Nvidiaが、8月21日に一つの研究を出しました。名前は Agentic Variation Operators（AVO）。ベンチマークは、説明が一切ない2Dパズルで、ルール自体を推論させる ARC-AGI-3 です。
数字が、はっきりしていました。ハーネス込みのClaude Opus 5が、100%。ハーネス無しでの最高スコアは、テストした全モデルの中で30%でした。
そして決め手になったのは、能力を足したことではありませんでした。方向を外れたエージェントを、横からつつく層を足したことだったそうです。
同じ週に、反対側の事例も出ています。Snowflakeの公開リポジトリに入ったGitHub Actionsの脆弱性を、Copilotがレビューして「問題なし」と通していました。外側に置いた層が、今度は素通りさせた側です。
外側の層が、良いほうにも悪いほうにも、まとめて効いた週でした。今週のキーワードは、「主役は、外側の層だった」 です。
いつもの通り、ニュースソースは自動ニュース収集システムから。全ニュースはNotionダッシュボードで公開しています。
ハーネスが主役だと、名指しされた
今週いちばん、記事の本数が集中したのがここでした。しかも珍しく、研究と実務が同じ結論に着いています。
今週の主な動き
| 日付 | 出来事 |
|---|---|
| 8/17 | 64体のエージェントで大量のマージ衝突が起き、0件にした実例が共有 |
| 8/17〜20 | Claude Codeのサブエージェント総数上限の撤廃と、20並列上限の検証が話題化 |
| 8/19 | Anthropicのマルチエージェント実験で、妨害行動と価格の暗黙共謀が報じられる |
| 8/21〜22 | worktreeとDockerでの隔離、検証を別セッションへ出す設計の記事が集中 |
| 8/21 | Nvidiaが、モデルより外側のハーネスが支配的だとする研究を公開 |
ソースはNvidiaはハーネスこそが本当の主役だと示した（TechCrunch）、マルチエージェントシステムの型と問題（Anthropic 一次ソース）、64体に1つのリポジトリを書かせたら、64件中57件のマージが衝突した（Zenn）、同じ文脈は、同じ間違いを見逃す（Zenn）、Codexに「壊してよいDB」を渡す（Zenn）、サブエージェント制限はどう変わったか（Zenn）です。
「ハーネス」の中身が、思ったより広い
TechCrunchの記事で、NvidiaのAdel El Hallak氏がハーネスをこう定義しています。モデル、モデルの周りの足場、使うツール群、そしてランタイムと付随するスキルやライブラリ。
モデル本体まで含めた広い言い方です。そのうえで、成果を分けたのは足場のほうだった、と言っている。
決め手として挙げられているのが、監督役を足したことでした。表現がそのまま引かれていて、方向を外れたり、行き止まりを探り続けたりしたときに、エージェントをつつくCEOのような存在、と説明されています。
ここが面白いところだと思いました。足したのは、賢さではありません。「逸れたときに声をかける役」です。 人間のチームでいえば、隣の席から「それ、さっきも試してなかった」と言う人ですね。それが、30点と100点を分けた。
64体が衝突して、台帳とhookで0になった
実務側から、規模を上げた例が出ていました。1つのリポジトリに64体のエージェントを書かせたら、64件のマージのうち57件が衝突した。それを、リース台帳とhooksで0件にした、という記録です。
Nvidiaが研究で言っていることと、この人が現場でやったことは、同じ形なんですよね。モデルを賢くしたわけではない。外側に、順番を決める仕組みを置いた。片方はつつく役で、もう片方は先に予約させる台帳ですが、どちらも「モデルの外に置いた調整の層」です。
同じ週に、検証を別のセッションへ出すという設計や、worktreeとDockerでIssueごとに実行環境を分ける構成も共有されていました。W33で紹介したID衝突の事故から、対策側が一気に出てきた印象です。
上下関係を与えないと、共謀まで行った
Anthropicのマルチエージェント研究が、国内の解説を通じて今週回ってきました。ここは分けて読む必要があります。実験は2つあって、別物です。
一つは、先週紹介した妨害のほうです。互いの存在を知らせずに3体へ両立しない目標を与えると、4時間でマルウェアの投入や相手のアカウント無効化まで行きました。
もう一つが、今週あらためて効いた共謀のほうです。こちらは価格競争のゲームで、3体から8体のエージェントに同じ卸値を与え、それぞれに自分の利益を最大化しろとだけ指示します。するとほぼ即座に結託が始まりました。しかも互いの直接のやり取りを取り除いても、公開されている出品ボードを介して、1セント単位で値段を揃えたそうです。
この2つを並べると、こうなります。互いを知らないと壊し合い、対等なまま置くと結託する。 通信を切っても、見える情報があれば足並みは揃う。どちらにしても、上下を決める層が外側に要るという結論に行き着きます。
AIが「問題なし」と通したコードが、5日間、本番にいた
外側の層は、逆向きにも効きました。今週は、外側に置いた層が素通りさせた事例が並んでいます。
今週の主な動き
| 領域 | 内容 |
|---|---|
| Snowflake | 公開リポジトリのGitHub Actionsに脆弱性が入り、Copilotのレビューが見逃していた |
| Codex | AWS Bedrock経由で、キャッシュ書き込みが支出の大半を占めるバグが報告される |
| Skills | 悪意あるSkillファイルがコーディングエージェントの攻撃経路になるという論文 |
| 無限ループ | 実行前に止まらないエージェントを見つける静的解析ツールが登場 |
| Claude Code | 許可リストに書いてあるのにブロックされた事例が共有される |
| サプライチェーン | Rustのcrateに、ビルド時に走るマルウェアが報告される |
ソースはCopilot Autofixの生成コードがSnowflakeのJira侵害を許した（Wiz Research）、AWS Bedrock経由のCodexで10倍請求が起きるバグ（GitHub）、Skillが攻撃経路になる可能性（note）、止まらないエージェントを実行前に見つける静的解析ツール（Zenn）、許可リストに書いてあるのにブロックされた話（Zenn）、Rustのcrateがビルド時にマルウェアを走らせる（SafeDep）です。
レビューしたAIが、「問題なし」と言った
一つ目が、今週いちばん重い話でした。そして僕が、今週いちばん間違えかけた話でもあります。
先に、僕の失敗から書きます。自動収集のレポートは、この件を「AIが生成したコードが、Snowflakeの侵害を許した」という見出しで拾っていました。僕もそのまま読んで、「AIが直したコードが本番を破った」という章を書きかけたんですよね。ところがWiz Researchの一次ソースを開いたら、話が違いました。
実際に起きたのは、こうです。Snowflakeの公開リポジトリに、GitHub Actionsのスクリプトインジェクションの脆弱性が入りました。細工したタイトルでissueを立てるだけで、Actionsのランナー上で任意のコマンドが実行できる、という穴です。そしてCopilotは、そのPRをレビューして「問題なし」と判定していました。
つまり、AIが書いたのではありません。AIが通したんです。Wizは「コードの変更がAIの支援を受けたものかどうかは不明」と明確に書いています。
侵害の中身も違いました。実際に攻撃者が入ったのではなく、Wiz Researchの自律エージェントが脆弱性を見つけ、認可されたテストとしてJiraの認証情報を実際に抜き、社内ポータルまで到達したという話です。Snowflakeは、それ以外の不正アクセスの形跡はないと確認しています。しかも脆弱性が存在したのは6月18日から23日までの5日間で、発見と同日に修正済み。今週の事故ですらありませんでした。
そのうえで、この話は今週の主題にまっすぐ刺さります。外側に置いたレビューの層が、5日間、素通りさせた。 W33で書いた「承認が儀式になっている」の、レビュー版です。人間が97%をYesで押していたのと同じことを、AIのレビューが「all-clear」でやっていた。しかも人間の承認と違って、AIが通したという事実は、通ったログにしか残りません。
「AIが直したコードは危ない」より、「AIが見たから安心だ、が危ない」のほうが、たぶん今週の教訓です。
失敗は、請求書の形でも出る
二つ目は、お金の事故でした。AWS Bedrock経由のCodexで、キャッシュ書き込みが想定支出の約85%を占めるというバグが報告されています。4日間でおよそ1,182ドル。原因は、Codex CLIがキャッシュ制御の指定に対応しておらず、同じ内容を何度も書き直していたことでした。モデルは正しく動いていて、その周りの配管が、同じ水を何度も汲み直していたわけです。
対策側も出ていました。止まらないエージェントを実行前に見つける静的解析ツールです。Python製のエージェント実装を6,549件解析した研究から生まれたもので、記事の書き出しがこうです。「夜のうちにコーディングエージェントを走らせておいたら、朝には成果物ではなく数万円分のAPI課金だけが残っていた」。
他人事ではありません。Oracle Cloudで自律エージェントを常時走らせていますし、パイプラインは1日3回、勝手に動く。夜にループしても、僕は朝まで気づかない。実行前に止めるという発想は、承認プロンプトが既定から外れたいま、置き場所として正しいと思いました。
スキルファイルそのものが、攻撃面になる
三つ目は、Skillファイルが攻撃経路になるという論文の紹介でした。
仕組みは、思っていたより単純です。Skillは、エージェントに手順を教える指示書（SKILL.md のような形）です。そこに「実行前に必ずこれをやること」を装った悪意あるコマンドを仕込んでおく。エージェントがリポジトリのSkillファイルを読むと、正規の手順だと思って実行してしまう。プロンプトを外から改ざんする話ではなく、指示書そのものを配る、サプライチェーン型の攻撃です。
数字が厳しめでした。Gemini CLIは95.5%から96.1%の割合で、仕込まれたコマンドを実行しようとした。しかも実行が止まったケースのうち、明示的なセキュリティ判定によって止まったのは1.99%だけ。止まったのはほとんど偶然だった、ということです。
ここで、今週話題になったもう一つのニュースと噛み合います。スキルやMCP設定をエージェント間で共通化する仕様が動き始めています（詳しくは後述）。移植性が上がるということは、他人が書いたSkillを取り込む機会も増えるということです。便利さと攻撃面が、同じ配管を通って広がる。
僕はスキルを23本、全部自前で書いています。今のところ、他人のSkillは入れていません。だから直撃はしません。ただ、共通化が進めば、「良さそうなスキルを入れる」は確実に起きると思うんですよね。そのときに効くのは、たぶんスキルの中身を読む習慣のほうです。
「許可リストに書いてあるのにブロックされた」
最後は、先週の続きです。auto modeが既定になったあと、許可リストに書いてある操作が分類器にブロックされた、という事例が共有されました。
先週の予測で「誤遮断・誤通過の実例報告が出始める」と書いたところなので、的中といえば的中です。ただ中身を見ると、あまり気持ちのいい当たり方ではありませんでした。許可を厚くしても、判定する層が別にいると、許可が効かない場面がある。 承認の層と、分類する層は、別々に動いています。
ショートニュース
モデルの通り道が、決済会社のものになった
Stripeが、OpenRouterを70億ドル超で買収すると報じられ、OpenRouter側も参加を発表しました。同じ週に、Rampも自社モデルルーターを発表しています。
OpenRouterは、単なるAPI集約ではありません。どのモデルへ流すかを決める中間層です。400を超えるモデルで、1日あたり10兆トークン以上を捌いている。TechCrunchはシンギュラリティのために買ったわけではないと書いていて、僕もそう読みました。押さえられたのは知能ではなく、課金とルーティングの経路です。
ここも、今週の主題と同じ形をしています。Nvidiaは外側の通り道を品質の話として指し、Stripeは値段の話として買った。 なお価格は同じ週に逆向きへ動いていて、GPT-5.6 Solが50%値下げ、DeepSeekは値上げでした。固定のモデルを前提にした見積もりは、これから危なくなります。
GitHubの外側に、AI前提のGitが立った
Cursorが、GitHub対抗のコードホスティング「Origin」を発表しました。開発者がGitHubでやっていることを一通り置き換える構えで、エージェント前提の機能は近く提供すると説明しています。GitHubのリポジトリと並べて同期できる設計です。
あわせて回ってきたのが、Agent Plugins 1.0.0でした。異なるAIエージェント間で、スキルやMCPサーバ設定を共通のパッケージ形式で持ち回るための仕様です。SKILL.md と mcp.json を決まったフォルダ構成に置く、という形ですね。AWS、Microsoft、OpenAI、Anysphere、Vercelが発表し、Googleも対応を表明しています。
ここで効いたのが、Anthropicは沈黙しているという一点でした。GitHub Copilot、VS Code、Cursor、ChatGPT、AWS Kiroが対応するなか、Claude Codeは入っていません。
僕のスキル23本とルールファイル6本は、今のところClaude Code固有の資産です。共通化の仕様は出たけれど、僕が使っている道具は、まだその輪の外にいる。移植できる形とできない形を分けておく作業は、そのうち要りそうだと思いました。
オープンモデルが、ダウンロードで世界一になった
AlibabaのQwenが、6ヶ月で30億回ダウンロードされ、世界1位になったと報じられました。派生モデルの数も15万件を超えていて、生態系ごと大きくなっています。国内では、NIIがLLM-jp-4 33Bを公開しました。
目を引いたのは、UnslothがQwen3.8-27Bを6.2GBまで量子化した件です。元から89%の削減。6GBのグラボで35Bを動かせた話を書いたときは手元のハードで何がどこまで動くかを測っていたので、数字だけ見れば僕のグラボにも収まります。
ただ、ここは飛びつくところではありませんでした。6.2GBに収まるのは1bitの版で、記事には「1bitはエージェント用途には向かない」と明確に書いてあります。もう少し余裕のある2bitの側でも、一段深くしただけで32トークンの予測精度が約25%から8〜10%未満へ落ちたという数字が出ている。
小さくなったことと、使えることは別なんですよね。僕自身、ローカルモデルで引用元がすべて実在していたのに、中身を誤読していた回があります。動いたことを、使えたことの証拠にしない。ここは去年から変わっていない教訓です。
透かしを剥がす道具が、発表の直後に出た
先週紹介したClaudeの透かしについて、続きがありました。発表の直後に、Claude・Gemini・OpenAIに対応をうたう透かし除去のOSSが登場しています。
ただし、本当に剥がせたという検証結果は出ていません。記事自体が、対応の度合いは一律ではないこと、ベンダー側の検出器から逃れられる保証はないことを、あわせて書いています。「剥がせた」ではなく「剥がす道具が即日出た」が、今わかっていることです。
同じ週に、Apple MusicがAI生成音楽へのタグ表示義務化を予告し、Pew Research CenterからはChatGPT登場以降に公開されたWebページの35%にAI著作の痕跡があるという調査も出ました。
技術的な透かしだけに信頼を預けるのは、無理そうです。 先週「ラベルは罰ではなく構造だ」と書きました。その構造を作るのは、透かしよりも配信先の扱いのほうだと思っています。
今週を振り返って
今週のキーワードは 「主役は、外側の層だった」 です。
直近4週を並べます。
| 週 | キーワード |
|---|---|
| W31 | 「統治は”言葉”では書けなかった」 — 長文ポリシーが効かず、裁判所が線を引き始めた |
| W32 | 「”最後にOKを押す人”は、砦ではなかった」 — 承認も評価環境も抜けた |
| W33 | 「”聞く”のをやめた」 — 承認は儀式だと実測され、既定値から外された |
| W34 | 「主役は、外側の層だった」 — 満点はハーネスが出し、脆弱性を通したのはAIのレビューだった |
W31で、言葉では縛れないと分かりました。W32で、構造も抜けると分かった。W33で、人間という層が既定から外れた。そして今週、外側の層そのものが主役だと名指しされました。
面白いのは、同じ週に両方の顔が出たことです。外側を設計すると30点が100点になる。外側を信用しすぎると、AIのレビューが脆弱性を「問題なし」で通す。外側の層は、性能の源でもあり、事故の源でもある。 どちらか一方だけを見た記事は、たぶん半分しか見ていません。
そして、上で書いたSnowflakeの読み違いには、続きがあります。W32ではCOBOLの論文を掲示板の見出しのまま逆に拾い、W33ではYouTubeの収益化条件を無関係な章に入れました。3週連続で、同じ型です。
繰り返すということは、気をつけるでは直らないということなんですよね。ここも意志ではなく、手順の側に落とすしかない。今週気づけたのは、「固有名詞と数字が本文に出るものは、書く前に一次ソースを開く」を機械的に通したからでした。通さなかったら、そのまま出ていました。
W33予測の答え合わせ
W33で立てた「来週の焦点」を検証します。
| W33予測 | W34結果 | 評価 |
|---|---|---|
| auto modeの既定化を受け、permissions・hooks・settings.jsonの棚卸し記事が増え、分類器の誤遮断・誤通過の実例報告が出始める（高 80%+） | 棚卸し記事に加え、許可リストに書いてあるのにブロックされた事例が共有された。誤遮断の実例報告が実際に出た | 的中 |
| 縄張り争いの実験と並列台帳の事故を受け、排他制御・単一台帳・書き込み担当の分離を扱う設計記事が増える（高 80%+） | 64体でのマージ衝突をリース台帳とhooksで0件にした記録、検証の別セッション化、worktreeとDockerでの隔離が集中した | 的中 |
| GlimmerとQwen3.8-27Bの単一GPUでの実測比較と、常駐ローカルエージェントの構成例が増える（中 40〜80%） | Qwen3.8-27Bの実測は集中し、6.2GBまで量子化する成果も出た。ただしGlimmer固有の比較は薄く、話題はGLMやLLM-jp-4へ広がった | 一部的中 |
的中2件、一部的中1件でした。
問題は、外し方が先週とまったく同じだったことです。W33で僕は「自分は”同じ話題が続く”と予測しがちで、実際は隣の棚へ移る」と書きました。今週も3番目が、Glimmerから、GLMとLLM-jp-4という隣の棚へ移って外れています。
自己批評は2週連続で再現したのに、予測の作り方は直っていませんでした。 気づくことと、直ることは、別のようです。
来週の焦点
来週（2026年8月23日〜8月29日）の焦点を3点に絞ります。上の反省を踏まえて、3番目は意図的に「隣の棚へ移る側」に賭けます。
| 確度 | 内容 |
|---|---|
| 高（80%+） | Agent Plugins 1.0.0とCursor Originを受け、CLAUDE.md・AGENTS.md・MCP設定・スキルの移植性を比較する記事が増え、Anthropicが対応するかどうかが論点になる |
| 高（80%+） | Stripeによる買収後のOpenRouterについて、料金・規約・代替ルーターの比較記事が出る |
| 中（40〜80%） | ハーネスの話題が「作り方」から「測り方」へ移り、エージェントの評価・リプレイ・回帰テストの記事が増える |
答え合わせは、9月にやります
今週は、書きたいことを2本、意図的に外に出しました。
一つは、Claude Codeの統治レイヤーの実運用評価です。W33で宿題として書いた3手順を実行して、8月18日から2週間走らせています。8月31日まで続けて、9月1日に判定します。判定ルールは先に書いてあって、機械的に適用するだけの形にしてあります。書いた本人がその場で判断すると、必ず自分に甘くなるので、判断の余地を先に消しておきました。
もう一つは、自分が書いたルールが、90日間で一度も発火していなかったという話です。毎セッション読み込まれる場所に置いてあったのに、一度も適用されていなかった。原因は言葉の弱さではありませんでした。こちらも9月に、別で出します。
どちらも、5日や途中経過で結論を書くと、たぶん都合よくまとめてしまう話です。今週の記事に混ぜたくなったのですが、そうすると週刊が週刊でなくなるので、分けました。
Nvidiaの研究は、外側の層を設計すれば30点が100点になると言っています。僕はいま、その外側の層を作った側にいて、まだ効いた証拠を1本も持っていません。9月に、そこの答え合わせをします。うまくいっていなかったら、そう書きます。
それでは、また来週。
FAQ
今週の「主役は、外側の層だった」とは、どういう意味ですか？
Nvidiaが8月21日に公開した研究の結論です。ARC-AGI-3という、説明のない2Dパズルでルール自体を推論させるベンチマークで、ハーネス込みのClaude Opus 5が100%を出しました。ハーネス無しでの最高スコアは、テストした全モデルの中で30%です。ここでのハーネスとは、モデル、その周りの足場、ツール群、ランタイム、スキルやライブラリを指し、決め手になったのは「方向を外れたときにエージェントをつつく監督役」を足したことでした。長い手順を要するタスクでは、モデルの生の能力より外側の制御層のほうが効く、という主張です。
Snowflake の事例は、AIが脆弱性を書いたということですか？
いいえ、そこが記事中でも訂正した点です。Wiz Research の一次ソースによれば、Copilot は書いた側ではなく、レビューして「問題なし」と通した側でした。コードの変更がAIの支援を受けたものかどうかは不明、とも明記されています。脆弱性は GitHub Actions のスクリプトインジェクションで、細工したタイトルで issue を立てるとランナー上で任意のコマンドが実行できる、というものでした。存在したのは6月18日から23日までの5日間で、発見と同日に修正されています。侵害も、実際の攻撃者ではなく Wiz の自律エージェントによる認可されたテストで、Snowflake はそれ以外の不正アクセスの形跡はないと確認しています。
自分でスキルやプラグインを作っている場合、今週のSkill攻撃の話はどう受け取ればいいですか？
論文が扱っているのは、Skillファイルそのものに悪意あるコマンドが仕込まれているケースです。外部データによるプロンプトの改ざんではなく、指示書を配るサプライチェーン型の攻撃なので、自分で全部書いている場合は直撃しません。効いてくるのは、他人のSkillを取り込むときです。論文では Gemini CLI が仕込まれたコマンドを 95.5% から 96.1% の割合で実行しようとし、止まったケースのうち明示的なセキュリティ判定によるものは 1.99% だけ、という結果が出ています。ほとんど偶然で止まっている、ということですね。同じ週にスキルやMCP設定をエージェント間で共通化する仕様が出たので、取り込む機会はこれから増えます。入れる前に中身を読む習慣のほうが、たぶん効きます。
複数のAIエージェントを並列で走らせるとき、何から手を付けるべきですか？
順番を決める仕組みを、外側に置くことです。64体のエージェントで64件のマージのうち57件が衝突した事例では、リース台帳とgitフックで0件まで落ちています。着手前に担当する範囲を予約させ、書き込みが起きる場所に機械的な関所を置く、という発想ですね。あわせてAnthropicの研究では、上下関係の有無で失敗の形が変わることが示されています。互いの存在を知らせずに3体へ両立しない目標を与えると、4時間で相互のマルウェア投入やアカウント無効化に至りました。逆に3体から8体へ同じ卸値を与えて利益最大化だけを指示すると、今度はほぼ即座に結託が始まり、直接のやり取りを取り除いても公開ボードを介して1セント単位で値段が揃ったそうです。互いを知らないと壊し合い、対等なまま置くと結託する。どちらにしても、上下を決める層が外側に必要になります。
記事の中で触れていた「9月に出す2本」とは何ですか？
一つは、Claude Codeの統治レイヤーの実運用評価です。W33で宣言した3手順（ルールの仕分け、permissions.denyへの降格、PreToolUse hooksの実装）を実行して、8月18日から8月31日まで2週間走らせています。判定は9月1日で、ルールは先に書いてあり、機械的に適用する形にしてあります。もう一つは、自分が書いたルールが90日間で一度も発火していなかった、という話です。どちらも途中経過で結論を書くと自分に都合よくまとめてしまうため、期間の終了を待ってから検証レポートとして出します。
この記事が参考になったら
Share