なぜ「書かせる」から「振る」へ移すのか
AI の能力は HumanEval や SWE-bench でほぼ上限まで来ており、「コードを書ける」こと自体はもう前提です。差がつくのは 1 タスクに使うトークン量、トークン当たりコストで、モデル選びだけで約 5 倍、Skill や subagent まで組み合わせると 10 倍規模の差が生まれます。Anthropic 公式ドキュメントも「Sonnet で大半のコーディングは足り、Opus は複雑な設計判断にだけ使う」「Status line で消費を継続的に可視化する」方向を推奨しています。焦点は「実現できるか」から「同じ価値をいくらで届けられるか」へ移ってきました。そしてこれは、エンジニアの仕事自体が「AIに書かせる」から「設計してAIに任せる」へと静かにシフトしていく流れでもあります。
Cost per Task とは — 1 タスクあたりのコスト
「1 タスクを完了させるのにどれだけのコストがかかったか」を測る指標です。式にすると次の形になります。
Cost per Task = 投じたコスト ÷ 完了したタスク数
ここでの「コスト」は主に API のトークン消費を指し、自分の時間も含まれます。「タスク」は自分が「終わった」と認識する単位を意味し、PR や機能追加、調査メモなどが該当します。
同じアウトプットでも、選択によって Cost per Task は数倍ぶれます。代表的な選択肢は３つです。
- モデル選び: 入力単価は Opus : Sonnet : Haiku ≒ 5 : 3 : 1 で、軽い作業を Opus に投げると 5 倍払う計算になる
- Skill 化: progressive disclosure で必要時だけ手順を展開し、複雑なタスクほど削減効果が大きい
- subagent の運用: 1 体ごとに独立 context を持つため、増やしすぎるとトークン消費が数倍に膨らむ
何でも Opus へ丸投げする人と、タスクの重さに合わせてモデル・Skill・subagent を選び分ける人とでは、同じ成果物でも Cost per Task に明らかな差が生まれます。
改善の第一歩は可視化 — 入り口は Status line
Cost per Task を改善する最初の一歩は、いま自分のコストがどう使われているかを可視化することです。Claude Code 周辺には、可視化のための道具が段階的にそろっています。
- on-demand 表示:
/cost/usage(必要なときに自分で呼び出す) - 個人・常時: Status line (画面下部に常時表示される計器盤)
- 個人・深掘り: claude-devtools (ターンごとの内訳を GUI で、subagent の実行ツリーまで展開)
- 個人・履歴: ccusage (過去ログを CLI で集計し、MCP 別 / 日別 / セッション別の内訳を出す)
- チーム・運用: OpenTelemetry (組織全体のトークン使用量を監視基盤へ流す)
この中でまず手を付けるべきは Status line です。Status line 自体は Claude Code に備わる基本機能で、目新しさはありません。しかし AI の Capability が天井に近づき、勝負所が「同じ仕事をいくらで出せるか」に移った今、その存在意義はかえって増しています。常時表示でコンテキストを消費せず、特別なセットアップも要らないため、日常運転の入り口として最も軽量かつ継続的に効きます。
Status line に常時出している 3 つの情報
私は Status line に次の 3 つを並べています。
- 直近ターンの入出力トークン量と tool 内訳 (Edit / Agent / MCP / Skill)
- セッション累計と 5 時間レート枠の残量
- 現在のモデルと effort、ブランチ名
/cost や /usage を能動的に呼び出さなくても、桁感が視界に入り続けるのがポイントです。
可視化で見えてくる 3 つのムダ
眺めていると、次のパターンが浮かび上がってきます。
- 🌿 空セッション開始時点でコンテキストが数十 % 埋まっている (
CLAUDE.mdや MCP 定義の肥大が原因) - 💬 軽い整形タスクに Opus + ultrathink が走り、桁違いのトークンを焼いている
- 🤖 subagent を多用してメインの 7 倍以上のトークンが裏で燃えている
どれも /usage を都度実行しないと見落としがちな、沈黙の劣化です。
仕組み化して永続化する
気づきは設定へ落とし込んで初めて効き続けます。私は次の 4 つを使い分けています。
- Skill: 長文の手順を逃がし、frontmatter でモデルと effort を固定
- Custom subagent: 軽量モデルに固定し、別 context で重い調査を完結
- Hook: subagent 起動を
PreToolUseで止め、暴走に歯止めをかける -
settings.json: 既定モデルや権限、MCP の有効可否を 1 ファイルで底上げ
まとめ — エンジニアの仕事はこう変わっていく
LLM のトークン消費は、事前に正確な値まで予測しきれない性質があります。それでも Status line を視界に置くだけで、「このターンは重い」「Opus のままだ」という体感が積み上がっていきます。積み上がった体感を設定に反映していけば、最適化は仕組みとして残り、状況に応じて育てていけます。
エンジニアの仕事の評価軸も、書いたコード量から「AI が良い仕事をする状態をどれだけ仕組みに焼き付けたか」へ、少しずつ移っていきます。Status line を計器盤として視界に置き、気づきを Skill や settings.json に残していく — その小さなループの積み重ねが、これからのエンジニアの基本動作になっていきます。