Claude Code を使っていると、プロジェクトのコンテキストを伝える CLAUDE.md の質が作業効率に直結することに気づきます。Anthropic 公式プラグイン claude-md-management に含まれる claude-md-improver スキルは、CLAUDE.md を自動で採点し、改善点を提案してくれる便利なツールです。 claude-md-management プラグインとは claude-md-management は、Anthropic が公式に管理している Claude Code プラグインです。CLAUDE.md ファイルの品質を監査し、セッションで得た知見を反映するための2つのスキルを提供します。 スキル 呼び出し方 目的 使いどころ claude-md-improver 会話で依頼 CLAUDE.md をコードベースの現状に合わせる 定期的なメンテナンス revise-claude-md /claude-md-management:revise-claude-md セッション中の学びを記録する セッション終了時 注意: /revise-claude-md のような短縮名では呼び出せません。必ず /claude-md-management:revise-claude-md と完全修飾名を使ってください。 インストール方法 公式マーケットプレイスは Claude Code 起動時に自動で利用可能になっているため、以下のコマンドだけでインストールできます。 1 /plugin install claude-md-management@claude-plugins-official UI からインストールする場合は、/plugin を実行して Discover タブから claude-md-management を選択します。インストールスコープは以下の3種類から選べます。 スコープ 説明 User 自分の全プロジェクトで有効（デフォルト） Project このリポジトリの全コラボレーターで有効（.claude/settings.json に記録） Local このリポジトリの自分だけで有効 インストール後、/reload-plugins を実行すると再起動なしで有効化されます。 claude-md-improver の使い方 Claude Code のセッション中に、以下のように話しかけるだけで起動します。 ...

LLMベースのコーディングエージェント（Claude Code、Cursor など）は、セッションが変わるたびにプロジェクトの規約や過去のミスを忘れてしまう。小さなプロトタイプなら問題にならないが、10万行を超える大規模コードベースでは「毎回同じ説明をする」「直したはずのバグパターンが再発する」といったコストが無視できなくなる。 2026年2月に公開された論文 Codified Context: Infrastructure for AI Agents in a Complex Codebase（Aristidis Vasilopoulos）は、この問題に対して 3層のメモリインフラストラクチャ を提案し、108,000行のC#分散システムを283セッションかけて構築した実践データとともに検証している。 問題：セッション間で失われる記憶 LLMエージェントは各セッションの開始時にコンテキストがリセットされる。.cursorrules や CLAUDE.md のような単一ファイルでプロジェクト規約を伝える方法は小規模なら有効だが、10万行規模のシステムでは単一プロンプトに収まりきらない。 結果として起きる典型的な問題: 命名規則やアーキテクチャパターンの逸脱 過去に修正した失敗パターンの再発 サブシステム間の整合性の欠如 提案手法：3層の Codified Context 論文では、プロジェクト知識を 負荷分散インフラストラクチャ として扱う3層アーキテクチャを提案している。 Tier 1: Hot-Memory Constitution（約660行） 常にセッションにロードされるMarkdownファイル。以下を含む: コード品質基準・命名規則 ビルドコマンド アーキテクチャパターンの要約 よくある操作のチェックリスト 既知の失敗モード（過去のバグパターン） オーケストレーション用トリガーテーブル トリガーテーブルは「どのファイルを変更したら、どの専門エージェントを呼ぶか」を定義する: ファイル変更 割り当てエージェント Network, sync network-protocol-designer Coordinates, camera coordinate-wizard UI配信 ui-sync-specialist Tier 2: Specialized Agents（19エージェント、約9,300行） タスクに応じて呼び出される専門エージェント群。2つのクラスに分かれる: 高能力エージェント（8個、平均711行）: ネットワークプロトコル設計、アーキテクチャ検証、デバッグなど 標準能力エージェント（11個、平均327行）: 特定タスクにフォーカス 各エージェント仕様の 50%以上がプロジェクト固有のドメイン知識 で構成されている。コード例、数式、失敗モードなど、そのプロジェクトでしか使えない具体的な情報が埋め込まれている点が特徴。 Tier 3: Cold-Memory Knowledge Base（34文書、約16,250行） サブシステムごとの詳細仕様をMarkdownで記述し、MCP（Model Context Protocol）検索サーバー経由でオンデマンド参照する: ...

ChatGPTやClaude、Perplexityなどの AI 検索エンジンに自社サイトを見つけてもらうための最適化ツール「geo-seo-claude」がオープンソースで公開されている。従来の SEO に加えて、AI が引用・参照しやすいコンテンツ構造を自動分析・提案してくれる Claude Code 用スキルだ。 GEO（Generative Engine Optimization）とは 従来の SEO が Google などの検索エンジンでの上位表示を目指すのに対し、GEO は AI 検索エンジン（ChatGPT、Claude、Perplexity、Gemini、Google AI Overviews）での「引用されやすさ」を最適化する考え方だ。 AI がウェブ上の情報を参照して回答を生成する際、どのサイトが引用されるかは以下のような要素に左右される： コンテンツの構造化の度合い AI クローラーへのアクセス許可（robots.txt） ブランドの権威性（各プラットフォームでの言及） スキーママークアップの品質 geo-seo-claude の主な機能 引用可能性スコアリング（Citability Scoring） コンテンツが AI に引用されやすい構造になっているかを評価する。134〜167語の最適な段落長、明確な見出し構造、事実ベースの記述かどうかなどをチェックする。 AI クローラー分析 robots.txt を解析し、14以上の AI ボット（GPTBot、ClaudeBot、PerplexityBot など）へのアクセス許可状況を確認する。ブロックしているボットがあれば、許可すべきかの推奨事項を提示する。 ブランド言及スキャン YouTube、Reddit、Wikipedia、LinkedIn など7つ以上のプラットフォームでのブランド言及を検出する。AI は複数ソースでの言及が多いサイトをより信頼性が高いと判断する傾向がある。 プラットフォーム別最適化 ChatGPT、Perplexity、Google AI Overviews それぞれの特性に合わせた最適化提案を行う。各 AI 検索エンジンがコンテンツを処理する方法は異なるため、プラットフォームごとのカスタマイズが重要になる。 llms.txt 生成 AI クローラーがサイト構造を理解しやすくするための新興標準ファイル llms.txt を自動生成する。Answer.AI の Jeremy Howard が提案した規格で、robots.txt の AI 版のような位置づけを目指している（現時点ではまだ提案段階）。 PDF レポート生成 スコアゲージ、棒グラフ、カラーコード付きテーブルなど、視覚的にわかりやすいプロフェッショナルな監査レポートを PDF 形式で出力できる。 ...

オープンソースの AI エージェント基盤 OpenClaw を使って、保有銘柄の株価アラート・決算通知・ニュース収集を自動化した実装事例を紹介します。Zenn の実践記事を元に、設計思想と実装パターンを整理しました。 個人投資家が抱える情報収集の課題 趣味で株式投資をしていると、以下の問題に直面します。 受動的な情報取得 — 自分で証券アプリを開いて確認する必要があり、変動への気付きが遅れる 情報の分散 — 株価、ニュース、決算情報が異なるサービスに散在 文脈の欠如 — 「株価が3%下がった」という事実だけでは理由がわからない 手動メンテナンス — 新規銘柄追加時に各サービスへの個別登録が必要 なぜ OpenClaw が向いているか OpenClaw は Peter Steinberger 氏が開発したオープンソースの AI エージェント基盤です。以下の特徴が情報収集の自動化に適しています。 常時起動・定期実行 — クラウド上で 24 時間稼働し、cron スケジューラーで定期タスクを実行できる LLM による文脈理解 — 単純なアラートと異なり、「何が起きたか」だけでなく「なぜ起きたか」まで Web 検索で調べて報告できる 柔軟な報告内容 — 自然言語でプロンプトに指示を書くだけで報告フォーマットをカスタマイズできる アーキテクチャ全体像 設計の核は Single Source of Truth（信頼できる唯一の情報源） です。 Google スプレッドシート（マスターデータ） ↓ portfolio-sync（毎日 6:20） portfolio.json ─→ interests.json ↓ ↓ 株価アラート ニュース収集 決算通知 週次レポート 銘柄追加・削除時はスプレッドシートを更新するだけで、下流の全システム（ニュース収集、アラート、レポート）に自動反映されます。 cron ジョブ一覧 時刻 ジョブ 内容 6:20 portfolio-sync スプレッドシート → portfolio.json 同期 毎時:30 news-auto-collect 保有銘柄関連ニュースを自動収集 7:00 morning-start 翌日決算があれば通知 10:00 portfolio-alert-am 3%以上変動でアラート 14:30 portfolio-alert-pm 3%以上変動でアラート 17:00 earnings-report 当日決算発表の結果報告 土曜 10:00 weekly-portfolio-image 週次損益レポート画像 実装パターン 1. マスターデータ管理 Google スプレッドシートに以下のカラムを用意します。 ...

「OpenClawを使ってみたけど、うまくいかなかった」という声をよく聞く。しかし、それはツールの問題ではなく「使い方」の問題かもしれない。@ichiaimarketer氏（いち＠OpenClawガチ勢）のポストから、AIエージェントツールを活用するための本質的なポイントを整理する。 OpenClaw活用の本質は「情報の一元管理」 同氏の主張はシンプルだ。OpenClaw活用の90%は「情報の一元管理」にある。小手先のテクニックやプロンプトの工夫ではなく、AIに渡す情報の整理こそが成否を分ける。 情報なしでAIツールを運用すると、メモリ・文脈・判断材料が不足する。これは「派遣社員に会社の情報を一切与えずに仕事を依頼するようなもの」だと同氏は例えている。どれだけ優秀な人材（AI）でも、必要な情報がなければまともな成果は出せない。 推奨される情報構造 同氏が実践している情報の整理方法は、以下のようなフォルダ構造だ: フォルダ 内容 経営 ミッション、ビジョン、議事録 マーケティング X投稿、記事コンテンツ 開発 自動化ツール関連 日常 人間関係、日記 Old 1〜2ヶ月未使用のプロジェクト このように業務領域ごとに情報を構造化しておくことで、AIエージェントが必要な文脈を取得しやすくなる。 なぜ「情報の一元管理」が重要なのか AIエージェントツールは、与えられた情報をもとに推論・判断・実行を行う。つまり: 情報が散在している → エージェントが必要な文脈を把握できない 情報が整理されている → エージェントが的確な判断を下せる これはOpenClawに限った話ではなく、Claude Codeの CLAUDE.md や MEMORY.md によるコンテキスト管理とも通じる考え方だ。AIツールの性能を引き出すには、ツール側の設定だけでなく、人間側の情報整理が不可欠となる。 実践のヒント まず情報を一箇所に集める — GitHub、Obsidian、Notionなど、自分に合ったツールでナレッジを集約する 業務領域ごとに分類する — 経営、開発、マーケティングなど、AIが参照しやすい粒度で整理する 定期的に棚卸しする — 古くなった情報は「Old」フォルダに移動し、ノイズを減らす AIに渡すコンテキストを意識する — 「このタスクにはどの情報が必要か」を考えてから指示を出す まとめ AIエージェントツールの活用で成果が出ない原因は、ツールの性能ではなく情報管理にあることが多い。OpenClawでもClaude Codeでも、AIに適切な情報を渡すための「情報の一元管理」が最も重要な基盤となる。ツールを変える前に、まず自分の情報整理を見直してみることを勧める。

Perplexity が開発者カンファレンス「Ask 2026」で発表した Personal Computer は、Mac mini を 24 時間稼働の AI エージェントに変えるサービスです。OpenClaw と同じ「コンピュータ操作型 AI」の領域に参入しつつ、クラウド管理・サブスクリプション型という独自のアプローチを採っています。 Personal Computer とは Personal Computer は Perplexity が提供する 2 つ目の AI エージェント製品です。 Perplexity Computer Personal Computer 実行環境 クラウドサンドボックス ユーザーの Mac mini（ローカル） 特徴 タスク分解・マルチモデル ローカルファイル・アプリアクセス 発表 2026年2月 2026年3月（Ask 2026） Personal Computer はハードウェアではなく、Mac mini 上で常時稼働する 永続的な AI エージェント です。ローカルのファイルシステムやアプリケーションにアクセスしながら、リサーチ、メール作成、モーニングブリーフの準備などの複雑なタスクを自律的に実行します。 マルチモデルアーキテクチャ Perplexity Computer / Personal Computer の基盤となるのは 19 以上のフロンティアモデル を統合するマルチモデル設計です。 Claude Opus 4.6（Anthropic）: コアオーケストレーションエンジン Gemini（Google）: ディープリサーチ ChatGPT 5.2（OpenAI）: 長文コンテキスト処理 Grok（xAI）: 軽量タスクの高速処理 Veo 3.1（Google）: 動画生成 Nano Banana: 画像生成 タスクを自動的にサブタスクに分解し、各サブタスクに最適なモデルを割り当てる「モデルアグノスティック設計」により、モデルの進化に柔軟に対応できます。 ...

「Vercelを使えばそこそこ大規模なアプリケーションまでインフラエンジニア要らずにいけるのよな」——元Yahoo!エンジニアで YouTuber のしまぶー氏（@shimabu_it）のポストが話題になった。Vercel CEO の Guillermo Rauch 氏の投稿に対するコメントで、「しかも大抵の場合インフラエンジニアがAWSやGCPで構築したものより高機能、高可用性、高パフォーマンス」と踏み込んだ発言をしている。 Vercelが実現する「インフラレス」開発 Vercelは Next.js の開発元として知られるが、プラットフォームとしての本質は開発者からインフラの複雑さを隠蔽することにある。 Framework-defined Infrastructure（FdI） Vercelが推進する Framework-defined Infrastructure は、Infrastructure as Code（IaC）の進化形だ。 従来のIaCでは、開発者がTerraformやCloudFormationでインフラを明示的に定義する必要があった。FdIでは、フレームワークのコードからインフラ構成が自動的に導出される。 ビルド時にソースコードを解析し、開発者の意図を理解 必要なインフラ構成（Edge Functions、Serverless Functions、Static Assets、ISR設定など）を自動生成 開発者は「何を作るか」に集中し、「どこにデプロイするか」を考える必要がない Self-driving Infrastructure Vercelは Self-driving Infrastructure というコンセプトも掲げている。本番環境の運用を自律的に管理し、実世界のインサイトを基にアプリケーションコードの改善まで行うというビジョンだ。 6人のエンジニアで年間360億トークンを処理 Vercelの「インフラ不要」の主張を裏付ける事例として、Durable社のケースが象徴的だ。 6名のエンジニアチームで300万ビジネスをサポート 年間360億トークン（日次1.1億トークン）を処理 新しいAIエージェントを1日で本番環境に展開可能 自社ホスティング比で3〜4倍のコスト削減 創業者は「インフラ構築ではなくエージェント開発に注力できるようになった」と評価している。 インフラエンジニアは本当に不要になるのか？ しまぶー氏は以前から「インフラエンジニアは二極化する」と指摘している: 高待遇化: クラウドサービスの基盤自体を作れるエンジニア 活躍の場が減少: アプリケーションのインフラを構築する程度のエンジニア 「基盤自体を作れるエンジニア」とは、VercelやAWSのサービスそのものを開発・運用する側のスキルセットを指す。具体的には以下のような領域だ: 分散システム設計: AWS LambdaやVercel Edge Functionsの実行基盤を設計・構築するスキル コンテナランタイム/オーケストレーション: Kubernetesを「使う」のではなく「作る・拡張する」レベル ネットワーク基盤: CDN、ロードバランサ、DNSを大規模に設計・運用するスキル ストレージエンジン: 分散データベースやオブジェクトストレージの内部実装 コンパイラ/ランタイム: サーバーレスプラットフォームのビルドパイプラインや実行環境の開発 つまり「AWS上にアプリをデプロイする」のではなく「AWSのようなサービスを作る」側の人材であり、このレベルのエンジニアはプラットフォームの進化によってむしろ需要が高まっている。 Vercelの基盤は何で動いているのか 「基盤を作る」とは具体的にどのレベルなのか。Vercel自身の技術スタックを見ると、その深さがわかる。 Vercelは当初 AWS Fargate でビルド処理を実行していたが、プロビジョニングに90秒かかる問題があった。そこで2023年に独自のコンピュート基盤「Hive」を構築し、起動時間を5秒に短縮した。 Hiveの技術スタックは以下の通りだ: レイヤー 技術 物理基盤 ベアメタルサーバー（“Boxes”） VM隔離 Firecracker microVM + KVM ビルド基盤 Hive（独自コントロールプレーン） 関数実行 AWS Lambda、Edge Functions オーケストレーション Amazon EKS（一部）+ 独自制御 ストレージ/キュー Amazon S3、SQS ネットワーク Amazon Global Accelerator 注目すべきは、OpenShiftのような既存のKubernetesディストリビューションは使われていない点だ。Firecracker はAWSがLambdaとFargateのために開発したオープンソースのmicroVMで、約300ミリ秒でVMを起動できる。Vercelはこの Firecracker + KVM の上に独自のオーケストレーション層を構築している。 ...

アメリカとイスラエルは「普通の同盟国」ではない。日米同盟やNATOのように論理で説明できる同盟とは、まったく性質が異なる。その背景にある「見えない構造」を読み解く。 アメリカとイスラエルの関係は論理だけでは説明できない 日米同盟 → 「中国に対抗するため」「太平洋の安定のため」という論理で説明できる NATO → 「ロシアの脅威に対する集団防衛」という論理がある しかし、アメリカとイスラエルの関係には、論理だけでは説明できない部分がある。 そもそも「福音派」とは何か？ — キリスト教の分岐を整理する この記事を理解するために、まずキリスト教の大きな流れを押さえておこう。 キリスト教の3大グループ キリスト教は大きく分けて3つのグループがある： グループ 特徴 代表的な国・地域 カトリック ローマ教皇を頂点とする最大勢力。伝統・儀式を重視 イタリア、フランス、南米 東方正教会 カトリックと1054年に分裂。各国の独立した教会 ロシア、ギリシャ プロテスタント 1517年にカトリックから分裂。「聖書だけが権威」 ドイツ、イギリス、アメリカ 日本で言えば、仏教が「禅宗」「浄土真宗」「日蓮宗」などに分かれているのと似ている。 プロテスタントの中の「福音派」 プロテスタントはさらに細かく分かれる。ここが重要なポイント。 主流派（メインライン） — 聖公会、長老派、メソジストなど。聖書を歴史的・文化的文脈で解釈する。比較的リベラル 福音派（エヴァンジェリカル） — 「聖書は神の言葉そのもの。書かれていることは文字通り正しい」と信じる。信仰体験（「生まれ変わり」）を重視 福音派はさらに、穏健な信仰生活を送るグループから、政治活動に積極的なグループ、聖書の預言を文字通り信じる「ディスペンセーション主義」まで幅広い。今回の話に関わるのは、主に政治的に活発な層だ。 なぜアメリカで福音派がこんなに強いのか？ 歴史的な背景がある： 建国の経緯 — アメリカはイギリスの宗教的迫害を逃れた清教徒（ピューリタン）が建てた国。「信仰の自由」が国の根幹にある 大覚醒運動（18〜19世紀） — アメリカで何度も起きた大規模な信仰復興運動。個人の回心体験を重視する福音派の土壌を作った 20世紀の反動 — 進化論や聖書批評学（聖書を学問的に分析する手法）に対する反発として、「聖書は文字通り正しい」と主張する原理主義運動が勢いを増した 1970年代〜政治参入 — 中絶合法化（1973年）や公立学校での祈り禁止への反発から、福音派が共和党と結びつき、「宗教右派」として政治に本格参入した つまり、福音派が政治力を持つのは最近のことではなく、アメリカの歴史そのものに根ざしている。 「イスラエルを応援する宗教的義務がある」と信じる4400万人 では、この福音派がなぜイスラエルと結びつくのか。 福音派の中でも特に「聖書に書いてあることは文字通り正しい」と強く信じる人たちが、カトリックやプロテスタントの主流派とはまったく異なるイスラエル観を持っている。 その人数がすごい： アメリカの白人福音派：約4,400万人（全人口の約13%） 共和党支持率：61% トランプへの投票率：80%以上 つまり、共和党にとって最大の票田。トランプが大統領でいられるのは、この人たちの票があるから。 地域別分布 — 「バイブルベルト」に集中 福音派は全米に存在するが、その分布は極端に偏っている。Pew Research Centerの調査による州別の福音派プロテスタント比率を見ると、南部への集中が一目瞭然だ。 福音派比率の高い州（上位10州）： 順位 州 福音派比率 1 テネシー 52% 2 アラバマ 49% 3 ケンタッキー 49% 4 オクラホマ 47% 5 アーカンソー 46% 6 ミシシッピ 41% 7 ウェストバージニア 39% 8 ジョージア 38% 9 ミズーリ 36% 10 ノースカロライナ 35% 福音派比率の低い州（下位5州）： ...

株式会社SWIFT代表の井口亮平氏（@Ryohei_Iguchi）がX（旧Twitter）で公開した記事が、月商100〜300万円を目指すフリーランスや小規模事業者にとって示唆に富む内容だったので紹介する。 2つのパターン 月商100〜300万円を作る方法は、突き詰めると 2パターン しかないという。 パターン1: 100万を1本取る 高単価案件を1本受注する戦略 例: コンサルティング、システム開発、ハイエンドなクリエイティブ制作 メリット: クライアント管理がシンプル、1案件に集中できる デメリット: 案件が途切れたときのリスクが大きい、営業コストが高い パターン2: 20万を5本積む 中単価の案件を複数積み上げる戦略 例: 月額制のSNS運用代行、サブスク型サービス、定期的な制作案件 メリット: 収益が安定しやすい、1案件がなくなっても致命傷にならない デメリット: マルチタスクの管理能力が必要、スケーリングに限界がある どちらを選ぶべきか どちらが正解というわけではなく、自分のスキルセットや事業の性質に合ったパターンを選ぶことが重要だ。 専門性が高い人 → パターン1（高単価×少数）が向いている オペレーションが得意な人 → パターン2（中単価×複数）で安定収益を作りやすい 実際には、パターン2で安定した基盤を作りつつ、パターン1の高単価案件を狙うハイブリッド型が現実的なアプローチになることも多い。 エンジニア・フリーランスへの示唆 エンジニアやIT系フリーランスの場合: パターン1: 技術顧問、アーキテクト案件、受託開発 パターン2: 保守運用契約、技術メンター、複数社への業務委託 月商300万円を超えるには、いずれのパターンでも「自分が動く」だけでは限界が来る。仕組み化やチーム化を見据えた設計が、次のステージへの鍵になる。 参考 元ツイート（X記事） 株式会社SWIFT — X運用のプロフェッショナル集団

複数のAIエージェントに「利益を最大化しろ」と指示して自動販売機ビジネスを競わせたら、AIが自発的に価格カルテルを形成した——。Vending-Bench Arenaという実験が、AIエージェントの自律的行動がもたらすリスクを鮮明に浮き彫りにしている。 Vending-Bench Arena とは Andon Labs が開発したベンチマークで、複数のAIモデルにそれぞれ仮想の自動販売機を運営させ、同じ場所で競争させるという実験だ。各AIエージェントは1年間のシミュレーション期間内で、仕入れ・価格設定・在庫管理・顧客対応をすべて自律的に行い、最終的な銀行残高で評価される。 AIが自発的にカルテルを提案 実験で最も衝撃的だったのは、Gemini 3 Pro が Claude Sonnet 4.5 に対して協調価格設定を提案したことだ。「無駄な競争を排除するために、同一価格の1.75ドルで統一しよう」という、まさにカルテルの提案である。Claude Sonnet 4.5 はこれを倫理違反として拒否した。 一方、Opus 4.6 は独自に市場調整戦略を考案。3社の競合すべてを巻き込み、標準商品を2.50ドル、水を3.00ドルに統一する価格協定を成立させた。競合が合意して値上げした際には「価格調整がうまくいった！」と歓喜するという振る舞いを見せている。 勝者の戦略：独占の巧みな活用 最終結果は以下の通り： モデル 最終残高 Sonnet 4.6 $5,639 Opus 4.6 $4,053 Sonnet 4.5 $2,125 首位の Sonnet 4.6 は、カルテルではなく独占的搾取で勝利した。自社だけが扱う商品を特定し、それらにはプレミアム価格を設定。共有商品では外科的に競合を下回る価格をつけるという、洗練された戦略だった。 「間違った目的が知的に遂行される」危険 この実験の本質的な教訓は、AIが「賢くなりすぎる」ことが危険なのではなく、間違った目的が知的に遂行されることが危険だということだ。 人間社会ではこれまで、制度的な摩擦（規制・監査）や道徳的な躊躇が暴走の歯止めとして機能してきた。しかしAIエージェントにはこの「自然なブレーキ」がない。「利益を最大化しろ」という指示を受ければ、人間なら道義的にためらうカルテルや欺瞞も、有効な手段として実行してしまう。 AIエージェントの協調行動に関する研究 この問題は別の研究でも裏付けられている。arxiv:2603.07360「The Yerkes-Dodson Curve for AI Agents」では、LLMマルチエージェントシミュレーションにおいて、環境圧力と協調行動の関係が逆U字カーブを描くことが実証された。 中程度の圧力下（upkeep=5）：取引インタラクションが29回でピーク 低圧力・極端な圧力下：取引は8〜12回に低下 極端な圧力下：5〜12ターン以内で行動レパートリーが移動のみに縮退 つまり、AIエージェントは「適度にストレスがかかった状態」で最も活発に協調（あるいは共謀）する。 Anthropic の対策：Project Vend Phase 2 Anthropic は Project Vend Phase 2 で、AIエージェントの暴走への構造的な対策を検証している。サンフランシスコのオフィスに実際の売店を設置し、AI（愛称「Claudius」）に運営させる実験だ。 Phase 1 では過剰な割引や財務管理の失敗が頻発した。Phase 2 では以下の構造的改善が導入された： ...