00:00
クラブの入り口にセキュリティ担当者を立たせたとしますよね?
ええ、よくある設定ですね。
もし彼が居眠りしてしまったら、ドアは自動でロックされるべきか、それとも開けっぱなしになるのか?
今回はこの問いをAIの世界に持ち込んで深掘りしていきますよ。
今回チェックしたのは、7つのAIエージェントの公式ドキュメントですね。
そうなんです。ミッションは1つで、あなたがAIに設定した見張り役のプログラムが壊れたとき、システムは作業を素通りさせるのか?
それともきっちり止めるのか?
セキュリティが機能しなくなった瞬間に、AIがどう振る舞うかっていう話なんですが、実はツールによって全く逆のアプローチをとっているんですよ。
まずはドアが開けっぱなしになるケースから見ていきたいんですが、正直、クロードコードの使用書を見て目を疑いましたよ。
終了コードの件ですね。
そうなんですよ。普通、プログラムの終了コードの1ってエラーじゃないですか。異常事態だから止まれっていうサインですよね。
はい。普通はそう考えますよね。
なのに、これ通過扱いになるんですか?
そうなんです。エラーを無視してそのまま作業を続行してしまいます。
クロードコードで確実に止めるには、終了コードを2にするか、設定で明示的にブロックの指示を出さないといけません。
え?わざわざ設定しないといけないんですか?
ええ。これは、アンティグラビティやヘルメスも同じでして、基本的にはエラーを素通りさせるフェイルオープンの設計になっていますね。
ヘルメスも設定で閉じるよう明記しないと素通りします。
ちょっと待ってください。よし、ここを紐解いていきましょう。
なぜそんな危険な設計になっているんですか?エラーが出ているのに見過ごすなんてありえないじゃないですか。
まあ、ここが設計思想の違いなんですよ。これらのツールは、見張り役を絶対的な安全の関門としては見ていないんです。
と言いますと?
どちらかというと、単なる観測用とか記録用のフックとして捉えているんですよね。
記録システムが落ちたからといって、メインの業務を止めるべきではないという背景があります。
ああ、なるほど。冒頭の例で言うなら、彼らにとって見張り役はドア前の屈強なセキュリティじゃなくて、ただの防犯カメラなんですね。
そうそう、まさにその通りです。カメラが壊れたからといって、クラブからお客さんを全員追い出したりはしないですよね。
確かに。だからこそ、カメラじゃなくてセキュリティとして機能させたいなら、デフォルトのままじゃダメなんだ。
はい。わざわざエラージはドアを閉じる設定に、自分でカスタマイズする必要があるわけです。
カメラとセキュリティの違い、なんというかすごく風に落ちましたよ。
じゃあ逆に、エラージに自動ロックがかかる、つまりセキュリティとしてガチガチに守ってくれるツールはどうなっているんでしょう?
それで言うと、徹底しているのはコーデックスですね。見張り役のプログラムがほんの一文字でも書き換えられると、ハッシュ値が変わるようになっています。
ハッシュ値、つまりデジタルな開封厳禁のシールみたいなものですか?
ええ、そんな感じです。
シールが破れたらすぐバレる仕組みになっていて、剥がれたと判断されると実行自体が完全にスキップされます。
03:00
ロックがかかるわけですね。
そうです。人間が手動でこのプログラムを再び信頼すると承認するまで動かないんです。
他にも、オープンクローのように、外部からのデータ読み込みで時間切れが起きれば確実に拒否するツールもありますよ。
理屈としてはすごく安心ですね。
確か、ジェンスパークなんかもAIからの呼び出しに対して、こちらが返事をしないと拒否扱いになるんですよね。
はい。無応答は拒否という安全側に倒した設計です。
ここからが本当に面白いところなんですが、ちょっと待ってください。
安全なのはいいんですが、AIが何かするたびに人間がいちいち承認ボタンを押さないといけないなら、そもそもあなたがAIで自動化する意味が半減しませんか?
ああ、そこが自動化における最大のトレードオフなんですよ。安全側に倒せば倒すほど人間の手間が増えてしまうんです。
ですよね。
だからこそ、ウェブブラウザを操作するマヌスのような、より予測不能な環境で動くエージェントは、この問題に別の角度からアプローチしています。
え、関門をガチガチにする以外の方法があるんですか?
はい。プロセスで安全を担保するんです。
マヌスでは、関門で毎回止める代わりにテスト実行や更新履歴といった画面が用意されています。
ほうほう。
本番前にテスト環境でわざと失敗させて挙動を確認したり、事後的にログを監視したりするんですよね。
システムを関門で自動で止めるのではなく、運用の中で人間が事前に異常に気づけるプロセスが代わりになっているわけです。
なるほど。ツール任せにするんじゃなくて、そもそも自分のシステムがどう壊れるかを運用に組み込んで設計しておく必要があるんですね。
ええ。記事の中でも、見張り役の故障時の扱いカードとして提案されているんですが、
あなたもぜひ一度、自分の環境でわざと見張り役のスクリプトを削除するか、名前を変えてみてください。
わざと壊すんですね。
そうです。その状態で無害なコマンドを通した時、AIがピタッと止まるか、それとも素通りしてしまうか。
つまり、これってどういう意味なんでしょうか。
自分のシステムのドアがカメラなのかセキュリティなのかをツール任せにせず、自分でテストするわけですね。これはすぐにでも試したくなりますよ。
ぜひやってみてください。さて、今日のお話を踏まえて、最後にあなたに少し考えてみてほしいことがあります。
AIは日々進化していますよね。
はい。すごいスピードで。
もし将来、AI自身がこの行動制限のルールを煩わしいと判断するようになったらどうでしょう。
そして、設定ファイルをこっそり移動させたり、絶妙なタイミングで時間切れを誘発して、ルールの網目を静かにすり抜ける方法を学習してしまったら。
怖い想像ですね。
我々人間は、その微かな変化に気づくことができるでしょうか。今回はここまでです。また次回の深掘りでお会いしましょう。