AIエージェントのトークン消費を減らすコツ

AIエージェントを使っていると、思ったより早く使用量の上限に近づいていく、ということが起きます。この記事は、その減り方を緩やかにするための実践的な話です。

コマンド名はClaude Codeのものを使いますが、考え方はどのエージェントでも共通です。

まず、これだけ分かれば半分終わります

多くの人が最初に誤解するのが、ここです。

「1回質問したら、1回分のトークンが減る」——そうではありません。

Anthropic公式のClaude Codeドキュメントに、はっきり書かれています。

“Claude Code sends your full conversation with every request… so a one-line question in a session that has been open all day still draws usage for the whole conversation.”

（Claude Codeはリクエストのたびに会話の全体を送っています。……そのため、朝から開きっぱなしのセッションで一行の質問をしただけでも、会話全体ぶんの使用量が発生します）

つまり、会話が長くなるほど、その後の一言一言が高くつくということです。「さっきの続きで、ちょっとだけ聞きたい」の「ちょっと」が、実は全然ちょっとではない。

AttentionとTransformerで「前のやり取りは毎回すべて読み直されている」と書いたのは、この話です。しかも読み直すたびに全語×全語の総当たりが走ります。

ここから先の対策は、全部「読み直させる量を減らす」の一点に集約されます。

1. 話題が変わったら /clear

いちばん効いて、いちばん簡単です。

/clear

これで会話の履歴が空になり、まっさらな状態から始まります。Anthropic公式ドキュメントの言い方はこうです。

“Use /clear to start fresh when switching to unrelated work. Stale context wastes tokens on every subsequent message.”

（関係のない作業に切り替えるときは/clearで仕切り直すこと。古くなった文脈は、以後のすべてのメッセージでトークンを無駄にします）

「以後のすべてのメッセージで」というのが重くなります。朝に片付けた別件の会話が、夕方の質問の料金にまで乗り続けている、ということです。

消えてしまうのが不安な場合は、/clearの前に/renameで名前を付けておけば、/resumeで戻れます。

同じ話題が続いているときは、どのくらいの間隔で打つのか

「話題が変わったら」は分かるとして、変わらないまま長くなったらどうするか。 ここも測りました。管理人の手元のMac mini 1台の作業記録（2026年9月、37,582回のやり取り）から、1回のやり取りのコストを、そのとき抱えていた会話の量ごとに並べたものです。

同じ質問でも、抱えている会話の量だけで6倍まで変わります。

では早く打てば打つほどよいかというと、そうではありません。 /clearすると会話は空になりますが、指示書や設定の読み込みはやり直しになります。 ——といっても、この負担は小さいことが分かりました。

同じ記録で、セッションの1回目に何が起きているかを見ると、92セッション中72本（78%）で読み込みの使い回しが働いていました。 指示書の中身は前のセッションと同じ文章なので、/clearをまたいでも処理済みのものが使えます。 処理し直したのは2万トークンほどで、やり直しの負担は「毎回1〜2回ぶんの質問」程度でした。

両方を合わせて、1回あたりがいちばん安くなる長さを計算すると、往復30〜50回、会話の量でいうと15万トークン前後です。

ただし、いちばん安い点の前後は、ほとんど差がありませんでした。 17回から84回までのどこで打っても（会話の量でいうと12万〜24万）、いちばん安いときとの差は1割に収まります。 「30回ちょうどで打つ」ような厳密さは要りません。

⚠️ この計算に含めていないものがあります。 /clearしたせいでエージェントが同じ作業をやり直した場合の損です。トークンの数だけを見た計算なので、そこは測れていません。 どこで打ってもさほど変わらないので、判断がつかないときは長いほう（往復50回くらい）に寄せるほうが安全です。

/contextで見える数字が15万を超えたあたりから、「そろそろ切り時か」と考え始めれば十分です。

2. 続きをやりたいときは /compact

「話題は変わっていないけれど、会話が長くなってきた」という場合はこちら。会話を要約して圧縮し、続きはそのまま続けられます。

そのとき、何を残してほしいかを指定できます。

/compact 認証まわりの修正内容を中心に残して

Anthropic公式ドキュメントにも例が載っています。

“/compact Focus on code samples and API usage tells Claude what to preserve during summarization.”

（/compact Focus on code samples and API usageと書けば、要約の際に何を残すべきかを指示できます）

毎回書くのが面倒なら、プロジェクトのCLAUDE.mdに方針として書いておくこともできます。

⚠️ /compact はタダではありません

ここは見落とされがちなので、はっきり書いておきます。

“/compact reads the conversation it summarizes, so compacting a large context is itself a large request. When you want a fresh start instead of continuity, /clear costs nothing.”

（/compactは要約する対象の会話を読み込むので、大きな文脈の圧縮は、それ自体が大きなリクエストになります。継続ではなく仕切り直しがしたいのであれば、/clearは何も消費しません）

「とりあえずcompactしておこう」は、逆に高くつくことがあります。 続きをやる必要が本当にあるのか、で選んでください。話題が変わっているなら/clearのほうが安い。

なお、放っておいても限界が近づけば自動で圧縮が走ります。ただし自動の場合は「何が大事か」を機械が推測するので、残ってほしいものが残るとは限りません。区切りのいいところで自分から/compactする意味は、そこにあります。

3. 今どれだけ使っているかを、見る

減らす前に、見えるようにするのが先です。

/contextは特に見返りが大きいです。「MCPサーバーの定義だけで結構な量を食っていた」といった、思ってもみなかった発見があります。

/usageのほうには、使用量の1割以上を占めている要因を指摘してくれる機能もあります。「長い文脈」や「キャッシュの外れ」が挙がってきたら、この記事の対策で減らせる状態だということです。

この2つは、ちょくちょく見て構いません

見るための操作は、ほとんど元手がかかりません。 ここは安心して習慣にしてください。

/usageは状態を問い合わせる通信が発生することがありますが、Anthropic公式のコスト解説は、この手の裏方の処理をまとめてこう見積もっています。

“These background processes consume a small amount of tokens (typically under $0.04 per session) even without active interaction.”

（こうした裏方の処理は、何もしていなくても少量のトークンを使います——通常はセッションあたり$0.04未満です）

桁が違います。 長い会話を1往復するほうがよほど高くつくので、「見るのを我慢して節約する」という発想は要りません。 むしろ逆で、見ないまま進めるほうが高くつきます。

4. ちょくちょく確認を挟む

その前に：「確認」には3種類あって、値段が違います

節約の話で「こまめに確認を」と言われるとき、指しているものが3つあります。そして、かかるコストがまるで違います。 ここを混ぜたまま読むと、この記事の後半と矛盾しているように見えるので、先に分けておきます。

「見る」と「止める」はちょくちょくやる。「直して」はまとめる。

同じ「確認」でも、①と②は減らすと高くつくもの、③は小分けにすると高くつくものです。小さく確認することと、小さく直しを頼むことは、別の話——ここさえ押さえれば、あとは迷いません。

①はひとつ上の節で見たとおりです。③は6の中にあります。この節は②の話です。

方向がずれたら、待つほど高くつく

エージェントが間違った方向に走り出したとき、損は二重に発生します。

1. 間違った作業に使ったトークンが、そのまま無駄になる
2. その無駄が会話に残り続け、以後ずっと読み直される

2番目が重くなるのが、この記事の最初に書いた話です。やり直しは、やり直しの分だけでは済みません。

だから、長く走らせてから確認するより、こまめに確認したほうが安い、ということになります。

止め方を覚えておく

• Escapeキーで、その場で止められます。「あ、違うな」と思った瞬間に押す
• /rewind、またはEscapeの2回押しで、会話とコードを前の状態に巻き戻せます

Anthropic公式ドキュメントもこう書いています。

“Course-correct early: If Claude starts heading the wrong direction, press Escape to stop immediately.”

（早めに軌道修正すること：Claudeが違う方向に進み始めたら、Escapeを押してすぐ止める）

「せっかく動いているから最後まで見よう」と待つ気持ちは分かりますが、方向が違うと分かっているなら、待つほど高くなります。

小さく頼んで、都度確かめる

“Test incrementally: Write one file, test it, then continue. This catches issues early when they’re cheap to fix.”

（少しずつ試すこと：1つファイルを書いて、試して、それから次へ進む。問題が安く直せるうちに見つかります）

「アプリを作って」と一息に頼むより、「まずこの画面だけ作って」と刻むほうが、結果的に安く済みます。間違いが小さいうちに見つかるからです。

5. 確認を「仕組み」にする

毎回自分で見張るのは疲れます。仕掛けのほうに寄せてしまうのが本筋です。

計画モード（先に作戦を見せてもらう）

Shift + Tabを押すと計画モードに切り替わります。この状態では、エージェントは調べて計画を立てるだけで、ファイルには一切手を出しません。 Anthropic公式ドキュメントにこうあります。

“Plan mode tells Claude to research and propose changes without making them. Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source.”

（計画モードは、変更を加えずに調査と提案だけを行うようClaudeに指示するものです。ファイルを読み、調べるためのコマンドは実行しますが、あなたのソースを編集することはありません）

そして、なぜこれがトークン節約になるのか。Anthropic公式ドキュメントが節約の項目として挙げている理由がこれです。

“preventing expensive re-work when the initial direction is wrong”

（最初の方向が間違っていたときの、高くつくやり直しを防ぐ）

計画の段階なら、違っていても「その方向じゃない」と言うだけで済みます。 実装まで走ったあとで言うと、書いたコードも、それを削除する作業も、全部が無駄になります。

検証の的を、先に渡す

“Give verification targets: Include test cases, paste screenshots, or define expected output in your prompt. When Claude can verify its own work, it catches issues before you need to request fixes.”

（検証の的を与えること：テストケースを含める、スクリーンショットを貼る、期待する出力を書く。エージェントが自分の仕事を検証できれば、あなたが修正を頼む前に自分で気づきます）

これは実感としても大きいところです。「いい感じにして」と頼むと、何が「いい感じ」か分からないので、当たるまで往復が発生します。「こうなったら成功」を先に渡せば、往復が減ります。

フックで、渡す前に絞る

もう一段進んだやり方です。エージェントに見せる前に、機械的に情報を絞ってしまうという発想です。

“Instead of Claude reading a 10,000-line log file to find errors, a hook can grep for ERROR and return only matching lines, reducing context from tens of thousands of tokens to hundreds.”

（エラーを探すために1万行のログを読ませる代わりに、フックでERRORをgrepして該当行だけを返せば、数万トークンが数百トークンで済みます）

数万が数百です。ここまで来ると設定の話になるので最初は不要ですが、同じ長い出力を毎回読ませている自覚があるなら、検討する価値があります。

6. 頼み方を具体的にする

“Vague requests like ‘improve this codebase’ trigger broad scanning. Specific requests like ‘add input validation to the login function in auth.ts’ let Claude work efficiently with minimal file reads.”

（「このコードベースを改善して」のような曖昧な依頼は、広範囲の読み漁りを引き起こします。「auth.tsのlogin関数に入力検証を追加して」のような具体的な依頼なら、最小限のファイル読み込みで済みます）

どこを触ればいいか分からないと、エージェントは探しにいきます。 その探索が全部トークンです。ファイル名が分かっているなら、書いてしまったほうが早くて安い。

直しは、まとめて1回で

返ってきたものに直したいところが3つあるとき、3回に分けて言えば、3回とも会話全体を読み直させることになります。

（もったいない例）
「タイトルを変えて」
→「2段落目を削除して」
→「最後にまとめを足して」

（1回で済む例）
「3点直してください。
 1. タイトルを〇〇に変更
 2. 2段落目を削除
 3. 最後にまとめを追加」

頼む内容は同じで、読み直しだけが3分の1になります。

これはAnthropic公式ヘルプも使用量を抑える工夫の項目として挙げています。

“If you have multiple related tasks or questions, group them in a single message.”

（関連する作業や質問が複数あるなら、1つのメッセージにまとめること）

コツは、直したいところを見つけても、すぐ言わないことです。最後まで目を通してから、まとめて渡す。同じページには送る前に読み返すことも挙がっています——「Take a moment to review your message for clarity and completeness to reduce the need for follow-up messages（追いかけのメッセージが必要にならないよう、送る前に一呼吸おいて見直す）」。

上の「小さく頼んで、都度確かめる」と逆のことを言っているように見えるかもしれませんが、4で分けた3種類の②と③の違いです。

• 作らせる前は、刻む（②）。一気に全部やらせると、方向が違ったときの損が大きい
• 返ってきた後は、まとめる（③）。直しの指示を小分けにしても、確認できるものは増えず、読み直しだけが増える

方向を確かめる往復は減らさない。直しを伝える往復は減らす。 そういう分け方です。

軽い直しは、自分でやったほうが安い

見落とされやすいのがこれです。誤字ひとつ、言い回しひとつのために、長い文章やコードを丸ごと作り直させるのは割に合いません。

頼んだ場合、会話には頼んだときの文＋作り直された全文が積み上がります。そしてそれが、以後ずっと読み直される分になります。直った1文字のために、全文をもう一部抱えることになるわけです。

エディタで直せる程度のものは、自分で直す。 エージェントに頼むのは、自分でやると面倒なものや、判断がいるものに絞る。

ステップ6では、誤字直しのような用事に最上位モデルを使うのはもったいない、と書きました。そこにはもう一段、「そもそも頼まない」という選択肢もあります。

7. モデルと「考える量」を選ぶ

モデルの使い分けはトークン節約のためのモデル選びにまとめてあるので、ここでは触れていない点だけ。

答える前に「じっくり考える」量を調整できます。 Claude Codeでは/effortで変えられます。

考える時間は精度を上げますが、考えている間のトークンも消費します。 難しい設計判断なら価値がありますが、「このファイル名を変えて」のような作業でじっくり考えられても仕方がありません。

8. そもそも読ませる量を減らす

• CLAUDE.mdを短くする。 このファイルは毎回のセッション開始時に丸ごと読み込まれます。公式は「200行未満を目標に」としています。長い手順書を書き込んでいると、無関係な作業のときも毎回その分を払うことになります
• 重い調べ物はサブエージェントに投げる。 別の文脈で作業してくれるので、大量のファイルの中身はサブエージェント側に残り、返ってくるのは要約だけです
• 使っていないMCPサーバーを切る。 /contextで量を確認できます

最後のものは、Anthropic公式のコスト解説にそのまま項目があります。

“Disable unused servers: Run /mcp to see configured servers and disable any you’re not actively using.”

（使っていないサーバーを無効にする：/mcpで設定済みのサーバーを一覧し、いま使っていないものは切る）

「登録してあるだけで使っていない」ものが、いちばん静かに消費を増やします。

そして同じ項目に、このサイトの趣旨からすると嬉しい一文が並んでいます。

“Prefer CLI tools when available: Tools like gh, aws, gcloud, and sentry-cli are still more context-efficient than MCP servers because they don’t add any per-tool listing.”

（使えるならCLIのツールを優先する：ghやawsのようなコマンドは、MCPサーバーより文脈の効率が良い。ツールごとの一覧を持ち込まないためです）

つまり、ステップ9でインストールしたghのような普通のコマンドが手元にあること自体が、節約になっているということです。エージェントはそれをそのまま打てるので、余計な仕込みが要りません。

⚠️ 「アーティファクトにすれば安い」は、逆です

節約の話でよく見かける説なので、ここだけ確かめておきます。結論から言うと、「アーティファクトにすると安くなる」と書いた公式の記述は見当たりません。 見つかるのは、逆向きの記述のほうです。

Claude Codeのアーティファクトは、セッションの成果物をclaude.ai上のページとして公開する機能です（Anthropic公式ドキュメント。Pro以上のプランで、/loginでサインインしたセッションが対象）。その公式ドキュメントに、こう書かれています。

“Generating an artifact uses output tokens like any other response, and a styled page is more token-intensive than the same content as terminal text. Inline CSS, JavaScript for interactive controls, and especially images embedded as data URIs are the main contributors.”

（アーティファクトの生成も、他の応答と同じように出力トークンを使います。そして体裁を整えたページは、同じ内容をターミナルのテキストで表示する場合よりもトークンを食います。埋め込みのCSS、操作用のJavaScript、とりわけデータURIとして埋め込まれた画像が主な要因です）

考えてみれば当たり前で、見た目を整えるための記述も、全部その場で生成しているからです。「きれいに出す」は、ただでは付いてきません。

ここから引き出せる一般則は、機能の名前よりもこちらです。同じ内容なら、飾りの少ない形で出してもらうほうが安い。 表やコードブロックくらいは気にしなくて構いませんが、「見栄えのする一枚もの」を頼むのは、それなりの出力を頼んでいるということです。

見やすさに価値がある場面で使うのは、もちろん構いません。ただ、節約を目的に選ぶものではありません。

アプリ版・ブラウザ版で使っている場合

ここまではターミナルのコマンドで書いてきましたが、アプリ版やブラウザ版から入っている方も多いはずです。

大前提——毎回すべて読み直される、というところは同じです。 打てる対策も、根っこは変わりません。ただしそのまま対応するものばかりではなく、計画モードやフック、サブエージェントのようにCLI側にしかない仕掛けもあります。ここでは、アプリ版でもそのまま効く2つを書きます。

/clearにあたるのは、「新しいチャットを始める」

Anthropic公式ヘルプも、上限が近づいたときの対処としてこれを挙げています。

“Try starting a new conversation if you’re approaching your usage limit in a longer chat.”

（長い会話で使用量の上限が近づいてきたら、新しい会話を始めてみてください）

そしてアプリ版にも、限界に近づくと自動で古い部分を要約する仕組みがあります。 上の/compactの項で「放っておいても自動で圧縮が走る」と書いたのと同じもので、こちらはAnthropic公式ヘルプにこう書かれています。

“When your conversation approaches the context window limit, Claude summarizes earlier messages.”

（会話がコンテキストウィンドウの上限に近づくと、Claudeはそれ以前のメッセージを要約します）

止まらずに済むのはありがたいのですが、要約が走るということは、そこにも消費があるということです。同じページに、こうあります。

“Longer conversations that trigger automatic context management consume more of your usage limit.”

（自動の文脈管理が走るような長い会話は、使用量をより多く消費します）

これは/compactがタダではないのと同じ話です。自動任せにせず、区切りのいいところで自分から新しいチャットに移ったほうが安く済みます。

繰り返し使う資料は、会話ではなく「プロジェクト」に置く

同じ資料を毎回チャットに貼り直しているなら、ここがいちばん効きます。 貼ったファイルは、以後のすべての発言で読み直される対象になるからです。

Anthropic公式ヘルプには、こう書かれています。

“When you upload documents to a project, they’re cached for future use.”

“Every time you reference that content, only new/uncached portions count against your limits.”

（プロジェクトにドキュメントをアップロードすると、以後の利用のためにキャッシュされます／その内容を参照するたび、上限にカウントされるのは新しい部分・キャッシュされていない部分だけです）

同じページの「Quick caching tips」も、方針は一行です——「Use projects for anything you’ll reference multiple times（複数回参照することになるものは、プロジェクトに置く）」。

「何度も見せるものは、置いておく。1回きりのものは、貼る。」 この線引きだけ持っておけば足ります。CLI側でCLAUDE.mdに共通の前提を書いておくのと、発想は同じです。

1時間あけて戻ると、その最初の一言が20倍になった

最後にひとつ。ここは実際に測ったので、数字ごと書きます。

同じ会話を送り直しても毎回満額かからないのは、一度処理した内容を再利用する仕組み（プロンプトキャッシュ——前回と同じ文章が先頭から続いている間は、処理済みのものを使い回す仕組み）が働いているからです。ただしこれには有効期限があり、Anthropicの公式ドキュメントによれば既定は5分、1時間に延ばす設定もあります（Claude Codeのサブスクリプションでは1時間）。

「処理し直す」とは、何をすることか

ここが分かりにくいところなので、具体で説明します。

モデルは答える前に、送られてきた会話の全体に目を通します。 この目を通す作業そのものが、使用量の本体です。

キャッシュは、その作業の結果を保管しておく仕組みです。 前回と同じ文章が先頭から続いていれば、保管してある結果をそのまま使えます。

20倍の差はここです。 何かを書き換えているわけではなく、同じ作業をもう一度やるかどうかの差です。

同じ大きさの会話でも、どちらになるかで変わります。 実測した2つを並べます。どちらも会話は38万トークン前後で、大きさは同じです。

1分未満のときの5,270トークンは、「前回の答え＋今回の質問」です。 会話は前回からその分しか伸びていないので、新しく処理するのはそこだけ。残りの38万は、保管してある結果を使い回しています。

1時間あくと保管が消えるので、38万全体を先頭から処理し直すことになります。 質問の中身は同じでも、73倍の量に目を通しています。

期限は、いつから数えられるのか

大事なのは、その1時間がいつから数えられるかです。 公式の記述はこうです。

“The cache is refreshed for no additional cost each time the cached content is used.”

（キャッシュは、使われるたびに追加のコストなしで期限が延びます）

つまり「会話を始めてから1時間」ではなく、「最後のやり取りから1時間」です。 話し続けている限り期限は切れません。手を止めた瞬間から、時計が動き始めます。

実際に測った境目

管理人の手元のMac mini 1台に残っていた作業記録（2026年9月、37,582回のやり取り）を集計しました。直前のやり取りから何分あいたかで分けて、再開したときに会話の何割を処理し直したかを見たものです。

56分では処理し直しがほぼゼロ、62分ではほぼ全部。 公式が書いている1時間が、そのまま境目として現れました。

1時間以上あけて再開した160件は、平均で38万6千トークンぶんを処理し直していました。 処理し直す側の単価は、使い回す側の20倍です。同じ質問でも、間隔が1時間を超えたかどうかだけで20倍変わります。

席を立つ前に/clear

戻ってきたときに処理し直す量は、席を立ったときに抱えていた会話の量で決まります。

• 38万トークンを抱えたまま離席 → 戻った最初の一言で、その38万を処理し直す
• 席を立つ前に/clear → 処理し直すのは4万5千ほど（指示書と設定だけ）。8分の1以下

/clear自体は何も消費しません。 迷う理由がないので、離席の前は打っておくのが得です。

⚠️ ここは仕様が変わりうる部分です。 有効期限も単価も提供側の設定で、告知なく変わることがあります。 上の数字は2026年9月に、管理人の1台で測った結果です。比率（20倍・8分の1）より、「間隔があくと処理し直しになる」という仕組みのほうを覚えておいてください。 仕組みが変わらない限り、/clearしてから離席する判断は変わりません。

まとめ

• 大前提：リクエストのたびに会話の全体が送り直されている。 長い会話ほど、その後の一言が高くつく
• 話題が変わったら/clear。 これがいちばん効く。しかも/clear自体は何も消費しない
• 話題が変わらなくても、往復30〜50回（会話の量で15万トークン前後）が目安。 ただし17〜84回のどこでも1割しか違わないので、厳密さは要らない。やり直しの損は測れていないので、迷ったら長いほうへ
• 席を立つ前に/clear。 キャッシュの期限は最後のやり取りから数えるので、1時間あけて戻ると、その最初の一言は20倍になる（手元の1台での実測）。抱えたまま離席するか、空にしてから離席するかで8倍以上違う
• 続けたいときは、/compactに焦点を指定する。 ただしcompact自体が大きなリクエストなので、仕切り直しでいいなら/clearのほうが安い
• /contextで現状を見る。 思わぬものが場所を取っていることがある。見るのはほぼタダなので、我慢して節約する必要はない
• 「確認」は3種類。 ①使用量を見る（ほぼタダ）②方向を確かめる（安い。やり直しを防ぐ）③直しを指示する（高い）。①②はちょくちょく、③はまとめて
• 方向がずれたまま進んだ分は、無駄になるだけでなく会話に残って以後ずっと課金される。Escapeで止め、/rewindで戻す
• 確認を仕組みに寄せる。計画モードで先に作戦を見る、「こうなったら成功」を先に渡す、フックで渡す前に絞る
• 頼み方を具体的に。 曖昧だと探しに行かれる
• 直しはまとめて1回で。 3回に分ければ、3回とも会話全体を読み直させることになる
• 軽い直しは自分でやる。 誤字ひとつのために全文を作り直させると、その全文が会話に残る
• CLAUDE.mdは短く（200行未満が目安）。重い調べ物はサブエージェントへ。使っていないMCPサーバーは切る（公式は「使えるならCLIのツールを優先」とまで書いている）
• 見た目を整えた出力は、素のテキストより高くつく。 「アーティファクトにすれば安い」は逆
• アプリ版なら、区切りで新しいチャットへ。何度も使う資料はプロジェクトに置く（キャッシュが使われ、再利用分は上限にカウントされない）

細かく見えますが、全部「読み直させる量を減らす」の一点に由来します。 そこさえ押さえておけば、個別のコマンドを忘れても自分で判断できます。

ひとつ補足を。この記事の「ちょくちょく確認する」と、「コマンド承認地獄」との付き合い方で書いた「承認を減らす」は、一見ぶつかって見えます。指しているものが違います。

• 承認プロンプトは、1コマンドごとの安全確認。lsのような無害なものまで聞かれるので、許可リストを育てて減らしてよい
• この記事で言う確認は、4で分けた3種類の①と②——使用量を見ることと、向かっている方向が合っているかを確かめること。こちらは減らすほど高くつく

手数は減らしていい。見るのと、方向の確認は減らさないほうが安い。 そういう関係です。