B121 原型炉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による相互監視である。

ただし、AIを3つ並べれば正解になるわけではない。

三者が同じ資料や思い込みに依存していれば、仲よく同じ方向へ間違える。多数決で2対1になったからといって、2が真実とは限らない。

3AI連携の価値は、正解を自動決定することではない。

三者が一致した場所ではなく、三者が食い違った場所を、人間へ届けること。

そこに原型炉3.0の種がある。

3AI相互監視の基本構造

graph TB
    A[質問・コード・文章] --> B[Gemini：生成]
    B --> C[ChatGPT：反証と監査]
    A --> D[RAG：一次資料と仕様書]
    C --> E[不一致・根拠不足の抽出]
    D --> E
    E --> F[電脳古老：承認・却下]

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に計算結果を投票させるのではない。

計算はテストで固定し、その外側にある曖昧さだけをAIへ監査させる。

この境界を曖昧にすると、警報器そのものが幻覚を見る。

6．原型炉2.0から3.0へ

いきなり商業炉を建てる必要はない。

まず原型炉2.0の内部に、小さな品質検査室を置けばよい。

監査ログが蓄積し、「公開前に何件の問題を発見できたか」を測れるようになって、初めて3AI監査を商品として語れる。

7．「ハルシネーション防止」は売らない

この仕組みを商品化するなら、「幻覚をなくします」とは言わないほうがよい。

そんな約束自体が、最大のハルシネーションになりかねない。

提供するのは、正解ではない。

これは「真実を自動販売するSaaS」ではない。

AIの答えを、どこから疑えばよいかを示す監査サービス。

老生が以前から面白がってきたのは、複数AIの出力を重ね、全部が一致する部分を「コア」として見る方法だった。

だが、商品価値が生まれるのは、一致した中心だけではない。

意見が割れた外縁部にこそ、人間が判断すべき場所が浮かび上がる。

8．総料理長の椅子は、どこへ移るのか

HITLでは、人間が工程の途中に入り、ボタンを押し、結果を確かめる。

HOTLでは、平常運転を自動化し、異常、判断の不一致、責任を伴う変更だけを監督席へ上げる。

これは、人間が不要になる道ではない。

人間の仕事を、コピペと単純確認から、目的と境界線の判断へ戻す道である。

老生： つまり、商業炉は「何もしなくていい機械」ではないんやな。

AI： はい。何を見るべきかを機械が絞り、人間が最後に「否」と言える仕組みです。

老生： ほな、総料理長の椅子は残るんか。

AI： 残ります。ただし、厨房の真ん中から、全体を見渡せる場所へ移ります。

老生： つまり、コードを書かなくても、最後の「否」は書くわけやな。

AI： その「否」が、システムの境界線になります。

9．遠き商業炉への羅針盤

原型炉2.0には火が入った。

だが、これは完成ではない。

Google Sheetsは本格的なデータベースではない。認証も、同時利用も、監視も、障害復旧も、商業炉としてはまだ仮設の配管である。

それでも、原型炉には価値がある。

実際に火を入れなければ、どのバルブが緩み、どの警報が鳴らず、どこで人間が「否」と言うべきかは分からなかった。

Vibe Codingの行き着く先は、人間が責任から解放される魔法のステッキではない。

不完全なAIと、不完全な人間が、互いのログを読み、異常だけを監督席へ運ぶ協調プロトコルである。

効率化の波に逆らって、すべてを人力へ戻す必要はない。

反対に、全自動化の波に流されて、厨房の鍵を丸ごと渡す必要もない。

原型炉の火を見ながら、老生は羅針盤を握る。

目的地は、無人の商業炉ではない。

人間がすべてを作らなくても、人間が最後に止められる商業炉。

そこまでの道は、まだ遠い。

だが、少なくとも進む方向は見え始めた。

さてAIたちよ。

次は、炉を大きくする前に、警報器を作ろうか。

🎙️ NotebookLM音声化ポイント

締めの問い：人間が最後に止められない自動化を、進歩と呼べるのか。

参考

• Gemini Notebook Enterprise：ノートブック管理API
• Dify：Knowledge Retrieval
• LangSmith：RAGアプリケーションの評価

（執筆協力：ChatGPT＋Gemini＋NotebookLM / 編集・監修：電脳古老）