更新しても比較できる運用を作る

教材、Skill、実験の版を分けて管理する。

学習時間の目安: 60 分.

1. 1モデルやSkillの変更
2. 2影響の確認
3. 3同じ回帰確認用入力
4. 4継続・修正・削除

独自の学習図。矢印は読み進める順序や判断の流れを表し、実測した実行traceではない。

前提となる章

• 差分を読み、実験台帳へ残す

根拠と演習の状態

本章は編集された学習ガイドです。出典を読んだこととSkillを実行して効果を測ったことを分けます。演習は未実施：not-run。実験ログやモデル出力はありません。

学習目標

• 版・参照先・回帰テストを管理できる
• Skillの廃止や縮小を判断できる

仕事の役割

• 学習者：仮説と採点基準を決める
• AI：承認された範囲の読取りと成果物作成を補助する
• レビュー担当：成果とログを分けて確認する

入力

• この章で指定した入力例
• 確認する公式資料と版

三つの版を分けて保存する

最低限、教材・Skill・実験を別の版として管理する。教材の誤字修正は実験の条件変更ではない。一方、Skill本文の一語の変更、参照資料の更新、モデル切替、実行環境の変更は挙動を変える可能性がある。比較を継続したいなら、これらを一度に更新しない。台帳では旧版を上書きせず、新しいrun IDで追記し、どの版に戻せるかを残す。

差分レビューの優先順位

更新時には、何ができるようになったかより先に、外部送信先、権限、実行スクリプト、依存関係、フック、ライセンスの変更を見る。次に起動説明、出力形式、失敗時の挙動を読む。古いプロジェクトの慣習を新しいSkillが上書きすることもあるため、既存ワークフローの代表例を回帰テストへ入れる。自動更新を便利さだけで選ばず、固定版の利点と更新漏れの危険を比較する。

小さく維持する

似たSkillを三つ並べるより、役割を分けて名前と説明を明瞭にする。会社固有の規約、一般的な作業手順、最新仕様へのリンクを一枚に詰め込むと更新理由が混ざる。変更頻度や責任者の違う資料は分ける。繰り返し同じ補助コードを生成するなら、レビュー済みのスクリプトとして共有する余地があるが、その分依存と安全性の保守が増える。手順の文章化は保守を不要にするわけではない。

なくす判断も成功である

同じモデルと代表課題でSkillを外しても品質が保たれ、時間や失敗が減るなら、削除・短縮・限定起動を検討できる。最初に役立ったから永久に必要とは限らない。逆に普段は効果が見えなくても、稀な高コストの失敗を防ぐ場合は平均だけで判断しない。維持判断には利用頻度、修正コスト、対象外での誤起動、重大な失敗の観測を使い、「Skillの数」を成果指標にしない。

制作・検証の工程

1. 変更時に必ず見る安全項目を5つ選ぶ
2. 起動の正例・負例と品質の回帰課題を決める
3. 採用・保留・旧版維持・廃止の条件を書く

出力

• Skill更新のレビューシート

品質チェック

• 参照資料も版管理の対象
• 動作変更と教材修正が区別できる
• 廃止条件を決めた

失敗の切り分け

• 症状: 効果を観測していないのに成功と記録する
• 原因: 期待判定と実際の出力を混同した
• 対処: 未実施はnot-run、実測欄は空欄に戻し、原出力とログを取得してから採点する

演習: 更新ゲートを作る

上の工程を順に行い、上記の成果物を作ります。

完了条件: 版を上書きしない方針と、権限変更時の停止条件がある

Status: not-run.

出典が支える範囲

出典は本文やカタログの機能・配布元表示を支えます。実測効果や人気順位の根拠ではありません。確認日は公開資料を読んだ日で、公開日・更新日とは異なります。main 等の可変参照は厳密な実験用固定版ではありません。

手元の実験記録テンプレート