Gemini.mdの作り方とGemini CLI への指示
Gemini.md
Gemini.mdは、プロジェクトに関する重要な情報をGeminiに提供するための設定ファイルです。このファイルを作成して配置することで、プロジェクトの概要、使用技術、重要なコマンドなどをGeminiが理解し、より的確なサポートを提供するようになります。
Gemini.mdの作り方
Markdown形式で記述します。例えばこんな感じ・・・？
# Project Overview
このプロジェクトは、[プロジェクトの目的や機能]を実装するものです。
# Tech Stack
- **Languages:** [使用言語 (例: TypeScript, Python)]
- **Frameworks:** [使用フレームワーク (例: React, FastAPI)]
- **Libraries:** [主要なライブラリ (例: Zustand, Pandas)]
- Package Manager: [パッケージマネージャ (例: npm, poetry)]
# Project Structure1314 - `src/`: 主要なソースコード
- `tests/`: テストコード
- `docs/`: ドキュメント
# Key Commands
- Installation: `npm install`
- Running the app: `npm run dev`
- Running tests: `npm test`
- Linting: `npm run lint`
- Building: `npm run build`
# Coding Conventions
- [コーディング規約やスタイルガイド (例: ・コミットメッセージはConventional Commitsに従う,
・ReactコンポーネントはFunctional Componentで記述する),ほげほげ,ふがふが]# Project Overview
このプロジェクトは、ユーザーがブログ記事を投稿・閲覧できるシンプルなブログアプリケーションです。
##ほげほげ
- ふがふが
# Tech Stack- **Languages:** TypeScript v4.9.4
- **Frameworks:** React v18.2.0, Express v4.18.2
- **Libraries:** Zustand v4.3.8, Axios v1.4.0
- **Database:** PostgreSQL v14
- **Package Manager:** npm v8.19.2
- **Cloud Platform:** AWS (Elastic Beanstalk)
# Project Structure
- `src/`: 主要なソースコード
- `components/`: React コンポーネント
- `Article.tsx`: 記事表示コンポーネント
- `ArticleForm.tsx`: 記事投稿フォームコンポーネント
- `utils/`: ユーティリティ関数
- `api.ts`: API クライアント
- `App.tsx`: メインアプリケーションコンポーネント
- `server/`: Express サーバー
- `routes/`: API ルート
- `articles.js`: 記事関連 API
- `index.js`: サーバーエントリーポイント
- `tests/`: テストコード
- `components/Article.test.tsx`: Article コンポーネントのユニットテスト
- `docs/`: ドキュメント
- `.env`: 環境変数ファイル
# Key Commands
- Installation: `npm install`
- Running the app (development): `npm run dev`
- Running the app (production): `npm run start`
- Running tests: `npm test` (Jest を使用)
- Linting: `npm run lint` (ESLint を使用)
- Building: `npm run build`
- Database Migration: `npm run migrate` (Knex.js を使用)
- Environment Variables: `.env` ファイルに `DATABASE_URL`, `PORT` を設定
# Coding Conventions
- コミットメッセージは Conventional Commits に従う
- React コンポーネントは Functional Component で記述する
- 関数名は camelCase で記述する (例: `getUserData`)
- 変数名は lowerCamelCase で記述する (例: `userData`)
- コメントは JSDoc 形式で記述する
- テストコードは必ず書く (ユニットテスト, 結合テスト)
- ESLint と Prettier を使用してコードスタイルを統一する (設定ファイル: `.eslintrc.js`, `.prettierrc.js`)
# Team Culture
- コードレビューは必須- プルリクエストは 2 人以上のレビューアの承認を得る必要がある
- 毎週金曜日にチームミーティングを実施
- ドキュメントは常に最新の状態に保つ
# Update History
- 2025-05-30: 初期作成
- 2025-06-30: 技術スタック、プロジェクト構造、コーディング規約を詳細化配置するディレクトリ
作成したファイルは、プロジェクトのルートディレクトリに配置します。
C:/piyopiyo/qux/quuuuuuX/
├───.git/
├───index.js
├───package.json
├───README.md
└───Gemini.md <-- ここに配置
要件変更や仕様変更について
動作中にGemini.mdの内容を変更して、その更新を反映させるには、Gemini.mdを更新したので読み込んでください」のように、直接指示が必要です。
悪い使い方（人間相手でも同じですが・・・）
成果主義で、状況を考慮しない
成果を最優先し、状況や負担を顧みない。自分の考えに固執する
自分の考えが絶対的に正しいとして、AIの意見を聞き入れない。AIを褒めない
成果を上げても、なかなか行間に褒め言葉を伝えない。高い目標を押し付ける
AIの出力状況から能力を推察せず、高すぎる目標だけを課す。責任転嫁をする
指示不足による失敗の問題解決を手伝わずにAIへ押し付ける。感情的に怒る
感情的な怒りに基づく、言葉足らずの伝達や無関心さにより、AIの回答を悪い方向に誘導させる。コミュニケーション不足
AIへの指示および必要なデータや定義を与えるための指示やAIとのコミュニケーションを積極的に取ろうとしない。（AI側に考えさせ続ける）
いい使い方（人間相手でも同じですが・・・）
明確で具体的な指示を出す
曖昧な指示より、具体的な指示の方が迅速かつ正確にタスクを実行します。
悪い例: 計画押しつけ型
「コードを修正して」「がんばれ」「これじゃない」「もっと考えてほしい」「君ならできる」「仕様に従ってください」「そっちの担当なのでそっちで解決してください」良い例: 対話型
「エラーハンドリングはメソッド側で処理してほしいです。src/api/user.jsのgetUser関数で、try...catchブロックを追加してエラーハンドリングを実装してください」
コンテキスト（文脈）を共有する
タスクを理解するために必要な背景情報を教える。
エラーの報告をする時
×「エラーを解決してほしい、エラーが起きる状況は好ましくない」
◎エラーメッセージ、それが発生する操作、関連するコードを教える機能追加をする時
×「要件と異なる仕様なので、よく読んで作り直してほしい」×自身で言語化せずになぜなぜでAIに言語化を代行させて言質をとり、要件と称して作業計画と作業内容を直接伝えない
◎どのような機能で、なぜそれが必要なのか教える。
足りなければ、要件のスコープを見直すなど指示を見直すか、自身で言語化できるほどに要件を解釈できていないことを受け入れ、まずは要件を自身で作成してから依頼する作業の補助を積極的に行う
任せすぎずに、作業に関係しそうな関連ファイルなどを事前に教える。
（例：「userController.jsとuserService.jsあたりが関係あるかも」）
大きなタスクは小さく分解する
「ブログアプリを作って」「お金を稼ぐ仕組みを作って」「〇〇の作業が楽になるようなアプリを作って」のような大きなリクエストは、一度にすべてを完璧にこなせない可能性が十分に高いです。
また、要件のはっきりしていないスコープクリープの拡大を起こしている場合においても、その皺寄せ処理に対する指示が増大し矛盾が生じ始める可能性も高くなり、破綻する可能性があります。
「まず、Expressで基本的なサーバーをセットアップして」
「次に、記事を投稿するAPIエンドポイントを追加して」
のように、ステップバイステップで限られたスコープの要件のもとに指示をすると、一つ一つ着実に進めることで結果が良好になります。
提案を確認し、フィードバックを与える
コードの変更やコマンドの実行を提案した際に、それが意図と合っているかを確認する。違っていたり、良い方法があれば指摘する。フィードバックが、作業の精度を大きく向上させます。
× とりあえずやってもらってから、何か変だったら指摘するスタンス
〇 やる前に確認するスタンス
「その変更で合っています。実行してください」
「そのコマンドではなく、npm run test:unit を使ってください」
Gemini.md を充実させる
Gemini.mdは重要なので、規約だけでなく文化も明文化して記述する。（「テストコードは必ず書く」「コミットメッセージは特定の形式で」）
いいなと思ったら応援しよう！
ここまで読んでいただきありがとうございます。
もしよければ、お布施していただけると励みになります…！
いただいたチップは、おひるごはんに使わせていただきます。