AIエージェントを業務システムにつなぐ前に決める、権限と自動実行の境界
木村 優志
「CRMを見て次のアクションを提案してほしい」「メールの下書きを作ってほしい」「社内文書を調べて回答してほしい」。生成AIの相談では、こうした要望が短期間で「AIエージェントに業務システムを操作させたい」へ進むことがあります。
技術的には、すでにその接続手段はそろいつつあります。OpenAIやAnthropic、GoogleのFunction Calling／Tool Use、LangGraphやLlamaIndexのようなエージェント実装、そして外部システムを共通のツールとして公開するModel Context Protocol（MCP）があります。Salesforce、HubSpot、kintone、Microsoft Graph、Slack、Google Driveなどに対する公式APIやMCPサーバーを使えば、LLMは検索し、下書きを作り、場合によってはレコードを更新できます。
しかし、接続できることと、自動実行してよいことは別です。業務システムへつなぐ前に決めるべきなのは、モデル名よりも、どの権限で、どの操作まで、誰の承認なしで実行させるかです。
本記事では、CRM更新、メール送信、社内検索を例に、権限と自動実行の境界をどう決めるかを整理します。あわせて、実装で使う具体的なツールも挙げます。
エージェントの実装は「モデル」ではなく「ツール呼び出し」が中心になる
業務向けエージェントは、次のような構成になることが一般的です。
利用者の指示
→ LLM（OpenAI / Claude / Gemini など）
→ ツール呼び出し（Function Calling / MCP / 独自API）
→ 業務システム（CRM、メール、チャット、文書保管）
→ 結果をLLMが要約・提示、または人が承認ここで使う主な部品は、次のとおりです。
- LLM API：OpenAI Responses / Chat Completions、Anthropic Messages、Google Gemini API
- エージェント実行基盤：LangGraph、LlamaIndex Workflows、自前のオーケストレータ
- ツール接続：各SaaSのREST API、またはMCPサーバー
- 認証：Microsoft Entra ID（旧Azure AD）、Google Workspace、Okta、各SaaSのOAuth
- 監査ログ：アプリケーションログ、クラウド監査ログ、SaaS側のアクティビティログ
モデルは回答文を作りますが、業務への影響を決めるのはツール側の権限です。search_contactsだけを渡したエージェントと、update_dealやsend_emailまで渡したエージェントでは、失敗したときの被害範囲がまったく違います。
最初に決めるのは「読める／下書きできる／実行できる」の3段階
業務操作は、少なくとも次の3段階に分けます。
| 段階 | エージェントができること | 例 |
|---|---|---|
| 参照のみ | データを読む、要約する、候補を出す | CRMの商談を検索し、状況を整理する |
| 下書き | 書き込み用の内容を作るが、保存は人が行う | メール本文、CRM更新案、タスク案を提示する |
| 自動実行 | 人がその場で承認しなくても書き込む／送信する | 商談ステージを更新する、メールを送る |
多くの導入では、最初から自動実行を目指す必要はありません。参照と下書きだけでも、探す時間と転記の手間は減らせます。自動実行は、評価セットで失敗パターンを確認し、影響の小さい操作から広げる方が安全です。
受託開発では、この段階を要件として明示します。「CRM連携」だけでは、参照なのか更新なのかが分からず、提案機能と見積もりが割れます。
例1：CRM更新 —— Salesforce / HubSpot / kintone
営業支援の相談では、次のような流れがよく出ます。
商談メモやメールを読む
→ 次回アクションとCRM更新案を作る
→ （人が確認）
→ CRMへ登録する実装で使うツールの例です。
- Salesforce：REST API、Bulk API、Apexを経由したカスタム処理。商談・取引先・活動の参照と更新
- HubSpot：CRM API（Contacts / Deals / Notes / Tasks）
- kintone：REST API（レコード取得・登録・更新）。日本企業の業務アプリ基盤として多い
- Microsoft Dynamics 365：Dataverse Web API
- 接続層：各社公式API、またはCRM向けMCPサーバー。社内ではLangGraphのToolとしてラップすることもある
ここで決めるべき境界は、次の点です。
- 商談の検索・要約は自動でよいか
- メモや活動履歴の追記は自動でよいか
- 金額、確度、ステージ変更は人の承認が必要か
- 担当者変更や取引先の新規作成は禁止するか
- エージェントが使うアカウントは個人の権限か、専用の連携アカウントか
実務では、次のような権限設計が現実的です。
許可：商談の参照、メモ下書きの作成
条件付き許可：メモの追記（特定フィールドのみ）
禁止：金額・契約条件・ステージの自動更新、レコード削除Salesforceでは、接続アプリのOAuthスコープに加え、プロファイル／権限セット、オブジェクト権限、項目レベルセキュリティ、レコード共有で「読めるオブジェクト」と「更新できる項目」を分けます。OAuthスコープだけで項目単位の更新範囲を制御できるわけではありません。HubSpotならPrivate Appのスコープ、kintoneならAPIトークンがアクセスできるアプリとフィールドを最小にします。
「CRMを更新できるエージェント」を作るのではなく、更新してよいフィールドだけを持つツールを渡します。LLMに広いupdate_recordを渡すと、意図しない項目まで書き換える余地が残ります。
例2：メール送信 —— Microsoft Graph / Gmail API / SendGrid
メールは、下書きと送信の差が特に大きい操作です。
実装で使うツールの例です。
- Microsoft 365：Microsoft Graph（
Mail.Read、Mail.ReadWrite、Mail.Send） - Google Workspace：Gmail API。
gmail.composeは下書き作成と送信の両方を許可するため、権限だけで「下書きのみ」に分けられない - トランザクションメール：SendGrid、Amazon SES（通知メール向け。顧客との個別商談メールとは用途が違う）
- 下書きの確認UI：自社Web画面、Slackへの承認依頼、Teams Adaptive Card
推奨する進め方は明確です。
- まずは下書き作成まで（Graphの下書き、Gmailの drafts）
- 送信先、件名、本文、添付を人が確認する
- 定型通知など影響の小さいものだけ、送信を自動化する
自動送信を許可する場合でも、次を固定します。
- 送信元アドレス（個人メールか共有メールか）
- 送信してよい宛先ドメイン
- BCCや社外アドレスを含む場合の追加承認
- 添付ファイルの種類とサイズ
- 送信前の禁止語・個人情報チェック
Microsoft Graphでは、下書きの作成・更新にMail.ReadWrite、送信にMail.Sendが必要です。したがって、送信を伴わない下書き段階ではMail.Sendを付与しない設計にできます。一方でGmailのgmail.composeは下書きと送信の両方を許可します。Gmailで下書き承認を実現するなら、APIスコープへの依存だけでは不十分で、エージェントに送信ツールを公開せず、承認済みの処理だけが送信APIを呼ぶようアプリケーション側で分離する必要があります。
誤送信の影響は検索ミスより大きいため、送信権限を付与する場合も、宛先・添付・送信条件をアプリケーション側で検証します。
例3：社内検索 —— SharePoint / Google Drive / Box / Slack
社内検索は「読むだけ」に見えますが、権限設計を誤ると機密情報の横断検索になります。
実装で使うツールの例です。
- Microsoft 365：SharePoint / OneDrive、Microsoft Graph Search、Azure AI Search
- Google Workspace：Google Drive API、Vertex AI Search
- Box：Box API、Box AI関連の検索・要約機能
- Notion / Confluence：公式API、または検索用インデックス
- チャット文脈：Slack API、Slack MCP server、Microsoft Teams
- RAG基盤：pgvector、OpenSearch、Azure AI Search、LlamaIndexのRetriever
ここで重要なのは、エージェント専用の強い検索権限を作らないことです。
- 利用者Aが見られない文書を、エージェント経由で読めてはいけない
- 部署をまたぐ規程と、特定顧客の契約書を同じ検索空間に置かない
- 古い版と現行版を区別できるメタデータを持たせる
Slack MCPやDrive連携を使う場合も、接続トークンが「組織の全データ」を見られる設計になっていないかを確認します。理想的には、ログイン中の利用者の権限を引き継いで検索するか、公開範囲が定義されたコーパスだけをRAGの対象にします。
社内検索エージェントで最初に許可しやすいのは、次の範囲です。
許可：公開社内Wiki、現行版の業務マニュアル、FAQ
保留：顧客契約、人事情報、未公開の経営資料
禁止：個人のメールボックス全体、権限外チャネルの横断検索権限は「人の権限」と「エージェントの権限」を分けて設計する
よくある失敗は、開発者や管理者の強いAPIキーでエージェントを動かすことです。これだと、現場の利用者より広いデータへアクセスできます。
分けるべき主体は次の3つです。
- 利用者：画面上で指示を出す人
- エージェント実行主体：ツールを呼ぶサービスアカウント、または利用者の委任トークン
- 管理者：接続アプリ、スコープ、監査ログを管理する人
認証まわりで使うものとしては、Microsoft Entra ID、Google WorkspaceのOAuth、Okta、各SaaSのPrivate App / Connected Appがあります。MCPを社内展開する場合は、組織のIdPで接続可否を管理するEnterprise-Managed Authorizationの考え方も重要です。ただし、MCPを使うだけで最小権限になるわけではなく、MCPサーバーが公開する各ツールと、背後のAPIトークンの権限を個別に設計します。
最低限、次をログに残します。
- 誰の指示か
- どのツールを呼んだか
- どのレコード／ファイル／チャネルにアクセスしたか
- 自動実行したか、人の承認後か
- 成功／失敗とエラー内容
障害や誤操作が起きたとき、「モデルが悪かった」だけでは原因を切れません。ツール呼び出しの監査がないと、再現も再発防止もできません。
自動実行してよい操作の決め方
自動実行の可否は、精度だけでは決まりません。次の問いで切り分けます。
- 間違えたときの影響は金銭・対外・安全に及ぶか
- 誤りを後から検知し、取り消せるか
- 同じ操作を人でも日常的に素早く確認できるか
- 例外が多い業務か、定型が多いか
- 評価セットで、その操作の失敗を観測できているか
目安は次のとおりです。
| 操作 | 初期の推奨 |
|---|---|
| 社内公開文書の検索・要約 | 自動実行しやすい |
| CRMの参照、商談メモの下書き | 自動実行しやすい |
| タスク作成、社内Slackへの下書き投稿 | 条件付きで検討 |
| CRMの金額・ステージ更新 | 人の承認を挟む |
| 社外向けメール送信 | 原則承認あり |
| レコード削除、権限変更、契約関連の更新 | 原則禁止 |
「AIが自信を持てないとき」のような曖昧な条件ではなく、検知できる条件で止めます。たとえば、必須項目の欠落、社外ドメインへの送信、金額フィールドの変更、検索結果の出典がない回答、評価対象外の文書タイプ、などです。
実装時にツールを渡す順番
エージェント開発では、最初から全部のAPIをつながない方がよいです。
1. 参照ツールだけを渡す
例：Salesforceの商談検索、SharePointの文書検索
2. 下書きツールを追加する
例：Gmail drafts、CRMメモ案、Slack下書き
3. 評価セットで失敗を分類する
例：誤った商談への紐づけ、古い規程の引用、宛先誤り
4. 影響の小さい書き込みだけを自動実行する
例：社内タスク作成、特定フィールドへのメモ追記
5. 対外送信や重要更新は承認フローを残す
例：Graphの送信、HubSpotのステージ更新LangGraphや自前オーケストレータを使う場合も、ノードとして「提案」「承認待ち」「実行」を分けます。MCPでSlackやDriveをつなぐ場合も、サーバー側で破壊的なツールを無効化できるかを確認します。
ZapierやMake、n8nのような自動化ツールと組み合わせることもできます。ただし、これらは「決まった条件で決まった処理を流す」のが得意です。LLMエージェントに広い権限を渡す前に、定型処理は従来の自動化へ寄せ、エージェントには判断と下書きを任せる分割も有効です。
発注側がベンダーへ最初に伝えるとよいこと
相談時に、次を共有できると設計が具体化します。
- 対象システム：Salesforce、HubSpot、kintone、Microsoft 365、Google Workspace、Slackなど
- やりたい操作：参照、下書き、更新、送信のどれか
- 自動実行してよい操作／承認が必要な操作／禁止する操作
- 利用者の権限を引き継ぐか、専用アカウントで動かすか
- 監査ログをどこに残すか
- 失敗時に業務へ戻す手順
逆に、「とりあえず全部つなげて、うまくいったら自動化したい」だけだと、受託側は強い権限のデモを作りやすくなります。デモは動いても、本番の権限設計としては危険です。
まとめ
AIエージェントを業務システムへつなぐときに先に決めるべきなのは、どのLLMを使うかではありません。どのツールを、どの権限で、どこまで自動実行させるかです。
- CRMなら、Salesforce / HubSpot / kintoneの参照と、更新してよい項目を分ける
- メールなら、Microsoft Graph / Gmail APIで下書きと送信を分ける
- 社内検索なら、SharePoint / Drive / Box / Slackで、利用者権限と公開範囲を守る
- 実装には Function Calling、MCP、LangGraph などを使えるが、渡すツールを最小にする
- 自動実行は、取り消せる定型操作から始め、対外送信や重要更新は承認を残す
エージェントの価値は、何でも自動で実行することではありません。人が判断すべき箇所を残しながら、調査と下書きの時間を減らすことです。権限と自動実行の境界を先に決め、その境界を評価セットで検証すると、技術選定と本番導入の議論が具体になります。
