はじめに
こんにちは、ネクストモードのゆきなわです。
現在、米国ラスベガスで開催中の Okta 社の年次イベント Oktane 2026 に参加しています。
初日の2026年9月22日に基調講演に先立ち行われたセッション「Yahoo's journey building to an agentic enterprise」では、米 Yahoo 社が 2017年に Okta を導入してから、AI エージェントを支える認証・認可基盤へ発展させるまでの歩みが紹介されました。
本記事では、Okta の利用範囲がどのように広がったのか、Oktane 2025 がなぜ転機になったのか、そして現在のエージェント開発基盤がどの規模で使われているのかをレポートします。
セッション概要
- 日時：2026年9月22日 15:00〜15:30（現地時間／PDT）
- タイトル：Yahoo's journey building to an agentic enterprise
- 登壇者：Bryan Meister 氏、Senior Principal Architect、Yahoo
- セッションタイプ：Breakouts
- 主なトピック：Access Management、Authentication、Authorization、Identity Posture Management、Securing Non-Human Identities
Yahoo のエンタープライズ ID の歩みを紹介する Bryan Meister 氏
2017年の Okta 導入から人の ID 基盤を成熟させるまで
Yahoo のサイバーセキュリティチーム「Paranoids」に属するエンタープライズ ID チームは、ID ライフサイクル、認証、ID ガバナンス、日々の ID サービス運用、メトリクスまでを担当しています。現在の体制は、オペレーションエンジニア、アーキテクト、開発者に加え、IT、HR、財務、調達など多くの関係者で構成されています。
Yahoo が Okta を導入したのは 2017年です。組織再編を機に新しい ID 環境をゼロから構築し、エンタープライズ向けアプリケーションの認証基盤として Okta を採用しました。当初の Okta は、社内の管理システムや LDAP ディレクトリの後段で、各アプリケーションの認証を担う基盤でした。OpenID Connect（OIDC）を優先しつつ SAML にも対応し、その後、対象アプリケーションは約 1,000 まで増えました。
2019年のリブランドでは、メールアドレスやドメインの変更を含む ID ライフサイクルの再設計が必要になりました。2021年には組織構造の変更に合わせ、ロールベースアクセス制御（RBAC）と属性ベースアクセス制御（ABAC）のモデルも見直しました。
2023年には Okta Identity Engine（OIE）への移行を進め、Okta MFA と Okta Device Trust を導入しました。セッションでは、Okta MFA の展開後、認証の 99%以上がフィッシング耐性のある方式になったと説明されました。Okta は単なるアプリケーション認証基盤から、端末状態やポリシーも含めてアクセスを制御するプラットフォームへ発展しました。
2017年から2025年までの Yahoo のエンタープライズ ID の歩み
Oktane 2025 で人の ID の課題が AI エージェントの課題につながった
2025年当時、Yahoo では Okta がアプリケーション認証を担い、別のガバナンス基盤がアプリケーションの権限を付与していました。利用者がアプリケーションを使うには、両方の仕組みで設定が一致する必要があります。LDAP インポートを介するため、申請した権限が Okta に反映されるまで待ち時間も発生していました。
Yahoo は Oktane 2025 で、認証と認可のポリシー制御を共通の ID 基盤に統合できるか検討する予定でした。しかし、現地入りしたタイミングで、プロダクション側の生成 AI ワーキンググループから、エンタープライズ領域にある MCP リソースへの認証を求める相談が届きました。
従来分かれていたエンタープライズ領域とプロダクション領域の境界が、AI エージェントによって薄れ始めていました。開発者が AI エージェントを使ってソフトウェア開発ライフサイクルを自動化しても、ドキュメント、チケット、SaaS などのエンタープライズサービスへ安全に接続できなければ、エンドツーエンドのワークフローは成立しません。
AI エージェントでは、権限反映の待ち時間が大きなボトルネックになります。セッションでは、あるサービスの利用申請後、LDAP から Okta への反映を待っている間に「使えない」というインシデントが起票された例も紹介されました。人の ID で残っていた権限反映の待ち時間が、エージェント型ワークロードの運用でも課題になりました。
Oktane 2025 の会期中に Yahoo は Identity Security Posture Management（ISPM） を確認し、その後 Okta Identity Governance（OIG） も評価しました。Okta Identity Governance（OIG） を ID プロバイダーとして活用する方針を決めたことが、現在の取り組みにつながっています。
MCP サーバー向け認証の相談が転機となった Oktane 2025
エージェント型 AI と人以外の ID（NHI）を支える設計原則
人以外の ID（Non-Human Identities：NHI）とは、サービスアカウントや AI エージェントなど、人ではない主体に割り当てる ID を指します。Yahoo が整理した初期設計原則は、次の 3つです。
| 設計原則 | セッションで示された考え方 | 読者への示唆 |
|---|---|---|
| ポリシー制御の統合 | 認証と認可のポリシーを共通の ID 基盤で評価し、変更をリアルタイムに適用する | 権限を申請してから利用できるまでの待ち時間を短縮する |
| 標準仕様の採用 | OAuth 2.0／OIDC、Cross App Access（XAA）／ID-JAG、MCP を軸にする | 独自方式を増やさず、利用者の権限を委任する仕組みを標準仕様で実装する |
| エージェントのライフサイクル管理 | 登録時点から所有者、権限、利用範囲を管理し、未登録のエージェントも検出する | 正規の登録手順と、管理者が把握していないエージェントを見つける仕組みを両立する |
AI エージェントが利用者の代わりに SaaS や API を呼び出す場合でも、誰の権限で、どのリソースへ、どのスコープでアクセスするのかを確認できる必要があります。人の ID が、代理アクセスにおける信頼の起点になります。
セッションでは、Cross App Access（XAA） と Identity Assertion JWT Authorization Grant（ID-JAG）の採用を促進する方針も示されました。XAA は ID-JAG を使い、利用者の ID 情報を、接続先のアプリケーションで使えるスコープ付きアクセストークンへ交換します。OAuth 2.0／OIDC に基づくトークン交換によって、利用者から AI エージェントへ委任された権限を接続先でも確認できるようにする考え方です。
セッションでは、エージェントを検出してから対処するだけでなく、最初から正しく登録させる方針も示されました。管理者が把握していない AI エージェント、いわゆるシャドー AI の検出は必要です。同時に、所有者と必要権限を登録時に定義し、役割の変化に合わせて権限を更新する仕組みも整えます。
エージェント型 AI と人以外の ID（NHI）に向けた初期設計原則
Yahoo Enterprise for Agentic Developers を支える Okta と YConnect
Yahoo は、オペレーション、テクノロジー、Paranoids の 3つの組織で Yahoo Enterprise for Agentic Developers を進めています。プログラムの合言葉として紹介されたのが、「Everyone is an Agentic developer」です。開発者だけでなく、アナリストやマネジメントも含め、誰もが AI エージェントを立ち上げ、不要になれば終了できる環境を目指しています。
Paranoids の ID チームでは、次の Okta 製品を組み合わせています。
- Okta Privileged Access：対話ユーザーを持たないサービスアカウントや特権アクセスを管理
- Identity Security Posture Management（ISPM）：既存環境にある AI エージェントやリスクを検出
- Okta for AI Agents：エージェントを ID として扱い、認証・認可の基盤を提供
- Okta Identity Governance（OIG）：アクセス申請、承認、ガバナンスを統合
Microsoft 関連環境との連携を有効にしてから約 5分後、ISPM は、すでに生成 AI の実験で使われていた複数のエージェントを検出しました。各エージェントの所有者も特定できたと紹介されています。接続先が Microsoft Entra ID、Microsoft 365 などのどの環境だったかは、文字起こしだけでは確認できませんでした。
OIG の概念実証では、サイバー防御チームが ISPM の利用を申請し、承認を含む一連の申請フローを検証しました。
テクノロジーチームは、最初に MCP OAuth Proxy を構築し、その後、内製の YConnect MCP Gateway に置き換えました。YConnect MCP Gateway は、利用者やエージェントが Okta で認証・認可を受けたうえで、複数の MCP サービスやエンタープライズアプリケーションへ接続するためのゲートウェイです。
Yahoo Enterprise for Agentic Developers を構成する取り組み
6つの指標で見るエージェント開発基盤の規模
セッションで示された数字からは、取り組みが実験段階を超え、全社規模の基盤になりつつあることがわかります。
| 指標 | セッションで示された規模 |
|---|---|
| Okta が管理する ID 数 | 8,600件。そのうち、従業員や契約社員など人に紐づく ID は約 8,000件 |
| Claude の利用時に実行された人の認証確認 | 直近 3か月で 20万回 |
| Okta に登録されたアプリケーション数 | 1,189件。2025年9月と比べて 200件増加 |
| Yahoo の従業員が利用できる MCP サービス数 | 66サービス。定期的に利用するユーザーは 4,000人超 |
| MCP サービスに対するツール呼び出し回数 | 2026年7月〜9月の四半期で 700万回 |
| 約 5%のユーザーを対象にした試験的な圧縮処理によるトークン削減数 | 9,500万トークン |
Okta に登録されたアプリケーションは、2025年9月から 200件増えました。OIDC や AI エージェントに関連する利用の広がりが背景にあると説明されています。また、約 5%のユーザーを対象にした圧縮実験で 9,500万トークンを削減できたことから、YConnect MCP Gateway は、認証・認可に加えてコストや利用量を管理する基盤にも拡張できる可能性があります。
Yahoo のエージェント開発基盤の利用規模
エンタープライズとプロダクションの境界を越える次の一歩
現在の高レベルアーキテクチャでは、YConnect MCP Gateway と Okta の認可サーバーが、エンタープライズ領域とプロダクション領域をつないでいます。AI エージェントを登録し、認可サーバーで許可するスコープと利用可能なツールやスキルを割り当てます。必要な権限だけを付与し、関係のないサービスへの横移動を防ぐ設計です。
今後は、セルフサービスでのエージェント登録に加え、エージェントからサービスへの呼び出しと、エージェント間の呼び出しを制御する予定です。強力な管理権限の一部だけをスキルとして切り出す場合でも、別のサービスへ横移動できないように制御し、エージェントが担当範囲を超えない設計が求められます。
人の ID 管理で使われる入社・異動・退職（Joiner・Mover・Leaver）の考え方は、AI エージェントにも適用できます。作成時に所有者と目的を登録し、役割の変更に合わせて権限を更新し、不要になったエージェントを確実に終了します。これは、AI エージェントを業務基盤に組み込む企業環境に必要な ID ライフサイクルです。
エンタープライズ領域とプロダクション領域をつなぐ概念設計
おわりに
AI エージェント対応は、人の ID で残っていた認証と認可の分離、権限反映の待ち時間、エンタープライズ領域とプロダクション領域の境界といった課題の延長線上にあります。
既存の ID 基盤を整え、標準プロトコルを採用し、登録と検出の両方でエージェントを管理することが、AI 活用を安全に広げる土台になると感じました。
また、利用範囲や組織の変化に合わせて ID 基盤を見直し続ける Yahoo の姿勢は、AI の活用が広がりつつあるエンタープライズの Okta の運用を考えるうえでも大変参考になりました。
引き続き現地からのレポートをお楽しみに！
Okta に関するお問い合わせ
ネクストモードでは Okta の導入から運用までを支援しています。Okta に関するご相談は、ネクストモードまでお気軽にお問い合わせください。
