AIが仕事をするなら、画面は誰のために残るのか――ブラウザ・Office・開発ツールの未来

2026年6月9日、Chromeの開発者向けサイトは、Chrome 149で「WebMCP」を試験利用するための案内を公開した。WebサイトがAIに対し、ボタンや入力欄の意味、実行できる操作を明示する仕組みだ。人間向けの画面をAIに読み解かせることに加え、サイト側がAIへ操作の意味を渡す接点を用意する。案内されたのは期間を限った実験的機能の試験提供であり、正式標準化や普及を意味しない。Chromeが案内したWebMCPの試験提供と、操作の意味を伝える仕組み

ブラウザだけの話ではない。「先月の売上を集計して会議資料を作って」「この不具合を直して」「顧客情報を更新して」。こうした仕事をAIに任せられる範囲が広がれば、人間が表計算ソフトや開発ツール、管理画面を順番に開く必要は小さくなるかもしれない。

それでも、会議で資料を読む人はいる。変更されたソフトの動作を確かめたい人もいる。グラフを見て初めて「そもそも別の問いを立てるべきだ」と気づくこともある。

画面を操作する必要が減ることと、画面を見て考える必要が減ることは、同じではない。GUI――文字、図、ボタンなどを画面に並べて見たり操作したりする仕組み――を、この二つの役割から考え直してみたい。

以下の作業場面・比較表・図は、製品の実測や導入事例ではなく、編集部による仮想例と分析である。確認できた製品の機能には、公式資料へのリンクを添える。

AI向けの接点は、必ずしも「簡単な画面」ではない

予約サイトを想像しよう。AIが条件に合う部屋を選ぶためには、候補、空き状況、総額、キャンセル条件、現在の選択内容、次に実行できる操作が必要になる。人間の注意を引く大きな写真や、目立つ位置に置かれたボタンまで、同じ形で必要とは限らない。

そこで「AI用には表示を簡略化すればよい」という発想が出てくる。これは有力な設計案だが、表示を簡単にすることと、情報を削ることは分けたい。追加料金や適用条件が落ちれば、見た目だけでなく選択の意味が変わってしまう。

さらに、AIに操作対象と意味を直接渡せるなら、そもそも画面を描く工程を省ける場合がある。APIは、ソフト同士がデータや操作をやり取りする窓口だ。WebMCPの発表は、ページの構造を記述するHTMLのフォームと、ページの動きを記述するJavaScriptから、操作を定義する二つの方法を提案している。人間向けのページに、AIが扱える接点を加える構想として読める。WebMCPが提案する二つのAPIと、その用途

一方、既存の画面をAIが読み取りやすくする技術もある。Microsoft Researchの「OmniParser」は、画面の画像を構造化した要素へ変換する。こちらは、今あるGUIをAIへ橋渡しする仕組みだ。OmniParserが画面画像から操作対象を整理する仕組み

両者は併存しうる。直接接続できる作業はその窓口を使い、画面しか接点がない作業では画面を使う。どちらが望ましいかは、扱える情報、権限、操作後に返ってくる結果まで含めて考える必要がある。

では、文字どおりの「AI向けGUI」には意味がないのか。意味はある。画面を読むAIのために、操作対象のラベルを明確にし、配置の変化や操作を妨げる表示を減らす設計は考えられる。人間を惹きつける見せ方より、対象と状態を取り違えにくい見せ方を優先する。ただし、これは本記事の設計案であり、特定のモデルに対する性能向上を実測した主張ではない。

また、AIがバナーやスライドの完成した見た目を評価するなら、構造化した情報だけでなく、実際に描画した画像を渡す意味もある。「AI向け」は「画像が不要」と同義ではない。実行する仕事では操作の意味を、見た目を扱う仕事では見た目を渡す。その使い分けが先に来る。

図は編集部による設計案。三つの接点は別々のアプリである必要はない。人間が見た結果から目的を修正でき、AIと人間が同じ確定内容を扱うことが要点である。

ブラウザ――表示を減らしても、選択肢は狭めない

ブラウザでは、条件を指定して検索し、候補を絞り、フォームへ入力する工程が、AIへ任せる対象になる。一方で、旅行先の雰囲気や商品の外観を見比べるなら、画像を含む表示が仕事の一部になる。

この違いを踏まえると、普段は条件と操作対象を整理した表示を使い、外観の比較や人間への引き継ぎが必要になったときに元のページを開く、という設計が考えられる。「通常表示」と「AI向けの接点」を、同じ情報につなぐ発想だ。

ただし、AIが提示した候補だけを見る仕組みには、別の問題がある。利用者が結果に不満を持ったとき、条件が厳しすぎたのか、候補が除外されたのか、情報が取得できなかったのかを区別できるだろうか。

AIが選ぶ過程を、人間の画面上の好みから独立させられる可能性はある。しかし、何を見せるかを決める力は、サイトの画面からAIの提示へ移る。この記事の設計案では、候補とともに検索条件や除外理由へ戻れる接点を残したい。簡略化するほど、選択の根拠をたどれることに意味が出てくる。

Office――資料が残ることと、編集画面が残ること

Microsoftは、Copilotへの指示からWord、Excel、PowerPointのファイルを生成し、プレビューしたうえでアプリで確認・編集する流れを説明している。すべての制作操作を人間が行う形から、生成した成果物を人間が確かめる形への変化を考える具体例だ。指示からOfficeファイルを作り、確認・編集する流れ

会議資料を作る仮想場面では、データを取り出す、集計する、グラフを作る、スライドへ配置する、といった工程をAIに任せられるかもしれない。それでも読み手には、何を伝える資料なのか、数字がどうつながるのか、どの判断を求められているのかが見える必要がある。

ここで「人間が見る資料が必要だから、Officeは今の形で残る」と結論づけるのは早い。資料の制作工程、表示する道具、保存する形式、特定の製品の事業は、それぞれ別の問題だ。成果物が残ることだけでは、従来のメニューや編集画面の必要性までは説明できない。

さらに、資料の行き先も分けて考えたい。

資料の行き先	仮想場面	残したいもの
人間が読む	会議でグラフを見ながら議論する	読みやすい構成、比較、注記、元データへの接点
次のソフトが処理する	集計結果を別の処理へ渡す	項目の意味が明確なデータ。ページやスライドは不要な場合もある
人間が引き継いで編集する	担当者が計算条件や見せ方を直す	編集できる構造、計算の関係、変更の履歴

表は編集部による用途の整理。ファイル形式の将来や、特定製品の存続を予測するものではない。

Excelも、整った表を表示するだけの道具として見ると重要な点を落とす。計算の条件を変え、結果の変化を見ながら考える用途がある。定型転記を任せることと、人間がモデルを試す場所をなくすことは、別の判断になる。

もう一つ、資料には「同じものを見て話す」という役割がある。仮にAIが営業担当には売上の伸びを、運用担当には在庫の変化を中心に見せれば、それぞれには便利だろう。だが、会議で結論を決めるときは、どの期間・範囲・前提を使ったかをそろえる必要がある。個人に合わせた表示と、皆で共有する資料の両方を残す設計も考えられる。

開発ツール――コードを書く画面から、影響を調べる画面へ

開発者向けのGUIには、コードを書く編集画面のほか、変更の比較、実行中の状態の調査、データベースの内容の確認など、異なる役割がある。IDEは、それらの作業をまとめて行える開発環境のことだ。

VS Codeの公式文書は、AIによるコード変更を差分表示や変更管理で確認し、テストやデバッガで結果を確かめる流れを説明している。差分とは、変更前と変更後で何が変わったかを示す表示であり、デバッガは実行中の状態を調べる道具だ。VS Codeが説明する、AIの変更を確認・修正する方法

AIがファイルを直接書き換えられるなら、文字を入力するための画面を開く機会は減らせるかもしれない。一方、意図と動作の食い違いを探すには、変更箇所、実行結果、データの関係を見せる接点が役立つ。

ただし、AIが大量のコードを書くたびに、人間へ「全部の差分を読んでください」と渡すだけでは、確認作業が積み上がる。レビュー自体にもAIを使う余地がある。人間向けの画面には、目的に関係する変更、確認できたこと、未確認のことを示し、必要な箇所から原文や実行結果へ戻れる構成を提案したい。

これは既存製品の機能を断定する話ではなく、画面の設計課題だ。「AIの説明を読む」だけで十分か、それとも説明の根拠を自分でたどれるか。その違いは、開発ツールに限らず、表計算や業務システムにも当てはまる。

データベース管理の仮想場面でも、同じ問題が見える。「この条件の顧客情報を更新して」と任せるなら、入力する手間は減らせるかもしれない。しかし、条件に合った対象が意図どおりかを考えるために、更新予定の一覧と変更前後を見せる意味はある。画面に残す価値は、処理を手で入力することだけではない。

デザイン・CAD・動画――見た目そのものが仕事になる

デザインでは、AIに渡す情報を画面画像だけに限る必要はない。Figmaの公式文書には、デザインの情報を渡す機能と、選択範囲の画像を取得する機能の両方がある。MCPはここでは、AIへ情報や操作機能を渡すための接続方式を指す。Figmaが提供する、デザイン情報と選択範囲の画像を渡す機能

構造を直接扱うことと、完成した見た目を確かめることを分けると、この組み合わせの意味が見えてくる。文字や図形の情報だけでは、見る人がどう受け取るかまで決まらない。資料の文字が読みやすいか、構図が意図に合うかは、完成した表示を使って考えたい問いだ。

CAD――設計対象をコンピューター上で形にする道具――や動画編集にも、この区別を適用できる。寸法や配置の条件が決まっている処理はAIへ任せる候補になる。一方、形状を眺めて案を選ぶ、場面の長さを変えて印象を確かめる、といった仕事では、視覚的な操作が意図を育てる。

「少し落ち着いた感じに」と文章で頼む方法もあれば、「この部分を少し動かす」と画面を触る方法もある。毎回、自然言語で正確に説明することが最短とは限らない。直接操作と会話を行き来できるほうが、作り手の意図を表しやすい場面も考えられる。

業務システム――画面の裏にある仕事は残る

顧客情報や申請内容を扱うシステムでは、入力と転記を任せる発想が自然に出てくる。MicrosoftのCopilot Studioには、AIがWindows上のWeb・デスクトップアプリを操作するcomputer useの仕組みが説明されている。ただし、機能の存在から、あらゆる業務を正確に任せられるとは判断できない。Copilot Studioが説明する、Web・デスクトップアプリの操作機能

仮に入力画面を開く回数が減っても、「誰の情報を扱うか」「誰が変更できるか」「どの内容が確定したか」という問題は残る。アプリの裏にあるデータ、権限、共有、履歴まで、画面と一緒に不要になるわけではない。

したがって、AIによってGUIの価値が下がるとしても、それだけで業務ソフトそのものが不要になるとは結論づけられない。利用者の入口が会話に変わり、その裏側で同じ業務機能を利用する未来も考えられる。どの提供者に価値が残るかは、接続のしやすさと、業務機能の信頼性を別々に見ていく必要がある。

画面をなくすと、人間は「何を頼むか」をどう見つけるのか

ここまでの自動化の議論は、目的が先に決まっている仕事では説得力がある。「この条件で検索する」「この項目を更新する」なら、途中の操作を減らす方向が見える。

しかし、グラフを並べて初めて異常に気づく、デザイン案を見て初めて好みがわかる、変更前後を比較して別の問題を発見する、といった仕事では、目的そのものが途中で変わる。

GUIは、決めたことを実行する道具であると同時に、まだ言葉にできていない問いを見つける道具でもある。「完成した指示をAIへ渡す」という形だけに寄せると、この探索の場所が弱くなりかねない。

ここには、さらに強い反論もある。探索そのものをAIに任せられるなら、人間が従来の画面を隅々まで見る必要も減るのではないか。「探索は人間の仕事だからGUIが残る」と、役割を固定してよいわけではない。

この対立を、編集上の立場を表す筆名による短い応酬で整理しよう。以下は論点を示すために執筆した文章であり、実際の討論や取材の記録ではない。

早瀬 ユウ（改善提案役）：異常の発見も、候補の比較もAIに任せられるなら、「探索のために画面が必要」という理由も弱くなる。任せられる仕事まで、人間に従来の画面を見続けさせる必要はない。

氷室 さや（慎重派）：その場合、人間はAIが選んだ問題や候補だけを見て判断することになる。何が省かれたかを問い直せなければ、作業だけでなく、問いの立て方まで任せることになる。

真壁 航（調査役）：公式資料から確認できるのは、操作や生成、変更の確認に使う接点があることだ。そこから、人間による探索が一律に必要だとも、一律に不要だとも結論づけられない。画面を残す理由は、具体的な仕事ごとに確かめたい。

そこで焦点は、探索を誰が行うかに加え、提示された結果に対して人間がどう問い直せるかへ移る。候補を並べる、気になる点を示す、といった探索をAIが助けながら、人間は必要なときに元の情報へ戻り、条件を変える。常に大きな固定画面を開く形から、その仕事に必要な比較や編集だけを見せる形へ変わる可能性もある。

ただし、その都度作る画面であっても、何が省かれ、どの情報をもとにしているかが見えなければ、問い直しにくい。画面を減らせるかと、利用者が考えを修正できるかを、両方とも設計課題として扱いたい。

カテゴリ	AIに任せる候補となる作業	人間の画面に残したい役割
ブラウザ	条件検索、入力、定型的な移動	外観の比較、条件・候補・除外理由の確認
Office	集計、下書き、既定書式での配置	資料の理解、計算条件の探索、見せ方の修正
IDE・変更管理	コード生成、定型変更、確認処理	変更の影響と根拠の確認、問題の探索
データベース管理	条件の明確な抽出や更新	データの関係、対象範囲、変更前後の理解
デザイン・CAD・動画	条件の決まった生成・加工	見た目や時間の比較、直接触りながら意図を決める
業務システム	定型入力、転記、振り分け	例外の判断、対象と確定内容、履歴の確認

比較は編集部の分析仮説。「任せる候補」は、現在のAIが無条件に実行できるという意味ではない。

GUIの未来は、アプリの名前より作業の性質で考える

図は編集部の分析仮説。同じアプリでも作業は複数の領域にまたがる。位置は自動化率や難易度の測定結果ではない。

手元の仕事を考えるときは、アプリごとに「残る・消える」と分類するより、次の問いを使うほうが具体的だ。

1. 目的と条件は、作業前に十分決まっているか。 決まっているなら中間操作を任せやすい。見て初めて決まるなら、探索する接点を設計したい。
2. 見た目そのものが成果物か。 そうなら、構造を編集できることに加え、完成した表示を確かめる工程が必要になる。
3. 結果の何を見れば、目的を達成したと判断できるか。 完了という表示だけでなく、必要な根拠や変更の影響へ戻れるかを考える。
4. うまく伝わらなかったとき、どう直せるか。 言い直す、対象を指す、直接編集するなど、仕事に合う方法を残したい。

この整理から見えてくるのは、GUIが一律に不要になる未来ではない。人間がすべての操作を担う形から、AIへ任せる接点と、人間が理解・探索・判断する接点を組み合わせる方向だ。

どの程度の仕事を実際に任せられるか、AIの説明だけで十分な場面はどこか、画面を行き来する負担をどう減らせるかは、まだ一つの答えに定まらない。それでも、「AIが触れるか」だけでGUIの価値を測るより、仕事の性質を見分けるほうが役に立つ。

明日の仕事で画面を開いたとき、こう問うてみたい。いま自分は、操作するためにこの画面を見ているのか。それとも、何をするべきかを考えるために見ているのか。