こんにちは。お疲れ様です。今回はタイトルの件について、自分なりに考えた内容を整理しておきます。
AIエージェントを設計する際、「どのような責務を持たせるべきか」という問いに直面します。関数やクラスの設計では確立された原則がありますが、AIエージェントにはどのような指針が必要でしょうか。
本記事では、私の開発経験を元にAIエージェントの設計パターンとその本質的価値について整理します。
よくみるAIエージェント責務のパターン
まず、よくみるAIエージェントの責務パターンを3つに分けて考えます。
- 機能に特化するパターン
- ロールに特化するパターン
- 実行支援に特化するパターン
1. 機能に特化するパターン
機能に特化するパターンは、例えば、二つのツールを持っているAIエージェントで、そのツールの組み合わせが「データの取得」と「データの加工」みたいなパターンの場合です。天気を取得して分析するとか。
このパターンを私も実装したことがありますが、この機能を客観的に見て思うのは、「普通の関数でいいんじゃないの？」ということです。データの取得と加工のツールがあったとしたら、常に同じ順番で実行されますし、常に同じ順序で実行されるならLLMの推論を挟まないロジックを記述できそうに思います。
機能特化の段階で止まるなら関数でいいのですが、次のステップに進むためにはAIエージェントの形式である必要があります。
2. ロールに特化するパターン
ロールに特化するパターンは、実際の職種を代替しようとするようなパターンです。AIカスタマーサポートとかAIエンジニアとか。この手のエージェントは、複数のデータソースにアクセスするツールと、複数のアクションを実行するツールを保持します。
このパターンを見て思うのは、コントロールが難しいということです。欲しいデータソースをいい感じの場面で参照してくれなかったり、期待したようなアクションを実行してくれなかったり。そうこうしているうちに、期待する条件が理解できてきたら、普通に条件分岐を実装してしまう方が安定しますし、実行コストとして優位に見えてきます。
私も実際に、ロール特化のパターンに対して条件分岐を実装したことがありますし、特定の場面においては有効です。また、動かせるようになると強力です。ただ、個人的には自由度が高すぎるとリスクが高いのでもっと限定していきたいと感じます。
私が思うに、ロール特化以上にエージェントの本質的な価値を引き出しやすいパターンがあるように思います。
3. 実行支援に特化するパターン
私の思う、ロール特化以上にエージェントの本質的な価値を引き出しやすいパターンは、実行支援に特化するパターンです。
そもそもの話として、複数のデータソースにアクセスするツールと、複数のアクションを実行するツールを保持するエージェントが有効なのは、それらの利用条件が事前に定義できない場面です。組み合わせパターンが多く、あるデータソースの条件次第で別のデータソースにアクセスする必要があるとか、アクションの実行結果によって次のアクションや必要なデータが変わるとか、入力値によっては複数の経路を通る必要があるとか。
つまり、エージェントは次の条件が揃った時に、効果的に動きます。
- 入力が多様である。必要な出力に対して必要な入力がバラバラであり、重複もある。自由テキストでの入力が効率的である。言い換えると、入力の不確実性が高く、条件も複雑。
- 出力が多様である。入力に対して、単一の出力結果にならず、外部データソースの状況によって、ワークフローが複雑に変化する。言い換えると、多様な入力と外部データの状況の考慮した出力の条件定義が困難である場合。
このパターンの具体例は、ClaudeCodeです。ClaudeCodeは、「ソフトウェアエンジニア」というロールに特化したAIエージェントではなくて、「ソフトウェアエンジニアリングタスクの支援」という実行支援に特化したAIエージェントであると見ています。
実行支援特化のAIエージェントは、「雑に情報をつっこんで、状況を見て、いい感じに動いてもらう」とことができます。この「いい感じ」をエージェントが評価するために目的が必要になります。
AIエージェントの本質的な価値
私が考えているAIエージェントの本質的な価値は、システム開発の省略にあります。AIエージェントが生み出す価値を列挙すると、次のような価値があります。
- 情報の入力負荷の低減（前提情報を注入可能で、利用時に投入する情報は最小限にできる）
- 文脈や周辺状況の有効活用（人が介在せずに、周辺状況のチェックを判断できる）
- 人側の認知負荷の低減（人が介在せずに、状況判断を進められる）
そして、「なぜ、上記の価値が生まれるのか」と言うと、アプリケーションの開発コスト・保守コストが高いからです。AIエージェントに複数のデータソースを参照と実行可能なアクションを渡すことで、エンジニアがドメイン知識を理解し、仕様を定義し、効率的な目的達成ロジックを定義するプロセスが省かれた上で、目的が達成されます。
それが随時行われることで、状況の変化に応じて、自動的にロジックが随時作成されることになります。つまりこれは、ロジックを作る部分が省略されています。LLMに寄って代替されています。
AIエージェントが生み出す価値の意味
AIエージェントが前述のような価値を生み出す代わりに、AIエージェントが向かない領域や、AIエージェントで目的を達成することで失われることもあります。これも意識していきたい話なので書いておきます。
- AIの基盤モデルにベンダーロックされる。
- 従来のソフトウェア開発・システム開発では、設計書やプログラムの中に業務ロジックが描かれますが、AIエージェントに複数のデータソースとアクションを渡して目的を達成すると、その目的の達成方法は、AIの基盤モデルの中に隠蔽されることになります。ちなみに、複数の道具を使って特定の目的を効率的に達成する方法は『技術』と呼ばれますが、技術が基盤モデルに隠蔽されます。
- 安定性・確実性・再現性に限界がある。
- 従来のソフトウェア開発のように業務ロジックを定義して実装すれば、あとはそのロジックで処理が実行されます。しかし、AIエージェントによって目的を達成すると、何度繰り返しても結果が不安定であったり、確実性や再現性に限界が出る状況があります。
- 価格決定権・更新権が低い
- AIの基盤モデル側の価格が上がれば、当然ながら価格を上げざるを得なくなります。エンドユーザーが品質に納得していたとしても、基盤モデル側がモデルを最新化し、価格を上昇させた場合、サービス提供側の都合で、値上げが発生します。
AIエージェントを活用する場合、これらを中長期的な目線で見て、AIエージェントの活動ログを元に条件をルールベース化してなりで、知識の内製化は図れます。ただし、状況が変化した場合にルールが無効化されるケースもあり、結局、知識を保守していくために、AIエージェントの利用は避けられなくなるかもしれません。
まとめ
話をまとめます。
- 単純な処理には関数を使用します。AIエージェントは不要です。
- 入力と処理の多様性が高い場合は「目的特化」パターンの採用が有効です。
- AIエージェントの導入時は、ベンダーロックや安定性のリスクを考慮した上で、適切な領域への利用と内製化を視野にしれましょう。
終わりです。
