AIで作れない人の正体は『言語化不足』ではない：もう一段深い断層、『曖昧さを構造化する力』の不在について
前回記事「AIが使えない人の思考構造：差を生むのは言語化力の有無である」への、自分自身からの宿題を返しに来た。あの記事を読んだ人の中には、こんな問いを持った人がいるはずだ。「言葉にはできている。なのに、AIにシステムを作らせると思った通りに動かない」。その断層は言語化の精度ではなく、もう一段深いところにある。
言語化力の先にある断層
前回記事の主張を一文で要約すれば、こうなる。AIは思考を増幅するツールであり、言語化できない思考は増幅されない。だからAI活用の格差は、ツールの習熟度ではなく言語化力によって生まれる。この主張は今も正しいと思っている。
だがシステム開発という文脈に入った瞬間、言語化できていても詰まる人の存在が浮かび上がる。彼らに足りないのは言語化力ではない。「何を言語化すべきか」を発見・分解する力だ。
前者は言語化力。後者を——タイトルで「曖昧さを構造化する力」と表現したものを——本記事では要件分解力と呼ぶ。言語化力の最高形態がこの要件分解力であり、前回記事はその一歩手前まで論じた。本記事はその先を掘る。
曖昧さを構造化するとはどういうことか
「在庫管理画面が欲しい」という依頼を受けたとする。言語化力がある人は、この依頼をそのままAIに渡さない。しかし要件分解力がある人とそうでない人の間には、さらに大きな溝がある。
要件分解力を持つ人がまず問うのは、誰が・どんな状況で・何の判断のために使うかという要件の層だ。「倉庫担当者が、補充発注のタイミングを判断するために、毎朝確認する」という一文が出てくれば、それは要件として機能している。
次に仕様の層。「どの粒度のデータを、どんな操作で、どの順序で見るか」に答える。「品目別の現在庫数・7日間の平均出荷数・推奨発注量を一覧で見て、チェックボックスで発注対象を選択できる」という記述が仕様だ。
さらに詳細の層。「在庫数がゼロの品目はどう表示するか」「権限のないユーザーが発注ボタンを押したらどうなるか」「同時に2人が編集した場合どちらが優先されるか」——こうした例外条件・境界条件を事前に列挙する能力が問われる。
この三段を踏んだうえで、もうひとつ別軸の能力が必要になる。AIが出力した画面を見て「これは違う、ここを直せ」と言える評価・フィードバック能力だ。「なんか違う」ではなく「在庫ゼロの品目が警告色で表示されていないのはなぜか。仕様書の3条件を満たしていない」と言える人は、正解のイメージ——つまり完結した要件——を事前に持っている。要件がなければ評価はできない。評価できなければ、AIは正しい方向に走り続けることができない。
開発プロジェクトにおける手戻り工数の70〜85%は要件の間違いに起因する——Karl Wiegers & Joy Beattyが『Software Requirements 3rd ed.』（2013）で示した数値であり、AI時代の要件定義について考えるでも引用されている（調査によって数値には幅がある点を付記する）。この数字はAI以前の世界のものだが、示す構造は変わらない。むしろAIが「それっぽい出力」を高速で返すぶん、要件の欠陥が出力の不一致として即座に顕在化するようになった。
「察してくれるエンジニア」依存症の正体
なぜシステム担当者ほど、この要件分解力が育ちにくかったのか。ひとつの産業史的な仮説を提示しておきたい。
外部委託中心の開発スタイルが定着した日本の大企業環境では、事業会社側の担当者が曖昧な要求を出しても、受け取ったエンジニアが「察して」構造化してきた歴史がある。あの時代の有能なSEは、要件の行間を読む達人だった。「なんとなくこんな感じで」という依頼を、数回のヒアリングで実装可能な仕様に変換する力を持っていた。
問題はそのプロセスが事業会社側に可視化されなかったことだ。担当者の眼には「言ったら作ってくれた」としか映らない。要件を構造化する工程は、受託側のバックルームで静かに行われ、請求書には「設計費」という名前で折り込まれていた。
さらに言えば、人月型の受託開発モデルには構造的な傾向がある。「優秀なエンジニアが短期間で終える」より「複数人が時間をかける」方が売上が大きくなりやすい。曖昧な要件はスコープ変更を生み、スコープ変更は追加発注を生む。要件をできる限り明確にしてから着手するインセンティブが、受注側に必ずしも強く働かない構造的な傾向があった。（参考：SIの本質と人月商売の構造）
多重下請け構造のもとでは、技術的な知見や設計思想が事業会社側に蓄積されにくい傾向がある。プロジェクト終了後に成果物と仕様書は引き渡されるが、それを活用・保守するための技術的文脈は共有されないことが多い。（参考：ニアショアと多重下請け：IT品質の構造問題）
ただし、これは蓋然性の高い仮説として読んでほしい。外部委託歴が長い企業ほどAI活用が失敗する、という直接の実証データは存在しない。そもそもAIプロジェクトの失敗は日本固有の問題でもない。Gartnerが2024年に公表した予測（対象：2025年末時点）では、生成AIプロジェクトの少なくとも30%がPoC後に放棄されるとされていた。複合的な要因として「データ品質の問題、リスク管理の不十分さ、コストの増加、不明確なビジネス価値」が挙げられている。（出典：Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025）
外部委託の多い開発文化はその失敗を増幅しやすい装置として機能する——というのが筆者の見立てだ。
AIは「地図なしに全力疾走する部下」である
「AIは忖度しない」という言い方をされることがある。しかし、これは正確ではない。2026年時点のモデル——Claude、GPT-4o、Gemini——は、曖昧な指示に対して止まるのではなく、最もらしい解釈で全力疾走する。
方向が合っていればこれほど頼もしい部下はいない。問題は、方向が違っていても止まらないことだ。「在庫管理画面」と言えば、AIは自分なりに解釈した画面を高速で出力する。それがマーケティング担当向けのダッシュボードでも、倉庫担当者には使えない5タブ構成でも、「作った」ことには変わりない。そして「なんか違う」という感想と共に、やり直しのサイクルが始まる。
これまで日本企業の現場が黙って埋めてきた隙間——要件の構造化という工程——を、AIは埋めない。正確に言えば、埋めようとはするが、その埋め方が正しいかどうかを確認する手段を持っていない。正確な指示書がないまま走り出したAIは、目的地に近そうな場所をそれらしく提示するだけだ。
あなたが渡す地図の解像度が高いほど、AIはその力を正確な方向に向けることができる。
「AIが賢くなれば解決する」論への相対化
よくある反論がある。「AIが賢くなれば、曖昧な指示でも補完してくれるようになる」というものだ。この主張は半分正しく、半分誤解を含む。
補完できる範囲は確実に広がる。これは認めるべき事実だ。要件工学（Requirements Engineering）の分野でLLMを活用する研究（LLM4RE）は急速に拡大している。74件の一次研究を分析した体系的文献レビューによると、2024年は2023年比136%増となった。NLP4RE（自然言語処理を要件工学に適用した研究群）が1983〜2019年の約40年間で蓄積した404本の約20%に相当する規模に、わずか2年で達している。
- LLMs for Requirements Engineering: A Systematic Review
AIが要件抽出インタビューを自動化するLLMREIの研究では、短いプロンプト設計を用いた条件で、最大73.7%（完全抽出60.94%＋部分抽出12.76%）の要件を抽出した。ミスの数は要件インタビューの訓練を受けた学生インタビュアー（18名）と同等だった、と報告されている。
- LLMREI: 要件抽出インタビュー自動化システムの研究
2026年1月にarxivへ投稿されたREpromptフレームワークは、要件工学の4段階（抽出・分析・仕様化・検証）をプロンプト最適化に組み込む手法を提案している。人間評価で7点満点中ユーザー満足度5.75・ユーザビリティ5.42を達成したと報告されている（ベースラインとの比較詳細は論文を参照されたい）。この研究が「プロンプトをソフトウェア要件の一形態と見なす」という中心概念を提示している点は、要件分解とプロンプト設計が本質的に同じ問いに答えることを示唆している。
- REprompt: 要件工学ガイドのプロンプト生成フレームワーク
しかし、Cambridge Core（2024）の論文は率直にこう結論する。「現状の最良のLLMベースNLPツールの性能はprecision・recallともに完全ではない。人間の専門家によるモデル訓練・検証・予測の受容可否の判断が依然不可欠だ」と。
- Challenges in Applying Large Language Models to Requirements Engineering Tasks
AIによる要件補完の範囲は広がる。しかし「何を作るべきか」を選び、判断し、出力の受容可否を決定する責任は人間に残り続ける。そして補完が効く範囲が広がっても、要件分解力を持つ人と持たない人の相対的な差は縮まらない。全体水準が上がれば、使いこなせる人間のアウトプットの質も同時に上がる。割合は変わらない。
あなたは今、どこで詰まっているか：5問の診断
要件分解力の現在地を確認するための問いを5つ用意した。
個人軸（3問）
1. ある業務依頼を、要件・仕様・詳細の3段に分けて書き下せるか 2. その業務の例外条件・境界条件を、自力で5つ以上列挙できるか 3. AIの出力を見て「これは違う、具体的にここが問題だ」と言えるか
組織軸（2問）
4. 要件が曖昧な状態で上位者に「定義してから着手したい」と言えるか 5. プロジェクト開始前に、要件定義フェーズの工数が組織として確保されているか
3は「正解のイメージを持っているか」の問いだ。4と5は、組織がその要件分解行為を「許しているか」の問いだ。スキルがあっても行使できない組織では、AIを使いこなす担当者は育たない。問いかけが通らない組織は、処方箋の前に文化の診断が必要になる。
処方箋は三階建てで考える
個人レベル：要件分解の練習
まず、既存のシステムを逆分解する習慣から始めるのが現実的だ。自分が普段使うツールを「これはどんな要件から作られたか」と言語化してみる。たとえば、メールの受信トレイの仕様書を自分で書くとしたら何が要件になるか——この問いを立てるだけで、要件分解の筋肉が動き始める。
次に、AIへの依頼文を書く前に「例外条件を3つ以上書く」ルールを自分に課す。「ユーザーがログインしていない場合」「データが存在しない場合」「同時アクセスが重複した場合」——こうした条件を先に書く癖は、要件の欠落を事前に発見するフィルターになる。
ただし正直に言えば、要件分解力の相当部分は暗黙知（タシット・ナレッジ）から成る。外科医の判断や熟練交渉者の直感と同様、失敗経験の蓄積から生まれる暗黙知は、練習法で完全に体系化できるものではない。短期で習得できるスキルではなく、継続的な実践と内省の積み重ねが前提になる。規模が小さく反復可能な領域では、探索的な試行錯誤から始める開発スタイルが機能する場合もあることを付け加えておく。
組織レベル：要件構造化を制度化する
個人の努力に依存する組織は脆い。Amazonの「6ページャー」やGoogleの「Design Doc」は、要件分解を個人スキルではなく組織的な装置として制度化した例だ。会議の冒頭でホワイトボードを前に「どんな機能が欲しいですか？」と問い始めることを禁じ、事前の文書化を強制する仕組みは、曖昧さのまま着手することを構造的に防ぐ。
JUAS「企業IT動向調査2025」では、IT部門が今後担うべき役割として「ビジネスプロセスの抜本的な改革提案」や「組織横断的な活動推進（PMO等）」への回答が増加傾向にある。PMO機能の整備と、外部委託契約において要件定義フェーズを発注側の責任として明示することが、組織レベルの処方箋になる。
業界・産業レベル：人材育成投資の構造転換
IPA資料が引用するリクルートワークス研究所「Global Career Survey 2024」（7か国調査）によれば、日本のOJT実施率は7か国中最下位だ。
東京商工リサーチの2025年調査では、生成AI非活用の主因として「推進するための専門人材がいない」が55.1%、「活用する利点・欠点を評価できない」が43.8%に上る。
「専門人材がいない」という声の裏には、要件分解力を持った人材を育ててこなかった積み重ねがある。この問題を個人の自助努力だけに帰属させることには無理がある。複雑なビジネス要件を持つシステム開発においては、要件分解のプロセスを組織として制度化することが、人材育成の実効的なルートになる。
むすびに
AIがコードを書く時代になっても、「何を作るべきか」を選び、腹を括り、うまくいかなければ別の手を打つのは人間の仕事だ。AI時代の要件定義について考えるはそう指摘する。
要件分解力は「作る」能力ではなく、「何を作るかを決める」能力だ。そしてこの能力は、これまでSIerや優秀なエンジニアが代わりに行使してきた。その代行が消え、AIという新しい実行者が登場した今、その空洞が初めて可視化されている。
前回記事「AIが使えない人の思考構造」で論じた言語化力は、この要件分解力の土台だ。「国数理社こそ最強のAI活用スキル」で論じた基礎学力は、要件を論理的に分解するための思考OSになる。「コミュ力偏重社会が招いた天才の大量廃棄」で論じたように、PMスキル（要件分解力）は日本の採用基準にほとんど含まれてこなかった——そのツケが、AI時代に一気に回収されようとしている。「死ぬまでレバーを押す消費者か、世界を創る生産者か」の問いと地続きの話でもある。要件を定義できる人間が「生産者」として残り、できない人間がAIの出力を眺めるだけの「消費者」になっていく構図は、すでに始まっている。
問いは残る。あなたの組織は、その空洞に気づいているか。
