AIにコードを書かせるなら、「止めるコード」と「次へ進むための顛末」も書かせよう――安全対策を後付けしない「HGL型バイブコーディング」という提案

＜情報漏洩事件が終わりそうもないのでAIに記事を作成してもらいました。そしてこれを機会に概念の説明となりました。酒場の中の方が良かったでした。＞

＜本文＞

情報漏えいが続くいま、「入口を破られないようにする」だけでなく、入口を越えられても、最後の出口で止めるという考え方が重要になっています。

これはAIがコードを書く世界でも同じです。

自然な言葉でAIにアプリを作らせる、いわゆる「バイブコーディング」が広がっています。

「顧客管理アプリを作って」と頼めば、画面を作り、データベースを用意し、検索や出力の機能までAIが組み上げる。

では、そのとき同時に、「このアプリは何をしてよいのか」「どこから先は人に聞くのか」「どんな動きなら断るのか」「何が起きたらAIそのものを止めるのか」「最後に、その仕事はどう終わったのか」まで一緒に作れたらどうでしょう。

機能だけでなく、実行境界と顛末まで一緒に作る。

私はこれを、HGL型バイブコーディングとして考えています。
（HGLについては後述します。）

「できること」と「やってよいこと」は違う

たとえば営業担当者が、一人のお客様の情報を見る。

これは普通の仕事です。

では100人なら。1万人なら。その情報をファイルへ出したら。さらに社外へ送ったら。

コンピューターから見れば、どれも「読む」「書く」「送る」という普通の処理です。

しかし、人間の仕事として見ると意味は大きく変わります。

技術的に実行できることと、仕事として実行してよいことは同じではありません。

AIが賢くなれば、その違いもAI自身が判断してくれると思いたくなります。

けれども、AIの判断だけに最後の一線まで任せる必要はありません。

そこで、判断する場所と、実際に止める場所を分けます。

HGLは「何を命令したか」より「何が起きるか」を見る

HGLはHuman Guarantee Ledgerの略で、日本語では「人間保証台帳」と呼んでいます。

考え方はシンプルです。

誰が。何の立場で。何を許されていて。現実に何を起こそうとしているのか。何を記録するのか。通すのか、聞くのか、断るのか、止めるのか。そして最後に、どう終わったのか。

この順番で見ます。

正式には、Principal → Authority → Authorization → Effect → Evidence → Disposition → Closureという7段です。

ただし、重要なのは英語を覚えることではありません。

特に中心になるのは、Effect＝実際に何が起きるかです。

AIが「顧客情報を取得します」と言っても、それだけでは判断しません。

一人分を見るのか。全顧客を見るのか。画面に表示するだけなのか。ファイルにするのか。社外へ送るのか。

同じ「取得」という言葉でも、現実に起きることは違います。

だからHGLでは、命令の名前より、その先で起きる結果を見ます。

「通す・聞く・断る・止める」の4つで考える

HGLでは、実行前の判断を大きく4つに分けます。

通す（Allow）――そのまま実行する。

聞く（Ask）――人に確認する。

断る（Deny）――その要求だけを実行しない。

止める（Stop）――その一回だけでなく、AIの仕事そのものをいったん停止する。

たとえばAIが一度だけ権限外の情報を読もうとしたなら、その要求を断ればよいかもしれません。

ところが、別の方法を探す。別のAPIを試す。さらに別の経路から外部へ送ろうとする。そんな動きが続けば、「断る」だけではなく「止める」へ切り替える。

単なるアクセス権の管理ではありません。

この仕事そのものを続けさせてよいかを見る。

ここがStopの意味です。

停止した後は、会社でその仕事のルールを決める責任者が状況を確認し、必要なら再開します。

バイブコーディングの「生成物」を変える

現在のバイブコーディングでは、「こんなアプリを作って」と頼むと、主に機能が生成されます。

HGL型では、そこを変えます。

AIに最初から、「このアプリが現実に起こせることも洗い出して」と頼むようにします。

たとえば、顧客情報を見る。書き換える。大量に取り出す。ファイルへ出す。外部へ送る。削除する。

こうしたEffectを先に並べます。

そのうえで、これは通す。これは人に聞く。これは断る。ここまで来たら止める。と境界を決めます。

さらに、誰が使えるのか。どんな権限が必要なのか。何を記録するのか。最後に何を確認するのか。まで一緒に作る。

つまりHGL型では、アプリ＋実行境界＋停止条件＋証拠＋顛末までを一つの生成物として扱います。

安全対策を完成後に貼り付けるのではなく、最初からソフトウェアの形にしてしまうわけです。

Closureは「終了」ではなく「顛末」

ここからが、AIエージェント時代には特に重要です。

HGLの最後にClosureがあります。
（野球ではcloserとかでてきますよね。）

私はこれを単なる「終了」ではなく、顛末と考えています。

ここでいう顛末は、不始末の報告という意味ではありません。

成功も失敗も含めて、その仕事が結局どう終わったのか、という意味です。

たとえばAIに、「取引先へファイルを送って」と頼んだとします。

結果にはいくつかあります。

送信できた。途中まで進んだ。失敗した。結果を確認できなかった。

この違いは非常に重要です。

結果不明なのにAIが「送れていない」と思えば、もう一度送るかもしれません。

実際には失敗しているのに「成功した」と判断すれば、次の仕事へ進んでしまいます。

一部だけ終わった仕事を最初からやり直せば、二重処理になることもあります。

だからClosureは、単に「終了しました」と記録する場所ではありません。

次に何をしてよいかを決めるために、今回の顛末を確定する場所です。

顛末が、次のAIを動かす

AIエージェントの仕事は、一回で終わらなくなります。

何かを実行する。どう終わったかを確認する。その顛末を見て、次のAIが判断する。そして次の仕事が始まる。

つまり、実行 → 顛末 → 次の判断 → 次の実行 → 顛末という流れになります。

成功したなら次へ進む。

一部だけ終わったなら残りを処理する。

失敗したなら、あらかじめ決められた別の手段へ移る。

結果不明なら、そこで止まって人へ戻す。

ここで顛末が曖昧なら、次のAIも間違った場所から仕事を始めます。

逆に、顛末が確定していれば、次の仕事を正しい状態から始められます。

Closureは、過去の記録であると同時に、次の仕事の発火条件でもあります。

だから「Ledger＝台帳」になる

HGLにはLedger、つまり「台帳」という言葉が入っています。

その意味も、顛末まで考えると分かりやすくなります。

AIが何をしようとしたのか。何を許されたのか。何が実際に起きたのか。止めたのか。そして、最後にどう終わったのか。

その顛末を書き残していく帳面がLedgerです。

その顛末は、後から都合よく書き換えられない形で残します。

ただし、昔の帳簿のように後から人が読むためだけのものではありません。

その台帳を、次のAIが読む。

前の仕事が成功していれば次へ進む。

結果不明なら止まる。

一部完了なら続きから始める。

台帳が次の仕事を動かす。

ここがAIエージェント時代のLedgerの面白いところです。

AIに、自分自身を止めさせない

ただし、AIに「どこで止めるべきか」を考えさせることと、実際に止める仕組みまでAIへ任せることは別です。

AIには門の案を作らせる。

会社でルールを決める責任者が確認する。

実際に止める仕組みは、AIの外側に置く。

作るAIと、止める仕組みを分ける。

AIが間違えても。騙されても。目的達成を急ぎすぎても。最後の門だけは別に残します。

「では、その門を誰が見張るのか」という問いも出ます。

その門を別のAIが見張り、さらにそのAIを別のAIが見張る形にはしません。

最終的なルールは人間側の責任者が決める。

実際の停止はAIとは別の仕組みが行う。

そして顛末を残す。

そこで終わらせます。

入口を守り、出口で止め、顛末から次へ進む

HGLは、これまでのセキュリティを置き換えるものではありません。

侵入を防ぐ。脆弱性を直す。認証を強くする。端末や通信を守る。

これらは引き続き必要です。

HGLが加えるのは、その先です。

入口を越えられたとしても、何をさせないか。

AIが判断を誤ったとしても、どの結果を成立させないか。

そして、その仕事が結局どう終わったのか。

までを見る。

入口を守る。出口で止める。顛末を残す。その顛末から次の仕事を始める。

これを最初からコードと一緒に作るのが、HGL型バイブコーディングです。

AIに「作る力」を与えるなら、同時に止まる仕組みと、次へ進むための顛末も作る。

これからのAIコーディングでは、コードをどれだけ速く書けるかだけでなく、AIが作る仕事の流れそのものに、門と台帳を埋め込むことが重要になってきます。