転職を考えているマーケターのミナが、オンライン講座サイトの AI アシスタントにこう尋ねたとする。「表計算ソフトしか使えません。平日の夜なら時間があり、6 週間で自動化レポートを作れるようになりたい。どの講座が合っていますか。8 月にまだ申し込めるクラスはありますか」。

この質問には、性質の違う三つの仕事が含まれている。講座を比べ、どれが彼女の経歴に合うかを判断するには、サイトで公開されている講座紹介を読むだけで足りる。8 月にまだ空きがあるかを確かめるには、変動するデータを調べる必要がある。彼女の代わりに申し込み、カード決済をするのは人に代わって動くことで、彼女はそもそもそれを頼んでいない。

最近、AI が「つながれる」ように API や MCP を作るべきかを議論するサイトが増えている。答えは、AI がこなす仕事が読む、調べる、動くのどれにあたるかで決まる。三つの入口が負う責任は大きく違い、多くのサイトがまず直すべきなのは、いちばん地味な層、つまり AI が読める公開ページだ。

まず MCP が何を解決するのかを押さえる

MCP（Model Context Protocol）は、AI アプリを外部のデータ、ツール、ワークフローにつなぐためのオープン標準だ。答えてくれるのは「どうつなぐか」であって、「何を開放すべきか」をサイトの代わりに決めてはくれない。

MCP の開発サービスを提供する Cloudflare は、自社のドキュメントではっきり注意している。MCP サーバーを API 全体のラッパーとして扱うのではなく、利用者の具体的な目的に合わせてツールを設計すること。よく設計された少数のツールのほうが、細かいツールを大量に並べるより役に立つことが多く、権限も狭くするべきだという。この技術を提供する側でさえ、何を開けるかの前に AI に何をさせるかを決めるよう勧めているわけだ。

読む、調べる、動くの三つは、段階的に上がっていく道筋ではない。読む入口を作ったら次は調べる入口、その次は動く入口、というものではない。三つはそれぞれ別の責任に対応している。読む入口が間違えば、AI は誤った紹介をする。調べる入口が間違えば、AI は古い答えを返す。動く入口が間違えば、誤った申し込みや支払いが現実に生まれる。入口が深くなるほど、サイトが引き受ける結果も重くなる。

読む：多くのサイトの本当の穴はここにある

ミナが最初に求める答えの出どころは公開されている講座紹介で、データベースは要らない。AI が理由のある推薦をできるかどうかは、そのページ同士が食い違っていないかにかかっている。講座名、前提となるスキル、学習成果、受講時間帯は、どのページでも同じことを言っているか。ページのタイトル、説明文、日付、言語版は同じ内容を指しているか。終了した講座のページに「受付中」と出たままになっていないか。

こうした問題には、すでに道具がある。Google 検索セントラルによれば、サイトマップ（サイトの重要なページと更新日時を並べたファイル）は、検索エンジンがページや言語版を見つける助けになる。rel="canonical" は、重複またはよく似たページの中でどれが正本かを検索エンジンに伝える。どちらも新しい技術ではなく、AI のために別途開発する必要もない。

講座ページ同士が矛盾しているなら、MCP を足しても AI がその矛盾を速く読むだけだ。読む層でやるべきことは、まず内容を直すことである。

広告

調べる：一つの問いに答える窓だけを開ける

空き枠、在庫、価格、配送状況は変わる。こうした数字を AI にページのレイアウトから推測させれば、サイトを改修したとたんに壊れる。安定した読み取り専用の照会を用意する価値が出てくるのは、このときだ。

その窓は狭く開ける。ミナの例なら、AI が照会できればよいのは候補講座のコード、8 月のクラス、平日夜の時間帯、残りの枠、データの更新時刻、そして「満席」「未同期」「該当クラスなし」「一時的な障害」といった状態だけだ。受講者名簿、支払い記録、社内メモ、枠を書き換える機能は、このタスクには含まれない。

とくに大事なのは最後の状態だ。照会に失敗したとき、AI は古いデータを答えとして出すのではなく、「いまは確認できない」と言えなければならない。テストでは照会ツールをわざと外してみるといい。AI は公開情報をもとに講座を推薦できるが、いまの空き状況は確認できないと正直に伝えるべきだ。

動く：承認と後始末の方法を先に用意する

申し込み、返金、設定変更、通知の送信は、誰かの権限を使って外の世界の状態を変える。この種の入口を開ける前に、誰のアカウントを使い、誰に対して、どんなパラメーターで行うのか、取り消せるのか、相手に通知が行くのか、間違えたらどう直すのかをはっきりさせておく。

AI エージェントを作るための開発キットである OpenAI の Agents SDK は、「人が介在する」承認の仕組みを具体的に示している。機密性の高いツールを実行する前にいったん止め、ツール名と引数を人に見せ、その一回の呼び出しについて承認か拒否かを決めてもらい、保存した状態から再開する。要点は「その一回」にある。漠然とした「同意」を一つ残すだけでは、あとからどの対象とどのパラメーターが承認されたのかわからない。

処理が途中で失敗しうるなら、すでに起きた結果、安全にやり直せるか、誰が後始末をするかも先に記録しておく。自動化が途中で止まったら、やり直す前に何がもう起きたかを確かめるも参考になる。これらが一つでも欠けているなら、動く入口はまだ開けるべきではない。

実際のタスク一つから判断を始める

「MCP を作るべきか」という会議を開くより、実際のタスクを一つ選んで完了条件を書き出し、こう問うほうがいい。このタスクのどの部分は読むだけで足り、どの部分は調べる必要があり、どの部分は動く必要があるのか。

ミナのタスクは、推薦の理由と申し込める 8 月の夜間クラスが一つ手に入った時点で完了する。「動く」を外しても彼女の答えは何も欠けない。これは、このタスクに必要な最も浅い入口が、読むことと狭い照会の窓だという証拠だ。彼女が続けて「このクラスに申し込んで」と頼み、本人確認、個人情報、一回ごとの確認、決済、重複申し込みの防止、失敗時の復旧のすべてに担当者がいるときになって初めて、動く入口を検討し直す価値が出てくる。

多くのサイトにとって次の一歩は、新しいインターフェースを開発することではないことが多い。AI がよく尋ねられるページをいくつか選び、それらが同じことを言っているかを確かめることだ。AI がチームのためにコードも書き換えるなら、同じ階層の考え方が使える。その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるも参考になる。

AI 整理カード

サイトのタスクにどの層の入口が必要か、AI と一緒に判断する このプロンプトは、実際のタスクを一つ説明してもらい、それを読む、調べる、動くの三つに分け、タスクに必要な最も浅い入口だけを提案する。

自分のサイトに、AI 向けの新しい入口（API や MCP など）を開けるべきか判断したい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/agentic-web-needs-machine-readable-doors/
記事の見方はこうだ。実際のタスクを一つ選び、「公開情報を読む」「変わるデータを調べる」「人の代わりに動く」の三つに分け、タスクに必要な最も浅い層だけを開ける。多くのサイトがまず直すべきは、AI が読める公開ページだ。

まず私に 3 つ質問してほしい：
1. 利用者が AI に頼む、私のサイト上の実際のタスクは何か。何をもって完了とするか；
2. そのタスクに答えるにはどんなデータが要るか。公開ページにすでにあるものと、随時変わるものはどれか；
3. そのタスクでは、誰かのアカウントを使って申し込み、支払い、変更、送信をするか。

私の回答をもとに、次を出力してほしい：
- タスクを読む、調べる、動くの三つに分け、それぞれに必要なデータや操作；
- 読む部分：先に直すべき公開ページの食い違いの候補；
- 調べる部分：このタスクだけに答える読み取り専用の照会に必要な項目とエラー状態；
- 一行の結論：このタスクに必要な最も浅い入口はどの層か；
- 動く入口が必要なら：事前に用意すべき承認、記録、復旧の方法。ただし実装の設計まではしないこと。
私が触れていないデータや機能がサイトにあると仮定しないこと。

提案は出発点にすぎない。どの層の入口を開けるかは、そのデータと結果に責任を持つ人が決める。

広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料