5 ポイント 投稿者 sleeplesshan 7 시간 전 | 2件のコメント | WhatsAppで共有

こんにちは。

普段、Claude Code や Codex のようなAIエージェントを使って大容量ログを分析したり、レガシーコードを修正したりする際、あっという間に膨らむトークンコストや待ち時間に悩んでいた方に向けて、私が作ったスキルを共有します。

大容量ファイルを扱うときに、**"探索はローカルで無料、推論はクラウドで高性能に"**処理するハイブリッドコンテキストルーター token-router です。


🛑 どんな問題を解決しますか?

2,000行を超えるインフラ配備ログや巨大なソースコードファイルを、そのままクラウドLLMに投入すると、入力トークンが大量に無駄になり、待ち時間も長くなります。

これを節約するために小型モデルでコードを事前要約することもありますが、この方法は危険です。エラー1行や変数定義が抜け落ちた瞬間、クラウドAIが文脈を見失い、とんちんかんな誤答を出してしまうからです。

さらに最新バージョンでは、毎ターン繰り返し付与される長い CLAUDE.mdAGENTS.md.cursorrules のような静的エージェント指示ファイルも、ルーティング対象に拡張しました。ただし、すでに自動注入された長い root ファイルのトークンコストを事後的に減らすことはできないため、root 指示ファイルは短く保ち、長い作業別ルールは別の reference ファイルに分離して、必要なときだけルーティングする構成を推奨します。


🧠 どう解決しますか?(ユーザー視点の動作方式)

このツールはテキストを要約せず、あくまで原文を必要な分だけ切り出す方式を使います。

  1. ローカル探索 (Local Triage): 自分のコンピュータ上で Ollama を通じて軽量な Gemma 4 2B モデルを動かします。このローカルモデルは、ユーザーの質問に合った正確な行番号(座標)だけを素早く見つけます。
  2. 原文抽出 (Raw Slicing): Pythonスクリプトがその行番号をもとに、ディスク上の原文そのままのクリーンなテキスト断片を切り出します。
  3. クラウド推論 (Reasoning): メインのクラウドモデルは、不要なノイズが除去された高密度の原文断片とファイル構造マップだけを受け取り、デバッグとコード作成に集中します。

未加工の原文をそのまま渡すため、クラウドモデルの推論能力を100%活かしつつ、コストだけを大幅に削減できます。

現在は error_logheavy_codeagent_context の3つのモードをサポートしています。agent_context は、長い CLAUDE.mdAGENTS.mdGEMINI.md.cursorrulesagent-context/*.md のようなエージェント指示の参照ドキュメントから、現在の作業に関係する原文行だけを探してくるモードです。


📊 実際に私のPCでテストした結果

  • 大容量インフラログ (2,000行): 入力コンテキストを41,711トークンから 131トークンに削減99.69%節約、処理時間 5.37秒)。
  • レガシーバグのソースコード (2,155行): 元の7,520トークン分を わずか70トークンに圧縮して送信(99.06%節約、処理時間 4.46秒)。

🛠️ 実務で使って便利だった点

  • PCのもたつきを防止: ローカルAIを使うとコンピュータが遅くなるのではと心配になるかもしれませんが、このツールはルーティング座標の抽出が終わったその瞬間に、ローカルモデルをVRAMメモリから即座に解放します。
  • 賢い逆方向コンテキスト拡張: 切り出したコードが狭すぎて前後の依存関係を把握しにくい場合、クラウドAIが適当に答えず、スクリプトに「より広い範囲をもう一度切り出してこい」と逆リクエストするプロンプトの安全装置を組み込んでいます。
  • 大容量ファイルのストリーミング: ファイルが大きすぎてローカルモデルのメモリ容量を超えても、バックエンドでキーワードとファイル末尾を先にスキャンするストリーミングロジックが自動で動作するため安全です。
  • Claude Code対応: 最新バージョンには Claude Code 用の compact CLAUDE.md bootstrap も含めました。長い Claude 専用指示は別の reference ファイルに置き、agent_context でルーティングする形で使えます。

MITライセンスで全面的に無料公開されており、スタンドアロンのスクリプトとしても、OpenAI Codex のスキル形式としても、そのまま登録して使えます。Claude Code でも CLAUDE.md bootstrap を参考にして、同じルータースクリプトを呼び出せます。大容量ログのデバッグや重いコードを頻繁に扱う方の開発生産性向上に役立てばうれしいです。

アーキテクチャやプロンプト最適化について、さまざまなフィードバックやご意見をいただけるとありがたいです!

2件のコメント

 
hshim 6 시간 전

良いスキルですね。軽く使ってみました。
Pythonで投げるJSONを生成する際、JSONの文法を破ってエラーになるケースがたまに発生したため、4bやqwen2.5-coder:7bに変更して使ってみたところ、エラー率が大幅に下がりました。

 
sleeplesshan 6 시간 전

おお、投稿してすぐにテストしてくださり、しかもモデルのサイズ別に具体的な比較フィードバックまで残していただいて本当にありがとうございます!
おっしゃる通り、2B級の超小型モデルは、複雑なログや特殊文字が混ざる環境では、ときどきシステムプロンプトの制約を破って文法に違反したJSONを出力してしまう限界があるようです。VRAMリソースに余裕があるなら、やはりQwen 2.5 Coder 7BやGemma 4B系のほうが、ルーティング座標をずっと安定して出してくれるようです。
もしほかの方もテスト中にJSONの文法エラーを経験されたら、環境変数の設定を通じて次のように、より大きなモデルへ変更して実行してみると、活用の助けになると思います。
OLLAMA_MODEL=qwen2.5-coder:7b python3 scripts/router.py ...
貴重な実運用ベンチマークのご意見を共有してくださり、ありがとうございます。