8月10日、Kanwal Mehreenが「Specification Engineering: The New Skill After Prompt Engineering」と題した記事を公開した。この記事では、プロンプトエンジニアリングの次に来る実践スキル「Specification Engineering（仕様エンジニアリング）」の概念と実践的な活用方法について詳しく紹介されている。以下に、その内容を紹介する。
プロンプトだけでは「何が正解か」を定義できない
プロンプトエンジニアリングは、AIに「どう聞くか」を磨く技術だ。しかし、AIがコーディングエージェントや自律ワークフローとして動く場面では、それだけでは足りない。
Mehreenはその核心をこう表現している：
Prompt engineering is how you ask. Specification engineering is how you define what "done correctly" means.
（プロンプトエンジニアリングは「どう聞くか」。スペシフィケーションエンジニアリングは「正しく完了した」とはどういう意味かを定義することだ。）
AIに「バグを直して」と頼めば、見た目は通るパッチを返してくるかもしれない。しかし隠れた前提を壊していれば、それは正解ではない。「レポートを要約して」と頼めば、流暢な文章が返ってくるが、経営陣が本当に必要だった指標が抜けていることがある。
これはAI安全性研究でいう「Specification Gaming（仕様ゲーミング）」と同じ問題だ。AIが書かれた目標は満たしつつ、意図した結果を外す現象を指す。プロンプトは機能した。しかし仕様が失敗した——Mehreenはそう指摘する。
弱いプロンプトと強い仕様の違い
記事中で最も具体的で刺さる対比が、データ分析タスクの例だ。
弱いプロンプト：
「この顧客チャーンデータセットを分析して、インサイトをください。」
強い仕様：
「この顧客チャーンデータセットを分析し、欠損値・クラス不均衡・リーケージリスク・上位予測特徴量を特定すること。前処理前にデータをtrain/testに分割すること。ロジスティック回帰・ランダムフォレスト・XGBoostを比較し、精度・適合率・再現率・F1・ROC-AUC・PR-AUCと混同行列をレポートすること。因果関係の主張は禁止。観察された相関のみに基づいた3つのビジネス提言を含めること。」
後者は単なるプロンプトではなく、仕事そのものの定義だ。
Mehreenが示す「良い仕様」の構成要素は以下の8項目だ：
- Objective（目標）：モデルは何を達成すべきか
- Context（文脈）：モデルが知っておくべき情報
- Inputs（入力）：使用できるデータ・ファイル・ツール・前提
- Output format（出力形式）：最終的な回答の形
- Constraints（制約）：モデルが避けるべきこと
- Evaluation criteria（評価基準）：正解をどう判断するか
- Edge cases（エッジケース）：何が問題になりうるか
- Verification steps（検証ステップ）：どのテストを通過すべきか
この発想は、プロダクトマネジメント・ソフトウェアテスト・データ検証・リサーチデザインに近い。
研究・業界トレンドが裏付ける
この方向性は実証研究でも支持されている。2024年の論文**Requirement-Oriented Prompt Engineering（ROPE）では、30名のノービスを対象にしたランダム化試験で、ROPE訓練が要件記述能力を20%向上させた一方、従来型のプロンプトエンジニアリング訓練では1%**にとどまったと報告されている。入力要件の質がLLM出力の質と直結することも確認されている。
産業側でも同様の動きがある。OpenAIのStructured Outputs機能はJSONスキーマへの厳密な準拠をAPIで実現し、**OpenAI Model SpecやAnthropicのConstitutional AI**はモデルの振る舞いを仕様書で定義するアプローチを採用している。AI業界そのものが、プロンプトから仕様へと移行している。
コーディングベンチマークでも、**SWE-bench**が実際のGitHubイシューをコードベスを編集して解決できるかを評価するなど、テストと検証を軸とした実力測定が主流になりつつある。
新しいワークフローの形
Mehreenが提示する今後のAI活用フローは以下だ：
仕様の作成 → 生成 → 検証 → 修正 → 監査
具体的には：
- タスク仕様を書く
- AIに不足している要件を指摘させる
- AIにソリューションを生成させる
- テストやチェックを実行する
- 失敗したチェックのみに対して修正を依頼する
- 最終的な前提と限界をログに残す
**Google DORA 2025レポート**（約5,000名の技術者を対象）も同じ結論を示している。AIは既存の組織的強みと弱みを増幅するアンプであり、強固なプロセスはAIによってさらに強化され、弱いプロセスも同様に増幅される。AIはエンジニアリング規律の必要性をなくすのではなく、それを持つことへのリターンを高める——Mehreenはそう述べている。
スペシフィケーションエンジニアリングは、プロンプトエンジニアリングを否定するものではなく、その上位概念に位置づけられる。AIシステムが自律的になるほど、「モデルにどう答えさせるか」よりも「タスクをどう定義するか」が問われる場面が増えていく。
詳細はSpecification Engineering: The New Skill After Prompt Engineeringを参照していただきたい。
