AIエージェントのしくみと技術：RAGベースとワークフローベース

先日は「ChatGPTでChatGPTの本を書く」という記事で、筆者が書いた『図解即戦力　ChatGPTのしくみと技術がこれ1冊でしっかりわかる教科書』（以降「本書⁠」⁠）の紹介とともに、本書執筆におけるChatGPTの活用について紹介しました。

今回の記事では、本書では触れられなかった「AIエージェント」について解説します。

この「AIエージェント」という用語は、文脈によって異なる意味を持つことに注意が必要です。まず、AI研究の分野でもともと「エージェント」と呼ばれていたのは「自律エージェント」のことでした。これは、人間が具体的な指示を逐一与えなくても、システムが自律的に状況を判断し、独立して行動可能な技術であり、汎用人工知能（AGI）を目指す技術の一環でした。

一方、最近の「AIエージェント」は、もっと広い意味で使われています。例えば、自治体や企業などの組織の情報についての質問に答えるボットのような、特定の目的に沿ってユーザと会話を行うAIも「AIエージェント」と呼ばれています。

このようなAIを賢く実現するには、人間の曖昧な指示から目的を推論したり、不定形なデータを処理したりするなどの高度な処理が必要です。そこには確かに自律エージェントの要素技術が応用されてはいますが、こうした特定の用途に特化したタイプのAIは「カスタムAI」と呼ぶほうが実態に即しているように思えます。

とはいえ、響きの良い言葉が本来の意味から離れ、流行りの技術に使われるのはよくある話です。一般のユーザーがAIに求めているのは汎用人工知能の実現ではなく、それぞれが直面する個別の問題解決であることの表れなのかもしれません。

本記事では、主に「カスタムAI」の意味でのAIエージェントを解説しますが、自律性の高いエージェントについても少し触れます。

AIエージェントを開発するツール

現在、さまざまな「AIエージェント」（⁠カスタムAI）が数多くリリースされています。その中の一つが自分の問題にぴったり適合すれば理想的ですが、それぞれが抱える問題は微妙に異なるため、なかなかそういうわけにもいきません。大規模言語モデル（以降「LLM⁠」⁠）によって汎用性が格段に上がったとはいえ、どんな問題でも解けるAI（汎用人工知能！）はまだ登場するには至っていません。また、昨今のAIブームの高まりを受けて、自分たちのサービスやプロダクトにサポート的なカスタムAIを開発・導入したいといった要望も増えています。

こうした「AIエージェントをアレンジしたい」「⁠自分たち専用のAIエージェントがほしい」といった要望を実現するには、従来はAI技術の専門家に依頼したり、LangChainなどのライブラリを使ってプログラミングによる開発したりしなければなりませんでした[1]。

しかし今では、GUI上でノーコードやローコードでAIエージェントを作れるツールやサービスがどんどんリリースされています。代表的なものを以下に挙げます。

OpenAI GPTs
Google Cloud: Vertex AI Agent Builder
Microsoft Copilot Studio
IBM watsonx Orchestrate
Dify.AI

こうしたAIエージェント開発ツールは大きく2種類のアプローチに分かれます。

RAGベース
ワークフローベース

それぞれのアプローチについて見ていきましょう。

RAGベースのAIエージェント開発アプローチ

RAG（Retrieval Augmented Generation）は、データベースから検索した適切なコンテキストを使って、LLM で回答を生成する手法全般です（本書50節⁠）⁠。高精度なLLMは一般的な知識ならかなりよく知っていますが、専門的な知識や特定の製品の情報は必ずしも知りませんし、社内限定の情報などは当然持っていません。そうした知識をRAGで与えることで、LLMの外の知識を使った回答を行うカスタムAIを作成できます。

RAGベースのAIエージェントを作成するツールとして最も代表的なのがOpenAI GPTsです（本書5節⁠）⁠。GPTsでは、プロンプトとデータソースを指定してAIエージェントを作成できます。必要に応じて外部サービスを呼び出す機能もついています。GPTsはユーザーの多いChatGPT内でAIエージェントを共有できるため、最も利用者が多いAIエージェントの仕組みと言えるでしょう。

RAGはコンテキストの候補となるデータがあれば構築できるため、データを蓄積するタイプのアプリケーションと好相性です。GoogleのNotebookLMは、GoogleドライブやGoogleドキュメントを前提としたRAGベースのAIエージェントツールと考えることができます。また手前味噌ながら筆者の属するサイボウズでも、クラウドアプリ開発サービスのkintoneにRAGベースのAIエージェント作成ツールを準備しています。

RAGベースのAIエージェントビルダーがあれば、様々な知識に特化したAIエージェントを作れますから、多くの要望に答えられそうです。しかし、AIエージェントへの要望は知識だけではありません。高まるAIへの期待に応えられるような、自由度の高いAIエージェント開発ツールがワークフローベースのアプローチになります。

シナリオベースのチャットボット開発

ここでワークフローベースのAIエージェント開発ツールについて解説したいところですが、その位置づけを理解するために、まずはシナリオベースのチャットボット開発について説明しておきます。

LLMが登場する以前、カスタマーサポートなどで利用されていたチャットボットの多くは、シナリオベースのチャットボットビルダーを使って構築されていました。チャットボットビルダーとは、プログラミング知識の少ない人でもローコード（またはノーコード）で開発できるよう、シナリオをフローチャート形式で記述できるGUIツールを指します。

例えば、オンラインショッピングで注文状況を確認するチャットボットをシナリオベースで開発する場合、以下のような会話が想定されます。チャットボットビルダーでは、このような会話シナリオをフローチャート形式で記述することでチャットボットを構築できます。

ユーザー：「注文状況を知りたい」
チャットボット：「注文番号を教えてください」
ユーザー：「1234567890です」
チャットボット：「注文番号1234567890の配達状況は『出荷準備中』です。配達予定日は12月3日です」

ユーザーがこのシナリオに常に完全に沿ってくれればいいですが、「⁠注文番号がわからない」と言うかもしれません。その場合を考えると、注文を検索するシナリオに分岐する必要があります。あるいは最初の一言が「先週の水曜に注文した商品はどうなっていますか？」だったりすることもあるでしょう。これらの可能性や表記揺れをできる限り網羅していくだけでも、シナリオは膨大に枝分かれしていきます。

この例からも、シナリオベースのチャットボットは特定の問い合わせや手順が明確なサポート業務に適していますが、ユーザーの質問や表現が少しでも異なると対応できなくなるなど、柔軟性に乏しいという問題があることがわかります。

ワークフローベースのAIエージェント開発アプローチ

ワークフローベースのAIエージェント開発ツールは、イメージとしてはシナリオベースのチャットボット開発ツールの部品にLLMを追加したものになります。ワークフローベースでは、一般にRAGも部品の1つとして搭載されており、機能的にはRAGベースの上位互換になります。

LLMの搭載により自然な応答文を生成できるだけでなく、シナリオの分岐などの判断をLLMに任せられるようになり、チャットボットの汎用性が大きく高まりました。これまでなら表記揺れや省略に対応するために記述していた膨大なホワイトリストやルールもLLMに任せられるようになりました。また、すでにシナリオベースのチャットボット開発ツールを提供していたサービサーは以下のように、LLMの部品を追加するだけでそうした価値を提供できます。

Vertex AI Agent BuilderによるChat Botの作り方

ワークフローベースのAIエージェント開発ツールの多くはノーコードやローコードを謳っているものの、実際には、プログラミングを完全に避けるよりも、プログラミングにある程度頼ったほうがワークフローがシンプルになって構築しやすいです。これはAIエージェントの開発ノウハウがまだまだ整備中であることも大きな要因の1つと考えられます。今後レシピやベストプラクティスが整っていき、開発ツールもそれにあわせて拡張されれば解消されていくのかもしれません。しかし一般に、人間の要望もどこまでも大きくなっていくため、開発ツールの自由度を超えてしまう……ということにもなりそうです。

ところで、RAGベースでもそれなりのカスタムAIを構築することは十分可能なのに、ワークフローベースのような高い自由度があってもしょうがないのではないか、という疑問を持つ人もいるかもしれません。AIエージェントがどの程度の自由度を必要かを示す好例として、2024年の東京都知事選に出馬された安野たかひろ氏の質疑応答システム「AIあんの」を紹介しましょう。

【都知事選2024】AIによるマニフェストへの質疑応答システム「AIあんの」の裏側を公開します！

「AIあんの」は、安野たかひろ氏の政策に関する意見や質問に対して回答するAI応答システムです。この「AIあんの」も、マニフェストなどのドキュメント（LLMの外部知識）に基づいて回答する部分は一般的なRAGで構成されています。さらに、選択した情報に紐付く画像を取得したり、AIの生成した回答が誤っていたり不適切であったりした場合に回答を行わない判断が組み込まれています。

この「AIあんの」自体はプログラミングによって構築されたものでしょうが、ワークフローベースのAIエージェントビルダーはこのようなロジックを必要に応じて組み込めることがポイントです。

AIエージェントに現在/今後求められる機能

AIエージェントはLLM技術によって大きく発展しましたが、現場で直接的に強く求められる技術であるからこそ、今後もかなり速いペースでさらなる発展を遂げることが予想されます。今後のAIエージェントに必須とされるであろう機能として、以下の3つが考えられます。

ガードレール
ハルシネーション対策
推論（Reasoning）

ガードレール

ガードレールとは、プロンプトインジェクション（本書51節）などの攻撃に対し、AIが不適切な応答をしないための仕組みです。特にAIエージェントを一般向けのサービスとして公開する場合には、こうした対策が必須となります。

例えば差別やアダルト系などの質問や回答を抑制するには、OpenAIのModeration API（本書48節）などのあらかじめ用意された分類フィルタが有効です。これらのフィルタは文章を「ハラスメント」や「暴力」などのラベルに分類される確率を高速に出力してくれます。AIエージェントへの入力文をチェックし、これらの危険なラベルに分類された場合は定型のお断り文を出力することで一定の対策が可能になります。

しかし例えば自社製品に関するサポートAIを公開した場合に、全く関係ないサービスや、自社にない製品に関する質問に間違って答えてしまうケースを抑制するにはそうした出来合いのフィルタでは間に合わないので、自前のガードレールを作成する必要があります。簡単にはLLMに「この文章は自社の製品に関する回答になっていますか？」といったプロンプトで判断させるという方法があります。

また、複数のLLMに回答を生成させるときに、異なるペルソナを割り当てるようなプロンプトにしたり、そもそものLLMのモデルを変更したり（1つは GPT-4o、もう1つは Gemini のように）といったことも可能です。アニメ『新世紀エヴァンゲリオン』のMAGIシステム（3賢者に見立てたAIの合議制で判断を行うシステム）を思い出す人も多そうですね。

やはりワークフローベースの強みは、こうした工夫を非専門家であっても試行錯誤しながら実現できる可能性がある点になるでしょう。

ハルシネーション対策

ハルシネーションはAIが誤った情報や論理を返す現象です（本書53節⁠）⁠。特に生成AIの間違いは、文章は流暢なのに、全体を通じてみると間違っているというパターンが多いです。AI自身からみても、正しい文章の生成と間違った文章の生成を区別できないので、発見が難しくなっています。

ハルシネーションの対策や検出はさまざまに研究されていますが、現在の技術でできるハルシネーション対策の一例として、回答を複数回生成して、それらの回答間に矛盾がないかを確認するというアプローチがあります。実はハルシネーションが起きるときは、同じプロンプトであっても生成される回答が毎回異なる（出力のばらつきが大きい）傾向が知られています。そのため、複数の回答が異なっていればハルシネーションの可能性が高いとわかるわけです。ワークフローベースであればこうした工夫も可能です。

LLMによる推論（Reasoning）

そしてAIエージェントの発展の要素技術として、もう一つの大きなポイントはLLMによる推論（Reasoning）です。ちなみに、機械学習の学習済みモデルを使った予測も同じく「推論」と呼ばれますが、そちらは英語では"Inference"です。"Reasoning"のほうの「推論」は、知識や論理を使って思考する（ように振る舞わせる）ことを指します。

現在のAIエージェントでも（自律エージェントもカスタムAIも⁠）⁠、LLMによる推論は重要な要素となっています。例えば、例示や思考の手順を指定することでLLMに考えさせるChain of Thought（CoT）はLLMによる推論の典型例です。LLMに文章の分類を行わせる場合に、分類結果のみを出力させるのではなく、「⁠そのカテゴリーに分類すべき理由も併記してください」などのように理由を記述させるようにしたほうが精度が上がるのも推論と言えます。前述のワークフローの中で「自社の製品に関する回答かどうか」を判断させるのも、推論の一例です。

また2024年9月にリリースされたOpenAI o1は、LLMに推論を行わせ、その出力をまたLLMに入力して推論を繰り返させることで、ユーザーの目的や解くべきタスクを自律的に推測させて、論理的な回答の精度を大きく高めました。

LLMによる推論は当初から活用されていますが、従来はChatGPTのようなチャットAIが生成する回答文の中で推論を促していたのに対し、AIエージェントでは回答の裏側で推論を行わせて、その過程は必ずしも表に出てこない点が異なります。それはつまり、LLMによる推論を活用して賢くなるほど、回答の表示が始まるまでに時間がかかるようになるということです。

インターネットに代表されるIT技術のほとんどは速くて正確であることがとても重要視されてきましたが、ChatGPTはある程度以上に賢ければ遅くて正確でなくても良いという価値観の転換を起こしました。ただ遅いとは言っても、回答の表示はすぐ始まってましたから、読む速度以上で表示されれば待ち時間をあまり意識せずに済みました。

LLMによる推論を活用するには、「⁠より賢くなるなら、待ってもいい」という価値観の転換をもう一度起こす必要があるわけです。そのためには、ユーザに待ち時間を許容して貰う必要があります。OpenAI o1 では、推論の要約を逐次表示することで、「⁠待ち時間＝AIが考えている時間」であることをユーザーに伝える工夫をしています。また今後のAIエージェントでは、人間が使うフィラー（⁠「⁠えっと」「⁠あの～」など）や、定型の挨拶と確認を兼ねたオウム返し（⁠「⁠ご質問ありがとうございます。『⁠～』に関するご質問ですね」など）といった推論の時間稼ぎを行うものもきっと出てくるでしょう。

他にも、LLMによる推論を超高速化するという力技な解決方法もあります。Groq社のLPU（Language Processing Unit）は、トランスフォーマーのデコーダーに特化した独自チップを設計し、8Bモデルなら1秒間に1200トークン、70Bモデルでも1秒間に300トークンという高速性を実現しています。AIチャットのためだけなら正直ここまでの性能はいりませんが、AIエージェントに推論を行わせるなら速ければ速いほど有利です。

まとめ

AIエージェント（カスタムAI）は、LLMを活用したRAGやワークフローベースのAIエージェント開発ツールによって、AIの専門知識がなくても特定のニーズに対応するカスタムAIを簡単に作れるようになってきました。ハルシネーションなどの課題はまだ立ちはだかっていますが、今後、LLMを使った推論（Reasoning）の技術が更に発展し、これらのツールでも気軽に使えるようになって、AIエージェントの課題の解消と、より賢いAIの実現が進むだろうと思われます。