ぼくは Claude Pro を契約しており、月ごとのトークン上限の中でやり繰りしています。常時 opus を使い続けるとすぐに枯渇します。お金で制限を引き上げるブルジョワジーではないので、設計の工夫で解決することにしました。BPR（Business Process Re-engineering）の「なくす→まとめる→標準化する→役割分担を見直す」の発想で9施策を試した記録です。
opusをぶん回し続ける体力はない#
Claude Code 上に記事制作ワークフロー（以下、AI 編集部）を組んでいます。サブエージェントやスキルが増えるほどトークン消費は積み上がり、月の使用量が無視できない水準になってきました。
コスト問題を直視したきっかけ#
AI 編集部のコアな判断（記事構成・言い回しの選択）は opus に任せたい派です。ただ、すべてのステップに opus を当てると月の上限があっという間に溶けます。
正直に言うと、最初は「困ったら opus に投げれば良い」で運用していました。これが甘えた解釈でした。サブエージェントが増え、スキルが増え、入力ファイルが分厚くなるにつれ、1記事あたりのトークン消費が無視できない水準に積み上がっていったからです。
そこで方針を切り替えました。常時 opus 前提をやめ、「opus を使うべき場所」と「そうでない場所」を仕分ける構造に組み直す。中身が雑なままマシンパワーで殴るのではなく、中身の設計でトークンを節約する側に倒すと決めたわけです。
まず計測した：振り返り分析フレームの設計#
何から手をつけるかを決めるために、まず計測の仕組みを作りました。1セッションで1つの仕事をこなした後、振り返りとして以下を出させるフレームです。
- セッション本体とサブエージェントを含む、全フロー・全ステップで消費したトークン量を集計する
- 「無駄に消費されている」と思われる箇所について、直接原因と真因を特定する
- 対策案を出す。ただしすぐには実装せず、効果とリスクのバランスで判断する
- 実装する場合は、処理間の依存関係・技術的依存関係を明らかにし、実装計画を起こしてレビューする
- 実装は必ずドライランを行い、動作確認をする。バグが出たらその都度修正する
整理すると、「計測→真因特定→対策案→計画レビュー→ドライラン」の5段階です。やってみてわかったのは、「気になる箇所」と「実際に消費しているステップ」が一致しないことが多いということ。体感では重そうに見えても集計するとたいしたことなく、逆に地味なステップが地味に積み上がってトップを取る、ということが普通に起きます。
このフレームを通したからこそ、以降の施策が「効果がありそう」ではなく「数字で効いた／効かなかった」で語れるようになりました。
なくす#
BPR の基礎では「なくす」が最初に来ます。やらない作業は一切コストを生まないからです。AI 編集部に当てはめてみると、ここが最も効くカテゴリでした。
機能していないステップを外す（効果◎）#
プロセス設計時に組み込んだステップが、実質的に意味をなしていないことがあります。「念のため」「あった方がきれいだから」で入れたステップは、運用しているうちに惰性で残っていくのです。
ぼくも AI 編集部のサブエージェントに「最終チェック」「整合性レビュー」みたいなステップを律儀に挟んでいました。集計してみると、これらが想定外に消費していて、しかも出力はほぼ「問題なし」。実質的な品質寄与がほとんどないのに、毎回コンテキスト全読み込みで動いているわけです。
定期レビューを入れて、機能していないステップは思い切って外す。これだけでまとまったトークンが浮きました。「やめる」が最強なのは BPR の世界と同じです。
無限ループの出口条件を明示する（効果◎）#
各ステップの終了条件を明示していないと、解釈次第で無限ループに入ります。たとえば「品質が十分になるまで修正する」と書いてあると、LLM の側で「もう少し直せる」と判断し続けてしまう。
ぼくもやらかして、ひとつのレビューサブエージェントが10往復以上修正を続けていたことがあります。出力を見ると後半はほぼ揺り戻しで、「直してまた戻して」を繰り返していました。これはトークンが溶ける典型例です。
対策としては、ループになりうる箇所を特定し、「3回まで」「これ以上は人間に投げる」のような出口条件を明記します。完璧主義を諦めて、ループから抜ける条件を先に決めておく方が安く済みます。
品質基準に「あきらめ」を組み込む（効果◎）#
各ステップの終了条件（品質基準）で、理想を押し付けないことも効きました。ちょっとした人間の判断、特に「妥協する」「あきらめる」で済むなら、そちらに流す方が圧倒的に安いのです。
たとえば「タイトル案を3つ出して、最良のものを1つに絞る」というタスク。AI に最終判断までさせると、評価軸を組み立てて比較して、と長い思考プロセスを踏みます。ところが「3つ出して人間に渡す」で止めれば、コストは大幅に下がります。最後の1択は人間が30秒で決められます。
ポイントは、AI が苦手な「えいやで決める」を人間に戻すことです。AI の品質追求は連続的なトークン消費ですが、人間の判断は離散的（やるかやらないか）で済む。この差を活かす設計が、結果として一番効きました。
まとめる・標準化する#
「なくす」の次に手を入れたのが「まとめる」と「標準化する」のカテゴリです。こちらは BPR 基礎の想定通り、それなりに効きました。
「読む→修正→また全部読む」をバッチ化する（効果○）#
情報の再読はトークンの無駄です。「情報を全部読んで → 何かを修正 → さらに情報を全部再読 → また修正」という順次処理は、毎回コンテキストにファイル全文を載せ直すので、消費が階段状に積み上がります。
そこで、一括読み込み→一括修正→一括確認のバッチ処理に組み替えました。修正対象が複数ある場合は、最初に全部の差分を組み立ててから一気に適用します。再読を1回に圧縮するだけで、思った以上にトークンが減ります。
これは LLM の使い方というより、データベースの N+1 問題に近い話です。ループの中で毎回フェッチするのをやめて、まとめて1回にする。発想自体は古典的で、AI 編集部のような新しい仕組みでも同じ罠にハマるのが面白いところでした。
似た機能を共通化し、スクリプト・スキル・エージェントに昇格させる（効果○）#
複数のサブエージェントやスキルに、似たような機能が散らばっていました。「ファイル一覧を出す」「タイトルを正規化する」「フロントマターを組み立てる」など、再利用できる断片です。
これをまとめて部品化していきました。昇格先の選び方は「どこまで曖昧さを扱うか」で決めています。
- スクリプト化 入出力が完全に定義できる処理。曖昧さゼロ
- スキル化 手順は決まっているが、入力に揺らぎがある処理
- サブエージェント化 タスク全体を任せる必要があり、判断が連続する処理
スクリプトに落とせるものはスクリプトにします。これだけでサブエージェントの仕事が減り、トークン消費も下がります。
切り出しのタイミングは、複数の箇所に散らばっている似た処理を統合する機会でもあります。共通化できるものはまとめる。ただし、統合によって依存関係が複雑になりやすい部分は無理にまとめず、独立した部品として並べておく方がリスクが低いです。
マークダウン内コードブロックをスクリプトに外出しする（効果△、ただしやらない理由はない）#
サブエージェントやスキルのマークダウンの中に、スクリプトが直書きされているケースがありました。これを引数付きのスクリプトに切り出すと、マークダウン全体が短くなり、トークン消費が減ります。
ただし効果は△です。1ファイルあたりの削減は数百〜数千トークン程度で、劇的な改善にはなりません。一方で、やらない理由もないのです。コードはバージョン管理しやすくなるし、テストも書けるようになるし、再利用も効く。ついでにトークンも減る、というくらいの位置づけです。
「効果は地味だがやって損はない」系の施策は、片手間にコツコツ進めるのが正解だと思っています。
役割分担を見直す#
最後のカテゴリは、Claude Code の中で全部やろうとせず、外部リソースや別モデルに振り分けるアプローチです。これも効果が大きいものとそうでないものがありました。
Web検索はGeminiの無料枠に外注する（効果◎）#
Web に情報を取りに行く系は、Claude Code でやると意外と高くつきます。ちょっとした検索や、概要レベルの WebFetch なら、Gemini API の無料枠を使った方が無駄がありません。
ぼくは記事の競合リサーチや一次情報の収集を、Gemini 側にスキルとして切り出しました。Claude Code 側は「Gemini に投げて、結果ファイルを読む」だけです。リサーチ系のトークンが Claude Code の集計から消えるので、効果はかなり大きいです。
ただしレートリミットには注意が必要です。無料枠なので、連続で叩くとすぐ詰まる。バッチで1日数回回すくらいのペースが現実的でした。
タスクの難度でopus / sonnet / haikuを使い分ける（効果◎）#
サブエージェントが扱うタスクや与えるトピックの複雑さに応じて、モデルを切り替えています。ざっくりの目安はこうです。
- opus 考える系・難しい系。記事構成の判断、編集方針の決定、複雑なレビュー
- sonnet 困ったらこれ。判断が必要だが opus ほど深さがいらない処理
- haiku 単純作業に近いが、スクリプト化できない処理。簡単な要約・分類・整形
「とりあえず opus」をやめて、タスクの難度で仕分けるだけで月のコストは大きく変わりました。ポイントは、サブエージェント単位でモデルを固定するのではなく、タスク単位で見ること。ひとつのサブエージェントの中でも、考える部分は opus、整形は haiku、というように分割できる場合があります。
インプットをGitHub経由にする（効果△、ただしやらない理由はない）#
記事の元ネタを音声入力でインプットしたり、Deep Research の結果を読み込ませたりするとき、Claude Code のチャットにそのまま貼り付けると損をします。チャット経由で入力してファイル保存までやらせると、インプット（チャットに載せた長文）とアウトプット（ファイルに書き出した内容）の両方でトークンを消費するからです。
そこで、GitHub 上にインプットファイルを先に作り、Claude Code には「このパスを読んで」とだけ指示する形に切り替えました。これでインプット側のトークンが消えます。
スマホで作業していると、つい全部チャットに貼りたくなります。そこを意識的に GitHub 経由にする。チャット欄に入力用ファイルへのリンクを出させて、一発で飛べるようにするなど工夫すれば、使い勝手も悪くありません。効果は△（チリツモ系）ですが、やらない理由はない施策の代表例です。
結果と現在地——モデル更新で最適解が書き換わる#
9施策を入れた現在、AI 編集部のトークン消費は大幅に減りました。ネタ出し・戦略・企画・調査・執筆・編集・品質チェック・価値観適合性レビューまで含む「1記事を回す」全フローで、以前は利用上限の70%程度を使っていたのが、今は20〜30%で済んでいます。一番貢献したのは「なくす」系の3つで、BPR の原則通りの結果でした。
ただ、ここで終わらないのが LLM のつらいところです。モデルが更新されると、最適化の前提自体が書き換わります。今まさに直面しているのがこれです。
opus 4.7が変えたこと：指示レベルが「手順書」から「完了基準＋禁止事項」へ#
opus 4.7 になってから、opus への指示レベル感が明らかに上がりました。
それまでは「指示書レベル」のプロンプトが必要でした。実現手順を細かく書いて、ステップごとの判断基準を明示して、という具合に「手順書としてのプロンプト」を書いていたわけです。これが opus 4.7 では、「品質基準レベル」（完了基準としてのゴール）や「禁止事項レベル」（やってはいけないことのハーネス）に変わっています。
ぼくから見ると、これは「指示の階層が一段上がった」という感覚です。What と How を書いていたのが、Why と Goal を書くだけで動くようになりました。
問題は、これまで前者を前提にサブエージェントもスキルも書いていたことです。opus 4.7 が必要な一部の複雑なタスクでは、書き直しが必要かもしれません。手順を細かく書きすぎているプロンプトは、新しい opus にとっては逆に窮屈で、思考の自由度を奪っている可能性があります。
最適化の方法自体をチューニングし続ける必要がある#
ただ、すべてを書き直すのが正解とも限りません。別案として、sonnet を使うか、thinking effort の調整で済ませられるかもしれない。ここはまだ改善の余地があるし、検証中です。
書いていたら気づいたのですが、業務の設計・改革（BPR）とソースコードのリファクタリングが悪魔合体した感じになってきました。「やめる、まとめる、分担を見直す、標準化する、自動化する」的な思考を、LLM のコンテキストウィンドウや使えるトークン総量という制約の中で、最適化問題として解いている感覚です。
そもそも BPR とリファクタリングは、制約の中で最大効果を出すために工夫を凝らすという意味でよく似ています。同じ思考回路を使っているのかもしれません（このあたりの「効率化のやりすぎライン」については別記事にも書きました）。
こうなると、こういうやり方自体をサブエージェントに渡して、モデル更新のたびにチューニングさせるのが良いのかもしれない、と最近は思っています。BPR やリファクタリングの基礎技法そのものは、モデルが変わってもそう簡単には変わらないはずだから、フレームワークだけ渡しておけば自走できるのではないか、というアイデアです。
まとめ：制約の中で最大効果を出す、というBPRとリファクタリングの共通言語#
AI 編集部のトークン効率改善で9施策を試した結果、一番効いたのは「なくす」系でした。標準化や自動化より、まずは要らないステップを外し、無限ループの出口を決め、品質基準にあきらめを組み込む。BPR の「やめる」が最強という基礎則は、AI ワークフローでも生きていました。
そして、最適解はモデル更新で書き換わります。opus 4.7 のように指示レベルの粒度が変わると、それまでチューニングしたプロンプトが過剰設計になることがある。だから「効率化の方法そのもの」を、フレームワークとしてサブエージェントに持たせる方向に動いています。
業務設計の BPR とコードのリファクタリングは、制約の中で最大効果を出すという意味でよく似ています。AI ワークフローのトークン最適化は、その2つの悪魔合体です。次にモデルが更新されたとき、ぼくはまたフレームを引っ張り出して仕分け直すことになるでしょう。それでも、フレームがあるかないかで、書き直しの速度はまるで違うはずです。制約があるから工夫が生まれる、という話は「仕事を3倍速く」のエピソードとも地続きだと思っています。
