> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # Agentic Workflow > AIエージェントが計画・実装・検証を自走し、人間がゴール設定と結果の判断を担う委任型の開発モデル。コンテキスト管理を軸に、コンテキスト境界での役割分担から並列実装までを解説します。 ## 概要 Agentic Workflowは、実装をAIエージェントに委任する開発モデルです。人間がゴールを示して結果を判断し、エージェントが計画・実装・検証を自走します。 人間がエージェントと対話しながら進める[Vibe Coding](/ja/ai/vibe-coding)とは異なり、働き方が「協働」から「委任」へ移り、人間はコードを書く役割から作業を指揮する役割へ移ります。 Vibe Codingでは人間とAIが1:1で向き合い、人間が作業者、AIがそれを支援する役割でした。Agentic Workflowではこの関係が逆転します。AIが実作業を行い、人間は方向性と判断を決めるオーケストレーターになります。 1体のAIと対話しながら進めるのではなく、多くの作業を複数のエージェントへ同時に委任する、人間とAIが1:Nの働き方です。 | | Vibe Coding | Agentic Workflow | | -------- | ----------- | --------------------- | | 人間とAIの関係 | 1:1 | 1:N | | 作業の主体 | 人間（AIが支援） | AI（エージェントが実作業） | | 人間の役割 | 作業者 | オーケストレーター（方向性と判断を決める） | このページでは、委任を成立させる要素を扱います。エージェントの自律性、リポジトリ側に必要な土台、コンテキスト管理を軸にした役割分担と並列実装のテクニック、そしてAIと人間の責任分担です。 ## エージェントの自律性を支える4要素 委任が成り立つのは、エージェントが逐次の指示なしに作業を前へ進められるからです。それを可能にするのが次の4つの能力です。 人間は「何を」達成するかを与え、「どう実現するか」の具体的な計画とコードはエージェントが組み立てます。 大きなタスクをサブタスクに分割し、順序立てて実行します。 ファイル・コマンド・Skillを操作し、必要に応じてMCP経由で外部システムにもアクセスします。 テストを実行し、失敗を読み、修正して再実行する。変更が通るまでこの繰り返しを自律的に続けます。 ## 前提条件 ### ガードレール エージェントはリポジトリが与えるシグナルに従って動きます。したがって、実装を委任する前に、そのシグナルを機械が読める形で用意しておく必要があります。重要なガードレールは次の4種類です。 アーキテクチャ・コーディング規約・命名規則・テスト方針を記したプロジェクトドキュメントと、エージェント向けの指示ファイル（README、rulesなど）。 エージェントが読んで模倣できる、統一された型定義と設計パターン。 エージェントの自己検証ループ（実行→失敗→修正→再実行）が意味を持つだけのテストコード。 適切なプルリクエストの粒度とレビュー文化。 弱い土台は補われるのではなく増幅されます。規約が不統一だったりテストが薄かったりすると、エージェントはその弱さを増幅します。委任の前に土台を整えてください。 ### git worktree git worktreeは、1つのリポジトリに対して複数の作業ディレクトリを作成するGitの機能です。 その場でのブランチ切り替え（`git switch`）では同時に扱えるブランチは1つだけで、別のタスクへ移るには作業途中の変更をstashするかコミットする必要があります。worktreeは、ブランチをディレクトリごと分離します。 ```text theme={null} # メインの作業ディレクトリ（feature/authブランチ） ~/project/MyApp/ # worktreeで作成した別の作業ディレクトリ（fix/login-bugブランチ） ~/project/MyApp/.claude/worktrees/fix-login-bug/ ``` 各ディレクトリが独立したブランチを持ちます。これが、並列エージェントが互いに干渉せずに作業できる鍵です。各エージェントが自分のディレクトリを持つため、一方の変更が他方に触れず、あるworktreeでのビルドやテストの実行が他のworktreeをブロックすることもありません。 手で運用すると、worktreeには作成からクリーンアップまで多くのコマンドが必要です。 ```bash theme={null} # 作成: worktreeを作って新しいブランチを切る git worktree add .claude/worktrees/fix-login-bug -b fix/login-bug cd .claude/worktrees/fix-login-bug # 環境セットアップ: gitが管理しないファイルのコピーと依存パッケージのインストール cp ../../../.env . cp ../../../localhost.pem . npm install # クリーンアップ: メインのディレクトリへ戻り、worktreeとブランチを片付ける cd ~/project/MyApp git worktree remove .claude/worktrees/fix-login-bug git branch -d fix/login-bug ``` この定型作業をタスクのたびに繰り返すのは負担であり、クリーンアップは忘れやすく、使い終わったworktreeが溜まり続けます。手順の多さそのものが、チームへworktreeを導入するときの障壁にもなります。 この手順を[Skill](/ja/ai/skill)に閉じ込めると、`/git-worktree feature/add-auth`のようなコマンド1つに集約できます。裏側では、worktreeの作成、セッションの作業ディレクトリの切り替え、設定ファイルのコピーが自動で行われます。 設計のポイントは「変わらない部分」と「変わる部分」の分離です。worktreeを作成するロジックはどのプロジェクトでも同じなので共通のSkillが担い、どの環境ファイルをコピーするか・依存パッケージをどうインストールするかというプロジェクト固有のセットアップは、各リポジトリに置いたスクリプトで上書きできるようにします。 worktreeの操作をSkillとして独立させておくと、実装エージェントは「worktreeの作り方」を知る必要がありません。Issueの取得、worktreeの作成、実装、プルリクエストの作成、クリーンアップという流れの部品としてSkillを呼び出すだけで済み、手順を変更するときもSkill側を直すだけで済みます。 ## Agentic Workflowを実現するテクニック ### コンテキストを管理する 生成AIは、コンテキスト（作業中に保持している情報）が肥大化すると精度が落ちます。長く自走するエージェントほどこの影響を受けるため、委任がうまくいくかどうかは、コンテキストをどう設計するかで決まります。このセクションで扱うテクニックは、すべてこの1点から導かれます。 まず、1体のエージェントの中では、次の3つでコンテキストを軽く保ちます。 * **重い探索はサブエージェントに切り出す。** コードベースの探索や調査など情報量の多い処理は別のエージェントに任せ、メインのエージェントには結果の要約だけを返します。 * **手順やガイドラインはSkillに切り出す。** 常にコンテキストへ読み込ませるのではなく、必要になったときに[Skill](/ja/ai/skill)として参照させます。 * **メインのコンテキストには判断に必要な情報だけを残す。** 途中経過や生データを持ち続けないことで、精度を保ったまま長いタスクを完走できます。 3つの共通点は、かさばる情報をメインのコンテキストの外に置き、必要な分だけを出し入れすることです。 ```mermaid theme={null} flowchart LR SUB[サブエージェント
大量の生データ] -->|要約だけ| MAIN[メインエージェント
判断に必要な情報だけ] SKILL[Skill
手順・ガイドライン] -.->|必要なときだけ| MAIN ``` この「切り出す」発想を、1体のエージェントの内側からエージェントのチーム全体へ広げたものが、次の役割分担と並列実装です。 ### コンテキスト境界で役割を分担する 複数のエージェントを使う基本形は、オーケストレーターが戦略を立て、タスクを専門のエージェントへ委譲し、返ってきた結果を統合する構図です。このとき重要なのは、何を基準に役割を切るかです。 **役割は作業の種類ではなく、コンテキストの境界で分けます。** 「情報収集係・分析係・実装係」のように工程で分けると、工程間の受け渡しのたびにコンテキストの引き継ぎが発生し、調整コストが膨らみます。逆に、互いのコンテキストを必要としない作業の間に境界を引けば、受け渡しは要約だけで済みます。 **✕ 作業の種類で分ける** — 受け渡しのたびにコンテキストを丸ごと引き継ぐことになります。 ```mermaid theme={null} flowchart LR A[情報収集係] ==>|丸ごと引き継ぐ| B[分析係] ==>|丸ごと引き継ぐ| C[実装係] ``` **○ コンテキスト境界で分ける** — 受け渡しは要約と自己完結した指示だけになります。 ```mermaid theme={null} flowchart LR S[調査エージェント] -->|要約だけ| ORCH[オーケストレーター
分析と判断] ORCH -->|自己完結した指示| W1[実装エージェント A
実装とテスト] ORCH -->|自己完結した指示| W2[実装エージェント B
実装とテスト] ``` この基準を当てはめると、分担の型は次のようになります。 * **情報収集は切り出す。** 探索が生む大量の生データは後工程には不要です。境界が最もきれいに切れる代表例であり、要約だけを返させます。 * **分析と判断はオーケストレーターに残す。** 各エージェントの結果を突き合わせて次の一手を決める作業は、すべての結果が集まる場所でしか行えません。 * **同じコンテキストを必要とする作業はまとめる。** 機能の実装とそのテストのように同じ理解を前提とする作業を別のエージェントへ分けると、同じコンテキストを二度構築することになります。 委譲するときの指示にも同じ原則が現れます。各エージェントには、目的・出力フォーマット・使用するツール・タスクの境界を自己完結した形で渡します。境界が曖昧なまま委譲すると、エージェント同士が作業を重複させたり、どのエージェントも拾わない欠落が生まれたりします。 並列にするエージェントの数は数個程度に留めます。エージェントを増やすほど結果を統合するコストが増え、ある点を超えると並列化の利得を上回ります。 ### 並列に実装する コンテキスト境界による分担を実装作業へ適用した型が**Issue × Worktree**です。適切に分解されたSub-issueは、それぞれが独立したコンテキストで完結する作業単位です。親Issueが依存関係でつないだSub-issueを持ち、git worktreeが各エージェントをディレクトリごと隔離することで、一方の変更が他方に触れない状態を保ちます。 タスクの粒度がエージェントの成否を左右します。タスクをどこまで小さくするか、独立性やrevert影響による分割の検証といった基準は[タスク分解](/ja/development/task-breakdown)を、親IssueとSub-issueの構造化や依存関係の設定方法は[タスクのIssue化](/ja/development/task-breakdown#タスクのissue化)を参照してください。 責務は2つのエージェントの役割にはっきり分かれています。分析と判断を担うオーケストレーターと、実装を担うWorkerです。 * **Team Lead（オーケストレーター）。** 依存関係グラフを構築し、実行レイヤーを決め、タスクを作成・割り当てし、レイヤー間のマージゲートを回し、Workerを同期します。コードは**書きません**。 * **Worker（実装担当）。** 割り当てられたIssueについて、worktreeを作成し、環境を整え、実装し、セルフレビューし、プルリクエストを作成し、結果を報告し、最後にworktreeを片付けます。Workerとworktreeは1対1で対応します。 LeadはSub-issueを依存関係にもとづいて**レイヤー**に分けます。互いに依存しないIssueが同じレイヤーに入り、レイヤーの中は並列、レイヤーの間は直列という2階建ての構造になります。 ```mermaid theme={null} flowchart TB LEAD[Team Lead
Issueを依存関係でレイヤーに分ける] LEAD -->|1. Workerを割り当てる| L0 L0 ==>|2. 全PRのマージ完了| LEAD LEAD -->|3. Workerを割り当てる| L1 subgraph L0["レイヤー0（依存なし）"] direction LR A[Worker A
Issue Aを実装] B[Worker B
Issue Bを実装] C[Worker C
Issue Cを実装] end subgraph L1["レイヤー1（レイヤー0に依存）"] direction LR D[Worker D
Issue Dを実装] E[Worker E
Issue Eを実装] end ``` レイヤー内のIssueは1体ずつのWorkerが自分のworktreeで同時に実装し、それぞれプルリクエストを作成します。レイヤー間の同期はLead専用の仕事で、未マージのプルリクエストを人間に通知しながらレイヤー全体のマージ完了を待ち、defaultブランチを最新化してから次のレイヤーを起動します。後続の作業は常に最新のコードの上に積まれます。循環依存はエラーであり、検出したら報告して中止します。 ## AIと人間の責任分担 このページのすべてのテクニックは、**AIが生成したコードの責任は人間にある**ことを前提とします。AIに委任しても、この責任は移りません。変わるのは、人間が注意を注ぐ場所です。 分担の基準はシンプルです。**機械的に検証できる領域はAIに任せ、判断が必要な領域は人間が担います。** 規約やルールと突き合わせれば正誤が決まるチェックはAIが得意とする一方、正解が文脈に依存する判断は人間にしかできません。 ルールとの照合で正誤が決まる、機械的に検証できる領域。 * コーディング規約・命名・型定義への準拠 * テストコードの有無とカバレッジ * バグ・セキュリティの走査（信頼度の高い指摘のみ報告） 正解が文脈に依存する、判断が必要な領域。 * 変更がビジネス要件を満たしているかの判断 * アーキテクチャ・設計の妥当性 * セキュリティリスクの受容とマージの最終判断 この分担の効果は、人間のレビュー時間の使い道が変わることです。規約や命名の確認はAIが済ませているため、人間は「この変更は本当に要件を満たしているか」という、人間にしかできない判断に時間を使えます。 Agentic Workflowは[Vibe Coding](/ja/ai/vibe-coding)より多くを委任しますが、その土台づくりを引き継いでいます。対話的な協働がまだ機能していないなら、丸ごと実装を委任するより先に土台を整えてください。