LLM のモデル ID を明示的にピン留めせず、プロバイダや CLI が定める既定モデルに自動的に従う運用。エージェントパイプラインでは「気づかないうちに別のモデルで動いていた」というドリフトの主要因になる一方、世代リリースごとの手動追従コストを払わずに済む利点もあり、リスクとして避けるか・方針として採るかを明示的に決めるべき設計点である。
概要 — 追従には 2 系統ある
同じ「デフォルト追従」でも、既定がどこで解決されるかによって性質が正反対になる。
| サーバー側追従 | クライアント側追従 | |
|---|---|---|
| 代表例 | Claude のエイリアス（sonnet / opus / haiku が最新版へ自動追従） | Codex CLI の既定モデル（バージョンごとに固定） |
| 既定の解決場所 | プロバイダのサーバー | CLI バイナリ内部 |
| 切替のタイミング | プロバイダ側の任意のタイミング（仕様非公開） | CLI を更新した瞬間のみ |
| 何もしないと | ある日突然変わり得る | 変わらない |
| 有効な検知手段 | 実 API プローブ・セッションに現れた初見 ID の監視 | 更新直後の実効モデル実測（サーバー側監視は無意味） |
サーバー側追従は「いつ変わるかわからない」ので常時監視が効く。クライアント側追従は「変えたときにしか変わらない」ので、CLI 更新やコンテナ再構築といった切替点になり得るイベントを更新手順に組み込むのが正しい防御になる。片方に張った検知網はもう片方に効かない。
ピン留めとのトレードオフ
- ピン留め（フル ID 指定）: 切替タイミングを統制できるが、世代リリースごとに手動で追従し続けるコストを払う。検証段（verifier）や再現性が要る用途に向く
- 既定追従: 追従コストはゼロだが、切替が暗黙になる。新世代へ素早く乗る利得が大きい段に向く。採用するなら「暗黙のデフォルト」のまま放置せず、追従していること・切替点・確認手順を台帳に明文化し、切替検知後は旧世代の評価資産（golden set 等）で較正チェックを行う
なお対話 UI が表示するモデルと非対話実行（exec 等）の実効モデルは一致しないことがあり、実効モデルの確認は実行系が実際に返す値を正とする。
関連記事
- GPT-5.6 sol に 2 日で準拠する — CLI 更新がモデルを黙って替える切替点を実測特定し、当日中に較正・再計測まで流した実録
- クロスファミリー検証の最終型 — モデルマスタ台帳と三経路の検知網（サーバー側追従の監視）の設計
- モデル戦略編 — ティア割当とエイリアス・effort 運用。「世代ごとに測り直す運用パラメータ」の考え方
関連用語
- ハーネスエンジニアリング — 「人が覚えておくべきこと」を設定と検知機構に落とす、という防御の考え方の全体像
- ループエンジニアリング — モデル世代交代を計測 → 改版のループの 1 イベントとして流す運用系