【ITニュース解説】Stop Prompt-Engineering Copilot. Write Three Rules in a File Instead.

AIを活用したコードアシスタント、例えばGitHub Copilotのようなツールは、プログラミング作業を大いに助けてくれる。しかし、そのAIから期待通りの、あるいはより良いコードを得るためには、どのように指示を出せば良いのかという疑問を持つ人も多いだろう。一般的には、「プロンプトエンジニアリング」と呼ばれる手法が推奨されてきた。これは、AIへの質問や指示の言葉遣いを工夫し、より具体的に、文脈を与え、段階的に考えるように促すといった方法である。確かにこれらの工夫は、ある程度の効果をもたらすが、その効果はすぐに頭打ちになる。

なぜなら、プロンプトエンジニアリングはAIに対して「もっと頑張って考えるように」と促すだけで、AIが「既に知っている」こと以上の新しい情報を与えているわけではないからである。AIはインターネット上の膨大なコードを学習しており、「クリーンで保守しやすいコードを書く」といった一般的な良い習慣については、既に理解している。しかし、特定のプロジェクトやチームにおける「暗黙のルール」や「技術的な取り決め」までは、AIは知らない。

そこで、より効果的なアプローチとして提案されているのが、レポジトリ内に特定のファイルを設置し、そこにプロジェクト固有のルールを記述するという方法である。具体的には、レポジトリのルートではなく、.githubディレクトリの中にcopilot-instructions.mdというファイルを作成する。このファイルはプレーンなMarkdown形式で記述され、特別なヘッダー情報（フロントマター）は不要である。一度このファイルをコミットすれば、Copilotはコード生成のリクエストごとにこのファイルを読み込み、そこに記述されたルールを考慮して出力を行うようになる。

この方法が効果を発揮するのは、AIが「知らなかった」具体的な情報を提供できる点にある。例えば、「クリーンで保守しやすいコードを書く」といった一般的な指示は、AIにとって既知のことであり、出力を大きく変えることはない。しかし、「お金に関する値は必ずDecimal型を使用し、float型は絶対に使わない。小数点以下の丸め処理は、最終的な応答を返す直前のみ、半数切り上げで2桁まで行う」といった具体的なルールは、AIにとって「このコードベースに関する新しい事実」となる。また、「全ての日付時刻はタイムゾーンを考慮したUTC（協定世界時）とする。datetime.utcnow()はタイムゾーン情報を持たない日付時刻を返すため、タイムゾーンを考慮した他の日付時刻と比較すると誤った結果になる可能性がある」といった指示も同様に、コードベース固有の重要な情報である。

良いルールには、三つの重要な特性が求められる。一つ目は「耐久性（Durable）」があること。これは、来月になっても真実であり続けるような、長期的な性質を持つルールであるべきだ。一時的なタスクに関する指示は、ここに含めるべきではない。二つ目は「具体性（Specific）」があること。「タイムゾーンを正しく処理する」といった漠然とした指示ではなく、「datetime.utcnow()はタイムゾーン情報を持たない日付時刻を返す」のように、特定の技術的な詳細に言及するべきである。三つ目は「確認可能（Checkable）」であること。これは、誰かがコードの変更点（差分）を見たときに、そのルールが守られているかどうかを明確に判断できるような内容である必要がある。

また、ルールは「～するべきだ」という願望よりも、「～してはならない」という禁止事項の形で記述する方が、より効果的に守られる傾向がある。「タイムゾーンを考慮した日付時刻を使用する」といった指示は、AIが「同意する」だけで実際には守られないことがある。これに対し、「datetime.utcnow()はタイムゾーン情報を持たない日付時刻を返すため、本コードベースではタイムゾーンを考慮した日付時刻と比較してはならない」といった具体的な禁止事項とその理由を伝えることで、AIはそれを遵守しようとする。理由を添えることで、予想外の状況にも対応しやすくなる。

ルールの数は、包括的であることよりも簡潔であることが重要だ。40個のルールが平均的に適用されるよりも、厳選された8個のルールが確実に守られる方が良い。このファイルはCopilotへのリクエストの前に付加されるため、400行にも及ぶような長い指示ファイルは、すべてのインタラクションに対してオーバーヘッドとなり、本当に重要なルールが薄まってしまう可能性がある。もし5行だけ残すとしたら、それは「一見して明らかではない」重要なルールにすべきである。さらに、すでにリンター（コードの構文やスタイルをチェックするツール）のような他のツールによって自動的に強制されているようなルールは、このファイルに記述する必要はない。そのツール自体が変更を拒否する場所で一度だけ伝えるのが最も効果的だ。

このアプローチはアプリケーションコードだけでなく、インフラストラクチャのコードにおいても有効である。むしろ、インフラでの設定ミスはより高価な間違いにつながるため、この効果は大きい。例えば、Terraformにおいては「コレクションにはfor_eachを使用し、countはオン/オフの条件にのみ使用する。countは位置に依存するため、3つのアイテムのうち2番目を削除すると3番目も破壊される」や、「すべての変数には型、説明、そして値の範囲を制限するバリデーションブロックを設ける」、そして「地域、アカウントID、ARNをハードコードしない」といった具体的なルールが有効だ。

Kubernetesでは、「すべてのコンテナにresources.requestsとresources.limitsを設定する」、「異なるエンドポイントを指す3つのプローブ（健全性チェック）を設定する。レディネスプローブと同じエンドポイントを指すライブネスプローブは、依存関係の遅延を再起動ループに変える可能性がある」、また「イメージはダイジェストによってピン留めし、:latestタグはデプロイできない」といったルールが考えられる。

GitHub Actionsでは、「github.event以下の内容は決してrun:ブロック内に直接展開せず、env:を介して渡す」、「ワークフローレベルでpermissions: contents: readを設定し、ジョブごとに必要に応じて権限を広げる」、そして「サードパーティ製アクションは完全なコミットSHAでピン留めし、タグは使用しない」などが挙げられる。これらはすべて、レビューで見逃されがちな、見た目上は正しく見えても実際は誤っている可能性のある欠陥のクラスである。

この仕組みの最も重要な側面は、このファイル自体がコードと同様にコミットされ、レビューされる点にある。これは単なる管理上の手続きのように聞こえるかもしれないが、チームの合意形成において非常に有益な特性を持つ。個人の好みに過ぎなかったコーディング規約が、履歴を持つファイルとして、プルリクエストを通じてチーム全体で合意された公式のルールとなるのである。ある規約に関する議論が、「それをインストラクションファイルに書こう」という言葉で解決するのを見たことがある。これは、ファイルが議論を直接解決したのではなく、個人的な提案を、チームの承認が必要な正式な提案へと変える役割を果たしたからだ。

この取り組みを始めるには、まずこのファイルを開き、あなたのコードベースにおいて、能力のある新人が最初の週に間違いやすい、かつスタイルチェックやリンターでは検出されないような、プロジェクト固有の重要なルールを三つ書き出すことから始めると良いだろう。それはわずか10分ほどの作業で、これまであなたが読んだあらゆるプロンプトエンジニアリングのヒントよりも、優れた成果をもたらすはずだ。