記録

モデルは多くを知り、ほとんど何もできない。道具を渡すまでは

検索する、計算する、コードを実行する、API を呼ぶ。いつ道具に手を伸ばすかはモデル自身が決め、その結果を答えに織り込みます。この一点が、文章生成器を「行動できるもの」に変えます。

モデルは書式を埋めるだけ。実行するのはこちら側

ツール利用の裏側にある仕組みです。関数を JSON スキーマとして記述すると、モデルは自由文ではなく get_weather({"city": "Stuttgart"}) のような構造化された呼び出しを返します。モデル側では何も動きません。埋まった要求が渡され、どうするかは自分のコードが決めます。

答えが外れたとき、知りたいのは「なぜ」であって「そうなった」ではない

すべての要求をトレースとして記録します。プロンプト、ツール呼び出し、中間手順、遅延、トークン、費用。これはインフラの仕事として自分がすでにやっていることです。顕微鏡の下の対象が新しいだけで、作法は同じです。

すべての提供元の手前に置く、ひとつの API

アプリと全モデル提供元をつなぐ中央の分岐点です。経路制御とフォールバック、キャッシュ、レート制限、鍵の管理、そして費用をひと目で見る場所（LiteLLM、Portkey など）。ひとつの提供元が落ちても、流れは別の経路へ続きます。

トークンはすべて請求書に載る

だから体系的に削ります。応答をキャッシュし、軽い仕事は小さなモデルへ段階的に振り、プロンプトを絞り、要求をまとめる。目指すのは安い製品ではなく、同じ品質を請求額の何分の一かで得ること。そして、どの手が品質を削るのかを知っておくことです。