「そろそろ /compact したほうがいいのかな」と感じながらも、タイミングがわからずズルズル使い続ける。あるいは、Opus でガッツリ作業した後で「今日いくら使ったんだろう」と不安になる。Claude Code を日常的に使っていると、こういう見えないストレスが地味に積み重なる。
これを解消する機能が statusline だ。画面下端に 1 行、モデル名・コンテキスト使用率・セッションコスト・Git ブランチを常時表示できる。設定さえすれば、もう「今何%使ったか」を手作業で確認する必要はない。
この記事では、公式 /statusline コマンドで自動生成する方法、settings.json に手書きで最小構成を書く方法、そして ccstatusline で本格的に可視化する方法を順に紹介する。
Statusline とは何か
Claude Code の画面下に表示される 1 行が statusline だ。設定ファイルにシェルスクリプトのパスを書いておくと、Claude Code がアシスタントメッセージの後や /compact 完了後などのイベント駆動でそのスクリプトを実行し、出力をそのまま画面に反映する。更新は 300ms のデバウンス処理を経て反映される（定期ポーリングではなくイベント駆動）。
スクリプトには標準入力から JSON が渡される。主要フィールドは次のとおりだ（公式ドキュメントより抜粋）。
{
"model": {"id": "claude-opus-4-7", "display_name": "Opus"},
"workspace": {"current_dir": "/path/to/project"},
"cost": {
"total_cost_usd": 0.12,
"total_duration_ms": 30000,
"total_lines_added": 5,
"total_lines_removed": 2
},
"context_window": {
"used_percentage": 42,
"remaining_percentage": 58,
"context_window_size": 200000
},
"session_id": "...",
"transcript_path": "..."
}この JSON から jq で必要な値を取り出し、echo で出力するだけで好みの表示が作れる。設定自体は ~/.claude/settings.json の statusLine キーに書く。
{
"statusLine": {
"type": "command",
"command": "/path/to/script.sh",
"padding": 0
}
}シンプルな仕組みだが、「スクリプトが重いと UI が固まる」という落とし穴がある。イベントが頻繁に発生する作業中は実質的に高頻度で git branch などが走るため、後述するキャッシュ設計が効いてくる。
なお、settings.json の管理についてはセキュリティ運用記事（2026/05/18）でも触れているので、プロジェクト別設定とユーザー設定の使い分けと合わせて読むと参考になる。
/statusline コマンドで自動生成する
手書きなしに始めるなら /statusline が早い。Claude Code のコマンドとして自然言語で指示すると、スクリプトを生成して ~/.claude/settings.json へ自動登録してくれる。
/statusline モデル名と現在のブランチを左、コストを右に表示してほしいこれだけで動く。生成されたスクリプトは ~/.claude/scripts/ 以下に置かれ、設定も自動で更新される。「何を表示したいか」だけ決まっていれば、jq や bash を知らなくても始められる。
ただし、生成されたスクリプトの中身は一度確認しておいた方がいい。リフレッシュ頻度への配慮がされていない場合、重い処理が含まれていることがある。特に Git コマンドが直叩きになっていたらキャッシュを入れるか、後述の ccstatusline に切り替えることを検討したい。
手書き最小構成：bash + jq で 5 行
自分でコントロールしたい派には、最小限のスクリプトを手書きする方法が向いている。
#!/bin/bash
input=$(cat)
model=$(echo "$input" | jq -r '.model.display_name')
dir=$(echo "$input" | jq -r '.workspace.current_dir' | sed "s|$HOME|~|")
cost=$(echo "$input" | jq -r '.cost.total_cost_usd // 0' | awk '{printf "$%.3f", $1}')
echo -n "[$model] $dir | $cost"これを ~/.claude/scripts/statusline.sh として保存し、実行権限を付与する。
chmod +x ~/.claude/scripts/statusline.sh~/.claude/settings.json に次の設定を追加する。
{
"statusLine": {
"type": "command",
"command": "~/.claude/scripts/statusline.sh"
}
}Claude Code を再起動すれば画面下に [Opus 4.7] ~/project | $0.042 が表示される。
コンテキスト使用率は context_window.used_percentage として JSON に含まれているため、jq -r '.context_window.used_percentage // 0' で取得できる。まずはセッションコストとモデル名の 2 点だけでも「今日いくら使っているか」「Sonnet と思ったら Opus だった」という事故は防げる。
なお、Hooks との組み合わせ（たとえば /compact 実行後に statusline を更新するトリガーを仕込む）についてはHooks 実例記事（2026/05/19）を参照してほしい。
ccstatusline で本格運用する
手書きの範囲を超えた可視化が必要なら、コミュニティツール ccstatusline（GitHub: sirmalloc/ccstatusline、MIT ライセンス）が事実上のデファクトになっている。スター数は 9,400 を超えており、活発にメンテされている。
インストール
# npm を使う場合
npx -y ccstatusline@latest
# bun を使う場合
bunx -y ccstatusline@latest起動すると TUI（Terminal UI）が立ち上がり、widget を選択・並べ替えして設定を完成させる。設定が決まると Claude Code の settings.json に直接書き込んでくれるため、手動編集は不要だ。
使えるもの
widget は 40 種類以上あり、主なカテゴリはこうなる。
使用量・コスト系はセッションコスト、モデル名、セッション時間、トークン速度（直近 0〜120 秒の窓で計算）、週次の Sonnet/Opus 別使用量、コンテキスト追跡、thinking effort レベルが揃っている。
Git 系はブランチ名（GitHub/GitLab へのクリッカブルリンク付き）、PR/MR の状態・タイトル、staged/unstaged/untracked ファイル数、コンフリクト数、insertions/deletions など。
システム系はカレントディレクトリ、メモリ使用量、Claude アカウントの email が選べる。
Git worktrees を使って複数セッションを並列実行しているときに「どのブランチで作業しているか」が常時見えるのは実際に便利で、私の場合はこれだけでも導入の価値があった。
Powerline 対応
v2.0.0 から Powerline スタイルの矢印セパレーターに対応している。見た目を整えたいなら設定 TUI で Powerline mode を ON にするだけでいい。複数行の statusline も v2.0.11 以降は行数無制限で設定できる。
設計のコツ：リフレッシュ頻度とキャッシュ
statusline はイベント駆動（アシスタントメッセージ後など）でスクリプトが実行されるため、作業が活発な時間帯は実質的に高頻度で動く。重い処理を書くと Claude Code の応答が鈍くなる。手書きスクリプトを育てていくうちに気づいたことをいくつか書いておく。
Git コマンドはキャッシュする
git branch --show-current は軽い部類だが、git status や git log を毎回叩くのは避けた方がいい。ファイル更新をトリガーにしてキャッシュに書き込む設計か、ccstatusline のキャッシュ機能（~/.cache/ccstatusline/git-cache）を使う方が安定する。
表示する情報を絞る
「全部見たい」という誘惑に負けてwidgetを詰め込みすぎると、statusline が 2 行になり視認性が落ちる。私はコンテキスト使用率・セッションコスト・ブランチ名を起点にして、必要に応じて追加していくやり方に落ち着いた。
モデル切り替えを常時表示する
Sonnet と Opus を使い分けるなら、モデル名の表示は外せない。「コストを抑えようと Sonnet に切り替えたつもりが、設定が残っていて Opus のまま 30 分動かしていた」というのは笑えない失敗だ。モデル名を statusline の先頭に固定しておくと、切り替えミスにすぐ気づける。
まとめ
statusline は Claude Code の「見えない不安」を解消する地味だが確実な設定だ。公式 /statusline コマンドなら 1 分で動く。自分でコントロールしたければ bash + jq の 5 行スクリプトで十分な情報が得られるし、Git 連携や Powerline スタイルまで必要なら ccstatusline の完成度が高い。
手段がどれであれ、コンテキスト使用率とセッションコストだけは表示しておいた方がいい。「使いすぎたかも」という漠然とした不安は、数字が見えているだけで消える。
まずは /statusline コマンドを 1 回実行して、画面下に何かが表示される状態を作ってほしい。
コメント