チャネルトークをAIエージェントに安全に連携する｜権限・承認・監査の設計

チャネルトークをAIエージェントにつなぐと、問い合わせの要約、対応履歴の分析、ヘルプ記事の下書きといったCS業務を自動化できます。便利な一方で、顧客へのメッセージ送信や記事の公開は「外に出る操作」です。連携の前に権限設計を決めておくべきです。

チャネルトーク連携でまず起きる問題

チャネルトークをそのままAIエージェントに渡すと、典型的に次の問題が起きます。

APIキーの散在：プロンプトやローカルのMCP設定に置いた認証情報は、漏れたときにチャネルトークの操作が丸ごと露出します。
読み取りと書き込みが同じ扱い：参照も更新も、エージェントから見れば同じ「ツール呼び出し」です。区別がなければ、AIは同じ気軽さで実行します。
顧客に直接届く操作：メッセージ送信や記事公開は相手に届いてしまえば取り消せません。

読み取りは自由に、書き込みは承認制に

実務的な原則はシンプルです。参照系は自由に、更新系は人間の承認を経てから。チャネルトークの操作をこの2種類に仕分けます。

自由に実行してよい（読み取り）：会話・メッセージ・ユーザー情報の参照、マネージャー一覧、ヘルプ記事・トピックの確認。分析や下書きはここで完結します。
承認を挟む（書き込み）：顧客へのメッセージ送信、ヘルプ記事の作成・削除。特にメッセージ送信と記事公開は顧客に直接届きます。

こうしておけば、AIエージェントは分析や下書きまで一人で走り切り、外部や本番に効く操作の直前だけ担当者が確認する、という運用になります。

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

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

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

チャネルトークを扱う以上、「誰が・どのワーカーで・何をしたか」を後から追えることは必須です。承認された操作もブロックされた操作も、ワーカー・ロール・ツール・接続・リクエスト・結果まで記録しておけば、後からの調査や説明責任にそのまま使えます。

Grantryでの実現方法

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

よくある質問

AIエージェントにチャネルトークのAPIキーを直接渡しても大丈夫ですか？

推奨しません。プロンプトやローカルのMCP設定に置いたAPIキーは、チャネルトークでできる操作すべて（例：顧客へのメッセージ送信）を許す常時オファーになります。APIキーはサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す設計が安全です。

チャネルトークの顧客へのメッセージ送信をAIに自動実行させても問題ないですか？

顧客へのメッセージ送信は影響が大きい、または戻せない書き込みです。会話の参照などの読み取り・分析は自由に実行させ、顧客へのメッセージ送信は人間の承認を経てから実行する承認ゲートを挟むのが実務的です。

AIに一次対応の下書きだけさせ、送信は人が承認できますか？

できます。会話の参照・要約・返信ドラフト作成までをAIに任せ、実際の顧客へのメッセージ送信や記事公開は承認ゲートに載せます。誤送信や解禁前の公開を防ぎつつ、対応のスピードは上げられます。