株式会社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ブラウザ | Auth0 JWT | ユーザーがログインしてJWTを取得 |
| Slack Bot | APIキー + セッションID | ブラウザログイン不可、Slack user IDからユーザー特定 |
| CLI（ローカル） | Device Flow → JWT | ブラウザでAuth0認証→CLIにトークン渡し |
| バッチ・cron | APIキーのみ or サービストークン | ユーザー不在、サービスアカウントで実行 |
これらすべてに対応しつつ、「誰が何をしたか」を追跡できる統一的な認証基盤が必要です。
課題2：二重認証の排除
AIエージェントの起動時点でユーザー認証が完了しているにもかかわらず、エージェントがAPIを呼ぶたびに再度JWTを要求する「二重認証」は、設計上の負債です。リフレッシュトークンの失効でシステム全体が止まるリスクがあります。
課題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つに整理します。
| 関数 | 用途 | 返却値 |
|---|---|---|
| get_current_employee | ユーザー特定が必要なAPI | (Employee, Auth) — JWT/APIKey+SessionID両対応 |
| require_manager | 管理者限定API | (Employee, Auth) — 上記に権限チェックを追加 |
| get_service_or_employee | バッチ処理も許可するAPI | (Employee, Auth) or {"auth": "service"} |
設計パターン2：Slack経由AIエージェントの認証フロー
ブラウザログインができないSlack経由のAIエージェントでは、以下のフローで認証を実現します。
セッション作成（サーバー側）
- ユーザーがSlackでBotにメンションする
- バックエンドがSlack EventのユーザーIDを取得
- Slack APIでメールアドレスを取得し、従業員テーブルと照合
- セッションIDを生成し、ユーザーIDと紐づけてDBに保存
AIエージェントの実行
- バックエンドがAIエージェント（VM上のClaude Code等）を起動
- 環境変数にAPIキーとセッションIDをセット
- AIエージェントがCLI/MCPでAPIを呼ぶ際、X-API-KeyとX-Session-Idヘッダーを付与
- バックエンドがセッションIDからユーザーを解決し、通常のJWTログインと同じ権限チェックを実行
この設計のポイントは、「入口の認証方法は異なるが、エージェント起動後は一本化される」点です。Webブラウザ経路でもSlack経路でも、APIの認可ロジック（権限チェック）は完全に共通です。
設計パターン3：バッチジョブの認証方式選定
定期実行ジョブ（Celery Beat、Container Apps Jobs、Cloud Run Jobs等）の認証方式は、以下の比較表で選定します。
| 方式 | 正しさ | 導入コスト | 適するケース |
|---|---|---|---|
| Client Credentials（M2M） | 最も正しい | 高 | scope制御が必要、Auth0を既に利用 |
| 自前JWT（サービストークン） | 良い | 中 | Auth0依存を避けたい、コンテナ起動・終了が頻繁 |
| APIキー + セッションID流用 | 妥協 | 低 | 既存のAI Terminal認証基盤に乗せたい場合 |
| APIキーのみ（現状維持） | 不可 | なし | 推奨しない（service bypassが残る） |
自前JWTが適するケースの具体的な理由
- バッチがコンテナ起動・終了する構成では、M2Mだとトークン保存の仕組み（Redis/DB）が必要
- 自前JWTなら環境変数にセットするだけで保存の仕組みが不要
- M2M枠（デフォルト月1,000トークン）は全ジョブをAPI経由にすると超過しコスト発生
- 自前JWTならトークン枠の制約がない
設計パターン4：Service Bypassの段階的解消
As-Is：よくある危険な状態
多くのシステムでは、開発初期に「ユーザー特定が必要なAPIにも、バッチ用のAPIキーだけで通る経路」が作られます。これは以下の問題を引き起こします。
- curlでAPIキーだけを指定すれば、権限チェックなしで任意のAPIを呼べる
- 「誰が実行したか」の監査ログが取れない
- 本来管理者だけがアクセスすべきAPIに、一般ユーザーの権限で（あるいは権限チェックなしで）アクセスできる
To-Be：段階的な解消ステップ
Step 1：認証関数の統一
get_current_employeeにAPIキー+セッションID認証を追加し、ルーター変更なしで全エンドポイントをマルチチャネル対応にする。
Step 2：Service Bypass経路の限定
get_service_or_employee（APIキーのみでservice応答を返す関数）の使用を、本当にバッチ処理が必要な限定的なエンドポイントだけに絞る。
Step 3：バッチジョブのAPI経由化
直接DB操作をしているバッチジョブを段階的にAPI経由に移行し、認可ロジックとバリデーションをAPI層に一元化する。
セッション管理のセキュリティ強化
TTL（有効期限）の設定
セッションIDに有効期限を設けます。デフォルト12時間程度が適切です。これにより、セッションIDが漏洩した場合のリスクを時間的に限定できます。
終了済みセッションの拒否
AIエージェントの実行が完了したセッションは、statusを「terminated」に更新し、以降のAPI呼び出しを拒否します。
JWTの優先順序
認証関数内では、Bearer JWTをAPIキーより優先する判定順序に統一します。これにより、JWTが存在する場合は常にJWTベースの認証が使われ、APIキー経路はJWTが使えないチャネル（Slack/バッチ）に限定されます。
実装時のチェックリスト
| チェック項目 | 対策 |
|---|---|
| APIキーだけで権限チェックをスキップできる経路がないか | get_service_or_employeeの使用箇所を棚卸し |
| セッションIDに有効期限があるか | TTL超過チェックを認証関数に追加 |
| 終了済みセッションが再利用できないか | status=terminatedのセッションを拒否 |
| すべての認証経路でユーザー追跡ができるか | 監査ログにuser_id/auth_methodを記録 |
| JWTの検証でissuer/audience/expiryをチェックしているか | RS256/ES256署名、短寿命トークン |
| APIキーのローテーション手順が整備されているか | 定期更新スクリプト + 環境変数管理 |
まとめ：AIエージェント時代の認証認可は「マルチチャネル統一」がカギ
AIエージェントの認証認可設計で最も重要なのは、チャネルごとにバラバラの認証方式を使うのではなく、認証基盤の内部で吸収し、エンドポイント側のコードを一切変更せずにマルチチャネル対応を実現することです。
本記事で紹介した4つの設計パターン（統一認証関数・Slack経由フロー・バッチ認証選定・Service Bypass解消）を組み合わせれば、安全かつ拡張性の高いAIエージェント認証基盤を構築できます。
AIエージェントの認証設計・開発はRenueにご相談ください
Renueでは、Slack・Web・CLI・定期バッチの4チャネルからAIエージェントが安全にAPIを呼び出すマルチチャネル認証基盤を自社で設計・運用しています。JWT + APIキー + セッションID認証の統一、service bypassの段階的解消、セッションTTL管理まで、実運用で検証済みのアーキテクチャです。AIエージェントのセキュリティ設計でお悩みの方は、お気軽にご相談ください。