Gemini CLI を使った開発では、適切なプロンプトを投げることで作業効率が劇的に向上します。しかし、毎回ゼロからプロンプトを考えるのは時間がかかりますし、プロンプトの品質にばらつきが出てしまうことも少なくありません。

本記事では、実務で頻繁に使われる「仕様化」「バグ調査」「コード変換」の 3 つのカテゴリに分けて、合計 40 個のプロンプトテンプレートをご紹介します。これらの雛形をそのままコピーして使うことも、プロジェクトに合わせてカスタマイズすることもできますので、ぜひ日々の開発にお役立てください。

プロンプト早見表

#	カテゴリ	プロンプト名	用途	難易度
1	仕様化	要件定義書生成	ユーザーストーリーから要件定義書を作成	★★☆
2	仕様化	API 仕様書作成	エンドポイント情報から OpenAPI 仕様を生成	★★★
3	仕様化	データベーススキーマ設計	業務要件から ER 図とテーブル定義を作成	★★★
4	仕様化	ユースケース図生成	機能要件からユースケース図を作成	★★☆
5	仕様化	シーケンス図作成	処理フローからシーケンス図を生成	★★★
6	仕様化	クラス図設計	オブジェクト指向設計からクラス図を作成	★★★
7	仕様化	テストケース生成	機能仕様からテストケースを自動生成	★★☆
8	仕様化	インターフェース定義	TypeScript 型定義を業務仕様から作成	★★☆
9	仕様化	状態遷移図作成	ステートマシン設計から状態遷移図を生成	★★★
10	仕様化	バリデーションルール定義	入力制約からバリデーション仕様を作成	★☆☆
11	仕様化	エラーハンドリング仕様	エラーケースからエラー処理仕様を作成	★★☆
12	仕様化	セキュリティ要件定義	脅威分析からセキュリティ仕様を作成	★★★
13	仕様化	パフォーマンス要件定義	性能目標からパフォーマンス仕様を作成	★★☆
14	仕様化	アーキテクチャ設計書	システム要件からアーキテクチャ図を作成	★★★
15	仕様化	コンポーネント設計書	UI 要件からコンポーネント仕様を作成	★★☆
16	バグ調査	エラーログ解析	スタックトレースから原因を特定	★★☆
17	バグ調査	パフォーマンス問題診断	プロファイリング結果からボトルネックを特定	★★★
18	バグ調査	メモリリーク検出	メモリ使用状況から原因を特定	★★★
19	バグ調査	デッドロック解析	スレッドダンプから競合状態を特定	★★★
20	バグ調査	型エラー診断	TypeScript エラーから原因と解決策を提示	★★☆
21	バグ調査	API 通信エラー解析	ネットワークエラーから原因を特定	★★☆
22	バグ調査	データベースクエリ最適化	スロークエリから改善策を提示	★★★
23	バグ調査	フロントエンドエラー診断	ブラウザコンソールエラーから原因を特定	★★☆
24	バグ調査	ビルドエラー解析	コンパイルエラーから解決策を提示	★☆☆
25	バグ調査	依存関係エラー解析	パッケージ競合から解決策を提示	★★☆
26	バグ調査	テスト失敗原因分析	テストログから失敗原因を特定	★★☆
27	バグ調査	セキュリティ脆弱性診断	コードから脆弱性を検出し修正案を提示	★★★
28	バグ調査	レンダリング問題診断	React/Vue のレンダリング問題を特定	★★☆
29	バグ調査	状態管理バグ解析	Redux/Zustand の状態不整合を特定	★★★
30	バグ調査	非同期処理エラー診断	Promise/async-await のエラーを特定	★★☆
31	コード変換	JavaScript→TypeScript 変換	JS コードを TS 型定義付きに変換	★★☆
32	コード変換	Class→ 関数コンポーネント変換	React クラスコンポーネントを Hooks に変換	★★☆
33	コード変換	REST API→GraphQL 変換	REST エンドポイントを GraphQL スキーマに変換	★★★
34	コード変換	SQL→ORM 変換	SQL クエリを Prisma/TypeORM に変換	★★☆
35	コード変換	CSS→Tailwind 変換	通常の CSS を Tailwind クラスに変換	★★☆
36	コード変換	CommonJS→ESModule 変換	require/exports を import/export に変換	★☆☆
37	コード変換	Redux→Zustand 変換	Redux 状態管理を Zustand に移行	★★★
38	コード変換	Webpack→Vite 変換	Webpack 設定を Vite 設定に移行	★★★
39	コード変換	Jest→Vitest 変換	Jest テストコードを vitest に変換	★★☆
40	コード変換	Options API→Composition API 変換	Vue 2 スタイルを Vue 3 に変換	★★★

背景

Gemini CLI の台頭と開発現場での活用

近年、AI 技術の進化により、開発者の作業を支援するツールが次々と登場しています。その中でも、Google が提供する Gemini CLI は、コマンドラインから直接 AI と対話できる強力なツールとして注目を集めています。

Gemini CLI の特徴は以下の通りです。

高性能な自然言語処理 Gemini モデルは、複雑な技術文書や大量のコードを理解し、的確な回答を生成できます。要件定義書の作成からバグ原因の特定まで、幅広いタスクに対応可能です。

マルチモーダル対応 テキストだけでなく、画像や PDF なども入力として受け付けるため、設計図やエラースクリーンショットを直接渡して分析してもらうこともできます。

コンテキスト理解能力 長い会話履歴を保持し、前後の文脈を踏まえた回答を生成します。これにより、段階的な仕様策定やデバッグ作業がスムーズに進みます。

下図は、Gemini CLI を使った典型的な開発フローを示したものです。

mermaidCopy codeflowchart TB
  dev["開発者"] -->|プロンプト入力| cli["Gemini CLI"]
  cli -->|API リクエスト| gemini["Gemini AI<br/>モデル"]
  gemini -->|生成結果| cli
  cli -->|出力| result["仕様書 / コード /<br/>デバッグ情報"]
  result -->|確認・修正| dev

  style gemini fill:#e1f5ff
  style cli fill:#fff3e0
  style result fill:#f1f8e9

このフローでは、開発者がプロンプトを入力すると、Gemini AI がそれを解釈し、適切な成果物を生成します。生成された結果を確認し、必要に応じて修正指示を出すことで、高品質なアウトプットが得られます。

プロンプトエンジニアリングの重要性

Gemini CLI の性能を最大限に引き出すには、プロンプトの品質が非常に重要です。同じ要求でも、プロンプトの書き方次第で結果が大きく変わります。

たとえば、「API 仕様書を作ってください」という曖昧な指示では、期待通りの出力が得られないことがあります。一方、「以下のエンドポイント一覧から OpenAPI 3.0 形式の仕様書を作成してください。各エンドポイントには、リクエスト/レスポンスのスキーマ、エラーコード、認証方法を含めてください」と具体的に指示すれば、高品質な仕様書が生成されます。

プロンプトエンジニアリングのポイントは次の通りです。

具体性 曖昧な表現を避け、期待する出力形式や含めるべき情報を明示します。

構造化 箇条書きや番号付きリストを使って、指示を整理します。

例示 サンプルコードや期待する出力例を示すことで、AI の理解を助けます。

反復改善 初回の出力を確認し、追加指示で品質を高めていきます。

課題

プロンプト作成の試行錯誤コスト

Gemini CLI は強力なツールですが、適切なプロンプトを作成するには時間がかかります。特に初心者は、どのように指示を出せば良いか分からず、何度も試行錯誤を繰り返すことになります。

以下のような課題が開発現場で発生しています。

時間的コスト プロンプトの作成と調整に予想以上の時間がかかり、本来の開発作業が圧迫されます。

品質のばらつき 人によってプロンプトの書き方が異なるため、同じタスクでも出力品質にばらつきが生じます。

知識の属人化 優れたプロンプトを書ける人とそうでない人で、作業効率に大きな差が出ます。

再利用性の低さ 過去に使ったプロンプトを記録していないと、同じ作業で毎回ゼロから考え直すことになります。

下図は、プロンプト作成における試行錯誤の流れを示しています。

mermaidCopy codeflowchart LR
  start["初回プロンプト<br/>作成"] --> exec1["実行"]
  exec1 --> check1["結果確認"]
  check1 -->|"不十分"| revise1["プロンプト<br/>修正"]
  revise1 --> exec2["再実行"]
  exec2 --> check2["結果確認"]
  check2 -->|"まだ不十分"| revise2["さらに修正"]
  revise2 --> exec3["再々実行"]
  exec3 --> check3["結果確認"]
  check3 -->|"ようやく満足"| done["完了"]

  style start fill:#ffebee
  style done fill:#e8f5e9
  style check1 fill:#fff3e0
  style check2 fill:#fff3e0
  style check3 fill:#fff3e0

この図からわかるように、満足のいく結果を得るまでに複数回の修正が必要になることが多く、これが大きな時間ロスにつながっています。

チーム開発での標準化不足

個人開発であれば自分のスタイルでプロンプトを書けば良いのですが、チーム開発では標準化が課題になります。

コードレビューの困難さ プロンプトの書き方が統一されていないと、レビュー時に「このプロンプトは適切か」を判断するのが難しくなります。

引き継ぎの問題 担当者が変わったときに、どのようなプロンプトを使っていたのか分からず、引き継ぎがスムーズに進みません。

ベストプラクティスの共有不足 優れたプロンプトを書けるメンバーがいても、そのノウハウがチーム全体に共有されません。

これらの課題を解決するには、プロンプトのテンプレート化と標準化が不可欠です。

解決策

プロンプトテンプレート化のメリット

プロンプトをテンプレート化することで、以下のメリットが得られます。

作業時間の短縮 テンプレートをコピーして必要な部分を埋めるだけで、すぐに使えるプロンプトが完成します。

品質の安定化 実績のあるテンプレートを使うことで、出力品質のばらつきを抑えられます。

学習コストの削減 新しいメンバーでも、テンプレートを見ることで効果的なプロンプトの書き方を学べます。

再利用性の向上 一度作成したテンプレートを様々なプロジェクトで使い回せます。

下図は、テンプレート化による効率化の仕組みを示しています。

mermaidCopy codeflowchart TB
  catalog["プロンプト<br/>カタログ"] --> select["テンプレート<br/>選択"]
  select --> custom["プロジェクト固有<br/>情報を埋め込み"]
  custom --> exec["即座に実行"]
  exec --> result["高品質な<br/>出力"]

  result -->|"必要に応じて"| minor["微調整"]
  minor --> done["完了"]

  style catalog fill:#e3f2fd
  style result fill:#f1f8e9
  style done fill:#c8e6c9

この図が示すように、テンプレートを使えば、選択 → カスタマイズ → 実行という 3 ステップで迅速に結果が得られます。

カテゴリ別テンプレート設計

本記事では、実務で頻繁に発生するタスクを 3 つのカテゴリに分類し、それぞれに対応するテンプレートを用意しました。

仕様化テンプレート（15 個） 要件定義、API 仕様書、データベース設計、テストケースなど、仕様策定に関わるプロンプトです。開発の上流工程で活用できます。

バグ調査テンプレート（15 個） エラーログ解析、パフォーマンス診断、メモリリーク検出など、デバッグ作業を効率化するプロンプトです。問題発生時に即座に使えます。

コード変換テンプレート(10 個) JavaScript→TypeScript 変換、REST→GraphQL 変換、CSS→Tailwind 変換など、コードの移行やリファクタリングに役立つプロンプトです。技術スタックの変更時に活用できます。

次のセクションでは、これら 40 個のプロンプトテンプレートを具体的にご紹介します。

具体例

ここからは、3 つのカテゴリに分けて、40 個のプロンプトテンプレートを詳しくご紹介します。各テンプレートは、そのままコピーして使えるように設計されています。

仕様化プロンプト（15 個）

仕様化プロンプトは、開発の上流工程で活用できるテンプレート集です。要件定義から設計書作成まで、幅広くカバーしています。

1. 要件定義書生成

ユーザーストーリーや簡単な要望から、体系的な要件定義書を生成します。

textCopy code以下のユーザーストーリーから要件定義書を作成してください。

【ユーザーストーリー】
{ここにユーザーストーリーを記載}

【出力形式】
- 機能要件（箇条書き）
- 非機能要件（性能、セキュリティ、可用性など）
- 制約事項
- 前提条件
- 優先度（Must/Should/Could）

このプロンプトを使うことで、断片的な要望を構造化された要件定義書に変換できます。出力形式を明示することで、一貫性のあるドキュメントが生成されます。

2. API 仕様書作成

エンドポイント情報から OpenAPI 形式の仕様書を作成します。

textCopy code以下のAPI情報からOpenAPI 3.0形式の仕様書を作成してください。

【エンドポイント情報】
{ここにエンドポイント一覧を記載}

【必須項目】
- パス、HTTPメソッド
- リクエストパラメータ（クエリ、パス、ボディ）
- レスポンススキーマ（200、400、500）
- 認証方法（Bearer Token想定）
- サンプルリクエスト/レスポンス

【フォーマット】
YAML形式で出力してください

API 仕様書は、フロントエンドとバックエンドの連携において非常に重要です。このテンプレートを使えば、標準形式の仕様書が素早く作成できます。

3. データベーススキーマ設計

業務要件からデータベーススキーマと ER 図を設計します。

textCopy code以下の業務要件からデータベーススキーマを設計してください。

【業務要件】
{ここに業務要件を記載}

【出力内容】
1. ER図（Mermaid形式）
2. テーブル定義（テーブル名、カラム名、型、制約）
3. インデックス設計
4. リレーションシップ（1対多、多対多など）
5. 正規化レベルの説明

【データベース】
PostgreSQL を想定してください

データベース設計は、後から変更するのが難しい重要な工程です。このプロンプトを使うことで、正規化やインデックス設計まで考慮されたスキーマが提案されます。

4. ユースケース図生成

機能要件からユースケース図を作成します。

textCopy code以下の機能要件からユースケース図を作成してください。

【機能要件】
{ここに機能要件を記載}

【出力内容】
1. Mermaid形式のユースケース図
2. 各ユースケースの詳細説明
3. アクター一覧
4. アクターとユースケースの関係
5. include/extend関係がある場合はその説明

ユースケース図は、システムの利用者視点での機能を整理するのに役立ちます。

5. シーケンス図作成

処理フローからシーケンス図を生成します。

textCopy code以下の処理フローからシーケンス図を作成してください。

【処理フロー】
{ここに処理の流れを記載}

【出力内容】
1. Mermaid形式のシーケンス図
2. 登場するオブジェクト/サービス一覧
3. 主要な処理ステップの説明
4. エラーハンドリングのフロー
5. 非同期処理がある場合はその説明

シーケンス図は、複数のコンポーネント間のやり取りを可視化するのに最適です。特にマイクロサービスアーキテクチャで有用です。

6. クラス図設計

オブジェクト指向設計からクラス図を作成します。

textCopy code以下の設計要件からクラス図を作成してください。

【設計要件】
{ここに設計要件を記載}

【出力内容】
1. Mermaid形式のクラス図
2. 各クラスの責務説明
3. プロパティとメソッド一覧
4. クラス間の関係（継承、実装、依存、関連）
5. デザインパターンの適用箇所があれば説明

オブジェクト指向設計では、クラス間の関係を正しく設計することが重要です。このプロンプトは、SOLID 原則を考慮した設計を支援します。

7. テストケース生成

機能仕様から網羅的なテストケースを生成します。

textCopy code以下の機能仕様からテストケースを作成してください。

【機能仕様】
{ここに機能仕様を記載}

【出力内容】
1. 正常系テストケース
2. 異常系テストケース
3. 境界値テストケース
4. 各テストケースの期待結果
5. テストデータのサンプル

【フォーマット】
表形式（No, テストケース名, 入力, 期待結果, 優先度）

テストケースの作成は時間がかかる作業ですが、このテンプレートを使えば、網羅的なケースを素早く洗い出せます。

8. インターフェース定義

業務仕様から TypeScript の型定義を作成します。

textCopy code以下の業務仕様からTypeScriptのインターフェース定義を作成してください。

【業務仕様】
{ここに業務仕様を記載}

【出力内容】
1. インターフェース定義
2. 型エイリアス
3. Enumやユニオン型の定義
4. JSDコメント付きの説明
5. バリデーションルールのコメント

TypeScript の型定義は、コードの安全性と可読性を高めます。業務仕様から直接型定義を生成することで、実装との乖離を防げます。

以下のコードは、生成されるインターフェース定義の例です。

typescriptCopy code/**
 * ユーザー情報を表すインターフェース
 */
interface User {
  /** ユーザーID（UUID形式） */
  id: string;

  /** ユーザー名（2-50文字） */
  name: string;

  /** メールアドレス（RFC 5322準拠） */
  email: string;

  /** 年齢（0-150の整数） */
  age: number;

  /** ユーザー種別 */
  role: UserRole;
}

typescriptCopy code/**
 * ユーザー種別を表すEnum
 */
enum UserRole {
  Admin = 'admin',
  User = 'user',
  Guest = 'guest',
}

このように、コメント付きで分かりやすい型定義が生成されます。

9. 状態遷移図作成

ステートマシン設計から状態遷移図を生成します。

textCopy code以下の状態遷移ルールから状態遷移図を作成してください。

【状態遷移ルール】
{ここに状態と遷移条件を記載}

【出力内容】
1. Mermaid形式の状態遷移図
2. 各状態の説明
3. 遷移条件の詳細
4. 初期状態と終了状態の明示
5. 不正な遷移を防ぐためのバリデーション

状態遷移図は、ワークフローや画面遷移の設計に不可欠です。

10. バリデーションルール定義

入力制約からバリデーション仕様を作成します。

textCopy code以下の入力項目からバリデーションルールを定義してください。

【入力項目】
{ここに入力項目一覧を記載}

【出力内容】
1. 各項目のバリデーションルール
2. 正規表現パターン
3. エラーメッセージ
4. クライアント側/サーバー側の役割分担
5. Yup/Zodスキーマ定義のサンプルコード

バリデーションはユーザー体験に直結します。明確なルール定義により、一貫したバリデーション実装が可能になります。

以下は、生成されるバリデーションスキーマの例です。

typescriptCopy codeimport { z } from 'zod';

/**
 * ユーザー登録フォームのバリデーションスキーマ
 */
const userSchema = z.object({
  // ユーザー名: 2-50文字の英数字とハイフン
  name: z
    .string()
    .min(2, {
      message: 'ユーザー名は2文字以上で入力してください',
    })
    .max(50, {
      message: 'ユーザー名は50文字以内で入力してください',
    })
    .regex(/^[a-zA-Z0-9-]+$/, {
      message:
        'ユーザー名は英数字とハイフンのみ使用できます',
    }),

  // メールアドレス: RFC 5322準拠
  email: z
    .string()
    .email({
      message: '有効なメールアドレスを入力してください',
    }),

  // 年齢: 0-150の整数
  age: z
    .number()
    .int({ message: '年齢は整数で入力してください' })
    .min(0, { message: '年齢は0以上で入力してください' })
    .max(150, {
      message: '年齢は150以下で入力してください',
    }),
});

このように、Zod スキーマとして実装可能な形で出力されます。

11. エラーハンドリング仕様

エラーケースからエラー処理仕様を作成します。

textCopy code以下のエラーケースからエラーハンドリング仕様を作成してください。

【想定エラーケース】
{ここにエラーケースを記載}

【出力内容】
1. エラーコード体系
2. 各エラーのHTTPステータスコード
3. エラーメッセージ（ユーザー向け/開発者向け）
4. エラーハンドリングフロー
5. ロギング方針
6. リトライ戦略（該当する場合）

適切なエラーハンドリングは、システムの堅牢性を高めます。

12. セキュリティ要件定義

脅威分析からセキュリティ仕様を作成します。

textCopy code以下のシステム概要から、セキュリティ要件を定義してください。

【システム概要】
{ここにシステム概要を記載}

【出力内容】
1. 想定される脅威（OWASP Top 10ベース）
2. 認証・認可方式
3. データ暗号化方針
4. セキュアコーディングルール
5. 脆弱性スキャン要件
6. ログ監査要件

セキュリティは設計段階から考慮する必要があります。このプロンプトは、OWASP Top 10 などの標準的な脅威モデルに基づいた要件定義を支援します。

13. パフォーマンス要件定義

性能目標からパフォーマンス仕様を作成します。

textCopy code以下の性能目標からパフォーマンス要件を定義してください。

【性能目標】
{ここに性能目標を記載}

【出力内容】
1. レスポンスタイム要件
2. スループット要件
3. 同時接続数要件
4. リソース使用率上限
5. パフォーマンス測定方法
6. 最適化ポイント

パフォーマンス要件を明確にすることで、設計段階からボトルネックを回避できます。

14. アーキテクチャ設計書

システム要件からアーキテクチャ図を作成します。

textCopy code以下のシステム要件からアーキテクチャ設計書を作成してください。

【システム要件】
{ここにシステム要件を記載}

【出力内容】
1. システム構成図（Mermaid形式）
2. 各コンポーネントの責務
3. 通信プロトコル
4. データフロー
5. 技術スタック選定理由
6. スケーラビリティ戦略

アーキテクチャ設計は、システム全体の品質を左右する重要な工程です。

15. コンポーネント設計書

UI 要件から React/Vue コンポーネント仕様を作成します。

textCopy code以下のUI要件からコンポーネント設計書を作成してください。

【UI要件】
{ここにUI要件を記載}

【出力内容】
1. コンポーネント階層図
2. 各コンポーネントのProps定義
3. State管理方針
4. イベントハンドリング
5. 再利用可能な共通コンポーネント
6. アクセシビリティ考慮事項

コンポーネント設計を事前に行うことで、保守性の高いフロントエンド実装が可能になります。

バグ調査プロンプト（15 個）

バグ調査プロンプトは、問題発生時の原因特定と解決策の提示を支援するテンプレート集です。

16. エラーログ解析

スタックトレースから原因を特定します。

textCopy code以下のエラーログから原因と解決策を提示してください。

【エラーログ】
{ここにスタックトレースを貼り付け}

【実行環境】
- OS: {OS情報}
- Node.js: {バージョン}
- 関連パッケージ: {パッケージ一覧}

【出力内容】
1. エラーの原因
2. 発生箇所の特定
3. 具体的な解決手順（優先度順）
4. 同様のエラーを防ぐための予防策
5. 関連するドキュメントリンク

エラーログを貼り付けるだけで、原因分析と解決策が得られます。実行環境情報を含めることで、より正確な診断が可能になります。

17. パフォーマンス問題診断

プロファイリング結果からボトルネックを特定します。

textCopy code以下のプロファイリング結果からパフォーマンスボトルネックを特定してください。

【プロファイリング結果】
{ここにCPU/メモリプロファイル結果を貼り付け}

【症状】
{ここに遅い処理や症状を記載}

【出力内容】
1. ボトルネックの特定
2. 原因の詳細分析
3. 最適化手法（優先度順）
4. 最適化後の期待効果
5. 最適化サンプルコード

パフォーマンス問題は、プロファイリングデータを正しく読み解くことが重要です。

18. メモリリーク検出

メモリ使用状況から原因を特定します。

textCopy code以下のメモリ使用状況からメモリリークの原因を特定してください。

【メモリ使用状況】
{ここにヒープスナップショットやメモリ推移を貼り付け}

【症状】
{ここにメモリ増加の症状を記載}

【出力内容】
1. リーク箇所の特定
2. リーク原因（イベントリスナー、クロージャなど）
3. 修正方法
4. メモリリーク検出方法
5. 予防策

メモリリークは長時間稼働するアプリケーションで深刻な問題です。早期発見と修正が重要です。

19. デッドロック解析

スレッドダンプから競合状態を特定します。

textCopy code以下のスレッドダンプからデッドロックの原因を特定してください。

【スレッドダンプ】
{ここにスレッドダンプを貼り付け}

【症状】
{ここに処理が停止する症状を記載}

【出力内容】
1. デッドロック発生箇所
2. ロック待ち状態の分析
3. デッドロック解消方法
4. ロック順序の最適化案
5. 非同期処理への移行提案

デッドロックは再現が難しいバグの一つです。スレッドダンプを正しく分析することが解決の鍵です。

20. 型エラー診断

TypeScript エラーから原因と解決策を提示します。

textCopy code以下のTypeScriptエラーから原因と解決策を提示してください。

【TypeScriptエラー】
{ここにエラーメッセージを貼り付け}

【関連コード】
{ここにエラー発生箇所のコードを貼り付け}

【出力内容】
1. エラーの原因説明
2. 型の不一致箇所
3. 修正コード（複数パターンあれば提示）
4. より型安全な設計への改善提案
5. 同様のエラーを防ぐためのベストプラクティス

TypeScript の型エラーは、初心者には理解が難しいことがあります。このプロンプトは、丁寧な説明と修正案を提供します。

以下は、型エラー修正の例です。

typescriptCopy code// エラーが発生するコード
interface User {
  id: number;
  name: string;
}

function getUser(): User | null {
  return null;
}

// Error: Object is possibly 'null'.
const user = getUser();
console.log(user.name);

typescriptCopy code// 修正案1: オプショナルチェーン
const user = getUser();
console.log(user?.name);

// 修正案2: 型ガード
const user = getUser();
if (user !== null) {
  console.log(user.name);
}

// 修正案3: Non-null assertion（確実にnullでない場合のみ）
const user = getUser()!;
console.log(user.name);

このように、複数の修正パターンが提示され、それぞれのメリット・デメリットも説明されます。

21. API 通信エラー解析

ネットワークエラーから原因を特定します。

textCopy code以下のAPI通信エラーから原因と解決策を提示してください。

【エラー情報】
- HTTPステータスコード: {ステータスコード}
- エラーメッセージ: {エラーメッセージ}
- リクエスト内容: {リクエスト詳細}

【出力内容】
1. エラー原因の特定
2. リクエスト/レスポンスの問題点
3. 修正方法
4. リトライ戦略
5. エラーハンドリングのベストプラクティス

API 通信エラーは、クライアント側とサーバー側の両方を確認する必要があります。

22. データベースクエリ最適化

スロークエリから改善策を提示します。

textCopy code以下のスロークエリログから最適化案を提示してください。

【スロークエリ】
{ここにクエリとEXPLAIN結果を貼り付け}

【テーブル定義】
{ここにテーブル構造を記載}

【出力内容】
1. パフォーマンス劣化の原因
2. インデックス追加提案
3. クエリ書き換え案
4. 最適化後のEXPLAIN予測
5. その他の改善策（パーティショニングなど）

データベースのパフォーマンスは、適切なインデックスとクエリ設計で大きく改善できます。

23. フロントエンドエラー診断

ブラウザコンソールエラーから原因を特定します。

textCopy code以下のブラウザコンソールエラーから原因と解決策を提示してください。

【コンソールエラー】
{ここにエラーメッセージを貼り付け}

【環境】
- ブラウザ: {ブラウザ名とバージョン}
- フレームワーク: {React/Vueなど}

【出力内容】
1. エラーの原因
2. 発生箇所の特定
3. 修正コード
4. ブラウザ互換性の確認
5. 同様のエラーを防ぐための予防策

ブラウザ固有のエラーや、フレームワーク特有のエラーを素早く解決できます。

24. ビルドエラー解析

コンパイルエラーから解決策を提示します。

textCopy code以下のビルドエラーから解決策を提示してください。

【ビルドエラー】
{ここにビルドエラーメッセージを貼り付け}

【ビルド設定】
{ここにwebpack/vite設定を記載}

【出力内容】
1. エラーの原因
2. 設定ファイルの修正箇所
3. 依存関係の問題があれば指摘
4. 修正手順
5. ビルド最適化の提案

ビルドエラーは、設定ファイルの問題であることが多いです。

25. 依存関係エラー解析

パッケージ競合から解決策を提示します。

textCopy code以下の依存関係エラーから解決策を提示してください。

【エラーメッセージ】
{ここにyarn/npmエラーを貼り付け}

【package.json】
{ここに依存関係を貼り付け}

【出力内容】
1. 競合している依存関係の特定
2. バージョン互換性の分析
3. 解決手順（resolutionsの使用など）
4. 代替パッケージの提案
5. 長期的な依存関係管理の推奨事項

依存関係の競合は、プロジェクトが大きくなるほど複雑になります。

26. テスト失敗原因分析

テストログから失敗原因を特定します。

textCopy code以下のテスト失敗ログから原因を特定してください。

【テストログ】
{ここにテスト失敗ログを貼り付け}

【テストコード】
{ここに失敗したテストコードを貼り付け}

【出力内容】
1. テスト失敗の原因
2. 期待値と実際の値の差異分析
3. 修正方法
4. テストの改善提案
5. モックやスタブの適切な使い方

テストが失敗する原因は、実装の問題かテスト自体の問題かを見極める必要があります。

27. セキュリティ脆弱性診断

コードから脆弱性を検出し修正案を提示します。

textCopy code以下のコードからセキュリティ脆弱性を診断してください。

【対象コード】
{ここにコードを貼り付け}

【出力内容】
1. 検出された脆弱性（OWASP分類）
2. 悪用シナリオ
3. リスクレベル（Critical/High/Medium/Low）
4. 修正コード
5. セキュアコーディングのベストプラクティス

セキュリティ脆弱性は、コードレビューで検出することが重要です。

28. レンダリング問題診断

React/Vue のレンダリング問題を特定します。

textCopy code以下のレンダリング問題から原因と解決策を提示してください。

【症状】
{ここにレンダリング問題の症状を記載}

【コンポーネントコード】
{ここにコンポーネントコードを貼り付け}

【出力内容】
1. レンダリング問題の原因
2. 無限ループの有無
3. 不要な再レンダリングの検出
4. 最適化方法（memo、useMemo、useCallbackなど）
5. パフォーマンス改善コード

レンダリング問題は、ユーザー体験に直結するため、早期の最適化が重要です。

29. 状態管理バグ解析

Redux/Zustand の状態不整合を特定します。

textCopy code以下の状態管理バグから原因と解決策を提示してください。

【症状】
{ここに状態不整合の症状を記載}

【状態管理コード】
{ここにReducer/Storeコードを貼り付け}

【出力内容】
1. 状態不整合の原因
2. イミュータブル更新の問題点
3. 修正コード
4. 状態設計の改善提案
5. デバッグ方法

状態管理のバグは、複雑なアプリケーションで発生しやすいです。

30. 非同期処理エラー診断

Promise/async-await のエラーを特定します。

textCopy code以下の非同期処理エラーから原因と解決策を提示してください。

【エラー情報】
{ここにエラーメッセージとスタックトレースを貼り付け}

【非同期コード】
{ここに非同期処理コードを貼り付け}

【出力内容】
1. エラーの原因
2. Promise チェーンの問題点
3. エラーハンドリングの不備
4. 修正コード
5. 非同期処理のベストプラクティス

非同期処理のエラーは、try-catch や Promise.catch()で適切にハンドリングすることが重要です。

コード変換プロンプト（10 個）

コード変換プロンプトは、既存コードを別の技術スタックやパターンに移行する際に役立つテンプレート集です。

31. JavaScript→TypeScript 変換

JavaScript コードを型定義付き TypeScript に変換します。

textCopy code以下のJavaScriptコードをTypeScriptに変換してください。

【JavaScriptコード】
{ここにJSコードを貼り付け}

【変換要件】
1. 適切な型定義を追加
2. インターフェースや型エイリアスを定義
3. strictモードで問題ないコード
4. JSDocがあればTypeScript型に変換
5. any型は極力避ける

【出力】
変換後のTypeScriptコードと、型定義の説明

JavaScript から TypeScript への移行は、多くのプロジェクトで行われています。このプロンプトを使えば、適切な型定義付きで変換できます。

32. Class→ 関数コンポーネント変換

React クラスコンポーネントを関数コンポーネント+Hooks に変換します。

textCopy code以下のReactクラスコンポーネントを関数コンポーネント(Hooks)に変換してください。

【クラスコンポーネント】
{ここにクラスコンポーネントコードを貼り付け}

【変換要件】
1. useState、useEffectなどのHooksを適切に使用
2. ライフサイクルメソッドを対応するHooksに変換
3. thisの参照を削除
4. 型定義（Props、State）を維持
5. パフォーマンス最適化（memo、useCallbackなど）

【出力】
変換後の関数コンポーネントと、変更点の説明

関数コンポーネントは、現代の React 開発の標準です。既存のクラスコンポーネントを移行する際に活用できます。

33. REST API→GraphQL 変換

REST エンドポイントを GraphQL スキーマに変換します。

textCopy code以下のREST APIエンドポイントをGraphQLスキーマに変換してください。

【RESTエンドポイント】
{ここにエンドポイント一覧を記載}

【変換要件】
1. GraphQLスキーマ定義（Type、Query、Mutation）
2. Resolverの実装サンプル
3. RESTとの対応関係
4. ページネーション対応
5. エラーハンドリング

【出力】
GraphQLスキーマとResolver実装

GraphQL は、柔軟なデータ取得が可能なため、フロントエンド開発を効率化します。

34. SQL→ORM 変換

SQL クエリを Prisma/TypeORM に変換します。

textCopy code以下のSQLクエリをPrisma/TypeORMのクエリに変換してください。

【SQLクエリ】
{ここにSQLクエリを貼り付け}

【ORM】
{PrismaまたはTypeORMを指定}

【変換要件】
1. ORMクエリビルダー形式に変換
2. 型安全なクエリ
3. リレーション取得の最適化
4. トランザクション処理
5. エラーハンドリング

【出力】
変換後のORMコードと、実行例

ORM を使うことで、型安全なデータベースアクセスが可能になります。

以下は、SQL から Prisma への変換例です。

sqlCopy code-- 元のSQLクエリ
SELECT u.id, u.name, COUNT(p.id) as post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
WHERE u.created_at > '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(p.id) > 5
ORDER BY post_count DESC
LIMIT 10;

typescriptCopy code// Prismaクエリに変換
const result = await prisma.user.findMany({
  where: {
    createdAt: {
      gt: new Date('2024-01-01'),
    },
  },
  include: {
    posts: {
      select: {
        id: true,
      },
    },
  },
  take: 10,
  orderBy: {
    posts: {
      _count: 'desc',
    },
  },
});

// ポストカウントでフィルタリング（Prismaでは2段階で処理）
const filtered = result
  .map((user) => ({
    id: user.id,
    name: user.name,
    postCount: user.posts.length,
  }))
  .filter((user) => user.postCount > 5);

このように、SQL クエリが Prisma の型安全なクエリに変換されます。

35. CSS→Tailwind 変換

通常の CSS を Tailwind クラスに変換します。

textCopy code以下のCSSをTailwind CSSクラスに変換してください。

【CSSコード】
{ここにCSSを貼り付け}

【変換要件】
1. 対応するTailwindクラスに変換
2. カスタム値が必要な場合はtailwind.configを提案
3. レスポンシブ対応
4. ホバー/フォーカスなどの擬似クラス対応
5. ダークモード対応（必要に応じて）

【出力】
Tailwindクラス名とHTML適用例

Tailwind CSS は、ユーティリティファーストのアプローチで開発速度を向上させます。

36. CommonJS→ESModule 変換

require/exports を import/export に変換します。

textCopy code以下のCommonJSモジュールをES Modulesに変換してください。

【CommonJSコード】
{ここにCommonJSコードを貼り付け}

【変換要件】
1. requireをimportに変換
2. module.exportsをexportに変換
3. 名前付きエクスポート/デフォルトエクスポートを適切に使用
4. dynamic importが必要な箇所を特定
5. package.jsonの"type": "module"対応

【出力】
変換後のESモジュールコード

ES Modules は、モダン JavaScript の標準です。

37. Redux→Zustand 変換

Redux 状態管理を Zustand に移行します。

textCopy code以下のReduxコードをZustandに変換してください。

【Reduxコード】
- Reducer: {ここにReducerを貼り付け}
- Action: {ここにActionを貼り付け}
- Selector: {ここにSelectorを貼り付け}

【変換要件】
1. Zustand storeの定義
2. アクション関数の実装
3. セレクター関数の実装
4. ミドルウェア対応（persist、immerなど）
5. TypeScript型定義

【出力】
変換後のZustandストアと使用例

Zustand は、Redux よりもシンプルで使いやすい状態管理ライブラリです。

38. Webpack→Vite 変換

Webpack 設定を Vite 設定に移行します。

textCopy code以下のWebpack設定をVite設定に変換してください。

【webpack.config.js】
{ここにWebpack設定を貼り付け}

【変換要件】
1. vite.config.tsの作成
2. ローダー設定をViteプラグインに変換
3. エイリアス設定の移行
4. 環境変数の扱い方
5. ビルド最適化設定

【出力】
vite.config.tsと、移行手順の説明

Vite は、高速な開発サーバーとビルドツールとして人気です。

39. Jest→Vitest 変換

Jest テストコードを Vitest に変換します。

textCopy code以下のJestテストコードをVitestに変換してください。

【Jestテストコード】
{ここにテストコードを貼り付け}

【変換要件】
1. インポート文の変更
2. 設定ファイルの移行
3. モック関数の書き換え
4. スナップショットテストの対応
5. カバレッジ設定

【出力】
変換後のVitestコードと、vitest.config.ts

Vitest は、Vite との統合が優れた高速テストランナーです。

40. Options API→Composition API 変換

Vue 2 の Options API を Vue 3 の Composition API に変換します。

textCopy code以下のVue 2コンポーネント(Options API)をVue 3 Composition APIに変換してください。

【Options APIコンポーネント】
{ここにVue 2コンポーネントを貼り付け}

【変換要件】
1. setup関数内での実装
2. ref、reactive、computedの適切な使用
3. ライフサイクルフックの変換
4. emit、propsの型定義
5. Composition関数への分割提案

【出力】
変換後のComposition APIコンポーネント

Composition API は、ロジックの再利用性と TypeScript との親和性に優れています。

まとめ

本記事では、Gemini CLI で活用できる 40 個のプロンプトテンプレートを、仕様化・バグ調査・コード変換の 3 つのカテゴリに分けてご紹介しました。

これらのテンプレートを活用することで、以下のメリットが得られます。

作業時間の大幅な短縮 テンプレートをコピーして必要な情報を埋めるだけで、即座に高品質な成果物が得られます。プロンプトをゼロから考える時間が不要になり、本来の開発作業に集中できます。

出力品質の安定化 実績のあるテンプレートを使うことで、誰が使っても一定品質の結果が得られます。チーム内での品質のばらつきが減少し、コードレビューやドキュメント作成が効率化されます。

学習コストの削減 新しいメンバーや Gemini CLI 初心者でも、テンプレートを参考にすることで、効果的なプロンプトの書き方を素早く習得できます。試行錯誤の回数が減り、早期に戦力化できます。

ベストプラクティスの共有 テンプレートをチーム内で共有することで、優れたプロンプト技法がチーム全体に広がります。個人のノウハウがチームの資産として蓄積されます。

本記事で紹介した 40 個のテンプレートは、以下のように分類されています。

• 仕様化プロンプト 15 個: 要件定義、API 仕様書、データベース設計、テストケース生成など
• バグ調査プロンプト 15 個: エラーログ解析、パフォーマンス診断、メモリリーク検出など
• コード変換プロンプト 10 個: JavaScript→TypeScript 変換、REST→GraphQL 変換など

これらのテンプレートは、そのまま使うこともできますし、プロジェクトの特性に合わせてカスタマイズすることもできます。ぜひご自身のプロジェクトに取り入れて、開発効率の向上を実感してください。

また、これらのテンプレートを出発点として、プロジェクト独自のテンプレートカタログを構築することもおすすめです。頻繁に使うプロンプトをドキュメント化し、チームで共有することで、さらなる効率化が図れます。

Gemini CLI は、適切なプロンプトと組み合わせることで、開発者の強力なパートナーとなります。本記事が、皆様の開発業務の効率化に少しでもお役に立てれば幸いです。

関連リンク

• Google AI Studio - Gemini API の公式サイト
• Gemini API Documentation - Gemini API の公式ドキュメント
• OpenAPI Specification - API 仕様書の標準形式
• TypeScript Documentation - TypeScript 公式ドキュメント
• React Documentation - React 公式ドキュメント
• Prisma Documentation - Prisma ORM 公式ドキュメント
• Tailwind CSS Documentation - Tailwind CSS 公式ドキュメント
• Vite Documentation - Vite 公式ドキュメント
• Vitest Documentation - Vitest 公式ドキュメント
• OWASP Top 10 - セキュリティ脅威トップ 10