クラウド / システム
コーディングエージェントが働いていると、ターミナルはたいていにぎやかです。コマンドが流れ、ファイルが変わり、メッセージが届きます。でも知りたいのは、もっと小さなことだったりします。今のモデルは何か。コンテキストはどれくらい埋まったか。このセッションで合っているか。そして、いくらかかっているのか。
スピナーが答えてくれるのは、別のこと
以前のETAの記事では、自分の時間をどう使うかを考えました。待つか、別のことをするか、後で戻るか。ステータスラインは、同じ問題の別の部分を扱います。次に何をするか決める前に、目の前のセッションを把握したいのです。
スピナーは何かが動いていることを、長いログは何が起きたかを教えてくれます。でも、どちらも欲しい情報を一目で伝えてくれるとは限りません。
ステータスラインで見えるもの
掲載したターミナル画面を見ると、イメージしやすいと思います。選択した経路、実際のモデル、コンテキスト使用量、費用の推定値を1行にまとめています。プロジェクトやアカウントの識別情報は架空の例に置き換えました。
経路のラベルと、その先で選ばれたモデルは別の情報です。この画面ではOpenRouterを経由し、OpenAIのモデルを使っています。拡張した構成の例であり、Claude Codeの標準UIを説明するものではありません。
コンテキストは1,000,000トークン中186,551、19.0%と表示されています。抽象的な容量を読み取りやすくできます。ただし19%使ったからといって、仕事が19%終わったわけではありません。残り何分かも、それだけではわかりません。
費用の欄は、推定値またはプロバイダー固有のカウンターです。それぞれ定義が必要で、ステータスラインの数字を確定した請求額とは考えません。この構成にある予測や自動モードも、ここで扱う最小限の表示スクリプトとは別の機能です。
費用の把握も、同じ1行に
費用を見えるようにすることは、ステータスラインを加える大きな理由のひとつです。エージェントが動き続ける間に、試行、再試行、並列セッションをどれだけ始めたか、わからなくなることがあります。請求を見る前に気付きたいところです。
画像の「est. $6.61」と「OR today $9.31」は、違う意味のカウンターです。単純に足してはいけません。何を集計し、どの料金情報を使い、いつ更新するのかを確認する必要があります。推定値は判断の助けに、実際の請求はプロバイダーの利用記録で確認します。
私なら、次のように使います。
- 作業前に、費用を見直す目安を決める。 思いがけない請求を待つのではなく、どこで止めて追加実行を見直すか決める。
- 費用の増え方と、得られた成果を比べる。 同じテストに失敗し続けるのに金額だけ増えるなら、また広く試させる前に、タスクを絞るか障害の原因を調べます。
- 次の一手を意識して選ぶ。 小さな追加作業、適したモデル、手動の確認で足りるかもしれません。モデルを変えても、同じ品質チェックは必要です。
見えるカウンターは、自動の予算上限ではありません。リクエストも止めません。API課金、サブスクリプション、プロバイダーごとの残高も分けて考える必要があります。時間や技術的な品質と同じように、費用も意識して判断したいのです。
パーセントを、次の判断につなげる
コンテキスト使用量が増えてきたら、作業の連続性を考えるきっかけになります。次の手順は明確か。重要な判断を残してあるか。次へ進む前に、短い引き継ぎを作るとよいか。
何%になったらセッションが悪くなる、という共通の基準はありません。範囲の絞れた小さなタスクと、広がり続ける調査では事情が違います。数値を目安にしつつ、作業そのものを確認します。
コンテキストのメーターだけでは、許可や判断が必要かどうかもわかりません。そこには明示的な注意のシグナルが必要で、このシリーズの別のテーマです。
「不明」も、役に立つ答え
欠けた情報を、安心できそうな数値に黙って変える表示は困ります。取得できない項目は、そのまま取得できないと伝えてほしいのです。
画像には値のある項目が表示されています。値がないなら、緑のゼロより、はっきり「取得できません」と出す方がよいと思います。表示が裏付けられない精密さを装わず、何が不明なのかを教えてくれます。
中身を確かめ、取り外せる小ささに
Claude Codeには、ローカルコマンドでセッションのJSONを読み、表示を出力するステータスラインの設定機能があります。公式資料にはモデルやコンテキストの項目が載っています。別のダッシュボードを増やさずに始められます。
最小構成ならモデルとコンテキストから始め、費用は情報源と集計範囲が明らかなときだけ加えます。渡された項目を表示し、リポジトリの走査、ネットワーク照会、会話の保存はしません。これはこのサンプルの設計方針で、すべての拡張機能に当てはまる保証ではありません。
有効にする前に、既知の入力を与えて試し、値がないときは「ない」とわかる表示になるか確認します。大事なのは数字の多さではなく、意味のわかるシグナルです。
頭の中で覚えておくことを減らしたい
ステータスラインでエージェントの推論力が上がるわけでも、変更のレビューが不要になるわけでもありません。覚えたり調べ直したりする情報に、小さくて決まった置き場所を作れるのが利点です。
エージェント用ツールに期待するのは、こうした方向です。基本的な状況確認のための中断を減らし、人にしかできない判断に注意を残したいと思います。
あなたなら、コーディング中の画面の下に、どんな情報を1行だけ置きますか？
参考資料
Claude Codeのステータスライン公式ドキュメント（2026年10月27日確認）。