2026.05.29

Claude Opus 4.8 で「同じ変更を複数のリポジトリに横展開する」作業が本当に楽になった話 – dynamic workflows で並列に回す

saratogax

記事内に商品プロモーションを含む場合があります

2026 年 5 月、Anthropic が Claude Opus 4.8 を公開しました。

ベンチマーク上の数字も伸びていますが、私の普段の運用作業に対しては、もっと地味で実利のあるインパクトがありました。

それが「同じ変更を複数のリポジトリに横展開する」作業です。

本記事では、Opus 4.8 の dynamic workflows を使って、この種の作業を並列で回す実践例を紹介します。

Contents

「複数のリポジトリへの横展開」という地味につらい作業
Opus 4.8 の dynamic workflows
並列だけではなく「検証まで一気通貫」が効く
「レビューの見逃し」が減ったことの効きどころ
コラム：会話の途中で方針を締める仕組み(Messages API)
まとめ

「複数のリポジトリへの横展開」という地味につらい作業

運用をしていると、こういう作業が定期的に発生します。

あるエージェント(監視・計測系)の設定を、十数リポジトリで一斉にバージョン更新する
CI で使っているサードパーティ製の処理を、新しい呼び出し方式へ全リポジトリで移行する
非推奨になったランタイムを参照している箇所を、対象リポジトリすべてで引き上げる

どれも「1 リポジトリ単位で見れば単純」だが「数が多い」という性質を持っています。

そして厄介なのは、完全な機械置換にはならない点です。

リポジトリごとに設定ファイルの場所が微妙に違ったり、たまたま 1 箇所だけ古い書き方が残っていたりします。

その「1 箇所だけのズレ」が、全リポジトリに伝播すると事故になる。これが横展開作業の本質的な怖さです。

Opus 4.8 の dynamic workflows

Opus 4.8 では、Claude Code の dynamic workflows が強化され、大規模なタスクに対して多数のサブエージェントを並列に実行できるようになりました。

公式の発表では、数十万行規模のコードベース移行のような大規模タスクで、数百の並列サブエージェントを動かす例が挙げられています。

これが「複数のリポジトリへの横展開」とぴったり噛み合います。

従来は、リポジトリを 1 つずつ順番に処理していました。

10 リポジトリあれば、単純に 10 回分の待ち時間が直列で積み上がります。

dynamic workflows では、これを「リポジトリごとに 1 サブエージェント」を割り当てて並列に走らせる形に組み替えられます。

体感の待ち時間は「直列の合計」から「一番長く時間の掛かったリポジトリ 1 つ分だけ」に近づきます。

たとえば A・B・C の処理にそれぞれ 1 分・2 分・3 分かかるとします。

直列: 1 + 2 + 3 = 6 分(全部の合計)
並列(dynamic workflows): 3 分(いちばん遅い 1 つだけ)

つまり待ち時間が「合計」ではなく「最大値」で済むようになる、というのが並列化の本質です。

並列だけではなく「検証まで一気通貫」が効く

ただ並列にするだけなら、シェルスクリプトを書いて回しても似たことはできます。

workflows の本当の旨味は、リポジトリごとに「変更 → 検証」をパイプラインとして組めるところにあります。

イメージとしては、こういう流れを各リポジトリで独立に走らせます。

対象の設定ファイルを探して目的の変更を適用する(リポジトリごとに場所が違っても、その場で探索する)
変更後の差分を、別のサブエージェントが第三者目線で検証する(意図しない箇所を触っていないか)
問題がなければそのリポジトリだけ次の段へ進める

ポイントは、リポジトリ A の検証が終わるのを待たずに、リポジトリ B の変更を進められることです。

段ごとに全リポジトリを揃える(バリア)のではなく、リポジトリ単位で独立に流す。

これにより、速い処理が遅い処理に足を引っ張られにくくなります。

「レビューの見逃し」が減ったことの効きどころ

横展開作業でいちばん怖いのは、前述の「1 箇所だけのズレ」を全リポジトリに広げてしまうことです。

Anthropic の発表によると、Opus 4.8 は Opus 4.7 と比べて、コードの欠陥を指摘せず通してしまう確率が約 4 分の 1 に下がったとされています。

「計画が甘いと押し返す」「自分の間違いに気づく」といった挙動も強化されているという報告です。

複数のリポジトリへの横展開のように「1 つの判断ミスが N 倍に増幅される」作業では、この検証段の精度向上がそのまま事故の確率を下げてくれます。

並列で速く回せることと、検証の見逃しが減ることは、横展開作業においてはセットで効いてくる、というのが使ってみての実感です。

コラム：会話の途中で方針を締める仕組み(Messages API)

少し毛色の違う話ですが、Opus 4.8 では Claude の Messages API も更新されています。

具体的には、会話の途中にシステム指示を差し込めるブロックが追加されました。

従来、会話全体のルールは冒頭で一度だけ渡すのが基本でした。

途中で方針を変えたいときは、ユーザー発言にそれっぽく紛れ込ませる必要があり、システム由来の方針なのか、ユーザーの依頼なのかが曖昧になりがちでした。

新しい API では、会話の特定の時点で「ここからはこの方針で」という指示を、システム由来として明示的に注入できます。

仕組みとしては、user メッセージの content の中に、type が mid_conv_system のブロックを差し込む形です。

messages = [
    {"role": "user",      "content": "設定ファイルを移行して"},
    {"role": "assistant", "content": "..."},
    {
        "role": "user",
        "content": [
            # ↓ 会話の途中で方針を締める(4.8 の新ブロック)
            {
                "type": "mid_conv_system",
                "content": [
                    {"type": "text", "text": "ここからは破壊的変更を禁止。必ず確認を取れ"}
                ],
            },
            {"type": "text", "text": "次のリポジトリも頼む"},
        ],
    },
]

従来は system 由来の方針を user 発言の文章に紛れ込ませるしかなく、モデルから見て「ルール」と「依頼」の区別が曖昧でした。

専用のブロックとして渡せる新しい書き方なら、その境界がはっきりします。

長時間動くエージェントを、フェーズごと(調査 → 実装 → 検証)に方針を締めながら走らせたいときに相性がよさそうです。

本記事のテーマである横展開作業も、まさに長時間エージェントの一種なので、今後の運用で試してみたいポイントです。