AIエージェントを導入する前に、「誰が、何を実行できるか」を決める。

AIエージェントに社内のツールをつなぐとき、最初に整理したいのは操作の範囲です。「社内システムに接続できる」という条件だけでは、閲覧から削除まで、どこまで任せるのかが決まりません。

この記事では、ツール連携を設計するときに使える三つの確認点を提案します。特定の製品を利用した検証結果ではなく、権限設計のための考え方です。

読む操作と、変える操作を分ける

議事録を探す操作と、参加者全員にメールを送る操作では、失敗した場合の影響が違います。ひとつの「利用許可」でまとめず、実行可能な操作を一覧にすると、設計上の抜けが見つかります。

操作の例	最初に決めておくこと
文書を検索する	検索対象のフォルダと閲覧権限
下書きを作る	保存先と、上書きしてよい範囲
外部へ送信する	宛先の確認と、実行前に必要な承認
データを削除する	対象の特定と、復元できる条件

この表は運用ルールの出発点です。すべての操作に同じ手間をかける必要はありませんが、影響の大きさに応じた条件は必要です。

認証の成功を、万能の許可にしない

MCPの認可仕様は、HTTPベースの接続で保護されたリソースにアクセスするための枠組みを定義しています。仕様への対応は接続の土台になりますが、自社のどのデータを誰に操作させるかという判断は別に必要です。MCPの認可仕様

実装時には「利用者」「接続するツール」「アクセス先のデータ」を分けて考えます。ある利用者のために取得した権限が、別の利用者の処理へ持ち越されないかも確認点です。

結果から、実行の経緯をたどれるようにする

便利なデモが動いた後に考えたいのは、意図しない結果が出たときの調査です。どの依頼から、どのツールが、どの対象へ、どの操作を行ったのか。必要な記録を先に決めておけば、原因調査の入口を作れます。

ただし、記録に認証情報や本文を無条件に残すと、別の管理対象が増えます。操作の識別子と結果を中心に、保存期間と閲覧者を決めるところまでを設計に含めます。

最初の検証で確かめたいこと

• 許可していないデータにアクセスしたとき、実行が止まるか。
• 同じ依頼を再実行しても、送信や登録が二重にならないか。
• 途中で権限を取り消したとき、次の操作に反映されるか。
• 操作に失敗した場合、利用者が結果を判断できるか。

機能の数を増やす前に、ひとつの操作についてこの四点を確かめる。小さくても、運用の条件まで含んだ検証になります。