はじめに
こんにちは、株式会社AI Shiftでバックエンド開発をしている中野です。
先日、AI Workerに外部認証（OAuth/OIDC）を追加しました。AI Worker上で動くAI エージェントが、GoogleやMicrosoftなど外部Providerのデータに、ユーザーの同意とスコープの範囲内でアクセスできるようにするための機能です。
導入前は、認証が必要な外部Providerのリソースに直接アクセスできませんでした。そのため、たとえばOutlookのメールやBoxのファイルをいったん手元にダウンロードしてから、AI Worker上でRAG用にインデックス化するといった手間が発生していました。
外部認証を入れたことで、AIエージェントが必要なデータを取得し、そのまま処理に繋げられるようになりました。「データをコピーして持つ」のではなく、「必要な範囲の権限を委任して取りに行く」方向へ設計を寄せられたのが大きいです。
今回は、この機能を導入していく過程で詰まったポイントを整理します。特に、Providerごとの違いを「主権モデル（最終的に誰がOKを出すか）」としてまとめ、次に同じことをやるならどう進めるかを手順として残します。
結論
結論から言うと、今回ボトルネックになったのは、OAuth/OIDCの実装そのものではなく、認証アプリの申請・同意でした。
OAuth 2.0は「第三者アプリが、リソースオーナー（多くはユーザー）の承認を経て、HTTPサービスに限定的なアクセスを得る」枠組みとして標準化されています。実装面は定石があり、設計でコントロールできる部分も多いです。[1]
一方で、マルチテナントで外部Provider連携をやると、技術以外の要素が前に出ます。たとえばMicrosoft Entra IDでは、テナントの設定によってユーザー同意が許可されない（あるいは要求権限がユーザー同意の対象外になる）ことがあり、その場合は管理者同意が前提になります。つまり、ユーザー体験としての同意ではなく、「組織（テナント）の方針としての同意運用」が開発速度を左右します。[2]
そのため、もし次に同じことをもう一度やるなら、実装に入る前に UI/UX・必要スコープ・予算/稟議・管理者同意の運用 を先に確定させます。ここが曖昧なまま進むと、途中で止まる可能性が高く、手戻りも大きくなりやすいと分かりました。特にGoogleはスコープ次第で求められる手続きが大きく変わり得るので、要求スコープと同意画面（何を、なぜ、どの範囲で扱うか）を早い段階で固め、必要なら審査や外部評価を前提に計画するのが安全です（詳細は後述します）。[3][4]
外部認証の構成
先に用語だけ整理します。
AuthN（Authentication / 認証）は「あなたは誰か」を確認することです。AuthZ（Authorization / 認可）は「あなたに何を許可するか」を決めることです。外部Providerのデータへアクセスする文脈で中心になるのは、主に後者（AuthZ）です。[1:1]
OAuth 2.0は「リソースオーナーの承認を経て、第三者アプリが限定的にアクセスを得る」ための枠組みです。[1:2]
OIDC（OpenID Connect）は、OAuth 2.0の上に「認証（AuthN）」のためのアイデンティティ層を載せた仕様で、ID Tokenなどを通じてユーザーの同一性を扱えるようにします。[5]
実装フローとしては、基本的にAuthorization Code Flowを前提にします。また、public clientになり得るケース（ネイティブ/SPA等）では、認可コード横取り攻撃への対策としてPKCE（Proof Key for Code Exchange）を組み合わせるのが一般的です。[6]
なお、実装の詳細（トークン管理や保管、鍵管理など）は今回の主題ではないため踏み込みません。
外部認証で見えてきた「主権モデル」
外部認証を複数Providerで扱ってみると、実装の違いよりも、申請・同意の運用の違いのほうが開発の進み方に影響しました。そこで、最終的に誰がOKを出すかという観点で「主権モデル」として整理しました。
本稿でいう主権モデルとは、端的には「最終的にアクセス許可のOKを出す意思決定者が誰か」を指します。OAuthはフロー（手順）を標準化しますが、許可の最終条件や運用主体までは標準化しません。この差分が、申請・同意・審査の難易度として表面化します。
以下では、Google / Microsoft Entra ID / Boxを同じ軸（主権モデル）で並べます。
Google：ユーザー主権 + 外部監査（市場化された信頼）
Googleは、特にSensitive / Restricted scopes[7]に対して追加要件を課します。Google API Services User Data Policyでは、Sensitive/Restricted scopesにアクセスするアプリはセキュアなデータ取り扱いを求められ、条件によっては年次のセキュリティ評価と、Google指定の第三者が発行するLetter of Assessment（LOA）が必要になる旨が説明されています。[3:1]
さらにrestricted scope verificationでは、verified restricted scopesを維持するために「少なくとも12か月ごとの再評価」と「セキュリティ評価（assessorのLOA）」が必要になることが明示されています。[4:1]
結果として、Googleでは「ユーザーが同意した」だけで完結せず、「アプリが安全に扱えることを（外部評価を含めて）示せるか」が許可の条件に入りやすい構造になります。
Microsoft Entra ID：組織主権（テナント管理者が最終決定者）
Microsoft Entra IDは、同意の主語が組織（テナント）側に寄るケースが明確です。Microsoftの説明では、ユーザー同意は「許可されている場合にのみ」成立し、管理者は組織の方針としてユーザー同意を無効化できます。ユーザー同意が無効、またはユーザーが同意できない権限を要求している場合は、ユーザーは同意できず、管理者同意が必要になります。[2:1]
自分のケースでも、親会社Azure×子会社という構造の中で「管理者は誰か」を特定するところから始まり、ここが実装以前のボトルネックになりました。
Box：コンテンツ境界モデル（スコープ×ユーザー権限 + downscoping）
Boxは、APIアクセスの成立条件が「スコープだけ」ではなく、ユーザー権限やアプリ設定、エンドポイント固有制約などの組み合わせで決まることを明示しています。つまり、許可の境界がコンテンツ（フォルダ・ファイル）と権限の交点に置かれている、と読めます。[8]
さらにBoxはdownscopingを前面に出しています。トークンをより制限された権限に絞る必要がある場面（例：ブラウザにトークンを露出させるケース）と、そのために追加スコープを用いてダウンスコープする考え方が説明されています。[8:1]
自分としては「まずフルスコープを委任し、運用で絞り込む」という発想が前提になっている点が意外でした。
ここまでが主権モデルの整理です。以降は、実務上ボトルネックになりやすかったGoogleの審査（Verification）とCASAを、工程として具体に書きます。
Google：審査フローでボトルネックになりやすいポイント
GoogleのVerificationは、ホームページ要件やプライバシーポリシー、ブランドガイドラインなど複数の観点で進行状況が管理されます。
この中でも、実務上もっとも負荷が高かったのは「最小スコープのリクエスト」と、最終的に要求されることがあるCASAセキュリティ評価でした。Google側が求める「最小化」と「説明責任」は、User Data Policyやrestricted scope verificationの趣旨とも整合します。[3:2][4:2]
最小スコープのリクエスト（UI/UXと説明責任の整合が問われる）
「最小スコープのリクエスト」は、単にスコープを絞ればよいという話ではありませんでした。アプリのUI/UX、同意画面の説明、実際に提供する機能、そして要求するスコープが一貫している必要があります。
とくにDriveの読み書きやメール送信のようなrestricted scopeを申請する場合は、審査側が「その権限が本当に必要で、どう使われ、どう保護されるのか」を具体的に確認できる状態を求めてきます。
その具体の代表例が「動画」の提出です。restricted scopeを含む場合、認証開始から完了までの一連の流れを説明できる動画を用意しておくと、後から慌てずに済みます。動画の中には少なくとも(1)認証開始から完了までの画面遷移と、(2)付与されたスコープをアプリ上でどのように利用しているかが写っている必要がありました。
審査のコミュニケーション（時差がリードタイムに影響する）
もう一つ、地味に辛かったのがコミュニケーションのリードタイムです。審査はTrust and Safetyチームとのメール往復が発生しますが、時差の影響で返信が日本時間の早朝（体感として朝5時前後）に届くことが多かったです。こちらの返答が遅れると、その分次の返信が翌日〜数日後になり、結果的に審査全体の進行が1〜2日単位で伸びます。
まとめると、Googleの審査は「スコープを申請する」よりも、「そのスコープが必要であることを、UI/UXと証拠（動画）で説明できる状態にする」ことが難所になりやすいと感じました。
GoogleでCASA（外部評価）が必要になった場合
restricted scopeを含む場合、状況によってはCASA（Cloud Application Security Assessment）の完了が求められます。ここから先は、実装というより「外部評価のプロセス」になるため、プロジェクト計画の立て方が変わります。実際、Googleのrestricted scope verificationでは、verified restricted scopesの維持に「セキュリティ評価とLOA」が関係することが明示されています。[4:3]
補足として、私のケースではrestricted scopeを申請していたため、CASAはTier3扱いになりました。ここは見落としやすいのですが、Tier2とTier3で必要な手間とコストが一段跳ねます。少なくとも私が確認した範囲では、期間の目安が約4倍（1週間→4週間）になり、費用も約7倍（$720→$4,500）に増えました。restricted scopeを含む場合は、最初からTier3前提で予算とスケジュールを組んでおいた方が安全です。
TACにおけるCASAの作業フロー
ここではCASA実施機関としてTAC Security[9]を選びました。
TACで案内されたCASAの作業フローをそのまま載せます（どこで待ち時間が発生するかの目安になります）。
| Step | 作業 | 目安 |
|---|---|---|
| 1 | Scan your App | 1–2 days |
| 2 | Remediate all found vulnerabilities | （指摘内容次第） |
| 3 | Rescan your App | 1–2 days |
| 4 | Submit the SAQ（Self-Assessment Questionnaire） | （提出作業） |
| 5 | Inform us for review | 1–2 days |
| 6 | LOA Submission | 1–2 days（脆弱性対応後、1〜2営業日が目安） |
| 7 | Reverification email from Google | 2–4 business days（Google側待ち） |
Google指定のCASA機関：相見積もり結果（当時）
次に、Google指定のCASA機関に相見積もりした結果をまとめます（価格と期間のレンジ感を見るためです）。
| 機関 | 価格 | 期間 | 備考/リンク |
|---|---|---|---|
| Bishop Fox | $15,000 USD | - | https://bishopfox.com/services/vendor-assessments/casa |
| KPMG | 600〜800万円 | 12〜14週間 | （当時の提示） |
| Leviathan Security | $6,000 USD | - | https://www.leviathansecurity.com/programs/google-casa-cloud-application-security-assessment |
| NCC Group | $9,650 USD | 2〜4 weeks | https://www.nccgroup.com/campaign/forms/casa/ |
| Prescient Security LLC | $10,000 USD | 2〜3 weeks | https://prescientsecurity.com/casa |
| TAC Security | $4,500 USD | 2〜4 weeks | https://casa.tacsecurity.com/site/home |
| DEKRA | 5,400 EUR | 3 weeks | https://www.dekra.com/en/contact-casa/ |
| NetSentries Technologies | — | — | https://www.netsentries.com/service/casa （返信なし） |
| Orange Cyberdefense South Africa (Pty) Ltd | — | — | （返信なし） |
上の通り、CASAは機関によって価格も期間もレンジが大きいです。実装工数は開発側である程度コントロールできますが、CASAは外部プロセスなので、見積取得・稟議・発注・スケジュール確保の時点でリードタイムが発生します。さらに、スキャン→修正→再スキャンの往復や、ベンダー側レビュー、Google側の再確認など、開発チームの都合だけでは短縮しにくい待ち時間も混ざります。
そのため、restricted scopeを含む可能性があるなら、実装に入ってから考えるのではなく、UI/UXと要求スコープを固めた時点で、稟議と予算枠（カード上限含む）を先に確保しておく方が安全でした。ここが後回しになると、実装が終わっていてもCASA待ちで検証が止まり、プロジェクト全体として前に進まない状態になりやすいです。
今ならこう進める
もし同じ前提で、AIエージェントに外部認証機能をもう一度ゼロから導入するなら、最初に実装へ入らないです。今回ボトルネックになったのはコードではなく、申請・同意・審査といった手続き側だったためです。
次にやるなら「主権モデルの確認→申請・同意・審査まわりの先行→UI/UXとスコープ最小化→実装→手戻り前提の計画」という順序で進めます。主権モデルが曖昧なままだと、後から「管理者同意が必要だった」「追加の審査が必要だった」といった形で手戻りが起きやすいです。
また、申請・同意・審査まわりは開発側だけでは短縮しづらい工程が混ざるので、最初から“待ち時間と差し戻しが起きる前提”で計画に織り込む方が安全でした。
まとめ
OAuthはフローとしては標準化されていますが、「最終的に誰がOKを出すか」という主権モデルまでは標準化されていません。[1:3] そのため、外部認証の導入では実装よりも、申請・同意・審査がボトルネックになりやすいと感じました。
特にマルチテナントでは、管理者同意や審査要件が前面に出ます。ここを後回しにすると、実装が終わっていても承認待ちで止まり、プロジェクト全体として前に進まない状態になりやすいです。
Providerによって「許可の最終決定者」が異なる点に気付けたのが、今回の一番大きい学びでした。
最後に
AI Shiftではエンジニアの採用に力を入れています。少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか（オンライン・19時以降の面談も可能です）。
【面談フォームはこちら】
参考文献（脚注）
-
RFC 6749 "The OAuth 2.0 Authorization Framework" (RFC Editor) https://www.rfc-editor.org/info/rfc6749 ↩︎ ↩︎ ↩︎ ↩︎
-
Overview of user and admin consent - Microsoft Entra ID（ユーザー同意が許可されない場合に管理者同意が必要になる）https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/user-admin-consent-overview ↩︎ ↩︎
-
Google API Services User Data Policy（Sensitive/Restricted scopesとセキュリティ評価・LOAについて）https://developers.google.com/terms/api-services-user-data-policy ↩︎ ↩︎ ↩︎
-
Restricted scope verification（再評価・セキュリティ評価・LOAについて）https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification ↩︎ ↩︎ ↩︎ ↩︎
-
OpenID Connect Core 1.0 (Final) https://openid.net/specs/openid-connect-core-1_0-18.html ↩︎
-
RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" (RFC Editor) https://www.rfc-editor.org/info/rfc7636 ↩︎
-
Googleの「Sensitive scopes / Restricted scopes」は、Google API（例：Gmail/Driveなどのユーザーデータ）に対するアクセス権限（OAuth scope）のうち、特に機微性が高いデータへのアクセスを伴うため追加要件（例：追加の審査、セキュリティ要件、場合によっては第三者評価）が課されるカテゴリです。定義と要求事項はGoogleのUser Data PolicyとRestricted scope verificationに整理されています。https://developers.google.com/terms/api-services-user-data-policy および https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification ↩︎
-
Box Developer Documentation - Scopes（downscopingやスコープ設計について）https://box.dev/guides/api-calls/permissions-and-errors/scopes/ ↩︎ ↩︎
-
TACは「TAC Security」のことで、Googleが指定するCASA（Cloud Application Security Assessment）実施機関の一つです。本稿ではCASAの外部評価を依頼するベンダーとしてTAC Securityを選び、その提示フロー例を掲載しています。https://casa.tacsecurity.com/site/home ↩︎
Discussion