AIのSkillsを社内開発ガイドとして設計する
AIのSkillsは、知識を追加する箱というより、作業の前提と手順を渡す開発ガイドとして設計すると力を発揮する。
しろまえ殿がAIを開発作業へ組み込むとき、一般的なプログラミング知識を毎回説明する必要はなかった。 必要だったのは、実行環境の制約、ファイルの置き場所、確認すべき順番、組織内で守る形式だった。
まず役割を分ける
Skillsは、特定の仕事に必要な前提と進め方をまとめた文書である。 AIがもともと持つ一般知識を、別のライブラリのように追加するものではない。
たとえば新人へ「Pythonの文法」を教えるのではなく、「この組織ではテストを先に実行し、成果物をこの場所へ置く」と伝える文書に近い。 そのため、環境固有の制約や独自の作業フローを短く明記すると、説明の重複を減らせる。
しろまえ殿は、作業の種類ごとに手順書を分け、AIが着手前に該当する文書を読む形へ整理した。 役割が分かれると、同じ確認を毎回チャットへ貼り付ける必要がなくなる。
導入経路を混ぜない
Skillsには、コマンドラインの開発環境へ追加する経路と、Webサービスの設定画面から有効にする経路がある。 見た目が似ていても、保存場所と適用範囲は同じではない。
コマンドライン用の導入例としては、次のような形式がある。
npx skills@latest add <repository-or-path>このコマンドで追加した文書が、Webサービス側の設定へ自動的に現れるとは限らない。 逆方向も同じである。 導入前に「どの実行環境へ、どの範囲で適用するか」を決めると、設定漏れを追いやすい。
外部の文書は読んでから使う
外部から取得したSkillには、手順だけでなくコマンド実行の指示が含まれることがある。 便利そうに見えるからといって、そのまま本番の作業環境へ入れるのは危険である。
しろまえ殿は、導入前に次の点を確認する流れを採った。
1. 発行元と更新履歴を確認する。 2. ファイルを読み、外部通信や破壊的な操作の指示を探す。 3. まず隔離した環境で、想定した入力だけを与えて動かす。 4. 適用範囲を限定し、不要になったら外せる状態にする。
これは、他人のスクリプトを実行する前に内容を読むのと同じである。 説明文の中に「常に実行する」と書かれていても、自分の環境で必要かは別途判断する。
良い手順書は短く具体的にする
Skillsへ一般論を詰め込みすぎると、重要な制約が埋もれる。 逆に「何を、いつ、どこまで確認するか」を具体的に書けば、AIの判断を安定させやすい。
しろまえ殿の運用で有効だった項目は、次の四つだった。
- 発動する作業の条件
- 読むべき前提ファイル
- 実行前後の確認方法
- 完了とみなす条件
手順を更新したときは、実際の作業で迷いが減ったかも確認する。 古くなった前提を残すと、AIが正しい手順を踏んでも誤った結果へ進むためである。
Skillsは、AIに能力を詰め込む仕組みではない。 その場のルールを、必要なときに再現できる形へ整える仕組みである。 しろまえ殿は、一般知識と環境固有の判断を分離したことで、開発手順の見直しを続けやすくした。