ここにいる多くの方と同じで、何か少しでも本格的なものを作ろうとすると、Claudeの使用量制限にぶつかり続けていました。

私は求人検索の自動化パイプライン（Career-Opsプロジェクトに基づく）で作業していて、素朴なフローだと申請1件あたり約16kトークンを消費していました——完全に持続不可能でした。

そこで、トークン効率を第一級の関心事として、後回しにせず組み直すのに少し時間を使いました。

結果

• トークン使用量を約85%削減
• 申請1件あたり約900トークン
• 最も繰り返されるコンテキスト呼び出しをほぼ排除
• 使用量制限に対してずっと安定

⚡ 実際に役立ったこと（実践的な学び）

1. プロンプトキャッシュ（最大の勝ち筋）

• キャッシュしたシステム＋プロファイルのコンテキスト（cache_control: ephemeral）
• 2回の呼び出しで損益分岐点、その後は大きな伸び
• 繰り返し操作で約40%削減

同じコンテキストを毎回送っているなら、トークンを浪費しています。

2. デフォルトでSonnet/Opusにせず、モデルルーティングする

• 軽量タスク → Haiku
• 中程度の推論 → Sonnet
• 重いタスクのみ → Opus

ほとんどの手順には高価なモデルは不要です。

3. 再利用できるものは前計算する

• 1回の呼び出しで回答バンク（標準応答25個）を作成
• 複数の申請で再利用

フォーム入力の間にLLM呼び出しを約94%削減しました。

4. 重複作業を避ける

• TF-IDFのセマンティック重複排除（閾値0.82）
• 評価の前に重複する求人掲載をフィルタ

同じ内容に対して繰り返しトークンを燃やすのを防ぎます。

5. 「過剰なインテリジェンス」を減らす

• 重い推論の前に軽量な分類器ステップを追加
• 必要なときだけ、より深いモデルにエスカレーション

すべてがLLMのフル推論を必要とするわけではありません。

重要な洞察

ほとんどのClaudeワークフローが制限に当たるのは、それが複雑だからではありません——
しかし、毎回すべてを作り直しているからです。

他の人のセットアップが気になります

• 繰り返しコンテキストはどう扱っていますか？
• 複数ステップのパイプラインでキャッシュを積極的に使っている人はいますか？
• Haiku vs Sonnet vs Opus のバランスを取る良いパターンはありますか？

https://github.com/maddykws/jubilant-waddle

サンティアゴ・フェルナンデスのCareer-Opsに着想を得ています。これは、効率と使用量制限下でのスケーリングに焦点を当てたフォークです。