【Antigravity連載④】RulesとSkillsは何が違う？

Antigravityは自分仕様にカスタマイズできる

Antigravityの特徴のひとつが、エージェントの振る舞いをカスタマイズできることです。生成AIに毎回ゼロから指示を出していると、「このプロジェクトではこの書き方にしてほしい」「テストコードではこのルールを守ってほしい」といった同じ説明を何度も繰り返すことになります。

Antigravityでは、こうした情報をRulesやSkillsとしてあらかじめ用意できます。Rulesはエージェントが従う制約や振る舞いを定義する仕組み、Skillsは特定のタスクに対する指示やベストプラクティスなどをまとめた再利用可能な知識と覚えておきましょう。

つまり、Antigravityを単なる「コードを書いてくれるAI」として使うだけではなく、自社やプロジェクトのルール、開発ノウハウを理解したAIエージェントへ近づけるための仕組みが用意されているわけです。その中心となるのがRulesとSkillsです。

Rulesとは？

Rulesは、その名前の通りエージェントに守らせたいルールや制約を定義する機能です。公式ドキュメントでは、Rulesはユーザー固有のユースケースやスタイルに合わせてエージェントの振る舞いをガイドするための、手動で定義された制約として説明されています。Rule自体はMarkdownファイルとして記述します。

たとえば、次のような内容がRulesに向いています。

• 回答は日本語で行う
• TypeScriptではanyを使用しない
• 新しいライブラリを追加する前に既存ライブラリで実現できないか確認する
• APIキーや認証情報をソースコードへ直接記述しない
• テストコードを必ず追加する

共通しているのは、特定の作業だけではなく、エージェントの振る舞いそのものに適用したい方針であることです。たとえば毎回プロンプトに「anyは使わないでください」と書くのではなく、Rulesとして定義しておけば、Antigravityに継続的な方針として与えられます。

RulesにはGlobalとWorkspaceがある

AntigravityのRulesには、大きく「Global Rules」と「Workspace Rules」があります。Global Rulesはすべてのワークスペースで適用されるルールで、~/.gemini/GEMINI.mdに保存されます。一方、Workspace Rulesは特定のワークスペースに対するルールで、現在は.agents/rulesフォルダが標準の保存先です。従来の.agent/rulesも後方互換性のためサポートされています。

たとえば「回答は日本語にする」のような個人として常に使いたい設定はGlobal、「このプロジェクトではReactのコンポーネントをこの形式で作る」といったプロジェクト固有のルールはWorkspace、という使い分けができます。

Rulesの作成方法

Rulesの作成方法は、前章で説明した指定の場所に、手動でRulesのファイルを作成する方法、AIエージェントに依頼して作ってもらう方法、そしてAntigravity IDEで作成する、3つのパターンが存在します。今回はAntigravity IDEで作成する手順について説明します。

※Antigravity 2.0のUIからはRulesは作れません。

①Antigravity IDEを開く

まず、最初にご利用のPCからAntigravity IDEを起動します。

②Rules設定画面を開く

Antigravity IDEのエージェントパネル上部の「…」からCustomizationsを開き、[Rules] > [+ Workspace]をクリックします。

③Rulesの名前を入力する

作成したいルールの名前を入力します。作りたいRulesに沿った名前がおすすめです。

④Activation Modeを選択する

RulesのActivation Mode(適用方法)を指定します。

適用方法として「Manual」「Always On」「Model Decision」「Glob」が用意されています。常時適用するだけでなく、手動で呼び出したり、モデルに適用判断を任せたり、特定のファイルパターンに対して適用したりできます。

適用方法の詳細については、以下表をご参考ください。

⑤Rulesの中身を編集する

以下のようにRulesの本文はMarkdownの見出しと箇条書きで記述できます。普段プロンプトに書いている指示のうち、このプロジェクトで共通して守ってほしい方針をまとめると良いです。

# プロジェクト共通の開発ルール  

## 回答の方針
- 回答や作業結果の説明は日本語で行う。 
- 作業完了時は、変更内容と実施したテストを説明する。 
- テストを実行していない場合は、その旨を明記する。  

## コードの書き方 
- 既存コードの命名規則やファイル構成に合わせる。 
- JavaScriptの変数宣言にはvarを使わず、constまたはletを使う。 
- 新しいライブラリを追加する前に、既存の機能で実現できないか確認する。  

## 認証情報の扱い 
- APIキーやパスワードをソースコードに直接記述しない。

⑥Rulesの保存

Rulesの編集が完了したら、Rulesを保存してください。今回はWorkspace Rulesとして「my-rule.md」を保存したため、保存先はプロジェクト直下の「.agents/rules/my-rule.md」になります。以上で、Rulesの作成は完了です。

Skillsとは？

Skillsについては、これまでの連載記事でも何度も書いてきましたが、Rulesとの比較のために改めて説明すると、エージェントの能力を拡張するためのオープンスタンダードの仕組みです。基本単位はSKILL.mdを含むフォルダで、そこに特定タスクへの取り組み方やベストプラクティス、規約などを記述できます。必要に応じてスクリプトや参考資料などを一緒に持たせることも可能です。

たとえば、「コードレビュー」というSkillを作るのであれば、単に「コードレビューしてください」と書くだけではありません。「正しく動作するか」「エッジケースが考慮されているか」「プロジェクトのコーディング規約に沿っているか」「パフォーマンス上の問題がないか」といった確認ポイントをSkillとしてまとめておくことができます。

Skillの基本構造は次のようになります。

必須なのはSKILL.mdだけで、その他のディレクトリは任意です。つまりSkillsは文章による指示だけではなく、必要に応じてスクリプト、実装例、テンプレートなどもひとつのパッケージとして管理できます。この点はRulesとの大きな違いです。

Skillsについて詳しく知りたい場合は以下の記事も合わせてご参考ください。

• 【Antigravity連載②】AIエージェントを自分仕様に育てる「Skills」とは？

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

RulesとSkillsの違い

ここまで読むと、どちらもMarkdownにエージェントへの指示を書くため、「結局ほとんど同じなのでは？」と思うかもしれません。しかし、考え方はかなり違います。

Rulesは「どう振る舞うべきか」を決めるものです。Skillsは「この仕事をどう進めるか」を教えるものです。学校に例えるなら、Rulesは「授業中はスマートフォンを使わない」「レポートは指定フォーマットで提出する」といった校則や授業ルールです。一方のSkillsは、「研究レポートを書くときは、まずテーマを決め、資料を調査し、仮説を立て、構成を作ってから本文を書く」といった作業ノウハウに近いでしょう。この違いを理解すると、どちらに何を書くべきなのか判断しやすくなります。

Skillsは必要な時にだけ利用される

Skillsを理解するうえでもうひとつ重要なのが、Progressive Disclosure（段階的開示）という考え方です。Antigravityでは会話開始時に、利用可能なSkillの名前とdescription（説明）がエージェントへ提示されます。そして、ユーザーから依頼されたタスクに関連すると判断した場合に、エージェントがそのSkillの詳しいSKILL.mdを読み込みます。

最初からすべてのSkillの詳細を読むのではなく、まずSkillの存在を把握し、必要になったものだけを読み込んで実行する仕組みです。そのためSkillを作成するときには、descriptionが重要です。

たとえば「コード関連のSkillです」のような曖昧な説明より、「Pythonコードの単体テストをpytestの規約に沿って生成する」のように、何をするときに使うSkillなのかを具体的に記述することが推奨されています。

どう使い分ければいい？

RulesとSkillsの使い分けに迷ったときは、「その指示は、さまざまな作業で守ってほしい方針なのか、それとも特定の仕事を行うためのノウハウなのか」と考えると分かりやすくなります。たとえばWebアプリケーションを開発しているチームを考えてみましょう。

「コード内に認証情報を書かない」「TypeScriptではanyを使用しない」「既存コードの命名規則に合わせる」といった内容はRulesに記述します。一方、「新しいAPIを追加するときは、既存APIの構造を確認し、エンドポイントを実装し、バリデーションとテストを追加する」といった一連の作業方法はSkillとして定義するのが分かりやすいでしょう。

さらに「コードレビュー用Skill」「テスト作成Skill」「リファクタリングSkill」のように、目的別にSkillを分けることもできます。一つのSkillに何でも詰め込むのではなく、一つのSkillが一つのことをうまく実行できるよう、焦点を絞ることが重要です。

RulesとSkillsは競合する機能ではない

ここで重要なのは、RulesとSkillsは「どちらを使うか」という二者択一ではないことです。むしろ、Rulesで共通ルールを定義し、Skillsで個別業務のノウハウを与えるという組み合わせが考えられます。たとえばRulesにセキュリティやコーディング規約を定義しておき、コードレビューSkillにはレビューの具体的なチェック手順を定義します。するとエージェントには、プロジェクトとして守るべき方針と、コードレビューという仕事を進めるための知識の両方を与えられます。

まとめ

Antigravityを使い始めた段階では、RulesとSkillsの違いが少し分かりにくいかもしれません。まず「Rules＝守ってほしいルール」「Skills＝仕事の説明書」くらいの理解から始めるのが、個人的にはおすすめです。プロジェクト全体で守ってほしい開発方針や禁止事項はRules、特定の作業を高い品質で繰り返すための手順やノウハウはSkills、この基準で整理すると、かなり判断しやすくなると思います。

Skillsは、単なる長いプロンプトの保存場所ではありません。必要なタイミングでエージェントがSkillを発見し、詳しい指示を読み込み、そこに含まれるリソースも利用できるという仕組みです。Antigravityを本格的に使うのであれば、毎回プロンプトを工夫するだけではなく、自社のルールはRulesへ、蓄積したノウハウはSkillsへ移していくことが、エージェントを自分たちの開発スタイルに近づけていく一つの方法です。