今週の問い：並列化したエージェントの仕事を、どうすれば「終わった」と言えるか

エージェントに複数の調査やレビューを任せると、人が手順を並べる負担は減ります。その代わり、いつ実行を始めたか、どの結果を受け渡したか、通信が切れた後に何を根拠に完了と判断するかが、プロダクトの要件になります。今週の二つの記事は、仕事を分ける仕組みと、失敗から戻る仕組みを同時に考える必要を示しています。

今週の結論は三つです。

  1. 多数の対象を扱う仕事では、エージェントが仕事の分割を決める動的ワークフローが有効になり得るが、予算と観測の境界を人が持つ必要がある。
  2. 復旧目標は「必ず止まらないこと」ではなく、失ってよいデータ量（RPO）と復旧に許される時間（RTO）を作業ごとに決めることから始まる。
  3. まずは読み取り専用のレビュー一件で、開始・中断・再開・完了の記録を検証してから、書き込みを伴う仕事へ広げる。

今週選んだ記事と、人気の判断

媒体 選定記事 公開日 選定根拠
Latent Space How Anthropic’s Dynamic Workflows Coordinate Claude Agents 10月12日 記事ページには61と10の数値が表示された。閲覧数・数値の項目ラベルは公開範囲で確定できないため、反応の代替指標としてのみ扱う。
The Pragmatic Engineer Building resilient AI-powered software, and planning for when things go wrong 10月13日 新着アーカイブ上で、同週の新着記事中では表示数値194・1・7が大きかった。閲覧数・項目ラベルは公開範囲で確定できない。

動的ワークフローは「サブエージェントの人数設定」ではない

Latent Spaceの記事（2026年10月12日）は、Claude Managed Agentsのdynamic workflowsを、固定した担当者表ではなく、主エージェントが計画とオーケストレーション用プログラムを作り、段階ごとに複数エージェントを動かすものとして紹介します。共有ファイルシステムを介した情報交換、セッション予算、遷移を追うグラフ表示も取り上げ、単一エージェントより費用が増える一方、詳細を拾う目的で使うものだと位置付けます。

公式のClaude Platformリリースノート（2026年10月9日）は、Managed Agents向けの同機能をベータとして案内しています。multiagentを有効にすると、エージェントは多数の処理をフェーズに分け、結果をまとめるプログラムを書けます。サーバー側で走るワークフロー実行は、セッションのworkflow_run.*イベントで追跡します。つまり、分割を任せても、開始条件・予算・イベントの読み方まで任せきりにはできません。

Simon Willisonの10月13日の投稿は、Anthropicのソース管理移行を紹介し、コード変更の増加と、エージェントによるレビューでも熟練者が過剰設計を避ける方向へ導く必要がある点を伝えます。これは製品仕様の根拠ではなく実務家の観察ですが、エージェントを増やすほど、人の役割が「一件ずつ処理する人」から「何を検証し、どこで止めるかを決める人」へ移る、という補助線になります。

復旧目標を、モデル提供者も含めた依存関係へ広げる

The Pragmatic Engineerの記事（2026年10月13日）は、Sam Newmanの書籍から、災害復旧の基本をAIを組み込むソフトウェアへつなげます。RPOは障害時に失ってよいデータの最大時間、RTOは復旧まで許容できる停止時間です。どちらもゼロへ近づけるほど、コストと複雑さが増えます。

記事は、バックアップから復元する方式、データだけを同期して必要時に計算資源を起こすパイロットライト、あらかじめ一部容量を用意するウォームフェイルオーバー、複数拠点を常時使うactive-activeを、目標と費用の異なる選択肢として説明します。AIを使う機能では、モデル提供者が使えないときに機能を縮退させること、代替の提供経路やベンダーを検討すること、モデル変更を観測することも挙げます。これは「複数モデルなら安全」という結論ではありません。代替が同じ障害や同じデータ依存を抱えないか、切替が本当に動くかを確かめる前提です。

Zennの実装例（2026年10月10日）は、Managed Agentsのイベント履歴から実行状態を組み立て直す方法を扱っています。接続後の新着だけを見るのではなく、ストリームと履歴の間で起きる抜け・重複を扱う必要があり、status_endedと結果を区別して完了を判断すべきだと整理しています。公開された実践記事であり、公式仕様の代替ではありませんが、イベント駆動のワークフローを画面に載せる際の具体的な論点です。

一致する点、食い違う点、未解決点

一致する点は、実行を「モデルへの一回の依頼」として扱わないことです。動的ワークフローではフェーズと結果の結合が、復旧設計ではデータ・計算資源・切替が、それぞれ明示的な管理対象になります。

食い違う点は、解こうとしている問題の時間軸です。Latent Spaceと公式リリースノートは、ある仕事を分割して進める仕組みを扱います。The Pragmatic Engineerは、拠点障害など大きな停止からの回復を扱います。ワークフローの再試行だけでDRを満たすわけでも、DR構成だけで個々のエージェント結果の重複を防げるわけでもありません。

未解決点は、コスト上限と成果の品質をどう結ぶかです。公式資料はイベント追跡と設定方法を示しますが、どの仕事に何エージェントを使うべきかの万能な数値は示しません。RPO・RTOと同じように、レビュー対象、使ってよい予算、失敗時の人の判断を、用途ごとに記録して調整する必要があります。

今週覚える用語

自分の開発・学習・キャリアへの意味

エージェントを使う仕事の設計力は、よいプロンプトを書く力だけでは測れません。どのイベントを保存し、何を再実行でき、どの変更で人の承認を止めるかを説明できると、コーディング支援、文書レビュー、データ処理のどれにも応用できます。小さな処理で完了判定と復旧手順を持つことが、長時間・高コストの自動化を安全に扱う土台になります。

今週20分で試すこと：一件の読み取り専用レビューに実行契約を付ける

対象: 自分のリポジトリで、読み取りだけで完結する作業を一つ選びます。例は依存関係の確認、ログの分類、ドキュメントのリンク切れ調査です。外部サービスへの書き込みやデプロイは行いません。

  1. 5分で、開始条件、入力、出力、完了条件を各一行で書きます。
  2. 5分で、途中停止時に残す識別子と結果ファイルを一つずつ決めます。
  3. 5分で、再実行時に重複してはいけない出力を一つ挙げ、重複を見分けるキーを決めます。
  4. 5分で、対象作業のRPOとRTOを仮置きし、その根拠がない項目を「要確認」と記録します。

完了条件: 一つの作業について、開始・完了・再開の判断材料と、失ってよいデータ量・停止時間を、推測と確認済みの事実を分けて説明できることです。

参照元

中心となる原資料を確認する ↗