要件定義をAIでという提案を受け取った方へ

「上流工程もAIエージェントが担います」という説明を受けて、どこまで本当に任せられるのか測りかねている方に向けて書いています。

判断材料が出ました。やろうとしている会社が、機能の中身まで公開したからです。

発表されたのは上流の3工程です

JBCCホールディングスが2026年7月31日、AIスタートアップのスパイスコードと業務提携し、現状分析や要件定義を自律的に行う「SIエージェント」を共同開発すると発表しました（プレスリリース）。目標は2026年9月末です。

同社は基幹システムの開発手法として「JBアジャイル」を持ち、5回の反復開発で要望を洗い出す進め方をとっています。その上流工程にAIを入れる、という位置づけです。

想定されている機能は3つ。リリースの記述をそのまま並べます。

機能 AIが行うこと
現状分析 既存システムの仕様書や業務フローを読み込み、業務の流れと構造を人が理解しやすい形に整理・可視化する
構想策定 ヒアリング内容をもとに解決の仕組みや機能を提案し、必要な機能とそうでない機能を整理して範囲を絞り込む提案も行う
要件定義 打ち合わせで決まった内容をもとに、業務の流れ・データ設計・システムへの条件・機能一覧などの仕様書を自動作成する

3つ目の説明に条件が書いてあります

太字にした箇所が、この記事で一番言いたいところです。

要件定義エージェントの入力は「打ち合わせで決まった内容」です。**決まったあとに動きます。**決める場に出て決めるわけではありません。

構想策定のほうも同じ構造です。範囲を絞り込む「提案」を行う、と書かれています。提案は決定ではない。採るか採らないかは発注側に残ります。

これは書きぶりの問題ではなく、機能の定義です。宣伝目的のリリースで、ここまで条件を明記しているのは誠実な部類だと思います。

解こうとしているのは別の問題です

では何が新しいのか。リリースが背景として挙げているのは、ハルシネーションです。膨大で複雑な業務情報を扱うとAIが誤った回答を返すリスクがあるため、基幹システム開発での全面的なAI活用は難しいとされてきた、と書かれています。

そこへ持ち込まれたのが「長期記憶」という技術です。文書・音声・各種データから業務上重要と判断したものを長期的に蓄積し続ける。これによって、顧客の業務知識、仕様変更の経緯、設計上の判断を貯め、要件や決定事項を設計・開発・テスト・運用まで一貫して引き継ぐ。

読み替えると、狙いは要件定義を速くすることではなく、決めた経緯が消えないようにすることです。

要件定義が失敗する原因を思い出すと、これは筋が通っています。仕様が決まらないから失敗するのではありません。決めたはずのことが、担当者の異動や工程の切り替わりで失われ、後工程で別の解釈が入る。そこで手戻りが起きます。コードを書く前に4つの工程が置かれていたSiemensの事例も、材料を揃える工程に人が入る構成でした。同じ場所を狙っています。

取り込むものの一覧が、発注側の宿題です

長期記憶に何を入れるかも公開されています。現行システムの仕様書とソースコード。業務マニュアル。顧客辞書。過去の仕様変更の経緯が分かるドキュメント。ベテラン社員の操作ログ。メールとチャットの記録。

これは、そのまま発注側の準備リストです。

自社にどれだけ揃っているかを数えてみると、要件定義AIを入れる難易度が見えます。操作ログは残っているか。仕様変更の経緯は文書として存在するか。それとも当時の担当者の記憶の中にあるか。

ここが薄い状態でAIを入れても、蓄積されるものが薄いだけです。仕様書のないシステムを読む工程が先に要ります。費用が動くのはAI側ではなく、この資料整備の側です。

まだ無いと書いてある機能があります

もう1つ、読み飛ばしやすい記述があります。

「全工程を通じて顧客との合意事項の経緯を記録する機能」は、追加開発する計画として書かれています。開発や運用保守といった下流の機能も同じ扱いです。今回作るのは上流3工程で、合意の記録はこれからです。

決定の経緯を残すことが狙いだと述べたうえで、その記録機能は次の段階に置かれている。順序としては自然ですが、提案を受ける側は現時点で何が動くのかを分けて聞く必要があります。

同じ領域の製品が続けて出ています

これは1社の動きではありません。同じ2026年7月31日に、ROUTE06が要件定義AI「Acsim」へテスト自動化機能を追加すると発表しています（IT Leaders）。こちらは要件・仕様の段階からテストケースとテストコードを生成する機能で、上流の成果物を下流へつなぐ方向です。要件定義に特化したエージェントを掲げる製品も、ほかに複数あります。

同じ日に別々の会社が上流工程を発表している。いま各社が同時に手を付けている場所だということです。

裏を返すと、選定基準がまだ固まっていない領域でもあります。比較の軸を自分で持たないと、機能一覧の多さで決めることになります。

要件定義AIを提案されたときに確認する4点

  • AIが動き始めるのはどの時点からですか: 決定の前か後か。「打ち合わせで決まった内容をもとに」書くのであれば、決める会議の回数と時間は減りません。工数削減の見積もりがどの工程を指しているかを聞きます
  • 何を読み込ませる前提ですか: 仕様書、ソースコード、業務マニュアル、変更の経緯、操作ログ、メールとチャット。この一覧に対して自社に何が揃っているかを数えます。足りないぶんは発注側の作業です
  • 決定の経緯はどこに残りますか: AIが記録するのは発言や文書であって、決裁ではありません。誰がいつ何を承認したかを、どの仕組みで残すのかを別に確認します
  • 出力の誤りは誰が見つけますか: 自動生成された仕様書を、どの立場の人が、どの粒度でレビューするのか。ここが決まっていない提案は、後工程で発注側が全部読むことになります

ベンダー面談やコンペの評価シート、社内の稟議資料にそのまま転記して使えます

現場メモ

私たちも要件定義でAIを使っています。使いどころは、リリースの書き方とほぼ同じです。既存の資料を読ませて構造を出す。打ち合わせの記録から仕様の草案を起こす。前に決めたことと矛盾していないかを突き合わせる。

やらせていないのは、決めることです。理由は能力の問題ではなく、あとで説明できないと困るからです。「なぜこの機能を外したのか」を数か月後に聞かれたとき、判断した人がいないと答えられません。

不利なことも書いておきます。この使い方だと、削減できるのは書く時間であって、決める時間ではありません。要件定義の工期は、打ち合わせの回数と、社内で承認が下りるまでの日数で決まります。そこはAIを入れても動きませんでした。短くなったのは、議事から仕様書の形にするまでの往復です。

短縮幅として派手ではないので、提案の場では見劣りします。それでも、この線を引いているほうが後半で崩れません。

何が残るか

上流工程がAIに移ると、発注側の仕事が減ると読まれがちです。公開された機能の中身を見るかぎり、そうではありません。移っています。

減るのは、決まったことを文書の形にする時間です。増えるのは、読み込ませる資料を揃える手間と、出力が自社の実態に合っているかを確かめる目です。そして決めること自体は、まるごと残ります。

基幹の中が標準で自動化されるほど発注側の仕事は外側へ移るという構造と同じです。使っているかではなく何を決めたかで差が出るという話とも重なります。道具が上流へ来たぶん、決める場の設計が効くようになりました。

自社の要件定義で、どこまでが資料として存在し、どこから人の記憶に頼っているのかを整理したい段階でしたら、お問い合わせからご相談ください。ツールの選定ではなく、揃っているものを数えるところから入ります。