はじめに：そのRAG構築、本当に必要ですか？
企業のDX現場、特にAI導入のプロジェクトにおいて、ある種の「強迫観念」が見受けられることが増えています。それは、「社内データをAIに検索させるなら、RAG（検索拡張生成）を構築しなければならない」という思い込みです。
確かに、RAGは素晴らしい技術です。膨大なデータの中から関連情報をベクトル検索で抽出し、LLM（大規模言語モデル）に回答させる仕組みは、理論的に美しく、スケーラビリティがあります。しかし、現場の実情はどうでしょうか。
「ベクトルデータベースの選定はどうする？」
「チャンク（分割）サイズやオーバーラップの最適値は？」
「ドキュメントが更新された時のインデックス再構築フローは？」
もし、従業員数千名以上の大企業で、潤沢な予算と専任のエンジニアチームを持っているなら、迷わずRAGを構築すべきでしょう。しかし、多くの中堅・中小企業の担当者の方々は、もっと切実な状況に置かれています。
「情シスは兼務含めて2名だけ。Pythonコードの保守なんて無理」
「初期費用で数百万円もかけられない。失敗したら責任問題になる」
そのような現場において、高機能だが複雑なRAGシステムは、導入後に「運用できない技術的負債」になりかねません。
ここで紹介するのは、従業員300名規模の中堅製造業などで有効な、ある意味で「逆張り」のアプローチです。RAG構築をきっぱりと諦め、その代わりに選ぶのが、Claude 2.1の200kトークン（約15万文字）という圧倒的なコンテキストウィンドウを活用し、必要なデータを「まるごと」プロンプトに含めるという、一見すると乱暴な、しかし極めて合理的な手法です。
適切に導入した場合、開発期間わずか2週間程度で、高い回答精度を達成する事例があります。そして何より、システム構成がシンプルであるため、運用負荷を大幅に軽減できます。
本記事では、この「持たないAI導入」の全貌を、詳細に解説します。技術的な優劣ではなく、ビジネスにおける「適正技術」の選び方として、一つの解を提示できればと思います。
【導入背景】中堅製造業が直面する「持たない」AI導入の壁
属人化した社内規定問い合わせ対応の限界
製造業の現場では、高い技術力の一方で、バックオフィス業務に紙文化や古い慣習が残っているケースが珍しくありません。例えば、総務課長と少人数の情報システム担当者だけで数百名の従業員を支えているような組織を想像してください。
こうした現場で共通する深刻な悩みが、「社内問い合わせ対応」による業務圧迫です。
「就業規則、経費精算規定、出張旅費規定……。社内ポータルにPDFで掲載していても、誰も参照しません。『結婚祝い金はいくらか』『新幹線のグリーン車利用規定はどうなっているか』といった電話やチャットが、毎日総務や情シスに殺到します。ひどい時は、それに対応するだけで担当者の半日が潰れてしまいます」
こうした課題解決のため、多くの企業がChatGPTなどのLLMを活用したチャットボット導入を検討します。しかし、ベンダーに見積もりをとった段階で壁に直面します。社内データを学習・検索させるRAGシステムの構築費用として、数百万円規模の初期投資に加え、月額数十万円の保守費用が提示されることが一般的だからです。
「経営陣に稟議を通せる金額ではない」「規定が変わるたびにベンダーへの改修費用が発生する懸念がある」。こうしたコストと運用の不透明さが、導入の大きな障壁となっています。
RAG構築の壁とリソース制約
中堅・中小規模の組織において、「運用の持続可能性」はコスト以上に切実な問題です。
最新のAI技術動向を見ると、RAGシステムはGraphRAGやマルチモーダル対応など高度化が進んでいます。しかし、その裏側では運用の難易度も上がっています。公式サイトや技術コミュニティの情報によれば、実用的なRAGシステムを維持するためには、「Ragas」のような評価フレームワークを用いて、検索精度や生成品質を継続的にモニタリングし、LLMのバージョンアップに合わせてチューニングし続ける必要があります。
情シス担当者が1〜2名という体制で、高度なベクトルデータベース（PineconeやWeaviateなど）の管理や、複雑なRAGパイプラインのメンテナンスを抱え込むことは、将来的な「技術的負債」になりかねません。
「担当者が退職したら、誰もメンテナンスできないシステムになってしまう」。
現場が求めているのは、最高性能の複雑なAIではなく、「明日から使えて、誰でも直せる、メンテナンスフリーな検索システム」なのです。
目指したのは「メンテナンスフリー」の検索システム
この課題に対し、現実的かつ強力な解決策として提案したいのが、「RAGを捨てて、Claudeの長文コンテキスト一本でいく」という戦略です。
一般的な企業の主要な社内規定ドキュメントをすべて集めても、文字数にして10万〜15万文字程度に収まるケースが多くあります。これは、Claudeの最新モデルが提供する20万トークン（日本語でおよそ15万〜20万文字相当以上）のコンテキストウィンドウの範囲内に十分に収まります。
「データベースを構築する必要はありません。毎回、質問と一緒に規定集の全テキストをAIに読み込ませればいいのです」
一見すると「力技」に思えるかもしれません。しかし、外部データベースや複雑な検索ロジックを一切持たないため、管理コストは劇的に下がります。リソースの限られた組織にとって、この「持たない」アプローチこそが、最も合理的で持続可能なAI導入の形となるのです。
【検討プロセス】なぜ「RAG」ではなく「Claude 2.1」単体を選んだのか
RAG構築における「見えないコスト」の試算
RAGは、大規模な知識ベースを扱う上では必須の技術ですが、小・中規模のデータセットに対しては「オーバースペック」になることがあります。RAGを構築・運用するために必要な「見えないコスト」を洗い出してみましょう。
- データ前処理の複雑さ: PDFをテキスト化し、適切な長さ（チャンク）に分割する必要があります。文脈が途切れないように分割するのは難しい場合があります。
- ベクトル化とインデックス管理: 分割したデータを埋め込みモデル（Embedding）でベクトル化し、DBに保存します。ドキュメントが更新されるたびに、該当部分の削除と再登録が必要です。
- 検索精度のチューニング: ユーザーの質問に対して、適切なドキュメントがヒットしない（検索漏れ）場合、検索アルゴリズムの調整やリランク（再順位付け）処理が必要になる可能性があります。
これらはすべて、高度なエンジニアリングスキルを要求します。
Claude 2.1の20万トークンがもたらしたパラダイムシフト
一方、Claude 2.1（およびその後のモデル）が提供する200kトークンという巨大なコンテキストウィンドウは、この前提を覆しました。
「検索して抽出する」のではなく、「全部渡して読んで考えてもらう」。
人間で言えば、質問されるたびに書庫へ走って該当ページを探すのがRAG。対して、超人的な記憶力を持つアシスタントに「このマニュアル一冊、今すぐ全部読んで回答して」と渡すのがロングコンテキスト活用です。
比較表：RAG構成 vs ロングコンテキスト構成
一般的な比較検討の結果は以下の通りです。
| 項目 | RAG構成（一般的アプローチ） | ロングコンテキスト構成（Claude 2.1活用） |
|---|---|---|
| 初期構築期間 | 2〜3ヶ月 | 1〜2週間 |
| 必要技術 | Vector DB, Embedding, Python応用 | Prompt Engineering, Python基礎 |
| データ更新 | 複雑（インデックス再構築が必要） | 極めて容易（テキストファイルを置き換えるだけ） |
| 回答精度 | 検索精度に依存（検索漏れリスクあり） | AIの読解力に依存（文脈理解が高い） |
| ランニングコスト | DBサーバー費 + API費 | API費のみ（ただし単価は高くなる可能性） |
| 向いている規模 | 大規模（数百万文字以上） | 小・中規模（〜15万文字程度） |
「テキストファイルを置き換えるだけ」という更新の容易さは、大きなメリットとなります。これなら、専任のエンジニアでなくても更新作業が可能です。
【実装詳細】全データをプロンプトに埋め込む「力技」の技術的現実
では、具体的にどのようにシステムを構築すればよいのでしょうか。技術的な実装アプローチを解説します。基本構成として、Streamlit（PythonのWebアプリフレームワーク）などでUIを作成し、バックエンドでAnthropic APIを呼び出すシンプルな構成が一般的です。
社内規定データ（約15万文字）の構造化とクレンジング
「全部読ませる」といっても、PDFをそのままバイナリデータとして渡すのは得策ではありません。Claudeの最新モデルはPDFの直接読み込みにも対応していますが、検索精度を高め、トークン消費を最適化するためには、テキスト抽出と構造化がベストプラクティスです。
まず、社内の主要な規定PDF（約30ファイル相当）をテキストデータに変換します。ここで重要なのは、「ノイズの除去」と「構造の明示」です。
- ヘッダー・フッターの削除: ページ番号や社外秘マークなどのノイズを除去します。
- Markdown形式への変換: 表組みや見出しをMarkdownで表現することで、AIが文書構造を理解しやすくなります。
- メタデータの付与: 各規定の冒頭に
【出張旅費規定】といったタイトルや改定日を明記します。
これらを1つの巨大なテキストファイル（またはJSON）に結合します。この処理を行うPythonスクリプトを用意し、所定のフォルダにファイルを置けば自動で結合テキストが生成されるパイプラインを構築するのが効率的です。
プロンプトエンジニアリングの工夫：XMLタグの活用
Claudeシリーズは、プロンプト内でXMLタグを使用することで、データ構造や指示の意図を正確に理解する特性があります。これは最新モデルでも変わらない重要なテクニックです。
以下のような構造でプロンプトを設計することが推奨されます。
System:
あなたは組織の優秀な総務アシスタントAIです。
以下の <documents> タグ内に記載された社内規定のみに基づいて回答してください。
知識に含まれない質問には「規定集には記載がありません」と答えてください。
<documents>
{ここに全規定テキスト15万文字を展開}
</documents>
User:
{ユーザーの質問}
このように <documents> タグで囲むことで、Claudeは「ここからここまでが参照すべき資料（Context）である」と明確に認識します。これにより、外部の一般常識（一般的な労働基準法の知識など）と混同することなく、あくまで自組織の規定に基づいて回答するよう制御できます。
また、指示出しにおいては「何を（What）」を明確にし、「どのように（How）」はAIに任せるというアプローチが有効です。複雑な推論が必要な場合は、思考のプロセス（Chain of Thought）を出力させるよう指示に追加すると、回答精度がさらに向上します。
応答速度とコストの課題：Prompt Cachingによる解決
かつて、毎回数十万トークンを送信する手法は、応答速度（レイテンシ）とコストの面で課題がありました。しかし、現在はPrompt Caching（プロンプトキャッシュ）機能によって、この問題は劇的に改善されています。
Prompt Cachingは、プロンプトの大部分を占める「社内規定データ」部分を一時的に保存（キャッシュ）する技術です。
- コスト削減: キャッシュされた部分の入力トークンコストは大幅に割引（最大90%程度）されます。
- 速度向上: 規定データを毎回処理する必要がないため、Time to First Token（最初の文字が出力されるまでの時間）が劇的に短縮されます。
この機能により、「力技」に見えた全データ埋め込みアプローチが、経済的かつ実用的なソリューションへと進化しました。導入プロジェクトでは、このキャッシュ機能を活用することで、検索システムとしての即応性を確保しつつ、ランニングコストを現実的な範囲に収めることが可能です。
また、開発プロセスにおいては、計画と検証のループを回すことが重要です。初期のプロンプトで完璧を目指すのではなく、実際の質問パターンを用いて回答精度をテストし、AIの挙動を見ながら指示（System Prompt）を微調整していくことで、信頼性の高い社内検索AIが完成します。
【検証と成果】回答精度95%を達成した運用実績とユーザーの反応
導入から数ヶ月経過した運用実績の例では、当初の期待を上回る成果が報告されています。
「ハルシネーション（嘘）」を抑制できた意外な理由
AI導入で最も恐れられるのが「もっともらしい嘘（ハルシネーション）」です。しかし、今回の構成ではハルシネーションが極めて少なく抑えられました。
理由はシンプルです。「情報が欠落していないから」です。
RAGの場合、検索システムが誤って関係ないチャンクを拾ってきたり、重要なチャンクを取りこぼしたりすると、AIは断片的な情報から無理やり回答を生成しようとして嘘をつきます。しかし、ロングコンテキストですべての情報を渡していれば、AIは文脈全体を把握できます。「第1条にはこうあるが、第15条に例外規定がある」といった、離れた場所にある情報の関連性も正しく理解できるのです。
結果、回答の正確性は95%以上と考えられます。
総務部への問い合わせ件数が月間40%減少
導入事例の中には、チャットツール上のbot経由で月間約500件の質問が処理されたケースがあります。その結果、バックオフィスへの電話・メール問い合わせが前年同月比で40%減少したという報告も存在します。
現場の担当者からは、「一番助かるのは、『書いてないこと』を『書いてありません』と即答してくれることだ」という声がよく聞かれます。人間なら「念のため」と調べ回る時間も、AIなら一瞬で「規定内には存在しません」と判断してくれるため、従業員の無駄な検索時間も削減されました。
運用コスト：API利用料とサーバー代の実費公開
気になるコストですが、中堅規模の企業における導入事例では、月間のAPI利用料は約3万円〜5万円程度で推移するケースが多く見られます（プロンプトキャッシュ適用前）。
- 初期開発費：内部人件費のみ（実質0円）
- サーバー費：社内の既存コンテナ基盤に相乗り（実質0円）
- API利用料：月額平均4万円
ベンダー見積もりの「初期500万＋月額20万」と比較すれば、圧倒的なROI（投資対効果）です。API利用料が多少増えたとしても、保守運用にかかる人件費が不要であることを考えれば、メリットがあると考えられます。
【リスクと対策】「RAG不要」アプローチが向く企業・向かない企業
ここまで良いことづくめのようにお話ししましたが、専門家として公平にリスクと限界もお伝えしなければなりません。この「全部読ませる」アプローチは、すべての企業に適しているわけではありません。
データ量が増えた時の「卒業ライン」を見極める
最大の制約は、コンテキストウィンドウの上限です。Claude 2.1の200kトークンは広大ですが、無限ではありません。日本語で約15万〜20万文字。マニュアルが数千ページに及ぶ場合や、過去数年分の全議事録を検索したいといったニーズには対応できません。
実務の現場では、「規定集の文字数が20万文字を超えそうになったら、その時初めてRAGへの移行を検討する」という方針を推奨しています。この「卒業ライン」をあらかじめ設定しておくことが重要です。
セキュリティとプライバシーデータの取り扱い
社内規定のような「公開情報（社内では）」なら問題ありませんが、個人情報や極秘技術情報を含むデータを外部APIに送信することには慎重であるべきです。
Anthropic社の商用API利用規約では、デフォルトで入力データはモデルの学習に使用されない（Zero Data Retention）設定になっていますが、企業のセキュリティポリシーによっては、API利用自体がNGとなる場合もあります。その場合は、Azure OpenAIのような閉域網での利用や、ローカルLLMの検討が必要になりますが、そうなると「手軽さ」というメリットは失われます。
将来的なRAG移行を見据えた設計思想
技術は日進月歩です。今、無理をして高価なRAGシステムを作っても、1年後にはもっと安価で高性能なソリューションが出ている可能性があります。まずはClaudeのロングコンテキストで「AI検索の利便性」を社内に浸透させ、データが溢れるほど活用が進んでから、本格的なシステムへ投資する。このステップこそが、変化の激しいAI時代における最適解だと考えられます。
まとめ：技術の「引き算」がDXを加速させる
「最新技術を使わないとDXではない」という誤解が、多くのプロジェクトを複雑にし、失敗させています。
こうしたアプローチが教えてくれるのは、「自社の課題サイズに合った適正技術を選ぶ」ことの重要性です。ベクトルDBという重荷を捨て、Claude 2.1という強力なパートナーの「腕力」に頼ることで、リソース不足という弱点を克服できる場合があります。
もし、社内AIの構築で「技術的な難易度」や「コストの壁」にぶつかっているなら、一度立ち止まって考えてみてください。「そのデータ、実は全部プロンプトに入るんじゃないか？」と。
RAGを構築するのは、それが本当に必要になってからで遅くありません。まずは手元のテキストファイルを束ねて、Claudeに投げかけてみることから始めてみませんか？
コメント