AI スキルにもバージョン管理が要る

ブログ · 6 分で読めます

パッケージマネージャー以前、「他人のコードを使う」とはファイルを自分のプロジェクトにコピーすることでした。それでうまくいっていました — 元のファイルに修正が入り自分のには入らなくなるまでは、あるいは自分のコピーがほんの少しだけ分岐して、修正を取り込むのがもうコピー＆ペーストでは済まなくなるまでは。コードについては数十年前に解決しました。スキルはいままさに、まったく同じ問題を、たいていは解決策なしで経験しています。

周りに聞いてみれば、どこでも同じ光景が見つかります。プルリクエストのレビュー用のよいプロンプトがプロジェクト A に貼られ、そこでもうまくいったからとプロジェクト B にも貼られ、別の言語向けに 2 行だけ変えて 3 度目が貼られる。それはもうひとつのスキルではありません。共通の祖先を持つ 3 つのプロンプトであり、半年後にどれが「本物」なのか、A に入れた修正が C に届いたことがあるのかを知る手立てはありません。

コピー＆ペーストが実際に払わせる代償

• 修正が伝わらない。 Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• 差分がない。 When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• 巻き戻しがない。 A change that turns out to be wrong has already overwritten the version that worked.

どれも、スキルを他のスキルから組み立てるのをやめる理由にはなりません。テストの考え方を 5 つの言語別スキルで共有すること、社内スタイルガイドを十数個のより具体的なスキルで共有することは、まさにやる価値のある再利用です。これらはむしろ、共有される部品にコード依存と同じ規律 — 本物のバージョン、宣言された制約、そして「最新」が意味を持つ場所 — が必要だという理由です。

パッケージマネージャーのモデルを、指示に当てはめる

スキルをテキストの塊ではなくパッケージとして扱えば、この種の問題はコードのときと同じようにまるごと消えます。

• スキルにはバージョンがある。変更すれば、バージョンも変わる。
• 別のスキルは、内容を埋め込む代わりに制約付き（>=1.0.0）で依存できる。
• 依存側の更新を公開すれば、それを解決するすべての依存スキルが更新される — コピー探しは不要。
• あるバージョンを非推奨にしても、そこに固定されているものは壊れない。
• 意図的な分岐はフォークとして記録され、追跡できないコピー＆ペーストにはならない。

これは npm、pip、cargo と同じかたちです。スキルがコードだからではなく、「時間とともに変わる共有物に多くのものが依存する」という問題が、ファイルの中身が何であれ同じだからです。

貼り付けたテキストとしてしか存在しないスキルには系譜がありません。バージョン管理され、組み合わせ可能なスキルには、実際に筋道を追える履歴があります。

試してみる

チュートリアル Compose and version skills like code では、依存の宣言、すべての依存スキルが取り込む更新の公開、そして出自を見失わずにスキルをフォークする方法を扱います。