テクノロジー · July 21, 2026 · 約8分
ソフトウェアエンジニアのためのプロンプトエンジニアリング: 逆向きのコードレビューとしてのプロンプト
エンジニアにとって、プロンプトは言い回しのテクニックではなく、システム設計とコードレビューそのものです。制約を明示し、テストを含め、出力を読み、非推奨の呼び出しを見抜く。実践的なワークサンプルと、その評価方法を紹介するガイドです。
エンジニアは、毎日の業務でAIアシスタントとともに働いた最初の専門職でした。だからこそ、このスキルを正確に捉える価値があります。それは気の利いたプロンプトを打ち込んで期待するだけのものではありません。AIから真のレバレッジを得るエンジニアは、あらゆるインターフェースと同じようにプロンプトを扱います。契約、制約、そして失敗モードを定義し、返ってきたものを検証するのです。これは当社の役割別プロンプトエンジニアリングシリーズにおけるソフトウェアエンジニアリングの記事であり、AI Sandboxが最も明確に浮かび上がらせるものの一つです。
プロンプトは逆向きのコードレビューである
最近のあらゆる研究にわたって通用するベストプラクティスは、表面的には退屈なものです。依頼する前に成功基準と制約を述べ、モデルに構造化された入力を与え、望む出力を正確に指定する。プロンプトエンジニアリングは「より長いプロンプトを書くこと」にはならず、「より明確な仕様を書くこと」になったのです。だからこそ、それはエンジニアにシステムエンジニアのように考えることを強います。しかし、強い人と弱い人を実際に分けるのは、コードが現れたあとに起こることです。それを批判的に読み、微妙な問題を見抜くこと——非推奨の呼び出し、本来表面化させるべき4xxを飲み込んでしまうリトライ、処理されていないエッジケース。これはコードに適用されたAIフルーエンシーです。
ワークサンプル
アシスタントに、リトライロジックを備えた非同期APIクライアントを求めてみましょう。弱いプロンプトは「リトライ付きでユーザーを取得する関数を書いて」です。強いプロンプトは、契約、制約、そして——決定的に重要なこととして——そのコードが通らなければならないテストを明確に定めます。そのうえでエンジニアは結果を読み、生成されたリトライループが本来スローすべき404でバックオフしていることに気づき、それを修正し、テストを実行して確認します。
## TASK
Write an async fetchUser(id) client method in TypeScript.
## CONSTRAINTS
- Modern async/await fetch — no deprecated request libraries
- Retry on 5xx and network errors only, never on 4xx
- Exponential backoff with jitter, max 3 attempts, 5s per-attempt timeout
## TESTS IT MUST PASS
- Returns parsed JSON on 200
- Throws immediately on 404 (no retry)
- Gives up after 3 failed attempts
## OUTPUT
Code first, then one line on any assumption you made.- 良い例: リクエストに制約を課し、モデルにテストを渡し、出力を読み、非推奨または安全でないコードを見抜き、素早い実行で検証する。
- 弱い例: 「リトライ付きのfetchを書いて」を貼り付け、最初のもっともらしい関数を受け入れ、4xxのバグを残したまま出荷する。
本当に効果を生むベストプラクティス
- 長さより構造。リクエストを一つの長い段落にするのではなく、タスク、入力、制約、出力形式といったセクションに分ける。推論の質は容量を使い切るよりずっと前に劣化しがちなので、簡潔で明確なほうが冗長より優れている。
- モデルにあなたのテストを渡す。要件だけでなく、コードが通らなければならないケースを含める。すると、汎用的な基準ではなく、あなたの基準に合わせて書いてくれる。
- コードの前に推論を示させる。そうすれば、その上に構築された実装を読み進める前に、誤った前提が見えるようになる。
- テストスイートをevalとして扱う。出力は正しそうに見えるから完成なのではない——通ったときに完成なのだ。
最もレバレッジの高い習慣は一つ: プロンプトにテストを入れること。モデルに「正しい」とは何かを伝えるエンジニアは、機能を説明して期待するだけのエンジニアよりも、はるかに高い確率で正しいコードを得る。
よくある失敗モード
- 貼り付けて出荷: 自信ありげに見えるコードを読まずに信頼する。
- 曖昧な依頼: 制約も出力形式もないため、モデルは推測する——しかも汎用的に推測する。
- 検証ステップの欠如: コードがコンパイルできたから正しいに違いない（信頼できる形では正しくない）。
私たちの評価方法
これらのいずれも、プロンプト構文についてのクイズでは測れませんし、面接でAIを禁止しても何も学べません。候補者を、実際に使うであろうツールとともに現実的なエンジニアリング課題に置き、どう指示し、読み、修正するかを観察するのです——それこそがAI Sandbox評価が行うことであり、AIフルーエンシーが一つの柱として採点される方法です。強力なソフトウェアエンジニア評価が他に何をカバーするか、なぜこれがAIネイティブ採用において仕事を誠実にテストする方法なのか、あるいは役割に合わせて調整された評価が組み立てられる様子を見る。
A different model judges the maker's output — cross-model review, not a rubber stamp.
最も優れたエンジニアはコードを求めてプロンプトを書くのではない。ドラフトを求めてプロンプトを書き、そのうえで、どんなプルリクエストにも向けるのと同じ懐疑心をそれに向ける——そしてその懐疑心こそが、採用する価値のあるものなのだ。
執筆者
Jakir Patel · Founder, Hanzomon
Building H-Evaluate — AI-native, quality-gated hiring assessments. Writes about assessment engineering, hiring integrity and compliance-first AI.