モダンOBSプラグイン開発

C++ MIX 第17回でOBSプラグイン開発について発表しました。
OBSプラグイン開発は厳しい世界ではありますが、誰かがやらなければならない分野でもあります。
我こそはという方は是非挑戦してみてください。
あなたが取り組むために必要な道は、すべて私が舗装しました。
https://lnkd.in/e-NYnsGS

Transcript

1. © 2026 Kaito Udagawa All Rights Reserved. モダンOBSプラグイン開発 Kaito Udagawa / umireon / うみれおん https://github.com/umireon 1
2. © 2026 Kaito Udagawa All Rights Reserved. 発表者紹介 #宇田川海斗 #32歳 #YouTuber #絵描き • 氏名：宇田川 海斗（うだがわ かいと） • 早稲田大学CS学科の修士卒 • 社会人4年目（開発→SRE→DevExp→無職） • GitHub上の初コミットは2011年 • Arctic Code Vault Contributor • OSS貢献の経験あり（vim、Homebrew、AWS、nvmなど） • pnpmメンバーおよびobs-backgroundremovalメンテナ • ポケモンにほぼ全人生（28年間）捧げてます 2
3. © 2026 Kaito Udagawa All Rights Reserved. 宣伝 ポケモンユナイト一緒にやってください サポタンでマクロキャリーします ランクはマスターです https://www.youtube.com/@umireon https://x.com/umireon FC4CH7A / 7412-5051-0082-9242 3
4. © 2026 Kaito Udagawa All Rights Reserved. 背景と動機： OBSプラグイン開発の技術的課題 • YouTube/Twitchでは長時間配信の需要が高まっている ◦ 業界標準の配信ソフトウェアが、 OBS（Open Broadcaster Software）である • 更なる視聴体験の向上のため、 OBSプラグイン開発が注目されている ◦ しかし、OBSのAPIはレガシーなC言語であり、RAIIなどの現代的な安全性は提供されない • 近年では、 AIによるリアルタイム映像・音声処理が台頭しつつある ◦ ONNX Runtimeなどを活用した高度な推論が求められるが、リソース管理が難しい • 「配信事故」は許されない ◦ 配信は数時間にも及ぶことも多いが、プラグインが一瞬のクラッシュもメモリリークも発生させないこ とは、ライブ配信の絶対的な生命線である • ゴール：Modern C++を活用し、安全性と生産性を両立する ◦ レガシーC APIの世界でいかに安全に AIを動かすか。その手法とパターンを紹介する 4
5. © 2026 Kaito Udagawa All Rights Reserved. OBSプラグインの開発について 5
6. © 2026 Kaito Udagawa All Rights Reserved. OBS (Open Broadcaster Software) • 配信業界のデファクトスタンダード ◦ YouTube, Twitch, NVIDIA, Intel 等が公式スポンサーとして開発を支援 ◦ 世界中の配信インフラとして、商用・非商用問わず圧倒的なシェアを持つ • オープンソースソフトウェア ◦ プロジェクト全体がGPLv2 or laterでライセンスされており、特許関連もクリーン ◦ プラットフォーム陣営ごとに派生ソフトウェアを作成することも自由である • 開発母体 ◦ OBS Project（非営利オープンソースプロジェクト）、リーダー： Jimmy ◦ GitHub: https://github.com/obsproject/obs-studio • ユーザーの例 ◦ 個人クリエイター、オンラインセミナー、テレビ局のネット放送 6
7. © 2026 Kaito Udagawa All Rights Reserved. OBSの特徴：多彩な機能 • 自由度の高いシーン作成 ◦ 様々な入力デバイス、画面共有、画像などを組み合わせて好みの画面を作ることが可能 ◦ 音声に関しても同様の自由度があり、同時に 6チャンネルまで制御可能 • リアルタイム配信・録画 ◦ 多くの配信サイトへの接続設定を内蔵しており、すぐに配信を始めることが可能 ◦ プログラム全体が低遅延を意識した C++で記述されており、動作が安定している ◦ 動画録画アプリケーションとしても事実上の標準である • 多彩なエンコード環境への対応 ◦ ソフトウェアエンコードはもちろん、 GPUやQSVなどのハードウェアエンコードにも対応 ◦ MacやLinuxの環境における安定動作にも注力している 7
8. © 2026 Kaito Udagawa All Rights Reserved. OBSプラグインの紹介 • Background Removal / Virtual Green-screen & Low-Light Enhance ◦ 開発者：Roy Shilkrot（タフト大教授）、Kaito Udagawa（発表者） ◦ https://github.com/royshil/obs-backgroundremoval ◦ 全世界で2番目に有名なOBSプラグイン ◦ エッジデバイス推論を活用して、グリーンバックなしで背景除去を行う ◦ ONNX Runtimeを推論バックエンドとして、複数のモデルを動作させることが可能 • Multiple RTMP outputs plugin ◦ 開発者：sorayukiさん ◦ https://obsproject.com/forum/resources/multiple-rtmp-outputs-plugin.964/ ◦ 全世界で最も有名な OBSプラグイン ◦ 同時に複数のサービスに配信を行うことを可能とする、 OBSのAPIの薄いラッパー 8
9. © 2026 Kaito Udagawa All Rights Reserved. Modern C++：OBSプラグイン最初のフロンティア • OBSプラグインの APIはC言語から変わることはない ◦ OBSではオーバーヘッドを極限まで低減させることが求められるため、プラグインの形式もネイティ ブライブラリ形式にこだわる必要がある。この制約条件があるため、 OBSプラグインの接続インター フェイスは、どのプラットフォームでも ABIが極めて安定している C言語のシンボルテーブル以外を 採用することはできない。 • C言語インターフェイスと Qt6と最も上手に統合できる言語が C++である ◦ C言語で複雑なメモリ管理をすると容易に破綻することは誰しもが知ることである。 ◦ C++のRAIIやSTLコンテナを活用することで、 OBSのプラグインに求められる複雑で厳格なメモリ管 理を、言語機能に基づいて自然に実現することが可能である。 ◦ OBSは全てのプラットフォームで Qt6によるGUIの実装を行っているため、 UIを提供するためにも C++を活用することは都合がいい。 9
10. © 2026 Kaito Udagawa All Rights Reserved. std::unique_ptrによるメモリ管理の自動化 #C++ カスタムデリータによる自動解放 https://github.com/kaito-tokyo/live-backgrou ndremoval-lite/blob/main/src/ObsBridgeUtils /KaitoTokyo/ObsBridgeUtils/ObsUnique.hpp malloc/freeの自動化です。 OBSではこの形式のメモリ管理は頻出で、頻繁 にメモリリークを起こしてクラッシュしています。 配信は長時間にわたるので、1箇所リークしてる だけでかなり不安定になります。 これでしらみつぶしリーク探しから解放されたの でかなり助かりました。 struct BfreeDeleter { void operator()(void *ptr) { bfree(ptr); } }; using unique_bfree_char_t = std::unique_ptr <char, ObsUnique::BfreeDeleter >; struct ObsDataDeleter { void operator()(obs_data_t *data) { obs_data_release (data); } }; using unique_obs_data_t = std::unique_ptr <obs_data_t, ObsUnique::ObsDataDeleter >; 10
11. © 2026 Kaito Udagawa All Rights Reserved. std::initializer_listを活用した構造化ログ API #C++ テンプレートとかで無茶してないロガーの実装 https://github.com/kaito-tokyo/live-backgroundremov al-lite/blob/main/src/Logger/KaitoTokyo/Logger/ILogg er.hpp ロガーはどのアプリケーションでも辛いと思うのですが、 OBSのプラグインではユーザーがまともに調査できないと いう問題があるので、綺麗にログを取れることは開発を進 める上で死活問題です。 また、OBSには標準のロガーがあるのですが、歴史的経 緯か色々わけがわからない仕様になっているため、既存 のロガーを使うのは難しく、単純なものを自作しています。 OBSでは現在のログレベルを取得することが不可能なの で、とにかく何であってもゼロオーバーヘッドで出力できる 仕組みを作る必要がありました。 struct LogField { std::string_view key; std::string_view value; }; virtual void log( LogLevel level, std::string_view name, std::source_location loc, std::span<const LogField> context) const noexcept = 0; logger->error( "PluginConfigLoadError" , {{"error", e.what()}}); 11
12. © 2026 Kaito Udagawa All Rights Reserved. シェーダーパイプラインの抽象化 #C++ #HLSL Direct3DとかをラップしたOBSのGraphics APIをさらにラップしてパイプラインを組めるようにしたもの https://github.com/kaito-tokyo/live-backgroundremoval-lite/blob/main/src/LiveBackgroundRemovalLite/MainFilter/MainEffect.hpp 映像処理のプラグインなので GPUと直接やりとりをすることも多いのですが、テクスチャの割り当てやシェーダーの呼び出し順序など、とにかくシビアな エンジニアリングが求められる箇所が多すぎます。計算資源とメモリ領域が無限なら簡単に記述することができるのですが、プラグインに割り当てる資 源は一ミリもないという実際の制約を突きつけられると、とたんに曲芸を実行する必要が発生します。以下のコードはその曲芸を実践しているのです が、C++のパワーでただの関数呼び出しにしか見えません。 mainEffect_.resampleByNearestR8(r32fSubGFSource_, r8SegmentationMask_); mainEffect_.applyBoxFilterR8KS17(r32fSubGFMeanGuide_, currentSubLuma, r32fSubGFIntermediate_); mainEffect_.applyBoxFilterR8KS17(r32fSubGFMeanSource_, r32fSubGFSource_, r32fSubGFIntermediate_); mainEffect_.applyBoxFilterWithMulR8KS17(r32fSubGFMeanGuideSource_, currentSubLuma, r32fSubGFSource_, r32fSubGFIntermediate_); mainEffect_.applyBoxFilterWithSqR8KS17(r32fSubGFMeanGuideSq_, currentSubLuma, r32fSubGFIntermediate_); mainEffect_.calculateGuidedFilterAAndB(r32fSubGFA_, r32fSubGFB_, r32fSubGFMeanGuideSq_, r32fSubGFMeanGuide_, r32fSubGFMeanGuideSource_, r32fSubGFMeanSource_, guidedFilterEps); mainEffect_.finalizeGuidedFilter(r8GuidedFilterResult_, r32fLuma_, r32fSubGFA_, r32fSubGFB_); 12
13. © 2026 Kaito Udagawa All Rights Reserved. OBSプラグインを取り巻く現状 13
14. © 2026 Kaito Udagawa All Rights Reserved. 直近のインシデントについて [1] 2026年3月9日、OBS ForumのAdminが フォーラムで発生したセキュリティインシ デントについて報告した。OBS Forumは ユーザーがOBSのプラグインを配布でき る公式の場である。今回、フォーラム上に 公開されていたいくつかのプラグインの配 布ページが侵害され、ページ上のバイナリ が悪意あるバージョンに差し替えられると いう事案が発生した。侵害された該当プラ グインをダウンロードしたユーザーは、そ れらを直ちに削除しPCをスキャンするよう に強く勧告されている。 [1] https://obsproject.com/forum/threads/resource-security-incident.194555/ [2] https://x.com/OBSProject/status/2031074701850603549 14
15. © 2026 Kaito Udagawa All Rights Reserved. 私が考える OBSのプラグインに求められる要件 • OBSおよびそのプラグインは、ユーザーの重要な財産を直接扱っている ◦ OBSは配信・録画の基盤ソフトウェアであるから、その時点では非公開のユーザーの動画・音声 データに直接触れることも多い。そのような非公開のデータ自体が操作の対象のソフトウェアなの で、OBSのプラグインには極めて高い水準の機密性と透明性が求められる。 ◦ ユーザーのデータを破損させないことは前提として、ユーザーのデータを漏らさないセキュリティ や、ユーザーのデータを勝手に利用しない誠実な開発プロセスが重要になる。 • SLSA (Supply-chain Levels for Software Artifacts) の最前線になりうる [2] ◦ OBSのプラグインにマルウェアを混入させれば、いとも簡単に最重要な未公開コンテンツをリークす ることが可能になる。例えば、著名な YouTuberの公開前コンテンツを取得できるなら、ありとあらゆ る手段で攻撃が試みられる可能性が高い。 ◦ ユーザーを守るために、コンテンツを守るために、何よりも開発している自分自身を守るために、開 発プロセスの多層防御は必須となる。 [2] https://slsa.dev/ 15
16. © 2026 Kaito Udagawa All Rights Reserved. GitHub Artifact Attestation [3] #透明性を支える技術 • 偽造不可能なビルド証明書の仕組みで信頼の連鎖を構築する ◦ サプライチェーンセキュリティにおいては、依存しているライブラリ、ビルドに使用したツールや環 境、そして自分自身が作成したプログラムの出自の全てを数学的に偽証不可能な形で誰もが検証 できることが求められている。（ SLSA 2以上）[4] ◦ GitHub Artifact Attestationは数学的に偽証不可能な証明書の発行を助けてくれる GitHubの提供 する比較的新しいサービスである。 • GitHub Actionsで透明性の高いビルドをしたことを証明してくれる ◦ GitHub公式アクション：https://github.com/actions/attest ◦ ワークフローでこのアクションを呼び出すだけで証明書の発行が完了する。 ◦ ビルドの透明性の担保は依然として開発者の責任であるため銀の弾丸ではない。 ◦ アルゴリズム的に難しい部分を GitHubが担当しているので、開発者は仕組みに集中できる。 [3] https://docs.github.com/actions/concepts/security/artifact-attestations [4] https://slsa.dev/spec/v0.1/requirements 16
17. © 2026 Kaito Udagawa All Rights Reserved. 依存関係を vcpkgで管理する #透明性を支える技術 • 依存ライブラリをよく知られた標準的な仕組みで管理する ◦ サプライチェーンセキュリティにおいて、依存関係をどのように管理するかは最も繊細で慎重に検 討を行わなければならない問題の一つである。 ◦ Microsoftが開発を主導するvcpkgは、C++のパッケージマネージャーとしては十分に検証されてお り、侵害された時のリスクを最小化することができると考えられる。 ◦ ライブラリのビルドプロセスも vcpkgのコミュニティが精査しているため、開発者の潔白を証明してく れる追加のレイヤーを得られていると考えることもできる。 • ビルドの再現性に基づくバイナリキャッシュの機能を活用する ◦ ビルドの全てのステップを GitHub Actions上で実行するなら、vcpkgが生成するバイナリは必ず安 定するので、バイナリキャッシュを活用してビルド時間を大幅に短縮できる。 ◦ 自前のバイナリキャッシュ基盤： https://github.com/kaito-tokyo/vcpkg-obs-kaito-tokyo ◦ これについてはCloudflareのミートアップで話すかもしれない 17
18. © 2026 Kaito Udagawa All Rights Reserved. GitHub Agentic Workflows #透明性を支える技術 • GitHubはLLM AIに基づく柔軟性の高いワークフローの仕組みを公開した ◦ 記事：https://github.blog/ai-and-ml/automate-repository-tasks-with-github-agentic-workflows/ ◦ 世間ではAIの力で煩雑なCIを楽に書けるようになりそうだという受け入れ方をされているがそんな ことはなく、より厳格で高度な判断が求められるチェックを精度高く行うために開発された仕組みで あると考えている。 ◦ 非常に活発に開発されており、昨日確認したら重要な機能が一つリプレースされていた 😇 • プルリクエストの厳格なコンプライアンスチェック ◦ OBSのプラグインにおいては、プルリクエストのコンプライアンスチェックが特に重要である。映像業 界には多数の特許が存在するため、無策にプルリクエストを取り込むとプロジェクト自体が消滅した り訴訟リスクを抱えたりすることとなる。 ◦ https://github.com/royshil/obs-backgroundremoval/blob/main/.github/workflows/pr-validation.md ◦ 厳格なチェックには厳格なプロンプトの開発が必須となる。 18
19. © 2026 Kaito Udagawa All Rights Reserved. 「モダンOBSプラグイン開発」発表まとめ • OBSでみんな配信できるようになった、OSSとして利用可能だから • 無料だけど最高品質が求められるし、みんな拡張したがっている • みんなが欲しいものをプラグインとして放流したい、でも品質が高くないとみんな 怒ってしまう。OBS Projectもエコシステム維持のために怒る • Modern C++使ってみんなを満足させよう！ • でも最近はセキュリティも大事、重大インシデントも発生したし • それで、C++では難しい厳密なCI/CDにも取り組まないといけなくなった • 私は誰よりも先導してSLSAを実践し、開発者の実践の礎となりたい • GitHubとMicrosoftのおかげでC++でもSLSAができるようになった • OBSプラグインの未来は私が照らす、最有力プラグインのメンテナとして 19
20. © 2026 Kaito Udagawa All Rights Reserved. 本スライドの権利表示 © 2026 Kaito Udagawa All Rights Reserved. 本資料の著作権は宇田川 海斗に帰属します。 引用の際は、著作権法に基づき出典を明記してください。 無断複写・転載・翻案を禁じます。 C++ MIXの団体には発表映像の公開を認めています。 上記の範囲を超えた再利用を検討している場合は umireon@kaito.tokyo まで連絡して ください。 20