メインコンテンツまでスキップ

Conway タイムライン: Anthropic はどう Always-On Agents を組み立てているか

· 約13分
Claude Dev
Claude Dev
Claude Dev

Conway についてまず正確に押さえるべきことはこれです。

Conway は、Anthropic が正式発表した製品ではありません。

現在見えているのは、次の 3 つの組み合わせです。

  • Cowork、Dispatch、computer use、scheduled tasks、auto mode に関する Anthropic の公式発表
  • それらがどうつながるかを示す最新のヘルプドキュメント
  • 2026 年 4 月 1 日に公開された、未発表の内部環境 Conway を報じる第三者レポート

リークだけを見ると全体アーキテクチャを見失います。 公式発表だけを見ると、Anthropic がどこへ向かっているかを見落とします。

技術的に重要なのは、その両方を合わせて読むことです。

短い結論​

システム設計の観点から見ると、Anthropic は明らかに always-on agent model に向かっています。

その理由は Conway が発表されたからではなく、すでに公開済みの製品群の中に必要な primitives がほぼ揃っているからです。

  • デバイスをまたいで続く persistent thread
  • ローカルファイルに触れる desktop runtime
  • scheduled execution
  • 直接統合がない時の computer use
  • sub-agent coordination
  • 長時間実行向けの permission mode
  • Dispatch によるモバイルからデスクトップへの handoff

Conway が重要なのは、それらをより明示的な always-on agent environment としてまとめようとしているように見えるからです。

何が確認済みで、何が未確認か​

Anthropic が公式に確認しているもの​

Anthropic はすでに次を公式に公開または文書化しています。

  • Claude Code の agentic architecture を土台にしたデスクトップ環境としての Cowork
  • Dispatch を通じた phone-to-desktop の継続的な task handoff
  • scheduled tasks と recurring routines
  • Cowork と Claude Code における computer use
  • 長く走る Claude Code session 向けの auto mode

公式ドキュメントで確認できるが、単独機能名ではないもの​

現在のヘルプドキュメントは、次のようなワークフローを説明しています。

  • 一つの継続スレッドを維持する
  • Claude が development work を Claude Code に振り分ける
  • Claude が knowledge work を Cowork に振り分ける
  • 結果が同じ persistent thread に戻る
  • scheduled tasks が自動実行される
  • computer use がデスクトップアプリを操作する

これは、名前こそ付いていなくても、かなり always-on agent runtime に近い状態です。

報道はあるが、公式発表ではないもの​

Conway という名前は、2026 年 4 月 1 日公開の第三者レポートに由来します。そこでは次のような要素があるとされています。

  • 専用の Conway instance
  • Search、Chat、System を持つサイドバー
  • extensions
  • webhooks
  • Claude in Chrome からの直接接続
  • notifications

これは Anthropic がより明示的な always-on agent environment を構築しているかもしれないという強いシグナルです。

ただし、まだ未発表製品に関する報道であり、正式リリースではありません。

タイムライン​

2026 年 1 月 12 日: Cowork research preview 公開​

Anthropic は Cowork を「Claude Code for the rest of your work」として紹介しました。

重要だったのは UI ではなく runtime model です。

  • Claude が自分のコンピュータ上のフォルダで直接作業する
  • multi-step tasks を処理できる
  • Cowork は Claude Code と同じ agentic foundations の上にある
  • ユーザーはタスクをキューに積み、Claude を単なるチャットではなく coworker のように使える

これは、Anthropic が単なる terminal coding tool より広い desktop agent runtime を狙っている最初の公開サインでした。

2026 年 1 月から 2 月: Cowork がプラン横断と Windows に拡大​

Anthropic は Cowork の提供範囲を有料プランへ広げ、その後 Windows にも拡張しました。

これは、Cowork が一部 power-user 向けの実験で終わらず、より広い配備に向けて runtime が強化されていることを意味します。

2026 年 3 月下旬まで: Cowork docs が local agent runtime 全体像を示す​

現在の Cowork ヘルプドキュメントは、最初のブログよりも architecture を明確にしています。

Cowork は次のように説明されています。

  • Claude Code の agentic capabilities を Claude Desktop に持ち込む
  • direct local file access を持つ
  • multiple sub-agents in parallel を調整する
  • 長時間タスクを走らせる
  • scheduled tasks をサポートする
  • files、instructions、memory を持つ projects をサポートする
  • virtual machine (VM) environment 内で作業する

これはチャットボット機能の集合ではなく、agent runtime です。

2026 年 3 月 23 日: Dispatch と computer use が Cowork / Code を横断して導入​

これは今のところ最大の公開マイルストーンです。

Anthropic は、Claude が次のことをできる状態を公式に示しました。

  • phone から desktop へ続く会話を保つ
  • computer を使う
  • セッションをまたいで context を保つ
  • schedule に従ってタスクを実行する
  • Cowork と Claude Code の両方をまたいで働く

ここで「always-on」方向はかなり明確になります。

always-on agent に本当に必要なものは 2 つです。

  1. persistence
  2. ユーザーが見ていない時でも行動できること

Dispatch と computer use は、その 2 つを揃えています。

2026 年 3 月下旬: Dispatch docs が routing model を補完​

Dispatch のサポートドキュメントには特に重要な詳細があります。

  • 一つの continuous persistent thread を持つ
  • タスクを投げると、Claude が仕事の種類を判断する
  • development tasks は Claude Code に流れる
  • knowledge work は Cowork に流れる

これは大きな architectural clue です。

Anthropic は Code と Cowork を別々の製品としてではなく、一つの task thread の下にある specialized execution surfaces として扱い始めています。

2026 年 3 月 24 日: Auto mode が Claude Code に長時間実行向けの中間レイヤーを追加​

翌日、Anthropic は Claude Code の auto mode を公開しました。

これは見た目以上に重要です。

always-on agent は、数分おきに permission を求めて止まるようでは役に立ちません。しかし permission を完全に外すのは危険です。Auto mode はその間を埋める層です。

  • Claude が一部の permission decisions を代行できる
  • classifier が tool calls を事前判定する
  • 安全な actions は自動で進む
  • 危険な actions はブロックまたは escalation される

これは unattended または semi-unattended work に必要なインフラです。

2026 年 4 月 1 日: 第三者レポートが Conway を表に出す​

TestingCatalog は、Anthropic が Conway という内部の always-on agent environment をテストしていると報じました。

報じられた要素は、Anthropic が公開済みの方向性とかなり整合します。

  • standalone instance
  • .cnw.zip を含む extension installation
  • connectors and tools
  • Claude in Chrome との直接接続
  • instance を起こせる public URL つき webhooks
  • notifications

もしこれが正しいなら、Conway はランダムな side project ではなく、すでに公開されている runtime を一段上でまとめる packaging layer だと考えられます。

なぜ Conway は技術的に自然なのか​

Anthropic は product names を外して見ると、always-on agent system に必要な部品の大半をもう持っています。

1. 持続する control thread​

Dispatch はデバイス変更をまたいでも生きる user-facing thread を提供しています。

その thread は重要です。なぜなら stable control surface になるからです。

  • ユーザーはそこで goal を出す
  • 結果はそこへ戻る
  • approvals もそこで処理できる
  • memory もそこに積み上がる

その thread がなければ、すべての task は毎回 fresh spawn です。

2. 専門化された runtimes​

Anthropic にはすでに 2 つの execution surface があります。

  • Claude Code は development work 用
  • Cowork は broader desktop knowledge work 用

これは scheduler-friendly architecture です。タスクごとに適切な runtime を選べます。

3. foreground chat を超えた triggering​

Scheduled tasks と Dispatch は、モデルを reactive chat から押し出しています。

always-on agent には外部 trigger が必要です。

  • time-based triggers
  • 別デバイスからの user messages
  • service-triggered events

Conway レポートで特に重要なのが webhooks なのはそのためです。

4. computer use を fallback actuator にする​

直接 integration の方が screen control より常に良いです。 Anthropic も computer-use docs で、まず connectors、次に browser automation、最後に direct screen interaction と書いています。

これは重要な順序です。 Anthropic は computer use を gimmick ではなく、より大きな action stack の last-resort actuator として扱っています。

5. 長時間実行の governance​

Auto mode は、always-on agent に foreground assistant とは違う permission architecture が必要だと Anthropic が理解している最初の公開シグナルです。

Conway が実在するなら、ほぼ確実にさらに強い以下が必要です。

  • policy checks
  • event filtering
  • webhook-level trust boundaries
  • extension sandboxing
  • auditability
  • wake / sleep semantics

だからこそ、Conway レポートにある extensions と webhooks は単なる gossip ではありません。そこが governance の難所だからです。

技術的に重要な Conway のシグナル​

Standalone instance​

「Conway instance」という表現は、Anthropic がこれを chat tab ではなく persistent agent container として考えている可能性を示します。

ここから出てくるのは、典型的な always-on agent の問いです。

  • いつ wake up するのか
  • どれだけ長く生きるのか
  • 何が persist するのか
  • restart で何が reset されるのか
  • 何が external trigger になれるのか

Extensions​

レポートが正しければ、Conway は次のような extension model に向かっています。

  • tools
  • UI tabs
  • context handlers

これは大きな変化です。Anthropic が fixed built-in runtime ではなく、persistent agents のための first-class plugin architecture を狙っている可能性があります。

Webhooks​

これが最も強い always-on signal です。

Webhook があるということは、agent が foreground の user prompt だけを待つのではなく、external system event で起きられるということです。

つまり、

  • 「頼まれた時に走る」

から

  • 「世界が変わった時に起きて動く」

への橋になります。

Chrome connection​

Anthropic はすでに Claude for Chrome と browser-based action paths を持っています。Conway と Chrome の直接接続は、browser を durable action surface にするという意味で自然です。

Notifications​

Notifications は小さく見えますが重要です。

always-on agent には次のための compact signaling channel が必要です。

  • task finished
  • approval needed
  • trigger failed
  • environment offline
  • schedule skipped

これがないと persistent agents は opaque になります。

技術的にどう読むべきか​

私の見方はこうです。

Conway は新しい基盤そのものというより、Anthropic がすでに公開してきた複数の subsystem を、より明示的な persistent-agent environment として包み直す試みである可能性が高い。

その subsystem はすでに見えています。

  • Cowork runtime
  • Claude Code runtime
  • Dispatch thread
  • scheduled tasks
  • computer use
  • mobile handoff
  • safer long-running permissions

Conway が将来出るなら、おそらく次のような instance model になるはずです。

  • durable identity
  • event triggers
  • extension points
  • external wake-up paths
  • unified notifications

これは「席を外している間も Claude が働く」より一段上の話です。

Claude が継続的に常駐する software system になるということです。

Anthropic がまだ解かなければいけないこと​

always-on agents は UX 問題というより、システムと安全性の問題です。

Conway が公開されるなら、少なくとも次の 5 つは解く必要があります。

1. Trigger trust​

Webhook-triggered agents は強力ですが、同時に攻撃面も増えます。

  • forged events
  • replayed events
  • poisoned payloads
  • 外部サービス経由の escalation

2. Extension isolation​

Extension model は、第三者ロジックが instance を簡単に壊せない場合にだけ意味があります。

  • package trust
  • install permissions
  • tool scoping
  • network boundaries
  • update behavior

3. State hygiene​

Persistent agents は context を蓄積し、蓄積した context は必ず汚れます。

  • memory pruning
  • project boundaries
  • stale state detection
  • trigger-specific context windows

4. Human control​

Agent が persistent になるほど、素早く止められることが重要になります。

  • pause instance
  • revoke tools
  • cut connector access
  • disable triggers
  • inspect recent actions

5. Execution visibility​

Foreground chat では actions が見えやすいですが、always-on execution ではそうではありません。

そのため、audit logs、summaries、traces、event histories がはるかに重要になります。

最終判断​

「Anthropic は Conway を正式公開したのか」という問いへの答えは no です。

「Anthropic は clearly always-on agent architecture に向かっているのか」という問いへの答えは yes です。

公式プロダクトの流れはすでにこうなっています。

  • Cowork が desktop agent runtime を作った
  • Dispatch が cross-device persistent thread を作った
  • scheduled tasks が time-based automation を作った
  • computer use が fallback actuator layer を作った
  • auto mode が safer long-running execution を作った
  • 報じられた Conway が instances、webhooks、extensions、notifications という語彙を補った

これが本当の技術ストーリーです。

Conway が重要なのは、Anthropic が always-on agents を完成させた証拠だからではありません。 Anthropic の product trajectory を、初めてかなり見えやすくしたからです。

Sources (checked April 3, 2026)​