LLM、RAG、プロンプト、AIエージェント、MCP、Tool Executor。次々と新しい言葉が出てくるけれど、一つひとつは何となく分かっても、全体がどうつながっているのかが見えにくい。自分もしばらくそうだった。
そこでこの記事では、これらを1本の線で並べ直してみます。LLMが言葉を扱う仕組みから、指示で回答が変わる理由、外部知識を足すRAG、目標を自分でこなすAIエージェントの中身まで、順番に。全体は次の6章です。
・LLMの学習 :LLMは、どうやって鍛えられるのか
・LLMの利用 :LLMは、どうやって答えているのか
・プロンプト手法の代表例として8種類を紹介 :指示の書き方で回答はどう変わるのか
・RAG :LLMに外の知識を持ち込む仕組み
・AIエージェントの動き方(工程) :目標を達成するまでの流れ
・AIエージェントの部品(構造) :その動きを支える部品たち
どこから読んでも通じますが、通しで読むと生成AIの全体像がつながって見えるはずです。
LLMの学習
LLMは、どうやって言葉を扱えるようになるのでしょうか。Webの膨大なテキストを読み込むだけで、あの流暢な回答が返ってくるわけではありません。大量のデータからモデルを鍛え、指示に従わせ、安全に応答できる状態へ仕上げるまでを、9つのステップで並べます。
Training Data(学習データ)
LLMの学習に使う、大量のテキストデータです。Webページ、書籍、論文、ニュース、プログラムコードなど、さまざまな情報源から収集されます。LLMの言語能力や知識は、この学習データが土台になります。
Data Preparation(データ準備)
収集したデータを、そのまま学習に使うわけではありません。重複した文章や品質の低いデータ、不適切な情報などを除去し、学習に適した形へ整えます。最後に文章をTokenへ分割し、モデルが処理できる形式へ変換します。
Pre-training(事前学習)
整えた大量のデータを使い、文章の次に続くTokenを予測する学習を繰り返します。この過程で、モデルは文法や言葉の使い方、文章の構造、さまざまな分野の知識などを身につけます。学習結果は、モデル内部の大量のパラメーターに反映されます。
Base LLM(基礎モデル)
事前学習を終えた、LLMの基礎となるモデルです。汎用的な言語能力や知識を持っていますが、まだユーザーの指示へ適切に回答するようには十分に調整されていません。質問への回答ではなく、入力された文章の続きを生成するような動作をすることもあります。
SFT/Instruction Tuning(指示学習)
「質問と望ましい回答」や「指示と模範回答」の組み合わせを使って、BaseLLMを追加学習します。これにより、単に文章の続きを生成するだけでなく、ユーザーの指示を理解し、求められた形式や内容で回答する能力を身につけます。
Alignment(アライメント)
モデルの回答を、人の意図や選好、方針に沿うように調整する工程です。RLHF/RLAIF/DPOなどの手法を使い、より役に立ち、安全で、望ましい回答を生成できるようにします。SFTが「指示に従う力」を加える工程なら、Alignmentは「どのような回答が望ましいか」を学ばせる工程です。
・RLHF(ReinforcementLearningfromHumanFeedback)
人が複数の回答を比較・評価し、その評価を基に報酬モデルを作ります。そして、評価の高い回答を生成できるよう、強化学習によってLLMを調整する方法です。
・RLAIF(ReinforcementLearningfromAIFeedback)
人の代わりにAIが回答を評価し、そのフィードバックを基にLLMを調整する方法です。人による評価の一部をAIで補うことで、評価にかかる負担を軽減できます。
・DPO(DirectPreferenceOptimization)
「望ましい回答」と「望ましくない回答」の組み合わせを使い、望ましい回答を選びやすくなるようLLMを直接調整する方法です。RLHFのように独立した報酬モデルを作って強化学習するのではなく、選好データから直接学習します。
Evaluation/Safety Testing(評価・安全性テスト)
学習したモデルの品質と安全性を確認します。回答の正確性、指示への追従性、安全性、偏り、望ましくない出力などを評価し、実際のサービスで利用できる水準に達しているかを検証します。問題が見つかった場合は、データや学習方法を見直して再調整します。
Instruct/Aligned LLM(調整済みモデル)
SFTやAlignmentを経て、ユーザーの指示に従い、対話形式で回答できるようになったモデルです。BaseLLMが言語能力と知識を身につけた基礎モデルであるのに対し、Instruct/Aligned LLMは、人が利用しやすいように振る舞いを調整されたモデルです。
Deployment(提供開始)
完成したモデルを、チャットサービスやアプリケーション、APIなどから利用できる環境へ配置します。実際の運用では、提供後も利用状況や回答品質、安全性、性能、コストなどを継続的に監視し、必要に応じて改善します。
LLMの利用
学習を終えたLLMは、質問を投げれば答えが返ってくるだけの箱に見えます。実際にやっているのは、入力を整え、Tokenに分け、次の言葉を確率で選び続ける、という地道な繰り返しです。その一連を工程ごとに見ていきます。
User Input(ユーザー入力)
ユーザーがLLMに送る質問や指示です。単純な質問だけでなく、文章の作成、要約、分析、翻訳など、LLMに実行してほしい内容が含まれます。この入力が、回答を生成する処理の出発点になります。
Context Assembly(コンテキストの組み立て)
LLMが回答を生成するために必要な情報をまとめる工程です。ユーザーの入力だけでなく、システム側の指示、過去の会話、RAGで取得した情報、外部ツールの実行結果などを組み合わせ、LLMへ渡すコンテキストを作ります。
System Prompt(システムプロンプト)
LLMの役割、基本的な動作、守るべきルールなどを指定する情報です。例えば、「初心者向けに説明する」「指定された形式で回答する」「特定の情報は回答しない」といった、LLM全体の振る舞いを制御します。
User Prompt(ユーザープロンプト)
ユーザーが入力した質問や指示です。LLMは、System Promptで指定されたルールに従いながら、User Promptに対する回答を生成します。
Few-shot Examples(回答例)
LLMに期待する入力と回答の例です。いくつかの例をコンテキストに含めることで、回答の形式、文体、判断方法などをLLMに示します。モデル自体を追加学習させるのではなく、その場の入力を使って望ましい回答へ誘導します。
Chat History(会話履歴)
ユーザーとLLMが、それまでにやり取りした内容です。過去の質問や回答をコンテキストに含めることで、前の会話を踏まえた回答や、話題の続きに対応できるようになります。
Retrieved Data(検索で取得した情報)
RAGなどの検索処理によって取得された外部情報です。社内文書、マニュアル、データベース、Web情報などから質問に関連する情報を取得し、LLMへ渡します。これにより、LLMは学習時に持っていなかった情報や、最新・組織固有の情報を参照して回答できます。
Tool Results(ツールの実行結果)
検索、計算、API、データベースなど、外部ツールを実行して得られた結果です。LLMが推測だけで回答するのではなく、ツールから取得した情報をコンテキストに加えることで、より具体的な回答や処理結果を返せるようになります。
補足：Context Window(文脈長の上限)
LLMが一度に処理できるTokenの上限です。System Prompt、User Prompt、Few-shot Examples、Chat History、Retrieved Data、Tool Resultsをすべて足したものが、この上限に収まっている必要があります。
Context Windowを超えた情報はLLMへ渡せません。会話が長くなると古い履歴が切り捨てられ、RAGで大量の情報を取得しても、すべてを一度に参照させることはできません。RAGでChunkingを行い、必要な情報だけを選んで渡す理由もここにあります。
モデルによってContext Windowの大きさは異なります。上限が大きいモデルほど多くの情報を一度に扱えますが、その分だけ処理コストや応答時間も増える傾向があります。
Tokenization(トークン化)
組み立てたコンテキストを、LLMが処理できるTokenへ分割します。LLMは文章をそのまま理解するのではなく、単語や文字の一部などに相当するTokenの並びとして処理します。
LLM Inference(推論)
Token化されたコンテキストをLLMへ入力し、次に続くTokenの確率を計算する工程です。
この確率計算を担うのがTransformerと呼ばれる仕組みで、文中のどの語がどの語に関係するかを見ながら、次のTokenを予測します。事前学習や追加学習で獲得したパラメーターを使い、入力内容に対してどのTokenが続く可能性が高いかを予測します。
Token Generation(トークン生成)
LLM Inferenceで計算された候補から、次に出力するTokenを選択します。選択したTokenをコンテキストへ追加し、再び次のTokenを予測します。
この処理を繰り返すことで、Tokenが一つずつ生成され、最終的に文章になります。LLMは回答全体を一度に作るのではなく、前に生成したTokenを踏まえながら、続きのTokenを順番に生成します。
補足：サンプリングパラメータ(生成の揺らぎを調整するパラメータ)
Token Generationでは、LLM Inferenceが計算したTokenの確率分布から、次に出力するTokenを選びます。このとき、どのように選ぶかを調整するのがサンプリングパラメータです。同じ入力でも、パラメータの設定によって回答の傾向が確率的に変わります。
・Temperature(温度)
確率分布の鋭さを調整します。値を低くすると確率の高いTokenが選ばれやすくなり、回答が安定し、事実確認や定型的なタスクに向きます。値を高くすると幅広いTokenが選ばれやすくなり、回答に多様性が出て、アイデア出しや文章生成に向きます。
・Top-p(核サンプリング)
確率の高い順にTokenを並べ、累積確率がpに達するまでの範囲だけを候補にします。例えばTop-p=0.9なら、上位90%の確率を占めるTokenだけが候補になります。極端に確率の低いTokenが選ばれることを防げます。
・Top-k
確率の高い上位k個のTokenだけを候補にします。例えばTop-k=50なら、確率上位50個のTokenの中から選びます。Top-pよりも単純で、候補数を明示的に制限したい場合に使います。
Response(回答)
生成されたTokenを、人が読める文章へ戻してユーザーに返します。利用するシステムによっては、回答本文だけでなく、引用元、参照情報、構造化データ、ツールの実行結果などが一緒に表示される場合もあります。
プロンプト手法の代表例として8種類を紹介
「記事を書いて」と「読者を情シス担当に絞って、構成案から出して」では、同じLLMでも返ってくるものがまるで違います。モデルを鍛え直さなくても、聞き方だけで精度も論理の深さも変わる。実務でよく使う8つの手法を、具体例つきで並べます。
| 場面 | 推奨手法 |
|---|---|
| まず試す | Zero-shot |
| 出力形式を揃えたい | Few-shot / Dynamic Few-shot |
| 論理的に考えさせたい | CoT / Plan-and-Solve |
| 手順を守らせたい | Step by Step |
| 品質を自己改善させたい | Self-Refine |
| ツールと連携させたい | ReAct |
Zero-shot Prompting
タスクの説明だけでAIに回答を生成させるプロンプト手法です。シンプルな指示で実行でき、多くの場面で最初に試すアプローチとして利用されています。
Copilotを導入する企業向けに、ブログ記事の構成案を作成してください。
読者は情報システム部門の担当者を想定してください。
Few-shot Prompting
入力例と期待する出力例をいくつか提示し、それを参考に回答を生成させるプロンプト手法です。出力形式や文体、回答品質の安定化に効果があります。
以下のような形式で、Copilotを導入する企業向けのブログ記事構成案を作成してください。
タイトル:Copilot導入前に整理すべき3つの観点
構成:
1.なぜ事前整理が必要なのか
2.ライセンスと利用者の整理
3.セキュリティと運用ルール
4.導入後に見直すポイント上記の形式を参考に、Copilot向けの記事構成案を作成してください。
Dynamic Few-shot Prompting
入力内容に応じて最適なサンプルを自動的に選択し、それを参考に回答を生成させるプロンプト手法です。多様なタスクに対する精度や柔軟性の向上に効果があります。
あなたはIT技術ブログ作成支援AIです。
Copilotに関する記事構成案を作成してください。ただし、回答する前に、過去の記事サンプルの中から今回のテーマと最も類似する3件を選択してください。
選択したサンプルを参考に、
・タイトルの付け方
・見出し構成
・記事の流れを踏襲したうえで、新しい記事構成案を作成してください。
過去記事:[記事DB]
Chain-of-Thought
複雑な問題を中間的なステップに分け、段階的に推論させるプロンプト手法です。最終的な結論だけでなく、判断の根拠や主要な検討ステップを示させることで、回答の妥当性を確認しやすくなります。
Copilotを導入する企業向けに、ブログ記事の構成案を作成してください。
最初に重要な検討観点を整理し、それぞれの判断理由を簡潔に示したうえで、最終的な構成案を提示してください。
Step by Step
タスクを段階に分けて、一つずつ順番に実行させるプロンプト手法です。作業手順を明示することで、複雑なタスクでも安定した回答を得られる効果があります。
Copilotを導入する企業向けのブログ記事構成案を作成してください。
一度に完成形を出すのではなく、次の順番で進めてください。Step1:想定読者を整理する
Step2:読者の課題を整理する
Step3:記事で伝えるべきメッセージを決める
Step4:見出し構成を作成する
Step5:最後にタイトル案を3つ出す
Self-Refine
AIが生成した回答を自ら評価し、改善点を見つけながら繰り返し修正を行うプロンプト手法です。回答の品質や完成度の向上に効果があります。
Copilotを導入する企業向けのブログ記事構成案を作成してください。
その後、次の観点で自己レビューしてください。
1.初心者に分かりやすいか
2.技術的に浅すぎないか
3.導入検討者が読みたい流れになっているか
4.タイトルと見出しに一貫性があるかレビュー結果を踏まえて、改善版の構成案を作成してください。
Plan-and-Solve
問題を解く前に実行計画を立て、その計画に沿って段階的に問題を解決するプロンプト手法です。複雑なタスクを整理しながら進めることで、回答精度の向上に効果があります。
Copilotを導入する企業向けのブログ記事構成案を作成してください。
進め方は次の通りです。Phase1:計画立案
・記事作成に必要な作業を洗い出す
・作業の順番を決める
・各作業の目的を明確にするPhase2:計画の実行
・立案した計画に沿って、順番にタスクを実行する
・各ステップの成果物を明示する最後に、完成したブログ記事の構成案を提示してください。
ReAct
推論と行動を交互に繰り返しながら問題を解決するプロンプト手法です。必要に応じて検索やツール実行を行い、得られた結果を基に次の判断を行います。外部ツールと連携する複雑なタスクの実行に効果があります。
Copilotを導入する企業向けのブログ記事構成案を作成してください。
次の流れを繰り返してください。
1.構成案を作るために不足している情報を判断する
2.利用可能な検索ツールを使い、Microsoftの公式情報を確認する
3.取得した情報を確認し、追加調査が必要か判断する
4.必要であれば検索条件を変えて再度調査する
5.十分な情報がそろったら、根拠となる公式情報を示して記事のタイトル案と見出し構成を作成する
RAG(Retrieval-Augmented Generation)
LLMは、学習した時点の知識しか持っていません。昨日の社内通達も先週更新したマニュアルもモデルの中には無いので、聞かれるとそれらしい嘘で埋めてしまうことがあります。これをモデルの再学習なしで補うのがRAGです。
このように、LLMが事実とは異なる情報を、もっともらしい文章で生成してしまう
現象をHallucination(ハルシネーション、幻覚)と呼びます。文法的に自然で、
口調にも自信があるため、読み手が誤りに気付きにくいのが厄介な点です。
学習時点に含まれていない情報、組織固有の情報、最新の情報を尋ねたときに発生
しやすくなります。
RAGは質問に関連する情報を外部データから検索し、その結果を添えてLLMに渡す
ことで、Hallucinationのリスクを下げる代表的な方法です。
さらにRAGには次のような利点があります。
・ドキュメントと検索Indexを更新するだけで、モデルを再学習させずに新しい
情報を回答へ反映できる
・回答に出典を添えることで、透明性や監査性を高められる
・検索時に適切な権限フィルタを実装することで、アクセス権に応じて検索結果を
制御できる
ここまで読んでお気づきの通り、RAGの回答品質を大きく左右するのが「検索」です。
渡す情報がズレれば、答えもズレる。ではその検索の裏側では何が動いているのか?RAGでこの検索を担当するパートはRetriever(検索係)と呼ばれ、その中では性格の違う2つの検索方式[キーワード検索]と[ベクトル検索]が使われています。
RAGのデータ登録の流れ
RAGは、質問が来る前の下ごしらえで半分決まります。文書をそのまま置くのではなく、読み取って、分割して、意味を数値にして、Indexに載せる。この仕込みを5工程で見ます。
Document(文書)
RAGで検索対象とする元のデータです。PDF、Word、Webページ、社内マニュアル、製品ドキュメントなどが該当します。RAGでは、これらの文書をLLMへそのまま渡すのではなく、必要な情報を検索できる状態へ加工します。
Parsing(解析・テキスト抽出)
文書を読み取り、検索やLLMへの入力に使える形式へ変換する工程です。本文だけでなく、見出し、表、ページ番号などの構造も可能な範囲で抽出します。スキャンされたPDFや画像を含む文書では、OCRによって文字を読み取る場合もあります。
Parsingが適切に行われないと、元の文書に情報が書かれていても、後の検索で見つけられない可能性があります。
Chunking(分割)
Parsingで抽出したテキストを、検索しやすい大きさへ分割する工程です。分割された一つひとつの単位をChunkと呼びます。
文書全体を一つのデータとして登録すると、検索結果に不要な情報が多く含まれます。一方で、細かく分割しすぎると文章の前後関係が失われます。そのため、見出しや段落などを基準に、意味が保たれる適切な大きさへ分割します。
Embedding(ベクトル化)
各Chunkの内容を、意味的な特徴を表す数値の並びであるVectorへ変換する工程です。
文章をVectorへ変換することで、質問と文書で使われている単語が完全に一致しなくても、意味の近い情報を検索できます。例えば、「リモート勤務のルール」という質問から、「在宅勤務に関する規定」を見つけやすくなります。
なお、Embeddingはベクトル検索で使われる処理です。キーワード検索だけを使う構成では必須ではありません。
Indexing(索引への登録)
Chunk、Vector、Metadataなどを、検索可能な状態でSearch IndexやVector Storeへ登録する工程です。Metadataには、元の文書名、見出し、ページ番号、更新日、参照元、アクセス権などを含められます。これにより、検索対象の絞り込み、参照元の表示、権限に応じた検索結果の制御が可能になります。
RAGのデータ利用の流れ
仕込みが終われば、あとは本番です。質問を受け、Indexから関連情報を引き、LLMに渡して答えを組み立てる。ユーザーの質問が根拠つきの回答に変わるまでを、6工程で。
User Query(ユーザーの質問)
ユーザーがRAGシステムへ入力する質問や指示です。例えば、「在宅勤務の申請方法を教えてください」といった質問が、検索と回答生成の出発点になります。
Query Processing(検索クエリの加工)
ユーザーの質問を、検索しやすい形へ整える工程です。質問から重要なキーワードを抽出したり、曖昧な表現を書き換えたり、複雑な質問を複数の検索クエリへ分解したりします。ベクトル検索を利用する場合は、質問をEmbeddingによってVectorへ変換します。
Retrieval(検索)
検索用のIndexから、ユーザーの質問に関連するChunkを探す工程です。検索には、単語の一致を調べるキーワード検索、意味の近さを調べるベクトル検索、両方を組み合わせるハイブリッド検索などが使われます。必要に応じて、MetadataによるFilteringや、検索結果を関連度順に並べ直すRerankingも行います。
Retrieved Data(取得した情報)
Retrievalによって取得された、質問に関連する文書の一部分です。例えば、「在宅勤務の申請方法」という質問に対して、社内規定から申請条件や手順が記載されたChunkを取得します。この情報はLLMへ再学習されるのではなく、回答を生成するときだけ参照されます。
Context Assembly(コンテキストの組み立て)
ユーザーの質問とRetrieved Dataを組み合わせ、LLMへ渡すContextを作る工程です。必要に応じて、System Prompt、会話履歴、回答方法の指示、参照元なども追加します。「取得した情報を根拠に回答する」「情報が見つからない場合は推測しない」といったルールも、この段階で組み込みます。
LLM Inference(LLMによる推論)
組み立てたContextをLLMへ入力し、回答を生成する工程です。LLMは、学習済みの言語能力を使いながら、Retrieved Dataの内容を参照して、次に続くTokenを順番に予測します。検索した情報はLLMへ再学習されるのではなく、その回答を生成する間だけContextとして利用されます。
Grounded Response(根拠に基づく回答)
検索で取得した情報を根拠として生成された回答です。必要に応じて、文書名、ページ番号、URLなどの参照元も表示します。これにより、ユーザーは回答の根拠を確認しやすくなります。ただし、検索結果を使ったからといって回答が必ず正しくなるわけではないため、検索精度や取得情報の品質も重要です。
RAGの回答品質を決める主役は、実は「検索」です。
どれだけ優秀なLLMを使っても、渡す情報がズレていれば、答えもズレます。
ここからは、RAGの検索を支える2つの方式(キーワード検索とベクトル検索)と、両者を束ねるRRFという合流点を、順番に見ていきます。
キーワード検索(TF-IDF/BM25)
単語の厳密一致で探すため、型番/SKU/エラーコード/固有名詞に強いのが最大の強み。TF-IDFの重み付けで「ください」などの汎用語は自動的に弱まり、特徴語で精度を保てる。
一方で、表記ゆれ/同義語/言い換えには弱く、「Copilotの使い方」で「AIアシスタントの利用方法」を取りこぼす。
ここでは仕組みを分かりやすくするためにTF-IDFを使って説明します。実際の検索サービスでは、文書の長さや単語の出現回数を調整したBM25なども広く使われています。
例：検索クエリ[Copilot 料金]の場合
| DocID | 内容 |
|---|---|
| Doc1 | Copilot の使い方と Copilot の活用法を教えてください |
| Doc2 | Copilot の 料金 プランと 料金 比較を教えてください |
| Doc3 | Cowork の 料金 プランを教えてください |
TFの計算：文章の中で、その単語がどのぐらい出てくるのか
| 単語 | Doc1 | Doc2 | Doc3 |
|---|---|---|---|
| Copilot | 2回 | 1回 | 0回 |
| 料金 | 0回 | 2回 | 1回 |
IDFの計算：その単語が、全文書のうち何件(Docs)に登場するか。希少性が高いほど１に近い
どこにでも出る語は、[IDF=0]で無視される
| 単語 | 登場文書数 | IDF(全3件で計算) |
|---|---|---|
| Copilot | 2件 | log10(3/2) ≒ 0.18 |
| 料金 | 2件 | log10(3/2) ≒ 0.18 |
| ください | 3件 | log10(3/3) = 0(全部に出るので無価値) |
Doc2「Copilotの料金プラン」が最上位にランクされる。
| 文書 | Copilot(TF×IDF) | 料金(TF×IDF) | 合計スコア |
|---|---|---|---|
| Doc1 | 2 × 0.18 = 0.36 | 0 | 0.36 |
| Doc2 | 1 × 0.18 = 0.18 | 2 × 0.18 = 0.36 | 0.54 🏆 |
| Doc3 | 0 | 1 × 0.18 = 0.18 | 0.18 |
ベクトル検索
意味の近さで探せるため、言い換えや表記ゆれに強く、「AIアシスタント」で「Copilot」もヒットさせられるのが最大の強み。一方で、型番や社内固有名詞など厳密な一致が求められる語には弱く、意味的に似た別文書を上位に返してしまうことがある。曖昧な自然文の質問には強いが、ピンポイント検索には不向き。
例：検索クエリ[Copilotの使い方]の場合
| DocID | 内容 |
|---|---|
| Doc1 | Copilotの使い方を教えてください |
| Doc2 | AIアシスタントの利用方法を知りたい |
| Doc3 | 有給休暇の申請方法を教えてください |
AI(埋め込みモデル)が、各文章を数値の並び(ベクトル)に変換します。
※意味が近い文章ほど、数値のパターンが似るように学習されています。
| 文章 | ベクトル(イメージ:3次元に簡略化) |
|---|---|
| クエリ「Copilotの使い方」 | [0.8, 0.7, 0.1] |
| Doc1「Copilotの使い方を教えて」 | [0.8, 0.7, 0.1] |
| Doc2「AIアシスタントの利用方法」 | [0.7, 0.8, 0.2] |
| Doc3「有給休暇の申請方法」 | [0.1, 0.2, 0.9] |
ベクトル同士の近さを計算します。近い=意味が似ているという判定です。
| 文書 | クエリとの類似度 | 判定 |
|---|---|---|
| Doc1 | 1.00(ほぼ一致) | 🏆 最も近い |
| Doc2 | 0.98(かなり近い) | ⭕ 意味的に近い |
| Doc3 | 0.31(遠い) | ❌ 無関係 |
RAGは、両者を組み合わせたハイブリッド検索(RRF)も利用可能
| キーワード検索 | ベクトル検索 |
|---|---|
| 固有名詞に強い | 意味検索に強い |
| 完全一致に強い | 類義語に強い |
| 挙動が説明しやすい | あいまい検索に強い |
| 長文でも安定 | ニュアンスを理解できる |
RRF(Reciprocal Rank Fusion)
キーワード検索とベクトル検索では、スコアの算出方法や尺度が異なるため、単純に足し合わせることができません。そこで、各検索結果のスコアではなく「順位」を使って統合するRRFが利用されます。
RRFでは、各文書に対して以下の式でスコアを計算します。
RRFスコア(d) = 1 / (k + rank(d))
kは定数で、一般的に k=60 が使われます。
両方の検索に登場する文書は、両方のスコアを足し合わせます。
| DocID | キーワード検索順位 | ベクトル検索順位 | RRFスコア計算 | 合計スコア |
|---|---|---|---|---|
| Doc1 | 3位 | 1位 | 1/63 + 1/61 | 0.0323 |
| Doc2 | 1位 | 2位 | 1/61 + 1/62 | 0.0325 |
| Doc3 | 2位 | 3位 | 1/62 + 1/63 | 0.0320 |
AIエージェントの動き方(工程)
チャット型が「答えるAI」なら、AIエージェントは「こなすAI」です。目標を渡すと自分で段取りを組み、ツールを動かし、結果を確かめながら最後までやりきる。その内部でどんな工程が回っているのかを追います。
User Goal(ユーザーの目標)
ユーザーがAIエージェントに達成してほしい目的です。単純な質問だけでなく、「複数の資料を調査して報告書を作る」「条件に合う商品を探して比較する」「問い合わせ内容を確認してチケットを登録する」など、複数の作業を含む目標も対象になります。
通常のチャットが質問に対する回答を主な目的とするのに対し、AIエージェントは、最終的な目標から必要な作業を考え、検索やツール実行を組み合わせながら目標達成を目指します。
Context Assembly(コンテキストの組み立て)
目標を達成するために必要な情報をまとめる工程です。ユーザーの指示、System Prompt、会話履歴、RAGで取得した情報、利用可能なツール、過去の実行結果、現在の進捗などをContextとして整理します。
ここで作られたContextをもとに、AIエージェントは「何を求められているのか」「何が分かっているのか」「何が不足しているのか」を判断します。
Planning/Reasoning(計画・推論)
UserGoalを達成するために、必要なタスクと実行順序を考える工程です。
例えば、「複数の製品を比較して提案書を作る」という目標であれば、製品情報の収集、比較条件の整理、各製品の比較、提案内容の作成といったタスクへ分解します。
すべての手順を最初に決める場合もあれば、実行結果を確認しながら、次の手順を段階的に決める場合もあります。
Action Selection(アクションの選択)
計画に基づいて、次に実行する処理を選ぶ工程です。
LLMだけで回答できるのか、RAGで情報を検索するのか、計算ツールを使うのか、外部システムのAPIを呼び出すのかなどを判断します。利用するツールだけでなく、ツールへ渡す入力内容もこの段階で決めます。
Tool Execution(ツールの実行)
選択したツールを実際に呼び出し、検索、計算、データ取得、ファイル操作、外部システムへの登録などを行う工程です。
Function Callingは、LLMが利用するツールと引数を構造化して指定する仕組みです。MCPやAPI、SDKなどは、AIエージェントが外部のデータや機能へ接続するための手段として利用されます。
ツールを利用する場合は、適切な認証、アクセス権、入力値の検証、実行範囲の制限なども重要になります。
Observation(実行結果の確認)
Tool Executionによって返された結果を確認する工程です。
AIエージェントは、取得した情報や処理結果を読み取り、期待した結果が得られたか、エラーが発生していないか、追加作業が必要かを判断します。
単にツールを実行するだけでなく、実行結果を次の判断へ反映することが、通常のツール呼び出しとAIエージェントの大きな違いです。
State/Memory Update(状態・記憶の更新)
取得した情報、完了したタスク、未完了のタスク、ツールの実行結果などを保存し、現在の進捗を更新する工程です。
Stateは、現在どこまで処理が進み、次に何を行うべきかを管理する情報です。Memoryは、過去の会話や実行結果、必要に応じて保持する情報です。
この更新により、AIエージェントは同じ作業を不必要に繰り返すことを避け、これまでの結果を踏まえて次の処理を進められます。
Evaluation(達成状況の評価)
User Goalを達成できたかを確認する工程です。必要な情報がそろっているか、実行結果が条件を満たしているか、回答や処理内容に問題がないかを評価します。
ここでいうEvaluationは、学習フローにおけるモデル全体の品質評価とは異なります。AIエージェントの実行ループでは、今回の目標に対する進捗や結果を評価する処理を指します。
未達成→Replanning(再計画)
Evaluationの結果、目標を達成できていない場合は、これまでの実行結果を踏まえて計画を見直します。
例えば、必要な情報を取得できなかった場合は検索条件を変更し、ツール実行が失敗した場合は入力値や実行方法を変更します。情報が不足している場合は、別のツールを選ぶか、必要に応じてユーザーへ追加情報を求めます。
再計画後は、ActionSelectionへ戻り、次の処理を実行します。この「実行→確認→再計画」のループが、AIエージェントの中心的な動作です。
達成→FinalResponse/Action(最終回答・アクション)
Evaluationによって目標を達成したと判断した場合は、結果をユーザーへ返します。
情報収集や分析が目的であれば、最終的な回答、要約、比較結果などを提示します。外部システムの操作が目的であれば、処理結果や実行内容をユーザーへ伝えます。
影響の大きい操作では、実行前にユーザーへ確認を求める設計や、人による承認を挟む設計も必要です。
AIエージェントの部品(構造)
ここまでは、AIエージェントの「動き方」を工程として見てきました。ここからは視点を変えて、その動きを支える「部品」を1枚のアーキテクチャ図として整理します。工程と部品では名前が似た用語が出てきますが、前者は「いつ何をするか(動きの順番)」、後者は「誰が担当するか(役割の分担)」を表しています。
LLMは文章の生成や分析に優れていますが、単体では外部システムを操作したり、実行結果を管理しながら仕事を進めたりすることはできません。ファイルを探したり、Teamsに投稿したり、といった実際の作業には手が届きません。使う人がその都度、次の指示を出し続ける必要があります。
AIエージェントは、このLLMを司令塔にすえて、外部のツールやデータと組み合わせ、依頼された仕事を最後までやりきる仕組みです。
主役となるのは2つのレイヤーです。「考える(思考レイヤー)」で段取りを立て、「動く(行動レイヤー)」で外部システムを操作します。この2つを行き来し、必要に応じて知識系(RAG)から情報を引き出しながら、最終的な結果をユーザーへ返します。
次項から、この図に登場する部品を1つずつ見ていきましょう。
LLM(頭脳)
思考レイヤーの中心にいるのがLLM(大規模言語モデル)、エージェントの頭脳です。
仕事は次の4つです。
・推論：依頼の解き方を組み立てる
・意図理解：言葉の裏にある本当の目的を汲み取る
・回答生成：ユーザーに返す文章を作る
・Tool選択：どの道具を使うかを判断する
考えることも、言葉を返すことも、道具を選ぶことも、すべてLLMが引き受ける、と覚えておきましょう。
Memory(記憶)
LLMは優秀ですが、そのままでは会話が終わった瞬間に何もかも忘れてしまいます。それを補うのが「Memory(記憶)」です。役割は次の2つです。
・短期記憶：直前までの会話履歴を保持し、話の流れを踏まえた応答を可能にする
・長期記憶：過去のやり取りや利用者の好みを蓄え、次に呼ばれたときにも活かす
忘れっぽい頭脳に、文脈と経験を持たせる仕組み、と覚えておきましょう。
Planner(段取り)
複雑な依頼を、そのままLLMに投げても上手くさばけません。そこで登場するのが「Planner(段取り)」です。仕事は次の4つです。
・ゴール分解：最終的な着地点を定める
・タスク分解：着地点に至る作業を小さく刻む
・順序決定：実行の順番を組み立てる
・実行計画作成：全体の段取り書を仕上げる
頭脳(LLM)が動き出す前に、道筋を描いてくれる参謀役、と覚えておきましょう。
MCP Client(接続係)
思考レイヤーが「このツールを使おう」と決めても、外部サービスとつながる口が無ければ手は動きません。その入口を担うのがMCP Clientです。仕事は次の3つです。
・MCP Serverへの接続：外部サービスとの通信路を確立する
・Tool一覧と定義の取得：使えるツールをカタログとして揃える
・Toolの呼び出しと結果の受け取り：LLMの依頼を外部が理解できる形式に翻訳する
エージェントと外の世界をつなぐ窓口役、と覚えておきましょう。
Tool Executor(実行係)
窓口から向こう側とつながっても、実際にツールを動かす担当がいなければ話は進みません。そこで働くのがTool Executorです。仕事は次の3つです。
・Tool実行の制御：呼び出しの順序や成否を管理する
・引数組立：必要なパラメータを整えて渡す
・実行結果の整形と返却：戻ってきたデータをLLMが扱える形に仕上げる
決めた作業を、確実にやり遂げる実務担当者、と覚えておきましょう。
おわりに
ここまで、学習・利用・プロンプト・RAG・エージェントと並べてきました。用語を一つずつ追うと生成AIは難しく見えますが、こうして並べると「言葉を扱うLLMを中心に、記憶・検索・道具・段取りが後から足されただけ」だと分かります。
技術はこれからも増えます。でも骨格はしばらく変わらないはずです。次に新しい言葉が出てきても、この並びのどこに入る話かを考えれば、そんなに慌てなくて済みます。
