AIエージェントはローカルかクラウドか｜業務ごとに処理場所を決める

「社内のPCで動くAIなら、顧客情報は外に出ない」。AIエージェントを検討するとき、このように考えていないでしょうか。

PC上のアプリを操作していても、回答を作るモデルはクラウドにある場合があります。反対に、モデルがPC内で動いていても、外部の顧客管理システムへ記録を送るなら、その工程では通信が発生します。

選ぶべきなのは、ローカルかクラウドかという一つの看板だけではありません。業務を工程に分け、どのデータを、どこで処理し、どこに保存するかを決めることが出発点です。

10月7日のMicrosoftの発表で何が変わったか

Microsoftは2026年10月7日、WindowsでローカルとクラウドのAIを組み合わせる「ハイブリッドインテリジェンス」の構想と関連機能を発表しました。GitHubのHydraFusionが端末上のモデルも利用する仕組みは、10月後半に実験的プレビューを予定するとしています。Copilot+ PC向けの関連機能は、今後数か月にかけて展開を始める予定です。Microsoft公式発表

つまり、発表された機能のすべてが、10月8日時点でどのPCでも使えるわけではありません。利用できる時期や条件は端末・地域などで異なります。

企業にとっての論点は、処理の内容に応じてローカルとクラウドを組み合わせる選択肢です。以下はこの発表を手がかりにしたIvyLeapの設計提案であり、Microsoftが電話受付向けの機能を提供したという意味ではありません。

「ローカル」を三つに分けて確認する

導入の打ち合わせでは、ローカルという言葉が何を指すかをそろえます。

• 操作画面がローカル：アプリがPC上で開くこと。AIの計算場所とは別です。
• モデルの処理がローカル：文章などを読み取り、出力を作る計算を端末内で行うこと。
• データの保存がローカル：元の資料や結果を端末内に残すこと。同期やバックアップの送信先も別途確認します。

この三つがすべて一致するとは限りません。「モデルはローカルですが、診断用の記録や作成した要約は外部に送ります」という構成も考えられます。

外部への送信を制限したいなら、モデルの設定だけでなく、連携ツール、ログ、保存先まで確認します。なお、氏名を取り除いただけでは、住所や会話の内容から個人が分かる場合もあります。「名前を消したから何でも送れる」と一律に判断しないようにします。

AIコールセンターの後処理を分解してみる

たとえば、通話後の記録を作る業務には、次の工程があります。

1. 音声を受け取り、録音や一時ファイルを扱う
2. 音声を文字に起こす
3. 会話から要点と未対応事項を抜き出す
4. 担当者が内容を確認する
5. 顧客管理システムへ保存する

録音を社内に残す構成でも、文字起こしを外部サービスへ依頼すれば音声の送信が必要になります。文字起こしを社内で行い、その全文をクラウドの要約モデルへ渡せば、今度は文章の内容が送信されます。

検討例として、社内で文字起こしと必要項目の抽出を行い、外部へ送信してよい範囲だけをクラウド側の処理へ渡す構成があります。ただし、これは各工程に対応するモデルやシステムを組み合わせ、品質とデータの扱いを検証できる場合の案です。特定のサービスを選ぶだけで自動的に実現するとは限りません。

工程ごとに「入力データ」「処理する場所」「保存先」「保存期間」「外部送信の有無」を一行ずつ記すと、確認する範囲を整理できます。

クラウドへ切り替える条件も、先に決める

端末内のモデルで処理できないとき、自動的にクラウドへ切り替える構成には注意が必要です。通常時は社内で扱う資料でも、長い文章や難しい依頼のときだけ外部へ送られる可能性があるためです。

たとえば、次のように対象を区分します。

• 公開済みのサービス説明文：許可されたクラウド処理も利用候補にする
• 顧客を特定できる通話記録：社内で認めた処理場所と送信範囲に限定する
• 送信可否を判定できない資料：処理を保留し、担当者へ確認する

この区分は各社の業務に合わせて決める必要があります。単に「難しい質問なら高性能なモデルへ送る」という条件だけで、送信先を変えないことが大切です。

設定画面に「ローカル優先」と書かれていても、それは「外部送信なし」と同じ意味とは限りません。通常時と切り替え時の両方について、実際の送信先を開発側へ確認します。

通信が切れたとき、どこまで続けられるか

端末内のモデルが動いていても、最新の顧客情報の照会や外部システムへの保存が必要なら、その工程は通信に依存します。AIが文章を作れることと、業務を完了できることを分けて考えます。

通話後の要約なら、回線障害時に要約案まで作り、顧客管理システムへの登録は「未保存」として待機させる運用が考えられます。一方、最新の契約内容を照会できない場合は、過去の情報だけで確定的な案内をしないようにします。

また、担当者のPCで処理するなら、電源断やスリープ中には処理が止まる構成もあります。これはローカルモデルの精度とは別の問題です。営業時間外にも必要な処理か、端末が止まった場合の担当は誰かを確認してください。

導入前は、同じ業務で比較する

「ローカルのほうが安い」「クラウドのほうが正確」と最初から決めず、自社の入力で確かめます。利用料金に加え、端末の準備、更新、管理、確認作業も含めて判断します。

まずは架空の通話記録など、検証用のデータで次の場面を試します。

• 通常の記録：必要な要点を落とさず、担当者が確認できる形になるか
• 長い記録：処理場所が変わる場合に、送信ルールが守られるか
• 通信の切断：どこまで完了し、何が未処理かを画面と記録で区別できるか
• 端末の再起動：途中の記録が消えたり、保存済みの内容が二重登録されたりしないか
• モデルの更新：同じ入力で要約の欠落や表現が変わらないか

結果は、処理時間だけでなく、要約の欠落、修正の手間、外部への送信内容、保存結果まで並べます。端末やモデルの性能だけでなく、業務として続けられる構成かを判断するためです。

IvyLeapのAIエージェント構築支援では、対象業務と必要な連携を整理して構成を検討します。通話後の要約や受付記録を含む電話業務の活用については、AIコール導入支援もご覧ください。