サンプリング
temperature、top_p、top_k、必要に応じてseed。低いtemperatureは抽出、分類、コードに向き、高い値は発想や創作的な文章に向きます。
AI推論ガイド
モデルとのやり取りとAPI
アプリケーションとモデルのあいだの取り決めです。リクエストをどう組み立てるか、出力を機械が扱える形にどう制約するか、モデルがどうツールを呼ぶか、そして全体の移植性を保つAPI面を扱います。
リクエストの構造
- メッセージとロール：systemメッセージが常設の指示を定め、userメッセージが入力を運び、assistantメッセージが過去のモデルの発話を運びます。モデルは直近の質問だけでなく、送信されたリスト全体を見ています。
- テンプレートと先頭埋め：アプリケーションは動的なスロットを持つテンプレートからプロンプトを組み立てます。assistantの発話の冒頭をあらかじめ埋めておくと、形式やトーンを誘導できます。
- コンテキスト管理：ウィンドウは有限なので、長い会話は切り詰めるか要約することになります。何を落とすかで答えが変わります。この方針は意図的に決めてください。
- サービングへの影響：プロンプトの構造は性能に関わる決定です。安定した内容（システムプロンプト、例）を前に、変動する内容を後ろに置くことがprefix cachingを効かせる条件です。サービング最適化を参照してください。
プロンプティングの手法そのもの（zero-shot、few-shotの例、chain-of-thought、役割設定）は、パターンのパターンカタログで扱っています。
推論パラメータ
どのリクエストにも、出力の分布と出力の取り決めを変えるつまみが付いています。
長さと停止
max_tokensは生成量と費用の上限を決め、stopシーケンスは早期に打ち切ります。どちらもコストだけでなく結果そのものを変えます。
整形と内部の観察
repetition、presence、frequencyの各ペナルティ、特定トークンを促進または禁止するlogit_bias、確信度の手がかりとなるlogprobs、複数候補を得るnやbest_ofがあります。
パラメータの対応状況と正確な意味はプロバイダーやランタイムによって異なります。これらの設定と再現性の関係は非決定性で詳しく扱います。
構造化出力
パイプラインが必要とするのは散文ではなくJSONです。そこへ至る手法は大きく2系統あります。
検証して再試行
スキーマに照らして応答をパースし、失敗したらプロンプトをやり直します（Instructorパターン）。ホスト型を含むどのAPIでも使えますが、失敗した試行のぶんレイテンシとトークンを消費します。
制約付きデコーディング
各ステップで無効なトークンをマスクし、スキーマに適合する出力しか生成できないようにします（Outlines、XGrammar、Guidance。vLLMとSGLangに組み込まれ、ホスト型プロバイダーではJSON schemaモードとして提供されます）。形式は保証されますが、構文的に正しい答えが意味的に誤っていることはあり得ます。
スキーマを伴わない単なる「JSONモード」が約束するのは、パースできるJSONであって、あなたのJSONではありません。スキーマの強制に加えて、値そのものをアプリケーション側で検証してください。
function callingとMCP
function calling
利用できるツール（名前、目的、パラメータのスキーマ）を記述すると、モデルは散文ではなく構造化された呼び出しを出力します。あなたのコードがそれを実行し、結果を新しいメッセージとして返すと、モデルは実データを使って続きを進めます。これは制約された形式を生成する次トークン予測なので、スキーマの質とツールの説明が信頼性を左右します。計画・実行・評価のループで包んだものがエージェントの基盤となる仕組みです。エージェント型パターンを参照してください。オープンモデルでは対応状況と品質に差があるため、使用するランタイムで確認してください。
Model Context Protocol
MCPは、アシスタントが外部システムに到達する方法を標準化します。ホストアプリケーションがMCPクライアントを動かし、MCPサーバーに接続します。各サーバーは共通のプロトコル越しに、ローカルまたはリモートでツール、データリソース、プロンプトを公開します。アプリごと・サービスごとに個別の統合を作る代わりに、プロトコルのどちら側も一度書けば済みます。1つのホストに複数のサーバーを同時に接続できます。
互換API
セルフホストのエンジンやゲートウェイは主要プロバイダーのHTTP APIを模倣しているため、既存のSDKはベースURLを変えるだけで動きます。これがホスト型とセルフホスト型のバックエンド間でアプリケーションの移植性を保っています。
OpenAI互換
- chat completionsとモデル一覧のエンドポイント。ストリーミングはstreamフラグで指定する
- 事実上の標準。vLLM、SGLang、大半のゲートウェイが提供している
- ベースURLを上書きして公式SDKを自分のエンドポイントに向ける。セルフホストのサーバーではAPIキーが単なるプレースホルダであることも多い
Anthropic互換
- Messages形式のエンドポイント。認証はx-api-keyとanthropic-versionヘッダーで行う
- システムプロンプトはトップレベルのフィールドで、ツール利用は型付きのコンテンツブロックとして届く
- 高度な機能（prompt caching、extended thinking、画像や文書の入力）はオープンなバックエンドでは部分的にしか再現されていない
互換性は保証ではなく程度の問題です。パラメータの網羅範囲と機能の対応はバックエンドごとに異なるため、エンドポイントを差し替える前に、依存している機能を実際に試してください。