AI使ってFlutter開発したら二週間かかった作業が2分でできたので、もうガンガンAI使うためのワークフローをまとめた[Google Antigravity + Flutter]
WRITER
ロッキーカナイ
SwiftやObjective-CでiOS開発や、Flutterを用いたiOS/Androidアプリ開発、PHPでLaravelを使ったWebアプリ開発などをしてます。趣味は猫と戯れる事、キックボクシングにハマってます。ちなみに名前のロッキーカナイは以前よく昼飯を食べてた所。
どうもロッキーカナイです。
もうね、怒ってますよ私は。
AI優秀すぎて。かつては使えねーなと思ったこともありましたが、とんでもないですわ、指示出しちゃんとすると本当に優秀。
私なんて、敬意を評して常に敬語で指示してますからね。
「〜して下さいませんでしょうか」「〜して頂いても宜しかったでございますでしょうか」ね。
そしたらAI側も深読みしてよくわかんない敬語で返してきますからね。これでトークン消費してるかもなんで完全無駄なんですけどね。
昨今AIの発展は著しく、開発現場でもAIの登場でプログラマーが職を奪われてしまうんじゃないかという危機を、まじまじと感じております。
正直、これまでは「人にしかできないことがある」「ニーズのある専門知識がある」って思ってましたが、今回で考えが180度変わりました。費用対効果を考えたらAIに任せた方がいい。AIに代替可能であれば全部やってもらえばいいという考えです。
それは、二週間かけて作ったアプリが2分で出来てしまったことが原因です。しかも人力ではしていなかったテスト実行とdart analyzeまでやって、大将全部やっときましたぜ、へいおまちって感じで。すごすぎん？
このことがあって、AIの知識を得るために色々調べています。（まだまだ途中）
上記はバイブコーディングでの開発ですが、ある程度規模のある開発をする場合、どのような手順で行っていくかをワークフローとしてまとめましたので、記載します。
ワークフロー
- AGENTS.md の作成。
- SPEC.md を作成（書き方に迷ったら 「付録B」 を参照）。
- 上記プロンプトをAIに投げて docs/architecture.md を生成。
- あとはマイルストーン（実装したい機能）ごとに「実装してください」➔「Proceed（承認）」を繰り返すだけで開発が進みます。
# AI協調開発ガイドライン & 新規開発ワークフロー完全ガイド
(AI Collaborative Development Workflow Guide)
本ドキュメントは、Antigravity や AI コーディングアシスタントを活用して新規開発・機能追加を行う際の**標準手順書、プロンプト集、および設計テンプレートを統合した完全ハンドブック**です。
次回以降の新規プロジェクト立ち上げ時のチェックリストや、チームメンバー・他開発者への開発フロー共有メモとして活用できます。
---
## 目次
1. [AGENTS.md の役割とテンプレート化（8割共通・2割固有）](#1-agentsmd-の役割とテンプレート化8割共通2割固有)
2. [新規開発の標準ワークフロー（5ステップ全体像）](#2-新規開発の標準ワークフロー5ステップ全体像)
3. [要求・基本設計の投入ガイド（Step 2 詳細）](#3-要求基本設計の投入ガイドstep-2-詳細)
4. [自律実装を成功させる実践テクニック（Step 3〜5 詳細）](#4-自律実装を成功させる実践テクニックstep-35-詳細)
5. [レイヤー順（下位 ➔ 上位）で実装するメリット](#5-レイヤー順下位--上位で実装するメリット)
6. [プロジェクト内ドキュメント体系の役割分担](#6-プロジェクト内ドキュメント体系の役割分担)
7. [【付録】コピペで使える標準テンプレート & 記述具体例](#7-付録コピペで使える標準テンプレート--記述具体例)
* [付録A: docs/SPEC.md 標準フォーマット（雛形）](#付録a-docsspecmd-標準フォーマット雛形)
* [付録B: docs/SPEC.md 記述具体例（認証・ログイン機能）](#付録b-docsspecmd-記述具体例認証ログイン機能)
* [付録C: AGENTS.md スターター雛形](#付録c-agentsmd-スターター雛形)
---
## 1. AGENTS.md の役割とテンプレート化（8割共通・2割固有）
`AGENTS.md`（または `GEMINI.md` / `CLAUDE.md`）は、AIアシスタントにとっての**「プロジェクトの憲法（Constitution）」**であり、コード生成時の安全柵（ガードレール）です。
AIは指示を受けるたびに最優先コンテキストとしてこのファイルを読み込むため、**プロジェクト初期化直後（コードを書く前）に配置するのが最も手戻りを防ぐベストプラクティス**です。
新規開発時、`AGENTS.md` は **約80%をそのまま流用し、約20%のみプロジェクト固有の内容に書き換える** だけで運用できます。
### 1.1 そのまま流用できる部分（約80%：プロジェクト共通の憲法）
* **開発プロセスの原則**:
* 「仕様確認 ➔ 計画提示（Planning） ➔ 実装 ➔ 自動検証」の反復サイクル。
* **コード品質・検証基準**:
* 静的解析で警告・エラー 0 件維持（`flutter analyze` / `dart analyze`）。
* 自動テスト全件パス必須（`flutter test`）。
* Effective Dart に準拠したドキュメントコメント（`///` 形式）の記述。
* **アーキテクチャの大方針**:
* レイヤードアーキテクチャの厳格な分離（Presentation / Logic / Domain / Data）。
* 依存性の逆転（DIP: 具象ストレージやAPIに直接依存せず、Repositoryインターフェースを介す）。
* **UI/レイアウト原則**:
* 親コンテナ制約を考慮する `LayoutBuilder` を使った適応型レスポンシブ設計。
* **モダン構文の適用**:
* Dart 3 の `switch` 式、パターンマッチング（レコード分解）、ガード節（`when`）による宣言的記述。
* **ドキュメント参照構造**:
* 「仕様・詳細設計は `docs/` を参照」「公式スキルは `.agents/skills/` を参照」というポインタ構造。
### 1.2 新規開発時に書き換えるべき部分（約20%：プロジェクト固有情報）
新規プロジェクト作成時には、以下の箇所のみをプロジェクト要件に合わせて書き換えます。
1. **「プロジェクト概要 & 技術スタック」**: アプリ名、開発目的、使用パッケージ（Riverpod, Drift, GoRouter など）。
2. **「設計規約の具体例」**: プロジェクト固有のエンティティ名やリポジトリ名。画面数が多い場合は Feature-first（機能単位: `lib/features/auth/` など）のディレクトリ方針。
---
## 2. 新規開発の標準ワークフロー（5ステップ全体像）
```mermaid
flowchart TD
classDef human fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px,color:#0d47a1;
classDef ai fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px,color:#4a148c;
classDef check fill:#fff3e0,stroke:#fb8c00,stroke-width:2px,color:#e65100;
Step0["Step 0: プロジェクト初期化<br/>(flutter create & パッケージ追加)"]:::human
--> Step1["Step 1: ガードレール設置【最序盤】<br/>(AGENTS.md & スキルの配置)"]:::human
--> Step2["Step 2: 要求・基本設計の投入<br/>(docs/SPEC.md ➔ docs/architecture.md)"]:::human
--> Step3["Step 3: 実装計画の策定 (Planning)<br/>AIが implementation_plan.md を作成"]:::ai
--> Gate{"【人間の唯一の作業】<br/>Proceed（承認）ボタンを押す"}:::check
--> Step4["Step 4: 自律実装<br/>Domain / Data / Logic / UI を自動作成<br/>単体・ウィジェットテストを作成"]:::ai
--> Step5["Step 5: 自律検証 & 完了報告<br/>analyze / test 実行（自動自己修復）<br/>walkthrough.md を生成"]:::ai
--> Done["【完了】<br/>成果物の確認 & Gitコミット"]:::human
```
### 対話シーケンスの流れ
```mermaid
sequenceDiagram
autonumber
actor User as 開発者
participant AI as AIアシスタント
User->>AI: 「docs/SPEC.md と architecture.md を元に実装して」
Note over AI: [Step 3: 計画策定]<br/>implementation_plan.md を自動作成
AI-->>User: 「実装計画を作成しました。確認してください」
Note over User: ★ 人間の唯一のアクション ★
User->>AI: 画面上の「Proceed」ボタンを押下（承認）
Note over AI: [Step 4: 自律実装]<br/>・各レイヤーのコード作成<br/>・単体/ウィジェットテスト作成
Note over AI: [Step 5: 自律検証]<br/>・flutter analyze / test（自己修復）<br/>・walkthrough.md 生成
AI-->>User: 「実装と全テストが完了しました！walkthrough.md をご確認ください」
```
### 各ステップの詳細
#### Step 0: プロジェクト初期化
```bash
flutter create my_new_app
cd my_new_app
flutter pub add flutter_riverpod shared_preferences
flutter pub add -d flutter_lints
```
#### Step 1: ガードレール（安全柵）の設置【最序盤】
* テンプレートから `AGENTS.md` をプロジェクトルートに配置。
* 公式スキルを追加（例: `npx --yes skills add flutter/skills`、`npx --yes skills add dart-lang/skills`）。
#### Step 2: 要求・基本設計ドキュメントの投入
* 人間のメモから `docs/SPEC.md`（仕様書）を作成。
* それを元に `docs/architecture.md`（技術設計書）をAIに生成させる。
* ※ この段階ではソースコード（`lib/`）はまだ1行も書きません。
#### Step 3: 実装計画の策定（Planning Mode）
* AI に「`docs/SPEC.md` と `docs/architecture.md` を元に実装計画を作成してください」と指示。
* AI が `implementation_plan.md`（変更ファイル一覧、手順、テスト方針）を作成して停止。
* 人間が内容を確認し、UI上の **「Proceed」ボタンをクリック**（または「OK」と返信）して承認。
#### Step 4: レイヤー順の実装 & テスト駆動
* AI が承認を受けて自律的にコード作成を開始（Domain ➔ Data ➔ Logic ➔ Presentation）。
* ロジックの単体テストやウィジェットテストを並行作成。
#### Step 5: 自動検証 & ウォークスルー記録
* AI が `flutter analyze` と `flutter test` を実行。エラーや警告が出た場合はAI自身が自動で自己修復。
* 全テスト合格後、成果物レポート `walkthrough.md` を生成して完了報告。
---
## 3. 要求・基本設計の投入ガイド（Step 2 詳細）
### 3.1 黄金の作成順序: 先に「SPEC」➔ 次に「architecture」
```text
【作成順序】
1. 人間がラフな要望・アイデアをインプット
↓
2. docs/SPEC.md を作成（何を作るかを確定）
↓
3. docs/SPEC.md と AGENTS.md を渡して、docs/architecture.md をAIに生成させる（どう作るかを確定）
```
* **理由**: 「何を作るか（機能や画面）」が決まらなければ、どのようなレイヤー分割やRepositoryが必要か（どう作るか）を正しく設計できないためです。
### 3.2 `docs/SPEC.md`（機能仕様書）のインプット & プロンプト
人間側で最初から完璧な仕様書を書く必要はありません。**箇条書きレベル**で十分です。
```markdown
新規アプリの要件・仕様書を作成したいです。
以下のラフなアイデアと要望を元に、要件定義と機能仕様を体系化した `docs/SPEC.md` を作成してください。
不足している考慮点やエッジケース（例外系）があれば、仕様に補完して盛り込んでください。
【アプリ名】タスク管理アプリ「TaskLite」
【ターゲット】日常のやることをシンプルに管理したい個人ユーザー
【欲しい機能】
- タスクの追加・編集・削除・完了チェック
- タスクに優先度（高・中・低）と締切日時の設定
- 端末ローカルへのデータ永続化（オフライン利用）
【画面構成イメージ】
- メイン画面（タスク一覧、優先度フィルター、作成FAB）
- タスク作成・編集モーダル
【デザイン方針】Material 3、片手操作しやすいレイアウト
```
### 3.3 `docs/architecture.md`（アーキテクチャ設計書）のプロンプト
`docs/SPEC.md` と `AGENTS.md` があれば、人間が細部を設計する必要はなく、**AIに9割自動生成させることが可能**です。
```markdown
`AGENTS.md` の設計規約と `docs/SPEC.md` の機能要件をインプットとして、
システム設計書 `docs/architecture.md` を作成してください。
以下の項目を必ず含めてください：
1. システム概要と採用技術スタック（選定理由含む）
2. レイヤードアーキテクチャ構成図（Mermaid のフロー図: Presentation / Logic / Domain / Data）
3. 各レイヤーの責務と具体的なコンポーネント（クラス名・役割）
4. ディレクトリ構成ツリー（lib/ 配下）
5. 主要なデータフロー（例: データ保存時の UI ➔ Notifier ➔ Repository ➔ DB の流れ）
6. 自動テスト方針（単体テスト・ウィジェットテストの検証対象）
```
### 3.4 仕様・設計を深める実践テクニック
* **AIに逆質問させる**: プロンプトの末尾に「**この仕様で実装を進めるにあたり、未定義な部分やエッジケース（例外時の挙動など）があれば、私に質問してください**」と添える。
* **`/grill-me` コマンドの活用**: チャット欄で `/grill-me docs/SPEC.md の内容について設計の抜け漏れがないかレビューして質問してください` と実行し、AIから深掘り質問を受ける。
---
## 4. 自律実装を成功させる実践テクニック（Step 3〜5 詳細）
### 4.1 「機能単位（マイルストーン）」で区切って依頼する
規模が大きいアプリの場合、「アプリ全体を一撃で全部作って」と頼むとAIが息切れして品質が落ちる場合があります。
実務では `docs/SPEC.md` 内にマイルストーンを定義し、**1機能ずつ Step 3 ➔ Step 5 を回す** のが最も確実です。
* **依頼例**:
* 1回目: 「`docs/SPEC.md` のうち、まず **『マイルストーン1: 認証・ログイン機能』** を実装してください」
* 2回目: 「次に **『マイルストーン2: タスク一覧・作成機能』** を実装してください」
### 4.2 「Mock（疑似実装）」を初期仕様に入れておく
バックエンドのAPI（Firebaseや外部サーバー）が未完成でも、仕様書に **「初期は MockRepository（固定アカウントで成功する疑似実装）で動かす」** と明記しておくことで、フロントエンドとUI、状態管理、画面遷移を先行して100%動く状態で完成させられます。API完成後は実装クラスを差し替えるだけで済みます。
### 4.3 「完了条件（Acceptance Criteria）」を箇条書きにする
仕様の末尾にチェックボックス形式（`- [ ]`）で完了条件を書いておくと、AIは **Step 5 の検証フェーズでそのチェックリストを自動テスト（Unit / Widget Test）として網羅しようとする** ため、テスト漏れが劇的に減ります。
### 4.4 完全自動化したい場合（`/goal` コマンド）
「Step 3 の承認ボタンを押す手間すら省いて、夜寝ている間に最後まで自律完走してほしい」場合は、スラッシュコマンド **`/goal`** を利用できます。
例: `/goal docs/SPEC.md のマイルストーン1を、テストが全て通るまで実装・検証してください`
---
## 5. レイヤー順（下位 ➔ 上位）で実装するメリット
UIから作り始めると画面内にロジックが混入（ファットウィジェット化）し、後からの分離が困難になります。
```text
推奨される実装順序:
1. Domain 層 : エンティティモデル、Repository インターフェース
2. Data 層 : 具象ストレージアクセス（API/DB/Prefs）、Repository 実装
3. Logic 層 : Riverpod Notifier（ビジネスロジック & 状態遷移） ★単体テスト作成
4. Presentation 層: UI ウィジェット、画面構築、状態の購読 ★ウィジェットテスト作成
```
1. **ロジックの独立性が保たれる**: UI が存在しない段階でビジネスロジックが完成し、単体テストで完璧に動作保証できる。
2. **UI は単なる「状態の投影」になる**: Presentation 層は Notifier の状態を表示し、イベントを渡すだけの薄いレイヤーになる。
3. **AI の生成コード品質が最大化する**: 契約（Interface/Model）が先に決まっているため、AI が矛盾したコードを生成する確率が劇的に下がる。
---
## 6. プロジェクト内ドキュメント体系の役割分担
| ファイル・配置場所 | 主な役割 | Git管理 | 更新頻度 |
| :--- | :--- | :---: | :--- |
| **`AGENTS.md`** | プロジェクト常時ルール・品質基準・憲法 | ○ 必須 | 初回作成後、規約変更時のみ |
| **`docs/architecture.md`** | システム全体構造・データフロー・レイヤー定義 | ○ 必須 | アーキテクチャ変更時に更新 |
| **`docs/development_workflow.md`** | 開発手順書・ワークフロー（本書） | ○ 必須 | 開発プロセス改善時に更新 |
| **`docs/SPEC.md` / `PLAN.md`** | 機能要件・仕様・機能バックログ | ○ 必須 | 新機能追加や仕様決定の都度 |
| **`implementation_plan.md`**<br>*(Antigravity アーティファクト)* | 単一タスクの実装計画書・変更ファイル一覧 | × 不要<br>*(brain/)* | タスク実行の都度生成 |
| **`walkthrough.md`**<br>*(Antigravity アーティファクト)* | タスク完了報告・検証結果・レビュー資料 | × 不要<br>*(brain/)* | タスク完了の都度生成 |
---
## 7. 【付録】コピペで使える標準テンプレート & 記述具体例
### 付録A: `docs/SPEC.md` 標準フォーマット（雛形）
新規開発時は、以下をコピーして埋めるだけで綺麗な機能仕様書が完成します。
```markdown
# 機能仕様書 (Functional Specification) - [アプリ名]
## 1. 概要 & ゴール
* **アプリ名称**:
* **目的**:
* **主要ターゲット**:
## 2. 画面一覧 & UIフロー
* **画面A (ScreenName)**: 概要と主要UI要素
* **画面B (ScreenName)**: 概要と主要UI要素
* **画面遷移**: [画面A] ➔ (ボタン押下) ➔ [画面B]
## 3. 機能要件 & マイルストーン
### 3.1 【マイルストーン1】[機能名1]
* **UI仕様**:
* **振る舞い・ユースケース**:
* **データモデル・インターフェース**:
* **完了条件 (Acceptance Criteria)**:
- [ ] 〇〇ができること
- [ ] △△のエラーが表示されること
### 3.2 【マイルストーン2】[機能名2]
* **UI仕様**:
* **振る舞い・ユースケース**:
## 4. 非機能要件 & 制約
* **永続化**: 完全オフラインで動作すること（ローカルDB/Prefs利用）。
* **レスポンシブ**: スマホ縦画面を基本としつつ、大画面でもレイアウト崩れしないこと（LayoutBuilder）。
* **アクセシビリティ**: ダークモード/ライトモード両対応。
```
---
### 付録B: `docs/SPEC.md` 記述具体例（認証・ログイン機能）
実務でそのまま使える、マイルストーン1「認証・ログイン画面」の仕様書実例です。
```markdown
# 機能仕様書 (SPEC.md) - TaskLite
## 3. 機能要件 & マイルストーン
### 3.1 【マイルストーン1】認証・ログイン機能 (Authentication)
#### (1) 画面構成 & UI仕様（LoginScreen）
* **配置場所**: `lib/presentation/screens/login_screen.dart`
* **画面要素**:
* **アプリロゴ / タイトル**: 上部にアプリ名とウェルカムメッセージ。
* **メールアドレス入力欄**:
* プレースホルダー: `example@email.com`
* キーボードタイプ: メールアドレス用（`TextInputType.emailAddress`）
* バリデーション: 必須入力、一般的なメアド形式（`@` とドメインを含む）。
* **パスワード入力欄**:
* プレースホルダー: `8文字以上`
* マスク表示（`obscureText: true`）、右端にパスワード表示/非表示の切り替えアイコン（目のアイコン）。
* バリデーション: 必須入力、8文字以上。
* **ログインボタン**:
* Primaryカラーの大型ボタン（ElevatedButton）。
* 押下時: ローディング中はスピナー（CircularProgressIndicator）を表示し、多重タップを防止。
* **補助リンク**:
* 「パスワードをお忘れですか？」（タップでSnackBar「準備中」を表示）
* 「新規アカウント登録」（タップで新規登録画面へ遷移、初期はモック遷移）
#### (2) 振る舞い & ユースケース
* **正常系（ログイン成功）**:
1. ユーザーがメアドとパスワードを入力してログインボタンを押下。
2. 認証処理が走り、成功したらセッショントークン/ログインフラグを端末にローカル永続化（SharedPreferences）。
3. メイン画面（HomeScreen）へ画面遷移（戻るボタンでログイン画面に戻らないよう `pushReplacement`）。
* **異常系（バリデーションエラー）**:
* 入力形式が不正な場合、各入力欄の下に赤字でエラーメッセージを表示（ボタン押下をブロック）。
* **異常系（認証失敗）**:
* 認証エラー（メアドまたはパスワード不一致）の場合、画面下部に SnackBar で「メールアドレスまたはパスワードが正しくありません」を表示。
* **自動ログイン（永続化判定）**:
* アプリ起動時、既にログイン済み情報がローカル保存されていれば、ログイン画面をスキップして直接メイン画面を開く。
#### (3) ドメイン & データ層の要件（Clean Architecture準拠）
* **Entity**: `User` クラス（`id`, `email`, `name`, `token`）
* **Repository インターフェース (`AuthRepository`)**:
* `Future<User> signIn(String email, String password)`
* `Future<void> signOut()`
* `Future<User?> getCurrentUser()` (自動ログイン判定用)
* **実装方針**:
* 初期マイルストーンでは外部API不要の `MockAuthRepository`（テスト用アカウント `test@example.com` / `password123` で成功する疑似実装）を用意し、UIとロジックを先行して完璧に動作させる。
#### (4) 完了条件（Acceptance Criteria）
- [ ] 有効なメアドとパスワードでログインすると、メイン画面に遷移すること。
- [ ] 不正な入力（空文字、7文字以下のパスワード）でエラーが表示されること。
- [ ] アプリを再起動してもログイン状態が維持されていること。
- [ ] 単体テスト（`AuthNotifier`）とウィジェットテスト（`LoginScreen`）が作成され、全テストがパスすること。
```
---
### 付録C: `AGENTS.md` スターター雛形
新規開発時にルートに配置する `AGENTS.md` のテンプレートです。
```markdown
# AGENTS.md - プロジェクト常時ルール・ガイドライン
当ファイルは、AIコーディングアシスタントが当プロジェクトで作業する際に常に遵守すべき最優先のルール・案内図です。
## 1. プロジェクト概要
* **名称**: [アプリ名]
* **目的**: [アプリの目的]
* **技術スタック**:
* **Framework**: Flutter (Material 3)
* **Language**: Dart 3.x+
* **State Management**: flutter_riverpod
* **Local Persistence**: shared_preferences
* **Testing**: flutter_test
## 2. 設計・アーキテクチャ規約
実装にあたっては、必ず docs/architecture.md に定義されたアーキテクチャ方針を遵守してください。
* **レイヤードアーキテクチャの厳格な分離**:
* Presentation層 (`lib/presentation/`): UIウィジェットおよび画面。状態更新ロジックを持たず、Notifierへ委譲。
* Logic層 (`lib/providers/`): RiverpodのNotifierによる状態遷移とビジネスロジック。
* Domain層 (`lib/domain/`): ドメインモデルおよびリポジトリインターフェース。
* Data層 (`lib/data/`): データソースへの具象アクセスおよびリポジトリ実装。
* **依存性の逆転 (DIP)**: ストレージやAPI具象サービスを直接参照せず、Repositoryインターフェースを介してDIすること。
* **モダンDart構文の適用**: `switch` 式、レコードパターン分解、ガード節（`when`）を積極的に利用すること。
* **適応型レスポンシブ設計**: `LayoutBuilder`（`constraints.maxWidth`）を使用すること。
## 3. コード品質・テスト基準
* **Effective Dart準拠**: すべてのパブリッククラス、メソッド、フィールドに `///` ドキュメントコメントを記述。
* **静的解析の維持**: 変更後は `flutter analyze` を実行し、警告・エラー0件であることを確認。
* **自動テストの網羅**: ロジック・UI変更時は単体・ウィジェットテストを更新・実行し、全テストパス（`flutter test`）を必須とする。
## 4. 上位ドキュメント・仕様書の所在マップ
* **開発手順・完全ワークフロー**: `docs/development_workflow.md`
* **全体アーキテクチャ設計書**: `docs/architecture.md`
* **機能仕様書**: `docs/SPEC.md`
* **スキルガイドライン**: `.agents/skills/`
## 5. 開発プロセス
1. **仕様確認**: 実装を開始する前に、必ず関連する設計書や既存コードのインターフェースを確認する。
2. **計画の提示 (Planning)**: 大きな機能追加や仕様変更を行う際は、コードを書き換える前に実装計画書 (Plan) を作成し、人間の承認を得てから実行する。
3. **検証と報告**: 実装後は自動テスト・静的解析をパスさせ、変更内容の検証結果を報告する。
```タッキー先生レビューお願いします！
参考にしたサイト
Google公式「Dart＆Flutter Agent Skills」が開発現場を変える — AIエージェントにFlutter専門知識を与える新手法
「Antigravity」使い方入門｜Google発の最新AIモデルも使える統合開発環境（IDE）
Google Antigravityは「ナビ」ではなく「自動運転」。Gemini 3が勝手に検証して「証拠」を出してくる
