プロンプトで十分な場合

ファインチューニングに取りかかる前に、プロンプト作成を帰無仮説として扱います。現代の最先端モデルは十分な潜在能力を備えているため、ほとんどのタスクは重みを更新する問題ではなく、知識を呼び出して指示する問題です。

チームが犯す高くつく誤りは、適切に構成したプロンプト、少数の例、ツールへのアクセスによって、追加のトレーニングコストなしに差を埋められる場合でも、トレーニングを実行してしまうことです。ファインチューニングが正当化されるのは、プロンプト作成では実証可能な形で限界に達した場合に限られます。

• プロンプト作成はリクエストごとに変更しますが、ファインチューニングはモデルを変更します
• プロンプト作成は数秒で元に戻せますが、チューニング済みチェックポイントは確定した成果物です
• 安価な方法から始め、根拠がある場合にのみ拡張します

アプローチを、金額だけでなく、独立した3つのコスト軸で比較します。

• 反復コスト - 振る舞いをどれだけ速く変更できますか。プロンプト作成：数分。ファインチューニング：1サイクルあたり数時間から数日。
• 推論コスト - プロンプト作成では、長い指示や例に対して毎回トークン単位の料金を支払います。チューニング済みモデルでは、その振る舞いを重みに組み込んでプロンプトを短くできます。
• 保守コスト - プロンプトはソース管理でき、監査可能です。一方、ベースモデルが廃止されるたびに、チェックポイントを再チューニングする必要があります。

プロンプト作成は反復コストと保守コストで優位ですが、大量利用ではファインチューニングが推論コストで優位になる場合があります。

ファインチューニングによる推論コスト削減の議論が成り立つのは、ボリュームの閾値を超える場合だけです。損益分岐点を明示的にモデル化してください。1回の呼び出しに入力トークンを2,000個追加する長い few-shot プロンプトには、繰り返し発生するコストがあります。一方、チューニング済みモデルでは、トレーニングコストを利用量全体に分散できます。

トラフィックが損益分岐点を下回るなら、few-shot プロンプトのほうが厳密に安価で、しかも柔軟です。

プロンプト方式を選ぶ最大の理由は、不確実性のもとでの選択肢の多さです。要件は変化します。新しいエッジケース、ポリシーの変更、新しい出力フィールドなどです。プロンプト方式ならテキストを修正すれば済みますが、チューニング済みモデルではデータを再収集して再トレーニングする必要があります。

タスクの定義がまだ変化している段階、つまりプロダクト初期、仕様が曖昧な時期、ステークホルダーの変更が頻繁な時期では、ほぼ常にプロンプト方式が適切です。対象が安定してから、初めて重みに組み込んでください。

チューニングが必要だと感じる問題の多くは、プロンプト側のテクニックで解決できます。

• 形式への準拠 - トレーニングではなく、構造化出力や JSON schema の制約で対応する
• ドメインのトーン - スタイルの例をまとめたブロックと、声の特徴を明示した説明を用意する
• 推論の深さ - 分解、chain-of-thought、または計画ステップを使う
• 知識の不足 - retrieval（RAG）で事実を注入する。チューニングでは古くなった事実を焼き付けてしまう

チューニングを検討するのは、プロンプト方式では構造的に実現できない場合だけにしてください。たとえば、レイテンシーが重要な場合のプロンプト圧縮、極めて独自性の高い形式、強い指示を与えてもモデルが従わない振る舞いなどです。

よくある混同があります。チームは知識を注入するためにファインチューニングしますが、本来は retrieval を使うべきです。ファインチューニングは事実を教える用途には向いていません。情報が失われやすく、更新コストが高いうえ、トレーニング例の間を補間する際に幻覚を起こしやすいためです。

判断の目安：不足しているのがモデルが何を知っているかなら retrieval を使います。不足しているのがモデルがどのように振る舞うかなら、チューニングを検討します。知識は毎日変わりますが、振る舞いが変わることはまれです。

プロンプト方式では不十分だと判断する前に、ラダーを最後まで登ってください。ほとんどのチームは2段目で諦めています。

• 第1段階：明確な指示 + 役割 + 明示的な出力契約
• 第2段階：エッジケースを網羅する few-shot の例
• 第3段階：複数の連続した呼び出しへの分解
• 第4段階：知識と計算を外部化するためのツール利用 / retrieval
• 第5段階：自己批評または検証パス

ホールドアウト評価セットで第1〜5段階をすべて試して初めて、ファインチューニングを正当化できます。

長いプロンプトが増やすのはコストだけではありません。時間も増加します。多くのサービングスタックでは、入力トークンが Time to First Token に大きく影響します。4,000トークンの指示と例を含むプロンプトには、呼び出しごとに測定可能なレイテンシーのオーバーヘッドがあります。

プロンプト方式が大規模運用で本当に不利になるのは、長いプロンプトの振る舞いと100ミリ秒未満の応答の両方が必要な場合です。その場合は、その振る舞いを小規模なチューニング済みモデルに蒸留するのが適切です。ただし、そのレイテンシー予算が思い込みではなく、実際に必要なものかを確認してください。

最初の請求額ではなく、アーティファクトのライフタイム全体の TCOで判断してください。チューニング済みチェックポイントには、次のような見えにくい継続コストがあります。

• プロバイダーがベースモデルを非推奨にした際の再チューニング（多くの場合、6〜12か月ごと）
• 維持し続けなければならないデータパイプラインとラベリングプロセス
• 再チューニングのたびにリグレッションを検出する評価インフラ
• バージョン管理、ロールバック、A/B サービングの複雑さ

プロンプト方式の TCO は、ほとんどの場合、テキストファイルと評価セットです。ML ops の成熟度が十分でないチームでは、この非対称性だけでも、予想以上に長くプロンプト方式が有利になります。

次の質問の大半に YES と答えられるなら、プロンプト方式で十分です。

• タスクの仕様は月ごとに変化し続けていますか？
• ボリュームは計算した損益分岐点の閾値を下回っていますか？
• 不足しているのは振る舞いではなく、retrieval で取得できる知識ですか？
• ホールドアウト評価で、ラダーを登った後のプロンプト方式が許容可能な品質に達していますか？
• レイテンシー予算は、現在のプロンプト長に余裕を持って対応できますか？
• チームに、維持管理されたチューニングと評価のパイプラインがありませんか？

YES が3つ以上ならプロンプト方式を継続し、答えが変わったときにだけ再検討してください。

意思決定は感覚ではなく、データとして表現してください。小さなスコアリング関数を使うと、チームは前提（ボリューム、レイテンシー、仕様の安定性）を明示せざるを得なくなり、後から推奨内容を監査できるようになります。

プロンプト方式をデフォルトとし、ファインチューニングは次の手段にします。仕様が変化していて、ボリュームが損益分岐点を下回り、不足しているのが振る舞いではなく知識である間は、プロンプト方式を継続してください。

• 金額だけでなく、反復、推論、保守のコストを比較する
• チューニングでコストが下がると考える前に、ボリュームの損益分岐点を計算する
• プロンプト方式では不十分だと判断する前に、プロンプト最適化ラダーを最後まで登る
• 知識は retrieval し、頑固な振る舞いやレイテンシーを理由とするプロンプト圧縮に限ってチューニングを使う
• ベースモデルの非推奨化を含め、ライフタイム全体の TCO で判断する