開発ツールで使うAIモデルを組織が固定できる設定が追加。見積書に書く3点

AI 駆動開発を外注するとき、見積書には「AI を使って効率化する」と書かれていても、実際にどのモデルが使われるかは書かれていないことが多い。モデルが違えば単価も精度も違う。にもかかわらず、これまでは契約書に書いても実行環境で担保する手段がなかった。

開発ツール側の設定に、その手段が増えてきている。Claude Code の最新版 2.1.283 で、組織が配る管理設定に availableModelsMatch と deniedModels が加わった。どちらも「開発者が使えるモデルを組織側で固定する」ための設定である。

工具棚の5つのフックのうち2つが鎖で塞がれ、手前に型板が置かれている

公開されている事実

Claude Code の変更履歴（CHANGELOG）に書かれている内容を整理する。

追加された設定・機能	内容
`availableModelsMatch`	`"exact"` を指定すると、`availableModels` に書いた項目がそこで名指ししたモデルのバージョンだけを許可する。新しいリリースは一覧に載るまでブロックされたままになる
`deniedModels`	`availableModels` が許可していても、特定のモデルを個別にブロックする
`x-claude-code-prompt-id`	ゲートウェイ向けのヒントヘッダに追加。1 つの指示に対応する複数のリクエストを、LLM ゲートウェイ側でまとめられる。`CLAUDE_CODE_GATEWAY_HINT_HEADERS=1` で有効化
OpenTelemetry の出力拡張	MCP ツール・WebFetch・WebSearch の出力を `tool.output` スパンイベントに記録できる（`OTEL_LOG_TOOL_CONTENT=1`）

前提として押さえておきたいのは、管理設定（managed settings）は利用者側では上書きできないという点である。公式ドキュメントによれば、管理設定は managed-settings.json というファイル、MDM のポリシー、または claude.ai のコンソールから配布するサーバー管理設定として配られ、設定の優先順位でいちばん上に置かれる。availableModels は /model コマンド、--model オプション、利用者自身の設定ファイルの model キーのすべてを縛る。

つまり今回の追加は、「組織が許したモデル以外は動かない」という状態を、機械的に作れるようにしたものだと読める。

論点 1. 「バージョンまで固定する」は検証コストの話

availableModelsMatch の "exact" が効くのは、新しいモデルが出たときに自動で切り替わらないようにする場面である。

モデルが勝手に新しくなると何が困るか。困るのは、精度を検証し直す必要が出ることだ。AI を組み込んだシステムでは、モデルが変わると出力の傾向が変わる。評価データで測り直し、プロンプトを調整し、場合によっては後段の処理も直す。この一連の作業は、新機能の開発とは別の工数として発生する。

AIの精度評価は誰がやるかで整理したとおり、評価の主体と頻度は契約で決めておく項目である。そこに「モデルを更新するとき」という条件が加わると考えると分かりやすい。バージョン固定は、検証をやり直す時期を発注側が選べるようにするための仕組みである。

論点 2. `deniedModels` は「許可リスト」だけでは足りない場面のため

許可リスト（availableModels）があるのに、なぜ拒否リストが別に要るのか。

実務では、許可リストを広めに作らざるを得ない場面がある。開発の段階では複数のモデルを試したい。一方で、特定のモデルだけは使わせたくないという要求が、別の理由で立つことがある。単価が高い、社内の審査を通っていない、提供条件が変わったばかりで様子を見たい、といった理由だ。

許可と拒否を別々に持てると、広い許可リストを維持したまま、個別の除外だけを素早く足せる。運用としては、許可リストの見直しより拒否リストの追加のほうが早く回る。

論点 3. 使用量の記録は「実費精算」の前提になる

x-claude-code-prompt-id と OpenTelemetry の出力拡張は、地味だが契約の型に関係する。

AI 駆動開発の案件では、AI の利用料を実費精算にする契約がある。AI運用費は定額保守か従量精算かで 3 つの型に分けたとおり、API 実費を誰が持つかで契約は分かれる。実費精算にした場合、請求の根拠になるのは使用量の記録である。

1 つの指示が裏で何回のリクエストに分かれたかをまとめられると、「この作業にいくらかかったか」を案件単位で示しやすくなる。ツールの出力までスパンに載せられるようにしたのも、同じ方向の変更だと考えられる。

発注者・企業への影響

ここからは見立てである。

1 つ目。「使うモデルを指定する」という要求が、実現可能な要求になってきたと考えられる。 これまでは契約書に書いても、開発現場で実際に何が使われたかを確かめる手段が乏しかった。組織の管理設定で縛れるなら、要求として書く意味が出てくる。ただしこれは開発会社側の環境の話であり、発注側が直接設定できるものではない。要求できるのは「そちらの環境でどう担保しているか」を説明してもらうところまでである。

2 つ目。モデル固定はタダではないと考えられる。 バージョンを固定すると、新しい安いモデルが出ても自動では乗り換わらない。乗り換えるには検証の工数がかかる。つまり**「固定して検証の時期を選ぶ」か「追随して単価の下落を取りに行く」かの選択**になる。どちらが得かは案件による。運用が長い案件ほど、乗り換えの手順を先に決めておくほうが効く。

3 つ目。今回の変更は 1 つのツールの話だが、方向としては業界全体のものだと考えられる。 企業が AI ツールを本格的に入れるほど、「誰がどのモデルをどれだけ使ったか」を管理側が押さえる要求は強くなる。開発会社を選ぶとき、この種の管理をすでに運用に組み込んでいるかどうかは、体制の成熟度を測る材料になる。

見積もりで確認する 3 点

提案に、使用するモデル名とバージョンが書かれているか。書かれていないなら、どの段階で決まるのか
モデルを更新するとき、精度の再検証は誰の費用で行うか。保守費に含まれるのか、都度見積もりなのか
AI の利用料を実費精算にする場合、使用量の記録をどう出すか。案件単位で分けられるのか

この 3 点は、条件をそろえて複数社に聞くと扱いの差がはっきり出るところである。案件票を作るところからであれば無料の相見積もりで始められる。AI 駆動開発で工数が下がる工程と下がりにくい工程の切り分けはAI駆動開発で工数が下がる工程、下がりにくい工程にまとめてある。

まとめ

Claude Code 2.1.283 で追加されたのは、組織が使えるモデルを固定・除外するための管理設定と、使用量を追いやすくするための記録の拡張である。開発ツールの内部的な変更に見えるが、発注側から見ると「見積書に書いた前提が実際に守られるか」に関わる。

やることは 2 つ。見積書にモデル名とバージョンを書かせること。そして、モデルを更新するときの再検証を誰が負担するかを先に決めておくこと。 どちらも契約前に決められる。

参考・出典

Claude Code CHANGELOG（Anthropic, 2.1.283）: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
Settings files and precedence（Claude Code Docs）: https://code.claude.com/docs/en/settings