Control Planeで育てるBtoB SaaSの認証基盤 - SRE NEXT 2026

Transcript

1. Control Planeで育てる、 BtoB SaaSの認証基盤 Dress Code株式会社 / Product & Technology ぽこひで 〜 認証基盤をControl Planeで多層に守り、AIエージェントと共生する 〜
2. © Dress Code Inc . 自己紹介 ぽこひで @pokohide • Dress Code株式会社 ／ Product Engineer • 2025年11月入社。認証基盤など共通基盤の開発を担当 • 前職：株式会社タイミーや不動産SaaSでバックエンド 󰳕 • クラフトビールが好きです🍻
3. © Dress Code Inc . 本日お話しすること 1. Control Planeに向けた認証基盤のリプレイス 2. 認証基盤の信頼性 3. Control Planeをどう守るか 4. 監査ログ基盤 5. AIエージェントとの共生
4. © Dress Code Inc . 会社・プロダクト紹介
5. © Dress Code Inc . 14.1億円　 資金調達を実施 Pre Seed&Seed Round 250+社 が利用中　 Number of companies Number of countries 5カ国 で事業を展開　 Dress Code 会社概要 Company Name / 会社名 Dress Code 株式会社 2024年9月　正式創業：2025年4月 49名 東京都中央区築地2-1-4 銀座PREX East 8F CEO / 代表取締役 Date of establishment / 設立年月 Location / 所在地 江尻 祐樹 Member / メンバー数 5
6. © Dress Code Inc . 挑戦する事業ドメイン/マーケット Asia To Global × Workforce Management 領域 【Entry】 入社/入場 ライフサイクル 【Retire】 退職/退場 採用管理 労務管理 人事/配置 育成/定着 福利厚生 ITツール/備品 拠点/環境 セキュリティ /ガバナンス プロジェクト 外部人材活用 Dress Codeは、従業員の「入社から退職まで」をすべて管理する グローバル（まずはアジア）なワークフォースマネジメントプラットフォーム
7. © Dress Code Inc . デジタル化に伴う社会課題 - 「摩擦問題」 SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む  各業務担当者 • ツールの乱立で、使いこなせない/慣れるまでに時間がかかる • ツール/部門間のアナログ連携が大変 • 担当間/部門間の摩擦が増大している  経営/管理部全体 • 最適なSaaSを選定することが困難 • データが散在していて利用/活用できない • 連携/メンテのためのコスト(時間・お金)が膨大 採用関連データ 採用管理システム 採用 部門 契約関連データ 契約管理システム 法務 部門 労務関連データ 労務管理システム 労務 部門 勤怠関連データ 勤怠管理システム 人事 部門 SaaS関連データ 情報 システム 部門 デバイス関連データ デバイス管理台帳 総務 部門 SaaS管理システム ❌ 分断 ❌ 分断 ❌ 分断 ❌ 分断 ❌ 分断
8. CONFIDENTIAL Copyright © DressCode Inc. All rights reserved. 8
9. © Dress Code Inc . 9
10. © Dress Code Inc . 10 01 Control Planeに向けた 認証基盤のリプレイス
11. © Dress Code Inc . Control PlaneとApplication Plane Control Plane 開設から認証・課金まで、 テナントのライフサイクル を横断して管理する オンボーディング テナント開設・環境の用意 認証・認可 — 今日の主役 誰が・どのテナントで・どの操作まで許されるか テナント管理・課金・計測 運営に必要な共通機能 各テナントを 開設・設定・管理 A 社のテナント A 社のユーザー・データ・設定だけを扱う B 社のテナント B 社のユーザー・データ・設定だけを扱う C 社のテナント C 社のユーザー・データ・設定だけを扱う Application Plane Application Planeの障害は1テナントに閉じるが、Control Planeは全テナントに波及する — 静的安定性の確保が課題
12. © Dress Code Inc . 創業期: Cognito + Lambda フロントエンド Amplify SDK ログイ ン／MFA ① 認証リクエスト Amazon Cognito User Pool ＋ Identity Pool ／ MFA・カスタム属性 ② 拡張処理（トークン発行直前） Lambda トリガー Pre Token Generation テナント情報をクレームに付与 Custom Message 認証コードメールを多言語生成 …ほか ③ テナント・組織情報の問い合わせ 密結合の起点 バックエンド API JWT を検証し、テナント・権限を解決 ④ 業務 API 呼び出し （JWT 付与） 参照 DB テナント／組織／所属情報 B2Bの要件（SSO、ステップアップ認証、多言語、MFA）を足すたびに、Lambdaと自社DBへの作り込みが増える
13. © Dress Code Inc . Cognito運用で見えてきた要件とのギャップ ① 認証とアプリの密結合 TOTPシークレットやステップアップ 認証を個別管理。認証とアプリが密 結合に ② セキュリティを自社で担保 ブルートフォース対策・不正検知・ リスクベース認証まで自前。追い続 ける負荷大 ③ 開発速度の低下 BtoBの当たり前品質の提供に開発リ ソースが溶け続ける ④ 開発体験と保守性 Lambda ＋ Cognitoはローカル再現 が困難。機能追加に伴い1つのトリ ガーに責務が集中 ⑤ マルチテナント非対応 単一テナント向けの基本設計。要件 となるテナントごとのSSOやポリ シー設定が困難 実害も発生 MFA有効時にパスワードリセット不 能に。手段と回復手段を分離できず 解決困難 運用トイルの増大と保守性の低下 — 認証基盤を根本から見直す判断へ
14. © Dress Code Inc . 移行先にOry Kratos (Self-Hosted)を選択 戦略 要件適合 コスト 運用負荷 データ主権 評価 A：Cognito-Hybrid 　 不足分を自前開発 低 低 中 なし 密結合・DX 悪化・セキュリ ティリスクがそのまま残る B：Kratos Self-Hosted 　 OSS を自社運用 ← 採用 高 低※ 高 あり ロックインなし。データを完全 にコントロールできる C：自前実装 　 全部頑張る 中 データ主権は得られるが、実装 ・運用コストとリスクを負う D：IDaaS（Auth0） 　 全部アウトソース 高 高 低 なし MAU課金が「低頻度利用×一括 オンボーディング」と不一致 要件適合＝テナント別SSO・MFAと回復手段の分離・多言語等 ／ ※ 一部のエンタープライズ向け機能は Ory Enterprise License が必要 運用負荷「高」を受け入れ、データ主権や要件適合を優先した選択 高 高 あり
15. © Dress Code Inc . 採用した認証基盤「Ory Kratos」 Go製・オープンソースの認証・Identity 管理システム API-First ＆ ヘッドレス — UI を一切持たず、認証のバックエンドロジックとデータ管理に特化 Self-Service Flow ユーザー自身で完結する操作を、安全な「一連の状態遷移」としてAPI 化 ログイン 登録 設定変更 アカウント回復 メール検証 認証手段はパスワード／パスワードレスコード／Passkey／MFA（TOTP 等）に標準対応。フローの前後に Webhook を差し込める 厳密な状態管理 セッション・CSRF・MFA の状態を Kratos が管理し、DB に集約 柔軟な Identity モデル JSON Schemaで属性・ログイン識別 子を自由に定義 シンプルな構成 単一の静的バイナリで、外部依存は RDBMSだけ。インフラ運用が比較的楽
16. © Dress Code Inc . 認証基盤をOry Kratosに完全移行 AWS Cloud VPC Public subnet Private subnet Isolated subnet  利用者 WAF CloudFront Public ALB NAT Gateway Ory Kratos Public API / Admin API Courier メール配信等 Internal ALB Aurora PostgreSQL SG で接続元を限定 Route 53 PHZ Backend API 同一 VPC・Private subnet SQS Lambda Webhook 監査ログ基盤（S3）
17. © Dress Code Inc . 認証情報の移行 前提: Cognitoはパスワードハッシュをエクスポートできないため、認証情報は「そのまま」持ち出せない Just-in-Time 移行 ログイン時に旧基盤で検証し、成功 したら新基盤に再ハッシュして取り 込む ◯ ユーザー影響ゼロ ✕ 全員ログインまで未完了 ダブルライト＋並行稼働 登録・変更を新旧両方に書き込み、 データが揃ったところで段階的に切 り替える ◯ 切替リスクを分散できる ✕ 二重運用が長期化 一括移行＋再設定案内 Identityを一括インポートし、認証情 報はユーザー個別に再設定してもら う方式 ◯ 二重運用がほぼゼロ・短期完了 ✕ 全ユーザーに再設定負荷 正式創業から約半年でアクティブ利用が限定的 ＝ 再設定の負担が最小の時期と判断。 現在の「事業フェーズ」に最適な移行戦略を選択しました。 採用
18. © Dress Code Inc . 「Ory Hydra」も導入 Go製・オープンソースのOAuth2 / OIDC 認可サーバー API-First ＆ ヘッドレス — UI を一切持たず、認可トークンの発行と検証に特化 OAuth2/OIDC 準拠のトークンフローを標準装備 — セキュアな認可の仕組みをゼロから実装せずに持てる アクセストークンの発行 クライアント管理 同意フロー JWKS公開・検証 認証はそのものは持たず（Kratosに委ねる）認可トークンの発行に専念 分離設計 認証と認可の責務を切り離すことで、シス テム全体の堅牢性と保守性を向上。 運用の横展開 Kratosのセルフホストのインフラ構成を再 利用。ステートレスな実行基盤、および監 視・ログ仕組みをそのまま横展開。 AIエージェントへの布石 RFCに完全準拠した強力なトークンフロー を自社チームのコントロール下に配置。
19. © Dress Code Inc . 19 02 認証基盤の信頼性
20. © Dress Code Inc . 全てのリクエストが認証基盤を通る Ory Kratos はセッションを DB で管理する（ステートフル） — 検証も毎回、照会になる Application Plane ユーザー IT Force HR Force GA Force … ログイン セッション検証 — 毎回 Control Plane Ory Kratos 認証DB Kratos が止まると、ログイン済みユーザーの操作もすべて止まる — 事実上の単一障害点
21. © Dress Code Inc . 信頼性を上げるアプローチ セッションの検証 毎回 短命 JWT による手元検証 Kratos から切り離す セッションの発行・管理 状態が必要 状態は DB に集約 DB を守ることに集中 切り離せる検証は切り離し、残る DB の守りに集中 責務の性質に合わせて打ち手を変える
22. © Dress Code Inc . Proxyを挟み、検証を自己完結に ユーザー セッション Oathkeeper Proxy：セッションを検証し JWT へ変換 短命 JWT バックエンド JWT を手元で検証 セッションの検証はApplication Plane内で自己完結 セッション照会はここだけ Ory Kratos 発行・管理に専念 プロダクトからの毎回 の照会が消える 効果 落ちても、止まるのは新規ログインだけ トレードオフ 失効の即時性 可用性と即時失効は同時に最大化できない — どこまで許容するかが設計判断
23. © Dress Code Inc . ステートフルなDB プロダクト Load Balancer AZ-a Kratos Hydra AZ-c Kratos Hydra 状態はすべてここへ 認証DB 認証基盤の信頼性は、「DB をどう守るか」にフォーカスできる 1. 状態はDBに集中 セッションの正は認証DBの責務 2. プロセスは使い捨て可能 水平スケール・ローリング更新・マル チAZ配信 3. 信頼性の勝負所はDBの1箇所 守る対象を明確にする
24. © Dress Code Inc . 勝負所をDBに集中する 守る 1 Aurora Multi-AZ化 障害時は数分の再作成ではなく、フェイルオーバーで切り替える 守る 2 RDS Proxyの導入 断の短縮と、復帰時の一斉再接続スパイクの平準化 守る 3 物理隔離 隔離サブネット・SG で接続元を限定、接続数上限、自動バックアップ 状態を1ヶ所に集めたことで、守りも1ヶ所に集中投資できる
25. © Dress Code Inc . 信頼性の計測 ECS タスク Kratos / Hydra Datadog Agent ↓ OTLP Datadog — 認証系ダッシュボード トレードオフの影響も計測で確かめながら、「止まるのは新規ログインだけ」の状態へ 1. DD Agentの導入 各タスクからOTLPでメトリクス収集 2. 認証のSLIを監視 認証成功率・p95/p99レイテンシ ・5xx率 3. 信頼性の勝負所はDBの1箇所 守る対象を明確にする
26. © Dress Code Inc . 26 03 Control Planeをどう守るか
27. © Dress Code Inc . DRESS CODEのControl Planeの位置付け 運用者 Control Plane DRESS CODE Admin 社内運用者向け Web UI / BFF 管理 API Backend の admin モジュール 認証基盤 Ory Kratos ＋ Hydra 閉域ネットワーク Internal ALB・SG 全テナントを横断して運用・管理 テナント開設・停止 ／ プラン・課金・計測 ／ ID 運用 ／ CS オペレーション支援 ／ 運用者管理・監査 Application Plane IT Force HR Force GA Force … 運用者向けのUI(Admin)、API、認証基盤、ネットワーク全体を定義
28. © Dress Code Inc . Control Planeのアーキテクチャ 運用者 VPC PUBLIC SUBNET Admin ALB Google OIDC PRIVATE SUBNET Admin Next.js SSR / BFF Internal ALB SG 間許可のみ Ory Kratos 認証基盤 Backend API ISOLATED SUBNET DB 状態の集約先 M2M この構成を ① インフラ ／ ② BFF ／ ③ バックエンド の3層に分けて、どう守っているかを見ていく Adminをハブに認証基盤とバックエンドは内部完結させる AWS WAF
29. © Dress Code Inc . 3層の検証・権限の分離 ① インフラ 到達経路を縛る WAF ＋ OIDC 終端 ＋ 閉域化 ② BFF ALB を信じ切らない 薄いプロキシ ＋ JWT 再検証 ③ バックエンド 特別扱いを作らない 操作範囲をテナントに強制 ＋ 権限で縛る （全層を横断） 認可の SSoT は Google Workspace OU × Role - WIF連携で静的クレデンシャルを持たず AWS の強権限はロールごと分離 特権は必要なときだけ AssumeRole で借りる 各層が同じ仮定に依存しない — 1つ破られても、次の層で止まる リクエストが通る3つの層を独立に検証し、権限で縛る
30. © Dress Code Inc . ① インフラ - 到達経路を物理的に縛る 運用者 同一 VPC Admin ALB Google OIDC 必須 PRIVATE SUBNET Admin ECS(BFF) Internal ALB SG 間許可のみ Ory Kratos 認証基盤 Backend API すべて Internal ALB 経由 入口で人を縛る Admin ALB は Google OIDC 必須 — 社内アカウント以外は到達できない サービス間も閉域 Internal ALB ＋ SG ＋ Private Hosted Zone でVPC 内に完結 インターネットに出ない 公開 ALB は CloudFront 限定 — 管理 経路が物理的に存在しない AWS WAF
31. © Dress Code Inc . ② BFF - 薄く保ち、検証を省かない STEP 1 ALB Google OIDC を終端し、署 名付きトークンを付与 STEP 2 ミドルウェア トークンを再検証（署名・発行 者・社内ドメイン・有効期限） STEP 3 ページ・API 認可ポリシーを各層で独 立に評価 STEP 4 Backend 呼び出し M2M トークンを付与して内 部経路へ 独自 DB を持たない 状態を持つと SSoT の分裂・トークン漏れの隙になる Backend とKratos への薄いプロキシに徹する 認可の SSoT は Google Workspace OU × Role WIF連携で静的クレデンシャルを持たず、権限が自動追従
32. © Dress Code Inc . ③ バックエンド - Contextで閉じる Application Plane 通常 API ユーザー セッションを検証 Context を注入 自テナントのスコープ Control Plane Admin API DRESS CODE Admin M2M 認証 Contextを外から注入 対象テナントを指定 同じ Force の ユースケースへ 処理は Context の スコープに閉じる ドメインのロジックは Force 配下 — Admin の Controller は Force が公開する Adapter I/F にだけ依存 違いは Context の注入元だけ — Admin 専用の広いスコープ・専用ルートを作らない 全ての処理にContextを与え、テナントに閉じたリクエストしか行わせない
33. © Dress Code Inc . 強権限はIAMロールで分離する Application Plane 通常 API 各 Force のユースケース Backend タスクロール 普段のロール データ操作のみ Control Plane テナント開設・削除 AssumeRole Control Plane 専用ロール 対象テナントに限定・短命セッション 特権操作 テナント専用の KMS 鍵・機密 データ用 S3の作成・削除 ECS ごと分ける選択肢もあるが、各環境1系統のシンプルさを保ち IAM ロールの境界で分離 一般 API が侵害されても、IAM レベルで特権操作に届かない
34. © Dress Code Inc . 3層の検証・権限の分離 ① インフラ 到達経路を縛る WAF ＋ OIDC 終端 ＋ 閉域化 ② BFF ALB を信じ切らない 薄いプロキシ ＋ JWT 再検証 ③ バックエンド 特別扱いを作らない 操作範囲をテナントに強制 ＋ 権限で縛る （全層を横断） 認可の SSoT は Google Workspace OU × Role - WIF連携で静的クレデンシャルを持たず AWS の強権限はロールごと分離 特権は必要なときだけ AssumeRole で借りる 各層が同じ仮定に依存しない — 1つ破られても、次の層で止まる リクエストが通る3つの層を独立に検証し、権限で縛る
35. © Dress Code Inc . 35 04 監査ログ基盤
36. © Dress Code Inc . 監査ログを取る 事後調査 起きたことを再構成できる インシデント時、影響範囲を証跡 から特定する。記録がなければ調 査は推測になる 「誰が・いつ・何を」を 操作した本人が否認できない記録 を残す。社内統制の土台 顧客と監査人に示せる エンタープライズのセキュリティ レビューやSOC 2・ISMS は、ログ の提示が前提 強権限が全テナントに及ぶ Control Plane は、操作を追えて初めて成立する 多層で守っても、正規の操作は起きる 説明責任 信頼の証明
37. © Dress Code Inc . 監査ログをどう集めるか DRESS CODE の内側 DRESS CODE の外側 組織のリソース への操作 Operation Activity 業務・管理・特権操作 Backend の各 Force が記録 対象外 外部 SaaS 内の組織リソース操作は、各 SaaS の監査ログの領分 個人の 本人性・行動 Identity Audit ログイン・MFA・セッション発行 認証基盤が記録 Accesses 外部 SaaS・デバイスへのアクセス GWS 監査ログ・Chrome 拡張・MDM 連携 「組織のリソースか、個人の本人性か」と「DRESS CODEの内外」の4事象で考える
38. © Dress Code Inc . 生ログはS3をSSoTに - 表示・分析は派生させる Outbox Pattern 業務 DB 同一トランザクション 業務テーブル 操作を書き込み ＋ Outboxテーブル イベントを追記 リレー Outboxを読み出し SNS へ発行 SNS Firehose S3 ＝ SSoT 生イベント・不変 Object Lock（WORM） 7年保持・KMS 暗号化 組織×日付パーティション 派生① Read Model 画面表示用 - Rehydrate可能 派生② Glue ＋ Athena 正規化して分析・検知クエリへ 証跡と分析は分ける - 正規化・dedupを経たデータは証跡にならない Backendの 各Force 業務・管理・特権操作
39. © Dress Code Inc . 39 05 AIエージェントとの共生
40. © Dress Code Inc . なぜ、AIエージェントの話をするのか コアDBを徹底する — 構造化されたデータ 全プロダクトが単一の正を共有。カスタム項目を作ら ないから、データの意味が組織ごとにブレない Operation Engine — 標準化された業務 入社・異動などの業務プロセスを、最初から Operation Engineの手続きとして標準化 後発だからこそプロダクトの構造で先回りして整備してきた
41. © Dress Code Inc . AIエージェントの責務はControl Planeと重なる • • • AIエージェントの業務はテナントに閉じない エージェントに負わせる責務 → Control Plane の性質そのもの 統治を新しく発明せず、設計済みの Control Plane を拡張して共生する • 判断を伴う実行まで担う • テナントを横断してデータに作用する • 無人で動き続ける • 全テナントのデータに触れる • 強い権限で、テナントを越えて動く • 人間と同等以上の統治が要る
42. © Dress Code Inc . 「繋ぎ方」の標準はある - 「統治」は各社の責任 MCP エージェント ↔ ツール・データ エージェントが外部のツールやデータを 呼び出すための共通規格 A2A エージェント ↔ エージェント エージェント同士が仕事を 依頼し合うための共通規格 誰が・どの権限で・誰の責任で動くか（＝統治）は各社の責任で設計する必要がある
43. 各社のエージェントとの共生の考え Microsoft 主要プレイヤーの統治のアプローチのまとめ OpenAI AWS Okta Ory
44. © Dress Code Inc . Microsoft - エージェントを従業員として統治する 中心概念 ID エージェントに、人間と同列の ID を与える エージェントは「もう一人の従業員」— 人事と同じ仕組みで統治する • Entra Agent ID エージェント1体ごとにIDを発行し、人間と同様に条件付きア クセス・リスク検知・ライフサイクル管理を適用 • Sponsorship 全エージェントに人間の責任者を必須化。異動・退職時は ワークフローで自動移管 • Agent 365 全エージェントの発見・管理・保護を1箇所に集約
45. © Dress Code Inc . Google - 経路と実行時の文脈で統治する 中心概念 Context 全通信を1つの統治プレーンに集 約する ネットワークがガードレール — 人事と全通信を統治プレーン経由に強制する • Agent Gateway エージェントの通信の入り口・出口を1点に集約 • Agent Identity + IAMを実行時検証 エージェント個体にmTLS保護のID。ツール単位のIAM権限を ゲートウェイで検証 • Model Armor - 経路上のコンテンツ検知 Prompt Injection・データ漏洩を通信経路で検査・ブロック
46. © Dress Code Inc . OpenAI - ツールとの接続点で統治する 中心概念 Tool エージェントが触れるツールと データを絞る 何に触れられるかを絞る — ツールの管理が統治の中心 • MCP 接続標準を中立で立て共同統治 • Connector Registry エージェントに触れるデータソース・ツールを一元管理 • Guardrails + Human-in-the-loop ガードレール層(P IIマスク・jailbreak検知） 副作用ある呼び出しは一時停止し人間の承認を求める
47. © Dress Code Inc . AWS - 実行環境ごとに隔離する 中心概念 Infra 実行環境そのものを隔離する 暴走しても問題ないように、実行基盤そのものを隔離する • AgentCore Runtime セッションごとに専用microVMを割当て、CPU・メモリ・ ファイルシステムを完全隔離 • AgentCore Identity エージェント個体にIDを発行。入り口はOAuth/IAMで検証 • Bedrock Guardrails 入力・出力・行動をインフラ側のポリシーで制御
48. © Dress Code Inc . Okta - IdPをエージェント接続の管制塔にする 中心概念 IdP 接続の認可をIdPに集約する 接続の認可をIdPに集約 — ゼロタッチと統制を両立する • Cross App Access - XAA OAuth拡張のオープンプロトコル。エージェントの認可をIdP で一元管理・自動化する • 組織単位での認可 管理者がコネクタを一度認可すれば全社員に適用 • 接続の一元可視化 誰がどのAIで何に繋いだかをIdPで一元可視化
49. © Dress Code Inc . Ory - 静的なキーを短命なトークンに置き換える 中心概念 Token 権限をトークンそのもの に刻んで絞る 権限をトークンに刻む — 絞ることはできても広げることはできない • 静的APIキーを、動的トークンへ - Ory Talos 長寿命な親キーから短命・最小権限な子トークンを都度派 生。親を失効すれば下流の子トークンも即座に無効化 • Macaroonベースの移譲 サブエージェントに渡す際の制約を暗号的に追加し縮小させ ていく。Google主導の認証・権限管理トークン • エージェントもIdentityの一員に AIエージェントにIDを付与し、同じ基盤で管理する
50. © Dress Code Inc . エージェント統治をどこに実装するか Microsoft ID AIエージェントを従業員と 同列のIDとして統治する IDを与え、権限を絞り、証跡を残す という統治のアプローチは共通 AWS Infra セッション単位のmicroVM で実行環境を隔離 Google Context 全通信を統治プレーンに集 約し、実行時にIAMを検証 OpenAI Tool エージェントが触れるツー ル・データを管理 Okta IdP 接続の認可・失効・可視化 をIdPで一元管理 Ory Token 静的APIキーを短命・最小 権限トークンに置き換える
51. © Dress Code Inc . 標準はどこに向かうか - draft-klrc-aiagent-auth エージェント=ワークロード エージェント専用の仕組みを発明せず、 サービスと同じワークロード 新しいプロトコルを発明せず、既存標準の組み合わせで統治する クレデンシャルは短命・実行時発行 自動ローテーション前提。静的APIキーは アンチパターンと明記 認可はOAuth2.0の移譲に乗せる トークンに個体(client_id)と移譲元(sub) を分けて刻む。高リスク操作は人の承認へ 個体をURIで一意に識別 エージェントごとにIDを一つ割当て、認証 ・認可・監査・移譲全ての基準にする IETFの議論中ドラフト https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/
52. © Dress Code Inc . DRESS CODEではどう共生するか
53. © Dress Code Inc . エージェント統治に必要なものはControl Planeにある エージェント統治 に必要なもの 個体の識別 誰であるか ↓ ↓ ↓ Control Plane Identity Control Plane Kratos ＋ Hydra ゼロから発明しない — 人間向けの Control Plane を「拡張」して共生する 行動と許可の制限 何を許すか 行動の証跡 実際に何をしたか 多層の検証 x 権限の分離 BFF / バックエンド / IAM 監査ログ基盤 Operation Activtiy
54. © Dress Code Inc . エージェントを個体として管理する いまの信頼モデル 呼び出し元は Admin 1つ 共有シークレットの M2M → 個体単位の ID ＋ 短命トークン ＋ 誰の代理かを保持 Agent ID どの個体か — 識別の単位を「アプ リ」から「エージェント個体」へ Agent Registry 名前・用途・許可スコープ・状態を台 帳で管理 Owner 人間の責任者を必須に — 退職・異動 時は停止か移管 権限・責任・証跡を、エージェント個体に紐づける 目指す設計
55. © Dress Code Inc . 「個体」として動き、「誰かの代理」で動く 個体として識別される 「どの個体がやったか」を、常に追える × ↓ この考えをトークンにそのまま刻む RFC 8693 Token Exchange sub ＝ 委任元の人間 誰の責任か act ＝ 実行体のエージェント どの個体か 常に誰かの代理で動く 委任の根は、常に人間
56. © Dress Code Inc . RFC 8693 Token Exchange 交換前 ユーザーのトークン sub ＝ ユーザー本人。これをそのまま渡 すと、本人の全権限ごと渡ってしまう Token Exchange → 認可サーバで交換 交換後 委任トークン＝OBO(On-Behalf-Of) sub 委任元のユーザー — 誰の代理か act 実行体のエージェント — どの個体か scope ユーザー権限の subset に絞る exp 短命 — 使い終わったら消える 元の認証情報を渡さない 権限を、必要な範囲だけに絞れる 「誰の代理で・どの個体が」が残る トークンを「委任のかたち」に交換して渡す — これが OBO トークン 手元のトークンを別のトークンに交換するOAuth2の標準拡張
57. © Dress Code Inc . チェーンは繋げず、都度発行し直す ❌ マルチホップ型 人 → A → B → C … 権限がバケツリレーで流れていく 深くなるほど検証・失効・性能が破綻 ⭕ ハブ型・都度発行 人 → オーケスト レーター → サブエージェントA → サブエージェントB → サービスC 呼ぶたびに Control Plane で再発行 権限は連鎖しない（常に 1 ホップ）
58. © Dress Code Inc . 同じ土俵、違いはトークンだけ 人間の運用者 認証基盤のセッション AI エージェント 短命の委任トークン sub＝委任元 ／ act＝実行体 業務 API 同じエンド ポイント 権限チェック 同じ Context 強制 監査ログ 委任元 ＋実行体を記録 危険な操作は 人の承認 入口で渡すものは違うがその先の検証・記録・統治はすべて共通 違いは入口の1行だけ — だから人間向けの統治が、そのまま効く 人間と同じ経路を通し、制約はより厳しく（短命トークン、権限サブセット、責任者必須）
59. © Dress Code Inc . 拡張① - OBO + Token Valut OBO トークン (RFC 8693 互換) sub 委任元のユーザー act 実行体のエージェント個体 scope ユーザー権限のsubsetのみ exp 最大 15 分・Refresh なし 「誰の代理で・どの個体が・何を・いつ まで」がトークンだけで完結する scope は「用途 × 委任元」の積集合 事前定義した用途の範囲と、ユーザー権限の重なりだけを渡す 再委譲は禁止（depth=1） jti の失効チェックで即時取り消し。発行も失効も Control Planeに集約 外部 SaaS のトークンは Token Vault に隔離 エージェント本体にクレデンシャルを渡さない 渡すのは権限そのものではなく — 期限と範囲を刻んだ、1枚の短命トークン
60. © Dress Code Inc . 拡張② - 危険な操作にだけ、人の承認を挟む 顧客への成代わり 隔離して実行 関門：検証 ＋ 承認 ＋ 隔離 破壊的・テナント横断の操作 非同期の人の承認 関門：検証 ＋ 人の承認 ほとんどの操作 自律で実行 関門：トークン検証と監査のみ read-only・時限つきの隔離実行環境 特に重い操作は、環境ごと閉じ込める APIは202で保留→通知→承認後に実行 非同期 Human-in-the-loop で承認疲れを防ぐ 短命 OBO トークンのまま流す 監査ログ・スコープ強制は全操作に適用 承認フローは共通基盤のOperation Engineの承認タスクに載せる
61. © Dress Code Inc . DRESS CODEでのAIエージェントとの共生 1 個体として識別する Agent ID を台帳で管理 — 責任者のいない個体はない 2 常に誰かの代理で動かす sub／act の委任トークン — 都度発行（depth=1） 3 人間と同じ経路・同じ統治 裏口を作らない — 危険な操作だけ、人の承認 専用の統治を新規発明しない。ヒトのために建てたControl Planeの「延長」で実現する
62. © Dress Code Inc . 補足：多段移譲の標準化 ① 委譲の経緯を、検証できる形で残す ユーザー → Agent A → Agent B ↓ トークン内の delegation_chain ① ユーザー → Agent A 認可サーバの署名 ② Agent A → Agent B 認可サーバの署名 署名付きレコードが積み上がる API 側で、チェーン全体を検証できる ② 権限を、暗号的に減衰させて渡す 親トークン 読取 更新 削除 → 削除 → 親トークンから、暗号的に権限を削った子トークンを派生 認可サーバに問い合わせない 手元のトークンから絞って渡せる（オフライン） https://datatracker.ietf.org/doc/draft- liu-oauth-chain-delegation/ IETF: draft-liu-oauth-chain-delegation IETF: draft-niyikiza-oauth-attenuating-agent-tokens（AATs） 子トークン 孫トークン 読取 更新 削除 読取 更新
63. © Dress Code Inc . 63 06 さいごに
64. © Dress Code Inc . まとめ 拡張 AIエージェントとの共生 エージェントも、同じ Control Plane に載る OBO - 常に誰かの代理 危険な操作は、人の承認 ▲ 延長 ▲ 実践 Control Planeを支える 信頼性 静的安定性・SLI で支える 多層防御 各層で独立に検証して守る 監査ログ Outbox→S3(SSoT)で証跡に ▲ ▲ 土台 SaaS の設計思想 Control Plane 認証基盤はここに — 統治を作り込む Application Plane ヒトのために建てたControl Planeの延長に、エージェントが載る Agentを個体とし識別
65. © Dress Code Inc . 65 ご清聴ありがとうございました！！ ブースや懇親会でもお話しましょう！