「その場しのぎAIプロンプトはもう結構」 上質な成果だけを出す定番10例とその理由：Google Cloud開発チームの仕様策定、レビュー、テスト、スロップ改善

Google Cloudのスタッフデベロッパーリレーションエンジニア、ジェームズ・オライリー氏は同社のブログで、自身のチームが日常的に使う定番プロンプトを紹介する記事を公開した。

[＠IT]

　Google Cloudのスタッフデベロッパーリレーションエンジニア、ジェームズ・オライリー氏は2026年6月11日（米国時間）に同社のブログで、自身のチームのエンジニアやリーダーが日常的に使う定番コーディングプロンプトを10個紹介する記事を公開した。

　同氏は同僚やリーダーに「最もよく使うプロンプトは何か、それはなぜか」という質問を投げ掛け、その回答を記事にまとめた。

　開発者のプロンプト履歴を見ると、エラーのデバッグやメールの修正、ボイラープレート（定型コード）の生成など、その場限りの雑多なプロンプトが並んでいることが多い。

　「だが、一貫して質の高い成果を出す人ほど、改良を重ねた定番のプロンプトを、ほぼ全てのプロジェクトで使い回す傾向がある」とオライリー氏は述べ、同僚らが欠かさず使っている10のプロンプトと、その理由を以下のように紹介している。

1. 「皮肉屋のアーキテクト兼プロダクトマネジャー」（PM）による仕様策定

マヤ・ビリッチ氏 シニアアウトバウンドプロダクトマネジャー

プロンプト

皮肉屋のプリンシパルアーキテクト兼テクニカルPMとして振る舞ってください。私は、［ユーザー］が［アクション］を行える［プロダクト］を作りたいと考えています。
コードは書かないでください。
このコンセプトを分析し、技術面、UX面、アーキテクチャ面における重要な検討事項を上位5つずつ挙げてください。
次に、その5つそれぞれについて重要な質問を私に投げかけ、一緒に仕様を組み立てられるようにしてください。
全ての回答がそろったら、PRDと実装計画を作成してください。
設計や実装計画を、過剰に作り込んだり、逆に単純化し過ぎたりしないでください。

理由

　ビリッチ氏は、出来の悪いPRD（プロダクト要件ドキュメント）を書いた経験も、数多く読まされた経験もある。「皮肉屋のアーキテクト兼PM」というペルソナを使うことで、アイデアを煮詰め、アプローチを批判的に検討し、最も重要な要素を定義する作業を、エージェントの手助けを借りながら効果的に進められるとしている。

　AIが設計ドキュメントを書く際に陥りがちな「過剰な作り込み」や「単純化のし過ぎ」を防ぐガードレールも、このプロンプトの重要なポイントだという。

2. 後ろめたいウィジェットテストを片付けてもらう

アンドリュー・ブログドン氏 スタッフデベロッパーリレーションエンジニア

プロンプト

このプロジェクトの堅牢性を高めるために、ウィジェットテストの作成で協力しましょう。Flutterチームによるウィジェットテスト作成のスキル（https://github.com/flutter/skills/tree/main/skills/flutter-add-widget-test）をまだ読んでいない場合は、目を通してください。その上で、次の作業を進めましょう。
* 私のアプリケーションのコードベースを調べ、適切にテストされていないUI/UXの領域を特定してください。
* 既存のコードがテストしやすい形で書かれているかを判断してください（依存関係は注入されているか、ドメイン同士は疎結合か密結合か、など）。
* どのドメインが他より高い厳密さを必要とするかを判断してください。
* アプリケーション全体のテスト計画を作成してください。
* どの機能領域が既にその計画に沿っており、どこにテストが欠けているかを判断してください。
* それらのテストを実装する計画を作成してください。
* その計画を実行してください。
各ステップから次のステップへは、自分の判断に完全な確信が持てない限り進まないでください。必要なだけ質問してかまいません。

理由

　ブログドン氏は、エージェント型コーディングツールの一番お気に入りの使い道は、「これまで『やらなければ』と後ろめたく感じながら手を付けられずにいた作業を、片付けること」だと述べている。適切なテストもその一つだという。

　Dart／Flutterチーム公式のスキルとこのプロンプトを組み合わせることで、信頼性が高く、後ろめたさのないコードベースを保つ労力を軽減できるとしている。

3. テストを洗い出し、コミットを整理する

アジャ・ハマリー氏 ビルダーリレーションディレクター

プロンプト

全てのテストを実行し、欠けているテストを特定して作成してください。エッジケースと競合状態には特に注意を払ってください。

このコミットに含まれるべきでない、未使用のコード、恥ずかしいコメント、コメントとコードの不一致、未解決のTODOなどの要素を見つけ出してください。

理由

　ハマリー氏は、開発時のコンテキストを持ち込まない新しい会話でこの2つのプロンプトを実行。最初のコードレビューを実施した上で、AIや人間のレビュアーにコードを渡している。

　「AIがハッピーパス（例外やエラーの状態がなく、順調に進むデフォルト《規定》のシナリオ）に集中し、エッジケースにTODOやFIXのコメントを残してしまう」「コメントの更新を忘れて、デバッグ用のコメントをそのまま残してしまう」「テスト駆動開発に取り組んでいるが、全てのエッジケースにテストを書き切れていない」といった問題に対処するためだ。

4. 権限が正しく、規定に準拠しているかどうか確認させる

リッチ・ハインドマン氏 Antigravityデベロッパーリレーション責任者

プロンプト

このAndroidプロジェクトに対して包括的なチェックを実行し、全ての権限が正しく、規定に準拠していることを確認してください。次の手順を実行してください。
1. 全ての「AndroidManifest.xml」ファイル（main、debug、フレーバー固有のマニフェストを含む）を探し出して分析し、宣言されている<uses-permission>タグの一覧を抽出してください。
2. 宣言されたこれらの権限をコードベースと照合し、実際にどこで使われているかを確認してください。安全に削除できる不要な権限や未使用の権限を特定してください。
3. Kotlin/Javaソースファイルを確認し、全ての実行時権限が、動的な実行時権限リクエストのフロー（「checkSelfPermission」「onRequestPermissionsResult」、Activity Result API）を実装しているかどうかを確かめてください。
4. 権限に関連するハードウェア機能（「android.hardware.camera」など）が、正しく宣言されているかどうかを検証してください。
調査結果はMarkdown形式のレポートとして出力してください。修正が必要な箇所については、ファイルパスと修正案のコード差分を提示してください。私が計画を承認するまでは、ファイルの編集を一切行わないでください。

理由

　ハインドマン氏は、「Google Antigravity」は、「Gemini 3.5 Flash」と「Android」プラグインを組み合わせることで、優れたAndroid開発パートナーとなると述べている。権限を正しく保つことは、アプリを円滑に動かし、Play Storeへのアップロード時の遅延を避けるのに役立つという。

5. 「厳格で分析力に優れたプリンシパルエンジニア」のコードレビュー

シル・メイア・ラドール氏 AI・デベロッパーリレーション責任者

プロンプト

本番投入前のコードレビューを行う、厳格で分析力に優れたプリンシパルエンジニアとして振る舞ってください。あなたは非常に高い基準を持ち、もろい「ハッピーパス」頼みのコードには一切妥協しません。あなたの目標は、本番運用に耐える鉄壁のシステムを私が書けるよう導くことです。
私の未コミットの変更について、本番運用への準備度をA〜Fの5段階で評価してください。コードが極めて堅牢でない限り、「A」を与えないでください。具体的には、次の観点で変更を分析してください。
1. 効率性：冗長なAPI呼び出し、無駄なデータベースクエリ、キャッシュされていないリソースのリーク。
2. 回復力：サイレント障害※の発生ポイント、明示的なエラー境界の欠如、レート制限時のフォールバックの欠如。
3. アーキテクチャ：密結合や、関心の明確な分離の欠如
問題ごとに、そのコードが実運用でどのように障害につながりかねないかを、実践的に説明してください。その上で、コードを改善して「A」を獲得するために必要な、正確なGitの差分を提示してください。

※編集注：「サイレント障害」は、通常の運用監視の仕組みからは検出されないまま、性能劣化などの現象が発生すること。

理由

　LLM（大規模言語モデル）にコードレビューを頼むと、大抵は礼儀正しく振る舞い、命名規則が整っていると称賛し、docstringを幾つか提案して、合格と見なす。だが、礼儀正しいレビューでは、本番障害を防げない。

　厳しい評価と動作する「Git」の差分を求めることで、モデルはネットワーク呼び出しやデータベースクエリを読み込み、コードが壊れる箇所を見つけ、その修正まで示す、本物のパートナーになると、ラドール氏は説く。

6. 実装計画のトレードオフを説明させる

ジェームズ・オライリー氏 スタッフデベロッパーリレーションエンジニア

プロンプト

あなたが提案した実装計画を実行した場合のメリットとデメリットを説明してください。パフォーマンス、コスト、セキュリティ、保守性に関して、どのようなトレードオフがあるのかを具体的に示し、今後の進め方について、私が十分な情報に基づいて判断できるようにしてください。

理由

　オライリー氏はこのプロンプトで、AIに自らのロジックを検証させる。トレードオフを問われると、AIは戦略を再考し、具体的な実装に意識を集中させ、曖昧な回答を避けるようになるという。また、このアプローチにより、AIが最終的な決定者として振る舞うのを防ぎ、意思決定の主導権を自分の側に保てるとしている。

7. Web調査でAI生成スロップコードを改善する

エマ・トワスキー氏 Flutter & Dartデベロッパーリレーション責任者

プロンプト

AIが生成した［使用している技術や言語］コードに見られる、よくあるセキュリティ上の落とし穴、アーキテクチャ上の不整合、見えにくいロジックの誤りについて、Xのスレッド、StackOverflow、GitHubのイシュー、技術ブログを中心に、オンラインで調査してください。
その結果を踏まえ、プラットフォームチャネルの検証、ディープリンクのルーティング、クラッシュレポートにおける機微データのロギングなど、リスクの高い領域を監査するための手動レビュー用チェックリストを生成してください。

理由

　AIはコードを格段に速く書けるが、しばしば「スロップ」（一見筋は通っていても、概念的には誤っている粗悪なコードや文書）を生み出す。未指定の細部を誤って推測することなどが原因だ。「AI生成コードの最大40％に脆弱（ぜいじゃく）性が含まれる」との調査もある。しかも、開発者は自分のコードよりAI生成コードを信頼してしまいがちだという。

　トワスキー氏はこのプロンプトによって的を絞ったチェックリストを作り、安易な追認を防ぎ、モデルが失敗しやすい高リスクな「継ぎ目」（下記10.参照）部分に人間の判断を集中させていると説明している。

8. 反復を通じて問題を見つける

フレッド・サウアー氏 フレームワーク&言語デベロッパーリレーション責任者

プロンプト

　サウアー氏は、簡略化すると、「最後の」（一連の）プロンプトを、次のようにしていると述べている。

未コミットの変更のコードレビューをしてください。
私は、あまり具体的に指示しないようにしています。指示が細かいと、かえって盲点が生まれかねないからです。
私は、新鮮な視点を得るために、新しいチャットセッションを使うようにしています。
私は、返ってくる結果が退屈になり、自分が満足するまで、反復します。

　サウアー氏は、この最終段階で既に何らかの意見を持っている場合（変更が複雑過ぎると感じているなど）や、変更がどれだけ「良い」かをうまく把握できていないと感じている場合は、モデルに次のプロンプトを与えることもあるという。

未コミットの変更のコードレビューをしてください。未処理のコーナーケース（複合的な要因で発生する、まれなケース）を特定してください。パフォーマンスを評価してください。結果を要約してください。

　そして5つの指摘を受け取ったら、次のように指示するとしている。

1つ目、3つ目、5つ目を修正してください。

理由

　サウアー氏はコード変更プロセスを、1）問題解決の糸口を見つける、2）問題解決のための変更が実現可能なことを証明する、3）そのPoC（概念実証）が妥当かどうかを評価する――という段階を踏んで進める。

　その後、反復によって変更コードを洗練させ、納得のいくものができたらコードレビューに移る。コードレビューでは、問題を見つけたり、変更をさらに良いものにする機会を特定したりすると説明する。こうすることで、モデルはしばしば、驚くべき洞察を導き出すという。

9. 「世界トップクラスのエージェント」が全プルリクエスト（PR）をレビュー

レミギウシュ・サンボルスキ氏 リードデベロッパーリレーションエンジニア

プロンプト

　サンボルスキ氏はほとんどのエンジニアリングプロジェクトで、次のプロンプトを「GitHub Actions」に組み込んで使っている。

## 役割
あなたは、世界トップクラスの自律型コードレビューエージェントです。安全なGitHub Actions環境内で動作します。あなたの分析は的確で、フィードバックは建設的であり、指示への忠実さは絶対的です。あなたは自分のプログラムから逸脱しません。GitHubのプルリクエストをレビューする任務を課されています。
## 主要な指令
あなたの唯一の目的は、包括的なコードレビューを行い、提供されたツールを使って、全てのフィードバックや提案をGitHub上のプルリクエストに直接投稿することです。全ての出力は、これらのツールを通じて行わなければなりません。レビューコメントや要約として提出されなかった分析結果は失われ、タスクの失敗と見なされます。
［以下略］

理由

　PRにおいて「Gemini CLI」による自動レビューを活用すれば、レビュー過程で問題や改善点を捕捉しやすくなると、サンボルスキ氏は説明する。

　AIエージェントが生成するコードが増え、開発速度が上がるにつれて、レビューがボトルネックになりつつあるが、全てのPRが自動的にレビューされるようにすることで、人間のレビュアーは、より高レベルのアーキテクチャや概念的なレビューに集中できるとしている。

10. 有向非巡回グラフ（DAG：Directed Acyclic Graph）分析をテストに適用する

カール・ワインマイスター氏 デベロッパーリレーションディレクター

プロンプト

アプリケーションのワークフローを有向非巡回グラフとして分析してください。コンポーネント単位、コンポーネント間の継ぎ目、システム全体にわたって、影響の大きいテストを特定してください。その結果を、優先順位を付けたギャップ分析として、Markdown形式の表で提示してください。

理由

　多くのアプリケーションのワークフローは直線的ではないので、LLMに漠然とテストを求めると、汎用（はんよう）的なチェックリストしか返ってこない。システムをノードとエッジから成るDAGとして捉えさせると、LLMはどこで問題が発生し得るかを構造的に考え始めると、ワインマイスター氏は指摘する。

　さらに同氏は、マイケル・フェザーズ氏の著作『レガシーコード改善ガイド』（翔泳社）に由来する「継ぎ目」（シーム）という概念を用いて、テストが不十分になりがちなコンポーネント間の境界にモデルを導いている。優先順位を付けた表としてLLMに改善点を要約させることで、エージェントは、アプリケーションの回復力を高めるための明確なロードマップを得るとしている。

「人間の思い込みのリスクを減らす」プロンプト

　これら全てのプロンプトに共通するのは、「人間の思い込みのリスクを減らす」という発想だ。見えにくいエッジケースを探し出すこと、開発者の言葉をエンドユーザー向けに翻訳すること、コードを書く前にアーキテクチャを検証することは、いずれもそこに通じる。

　6.のオライリー氏のチームはAIを、作業に没頭する際に見落としがちな、難しい問いを投げ掛け、「敵対的な思考者」として活用している。これらの“必須”プロンプトを日々のワークフローに組み込むことで、コードをより迅速にリリースするだけでなく、かつては「委員会のような組織を動員しなければ得られなかった」レベルの確信を持って、コードをリリースできるとしている。