WSJ の CIO Journal が、Meta の新モデル Muse Glimmer について「企業から見て最も興味深いのは、常時稼働（always-on）のAIエージェントに焦点を当てている点だ」と報じています。記事の中で紹介されている一言が、私には一番実務的に響きました。「今後の問いは、何を24時間365日でできるかではなく、何がそうできないか、に移っていく」。設計する側から見ると、これは要件定義の話です。
要点 (出典の事実のみ)
- Meta の新モデル Muse Glimmer について、同社は発表で「常時稼働のローカルエージェントのワークフローに最適化されている」と説明している。WSJ は企業視点で最も興味深い点として、この常時稼働エージェントへの focus を挙げている。
- Muse Glimmer は、エンドツーエンドでのエージェント的なタスク遂行と、失敗からの復旧といった原則に焦点を当てているとされる。
- Sequoia Capital のパートナー Konstantine Buhler 氏は「AIは、従来の時間と処理能力の制約を超える自動化を提供することで経済を作り替えており、企業が24時間シームレスに稼働できるようにしている」と述べ、この力学が今後5〜7年かけて経済のより多くの領域に広がると見ている。
- AIエージェント企業 Alta の共同創業者兼CEO である Stav Levi-Neumark 氏は、営業領域で企業が「ゼロ・レイテンシ」を目指すようになると指摘。真夜中でも昼下がりと同じ品質で顧客の問い合わせに応じられることの重要性が増しており、製造・物流・営業・カスタマーサポートなど多くの業務で効いてくるとしたうえで、「今後の問いは、何を24時間365日でできるかではなく、何がそうできないかに移る」と述べている。
- 同じ号の「Signals」では、Mark Zuckerberg 氏が月曜に公開した6,500語のエッセイ（オープンウェイトモデルの拡大と、データセンターを受け入れる地域向けの10億ドルのファンドを含む）に言及。米国内で500件超のデータセンター建設禁止が有効であること（The Information 調べ）、JPMorgan が S&P500 の目標を8,000ポイントへ2か月で2度目の引き上げをしたこと（AIハイパースケーラーの巨額の設備投資が顧客需要を通じて収益化されている証拠を挙げている）も報じられている。
- 執筆は WSJ Leadership Institute のエンタープライズ技術担当 Steven Rosenbush 氏。2026年8月10日付。
「常時稼働」は速さの話ではなく、業務設計の話
常時稼働と聞くと処理速度やインフラの話に聞こえますが、私はこれを業務設計の前提が動く話だと読んでいます。
日本の業務システムの多くは、人間の勤務時間を前提に組まれています。受付時間、翌営業日回答、夜間バッチ、月次締め。これらは「人がいる時間しか処理できない」という制約から生まれた設計です。競合が24時間同じ品質で応答するようになると、この制約はそのまま競争上の遅れに変わります。Levi-Neumark 氏が「ゼロ・レイテンシ」と呼んでいるのはそういうことでしょう。
ただし、だから全部を24時間動かせという話にはなりません。ここが本題です。
設計の核心は「24時間動かさないもの」を決めること
「問いは何が24時間できるかではなく、何がそうできないかに移る」という反転が、私は一番重要だと考えています。これは要件定義の成果物として書けるからです。
私はこれまで、モノタロウが「AIに任せない範囲」を先に決めて4か月で購買エージェントを出した話や、Airbnb のAIアシスタントが問い合わせの約45%を人を介さず解決し、残りは人に渡す設計になっている話を書いてきました。どちらも共通しているのは、AIに任せる範囲を絞ったことが成果に繋がっている点です。常時稼働も同じで、「常時稼働させない範囲」を定義できるかどうかが設計の質を決めます。
実務的には、次の3つは24時間の自動処理から外す候補になります。
| 外す候補 | 理由 |
|---|---|
| 金銭・契約が確定する処理 | 誤りの取り消しコストが大きく、深夜に発生すると発見が遅れる |
| 例外・苦情への一次対応 | 判断の前提が毎回変わる。誤対応が信頼を直接毀損する |
| 社外への不可逆な送信 | 送ってしまったものは戻せない。人のレビューを挟む価値が最も高い |
逆に、照会・下調べ・一次仕分け・下書き作成のように間違えても取り返しがつく処理は、常時稼働の効果が素直に出ます。
24時間動くとは、誰も見ていない時間に失敗するということ
Muse Glimmer が「失敗からの復旧」を原則に掲げている点は、作る側として見逃せません。常時稼働は、失敗が必ず起きる前提の設計を要求します。
日中しか動かないシステムなら、異常があれば誰かが気づきます。24時間動くシステムでは、深夜3時の失敗を誰も見ていません。したがって、リトライ、途中状態からの再開、エスカレーション先、そして何が起きたかを後から再現できるログが、あれば良いものではなく必須要件になります。監視基盤が人間スケールの前提のままでは破綻するという論点そのものです。
先日書いた EY の CIO の話でも、「エージェントが行動を起こすようになると、ガバナンスは文書のままではいられず、システム自体に組み込む必要がある」という指摘がありました。常時稼働はその要求を一段強めます。動いている時間が長いほど、書類ではなく実装で担保するしかなくなる。
開発会社の事業判断にどう効くか
三つ挙げます。
一つ目。要件定義に「常時稼働させない処理の一覧」を成果物として入れる。 「どこを自動化しますか」ではなく「どこは夜間に動かさないでおきますか」と聞くと、顧客の側もリスクを言語化しやすくなります。この一覧は後の運用ルールにもそのまま使えます。
二つ目。復旧設計を見積もりの独立項目にする。 リトライ、再開、エスカレーション、ログ保全は、常時稼働では機能要件です。「非機能要件」として一括りにすると値引きの対象になり、公開後に事故として跳ね返ります。工数を分けて提示したほうが、結果的に通ります。
三つ目。常時稼働の範囲は費用に直結すると先に伝える。 24時間動かすということは、その分だけ推論コストが燃え続けるということです。AI開発会社の選び方でも運用時の推論コストを確認観点に挙げましたが、常時稼働案件ではここがより効きます。範囲を絞る提案は、品質だけでなく費用の話としても筋が通ります。
誤読しやすい点
Muse Glimmer の登場で常時稼働が実現した、と読むのは早いと思います。 記事が伝えているのはモデルが常時稼働のワークフロー向けに最適化されたという設計方針であり、業務で成果が出たという事例ではありません。Buhler 氏自身も、この力学が広がるのは5〜7年かけてと見ています。
もう一つ、同じ号の Signals が示しているのは、この方向に物理的な制約が付いて回るという事実です。米国内で500件超のデータセンター建設禁止が有効で、AI需要でメモリ価格は1年で4倍になっている。常時稼働は計算資源を継続的に食う前提なので、この層のコストと供給が効いてきます。技術的にできることと、費用対効果が合うことは別問題です。
出典: The Morning Download: Meta Shares Glimmer of Always-On AI Future (The Wall Street Journal CIO Journal、Steven Rosenbush、2026年8月10日)
