Claude Code 2.1.154が2026年5月28日に公開されました。目立つのはOpus 4.8対応ですが、実務目線ではDynamic workflowsの追加が大きいです。
何が起きたか
公式changelogとGitHub Releasesでは、2.1.154の主な変更として、Opus 4.8、Dynamic workflows、fast mode、lean system prompt、複数選択質問の出し方の調整、/simplifyのcleanup寄りの変更、background sessionまわりの改善などが挙げられています。
Dynamic workflowsは、Claudeにworkflowを作らせ、裏側で多数のagentに作業を分ける考え方です。単発の「このコードを直して」から、複数の作業を並行で進める方向に寄っています。
何が変わったか
小さな開発会社が見るべき変化は、モデル性能そのものよりも作業の切り方です。AIコーディング支援は、最初は補完やレビューの道具でした。Claude Codeのこの更新では、作業単位を作り、複数のagentに分け、進行を見ながら戻す運用に近づいています。
もう一つ地味に効くのは、Claudeが必要以上に質問しにくくなった点です。公式changelogでは、Claudeが判断できる文脈では複数選択の質問を出さず、本当に判断できない場面に絞る方向の変更が書かれています。AI作業員を使うとき、毎回確認で止まると現場では使えません。この調整は、実務導入ではかなり重要です。
小さな会社・開発会社・EC運用ではどこに効くか
一番使いやすいのは、調査、実装、検証、文章化が分かれる作業です。たとえばECサイトの小さな改修なら、商品ページの不具合調査、テーマ側の修正、テスト観点の整理、運用担当向けメモ作成を別レーンにできます。
少人数の開発会社なら、既存コードの棚卸しにも使えます。1人の担当者が全部を見るのではなく、API、画面、テスト、ドキュメントを分けてAIに確認させる。ただし最後の判断は人間が持つ。この線引きが現実的です。
そのまま真似ると危ない点
agentを増やせば成果が増える、という話ではありません。指示が雑なまま並列化すると、間違った実装案、重複した修正、読みにくい差分が増えます。人間側に「どの作業を分けるか」「何を完了条件にするか」「誰が最後に見るか」がないと、速く散らかるだけです。
もう一つのリスクは、社内ルールや顧客情報の扱いです。複数agentに作業を分けるほど、見せてよい情報と見せてはいけない情報の区切りが必要になります。顧客名、契約条件、秘密キーや接続情報、未公開案件を不用意に混ぜる運用は避けるべきです。
最初にやるなら何か
最初は本番コードではなく、社内用の小さな改善で試すのが安全です。おすすめは、既存リポジトリのREADME整理、テスト観点の洗い出し、古いTODOの分類、問い合わせ対応テンプレートの改善あたりです。
作業を頼むときは、次の3点だけ先に決めます。対象範囲、完了条件、最後に人間が確認する場所。この3つがないままagentを増やすと、確認コストが増えます。
monoblo/Sync8実務メモ
私なら、Dynamic workflows系の機能は「AIに任せる量を増やす機能」ではなく、「人間が作業を小分けにして、戻り値を確認しやすくする機能」として見ます。
小さな会社で効くのは、開発者を置き換える場面ではありません。問い合わせ、EC運用、社内ツール、簡単な改修のように、毎回似た作業が出る領域です。そこに作業レーンを作り、AIが調査と下準備を進め、人間が最後の判断をする。この形なら現場に入りやすいです。