社内問い合わせ対応や顧客サポートにAIチャットボットを導入する計画がある方に向けた内容です。導入時の見積もりと、稼働後1年目の実際のコストがずれてしまう理由を整理します。
AIエージェント（人間の指示なしに複数の処理を自律的に実行するプログラム）を業務システムに組み込む際、多くの現場は「導入コスト」だけを見て意思決定します。しかし本当に効いてくるのは、稼働後に発生し続ける保守コストです。月5万件のチャットに対応するサポートエージェントを精度良く維持するには、約3.5人のフルタイム要員（FTE）と年間5000万円以上の予算が必要になるという試算があります。一方で100席分導入したMicrosoft Copilot（マイクロソフトのAIアシスタント製品）のうち、実際に毎週使われているのは20〜30席程度にとどまるという報告もあります。導入した機能と、使われ続ける機能の差が、そのままコストの無駄になっています。
何が起きるか：見積もりと実績が乖離する
従来型の業務システムは、放置してもおおむね同じ挙動を続けます。データベースのスキーマも、バッチ処理のロジックも、誰かが手を加えない限り変わりません。
ところがAIを組み込んだ機能は違います。何もしなくても精度が落ちていきます。これを「ドリフト」と呼びます。
たとえば社内FAQボットを導入した初期は、単純な質問しか来ないため正答率90%を維持できます。しかし利用者がボットを信頼し始めると、複雑な質問や例外ケースを投げるようになり、正答率が70%まで下がることがあります。エラーログには何も残らないため、気づいた時には利用者からの信頼をすでに失っています。
さらに見落とされがちなのが、AIベンダー側の都合による強制アップデートです。OpenAIはGA（一般提供）モデルを廃止する際、最低6か月の予告期間を設けるとしていますが、これは裏を返せば「6か月以内に必ず対応しなければならない期限」です。プロンプト（AIへの指示文）、評価スクリプト、出力のパース処理をすべて作り直す必要が出てきます。
なぜ起きるか：コスト構造そのものが違う
原因を段階的に分解すると、従来のソフトウェアとAI機能ではコストの発生原理が根本的に異なることが分かります。
1. リクエスト単価の掛け算が変わる
人間が画面をクリックして1件処理する場合、コストは1アクション分です。しかしAIエージェントが1件の問い合わせを解決するには、社内システムへの検索、下書き作成、レコード更新、ログ記録など6段階の処理が発生することがあります。API呼び出しごとに従量課金されるなら、単純計算で6倍のコストがかかる構造になります。
2. 連携先システムが動き続ける
Salesforce、SharePoint、Jira、Zendeskといった外部システムは、認証方式やAPIレート制限、エンドポイント仕様を頻繁に変更します。エージェントは動き続けているのに、参照している知識やAPI接続だけが古くなっていく状態が発生します。誰かが定期的に連携部分を保守しなければ、ある日突然エラーが積み上がります。
3. 法的責任の所在があいまいになる
2024年、カナダのエア・カナダのチャットボットが誤った忌引き割引ポリシーを案内した事例があります（Moffatt v. Air Canada, 2024 BCCRT 149）。利用者は案内通りに全額運賃で予約し、後から割引を申請しましたが却下されました。ブリティッシュコロンビア州の民事審判所は、エア・カナダに対し過失による不実表示として812.02カナダドルの支払いを命じています。同社は「チャットボットは別の法人格を持つ」という主張をしましたが、審判所はこれを退け「ウェブサイトの一部にすぎない」と判断しました。社内向けボットであっても、案内内容に誤りがあれば運用元が責任を負う構図は変わりません。
自分のプロジェクトが該当するか確認する
次の観点で、現在または導入予定のAI機能を点検してみてください。
- 利用ログの保存先と保持期間: 監視ダッシュボードやログ基盤（Datadog、CloudWatch等）で、正答率や誤答率を可視化できているか
- 外部モデルのバージョン固定状況:
model="gpt-4o"のようにモデル名を直接指定していないか、廃止予告への対応フローがあるか - 連携先APIの契約更新サイクル: SalesforceやZendeskとの連携部分について、認証トークンの有効期限や仕様変更の通知を受け取る窓口があるか
- 座席・ライセンスの利用率: Copilotや同等ツールについて、管理コンソールで週次アクティブ利用者数を確認できているか
- エスカレーション経路の有無: AIが誤答した場合に人間へ引き継ぐルールが、設計書やランブックに明記されているか
これらのうち2つ以上が「確認できていない」状態であれば、見積もり時点のコスト想定と実態がずれている可能性があります。
対策の手順
手順1: 現状の利用率を数値化する
AIツールの管理画面（Microsoft 365 管理センターなど）から、週次・月次のアクティブユーザー数を取得します。導入席数に対する稼働率が3割を下回る場合、契約規模の見直しを検討する材料になります。
手順2: 精度のドリフトを定点観測する仕組みを作る
初期導入時の正答率を基準値として記録し、月次で再評価するプロセスを組み込みます。評価用の質問セット（eval set）を用意し、回帰テストのように定期実行すると変化を検知しやすくなります。
手順3: モデル・API変更の通知を受け取る体制を作る
ベンダーの変更履歴ページ（OpenAIのdeprecationsページ等）を定期チェックする担当を決めます。廃止予告が出た時点でタスク化し、6か月の猶予期間内に移行作業を終えるスケジュールを組みます。
手順4: 人間へのエスカレーション経路を明文化する
AIが「分からない」と判断すべき条件（信頼度スコアの閾値、特定キーワードの検出等）を定義し、人間の担当者へ引き継ぐフローを設計書に残します。エア・カナダの事例のように、誤答がそのまま契約や返金の根拠にされないよう、案内内容と公式ポリシーページの整合性を確認する仕組みも併せて入れておきます。
手順5: 24か月の総保有コストで再試算する
初期導入費用だけでなく、想定FTE数（保守担当の人件費換算）、API従量課金、連携先保守の工数を24か月分足し合わせて再計算します。月5万件処理する規模なら約3.5人分の保守要員が必要になるという水準感を目安に、自社の処理量に応じて按分してみてください。
まとめ
AI機能の導入判断で見落とされやすいのは、稼働後にじわじわ増える保守コストです。
- 精度はドリフトする前提で、月次の定点観測を仕組み化する
- モデル廃止予告や連携先API変更に対応する担当と期限管理を決めておく
- 誤答が法的責任に発展する可能性を踏まえ、人間へのエスカレーション経路を設計段階で明文化する
- 座席稼働率と処理件数から24か月分の総保有コストを再試算し、見積もり時点の想定とのずれを確認する
まずは管理コンソールで現在のアクティブ利用率を確認し、想定と実態のギャップがどの程度あるかを数字で把握するところから始めてみてください。