ほとんどの人はLLMにプロンプトを入力できます。しかし、実際のトラフィックに耐えうる製品に組み込むとなると、それは全く別のゲームになります。チャットウィンドウに文字を打ち込む段階から、本番環境向けのAIをリリースする段階へと進むには、スタックが実際にどのように組み合わさっているかを理解する必要があります。それは魔法ではありません。個別のエンジニアリング課題が連なるパイプラインであり、各レイヤーにはそれぞれ特有の失敗モードが存在します。
言葉を一つ入力した瞬間から、エージェントがタスクを完了する瞬間まで、現代のAIシステムがどのように機能するのかを解説します。
基盤：モデルはどのように考えるか
その核心において、大規模言語モデル（LLM）が行うことはただ一つです。それは「次のトークンを予測すること」です。そのトークンは、次の単語であったり、単語の一部であったり、あるいは記号であったりすることもあります。詩、コード、推論といった他のすべては、その単一のタスクを大規模に行うことで生まれる創発的な振る舞いです。
プロンプトからモデルの回答に至るまでのプロセスは、以下のようになります。
トークン化（Tokenization） は最初のステップです。ニューラルネットワークにとって生のテキストは意味をなしません。そのため、モデルは単語を断片に分割し、各断片を数値にマッピングします。例えば「tokenization」という単語は、3つの別々のトークンになるかもしれません。「New York」というフレーズは、語彙（ボキャブラリー）によって1つまたは2つのトークンになります。これらの数値は恣意的なものではなく、モデルが学習中に習得した固定の辞書に基づいています。
単語が数値になったら、次は意味を持たせる必要があります。エンベディング（Embeddings） は、それらの数値をベクトル（数学的な空間において類似した概念を近くに配置する、浮動小数点値の長いリスト）に変換します。「King」と「Queen」は互いに近くに位置します。「Paris」と「Berlin」は同じグループに属しますが、「Python」や「JavaScript」とは異なる領域に位置します。
しかし、ベクトルだけでは順序が失われてしまいます。位置エンコーディング（Positional encoding） は、文中の各トークンがどこに位置するかをモデルに伝えます。これがないと、「The dog bit the man（犬が男を噛んだ）」と「The man bit the dog（男が犬を噛んだ）」は全く同じものに見えてしまいます。
次に アテンション・メカニズム（Attention mechanism） が登場します。ここでモデルは入力内のすべてのトークンを俯瞰し、次のトークンを予測するためにどれが重要かを判断します。「その会社はいつ設立され、現在は誰が率いていますか？」と尋ねたとき、モデルは「founded」を日付に、「leads」をCEOの名前に結びつける必要があります。アテンションがそれらのつながりを作り出すのです。
これらの操作は、数十にも及ぶ レイヤー（Layers） として積み重なっています。初期のレイヤーは構文を扱い、後半のレイヤーは抽象的な推論を構築します。その中間のどこかで、 フィードフォワード・ネットワーク（Feed-forward networks） が事実に基づいた関連性を保持しています。ここでモデルは、「パリはフランスの首都である」とか「特定のAPIはJSONペイロードを期待している」といった知識を保持しています。これは正確にはデータベースではありませんが、パターンを活性化させる、圧縮された重みのネットワークなのです。
最後に、 デコーディング（Decoding） によって、内部のベクトル表現が人間が読めるトークンへと変換されます。モデルは自分が英語を書いていることを「知って」いるわけではありません。単に、起こりうる数千の次のトークンの候補をランク付けし、停止条件に達するまで、最も確率の高いものを繰り返し選び続けているだけなのです。
RAGレイヤー：モデルに記憶を与える
ベースモデルは、ある時点の状態で凍結されています。その重みはカットオフ日までのインターネット上の情報を捉えていますが、データを入力しない限り、ユーザーのプライベートなドキュメントにアクセスすることはできません。そのため、ほとんどのビジネス業務においてベースモデルはそのままでは役に立ちません。Retrieval-Augmented Generation（検索拡張生成）、いわゆる RAG は、回答の前に参照できる外部ライブラリをモデルに与えることで、この問題を解決します。
コンセプトは単純ですが、実際の実装は非常に繊細です。まず、ドキュメントを取得して チャンキング（Chunking） を行います。100ページのPDFをそのままプロンプトウィンドウに放り込むわけにはいきません。意味を保持しつつ、モデルのコンテキスト制限内に収まるように、段落、セクション、または意味的なブロックへと分割します。
各チャンクは エンベディング・モデル（Embedding model） を通じて、LLM内のトークンと同様にベクトルへと変換されます。これらのベクトルは、完全一致検索ではなく類似性検索のために設計された専用の保存先である ベクトルデータベース（Vector database） に格納されます。ユーザーが質問をした際、そのクエリをエンベディングし、データベースに対して「このベクトルの意味に最も近いチャンクはどれか？」と問いかけます。
ベクトル検索だけでは、完全な一致を見逃すことがよくあります。優れた本番用システムでは、キーワード一致と意味的な類似性を組み合わせた ハイブリッド検索（Hybrid search） を使用します。例えば「SLA-99 compliance」について尋ねられた場合、単に意味が似ているものではなく、文字通りその文字列を含んでいるドキュメントを取得したいと考えます。
検索後、 リランキング（Re-ranking） によってノイズが除去されます。最初の検索では20個のチャンクが返されるかもしれませんが、実際に役立つのは上位の3、4個だけかもしれません。リランカーは関連性をスコアリングし、LLMに渡す前に残りを破棄します。これにより、トークンの節約とハルシネーションの抑制が可能になります。
エージェントレイヤー：行動を起こす
RAGはモデルに「読む」ことを可能にし、エージェントはモデルに「行動」することを可能にします。
エージェントとは、根本的にはループの中に組み込まれたLLMのことです。観察し、推論し、行動し、そして再び観察します。もしエージェントに航空券の予約を依頼した場合、単に予約方法を説明するだけではありません。タスクをステップに分解し、適切な関数を呼び出し、レスポンスを読み取り、それに応じて調整を行います。
ループの仕組みは以下の通りです。Observe（観察）：エージェントは現在の状態（ユーザーのリクエスト、以前のツール呼び出しの結果、エラーなど）を読み取ります。Reason（推論）：LLMは、構造化されたプランを生成したり、定義済みのオプションから選択したりすることで、次に何をすべきかを決定します。Act（行動）：ツールを呼び出します。
ツールは、エージェントが現実世界に働きかけるための手段です。ツールはJSON schemasによって定義され、APIが必要とするパラメータをモデルに正確に伝えます。LLMは任意のHTTPリクエストを生成するのではなく、スキーマの値を埋めていきます。「city: London, units: metric で weather API を呼び出す」といった具合です。もしツールが温度を返せば、エージェントはその情報を...