GitHubは「Issue → Agent → PR」の先へ進むのか――今後1〜2年でAgent Control Planeが本格化する可能性

2026年現在、GitHub上でAI Coding Agentを使う開発は急速に現実的なものになっている。

現時点で、次の流れはすでに実用段階にある。

Issue
  ↓
Agent
  ↓
sandbox
  ↓
code
  ↓
test
  ↓
PR
  ↓
review

IssueをCopilotや外部Agentへ割り当てると、Agentが独立した環境でコードを書き、テストし、Pull Requestを作る。

一見すると、これでAIによるソフトウェア開発基盤は完成に近づいているようにも見える。

しかし、ある程度複雑なソフトウェアをAgent中心で開発していると、別の問題が目立ち始める。

それは「コードを書く能力」ではなく、**「コードを書く前に必要な意思決定をどう管理するか」**という問題だ。

この記事では、2026年時点のGitHubの動きをもとに、今後1〜2年、つまり2027〜2028年頃にGitHubがどの方向へ進むのかを考えてみたい。

注記
本文中の2026年の機能に関する記述は、それぞれGitHub公式ブログを出典としている（各節末にリンクを記載）。「今後1〜2年で起こりそうなこと」以降は、GitHubが公表しているロードマップではなく、筆者の予測である。

Coding Agentの性能向上だけでは解決しない問題

Coding Agentの性能はここ数年で急激に向上した。

単純なバグ修正やテスト追加だけでなく、

• API実装
• リファクタリング
• ライブラリ更新
• migration
• CI修正
• 複数ファイルにまたがる機能追加

なども、かなり任せられるようになっている。

ところが、Agentが強くなるほど別の問題が浮き上がる。

たとえば、次のようなIssueがあるとする。

OAuth Tokenの保存方式を変更する

このIssueには、実際には多数の判断が含まれている。

• 暗号化方式はどうするか
• 既存データをどうmigrationするか
• backward compatibilityをどうするか
• token rotationをどう扱うか
• schemaをどう変更するか
• 失敗したmigrationからどう復旧するか

IssueをそのままCoding Agentへ渡すと、Agentはコードを書くだけでは済まない。

実質的には、

要件解釈 + 技術判断 + 設計 + 実装 + テスト設計 + 検証

をまとめて行うことになる。

Agentの性能が低かった時代には、「もっと賢いモデルを使えば改善する」という説明で済んだ。

しかしAgent自体が十分強くなると、改善幅は徐々に小さくなる。

ボトルネックが「コードを書く能力」から「コードを書く前の意思決定を固定する能力」へ移るからだ。

GitHubもすでにこの問題へ向かい始めている

2026年のGitHubの新機能を見ると、GitHub自身も「Agentにコードを書かせる」だけでなく、その前後の制御へ急速に進み始めている。

Agent Control Planeの登場

2026年2月、GitHub Enterprise向けに「agent control plane」が一般提供（GA）になった。

現在の中心はAgent利用状況、監査ログ、ポリシー、MCPガバナンスなど企業レベルの統制だが、GitHub自身がすでに「Agentを管理するControl Plane」という概念を明確に使い始めている。

Agent SessionのIssues / Projectsへの統合

3月には、Coding AgentのsessionがIssuesやProjectsに直接表示され、

queued → working → waiting for review → completed

といった実行状態をプロジェクト管理画面から追跡できるようになった。

Implementation Planによる事前承認

4月には、Copilot cloud agentにImplementation Plan機能が入り、コードを書く前の承認（Approval Gate）が導入された。

要求
  ↓
Agentが調査
  ↓
Implementation Plan
  ↓
人間が確認
  ↓
承認
  ↓
実装開始

これは重要な変化だ。従来の「Issue → Agent → Code」が、

Issue
  ↓
Implementation Plan
  ↓
Human Approval
  ↓
Agent
  ↓
Code

へ変わり始めているからだ。

出典：

• Enterprise AI Controls & agent control plane now generally available（2026-02-26）
• Agent activity in GitHub Issues and Projects（2026-03-26）
• Research, plan, and code with Copilot cloud agent（2026-04-01）

Issueも「文章」から「構造化されたWork Item」へ変わっている

2026年7月には、Issue Fieldsが一般提供（GA）になった。

GitHub Issuesに、PriorityやEffortだけでなく、組織共通の型付きメタデータ（typed metadata）を持たせられるようになった。APIやwebhookからも操作できる。

さらにGitHub CLIから、

• Issue Type
• Parent / Sub-Issue
• blocked-by
• blocking

を扱えるようになっている。

これはCoding Agent時代にはかなり重要だ。Issueを単なる文章としてではなく、

Feature
├─ Decision
├─ Decision
├─ Architecture
├─ Implementation
└─ Verification

のような構造としてAgentが読み取れるようになるからだ。

たとえば、

#120 OAuth Token保存方式変更
├─ #121 暗号化方式を決定
├─ #122 migration方式を決定
├─ #123 backward compatibilityを決定
└─ #124 実装

という構造を作り、#121〜#123が完了するまで#124を「Ready for Agent」にはできない、という運用が考えられる。

このような開発方法が、GitHub上でもかなり作りやすくなってきた。

出典：

• Issue fields are now generally available（2026-07-02）
• Manage sub-issues, types, and dependencies from GitHub CLI（2026-06-10、gh v2.94.0〜）

Agent自身による状態変更にもApprovalが入り始めた

同じく2026年7月、GitHub IssuesにAgent Automation Controlsがパブリックプレビューとして追加された。

Agentが label、field、type、assignee、close などを変更する際に、次のフローを取れる。

Agent Proposal
  ↓
Rationale（根拠）
  ↓
Confidence（確信度）
  ↓
Human Approval
  ↓
Apply

GitHub自身は、このApprovalについて「現時点ではsecurity boundaryではなくworkflow convenienceである」と明記している。

逆に言えば、GitHubが「Agentが提案した状態変更」と「本当に状態を変更してよいこと」は別である、という考え方をUIとworkflowに入れ始めた、ということでもある。

出典：

• Agent automation controls in GitHub Issues in public preview（2026-07-23）

Agentic WorkflowsはよりControl Planeに近い

2026年6月には、GitHub Agentic Workflowsがパブリックプレビューとして登場した。

AgentはGitHub Actions内で動作し、基本的にはread-only権限で処理を行う。変更を行う場合は、次の構造を取る。

Agent
  ↓
Safe Output
  ↓
Validation
  ↓
Threat Detection
  ↓
Write

従来のAgentは「Agent → GitHub API → 変更」だった。Agentic Workflowsでは、

Agent
  ↓
Proposal
  ↓
Policy / Validation
  ↓
GitHub

へ変わっている。これはまさにControl Plane的な構造である。

出典：

• GitHub Agentic Workflows is now in public preview（2026-06-11）

権限についてもAgent単位のGateが入り始めた

2026年9月には、Copilot Business / Enterpriseの管理者が、Copilot app・Copilot CLI・VS CodeにおけるAgentの操作について、

• block
• human approval required
• allow without prompt

を強制できるようになった。

対象には、shell command、file read、file edit、network domain などが含まれる。しかも、この制限はユーザー設定やworkspace設定、auto-approveでは弱められない。

つまりGitHubは、**「Agentが何をしたいか」と「Agentに何をさせてよいか」**を別レイヤーとして扱い始めている。

この考え方は、今後のAgent Control Planeの土台になるはずだ。

出典：

• Enterprise managed permissions for GitHub Copilot agent operations（2026-09-09）

今後1〜2年で起こりそうなこと

ここから先は、GitHubが発表しているロードマップではなく、現在の機能進化から考えた筆者の予測である。

私は、2027〜2028年頃までにGitHub上のAgent開発は次の方向へ進むと見ている。

1. IssueにDevelopment State Machineが入る

現在でもProject StatusやIssue Fieldsを使えば、

Draft
Decision Required
Plan Review
Ready for Agent
Agent Running
Verification
Ready for Merge

という状態を表現できる。

しかし現状では、これらは基本的に「値」である。

将来的には、

Draft
  ↓
Requirement Ready
  ↓
Plan Approved
  ↓
Ready for Agent
  ↓
Agent Running
  ↓
Verification
  ↓
Ready for Merge

という状態遷移そのものが、GitHub上の第一級（first-class）の概念になると考えている。

特に重要なのはtransition guard（遷移条件）だ。

たとえば「Plan Approved → Ready for Agent」へ進む条件として、

Decision Issue       = Closed
Dependencies         = Resolved
Implementation Plan  = Approved
Required Review      = Completed

などを設定する。条件を満たしていなければ、人間でもAgentでも状態を進められない。

これは、現在のGitHubでまだ弱い領域だ。

2. 「Ready for Agent」が明確な実行境界になる

現在は、IssueをAgentにassignすれば実行できる。

将来的には、

Issue
  ↓
Eligibility Check
  ↓
Ready for Agent
  ↓
Agent Session

という形になるのが自然だろう。

たとえば、

requirements fixed
dependencies resolved
plan approved
security policy passed
repository allowed
budget available   （Agent実行に割り当てられたコスト・時間の上限内か）

などが揃って初めてAgentを起動する。

Coding Agentへ仕事を渡すこと自体が、workflow上の正式な状態遷移になる。

3. Implementation Planが「参考資料」から「実行Contract」へ変わる

現在のImplementation Planは、人間がAgentの方針を確認するための機能である。

しかしAgent開発が大規模化すると、「Issue → Plan → Approval → Implementation」だけでは足りなくなる。

おそらく、

Requirement Revision
Plan Revision
Approved By
Approved At
Source Revision

のような情報が紐づき、「どのPlanを承認してAgentを動かしたのか」が追跡可能になる。

さらに、Plan v3を承認した後にIssueやPlanが変更された場合、

Approval Stale

として再承認が必要になる仕組みも、自然な進化だと思う。

4. Agentの実行Identityが強くなる

現在もGitHubはAgent Sessionを追跡している。

しかし今後は、

Issue
Requirement Revision
Plan Revision
Repository
Source Commit
Agent
Model
Execution Policy
Session

が一つのexecution identityとして扱われるようになるだろう。

すると、「このPRは何を根拠として作られたのか」を後から正確に説明できる。

これは企業利用では欠かせない要素になる。

5. 「Agentがテストした」と「独立検証」が分離される

今後かなり重要になると思うのが、この部分だ。

現在の典型的なCoding Agentは、

Agent
  ↓
Code
  ↓
Test
  ↓
PR

まで自分で行う。

しかし、

Agent自身が書いたコードを、Agent自身が選んだテストで、Agent自身が確認する

という構造には限界がある。

今後は、

Implementation Agent
  ↓
Artifact
  ↓
Independent Verification
  ↓
Review

という分離が強くなると見ている。

このIndependent Verificationを担う主体をここではVerifierと呼ぶ。VerifierはImplementation Agentのworkspaceを信用せず、

Clean Checkout
Exact Source Revision
Change Artifact

から環境を再構築して検証する。

AI開発が企業システムへ広がるほど、この分離は重要になる。

6. Agentは交換可能なWorkerになる

GitHubはすでにAgent Appsを提供し、Copilot、Claude、Codex、外部Agentを GitHub workflowへ統合する方向へ進んでいる。

2026年6月にはMarketplaceからパートナー製のAgent Appsをインストールできる仕組みが登場し、今後は誰でも（社内ツールとしても）Agent Appsを構築できるようにする方針が示されている。

そのため将来的には、

GitHub Control Plane
        │
        ├─ Copilot
        ├─ Codex
        ├─ Claude
        └─ Internal Agent

という構造になっていくだろう。

重要なのは、**「Agentがworkflowを所有するのではなく、workflowがAgentを選択する」**という逆転だ。

AgentはControl Planeから見れば、交換可能なWorkerになる。

出典：

• Extend GitHub with agent apps（2026-06-02）

7. PRは「成果物」ではなく「Agent Executionの結果」になる

現在のGitHubでは、PRが開発workflowの中心にある。

しかしAgent中心になると、PRの意味も少し変わる。

現在はIssueからAgentが直接PRを作るが、将来は、

Issue
  ↓
Requirement / Decision
  ↓
Implementation Plan
  ↓
Human Approval
  ↓
Execution
  ↓
Independent Verification
  ↓
PR

になる。

つまりPRは開発プロセスそのものではなく、承認されたExecutionの結果として生成された成果物になる。

最終的には「GitHub Development Control Plane」へ向かうのではないか

以上をまとめると、今後のGitHubは次のような構造へ進むと考えている。

GitHub Issue
     │
     ▼
Requirement / Decision
     │
     ▼
Implementation Plan
     │
     ▼
Human Approval
     │
     ▼
Transition Guard
     │
     ▼
Ready for Agent
     │
     ▼
Execution Policy
     │
     ▼
┌───────────────┐
│ Agent Router  │
├───────────────┤
│ Copilot       │
│ Codex         │
│ Claude        │
│ Custom Agent  │
└───────┬───────┘
        │
        ▼
Isolated Execution
        │
        ▼
Change Artifact
        │
        ▼
Independent Verification
        │
        ▼
PR
        │
        ▼
Human / Policy Gate
        │
        ▼
Merge / Release

ここまで来ると、GitHubは単なるSource Code HostingでもIssue Trackerでもない。

AI Agentを含めたソフトウェア開発全体のControl Planeになる。

「Agentを賢くする」フェーズの次が来ている

Coding Agentの進化を見ていると、どうしてもモデル性能に目が向きやすい。

しかし実際の開発では、Agentが十分強くなった後に、別の問題が出てくる。

• 何を実装するのか
• 誰がその判断を承認したのか
• いつ要件が確定したのか
• どのsource revisionへ実装したのか
• そのAgentに実行権限があったのか
• 結果を誰が検証したのか

つまり次の競争は、「どのAgentが一番コードを書けるか」だけではなく、**「Agentへ仕事をどのように安全かつ確実に渡すか」**へ移っていく。

2026年のGitHubには、Agent Control Plane、Agent Session、Implementation Plan、Issue Fields、Sub-Issues / Dependencies、Agent Automation Controls、Agentic Workflows、Agent Appsといった機能が短期間に一気に追加された。

これらはまだ完全には一つにつながっていない。しかし、今後1〜2年でこれらが統合されれば、「Issue → Agent → PR」という単純なCoding Agentモデルは、Requirement・Decision・Approval・Gate・Independent Verificationを備えた、本格的なAgent Development Platformへ変化していくだろう。

AI Coding Agentが本当に大規模なソフトウェア開発を担うようになるなら、この「Gateの層」は避けて通れない。

Coding Agentの次に必要になるものは、さらに賢いCoding Agentだけではない。Coding Agentを組織的に制御する仕組みそのものなのかもしれない。