参入障壁を文書で守るのはやめる (3/5)

AI プロダクトの多くは、自分たちの参入障壁を文書で守っている。だがその文書は、新人がひとり入るか、深夜のリファクタリングが一度走っただけで、静かに腐りはじめる。lodos では、コミットのたびに走る二つの厳しい検査で守っている。片方は、絶対に作らないと誓ったものを出荷しかけたらビルドを落とす。もう片方は、苦労して手に入れた教訓が引けなくなったり、別のページと食い違ったりしたらウィキ自身を落とす。どちらも HMAC の連鎖に封じてある。こうして出来上がるのが、本当に後戻りしない障壁だ。拒否がひとつ、教訓がひとつ増えるたびに、システムは後戻りしにくくなり、その分だけ確実に役に立つようになる。

コミットのたびに、スクリプトを二本走らせている。

一本目は、絶対に出荷しないと誓ったものをコードベース全体から grep する。その場で式を評価する仕組み。機密情報の値をそのまま返すツール。モデル提供元の API を直に叩くモジュール。そして、エージェント経由の情報流出を成立させてしまう三点セット。どれかひとつでも見つかれば、ビルドは容赦なく落ちる。

二本目はウィキ全体を歩き回り、正反対の問いを立てる。ここにあるべきなのに、ないものは何か？　出典のない主張。どこからもリンクされていない概念のページ。数か月あけて書かれた二つのページが、互いに違うことを言っている箇所。一本目はシステムが CVE に変わるのを止める。二本目は、すでに学んだことを忘れるのを止める。

lodos は、たったひとつの決まりを軸に作った。意味のある拒否は、すべてビルドの中の grep として存在する。意味のある知識は、すべて版が残り、あとから引けるページとして存在する。

どちらも HMAC の連鎖の中にあり、何かに手が加えられた瞬間に大きな音を立てて壊れる。加えることを拒むものを書き出す。忘れることを拒むものを書き出す。その両方がそろわなければ出荷を拒むビルドを作る。AI プロダクトの多くは、自分たちが何になりたいかを書き出し、それを文書で守る。もっと少ないが、自分たちが何になることを拒むのかを書き出し、それをコードで守る会社もある。いちばん珍しいのは、忘れることを拒むものまで書き出す会社だ。しかもそれを、ページの中身がずれた瞬間に自分で自分の整合性検査を落とすウィキで守っている。複利で積み上がる障壁を築けているのは、そういう会社だけだ。

腐るものと、腐らないもの

文書で守った障壁は、静かに死ぬ。「機密情報をログに出すことはありません」「ツールの出力はすべて隔離環境を通します」「LLM に渡す前に必ず検証します」。こうした一文は SOC 2 の文書の中で生きている。書かれた日には本当のことだ。そこへ新人がデバッグ用のログ出力を一行足す。リファクタリングが無害化処理を機能フラグの裏へ動かす。一文は文書の中に残ったままだ。システムはもう、その一文のようには振る舞わない。何も失敗しない。誰も気づかない。

知識の側は、もっと速く死ぬ。創業者が午前2時に、あの顧客がなぜ解約したのかを理解する。その気づきを Slack に投げ、一週間で忘れる。教訓は、あとから引ける場所のどこにも残らない。3か月後に同じ形の出来事が戻ってきて、創業者は同じ授業料をもう一度払う。いちばん高くつくのはこの腐り方だ。本人が、それが起きていることにすら気づかないのだから。

この二つの失敗には、同じ薬が効く。守りたいものを、それが壊れたら一緒に壊れる構造に縛りつけることだ。一度拒んだものが戻ってきたら、ビルドを落とす。ページがどこからも参照されなくなったり、主題からずれたり、自分で自分と矛盾したりしたら、ウィキ自身の lint を落とす。直すべきなのは運用ルールではない。直すべきなのは、システムが毎回自分自身に向けて走らせる検査のほうだ。

Karpathy のやり方を、売れる形にする

知識の側は、自分で考え出したものではない。Andrej Karpathy が、三つの操作とひとつの主張からなる LLM ウィキを書いている。ウィキが実行ファイルで、生の資料がソースコードで、LLM がコンパイラで、lint がテストで、問い合わせが実行そのものにあたる、という主張だ。

そのやり方をそのまま真似たうえで、三つだけ意図して変えた。

• 保存先。 Karpathy は markdown ファイルを並べたフォルダと git を使う。こちらは SQLite と、セクションごとに暗号化したボールトを使う。相互運用性と引き換えに、秘匿性を取った。きれいな markdown で書き出せるようにはしてあるので、Obsidian が欲しくなればいつでも移れる。
• 自律性。 Karpathy は LLM に直接書かせる。こちらは、すべての変更を提案と承認の差分画面に通す。エージェントが確定版のページそのものに触れることはない。承認一回につき、5秒から10秒かかる。その代わり、エージェントが自分の振る舞いをこっそり書き換えることはできない。
• 監査。 Karpathy は素の markdown でログを残す。こちらはマスターパスワードから派生させた鍵で署名し、HMAC でつないだ連鎖にする。ログに手が入れば、次の起動時に連鎖の断裂として表に出る。

これは思想の違いではない。個人の知識管理のやり方を、商売として成り立つ形に直しただけだ。精神はそのままに、コンプライアンスを気にする買い手が払える値札をつけている。

どちらの側も、同じやり方で締まっていく

拒否の側と知識の側は、形がまったく同じだ。片方は、絶対に存在してはいけないものを grep する。もう片方は、絶対に欠けてはいけないものを grep する。どちらも「ないこと」を確かめる検査だ。どちらも落ちるときは大きな音を立てる。どちらも同じ HMAC の連鎖に封じてある。

ウィキに質問して答えが良かったとき、画面には「この回答をページにする」というボタンが一つ出る。押せば、その答えは残る。次のセッションでは、それがちゃんと見つかる。同じ質問を二度する必要はもうない。追っている指標は、出た答えのうちどれだけをページに変えたか、という保存率だ。この数字は時間とともに上がっていく。使えば使うほど確実に強くなるのは、システムの中でウィキだけだ。

拒否の側も同じように動く。不変条件を脅かしそうな機能を作るたびに、新しい不変条件が検証スクリプトに書き足される。このスクリプトは8か月で、検査7個から32個まで増えた。どの機能も、その機能が生む悪用の型を塞ぐ grep と一緒に出荷される。機能がひとつ出るたびに、コードベースが拒むものは、減ることなく増えていく。

多くのチームは、この二つを別々の話として扱う。実際には同じ規律を、二種類の「ない」に当てているだけだ。絶対に存在してはいけないものと、絶対に忘れてはいけないもの。

失うもの、そしてそれこそが狙いである理由

速度が落ちるのは、きっかり二か所だ。拒否とぶつかる機能と、ウィキを無視して進めたい書き直し。使い込んでいるユーザーが、その場で式を評価できる機能を欲しがる。断る。顧客が、機密情報の値をそのまま返すツールを欲しがる。断る。未来の自分は、この承認の手順を遅いと感じて引き剥がしたくなるはずだ。ビルドがそれを許さない。

リリースノートの見た目は、どの競合とも違う。こちらのノートには、機能と同じ回数だけ、断ったものの名前が並ぶ。意図して作らなかったものを伏せたまま、きれいな成長物語を語ることはできない。

得られるものは、宣伝文句には収まらない。効いてくるのは、規制の厳しい業界の買い手と向き合う商談の場だ。その相手は「できません」と「しないと約束します」を、まったく別の言葉として聞く。コンプライアンス担当者にとって、改ざんが検知できる HMAC の連鎖と、素の markdown のログは別物だ。今日ウィキに書き込んでいる創業者は、半年後にそれを必要とする創業者に読まれる。ここに挙げた相手は、どれも広告の売り文句では動かない。

持って行っていい五つの部品

どれも、ほかの四つを前提にしていない。五つそろって初めて、ひとつのやり方になる。

1. 式を評価する仕組みを一切持たない、宣言的なワークフローエンジン。
2. AI が平文の機密情報を返すことが構造上できない、ストアを二つに分けたボールト。
3. わざと破ってみせて初めて証明とみなす規律で書かれた、ビルド時の不変条件スクリプト。
4. Karpathy の三つの操作を実装し、ログを HMAC の連鎖で包んだウィキ。
5. エージェントが自分の振る舞いを決して書かない、提案しかできない学習ループ。

どの順で入れてもいい。五つに共通するのは規律だけだ。出荷することを拒むものと、忘れることを拒むものを書き出し、その両方をビルドの中で検査し、わざと違反してみせることで、その検査がまだ生きていることを確かめる。残りはすべて、ただのエンジニアリングだ。

次に来るもの

最後のループは、まともに動くまでいちばん時間がかかったものだ。エージェントは会話を見ていて、自分のスキル一覧に改善の余地があると気づくと、編集を提案してくる。承認するか却下するかを決めるのは自分だ。その編集も、ウィキのほかの提案とまったく同じ差分画面を通る。エージェントが自分の振る舞いを書くことはない。提案と承認のあいだにあるこの関門こそが、本当の障壁だ。次の投稿で書くのは、このループそのものだ。そして、これだけの手間をまるごと正当化してしまった、振る舞いを定める指示文のごく短い一節についても書く。

先行登録する