公的統計によれば、生成AIを業務に活用している企業の割合は前年から大きく伸びており、用途として最多に挙がるのが「社内情報の検索・要約」だと報告されています。士業事務所でも「所内のナレッジを生成AIに答えさせたい」というテーマが、議題として上がる頻度が増えてきました。
ただ、「全部読ませて検索できるようにする」という構想で着手すると、後段で詰まることが多いです。詰まる場所は技術ではなく、元データの整理・鮮度・引用元の3点に集中する傾向があります。本稿では所内FAQをAI化する前に、判断の出発点として整理しておきたい論点を並べていきます。
AI化に向くFAQ、向きにくいFAQ
最初に分けたいのは、AIに任せやすい問いと、任せると事故になりやすい問いの境界です。
向きやすいのは、たとえば次のような類型です。
- 手順・操作系（◯◯システムの操作手順、書類の提出先と部数）
- 用語・略語の定義（所内独自の略称、勘定科目の呼び分け）
- ルール・規定の参照（就業規則、経費精算ルール、出張規程）
- 過去案件の類例検索（似たようなケース、相談記録の検索）
いずれも「元の文書が存在する」「正解が比較的固定されている」「機微情報を含まない」という条件を満たしやすい類型です。AIが答え方を間違えても、原典に当たれば確認できる構造になっています。
向きにくい類型は、その裏返しになります。
- 判断系（このケースは特例にあたるか、否認リスクはどうか）
- 個別顧客に紐づく事実関係（◯◯社の昨年の処理）
- 法令解釈そのもの（条文の意味、最新通達への当てはめ）
これらは「回答を間違えると顧客に不利益が及ぶ」「最新性が極めて重要」「専門家の判断責任そのもの」という性質があります。AIに直接答えさせるのではなく、参照すべき根拠資料を出すところまでに留めるのが穏当だと考えています。
3つの実装パターン
実装の選択肢は、おおむね3つの型に整理できます。
専用チャットUI型は、独立した画面で所内ナレッジに質問する形です。汎用のAIチャットや社内ナレッジ検索系のサービスが該当します。自由に対話できる利点がありますが、業務フローから離れた場所に移動する手間がともないます。
検索結果の要約型は、既存の社内検索（社内ポータルやドキュメント管理基盤など）の結果ページにAI要約を差し込む形です。既存導線にそのまま乗る利点がありますが、検索クエリを工夫する必要があります。
チャットツール常駐ボット型は、普段使っているチャットツール内でボットにメンションすると答えが返ってくる形です。動線を変えずに済みますが、会話履歴の保管と引用の可視化の設計が要ります。
3つを観点で並べると、次のように整理できます。
| 観点 | 専用チャットUI型 | 検索結果の要約型 | チャットツール常駐ボット型 |
|---|---|---|---|
| 業務動線との親和性 | 別画面に移動 | 既存検索に乗る | 動線そのまま |
| 質問の自由度 | 高い | 検索クエリ依存 | 中程度 |
| 引用・履歴の見せ方 | 設計次第 | 検索結果に紐づく | チャンネル履歴で残る |
| 想定される配置場所 | 新人席のチャット画面 | 社内検索ポータル | 普段使うチャットチャネル |
どれが正解という話ではなく、「ベテランが質問されている場所」がどこかに合わせるのが現実的だと考えています。チャットで質問されているならチャットに置く、対面なら新人席にチャットUIを置く、という具合に決まっていきます。
元データの整理が、実は仕事の8割
技術的な仕組みより先に効くのが、元データの整理です。RAG（Retrieval-Augmented Generation：参照型生成）と呼ばれるアプローチでは、AIに渡す前段でナレッジを検索し、その内容を根拠として回答させる構造になっています。検索で正しい資料が取れない限り、AIの答えも正しくなりません。
整理しておきたい観点は3つあります。
第1に鮮度です。3年前の手順書と先月改訂された手順書が両方ヒットすると、AIは新旧を判別できないケースがあります。改訂日・最終更新日が文書側にメタデータとして入っているか、古い版がアーカイブされているかは事前確認の対象になります。
第2に引用元の明示です。「この手順書の何ページに書いてある」と引用が付くか、AIが要約だけ返すかで運用負荷は大きく変わります。引用が出ない設計だと、新人は確認できず、結局ベテランに聞きに行くことになります。
第3に権限設計です。人事評価メモ、顧客の機微情報、所長宛のメール。こうしたものがAIの検索対象に混じっていないかは要確認です。エンタープライズ向けのAIサービスは「ユーザーがアクセス権を持つデータのみ参照する」と設計されているのが一般的ですが、これは裏返すと、アクセス権設定が雑だとそのまま漏れるということでもあります。
古い回答が混入する経路と、対策
最も警戒したいのは、税制改正前の取り扱いがそのまま回答されて顧客に伝わる経路です。廃止された届出様式を案内してしまう経路も同じ構造です。AI自体は「もっともらしく」回答するため、現場では正誤の判別がつきにくくなります。
対策の方向性としては、次のような工夫が想定されます。
- 文書側に「有効期限」「次回見直し日」をメタデータで持たせる
- AIに渡す前の検索ステージで、古い版を除外する
- 回答にかならず引用元と更新日を表示する
- 「税制・法令に関わる質問は専門家確認必須」と回答末尾に定型注記を入れる
- 月次・四半期で「FAQで参照された文書」のレビュー会を入れる
完全に防ぐのは難しいです。「AIに答えを言わせる」より「AIに根拠文書を出させて、判断は人がする」という設計のほうが、士業の業務には適合しやすいと考えています。
セキュリティと守秘義務の論点
ここは士業事務所では避けて通れない領域です。
監督官庁からは、生成AIサービスに個人情報を入力する場合の留意事項について注意喚起が出されています（公式情報を確認のこと）。所内FAQをAI化する文脈では、次の点を整理しておきたいところです。
- 学習利用の有無: 利用するAIサービスが、入力データを学習に再利用しない契約形態か（テナント分離、エンタープライズ契約、API利用時の opt-out 等）
- 保管場所と越境: データの保管リージョン、海外移転の有無、顧客との契約上の制約
- 守秘義務との整合: 税理士法・弁護士法・社労士法等の守秘義務に照らして、AIベンダーに渡してよい範囲か
- ログとアクセス記録: 誰がどんな質問をしたか、どんな回答が返ったかが追跡できるか
- 退職者・異動者のアクセス制御: アカウント停止がAI側の参照範囲にも反映されるか
「テナント内に閉じている」と説明されるサービスでも、エンドユーザー設定や連携アプリ経由で外に出るケースは想定しておくのが安全です。導入時にIT部門と顧問弁護士で照らし合わせるプロセスを挟むのが穏当だと考えています。
設計の出発点
所内FAQのAI化は、技術的にはかなり身近になってきています。一方で、「鮮度・引用元・権限」の3点を曖昧にしたまま導入すると、新人に古い回答が届いて顧客に伝わる経路が残ります。
着手前に押さえたい論点を簡潔に並べると、次のようになります。
- AI化したいFAQ上位20件を頻度ベースで挙げ、それぞれの「正解の根拠文書」が特定できているか
- 根拠文書の最終更新日・改廃のメタデータが運用されているか
- 利用予定のAIサービスの学習利用ポリシー・保管リージョン・監査ログを契約条項で確認したか
- 回答に引用元と更新日が表示される設計になっているか
- 「税制・法令の判断はAI回答を根拠にしない」という運用ルールを所内で合意したか
AIに答えを断言させるより、根拠文書を提示させて判断を人に残す設計のほうが、士業の業務には合うケースが多いと考えています。この方針が決まると、製品選定・データ整備・教育の優先順位は、おのずと並び替わっていきます。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」: https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 総務省「通信利用動向調査」: https://www.soumu.go.jp/johotsusintokei/statistics/statistics05.html