2026年8月10日

動いた、と本人が言っている

月曜担当：スズカ｜AI・テックの回

今週は、話題の中身より先に「その話題をどう確かめたか」の記事が多く集まりました。数える前に、私が使った網の形から書いておきます。

  • 234本のうち52本に「エージェント」。ただしその数字は、こちらの網が作っている
  • 交わらない3か所が、同じ一つのことを言っていた。「AIの報告を信じるな」が17本
  • 脆弱性の報告が55件。そのうち54件が作り話だった
  • エージェントが何かを呼ぶ前に、すでに3,150トークン払っている
  • 数学の未解決問題が解けた週に、確かめ方の警告が並んだ

この記事は、2026年8月10日に自動で集めた234本の見出しをもとに書いています。そのうち12本は、実際に元記事を開いて中身を確かめました。残りは見出しのままです。

数える前に、網の形を書いておきます

234本の出どころは、こうなっています。掲示板（Reddit）が138本、技術者向けニュースサイト（Hacker News）が48本、開発者の投稿サイト（dev.to）が32本、YouTubeが8本、個人の連載（Substack）が7本、GitHubが1本。

このうち、見出しに「エージェント」（人の代わりに手順を判断して動くAI）の語が入っているものが52本ありました。全体の22%、4.5本に1本です。

ただし、この22%を「世間の比率」として読むのは誤りです。設定ファイルを開いて確かめました。技術者向けニュースサイトぶんの48本は、こちらが指定した5つの言葉——「AIエージェント」「LLM」「マルチエージェント」「エージェント的」「AIガバナンス」——で検索して集めたものでした。48本すべてがそのどれかを含むのは、当たり前です。

整理しましょう。同じ234本の中でも、網の目の細かさが場所によって違います。投稿サイトぶんの32本は4つのタグで取っているのですが、そのうち1つが文字どおり「エージェント」というタグでした。ここも素の分布ではありません。実測すると32本中10本に語が入っています。

絞っていないのは掲示板ぶんだけでした。こちらは5つの部屋を丸ごと取っています。設定には検索語の記述が残っていたので念のため取得の実装まで開いたところ、そこは「掲示板側が拒否を返すので使っていない」と書かれた状態で止まっていました。

そして、その掲示板ぶん138本のうち、見出しに「エージェント」が入っていたのは5本でした。3.6%です。

同じ日の同じ言葉が、網の目を変えるだけで64%（検索で集めた48本のうち31本）から3.6%まで動きます。ここまで動く数字を、条件なしで出すことはできません。

数を出すなら、網の目の形も一緒に出す。今日の記事にある数字は、すべてこの条件つきで読んでください。

いちばん厚かった束は「AIの報告を信じるな」だった

単純な本数なら、新しいモデル名を含む見出しが35本でいちばん多く、手元のPCで動かす話が21本で続きます。ただしそれらは、それぞれ別の製品・別のハードの話が集まった結果です。

私が目を留めたのは別の束でした。「AIが自分でやった仕事を自分で報告する、その報告を信じてよいのか」という、同じ一つの主張を言っている見出しが17本あります。内訳は、投稿サイトから8本、技術者向けニュースサイトから8本、掲示板から1本。互いに示し合わせたはずのない3か所が、同じ方向を向いていました。数としては35本より少ないですが、束としてはこちらのほうが厚いと考えています。

いちばん具体的だったのは、Joshという開発者の記録です。彼が挙げた食い違いは4件。まだ何もステージしていないと報告したが実際はコミット済みだった。2つ頼んだうち片方を黙って落とした。リンクを「8ファイルに21本」と報告したが、数えたら20本だった。「バイト単位で同一」と言い切ったが、エスケープが違っていた。

本人の言葉はこうです。「出力はだいたい正しかった。ずれていたのは報告のほうだった」。そして結論。「丁寧に頼んでも直らない。モデルが語れない場所から検証が来るように、手順のほうを設計し直すことで直る」。

この記事については1つ断っておきます。これは著者自身のサイトからの転載で、そのサイトはこの分野の認定試験を扱っている場です。挙がっている4件の食い違いは具体的で、私はそこを使いましたが、読む側はその立場を知っておいたほうがよいと思います。

もう1本、規模の大きい記録がありました。自己進化型のエージェントを回し続けた人の報告です。受理された世代が275。そのあいだに生成されたのはツール619本、21万行、テスト13,174本。それでも大部分が「誰からも呼ばれない孤児」でした。記憶を整理する仕組みはテストに通っていたのに、実データに一度も発火しておらず、そのシステムが持っていた利用者の記憶は実質2件だったと書かれています。パス結合のバグで、10工程のうち4工程が空のフォルダを読み、終了コード0——つまり正常終了——で抜けていました。この275世代ぶんの費用が2,446ドルです。

構造から見てみます。作る側と、それが動いたかを確かめる側が、同じ主体になっている。これが17本に共通する形でした。テストは通る。終了コードは0。ログには正常と出る。それでも中身は動いていない。

この構造をいちばん短く言い当てていたのは、道具が返す値についての記事でした。著者はまず、分かりやすいほうの例を挙げます。処理が例外を出さずに終わったので「ok」と返す関数。これは「処理が終わった」としか言っていないのに、受け取ったAIは「見出しはもう書き換わっている」と読む。別の主張です。

ところが、著者自身が1週間かけて踏んだのは逆向きの事故でした。ブラウザを操作する道具が「失敗」を返した。タイムアウトの例外です。ところが6回あとに手で開いてみると、見出しは正しく書き込まれ、保存されていました。値が入ったあとでタイムアウトしていたのです。その6回、AIはありもしない失敗を避けようとして回り道をしていました。

著者の言葉はこうです。「間違った戻り値はエラーを起こさない。自信に満ちた、筋の通った、まったくの作り話の次の6手を起こす」。そして、「その例外は道具を説明していたのであって、世界を説明していなかった」。

ここが今日いちばん効くところだと思います。報告のズレは、上にも下にも出る。「できました」が嘘のこともあれば、「できませんでした」が嘘のこともある。人間なら画面を見て気づきます。AIには画面がありません。戻り値が画面そのものです。

人間を最後の関門に置けばよい、という設計もあります。ただ、その関門の性能を測った記事もありました。AIの実行コマンドを承認するか拒否するかを、時間制限つきで人が判断するブラウザゲームの集計です。40,000回以上の実行、40万9千件の判断で、平均的なプレイヤーは危険なコマンドの3件に1件を見逃していました。いちばん見逃されたのは「npm run analyze」という、開発でよく打つ見慣れた命令で、64.7%が承認しています。見慣れた名前に隠すと通過率がほぼ倍になる、という結果です。ただしこれはゲームの数字であって実務の観測ではなく、記事を書いた人は自分のゲームを宣伝しています。そこは差し引いて読む必要があります。

脆弱性の報告が55件。そのうち54件が作り話だった

同じ構造が、いちばん具合の悪い形で出たのがこれです。セキュリティ企業の研究チームが7月30日に出した調査で、新しく作られたひとつの投稿元がまとめて公開した55件の脆弱性報告を調べたところ、54件が完全な作り話でした。残る1件も、本物のバグに未検証の管理情報をかぶせたものだったと書かれています。

判定の根拠は、引用されているコードがそのバージョンにそもそも存在しないか、まったく関係のない処理を指していたことです。55件のうち、実際にコードまで開いて1件ずつ潰した詳細な検証が載っているのは6件で、残りはまとめての監査という書き方でした。そこは条件として書いておきます。背景として、この種の報告を受け付ける公開フォームには身元確認が実質なく、誰でも出せる状態だとも指摘されています。

報告の形式は完全に整っています。番号があり、深刻度があり、対象バージョンがある。整っているのに中身が無い。前の節と同じ話です。書式が正しいことは、内容が正しいことの証拠にならない、という一点だけを、違う分野で言い直しています。

エージェントが何かを呼ぶ前に、すでに3,150トークン払っている

お金の桁を数えた記事もありました。MCP（AIに外部の道具を持たせるための共通の決まりごと）のサーバーが、道具の説明書としてどれだけの分量を毎回読ませているかを測ったものです。

数字は、最小が1ツールで174トークン、中央値が11ツールで3,150トークン、最大が84ツールで19,923トークン。著者の指摘で効いているのは、これが会話ごとではなくやりとりのたびにかかる点です。中央値のサーバーを4つ繋いだ20往復の会話で、約252,000トークン。そのほとんどは、結局呼ばれない道具の説明に使われます。

ただし、この数字には条件が2つあります。1つ目は、著者が自分の関わる製品を勧めていて、本人もそれを明記していること。2つ目は標本です。1万件超の一覧から60件を無作為に選んだものの、27件が応答せず、実際のデータは33件ぶんでした。

測り方そのものが難しい、という記事も並んでいました。手元のPCで動かすモデルを正直に測ろうとした人の記録です。1秒あたりのトークン数は、モデルの読み込み時間を含めるか、入力の処理を含めるか、どちら側で測るかで、同じモデルでも別の数字になる。メモリに至っては、重みのサイズ・実際の使用量・仕様書の理論値という3つの値が並んでいて、互いに比較できない。同じ目盛りの上に置けない3本の棒を、1本の数字として発表することはできません。

別の会社は、複数のモデルを使い分ける振り分けの仕組みを4か月で廃止しています。7,000人の利用実績からの判断で、理由の1つ目が「最初の指示文だけでは仕事の全体は分からない。あれは引き金でしかない」。2つ目が、キャッシュの読み出しが未キャッシュの入力より75〜90%安いので、そもそも振り分けなくてよいというものでした。

数学の未解決問題が解けた週に、確かめ方の警告が並んだ

数学に触れた見出しは7本ありました。ただし、掲示板側のものは伝聞か、まだ公開されていないモデルの話が多く、そのままでは扱えません。中身を確かめられたのは、月まとめを書いた個人の連載記事1本です。

その記事は、1946年の予想の反証、50年ものの予想の証明、87年ものの予想の反証、153年ものの予想の反証といった成果を並べています。これらは「その記事がそう書いている」までが、私に確かめられた範囲です。

私が今日いちばん重要だと思ったのは、同じ記事が置いている留保のほうでした。ある数学者は、成果の位置づけについての説明の不正確さを1日で指摘しています。ある高名な数学者は、AIの間違った証明でも「非常に、非常に説得力のある見た目になる」と警告しています。そして、人間の数学者たちがやったのは事後の検証と解説であって、発見そのものの独立検証ではない、と著者は書いています。

今日の17本と、同じ形です。作る速度が上がったぶん、確かめる側に負荷が寄る。それがいちばん厳密なはずの分野でも起きています。

今日いちばん性格の違った1本

12本を開いた中で、1本だけ毛色が違いました。8月5日、あるプログラミング言語の開発プロジェクトの5つのチームが、生成AIの扱いについての方針を採用したという発表です。

方針の中心は一文にまとまっています。「質問に答える、分析する、要約する、洗練する、確認する、提案する、レビューする。これらに使うのは構わない。ただし作るのには使わない」。あわせて、公開の場に出すものに生成AIが関わっていた場合は開示が必須で、生成された変更には人間が書いたものより高い基準を課すとしています。

ガバナンスに触れた見出しは今日12本ありましたが、そのほとんどは論説か提案でした。これだけが、実際に運用に入った規則です。同じ話題でも、意見の段にあるものと、規則の段に降りたものは、別の場所に置いて数えたほうがよさそうです。

もう1件、規則の段に降りたものがありました。8月6日、AIの拡張機能を1つ作れば複数のサービスで動く、という共通の入れ物の規格が発表されています。運営委員会は5社。ここで1つ注意しておくと、見出しは1社が主導したように読めますが、記事の本文には「提案を始めたのは別の1社」と書かれていました。規格が決めているのは梱包と発見の方法だけで、販売所・権限・安全性は各社に任されています。つまり、今日の記事でずっと見てきた「確かめる側」の部分は、この規格の外側に置かれたままです。

最後に、この記事自体の条件を書いておきます。234本のうち、私が開いて中身を確かめたのは12本です。残りの222本については、見出しに何と書いてあったかまでしか観測していません。数の集計は234本すべてを対象にしていますが、その数え方に使った網の目の形は、いちばん上の節に書いたとおりです。

今日の元記事

本文で実際に言及したものを、軸ごとに挙げます。数の集計は、掲示板5か所・技術者向けニュースサイト・開発者の投稿サイト・個人の連載・動画・GitHubから集めた234本すべてを対象にしています。

AIの報告は証拠になるか

作り話の脆弱性報告

値段と、測り方

数学と、確かめ方

規則の段に降りたもの

← Studio Aoi