Microsoft ClarityをAIエージェントに安全に連携する｜権限・承認・監査の設計

Microsoft ClarityをAIエージェントにつなぐと、ヒートマップやセッションのインサイトを要約し、UX改善の示唆を自動で引き出せます。Clarityは参照中心のツールですが、セッション記録には利用者の行動が含まれるため、参照範囲の限定と監査は依然として必要です。

Microsoft Clarity連携でまず起きる問題

Microsoft ClarityをそのままAIエージェントに渡すと、典型的に次の問題が起きます。

APIトークンの散在：プロンプトやローカルのMCP設定に置いた認証情報は、漏れたときにMicrosoft Clarityの操作が丸ごと露出します。
読み取りと書き込みが同じ扱い：参照も更新も、エージェントから見れば同じ「ツール呼び出し」です。区別がなければ、AIは同じ気軽さで実行します。
行動データの過剰な露出：セッションやインサイトには利用者の行動が含まれ、必要以上に広く参照させるべきではありません。

参照でも油断しない：範囲を絞って監査する

Clarityは読み取り中心ですが、だからといって全プロジェクトを無条件に開放してよいわけではありません。対象を絞り、アクセスを記録します。

自由に実行してよい（読み取り・分析）：ライブインサイトの取得、ヒートマップ・セッション傾向の分析、改善示唆の要約。分析はここで完結します。
範囲を絞る・承認を挟む：対象プロジェクトをロールで限定し、参照アクセスも監査ログに残す。書き込み系がなくても「誰が何を見たか」を追えるようにします。

こうしておけば、AIエージェントは分析や下書きまで一人で走り切り、必要なプロジェクトだけを参照させ、アクセスの記録を残す運用になります。

生のAPIトークンをエージェントに渡さない

もう一つの要点は認証情報の置き場所です。Microsoft ClarityのAPIトークンをエージェントのランタイムやプロンプトに置くのは避けます。認証情報はサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す。こうすれば、あるワーカーのトークンが漏れても、失効はそのワーカーの範囲に限定でき、Microsoft Clarity本体の認証情報を作り直す必要はありません。

すべての操作を監査ログに残す

行動データを扱う以上、「どのワーカーが・どのプロジェクトを・いつ参照したか」を後から追えることが重要です。承認された操作もブロックされた操作も、ワーカー・ロール・ツール・接続・リクエスト・結果まで記録しておけば、後からの調査や説明責任にそのまま使えます。

Grantryでの実現方法

Grantryは、AIエージェントと業務ツールの間に入る権限レイヤーです。 Microsoft Clarityを含むMCP対応のサービスに対して、ワーカーごとにスコープ付きトークンを1つ発行し、読み取りは自由に、インサイト参照などの書き込みは承認ゲート越しに、そして全コールを監査ログに残します。 Claude CodeやCodexなどのMCPクライアントを、ワーカートークン付きでGrantryのエンドポイントに向けるだけで、エージェント側のコード変更なしに始められます。

よくある質問

AIエージェントにMicrosoft ClarityのAPIトークンを直接渡しても大丈夫ですか？

推奨しません。読み取り中心のツールでも、トークンが漏れれば全プロジェクトのインサイトが露出します。トークンはサーバー側に保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡し、参照できるプロジェクトをロールで絞るのが安全です。

Clarityは読み取りだけなので権限管理は不要では？

参照だけでも、セッション記録には利用者の行動が含まれます。誰がどのプロジェクトを参照したかを監査ログに残し、対象範囲を限定することは、読み取り専用でも意味があります。

GA4やSearch Consoleと合わせてAIに分析させられますか？

できます。いずれもMCP対応で、同じ権限レイヤーの後ろに置けます。分析系はまとめてAIに任せつつ、プロパティやサイトごとにロールで参照範囲を分けられます。