【ITニュース解説】Three developer prompts to keep, and the one decision that makes each reusable

「プロンプト」とは、AIに特定のタスクを実行させるための指示文のことだ。最近のAI技術の進歩により、開発作業の多くの場面でAIを効果的に活用できるようになった。しかし、毎回AIに指示を出すたびに、その指示内容を細かく調整するのは手間がかかる。そこで重要になるのが、一度作成したプロンプトを「再利用可能」にすることだ。再利用可能なプロンプトとは、基本的な指示部分を変えることなく、その時々の新しい情報（例えば、今日書いたコードや最新のコミットメッセージなど）を与えるだけで、すぐに役立つ結果が得られるようなプロンプトを指す。この再利用性を実現する鍵は、プロンプトを作る段階で、ある一つの「決定」を明確にプロンプトの中に書き込んでおくことにある。これにより、AIを利用するたびに同じ疑問が繰り返されたり、毎回異なる基準で結果が出てきたりするのを防げるのだ。

ここでは、システムエンジニアが日々の開発業務でよく遭遇する三つのタスクを例に、再利用可能なプロンプトの具体的な作り方を解説する。

一つ目は、「プルリクエスト（PR）レビュー」を行う際のプロンプトだ。プルリクエストとは、開発者が書いた新しいコードを、プロジェクトの主要なコードに統合する前に、他の開発者がそのコードをチェック（レビュー）するプロセスを指す。このレビュー作業にAIを活用するプロンプトは、次のように構成できる。AIに対して、レビューで発見された問題の重大度を明確なスケールで分類するよう指示するのだ。例えば、「Blcoker（システムを破壊したり、データを失わせたり、セキュリティ上の脆弱性を生じさせるような、絶対に修正が必要な問題）」「Major（バグの可能性が高い、あるいは意図しない動作変更で、早急な対応が必要な問題）」「Minor（修正する価値はあるが、すぐにコードを統合しても大きな問題はない軽微な修正）」といった具体的な分類基準をプロンプト内に記述する。さらに、発見された問題点については、どのファイル・どの行にあり、何が問題で、どのような修正が考えられるかを、BlcokerからMinorの順にリストアップするよう指定する。AIには、コードのフォーマットや命名規則に関する指摘は、それがバグを隠している場合を除いてスキップするよう指示し、これらはコード整形ツール（リンター）に任せる。 このプロンプトが再利用性を持つのは、この「明示的な重大度スケール」を組み込んでいるためだ。このスケールがない場合、AIからのレビュー結果は単なる問題点の羅列となり、開発者は毎回、どの問題が本当に重要なのかを自分で判断し、優先順位をつけ直す手間が発生する。しかし、この三段階の重大度を定義しておくことで、全てのレビュー結果が同じ基準で整理され、「Major」が何を意味するかが常に一貫する。時間がない場合でも、Blcokerの問題だけを優先的に確認するといった柔軟な対応も可能になる。もしチームで異なる重大度基準を使っている場合でも、この三つの定義部分だけを一度書き換えれば、プロンプトの他の部分は変更せずに使い続けられる。

二つ目の例は、コードの「コミットメッセージ」から「変更履歴（Changelog）」を作成するプロンプトだ。コミットメッセージとは、開発者がコードの変更を保存する際に添える短い説明文で、変更履歴は、その製品がどのように変化したかをユーザーや他の開発者に伝えるための文書である。このプロンプトでは、「誰がこの変更履歴を読むのか」という「対象読者」を明確に指定することが再利用性の鍵となる。例えば、「製品を日々利用する人々」を読者として想定し、彼らがコードの中身を知らなくても、製品の何が変わったかを理解できるような言葉で変更を説明するようAIに指示する。さらに、「追加された機能」「変更された内容」「修正されたバグ」といった見出しの下に項目をグループ化し、特に重要な破壊的変更があれば、それを一番上にまとめるよう指示する。AIは、コミットメッセージのみを情報源とし、あいまいなコミットは「人間による確認が必要」としてリストアップし、マージコミットや内部的なリファクタリングなど、ユーザーに直接影響しない変更は省くよう指示される。 このプロンプトが再利用可能なのは、この「読者の明確化」があるからだ。読者を指定しないと、生成される変更履歴は、ユーザー向けの親しみやすい説明になったり、開発者向けの技術的な変更点の要約になったりと、毎回内容がぶれてしまう。読者を「製品を日常的に使う人々」と定義することで、何が変更として記述されるべきか、どのように説明されるべきか、何が省略されるべきかといった、ほぼ全ての判断基準が自動的に定まる。また、このプロンプトは非常に柔軟で、もし別の読者（例えば、内部の保守担当者や貢献者）向けの変更履歴が必要になった場合でも、プロンプトの中の「Reader:」の一行を書き換えるだけで、同じプロンプトが全く異なる視点の変更履歴を生成できる。

三つ目は、「テストの足場（Scaffolding）」を作成するプロンプトだ。ソフトウェア開発においてテストは非常に重要で、書いたコードが意図通りに動作するかを確認するために行われる。テストの「足場」とは、テストコードの基本的な構造やひな形のことだ。このプロンプトを再利用可能にするためには、「フレームワークの規約」に沿うようにAIに指示することが重要になる。例えば、Pythonの「pytest」というテストフレームワークを使用する場合、AIに対して以下のような具体的な規約に従うよう指示する。「テストファイル名はtest_にモジュール名を加えたものとする」「各振る舞いにつき一つのテスト関数を作成し、test_に何を確認するかを加えて命名する」「共通の準備処理はフィクスチャにまとめる」「引数だけが異なるケースはpytest.mark.parametrizeを使用する」「外部依存（ネットワーク、ファイルシステム、時計など）のみをモック化する」といった具合だ。AIはまず、カバーすべき振る舞いやエッジケース、エラーパスをリストアップし、その後で実際のテストコードを生成する。もし期待値がコードだけでは判断できない場合は、明確な「TODO」コメントを残して推測しないように指示する。 このプロンプトが再利用可能なのは、既存のテストスイート（テストコードの集まり）がすでに持つ規約に合わせて出力されるからだ。一般的に「このコードのテストを書いて」とだけ指示した場合、生成されるテストは汎用的すぎて、既存のテストコードとスタイルが異なり、手作業で修正する必要が生じる。しかし、具体的な規約をプロンプトに組み込むことで、AIが生成するテストコードは既存のテストに自然に溶け込み、すぐに利用できる。JestやGoのテスティングパッケージなど、異なるテストフレームワークを使用している場合でも、この規約ブロックだけを一度書き換えれば、他の部分はそのまま再利用できる。

これら三つの再利用可能なプロンプトに共通しているのは、AIを使うたびに開発者が毎回判断する必要があった「どれくらい深刻な問題か」「誰がこの情報を読むのか」「テストはどのように書かれるべきか」といった一つの重要な問いに対する答えを、プロンプト自体が固定している点だ。コードやコミットメッセージといった入力材料は毎回変わるが、その判断基準は決して変わらない。これにより、開発作業の効率性が大幅に向上し、チーム全体でのアウトプットの一貫性も保たれる。一度効果的なプロンプトが作られたら、それを手元に保存し、繰り返し活用することが、AIを最大限に活かす上で非常に重要になる。