SkillOpsとは：Googleの事例に見るAgent Skillの運用と保守
この記事で学べること
- Googleの公開事例と、研究論文で提案されたSkillOpsの共通点・違い
- Skillの有無による、回答の正確性や作業効率の比較方法
- 修正担当、自動チェック、定期評価を組み合わせた運用の基本
SkillOpsの基本：作成から保守までの継続管理
Agent Skill（AIが仕事を進めるための手順や知識をまとめたもの）は、作成して公開すれば終わりではありません。接続先のサービスやAIモデルが変わると、以前はうまく動いていた手順が使えなくなることがあります。Skillが増えれば、誰が修正するのか、どの版を配布するのかも決める必要があります。
SkillOpsは、こうしたSkillの作成・公開・評価・保守を、一連の運用として管理する方法です。
Google Cloudの公開事例では、Skillを継続的に管理する資産として扱っています。本記事では、この事例と研究論文をもとに、誰が更新を担い、何を確認して公開し、その後の品質をどう保つのかを整理します。自分の組織に合う運用を考えるための判断材料として紹介します。
Googleの公開事例と「SkillOps」の位置づけ
Google Cloudは「Behind the scenes: How we build, test, and scale Google Agent Skills」という記事で、運用の舞台裏を公開しています。Google Agent Skillsは、Google Cloudなど特定分野の知識を、AIが利用できる共通形式にまとめて一般公開したものです。[1]
Googleが「SkillOps」という製品や新しい標準を発表したわけではありません。公式記事が説明しているのは、Skillの品質管理、評価、公開、担当者の責任です。本記事では、その実践をSkillOpsの事例として読み解きます。
一方、「SkillOps」という名称は、Hongji Pu、Xinyuan Song、Liang Zhaoが2026年5月13日に公開した研究論文でも使われています。この論文は、Skillの集まりに重複や古い手順が蓄積する問題を扱い、日々の利用とは別にSkill全体を保守する方法を提案しています。[2]
Googleの公式記事と、この研究論文は別の発表です。両者の考え方には共通点がありますが、同じ取り組みとして扱わないよう注意が必要です。
Skillの拡大に伴う品質管理の課題
Google Agent Skillsは、Google Cloud Next 2026に向けた部門横断チームの取り組みとして始まりました。中心となったのは、開発者向けに情報を発信する担当者と、技術文書の担当者です。公開後はCloud以外の製品チームからもSkillを提供したいという声が上がり、品質を保ちながら参加者を増やす必要が生じました。[1]
Googleが挙げている問題は、曖昧な指示、リンク切れ、想定されていない例外条件です。不十分なSkillが1つあるだけでも、AIエージェント（依頼に応じてツールを使い、作業を進めるAI）の動作や使い勝手に影響します。
そこでGoogleは、Skillの追加を自由な文書投稿として扱わず、共通ルール、変更ごとの自動検査、継続的な配布と評価、担当者の責任を組み合わせています。[1]
運用の対象は、SKILL.md（Skillの名前・説明・手順などを書くファイル）の書き方だけではありません。誰が変更できるか、何を確認すれば公開できるか、接続先のサービスやAIモデルが変わった後も正しく動くかまで含まれます。
Googleの運用を支える6つの仕組み
Googleが公開した運用は、次の6つに整理できます。[1]
| 仕組み | Googleの実践 | 防ぎたい問題 |
|---|---|---|
| 共通の形式 | フォルダー構成と命名ルールの統一 | チームごとに形式が異なり、必要なものを探しにくくなること |
| 外部ツールとの接続 | remote MCPを優先し、対応できない場合に限ってパソコンからの直接操作やサービスへの個別接続を利用 | 認証情報や権限の管理先が増え、独自の接続方法が乱立すること |
| GitHubへの公開 | 社内で作成・確認した内容から、公開可能なものだけを自動で公開 | 社内資料、担当者情報、テスト用データの誤公開 |
| 変更時の自動チェック | 基本情報、名前、配置、リンク、安全上のルールの確認 | リンク切れ、存在しないURL、形式の崩れの見落とし |
| 定期的な効果確認 | 提出時と毎週、Skillなし・ありの結果を比較 | 接続先サービスやAIの変更による品質低下 |
| 修正担当の明確化 | 全体の管理者と個別Skillの担当者の分担 | 問題が見つかっても修正されない状態 |
remote MCP（ネットワーク経由でAIを外部ツールに接続するための共通の仕組み）を使うと、認証と権限をまとめて管理しやすくなります。GitHubは、ファイルや変更履歴を管理・共有するサービスです。
ただし、形式のチェックだけでは、Skillを公開してよいか判断できません。Lint（文章やファイルが決められた形式に従っているかを機械的に調べる検査）に合格しても、回答が正確になるとは限らないからです。
Googleは、「形式が正しいか」と「実際に使って効果があるか」を分けて確認しています。
社内版をもとにした公開版の自動生成
Googleは、まず社内でSkillを作成・評価します。その後、決められたルールに従って必要なファイルを抽出し、一般公開用のGitHubリポジトリ（ファイルと変更履歴の保管場所）へ送ります。このとき、社内資料、社内の担当者情報、テスト問題一式は取り除きます。[1]
この設計では、社内版を管理の基準にして公開版を生成することで、社内の運用に必要な情報と、外部に配布する情報の境界を保ちます。
実務に当てはめると、次のような流れになります。
- 社内の保管場所で、Skill、修正担当、テスト、非公開の参照資料を管理する
- 変更提案を取り込む前に、形式と実際の動作を確認する
- 公開可能なSKILL.md、スクリプト（処理を自動実行するプログラム）、参照資料だけを抽出する
- 公開先でも、秘密情報や内部リンクが含まれていないことを再確認する
公開先には、Skillの配布に必要な内容だけを置きます。ただし、公開版だけでは保守責任者や評価条件が分かりません。どの公開版が社内のどの管理記録に対応するかは、後から確認できるようにしておく必要があります。
Skillの有無による正確性と効率の比較
Googleでは、Skillの著者が複数のテスト問題を用意します。各問題には、AIへの依頼文と期待する結果を含めます。同じ問題をSkillなし・ありで実行し、回答の正しさと作業効率を比べます。[1]
効率の評価対象は、トークン数（AIが処理した情報量の単位）と、作業が完了するまでの時間です。また、異なるエージェント基盤で複数回試し、結果に統計的な意味があるかも確認します。[1]
正確性と効率の組み合わせから、結果は次の4つに整理できます。Googleが公開した2×2の評価軸をもとにした、本記事での判断例です。[1]
| Skillなしと比べた結果 | 結果の意味 | 本記事での判断例 |
|---|---|---|
| 正確性も効率も向上 | Skillの効果が分かりやすい | 公開候補にする |
| 正確性は向上、効率は低下 | 品質は上がるが、処理量や時間が増える | 高い正確性が必要な業務などに適用範囲を絞る |
| 正確性は低下、効率は向上 | 速くなる一方で、品質に問題がある | 期待する結果や手順を見直す |
| 正確性も効率も低下 | 導入効果が見られない | 公開を止め、再設計や廃止を検討する |
たとえば、Cloud Run（Google Cloudでアプリケーションを実行するサービス）へ安全に公開するSkillを考えてみます。「エラーなく処理が終わった」だけでは、安全に公開できたかは分かりません。
テストでは、次のような条件を期待する結果として明示します。
- 必要最小限の権限で動作すること
- 指定したリージョン（サービスを稼働させる地域）を使うこと
- 公開後の稼働を確認できること
- 禁止された公開設定が含まれないこと
そのうえで、Skillを使った場合に、これらの条件をより正確に満たせるかを測ります。
これはGoogleの記事の評価方法を実務に当てはめた例です。Googleが公開した個別のテストケースそのものではありません。
継続保守の責任と作成支援の役割
Googleは「Skills are products, not snippets」という考え方を示しています。Skillを短い文章として置いておくのではなく、継続して管理する製品として扱うという意味です。[1]
その責任は、全体の管理者と個別Skillの担当者に分かれます。
| 担当 | 主な責任 |
|---|---|
| 全体の管理者 | Skillの保管場所、共通の自動チェック、設計ルールの管理 |
| 個別Skillの担当者 | 担当するSkillの長期保守、接続先サービスの変更への対応、週次評価で見つかった品質低下の修正 |
作成を支援する仕組みもあります。Googleは、著者を支援する内部向けSkillを用意しています。さらに、ADK（Agent Development Kit：AIエージェントを開発するためのツール群）を使い、複数のエージェントが作成と自己批評を行うワークフローも構築しています。[1]
また、一般公開しているGoogle Agent Skillsとは別に、社内で「DevRel Skills」を運用しています。DevRel（開発者との関係づくりや情報発信）の業務に使うSkillで、コンテンツ変換、SEO（検索エンジンで情報を見つけてもらいやすくするための最適化）、社内レポートなどを標準化しています。[1]
Skillは、外部ユーザー向けの製品知識だけでなく、社内の標準的な作業手順にも使えるということです。
ただし、AIにSkillの下書き作成や自己批評を任せても、Owner（更新や廃止に責任を持つ担当者）や評価ゲート（公開に進むための確認・合格条件）は必要です。自動生成と自己批評で作成を速めながら、人とテストによって公開の可否を判断する、という役割分担が求められます。
研究版SkillOpsとの共通点と違い
研究論文のSkillOpsは、Skillを使う際の条件や期待する結果を、契約書のように明確に記録します。記録するのは、使える条件、実行する処理、成果物、確認方法、既知の失敗条件です。[2]
加えて、Skill同士の関係も管理します。あるSkillが別のSkillを必要とする関係、互いに置き換えられる関係、内容が重複する関係などです。
保守の進め方にも特徴があります。目の前の仕事で起きた問題への対応と、Skill全体の重複整理・修正・廃止を、別の流れとして扱います。[2]
| 観点 | Googleの公開事例 | 研究論文のSkillOps |
|---|---|---|
| 主な対象 | 組織での作成、確認、評価、公開、担当分け | Skill全体に蓄積した重複や古い手順の診断・保守 |
| Skillの記述方法 | 共通のフォルダー構成と指示形式 | 利用条件、処理、成果物、確認方法、失敗条件の明示 |
| 品質の確認方法 | 形式やリンクの検査、AIによる補助確認、実際の動作確認 | 有用性、重複、共存の可否、確認不足の診断 |
| 保守のタイミング | 提出時と週次の効果確認 | 個別の仕事への対応と、Skill全体の保守を分離 |
| 保守を担う主体 | 全体の管理者と個別Skillの担当者 | 保守用の仕組みと、既存のAIエージェント |
共通するのは、Skillを一度書いて終わるプロンプト（AIへの指示文）として扱わず、関連するサービスやツールの変化に合わせて検証・更新する点です。
一方、Googleの記事は実際の組織運用を説明し、論文はSkill同士の関係や自動保守を一定のルールで表現しています。Googleが研究論文のSkillOpsを採用したと確認できる記述はありません。
小規模な導入に必要な運用項目
Googleの事例と研究提案を踏まえると、最初から多くのSkillを対象にするより、1つのSkillから運用を整える方法が現実的です。確認する項目は、次の順序で整理できます。
| 項目 | 決めること・確認すること |
|---|---|
| 1. 担当者と利用目的 | 更新と廃止を誰が判断するか、何のために使うか |
| 2. 変更時の静的検査 | SKILL.md先頭の設定情報（frontmatter）、命名、構造、リンク、含めてはいけない情報の確認 |
| 3. Skillなし・ありの比較 | 正確性、AIが処理した情報量、完了時間の比較に使うテストケース |
| 4. 定期的な再評価 | 週次または月次での、API・モデル・エージェント基盤の変更による品質低下の確認 |
| 5. Skillの管理台帳 | 重複、互換性、失敗の記録と、統合・修正・廃止の判断 |
| 6. 社内版と公開版の分離 | 公開対象の抽出ルールと、情報漏えいを防ぐ自動検査 |
静的検査は、Skillを実際に動かさず、ファイルの内容や構造を調べることです。APIは、ソフトウェア同士が機能やデータをやり取りするための接続口です。
このサイトでは、共有Skillをshared/skills/で管理し、npm run harness:checkというコマンドで、Skillと実行環境向け設定の整合性を確認しています。
次の改善候補は、各Skillに担当者、評価用プロンプト、期待する結果、前回の評価日をひも付け、Skillなし・ありの差を継続的に記録することです。
これはGoogleの内部実装を再現するものではありません。公開された運用原則を、このサイトのハーネス（AIへ渡すルール、手順、検証をまとめた基盤）に適用する案です。
公開情報の限界と導入時の留意点
Googleの記事から運用の方針は分かりますが、実装や評価の詳細まですべて分かるわけではありません。次の情報は公開されていません。[1]
- 評価に使うモデル、合格基準、評価件数
- 週次の自動評価処理の実装
- 担当者が交代する際の手順
- 個別Skillの改善率やトークン削減率
正確性と効率を組み合わせた4区分の評価について説明されていても、Skillごとの変化量は示されていません。
研究版SkillOpsは、ALFWorldを使った評価で、200個のSkillがある条件のタスク成功率を79.5%と報告しています。ALFWorldは、家庭内の作業を文章で模した環境で、AIのタスク遂行能力を測るベンチマークです。
この数値は、3つの異なるseed（評価用Skill群を作る際の初期値）について各185タスクを評価した平均で、最も成績の良い比較手法を8.8ポイント上回りました。[2]
ただし、この結果をGoogleの運用や一般企業の業務にそのまま当てはめることはできません。公開事例を参考にしつつ、自分たちのSkillと業務に合う評価基準や保守周期を決め、小さな範囲で比較する必要があります。
まとめ：Skillの品質を支える比較評価と保守体制
本記事でいうSkillOpsは新製品の名前ではなく、Skillの作成・公開・評価・修正・統合・廃止を継続的に管理する運用です。Googleの事例と研究論文には、Skillを増やすだけでなく、使い続けるための品質管理を重視するという共通点があります。
その判断の土台になるのが、Skillなしの結果との比較です。接続先のサービスやAIモデルが変わった後も再評価し、効果が続いているかを確かめます。
導入を考える際は、影響範囲を限定できるSkillを1つ選び、担当者、比較の基準となる結果、期待する結果、再評価日を記録することが出発点になります。合格基準や担当交代の条件は、自組織の業務とリスクに合わせて決めます。こうした評価と保守の体制があってこそ、Skillの数を増やしながら品質も維持できます。
参考文献
- Remigiusz Samborski, Behind the scenes: How we build, test, and scale Google Agent Skills, Google Cloud Blog, 2026年8月3日
- Hongji Pu, Xinyuan Song, Liang Zhao, SkillOps: Managing LLM Agent Skill Libraries as Self-Maintaining Software Ecosystems, 2026年5月13日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。