Microsoft developer platform documentation update のうち、2026年5月5日に確認された「feat(agents): optimize RPI agent context management with discipline rules」は、RPI（Research, Plan, Implement, Review）系エージェントの会話コンテキストを軽くするための変更です。結論から言うと、既存の呼び出し方法は大きく変えず、チャットには要約だけを返し、詳細は .copilot-tracking/ 配下の追跡ファイルに残す運用へ寄せる内容です。RPIエージェントをそのまま使う人よりも、エージェント定義を配布・改変しているチーム、サブエージェントの出力を自動処理している開発チームが確認すべき更新です。(GitHub)
Microsoft developer platform documentation updateで何が変わったのか
今回の更新は、Microsoftの hve-core リポジトリにあるRPIエージェント群のコンテキスト管理ルールを見直すPRです。PR説明では、RPI親エージェントに共通の Context Discipline セクションを追加し、サブエージェントのチャット応答をエグゼクティブサマリーに制限する方針が示されています。(GitHub)
ポイントは「チャットを作業ログの本体にしない」ことです。これまでのように長い調査結果、検証結果、コードブロック、差分、引用をチャットへ大量に返すのではなく、完全な内容は追跡ファイルへ保存し、チャットはその場所を示すインデックスとして使います。
実務上の意味は大きく、長時間のRPIセッションで会話履歴が肥大化しにくくなります。一方で、詳細を読みたい場合はチャットだけで判断せず、該当する .copilot-tracking/ ファイルを確認する運用が必要になります。
変更の中心は「Context Discipline」の追加
今回の更新で最も重要なのは、5つのRPI親エージェントに同じ考え方の Context Discipline が追加されたことです。対象は rpi-agent.agent.md、task-researcher.agent.md、task-planner.agent.md、task-implementor.agent.md、task-reviewer.agent.md の5ファイルです。ファイル差分上でも、各親エージェントに23行の Context Discipline セクションが追加されています。(GitHub)
このセクションは、親エージェントがサブエージェントから結果を受け取った後に、無駄な再読込や長文の再掲をしないよう制御するためのものです。
| 変更点 | 内容 | 実務での影響 |
|---|---|---|
| Lean Post-Work Turn | サブエージェント終了後は、1サブエージェントにつき1行の結果、必要なら1回の追跡ファイル更新で止める | 「次に何をするか」の長い語りや、同じ結果の再掲が減る |
| Response Mode Selection | Direct / Lightweight / Standard / Full から最も軽い応答モードを選ぶ | すべての依頼で重いサブエージェント処理を走らせにくくなる |
| Subagent Result Handling | サブエージェントのチャット応答を「完全な結果」ではなく「索引」として扱う | 詳細確認が必要な場面だけ追跡ファイルを読み直す |
この変更により、RPIエージェントの使い方は「最初からフル処理を前提にする」のではなく、「必要な重さを選ぶ」設計に近づきます。
Response Mode Selectionの4段階を理解する
Context Discipline では、親エージェントが依頼内容に応じて4つの応答モードを選ぶよう定義されています。これは、RPIエージェントを使う開発者にとって確認すべき重要な判断基準です。(GitHub)
| モード | 使う場面 | 例 |
|---|---|---|
| Direct | 現在の会話コンテキストだけで答えられる場合 | 「この計画の要点だけ教えて」「今の状態は？」 |
| Lightweight | 1つのサブエージェントで足りる軽い作業 | 単一ファイルの確認、調査結果の要約 |
| Standard | 通常のRPI処理 | 調査、計画、実装、レビューを段階的に進める |
| Full | 複数サブエージェントや横断的な統合が必要な場合 | 複数領域の並列調査、大規模な設計レビュー |
実務では、ユーザー側も依頼文を少し変えるだけで無駄な処理を減らせます。たとえば、単に「このレビュー結果を要約して」と頼む場合は、Full相当の深い再調査を期待するのではなく、「既存の追跡ファイルを前提に要点だけ整理して」と書くと、軽量な応答に寄せやすくなります。
逆に、複数の設計案を比較し、採用可否まで判断したい場合は「必要なら複数サブエージェントで調査し、根拠を追跡ファイルに残して」と明示すると、Fullに近い動きが適しています。
サブエージェントのチャット応答は短くなる
今回の更新では、4つのRPIサブエージェントの Response Format も変更されています。対象は researcher-subagent.agent.md、plan-validator.agent.md、implementation-validator.agent.md、rpi-validator.agent.md です。PRの説明では、サブエージェントのチャット応答を最大7件の優先度付き箇条書き、各240文字以内、ブロッキング時のみ最大3つの確認質問に制限する方針が示されています。(GitHub)
具体的には、チャット側には次のような短い情報だけが返る想定です。
| 出力項目 | 内容 |
|---|---|
| ファイルパス | 詳細が保存された追跡ファイルの相対パス |
| ステータス | Complete、Blocked、Pass、Failなど |
| 主要な発見事項 | 最大7件、優先度順 |
| 確認質問 | 作業が止まる場合のみ最大3件 |
| 詳細への誘導 | Re-read <path> のような追跡ファイル参照 |
この変更で注意したいのは、「チャットが短い＝情報が不足している」ではない点です。完全な調査結果や検証結果は、チャットではなく追跡ファイルに保存される設計です。
たとえば、implementation-validator は完全な検証結果をレビュー用ログに書き込んだうえで、チャットでは検証ステータス、最大7件の重要な発見、必要な確認質問、詳細ファイルへの誘導に絞るよう変更されています。(GitHub)
影響を受ける人と受けにくい人
このMicrosoft developer platform documentation updateは、すべての利用者に同じ影響があるわけではありません。特に確認すべきなのは、RPIエージェントをチーム運用や自動化に組み込んでいるケースです。
| 対象者 | 影響度 | 確認すべきこと |
|---|---|---|
| RPIエージェントを通常の対話で使うユーザー | 低〜中 | チャットが短くなっても、詳細は追跡ファイルにあると理解する |
@rpi-agent などを業務フローに組み込むチーム | 中 | 詳細確認の手順を .copilot-tracking/ 前提に変える |
| サブエージェントの出力をパースする自動化担当者 | 高 | チャット全文ではなく、ファイルパスとステータスを起点に処理する |
| RPI系エージェントを独自改変している開発者 | 高 | 親エージェントとサブエージェントの出力形式を合わせる |
| プラグインや拡張として配布しているメンテナー | 高 | インライン化されたContext Disciplineの差分管理を確認する |
特に注意したいのは、チャット応答をそのままCIログ、レビューコメント、タスク管理ツールへ転記していたケースです。今後はチャットに完全な検証結果が含まれないため、必要に応じて追跡ファイルを読み取る設計に変える必要があります。
既存の呼び出し方法は基本的に変わらない
PRのサンプルフローでは、既存のRPIワークフロー呼び出しである @rpi-agent、@task-researcher、@task-planner、@task-implementor、@task-reviewer は変更されないと説明されています。コンテキスト最適化は透過的に動く位置づけです。(GitHub)
つまり、エンドユーザーがすぐに新しいコマンドを覚える必要はありません。ただし、返ってくる内容の見え方は変わります。
従来の期待値が「チャットにすべて出る」だった場合、更新後は次のように考え方を変える必要があります。
| 以前の見方 | 更新後の見方 |
|---|---|
| チャット本文が最終成果物 | チャットは成果物への案内 |
| サブエージェント結果を親が再掲する | 親は要点とパスだけ返す |
| 詳細も会話履歴で追える | 詳細は .copilot-tracking/ で追う |
| 毎回フル処理に近い動きを期待する | DirectやLightweightを含め、必要な重さを選ぶ |
この差を理解していないと、「以前より情報が少なくなった」と誤解しやすくなります。実際には、情報の保存場所がチャットからファイルへ移ったと捉えるのが正確です。
移行時に確認すべき設定と運用ポイント
RPIエージェントをチームで使っている場合は、単に最新版を取り込むだけでなく、追跡ファイルを前提にした運用へ整えることが重要です。
.copilot-tracking/ を成果物の保存場所として扱う
今回の変更では、.copilot-tracking/ 配下の追跡ファイルが事実上のソース・オブ・トゥルースになります。PR説明でも、RPI tracking filesが引き続き真実の情報源であり、チャット応答は完全なペイロードではなくエグゼクティブサマリーになると整理されています。(GitHub)
そのため、次の点を確認してください。
| 確認項目 | チェック内容 |
|---|---|
| 保存場所 | .copilot-tracking/ がワークスペース内で生成・更新されるか |
| バージョン管理 | 追跡ファイルをGit管理するのか、作業用ログとして除外するのか |
| 機密情報 | 調査結果やコード断片に秘密情報が混ざらない運用になっているか |
| レビュー導線 | チャット要約から該当ファイルをすぐ開けるか |
| 自動処理 | チャット本文ではなく、ファイルパスを起点に後続処理できるか |
特に企業利用では、追跡ファイルに検証結果、設計上の判断、コード参照、却下した代替案などが残る可能性があります。保存先や共有範囲を曖昧にしたまま導入すると、ナレッジ管理と情報管理の両方で問題が起きやすくなります。
チャット出力をパースしている処理を見直す
サブエージェントのチャット応答は、最大7件の発見事項や最大3件の確認質問など、短い形式に寄せられています。researcher-subagent と rpi-validator では、未完了の次アクションも最大5件に制限される差分が確認できます。(GitHub)
既存の自動化で次のような処理をしている場合は、見直しが必要です。
| 既存処理 | 見直し方 |
|---|---|
| チャット全文から検証結果を抽出 | まずファイルパスを取得し、追跡ファイルを読む |
| チャット内のコードブロックを保存 | コードや証跡は追跡ファイル側から取得する |
| 箇条書き件数を前提に判定 | 最大件数が制限されるため、詳細件数はログ側で確認する |
| 長い引用や差分をレビューコメントに貼る | 要約だけコメントし、詳細ファイルへの参照を付ける |
実務では、「チャット応答を人間向けのサマリー」「追跡ファイルを機械処理や監査向けの詳細」と分けると運用しやすくなります。
導入後の動作確認手順
更新を取り込んだ後は、単にエージェントが起動するかだけでなく、コンテキスト管理の意図どおりに動いているかを確認します。
| 手順 | 確認内容 | 合格基準 |
|---|---|---|
| 簡単な質問を投げる | Direct相当で処理されるか | 不要なサブエージェント呼び出しやファイル読込が発生しない |
| 単一テーマの調査を依頼する | Lightweight相当で処理されるか | 1つのサブエージェント結果と追跡ファイル参照に収まる |
| 通常のRPI作業を実行する | Standard相当で処理されるか | 追跡ファイル更新と次フェーズへの引き渡しが成立する |
| 複数領域の比較を依頼する | Full相当が必要時だけ使われるか | 複数サブエージェントの結果が簡潔に整理される |
| 詳細確認を依頼する | 必要なときだけ追跡ファイルを読み直すか | 要約にない根拠が必要な場面でのみファイル参照する |
確認時のコツは、あえて「軽い質問」と「重い質問」を分けて投げることです。どちらも同じように大きな処理になる場合、Response Mode Selectionがうまく効いていない可能性があります。
よくある失敗と回避策
チャットが短くなっただけで品質低下と判断する
今回の変更では、チャットは意図的に短くなります。品質を見るときは、チャットの長さではなく、追跡ファイルに必要な証跡が残っているかを確認してください。
たとえば、実装レビューでチャットには「重大な回帰が1件」としか出ていなくても、レビュー用ログに対象ファイル、再現条件、検証結果、修正案が残っていれば、設計どおりです。
追跡ファイルを読まずに意思決定する
親エージェントは、サブエージェントのチャット応答を完全な結果ではなく索引として扱うよう定義されています。計画構造、フェーズ順序、代替案の採否、検証結果の判断など、詳細な根拠が必要な場合は追跡ファイルを再読込するルールです。(GitHub)
レビュー承認や設計判断のような場面で、チャットの短い要約だけを根拠にするのは避けるべきです。
独自エージェントだけ古い出力形式のまま残す
RPI親エージェントだけを更新し、独自のサブエージェントが長文のチャット出力を続けると、コンテキスト削減の効果が薄れます。逆に、サブエージェントだけを短くして親エージェント側が毎回詳細ファイルを読み直す場合も、意図した軽量化になりません。
独自エージェントを使っている場合は、親と子の両方で次の方針をそろえる必要があります。
| 対象 | そろえるべき方針 |
|---|---|
| 親エージェント | 最軽量モードの選択、サブエージェント後の短い終了ターン |
| サブエージェント | 完全な詳細はファイルへ保存、チャットは要約 |
| 追跡ファイル | 判断に必要な証跡、引用、検証結果を保持 |
| 自動化 | チャット本文ではなく、追跡ファイル参照を前提にする |
セキュリティと依存関係への影響
PR説明では、今回の変更により新しい依存関係は追加されず、機密情報やセキュリティ関連スクリプトの変更もないとされています。自動検証としてMarkdown lint、frontmatter validation、collection metadata、plugin generationの通過も記載されています。(GitHub)
ただし、これは「運用上の情報管理リスクがゼロ」という意味ではありません。むしろ、詳細情報が .copilot-tracking/ に集約されるため、次の点はチーム側で確認すべきです。
| 観点 | 注意点 |
|---|---|
| 機密情報 | 調査ログにAPIキー、内部URL、顧客情報が混ざらないようにする |
| Git管理 | 追跡ファイルをコミット対象にするか、.gitignore で除外するか決める |
| レビュー共有 | チャットではなくファイル参照を共有する場合、閲覧権限に注意する |
| 監査 | 判断根拠を残すなら、追跡ファイルの命名と保存期間を統一する |
この更新は、コンテキスト最適化だけでなく、エージェント作業のログ設計を見直すきっかけにもなります。
すぐに取るべき対応
Microsoft developer platform documentation updateとしてこの変更を確認する場合、まずは自分たちがRPIエージェントをどのレベルで使っているかを切り分けてください。
単にチャットでRPIエージェントを使っているだけなら、まず「詳細は .copilot-tracking/ にある」と理解すれば十分です。開発チームで運用している場合は、追跡ファイルの保存・共有・レビュー導線を確認してください。自動化に組み込んでいる場合は、チャット全文依存の処理を見直し、ファイルパスとステータスを起点にした処理へ移行するのが優先です。
最後に、PRベースの情報はマージ前後で差分が変わる可能性があります。採用前には、対象ファイルが5つの親エージェントと4つのサブエージェントであること、サブエージェントの出力上限、.copilot-tracking/ をソース・オブ・トゥルースとする運用が最終版でも維持されていることを確認しましょう。2026年5月5日のレビューでは、Context Disciplineの導入、サブエージェント応答形式の制限、追跡ファイル重視の設計意図が確認されています。(GitHub)
コメント