AIと既存システムを連携する前に決めること

CRMや表計算にAIをつなぐと、担当者名や商品資料をすぐ参照できる一方で、ステータス変更や外部送信まで任せてよいかで迷いやすくなります。AIと既存システムの連携では、最初に参照と更新を分け、入力、参照先、更新先、承認者をそろえることが判断の起点になります。まずは既存システムを残したまま、返信案の作成までを小さく切り出すと、どこで人が確認するべきかを決めやすくなります。

AIと既存システム連携の境界

AIと既存システムをつなぐ時の境界は、AIが情報を読むだけか、既存システムの値を書き換えるかで大きく変わります。参照はCRMの担当者名や商品資料などを読み、回答や下書きに使う動きです。更新はCRMのステータスや表計算のセルなど、後から業務判断に使われる記録を変更する動きです。

参照と更新の違い

問い合わせID Q-001を編集部の設計例として使うと、最初の動きはCRMにある現在の担当者名を読み、商品資料から回答に必要な事実を探すことです。実システムを動かした結果ではなく、境界を決めるための例です。AIはその情報をもとに返信案を作り、担当者が内容を確認します。この範囲では外部送信を行わず、CRMのステータスも変更しないため、既存システムへの影響は参照と下書きに限られます。

次に境界が変わるのは、返信案を作った後にCRMへ対応済みなどの状態を書き込む場面です。更新を含めると確認する項目が増えるため、後半の「更新へ進む時の確認」で整理します。段階ごとの止める条件と確認者は、次の図と表のとおりです。

APIとMCPの役割

APIは、相手システムが外部からの操作を受け付ける入口です。CRMが担当者情報の取得やステータス変更の操作を提供している場合、AI側のアプリケーションはその入口を通じて、許可された範囲の参照や更新を行います。ただし、入口があることと、業務上どこまで任せるかは別の問題です。

MCPは、AIアプリケーションがツールや資料などに接続するための共通プロトコルです。（MCP Architecture overview・公式、2026年10月12日確認）公式資料では、AIアプリケーションがMCPホストとなり、MCPクライアントを通じてMCPサーバーへ接続し、ツール、リソース、プロンプトなどの文脈を受け取る構造が説明されています。つまりMCPは接続の型をそろえる役割を持ちますが、すべての既存システム連携に必須とは限りません。

MCPのツール仕様（2025-11-25版）では、外部システムの照会や操作に使うツールをサーバーが公開し、AIモデルが文脈に応じて呼び出せると説明されています。（MCP Tools specification 2025-11-25・公式、2026年10月12日確認）同じ仕様は、信頼性と安全性のために、人がツール呼び出しを拒否できる状態や、操作前の確認を設けることを推奨しています。MCPの最新版は2026-07-28版と表示されているため、採用時は版を確認してください。MCPが用意されていても、相手システムの権限、承認者、更新前の停止条件は業務側で決める必要があります。

CRMと表計算の受渡し図

CRMや表計算とAIをつなぐ前に見るべきものは、接続方式より先に、情報がどこから入り、どこへ戻り、どこで人が止めるかです。

問い合わせQ-001の流れ

AIへ渡す入力は問い合わせ本文と問い合わせIDに絞ります。AIはCRMの現在の担当者と商品資料を参照して返信案を作りますが、返ってくるのは送信済みメールではなく、担当者が確認する下書きです。担当者はその案を読み、顧客へ送るか、修正するか、別の確認へ回すかを判断します。

更新先は空欄にせず、初期範囲では更新なしと明示します。CRMのステータス変更や外部送信を含めると、権限、履歴、差し戻しの設計が変わるためです。

渡す情報と戻るもの

連携条件は、渡す情報、受け取るもの、更新の有無、担当を同じ行でそろえると読み違いが減ります。表計算で管理している商品資料を参照する場合は、読み取り専用のシートか範囲を指定し、初期範囲では書き込みを許す列を置きません。後で更新へ広げるなら、書き込む列と行の範囲、変更前の値を残す履歴の置き場所を先に決めます。次の表はCRMの問い合わせを例にしていますが、表計算でも同じ行の立て方で使えます。

この記入例は設計例です。CRM担当者、商品資料、返信案の順に読むと、AIが参照する情報と、人が確認してから扱う情報が分かれます。CRMステータスの行を消さずに初期範囲外と置くことで、更新しない判断も設計に残せます。

連携方式を選ぶ条件

連携方式は、更新の重さで選びます。ここでは編集部の整理として、標準コネクタを既存サービスが用意する接続部品、個別開発を既存の項目名や承認順、例外時の戻し方に合わせて接続やログを作る方式と呼びます。参照だけの段階では、読み取り権限に限ったコネクタやAPIで足りるかを先に確かめます。更新申請から先は、承認や履歴を残せるかが決め手になり、足りなければ個別の作り込みを検討します。どの製品がどこまで対応するかは、利用するCRM事業者の公式資料で確認してください。

APIがある場合は、相手システムが提供する操作の入口を使って、参照や更新を設計できます。APIがない古いシステムでは、具体的な製品別手順を決め打ちせず、まずAIが読む情報を表計算や出力ファイルとして受け渡し、更新は人の確認に残す設計から考えます。

AI既存システム連携の小さな試験

小さな試験では、既存システムを一気に書き換えず、AIが読む情報と人が判断する位置を固定します。問い合わせ返信のように、入力、参照先、戻る案、承認者が見えやすい業務から始めると、参照だけで足りる範囲と更新が必要になる範囲を分けやすくなります。

返信案までに絞る

返信案までの範囲で見るのは、AIの文章が便利かどうかだけではありません。AIが参照した担当者名、商品資料の根拠、人が直した箇所を記録すれば、顧客対応に使える形へ整えるべき情報が分かります。CRMのステータスを変えないため、試験の失敗が顧客対応の進行状態に直接影響しにくく、外部送信とステータス変更は別の判断として扱えます。

更新へ進む時の確認

返信案の品質が確認できても、すぐにCRM更新へ進める必要はありません。更新を含めるなら、対象レコード、変更前、変更後、根拠、承認者、再取得時刻を同じ画面や記録で確認できる形にします。再取得時刻は、更新判断に使った現在値をいつ取得したかを示す時刻です。

設計例では、更新申請でAIが変更内容を提案し、人が承認するところで止めます。たとえば、対象レコードがQ-001、変更前が未対応、変更後が返信案確認済み、根拠が担当者の確認、承認者がCS責任者、再取得時刻が承認直前の取得時刻というように並べます。ここまでそろうと、AIが書き換える前に、人が業務上の妥当性を確認できます。

更新前に止める条件

更新前に止める条件は、AIが便利かどうかではなく、既存システムで許された範囲を超えないかで決めます。CRMや表計算をつなぐ場合も、参照できる情報、変更できる項目、承認なしに進めない操作を分けると、情報漏えいや重複更新の起点を減らせます。

権限と共有範囲

既存システムの権限は、AIに接続した後も利用者ごとの境界として残します。Microsoft Copilotの資料では、組織データはユーザーがアクセス権を持つ範囲で扱われ、個々の利用者に少なくとも表示権限がある組織データだけが表示されると説明されています。（Microsoft Copilotのデータ・プライバシー・セキュリティ資料・公式、2026年10月12日確認）この資料にはMicrosoft 365 CopilotからMicrosoft Copilotへの名称変更も案内されています。AIと既存システムの連携では、この考え方をCRMや表計算にも当てはめ、部署全体という大きな単位ではなく、利用者、参照対象、操作、確認者を分けて設計します。

共有範囲は、社内の誰が見るかだけでなく、接続先のサービスやエージェントがどのデータを扱うかまで含めて確認します。同じ資料では、エージェント利用時にプライバシー声明や利用条件を確認すること、管理者がエージェントの権限やデータアクセスを確認できることが示されています。CRM更新のような操作では、営業部という部署名だけで広い権限を渡さず、担当者名の参照、商品資料の参照、ステータス変更、外部送信を別々の許可として扱うほうが安全です。

IPAはAI利用時の最低限かつ有効性の高いセキュリティ対策を利用者やマネージャ向けに整理し、クラウドAIに営業秘密を教えないことや、AIブラウザを社内用と社外用で分けることを項目として挙げています。（IPA AI利用者のためのセキュリティ豆知識・公式、2026年10月12日確認）既存システム連携では、この注意を業務画面の権限に落とし込み、社外へ出せない情報を返信案の入力に含めない、共有フォルダの資料をAIの参照対象に混ぜない、といった境界を先に決めます。

連携先から渡す資料の確認方法 関連記事を読む

古いデータと重複

古いデータをもとに更新すると、AIの判断が正しく見えてもCRM側の現在値とずれます。変更履歴は、対象レコードに対して誰がいつ何を変えたかを追える記録です。更新前には、対象レコードの現在値、直近の変更履歴、AIが参照した再取得時刻を並べて確認します。

タイムアウトや応答切れが起きた場合、更新できなかったと決めつけて同じ依頼を再実行すると、重複更新につながることがあります。AWSの資料では、タイムアウトや失敗は副作用が起きていないことを意味するとは限らず、再試行は依存先の負荷を増やす場合があるとされています。副作用のある操作は、冪等でなければ安全に再試行できないとも説明されています。（AWS Timeouts, retries, and backoff with jitter・公式、2026年10月12日確認）冪等性は、同じ依頼を繰り返しても追加の副作用が起きない性質です。

問い合わせID Q-001のような依頼では、CRM更新要求がタイムアウトした時に、未更新としてすぐ再実行しない形にします。現在値と変更履歴を照合し、同じ依頼IDで処理済みの記録がないかを確認してから再開します。

同じ依頼IDの再実行を扱う時は、更新先だけでなく、根拠になった入力も見ます。AWSの資料では、同じ識別子でパラメータの組み合わせが変わった場合、別の意図として扱い検証エラーを返す設計が説明されています。（AWS Making retries safe with idempotent APIs・公式、2026年10月12日確認）CRMや表計算では、問い合わせID、対象レコード、変更前、変更後、根拠資料、承認者をひとまとまりで見れば、同じ依頼の再開なのか、別の更新なのかを判断しやすくなります。

発注前の確認表

発注前の確認表は、外部仕様に書かれている安全策と、業務側で決める運用条件を混ぜずに作ります。外部仕様は、権限、入力検証、タイムアウト、ログ、利用者確認といった考え方の根拠になります。次の項目は編集部の設計例で、初期範囲ではCRMステータスを更新しません。

• 入力資料：AIに渡す問い合わせ文、商品資料、社内メモを分ける
• 参照先：CRMの担当者、商品資料、表計算の項目を列挙する
• 更新先：初期範囲では更新なしとし、後で対象レコードを指定する
• 承認者：返信案、更新申請、外部送信の確認者を分ける
• ログ：依頼ID、再取得時刻、変更前、変更後、根拠を残す
• 差し戻し先：AIの案を直す担当者と戻す項目を決める
• 例外時の戻し方：タイムアウト時は現在値と履歴を照合してから再開する

この確認表は、AIに任せる作業を増やすための書類ではなく、止める条件を共有するためのものです。IPAの資料は、AI利用では利用者側と開発側の双方に向けた対策の強化が求められると述べています。（IPA AI利用者のためのセキュリティ豆知識・公式）発注前の段階で確認者と差し戻し先まで決めておくと、承認なしの自動更新に進まず、参照だけの試験から安全に広げられます。

連携条件を要件へまとめる方法 関連記事を読む

自社の業務で試す

インパクトトライアルでは、対象業務を相談のうえ決め、最短1ヶ月で現状の数字とAI適用後の見込みを出し、実資料の試作を毎週更新して同じ指標で実測します。本番環境の構築と継続運用は含まず、結果をもとに次の段階を提案します。

インパクトトライアル