AI時代のプロダクトマネージャー 05|曖昧に伝えると、AI が勝手に埋めてしまう
あなたは AI に「ログイン機能を作って」と言う。
AI はそれを作り上げてくれる。だがあなたのその一言とそのコードのあいだで、AI はあなたがまったく触れていない一連の決定を、あなたの代わりに下している――メールか電話番号か、認証コードを要るか要らないか、パスワードを何回間違えたらアカウントをロックするか、どれくらいの時間ロックするか、エラーメッセージは「パスワードが違います」と書くのか「アカウントまたはパスワードが違います」と書くのか、「ログイン状態を保持する」を付けるか、ログイン状態をどれだけ保持するか。この十数個の決定のうち、あなたが決めたものは一つもない。すべて AI があなたの代わりに推測したものだ。
問題は、AI の推測が当たっているかどうかではない。AI がそもそもあなたに聞かない、という点にある。同じ仕事を人が引き受けたなら、彼はこう聞き返すだろう。「このログインって、電話番号ですか、メールですか?」AI は聞かない。AI は yes-machine なのだ――あなたが言ったことはやるが、あなたが思っていることはやらない。要求の中で触れられていない箇所は、学習の中でいちばん多く見たデフォルトで埋めてしまう――バリデーションのルール、有効期限のロジック、エラー時の挙動、すべてあなたの代わりに一つ補ってくれる。多くの場合、それはあなたの欲しかったものではない。
OpenAI の Sean Grove はこう言った。あなたが書くコードはあなたの価値の 10% から 20% を占めるにすぎず、残りの 80% から 90% は、作るべきものをはっきり語ることだ、と。AI が「作り上げる」というこの一歩を丸ごと引き受けたとき、あなたの仕事は前半のその 80%――要求を曖昧さがなくなるまで語ること――だけになる。以下は、そのまま真似できる四つの動作だ。
一、形容詞を数字に変える
「もっと速く」「もっとシンプルに」「もっと目立つように」「体験を良く」――こうした言葉を AI は検証できず、自分で一つ定義するしかない。ある人が AI に「システムは過負荷に対して素早く応答すること」と書いたところ、AI はこの一条をそのまま「検証不能」と印を付けた。測れる閾値が一つもないからだ。「素早く」とはどれくらい速いのか?
形容詞を数字に変えれば、曖昧さは消える。「読み込みは速く」は「ファーストビューを 1.5 秒以内に出す」と書く。「リストは長すぎないように」は「一画面に最大 8 件、それ以上はページ送り」と書く。「ボタンは目立つように」は「メインカラーのボタン、背景とのコントラストははっきり見える程度」と書く。数字やルールに書けるものは、形容詞のまま残さない。
二、状態をすべて書き切る
doaipm はずっと、本物の四つの状態を強調している――読み込み中、空、エラー、成功。あなたが「注文リストを作って」とだけ言えば、AI はデフォルトで成功状態を作る――データがあり、ネットワークが良好で、すべてが正常な状態だ。
注文リスト: 読み込み中はスケルトンスクリーンを表示する。注文が一件もないときは「まだ注文はありません」と注文への導線を一つ表示する。リクエストが失敗したときは「読み込みに失敗しました。タップして再試行」を表示する。正常時は各行に注文番号、金額、ステータスを表示する。
空のリストはどう見えるのか、読み込み中にユーザーに何を見せるのか、失敗したらどう知らせるのか――この三つをあなたが書かなければ、AI はやらないか、適当に一つ補ってくるかのどちらかだ。本物のプロダクトでユーザーが空とエラーに行き当たる確率は、あなたが思うよりずっと高い。
三、エッジケースを並べ出す
いちばん省きやすく、いちばん事故を起こしやすいのが異常系のパスだ。AI が曖昧な要求に対して前提を補うときの研究では、AI がもっとも多く補っていたのが、まさにこれらだった――データが期限切れになったらどうするか、権限のない人がアクセスしたらどうするか、二人が同時に同じ一件を操作したらどうするか、タイムアウトしたらどうするか。
クーポンを作るなら、こうしたことをはっきり語らなければならない――クーポンが期限切れのときユーザーが「使う」を押したら何を出すか、同じ一枚のクーポンを二台の端末で同時に注文したらどちらのものになるか、ユーザーがクーポンを半分使った状態で返金したらクーポンは戻るのか戻らないのか。あなたが並べなければ、AI はそれぞれに一つずつ前提を立ててしまい、本番で問題が起きてはじめて、AI が当初どう推測していたかにあなたは気づく。
四、書き終えたら、前提ゼロのテストで自己点検する
ある要求が十分にはっきりしているかどうかを判断する、出来合いの物差しがある――それを、このプロジェクトをまったく知らない人に渡して、彼があなたの頭の中とそっくり同じものを、それを見ながら作り上げられるか? もし二人が読み終えて二通りに理解するなら、それはまだ十分にはっきりしていない。続けて分解し、曖昧さがなくなるまで分解する。
面倒なら、もっと手間のかからない方法もある――AI にまだ手を動かさせず、あなたの代わりに補おうとしている前提を一条ずつ並べて見せてもらうのだ。AI が並べた「クーポンは全店共通だとデフォルトしました」「有効期限は 7 日だと仮定しました」こそが、あなたがさっき語り切れていなかった箇所だ。AI がまだ作っていないうちに、これらを塞いでおく。
今日できることが一つある。あなたがちょうど AI に投げようとしている要求を一つ選び、まだ送らずに、「形容詞を数字に、状態をすべて書き切る、エッジケースを並べ出す」で一度通してから送る。そして比べてみてほしい――この版の産出と、何気なく送ったあの版とで、どれだけ差があるかを。
関連記事
- Sean Grove(OpenAI)『The New Code』:spec はあなたの 80〜90% の価値が宿るところ — https://www.youtube.com/watch?v=8rABwKRsec4
- Improve & Repeat『Why Requirements Matter So Much for AI Coding Agents』(AI が曖昧な要求に前提を補うリスト):https://improveandrepeat.com/2026/04/why-requirements-matter-so-much-for-ai-coding-agents/
- 本シリーズ第03回『AIを「道具」ではなく「同僚」として扱う』:/ja/blog/ai-as-colleague/
- 本シリーズ第04回『「作るべきか」の判断が、初めて「作れるか」より高くつく』:/ja/blog/judgment-over-feasibility/
ディスカッション