第1章 第2話　「こうしたい」だけ伝えたら、AIはどこまで要件を作れる？

前回は、既存システムのAs-Is整理をAIに任せました。

設計書、Python実装、入力CSV、実行結果。

複数の資料を与え、

とSource of Truthを変えて分析させました。

結果、クラウドAIはかなり正確に情報源を切り分けた一方、ローカルLLMは設計書の内容を「実装にも存在する」と誤認する場面がありました。

そこで今回は、逆方向へ行きます。

設計書もありません。

実装もありません。

あるのは、

という一文だけです。

この状態からAIは、実装へ進む前に必要な確認事項をどこまで自力で洗い出せるのでしょうか。

タイトルでは「要件を作れる？」としていますが、正確には今回は、

「要件を作るために、何を人間へ確認すべきかをAI自身に洗い出させる」

実験です。

今回は、

AIは答えられるか？

ではなく、

AIはちゃんと質問できるか？

を試します。

今回AIに渡す情報は、これだけ

新しく、

chapter1/requirements/request.md

を作成しました。

中身はこちらです。

# 実現したいこと

エリア単位で連携される日次売上金額を、
そのエリアに所属する店舗へウェイトに応じて按分し、
店舗単位の日次売上データを作成したい。

以上。

かなり短いです。

入力ファイルの形式もありません。

店舗マスタの仕様もありません。

ウェイトの意味もありません。

端数処理もありません。

エラー処理もありません。

そして今回は、前回作ったAs-Isの設計書やPython、CSVはAIから見えない場所へ退避しました。

つまり、

この一文だけを読んで考えてもらいます。

今回のルール

AIには、

と指示しました。

今回見たいのは、

人間へ何を確認する必要があるか

だからです。

主な指示は、

というもの。

例えば、

と勝手に決めるのではなく、

と質問に戻せるかを見ます。

人間側では、先に「聞いてほしいこと」を考えておく

もちろんAIには教えません。

比較用として、人間側では事前に確認したい論点をいくつか想定しておきました。

例えば、

入力データのgrain
出力データのgrain
対象店舗の条件
店舗所属の基準日
ウェイトの意味
ウェイトの有効期間
ウェイト未設定時
ウェイト合計0
負のウェイト
小数ウェイト
正式な按分式
端数処理
残額処理
按分前後の総額一致
売上0円
売上負数
対象店舗なし
重複データ
エラー時の処理単位
通知
再処理
手動補正

などです。

このリスト自体が唯一の正解というわけではありません。

ただ、

AIが要求文からどの程度まで自力で論点を広げられるか

を見るための物差しにはなります。

なお、今回の結果は厳密なLLMベンチマークではありません。

クラウドAIは1回、ローカルLLMは初回と再実行の2回を観察しています。

したがって、

という性能比較を目的としたものではありません。

あくまで、今回の条件でどのような違いが観察されたかを見ていきます。

まずはクラウドAI

今回もクラウド側は、

GPT-5.6 Sol

を使用しました。

結果。

かなり出ました。

個別質問として45個。

45個の確認事項が出てきた

最初は、

から始まりました。

税込・税抜。

総売上・純売上。

返品や取消を含むのか。

さらに、

というところまで進みます。

そして店舗についても、

と続きました。

ウェイトについてもかなり細かい

ウェイトについては、

から始まり、

まで質問しています。

ここはかなり良かったです。

「ウェイトで按分する」とだけ聞いて、

売上 × ウェイト

と勝手に実装を始めませんでした。

按分処理で一番怖い「端数」も拾った

今回、個人的にかなり重要だと思っていたのが端数です。

例えば、

1000円

を3店舗へ同じ比率で按分すれば、

333.333...

になります。

このとき、

だけでは終わりません。

AIはさらに、

まで出してきました。

これはかなり実務的です。

grainも聞いてきた

データ処理では重要な、

1レコードが何を表すのか

についても質問が出ました。

入力について、

出力についても、

と確認しています。

この辺りは、今回かなり見たかったところです。

エラー処理だけでなく、再処理まで行った

さらに後半になると、

まで進みます。

そして、

という再処理・訂正まで出ました。

最後には、

という受入条件まで。

ここまで来ると、

「要求を聞いて実装案を出すAI」ではなく、「要件定義で確認事項を洗い出すAI」

としてかなり使えそうです。

ただし、要求文だけでは出にくいものもある

こちらが事前に想定していた中で、明示的には出なかったものもあります。

例えば、

手動override。

通常のウェイトとは別に、

という運用が必要かどうか。

これは前回の架空As-Isでは存在していましたが、今回はAI側からは出ませんでした。

ただし、これは単純なAIの「見落とし」とは考えていません。

手動overrideのような機能は業務固有性が高く、今回の短い要求文だけから自力で発見するのは難しい類のものです。

むしろ今回の例から分かるのは、

要求文に現れていない業務固有の例外や暗黙知まで、AIが必ず発掘してくれるわけではない

ということです。

ここは人間側の業務知識が必要になります。

もう一つ問題がある

45個。

多い。

網羅性としてはありがたいのですが、このまま業務担当者へ、

と送ったら、たぶん嫌な顔をされます。

AI自身も最後に、

売上金額と日付
店舗所属
ウェイト
按分式
端数
出力grain
異常時処理
再処理
受入条件

という大きなテーマへ優先整理していました。

これは重要です。

質問をたくさん出せることと、効率よくヒアリングできることは別です。

次はローカルLLM

続いて、第0章から使用している、

Qwen3-Coder 30B

です。

ローカル環境は、

Model: qwen3-coder:30b
Radeon RX 7600 XT 16GB
RAM 32GB
Ollama
Context Window: 32768

です。

ClineからはOpenAI Compatible経由でローカルOllamaへ接続しています。

量子化方式については、今回の実験時には記録していなかったため、ここでは断定しません。

そしてクラウドと同じプロンプトを渡しました。

初回は、かなり短かった

初回回答で出てきた主な質問は、

ウェイトとは何か
入力データはCSVかAPIか
按分方法は何か
店舗とエリアの関係
売上0円・ウェイト0をどうするか

というもの。

方向性自体は間違っていません。

むしろ、

書いていない仕様を勝手に確定しなかった

という意味では、第1話より安定しています。

ただし、かなり足りません。

端数がない

特に大きかったのがこれです。

端数処理について質問がありません。

1000円を3店舗へ配るようなケースで、

333
333
333

にするのか、

334
333
333

にするのか。

そもそも四捨五入なのか。

元金額との一致を必須とするのか。

この辺りが全く出ませんでした。

grainも聞かない

入力形式について、

とは聞きました。

一方で、

は聞きませんでした。

個人的にはデータ基盤開発の場合、

CSVかAPIかより、grainの方を先に聞きたい。

もちろんCSV/APIという質問自体が不要なわけではありません。

ただ、CSVかAPIかは比較的インターフェース設計寄りの論点です。

一方、

日付×エリアなのか
日付×エリア×売上区分なのか

というgrainや、按分対象・計算ルールは、より業務要件そのものに近い。

今回の段階では、インターフェース方式を決める前に、まずデータの意味やgrain、按分ルールを固めたいところです。

つまり、

CSV/APIを聞くことが悪いのではなく、質問する順序・優先度の問題

だと思います。

質問の優先順位もちょっと気になる

初回では、

を優先度：高

としていました。

一方、

は優先度：低。

私なら、かなり逆寄りです。

1店舗が複数エリアへ所属できるなら、

• 按分対象

• 二重計上

• 出力grain

• 店舗単位で合算するか

• エリア別レコードを残すか

まで変わります。

一方、CSVかAPIかは重要ではありますが、

按分結果そのものの意味は変えません。

質問を出せるかだけでなく、

どの質問を先に聞くべきか

にも差がありそうです。

ただ、初回はGPUを別処理でも使っていた

ここで一つ、実験条件に気になる点がありました。

初回実行時、裏で別のGPU処理を動かしていました。

通常、GPUリソースの競合は主に処理速度へ影響すると考えられます。

ただ、比較記事として実験条件のノイズは減らしたかったので、別処理を止めた状態でもう一度だけ同じプロンプトを実行しました。

再実行すると、扱う論点が増えた

二回目の出力は、内容だけを比較すると初回より明らかに網羅的でした。

新たに、

などが出てきました。

論点を大きくまとめると、12テーマ程度まで広がっています。

ただし、ここで数字だけを比較するのは適切ではありません。

重要なのは件数そのものより、

どんな重要論点まで自力で到達したか

です。

「GPUを空けたら賢くなった」とは言えない

ここは注意が必要です。

初回も処理自体は正常終了しています。

そのため、

とは判断できません。

二回目の出力がより網羅的だったことは事実ですが、

それがGPU負荷の違いによるものなのか、LLM本来の生成の揺らぎなのかは今回の試行数では判断できません。

LLMの生成にはもともと揺らぎがあります。

今回は、

クラウドAI：1回
ローカルLLM：2回

だけを観察した実験です。

統計的な性能比較ではありません。

したがって今回確認できたのは、

少なくとも同じローカルモデル・同じ要求・同じプロンプトでも、出てくるQAの網羅性に幅があった

というところまでです。

再実行版でも、まだ拾われなかった論点はある

ローカル再実行版は、初回より多くの論点へ広がりました。

それでも、

• 入力grain

• 出力grain

• ウェイトの有効期間

• ウェイト未登録

• 負ウェイト

• ウェイト精度・許容範囲

• 売上負数・返品

• 総額一致を必須とするか

• 残額をどこへ寄せるか

• 再処理

• 訂正

• 受入条件

• 手動override

などは明示的には出ていません。

もちろん、一度の出力でこれらすべてが出なかったからといって、

という話ではありません。

今回観察できた範囲では、

要求文から基本的な確認事項を起こすことはできたが、より深い業務・データ設計上の論点まで広げるには人間側の補助が必要だった

という結果です。

質問自体にも少しズレがあった

例えば再実行版には、

という質問があります。

しかし要求文にはすでに、

と書いてあります。

もちろん、

を聞く意味はあります。

ただ、

まで戻る必要はあまりなさそうです。

また、

という質問もありました。

本当に確認したいのは店舗名より、

の方でしょう。

データ処理では、

表示名称の重複とデータ上の重複は別物です。

端数の質問でも、論点が少し混ざった

ローカル版には、

という質問があります。

でもこれは厳密には、

ウェイトは正規化する必要があるのか

と、

按分後に発生する金額端数をどうするのか

という別の問題です。

例えば、

weight = 6, 4

でも、

1000 × 6 / 10
1000 × 4 / 10

と正規化すれば按分できます。

一方、

1000 × 1 / 3

では、ウェイトが完全に妥当でも金額端数が発生します。

クラウド側はこの二つを別々の確認事項として扱っていました。

今回は、第1話とは違う差が出た

第1話では、

複数資料を正しく区別して扱えるか

を試しました。

そこではローカルLLMが、設計書の内容を実装にも存在すると誤認する場面がありました。

今回は資料を一つに限定しています。

すると、そのような情報源の混同はほぼ見られませんでした。

代わりに差が出たのが、

不足情報をどこまで自力で質問として発見できるか

です。

つまり第1話と第2話では、違う能力を試しています。

そして今回の一回・二回という少ない試行だけでモデル全体の優劣を決めるつもりもありません。

むしろ、

という点の方が重要に感じました。

AIに「質問させる」使い方はかなり有効そう

今回、特にクラウド側では、一文の要求から、

grain
店舗所属
ウェイト
端数
異常系
再処理
受入条件

まで論点を広げました。

要求定義の初期段階で、

状態から叩き台を作る用途なら、かなり有効そうです。

一方で今回見えた通り、質問が多ければ自動的に完璧というわけでもありません。

業務固有の暗黙知は要求文から出てこないことがあります。

重要度の付け方にも、人間とAIで差があります。

似た論点が混ざることもあります。

そして同じモデルでも、実行ごとに拾う論点が変わることがあります。

AIのQAは「完成品」ではなく「レビュー対象」

結局、ここもコードと同じでした。

AIにコードを書かせた。

人間がレビューする。

AIにテストを作らせた。

人間がレビューする。

そして今回。

AIに質問を作らせた。

その質問も、人間がレビューする。

AIに確認事項を出してもらうこと自体は、かなり役に立ちそうです。

でも、

とは考えない。

質問の網羅性。

優先順位。

似た質問の統合。

論点の分離。

そして、AIには見えない業務固有の暗黙知。

これらを人間側で確認して、初めて実際のヒアリングへ使えるQAになります。

次は45個をそのまま聞くのか？

クラウドAIは、個別質問として45個の確認事項を出しました。

でも、本当にその45個を全部、同じ優先度で業務担当者へ聞けばよいのでしょうか。

似た質問をまとめられるかもしれません。

今決める必要のないものもあるかもしれません。

逆に、AIが聞かなかった重要事項を人間側で追加する必要もあります。

そこで次は、

AIが作ったQAそのものを人間がレビューします。

必要な質問。

不要な質問。

まとめる質問。

追加する質問。

そして実際に回答を与え、要件を確定させていきます。

次回。

AIが出した45個の質問、本当に全部必要？ 人間がQAをレビューして要件を固める。