$ man context-wiki/multi-model-optimization
インフラストラクチャadvanced
マルチモデルAI最適化
ビルド時の静的データを活用して4つのAIモデルを1日1ドル未満で運用する方法
単一モデルの問題
ほとんどの人は一つのAIモデルをすべてに使います。それは額縁を掛けるのに大ハンマーを使うようなものです。使えますが、過剰に支払い、過剰に構築しています。私は Claude Opus で毎日104回のcron APIコールを実行していました。出力価格は $75/100万トークン。WhatsApp の自己チャットループがカスケード返信を生成していました。請求額は1日50ドル。ローカルの14Bモデルで処理できる作業に対してです。解決策はAIの使用をやめることではなく、一つの質問に基づいて各タスクを適切なモデルにルーティングすることでした:人間がその出力を読むのか?
パターン
4モデル体制
1. Ollama / Qwen 2.5 14B(無料、ローカル)
Mac Mini M4 Pro で実行。すべての反復的なcronタスクを処理:コミット追跡、RSSモニタリング、ダッシュボードデータ生成、ステータスレポート。これらのタスクは1日4回以上実行されます。Opus の価格では、96回のAPIコールが構造化データ抽出に本物のお金を燃やしていたことになりますが、14Bモデルで十分に処理できます。M4 Pro と24GBメモリで約9GB VRAMで動作します。
2. Claude Sonnet 4($15/100万出力トークン)
すべての会話、オーケストレーション、エージェント連携。これがメインエージェントです。チャット、WhatsApp、Discord、メモリ管理。Sonnet は Opus より5倍安いですが、会話処理は同等です。品質の差が出るのは長文コンテンツ制作のみです。
3. Claude Opus 4($75/100万出力トークン)
コンテンツ制作専用。ブログ記事、Substack のエッセイ、LinkedIn の下書き、深い分析。コンテンツ制作はモデルの品質が出力の品質に直接影響する領域です。2000語のエッセイではその差を感じられます。コミットの要約では?差はゼロです。
4. Claude Code / Opus 4.6(無料、Max サブスクリプション)
インフラストラクチャ層。デバッグ、デプロイ、Git操作、アーキテクチャの判断、他のモデルの出力に対する品質レビュー。サブスクリプションで無制限に使用可能。トークン単位の課金なし。重い作業を行う場所です。
Mac Mini M4 Pro で実行。すべての反復的なcronタスクを処理:コミット追跡、RSSモニタリング、ダッシュボードデータ生成、ステータスレポート。これらのタスクは1日4回以上実行されます。Opus の価格では、96回のAPIコールが構造化データ抽出に本物のお金を燃やしていたことになりますが、14Bモデルで十分に処理できます。M4 Pro と24GBメモリで約9GB VRAMで動作します。
2. Claude Sonnet 4($15/100万出力トークン)
すべての会話、オーケストレーション、エージェント連携。これがメインエージェントです。チャット、WhatsApp、Discord、メモリ管理。Sonnet は Opus より5倍安いですが、会話処理は同等です。品質の差が出るのは長文コンテンツ制作のみです。
3. Claude Opus 4($75/100万出力トークン)
コンテンツ制作専用。ブログ記事、Substack のエッセイ、LinkedIn の下書き、深い分析。コンテンツ制作はモデルの品質が出力の品質に直接影響する領域です。2000語のエッセイではその差を感じられます。コミットの要約では?差はゼロです。
4. Claude Code / Opus 4.6(無料、Max サブスクリプション)
インフラストラクチャ層。デバッグ、デプロイ、Git操作、アーキテクチャの判断、他のモデルの出力に対する品質レビュー。サブスクリプションで無制限に使用可能。トークン単位の課金なし。重い作業を行う場所です。
フォーミュラ
判断フレームワーク
モデルを決める質問は一つ:出力の品質は人間の読者にとって重要か?
cronジョブ(追跡、モニタリング、更新) -> Ollama ローカル。頻繁に実行、出力は構造化データ、品質は重要ではない。
会話、ルーティング、メモリ -> Sonnet。リアルタイムのやり取りに十分、Opus より5倍安い。
ブログ記事、エッセイ、コンテンツ -> Opus。品質が製品であり、人間が読む。
インフラストラクチャ、デバッグ、デプロイ -> Claude Code。サブスクリプションで無料、完全なコードベースコンテキストが必要。
人間が出力を読まないなら、動作する最も安いモデルを使う。人間が出力を読むなら、予算内で最も良いモデルを使う。インフラに関わるなら、Claude Code を使う。
cronジョブ(追跡、モニタリング、更新) -> Ollama ローカル。頻繁に実行、出力は構造化データ、品質は重要ではない。
会話、ルーティング、メモリ -> Sonnet。リアルタイムのやり取りに十分、Opus より5倍安い。
ブログ記事、エッセイ、コンテンツ -> Opus。品質が製品であり、人間が読む。
インフラストラクチャ、デバッグ、デプロイ -> Claude Code。サブスクリプションで無料、完全なコードベースコンテキストが必要。
人間が出力を読まないなら、動作する最も安いモデルを使う。人間が出力を読むなら、予算内で最も良いモデルを使う。インフラに関わるなら、Claude Code を使う。
パターン
ビルド時の静的JSONパターン
これが Vercel でダッシュボードを動作させる重要なアーキテクチャパターンです。問題:
解決策:ビルド時に静的JSONを生成する。JSONをコミットする。Vercel がそれを配信する。
ジェネレータースクリプトがすべてのローカルデータソース(Markdownファイル、cronジョブ設定、Gitログ)を読み取り、構造化JSONを
5つのJSONファイルでダッシュボード全体をカバーします:
~/.openclaw/workspace/HEARTBEAT.md のようなローカルファイルを読んだり execSync("git log") を実行するAPIルートは、ローカルでは完璧に動作しますが、Vercel では完全に壊れます。ビルドサーバーはあなたのラップトップのファイルシステムにアクセスできません。解決策:ビルド時に静的JSONを生成する。JSONをコミットする。Vercel がそれを配信する。
ジェネレータースクリプトがすべてのローカルデータソース(Markdownファイル、cronジョブ設定、Gitログ)を読み取り、構造化JSONを
public/data/*.json に書き出します。APIルートは絶対パスではなく、これらのJSONファイルから読み取ります。ジェネレーターは prebuild で実行されるため、毎回のデプロイで最新データを取得できます。cronジョブがデータを再生成し、コミットしてプッシュします。プッシュが更新されたデータでの Vercel の再ビルドをトリガーします。5つのJSONファイルでダッシュボード全体をカバーします:
tasks.json は HEARTBEAT.md のチェックボックスから、calendar.json は Git コミットとcronスケジュールから、memories.json はワークスペースのメモリファイルから、team.json はcronジョブのモデル統計から、status.json はステータス更新のMarkdownから。コード
APIルートの変更内容
変更前:すべてのAPIルートにハードコードされた絶対パスとシェルコマンドがありました。
変更後:すべてのAPIルートは相対的な静的JSONファイルから読み取ります。
execSync なし。絶対パスなし。ファイルシステム依存なし。どこでも動作します。ジェネレータースクリプトがビルド時にすべてのローカルファイルシステムアクセスを処理するため、本番環境のAPIはそれを必要としません。
const heartbeatPath = "/Users/shawnos.ai/.openclaw/workspace/HEARTBEAT.md"execSync("git log --since=...", { cwd: "/Users/shawnos.ai/shawn-gtme-os" })const jobsPath = "/Users/shawnos.ai/.openclaw/cron/jobs.json"変更後:すべてのAPIルートは相対的な静的JSONファイルから読み取ります。
const dataPath = path.join(process.cwd(), "public/data/tasks.json")const data = JSON.parse(fs.readFileSync(dataPath, "utf8"))return data.tasks || []execSync なし。絶対パスなし。ファイルシステム依存なし。どこでも動作します。ジェネレータースクリプトがビルド時にすべてのローカルファイルシステムアクセスを処理するため、本番環境のAPIはそれを必要としません。
パターン
データの鮮度を保つ
ジェネレーターは2つの場所で実行されます。まず、package.json の
データの鮮度はcronの頻度に依存します。30分ごとなら、ダッシュボードが30分以上古くなることはありません。ステータスダッシュボードには十分です。WebSocket やリアルタイムサブスクリプションは必要ありません。cronとGitプッシュと再ビルドの組み合わせは、シンプルで信頼性が高く、無料です。
prebuild が next build の前に実行されるため、毎回のデプロイで最新データを取得できます。次に、ローカルマシン上のcronジョブがジェネレーターを実行し、新しいJSONをコミットし、GitHub にプッシュします。プッシュが Vercel のデプロイをトリガーします。データの鮮度はcronの頻度に依存します。30分ごとなら、ダッシュボードが30分以上古くなることはありません。ステータスダッシュボードには十分です。WebSocket やリアルタイムサブスクリプションは必要ありません。cronとGitプッシュと再ビルドの組み合わせは、シンプルで信頼性が高く、無料です。
プロのコツ
実際にどれだけ節約できたか
変更前:すべて Opus。毎日104回のcron APIコール、出力価格 $75/100万トークン。WhatsApp の自己チャットループがカスケード返信を生成。APIコスト 約50ドル/日。
変更後:96回のcronコールを無料のローカル Ollama に移行。残り8回のAPIコールを Sonnet($15/100万)で。コンテンツ制作は Opus で1日1-2回。自己チャットループを3秒のデバウンスで解消。APIコスト 約0.50ドル/日。
99%のコスト削減です。重要な部分では同じ出力品質を維持。ダッシュボードは Vercel で動作します。チーム名簿は実際のcronジョブデータからのモデル統計を表示します。タスクボードは HEARTBEAT.md の実際のチェックボックスを読み取ります。モックデータなし。ローカル依存なし。本番投入です。
変更後:96回のcronコールを無料のローカル Ollama に移行。残り8回のAPIコールを Sonnet($15/100万)で。コンテンツ制作は Opus で1日1-2回。自己チャットループを3秒のデバウンスで解消。APIコスト 約0.50ドル/日。
99%のコスト削減です。重要な部分では同じ出力品質を維持。ダッシュボードは Vercel で動作します。チーム名簿は実際のcronジョブデータからのモデル統計を表示します。タスクボードは HEARTBEAT.md の実際のチェックボックスを読み取ります。モックデータなし。ローカル依存なし。本番投入です。
アンチパターン
よくある間違い
すべてに Opus を使う。最大の金食い虫です。ほとんどのタスクにフロンティアレベルの推論能力は不要です。14Bのローカルモデルで構造化データの抽出は十分に処理できます。
サーバーレス関数からローカルファイルを読む。本番サーバーはあなたのラップトップではありません。絶対パスは Vercel、AWS Lambda、その他どのクラウドプラットフォームでも必ず失敗します。デプロイ前にデータを生成しましょう。
データがない場合のフォールバックがない。クラッシュする代わりに、常に空の配列を返しましょう。tasks.json がまだ存在しなければ、[] を返す。ダッシュボードはエラーを出すのではなく、空の状態でレンダリングされるべきです。
APIルートでGitコマンドを実行する。execSync("git log") はローカルでは動作しますが、Gitリポジトリがない本番環境では失敗します。ビルド時に移動しましょう。
リフレッシュの過剰設計。ステータスダッシュボードに WebSocket は不要です。cronとGitプッシュと再ビルドの組み合わせで、シンプルかつ信頼性があります。
サーバーレス関数からローカルファイルを読む。本番サーバーはあなたのラップトップではありません。絶対パスは Vercel、AWS Lambda、その他どのクラウドプラットフォームでも必ず失敗します。デプロイ前にデータを生成しましょう。
データがない場合のフォールバックがない。クラッシュする代わりに、常に空の配列を返しましょう。tasks.json がまだ存在しなければ、[] を返す。ダッシュボードはエラーを出すのではなく、空の状態でレンダリングされるべきです。
APIルートでGitコマンドを実行する。execSync("git log") はローカルでは動作しますが、Gitリポジトリがない本番環境では失敗します。ビルド時に移動しましょう。
リフレッシュの過剰設計。ステータスダッシュボードに WebSocket は不要です。cronとGitプッシュと再ビルドの組み合わせで、シンプルかつ信頼性があります。
knowledge guide
関連記事