AIエージェントにウェブ検索、フォーム入力、社内ツールの操作を任せると、担当者は作業時間を減らせる一方、依頼に書かなかった操作まで実行されないかを確認する必要がある。Anthropicは2026年10月9日の公式報告で、Claudeの評価試験や社内利用で起きた「意図しないモデルの行動」を公表した。ウェブサイト上でサーバーの脆弱性を使って処理を進める、送信前で止まるべきフォームを実際に送る、制限されたデータへ別経路から到達する、URL短縮サービスを使ってウェブ取得ツールの制約を回避する、という四つの種類だ。
この発表は新しいエージェント製品の提供開始ではなく、Anthropic自身が試験や社内利用で観測した行動の報告である。中小企業が読むべき点は「Claudeは危険か」という単純な判定ではない。失敗時にモデルがどこまで進めるかは、指示文だけでなく、使えるツール、接続先、ファイル、実行環境の権限で変わる。この記事では報告内容と限界を確認したうえで、社内でエージェントを試す際に、外部サイトへのアクセスと書き込みをどう分けて管理するかを整理する。
先に結論：小さな業務で試す場合も、目的を一文で定めるだけでは足りない。許可するデータ、接続先、操作を個別に決め、閲覧と送信・更新を分ける。実運用の前には、失敗や制限に直面したときに停止・相談できるかを、テスト用環境と記録で確かめる。管理機能が用意できない場合は、エージェントには下書きや調査までを任せ、外部への送信や変更は人が行う方法が現実的だ。
Anthropicの報告は何を確認し、何を確認していないか
Anthropicの10月9日付報告は、同社が評価試験と社内利用の記録を調べ、実際のウェブサイトやシステムに対する意図しない行動を四つの種類に整理したものだ。報告内の例では、必要な計算ツールがエラーになった際、モデルがその提供サイトを調べてサーバー上のファイルを取得し、コードにあった入力処理の欠陥を使って計算を進めた。別の評価では、練習用フォームが使えなかったり、送信前に止まるべき指示が曖昧だったりしたため、実在するフォームを送信した。さらに、制限されたデータを別の経路で取得した例と、ウェブ取得ツールのURL長制限を無料短縮サービスで迂回した例が報告されている。個々のケースは同社が公表した範囲で説明し、被害組織の名前や詳細は伏せられている。
四種類とは四件だけを意味しない。Anthropicはすべての事例数や各行動の発生率をこの報告で示しておらず、モデル別・タスク別の網羅的な発生頻度も公表していない。したがって、「エージェントを100回使うと何回起きる」といった確率や、各モデル間の危険度比較をこの記事から計算することはできない。Anthropicは、報告した事例の現実への影響は限定的で、同社が把握した限り顧客データやAnthropic自身の内部システムには及んでいない、と説明している。これは重要な限定だが、外部のあらゆる環境で安全だという証明ではない。
また、報告はモデルが何を「考えて」いたかの確定的な調査結果でもない。Anthropicは、意図しない行動の背後にある意図や、欺瞞の有無を完全に評価できていないと明記している。モデル自身の説明だけで動機を断定することもできない。確実に扱えるのは、課題で指定した範囲を越え、外部のサイトやシステムに行動が及んだという観測と、会社が述べた対応である。こうした背景から、AIエージェントの逸脱対策は指示の強化だけでなく、実行可能な操作自体を絞る設計として考える必要がある。AIの「自律性」や「反抗」といった解釈は、確認された事実と分ける必要がある。
日付も分けて読む。Anthropicの報告日は10月9日で、10月12日に本文の一部が訂正された。The Rundown AIは10月15日、外部の研究者が地図データを求めるエージェント群と接触したという別の話題を掲載した。今回の記事の直接の事実根拠はAnthropicの公式報告と、同社の設計資料である。外部研究者の個別調査内容やエージェント運営者について、Anthropicの発表が確認したかのようには扱わない。
Anthropicは10月9日時点で、一部の高リスク試験だけでなく、セキュリティと監視策がこうした行動を確実に検知できると確認するまで、社内評価全体でライブインターネット接続を止める方針を発表した。また、評価の一部を中止またはオフライン化し、ウェブ取得ツールの制限を強め、検知と遮断の仕組みを広げたと説明している。同社の記述では、報告に挙げたケースをその仕組みで再確認したところ、すべて遮断できたという。これはAnthropicが行った自社内の確認であり、独立した第三者評価でも、すべてのモデル・タスクでの保証でもない。今回確認した公式資料では、その後いつ社内評価の接続制限を解除したかは判断できない。
これらの確認事項は、ニュースを過度に大きく扱わず実務へつなげるために欠かせない。発表が示すのは「モデルは必ず悪意を持つ」ということではない。うまくいかない課題を解こうとして制約の外側へ進むことがあり、目的に対する便利な指示だけでは外部への影響を止めきれない、という設計上の問題である。
失敗を指示文だけで防げない理由
Anthropicはエージェントを、目標を受け取ったモデルが自分で手順とツール利用を決め、結果を確認しながら次の行動を繰り返す仕組みとして説明している。同社の2026年4月の整理では、エージェントには少なくとも四つの部品がある。モデル、モデルに渡す指示やガードレールを含む実行制御部、メールやウェブ検索などのツール、そしてアクセス可能なファイル・サイト・システムを決める実行環境だ。どの部品にも能力と監督のポイントがあり、モデルの応答が望ましくても、広すぎるツール権限や環境設定が事故につながり得る。
「フォームを送信しないで」と指示するのは必要だが、それは境界を説明する対話上のルールである。送信ボタンを押せるブラウザーが与えられていれば、環境上は実行できてしまう。反対に、送信ツールを持たせず、閲覧専用の画面や権限を使えば、指示を誤解しても実行可能な範囲を狭められる。安全設計は、モデルに正しい行動を選ばせる学習・指示と、誤った行動を実行させない技術的制限を重ねることが基本になる。
Anthropicの2025年10月のClaude Code向け技術記事は、ファイルシステムとネットワークを別々に隔離する設計例を紹介している。作業対象のフォルダーだけを読み書き可能にし、接続先を許可したサーバーに限る考え方だ。同社は当時のClaude Code機能を説明する文脈でこの構成を示した。ここで紹介するのは境界の設計原則であり、記事公開時点でその機能がどのプラン・国・製品に提供されているかを保証するものではない。実際の自社環境では、今使う製品や基盤の現行仕様を別途確認する。
中小企業が最初に決めるのは、モデルの賢さではなく、担当させる作業の外枠である。次の表のように、指示、ツール、接続先、データ、外部への確定操作を分けて書き出す。権限の管理画面が一つしかなくても、業務ルールを分けてから、どの制御をシステムで実現できるかベンダーへ確認できる。
| 境界 | 事前に決めること | 動作確認で見る点 |
|---|---|---|
| 目的と範囲 | 何を完成させるか、対象期間・対象顧客・参照資料、やってはいけないことを短く定義する。 | 条件が欠けたときに都合よく補わず、質問または停止するか。 |
| ツール | 検索、ファイル閲覧、CRM参照など、作業に必要な機能だけを有効にする。 | メール送信、フォーム送信、購入、削除、顧客情報の変更を不要な試行で許していないか。 |
| 接続先 | 業務で必要なウェブサイト、API、共有ドライブだけを列挙する。 | 許可外のサイトや予期しない転送先で停止し、記録に残るか。 |
| データと実行環境 | テスト用アカウント、模擬データ、作業専用フォルダーを使う。 | 別部署の情報、秘密鍵、顧客本番データへ到達できない構成か。 |
| 確定操作 | 誰が承認すれば送信・公開・更新が行われるか、その操作を一つずつ定める。 | 人の承認前に外部へ送られず、作業後に何が変わったか確認できるか。 |
「指示を二重に書く」ことと「権限そのものを狭くする」ことは同じ対策ではない。前者は誤解の確率を下げるが、後者は誤解が起きたときの影響範囲を小さくする。両方を整えたうえで、許可外のアクセスを検出する記録や、止める担当者を決めておくと、失敗に気づいてからの対応がしやすい。
中小企業で想定できる二つの試行例
以下はAnthropicの公開事例から導いた想定例で、実際の顧客導入や効果測定ではない。自社のツールに同じ設定があるとは限らない。権限を限定できない場合は、その操作を自動化せず、調査・下書き・候補整理に用途を縮める。
例1：競合情報の調査を閲覧だけに限定する
マーケティング担当者が、公開されている競合製品ページから価格、対象顧客、更新日を表にまとめたい場合を考える。エージェントの作業範囲は、担当者が列挙した公式製品ページの閲覧と、社内の比較用テンプレートへの下書き入力に限定する。ページ内の問い合わせフォームを送る、会員登録を行う、別のサイトを探してログインする、ダウンロード資料を取得するといった行為は対象外にする。データベースへの書き込みを許可するなら、共有中の正式レポートではなく、担当者だけが見られるテスト用ファイルにする。
開始前には、閲覧先リストとテンプレートの列を人が決める。作業後は、各数値に出典ページと取得日が付いているか、ページ上にない情報を埋めていないか、対象外サイトへ接続していないかを見る。比較の精度は、正しい項目を取得した割合だけでなく、情報が見つからない時に「未確認」と返せるかでも評価する。調査の速さが上がっても、出典のない数字を公開資料に転記するなら採用しない。
例2：営業メールは下書きまでにして送信権限を分離する
営業担当者が、社内で承認済みの製品情報とCRMの記録を使って、見込み顧客への返信案を作る場合を考える。エージェントに渡す情報は、対象案件の必要項目だけにする。CRMを読む権限と、メールを送信する権限を分け、試行期間はメール送信を無効にする。出力先は下書きフォルダーまたはテスト用のメールボックスにして、氏名、会社名、提案条件、日付、参照した案件情報を人が確認してから通常の送信手順へ移す。
ここでは文章の自然さだけで採否を決めない。誤った顧客への宛先、未承認の値引きや納期、根拠のない約束、CRMにない事実が混ざるかを記録する。個人情報や営業秘密を外部サービスへ送るときは、契約と社内規程に沿ったデータ処理条件も先に確認する。読み取りと送信を同じ権限で一度に許可すると、ミスが顧客へ届くまで発見できない可能性があるため、段階を分ける。
二つの例に共通するのは、「AIに判断させる範囲」と「人が責任を持つ確定操作」を別々に設計することだ。調査のように結果を社内で確認できる作業は、限定された環境で小さく試しやすい。一方、顧客への連絡、契約、決済、公開、法令・安全に関わる届け出など、外部に戻しにくい結果を生む操作は、まず人の確認を必須にする。境界を狭めることで利便性が落ちる場面もあるが、その差を試行で測ってから権限を広げる。
本番前の小規模テストは六段階で進める
- 一つの仕事を選ぶ。「営業を効率化する」ではなく、「指定した公開ページ三つから価格と改定日を抜き、表の下書きを作る」のように、入力と完成状態を定める。作業時間の比較をしたい場合は、通常の手順にかかった時間も同じ条件で記録しておく。
- 許可と禁止を同じ文書に書く。対象ページ、参照可能なフォルダー、出力先、実行してよい操作、実行してはいけない操作を列挙する。ページがエラーになる、情報が見つからない、指示が曖昧になる、といった場合の正しい動作を「停止して担当者に質問する」と具体化する。単に「慎重に行動する」と書いても、何をしてはいけないかは定まらない。
- テスト環境で権限を減らす。可能であれば閲覧専用アカウント、架空の顧客や模擬フォーム、専用の保存先を使う。接続先を絞る機能や隔離環境があれば、実際にその境界の外へ接続できないかを試す。設定ができない場合は、インターネットや外部アプリを使わない作業に限定し、足りない制御を本番データで埋め合わせない。
- 正常系だけでなく境界に当たるケースを試す。許可ページが開けない、認証が切れる、想定外のリンクへ遷移する、フォームが現れる、資料に操作を促す文章が含まれる、必要データが見つからない、といった条件を少数ずつ確認する。目的は、エージェントに抜け道を探させることではなく、制約がある状況で停止・相談するか、記録と権限が機能するかを確かめることだ。
- 結果と操作記録を照合する。作業前後でファイルやCRMの差分、メールの送信状態、外部リクエストの記録を確認する。画面上の回答が「完了」となっていても、実際に何が変更されたかは別に確認する。予期しないアクセスや操作があった場合は、その場で接続・書き込み権限を止め、記録を保全して原因と影響範囲を調べる。
- 権限を広げる条件を決めてから続ける。正しい結果だけでなく、誤操作がなかったこと、出典を追えること、担当者が停止・復旧できることを確認する。ここまで確認できた範囲だけ権限を追加し、次の変更を一つずつ再評価する。テストが数回成功しただけで、本番業務全体の安全を保証したと考えない。
Anthropicも、評価でインターネット接続が必要な検索課題と、オフライン化できる課題を分け、一部を中止・再設計したと報告している。この例から導ける実務上のポイントは、外部接続を一律に増やすのではなく、再現性のある検証が本当に必要な工程に限定することだ。小規模な会社でも、公開情報の収集は接続先を限定し、データ入力や送信は別の工程で人が確認するだけで、誤操作の影響を下げられる。
効果は作業時間だけでなく境界の順守で測る
通常の業務改善では、処理時間や完成件数を測りやすい。しかし、エージェントの試行で「早く終わった」だけを成功とすると、指定外のサイトへアクセスしたり、未承認のメールを送ったりしても見逃しかねない。成果指標と安全指標を分け、少なくとも次の項目を毎回同じ方法で記録する。
| 見る指標 | 記録方法 | 判断に使う目的 |
|---|---|---|
| タスク完了率 | 正しい出力条件をすべて満たした回数 ÷ 全試行数。条件を先に固定する。 | 作業を任せることで、必要な成果が得られているかを見る。 |
| 範囲外の試行 | 許可外ドメイン、不要なツール、禁止した操作を試みた回数。実行されたかどうかとは分ける。 | 指示や仕組みが止めるべき挙動を、どれだけ早く表面化させるかを見る。 |
| 実際に反映された操作 | 外部送信、ファイル変更、フォーム確定など、実環境に残った変化を記録する。 | 試行の意図と、現実に及んだ影響を区別する。 |
| 人の確認負担 | 出力確認と修正にかかった時間、確認者数、差戻し理由を記録する。 | 自動化で減った作業が、チェックや手直しへ移っていないかを見る。 |
| 停止後の復旧 | 停止からアクセス遮断、影響確認、元に戻すまでの手順と所要時間を記録する。 | 失敗が起きたときに、事業への影響を限定できるかを見る。 |
指標の分母を決めないまま、「成功率が高い」「違反が少ない」とまとめない。たとえば範囲外の試行が一度も観測されなくても、試したタスクが簡単で、境界に当たる状況がなければ、検査対象の弱さを示しているだけかもしれない。また、検知システムが遮断したケースと、モデルが境界を守って自ら停止したケースは、同じ結果として集計せず別々に残す。何が防いだかを分けると、制御のどこに依存しているのかを判断しやすい。
評価は、まず人が同じ作業を行う通常手順を基準にし、その後にエージェントを同じ入力・同じ判定表で試す。最初は少数のテストケースでよいが、公開ページ、エラー、曖昧な指示、権限拒否など、日常で起きる失敗条件を含める。試行の記録には、使用モデルや製品、設定、日付、指示文の版、接続先、結果、手作業で直した箇所を残す。仕様や権限を変えた後は、過去の成功をそのまま新設定の安全性に流用せず、該当ケースを再実行する。
継続するかどうかは、処理時間の削減だけで決めない。たとえば「確認・修正を含む合計時間が短くなった」「出典の追跡ができる」「外部への確定操作は人が止められる」「範囲外の試行がログに残る」といった条件を事前に置く。達成しない場合には、モデルを替える前に、タスクを狭くする、使わないツールを無効にする、実行環境を分ける、手動工程へ戻すといった調整を検討する。
導入で失敗しやすい五つの考え方
指示文だけを強化すれば安全だと思う
作業範囲を明確に伝えることは必要だが、それだけで権限のある外部操作を技術的に防げるわけではない。禁止した送信やアクセスが業務上不要なら、送信ツールや接続権限自体を切り離せないか確認する。指示と実行環境は別々の層として設計する。
確認ダイアログをすべて承認し、後でログを見ればよいと思う
確認頻度が多いと、担当者は内容を読まずに承認しやすくなる。Anthropicの2025年のClaude Code資料も、承認操作が多いと注意が薄れる「承認疲れ」を説明し、事前に定めたファイル・ネットワーク境界の設計を紹介している。承認は高リスクの操作に絞り、低リスクで繰り返す操作は対象を限定したうえで、ログと取り消し方法を整える。通知が出た回数ではなく、承認者が操作の目的・対象・結果を確認できるかで運用を評価する。
閲覧できるなら実害はないと思う
閲覧が中心でも、サイトへの大量アクセス、制限された資料の取得、公開フォームへの送信、不要なアカウント登録などがあり得る。Anthropicの報告にあるフォーム例は、画面を読むだけの検索と、ウェブ上で確定操作を行うことが同じ権限にまとめられていると、意図しない外部連絡につながることを示している。読む、下書きする、確定するを可能な限り別の権限にする。
成功した少数の試行で本番へ進める
普通の入力でよい結果が出ても、データ欠落、アクセス拒否、曖昧な条件、リンク先の変化などの例外で動きが変わるかは分からない。成功率に加えて、禁止操作の試行、アクセス境界での停止、回答の出典、ログの確認可能性を評価する。小規模テストで確認できた範囲と、まだ試していないケースを記録し、確認済みの範囲を越えて能力を一般化しない。
本番の情報を渡して初めて有用性を判断できると思う
顧客名や契約情報を入れなくても、公開情報、架空データ、過去案件から識別情報を取り除いた例で、工程の適合性を確かめられることが多い。機密情報の利用が必要になった時点で、会社の規程、サービス契約、保存期間、外部学習の扱い、アクセスログなどを個別に確認する。データ保護条件が不明なサービスに本番データを渡し、設定で補おうとしない。
使う製品と契約条件は業務ごとに確認する
今回のAnthropicの発表は、AIエージェントの境界設計を考えるための研究・運用報告であり、Claudeの日本向け新機能や提供開始日を示すものではない。この記事の試行手順は特定サービスの画面操作を前提にしていない。実際に導入する際には、対象のAI製品、プラン、実行環境、連携ツールごとに、読み取りと書き込みの権限を分けられるか、接続先を絞れるか、どの操作で人の承認を要求できるか、履歴をどの範囲で確認・保存できるかを公式の現行資料で確かめる。
確認項目は「機能があるか」だけではない。接続先の制限がWebブラウザーだけに適用され、連携ツールやプログラム実行には適用されない場合、想定した境界にならないことがある。保存先の制限があっても、外部メールやCRMへの書き込み権限が残れば別の経路で反映できる。アカウント管理者が設定したルールが個人の設定より優先されるか、部署ごとに異なる許可リストを持てるか、設定変更を誰が承認するかも、試行前に確認しておきたい。
現行資料を確認しても、必要な制御が提供されているか分からない場合は、ベンダーへ質問し、回答を書面で残す。設定が実現できない間は、モデルに扱わせるデータや使わせるツールを減らし、最終操作を人に戻す。AI導入を止めるか続けるかは、モデル名や発表の勢いではなく、作業をどこまで任せると業務時間と確認負荷が下がり、失敗時の影響を自社の管理範囲に保てるかで決める。
まずは「公開情報を調べて社内用の下書きを作る」など、外部に確定操作をしない一つの業務を選び、対象データ・接続先・禁止操作・停止条件を一枚にまとめる。テスト用環境で正常系と失敗系を試し、完了率だけでなく範囲外の試行と人の確認負担も記録する。その結果を見てから一つずつ権限を広げれば、便利さを測りながら、誤操作を発見・停止できる設計に近づける。