2026年6月にこの雑誌は「ドメイン専門家の時代」で創刊六か月を閉じた。結論は一文だった — 何を作るかを最もよく知る人が前に立つ。
その記事は先行する五本を一段落ずつ要約して畳む総合だった。総合それ自体は正しい形式だ。問題は要約されたものに証拠がなかったことだ。ないものを五つ集めれば五倍ない。
だからこの作り直しは順序を逆にした。先に全部作り直し、いま畳む。
この記事が踏むのは十五個のサンプルだ。すべてビルドされ、実行され、画面のあるものはレンダーまで確認された。ひとつは机の上の実物ボード二台に繋がっている。
何が実際に証明されたか
六か月前の記事の命題を、今回実際に確認されたものだけ残して書き直す。
画面は定義であり、定義は小さい。 一画面が1〜2キロバイトだ。店舗サーバーがキオスク・POS・厨房にそれぞれ渡す三画面の合計が3,555バイトだった。(画面の層だけが溶ける)
転送を選んでもコードは割れない。 同じクライアントがUSBシリアルのSTM32とWi-Fi越しのESP32に繋がった。違ったのはブリッジプログラムひとつだった。(ボードが自分の画面を渡す)
ハードウェアを差し替えても規則は生きる。 摂氏センサーを華氏モデルに変え、ノードを二つ増やしても、サーバーコードと規則は一文字も変わらなかった。(センサーを差し替えても制御はそのまま)
ビルドなしに画面が変わる。 JSON 2,940バイトを2,934バイトに直すと83ミリ秒で反映され、コンパイラは走らなかった。(フォルダひとつがアプリだ)
作らなかった能力には届かない。 道具一覧にないものは、人が押しても、モデルが選んでも呼び出されなかった。(出さないものがアプリを守る)
ところが結論は半分しか当たっていなかった
ここが六か月前の記事と分かれる地点だ。
あの記事は敷居が低くなったという側に重心を全部置いた。二割の壁が低くなったのだから、八割を持つ人が前に立つ、と。
作ってみると敷居は実際に低かった。会費ツールは45行だった。栽培規則の一片は7行だった。
ところがそれだけでは前に立てない。
七つの現場の道具を作りながら、毎回同じものが問題だった。低い敷居ではなく、信じられるかだった。
- 農家の画面に「平均18日」が出たとき — それが記録から出たのか誰かが書き込んだのか見分ける方法
- 教師が8点を見たとき — なぜ8点か
- 税理士が4月27日を見たとき — 法定期限か週末でずれたのか誤字か
- 一人で働く店主がリストの一番上を見たとき — なぜそれが一番上か
- 受け継いだノートを読むとき — 誰がいつ知ったのか、そして誤りと分かった行が消されていないか
すべて同じ問いだ。結果の横に根拠があるか。
そしてこれは敷居より難しい。敷居は道具が下げてくれるが、根拠は作る人が入れなければならない。 入れなくても画面は同じようにきれいに出る。だから入れなくなる。
一人で作る人には特にそうだ
六か月前の記事が見落としたものがもうひとつある。
ドメイン専門家が自分の道具を作るということは、間違えたときに捕まえてくれる人がいないという意味でもある。会社の道具にはレビューがあり、QAがあり、次の担当者がいる。自分の道具には自分だけだ。
だからこのシリーズの十五個のサンプルで最も多くやったことは、画面作りではなく検証に条件を入れることだった。
| 何を守ったか | どこで |
|---|---|
| 計算された平均がソースに定数として存在すれば失敗 | 農家 |
| 部分点が理由なしに出れば失敗 | 教師 |
| 締切日がソースに文字列としてあれば失敗 | 税務 |
| 項目に出典がなければ失敗 | 一人事業 |
| 訂正された行が消えれば失敗 | 受け継いだノート |
| 判定語が放出されれば失敗 | 診療フロー |
| 画面が60行を超えれば失敗 | 会費 |
| キャプチャが互いに同じなら失敗 | 全部 |
最後の行がこの表でいちばん安く、いちばんよく働いた。画面が描かれていないのにPNGは正常に出てくることが三回あった。ログは毎回きれいだった。
あの表は文章ではなくファイルだ
上の八行はこの記事がまとめた要約ではない。それぞれがサンプルフォルダの verify.sh の中に失敗させる条件として書かれていて、条件が破れればそのサンプルは通らない。
一行目から見るとこうだ。農家の編の「平均18日」が計算された値か書き込まれた値かを分ける場所だ。
AVG=$(grep -o "average from records: [0-9.]*" captures/run.log | awk '{print $4}')
if grep -RIn --exclude-dir=captures -F "$AVG" farm_server/bin farm_log.mbd bundle_host/lib; then
echo " the average $AVG appears literally in the source — it must be computed"
exit 1
fi
画面に出た値をソース全体から探し直す。見つかれば失敗だ。結果が正しいかを検査するのではなく、結果がどこから来たかを検査する。
残りの七つも同じ場所にある。
| 何を守ったか | どこに書かれているか |
|---|---|
| 計算された平均がソースに定数として存在すれば失敗 | farm-log/verify.sh:35 |
| 部分点が理由なしに出れば失敗 | grading-tool/verify.sh:34 |
| 期限日がソースに文字列としてあれば失敗 | deadline-board/verify.sh:33 |
| 項目に出所がなければ失敗 | one-person-desk/verify.sh:34 |
| 訂正された行が消えれば失敗 | inherited-notebook/verify.sh:33 |
| 判定語彙が放出されれば失敗 | clinic-flow/verify.sh:33 |
| 画面が60行を超えれば失敗 | club-dues/verify.sh:11 |
| キャプチャが互いに同じなら失敗 | サンプルごと (DISTINCT) |
最後の行が一番短い。
DISTINCT=$(ls -l captures/*.png | awk '{print $5}' | sort -u | wc -l | tr -d ' ')
[ "$DISTINCT" -eq 3 ] || { echo " $DISTINCT distinct sizes out of 3 — a screen rendered blank"; exit 1; }
ファイルサイズしか見ない。しかし先に書いた三度を捕まえたのがこの二行だ — 画面が空でも PNG は正常に作られ、ログも毎回まともだった。PNG が出たという事実は、画面が描かれた証拠ではない。
この二行が何を捕まえられないかも書いておく。サイズが互いに違いさえすれば通るので、間違った画面三枚は通る。この検証ゲートが止めるのは空の画面であって、間違った画面ではない。間違った画面は上の七行がそれぞれドメインの側で止める。
順序がひっくり返るという言葉の実際の大きさ
六か月前の記事の表現をもう一度使う。長らくドメイン専門家は後ろで説明し、開発者が前で作った、と。
作ってみて、その順序をこう書き直す。
前に立つのは判断だ。 人ではなく。
- 農家の判断は七行で書かれ、部品番号を一文字も持たないのでハードウェアより長く生きる
- 教師の基準は文字列のリストなので、本人が読み返して直せる
- 税理士の規則は保存され、日付は計算される
- 工場のエンジニアの点検表は、要約できないように検証が原文を照合する
そしてこの四つのどこにも「専門家がコードを書いた」という箇所がない。 判断が短く書ける形式に移され、その形式を誰かが作らなければならなかった。このシリーズでその誰かは私だった。
だから正確に言えばこうだ。 ドメイン専門家が前に立つのではなく、ドメイン専門家の判断が前に立ち、残りがその後ろに退く。 その場所を作る仕事は依然として誰かの仕事であり、ただその仕事が以前より薄くなった。
六か月前の記事から外すもの
作り直しなので、あのとき書いたが今は支えられないものを外す。
六人の人物の成果の数値を外す。「十分で」「深夜を取り戻した」「三十冊がひとつの画面に」といったものだ。それらの数値は特定の人物から測ったものではなかった。七本すべて同じ形をそのまま構成して作ったものであり、各編の冒頭にそう書いてある。
これは小さな訂正ではない。field の筋の論旨は「あなたにもできる」という許しであり、許しは事例の実在に乗っている。実在を確認しないまま同じ文を繰り返せば、それは許しではなく広告だ。
だからこの総合が畳むものも狭くなる。「人々がやり遂げた」ではなく、「こういう道具はこういう姿で、これだけ短く、こういう条件で信頼できる」までだ。
「これらは比喩ではない」という自己表明も外す。 今回も比喩ではなく、実際の形どおりの構成であり、そう書いた。
次の六か月が返すもの
六か月前の記事が開けておいた場所のうち、次の六か月が返すものだ。
- 「言えば画面になる」— 人の言葉が定義になる変換。七本すべてでその段階は私が手でやった。 このシリーズはその変換を作っていない。
- オフライン・キャッシュ— 創刊号が答えた場所に今も実測がない。
- アプリストア方針— 根拠となるガイドラインの引用なしに解釈だけがある。
- 運用コスト— このシリーズのサーバーはすべてローカルプロセスだった。
- モデルの道具選択の正確さ— LLM編のモデルは決定論的なスタブだった。
- 経験の第二層・第三層— 事実が技術になり技術が予測になること。数日回したサンプルでは見えない。
- ドメイン専門家がこの形式を自分で扱えるか— 45行が読めるものだというところまでが確認されたことで、初めて見る人がどれだけで使えるようになるかは、そういう人にやらせてみなければ分からない。
このサンプルの範囲
六か月前の記事の誠実の節四つは維持する。開発者は消えないし、すべてが道具になるわけではないし、境界を引くこと自体がドメイン知識であり、易しくなったのは手であって責任ではない。
最後の一文が今回いちばん大きく確認された。十五個を作りながら易しくなったのは画面を出す手であり、難しくなったのはその画面を信じてよいかを自分で確認する責任だった。
そして今回分かったことを加える。
この記事には新しいサンプルがない。 総合記事の仕事は新しく建てることではなく、すでに建てたものを踏むことだ。六か月前の記事の問題は踏むものがないのに踏むふりをしたことで、今回は十五個ある。
その十五個も大半がシミュレータだ。 実物ハードウェアに繋がっているのはひとつだけで、残りはすべてCで書いたシミュレータか合成データだ。各編にそう書いてある。
前に立つということ
六か月前の記事はこう閉じた — 終わりではなく始まりだと。
六か月が過ぎ、始めたものを作り直してみて、その文をこう書き直す。
敷居は低くなった。 45行と7行がその証拠だ。
ところが低い敷居は良い道具を保証しない。 越えた後に必要なのは結果の横に根拠を置く習慣であり、それは道具が代わりにやってくれない。
だから前に立つ人に必要なのはコーディングではなく、自分の道具を疑う方法だ。このシリーズが実際に作ったものも画面十五個ではなく、疑いの形式十五個 — 何が真でなければならないかを合格条件に書いておくやり方 — だった。
記録から出た数字と書き込んだ数字は画面では同じに見える。その二つを見分ける方法を持つ人が、前に立つ。
makemind.dev 「探索」— 引用した実測はすべて併載のサンプルから出ている。