株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
この記事でわかること
- 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側の権限を対応付ける |
| CLI（ローカル） | Device Flow → JWT | ブラウザでIdP認証→CLIにトークン渡し |
| バッチ・cron | APIキーのみ or サービストークン | ユーザー不在、サービスアカウントで実行 |
これらすべてに対応しつつ、「誰が何をしたか」を追跡できる統一的な認証基盤が必要です。
課題2：二重認証の排除
AIエージェントの起動時点でユーザー認証が完了し、有効なアクセストークンがあるのに、APIを呼ぶたびユーザーへ再ログインを求める設計は見直しが必要です。一方、APIリクエストごとのトークン提示・検証は必要であり、「二重認証」ではありません。リフレッシュトークンが失効した場合に備え、再認証と処理再開の方法を設計します（RFC 6750：トークンの提示・検証）。
課題3：Service Bypassの防止
バッチジョブ用にAPIキーだけで認証を通す経路（service bypass）を作ると、本来ユーザー特定が必要なエンドポイントにもAPIキーだけでアクセスできてしまう脆弱性が生まれます。
設計パターン1：入口とAPIの責任を分ける
入口では利用者またはサービスの認証を行い、APIでは受け取った認証情報の有効性と、対象リソースへの操作権限を検証します。入口で認証済みでも、APIごとの検証は省略しません。
設計パターン2：人の代理実行を追跡する
チャットやCLIで起動するエージェントには、認証された主体と許可された操作範囲を結び付けます。チャット上の表示名やメールアドレスだけを本人確認の根拠にせず、承認された対応付けを使います。誰が何を依頼し、どの権限で実行したかを記録します。
設計パターン3：バッチを独立した主体として扱う
ユーザーがいない定期処理には、必要な権限だけを持つサービス主体を用意します。利用する認証基盤の機械間認証の方式、トークンの有効期限、鍵の保管と更新、失効方法を確認します。人のセッションを流用して権限を引き継がせないようにします。
設計パターン4：複数経路で認可を検証する
既存の認証経路を棚卸しし、ユーザー用・サービス用のいずれでも権限外の処理が拒否されるかを確かめます。移行中も実認証と認可を維持し、認証方式の追加を理由に既存の検証を省略しません。
Bearerトークンを用いる場合は送信と保護の要件を確認します。参照：RFC 6750。HTTPのMCP認可には別途MCPの認可仕様も確認し、独自のAPIキーやセッションの組合せをMCP標準と扱わないようにします。
セッション管理のセキュリティ強化
TTL（有効期限）の設定
セッションIDに有効期限を設けます。数時間〜1日程度の範囲で業務に合わせて設定します。これにより、セッションIDが漏洩した場合のリスクを時間的に限定できます。
終了済みセッションの拒否
AIエージェントの実行が完了したセッションは、セッションを終了状態に更新し、以降のAPI呼び出しを拒否します。
認証方式の混在を避ける
同じ要求に複数の認証情報がある場合の扱いを明確にします。不正なトークンを別経路への切替で受け入れず、利用主体と許可範囲が曖昧な要求は拒否します。
実装時のチェックリスト
| チェック項目 | 対策 |
|---|---|
| APIキーだけで権限チェックをスキップできる経路がないか | サービス・ユーザー兼用の認証関数の使用箇所を棚卸し |
| セッションIDに有効期限があるか | TTL超過チェックを認証関数に追加 |
| 終了済みセッションが再利用できないか | 終了状態のセッションを拒否 |
| すべての認証経路でユーザー追跡ができるか | 監査ログに実行者と認証方式を記録 |
| JWTの検証でissuer/audience/expiryをチェックしているか | RS256/ES256署名、短寿命トークン |
| APIキーのローテーション手順が整備されているか | 定期更新スクリプト + 環境変数管理 |
まとめ：AIエージェント時代の認証認可は「マルチチャネル統一」がカギ
AIエージェントの認証認可設計で最も重要なのは、チャネルごとにバラバラの認証方式を使うのではなく、認証基盤の内部で吸収し、エンドポイント側のコードを一切変更せずにマルチチャネル対応を実現することです。
本記事で紹介した4つの設計パターン（統一認証関数・Slack経由フロー・バッチ認証選定・Service Bypass解消）を組み合わせれば、安全かつ拡張性の高いAIエージェント認証基盤を構築できます。
AIエージェントの認証設計・開発はrenueにご相談ください
renueでは、複数チャネルからAIエージェントが安全にAPIを呼び出すための認証基盤を自社で設計・運用しています。本記事では自社の具体的な判定順序や移行手順を公開せず、設計時の一般的な確認事項を整理しています。AIエージェントのセキュリティ設計でお悩みの方は、お気軽にご相談ください。