Claudeを起動しただけで利用枠が27%消えていた話 ― 犯人は「自分が仕込んだ自動化」だった
Claude Code を起動して端末を開く。まだ何も打っていない。なのに、ステータスラインの利用枠がすでに27%減っている。
最初は「Claude 本体が毎回読み込む前置き（システムプロンプトやスキルの一覧）が重いんだろう」と考えた。結論から言うと、それは誤診だった。犯人は、数週間前の自分が「作業を自動化して楽をしよう」と思って仕込んだ、macOS のスケジューラ（launchd）から Claude をヘッドレス実行するジョブ群だった。しかもそれらは、私が端末を開く前に走って枠を食っていた。
この記事は、その原因を推測ではなく実測で突き止めるまでの手順と、同じ状況にいる人が自分の環境で切り分けるための方法をまとめたものだ。「Claude の使用量がいつの間にか減っている」と感じたことがある人向けの、体験と実測の記録になっている。
症状：何も入力していないのに枠が減っている
状況はこうだった。
朝、Mac を起動して Claude Code の端末を開く
まだプロンプトを一文字も入力していない
それなのに、5時間の利用枠のメーターが「27%消費済み」と出ている
ひどいときは、少しやり取りしただけで枠の上限に当たり、作業が止まる
「起動しただけで4分の1が消えている」というのは、体感としてかなり大きい。5時間の利用枠を4分の3しか使えない状態でその日の作業を始めることになる。実際、少し込み入った調べ物を1本やっただけで枠の上限に当たり、次のブロックまで1〜2時間待たされたこともあった。「まだ何もしていないのに」という感覚が強かったので、これは一度きちんと原因を潰そうと決めた。
まず疑ったのは、Claude Code が会話を始める前に固定で読み込んでいる前置き（プリアンブル）だった。設定を盛っている自覚があったからだ。
最初の誤診：前置き（プリアンブル）を疑った
Claude Code は、ユーザーが最初のメッセージを送る前に、いくつかのものを固定で読み込む。ざっと挙げるとこうだ。
ベースのシステムプロンプト：本体の指示、ハーネスの規約、ツールの使い方
組み込みツールの定義：ファイル読み書き、シェル実行、検索などのスキーマ
MCP サーバー：外部連携（ブラウザ操作、カレンダー、ストレージ等）の指示文とスキーマ
プロジェクト設定ファイル群：複数階層の設定・ポリシー・ルールファイル
スキルの一覧：使えるスキル全部の名前と説明文
カスタムエージェントの一覧：自作サブエージェントの種別と説明
メモリ：永続メモの索引と、想起された本文
私の環境は、この積み上げが厚い方だった。設定ファイルが4階層、スキルが約40個、MCP サーバーが4つ、カスタムエージェントが十数種類。だから「この前置きが枠を27%食っているに違いない」と考えた。
ところが、/context（コンテキストウィンドウの内訳を表示するコマンド）を実行してみると、話が合わなかった。私は大きめのコンテキストウィンドウ（1M トークン）で運用している。その状態では、前置きを全部足しても使用率は数%にしかならない。仮に削れるところを全部削っても、減るのは1%未満。「27%」とは桁が違う。
ここで、ようやく前提の間違いに気づいた。私が見ている「27%」と、/context が示す数字は、別々のメーターだった。
原因の核心：2つの別メーターを混同していた
Claude Code で「使用量」と呼ばれるものには、少なくとも2つある。これを混同すると、いくら前置きを削っても症状が消えない。
① コンテキストウィンドウ使用率
見る場所：/context
何の量か：「今の1回の会話」に積まれているトークン量
リセット条件：/clear や新規セッション起動で即ゼロ付近に戻る
共有範囲：そのセッション内で閉じている
② 5時間ローリングの利用枠
見る場所：/status、ステータスライン
何の量か：一定時間内に使える総量の消費分
リセット条件：5時間のタイマーが切り替わったときだけ。/clear や新規起動では戻らない
共有範囲：すべての Claude 利用で共有（複数の Code セッション、ブラウザ版、スケジュール実行、バックグラウンド処理をまたいで合算される）
ポイントは②の性質だ。②は「今このセッションで何をしたか」とは無関係に、同じ5時間ブロックの中で、どこかで誰か（何か）が Claude を使っていれば、その分が繰り越されて乗っている。
だから、/context が5%（＝今の会話はほとんど何も積んでいない）でも、②が27%になることは普通に起こりうる。新しく起動しても②は戻らないからだ。
切り分けの第一歩
「起動時X%」の画面で、まず次を確認する。
その画面で /context を実行する
/context 自体が27%と出る → ①の話。原因は、--continue や --resume を使って前のセッションの履歴（または圧縮された要約）を読み直していること。長時間使った会話は数十万トークン積まれるので、それを引き継げば起動時点で20〜30%になる。対策は「不要なら --continue せず、素の状態で起動する」
/context は数%なのに、別の数字（ステータスライン等）が27% → ②の話。それは利用枠のメーターで、/status に内訳が出る。対策は「前置きいじり」ではなく「5時間ブロックの中で他に何が Claude を使っているか」の棚卸し
私の場合は2だった。/context は5%。つまり②。「端末を開く前に、何かが枠を食っている」ということになる。
実測で犯人を特定する
心当たりを探すと、すぐ見つかった。私は以前、個人のメモ管理フォルダ（Obsidian の Vault）の整理を自動化するために、macOS の launchd（OSのスケジューラ）から Claude をヘッドレス実行（claude -p 相当、対話画面を出さずにプロンプトを1回投げる使い方）するジョブをいくつも仕込んでいた。
未分類メモとタスクを検知して一覧を更新するジョブ
「承認済み」と書いたタスクを拾って処理するジョブ
「回答済み」タスクを拾って処理するジョブ
セッション履歴を観察して「繰り返している作業」の候補を出すジョブ
どれも「自分がやると面倒だから Claude に自動でやらせる」という発想で作ったものだ。当時は良いアイデアだと思っていた。
ログから比率を出す
私は Claude Code のセッションログを自分で SQLite に取り込んでいる。そこで直近9日分を集計し、「対話（自分が打ったセッション）」と「自動実行（スケジューラが起動したセッション）」を、プロンプトの先頭文字列で分類して、消費量の比率を出した。
消費量はトークン種別で重みが違う（概算で「出力×5 ＋ 入力×1 ＋ キャッシュ書き込み×1.25 ＋ キャッシュ読み込み×0.1」くらい）。正確な係数は非公開なので、絶対値ではなく比率で見る。
結果はこうだった（直近9日、加重トークンに占める割合）。
自動実行ジョブ 合計：約23%
うち「タスク検知の一覧更新」ジョブ単独：約15%（自動実行分の約73%）
残りは対話・その他
「自動実行分＝約23%」。私が体感していた「起動時27%」と、ほぼ一致する。ジョブ別に分けると、消費の偏りがはっきり出た（カッコ内は「自動実行分に占める割合／1回の重さ／1日の実行回数」）。
タスク検知の一覧更新：約73%／キャッシュ読み込み 約180万トークン／6〜8回
「回答済み」タスクの処理：約9%／中／3回
「承認済み」タスクの処理：約9%／中／3回
セッション履歴の観察：約2%／小／1回
その日のメモ棚卸し：約1%／小／1回
上位1本が全体の7割を占めている。「全部が均等に悪い」のではなく、「特定の1本が突出して重い」というパターンだった。これは対策を考えるうえで重要で、上位1本を止めるだけで自動実行分の大半が消えることを意味する。
なぜ「起動する前」に食われるのか
犯人が一番効いていたのは、2つの増幅メカニズムだった。
1. 起動時トリガー（RunAtLoad）
一部のジョブに「Mac の起動・ログイン時に即実行する」という設定（launchd の RunAtLoad。cron でいう @reboot に近い）が入っていた。つまり、朝 Mac を立ち上げてコーヒーを淹れている間に、勝手に Claude が走って枠を消費していた。ログを見ると、定時スケジュールと関係ない朝7〜9時台の起動が毎日あった。
2. 固定時刻スケジュールが密
検知系のジョブが2〜3時間おき（9時・11時・13時・15時・17時・19時など）に走る設定になっていた。どの5時間の窓を切り取っても、検知2〜3本＋処理系1〜2本が必ず入る。たとえば15時30分に端末を開くと、直前5時間（10:30〜15:30）に11時・13時・15時の検知ジョブと、その間の処理系ジョブで、合計5本のヘッドレス実行がすでに枠を使い終わっている。
さらに、主犯の「タスク検知の一覧更新」ジョブはプロンプト自体が重かった。「未分類メモの本文を全部読む」「全プロジェクトの索引ファイルを読む」「タスクごとに Vault を検索して関連メモを探す」を毎回フルでやる。1回あたりキャッシュ読み込みで約180万トークン、これが1日6〜8回。効率化のつもりが、一番の浪費源になっていた。
誰でもできる切り分け手順（まとめ）
この経験を一般化すると、「起動しただけで枠が減っている」は次の順で切り分けられる。
メーターを特定する。 枠が減っている画面で /context と /status を両方見る。/context 自体が高いなら①（履歴の引き継ぎ）、/context は低いのに別の数字が高いなら②（利用枠の繰り越し）。
①なら履歴の引き継ぎを疑う。 --continue / --resume を常用していないか。長時間の会話をずっと引きずっていないか。話題が変わったら区切る。
②なら「自分が見ていない時間の Claude 利用」を疑う。 候補は次のとおり。
スケジュール実行（Claude Code のスケジュール機能、繰り返し実行機能）
OSのスケジューラ（macOS の launchd、Linux の cron、Windows のタスクスケジューラ）から Claude を叩くジョブ
別マシンやブラウザ版での利用（これは同じアカウントなら②に合算される）
トリガーを確認する。 launchd なら launchctl list、cron なら crontab -l、Claude Code 内蔵なら各機能の一覧コマンド。特に「起動時／再起動時」に発火する設定（RunAtLoad、@reboot）は、利用者不在で走るので体感ゼロのまま枠だけ減る。
比率を出す。 ログ（自前のDBやセッション履歴）があるなら、「対話」と「自動実行」をプロンプトの先頭文字列で分類して、消費量の比率を出す。絶対値は出せなくても「起動前の消費の何%が自動実行か」は分母に依存せず出せる。
対策と結果
やったことはシンプルだ。ヘッドレス実行の4ジョブ（検知系・処理系・観察系）を停止した。
設定ファイル（plist）はバックアップを取ってから、無効化用のフォルダへ退避した。削除はしていない。 戻したくなったら元の場所に置いて再登録すれば復活する（切り戻し可能）。
残したのは、1日1回だけ・深夜に走る軽いジョブ（その日のメモの棚卸し）と、Claude を使わないバックアップ処理だけ。
結果、起動時の枠消費は 27% → 0〜3% になった。削るべきだったのは「Claude 本体の前置き」ではなく、「自分が仕込んだ自動実行」だった。
止めたものと残したものの線引き
全部を止めたわけではない。判断の基準はこうした（「止めた条件 ↔ 残した条件」）。
実行頻度：1日3回以上 ↔ 1日1回だけ
1回の重さ：Vault 全体をスキャンするような重いプロンプト ↔ 差分だけを見る軽いプロンプト
起動時トリガー：あり（RunAtLoad）＝不在時に発火 ↔ なし＝決まった時刻に1回
代わりの手段：端末を開いたときに手動で実行できる ↔ 深夜など、そもそも自分が起きていない時間にやってほしい
「メモの棚卸しを毎晩22時に1回」だけは残した。これは消費が小さく、かつ「寝ている間にやっておいてほしい」ものだからだ。逆に、日中2〜3時間おきに Vault 全体をスキャンする検知ジョブは、必要になったら端末で手動実行すればいい。自動化する価値が、消費量に見合っていなかった。
教訓
この件で学んだことは3つある。
1. 「効率化のための自動化」が「リソースを食う自動化」に化けていた。
特に「利用者が画面を見ていない時間に走るもの」は、体感コストがゼロなので、重くても気づかない。気づいたときには枠を毎日食っている。自動化を足すときは「これは自分がいない時間にどれくらいの頻度で走り、1回どれくらい使うのか」を最初に見積もるべきだった。
2. メーターの意味を取り違えると、対策の方向が丸ごとずれる。
「使用量27%」を見て前置きを削ろうとしていた時間は、完全に無駄だった。数字が何を指しているのか（今の会話の量なのか、時間あたりの枠なのか）を先に確定させる。/context と /status は別物。
3. 止めるときは可逆な形で。
plist を削除せず退避しただけなので、「やっぱり検知ジョブは1日1回だけ欲しい」と思えばすぐ戻せる。いきなり消していたら、設定を作り直す羽目になっていた。自動化の棚卸しは「消す」より「頻度を下げる・起動時トリガーを外す・退避する」から始めるのが安全だ。
4. 自動化は「作ったら終わり」ではなく、定期的に棚卸しする。
今回の重いジョブも、作った当初は「再起動時のみ実行」だった。それを後から「日中も2〜3時間おきに」と頻度を上げ、そのまま忘れていた。追加や変更のたびに少しずつ重くなり、全体像を誰も把握していない状態になっていた。月に1回でいいので、「今動いている自動実行を全部書き出して、それぞれ本当に要るか」を見直す時間を取ることにした。書き出す先は、この記事のように1枚のメモにまとめておくと次に見直すときに早い。
もし同じように「Claude を起動しただけで使用量が減っている」と感じているなら、まず /context と /status を両方見て、どちらのメーターの話なのかを確定させるところから始めてほしい。そこさえ間違えなければ、原因の8割は「自分が過去に仕込んだ何か」の中にある。
