AIエージェント開発を始めたら、結局ずっと「要件定義」をしていた

AIエージェントを作る、と言うと、何か特別な専門技術の話に聞こえるかもしれません。

私も、正直に言うと、最初は身構えていました。
これは今まで自分がやってきたことと地続きなのか、それとも、まったく新しい世界なのか。近い気はしていたのですが、うまく言葉にできていませんでした。

実際に手を動かしてみて、その正体が分かりました。
やっていたのは、私がずっとやってきた「要件定義」でした。

手を動かして、腹落ちした

一番はっきり感じたのは、お客様の実態を見にいって、高速に作って、試してもらって、直す。これを何度も繰り返しているときでした。

このプロセスに、強い既視感がありました。
プロダクトのPoC（お試し版）を作るとき、新しい機能や新規プロダクトを立ち上げるときに、私が繰り返し繰り返しやってきたループそのものだったからです。

現場に行って、本当に困っていることや実現したいことを見る。
仮説を、動くものにして、目の前で触ってもらう。
反応を見て、違ったら直す。
作っているものがAIエージェントに変わっただけで、やっていることは何も変わっていませんでした。

プロダクトも、業務プロセスも、AIエージェントも

振り返ると、私はこの数年、3つの違うものを作ってきました。
プロダクト。会社の業務プロセス。そして、AIのワークフローとエージェント。

世の中では、この3つは別の仕事として語られます。
プロダクトマネジメント、業務改善、AIエンジニアリング。
求人票も、求められるスキルも、別々に並んでいます。

でも、自分でやってみると、真ん中にある作法は同じでした。
突き詰めると、2つのことをやっているだけです。

1つは、本質的に必要なことを、ピンポイントで特定すること。
お客様の声や現場の実態から、本質的な要求を掘り当てる。言われた要望をそのまま作るのではなく、その奥にある本当に必要なものを見極める作業です。

言われた通りに作ると、大体外します。
「この画面がほしい」の裏には「本当はこの判断を速くしたい」があって、実は画面自体なくてもいいパターンがある。
これを掴めるかどうかで、出来上がるものがまるで変わります。
これはプロダクトでも、業務でも、AIエージェントでも、同じでした。

もう1つは、それを、使いやすい形にちゃんと作り上げること。
大きな塊を、扱えるサイズに分解して、何をやって何をやらないかの境界を引く。

たとえば「やる・やらない」の境界です。
プロダクトなら、初期版で何を載せて、どう線引きをするのか。
業務なら、人がやることと、仕組みに任せることの線。
AIエージェントなら、AIに任せるところと、人が最後に承認するところ。
引いている線の中身は違っても、線を引くという行為そのものは同じでした。

プロダクトの機能を切るのも、業務の工程を整理するのも、AIエージェントのステップを組むのも、私がやっていたのはこの2つでした。
呼び名が違うだけで、頭の使い方は同じだったのです。

つまり「要件定義」だった

言葉にすると、拍子抜けするくらい当たり前かもしれません。
私がAIエージェント開発でやっていたのは、要件定義でした。

何を叶えたいのかを定めて、そこから必要なものを逆算する。
作って、試して、違ったら直す。
プロダクトを作っていた頃と、同じ型の上に立っていました。

やってみて分かったのは、AIエージェント開発でいちばん頭を使うのは、AIの設定そのものではないということです。
AIに何をさせるか、どこまで任せるか、その手前をどう定義するか。ここが決まっていないと、どんなに賢いモデルを使っても、返ってくるものは的を外します。
難しいのは、「何を作るか」の側にありました。

AIエージェントを作る側に回ったとき、私は職種が変わるのかなと思ってました。
でも実際には、PdMとしてやってきた仕事が、名前を変えて続いていただけでした。強いて言えば、プロダクトがプロセスに変わっただけ、かもしれません。

新しい技術に身構える前に、この「要件定義の型」を持っているかどうか。
AIエージェント開発で効いたのは、最新のツールの知識よりも、こちらのほうでした。

ただし、1つだけ大きく変わったことがある

ここまで書くと、全部同じ、で片づけたくなります。
でも、決定的に変わったことが1つだけありました。

自分で、いろいろできるようになったことです。

以前は、要件を定義したら、実装は別のエンジニアに、デザインは別のデザイナーに、などいろんな方にお願いしていました。
私は「何を作るか」を決める人で、「どう作るか」は人に任せる、という分業が前提でした。

AIを使うと、その境界が溶けます。
設計だけでなく、実装も、動かすところまで、自分で手が届いてしまう。
これは、大きな変化でした。

ただ、その分、気をつけることも一気に増えました。
たとえばセキュリティです。
人に任せていた頃は、その人が守ってくれていた領域を、今は自分で意識しないといけない。作れてしまうからこそ、危ないものも作れてしまいます。

設計だけをしていた頃は、この部分は考えなくてよかった、というより、考えられる状態にありませんでした。今は、良くも悪くも、全部が自分の手の中にあります。

そして何より、これまで人にお願いしていた領域を、自分で語れるようにならないと、結局は回らないと痛感しました。
「あとはよろしく」で渡していた部分を、自分の言葉で理解して、判断できる状態にする。
ここができていないと、自分で作れるようになった意味が半分になってしまいます。

作る人と、設計する人の境界が溶ける

まとめると、こうです。

プロダクト作りも、業務プロセスの整理も、AIエージェント開発も、根っこにある設計の作法は同じでした。
本質を特定して、使える形に作り上げる。ずっと要件定義と呼ばれてきた仕事です。

変わったのは、作る人と設計する人の境界が溶けたことです。
設計する人が、そのまま作れてしまう。だからこそ、これまで分業で任せていた領域まで、自分で語れる人の価値が上がっていくのだと思います。

AIエージェント開発と聞いて身構えている方がいたら、伝えたいことは1つです。
もしあなたが、要件を定義して、動くものにして、試して直す、という仕事をしてきたなら、その型はそのまま使えます。名前が変わっただけの、続きの仕事です。

deflagをもっと知りたい方へ

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） → https://x.com/nakamae__deflag
📝 note → https://note.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a