公開日:

森田 嶺

【Antigravity連載③】Skillsを実際に作ってみよう!作成方法をステップごとに解説

【Antigravity連載③】Skillsを実際に作ってみよう!作成方法をステップごとに解説サムネイル画像

前回の記事では、Antigravityの「Skills」がどのような仕組みなのかを紹介しました。Skillsを簡単に振り返ると、特定の作業をするときにAIエージェントに守ってほしい手順やノウハウをまとめておける仕組みです。たとえば、普段Antigravityを使っていると、以下のような自分なりの「いつものやり方」が出てくると思います。

  • コードレビューでは、セキュリティも必ず確認してほしい
  • GASを書くときは、必ずエラーハンドリングを入れてほしい
  • READMEを作るときは、決まった構成にしてほしい

毎回プロンプトに同じ指示を書くこともできますが、それでは面倒です。こうした繰り返し利用する手順をSkillとして用意しておけば、Antigravityのエージェントが必要に応じてそのSkillを読み込み、作業に利用できるようになります。Skillは特定のタスクに対してエージェントが従う指示を記述したSKILL.mdを含むフォルダから構成されます。今回は説明だけではなく、実際にAntigravityでSkillを1つ作ってみます。この記事では、初心者でも試しやすい「コードレビュー用Skill」を例に、作成から実行までを順番に紹介します。

今回作成するSkill

今回作るのは、コードレビューを行うためのSkillです。たとえばAntigravityに、「このコードをレビューして」と依頼したとします。もちろん、そのままでもAntigravityはコードを確認してくれます。しかし、レビューの観点や出力方法をあらかじめ決めておきたいケースもあると思います。

そこで今回は、以下の観点からコードをチェックするSkillを作ります。

  1. バグにつながる可能性
  2. セキュリティ上の問題
  3. 可読性
  4. パフォーマンス
  5. 改善案

さらに、問題を指摘するだけではなく、「なぜ問題なのか」「どう修正すればよいのか」まで説明するようにします。このルールをSkillとして保存しておけば、コードレビューを行う際の基準をある程度統一できます。

Skillを作成する手順

① Skillを配置する場所を決める

まず知っておきたいのが、Skillの保存場所です。Antigravityでは、大きく分けて「Workspace Skill」と「Global Skill」の2種類のSkillを利用できます。Workspace Skillは、特定のプロジェクトだけで利用するSkillです。

<workspace-root>/.agents/skills/<skill-folder>/

一方、Globalは複数のWorkspaceから共通で利用できます。配置先は以下のパスになります。

~/.gemini/config/skills/<skill-folder>/

たとえば、特定のシステムだけで利用するコーディングルールならWorkspace Skill、どのプロジェクトでも使いたいコードレビュー手順ならGlobal Skillというように使い分けるとわかりやすいです。今回は練習も兼ねて、Workspace Skillとして作成してみます。

② Skill用のフォルダを作成する

プロジェクトのルートに.agentsフォルダを作成し、その中にskillsフォルダを作ります。さらに、その配下に今回作成するSkill専用のフォルダを用意します。今回はcode-reviewという名前にしてみましょう。最終的な構成は次のようになります。

プロジェクト

└── .agents

└── skills

└── code-review

ここで重要なのは、1つのSkillを1つのフォルダとして管理するという点です。今後Skillが増えてきた場合は、以下のような形で整理していきます。

.agents/

└── skills/

├── code-review/

├── create-readme/

├── generate-tests/

└── security-check/

Skillごとに役割を分けておくことで、後から修正したりチームで共有したりするときにも管理しやすくなります。

③「SKILL.md」を作成する

続いて、先ほど作ったcode-reviewフォルダの中に、次のファイルを作ります。

SKILL.md

最終的には次の構成になります。

.agents/

└── skills/

└── code-review/

└── SKILL.md

このSKILL.mdがSkillの中心です。AntigravityのSkillでは、このファイルに「何をするSkillなのか」「どのような手順で作業するのか」を記述します。難しそうに見えるかもしれませんが、中身はMarkdownです。つまり、プログラムを書くというより、AIエージェント向けの作業マニュアルを書くと考えると分かりやすいです。

④ Frontmatterを記述する

それではSKILL.mdを書いていきます。最初に記述するのがFrontmatterです。たとえば以下のようなフォーマットで記述します。

---

name: code-review

description: ソースコードをレビューし、バグ、セキュリティ上の問題、可読性、パフォーマンスを確認して、具体的な改善案を提案します。

---

---で囲まれている部分がFrontmatterです。ここで特に重要なのがdescriptionです。公式ドキュメントによると、descriptionは必須項目であり、そのSkillが何をするものなのか、どのような場面で利用するのかを説明する項目です。一方、nameは省略可能で、省略した場合はフォルダ名が利用されます。なぜdescriptionが重要なのでしょうか。

Antigravityでは、会話を開始するとエージェントが利用可能なSkillの名前と説明を確認します。そして、ユーザーから依頼された作業に関連するSkillがあると判断すると、そのSkillの詳しい内容を読み込みます。つまり、descriptionは単なる説明文ではなく、エージェントが「このSkillを使うべきか」を判断するための重要な情報になります。

⑤ エージェントへの具体的な指示を書く

続いて、Frontmatterの下に実際のレビュー手順を書いていきます。

今回は次のような内容にします。

---

name: code-review

description: ソースコードをレビューし、バグ、セキュリティ上の問題、可読性、パフォーマンスを確認して、具体的な改善案を提案します。

---

 

# コードレビュー

 

ユーザーのソースコードをレビューしてください。

 

## レビュー項目

 

以下の観点から確認してください。

 

1. バグや潜在的なエラー

2. セキュリティ上のリスク

3. 可読性と保守性

4. パフォーマンス上の問題

5. 改善できるポイント

 

## レビュー時の指示

 

- 問題を指摘する場合は、なぜ問題なのかを説明してください。

- 具体的な修正方法を提案してください。

- 重要度の高い問題を優先して指摘してください。

- 可読性に影響しない軽微なスタイル上の問題は指摘しないでください。

- 重大な問題が見つからなかった場合は、その旨を明確に記載してください。

 

## 出力形式

 

レビュー結果を以下のセクションに分けて整理してください。

 

### 重大な問題

すぐに修正すべき問題を記載してください。

 

### 改善点

コードをより良くするための改善案を記載してください。

 

### 良い点

適切に設計・実装されている点を記載してください。

これだけでも立派なSkillです。ポイントは、AIに対して抽象的に「いい感じにレビューしてください」と書くのではなく、何を確認し、どう判断し、どのような形式で回答するのかまで具体的に書くことです。

Skillsは魔法のようにAIの能力そのものを変更する仕組みではありません。作業に必要な手順や判断基準をエージェントへ与えることで、特定のタスクをより一貫した方法で実行させる仕組みです。そのため、Skillの品質はSKILL.mdに書かれた指示の品質にも大きく左右されます。

⑥ 実際にSkillを使ってみる

Skillを作成したら、実際にAntigravityで試してみます。たとえば、レビューしたいコードをWorkspaceに用意して、Antigravityに次のように依頼します。

このコードをレビューしてください。

Antigravityでは、ユーザーが必ずSkill名を指定する必要はありません。公式ドキュメントによると、エージェントは会話開始時に利用可能なSkillの名前とdescriptionを確認し、依頼内容に関連すると判断した場合にSKILL.mdの内容を読み込みます。Skillを確実に使わせたい場合は、Skill名を明示して依頼することもできます。

code-review Skillを使って、このコードをレビューしてください。

まずは明示的に指定して、Skillに書いたレビュー観点や出力形式が反映されるか確認してみると分かりやすいでしょう。ここまで確認できれば、最初のSkill作成は完了です。

Skillは「作って終わり」ではない

実際に使ってみると、「セキュリティのチェックをもっと厳しくしたい」「重要度をHigh / Medium / Lowで表示してほしい」「修正後のコードも提示してほしい」といった改善点が見えてくると思います。その場合はSKILL.mdを書き換えればOKです。たとえば重要度を付けたいのであれば、

重要度を以下に定義する:

- High

- Medium

- Low

と追加できます。このように、Skillsは最初から完璧なものを作る必要はありません。実際の業務で何度か使いながら、「毎回追加している指示」「毎回修正しているポイント」をSkill側へ少しずつ取り込んでいくと、徐々に自分の作業スタイルに合ったSkillになっていきます。

SKILL.mdだけでは足りなくなったら?

SkillはSKILL.mdだけでも作成できますが、より複雑な処理にも対応できます。Skillフォルダに次のような追加リソースを配置することができます。

.agents/skills/code-review/

├── SKILL.md

├── scripts/

├── examples/

└── resources/

scriptsには処理を補助するスクリプト、examplesには参考となる実装例、resourcesにはテンプレートなどのリソースを配置できます。たとえばコードレビューSkillであれば、社内のコーディング規約や良い実装例を参考資料として持たせる、といった発展も考えられます。ただし、最初から複雑な構成にする必要はありません。まずはSKILL.mdだけで小さなSkillを作り、必要になったタイミングでファイルを追加していきましょう。

良いSkillを作るための3つのポイント

最後に、Skillを作るときに意識したいポイントを紹介します。

① 1つのSkillに役割を詰め込みすぎない

Googleの公式ドキュメントでも、Skillは1つのことに集中させることがベストプラクティスとして紹介されています。

たとえば、

development-helper

という巨大なSkillを作り、その中にコードレビュー、テスト生成、README作成、デプロイ手順まで全部入れるよりも、

code-review

generate-tests

create-readme

と分けた方が、それぞれのSkillの用途が明確になります。

エージェント側も「いつ使うSkillなのか」を判断しやすくなるため、まずは小さく作ることをおすすめします。

② descriptionを具体的に書く

Skillを作ったのに、思ったように動かない場合は、descriptionを確認してみましょう。

たとえば、

description: 開発を手伝って

では、何をするSkillなのかが曖昧です。

一方、以下なら、コードレビューに利用するSkillであることが明確です。

description: ソースコードをレビューし、バグ、セキュリティ上の問題、可読性、パフォーマンスを確認して、具体的な改善案を提案します。

Skillの本文だけではなく、「いつ呼び出されるべきSkillなのか」をdescriptionで分かりやすく伝えることが重要です。

③ 手順や判断基準を具体的にする

Skillには、単なる役割だけではなく手順を書くこともできます。

Googleはベストプラクティスとして、複雑なSkillでは判断フローを含めることも推奨しています。

たとえば、

エラーが再現できる

→ 原因を特定する

→ 修正する

→ テストする

 

エラーが再現できない

→ ログを確認する

→ 再現条件を整理する

といった判断基準です。

実際の業務では「Aの場合はB、Cの場合はD」という手順が数多く存在します。こうした人間が普段無意識に行っている判断を言語化することが、実用的なSkillを作るポイントになります。

まずは「いつもAIに指示していること」をSkillにしてみよう

今回は、Antigravityで実際にSkillを作成する方法を紹介しました。Skillsの面白いところは、特別なプログラムを書かなくても始められることです。普段Antigravityを使っていて、「また同じことを指示しているな」と感じたら、それはSkill化できる可能性があります。

コードレビュー、テスト作成、ドキュメント作成、調査、デプロイ手順など、まずは繰り返し発生する小さな作業からSkillにしてみると、その便利さを実感しやすいでしょう。そしてSkillに慣れてきたら、scriptsresourcesを組み合わせることで、より高度な業務手順もエージェントに持たせられるようになります。「AIに毎回細かく指示する」のではなく、自分たちの仕事のやり方をSkillとして蓄積していく。これが、Antigravityを単なるAIコーディングツールではなく、自分やチームの仕事に合わせたAIエージェントへ育てていく第一歩になるはずです。

森田 嶺
森田 嶺
大学卒業後、 AWS や Google Cloud 等、主にクラウドを基盤とした新規サービス開発の経験を経て、YOSHIDUMIに入社。Google ドライブ拡張サービス「Cmosy Pocket」「共有ドライブマネージャー」等、 Google Cloud を活用した自社サービスの開発に従事。現在、 Google 等が提供する生成AIを活用したサービスを開発中。https://x.com/r__morita
なぜ生成AI導入は失敗するのか?組織定着とガバナンス構築を実現するGoogle Workspace with Geminiセミナー

14:00-15:00 オンライン

なぜ生成AI導入は失敗するのか?組織定着とガバナンス構築を実現するGoogle Workspace with Geminiセミナー

詳細はこちら

Gemini・Notebookで変革! Google Workspaceで始めるAIファーストの働き方 〜「うちの会社でもできる」成長企業のための効果的な導入移行へのアプローチ〜

14:00-15:00 オンライン

Gemini・Notebookで変革! Google Workspaceで始めるAIファーストの働き方 〜「うちの会社でもできる」成長企業のための効果的な導入移行へのアプローチ〜

詳細はこちら

「閉じた」共有ドライブの利便性を最大化する! Cmosy Pocketで実現する、安全・快適な外部コラボレーション術セミナー

14:00-15:00 オンライン

「閉じた」共有ドライブの利便性を最大化する! Cmosy Pocketで実現する、安全・快適な外部コラボレーション術セミナー

詳細はこちら

Geminiの各機能、どう活かす?日常業務を加速する活用術と全社展開へのステップセミナー

14:00-15:00 オンライン

Geminiの各機能、どう活かす?日常業務を加速する活用術と全社展開へのステップセミナー

詳細はこちら

オンラインセミナー開催中

お申込みはこちらをCheck!