問い合わせ、顧客情報、スケジュール、日報をそれぞれ別のシステムで管理していると、担当者は情報の検索と転記に追われます。本記事では、私たちギグワークスクロスアイティのコンサルタントが顧客の既存システムをMCPサーバーから呼び出せるようにし、AIエージェントで一連の作業を自動化した事例を紹介します。顧客情報を安全に扱うため、AIが実行できる操作を限定し、承認手続きとログ管理の仕組みも設けました。
【関連記事】AI研修を業務改善につなげる！DifyによるRAG構築とAIエージェント開発事例
業務を妨げる転記作業
F社には約300人の従業員がおり、法人向け設備の修理や定期点検を行っています。問い合わせ窓口には20人が所属し、1日約200件の連絡を受けます。顧客先を訪問する保守担当者は80人です。問い合わせの受付から作業報告まで複数の部門が関わりますが、各部門で使うシステムは連携していませんでした。
問い合わせのたびに4つのシステムを確認する
修理の依頼を受けた窓口担当者は、まず顧客管理システムを開き、顧客名や契約番号から契約内容を調べます。次に問い合わせ管理システムへ移り、同じ設備で過去に発生した不具合や修理履歴を確認します。訪問が必要であれば、グループウェアのスケジューラから保守担当者の予定を探します。
空いている担当者なら誰でもよいわけではありません。設備の種類によって必要な資格が異なり、担当区域や移動時間も考慮する必要があります。候補者の予定を1人ずつ確認している間、顧客に電話口で待ってもらうか、後から折り返さなければなりません。契約内容や以前の対応を確認しきれず、別の担当者へ聞き直す場合もありました。
訪問日時が決まると、窓口担当者はスケジューラへ予定を登録し、問い合わせ管理システムにも対応内容を記録します。作業を終えた保守担当者は、訪問先、設備、作業内容、交換した部品などを日報システムへ入力します。問い合わせ管理システムに残っている情報も、日報へ改めて転記していました。
1件当たり数分の作業でも、毎日繰り返せば大きな負担になります。 システムを切り替えるたびに検索条件を入れ直すため、顧客や設備を取り違える危険もあります。担当者は情報を探して記録する作業に追われ、顧客から詳しい状況を聞いたり、再発を防ぐ保守方法を提案したりする時間を確保できませんでした。
個別改修では費用に見合う効果を得にくい
F社は当初、4つのシステムを個別に改修して連携させる案を検討しました。しかし、問い合わせの内容によって確認先と処理の順序が変わります。修理依頼では契約内容、故障履歴、担当者の資格を調べますが、定期点検の日程変更では、現在の予約と担当者の予定を確認します。契約に関する質問では、訪問手配は必要ありません。
例外も少なくありません。緊急案件を優先する必要がある、空きのある担当者が遠方にしかいない、同じ設備への問い合わせが続いているといった状況では、対応の優先順位や担当者の割り当てを個別に判断する必要があります。すべての業務パターンに対応する処理を各システムへ組み込むと、設計、開発、テストの範囲が広がります。システムを更新するたびに連携部分の改修も必要になるため、導入後の保守費用も増えます。
全面的な刷新も現実的ではありませんでした。長年蓄積した顧客情報や対応履歴を移し、従業員に新しい操作を教えるには、多くの時間と費用がかかります。移行期間中の業務停止やデータ欠落も避けなければなりません。発生頻度の低い業務まで作り込めば投資額が膨らみ、対象を絞れば従来の手作業が残ります。
画面操作をそのまま自動化する方法も、例外の多い業務には向きません。決められた項目を転記する処理は自動化できても、問い合わせ内容を読み取り、必要な情報を選び、複数の候補から担当者を探す処理には別の仕組みが必要でした。
システムによってデータの管理方法が異なる点も問題でした。顧客番号、設備番号、担当者IDなどを正しく対応付けなければ、別の顧客や設備の情報を結び付けるおそれがあります。個別に連携する場合は、システムの組み合わせごとにデータの対応関係を定義し、変更のたびに検証し直さなければなりません。
業務を分類しAIエージェントで自動化する
ギグワークスクロスアイティのコンサルタントは、問い合わせ受付から日報登録までの流れを部門をまたいで整理しました。どの画面を操作しているかではなく、担当者が何を確認し、どこで判断し、どの情報を登録しているかを調べました。
整理すると、担当者の作業は、顧客情報や履歴の取得、訪問候補の作成、顧客との日程調整、予定の登録、メールの下書き、日報の作成と登録に分けられます。情報を検索したり候補を作成したりする手順が一定でない場合でも、AIエージェントを活用できます。一方、顧客との日程調整や社外へ送る文章の確認は、担当者が責任を持って行います。
そこで、顧客への説明と訪問日時の確定は担当者が行い、その前後で必要となる検索、下書き、登録をAIエージェントへ任せる方針を決めました。AIエージェントは、依頼された目的に応じて必要な情報や機能を選び、一連の作業を進めるソフトウェアです。
既存システムには、それぞれ外部から機能を利用するためのAPIが用意されていました。AIエージェントから既存システムのAPIをMCP経由で利用できれば、システムを作り直さずに、問い合わせ内容に応じて必要となる一連の作業を支援できます。F社はこの考え方に基づき、MCPを使ってシステムを連携する方針を採用しました。
MCPサーバーでAIが実行できる操作を限定する
F社は、自動化する範囲を広げると同時に、AIに許可しない操作を技術的に定めました。顧客情報の流出や誤操作を避けるには、AIへの指示に禁止事項を書くだけでは足りません。AIが利用できる機能と権限をMCPサーバー側で制限し、許可されていない操作は実行できないようにしました。
既存のAPIをMCPサーバーから呼び出す
MCPは、AIを利用するアプリケーションと外部のデータや機能を接続するための共通仕様です。ギグワークスクロスアイティは、F社の各システムが備えるAPIをMCPサーバーから呼び出せるようにしました。AIエージェントはMCPサーバーに公開された機能を確認し、問い合わせ内容に応じて必要なものを使います。
AIエージェントは、顧客管理システムで契約情報を検索し、問い合わせ管理システムで過去の対応履歴を調べます。スケジューラでは担当者の予定を確認し、合意済みの訪問予定を登録します。日報システムには、保守担当者が確認した内容を日報として登録します。
顧客情報、対応履歴、予定、日報は従来のシステムで管理し続けます。AIエージェントは、複数のシステムから必要な情報を集め、システム間で受け渡します。既存システムの役割を変えず、部門間の情報連携だけを追加したため、大規模なデータ移行や画面の刷新を避けられました。
問い合わせを受けると、AIエージェントは窓口担当者の権限で顧客情報と過去の対応履歴を取得します。訪問が必要な場合は、設備の種類や担当区域、担当者の資格、空き時間を基に候補を絞り込みます。窓口担当者が顧客と日時を決め、登録内容を確認すると、AIがスケジューラへ予定を登録します。
顧客への返信が必要な場合は、契約内容や対応履歴を基にメールの下書きを作ります。担当者は内容と宛先を確認し、自分で送信します。作業後は、AIが問い合わせ履歴、訪問予定、保守担当者の作業メモを基に日報の草稿を作成します。保守担当者が草稿を確認した後に限り、AIが日報システムへ登録します。
AIに許可しない操作を定義する
AIエージェントは、利用できる機能の中から目的に合うものを選びます。業務に不要な機能まで公開すると、AIが誤って利用する可能性があります。F社は業務ごとに必要な操作を洗い出し、AIに公開する機能を最小限に絞りました。
顧客管理システムでは、問い合わせ対応に必要な顧客情報を検索できますが、全顧客の一括取得、契約情報の削除、利用者の権限変更はできません。スケジューラでは予定の検索と新規登録を許可する一方、既存予定の一括変更や削除は許可しません。メールは下書きの作成までとし、送信機能をAIに公開していません。
AIが誤ってメール送信や予定削除を要求しても、MCPサーバーが拒否するため、既存システムでは実行されません。AIへの指示に頼らず、システム側で誤操作を止められます。
公開している機能にも制限を設けました。顧客情報の取得件数と検索期間に上限を設け、予定や日報に登録できる項目も限定しました。AIが生成した値をそのままAPIへ渡さず、顧客番号や担当者IDが正しいか、日時の前後関係に問題がないか、必須項目が入力されているか、文字数が上限を超えていないかをプログラムで検証します。条件を満たさない場合は登録しません。
同じ予定や日報を二重に登録しないよう、各処理には識別番号も付けました。日報の登録機能を呼び出すには、保守担当者が草稿を確認した記録が必要です。登録対象の日報に対応する承認情報がなければ、MCPサーバーは登録を受け付けません。
利用者の権限を超える操作を禁止する
AIエージェントが高い権限を持つ共通アカウントで各システムへ接続すると、担当者本人に閲覧権限のない顧客情報まで取得できてしまいます。F社は利用者ごとに認証を行い、AIが本人の権限を超えて操作できないようにしました。
窓口担当者は、自部門が扱う顧客と問い合わせ履歴を参照できます。保守担当者は、自分が担当する訪問予定と日報を確認できます。AIエージェントも、この範囲内でシステムを利用します。AIが担当外の顧客や別部門の情報を取得しようとしても、MCPサーバーと既存システムの双方が拒否します。
誰がどの問い合わせで何を実行したかを記録する仕組みも整えました。操作ログには、利用者、日時、問い合わせ番号、呼び出した機能、承認の有無、処理結果を残します。監査ログには顧客の氏名や問い合わせ内容を保存せず、顧客番号と処理IDから必要な記録を追跡できるようにしました。
短時間に大量の情報を取得しようとした場合や、同じ処理が繰り返し失敗した場合には、MCPサーバーが処理を止めて管理者へ通知します。異常な操作を検知した段階で止めるためです。
クラウドAIの契約条件
F社は、クラウドAIサービスをエンタープライズ契約で利用しました。選定時には、入出力データがモデルの学習に使われるか、保存期間と保存先がどう定められているかを確認しました。管理者が利用者を管理し、権限を設定できるか、利用状況を監査できるかも選定条件に加えています。
F社は、サービス名やプラン名だけで安全性を判断せず、契約内容と管理画面を確認したうえで、情報管理規程を満たすサービスを選びました。AIに渡す情報も処理に必要な項目に絞り、日程調整や回答作成に使わない個人情報は送信しません。
MCPはAIと外部システムを接続するための共通仕様ですが、適切な権限や承認手順まで自動的に決めるわけではありません。F社はクラウドAIの契約条件を確認したうえで、MCPサーバーによる機能制限、既存システムの権限管理、利用者による承認、操作ログを組み合わせて安全性を確保しました。
顧客と向き合う時間が増えた
F社は、すべての問い合わせを一度に自動化せず、対象を絞って効果と安全性を確かめました。試験で見つかった例外を設計に反映した後、利用者を段階的に増やし、導入開始から6か月後に本稼働へ移りました。成果は、削減した作業時間と、顧客対応や顧客ミーティングに充てた時間で評価しています。
3か月間の検証
試験導入では、修理依頼と定期点検の日程変更を対象にしました。問い合わせ窓口と保守部門から一部の担当者を選び、AIエージェントを利用して、顧客情報の取得から日報の登録までの一連の処理を検証しました。
通常の処理に加え、社名が似た顧客が複数いる場合や、顧客番号と問い合わせ内容が一致しない場合、必要な資格を持つ担当者が空いていない場合、移動時間を確保できない場合などの例外も検証しました。必要な情報や条件がそろわない場合は、AIが処理を止め、担当者に確認を求めるようにしました。
予定の登録では、同じ訪問予定がすでに登録されていないか、営業時間外に設定されていないか、担当者の既存の予定と重ならないかを確認しました。日報では、問い合わせ履歴と作業メモが食い違う場合や、必須項目が不足している場合に登録を止めました。
試験中に見つかった例外には、AIへの指示を変えるだけでなく、MCPサーバーの入力条件や承認画面を修正して対処しました。
月520時間の業務を削減
本稼働後は、情報収集、日程調整、日報作成にかかる時間を導入前と比べました。計算は1か月20営業日を基準としています。
顧客情報と過去の対応履歴を集める時間は、1件当たり8分から3分へ短縮しました。1件当たり5分短くなり、1日120件では合計600分を削減できました。20営業日では12,000分となり、月200時間を削減しました。
訪問候補の確認からスケジューラへの登録までは、1件当たり6分から2分へ短縮しました。1件当たり4分短くなり、1日60件では合計240分を削減できました。20営業日では4,800分となり、月80時間を削減しました。
日報の作成と登録は、保守担当者1人当たり1日15分から6分へ短縮しました。1人当たり9分短くなり、80人では1日合計720分を削減できました。20営業日では14,400分となり、月240時間を削減しました。
3つの業務を合わせると、削減時間は月520時間になりました。AIがすべての作業を代行したわけではありません。窓口担当者は顧客と合意した訪問日時を確認し、保守担当者は日報の草稿を確認してから登録を承認します。担当者による確認を残しても、複数の画面から情報を探し、同じ内容を入力し直す負担を大きく減らせました。
削減した時間で顧客に向き合う
F社は、作業時間の削減だけでなく、担当者がその時間を何に充てたかも測りました。顧客対応や顧客ミーティングに充てた時間は、月1,100時間から1,360時間へ増えました。月260時間、23.6％の増加です。
顧客ミーティングは月160件から220件へ増えました。1回当たりの平均時間は1時間で、ミーティングの総時間は月160時間から220時間へ増えました。月60時間、37.5％の増加です。これまで日程調整や日報作成に使っていた時間を、設備の状況を詳しく聞き取る面談や、故障を未然に防ぐ保守計画の説明へ振り向けられるようになりました。
問い合わせ窓口でも、顧客を待たせる時間が減り、説明を遮らずに聞けるようになりました。過去の対応履歴がまとまって表示されるため、以前の修理内容を踏まえて質問できます。保守担当者は日報を一から書く代わりに、AIが作った草稿の誤りや不足を確認し、必要な情報を補います。
削減した520時間のうち、顧客対応と顧客ミーティングに振り向けたのは260時間です。残りは草稿の確認、保守計画の作成、従業員教育、業務改善に使いました。単に事務作業を減らすのではなく、担当者が経験や判断力を生かせる業務に時間を充てられるようになった点が、F社にとって大きな成果です。
AI利用拡大のためのタスクフォースを設立
F社は本稼働後、見積管理システムや在庫管理システム、社内FAQとの連携を検討し始めました。見積管理システムと連携すれば、契約範囲外の作業について概算金額を案内できます。在庫管理システムと連携すれば、交換部品の有無を確認したうえで訪問日を決められます。
接続先が増えるほど、AIが扱う情報と実行できる操作も増えます。部門ごとに開発を進めると、権限設定が統一されなかったり、本来は承認が必要な操作まで自動化してしまったりするおそれがあります。F社は全社で共通のルールを定めるため、業務部門、情報システム部門、セキュリティ部門、法務・個人情報保護部門、内部監査部門、利用者の代表が参加するタスクフォースを設立しました。
ギグワークスクロスアイティのコンサルタントは、タスクフォースの役割と審査手順の策定を支援しました。新しい機能をAIに公開する際は、扱う情報、必要な権限、承認の要否、ログの保存期間、問題が起きた場合の停止手順を確認します。導入後も利用状況と業務効果を定期的に見直します。
接続先を増やす際は、利用者と対象業務を限定して試験し、安全性と効果を確認します。各操作を誰の権限で実行し、誰が責任を負うかを明確にしたうえで、段階的に利用範囲を広げる体制を整えました。
まとめ
F社の事例が示すように、AIエージェントは単純な作業を自動化するだけでなく、分断されていたシステムやツールをつなぐ役割も果たします。既存システムのAPIを活用すれば、個別改修にかかる開発費が障壁となり、システム連携を進められなかった企業でも導入を検討できます。
一方、AIエージェントには想定外の動作が起こり得ます。AIが利用できるシステムや機能を増やすほど、誤操作や情報流出が業務に与える影響も大きくなります。AIエージェントを導入する際は、業務シナリオを設計すると同時にリスクを洗い出し、顧客情報など、想定外の事態が起きても守るべき対象を明確にする必要があります。
守るべき対象が決まれば、AIに許可する操作、人が確認する処理、異常時に処理を停止する条件を具体化できます。ギグワークスクロスアイティのコンサルタントは、業務の整理からリスクの洗い出し、ルールの策定、システム開発、運用体制の整備まで、AIエージェントの導入に必要な支援を提供します。
参考文献
Understanding Authorization in MCP – Model Context Protocol
Security Best Practices – Model Context Protocol
この記事を書いた人
