AIエージェント時代に必要なのは、「仕様」ではなく「要件」を考える力です

AIエージェントを使うとき、多くの人は最初から「どう作るか」を指示しようとします。

「この形式で資料を作って」
「このツールを使って自動化して」
「こういうプロンプトで出力して」
「この手順で処理して」

もちろん、具体的な指示は必要です。AIに作業を任せるには、形式、条件、手順を伝える必要があります。ただし、最初から仕様だけを考えると、仕事の目的を見失います。ユーザーが先に考えるべきなのは、仕様ではありません。要件です。

AIエージェント活用では、要求、要件、仕様、実装、テストの順に考え、要件を成功条件として先に定義することを示す図。 — AIはHowを速くします。だからこそ、人間は先にWhatとWhy、つまり要件を決める必要があります。

Contents

要件と仕様の違い

要件定義と仕様の違いは、よくWhatとHowの違いとして扱われます。要件定義は、何を満たすべきかを決めます。仕様は、その要件をどう実現するかを決めます。たとえば、AIエージェントに記事を書かせる場面を考えます。

「1000字でコラムを書いてください」
「見出しを3つ入れてください」
「ですます調で書いてください」

これは仕様に近い指示です。出力の形式や振る舞いを指定しています。一方で、次のように伝えると要件に近づきます。

「読者が、AIを単なる便利ツールではなく、思考を外に出す装置として捉え直せるようにしたい」
「AI活用では、ユーザー側の問いの設計が重要だと伝えたい」
「技術論ではなく、仕事観と思考法として読ませたい」

要件は、何を成立させたいのかを決めます。読後にどんな認識変化を起こしたいのかを決めます。

この違いは大きいです。

AIエージェントは、仕様に従うことが得意です。形式、文体、手順、構成、出力条件、制約を与えれば、かなり正確に処理します。しかし、仕様だけを与えても、良い中身になるとは限りません。仕様は目的ではなく手段だからです。1000字で書くことが成功ではありません。見出しを3つ入れることが成功でもありません。ですます調で書くことが成功でもありません。

本来の成功は、読者に伝わることです。意思決定が変わることです。行動が変わることです。理解が深まることです。つまり、AIエージェント活用でユーザーが担う役割は、作業指示者ではありません。

要件定義者です。

ここを取り違えると、AIの出力は一見きれいでも、使えないものになります。

整っているが刺さらない資料が生まれる理由

たとえば、ビジネス資料を作る場面を考えます。

「10枚のスライドを作って」
「市場規模、課題、解決策、収益モデルを入れて」
「デザインはシンプルにして」

こう頼めば、AIはそれらしい資料を作ります。しかし、その資料が本当に必要な資料かどうかは別問題です。相手は投資家でしょうか。社内の意思決定者でしょうか。現場メンバーでしょうか。

目的は予算獲得でしょうか。合意形成でしょうか。問題提起でしょうか。読み手はどこに疑念を持つでしょうか。何に納得すれば、次の行動に進めるでしょうか。こうした要件が曖昧なまま仕様だけを与えると、整っているが刺さらない資料ができます。

これはAIの失敗ではありません。ユーザー側の要件定義の失敗です。

要件定義書と仕様書の関係

要件定義書と仕様書の関係も、この観点から見ると分かりやすくなります。要件定義書は、何を満たせば成功かを決める文書です。仕様書は、その成功条件をどう実現するかを具体化する文書です。要件定義は、目的、背景、課題、制約、評価基準、優先順位を扱います。仕様は、画面、機能、処理、データ、手順、例外処理などを扱います。

両者は実務ではよく混ざります。要件定義書の中に仕様が書かれることもあります。仕様書という名前の文書に要件が含まれることもあります。だから、文書名だけで判断すると危ないです。見るべきなのは中身です。何を成立条件にするのかが書かれていれば、要件に近いです。どう動かすのか、どう作るのかが書かれていれば、仕様に近いです。概念としては、仕様は要件に従います。要件が上位にあり、仕様は要件の具体化です。

要件は解くべき問題を決めます。仕様は、その問題に対するひとつの解き方を書きます。たとえば、問い合わせ対応を減らしたい、という声があります。これはまだ要求です。困りごと、願望、課題意識に近いものです。そこから、次のように置くと要件に近づきます。

「FAQ検索によって、月間問い合わせ件数を30%減らす」
「ユーザーが24時間自己解決できる導線を用意する」
「初回問い合わせ前に、関連FAQが提示される状態にする」

さらに次のように落とすと仕様になります。

「検索窓をヘッダー右上に置く」
「FAQはカテゴリとタグで分ける」
「曖昧検索に対応する」
「回答候補を3件表示する」
「解決しない場合は問い合わせフォームへ移る」

順番は、要求、要件、仕様、実装、テストです

この順番が重要です。要求、要件、仕様、実装、テスト。本来はこの順に進みます。まず、何に困っているのかを捉えます。次に、何を満たせば成功なのかを決めます。そのうえで、どう実現するかを設計します。そして、実際に作ります。最後に、本当に要件を満たしているかを確かめます。AIエージェントの時代には、この順番がさらに重要になります。理由は、AIがHowを速くするからです。

文章を書く。表を作る。コードを書く。調査する。要約する。資料にする。手順にする。こうした作業の速度は、人間だけで進める場合とは比べものになりません。しかし、Howが速くなるほど、WhatとWhyが曖昧なまま進む危険も増えます。目的が曖昧なまま、AIが大量の中身を出します。評価基準が曖昧なまま、もっともらしい選択肢が並びます。前提が曖昧なまま、実装だけが進みます。その結果、仕様通りにできているのに、欲しかったものではない、という状態が起きます。

これは人間の開発現場でも昔からある問題です。ただし、AIエージェントによって増幅されます。AIは迷わず作ってしまうからです。人間なら途中で違和感を覚えて止まる場面でも、AIは与えられた仕様に沿って最後まで進めます。だからこそ、ユーザーはAIに指示を出す前に、次の問いを持つ必要があります。

何を解決するためのものか。
誰にとって成功すればよいのか。
何が満たされれば十分なのか。
何は満たさなくてもよいのか。
どの制約は守るべきなのか。
出力後、何を基準に良し悪しを決めるのか。

この問いが要件定義です。

プロンプトは要件定義の圧縮表現です

AIエージェント活用の本質は、細かいプロンプト技術だけではありません。むしろ、プロンプト以前に、何を問うべきか、何を成功とするかを決める力にあります。プロンプトは、単なる命令文ではありません。

プロンプトは、要件定義の圧縮表現です。

良いプロンプトには、目的があります。読み手があります。制約があります。評価基準があります。優先順位があります。逆に、悪いプロンプトは、仕様だけを並べます。

「この形式で出して」
「この口調で書いて」
「この順番でまとめて」

それだけでは、AIは作業はできても、意思決定はできません。意思決定の基準が与えられていないからです。もちろん、現実の仕事では、要件から仕様へ一直線に進むわけではありません。AIを使う場合は、むしろ反復が重要です。

仮の要件を置きます。
仮の仕様で出力させます。
出力を見て、違和感を見つけます。
そこで要件を直します。
再び仕様に落とします。

この循環によって、最初は曖昧な要件が少しずつ見えてきます。つまり、AIエージェントは単なる実行装置ではありません。要件を見つけるための対話相手にもなります。ただし、AIに丸投げするという意味ではありません。AIが出してきたものに対して、何を満たしていないのか、なぜ違和感があるのか、本当の目的は何かを問い直す必要があります。