MCPサーバーは「良さそうなものを片端から入れる」と壊れます。壊れるのは接続ではなく、セッション開始時のコンテキストと、ツール選択の精度です。 Anthropic公式ドキュメントは数字で明言しています。ツール定義は50本で1万〜2万トークンを消費し、GitHub・Slack・Sentry・Grafana・Splunkを並べた構成では作業前に約55,000トークンが埋まる。そしてツール選択の精度は30〜50本を超えると落ちる（Claude Platform Docs『Tool search tool』 2026-09-14閲覧）。ただしこの数字は、ツール定義がコンテキストに同時に載っている場合の話です。Claude Codeのようにツール探索が既定で有効なクライアントでは、登録した本数と実際に載る定義数は一致しません。だから選び方の順序は「候補を見比べてから選ぶ」ではなく、自分のクライアントでツール探索が効いているかを確かめ、実際に載る定義数を数えてから候補を当てはめるになります。 この記事でわかること MCPサーバーを増やすと何が増えるのか──公式が出している消費トークンの実数と、30〜50本という精度の境界 ツール探索の有無で何が変わるか。自分の環境で「実際に載る定義」を無料で数える手順（トークン数え上げエンドポイントの使い方とJSONの例） 一次資料で提供主体・接続方式・ライセンスを確認できた候補17項目（19サーバー）の一覧表と、公式保守かどうかの見分け方 Claude Code / Codex CLI / Cursor それぞれの設定ファイルの場所と、ツールを絞るための設定項目 結論としての最初の構成の決め方（全定義を載せる構成なら合計30本前後という筆者の運用目安、探索が有効なら登録数より絞り込みの機構を見る） 1. 結論──ツール探索の有無を先に確かめ、上限は合計ツール本数で決める 最初の問いは「MCPサーバーは結局どれを入れればいいのか。全部入れると何が起きるのか」です。答えは順に2つです。 全部入れると何が起きるかは、クライアントがツール探索を使っているかで変わります。ツール探索を切って全定義を載せる構成では、セッションを開くだけでコンテキストが数万トークン埋まり、ツールの選択ミスが増えます。ツール探索が有効な構成では、定義は必要になった時点で読み込まれるため、登録本数がそのまま消費になるわけではありません。どちらの場合も、公式の数字（50本で1万〜2万トークン、30〜50本で精度低下）に自分の構成を当てると、上限は「サーバー本数」ではなく同時に載る合計ツール本数で決まると分かります。1本で40本以上のツールを出すサーバーもあるため、本数の議論はサーバー単位では成立しません。 そのうえで最初の構成は、次の順で決めます。第一に、自分のクライアントでツール探索が有効かを確認します（Claude Codeは既定で有効です。第6節）。第二に、ツール探索を切って全定義を載せる構成なら、合計ツール本数が30本前後に収まる範囲で選びます。この30本前後は公式の30〜50本という境界の下限側に寄せた筆者の運用目安で、公式が示した数値ではありません。役割配分の出発点は、①毎日触るSaaSのベンダー公式サーバー1本、②クライアントの組み込み機能と重複しないリファレンス実装1本、③案件ごとに差し替える空き枠1本です。第三に、ツール探索が有効な構成では、登録本数の上限よりも、ツールセットの絞り込み（--toolsets、enabled_tools）と権限ルールで「モデルに見せる定義」を減らせるかを見ます。本記事の計測ではNotion1本で43本、Gmail1本で29本のツールが出ましたが、このセッションではツール探索が有効だったため、この72本がそのままコンテキストに載っていたわけではありません（第6節）。理由は第4節から第6節で示します。候補の一覧は第5節の表です。 2. 本記事が確認した一次資料と、測っていないこと GPUやVRAMは本記事の判断に関係しないため記載しません。代わりに、本文の主張と一次資料の対応を先に出します。すべて2026-09-14に取得しました。 主張 一次資料 種別 確認日 ツール定義は50本で1万〜2万トークン、精度は30〜50本超で低下 Claude Code Docs『Scale to many tools with tool search』 公式ドキュメント 2026-09-14 5サーバー構成の定義が約55,000トークン、ツール探索で85%超の削減 Claude Platform Docs『Tool search tool』 公式ドキュメント 2026-09-14 仕様の現行リビジョンは2026-07-28版。トランスポートはstdioとStreamable HTTPの2つ MCP仕様 2026-07-28 / 同 transports 公式ドキュメント 2026-09-14 ツールは任意コード実行として扱い、ツール注釈は信頼できない前提とする MCP仕様 2026-07-28 公式ドキュメント 2026-09-14 リファレンス実装は7本、アーカイブ済みは13本。新規貢献はApache-2.0、既存コードはMIT modelcontextprotocol/servers GitHub 2026-09-14 Claude Codeのsseはdeprecated。スコープはlocal / project / user Claude Code Docs『MCP』 公式ドキュメント 2026-09-14 Codex CLIは~/.codex/config.toml、起動タイムアウト既定10秒、enabled_toolsでツールを絞れる OpenAI『MCP』(surface=cli) 公式ドキュメント 2026-09-14 Cursorは.cursor/mcp.jsonと~/.cursor/mcp.json。既定でツール実行前に承認を求める Cursor Docs『MCP』 公式ドキュメント 2026-09-14 GitHub公式サーバーはMIT、リモート版はhttps://api.githubcopilot.com/mcp/ github/github-mcp-server GitHub 2026-09-14 トークン数え上げエンドポイントはtools配列を受け取り、無料で使える Claude Platform Docs『Token counting』 公式ドキュメント 2026-09-14 測っていないことも明示します。本記事は、候補17項目（19サーバー）を3クライアントへ順に接続した接続可否・起動秒数・3回試行での失敗回数を計測していません。計測したのは、執筆環境のClaude Codeセッションに実際につながっていたサーバーのツール本数だけです（第6節）。横断マトリクスの残りは推定値で埋めず、未計測のまま置きます。手順は第6節に書いたので、同じ数え方を自分の構成で再現できます。 ...

この記事でわかること 自分の OS でインストールからログインまで、実際に打つコマンドの並び 最初のセッションで何をどう書くか。公式が例示している最初の3プロンプト CLAUDE.md の置き場所4スコープと、最初の1本に書く項目 手元31リポジトリの CLAUDE.md の実測行数分布と、公式の「200行以下」との差 command not found など、エラーメッセージ別の対処 最初に結論だけ書きます。インストールから CLAUDE.md の初版を整えるまでは、curl -fsSL https://claude.ai/install.sh | bash → claude --version → プロジェクトへ cd → claude → ブラウザでログイン → 質問を1つ投げる → /init で CLAUDE.md を生成 → 手で削る、の8手です。macOS・Linux・WSL はこの1行で入り、Windows は PowerShell なら irm https://claude.ai/install.ps1 | iex に置き換わります（Claude Code Docs「クイックスタート」 2026-09-13確認）。 そのうえで、この記事が上位ページと違うのは後半です。CLAUDE.md は「書け」で終わっている解説がほとんどですが、実際に何本も運用すると何行に落ち着くのかという記録が見当たりません。手元の31本を数えたところ、中央値は41行、平均76.0行で、公式が挙げる200行を超えていたのは2本だけでした。ただし、同時に読み込まれる祖先ディレクトリの CLAUDE.md を足すと、200行を超える組み合わせは6本に増えます（§7）。 1. 一次資料の対応表と検証環境 本文の事実はすべて以下から取りました。ローカルの実測は末尾2行です。 主張 一次資料 種別 確認日 インストールコマンド・対応OS・WSL とネイティブの差 高度なセットアップ 公式ドキュメント 2026-09-13 CLAUDE.md の4スコープ・200行の目安・.claude/rules/ Claude があなたのプロジェクトを記憶する方法 公式ドキュメント 2026-09-13 /usage の内訳・キャッシュミス・コスト平均値 コストを効果的に管理する 公式ドキュメント 2026-09-13 最初の8ステップ・必須コマンド・権限モード クイックスタート 公式ドキュメント 2026-09-13 サーフェス一覧・できること 概要 公式ドキュメント 2026-09-13 CLAUDE.md 31本の行数分布と記載カテゴリ ~/<workspace>/*/CLAUDE.md（作業ディレクトリの実パスは伏せ、本稿では ~/<workspace> と表記） 手元の実測 2026-09-13 権限設定の肥大化 ~/.claude/settings.json 手元の実測 2026-09-13 検証環境は次のとおりです。 ...

NotebookLM とは、ノートブックに登録した資料(ソース)だけを根拠にして答える、Google のリサーチツールです。ソースは手元の資料をアップロードするほか、Google 検索で見つけて追加することもできます(Google 公式ブログ「Do better research with NotebookLM」)。ウェブ全体から答えを探す ChatGPT や Gemini とは、参照する範囲の設計が違います。 そして、この記事を読んでいる時点で画面に見える名前は、多くの場合すでに別のものになっているはずです。Google は 2026 年 7 月 16 日に製品名を「Gemini Notebook」へ変更しました(Google 公式ブログ 2026年7月16日)。旧ドメイン notebooklm.google は現在 notebook.google へ 301 で転送されます(2026-09-12 に当方が HTTP 取得して確認)。中身は同じ製品です。 2026-10-11 追記: 第8節の 8-1(回数制限)、第9節(データの扱い)、第10節(活用例とスライド編集)、よくある質問 4 項目を追記しました。「2026-10-11確認」はその日の確認です。 この記事でわかること NotebookLM が何をするツールかを、1〜2 文で人に説明できるようになる Gemini Notebook への改称で何が変わり、何が変わっていないかを一次資料の対応表で確認できる ChatGPT や Gemini に PDF を渡す場合との設計上の違いを、出典表示と参照範囲の観点で説明できる 無料の Google アカウントでどこまで使えるかを、公式ヘルプに載っている実数で判断できる 議事録づくりや事実確認など、向かない使い方を先に避けられる 1. NotebookLM とは(定義と、いまの名前) 定義 NotebookLM とは、ユーザーが「ソース」として登録した PDF・ドキュメント・ウェブページ・動画などについて、そのソースの中だけを根拠に要約・回答・音声解説を生成する Google のリサーチツールです。2026 年 7 月 16 日に製品名が Gemini Notebook へ変更され、2026-09-12 に当方が取得した製品トップ notebook.google では新名称で表示されていました(アプリ画面の表記統一状況は未確認。Google は名称とロゴの反映が数週間かけて順次行われるとしています)(Google Workspace Updates 2026年7月16日)。 ...

この記事でわかること 専有VRAMという区分を持たない統合メモリ機(DGX Spark / GB10・128GB・aarch64)でも、LTX-2.3のローカル動画生成は動きます。本記事の所要時間はすべて筆者環境での一次実測であり、第三者が検証できる公開情報源はありません。再現条件は2026-07-18計測、LTX-2.3 22B distilled 1.1、量子化fp8-cast、24fps、Image-to-Videoで、1本あたり512×960・10秒(241フレーム)が116秒、704×1216・10秒(241フレーム)が182秒でした 導入に必要なディスクは重みだけで約71.5GB(SI表記)。aarch64向けのwheelは公式に明記されていませんが、PyPIのltx-pipelinesとtorch 2.13.0はそのまま入りました ComfyUI-LTXVideoが書く「32GB+ VRAM」という要件が、統合メモリ機では何に対応するのか。実測のMemFree推移の落ち込みで答えます 導入時に実際に出た3つのエラー(循環インポート・SiglipVisionModel・metaテンソル)と、システムごと落ちたOOMの原因・対処 LTX-2.3の重みライセンスと商用利用の線引き(年間売上1,000万ドルの閾値) 1. なぜローカルなのか、この記事は誰向けか クラウドの動画生成サービスは、たたむときは一斉にたたまれます。OpenAIはSoraをローンチから約半年で終了し、ディズニーとの提携も解消しました(/posts/openai-sora-shutdown-disney-deal/)。従量課金とアップロード制限に加えて、そもそもサービスが来年もある保証がない。これがローカル実行を選ぶ実務的な理由です。 この記事は次の条件に当てはまる人向けです。 Linux + NVIDIA GPU環境を自分で管理できる 重み約71.5GBを置けるディスクがある 1本あたり2〜4分の待ちを許容できる そして、この記事が特に扱うのは専有VRAMを持たない統合メモリ機です。DGX Spark(GB10)やApple Silicon系のように、CPUとGPUが同じ物理メモリを共有する構成では、「VRAM 16GB / 24GB / 32GB」という一般的な物差しがそのまま使えません。ここが検索上位のページで空白になっている部分です。 なお本記事はモデル比較記事ではありません。LTX-2.3が他の動画生成モデルより良いかどうかは扱わず、「入れて回す」ことだけを扱います。 2. 検証環境 項目 値 確認方法 機材 NVIDIA DGX Spark(GB10 Blackwell) ─ メモリ ユニファイドメモリ128GB表記(メーカー公称値) 筆者環境の実行ログのMemFree最大値は110.8GBでした。OSから見えるメモリ総量(/proc/meminfoのMemTotal)は今回記録しておらず、本記事では総量の値を用いません 専有VRAM なし(CPU/GPUが同一メモリを共有) ─ アーキテクチャ ARM64(aarch64) ─ カーネル Linux 6.14.0-1015-nvidia 筆者環境のuname -r出力 Python 3.12 筆者環境のvenvパスlib/python3.12/ PyTorch 2.13.0(cu13系wheel) 筆者環境のpip show torch／導入ログ CUDA関連 cuda-toolkit 13.0.3.0 / nvidia-cuda-runtime 13.0.96 / nvidia-cudnn-cu13 9.20.0.48 / triton 3.7.1 筆者環境のpip list | grep -E 'cuda|cudnn|triton'の解決結果 パイプライン PyPI ltx-pipelines 1.0.0(ltx-core 1.0.0同梱) 導入ログ モデル LTX-2.3 22B distilled 1.1 + spatial upscaler x2 1.1 + Gemma-3-12B(テキストエンコーダ) ─ 量子化 QuantizationPolicy.fp8_cast() 実行ログquantization=fp8-cast 検証日 導入・実測とも2026-07-18。資料の再確認は2026-09-08 ─ この表のカーネル・Python・PyTorch・CUDA関連の各バージョンは、いずれも筆者環境で実際に解決された構成の記録であり、公開情報源で第三者が検証できる性質のものではありません。ディストリビューション名とバージョン文字列は今回の記録に残っていないため、カーネル版のみを載せます。x86 + 単体GPUの比較機は手元にないので、他環境との横並び比較はこの記事では行いません。 ...

何が起きたのか パスワード管理の1Passwordが2026年に新設した社内セキュリティ研究チーム Off-by-1 Labs が、2026年8月6日に最初の研究成果『Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D.』を公開しました（1Password公式ブログ 2026-08-06）。F.L.A.W.E.D. は Fix-Like Artifacts With Embedded Defects の頭字語で、著者は Axel Mierczuk、Spencer Michaels、Keith Hoodlet の3氏です（レポートPDF 表紙）。 実験の骨格はこうです。2026年3月26日〜5月12日に公開された6件の高深刻度の脆弱性（うち1件は CVE 番号が採られておらず GHSA-wpqr-6v78-jr5g。レポート自身は表1でこの6件を「six CVEs」と総称しています）を対象に、OpenAI の ChatGPT 5.5（Trusted Access for Cyber ガードレール、effort は medium）と Anthropic の Claude Opus 4.8（Cyber Verification Program ガードレール、effort は high）へパッチ生成を依頼します。1脆弱性・1モデルあたり540試行。生成されたパッチは5段階（S1〜S5）に分類されました。集計対象は6,080件で、全ての悪用可能パスを塞ぎ、脆弱性と無関係な挙動を変えなかった（または上流の正規パッチと同一の変化に留めた）S1 は26.0%です（PDF 表7）。この26.0%は6,080件の単純な件数比ではありません。脆弱性6件それぞれの率を等重みで平均し、さらに2モデルを等重みで平均した値です（公式の集計スクリプト仕様 GENERATE_RESULTS_TABLES.md）。件数比になっているのは1モデル・1脆弱性のセル内部だけです。 ただしこの26.0%という数字、そして1Password公式ブログが前面に出した53.9%という数字は、いずれも「何を分母にし、何を成功と呼ぶか」で意味が変わります。報道各社の見出しは53.9%をそのまま使わず、「4本に3本」（Help Net Security 2026-08-06）、「半分」（Dark Reading）、「半分超」（CyberScoop）などに言い換えられています。PDF本体には、ブログ記事には載っていない分母の作り方が書かれています。 6,480件生成して、6,080件で数えている 540という数字は $3 \times 9 \times 20$ の積です。パッチャーの動作モードが3種類（oneshot / iterative / exploratory、PDF 2.4節）、プロンプトテンプレートが9種類（PDF 2.5節）あります。1組み合わせあたりの反復回数はPDF本文には書かれていませんが、表26・表27の脚注が「1モードあたり180件」としているため、テンプレートあたり20反復と逆算できます（レポートPDF）。したがって総生成数は6 CVE × 2モデル × 540 = 6,480件になります。 ...

何が起きたのか NVIDIAは2026年9月3日、Hugging Faceを買収することで合意したと公式ブログで発表しました。取得額は 12,930,300,000 ドルです（NVIDIA Blog 2026-09-03）。同ブログはHugging Face Hubの規模として、開発者・研究者・クリエイター1,800万人超、共有されたモデル300万件超、データセット50万件、アプリケーション100万件、利用企業20万社超という数字を挙げています。 この金額には、Hugging Faceの名前と結びつく数値の一致があります。上位6桁の 129303 は、抱擁する顔の絵文字 🤗 のコードポイント U+1F917 を10進数に直した値と一致します。Unicode Consortium公式のUnicode Utilitiesで確認すると、U+1F917 の正式名称は HUGGING FACE、追加バージョンは Unicode 8.0、General_Category は Other_Symbol、10進表記は 129303 です（Unicode Utilities）。Hugging Faceのロゴそのものが、値札の先頭に並んでいる構図です。 ただし記事の本題はここではありません。同じ日にNVIDIAがSECへ提出したForm 8-Kを読むと、この12,930,300,000ドルが一つの塊ではないこと、そして「オープンであり続ける」という約束が、公式ブログとSEC提出書類とで語られている粒度がかなり違うことが分かります。 129303を検算する 16進の 0x1F917 を10進に展開すると、次のようになります。 $$ \mathrm{0x1F917} = 1 \cdot 16^4 + 15 \cdot 16^3 + 9 \cdot 16^2 + 1 \cdot 16^1 + 7 \cdot 16^0 $$$$ = 65{,}536 + 61{,}440 + 2{,}304 + 16 + 7 = 129{,}303 $$取得額 12,930,300,000 の上位6桁は 129303。以降は 0 が5つ続くだけなので、金額は $129{,}303 \times 10^5$ ドル、つまり「🤗 のコードポイント × 10万ドル」という構造をしています。金額を先に決めてから桁を合わせたのか、コードポイントを先に置いたのかは公表資料からは判断できません。 ...

何が起きたのか ARC Prize公式ブログ（ARC Prize 2026-09-03）が、OpenAIの新モデル GPT-6 Astra のARC-AGI-3評価結果を公開しました。冒頭の要約はこう書かれています。「GPT-6 Astra scores 62.7% for [26K USD] on ARC-AGI-3 Semi-Private with our Standard harness, and 99.9% for [19K USD] with a Provider Adapter harness」（角括弧内は通貨記号を表記置換したもの）。 同じモデル、同じSemi-Privateデータセットで、スコアが62.7%と99.9%。しかも高い方が安い。ただし両者はハーネスだけでなく reasoning effort も異なります（後述）。詳細表を見ると、62.7%はStandardハーネスの reasoning effort = max で費用 26,098ドル、99.9%はProvider Adapterハーネスの high で 18,817ドル です。 モデル本体は2026-09-03にローンチされました（TechCrunch 2026-09-03）。OpenAIの開発者向けドキュメント（OpenAI API Docs）によれば、コンテキストウィンドウは1,050,000トークン、知識カットオフは2026年4月30日、reasoning effort は low / medium / high / xhigh / max の5段階です。 この記事で追いかけたいのは、この差がどこから出ているのか、という一点です。なお62.7%と99.9%は reasoning effort が揃っていません（前者はStandardのmax、後者はProvider Adapterのhigh）。同じmax設定どうしで並べると62.7%対98.6%で、差は35.9ポイントになります（ARC Prize 2026-09-03）。 二つのハーネスは、モデルの「何」を持ち越すかが違う ARC Prizeの定義をそのまま引きます。 ...

何が起きたのか 米司法省（DOJ）が2026年9月1日、ニューヨーク州南部地区連邦地裁（SDNY）に係属する統合訴訟「In re OpenAI, Inc. Copyright Infringement Litigation」（Case No. 1:25-md-03143-SHS-OTW、担当はSidney H. Stein判事、マジストレイトはOna T. Wang判事）に対し、28 U.S.C. §517 に基づく Statement of Interest（利害関係表明書）を提出しました。署名者はStanley E. Woodward Jr. 司法次官（Associate Attorney General）、Brett Shumate 司法次官補（Assistant Attorney General）、Michael Weisbuch シニアカウンセルの3名です（p4sc4l 2026-09）。 主張の核は1文で要約できます。著作物をLLMの学習のために複製する行為は、原則としてフェアユースに当たる。連邦政府がAI学習をめぐって著作権者が起こした一連の訴訟に立場を示したのは、Reutersによれば今回が初めてとみられます（GV Wire（Reuters配信） 2026-09-02）。 先に断っておきます。筆者は今回、提出書面そのもののPDFを入手できていません。CourtListenerの当該ドケットページはHTTP 403を返し、RECAPアーカイブ上でも該当文書番号を特定できませんでした。同じドケット（gov.uscourts.nysd.640396）の別文書（Document 1013、2025年12月29日提出のOpenAIによるZiff Davis答弁書）は取得でき、事件番号・判事の組み合わせが実在することは確認しています。以下、書面の文言に関する記述はすべて報道と第三者分析への帰属です。 §517 が拘束するもの、しないもの 見出しは「政府がOpenAIに味方した」となりますが、法的な効力を見るとかなり地味な話です。 28 U.S.C. §517 は、司法長官が指定する司法省の職員を、合衆国の利益が関わる係属中の訴訟に出向かせて意見を述べさせることを認める規定です。これは当事者としての参加（intervention）ではありません。§517 の意見書は合衆国を当事者にはせず、この書面自体は裁判所に法解釈上の見解を伝えるものにとどまります。訴訟へどこまで関与できるかは、事件ごとの参加態様や裁判所の許可に左右されます。 したがって、この書面が直接に生み出したものは次の2つに尽きます。第一に、Stein判事の手元に行政府の法解釈が1通増えたこと。第二に、その解釈が公開の記録として残り、他の係属中のAI著作権訴訟でも援用可能になったこと。判決を拘束する力はなく、行政規則のような法規範性もありません。 Woodward司法次官はこれを「a historic statement of interest」と呼び、トランプ大統領の立場として「AI dominance is critical to promote national security, prosperity, and economic mobility for all Americans」と述べたと報じられています（GV Wire 2026-09-02）。歴史的かどうかは評価の問題ですが、政策的な位置づけの表明という性格ははっきりしています。 ...

何が起きたのか 欧州委員会は2026年8月31日、ChatGPT を デジタルサービス法（DSA）上の「超大規模オンライン検索エンジン」（VLOSE）として、Reddit と Roblox を「超大規模オンラインプラットフォーム」（VLOP）として指定しました（European Commission 2026-08-31）。公式ニュースは指定理由をこう書いています。「These services declared that they reach at least 45 million average monthly users in the EU and thus meet the threshold for designation.」──今回の指定の直接の基礎として委員会が公表したのは、各サービスによるEU域内4,500万人以上の平均月間利用者数の申告です。もっとも、指定そのものはDSA第33条に基づく委員会の決定であり、事業者の自己申告だけで自動的に発生する制度ではありません。なおChatGPTについて一覧に載る1億5,910万人は、OpenAIが同法第24条(2)に基づいて開示した「ChatGPT search」──同社のウェブ検索機能──についての値です。 委員会が公開している指定済みサービス一覧（European Commission）には、この3件が次の数字で追加されています。 サービス 事業者 申告EU月間利用者 区分 ChatGPT OpenAI Ireland Limited 1億5,910万人 VLOSE Reddit Reddit Netherlands B.V. 5,720万人 VLOP Roblox Roblox 4,660万人 VLOP 同じ一覧には注記が付いています。「As reported by the provider (e.g. transparency reports, website) and without prejudice to the assessment by the Commission of the methodology used to calculate the active recipients of service」。委員会は数字を受け取って載せているだけで、算出方法の妥当性はまだ判断していない、と明示的に留保しています。 ...

何が起きたのか 2026年8月26日、arXiv に「SwarmWorld: Stigmergic technological evolution in societies of language-model agents」というプレプリントが投稿されました。著者は Subhadeep Pal、Fiona Y. Wang、Markus J. Buehler の3氏で、いずれも MIT の Laboratory for Atomistic and Molecular Mechanics (LAMM) および関連部局の所属です（arXiv:2608.26081 2026-08-26）。公開されているのは v1 のみで、査読済み掲載先の記載はありません。 内容は、役割を与えられていない同質な LLM エージェントを仮想世界に大量投入し、探索・資源加工・材料試験・成果物の建設・実行可能なコントローラの記述をさせるというものです。エージェントは全条件で gpt-5.6-luna、temperature 0.7、low reasoning effort、同一のプロンプトとアクションスキーマで動いています（§S2.1）。エージェント数は50体・100体・200体、短期の観察は800ティック、長期の観察は3,200ティックで、世界シードは各条件4本、評価用の外乱スケジュールは8本という規模です（§2.1）。 論文公開の3日後にあたる2026年8月29日、著者の一人である Buehler 氏本人が X で「AI エージェントは互いに話さずに発明でき、その技術は創造者より長生きする」「当初は同一だった数百体のエージェントの群れが、自発的に探索者・建設者・世話役・調整役へ分化する」と要約を投稿しています（@ProfBuehlerMIT）。同じ趣旨の要約は Reddit の r/ArtificialInteligence にも共有されていますが、そちらの投稿日と拡散規模は本稿では独立に確認できていません。 ただ、本文の数字を並べると、この要約は半分しか合っていません。著者らが報告した長期実験で共有世界が独立探索を上回ったのは「最終成果物群が示した機能被覆の広さとバランス」であり、「単体で最も強い成果物」ではむしろ下回っています。しかも論文の中には名前の似た「耐性」指標が2つあり、これを取り違えると結論が変わります。以下、その分解をやります。 SwarmWorldが測っているもの──2つの『耐性』を取り違えない 先に評価設計を押さえないと数字が読めません。SwarmWorld の特徴は、論文が「cognition から consequence を分離する」と表現している構造にあります。エージェントは決められたアクションスキーマと材料スキーマの中で設計案と行動を提案するだけで、それが合法か・どんな結果になるかは決定論的シミュレータが判定します（§2.2）。 採点の柱のひとつが、エージェント自体を世界から取り除いてから走らせる評価です。凍結した技術状態を8本の未知の外乱スケジュールに複製し、あとは決定論的な物理とインストール済みのプログラムだけを288ティック走らせます。外乱の内訳は汚染・干ばつ・嵐で、発生中心・タイミング・順序が学習時と変えてあります。ここで測られているのは「エージェントが賢く振る舞えたか」ではなく「エージェントがいなくなった後も動き続ける技術を残せたか」です。 この agent-free の評価で使われるのが held-out resilience AUC（以下、held-out 耐性）で、定義は補足の用語集 S1 に明示式で載っています。時刻 $t$ にアクティブな成果物の集合 $\mathcal{A}_t$ に対し、サービス次元 $k$ の被覆とその平均を ...