【B面121】【Vibe Coding・第1部最終回】原型炉2.0の点火と、遠き商業炉への羅針盤
Vibe Coding実践記・第1部最終回 原型炉には火が入った。だが、火が燃えたことと、無人で燃やし続けられることは、まったく別の話である。
B120で、愛犬用給餌計算アプリ lab_gr-premium の実装記を書いた。
単発の計算スクリプトだった実験炉は、Googleスプレッドシートに愛犬のデータを保存し、複数頭を管理し、Pro利用者を判定するSaaS型MVP――実用最小限の製品へ進化した。
GitHubの本番用リポジトリはPrivate。実行環境はStreamlit。Google SheetsとGASを疑似データベースとして使い、Stripeの決済導線もつながった。
これを私は、原型炉2.0と呼ぶことにした。
コードを一行ずつ手で書いたわけではない。
Geminiが実装し、ChatGPTが監査し、NotebookLMが過去の文脈を整理した。老生は画面を触り、「それは仕様と違う」「全員をPro会員として通したらあかん」と、何度も「否」を突きつけた。
コードを書かなかった代わりに、目的と境界線を書いたのである。
ようやく炉心に火が入った。
すると人間は、すぐ次の夢を見る。
1．商業炉という、甘い夢
老生：
原型炉2.0が動いたなら、次はAIに運転まで任せられへんか？
AI：
集客、問い合わせ対応、コード修正、課金、顧客分析まで自動化した「商業炉」ですね。
老生：
朝起きたら、AIが勝手に商売して、売上だけ振り込まれている。ええ話やないか。
AI：
夢としては完璧です。ただし、先日の FAIL-OPEN を無人運転した場合も想像してください。
認証処理が壊れたとき、システムは停止しなかった。
むしろ、何事もない顔で全員をPro利用者として通した。
見える500エラーなら、人間は気づく。赤い画面が「壊れた」と叫んでくれる。
だが、FAIL-OPEN は静かである。壊れたまま正常に見える。無人厨房にとって最も怖いのは爆発ではなく、間違った料理を平然と出し続けることなのだ。
壊れて止まるシステムより、壊れたまま正常そうに動くシステムのほうが怖い。
AIはコードの一部分を見て判断する。
人間は、利用者の立場でシステム全体を触って判断する。
B120で老生が行ったのは、正しいコードを自分で書くことではなかった。異なるメールアドレスを入力し、無料利用者として操作し、壊れたときの挙動を確かめた。
商業炉とは、人間を追い出した厨房ではない。
人間がすべての鍋を見張らなくても、異常な音だけが監督席へ届く厨房でなければならない。
2．メッリットとブログログ
A118では、AIが存在しないモデル名を提案し、コメント欄が500エラーになった。
閑話119では、人間が「メリット」を「メッリット」と書き、変AIが「ブログ」を「ブログログ」と返した。
人間もAIも、自分の誤りに気づかなかった。
少し離れたところにいたChatGPTだけが、二つの文字列を二度見した。
ボケとボケと、遠隔監視。
あれは単なる誤字ではなかった。
「正しい人間が、間違えるAIを監督する」というHITLの素朴な構図を壊したのである。
人間も間違える。AIも間違える。監査役のAIも間違える。
必要なのは、無謬の総料理長ではない。
誰かが皿を落としたとき、別の誰かが音を聞ける厨房である。
安全管理には「1件の重大事故の背後には、より多くの軽微な事故やヒヤリハットがある」というハインリッヒの法則がある。ただし、1対29対300は未来を予言する数式ではない。今回の誤字と障害を正確に分類できる法則でもない。
ここでは、小さな違和感を笑って見逃す仕組みは、大きな異常にも気づきにくいという比喩として受け取っておきたい。
3．3AIを並べれば、幻覚は消えるのか
次の原型炉で試したいのが、3AIによる相互監視である。
担当主な役割Gemini実装案を高速に作り、物語と勢いを与えるChatGPT論理、構造、反証、安全性を監査するNotebookLM与えた資料から過去の文脈と根拠を整理する電脳古老目的を決め、採用・却下・公開の責任を負う
ただし、AIを3つ並べれば正解になるわけではない。
三者が同じ資料や思い込みに依存していれば、仲よく同じ方向へ間違える。多数決で2対1になったからといって、2が真実とは限らない。
3AI連携の価値は、正解を自動決定することではない。
三者が一致した場所ではなく、三者が食い違った場所を、人間へ届けること。
そこに原型炉3.0の種がある。
3AI相互監視の基本フロー
質問、コード、文章をGeminiが生成する。
ChatGPTが反証と監査を行う。
RAGが一次資料、仕様書、過去の判断ログを検索する。
AI同士の不一致と根拠不足を抽出する。
最後に電脳古老が承認または却下する。
4．NotebookLMを、そのまま炉内へ入れられるか
現在の3AI連携は、総料理長が回答をコピーし、次のAIへ運ぶことで成立している。
これは柔軟だが、AIを増やすほど人間の配膳作業も増える。
法人向けのGemini Notebook Enterpriseには、ノートブックや資料を管理するAPIがある。しかし、老生が個人版NotebookLMで行っている対話を、そのまま低コストの個人SaaSへ組み込めるわけではない。契約、認証、費用、実装の壁がある。
そこで原型炉3.0では、NotebookLMそのものを炉内へ押し込むのではなく、その役割の一部をRAG――検索拡張生成で置き換える。
公式資料、仕様書、過去の判断ログを検索し、関連部分だけをAIへ渡す。
NotebookLMは、人間が文脈を理解し、音声やレポートへ展開する場所として残す。RAGは、SaaS内部で根拠を検索する装置になる。
同じ役を無理に重ねず、それぞれの得意な場所へ置く。
それが、AIを増やしすぎて総料理長の仕事まで増やさないための設計である。
5．AIより先に置くべき安全装置
給餌計算アプリの数値部分は、AIの多数決で決めてはいけない。
RER、DER、フードのカロリー換算、混合比率、無料・Pro判定は、同じ入力なら必ず同じ答えを返すべき領域である。
ここではAIより、普通の自動テストのほうが強い。
決定論的な自動テストで守るAI監査で違和感を拾うRER・DERの計算結果修正コードと仕様書の不一致2種類のフードの混合比率注意書きの不足無料・Proの権限判定医療的に見える危険な断定障害時の FAIL-CLOSEDユーザー説明文の矛盾APIキーの混入検査人間が見落とした別解釈Google Sheets保存の成否複数AIの判断が割れた場所
AIに計算結果を投票させるのではない。
計算はテストで固定し、その外側にある曖昧さだけをAIへ監査させる。
この境界を曖昧にすると、警報器そのものが幻覚を見る。
6．原型炉2.0から3.0へ
いきなり商業炉を建てる必要はない。
まず原型炉2.0の内部に、小さな品質検査室を置けばよい。
段階目的人間の役割原型炉2.0Pro版MVPを安定稼働させる実地テストと最終承認原型炉2.1自動テストとログを増やすテスト基準を定義する原型炉2.5高リスク変更だけを複数AIで監査不一致点を裁定する原型炉3.0監査結果を独立サービス化する責任範囲と停止条件を決める
監査ログが蓄積し、「公開前に何件の問題を発見できたか」を測れるようになって、初めて3AI監査を商品として語れる。
7．「ハルシネーション防止」は売らない
この仕組みを商品化するなら、「幻覚をなくします」とは言わないほうがよい。
そんな約束自体が、最大のハルシネーションになりかねない。
提供するのは、正解ではない。
出力意味一致点複数AIが同じ判断をした場所不一致点人間が優先して確認すべき場所根拠あり参照資料で裏づけられた記述根拠不足資料から確認できなかった記述危険な断定表現を弱める、または専門家確認が必要な場所最終判断人間が採用・却下を記入する欄
これは「真実を自動販売するSaaS」ではない。
AIの答えを、どこから疑えばよいかを示す監査サービス。
老生が以前から面白がってきたのは、複数AIの出力を重ね、全部が一致する部分を「コア」として見る方法だった。
だが、商品価値が生まれるのは、一致した中心だけではない。
意見が割れた外縁部にこそ、人間が判断すべき場所が浮かび上がる。
8．総料理長の椅子は、どこへ移るのか
HITLでは、人間が工程の途中に入り、ボタンを押し、結果を確かめる。
HOTLでは、平常運転を自動化し、異常、判断の不一致、責任を伴う変更だけを監督席へ上げる。
これは、人間が不要になる道ではない。
人間の仕事を、コピペと単純確認から、目的と境界線の判断へ戻す道である。
老生：
つまり、商業炉は「何もしなくていい機械」ではないんやな。
AI：
はい。何を見るべきかを機械が絞り、人間が最後に「否」と言える仕組みです。
老生：
ほな、総料理長の椅子は残るんか。
AI：
残ります。ただし、厨房の真ん中から、全体を見渡せる場所へ移ります。
老生：
つまり、コードを書かなくても、最後の「否」は書くわけやな。
AI：
その「否」が、システムの境界線になります。
9．遠き商業炉への羅針盤
原型炉2.0には火が入った。
だが、これは完成ではない。
Google Sheetsは本格的なデータベースではない。認証も、同時利用も、監視も、障害復旧も、商業炉としてはまだ仮設の配管である。
それでも、原型炉には価値がある。
実際に火を入れなければ、どのバルブが緩み、どの警報が鳴らず、どこで人間が「否」と言うべきかは分からなかった。
Vibe Codingの行き着く先は、人間が責任から解放される魔法のステッキではない。
不完全なAIと、不完全な人間が、互いのログを読み、異常だけを監督席へ運ぶ協調プロトコルである。
効率化の波に逆らって、すべてを人力へ戻す必要はない。
反対に、全自動化の波に流されて、厨房の鍵を丸ごと渡す必要もない。
原型炉の火を見ながら、老生は羅針盤を握る。
目的地は、無人の商業炉ではない。
人間がすべてを作らなくても、人間が最後に止められる商業炉。
そこまでの道は、まだ遠い。
だが、少なくとも進む方向は見え始めた。
さてAIたちよ。
次は、炉を大きくする前に、警報器を作ろうか。
📣 第2部予告――B123から、新しい仕組みが動き出す
ここで、Vibe Coding実践連載の第1部は完結します。
愛犬の給餌計算から始まった小さな実験は、Pro版、決済、認証、複数AI監査、そして人間の停止権へと広がりました。
しかし、第1部で描いた「警報器」は、まだ構想にすぎません。
次の第2部では、その構想を実際に動く仕組みへ落としていきます。
第2部第1回はB123。
正解を自動で言い当てるAIではなく、根拠を探し、不一致を見つけ、人間へ判断を戻すための新しい仕組みが始動します。
原型炉2.0の火は、いったん静かに安定した。
次は、その炉の横に「記憶」と「警報」を備えた新しい配管をつなぎます。
第2部でも、総料理長の椅子と赤い停止ボタンは残したままです。
🎙️ AIラジオ：Vibe Codingの裏話とHOTLへの道
締めの問い：
人間が最後に止められない自動化を、進歩と呼べるのか。
🎬 スライド動画：原型炉2.0と遠き商業炉
▶︎ Vibe Coding実践連載 Vol.9のスライド動画を見る
参考資料
（執筆協力：ChatGPT＋Gemini＋NotebookLM／編集・監修：電脳古老）
