0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@saitoko(さいとう こういち)

Claude Codeのステータスラインに何を表示するか——ワークスタイルに合わせると、ターミナルを離れなくなる

0
Last updated at Posted at 2026-06-28

この記事の要点: Claude Code のステータスライン（画面下部のカスタム情報バー）は、~/.claude/settings.json に statusLine を1ブロック書くだけで有効になり、stdin で渡される JSON を加工して任意の文字列を出せる。私は標準的なモデル名・コンテキスト使用率に加えて、GTD のタスク件数（GitHub Issue を5分キャッシュで集計）・再生中の音楽・宣言中の作業タスクの3つを足して常時4行表示にしている（2026-06-28 時点・実機スクリプト118行）。本記事では公式の設定方法、一般的な表示項目のカタログ、私の構成と選択理由、そして「増やしても邪魔にならない」ための行ごと消える設計を扱う。

ステータスラインとは何か

ステータスラインは、Claude Code の画面最下部（組み込みフッターの1段上）に表示されるカスタム情報バーだ。公式ドキュメントの説明によれば、Claude Code が起動するシェルスクリプトに JSON のセッション情報を stdin で渡し、スクリプトが標準出力に書いた文字列をそのまま描画する仕組みになっている。

つまり「シェルで echo できる情報なら何でも出せる」。モデル名やコンテキスト使用率といった Claude Code 内部の状態だけでなく、Git のブランチ、外部 API で取った天気、別プロセスの状態まで、スクリプトが取得できる情報はすべて候補になる。ここがステータスラインの面白いところで、本記事の主題でもある。

有効化のしかた（基本形）

設定は ~/.claude/settings.json に statusLine フィールドを足すだけだ。type を "command" にして、command に実行するスクリプトのパスを指定する。

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 2
  }
}

padding は左端の余白で、省略可能だ。スクリプトを用意せずワンライナーを直接書くこともできる。たとえば公式ドキュメントが挙げている最小例はこうだ。

{
  "statusLine": {
    "type": "command",
    "command": "jq -r '\"[\\(.model.display_name)] \\(.context_window.used_percentage // 0)% context\"'"
  }
}

これだけで [Claude Sonnet 4.6] 34% context のような1行が画面下部に出る。スクリプトに渡ってくる JSON には、たとえば次のようなフィールドがある（一部抜粋）。

フィールド 内容
model.display_name 現在のモデル表示名
context_window.used_percentage コンテキスト使用率（計算済みのパーセント値）
cost.total_cost_usd セッションの推定コスト（USD、クライアント側計算）
workspace.current_dir カレントディレクトリ
rate_limits.five_hour.used_percentage 5時間レート制限の使用率（0〜100）
rate_limits.seven_day.used_percentage 7日間レート制限の使用率（0〜100）

rate_limits は Claude.ai サブスクリプション（Pro / Max）の契約者で、かつセッション中に最初の API 応答が返った後にだけ現れる。各ウィンドウ（five_hour / seven_day）は独立して存在しないことがあるため、公式ドキュメントは jq -r '.rate_limits.five_hour.used_percentage // empty' のように // empty でフォールバックを書くことを勧めている。私のスクリプトもこの書き方を踏襲している。

一般的に何が表示されているか

世の中のステータスライン事例を眺めると、表示項目はだいたい3つの層に分かれる。ここでは「定番」「中級」「凝った」の順にカタログしておく。自分のラインに何を足すか考えるときの引き出しとして使ってほしい。

A. 定番（最頻出）

  • モデル名（Sonnet / Opus などの短縮表記）
  • コンテキスト使用率（%）と色付きプログレスバー（緑→黄→赤）
  • セッション累積コスト（USD）
  • Git ブランチ名
  • ワーキングディレクトリ / プロジェクト名

このあたりは「常に見えていてほしい現在地」だ。特にコンテキスト使用率のバーは、長い作業でいつコンパクション（文脈の自動圧縮）が走りそうかを読むのに役立つ。

B. 中級（複数の事例で見かける）

  • 5時間 / 7日間レート制限の使用率＋リセットまでの残時間
  • セッション経過時間
  • Git のステージ済み / 未ステージ / 未追跡ファイル数（S:0 U:1 A:0 のような表記）
  • セッション中の追加 / 削除行数（+42 -7 形式）
  • 今日の累積コスト＋バーンレート（🔥 $0.12/hr）
  • 入力 / 出力トークン数、キャッシュヒット率

コストとレート制限の可視化は、ccusage（コスト・バーンレート特化のツール）のようなライブラリを噛ませて実現している例が多い。

C. 凝った・ユニークな例

  • リーズニング（思考）の強度インジケーター
  • Anthropic Platform の稼働ステータス（status.claude.com を監視）
  • vim モードの自前描画
  • 実行中のサブエージェント名
  • GitHub / GitLab の PR タイトルとステータス、未マージ PR 数
  • 天気・大気質（AQI）・日の出日の入り時刻（外部 API）
  • 別タイムゾーンの現在時刻、特定日までのカウントダウン
  • 未読メール数、次のカレンダー予定と残り時間
  • ブランチ名をクリック可能なリンクにして、ターミナルから GitHub を直接開く

C 層まで来ると、もはや「Claude Code の状態表示」という枠を超えて、自分専用のダッシュボードになっている。天気やカレンダーまで出すかどうかは好みの問題だが、「シェルで取れる情報は何でも置ける」という設計思想がよく分かる事例群だ。

Claude Codeのステータスラインに追加した3つの情報

ここからが本題だ。私のステータスラインは、A 層の定番に加えて、自分のワークスタイルに直結する3つの情報を足してある。実機のスクリプト（118行）が実際に出す4行はこうなっている。

Claude Sonnet 4.6  Ctx:[███░░░░░░░] 34%  5h:[██░░░░░░░░] 22%  7d:[█░░░░░░░░░] 8%  00:07
📥 0  🎯 6  ⏳ 6  🌈 89  🔁 6  📁 19  📎 7
🎯 #1544 Vol.5 Zenn公開
♫ 夕凪 — 宇多田ヒカル

上から順に役割を説明する。

  • 1行目: モデル名＋コンテキスト / 5時間 / 7日間の各バー＋日本時間（HH:MM）。バーは使用率に応じて色が変わる（後述）
  • 2行目: GTD のタスク件数。📥 inbox / 🎯 next / ⏳ waiting / 🌈 someday / 🔁 routine / 📁 project / 📎 reference
  • 3行目: いま宣言している作業タスクの ID とタイトル
  • 4行目: Music アプリで再生中の曲名とアーティスト

A 層との違いは、2〜4行目がいずれも「Claude Code の外側にある私の状況」だという点だ。タスク管理ツールの中身、音楽プレイヤーの状態、自分が宣言した作業対象——これらをターミナルの底に集約した。理由を1つずつ書く。

GTDカウント——Inboxの溜まり具合が頭の片隅に残る

私はタスクを GitHub Issue で GTD（Getting Things Done）管理している。2行目はその件数を、gh issue list でラベル別に集計して出している。狙いは単純で、Claude Code で作業しているあいだも「いま Inbox に何件溜まっているか」が視界の隅に残ること。タスク状況を確認するためにわざわざ別のウィンドウへ切り替えなくていい。

GTD の仕組み自体については「Claude Code GTDスキルにPro機能を実装した話」に詳しく書いた。

ただし、ここには1つ実装上の工夫が要る。gh issue list はネットワーク越しに GitHub API を叩くため、毎回実行すると数百ミリ秒かかる。ステータスラインはセッション中に何度も再描画されるので、その都度 API を叩くと体感が重くなる。そこで私は集計結果を5分間キャッシュしている。キャッシュの仕組みはこうだ。

GTD_CACHE="$HOME/.claude/gtd-counts-cache"
GTD_CACHE_TS="$HOME/.claude/gtd-counts-ts"
GTD_CACHE_TTL=300   # 5分

needs_refresh=true
if [ -f "$GTD_CACHE" ] && [ -f "$GTD_CACHE_TS" ]; then
  last_ts=$(cat "$GTD_CACHE_TS" 2>/dev/null || echo 0)
  now=$(date +%s)
  [ $(( now - last_ts )) -lt "$GTD_CACHE_TTL" ] && needs_refresh=false
fi

タイムスタンプを別ファイルに記録しておき、前回取得から300秒以内ならキャッシュをそのまま使う。古くなっていれば gh issue list で取り直してキャッシュを更新する。タスク件数は秒単位の鮮度を必要としないので、5分遅れても実害はない。「正確さ」より「描画が止まらないこと」を優先した判断だ。

外部コマンドや API を呼ぶ項目をステータスラインに足すなら、このキャッシュの考え方は応用が利く。天気でもカレンダーでも、更新頻度の許容範囲を決めて TTL（生存期間）を設ければ、重い取得処理を毎描画から切り離せる。

current-task連携——「今やっていること」が常時見える

3行目は、いま自分が宣言している作業タスクだ。私は /current-task #1544 Vol.5 Zenn公開 のように作業対象を宣言するスキルを使っており、その内容を ~/.claude-state/current-task という1ファイルに書き出している。ステータスライン側はそれを読むだけだ。

CURRENT_TASK_FILE="$HOME/.claude-state/current-task"
if [ -f "$CURRENT_TASK_FILE" ]; then
  current_task=$(cat "$CURRENT_TASK_FILE" 2>/dev/null)
  [ -n "$current_task" ] && current_task_line="🎯 $current_task"
fi

補足: /current-task は私が個人的に組んでいるスキルで、Claude Code 標準の機能ではない。再現したい場合は、作業対象を1ファイル（例: ~/.claude-state/current-task）に書き出す仕組みなら何でもよい。echo "#1544 Vol.5 Zenn公開" > ~/.claude-state/current-task のように手で更新するだけでも同じ表示になる。

これを足してから、作業の脱線が減った。今やるべきことが画面の底に固定表示されていると、別の気になる Issue に手を出しかけたときに「いや、今は #1544 だ」と引き戻される。タスク宣言を「自分への約束」として可視化する効果がある。

Now Playing——どんな曲を聴きながら書いたかが残る

4行目は Music アプリで再生中の曲だ。pgrep で Music プロセスの存在を確認し、起動していれば AppleScript（osascript）で再生状態と曲名・アーティストを問い合わせる。

if pgrep -xq "Music"; then
  music_info=$(osascript -e '
    tell application "Music"
      if player state is playing then
        return "♫ " & name of current track & " — " & artist of current track
      end if
    end tell' 2>/dev/null)
  [ -n "$music_info" ] && music_line="$music_info"
fi

これは実用というより記録のための表示だ。作業中にかけている曲が見えると、後で「あの記事はどんな音楽を聴きながら書いたか」が思い出せる。実利は薄いが、ターミナルに自分の作業の手触りが残るのが気に入っている。

なお、このブロックは macOS の Music アプリと AppleScript に依存している。別 OS や別プレイヤーで再生中の曲を出したい場合は、playerctl（Linux の MPRIS 経由）など環境ごとの取得手段に置き換える必要がある。AppleScript で Music アプリを操る仕組みについては「Claude Code から Mac の Music.app を AppleScript で操る /dj スキルを自作した」でも触れている。

ステータスラインを増やしても邪魔にならない——行ごと消える設計

ここまで「足した、足した」と書いてきたが、表示項目を増やすと当然ながらラインは縦に伸びる。私の場合、current-task と Now Playing を足した結果、上限で4行になった。

それでも「多い」とは感じなかった。理由は、4行が常に4行ではないからだ。私のスクリプトは、各行を「中身があるときだけ出す」設計にしてある。出力部分を抜き出すとこうだ。

# 1行目（モデル＋バー＋時刻）は常に出す
printf "%s  Ctx:%s  5h:%s  7d:%s  %s" "$model" "$ctx_bar" "$rate_bar" "$rate_7d_bar" "$jst_time"
# 2行目以降は、中身があるときだけ改行して追加
[ -n "$gtd_line" ]         && printf "\n%s" "$gtd_line"
[ -n "$current_task_line" ] && printf "\n%s" "$current_task_line"
[ -n "$music_line" ]        && printf "\n%s" "$music_line"
printf "\n"

タスクを宣言していなければ3行目は出ない。音楽を止めれば4行目は消える。つまり、何も宣言せず音楽も止まっているときは2行に戻る。情報は「常時4行を占有する」のではなく、「状況に応じて現れたり消えたりする」。

この発想の転換が、項目を増やすときの鍵だと思っている。「情報を詰め込む」と考えると、行数が固定的に増えて画面を圧迫する。だが「状況に応じて出る / 消える」と考えれば、関係ない情報は自動的に引っ込むので、増やしても普段の見た目は重くならない。

応用すると、たとえば「Git のブランチ名はメインブランチのときだけ警告色で出し、作業ブランチでは出さない」「コンテキスト使用率は80%を超えたときだけ赤帯で大きく出す」といった、条件付き表示のラインも組める。常時すべてを見せるのではなく、「今この情報が要る状況か」をスクリプト側で判定して出し分ける。これが、増やしても邪魔にならないステータスラインの作り方だ。

バーの色も「状況に応じて」変える

同じ考え方で、1行目の各バーは使用率に応じて色を変えている。私のスクリプトのしきい値は、60%未満が緑、60〜79%が黄、80%以上が赤だ。

if [ "$pct_int" -le 59 ]; then
  color="\033[32m"   # 緑
elif [ "$pct_int" -le 79 ]; then
  color="\033[33m"   # 黄
else
  color="\033[31m"   # 赤
fi

色は ANSI エスケープコードで指定する（\033[32m が緑、\033[33m が黄、\033[31m が赤、\033[0m でリセット）。コンテキストが赤くなってきたら、そろそろ区切りを入れるかコンパクションを意識する、という具合に、数字を読まずとも色で状況が分かる。しきい値は好みで、公式ドキュメントの例は「70%未満が緑、70〜89%が黄、90%以上が赤」を採っている。自分の作業リズムに合わせて調整すればいい。

同じ構成を自分で作るには——Claude Codeへのプロンプト例

私の構成をそのまま作りたい場合は、以下のプロンプトを Claude Code に渡すとスクリプト全体を出力してくれる。{リポジトリ名} の部分だけ書き換えればよい。

以下の要件で Claude Code の statusLine 用 bash スクリプトを書いてください。

設定方法:
  ~/.claude/settings.json の statusLine.command で呼ぶ想定。
  stdin から JSON を受け取り、stdout に表示文字列を出力します。

表示内容（上から）:
1行目: モデル名 + コンテキスト使用率（10幅プログレスバー、60%/80%で緑/黄/赤に色切替）
       + 5時間レートリミット使用率（同形式）
       + 7日間レートリミット使用率（同形式）
       + JST現在時刻（HH:MM）
2行目: GitHub Issue を GTD ラベル別に集計したカウント
       （📥inbox 🎯next ⏳waiting 🌈someday 🔁routine 📁project 📎reference）
       gh issue list で {リポジトリ名} から取得、5分キャッシュあり
3行目: ~/.claude-state/current-task が存在すれば「🎯 {内容}」を表示。
       ファイルがなければこの行は省略
4行目: macOS の Music アプリが再生中なら「♫ {曲名} — {アーティスト}」を表示。
       再生していない・未起動の場合はこの行を省略

要件:
  - jq を使って JSON を解析する
  - rate_limits フィールドは存在しない場合があるので // empty でフォールバック
  - ANSI エスケープコードで色付けする

自分の使い方に合わせて要件を変えれば、カスタム構成のスクリプトを出してくれる。「GTD は使っていないので2行目は不要」「コストを出したい」「Spotify を使っている（Linux）」などの条件を追記してみてほしい。

まとめ——ステータスラインで作る、自分のワークスタイルの可視化

ステータスラインは ~/.claude/settings.json に statusLine ブロックを1つ足すだけで始められる。stdin で渡る JSON を加工して標準出力に書けば、Claude Code 内部の状態も、Git も、外部 API も、別アプリの状態も、シェルで取れる情報は何でも置ける。

私はそこに、GTD のタスク件数（5分キャッシュ）・宣言中の作業タスク・再生中の音楽という、自分のワークスタイルに直結する情報を足した。結果として、タスク状況を確認するためにも、今やるべきことを思い出すためにも、ターミナルを離れなくてよくなった。

そして項目を増やすときの肝は、行ごとに「中身があるときだけ出す」設計にすること。状況に応じて現れて消えるラインは、増やしても普段の見た目を重くしない。まずは定番のモデル名とコンテキストバーから始めて、自分が「ターミナルにいながら見たい情報」を1つずつ足していくのがおすすめだ。

参考リンク

関連記事・書籍

この記事は はてなブログ からのクロスポストです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?