AIの回答の中身だけを見ているうちは、それは便利なチャットのままです。業務システムとして使うなら、誰が、いつ、何を入力し、何を参照し、どのモデルが回答し、誰が承認し、どう修正されたかを残せるかが分かれ目になります。便利なチャットAIと、業務に使えるAI基盤の違いは、回答の質ではなく、証跡を残せるかどうかにあります。
この記事の要点
- AIの回答だけでは業務システムにならない。誰が何を聞き、何を参照したかを残せるかが分かれ目。
- 必要なのはアクセスログ、プロンプトログ、出力ログ、モデルID、承認・修正・削除履歴など。
- 閉域AIなら、監査証跡を契約・法令・社内規程・委託元要件に合わせて設計できる。
回答だけでは業務システムにならない
AIに質問して、良い回答が返る。これは便利ですが、それだけでは業務システムとは呼べません。業務システムは、入力と処理と出力をたどれることで成り立ちます。誰が何を聞いたか分からないチャットは、どれだけ賢くても、後から検証できません。
業務に組み込むと、必ず「あのとき何を入力したのか」「どの資料を見て答えたのか」を問われる場面が来ます。クレーム対応、監査、トラブル調査、教育。そのとき証跡がなければ、AIの回答は再現も検証もできず、判断の根拠として使えません。
業務AIに必要な証跡
業務に使えるAIに残したい証跡を並べると、回答そのものより、その周辺の記録が多いことが分かります。これらが揃って、初めて利用履歴と業務判断をたどれます。
入力と参照
ユーザーID、入力プロンプト、添付ファイル、RAG検索クエリ、参照文書ID。
処理と出力
モデルID、モデルバージョン、システムプロンプト、出力結果、人の修正履歴。
承認と管理
承認者、利用業務、保存期間、削除履歴、アクセスログ、管理者操作ログ、エクスポート履歴。
クラウドの標準サービスで残せる範囲
クラウドAIにも利用ログの機能はありますが、業務システムとして求める粒度や保存期間、エクスポート範囲を自社で決められるかは、サービスによって変わります。事業者の内部にしかないログは、委託元監査にそのまま出せないこともあります。
どこまでの証跡をユーザー側が取得でき、どの保存期間で、どの形式で出せるか。ここが自社の規程や委託元要件と合わないと、AIを業務システムとして位置づけるのが難しくなります。証跡の設計可能性は、回答精度とは別の判断軸になります。
証跡を要件に合わせて設計する
監査証跡は、後から足そうとするほど難しくなります。ローカルLLMやオンプレミスAIを管理された環境で動かす閉域AIであれば、アクセスログ、プロンプトログ、出力ログ、参照文書、モデルID、承認履歴、修正履歴、削除履歴、管理者操作ログを、自社の契約、法令、社内規程、委託元要件に合わせて設計できます。
AIモデルを導入することと、AIの利用履歴と業務判断の証跡を残せる基盤を導入することは、別の意思決定です。前者は便利さを、後者は業務システムとしての説明可能性をもたらします。金融、BPO、コールセンター、受託開発など、説明を求められる業態ほど、後者が効いてきます。
この連載で見てきた委託契約、利用規約、再委託、責任分界、個人情報、金融の論点、通話録音、ブラックボックスは、最後にこの一点へ収束します。クラウドAIを否定するのではなく、用途ごとにクラウドAI、ローカルLLM、オンプレミスAI、閉域AIを使い分け、契約と監査に耐える業務には処理境界と証跡を自社で設計できる基盤を選べること。それが、AIを業務システムにする条件になります。
閉域AI・社内データ活用を相談する
閉域AI、社内データ活用、拠点間ネットワーク、音声・録音データ、クラウド接続など、AIを業務環境に組み込むためのインフラ構成についてご相談ください。
既存ネットワーク、PBX、データセンター、業務システムとの接続を前提に、実装しやすい構成を整理します。
要件を相談する