ソフトウェア開発のプロンプト：よりよい解決策の余地を残す

AI とソフトウェアを開発するとき、私はまず問題を明確にしてから解決方法を決めるようにしている。詳しいプロンプトは役に立つ。ただ、自分が好む技術や画面構成を書き込みすぎると、よりよい選択肢を早い段階で閉ざしてしまう。私が意識しているのは、次の5つだ。

1. 既存の解決策を探す

作りたいものは、すでに誰かが実装しているか、ライブラリで大部分をまかなえることが多い。まずプロジェクトと既存の選択肢を調べてもらい、適合性、保守状況、ライセンス、統合コストを比較する。再利用にも、自作にも、選ぶ理由が必要だ。

2. 達成したい結果を伝える

何を可能にしたいのか、なぜ必要なのか、どう検証するのかを説明する。技術的な決定が確定していなければ、実装方法は開いておく。「中断したアップロードを再開できる」と伝えるほうが、データベースとキューを指定するよりも、適切な設計を検討する余地が生まれる。

3. 利用体験を伝える

誰が、どんな状況で使い、何を達成し、失敗からどう復帰するのかを描く。「ファイルの送信後、成功したか分かり、失敗しても再開できる」は利用体験の説明だ。右上にボタンのあるダッシュボードは、すでに画面の選択になっている。画面が確定しているなら、確定済みの制約として明記する。

4. 質問を通じて前提を見直す

要件を詰めるために Matt Pocock の grilling skill を使う。下のプロンプトでは、選択肢、トレードオフ、推奨案を添えて、一度に一問ずつ尋ねるよう追加で指定している。ここで当初の技術や画面の好みを問い直せば、よりよい解決策を探せる。Claude Code では AskUserQuestion を指定し、ほかのエージェントでは利用可能な質問ツールかテキストを使う。

5. 決定を実行可能なタスクにする

合意できたら、設計書とアーキテクチャ決定記録（ADR）を docs/ に残す。ADR は重要な選択と代替案を記録し、タスクは実装する作業を示す。各タスクに前提条件と検証方法を付ける。依存関係の「ツリー」には共通の前提タスクがあり得るので、有向非巡回グラフ（DAG）と実行順序を求めている。

grilling をインストールする

Node.js、npm、Git を用意し、ターミナルで利用するエージェントのコマンドを実行する。サードパーティーの Skills CLI を使い、Matt Pocock の grilling skill をユーザー単位でインストールする。

Codex

npx skills@latest add mattpocock/skills --skill grilling --agent codex --global

Claude Code

npx skills@latest add mattpocock/skills --skill grilling --agent claude-code --global

--global を外すと現在のプロジェクトにインストールされる。個人用スキルの場所は Codex が ~/.agents/skills/、Claude Code が ~/.claude/skills/。見つからない場合は新しいセッションを開く。Codex では $grilling、Claude Code では /grilling で呼び出す。

コピーして使える汎用の計画プロンプト

角括弧を埋めて、ブロック全体を貼り付ける。新しい製品、機能追加、既存システムの変更に使える。対話で計画を作り、実行は別のプロンプトで始める。

次のソフトウェア開発タスクの計画を手伝ってください。まだ実装しないでください。

達成したい結果とその理由：[結果を記入]
ユーザーと利用体験：[誰が、どんな状況で、どう使い、成功し、失敗から復帰するか]
成功基準：[観察・検証できる結果]
制約：[既存システム、互換性、期間、予算、安全性など]
確定済みの決定と理由：[列挙。なければ「なし」]
見直してよい好み：[任意]

1. まず調査する
関連プロジェクトを確認し、既存の実装、ライブラリ、サービスを探してください。調査できる場合は最新の一次資料を確認してください。再利用、既存案の調整、自作を、適合性、保守、ライセンス、統合コストで比較し、出典を示してください。事実と仮定を分け、調べられない情報は未検証と明記してください。

2. 設計の前に認識を合わせる
grilling skill を使ってください。このタスクでは一度に一問だけ尋ね、私の回答を待ってください。前提となる決定を先に解決し、それに依存する質問は後にしてください。調べられる事実は自分で確認し、判断や取捨選択を私に尋ねてください。
各質問には意味のある選択肢を2〜4個用意し、内容とトレードオフ、推奨案と理由を示し、自由回答も受け付けてください。Claude Code では利用可能なら AskUserQuestion を使ってください。Codex などでは利用可能な質問ツールを使い、なければ同じ選択肢をテキストで示してください。ツールが存在すると決めつけないでください。
目的、利用体験、範囲、失敗時の動作、受け入れ条件を中心に確認してください。確定済みと明記したもの以外は、実装方法や画面を先に固定しないでください。よりよい案がありそうなら私の好みを問い直し、確定済みの制約と矛盾する場合は指摘してください。
合意事項と未解決事項を整理し、共通理解に達したと私が明示的に確認するまで、計画書の作成や実装を待ってください。

3. 確認後に計画を文書化する
docs/[task-slug]/ を使い、既存の文書規約がある場合はそれに合わせてください。
- design.md：問題、ユーザーと利用の流れ、目標と対象外、制約、提案する方式、受け入れ条件、リスク、検証方針。
- adr/NNNN-short-title.md：重要なアーキテクチャ上の決定ごとに、背景、代替案、決定、理由、影響、状態を記録し、設計書へリンクする。通常の作業を無理に ADR にしない。
- tasks.md：小さく独立して検証できるタスクに分割する。各タスクに固定 ID、範囲、前提タスク（depends_on IDs）、成果物、受け入れ条件、検証手順、状態、関連する設計箇所や ADR へのリンクを付ける。
- dependency-graph.md：孤立したタスクも含め、全タスクを Mermaid DAG で示す。テキストの依存関係一覧と、トポロジカル順に段階分けした実行順序も付ける。A --> B は「B には A の完了が必要」と定義する。存在しない ID と循環依存を確認し、並列実行できるタスクとブロック中のタスクを示す。
すべての受け入れ条件をタスクでカバーしてください。タスクは合意した設計と決定を実装する作業とし、ADR の書き直しだけにしないでください。最後に最初の実行可能なタスクと実行方法を示し、実装前に止めてください。

一つずつ実行を進める

文書を確認した後は、このプロンプトを各ステップで使える。すべての前提タスクが完了して初めて、そのタスクを開始できる。

docs/[task-slug]/design.md、adr/、tasks.md、dependency-graph.md を読んでください。
[タスク ID、または「次の実行可能なタスク」] の前提タスクがすべて完了していることを確認してから実行してください。ブロックされている場合は理由と、現在実行可能なタスクを示してください。
合意済みの範囲内でこのタスクを完了し、関連する検証を行い、状態と検証の証拠を tasks.md に記録してください。新しい発見が設計や ADR を変更する場合は、影響を説明し、私と認識を合わせてからその変更を進めてください。
変更内容、検証結果、次に実行可能なタスクを報告し、別のタスクを始める前に止めてください。

インストールとツールの参考資料

コマンドとツールの説明は2026年10月17日に確認。Skill は更新されるため、上のプロンプトでは対話の進め方を明示している。

あわせて読む

Unknown Known：監視の構築速度がリソース作成に追いつかないとき

記事一覧へ →