グローバルスキル管理リポジトリを作ろう AIエージェントの手順を持ち運ぶ

AIエージェント用のグローバルスキルをGitで管理し、変更履歴、レビュー、ロールバック、複数端末同期を扱える作業資産にする考え方を整理します。

この記事の要点

AIエージェントのグローバルスキルは、使い込むほど手放せなくなる。レビューで見る観点、PR本文の組み立て方、調査メモの残し方、セッションの引き継ぎ方。毎回口頭で説明していた手順が、いつのまにかエージェントの初期装備になっている。

厄介なのは、ホームディレクトリに置いたまま育ててしまうことだ。気づくとどれが最新版か分からなくなる。別の端末へコピーしたとき、古いファイルが紛れ込む。挙動がおかしくなっても、いつのどの変更が原因なのか追えない。

仕事の進め方そのものを支える土台になっているのに、その土台が誰の目にも見えない場所に積み上がっていく。これが運用上の弱点になる。

グローバルスキルをGitで管理するといっても、気に入った指示文を集めておく場所をつくる話ではない。入れるのは、作業手順、動作を確かめるコマンド、避けたい表現、レビューで見る観点、サンプル入力、そしてうまくいかなかったときの戻し方だ。

READMEには、何をどこへ同期するか、どのCLIにインストールするか、どのファイルを「生成物」として扱うかを書く。スクリプト類には、コピーやシンボリックリンクを張る手順を置く。変更履歴には、なぜその手順を変えたのかを書き添える。

ここまで整えると、スキルは個人の勘ではなく、差分を見ながら直せる対象になる。

Gitで管理する価値は、バックアップが取れることだけではない。手順を変えた日付、ある表現を禁止に回した理由、確認コマンドを足した背景が、変更履歴として残る。

エージェントの挙動が急に変わったとき、モデルだけを疑っても原因にはたどり着けない。実際には、説明文を少し書き換えた、スキルが発動する条件を広げすぎた、古いテンプレートを消し忘れていた、といった理由のことが多い。こうした変化は、履歴に残っていれば突き止められる。

元に戻せることも効いてくる。壊れた手順をその場で削るのではなく、どの変更で壊れたのかを一つずつ戻しながら確かめられる。

リポジトリに入れてよいのは、繰り返し使える段取りだ。skillsディレクトリ、インストール手順、確認用のチェックリスト、サンプルプロンプト、PR本文のテンプレート、引き継ぎファイルの雛形。

入れてはいけないのは、認証情報と現場固有の秘密だ。APIキー、OAuthトークン、個人のメールアドレス、顧客名、未公開案件の指示、その端末にしかない絶対パス。便利な手順ほど、関連する秘密をすぐ隣に置きたくなるので、ここは意識して分ける。

公開リポジトリにするのか、プライベートにするのか、社内Gitに留めるのかは、また別の判断になる。すべてをGitHubに出す話ではない。

グローバルスキルをチームで共有しはじめると、もう一段の切り分けが要る。個人用には作業者ごとの癖が混ざる。チーム用には、合意の取れた手順だけを残す。プロジェクト用には、そのリポジトリの公開ルールと品質基準を入れる。

この切り分けがないと、個人が速く動くための手順が、いつのまにかチームの標準のように扱われる。逆に、あるプロジェクト固有の制約がグローバルへ漏れ出し、別の現場で不要な縛りとして効いてしまう。

スキルの数を増やすこと自体に意味はない。狙いは、同じ作業を、誰がやっても同じ粒度で始められる状態をつくることだ。

AIエージェントの出力は、モデルの良し悪しだけで決まるわけではない。どの手順を読み、どのツールを使い、どの確認で立ち止まるか。この外側の仕組みが、結果の安定度を左右する。

グローバルスキルをひとつのリポジトリにまとめておくと、その外側の仕組みごと持ち運べる。端末を入れ替えても、CLIを乗り換えても、積み上げた手順は残る。AIの使い方を、目の前の会話の中だけに閉じ込めずに済む。

閉域AI、社内データ活用、拠点間ネットワーク、音声・録音データ、クラウド接続など、AIを業務環境に組み込むためのインフラ構成についてご相談ください。

既存ネットワーク、PBX、データセンター、業務システムとの接続を前提に、実装しやすい構成を整理します。

要件を相談する