「詳しい人に聞く」を Claude に置き換えたナレッジ検索

長く続いている案件では、「この方針はいつ決まったのか」を確かめるだけで資料を何本も開き、最後は古くからいるメンバーに聞くことになりがちです。担当しているプロジェクトでは、Box と Backlog にある約 4 万 1,000 件の資料を Markdown 化して索引を作り、Claude に目次をたどらせて出典付きで答えさせるナレッジ検索を作りました。30 分から半日かかっていた調べものが、約 5 分で済むようになっています。

---

背景：調べものが特定の人に集まっていた

担当しているのは、社会インフラ系システムの保守・開発案件です。プロジェクトマネージャーとして、稼働中のシステムの保守、次期システムの開発、お客様向け業務システムの開発、社内システムの提供を並行して見ています。

課題は大きく 2 つありました。

• 対応範囲が広い: 会議の数が多く、宿題の管理が追いつかない。見積などの定常業務も積み重なる
• 暗黙知が多い: 案件が 10 年以上続いているため、方針の経緯を確かめるには資料を何本も開く必要がある。最終的には、長く担当しているメンバーに聞くことがほとんどだった

聞かれる側もすぐに答えられるとは限らず、調べものの待ち時間がそのまま作業の待ち時間になっていました。そこで、詳しい人に聞く前の一次調査を Claude に任せることにしました。

ナレッジ検索の仕組み

ナレッジ検索は、資料を Markdown 化して階層ごとに索引と要約を作り、Claude がその索引をたどって回答する構成です。考え方は、EMNLP 2026 Findings に採択された論文「Corpus2Skill: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG」（Y. Sun, P. Wei, L. B. Hsieh）の手法をもとにしています。

5 つのステップで動かす

処理は次の 5 ステップに分かれています。

1. 原本（Box・Backlog）: 読み取りだけを行い、原本には書き込まない
2. Markdown 化（Mac で日次実行）: Word・Excel・PDF などを Markdown に変換し、共有ドライブに置く
3. 索引・要約の作成（Claude）: 各階層に INDEX とフォルダ要約を作る
4. 依頼文の作成（GAS の画面）: 質問と参照する資料の範囲をまとめ、Claude を起動する
5. 回答（Claude）: 索引をたどり、出典の相対パスを付けて回答する

最初の全件 Markdown 化には時間がかかりますが、一度済めばあとは日次の差分だけを自動で変換しています。

フォルダ要約に「答えられる質問」を書く

Markdown 化した要件整理の資料には、Word の「はじめに」「目的」「要件」といった章立てがそのまま残ります。各フォルダには、そのフォルダにどんな資料が入っているか、どんな質問に答えられるか、配下の文書構成の 3 点を要約として持たせています。Claude はこの要約を読んで、次にどのフォルダへ降りるかを決めます。

利用者は Claude デスクトップだけを用意する

利用者に必要なのは、Google Drive コネクタを接続した Claude デスクトップだけです。ツールの導入やローカルの設定は要りません。GAS で作った画面に質問を入力し、参照する資料（設計書・Backlog など）を選んで Claude を起動すると、依頼文がプロンプトに入った状態で始まります。あとは回答を待つだけです。

デモで「この案件はどんな案件か」と聞いたときは、Claude がナレッジ検索の手順を確認してから索引を順にたどり、案件の概要を出典付きで返しました。実務ではもっと細かく、「ソースコード上でこの処理のフローはどうなっているか」「マスターデータのこのパラメーターはシステム内でどう使われているか」といった調査にも使っています。

RAG と Corpus2Skill の違い

社内ナレッジの検索と聞くと、まず RAG（Retrieval-Augmented Generation）を思い浮かべる方が多いと思います。2 つの違いは、LLM が資料全体の構成を見られるかどうかにあります。論文の Figure 1 が、この違いを 1 枚で示しています。

出典：Y. Sun, P. Wei, L. B. Hsieh「Corpus2Skill: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG」Figure 1（CC BY 4.0）。

上段の RAG では、検索パイプラインが選んだ文書をそのまま LLM に渡します。下段の Corpus2Skill では、LLM エージェントがスキル A に入って外れと判断すると引き返し、スキル B から索引をたどって根拠の文書にたどり着きます。

RAG は検索結果を受け取る

RAG では、検索器が質問文を埋め込みに変換し、類似度の高い上位 k 件の文書を取り出して LLM に渡します。LLM が読めるのは渡された k 件の断片だけです。上位 k 件の外に正解の文書があっても、LLM はその存在を知ることができません。k は 10〜15 件程度に設定することが多く、文書が 10 万件あっても読めるのはその範囲に限られます。

Corpus2Skill は目次をたどって取りに行く

Corpus2Skill では、事前に文書をクラスタリングして要約を重ね、階層構造の索引（スキル）を作っておきます。LLM は最上位の要約から読み始め、質問に関係する枝を選んで下の階層へ降り、最後に文書を ID で取得して回答します。構成が見えているので、外れたら上の階層に戻って別の枝を選び直せますし、複数の枝から根拠を集めることもできます。

各階層で約 p 件の要約を読み、候補を N 件から N/p 件に絞っていくので、読む要約の総数は O(p·log_p N) に収まります。たとえば文書が 6,221 件、分岐比 p = 10 なら階層は 3 段で、読む要約は約 30 件です。

この案件では、クラスタの階層を Box のフォルダ構成で代用し、各フォルダの要約を Claude に作らせています。論文の手法をそのまま実装したのではなく、既存のフォルダ構成を索引として使う形に寄せています。RAG と agentic search の一般的な比較は「RAG と agentic search の違いと選び方」で整理しています。

4 万件規模で運用して直したこと

いまの収録規模は、文書が約 4 万 1,000 件、フォルダが約 1 万 4,700 です。この規模で使い続けるなかで、回答の作法をいくつか決めています。

• 出典の相対パスを必ず付ける: どの索引をたどってどの資料に行き着いたかを、回答から確認できるようにしている
• 選んだ資料の外は参照しない: 根拠が足りないときは参照範囲を勝手に広げず、資料の選び直しを促す。網羅性を保証できない調査では、その旨を回答に書かせる
• 同名ファイルの版を比較する: 運用中に、旧版の資料を最新として回答した例があった。これを受けて、同じ名前のファイルが複数あるときは版を比べる手順を依頼文に追加した

仕組みは横展開キットとしてまとめ、別の案件でも稼働しています。

索引づくりは 1 人で回す

ファイル数が多いと、最初の索引づくりを複数人で分担したくなります。ただ、いまの仕組みには「この文書は処理済み」という目印がないため、複数人で同時に走らせると処理がぶつかるおそれがあります。索引づくりは 1 人で回すのがよいと考えています。4 万件規模でも、1 週間ほど動かしておけば終わるので、初期の導入ハードルとしては許容できる範囲でした。

調べものにかかる時間の変化

経緯や判断理由を確かめる調べものは、導入前は 30 分から半日かかっていました。導入後は、約 5 分で一次回答が返ります。

削減率は、30 分が 5 分になる場合で約 83%、半日（4 時間）が 5 分になる場合で約 98% と見積もっています。1 回あたり 25 分の削減を 1 日 10 回とした最小の条件で、1 人日を 8 時間、年間 240 営業日として換算すると、年間で約 120 人日以上の目安になります。いずれもこの案件での概算で、資料の量や質問の種類によって変わります。

見積と定例会の宿題管理にも広げている

ナレッジ検索のほかに、同じ案件で 2 つの取り組みを進めています。

• 定例会管理ダッシュボード: Gemini の会議メモから宿題を自動で抽出し、会議・人・案件の単位で一覧にする。Backlog に起票しない軽微な課題も把握でき、長期の課題はその場で Backlog に起票できる。削減効果は週約 6 時間（5 分 × 7 人 × 10 会議）、年間約 36 人日の目安
• 雑務の指示書化: 見積・議事録・WBS・文書整形の手順とルールを指示書にまとめ、Claude のプロジェクトに登録している。ファイルを渡して一言依頼すれば、誰が依頼しても同じ品質で出てくる。見積は半日〜1 日かかっていたものが 1〜2 時間（一次作成は約 10 分）になり、年 30〜40 件で年間約 11〜30 人日の目安

3 つの取り組みを合わせると、年間で約 170〜190 人日の削減を見込んでいます（1 人日 = 8 時間、年間 240 営業日で換算した目安）。

次に取り組んでいること：AI がタスクを実行し、人が承認する

いま構築しているのは、タスクをアクションレベルで管理する仕組みです。定例会の議事録などから、「ある日までに証明書を払い出す」といった粒度でタスクを切り出し、1 タスクごとに「背景」「作業内容」「完了条件」を書きます。作業内容はそのまま実行できる手順の粒度で書き、完了条件があることで何をもって完了とするかを判断できるようにします。

この形にすると、Claude がタスクの背景を理解したうえで、ナレッジを参照して調査・回答案・資料の作成まで進められるはずです。人は完了条件を満たしているかを確認して承認するだけにし、結果のドキュメントはナレッジに加えて次のタスクで参照できるようにします。整ったドキュメントが残るほど、次の案件の要件整理や見積もやりやすくなると考えています。

まとめ

• 10 年以上続く案件の資料約 4 万 1,000 件を Markdown 化し、フォルダごとの索引と要約を作って、Claude に目次をたどらせる形でナレッジ検索を作った
• RAG と違い、LLM が資料全体の構成を見ながら文書を取りに行くため、外れたら戻る・複数の枝から根拠を集める・たどった経路を出典として示す、ができる
• 運用では、出典パスの付与、参照範囲を勝手に広げないこと、同名ファイルの版比較を依頼文に組み込んだ
• 調べものは 30 分〜半日から約 5 分になり、この案件の条件では年間約 120 人日以上の削減を見込んでいる

社内ナレッジを AI で引けるようにする取り組みは、gaipack でも支援しています。社内ナレッジ検索を導入した例は「RAG × MCP で社内ナレッジを資産化した導入事例」で紹介しています。お気軽にご相談ください。