体験へ移動
assaynotes

02 / 検証

数字は​正しい⁠。 問いが​違う⁠。

答えが​出る速さに⁠、​確かめる​速さが​追いつかない⁠。​もっともらしい​数字ほど⁠、​誤りに​気づきにくい⁠。​何を​基準に​確かめたのかを⁠、​答えと​一緒に​示す⁠。

自分で確かめる設計の考え方を見る

正しいと、言えること。

操作して確かめる架空の事例
02 / 検証

スクロールで進み、操作で確かめる。

問いを​読み⁠、 答えを​確かめる⁠。

営業部長は、​短納期の​大口案件を​受けるかどうか​決める​前に、​データ問答エージェントに​聞く。​先月の​納期遵守率は？ エージェントは​94%と​答える。​同じ問いは​前にも​一度ずれ、​その​修正は​記憶に​残っている。​この​答えを​使えるかどうか、​確かめるのはあなただ。

  1. 02計算を​確かめる​：​答えと​同じ定義で、​注文100件を​数え直す。
  2. 03定義を​確かめる​：​記憶にある​修正と​照らし​合わせる。
  3. 04二つの​定義で​数え、​答えを​書き直す。
  4. 05受けるかどうかは​人が​決め、​判断を​記録に​残す。

どの​手順も、​あなたが​押すまで​進まない。​前の​手順が​済むと、​次が​開く。

架空の​事例注文も​人物も​数字も、​設計の​仕組みを​示すために​作ったものだ。​実在の​顧客データではなく、​効率改善の​実測でもない。​この​ページで​動いている​AIもない。

01同じ問いに、​また​94%。

翌週、​別の​大口案件で、​同じ問いが​来た。​エージェントは、​また​94%と​答えた。​記憶には​前回の​修正が​残っている。​それでも、​答えがそれに​従っているとは​限らない。

決める​前に、​二つを​分けて​確かめる。​計算は​合っているか。​問いに​答えているか。

02計算は、​合っているか。

先月の​注文100件を、​答えと​同じ定義で​数え直す。

03問いに、​答えているか。

答えが​使った​定義を、​記憶にある​修正と​照らし​合わせる。

計算をまだ​確かめていない。 先に​確かめる

04二つの​定義で、​数える。

同じ​100件を、​工場の​回答日と​客先の​希望日の​両方で​数える。

計算をまだ​確かめていない。 先に​確かめる

05受けるかどうかは、​人が​決める。

答えは、​定義と​根拠を​添えて​営業部長に​渡る。​短納期の​大口案件を、​受けるか。

計算をまだ​確かめていない。 先に​確かめる

計算が​合っていることと⁠、 問いに​答えたことは⁠、​違う⁠。

設計原則

確かめることを、​二つに​分ける。​計算が​合っているか。​問いが​求める​定義で​答えているか。​定義が​分からないときは、​分からないと​答える。​決めるのは​人で、​その​判断も​記録に​残す。

何が​変わったか

答えは​94%から​79%に​変わった。​それでも、​計算は​一度も​間違っていない。​変わったのは​定義だ。​同じ​100件を、​工場の​回答日ではなく​客先の​希望日で​数えると、​15件の​判定が​変わる。

なぜ重要か

定義を​誤った​答えも、​正しい​答えと​同じくらい​確かに​見える。​数字は​精密で、​計算も​確かめられる。​計算だけを​確かめれば、​そのまま​通ってしまう。​そして​受注の​判断は、​その​数字の​上に​下される。

ほかの​判断にどう​生かすか

AIが​出す数字には、​二つを​分けて​問う。​計算は​合っているか。​この​問いに​答えているか。​定義が​曖昧なら、​曖昧だと​言う。​考えられる​定義とそれぞれの​結果を​並べ、​問いを​出した​人に​選んでもらう。

同じずれは、​どこにでもある。​「アクティブユーザー」は​ログインで​数えるか、​操作で​数えるか。​「売上」に​返金を​含めるか。​「納期どおり」は、​どの​日付で​決まるか。

この​答えは⁠、 何に​支えられているか⁠。

上の​手順に​合わせて​更新される。​確かめたものは​証拠に、​確かめずに​成り立つとしたものは​仮定に、​この​データでは​答えられないものは​未知に​入る。

手順02から​始める​：​計算を​確かめる

証拠

0

この​ページで​確かめた

まだない。​確かめるまで、​94%は​一つの​主張にすぎない。

仮定

3

成り立つとして、​確かめていない

  • 計算に​誤りはない。手順01
  • 答えの​定義は、​問いが​求める​定義と​同じだ。手順01
  • この​100件が​先月の​注文のすべてで、​日付は​正しく​記録されている。手順01

未知

0

この​データでは​答えられない

まだ​挙げていない。​二つの​定義で​数えて、​はじめてこの​データでは​答えられないものが​見える。

架空の​注文100件で、​一つの​問いだけを​確かめる​限定的な例です。​二つの​割合は、​この​ページで​注文データを​実際に​数えて​出しています。​実際の​検証では、​定義の​出所や​集計の​範囲も​確かめる​必要があります。

よくある​質問

これは​実在の​会社の​データか。

違う。​注文も​人物も​数字も​架空だ。​94%と​79%も​書き込んだ​値ではない。​この​ページが、​架空の​注文100件から​毎回数えている。

この​ページで​AIは​動いているか。

動いていない。​エージェントの​答えは、​あらかじめ書いた​筋書きだ。​この​ページが​示すのは​設計の​仕組みで、​確かめることを​二つに​分け、​答えを​根拠と​一緒に​渡す。

効率や​正確さが​上がったことを​示しているか。

示していない。​効率も​正確さも​測っていない。​示しているのは​一つだけ、​計算だけを​確かめたときに​何を​見逃すかだ。

定義は​一度直したのに、​なぜまたずれたのか。

修正が​記憶に​残っていても、​次の​答えがそれに​従うとは​限らない。​だから​毎回、​答えを​問いと​照らし​合わせる。​前回直したから​大丈夫だとは​考えない。 記憶が​結果を​持ち帰る仕組みを​見る

問いそのものの​定義が​曖昧なときは。

曖昧だとはっきり言う。​考えられる​定義とそれぞれの​結果を​並べ、​問いを​出した​人に​選んでもらう。​その​選択を、​システムが​代わりにすることはない。

自分の​チームの​AIの​答えに、​どう​使うか。

最近、​何かを​決めるのに​使った​数字から​始める。​どの​定義で​数えたのか。​その​定義は​問いの​意図と​合っているか。​どこを​確かめ、​どこが​仮定で、​何がまだ​分からないのか。​この​三つの​欄を、​数字と​一緒に​渡す。