Agent Skills の AAIF 移管で考える、チームの仕事の進め方は持ち運べるか

概念イラスト：方法は持ち運び、道具とアクセスの鍵は別に用意する。

顧客の利用開始資料を AI に確認してもらう方法が、何度か調整してようやく落ち着いたとする。リストと添付を読み、不足を挙げ、日付が違えば両方を残す。ところが Agent 環境を変えると、スクリプトも添付も見つからず、「完了」の意味まで変わってしまった。また一から説明することになる。

何が欠けたら止めるのか、どの日付を見るのか、誰に渡すのか。その細かい取り決めは、次の人も使える形で残しておきたい。道具が変わっても、せっかく合わせた仕事の進め方まで忘れずに済むように。

Anthropic は 2026 年 10 月 22 日、Agent Skills 標準の AAIF への寄贈を発表した。開かれた形式は方法を保存・共有しやすくする。移した先で使うには、中を開いて何に依存していたかも見ておこう。

方法、環境、認可を別々に準備する

顧客の利用開始資料を確認し、不足を挙げて担当者への質問を作る仕事を例にする。

Skill フォルダーには SKILL.md、スクリプト、参考資料を入れられる。パスワード、生のトークン、実顧客の添付を一緒にしない。説明の共有ではアカウント権限は移らない。

暗黙の経験を点検できる規則にする

持ち運びにくいのは、慣れているからこそ書かなくなった部分だ。「契約の日付を確認する」とは署名日か利用開始日か。食い違ったら止めるのか、担当者に聞くのか。答えが古い会話にしかなければ、新しい同僚にも Agent にも分からない。

資料完備、追加情報が必要、記録が矛盾、という結果を定義し、元の識別子、出典、確認事項を指定する。言い回しは変わっても判断根拠は残す。

Leina は有効な方法を Skill に残し、認可済み Apps で使える。Skills 一覧で必要な Apps と導入方法を読み、実環境で適合を試す。

flowchart TB
  accTitle: アカウント権限をコピーせず方法を移す
  accDescr: 方法と匿名サンプルを移行先へ渡し、道具と認可を設定して検証してから実務に使う。
  A("方法と匿名サンプル"):::resource --> B("移行先 Agent 環境"):::agent
  B --> C("道具と依存関係を用意"):::gateway
  B --> D("アカウント認可を別途設定"):::restricted
  C --> E("サンプルと照合"):::gateway
  D --> E
  E --> F("検証後に実タスクを実行"):::resource

問題を見つけるサンプルも持参する

理想の一件だけでは移行成功の証拠にならない。匿名化した完備例、添付不足、日付矛盾、番号重複を用意する。

旧回答の復唱ではなく期待結果を記録する。出典を残す、不足を名指す、矛盾する両記録を示す、重複を上書きしない、といった条件だ。

読めない情報源、スクリプト失敗、書き込み権限なしも試す。未完了の手順を示し、一部の結果を全件成功としない。顧客資料を公開テスト集にする必要はない。

Leina で最小タスクを再構成する

この顧客資料 Skill の Apps、操作、スクリプト、ローカルパス依存を列挙して。実顧客資料を読んだり記録を変更したりせず、提供した匿名サンプルと期待結果を照合して。流用できる方法、書き換える道具の手順、不足権限を分け、初回の実務範囲を説明して。

導入は移行先の説明に従う。CLI や特別なプラグイン、Python パッケージを使うなら、依存関係を用意したり同じ工程を別の道具で書き直したりすることもある。フォルダーをコピーした後に何が足りないかは、サンプルで確かめられる。

接続後は読み取りだけで試し、表への書き戻しや送信は対象、権限、確認方法を別に確かめる。

担当者と変更履歴を残す

複数人が使う方法には説明できる管理者が必要だ。管理者、版の説明、最終検証日、変更した業務ルール、再実行したサンプルを残す。

顧客項目、コネクター操作、依存更新で旧手順が使えなくなることもある。実資料の前にサンプルを再実行する。文書やリポジトリで履歴を管理でき、全 Agent の管理画面が同じとは限らない。

まずは使い慣れた顧客資料の確認を一つまとめよう。次の同僚が説明を読み、自分の認可済みアカウントを接続し、サンプルで期待した結果を得て実務に戻れたら、調整に費やした時間も次につながる。