タグアーカイブ AIエージェント

VS Code 1.121が公開、AIエージェントのターミナル連携とモデル管理が進化

VS Code 1.121が公開、AIエージェントのターミナル連携とモデル管理が進化

マイクロソフトは2026年5月20日、コードエディタ「Visual Studio Code」のバージョン1.121を公開した。今回のリリースでは、Copilot Chatが備えるエージェント機能とターミナルとの連携部分に多くの改良が加えられている。

具体的には、ツール呼び出しの表示が見やすくなり、特定のLLMモデルをピン留めして素早く選択できる仕組みが追加された。加えて、長いテストやビルドの出力を自動で圧縮する範囲が大幅に拡大され、エージェントが生成するコマンドの実行効率と可読性が一段と向上している。

開発者のワークフローに与える影響は小さくない。ターミナルに流れるログ情報が整理され、エージェントが勝手にバックグラウンド処理に移行するタイミングが賢くなったおかげで、より思考の流れを途切らせずに済むのだ。本記事ではこれらの改善点を実務的な視点で掘り下げていく。

エージェントホストの操作性向上

エージェントホストの操作性向上

まず目を引くのが、エージェントホスト内でのツール表示まわりの改善だ。Copilot Chatのエージェントモードでは、AIが「ファイルを読む」「ターミナルでコマンドを打つ」などのツールを自律的に呼び出す。今回のアップデートで、それらのツール名がより直感的な表示になった。

これまでは内部的で分かりにくかった呼称が、人間にとって理解しやすい「ファイル読み取り」「コマンド実行」といったラベルに置き換わっている。入力と出力のUIも再設計され、どのツールに何を渡し、何が返ってきたかが一目で追えるようになった。エージェントの行動をレビューしたり、デバッグしたりする局面で役立つ変更だ。

自動承認ピッカーとワークスペースの事前選択

もうひとつ、エージェントホスト接続時の「自動承認ピッカー」が追加された。外部のエージェントホストへ接続する際に、あらかじめ信頼できるものを選んでおける仕組みで、毎回承認操作を求められる煩わしさが減る。

また、VS Codeを既に特定のワークスペースで起動している場合、エージェントウィンドウを開くとそのワークスペースのフォルダが自動で事前選択される。手動でプロジェクトフォルダを指定し直す手間が不要になるため、作業開始時のリズムが良くなる。小さな改良だが、1日に何度も繰り返す操作だけに、開発効率への積み重ね効果は意外と大きい。

Before
ツール表示:run_in_terminal (何をするツールか直感的に分からない)
エージェント起動時:フォルダ未選択の状態 (手動で毎回選ぶ必要がある)
After
ツール表示:コマンド実行(ターミナル) (ツールの役割がラベルからすぐ分かる)
エージェント起動時:現在のワークスペースが自動選択 (操作を1ステップ省略できる)
変更前   変更後

上の図は、ツール表示とワークスペース選択の流れをビフォーアフターで示したものだ。変更前は開発者がエージェントの内部的な動きを読み解く必要があったが、変更後は視覚的に整理され、作業開始時の手数も減っている。

モデル管理の進化と「お気に入り」機能

モデル管理の進化と「お気に入り」機能

続いて、言語モデルピッカーに「ピン留め」機能が追加された。これは、よく使うモデルをお気に入り登録して、ドロップダウンリストの上部に固定する機能だ。

現在、VS CodeのCopilot Chatでは複数のAIモデルを切り替えて使える。コーディング向きのモデル、自然言語のやり取りに向いたモデル、軽量で反応が速いモデルなど、タスクに応じて選び分ける開発者も多い。ピン留め機能により、毎回リストをスクロールして探すストレスから解放される。

環境変数「VSCODE_AGENT」の追加とその効果

Copilot Chatがターミナルでコマンドを実行する際、専用の環境変数「VSCODE_AGENT」がセットされるようになった。この変数は、AIが起動したターミナルセッションであることを明示的に示すためのものだ。

実務では、シェルのプロンプト表示を変えたり、エージェント向けのログフォーマットを自動判別したりする用途に使える。たとえば、AI用のターミナルでは冗長なカラー表示をオフにして、パースしやすいテキスト出力に切り替える、といった使い方が考えられる。自分でシェル初期化ファイルをカスタマイズしている開発者にとっては、自動化の可能性が広がる嬉しい追加だ。

チャットと統合ブラウザの連携強化

チャットと統合ブラウザの連携強化

統合ブラウザ(Simple Browser)で表示中のWebページを、ワンクリックでCopilot Chatに共有できる「Add to Chat」オプションが右クリックメニューに追加された。

VS Codeの統合ブラウザは、エディタ内でドキュメントやAPIリファレンスを閲覧するのに使われる。今回の機能で、例えばReactの公式ドキュメントを開きながら「このセクションの内容を要約して」とAIに投げる操作が、ドラッグやコピーペーストなしで完結する。Web上の情報をコーディングの文脈にスムーズに取り込めるのは、エディタを離れずに作業を続けたい開発者にとって大きな利点だ。

また、チャットエージェントが内部的に生成したバックグラウンドターミナルは、コマンド完了後に自動で破棄されるようになった。これにより、使われないプロセスが蓄積してシステムリソースを圧迫するのを防げる。エージェントがテストの実行や依存関係のインストールなどを一括操作した後、きれいに後片付けされるイメージだ。

統合ブラウザ活用フロー
📄 ドキュメント閲覧 🖱️ 右クリックでAdd to Chat 💬 Copilot Chatに内容共有 📝 エディタでコード生成
バックグラウンドターミナルのライフサイクル
エージェントがコマンド実行 バックグラウンドターミナル生成 コマンド完了後に自動破棄 (不要なプロセスが残らない)

これらの改善は、AIアシスタントを「裏方」として使う際の体験を底上げする。情報収集からコード生成、実行、後始末まで、一連の流れに無駄がなくなっていく方向性だ。

ターミナルツールの出力処理が大幅に改善

ターミナルツールの出力処理が大幅に改善

今回のリリースで最も実務的なインパクトが大きいかもしれないのが、ターミナルツールの出力圧縮まわりの拡張だ。

エージェントがテストランナーやビルドツールを実行すると、膨大なログが出力され、チャット画面が埋め尽くされることがある。この問題に対応するため、出力圧縮(冗長な行を折りたたみ、重要な結果だけを強調表示する仕組み)の対象が一気に広がった。

圧縮対象が大幅に拡大されたコマンド群

新たに対象となったのは、以下のツール群だ。

  • テストランナー: pytestjestcargo test
  • ビルドツール: tsc(TypeScriptコンパイラ)、cargo buildmake
  • リンター類
  • Docker関連コマンド
  • パッケージマネージャ(npm、yarn、pipなど)

これらのツールが出力する長大なログから、本当に必要なエラー行やサマリーだけを抽出し、チャット画面上ではコンパクトに表示してくれる。テストが数千件走っても、失敗したケースだけに集中できるわけだ。

アイドルサイレンスタイマーで同期実行を自動バックグラウンド化

ターミナルツールには、同期コマンドが一定時間まったく出力を返さない場合に、自動的にバックグラウンド実行に切り替える「アイドルサイレンスタイマー」が導入された。設定した時間内に何の進捗も表示されなければ、AIエージェントはそのコマンドをバックグラウンドに回し、別のタスクに取り掛かれる。

従来は、長時間かかる処理が走っている間、エージェントの思考がブロックされがちだった。この機能は、CI/CDパイプラインや重いデータベースマイグレーションの待ち時間中に、エージェントが他の作業を並行して進められるようにするものだ。

従来の同期実行
$ pytest –long-suite
(数千行のログが流れる)
エージェントは完了まで他の操作ができない
1.121での改善
$ pytest –long-suite
出力が折りたたまれ、エラー行のみ表示
一定時間出力なし → 自動でバックグラウンド化
ブロックされていた時間   他の作業を並行実行できる

アイドルサイレンスタイマーは設定可能なため、プロジェクトの特性に合わせて閾値を調整できる。テストが沈黙するのはバグではなく重い処理の前触れ、というチームなら長めに取ればいい。

マルチラインコマンドの修正とConPTYの最新化

エージェントホストのターミナルツールでは、複数行にまたがるシェルコマンドの実行時に問題が発生することがあったが、今回のアップデートで修正された。bashやPowerShellでループや条件分岐を含むスクリプトを生成させるケースで、従来は行の継続が正しく解釈されないバグに遭遇することがあった。この修正によって、AIが生成した複数行スクリプトの信頼性が高まっている。

さらに、Windows環境向けに、擬似ターミナルAPIの基盤となるConPTY(conpty.dll)の新しいバージョンがVS Code本体に直接バンドルされるようになった。これまではシステム側のバージョンに依存しており、古いWindowsではターミナルの描画に問題が出ることがあった。バンドル化により、VS Code側で一貫したターミナル挙動を保証できるようになった。

SSH接続におけるキーボード対話認証のサポート

SSH接続におけるキーボード対話認証のサポート

最後に、エージェントホストがSSH接続する際に、キーボードインタラクティブ認証(パスワード入力やワンタイムパスコードの要求を含む対話形式の認証)がサポートされた。多要素認証が求められるサーバーや、接続時に追加の質問が表示される環境でも、エージェントホスト経由の自動接続が可能になったわけだ。

セキュリティ要件が厳しい本番環境や、企業ポリシーで対話認証を強制されているサーバーに対して、Copilot Chatのエージェントを遠隔操作するハードルが下がる。VS Code Remote Developmentの既存ユーザーにとっては、よりシームレスにAI支援を組み込めるようになる変更だ。

エージェントホストのSSH認証フロー
🔑 SSH接続試行 🔐 キーボード対話認証(OTP・質問応答) ✅ 接続確立
※従来はキーボード対話認証が未対応で、多要素認証が必要なサーバーではエージェントの遠隔接続に支障があった
認証試行   接続成功

この機能は、特にDevSecOpsの文脈で歓迎されそうだ。開発環境と本番環境を明確に分離しつつ、AIアシスタントの支援を安全に受けられる選択肢が増えたことを意味する。

この記事のポイント

  • VS Code 1.121ではAIエージェントのツール表示が見直され、入力と出力の可読性が向上した
  • モデルピッカーにお気に入りのピン留め機能が追加され、切り替え操作が高速化した
  • ターミナル出力の圧縮対象が拡大され、テストやビルドのログがコンパクトに表示される
  • アイドルサイレンスタイマーにより、長時間コマンドの自動バックグラウンド化が可能になった
  • SSHのキーボード対話認証サポートで、よりセキュアな環境へのエージェント接続が容易になった
AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に

AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に

AWSは2026年5月6日、AIエージェント向けのマネージドサービス「AWS MCP Server」の一般提供を開始した。AIコーディングアシスタントがAWSの各種サービスを安全に呼び出し、最新ドキュメントを参照し、必要ならサンドボックス内でスクリプトを実行できるようになる。

これまではAIエージェントがAWSを操作しようとしても、訓練データが古く、IAMポリシーが過剰になりがちだった。本サーバーはそうした課題を解決し、本番環境でも使えるレベルのインフラコード生成を後押しする。

本記事ではAWS MCP Serverの機能、GAで追加された新要素、具体的な利用手順、対応ツール、料金までを詳しく解説する。

AWS MCP Serverの概要

AWS MCP Serverの概要

MCP(Model Context Protocol)は、AIエージェントが外部サービスやツールと安全にやり取りするための標準プロトコルだ。AWS MCP Serverはこのプロトコルに準拠したマネージド型のリモートサーバーであり、数個の固定ツールを通じて1万5000を超えるAWS APIへのアクセスを提供する。

AIコーディングアシスタントは多くの場合、訓練データに依存するため、2025年後半以降に登場した新サービス(Amazon S3 VectorsやAurora DSQLなど)を知らない。また、インフラ構築時にAWS CLIを好み、AWS CDKやCloudFormationといったIaCツールを使わない傾向があった。生成されるIAMポリシーも権限が広すぎるなど、デモ用には動いても本番投入は難しい状態だった。

従来のAIエージェントによるAWS操作
訓練データは数カ月前の知識のみ。AWS CLIを直接実行し、過剰なIAM権限を要求。最新サービスを認識できない。
AWS MCP Serverを経由した操作
エージェントはMCPサーバーに問い合わせ。最新ドキュメントを検索し、IAM認証を通じて最適なAPIを実行。サンドボックスでスクリプト処理も可能。
call_aws search_documentation run_script

この仕組みにより、AIエージェントは常に最新の情報と最小権限でAWSリソースを操作できる。ツールの数が少なく固定されているため、モデルのコンテキストウィンドウを圧迫せず、ハルシネーション(誤った回答の生成)も抑えられる。

GAで追加された主な機能

GAで追加された主な機能

プレビュー期間を経て正式提供となったAWS MCP Serverでは、以下の機能が新たに導入されている。

IAMコンテキストキーのサポート

従来はMCPサーバー自体の利用に専用のIAM権限が必要だったが、今回からIAMコンテキストキーに対応した。これにより、通常のIAMポリシーの中で「特定のユーザーは更新系APIを許可、MCPサーバー経由では読み取り専用」といったきめ細かい制御が可能になる。余分な権限管理の手間が減り、セキュリティ設計がシンプルになる。

ドキュメント検索の認証不要化

search_documentationおよびread_documentationツールが、認証なしでも利用できるようになった。これにより、まだAWSアカウントを持っていない段階でも、AIエージェントは最新のAWSドキュメントを参照して設計や調査を行える。

トークン消費の最適化

インタラクションあたりのトークン消費量が削減された。マルチステップのワークフローを伴う複雑なタスクでは、モデルのコンテキストウィンドウがすぐに埋まりがちだったが、今回の改善でより長い会話を維持しやすくなっている。

run_scriptツールとサンドボックス実行

run_scriptツールとサンドボックス実行

GAの大きな目玉がrun_scriptツールの追加だ。AIエージェントは短いPythonスクリプトを記述し、MCPサーバー側のサンドボックス環境で実行させることができる。このサンドボックスは呼び出し元のIAM権限を継承するが、ネットワークアクセスは一切持たない。つまり、エージェントはAWSリソースのデータを処理できるものの、ローカルのファイルシステムやシェルには触れない。

Before run_script(APIを逐次呼び出し)
エージェントが複数のAPIを1つずつ呼び出し、その都度応答を解析。レイテンシが増大し、コンテキストも大量に消費する。
After run_script(サンドボックスで一括処理)
エージェントがPythonコードを生成し、サーバー側で複数APIをチェーン実行。結果は1回の応答で返るため、高速かつコンテキスト効率が良い。
import boto3

# 複数APIを組み合わせた処理を1回のラウンドトリップで

従来、エージェントが複数のAPIを呼び出してデータを結合する場合、1つずつリクエストを送っては応答を待つ必要があり、時間もトークンも浪費していた。run_scriptを使えば、1回のラウンドトリップで一連の処理を完結させられる。これにより、処理速度とコンテキスト効率の両方が大幅に向上する。

Skillsによるベストプラクティスの提供

Skillsによるベストプラクティスの提供

プレビュー版では「Agent SOPs」という形式でガイダンスが提供されていたが、GAではより洗練された「Skills」に移行した。Skillsは、エージェントがよく間違えるタスクに対して、AWSの各サービスチームがメンテナンスする検証済みのベストプラクティスを提供する。

スキルにより生成されるコードの品質が安定し、エラーやトークンの無駄も減る。ツール一覧を短く保ちつつ、必要なガイダンスをピンポイントで渡せるため、エージェントの挙動が予測しやすくなり、無駄な試行錯誤も抑制される。

Skillsライブラリのイメージ
EC2 インスタンス設計の勘所
S3 バケットポリシーの安全設定
CDK プロジェクト構成のテンプレート
Lambda 関数の権限制御
エージェントはタスクに応じて最適なスキルを参照し、検証済みのコードや設定を生成する。

エンタープライズの現場では、開発者の数だけ書き方がバラバラになりがちだが、Skillsによってサービスチーム公認のパターンがチーム全体に自然と浸透する。結果として、セキュリティレビューの工数も削減できるだろう。

セキュリティと監査の仕組み

セキュリティと監査の仕組み

AWS MCP Serverは、ユーザーが直接操作する時とAIエージェント経由の操作を明確に区別できる設計になっている。IAMポリシーやSCP(Service Control Policies)を使って、特定のユーザーには全操作を許可しつつ、MCPサーバーには読み取り専用のみ許可する、といった制御が可能だ。

さらに、AWS-MCP名前空間のAmazon CloudWatchメトリクスが提供され、MCPサーバー経由のAPIコールと人間による直接のAPIコールを分離して監視できる。AWS CloudTrailもすべてのAPI呼び出しを記録するため、コンプライアンスチームが求める監査証跡を完全な形で確保できる。

監視ダッシュボードの概念
人間の操作
1,245 calls
MCPサーバー経由
867 calls
CloudWatchメトリクスで分離表示。CloudTrailには全ログが残る。

このように、AIエージェントが安全にインフラを操作できる環境が整ったことで、これまで人間の開発者しか触れなかった本番環境へのAI活用も現実味を帯びてきた。

利用方法と対応ツール

利用方法と対応ツール

AWS MCP Serverは、MCPに対応するあらゆるAIコーディングツールから利用できる。Claude Code、Cursor、Kiro、OpenAI Codexなど、主要なアシスタントはすでにサポートしている。

セットアップは非常にシンプルだ。AWS MCP ServerはIAM SigV4認証を利用するが、多くのMCPクライアントはOAuth 2.1のみに対応している。そのため、オープンソースの「MCP Proxy for AWS」を使ってIAM認証をOAuthにブリッジする。具体的には以下のようなコマンドで設定する。


curl -LsSf https://astral.sh/uv/install.sh | sh
claude mcp add-json aws-mcp --scope user \
   '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'
設定後の動作確認イメージ
AIアシスタント上で/mcpコマンドを実行すると、AWS MCP Serverが利用可能なツール一覧が表示される。
あとは「S3にベクトルデータを保存する方法は?」と尋ねるだけで、エージェントがsearch_documentationツールを呼び出し、最新のS3 Vectorsの情報をもとに回答を生成する。

プロキシはローカルマシン上で動作し、MCPサーバーのエンドポイントとしてhttps://aws-mcp.us-east-1.api.aws/mcp(米国東部)または欧州(フランクフルト)のリージョナルエンドポイントを指定する。APIコール自体は他の全リージョンに対しても実行可能だ。

料金と提供リージョン

料金と提供リージョン

AWS MCP Server自体に追加料金は発生しない。支払うのは、AIエージェントが操作した結果として作成されたAWSリソースの利用料と、データ転送料金のみだ。このため、まずは試験的に導入し、効果を検証しやすい。

現在の提供リージョンは米国東部(バージニア北部)と欧州(フランクフルト)の2拠点。今後、他のリージョンにも順次拡大される見込みだ。

AWS MCP Serverはすでに多くのAIコーディングアシスタントで利用可能であり、AWSドキュメントの最新ページからクイックスタートガイドを参照できる。

この記事のポイント

  • AWSがAIエージェント向けのマネージドMCPサーバーを一般提供開始
  • call_aws、search_documentation、run_scriptの3ツールでAWSを安全に操作
  • run_scriptはサーバー側サンドボックスでスクリプトを一括実行し高速化
  • SkillsによりAWSチーム公認のベストプラクティスをコード生成に活用可能
  • IAMとCloudTrail/CloudWatchで人間の操作とAIの操作を明確に分離監査
  • サーバー利用料は無料、リソース使用量のみの課金。米国東部と欧州で提供開始
Amazon WorkSpacesがAIエージェント専用デスクトップを提供開始

Amazon WorkSpacesがAIエージェント専用デスクトップを提供開始

企業がAIエージェントを本格導入しようとすると、大きな壁に突き当たる。基幹業務を支える既存のデスクトップアプリケーションやレガシーシステムは、最新のAPIを備えていないことがほとんどだ。2024年のGartnerレポートによれば、75%の組織がモダンなAPIを持たないレガシーアプリを運用しており、Fortune 500社の71%は十分なプログラムアクセス手段のないメインフレーム上で重要プロセスを動かしている。

AWSはこの課題に対して、新しいアプローチを発表した。2026年5月5日、Amazon WorkSpacesがAIエージェントに対して安全なデスクトップ環境を提供する機能をプレビュー公開した。これにより、アプリケーションの改修やAPIの新規開発なしで、AIエージェントが既存のデスクトップアプリケーションを人間と同じように操作できるようになる。

レガシーアプリケーションの課題とAI導入の壁

レガシーアプリケーションの課題とAI導入の壁
従来のアプローチ(Before)
AIエージェントAPI接続が必要レガシーアプリ(直接操作不可)アプリのモダナイズが必須
※ 多くの企業ではコスト・リスクが高く、AI導入の足かせに
WorkSpacesの新しいアプローチ(After)
AIエージェントWorkSpaces仮想デスクトップレガシーアプリをクリック・入力・スクロールで操作
※ アプリケーション側の改修は一切不要。既存のセキュリティポリシーも維持

従来は、AIエージェントが業務システムと連携するには、アプリケーション側にAPIを実装するか、RPAによる擬似的な操作を行うしかなかった。いずれも大がかりな作業とメンテナンスを伴い、特に規制産業では監査やセキュリティ面でハードルが高かった。WorkSpacesの新機能は、仮想デスクトップという“もう一つの画面”をAIエージェントに渡すことで、この問題を一気に解消する。

WorkSpacesがAIエージェントに提供するもの

WorkSpacesがAIエージェントに提供するもの

この新機能の核は、人間用に管理されてきたWorkSpaces環境を、AIエージェントにも安全に割り当てられるようにした点にある。エージェントはAWS Identity and Access Management(IAM)で認証され、WorkSpacesへ接続する。操作はすべてAWS CloudTrailとAmazon CloudWatchで監査ログが残り、既存のセキュリティ制御やコンプライアンスポリシーがそのまま適用される。

また、業界標準のModel Context Protocol(MCP)に対応しているため、LangChainやCrewAI、Strands Agentsなど、さまざまなAIエージェントフレームワークから利用できる。特定のSDKに縛られない設計は、企業の既存AI基盤に組み込みやすい。

AWSのブログ記事では、Nuvens ConsultingのディレクターChris Noon氏が次のようにコメントしている。「WorkSpacesは、クライアントが従業員に提供しているのと同じ安全でガバナンスの効いたデスクトップ環境を、AIエージェントにも提供できる。カスタムAPI統合は不要で、完全な監査証跡とエンタープライズグレードの隔離が最初から組み込まれている。規制の厳しい業界では、これは単なる追加機能ではなく、前提条件だ」

AIエージェント用WorkSpacesの設定手順

AIエージェント用WorkSpacesの設定手順

AWS Management Consoleから設定を開始する。WorkSpacesコンソールで「スタックの作成」を選択し、スタック名やフリートの関連付け、VPCエンドポイントなどの基本情報を入力する。作成ウィザードのステップ3では、AIエージェント用の新しいセクションが追加されている点がポイントだ。

ここでは「AIエージェントの追加」オプションを選択する。これにより、人間用のスタックとは別に、エージェント専用のIDと権限でデスクトップにアクセスできるようになる。続いてエージェント機能を有効化する設定へ進む。「コンピューター入力」はマウスクリックやキーボード入力、スクロール操作を許可し、「コンピュータービジョン」はエージェントがデスクトップのスクリーンショットを取得できるようにする。これはエージェントが画面を「見る」仕組みだ。さらにスクリーンショットの保存先を指定し、監査やデバッグに備える。

画面レイアウトの設定では、解像度や画像フォーマットを選ぶ。UI要素が密集した複雑なアプリケーションでは高解像度が有効だが、ターミナル風のシステムであれば720pで十分だ。これらの設定を済ませると、WorkSpacesがマネージドMCPエンドポイントを生成する。あとはAIエージェントのフレームワーク側で、このエンドポイントとIAM認証情報を指定するだけで接続が完了する。

実際の動作とユースケース

実際の動作とユースケース

実際のデモでは、AWSがStrands Agent SDKとAmazon Bedrockを組み合わせて構築したエージェントが、架空の薬局システム上で処方箋の再発行処理を一通り実行している。患者レコードの検索から薬剤の選択、注文、再発行確認まで、すべてAPIなしで完結する。アプリケーション側はエージェントが操作していることを一切意識しておらず、ソフトウェアの改修も再構築も行われていない。

このようなアプローチは、金融機関の勘定系システムや医療機関の電子カルテ、物流システムの倉庫管理アプリなど、何十年も使い続けられている業務アプリケーションにすぐに適用できる。モダナイズに踏み切れずAI導入を断念していた企業にとって、有力な選択肢になるだろう。

今後の展望と利用可能リージョン

今後の展望と利用可能リージョン

今回の機能はパブリックプレビューとして、米国東部(バージニア北部、オハイオ)、米国西部(オレゴン)、カナダ(中部)、欧州(フランクフルト、アイルランド、パリ、ロンドン)、アジアパシフィック(東京、ムンバイ、シドニー、ソウル、シンガポール)の各リージョンで追加料金なしで利用できる。

エージェントが人間と同じデスクトップを共有するという発想は、レガシーシステムとAIの架け橋として大きな可能性を秘めている。AWSのブログでは、GitHubリポジトリにサンプルコードが公開されており、すぐに試せる環境が整っている。今後は、より細かな権限制御やマルチエージェント対応など、エンタープライズ利用を加速させる機能拡張が期待される。

この記事のポイント

  • Amazon WorkSpacesがAIエージェントに仮想デスクトップを提供する機能をパブリックプレビュー開始
  • レガシーアプリのAPI改修不要で、AIエージェントがクリックや入力、スクリーンショット取得で操作可能
  • IAMによる認証とCloudTrailの監査証跡で、既存のセキュリティ・コンプライアンスを維持
  • MCP対応でLangChainやCrewAIなど主要フレームワークと接続可能
  • 東京リージョンを含む多数のリージョンで追加費用なしで試用可能
2026年Web運用を変えるAIエージェント10選

2026年Web運用を変えるAIエージェント10選

Webの制作と運用は、静的なページ編集から「アクションウェブ」の時代へと完全に移行した。AIはもはやテキストを下書きするだけではない。状況を理解し、コードを生成し、テストを経て本番環境へ自らデプロイする。エージェンティックAIは、Web制作の現場における実装プロセスそのものを大きく変えつつある。

自律型AIエージェントの市場規模は、年平均44.8%の成長率で拡大し、2030年までに471億ドルに達すると予測されている。Gartnerのレポートによれば、2026年末までに企業アプリケーションの40%が何らかの会話型AIエージェントを内蔵する見込みだ。Web制作者は、手動のコード編集やZapierのルール設定に終止符を打ち、自律的に動くシステムを活用するスキルが求められている。

本記事では、2026年時点で注目すべきエージェンティックAIツールを10本厳選した。WordPressの管理画面に統合されネイティブに動作するプラグインから、大企業向けの高精度な対話型エンジン、ブラウザ操作やデータ収集を自動化するツールまでを機能別に解説する。自社のWebサイトに最もフィットするエージェントを選ぶための指針にしてほしい。

従来のWeb制作(Before)
要件定義と企画
手動コーディングやCSS調整
FTPアップロードとテスト環境確認
本番反映と不具合修正
↓ エージェンティックAIによる変革
エージェンティックAI活用(After)
自然言語で「〇〇を実装して」と指示
AIがコード生成・既存テーマと統合
サンドボックスで安全にテスト
承認後、自動デプロイ

上図のように、AIエージェントは人の手を介さず「計画 → 実行 → 検証 → リリース」のサイクルを自律的に回す。これにより、Webサイトの更新速度は劇的に向上する。

WordPress制作を高速化するAngie by Elementor

WordPress制作を高速化するAngie by Elementor

Elementorが提供する無料プラグイン「Angie」は、WordPressのダッシュボード内で動作する自律型の開発エージェントだ。従来のAIコーディングアシスタントとは異なり、サイトで有効化されているテーマやプラグインの情報をMCP(モデルコンテキストプロトコル)経由で自動的に取得する。Angieは、ただのコードスニペットを返すのではなく、実際のWordPressアセットを生成して本番に近い環境でテストする。

この仕組みが大きな安心感を生む。ユーザーは自然言語で要望を入力するだけで、Angieがカスタムウィジェットや管理画面用スニペット、カスタム投稿タイプを作成し、隔離されたサンドボックス内で動作を確認する。問題がなければ、ワンクリックで本番サイトに反映される。Elementor Editor Proとの連携時には、世界で2,100万サイト(インターネット全体の約13%)を支えるエコシステムの力をダイレクトに引き出せる。

主な機能と利点

  • コンテキスト認識型の実行により、テーマやプラグインとの競合を回避
  • サンドボックス環境でカスタムコードを事前検証し、本番サイトへの影響をシャットアウト
  • 自然言語から直接、カスタム投稿タイプや管理画面スニペットなどのWordPressアセットを生成
  • ビジュアルなフロントエンドインターフェースもテキスト指示で構築可能
  • すべての変更はユーザーが承認してから適用されるため、完全なコントロールを維持

料金と評価

Angieは完全無料のWordPressプラグインだ。Elementor Oneとの組み合わせでプロ仕様の体験になるが、単体でも十分に機能する。WordPressの複雑なアーキテクチャをネイティブに理解する専用ツールとして、手動コーディングから解放された開発者や制作会社から高い評価を得ている。

カスタマーサポートを自動化する対話エージェント群

カスタマーサポートを自動化する対話エージェント群

Webサイトの問い合わせ対応は、エージェンティックAIの実力を最も早く体感できる領域だ。高性能な対話エージェントは、FAQのトリアージを超えて、実際の業務処理まで自律的に動く。

Intercom Fin

Intercom Finは、知識ベースを読み取って自律的に回答するサポートエージェントだ。2021年型のチャットボットのように分岐ツリーを使うのではなく、ユーザーの意図を推論し、必要な情報とアクションを組み合わせる。Finはカスタマーサポートチケットの50%を人間の介入なしに解決し、1件あたり0.99ドルという成果報酬型の課金モデルを採用する。

  • 既存のヘルプセンターやNotionドキュメントを読み込ませるだけで稼働開始
  • 払い戻しなどの業務プロセスもAPI連携で自動実行可能
  • 複雑な案件は会話履歴を添えて人間スタッフに引き継ぐ
  • 対応チャネルはWebチャット、WhatsApp、メールに対応

大量の問い合わせを抱えるECサイトやSaaS事業者にとって、Finは人手による対応コストを大幅に削減する即戦力になる。

Sierra

Fortune 500企業のようなブランドイメージが優先される現場では、Sierraが選ばれる。元SalesforceのBret Taylor氏が設立したこのプラットフォームは、誤回答(ハルシネーション)を許容できない環境向けに設計されており、高度な安全性と論理推論を兼ね備える。Sierraはバックエンドの在庫データベースや配送システムに深く統合し、商品の交換やサブスクリプションのダウングレードといったトランザクション処理を自律的に行う。ただし、導入には数週間のエンジニアリング作業とエンタープライズ価格が必要で、中小企業には過剰な装備といえる。

マルチエージェントでワークフローを自動化

マルチエージェントでワークフローを自動化

単一のAIに任せるのではなく、調査・執筆・編集といった複数の専門エージェントをチームとして動かすアプローチが広がっている。これにより、Webサイトのコンテンツ運用やデータ処理のスピードは非連続的に向上する。

Relevance AI

Relevance AIは、マルチエージェントのオーケストレーションに特化したプラットフォームだ。ビジュアルなビルダーでエージェントをドラッグ&ドロップし、競合サイトの価格変動を抽出する担当、比較ページを執筆する担当、HTML整形を担当するチームを構築できる。エージェント同士の連携により、反復作業にかかる時間を平均60%削減した事例も報告されており、デジタルエージェンシーや高頻度でコンテンツを更新するパブリッシャーに適している。料金はチームプランで月額199ドルから。

Zapier Central

Zapier Centralは、6,000を超える外部アプリとの連携にAIの判断力を加えたハブだ。従来のif-thenルールではなく、会話形式で「今日のWeb経由リードを企業規模でスコアリングし、上位3件をSlackで営業チームに通知して」といった複合指示を解釈し、複数アプリをまたいだ自律的なワークフローを実行する。タスクの実行速度は1ステップあたり2秒未満と高速で、すでにZapierのエコシステムを活用しているチームに大きなアドバンテージをもたらす。

ブラウザ操作を自律化するツール

ブラウザ操作を自律化するツール

APIが提供されていない外部サイトとの連携は、これまで手作業によるデータ収集やフォーム入力に頼らざるを得なかった。エージェンティックなブラウザ操作ツールは、この壁を取り払う。

MultiOn

MultiOnは、ヘッドレスブラウザをインテリジェントに制御するAPIだ。APIが用意されていない旅行予約サイトでも、MultiOnは画面を視覚的に解析し、「2名でレストランを予約して」といった指示に対して、ボタンのクリックやフォーム入力を自律的に実行する。複雑なマルチステップのフォームでも成功率は90%以上を維持しており、対象サイトのUIが一部変更されても自己修復する。ブラウザベースの処理速度はAPI呼び出しに比べると遅いが、クローズドなWebサービスと連携したいシステムにとって強力な選択肢だ。

Bardeen

BardeenはChrome拡張機能として動作し、ユーザーが現在閲覧しているページのコンテキストを読み取って自動化を提案する。競合サイトのブログ記事一覧をスクレイピングし、要約をコンテンツ計画スプレッドシートに書き込むといった作業をワンクリックで実行できる。月額10ドルからのプロフェッショナルプランで利用でき、ブラウザがアクティブな間だけ動作するため、常時稼働のサーバーエージェントとは異なるが、マーケティングチームのリサーチ負荷を大きく下げる。

コード生成に特化した開発者向けエージェントCursor

コード生成に特化した開発者向けエージェントCursor

カスタムWebアプリケーションの開発において、Cursorは純粋なコード生成の最高峰だ。VS Codeをフォークしたこのエディタは、エージェントAIを深く統合し、単一行の補完ではなくプロジェクト全体を横断するリファクタリングを実行する。Composer機能を使えば、「認証フローを新しいAPI構造に合わせて全面的に書き直して」という指示で、複数のファイルにまたがる変更を計画し、コードを生成する。React、Vue、Node.js、Pythonなど幅広いスタックに対応し、月額20ドルのProプランで強力なモデルを利用できる。ただし、CMSの内部構造に依存するWordPress環境では、Angieのようなネイティブツールを併用する方が効率的だ。

デザイン自動生成のFramer AI

デザイン自動生成のFramer AI

ビジュアル面でのエージェンティックAIとして、Framer AIはプロンプトからレスポンシブなWebサイトのレイアウト、カラーパレット、コピーを一括生成する。CSSグリッドやブレークポイントを自動で処理し、マイクロアニメーションもあらかじめ組み込まれるため、短時間で高品質なランディングページを作成したい場面に適している。ただし、Framerはクローズドなホスティング環境であり、生成したコードの外部エクスポートは容易ではない。静的なマーケティングサイトの高速プロトタイピングには最適だが、複雑な動的機能を後から追加する場合には別のオープンなプラットフォームへの移行が必要になる。

この記事のポイント

  • エージェンティックAIは、コード提案にとどまらず、実装・テスト・デプロイまでを自律実行する
  • WordPressサイトにはAngieが最も整合性が高く、無料でサンドボックス検証まで行える
  • カスタマーサポートにはIntercom Finが有効で、チケットの50%を自動解決する
  • マルチエージェントを組めば、コンテンツ更新やデータ処理の反復作業を最大60%削減できる
  • API非公開の外部サイトとの連携には、MultiOnやBardeenのようなブラウザ操作エージェントが有効
AIエージェントがCloudflareで自律デプロイ。Stripe連携でアカウント作成からドメイン購入まで完結

AIエージェントがCloudflareで自律デプロイ。Stripe連携でアカウント作成からドメイン購入まで完結

AIエージェントがソフトウェアを開発するだけでなく、本番環境のインフラまで自ら調達し、デプロイを完了させる時代が到来した。Cloudflareは2026年4月30日、AIエージェントがユーザーに代わってCloudflareアカウントを作成し、ドメインを購入し、アプリケーションをデプロイできる新機能を発表した。

この仕組みは決済プラットフォームのStripeが提供する「Stripe Projects」と共同設計された新しいプロトコルによって実現されている。従来は人間が管理画面で行っていたAPIトークンの発行やクレジットカード情報の入力といった作業を、AIが安全かつシームレスに代行する。

開発者は複雑な初期設定に煩わされることなく、AIに指示を出すだけで「ゼロから本番公開まで」を最短距離で駆け抜けられるようになる。これはインフラ構築の在り方を根本から変える可能性を秘めたアップデートだ。

AIエージェントがインフラ構築を担う新時代の幕開け

AIエージェントがインフラ構築を担う新時代の幕開け

コーディングエージェントはプログラムを書く能力には長けているが、これまでは本番環境へのデプロイという壁に直面していた。アプリケーションを公開するには、ホスティング先のアカウント、支払い手段、そして操作のためのAPIトークンの3つが不可欠だからだ。

これまでは人間がダッシュボードにログインし、設定を済ませてからエージェントに情報を渡す必要があった。Cloudflareが導入した新機能は、この「人間による介在」を最小限に抑えることを目的としている。

開発者の手作業をゼロにするStripe Projectsとの連携

今回の機能の中核にあるのが、Stripeとの提携による「Stripe Projects」だ。これはAIエージェントが複数のサービスを組み合わせてプロジェクトを立ち上げるためのプラットフォームである。開発者がStripeのアカウントを持っていれば、それを認証の基盤として利用できる。

エージェントはユーザーの許可を得た上で、Cloudflareのアカウントを自動的にプロビジョニング(準備)する。もしユーザーがすでにCloudflareのアカウントを持っている場合は、標準的なOAuthフローを通じてアクセス権が譲渡される。これにより、APIキーのコピペという原始的な作業から解放される。

1. 従来のワークフロー(人間主体)
アカウント作成(手動)
カード情報登録(手動)
APIキー発行とコピペ(手動)
ドメイン検索と購入(手動)
2. 新しいワークフロー(AIエージェント主体)
認証とアカウント自動生成
支払いトークンの自動受け渡し
ドメインの自律取得とデプロイ
手動作業  エージェントによる自動化

上記の図が示すように、人間が介入すべきポイントは「AIへの指示」と「最終的な承認」だけに集約される。これにより、開発のリードタイムは劇的に短縮されるだろう。

プロトコルを支える3つの柱

プロトコルを支える3つの柱

AIエージェントが自律的に動くためには、単にAPIを叩くだけでは不十分だ。CloudflareとStripeは、エージェントが環境を理解し、権限を得て、支払いを実行するための3つの要素をプロトコルとして定義した。

サービスカタログからの自律的な発見

まず重要になるのが「Discovery(発見)」だ。エージェントは、利用可能なサービスが何であるかを知る必要がある。新しいプロトコルでは、CloudflareなどのプロバイダーがREST APIを通じてサービスカタログをJSON形式で提供する。

エージェントはユーザーの要望に基づき、このカタログから最適なサービス(ドメイン登録、ストレージ、コンピューティングなど)を選択する。人間が「どのメニューから選ぶか」を悩む必要はなく、エージェントがタスク達成に最適な道具を自ら選び出す仕組みだ。

認証とアカウントの即時発行

次に「Authorization(認証)」だ。Stripeがアイデンティティプロバイダーとして機能し、ユーザーの身元を保証する。Cloudflareはこの情報を基に、未登録のユーザーに対しては即座にアカウントを発行する。

発行された認証情報はStripe Projects CLIによって安全に保管され、エージェントはそれを使ってCloudflareのAPIを操作する。この一連の流れにおいて、ユーザーがサインアップフォームに入力する手間は一切発生しない。

クレジットカード情報を渡さない安全な決済

最も懸念されるのは「Payment(支払い)」の安全性だろう。AIにクレジットカード番号を教えるのはリスクが高い。そこでこのプロトコルでは、カード情報の代わりに「支払いトークン」を使用する。

Stripeから発行されたトークンをCloudflareに渡すことで、エージェントは実際のカード番号に触れることなく、有料プランの購読やドメインの購入を実行できる。決済の利便性とセキュリティを両立させた設計となっている。

実際のワークフローとCLIでの操作感

実際のワークフローとCLIでの操作感

この新機能を利用するには、Stripe CLIと専用のプラグインが必要になる。セットアップが完了すれば、ターミナルから簡単なコマンドを実行するだけでプロジェクトを開始できる。Cloudflareのブログでは、具体的な手順が紹介されている。

Stripe CLIを用いたプロジェクトの初期化

まず、以下のコマンドでプロジェクトを初期化し、Stripeにログインする。これがすべての作業の起点となる。

stripe projects init

その後、AIエージェントに対して「新しいドメインを取得してアプリをデプロイしてほしい」と指示を出す。エージェントは自ら stripe projects catalog コマンドを叩いてCloudflareのドメイン登録サービスを見つけ出し、購入プロセスを開始する。

もしStripeアカウントに支払い方法が登録されていない場合は、エージェントがユーザーに対してカード情報の追加を促すプロンプトを表示する。人間はエージェントが提示した確認事項に対して「Yes」と答えるだけで、裏側で複雑なインフラの紐付けが完了する。

セキュリティとガバナンスへの配慮

セキュリティとガバナンスへの配慮

AIに支払権限を与えることには、慎重な意見も多い。「エージェントが勝手に高額なドメインを大量購入したらどうするのか」という懸念は当然の反応だ。この問題に対処するため、プロトコルには厳格な制限が設けられている。

予算制限と予算アラートによる暴走防止

Stripe Projectsでは、デフォルトで1つのプロバイダーに対して月額100ドルという支出上限が設定されている。エージェントがこの上限を超えて勝手に課金することはできない仕組みだ。

さらに上限を引き上げたい場合は、ユーザーが明示的に設定を変更し、Cloudflare側で予算アラート(Budget Alerts)を設定する必要がある。これにより、AIの自律性を保ちつつ、予期せぬコスト増大を防ぐガバナンスが効いている。

💡 セキュリティのポイント
エージェントは実際のクレジットカード番号を見ることはできない。また、デフォルトの「100ドルの壁」があるため、AIのバグや指示ミスによる致命的な損失を回避できる。

独自分析。インフラのコモディティ化とエージェントOSの加速

独自分析。インフラのコモディティ化とエージェントOSの加速

今回のCloudflareの動きは、単なる利便性の向上に留まらない。筆者は、これがインフラの「完全な抽象化」に向けた決定的な一歩であると考えている。かつて開発者はサーバーを自前で立てていたが、クラウドが登場し、さらにサーバーレスへと進化した。そして今、インフラは「AIが勝手に調達するもの」へと変貌しようとしている。

ここで重要なのは、Stripeが単なる決済手段ではなく、Web上の「アイデンティティ(身元)」のハブとして機能し始めている点だ。Stripeでログインしていれば、CloudflareもPlanetScaleもNeonも、あらゆるクラウドサービスが即座に利用可能になる。これは、Web全体が1つの巨大なオペレーティングシステム(OS)のように振る舞い、AIエージェントがその上で自由にリソースを操作できる環境が整いつつあることを意味する。

開発者の役割は、コードを書くことよりも「AIにどのようなビジネスロジックを実現させたいか」を定義することへとシフトしていくだろう。インフラの設定ミスやAPIトークンの管理漏れといった「非本質的なトラブル」から解放される未来は、すぐそこまで来ている。

この記事のポイント

  • AIエージェントがCloudflareのアカウント作成、ドメイン購入、デプロイを自律的に行えるようになった。
  • Stripe Projectsとの連携により、OAuth認証と支払いトークンを用いた安全なプロトコルが構築されている。
  • 人間はダッシュボードを操作することなく、CLIとAIへの指示だけで本番環境を構築できる。
  • 月額100ドルのデフォルト支出制限により、AIの暴走による高額請求を防ぐ仕組みが備わっている。
  • インフラの調達が自動化されることで、開発者はより高度なアプリケーション設計に集中できるようになる。
Google検索結果の「続きを読む」リンク表示を増やす3つの法則!robots.txtドキュメント拡充と最新SEO動向

Google検索結果の「続きを読む」リンク表示を増やす3つの法則!robots.txtドキュメント拡充と最新SEO動向

Googleが検索結果の表示をより詳細にする「続きを読む(Read more)」ディープリンクのベストプラクティスを公開した。これは検索結果のスニペット内に、ページ内の特定セクションへ直接ジャンプできるリンクを表示させるための指針だ。これまで経験則で語られてきた部分が、公式ドキュメントによって明確化された形となる。

あわせて、robots.txtのドキュメント拡充や、EUでのAIチャットボットに対するデータ共有規制、さらには検索画面上でタスクを完結させる新機能についても動きがある。2026年4月の最新情報を踏まえ、Webサイト運営者が今取り組むべき構造改革について解説する。

これらのアップデートは単なる表示の変化ではなく、Googleが「AIエージェントにとって読みやすい構造」をWebサイトに求めていることの表れだ。サイトの構造が古いままでは、検索結果での露出機会を大きく損なう可能性がある。技術的な背景とともに、具体的な対策を確認していこう。

Google検索のディープリンク表示を増やす3つの鉄則

Google検索のディープリンク表示を増やす3つの鉄則

Googleは検索結果のスニペット(説明文)の下に表示される「続きを読む」リンクについて、その出現率を高めるための具体的な方法を明らかにした。ディープリンクとは、ページ全体ではなくページ内の特定の章や節に直接ユーザーを誘導するリンクのことだ。これが表示されると、検索結果の占有面積が増え、クリック率の向上が期待できる。

コンテンツはページ読み込み時に即座に表示させる

最も重要なポイントは、ユーザーがページを開いた瞬間にコンテンツが人間にとって可視化されていることだ。クリックしないと中身が見えない「折りたたみ式(アコーディオン)」や「タブ切り替え」の中に重要な情報を隠している場合、ディープリンクとして採用される確率は下がる。Googleは、ユーザーの操作なしにレンダリングされる情報を優先して評価している。

これは「隠れたテキスト」がインデックスされないという意味ではないが、検索結果の拡張機能(リッチスニペットやディープリンク)においては、露出の優先度が低くなることを示唆している。特にモバイルユーザー向けに情報をコンパクトにまとめようとして、重要な見出しや本文をアコーディオン内に閉じ込める設計には注意が必要だ。

H2やH3の見出しタグを適切に活用する

ディープリンクのリンク先となるセクションには、必ず <h2><h3> といった見出しタグを使用する必要がある。Googleのシステムは、これらの見出しをページの構造的な区切りとして認識し、リンクのアンカー(目的地)として利用するからだ。

また、検索結果に表示されるスニペットのテキストと、実際のページ内の見出しや本文の内容が一致していることも条件となる。見出しが画像だけで構成されていたり、装飾目的で <div> タグにスタイルを当てただけの「見出し風」のデザインになっていたりすると、Googleはそこをセクションの開始点として正しく認識できない。

UIデザインのBeforeとAfter比較

ディープリンクが表示されにくい構造(タブ・アコーディオン)と、表示されやすい構造(フラットな見出し構成)を比較してみよう。以下のデモは、コンテンツの露出度による構造の違いを視覚化したものだ。

非推奨:タブ・アコーディオン形式(情報の隠蔽)
概要 詳細 価格
概要テキストのみが表示されている状態…
※他のセクションはクリックしないと見えない
推奨:フラットな見出し形式(情報の露出)
製品の概要
ここに概要のテキストが入る。
詳細スペック
ここに詳細なスペックが並ぶ。
料金プラン
ここに価格情報が記載される。

このデモのように、すべての主要コンテンツがページロード時に露出している構成の方が、Googleは各セクションをディープリンクとして採用しやすくなる。ユーザーの利便性を損なわない範囲で、情報の「隠しすぎ」を避けることが重要だ。

robots.txtの公式ドキュメント拡充とスペルミスへの寛容さ

robots.txtの公式ドキュメント拡充とスペルミスへの寛容さ

GoogleのGary Illyes(ゲイリー・イリェーシュ)氏とMartin Splitt(マーティン・スプリット)氏は、ポッドキャスト「Search Off the Record」にて、robots.txtに関する新たなプロジェクトについて語った。Googleは現在、HTTP Archiveのデータを分析し、実際に世界中のサイトで使用されているrobots.txtの記述パターンを調査している。

非サポートルールの明文化

robots.txtには、Googleが公式にサポートしていない独自の命令(ディレクティブ)が記述されているケースが多々ある。例えば、クロールの頻度を指定する Crawl-delay や、特定の条件下でのみ適用されるカスタムルールなどだ。Googleは今回の分析に基づき、よく使われているが実際にはGoogleが無視している「非サポートルール」のトップ10から15をドキュメントに追加する予定だ。

これにより、Webサイト運営者は「自分が設定しているルールがGoogleに効いているのか」を正確に判断できるようになる。もしGoogleがサポートしていないルールに頼ってクロール制御を行っている場合、それは期待通りに機能していない可能性が高い。公式ドキュメントが更新された際には、自サイトのrobots.txtを改めて監査する必要があるだろう。

記述ミスの自動補完が進む可能性

さらに興味深い点として、Googleのrobots.txtパーサー(解析機)が、記述のスペルミスをより柔軟に受け入れるようになる可能性が示唆された。例えば disallowdissallow と書き間違えた場合でも、Googleがそれを意図通りの命令として解釈してくれるようになるかもしれない。

ただし、これはあくまで「Googleが親切に解釈してくれる」という話であり、ミスを放置してよいという意味ではない。他の検索エンジン(Bingなど)が同様の寛容さを持っているとは限らないからだ。robots.txtはサイトの立ち入り禁止区域を指定する「地図」のようなものだ。記述ミスがあれば、検索エンジンにインデックスさせたくないページが公開されてしまうリスクがある。基本的には、標準的なスペルを厳守すべきだ。

EUのデータ共有規制がAIチャットボットに波及

EUのデータ共有規制がAIチャットボットに波及

欧州委員会(EC)は、デジタル市場法(DMA)に基づき、Googleに対して検索データを競合他社と共有するよう求める予備的な見解を示した。この規制の対象には、従来の検索エンジンだけでなく、特定の条件を満たす「AIチャットボット」も含まれる見通しだ。

AIチャットボットが「検索エンジン」として定義される日

これまでSEO業界では、Googleのような検索エンジンと、ChatGPTやPerplexityのようなAIチャットボットを別物として扱ってきた。しかし、EUの規制当局は「オンライン検索エンジン」の定義を広げ、AIチャットボットもその範疇に含める動きを見せている。これが確定すれば、Googleが持つ膨大なランキングデータやクリックデータが、競合するAIサービスに提供されることになる。

この変化は、EU圏内での検索市場の流動性を高める可能性がある。Googleのデータを活用して精度を高めたAIチャットボットが普及すれば、ユーザーの検索行動はさらに分散するだろう。Webサイト運営者にとっては、Googleだけでなく「AIチャットボットからどう参照されるか」という視点が、法規制の面からも裏付けられた重要な課題となる。

匿名化された検索シグナルの行方

共有されるデータは匿名化されるものの、ランキング、クエリ、クリック、閲覧データといった核心的な情報が含まれる。これにより、新興のAI検索サービスが「どのコンテンツがユーザーに支持されているか」をより正確に把握できるようになる。日本国内のサイトであっても、EUからのアクセスがある場合は、これらのデータ共有の影響を間接的に受けることになるだろう。

検索結果でタスクを完結させる新機能の追加

検索結果でタスクを完結させる新機能の追加

Googleは検索結果画面(SERP)上で直接ユーザーの目的を達成させる「タスクベース」の機能を強化している。その一環として、特定のホテルの価格下落を追跡できるトグルスイッチが導入された。これは、ユーザーがホテル予約サイトへ移動することなく、Google内で価格監視を開始できる機能だ。

Webサイトへの流入機会が「Google内」に吸収される

これまで、価格下落通知は旅行予約サイトや比較サイトが提供する主要なサービスの一つだった。Googleがこの機能を検索結果に直接組み込むことで、ユーザーが各サイトを再訪する動機が減少する可能性がある。GoogleのSundar Pichai(サンダー・ピチャイ)CEOが語っていた「エージェントとしての検索」が、着実に具現化していると言える。

この変化への対策として、ホテルなどのサービス事業者はGoogleビジネスプロフィールの情報を最新に保ち、Googleのフィードに対して正確なデータを提供し続ける必要がある。検索結果が単なる「リンク集」から「実行プラットフォーム」へと進化する中で、プラットフォームとのデータ連携の重要性はかつてないほど高まっている。

AIエージェントの起動ボタン

また、Googleの「AIモード」から直接AIエージェントを起動し、複雑なタスクを委任できる機能もテストされている。例えば「旅行の計画を立てて予約まで進める」といった一連の動作を、AIが代行する仕組みだ。この際、AIがどのWebサイトの情報をソース(情報源)として採用するかは、前述した「ディープリンクのベストプラクティス」のような構造化された情報の有無に左右される。

AIエージェントは、人間と同じようにWebページを「読み」に行く。その際、Javascriptの実行や複雑なクリック操作を必要とするページよりも、シンプルで見出し構造が明確なページを好む。検索がタスク完結型になればなるほど、Webサイトは「人間が見る場所」であると同時に「AIがデータを取得するAPI」のような役割を求められるようになるのだ。

この記事のポイント

  • 「続きを読む」リンクを表示させるには、コンテンツをアコーディオンやタブに隠さず、ページロード時に露出させることが重要だ。
  • 適切な見出しタグ(H2、H3)を使用し、検索スニペットとページ内容の整合性を保つことで、ディープリンクの採用率が高まる。
  • robots.txtの公式ドキュメントが拡充され、Googleがサポートしていないルールの実態が明確になるため、定期的な記述の監査が推奨される。
  • EUの規制によりAIチャットボットが「検索エンジン」として扱われ始め、Googleの検索データが競合AIに共有される道が開かれつつある。
  • Google検索は「情報を探す場所」から「タスクを完結させる場所」へ進化しており、WebサイトにはAIエージェントが読み取りやすい構造が求められている。
Cloudflareが提唱するエージェント指向クラウド。Agents Week 2026の全発表まとめ

Cloudflareが提唱するエージェント指向クラウド。Agents Week 2026の全発表まとめ

AIエージェントが自律的にコードを書き、顧客サポートを完結させ、複雑なリサーチを数分でこなす時代が到来した。これまでのクラウドは「1つのアプリケーションが多くのユーザーにサービスを提供する」というモデルで設計されていたが、その前提が根底から覆されようとしている。

Cloudflareは2026年4月、AIエージェントが主役となる新しいインフラ「Agentic Cloud(エージェント指向クラウド)」の構築に向けた大規模なアップデート「Agents Week」を実施した。数千万のエージェントが並列稼働する世界を支えるため、計算資源からセキュリティ、開発ツールまで、全レイヤーにわたる新機能が公開された。

本記事では、Cloudflareが目指す「Cloud 2.0」の全容と、発表された膨大な新機能のポイントを整理して解説する。開発者がプロトタイプから本番環境へとエージェントをスケールさせるための、具体的な武器が揃ったと言える。

エージェントのための新しい計算基盤と実行環境

エージェントのための新しい計算基盤と実行環境

エージェントは人間とは異なり、24時間365日、膨大な数で並列に動作する。そのため、従来の仮想マシンやコンテナよりも軽量で、かつ持続性のある計算資源が必要だ。Cloudflareは、エージェントが自由にコードを書き、実行できる専用の環境を整備した。

Git互換ストレージ「Artifacts」と隔離環境「Sandboxes」

「Artifacts(アーティファクツ)」は、エージェントが生成したコードやデータを保存するための、Git互換のバージョン管理ストレージだ。エージェントは数千万のリポジトリを動的に作成し、既存のリモート環境からフォーク(複製)して作業を進めることができる。これにより、エージェントが書いたコードを即座にGitクライアントで引き継ぐことが可能になった。

また、エージェントが実際にコマンドを実行し、パッケージをインストールするための環境として「Cloudflare Sandboxes」が正式リリース(GA)された。これは、ファイルシステムやシェルを備えた本物のコンピュータのような環境でありながら、ミリ秒単位で起動し、必要に応じて状態を保存・再開できる。エージェントごとに「専用のパソコン」を割り当てるイメージだ。

Durable Objectsによるエージェント専用データベース

「Durable Objects(デュラブル・オブジェクト)」は、特定の状態を保持できるサーバーレスの仕組みだ。今回のアップデートでは、Durable ObjectsにSQLiteデータベースを内蔵できる「Facets」という機能が追加された。これにより、エージェントが動的に生成したアプリケーションごとに、完全に隔離された専用のデータベースを持たせることが可能になる。

従来のモデル(Before)
1つの巨大なデータベースを共有。
エージェントごとの隔離が難しく、管理が複雑。
エージェント指向モデル(After)
エージェント A ➔ 専用SQLite DB
エージェント B ➔ 専用SQLite DB
個別に隔離され、ミリ秒で起動・破棄が可能。
共有型  個別隔離型

この仕組みにより、開発者は数万人のユーザーに対して、それぞれ専用のAIエージェントと専用のDBを瞬時に提供するプラットフォームを構築できる。スケーラビリティの概念が、ユーザー単位からエージェント単位へとシフトしている。

自律動作を支えるセキュリティとネットワーク

自律動作を支えるセキュリティとネットワーク

エージェントが社内ネットワークにアクセスしたり、ユーザーに代わって決済を行ったりする場合、セキュリティが最大の懸念となる。Cloudflareは、エージェントを「非人間(Non-human)のアイデンティティ」として定義し、その行動を厳密に制御する仕組みを導入した。

プライベート接続を簡素化する「Cloudflare Mesh」

「Cloudflare Mesh(クラウドフレア・メッシュ)」は、ユーザー、デバイス、そしてAIエージェントを安全につなぐプライベートネットワーク機能だ。これまでは、エージェントが社内のデータベースにアクセスするためには複雑なトンネル設定が必要だったが、Meshを使えば、エージェントに最小限の権限(最小特権原則)を与えて直接接続させることができる。

ユーザーに代わって認証する「Managed OAuth」

エージェントがユーザーの代わりにSaaSツールを操作する場合、これまではセキュリティ的に危うい「サービスアカウント」が使われることが多かった。今回発表された「Managed OAuth for Access」は、RFC 9728という新しい規格を採用し、エージェントがユーザーの権限を安全に借用して認証を行う仕組みを提供する。これにより、エージェントが何をしたかの監査ログも正確に残るようになる。

エージェントを「知能」に変えるツールボックス

エージェントを「知能」に変えるツールボックス

計算資源があるだけではエージェントは動けない。適切なモデル(脳)、記憶(メモリー)、そして外部世界を認識する手段(ブラウザや音声)が必要だ。Cloudflareはこれらを「Agents SDK」として統合し、数行のコードで実装可能にした。

長期記憶と高度な検索機能

エージェントが過去の会話や作業内容を忘れないようにするための「Agent Memory」が導入された。これは、エージェントに必要な情報を記憶させ、不要な情報を忘れさせるマネージドサービスだ。また、「AI Search」という新しい検索プリミティブ(基本要素)を使えば、エージェントが膨大な文書の中から必要な情報をハイブリッド検索(キーワードと意味の両方で検索)して取り出せるようになる。

ブラウザ操作とマルチモーダル対応

「Browser Run(旧Browser Rendering)」は、エージェントにブラウザを与える機能だ。エージェントはウェブサイトを閲覧し、フォームを入力し、スクリーンショットを撮ることができる。新機能の「Human in the Loop」を使えば、エージェントが判断に迷ったときだけ人間に確認を求めるフローも構築可能だ。

さらに、音声認識(STT)と音声合成(TTS)をリアルタイムで行うパイプラインも追加された。WebSocket(ウェブソケット:双方向通信を行うための規格)を使い、わずか30行程度のコードで「声で会話するエージェント」を実装できる。メールの送受信も「Cloudflare Email Service」を通じてネイティブにサポートされた。

認識(入力)
音声、メール、ブラウザ閲覧、ファイルアップロード
思考(処理)
Agents SDK、14以上のモデルプロバイダー、Agent Memory
行動(出力)
ブラウザ操作、メール送信、音声合成、Gitコード生成

開発効率を最大化するインターフェースの進化

開発効率を最大化するインターフェースの進化

Cloudflareそのものの使い勝手も、エージェント時代に合わせて変化している。開発者が管理画面でポチポチと設定を変えるのではなく、エージェントがAPIを通じてインフラを操作するシーンが増えるからだ。

統一CLI「cf」と管理画面AI「Agent Lee」

約3,000ものAPI操作を統合した新しいCLI(コマンドライン・インターフェース)「cf」が登場した。これは人間だけでなく、エージェントがインフラを操作する際の一貫性を保つために設計されている。また、Cloudflareのダッシュボード内には「Agent Lee」というAIアシスタントが常駐するようになった。ユーザーはプロンプトを入力するだけで、複雑なスタックのトラブルシューティングや設定変更を行える。

ドメイン登録もAPIから可能に

「Cloudflare Registrar API」がベータ版として公開された。これにより、エージェントが自らドメインを検索し、空き状況を確認して登録するまでを完全に自動化できる。エージェントが新しいサービスを立ち上げ、ドメインを取得し、デプロイするまでの全工程がプログラム可能になったことを意味する。

ウェブ全体をエージェント対応へアップデートする

ウェブ全体をエージェント対応へアップデートする

現在のインターネットは人間が読むことを前提に作られているが、これからはエージェントが読みやすい「Agentic Web」への適応が求められる。Cloudflareは、サイト運営者がこの変化に対応するためのツールも提供開始した。

Agent Readiness ScoreとAIトレーニング用リダイレクト

自分のサイトがどれだけAIエージェントにとって読みやすいかを測定する「Agent Readiness Score」が導入された。構造化データが適切か、ボットのアクセスを過度に制限していないかなどを評価する。また、古いコンテンツをAIが学習しないように、検証済みのクローラーを最新のページへ自動で誘導する「Redirects for AI Training」機能も追加された。これにより、古い情報に基づいたAIの回答(ハルシネーション)を防ぐことができる。

独自の分析:Cloudflareが描く「Cloud 2.0」の正体

独自の分析:Cloudflareが描く「Cloud 2.0」の正体

今回のAgents Weekを通じて見えてきたのは、Cloudflareが「エッジコンピューティング」の強みを最大限に活かし、他社とは異なるアプローチでAIインフラを構築しようとしている点だ。AWSやGoogle Cloudが巨大なGPUセンターに注力する一方で、Cloudflareは「エージェントの実行場所(推論と実行の融合)」という独自のポジションを狙っている。

筆者の見解では、Cloudflareが提唱する「Cloud 2.0」の核心は、ステート(状態)とコンピューティングの極限までの近接にある。Durable Objectsによる超低遅延な状態管理と、ミリ秒で起動するSandboxesの組み合わせは、数千万という単位で増殖するエージェントを効率よく捌くための唯一の解かもしれない。中央集権的なクラウドでは、これほど大量の独立したセッションを低コストで維持するのは困難だからだ。

また、セキュリティを「後付け」ではなく「デフォルト」に置いている点も重要だ。エージェントが自律的に動く世界では、一度の権限設定ミスが致命的な被害を招く。MeshやManaged OAuthをインフラ層で提供することで、開発者はセキュリティの専門知識がなくても「安全なエージェント」を構築できるようになる。これはエージェントの普及を加速させる大きな要因になるだろう。

この記事のポイント

  • Cloudflareは、AIエージェントが主役となる「Agentic Cloud(Cloud 2.0)」への進化を宣言した。
  • Git互換ストレージ「Artifacts」や隔離環境「Sandboxes」により、エージェント専用の計算基盤が整った。
  • 「Cloudflare Mesh」や「Managed OAuth」により、非人間(エージェント)の安全な認証とアクセス制御が可能になった。
  • 「Agents SDK」に記憶、検索、ブラウザ操作、音声、メール機能が統合され、開発効率が飛躍的に向上した。
  • サイトのエージェント親和性を測る「Agent Readiness Score」など、ウェブ自体をエージェント向けに最適化するツールが登場した。
AIエージェントに最適化されたWebサイトとは?Cloudflareが提唱するAgent Readinessスコアの全容

AIエージェントに最適化されたWebサイトとは?Cloudflareが提唱するAgent Readinessスコアの全容

Webサイトのあり方が、人間がブラウザで閲覧するものから、AIエージェントが自律的に情報を収集し処理するものへと劇的に変化している。かつてWebサイトが検索エンジンに最適化(SEO)されたように、これからはAIエージェントが理解しやすい形に最適化される必要がある。

Cloudflare(クラウドフレア)は、自社サイトがどの程度AIエージェントに対応できているかを測定するツール「isitagentready.com」を公開した。これは、AIがサイトをクロールし、内容を理解し、さらには決済まで行える状態にあるかを数値化する指標である。

現在、インターネット上の主要な20万ドメインを調査した結果、AIエージェントへの最適化が進んでいるサイトは極めて少ないことが判明した。しかし、これは早期に対応することで、競合他社よりもAIによる情報提供やサービス利用の面で優位に立てる可能性があることを示唆している。

AIエージェント向けのWeb最適化指標であるAgent Readinessとは

AIエージェント向けのWeb最適化指標であるAgent Readinessとは

Agent Readiness(エージェント・レディネス)は、WebサイトがAIエージェントという新しい「訪問者」をどれだけ歓迎し、効率的に情報を渡せるかを示す新しい概念である。Cloudflareが提供を開始した「isitagentready.com」では、URLを入力するだけで、そのサイトの対応状況をスコア化できる。

このスコアは、単に「AIを拒否していないか」を確認するだけのものではない。AIがサイト内を迷わずに移動できるか、情報を処理する際のコスト(トークン数)を削減できているか、そしてAIが自律的にアクションを起こせるかといった多角的な視点で評価される。

評価を構成する4つの主要な軸

Agent Readinessスコアは、主に以下の4つのカテゴリに基づいて算出される。それぞれの要素は、AIエージェントがサイトを訪れた際の「体験」を向上させるために不可欠なものだ。

  • ディスカバリー(発見しやすさ):AIがサイトの構造を即座に把握し、必要なページへたどり着けるか
  • コンテンツの最適化:AIが理解しやすい形式(Markdownなど)でデータを提供しているか
  • 制御とセキュリティ:AIの行動範囲を適切に制限し、信頼できるAIかどうかを認証できるか
  • インタラクション(相互作用):AIがAPIを介してツールを操作したり、決済を行ったりできるか

Cloudflare Radarの調査によれば、現在インターネット上の主要なサイトの約78%が「robots.txt」を設置しているが、そのほとんどは従来の検索エンジン向けに書かれたものである。AIエージェントに特化した設定を行っているサイトは、まだ全体の数パーセントに過ぎない。

AIエージェントに情報を届けるための新規格と実装方法

AIエージェントに情報を届けるための新規格と実装方法

AIエージェントがWebサイトを巡回する際、最大の障壁となるのが「HTMLの複雑さ」である。人間向けの装飾や広告が含まれるHTMLは、AIにとってノイズが多く、処理に多くのトークンを消費させる。これを解決するための新しい標準規格が登場している。

llms.txtによる「AI専用のお品書き」の提供

「llms.txt」は、Webサイトのルートディレクトリに配置するプレーンテキストファイルである。これは、AI(大規模言語モデル)に対して、サイトの概要や重要なコンテンツへのリンクをリスト化した「読書リスト」のような役割を果たす。サイトマップをAIが読みやすい言葉で書き直したものと考えると分かりやすい。

# サイト名
> サイトの短い説明文
## 主要ドキュメント
- [導入ガイド](https://example.com/docs/intro.md)
- [APIリファレンス](https://example.com/docs/api.md)

このファイルを設置することで、AIは数千ページあるサイトの中から、どのページを優先的に読むべきかを瞬時に判断できる。これにより、AIエージェントの回答精度が向上し、ユーザーが求める情報にたどり着くまでの時間が短縮される。

Markdownコンテンツ・ネゴシエーションによる軽量化

コンテンツ・ネゴシエーションとは、クライアント(訪問者)の要望に合わせて、サーバーが最適な形式のデータを返す仕組みである。AIエージェントがHTTPヘッダーに Accept: text/markdown を含めてリクエストを送った際、サーバーがHTMLではなくMarkdown形式を返すように設定することが推奨されている。

HTMLからMarkdownへの切り替えは、AIが消費するトークン数を最大で80%削減できるというデータがある。トークンの削減は、AIの処理速度を上げ、運用コストを下げることに直結する。以下のデモは、HTMLとMarkdownでどれほど情報の密度が異なるかを視覚化したものである。

従来のHTML表示(人間向け)
最新ニュース
投稿日:2026年4月17日
WebサイトのAI最適化が始まりました。これにより… [続きを読む]
※タグやスタイルなどの装飾データが大量に含まれる
AI向けMarkdown表示
# 最新ニュース
WebサイトのAI最適化が始まりました。
[詳細](https://example.com/news/1)
      
※純粋なテキストのみ。トークン消費を大幅に抑制

このデモのように、AIにとっては構造化されたテキストのみの方が扱いやすく、誤認のリスクも低い。Cloudflareでは、URLの末尾に /index.md を付与することで、動的にMarkdownを返す仕組みを推奨している。

AIエージェントの制御とセキュリティの新基準

AIエージェントの制御とセキュリティの新基準

すべてのAIエージェントにサイトを解放するのが正解とは限らない。コンテンツの無断学習を拒否したい、あるいは特定の信頼できるエージェントにのみアクセスを許可したいというニーズがある。これに対応するための規格が「Content-Signal」と「Web Bot Auth」である。

Content-Signalによる詳細な意思表示

従来の robots.txt では、アクセスを許可するか拒否するかという二択しかできなかった。新しい「Content-Signal」ディレクティブを使うと、AIによる学習(ai-train)、推論への利用(ai-input)、検索結果への表示(search)を個別に制御できる。

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

例えば、上記の記述では「AIの学習には使わせないが、AIがユーザーの質問に答える際の参考資料(RAG)としての利用や、検索結果への掲載は許可する」という柔軟な設定が可能になる。これにより、著作権を守りつつ、AIを介したトラフィックを確保できる。

Web Bot Authによるエージェントの身元確認

悪意のあるボットがAIエージェントを装ってアクセスしてくるリスクに対し、「Web Bot Auth」という認証規格が提案されている。これは、エージェントがリクエストにデジタル署名を付与し、サイト側がその署名を公開鍵で検証する仕組みである。

これにより、サイト運営者は「このアクセスは確かにOpenAIの公式エージェントからのものだ」と確信を持ってアクセスを許可できるようになる。匿名のスクレイパーと、正当なAIサービスを明確に区別するための重要なインフラとなるだろう。

自律的なアクションを可能にするAPIと決済の統合

自律的なアクションを可能にするAPIと決済の統合

AIエージェントの真の価値は、情報の閲覧だけでなく、ユーザーの代わりに「行動」することにある。買い物、予約、データの処理といったタスクをAIが自律的にこなすためには、WebサイトがAI向けの「窓口」を備えていなければならない。

MCP(Model Context Protocol)の活用

MCPは、AIモデルが外部のデータソースやツールと接続するためのオープン標準である。サイト側が「MCPサーバー」を用意し、その機能(ツール)を記述した「サーバーカード」を /.well-known/mcp/server-card.json に配置することで、AIはどのような操作が可能かを理解できる。

例えば、ドキュメント検索ツールや在庫確認ツールをMCP経由で公開すれば、AIエージェントは自らそのツールを呼び出し、ユーザーの複雑な要求に応えることができるようになる。これは、AIが「サイトを読む」段階から「サイトを使う」段階への進化を意味する。

HTTP 402によるマシン間決済の復活

AIエージェントが有料の情報を取得したり、商品を購入したりする場合、人間向けのクレジットカード入力画面は機能しない。そこで注目されているのが、長らく使われてこなかったHTTPステータスコード「402 Payment Required」の活用である。

「x402」と呼ばれるこの新しい決済フローでは、AIがリクエストを送ると、サーバーが402エラーとともに「支払い条件」を機械読み取り可能な形式で返す。エージェントはその条件に従って決済を行い、再度リクエストを送ることでコンテンツを取得できる。人間を介さない、マシン間の経済圏を支える技術である。

Cloudflare ドキュメントに見るAI最適化の実践事例

Cloudflare ドキュメントに見るAI最適化の実践事例

Cloudflareは自社の開発者向けドキュメントにおいて、これらの規格をいち早く導入している。その結果、AIエージェントによる回答速度が66%向上し、消費トークン数が31%削減されたという。具体的にどのような工夫がなされているのかを見てみよう。

URL書き換えによる動的なMarkdown提供

Cloudflareは、既存のHTMLページをわざわざMarkdownで書き直すのではなく、エッジコンピューティング(Cloudflare Rules)を活用して動的に変換している。URLの末尾に /index.md を付けると、オリジナルのHTMLからタグを取り除き、Markdownとして配信する仕組みだ。

これにより、メンテナンスコストを増やすことなく、人間向けとAI向けのコンテンツを両立させている。また、大規模なサイトでは llms.txt が巨大になりすぎるため、ディレクトリごとに分割した llms.txt を用意し、ルートからそれらをリンクする階層構造を採用している。

古い情報をAIに学習させないためのリダイレクト

Webサイトには、歴史的な理由で残されている古いドキュメント(非推奨のツールなど)が存在する。人間は「非推奨」という警告バナーを見て判断できるが、AIクローラーはテキストをそのまま飲み込んでしまい、古い情報をユーザーに教えてしまうことがある。

Cloudflareでは、AI学習用クローラーを識別し、古いページから最新のページへと強制的にリダイレクトさせる処理を行っている。これにより、AIが常に最新かつ正確な情報のみを学習するように制御している。これは、AI時代の新しいコンテンツ管理の形と言えるだろう。

独自の分析:Webサイトは「読むもの」から「使われるもの」へ

独自の分析:Webサイトは「読むもの」から「使われるもの」へ

Agent Readinessの普及は、Webサイトの設計思想を根本から変える可能性がある。これまでのWebデザインは、いかに人間の視線を誘導し、クリックさせるかという「UI/UX」が中心だった。しかし、AIエージェントが主役となる世界では、いかに機械が迷わず、低コストで目的を達成できるかという「DX(Developer Experience)ならぬAX(Agent Experience)」が重要になる。

特に注目すべきは、AIエージェントが「ブラウザ」を介さずに直接サーバーと対話するようになる点だ。これは、Webサイトが「情報の展示場」から「プログラム可能なインターフェース」へと進化することを意味している。APIが公開されていない小規模なサイトでも、llms.txt やMarkdown配信を導入することで、AIという強力な力を味方につけることができる。

今後、Googleなどの検索エンジンも、Agent Readinessスコアが高いサイトを「AIフレンドリーな良質なソース」として優遇する可能性がある。SEOの次のステージとして、この「AI最適化」への取り組みは、企業のデジタル戦略において避けて通れない課題となるだろう。

この記事のポイント

  • Agent Readinessスコアの登場:WebサイトがAIエージェントにどれだけ最適化されているかを測定する新しい指標が公開された
  • llms.txtとMarkdownの重要性:AI専用の案内図(llms.txt)と軽量なデータ形式(Markdown)が、AIの回答精度向上とコスト削減に直結する
  • 詳細なアクセス制御:Content-Signalにより、学習は拒否しつつ検索や推論への利用を許可するなど、柔軟な意思表示が可能になる
  • マシン間経済の加速:MCPによるツールの公開や、x402による自動決済など、AIが自律的にアクションを起こすためのインフラが整いつつある
  • 早期対応のメリット:現状では対応サイトが少ないため、今すぐ対策を始めることでAI経由のトラフィックや利便性において大きなアドバンテージを得られる
AIが買い物をする時代へ!エージェント・コマース(Agentic Commerce)の仕組みと対応策

AIが買い物をする時代へ!エージェント・コマース(Agentic Commerce)の仕組みと対応策

ネット通販における「決済ページ」という概念が消えようとしている。これまで30年間、オンラインで物を買うには名前や住所、クレジットカード番号をフォームに入力するのが当たり前だった。しかし、AIエージェントがユーザーの代わりに商品を探し、そのまま購入まで完了させる「エージェント・コマース」が急速に現実のものとなっている。

2025年から2026年にかけて、Stripe、OpenAI、Shopify、Googleといったテック巨人が相次いで新しい決済プロトコルを発表した。これにより、チェックアウトは「Webページ」で行う作業から、システム間で完結する「プロトコル」へと進化を遂げている。もはや人間がフォームを埋める必要はない。

この変化は、Web制作やECサイト運営に携わる者にとって無視できないパラダイムシフトだ。AIエージェントに自社の商品を見つけてもらい、スムーズに決済してもらうためには、サイトの構造そのものを「マシン・リーダブル(機械が理解可能)」に変えていく必要がある。本記事では、最新の業界動向と技術仕様を基に、エージェント・コマースの全貌を解説する。

決済は「ページ」から「プロトコル」へ進化する

決済は「ページ」から「プロトコル」へ進化する

1994年に世界で初めてオンライン決済が行われて以来、ECの歴史は「摩擦の解消」の歴史だった。物理的な店舗に行く手間を省き、価格比較の手間を省き、レコメンド機能によって探す手間を省いてきた。エージェント・コマースは、その進化の最終段階といえる。ユーザーが「これを買っておいて」とAIに頼むだけで、決済まで完了するからだ。

30年続いた「フォーム入力」の終焉

従来のECサイトでは、売り手がチェックアウト体験を設計していた。ボタンの色やフォームの配置を工夫し、いかにカゴ落ちを防ぐかがコンバージョン率向上の鍵だった。しかし、エージェント・コマースでは、チェックアウトのインターフェースを作るのはAIエージェント側だ。ChatGPTなどのAIが、チャット画面の中で商品情報と購入ボタンを提示する。ユーザーがそこで承認すれば、裏側でAPIが呼び出され、決済が完了する。

売り手側の仕事は、魅力的なページを作ることではなく、構造化された商品データを提供し、注文を処理するAPIエンドポイントを用意することにシフトする。Stripeの情報によれば、コマースの課題はユーザー体験(UX)の問題からプロトコルの問題へと変化しているという。つまり、見た目の美しさよりも、機械がいかに正確にデータを読み取れるかが重要になるのだ。

AIエージェントが購入を代行する仕組み

AIエージェントによる購入は、人間がブラウザを操作するのとは全く異なるプロセスを辿る。エージェントはサイトの視覚的なデザインを無視し、テキストデータやメタデータ、APIを通じて情報を取得する。決済時には、ユーザーがあらかじめAIプラットフォームに登録しておいた支払い情報が使われる。売り手側のサイトにユーザーが直接クレジットカード情報を入力することはない。

従来の購入フロー(Before)
1. 検索エンジンで探す ↓ 2. ECサイトを訪問 ↓ 3. カートに入れる ↓ 4. 住所・カード入力 ↓ 5. 注文完了
エージェント購入フロー(After)
1. AIに依頼 ↓ 2. AIがAPI経由で商品特定 ↓ 3. チャット内で承認 ↓ 4. AIが決済プロトコルを実行 ↓ 5. 注文完了

このデモは、購入プロセスの構造的な変化を視覚化したものだ。人間が介在するステップが大幅に短縮されていることがわかる。

二大勢力が競う「エージェント・コマース」の標準規格

二大勢力が競う「エージェント・コマース」の標準規格

現在、この新しい市場を支配しようと、二つの大きなプロトコルが標準化を競っている。一つはOpenAIとStripeが主導する「ACP」、もう一つはGoogleとShopifyが主導する「UCP」だ。これらは対立するものではなく、補完し合う関係にあるが、それぞれの設計思想には違いがある。

StripeとOpenAIによる「ACP」

ACP(Agentic Commerce Protocol / エージェント・コマース・プロトコル)は、2025年9月に発表されたオープン標準だ。主にChatGPT内での「インスタント・チェックアウト」を実現するために設計されている。ACPは、AIエージェント、売り手、支払いサービスプロバイダーの三者が通信するための4つのAPIエンドポイントを定義している。

具体的には、カートの作成、情報の更新、決済の完了、そしてキャンセルの4段階だ。売り手は自社のシステムをこれらのエンドポイントに対応させるだけで、ChatGPTを通じて商品を販売できるようになる。Stripeはこの導入を容易にするために「Agentic Commerce Suite」を提供しており、既存のStripeユーザーであれば最小限のコードで対応が可能だ。すでにWalmartやInstacartといった大手がこの仕組みを導入し、ChatGPT経由での販売を開始している。

ShopifyとGoogleによる「UCP」

UCP(Universal Commerce Protocol / ユニバーサル・コマース・プロトコル)は、2026年1月にGoogleとShopifyが発表した。ACPが決済フローに特化しているのに対し、UCPは商品の発見から購入後のサポートまで、コマース体験の全工程をカバーすることを目指している。その構造はインターネットの基本プロトコルであるTCP/IPをモデルにしており、非常に拡張性が高い。

UCPの特徴は、サイトの特定の場所に設置された「/.well-known/ucp」というエンドポイントを通じて、AIエージェントがそのサイトの販売能力を自動的に認識できる点にある。Google検索やShopifyのプラットフォームと深く統合されており、多くのEC事業者が意識せずともAIエージェントに対応できる環境を整えようとしている。MastercardやVisaといったカードネットワークもUCPへの支持を表明しており、より広範なエコシステムを形成している。

「人がいない決済」を支えるセキュリティ技術

「人がいない決済」を支えるセキュリティ技術

エージェント・コマースにおける最大の課題はセキュリティだ。クレジットカードの持ち主がその場にいない「Person-not-present(本人が不在の決済)」において、どうやって不正を防ぎ、信頼を担保するのか。これまでの「カード番号とCVVを知っていれば本人とみなす」という前提は、AIの時代には通用しない。

Shared Payment Tokens(共有支払いトークン)の役割

この問題に対するStripeの回答が「Shared Payment Tokens(SPT)」だ。これは、AIプラットフォームが発行する、特定の取引専用の使い捨てトークンである。ユーザーがChatGPTで「購入」を承認すると、ChatGPTは特定の売り手、特定の金額、特定の有効期限に限定されたトークンを発行する。売り手はこのトークンを使ってStripeに決済を依頼する。

この仕組みの優れた点は、売り手にもAIエージェントにも、ユーザーの本物のクレジットカード情報が渡らないことだ。万が一データが漏洩しても、そのトークンは他の場所では使えない。また、Googleが推進するAP2プロトコルでは、デジタル署名を用いてユーザーの同意を厳密に検証する仕組みが導入されている。これにより、AIが勝手に高額な買い物をするといったリスクを技術的に排除している。

クレジットカード各社の「Trusted Agent」対応

VisaやMastercardといったカードネットワークも、AI時代に合わせた新しい枠組みを構築している。Visaが発表した「Trusted Agent Protocol」は、正規のAIエージェントと悪意のあるボットを識別するためのフレームワークだ。従来の不正検知システムは、マウスの動きやタイピングの癖といった「人間らしい振る舞い」を指標にしていたが、AIエージェントにはそれが存在しない。

そのため、新しいシステムでは、AIエージェントの身元を暗号学的に証明し、そのエージェントがユーザーから正当な権限を与えられているかを確認することに主眼が置かれている。Stripeの調査によれば、消費者の88%がAIによるなりすまし詐欺を懸念しているが、こうした堅牢なインフラが整備されることで、徐々に信頼が醸成されていくとの見方がある。

自社の商品を「AIに売る」ための具体策

自社の商品を「AIに売る」ための具体策

エージェント・コマースの波に乗るために、ECサイトの運営者は今何をするべきか。最新のプロトコルに対応することも重要だが、その基礎となるのは「データ」の質だ。AIエージェントがサイトを訪れた際、迷うことなく商品を理解し、推奨できるように準備しておく必要がある。

マシン・リーダブルな商品データの整備

AIエージェントはプログラムによってカタログを解析する。そのため、曖昧な表現や、画像の中にだけ書かれた情報は理解できない。例えば、商品タイトルを「青いシャツ」とするのではなく、「メンズ オーガニックコットン クルーネック Tシャツ、ネイビー」のように具体的かつ詳細に記述することが求められる。素材、寸法、お手入れ方法、用途といった情報を、すべてテキストデータとして網羅しておくことが重要だ。

また、価格や在庫状況がリアルタイムで正確であることも欠かせない。AIエージェントが「在庫あり」と判断してユーザーに提案したのに、いざ決済しようとしたら「在庫切れ」だったという体験は、エージェントからの信頼を失う原因になる。AIは信頼性の高いソースを優先的に選ぶ傾向があるため、正確な情報提供はSEOならぬ「AI-SEO」の根幹となる。

構造化データ(Schema.org)の重要性

プロトコルへの直接的な統合が難しい場合でも、構造化データのマークアップは今すぐ実行できる強力な対策だ。Schema.orgの Product スキーマを使い、名前、説明、画像、SKU、ブランドなどの情報を正しくタグ付けする。さらに、その中に Offer スキーマをネストさせ、価格、通貨、在庫状況、販売者を明記する。

BingでSchema.orgの立ち上げに携わったDuane Forrester氏によれば、一貫した構造化データを提供し続けることで、AIシステムの中に「マシン・コンフォート・バイアス(機械的な安心感による偏り)」が生まれるという。つまり、AIが「このサイトの情報は常に正確で読み取りやすい」と学習すれば、競合他社よりも優先的に引用・推奨されるようになる可能性があるのだ。

AIエージェント向けチェックリスト
  • 商品タイトルを具体的かつ詳細にする
  • 素材、サイズ、用途をテキストで網羅する
  • Schema.org(Product/Offer)を全商品に適用する
  • 在庫と価格をリアルタイムで同期する
  • 画像に適切なaltテキスト(代替テキスト)を付与する

このリストにある項目は、従来のSEO対策とも共通する部分が多いが、AIエージェントを意識する場合は「より厳密な正確性」が求められる点に注意が必要だ。

独自の分析:AI SEOがECの勝敗を分ける

独自の分析:AI SEOがECの勝敗を分ける

エージェント・コマースの普及に伴い、EC業界には「選択の均質化」という新たなリスクが浮上している。コロンビア大学とイェール大学の共同研究によれば、現在のAIショッピングエージェントは、少数の特定商品に需要を集中させる傾向があるという。人間のように検索結果の2ページ目や3ページ目まで丹念に探すことはせず、アルゴリズムが「最適」と判断したトップ数件だけが選ばれる「勝者総取り」の構図が強まるのだ。

これは、中小規模のブランドにとっては大きな脅威であると同時に、チャンスでもある。巨大な広告予算がなくても、AIが理解しやすい高品質なデータを提供し、特定のニッチなニーズに対して「最も正確な回答」を提示できれば、AIエージェントに選ばれる可能性が高まるからだ。これからのEC戦略は、人間の感性に訴えるデザインと、機械の論理に応えるデータの両立が不可欠になる。

また、今後は「AIエージェント向けの広告」という概念も登場するだろう。しかし、Anthropic(Claudeの開発元)のように、広告やスポンサーリンクを一切排除したクリーンなコマース体験を標榜するプラットフォームも存在する。売り手としては、特定のプラットフォームに依存するのではなく、ACPやUCPといったオープンな標準規格に対応し、どこからでも「見つけられ、買える」状態を作っておくことが、長期的な生存戦略となるはずだ。

この記事のポイント

  • 決済は「ページ」から「プロトコル」へ移行し、人間によるフォーム入力が不要になる
  • StripeとOpenAIの「ACP」、ShopifyとGoogleの「UCP」という二大規格が標準化を競っている
  • 「共有支払いトークン(SPT)」などの技術により、本人が不在でも安全な決済が可能になる
  • ECサイトは、詳細なテキストデータとSchema.orgの導入により、AIに選ばれる準備をすべきだ
  • AIエージェントによる「選択の均質化」が進むため、正確な情報の提供が生き残りの鍵となる
AIエージェントに最適化するAEOとは?Google Cloud AIのディレクターが提唱する新戦略

AIエージェントに最適化するAEOとは?Google Cloud AIのディレクターが提唱する新戦略

検索エンジンの仕組みが、人間のブラウジングからAIエージェントによる自動処理へとシフトし始めている。Google Cloud AIのエンジニアリングディレクターであるAddy Osmani氏は、この変化に対応するための新しい枠組みを提唱した。それがAEO(Agentic Engine Optimization)だ。

AEOとは、AIエージェントがコンテンツを自律的に取得し、解析し、実行しやすくするための最適化手法を指す。従来のSEOが「人間のクリック」を目的としていたのに対し、AEOは「マシンの理解と行動」に焦点を当てている。この違いが、今後のWeb制作のあり方を根本から変える可能性がある。

AIエージェントは、人間のようにページをスクロールしたり、広告を眺めたりはしない。彼らは必要な情報を瞬時に抽出し、次のタスクへと進む。このプロセスを効率化することが、AI時代のWebサイトにとって不可欠な戦略となるのだ。

AIエージェントが情報を消費する仕組みとAEOの定義

AIエージェントが情報を消費する仕組みとAEOの定義

AEOは、一般的に知られている「Answer Engine Optimization(回答エンジン最適化)」とは異なる概念だ。Addy Osmani氏が提唱するAEOは、AIエージェントが自律的にコンテンツを消費するためのモデルを指している。AIエージェントとは、ユーザーの指示を受けてネット上を駆け巡り、情報の収集や予約、購入などのアクションを代行するプログラムのことだ。

ブラウジングからアクションへの変化

従来のWeb利用では、人間が複数のサイトを訪問し、情報を比較検討していた。しかしAIエージェントは、複数のステップを一つのリクエストに集約する。彼らはUI(ユーザーインターフェース)のデザインや操作性には関心を持たず、背後にあるデータそのものを必要としている。

この変化により、これまでのエンゲージメント指標は意味をなさなくなる。滞在時間や直帰率といった数字は、AIエージェントの活動を測定する上では重要ではない。重要なのは、エージェントがいかに速く、正確に目的の情報を取得できたかという点だ。

マシンのためのアクセシビリティ

AEOの核心は、Webコンテンツを「マシンにとって読みやすい形」に整えることにある。これは、視覚障害者のためのアクセシビリティ対応に似ている。セマンティックなタグ付けや構造化データの提供が、AIエージェントにとっても道標となる。情報の透明性と構造の明快さが、AEOの土台を支えている。

トークン制限という新たな最適化指標

トークン制限という新たな最適化指標

AIエージェントがコンテンツを処理する際、最大の障壁となるのが「トークン制限」だ。トークンとは、AIがテキストを処理する際の最小単位を指す。多くのLLM(大規模言語モデル)には、一度に処理できる情報の量に限界がある。これをコンテキストウィンドウと呼ぶ。

ページが長すぎたり、不要な情報が多すぎたりすると、AIエージェントの処理能力を超えてしまう。その結果、情報の断片化や、最悪の場合は内容の読み飛ばしが発生する。Osmani氏は、トークン数を主要な最適化指標として意識すべきだと指摘している。

トークン消費の視覚化デモ

AIエージェントがどのように情報を切り捨てているかを視覚的に理解するためのデモを以下に示す。コンテキストウィンドウの限界に達したとき、重要な情報がどのように失われるかを確認してほしい。

従来の冗長なページ(処理前)
[冒頭の長い挨拶文… 150トークン]
[サイトの歴史と理念… 300トークン]
[★ 重要な回答データ… 50トークン]
[関連する広告やリンク… 400トークン]
[詳細な技術解説… 500トークン]
AIエージェントの処理(トークン上限到達)
[冒頭の長い挨拶文… 処理中]
[サイトの歴史と理念… 処理中]
[!!! ここでトークン上限に到達 !!!]
[重要な回答データ… 読み飛ばし]
[以降のデータは破棄されました]
処理された内容  本来必要な情報  破棄された情報

このデモのように、重要な情報がページの下部にあると、AIはそこに到達する前に処理を打ち切ってしまう。不要な装飾や冗長な文章を削ぎ落とし、トークン効率を高めることがAEOの第一歩だ。

ハルシネーションのリスクを低減する

不完全な情報しか取得できなかったAIエージェントは、不足している部分を推測で埋めようとする。これがハルシネーション(もっともらしい嘘)の原因の一つになる。正確な情報を提供し、AIに正しく引用してもらうためには、コンテキストの密度を高める必要がある。ページをコンパクトに保ち、一つのテーマに絞り込むことが推奨される。

AIエージェントに好まれるコンテンツ構造

AIエージェントに好まれるコンテンツ構造

Addy Osmani氏は、AIエージェントが効率的に情報を解析できるよう、コンテンツの構造を再設計することを提案している。その具体的な手法として「回答の早期配置」と「Markdownの活用」が挙げられている。

最初の500トークンに全力を注ぐ

AIエージェントは忍耐強くない。彼らが最も注目するのは、コンテンツの冒頭部分だ。Osmani氏は、重要な回答を最初の500トークン以内に配置することを推奨している。これは、ジャーナリズムにおける「逆ピラミッド型」の文章構成に近い。結論を先に述べ、その後に詳細を続けるスタイルだ。

HTMLよりもMarkdownが選ばれる理由

興味深い提案の一つが、従来のHTMLページに加えて、クリーンなMarkdown形式のファイルを提供することだ。HTMLにはナビゲーション、スクリプト、複雑なレイアウトタグなど、AIエージェントにとっての「ノイズ」が大量に含まれている。これらは解析コスト(トークン消費)を増大させる要因となる。

Markdownは構造が単純であり、AIが文脈を把握するのに最適だ。実際に、多くのAI開発ツールやドキュメントサイトでは、Markdown形式の提供が標準化しつつある。以下のデモで、HTMLとMarkdownの情報密度の違いを比較してみてほしい。

HTML(ノイズが多い)
<nav>…</nav>
<div class=”main-content”>
  <h1>製品の仕様</h1>
  <p>最新のモデルは…</p>
</div>
<aside>広告</aside>
※タグだけで数十字を消費
Markdown(クリーン)
# 製品の仕様
最新のモデルは…
※純粋な情報のみ。トークンを節約できる

このデモは、同じ情報を伝える際にMarkdownがいかに効率的かを示している。

このように、情報の「純度」を高めることがAIエージェントに対する最高のおもてなしとなる。将来的には、人間用のWebページとは別に、マシン専用のエントリポイントを用意することが一般的になるかもしれない。

マシンリーダブルなインデックスの整備

マシンリーダブルなインデックスの整備

AIエージェントがサイト全体を効率よく把握するために、新しい標準ファイルが登場している。これらは、かつての sitemap.xmlrobots.txt のAI版と言えるものだ。Osmani氏は、いくつかの重要なファイル形式を紹介している。

llms.txt による構造化インデックス

llms.txt は、ドキュメントやコンテンツのインデックスを構造化したテキストファイルだ。AIエージェントはまずこのファイルを読み込むことで、サイト内のどこに何が書かれているかを即座に理解できる。全ページをクロールする手間を省き、必要な情報へ最短距離でアクセスさせるためのショートカットだ。

能力を定義する skill.md と AGENTS.md

特定の機能やAPIを提供しているサイトでは、skill.md というファイルが役立つ。これは、そのサイトができること(能力)を定義したファイルだ。また、コードベースに対しては AGENTS.md がマシンのための案内図として機能する。これらのファイルを用意することで、AIエージェントは「このサイトを使って何ができるか」を迷わずに判断できるようになる。

SEOとAEOの共存と今後の展望

SEOとAEOの共存と今後の展望

AEOの概念が登場したことで、従来のSEOは不要になるのだろうか。Googleの検索チームに属するJohn Mueller氏は、現時点では「通常のSEOがAI Overviewsなどのランキングにも有効である」との見解を示している。また、Markdown専用ページを別途用意することに対しては、重複コンテンツのリスクから否定的な意見も出ている。

しかし、Osmani氏が説くAEOは、単なる検索順位の向上だけを目的としたものではない。AIエージェントがワークフローの中でコンテンツを正しく「実行」し、成果に結びつけるための最適化だ。ここには、従来の検索エンジン最適化とは異なる次元の価値が存在する。

二極化する最適化戦略

今後は、人間向けの「情緒的・視覚的な体験」と、マシン向けの「論理的・構造的なデータ」の二極化が進むだろう。Web制作者は、美しいデザインを維持しつつ、その裏側でAIエージェントに優しいデータ構造を維持するという、二つの役割をこなす必要がある。

これは技術的な負担が増えることを意味するが、同時に大きなチャンスでもある。AIエージェントに「使いやすいサイト」として認識されれば、AIが主導する新しい経済圏において、強力なプレゼンスを確立できるからだ。AEOは、AI時代のWebサイトが生き残るための新しいプレイブックとなるだろう。

この記事のポイント

  • AEOはAIエージェントが自律的にコンテンツを消費・実行しやすくするための最適化である
  • トークン消費量を新たな指標とし、重要な情報は最初の500トークン以内に配置すべきだ
  • ノイズの少ないMarkdown形式の提供や、llms.txtなどの専用インデックスが有効な手段となる
  • 従来のSEOが人間向けであるのに対し、AEOはマシンの理解とアクションを最大化することを目指す
  • Google検索の公式見解とは一部異なる点があるが、AIワークフローへの適合は今後の重要課題となる