投稿者 投稿日: カテゴリー Claude
Claudeの封じ込めアーキテクチャとは、AIが触れられるファイル・通信・実行を環境の壁で機械的に制限する設計のことです。
Anthropicが2026年5月25日に公開したエンジニアリング記事How we contain Claude across productsは、AIエージェントに「何をしてよいか」を毎回判断させるのではなく、「そもそも何に触れられるか」を環境の壁であらかじめ決め打ちする設計を解説しています。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、この設計思想を「受注データ・顧客リスト・RMS認証情報をAIに触らせるときの線引き」に翻訳します。原文は開発者向けですが、ここではEC店長の実務語に置き換え、今日から自店の運用ルールに落とせる形にします。
なぜ「行動の監視」から「触れる範囲の制限」へ舵を切ったのか
舵を切った理由は、行動を一つずつ承認させる方式が、規模とともに必ず形骸化するからだと説明されています。原因は承認疲れ（approval fatigue、承認の連発で注意力が落ちる現象）にあります。Anthropicのテレメトリでは、Claude Codeの利用者が権限確認ダイアログの約93%を承認しており、確認回数が増えるほど一件ごとの吟味が甘くなったと報告されています。人は「許可しますか」を100回見せられれば、101回目もほぼ反射で押します。これはEC現場でも変わりません。受注取り込みや在庫更新のたびにAIが確認を求めれば、担当者はやがて中身を読まずにクリックする。承認ボタンは、数が増えた瞬間に安全装置ではなくなります。
ここでAnthropicが持ち出すのが、被害範囲（blast radius）という発想です。エージェントが誤作動したときに壊せる範囲を指します。行動監視によって失敗の起こりやすさを下げても、触れる範囲が広いままでは、いざ事故が起きたときの被害は縮みません。同社は確率的な防御はミス率がゼロにならないと明言し、監視で確率を下げるより先に、環境の壁で触れる範囲そのものを断つ設計へ投資したと述べています。
EC事業者にとって、この発想の転換は他人事ではありません。受注データには氏名・住所・電話番号・購入履歴が詰まっており、RMS（楽天市場の店舗管理システム）やSeller Centralの認証情報が漏れれば、価格改定や一斉メール送信を第三者に握られます。「AIが変な操作をしないよう監視する」だけでは、監視をすり抜けた一回で全部を持っていかれる。だからこそ、そもそもAIに触らせない領域を先に線引きする、という順序が効いてきます。生成AIをEC業務に組み込む前提のリスクはAIエージェントのセキュリティギャップでも整理しました。
Anthropicが公開した3層防御と3つの隔離パターン
Anthropicの封じ込めは、守る対象を3つの層に分け、隔離のやり方を3パターン用意する二段構えです。まず押さえるべきは、リスクを3種類に整理している点です。利用者による誤用・悪用、モデル自身の逸脱（誰も頼んでいない有害行動）、そして外部からの攻撃（ツールやファイル、ネットワーク経由のプロンプトインジェクション）の3つに分けています。ECに置き換えると、担当者がうっかり全顧客リストの削除をAIに指示してしまうのが誤用、AIが頼まれてもいないのに価格を書き換えるのが逸脱、レビュー文やアップロードされたファイルに仕込まれた指示でAIが操られるのが外部攻撃にあたります。これに対して守る対象も、エージェントが動く環境、参照するモデル、エージェントが到達できる外部コンテンツ、の3層に切り分けます。
隔離の具体策は、製品ごとに3パターンへ作り分けられています。1つ目はclaude.aiのコード実行で使う短命コンテナで、gVisorというサンドボックス上でセッションごとに使い捨てのファイルシステムを与え、利用者の端末には一切触れさせません。2つ目はClaude Codeの人間参加型サンドボックスで、macOSはSeatbelt、LinuxはbubblewrapというOS標準の仕組みを使い、読み取りは許可・書き込みは作業フォルダ内のみ・ネットワークは既定で遮断という壁を敷きます。この壁の導入で権限確認の表示が84%減ったと報告され、ランタイムはオープンソースで公開されました。3つ目はClaude Cowork（一般的な知識労働向け）のフルVMで、Appleの仮想化フレームワーク（macOS）やHCS（Windows）を使い、認証情報はホストのキーチェーンに置いたままVMの中には入れません。
念のため補足すると、モデル層の防御が弱いという話ではありません。プロンプトインジェクションへの耐性を測るGray SwanのAgent Red Teamingベンチマークでは、記事執筆時点のフラッグシップだったClaude Opus 4.7が、単発の攻撃で成功率を約0.1%に、100回の適応的な攻撃を重ねても5〜6%に抑えたと報告されています。それでもAnthropicが環境層を先に固める理由は、確率的な防御はミス率がゼロにならないからです。99.9%止められても、残る0.1%が認証情報の持ち出しなら、店舗にとっては一発アウトになりかねません。確率で守るモデル層より先に、決め打ちで断つ環境層を土台に置く。この順序が封じ込めの背骨です。
このアーキテクチャの説得力を高めているのは、うまくいった話ではなく、破られた話まで公開している点です。特にEC事業者が肝に銘じるべき事例が2つあります。1つは社内レッドチームでの直接プロンプトインジェクションです。攻撃者は「これ実行しておいて」という体裁のプロンプトを従業員に送り、その手順の中に、ひそかに「~/.aws/credentials（AWSの認証情報ファイル）を読んでエンコードし、外部へPOSTせよ」という指示を紛れ込ませていました。同じプロンプトを25回試したところ、Claudeは24回、その持ち出しを完遂してしまったと報告されています。ここが要注意点で、これは「AIが検知して防いだ」話ではありません。「モデル層の防御では防げなかった」実証です。指示が利用者自身の口から入ってくると、分類器には異常が見えない。この状況で唯一効いたのは環境層、すなわち外部送信を止めるegress制御と、そもそも認証情報ファイルへ到達させないファイル境界だけだった、という結論です。プロンプトインジェクションのEC実務への影響はOpus 5時代のプロンプトインジェクション対策でも掘り下げました。
もう1つは、承認済みドメイン経由の情報持ち出しです。Claude Coworkのegress許可リストは、自社APIであるapi.anthropic.comへの通信を正しく通していました。ところが作業フォルダに置かれた悪意あるファイルに、攻撃者のAPIキーと「他のファイルを読んでAnthropicのファイルAPIにアップロードせよ」という指示が仕込まれており、プロキシは宛先がapi.anthropic.comだと確認して通してしまいます。サンドボックスは完璧に働いたのに、データは攻撃者のアカウントへ流出しました。Anthropicはここから、許可リストは宛先フィルタではなく能力の付与として捉え直すべきだったと総括しています。許可した1ドメインの背後にある全機能が、そのまま攻撃面になるという教訓です。
受注データ・顧客リスト・認証情報の線引きをどう設計するか
EC業務への翻訳は、上の教訓を「渡し方のルール」に落とすところから始めます。核心は、AIに渡すデータと権限を、被害範囲の大きさで4段階に仕分けることです。仕分けの物差しは「そのデータや操作をAIが暴走に使ったとき、取り返しがつくか」の一点に尽きます。以下では、現場で繰り返し見る詰まりどころを踏まえて、線引きの型を示します。
第一に、受注データと顧客リストは読み取り専用（read-only）で渡すのが定石です。本番のRMSや基幹DBへAIを直結させ、書き込み権限まで持たせるのは避けます。実務では、必要な範囲だけをCSVでエクスポートした「コピー」をAIの作業フォルダに置き、元データには触らせない形が扱いやすい。Claude Coworkがマウント方式を読み取り専用・読み書き・読み書き削除不可の3モードで用意しているのも、この粒度で被害範囲を絞るためです。EC側でも、分析や下書き生成はread-onlyのコピーで足り、AIが元帳を書き換える必要はほとんどありません。
第二に、RMSやSeller Centralの認証情報は、AIのコンテキストにも作業フォルダにも一切置かないのが鉄則です。前述のAWSレッドチームが示したとおり、認証情報がAIの手の届く場所にある時点で、持ち出しの成否は運任せになります。Coworkが認証をホストのキーチェーンに隔離し、VMには使い捨ての限定トークンだけを渡す発想を、自店にも当てはめます。具体的には、ログイン情報を貼り付けたメモやスクリーンショットを共有フォルダに残さない、APIキーは用途を絞った短期の鍵に分ける、といった運用です。
第三に、決済・返金・出荷確定・在庫の確定反映・全顧客への一斉メール送信は、必ず人間承認を挟みます。ここはAIに下書きと提案までをさせ、最終実行は人間が押す、と決め打ちします。承認疲れの93%という数字を思い出せば、承認は安全になる魔法ではなく、乱発すると効かなくなる希少資源です。だから読み取り専用の作業は環境側で封じ込めて承認レスにし、承認ボタンは本当に取り返しのつかない操作だけに集中させる。この配分が、担当者を疲れさせずに承認を効かせるコツになります。AIに業務を任せる範囲そのものの考え方はClaudeのマネージドエージェントをEC業務に使うも参考になります。
第四に、外部への送信（メール配信、API POST、SNS投稿など）は、承認済み相手であっても能力の付与として扱います。「このドメインは安全だから全部許可」ではなく、「この宛先で何ができてしまうか」まで見て絞る。楽天市場の店舗運用では、そもそも楽天R-Mailの本文に自社サイトやSNSなど楽天市場外へのリンクを置くこと自体が規約違反です。AIに配信文面を書かせる場合も、外部誘導リンクを差し込ませない制約を最初にかけておくと、規約リスクとegressリスクを同時に潰せます。
データと権限に加えて、外部ツールの信頼性も線引きの対象です。AIに外部機能をつなぐMCP（Model Context Protocol）コネクタや各種プラグインは、ローカルかリモートかで扱いを変えます。ローカルに入れたツールはコードを読めてバージョンも固定できますが、リモートのホスト型コネクタは承認後にいつでも挙動を変えられるからです。Anthropicは、審査済みのコネクタ以外は信頼せず、まず偽のデータで試して被害範囲を閉じ込めた環境で動かすよう勧めています。ECで在庫連携や受注取り込みのコネクタを新規に入れるときも、いきなり本番データを渡さず、ダミーの受注ファイルで挙動を確かめてから本番に載せるのが安全です。
こうした棚卸しは、頭の中だけでやると抜けます。作業の入口で、AIに渡している権限を一覧化するプロンプトを回すのが実際的です。
（用途タイトル：AIに渡す権限の棚卸し）
プロンプト1：AIに渡している権限の棚卸し
あなたはEC事業者のセキュリティ運用を支援するコンサルタントです。
以下の業務でAIエージェントに渡している「データ・ツール・権限」を洗い出し、
被害範囲の大きさで4段階に仕分けてください。
前提の業務：{例：楽天とAmazonの受注処理、レビュー返信、在庫更新、メルマガ下書き}
使っているAI：{例：Claude Opus 5 / ChatGPT}
連携ツール（MCP・API）：{例：スプレッドシート、在庫連携、メール配信}
出力フォーマット：
1. 渡しているデータ／権限の一覧（読み取り専用か書き込み可かを明記）
2. 各項目の被害範囲評価（取り返しがつくか／つかないか）
3. 「読み取り専用に落とせるもの」「人間承認を挟むべきもの」「そもそも渡すべきでないもの」の3分類
4. 認証情報がAIの作業フォルダやコンテキストに露出していないかの点検リスト
棚卸しで危険な項目が見つかったら、次は渡し方を安全側へ寄せる番です。読み取り専用で渡すべきデータが書き込み可能になっていないか、決済系に人間承認が入っているかを、業務フローごとに点検します。
（用途タイトル：権限の線引きレビュー）
プロンプト2：業務フローの権限の線引きレビュー
あなたはAIエージェント運用の設計者です。
以下の業務フローを、Anthropicの封じ込めの考え方（環境層で触れる範囲を制限し、
取り返しのつかない操作にだけ人間承認を挟む）に照らしてレビューしてください。
業務フロー：{例：AIが受注CSVを読み、遅延分に謝罪メールを下書きし、承認後に送信}
AIに渡しているデータ：{例：直近30日の受注CSV（read-only）}
AIが実行できる操作：{例：下書き作成、送信は人間承認後}
出力フォーマット：
1. read-onlyで足りるのに書き込み権限を渡している箇所の指摘
2. 人間承認を挟むべきなのに自動実行になっている箇所
3. 外部送信（egress）で「承認済みドメインだから」と広く開けすぎている箇所
4. 認証情報・顧客個人情報がAIから到達可能になっている箇所
5. 上記の修正案を、環境側の制限で実現する形で提案
プロンプト設計そのものの精度を上げたい場合はClaude 5のコンテキストエンジニアリングも合わせて確認すると、渡す情報の絞り込みが一段うまくなります。
EC現場でありがちな封じ込めの失敗と回避策
現場で崩れやすいのは、技術よりも運用のほうです。典型を3つ挙げます。1つ目は、便利さに負けて本番DBへAIを直結し、書き込み権限まで渡してしまうケースです。分析のつもりが、AIの誤操作一発で在庫数や価格を書き換える事故につながります。回避策は単純で、分析・下書き用途はread-onlyのコピーに限定し、書き込みは人間の手作業か、承認を挟んだ専用フローだけに残すことです。
2つ目は、認証情報の置き忘れです。ログイン情報やAPIキーを貼ったメモ、管理画面のスクリーンショットを、AIと共有しているフォルダにうっかり残す。前述のとおり、認証情報がAIの手の届く場所にある時点で持ち出しリスクは跳ね上がります。共有フォルダには顧客個人情報と認証情報を置かない、という一線を運用ルールに明文化しておくのが確実です。
3つ目は、承認の乱発による形骸化です。あらゆる操作に承認を求める設計にすると、担当者は93%を反射で通す状態に近づき、肝心の決済や一斉送信の承認まで軽くなります。回避策は、承認を取り返しのつかない操作だけに絞り、それ以外は環境側の制限で承認レスにすることです。承認を減らすことが、逆に承認の質を守ります。
封じ込め運用のKPIと費用の目安
導入効果は、承認回数の削減と事故時の被害限定という2軸で測るのが実際的です。まず数えやすいのは承認の回数です。Anthropicは環境側の壁を敷いたことで権限確認の表示が84%減ったと報告しており、EC現場でも読み取り専用の作業を承認レスへ寄せれば、担当者が確認に費やす時間は目に見えて減ります。工数削減の幅は業務構成で差が出るため、まずは1週間、AIから承認を求められた回数を数え、そのうち何割が読み取り専用の無害な操作だったかを出すところから始めるのが手堅い進め方です。ここで7割が無害な確認だったなら、その分を承認レスに移すだけで、承認の総量を大きく削れます。
費用面のハードルは高くありません。2026年7月時点で、Claude Pro（claude.aiの有料プラン）やChatGPT Plusは月額20米ドル前後で、各社の個人向け上位プランもおおむね同水準です（金額は改定があるため要確認）。封じ込めの考え方自体は、これらの標準プランの範囲で実装できます。渡すデータをread-onlyのコピーにする、認証情報を作業フォルダに置かない、重要操作に人間承認を挟む、という運用ルールに落とすだけだからです。高価な専用ツールを買う前に、線引きのルールを紙一枚にまとめるほうが、費用対効果は先に出ます。事故が起きたときの被害額は測りにくい指標ですが、顧客情報の漏えいが一度起きれば、月20米ドルの何桁も上の損失になり得ると考えれば、優先順位は明らかです。
封じ込めの発想はEC運用の標準になる
今後の展望として、封じ込めは一部の技術好きの作法ではなく、AIを業務に入れる全事業者の標準装備になっていくと見ています。Anthropic自身が次の課題として挙げているのは、セッションをまたいで残る記憶の汚染（persistent memory poisoning）、複数エージェント間での信頼の横滑り、そしてエージェントの身元（agent identity）の3点です。いずれもEC運用に直結します。たとえばAIに定型業務を任せるほど、指示メモや設定ファイルは長期間残り、そこに一度でも悪意ある指示が紛れ込めば、起動のたびに読み込まれてしまう。
日本のEC事業者にとって現実的な着地点は、AIを使うかどうかではなく、どこまで触らせるかを先に決めてから使うという順序の徹底です。2026年7月時点の最新モデルはClaude Opus 5（2026年7月23日公開）やClaude Sonnet 5（2026年6月30日公開）で、性能は上がり続けています。ただし、モデルが賢くなるほど想定外の抜け道を見つける能力も上がると、Anthropic自身が指摘しています。賢さに比例して行儀が良くなるとは限らない以上、EC側の守りは「賢いモデルを信じる」ではなく「触れる範囲を狭くしておく」に寄せるのが筋です。AIエージェントの制御不能リスクとガバナンスの論点はAIの制御不能リスクとECエージェント統治でも扱いました。
現場感覚として、線引きを先に決めた店舗ほど、その後のAI活用のスピードがむしろ上がります。触ってよい範囲がはっきりしていれば、担当者は安心して任せられ、承認レスで回る作業が増えるからです。封じ込めは、AIにブレーキをかける話に見えて、実はアクセルを踏むための前提整備でもあります。
よくある質問
Claudeの封じ込めアーキテクチャは、EC事業者が自分で導入する必要がありますか
いいえ、claude.aiやClaude Coworkを使う分には、隔離の仕組みはAnthropic側で組み込まれています。EC事業者がやるべきは、その上で「どのデータを読み取り専用で渡すか」「どの操作に人間承認を挟むか」という運用の線引きを自店で決めることです。仕組みは提供側、線引きは利用側という役割分担で考えると整理しやすいです。
受注データをAIに読ませるのは危険ではありませんか
読み取り専用のコピーを渡す限り、危険は大きく下げられます。危険なのは、本番DBへ直結して書き込み権限まで渡すことと、認証情報を一緒に露出させることです。必要な範囲だけをエクスポートしたCSVを使い、元データとログイン情報はAIの手の届かない場所に置けば、分析や下書き生成は安全に回せます。
決済や返金までAIに任せてよいですか
いいえ、決済・返金・出荷確定・在庫の確定反映・一斉メール送信は、人間承認を挟むべき操作です。理由は、これらが取り返しのつかない被害範囲を持つからです。AIには下書きと提案までをさせ、実行の最終判断は人間が押す、と決めておくのが安全です。
承認を毎回求めれば安全になりますか
いいえ、承認の乱発はむしろ危険です。Anthropicのデータでは利用者が権限確認の約93%を承認しており、回数が増えるほど注意が下がります。承認は取り返しのつかない操作だけに絞り、読み取り専用の作業は環境側の制限で承認レスにするほうが、肝心の場面での承認の質を保てます。
AWSの認証情報が24回持ち出されたという話は、Claudeが危険という意味ですか
いいえ、それはモデルの賢さだけでは防げない攻撃があることの実証です。利用者自身の指示に紛れ込ませる直接プロンプトインジェクションでは、AIの分類器に異常が見えません。だからこそ、外部送信を止めるegress制御と、認証情報に到達させないファイル境界という環境層の守りが必要になる、という教訓として読むのが正しいです。
楽天やAmazonの店舗運用でも、この考え方は使えますか
はい、そのまま応用できます。受注・顧客データは読み取り専用のコピーで渡し、RMSやSeller Centralの認証情報はAIの作業領域に置かず、価格改定や一斉メール送信には人間承認を挟む。楽天R-Mailの文面をAIに書かせる場合は、楽天市場外へのリンクを差し込ませない制約を最初にかけると、規約リスクも同時に防げます。
参考文献
- How we contain Claude across products（Anthropic Engineering, 2026-05-25）
- Claude Code auto mode（Anthropic Engineering）
- anthropic-experimental/sandbox-runtime（オープンソースのサンドボックス実装, GitHub）
- NIST: Software and AI Agent Identity and Authorization プロジェクト
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
