この記事は、士業（税理士・社会保険労務士・弁護士などの専門家事務所）やBtoBサービス（法人向けのサービス）を営む事業者・担当者に向けて書いています。自社サイトにWebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を載せるなら、どの操作をAIに開き、どの判断を人が持つべきかを整理します。読み終えると、問い合わせと見積の入口で、AIに任せてよいことと任せないことを切り分ける考え方が分かります。
WebMCPはW3C（Web標準を決める団体）の標準ではなく、W3CのWeb Machine Learning Community Groupが公開している仕様の草案です。Chromeではオリジントライアル（試験的な提供）の段階で、内容は変わり続けています。この記事は2026年10月20日時点の確認に基づきます。
WebMCPの全体像はWebMCPの入門記事で扱っています。この記事に出てくる事務所や数字、やり取りは、すべて説明のための架空の例です。
なぜ士業・BtoBサービスで考える価値があるのか
士業やBtoBサービスの入口は、多くの場合「相談したい内容を伝え、対応してもらえるかを知り、おおよその費用感をつかむ」という流れです。ここには、似た質問に毎回答える作業や、長い問い合わせフォームの入力が含まれます。
Chromeの資料は、WebMCPの使いどころとして、長いフォームの入力（勤怠、中古車検索、保証請求、ケータリングの問い合わせなど）を挙げています。既存のフォームがあれば、少ない手順でツールにできるとも説明しています。相談内容の入力は、この種類の作業に近いと言えます。
一方で、士業の仕事の中心は、事情を聞いたうえでの判断や助言です。ここはAIに開く対象ではありません。WebMCPの仕様は、人が使う画面が主役であり、人が関わる使い方（human in the loop）を主に想定しています。完全に自律して、人の画面なしで動く運用を想定したものではない、という位置づけです。
つまり、考えるべきことは「何をAIに任せるか」より、「入口の作業のうち、どこまでを手伝ってもらい、どこから人が受け持つか」です。
AIに開く操作の候補
次の表は、架空の例として、ある士業事務所のサイトでAIエージェントに開く操作の候補を整理したものです。操作の名前や中身は、自社に合わせて考えてください。
| 操作の候補（架空の例） | AIに手伝ってもらうこと | 人が持つこと | 注釈の考え方 |
|---|---|---|---|
| ヒアリング項目の案内 | 相談前に用意しておくとよい情報の一覧を示す | 実際の事情の聞き取りと、その解釈 | 読み取りのみ（readOnlyHint）が候補 |
| 対応可否の案内 | 取り扱い分野や受付の範囲を、公開済みの情報から案内する | 個別の案件を受けるかどうかの判断 | 読み取りのみが候補 |
| 概算見積の目安の表示 | 公開している料金の考え方を示す（要確認の注記つき） | 実際の見積額の決定と提示 | 読み取りのみが候補 |
| 日程調整 | 空き枠の確認と、希望日時の仮の入力 | 日程の確定と、当日の対応 | 確定は影響が出るため、人の確認を挟む |
| 問い合わせフォームの入力補助 | 利用者の言葉をフォームの項目に整理して入力する | 内容の確認と、送信するかどうかの判断 | 送信前に利用者が見て押す形が安全 |
表の「注釈」は、WebMCPの草案にあるヒントです。readOnlyHintは状態を変えない操作、consequentialHintは実世界への影響や取り消せない操作を示します。クライアント（エージェントを動かす側）は、これを手がかりに利用者へ確認を求めることができます。ただし、草案はツール実行時の確認を必須とは定めていません。確認の仕組みは自社でも考えておく必要があります。
相談内容のヒアリング項目を整理する
最初に整えたいのは、相談を受けるときに必要な情報の整理です。これはAIのためだけでなく、人が読む画面のためにも役立ちます。
架空の例として、企業の契約書チェックを扱う事務所を考えます。相談の前に分かっているとよい情報は、たとえば次のようなものです。
- 相談したい分野（契約、労務、税務など、事務所が扱う区分）
- 相談の背景を短く書いた文
- 希望する連絡の方法と、返事がほしい時期
- 法人か個人かの区別（法人名は、必要になってから尋ねる）
項目を決めたら、WebMCPのツールの入力スキーマ（入力項目の定義）に反映します。Chromeの資料は、JSON Schemaで入力と期待する出力を決めておくと、エージェントの誤りが減ると述べています。分野のような選択肢のある項目は、自由記述よりも、決まった選択肢にしておくほうが伝わりやすくなります。
ここで注意したいのは、項目を増やしすぎないことです。聞けるからといって何でも尋ねると、個人情報の取りすぎにつながります。この点は後の「よくある失敗」で触れます。
概算見積の目安を出すときの考え方
費用感は、問い合わせの前に知りたい情報の代表です。AIが答えられれば便利ですが、士業・BtoBサービスでは、金額が案件の中身で大きく変わることがあります。
架空の例を挙げます。事務所が「料金の考え方」というページを公開していて、作業の種類ごとに、料金が決まる要素（作業量、急ぎかどうか、書類の数など）を説明しているとします。ツールは、そのページの内容を、利用者の質問に合わせて返します。
このとき、ツールの返答には次のような注記を添える設計が考えられます。
- これは公開している料金の考え方に基づく目安であること
- 実際の金額は、内容を確認したうえで人が提示すること
- 状況によって、目安から外れる場合があること
Chromeの資料は、ツールの返答で立て直せる案内を返すことを勧めています。たとえば、条件が足りないときに「何を教えてもらえれば目安を出せるか」を返す形です。汎用的なエラーや、無言の失敗は避けるべきだとされています。
金額を断定して返すツールは、慎重に考えてください。誤った金額をAIが伝えると、後の契約や信頼に影響しかねません。目安を示すにとどめ、確定は人が行う形が無理のない線引きです。
日程調整と問い合わせフォームの入力補助
日程調整は、読み取りと確定を分けて設計できます。空き枠の確認は読み取りのみの操作です。一方、予約の確定は、相手の時間を押さえる操作で、影響が出ます。
Chromeの資料には、「開始」と「実行」を動詞で区別する考え方があります。たとえば、即座に作成するツールと、フォームへ誘導して入力を始めるツールを分けます。日程調整なら、「候補日を入れた状態の予約フォームを開く」ツールと、「予約を確定する」ツールを分けるイメージです。前者なら、最後の確認は利用者が画面で行えます。
問い合わせフォームの入力補助は、宣言的API（HTMLのフォームに属性を付けてツールにする方式）と相性がよい場面です。Chromeの資料では、フォームにtoolnameとtooldescriptionを付けるとツールとして登録され、エージェントが呼ぶと、ブラウザがフォームの項目を入力し、フォームは利用者に見える状態のままになると説明されています。送信は、既定では利用者が送信ボタンを押して完了します。自動で送信させる設定もありますが、問い合わせフォームでは、利用者が内容を見てから送る既定のままにするのが安全です。
なお、この宣言的APIは、Chromeの資料では紹介されていますが、W3Cの草案の本文には、2026年10月時点でまだ含まれていません。両者の違いを、混同しないようにしてください。
Chromeの資料には、情報が足りないときは、エージェントが利用者に尋ねる、または利用者がフォームを手で埋めて送信できる、という説明もあります。入力補助は、あくまで手伝いであり、人の手で完了できる道を残しておくのが前提です。
人が持つべき判断：判断・助言・契約
士業の場合、法律や制度に基づく判断・助言・契約の締結は、人が責任を持って行う領域です。どこからがその業務にあたるのかは、資格や業法によって異なり、この記事では断定できません。AIに開く操作がその領域に入り込まないか、所管の団体や専門家に確認してください。
実務上の整理として、次の分け方が考えられます。
- AIに手伝ってもらう：公開済みの情報の案内、項目の整理、フォームへの入力、空き枠の表示。
- 人が行う：個別の事情を踏まえた判断、助言、見積額の確定、契約の締結、受任するかどうかの決定。
線の引き方を、サイトの文面にも書いておくとよいでしょう。たとえば、「この案内は一般的な情報であり、個別の助言ではありません」といった注記です。ただし、その文面が適切かどうかも、専門家に確認するのが望ましいです。
人の確認をどう設計するかは、WebMCPと人の確認（human in the loop）の記事で詳しく扱っています。
よくある失敗
誤った回答を、断定して返す
架空の例です。取り扱い分野の案内ツールが、古い情報を元にしていて、すでに受けていない案件を「対応できます」と返してしまう。利用者は、それを事務所の回答と受け取ります。
対策は、返答の元になる情報を一か所にまとめて更新すること、そして返答に「最終的な可否は、内容を確認して人が回答する」と添えることです。ツールの説明と実際の動作が食い違う危険は、草案もリスクとして挙げています。名前と説明は、動作と一致させてください。
個人情報を、過剰に取得する
入力項目を増やしすぎると、相談の入口で不要な個人情報まで集めることになります。草案は、過剰なパラメータによるプライバシー漏えいを、リスクの一つとして挙げています。
入口で本当に必要な項目は何かを絞り、詳細は、人が対応する段階で尋ねる形が現実的です。個人情報の扱いは、法令や自社の方針にも関わります。専門家に確認してください。
外から来た内容を、そのまま信頼する
問い合わせの本文は、利用者が書いた内容です。それを返すツールには、悪意ある指示が紛れる可能性があります。草案もChromeの資料も、間接プロンプトインジェクション（モデルが読む内容に悪意ある指示が埋め込まれること）を課題として挙げています。利用者由来の内容を返すツールには、untrustedContentHintという注釈が使えます。
名前や説明を、長く詳しく書きすぎる
W3Cの草案は、ツールの名前を128文字以内と定めています。一方、Chromeの資料は、エージェントに見せる量の目安として、名前とパラメータ名は30文字、ツールの説明は500文字、パラメータの説明は150文字、ツールの出力は1.5K文字を目安として挙げています。草案の上限に近づけるより、短く書くほうが安全です。
最初の一歩
- 入口の作業を書き出す：問い合わせの電話やメールで、毎回同じことを聞いている項目を洗い出す。
- 人の領域に線を引く：判断・助言・契約にあたる部分を明記し、専門家や所管に確認する。
- 読み取りだけのツールから始める：ヒアリング項目の案内や、対応分野の案内など。
- フォームを見直す：項目を絞り、各項目の説明を整える。
- DevToolsで確認する：ChromeのDevToolsのApplicationタブに、WebMCPの項目があります。ツールの名前・説明の確認や、手動での実行ができます。
ツールの設計の細部は、WebMCPのツール設計の記事が参考になります。公開前の点検には、AIエージェント対応サイトのチェックリストをお使いください。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 資格業務の線引きは、この記事では判断できません。業法や所管のルールは、専門家や所管の窓口に確認してください。
- セキュリティと個人情報は、専門家の確認を受けてください。この記事は法的な助言ではありません。
- ツールは補完です。人が使う画面が主役であることに変わりはありません。
Otsumuに相談できること
入口の作業の書き出しと、人が持つ判断の線引きは、社内で始められます。まずは、問い合わせの対応で繰り返している作業を一覧にしてみてください。
そのうえで、ツールの設計や、フォームとの連携、確認の仕組みづくりは、実装との兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、サイトを「AIが使える形」にする設計もご一緒できます。資格業務に関わる判断は、専門家のご確認の上で進めます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20