RAG精度は「データ準備」で9割決まる。カスタムGPT構築前に埋めるべきナレッジエンジニアリングの溝

PoCで「使えない」と判断される前に

「社内マニュアルを全部PDFで読み込ませたのに、トンチンカンな回答しか返ってこない」
「重要な注意事項を無視して、AIが勝手に嘘をつく（ハルシネーション）」

AI導入の現場、特にRAG（Retrieval-Augmented Generation：検索拡張生成）を用いたカスタムGPTの構築プロジェクトにおいて、こうした課題に直面するケースは決して珍しくありません。多くのDX担当者が、OpenAIの「GPTs」や各種RAGツールのデモを見て、「ファイルをドラッグ＆ドロップすれば、明日から自社専用の有能なアシスタントが誕生する」という期待を抱いてしまいます。

しかし、現実はそう単純ではありません。

たしかに基盤となるAIモデルの進化は目覚ましく、OpenAIの環境でもGPT-4o等のレガシーモデルが段階的に廃止され、100万トークン級のコンテキストや高度な推論能力を備えたGPT-5.2、あるいはコーディングや開発タスクに最適化されたGPT-5.3-Codexといった新たな標準モデルへの移行が進んでいます。既存のチャット環境が新モデルへ自動移行されるなど、AI自体の処理能力は飛躍的に向上しています。

それでもなお、画像認識や自然言語処理を組み合わせたシステム開発の観点から言えば、「入力されるデータ品質がAIの性能上限を決定する」という原則は揺るぎません。最新モデルがどれほど長文や複雑な推論を安定して処理できるようになったとしても、テキストベースのRAGにおいては、人間が無意識に行っている「文脈の補完」や「レイアウトからの意味理解」を、AIは依然として読み違えるリスクを抱えています。

本記事では、ツール選定やプロンプトの調整に取り組む前に、ビジネスサイドがしっかりと向き合うべき「ナレッジエンジニアリング（知識の構造化）」について、開発着手前に確認すべきチェックリストと共に論理的に解説します。これは、AI導入を単なる「実験」で終わらせず、実際の業務プロセスに定着させるための極めて実用的なステップとなります。

なぜ「ドキュメントを読み込ませるだけ」では失敗するのか

まず、根本的な誤解を解く必要があります。多くの人は、RAG（検索拡張生成）を「高機能なキーワード検索エンジン」の延長線上で捉えています。しかし、生成AIが行っているのは単なる検索ではありません。「検索結果を文脈として取り込んだ上での、もっともらしい文章の生成」です。

ナレッジグラフを活用したアプローチや、画像認識と自然言語処理を統合して処理する高度なRAGといった技術が登場しても、この原則は変わりません。例えば、Amazon Bedrock Knowledge Basesではグラフデータベース（Amazon Neptune Analyticsなど）を活用した検索機能がプレビュー提供されるなど、情報の関係性を捉える仕組みは日々進化しています。それでも、データ分析やシステム開発の基本として、処理が高度化すればするほど、入力されたデータの品質が最終的なアウトプットにダイレクトに影響するという事実に変わりはありません。

検索ツールと「特化型AI」の決定的な違い

従来のキーワード検索であれば、検索結果にノイズ（無関係なドキュメント）が含まれていたとしても、人間がタイトルや要約を見て「これは探しているものと違う」と判断し、無視できました。ところがRAGの場合、検索システムが取得したドキュメント（チャンク）はすべて「正解の根拠」としてAIモデルに直接入力されます。

もし、その根拠データの中に、すでに廃止された古い規定、他と矛盾する記述、あるいは「前後の文脈がなければ意味不明な断片」が混ざっていたらどうなるでしょうか。AIはそれらを真実として受け取り、自信満々に誤った回答を生成してしまいます。これが「Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）」の原理であり、どれほど最新のAIモデルを採用したとしても回避できない本質的な課題と言えます。

ナレッジエンジニアリングがROIを左右する理由

AIにドキュメントの意図を正しく理解させるためには、人間向けに書かれた文章を、AIが処理しやすい論理的な構造へと翻訳・加工する工程が求められます。これがナレッジエンジニアリングの核心です。

具体的な例を挙げてみましょう。社内規定のPDFに「特例措置として、以下の場合は除く」という記述があったとします。人間であれば、視覚的なレイアウトやインデントを見て、それがどの条項にかかる特例なのかを直感的に把握できます。しかし、単にテキストだけを抽出したデータでは、この「特例」がどこに掛かっているのかという重要な構造情報が欠落してしまいます。その結果、AIは全く関係のない質問に対して、誤ってこの特例を適用してしまうリスクを抱えることになります。

現在では、単純なテキストだけでなく、図表や複雑なレイアウト構造を含めて統合的に理解させるアプローチや、前述のように情報の関係性をグラフ構造で定義する手法も普及しつつあります。しかし、この「知識の構造化」という地道な作業を飛ばして、高価なベクトルデータベースや高性能なモデルだけを導入したとしても、期待するような回答精度は得られず、投資対効果（ROI）は見込めません。精度の高いシステムを構築するためには、まず足元にある自社データを見直し、整理することから始める必要があります。

Phase 1：データ資産の「AI可読性」評価チェック

では、具体的にどのような準備が求められるのでしょうか。まずは、保有しているデータ資産がAIにとって「読みやすい」状態にあるかを診断します。単にファイルを集めるだけでなく、データ品質の観点から基礎的な準備状況を評価することが重要です。

暗黙知と形式知の棚卸し状況

最も厄介なのが、ドキュメントに書かれていない「暗黙の了解」です。人間であれば前後の文脈や業務経験から推測できる内容も、AIにとっては理解不能なノイズとなるケースが珍しくありません。

• チェック項目:
  • 「最新版」の定義は明確か？
    • Why: ファイル名に「_final」「_v2」「_最新」などが乱立していると、AIはどれを正とすべきか判断できません。複数バージョンの情報が混ざることで、回答の精度が著しく低下します。
    • What: 参照すべき唯一の正解ソース（Single Source of Truth）を特定し、古いファイルを隔離する運用ルールを徹底します。
  • 「あれ」「それ」の指示語が解決されているか？
    • Why: 会話形式の議事録やメール文面などは、文脈依存度が高すぎてRAGの検索対象としては不向きです。指示語が多い文章は、単独のチャンク（情報の塊）として切り出された際に意味を成さなくなります。
    • What: Ｑ＆Ａ形式にリライトするか、学習対象から除外する判断を下します。人間なら文脈で分かる情報も、主語や目的語を明文化しておく工夫が求められます。

ドキュメントの構造化レベル診断

画像認識技術の領域では、画像内の複雑な状況推論や物体特定の能力が進化しています。近年では、ドキュメント解析に特化したモデルも登場しており、レイアウト、表、数式、手書き文字などを高精度に理解し、MarkdownやLaTeXなどの構造化データとして出力する技術が発展してきました。

しかし、一般的なRAG構築においてPDFやPowerPointを単純なテキストとして抽出する場合、これらの視覚的な文脈（レイアウトによる意味付け）が失われ、情報が崩壊してしまうリスクは依然として高いのが実情です。そのため、従来の単純なテキスト抽出から、最新のドキュメント解析モデルを活用した構造化抽出への移行が推奨されます。

• チェック項目:
  • 表組み（テーブル）はテキスト化しても意味が通じるか？
    • Why: 複雑なセル結合を含む表は、単純なテキスト抽出では行と列の関係が破綻します。以前はテキストベースの処理が主流でしたが、現在ではドキュメント解析に特化した画像認識モデルを活用して視覚的構造を維持するアプローチが現実的になっています。
    • What: 表データをMarkdown形式やCSV形式に正確に変換するか、ドキュメント解析モデルを用いて表の内容を文章で要約したメタデータを付与します。
  • 見出し構造（H1, H2, H3）は論理的か？
    • Why: AIはドキュメントを分割（チャンキング）して読み込みますが、見出し構造がないと、その文章が何のトピックに属するのかを見失います。階層構造は、情報同士の関連性をAIに伝えるための重要なシグナルです。
    • What: フォントサイズや太字などの「見た目」だけで見出しを表現せず、ドキュメントのプロパティとして正しい見出しスタイルを適用し、論理的な文書構造を構築します。

専門用語・社内用語の辞書化準備

社内独自の略語（例：「PM」はプロジェクトマネージャーかプロダクトマネージャーか？）は、AIにとって最大の混乱の元です。業界標準とは異なる意味で使われている言葉がないか、あらかじめ洗い出しておく必要があります。

• チェック項目:
  • 社内用語・略語リストはあるか？
    • Why: 一般的なLLMが学習している知識と、社内用語の実際の意味が乖離している場合、ハルシネーション（もっともらしい嘘）を引き起こす原因になります。
    • What: 用語、読み方、定義、類義語を網羅的にまとめたリストを作成し、システムプロンプトや検索時の辞書として組み込む準備を進めます。これにより、AIが社内特有の文脈を正確に解釈できるようになります。

Phase 2：回答精度を担保する「知識検索戦略」の設計

データが綺麗になったら、次はそれをどう「分割」し、どう「検索」させるかの戦略設計です。この工程はシステム開発において非常に重要であり、ビジネス要件と密接に関わる部分と言えます。近年、GPT-4o等のレガシーモデルが廃止され、100万トークン級のコンテキストや高度な推論能力を備えたGPT-5.2のような新世代モデルへの移行が進んでいますが、モデルが高性能化しても「適切な知識をどう渡すか」という検索戦略の価値は変わりません。

チャンク分割（Chunking）の戦略策定

RAGでは、長いドキュメントを「チャンク」と呼ばれる短い単位に分割してデータベースに格納します。この分割サイズと手法が、最終的な回答精度を大きく左右します。

• チェック項目:
  • 意味のまとまりごとの分割方針はあるか？
    • Why: 文字数だけで機械的に切断すると、重要な文脈が分断されてしまいます。たとえば「製品Aの仕様」という見出しと、実際の「内容」が別のチャンクに分かれると、AIは正確な情報を引き出せません。最新モデルは長文処理に優れていますが、ノイズを排除して回答の正確性を高めるためには、意図したサイズでの適切な分割が求められます。
    • What: 章ごと、段落ごと、あるいはQ&A単位など、ドキュメントの性質に合わせた明確な分割ルールを策定します。

メタデータ付与のルール定義

検索の精度と柔軟性を引き上げる強力な武器が「メタデータ（属性情報）」です。本文には直接書かれていない背景情報を、タグとしてデータに付与します。

• チェック項目:
  • 絞り込みに必要な属性は定義されているか？
    • Why: ユーザーが「昨年の営業資料を見せて」と要求した際、本文内に「昨年」や該当する年号が明記されているとは限りません。ファイル作成日や対象年度をメタデータとして保持させる必要があります。
    • What: 作成日、著者、部署、対象製品、ドキュメントの種別（社内規定、マニュアル、日報など）といった多角的なタグ設計を行います。

検索意図と回答範囲のマッピング

• チェック項目:
  • ユーザーの質問パターンを想定できているか？
    • Why: 「全体を要約してほしい」という要望と、「特定のエラーの解消手順を知りたい」という要望では、AIが参照すべき情報の粒度がまったく異なります。特に高度な推論（Thinking機能など）を行う最新モデルの能力を最大限に引き出すには、ユーザーの意図に沿った的確な情報を渡す設計が重要です。
    • What: 現場で想定される質問リスト（Query）と、それに対する理想的な回答ソース（Passage）のペアを作成し、検索ロジックの事前検証に活用します。

Phase 3：運用を見据えた「評価と改善」の体制準備

AIシステムは開発して終わりではありません。むしろ、運用開始後が本番です。AIの回答精度を誰が保証し、どう改善していくかのプロセスが決まっていないと、現場は混乱します。実用的な運用体制の構築が不可欠です。

Ground Truth（正解データ）の作成準備

「精度が低い」と感覚的に評価するのではなく、データ分析に基づき定量的に評価するための基準が必要です。

• チェック項目:
  • 評価用QAセット（ゴールデンデータ）は準備できているか？
    • Why: 修正を加えた際、以前は正解していた質問が間違えるようになる（退行）現象を防ぐためです。
    • What: 頻出質問50〜100件と、その「模範解答」および「参照すべきドキュメント」のセット。

Human-in-the-loop（人による評価）フローの確立

AIの誤りを修正し、知識ベースを更新するサイクルを回す必要があります。

• チェック項目:
  • 回答へのフィードバック経路は確保されているか？
    • Why: ユーザーが「役に立たなかった」と感じた情報を吸い上げないと、AIは継続的に改善されません。
    • What: チャット画面へのGood/Badボタン設置と、Bad評価時の正しい情報をナレッジ管理者が確認・修正する業務フローの策定。

ハルシネーション許容ラインの設定

• チェック項目:
  • 誤回答のリスク許容度は定義されているか？
    • Why: 社内FAQなら多少のミスは許容されても、顧客向け回答や法務関連では許されない場合があります。
    • What: 業務別に「AI回答そのまま利用OK」「人間が必ず確認」「参照ソースのみ提示」といった運用ルールの策定。

最終確認：ドメイン特化GPT導入準備完了度診断

ここまで見てきたチェック項目、プロジェクトにおいていくつ埋まりましたか？

ナレッジエンジニアリングは、地味で根気のいる作業です。しかし、ここを疎かにして高額なAIツールを導入するのは、基礎工事をせずに高層ビルを建てるようなものです。AIシステム開発の現場においても、モデルのアーキテクチャ以上に「高品質なデータセットの構築」が成果を分ける最大の要因となっています。

スコア別アクションプラン

現在の準備状況に応じて、取るべきアクションは明確に分かれます。無理な見切り発車は避け、論理的かつ着実なステップを踏んでください。

• Goサイン（達成率 80%以上）:
  データ基盤は十分に整っています。RAGのプロトタイプ作成や、具体的なドメイン特化モデルのファインチューニング検討に進んでください。
• 要注意（達成率 50%〜79%）:
  部分的な導入は可能ですが、回答精度にムラが出る可能性があります。特に「データの鮮度」や「構造化」の項目で見落としがないか再確認し、不足部分を補強しながらスモールスタートを切ることを推奨します。
• Stop（達成率 50%未満）:
  現段階でのツール導入は時期尚早です。まずは「ドキュメントの整理整頓」から始めてください。それが、遠回りのようでいて、最適なカスタムAIを作るための最短ルートです。

不足項目を補うためのリソースガイド

準備不足の項目が明確になった場合、以下の観点でリソースを配分してください。

• データ整理の人手が足りない: 非構造化データを構造化するためのOCRツールや、データクレンジング専門の外部パートナーの活用を検討します。
• 技術的知見が不足している: プロジェクトメンバーに対し、最新のRAGアーキテクチャやベクトルデータベースに関する学習時間を確保させてください。

次のステップへ：進化するAI技術を受け入れる土台

データ準備が整えば、いよいよ実装フェーズです。技術の世界は日進月歩で変化しており、特に画像認識や自然言語処理を統合したAI技術の進化は目覚ましいものがあります。

例えば、Geminiでは適応型思考（Thinking）プロセスが統合され、複雑な推論能力が飛躍的に向上しています。また、動画生成・理解モデル（Veoなど）における高解像度への対応や、多様なフォーマットのサポート強化など、扱えるメディアの幅も広がっています。

さらに、OpenAIのAPIモデルにおいても世代交代が進んでいます。GPT-4oやGPT-4.1などの旧モデルは2026年2月に廃止され、より長い文脈理解や画像理解、ツール実行能力が向上したGPT-5.2（InstantおよびThinking）が新たな主力モデルへと移行しています。旧モデルに依存したRAGシステムやAPI連携を運用している場合は、機能停止を避けるために、公式ドキュメントを確認しながら速やかに最新モデルへの移行作業（エンドポイントの変更やプロンプトの再調整など）を進める必要があります。このように、AIがテキストだけでなく画像などのデータを複合的に処理する能力はビジネスの現場で強力な武器となる一方で、モデルのライフサイクルに合わせた継続的なアップデートが求められます。

しかし、どれほどAIが進化し、思考能力や表現力が向上しても、それを自社のビジネスに最適化させるための「燃料」となるのは、適切に整理された自社データです。

確かなデータ基盤さえあれば、どのような新モデルが登場しても、即座に接続し、価値を引き出すことが可能です。まずは足元のナレッジを固め、AI時代の波に備えましょう。