Claude Code の足もとに、18分類の計器盤を。ステータスラインを作りました

導入と検証

ここまでで、ステータスラインの中身をひととおり見てきました。最後のページでは、これを別のパソコンでも同じ形で動かす方法と、正しく動いていることの確かめ方、そして、あえて表示しないと決めたものの話をします。

setup.sh 1本で、再現できるようにする

ステータスラインの本体は、私のリポジトリの中の scripts/statusline/ というフォルダに置いています。けれど、Claude Code が実際に呼び出すのは、ホームフォルダの ~/.claude/ に置いたファイルです。つまり、同じファイルが2か所にあることになります。リポジトリで直したのに ~/.claude の側に写し忘れると、画面は古いまま動き続けます。これもエラーにならない食い違いです。

そこで、写す作業を手でやらず、setup.shという1本のスクリプトにまとめました。

sh scripts/statusline/setup.sh          # 導入（~/.claude へ配置し settings.json を更新）
sh scripts/statusline/setup.sh verify   # 描画テストのみ（導入済みの検証）

setup.sh がすることは4つです。1つ目は退避で、~/.claude にすでに別の statusline.py があり、中身が違っていれば、日付と時刻を付けた名前で残してから上書きします。前の設定を消さないためです。2つ目は配置で、リポジトリの statusline.py と statusline.sh を ~/.claude へ写します。3つ目は設定で、settings.jsonの statusLine の項目に、コマンドの場所を書き込みます。4つ目が描画テストです。

描画テストでは、2種類の入力でスクリプトを実際に動かします。1本目は、空の JSON（{}）です。セッションを始めた直後のように、ほとんど何も届いていない状態を再現して、途中で止まらずに最後まで動くかを確かめます。2本目は、モデル名・使用率・料金などを入れた合成の JSON で、実際に行が表示されるかを確かめます。何も無いときに壊れないことと、全部あるときに正しく出ることの、両端を確かめるわけです。

2ページ目で見たとおり、料金の推計に使う ccusage、PR の状態を調べる gh、曲名を調べる nowplaying-cli は、入っていなくても動くように作ってあります。無ければ、それぞれのチップが出ないだけです。導入の手順から「まずこれを入れてください」という前提を減らしておくと、別のパソコンに持っていったときに、最初の1回で動く見込みが高くなります。

直すときの決まりも1つ決めました。変更はリポジトリの側で行い、必ず setup.sh で ~/.claude へ写すことです。~/.claude のファイルを直接直すと、次に setup.sh を実行したときに、リポジトリの古い中身で上書きされてしまいます。どちらが正本かを決めておき、写す向きを一方通行にしておけば、2か所にある食い違いは起こりません。

点滅のテストは、「点滅しない」側も確かめる

表示の中でいちばん確かめにくいのが、4ページ目で作った点滅です。点滅は時刻で変わるので、1回描画しただけでは、赤い帯の絵が出るか、通常の絵が出るかは、そのときの秒しだいです。「赤い帯が出たから合格」とすると、たまたま奇数の秒に当たっただけかもしれません。

そこで、対照実験の形でテストを組みました。まず、使用率を93%のような危険域に偽装した入力を用意し、数秒おきに何度も描画させます。そして、出力の中に赤い背景の色の命令（\x1b[48;5;196m）がある描画と、無い描画の両方が見つかったら、点滅していると判定します。両方がそろうまで描画を繰り返すので、何秒目に当たったかに左右されません。

もう1つ大事なのが、ふだんの入力でのテストです。使用率42%のような、警告の出ない入力で同じように描画させ、赤い帯の命令が1回も出ないことを確かめます。こちらを確かめないと、「いつでも赤い帯が混ざってしまう」という壊れ方を見逃します。鳴るはずのときに鳴り、鳴らないはずのときに鳴らない。この両方がそろって、はじめて警告のテストになります。

このテストを作るときに、1つ失敗もしました。最初は「描画の時刻が奇数の秒なら赤い帯があるはず」と、秒と結果を対応させて判定していました。ところが、テストの側で時刻を取ってから、スクリプトが描画するまでのあいだに、秒の境目をまたぐことがあります。すると、テストは奇数の秒だと思っているのに、描画は偶数の秒で行われ、正しく動いているのに不合格になります。対応させるのをやめて、「両方の状態が見えるまで繰り返す」判定に変えたのは、このためです。

目で確かめたいときのために、デモの仕掛けも入れてあります。~/.cache/statusline-blink-demo というファイルを作ると、その間だけ、すべてのチップが点滅の対象になります。

touch ~/.cache/statusline-blink-demo    # 全チップ点滅（動作確認）
rm ~/.cache/statusline-blink-demo       # 本番の条件（90%）へ戻す

無いデータは、出さない

最後に、表示しないと決めたものの話をします。冒頭の画面で、⚡ Claude の行には5時間と7日の2つの枠が並んでいたのに、🤖 Codex の行には7日の枠しかありませんでした。Codex にも5時間の枠を出したくなるのが自然ですが、あえて出していません。

理由は、Codex のログに、5時間の枠の値が1件も記録されていなかったからです。2ページ目で見たとおり、🤖 Codex の行は、Codex が手元に残すログから値を読んでいます。5時間の枠が無いことに気づいたとき、まず探し方の誤りを疑いました。そこで、直近30セッション分のログを全部読み、rate_limits の記録1,046件を1件ずつ確かめました。7日の枠（10080分）の記録はありましたが、5時間の枠にあたる記録は、1件もありませんでした。

ここで取れる選択肢は3つありました。1つ目は、5時間の枠を0%と表示すること。けれどそれは、「値が無い」を「まったく使っていない」にすり替えることになります。2つ目は、7日の枠の値などから推測して作ること。これは、根拠の無い数字を、公式の値と同じ顔で画面に置くことです。3つ目が、出さないことです。

確かめたうえで無いと分かった値は、出さない。それが、3つの中でいちばん正直な表示だと考えました。そのうえで、コードは5時間の枠を探す作りのままにしてあります。いつか Codex のログに記録されるようになれば、何も直さなくても、画面に自動で現れます。

ここで気をつけたのは、「探して0件だった」ことと、「探していない」ことを混ぜないことです。最初に5時間の枠が見当たらなかったときに、それだけで「無い」と決めていたら、単に探し方が悪かっただけかもしれません。全部を読んだうえでの0件だから、無いと言える。この区別は、1ページ目で書いた「データが無い分類は行ごと消す」の、もう一段深い意味でもあります。消してよいのは、無いと確かめたときだけです。

ちなみに、ほかにも見送ったものがあります。英語圏で公開されているステータスラインの道具には、天気やスポーツの結果、ポモドーロのタイマー、画面の中で育つペットまで表示できるものもありました。見ていて楽しいのですが、この計器盤では採用していません。1ページ目で決めた「見たあとの行動が変わる数字だけ」という方針に照らすと、どれも運転中の計器ではなかったからです。

自分の計器を足すには

ここまで読んで、「自分なら、この数字も出したい」と思ったものがあるかもしれません。最後に、この計器盤へ新しいチップを足すときの手順を書いておきます。私自身も、この手順で1つずつ足してきました。

手順4の確かめは、次のように、幅を変えて同じ入力を何度か描画させるだけです。直前の描画で届いた JSON が手元に残っているので、それを入力に使えば、本物に近い状態で試せます。

for c in 60 87 130; do
  COLUMNS=$c python3 ~/.claude/statusline.py \
    < ~/.cache/claude-statusline-last-input.json | head -20
done

足したいチップが比率なら、3ページ目の「分母が育つまで出さない」条件を、はじめから一緒に決めておくことをおすすめします。そして、そのチップを見たあと、自分の行動が変わるかどうかを、一度考えてみてください。変わらないなら、その数字は計器ではなく飾りかもしれません。足すのは簡単で、減らすのは難しい。1ページ目で決めた方針は、ここで効いてきます。

参考にしたもの

この計器盤は、ゼロから考えたものではありません。Zenn・Qiita・note に公開されている日本語の記事17本と、英語圏で公開されているステータスラインの道具、そして Claude Code の公式ドキュメントを読み比べて、よいと思った考え方を取り入れています。とくに影響を受けたものを挙げておきます。

ステータスラインのしくみと標準入力の項目は、Claude Code の公式ドキュメントStatus line configurationで確かめられます。料金の推計にはccusageを、障害情報には Anthropic の状態ページが公開している API を使っています。

まとめ

今回は、Claude Code の入力欄の下に、18の分類を並べたステータスラインを作った話をしました。しくみ自体は、標準入力で JSON を受け取り、文字を print するだけの単純なものです。けれど、その単純なしくみの上で、数字を正しく集め、行動の言葉に翻訳し、欠けずに並べ、正直に表示するには、思った以上にたくさんの判断が必要でした。

振り返ると、この記事で出会った困りごとは、どれもエラーにならずに起きていたことに気づきます。右端のチップは黙って消え、絵文字は黙って隣の文字を踏み、点滅は黙って止まり、比率は黙って1万を超えました。どれも、プログラムとしては正しく動いていて、画面を見た人が「何かおかしい」と感じてはじめて見つかったものです。

だからこそ、この計器盤では、確かめ方をできるだけ仕組みにしました。幅は推測せずに測る。キャッシュは覚えるものまで決める。比率には資格の条件を付ける。点滅は、鳴る側と鳴らない側の両方をテストする。画面の数字を信じてよい理由を、1つずつ積み上げていく。それが、ステータスラインという小さな場所で学んだ、いちばん大きなことだったと思います。

冒頭の画面に戻ると、あの朝の計器盤は「Codex はもう使えない、Claude の7日枠もこのペースでは今日のうちに尽きる」と教えてくれていました。数字を読んだあと、何をするかを決めるのは人です。けれど、その判断に必要な材料が、視線を少し落とすだけで、正しくそろっている。そういう道具があると、長い作業がずいぶん落ち着いて進められます。あなたの画面の下にも、自分の判断に効く計器を、1つずつ足してみてはいかがでしょうか。

プロマリでは、Webサイトの制作に加えて、開発の現場で使う道具や、それを運用できる人材の育成にも取り組んでいます。AI のコーディング支援ツールをチームで使いこなす環境づくりに興味のある方も、お気軽にご相談ください。

Web制作・開発環境・人材育成のご相談はこちら ↗