CopilotのHydraFusionはリクエストごとにモデルワークフローを構築する — プロジェクトのコンテキストはそれらすべての外部に存在しなければならない (2026)

この問いにおいて、投稿内の5つの点が重要であり、そのすべてがGitHub自身の言葉で語られています。

第一に、決定の単位です。「各リクエストに対して、HydraFusionは現在、3つの実行パターンのいずれかを選択します。」それらは、Single（「選択された1つのモデルがタスクを直接解決する」）、Cascade（「効率的なモデルがソリューションをドラフトし、クオリティゲートがそれを受け入れるか、より強力なモデルにエスカレーションするかを決定する」）、そしてCritique（「1つのモデルが結果をドラフトし、異なるモデルファミリーの独立した読み取り専用のクリティックがそれをレビューし、ドラフトモデルが1回修正する」）です。

第二に、クリティックは意図的に隔離されています。GitHubは5つの動作原則の1つとして「隔離されたレビュー（Isolated review）」を挙げています。「レビューのステップは、隔離されたツールなしのコンテキストで実行し、ソルバーステップは共有ワークスペースと通常の権限対応エージェントループを使用します。これにより、モデルはリポジトリを変更することなく、独立して作業を評価できます。」クリティックは読み取るだけです。ファイルに触れることはできず、ツールを持ち込むこともありません。

第三に（報道が完全に無視した一文ですが）、何が起きたかの記録は存在しますが、それは壁の向こう側にあります。「内部的には、ランタイムは各フェーズの役割、結果、コスト、レイテンシ、診断情報を記録するため、実行後にワークフローを理解できます。外部的には、開発者は1つの首尾一貫したレスポンスと、1つの権限対応の変更セットを受け取ります。」

第四に、中間の作業は意図的に非開示とされており、GitHubはその理由を説明しています。「現在：HydraFusionはワークフローのステージを表示しますが、1つの首尾一貫した結果を返すまでは中間のドラフトを保持します。」なぜなら「それらのドラフトはレビュー、修正、または破棄される可能性があるため、ライブで表示すると未完成の作業が最終的なものに見えてしまう可能性がある」からです。GitHubはトレードオフを隠すことなく挙げており（「十分な可視性がないまま待つことは、開発者にとって現実的なトレードオフである」）、さらに「より良い進捗状況のアップデートを積極的に模索している」と述べています。

第五に、プレビュー自体のスコープです。「このプレビューでは、最初のターン、シングルプロンプトのコーディングタスクから始めるのが最適です。次は、より長く反復的なセッションでの強力なマルチターンパフォーマンスに焦点を当てます。」GitHubはまた、「プレビューから学ぶにつれて、結果、モデル、ワークフロー、利用可能性、名称、製品の挙動が変更される可能性があります」と注意を促しています。これは、すべてのプランでCopilot CLIの/experimentalを通じて実行されます。

これら5つの要素は、リクエストごとに1つのクリーンな回答を提供するように最適化されたシステムを示しています。これは合理的な設計目標であり、回答を生み出した推論は、永続的なアーティファクトではなくランタイムのアーティファクト（一時的な生成物）となります。

優れた指示ファイル（instruction file）の役割は変わりません。Copilotは依然として指示ファイルを読み込みます。2日前のGitHub自身のエンジニアリング記事でも、その仕組みが明示されています。「プロンプトはエージェントの動作を形成する指示を運び、それらは毎ターンモデルに送信されます。」指示は再送信されるものであり、記憶されるものではありません。これはモデルが1つの場合でも真実でしたし、3つの場合でも真実です。

変わるのは、「誰が蓄積しているか」です。シングルモデルのセッションでは、作業を進めるにつれてモデルがコードベースを「理解し始めている」という直感（通常は誤りですが）が少なくとも存在しました。リクエストごとの実行プランでは、その直感を抱く余地はありません。レースコンディションを検出したクリティックは、GitHubの言葉を借りれば「異なるモデルファミリーの独立した読み取り専用のクリティック」でした。それはドラフトを見て判断を下し、その判断は修正された結果に圧縮されてあなたに届きました。次回、そのクリティックがその場にいることはありませんし、チェーンのどの部分もそれが気づいたことを保持していません。ルーティングがリクエストごとに行われ、GitHubが新しいモデルを「評価し、組み込む」につれてプールがシフトする可能性があるなら、確実に存在させたい情報は、ルーターが回避できない場所に記述しておく必要があります。

そして、これは特定のベンダー特有の奇妙な仕様ではありません。SourcegraphのAmpは、完全に異なる出発点から、ほぼ同一のアーキテクチャをドキュメント化しています。その「Modes and Models」ページによると、Ampは「異なる種類の作業に異なるモデルを使用します。メインエージェントがタスクを処理し、専門のサブエージェントがその特定のフォーカスされた部分を担当し、より小さなシステムモデルがサポート業務を処理します」とし、「より良い選択肢が利用可能になればモデルは変更される可能性がありますが、各モードとサブエージェントの役割は安定したままです」と述べています。隔離の問題について、AmpはGitHubよりも率直です。専門サブエージェントは「隔離されて動作するため、互いに通信することはできず、タスクの途中でユーザーがガイドすることもできません。また、会話全体ではなく、メインエージェントが提供する指示とコンテキストから開始します。メインエージェントは、彼らの段階的な作業を監視するのではなく、最終的なサマリーのみを受け取ります。」

2つの独立した製品、2つの独立したドキュメント群が、同じ結論に達しています。すなわち、複合的な実行は品質とコスト効率をもたらしますが、その代償として、中間的な理解は保持されるのではなく要約されるということです。これはアーキテクチャ上の結果であり、どちらのチームに対する批判でもありません。単に、永続的なレイヤーが別の場所になければならないことを意味しています。

「単に安価なモデルピッカーに過ぎない」 価格設定に関する報道が主流を占めましたが、これは構成がリクエストごとに変化することを見落としています。ピッカーは1つのものを選択します。HydraFusionはプランを構築します。GitHubはこの動きを「最適なモデルを選択することから、各タスクを解決するための最適な方法を動的に構築することへの移行」と表現しています。

「では、クリティックのレビューは履歴に残っているはずだ」 設計上、残っていません。あなたが受け取るのは「1つの首尾一貫したレスポンスと、1つの権限対応の変更セット」です。フェーズごとの記録は内部的なものです。

「マルチターンが予定されているから、この問題は自然に解決する」 GitHubはマルチターンのパフォーマンスが次に来ると述べていますが、これはより長いセッションの品質に関するものです。より優れたセッションであっても、それは依然としてセッションに過ぎません。実行から学んだことがタスクをまたいで永続化されることを示唆する内容は、投稿のどこにもありません。「マルチターン」を「永続的な記憶」の同義語として扱うと、チームは9月に説明した制約を10月に再び説明し直す羽目になります。

「では、Copilotには記憶がないということか」 それは誤りであり、はっきりと否定しておく価値があります。Copilotにはドキュメント化されたメモリサーフェスが存在し、このプレビューはその一つではありません。正確な表現はもっと限定的です。HydraFusionのドキュメント化された動作は実行プランニングと結果の配信をカバーしており、その中にタスク間でプロジェクトの事実を蓄積するストアに相当するドキュメント化された機能はありません。これは機能のスコープに関する記述であり、製品全体に対する主張ではありません。

対策はルーターと戦うことではありません。チェーン内のどのモデルにも「記憶する役割」を期待するのをやめ、すべてのプランのすべてのフェーズが読み取れる、小さく明示的なレイヤーを配置することです。

ステップ 1：現在混在している2種類のコンテキストを分離する

指示ファイルのすべての行を、次の2つのバケットのいずれかに分類します。

1つ目は「ここでの作業方法」です。ビルドコマンド、レビュー手順、スタイル制約、触れてはならないディレクトリなどです。これらはファイルに属し、現在とまったく同様に毎ターン再送信されます。GitHubもAmpもこれをうまく処理しているため、移動する必要はありません。

2つ目のバケットは「私たちが確立したこと」です。ストリーミングパーサーの使用をやめる決定とその理由、ベンダーのサンドボックスのために決済サービスが異なるテストコマンドを使用しているという事実、不安定な統合テストに対してすでに試した2つのアプローチなどです。このバケットは継続的に増加し、事前に書かれるのではなく作業中に発見されます。そして、これこそがリクエストごとのプランが保持できないものです。なぜなら、それを発見したフェーズは隔離され、要約されてしまったからです。

もしあなたの指示ファイルに現在2つ目のバケットの内容が含まれているなら、再送信されるプロンプトをメモリ（記憶）ストアとして使用していることになります。それは機能しなくなるまでは機能しますが、1つ目のバケットと同じプロンプト予算を静かに奪い合うことになります。

ステップ 2：セッションの最後ではなく、修正した瞬間にキャプチャする

価値のある素材は、エージェントに「間違っている」と伝えるときに現れます。その瞬間こそが制約が明示的になる瞬間であり、タスクを終わらせたいために、最も書き留める可能性が低い瞬間でもあります。

面倒な作業にするのではなく、1つのアクションにしましょう。エージェントを修正するとき、その修正を永続的な事実として述べ（例：「ベンダーのサンドボックスにはフィクスチャサーバーが必要なため、決済サービスのテストは npm test ではなく make test-payments で実行する」）、その一文をチャットだけでなくメモリレイヤーに送信します。理由を添えることで、将来の決定に直面したときにも生き残ることができます。根拠のない単なるルールは、不都合が生じた瞬間に上書きされてしまいます。

ステップ 3：プランのすべてのフェーズに同じ読み取りパスを提供する

レイヤーを外部に置くポイントは、どのモデルが実行されているかを気にしなくてよい点にあります。ソルバーフェーズ、カスケードのエスカレーション、および明日の新しいセッションのすべてが、同じ方法で同じストアにアクセスします。実際には、これをMCP経由で公開することで、プロトコルをサポートする任意のクライアントが読み取れるようにし、サポートしていないサーフェス向けにはAPI経由で公開することを意味します。

これは、逆方向からの隔離問題も解決します。GitHubのクリティックは設計上「ツールなし」で動作するため、レビューの途中で何かをクエリすることはありません。しかし、共有ワークスペースを使用するドラフトモデルは、書き込みを行う前に確立された事実を取得できます。制約をドラフト段階で取り込むことは、レビューでそれを検出することよりも優れています。

MemoryLakeは、まさにこの種の問題のために構築されたレイヤーです。特定のモデル、セッション、または実行プランよりも長生きする1つのストアです。

ステップ 1：APIキーを作成する

キーを生成し、約30秒で最初のリクエストを送信します。このキーにより、ルーティングされたワークフロー、CLIセッション、同僚のエディタが、それらを所有することなく同じ事実を読み取ることができます。

ステップ 2：最初の記憶（メモリ）をアップロードする

プロジェクトの確立された決定事項（アーキテクチャのメモ、現在のリトライポリシーの背景にあるインシデント報告書、今でも全員が議論している設計書など）がすでに記載されているドキュメント、画像、ファイルをドロップします。網羅しようとするのではなく、何度も説明するのにうんざりしていることから始めましょう。

ステップ 3：AIとエージェントを接続する

Claude、Codex、OpenClaw、その他のエージェントにMCPまたはAPI経由でアクセスを許可します。Copilot CLIワークフローの場合、タスクの開始時に関連する記憶を読み取ることで、ドラフトに事実を反映させ、作業中に加えた修正を書き戻します。

最初に気づくのは、特定の種類の「繰り返される会話」が消えることです。「この関数は何をするのか」といった質問（エージェントはもともとこれが得意でした）ではなく、「7月にそれを試したらステージング環境が壊れた」といった会話です。この一言を人間が提供する必要はなくなります。

2つ目は、モデルの変更によるコスト（手間）がかからなくなることです。GitHubは「GitHub Copilotで新しいモデルが利用可能になったとき、それらを評価してモデルプールに組み込むことができます」と述べています。もしあなたの永続的な知識がプールの外部に存在していれば、プールの変更は品質とコストの変更を意味するだけであり、エージェントが知っていることの変更にはなりません。これが「アップグレード」と「移行（マイグレーション）」の違いです。

3つ目は、隔離されたクリティックによる損失が少なくなることです。その推論プロセスを見ることはできませんし、おそらく見る必要もありません。破棄されたドラフトを表示すると「未完成の作業が最終的なものに見えてしまう可能性がある」というGitHubの主張は妥当です。しかし、その判断があなたが受け入れる変更として表面化したとき、その結論を1文で記録することができます。推論はランタイムに残り、結論はあなたのものになります。

4つ目は、主にチームにとって重要です。任意のクライアントが読み取れるストアは、新しく入ったエンジニアのエージェントが初日から読み取れるストアであることを意味します。そのため、知識は「長いセッションを持っていた誰か」の専有物ではなくなります。

「トランスクリプト（会話記録）ではなく、結論を書く。」 ルーティングされたワークフローは、あなたが目にすることのない多くの中間生成物を生み出します。それを再構築しようとしないでください。1行の結果と理由を記録してください。

「指示ファイルは不変のルール（インバリアント）のみに限定する。」 取り組んでいる作業に関係なく真実であることはファイルに属し、発見されたことはストアに属します。これらを混在させると、発見された事実がビルドコマンドと同じプロンプト予算を奪い合うことになります。

「すべての事実に理由を添付する。」 「ここでは make test-payments を使用する」は上書きされてしまいます。「ベンダーのサンドボックスにはフィクスチャサーバーが必要なため、ここでは make test-payments を使用する」は上書きされません。

「削除するのではなく、上書き（代替）を記録する。」 決定が覆ったときは、その旨と時期を明記してください。すべてのバージョンを保持するアーカイブは何の解決にもなりません。古いバージョンを静かに削除するストアは、新しいバージョンを説明できません。

HydraFusionは、コーディングエージェントにおける次の進化は、1つのモデルを選択することではなく、モデルを組み合わせることから得られるという、十分に議論された賭けです。その5つの動作原則（隔離されたレビュー、制限された実行、フェイルセーフな適用、検証されたルーティング、完全なアカウンティング）は、他人のリポジトリを実行することについて深く考え抜いたチームによるものであることを物語っています。

この賭けが静かに行っているもう一つのことは、ある前提を退場させることです。もはや、セッションの背後に記憶を保持していると思われる単一のモデルは存在しません。ルーターはリクエストごとに新しいプランを選択し、クリティックは意図的に隔離され、あなたに届くのは1つの回答と1つの変更セットだけです。Ampは異なる方向から同じ形状をドキュメント化しており、これは複合エージェントが一般的に向かっている方向であることを示唆しています。

実践的な対応はわずかです。コンテキストのうち、どれが不変で、どれが発見されたものかを判断します。不変の部分は、すでに機能しているファイルに残しておきます。発見された部分は、いかなる実行プランも回避できない場所に置き、すべてのエントリに理由を添付し、次のルーティング決定を勝ち取ったモデルがそれを読み取れるようにします。そうすれば、GitHubが望むだけモデルプールが変更されても、変わるのはコードが書かれるスピードだけになります。