AIエンジニアが習得すべき30の核心概念

はじめに

今からAIエンジニアを始めると、画面一杯に新しい用語が溢れる：

「RAGでLLMを拡張し、Embeddingでベクトルデータベースに保存し、MCPでツール呼び出しを行い、Few-shot Promptingで出力を最適化…」

まるで宇宙語のようだ。

しかしこれらの概念は実は難しくない。難しいのは良い整理方法がなく、それらの関係がわからないことだ。

この記事は知識マップとして、完全なAI工学知識フレームワークの構築を助ける。

---

第一層：基礎概念（必須）

1. Token

定義：テキストの最小処理単位、「語句ブロック」として理解できる。

実例：

• "Hello World" → ["Hello", " World"] (2 tokens)
• "你好世界" → ["你好", "世界"] (2 tokens、中国語は一般に1文字=1 token)

重要性：

• モデルはtokenで課金（文字数ではない）
• モデルにはtoken上限がある（GPT-4は128k tokens対応）
• token使用の最適化 = コスト削減

ツール：

• OpenAI Tokenizer: https://platform.openai.com/tokenizer
• tiktoken (Pythonライブラリ)

---

2. Context / Context Window

定義：モデルが一度に「覚えられる」コンテンツの長さ。

比喩：友人とチャットする時の「短期記憶」。長く話すと前の内容を忘れる、モデルも同じ。

実例：

• GPT-4 Turbo: 128k tokens (約10万漢字)
• Claude 3: 200k tokens
• Gemini 1.5 Pro: 1M tokens

Contextを使い切るとどうなる？

• 初期コンテンツが「忘れられる」
• RAGや要約技術で記憶を拡張する必要がある

---

3. Prompt / Prompt Engineering

定義：AIへの指示と入力。

高度な技術：

Few-shot Prompting

モデルに例を与え、パターンを学習させる：

例：
入力：「今日は天気が良い」 → 感情：ポジティブ
入力：「この製品は最悪」 → 感情：ネガティブ

今分析：「この機能はまあまあ」 → 感情：？

Chain-of-Thought (CoT)

モデルに「ゆっくり考えさせる」：

問題：太郎は5個のリンゴを持っていて、2個食べ、3個買った。今何個？

回答（普通）：6個

回答（CoT）：
1. 初期：5個
2. 2個食べた：5 - 2 = 3個
3. 3個買った：3 + 3 = 6個
答え：6個

System Prompt

モデルの「人格」と行動ルールを定義：

System: あなたは厳格な弁護士アシスタント、回答には法条文を引用必須。
User: 契約違反はどうする？

---

4. Temperature / Top-p

定義：モデル出力の「ランダム性」を制御。

Temperature：

• 0.0：完全確定、毎回同じ出力（コード生成に適する）
• 1.0：標準ランダム性（チャットに適する）
• 2.0：高創造性（詩作、ブレインストーミングに適する）

Top-p (Nucleus Sampling)：

• 0.1：確率最高の10%の選択肢のみ考慮（保守的）
• 0.9：確率累積90%の選択肢を考慮（バランス）

経験：

• コード：temperature=0, top_p=0.1
• 記事：temperature=0.7, top_p=0.9
• 創造的作業：temperature=1.5, top_p=0.95

---

5. Embedding / ベクトル化

定義：テキストを数値ベクトル（浮動小数点数列）に変換。

必要性：

• コンピュータは「猫」と「犬」の類似性を理解できない
• しかしベクトル [0.2, 0.8, ...] と [0.3, 0.7, ...] の距離は計算できる

実例：

from openai import OpenAI
client = OpenAI()

text = "人工知能が世界を変える"
embedding = client.embeddings.create(
    model="text-embedding-3-small",
    input=text
)
# 返却：[0.023, -0.45, 0.78, ..., 0.12]  (1536次元)

用途：

• セマンティック検索
• 推薦システム
• RAGの基礎

---

第二層：アーキテクチャとモデル

6. Transformer

定義：現代LLMの核心アーキテクチャ（2017年Google提案）。

核心イノベーション：Self-Attentionメカニズム

• 伝統的RNN：逐字処理、遅い、長文を覚えられない
• Transformer：並列処理、速い、長距離依存を処理可能

構成要素：

• Encoder：入力理解（例：BERT）
• Decoder：出力生成（例：GPT）
• Encoder-Decoder：翻訳タスク（例：T5）

---

7. LLM (Large Language Model)

定義：パラメータ数が超大規模な言語モデル。

規模比較：

• GPT-3：175Bパラメータ
• GPT-4：推測1.7Tパラメータ
• Llama 2：7B / 13B / 70Bパラメータ

---

10. RAG (Retrieval-Augmented Generation)

定義：検索拡張生成 = 検索 + 生成。

ワークフロー：

1. ユーザー質問：「Llama 3のコンテキスト長は？」
2. 検索：知識ベースで関連文書を探す
3. 生成：文書と質問を一緒にLLMに渡し、回答させる

RAGが必要な理由：

• モデルの知識には期限がある（GPT-4は2023年まで）
• 企業データはモデルが見たことない
• Fine-tuningは高価、RAGはより柔軟

RAG vs Fine-tuning：

シナリオ	RAG使用	Fine-tuning使用
頻繁更新データ	✅	❌
特定スタイル学習	❌	✅
コスト重視	✅	❌
出典引用必要	✅	❌

---

11. Vector Database / ベクトルデータベース

定義：ベクトルの保存と検索専用データベース。

通常のDBを使わない理由：

• ベクトル次元が高い（768/1536/3072次元）
• 効率的な「類似度検索」（KNN/ANN）が必要
• 通常のDBでは不可能

主流製品：

• Pinecone：マネージドサービス、簡単
• Weaviate：オープンソース、ハイブリッド検索対応
• Qdrant：オープンソース、Rust製、高性能
• Milvus：オープンソース、Alibaba開発、大規模
• Chroma：オープンソース、Python-native、軽量
• pgvector：PostgreSQLプラグイン

---

15. Function Calling / Tool Use

定義：LLMに外部ツール（API、DB、計算機など）を呼び出させる。

実例：

from openai import OpenAI
client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "天気取得",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {"type": "string"}
            }
        }
    }
}]

response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "東京の天気は？"}],
    tools=tools
)

用途：

• リアルタイムデータ照会（株価、天気）
• 操作実行（メール送信、チケット予約）
• プライベートデータアクセス（社内DB）

---

16. MCP (Model Context Protocol)

定義：Anthropic提案の標準化ツール呼び出しプロトコル（2024年11月リリース）。

解決する問題：

• 以前は各AIアプリが独自にツール呼び出しを実装
• MCPで標準統一、ツールがアプリ間で再利用可能

アーキテクチャ：

AIアプリ ←→ MCP Client ←→ MCP Server ←→ ツール/データソース

意義：

• USBプロトコルに類似：一つの標準で万物接続
• 未来のAIツールエコシステムの基盤

---

第三層：工程実践

18. Agent / 智能体

定義：自律的に判断、ツール呼び出し、タスク完成できるAI。

ワークフロー：

1. 思考：タスク分析
2. 行動：ツール呼び出し
3. 観察：結果確認
4. 繰り返し：完成まで

実例：

タスク：明日東京から大阪への航空券予約

Agent:
  思考：フライト情報が必要
  行動：search_flights("東京", "大阪", "明日")を呼び出し
  観察：3便発見
  思考：ユーザー選択が必要
  行動：ask_user("どの便を選択？")
  観察：ユーザーが便2を選択
  行動：book_flight(flight_id=2)
  観察：予約成功
  完了！

---

19. Streaming / ストリーミング出力

定義：結果を逐次返却、全生成完了を待たない。

UX：

• 非ストリーミング：10秒待つ → 完全な回答を見る
• ストリーミング：即座に最初の文字を見て、逐次表示

---

21. SDD (Specification-Driven Development)

定義：先に「仕様」（Spec）を定義、後からコード生成。

従来開発：

要件 → 設計 → コード → テスト

SDD：

要件 → Spec作成（テストケース/制約） → AI生成 → 自動検証

意義：

• AI時代の開発パラダイム
• 人間は「何が欲しいか」に集中、AIが「どうするか」を担当

---

30. Hallucination / ハルシネーション

定義：モデルが「真面目にデタラメを言う」。

実例：

ユーザー：『量子仏教学』という本を紹介して
AI：この本は山田太郎が2018年に出版...
（実際にはこの本は存在しない）

原因：

• モデルは「次の単語を予測」、「データベース照会」ではない
• 訓練データにノイズがある

緩和方法：

1. RAG：本物の文書を提供
2. Temperature低下：ランダム性削減
3. Prompt制約：「知らなければ『わかりません』と言う」
4. 出典引用：モデルに根拠引用を要求

---

これらの概念をどう学ぶ？

1. 階層学習

第1週：Token, Context, Prompt, Temperature（Promptをいくつか書いて遊ぶ）

第2週：Embedding, RAG, ベクトルDB（簡単な質問応答システムを作る）

第3週：Function Calling, Agent（AIに天気API呼び出しをさせる）

第4週：Fine-tuning, Quantization（小型モデルを微調整）

2. 実践

プロジェクト提案：

• Week 1：個人知識ベース質問応答（RAG）
• Week 2：マルチツールAIアシスタント（Function Calling）
• Week 3：コードジェネレーター（Few-shot + CoT）
• Week 4：カスタマーサービスボット微調整

---

結語

この30の概念は、AI工学の「周期表」だ。

一度に全て学ぶ必要はない。しかしそれらが存在すること、相互関係、どこで使うかを知っていれば、問題に遭遇した時に素早く特定できる。

2点を覚えよう：

1. 概念は死んでいる、応用は生きている。定義を暗記せず、シナリオを理解する。
2. AI技術は急速に反復。今日のベストプラクティスが、半年後には時代遅れかもしれない。学び続け、変化を受け入れる。

今、興味のある概念を一つ選んで、実際に試してみよう。

AIを理解する最良の方法は、AIと一緒に働くことだ。