MCPとA2Aの普及を見て、「人間がウェブサイトを開く必要はなくなり、すべてAIエージェントが処理する」と考えるのは早い。

公式ドキュメント上、MCPはAIアプリケーションを外部のデータ、ツール、ワークフローへ接続する標準である。A2Aは、異なる事業者やフレームワークで作られたAIエージェント同士が通信し、仕事を委任し、結果を共有するための標準である。

二つのプロトコルが担うのは、人間向けウェブの置き換えではない。これまで人間向け画面の裏側に閉じ込められていた情報と機能を、機械が利用できる形で分離することである。

MCPとA2Aは何を分けるのか

両者は似た文脈で語られるが、役割が異なる。

標準主な接続役割
MCPエージェントとツール・データ情報取得や操作を標準化する
A2Aエージェントと別のエージェント発見、委任、協調を標準化する

例えば調査エージェントが、MCPを使ってニュースデータベースとGitHubへ接続し、A2Aを使って法務確認エージェントや翻訳エージェントへ作業を委任する構成が考えられる。

ここで重要なのは、利用者が個別のデータベース画面やGitHub画面をすべて操作しなくても、作業が進む点である。一方、結果の根拠を確認するときには、依然として人間が読める原文、履歴、説明画面が必要になる。

ウェブは「読む層」と「実行する層」に分かれる

従来のウェブページは、情報表示、操作、認証、説明、広告、法的表示を一つの画面へ集めてきた。人間がブラウザを使うことが共通前提だったからである。

エージェントが利用者の代わりに作業する場合、この一体構造は効率が悪い。機械は装飾されたボタンの位置を推測するより、利用可能な操作、必要な入力、権限、結果の形式を構造化された形で受け取る方がよい。

その結果、ウェブサービスは次の二層へ分かれていく。

人間向けの信頼層

  • 本文を読み、文脈を理解する
  • 運営者と編集責任を確認する
  • 訂正履歴や利用規約を確認する
  • 結果が妥当か判断する
  • 例外や曖昧さを理解する

エージェント向けの実行層

  • データを検索する
  • 条件を指定して取得する
  • 操作可能な機能を発見する
  • 権限の範囲内で処理する
  • 結果と状態を構造化して返す

この二層は競合しない。機械向けの実行層だけでは、読者が情報源を評価できない。人間向けページだけでは、エージェントが安定して情報を利用できない。

なぜウェブサイトは残るのか

AIが要約を返すなら、原文ページへのアクセスは減る可能性がある。それでもウェブサイトには少なくとも四つの役割が残る。

1. 正式な原本

エージェントの回答は、その時点の複数情報を合成した二次生成物である。どの表現が発行者自身のものかを確定するには、正規URLを持つ原本が必要になる。

2. 責任主体の表示

情報が誤っていた場合、誰が訂正するのかはプロトコルだけでは決まらない。運営者、著者、編集方針、連絡先を確認できる公開ページが必要になる。

3. 複雑な文脈

構造化データは明確な項目の取得に強いが、例外、留保、価値判断、反対意見などの文脈を完全には表しにくい。長文の説明や資料を人間が確認する場は残る。

4. 公開性

MCPやA2Aの接続先が認証を要求する場合、一般の利用者が内容を監視できない可能性がある。公共的情報では、誰でも確認できる公開面が重要である。

逆に、HTMLだけでは不十分になる

ウェブサイトが残るからといって、従来通りHTMLだけを作ればよいわけではない。

エージェントが画面を解析して情報を得る方法は、表示変更に弱く、誤読も起こる。日付、価格、版番号、状態、利用条件などは、本文に書くだけでなく機械が区別できる形で提供する必要がある。

ニュースメディアの場合、最低限次の層が必要になる。

層主な形式目的
原本HTML記事人間が内容と責任を確認する
意味JSON-LD記事、著者、日付、発行者を表す
更新通知RSS・サイトマップ新着と変更を発見させる
検索JSONインデックス記事候補を効率的に探す
操作API・MCP条件付き取得や処理を実行する
協調A2A専門エージェントへ作業を委任する

すべてを最初から実装する必要はない。重要なのは、各層の役割を混同しないことだ。

小規模サイトがMCPを急ぐべきでない理由

新しいプロトコルが注目されると、接続対応そのものが目的になりやすい。しかし、記事が少なく、更新頻度が低く、権限管理も不要なサイトでは、MCPサーバーを作る利益は限定的である。

静的サイトでも、次が整っていれば多くの機械利用に対応できる。

  • 安定したURL
  • 正しい見出し構造
  • 構造化データ
  • RSS
  • サイトマップ
  • 検索用JSON
  • 明確な利用条件
  • 訂正履歴

MCPが必要になるのは、全文検索、購読者限定データ、複数条件による取得、外部システムへの操作など、単純な公開ページでは表現しにくい能力を提供するときである。

機械インターフェースの危険性

エージェント向け接続は便利だが、閲覧だけだったウェブを実行環境へ変える。

記事を読む処理と、メールを送る処理、データを削除する処理、決済する処理が同じエージェントへ接続されると、誤った指示の影響範囲は大きくなる。外部コンテンツに埋め込まれた指示、過剰な権限、接続先のなりすまし、監査不能な委任などを考慮しなければならない。

したがって、実行層には次が必要になる。

  • 最小権限
  • 操作前の確認
  • 接続先の認証
  • 入出力の記録
  • 取り消し可能性
  • 人間へ戻す条件

「AIが自律的に動く」ことを目標にするより、どの時点で人間の判断が必要かを明示する方が、実運用では重要である。

AI CHANGE DESKの現実的な順序

このサイトでは、当面次の順序が妥当である。

  1. HTML記事を信頼できる原本として整える
  2. JSON-LD、RSS、サイトマップを維持する
  3. 記事検索用JSONを安定させる
  4. 出典、確度、更新履歴を構造化する
  5. 利用規約と機械取得方針を決める
  6. 記事数と利用需要が増えた段階でMCPを検討する
  7. 複数の専門処理が必要になった場合にA2Aを検討する

この順序なら、新技術へ対応しながら、運営負荷とセキュリティリスクを増やしすぎずに済む。

結論

MCPとA2Aはウェブサイトを消す技術ではない。人間にしか使えなかったウェブサービスを、機械が利用できる能力へ分解する技術である。

その結果、ウェブは二層化する。人間向けページは信頼、説明、責任、原本を担い、機械向けインターフェースは検索、取得、実行、協調を担う。

これから重要になるのは、どちらか一方を選ぶことではない。同じ情報と機能を、人間にも機械にも誤解されにくい形で提供し、両者の間で出典と権限を失わない設計である。

一次情報