世界の大企業が採用してきたID基盤「Ping」──Entra ID/Oktaとの違いを読み解く

トヨタの欧州法人は車両を認証要素に？ グローバル大手に選ばれる理由

　Toyota Motor EuropeもPingを利用して顧客ポータル「My Toyota」と車載システムの認証を統合した。ユニークなポイントとして齊藤氏は、多要素認証（MFA）の要素に車両そのものを使っている点を挙げる。作り込みを基本方針とするPingの特徴がよく表れた事例といえる。

　Pingは、要件に合わせて認証の流れを細かく作り込めることを重視した製品だ。「これらを使いこなすにはそれなりの設計力が必要になってきます。これは優劣ではなく、設計思想の違いです」と齊藤氏は説明する。

　置き場所の自由度も特徴だ。マルチテナントと専有テナント型のSaaSに加え、オンプレミス環境にも展開できるPingFederate、また米国政府向けのソリューションも持つ。齊藤氏はSaaSとオンプレミスの両方を提供している点を、医療や航空などの重要インフラ業界や銀行で好まれる理由の一つに挙げた。

　同社ソリューションの作り込みを担っているのが、認証／認可のフローをブロックで視覚的に組み立てるPingOne DaVinciだ。クラウドネイティブ社は自社でPingOneを利用し、通信を検査するセキュリティソリューションであるNetskopeが起動していない端末からはシステムにログインさせないフローを、分岐ブロックの追加で実装できることを確認している。EDRやVPNクライアントの稼働状況も同じように条件に加えられるほか、Jamf ProやIntuneといったMDM（モバイルデバイス管理）に問い合わせて会社の管理下にある端末かチェックを行い、社外の端末からの認証を弾くこともできる。

　既存のActive Directoryとの連携では、Pingはグループのネスト構造を保ったまま取り込むことが可能だ。

　「エンタープライズ企業は特にActive Directoryへの依存が非常に大きいので、Active Directory時代のグループ設計を活かして移行できるのは大きなポイントです」（齊藤氏）

AIエージェントの管理設計にみる3社の違い

　続いて同氏は、AIエージェント向けのID基盤の動きに話題を移した。現状、多くのAIエージェントは人間のOAuthトークンを使い回したり、APIキーを渡されたりすることで動いている。そのためID基盤側でAIを「IDを持つ主体」として管理する必要性が高まってきた。

　こうした状況を踏まえ、Okta、Entra ID、PingそれぞれがAI向けのアイデンティティ管理ソリューションを提供している。PingのIdentity for AIは2026年3月31日、Microsoft Entra Agent IDが同年4月、Okta for AI Agentsが同年4月30日に一般提供が開始された。

　3社のソリューションは組み立て方やAIによる代理許可を事前に置く場所などに違いはあるものの、「AIエージェントの管理という側面においては、基本的にどの製品を選んでもできることは間違いないです」と齊藤氏は述べる。

　大きな違いは機能の有無ではなく、「代理情報を誰が作り、どこで必須化するかにある」と言う。

　「AIエージェントの領域は第三者機関によって定められた標準などがまだないため、自社への導入を検討する際には、製品を見て決めるのではなく、自社の要件を先に決める必要があります」（齊藤氏）

　具体的な差について同氏は、ID／クライアント登録から運用まで一連の流れを示して説明した。たとえば、ID／クライアントを登録する段階においてPingはOAuthクライアント、Entra IDはblueprintの子ID、Oktaはディレクトリ上のIDとして登録する。その後のAIに任せる仕事を人間が認証するフローはいずれも同じだが、その後のトークン発行方法、AIエージェントの認証／認可経路も三者三様である。

　また、AIエージェントが暴走した場合の制御方法も3つのソリューションで異なる。齊藤氏は「深夜2時、基幹データベースにAIエージェントがDELETEコマンドを投げつづける」という状況を例に挙げ、3つのソリューションで何が止まりどこに影響があるかという観点で違いを説明した。

　PingはアプリやAPIの手前に置くPingGatewayのルートを変更し、そこを通るリクエストを止める。Entra IDは個体そのものか、配下全体に効くblueprintを無効化する。OktaはAIエージェントを停止し、新たなトークンの発行を止める。ただし、経路上の遮断やエージェントの停止と、発行済みトークンやアプリ側セッションの失効は別の話で、どこまで連動して止まるかはいずれの製品でも構成次第だ。「どのソリューションを選ぶにしても、止め方は事前に人間が設計しておく必要がある」と齊藤氏は指摘する。

　そもそも、野良AIをどう止めるかという議論もある。「結論から言うと、基本的にID基盤だけでは野良AIを捕まえることはできません」と同氏は言い切る。発見の経路はID基盤、ブラウザ、管理下のSaaS、端末に分かれるため、ブラウザ管理やEDR、SASEを重ねる必要があるのだ。