2 つとも「見せる量を絞る」話
Claude Code v2.1.221 に、性質の近い変更が 2 つ入りました。表示するログの量を絞る Focus view と、サンドボックス内に見せる資格情報を絞るマスキングです。
見た目には無関係ですが、揃えて見ると理解しやすくなります。どちらも「必要な分だけを渡す」という同じ考え方の適用です。
順に見ていきます。
Focus view でログを畳む
VS Code 版に追加された表示の切り替えです。公式にはこう書かれています。
[VSCode] Added Focus view: a chat-menu toggle that hides tool activity behind an expandable per-turn summary with a live running-tool indicator, toggled with
Ctrl+Alt+For the "Claude Code: Toggle Focus view" command
ツールの実行ログを折りたたみ、ターンごとの要約と実行中の表示だけを残します。 切り替えは Ctrl+Alt+F、またはコマンドパレットから行います。
畳まれた部分は展開できるので、見たいときには中身を確認できます。消えるわけではありません。
なぜ効くのか
揃っているか・崩れないかという観点で言うと、流れ続けるログは、読む対象として成立していません。
量が多いと、人は読むのをやめます。最初のうちは追いかけていても、数十行が数秒で流れる状態が続けば、目で追うこと自体をやめます。そして結果だけを見るようになります。
Focus view が変えるのは、この構造です。常に全部が見えている状態から、要約が見えていて必要なら開く状態へ変わります。
| 状態 | 起きること |
|---|---|
| 全部が流れている | 読むのをやめて、結果だけ受け取る |
| 要約だけが見える | 要約は読む。気になれば展開する |
読む量が減るのに、確認の質は上がります。見る場所が絞られると、そこは読まれるからです。
コツ
導入したてのチームで「何をしているか分からない」という声が出るなら、まずこの表示を試してみてください。情報が多すぎることが原因の場合があります。
畳まないほうがよい場面
一方で、常に畳んでおけばよいわけでもありません。実行されたコマンドそのものを見る必要がある場面があります。
- 外部から取得した内容をもとに作業させているとき
- 権限を広めに開けた状態で動かしているとき
- 初めて任せる種類の作業を試しているとき
いずれも、要約では分からない部分が問題になりうる場面 です。要約は「何をしたか」を伝えますが、「どう実行したか」までは含みません。
作業の性質で切り替えるのが妥当です。慣れた作業は畳み、危うい作業は開く。切り替えが 1 つのキーで済むのは、この使い分けを前提にした設計だと考えられます。
要約に何が出るかを一度見ておく
畳んだあとに残るのは、ターンごとの要約と実行中の表示です。この要約に何が出るかを、最初に一度だけ確認しておいてください。
理由は、要約の粒度と自分が見たい粒度が合うとは限らないためです。合っていれば、そのまま畳んだ運用に移れます。合っていなければ、畳むのは慣れた作業だけにする、という使い分けになります。
確認は簡単です。同じ作業を、畳んだ状態と開いた状態で 1 回ずつ流してみる。 それだけで、要約でどこまで分かるかが体感できます。
注意
畳んだ状態でしばらく使ってから開くと、「こんなことをしていたのか」と気づくことがあります。それは要約が悪いのではなく、そもそも許可の範囲が広すぎるという合図です。
資格情報をサンドボックス内で隠す
もう 1 つが、Linux と WSL 向けの機能です。公式の記述を引きます。
Added
mode: "mask"for sandbox credential files on Linux and WSL — sandboxed commands read a sentinel copy (the whole file, or just the spans captured by anextractregex) while the sandbox proxy substitutes the real value on egress; on macOS file masking falls back todeny
整理すると、次の流れになります。
- サンドボックス内のコマンドが資格情報ファイルを読む
- ただし読めるのは 身代わりの値 で、本物ではない
- 外部へ通信する段階で、サンドボックスのプロキシが本物に差し替える
サンドボックス内では本物の値が存在しない状態で、通信は成立します。 ファイル全体を身代わりにするか、抽出用の正規表現で捉えた範囲だけを置き換えるかを選べます。
何を防ぐのか
現実的な効き方は、読み取られたものが外へ持ち出される経路を細くする ことです。
サンドボックス内で動くコマンドが設定ファイルを読むこと自体は、正常な動作です。問題は、その中身がそのまま扱われてしまう場面があることです。ログに出る、要約に含まれる、意図しない宛先へ渡る。いずれも実際に起こりえます。
読める値が身代わりであれば、中身が漏れても実害が出ません。 通信の段階でだけ本物になるので、機能は損なわれません。
注意
すべての漏洩を防ぐ仕組みではありません。防げるのは、サンドボックス経由の読み取りだけです。手元の環境で直接ファイルを開く経路には効きません。
環境で挙動が違う
ここが実務では重要です。macOS ではファイルのマスキングは deny に落ちます。
つまり、同じ設定を配っても環境によって動きが変わります。Linux と WSL では身代わりが読まれ、macOS では読めなくなります。
| 環境 | 挙動 |
|---|---|
| Linux | 身代わりの値が読まれる |
| WSL | 身代わりの値が読まれる |
| macOS | 読み取り自体が拒否される |
チーム内で環境が混在しているなら、手順書に環境ごとの記述を入れてください。 「設定したのに動かない」という問い合わせは、たいていここです。
揃えておくと後が楽なのは、この種の環境差です。設定を配る側が把握していないと、受け取った側が個別に調べることになります。
FIXIT
IrodoriFIXITIrodori見る場所を絞ると、そこは読まれます。揃えておくと後が楽です。
どのファイルを対象にするか
マスキングを入れるとき、対象の選び方で手間が変わります。外部へ出ると困るものから順に入れてください。
優先順位としては、次のようになります。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高い | 外部サービスへの接続に使う資格情報 | 漏れると直接的な被害が出る |
| 中程度 | 社内システムへの接続情報 | 範囲が社内に留まる |
| 低い | 開発用・検証用の値 | 漏れても実害が小さい |
一番上から入れて、動くことを確認してから次に進みます。全部を一度に対象にすると、動かなくなったときに原因が絞れません。
なお、抽出用の正規表現で範囲を指定できるので、ファイル全体をマスクする必要はありません。設定ファイルの中で、実際に秘密なのは 1 行だけ、ということは多くあります。必要な部分だけを対象にするほうが、検証も軽く済みます。
この版に含まれる、もう 1 つの変更
本記事では表示と資格情報の 2 つを扱いましたが、v2.1.221 には権限チェックの不具合の修正も含まれています。zsh の条件式内に隠したコマンドが権限チェックを通過する問題などです。
この点は続く v2.1.222 と v2.1.223 でも修正が続きました。権限まわりを重視するなら、この版で止めずに最新まで上げてください。 経緯は Claude Code の権限バイパス修正が続いた 3 リリース に整理しています。
そもそもサンドボックスを使っているか
前提の確認になりますが、マスキングはサンドボックスを使っている場合の機能です。 サンドボックス自体を有効にしていない環境では、この設定を入れても何も起きません。
「資格情報が心配なので入れたい」という話が出たときは、順番を確認してください。
- サンドボックスを使っているか
- 使っているなら、資格情報ファイルをどう扱っているか
- そのうえで、マスキングが要るか
1 番が「いいえ」なら、まずそこからです。マスキングは、サンドボックスという枠組みの中の細かい調整であって、単体で成立する対策ではありません。
逆に、既にサンドボックスを使っていて資格情報の扱いに悩んでいたなら、今回の追加はそこに直接効きます。読ませないか、読ませて漏れるかの二択だった部分に、読ませるが実値ではない という選択肢が増えた形です。
どちらから触るか
2 つのうち、先に触る価値があるのは Focus view です。
理由は 2 つあります。1 つは、キー 1 つで戻せること。合わなければ元に戻せばよいので、試す負担がありません。もう 1 つは、効果がその場で分かることです。表示が変わるので、良し悪しをすぐ判断できます。
マスキングのほうは、設定と検証が要ります。 資格情報の扱いを変える以上、動かなくなる可能性を踏まえた確認が必要です。急ぐ理由がないなら、時間が取れるときに落ち着いて入れてください。
順番としては、次のようになります。
- Focus view を試す。合わなければ戻す
- 環境が Linux か WSL かを確認する
- マスキングの対象にしたいファイルを決める
- 検証してから、通常の作業に適用する
3 番で対象を絞るのが要点です。すべての資格情報を一度にマスクしようとすると、検証の範囲が広がりすぎます。 外部へ出て困るものから順に入れるほうが、確実に進みます。
環境差をチームでどう吸収するか
マスキングに限らず、環境で挙動が変わる設定は、配り方に一手間が要ります。 ここを詰めておくと、後の問い合わせがまとめて減ります。
やることは 3 つです。
- 手順書に環境の見出しを立てる。Linux / WSL / macOS で節を分ける
- 効かない環境では、代わりに何をするかを書く。「対象外です」で終わらせない
- 設定を配った人が、各環境で 1 回ずつ確認する
2 番が抜けやすい部分です。macOS の人が手順書を読んで「自分の環境では使えない」とだけ分かっても、そこで止まります。代わりの手当てまで書いてあれば、そのまま進めます。
3 番は面倒に見えますが、結局これがいちばん早いです。配ってから個別に問い合わせを受けるより、先に 3 回試すほうが総量として軽く済みます。
なお、環境をそもそも揃えるという選択肢もあります。ただし、揃えるコストは環境差を吸収するコストより大きくなりがちです。混在を前提にした書き方をするほうが、現実的なことが多いです。
表示を絞ることと、権限を絞ること
最後に、この 2 つの変更が示している方向について書いておきます。
エージェントに任せる範囲が広がるほど、人が見るべき情報と、渡すべき情報の量を絞る設計が要ります。 全部を見せる、全部を渡す、という作りは、規模が小さいうちしか成立しません。
Focus view は、人が見る量を絞る仕組みです。マスキングは、機械に渡す量を絞る仕組みです。方向は同じで、必要な分だけを、必要なところに。
設定を作る側から見ると、この観点は既に権限設計で扱ってきたものです。考え方そのものは Claude Code の権限と settings.json 設計 に整理しています。表示の設計も、同じ延長線上にあると考えると据わりがよくなります。
組織として配る段階まで進んでいるなら、Claude Code 全社導入 完全ガイド も合わせて参照してください。環境差の吸収と設定の配り方は、機能が増えるたびに同じ形で発生します。 1 回作った型は、次の機能でもそのまま使えます。
まとめ
- Focus view は VS Code 版の表示切り替え。ツールのログを畳み、ターンごとの要約を残す
- 切り替えは
Ctrl+Alt+F、またはコマンドパレットから。畳んだ部分は展開できる - 読む量が減るぶん、要約は読まれるようになる。全部流れる状態より確認の質が上がる
- 外部の内容を扱う作業や、初めて任せる作業では畳まないほうがよい
- 資格情報のマスキングは、サンドボックス内に身代わりを読ませ、通信時に実値へ差し替える
- macOS では
denyに落ちる。環境が混在するチームは手順書に環境差を書いておく - マスキングはサンドボックスを使っている前提の機能。単体で成立する対策ではない