タスクの複雑さでモデルを選ぶ ── Thompson Samplingで動かす“トークン/コスト最適化

Claude Code で動くマルチエージェントの個人OSS C3
タスクごとにどのモデルを使うか自体を学習させる というアプローチ

1. タスクの複雑さでモデルを選ぶ Thompson Sampling で動かす“ トークン/ コスト最適化” @satoh_y_0323 ／ 個人OSS C3 (Claude Code Conductor)
2. モデル選び、結局“ 勘” になっていませんか 「簡単そうだから安いモデルでいいか」は 毎回人間が判断 判断基準が 言語化されていない ので引き継げない 「本当にそのモデルで精度は足りていたか」は 検証されないまま トークン節約術 Night - TECH BATON - 2
3. C3 の tier-routing ：3 段階で“ 選ぶ理由” を作る 複雑度を推定 ▶ Thompson Sampling で学習 ▶ 拮抗時は安い方（cost-aware ） 人の勘ではなく、過去の承認/ 否認の実績でモデルを選ぶ トークン節約術 Night - TECH BATON - 3
4. 実際に溜まったデータ（自分のOSS 開発ログ） c3 tier stats で複雑度×Tier 別に 成功率・トークン・実コスト が見える ※個人開発ログの実測値（収集期30 試行を卒業済み・履歴には failure もそのまま残る） トークン節約術 Night - TECH BATON - 4
5. 推奨止まり→ 適用したら、次の問題が見えた これまで 「実行時に変更不可」 と 思い込み 推奨を表示するだけ → 誰も従わない ➜ 検証→ 即実装 呼び出し時の明示指定 で 切り替え可能と判明 その日に適用まで実装 → 推奨が実際に効く ➜ 適用で見えた罠 安いモデルが一度失敗 すると二度と選ばれな い デッドロックが発覚 → 失敗の定義を再設計 トークン節約術 Night - TECH BATON - 5
6. 持ち帰り（ツールが何でも真似できる） モデル選びは 言語化して検証できる状態 にする 「簡単/ 複雑」の判定と「選んだ結果」を 両方記録する（記録は消さず、集計ル ールだけ変える） 失敗に数えるのは 客観的な事象だけ（テスト不合格・スタック） 拮抗したら 安い方を選ぶ、というルールだけでも十分効く 最適化は 適用して初めて次の問題が見える ── 測る→ 適用→ また測る トークン節約術 Night - TECH BATON - 6
7. 今日のひとこと モデル選びを“ 勘” から、 “ 実データに基づく学習” に。 C3 ─ pip install claude-code-conductor ／ @satoh_y_0323 ／ つまずき報告がいちばんあ りがたいです 7