1. はじめに
Devin や Slack 連携などで、メンションするだけで修正やタスクをAIに依頼できるようになりました。
一方で、依頼文が曖昧だと見当違いな実装をしてしまうことがあります。特にジュニアレベルの方は曖昧な指示になりやすく、暗黙知を必要とするタスクに対しても丸投げしているケースが見受けられます。
AIを用いた実装は効率的ですが、質や精度は担保しなければなりません。
質や精度を高めるには、何をどう書いて渡すか（プロンプト）の向上が効果的です。毎回十分な量のプロンプトを作成するのも大変なので、プロンプト自体をAIに作ってもらいましょう。
今回は、事象を投げて「調査して、修正のためのプロンプトを作成して」と依頼し、出てきたプロンプトを貼り付けて実装する流れをまとめます。
2. 流れ（2ステップ）
多くの人は「事象→実装」をAIに頼んでいる。それがズレる最大の原因。正しくは「事象→（調査＋プロンプト作成）→実装」。 いきなり実装させず、先に調査とプロンプト作成をさせる。ここがキモです。
Step1：事象を投げて「調査して、修正のためのプロンプトを作成して」と依頼する
バグの現象や「やりたいこと」を、大まかにAIに投げます。「この画面で〇〇すると△△になる」「ここに〇〇を追加したい」程度で十分です。
そのうえで、**「以下を調査して、修正のためのプロンプトを作成して」**と依頼します。AIには、実際のコードやリファレンス（ドキュメント・仕様）を参照しながら調査し、その結果を踏まえて実装担当AI（Devin や Cursor）にそのまま貼り付けて使えるプロンプトを1本出してもらいます。Cursor なら該当リポジトリを開いた状態で、Devin なら対象リポジトリを指定したうえで依頼します。
Step2：そのプロンプトを貼り付けて実装する
Step1で出てきたプロンプトをコピーし、Devin や Cursor などの実装依頼欄に貼り付けて実行します。事象をそのまま書いて依頼するより、調査済みで内容が整理されたプロンプトで依頼したほうが精度が高くなります。
なぜ精度が上がるか。 AIは「実装」より「読解・要約・整理」の方が圧倒的に得意です。調査 → 要約 → プロンプト化をAIにやらせると、得意分野だけで回ります。
3. よくある失敗パターン
- 事象だけ書いていきなり実装させる
- 推測ベースで答えさせる（コード・リファレンスを見させていない）
- コードを見させていない
- 環境を渡していない
- 「修正して」と丸投げする
4. 依頼文の例
事象を書いたうえで、「以下を調査して、修正のためのプロンプトを作成して」と依頼します。
プロンプト作成例：
以下を調査して、修正のためのプロンプトを作成してください。
【事象】
（ここに事象を書く）
【依頼内容】
- コードとリファレンスを参照して調査すること
- 調査結果を踏まえ、実装担当AI（Devin / Cursor）にそのまま貼り付けて実行できるプロンプト文を1つ出力すること
- 出力はプロンプト文のみ（説明や前置きは不要）
- プロンプトには含めること：対象リポジトリ・ファイル・関数、タスクの種類（バグ修正/機能追加/リファクタ）、修正方針または実装要件、環境、完了基準（あれば）
Step1で返ってくるプロンプトは、調査結果が反映された「そのまま貼って実行できる」文面になっています。それをコピーし、実装依頼先に貼り付けて使います。
5. 使うときのコツ
- 「調査して、修正のためのプロンプトを作成して」とセットで依頼する。事象だけ書いて「推測で」答えさせず、コード・リファレンスを参照させると、出てくるプロンプトの質が上がります。
-
開発環境は Rules に書いておく。Cursor なら
.cursor/rules/に言語・FW・OS・接続コマンドなどを置いておくと、調査も実装もAIが自動で参照してくれます。 - 「プロンプト文だけ出力」と書いておく。依頼時に「貼り付けて使える形式で」「説明は不要でプロンプト文のみ」「.mdのコードスニペットで出力して」などと書いておくと、余計な説明なしで返してくれやすくなります。
6. まとめ
AIの精度は、事象の書き方ではなく、依頼する順番で決まります。事象 →「調査して、修正のためのプロンプトを作成して」→ そのプロンプトで実装。この順で回すと、事象だけ書いて依頼するより精度が高くなります。
余談1：上記の流れは「Planモード」で既にある
上記の「事象を投げて調査＋プロンプト作成 → そのプロンプトで実装」の流れは、Planモードとして Cursor や GitHub Copilot にすでにある。具体的には、いま紹介した手順（先に調査・プロンプト作成、そのあと実装）でやっているから精度が上がっている、という話です。
GitHub Copilotの新機能「Planモード」
余談2：この流れを自動化したのがエージェントチーム
上記の「事象 → 調査＋プロンプト作成 → 実装」を、役割分担した複数のAIに任せて自動化したのがエージェントチーム（AIマイクロチーム）です。
-
AIマイクロチーム
Slack で要望を受け、AIサポートエンジニアがコードベースを参照してトリアージ・要件整理・1次調査を行い、その結果を「発注書」としてまとめて Devin に渡す。Devin が実装し PR を作成。人間はレビューと意思決定だけ担当し、要望から PR まで数日で完結している（Zenn: Slack Workflow × AIパートナー× Devinで作る「AIマイクロチーム」 — 問い合わせ対応から実装までを自律化） -
マルチエージェント
Claude Code でも、スキルとサブエージェント（Task tool）で「調査 → 実装」の役割分担ができる。メインの Claude Code が統括・実装し、サブエージェント（Explore：コードベース探索、Plan：計画立案、general-purpose：汎用調査）に調査を任せ、必要なら Codex にレビューを依頼する流れ。/ask-agentで「このエラーの原因を調査して」と投げてから実装する運用が、本記事の Step1〜2 に相当する（Zenn: Claude Codeでマルチエージェント環境を構築する - Codexとサブエージェントの活用）。oh-my-claudecode を使うと、Swarm・Pipeline などで複数エージェントの並列・連鎖実行もできる。
自分で Step1〜2 を回すのではなく、「事象を投げる → 調査AIがプロンプトまで組み立て → 実装AIに渡す」までをパイプライン化するイメージです。
今後やってみたいこと
- エージェントチームの導入：調査用と実装用でエージェントを分け、Slack やチャットで事象を投げたら、調査 → プロンプト作成 → 実装依頼まで一気に回す。
- AGENTS.md の整備：Devin などが参照するプロジェクト用指示書（AGENTS.md）に、調査・実装時のルールや参照すべきドキュメントを書いておき、渡すプロンプトの質を底上げする。
- 仕様書の整備と自動アップデート：実装だけでなく仕様書の整備も依頼対象にする。実装完了後、追加機能や変更内容に応じて仕様書を自動で更新するフロー（PR マージ時に仕様書を差分更新するなど）もやってみたい。
- Human-in-the-Loop の設計：どこまで自動で回し、どこで人間がレビュー・承認するかを決め、精度と安全性のバランスを取る。