GoogleのAI開発ツール「Antigravity」を使ってエージェントファースト開発を実践する本連載。前回は、エージェントへの指示の出し方と、実装計画の確認・修正のサイクルを体験した。今回は少し視点を変え、エージェントをうまく動かす仕組みづくりにフォーカスして、「ルール(Rules)」と「ワークフロー(Workflows)」という2つの機能を紹介する。

「ルール」と「ワークフロー」

前回、AIエージェントに正確に意図を伝えるためには、できるだけ具体的に条件を伝えることが重要だと説明した。この点を意識して開発を続けていくと、同じような指示を何度も繰り返し書いていることに気付くかもしれない。

例えば変数の命名規則や、ソースコードの配置の仕方、コメントの書き方など、プロジェクト単位で毎回守って欲しいルールはたくさんある。エージェントも既存のソースコードを読んである程度は自動的にこれらのルールを読み取ってくれるものの、正確さを求めるのであれば、やはり明確に指示に含めた方がいい。とはいえ、これらの指示を毎回プロンプトに書くのは手間がかかる。

そこでAntigravityには、こうしたプロジェクトごとの決まりごとをあらかじめ設定しておく仕組みが用意されている。それが「ルール(Rules)」と「ワークフロー(Workflows)」だ。

エージェントが常に従う「ルール」

ルールは、エージェントがコードやテストなどを生成する際に常に従うべきガイドラインを設定するための仕組みだ。一度設定すれば、以降は毎回プロンプトで伝えなくても、すべての作業でそのルールを自動的に適用してくれる。

ルールには、グローバルルールとワークスペースルールの2種類があり、それぞれで保存される場所が異なる。

  • グローバルルール: 全プロジェクトに共通して適用されるルール。「~/.gemini/GEMINI.md」というMarkdown形式のファイルで管理される。どのプロジェクトでも共通して守ってほしいことを記述する

  • ワークスペースルール: 特定のプロジェクト専用のルール。各ワークスペースの「.agent/rules/」ディレクトリ以下にMarkdownファイルとして保存される。そのプロジェクト固有のディレクトリ構成や命名規則、使用するライブラリーの方針などを記述する

定型的な指示を事前に登録しておく「ワークフロー」

ワークフローは、よく使う定型的な手順を事前に登録しておき、必要なときにチャットから呼び出せるようにする仕組みだ。チャット欄で「/」と入力すると登録済みのワークフロー一覧が表示され、選択して実行できる。

ワークフローもルールと同様に、グローバルとワークスペースの2種類があり、それぞれ設定を保存する場所が異なっている。

  • グローバルワークフロー: 全プロジェクトで共通で利用できるワークフロー。「~/.gemini/antigravity/global_workflows/global-workflow.md」というMarkdown形式のファイルで管理される
  • ワークスペースワークフロー: 特定のプロジェクト専用のワークフロー。各ワークスペースの「.agent/workflows/」ディレクトリ以下にMarkdownファイルとして保存される

ルールとワークフローの使い分け

ルールとワークフローの違いは、それが常に適用されるのか、それとも必要なときに呼び出して適用するのかという点にある。ルールはとくに指示をしなくてもすべての作業でエージェントが自動的に従うが、ワークフローは明示的に呼び出さなければ適用されない。

例えば、「コードスタイルを統一したい」という要件は、常に従ってほしいのでルールで設定するのに向いている。一方、「機能を追加した際にREADMEを更新する」というような作業は、毎回自動で行うものではなく、必要なタイミングで呼び出せばいいのでワークフローに向いている。ワークフローは特定のプロンプトをワンタッチで実行できるコマンドのようなものだと思えばいいだろう。

MyMarksにルールを設定する

それでは、実際にMyMarksプロジェクトにルールを設定してみよう。ルールを設定するには、Editorの右上にある「...」メニューから「Customizations」を選択してカスタマイズメニューを開く。

  • Editorでカスタマイズメニューを開く

    Editorでカスタマイズメニューを開く

ここの「Rules」タブで。「+Workspace」ボタンをクリックすると、ワークスペースルールの追加画面が開く。ルール名を聞かれるので、任意の名前(例:code-style)を入力してエンターを押す。なお、グローバルルールを設定したい場合には「+Global」ボタンをクリックすればよい。

  • 「Rules」タブから新規ルールを追加する

    「Rules」タブから新規ルールを追加する

今回は、次の5つのルールを設定しようと思っている。

  • コードスタイルは次の「Google TypeScript Style Guide」に準拠する
  • コンポーネントは src/components に配置する
  • LocalStorageの操作は src/utils にまとめる
  • 型定義は src/types にまとめる
  • コードのコメントは日本語で書く

ルールは自然言語で書くことができる。Markdown形式で書けるので、次のように見出しや箇条書きを活用して整理すると見やすくなる。

# MyMarks プロジェクトのルール

## コードスタイル
- コードスタイルは次の「Google TypeScript Style Guide」に準拠すること。
    - https://google.github.io/styleguide/tsguide.html

## ディレクトリ構成
- コンポーネントは src/components に配置すること
- LocalStorageの操作は src/utils にまとめること
- 型定義は src/types にまとめること

## コメント
- コードのコメントは日本語で書くこと
  • コーディングスタイルに関するルールの作成例

    コーディングスタイルに関するルールの作成例

保存すると、.agent/rules/ディレクトリ以下にMarkdownファイルとして保存される。

MyMarksにワークフローを設定する

続いてワークフローを設定しよう。ワークフローはカスタマイズメニューの「Workflows」タブで追加できる。今回はワークスペースワークフローを設定したいので「+Workspace」ボタンをクリックする。グローバルワークスペースの場合は「+Global」ボタンをクリックすればよい。今回は2つのワークフローを追加してみる。

1つ目は、新しい機能を実装したあとで、Webブラウザを起動して動作確認し、スクリーンショットを撮影して期待通りの動作になっているかを確認するワークフローだ。名前は「browser-test」とする。ワークフローファイルには、Content欄に次のように記載してみる。Descriptionには簡単な説明を書いておけばよい。

ブラウザを起動してlocalhost:3000にアクセスし、直前に実装した機能が期待通りに動作しているかを確認してください。
確認結果をスクリーンショット付きで報告してください
  • Webブラウザー上で動作確認を実行するワークフローの例

    Webブラウザ上で動作確認を実行するワークフローの例

2つ目は、機能を追加したあとにREADMEの機能一覧を最新の状態に更新するワークフローで、名前は「update-readme」とする。ワークフローファイルには、Content欄に次のように記載してみる。

README.mdの機能一覧を更新するワークフローの例

README.mdの機能一覧セクションを、現在のMyMarksアプリに実装されている機能を反映した内容に更新してください

MyMarksにお気に入りマーク機能を追加する

ルールとワークフローを設定したら、実際に使ってみよう。今回はMyMarksのブックマークに「お気に入りマーク」を付ける機能を追加してみる。

Agent Managerのチャット欄には、次のような指示を入力する。

各ブックマークカードにお気に入りマーク「★」を追加してください。
★をクリックすると「お気に入り」状態がトグルし、「お気に入り」になっているときは★が黄色で、そうでないとき(デフォルト)では白抜きで表示します。
お気に入り状態はLocalStorageに保存してください

これまでと同様に実装計画(Implementation Plan)が作成される。問題なさそうであれば、「Proceed」ボタンを押して実装を開始しよう。

  • お気に入りマーク機能を追加する実装計画

    お気に入りマーク機能を追加する実装計画

実装が完了したら、ソースコードを確認してみよう。今回のケースではファイルツリーはこれまでと変わっていないと思うが、もしも新たにコンポーネントや型定義が追加された場合は、それらはルール通りにcomponentsやtypesディレクトリに配置されているはずだ。

ソースコードの中身を見ると、今回追加されたコードには日本語のコメントが付けられていることがわかる。これも新たに追加したルールに従った形だ。他にも細かく見ていけば、コーディングスタイルがGoogle TypeScript Style Guideの通りになっていることに気が付くだろう。

  • ディレクトリ構成やコメントがルールに従って整理されている

    ディレクトリ構成やコメントがルールに従って整理されている

もしもルールから逸脱した箇所があれば、実装計画やコード差分段階のアーティファクトにコメントをつけて修正を求めるとよい。また、ルールが明確でないために守れなかった可能性もあるので、ルールの記述も見直すようにしよう。

ワークフローを呼び出してみる

問題なく実装できたら、ワークフローも呼び出してみよう。チャット欄で「/」を入力すると、利用可能なワークフローの一覧が表示される。候補がたくさんある場合には、続けて「browser」まで入力すれば「browser-test」が絞り込めるので、選択して実行する。

browser-testの呼び出しに成功すれば、設定した内容の指示がエージェントに渡され、ブラウザが起動して動作確認が始まる。ブラウザの操作はエージェントが自動で行うので、終わるまでそのまま待てばいい。

  • browser-testワークフローによってブラウザー上で動作確認が実行される

    browser-testワークフローによってブラウザ上で動作確認が実行される

なお、どのような動作確認を行うかはチャット欄に「Goal」として表示される。筆者の環境では次のような内容になった。

ブラウザはすでに http://localhost:3000/ が開かれています。MyMarksアプリのお気に入り(★)機能の動作確認を行ってください。

## 確認手順

### 1. 現在のページ状態を確認
- スクリーンショットを撮る(現在の状態を確認)

### 2. ブックマークの準備
- ブックマークが0件の場合は、以下を追加する:
  - 「ブックマークを追加」ボタンをクリックしてフォームを展開
  - タイトル入力欄に「GitHub」、URL入力欄に「https://github.com」を入力して「追加」ボタンをクリック
  - 同様にタイトル「Google」、URL「https://google.com」を追加
  - スクリーンショットを撮る

### 3. ★ボタンの表示確認
- ブックマークカード右上付近に「★」ボタンが表示されていることを確認
- スクリーンショットを撮る(★が白抜きかどうか確認)

### 4. お気に入りON
- いずれかのブックマークの「★」ボタンをクリック
- スクリーンショットを撮る(★が黄色になっているか確認)

### 5. リロード後の永続化確認
- ページをリロード(F5を押す)
- スクリーンショットを撮る(★が黄色のまま保持されているか確認)

### 6. お気に入りOFF
- 黄色の★ボタンを再度クリックして解除
- スクリーンショットを撮る(★が白抜きに戻っているか確認)

## 報告内容
各ステップの成否、撮影したスクリーンショットのファイルパス、確認できた内容を報告してください

確認手順が不十分だった場合には、この内容を真似して、再度エージェントにチャットで指示を出せばいい。

動作確認が完了すると、スクリーンショットや動画(Playback)が作られて結果を確認できる。

  • 動作確認結果が確認できる

    動作確認結果が確認できる

続いて「update-readme」のワークフローも呼び出してみよう。チャット欄で「update-readme」を選択して実行する。するとエージェントは現在実装されている機能と、既存のREADME.mdを確認した上で、機能一覧を最新のものに更新してくれる。まだREADME.mdが存在しなかった場合には、実装済みの機能を元にして新規で作成される。

  • update-readmeワークフローによってREADME.mdが更新された

    update-readmeワークフローによってREADME.mdが更新された

README.mdに記載する内容などをもっと細かく指示したい場合は、ワークフローの内容を工夫すればいい。同様に、変更点をリストアップするChangelog.mdの更新なども、ワークフローにしておくと便利だ。

ルールとワークフローは、エージェントファースト開発における「プロジェクトの作法」のようなものだと考えるとわかりやすい。現実のチーム開発では、コーディング規約やディレクトリ設計などの基本方針が定められており、メンバーはそれに従って開発を行うのが一般的だ。ルールやワークフローを活用すれば、エージェントに対しても同様に、プロジェクトの作法を事前に教えておくことができる。毎回同じような指示を出す必要がなくなり、開発のリズムが格段に良くなるので、積極的に活用していこう。