はじめに
こんにちは。エンジニア 兼 講師のShotaです。
普段はエンジニアとしてAIツールを実案件に適用しながら開発を行い、同時に講師として得られた知見を体系化して受講生の方にお伝えする活動をしています。
AIツールを実案件に適用する際に事前に知っておくべき実践的なTipsのシリーズ第5回（最終回）。今回のテーマは「【AI駆動開発】Cursor@ファイル指定でコードレビュー工数50%減」です。
※本記事の内容は「AI駆動開発実践コース」での知見をもとにしています
前回までの振り返り
前回、前々回は、AIツールを使ったバグ修正、リファクタリングにおいて、以下の2つのポイントが効果的であることを確認しました：
- タスクの細分化 - 複雑な修正を小さな単位に分割
- ファイル名指定 - @マークを活用した明確な修正対象の指定
なぜ効果的なのかというと、以下の理由からでした。
✅ タスクの細分化の効果
- 大きなタスクを別々のサブタスクに分割することで、AIが各修正を正確に理解
- 修正内容を段階的に確認でき、手戻りを最小限に抑制
- 各修正の影響範囲が明確で、レビューが容易
✅ ファイル名指定の効果
- @ファイル名の指定により、AIが修正対象ファイルを正確に認識
- 修正箇所が明確で、意図した通りの実装が実現
一方で、この手法はAI駆動開発で活用できる7つのメソッドのうちの1つです。
7つのメソッドの概要
開発の生産性と品質を両立するためのAIへの指示方法をまとめたものです。
以下の通り、どの開発プロセスで使用する指示方法なのかを整理しています。
AIへの指示といっても、そのプロセスは大きく3つのステップに分けられます：
①準備 → ②指示 → ③確認
7つのメソッドの位置づけは、②指示プロセスにおける具体的な指示方法です。
この指示方法に従った、実際のAIツールへの指示、修正結果のコードを示したのが、前回、前々回のバグ修正、リファクタリングのTipsでした。
リファクタリング・バグ修正で使用したメソッドの位置づけ
実は、前回、前々回のバグ修正、リファクタリングは、「一括修正法」を使って実際にコードを修正した事例でした。
各メソッドは、実案件で実践できるように、上記の概要レベルだけでなく、詳細レベルの具体的な伝え方も整理されています。例えば一括修正法の伝え方はこの通りです。
[@ファイル名] ＋
[コーディング規約 (オプション)] ＋
[修正方針]
で修正を依頼する
実際の使用例
このメソッドを使ってどうやって修正するのかというと、例えば前々回のリファクタリングの事例で言うと：
プロンプト：
@client/src/components/task-list.tsx
@client/src/components/task-dialog.tsx
@client/src/components/task-card.tsx
これらのファイルのエラー処理ロジック（エラーコードに応じたメッセージ設定）を@client/src/lib/error-utils.tsに共通関数化し、
各ファイルから共通関数を呼び出すよう修正してください。
修正結果：
// 修正前
} catch (error) {
let title = "エラーが発生しました";
let description: string;
if (error instanceof Error) { // ❌ 重複したエラー処理
if (error.message === ERROR_CODES.NOTFOUND_ERROR) {
description = "対象のタスクが見つかりません。一覧を更新して最新情報をご確認ください。";
} else if (error.message === ERROR_CODES.SERVER_ERROR) {
description = "サーバーエラーが発生しました。しばらく経ってから再試行してください。";
} else {
description = "タスクの保存に失敗しました。ネットワーク接続を確認して再試行してください。";
}
}
}
// 修正後
} catch (error) {
const { title, description } = getErrorMessage(error, "タスクの保存"); // ✅ 共通関数化
}
伝え方の構造
伝え方：
[@ファイル名] ＋
[コーディング規約 (オプション)] ＋
[修正方針]
で修正を依頼する
プロンプト：
@client/src/components/task-list.tsx
@client/src/components/task-dialog.tsx
@client/src/components/task-card.tsx
これらのファイルのエラー処理ロジック（エラーコードに応じたメッセージ設定）を@client/src/lib/error-utils.tsに共通関数化し、
各ファイルから共通関数を呼び出すよう修正してください。
上記の伝え方と実際のプロンプト照らし合わせると：
-
[@ファイル名] が
@client/src/components/task-list.tsx...の部分 -
[修正方針] が
これらのファイルのエラー処理ロジック（エラーコードに応じたメッセージ設定）を...の部分
コーディング規約はオプションで、指定してもいいですが、毎回指示するのは手間なので、AIツール自体に設定してしまいます。この設定はカスタムルールなどと呼ばれ、具体的な設定方法などはコースの中で紹介しています。
タスクの細分化と7つのメソッドの関係性
前回、前々回と、AIへの指示における2つのポイントが効果的だと説明してきましたが：
- タスクの細分化 - 複雑な修正を小さな単位に分割
- ファイル名指定 - @マークを活用した明確な修正対象の指定
後者のファイル名指定は伝え方の [@ファイル名] の部分だとして、前者のタスクの細分化の話は伝え方のどこにいった？ という疑問があるかもしれません。
実は、タスクの細分化は7つのメソッドには含めていません。
なぜなら、前段でお話した通り、7つのメソッドは ①準備 → ②指示 → ③確認のうち、②指示プロセスの方法をまとめたもの で、タスクの細分化の話は、指示する前の準備段階、①準備プロセスの話 だからです。
要するに、AIに指示する前に、タスクの細分化のお膳立てを整えたうえで、7つのメソッドを使ってAIに指示すると、速く正確に作業してくれる、すなわち、開発の生産性と品質を両立することができます。
他の6メソッドの詳細
メソッドの全体像
7つのメソッドの概要に改めて触れます。では他に具体的にどのようなメソッドがあるのか、さらにもう一つご紹介します。
データフロー法
これは、コードレビューにおいてコード理解を効率化するために、アプリケーションのデータフローを短時間で理解するための質問方法 です。
具体的には：
[機能名] ＋
[アーキテクチャー]
で説明を依頼する
このような形式で質問します。
具体的なプロンプトとAIの回答
プロンプト：
タスク一覧表示機能のデータフローを、
下記のアーキテクチャに基づいて、
具体的なファイル名やコンポーネント名
などを踏まえて説明してください。
Frontend (React)
- UI
- Business Logic
- API Access
Backend (Express + Drizzle ORM)
- API EndPoint
- Business Logic
- Data Access
Database (PostgreSQL)
- Table
AIの回答：
タスク一覧表示機能のデータフローは、以下のアーキテクチャに基づいて説明できます：
Frontend (React)
- UI
- コンポーネント名: TaskList（task-list.tsx）
- タスクの一覧を表示するために、Reactのコンポーネントとして実装されています。TaskCard（task-card.tsx）コンポーネントを利用して、各タスクの詳細を表示します。
- Business Logic
- React Queryを使用してAPIからタスクデータを取得し、ローディング状態を管理します。
- API Access
- タスクデータの取得はuseQueryを用いて行われ、APIエンドポイント/api/tasksへのリクエストを通じてデータを取得します。
Backend (Express + Drizzle ORM)
- API Endpoint
- ファイル名: server/routes.ts（routes.ts）
- タスクの取得、作成、更新、削除を処理するAPIエンドポイントを定義しています。GET /api/tasksエンドポイントがタスク一覧の取得を担当しています。
- Business Logic
- 各APIエンドポイントのロジック（例:タスクの取得）はこのファイル内で実装され、データベースからのデータ取得やエラーハンドリングを行います。
- Data Access
- drizzle-ormを使用してデータベースアクセスを行い、タスクデータに対するCRUD操作を行います。
Database (PostgreSQL)
- Table
- テーブル名: tasks（schema.ts）
- タスクの情報を格納するtasksテーブルが定義されています。カラムにはid, title, description, status, created_at, updated_atが含まれます。statusはタスクの状態（未着手、進行中、完了）を表します。
このように、フロントエンドからバックエンド、そしてデータベースまで、タスク一覧表示機能はコンポーネントやエンドポイントを介してスムーズにデータを流通させ、ユーザーにタスク情報を表示する仕組みになっています。
一括修正法と同様に、データフロー法も伝え方の構造が明確に定義されています：
伝え方の構造
伝え方：
[機能名] ＋
[アーキテクチャー]
で説明を依頼する
プロンプト：
タスク一覧表示機能のデータフローを、
下記のアーキテクチャに基づいて、
具体的なファイル名やコンポーネント名
などを踏まえて説明してください。
Frontend (React)
- UI
- Business Logic
- API Access
Backend (Express + Drizzle ORM)
- API EndPoint
- Business Logic
- Data Access
Database (PostgreSQL)
- Table
上記の伝え方と実際のプロンプトを照らし合わせると：
-
[機能名] が
タスク一覧表示機能のデータフローの部分 -
[アーキテクチャー] が
下記のアーキテクチャに基づいて...で指定された構成要素の部分
データフローを最初に理解する意味
なぜデータフローかというと、アプリケーションの処理の本質は①入力データ → ②データ変換 → ③出力データという一連のデータの流れだからです。
各アーキテクチャの要素がどのようにデータを変換し、データがどのように流れていくのかを理解できれば、アプリケーションの仕様を効率的に把握することができます。
また、これらの質問方法は段階的に理解を深めていく構造 になっています。
- データフロー法 でアプリケーション全体を把握
- ファイル法 で特定のファイルを理解
- ブロック法 で特定のコンポーネントや関数の役割を把握
- ロジック法 で特定の処理内容の詳細を理解
という流れです。
質問方法の効果的な使い方について
AIツールにはコード選択→右クリックでの説明機能がありますが、なぜわざわざ機能名やアーキテクチャを指定して質問するのでしょうか？
デフォルトのコード説明機能の限界
- 「何を」説明するかはコード選択で指定可能
- 「どう説明させるか」の指示ができない
- プログラミング的視点（文法解説）に偏りがち
明示的プロンプトの利点
- 「どう説明させるか」をプロンプトで制御可能
- 技術知識に関係なく本質的理解が得られる
- 説明の視点・方法を自由に指定できる
もちろん、デフォルト機能で理解が進むならそちらを使うのも効率的です。すべてのメソッドを順番に使う必要はなく、疑問箇所だけの質問も効果的なアプローチです。
以上、データフロー法と一括修正法を含む7つのメソッドをご紹介しました。少しでも皆様のお役に立てば幸いです。
その他のメソッド
AI駆動開発では、これらのメソッドに加えて、以下のような手法も効果的です：
- 要件6か条
- フェーズ法
- データフロー法
- ファイル法
- ブロック法
- ロジック法
- 一括修正法
まとめ
今回のTipsシリーズを通じて、以下のことが明らかになりました：
効果的なAI指示の基本構造
①準備（タスクの細分化）→ ②指示（7つのメソッド）→ ③確認
各ステップが重要で、7つのメソッドによる体系的な指示が成功の鍵
実証された手法の汎用性
- 一括修正法がリファクタリングとバグ修正の両方で高い効果を発揮
- @ファイル名 + 修正方針という簡潔な構造が様々な場面で活用可能
体系的なアプローチの重要性
- 単発のテクニックではなく、開発プロセス全体を通じた体系的な方法論
- 各メソッドが相互に連携し、開発の生産性と品質を両立
この実践Tipsシリーズは今回で完結となります。5回に渡ってお付き合いいただき、本当にありがとうございました。この記事が参考になりましたら、ぜひいいねをお願いします。今後も有益な情報をお届けしてまいりますので、フォローしていただけると幸いです。
Discussion