「社員名簿にいないAIを、誰が止めるのか：Oktaが築いたアイデンティティ帝国」（DeepDive: Okta）

DeepDiveはテクノロジー企業に特化したビジネスケーススタディシリーズ。Okta編では、Salesforce卒業生2人がクラウド時代のアイデンティティ管理を立ち上げ、ゼロトラスト、Auth0、侵害対応、Microsoftとの競争、AIエージェント時代へ進むまでを1本で扱う。成功譚ではなく、「信頼の基盤」を売る会社が、自分自身の信頼をどう守り直したかの記録として読んでほしい。

Abstract

社員名簿にいないAIを、誰が止めるのか。

2026年のOktaが出した問いは、派手なAIビジョンではない。自社環境のどこにAIエージェントがいるのか、何に接続でき、何をしてよいのか。組織の88%がAIエージェント関連のセキュリティインシデントを疑うか確認している一方、AIエージェントを独立したアイデンティティ主体として扱う組織は22%にとどまる。人間ではないが、アクセス権を持つ主体が増えている。

原点は、臆病なPowerPointだった。Salesforceのエンジニアリング担当幹部だったTodd McKinnonは、第一子、1型糖尿病、リーマンショック後の景気後退を抱えながら起業を考えていた。妻を説得する資料の趣旨は、「なぜ私は狂っていないか」。夢ではなく、貯蓄、失敗時の戻り道、資金調達できない場合の分岐が並んでいた。

共同創業者Frederic Kerrestと始めた最初の会社は、OktaではなくSaaSureだった。クラウド監視の反応は鈍い。だが雑談になると、SaaSが増えすぎてパスワードとアクセス権限が壊れている、という痛みが何度も出た。Xactlyの400ドルの注文書と「5社ライブ」は、契約ではなく運用が動き始めた証拠だった。

FY2026のOktaは年間売上29億1,900万ドル、年間契約額10万ドル超の顧客5,100社まで大きくなった。Todd McKinnonは価値の核を「unified identity platform」と呼び、対象を「humans to AI agents」まで広げている。SSOの会社ではなく、境界が溶けた世界で誰を信頼するかを決める会社として読むと、Oktaの問いは創業時と同じ形で戻ってくる。市場がまだ小さく見えるとき、あなたは「いま痛い問題」だけを見るのか。それとも、次の10年で信頼の前提がどこへ移るかを見るのか。

プロローグ：2026年、AIエージェントにも社員証が必要になる

2026年4月30日、Okta for AI Agentsが一般提供に入った。Oktaが提示した問いは、拍子抜けするほど実務的だった。原文では「where are my agents」「what can they connect to」「what can they do」である。自社環境のどこにAIエージェントがいるのか。そのエージェントは何に接続できるのか。そのエージェントは何をしてよいのか。

この3問は、人間の社員管理なら当たり前に聞かれてきた。誰が入社したのか。どのアプリにアクセスできるのか。どの権限まで許すのか。だがAIエージェントになると、多くの企業はこの当たり前を失う。業務部門が勝手にエージェントを作り、開発者がAPIキーを渡し、営業支援エージェントがCRMを読み、サポートエージェントが顧客情報に触れる。人間ではないが、アクセス権を持つ主体が増殖する。

Oktaが2026年3月に示した調査では、組織の88%がAIエージェント関連のセキュリティインシデントを疑うか確認している。一方で、AIエージェントを独立したアイデンティティ主体として扱う組織は22%にとどまる。多くの企業では、「働いているが社員名簿に載っていない存在」が、すでに社内システムへ入っている。

一般提供時点で、OktaはYahooとRampを初期事例として掲げた。OktaはこれをAIエージェントを発見・保護・統制する「single control plane」と説明する。Yahooは従業員、パートナー、非人間エージェントまでを同じID面で管理する方向を示し、Rampは、MCPサーバーやAIエージェントが複数の業務アプリへ接続する前提で、誰の責任で動くか、どの権限で動くか、いつ止めるかを追える設計を採っている。AIエージェントIDは未来の抽象論ではなく、すでに運用設計の問題になっている。

この局面で、Oktaの原点は奇妙に戻ってくる。2009年、同社が見つけた痛みは、SaaSが増えすぎて人間のパスワード管理が壊れることだった。2026年の痛みは、AIエージェントが増えすぎて非人間のアクセス管理が壊れることだ。主語は人からエージェントへ変わった。だが問いは同じである。境界が溶けた世界で、誰を信頼するか。

この問いにたどり着くまで、Oktaは何度も自分の前提を壊してきた。最初の社名すら、間違っていた。

第1章：「なぜ私は狂っていないか」

2008年末、Todd McKinnonはSalesforceにいた。

彼はエンジニアリング組織を率い、Salesforceの急成長を内側から見ていた。クラウドソフトウェアは、もはや実験ではなかった。企業はオンプレミスのソフトウェアを自社サーバーに入れるのではなく、ブラウザから使うようになっていた。AWSもGoogle Appsも立ち上がりつつあった。仕事の場所は、会社のネットワークの内側から、インターネット上のサービス群へ移っていた。

それでも、起業のタイミングとしては最悪だった。

リーマンショックの直後で、資本市場は冷え込んでいた。Toddには生まれたばかりの子どもがいた。さらに1型糖尿病の診断を受け、健康保険や家計の現実は重かった。安定した大企業の役職を捨てるには、あまりに悪い条件が揃っていた。CNBCが引用する当時の本人の見立ては、逆に「perfect time to start a new tech company」だった。

だから彼は、妻を感動させる資料を作らなかった。

作ったのは、失敗を見積もる資料だった。起業する理由、家計の持続可能期間、資金調達できなかった場合、早期に買収された場合、長期で会社を続けられた場合。それぞれの分岐を、事前に書き出した。

これは、Oktaの最初の経営思想だったと言っていい。

起業家の勇気は、恐怖を見ないことではない。恐怖を数字にし、家族と共有し、最悪の着地点を見たうえで、それでも前に進むことだ。ToddのPowerPointは、夢の資料ではなく、撤退条件つきの賭けだった。

共同創業者になったのは、Frederic Kerrestである。彼もSalesforce出身だった。営業と事業開発の経験を持ち、MIT SloanでMBAを取得し、ベンチャーキャピタル側も見ていた。Toddがエンジニアリングとプロダクトの人なら、Fredericは顧客と市場の人だった。

2人は親友として始めたわけではない。Salesforce時代に互いを知り、共通のネットワークから信頼を確認できる距離感だった。近すぎず、遠すぎない。これは共同創業では重要である。起業直後の会社は、友情の強さより、役割の違いと信頼の検証可能性を必要とする。

2009年、2人は会社を始めた。

名前はOktaではなかった。

第2章：SaaSureは、ほとんど誰にも刺さらなかった

最初の会社名はSaaSureだった。

SaaSとassuranceを掛け合わせた名前である。売ろうとしていたのは、クラウドサービスの信頼性やパフォーマンスを監視する仕組みだった。SalesforceやGoogle AppsのようなSaaSが増えるなら、IT部門はサービスの遅延、障害、ユーザー体験の劣化を監視したくなるはずだ。

仮説としては、悪くない。

だが、顧客の反応は鈍かった。否定されるなら、まだいい。強い否定は痛みの裏返しであることがある。SaaSureが受けたのは、もっと危険な反応だった。便利そうですね、いつか必要かもしれません、検討します。こうした生ぬるい言葉は、たいてい買わないという意味である。

ところが、見込み客との会話の終わりに、別の話題が何度も出た。

パスワードだった。

社員が使うSaaSが増えている。入社時にアカウントを作るのが大変だ。退職者のアクセス権を消し忘れる。Salesforce、Google Apps、Box、Zendesk、社内アプリ、それぞれでログインが違う。IT部門は、ユーザー名とパスワードと権限の組み合わせに追われている。

Okta自身も後年、この時期を「fledgling company called SaaSure」と振り返り、2人が見込み客と「spoke with prospects one-on-one」しながら、顧客が本当に求めるものを探したと説明している。つまり、ピボットは会議室の戦略ではなく、顧客会話の熱量から生まれた。

SaaSureの本題には熱がない。雑談のパスワードには熱がある。

この差が、ピボットを生んだ。

優れたピボットは、創業者のひらめきだけで起きるのではない。顧客が、こちらの提案とは別の場所で同じ痛みを繰り返すときに起きる。2人は監視サービスを捨て、クラウドID管理へ向かった。

2010年4月、会社はOkta, Inc.として再法人化された。Oktaは気象観測で使われる雲量の単位で、空を8等分して雲が覆う割合を表す。クラウドの世界を測る会社には、皮肉なくらい合っていた。

2人は「クラウド」という大きなテーマまでは捨てなかった。捨てたのは、クラウド監視という最初の実装である。ビジョンは残し、問題設定を変えた。創業初期に必要なのは、信念を曲げないことではない。どの信念は守り、どの仮説は捨てるかを分けることだ。

Oktaの中心ジレンマは、ここで形になる。

クラウドが増える世界で、監視の会社になるのか。アクセスの会社になるのか。

前者は、SaaSの状態を見る会社だ。後者は、SaaSを使う人間の信頼を決める会社だ。2人は後者を選んだ。

もしあなたがこの時点の創業者なら、何を捨てるだろうか。目の前の監視プロダクトを磨くのか。便利なログインツールに留めるのか。それとも、まだ小さく見えるクラウドIDを、次の10年の信頼制御層として取りに行くのか。

第3章：400ドルの注文書と「ライブ」の重さ

2009年末、最初の顧客が現れた。

Xactlyである。セールス報酬管理のSaaS企業だった。創業者回想では、最初期の発注額は400ドルとされる。大きな契約ではない。むしろ、上場企業の歴史に残すには小さすぎる数字だ。

だが、創業期の会社にとって、400ドルは市場からの最初の署名だった。

見込み客が「いいですね」と言うことと、発注書を出すことの間には深い谷がある。Xactlyはその谷を越えた。だからToddは、その発注書を家族に見せた。最初の売上が立った、と。

ただし、ここで終わらないのがB2Bインフラの厄介さである。

契約したことと、使われることは違う。Xactlyは発注したが、すぐに全社でOktaが動いたわけではない。実際のユーザーがOkta経由でログインし、IT管理者が日々の運用を回し、入退社の権限管理が変わって初めて、プロダクトは「買われた」ではなく「使われた」になる。

Oktaが2010年に置いた目標は、売上額ではなかった。Todd McKinnon自身も後年、初年度の中心目標は「5社をライブにする」ことだったと説明している。ライブとは、契約書が存在する状態ではない。顧客の環境でSSOが動き、社員が毎日ログインし、IT部門がOktaを前提に業務を回している状態である。これは営業の仕事だけでは達成できない。プロダクト、導入支援、統合、サポート、顧客成功が一体にならなければならない。

この時期のOktaが見つけたもう一つの武器が、統合カタログだった。

顧客に、どのSaaSを使っているかを聞く。まだカタログにないアプリなら、作る。必要なら翌日までに作る。Salesforce、Google Apps、Box、Zendesk、その他の業務アプリを、顧客ごとに統合していく。この地味な積み上げが、後のOkta Integration Networkになる。

2026年時点で、Okta Integration Networkは8,000を超える既製統合を掲げている。だが、その原型は「そのアプリも明日までに繋ぎます」という創業期の約束だった。

スタートアップの初期PMFは、綺麗なダッシュボードに出ない。400ドルの発注書、5社をライブにする泥臭さ、夜通しで統合を書く約束。そういう小さな証拠の束として現れる。ここまでが無料範囲で見えるOktaの原型だ。契約ではなく、運用が変わるところまで行って初めて、信頼の置き場所は動き始める。