AIのSkillは会社の仕事を持ち運べるのか｜SKILL.mdで移せるもの、移せないもの
生成AIを仕事で使っていると、同じ説明を何度も書く場面があります。
「この資料を先に読む」「この順番で作業する」「ここでは人間の確認を待つ」といった、繰り返し使う仕事の手順です。
最近、この手順をAIが再利用できる形でまとめる「Skill」という仕組みが広がっています。
Skillは、AIに特定の仕事の進め方を覚えさせる再利用可能な指示セットです。たとえば、記事制作の手順、調査の順番、出力形式、停止条件などをまとめておき、必要なときに読み込ませます。
僕自身も、このサイト「海辺の部屋」で、Blog制作とKnowledge制作の手順をSkillとして切り出して運用しています。2026年9月には、作成したKnowledge用SkillのSKILL.md本文が標準レビュー画面で保持されていることも確認しました。
では、Skillをファイルとして持てるようになれば、会社の仕事も別のAIへそのまま持ち運べるのでしょうか。
調べるほど、答えは「一部は持ち運びやすくなる。でも仕事全体は別」です。
まず、Skillで持ち運びやすいのは「手順」
Googleは2026年、GeminiアプリとGoogle Workspaceで使うカスタム指示を、GemsからSkillsへ移行すると発表しました。
Googleの公式ヘルプでは、Skillsを会話やワークフローへ再利用できるモジュール式の指示と説明し、オープンなMarkdownベースのSKILL.md形式を使うとしています。
Markdownは、見出しや箇条書きを普通のテキストで表現できる形式です。つまり、Skillの中心部分は特殊なデータベースではなく、人間にも読める指示ファイルとして外へ出しやすい。
Googleは、この形式によってツール間で指示を作成・カスタマイズ・転送しやすくなり、プラットフォームへの固定を減らせると説明しています。
たとえば、毎月行う競合調査なら、何を調べるか、どの資料を先に読むか、どう比較するか、どの形式で結果を残すか、といった手順は文章にできます。
ここはSkillとして持ち運びやすい部分です。
ただし、同じGoogleの中でも自動では移らない
一方で、Google自身の説明にも重要な但し書きがあります。
2026年10月7日時点では、GeminiアプリのSkillsとGoogle Workspace側のSkillsは同期されません。両方で使う場合は、Workspace Studio側で手動で作り直す必要があります。
Google WorkspaceでのSkillsのロールアウトは10月5日に始まり、Geminiアプリ側は10月13日から始まる予定です。
つまり、オープンな形式になったからといって、同じ会社の別サービス間ですら、設定や運用状態まで自動で移るわけではありません。
形式が共通であることと、仕事が自動的に移植されることは別です。
会社の仕事を4つに分けると分かりやすい
僕は、AIへ渡す仕事を少なくとも4つに分けて考えると、この違いが見えやすいと思っています。
1．手順
何を、どんな順番で、どんな条件で進めるか。SkillやSKILL.mdで最も外へ出しやすい部分です。
2．データ
顧客情報、商品マスター、社内ルール、過去の作業状態、記事データ、会話記録などです。Skillを別のAIへ渡しても、元データまで自動で移るわけではありません。
3．権限と接続先
Google Driveを読めるのか、CMSを書き換えられるのか、メールを送れるのか、AWSのAPIを実行できるのか。これは手順ファイルではなく、実行環境側の設定です。
4．検証基準
どこまで終われば「完了」なのか。保存できればよいのか、公開ページまで確認するのか、人間承認が必要なのか。ここが違えば、同じ手順でも結果は変わります。
この4つを一つにまとめて「AIの仕事」と呼ぶと、Skillをコピーしただけで全部移ったように見えてしまいます。
でも実際には、持ち運びやすさが違います。
AWSのSkillも、実行には環境と権限が必要
AWSの2026年10月5日の公式発表にも、この違いがよく表れています。
Amazon SageMaker AIは、生成AIの推論最適化を支援する「aws-ai-ml」というSkillを公開しました。Kiro、Claude Code、Codexなど、MCPに対応する複数のコーディングエージェントで利用できると説明しています。
これは、同じSkillを複数のエージェントへ持ち込める具体例です。
ただしAWSは同じページで、SageMaker APIを呼び出すためのAWS認証情報と権限が必要だとも明記しています。
Skillがあっても、そのAIに実行権限がなければ仕事は進みません。
さらにAWSはAmazon Bedrock Managed Agentsについて、AIを企業環境で動かすとき、既存のidentity、permissions、governance controlsと統合して使う仕組みを説明しています。
AIの能力やSkillだけではなく、「誰として、何へ、どこまでアクセスできるか」が仕事の一部になっています。
レシピを持って別の厨房へ行くのに近い
僕は、Skillの可搬性を料理のレシピに近いものとして考えています。
レシピは別の厨房へ持っていけます。作る順番や必要な材料も書けます。
でも、移動先に同じ材料があるとは限りません。同じ調理器具があるとも限らない。その器具を使う許可があるかも別です。
完成した料理を誰が合格と判断するのかも、レシピだけでは決まりません。
Skillが持ち運ぶのは、主に「どう作るか」。仕事全体には「何を使えるか」「何を読めるか」「何をもって完成とするか」も付いています。
僕自身のSkill運用でも、手順だけでは足りなかった
海辺の部屋でも、Blog制作やKnowledge制作の手順をSkillとして分離しています。
ただ、Skillの本文だけ読めばすべての仕事が完了するわけではありません。
Blogなら、最新の作業状態をGoogle Driveで確認し、Wixの既存記事を読み、構造台帳を確認し、必要な権限で保存・公開し、最後に読み戻す必要があります。
Skillは「何を読むか」「どんな順番で進めるか」を示しますが、現在のデータそのものやWixへのアクセス権まで内包しているわけではありません。
標準化で消えるのは、ロックインの一部
だから僕は、Skillの標準化を「これでAIの仕事が完全にモデル非依存になる」とは見ていません。
むしろ価値があるのは、これまで一つのAIの中に混ざっていたものを分けやすくなることです。
手順はSKILL.mdへ出す。事実や現在地は外部データへ置く。認証と実行権限は環境側で管理する。成功条件はAIとは別に定義する。
この分離ができていれば、モデルやサービスを変えるときに、全部をゼロから作り直す必要は減らせます。
「特定のAIしかできない仕事」から、「条件をそろえれば別のAIでも再構築できる仕事」へ近づける。
僕がSkillの標準化に期待しているのは、今のところそこです。
まだ確認できていないこと
この記事では、僕自身が同一のSkillを複数の異なるAI製品へ移し、同じ業務が何％再現できたかまでは測定していません。
確認できたのは、GoogleがSKILL.mdをオープンな形式として採用し、AWSでも複数エージェントで使えるSkillの具体例が出ていること。一方で、同期、データ、接続先、認証、権限、検証条件は別レイヤーとして残ることです。
だから今後、AIのSkillを見るときは、「対応しているか」だけでなく、
何がSkillに入り、何が外部データに残り、何が実行環境に依存するのか。
ここまで分けて見る必要がありそうです。
コメント