長さよりも構造を優先する
システムプロンプトを書くときに最もよくある失敗は、考えられるあらゆるシナリオを一つの長文に詰め込もうとすることです。モデルは、役割定義、プロセス手順、出力フォーマット、制約、例示といった異なる種類の指示を明確に分離した構造的なプロンプトに、より良く反応します。
構造化されたプロンプトには、たとえば役割セクション(「あなたはPythonに特化したコードレビュアーです」)、プロセスセクション(「各ファイルについて、未使用のインポート、欠落している型ヒント、セキュリティ上の問題、パフォーマンスの懸念を確認してください」)、出力セクション(「指摘事項は重要度評価付きの番号リストで提示してください」)、制約セクション(「読みやすさに影響しない限り、スタイル上の変更は提案しないでください」)などが含まれます。
こうした構造によって、モデルは処理の各段階で何が重要で何に集中すべきかを把握しやすくなります。同時に、人間にとってもプロンプトのレビュー、修正、メンテナンスがしやすくなるという利点があります。
欲しいものを具体的に書く
曖昧な指示は曖昧な結果しか生みません。「コードを分析して」では何を意味するか分かりません。「各関数で欠落しているエラーハンドリングを確認し、パラメータ化された入力を使っていないデータベースクエリを特定し、ハードコードされた認証情報があればフラグを立ててください」と書けば、モデルは何を探すべきかを正確に理解できます。
AIスキルを書くときには、具体性こそが品質を担保する第一の道具となります。プロンプトに残された曖昧さは、モデルが独自に判断する余地となり、その判断は必ずしもあなたの期待と一致しません。具体的に書くほど、モデルの推測に頼る部分は減っていきます。
例示を盛り込む
欲しいものを伝える上で、例示ほど効果的な手段はありません。望ましい出力形式を抽象的に説明する代わりに、良い出力がどのようなものかをモデルに見せましょう。エッジケースを文章で説明する代わりに、それをどう扱うべきかを例で示すのです。
適切に選ばれた2〜3個の例は、何段落にもわたる指示文の代わりになります。モデルはルールよりもパターンから学ぶ方が得意です。難しい入力に対する正しい応答を示す例があれば、明示的なルールを書かなくても、似たような入力をモデルが処理できるようになります。
境界線を明示する
モデルが「やってはいけないこと」を伝えましょう。境界線がなければ、モデルはあなたが望まない方向で「親切」を発揮しようとします。バグの特定だけを頼んだはずなのに、コードレビュースキルがリファクタリングのアイデアまで提案し始めるかもしれません。記述統計だけを欲しかったのに、データ分析スキルが推奨事項を提示してくることもあります。
「〜しないでください」という指示は、挙動を制約するうえで驚くほど効果的です。「コードのアーキテクチャ変更は提案しないでください」「データから直接裏付けられない情報は含めないでください」「謝罪や前置きの定型句は使わないでください」といった指示は、出力をあなたのニーズに合わせて引き締めてくれます。
テストして反復する
初回で完璧に動くシステムプロンプトはありません。多様な入力でスキルをテストすることで、プロンプトの不足部分が見えてきます。単純なケースは上手く扱えるのにエッジケースで失敗するかもしれません。短い入力では正しい出力フォーマットなのに、長い入力で崩れることもあるでしょう。
テストの失敗は、プロンプトのどこを改善すべきかを教えてくれる情報源です。エッジケースの処理を加える、出力フォーマットの仕様を厳密化する、失敗パターンをカバーする例を追加する、といった具合に対処していきます。テストと改良を何回か繰り返すことで、プロンプトは安定した挙動に収束していきます。
プロンプトのバージョン履歴を残しておけば、どの変更が結果を改善し、どの変更がそうでなかったかを追跡できます。これは、ある問題を直した変更が別の問題を再発させてしまう「堂々巡り」という典型的な落とし穴を避けるのに役立ちます。