AI-DLC Workflows v2.5.5がGAになった今、Claude Codeで副業を回す人が飛びつく前に切る4スコープ設計

新しいAIツールが出るたびに触ってしまうのに、副業の成果は増えない理由
GAになったAI-DLC Workflows v2.5.5をKiro CLIで動かしてみた
poc・mvp・featureという「スコープ選択」が教えてくれた、自動化に足りない判断軸
コンダクターとサブエージェントのモデル分担から学ぶ、自分のAI運用コストの見直し方
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

新しいAIツールが出るたびに触ってしまうのに、副業の成果は増えない理由

新しい AI ツールが出るたびに触ってしまうのに、副業の売上は増えない。この矛盾に、自分は何度も引っかかってきた。10 年以上エンジニアをやってきて、副業では AI エージェントを組んで動かしているが、機能追加や新バージョンに反射的に飛びつくほど、稼ぐ側の設計が薄くなる瞬間がある。

結論を先に置くと、ツールを差し替える前に「ワークフローのどこに自分の判断を残すか」を決めておかないと、最新版に乗り換えても副業の売上には直結しない。触る楽しさと売れる仕組みは、別の回路で動いているからだ。

きっかけは、AWS Labs が OSS として公開している「AI-DLC Workflows」という AI 駆動開発向けのワークフロー集が v2.0 で GA (正式版) になったことだ。クラスメソッドの検証記事によれば、GA 後もマイナーアップデートが積み重なり、5 週間で 30 リリース、現行版は v2.5.5 まで進んでいるという。これを Kiro CLI (AI コーディング向けの開発者 CLI) で動かした検証レポートを読んで、自動化の「入口の設計」の勘所が言語化されていると感じた。

GAになったAI-DLC Workflows v2.5.5をKiro CLIで動かしてみた

元記事の著者は、v2.5.5 の dist/kiro/ をそのままコピーしてワークフローの入口までを動作確認している。使用環境は Kiro CLI 2.13.1、コンダクターモデルに claude-opus-4.6、サブエージェントモデルに claude-sonnet-4.6 という組み合わせだ。ちなみに AI-DLC のデフォルト構成はコンダクターが claude-opus-4.8、サブエージェントが claude-sonnet-4.5 で、cli.json の defaultModel と各エージェント定義を書き換えて評価している。

v2.0.0 から v2.5.5 までの構成変化は元記事にまとまっているが、要点だけ拾うと、Stage modes が 2 から 4 (pipeline と mob が追加)、エージェントに composer が加わって 14 種、ハーネスに opencode が加わって 5 種、スコープが 9 種、ステージが 32 種というスケールになった。ワークフロー自体が「単一の直線」から「役割と経路で組み替えられる網」に近づいている印象を受ける。

自分が特に注目したのは、途中で追加された 4 つの機能だ。

Adaptive Workflows (v2.2.0) 自然言語の入力に応じて composer エージェントがスコープを推論し、EXECUTE/SKIP グリッドを動的に生成する仕組み

プラグインメカニズム (v2.3.0) plugins/ ディレクトリで拡張ステージや contribution を定義できる仕組み

opencode ハーネス (v2.4.6) 5 番目のハーネスとして opencode.ai に対応

3 ロールアンサンブル (v2.5.0) pipeline と mob モードによるコラボレーター分離と contribution files の導入

配置後、元記事の著者は /aidlc --doctor を実行して 39 passed, 0 failed で通過している。設定不備や依存欠落を最初に自動でチェックしてくれる仕組みは、副業で複数プロジェクトを回している側からするとありがたい。自分の運用でも、CLI 起動時にヘルスチェックを走らせるかどうかで、その日 1 日の生産性が変わる。ハーネス (実行系の外殻) が壊れていることに気付かず 3 時間走らせて全部やり直し、みたいな事故はもう起こしたくない。

poc・mvp・featureという「スコープ選択」が教えてくれた、自動化に足りない判断軸

元記事で一番刺さったのは、ワークフロー起動時に提示される「スコープ選択」だった。「シンプルな電卓 Web アプリを作りたい」と投げると、compose (適応型で組む) / mvp (運用を飛ばして本体だけ出す) / feature (新機能、現実的な深さで進める) / poc (概念実証、8/32 stages のみ) といった選択肢が並ぶ。元記事では poc を選んで intent-birth → intent-capture に進み、3 つの質問 (用途・演算範囲・ターゲットユーザー) まで生成されている。

ここで自分がハッとしたのは、この選択が「機能」ではなく「判断軸」の入口だという点だ。同じ題材でも、mvp を選べば運用系のステージを丸ごとスキップする。poc を選べば全体 32 のうち 8 しか回さない。この「何をやって、何をやらないか」を最初に切る仕組みが、副業で自動化を組む時に一番抜けやすい。

自分の場合、AI エージェントで記事や返信を回している時、つい「全部やる」を選びがちだった。下書き生成・品質チェック・タイトル候補・タグ提案・関連記事挿入・投稿予約……全部繋げようとして、結局どこかが詰まると連鎖して止まる。3 時間かけた仕組みが 5 分で壊れる。泣いてない。

AI-DLC のスコープ選択は、この「全部やる病」に対して「今日はここまで」と最初に線を引かせる装置になっている。副業側の運用に翻訳するなら、次のような分岐を最初に決めておくと、その日の稼働時間が変わる。

検証だけ回す日 — 概念実証、コアだけ動けばいい

本体を出す日 — 運用系は捨てて、届く形にする

新機能を足す日 — 現実的な深さで整える

全面刷新する日 — 適応型で組み直す

大事なのは、この 4 つを混ぜないことだ。混ざると、AI も自分も判断がぶれる。ぶれるとレビュー時間が伸びる。伸びると、その日は投稿できずに終わる。売上に届く直前で止まるのは、たいていこの「混ぜてしまう」構造だ。

コンダクターとサブエージェントのモデル分担から学ぶ、自分のAI運用コストの見直し方

もう 1 つ、元記事の設計で示唆的なのが、コンダクターに opus 系、サブエージェントに sonnet 系という「モデルの階層化」だ。全体を判断する側に重いモデルを、実際に手を動かす側に軽いモデルを配置する。自然な設計に見えるが、副業で AI を運用している側にとって、月末の管理画面の数字を軽くする鍵はここに集約される。

自分は少し前まで、記事生成も分類も抽出も全部同じモデルで動かしていた。動くには動くが、単純な分類ジョブに強力なモデルを使うのは、コンビニに戦車で買い物に行くようなものだった。使い分けは面倒だが、それを避けるコストの方が高かった。

そこで自分の運用では、CLI 側のジョブを「判断層」と「実行層」に分けて、実行層は軽いモデル (haiku 系)、判断層は中位のモデル (sonnet 系) に階層化した。トレンド抽出・分類・エピソード抽出・関連記事キーワード生成・画像プロンプト生成は軽い側に落とし、品質分析・情報系の短文・応答文面のような読者に届く部分は中位に、本文生成やタイトル決めのように売上に直結する部分だけ上位モデルに残す。この 3 階層に整理し直したら、月末のダッシュボードの数字が体感で半分になった。落ちた品質はほぼゼロだった。

AI-DLC のコンダクター/サブエージェント構成は、この考え方をワークフロー側から強制する仕組みになっている。ハーネスが 5 種類、スコープが 9 種類、ステージモードが 4 種類。組み合わせて「今日の作業に必要な最小構成」を先に決めさせる。判断層に贅沢に、実行層は絞る。副業で AI を毎日回す側からすると、この設計思想を借りて自分のジョブ棚をもう一度並べ直すだけで、月末の管理画面の数字が変わってくる。