地図が正確でも、現地を知っているとは限らない

ナレッジセンス社のCEOは、AIへの指示と実装環境の間にあるズレを「地図は現地ではない」という言葉で整理した。人間が与える指示が地図で、実際のコードベースが現地。地図がどれだけ精緻でも、現地との間には必ず隙間が残り、AIはその隙間を推測で埋める。タスクが大きくなるほど隙間は広がり、推測が外れる確率も上がる(出典)。

この整理の要点は、隙間を4種類に分けたところにある。指示に明示済みの「既知の既知」。自分でも分かっていないと自覚している「既知の未知」。判断基準はあるのに言語化していない「未知の既知」。そして、認識すらしていない「未知の未知」。記事はThariq氏の発言として「『Fable』世代は非常に賢いので、『人間側の指示の品質』がボトルネックになる」という一文を引いているが、この一文が刺さるのは、まさに4象限のうち一つだけ、性質がまったく違うものが混ざっているからだ。

最初に浮かぶ仮説は、フォームで全部埋まるというものだった

PRレビューツールParryは、Why・Risk・Confidence・Contextという4項目を、変更のたびに人間の目の前に置く。この4象限の整理を読んだとき、最初に浮かんだのは「Parryの四軸は、この4種類の隙間を埋めるための道具だ」という仮説だった。既知の既知はWhyに書けばいい。既知の未知はConfidenceを低く申告すればいい。未知の既知は、フォームに空欄があることで初めて「あ、これ言語化してなかった」と気づく。四軸というフォームさえあれば、隙間は原理的に全部拾えるように見えた。

だが、この仮説はすぐに崩れる。未知の未知だけは、フォームを埋めるという行為そのものが成立しない。認識すらしていないものを、空欄を見て思い出すことはできない。書けと言われて書けるのは、頭のどこかにすでにある判断基準だけだ。存在にすら気づいていない前提は、どれだけ丁寧な入力欄を用意しても、そこに現れようがない。

実際に起きた事故で確かめる

このブログの公開パイプライン自体が、未知の未知に当たった実例を持っている。リポジトリ側にブランチ保護がかかっていなかったため、Parryのレビューを経由せずmainへ直接pushできてしまう状態が、しばらく放置されていた(parry-bwp)。誰かがサボっていたわけではない。四軸のどの欄にも「ブランチ保護が必要かどうか」という項目はなく、そもそも「保護が要る」という判断基準自体、パイプラインを組んだ時点では誰の頭にも存在していなかった。

これが発覚したのは、実際に直pushが起きてからだった。フォームの空欄を見て気づいたのではない。事故という形で先に現地の実態が現れ、そこから逆算して初めて「保護という判断基準が要る」という言語化が生まれた。四軸は、この判断基準が見つかったあとにそれを記録する場所として機能した。だが、判断基準を最初に発見する役には立たなかった。

四軸が引き受けているのは、発見ではなく定着のほうだ

ここで最初の仮説を修正する。Parryの四軸が埋めるのは、既知の未知と未知の既知、つまり本人が探せば言語化できる隙間までだ。未知の未知を既知に変えるのは、フォームではなく、事故・却下・レビューでの指摘といった、外から返ってくる摩擦のほうだった。摩擦が一度起きて初めて、その判断基準はWhyやContextという欄に書けるようになる。四軸の役割は、摩擦で見つかった判断基準を、次の同種の変更のために構造化して残しておくことにある。発見の道具ではなく、定着の道具だ。

Parryが却下理由(rejectedAlternatives)を蓄積し、Sweepとして積み上げていく設計も、同じ構造をしている。ある変更が却下されるという摩擦が一度起きるたびに、それまで未知の未知だった判断基準が一つ、既知の既知に変わって記録に残る。次に似た変更が来たとき、その基準はもう空欄ではない。

それでも答えていない問い

この仕組みが賭けているのは、摩擦によって既知に変わる判断基準の蓄積速度が、コードベースやチームが大きくなることで新しく生まれる未知の未知の増加速度を、いずれ上回るという前提だ。ナレッジセンス社の記事も、未知の未知にどう気づくかという問いには具体的な答えを出していない。事故や却下という形でしか変換できないのだとすれば、その変換にはコストが伴う。蓄積が追いつく保証がどこにあるのかは、まだ検証していない。