AI ブラウザのサイトツール:ChatGPTで反復作業を減らす

ChatGPT WorkとCodexがデスクトップアプリ内のAI ブラウザでWebMCPサイトツールを使う仕組みを解説します。利用条件、現場別の活用例、5ステップのテスト手順、20週間の投資回収例、安全性と技術上の制約まで整理。繰り返し発生するWeb作業で導入効果が見込めるか、実測データから判断する方法がわかります。

Monday, September 7, 2026Omid Saffari
AI ブラウザのサイトツール:ChatGPTで反復作業を減らす

ChatGPTのサイトツールがAI ブラウザで導入コストに見合う価値を生むのは、対応するWebサイト上の同じ操作が、実装費を回収できるほど繰り返される場合だけです。2026年8月31日OpenAIChatGPT WorkとCodexに、デスクトップアプリの内蔵ブラウザ上で、Webサイトが提供するアクションを別途接続せず直接使える仕組みを追加しました。

AI ブラウザでサイトツールは何を変えるのか

通常のブラウザエージェントは、人向けに作られたページを見て、どのボタンを操作すべきか判断し、クリックや文字入力で画面を動かします。サイトツールでは、ページ自体が構造化されたアクションをエージェントに渡します。

いわば、もう1つのメニューが用意されるようなものです。人にはボタンやフォームが見えます。一方、アシスタントには、名前の付いたアクション、その実行に必要な情報、動かすべきコードが簡潔な一覧で提示されます。

Webサイトは、クライアント側のJavaScript関数をエージェント用ツールとして公開するWeb標準案、WebMCPを介してアクションを登録します。ツールには、名前、平易な説明、入力項目を定義するスキーマ、実行関数に加え、読み取り専用か、信頼できない内容を返すか、重大な結果を伴う操作かを示すヒントを持たせられます。現在のWebMCPドラフトはCommunity Groupの報告書であり、完成したW3C標準ではありません。

実務上の違いは次のとおりです。

方式アクションの提供元向いている用途主な制約
ブラウザでのクリックと文字入力ChatGPTが画面上のインターフェースを解釈サイトツールがないページページレイアウトに左右される工程が増える
WebMCPサイトツール開いているWebページが構造化アクションを登録現在のページとログイン済みセッション内での作業ページ側のツール提供が必要で、ページを開いておく必要がある
バックエンドMCP接続サービスがサーバー側の独立したツールを公開開いている特定ページに依存させたくない作業専用の接続とサービス側の実装が必要

WebMCPとバックエンドMCPは、ツールスキーマといった用語こそ共通していますが、相互に置き換えられるものではありません。WebMCPはブラウザネイティブのクライアント側ルートです。仕様上、ブラウザはMCP、独自の関数呼び出し、または別の方式を通じてページのツールをエージェントへ渡せます。WebMCPプロジェクトも、バックエンド統合の代替ではなく補完手段と位置付けています。

この違いは、サイトツールとChatGPT Computer Historyの役割も分けます。Computer Historyは、承認済みの操作を記録し、後から作業を見つけて呼び出せるようにする機能です。サイトツールは、Webページがその場で意図的に提供する、呼び出し可能なアクションです。

アカウント、モデル、開いているWebページの3条件をすべて満たして初めてChatGPTがサイトツールを使えることを示す粘土細工風の解説場面
サイトツールが表示されるのは、アカウント、選択中のモデル、現在のWebページがすべて対応している場合だけです。

ChatGPT デスクトップアプリならユーザー側の準備を減らせる

対応ページを使う側は、別途コネクタをインストールする必要がありません。ChatGPTデスクトップアプリのブラウザでページを開き、必要ならその場でログインすれば、ChatGPTがページ上の利用可能なアクションを検出できます。

ただし、準備そのものがなくなったわけではありません。担い手がWebサイトの運営者側へ移っただけです。

プロダクトチームは依然として、有用なアクションの選定と登録、入力の検証、既存アプリケーションロジックの呼び出し、画面表示の更新、エラー処理、権限経路のテストを担います。その代わり、同じページ内の仕事のためにエージェント向けバックエンドを別に作らなくても、現在のページ状態とログイン済みセッションを再利用できます。

ビジネス上重要なのはこの点です。サイトツールは、1度実装すれば繰り返し発生する画面移動やフォーム操作を減らせますが、効果があるのは対応するページとアクションに限られます。一致するツールを公開していないWebサイト、アクセス権のないアカウントやモデル、ページを閉じた後も動かす必要があるワークフローには役立ちません。

通常のChat、Work、Codexのどれを選ぶべきかは、ChatGPT Workのレビューで、成果物ごとに適した利用画面を解説しています。

誰が、どのように使えるのか

ブラウザ型タスクボードを使うオペレーション責任者

プロダクトチームは、稼働中のタスクページに既存の「フォローアップを追加」アクションを1つ公開できます。オペレーション責任者が、会議で合意した対応事項を追加するようChatGPTに頼み、各項目を確認すると、同じ画面にタスクが表示されます。

効果は、繰り返しの画面移動を減らせることです。検証は引き続きサイトが担い、画面に表示された記録がオペレーターの確認場所であることも変わりません。

ダッシュボードで対応するサポート責任者

サポート製品では、表示中の顧客情報に絞った検索アクションと、社内メモを更新する別のアクションを公開できます。責任者はダッシュボードを開いたまま、該当アカウントの背景情報を探してメモを準備するようChatGPT Workに依頼します。

複雑な画面をたどる時間を短縮できるのが利点です。権限の境界が明確になるよう、読み取りと書き込みのアクションは分けておくべきです。

カートを確認するEC運用担当者

OpenAIは、サイトツールが対応する作業の一例としてショッピングカートの更新を挙げています。EC運用担当者は、ログイン済みのページ上でカートを調整するようChatGPTに頼み、購入前に結果を確認できます。

手作業を減らせる一方、購入は重大な結果を伴うため、引き続き確認が必要です。

コードレビューページを使うエンジニアリング責任者

WebMCPプロジェクトは、コードレビュー画面をユースケースの1つとして紹介しています。ページ側は独自のアプリケーションコードを通じて、ステータス確認、障害の詳細、修正案の提示といったアクションを公開できます。Codexは障害を調べ、提案する変更を目に見えるレビュー画面へ反映できます。

価値は、自動でマージすることではありません。複雑なページ状態から、レビュー可能な提案へ至るまでの経路を短くすることです。

ChatGPT ブラウザでユーザーワークフローを検証する方法

OpenAIのサイトツールガイドには、アクセス可否を画面上で確かめる方法が示されています。ページが対象かどうかを推測する必要はありません。

  1. 1. 対応するブラウザを開く

    macOSまたはWindowsのデスクトップアプリで、ChatGPT WorkかCodexから内蔵ブラウザを開きます。Chrome拡張機能ではサイトツールを利用できません。

  2. 2. ページを開いてログインする

    アクションを提供するページへ移動します。内蔵ブラウザは独自のブラウザ状態を保持するため、Chromeのログイン状態が引き継がれない場合があります。

  3. 3. アドレスバーを確認する

    灰色の矢印が表示されれば、サイトツールを利用できます。矢印を選ぶと、そのページのツールと、各ツールが情報を読み取るものか変更を加えるものかを確認できます。ChatGPTがツールを使っている間、矢印は青色になります。

  4. 4. 範囲を限定したアクションを1つ依頼する

    得たい結果と、操作対象のレコードを明示します。最初のテストは、画面上で結果を確認できる1つのアクションに絞ります。

  5. 5. アクセス権と結果を確認する

    求められたら、Webサイトとのやり取りを承認します。購入、削除、権限変更、個人データの共有、メッセージ送信など機密性の高い操作の前には、ChatGPTが改めて確認を求めます。

矢印が見当たらなければ、アカウント、選択中のモデル、現在のWebページという3つの条件のいずれかを満たしていません。OpenAIの現行ガイドにはプランとモデルの正確な互換表がないため、曖昧な利用可否の説明を調達判断に結び付けるべきではありません。実際に導入するアカウントとモデルで確認してください。

導入前に投資回収を計算する

計算式はシンプルです。

単純回収期間(週)=実装コスト ÷ 1週間当たりの人件費削減額

製品発表時の主張ではなく、実測した作業時間を使います。ここで参照した一次資料には、サイトツールによる時間短縮のベンチマークはありません。

この試算には、アシスタントの利用料、保守、セキュリティレビュー、エラー処理、誤った書き込みによるコストが含まれていません。導入を承認する前に、それらも計上してください。チームがまだサイトツールの対象でない場合は、実際に展開するアカウントとモデルでアクセスできることを確認してから、増分のアカウント費用を加えます。

採算を最短で改善する方法は、ツールの数を増やすことではありません。実行頻度が高く、入力が安定し、人が結果を確認できるアクションを1つ選びます。大量のツールを並べると、モデルのコンテキストを多く消費し、ツールの取り違えも起きやすくなります。

ChatGPT 自動化とは異なる――正直に押さえておくべき制約

サイトツールはページにひも付きます。ChatGPTは複数のタブをまたいで作業できますが、ツールはそれを提供するページに属します。そのページを閉じればツールも使えなくなります。埋め込みコンテンツだけが公開するツールには、現在対応していません。

また、これはバックグラウンド自動化システムではありません。WebMCPは、Webページを中心に人が関与しながら協調して進める作業のために設計されています。ページを開かず無人で実行する必要があるなら、バックエンド統合や通常のアプリケーションAPIの方が適しています。

仕様案は今も変化しています。宣言型のフォームベースAPIは現行ドラフトでも未完成で、エラー、検証、ドキュメントをまたぐ処理には未解決の点が残っています。測定可能な成果を生む最小限の範囲で実装し、継続的な保守を見込んでください。

今すぐ動くべき人、待つべき人、影響を受けない人

今週動くべきなのは、Webサイトを管理しており、ページ内の同じ操作が頻繁に発生し、その操作を担う明確な関数がアプリケーションにすでにあり、人が結果を確認できるチームです。条件はこれだけで、範囲を限定した試験導入を始められます。

必要なモデルやプランでアクセスが表示されない、有用なアクションが埋め込みコンテンツ内にある、ページを開いたままにできない、あるいは作業の頻度が低くリスクが高い場合は待つべきです。標準が新しいというだけでは、初期費用を回収できません。

サイトツールを公開していない第三者のWebサイトを使うだけなら、影響はありません。ChatGPT側からアクションを追加することはできません。通常のブラウザ操作が役立つことはあり、サーバー側の作業なら独立したMCP接続が適している場合もあります。

月曜日にまずやること

チームが管理するWebサイトから、繰り返し発生する操作を1つ選びます。先週の実行回数を数え、通常の作業を5回計測し、残すべき人の確認作業を書き出してください。まず読み取り専用ツール1つに範囲を絞り、デスクトップの内蔵ブラウザでテストします。そのうえで、実測した回収期間が社内ソフトウェアに普段適用している予算期間に収まる場合だけ、次の段階を承認します。

AIの新機能を実務でどう判断するか、平易な解説を受け取りたい方はニュースレターにご登録ください。

最終更新

2026年9月7日

カテゴリーExplained

Googleでこのサイトを優先する

omidsaffari.comをGoogle検索の優先ソースに追加

omidsaffari.comを優先ソースに設定すると、GoogleがTop Stories・AI Overviews・AI Modeであなたのために優先表示します。

Explainedの他の記事

Explainedの記事をすべて見る
ニュースレター

毎週日曜、一通の手紙。 動くシステムの話。感想戦ではなく。

AIベンチャーのポートフォリオ運営から生まれるビルドログ、稼働中のシステム、現場ノート。

週刊。スパムなし。いつでも解除できます。