AI活用ナビゲーターの ワケハト です。「新しいモデルが出たので入れました」は、検証組織としては不完全な報告です。知りたいのは、今どの状態か・何が未検証か・誰の用途なら使ってよいか、の三点です。
この回の答え
モデルは名前一覧ではなく、候補／試験中／安定の状態付き台帳で管理します。誰の用途なら使ってよいかを合意台帳にします。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| レジストリ | モデルの合意台帳。状態・用途・未検証を残す |
| candidate | 触り始めた候補。本番ではない |
| testing | 評価中。ゲートを通している途中 |
| stable | 合意した用途と評価を満たした状態。次スパイラルで再評価する |
| deprecated / failed | 使わない／不合格として残す終端状態 |
| use_cases | どの用途で許可するかのタグ |
社内ではモデルをレジストリで宣言し、status で管理します。
candidate → testing → stable（または deprecated / failed）
なぜレジストリが事業に効くか
技術チームの中だけでは、「昨日のチャットで良いと言われたモデル」が正になりがちです。レジストリがあると、次の合意が作りやすくなります。
- PoC で触っただけの候補を、本番候補と混同しない
- coding 向け合格を、全社標準と誤読しない
- 失敗理由が残り、同じ遠回りを繰り返さない
- 後任モデルへの置換時期を説明できる
つまりレジストリは、技術資産というより 意思決定の翻訳装置 です。
レジストリに持つ情報
最低限、次を持たせます。
- 一意な model_key
- 公開名 / 取得元（HF など）
- 量子化方式、context 長
- 推奨ランタイムと対応ランタイム（エンジン比較対象: vllm / trtllm / sglang / atlas）
- 必要メモリの目安
- 用途タグ（coding、long_context、rag など）
- known_issues
- tested_profiles / best_profile
- status
用途タグがあることで、「速いがcoding向けではない」といった誤採用を減らせます。事業側への説明でも、「速いです」より「coding 用途・同時利用N名・メモリ枠Xの条件下で stable」の方が合意が早いです。
| 項目 | 事業側で使う読み方 |
|---|---|
| status | 触ってよいか、採用してよいか |
| 用途タグ | どの業務仮説の話か |
| known_issues | 期待値調整とリスク共有 |
| best_profile | 「どれを起動すればよいか」の答え |
| tested_profiles | まだ試していない条件の可視化 |
状態遷移の意味
| status | 意味 | やってよいこと |
|---|---|---|
| candidate | 候補として登録しただけ | dry-run、小規模試験 |
| testing | 比較評価中 | ベンチとスモークを反復 |
| stable | 用途付きで採用可 | 常駐や社内公開の対象 |
| failed | 条件付きで不合格 | 理由をknown_issuesへ |
| deprecated | 後任へ置換 | 新規採用しない |
重要なのは、stable を「勝ち」ではなく 用途と制約付きの合格 として扱うことです。coding で stable でも、長文で stable とは限りません。ステークホルダー説明では、必ず用途と制約をセットで話します。
遷移を止める判断も成果
failed や「testing のまま保留」は敗北ではありません。早く止めたことで、重い検証コストや誤った社内展開を避けられます。レジストリは成功事例の陳列棚ではなく、判断履歴です。
追加手順（要約）
- レジストリに候補を追加しスキーマ検証
- 起動プロファイルを作る
- スパイラル（起動→計測→評価→記録）を回す
- best_profile / known_issues を更新
- status を進めるか止めるか決める
- 関係者向けに「用途・制約・次の一手」を一文で共有する
合意形成チェックリスト
- [ ] 誰の用途の話かが明示されている
- [ ] stable の制約（メモリ、同時利用、ランタイム）が書かれている
- [ ] 未検証項目が「無い」ではなく「未検証」と残っている
- [ ] 失敗時の known_issues が次の実験仮説につながっている
- [ ] 前任 / 後任の関係が deprecated で追える
よくある認識ズレ
| 技術側の言い方 | 事業側が受け取りやすい言い方 |
|---|---|
| tok/s が伸びた | この用途では待ち時間が許容範囲に入った |
| smoke 通過 | 最低限の業務接続試験は通った（採用決定ではない） |
| stable | 指定用途・指定制約なら社内利用してよい |
| failed | この条件では見送り。理由と代替を残した |
数字を減らす必要はありません。数字の横に、決めるための一文を添えることが翻訳です。
つまずいたこと
「どのモデルが本番候補か」がチャットの記憶にしかないと、休暇明けに全員が迷子になります。レジストリ以前は、それでした。
苦労したのはツール選定より、ステータス（実験／候補／廃止）を更新する責任者を決めることです。箱だけ作っても、腐った一覧になります。
この回の要点
- 実験／候補／廃止のステータスを持つ
- 更新責任者を決める
- チャットの記憶をレジストリにしない
candidate / stable / 廃止の型は公開していますが、どのモデルが stable かは環境依存で断定しません。昇格根拠となる数字は再計測と匿名化が済んだものから載せます。
次は「測って比べて、次は1つだけ変える」です。レジストリのステータス更新を、1軸ずつの改善ループに載せます。
よくある質問
新しいモデルを入れたらすぐ本番ですか？
いいえ。candidate→testing→stable の遷移で、何が検証済みかを明示します。
レジストリで管理する理由は？
「入れました」だけでは、状態・未検証項目・用途許可が伝わらないためです。
stable の意味は？
合意した用途と評価ゲートを満たした状態です。永久保証ではなく、次のスパイラルで再評価します。
