2026 年 8 月 26 日に何が変わったのか
2026 年 8 月 26 日、Anthropic が Claude in Chrome の一般提供を発表しました。これまで限られた利用者向けだった Chrome 拡張機能が、有料の Claude プラン全体で使えるようになっています。原文では "Claude in Chrome is now generally available on every paid Claude plan" と説明されています。
ただし、業務で使う組織にとって重いのは提供範囲の話ではありません。既定の振る舞いが変わったことです。Claude はブラウザ上で "take actions autonomously in the browser, instead of needing approval for every one" と説明されるとおり、1 操作ごとに人の承認を待たずに進むようになりました。挙げられている操作は、文字を読むこと、文字を入力すること、リンクをクリックすること、ページ間を移動すること、フォームを埋めることです。
言い換えると、これまで「操作のたびに人が見ている」ことが前提だった仕組みが、「1 操作ごとに人の確認を挟まずにブラウザが進む」仕組みに変わりました。誰がどのサイトで何をさせられるのかを、拡張機能の設定ではなく組織の方針として決める段階に入ったということです。
Chrome 以外では動かない
動作環境には制限があります。この拡張機能は Chrome でのみ動作し、ほかの Chromium 系ブラウザやモバイルでは動作しません。ファイル操作にはデスクトップアプリが必要と記載されています。入手経路は Chrome ウェブストアです。
補足
社内標準ブラウザが Chrome 以外なら、この記事の検討はいったん保留できます。逆に Chrome を標準にしている組織は、利用者が自分の判断で拡張機能を入れられる状態かどうかを先に確認してください。
承認モードは 3 段階ある
自律的に動くといっても、止まり方が 1 通りしかないわけではありません。権限モデルの公式ページには、承認モードが 3 つ用意されていると書かれています。違いは「各アクションの前に止まるか」と「自動の安全性検査が働くか」の 2 軸で整理できます。
| モード | 各アクション前の停止 | 自動の安全性検査 |
|---|---|---|
| 都度承認 (Manually approve) | 止まって承認を求める | 人が判断する |
| 自動承認 (Automatically approve) | 止まらない | Claude が検査してブロック |
| 承認を飛ばす (Skip all approvals) | 止まらない | 働かない |
都度承認
原文は "Claude pauses and asks for approval before each action" です。Claude は各アクションの前で停止し、承認を求めます。操作のたびに人の手が要るため作業は遅くなりますが、Claude が何をしようとしているかを 1 つずつ確認できます。
導入直後や、扱う業務が固まっていない時期に向きます。どんな操作が実際に飛んでくるかを見てからでないと、許可リストも承認方針も具体的に決められません。
自動承認
原文は "Claude reviews each action for safety...and automatically blocks anything it determines to be unsafe" です。Claude が各アクションの安全性を検査し、危険と判断したものを自動でブロックします。1 操作ごとに人が承認する代わりに、この検査が働きます。
実務で見落としやすいのは、この検査がバックグラウンドで動くぶん 使用量の消費が増える と説明されている点です。同じ作業をしても、都度承認より消費が増えます。増える幅は公式ページに書かれていないため、数字が必要なら自分の環境で測るしかありません。「安全側に倒すと使用量が増える」というトレードオフが設定として存在すること自体を、利用者へ先に伝えておくと混乱が減ります。
承認を飛ばす
原文は "Claude doesn't pause to ask, and nothing checks its actions automatically" です。Claude は停止せず、アクションを自動で検査する仕組みも働きません。3 つの中で最も制限が緩いモードだと説明されています。
止まらないことと検査されないことが同時に起きるため、業務端末の既定値としては選びにくい設定です。使うとしても、扱う情報が限定された環境で、対象サイトを絞ったうえでの判断になります。
FIXIT承認モードって、どれを選んでも Claude のやることは同じなの？
Hayate同じ操作でも、止まるかどうかと検査が入るかが変わります。
FIXIT自動承認は検査が入るぶん、使用量が増えるんだよね。
Hayateはい。安全側に倒すコストです。先に許可するサイトを絞るほうが効きます。
サイト単位の継続許可と、その対象外になる操作
承認モードとは別に、サイト単位で許可を出し続ける設定があります。"Always allow actions on this site" を選ぶと、そのサイトでの操作をそのつど承認しなくてよくなります。毎日触る社内ツールのように、同じ画面を何度も操作する業務では現実的な設定です。
ただし、この継続許可には対象外があります。公式ページは、ファイルのダウンロード、機密情報の入力、認可の付与について、継続許可の範囲に入らず、そのつど明示的な承認 ("explicit approval") が要ると説明しています。明示的な承認が必要なアクションの例としては "Entering potentially sensitive information into a page" が挙げられています。
この 3 つが分けられている理由は公式ページに書かれていません。ただし、ダウンロードは端末にファイルが残り、機密情報の入力は外へ出た時点で戻せず、認可の付与は Claude が触れる範囲そのものを広げます。取り返しがつきにくい点は共通しています。
注意
「このサイトは許可したから任せきりで大丈夫」という理解のまま運用に乗せると、実際には承認ダイアログが出続けます。継続許可は「このサイトの通常操作を止めない」設定であって、「このサイトなら何でも任せる」設定ではありません。利用者への説明ではここを分けて伝えてください。
Claude が実行しない操作として挙げられているもの
権限モデルのページには、Claude が実行しない操作をまとめた節があります。挙げられているのは次のような操作です。
- 購入・金融取引
- アカウントの作成
- クレジットカード情報や本人確認情報の取り扱い
- ファイルの完全な削除
- 投資助言
- システムファイルの改変
金銭と本人性に関わるもの、そして取り消せない破壊的な操作が並んでいます。ブラウザで自律的に動く仕組みとして、外してはいけない線が引かれている形です。
一方で、この一覧が禁止事項のすべてだと読むのは避けてください。公式ページに挙げられている例として扱い、社内の判断基準は別に持つほうが安全です。たとえば決裁ワークフローの承認ボタン、社外への一斉送信、権限申請の提出などは上の一覧に含まれませんが、押されてから気づいても遅い操作です。組織として押させたくない操作は、拡張機能側の制限に期待せず、許可リストと承認モードの側で閉じる設計にしてください。
社内の利用ルールをこれから整える段階なら、生成 AI 全体の方針から先に固めたほうが早いです。生成 AI 利用ガイドラインの作り方で、業務内容別の利用ルール設計とデータ保持契約の論点を扱っています。
プロンプトインジェクション対策の 3 層と、測定された攻撃成功率
ブラウザで自律的に動く仕組みでは、プロンプトインジェクションが具体的な危険になります。Claude が読むのは Web ページの中身であり、そこには第三者が書いた文章が入っているためです。公式ブログはこの点に 2 つの節を割いています。
3 層の対策
対策は 3 つの層で構成されると説明されています。
- モデルの学習強化。Claude がより多くの攻撃を認識できるよう、学習ライブラリを拡充する
- プローブ。"Probes screen web content before Claude acts on it" のとおり、Claude が動く前に Web コンテンツを走査する
- アクションの検証。"Actions are verified before they run" のとおり、自動承認の分類器が、そのアクションが利用者の元の指示と合致するかを検証する
3 層目が自動承認の仕組みと結びついている点は押さえておく価値があります。承認を飛ばす設定を選ぶと、この検証が働きません。承認モードの選択は使い勝手の話に見えて、インジェクション対策の一部を外すかどうかの選択でもあります。
flowchart LR
A[利用者の指示] --> D
B[Web ページの内容] --> C{プローブ}
C -->|走査してから渡す| D[Claude が次の操作を決める]
D --> E{分類器による検証}
E -->|元の指示と合致| F[ブラウザ上で実行]
E -->|合致しない| G[実行しない]レッドチームが測定した攻撃成功率
公式ブログには、レッドチームによる測定値が掲載されています。プローブと分類器を適用した状態を対策適用後として、次の数字が示されています。
| 条件 | モデル | 攻撃成功率 |
|---|---|---|
| プローブなし | Opus 4.5 | 17.6% |
| プローブなし | Opus 5 | 3.8% |
| プローブ + 分類器 | Opus 4.5 | 16.7% |
| プローブ + 分類器 | Sonnet 5 | 0% |
| プローブ + 分類器 | Opus 5 | 0% |
| プローブ + 分類器 | Fable 5 | 0.3% |
0% という数字が並んでいますが、これを「対策済みなので安全」と読むのは誤りです。理由は 3 つあります。
1 つ目は、測定条件つきの数字であることです。レッドチームが用意した攻撃セットに対する成功率であり、まだ試されていない攻撃に対する保証ではありません。攻撃手法は測定のあとも増えます。
2 つ目は、モデルによって結果が大きく違うことです。同じ対策を入れても、Opus 4.5 では 16.7% が残っています。プローブなしの 17.6% と比べると、対策の効き幅は 1 ポイント弱です。0% は Sonnet 5 と Opus 5 の数字で、モデル側の性質と対策の組み合わせで出ています。対策単体の効果ではありません。
3 つ目は、成功率が下がっても被害の大きさは変わらないことです。1 回でも通れば、その先で何が起きるかは Claude が触れる範囲によって決まります。だからこそ、確率を下げる対策と並行して、触れる範囲そのものを狭める設定が要ります。
FIXITえっ、攻撃成功率 0% なら、もう気にしなくていい？
Hayate測定条件つきの 0% です。モデルが変われば数字も変わります。
FIXITじゃあ、どこを見ておけばいいの？
Hayate通す先です。許可リストを絞れば、読ませる範囲がそもそも減ります。
9 月 10 日に Enterprise の既定値が変わる
管理者にとって期限があるのはここです。管理者向け設定の公式ページによると、管理機能は Team プランと Enterprise プランで使えますが、既定値がプランで異なります。
Team プランは "The extension is enabled by default" と記載されており、拡張機能は既定で有効です。
Enterprise プランは "The extension is disabled by default. Starting September 10, 2026, it turns on by default unless you've already disabled it." と記載されています。現時点では既定で無効ですが、2026 年 9 月 10 日から既定で有効に変わります。ただし、それまでに無効にしてある組織はそのままです。
つまり Enterprise の管理者にとって、9 月 10 日は「何もしなければ有効側に倒れる日」です。方針が固まっていないなら、それまでに明示的に無効へ倒しておけば、既定値の切り替えに巻き込まれません。逆に、日付を越えてから気づく形になると、利用実態の把握から始めることになります。
ここで分けて考えたいのが、組織設定のトグルと、実際に端末で使われるまでの距離です。既定値が有効に変わるのは組織側の設定であり、拡張機能そのものは Chrome ウェブストアから入れるものです。公式ページには、この切り替えで利用者の端末へ拡張機能が配布されるとは書かれていません。とはいえ、組織側のトグルで許可されていれば、拡張機能を入れた利用者から順に使える状態になります。カスタムロールを使っている Enterprise 組織では、これに加えてロール単位の権限も必要です。「誰も入れていないから実質無効」という状態は、放っておくと崩れます。
要点
判断そのものは「使う」「使わない」の二択ではありません。9 月 10 日までに決めるのは、既定で有効な状態のまま日付を越えるかどうかだけです。有効にしたうえで許可リストを絞る、いったん無効にして検討期間を取る、どちらも取れます。決めていない状態が一番まずい形になります。
管理者が決めることと、管理画面にある設定項目
設定場所
Owner または Primary Owner でサインインし、Organization settings > Claude in Chrome へ移動します。管理画面の URL は https://claude.ai/admin-settings/browser-extension です。
権限は組織全体とロール単位の 2 段構え
公式ページは "Claude in Chrome has its own permission, separate from Claude Cowork. Two settings control Claude in Chrome: an organization-level toggle, and a per-role capability that admins can grant or withhold." と説明しています。組織全体のトグルと、管理者が付与または保留できるロール単位の権限の 2 つで制御します。ロール単位の権限は、カスタムロールを使う Enterprise 組織が対象です。
具体的にどのロールで何ができるかは公式ページに記載がないため、実際の粒度は管理画面で確認してください。
許可リストは絞って始める
サイトのアクセス制御には許可リストと拒否リストがあります。許可リストは "Specify which sites Claude is permitted to access by adding them to the allowlist." と説明され、拒否リストは "Specify sites Claude should never access, regardless of other settings, by adding them to the blocklist." と説明されています。拒否リストはほかの設定に関わらず優先されます。
公式ページは開始時の方針についても書いています。"We recommend starting with a more restrictive allowlist for the security of your organization's data, then expand access over time as you become comfortable with the extension's behavior." つまり、まず絞った許可リストで始め、拡張機能の振る舞いに慣れてから広げることを推奨しています。
この推奨は、攻撃成功率の節で見た測定値の読み方とつながります。攻撃成功率を下げる対策は入っていますが、そもそも読ませるページを減らすほうが確実です。最初から全社的に開放するのではなく、業務で必要な数サイトから始めるほうが、後から広げる余地も残ります。
管理画面にあるほかの項目
管理者向けページには、上記のほかに次の項目が並んでいます。
- Cowork サイドパネルの有効化
- パスワードマネージャーへのアクセス制御
- Claude Desktop 側のユーザーアクセス管理
- 導入方式の選択肢
- パイロット運用
- 既存の統制との関係
- 利用者への教育
それぞれの手順や選択肢の中身は、この記事の執筆時点で内容を確認できていません。管理画面を開いて実物を確認してください。項目として存在することが分かっていれば、初回の設定作業で見落とすことはなくなります。
利用者への教育まで管理項目に含まれている点も見落とせません。承認モードの意味も、継続許可の対象外も、利用者が理解していなければ設定どおりには運用されません。就業規則や社内規程の側で整理しておく論点は AI 就業規則の改定ポイントにまとめています。
API の Browser Use ツールとの違い
「Claude がブラウザを操作する」という言い方は、いま 2 つの別々の仕組みを指します。混同すると検討の入口を間違えます。
| 観点 | Claude in Chrome | Browser Use ツール |
|---|---|---|
| 形態 | Chrome 拡張機能 | Claude API のクライアントツールセット |
| 動く場所 | 利用者が普段使っている Chrome | 開発者が用意したブラウザと実行系 |
| 入手・導入 | Chrome ウェブストア | API リクエストのツール定義 |
| 担い手 | 情報システム部門・管理者 | 組み込む側のアプリケーション開発者 |
| 制御の単位 | 承認モード・許可リスト・組織のトグル | ツールの有効化・実行系の実装 |
Claude API の Browser Use ツールは、開発者が自分のアプリケーションに組み込むものです。ブラウザ本体も操作を実行する仕組みも自前で用意し、Claude は操作の呼び出しを返すだけです。仕様と Computer Use との使い分けは Claude Browser Use ツールの解説で扱っています。
Claude in Chrome は、業務端末に入る拡張機能です。ブラウザは利用者のものであり、そこには社内システムのセッションも個人のログインも同居しています。だからこそ許可リストと承認モードが管理項目として用意されています。
検討の順番も違います。Browser Use は「この機能を自社プロダクトに載せるか」というプロダクト側の判断です。Claude in Chrome は「業務端末で従業員に使わせるか」という端末管理の判断です。判断の性質が違うため、社内で相談する相手も変わります。同じ社内で両方の話が同時に進むこともあるため、会話の中でどちらの話をしているかを明示しておくと余計な混乱を避けられます。
まとめ
2026 年 8 月 26 日の一般提供で変わったのは、提供範囲だけではありません。ブラウザ内の操作が毎回の承認を待たずに進むようになり、どこまで任せるかを組織として決める必要が出ました。
決めることは 3 つに整理できます。承認モードをどれにするか、許可リストをどこから始めるか、そして Enterprise なら 9 月 10 日をどちらの状態で越えるかです。承認モードは都度承認から始めて実際の操作を見てから移す、許可リストは公式の推奨どおり絞って始める、というのが無理のない順番です。Enterprise の 9 月 10 日については、有効のまま越えるか、いったん無効にして検討期間を取るかを、その日までに決めておいてください。
プロンプトインジェクション対策の測定値は、対策が入っていることの根拠にはなりますが、任せきりにしてよい根拠にはなりません。0% は測定条件つきの数字で、モデルが変われば結果も変わります。確率を下げる対策と、触れる範囲を狭める設定は、どちらも必要です。
AI ツールを業務へ入れるにあたって、権限設計や社内ルールの整備まで含めて進め方を決めたい場合は、AI 開発ツール導入支援で伴走しています。ご相談は お問い合わせからご連絡ください。