AIエージェントは、ソフトウェアの使い方をどう変えるのか

ソフトウェアの形が変わる

これまでのソフトウェアは、人が画面を開いて使うことを前提に作られてきました。ブラウザから利用する業務ソフトウェア、いわゆるSaaSでも、利用者は顧客管理、会計、文書作成などの製品を行き来し、それぞれのメニューや入力方法を覚えます。仕事の目的を、各製品の操作手順へ翻訳していたのは人でした。

AIエージェントが担うのは、この翻訳と実行です。人が『更新が止まっている重要商談を調べ、会議で判断できる資料を作り、送信前に確認を求めてください』と伝えると、エージェントは必要な情報と操作先を探し、複数の処理をつないで結果を作ります。人が製品名や画面の順番を細かく指定しなくても、仕事を進められるようになります。

この変化で人間が不要になるわけではありません。顧客情報、契約、在庫、会計などを正しく保つ仕組みも消えません。中心ではなくなるのは、人が一つずつ画面を開き、操作することを前提にした『アプリ』という見え方です。ソフトウェアの機能は裏側に残り、人から見える入口が、製品の一覧から仕事の依頼へ変わります。

エージェントはどう動くのか

AIエージェントとは、人から目的を受け取り、現在の状態を調べ、使える道具を選び、実行結果を確認しながら仕事を進めるシステムです。文章を作る大規模言語モデル（LLM）だけを指すのではありません。モデルの周囲に、ファイルやブラウザを扱う機能、外部サービスへ接続する機能、権限、操作履歴、人へ確認を求める仕組みが組み合わされています。

たとえば『今月動きのない重要商談を調べ、次回会議の資料を作る』という依頼を考えます。最初にエージェントは、何をもって完了とするかを整理します。対象はどの顧客か、数字はいつの時点か、資料はどの形式か、メール送信まで任されているのかを確認し、不明点が結果を左右するなら人へ質問します。

次に、顧客管理システムから商談を探し、メールや議事録から最近の動きを集め、在庫や納期が関係する案件では別のシステムも確認する、という作業へ分けます。そのうえで、利用できる接続先と権限を調べます。読み取りだけ許された場所へ書き込もうとしたり、送信の許可がないのにメールを送ったりしないためです。

実行するときは、いきなり全件を変更するのではなく、小さな単位で動かして結果を確かめます。顧客番号が一致しているか、取得件数は妥当か、作った表の合計は元データと合うかを確認し、想定と違えば検索条件や操作方法を変えます。失敗したときに同じ操作を繰り返して二重登録しないことや、途中から再開できることも必要です。

最後にエージェントは、作った資料だけでなく、参照した情報、変更した内容、判断できなかった点をまとめます。メール送信や顧客データの更新など、外部へ影響する操作の前で人へ承認を求め、承認後の実行結果も記録します。エージェントの動きは、計画を一度作って終わる直線ではなく、『確認する、選ぶ、実行する、検証する、必要ならやり直す』という繰り返しです。

画面以外の操作口

エージェントがソフトウェアを使う方法は、画面上のボタンを押すことだけではありません。ソフトウェア同士がデータや命令を直接やり取りする公式の窓口をAPIと呼びます。黒いターミナル画面へ文字の命令を入力してプログラムを動かす方法は、CLI、つまりコマンド操作です。どちらも、画面を目で追うより入力と結果が明確で、大量処理や再実行に向いています。

100件の顧客情報を更新するなら、画面へ100回入力するより、APIへ対象と変更内容をまとめて渡し、返ってきた100件分の結果を検査する方が速く、間違いも追いやすくなります。開発作業では、ファイル検索、テスト、バージョン管理などを文字の命令で組み合わせられるCLIが有効です。

Model Context Protocol（MCP）は、エージェントが『どの道具があり、何を渡せば使えるか』を共通の形式で知るための接続規格です。MCP自体が顧客情報を更新するわけではありません。MCPの先にあるAPI、データベース、ファイル操作などが実際の処理を担当します。たとえるなら、APIやコマンドが個々の道具で、MCPは道具の名前、用途、使い方を同じ書式で並べる道具箱です。

エージェントは、まずこのような入力と結果が明確な操作口を探します。使えない場合はブラウザの内部構造を利用し、それでも届かない場所だけ画面認識とマウス操作へ進みます。どれか一つの方式だけを使うのではなく、正確さ、権限、処理時間、失敗したときの戻しやすさを見ながら選び直します。

図を原寸で開く

ブラウザを内側から使う

Webページは、人には一枚の画面として見えますが、ブラウザの中では見出し、入力欄、送信ボタン、表などが意味を持つ部品として組み立てられています。この部品の並びをブラウザが扱える木構造にしたものがDOMです。エージェントは画像の座標だけでなく、この構造から『送信という名前のボタン』や『合計金額のセル』を探せます。

Chrome DevTools Protocol（CDP）は、Chromeの開発者向け機能がブラウザとやり取りするための遠隔操作用の通信規約です。開発者がChromeの検証画面で確認できるページ構造、通信内容、エラー、JavaScriptの実行などを、別のプログラムから扱えるようにします。エージェントにとっては、画面を撮影して数字を読み取る前に、ブラウザへ正確な文字や通信結果を問い合わせるための入口になります。

読み上げソフトなどがページを理解するために使う『アクセシビリティツリー』も利用できます。これは、見た目の装飾を減らし、『これは見出し』『これは入力欄』『これは押せるボタン』と役割を整理した情報です。Vercel Labsが公開するagent-browserや、MicrosoftのPlaywrightが提供するエージェント向けコマンド機能は、こうした構造を使って要素を選びます。

ブラウザが裏側で送っている通信を観測し、同じ処理を直接呼び出すことも技術的には可能です。ただし、公式APIがあるならそちらを優先すべきです。画面内部だけで使われる非公開の接続先は、ログイン状態やページの実装に依存し、予告なく変わります。操作できることと、業務で安全に使い続けられることは別です。

CloudflareのKitesurf

Kitesurfは、インターネット基盤を提供するCloudflareが、AIエージェント向けに開発しているブラウザエンジンです。ブラウザエンジンとは、Webページを読み込み、HTMLや画像を解釈し、JavaScriptを動かす中核部分を指します。Kitesurfは、質問に答えたり操作手順を考えたりするAIエージェントそのものでも、一般の利用者がタブやブックマークを使って閲覧する完成品のブラウザでもありません。

Cloudflareが狙っているのは、エージェントが短いWeb処理を大量に実行する用途です。人が一日中開いて使うブラウザでは、幅広い機能や互換性が必要になります。一方、エージェントが数十秒だけページを開いて情報を取得する処理を何千件も動かすなら、一回ごとのCPUとメモリを小さくする価値が大きくなります。Kitesurfは、その用途に合わせてブラウザの中核を作り直す試みです。

KitesurfはCDPから制御できるため、すでにCDPへ対応している自動操作ツールを接続できます。ここでCDPの説明が効いてきます。エージェントはKitesurfの見た目を操作するのではなく、CDPという遠隔操作口を通じて、ページを開く、構造を読む、通信を確認するといった処理を行います。

この例が示すのは、エージェント向けソフトウェアでは、人が見る外枠より『必要な処理を軽く、観測可能な形で動かせるか』が重要になるということです。ただし、性能や互換性に関する説明はCloudflare自身によるものであり、あらゆるWebサイトで既存ブラウザを置き換えられることが独立に確認されたわけではありません。

画面操作が必要な場面

構造化された操作口がないソフトウェアでは、エージェントも人と同じ画面を使います。画面画像をAIへ渡し、クリック、スクロール、キー入力を返させ、その結果の画面をもう一度確認させる方法は、一般にComputer Useと呼ばれます。OpenAIやGoogleなどが、この方式を使うモデルや開発機能を提供しています。

この方法の強みは、専用APIがない古い業務システム、デスクトップアプリ、地図、画像編集、グラフなどにも届くことです。一方、画面画像を何度もAIへ送るため、処理する情報量と費用が増えます。ボタンの位置が変わる、ポップアップが出る、読み込みが遅れるといった変化にも影響されます。

そのため、画面操作は何にでも使える最初の手段というより、他の操作口から届かない部分を埋める手段になります。ページの構造から正確に読める文字は構造から取得し、地図の位置関係や画像の状態など、見なければ分からないものだけ画像認識へ渡す方が効率的です。

二つの使いやすさ

これからの業務ソフトウェアには、人が理解して判断するための画面と、エージェントが安全に実行するための操作口が並びます。人向けの画面では、目的の指定、変更前後の差、根拠、承認、例外への対応が見やすいことが重要です。エージェント向けの操作口では、利用できる処理、必要な権限、入力形式、成功と失敗の理由が機械から明確に読める必要があります。

同じ依頼を再送しても二重登録しないこと、実行前に変更予定を確認できること、途中から再開できること、誤った変更を取り消せることも重要です。これは人向け画面の美しさとは別の『使いやすさ』です。エージェントが迷わず、結果を検証でき、失敗を限定できる設計と言い換えられます。

Cloudflare OSは、Cloudflareが発表したエージェント、社内ツール、文書作成などをまとめる作業プラットフォームです。名前にOSとありますが、WindowsやmacOSのようなパソコンの基本ソフトではありません。利用者が会話からエージェントへ仕事を頼み、必要に応じて画面と操作用のAPIと保存データを持つ小さなアプリを作れる構想です。Gatekeeperと呼ぶ仕組みを通じて、社内の文書やシステムへどの範囲で接続できるかを管理します。

ServiceNowは、申請、承認、パスワード再発行、入社準備などの業務手順を管理する企業向けソフトウェアです。同社は、外部のAIエージェントがServiceNowの画面を開かずに業務手順を呼び出せる仕組みを発表しています。画面なしで動かすことを技術文書ではheadlessと呼びますが、処理そのものは既存の権限、承認経路、操作記録に従います。画面を省いても、業務の統制まで省くわけではありません。

図を原寸で開く

いまのSaaSという形の終わり

ここからは筆者の見立てです。SaaSが提供してきた顧客管理、会計、契約、在庫管理などの機能は残りますが、それらを製品ごとの画面に束ね、人がログインして使い分ける現在の形は中心ではなくなる可能性があります。人が見る『ソフトウェアの一覧』が、エージェントから見る『利用できる機能の一覧』へ溶けていくためです。

利用者は、顧客管理ソフトを開いて検索し、表計算へコピーし、資料作成ソフトへ貼り付ける代わりに、必要な成果を伝えます。裏側では顧客管理、在庫、文書作成、メール送信の機能が使われていても、利用者はすべての製品名や画面遷移を意識しないかもしれません。ソフトウェアは、利用者が訪れる場所から、エージェントが呼び出す業務能力へ近づきます。

画面が完全になくなるわけではありません。人は、目的を伝え、候補を比較し、変更差分を確認し、送信や購入を承認し、例外を判断するために画面を使います。ただし、その画面は一件ずつ入力する作業場所ではなく、任せた仕事を監督して責任を引き取る場所になります。

したがって『SaaSは残る』とだけ言うのも、『ソフトウェアはなくなる』とだけ言うのも正確ではありません。裏側の記録、業務ルール、権限、処理機能は残り、その価値はむしろ上がります。一方で、人が製品単位の画面を操作する現在のソフトウェアの形は、見えにくくなり、別の形へ組み替えられていきます。

エージェント同士の分業

一体のエージェントが営業、在庫、法務、会計の知識と権限をすべて持つ必要はありません。人の組織と同じように、窓口となる調整役が仕事を分け、それぞれの領域に必要な権限だけを持つ専門エージェントへ依頼する構成が考えられます。

たとえば営業資料を作る調整役は、在庫担当のエージェントへ納期確認を頼み、法務担当のエージェントへ契約条件の確認を頼めます。在庫担当は在庫システムを使い、法務担当は契約文書を調べます。調整役は返ってきた回答と根拠を一つの資料へまとめ、外部送信の直前で人へ承認を求めます。

Agent2Agent Protocol（A2A）は、このようなエージェント間の業務依頼を共通化するための通信規格です。相手が何をでき、どこへ接続し、どんな認証が必要かを示す情報は、デジタルな名刺に相当します。長い仕事には追跡番号を付け、進捗を知らせ、完成した文書やデータを成果物として返します。仕様ではこれらをAgent Card、Task、Status、Artifactと呼びますが、役割は『相手を探す、仕事を頼む、進み具合を知る、納品物を受け取る』です。

MCPとA2Aは役割が違います。MCPはエージェントがデータや道具を使うための接続で、A2Aは別のエージェントへ仕事を委ねるための接続です。道具箱を開くことと、別の専門家へ業務を依頼することの違いに近いでしょう。どちらの規格も、相手の判断が正しいことや、必要な権限だけを使うことまでは保証しないため、依頼元での検証と承認は残ります。

図を原寸で開く

人に残る目的と責任

Anthropicが約40万件のClaude Code利用記録を分析した研究では、典型的な利用で、人が計画に関する判断の約70％を担い、AIが実行に関する判断の約80％を担っていました。これは開発作業の利用記録を基にした分析で、あらゆる仕事にそのまま当てはまる数字ではありません。それでも、人が『何を、どの状態まで行うか』を決め、エージェントが『どのファイルや道具を使い、どう進めるか』を多く決める分担を示しています。

人に残るのは、目的、優先順位、品質基準、例外判断、承認、最終的な責任です。顧客へ何を約束してよいか、価格より納期を優先するか、法的に曖昧な条件を受け入れるかは、単に操作ができるだけでは決められません。エージェントが提案を作れても、組織として引き受ける判断は人が担います。

操作を任せるほど、仕事を学ぶ仕組みも見直す必要があります。これまで若手は、ソフトウェアへ入力し、例外にぶつかり、先輩へ確認する過程で業務を覚えてきました。操作だけを消すと、その学習機会も消えます。エージェントが何を調べ、なぜ判断を人へ戻したかを見られることが、教育の面でも重要になります。

任せられる範囲

エージェントが操作できることと、安心して任せられることは同じではありません。長い仕事では小さな誤りが積み重なり、Webページや文書に書かれた悪意ある指示を、利用者からの命令と取り違える危険もあります。取得した情報の出所を残し、重要な数字を別の方法で照合し、想定外の指示を実行しない仕組みが必要です。

権限は仕事に必要な範囲と時間へ絞るべきです。読む、下書きする、試算する処理と、送信、購入、削除、公開、送金する処理を同じ扱いにしてはいけません。外部へ影響する直前で人へ確認し、実行前の予定、実行後の結果、誰の代理で何をしたかを記録し、必要なら止めて戻せる設計が欠かせません。

AIエージェントが普及しても、人間が消えるのではありません。変わるのは、人がソフトウェアの操作係である時間です。現在のSaaSやアプリの形は薄れ、裏側の機能をエージェントが組み合わせるようになります。その上で人は、何を実現するか、どこまで許可するか、結果を正しいと判断できるかを担います。