modelchk

実行に費やす前に規模を見極めましょう。モデルにどれほどの能力が必要か、どれほど深く考えるべきかを判断します。

modelchk は読み取り専用の助言ツールです。1 回の評価から、モデルの 1 回の実行における認知コストを決める 2 つの調整項目、つまり能力ティアと推論の労力を見積もります。具体的なモデルやレベルを選択、ルーティング、切り替え、固定、起動、設定したり、必須としたりすることはありません。

目標

リスクと複雑さを 1 回評価し、2 つの座標を推奨します。

能力ティア — 十分な能力を持つ最も低コストのクラスです。

• fast は、ローカルで機械的かつ取り消し可能な作業で、低コストかつ完全な検証ができる場合に適しています。
• standard は、通常のリポジトリに基づく推論、複数ステップの草案作成、一般的なコーディング、標準的なドキュメントやスキルの作成に適しています。
• frontier は、アーキテクチャ、高い曖昧さ、安全性・セキュリティ・プライバシー・データ損失のリスク、リリースに関わる重要なレビュー、複数分野にまたがる作業、または誤った仮定によって大規模な実行が無駄になる作業に適しています。

推論の労力 — そのモデルにどれほど深く検討させるかを示します。modelchk が推奨するのは労力の 意図 であり、それをアクティブなモデルの実際のレベルに対応づけること（モデル自体を選ぶのと同様）は、実行側の役割であり、このスキルの役割ではありません。検討の浅いものから深いものへ、次のようになります。

• glance — 最小限の検討で、直接的な道筋を進みます。（モデルの最低レベルに対応します。）
• measured — 通常の日常的な検討です。（モデルのデフォルト、またはデフォルトが指定されていない場合は段階の中間に対応します。）
• thorough — さらに慎重に検討し、選択肢を比較して前提を確認します。（日常的な設定より上で、最上位より下です。）
• exhaustive — 最大限に検討し、探索を尽くして作業を再確認します。（モデルの最高レベルに対応します。）

この 2 つの軸は直交しています。範囲は限定されていても細かな作業なら fast + thorough、専門家による迅速な判断なら frontier + glance になり得ます。ただし、ほとんどの作業では両者は連動し、低コストの作業に深い検討が必要な場合や、高性能なモデルに簡単な判断だけを求める場合にのみ分かれます。推論の労力が増やすのは検討の深さであり、能力ではありません。また、労力を増やせば正確さが増すとは限りません。

ワークフロー

1. 規模を見極める対象を明確にします。タスク、成果物、レビュー、再実行、または計画のいずれかです。
2. リスクと複雑さを 1 回評価します。この 1 回の評価が、両方の座標に反映されます。
   • ファイル、モジュール、または担当範囲の境界をまたぐかどうか。
   • 可逆性と影響範囲。
   • 安全性、セキュリティ、プライバシー、公開、またはデータ損失のリスク。
   • 新規性、曖昧さ、長いコンテキストを統合する負荷。
   • 外部調査、敵対的レビュー、または慎重なリリース手順が必要かどうか。
   • 誤った回答によるコスト。
3. 能力ティアを決定します。作業に必要な判断力とリスクを許容範囲内に収める、最も低コストのクラスを選びます。
4. 推論の労力を決定します。まずはティアに合わせます（fast→glance、standard→measured、frontier→thorough。最も難易度と重要性が高い作業には exhaustive を使用します）。そのうえで、検討の必要性と能力の必要性が分かれる場合は調整します。たとえば、低コストの作業でも曖昧さ、長い複数ステップの推論、または敵対的な自己確認が必要なら引き上げ、高性能なモデルで範囲の限定された作業を行うなら引き下げます。
5. 両方の座標と共通の根拠を報告します。また、各調整項目について「引き上げる場合」と「引き下げる場合」の条件、およびティアや労力にかかわらず作業に必要な検証、つまり検証対象も報告します。
6. 終了します。

ルール

• 実行における認知コストの規模だけを判断します。それ以外は判断しません。調整するのは、どの能力層を使うか（能力ティア）と、どれだけ深く考えるか（推論の労力）の2つです。オーケストレーションの調整項目であるコンテキスト予算、並列実行の幅、ツール権限の範囲は別の判断事項なので、ここでは扱いません。このリスク評価を共有しても、それらの判断事項は対象になりません。
• 中立的な表現のみを使用します。ティアは fast／standard／frontier、労力は glance／measured／thorough／exhaustive です。それぞれは、使用中のモデルの段階における位置（最低、既定、既定より上、最高）で定義される意図であり、特定ベンダーのレベル名ではありません。
• 解決時には、労力をレベルではなく段階に対応させます。モデルに中間レベルがない場合は、最も近い提供レベルに段階を対応させます。これにより、意図は常に実在する設定に対応し、範囲外の設定に解決されることはありません。
• 既定では、必要十分な最も低コストのティアと、作業を満たす労力を選びます。どちらも最強のものを選ぶのではありません。
• 労力は熟考の予算であり、能力でも回答の長さでもありません。能力を補うために労力を上げてはいけません。それはティアの役割です。
• ルーティング権限はありません。このスキルが推奨するのは2つの座標のみです。何を実行するかを決め、実際のレベルを設定するのはユーザー、ハーネス、または実行者です。
• 恒久的な仕組みの説明文では、具体的なモデル製品、ベンダー、バージョンを挙げてはいけません。
• 規模よりリスクを優先します。1ファイルの変更でもリスクが高ければ frontier が適切な場合があります。一方、広範囲に及ぶ機械的な名前変更でも、検証が完了していれば fast + thorough のままでよい場合があります。
• 検証は別のものです。より高いティアや労力を選んでも、テスト、レビュー、コマンド出力、手動 QA、その他の証拠を代替することはありません。
• 判断対象となった作業を実行したり、設定を変更したり、別のモデルを呼び出したり、プロバイダー設定を変更したりしてはいけません。
• ユーザーが明示したティアや労力の選択を上書きしてはいけません。不一致が確認できる場合は報告します。

出力

recommended_tier: fast|standard|frontier
recommended_effort: glance|measured|thorough|exhaustive
rationale: <one sentence, covering both dials>
move_up_if: <signals that would justify a stronger tier or higher effort>
move_down_if: <signals that would justify a cheaper tier or lower effort>
proof_surface: <verification still required, independent of tier and effort>

検証

完了する前に、報告内容が次の条件を満たしていることを確認します。

• ティア（fast／standard／frontier）を1つ、労力（glance／measured／thorough／exhaustive）を1つだけ挙げている。
• どちらも最強のものではなく、必要十分な最も低コストのティアと、作業を満たす労力を示している。
• 2つの調整項目それぞれについて、上げる場合と下げる場合の条件を示している。
• 証拠となるものを明示している。
• ルーティング、切り替え、プロバイダー、ベンダー、製品、バージョン、具体的なレベルに関する主張を含まず、認知コストに関する2つの調整項目以外のオーケストレーション項目を挙げていない。