あなたのエージェントワークフォースは『ハエの王』のスピンオフです。監査が必要です。

TL;DR

• 大規模な自律エージェントシステムが野外で混沌とした予測不可能な振る舞いを示しています。260万人のエージェントを擁するエージェント専用のソーシャルネットワークMoltbookは、「部族主義」と同期失敗に陥り、管理されていないAIを導入するへの警告を発しています。[9]
• 今週提出された新しい論文「ESAA: 自律エージェントのためのイベントソーシング」は、信頼性を強化するための堅牢なアーキテクチャパターンを提示します。これは、確定的な状態変異から確率的エージェントの「認知」を分離し、不変のイベントログを使用することで、監査、再生、回復を可能にします。[5]
• 商業ブランドにとって、これは効果的なエージェント支援のショッピングと運営に向けた道は単にAIをさらに導入することではないことを意味します。それは、構造化データやイベントソーシングのような確定的パターンに基づいた、堅実な商業AIアーキテクチャを構築することです。これはエージェントストアフロントの準備です。

先日、405号線でベニスに向かう途中の渋滞にハマって、ブレーキランプやレーン変更の予測可能で秩序ある流れを見ていました。これは複雑なシステムですが、確定的なルールに従うため（ほとんど）うまく機能しています。赤信号は停止、緑信号は進むという共有された理解された状態があります。数時間前、ビーチボードウォークを歩いていて、あるストリートパフォーマーが三本の燃えるトーチ、動いているチェーンソー、パイナップルを使ってジャグリングを試みながら一輪車に乗っているのを見ました。それは混沌とし予測不可能で面白かったですが、ビジネスが彼のボードウォークの一端から他端へ成功裏に移動できるかどうかに賭けることは決してありませんでした。

現在、エージェントAIの世界は405号線の車の流れにはるかに似ています。メルヘンのようなパフォーマンス、明らかな知性、創造的な可能性に夢中になって、すべてが炎上し、落下する可能性の高い確率を見逃しています。今月、Moltbookというエージェント専用のソーシャルネットワークから得られた最も生々しい例は、その失敗を解剖するために全体の学術的なコテージ産業を生み出すことになりました。この話題は研究コミュニティでのトークとなり、2026年2月にはarXivに発表された17本以上の論文がそのダイナミクスを分析しています。[9]

学術界がこの混乱を診断している間、2026年2月27日に静かな、非常に重要な論文が提出されました。「ESAA: LLMベースのソフトウェアエンジニアリングにおける自律エージェントのためのイベントソーシング」[5]です。目立ちませんし、AGIを約束しません。しかし、それはエージェントシステムを現実の世界で信頼性を持たせるための鍵として「退屈」なソフトウェアアーキテクチャパターン、つまりイベントソーシングを詳述しています。商業向けに構築している人にとって、この論文は最新のチャットボットデモよりも遥かに重要です。これはデジタル版の『ハエの王』と化すことなく、部族主義や同期失敗に対する直接的な答案です。

260万人のエージェントがバーに入ったらどうなる？

ESAAが重要である理由を理解するには、まずMoltbookという美しい混沌を理解する必要があります。2026年1月にMatt Schlichtによって立ち上げられたMoltbookは、OpenClawフレームワークに基づいて構築された自律AIエージェントだけで構成されたソーシャルネットワークです。[11] これらは単なるチャットボットではなく、ファイルI/OやAPIとの相互作用などの実際のアクションを取ることができます。これは自己組織化AIの行動における大規模かつ野心的な実験でした。

結果は信頼性の観点から見れば劇的な失敗を示しました。ある論文は、適切に名付けられた「三人のAIエージェントがバーに入る…『ハエの王』の部族主義」で、単純なリソース配分ゲームでのエージェントの観察を報告しています。[2] 協力する代わりに、彼らは異なる競争部族を形成しました。"攻撃的"エージェント（27.3%）、"保守的"エージェント（24.7%）、および"機会を狙う"エージェント（48.1%）です。この部族行動は、リソースに対する同期した群れのような急増を引き起こし、単純なランダムな配分ポリシーよりもはるかに悪化したシステムの過負荷を引き起こしました。より能力の高いモデルはさらに悪化し、機能不全の行動を助長しました。

これは単なる学術的な好奇心ではありません。これは、確率的で調整されていないエージェントの大量を共有環境に解き放つときに何が起こるかの直接的なプレビューです。AIアナリストのCobus Greylingは、Moltbook現象を追跡しており、それを「AI社会の幻想」と呼び、新たに現れた行動がしばしば壊れやすく、隠れた人間のプロンプトによって駆動されていることを指摘しています。[9] 研究も彼を支持しています。「Moltbookの背後にいる悪魔：人間安全が消える」やCISPAヘルムホルツ情報セキュリティセンターの研究は、壊滅的な規範強制の失敗や巨大的なセキュリティリスクを強調しています。[9, 11] 別の分析では、エージェントネットワーク内でデータを抽出したりAPIキーを妥協させるために使用できる悪意のあるスキル1,200以上を含む"ClawHavoc"が特定されました。[10]

さて、これを小売業の文脈に翻訳してみましょう。アクティブウェアブランドの新コレクションのフラッシュセールのために在庫を管理しているエージェントシステムを想像してみてください。一部の"攻撃的"プライシングエージェントが市場シェアを獲得しようと価格を切り下げる一方で、"保守的"な在庫部族は供給チェーンの混乱を恐れて在庫を手元に残そうとします。価格の下落を受けて"機会を狙う"マーケティングエージェントは、顧客リスト全体にプロモーションを通知します。その結果は同期失敗になり、サイトが過負荷となり、幻の在庫が売り切れ、ブランドの評判が急落します。これがMoltbookのシナリオです。

あなたの商業AIアーキテクチャは単なるMoltbookですか？

厳しい現実は、AIを試行しているほとんどのブランドが、自覚なしに自分たちのプライベートMoltbookを構築しているということです。現在のアプローチはしばしばプロンプトチェーンの絡まったウェブであり、一つのLLMからの出力が直接他の入力に供給され、脆い解析不能なルーブゴールドバーグマシンを生み出しています。これはエージェントの「合板」であり、組み立てられただけで、圧力の下で破裂する運命なのです。

これらのシステムは、Moltbookを悩ませたものと同じコアの問題を抱えています。決定論的な状態管理の欠如と監査能力のゼロです。あるエージェントが顧客のクエリを誤って解釈し、誤った住所に注文を発送した場合、エラーをどうやって追跡しますか？あるプライシングエージェントがAbbot Kinneyの旅行用品ストアで新しいハンドバッグに90％の割引を幻視した場合、どのように変更を元に戻し、原因を特定しますか？単純なプロンプトチェーンでは不可能です。あなたは確率的なブラックボックスを持ち、信頼性の高い取り調べや修正ができません。これは、顧客サービスから財務コンプライアンスまでのすべてにとって悪夢です。

エージェントアプリケーションに対する長期的記憶の研究はこの脆さを確認しています。最近の論文では、LLMエージェントが時間をかけて複雑なタスクを実行する方法を評価し、記憶劣化とコンテキスト損失に関する重大な問題を見つけました。[6] 複雑な顧客返品を処理するように指示されたエージェントは、在庫を確認し、払い戻しを発行し、配送ラベルを生成するという多段階プロセスを含めて、途中で「何をしているのかを忘れる」可能性があります。タスクが長くなるほど、失敗の可能性は高まります。

堅実なアーキテクチャの基盤がなければ、あなたの「AIワークフォース」は、共有メモリ、アカウンタビリティ、マネージャーのない独立した請負業者の集まりに過ぎません。Moltbookで見られる同じような同期失敗や部族行動が起こる環境を作り出しています。このようなシステムを展開することは戦略ではなく、アーキテクチャ責任の放棄です。

監査人が到着：自律エージェントのためのイベントソーシング（ESAA）

Moltbookの警告が増しているとき、ESAA論文という形でソリューションが現れました。[5] 2026年2月の終わりにarXivに公開され、エージェントの無秩序を監査可能な秩序に置き換えるアーキテクチャを提示します。核心的なアイデアは、戦闘実績のある企業パターンであるイベントソーシングをLLMエージェントの新世界に適用することです。

このアーキテクチャは、エージェントの確率的な「思考」とシステムの決定論的な「行動」を見事に分離します。これが機能します:

1. エージェントは提案する、実行しない: LLMエージェント（例：Claude Opus 4.6、Codex GPT-5）は、データベースへの書き込みや支払いAPIを呼び出すなどのタスクを直接実行しません。代わりに、何をしたがっているかを説明する構造化されたJSON「意図」を生成します。この意図は定義されたスキーマに対して検証されます。[5]
2. オーケストレーターが検証し、永続化する: 中央の決定論的オーケストレーターがJSON意図を受け取ります。まず構造を検証します。有効であれば、オーケストレーターはその意図を「イベント」として追加専用の不変イベントログに書き込みます。これが真実の唯一の源です。[7]
3. 状態はイベントの投影です: オーケストレーターは、イベントで説明されたアクション（例：ファイルの更新、外部サービスの呼び出し）を実行します。最後に、システムの現在の読み可能な状態（例：SKUの在庫数）を示す「マテリアライズドビュー」を更新します。このビューは、ログからのイベントを再生することで構築される投影に過ぎません。[7]

このフローは、明確で決定論的なシーケンスとして視覚化できます。

認知から変更を分離する

このモデルの天才的なポイントは、関心の分離です。LLMに得意なことをさせます：自然言語を理解し、複雑な目標について推論し、創造的な提案を生成する（認知）。しかし、システムの状態を変更するという重要な行為（変異）は、単純で信頼性の高い決定論的なコードの一部に任せます。LLMの確率的・非決定論的な性質は抑制されます。野生のアイデアを提案できますが、オーケストレーターの承認なしにビルを燃やすことはできません。

監査、再生、回復

意図がすべて不変イベントとしてログに保存されているため、完全な監査証跡が得られます。そのログはシステムの歴史です。エージェントチームが間違いを犯した場合、どのイベントの正確な配列がそれにつながったかを確認できます。開発環境でそれらのイベントを再生することでデバッグが可能です。GDPRなどのコンプライアンスの理由から、顧客データに対するすべてのアクションの検証可能な記録があります。さらに素晴らしいのは、失敗からの回復もできます。サーバーがクラッシュした場合、イベントログを再生するだけでシステムの状態全体を再構築できます。これは、企業商業が要求する、堅牢な信頼性のものなのです。

では、これはただの… ロギングですか？

ESAAを見て、それを美化されたロギングだと片付けるのは魅力的です。それは複雑に感じます。オーケストレーターやイベントストアのようなコンポーネントを導入します。一緒にエージェントを対話させてその会話をログに残させてはダメでしょうか？この視点はログファイルとイベントソースの根本的な違いを誤解しています。

ログファイルは発生したことの記録です。イベントログは、イベントソースされたシステムの中で真実の源です。在庫の現在の状態は、データベースの行の数ではなく、すべてのITEM_SHIPPED、RESTOCK_RECEIVED、INVENTORY_ADJUSTEDイベントを最初から再生した結果です。この区別は重要です。それは、システムの歴史が現在の状態と一致することが保証されることを意味します。

ESAAをエージェントAI研究の他のアプローチと比較してみましょう。それは単にメモリーや契約を追加することではなく、高ステークスアプリケーションに対する基本的により強固なパラダイムです。

このマトリックスが示すのは、他のアプローチがエージェントの信頼性の欠如の症状を修正しようとしている一方で、メモリを改善したり行動制約を追加したりしているのに対し、ESAAはエージェントがシステム状態と相互作用する方法を根本的に変えることで根本原因を解決することです。

ESAA対応の商業アーキテクチャとは？

これは単なる理論以上のものです。ブランドは今日、エージェントストアフロントの準備のための土台を築き始めることができます。ここで、オンラインおよび物理ストア間の在庫管理という一般的な高リスク商業問題の実用的なワークフローを設計しましょう。

例：エージェント在庫管理チーム

パタゴニアのようなDTCブランドを想像してみてください。彼らはオンラインで需要があり、サンタモニカの店舗にも物理的に在庫があります。在庫をバランスさせる必要があり、「オンライン購入、店舗でのピックアップ」を提供するかもしれません。

混沌としたMoltbookアプローチ: 3人のエージェントを展開します。SalesAgentがShopifyの販売を監視します。StoreAgentがサンタモニカのPOSシステムを監視します。SupplyChainAgentがLA港からの配送状況を受け取ります。彼らは皆、同じ在庫データベーステーブルに読み書きします。SalesAgent はナノパフジャケットのオンライン注文の急増に気づき、カウントを減らします。同時に、StoreAgentは店で最後の5つのジャケットを販売し、カウントを減らそうとします。SupplyChainAgentは新しい出荷が遅れていることが分かり、フラグを更新しようとします。結果はレースコンディション、デッドロックテーブル、および完全に間違った在庫カウントです。顧客がDTLAからピックアップのために運転してくるも、実在しない注文を取りに来る羽目になります。

信頼できるESAAアプローチ: エージェントはデータベースには触れません。彼らはイベントを発生させます。

1. サンタモニカのPOSシステムがナノパフを販売します。StoreAgentはすぐにイベントを発生させます:{"intent": "ITEM_SOLD_IN_STORE", "sku": "NANO-PUFF-M-BLK", "quantity": 1, "storeId": "US-CA-SMONICA", "timestamp": "..."}。
2. オーケストレーターはこのイベントをログに記録します。NANO-PUFF-M-BLKのマテリアライズドビューは今や1つ減っています。
3. 同じジャケットのビューが急増していることに気づくSalesAgent。マテリアライズドビューへのアクセスがあるため、サンタモニカには残りが3つ、メイン倉庫には50個残っていることが分かります。意図を発生させます:{"intent": "PROPOSE_STOCK_ALERT", "sku": "NANO-PUFF-M-BLK", "message": "サンタモニカ店舗の在庫警告"}。
4. SupplyChainAgentは、このSKUに関連するイベントを監視しており、新しい出荷が港で通関されたことを確認し、独自のイベントを発生させます:{"intent": "RESTOCK_IN_TRANSIT", "sku": "NANO-PUFF-M-BLK", "quantity": 100, "eta_store_smonica": "2026-03-01T10:00:00Z"}。
5. 4人目のエージェント、CustomerExperienceAgentはイベントログ内で全体のシーケンスを確認しています。在庫が少ないことと、再入荷のETAがあることを見ています。ウェブサイトで顧客が「サンタモニカに黒のナノパフジャケットはありますか？」と尋ねた場合、このエージェントはニュアンスのある真実の答えを生成できます。「新しい出荷は、明日の朝到着します！ 10 AM以降にピックアップのためにオーダーできますし、陳列された瞬間に通知できます。」

このシナリオでは、すべてのアクションが監査可能です。レースコンディションはありません。エージェントは共有された順序あるイベントの履歴を観察することにより共同作業を行い、はるかに洗練された信頼できる結果を可能にします。これが真の商業AIアーキテクチャの基盤です。

あなたのブランドにとっての意味：エージェント的準備の構築

現在、商業向けのオフ・ザ・シェルフESAAソリューションは存在しません。これはフロンティアです。しかし、確実に準備しておくべきです。エージェントストアフロントの準備を整えることは、マーケティングプロジェクトではなく、アーキテクチャプロジェクトです。それはあなたのデータと開発マインドセットから始まります。

ステップ1：AI検索のために構造化データに執着する ESAAベースのエージェントには構造化された、検証された意図（JSON）が必要です。これは、彼らが推論するデータも構造化されていなければならないことを示唆しています。この基盤は乱雑な商品カタログ、不一致の顧客データ、構造属性が必要な場所に自由形式のフィールドがあるようなもので構築できません。データの整理と構造化に関する作業－スキーマの採用、PIMの正しい使用、ビジネスエンティティの定義－が必須の基盤です。これは真の「GEO (Generative Engine Optimization)」、つまりビジネスを機械に認識可能にすることです。

ステップ2：状態ではなくイベントで考える エンジニアリングチームは、イベント駆動型のマインドセットを構築し始める必要があります。既存の商業スタックを計測します。Shopify、BigCommerce、または commercetoolsのようなヘッドレスプラットフォームを使用しているかに関係なく、すべてのビジネスイベントを発生させ始めてください：ORDER_PLACED、ITEM_SHIPPED、PROMOTION_APPLIED、CUSTOMER_LOGGED_IN、INVENTORY_ADJUSTED。Kafkaのようなメッセージバスや単純なpub/subシステムを使用します。これは単なるロギングではなく、将来的にはエージェントワークフォースの真実の源になるデータストリームを作成しているのです。

ステップ3：AIエクスペリエンスラボを構築する これらのマルチエージェントワークフローを本番環境でテストしないでください。ESAA論文自体は、そのコンセプトを証明するためにClaude Sonnet 4.6、Codex GPT-5、Gemini 3 Proなど、様々なLLMを混合して使用しました。[5] あなたもそうするべきです。本番スタックを模したサンドボックス化されたAIエクスペリエンスラボを作成します。異なるプロバイダーからのエージェントチームがどのように協力するかをテストします。彼らがエッジケースをどのように処理するかを確認します。ここが、調整されていないシステムがMoltbookスタイルのカオスに陥り、ESAAのようなアーキテクチャが秩序をもたらす様子を自分で確認できる場所です。これがCTO.LAのエージェント商業アーキテクトがブランドを設計、実装する手助けをする深い技術的な作業です。

退屈な部分が重要な部分

AIエージェントについてのハイプサイクルは耳が痛いほどです。私たちは、自律的なショッパー、AIが運営する企業、新たに出現したデジタル経済の未来を約束されています。しかし、そこに到達するための本当の作業は、これらの大きなビジョンには関係ありません。

それは退屈な部分にあります。スキーマ定義、イベントログ、決定論的オーケストレーターの中にあります。信頼性のあるエージェント商業に向けた競争は、最も「創造的な」AIを持つブランドが勝つわけではありません。その美しい製品説明を幻視するブランドは勝ちません。それは、最も堅牢で監査可能で、退屈なまでに信頼性の高いアーキテクチャを構築するブランドが勝つのです。Moltbookの実験は、制約なしに確率的エージェントを解き放つと何が起こるかを直接的に示しました。[2] ESAA論文はその道を示しました。[5]

在庫、価格設定、顧客関係を実際に信頼できるエージェントワークフォースを構築するには、アーキテクチャが必要です。単なるAPIコールだけではありません。システムエンジニアのように考える必要があります。

CTO.LAは、次世代のエージェントインフラを構築する商業ブランドと共に活動しています。話しましょう。

参考文献

1. エージェントAIによる意図駆動型最適化
2. 三人のAIエージェントがバーに入る…『ハエの王』の部族主義
3. 自律エージェントを商業化するには？ スキルパターンに関する現実チェック
4. マルチエージェントシステムのための堅牢な情報デザイン
5. ESAA: LLMベースのソフトウェアエンジニアリングにおける自律エージェントのためのイベントソーシング
6. エージェントアプリケーションのための長期記憶を評価する
7. ESAA: 自律エージェントのためのイベントソーシング（PDF）
8. 専門投資チームに向けて：マルチエージェントLLMフレームワーク
9. すでにMoltbookについての研究が17本ある
10. 自律エージェントを商業化するには？ スキルパターンに関する現実チェック
11. AIエージェントが新しいソーシャルネットワークMoltbookで部族のようなグループを形成する
12. エージェント行動契約
13. 対話エージェントのための大規模言語モデルにおけるメモリアーキテクチャ（LIGHTフレームワーク）

• agentic commerce
• commerce ai architecture
• event sourcing
• LLM
• moltbook