第3章 主要コンポーネント徹底解剖とエンジニアの最適化ポイント
対象＝一般Web/アプリ開発者・バックエンドエンジニア。Transformer, LLM, RAG, MCP, SKILLの各技術の仕組みを解き明かし、プログラマーが現場でチューニングすべき具体的急所を網羅する。
1. Transformer & LLM：基本原理とプログラマーの最適化
仕組みの要点
- Self-Attention機構: 文中の全単語同士が「どれくらい関連しているか」を重み付け計算する行列演算。計算量はトークン数の2乗 $O(N^2)$ でスケールするため、長大なコンテキストはレイテンシと費用の急激な悪化を招く。
- Next Token Prediction: LLMは一度に文章全体を理解して書いているのではなく、「これまでの文脈に続く確率が最も高い次の1トークン」を確率的に予測して繰り返しているに過ぎない。
- Lost in the Middle 現象: コンテキストウィンドウが数十万トークンあっても、「プロンプトの先頭」と「末尾」の情報に強く注目し、中央部に置かれた指示やデータを見落としやすい というモデルの固有特性。
🔧 プログラマーが最適化すべき急所
- 重要指示の配置ルール（Sandwich Prompting）:
- 最も重要な制約（「JSONのみ出力せよ」「外部送信禁止」等）は、プロンプトの最先頭（System）と最末尾（Userプロンプトの直後）の両方に挟み込む。
- Structured Outputs（構造化出力の強制）:
- 自然言語で「JSON形式で返してください」と頼むのはアンチパターン（稀にMarkdownコードブロックや前置き文が混入して
JSON.parse()が例外落ちする）。 - OpenAI/Anthropic/Geminiが提供する Structured Outputs (JSON Schema Strict Mode) を必ず使用し、モデルのサンプリング段階で指定スキーマに合致するトークンのみを出力させる。
- Temperature と Top_p の制御:
- Agentのツール呼び出し・データ抽出：
temperature = 0.0（決定論的で再現性の高い挙動にする）。 - 提案文・クリエイティブな文面作成：
temperature = 0.7。
- Token Capping と ストリーミング処理:
- 1リクエストの
max_tokensを必要最小限に制限。 - ユーザーUIにはストリーミング（Server-Sent Events: SSE）でトークンを順次返し、TTFT（Time To First Token）の体感速度を改善する。
2. RAG（Retrieval-Augmented Generation）：検索拡張の急所
仕組みの要点
LLMの学習データに含まれない社内規程、最新DBデータ、個別案件資料を、外部データベースから検索してプロンプトのコンテキストに動的に注入する仕組み。
[社内文書 / PDF / DB]
│
▼ (チャンク分割: Chunking)
[テキストチャンク]
│
▼ (Embedding モデルでベクトル化)
[Vector DB] (pgvector / Pinecone / Qdrant)
▲
│ 類似度検索 (コサイン類似度 + キーワード検索)
[ユーザーの質問] ──► [Query Embedding]🔧 プログラマーが最適化すべき急所
- チャンキング戦略（Chunking Strategy）:
- 固定文字数（例: 500文字固定）でブツ切りにすると、重要な文脈（主語や条件文）が分断されて検索ヒットしなくなる。
- 見出し単位（Markdown Header分割） や セマンティックチャンキング（段落・意味のまとまり単位） を採用し、20〜50トークンの「オーバーラップ（重なり）」を持たせる。
- Hybrid Search（ハイブリッド検索）の導入:
- ベクトル検索（意味的類似性）だけでは、「型番 ABC-1234」「社員番号 99812」のような完全一致キーワード検索に弱い。
- BM25（伝統的全文検索） + ベクトル検索 を組み合わせ、相互順位融合（RRF: Reciprocal Rank Fusion）でスコアリングする。
- Reranker（リランカー）による絞り込み:
- Vector検索で上位20件を粗く取得し、軽量なクロスエンコーダーモデル（Cohere Rerank等）で質問との関連度を再計算して上位3〜5件に絞り込む。
- プロンプトに無駄なノイズが混ざるのを防ぎ、トークン代を大幅削減しつつ精度を跳ね上げる。
- メタデータフィルタリング（Metadata Filtering）:
- 「総務部の規程」「2026年度版」などの属性をベクトルのメタデータとして付与し、検索クエリの段階で
WHERE department = 'soumu' AND year = 2026とプレフィルターをかける。
3. MCP（Model Context Protocol）：標準インターフェース
仕組みの要点
2024年末にAnthropicが提唱し、急速にデファクトスタンダードになりつつある オープンな通信プロトコル。 これまでの「LLMフレームワークごとに個別にツール連携コードを書く」状態から、「WebにおけるHTTP」のように、あらゆるデータソースやツールを標準規格でつなぐアーキテクチャ を提供します。
- MCP Client: Agent側（Claude Desktop、Antigravity、独自のAgentアプリ）。
- MCP Server: ツールやリソースを提供する軽量サーバー（DB、GitHub、Slack、自社API等）。
- 通信形式: JSON-RPC 2.0（stdio または SSE/HTTP 経由）。
提供される3つの基本機能：
- Tools: Agentが実行できる関数（例:
execute_sql,send_slack_message）。 - Resources: Agentが読み取れるファイルやデータ（例:
file:///logs/app.log,postgres://tables/users）。 - Prompts: サーバー側が提供する再利用可能なプロンプトテンプレート。
🔧 プログラマーが最適化すべき急所
- ツールの粒度設計（Granularity）:
- 1つのMCP Serverに数十個のツールを無秩序に詰め込むと、スキーマだけで数千トークンを消費し、LLMがツールの選択を間違える。
- 業務ドメインごとにServerを分割（例:
mcp-server-accounting,mcp-server-github）し、必要なAgentにだけ接続する。
- エラーハンドリングと丁寧なエラーメッセージ:
- MCPツールの返り値で
isError: trueとともに、「何が原因で、どう修正すれば成功するか」 を自然言語で詳しく書く（例:{"error": "Invalid date format. Expected YYYY-MM-DD, received 2026/09/13"}）。Agentはこのエラー文字列を読んで即座に自律修正を行う。
- セキュリティと最小権限の原則:
- DB用MCP Serverには原則として
SELECT権限のみの読み取り専用ユーザーを割り当てる。更新系は専用の承認フラグを要求する別のツールにする。
4. SKILL（スキルパッケージ）：知識と指示のカプセル化
仕組みの要点
Agentに特定のタスク（例: 「コードレビュー」「障害分析」「請求書照合」）を高精度で実行させるための、再利用可能なプロンプト・手順・スクリプトを束ねた仕様フォーマット。 通常、YAMLフロントマター（メタデータ）とMarkdown（詳細指示）で構成されます。
🔧 プログラマーが最適化すべき急所
- Progressive Disclosure（段階的コンテキスト開示）:
- すべてのスキルの詳細手順を最初からシステムプロンプトに入れておくと、コンテキストウィンドウが枯渇する。
- 初回はスキルの「名前と短い1行説明」だけをAgentに見せておき、Agentが「このタスクにはこのスキルが必要だ」と判断した瞬間に、該当スキルの詳細な
SKILL.mdを動的に読み込ませる。
- Few-Shot Examples（高品質な入出力例）の厳選:
- 抽象的なルールを10行書くよりも、「入力例」と「期待される出力例」を2〜3組提示する方が、LLMの出力フォーマット維持率は劇的に向上する。