AIエージェントの未来：ChatGPT Atlas を使ってみた

💡 ChatGPT Atlas を使ってみた

日本時間10月22日、OpenAIからChatGPTを搭載したAIブラウザー「ChatGPT Atlas」がローンチされました。エージェントモードがなかなか便利との話を巷で聞くため、実際に使ってみてのファーストレビューです。

🚀 エージェントモードの使い勝手を検証

普段のお買い物の例として「ユニクロオンライン」、会社の面倒くさい総務作業の一つである交通費精算の例として「楽楽精算」で試してみました。

✨　ユニクロでお買い物

「ユニクロオンラインにログインしてグレーのスウェットシャツを買って」と指示

ログインは自動で出来ないようで、ユーザー自身でのログインを依頼される。

自分でログイン後、「ログインしました」と送信。

かなり試行錯誤していて時間がかかりましたが、スウェットシャツがカートに追加されて購入手続きページに無事遷移。
検索でスウェットシャツを探したり、メニューから探したり、色々やってました。カートから購入手続きページに遷移する為のボタンを一発で探せずにかなり時間がかかってた感じ。

本当はセール中の「スウェットシャツ」が欲しかったのですが（笑）、「オーバサイズスウェットシャツ」になってました。。。この辺の精度は課題ですかね。

✨　ユニクロでコーデ提案

「MENsのトップスとボトムスのおすすめのトレンドの冬物を１着づつコーディネイトしてカートに追加して」と指示

補足でサイズはトップスはL、ボトムスはMと指示

商品は全く指示してませんが、いい感じに「パフテックパーカ」と「タックストレートパンツ/デニム」が追加されました。そのまま買おうかな（笑）

面白かった点

• ボトムスはMと指示したが、いい感じに76を選んでくれた。
• この指示をする前に、前回のスウェットシャツをカートから削除しておいたのですが、買い忘れがあると思ったのか勝手に追加してくれた（笑）。過去の会話履歴から判断しているようでかなり優秀。

📊　楽楽精算で交通費精算

毎回面倒な交通費精算を自動化できないか？

以下のように指示

• 楽楽精算（専用のURLを記載）にログインして、交通費精算で明細を追加して一時保存して
• 利用日は本日
• 豊田から多摩センターまで
• 往復は「往復」
• 経路は「通勤費（電車・バス）」
• 用件は『hogehoge」
  
  ログインは自動で出来ないようで、ユーザー自身でのログインを依頼される。
  
  自分でログイン後に続行してと指示しましたが、交通費精算ボタン押下後のポップアップ画面がでずここで断念。。。
  

ユニクロの場合はポップアップ画面が出た時もAtlasくんが操作できたのですが、Webページの作りによって違うのかも。

🎯　まとめ

• ユニクロの方は時間は掛かりましたが、いろいろ試行錯誤して正解にたどり着いてくれました。個人用にファインチューニングなどが出来れば推論時間も短くなるのかも。今後の精度Upに期待しましょう。コーディネイトなどは面白かったので他にもいろいろ試したいと思います。
• 現時点ではwebページの作りによって、操作が出来ないこともあるようです。今後、この辺りの問題はAtlas側の対応によって改善はされてくると思いますが、これからのAIエージェント時代に、Webページを作る側もこのようなエージェントを受け入れるのか（当然、リスクもある）？拒否するのか？の指針も課題になってくるのかなと思いました。

🧠　技術的評価：深掘りポイント

アーキテクチャ観点

• Atlas が「ブラウザ上のエージェントモード」でユーザ操作を模倣／補助するという構造を踏まえると、内部的には Web UIのDOM操作、要素探索・クリック・入力・遷移判断 といった機能を伴っていると推測できます。
• そのため、Web ページの構造に大きく依存。「UNIQLOオンライン」と「楽楽精算」の差異（UNIQLOは成功／楽楽精算が途中断念）も、「ページ設計（ポップアップ／iframe／SPA／非標準DOM）」による影響と考えられます。
• つまり、Atlas を業務自動化目的で使う際は「操作対象の Web UI がどう構築されているか」を事前に “可操作性 (操作者エージェント) の観点” からチェックする必要があると思われます。

依存技術例：

• WebDriver 風の動的操作技術
• VDOM や Shadow DOM, SPA 利用サイトへの対応（探査が難しいケースあり）
• 認証／2FA／ログインフロー：今回も手動ログインが必要だった点が課題。

適用可能性と制約

適用可能範囲として次のような条件下で成功率が高そう：

• ログイン済み・クッキー／セッション管理が安定しているページ
• 固定パターンの操作（検索→結果→カート→購入）など、変種が少ない。
• DOM要素が比較的シンプル・遷移が少ない構造。

制約・リスクとしては：

• 2FA／動的ロード／ポップアップUI等、エージェントが認識・操作できない構成では “断念” が起きうる：楽楽精算の例がこれに該当。
• 操作の“意図”と“要素マッチング”のズレ：例えば「セール中のスウェットシャツ」が欲しかったにもかかわらず「オーバーサイズ」が選ばれたという “精度” の課題。
• 権限・セキュリティ・誤操作リスク：意図しないボタン・誤購入など。
• 技術的には、「DOM要素をどう認識するか（ラベル／属性／位置／文脈）」という “要素探索” の強化が鍵。将来的には “画面キャプチャ→OCR／画像認識＋自然言語連携” のハイブリッドアプローチが増えると考えられます。

性能・UX観点

• レイテンシ／反応性が改善されることで、業務ユースで “待ち時間” が実用許容範囲内に入るかが鍵。
• UI遷移失敗時のフィードバック・ユーザ介入設計（手動ログインなど）も UX の “エージェント導入障壁” になります。