『わからない』を言える設計 — 推測で進めないという規律

🧭推測で埋めた1ミリが、あとで1メートルになる

あいまいな前提を仮で埋めて進むと、外れた瞬間に積み上げた全部が崩れる。だから進む前に、いったん止まる。

不明点を「たぶんこうだろう」で埋めて先へ進む。すると、その仮定が土台になって、次の作業がその上に積み上がっていきます。

仮定が外れていたと気づくのは、たいてい成果物ができあがってから。そのとき戻すのは、1ミリの判断ではありません。その上に積んだ全部です。

当社でも、指示のあいまいな部分を AI が善意で補い、意図とずれた方向に丁寧に作り込んでいた、という失敗を何度かやりました。皮肉なもので、作り込みが丁寧なぶん、修正コストはむしろ大きくなる。

だからこそ、進む前の「わからない」を歓迎する設計にしたかったのです。

📌ルールとして明文化する

『不明点は推測で進めず確認する』を運営ルールに一行で明記し、気合いではなく文書に従わせている。

当社の運営ルールを書いた communication.md には、基本原則として「不明点は推測で進めず、社長に確認する」と、たった1行で明記してあります。

気持ちの問題にしない。参照できる文書に落とす。ここがポイントです。人間も AI も、疲れているときほど、気合いより文章に従うからです。

あわせて、報告フォーマットは PREP 法（結論→理由→具体例→結論）で固定しています。確認を求めるときも、「何がわからないか」を結論から書く。

これで「なんとなく不安」が、「この軸が決められない」という形に変わる。問いが、ちゃんと構造を持つのです。

🚦確認を仰ぐのは「判断できない軸名を明記できたとき」だけ

確認は無制限に許さない。可逆性・外部到達・金銭/法的の三軸で、未確定の軸名を言えたときだけ承認を仰ぐ。

正直に言うと、はじめは「確認するほど丁寧でいい」と思っていました。でも、これを無制限に許すと、今度は何でもかんでも人間に投げる、別の非効率が生まれます。

そこで当社は、承認の判定軸を、可逆性 × 外部到達 × 金銭/法的の3軸に整理しました（ADR-015）。以前の「迷ったら、とりあえず上位承認へ」は、廃止しています。

では、いま何を基準に止まるのか。

3軸のうち、確定できない軸の名前を明記できたときだけ、事前承認を仰ぐ。逆に、可逆か・外部に届くか・金銭や法的の縛りがあるか、を自分で確定できたなら、「なんか重そうだから」で止めない。

「わからない」を、感情のままにせず、「どの軸が未確定か」という具体語に翻訳させる。それだけの規律です。

🔍「わからない」の最頻出は、状態を推測したとき

いちばん多い推測は仕様ではなく「今どうなっているか」。状態は語る前に、必ずライブで実測する。

実運用でいちばん多かった推測は、意外にも仕様の話ではありませんでした。「今どうなっているか」の推測です。

「あの PR はマージ済みのはず」「デプロイは反映されているはず」——文書に書いてあることを、現在の状態と取り違える。この静かなズレが、いちばん多かった。

当社の common-mistakes.md では、これを「文書＝計画、live＝状態」という言い方で戒めています。状態を報告する前に、必ず1つ以上ライブで実測する。

gh pr view で本当にマージされているか。curl で本番がちゃんと返しているか。「実測したことがある」は「実測した」ではない、という一文まで書いてある。

わかったふりの、いちばん静かな形。それは「過去の記憶を、現在として語ること」でした。ここで何度も痛い目を見たので、文章に刻みました。

ただ、文章だけでは人も AI も忘れます。だから当社では、状態を断定する前に実測した形跡があるかを機械的に点検する仕組み（フック）まで足しました。気合いに頼らず、規律を仕組みへ逃がす。ここでも発想は同じです。

🤖AIにこそ効く規律

言語モデルは空欄を上手に埋める。だからこそ『わからないと言え』を設計に組み込む価値は、人間より AI で大きい。

言語モデルは、空欄をもっともらしく埋めるのが、とても得意です。これは長所であると同時に、確認すべき場面でも自信ありげに補ってしまう、短所にもなる。

だから「わからないと言ってよい」「むしろ言え」を、明示的に設計へ組み込む価値は、人間よりも AI のほうが大きい。私はそう感じています。

Anthropic 自身も、モデルに検証や自己点検のステップを踏ませる設計を推奨しています（Anthropic 公式ドキュメント）。当社の「推測で進めない」も、根っこは同じ。答えを出す前に一拍おいて、根拠を確かめさせる仕組みづくりです。

🧩まとめ — 立ち止まれる設計が速さを生む

「わからない」と言えるのは弱さではなく設計の成熟。立ち止まれる仕組みがあるほうが、結局は速い。

「わからない」を言えることは、能力の低さではありません。設計の成熟だと、私は思っています。

推測で進めない・不明点は確認する、を文書に落とす。確認は「未確定の軸名を言えたときだけ」に絞る。状態は、必ず実測する。

この3点で、当社は手戻りの体感が目に見えて軽くなりました。立ち止まれる仕組みがあるほうが、結局は速い。一人会社の小さな実感ですが、規模が変わっても効く規律だと考えています。

あなたのチームでは、「わからない」を、ちゃんと口に出せる設計になっていますか。