「入場書類はどの様式か」「この図面は最新版か」「経費申請を誰に出せばよいか」。建設会社の社内問い合わせでは、答えそのものより、正しい資料と担当者を探すことに時間がかかる場合があります。現場ごとに保存先や呼び方が違い、知っている人が不在だと確認が止まります。

社内問い合わせAIは、この資料探索と一次案内を支援する候補です。ただし、検索で見つかった資料を読み上げるだけでは、古い図面や閲覧権限のない情報を回答する危険が残ります。導入の中心は、会話画面の用意よりも、誰が、どの現場の、どの版を参照できるかという情報管理です。

本記事は社内の問い合わせ窓口を対象とし、施主や近隣住民からの外部着信を扱う建築会社のAI電話受付とは区別します。説明する構成と場面は一般的な設計例であり、Bellや特定サービスがすべての機能・連携を標準提供するという意味ではありません。

自動回答しやすい社内問い合わせを選ぶ

資料の案内と施工判断を分ける

申請窓口、承認済み様式の所在、社内システムの利用手順などは、回答根拠を管理しやすい領域です。一方、「この条件で作業してよいか」「図面と現物が違うがどちらを採用するか」は、現場の状況と責任者の判断が必要です。資料が見つかったことをもって施工可否の判断まで代行させないようにします。

たとえば入場手続きの問い合わせでは、対象現場を確認し、適用中の手順書と提出先を案内できます。ただし、資格証の有効性や提出書類の不足をAIが独自に判断して入場許可を出す設計は別の検討になります。最初は、必要資料への案内と担当者への質問整理に範囲を絞ると、正否を確認しやすくなります。

問い合わせ件数が多いだけで優先しないことも重要です。資料の更新者が決まっておらず、同じ質問への回答が部署ごとに異なるなら、先に規程や窓口を揃えます。曖昧な運用をAIへ移しても、回答のばらつきを別の形で残すだけになります。

RAGは「根拠を探す仕組み」として設計する

RAGは、関連資料を検索し、その内容を参照して回答を生成する構成です。すべての社内資料をモデルに覚えさせる方式とは異なり、回答時に参照した文書を確認できる形にしやすい一方、検索対象や取り出した部分が不適切なら回答も誤る可能性があります。

「出典付きだから正しい」と判断せず、質問に対応した記述が出典にあるか、対象現場と版が合っているか、回答が原文にない結論を追加していないかを検証します。回答には文書名、管理番号、版、適用日、該当する節やページを添え、利用者が元資料へ戻れるようにします。出典リンクのクリック数は利用状況であり、回答の正確さや最新版の利用率そのものではありません。

図面と文章では検索の限界が違う

図面の注記や寸法、表の罫線、矢印の関係は、文字抽出だけで正しく扱えるとは限りません。OCRで数字が取れたとしても、どの部材や箇所の数値かを取り違える場合があります。図面の検索は管理番号や注記の所在を探す支援から始め、寸法の判断や図面同士の整合性確認は担当者が原図で行う運用にします。

試験では、検索しやすい本文だけでなく、スキャンした書類、差し替えページ、似た管理番号、別棟の同名図面を含めます。文字が取れない資料に対して、AIが一般知識で答えを補うのではなく、該当資料を確認できないと伝えて人へ戻せるかを確認してください。

版管理は、更新日だけに頼らない

承認済みの適用版を特定する

ファイルの更新日が最も新しいものが、現場で使うべき正式版とは限りません。検討中の修正版、承認待ちの図面、別工区に適用する資料が混在するためです。文書台帳には対象現場、管理番号、版、承認状態、適用開始日、失効条件、管理責任者を持たせます。

正式版が変更されたら、旧版を通常回答の対象から外します。履歴として保存する必要がある資料は、履歴検索と現在の案内を分け、旧版であることが分かるようにします。ファイルを差し替えるだけでなく、検索索引や保存済みの回答にも古い情報が残っていないかを確認する必要があります。

更新が失敗したときは、回答を狭める

文書保管先との同期が止まった場合、前日の資料でそのまま回答し続けると、利用者は最新版だと思ってしまいます。最終同期日時と情報の鮮度を監視し、重要文書は期限切れ時に回答を止めるなどのルールを設けます。障害中に使える代替の資料確認窓口も案内します。

改訂内容が現場に適用済みか分からない場合も、AIが勝手に新しい版を採用しないようにします。「最新」と「当該現場で適用中」を分けて管理することで、工事ごとの段階や承認手続きに沿った案内ができます。

アクセス権は検索前から回答後まで確認する

社内向けであっても、すべての社員や協力会社が同じ資料を閲覧できるとは限りません。現場別の図面、見積、個人の勤怠情報などは、役割や所属によって閲覧範囲が異なります。質問者を識別し、検索する段階で対象を権限内に限定する設計を検討します。

回答の表示だけを隠しても、文書名、検索候補、要約、引用、ログに情報が残れば漏えいにつながります。権限のない現場の情報を質問した場合、異動直後、協力会社の契約終了後などを試し、回答本文以外にも情報が出ないか確認してください。資料側の権限変更がAI側に反映されるまでの時間も確認対象です。

電話での問い合わせは、チャットのログイン状態をそのまま使えません。発信者番号や名乗りだけで権限を付与せず、機密情報を案内するための本人確認方法を別に設計します。認証できない電話では、一般的な手順の案内や問い合わせ受付までに限定する方法があります。

想定例：入場書類の様式を現場から問い合わせる

次の場面は架空の運用例です。現場担当者が社内チャットで「来週入る協力会社の書類は前と同じでよいか」と質問したとします。AIは対象現場と手続きの種類を確認し、質問者が閲覧できる資料から適用中の手順書を探します。

回答には必要な様式の名称、提出先、該当する手順書の版と適用日を示します。過去の様式も検索で見つかった場合は、現行の受付に使えるかを台帳で確認し、単に類似度が高い方を採用しません。書類の承認や入場可否については管理担当者が確認することも明示します。

ところが、現場の掲示に書かれた提出先と手順書が異なると利用者が返答した場合、自動回答を押し通さずに確認案件へ切り替えます。質問内容、対象現場、参照した文書と版、相違点を管理担当へ渡すと、担当者はどこを直すべきか調査できます。確認が終わるまで対象の回答を一時停止すれば、同じ不一致を他の利用者へ広げずに済みます。

担当者が正式な案内を決めた後は、元資料と受付FAQを更新し、同じ質問で正しい回答に戻ることを再試験します。問い合わせが解決したことと、知識源の不備が修正されたことを別々に確認するのが、この運用の要点です。

現場で使える引き継ぎと、弱い通信環境への対応

手袋を着けた作業者や騒音下の利用者に、長文の入力を何度も求める運用は定着しにくくなります。質問を短くし、現場名など既に認証情報から分かる項目は重ねて聞かないようにします。ただし、作業中の無理な端末操作を前提とせず、安全に確認できる場面で利用する運用を決めてください。

通信が切れた場合は、質問を送信できたのか、受付だけ保存されたのか、担当者が受領したのかを区別します。再送で同じ案件が増えない識別方法を用意し、利用者には未完了の状態が分かる表示や案内を行います。保存済みの回答を利用できる場合も、その情報の版と取得時点を示し、鮮度の必要な質問には再確認を促します。

人へ渡す条件は、根拠が見つからない場合だけではありません。資料が矛盾する、権限の確認ができない、利用者が回答を否定する、安全や品質に関する現場判断が必要、担当者を希望している、といった条件を定めます。引き継ぎ先が不在の場合の代理担当と、未受領案件を確認する管理者も必要です。

導入は資料を限定した検証から始める

最初の対象は、責任者が明確な一つの手続きや文書群に絞ります。質問例と正解、その根拠、回答してはいけない条件を担当者と作ります。業務を知らない評価者が文章の自然さだけで合格にしないように、正しい版と権限を含めて判定してください。

次に、正式版、旧版、権限外の資料、根拠がない質問、矛盾する資料を混ぜて試験します。回答できない場合に適切に止まり、担当者に必要な情報が渡れば、それも設計上の成功です。自動回答率を上げることだけを目標にすると、本来止めるべき質問へ回答しやすくなります。

費用対効果には、削減できた探索や確認の時間だけでなく、文書の整理、権限管理、評価、問い合わせの有人対応にかかる工数を含めます。既存ツールとの連携は製品名だけで判断せず、対象データ、権限の継承、同期の方式、監査記録を具体的に確認します。PoCの期間も一律には置かず、資料の状態と検証範囲から計画します。

まとめ

建設業の社内問い合わせAIは、正しい資料へたどり着くまでの手間を減らす支援として設計できます。RAGの回答根拠、現場ごとの適用版、アクセス権、回答できないときの担当者移管が、その土台になります。電話受付との連携や資料検索の対応範囲は、利用するサービスと既存環境に合わせて確認が必要です。

「あの様式はどこにあるか」という確認で、現場と本社の双方の仕事が止まってしまう。電話での社内問い合わせも含めて見直したいなら、Bellへご相談ください。資料の案内で済む質問と、担当者へつなぐ必要がある質問を分けるところから、窓口の役割を一緒に整理しましょう。どの仕組みを使うか決まる前でも、繰り返し寄せられる質問が検討の出発点になります。

技術参考資料：Microsoft Learn「Retrieval-augmented generation (RAG) in Azure AI Search」「Document-Level Access Control - Azure AI Search」。確認日：2026年10月7日。特定製品の機能をBellの対応機能として示すものではありません。

安全に関する参照資料：厚生労働省「職場のあんぜんサイト：リスクアセスメント情報」。確認日：2026年10月7日。本文のAI構成・試験方法は、資料そのものの規定ではなく、社内窓口を設計するための実務上の提案です。