25年のAIはエージェントが流行るよ
という話をよく聞きます。ベンダー含め色々な情報をチェックしたのですが、色々な語られ方をしており、概念的には何となく分かったけど実際何をすればいいのかが不透明な印象です。
そこで、AIエージェントについて
- どんなものをつくればいいのかイメージする
- 25年にどこまで実現するかという予想をする
を整理してみたいと思います。結果は25年末に振り返りをしてみます。
AIエージェントとは
LLMの使い方のひとつとして、システムプロンプトに「あなたは有能なXXで、こんな観点で入力をYYします」といった役割・処理を用途別に定義することがあると思います。こうした擬人化を「エージェント」と呼ぶこともあるようですが、25年のAIエージェントはもっと広い意味で使われます。
各AIベンダーの定義（最後のほうにまとめました）は少しずつテイストが異なりますが、LLMの機能に限定せず様々な外部ツールのデータやスキルを活用して結果を出すという点は概ね共通しています。
AIエージェントについて特徴を一言で説明するとしたら、次のようになりそうです。
ユーザー向けのバリュー説明
これまでのAIは同僚、エージェントは片腕
これまでのAIは相談相手になってくれる同僚。多数のインプットを準備することで的確な回答を返してくれる相談相手。
AIエージェントはあなたの片腕。少ないインプットでも必要な情報を収集したり作業を進めたりしてくれる。
技術者向けのAIエージェントの特徴説明
ビジネスタスクを手続き的から宣言的に移行するツール
k8sなどで観察してきた「手続き型から宣言型への移行体験」をビジネスのIT利用の現場にもたらします。
従来は、手続き的なタスクを把握、実践することが仕事スキルの一部とされてきましたが、これをAIエージェントに担ってもらうものになります。
AIエージェントの種類
IBMの公開資料では、5種類のパターンが定義されています。後の方ほど仕組みが複雑化する代わりに精度向上が期待できるでしょう。
| パターン | 概要 | 所感 |
|---|---|---|
| 単純条件反射・エージェント Simple reflex agents |
LLM単独で結果を判断し返却する。いちばんプリミティブな利用方法。 | シンプルなLLM利用に該当する。 |
| モデル ・ ベース条件反射・エージェント Model-based reflex agents |
LLMとLLM外の情報や機能を利用して結果を出力する。 ここで使われる「モデル」は基盤モデルのことではなく、LLMを中心に、お世話になる色々な要素を抽象的に示している。ユーザーの対話履歴や外部APIなど。 |
RAGはこのパターンの実例の1つと考えている。 実装は、定義済ワークフローに基づくパイプライン処理が有力。ただフローは特定目的を想定して作成するため、用途の数だけフローを準備する必要がある。 |
| 目的ベース・エージェント Goal-based agents |
色々な要素を利用する点はモデルベースと一緒だが、ワークフローを定義せずにAIが入力された目的にあわせた処理手順を生成する。 | 後述するReActとReWOOが手順生成の方式として考えられる。 |
| 効用ベース・エージェント Utility-based agents |
単に目的を達成するだけでなく、賢く達成する（低コスト、高速、高品質）ための評価を組み込む。 | 評価式（ユーティリティ）はロジックや評価用の係数設定など、静的な処理（つくりこみでの埋め込み）になると思われる。 |
| 学習エージェント Learning agents |
過去の実績から動作を修正して、時間経過とともに賢い対応を行なう。 | 評価式のパラメータを、ユーザーフィードバックや何らかの測定結果を外部から収集することで動的な評価を行なう。 事務アプリでどのような実績をどのように収集するかが大きな課題になりうる。 |
「モデルベース」と「目的ベース」が開発者目線ではアーキテクチャが異なることから理解しておくべき重要パターンであると考えています。
効用ベースと学習エージェントは目的ベースのチューニング手法という位置づけかなと理解しました。
AIエージェントのアーキテクチャ
上記のパターンに出てくる「ワークフロー」「ReAct」「ReWOO」を図示します。
ワークフロー
図でみるとほぼiPaaSですが、リクエストに合わせてフロー上の実行タスクや進み方を選択するあたりにLLMを使うかなと考えています。入力の情報には、LLMの対話メモリなども含みます。
外部サービスの部分はSaaSや各種システムなどが当てはまります。ここにLLMを当てはめることもあるでしょう。
iPaaSを使わずに、つくりこみで実現する際にはLangGraphが選択肢にあがりそう。
ReAct
AIが自律的に処理を進める場合の1パターン。LLMが自身で必要な外部サービスを選択して情報を受け取り結果を生成し、評価プロセスが承認するまで推敲を繰り返します。
「ガムシャラな若手社員が、先輩に ダメ出し 指導を受けながら、資料を完成に近づけていく」構図みたいです。機械処理だからこそ可能な力業。
LLM自身には外部サービスを呼び出す機能は無いため、タスクの実行とLLMへの結果の連携はLLM外のプログラム等で対応することになります。
LLMが適切なタスク選択およびパラメータ生成をできるように、タスクの仕様を適切に提示することが精度を上げるポイントになりそうです。
実装ではFunctionCallingなどの連携技術が必須です。
ReWOO
AIが自律的に処理を進める場合の1パターン。LLMの推論で処理の流れを予め整理したうえでタスクを進めるという考え方です。図にするとReActとワークフローを融合したような形になります。
大きな違いはワークフローを開発者が事前定義するのではなく、LLMがプランニングするところです。
「若手社員が仕事の進め方を段取り組めるようになって、無駄のない仕事ができるようになった」という感じになりました。先輩の負荷も軽くなることでしょう。
いくら機械作業とはいえ各種処理にはコストがかかります。計画的に仕事を進めることでトークン消費の抑制や結果出力までの時間の効率化が期待できます。
「AIが効果的なプランニングを行なえるのか」は大きな論点ですが、AIの推論能力向上は各社が注力する分野なので時間が解決するのではないかと楽観視しています。現時点でもワークフローの組み方をCoTプロンプティングの要領で補助することで、ある程度の精度向上は期待できそうです。
エージェントの階層化
AIエージェントのアーキテクチャを見てきましたが、ビジネスの全領域をカバーするエージェントをつくりきるのは現実的とはいえません。企業のITが多数のシステムで成り立っているように、特定領域をカバーするエージェントを複数つくるほうが開発・保守の両面で合理的です。
とはいえ、ユーザー目線ではときに領域をまたいだタスクをこなしてほしいケースもあるでしょう。その他、使い分けるのも手間なので何でもよろしくやってくれるスーパーエージェントが欲しい、というニーズもあるかもしれません。
そこで「個々のエージェントを使いこなすエージェントを上位に置く」というパターンが考えられます。
図の構成からの例を挙げると、
3年後に自社の主力商品になるアセットをつくるためのプロジェクト案をつくってください
といったリクエストに、
- 統括エージェントが指示を受け、関係するエージェントを選択し指示を出す
- 営業エージェントは、売上状況や他社動向、お客様フィードバックをもとに潜在ニーズをピックアップする
- 技術開発エージェントは、自社アセットのラインナップや開発進捗状況から、市場に出せそうなアセットを提案する
- 人事エージェントは、提案アセットの難易度や規模から必要な人員を選定してチーム案を提示する
- 統括エージェントが結果を取りまとめて最終結果を出力する
といった動き方をするイメージです。
25年のAIエージェントを予想する
ITの現場で、25年にAIエージェントがどのように展開されるのかを想像していきます。
AIエージェントで流行するアーキテクチャ
ワークフローの適用が主流
AIエージェントへの取り組みの初期段階では「特定の課題を解決できるエージェント」となるべく課題を絞ったほうが仕様検討や効果測定に取り組みやすいと考えます。
利用できる外部サービスのストックが多種多様になるとワークフローの開発・運用が追い付かなくなり、自然とReACTやReWOOに発想がシフトしていくでしょう。
AIエージェントが自律的に仕事を進められるか
影響が少ない範囲で適用が始まるかもしれない
「AIエージェントは自律的だから、自動で物品の購入手続きなどを進めてくれる」という期待感もあると思います。承認や発注といった仕事のステータスを前に進める更新系タスクをAIエージェントが行ってくれれば、人間のワークロードを削減してAI利用が業務効率化に直結することをアピールできそうです。
自動車の自動運転に例えると レベル4（高度運転自動化） を狙うイメージですが、精度的な課題は今後も発生すると思われ、25年中は レベル3（条件付運転自動化） に到達できるかどうか、というところでしょう。
それでも、ビジネスの主流ではない部分、例えば勤怠システムへの打刻処理や消費者アンケート結果のデジタイゼーションなど、エラーが発生した際のインパクトが吸収できそうな領域では自動化の挑戦はできるでしょう。
AIエージェントのインターフェース
チャットライクなI/Fが主流
個人的にはITシステムとAIエージェントがシームレスに連携して、ユーザーのIT利用全般でAIの恩恵が受けられるようになってほしいです。ただAI=チャットベースのような考え方が大半なので、チャットのような仕組みを使った利用は今後も続いていくでしょう。
スーパーAIエージェントの活用
25年はスーパーではない部分に留まる
ここでいうスーパーとは、上の方で述べた「エージェントの階層化」に基づきAIエージェントを束ねるという意味でのスーパーエージェントです。
AIエージェントが進化していけば、自然にスーパーエージェントの必要性が議論されるでしょう。ただ25年は個々のエージェントが価値を出す活動が優先されますね。
数年後のAIエージェントの姿
ここまで見てきた技術的な方向性や可能性を元に、数年後はこれができてほしいという未来予想です。
AIでの実現可能性については楽観的ですが、IT開発界隈がパラダイムシフトに追従できるかのほうが怪しいです。
IT開発のAIエージェントの適用
コーディングを行なわない世界に踏み出す
SoR系システムは突き詰めると「いかにデータを正確に登録／共有するか」という仕事を行なっています。具体的な処理としては「入力チェックして正しいデータをデータベースに書き込む」「ユーザーに必要な形でデータを提供する」のどちらかです。
AIエージェントのアーキテクチャ論がほぼ確立されて、更新系タスクへの信頼性も上がってくるとしたら「ビジネスルールのドキュメントがあれば、入力データを渡したらデータチェックと更新までお任せする」タスクも任せられそうです。
これが実現できれば、IT開発分野では「AIでコーディングを支援する」ではなく「AIがコード実行を代替する」という世界が見られるかもしれません。
大量データを対象として処理速度を追求する必要がある分野はスクラッチがまだまだ必要とされそうですが、それ以外の分野には適用できるでしょう。
最後に
色々書いてきましたが、言葉の最後に「〜かもしれない」とか自信の無い表現が目立ちますね。
25年は実装含めて色々と知見と経験を蓄えて、少しずつ自信のある表現に変えていきます。一緒に頑張りましょう。
参考（AIエージェントの定義）
IBM
人工知能（AI）エージェントとは、ワークフローを設計し、利用可能なツールを活用することで、ユーザーまたは別のシステムに代わってタスクを自律的に実行できるシステムまたはプログラムです。
AWS
環境と対話し、データを収集し、そのデータを使用して自己決定タスクを実行して、事前に決められた目標を達成するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。
Microsoft
ただ単に支援するだけでなく、ユーザーと一緒に、あるいはユーザーの代わりに作業を行うことができます。エージェントは質問への回答から、より複雑なマルチステップのタスクまで幅広いことをこなせます。パーソナルアシスタントとの特筆すべき違いは、特定の専門性を持つようにカスタマイズできる点です。
Google(Agentspace)
Gemini の高度な推論、Google 品質の検索機能、ホストされている場所に関係なくあらゆるエンタープライズ データを統合するエージェントにより、従業員がエンタープライズの専門知識を活用できるようにします。
Anthropic
"Agent" can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows.
「エージェント」は、いくつかの方法で定義できます。一部の顧客は、エージェントを、さまざまなツールを使用して複雑なタスクを遂行し、長期間にわたって独立して動作する完全に自律的なシステムと定義しています。また、定義済みのワークフローに従う、より規範的な実装を説明するためにこの用語を使用する顧客もいます。
参考