「部屋」はプロンプトできない — Balázs Horváth (Visual Labs) が説く、 AI 時代に最後まで残る要件定義のスキル

AI Engineer World's Fair 2026 (SF) / 約 16 分

バラージュ・ホルヴァート / Balázs Horváth · 03:00 「コードにもプロンプトできる。 AI にも、仕様書全体にもプロンプトできる。だが『部屋』にはプロンプトできない」

You Can't Prompt the Room: The Last Skill AI Won't Replace — Balázs Horváth, Visual Labs

AI Engineer World's Fair 2026 (SF) での Balázs Horváth 講演、約 16 分。話者の Balázs Horváth は、 13 年にわたりビジネスと IT・開発者の「橋渡し」をしてきた functional consultant (機能コンサルタント) 。 KPMG や HCL で米英の大規模 ERP / CRM 導入に携わった後、 2017 年に Microsoft Dynamics 365 を軸とするコンサルティング会社 Visual Labs を創業した。講演の主題は 1 つ —— コードを書くことがボトルネックでなくなった時代に、最後まで AI に奪われない技能は「部屋を読み、正しい要件を引き出す」分析の技術だ。

出発点は 1 つの実例だ。年初の社内ハッカソンで 21 のエージェント案を出し、そのうち 17 を破棄した —— データにアクセスできない、あるいは作る意味がなかったからだ。残った 4 つが、実際に大きな価値を生み、今の働き方を変えた。 5 つに 1 つも生き残らなかったこの比率が、「作る価値のあるものだけを作る」ことの重さを示す。コードへのアクセスと「作れること」は、もはや開発の律速ではない。本当のボトルネックは、ステークホルダーや意思決定者を「部屋」に集め、時間をかけて正しい要件を引き出すことに移った。

なぜ「作るだけ」では足りないのか。 Balázs は Henry Ford の逸話を引く。顧客に何が欲しいか尋ねれば「もっと速い馬」と答えただろう。だが Ford は車を作った。 AI は平均を返す —— AI は最もありふれた答えを返すよう作られているから、「より良く作る」ためだけに使うと、既にあるものを再生産してしまう。編集部の視点では、これは「速い馬を速く量産する装置」を、「車を発想する場」へ引き戻す仕事だと言える。

着眼点

ボトルネックは「何を作るか」に移った —— 部屋はプロンプトできない (00:00 - 04:03)

過去 2〜3 年の大きな転換は、コードを書けることが「最も重要な技能」ではなくなったことだ。コードにも、 AI にも、仕様書全体にもプロンプトできる。だが「部屋」 —— そこにいる人、利害関係者、意思決定者 —— にはプロンプトできない。律速は「正しいものを見極めること」へ移り、それは people skills、すなわち部屋を読み、要件を引き出す力に帰着する。「部屋を読み、正しい要件を引き出せれば、より価値あるソフトが作れる」。この一文が講演全体の背骨になっている。

アナリストの道具箱が新しい moat —— story mapping と 4 つの問い (04:03 - 11:05)

では何が重要な技能か。 Balázs は analyst toolkit (アナリストの道具箱) —— story mapping 、 business model canvas、 value canvas —— を挙げ、中でも story mapping を最も価値ある技能とする。サポート業務なら接触 → トリアージ → 解決 → クローズの backbone を引き、その下に user story を並べる。最初の 4 つ (意図の把握、緊急度の分類、根拠ある回答の下書き、記録システムへの登録) が MVP になる。

鍵は、 user story を AI に馴染む型で書くこと。 user story は「ペルソナ・what・need・why」の構造を持ち、 acceptance criteria を添えればテストケースを導ける。 AI はパターン認識が得意で、 user story の型を学習済みだから、馴染んだ型に戻すほど良い結果が返る。それを daisy chain のようにつなぐと、一貫したシステム → 仕様 → コードへ落ちる。併せて、システムに向き合う前に 4 つの問いを立て、リポジトリの markdown ファイルに残して AI に読ませる —— (1) これは誰の問題か (ペルソナを名指しし定量化)、 (2) その人にとって「勝ち」とは何か、 (3) 何があれば使うのを拒むか (プラットフォーム非対応・煩雑・データセキュリティ)、 (4) 意思決定を変えるか、変えるならどの決定か。

「build an agent that handles support」のように漠然と頼んでも、欲しい答えは返らない。だから Balázs のチームは常に VAD (Value Architecture Design) —— まず value (どう価値が生まれ、何が価値か)、次に architecture (それを支える業務プロセスと基盤)、最後に design —— の順で考える。「これは結局ただのプロダクトマネジメントでは?」という問いに、 Balázs は「ある程度はそうだ、古い商売だ」と認めつつ、だからこそ今それが moat になると言う。皆が同じ道具 (最新モデル) を持つ時代、差がつくのは「誰が business need をよりよく理解できるか」だけ。古い技能、だが新しい経済学。

「間違ったものを作る」兆候と、月曜からの実践 (11:05 - 15:44)

間違ったものを作っている兆候は分かりやすい。新機能を猛烈な velocity で出しているのに adoption が低い (誰もほとんど使わない)。デモが成果物になっている (デモは速くて見栄えするが、デモシステムは生きたシステムではない)。 PR に実ユーザーのテストがない。だから測るべきは滞在時間ではなく、特定の活動の「頻度」だ。そして全てを upstream へ動かす。 AI ブーム前は最も賢い人がコードを書いていたが、今はその人たちを顧客と業務課題の側へ動かす。「何を作るか」を決めることにこそ時間を使う —— そこが高価な部分で、作ること自体は安くなったからだ。

月曜からできることも具体的だ。まず「間違ったもの」を監査する —— いま何を追っているかを洗い出し、測定と時間を再調整する。 KPI は「先四半期に出荷した機能数」を消し、「2 回以上使われた機能数」に置き換える。経験ある subject matter expert を、実際に作るものへ影響を持てる顧客対応の役割へ動かす (全員がコンサルや PM になる必要はない、意思決定に加わればよい)。そして作る前に必ず mapping session をやる —— user story map でも business model canvas でも、価値がどこにあるかを可視化する。 Balázs 自身、 user story ありと無しで vibe コードした結果を比べて「まだ user story を開発に組み込む必要がある」と痛感したという。こうして「次のもの」ではなく「正しいもの」を作る。

動画の構成

(00:00) 「部屋はプロンプトできない」、コードは律速でなくなった
(00:35) 社内ハッカソン、 21 案中 17 を破棄・4 が価値を生んだ
(01:14) 13 年の経歴、ビジネスと IT の橋渡し、 Visual Labs 創業
(02:28) 本当のボトルネックは要件を引き出すこと
(03:05) Henry Ford の「速い馬」、 AI は平均を返す
(04:16) 重要な技能はアナリストの道具箱 (story mapping / canvas)
(04:39) story mapping —— backbone と user story、 MVP は最初の 4 つ
(05:48) 2 段目の user story はバックログ、対話を引き出す道具に
(06:50) AI に馴染む user story の型 (persona / what / need / why + acceptance criteria)
(07:44) SDLC は変わらない、変わるのは道具箱
(08:04) 4 つの問い (誰の問題 / 勝ち / 拒否理由 / 意思決定を変えるか)、 markdown に残す
(09:25) value から始める、 VAD (Value Architecture Design)
(10:28) 「これはプロダクトマネジメントでは?」古い技能・新しい経済学・新しい moat
(11:05) 間違ったものを作る兆候 —— velocity 高 adoption 低、 demo が成果物、実テスト無し
(12:40) upstream へ、最も賢い人を顧客側へ、「何を作るか」に時間を
(13:06) 月曜からの実践 —— 間違った指標の監査、 KPI 置換
(13:50) SME を顧客対応へ、意思決定に加える
(14:31) 作る前に mapping session、 user story あり/無しの比較
(15:33) 「次のもの」ではなく「正しいもの」を作る

関連リソース

バラージュ・ホルヴァート

Balázs Horváth

Visual Labs 創業 / 元 KPMG・HCL の機能コンサルタント — ビジネスと IT の橋渡し

用語集

「部屋をプロンプトできない」: AI・コード・仕様書にはプロンプトできても、意思決定者や利害関係者のいる「部屋」には指示を出せない、という本講演の中心命題。コードを書くことが律速でなくなった今、律速は「正しいものを見極めること」 = 部屋を読み要件を引き出す people skills に移った。
AI は平均を返す (Henry Ford の「速い馬」): AI は定義上、最もありふれた答えを返すよう学習されている。顧客に聞けば「もっと速い馬」と答えるが、 Ford は車を作った。「より良く作る」ためだけに AI を使うと既存のものを再生産する。仕事は AI を平均から引き離し、桁違いに良いものを作らせること。
analyst toolkit (アナリストの道具箱): story mapping、 business model canvas、 value canvas、 design thinking など、機能コンサルタントやビジネスアナリストが使ってきた「古い道具」。 Balázs はこれが AI 時代の新しい moat (堀) になると論じる。古い技能、新しい経済学。
story mapping: ユーザーの行動を段階 (backbone) に分け、その下に user story を並べて全体像を捉える手法。例: サポート業務なら接触 → トリアージ → 解決 → クローズ。高い視座を保ったまま、何を作る・リリースするかを決められる。最初の数個が MVP になる。
user story: 「ペルソナ (誰が) / what (何を) / need (必要) / why (なぜ)」の構造で要件を書く定型。 acceptance criteria (受け入れ基準) を添えるとテストケースを導ける。よく知られた型のため AI が学習済みで、同じ型で渡すとパターン認識が効いて結果が良くなる。
4 つの問い: 作る前に立てる問い —— (1) これは誰の問題か (ペルソナを名指し・定量化)、 (2) その人にとって「勝ち」とは何か、 (3) 何があれば使うのを拒むか、 (4) 意思決定を変えるか。リポジトリの markdown に残して AI に読ませると、より多くの文脈が引き出せる。
VAD (Value Architecture Design): Balázs のチームの思考プロセス。まず value (どう価値が生まれ、何が価値か)、次に architecture (その価値と業務プロセスを支える基盤)、最後に design (システム設計) の順で考える。「漠然とエージェントを作れ」では欲しい答えは返らない、への処方箋。
間違ったものを作る兆候: 高い velocity で機能を出しているのに adoption が低い / デモが成果物になっている (デモは生きたシステムではない) / PR に実ユーザーのテストがない。測るべきは滞在時間ではなく活動の頻度。 KPI は「出荷した機能数」ではなく「2 回以上使われた機能数」。
upstream へ動かす: AI ブーム前は最も賢い人がコードを書いていたが、今はその人たちを顧客と業務課題の側へ動かす。「何を作るか」を決めるところに時間を使う —— そこが高価な部分で、作ること自体は安くなった。