Copilot CLI自動モデル選択とgh skillを同時に統制する運用設計

GitHubは同じ週に、運用面で強く連動する2つの変更を出しました。Copilot CLIの自動モデル選択と、gh skillによるエージェントスキル管理です。

Copilot CLI auto model selection（2026-04-17）
Manage agent skills with GitHub CLI（2026-04-16）

どちらも「便利機能」として導入すると、数週間でコストと統制が崩れます。正しくは、これは開発体験の話ではなく制御プレーン設計です。

何が難しくなるのか

従来は、モデル指定が明示的で監査しやすい代わりに運用が重い状態でした。gh skill以前は、スキル管理がローカル慣習や私製スクリプトに分散しがちでした。今回の変更で、モデル解決とスキル供給の両方が動的化されます。動的化された運用には、固定的なガードレールが必要です。

主なリスクは3つです。

モデルドリフト: 同じプロンプトでも時期で実行モデルが変わる。
コスト不透明化: autoは可用性を最適化するが、社内予算ポリシーを最適化するとは限らない。
スキル由来リスク: 便利なスキルでも、供給元と更新経路が管理されていなければ危険。

推奨アーキテクチャ

次の4層で整理すると、設計が破綻しません。

Policy層: 組織レベルのモデル許可範囲、スキル供給元許可範囲。
Execution層: Copilot CLI/gh CLIの実行経路（ローカル、CI）。
Evidence層: 解決モデル、課金係数、導入スキルバージョンの証跡。
Response層: 差し止め、固定化、ロールバック手順。

要点は、これをチャット設定ではなく依存関係管理として扱うことです。

実装手順

1. 「バージョン固定」だけでなく「方針固定」を行う

リポジトリ単位でポリシーファイルを置き、最低限以下を定義します。

許可するモデル系統
禁止するモデル系統
環境ごとの上限マルチプライヤ
許可スキルレジストリ（またはリポジトリ）

このファイルはIaCと同じレビュー強度で扱います。

2. モデル解決のテレメトリを残す

CIでCopilot CLIを使うたびに、次を記録します。

指定モード（auto/explicit）
実際に解決されたモデル
消費係数
タスク分類（テスト生成、リファクタ、レビューなど）

これがないと、FinOps会話が体感ベースになります。

3. Skill SBOMを作る

ビルド時に、エージェント用SBOMを生成します。

スキル名
供給元URL
インストールバージョン
取得時刻
利用可能なら署名/チェックサム

成果物と一緒に保存すると、障害時の追跡時間が大幅に縮みます。

4. 環境ごとに挙動を分ける

実務では次の分離が安全です。

開発環境: auto許可、広めの検証をサンドボックスで実施
ステージング: auto許可、ただし係数上限を厳格化
本番CI: 重要ジョブは明示モデル固定、スキル集合は凍結

探索速度と本番安定性を同時に満たせます。

KPIはこの5つで十分

毎週、以下を追います。

ワークロード別の解決モデル分布
チーム別のプレミアム消費
スキル更新速度
ポリシーブロック発生件数
ロールバック回数と失効までの平均時間

リクエスト数やトークン量だけを追うと、最適化対象を誤ります。

典型的な失敗

autoを「無料最適化」と誤認し、係数分布を見ない
本番ランナーで外部スキルを直接導入する
違反を個人のミスとして扱い、プラットフォーム設計を改善しない

30日導入プラン

1週目: 現行Copilot CLI利用と非公式スキルの棚卸し
2週目: 組織ポリシー適用、可視化ダッシュボード整備
3週目: Skill SBOM導入、署名付き更新経路へ移行
4週目: 障害演習（悪性スキル混入、モデル方針急変更）

30日後に目指す状態は、エージェント運用が「見える・止められる・戻せる」ことです。

参考リンク: