目次
はじめに
ポイント①：最初に「目指す問い合わせ回答支援の姿」を整理する
ポイント②：最初から全部やらず「最小構成」で始める
ポイント③：回答精度を上げるには「情報の持たせ方」が重要
ポイント④：精度検証の次は「配布・運用」を設計する
■ 今回の試作で学んだ進め方
まとめ：AI活用は「構想整理×最小構成」で進めやすくなる
はじめに
今回は、社内の問い合わせ対応を少しでも効率化できないかという課題意識から試作した、AIが社内ナレッジを参照して問い合わせ回答案を作るシステムについて共有します。
単に「AIで何か作ってみた」という話ではなく、AIと壁打ちしながら構想を整理し、制約の中で最小構成に落とし込み、段階的に形にしていった過程をまとめた内容です。
今回の取り組みでは、特に次のような点を重視しました。
- 最初に「どのような支援を実現したいか」を整理すること
- いきなり完成形を目指さず、最小構成で検証すること
- AIが参照しやすい情報構造を作ること
問い合わせ対応のような業務では、AIモデルやツール選定だけでなく、業務・情報・運用をどう設計するかで進みやすさが大きく変わると感じました。
ポイント①：最初に「目指す問い合わせ回答支援の姿」を整理する
最初に行ったのは、いきなり実装に入ることではなく、どのような問い合わせ回答支援が現場で有効かを整理することでした。
この段階ではAIを実装支援だけでなく、構想の壁打ち相手として活用しています。
初期の構想段階でイメージしていたのは、例えば次のような支援です。
- 問い合わせ内容に対する回答案の作成
- 社内ナレッジを踏まえた回答の提示
- 必要に応じたソースコード参照・改修観点の示唆
- 仕様書化されていない運用上の知見（暗黙知）の考慮
もちろん、初期段階でこれらをすべて実現するのは現実的ではありません。
ただ、先に目指す姿（理想形）を整理しておくことで、「何を優先するか」「何を後回しにするか」の判断がしやすくなりました。
ポイント②：最初から全部やらず「最小構成」で始める
次に検討したのは、入力（ナレッジ収集）と出力（利用体験）の設計です。
社内ナレッジはSlack、スプレッドシート、メール、Redmine、共有フォルダなど複数箇所に分散しており、いきなり一元化するのは難しい状態でした。
また、予算面の制約もあり、初期段階からAPIを多用する構成は取りにくい前提がありました。
そのため今回は、「全部入り」を目指すのではなく、効果が大きい領域から最小構成で着手する方針を取りました。
最初の対象として選んだのはSlackです。理由は、問い合わせ対応に関する知見が比較的多く蓄積されていたためです。
- まずはデータを取り出してためる
- AIが扱いやすい形に加工する
- 問い合わせ回答として成立するかを検証する
このように段階を分けることで、最初から運用自動化まで抱え込まず、検証に集中しやすくなりました。
ポイント③：回答精度を上げるには「情報の持たせ方」が重要
Slackの内容をそのままAIに読ませるだけでは、効率・精度の両面で安定しにくいと考え、参照構造を工夫しました。
今回採用したのは、概要で候補を絞り、必要なときだけ元データを読む構成です。
具体的には、次のような流れにしました。
- Slackスレッドごとに「概要mdファイル」を作成する
- 概要mdをRAGの検索対象にする
- 概要だけで不足する場合は、対応する元スレッドmdを参照する
この構成にした理由は、概要だけでは情報が落ちる一方で、毎回元スレッド全文を読ませると処理効率が悪くなるためです。
問い合わせ回答で必要になる精度と速度のバランスを意識して、段階的に読む形にしました。
また、RAGで概要を見つけたあと、必要に応じて元スレッドを読み込む流れは、プロンプト側にも組み込みました。
このあたりはAIと壁打ちしながら調整し、「どの情報を先に見せるか」「どの条件で詳細参照に進むか」を少しずつ詰めていきました。
ポイント④：精度検証の次は「配布・運用」を設計する
構成案がまとまった段階で、まずはClaude Codeで性能を検証しました。
この時点で確認したかったのは、問い合わせ回答として実用的な精度が出るか、概要→元スレッド参照の流れが機能するか、という点です。
試した範囲では精度面の感触は良く、次の検討として「どう作るか」から「どう配るか」に進める見通しが立ちました。
そこで次に重視したのが、非エンジニアでも使いやすい形で展開できるかという観点です。
会社の利用環境や導入負担を踏まえてAIと相談した結果、今回は次の構成が現実的と判断しました。
- Claude Desktop
- MCPサーバ
既存契約との相性や、利用者側のハードルを考慮しながら、技術的な実現性だけでなく運用に乗せやすい形を意識して構成を決めました。
■ 今回の試作で学んだ進め方
今回の試作を通じて学んだ進め方として、次の流れが有効だと感じました。
- 目指す姿を整理する（どの支援が現場価値につながるか）
- 最小構成を決める（対象範囲を絞って検証可能にする）
- 情報構造を整える（AIが参照しやすい形に加工する）
- 精度を検証する（実用レベルかを確認する）
- 配布・運用を設計する（利用者負担と定着を考える）
また、実際に進めやすかったのは、できていること／これからやりたいことを計画として整理し、md化してAIに渡す進め方でした。
AIが全体像を把握しやすくなり、実装支援だけでなく構想整理の壁打ち相手としても機能しやすくなります。
まとめ：AI活用は「構想整理×最小構成」で進めやすくなる
今回の試作を通じて、AI活用は「いきなり全部作る」よりも、最終像を持ちながら最小構成で始める進め方と相性が良いと感じました。
- 先に目指す姿を整理すること
- 効果の大きい領域から小さく検証すること
- AIが参照しやすい情報構造を作ること
- 精度の先に、配布・運用設計まで考えること
問い合わせ対応のような業務領域では、技術要素だけでなく、業務・情報・運用を含めた設計が重要になります。
今後も、実装面だけでなく「どう現場で使える形にするか」という観点で、AI活用の形を整理していきたいと思います。
