株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
この記事でわかること
- AIエージェントがAPIを安全に呼び出すための認証認可の設計パターン
- JWT・APIキー・セッションIDの使い分けとマルチチャネル認証の統一方法
- バッチジョブやSlack連携など、ブラウザ外からのAI実行における認証のベストプラクティス
はじめに：AIエージェントが認証認可の常識を変える
従来のWebアプリケーションでは、「ブラウザでログインしたユーザーがAPIを呼ぶ」という単一の認証経路を想定すれば十分でした。しかしAIエージェントの登場により、状況は一変しています。
AIエージェントは、Webブラウザ、Slack、CLI、定期バッチなど、複数のチャネルからAPIを呼び出します。しかもエージェントは「人間の代理」として動作するため、「どのユーザーの権限で実行しているのか」を常に追跡できる設計が必要です。
本記事では、AIエージェントのための認証認可アーキテクチャを、実際のシステム設計パターンに基づいて解説します。
AIエージェント認証の3つの課題
課題1：マルチチャネル認証
AIエージェントは以下のような多様なチャネルからAPIを呼び出します。
| チャネル | 認証方式 | 特徴 |
|---|---|---|
| Webブラウザ | IdP発行のJWT | ユーザーがログインしてJWTを取得 |
| Slack Bot | APIキー + セッションID | ブラウザログイン不可、Slack user IDからユーザー特定 |
| CLI（ローカル） | Device Flow → JWT | ブラウザでIdP認証→CLIにトークン渡し |
| バッチ・cron | APIキーのみ or サービストークン | ユーザー不在、サービスアカウントで実行 |
これらすべてに対応しつつ、「誰が何をしたか」を追跡できる統一的な認証基盤が必要です。
課題2：二重認証の排除
AIエージェントの起動時点でユーザー認証が完了し、有効なアクセストークンがあるのに、APIを呼ぶたびユーザーへ再ログインを求める設計は見直しが必要です。一方、APIリクエストごとのトークン提示・検証は必要であり、「二重認証」ではありません。リフレッシュトークンが失効した場合に備え、再認証と処理再開の方法を設計します（RFC 6750：トークンの提示・検証）。
課題3：Service Bypassの防止
バッチジョブ用にAPIキーだけで認証を通す経路（service bypass）を作ると、本来ユーザー特定が必要なエンドポイントにもAPIキーだけでアクセスできてしまう脆弱性が生まれます。
設計パターン1：統一認証関数によるマルチチャネル対応
認証の2層構造
認証基盤は以下の2層で設計します。
層1：ミドルウェア（リクエスト検証）
すべてのAPIリクエストに対して、JWTまたはAPIキーのいずれかが有効であることを検証します。この層は「リクエストが正当か？」だけを判定します。
層2：エンドポイント依存関数（ユーザー解決）
ユーザーの特定が必要なAPIでのみ、以下のロジックでユーザーを解決します。
- Bearer JWTがあれば → JWTのclaimsからユーザーを特定（従来のWebブラウザ経路）
- APIキー + セッションIDがあれば → セッションIDからDBでユーザーを特定（Slack/CLI経路）
- APIキーのみ（セッションIDなし）→ ユーザー不明のため401エラー
この設計により、エンドポイント（ルーター）側のコードを一切変更せず、認証基盤だけの修正で全APIをマルチチャネル対応にできます。
認証関数の整理
エンドポイントから呼び出す認証関数は、以下の3つに整理します。
| 関数 | 用途 | 返却値 |
|---|---|---|
| ユーザー解決関数 | ユーザー特定が必要なAPI | (ユーザー, 認証情報) — JWT/APIKey+SessionID両対応 |
| 管理者判定関数 | 管理者限定API | (ユーザー, 認証情報) — 上記に権限チェックを追加 |
| サービス兼用解決関数 | バッチ処理も許可するAPI | (ユーザー, 認証情報) or サービス認証情報 |
設計パターン2：Slack経由AIエージェントの認証フロー
ブラウザログインができないSlack経由のAIエージェントでは、以下のフローで認証を実現します。
セッション作成（サーバー側）
- ユーザーがSlackでBotにメンションする
- バックエンドがSlack EventのユーザーIDを取得
- ユーザーIDが登録済みかを確認する
- セッションIDを生成し、ユーザーIDと紐づけてDBに保存
AIエージェントの実行
- バックエンドがAIエージェント（VM上のClaude Code等）を起動
- エージェントにセッションIDを渡す
- AIエージェントがCLI/MCPでAPIを呼ぶ際、APIキーとセッションIDをリクエストヘッダーで付与
- バックエンドがセッションIDからユーザーを解決し、通常のJWTログインと同じ権限チェックを実行
この設計のポイントは、「入口の認証方法は異なるが、エージェント起動後は一本化される」点です。Webブラウザ経路でもSlack経路でも、APIの認可ロジック（権限チェック）は完全に共通です。
設計パターン3：バッチジョブの認証方式選定
定期実行ジョブ（Celery Beat、Container Apps Jobs、Cloud Run Jobs等）の認証方式は、以下の比較表で選定します。
| 方式 | 正しさ | 導入コスト | 適するケース |
|---|---|---|---|
| Client Credentials（M2M） | 最も正しい | 高 | scope制御が必要、外部IdPを既に利用 |
| 自前JWT（サービストークン） | 良い | 中 | 外部IdP依存を避けたい、コンテナ起動・終了が頻繁 |
| APIキー + セッションID流用 | 妥協 | 低 | 既存の認証基盤に乗せたい場合 |
| APIキーのみ | 不可 | なし | 推奨しない（認証を迂回する経路が残る） |
自前JWTが適するケースの具体的な理由
- バッチがコンテナ起動・終了する構成でも、M2MにRedis/DBは必須ではない。有効なトークンはメモリ内で再利用でき、起動をまたいだ共有・再利用が必要な場合にRedis/DB等を選択する（Auth0公式資料）
- 自前JWTを環境変数で渡す構成でも、署名鍵の安全な保管、有効期限、失効・更新方法の管理が必要（トークン管理の公式解説）
- M2Mの発行枠・追加料金はIdPと契約プランによって異なる。Auth0ではAPI呼び出し数そのものではなくトークン発行要求が枠を消費するため、有効期限内の再利用と契約条件を確認する（発行枠の説明、料金・プラン）
- 自前JWTには外部IdPの発行枠は適用されないが、発行・検証基盤の容量と鍵・有効期限の運用管理は必要
設計パターン4：Service Bypassを残さない是正の進め方
よくある危険な状態（一般的な例）
多くのシステムでは、開発初期に「ユーザー特定が必要なAPIにも、バッチ用のAPIキーだけで通る経路」が作られます。これは以下の問題を引き起こします。
- APIキーだけではユーザー個別の権限を判定できない
- 「誰が実行したか」の監査ログが取れない
- 本来管理者だけがアクセスすべきAPIに、一般ユーザーの権限で（あるいは権限チェックなしで）アクセスできる
To-Be：段階的な解消ステップ
Step 1：認証関数の統一
ユーザー特定用の認証関数にAPIキーとセッションIDによる認証を追加し、ルーター変更なしで全エンドポイントをマルチチャネル対応にする。
Step 2：Service Bypass経路の限定
サービス・ユーザー兼用の認証関数（APIキーのみでservice応答を返す関数）の使用を、本当にバッチ処理が必要な限定的なエンドポイントだけに絞る。
Step 3：バッチジョブのAPI経由化
直接DB操作をしているバッチジョブを段階的にAPI経由に移行し、認可ロジックとバリデーションをAPI層に一元化する。
セッション管理のセキュリティ強化
TTL（有効期限）の設定
セッションIDに有効期限を設けます。数時間〜1日程度の範囲で業務に合わせて設定します。これにより、セッションIDが漏洩した場合のリスクを時間的に限定できます。
終了済みセッションの拒否
AIエージェントの実行が完了したセッションは、セッションを終了状態に更新し、以降のAPI呼び出しを拒否します。
JWTの優先順序
認証関数内では、Bearer JWTをAPIキーより優先する判定順序に統一します。これにより、JWTが存在する場合は常にJWTベースの認証が使われ、APIキー経路はJWTが使えないチャネル（Slack/バッチ）に限定されます。
実装時のチェックリスト
| チェック項目 | 対策 |
|---|---|
| APIキーだけで権限チェックをスキップできる経路がないか | サービス・ユーザー兼用の認証関数の使用箇所を棚卸し |
| セッションIDに有効期限があるか | TTL超過チェックを認証関数に追加 |
| 終了済みセッションが再利用できないか | 終了状態のセッションを拒否 |
| すべての認証経路でユーザー追跡ができるか | 監査ログに実行者と認証方式を記録 |
| JWTの検証でissuer/audience/expiryをチェックしているか | RS256/ES256署名、短寿命トークン |
| APIキーのローテーション手順が整備されているか | 定期更新スクリプト + 環境変数管理 |
まとめ：AIエージェント時代の認証認可は「マルチチャネル統一」がカギ
AIエージェントの認証認可設計で最も重要なのは、チャネルごとにバラバラの認証方式を使うのではなく、認証基盤の内部で吸収し、エンドポイント側のコードを一切変更せずにマルチチャネル対応を実現することです。
本記事で紹介した4つの設計パターン（統一認証関数・Slack経由フロー・バッチ認証選定・Service Bypass解消）を組み合わせれば、安全かつ拡張性の高いAIエージェント認証基盤を構築できます。
AIエージェントの認証設計・開発はrenueにご相談ください
renueでは、複数チャネルからAIエージェントが安全にAPIを呼び出すための認証基盤を自社で設計・運用しています。本記事の設計パターンは、その運用経験をもとに一般化したものです。AIエージェントのセキュリティ設計でお悩みの方は、お気軽にご相談ください。
