AIのコーディングは、「すべてを1つのエージェントにやらせること」を期待するのをやめたとき、ずっと役に立つと感じ始めます。
本当のレバレッジはモデルそのものだけではありません。それを取り巻くシステムです。明確な役割、明確な文脈、明確なルール、そして明確な検証。これが、全体をより予測可能にし、信頼しやすくし、さらにスケールしやすくするのです。
このように考え始めると、ワークフローは変わります。魔法を求めるのをやめて、責任を設計するようになります。
支援レイヤーは、人々が思うよりも重要だ
品質の多くは、プロンプト自体から生まれるわけではありません。ワークフローの周囲にあるファイルや構造から生まれます。
これらの支援用ファイルが、システムを混乱に変わるのを防ぎます。仕事がどう進められるべきか、何が尊重されるべきか、タスクが大きくなったり、より曖昧になったりしたときにエージェントがどう振る舞うべきかを定義します。
こう考えると分かりやすいです：
- エージェントファイル は、デフォルトの振る舞いと全体的な境界を定義する
- スキル は、特定の種類の作業に対する再利用可能な能力を定義する
- サブエージェント は、大きなフローを小さな、焦点の合った責任に分割する
これらすべては、セットアップを見栄えよくするためにあるわけではありません。もっとシンプルな目的があります。ランダム性を減らすことです。
ワークフローに構造があると、エージェントはあれこれ推測しなくなります。何が重要か、何が許されているか、どこまで掘り下げるべきかが、よりはっきり分かるようになります。
エージェントファイル
これは基礎レイヤーです。
エージェントファイルは通常、ワークフローにおけるメインの実行ロジックのように振る舞います。プロジェクト内のタスクにどう取り組むべきか、デフォルトとしてシステムがどう振る舞うべきか、どの基準が重要か、決して破ってはいけないことは何かを指示します。
ここで通常、次のようなものを定義します：
- アーキテクチャの境界
- コーディング規約
- 検証に関する期待
- エージェントが避けるべきこと
- 常に成り立ち続けるべきプロジェクト固有のルール
このレイヤーがないと、すべてのタスクがより弱い基準から始まります。そのたびにエージェントは作業の前提を作り直さなければなりません。
スキル
スキルがあることで、ワークフローがモジュール化したように感じられるようになります。
スキルとは、基本的に繰り返される種類の作業に対する再利用可能な能力です。巨大な汎用の命令セットに頼るのではなく、特定のタスクを扱うための焦点の合った方法を作ります。
例：
- コーディングの前に機能を計画する
- 差分（diff）をリグレッションの観点でレビューする
- テストを書く／改善する
- 失敗しているフローをデバッグする
- 実装が元の依頼内容と実際に一致しているかを確認する
スキルによって、ワークフローはより鋭くなります。エージェントが「一般的な知性モード」から「特定の業務モード」に切り替えるのを助けます。
通常、それによってタスクの枠組みがより正確になるため、より良いアウトプットにつながります。
サブエージェント
サブエージェントは、1つのタスクが広すぎて、単一の実行スレッド内で信頼性を保つのが難しいときに有用です。
1人のエージェントが、すべてを理解し、すべてを決め、すべてを作り、すべてを検証しようとするのではなく、スコープをより絞った小さな担当者にフローを分割します。
そうすると、物事がずっと整理されます。
サブエージェントは、1つのことだけに集中できます。その責任が狭いことが、通常はドリフトを減らし、ノイズを減らし、奇妙な副作用を減らします。
良いサブエージェントは「単なる別のエージェント」ではありません。非常に明確な目的を持っています。
たとえば：
- あるサブエージェントがコードベースを調べる
- あるサブエージェントが実装方針を提案する
- あるサブエージェントが変更を書く
- あるサブエージェントが品質とリスクをレビューする
ここで、マルチエージェントのワークフローが、ただ目を引くだけでなく、本当に役に立つものとして感じられ始めます。
シンプルな開始時の役割で十分だ
始めるのに大きなシステムは不要です。実際、最初から大きくしすぎると、たいていは状況が悪化します。
非常にしっかりした構成は、ほんの少数の単純な役割だけでも始められます。
プランナー
プランナーは、コードの動きが始まる前にタスクを理解するために存在します。
その役割は、問題を分解し、影響を受ける領域を地図化し、リスクを特定し、最も安全な次の手を提案することです。
良いプランナーは、無駄な手数を減らします。ワークフローの残りに方向性を与えます。
典型的な責任：
- 依頼内容を理解する
- 関連するファイルを調べる
- 制約を特定する
- 小さな実装方針を提案する
- リスクと不明点を明らかにする
プランナーは、コードを作るのではなく、明確さを作るべきです。
ビルダー
ビルダーは実行レイヤーです。
この役割は、承認された方針を取り、スコープをきっちり絞って実装します。ここで重要なのは規律です。ビルダーは途中で「より見栄えのする解決策」を見つけたからといって、システム全体を作り直すべきではありません。
価値は集中から生まれます。
典型的な責任：
- 計画した変更を実装する
- スコープ内にとどまる
- 必要な場合は既存の振る舞いを維持する
- 解決策をできるだけ小さく、安全に保つ
良いビルダーは、間違った場所で創造性を発揮しません。正確です。
レビュアー
レビュアーは、（良い意味での）摩擦のレイヤーです。
その役割は、より多くを作ることではありません。作られたものに対して異議を唱えることです。これには、バグ、リグレッション、見落とされたエッジケース、弱い検証、不必要な複雑さを探すことが含まれます。
典型的な責任：
- ロジックの品質を確認する
- リグレッションを探す
- 不足しているテストを見つける
- 過剰な設計（やりすぎ）を見抜く
- リスクのある前提に異議を唱える
この役割は非常に重要です。エージェント型ワークフローはコードを速く作れますが、レビューなしのスピードは、単にミスがより早く到着するだけだからです。
後から追加できる任意の役割
ワークフローが成長してきたら、いくつか追加の焦点の合った役割を加えると役立つことがあります。
追加するかもしれません：
- 検証とエッジケースにだけ集中するテスター
- 失敗の調査を行うデバッガー
- 振る舞いを変えずに構造を改善するリファクタラー
- 技術的な判断を明確に保つドキュメンター
ただし、最初はプランナー、ビルダー、レビュアーだけでも、強固な土台を作るのに十分です。
本当の考え方
目標は、エージェントを増やすことではありません。
目標は、責任をより良く分離することです。
これが、AIのコーディングを「ランダム」ではなく、実際のエンジニアリングシステムのように感じさせる転換点です。ワークフローの各パートに明確な仕事が割り当てられるようになれば、品質は管理しやすくなり、判断はレビューしやすくなり、プロセス全体ははるかにスケーラブルになります。
そのとき、プロンプトの実験のような感覚から、実際のワークフロー設計の感覚へと変わります。
近いうちに、このワークフローを複数のサブエージェントで実際に設定・実装する方法について、CYA
