AIが業務システムに「つながる」話をするとき、MCP（コネクタ）とブラウザ操作は、たいてい同じ棚に並べられます。どちらも「AIが自分で外部のサービスを触ってくれる機能」だからです。

ですが、この2つはできることの多さで並ぶものではありません。事故が起きたときに、誰の名前で起きるかが違います。ここを分けずに導入すると、後から効いてきます。

いちばん腹落ちしやすい説明の仕方があるので、それで整理します。

1．AIを「見習いインターン」だと考えてください

パソコンの前に、今日来たばかりの見習いインターンが座っている。そう想像してください。優秀かどうかは、いったん脇に置きます。

MCPは、そのインターンに「この作業だけやっていいよ」と、明確な手順書と制限を渡した状態です。

触ってよいシステムが決まっていて、そこでできる操作の種類も決まっている。手順書に書いていないことは、そもそもやりようがありません。持ち場が先に区切られている、という言い方がいちばん近いと思います。

ブラウザ機能は、そのインターンに「私の代わりにログインして、画面を見て自由に操作しておいて」と、自分のIDを渡して座らせるのと同じです。

持ち場はありません。あるのは「私に見えている画面ぜんぶ」です。承認ボタンも、ダウンロードも、送信も、画面に映っている限りは押せてしまう。

2．論点は、インターンの資質ではありません

ここで多くの議論が「では、そのAIはどのくらい賢いのか」「誤操作の確率はどのくらいか」という方向に行きます。精度の話です。

ですが、後者（ブラウザ）で本当に効いてくるのは、そこではありません。

自分のIDを貸し与えた時点で、インターンが誤操作をしたとしても、その責任はIDの持ち主である私たちが負うことになります。

システムのログに残るのは、AIの名前ではなく、私たちのアカウント名です。「AIがやりました」という抗弁は、ログの上には存在しません。私が承認したことになっている。私が送信したことになっている。内部統制の観点でいえば、これは精度の問題ではなく、権限と証跡の問題です。

言い方を変えると、MCPで起きた事故は「渡した手順書が甘かった」という設計の話に落とせますが、ブラウザで起きた事故は「私がやった」という記録として残ります。同じ「AIが外部を触る」でも、着地する場所がまったく違います。

3．だから、貸すIDは徹底的に制限する

結論はここに尽きます。ログインさせるIDは、徹底的に制限する必要があります。

ブラウザ操作を使わない、という話ではありません。実際に便利ですし、MCPが用意されていない社内システムを触るには、これしかない場面もあります。使うなとは言いません。

ただ、そこで貸すのが「普段自分が使っている、承認権限のついたID」であってはならない、ということです。誤操作の確率をゼロにはできない以上、誤操作が起きても致命傷にならない範囲のIDを渡す。順番としては、AIの賢さを評価するより先に、こちらです。

具体的にどう絞るか（専用アカウントの立て方、読み取り専用の使い分け、証跡の残し方）は、それだけで一本になるので、稿を改めます。

まずは、いま社内で誰かがAIにブラウザを触らせているとして、それが誰のIDかを確認するところから始めてみてください。

ISAO国際公認会計士事務所　加藤 勲