コード作成より構築を重視する Angie Jones氏、Agentic AI Foundation

エージェント開発の真実：コード作成から「システム設計」へ、Angie Jones氏が提唱する新しいエンジニアリングの視点

生成 AI の進化により、多くの開発者が「AI エージェントを使ってコードを書く」ことに没頭しています。しかし、その過程で失われつつあるのは、ソフトウェア構築の醍醐味である「興奮」です。 Angie Jones 氏は、単なるプロンプトの羅列やコード生成に終始するのではなく、エージェントを一つの巨大な自律システムとして設計し直す視点の転換を提唱します。

この動画は、AI エージェント開発における本質的な課題と解決策を、従来のソフトウェアエンジニアリングの原則に基づいて解説しています。読者は、なぜ「地味な作業」に陥りやすいのか、そしてどうすれば再び「構築の興奮」を取り戻せるのかを理解できます。

単体のエージェントではなく「システム」を設計する思考

多くの開発者が陥る誤解は、「エージェントさえ作ればすべて解決する」という考え方です。しかし、Angie Jones 氏はこれを強く否定します。エージェント自体が独立した存在ではなく、ファイル、ツール、人間、そして他のエージェントを含む大きなシステムの構成要素として捉える必要があります。

「エージェントを構築する際、単にコード作成に使っているだけでなく、自律型システムの設計へと入っていきます」

例えば、家探し用の「移住スカウト（Relocation Scout）」というエージェントを考えてみましょう。これを一度きりのプロンプトで「物件リストをランク付けして」と指示するだけでは、一時的には機能しても、1 日で最適な家を見つけることは困難です。

真のシステム設計では、以下の要素を明確に定義します。

• 役割: このエージェントは何のために存在するのか？
• 依存関係: 他のコンポーネントとどう連携するか？
• 境界線: エージェントがどこまで責任を持ち、どこで人間や他のツールに引き継ぐか？
• 失敗時の挙動: エラーが発生したらどうなるか？

このように、エージェントを「部品」として扱い、システム全体としての振る舞いを設計することが、エンジニアリングの第一歩です。

巨大なプロンプトを避ける：ワークフロー設計と分解の重要性

従来のソフトウェア開発では、CI/CD パイプラインやチケットのライフサイクルなど、明確なワークフローが存在します。しかし、AI エージェントシステムでは、多くの人が「スラッシュコマンド」で済ませようとし、目標（ゴール）はあっても道筋（ワークフロー）が欠落しています。

「エージェントには目標だけでなく、道筋が必要です」

例えば、「リストを検証する」という目標に対し、実際に何が起こるかを定義する必要があります。エージェントは情報を収集し、基準と照合し、最終的に行動するという一連のステップを設計します。また、実行結果が「停止」「再試行」「エスカレーション」のいずれで終わるかも事前に決めておくべきです。

多くのシステムが失敗する原因は、巨大なプロンプトに依存していることです。指示ファイルに注記や例外処理を次々と追加し続けると、プロンプトはごちゃごちゃした「巨大な塊」と化します。これは従来のソフトウェアにおける「スパゲッティコード」や「巨人クラス」と同じ問題です。

解決策は分解（Decomposition）と関心の分離（Separation of Concerns）です。

1. タスクの分解: プロンプトの中に隠されている異なる作業を特定し、別々のピースに引き離します。
2. 適切な場所への配置:

• スキル（Skills）: リストの正規化など、再利用可能な処理はスクリプトやスキルとして実装する。
• サブエージェント: 通勤距離の計算や地域調査など、特定のタスクに特化した処理は、独立したサブエージェントに任せる。
• プロンプト: 複雑な判断が必要な部分のみをメインのプロンプトに残す。

これにより、各部分が推論しやすくなり、変更も容易になります。一度作成したスキルやサブエージェントは、他の市場やワークフローでも再利用可能となり、モジュール性の高いシステムが構築できます。

アルゴリズム思考：コードと AI の使い分け

「AI エージェントができるからといって、すべてを任せるべきではありません」と Angie 氏は指摘します。ここでの鍵となるのはアルゴリズム的思考です。

• 明確な答えが必要な計算: 通勤時間の計算や重複する物件の削除など、確実な結果が求められるタスクは、コード（スクリプト）で処理すべきです。
• 曖昧さや判断が必要な部分: 「どの物件が魅力的か」「地域の雰囲気をどう評価するか」など、不確実性や文脈理解が必要な部分にのみ、AI モデルを割り当てるべきです。

「明確な答えがあるタスクにはコードを使い、解釈や判断が必要ならエージェントに任せ、権限には人間を使うのです」

この使い分けにより、システムの信頼性とコスト効率が劇的に向上します。AI の出力が毎日異なることにイライラするのではなく、安定した計算部分はコードで固定し、AI にはその上で柔軟な判断をさせることで、システム全体の品質を保てます。

セキュリティと保守性：設計段階での脅威モデリング

生成 AI システムのセキュリティは、従来のソフトウェアセキュリティの原則を踏襲しつつ、独自の対策が必要です。特に重要なのが脅威モデリング（Threat Modeling）です。

• 最小権限の適用: エージェントが「売り手にメールを送る」や「家見学の予約をする」など、重要なアクションを実行する際は、必ず人間の承認を挟むなどの壁（バリア）を設けます。これにより、万が一のエラーによる被害範囲（ブラスト・レイディアス）を最小限に抑えます。
• 信頼できない入力の扱い: エージェントが外部のフォーラムや匿名レビューなどを読み取る場合、それらを「指示」としてではなく「証拠（コンテキスト）」として扱うよう明確に定義する必要があります。

また、システムの保守性を高めるためには、構造化された出力と明確なドキュメントが不可欠です。

• 契約書の役割: エージェントの出力は、人間が読むだけでなく、次のステップのシステムが自動的に処理できる形式（JSON などの構造化データ）であるべきです。これにより、決定内容や評価スコアがセッション内に埋もれることなく、後から検索・再利用可能になります。
• 冪等性の確保: システムは常にクラッシュや再試行を想定して設計されます。「すでに送信したメールを再度送らない」などの処理を、システムの状態（メモリ）を確認しながら安全に実行できる仕組みが必要です。

「プロンプトを一度実行して完了するものではなく、ウェブフックが二重発火したり、実行が失敗したりする現実環境で動作できなければなりません」

まとめ：一層上のレイヤーで再び興奮を取り戻す

Angie Jones 氏が提唱するのは、AI エージェント開発におけるエンジニアリングの筋肉を再活性化させることです。プリミティブ（基本要素）はプロンプトやモデルへと変わりましたが、システムを理解し、分解し、設計するという本質的な規律は変わりません。

コード作成に没頭するだけでは得られない「地味な作業」から抜け出し、エージェントシステム全体のアーキテクチャを設計するという一層上のレイヤーで思考することで、私たちは再び構築の興奮を取り戻すことができます。これは単なるツールの使い方の話ではなく、開発者の役割が「コードを書くこと」から「システムを設計すること」へと再定義される重要な転換点です。