探索

通訳なしで座る — 判断ひとかけらが規則になる場所

著者: makemind · 2026年7月17日

2026年3月に「基盤はすでにある」を載せた。要旨はこうだった — 「あなたにも道具が作れる」は更地から始めよという言葉に聞こえるが実際は正反対であり、道具の八割は判断で、その判断はまさに作ったらいい人の手にすでに握られている。 欠けているのは画面という一軸だけだ、と。

その記事で最も良かった段落は比喩ではなく警告だった。

班長が「この音」と言ったものが文書では「異常音発生時」になり、その間で30年の耳が丸ごと蒸発する。

これが八割を失う仕方だ。判断は運ぶ間にすり減る。要件定義書を経て開発者の解釈を経て、「こういう場合はちょっと違うんですが」のニュアンスが消える。

だからあの記事の本当の主張は「画面が簡単に作れる」ではなかった。判断が通訳なしに座れるかだった。それは難易度の問題ではなく経路の問題だ。

あのときはその経路を言葉でだけ書いた。今回は実際に回るものの上で確認する。

農家の判断ひとかけら — 七行

温室制御のサンプルを作りながら、栽培規則をこう置いた。

Rule(
  name: 'vent above 26C',
  whenKind: 'temperature',
  above: 26.0,
  thenKind: 'vent',
  setTo: 80.0,
  elseSetTo: 0.0,
),

七行だ。 そしてこの七行が何を言っていないかが重要だ。

どのセンサーかを言わない。どのリレーかを言わない。型番が一文字もない。読む値の種類と動かすものの種類だけがある。だから温度計を別会社の製品に差し替えてもこの七行はそのまま生きる — 実際に差し替えてみて、摂氏センサーを華氏モデルに変え、CO2センサーとバルブを増設しても規則は一文字も変わらなかった。

A: vent above 26C: 26.5 -> v1=80.0     (TH-100, 摂氏, 3ノード)
B: vent above 26C: 26.3 -> v1=80.0     (FX-200, 華氏, 5ノード)
   server code: unchanged   rules: unchanged   rebuild: none

元の記事が「判断ひとかけらが通訳なしに定義となって画面に座る」と書いた場所に、いまやそのかけらが何行で何に耐えるかが入る。

(温室の連鎖全体はセンサーを差し替えても制御はそのままに。)

班長の点検表 — 一文字も変えられないように止めた

元の記事のあの警告を正面から受けたものがもうひとつある。

設備整備アシスタントを作りながら、安全点検表をサーバーに置いた。そしてその道具の説明文にこう書いた。

server.addTool(
  name: 'checklist.get',
  description:
      'Get the plant safety checklist for a machine type (press, conveyor, welder). '
      'These steps are set by the plant engineer and must not be paraphrased.',

道具の説明は装飾ではない。モデルが実際に読むテキストだ。そしてその上に載せた指示にも同じ行がある。

- Safety checklist steps are the plant engineer's. Quote them in order and do
  not paraphrase, shorten or reorder them.

ところが指示は依頼であって保証ではない。だから検証が実際に照合する。

# 点検表は引用であって要約であってはならない — 一行を原文どおり照合
grep -q "Verify emergency pull-cord continuity along both sides" captures/run.log \
  || { echo "a checklist step was altered on its way to the answer"; exit 1; }

「30年の耳が蒸発する」を止める方法がこれだ。 動かすなと頼み、動かされたかを機械が照合する。合格条件に入れなければ依頼はいつか守られず、守られなかったことを誰も知らない。

元の記事は判断がすり減ることを問題として指摘したが、対策は「自分で作ること」までだった。実際に作ってみると対策がもうひとつ必要だった。自分で書いたものがそのまま残っているか確認する装置。 自分で書いても、その下の層が要約すれば同じように蒸発する。

(設備アシスタントは答えの横に根拠を付けるに。)

判断を受け取る側がやってはいけないこと

この記事の元編はドメイン専門家の側からだけ見ていた。作ってみると反対側にも規律が必要だった。

設備サーバーの状態ハンドラだ。

// The server states facts and how those facts compare to limits.
// The machine never says "fine" — that word belongs to the person
// holding the checklist.
final overdue = (m['runHours'] as int) > (m['serviceEveryHours'] as int);
final vibrationOver =
    (m['vibrationMm'] as num) > (m['vibrationLimitMm'] as num);

serviceOverdue: true は事実だ。safe: false は判断だ。判断をシステムが代わりに下し始めると、八割が手にあるという言葉が無意味になる。 専門家が判断を持っているのに道具が先に結論を出せば、その判断は使われない。

だから元の記事の命題に半分を足す。八割は専門家の手にある — そしてシステムはその八割が置かれる場所を空けておかなければならない。

二割はどれだけ低くなったか — そして元の記事が間違っている箇所

元の記事は二割の壁が低くなったと言った。どれだけ低くなったかは測らなかった。

いまはいくつか測れる。

栽培規則ひとかけら7行
規則一覧全体(規則2つ)18行
画面定義一枚1〜2 KB
無人店舗アプリ全体JSON 4つ、約6 KB、コンパイル0回
画面文言の修正 → 反映83 ms、ビルド0回

ところがここで元の記事が間違っている箇所が露わになる。

「十行」という言葉がその記事にあった。 画面ひとつが十行で済むという趣旨だったが、そのときその十行が実際に何なのかは見せられなかった。いま数えてみると規則ひとかけらは七行で合っている。しかし画面一枚は1〜2キロバイトであって十行ではない。 ボタンひとつテキストひとつなら十行だが、役に立つ画面一枚はそれより大きい。その差を元の記事はぼかしていた。

「三日対一時間」のような時間の比較もその記事にあった。 根拠がなかった。このシリーズもその比較に代わる実測を持っていない — 旧来のやり方で同じものを作って測ったことがないからだ。比較がないなら比較を書かない。 この記事ではその一文を外す。

そしてもうひとつ。二割が低くなったのは事実だが、消えたわけではない。 無人店舗バンドルをクリーニング店に直してみたらラベルは変わったのに品目はアイスクリームのままだった。画面はJSONなのでドメイン専門家が直せるが、品目が何か・再発注点がいくつかは依然としてバンドルの外にある。 ノーコードでできることとできないことの境界がまさにそこだ。

(その境界はフォルダひとつがアプリだで絵として見られる。)

柔らかいものの復権 — いまも有効な部分

元の記事の最後の軸はこうだった。長らく「硬いもの」(コード・技術)が価値を持ち「柔らかいもの」(経験・勘・目利き)には値が付かなかったが、二割の壁が低くなればその値が逆転する、と。

作ってみて、この軸は有効だと見る。ただし根拠をひとつ付けられる。

温室の規則が部品番号を一文字も持たないこと — それが柔らかいものを価値あるものにする構造だ。規則が FX-200 を知っていればその規則は部品に縛られる。種類だけで語れば規則が部品より長く生きる。長く生きる側が価値ある側であり、ここで長く生きるのは「26度で開けろ」という判断だ。

このサンプルがやっていないこと

元の記事の誠実の節を維持し、今回分かったことを足す。

この記事には新しいサンプルがない。 引用したコードとログはすべて先行する編で作ったものだ。horizonの記事の仕事は新しく建てることではなくすでに建てたものを踏むことであり、元編の問題は踏むものがないのに踏むふりをしたことだった。

「半日あればできる」類の所要時間は測っていない。 元編にそういう趣旨の文があり、このシリーズもそれに代わる実測がない。ドメイン専門家が実際に規則を書くのにどれだけかかるかは、ドメイン専門家にやらせてみなければ分からず、それをしていない。 ここに載せた七行は私が書いたものであって農家が書いたものではない。

八割/二割という比率自体も測られたことがない。 元編の修辞であり、この記事もそれを検証していない。比喩としてだけ読んでほしい。

規則が種類で語れば生きるということは確認したが、ドメイン専門家がその形式を自分で扱えるかは確認していない。上の七行はDartの文法だ。農家がそれをそのまま書けるかは別の問いであり、このシリーズはその問いに答えていない。

判断が座る場所

元編はこう問うた — 八割を持つ人がなぜ二割の前で止まるのか。

作ってみて答えを少し変えて書く。止めるのは二割の難易度だけではない。判断が運ばれる間にすり減ること、そして運んだ後にそれが残っているか確認する方法がないことだ。

だから必要なものは三つだ。

  • 判断が短く書ける形式 — 七行。部品番号なしに種類で。
  • 動かすなという規律 — 道具の説明と指示文に。
  • 動かされたかを照合する装置 — 合格条件に。依頼だけでは守られない。

三つのうち最後が元編になかったものであり、実際に作ってみなければ出てこない項目だった。

基盤はすでにある — その言葉はいまも正しい。そこに一行を足す。その基盤が道具になる道ですり減らないか、誰かが確認しなければならない。


makemind.dev 「探索」— 判断ひとかけらの実際の大きさと、その判断がすり減らないよう止める装置を実物で返した。

Twitter