スキルアップカレッジ エージェント型・自律型の使い分け——Coding Agent・Copilot Workspace・Claude Code
レッスン4：エージェント型・自律型の使い分け——Coding Agent・Copilot Workspace・Claude Code
このレッスンで学ぶこと
- 同期型（対話型）と非同期型（自律型）の境界を理解する
- Copilot Coding Agent の Issue → 自動 PR の流れと、GitHub Actions との連携を押さえる
- Copilot Workspace の仕様→計画→実装→PR の 4 段階 UI の狙いを理解する
- Claude Code の Subagent・Skills・Hooks 拡張機構の役割を把握する
- Devin の自律型エージェントとしての境界と、2026 年時点の実務での位置づけを見極められる
- 非同期委譲の運用設計（どのタスクを任せ、どのタスクを人間が持つか）を組み立てられる
前回のレッスン 3 では、コード生成タスクのプロンプト設計と、Vibe Coding／Spec-driven の対比を扱いました。今回は「非同期委譲」の主戦場である、エージェント型と自律型のツール群に踏み込みます。同期型と非同期型の境界、代表ツールの使い分け、非同期委譲の運用設計を扱います。中核メッセージの「Human-in-the-Loop の設計こそエンジニアの新しい仕事」が、ここで具体的な形になります。
同期型と非同期型の境界
エージェント型・自律型のツールは、大きく「同期型」と「非同期型」に分類されます。
sequenceDiagram
participant H as 人間
participant S as 同期型 AI<br/>Cursor Composer<br/>Claude Code
participant A as 非同期型 AI<br/>Coding Agent<br/>Devin
Note over H,S: 同期型：ターン制で会話
H->>S: 指示 1
S->>H: 結果 1
H->>S: 指示 2
S->>H: 結果 2
Note over H,A: 非同期型：投げて待つ
H->>A: Issue / 仕様
Note over A: バックグラウンドで実装<br/>数分〜数十分
A->>H: Pull Request
H->>A: レビュー結果同期型——ターン制の会話
同期型は、人間が指示を出し、AI が応答し、人間が次の指示を出す——というターン制の会話で進めるスタイルです。Cursor Composer、Windsurf Cascade、Claude Code、Aider、Continue、Cline などが該当します。人間は「その場で」応答を確認し、方向修正できます。反応時間は数秒〜1 分程度で、対話のリズムを保てます。
非同期型——投げて待つ
非同期型は、人間が Issue や仕様書として指示を渡し、AI がバックグラウンドで実装を進める——というスタイルです。GitHub Copilot Coding Agent、Devin、Copilot Workspace の一部モードなどが該当します。応答時間は数分〜数十分で、その間に人間は別の作業を進められます。
使い分けの判断軸
どちらを選ぶかは、次の 3 つで判断できます。
- タスクの明確さ：指示が明確で分解できるなら非同期型、対話しながら決めたいなら同期型
- 並行度：複数タスクを同時に走らせたいなら非同期型、集中して 1 つを深めたいなら同期型
- 失敗コスト：失敗しても軌道修正が容易なら非同期型、判断ミスが大きなロスにつながるなら同期型
💡 ポイント 「非同期委譲は生産性を上げる魔法」ではありません。指示が曖昧なタスクを非同期に投げると、40 分後に「期待と違うもの」が返ってきて、手戻りが大きくなります。明確に切り出せるタスクだけを非同期化する——この見極めが運用設計の鍵です。
Copilot Coding Agent——Issue から Pull Request まで自動化
GitHub Copilot Coding Agent は、GitHub が 2025 年に一般提供を発表した自律型エージェントです。GitHub の Issue に対してエージェントを起動すると、専用の実行環境でリポジトリをチェックアウトし、実装を進め、Pull Request として返してきます。
動作の流れ
- Issue にラベルを付けるか、コメントで
@copilotを呼ぶことでエージェントを起動する - エージェントが専用の実行環境（GitHub Actions 上のランナー）でリポジトリをチェックアウトする
- Issue の内容と関連コードを読み、実装計画を立てる
- コードを編集し、テストを走らせる
- Pull Request を作成し、人間のレビュー待ち状態にする
GitHub Actions との連携
Coding Agent は GitHub Actions 上で走るため、既存の CI/CD パイプラインと組み合わせやすい点が特徴です。PR が作成された後は、既存の CI（テスト・Lint・型チェックなど）が自動で走り、失敗したら人間が修正指示を出せます。
向くタスク・向かないタスク
向くタスク：
- 明確なバグ修正（再現手順とスタックトレースがあるもの）
- 定型的なリファクタリング（命名変更・ディレクトリ移動）
- テストの追加・更新
- ドキュメントの更新
向かないタスク：
- 設計判断を伴う新機能開発
- 複雑な業務ロジックの実装
- 複数モジュールにまたがる横断的な変更（判断ポイントが多い）
📝 補足 Coding Agent は「AI が 100 パーセント自律で完結する」ものではなく、「AI が実装を進めて PR を作り、人間がレビューでゲートを持つ」設計です。Human-in-the-Loop の設計こそエンジニアの新しい仕事という中核メッセージが、ここでも生きます。
Copilot Workspace——4 段階 UI で Human-in-the-Loop を担保
GitHub が 2024 年にテクニカルプレビュー公開した Copilot Workspace は、仕様→計画→実装→PR の 4 段階を持つ UI が特徴です。
flowchart LR
S1[仕様<br/>Specification] --> S2[計画<br/>Plan]
S2 --> S3[実装<br/>Implementation]
S3 --> S4[PR<br/>Pull Request]
H1[人間の介入] -.-> S1
H2[人間の介入] -.-> S2
H3[人間の介入] -.-> S3
H4[人間の介入] -.-> S44 段階の役割
- 仕様（Specification）：AI が Issue の内容を読み、実装すべき仕様を明文化する。人間は仕様の妥当性を確認・修正する
- 計画（Plan）：AI が実装計画を立てる。ファイル単位で「何を変えるか」がリスト化される。人間は計画を確認・修正する
- 実装（Implementation）：AI が計画に沿ってコードを編集する。人間は差分をレビューし、修正指示を出せる
- PR（Pull Request）：完成したコードを Pull Request として GitHub に登録する
各段階で人間が介入できる設計により、AI が誤った方向に走ることを防げます。Coding Agent より人間のガイダンスが強く効くのが Copilot Workspace の位置づけです。
Claude Code——CLI ベースの拡張性
Claude Code は、Anthropic が提供する CLI ベースの対話型エージェントです。ターミナルで claude コマンドを起動すると、Claude Opus 系のモデルとリポジトリ内で対話しながら開発を進められます。
拡張機構——Subagent・Skills・Hooks
Claude Code の特徴は、単純な CLI エージェントを超えたカスタマイズ機構を持つことです。
- Subagent（サブエージェント）：特定タスクに特化した別インスタンスを呼び出す仕組み。例えば「テスト実装専用のサブエージェント」「セキュリティレビュー専用のサブエージェント」を作れる
- Skills（スキル）：特定手順を再利用可能な形でパッケージ化する仕組み。「新規 API エンドポイントを追加する手順」「新規テストを追加する手順」などを再利用できる
- Hooks（フック）：エージェントのライフサイクルの節目で任意のスクリプトを実行する仕組み。例えば「編集前に自動フォーマットを走らせる」「PR 作成前に社内テンプレートを差し込む」といった連携ができる
CLI ゆえの汎用性
Claude Code は CLI ベースなので、VS Code・Vim・Emacs のいずれのエディタと組み合わせても使えます。リモート SSH 越しの開発、コンテナ内での開発、CI 環境での自動実行など、幅広い環境で動作します。エディタ内蔵型と併用して、「エディタでは Copilot タブ補完、複雑なタスクは Claude Code」という使い分けもよく行われます。
Devin——「AI エンジニア」の現実
Cognition AI が 2024 年 3 月に発表した Devin は、「AI ソフトウェアエンジニア」を掲げる自律型エージェントです。Web 検索・ブラウザ操作・シェル実行・コード編集を統合した環境で動作します。
期待値と現実のギャップ
Devin は発表時、「1 人の AI エンジニア」というインパクトのある PR で話題を集めました。実際の運用では、期待値の管理が重要です。単純なタスク（データ収集、簡単なコード生成、調査の切り出し）では威力を発揮しますが、複雑な業務ロジックの実装や、複数モジュールにまたがる設計判断が必要な場面では、人間の伴走が必要です。
向く場面
- リサーチタスク（技術調査・競合調査）
- データ収集・整形・前処理
- 定型的なプロトタイプ作成
- 単体で完結する小さな新機能
向かない場面
- 大規模リファクタリング（判断ポイントが多い）
- セキュリティクリティカルなコード
- 複数チームにまたがる調整が必要な変更
⚠️ 注意 ベンダーの PR 動画は「うまくいった例」だけを見せます。実際の運用では失敗ケースも観察し、「向く／向かない」の見立てを組織内で共有する姿勢が大切です。
講師の現場メモ——非同期委譲を初めて任せた案件
私が独立してから支援したある中堅 SaaS 企業で、Copilot Coding Agent の導入を主導した経験があります。最初の 1 か月は、エンジニアたちが「Agent に任せられる Issue」を見極めるのに苦労しました。ある日、あるチームリーダーがこう言いました。「今まで自分が『10 分で片付くから後で』と後回しにしてきたタスクが、実は Agent に投げるのに一番向いている」。
以降、そのチームでは「10 分で片付くが、自分で書くにはもったいない」Issue を積極的に Agent に流すようになりました。3 か月後、そのチームの Lead Time（コード完成からデプロイまでの時間）は 30 パーセント短縮しました。ただ、興味深いことに「1 人あたりの Issue クローズ数」は変わっていませんでした。「後回しになっていた小タスクが片付いた」効果として現れたのです。
この経験から学んだのは、非同期委譲は「大きなタスクを丸投げする道具」ではなく「後回しになる小タスクを消化する道具」として最初に機能する、ということです。組織導入の設計では、この「小タスク消化」の勝ちパターンを最初に見つけることが、定着への近道になります。
非同期委譲の運用設計
非同期委譲を組織で使うときの運用設計は、次の 4 点に集約されます。
1. 明確に切り出せるタスクだけを非同期化する
Issue に「再現手順」「期待する挙動」「成功判定条件」が書けるタスクだけを Agent に流します。曖昧な Issue は人間が同期型で対話しながら詰めるほうが効率的です。
2. レビューコストを見積もる
Agent が作った PR のレビュー時間は、人間が書いた PR のレビュー時間と大きくは変わりません。「Agent に任せれば時間が浮く」という期待は、レビューコストを見落としがちです。定量的には「実装時間の 30〜50 パーセント」がレビュー時間の目安です。
3. 失敗パターンを組織で共有する
Agent が失敗したパターン（規約違反・過剰リファクタ・テスト無視）は、AGENTS.md や CLAUDE.md にフィードバックとして書き足します。組織全体で「Agent が同じ失敗を繰り返さない」体制を作るのが、定着の鍵です。
4. コストとレイテンシを可視化する
非同期型は「見えないコスト」が積み上がりやすい仕組みです。月次の実行回数・トークン消費量・失敗率をダッシュボード化し、費用対効果を追える体制を作ります。詳しくはレッスン 8 で扱います。
まとめ
このレッスンでは、以下のことを学びました。
- 同期型（ターン制の会話）と非同期型（投げて待つ）の境界、選択の判断軸
- Copilot Coding Agent の Issue → PR 自動化と、向くタスク・向かないタスク
- Copilot Workspace の 4 段階 UI で Human-in-the-Loop を担保する設計
- Claude Code の Subagent・Skills・Hooks による拡張性
- Devin の「AI エンジニア」の期待値管理と、向く場面・向かない場面
- 非同期委譲の運用設計 4 点（明確に切り出す・レビューコスト見積・失敗共有・コスト可視化）
- 「後回しになる小タスク消化」が非同期委譲の最初の勝ちパターンになること
次のレッスンでは、AGENTS.md・CLAUDE.md・.cursorrules・.windsurfrules といったルールファイルの運用に踏み込みます。「AGENTS.md／CLAUDE.md はコードの一部である」という中核メッセージを具体化していきます。
確認クイズ
このレッスンの理解度をチェックしましょう。