計画、推論、実行を分離する
このユニットでは、次の内容について説明します。
計画、実行、検証を分離することで信頼性が向上する理由
プラン優先ワークフローとプラン + 実行ワークフローの違いを理解する
機能制限とツール ゲーティングを使用して計画境界を適用する方法
分離によって信頼性が向上する理由
信頼性の高いエージェントシステムでは、以下が分離されます。
計画: 何が行われるか、その理由。
実行: リポジトリに対して行われた具体的な変更。
検証: 結果が成功基準を満たしていることを示す証拠。
計画と実行が混在している場合、レビュー担当者には最終的な相違のみが表示されます。 意図を早期に検証し、誤解をすばやく検出し、影響を受ける前にスコープを制御する機能が失われます。
分離を GitHub に対応させる方法
GitHubは当然、この分離をサポートします。
計画は、PR の説明、問題のコメント、または Github/pull_request_template.md 成果物に表示されます。
実行はブランチのコミットとして表示されます。
検証は、チェック、スキャン、成果物、およびレビュー結果として表示されます。
プラン優先ワークフローとプラン + 実行ワークフローの違いを理解する
エージェントを操作する場合、チームはプランがいつ表示され、いつコードの変更を開始するかを決定する必要があります。 GitHubでは、計画と実行は、GitHubの問題 (Copilot クラウド エージェントの割り当てなど) や、プランが対話形式で生成される [エージェント] タブなど、さまざまなエントリ ポイントから開始できます。
これらはエージェントとやり取りする個別の方法ですが、同じガバナンス モデルに収束します。すべての作業が最終的に表示され、プル要求 (PR) で確認されます
そのため、重要な設計の選択は、プランが開始される場所ではなく、コードの変更に対して人間による検証が必要な場合です。
選択肢A: 計画優先プルリクエスト
このアプローチでは、コード変更が導入される前に計画が完了し、承認されます。
実際の動作:
プランが生成されます (たとえば、エージェントをGitHubの問題に割り当てたり、[エージェント] タブで作成したりします)。
エージェントは、プランのみを含むプル要求を開きます (コードはまだ変更されていません)。
校閲者は、PR で直接プランについて話し合い、調整し、承認します。
承認後、エージェントはフォローアップ コミットまたは新しい PR でプランの実装に進みます。
これにより、意図 (プラン) と実行 (コード) が明確に分離されます。
オプション B: 同じプル要求での計画と実行
このアプローチでは、計画と実行が 1 つの PR 内で結合されます。
実際の動作:
エージェントは、次の両方を含む PR を開きます。
構造化されたプラン (説明内)
初期コード変更 (コミット)
プランの進化に応じて、エージェントは PR の更新を続行できます。
標準のGitHubコントロールに必要なチェック、CODEOWNERS のレビュー、ブランチ保護により、すべての要件が満たされるまでマージを防止します。
ここでは、プランは引き続き表示されますが、アクティブな変更内容の前に表示されるのではなく、それらの変更内容と併せて提示されます。
主な違い: 検証のタイミング
どちらのオプションも、同じGitHub コントロールを使用します。 違いは、これらのコントロールが実行に対して適用される場合です。
オプション A (プラン優先): 人間による検証は、コードが記述される 前に 行われます。
オプション B (プラン + 実行): コードはすぐに生成されますが、 マージの前に検証が必要です。
リスクに関する考慮事項
どちらの方法も、GitHub保護が正しく構成されている場合に安全です。 違いは、システムにリスクが導入されたときにあります。
オプション A は、早期露出を減らします。 承認前にコードは生成されないので、レビュー担当者は最初に意図を検証します。 これにより、不要な変更や安全でない変更が最小限に抑えられます。リスクの高い環境 (運用システムやセキュリティに影響を受けやすい領域など) で推奨されます。
オプション B では、変更への早期露出が含まれています。 プランが完全に検証される前に、PR にコードが表示されます。 このコードは承認なしでマージすることはできませんが、次の場合があります。
レビューと拒否が必要な不要な変更または不適切な変更が導入される
レビュー担当者の作業量を増やす
計画と実装の間に一時的なミスアラインメントを作成する
重要なのは、このリスクは、マージ後ではなく、提案段階に存在することです。 GitHubの強制メカニズムにより、安全でないコードがデプロイされるのを防ぐことができます。
各オプションを使用する場合
プランを優先するワークフローは以下の場合に使用します。
変更はリスクが高いか、元に戻すのが困難です
意図に対する配置は、実行前に重要です
計画と実装を厳密に分離する必要がある
プランと実行のワークフローは、次の場合に使用します。
速度と反復がより重要である
変更がリスクが低い、または簡単に元に戻せる
レビュー担当者は、計画とコードを一緒に評価することに慣れている
重要なポイント
選択は、作業がレビューされるかどうかではなく、常に行われるかどうかです。 選択するのは、システムで人間による検証に関連してコードを生成できる場合と、ワークフローに変更を導入する早い時期です。
機能制限とツール ゲーティングを使用して計画境界を適用する
- 機能の境界 (計画エージェントは読み取り専用) 計画エージェントは、計画中にファイルを変更できないように、読み取り専用ツールに制限する必要があります。
- 実装エージェントへの明示的な移行 (またはハンドオフ)。 実行は、計画の承認後にのみ、意図的な移行を通じて行うべきです。
- 自動オーケストレーションのオーケストレーターのツール ゲーティングでは、計画を強制的にツールを実行せずに実行し、プランが受け入れられた後にのみツールを有効にすることができます。
- "プラン モード" ワークフロー - 一部のインターフェイスでは、計画成果物を生成し、変更が適用される前に一時停止する計画優先エクスペリエンスがサポートされています。
意思決定ガイダンス
リスクの高い作業 (ワークフロー、インフラストラクチャ、認証、運用) には、plan-first を使用します。
中/低リスクの作業にはプラン + 実行を使用しますが、チェック/レビューは必須のままにします。
「編集しないでください」という指示はガイダンスとして扱い、ツールの許可リストとゲートは強制手段として扱います。
重要なポイント: 分離により、影響を受け入れる前に意図を確認する機会が生まれます。
次に、プル要求承認ゲートを使用して、プランの可視性と検証を適用します。