AIを触っているとよく聞く横文字を、自分なりに整理してみた【前編】

こんにちは！
フロントエンドエンジニアのあまんちゅです。

最近、AIまわりの話題が増えてきて、会話の中に横文字がよく飛び交うようになりました。

LLM、Token、RAG、API、MCP、Prompt、Agent……

どれも「聞いたことはある」「なんとなく知っている気がする」言葉です。
でも改めて「それって何？」と聞かれると、うまく答えられないことも実はけっこうありました。

それを受けて調べてみたこともありましたが、説明を読んでみてもなんとなくしっくりこないこともよくありました。

それはたぶん、定義は分かっても、なぜそれが必要なのかが見えていないからだと思ったので、この記事では、
「その説明、間違ってはいないけど、それだけだと分からない」
と感じた用語を、自分なりに整理してみたいと思います。
辞書的な正確さよりも、腹落ち感を優先しています。

前編では LLM・Token・RAG・API の4つを扱います。
後編ではPrompt・MCP・Agentを整理します。（が、公開までもう少しお待ちください）

LLM（Large Language Model）── 「次の言葉を予測する」

LLMはLarge Language Model、日本語にすると「大規模言語モデル」の略です。
ChatGPTやClaudeの中心にある仕組みがこれです。

Claudeに聞いたらこう説明してくれました。

「次に来る言葉を予測するモデルです」

間違ってはいないのだと思いますが、でも最初にこれを読んだとき、「予測？そんな感じだっけ？」と思いました。

予測というと、天気予報みたいなイメージが浮かびます。
「明日は70%の確率で雨」みたいな話？と思いました。

でも実際にChatGPTやClaudeと話してみると、そんな単純な感じではないですよね。
文脈を理解しているし、複雑な質問にも答えてくれます。

なぜ、「次の言葉を予測するだけ」でここまでできるのか。

ポイントは、「次の言葉を予測する」のに必要な能力が、実はかなり高度だということです。

「今日は天気が____」の次を予測するには、「いい」や「悪い」が来そうだと分かれば十分です。
でも「この関数がうまく動かない理由を____」の次を予測するには、コードの構造やパターンをある程度捉えられないと、自然な続きを出しにくいはずです。

つまりLLMは、大量のテキストから「次の言葉の予測」を繰り返し学ぶことで、
結果として言葉の意味・文脈・論理の構造を体に染み込ませていった、というイメージです。

「予測する」という行為がシンプルなのではなく、「予測できるようになるために必要なこと」が膨大だったからこそ予測できたということのようです。

ここが見えていなかったから、LLMの話を聞いていてもうまく理解できなかったんだ、と思いました。

また、LLMは一度に全部の答えを出すのではなく、1トークンずつ順番に出力しています。
「今日は」→「天気が」→「いい」→「ですね」というように、少しずつ次を選び続けています。
これを踏まえてTokenの話を読むと、より理解が深まると思います。

Token（トークン）── 「AIが読む言葉の単位」

TokenはそのままTokenと表記されることが多い言葉です。
日本語では「トークン」と呼ばれます。

Claudeに聞いたらこう説明してくれました。

「AIがテキストを処理するときの最小単位です」

「最小単位？何かができる回数じゃないの？言葉とか文字のことなの？」と思いました。

ゲームのトークン（コイン）のようなイメージが先に浮かんでしまったのと、「最小単位」と言われても自分の中では、文字とうまく結びつかなかったのが正直なところです。

Tokenが「言葉」や「文字」と違うのはなぜか。

AIがテキストを読むとき、内部ではこんなふうに分割しています。

英語では、1単語がそのまま1トークンになることもあれば、複数のトークンに分かれることもあります。
たとえば「running」が「run」と「ning」に分かれるケースがその一例です。

日本語も同様で、1語がそのまま1トークンになる場合もあれば、もっと細かく分かれる場合もあります。分割のされ方はモデルによって異なります。

なぜ単語や文字そのままじゃないのか。

でも実は逆です。たとえば「running」は「run」と「ning」に分解されます。
「run」を知っていれば「running」を丸ごと覚えなくても意味の一部が分かりますし、見たことのない新しい単語が出てきても、パーツに分解することでなんとなく推測できるようです。
（正直「本当に？」と思いますが、パーツのパターンを大量に学習しているからこそできる、ということのようです。）

LLMが「次のTokenを予測する」と言われているのはこのためで、文字でも単語でもなく、このトークン単位で言葉を読み書きしているというイメージです。

またTokenの数は、AIへの入力・出力の量を測る単位にもなっています。
「このモデルは最大〇〇トークンまで扱えます」という文章を見たことがありますが、それは「一度に読み書きできるテキストの量の上限」の話のようです。

RAG（Retrieval-Augmented Generation）── 「検索してから答える」

RAGはRetrieval-Augmented Generation、日本語にすると「検索拡張生成」の略です。

Claudeに聞いたらこう説明してくれました。

「検索してから答える仕組みです」

「なるほど、でもそんな単純な話じゃない気もするような・・・？」と思いました。

RAGがどう動いているのかが分からないと理解が深まらない気がしました。

なぜ、RAGが必要になったのか。

LLMはとても賢いのですが、知識に限界があります。
学習データに含まれていない情報、たとえば昨日起きたニュース、社内のドキュメント、最新の仕様書などは、そもそも知りません。

さらに困るのが、知らないのに答えようとすることです。
これを「ハルシネーション」と言います。もっともらしいけれど間違っている答えを、自信満々に返してしまう現象です。

そこで考えられたのが、「答える前に、正しい情報を外から渡してあげる」という方法です。
これがRAGの基本的な考え方です。

具体的なフローはこうです。

1. 質問が届く
2. 関連する情報を外部（ドキュメントやWebなど）から検索する
3. その内容をLLMに渡す
4. 「この内容をもとに答えてください」とLLMに指示する
5. 答えが返ってくる

「検索してから答える」というのはその通りなのですが、
本質は「LLMが知らないこと・間違えやすいことを、外から情報を渡すことで補う仕組み」です。

LLMが全部知っている前提ではなく、「必要な情報をそのつど渡せばいい」という発想の転換が、RAGの考え方のポイントだと思いました。

API（Application Programming Interface）── 「窓口」

APIはApplication Programming Interface、日本語にすると「アプリケーションプログラミングインターフェース」の略です。
長いので、そのままAPIと呼ぶことがほとんどです。

Claudeに聞いたらこう説明してくれました。

「サービス同士をつなぐ窓口です」

「窓口」と言われても、そもそも何をしているのかが見えてこなかったので、もう少し掘り下げてみました。

なぜ、APIが必要なのか。

たとえば、自分のWebサービスに地図や決済、天気情報の機能を追加したいとします。
そのとき、相手サービスの内部データやシステムに直接触るのではなく、用意されたAPIを通して必要な情報や機能を利用します。
セキュリティ上の問題もありますし、内部の構造が変わったら直接つないでいた部分が全部壊れてしまいます。

そこで各サービスが「ここからリクエストを送ってくれれば、必要な情報を返しますよ」という入口を用意します。
これがAPIです。

APIのポイントは3つです。

• 内部実装を隠せる：データベースの中身や構造を外から見せずに済む
• 変更に強い：内部が変わっても、入口の仕様さえ守ればつながり続けられる
• 約束だけ守ればいい：「こう送ればこう返ってくる」というルールさえ守れば、誰でも使える

つまりAPIは「窓口」ではあるのですが、
本質は「中身を見せずに、決まった形でやりとりできる約束事」です。

「窓口」という比喩は正しいのですが、
なぜ窓口が必要なのかが見えないと、ありがたさが分かりにくい言葉だと思います。

なお後編で出てくるMCPは、このAPIの考え方をベースに、
AIとツールの接続をさらに統一しようとした仕組みです。APIを理解しておくと、MCPの話もスムーズに入ってきます。

まとめ

後編ではPrompt・MCP・Agentを整理します。公開までもう少しお待ちください！