AIエージェント連携とは？仕組み・始め方と案件ワークスペースでの活かし方

「AIエージェント連携って、結局どこまでを指す言葉なのか」「自分たちの案件現場に関係があるのか」と迷う方は多いはずです。AIエージェント連携とは、AIエージェントが外部のツールやデータ、あるいは別のエージェントとつながり、実際の業務を実行する仕組みを指します。チャットで質問に答えるだけのAIと違い、連携したAIは資料を探し、情報を取りに行き、下書きや準備まで肩代わりします。本記事では、連携の全体像をまず2つの層に整理し、function calling・MCP・A2Aという主要な方式の違いと使い分け、そして案件ごとに顧客と共有するワークスペースへどう適用するか、始め方の手順と導入前の注意点まで一本で解説します。Terasuを開発・運営するkoromoは、自分たちの受託案件もTerasuの「Room」で顧客と進めています。本記事はその運営元の編集部が、概念を実際の現場に接続する立場からまとめました。

AIエージェント連携とは？基礎から整理する

AIエージェント連携とは、AIを外部のツールやデータ、他のエージェントとつなぐ仕組みで、整理の鍵は対象を2層に分けて捉えることです。

混同されやすいのですが、AIエージェント連携は「決まった手順を自動で繰り返す」だけの仕組みとは異なります。あらかじめ定めた操作をなぞる自動化と違い、連携したエージェントは状況を読み、必要な道具を自分で選んで呼び出し、結果を見て次の動きを決めます。決まりきった作業の肩代わりにとどまらず、文脈に応じて判断しながら実務を進められる点が、従来の自動化との大きな違いです。だからこそ「何につなぐか」の設計が効果を左右します。

ここで重要なのは、「連携」と一口に言っても対象が2種類ある点です。1つはAIと「ツール・データ」をつなぐ連携、もう1つはAIと「別のAIエージェント」をつなぐ連携です。この2つを分けて捉えると、function calling・MCP・A2Aといった用語がそれぞれどの場面の技術なのかが一気に見通せます。用語の多さに圧倒される前に、まず全体を俯瞰する地図を持っておくと、後の比較や導入判断がぐっと楽になります。

ツール連携とエージェント間連携の2層

連携は「対ツール・データの連携」と「対エージェントの連携」という2つの層に分けて捉えると整理できます。

前者は、AIが表計算やデータベース、ファイル置き場、業務システムといった「道具と情報」にアクセスして作業する層です。AIが単独では持っていない社内資料や最新データを参照し、計算や検索、書き込みといった操作を実行します。この層を支えるのが、後述する function calling と MCP です。AIが「何を使えるか」を知り、必要なときに呼び出して結果を受け取る、という関係がこの層の中心になります。

後者は、役割の異なるAIエージェント同士が互いに連絡を取り合い、仕事を分担したり委任したりする層です。たとえば調査を担うエージェントと、文章をまとめるエージェントと、スケジュールを調整するエージェントが協調して一つのゴールに向かう、といった構図です。この層を支えるのが A2A です。1体のAIで完結させるのではなく、得意分野の違うエージェントを組み合わせて複雑な仕事をこなす、という発想がここにあります。

多くの現場でまず必要になるのは前者、つまりツール・データとの連携です。社内の情報や既存システムにAIをつなぐだけでも、調べ物や下書きの手間は大きく減ります。エージェント同士の協調は、ツール連携が回り始めた先にある発展形だと考えると、優先順位を付けやすくなります。

この2層の地図を手元に置いておくと、新しい用語に出会ったときも「これはツールをつなぐ話か、エージェントをつなぐ話か」という問いで仕分けできます。AIエージェント連携をめぐる議論は進展が速く、次々と新しい規格や製品が登場しますが、その多くはこの2層のどちらか（あるいは両方）に位置づけられます。個々の技術名を追いかける前に、まず「どちらの層の話をしているのか」を見分ける習慣を持つことが、情報に振り回されないための要になります。

なぜいま「連携」がこれほど語られるのかというと、AIの役割が「言葉を返す」段階から「作業をこなす」段階へと移ってきたからです。文章を生成するだけなら外部とつながる必要はありませんが、実際の業務では「最新の資料を見る」「システムに記録する」「別の担当に引き継ぐ」といった、外の世界に触れる動作が欠かせません。連携は、この外の世界への接点をAIに与える仕組みであり、AIを「賢い相談相手」から「手を動かす実務の担い手」へと変える鍵になっています。

連携を支える基礎技術（function calling・MCP・A2A）

連携を支える基礎技術は、ツール呼び出しの土台である function calling、接続を標準化する MCP、エージェント間をつなぐ A2A の3つです。

まず function calling（tool calling とも呼ばれます）は、AIモデルが外部のシステムやデータにアクセスするための基礎的な仕組みです。開発者が「このツールが使える」とJSONスキーマで定義しておくと、モデルは指示を読んで必要だと判断したときにそのツールの呼び出しを返します。実際の処理はアプリケーション側が実行し、その結果を再びモデルに渡して最終的な回答へつなげる、という多段のフローで動きます。OpenAIの公式ドキュメントでは、この流れが「ツールを添えてモデルに要求する→モデルからツール呼び出しを受け取る→アプリ側で実行する→結果を添えて再度要求する→最終回答を得る」という5段階として整理されています（function callingガイド）。つまり function calling は、AIが「言葉を返す」だけでなく「道具を使う」ための最小単位だと捉えられます。

次に MCP（Model Context Protocol）は、このツール連携を標準化するためのオープン標準です。Anthropicが2024年11月25日に発表しました（Anthropic公式発表）。MCPは、AIアプリケーションをデータソースやツール、ワークフローといった外部システムへつなぐための共通の規格で、公式ドキュメントでは「AIアプリ向けのUSB-Cポート」にたとえられています（MCP公式ドキュメント）。USB-Cが機器をつなぐ差し込み口を1つに統一したように、MCPは「AIと外部システムのつなぎ方」を統一します。接続のたびに個別の作り込みをするのではなく、標準に沿えば多様なツールやデータに同じ流儀でつながる、というのがMCPの狙いです。仕組みとしては、AIアプリ本体であるホストが、接続先ごとにクライアントを用意し、データや機能を提供するサーバーと二方向でつながるクライアント・サーバー型を採ります（MCPアーキテクチャ）。サーバー側は、AIに行動を与えるツール、文脈となるデータ、やりとりの雛形となるプロンプトを提供します。

標準に乗ることは、長い目で見た安心にもつながります。特定の製品だけが使える独自のつなぎ方に依存すると、乗り換えや拡張のたびに作り直しが発生しかねません。オープンな標準が広く支持されるほど、同じ接続の考え方を別の環境でも生かしやすくなり、選択肢を狭めずに済みます。いまMCPのような標準が注目されるのは、便利さだけでなく、こうした将来の選びやすさを残してくれるからでもあります。

そして A2A（Agent2Agent）は、エージェント同士が相互運用するためのオープンプロトコルです。Googleが2025年4月9日に、50社を超える技術パートナーとともに発表しました（Google A2A発表）。A2Aは、AIエージェント同士が安全に情報を交換し、アクションを調整し合うことを目的としており、AnthropicのMCPを「補完する」ものと位置づけられています。MCPがAIとツール・データの接続を担うのに対し、A2AはAIエージェント間の連絡を担う、という役割分担です。さらにA2Aは、2025年6月23日にGoogleからLinux Foundationへ寄贈され、中立的なガバナンスのもとで運営されるプロジェクトになりました（Linux Foundationへの寄贈）。Linux Foundationの発表では、A2Aは100社を超える主要テクノロジー企業の支持を得ているとされ、Googleの寄贈の発表では、AWS・Cisco・Microsoft・Salesforce・SAP・ServiceNowが創設メンバーとして紹介されています（Linux Foundationの発表、Linux Foundationへの寄贈）。特定企業の持ち物ではなく、業界横断で育てる共通基盤へと舞台が移った形です。

補足しておくと、MCPは発表の時点から、企業で広く使われるシステム向けにあらかじめ用意されたサーバーを伴って登場しました。Google Drive・Slack・GitHub・Git・Postgres・Puppeteerといった定番のシステムに接続するためのサーバーが例として示されており、ゼロから作らなくても標準的なつなぎ方に乗れる設計です。対応するクライアント側も幅広く、ClaudeやChatGPTのようなAIアシスタント、Visual Studio CodeやCursorといった開発ツールがMCPに対応しています。接続される側とする側の両方に選択肢があることが、標準としての広がりを支えています。

A2Aの特徴としては、各エージェントが自分の能力を「Agent Card」と呼ばれるJSON形式の情報で公開できる点が挙げられます。これにより、相手のエージェントが「何ができる存在か」を見つけて連絡を取り、仕事を委ねられます。人間のチームでいえば、名刺や役割表を見て誰に何を頼むか判断するのに近い仕組みです。エージェントが増えても、互いの能力を宣言し合う共通のやり方があれば、協調の設計が破綻しにくくなります。

この3つを並べると、function calling は「AIが道具を使うための基礎」、MCP は「その接続を標準化する規格」、A2A は「エージェント同士をつなぐ規格」と役割がきれいに分かれます。次の章では、これらをどう使い分けるのかを一覧で比較します。

主要な連携方式を比較する

連携方式は用途で選び、単発実行はfunction calling、標準接続はMCP、協調はA2Aが担います。

さらに、Salesforce・HubSpotといったCRMやSlackのような業務システムと実データをやりとりする場面では、各サービスのAPIやコネクタ、製品側の実装が窓口になります。どれか1つが正解というより、「何と何を、どの粒度でつなぎたいか」によって適した方式が変わります。概念が近いために混同されがちな4つの方式を、つなぐ対象・代表的な用途・標準や提供元・境界という観点で並べると、違いがはっきりします。

表の各方式の一次情報は、MCPがAnthropicの公式発表とMCP公式ドキュメント、A2AがGoogle Developers Blogの発表記事とLinux Foundationへの寄贈記事、function callingがOpenAIの公式ガイドにそれぞれ基づいています（いずれも前章でリンク済みです）。ここで押さえておきたいのは、各方式の「境界」です。function calling では、モデルはツールの呼び出しを返すだけで、実際の実行や何段もの処理の継続はアプリケーション側が制御する必要があります。MCP は接続の規格を整えますが、どのデータに誰がアクセスできるかという権限の設計は接続する側の前提になります。A2A はエージェント同士をつなぐ規格であって、ツールそのものへの接続を肩代わりするわけではありません。CRM・Slack連携は実データを扱う分だけ、提供範囲や参照できる範囲の確認が欠かせません。

用途ごとに当てはめると、違いはさらに具体的になります。たとえば「AIに社内の価格表を見せて見積もりの草案を作らせたい」なら、1つの道具を呼ぶ単発の作業なので function calling の発想が土台になります。「複数のデータソースやツールに、同じ流儀で安定してつなぎたい」なら、接続を標準化する MCP が向きます。「調査担当のエージェントと資料作成担当のエージェントを連携させ、片方の成果をもう片方に渡したい」なら A2A の領域です。そして「Salesforceの案件データやSlackのやりとりを実際に読み書きしたい」なら、各サービスのAPIやコネクタ、それを束ねる製品の実装が窓口になります。

もう1つ押さえておきたいのは、MCPのような標準を使う利点が「作り込みの重複を減らせる」点にあることです。標準がない世界では、つなぎたいツールの数だけ個別の接続を作り込む必要があり、ツールが増えるほど保守の負担が膨らみます。共通の規格に乗せておけば、同じ流儀で多様な接続先に対応でき、1つ作った接続の考え方を次にも使い回せます。逆に A2A は、ツールへの接続そのものは引き受けません。あくまでエージェント間の連絡係であり、各エージェントが道具を使う部分は function calling や MCP が支える、という分業になります。

実務では、これらを排他的に選ぶというより組み合わせて使います。たとえば「AIが社内データを参照して下書きを作り、CRMの案件情報も見に行く」運用なら、MCPで標準的に外部システムへつなぎつつ、CRM側はコネクタで接続する、といった具合です。CRMとの連携やSalesforce・Notionといった既存ツールの使い分けに関心がある場合は、SalesforceとNotionの使い分けを整理した記事もあわせて参考にしてください。方式そのものより「自分たちの何をつなぎたいか」から逆算すると、必要な方式が自然に絞り込めます。どの方式も「便利な道具箱」ですが、箱の中身を全部使う必要はなく、目的に必要なものだけを選べば十分です。

案件ワークスペースとAIエージェントを連携させると何が変わるか

案件ワークスペースにAIを連携すると、散らばる資料ややりとりを横断し根拠つきで答え、準備まで代行できます。

受託開発・制作・コンサルといったクライアントワークの現場では、1つの案件の情報が複数のツールに散らばりがちです。資料はクラウドストレージ、やりとりはメールやチャット、議事録は別のドキュメント、宿題は表計算、決まったことは誰かの記憶の中、という状態になりやすいのが実情です。この散らばりがあると、AIを連携させても「どこを見ればよいか」が定まらず、力を発揮できません。逆に言えば、案件の情報が1か所に集まっているほど、連携したAIの効果は大きくなります。

ここで効いてくるのが、案件ごとに顧客とワンチームで使う共有スペースという考え方です。Terasuでは、案件ごとに顧客を招いて使う共有スペースを「Room」と呼びます。Roomは、資料・やりとり・議事録・宿題・決まったことを1か所に揃えるための場所で、ツールを行き来していた仕事をRoom1つで完結させることを狙っています。これまで資料はクラウドストレージやメール添付、やりとりはメールやチャット、議事録は別のドキュメント、宿題は表計算、というように道具ごとに分かれていた置き場所を、案件単位の1つのスペースに集約するイメージです。情報が1つのRoomに集まっていれば、そこにAIエージェントを連携させたとき、AIは案件の文脈をまたいで調べ、根拠を示しながら答え、依頼された準備まで肩代わりできます。「聞けば根拠つきで答え、頼めばAIが準備する」という運用が、散らばりの解消と同時に成立するわけです。

クライアントワークにありがちな困りごとに引きつけると、効果はさらに具体的になります。「あの資料どこだっけ」という探し物は、案件の情報が1か所に集まっていれば、AIに聞くだけで根拠となる記録ごと示してもらえます。「言った言わない」で揉めがちな決定事項も、やりとりと決定の記録が同じ場所に残っていれば、AIが経緯をたどって答えられます。催促や抜け漏れも、宿題と期限が同じスペースにあれば、状況を横断して拾い出せます。連携したAIの価値は、派手な新機能というより、こうした日々の摩擦を静かに減らすところに現れます。

具体的には、Terasuは AIエージェント連携（MCP）、エージェントをプログラムを書かずに設計・運用する Agent Studio、CRM連携（Salesforce・HubSpot）、Slack連携を製品として備えています。ここでのMCPは、Claude.ai や Claude Code といった外部のAIツールからTerasuのRoomの情報へつなぐための入口で、ワークスペース管理者が発行するトークンとスコープ（アクセス権限）で、外部のAIに何を許すかを決めます（MCP接続のヘルプ）。一方、CRMとSlackとは専用の連携で実データを橋渡しし、Slackでは @Terasu とメンションすると、チャンネルに紐付けたRoomのAI Agentが出典つきで答え、「タスクを作って」のような依頼は承認カードとして届きます（Slackからの使い方）。これらを組み合わせると、たとえば「Roomに蓄積した会話と資料をもとに次回打ち合わせの論点をAIがまとめる」「CRMの案件状況と突き合わせて準備物を洗い出す」「Slackのやりとりと同期して抜け漏れを拾う」といった運用が、ばらばらのツールをまたがずに回せます。前章の地図に当てはめれば、外部AIとの接続口は MCP、業務システムとの実データは専用の連携が担い、それらを1つの案件スペースの文脈に束ねる、という役割分担です。利用者から見れば個々の方式を意識する必要はなく、「案件のスペースで聞けば、必要な情報を横断して答えてくれる」という体験として現れます。

1日の流れに置き換えると、連携の効き方はよりはっきりします。朝、担当者が案件のスペースで「前回の打ち合わせ以降に決まったことと、未対応の宿題を教えて」と聞けば、AIは会話・議事録・タスクを横断して、根拠となる記録とともに答えます。顧客への返信が必要なら、AIが過去のやりとりを踏まえた下書きを用意し、担当者は中身を確かめて承認してから送ります。CRMに案件の進捗を反映する必要があれば、Slackでの合意内容と突き合わせて更新候補を示す、といった具合に、ツールをまたぐ手作業が一本につながります。派手さはありませんが、こうした積み重ねが毎日の時間を取り戻します。

Terasuを開発・運営するkoromoも、自分たちの受託案件をTerasuのRoomで顧客と進めています。概念としての「連携」は、催促・探し物・検収前の「言った言わない」といった、案件現場の日々の困りごとに向けて使うものです。大がかりな仕組みを構えなくても、進行中の案件を1つスペースに乗せ、そこにAIを連携させるだけで、調べ物と下書きの負担は着実に軽くなります。

AIが答えるときに「根拠が付く」ことは、顧客と共有する現場では特に重要です。回答の裏付けとなった資料や会話へ戻れるようになっていれば、AIの出力をそのまま鵜呑みにするのではなく、人が確かめてから使えます。顧客に関わる判断ほど、この「根拠へ戻れる」性質が信頼の土台になります。連携したAIを案件現場で安心して使うには、速さや便利さだけでなく、出力の根拠をたどれるかどうかを見ておく価値があります。

案件管理そのものの観点から他のツールと比べたい場合は、案件管理ツールの比較記事で機能面の違いを整理しています。AIエージェント連携は「案件情報を1か所に集める」運用と組み合わせて初めて力を発揮するため、連携の前提として案件管理のかたちを見直すのは理にかなっています。既存の課題管理ツールや開発タスク管理をすでに使っている場合でも、それらを置き換える必要はなく、顧客と共有する資料・決定・依頼・AIの部分を案件スペースが受け持つ、という併用の形が現実的です。

AIエージェント連携の始め方

始め方の基本は小さく始めることで、つなぐ目的を1つに絞り、対象を限定し、接続と承認を整えて1案件で試すのが近道です。

いきなり全社・全案件に広げようとすると、設定も合意形成も重くなり、動き出す前に止まってしまいがちです。最初は進行中の案件を1件選び、そのRoomの中だけで小さく始めるのが現実的です。前章の構成図（Roomを中心に、外部AIツールとのMCP接続、CRM・Slack連携、承認を経た顧客への送信）を思い浮かべながら、次の順番で進めると迷いません。大きな運用変更を伴わないので、進行中の案件の資料・議事録・質問を1つのスペースに置くところから、その日のうちに着手できます。

ステップ1 つなぐ目的を1つに決める

まず「AIに何をさせたいか」を1つだけ決めます。「議事録から次のアクション案を作る」「顧客に送る資料の下書きを用意する」など、効果が分かりやすく、失敗しても影響が小さい作業が向いています。目的が多すぎると評価もしにくいため、最初は欲張らないのが成功の鍵です。良い目的の見分け方は、「毎週のように発生し、手間はかかるが判断は定型的」な作業かどうかです。頻度が高ければ効果を実感しやすく、判断が定型的なら最初から精度も出しやすくなります。逆に、年に数回しか起きない特殊な作業や、高度な判断を伴う業務は、連携に慣れてから広げる方が無理がありません。

ステップ2 対象データとツールを1案件に絞る

次に、AIが参照するデータと使うツールを1つの案件のRoomに限定します。対象が広いほど権限や参照範囲の設計が複雑になるため、まずは1案件分の資料・会話・タスクに閉じて始めます。ここで「どの情報を見せ、何はまだ見せないか」の線引きをしておくと、後の拡張がスムーズです。1案件に閉じることには、安全面だけでなく評価面の利点もあります。対象が狭ければ、AIの回答がその案件の文脈にどれだけ合っているかを人が確かめやすく、改善のループを素早く回せます。全体に広げるのは、この1案件で「使える」と判断できてからで十分です。

ステップ3 接続する方式を選ぶ

目的と対象が決まったら、つなぎ方を選びます。ClaudeなどのAIツールから案件データを標準的な方法で参照させたいなら MCP、CRMやSlackのような業務システムとの実データ連携なら各サービスのコネクタ、というのが基本の考え方です。function calling は多くのツール連携の土台として内側で働きます。Terasuのように MCP連携やCRM連携、Slack連携を製品機能として備える環境を使えば、方式ごとの作り込みを自分で抱え込まずに始められます。ここで迷いやすいのが「自前で組むか、用意された連携機能を使うか」の選択です。開発リソースがあり、独自のツールや社内システムに深くつなぎたいなら自前の実装にも意味がありますが、多くの現場では、まず製品が標準で用意する連携の範囲で目的を満たせないかを確かめる方が、立ち上がりが速く保守も軽くなります。凝った構成は、標準の範囲で物足りなさを感じてから検討すれば十分です。

Terasuで外部のAIツール（Claude.ai・Claude Code・Coworkなど）からMCPで接続する場合の設定は、次の流れです（MCP接続のヘルプ）。操作できるのはワークスペース管理者だけです。

1. サイドバー上部のワークスペース名をクリックしてメニューを開き、「設定」を選ぶ
2. 左の設定メニュー「連携」から「MCP接続」を選ぶ
3. 「MCPトークンを作成」をクリックし、トークン名を入力する
4. スコープ（アクセス権限）を1つ以上選び、「トークンを作成」をクリックする
5. 表示された Bearer トークンをコピーする（全文は作成時だけ表示され、あとから再表示できません）
6. 同じ画面の「接続ガイド」で「接続の設定をコピー」を押し、設定例のJSONを接続したいAIツール側に貼り付ける

スコープは、ルーム・ページ・タスク・メッセージ・ファイル・ステークホルダー・AIエージェントなどの対象ごとに「閲覧」と「編集・管理」が分かれています。最初は「ルーム閲覧」「ページ閲覧」「タスク閲覧」「メッセージ閲覧」のような読み取りだけで始め、議事録の要約や次のアクション案の作成で手応えを確かめるのが安全です。「メッセージ管理」は送信・編集・削除まで、「ルーム削除」は取り消しできない削除まで、「エージェント操作」はアクションの承認・却下まで外部のAIに任せることになるため、人が判断を持ちたい間は付けないでおきます。アクティブなトークンは20件までで、失効や削除は取り消せません。

ステップ4 権限と承認フローを設定する

接続ができたら、誰が何を参照・実行できるかという権限と、AIの出力をどう扱うかという承認フローを整えます。特に顧客と共有する案件では、AIが用意した顧客向けのメッセージや依頼を、人の確認を経てから送る運用にしておくことが重要です。承認を挟むことで、AIの下書きを活かしつつ、送信の最終判断は人が持つ形を保てます。権限設計では、「読めるだけ」「下書きまで作れる」「承認を経て実行できる」といった段階を分けて考えると整理しやすくなります。最初は読み取りと下書き作成に絞り、実行や送信は人の承認を必須にしておくと、慣れないうちの思わぬ動作を防げます。運用に自信がついてから、承認なしで任せる範囲を少しずつ広げていくのが安全です。

ステップ5 1案件で試し、手応えを見てから広げる

最後に、設定した1案件で実際に使ってみます。AIの回答に根拠がきちんと付いているか、準備物の精度は実用に足るかを確かめ、手応えがあれば次の案件へ、必要なら目的を1つ足す、という順で少しずつ広げます。小さく始めて確かめながら広げることで、現場に無理なく定着させられます。試す段階では、AIの出力を一度で完璧にしようとせず、「人が少し直せば使える」水準に達しているかを基準にすると判断がぶれません。下書きの8割をAIが用意し、最後の仕上げと判断を人が担うだけでも、1案件あたりの手間は目に見えて減ります。この手応えが次の案件へ広げる根拠になり、連携が現場の標準的な進め方へと定着していきます。

なお、MCP連携・CRM連携・Slack連携などの機能は提供されるプランが分かれています。連携が使えるプランは料金プランのページで確認できます。どの機能をどのプラン帯から使えるかを先に押さえておくと、始め方の計画が立てやすくなります。

導入前に確認したい注意点

導入前に、データの参照範囲・承認フロー・学習利用の有無・プラン別の提供範囲を確認します。

AIを外部のデータやツールにつなぐということは、裏を返せば「AIがどこまで見て、何を実行できるか」を設計する作業でもあります。特に顧客のデータを預かって共有する案件現場では、便利さと同じだけ、参照範囲やガバナンスの確認が欠かせません。顧客から預かった情報の扱いは、自社の都合だけでは決められない領域であり、「どこまでAIに見せてよいか」は契約や顧客との合意にも関わります。だからこそ、連携を広げる前に確認の観点を言語化しておくことが、後々のトラブルを避ける近道になります。以下の4点を押さえておくと、安心して連携を始められます。

• データの参照範囲：AIがどこまでの情報を見るのかを確認します。Terasuでは、Roomで聞いたときはそのRoomに置かれたページ・資料・会話・タスクをもとに答え、外部Webの参照は既定でオフになっています。管理者が設定でオンにしたときだけ外部Webを使う仕組みのため、まずは「Room内に閉じた参照」から始められます。一方、外部のAIツールからMCPで接続する場合は、現時点のトークン作成画面ではアクセスできるRoomが「すべてのルーム」になるため、スコープ（アクセス権限）を必要なものに絞り、使わなくなったトークンは失効させる運用にしておきます。
• 承認フロー：AIが顧客に向けて送るメッセージや依頼は、必ず人の承認を経てから送られる設計かを確認します。AIの下書きをそのまま自動送信するのではなく、承認を挟むことで、言い回しや送信タイミングの最終判断を人が持てます。
• 学習利用の有無：預けたデータがAIモデルの学習に使われないかを確認します。Terasuでは、顧客のコンテンツを自社または第三者のAIモデルの学習（トレーニング）に利用することはなく、外部のAI事業者との契約でも学習利用を許諾していません。案件データの機微を扱う現場では、この点を最初に確かめておくと安心です。
• プラン別の提供範囲：連携機能は提供されるプランが分かれています。必要な連携が、検討しているプラン帯で使えるかを事前に確認します。金額ではなく「どの機能が、どのプランから使えるか」という提供範囲で見ておくと、導入後の想定外を避けられます。

組織の規模が大きくなるほど、「誰がいつ何をしたか」をたどれることも重要になります。Terasuでは、シングルサインオンや監査ログといった運用管理の仕組みはEnterpriseで提供されます。少人数のチームで小さく始める段階ではそこまで必要ないことも多いですが、全社的に連携を広げる局面では、操作の記録を残せるかどうかが運用の安心につながります。自社がいまどの段階にあるかを踏まえ、必要な管理機能が揃うプラン帯かを見ておくとよいでしょう。

これらは「セキュリティは大事」という一般論ではなく、Roomごとにアクセス範囲を管理し、承認後に送信し、学習には使わない、という具体の運用に落ちている点が実務では効いてきます。連携を広げる前に、この4点を案件の性質に照らしてご確認ください。

もう1つ、見落とされがちな観点として「どこまで自動化し、どこは人が握るか」の線引きがあります。連携が進むと、AIに任せられる範囲はどんどん広がりますが、顧客との関係に直接影響する判断（提案の方向性、トラブル時の初動、価格に関わる約束など）は、人が最終責任を持つ前提で設計する方が健全です。AIは下準備と根拠の提示に徹し、顧客に向き合う判断は人が担う——この役割分担を最初に決めておくと、連携を広げても現場の納得感を保てます。便利さを追うほど、どこで人が関わるかを意識的に残すことが、長く使える連携の条件になります。

状況別の読み分け早見表

ご自身の状況によって、次に読むべきものや取るべき行動は変わります。以下の早見表から、当てはまる状況の行を手がかりにしてください。

判断に使えるチェックリスト

自社が連携を始めてよい状態かは、目的・対象・接続先・権限・参照範囲・プランの観点で自己点検できます。以下のチェックリストで、整っている項目と未確定の項目を切り分けてください。

• つなぐ目的を案件業務で1つに絞れている（例：議事録から次アクション草案を作る）
• 最初に連携する対象データ・ツールを1案件のRoomに限定できている
• CRM（Salesforce/HubSpot）やSlackのどれを最初につなぐか決まっている
• 誰が何を参照・実行できるか（権限）と承認フローを設計済み
• データ参照範囲が既定でRoom内に閉じ、外部Web参照の要否を判断済み
• 必要な連携機能が使えるプラン帯かを確認済み（金額ではなく提供範囲で判断）

6項目にひととおりチェックが付く方は、具体的な導入の検討段階に入っていると考えてよいでしょう。チェックが付かない項目が多い段階では、本記事の前半と関連記事で目的や対象を固めるところから始めると、無駄なく進められます。

これらの観点を踏まえ、すでに進行中の案件があり、CRMやSlackを案件現場につなぎたい情シス・営業企画の方は、導入相談で自社の案件に即した進め方を詰めるのが近道です。一方で、いまはまず連携の概念を押さえたい段階という方は、本記事前半と関連記事で理解を深めるだけでも十分に役立ちます。

よくある質問

AIエージェント連携は、用語の数ほど難しいものではありません。「AIを何につなぎ、何をさせたいか」を1つ決め、対象を絞って小さく試す——この順番さえ守れば、概念は実際の案件業務にそのまま接続できます。function calling・MCP・A2Aという技術の違いも、「ツールをつなぐ話か、エージェントをつなぐ話か」という2層の地図に当てはめれば迷いません。そのうえで、案件の情報が1か所に集まっている状態を整え、参照範囲と承認フローを設計しておけば、連携したAIは安心して任せられる実務の担い手になります。本記事の基礎・比較・適用・手順・注意点を手がかりに、自社の現場で最初の一歩を踏み出してみてください。基礎技術の事実はAnthropic・Google・OpenAIの各公式情報に基づいています。