AI版自動ブレーキ

速さは正義ではない

F1の技術革新は、ルールによって生まれてきた。

ダウンフォースが強くなりすぎれば、ダウンフォースの上限が定められた。エンジンが高回転になりすぎれば、回転数の上限が設けられた。空力の工夫が複雑すぎれば、デザインの自由度に制限が加わった。モノコックの強度が問われれば、クラッシュテストの基準が引き上げられた。

その都度、チームは「規制の中で最速を目指す」という命題に取り組んだ。そしてその制約こそが、エンジニアの創造性を引き出し、技術の密度を高めてきた。

制約は技術の敵ではない。制約は技術を洗練させる圧力である。

AIの高速化・自律化が加速する今、同じ問いが再び提起されている。速く走ってよい場所はどこで、必ず減速すべき場所はどこか。そのルールを、レース開始前に設計しておけるかどうかが問われている。

自動ブレーキが生まれた経緯

自動車に自動ブレーキ（衝突被害軽減ブレーキ、AEB）が普及した背景には、単純な技術進歩だけでなく、設計思想の転換があった。

かつての自動車設計の前提は「ドライバーが判断し、ドライバーが止める」だった。ブレーキはあくまでドライバーの指示を受けて作動するものだった。しかし現実の事故のデータは、ドライバーの反応速度には物理的な限界があること、そして衝突の多くはその限界を超えた局面で起きることを示していた。

「人間が止める」という前提が、安全設計の根拠として不十分だと分かった時、設計は変わった。一定の条件下では、システムが人間の判断を待たずに介入する。 これが自動ブレーキの本質である。

重要なのは、自動ブレーキがドライバーの能力を否定するものではない、という点だ。高速道路でも市街地でも、ドライバーは引き続き運転する。自動ブレーキが作動するのは、ドライバーの判断が間に合わない特定の局面だけだ。全体を自動化するのではなく、不可逆な事態が起きる手前の局面だけを構造的に守る──これが設計の核心だった。

AIエージェントに「自動ブレーキ」はあるか

現在のAIエージェントには、この意味での自動ブレーキがほとんど存在しない。

エージェントはプロンプトに従って動く。「このデータを削除して」と言われれば削除する。「この取引を実行して」と言われれば実行する。「このメールを全員に送って」と言われれば送る。処理が不可逆であることも、影響範囲が数万件に及ぶことも、エージェントは止まる理由にしない。

プロンプトによる指示の精緻化──「重要なデータは削除しないで」「確認を取ってから実行して」──は有効だが、それは安全装置ではない。プロンプトは意図の表明であり、構造的な歯止めではない。プロンプトを書き忘れれば、あるいは条件を書き漏らせば、歯止めは消える。プロンプトは人間の代わりに考えてくれるが、構造として止まってはくれない。

実際に起きた。2026年、AIエージェントによる本番データベースの誤削除が複数の現場で報告された（前出のPocketOS事件もその一つだ）。エージェントへの指示は明確だったが、指示の射程の外に本番環境が含まれていた。9秒で数万件のデータが消えた。ロールバックは一部にしか適用できず、残りは永久に失われた。

「エージェントに聞かせればよかった」という結論は正しい。しかし聞かせなかったことが致命傷になる設計そのものが問われていない。

構造的ブレーキの設計

自動ブレーキが「ドライバーの判断が間に合わない局面を守る」設計であるように、AIエージェントの構造的ブレーキが守るべきは「人間の確認が間に合わない局面、または確認が形骸化している局面」だ。

具体的には、次の条件が一つでも重なる操作については、AIエージェントが自律的に完結することを構造として防ぐ設計が必要になる。

これらの条件下では、エージェントは衝突予測→速度低下→人間への問い合わせ→承認後に実行→実行内容の記録というシーケンスを自律的に踏む。承認が得られなければ停止し、その判断ログを残す。

これはエージェントの「能力の制限」ではない。制約の外での失速を防ぐための、設計的な歯止めである。

「意味のある承認」という概念

ここで問われるのが、承認の質である。

現場でしばしば起きることを正直に描写しよう。AIエージェントが「この操作を実行してよいですか？」と尋ねる。担当者は確認を取ったつもりで「Yes」と押す。しかし担当者には影響範囲が見えていなかった。削除されるのが10件なのか10万件なのか、どのシステムに波及するのかが明示されていなかった。

これは承認ではない。形式的な同意である。

意味のある承認とは、影響範囲・不可逆性・代替案の有無・復旧の可否がすべて明示された状態で、判断する側がそれを理解した上で下す同意のことを指す。承認の栞（前出の栞7類型）が必要なのはまさにここだ。「承認を取った」という記録だけでなく、「何を理解した上で承認したのか」が記録されなければ、事後の検証は機能しない。

上長承認というルールが形骸化するのも、同じ理由による。上長が承認を求められたとき、提示された情報が「実行してよいですか」だけであれば、承認はゴム印になる。承認のプロセスに影響範囲の明示を組み込むことで初めて、上長承認は意思決定の機能を取り戻す。

速く走ってよい場所

ここまで読んで、「AIを遅くしたいのか」と感じた読者がいるかもしれない。そうではない。

F1のレギュレーションが全コースを徐行区間にするわけではないように、構造的ブレーキはAIエージェントの全操作に適用されるものではない。日常的な検索・要約・翻訳・文章生成・スケジュール調整──影響が可逆的で、範囲が限定的で、ユーザーが手動で取り消せる操作については、エージェントは存分に速く動いてよい。

速さが価値を生む場所がある。そしてそれとは別に、速さが取り返しのつかない結果を生む場所がある。この二つを構造として分けること──これがAI版自動ブレーキの設計思想だ。

F1において最速のドライバーとは、速く走れるだけの人物ではない。どこで全力を出し、どこで制御するかを知っている人物だ。AIエージェントの設計においても、この知性が求められている。

コーストガードとの接続

AIの速さを制御する設計は、本稿が提案するコーストガードの思想と重なる。

コーストガードは海を守るために「止める」機能を持つが、それは海そのものを封鎖するためではなく、海が汚染されたときに被害を広げないための構造だ。自動ブレーキもまた、AIの動作を止めるためではなく、不可逆な局面でのみ作動する選択的な介入機構として設計される。

共通しているのは「すべてを止めることと、すべてを通すことの間に、設計の空間がある」という認識だ。そしてその空間を埋めるのが、判断の栞・承認の栞・復旧の栞を含む記録の体系である。

記録は事後の言い訳のためにある装置ではない。記録があることで、次のブレーキの精度が上がる。どの局面で止まるべきだったか、どの承認が形骸化していたか、どの影響範囲が見えていなかったか──ブレーキの設計は走るたびに更新される。

速さと安全は対立しない。どこで止まるかを知ることが、より速く走ることを可能にする。