投稿者 投稿日: カテゴリー Claude
Focusビューとは、Claude CodeのVS Code拡張でツール実行の詳細を折りたたむ表示切替のことです。
楽天RMSやAmazon SP-APIの認証情報を置いたリポジトリで、AIにコードを触らせるのは怖い。この不安に対して、Claude Codeは2026年8月4日のバージョン2.1.221で具体的な回答を出しました。サンドボックス内のコマンドには偽の値を読ませ、外部への通信時にだけ本物の値を差し込む「マスク」モードです。あわせてVS Code側にFocusビューが追加され、ツール実行のログに埋もれずに作業内容を追えるようになりました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援を2023年から提供する株式会社オルセル（うるチカラ運営）が、EC開発の現場で何をどう設定すべきかを整理します。
2026年8月4日の更新で何が変わったか
結論から書くと、変わったのは2点です。VS CodeにFocusビューが追加されたことと、サンドボックスの認証情報の扱いに「マスク」という第3の選択肢が加わったことです。
Claude Codeの変更履歴によると、バージョン2.1.221は2026年8月4日付です。Focusビューは、チャットメニューから切り替えるトグルで、ツールの実行内容をターンごとの折りたたみサマリーの後ろに隠します。実行中のツールはライブのインジケーターで示されるため、何が動いているかは分かる状態を保ちます。ショートカットは Ctrl+Alt+F、コマンドパレットからは「Claude Code: Toggle Focus view」で呼び出せます。
認証情報のマスキングのほうが実務的な意味は大きいでしょう。同バージョンでは、LinuxとWSL（Windows上でLinux環境を動かす仕組み）向けに mode: "mask" が追加されました。サンドボックス内のコマンドは、認証情報ファイルの代わりにセンチネル（見張り役の代替値）が入ったコピーを読みます。ファイル全体を差し替えることも、extract 正規表現で捕まえた範囲だけを差し替えることもできます。そして外部への通信が発生する段階で、サンドボックスのプロキシが本物の値に置き換えます。
ここで日本のEC開発チームが必ず確認すべき点があります。macOSではファイルのマスキングが deny（拒否）にフォールバックする、と明記されている点です。つまりMacで開発している場合、この機能は「値を隠して読ませる」のではなく「そもそも読ませない」動作になります。国内のEC事業者の開発現場はMacが多いため、LinuxやWSLの環境を前提とした記事をそのまま真似すると挙動が食い違います。
前提として、サンドボックスの認証情報制御そのものは2026年6月23日のバージョン2.1.187で入っていました。このときは sandbox.credentials 設定として、サンドボックス内のコマンドが認証情報ファイルや秘密の環境変数を読むことをブロックする、という単純な遮断でした。2か月を経て、遮断だけでなく「動くけれど本物は渡さない」という中間の選択肢が用意された、という流れになります。
EC開発で認証情報マスキングが効く3つの場面
マスキングが効くのは、コードは動かしたいが本物の鍵は渡したくない場面です。EC開発では3つの典型があります。
1つ目は、モールのAPI連携コードの動作確認です。楽天RMSのAPIやAmazon SP-API、Shopify Admin APIを叩くスクリプトを書かせるとき、AIが実際にリクエストを組み立てて動作を確認できると開発は速く進みます。しかしそのために本番の認証情報を渡すのは避けたい。マスクモードなら、コード側は認証情報を読んで組み立てられる一方、その値はセンチネルであり、外部に出る瞬間だけ本物になります。ローカルのログやデバッグ出力に本物の鍵が残るリスクが下がります。
2つ目は、外部パートナーとの共同開発です。制作会社や業務委託のエンジニアと同じリポジトリで作業する場合、本番の認証情報を共有せずに動作確認まで進められる意味は大きいでしょう。従来は検証用の別アカウントを用意する運用が一般的でしたが、モールによっては検証環境が用意されていない、あるいは本番と挙動が違うという問題がありました。
3つ目は、CI（自動テスト）に近い使い方です。決済や配送APIのように、誤って本番に投げると実害が出る処理を含むコードを検証するとき、サンドボックス側で読める値を制御できると事故の確率が下がります。ただしこれは万能ではありません。マスクはあくまで「サンドボックス内での読み取り」に対する仕組みであり、外部通信そのものを止める機能ではない点に注意が必要です。本番エンドポイントに投げてよいかどうかは、別途の設計判断になります。
直近の支援案件で観測したのは、認証情報の管理をルール文書だけで運用しているチームほど事故が起きやすいという傾向でした。「本番の鍵はローカルに置かない」と書いてあっても、動作確認のために一時的に置いて消し忘れる、という経路で漏れます。ツール側で読める値を制御できるなら、ルールに頼る部分をその分減らせます。開発ルールの共通化についてはAGENTS.mdの書き方をまとめた記事も参考になります。
設定手順とレビュー用プロンプト4本
導入は「環境の確認、対象ファイルの棚卸し、設定、検証」の4段階です。ここでは各段階で使えるプロンプトを4本示します。Claude Codeで実行する前提ですが、ChatGPTやGeminiでも動きます。
最初に、自社の開発環境でマスクモードが使えるかを確認します。macOSなら挙動が変わるため、ここを飛ばすと後で混乱します。
プロンプト1：マスクモード適用可否の環境確認
あなたは開発環境の構成を確認するエンジニアです。
以下の情報をもとに、Claude Code のサンドボックス認証情報マスキングが
「mask として機能するか」「deny にフォールバックするか」を判定してください。
前提（2026年8月時点の仕様）：
- mode: "mask" は Linux と WSL で有効
- macOS ではファイルのマスキングは deny にフォールバックする
環境情報：
- 開発端末のOS：{macOS / Windows+WSL / Linux}
- Claude Code のバージョン：{バージョン}
- サンドボックスの利用有無：{有 / 無}
出力：判定結果、その環境で取りうる代替手段、次にやるべき設定作業を3項目
次に、そもそもどのファイルを保護対象にするかを洗い出します。ここが曖昧なままだと設定が漏れます。
プロンプト2：保護すべき認証情報ファイルの棚卸し
あなたはEC事業者のシステムセキュリティ担当です。
以下のリポジトリ構成から、認証情報が含まれる可能性のあるファイルを列挙してください。
観点：
1. 環境変数ファイル（.env 系）
2. クラウド事業者の資格情報ファイル
3. モールAPI（楽天・Amazon・Shopify・Yahoo!）のキーやトークンを含む設定ファイル
4. 決済・配送・会計システムの接続情報
5. 上記を参照しているスクリプトや設定の記述箇所
リポジトリ構成：
{ディレクトリツリーを貼る}
出力：ファイルパス、含まれる想定の情報、保護の優先度（高／中／低）を各1行
3本目は、マスク対象の範囲を決める作業です。ファイル全体か、正規表現で切り出した一部かを判断します。
プロンプト3：マスク範囲（全体 / extract）の判定
あなたは設定ファイルの構造を読むエンジニアです。
以下のファイル内容について、Claude Code のサンドボックス設定で
「ファイル全体をマスクすべきか」「extract 正規表現で一部だけマスクすべきか」を判定してください。
判定基準：
- ファイル全体が秘密情報のみなら全体マスク
- 秘密情報と通常の設定値が混在し、通常値はコマンドが読む必要があるなら extract
- extract の場合、対象となる値の位置を特定できる正規表現案も提示すること
ファイル内容（値は伏せ字でよい）：
{内容を貼る}
出力：推奨方式、その理由を2文、extract の場合は正規表現案とマッチ対象の説明
最後に、設定後の検証です。設定したつもりで効いていない、という状態を潰します。
プロンプト4：マスキング設定の検証手順の作成
あなたは検証手順を設計する品質担当です。
以下の設定内容について、意図通りマスキングが効いているかを確認する手順を作成してください。
設定内容：
{設定ファイルの該当箇所を貼る}
対象ファイル：{パス}
想定する動作：{サンドボックス内では伏せ字、外部通信時のみ実値}
出力：
1. サンドボックス内でファイルを読んだときに何が見えるべきかの期待値
2. 実際に確認するコマンド例（値そのものをログに残さない書き方で）
3. 期待と違った場合に疑うべき設定項目を3つ
4. この検証で確認できないリスクの明示
この4本は順番に回すことを想定しています。特にプロンプト2の出力は、そのまま社内のセキュリティチェックリストに転記できる形にしてあります。
遮断・マスク・許可の3段階をどう使い分けるか
設定の考え方を整理しておきます。サンドボックス内の認証情報の扱いは、遮断・マスク・許可の3段階として捉えると判断しやすくなります。
遮断は、サンドボックス内のコマンドに認証情報ファイルも秘密の環境変数も一切読ませない設定です。2026年6月の sandbox.credentials 設定がこれにあたります。安全ですが、認証情報を読む前提のコードは動きません。API連携の実装を進めたい局面では使いにくいのが実情です。
マスクは、読み取り自体は通し、返す値を差し替える設定です。コードは動くが本物の値はローカルに現れない、という中間状態を作ります。今回追加された選択肢がこれです。開発と検証の大半はここで足ります。
許可は、そのまま読ませる設定です。本番相当の通信を実際に確認する必要がある局面に限定し、作業が終わったら遮断かマスクに戻す運用が前提になります。許可のまま常用するのは避けてください。
この3段階を、リポジトリ単位ではなくファイル単位で当てはめるのが実務的です。例えば決済代行の本番キーは遮断、モールAPIの検証用キーはマスク、公開情報だけを含む設定ファイルは許可、という配分になります。ファイル単位で分けるには、まずどのファイルに何が入っているかを把握している必要があり、そこがプロンプト2の棚卸しに戻ってくる、という構造です。
現場で繰り返し見るのは、全ファイルを一律で遮断にしてしまい、開発が止まって結局サンドボックスごと無効化するパターンです。安全側に倒したつもりが、最終的に一番危険な状態に落ち着きます。段階を分けることが、運用を続けるための条件になります。
Focusビューが効くのはどんな作業か
Focusビューは、長時間の自動処理を回すときに効きます。Claude Codeは1ターンの中で複数のツールを呼ぶため、ファイル読み込みや検索の出力でチャット画面が埋まります。商品データの一括変換のように数十ファイルを触る作業では、何が起きたのかを後から追うのが難しくなります。
Focusビューをオンにすると、ツールの実行内容がターンごとのサマリーに折りたたまれ、必要なときだけ展開する形になります。実行中のツールはライブのインジケーターで示されるため、止まっているのか動いているのかは分かります。切り替えは Ctrl+Alt+F で、作業中に何度でも切り替えられます。
使い分けの目安としては、コードの中身を1行ずつ確認したい初期の実装フェーズはオフ、方針が固まって一括処理を回すフェーズはオンが扱いやすい構成です。編集部で実際に運用している範囲では、レビュー時に画面を共有する場面でFocusビューをオンにすると、説明が通りやすくなりました。並列で複数の処理を走らせる場合の全体設計はClaude Codeのマルチエージェント並列処理の記事にまとめています。
よくある失敗と回避策
3つ挙げます。
1つ目は、macOSでマスクを設定して効いていると思い込むケースです。仕様上、macOSではファイルのマスキングは拒否にフォールバックします。設定を書いたのにサンドボックス内のコマンドが「ファイルが読めない」と失敗する場合、これが原因の可能性があります。回避策は、プロンプト1で環境を先に確認し、macOSならWSLやLinuxのコンテナ上で開発する構成に寄せるか、そもそも認証情報を必要としない検証手順に切り替えることです。
2つ目は、マスクを設定したので本番の鍵をリポジトリに置いてよい、と誤解するケースです。マスキングはサンドボックス内の読み取りに対する仕組みであり、リポジトリへの平文コミットを防ぐものではありません。gitignoreの設定、コミット前のスキャン、権限管理は従来通り必要です。ここを混同すると、かえって危険な運用になります。
3つ目は、extract 正規表現の書き方が甘く、マスクすべき値が漏れるケースです。1行に複数のキーが並ぶ設定ファイルや、改行を含む秘密鍵では、想定した範囲だけを捕まえられないことがあります。回避策は、設定後にプロンプト4の検証手順を必ず通し、サンドボックス内で実際に何が見えるかを目視することです。設定した本人が確認するのではなく、別の担当が確認する体制にできると、なお確実になります。
4つ目として、検証コマンドの書き方で自ら漏らすパターンにも触れておきます。マスクが効いているかを確認するために、認証情報をそのまま標準出力に出すコマンドを打つと、その出力がチャットの履歴やターミナルのログに残ります。マスクが効いていれば伏せ字が残るだけですが、効いていなかった場合は本物が記録されます。確認は「先頭数文字だけを表示する」「文字数だけを数える」といった、値そのものを露出しない方法で行ってください。
5つ目は、Focusビューをオンにしたまま危険な操作を見落とすケースです。ツール活動が折りたたまれるため、ファイルの削除や上書きが混ざっていても目に入りにくくなります。破壊的な操作を含む作業のときは、Focusビューをオフに戻すか、権限の確認プロンプトを有効にしたまま進めるのが安全です。表示の見やすさと監視のしやすさは、ある程度トレードオフになります。
費用と工数、そして測るべき指標
設定作業自体の工数は軽く、対象ファイルが5個程度であれば1〜2時間で終わります。時間がかかるのはプロンプト2の棚卸しで、リポジトリの規模によっては半日から1日を見ておくと安全です。既存の環境変数が整理されていないチームほど、この工程で時間を使います。
Claude Codeの利用料は契約プランに依存します。個人利用のClaude Proが月20米ドル前後、より多い利用を前提としたプランは上位の価格帯です。組織で使う場合はチーム向けプランの単価に人数を掛けた額になります。いずれも2026年8月時点の水準で、改定される可能性があるため公式の料金ページで確認してください。
測る指標は2つで足ります。第一に、開発環境から本番認証情報を参照できる経路の数。棚卸しの前後で数えて、減っていることを確認します。第二に、認証情報に起因するインシデントの件数。これはゼロが前提で、発生した場合は原因を設定に戻して潰します。開発速度の指標を無理に紐づける必要はありません。速度は別の要因で動くためです。
この先の見立て
サンドボックスの権限制御は、今後さらに細かくなる方向だと見ています。理由は単純で、AIエージェントに実行させる範囲が広がるほど、「全部禁止」か「全部許可」の2択では運用が回らなくなるからです。今回のマスクモードは、その中間を作る動きの一例と位置づけられます。
EC事業者にとって現実的な準備は2つです。1つは、認証情報の棚卸しを今のうちに済ませておくこと。どのツールが何を読むかが分かっていないと、細かい制御が入っても設定できません。もう1つは、開発端末のOSを揃えることです。macOSとLinuxで挙動が変わる機能は今後も出てくるため、チーム内で環境が混在していると、設定の検証が毎回2倍になります。
なお、macOSでのファイルマスキング対応が今後入るかどうかは、2026年8月時点では公表されていません。ここは要確認として、変更履歴を定期的に確認する運用にしておくのが安全です。
よくある質問
Claude CodeのFocusビューとは何ですか
Focusビューとは、Claude CodeのVS Code拡張でツール実行の詳細を折りたたむ表示切替のことです。ターンごとの折りたたみサマリーの後ろにツール活動を隠し、実行中のツールはライブのインジケーターで示します。Ctrl+Alt+F、またはコマンドパレットの「Claude Code: Toggle Focus view」で切り替えます。
認証情報のマスクモードはどのOSで使えますか
LinuxとWSLで使えます。macOSではファイルのマスキングが拒否にフォールバックする仕様のため、値を隠して読ませる動作にはなりません。Macで開発しているチームは、この違いを前提に構成を決めてください。
マスクモードがあれば本番の鍵をリポジトリに置いてもよいですか
いいえ、置いてはいけません。マスキングはサンドボックス内での読み取りを制御する仕組みであり、リポジトリへの平文コミットや権限管理の代替にはなりません。gitignoreとコミット前スキャンは従来通り必要です。
ファイル全体をマスクするのと一部だけマスクするのはどちらがよいですか
秘密情報だけが入ったファイルは全体、通常の設定値と混在しているファイルは extract 正規表現で一部だけ、という使い分けが基本です。混在ファイルを全体マスクすると、コマンドが読むべき通常値まで伏せ字になり動作しなくなります。
楽天やAmazonのAPI連携開発で使えますか
使えます。APIキーやトークンを含む設定ファイルを対象にすることで、コードは動かしつつローカルには本物の値を残さない構成が組めます。ただし外部通信そのものを止める機能ではないため、本番エンドポイントに投げてよいかは別途判断してください。
設定にどれくらい時間がかかりますか
対象ファイルが5個程度であれば設定作業は1〜2時間が目安です。時間がかかるのは事前の棚卸しで、リポジトリの規模によって半日から1日を見込んでください。既存の環境変数が整理されていないほど長くなります。
設定が効いているかはどう確認しますか
サンドボックス内でファイルを読んだときに伏せ字が返るかを確認します。確認コマンドは値そのものをログに残さない書き方にしてください。本記事のプロンプト4で、検証手順と確認できないリスクの明示までまとめて出せます。
まとめ
Claude Codeの2026年8月4日の更新は、EC開発の現場に「動かしつつ鍵は渡さない」という選択肢を追加しました。ただしmacOSでは挙動が変わるため、環境の確認を最初に済ませることが前提になります。まずはプロンプト2で認証情報ファイルの棚卸しを行い、自社のリポジトリに本番の鍵がどれだけ紛れ込んでいるかを可視化するところから始めてください。設定はその後で構いません。
著者：齋藤竹紘（株式会社オルセル 編集長／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実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
