Claude in Chrome と GPTを比べてみた
――AIに仕事を任せる、二つのまったく違う方法
この記事の要点
前回までの記事で、Digital Supporters Clubの運営を支援する 「DSC Builder GPT」をつくってきました。
SharePointに会員用のフォルダをつくり、 決められたアクセス権を設定し、 最後に本当に正しく設定されたかを確認する。
ようやく、実際に動くところまでたどり着きました。
そこで今回は少し視点を広げ、 私が実際に作ったり使ったりした二つのAIエージェントを比較します。
一つは、今回つくったDSC Builder GPTのように、 APIを通じて、あらかじめ決められた仕事を行うタイプ。
もう一つは、Claude in Chromeのように、 AIがブラウザを見ながら人間の代わりに画面を操作するタイプです。
これは「ClaudeとGPTのどちらのAIモデルが賢いか」という比較ではありません。
Claude in Chromeというブラウザ操作型のAIエージェントと、 Custom GPT＋Actions/APIでつくった専用型AIエージェントの比較です。
- GPT型は「サービスをAIへつなぐ」
- Claude in Chrome型は「AIがサービスへ出かけていく」
- 自由度と安全性では、手綱を置く場所が違う
- どちらが優れているかではなく、向いている仕事が違う
１．そもそもAIエージェントとは何なのか
私は、AIエージェントを難しく考えず、
と考えると分かりやすいと思っています。
これまでChatGPTを使うときは、 プロンプトで相談することが中心でした。
「これについて調べて」
「どうすればいい？」
「文章を書いて」
「SharePointではどう設定すればいい？」
AIが答えてくれる。
しかし、その答えを読んで、 実際にSharePointを開いて操作するのは自分です。
つまりAIは非常に優秀な相談相手でしたが、 仕事は最後に人間へ戻ってきました。
AIエージェントでは、 この関係が少し変わります。
「これをやっておいて」と頼める。
たとえば、
「この会員が使うフォルダを準備しておいて」
と頼む。
するとAIが、自分の代わりにシステムへ働きかけ、 実際に仕事を進めます。
私はこの、
が、AIエージェントを理解する一番分かりやすい入口だと思っています。
２．GPTが登場したとき、「AIのApp Store」が始まるように見えた
ここで少し時間を戻します。
OpenAIがGPTsを発表したのは、2023年11月でした。
特定の目的に合わせたChatGPTを、 専門的なプログラミングをしなくても作れる。
それを他の人と共有できる。
さらにActionsを使えば、 外部のAPIにつなぎ、 データを取得したり、 外部システムを動かしたりすることもできる。
そして、それらのGPTを探して使える 「GPT Store」も発表されました。
2024年1月にGPT Storeが公開されたときには、 OpenAIによれば、すでに300万を超えるカスタムGPTが作られていました。
当時は、
という期待が大きく広がりました。
スマートフォンにアプリを追加するように、 ChatGPTの中にさまざまな専門GPTが並ぶ。
旅行のGPT。
会計のGPT。
教育のGPT。
会社独自のGPT。
そして必要なら、 それぞれが外部サービスのAPIにつながる。
考え方としては、
方向です。
今回つくったDSC Builder GPTも、 まさにこの考え方の延長にあります。
３．DSC Builder GPT――「できる仕事」を先に定義する
DSC Builderでは、 GPTからSharePointを自由に操作できるようにはしていません。
たとえば、
と頼む。
GPTは専用APIへ依頼します。
API側では、
- どのSharePointサイトを操作できるか
- どのフォルダを作れるか
- どんな会員番号を受け付けるか
- どんな権限を設定できるか
を、あらかじめ決めています。
つまりGPTに「何でもできる道具」を渡すのではなく、 必要な仕事だけを実行できる道具を用意する考え方です。
DSC Builderでは、さらに、
↓
人間が確認
↓
Apply
↓
Verify
という流れをつくりました。
まず何を変更するか計画を出す。
私が確認する。
それから実行する。
最後に本物のSharePointから状態を読み直し、 予定と実際が一致したらPASSにする。
ここでは、 AIの自由度を意図的に小さくしています。
その道路の上だけを走らせる。
そんな方法です。
４．Claude in Chrome――AIが既存のサービスへ出かけていく
Claude in Chromeは、 これとはほとんど逆の発想です。
こちらでは、 SharePoint専用APIを私が用意する必要はありません。
自分でSharePointの管理画面へログインする。
その状態で、
「この設定を確認して」
「ここを変更して」
と頼む。
するとClaudeが、 人間と同じように画面を見ながら進みます。
↓
クリックする
↓
次の画面を開く
↓
入力する
↓
保存する
つまりGPT型が、
仕組みだとすれば、 Claude in Chromeは、
仕組みです。
この違いは、 かなり大きいと思います。
APIが用意されていない社内ツールや、 古いシステムや管理画面でも、 ブラウザで操作できるのであれば、 AIが人間と同じ画面を使える可能性があります。
言い換えるなら、
発想です。
５．二つを比較すると、こうなる
| 比較項目 | DSC Builder GPTのようなAPI型 | Claude in Chromeのようなブラウザ型 |
|---|---|---|
| 基本思想 | サービスをAIへAPIで接続する | AIが既存のWebサービスへ行く |
| 操作方法 | APIを直接呼び出す | 画面を見てクリック・入力する |
| 事前準備 | API、認証、スキーマなどの開発が必要 | 拡張機能を使い、対象サイトへログインすれば始めやすい |
| 開発知識 | 比較的必要 | 少なくて済む |
| 操作できる範囲 | あらかじめ定義した範囲 | ブラウザで到達できる範囲が広い |
| 自由度 | 低い | 高い |
| 実行速度 | APIなので比較的速い | 画面操作なので相対的に遅い |
| UI変更の影響 | 比較的小さい | 画面構成変更の影響を受けやすい |
| APIのないシステム | 原則として苦手 | 強い |
| 同じ処理の反復 | 得意 | 可能だが画面状態に左右されやすい |
| 操作範囲の制限 | API側で強制しやすい | 権限モード、サイト権限、ブラウザ権限などで管理 |
| 安全性の考え方 | API・権限・処理フロー自体を設計段階で制限 | Manual / Auto / Skipから承認・自動チェックのレベルを選択 |
| 結果検証 | Expected / ActualをAPIで比較しやすい | 画面や実行結果を再確認する形になりやすい |
| 監査・ログ | operationIdなどで構造化しやすい | ブラウザ操作・実行履歴が中心になりやすい |
| 向いている仕事 | 定型・反復・重要な業務 | 探索的・臨時・幅広いWeb作業 |
| 最大の魅力 | 確実性と制御 | 自由度と導入の簡単さ |
| 最大の弱点 | 作るのが大変 | 自由である分、監督や安全設定が重要 |
この表をつくってみると、 単なる「便利さ」の違いではないことが分かります。
のです。
６．Claude in Chromeを先に使ったから、DSC Builderをつくろうと思った
実際の順番としては、 私はDSC Builderより先にClaude in Chromeを試しました。
最初に動かしたときは、 かなり驚きました。
SharePointの管理画面をClaude自身が開き、 設定を探し、 クリックしていく。
私はほとんど見ているだけです。
「これなら、わざわざ専用のアプリをつくらなくてもいいのではないか」
とも思いました。
何しろ、準備が簡単です。
私がSharePointへログインできればいい。
細かな画面操作を全部覚えていなくても、 Claudeが探してくれます。
これは非常に大きなメリットです。
一方、しばらく見ていると、 少し違う面も見えてきました。
↓
クリックする
↓
反応を待つ
↓
違う場所へ行ったら戻る
↓
必要ならもう一度試す
人間がブラウザを操作するのと同じなので、 ときどき少しモタモタします。
セキュリティ確認のポップアップが出れば、 そこで止まることもありました。
さらに初期には、 権限グループを誤って削除してしまったこともありました。
それ以降、
- 今回は確認だけ
- まだ変更しない
- 実行前に確認する
と指示を明確にするようになりました。
この体験から、
自由に画面を操作させるより、
できる操作を最初から限定した専用の仕組みをつくった方がいいのではないか
と思ったのが、 DSC Builderをつくる一つのきっかけでした。
７．自由度と安全性は、どうしても表裏一体になる
ブラウザ型の最大の魅力は自由度です。
しかし、その自由度は、 そのまま注意すべき点にもなります。
Claude in Chromeは、 ログインしているWebページを直接操作できます。
そのため、ブラウザ型AIでは、 Webページやメールなどの中に埋め込まれた指示をAIが誤って受け取る 「プロンプトインジェクション」のようなリスクも考える必要があります。
Anthropicは、安全分類器や権限制御などの対策を用意していますが、 ブラウザを直接操作する以上、 自由度と安全性のバランスは重要になります。
現在のClaude in Chromeには、 3種類の権限モードが用意されています。
Manual
操作ごとに人間の確認を求めながら進めるモードです。
Auto
Claudeに作業を進めさせつつ、 危険と判断された操作は安全分類器によって自動的にブロックするモードです。
Skip
確認や自動チェックを行わずに進めるモードです。
つまりブラウザ型のAIでも、
考え方になっています。
一方、DSC Builderでは、 安全装置の考え方が少し違います。
別のSharePointサイトは操作できない。
任意のURLは受け付けない。
できる操作も決まっている。
つまり、
広い世界を歩けるAIを、どう安全に監督するか
API型
歩ける世界そのものを、最初から狭く設計するか
という違いがあります。
８．「GPTがプラットフォームになる」という未来と、別の未来
ここが今回、 一番面白いと思ったところです。
GPTが登場した2023年には、
ような未来が見えました。
GPT Storeがあり、 専門GPTが並び、 それぞれが外部APIへ接続する。
ユーザーはまずChatGPTへ来て、 そこから必要なサービスを使う。
これは、
です。
しかしClaude in Chromeを使ってみると、 まったく別の未来も見えます。
今あるWebサイトや業務システムは、 そのままでいい。
SharePointも、そのまま。
管理画面も、そのまま。
人間向けにつくられた画面を、 AIも操作できるようになればいい。
つまり、
AIが人間向けの画面を使えばいい。
という未来です。
これはかなり発想が違います。
AIのところへ、サービスを持ってくる
Claude in Chrome型
サービスはそのままにして、AIをそこへ送り込む
私は、今回実際に両方を触ったことで、 この違いがとてもはっきり見えました。
９．では、どちらが向いているのか
ここまで比較すると、
「では、結局どちらが正しいのか」
という話になります。
しかし私は、 今のところどちらか一方になるとは思っていません。
むしろ仕事によって分かれるのではないかと思います。
API型が向いている仕事
- 毎日、毎週、毎月、同じ処理をする
- 権限や個人情報を扱う
- 失敗したときの影響が大きい
- 実行履歴を残したい
- 同じ結果を安定して繰り返したい
ブラウザ型が向いている仕事
- 一度しかやらないかもしれない
- どの画面へ行くか事前に分からない
- APIが提供されていない
- 古い管理画面を使わなければならない
- いろいろなWebサービスを横断したい
今の段階では、
探索的な仕事はブラウザ型。
という使い分けが、 かなり自然に思えます。
そして将来、 この二つが近づいていく可能性もあります。
最初はブラウザ型AIに自由に仕事をしてもらう。
よく使う仕事が見えてきたら、 それを専用のAPIやワークフローへ落とし込む。
あるいは逆に、 専用APIでは対応できない例外だけをブラウザ型へ渡す。
そんな組み合わせも考えられます。
１０．Microsoftの仕組みを一通り使ってみて分かったこと
DSC Builderをつくるために、 今回はMicrosoftのさまざまなサービスを実際に使いました。
- SharePoint
- Microsoft Entra ID
- Azure Functions
- Azure Key Vault
- 証明書
- API
- OpenAPI
以前から名前は知っていたものもあります。
でも、自分で組み合わせて本当に動かしてみると、 理解の仕方がまったく違います。
「ああ、Entra IDというのは、 AIにこういう身分証を持たせるためにも使えるのか」
「Key Vaultは、 この秘密をここに置くためにあるのか」
「APIというのは、 単にシステム同士をつなぐだけではなく、 AIが安全に仕事をするための“道”にもなるのか」
それまで単なる製品名だったものが、 一つの仕組みとしてつながりました。
もちろん、かなり面倒でした。
動かない。
直す。
また試す。
今度は別のところで止まる。
それでも、 自分がChatGPTへ、
と頼む。
すると、自分でつくった仕組みを通って、 本当にSharePointが動く。
これは、やはり面白い体験でした。
１１．「AIが何をできるか」より、「どう仕事を渡すか」
今回、Claude in ChromeとDSC Builder GPTを比べてみて、 AIエージェントについての見方が少し変わりました。
重要なのは、
「AIはどこまで賢くなるのか」
だけではないのだと思います。
むしろ、
そこが、これから大きなテーマになりそうです。
自由に画面を動かしてもらうのか。
専用のAPIを用意するのか。
どこまで任せるのか。
どこで人間が確認するのか。
手綱を人間が握るのか。
それとも、 手綱そのものをシステムの中へ組み込むのか。
2023年にGPT Storeが発表されたとき、 私は「AIの中にさまざまなアプリが集まる未来」を想像しました。
そして今回Claude in Chromeを使ってみて、
AIが今あるアプリを使いに行けばいい。
という、もう一つの未来があることに気づきました。
どちらが主流になるのか。
それとも、 この二つが混ざっていくのか。
今の段階では、 まだ分かりません。
ただ、実際に作ったり使ったりしてみると、
すでにかなり違う未来の形が競い始めている。
そんなことを感じています。