SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

計画的な作業指示書で Gemini CLI の実力を引き出す

2025.10.30

はじめに

2025年6月25日にGemini CLI が登場しました。Gemini CLI はコマンドラインで起動し、ローカルにあるコードを理解し、様々なタスクを実行することができます。本稿ではその中でも、筆者が業務で取り扱っているフロントアプリケーション開発を題材として利用例を見ていきます。

なぜ Gemini CLI なのか？
無料プラン：Google 個人アカウントで毎分 60 リクエスト、1日 1,000 リクエストまで利用可能
高性能 Gemini 2.5 Pro：100万トークンのコンテキストウィンドウにアクセス可能
組み込みツール：Google検索連携、ファイル操作、シェルコマンド、Web取得
拡張可能：MCP（Model Context Protocol）対応でカスタム統合が可能
ターミナル特化：コマンドラインで作業する開発者向けに設計
オープンソース：Apache 2.0 ライセンス
（出典：Google 公式 Gemini CLI リポジトリ ）

本記事では、AIエージェント（Gemini CLI）をフロントアプリケーション開発に効果的に利用するためのポイントを開発の順序に沿って説明します。

目次

  • Gemini CLI 環境の準備
    • GEMINI.md は作業指示書
    • 階層的に GEMINI.md を作成し汎用的な指示と作業別の詳細指示を分ける
    • /memoryコマンドで PJ 別の GEMINI.md を記憶させることも可能
  • 人と AI が対話しながら開発を行う
  • Gemini CLI の Tips
    • 作業の記録（Git）
    • 品質の確保（静的解析、テストコード）
    • yolo（ヨロモード）
    • 現地現物現実を見る

凡例

人の指示、入力

Gemini の回答、説明

Gemini CLI 環境の準備

以下のコマンドでインストールできます。APIキーの設定などの詳細は公式の手順をご参照ください。

npx https://github.com/google-gemini/gemini-cli

または

npm install -g @google/gemini-cli
gemini

GEMINI.md は作業指示書

GEMINI.mdは人が Gemini と対話して作業依頼する際に Gemini に伝えたい作業の前提となる知識や作業の進め方を伝える作業指示書です。プロジェクト全体の共通ルールはルートフォルダのGEMINI.mdに書き、各ディレクトリの作業指示書を参照させるようにします。

プロジェクトルート
├ README.md
├ GEMINI.md
└ ./gemini
      └ gemini-guides
        └ PLAN_GUIDE.md
        └ GIT_GUIDE.md
        └ TESTING_GUIDE.md
        └ DOC_GUIDE.md

以下は筆者が利用している指示書のサンプル抜粋です。朝から夕方までGemini CLIで開発を進めていくとGeminiが徐々にルールを忘れていくようになりました。何か対策が無いかと思い「これは重要なルールです」という一文を添えたところ、Geminiが作業の開始前に忘れずに計画を立てるようになった印象があります。あくまで筆者の体験談ではございますが参考になればと思い、お伝えします。
GEMINI.md

# ルール

- ルールを遵守すること。
- 日本語で会話すること。
- README.md に記載されている背景情報を読み込むこと。
- 計画を立てる際には `.gemini/gemini-guides/PLAN_GUIDE.md` の情報を読み込みルールに沿って計画を立てること。これは重要なルールです。
- `.gemini/gemini-guides/` 配下のルールは全て読み込むこと。
  - GIT_GUIDE.md
  - DOC_GUIDE.md
  - TESTING_GUIDE.md
  - COMPONENT_GUIDE.md
README.md 
# 目的
- React UI コンポーネントをライブラリを作成します。
- 実装されたReactコンポーネントはStorybook上でカタログ化され、ブラウザ上で実際に操作・確認できます。

## 技術スタック
- React
- TypeScript
- shadcn/ui
- Storybook
- Vite
- React Testing Library, Vitest
PLAN_GUIDE.md 
1. 事前準備フェーズ

- ユーザーが Gemini に対して、実行したいタスクの概要を伝える
- このフェーズで !mkdir -p ./.gemini/specs を実行します
- ./gemini/specs 内にタスクの概要から適切な spec 名を考えて、その名前のディレクトリを作成します
- たとえば、「記事コンポーネントを作成する」というタスクなら ./.gemini/specs/create-article-component という名前のディレクトリを作成します
- 以下の各フェーズで利用するファイルはこのディレクトリの中に作成します
- ファイル名は GEMINI_PLAN.md です。GEMINI_PLAN.md に計画を追記する際には過去のフェーズの計画を消さないでください。これは重要なルールです。
- タスクのフォーマットは次のサンプルのようにしてください。日本時間です。 [✓] `glob` を使用して `src/components/**/*.stories.tsx` に一致するファイルを取得する (2025-08-13 21:20)

2. 要件フェーズ

- Gemini がユーザーから伝えられたタスクの概要に基づいて、タスクが満たすべき「要件ファイル」を作成する
- Gemini がユーザーに対して「要件ファイル」を提示し、問題がないかを尋ねる
- ユーザーが「要件ファイル」を確認し、問題があれば Gemini に対してフィードバックする
- ユーザーが「要件ファイル」を確認し、問題がないと答えるまで「要件ファイル」に対して修正を繰り返す

3. 設計フェーズ

- Gemini は、「要件ファイル」に記載されている要件を満たすような設計を記述した「設計ファイル」を作成する
- Gemini がユーザーに対して「設計ファイル」を提示し、問題がないかを尋ねる
- ユーザーが「設計ファイル」を確認し、問題があれば Gemini に対してフィードバックする
  ユーザーが「設計ファイル」を確認し、問題がないと答えるまで「要件ファイル」に対して修正を繰り返す

4. 実装計画フェーズ

- Gemini は、「設計ファイル」に記載されている設計を実装するための「実装計画ファイル」を作成する
- Gemini がユーザーに対して「実装計画ファイル」を提示し、問題がないかを尋ねる
- ユーザーが「実装計画ファイル」を確認し、問題があれば Gemini に対してフィードバックする
- ユーザーが「実装計画ファイル」を確認し、問題がないと答えるまで「要件ファイル」に対して修正を繰り返す
- 「実装計画」ファイルはチェックリスト形式で出力する

5. 実装フェーズ

- Gemini は、「実装計画ファイル」に基づいて実装を開始する
- 実装するときは「要件ファイル」「設計ファイル」に記載されている内容を守りながら実装してください
- 「実装計画ファイル」の内容が完了した際に、チェックリストにチェックをつける

/memory コマンド

メモリーコマンドは重要です。GEMINI.md ファイルを使って、プロジェクトやフォルダ単位で作業指示（文脈）を定義して記憶させたり読み込ませることができます。

コマンド 機能説明
/memory add “…” 作業指示をGEMINI.mdに保存
/memory show 保存済みの記憶（および読み込み元）を表示
/memory refresh 外部編集後の.mdファイル内容を再読み込み

メモリーコマンドで適切に作業指示を保存することも重要ですが、作業指示書が多くなると Gemini は指示書を読まなくなります。作業を依頼する時には参照して欲しい指示書を @ ファイルパスで指定すると確実に作業指示を読んでくれます。

テストカバレッジが下がっています。テストの計画を立ててください @GEMINI.md @.gemini/gemini-guides/PLAN_GUIDE.md

人と AI が対話しながら開発を行う

Gemini に指示を出し、アプリケーションを開発します

PLAN_GUIDE.mdの指示に沿って段階的に Gemini が計画を行います。アプリケーション開発の方向性を人とすり合わせながら作業を進めていきます。

  1. 事前準備フェーズ
  2. 要件定義フェーズ
  3. 設計フェーズ
  4. 実装計画フェーズ
  5. 実装フェーズ

まずは作業の概要を人から Gemini に伝えます。

> React UI コンポーネントライブラリを構築します。Storybook 上にカタログ化されており、ブラウザで操作・確認できるものを作りたいです。まずは環境を構築する計画を立ててください

事前準備フェーズ

✦ 承知いたしました。React UIコンポーネントライブラリの環境構築ですね。まずは、README.mdとPLAN_GUIDE.mdを拝見し、プロジェクトのルールや計画の指針を確認します。
まずは事前準備フェーズとして、計画を管理するためのディレクトリとファイルを作成します。
今回のタスク名は create-react-ui-library-env とします。
✔ Shell mkdir -p ./.gemini/specs/create-react-ui-library-env (計画を管理するためのディレクトリを作成します。)

要件定義フェーズ

✦ 計画ファイルの準備ができました。
次に要件定義フェーズとして、環境構築の要件を定義します。

要件

  • Vite を使用して React + TypeScript プロジェクトをセットアップする。
  • Storybook を導入し、コンポーネントを視覚的に確認できる環境を構築する。
  • shadcn/ui を導入し、UIコンポーネントのベースとして利用できるようにする。
  • ESLint と Prettier を導入し、コードの品質とフォーマットを維持する。
  • Vitest と React Testing Library を導入し、コンポーネントのテストができる環境を構築する。
  • README.md に記載されている npm scripts (storybook, test, build, lint, lint:fix, format) を実行できるようにpackage.json を設定する。

こちらの要件で問題ないでしょうか？

はい

Gemini が要件定義を行い、ユーザーに内容を確認します。要件定義が誤っている場合は指示を出し直して方向性を修正することができます。

設計フェーズ

承知いたしました。要件についてご承認いただきありがとうございます。
それでは、設計フェーズに進みます。
以下の設計で環境構築を進めたいと思いますが、いかがでしょうか。

設計

1.プロジェクト初期化:
◦npm create vite@latest . -- --template react-ts を実行し、React と TypeScript のViteプロジェクトをカレントディレクトリにセットアップします。

2.Storybook の導入:
◦npx storybook@latest init を実行し、Storybook を自動でセットアップします。Viteとの連携も自動で行われます。

3.shadcn/ui の導入:
◦npx shadcn-ui@latest init を実行し、shadcn/ui を初期化します。これにより、components.jsonが作成され、CLI を使用してコンポーネントを追加できるようになります。

4.リンターとフォーマッターの導入:
◦ESLint と Prettier、および関連プラグインを npm でインストールします。
◦.eslintrc.cjs と .prettierrc.json を作成し、標準的なルールセットを設定します。

5.テスト環境の導入:
◦Vitest, React Testing Library, jsdom などのテスト関連ライブラリを npm でインストールします。
◦vite.config.ts に Vitest の設定を追記し、テスト環境をセットアップします。
◦React Testing Library のカスタムマッチャーを読み込むための setupTests.ts ファイルを作成します。

6.npm scripts の設定:
◦package.json の scripts フィールドを編集し、README.md に記載されているすべてのコマンド (storybook, test,build, lint, lint:fix, format) を追加します。

こちらの設計で問題ないでしょうか？

はい

実装計画フェーズ

✦ 設計にご承認いただきありがとうございます。
それでは、実装計画フェーズに進みます。
以下の実装計画で環境構築を進めます。

実装計画

  • [ ] Viteプロジェクトを初期化する (2025-08-15 10:00)
  • [ ] Storybook を導入する (2025-08-15 10:05)
  • [ ] shadcn/ui を導入する (2025-08-15 10:10)
  • [ ] リンターとフォーマッターを導入する (2025-08-15 10:15)
  • [ ] テスト環境を導入する (2025-08-15 10:20)
  • [ ] package.json に npm scripts を設定する (2025-08-15 10:25)

この計画を GEMINI_PLAN.md に保存します。

主に GEMINI が計画し、人が承認した作業計画（GEMINI_PLAN.md）は以下のようになります。

.gemini/specs/create-react-ui-library-env/GEMINI_PLAN.md 
# 計画: React UIコンポーネントライブラリの環境構築

## 概要
このドキュメントは、Storybookでカタログ化されたReact UIコンポーネントライブラリの開発環境を構築するための計画を記述したものです。
要件定義、設計、そして実装のチェックリストの3つのフェーズで構成されています。

---

### 要件定義
*   Vite を使用して React + TypeScript プロジェクトをセットアップする。
*   Storybook を導入し、コンポーネントを視覚的に確認できる環境を構築する。
*   `shadcn/ui` を導入し、UIコンポーネントのベースとして利用できるようにする。
*   ESLint と Prettier を導入し、コードの品質とフォーマットを維持する。
*   Vitest と React Testing Library を導入し、コンポーネントのテストができる環境を構築する。
*   `README.md` に記載されている npm scripts (`storybook`, `test`, `build`, `lint`, `lint:fix`, `format`) を実行できるように `package.json` を設定する。

### 設計
1.  **プロジェクト初期化**:
    *   `npm create vite@latest . -- --template react-ts` を実行し、React と TypeScript の Vite プロジェクトをカレントディレクトリにセットアップします。
2.  **Storybook の導入**:
    *   `npx storybook@latest init` を実行し、Storybook を自動でセットアップします。Vite との連携も自動で行われます。
3.  **shadcn/ui の導入**:
    *   `npx shadcn-ui@latest init` を実行し、`shadcn/ui` を初期化します。これにより、`components.json` が作成され、CLI を使用してコンポーネントを追加できるようになります。
4.  **リンターとフォーマッターの導入**:
    *   ESLint と Prettier、および関連プラグインを `npm` でインストールします。
    *   `.eslintrc.cjs` と `.prettierrc.json` を作成し、標準的なルールセットを設定します。
5.  **テスト環境の導入**:
    *   Vitest, React Testing Library, jsdom などのテスト関連ライブラリを `npm` でインストールします。
    *   `vite.config.ts` に Vitest の設定を追記し、テスト環境をセットアップします。
    *   React Testing Library のカスタムマッチャーを読み込むための `setupTests.ts` ファイルを作成します。
6.  **npm scripts の設定**:
    *   `package.json` の `scripts` フィールドを編集し、`README.md` に記載されているすべてのコマンド (`storybook`, `test`, `build`, `lint`, `lint:fix`, `format`) を追加します。

### 実装計画

*   [ ] Viteプロジェクトを初期化する (2025-08-15 10:00)
*   [ ] Storybook を導入する (2025-08-15 10:05)
*   [ ] shadcn/ui を導入する (2025--08-15 10:10)
*   [ ] リンターとフォーマッターを導入する (2025-08-15 10:15)
*   [ ] テスト環境を導入する (2025-08-15 10:20)
*   [ ] `package.json` に npm scripts を設定する (2025-08-15 10:25)

実装フェーズ

✦ 計画の準備が整いました。

これより実装フェーズを開始します。まずはViteプロジェクトを初期化します。
✔ Shell npm create vite@latest . -- --template react-ts

✦ 無事にViteプロジェクトの初期化が完了しました。
計画のチェックリストを更新します。

GEMINI_PLAN.md 
1   ### 実装計画
2
3 - *   [ ] Viteプロジェクトを初期化する (2025-08-15 10:00)
3 + *   [✓] Viteプロジェクトを初期化する (2025-08-15 10:00)
4   *   [ ] Storybook を導入する (2025-08-15 10:05)
5   *   [ ] shadcn/ui を導入する (2025-08-15 10:10)
6   *   [ ] リンターとフォーマッターを導入する (2025-08-15 10:15)

と、このような形で実装計画に沿って Gemini が開発を進めていきます。
ある程度の時間作業を進めていくと以下のように Storybook を構築することができました。

Gemini CLI の Tips

作業の記録（Git）

筆者はGEMINI.mdに作業が完了する度に git add . , git commit を実行することという一行を足しています。そしてgit pushをしないことという重要なルールも追加しています。
Gemini は昨日の作業内容のことは忘れています。起動する度に過去の文脈がクリアされているからです。

昨日まで動いていたコードが Gemini がたくさん作業をしたことによって壊れてしまうことがあります。壊れたことに気がついた後に Gemini に「昨日のコードに戻して」と依頼しても手遅れです。旧戻しを行うためには Git を使うことを推奨します。

また、前述の作業単位で計画をさせていることも Gemini の作業内容を記録させていく上でも有効です。いくら AI が便利だとしても、最後の説明責任は人に残ると筆者は思っています。作業の記録が残るための仕組みを準備することをおすすめします。

品質の確保（静的解析・テストコード）

Gemini が開発するコードは頻繁にエラーを出します。「作業が終わりました」と Gemini が言うのでアプリを触ってみるとエラーが出ていて起動すらしない・・・ということが普通に発生します。
Gemini CLI はアプリ起動して、動作確認をしてくれません。（ MCP やプロンプトの工夫でやってくれるようになるかもしれません）

では、このような場合はどうすべきでしょうか。
答えはシンプルで、これまで人が行ってきたように細かな作業の単位で静的解析（Lint, Prettier）をしたり、テストコードを書いてミス・デグレードが発生していないかを潰し込んでいくことが大切です。

筆者はTESTING_GUIDE.mdに作業が完了する度に npm run prettier, npm run lint, npm run test を実行すること。と指示をしています。この1行があるか無いかで大きく Gemini の手戻りが減少することを体感しています。
本稿では要件定義→設計→実装という順序で工程定義をしていますが、テスト駆動開発（TDD: Test-Driven Development）のプロセスを実践すると手戻りが減るため Gemini CLI を用いたフロントアプリケーション開発では有効です。

（出典）React で紐解くモダンフロントエンド開発の歴史と進歩 | TECH | NRI Digital

--yolo（ヨロモード）

You Only Live Onceモードは Gemini がコマンドの実行やファイルの更新前に確認を求めずに、全て自動で承認します。便利ではあるのですが、何でもかんでも承認してしまうと意図しないファイル削除や大規模なコード変更などを引き起こします。

Gemini は大胆なコード変更を加える印象があります。ビッグバン変更を加えてしまい全体が動かなくなるという状態もよく遭遇します。そういった時は、一度 Gemini を落ち着かせて静的解析させたり、テストコードを動かさせたり、どうしようも無ければ git で旧戻しさせます。ヨロモードは便利ですが用法用量を守りましょう。

現地現物現実を見る

Gemini はとても便利ですが、ハマり始めるとずっと同じことを延々と繰り返します。 Gemini と対話を続けるよりもコードを自分自身で読み、理解して問題解決に向けて適切な指示を出すことが大切だと感じています。Gemini の作業生産性が下がってきたことを感じたら、早々に現地現物現実を見に行くのがよいでしょう。

おわりに

Gemini CLI を利用していく中で、以下に指示書を丁寧に作るかが Gemini の性能を引き出すポイントだと感じています。実践を繰り返していく中で更によい使い方が発見できると思いますので、その際にはまたお伝えできればと考えております。