プロンプトエンジニアリングの次は仕様の設計が重要となる
本文の状態
日本語全文を表示中
詳細モードで約11分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
KDnuggets
AI がチャットボットからコーディングエージェントや自律ワークフローへ移行する中、LLM からより良い結果を得るために、明確なプロンプト作成に加え、仕様を設計するスキルが新たな必須能力として注目されている。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るAI深層分析を開く2026年8月10日 23:33
AI深層分析
キーポイント
プロンプトエンジニアリングの限界
明確な指示を出しても、AI が生成した回答が実際の要件や隠れた前提を満たしているか保証できず、外見上は正しくても実用性に欠けるケースが発生する。
仕様設計の定義と役割
仕様設計とは、タスクの目標、制約、期待される出力、エッジケース、テスト、成功基準、および失敗モードを明確に定義し、実行可能で検証可能な指示セットへ変換する実践である。
仕様のゲーム(Specification Gaming)
AI が書かれた目的には合致しつつも意図した結果から外れる現象が日常化しており、バグ修正でテストは通すが隠れた前提を壊すなどの事例が報告されている。
構造化されたタスクへの対応
SQL 生成やコードベースの改変など、AI が複雑な意思決定を行う場面では、出力の検証可能性や他システムとの連携可否が問われるため、厳密な仕様の定義が必要となる。
仕様の具体化による実行可能性の向上
曖昧なタスクを実行可能でテスト可能な指示セットに変換する実践が仕様エンジニアリングである。従来のプロンプトは単なる依頼に過ぎず、仕様は作業そのものを定義する。
重要な引用
Prompt engineering is how you ask. Specification engineering is how you define what "done correctly" means.
AI safety researchers have long studied specification gaming, where an AI system satisfies the written objective while missing the intended outcome.
"Specification engineering is the practice of turning a vague task into an executable, testable, reviewable instruction set."
"The second version does more than prompt. It defines the work."
編集コメントを表示
編集コメント
本記事は、AI の実用化が進む中で「指示出し」から「要件定義」へとパラダイムシフトが必要であることを示唆しており、現場のエンジニアリングプロセスを見直す重要な視点を提供する。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

ここ 2 年間、人々は大規模言語モデル(LLM)からより良い結果を引き出すために、明確なプロンプトを書く方法を学んできました。文脈の追加、役割の定義、例示、形式の指定、そして反復です。これは依然として有用な手法ですが、AI がチャットボットからコーディングエージェント、研究アシスタント、データサイエンスのコパイロット、自律的なワークフローへと進化していく中で、「良いプロンプト」だけではもはや不十分になっています。
新しいスキルが「仕様のエンジニアリング(Specification Engineering)」です。これは、AI を活用したタスクの目標、制約条件、期待される出力、エッジケース、テスト、成功基準、そして失敗モードを定義する能力を指します。簡単に言えば以下のようになります。
プロンプトエンジニアリングは「どう尋ねるか」であり、仕様のエンジニアリングは「何が正しく完了したとみなすか」を定義する方法です。
# なぜプロンプトエンジニアリングだけでは不十分なのか
**
プロンプトは魅力的な回答を生み出すことができます。しかし、その回答が実際に許容できるものかどうかを判定するのは仕様です。
この区別が重要なのは、現代の AI システムが単に段落を生成するだけではないからです。SQL クエリの作成、コードベースの変更、スプレッドシートの分析、構造化された JSON の出力、アプリケーションの構築、そして多段階の意思決定などを行っています。こうした場面では、「モデルが応答できるか」という問題だけでなく、以下の点が問われます。
- 要件を満たしたか
- 制約を遵守したか
- エッジケースは適切に処理されたか
- 出力を検証できるか
- 他のシステムが結果を利用できるか
- 間違ったものを最適化していないか
最後の質問、特に重要です。AI セーフティ研究者たちは長年「仕様のゲーム(specification gaming)」を研究してきました。これは、AI システムが書かれた目的には合致しているように見えても、意図した成果から外れてしまう現象です。
今や日常の AI 作業でも同じ問題が見られます。「バグを直して」とコーディングエージェントに指示すると、目に見えるテストは通過するパッチを作成する一方で、隠れた前提条件を壊してしまうことがあります。「このレポートを要約して」と指示すると、流暢な要約文を出力するものの、経営層が本当に必要としていた指標が抜けてしまうこともあります。「このデータセットをクリーンアップして」と指示すると、調査すべき行を無断で削除してしまうかもしれません。
プロンプトは機能しました。しかし、仕様(specification)は失敗したのです。
仕様のエンジニアリングとは何か
仕様のエンジニアリングとは、曖昧なタスクを実行可能で、検証可能で、レビュー可能な指示セットへと変換する実践です。
弱いプロンプトの例:
「この顧客離脱データセットを分析し、インサイトを教えて。」
より良い仕様の例:
「顧客離脱データセットを分析し、欠損値、クラス不均衡、リーケージリスク、および主要な予測特徴量を特定してください。前処理を行う前にデータをトレーニング用とテスト用に分割してください。ロジスティック回帰、ランダムフォレスト、XGBoost を比較し、精度、適合率、再現率、F1 スコア、ROC-AUC、PR-AUC、および混同行列を報告してください。因果関係を主張しないでください。観測された相関関係にのみ基づいた 3 つのビジネス推奨事項を含めてください。」
この第二版は単なるプロンプトを超えており、作業そのものを定義するものです。
優れた仕様書には通常、以下の要素が含まれます。
- 目的: モデルが達成すべきことは何か?
- 文脈: モデルが知る必要がある情報は何か?
- 入力: 許可されるデータ、ファイル、ツール、または前提条件は何か?
- 出力形式: 最終的な回答はどういったものになるべきか?
- 制約事項: モデルが避けるべきことは何か?
- 評価基準: 正しさをどのように判断するか?
- エッジケース: 何が失敗する可能性があるか?
- 検証ステップ: 通過させる必要があるテストやチェックは何か?
このため、仕様エンジニアリングは従来のプロンプトよりも、製品管理、ソフトウェアテスト、データ検証、研究設計に近く感じられます。
# 研究もすでにその方向を指し示している
2024 年に発表された論文「Requirement-Oriented Prompt Engineering」は、プロンプト学習の多くがロールプレイや「ステップバイステップで思考する」といったテクニックに偏っている一方で、複雑な LLM の利用には明確な要件定義がより重要であると指摘しています。30 名の初心者を用いたランダム化比較試験では、ROPE(Requirement-Oriented Prompt Engineering)トレーニングを受けたグループの要件記述能力が 20% 向上したのに対し、従来のプロンプトエンジニアリングを学んだグループはわずか 1% の改善にとどまりました。著者らはさらに、入力される要件の質と LLM が出力する結果の質には明確な相関関係があることも発見しています。
この傾向は、実際の AI ツールでも確認できます。OpenAI の「Structured Outputs」機能では、開発者がモデルの応答を JSON スキーマに一致させるよう制約でき、公式の評価テストでもスキーマへの厳密な準拠が報告されています。これは API 形式での仕様エンジニアリングと言えます。モデルが偶然有効な JSON を返すのを期待するのではなく、出力が従うべき構造を開発者が定義するのです。
OpenAI の「Model Spec」や Anthropic の「Constitution」も、同様の考え方をモデルの振る舞いレベルで示しています。OpenAI は Model Spec を、ChatGPT や API において自社のモデルがどのように振る舞うべきかを規定する文書として説明しており、Anthropic の Constitutional AI もまた、モデルの行動を導くための成文化された原則を採用しています。
つまり、AI 業界全体が「プロンプト」から「仕様」へと移行しているのです。
# バイブコーディングから仕様駆動型コーディングへ
この違いは、AI を活用したコーディングにおいて特に明確に現れます。
プロンプトエンジニアリングのアプローチでは、以下のような指示が出されることがあります。
「簡単な経費管理アプリを作って」
一方、仕様エンジニアリングのアプローチでは、より具体的な指示がなされます。
「React を使った経費管理アプリを作成してください。機能は、項目の追加・編集・削除、カテゴリによるフィルタリング、月ごとの合計表示、ローカルストレージへの永続化です。金額は正数であることを検証し、日付は必須とし、カテゴリは必ず選択させるようにしてください。また、追加・削除・フィルタリング・合計計算に関するユニットテストを含めてください。外部の有料 API は使用しないでください。まずはファイル構造を提示し、その後ファイルを一つずつ実装してください。」
このように指示することで、AI が危険な方向で独断して振る舞う余地を減らすことができます。
これは重要な点です。なぜなら、ソフトウェアエンジニアリングのベンチマークは、もはや単なるコードスニペットの生成ではなく、実際の課題やテスト、検証に基づいて構築されつつあるからです。例えば SWE-bench は、モデルが孤立したコードを生成するだけでなく、実際に GitHub の課題を解決するためにコードベースを編集できるかを評価します。OpenAI's SWE-bench Verified は、現実世界のソフトウェア課題解決能力をより信頼性高く評価するために、人間が検証したサブセットとして作成されました。
それでもなお、テストは完璧ではありません。SWE-bench Verified におけるエージェント生成パッチの研究では、テストに合格したパッチであっても、人間の作成したパッチと意味のある違いがあることが示されており、ベンチマークのテストカバレッジには限界があることがわかりました。また別の論文 SWT-Bench では、生成されたテストが提案されたコード修正に対する効果的なフィルターとして機能し、SWE-Agent の精度を倍増させることができることが発見されています。
# 新しいワークフロー
将来の AI ワークフローは、以下のような形から
プロンプト → 出力 → 手動修正
へと移行し、より以下の形へと変わっていくでしょう。
仕様定義 → 生成 → 検証 → 改訂 → 監査
例えば、次のような手順です。
- タスクの仕様を記述する。
- AI に不足している要件がないか確認させる。
- 解決策の生成を依頼する。
- テストやチェックを実行する。
- 失敗した項目に対してのみ修正を依頼する。
- 最終的な前提条件と制限事項をログに記録する。
これは特に、エージェント型システムにおいて重要です。OpenAI の実践的エージェントガイド では、複雑なリソースをより小さく明確なステップに分解し、各ステップが特定のアクションや出力に対応していることを確認するよう推奨しています。これがワークフローにおける「仕様エンジニアリング」の適用例です。
Google の DORA 調査 も、この方向性を裏付けています。同レポートは約 5,000 名の技術専門家を対象に実施され、AI は既存の組織的な強みと弱みを増幅するものであるという結論に至りました。堅牢なプラットフォームと高品質なプロセスがあれば、チームは AI からより大きな価値を引き出せます。一方で、脆弱なプロセスもまた増幅されてしまいます。
これは警鐘として受け止めるべきです。AI がエンジニアリングの専門性を不要にするわけではありません。むしろ、その専門性を持つことのメリットを大きくするものです。
結びの言葉
プロンプトエンジニアリングが死んだわけではありません。それはより大きな分野の一部へと進化しているのです。
初期の AI 時代には、チャットボットからより良い回答を引き出せる人が評価されました。しかし次の時代は、信頼できる AI の作業を設計できる人に報われます。具体的には、要件が明確で、出力形式が構造化され、評価チェックがあり、境界線が明示されたタスクです。
求められるスキルはもはや単に「質問する」ことだけではありません。
「どうすればモデルに回答させられるか?」
ではなく、こう問うことが重要になります。
「どうすれば、モデル・ユーザー・評価者が『正しい回答』について合意できるかを定義できるか?」
これがスペシフィケーションエンジニアリングです。AI システムがより自律化していくにつれ、プロンプトエンジニアリングに次ぐ最も重要な技術スキルの一つとなる可能性があります。
Kanwal Mehreen 氏は機械学習エンジニアであり、データサイエンスと AI と医療の交差点に対する深い情熱を持つテクニカルライターです。共著書に『ChatGPT で生産性を最大化する』があります。2022 年の APAC 地域 Google Generation Scholar に選出され、多様性と学術的卓越性の推進に尽力しています。また、Teradata Diversity in Tech Scholar、Mitacs Globalink Research Scholar、Harvard WeCode Scholar としても認定されています。Kanwal は変革の熱心な支持者であり、STEM 分野の女性を支援するために FEMCodes を設立しました。
原文を表示

**
For the last two years, people have learned to get better results from large language models (LLMs) by writing clearer prompts: add context, define the role, give examples, specify the format, and iterate. This is still useful. But as AI moves from chatbots to coding agents, research assistants, data science copilots, and autonomous workflows, "good prompting" is no longer enough.
The new skill is specification engineering**: the ability to define the goal, constraints, expected outputs, edge cases, tests, success criteria, and failure modes of an AI-assisted task. In simple terms:
Prompt engineering is how you ask. Specification engineering is how you define what "done correctly" means.
# Why Prompt Engineering Is Not Enough
**
A prompt can produce a good-looking answer. A specification defines whether that answer is actually acceptable.
This distinction matters because modern AI systems are not just generating paragraphs. They are writing SQL queries, modifying codebases, analyzing spreadsheets, producing structured JSON, building applications, and making multi-step decisions. In these settings, the main problem is not only "Can the model respond?"** It is:
- Did it satisfy the requirement?
- Did it respect the constraints?
- Did it handle edge cases?
- Can the output be validated?
- Can another system consume the result?
- Did it optimize the wrong thing?
That last question is especially important. AI safety researchers have long studied specification gaming, where an AI system satisfies the written objective while missing the intended outcome.
This is the same problem we now see in everyday AI work. Ask an AI coding agent to "fix the bug," and it may produce a patch that passes a visible test but breaks a hidden assumption. Ask a model to "summarize this report," and it may produce a fluent summary while omitting the one metric leadership actually needed. Ask it to "clean this dataset," and it may silently drop rows that should have been investigated.
The prompt worked. The specification failed.
# What Specification Engineering Means
**
Specification engineering is the practice of turning a vague task into an executable, testable, reviewable instruction set.
A weak prompt says:
"Analyze this customer churn dataset and give me insights."
A better specification says:
"Analyze this customer churn dataset. Identify missing values, class imbalance, leakage risk, and top predictive features. Split the data into train/test before preprocessing. Compare logistic regression, random forest, and XGBoost. Report accuracy, precision, recall, F1, ROC-AUC, PR-AUC, and a confusion matrix. Do not claim causality. Include three business recommendations linked only to observed correlations."
The second version does more than prompt. It defines the work.
A good specification usually includes:
- Objective: What should the model achieve?
- Context: What does the model need to know?
- Inputs: What data, files, tools, or assumptions are allowed?
- Output format: What should the final answer look like?
- Constraints: What should the model avoid?
- Evaluation criteria: How will we judge correctness?
- Edge cases: What could go wrong?
- Verification steps: What tests or checks must pass?
This is why specification engineering feels closer to product management, software testing, data validation, and research design than traditional prompting.
# The Research Is Already Pointing This Way
A 2024 paper on Requirement-Oriented Prompt Engineering** argues that much prompt training focuses on tricks like role-play or "think step by step," while complex LLM use depends more on clear requirement articulation. In a randomized study with 30 novices, their ROPE training improved users' requirement-writing ability by 20%, compared with 1% for conventional prompt engineering training. The authors also found a direct relationship between the quality of input requirements and the quality of LLM outputs.
We see the same trend in production AI tools. OpenAI's Structured Outputs feature lets developers constrain model responses to match a JSON schema, with strict schema adherence reported in its own evals. This is specification engineering in API form: instead of hoping the model returns valid JSON, the developer defines the structure the output must obey.
OpenAI's Model Spec and Anthropic's Constitution show the same idea at the model-behavior level. OpenAI describes the Model Spec as a document that specifies how its models should behave in ChatGPT and the API, while Anthropic's Constitutional AI uses written principles to guide model behavior.
In other words, the AI industry itself is moving from prompts to specifications.
# From Vibe Coding to Spec-Driven Coding
**
The difference becomes very clear in AI coding.
A prompt-engineering approach might say:
"Build me a simple expense tracker app."
A specification-engineering approach says:
"Build a React expense tracker with add, edit, delete, category filter, monthly total, and local storage persistence. Validate that amount is positive, date is required, and category is selected. Include unit tests for adding, deleting, filtering, and total calculation. Do not use external paid APIs. Return the file structure first, then implement one file at a time."
The second version gives the AI less room to improvise in dangerous ways.
This matters because software engineering benchmarks are increasingly built around real issues, tests, and validation. SWE-bench, for example, evaluates whether models can resolve real GitHub issues by editing codebases, not just produce isolated code snippets. OpenAI's SWE-bench Verified** was created as a human-validated subset to more reliably evaluate real-world software issue solving.
Even then, tests are not perfect. A study of agent-generated patches on SWE-bench Verified found that even patches passing tests could differ meaningfully from human patches, showing limitations in benchmark test coverage. Another paper, SWT-Bench, found that generated tests can act as an effective filter for proposed code fixes, doubling the precision of SWE-Agent.
# The New Workflow
**
The future AI workflow will look less like this:
prompt → output → manually fix
and more like this:
specification → generation → validation → revision → audit
For example:
- Write the task specification.
- Ask the AI to identify missing requirements.
- Ask it to generate the solution.
- Run tests or checks.
- Ask it to revise only against failed checks.
- Log the final assumptions and limitations.
This is especially important for agentic systems. OpenAI's practical agent guidance** recommends breaking down dense resources into smaller, clearer steps and ensuring every step maps to a specific action or output. That is specification engineering applied to workflows.
Google's DORA research also supports this direction. The report surveyed nearly 5,000 technology professionals and concluded that AI acts as an amplifier of existing organizational strengths and weaknesses. Strong platforms and quality processes help teams get more value from AI. Weak processes are amplified too.
That should be a warning. AI does not remove the need for engineering discipline. It increases the payoff from having it.
# Final Thoughts
**
Prompt engineering is not dead. It is becoming part of a larger discipline.
The early AI era rewarded people who could get better answers from chatbots. The next era will reward people who can design reliable AI work: tasks with clear requirements, structured outputs, evaluation checks, and explicit boundaries.
The skill is no longer just asking:
"How do I get the model to answer?"
It is asking:
"How do I define the task so the model, the user, and the evaluator agree on what a correct answer is?"
That is specification engineering. And as AI systems become more autonomous, it may become one of the most important technical skills after prompt engineering.
Kanwal Mehreen** is a machine learning engineer and a technical writer with a profound passion for data science and the intersection of AI with medicine. She co-authored the ebook "Maximizing Productivity with ChatGPT". As a Google Generation Scholar 2022 for APAC, she champions diversity and academic excellence. She's also recognized as a Teradata Diversity in Tech Scholar, Mitacs Globalink Research Scholar, and Harvard WeCode Scholar. Kanwal is an ardent advocate for change, having founded FEMCodes to empower women in STEM fields.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み