デベロッパー必見: 開発に欠かせない 10 個のプロンプト
James O'Reilly
Staff Developer Relations Engineer, Google Cloud
※この投稿は米国時間 2026 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。
開発者のプロンプト履歴を見ると、非常に具体的で、ときには雑然とした、その場限りのプロンプトが並んでいることがあります。AI を使って、個別のエラー メッセージをデバッグしたり、まとまりのないメールを整えたり、簡単な定型文を生成したりしているのです。
一方で、質の高い成果物を継続的に生み出している人たちと話してみると、興味深いことがわかります。そうした人たちは、単に思いつきでプロンプトを書いているわけではありません。時間をかけて調整と改善を重ね、ほぼすべてのプロジェクトで活用している定番のプロンプトを持っているのです。
そこで、同僚やリーダーにシンプルな質問を投げかけました。「最もよく使うプロンプトは何ですか。また、それを使う理由は何ですか。」
共有されたのは、単なるコマンドの寄せ集めではありませんでした。ここでは、私たちのチームにとって手放せないプロンプトと、さらに重要な、そのプロンプトを使う理由をまとめてご紹介します。
理由: 私は質の低いプロダクト要件定義書（PRD）を書いたこともありますし、質の低い PRD を数多く読んできました。このプロンプトでは、懐疑的なアーキテクト / PM というペルソナを使うことで、アイデアを整理し、アプローチやコンセプトを批判的に検討し、最も重要な要素を定義する作業を一緒に進めることができます。エージェントの助けを借りて計画を詰めながら、プロダクト設計のアイデアをさらに発展させることもできます。また、過度に作り込みすぎたり、単純化しすぎたりしないという制約も気に入っています。AI は、特にプロダクト設計ドキュメントを作成する際に、そうした方向に寄りがちだからです。
理由: エージェント型コーディング ツールの使い方として私が特に気に入っているのは、プロジェクトでやるべきだと思いながらも、これまで後回しにしてきたことを実際に進められる点です。適切なテストは、まさにその一つです。Dart / Flutter チームの公式スキルは、優れたウィジェット テストがどのようなものかをエージェントに指示するうえで非常によくできています。このプロンプトと組み合わせることで、それらの手順を自分のコーディング ワークフローに組み込み、信頼性が高く、安心して保守できるコードベースを維持するためのトイルを減らすことができます。
理由: コードを書いていると、ユーザーに通ってほしい主要な経路である「ハッピーパス」に意識が偏ってしまうことがよくあります。その作業に集中している間は、まだ深く考えたくないエッジケースについて TODO や FIXME コメントを残しておくことがあります。また、コメントの更新を忘れたり、デバッグ用のコメントを残したままにしたりすることもあります。テスト駆動開発に従うよう努めてはいますが、すべてのエッジケースに対して必ずテストを用意できているわけではありません。私は通常、AI または人間のレビュアーに提出する前に、最初のコードレビューとして、この 2 つのプロンプトを新しい会話で実行します。その際、開発時のコンテキストは含めません。これにより、自分が作ったものを、他の人がレビューしやすく、使いやすい状態に整えることができます。
理由: Gemini 3.5 Flash と Android プラグインを備えた Antigravity は、Android 開発における優れたパートナーです。権限が正しく設定されているかを確認することで、アプリをスムーズに動作させ、Google Play ストアへのアップロード時の遅延を回避しやすくなります。
理由: LLM にコードレビューを依頼すると、多くの場合、丁寧な反応が返ってきます。命名がきれいだと言い、いくつか docstring を提案し、問題なしという評価を付けてくれます。しかし、丁寧なレビューでは本番環境の障害は防げません。このプロンプトが気に入っているのは、AI の当たり障りのない返答を取り除けるからです。モデルに厳しい基準で作業を評価させ、修正のために実際に使える git diff を求めることで、モデルを本当のパートナーにできます。モデルは推測するのをやめ、ネットワーク呼び出しやデータベース クエリを実際に読み取り、コードがどこで壊れるのかを見つけるようになります。妥協を許さないシニア デベロッパーが肩越しに見ていて、どこで手を抜いたのかを正確に指摘し、それを修正するためのコードまで渡してくれるようなものです。
理由: 私は、AI に自分のロジックを厳しく検証させるようにしています。どのようなトレードオフがあるのかを尋ねることで、AI は戦略を再考し、こちらの具体的な実装により集中するようになり、曖昧で大ざっぱな回答を避けやすくなります。また、このアプローチにより、AI が最終判断者のように振る舞うことを防ぎ、意思決定の主導権を自分の側に保つことができます。
理由: AI はコード作成を 10 倍速くできる一方で、粗いコードを生成することも少なくありません。そうしたコードは一見筋が通っているように見えても、指定されていない詳細について誤った前提を置いているため、概念的にはバグを含んでいることがあります。調査によると、AI 生成コードの最大 40% に脆弱性が含まれており、開発者は自分のコード以上に AI のコードを信頼してしまう傾向があります。そのため、危険なミスマッチが生じます。私はこのプロンプトを使って、冗長な AI 生成の変更を深く検討しないまま承認してしまうことを防ぐ、的を絞ったチェックリストを作成しています。これにより、人間の判断を、モデルが失敗しやすい高リスクの境界部分に集中させることができます。タスクの生成には AI を使いながらも、最も重要な部分では人間が関与し続けられるようにしています。
この最後のフェーズに入る時点で、たとえば「変更が複雑すぎる気がする」といった懸念がある場合や、その変更がどの程度「良い」のか十分に把握できていないと感じる場合は、次のプロンプトでモデルに検討を促すことがあります。
その後、5 件の指摘を受け取ったら、次のように指示します。
理由: 最後に送るプロンプトが 1 つだけあるわけではありません。むしろ、変更は複数の段階を経て進んでいきます。初期段階では、多くの場合、発見が中心です。つまり、手がかりとなる針や糸口を見つける段階です。次に、存在証明に移ります。やりたいことが実現できることを示したいだけです。その後、評価します。PoC は妥当か、複雑すぎないか、まったく違う場所を変更していないか、といった点を確認します。そのうえで、実装方法と変更箇所の両面から、より洗練されたソリューションになるよう反復します。自分で書いたとしても満足できると感じられるものになったら、最後のフェーズであるコードレビューに移ります。ここでは、問題を見つけたり、変更をさらに改善する機会を特定したりします。モデルが示してくれるインサイトには、驚かされることがよくあります。
プロンプト全文: リンク
理由: PR で自動化された Gemini CLI レビューを使用すると、レビュー プロセス中に問題や改善の機会を見つけやすくなります。さらに、AI エージェントによって生成されるコードが増え、開発スピードが上がるにつれて、レビューがボトルネックになりつつあります。すべての PR が自動的にレビューされるようにすることで、人間のレビュアーは、提案された変更について、より高レベルのアーキテクチャ面や概念面のレビューに集中できます。
理由:
ほとんどのアプリケーション ワークフローは線形ではありません。LLM にテストを提案させると、通常は、どのプロジェクトにも当てはまるような一般的なチェックリストが返ってきます。
しかし、システムをノードとエッジを持つ有向非巡回グラフ（DAG）として考えるよう促すと、どこで問題が発生し得るのかを構造的に推論し始めます。
また、Michael Feathers 氏の著書『レガシーコード改善ガイド』で使われている「シーム」についても考慮するよう指示しています。
最後に、結果を優先順位付けされた改善機会の表として要約するようモデルに依頼しています。これにより、アプリのレジリエンスを高めるための明確なロードマップをエージェントに与えることができます。
まとめ
これらのプロンプトすべてに共通しているのは、人間の思い込みに伴うリスクを減らすという点です。見落としやすいエッジケースを探す場合でも、デベロッパー向けの表現をエンドユーザー向けに言い換える場合でも、コードを書く前にアーキテクチャをストレステストする場合でも同じです。私たちのチームは、AI を、あえて厳しい問いを投げかける思考のパートナーとして活用しています。つまり、細部に入り込んでいると見落としがちな点を指摘してくれる存在です。
こうした「必ず実行する」プロンプトを日々のワークフローに組み込むことで、単にリリースを速めるだけでなく、かつてはチーム全体でレビューしなければ得られなかったレベルの確信を持ってリリースできるようになります。
- Google Cloud、スタッフ デベロッパー リレーション エンジニア James O'Reilly
