OpenAIは9ヶ月でAtlasを終了させた。このプロジェクトは、AIエージェント専用に構築されたブラウザを作るという野心的な試みだった。そこは、ソフトウェアが人間の入力を待つことなく、ウェブサイトにログインし、フォームを入力し、ウェブ上のタスクを実行できる場所を目指していた。現在、それらの機能はOpenAIのデスクトップアプリとChrome拡張機能へと移行している。実験は終わったが、そこから得られた教訓は痛烈だ。ユーザーは新しいアプリを求めているのではない。彼らがすでに使っているアプリが、より賢くなることを求めているのだ。
スタンドアロン・ブラウザの罠
Atlasは人のためのブラウザではなかった。エージェントのためのブラウザだった。理論上、その分離は理にかなっていた。クリーンな環境であれば、既存の拡張機能や乱雑なブックマーク、競合するスクリプトと戦うことなく、AIがビューポートを完全に制御できるからだ。エージェントは、人間のブラウジング習慣に邪魔されることなく、自由にナビゲートし、認証を処理し、ウェブページを操作することができた。
しかし、ユーザーはクリーンな環境で生活しているわけではない。パスワード、セッションクッキー、二要素認証のフロー、そしてマッスルメモリーは、Chrome、Edge、あるいはSafariの中に存在している。AIに代理で作業させるために、別のブラウザを開くよう求めることは、即座に障壁を生む。コンテキストスイッチングはコストが高い。リサーチ、メール、プロジェクト管理のためにすでに20個ものタブを使い分けているとき、エージェントに処理させるためだけに、慣れないサンドボックスへタスクをコピーすることなど、最も避けたいことだ。フローが途切れ、忍耐が尽きてしまう。
経費精算のような日常的な作業を考えてみよう。一般的な従業員は、Gmailから領収書を抽出し、それをカレンダーの予定と照らし合わせ、合計金額を企業のポータルサイトに貼り付ける必要がある。Atlas内で行う場合、これは未知のブラウザに認証情報を渡し、エージェントがこれら3つのサービスをすべて正しく処理してくれることを祈ることを意味した。一方、Chrome内であれば、拡張機能がすでに開いているGmailのタブを読み取り、その隣にあるカレンダーのタブを参照し、ユーザーが各入力を確認しながらポータルのフォーム入力を支援することができる。ユーザーは椅子から立ち上がることも、メインのブラウザから離れることもない。この日常的な摩擦の差こそが、人々が「仕方なく使うツール」と「見捨てられるツール」を分ける違いなのだ。
信頼には可視性が必要
Atlasはさらに深い問題も浮き彫りにした。完全に自律的なエージェントはまだ十分に信頼できるレベルにはなく、人々もそれを分かっている。AIがあなたの身元を使って銀行にログインしたり、納税フォームを提出したり、航空券を予約したりするとき、人はそれが何をしているのかを見たいと思う。Atlasはエージェントを独自のコンテナ内に隔離していた。「見えないものは、存在しないも同然」であることが多く、このケースでは、信頼を築くどころか、むしろ信頼を損なう結果となった。
エージェントは、いまだにボタンを読み間違えたり、フォームフィールドをハルシネーション（幻覚）したり、CAPTCHAでつまずいたりする。それが、普段使わないブラックボックスのようなブラウザの中で起こると、その失敗は異質なもの、信頼できないものと感じられる。機能をChrome拡張機能へと移行することで、OpenAIはエージェントをユーザーの通常の視界の中に持ち込んだ。拡張機能は、購入前に一時停止して確認を求めることができる。確信が持てないフィールドをハイライトすることもできる。タスクが機密性の高いものになったとき、ユーザーが操作権を握ることもできる。信頼は一度に与えられるものではない。人間が主導権を握り続ける、繰り返しのやり取りを通じて築かれるものだ。
セキュリティチームも同様に感じている。企業はブラウザのポリシーを管理し、拡張機能をホワイトリスト化し、ChromeやEdge内のツールの権限を監査している。Atlasのようなスタンドアロンのブラウザは、そうしたエコシステムの外部に位置する。IT部門は、それに対して標準的なセキュリティポリシーを簡単に適用することができない。Chrome拡張機能にシフトすることで、OpenAIは、コンプライアンス・フレームワークや権限モデルがすでに存在する環境へと滑り込むことができる。ツールが実際の企業内で採用されることを望むなら、これは極めて重要なことだ。
重要な3つのプロダクト・ルール
Atlasがわずか9ヶ月で終了したことは、現在AIツールを構築しているすべての人にとって、3つの厳しいルールを再確認させるものとなった。
プラットフォームの親しみやすさは、目新しさに勝る。 ユーザーに環境の切り替えを求めるのはやめよう。GitHub Copilotを見てほしい。それは開発者にIDEを離れるよう求めたのではなく、VS Code、IntelliJ、NeoVimの中に現れた。だからこそ、定着したのだ。Atlasはこれを無視した。開発者は、ユーザーが毎日業務を行っている場所に寄り添うべきだ。オーディエンスがSlackを使っているなら、Slack統合機能を作るべきだ。彼らがChromeでブラウジングしているなら、拡張機能を作るべきだ。目標は、習得すべき新しいインターフェースを作ることではなく、学習コストをゼロにすることである。
摩擦の少なさは譲れない条件です。 ダウンロード、サインアップ、移行といったステップが増えるたびに、普及の可能性は削がれていきます。Chrome拡張機能のインストールなら、2クリックと10秒で済みます。しかし、新しいブラウザをダウンロードし、ブックマークを移行し、デフォルト設定を変更し、ワークフローを調整するには、それよりも桁違いに多くの労力と注意が必要です。優れたAI機能とは、ユーザーがすでに使い慣れているソフトウェアのアップグレードのように感じられるものであり、管理すべき新しいソフトウェアであってはなりません。
信頼には明確なコントロールポイントが必要です。 ユーザーが求めているのは単なる自律性ではなく、ガードレール（安全策）です。Grammarlyが問題をアンダーラインで示し、ユーザーがそれを承認するか無視するかを待つ仕組みを考えてみてください。1Passwordが、ユーザーが意図的にアイコンをクリックしたときにのみパスワードフィールドを埋める仕組みを考えてみてください。成功しているツールは、その判断根拠を明示し、チェックポイントを提供します。エージェントはワークフローを支援すべきであり、それを乗っ取るべきではありません。Atlasは、新しい環境とリスクの高い自律性を組み合わせることで、あまりにも早く、あまりにも多くの信頼を求めすぎました。それは、ほとんどの人が準備できていない「二段跳び」を要求したのです。
市場はまだ調整段階にある
業界全体が、アプリ全体を置き換える完全自律型エージェントという夢を追い続けています。スタートアップは、人間が手を引いている間に職務全体をこなす「AI従業員」を頻繁に提案しています。しかし、Atlasはタイミングが間違っていることを証明しました。人々は、隔離された環境で動く目に見えないプロセスに、機密性の