Behind the Craft
AIエージェントの正しい作り方と管理術
要点
- チームは最初のAIエージェントを「作りすぎる」傾向がある。細かいルールや決定論的な指示を詰め込む前に、まずシンプルなプロンプトでモデルに意図を伝え、動かしてみることが先決
- 「プロンプトエンジニアリング」より「ツールエンジニアリング」が重要。コード検索・ログ閲覧・テスト実行・画面確認などのツールをモデルに与えることで、文脈を自分で取得できるエージェントになる
- エバリュエーション（評価基準）はリリース前ではなくリリース後に構築する。実際の動作パターンが見えてから設計すると精度が上がる
- マネージャーエージェント1体が複数のクラウドエージェントに並列でタスクを振り、人間のレビューが必要な箇所だけを判断して戻す構造が、現在の実用的なマルチエージェント設計
- 大規模マイグレーションなどの大きなタスクは「独立したスライス」に分割し、各スライスを別のセッションに渡すことで並列実行・並列テストが可能になる
編集部の考察
記事が示す設計の核心は「マネージャーエージェント1体が複数のクラウドエージェントに並列でタスクを振り、人間のレビューが必要な箇所だけを判断して返す」という構造だ。大規模マイグレーションを「独立したスライス」に切り出して別セッションで並列実行するという具体例も出ている。これをそのまま自社開発組織に当てはめると、エンジニアリングマネージャーや開発リードが現在費やしている「チェックインポイントの設計と判断」の時間が、この構造によって大きく圧縮される。問われるのは「どこで人間が止まるか」のリストが社内に存在するかどうかだ。このリストがなければ、マルチエージェント構成を導入しても品質の天井はすぐに現れる。逆にいえば、「人間が介入すべき判断ポイント」を開発プロセスの中で明文化できている組織ほど、エージェントへの委譲範囲を広げやすく、スピードでの競争優位が先に出る。経営として先行させるべきは、AIガバナンスポリシーの策定ではなく、開発フローの責任境界線の棚卸しとその明文化だ。
原文より
“Tool engineering" is giving the model ways to search your code, read logs, run tests, open the app, and inspect what it changed.”
本記事は原文ニュースレターの独自キュレーション・考察であり、翻訳ではありません。引用部分の著作権は原著者に帰属します。