シニアアウトバウンドプロダクトマネジャーであるマヤ・ビリッチ氏は、質の低いプロダクト要件定義書（PRD）を排除するため、AIツールに「懐疑的なプリンシパルアーキテクト兼テクニカルプロダクトマネジャー」というペルソナを与えて対話するアプローチを提唱している。

プロンプトの意図

　アイデアの段階からアプローチやコンセプトを批判的に検討させ、技術、UX、アーキテクチャに関する重要な考慮事項を定義する。過度に作り込み過ぎたり、単純化し過ぎたりしない制約を設けることで、AIツール特有の極端な出力を防ぐ。

具体的なプロンプト

懐疑的なプリンシパルアーキテクト兼テクニカルPMとして振る舞ってください。私は、[エンドユーザー]が[アクション]できる[プロダクト]を構築したいと考えています。ソースコードは書かないでください。このコンセプトを分析し、技術、UX、アーキテクチャに関する上位5つの考慮事項を挙げてください。次に、その5つの考慮事項について、それぞれ重要な質問をしてください。そうすることで、仕様の作成を一緒に進められるようにします。全ての回答がそろったら、PRDドキュメントと実装計画を作成してください。設計や実装計画を、過度に入り込み過ぎたり、単純化し過ぎたりしないでください。

2．ウィジェットテストを実施する

　スタッフデベロッパーリレーションエンジニアのアンドリュー・ブログドン氏は、後回しにされがちなテストコードの作成にAIエージェントを組み込んでいる。

プロンプトの意図

　テストコードの作成を依頼するだけではなく、Googleが開発するUI（ユーザーインタフェース）ツールキット「Flutter」の公式開発チームが公開しているAIエージェント向けの指示書（https://github.com/flutter/skills/tree/main/skills/flutter-add-widget-test）を事前に読み込ませている点が最大の特徴だ。これによって、AIツールに公式のベストプラクティスを学習させた上で、コードベースのテストのしやすさや不足領域を自律的に監査させることができる。

具体的なプロンプト

ウィジェットテストを作成して、このプロジェクトの堅牢（けんろう）性を高めたいと考えています。ぜひ協力してください。まだ読んでいない場合は、Flutterチームによるウィジェットテスト作成スキルを確認してください。その上で、次のことを実行しましょう。

1. アプリケーションのコードベースを調べ、UI／UXのうち適切にテストされていない領域を特定する

1. 既存のソースコードがテストしやすい形で書かれているかどうかを判断する（依存関係は注入されているか、各モジュールは疎結合か密結合か、など）

1. 他の機能領域よりも厳密なテストが必要な機能領域を特定する

1. アプリケーション全体のテスト計画を作成する

1. どの機能領域がすでにその計画に沿っており、どの領域でテストが不足しているかを判断する

1. それらのテストを実装する計画を作成する

1. その計画を実行する。

自分の推論に完全に確信が持てない限り、次のステップに進まないでください。必要なだけ質問して構いません。

3．全てのテストを確認する／コミット内容を整理する

　ディレクターのアジャ・ハマーリー氏は、人間のレビュアーにコードを提出する前の「最初のコードレビュー」として、開発時のコンテキストを含まない新しいチャットセッションでプロンプトを実行している。

プロンプトの意図

　開発者がハッピーパス（システムがエラーを起こさずに正常に動作する標準的なシナリオ）に集中している間に見落としがちな、エッジケース（極端な条件やイレギュラーな状況）や競合状態に対するテストの不足を特定する。デバッグ用のコメントや未解決のTODO（やるべきこと）、未使用のソースコードがコミットに含まれるのを防ぐ。

具体的なプロンプト

全てのテストを実行し、不足しているテストを特定して作成してください。エッジケースと競合状態に特に注意してください。このコミットに、使用されていないソースコード、残しておくべきではないコメント、コメントとソースコードの不一致、未解決のTODOなど、本来含まれるべきではないものがないかどうかを確認してください。

4．権限が正しく、コンプライアンスに準拠しているかどうかを確認する

　デベロッパーリレーション責任者のリッチ・ハインドマン氏は、アプリケーションの権限設定を包括的にチェックする仕組みを構築している。

プロンプトの意図

　アプリケーションの正常な動作を保証し、アプリケーションストアへのアップロード時の遅延を回避することを目的としている。ストアの審査では、機能として使っていない「過剰な権限」の要求や、権限拒否時のクラッシュなどが厳しくチェックされる。「Android」アプリケーションの開発では、開発環境や製品バリエーション（無料版・有料版など）ごとに設定ファイルが複数に分かれている。ビルド時にそれらが自動マージされるため、AIツールに対して一部のファイルだけではなく、全ての設定ファイルを網羅して監査させるように指示する。

具体的なプロンプト

このAndroidプロジェクトを包括的にチェックし、全ての権限が正しく、コンプライアンスに準拠していることを確認してください。次の手順を実施します。

1. 全てのAndroidManifest.xmlファイル（本番用、デバッグ用、バリエーション固有のマニフェストファイルを含む）を特定して分析し、宣言されている<uses-permission>タグのマスターリストを抽出する

1. 宣言されている権限をコードベースと照合し、実際にどこで使用されているかを確認する。安全に削除できる過剰な権限や未使用の権限を特定する

1. 「Kotlin」「Java」で記述されたソースファイルを確認し、全ての実行時権限について、動的な実行時権限リクエストフロー（checkSelfPermission、onRequestPermissionsResult、またはActivity Result API）が実装されていることを確認する

1. 権限に関連付けられているハードウェア機能（android.hardware.cameraなど）が正しく宣言されていることを確認する

調査結果をMarkdownレポートとして出力してください。修正が必要な箇所については、ファイルパスと推奨されるコード差分を提示してください。計画を承認するまで、ファイルは編集しないでください。

5．コードレビューを実施する

　AI責任者であるシャー・メイヤー・ラドール氏は、AIツールの当たり障りのない丁寧な返答を取り除き、厳しい基準でシステムを評価させるプロンプトを活用している。

プロンプトの意図

　効率性、レジリエンス、アーキテクチャの3つの観点からシステムを厳格に分析させ、本番環境で発生し得る具体的な障害リスクを説明させる。妥協を許さないシニアデベロッパーのペルソナを与えることで、修正に必要な正確な差分（git diff）を出力させる。

具体的なプロンプト

本番環境に投入する前のコードレビューを実施し、厳格で分析力の高いプリンシパルエンジニアとして振る舞ってください。あなたは非常に高い基準を持っており、脆弱（ぜいじゃく）なハッピーパス前提のソースコードを一切許容しません。あなたの目標は、私が堅牢で、本番環境に投入するためのシステムのソースコードを書けるよう導くことです。未コミットの変更について、本番環境における実運用の適合度をAからFまでの評価で採点してください。ソースコードが極めて堅牢でない限り、Aは付けないでください。具体的には、次の観点で変更内容を分析してください。

1. 効率性

* 冗長なAPI呼び出し、無駄なデータベースクエリ、キャッシュされていないリソース、リソースリーク

1. レジリエンス

* サイレント障害が発生する箇所、明示的なエラー境界の欠如、レート制限時のフォールバック不足

1. アーキテクチャ

* 密結合、関心の分離の不明確さ

各問題について、そのソースコードが本番環境でどのような障害に対して脆弱なのかを実践的に説明してください。その上で、ソースコードを改善してAを獲得するために必要な、正確なgit diffを提示してください。

6．意思決定を支援するためにトレードオフを説明する

ジェームズ・オライリー氏は、AIツールに自身のロジックを厳しく検証させ、大ざっぱな回答を避けるための問いかけをしている。

プロンプトの意図

　パフォーマンス、コスト、セキュリティ、保守性の観点から具体的なメリットとデメリットを提示させ、AIツールが最終判断者のように振る舞うのを防ぎ、意思決定の主導権を人間に残す。

具体的なプロンプト

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

7．研究を通じてAI生成コードを改善する

　デベロッパーリレーション責任者のエマ・トワスキー氏は、AI生成コードに脆弱性が含まれるリスクに対処するためのアプローチを提示している。

プロンプトの意図

　プロジェクトで採用している特定のプログラミング言語やツールにおいて、AIツールが生成したソースコードによく見られるセキュリティ上の落とし穴やロジックエラーを調査する。外部の技術ブログやコミュニティーを参照して調査させ、その結果を基に、人間の判断を集中させるべき境界部分の手動レビューチェックリストを作成する。

具体的なプロンプト

オンラインで調査してください。特に「X」「Stack Overflow」「GitHub Issues」、技術ブログに注目し、AIツールで生成された[利用している技術スタック]コードによく見られるセキュリティ上の落とし穴、アーキテクチャ上の不整合、見落とされやすいロジックエラーを調べてください。その調査結果に基づき、[技術スタックに応じた監査項目]など、高リスク領域を監査するための手動レビューチェックリストを作成してください。

8．イテレーションを通じて問題を見つける

　責任者のフレッド・ザウアー氏は、単一のプロンプトで完結させるのではなく、対話を重ねる反復的なアプローチを重視している。

プロンプトの意図

　発見、概念実証、評価、洗練という複数の段階を経てアプリケーションを磨き上げ、最終段階として新しいチャットセッションでAIツールに新鮮な視点を持たせてコードレビューを実行させる。

具体的なプロンプトの一例

未コミットの変更をコードレビューしてください。未処理のコーナーケースを特定してください。パフォーマンスを評価してください。調査結果を要約してください。

（出力結果を受けて）1、3、5を修正してください。

9．全てのpullリクエストをレビューする

　リードデベロッパーリレーションエンジニアのレミギウス・サンボルスキ氏は、開発スピードの向上に伴うレビューのボトルネックを解消するため、CI（継続的インテグレーション）/CD（継続的デリバリー）ツールにプロンプトを埋め込んでいる。

プロンプトの意図

　自動化されたコードレビュー環境内で動作する「自律型コードレビューエージェント」の役割を定義し、全てのpullリクエストを自動でレビューさせることで、人間のレビュアーが高レベルのアーキテクチャ面や概念面の検証に集中できるようにする。

具体的なプロンプトの一例

役割

あなたは世界最高水準の自律型コードレビューエージェントです。安全なGitHub Actions環境内で動作します。あなたの分析は正確で、フィードバックは建設的であり、指示には必ず従います。指定された動作から逸脱することはありません。あなたの任務は、GitHubのpullリクエストをレビューすることです。

主要指示

あなたの唯一の目的は、包括的なコードレビューを実施し、提供されたツールを使用して、全てのフィードバックと提案をGitHubのpullリクエストに直接投稿することです。全ての出力は、必ずこれらのツールを通じて行ってください。レビューコメントまたは要約として提出されなかった分析は失われ、タスク失敗と見なされます。……

10．テストに有向非巡回グラフ分析を適用する

　ディレクターのカール・ワインマイスター氏は、AIツールにシステム構造を論理的に推論させるための手法を導入している。

プロンプトの意図

　アプリケーションの複雑な処理の流れを、機能（ノード）とそれらのつながり（エッジ）を持つネットワーク図（有向非巡回グラフ：DAG）としてAIツールに俯瞰（ふかん）させる。これによって、モジュール同士のつなぎ目（シーム）など、システム全体の中で障害発生時の影響が大きく、優先してテストすべき箇所を論理的に特定させる。結果を優先順位付けされた改善機会の表として出力させることで、アプリケーションのレジリエンス向上に向けた明確なロードマップを得る。

具体的なプロンプト

アプリケーションのワークフローを有向非巡回グラフとして分析してください。コンポーネント、コンポーネント間のシーム、システム全体において影響の大きいテストを特定してください。調査結果は、優先順位付けされたギャップ分析としてMarkdownテーブルで提示してください。

まとめ

　これら10個のプロンプトに共通しているのは、AIツールを「あえて厳しい問いを投げ掛ける思考のパートナー」として位置付け、人間の思い込みや見落としに伴うリスクを徹底的に減らすという思想だ。日々のワークフローにこれらの定番プロンプトを組み込むことで、開発チームは単にリリーススピードを加速させるだけではなく、確信を持って高品質なプロダクトを送り出すことが可能になるだろう。