ChatGPTのような汎用AIは便利ですが、会社独自の料金、ルール、商品、業務手順までは知りません。
要点
- RAGは承認済み資料を検索して根拠とともに回答し、資料にない内容を補いません。
- 公開情報と社内情報を分離し、利用者の権限に応じて検索対象を制限します。
- 回答不能、根拠不足、期限切れ資料では停止し、人へ引き継ぎます。
そこで開発しているのが、その会社・その店舗の情報を理解した専用AIです。
背景：毎回答えが違う、資料を探す時間がかかる
社内には、Notion、マニュアル、FAQ、商品情報、過去の対応履歴など、多くの情報があります。
しかし、必要な情報がどこにあるか分からず、人に聞く、検索する、資料を開くという作業が繰り返されます。
具体的な仕組み
RAGという仕組みを使い、AIが質問に答える前に、社内の関連情報を検索します。
- ユーザーが質問
- 質問に近い社内情報を検索
- 関連資料をAIへ渡す
- AIが資料を根拠に回答
- 必要に応じて会話フローを分岐
この構成により、一般論ではなく、登録された会社・店舗の情報に沿った回答を作りやすくなります。
使用している技術
- OpenAI API
- Notion API
- RAG
- ベクトル検索
- LangChain
- LangGraph
- Python / FastAPI
- Next.js
- Chromaなどのベクトルデータベース構成
実際に構築してきた用途
- 店舗案内AI
- 業種別FAQチャットボット
- 修理相談AI
- 社内ナレッジ検索
- Notion連携型相談システム
- 会話フローを持つAI案内
特にLangGraphを使うことで、単純な一問一答だけでなく、「質問内容によって処理を変える」会話設計も可能になります。
何が楽になるのか
同じ質問に何度も答える負担を減らし、必要な資料を探す時間を短くできます。
また、担当者ごとに説明内容が大きく変わることを防ぎやすくなります。
ただし、登録されていない情報までAIが正しく知っているわけではありません。そのため、回答根拠の管理と、人へ引き継ぐ条件の設計が重要です。
汎用AIとの違い
専用AIでは、「何でも答える」ことを目指しません。
むしろ、
- 自社情報がある質問は答える
- 情報がない場合は断定しない
- 重要な判断は人へつなぐ
という制御を入れることで、業務で使いやすくします。
具体例1：店舗の営業時間を尋ねられたとき、最新の承認済み情報で答える
架空の富士市の店舗で、スタッフが「祝日の営業時間は何時ですか」と専用AIに尋ねたとします。AIはNotionの店舗情報から、営業時間、対象日、更新日、承認者がそろったページを検索し、根拠ページへのリンク付きで回答します。複数ページに異なる時間が書かれていたり、祝日の記載が見つからなかったりしたら、古い方を選ばず「確認できる情報がありません。担当者へ確認してください」と返します。
運用担当者は、店舗情報の正本、更新責任者、営業時間の変更手順を決めます。公開用FAQと内部用メモを同じ検索対象へ混ぜず、アクセス権に応じてAIが検索できる資料を分けます。営業時間の変更を確認した後で正本を更新し、更新日や古い情報の扱いも記録します。
具体例2：返品相談で、規程を探しても答えが足りないときは止まる
架空のスタッフから「開封済み商品の返品はできますか」と質問されたとします。社内資料に「返品は購入後7日以内」とだけあり、開封状態や不具合の扱いが書かれていなければ、AIは返品可能・不可を断定しません。該当する返品規程の引用、根拠ページ、確認できていない条件を表示し、担当責任者へ照会を引き継ぎます。責任者が正式ルールを確認・改訂した後、承認済みの回答だけを検索可能にします。
問い合わせが外部の顧客向けなら、公開用の一般案内だけを提示し、購入経路や商品状態など個別事実に応じた判断は人へつなぎます。LangGraphの公式資料では、外部入力を待つために処理を一時停止し、状態を保存して人の確認後に再開するインタラプト機能が説明されています。これを使う場合も、誰が何を承認したかをアプリ側で記録する設計が必要です。LangGraph「Interrupts」
回答品質を上げる評価セット
- 正しい根拠が見つかる質問
- 言い換えや略語を含む質問
- 情報がない・期限切れの質問
- 複数の規程が矛盾している質問
- 権限のない利用者からの質問
- 回答ではなく人の判断が必要な質問
テストには期待する回答、参照する資料、許容する未回答の条件を記録します。回答の正しさだけでなく、誤った資料を引用しないか、根拠へ戻れるか、分からないとき止まれるかを確認します。Notion APIにはリクエスト数やページネーションなどの制限があるため、同期対象や更新頻度を決め、全ページを都度取得する設計を避けます。Notion API「Request limits」
RAGは社内情報を自動で正確にする仕組みではありません。資料の所有者、版、アクセス権、更新担当を整えることが、専用AIを信頼できる業務支援にする出発点です。
小さく運用して、誤答を直すサイクル
公開前に、典型質問、資料にない質問、古い版と新しい版が混在する質問、アクセス権のない情報を求める質問をテストします。担当者は回答本文だけでなく、参照元が正しいか、引用が質問に答えているか、回答不能時に適切に止まるかを確認します。公開後に誤りが見つかったら、会話ログだけを直すのではなく、根拠資料、FAQ、検索対象、プロンプトのどこを直すべきかを切り分けます。改訂日と責任者を残し、同じ質問を再テストすることで、専用AIを一度作って終わりにせず育てていきます。
公開範囲と内部ナレッジを分ける
顧客向けチャットボットへ、社内の原価、従業員情報、未公開の対応履歴を混ぜないよう、検索対象そのものを分けます。ページ単位のアクセス権を確認し、情報源の権限を持たない利用者に検索結果が漏れないことを、アカウント別のテストで確かめます。退職や担当変更があった時は、AIの利用権限、API連携、共有リンクを一緒に見直し、使わなくなったデータの削除手順も記録します。
まとめ
専用AIの価値は、AIそのものよりも、その会社の知識を使える状態にすることにあります。
FUJI PRESSでは、Notionや既存資料を活かしながら、業務に合わせた専用AIの設計・開発に取り組んでいます。
運用上の確認
文書ID、版、承認日、更新者、公開範囲を管理し、評価質問で回答・根拠・拒否を定期検証します。誤答は会話だけで直さず、元資料と検索設定を修正します。
よくある質問
Q. 汎用AIとの違いは何ですか？
指定した自社資料を検索し、根拠を示して回答する点です。ただし資料不足や検索失敗は残ります。
Q. 資料にない質問へ答えますか？
推測せず、情報不足を示して担当者や正しい窓口へ引き継ぎます。
Q. 社内資料を全員が検索できますか？
いいえ。部署、役割、案件などの権限に合わせて検索対象と表示内容を制限します。
Q. 精度はどう評価しますか？
代表質問、誤りやすい質問、回答不能質問を用意し、回答、根拠、拒否、権限を継続的に確認します。