AIエージェント開発の課題

AIエージェント開発は「プロンプトを書く」時代から「アーキテクチャを設計する」時代へ移行しています。本記事では、5つの重要概念（MCP、Tool、Skill、Agent SOP、マルチエージェント）が、それぞれどのような課題を解決するために生まれたのかを解説します。

読了時間: 約5分

はじめに：「動かない」から「信頼できる」へ

AIエージェント開発の世界では、単一の巨大なLLMにすべてを任せる時代から、構造化され、専門化され、相互接続された複数のエージェントが協調する時代への移行が起きています。

本記事では、AmazonやAnthropicなどが提示する新しい概念の全体像を整理し、実務での採用判断に役立つ知識を提供します。

問題1：「統合地獄」を解決する - MCP (Model Context Protocol)

なぜ生まれたのか

従来のAI統合は「M×N問題」に悩まされていました。3つのモデルと5つのデータソースを連携させるだけで、15通りのカスタム実装が必要になります。新しいモデルを追加するたびに、すべてのデータソースとの連携を再実装。新しいデータソースを追加するたびに、すべてのモデルとの連携を書き直す。このサイクルは持続不可能でした。

MCPが変えたこと

Model Context Protocol (MCP) は、AIモデルと外部システムを繋ぐための標準化された通信プロトコルです。

統合の数式が変わる:

従来: M個のモデル × N個のツール = M×N個の統合コード
MCP後: M個のモデル + N個のMCPサーバー = M+N個の統合コード

一度MCPサーバーを作成すれば、MCP対応のどのAIモデルからも同じインターフェースでアクセスできます。これは、USBが登場する前の周辺機器接続の混乱が、USB規格の標準化によって解決されたのと同じ構造です。

なぜ重要なのか

開発コストの削減: 統合コード量が1/3〜1/5に削減
保守性の向上: 新しいデータソース追加時、既存コードへの影響ゼロ
エコシステムの形成: 作成したMCPサーバーをコミュニティで共有可能

問題2：「粒度の混乱」を解決する - ToolとSkillの使い分け

なぜ区別が必要なのか

初期のエージェント開発では、「何を1つのツールとして定義すべきか」が曖昧でした。その結果、100個以上の細かすぎるツールを持つエージェントや、1つで何でもやろうとする肥大化したツールが生まれました。

ToolとSkillの明確な違い

概念	スコープ	役割
Tool	単一のアトミックな操作	「原子的な機能」を提供
Skill	目的達成のための複合能力	「業務知識」を含むワークフロー

Toolの本質
それ以上分割できない最小単位の機能。単一責任の原則に従い、1つのことだけをうまくやります。

Skillの本質
複数のToolを組み合わせて特定の目的を達成するワークフロー。「何を」「いつ」「どの順番で」Toolを使うべきかという業務知識を持ちます。

いつSkillを作るべきか

同じツールの組み合わせを3回以上使う場合
特定のドメイン知識（業務知識）が必要な場合
チーム間で再利用したい標準手順がある場合

問題3：「動作の不安定性」を解決する - Agent SOP

なぜ生まれたのか

Amazonの社内で数千人のエンジニアがAIエージェントを使い始めたとき、2つの大きな問題が顕在化しました。

課題1: 不一致な動作
同じプロンプトでも、実行のたびに異なる結果が出る。開発環境では完璧に動いていたエージェントが、本番環境では想定外の挙動を繰り返す。

課題2: プロンプト変更の恐怖
効果的なプロンプトを書くには深い専門知識が必要で、一度書いたプロンプトを修正すると予期せぬ副作用が発生。変更の影響を評価するだけで数週間かかることも。

Agent SOPという解決策

Agent SOP (Standard Operating Procedure) は、自然言語でありながら決定論的な制御を可能にします。「決定論的すぎず、かつ予測可能」という絶妙なバランスを実現します。

キーポイント: RFC 2119準拠

Agent SOPは、インターネット標準化で使われるRFC 2119という仕様に準拠しています。

3つのキーワード

MUST（必須）: 必ず実行しなければならない
- 法的要件、セキュリティ、データ整合性など
SHOULD（推奨）: 通常は実行すべきだが、正当な理由があれば省略可能
- 最適化、ユーザー体験向上など
MAY（任意）: オプショナルな強化機能
- 付加価値、差別化要素

なぜ重要なのか

Agent SOPは、AIエージェント開発における「知識の形式知化」を実現します。優秀なプロンプトエンジニアの頭の中にあった暗黙知が、SOPというフォーマットで明示的に表現され、組織全体で共有可能になります。

さらに、MUSTで定義された部分を守る限り、SHOULDやMAYの部分を安全に改善できるため、継続的な品質向上が可能になります。

問題4：「単一エージェントの限界」を解決する - マルチエージェント設計

なぜ1つのエージェントでは不十分なのか

「全知全能のAI」を1つ作ろうとすると、必ず壁にぶつかります。

典型的な失敗

システムプロンプト: 5,000単語以上
ツール数: 50個以上
成功率: 30%以下
デバッグ: ほぼ不可能

問題の本質はコンテキストの混乱です。1つのエージェントにあまりにも多くの責任を持たせると、どのツールをいつ使うべきか判断できなくなります。

マルチエージェントが変えること

研究によれば、複雑なタスクにおいて、マルチエージェントはシングルエージェントと比較して成功率が最大70%向上します。

この改善は、 「専門化」と「協調」 という2つの原理から生まれます。

4つの協調パターン

パターン1: Agents as Tools（階層型）

構造: オーケストレーター（マネージャー）が複数の専門エージェント（ワーカー）を管理

なぜ有効か

コスト最適化（高価なモデルは判断のみ、定型作業は安価なモデル）
関心の分離（各エージェントが明確な責任範囲）
段階的な拡張が容易

パターン2: Swarm（群れ型）

構造: 複数の対等なエージェントが協調して問題を探索

なぜ有効か

多様な視点（同じ問題に異なるアプローチ）
リスク軽減（1つの誤りを他がカバー）
並列処理（複数の仮説を同時検証）

パターン3: Graph（グラフ型）

構造: エージェント間の情報の流れを厳密に制御する有向グラフ

なぜ有効か

監査可能性（情報の流れが明確）
予測可能な動作（実行順序が決まっている）
品質保証（各ステップで検証を挟める）

パターン4: Workflow（ワークフロー型）

構造: 明確なステージ構造を持つ順次処理パイプライン

なぜ有効か

明確な段階構造（各ステップの責任が明確）
依存関係の管理（前段階の出力が次段階の入力）
チェックポイント（失敗時に特定のステージから再開）

パターン選択のガイドライン

パターン	最適なケース
Agents as Tools	タスクが明確に分離可能で、コスト最適化が重要
Swarm	正解が1つではない創造的タスク
Graph	コンプライアンスや監査が重要
Workflow	既存の業務プロセスをAI化

実践：5つの概念を統合した設計の考え方

ステップ1: 現状分析

自動化したい業務を明確にし、暗黙知を形式知化します。

問うべき質問:

業務プロセスを文書化できているか？
どのような判断基準で業務が進行しているか？
必要なデータソースは特定できているか？
成功の指標（KPI）は明確か？

ステップ2: MCP基盤の設計

必要なデータソースとツールをMCPサーバーとして整理します。すべてを自作せず、既存のMCPサーバーを積極的に活用すべきです。

ステップ3: Agent SOP作成

既存の業務マニュアルを元に、SOPを作成します。

作成の順序

まず「MUST」だけを定義（最小限の動作保証）
次に「SHOULD」を追加（理想的な動作）
最後に「MAY」で拡張機能を加える

ステップ4: マルチエージェント設計

タスクの性質に応じて、適切な協調パターンを選択します。

ステップ5: 評価とイテレーション

評価の3つの軸

機能性: SOPで定義したMUST要件をすべて満たしているか
効率性: 処理時間とコストは許容範囲内か
信頼性: 同じ入力に対して一貫した出力が得られるか

よくある失敗と対策

失敗パターン	原因	対策
プロトタイプ止まり	本番データとの統合が困難	初日からMCPで標準化
精度が上がらない	プロンプトの属人化	SOPで知識を形式知化
コストが膨大	全タスクに最高性能モデル使用	マルチエージェントで適材適所
保守できない	ブラックボックス化	Graphパターンで可視化

まとめ：「育てる」システムとしてのAIエージェント

AIエージェント開発は、もはや「プロンプトを書く」だけの作業ではありません。

新しいスキルセット:

アーキテクト: システム全体の構造を設計する
SOPライター: 業務知識を形式知化する
インテグレーター: MCPで異種システムを繋ぐ
オーケストレーター: 複数エージェントを協調させる

これらは、従来のソフトウェアエンジニアリングとビジネスプロセス設計の知識を組み合わせた、新しい専門領域です。