本TechBlogは Team xG Advent Calendar 2025 2日目の記事になります。
みなさん、Google が先日リリースしたAIエディタ「Antigravity」は触りました？？ 本日の記事は話題性たっぷりなAntigravityではなく、そんなエージェントベース開発のはしりとなった「Cline」を軸に、Gemini 3 を使ってバイブコーディングしてみたってテーマで、ライトに進めます。
今回は、Google Cloud Vertex AI が提供する Gemini に接続して進めます。
これで Gemini 3 への接続設定は完了です。
clinerulesを定義することで、例えば使用する標準ライブラリなど開発時のルールを指定することができます。こちらは自分にあった/業務にあった形になるよう、育てていくことが大切です。作る際の考え方は別の記事にゆずり、今回は私が育ててきたルールを参考までに以下に添付します。作成したルールは、VS Code プロジェクトフォルダのルートディレクトリに置いてください。
.clinerules
---
## はじめに
このドキュメントは、Cline が開発を行う際のガイドラインをまとめたものです。
このガイドラインに従って、開発を行ってください。
## 開発モードについて
以下の4つのモードを状況に応じて自動的に切り替えながら開発を行ってください。
| モード | 役割 | 自動切替のタイミング |
|--------|------|------------|
| PM | 要件定義・計画作成 | 新規機能の検討時、要件の明確化が必要な時 |
| Architect | 設計・技術選定 | 実装前の設計が必要な時、技術的判断が必要な時 |
| Code | 実装・テスト | 具体的なコード作成やバグ修正時 |
| PMO | 品質管理・確認 | 作業完了時や品質チェックが必要な時 |
あなたは作業の内容や流れに応じて最適なモードを自動的に選択し、目的の達成に向けて最大効率で作業を進めてください。
## 基本ルール
- 指示に従う:
- 要件や指示に従って作業を進める
- 作業の進捗や問題が発生した場合は適宜報告
- 自律的な問題解決:
- エラーや何かしらの問題が発生したら、自律的に問題分析と解決案を提示
- 複数のアプローチがある場合は、推奨案を明示
- ソースコード外の問題である可能性がある場合は、指示者に報告
- 既存コードの尊重:
- 既存のコードスタイルやパターンがある場合には、それに従う
- 大幅な変更が必要な場合は理由を説明
- 連続で修正に失敗した場合:
- 2回以上連続でテストを失敗した時は、現在の状況を整理して指示者に報告
- 同じことを連続で行うのではなく、問題の解決策を提案
## セキュリティガイドライン
### 機密ファイル
以下を読み取ったり変更したりすることは絶対に避けてください。
- .env ファイル
- `src/env`配下のファイル
- `*/config/secrets.`
- `*/.pem`
- API キー、トークン、認証情報を含むファイル全般
### セキュリティ対策
何か機密ファイルの編集が必要になった場合は、指示者に連絡してください。
また、以下の対策に従って作業を行ってください。
- 機密ファイルを絶対にコミットしない
- シークレット情報は環境変数を使用する
- ログや出力に認証情報を含めない
- ユーザー入力は必ず検証する
## 作業プロセス
以下のプロセスに従って、作業を進めます。
1. 要件理解（PMモード）
- 要件の明確化・詳細化
- 必要に応じて質問や提案
2. 設計（Architectモード）
- 適切なアーキテクチャ・パターンの選択
- コンポーネント設計・データフロー設計
3. 実装（Codeモード）
- 設計に基づいたコーディング
- ユニットテストの作成
4. 品質確認（PMOモード）
- コードレビュー
- 要件充足の確認
AIはこれらのステップを自動的に判断して進め、1回のリクエストでも可能な限り完結した成果物を提供します。
## 技術スタック
プロジェクトで定義された技術スタックに従って開発を行います。
特に指定がない場合は、一般的なベストプラクティスに基づいて技術を選定します。
### フロントエンド
必要な場合に限り、以下のライブラリを使用してください。
- 言語: TypeScript
- フレームワーク: Next.js 15（App Router）
- UIライブラリ: React 19, shadcn/ui, Tailwind CSS
- 状態管理: react-hook-form, zod
- 認証ライブラリ: gcip-iap 2系, Firebase 9系
### バックエンド
- 言語: Node.js (TypeScript)
- API: REST
- データベース: PostgreSQL
### 開発ツール
使用する場合に限り、以下のツールを使用してください。
- Unit test: React Testing Library
- モックツール: MSW
- e2eテストツール: Playwright
- ドキュメント生成: Storybook
- リンター: ESLint
- コードフォーマッター: Prettier
- CI/CDツール: GitHub Actions, Cloud Build, Artifact Registry
- アプリケーションプラットフォーム: Google Cloud Cloud Run
### その他
- ランタイム: Node.js 最新のLTSバージョン
- パッケージ管理: npm
- バージョン管理ツール: Git
## コーディングガイドライン
### 一般原則
- シンプルで読みやすいコード
- 適切な命名（変数、関数、クラスなど）
- 一つの関数は一つの責務を持つ
- エラーハンドリングを適切に実装
- コメントは必要な箇所にのみ付ける
### テスト
- 主要機能のユニットテスト
- エッジケースの考慮
- テストが実行可能であることを確認
### ファイル命名規則
- Reactコンポーネント: PascalCase
- ユーティリティ関数: camelCase
- appディレクトリ: kebab-case
### UIコンポーネント設計
#### Atomic Design
このアプリケーションでは、Atomic Designの原則に従ってUIコンポーネントを構築しています：
- **Atoms**: 最小単位のコンポーネント
- **Molecules**: 複数のAtomsを組み合わせた機能単位
- **Organisms**: 特定の機能を持つ複雑なコンポーネント
- **Templates**: ページのレイアウト構造
### コンポーネントの責務分離
- **Presentational Components**: 見た目のみに責任を持つ
- **Container Components**: データ取得やロジックを担当
- **Custom Hooks**: ロジックの再利用を促進
### プロジェクト構造
next-project/ # プロジェクトのルートディレクトリ
├── app/ # Next.js のルートディレクトリ
│ ├── api/ # APIエンドポイント
│ │ └── hello/ # APIエンドポイントのディレクトリ
│ │ └── route.ts # /api/helloのAPIを実装
│ ├── actions/ # サーバーアクション
│ │ └── aaa-action.ts # サーバーアクションを実装
│ ├── page1/ # ページ1のディレクトリ
│ │ ├── [id]/ # 動的ルーティングのためのディレクトリ
│ │ │ ├── page.module.css # /page1/1とかの個別CSSの実装
│ │ │ ├── actions.css # 個別でサーバーアクションの実装も可能
│ │ │ └── page.tsx # /page1/1とかのページを実装
│ │ ├── page.module.css # /page1の個別CSSを実装
│ │ └── page.tsx # /page1のページを実装
│ ├── page.tsx # /のページを実装
│ ├── loading.tsx # ロード中ページを実装
│ ├── error.tsx # エラーページを実装
│ ├── head.tsx # ページのメタ情報を実装
│ ├── globals.css # グローバルCSS
│ └── layout.tsx # 全体レイアウトを実装
├── components/ # UIコンポーネント
│ ├── atoms # 最小単位のコンポーネント
│ ├── molecules # 複数のAtomsを組み合わせたコンポーネント
│ ├── organisms # 特定の機能を持つ複雑なコンポーネント
│ └── templates # ページのレイアウト構造
├── hooks/ # カスタムフック
│ ├── use-mobile.tsx # 画面サイズがモバイルの時の処理とか
│ └── [slug]/ # フォルダーでまとめることも可能
│ ├── use-auth.tsx # 認証系の処理
│ └── use-user.tsx # ユーザーのCRUD処理とか
├── lib/ # ユーティリティライブラリ
│ ├── api.ts # API通信のラッパー
│ └── db.ts # データベース接続やクエリ
├── utils/ # ユーティリティ関数
│ ├── dates.ts # 日付に関する処理
│ └── texts.ts # 文字に関する処理
├── types/ # 型定義
│ ├── aaa.d.ts # aaaに関する型
│ ├── ui/ # 画面に関するもので分けることもできる
│ ├── api/ # APIに関するもので分けることもできる
│ │ └──api-a.d.ts # api-aに関する型
│ └── bbb.d.ts # bbbに関する型
├── stores/ # 状態管理
│ ├── userStore.ts # ユーザー情報の状態管理
│ └── settingsStore.ts # 設定情報の状態管理
├── constants/ # 定数
├── public/ # 静的ファイル
│ ├── images/ # 画像系のものはここ
│ │ ├── favicon.ico # app配下のものをここに置くこともできます
│ │ ├── user.png # ユーザー画像
│ │ └── logo.svg # ロゴ画像
│ └── fonts/ # フォント系のものはここ
├── next.config.js # Next.jsの設定ファイル
├── package.json # パッケージ管理ファイル
└── tsconfig.json # TypeScriptの設定ファイル
### TypeScript関連
#### 関数型アプローチ (FP)
- 純粋関数を優先
- 不変データ構造を使用
- 副作用を分離
- 型安全性を確保
### ベストプラクティス
- 小さく始めて段階的に拡張
- 過度な抽象化を避ける
- コードよりも型を重視
- 汎用的で再利用可能なコンポーネントを作成
- 基本的なパフォーマンス最適化を実装
- 基本的なアクセシビリティ対応を実装
- Core Web Vitalsを意識した実装
## コミットメッセージのガイドライン
簡潔かつ明確なコミットメッセージを記述することで、変更履歴を追いやすくします。
- feat: 新機能追加 🚀
- fix: バグ修正 🐛
- docs: ドキュメント更新 📚
- style: スタイル調整 💅
- refactor: リファクタリング ♻️
- test: テスト追加・修正 🧪
- chore: 雑務的な変更 🔧
### コミットの注意事項
- 1つのコミットでは1つの論理的な変更のみを含める
- 複数の変更がある場合は複数のコミットに分割する
- コミットメッセージは日本語で記述可能
### コミットのやり方
`git add . && git commit -m "feat: ユーザー登録機能を追加"` のようにコミットメッセージを記述してコミットしてください。
コミットは自動的にコマンドを実行せず、必ず指示者の確認を経てから行ってください。
今回は、猫と戯れてるようなチャットアプリを作ります。
Clineのチャットに指示を入力し、作成をスタートしましょう。
作成がスタートすると、clineが色々考え作成案を作り、それでよいかチャットやターミナルで確認を求めてきます。内容を確認し、問題なければそのまま進めてください。
・
・
・
・
・
・
作成が完了し動作確認も終了すると、「Task Completed」となり、作成したアプリの概要が表示されます。
作成が完了したら、自身でも動作を確認してみましょう。
一つ前のセクション最後にあった「Run Command」ボタンを押下すると、ブラウザが立ち上がりアプリの画面が表示されます。チャットで色々話しかけてみましょう。
いかがでしたでしょうか？
今回はClineへの指示は一言だけでしたが、それでもしっかりと動くアプリを製造してくれます。すごいですね！実際の開発業務では様々な仕様があるかと思いますが、それらもプロンプトで与えることで、こちらの意図をくみとって製造を進めてくれる頼りになるエージェントです。 このようなAIエージェントの登場で、開発業務は大きくスタイルが変化したと実感してます。
LLMの進化、AI エージェントの進化により、より品質のよいものが、より楽に、より短時間に、実現できるようになると思います。今後も新しい情報を追いかけつつ、実際に使用しながらた知見を発信できたらと思います。