00:00
あのちょっと想像してみて欲しいんですけど、家の玄関に数百万もするような最新鋭のセキュリティシステムを導入したとしますよね。
はい。 顔認証も指紋認証も完璧で、でも誰かが外からドアノブをガチャガチャーって回すたびに、あなたのスマホに中に入れますかっていうポップアップ通知が来るんです。
それはちょっとかなり面倒ですね。 そうですよね。最初は真面目にカメラの映像を確認していても、1日に何十回もそれがなったらどうなるか。
そのうち中身も見ずに、はいを連打するようになっちゃうじゃないですか。 間違いなくそうなると思います。
実はですね、これって私たちが今最先端のAIエージェントに対してやってしまっていることと全く同じなんですよ。
なるほど。いわゆる承認疲れの問題ですね。実はそれに関してすごく衝撃的なデータがあるんです。93%。これ何の数字だかわかりますか?
93%。何かの承認率ですか?
その通りです。これはアンスロピックのクロードコードの自動モードに関するデータなんですが、
AIからの権限要求に対してユーザーがなんと93%の確率でそのまま承認ボタンを押してしまっているという現実があるんです。
93%。ほぼスト通りじゃないですか?
ええ。これほどまでに人間は繰り返される確認作業、つまり承認疲れに弱いんですよね。
どんなに強固なセキュリティシステムを作ったつもりでも、最終的な決定権を持つ人間の認知的な限界を超えてしまったら、もうシステムとしては完全に機能不全に陥っているのと同じなんです。
確かに。ということで、今回の深掘りではこの承認疲れという恐ろしい落とし穴からどうやって抜け出すのかを解き明かしていきたいと思います。
はい、よろしくお願いします。
ベースにする情報源は、AIエージェント日地速報2026年7月30日版のデータと分析です。
今の時代、AIがどれくらい賢いかとか、何ができるかっていう議論のフェーズはもう終わりましたよね?
ええ、そうですね。もう十分すぎるほど賢いですから。
ですよね。なので、今日私たちがミッションとして掲げたいのは、AIの権限、つまり何をさせていいかをどうコントロールするかっていう部分なんです。
有能なAIに白紙の委任状を渡しちゃって第三児を引き起こす前に、どうやって安全な手綱の握り方を見つけるか、ここを徹底的に掘り下げていきましょう。
はい。AIモデルの知能が上がれば上がるほど、皮肉なことに実務で最初に発生する事故っていうのは、賢すぎるがゆえの暴走になるんですよね。
賢すぎるがゆえの暴走。
ええ。例えば、頼んでいないファイルを勝手に書き換えちゃったりとか、関係ない部署のメーリングリストに突然メールを送信したりとか。
うわあ、それは生きた心地がしないですね。
ですよね。でもこれらはAIが愚かだから起きるわけじゃないんです。システム側がAIに対して、ここは読んでいい場所、ここは書いていい場所、そしてこれは外部へ送信していい情報なのかっていう物理的な境界線をちゃんと引けていないから起きる構造的な欠陥なんですよ。
03:04
なるほど。AIの問題じゃなくて人間の側の管理の枠組みの問題だと。
そこで先ほどの93%っていう数字に戻るんですけど、これって確認のポップアップの数が増えれば増えるほど、私たちの確認の質が劇的に下がるっていう矛盾を抱えてますよね。
その通りです。毎回これを実行していいですかって聞かれると、最初はこのコードの変更ならOKだなって中身を精査していても、5回目づらいでどうせさっきの作業の続きでしょって思い込んじゃう。
ええ、人間の脳ってそういう繰り返される刺激に対して注意力を節約するようにできているんですよね。
だからこそ先ほど少し触れたクロードコードなんかはファイルシステムとかレッドワークの境界線を先に決めておくというアプローチをとっています。
先に決めておく、つまり後から都度聞くのやめたってことですか。
そうです。いわゆるサンドボックス環境と呼ばれるものですね。
AIが自由に動ける安全な箱を物理的に構築しちゃうんです。その中であれば、いちいち人間に許可を求めずにAIが自律的に動けるようにする。
ああ、なるほど。
毎回の細かい許可をなくす代わりに、許可をまとめて出して良い範囲自体を狭くそして固く定義し直しているわけです。
確かに、それなら箱の中では全速力で走っていいよって言えますね。でもそれだとその箱の大きさをどうやって決めるかっていう新たな問題が出てきませんか。
と言いますと?
いや、なんかこのAIモデルにはこのくらいの箱を用意しようみたいに、AIの優秀さごとに権限を決めていたら、新しいAIが出る度に毎回設定を作り直さないといけないじゃないですか。それって結構面倒だなと。
ああ、素晴らしい視点です。そこでパラダイムシフトが必要になるんです。権限の基準をどのAIを使うかではなくて、何をするかに切り替えるんですよ。
何をするかですか?
はい。オープンAIのコーデックスCLIの設計思想がまさにそれを体現していまして、コーデックスにはサジェスト、つまり提案ですね。それからオートエディット、自動編集、そしてフルオート、完全自動、この3つのモードが用意されているんです。
ほほう。つまり、AIに対する権限が全権委任かゼロかの極端な二択じゃなくてグラデーションになっているということですね。
その通りです。そして重要なのは、そのグラデーションをタスクの性質に紐づけているという点なんです。
タスクの性質。
ええ。例えば、公開されているAPIの仕様を調べるだけの調査タスクだったとします。その場合、AIがどれほど優秀でも一番下のサジェストモードに留めて、読み取り権限しか与えないんです。
なるほど。調べるだけなんだから書き込む権限はいらないだろうと。
そういうことです。逆に、完全にネットワークから隔離されたローカルのテスト環境でひたすらバグ修正を行わせるような場合は、一番上のフルオートにして全権を委任する。
つまり、優秀なAIだから何でも許可するというわけではなくて、その作業のリスクに応じて自動化レベルを意図的に上下させるという仕組みなんです。
06:08
いやー、それは合理的ですね。Aという超優秀なAIだからとりあえず全部任せちゃえみたいな雑な設定による大事故は、それで確実に防げそうです。
はい。かなりリスクは減らせます。
でも、ちょっと意地悪な聞き方をしちゃうんですけど、タスクごとに権限を切り替えるとして、そもそも私たち人間の判断自体が適当になっちゃうときってありませんか?
適当になるとは?
なんか、このタスク多分外部通信はしないはずだから、面倒だしフロートで許可しちゃえみたいな。
そういう人間の曖昧な判断をAIが真に受けてしまったら、いくらグラデーションを作ってもすり抜けられちゃうんじゃないかなって。
いや、まさにそこなんですよ。その人間の曖昧さこそが最大の脆弱性なんです。
やっぱりそうですか?
人間の多分大丈夫だろうという推測とか、あるいはAI側のこの作業の延長線上だから気を利かせてやってしまおうという文脈の拡大解釈ですね。
これをシステム的に防ぐには、何をしていいかを決める前に、何をしてはいけないかをシステムレベルでハードコード、つまりガチガチに固定しておく必要があるんです。
何をしてはいけないかを先に決める。
Googleのアンティグラビティというシステムがこの課題に対して非常に明確な答えを出しています。
アンティグラビティですか?それはどうやってその解釈のブレを防ぎているんですか?
彼らは権限の評価を3つのリストで管理しています。
ディナイ、つまり拒否、それからアスク、確認、そして洗う、許可。この3段構えですね。
拒否、確認、許可ですね。
はい。ここで絶対的なルールとして機能するのが、もしこの3つの条件が競合した場合、システムは必ずディナイ、アスク、洗うの順番で評価を下すという点なんです。
えーと、ちょっと待ってくださいね。
それってつまり、AIが前後の文脈からこれは許可されている、洗うの作業の一部だって勝手に判断して実行しようとしても、その操作自体がディナイリストに入っていたら問答無用でブロックされるっていうことですか?
その通りです。AIの高度な推論能力とか、あるいは人間が過去に曖昧に出してしまった承認履歴よりも、システムのディナイリストが最優先されるんです。
なるほど。絶対にダメなものはダメだと。
ええ。例えば、データベースの削除とか、本番環境への公開、経費の支払い、認証情報の変更、こういった人間が画面で直接確認するまで絶対に動かしてはいけない操作を、まず最初にディナイリストとして定義しておくんです。
確かにそこをやっておかないと怖いですね。
はい。これをやらない限り、どんなに洗うリストを細かく設定したところで、AIの解釈の飛躍によって簡単に突破されてしまいますから。
AIが便利になればなるほど、実はブレーキの性能の方が重要になってくるんですね。
09:01
本当にそうなんです。もしこのディナイ優先の原則を無視するとどうなるのかって考えると、手元の資料にあるハルメスエイジェントの事例を見ると、ちょっと背筋がこわりますよね。
これ、外部のメッセージツール経由でAIに指示を出すシステムですよね。
ええ、スラックとかディスコードみたいな普段使っているチャットツールからAIに指示を出して、裏側にあるホストマシンのOSでそのままコマンドを実行させるっていう仕組みですね。
それってすごく便利そうですけど。
便利ですが、同時に構造的な恐怖をはらんでいます。
チャットという極めてカジュアルなインターフェースとシステムの中枢である実行権限の距離があまりにも近すぎるんですよ。
これ、資料を読みながら思ったんですけど、なんか電話に出るのが愛想良くて上手だからといって、オフィスの受付係にミサイルの発射コードを持たせているようなものですよね。
まさにそんな感じです。非常にわかりやすい例えですね。
もし、悪意のある誰かがチャットでAIを騙したりとか、あるいはAI自身が言葉のニュアンスを勘違いしちゃったら、そのままサーバーが初期化されかねないじゃないですか。
だからこそ、その危険性を排除するために、ハーメスエージェントのリポジトリでは、実行前の入り口を絞る順番をの厳格に定めているんです。
入り口を絞る順番。
はい。まず第一に、誰がその指示を出したのか、DMのペアリングで支持者を物理的に特定します。
次に、AIが生成したOSコマンドをそのまま実行するのではなくて、必ず人間が承認するプロセスを間に挟む。
ここで一度ストップをかけるわけですね。
ええ。そしてさらに、万が一危険なコマンドがそこを通り抜けてしまった場合に備えて、本体のOSから完全に切り離されたコンテナ環境の中だけでAIを動かすんです。
コンテナ環境で動かす。つまり、AIには今本物のOSを操作してますよって思い込ませつつ、実際には隔離された偽物の環境を与えておくわけですね。
そういうことです。
これなら、仮にさっきの受付係が発射コードを打ち込んじゃっても、おもちゃのミサイルしか飛ばないわけだ。
入り口で支持者を絞って、途中で確認を挟んで、最後は実行環境ごと隔離する。
この多層的な防御があって初めて、外部ツールからの操作っていうのが安全に成立するんですね。
ええ、おっしゃる通りです。しかしですね、ここでまた新たな壁にぶつかるんです。
え、また壁があるんですか。
はい。仮にディナイリストを作り、実行環境を隔離して、安全に作業できる枠組みが完成したとしましょう。
そうなると、次にあなたがAIに頼みたくなるのは、ファイルを1個作って、みたいな単発の作業ではなくなるはずです。
ああ、もっと大きな仕事をお願いしたくなりますね。
ですよね。この新製品の市場調査をして、レポートにまとめて、明日のプレゼン資料を作成しておいていっていったような複雑で長期的なプロジェクト全体になるはずなんです。
確かに。でもそうなると、一番最初に話した承認疲れの問題が、全く別の形で復活しちゃいませんか。
その通りです。
12:00
安全のために細かい確認プロセスを挟んでいたら、AIがレポートを作る過程で、検索していいですか、データを抽出していいですか、グラフを描いていいですかって、もう数秒おきにポップアップが出てきて、こっちの仕事になりませんよね。
これ、どうやって効率よく監督すればいいんでしょうか。
そこで、人間が確認する対象の抽象度を意図的に引き上げるというアプローチが登場するんです。
マヌースというAIエージェントのプランモード、プランモードですね。これがその代表例です。
マヌースのプランモード。
はい。マヌースはユーザーから指示を受けても、すぐにブラウザを開いたりコードを書き始めたりはしません。まず一番初めに作業の全体計画を立案するんです。
全体計画ですか。
ええ。どのサイトを見て、どのデータをつなぎ合わせて、最終的にどんな形式で出力するか、その実現可能性を含めたブループリント、設計図ですね。これを先に人間に提示するんです。
そして、人間がその計画自体を承認して初めて実際の物理的な操作を開始します。
なるほど。細切れのツールの呼び出しをいちいち確認するんじゃなくて、最初の設計図の段階で、このルートで進むなら、変なところに寄り道場しないなっていう合意を取っちゃうわけですね。
まさにそういうことです。
これなら途中で出てくる確認ポップアップの数を劇的に減らせますね。なんかAIの歩みを遅くしているように見えて、実はマクロな視点での承認を一度で済ませるためのすごく合理的な仕組みなんですね。
ええ。そしてこれがさらに複雑になってくると、Jenspark AI Workspace 6.0のようなシステムに行き着きます。これは単一のAIモデルではなくて、複数のモデルが共同するシステムなんです。
複数のモデルが一緒に働くんですか?
はい。驚くべきことに、Jensparkは一つのタスクをこなすために、なんと70以上の異なるモデルを使い分けているんです。
70ですか。それはすごい数ですね。
ええ。過去の情報を保持するセカンドブレインという記憶の層、複雑な推論を行うスーパーエージェントという処理の層、実際のツールを動かすスイートという作業の層、そしてそれらを連携させるジェンティームという共同の層。
役割が完全に分かれているんですね。
そうなんです。これだけ多くのモデルが裏柄で動いているシステムにおいて、どのモデルにどの権限を与えるかを人間がいちいち管理するなんて、もはや不可能です。
ああ、ここでさっきのAIごとじゃなくて、タスクや役割ごとに権限を変えるという話が聞いてくるわけですね。
そういうことです。
これ、レストランの厨房をイメージするとすごくしっくりきますね。
厨房のスタッフですか?
AIを何でもできる一つの人格として捉えるんじゃなくて、専門職が集まった厨房のスタッフとして考えるんです。
面白いですね。もう少し詳しく教えてもらえますか?
例えば、調査役という下ごしらえのスタッフには、外から買ってきた食材、つまりインターネット上の公開情報にだけアクセスさせる。
次に、要役役というメインの調理スタッフには、お店の秘伝のレシピ、つまり社内の機密データベースへのアクセス権を渡す。
15:06
そして、実行役という配膳スタッフには、出来上がった料理をお皿に盛り付ける、つまりファイルの編集権限を持たせる。
でも、どのスタッフであっても、完成した料理を勝手にお店の外へ出前しちゃうような外部への公開権限は絶対に持たせない。
こうやってデータの動線を物理的に切り離せば、裏で70個のモデルが動いていても安全に制御できるんじゃないですか。
いやー見事なアナロジーです。まさにその、データの動線を切り離すという設計が、複雑なAIエージェント群を安全に運用するためのようなんですよ。
やっぱりそうなんですね。
どのAIモデルがどう答えるかではなくて、どの役割に、どのデータへのアクセスパスをつなぐか、モデルの数を増やす前に、役割ごとの入力と出力の境界を物理的に分離しておかなければ、一つのモデルの幻覚、いわゆるハルシネーションが、システム全体に波及してしまいますから。
厨房のオペレーションが完璧に設計できたら、すごく安心ですね。でもちょっと一つ不安なことがありまして。
何でしょう。
明日になったらどうなるのかっていう問題なんです。
今日チャットでAIに、この機密ファイルは読まないでねってルールを決めて、AIも分かりましたって答えたとしますよね。
はい。
でもそれってあくまでそのチャットの会話の文脈の中での話じゃないですか。
ブラウザを閉じたりとか、翌日全く別のタスクを頼んだりしたとき、AIはそのルールをちゃんと覚えていてくれるんでしょうか。
いやそこがですね、継続的なAI運用における最大の盲点なんです。
やっぱり忘れちゃいますか。
はい。ルールを会話の文脈、つまりコンテクストに依存させてしまうと、チャットの履歴が流れたり、別のプラグインを呼び出した瞬間に、その制限は簡単に消滅してしまうんです。
うわー、それは困りますね。
昨日1回だけ許可した操作を、AIが今日も許可されていると勘違いして、別のタスクで勝手に実行してしまう事故っていうのが本当に後立たないんですよ。
会話の記憶は、揮発性が高いから、セキュリティの担保にはならないっていうことですね。
だたらこそ、オープンクローというシステムの、オープンクローエクセクポリシーのような仕組みが不可欠になるんです。
エクセクポリシー、それはどういう仕組みなんですか。
国立に保存し、システム全体と同期させるアプローチなんです。
つまり、AIが何か行動を起こす前に、必ずその物理的なルールブックである設定ファイルを読みに行かせる仕組みですね。
その通りです。
自然言語の曖昧な記憶じゃなくて、コードとして書かれた絶対的なポリシーを毎回チェックさせる。
これなら、会話の文脈が途切れてもルールは永続化されるわけだ。
AIの推論を司るLLMが処理を行うよりも前に、決定論的なコードによって権限のチェックを行う。
18:02
この順序を守ることで、AIがどれほど巧みな言い回しでルールを迂回しようとしても、システムが物理的にシャットアウトできるわけです。
だいぶ全体像が見えてきました。
今日私たちが話してきたサンドボックスの話とか、出ないリストの優先、全体計画の承認、役割の分離、そして今のルールの永続化。
これらをすべて踏まえた上で、明日皆さんが職場でAIに仕事を頼むとき、具体的にどう動けばいいのか。
今回の資料の最後に非常に実践的な4つの分割というフレームワークが提示されています。
権限をただのオン・オフじゃなくて、次の4つのステップに切り分けて考えるんですよね。
ちょっと読み上げますね。
お願いします。
まず1つ目は、読む、リード。
どのホルダー、どのサイトの情報を参照していいのか。
2つ目は、変える、チェンジ。
既存のファイルのどの範囲までなら編集していいのか。
3つ目は、実行する、エグゼキュート。
スクリプトを回したり、ブラウザを操作したりといったシステムを動かす行為を許すか。
そして最後4つ目が、出す、アウトプット。
メールの送信、ウェブへの公開、API経由での購入、あるいはデータの削除など、外側に影響を与えるアクションを起こしていいのか。
この4つですね。
ええ。そして、この4つの境界線の中で、私たちが絶対に支手しなければならないのが、最後の出す、アウトプットのラインなんです。
一番最後の部分ですね。
はい。前の3つ。つまり、読み取り、編集、実行の段階で、仮にAIが失敗したとしても、それはローカル環境やバージョン管理システムの中でいくらでも元に戻せます。
しかし、外に出すこと、あるいは消し去ることだけは不可逆なんです。
取り返しがつかないと。
そうです。極端な話、この出す操作の直前にだけは必ず人間が介入する、という一点ルールを設けるだけでも、AI導入の安全性は劇的に引き上げられます。
なるほど。単に情報を読んでまとめるだけのタスクなのに、変えるとか出すの権限までなんとなく許可してしまうのが一番危ないんですね。
まさにその通りです。
失敗してもすぐ元に戻せる範囲だけをAIの自立性に任せて、取り返しのつかない境界線には人間の承認という強固なゲートを置く。これが今回の最大の学びですね。
え?
AIを使いこなすための本当の鍵は、アクセルの踏み込み方じゃなくて、ブレーキの性能とそれを踏むタイミングにあると。
皆さんも明日、AIに何か仕事を丸投げしたくなった時、実行ボタンを押す前にこう問いかけてみてください。
あなたは今、何を読めて、何を変えられて、何を外へ出せますか?と。
もしAIの答えが曖昧だったり、あなたの意図を超えた広範囲な権限を持っていたら、それは間違いなく任せすぎのサインです。
そうですね。最後に、今日議論してきた枠組みを少し俯瞰した視点から捉え直してみたいと思います。
21:00
お、なんでしょうか。
私たちは今、AIに対して完璧なディナイリストを作り、4つの境界線を厳格に感じしようと努力しています。
もし、近い将来、これらの権限ポリシーの設計が完全に自動化されて、人間が完全に、そして安全にAIをコントロールできるようになったとしたら、
その時、私たち人間の仕事は一体何になっているのでしょうか?
人間の仕事ですか?
ええ。自村の手を動かして何かを生み出す作業は全てAIが担い、人間の役割は、有能すぎるAIに対する完璧な禁止事項のルールをひたすら出筆し続けることにすり替わってしまうのではないでしょうか。
うわあ、それは。
これは単なる技術的な課題にとどまらず、私たちが今後、働くという行為にどう意味を見出すのかという根源的な問いでもあります。
これを聞いているあなたは、優秀なAIに指示を出す管理者として生きる準備はできていますか?それとも、ルールを書くだけの存在になることに抵抗を感じますか?
なんだか、SF映画に出てくる管理社会が、AIの暴走によってじゃなくて、完璧なルールの記述によって完成してしまうような、少しゾッとする問いですね。
私たちがAIを使っているのか、それとも、AIが安全に動くためのルール作りに私たちが使われているのか、その境界線すら今後どんどん曖昧になっていくのかもしれません。
でも、だからこそ、今日お話ししたような、システムの裏側で何が起きているのかとか、なぜ権限を分ける必要があるのかっていう仕組みの理解が、波に飲まれないための唯一のライフジャケットになるはずです。
それでは、今回の徹底解説はこの辺りで、次回もあなたの知的好奇心を刺激するテーマでお会いしましょう。
