チャットボットと AIエージェント Advent Calendar 2025

株式会社ナレッジコミュニケーション

仕事で使う生成AI入門：知識カットオフとWeb検索/RAG、モデル選び

Last updated at 2025-12-24Posted at 2025-12-24

はじめに
概要
1. 「知識カットオフ」とは何か？
2. “最新情報”を扱う方法は3つ
3. 「RAG/検索があるのに、使えてない」あるあると対策
4. モデルの「得意・不得意」は何で決まる？
5. 仕事で事故らないための「質問テンプレ」
6. セキュリティ/コンプラで最低限知っておくこと
7. まとめ
おわりに
参考文献

はじめに

この記事は株式会社ナレッジコミュニケーションが運営するチャットボットと AIエージェント Advent Calendar 2025 の24日目にあたる記事になります！

これを読んでくれている皆様、生成AIライフを楽しんでいますでしょうか？
生成AIって便利ですよね？
お仕事で使うことも出てきているかと思います。

しかし、生成AIを使う人が増える一方で、

「知識カットオフ」を知らずに、最新情報や規約/法令の話をそのまま信じてしまう
「Web検索/RAGが使える」と聞いているのに、実際は根拠が出てこない（または誤った根拠）
「モデルが違うと何が違うの？」が共有されていない

という状態だと、 “便利だけど怖い” ツールになりがちです。

この記事のゴールは、 生成AIを使うときの共通言語（期待値）を揃えること です。
具体的には「この質問はカットオフの影響がある？」「今は検索/RAGが必要？」「どのモデルを選ぶ？」を、誰でも同じ粒度で判断できる状態を目指します。

概要

生成AI（LLM）は “検索”ではなく 、学習済み知識＋入力文脈から文章を生成します。学習データには期限があり、それが 知識カットオフ（Knowledge cutoff） です。
「Web検索機能」や「RAG（社内文書検索）」があっても、毎回うまく使われるとは限りません。必要なときに“参照”させ、根拠を出させるのがコツです。
モデルには得意不得意があるので、 用途で使い分け（速さ重視／品質重視／長文処理／ツール連携など）すると失敗が減ります。
セキュリティ面では「社内情報の投入」「プロンプトインジェクション」が典型的な落とし穴となります。 ガードレール（Guardrails）やコンテンツフィルタ の使いどころも押さえておくと安心です。

1. 「知識カットオフ」とは何か？

ここでは、「知識カットオフ」についてお話しします。

1.1 知識カットオフ＝“学習データの最終時点”

LLMは、学習時点までの情報をもとに回答します。
その“学習が止まっている日付”の目安が、知識カットオフです。

OpenAIのモデル比較ページでは、モデルごとに知識カットオフが明記されています（例：GPT-5.2 は 2025-08-31（参照日2025-12-24）)
Claudeでも同じようにモデルごとの知識カットオフが明記されています（Claudeモデル概要）。

重要
カットオフ後の出来事（新製品、最新障害、組織改編、法改正、社内ルール更新など）を、LLMは「知らない」のが基本となります。
知らないのに“それっぽく答える”ことがあるのが厄介で怖いポイントです。

1.2 「モデルに“知識のカットオフいつ？”と聞く」だけだと危ない

カットオフはモデル自身が正確に自己申告できるとは限らないので、原則は公式ドキュメントで確認するのが安全です。

例えば、OpenAIでは「モデルによって現在の出来事への知識は異なる」こと、そして不足分はツールで補う、という整理をしています。 (help.openai.com)

2. “最新情報”を扱う方法は3つ

仕事で扱う情報には、大きく分けると以下の3種類があると考えられます。

普遍的/安定的な知識（概念説明、一般的な文章改善、基礎的な手順のたたき台）
最新の公開情報（プレスリリース、価格、障害、仕様変更）
社内固有の情報（社内規程、運用手順、案件固有の前提）

それぞれで、LLMに渡す“情報源”が変わります。

2.1 Web検索（公開情報のアップデートに強い）

OpenAI API の例では、学習カットオフと現在の出来事のギャップを埋めるために、Responses APIのツールとして Web Search / File Search を挙げています。 (help.openai.com)

ただし、Web検索は「見つかる情報の質」がまちまちなので、 出典の吟味が必須 です。

2.2 RAG（社内文書・ナレッジに強い）

RAG（Retrieval-Augmented Generation）は、ざっくり言うと

まず検索（Retrieve）
見つけた文書の一部を入力する情報に差し込み（Augment）
その情報に基づいて生成（Generate）

するやり方です。

Azure側でも、Azure AI Searchを使った「Classic generative search（RAG）」のQuickstartが整理されています。

AWS側でも Knowledge Bases for Amazon Bedrock が “フルマネージドなRAG機能”として、取り込み→分割→embedding→検索→プロンプト拡張を扱い、Retrieve / RetrieveAndGenerate といったAPIや citation（出典）も提供すると説明されています。

2.3 人間のレビュー（最後の砦）

LLM＋検索/RAGでも、最終的に

社内の意思決定
顧客に出す正式文書
契約・法務・会計・セキュリティ判断

のような領域は、人間の責任で裏取りが必要です。
この部分については、LLMは責任を負えないものとなります。

3. 「RAG/検索があるのに、使えてない」あるあると対策

あるある1：根拠が出てこない（＝検索してない/参照してないかも）

対策：質問の時点で、根拠の出し方を指定します。

例（利用者向け）：

「社内文書（RAG）を参照して、 文書名＋該当箇所の引用（短く） を添えて答えて」
「根拠が見つからない場合は、推測せず『不明』と言って」

あるある2：RAGや検索の結果がズレている（＝検索品質の問題）

RAGは検索なので、以下があると精度が落ちます。

文書が古い（更新されていない）
文書の分割（chunking）が悪い
用語が揺れている（略語・別名）
権限/スコープの問題で検索できていない

アプリ側の改善（インデックス設計、メタデータ、更新頻度）でもある程度問題を解決することができますが、最も重要なのは 参照するデータの品質 となります。

4. モデルの「得意・不得意」は何で決まる？

LLMはモデルごとに得意・不得意があり、同じベンダーでも世代や設定で挙動が変わります。
まずは「このタスクで何を優先するか」を、以下の軸で揃えると判断がブレにくくなります。

品質（推論/一貫性）：複雑な意思決定、設計レビュー、障害解析、最終レビュー
速度/コスト：下書き、要約、テンプレ作成、定型タスク
コンテキスト（長文耐性）：仕様書・ログ・議事録などのまとめ読み
ツール連携：Web検索、RAG、社内API呼び出し（エージェント）
入出力モダリティ：画像/音声など
指示追従・再現性：フォーマット（箇条書き/JSON）、禁止事項、「不明なら不明」を守れるか

4.1 おすすめの“2段階運用”（標準＋高品質）

最初から細かく使い分けるより、まずは 2枠で運用するのが安全です。

標準モデル（速い/低コスト）：下書き・要約・文章整形・アイデア出し
高品質モデル（じっくり/高コスト）：重要文書、設計/障害、意思決定支援、最終レビュー

切り替えの目安：失敗コストが高い／根拠が必要／前提が曖昧／社外に出す → 高品質モデルに切り替え

4.2 モデル選定は“比較”より“使い分け＋運用”で決める

モデルは“どれが最強か”より、使い分けルールと運用の安定化を先に決めるのが安全だと考えられます。

まずは 標準モデルで「たたき台」を作る（完璧より速さ）
次に当てはまる場合は 高品質モデルに切り替える（失敗コスト優先）
- 顧客提出・正式文書（メール/提案書/FAQなど）
- 組織の意思決定に使う（稟議・方針・判断材料）
- 設計/障害など、誤りの影響が大きい
- **根拠（出典）**が必須（Web検索/RAGの参照＋短い引用が必要）
運用側のポイント：重要タスクは モデル固定＋ミニ評価で品質を安定させる
- 自社の実データから 5〜10タスクを選び、同条件（プロンプト/設定/ツール）で比較し、定期的に見直す
- 評価観点（例）：指示追従／根拠提示（出典＋引用の対応）／再現性／速度・コスト（SLA/工数）

5. 仕事で事故らないための「質問テンプレ」（初心者向け）

5.1 まずこれだけ書く（5点セット）

目的：何のために？
前提：何が決まっていて、何が未確定？など
制約：守るべきルール（社内規程、納期、文字数、トーン）
出力形式：箇条書き／表／手順／メール文面など
根拠：出典（Web or 社内文書）を出してほしいか

例（コピペ用）：

目的：〜をしたい
前提：〜は確定、〜は未確定など
制約：社内規程Xに従う。機密情報は出さない
出力形式：結論→理由→次アクション（箇条書き）
根拠：参照した社内文書名（またはURL）と、該当箇所を短く引用して
不明な場合：推測せず「不明」と言って、追加で必要な情報を質問して

例（実際に入力する場合）：

以下の文章を、社内向けのお知らせ文として「読みやすく・誤解がない」ように書き直したいです。

目的：社内ポータルに掲載する告知文を整える
前提：読み手は非エンジニアが多い
制約：600〜900文字。断定しすぎない。煽り口調にしない
出力形式：結論→要点（箇条書き）→注意事項→次アクション
根拠：不要（文章改善のみ）。ただし不確かな内容が含まれる場合は「不確か」と指摘して

以下の文章：
---
生成AIはめちゃ便利なのでどんどん使いましょう。最近はWeb検索もできるので基本なんでも答えられます。
社内資料を貼り付けると精度が上がるので、困ったら資料をそのまま入れてOKです。
回答はだいたい正しいので、急いでるときはそのまま顧客に出しても大丈夫です。
---
不明な場合：推測せず「不明」と言って、確認すべき点を最大3つ質問して

5.2 「最新情報」かどうかを最初に判定させる

知識カットオフに引っかかりそうなときは、冒頭でこう頼むと事故が減ります。

この質問は知識カットオフの影響を受けますか？
受ける場合は、(1) Web検索 or (2) 社内RAG のどちらが必要か提案してから回答してください。

6. セキュリティ/コンプラで最低限知っておくこと

6.1 入れてはいけないもの：秘密情報・個人情報

社内アプリ経由だとしても、入力したものがログ/監視/評価に使われ得る前提で運用設計すべきです。

Azure側のデータ取り扱いについては、Microsoft Foundryとして「プロンプト/応答が基盤モデルの学習に使われない」「モデルはステートレス」等が明記されています。 (learn.microsoft.com)

注意
「入力して良い情報の線引き」は、技術だけでなく組織のルール（法務/セキュリティ）で決める領域です。
この記事は方針決定の代わりにはなりません。社内規程に寄せてください。

6.2 プロンプトインジェクション（Prompt injection）を知っておく

RAGやWeb検索を使うと、モデルは「外から取ってきた文章」を読みます。
その文章の中に “前の指示を無視して…” のような“悪い指示”が混ざるのが、プロンプトインジェクションです。

これらの対策も今後AIを活用していくうえで重要になっていきます。

7. まとめ

この記事のまとめです。

LLMは万能な検索ではない。知識カットオフがあり、最新情報は検索/RAG/人間レビューで補う。
「RAGや検索があるのに微妙」は、たいてい 根拠を出させてない か 検索品質の問題。運用と仕組みの両方を直す。
モデルは用途で使い分ける。まずは 標準モデル＋高品質モデルの2段階から。
セキュリティは「入力していい情報」と「プロンプトインジェクション対策」を最優先で整える。

おわりに

AIを活用した業務効率化や、AIエージェント実装にご興味があれば、ぜひ弊社にお気軽にご相談ください。

参考文献（参照日: 2025-12-24）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up