Oh-My-OpenCodeを解剖する：コンテキストエンジニアリングの未来

OpenCodeがいま、開発者の間で急速に広がっている。高性能モデルが無料で使えるうえ、強力なプラグインエコシステムが整備されたことで、プロプライエタリなAIコーディングツールからの乗り換えが加速している。

中でも注目を集めているのが、韓国の開発者キム・ヨンギュ氏が作ったOh My OpenCodeだ。異なるAIモデルをチームとして協調させるマルチエージェントオーケストレーションの実践的な実装として、高い評価を得ている。

コードベースを読み込んでみて気づいたのは、巧みなプロンプト設計以上のものがあるということだ。コンテキストエンジニアリングのレベルで、本質的な構造のイノベーションが起きている。

シングルエージェント型コーディングツールの構造的限界

多くのAIコーディングツールは、1つのエージェントがプランナー、開発者、デバッガー、リサーチャーの全役割を逐次的にこなす。この設計には複合的な問題がある。

• コンテキストウィンドウの消耗が速い。 役割が切り替わるたびにエージェントの焦点が分断され、本来の作業に使うべきトークンがコンテキスト管理に消費される。
• コンテキスト過負荷がハルシネーションを引き起こす。 1つのコンテキストに関心事が積み重なりすぎると、モデルは情報を捏造したり、タスクを途中で放棄したりし始める。
• 単一モデルの弱点がそのまま全体の弱点になる。 アーキテクチャ設計が苦手でUIは得意なモデルを使っていても、アーキテクチャの仕事の質は低いままだ。

コアイノベーション：オーケストレーターベースのチームアーキテクチャ

Oh My OpenCodeの真の突破口はSisyphusだ。マネージャーエージェントが専門サブエージェントに作業を委任し、並列実行する仕組みになっている。

• Frontend EngineerがUIコンポーネントを担当し、Librarianがドキュメントリサーチを行い、Oracleがアーキテクチャを設計する - すべて同時並行で。
• 各エージェントのコンテキストはコードレベルで分離されている。これは「コンテキスト腐敗」 - 無関係な情報が蓄積してアウトプットの品質を劣化させる現象 - を防ぐうえで決定的に重要だ。
• 異なるモデルが異なる役割を担う。 アーキテクチャ設計はGPT-5（Oracle）、エビデンスベースのリサーチはClaude Sonnet 4.5（Librarian）、クリエイティブなUI生成はGemini 3 Pro（Frontend Engineer）、ドキュメント作成はGemini 3 Flash（Document Writer）に振り分けられる。各タスクに最適なモデルが割り当てられる設計だ。

Sisyphusオーケストレーター：設計思想

Sisyphusは単なる役割分担ではない。ワークフローをコードで強制する仕組みだ。

• createSisyphusAgent関数は、**Phase 0（Intent Gate）からPhase 3（Completion）**までのプロンプトを動的に組み立て、構造化された実行パイプラインを定義する。
• 並列実行は必須。 コードベースには// CORRECT: Always background, always parallelというコメントとともに、background_task呼び出しパターンが注入されており、並行実行が強制されている。
• 逐次実行は構造的にブロックされている。 サブタスクが順番に実行されることはアーキテクチャ上不可能で、すべてが並列にディスパッチされる設計になっている。

Librarianエージェント：エビデンスベースのリサーチの実践

ハルシネーションに対する最も洗練された防御機構は、Librarianエージェントに実装されている。

• すべての主張にGitHubパーマリンクが必須。 回答には検証可能なソースを引用しなければならない - 「公式ドキュメントの3行目、GitHub Issue #1234、ソースコードの47行目」のように。
• 回答前の分析ブロックが義務化されている。 エージェントはLiteral Request（ユーザーが入力した内容）とActual Need（ユーザーが本当に求めていること）を分離し、両方を明示する。
• Type A/B/C/D分類システムがGitHub Issues、公式ドキュメント、ソースコードを並列検索し、エビデンスを収集する。
• 2024年以前の情報は自動的に除外される。 エージェントは2025年以降のドキュメントを優先的に検索するよう強制される。

コードで強制される完了条件 - 希望的観測ではなく

最も感心したのは、動作がプロンプトだけでなくプログラムとして強制されている点だ。

• Todo Continuation Enforcer：エージェントが早期に完了したと判断した場合、システムがsession.idleイベントを検出し、「残りのタスクがあります。続行してください。」というシステムメッセージを注入する。エージェントが途中で勝利宣言する - AIコーディングツールにありがちな失敗パターン - を防ぐ仕組みだ。
• Ralphループ：エージェントは<promise>DONE</promise>タグを明示的に出力するまでループ内で実行され続ける。完了はモデルの自己評価ではなく、証拠によって判定される。

LSP統合：IDEと同じ方法でコードを理解する

一般的なgrep検索とは異なり、Oh My OpenCodeは実際のLanguage Server Protocolクライアントを実装している。

• LSPClientクラスがtypescript-language-serverなどの言語サーバーと直接通信する。
• Content-LengthヘッダーとJSON-RPCメッセージを処理する - VSCodeやIntelliJがコードを理解するために使っているのと同じプロトコルだ。
• Diagnostics、Definitions、Referencesがエージェントツールとして直接公開されており、人間の開発者がエディタで使っているのと同じコードインテリジェンスをAIが利用できる。

階層的コンテキスト注入

開発者が毎回プロジェクトのコンテキストを説明する必要はない。Oh My OpenCodeはこれを自動化する。

• findAgentsMdUp関数が、現在のファイルからディレクトリツリーを上方向にたどっていく。
• たとえばsrc/components/auth/LoginForm.tsxを編集する際、src/AGENTS.md、src/components/AGENTS.md、src/components/auth/AGENTS.mdが自動的に収集される。
• アーキテクチャルール、UIパターン、セキュリティガイドラインが、コードを書く前にエージェントのコンテキストに注入される - プロジェクトの暗黙知を自動的に取り込む仕組みだ。

なぜこれが重要なのか

CursorやClaude Codeと比較すると、Oh My OpenCodeはエンジニアリングファーストのアプローチを示している。複数モデルの強みを同時に活用し、コンテキストを構造的に管理し（運任せにするのではなく）、正しい動作をプロンプトの遵守に頼るのではなくコードで強制する。

このコミュニティ主導のアプローチが急速に広がるなか、プログラム的なガードレールを備えたマルチモデルチームのオーケストレーション - このパターンがAI支援開発の業界標準になるかどうか、注視する価値がある。