課題
社内にドキュメントは大量にあるのに、必要なときに出てこない。検索してもファイル名しか当たらず、中身に何が書いてあるかは開くまで分からない。結局「詳しい人に聞く」のが一番早い、という状態が常態化していました。
情報システム部門としては、生成AIを使えば解けそうだという感触はありました。ただ社内文書を外部のサービスに渡すわけにはいきません。まず「自社の環境で、自社の文書で、どこまで使えるのか」を確かめる必要がありました。
打ち手
Azure の中に閉じた RAG（検索拡張生成）の基盤を組みました。
- Azure AI Search に社内ドキュメントを取り込み、言葉の意味で引ける検索インデックスをつくる
- Azure OpenAI が、その検索でヒットした社内文書だけを根拠に回答する
- Azure Functions が文書の取り込みと更新を回す
肝は、文書もAIへの問い合わせも自社の Azure テナントから外に出ないようにしたことです。プライベートエンドポイントでネットワークを閉じ、どのデータがどの経路を通るかを構成図に落として提出しました。
「安全かどうか」を感覚ではなく構成で説明できる状態にする。それが社内の稟議を通すための条件でした。
進め方
最初に PoC のゴールを決めました。何ができたら「使える」と判断するのか、何ができなかったら見送るのか。ここを曖昧にしたまま作ると、動くものはできても意思決定には使えません。
検証の過程と結果は技術ドキュメントにまとめて引き渡しています。PoC で終わらせず、本番化するとしたら次に何が必要かまで書いてあります。
この事例から言えること
社内文書の検索は、AI導入の入口として当たりやすい領域です。効果が担当者の日常業務に直結し、外に見せる必要がないので失敗しても傷が浅い。まず小さく確かめてから広げる、という順番が取れます。
【公開前に埋める】相談時の具体的な状況／検証期間と体制／対象にした文書の種類と量／回答精度の実測値／検証後の判断（本番化したか）