Anthropic が 2026 年 4 月 7 日に発表した Claude Mythos Preview は、同社史上最も高性能な汎用言語モデルでありながら、一般公開が見送られた異例のモデルです。同モデルはサイバーセキュリティ分野で突出した能力を示し、主要 OS やブラウザに潜む数千件のゼロデイ脆弱性（開発者が認識する前に存在する未修正のセキュリティ上の欠陥）を自律的に発見・悪用できることが確認されました。 この発表はセキュリティ業界だけでなく金融業界にも波紋を広げ、米国の財務長官や FRB 議長、ウォール街の CEO たちが緊急招集される事態にまで発展しています。 Claude Mythos Preview のベンチマーク性能 Mythos Preview は、従来の Claude Opus 4.6 を大幅に上回るベンチマーク結果を示しています。SWE-bench Verified では 13 ポイント以上、USAMO 2026 では 55 ポイント以上の向上を記録しました。 評価項目 Mythos Preview Opus 4.6 SWE-bench Verified 93.9% 80.8% USAMO 2026 97.6% 42.3% CyberGym（脆弱性再現） 83.1% 66.6% SWE-bench Pro 77.8% 53.4% Terminal-Bench 2.0 82.0% 65.4% 特にサイバーセキュリティの領域では、「ほぼすべての熟練した人間のセキュリティ研究者を上回る」と Anthropic 自身が述べています。 Mythos Preview が発見したゼロデイ脆弱性 Mythos Preview が内部テストで発見した脆弱性は衝撃的です。 ...

AIエージェントプラットフォームの世界で、OpenClaw から Hermes への乗り換えが予想以上の速さで進んでいるという観測が SNS 上で広まっている。 ポイント 韓国の技術インフルエンサー Cognac（꼬냑）氏が X（旧 Twitter）に投稿した内容によると、最近 OpenClaw から Hermes に切り替えるユーザーが増えているとのこと。その理由として以下の 5 点が挙げられている。 再帰的メモリの改善で Hermes が圧勝 エージェントが過去の文脈を再帰的に参照して学習・記憶を改善する仕組みが Hermes のほうが優れているとされる。 チーム単位ではなくエンタープライズ単位での管理 組織全体での一元管理が可能なエンタープライズ向け機能が充実している。 エンタープライズレベルでのスキル作成で信頼性が向上 大規模組織での運用実績が積み重なり、Hermes のスキル（機能拡張）に対する信頼感が高まっている。 開発チームおよび会社の対応が非常に迅速 不具合報告や機能要望に対するフィードバックループが速く、ユーザーの信頼を獲得している。 GitHub からのコピー＆ペースト不要で自動アップデート OpenClaw では GitHub からスキルや設定を手動でコピーする手間があったが、Hermes は自動更新で手間が少ない。 OpenClaw との比較 OpenClaw はこれまで AIエージェントのスキル管理や Claude Code との連携で注目されてきたプラットフォームだが、以下の点でユーザーの不満が蓄積しているようだ。 エラーの多さとレスポンスの遅さ スキルの手動管理（GitHub からのコピー＆ペースト作業） エンタープライズ向け機能の不足 一方 Hermes は、再帰的メモリの技術的優位性とエンタープライズ対応、迅速な開発サイクルを武器に、OpenClaw ユーザーの取り込みを加速させている。 まとめ AIエージェントプラットフォームは機能面だけでなく、開発チームの対応速度 や エンタープライズ対応 など非技術的な要素でも差がつく時代になっている。今後も Hermes と OpenClaw の競争から目が離せない。

完全オープンソースで動く AI 同僚ツール「Rowboat」が注目を集めている。音声制御、MCP ツール連携、バックグラウンドエージェントなど、有料 AI アシスタントサービスに相当する機能を、データをローカルに保ったまま利用できる点が特徴だ。 Rowboat とは Rowboat（rowboatlabs/rowboat）は「Open-source AI coworker, with memory」を謳う AI 同僚ツール。GitHub スター数は 12,000 以上（2026年4月時点）に達しており、急速に注目が高まっている。 主な特徴は以下の通り。 100% ローカル動作 — データが外部に出ない 音声制御 — リアルなアシスタントのように話しかけられる 任意の LLM に接続可能 — Claude、GPT-4 系などを選択できる MCP ツール + Obsidian ブレイン — ナレッジグラフと外部ツールを組み合わせた記憶管理 バックグラウンド自律エージェント — 裏側で自律的にタスクをこなすエージェント群 知識グラフの自動構築 — 会話・作業履歴から知識を蓄積 ローカルで動く AI 同僚のインパクト これまでの AI アシスタントの多くはクラウド型であり、プロンプト・ドキュメントなどのデータが外部サーバーに送信される仕組みだった。Rowboat はすべてローカルで処理するため、機密情報を扱う業務でも安心して利用できる。 また、任意の LLM を接続できる柔軟性も魅力だ。Anthropic の Claude を接続しながら推論はローカルで完結させるといった構成も可能で、API コストの制御がしやすい。 MCP ツール連携と Obsidian ブレイン Rowboat が対応している MCP（Model Context Protocol）は、AI ツールが外部サービスや情報源と標準化されたインターフェースで通信するためのプロトコルだ。これにより、ファイルシステム、Web 検索、カレンダーなど様々なツールをエージェントに組み込める。 ...

LangChain の創設者 Harrison Chase が 2026年4月11日に公開した記事「Your harness, your memory」を読んだ。AI エージェント開発におけるハーネス（harness）とメモリの密接な関係、そしてクローズドなハーネスがもたらすロックインの危険性を指摘する内容だ。本記事ではその要点を整理し、エージェント開発者が考慮すべきポイントを解説する。 エージェントハーネスとは何か エージェントハーネスとは、LLM がツールやデータソースとやり取りするための「足場」を提供するシステムだ。テストハーネスがテスト実行環境を支える外枠であるように、エージェントハーネスはエージェントの実行環境を支える外枠を指す。Chase は以下のような進化の流れを示している。 RAG チェーン時代（2023年〜）: ChatGPT 登場直後、シンプルな検索拡張生成（LangChain） 複雑なフロー時代: モデルの改善に伴い、より複雑なワークフローが可能に（LangGraph） エージェントハーネス時代（現在）: モデルの大幅な性能向上により、新しい種類の足場が登場 具体的なエージェントハーネスの例として、Claude Code、Deep Agents、Pi（OpenClaw を駆動）、OpenCode、Codex、Letta Code などが挙げられている。 Chase は「モデルがハーネスの機能を吸収していく」という意見に反論する。2023年に必要だった足場の多くは不要になったが、それに代わる新しい種類の足場が登場している。エージェントは定義上、LLM がツールやデータとやり取りするものであり、その相互作用を仲介するシステムは常に必要だ。Chase はその根拠として、Claude Code のソースコードが51万2000行に及ぶ規模を挙げている。 エージェントハーネスとメモリが切り離せない理由 Chase は Letta の CTO Sarah Wooders のブログ「memory isn’t a plugin (it’s the harness)」を引用し、ハーネスとメモリは不可分だと主張する。 メモリをエージェントハーネスにプラグインしてほしいと頼むのは、運転を車にプラグインしてほしいと頼むようなものだ。コンテキストの管理、すなわちメモリの管理は、エージェントハーネスの中核的な能力であり責任だ。 メモリはコンテキストの一形態に過ぎない。ハーネスが管理するコンテキストには以下が含まれる。 短期メモリ: 会話内のメッセージ、大きなツール呼び出し結果 長期メモリ: セッションをまたぐ記憶（クロスセッションメモリ） 設定ファイル: AGENTS.md や CLAUDE.md のロード方法 スキルメタデータ: エージェントへの提示方法 コンパクション（要約による圧縮）: 長い会話履歴を要約して短縮する際、何が残り、何が失われるか これらすべてがハーネスの設計に依存しており、メモリを独立したサービスとして切り離すことは現時点では現実的ではない。 エージェントにおける「メモリ」の実体 Chase の記事では「メモリ」が抽象的に語られているが、その実体は大きく4つの層に分けられる。それぞれの層がなぜハーネスと切り離せないのかを具体的に見ていこう。 第1層: コンテキストウィンドウ内のメッセージ履歴 最も基本的なメモリの実体は、LLM に渡される会話メッセージの配列だ。ユーザーの発言、アシスタントの応答、ツール呼び出しの結果がすべてこの配列に格納される。 ...

AIモデルのリリース後、時間が経つにつれてパフォーマンスが落ちた気がする——そんな経験をしたユーザーは少なくないだろう。最近、SNS上でこの「体感」に関する興味深い主張が話題になった。 「性能放血」戦略という仮説 中国のテック系アカウント「墓碑科技（mubeitech）」が2026年4月10日に投稿したツイートは、約21万回以上閲覧され、1,600件以上のいいねを集めた。 その内容はこうだ： OpenAI・Google・Anthropicは同様の戦略を採用している。新モデルのリリース初日には性能が最高（100%）に達し、その後「放血」と呼ぶ数ヶ月間の段階的な低下を経験し、最終的に約60%まで落ちる。この目的は、次世代製品リリース時に「劇的な改善」を強調するためだ。 このパターンを同氏は「放血（bloodletting）」と表現した。意図的に性能を落としておき、次世代モデルの登場時に比較対象を都合よく用意するという戦略的操作だという主張だ。 この主張の背景 同様の「体感」を持つユーザーはこれまでにも多く、特にGPT-4が登場直後より時間が経つにつれ「鈍くなった」「回答が短くなった」と感じるユーザーの声はX（Twitter）やRedditで繰り返し話題になってきた。 一方で、OpenAIは過去にGPT-4モデルへの変更内容を公開し、変化があったことを認めつつも「意図的な品質低下」は否定している。また、2023年に行われたスタンフォード大学の研究（“How Is ChatGPT’s Behavior Changing over Time?"）では、GPT-4の一部タスクで時間的な性能変動が確認されたことも報告されている。 なぜこの主張が広がるのか ユーザーの体感との一致: モデルの応答品質の変化はユーザーが実感しやすく、「意図的」という説明が腑に落ちやすい 商業的インセンティブへの不信感: 次世代モデルの販促のために旧モデルを陳腐化させるというシナリオは、ビジネス的に合理的に見える 検証困難性: APIの内部変更は外部からの完全な検証が難しく、陰謀論的な解釈が入り込みやすい 実際のところはどうなのか 「意図的な性能低下」説については、現時点で公開情報による明確な裏付けはない。ただし、以下のような要因で性能変動が起きることは事実だ： モデルの量子化・最適化: コスト削減のためにより軽量な推論方法に移行することで、一部タスクの精度が変化する 安全性フィルタリングの調整: ガイドラインの変更により、出力の傾向が変わることがある プロンプト処理の変更: 内部のシステムプロンプトや前処理ロジックの変更が応答に影響する インフラのスケーリング: 急激なユーザー増加に対応する際の一時的なサービス品質の変化 まとめ 「意図的放血戦略」は現時点では未確認の仮説だが、AIモデルの品質管理と透明性に対するユーザーの関心の高さを示している。実際、リリース初期と数ヶ月後でモデルの挙動が変わることは多くの利用者が実感しており、各社がより詳細な変更履歴を公開することで、こうした不信感を払拭できる余地はあるだろう。 AI企業の透明性とユーザーの信頼構築は、今後ますます重要な課題となっていきそうだ。

Anthropic が 2026 年 4 月 10 日に公開したブログ記事「Multi-agent coordination patterns: Five approaches and when to use them」では、複数のAIエージェントを協調させるための 5 つのパターンが紹介されています。 それぞれのパターンを整理してみます。 1. Generator-Verifier（生成・検証） 概要: 一方のエージェントが出力を生成し、もう一方のエージェントが明示的な基準に照らして検証します。検証が失敗した場合、フィードバックが生成エージェントに戻り、条件を満たすか最大反復回数に達するまでループします。 向いているケース: コード生成＋テスト実行のような、品質が最重要でかつ評価基準を明確に定義できるタスク。 注意点: 検証の質は定義した基準の質に完全に依存します。評価基準の設計を省略すると、「品質管理をしているという幻想」だけが残ってしまいます。 2. Orchestrator-Subagent（オーケストレーター・サブエージェント） 概要: リーダー役のエージェントが作業を計画し、専門化されたサブエージェントに明確な境界付きのタスクを委任します。サブエージェントは作業を実行し、結果をオーケストレーターに返します。オーケストレーターは各結果を統合して最終的なアウトプットを生成します。 向いているケース: セキュリティ・テストカバレッジ・スタイルをそれぞれ別エージェントが担当するコードレビューのように、サブタスクの依存関係が少ない明確なタスク分解ができる場合。 注意点: サブエージェント同士で発見した情報に依存関係が生じると、オーケストレーターが「情報のボトルネック」になります。また、明示的に並列化しない限り、サブエージェントは逐次実行されるためスループットが制限されます。 推奨: Anthropic は「大半のユースケースでまず試すべきパターン」としてこのパターンを位置づけています。最も問題の幅広さをカバーしつつ、調整のオーバーヘッドが最小限です。 3. Agent Teams（エージェントチーム） 概要: コーディネーターがキューからタスクを取得する 永続的な ワーカーエージェントを生成します。ワーカーは複数のステップにわたって自律的に作業し、担当コンポーネントのドメイン知識を蓄積します。 向いているケース: 大規模コードベースのサービス移行のように、エージェントが担当範囲に習熟しながら並列で長期間実行するタスク。 Orchestrator-Subagent との違い: サブエージェントが単発タスクで消えるのに対し、チームワーカーはアサインをまたいで生存し続けるため、ドメイン知識が蓄積される。 注意点: タスク間の独立性が必要で、エージェント同士が中間結果を共有しにくい。タスク時間がばらつく場合、完了検知が難しくなります。 4. Message Bus（メッセージバス） 概要: エージェントが共有ルーターを介してトピックをパブリッシュ・サブスクライブします。ルーターはマッチングメッセージを配信しますが、実行順序はあらかじめ決まっていません。 向いているケース: セキュリティアラートが多段階の調査を動的にトリガーするようなイベント駆動パイプラインで、どのエージェントが関与するかがリアルタイムに決まる場合。 注意点: イベントが複数エージェントを連鎖的にトリガーすると、トレーサビリティが困難になります。ルーターがイベントを誤分類すると、エラーが静かに発生します。 5. Shared State（共有ステート） 概要: 中央コーディネーターを置かず、エージェントが永続ストレージに直接読み書きします。エージェントは他エージェントの発見をリアルタイムで参照しながら協調的な知識を蓄積します。 向いているケース: 一方の調査結果が即座に他方のエージェントの探索方向に影響する、協調型のリサーチタスク。単一障害点がなくなるというメリットもあります。 注意点: 収束条件がないとエージェントが際限なく反応し合い、トークンを無駄に消費します。「時間予算・収束閾値・終了エージェントの指定」のいずれかによる明示的な終了条件が必須です。 ...

メルカリが「Claude Code Meetup Japan #4」で公開した資料が注目を集めている。エンジニアだけでなく非エンジニアにもClaude Codeを全社展開するにあたって実施したセキュリティ設定と、MDMを活用した組織配布の実践的な戦略が体系的にまとめられている。 Claude Codeがもたらすリスク Claude Codeは非常に強力なツールだが、その強力さゆえにセキュリティリスクも伴う。具体的には以下の操作が可能なため、適切な制限なしに利用すると重大な問題につながりかねない。 ファイルの検索・読み書き・編集 Webページの取得・検索 任意のコマンドの実行（rm -rf や curl など） PCに保存されている認証情報（APIキー、AWSクレデンシャルなど）や重要なファイルに、LLMが直接アクセスできてしまう状態は大きなリスクとなる。 メルカリが実施した5つのセキュリティ対策 メルカリのAI Security Teamはこれらのリスクに対し、以下の5つの対策を実施した。 1. バイパスモードの禁止 --dangerously-skip-permissions などのバイパスオプションを利用禁止にし、ユーザーによる確認ステップを必ず経由させる。LLMが自律的に危険な操作を実行できないようにする基本的な設定だ。 2. 危険コマンドの確認必須化 bash の実行や curl による外部通信など、影響範囲の大きいコマンドは都度ユーザーの確認を求めるように設定する。自動承認させずに人間が内容を確認してから実行させる。 3. 危険な操作の禁止 環境変数の読み込み（APIキー等の漏洩を防ぐ） sudo によるシステム管理者権限での操作 これらを設定レベルで禁止することで、意図しない権限昇格やクレデンシャルの流出を防ぐ。 4. Sandboxによる操作範囲の制限 作業ディレクトリ外へのファイルアクセスを制限 不要なネットワークアクセスを制限 Sandboxを活用することで、Claude Codeの操作範囲を必要最小限に絞り込む。 5. セキュリティポリシーのシステムプロンプトへの組み込み 社内のセキュリティポリシーをClaude Codeのシステムプロンプト（CLAUDE.md など）に直接記述する。LLM自体にセキュリティ意識を持たせる「教育」的なアプローチだ。 組織配布の課題と解決策 全社員に安全な設定を届けるうえで、メルカリが直面した課題がある。エンジニアと非エンジニアで求める設定のニーズが相反するという点だ。 対象 ニーズ エンジニア 柔軟にカスタマイズできる設定 非エンジニア 何も考えなくても安全な初期設定 MDMを活用した属性別の設定配布 メルカリはMDM（Mobile Device Management：端末管理システム）と連携し、社員属性（エンジニア / 非エンジニア）に応じて配布する設定を分離した。 非エンジニア向け: 最も制限が強い安全な設定を自動適用。ユーザー側での変更を不要にする エンジニア向け: 基本的な安全性を担保しつつ、業務に応じたカスタマイズを許容する これにより、全社員が「最初から安全な環境でClaude Codeを使える」状態を実現している。 企業でClaude Codeを導入する際のポイント メルカリの事例から、企業導入に際して押さえておきたいポイントをまとめる。 ...

前回の記事では Claude Managed Agents の概要と業界インパクトを紹介した。本記事では、Anthropic のエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」に基づき、内部アーキテクチャを掘り下げる。 全体アーキテクチャ Claude Managed Agents は4つのコアコンセプトで構成される。 コンセプト 説明 Agent モデル、システムプロンプト、ツール、MCP サーバー、スキルの定義 Environment コンテナテンプレート（パッケージ、ネットワークアクセス、マウントファイル） Session Agent と Environment を参照して起動される実行インスタンス Events アプリケーションとエージェント間でやり取りされるメッセージ（SSE） これらの背後には、Brain / Session / Hands という3層の分離設計がある。 設計思想: OS の抽象化パターン Anthropic はこのアーキテクチャの設計思想を、OS がハードウェアを抽象化した歴史に重ねている。 1970年代のディスクパックでも現代の SSD でも、read() コマンドは同じように動く。ハードウェアの実装が変わっても、その上の抽象化層（プロセス、ファイル）は安定し続けた。 Managed Agents も同じパターンを採用している。Session、Harness、Sandbox というエージェントのコンポーネントを仮想化し、インターフェースは安定させたまま、内部実装を自由に交換できる構造にした。Anthropic はこれを「メタハーネス」と呼んでいる。 なぜこの設計が必要なのか。ハーネスには「モデルが自力でできないこと」に関する前提が埋め込まれるが、モデルの能力が向上するとその前提が陳腐化する。例えば Claude Sonnet 4.5 では、コンテキスト制限が近づくとタスクを早期終了する「コンテキスト不安（context anxiety）」が見られた。そこでハーネスにコンテキストリセットを追加した。しかし Claude Opus 4.5 ではこの振る舞いが消え、リセット機能は無駄な荷物になった。 ...

2026年4月8日、Anthropicが「Claude Managed Agents」をパブリックベータとして公開した。AIエージェントの本番運用に必要なインフラをすべてマネージドで提供するサービスで、エージェント構築のコストと期間を劇的に削減する。 Claude Managed Agents とは Claude Managed Agents は、AIエージェントの構築・デプロイ・運用に必要なインフラを一括提供する API スイートだ。開発者はモデル、システムプロンプト、ツール、MCP サーバーを定義するだけで、本番レベルのエージェントを稼働させられる。 提供される主な機能: セキュアなサンドボックス: エージェントの実行環境を安全に分離 長時間実行セッション: 数時間にわたるタスクも途中状態を維持しながら処理 状態管理: コンテキストウィンドウの外に永続的なセッションログを保持 マルチエージェント連携: 複数のエージェントが協調して動作するフリート管理 MCP 統合: HubSpot などの外部サービスと即座に連携可能 スコープ付き権限管理: エージェントごとに適切なアクセス制御を設定 platform.claude.com から利用でき、API 従量課金に加えてセッション時間あたり $0.08 の料金が発生する。 エージェント構築市場へのインパクト この発表が業界で大きな反響を呼んでいるのは、エージェント構築の構造そのものを変える可能性があるためだ。 開発期間の短縮 これまでエージェントを本番運用するには、サンドボックス、状態管理、認証、長時間実行、マルチエージェント協調といったインフラを自前で構築する必要があった。Claude Managed Agents はこれらをすべてマネージドで提供するため、月単位だった開発が日単位に短縮される。 既存プレイヤーへの影響 LangChain は Deep Research エージェントだけで1年かけて4つのアーキテクチャを開発してきた。Manus は6ヶ月で5回のハーネス書き直しを行った。Anthropic はこうした領域をファーストパーティのマネージドサービスとして一気に抽象化した形だ。「Claude を本番で安定稼働させる」ことを売りにしていたエージェントスタートアップにとっては、ビジネスモデルの根本的な見直しを迫られる状況と言える。 AWS のサーバーレス革命との類似 企業が求めているのは「エージェントのインフラを構築すること」ではなく「動くエージェント」そのものだ。AWS がサーバー管理を EC2 で抽象化したのと同じ構造で、Anthropic はエージェント構築という市場そのものを縮小させる可能性がある。 既に本番運用している企業 Anthropic の発表によると、Notion、Rakuten、Asana、Sentry がすでに Claude Managed Agents を本番環境で運用している。公式デモのダッシュボードでは、複数のエージェントがフリートとして稼働しタスクを処理している様子が確認できる。 OpenClaw 遮断との関連 発表の4日前、Anthropic は OpenClaw をはじめとするサードパーティ製ハーネスによるサブスクリプション認証情報の利用をブロックした。消費者向け認証レイヤーの上にサービスを構築することを止め、代わりにファーストパーティのマネージドプラットフォームを提供するという戦略が明確になった。 ...

2026年4月7日、AWSがAmazon S3 Filesを一般提供（GA）しました。S3バケットをNFS v4.1/v4.2のファイルシステムとしてマウントできる機能で、EC2・EKS・ECS・Lambdaのいずれからでも利用できます。 本記事は、ikenyal氏のZenn記事「S3 Filesで消えるアーキテクチャ層、生まれるアーキテクチャ」を参照しながら、S3 Filesが既存のアーキテクチャにどう影響するかを整理します。「何が設定できるか」ではなく「何が不要になり、何が可能になるか」にフォーカスします。 S3 Filesが解こうとしている問題 たとえば、MLチームが学習データの前処理をする場面を考えましょう。元データはS3に置いてあり、pandasで読み込んで加工したい場面です。 pd.read_csv("s3://my-bucket/data.csv") と書けますが、内部ではboto3がGETリクエストを発行してメモリに読み込んでいます。手元の open("./data.csv") とは根本的に異なるI/Oモデルです。 規模が大きくなると、これは「パイプラインのアーキテクチャ課題」になります。 S3からEFS/EBSにコピー → 処理 → 結果をS3に書き戻す この「中間のコピー層」は本来やりたい処理ではなく、ストレージのI/Oモデルの違いを埋めるためだけに存在しています。 S3 Filesはこのギャップそのものを解消します。アプリケーションからS3のデータはローカルのディレクトリに見えます。 1 2 3 # S3 Filesを使うと pd.read_csv("/mnt/s3files/data.csv") # S3のオブジェクトが読まれる df.to_csv("/mnt/s3files/result.csv") # 変更が自動的にS3にコミットされる FUSEベースのツールとの違い 「S3をマウントできる」と聞いて、Mountpoint for Amazon S3やgcsfuseを思い浮かべる方も多いでしょう。S3 Filesは内部構造がまったく異なります。 FUSEベースのツールは、S3 APIの上にファイルシステムの振る舞いを「エミュレーション」するアプローチです。ファイルの一部だけを書き換えるような操作がサポートされず、空ディレクトリの扱いに不整合が出ることもあります。 S3 Filesはエミュレーションではなく、EFS（Elastic File System）という本物のNFSファイルシステムをS3に接続しています。二つの異なるシステムが共存し、その間に明示的な同期レイヤーがある構造です。 「stage and commit」モデル ファイルシステム上での変更は即座にS3に反映されるのではなく、約60秒ごとにまとめてS3へPUTされます（「commit」）。逆に、S3側でオブジェクトが更新された場合は通常数十秒以内にファイルシステム側に反映されます。 これは明確なトレードオフです。「リアルタイムに同期される共有ファイルシステム」ではなく、「数十秒の遅延を許容する代わりに、ファイルとオブジェクトの両方のセマンティクスを壊さない」設計です。 消えるアーキテクチャ層 1. S3 → EFS/EBSのステージングパイプライン 100GBの学習データを処理する場合、従来の手順は： S3からEBSにダウンロード（数分かかる） データを処理する 結果をS3にアップロード EBSボリュームをクリーンアップ やりたい処理は2番だけです。S3 Filesでは、S3プレフィックスをマウントするだけで処理スクリプトはそのまま /mnt/s3files/ のファイルを読み書きします。ダウンロード・アップロード・クリーンアップのステップが消えます。 ...