指示が曖昧なぶんだけ、
誰の作品でもなくなる

以前は、曖昧なまま始めても大丈夫だった

人が実装していた頃、曖昧な仕様はそれほど怖くありませんでした。 書き始めれば手が止まるからです。「ここ、どうするんだっけ」で作業が物理的に止まり、 そこで考え直す機会が来る。実装の遅さが、暗黙の検問所になっていました。

見積もりも同じです。3日かかると分かっていれば、始める前に few 回は考え直します。 コストが高いこと自体が、企画を選別していた。

実装が遅いあいだは、遅さが品質保証の一部でした。

止まらなくなった

AIエージェントは、曖昧な指示でも止まりません。行間を埋め、それらしいものを完成まで持っていきます。 速さは本物です。しかし同時に、考え直す機会だった「詰まり」が消えました。

結果として現れる失敗は、バグではありません。整合はしているが、作りたかったものではないという失敗です。 しかも動くので、間違いだと気づくのが遅れます。

最後の行が厄介です。1時間で完成品が出てくると、方向が違っていても捨てにくくなる。 速さは、判断を歪める方向にも働きます。

質問を、工程として前に置く

答えは単純で、実装の前に、質問で解像度を上げる工程を明示的に置くことでした。 私は Claude Code の superpowers にある brainstorming の型を使っています。 要点は3つです。

1. 規模を先に宣言する

すべての依頼に重い手続きを課すと、誰も守らなくなります。だから最初に、 この依頼はどの重さかを宣言してから始める。

迷ったら重い方を選ぶ。そして途中で複雑さが見つかったら、その場で格上げして宣言し直します（逆はしない）。

2. 質問は一度に一つだけ

まとめて5つ聞かれると、人は雑に答えます。1問ずつ出すと、答えるうちに自分でも決まっていなかったことに気づく。 質問の本当の目的は情報収集ではなく、依頼者に決めさせることです。

3. 承認の門は、規模で軽くならない

ここが最も効きました。設計の分量は依頼の大きさに比例して変わるが、承認そのものは省略しない。 2文の設計でも「これでいい」と言われるまで着手しない。

「単純すぎて確認は要らない」と思った時が、いちばん危ない。
単純な依頼ほど、前提が検証されないまま進みます。

速さの代わりに失った検問を、置き直す

実装が止まらなくなったぶん、止まる場所を人工的に作ります。私が常用しているのは4つです。

検問1: 完了を「観測」で定義する

「終わった」を主観で言わせない。コマンドの出力で示すと決めておきます。

検問2: 変更行を、依頼にたどれるようにする

エージェントは親切なので、頼んでいない改善を混ぜてきます。悪意はありませんが、 レビュー範囲が膨らみ、事故の温床になります。 「変更した行はすべて依頼にトレースできること」を規約にしておくと、これが止まります。

検問3: 壊れ方を先に想像させる

設計の段階で「この設計で破綻する場面を挙げて」と一度聞きます。費用対効果が最も高い質問です。 実際、多言語化のフォールバックが未デプロイを隠す問題は、この問いを飛ばしたときに起きました。

検問4: 妥協した版をそのまま残さない

ツールが動かないとき、エージェントは「動く範囲で作った版」を完成品のように提示することがあります。 悪意ではなく、指示を満たそうとした結果です。 「品質を落とした版を成果として出さない」「方針転換したなら、したと言う」を明示しておく必要があります。

実際に使っている順番

1. 規模を宣言する（調べる / 限定 / 構造）。迷ったら重い方
2. 1問ずつ質問する。目的は情報でなく、依頼者に決めさせること
3. 案を2〜3個出して比較する。1案だけだと「他になかったのか」が残る
4. 設計を提示して、承認を待つ。分量は変えていいが、門は省かない
5. 完了の観測方法を、着手前に決める
6. 作る
7. ライブの成果物で検証する。手元の作業コピーはいちばん信用できない

人間が決めることは、実は少ない

創作なら5つだけです。読後感 / 主人公の芯 / 世界の圧力 / 中心の関係 / 着地と規模。 この5つが埋まっていれば、残りは整合性の問題なので任せられます。 逆に、ここが曖昧なまま任せると、整合はしているが誰の記憶にも残らないものが返ってきます。

AIに任せられないのは、実装ではありません。何を作るかを決めることと、 できたものが違うと認めることの2つだけです。

静かに壊れる不具合の捕まえ方は 品質検問 に、 他の型は 新しい形の研究 に置いています。