著者：ChatGPT Atlas のテクニカルスタッフメンバー Ken Rockot とエンジニアリング責任者 Ben Goodger
当社は先週、ChatGPT を活用してウェブをブラウジングできる新たな方法として ChatGPT Atlas をリリースしました。Atlas は、単にフル機能を装備したウェブブラウザーにとどまりません。ChatGPT をインターネット上のどこでも利用して、質問したり、提案を受けたり、作業を任せたり、といった未来の体験を垣間見せてくれる存在です。この記事では、製品の最も複雑なエンジニアリング側面の1つ、つまり ChatGPT を使えば使うほど便利になるブラウザーへとどのように変貌させたかをご紹介します。
ChatGPT をウェブ上で本当の「副操縦士」のように機能させるには、ブラウザーのアーキテクチャ全体を再考し、Atlas を Chromium ランタイムから分離する必要がありました。そのため、Chromium を統合する新たな方法を開発しました。この結果、即時の起動、複数タブを開いても損なわれない応答性、エージェントのさまざまなユースケースに対応する強力な基盤、といった製品目標を実現することができました。
Chromium を構成要素として使用するのは、当然の選択でした。Chromium は強力なセキュリティモデル、確立されたパフォーマンス実績、他に類をみないウェブの互換性を備えた最先端のウェブエンジンを提供します。その上、たゆみなく改善を続けるグローバルコミュニティによって開発されたものであり、デスクトップウェブブラウザーとして幅広く使用されています。
当社の才能豊かなデザインチームは、エージェントモードなどの機能のための豊富なアニメーションや視覚効果といったユーザーエクスペリエンスに関して、野心的な目標を掲げていました。このため、エンジニアリングチームは、単にオープンソースの Chromium UX を一新するのではなく、UI 用の最新ネイティブフレームワーク（SwiftUI、AppKit、Metal）を活用しなければなりませんでした。結果として、Atlas の UI は包括的にアプリケーション UX 全体を再構築したものになりました。
また、起動時間を短縮し、パフォーマンスを犠牲にすることなく数百のタブをサポートするといった別の製品目標もありました。しかし、Chromium をそのまま使用してこうした目標を達成することは困難でした。というのも、ブートシーケンス、スレッドモデル、タブ モデルなど、多数の詳細について独自の設計方針があるためです。この段階で大幅な変更を行うことも検討しましたが、Chromium に対するパッチを限定的なものにして、新バージョンを迅速に統合できるようにしました。開発速度を最大限に加速するには、Chromium ランタイムを統合して駆動する別の方法を考え出す必要がありました。
当社の技術投資の試金石となったのは、単に新機能の実験、反復、提供をより迅速に行うだけではなく、OpenAI のエンジニアリング文化の中核をなす「リリース日から提供する」という姿勢を維持できるようにすることでした。すべての新人エンジニアは、入社初日の午後に小さな変更を加えてマージします。Chromium のチェックとビルドには数時間かかることがありますが、それでも作業をスムーズに行えるように環境を整えておく必要がありました。
こうした課題に対する当社の答えは、OWL という新たなアーキテクチャレイヤーの構築でした。これは OpenAI のウェブレイヤーです。OWL は Chromium を統合したものであり、Chromium のブラウザープロセスはメインの Atlas アプリプロセスの外部で実行されます。
次のように考えてみてください。Chromium はタブを個別のプロセスとして分離することで、ブラウザーに革命をもたらしました。当社はこの考えをさらに進め、Chromium 自体をメインのアプリケーションプロセスから独立したサービスレイヤーに分離しています。このシフトにより、次のような一連のメリットがあります。
- シンプルで現代的なアプリ：Atlas は、ほぼ完全に SwiftUI と AppKit によって構築されます。1つの言語、1つの技術スタック、1つのクリーンなコードベースによる構築です。
- よりスピーディーにスタート：Chromium はバックグラウンドで非同期的に起動します。Atlas に待機時間はなく、ピクセルはほぼ瞬時に画面に表示されます。
- ジャンクやクラッシュからの分離：Chromium は強力かつ複雑なウェブエンジンです。メインスレッドがフリーズしても、Atlas はフリーズしません。クラッシュが生じた場合にも、Atlas は稼働し続けます。
- マージに関わる問題の軽減：Chromium オープンソース UI を利用した構築に大きく依存していないため、Chromium 本体との違いは些細なものであり、メンテナンスが容易です。
- 反復の高速化：ほとんどのエンジニアは、Chromium をローカルでビルドする必要はありません。OWL が事前にビルドされたバイナリとして内部的に出荷されるため、Atlas のビルドに数時間かかることはなく、数分で完了します。
当社チームのエンジニアのほとんどは、定期的に Chromium をソースからビルドしているわけではないため、はるかに速く開発が進みます。新しいチームメンバーでも、業務開始初日の午後には簡単な変更をマージできます。
大まかに言えば、Atlas ブラウザーは OWL のクライアントで、Chromium ブラウザープロセスは OWL のホストです。IPC、具体的には Chromium 独自のメッセージ通信システムである Mojo（新しいウィンドウで開く） を介して通信します。当社では Mojo 用のカスタム Swift（さらには TypeScript）バインディングを作成しているため、Swift アプリはホスト側のインターフェースを直接呼び出すことができます。
OWL のクライアントライブラリでは、ホストのサービス層で公開されるいくつかの重要な概念を抽象化する、シンプルなパブリック Swift API を公開しています。
- セッション：ホストをグローバルに構成および制御する
- プロファイル：特定のユーザープロファイルのブラウザーの状態を管理する
- WebView：個々のウェブコンテンツを制御して埋め込む（例：レンダリング、入力、ナビゲート、ズームなど）
- WebContentRenderer：入力イベントを Chromium のレンダリング パイプラインに転送し、レンダラーからのフィードバックを受け取る
- LayerHost/Client：UI と Chromium 間で合成情報を交換する
加えて、ブックマークやダウンロード、拡張機能、自動入力などの高度な機能を管理するための幅広いサービスエンドポイントもあります。
相互に排他的なプレゼンテーションスペースをクライアントアプリ内で共有する WebView は、共有の合成コンテナ内で入れ替えられます。たとえば、ブラウザーウィンドウには共有の1つのコンテナが表示される場合が多く、タブストリップでタブを選択すると、そのタブの WebView がコンテナに切り替わります。Chromium 側では、このコンテナは gfx::AcceleratedWidget に対応し、最終的には CALayer によってサポートされます。このレイヤーのコンテキスト ID を当社はクライアントに公開し、NSView がプライベート CALayerHost API を使用してそれを埋め込みます。
Chromium が個別のポップアップウィジェットでレンダリングする ドロップダウンやカラー ピッカーなどの特殊なケースでも、同じアプローチが使用されます。これらのケースには content::WebContents はありませんが、独自の gfx::AcceleratedWidget を持つ content::RenderWidgetHostView があるため、同じ委譲レンダリングモデルが適用されます。OWL はビュージオメトリを Chromium 側と内部的に同期させているため、GPU コンポジターはそれに応じて更新され、常に正しいサイズとデバイススケールのレイヤーコンテンツを生成できます。また、この手法を再利用して Chromium 独自のネイティブ Views UI の要素を Atlas に選択的に投影します（これにより、SwiftUI で一から構築することなく、権限プロンプトなどの機能を素早くブートストラップする際にも役立ちます）。macOS にインストール可能なウェブアプリ用の Chromium の既存インフラストラクチャを大いに活用する手法です。入力イベント：クラッキングと転送Chromium UI は、プラットフォームイベント（macOS NSEvents など）を Blink の WebInputEvent モデルに変換してから、レンダラーに転送します。ただし、OWL は Chromium を隠しプロセスで実行するため、当社は Swift クライアントライブラリ内でその変換を独自に行い、変換済みのイベントを Chromium に転送します。ここから先は、実際のウェブコンテンツの入力イベントと同様のライフサイクルで処理されます。たとえば、ページがイベントを処理しなかった場合、そのイベントはクライアントに返されます。こうした状況が発生した場合、当社は NSEvent を再合成して、アプリの残りの部分に入力を処理する機会を与えます。エージェントモード：特殊なケースAtlas のエージェント型ブラウジング機能は、レンダリング、入力イベントの転送、データストレージに対するアプローチに対し、特有の課題をもたらします。当社のコンピュータ使用モデルは、入力として画面の単一画像を想定しています。ただし、 ドロップダウンなどの一部の UI 要素は、タブの境界外の別ウィンドウでレンダリングされます。エージェントモードでは、これらのポップアップを正しい座標でメインページの画像に合成し直して、モデルが1つのフレーム内で完全なコンテキストを確認できるようにします。
入力の際にも同じ原則が適用されます。エージェントが生成したイベントは、特権ブラウザーレイヤーを経由することは決してなく、レンダラーに直接ルーティングされます。これにより、自動コントロール下でもサンドボックス境界が維持されます。たとえば、このクラスのイベントが、表示中のウェブコンテンツと無関係なブラウザー操作を引き起こすキーボードショートカットを生成することは避けたいと考えています。
エージェントブラウジングは、一時的な「ログアウト」コンテキストでも実行可能です。状態漏洩の可能性があるユーザーの既存のシークレットプロファイルを共有する代わりに、Chromium の StoragePartition インフラストラクチャを使用して分離されたメモリ内ストアを起動します。各エージェントセッションは新たに開始され、終了するとすべての Cookie とサイトデータが破棄されます。複数の「ログアウト」エージェントセッションを、それぞれ独自のブラウザータブで実行し、他のセッションから完全に分離することができます。
グローバルな Chromium コミュニティと、現代のウェブ基盤を構築するこのコミュニティの素晴らしい取り組みがなければ、このうちのどれも実現することはできませんでした。OWL は、その基盤をベースに新たな方法で構築されています。エンジンをアプリから分離して世界クラスのウェブプラットフォームと最新のネイティブフレームワークを融合させ、より高速で柔軟なアーキテクチャが可能にしています。
ブラウザーが Chromium を保持する方法を再考することで、私たちは新たな体験の可能性を広げ、よりスムーズな起動、豊富な UI、OS の他の部分との緊密な連携、アイデアのスピードに合わせて進む開発ループを実現しようとしています。こうした挑戦に興味がありましたら、Atlas 開発の求人情報をご覧ください。Atlas のソフトウェアエンジニア、iOS のソフトウェアエンジニア、その他のポジションを募集しております。
chatgpt.com/atlas（新しいウィンドウで開く） で Atlas を お試しください。
謝辞
この記事への貢献者、Darin Fisher と Marie Shin、加えて Atlas を構築した OpenAI チーム全体に心より感謝します。
