0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ナレッジ検索をClaude Codeからも引けるようにした:社内ドキュメントをAIに答えさせる3つの道を比べた

0
Posted at

はじめに

今回は、社内の「これどこに書いてありますか」系の問い合わせを減らす、というテーマです。

ドキュメント自体は十分にあります。仕様書も、運用手順も、過去の障害報告も、ちゃんと書かれて残っている。それなのに、チャットには毎日のように同じ質問が飛んできます。書いてあるのに、たどり着けない。ここをAIで埋められないかというのが出発点でした。

結論を先に書くと、決め手は「作れるかどうか」ではなく「誰が使えるか」でした。 技術的に組めても、質問してくる本人が使えなければ、問い合わせは減りません。

そこで、社内ドキュメントにAIで答えさせる方法を3つ試して、準備の重さと、実際に誰が使えるかを並べてみました。最後に、エンジニアがClaude Codeから同じナレッジベースを引けるようにした話も書きます。

この記事には、ONES.comの製品が3つ出てきます。先に短く紹介しておきます。

  • ONES Wiki:仕様書や運用手順、議事録などのドキュメントを書いて貯めておける、ナレッジベース管理のツールです。
  • ONES Assistant:ONESの画面に組み込まれたAIアシスタントです。今開いているページやナレッジベースの内容を読み取って、質問に答えたり、課題を作ったりしてくれます。
  • ONES MCP:ONESが公開しているMCPサーバーです。Claude CodeのようなMCPクライアントからONESのデータを参照・操作できるようになります。

1-connect.png

道その1:自前でRAGの仕組みを組む

最初に検討したのが、王道の構成です。ドキュメントを取り出して、分割して、ベクトル化して、検索できる置き場に入れ、質問が来たら関連箇所を引いてAIに渡す。技術記事でもよく紹介されている作り方ですね。

やること自体ははっきりしています。ただ、手を動かし始めると決めることが次々に出てきました。

  • ドキュメントをどうやって定期的に取り出すか(APIキーの発行と、認証情報の置き場所)
  • どの単位で分割するか(見出し単位か、文字数か。表や箇条書きをどう扱うか)
  • ベクトル化に何を使い、どこに保存するか(費用と運用の担当を決める必要があります)
  • 元のドキュメントが更新されたとき、どうやって作り直すか
  • 権限をどう再現するか。ここがいちばん重いです

最後の権限が特に厄介で、元のナレッジベースでは見られる人が限られているページも、自前で作った検索の中に入れてしまえば誰でも引けてしまいます。これを防ごうとすると、権限の情報も一緒に取り込んで、質問する人ごとに絞り込む仕組みが必要になります。

動くものを作るところまでは行けます。ただ、これは実行環境と鍵の管理ができる人が前提の話で、しかも作ったあと誰かが面倒を見続けることになります。「書いてある場所が分からない」と困っている当の本人が、明日から使える形にはなりません。

道その2:ドキュメントを書き出して、汎用のAIに読ませる

次に試したのが、もっと素朴なやり方です。関係しそうなドキュメントをまとめて書き出して、手元のAIに読ませ、そこに質問する。準備は道その1に比べればずっと軽いです。

その日のうちに試せますし、答えの質も悪くありません。ただ、続けようとすると引っかかるところがありました。

一つは、書き出した瞬間のコピーに対して答えている点です。元のページが更新されても手元のファイルは古いままなので、答えも古くなります。更新のたびに書き出し直す運用は、正直なところ続きませんでした。もう一つは、書き出した先が元の権限から切り離されることです。社外秘の記述が混ざったファイルが手元に残り、誰の手元にどこまでのコピーがあるのかを追えなくなります。

そして根本的なところとして、この方法は「書き出せる人」しか使えません。問い合わせを送ってくる側の人に、まずドキュメントを書き出してもらうところから始めるのは、現実的ではないですよね。

道その3:ナレッジベースの中にいるAIに、そのまま聞く

3つ目は、ドキュメントが置いてある場所そのものにAIがいる形です。私たちの場合はONES Wikiにドキュメントがあるので、ONES Assistantにそのまま聞きます。

準備は要りません。実行環境も、鍵の発行も、取り込みの仕組みも作らなくていい。会話パネルを開いて日本語で聞くだけです。

「デプロイ手順のうち、ロールバックのやり方が書いてあるページを探して、手順の部分だけ先に見せてください。どのページから引いたかも教えてください」

返ってくるのは、該当ページを探したうえでの要約と、根拠になったページです。元のページがそのまま参照されるので、ドキュメントが更新されれば次に聞いたときの答えも更新後の内容になります。 取り込み直しの運用が発生しません。

権限についても、使う人が見られる範囲で動きます。見えないページの内容が答えに混ざることを気にしなくていいので、そのままチーム全員に「困ったらここに聞いて」と渡せました。ここがいちばん大きかったです。エンジニアでないメンバーにも、説明が一行で済みます。

聞いた結果をそのまま課題にすることもできます。「この手順の記述が古いので、更新する課題を立てて」と続ければ、ONES Projectの課題として残ります。調べる場所と、やることを残す場所が地続きなんです。

3つの道を並べてみる

準備の重さと、誰が使えるかで比べると、こうなりました。

自前でRAGを組む 書き出して汎用AIに読ませる ナレッジベースの中のAIに聞く
準備 実行環境・鍵の発行・取り込みの設計が必要 都度の書き出しが必要 不要。画面の会話パネルから
使える人 環境を作れる人 書き出せる人 ドキュメントを見られる人なら誰でも
更新への追随 作り直しの運用を自分で用意する 書き出し直すまで古いまま 元のページを参照するので追随する
権限 別途、再現する仕組みが要る 書き出した時点で切り離される 利用者の権限の範囲で動く
答えの根拠 出せるように自分で作り込む 渡したファイルの範囲 参照元のページが示される

こうして並べると、比較の軸が「性能」ではなかったことがはっきりします。質問している当人がそのまま使えるか。ここで差がつきました。

エンジニアには、Claude Codeからも引けるようにした

ここまでで全員が使える道はできました。ただ、エンジニアだけは事情が少し違います。実装中はターミナルにいるので、ブラウザに切り替えてドキュメントを探すこと自体が中断になるんです。

そこで用意したのが、Claude CodeからONES MCPにつなぐ形です。ONESはMCPサーバーを公開しているので、Claude Code側にMCPサーバーとして登録すれば、そのままONES Wikiのページや、ONES Projectの課題を参照できるようになります。自前で取り込みの仕組みを作る必要はありません。

実装中に効いてくるのは、こういう聞き方です。

「この修正に関係する仕様が書かれているページをONES Wikiから探して、いま触っているコードの挙動と食い違っている箇所があれば指摘して」

コードとドキュメントの両方を見たうえで返ってくるので、仕様の読み直しをターミナルから出ずに済ませられます。ここは道その3では届かない範囲で、Claude Codeを使っている人にはかなり実用的でした。

大事なのは、この2つが役割で分かれていて、どちらもONESの標準の使い方だということです。手軽に全員へ配れるONES Assistantと、エンジニアの作業環境に寄せられるONES MCP。片方を選ぶ話ではなく、使う人に合わせて出し分けられます。

なお、ONES Assistantは製品の画面に組み込まれたAIで、Claude CodeからつなぐほうはMCPクライアント側の機能と組み合わせて実現するものです。この2つは別の仕組みなので、社内に説明するときも分けて伝えるようにしています。

2-outh.png
3-connected.png

そのまま真似できる聞き方

どちらの入り口でも、答えの質が安定した聞き方は同じでした。次の3点を最初に指定するのがコツです。

  1. 探してほしい範囲:どの領域の話かを一言添える
  2. 返してほしい形:手順なのか、要点なのか、比較なのか
  3. 根拠の明示:どのページから引いたかを必ず添えさせる

型にするとこうなります。〇〇の部分を自分の状況に差し替えれば、そのまま使えます。

〇〇(探したい領域)について、次の形で答えてください。

- 質問:〇〇
- 返してほしい形:〇〇(手順の箇条書き/要点3つ/条件と挙動の対応 など)
- 根拠になったページ名を必ず添えてください
- 複数のページに書かれていて内容が食い違う場合は、両方を並べて教えてください

書かれていない場合は「見つかりませんでした」と答えてください。

最後の一文を入れておくのがおすすめです。書かれていないことを埋めて答えられてしまうより、「見つかりませんでした」と返ってきたほうが動きやすい。その場合はドキュメント側が足りていないということなので、そのままページを追加する作業に進めます。

問い合わせは、どう変わったか

正確に数えたわけではないので体感ベースになりますが、チャットに飛んでくる「これどこですか」系の質問は、目に見えて減りました。

面白かったのは、減った分がそのまま消えたわけではなかったことです。かわりに「聞いてみたけど見つからなかったので、書いておいてもらえますか」という連絡が来るようになりました。探す手間だった部分が、ドキュメントを足す作業に置き換わった形ですね。これは歓迎すべき変化だと思っています。

おわりに

社内ドキュメントにAIで答えさせる方法を3つ試して、最終的に効いたのは、いちばん作り込まなかった選択肢でした。仕組みを自分で組み上げなくても、ドキュメントが置いてある場所にAIがいれば、その日から全員が使えます。そのうえで、ターミナルから離れたくないエンジニアにはClaude CodeとONES MCPという入り口も用意できました。

同じように「書いてあるのにたどり着けない」で困っているなら、まずはよく聞かれる質問を1つ選んで、AIに投げてみるところから始めるのがいいと思います。答えが返るか、根拠のページが示されるか。それだけでも手触りは分かります。

実際の画面で確かめてみたい方は、ONES.com からどうぞ。自社のドキュメント量や権限構成で成立するかを見てほしい場合は、support@ones.com までご相談ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?