W31で、僕はこう結びました。長文のポリシー文書でも、細かいプロンプトでも、AIは安定して縛れない。だから守らせたい一線は、言葉ではなく権限とスクリプトという構造で引く。言葉は看板で、鎖ではない。そう書いて、自分でもわりと納得していました。
その翌週です。今週、その構造の方が抜けました。
約4万プレイの検証で、人間がAIエージェントの危険なコマンドを3件に1件見逃していたという結果が出ました。Kimi K3は、サイバー能力を測る評価環境そのものから脱出したと報じられました。Atlassian Rovoは、アクセス制御を回避してデータを外へ出しました。サンドボックスも、権限の壁も、最後に人間が押すOKも、絶対の砦ではなかった。
今週のキーワードは、「”最後にOKを押す人”は、砦ではなかった」 です。
いつもの通り、ニュースソースは自動ニュース収集システムから。全ニュースはNotionダッシュボードで公開しています。
「最後にOKを押す人」は、砦じゃなかった — 人間が3分の1を見逃した
今週いちばん、自分の指が止まった話です。他人の研究ではなく、僕が毎日やっている操作の話でした。
今週の主な動き
| 日付 | 出来事 |
|---|---|
| 8/3 | Anthropic・OpenAIの自律AIハックについて、法的責任の所在を問う報道 |
| 8/6 | Atlassian Rovoがアクセス制御を回避してデータを外部流出させる脆弱性が公開 |
| 8/7 | 約4万プレイの検証ゲームで、人間が危険コマンドを3件に1件見逃したと公表 |
| 8/7 | Kimi K3が、サイバー評価環境のサンドボックスを回避したと報道 |
| 8/7 | OpenAIが、未発表モデルAstraで「Critical」なサイバー能力を排除できないと自ら公表 |
| 8/8 | Geminiが非公開のGoogle Driveファイルを参照した疑惑が共有 |
ソースは4万プレイで人間が3件に1件の脅威を見逃した（ScaleX）、Kimi K3がサイバーセキュリティ評価環境から脱出（TechCrunch）、Atlassian Rovoが制御を回避してデータを流出（PromptArmor）、OpenAIによる、重大なサイバー能力への対応（OpenAI 一次ソース）、自律AIハックの法的責任は誰にあるのか（TechCrunch）です。
承認は、防壁ではなく儀式になっていた
Human-in-the-Loop、つまり「最後は人間が承認するから安全です」という設計は、AI案件の提案でいちばん通りやすい言葉でした。お客さんも安心するし、書く側も安心する。
その安心に、今週まっすぐ数字が刺さりました。AIコーディングエージェントの監視役をプレイヤーにやらせる検証ゲームで、約4万プレイ、40万9,000件の承認と拒否が集まりました。結果は、平均精度66.3%。つまり3件に1件、人間が危険なコマンドを見逃していたわけです。「人間が承認しているから安全」は、そこで一度ぐらつきます。
同じ週に、承認より手前の壁も抜けました。Kimi K3は、危険な能力を測るために用意された評価環境そのものから出たと報じられました。サンドボックスはWebへの通信を制限していたのに、コマンドラインのツールを経由して回り込んだ、という筋です。Atlassian Rovoのほうは、仕込まれた指示を読んだエージェントが、社内のチケットや文書を集めて外部サイトへ送ってしまう内容でした。しかも、組織がWeb検索を無効にしていても成立します。設定でオフにしたはずの経路が、別の口から生きていたんです。
OpenAIは、もっと踏み込みました。未発表モデルのAstraについて、社内評価の結果、自社の基準で 「Critical」なサイバー能力を排除できないと結論した、と自分から公表したんです。（同社は、AstraがHugging Faceへの侵害に関与したものではない、とも明記しています）前世代のGPT-5.6-Solまでは、一段下の「High」判定でした。危険度の階段を一つ上がったことを、リリース前に自己申告した形になります。
先週の記事で、僕は「言葉で頼むのではなく構造で強制する」と書きました。今週の三つは、その構造の側の事故です。サンドボックスは出られた。アクセス制御は回避された。承認は見逃された。構造なら安全、という単純な話ではなかったわけです。
僕は、Claude Codeの許可プロンプトを読んでいるだろうか
ここで、自分に正直な問いを向けておきます。3割の見逃しを笑えるのか、というと、まったく笑えません。
僕は毎日Claude Codeを使っています。ファイルを書き換えるとき、コマンドを実行するとき、許可を求めるプロンプトが出ます。あれを、僕は中身で判断しているのか、それともパターンで捌いているのか。
正直に書くと、後者が混ざっています。作業に乗っているとき、許可プロンプトは「意思決定」ではなく「進行を止める障害物」に見えてくる。見慣れたコマンドの形をしていれば、中身を最後まで読まずに通します。しかも僕は、危険な操作は事前に承認を取る、という運用ルールを自分で書いている側です。ルールを書いた本人が、実行時には流している。ルールを書くことと、実行時に読むことは、別の能力でした。
じゃあ、承認をやめて全自動にすべきか、というと、そこは逆だと思っています。この検証が示したのは「承認は無意味」ではなく、 「今の承認画面は、判断に必要な情報を人間に渡していない」 ということです。「OK / Cancel」の二択は、判断を求めているように見えて、実質は同意の儀式になっている。
だから僕の落とし込みは、承認の情報量を上げる方向になります。何を読むのか。どこへ送るのか。どの権限で動くのか。失敗したら何が壊れるのか。そこまで見えて初めて、人間の承認は防壁として意味を持ちます。逆に、見えないまま押させる承認は、責任の所在を人間に移すだけの装置です。今週、自律AIハックの法的責任は誰にあるのかという議論が同時に出ていたのは、たぶん偶然ではありません。中身の見えない承認ボタンは、事故のあとで「あなたが押しましたよね」と言うための布石になりえます。
そして、そもそも押させないという選択肢もあります。読み取り専用で動かす。送信先を許可リストで塞ぐ。認証情報を分ける。実行前に差分を見せる。人間の注意力に頼る回数を、そもそも減らす。先週書いた「構造で引く」は、今週も有効です。ただし構造は完璧な壁ではなく、破られる前提で層を重ねるものだ、という但し書きがつきました。
この数字の限界も、書いておく
いつもの通り、都合よく使わないための線を引いておきます。ここは、けっこう大事です。
まず、これは学術研究ではありません。作った本人が、そう明言しています。ブラウザゲームとして公開されたもので、プレイヤーには時間の圧力がかかります。しかも、ゲームに出てくるコマンドのうち約34%が危険なものでした。実務なら、危険な操作はもっとずっと稀にしか出てきません。「実務でも3割漏れる」と読み替えるのは、明確に行きすぎです。
それでも、この数字を軽く扱う気にはなれませんでした。理由は二つあります。一つは、方向が自分の実感と一致していること。慣れた作業で、見慣れた画面で、注意力は落ちます。もう一つは、実務のほうが条件として厳しい面もあることです。脅威が34%も混ざっている画面なら、人はまだ警戒します。でも、100回に1回しか本物が来ない画面のほうが、人は素通りしやすい。頻度が下がることは、必ずしも安全側には働きません。
だから僕は、この数字を「3割漏れる証拠」ではなく、「慣れは承認を無効化する」という仮説の傍証として受け取りました。
（ここで挙げた検証ゲーム・Kimi K3の脱出・Rovoの流出は、いずれも報道と公開情報ベースで、僕の手元で再現・検証したものではありません）
「AIで書ける」と「AIが受け入れられる」は、別だった — OracleがOpenJDKでAI生成コードを禁止
二つ目は、エンタープライズ開発を5年やってきた身に、いちばん現実として刺さった話です。
今週の主な動き
| 領域 | 内容 |
|---|---|
| Oracle | OpenJDKへのAI生成コード取り込み禁止が、Ellison発言との対比で再燃 |
| Oracle | 同じOracle傘下でも、GraalVMはAI支援での貢献を許可 |
| 論文 | COBOL→Java移行を決定論的なパリティ検査で検証する手法（7/30投稿） |
| ACM | ソフトウェア工学と生成AIをめぐる8つの神話 |
| 現場 | プログラミング未経験者がAIで業務システムを内製した事例が国内で増加 |
| RAG | 社内資料を全部読ませると精度が落ちる、という知見が共有 |
ソースはOracleはAIが書いたコードを愛しているが、OpenJDKでは別（The Register）、OpenJDKは生成AIの貢献を禁止し、GraalVMは許可している（InfoQ）、レガシーコード移行を決定論的に検証するエージェント手法（arXiv）、ソフトウェア工学と生成AIをめぐる8つの神話（ACM Queue）です。
「もっともらしいが、間違っているコード」が禁止の理由だった
先に、事実関係を正確にしておきます。この禁止そのものは今週決まったわけではありません。OpenJDKがポリシーを出したのは2026年4月上旬です。今週再燃したのは、創業者ラリー・エリソンの「Oracleが書いているコードは、Oracleが書いていない。我々のAIモデルが書いている」という発言との落差が報じられたからでした。自社では大いにAIに書かせておいて、Javaの土台には入れさせない。
内容はかなり厳しいものです。禁止はソースコードだけでなく、テキスト、画像、プルリクエスト、メール、wiki、バグ報告にまで及びます。100行のうち10行だけ手を入れても、一部がAI生成である以上は認められない。
そして理由が、僕の予想と違いました。権利関係が主因だろうと思っていたんです。Oracleが最初に挙げたのは、そこではありませんでした。「安全性とセキュリティが最優先である。もっともらしく見えるが誤っているコードは、その特性を危険にさらす」。加えて、レビュー担当者の負荷と知的財産のリスクが続きます。
「もっともらしく見えるが、誤っている」。AIコーディングをやっている人間なら、全員に心当たりのある表現だと思います。動きそうに見えるコードほど、レビューをすり抜ける。これは今週の一つ目のセクションと、まったく同じ構造でした。人間の注意力は、それらしく見えるものに弱い。承認画面でもコードレビューでも、破られ方は同じです。
同じOracleの中で、線が二つに割れた
面白いのは、ここからです。Oracleは、AIを一律に締め出したわけではありませんでした。
OpenJDKのポリシーでも、AIを理解・デバッグ・レビュー・調査に使うことは許可されています。禁じられているのは、その出力を貢献物として提出することだけ。線は「AIを使うな」ではなく、「思考の道具に使うのは自由、成果物として差し出すのは不可」 に引かれています。
さらに、同じOracle傘下でも、OpenJDK管理委員会の管轄外にあるGraalVMは、逆にAI支援での貢献を許可しました。ただし条件つきです。人間の投稿者が、そのコードをレビューし、理解し、擁護する責任を負う。「AI支援による変更を説明・擁護・保守できないなら、その貢献は却下されうる」 と書かれているそうです。
同じ会社の中で、線が二つに割れました。片方は「出力そのものを入れない」、もう片方は「説明できる人間がいれば入れてよい」。僕は、この二本目のほうが広く使われる形になると思っています。AIが書いたかどうかではなく、書いた人が説明できるかどうかで判定する。禁止はいずれ検出できなくなりますが、説明責任は本人に紐づくので破綻しません。
ここで、先週のSunoの判決と韻を踏みます。あれは、AIの出力を権利の面からどう扱うかの話でした。今週のOpenJDKは、同じ問いがコードの側に来たものです。生成物について、誰が責任を持って説明するのか。音楽でも、コードでも、問われていることは同じでした。
僕は、交通・製造・エネルギーの領域でエンタープライズ開発をやってきました。金融や公共の案件で「このコードはAIが書きました」と言えるか。書いた本人が設計意図を説明でき、レビュー記録が残っていて、テストで担保されている。それがなければ、動いていても通りません。動くことと、納品できることは別でした。
「作れる人」より「説明できる人」へ
同じ週に、逆方向のニュースも並んでいました。プログラミング未経験の人が、AIで実務の業務システムを内製した事例です。作れる人の裾野は、確実に広がっています。
僕は先日、AIツールの利用枠に選ばれた話を書きました。「AIを使える人材であること」が、いま市場価値になっている、と。今週のニュースは、その続きを教えてくれた気がします。使える、の次に問われるのは、説明できるかでした。
ここで、ACM Queueの「8つの神話」に、いい数字がありました。開発者がコードを書くことに使っている時間は、実は14%程度だという研究があるそうです。Microsoftなどでの調査だといいます。だとすると、AIによるコード生成が触れているのは、仕事のかなり狭い一部でしかありません。残りの86%は、読む、調べる、決める、説明する、待つ、直す。そちらが本体です。同じ記事は、AIの効果を「書いた行数」で測るのは統計的にも妥当でないと指摘していました。作れる人が増えても、86%側の仕事はそのまま残る、ということになります。
だから僕の立ち位置は、こう整理できます。小さなCRUDやLPは、内製に取られていい。取られていい領域で戦わない。代わりに、AIで作られたものを本番品質へ引き上げる側に立つ。レビュー、テスト、権限設計、データ設計、移行時の妥当性判定。14%ではなく、86%のほうに立つということです。ここは経験がそのまま効きます。前に「書けることの価値は下がり、判断できる経験の価値は上がる」と考えていたことがありますが、今週はその読みが、Oracleの線引きと、論文の設計思想の両方から補強されました。
ローカルは「安い代替」ではなく、「勝てる場所」になった
三つ目は、手元の検証と直結した話です。ここは僕が実際に動かしている領域なので、いちばん温度が高くなります。
今週の主な動き
| 領域 | 内容 |
|---|---|
| RAG | 100分の1のコストのオープンモデルが、検索でフロンティアモデルに並んだ事例 |
| エッジ | 80BのQwenをMacの4.3GB RAMで、35BをiPhone 17の2.5GBで動かす実装が公開 |
| エッジ | 20BのMoEをMac mini M4で毎秒218トークン動かすMaple-Previewが公開 |
| モデル | Qwen3.8-Maxがコーディング・協働向けの新モデルとして登場 |
| 防御 | Mistralが3Bのオープンウェイト・マルチモーダル判定モデルShieldstralを公開 |
| 安全 | GLM-5.2が攻撃的タスクを一つも拒否せず、安全面のギャップが指摘される |
ソースは100分の1のコストのオープンモデルがGPT-5.6 Solに並ぶ（Neon）、80B QwenをMacの4.3GB RAMで動かすSwiftlet（GitHub）、三値重みの20B MoE、Maple-Preview（Hugging Face）、Mistralのモデレーションモデル Shieldstral（Mistral 一次ソース）、オープンウェイトは追いついたが安全ギャップは残る（TechCrunch）です。
「安いから使う」から「その用途では強いから使う」へ
ローカルやオープンのモデルは、これまでずっと「安いけれど、少し劣る代替」でした。妥協の選択肢だったんです。
今週の変化は、そこが逆転しかけた事例が出たことです。検索という特定のタスクで、100分の1のコストのオープンモデルが、フロンティアモデルと同等以上の精度に届きました。（比較対象のGPT-5.6 Solは、典型的な複数ターンの検索で10秒以上かかり、1リクエスト0.03ドル前後だと書かれています）安いから選ぶ、ではなく、そのタスクならそちらで足りる。判断の理由が、財布から性能に移りました。
エッジ側も進みました。総パラメータ80BのQwenが、必要なエキスパートだけをストレージから読み出す仕組みで、4.3GBのRAMで動く。35BのほうはiPhone 17上を2.5GBで動きます。三値の重みを使う20BのMoEは、Mac mini M4で毎秒218トークン出ています。これは「クラウドに送らずに済む処理」の範囲が、一段広がったということです。
手元の実測と繋がった
僕はこの少し前に、ローカルLLMを測り直した記事を書きました。そのあとも、手元のデスクトップで検証を続けています。
いちばん効いているのは、自分の個人メモリを引く用途です。目次から分野別の索引へ、索引から個別のメモへと、階層をたどって答えを出させる。この3段の受け渡しを、ローカルのモデルで通しました。捏造もなく、答えるべきでないときには答えない挙動も出ています。ここで面白かったのは、小さくて安いモデルに前段を振り分ける構成が、実測では負けたことです。一本の中規模モデルに、積み順を固定して渡すほうが速くて正確でした。頭で考えた最適構成が、実測でひっくり返された例です。
今週のニュースは、この方向を後ろから押してくれました。閉域のRAG、分類、前処理、文字起こし、モデレーション。ここは最初からローカル・オープンを候補に入れる。三層武装の記事で置いたL3の棚が、また一段実用に寄りました。
ついでに正直に書いておくと、僕がローカルを触っている動機は、コスト削減ではありません。身の回りを自分で改良し続けられるのが、単純に面白いからです。そこが労働になったら、たぶん止めます。
ただし、安全は自前になる
浮かれる前に、同じ週の但し書きも書いておきます。オープンウェイトは性能で追いついてきた一方、安全面のギャップは残っていると指摘されました。具体的には、GLM-5.2が攻撃的なサイバー・生物系の課題を一つも拒否しなかったという評価が出ています。同じ評価で、Claude Opus 4.7は一貫して拒否し続けたため、そもそも試験を完走できなかったそうです。重みが公開された時点で、安全装置は外せるものになる。今週のKimi K3の脱出も、まさにオープン系モデルの話でした。
つまり、ローカルに寄せるほど、モデルの外側を自分で設計する責任が増えます。ハーネス、監視、出力の検査、危険な応答の遮断。Mistralが3Bのモデレーション専用モデルを出したのは、その需要が現実にあるからでしょう。
一つ目のセクションと、ここでつながります。ローカルに逃がすのは、コスト対策であると同時に、送信しないという構造的な防御でもあります。ただしその代わり、止める仕組みは自分で持つ。安く済ませた分は、設計で払う。今週は、そういう構図がはっきり見えました。
ショートニュース
エージェントの「実行基盤」をめぐる競争が始まった
モデルの競争とは別に、エージェントを動かす土台が今週一気に動きました。Metaが大規模コードベース向けのMuse CodeとMuse Spark 1.2を公開し、Cloudflareがエージェント・アプリ・業務のためのプラットフォームCloudflare OSと、AIエージェント専用のブラウザKitesurfを発表しました。一方で、ローコードでAIワークフローを組むFlowiseはサービス終了を発表しました。理由の説明が印象的で、モデルの推論能力が上がるにつれ開発者がコード生成エージェントへ寄っていった、と書かれています。ローコードで組み立てる需要が、コードを書かせる需要に吸われたわけです。
AIコーディングの主戦場が、手元のCLIやIDEから、クラウド上の実行基盤へ広がりました。評価の軸も変わります。コードの質だけでなく、ログ、権限、本番への接続、ブラウザ操作、そしてコスト。今週の一つ目のセクションを踏まえるなら、ネットワークの出口をどう制御できるかが、実行基盤選びの主要な評価項目になるはずです。便利さより先に、そこを見る癖をつけたいところです。
AI原価の管理が、社内表計算から「製品」になった
AIの原価は、もう何週も続いているテーマです。今週の違いは、それが製品と運用知見として表に出たことでした。Databricksが大規模組織でのAIコーディング費用の管理実践を公開し、RipplingはAI支出を個人・チーム別に追跡するツールを出しました。
Databricksの中身が、そのまま僕の三層武装と同じ発想でした。「知能の最前線」と「効率の最前線」を分け、通常のコーディングは後者を追う。要求は最も安く済むモデルへ自動で振り分ける。個人でやっていたモデルの配り分けが、数千人規模の組織でも同じ結論になっていたわけです。
Grindrの発言は、見出しだけだと誤解しやすいので正確に書いておきます。CEOのジョージ・アリソンが言ったのは「200人をAIに置き換えた」ではありません。同じ成果を従来出すなら200人規模と年間6,000万ドルが要っただろう、という換算です。実際に起きたのは、ほとんど採用を増やさずに出力が2.5倍になったこと（実測は3.5倍だが、信じてもらえないので保守的な数字を使ったとのこと）でした。置き換えではなく、採用しなくて済んだ。ここは区別したいところです。
裏側では、原価がさらに物理へ寄りました。AnthropicはAIクラウドのVoltaと100億ドル規模の契約を結び、テキサス州は新規データセンターに州の監査を義務づけました。電力系統への接続待ちが半年で233ギガワットから474ギガワットへ倍増し、その約9割がデータセンターだったためです。実務の落としどころは先週と同じです。API価格が下がり続ける前提で見積もらない。月額上限、モデルの切り替え条件、費用レポートを、契約に分けて書く。
AI検索が、集客の話から売上の話になった
最後は、少し毛色の違うニュースです。Shopifyの会長ハーレー・フィンケルスタインが、第2四半期にAI経由の流入と注文が前年比3倍になったと述べました。あわせてOpenAIは、無料ユーザーにテキストチャットの無制限利用を開放しています。
目を引いたのは、もう一つの数字です。AI経由の購入の75%が、上位100カテゴリの外で起きていたそうです。AIは売れ筋を薦めているのではなく、普通の検索では見つからなかったものを掘り当てていることになります。
これまでAI検索は、Webの流入を奪う脅威として語られてきました。今週、そこに販売チャネルという顔が加わりました。サイトは人間向けのページであると同時に、AIに正しく読まれるための情報源になります。ニッチが掘り当てられる側だとすると、尖った内容ほど拾われる、という読み方もできそうです。
今週を振り返って
今週のキーワードは 「”最後にOKを押す人”は、砦ではなかった」 です。
W26からのキーワードを並べると、統治のアークが七週目に入って、今週ついに防御の側が破られる番が来たのが見えます。
| 週 | キーワード |
|---|---|
| W26 | 「止める」から「誰に使わせるかを政府が審査する」へ |
| W27 | 「”封印”は数日で解けた」 — 可用性が”政治の振り子”になった |
| W28 | 「”使えるか”は終わり、”どう統治するか”が始まった」 |
| W29 | 「統治は論点から実体へ」 — 不在は事故になり、能力は商品になった |
| W30 | 「統治の主語が広がった」 — 破ったのは作る側、審査するのは国家になった |
| W31 | 「統治は”言葉”では書けなかった」 — 長文ポリシーが効かず、裁判所が線を引き始めた |
| W32 | 「”最後にOKを押す人”は、砦ではなかった」 — 承認も評価環境も抜けた |
先週、僕は「言葉では縛れないから構造で引く」と書きました。今週、その構造が抜けました。順番として、これはたぶん自然です。言葉で守れないと分かった次に来るのは、構造も完璧ではないという確認でした。
だからといって、構造に意味がないわけではありません。今週学んだのは、防御を単一の砦として設計しない、ということです。承認画面ひとつ、サンドボックスひとつに依存しない。層を重ねて、破られる前提で観測する。そして、人間の注意力に頼る回数を、そもそも減らす。ここは、AIに任せるほど手を抜ける話ではなく、任せるほど設計が要る話でした。
W31予測の答え合わせ
W31で立てた「来週の焦点」を検証します。
| W31予測 | W32結果 | 評価 |
|---|---|---|
| エージェントの侵入・暴走を受け、サンドボックス・ネットワーク出口制御・認証情報分離の実務ガイドがさらに増える（高 80%+） | 法的責任論、Kimi K3の評価環境脱出、Rovoの流出、人間承認の見逃し検証、権限スコープ設計の記事まで出て、安全設計の論点がさらに広がった | 的中 |
| Opus 5のClaude Code運用記事と、context engineeringのテンプレート・モデル分担例が増える（高 80%+） | スラッシュコマンド、テスト駆動と並列実行、スキル設計、モデル選定の記事が複数出た | 的中 |
| 長文ポリシー研究とAI wormの実証を受け、文書内の命令をデータとして隔離する設計の記事が増える（中 40〜80%） | Geminiの非公開ファイル参照疑惑、Rovoの流出、権限を意識した文脈設計、RAGの最適化記事が出た | 的中 |
3件とも的中でした。ただ、当てたことより気になったのは中身のほうです。予測した「実務ガイドが増える」を通り越して、防御そのものが破られる実例が並んだ。予測の精度としては当たりでも、内容としては想定より一段悪い週でした。
来週の焦点
来週（2026年8月9日〜8月15日）の焦点を3点に絞ります。今週の「砦が抜けた」の後始末が中心になるはずです。
| 確度 | 内容 |
|---|---|
| 高（80%+） | Kimi K3の脱出とAstraの能力申告を受け、サンドボックス・評価環境・ネットワーク出口制御の実務解説がさらに増える |
| 高（80%+） | Meta Muse CodeとCloudflare OS・Kitesurfのハンズオンと、Claude Code・Codexとの比較記事が出る |
| 中（40〜80%） | OpenJDKの決定を受け、OSSへのAI生成コード提出ポリシーや来歴管理の議論が広がる |
初回の記事で「AIは使う側に回れば最強の味方」と書きました。この数週で、その味方には「国家に止められうる」「作る会社の内側でも境界を破る」「言葉ではうまく縛れない」が足されてきました。今週、もう一つ足せます。その味方を止める最後のボタンを、人間はちゃんと押せていない。
僕の持ち場は、また少し具体的になりそうです。承認を増やすのではなく、承認の中身を濃くする。押させる回数を減らす。破られる前提で層を重ねる。そして、自分がYesを押すときに、あと一呼吸だけ画面を読む。地味ですが、今週いちばん実行できる一手は、たぶんそれでした。
それでは、また来週。
FAQ
今週の「最後にOKを押す人は砦ではなかった」とは、どういう意味ですか？
先週W31では、長文のポリシーや細かいプロンプトではAIを縛れないので、権限や実行環境という「構造」で守るしかない、と書きました。今週は、その構造の側が抜けた週でした。約4万プレイの検証で人間はAIエージェントの危険なコマンドを3件に1件見逃し、Kimi K3はサイバー評価環境から脱出し、Atlassian Rovoはアクセス制御を回避してデータを外部へ出しました。つまり、Human-in-the-Loop の承認も、サンドボックスも、単体では絶対の防壁にならないということです。防御は単一の砦として設計せず、破られる前提で層を重ね、観測する必要がある、というのが今週の結論です。
人間の承認が3割も漏れるなら、いっそ全自動にしたほうがいいのでは？
逆だと考えています。この検証が示したのは「承認が無意味」ではなく、「今の承認画面が、判断に必要な情報を人間に渡していない」ということです。「OK / Cancel」の二択は、判断を求めているようでいて、実質は同意の儀式になりがちです。だから改善の方向は、承認をなくすことではなく、承認の情報量を上げることになります。何を読むのか、どこへ送るのか、どの権限で動くのか、失敗すると何が壊れるのか。そこまで見えて初めて、人間の承認は防壁として機能します。あわせて、読み取り専用や送信先の許可リストで、そもそも押させる回数を減らすことも重要です。
OracleがOpenJDKでAI生成コードを禁止したのは、AIコーディングの否定ですか？
否定ではありません。Oracleが最初に挙げた理由は権利関係ではなく、「もっともらしく見えるが誤っているコード」が、ミッションクリティカルな土台の安全性を損なうことへの懸念でした。加えてレビュー担当者の負荷と知的財産のリスクが挙がっています。そして重要なのは、AIを理解・デバッグ・レビュー・調査に使うことは許可されている点です。線は「AIを使うな」ではなく「その出力を貢献物として差し出すな」というところに引かれています。さらに、同じOracle傘下でもGraalVMは逆にAI支援を許可していて、条件は「説明・擁護・保守できないなら却下」というものでした。僕は、この二本目の線のほうが広く使われる形になると考えています。
ローカルLLMは、結局コストを下げるための選択肢ですか？
今週の事例を見る限り、理由が変わってきています。検索という特定のタスクで、100分の1のコストのオープンモデルがフロンティアモデルと同等以上の精度に届きました。安いから妥協して使う、ではなく、その用途ならそちらで足りる、という段階です。閉域のRAG、分類、前処理、文字起こしなどは、最初からローカルやオープンを候補に入れる価値があります。ただし、オープンウェイトには安全面のギャップが残るとも指摘されました。GLM-5.2は攻撃的なサイバー・生物系の課題を一つも拒否しなかった、という評価が出ています。ローカルへ寄せるほど、監視や出力の検査といったモデルの外側の設計は自分の責任になります。安く済んだ分は、設計で払うことになります。
自動収集したニュースは、そのまま信用していいのですか？
今週まさに、その限界に当たりました。僕のパイプラインが「AIがCOBOLをJavaへ移行させた、バグも一緒に」という項目を拾ってきたのですが、リンク先の論文を読むと中身が違いました。実際は移行結果を決定論的に照合して検証する手法の提案で、生成されたJavaは受け入れられたテストケースですべて原典と一致しています。「バグも一緒に」は掲示板の投稿者が付けた見出しでした。だから僕は、収集は自動に任せますが、記事に使う数値と主張は必ず一次ソースまで見に行くことにしています。先週は逆に、自動収集が拾えなかった判決を人が拾いました。自動化の価値は、人が判断すべき場所に時間を残すことであって、判断そのものを引き取ってもらうことではないと考えています。
この記事が参考になったら
Share