GoogleのAI開発ツール「Antigravity」を使ってエージェントファースト開発を実践する本連載。前回は、ルールとワークフローを使ってAIエージェントの行動規範を設定する方法を紹介した。ルールを設定しておけば、コーディングスタイルやディレクトリ構成といったプロジェクトの作法を毎回指示しなくて済むようになる。今回はさらに一歩進めて、エージェントに特定のタスク専用の知識や技能を持たせる「スキル(Skills)」という機能を紹介する。
「スキル」とは: ルールやワークフローと何が違う?
Antigravityで使用するGeminiやClaude SonnetといったAIモデルはきわめて高度で汎用的な知識を持っているが、それでも特定のプロジェクトや業務に特化した知識を持っているわけではない。したがって、組織やプロジェクトで標準的に使用している共通の前提知識やノウハウなどがある場合には、これを何らかの方法でエージェントに提供する必要がある。
そのようなときに活用できるのが「スキル(Skills)」だ。スキルは、エージェントが特定の作業を実行する際に必要となる専門知識をパッケージとしてまとめたもので、これを利用することでエージェントの機能をより専門的に拡張することができる。
ルールやワークフローとの大きな違いは、スキルは「エージェントが必要だと判断するまで読み込まれない」という点にある。ルールはすべての作業でエージェンによって参照される。一方でワークフローはコマンドのようにユーザーが明示的に呼び出して使う。スキルはこのどちらとも異なり、エージェントがユーザーの指示を解釈した結果、実行しようとしているタスクに関連するスキルがあると判断したときのみ、自動的に読み込んで実行する。
ルールには、ワークフローのように呼び出されたときに実行するべき一連の作業を自然言語で記述できる。関連するドキュメント(例えば、ツールの利用マニュアルなど)を読み込ませたり、画像やテキストなどの静的コンテンツをあらかじめ用意しておいて作業に利用することもできる。また、Pythonなどのスクリプトを用意して実行といったことが可能になっている。
一度作ったスキルのパッケージは別のプロジェクトでも再利用できる。「よく使う作業のパターン」をスキルとしてストックしておけば、ノウハウを蓄積して開発効率を向上させていくことができる。
スキルはどこで使える?適用範囲と配置場所
ルールやワークフローと同様に、スキルにもグローバルとワークスペースの2種類がある。
- グローバルスキル: 全プロジェクトで共通で利用できるスキル。組織内で共通して使いたい専門知識などを定義する場合に使う。保存場所は「~/.gemini/antigravity/skills/」ディレクトリ
- ワークスペーススキル: そのプロジェクト専用のスキル。プロジェクトの特定の作業に特化した専門知識を定義する場合に使う。保存場所は各ワークスペースの「.agent/skills/」ディレクトリ
スキルのパッケージ構造と中身
スキルは、ディレクトリベースのパッケージとして定義する。ディレクトリの基本的な構造は次のとおりだ。
中心になるのは「SKILL.md」というファイルで、ここにそのスキルで実行する処理を記述する。scripts、references、assetsの各ディレクトリには、スキルで使用するスクリプト、ドキュメント、画像やテキストなどの静的ファイルをそれぞれ格納する。必須なのはSKILL.mdだけで、その他のディレクトリは必要に応じて用意すればよい。SKILL.mdで明示的に参照するように指定すればこれ以外のディレクトリを用意することもできる。
SKILL.mdには、上部にYAML形式でメタデータを記述し、その背後にMarkdown形式で作業手順などの本文を記述する。
メタデータには次のようにnameとdescriptionを記述する。
---
name: スキルの名前
description: このスキルはどんなときに使われるべきかの説明
--
descriptionはとくに重要で、エージェントがユーザーの指示とスキルを照合する際の基準として使われる。したがって、どんな指示を受けたときにこのスキルを使うべきかが、メタデータから判断できなければならない。
Markdown形式の本文には、スキルの目標や、実行手順、制約事項などを記述する。この部分はプロンプトと同様にエージェントが意図を解釈しながら実行するので、自然言語で記述できる。ただし、チャットのプロンプトと同様に、できるだけ具体的に手順などを記述すれば、それだけ意図通りの処理を実行してくれる可能性が高まる。
実践: 動作確認レポートを自動生成するスキルを作る
それでは、実際にスキルを作ってみよう。今回は、MyMarksアプリで動作確認レポートを生成するスキルを作成してみたい。このスキルは、エージェントがWebブラウザ上でアプリの各機能の動作確認を行い、その結果をスクリーンショット付きでMarkdown形式で出力するというものだ。
このような動作確認は、機能の変更や追加を行うたびに繰り返し実行する作業になる。確認項目が複数あるので、この手順を毎回チャットで詳細に指示するのは現実的ではない。スキルとして定義しておけば、「QAレポートを作って」という一言だけで、一連の確認作業を自動実行できるようになる。
今回はワークスペーススキルとして定義したいので、ワークスペースのルートディレクトリに「.agent/skills/qa-report/」ディレクトリを作成する。このディレクトリの作成は、ファイルマネージャーなどを使って(Windowsならエクスプローラー、MacならFinder)から手動で行う必要がある。エージェントに指示して作成してもらうこともできる。
次に、SKILL.mdを作成しよう。
---
name: qa-report
description: MyMarksアプリの動作確認を行い、動作確認レポートを生成する。ブラウザで各機能をテストしてスクリーンショットを撮影し、結果をMarkdownファイルにまとめる。
---
# QA Report Skill
## Goal
MyMarksアプリの主要機能を一通りブラウザで操作し、動作確認レポート(`qa-report.md`)を生成する。
## Instructions
1. `npm run dev`でアプリを起動する(すでに起動中であれば不要)
2. ブラウザで`http://localhost:3000`を開く
3. `references/checklist.md`に記載された確認項目を順番に実行する
4. 各項目でスクリーンショットを撮影する
5. プロジェクトのルートに、現在時刻を使った`年月日-時分秒`形式の名前のディレクトリを作成する
6. 確認結果(OK / NG)とスクリーンショットをまとめた`qa-report.md`を作成し、5で作ったディレクトリに格納する
## Constraints
- NGの項目があっても修正は行わない。レポートへの記録にとどめる
- スクリーンショットは各確認項目につき1枚撮影する
スキル名は「qa-report」とした。descriptionには「動作確認」や「レポート」といったキーワードを含めて、エージェントが何をするときにこのスキルを呼び出すのか明確に判断できるようにしておく。
本文は作業手順を自由に書くことができるが、今回は目標(Goal)、実行手順(Instructions)、制約事項(Constraints)の3つの項目を明記した。実行手順はできるだけ間違いがないように、実施したい処理を箇条書きで記述している。
次に「references/」ディレクトリを作成し、そこに「checklist.md」を用意する。このファイルには、動作確認したい項目を列挙しておく。後で機能追加した場合などには、このファイルに項目を追加すればよい。
これでスキルの準備は完了だ。ファイルツリーは次のようになっている。
qa-reportスキルを実行してみる
スキルが完成したら、エージェントに指示を出してみよう。チャット欄に次のように入力する。
QAレポートを作って
指示はこれだけでいい。エージェントはこの指示を受け取ると、SKILL.mdのdescriptionと照合してqa-reportスキルが適切だと判断し、スキルの内容を読み込んで作業を開始する。
エージェントが動き出すと、まずアプリを起動してWebブラウザーでlocalhost:3000にアクセスし、チェックリストに沿って各機能を操作する。ブックマークの追加や並べ替え、★ボタンのクリックなど、人間が手動で行うような確認作業をエージェントが自動でこなしていく。各ステップではスクリーンショットを撮影する。
時折、作業を続行していいかの確認を求められるので、作業内容を確認した上で問題なければ承認して続きを実行しよう。
すべての動作確認が終わると、ワークスペースのルートに日付時刻のディレクトリが作られ、そこに動作確認の結果をまとめたレポート「qa-report.md」と、スクリーンショットが格納される。
生成されたレポートには、実施日時・確認した機能の一覧・各項目の合否・問題があった場合の詳細などがまとめられている。もし不合格の項目があれば、そこを起点に修正の指示を出せばいい。
スキルをさらに活用するには
スキルは使い始めてからも改善できる。何度か実行してみると、「この確認項目が足りなかった」「レポートの形式をもう少し変えたい」といった改善点に気付くかもしれない。そのたびにSKILL.mdやreferences/checklist.mdを修正していくことで、スキルの品質を上げることができる。
descriptionの精度も重要だ。もし意図しない場面でスキルが発動してしまう場合には、descriptionにそのスキルを使わない場合の例を追記してみるといいだろう。逆に発動してほしいのに認識されない場合は、ユーザーが普段使いそうなキーワードをdescriptionに盛り込むことで改善できる。
前回と今回で、エージェントの振る舞いを制御する仕組みを紹介した。ルールは常に守るべき制約、ワークフローは明示的に呼び出す定型的な手順、そしてスキルは指示の意図を読み取って自動的に読み込まれる専門知識のパッケージだと考えればいいだろう。この3つを組み合わせることで、エージェントはプロジェクトの文脈をより深く理解した上で作業を進められるようになる。






