第12章: AIシステム構築入門 — API・RAG・ファインチューニング

この章を読むと: 「ChatGPTのようなものを社内で作りたい」という要望に対して、API利用・RAG・ファインチューニングの3つのアプローチから適切な方法を選べるようになります。また、コスト・開発期間・必要なデータ量の感覚を掴み、AI導入プロジェクトの意思決定に参加できるようになります。

この章を一言で言うと

「AIシステムを作る方法は3つある。それぞれの使い時を知るだけで、判断が変わる」

ChatGPTを使うのは「完成した製品を買う」こと。しかし企業でAIシステムを構築する場合は、自社のニーズに合わせて「設計」が必要です。その設計には主に3つのアプローチがあります。どれが正解かは状況によって異なります。この章では、その使い分けの地図を手に入れましょう。

---

1. 3つのアプローチを最初に整理する

AIシステム構築において、まず押さえるべき全体像は以下の通りです。

この3つを「レストランのアナロジー」で考えてみましょう。

• API利用: 出前（既製品をそのまま注文する）
• RAG: 出前の料理人に「うちの食材を使って調理してもらう」
• ファインチューニング: 料理人自体を自社流のレシピで特訓する

どのアプローチを選ぶかは、「何を変えたいのか」によって決まります。

---

2. LLM API入門 — まず「使う」ところから

APIとは何か

API（Application Programming Interface）とは、「ソフトウェア同士が会話するための窓口」です。LLM APIを使えば、自社のシステムからChatGPTやClaudeを呼び出せます。

あなたのシステム → [API] → OpenAIのサーバー → AIが回答を生成 → [API] → あなたのシステム

メールソフトから郵便局に手紙を出し、返信を受け取るイメージです。自社がAIを保有・運営する必要はなく、使った分だけ料金を払います。

主要3社のAPIを知る

2026年現在、LLM APIの市場を牽引するのは3社です。

OpenAI（ChatGPTの会社）

強み: 最も実績が多く、エンジニア向けドキュメントが充実。関数呼び出し（Function Calling）、音声・画像への対応が早い。

代表モデル:

• GPT-5: 最高性能フラッグシップモデル（2025年リリース）
• GPT-4.1: コスト効率の高いミッドティアモデル
• GPT-4.1 Nano: 軽量・高速・格安のライトモデル

Anthropic（Claudeの会社）

強み: 長い文章の処理（コンテキストウィンドウ）が特に優秀。安全性への取り組みが評価高く、法務・医療など慎重さが求められる業界での採用が増加。プロンプトキャッシュによるコスト削減効果が業界最高水準。

代表モデル:

• Claude Opus 4.6: 最高性能フラッグシップモデル
• Claude Sonnet 4.6: バランス型ミッドティアモデル（最もコスパが高い）
• Claude Haiku: 高速・軽量・格安ライトモデル

Google（Geminiの会社）

強み: Google検索・Google Workspace（Docs・Sheets・Gmail）との連携が強み。無料枠が大きく、価格競争力が高い。

代表モデル:

• Gemini 3.1 Ultra: 最高性能フラッグシップモデル
• Gemini 3.1 Pro: ミッドティアモデル（コスパ最優秀）
• Gemini 2.0 Flash: 超格安・高速ライトモデル

2026年の料金比較

LLM APIの料金は「トークン課金」が基本です。トークンとは「テキストを分割した最小単位」で、日本語は1文字あたり約1〜2トークンに相当します。

トークンとは何か

英語: "Hello World" → 2トークン
日本語: 「こんにちは」 → 約3〜5トークン（文字数より多くなる）

1,000トークン ≒ 英語750単語 ≒ 日本語400〜500文字

日本語はトークン効率が英語より低いため、同じ内容でも英語より費用がかかる点に注意が必要です。

2026年4月時点の料金（1Mトークンあたり）

2年前との比較: 2024年当時、フラッグシップモデルの入力料金は1Mトークンあたり$10前後が相場でした。2026年現在、同等性能のモデルが$2〜5で利用でき、料金は約70〜80%下落しました。AIのコストは毎年劇的に下がっています。

コスト感覚を掴むための具体例

A4 1枚の文書を要約するケース（約1,000日本語文字 = 約1,500トークン）:

格安モデルは驚くほど安価ですが、精度・文章の質にはトレードオフがあります。まずは格安モデルでプロトタイプを作り、品質が十分かを確認してからグレードアップする手順が実践的です。

コスト削減の2大テクニック

1. プロンプトキャッシュ（Anthropic優位）

同じシステムプロンプト（AIへの指示文）を繰り返し使う場合、一度処理したものをキャッシュ（保存）して再利用できます。Anthropicのキャッシュは最大90%のコスト削減が可能です。例えば毎回同じ長い指示文を送る場合、実質的なコストは1/10になります。

2. バッチAPI

リアルタイム応答が不要な場合（夜間に大量文書を処理するなど）、バッチ処理を使うと通常料金の約50%引きになります。

API呼び出しの基本パターン

LLM APIの呼び出しは、どの会社のAPIも基本的に同じ構造です。

# Python + OpenAI APIの例（概念説明用）
from openai import OpenAI

client = OpenAI(api_key="your-api-key")

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        # システムプロンプト: AIの役割・制約を定義
        {"role": "system", "content": "あなたは法律文書の専門家です。"},
        # ユーザーの質問
        {"role": "user", "content": "この契約書の問題点を教えてください"},
    ],
    temperature=0.3,  # 低いほど安定・一貫した回答（0〜2の範囲）
    max_tokens=1000   # 出力の最大トークン数
)

# 回答を取り出す
answer = response.choices[0].message.content

3つのメッセージロール:

• system: AIへの「役割・前提条件」の指示（毎回送る）
• user: 人間からの質問・指示
• assistant: AIの返答（会話履歴として使う）

---

3. RAG — 「社内データをAIに参照させる」技術

なぜRAGが必要なのか

LLM APIをそのまま使うだけでは、2つの根本的な問題があります。

問題① ハルシネーション: AIは存在しない情報を自信満々に答えることがある（第3章参照）

問題② 社内データを知らない: OpenAIやAnthropicのAIは、あなたの会社の社内規定・製品マニュアル・顧客データを学習していません

RAG（Retrieval-Augmented Generation、読み: ラグ）は、この2つの問題を同時に解決する技術です。

RAGの核心: 「AIに回答を生成させる前に、まず正しい情報を検索して、その情報だけに基づいて回答させる」

これは人間でいえば、「試験前に参考書を開いて、そこに書いてあることだけを答える」オープンブック試験のようなものです。記憶に頼らず、手元の資料から答えるので、ハルシネーションが大幅に減ります。

RAGが必要な典型的なシナリオ

ベクトルデータベース — RAGの「検索エンジン」

RAGの心臓部はベクトルデータベースです。通常のデータベースは「キーワード完全一致」で検索しますが、ベクトルデータベースは**「意味の近さ」で検索**できます。

通常の検索 vs ベクトル検索

質問: 「有給休暇の取り方を教えて」

通常の検索（キーワード一致）:
→ 「有給休暇」「取り方」が完全一致するページのみヒット

ベクトル検索（意味検索）:
→ 「年次有給休暇の申請手順」「休暇取得フロー」「休みの申請方法」も同時にヒット
→ 言葉が違っても「意味が近い」文書を見つけられる

主要ベクトルデータベース（2026年比較）

2026年の選び方の原則: 既にPostgreSQLを使っているならpgvectorが最もコスパが高い（ベクトル数5百万件まで実用的）。大規模・自動スケールが必要ならPinecone。OSS・ハイブリッド検索重視ならWeaviateかQdrant。

エンベディング — テキストを数値に変換する

ベクトルデータベースに文書を格納するには、まずテキストを「数値の配列（ベクトル）」に変換する必要があります。この変換処理を**エンベディング（Embedding）**と言います。

「有給休暇の申請方法」→ [0.12, -0.45, 0.87, 0.23, ...]（1536次元の数値配列）
「休みの取得手順」   → [0.11, -0.43, 0.89, 0.21, ...]（似た意味 → 似た数値）
「猫のエサの選び方」 → [0.92, 0.31, -0.12, 0.67, ...]（意味が違う → 異なる数値）

意味が似ている文章は、数値的にも「近い」ベクトルになります。これにより、「意味の距離」で検索できるようになります。

主要エンベディングモデル（2026年）:

• OpenAI text-embedding-3-large: 高精度、コストは1Mトークン$0.13
• text-embedding-3-small: 軽量版、1Mトークン$0.02
• Google text-embedding-004: Googleのモデル、精度・コスト共にバランスが良い
• 日本語特化モデル: intfloat/multilingual-e5-large（OSS）が日本語RAGで実績多数

RAGのパイプライン全体像

RAGシステムは「準備フェーズ」と「回答フェーズ」の2段階で構成されます。

準備フェーズ（文書の事前処理）

社内文書（PDF・Word・Webページ等）
    ↓ テキスト抽出
テキストデータ
    ↓ チャンキング（適切な長さに分割）
チャンク（断片）
    ↓ エンベディング（数値ベクトルに変換）
ベクトルデータ
    ↓ 格納
ベクトルデータベース（Pinecone / pgvector 等）

回答フェーズ（ユーザーからの質問に答える）

ユーザーの質問: 「有給休暇は何日取れますか？」
    ↓ エンベディング（質問もベクトル化）
質問ベクトル
    ↓ 類似度検索
ベクトルデータベース → 関連文書チャンクを取得（Top 3〜5件）
    ↓ プロンプト構成
「以下の情報を参考に質問に答えてください:
[取得したチャンク1]
[取得したチャンク2]
質問: 有給休暇は何日取れますか？」
    ↓ LLM API呼び出し
回答: 「就業規則第12条によると、勤続1年以上の正社員は年間10日〜20日の有給休暇が...」

チャンキング戦略 — 最も重要なチューニングポイント

チャンキングとは「大きな文書を検索しやすい断片に分割する」処理です。チャンクの大きさが適切でないと、RAGの精度が大きく低下します。

2026年のベストプラクティス: 「固定長512トークン + 50トークン重複」でまずプロトタイプを作り、RAGASでの評価後にチャンク戦略をチューニングする。最初から複雑な戦略を選ぶ必要はない。

ハイブリッド検索 — 2026年の本番環境標準

2026年の本番RAGシステムは、**ベクトル検索と従来のキーワード検索（BM25）を組み合わせた「ハイブリッド検索」**が標準になっています。

ユーザーの質問
    ├─ ベクトル検索（意味の近さで検索）
    └─ BM25検索（キーワード一致で検索）
        ↓ 結果を統合・スコアリング
        ↓ リランキング（順序を最適化）
    最終的な関連チャンク（Top 3〜5件）

純粋なベクトル検索だけでは「製品型番SK-2023-A」のような固有名詞・数字の検索が弱く、純粋なキーワード検索では「有給の取り方」と「年次休暇の申請」が同じ意味だとわかりません。ハイブリッド検索はこの両方の弱点を補います。

---

4. ファインチューニング — AIの「クセ」を変える

ファインチューニングとは何か

LLMのファインチューニングとは、既存の大規模モデルを自社独自のデータで追加学習させ、特定の振る舞い・口調・知識を身につけさせる技術です。

人間で例えると、「大学で幅広く教育を受けた新卒を、自社の業務に特化した研修でベテラン社員にする」イメージです。基礎能力（一般的な言語能力）はそのままで、専門的な振る舞いを上乗せします。

フルファインチューニング vs LoRA/QLoRA

ファインチューニングには大きく2つのアプローチがあります。

フルファインチューニング

モデルの全パラメータ（数千億個の数値）を再学習します。最高の性能が出る一方、コストと計算資源が膨大です。

• 必要なGPUメモリ: 70Bパラメータモデルで約140GB以上（高価なGPUが複数必要）
• 学習コスト: 数十〜数百万円
• 現実的な採用者: 大企業・AI専業企業のみ

LoRA（Low-Rank Adaptation）

2021年にMicrosoftが発表した手法。モデルの重みをほぼ固定したまま、小さなアダプター部分だけを学習します。

通常のファインチューニング: 全重みを更新（100%）
LoRA:                   アダプター部分のみ更新（0.1〜1%）

→ 必要な計算量が1/10以下になる
→ 結果の品質はフルファインチューニングとほぼ同等

QLoRA（Quantized LoRA）

LoRAをさらに進化させ、モデルを4ビット精度に量子化（圧縮）してから学習します。

LoRA  : 16ビット精度のまま学習 → GPU 48GB程度が必要
QLoRA : 4ビット精度に圧縮して学習 → GPU 24GB（1枚）でも可能

2026年の実践的な出発点: QLoRAの設定 r=16, DoRA有効, target_modules="all-linear" が推奨されています。コンシューマー向けGPU（RTX 4090/5090）でも7Bクラスのモデルをファインチューニングできます。

主要手法の比較

いつファインチューニングすべきか

ファインチューニングはコストと時間がかかるため、本当に必要かどうかを慎重に見極める必要があります。

ファインチューニングが効く3つのパターン

パターン1: 出力フォーマットの徹底統一

「JSONで必ず3つの項目を返してほしい」「医療レポートは必ずこの書式で」といった要求は、プロンプトエンジニアリングだけでは失敗率が下がりません。1日1万件のリクエストで「ほぼ正しい」では、数百件の失敗が発生します。ファインチューニングで出力の一貫性を確保できます。

パターン2: 特定ドメインの口調・文体の統一

「当社のカスタマーサポートらしい返答をしてほしい」「法律事務所らしい堅い文体で」といった要求は、ファインチューニングが最も効果的です。数百〜数千件のQ&Aサンプルで学習させると、RAGより自然な文体の一貫性が得られます。

パターン3: 推論コストの削減

長いシステムプロンプトを毎回送るよりも、ファインチューニングで振る舞いを内在化させた方が、トークン消費を減らせるケースがあります。ただしこれは高度な最適化であり、一般的なケースでは検討不要です。

ファインチューニングが「不向き」なケース

• 最新情報が必要な場合: ファインチューニングしても、学習後の新情報には対応できない → RAGが正解
• 情報量が少ない場合: 良質なデータが100件以下では効果が薄い → まずはプロンプトエンジニアリングで解決を試みる
• 精度検証環境がない場合: ファインチューニング後に評価ができなければ、むしろ品質が下がるリスクがある

RAGとファインチューニングの使い分け

2026年の現場で確立した判断基準:

「何を変えたいか？」

知識・情報を変えたい → RAG
（最新の法律を参照したい、社内規定に答えたい）

振る舞い・口調を変えたい → ファインチューニング
（特定のフォーマットで回答させたい、自社ブランドの文体にしたい）

両方を変えたい → RAG + ファインチューニング（ハイブリッド）

---

5. LLMOps — 本番環境でAIを「運用」する

LLMOpsとは何か

LLMOps（Large Language Model Operations）は、AI開発・デプロイ・運用・改善のサイクルを体系化したプラクティスです。ソフトウェア開発における「DevOps」のAI版と考えればわかりやすいでしょう。

AIシステムは「作って終わり」ではありません。モデルのアップデート、コストの変動、出力品質の劣化、新しい攻撃手法（プロンプトインジェクションなど）への対応が継続的に必要です。

モニタリング — AIの「健康診断」

AIシステムを本番で動かす場合、以下の指標を常時監視します。

システム指標:

• レスポンスタイム（API呼び出しから回答返却までの時間）
• エラー率（APIタイムアウト・レート制限超過など）
• コスト（1時間あたり・1ユーザーあたりのトークン消費量）

品質指標:

• ハルシネーション率（事実誤りの割合）
• ユーザーからのネガティブフィードバック率
• タスク完了率（チャットボットであれば問題解決できた割合）

2026年注目ツール: Langfuse（OSS、50以上のフレームワークに対応）とLangSmith（LangChain公式）が本番環境での標準モニタリングツールになっています。

評価（Evals）— AIの「テスト」

一般的なソフトウェアは「バグがない = 正解」と判定できます。しかしAIの「出力の質」は定量的に測るのが難しいという根本的な問題があります。

この問題を解決するのが Evals（評価フレームワーク） です。

代表的な評価指標（RAGAS）:

ゴールデンデータセット: 「正解が既知の質問100〜200件」を準備し、定期的に自動評価を回す仕組みを作ることが、LLMOps の核心です。

コスト管理 — 「使いすぎ」を防ぐ

AIの従量課金は予算超過のリスクがあります。以下の対策が実践的です。

技術的な対策:

• レート制限: 1ユーザーあたりの1日の最大リクエスト数を設定
• トークン制限: 入力・出力の最大トークン数を制限（max_tokensパラメータ）
• プロンプトキャッシュ: 共通のシステムプロンプトをキャッシュして再利用
• モデルのカスケード: まず安価な軽量モデルで試み、必要なときだけ高性能モデルを使う

組織的な対策:

• 部門別・プロジェクト別のコストアラート設定
• コスト閾値を超えたら自動通知・自動停止
• 月次コストレポートの作成と最適化サイクル

ガードレール — AIの「暴走」を防ぐ

AIが不適切な出力をしないよう制御する仕組みをガードレールと言います。

入力側ガードレール（ユーザーの悪用防止）:

• プロンプトインジェクション検出（「前の指示を忘れて...」のような攻撃）
• 禁止トピックのフィルタリング（競合他社への誹謗、機密情報の漏洩など）
• 個人情報の自動マスキング

出力側ガードレール（AIの誤出力防止）:

• 有害コンテンツフィルター
• フォーマット検証（JSON形式で返すべき場面での形式チェック）
• 信頼度スコアによる低品質回答の検出

代表的なツール: NVIDIA NeMo Guardrails（OSS）が企業向けの標準として普及しています。また、AnthropicはConstitutional AIというアプローチでモデル自体に倫理制約を内在化させており、Claudeシリーズはガードレール機能が充実しています。

---

6. 主要フレームワーク — AIシステムを「組み立てる」道具

LangChain

最も広く使われているLLMアプリケーション開発フレームワーク（Python/JavaScript）。

できること:

• RAGパイプラインの構築（文書ロード→チャンキング→エンベディング→検索→回答）
• 複数のLLM・ベクトルDB・外部APIを繋げる「チェーン」の構築
• AIエージェントの構築（ツールを使って自律的に問題解決）

強み: エコシステムが最大規模。ほぼすべてのLLM・ベクトルDBに対応。学習リソースが豊富。

弱点: バージョン間の非互換性変更が多く、コードのメンテナンスコストが高い。

LlamaIndex

データとLLMの連携に特化したフレームワーク。RAG構築に最適化されています。

できること:

• PDF・Word・Webページ・データベースなど多様なデータソースの統合
• 高度なチャンキング・インデックス戦略の実装
• 構造化データ（表・CSV）への質問応答

強み: RAGに関しては LangChain より使いやすく・高機能。データコネクタが充実。

弱点: エージェント機能は LangChain に劣る。

Semantic Kernel

Microsoftが開発するフレームワーク（C# / Python）。Microsoft Azureとの統合が強み。

できること:

• Microsoft 365（Word・Excel・Teams）とのAI連携
• Azure OpenAI Serviceとのネイティブ統合
• エンタープライズ向けの権限・セキュリティ管理

強み: Microsoft環境を使っている企業に最適。エンタープライズセキュリティの実績。

弱点: OSSコミュニティは LangChain より小さい。Python版は機能がC#版に遅れる場合がある。

フレームワーク選定ガイド

---

7. 2026年のAI製品・サービス一覧

AIシステムを自作する場合と、既製品・SaaSを使う場合では、コストと開発期間が大きく異なります。まず既製品で要件を満たせないか確認する習慣が重要です。

LLM API

ベクトルデータベース

LLMOpsツール

RAG・AIアプリ開発SaaS

---

8. 企業での活用事例

事例①: 大手製造業 — 社内技術文書Q&Aシステム（RAG）

課題: 設計・品質マニュアルが数万ページあり、担当者が必要な情報を探すのに1件あたり平均40分かかっていた。

構成:

• 文書ストア: SharePoint上の全マニュアル（PDF/Word）
• エンベディング: text-embedding-3-large
• ベクトルDB: pgvector（既存PostgreSQL活用）
• LLM: Claude Sonnet 4.6（長文対応・安全性）
• フレームワーク: LlamaIndex

成果:

• 情報検索時間: 40分 → 平均3分（92%削減）
• 月次コスト: 約85,000円（Claude APIトークン + pgvector運用費）
• 構築期間: 約2ヶ月（既存インフラ活用）

ポイント: 既にPostgreSQLを使っていたため、pgvectorで追加インフラ費用をゼロに抑えた。初期はChromaDBで2週間のPoC（実証実験）を実施してから本番移行。

事例②: 法律事務所 — 契約書レビュー支援（API + ファインチューニング）

課題: 契約書のリスク項目チェックに弁護士が1件あたり2〜3時間かけていた。フォーマットが事務所独自の書式で統一されていなかった。

構成:

• フェーズ1: GPT-4.1のAPIで標準的なリスクチェック（2週間で導入）
• フェーズ2: 過去5年分の契約書レビュー記録2,000件でQLoRAファインチューニング（3ヶ月）
• 出力を事務所独自のリスク評価フォームに統一

成果:

• 初期確認時間: 2〜3時間 → 20分（弁護士はAI出力の最終確認のみ）
• リスク見落とし率: 15% → 4%（AIが網羅的に確認）
• 構築コスト: PoC 30万円 + ファインチューニング 150万円

ポイント: フェーズ1のAPI導入で業務フローを固め、フェーズ2でファインチューニングを実施。いきなりファインチューニングから始めなかったことが成功の鍵。

事例③: 小売チェーン — カスタマーサポートチャットボット（RAG + ガードレール）

課題: 問い合わせの70%が「返品ポリシー・在庫状況・店舗情報」の繰り返し質問。オペレーター不足が深刻。

構成:

• 文書: 商品カタログ・店舗情報・FAQページ（週次更新）
• ベクトルDB: Pinecone（在庫状況の頻繁な更新に対応）
• LLM: Gemini 2.0 Flash（大量リクエストを低コストで処理）
• ガードレール: 競合他社比較・過激な発言を自動フィルタリング

成果:

• 問い合わせのうちAI自動解決率: 72%
• 月次コスト: 約12万円（Pinecone + Gemini APIトークン）
• オペレーター対応件数: 月5万件 → 1.4万件（72%削減）

ポイント: 最安値のGemini 2.0 Flashを採用し月12万円に抑制。応答品質が十分かをRAGASで毎週評価し、必要に応じてプロンプトを調整。

---

9. 自分でAIシステムを構築するためのステップ

理論を学んだ後は、実際に手を動かす段階です。以下のステップに従えば、技術的な専門知識がなくても小さなAIシステムを構築できます。

ステップ1: 問題を明確にする（1週間）

AIシステムの失敗の多くは、「何を解決したいか」が曖昧なまま技術選定を始めることです。

• 「誰の」「どんな問題」を「どれくらい」改善したいかを1文で書く
• 「AIを使いたい」から始めない。「〇〇の業務に△時間かかっているを□分にしたい」から始める
• 成功基準（KPI）を数値で決める

ステップ2: PoC（実証実験）を2週間でやる

いきなり本格的なシステムを作らない。まず最小限の構成で「そもそもAIで解決できるか」を検証します。

最短PoC構成（コーディング不要版）:

1. ChatGPT Plus（$20/月）でシステムプロンプトを試す
2. NotionAI や Google Workspace AI で文書処理を試す
3. Dify（ノーコードRAGツール）で社内文書Q&Aを試す

最短PoC構成（軽量コーディング版）:

1. Python + LlamaIndex + ChromaDB でローカルRAGを構築（3〜5日）
2. 100件の社内文書で評価
3. RAGASで精度を数値化

ステップ3: 技術選定（1週間）

PoCで「使えそう」と判断できたら、本番に向けた技術選定を行います。

選定チェックリスト:

• データ更新頻度は？（高頻度 → RAG優先）
• フォーマット統一が必要か？（必要 → ファインチューニング検討）
• 既存DBはPostgreSQL？（YES → pgvector）
• Azure/GCPどちらのクラウド？（連携ツールが変わる）
• 月間リクエスト数は？（コスト計算の基準）
• 個人情報・機密情報が含まれるか？（セキュリティ要件確認）

ステップ4: 段階的に構築する

推奨スケジュール（小〜中規模AIシステムの場合）:

ステップ5: 継続的に改善する

AIシステムは「リリースして終わり」ではありません。

• 週次でRAGAS評価を実行し、品質低下を早期発見
• ユーザーフィードバックを収集し、プロンプトや検索戦略を改善
• 新しいモデルが出たらA/Bテストで比較
• コストレポートを見て最適化の余地を探す

---

10. AIシステム構築の「落とし穴」

落とし穴① 「とりあえずRAG」症候群

RAGを導入すれば解決すると思い込み、そもそもプロンプトエンジニアリングで解決できる問題にコストをかけてしまう。

対策: まず「システムプロンプトだけで解決できないか？」を試す。解決できない場合にRAGを検討。

落とし穴② チャンキング無思慮

「とりあえず500文字で分割」で本番稼働させ、検索精度が悪いまま放置する。

対策: PoCでチャンク戦略を2〜3種類試してRAGASで評価し、最も精度が高い戦略を採用してから本番移行。

落とし穴③ Evals（評価）を後回しにする

「動いているから大丈夫」と評価を省略し、品質劣化を見逃す。

対策: 本番リリース前にゴールデンデータセット（100件以上）を必ず準備。週次での自動評価を義務化。

落とし穴④ コスト見積もりが甘い

PoCは少量リクエストなのでコストが安く見える。本番の実リクエスト数で計算せず、スケールアップ後に予算超過する。

対策: 本番の見込みリクエスト数 × 1リクエストのトークン数 × 単価 を必ず計算。余裕を持たせて1.5倍の予算を見積もる。

落とし穴⑤ セキュリティを後回しにする

「まず動かす」を優先し、個人情報のマスキング・プロンプトインジェクション対策・アクセス制御を後回しにする。

対策: PoCの段階からテストデータ（本物の個人情報を含まないダミーデータ）を使う習慣をつける。本番移行前にセキュリティチェックリストを必ずクリア。

---

この章のまとめ（3ポイント）

1. AIシステム構築の選択肢は3つ。「API利用」は最も手軽、「RAG」は社内データと組み合わせたい場合、「ファインチューニング」は振る舞い・口調を変えたい場合。最初にRAGやファインチューニングに飛びつかず、まずAPIとプロンプトエンジニアリングで試す

2. コスト感覚を持つことが重要。2026年の格安モデルは月1万件処理で数百円〜数千円。高性能モデルでも数万円台。PoC段階で見込みコストを計算する習慣が失敗を防ぐ

3. 作って終わりではなくLLMOpsが本番。リリース後の評価（Evals）・モニタリング・ガードレールの運用こそが、AIシステムを「使えるもの」に育てる。ゴールデンデータセットと週次評価のサイクルを最初から設計に組み込む

---

もっと知りたい人へ

• LangChain公式ドキュメント（langchain.com）: LangChainの最新チュートリアル。RAGの構築手順が初心者向けに整理されている
• LlamaIndex公式ドキュメント（llamaindex.ai）: RAGに特化した実装例が豊富。Pythonを少し書ける人はここから始めるのが最短
• RAGAS公式（ragas.io）: RAGシステムの評価フレームワーク。評価指標の定義と実装方法を学べる
• Unsloth（unsloth.ai）: QLoRAによるファインチューニングを誰でも試せるフレームワーク。Google Colabで無料GPU使用可能
• 『Building LLM Apps』（O'Reilly）: LLMアプリケーション開発の体系的な教科書。PythonとLangChainを使った実装中心