概要
Agentic Workflowは、実装をAIエージェントに委任する開発モデルです。人間がゴールを示して結果を判断し、エージェントが計画・実装・検証を自走します。 人間がエージェントと対話しながら進めるVibe Codingとは異なり、働き方が「協働」から「委任」へ移り、人間はコードを書く役割から作業を指揮する役割へ移ります。 Vibe Codingでは人間とAIが1:1で向き合い、人間が作業者、AIがそれを支援する役割でした。Agentic Workflowではこの関係が逆転します。AIが実作業を行い、人間は方向性と判断を決めるオーケストレーターになります。 1体のAIと対話しながら進めるのではなく、多くの作業を複数のエージェントへ同時に委任する、人間とAIが1:Nの働き方です。
このページでは、委任を成立させる要素を扱います。エージェントの自律性、リポジトリ側に必要な土台、コンテキスト管理を軸にした役割分担と並列実装のテクニック、そしてAIと人間の責任分担です。
エージェントの自律性を支える4要素
委任が成り立つのは、エージェントが逐次の指示なしに作業を前へ進められるからです。それを可能にするのが次の4つの能力です。ゴール指向
人間は「何を」達成するかを与え、「どう実現するか」の具体的な計画とコードはエージェントが組み立てます。
計画と分解
大きなタスクをサブタスクに分割し、順序立てて実行します。
ツール使用
ファイル・コマンド・Skillを操作し、必要に応じてMCP経由で外部システムにもアクセスします。
自己検証ループ
テストを実行し、失敗を読み、修正して再実行する。変更が通るまでこの繰り返しを自律的に続けます。
前提条件
ガードレール
エージェントはリポジトリが与えるシグナルに従って動きます。したがって、実装を委任する前に、そのシグナルを機械が読める形で用意しておく必要があります。重要なガードレールは次の4種類です。ドキュメントとルール
アーキテクチャ・コーディング規約・命名規則・テスト方針を記したプロジェクトドキュメントと、エージェント向けの指示ファイル（README、rulesなど）。
一貫したコードパターン
エージェントが読んで模倣できる、統一された型定義と設計パターン。
テストコード
エージェントの自己検証ループ（実行→失敗→修正→再実行）が意味を持つだけのテストコード。
プルリクエストの粒度とレビュー文化
適切なプルリクエストの粒度とレビュー文化。
git worktree
git worktreeは、1つのリポジトリに対して複数の作業ディレクトリを作成するGitの機能です。 その場でのブランチ切り替え（git switch）では同時に扱えるブランチは1つだけで、別のタスクへ移るには作業途中の変更をstashするかコミットする必要があります。worktreeは、ブランチをディレクトリごと分離します。
/git-worktree feature/add-authのようなコマンド1つに集約できます。裏側では、worktreeの作成、セッションの作業ディレクトリの切り替え、設定ファイルのコピーが自動で行われます。
設計のポイントは「変わらない部分」と「変わる部分」の分離です。worktreeを作成するロジックはどのプロジェクトでも同じなので共通のSkillが担い、どの環境ファイルをコピーするか・依存パッケージをどうインストールするかというプロジェクト固有のセットアップは、各リポジトリに置いたスクリプトで上書きできるようにします。
worktreeの操作をSkillとして独立させておくと、実装エージェントは「worktreeの作り方」を知る必要がありません。Issueの取得、worktreeの作成、実装、プルリクエストの作成、クリーンアップという流れの部品としてSkillを呼び出すだけで済み、手順を変更するときもSkill側を直すだけで済みます。
Agentic Workflowを実現するテクニック
コンテキストを管理する
生成AIは、コンテキスト（作業中に保持している情報）が肥大化すると精度が落ちます。長く自走するエージェントほどこの影響を受けるため、委任がうまくいくかどうかは、コンテキストをどう設計するかで決まります。このセクションで扱うテクニックは、すべてこの1点から導かれます。 まず、1体のエージェントの中では、次の3つでコンテキストを軽く保ちます。- 重い探索はサブエージェントに切り出す。 コードベースの探索や調査など情報量の多い処理は別のエージェントに任せ、メインのエージェントには結果の要約だけを返します。
- 手順やガイドラインはSkillに切り出す。 常にコンテキストへ読み込ませるのではなく、必要になったときにSkillとして参照させます。
- メインのコンテキストには判断に必要な情報だけを残す。 途中経過や生データを持ち続けないことで、精度を保ったまま長いタスクを完走できます。
コンテキスト境界で役割を分担する
複数のエージェントを使う基本形は、オーケストレーターが戦略を立て、タスクを専門のエージェントへ委譲し、返ってきた結果を統合する構図です。このとき重要なのは、何を基準に役割を切るかです。 役割は作業の種類ではなく、コンテキストの境界で分けます。 「情報収集係・分析係・実装係」のように工程で分けると、工程間の受け渡しのたびにコンテキストの引き継ぎが発生し、調整コストが膨らみます。逆に、互いのコンテキストを必要としない作業の間に境界を引けば、受け渡しは要約だけで済みます。 ✕ 作業の種類で分ける — 受け渡しのたびにコンテキストを丸ごと引き継ぐことになります。 ○ コンテキスト境界で分ける — 受け渡しは要約と自己完結した指示だけになります。 この基準を当てはめると、分担の型は次のようになります。- 情報収集は切り出す。 探索が生む大量の生データは後工程には不要です。境界が最もきれいに切れる代表例であり、要約だけを返させます。
- 分析と判断はオーケストレーターに残す。 各エージェントの結果を突き合わせて次の一手を決める作業は、すべての結果が集まる場所でしか行えません。
- 同じコンテキストを必要とする作業はまとめる。 機能の実装とそのテストのように同じ理解を前提とする作業を別のエージェントへ分けると、同じコンテキストを二度構築することになります。
並列に実装する
コンテキスト境界による分担を実装作業へ適用した型がIssue × Worktreeです。適切に分解されたSub-issueは、それぞれが独立したコンテキストで完結する作業単位です。親Issueが依存関係でつないだSub-issueを持ち、git worktreeが各エージェントをディレクトリごと隔離することで、一方の変更が他方に触れない状態を保ちます。 タスクの粒度がエージェントの成否を左右します。タスクをどこまで小さくするか、独立性やrevert影響による分割の検証といった基準はタスク分解を、親IssueとSub-issueの構造化や依存関係の設定方法はタスクのIssue化を参照してください。 責務は2つのエージェントの役割にはっきり分かれています。分析と判断を担うオーケストレーターと、実装を担うWorkerです。- Team Lead（オーケストレーター）。 依存関係グラフを構築し、実行レイヤーを決め、タスクを作成・割り当てし、レイヤー間のマージゲートを回し、Workerを同期します。コードは書きません。
- Worker（実装担当）。 割り当てられたIssueについて、worktreeを作成し、環境を整え、実装し、セルフレビューし、プルリクエストを作成し、結果を報告し、最後にworktreeを片付けます。Workerとworktreeは1対1で対応します。
AIと人間の責任分担
このページのすべてのテクニックは、AIが生成したコードの責任は人間にあることを前提とします。AIに委任しても、この責任は移りません。変わるのは、人間が注意を注ぐ場所です。 分担の基準はシンプルです。機械的に検証できる領域はAIに任せ、判断が必要な領域は人間が担います。 規約やルールと突き合わせれば正誤が決まるチェックはAIが得意とする一方、正解が文脈に依存する判断は人間にしかできません。AIに任せる
ルールとの照合で正誤が決まる、機械的に検証できる領域。
- コーディング規約・命名・型定義への準拠
- テストコードの有無とカバレッジ
- バグ・セキュリティの走査（信頼度の高い指摘のみ報告）
人間が担う
正解が文脈に依存する、判断が必要な領域。
- 変更がビジネス要件を満たしているかの判断
- アーキテクチャ・設計の妥当性
- セキュリティリスクの受容とマージの最終判断
Agentic WorkflowはVibe Codingより多くを委任しますが、その土台づくりを引き継いでいます。対話的な協働がまだ機能していないなら、丸ごと実装を委任するより先に土台を整えてください。