12人のエージェントが同時に分析しても、なぜ課題は1つしか開かれないのか

src/ 以下の散在したディレクトリから廃止されたAPI呼び出しを探さなければならない状況を想像してみてください。12個のディレクトリに12個のAIエージェントを同時にアタッチすれば、12個の問題が発生しそうな印象を受けます。しかし、GitHubのエージェント型ワークフロー（gh-aw）では、エージェントをどれだけ多数動員しても、最終的に作成されるIssueは1つだけです。その鍵は複雑な競合解決技術にあるのではなく、エージェントにそもそもリポジトリを修正する権限（書き込み権限）を与えない設計にあります。

エージェントが保持しているGitHubトークンには、書き込み権限が一切ありません。「このコードをリポジトリにプッシュせよ」と指示しても、トークン段階で拒否されるため、物理的に保存が不可能です。エージェントに可能な唯一の出力は、「この内容をIssueとして作成してください」というリクエストデータを残すことです。本記事では、複数のエージェントが並列に分析する場合、なぜリポジトリの競合や重複作業が発生しないのか、その動作構造を解説します。

並列性は「読み取り」にあり、「書き込み」はゲートの後に存在する

GitHubは2026年6月11日にエージェント型ワークフローを公開プレビューへ移行しました。この機能は、コーディングエージェントをGitHub Actionsで実行し、Issueの分類や週次サマリーといった反復的な処理に対応するものです。このシステムの主要なセキュリティ設計の一つは、エージェントに読み取り専用トークンのみを提供し、シークレット値へのアクセスを遮断することです ¹。

すなわち、並列処理は「リポジトリの読み取りと分析」段階にのみ存在します。複数のエージェントが同時に異なるファイルを開いて内容を把握することはできますが、誰一人としてその結果を直接リポジトリへ書き込むことはできません。実際の保存処理は、別の書き込み権限を持つ別のジョブが担当します。この分離構造により、並列実行時に発生し得る競合や重複が根本から遮断されます。

Safe Outputs：提案はエージェントが、実行はシステムが

GitHub公式ドキュメントで「Safe Outputs」と呼ばれる仕組みが、分離された保存処理を担当します。エージェントは書き込み権限なしに構造化データ（リクエスト）のみを生成し、これを読み取った権限を持つ別のジョブが実際にAPI呼び出しを行います ²。エージェントが「こうしたタイトルでIssueを作成してほしい」と記録すると、issues: write の権限を持つ別のシステムがこれを処理するという形です ²。

ここで重複防止の鍵となるデフォルト値があります。特別な設定がない限り、create-issue 機能は自動的に有効になり、その上限（max）は「1」に固定されます ²。ラベルおよびタイトルプレフィックスもまた、ワークフローIDに紐付けられて管理されます ²。12個のエージェントが同時に「Issue作成」をリクエストしても、ゲートの役割を担うシステムはこれを検証し、一度だけ実行します。

各リクエストには一意のID（so_...）が割り当てられ、ジョブ間で順序が必要な場合はdepends-onを用いて先行ジョブのIDを参照し、待ち行列を作成します。先行ジョブが完了後に次が実行されることとなり、依存関係が循環した場合（fail-closed）には安全性を確保するため実行が停止します ²。PRマージもこの規則に従い、エージェントが直接マージ権限を持つのではなく、システムがポリシーを検証した後に承認済みのもののみを処理します ²³。

実際のコードに見る並列と逐次の境界

Start Debuggingが公開したapi-sweep のサンプルコードは、このフローをよく示しています。この例では、src/ 配下の各ディレクトリにエージェントを1つずつアタッチし、廃止されたAPI呼び出し（HttpClientFactory.Legacy）を検出します ³。

// .github/extensions/api-sweep/extension.mjs (Start Debugging 예제 기반)
const dirs = await ctx.step("dirs-v1", async () =>
  (await readdir("src", { withFileTypes: true }))
    .filter((d) => d.isDirectory())
    .map((d) => `src/${d.name}`),
);
// ctx.parallel(): 디렉터리 수만큼 에이전트를 동시 실행 (읽기/분석)
const results = await ctx.parallel(dirs.map((dir) => () =>
  ctx.agent(
    `List every call to ${api} under ${dir} and the replacement it needs. ` +
    `Return an empty list if there are none.`,
    { label: `sweep:${dir}`, schema: HITS },
  ),
));
// 결과를 합치는 단계는 순차적으로 진행됨
return { hits: results.filter(Boolean).flatMap((r) => r.hits) };

ctx.parallel() 関数を使用するセクションまでは並列実行です。各エージェントは検出した結果をJSON形式で返すのみです。返却されたデータが統合された後、最終段階でsafe-outputs 設定（max: 1）に従い、最終的に1つのIssueのみが作成されます ³。12個のエージェントが各自で発見した内容を持ち帰っても、最終ゲートで1つに収束します。

3つの運用方法と共通する安全境界

マルチエージェントの使用方法は大きく3種類に分類され、書き込み権限の有無が異なります ³。

1. /fleet（即時実行）：Copilot CLIセッションでユーザーがプロンプトを入力すると、サブエージェントが即座にタスクを分担します。人が見守りながら方向性を決める際に適しており、セッションに付与された権限で保存が可能になります ³。
2. 動的ワークフロー（スクリプト）：分割計画をJavaScriptコードであらかじめ定義します。反復実行や予算上限が必要な処理に用いられ、セッション権限およびコードに基づいて保存可否が決定されます ³。
3. gh-aw（無人自動化）：イベントやスケジュールにより、誰も見ていない時に実行されます。この環境では、エージェントジョブは必ず読み取り専用である必要があり、すべての書き込み操作はSafe Outputsゲートを通過しなければなりません ³。

CarvanaやMarks & Spencerといった企業が、gh-awを複雑なシステム変更や保守に使用しているのも、結局はこうした組み込み制御装置が生み出す信頼性によるものです ¹。Carvanaは、複数のリポジトリを同時に触れる変更までエージェントに委ねることができた理由を「柔軟性とデフォルトで提供される統制」に見出しており、Marks & SpencerはIssue分類および依存性保守で失われていた開発時間を、再利用可能なワークフローカタログとして回収しました。

まとめ

複数のAIエージェントが同じリポジトリを扱う際に競合しない理由は、彼らが賢明に競い合っているからではありません。gh-aw構造のエージェントは読み取り専用トークンを保有しているため、物理的にリポジトリへ書き込むことができないからです ³¹。その代わり、生成されたリクエストはmax の上限およびラベル規則を備えた別のゲートで検証され、複数の提案が入力されても最終的な反映は一度のみ行われます ²。並列性が安全に保たれているのは、複雑なマージ技術の恩恵ではなく、書き込み操作を初めから単一のゲート後方へ押し込んでいるためです。