AIエージェントを使う際の2つ目の基本ルールです。大きな依頼をより細かい粒度に分割し、各ステップの後で検証することで、巨大な1本のプロンプトよりも良い結果が得られます。
大規模な新機能に取り組む場合は、いくつかの理由から、小さなタスクに分割する方が適切です。
特に触れておくべき重要な点の1つは、ソフトウェア開発のコストが時間とともにどう変化するかです。書籍『Code Complete』には、開発のどのフェーズでバグを見つけるかによって、修正がどれだけ高くつくようになるかを示した有名なグラフがあります。分析段階ではコストはほぼゼロですが、ソフトウェアが顧客先の本番環境にある段階では、桁違いかそれ以上に高くなります。現在のAIのコード生成の速さを考えると、アーキテクチャを事前に設計することにいっそう注意が必要です。リファクタリングは、まさにAIがあまり得意としないことだからです。最善のアプローチは、クリーンコード系の書籍で説明されている標準に従い、構造やビジネスロジックには確立されたパターンを使うことです。書籍は、AIモデルが学習時に正しい実践を学んだ最も質の高い情報源の1つであり、モデルはそれを最もよく理解しています。AIにとっては、モノリスであってもコードを明確な層に分けておくことも重要です。そうすればエージェントはコードの中でずっと迷いにくくなります。
タスクを正しく分割する方法に話を戻しましょう。たとえば、新しい顧客満足度フォームを作るタスクだとします。どのようなフェーズが必要でしょうか。
- UI — フォーム、各フィールド、送信イベント。
- ビジネスロジック — フォームのバリデーション、リクエストの顧客アカウントへの紐付け、リクエストの優先度。
- データ構造 — データがどのように BE へ渡り、FE へ戻るか。
- BE — バリデーションとビジネスロジックを、今度はバックエンド側で。
- データ層 — データ構造からデータベースへのマッピング。
- データの永続化と、BE から FE へ戻る対応する構造。
AIにとって、どこから始めるかは実はあまり重要ではありません。重要なのは、各ステップを正しく記述することです。ユーザーとして最も実用的なのは、データベースかフロントエンドのどちらかから始めることです。
これですべてのタスクが揃いました。次の問いは、1つの大きなタスクと複数の小さなタスクとでは何が違うのか、です。
1つのタスクにすると、ステップ間で共有されるコンテキスト（キャッシュ）が使えるという利点があり、エージェントは何も調べ直す必要がありません。しかしターン数が増えると、この利点は逆転します。1つのコンテキストに長くとどまるほど、後続のターンごとに再送信・再処理されるトークンが増え、ターンあたりのコストがコンテキストのサイズとともに増え続けます。ターン数の多い長いタスクでは、無視できない金額になりえます。
代わりにタスクを分割すれば、AIは担当する特定の部分だけを行い、最後にそれを独立してテストできます。つまり、次の部分の作業が始まる前に誤りを捕捉できます。全体で消費するトークンも少なくなり、各ステップを独立して検証できるため、巨大な1つのタスクが終わった後よりもはるかに早く、ハルシネーションや要件からの逸脱を捕捉できます。また、小さなタスクなら、モデルがすべての細部に同時に注意を保ち続ける必要もありません。
なぜAIモデルにとってこれがそれほど重要なのでしょうか。モデルは、多数の指示にまたがって同時に優先順位を維持する能力に限りがあるからです。1つのプロンプトに「新機能を追加し、古いロジックをリファクタリングし、関連する3つのバグを修正する」と書くと、モデルは独自の優先順位を組み立てますが、それがあなたのものと一致するとは限りません。その結果、タスクの一部は見事に完了し、一部は手薄になり、本番で壊れるまで誰も気づきません。
だからこそ AITM は、大きな依頼を1回の連続した処理として実行させるのではなく、連鎖したタスクに分割します。
実際にはどうなるか：通常のAIチャットと AITM の比較
通常のAIエージェント（チャット／IDE コパイロット）では、1本の長いプロンプトを渡すと、エージェントは1つの連続したコンテキストの中で作業します。80%まで進んだところで細部を間違えても、差分全体をレビューするまで気づけません。その間にも、後続の項目の作業は壊れた土台の上で進み続けています。
AITM では、同じ依頼がチャットやブレインストーミングで、依存関係を持つ別々の連鎖したタスク呼び出しに分割されます。タスクBは、タスクAがパイプライン全体を通過してマージされた後でなければ開始できません。タスクAがレビューやテストで失敗した場合、タスクBは壊れた土台の上では始まらず、待機します。その間に Watchdog がタスクAの失敗を自ら評価します。エラーを分析して修正案を提案できる場合は、まさにそのエラーと提案された修正を記述したプロンプトでタスクが自動的に再起動します。エラーが不明確であったり、人間の判断なしには解決できない場合は、タスクは停止し、ユーザーがどう進めるかを決めるのを待ちます。さらに、チェーンの最後のタスクがマージされた後には、chain-audit ステップが実行されます。これは決定論的な（AIではない）最終チェックで、チェーン全体の影響を受けるコントラクトを再検証します。
ユーザーから見える違いはこうです。通常のエージェントでは、最後に大きく不透明な差分が1つ出てきます。AITM では、それぞれ独自の履歴を持つ、名前の付いた、独立してチェックされた複数の小さなタスクが得られ、計画どおりに進まなかった場合でも、どこで問題が起きたのかが正確に分かります。