AI-DLC Workflow V2のAdaptive Composer: スコープを"選ぶ"から"作る"へ
9つのスコープで足りない時、どうする？ Adaptive Composerに聞いてみましょう。タスクに合ったステージ構成を提案してくれます。この記事ではAdaptive Composerの考え方と使い方を見ていきます。シリーズ第5回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 5AI-DLC Workflow V2のAdaptive Composer: スコープを"選ぶ"から"作る"へ This article
1. はじめに
この記事はAI-DLC Workflow V2 シリーズの第5回です。第4回 では5フェーズ・33ステージの全体地図とスコープによる使い分けを扱いました。
第4回 で、スコープを選ぶとステージ構成が自動的に絞られる仕組みを見ました。9つの静的スコープがそれぞれ固有のEXECUTE/SKIPグリッドを持ち、プロジェクトの性質に応じてワークフローの形が変わる。これがV2のスコーピングです。
しかし実際にプロジェクトを進めていくと、既存のスコープにぴったり当てはまらない場面があります。この記事ではそんな時に使うAdaptive Composerを見ていきます。
2. 静的スコープの仕組みと課題
スコープとは何か
改めて整理します。スコープとは「33ステージのうちどれをEXECUTE（実行）し、どれをSKIP（スキップ）するか」を定義したグリッドです（Scopes and Depth ）。
1
スコープ: ステージのEXECUTE/SKIPグリッドmvpスコープは23/33ステージを実行し、bugfixは7/33に絞る。スコープが違えば、同じエンジンから異なるワークフローが生まれます。スコープの選ばれ方
スコープを選ぶパスは3つあります。
- キーワードマッチ: タスク記述に"fix"が含まれれば
bugfix、"mvp"ならmvp。スコープファイルのkeywordsフィールドに基づく自動検出 - 明示指定:
--scope enterpriseのようにフラグで直接選ぶ - フォールバック: どのキーワードにも当てはまらなければ、デフォルトの
featureが適用される
当てはまらない場面
試しに、あるタスクでスコープを選んでみましょう。「既存APIに認証を追加し、テストも書くが、デプロイパイプラインの構築は不要」というタスクの場合、どのスコープを選びますか。
feature: 全33ステージが動く。デプロイ系も走るので過剰bugfix: 7ステージのみ。設計やテストのステージが足りないmvp: 23ステージ。近いが、市場調査やモックアップは不要
どれも微妙にフィットしない。こういう場面が、Adaptive Composerの出番です。
3. Adaptive Composerとは
"選ぶ"から"作る"へ
ここで登場するのがAdaptive Composerです。
静的スコープが「人間が事前に定義済みスコープの1つを選ぶ」仕組みだとすれば、Adaptive Composerは「AIがタスクの特性を分析し、最小限で十分なステージ構成を動的に提案し、人間がフィードバックする」仕組みです。
重要なのは、Adaptive Composerの提案はあくまで提案だという点です。人間が承認するまでワークフローは始まりません。
3つの起動タイミング
Adaptive Composerは3つの場面で使えます。
| タイミング | 説明 | ユースケース |
|---|---|---|
| Front | 新規プロジェクト開始時 | どのスコープにも当てはまらない時に使う |
| Report | スキャン結果を入力として | SonarQube等の静的解析レポートファイルから修正フローを構成 |
| In-flight | ワークフロー実行中 | 途中で「このステージは要らない」と気づいた時 |
4. ARS（Autonomy Risk Score）の概要
Adaptive Composerはどう判断しているのか
Adaptive Composerが提案を組み立てる際、内部で**ARS（Autonomy Risk Score）**というスコアリングを行っています。5つの軸でタスクの特性を評価し、それぞれ0〜1の値を取ります。
| 軸 | 記号 | 何を見ているか |
|---|---|---|
| Intent Ambiguity | IAE | タスクの意味やスコープがどれくらい曖昧か |
| Codebase Structural Uncertainty | CSU | 影響を受けるコードの複雑さと結合度 |
| Verification Entropy | VE | 正しさを証明するためのテストや証拠の弱さ |
| Risk | R | 間違った時の影響範囲（お金、セキュリティ、顧客影響） |
| Unresolved Assumptions | UA | 明示されていない暗黙の前提がどれくらいあるか |
各スコアはLOW（0.00〜0.29）/ MED（0.30〜0.69）/ HIGH（0.70〜1.00）の3バンドに分類されます。
スコアとステージ数の関係
仕組みはシンプルで、スコアが高い軸があるほど、それを解消するためのステージが「必要」と判断されます。
- IAEが高い → Intent CaptureやRequirements Analysisが必要
- CSUが高い → Reverse EngineeringやDomain Designが必要
- VEが高い → Practices DiscoveryやBuild and Testが必要
5つのスコアは重み付け加重平均で合成スコア（0〜100）になりますが、最終的なステージ判断は軸ごとの値に基づいて行われます。合成スコアはワークフロー全体の「厚み」を示す参考値です。
5. /aidlc compose の使い方
基本の流れ
Adaptive Composerを使うには、
/aidlc compose に続けてタスクの説明を書きます。1
/aidlc compose "既存APIに認証を追加し、テストも書く。デプロイは不要"Adaptive Composerが分析を行い、3つのブロックで提案を返します。以下は実際の出力です。
提案の構造
Block 1: サマリー
1
2
3
8 stages EXECUTE / 25 SKIP, 5 approval gates
Scope: api-auth-addition (custom)
Mode: customBlock 2: ARSスコア表
| Component | Symbol | Score | Band |
|---|---|---|---|
| Intent Ambiguity | IAE | 0.35 | MED |
| Codebase Structural Uncertainty | CSU | 0.45 | MED |
| Verification Entropy | VE | 0.30 | MED |
| Risk / Blast Radius | R | 0.55 | MED |
| Unresolved Assumptions | UA | 0.40 | MED |
| Composite ARS (advisory) | — | 40 / 100 | Focused |
上記の例ではスコアリングはCodeKBが利用できなかったためfallback方式で算出しています。全コンポーネントがMEDバンドに収まり、Composite ARSは40/100（Focused）。CSUは認証が全エンドポイントに影響する一方で1パッケージに集中しているためMED、Rはセキュリティ関連だがPoC・内部ツール向けのためMED、VEは既存テスト基盤が強固なためlow〜MEDです。このFocused shape（8ステージEXECUTE）が妥当で、スパインは reverse-engineering → requirements → NFR → code → test となります。
Block 3: ステージ決定表（抜粋）
| # | Stage | Decision | Reasoning |
|---|---|---|---|
| 1.1 | intent-capture | SKIP | IAE=0.35 低MED; タスクが明確 — requirements-analysisで残余を解消 |
| 1.2 | market-research | SKIP | 内部ツール — 市場調査不要 |
| 2.1 | reverse-engineering | EXECUTE | CSU=0.45を削減; 既存エンドポイント・ミドルウェア構造をマッピング |
| 2.3 | requirements-analysis | EXECUTE | IAE=0.35 + UA=0.40を解消; 認証方式・対象エンドポイントを確定 |
| 3.2 | nfr-requirements | EXECUTE | R=0.55を削減; セキュリティNFRが認証の主要関心事 |
| 3.5 | code-generation | EXECUTE | コア — 実装 |
| 3.6 | build-and-test | EXECUTE | コア — 検証 |
| 4.1–4.7 | Operation全ステージ | SKIP | ユーザー明示:「デプロイは不要」 |
各ステージのEXECUTE/SKIPに対して、どのARSコンポーネントを削減するのか、あるいはなぜ不要なのかが理由付きで示されます。この例では33ステージ中8つだけが実行される、かなり絞り込まれた構成が提案されています。
承認ゲート
この提案に対して3つの選択肢が提示されます。
- Approve: このグリッドで新しいインテントを開始する
- Edit: ステージの追加/削除を指定する
- Reject: やめる（手動でスコープを選択）
Editを選べば「domain-designを追加したい」「nfr-requirementsは外したい」といった調整ができます。調整後に改めてApproveすれば、カスタムスコープが保存されてワークフローが始まります。
作ったスコープは再利用できる
Approveされたカスタムスコープはプロジェクトに永続化されます。具体的には2つのファイルが書き込まれます。
.kiro/scopes/aidlc-<name>.md（スコープ定義）scope-grid.json（EXECUTE/SKIPグリッド）
次回以降
--scope <name> で明示指定すれば同じグリッドが再利用されます。さらに、プロジェクトのデフォルトスコープとして設定することも可能です（詳細はCustomization Guide 参照）。チームで繰り返し発生するタスクパターン（例:「API追加はするがデプロイは別チームが担当」）をカスタムスコープ化しておけば、Adaptive Composerで毎回分析する手間も省けます。
なお、デフォルトではキーワード自動検出の対象外です。自動検出にも参加させたい場合は、承認ゲートでキーワードを付与します。
実行中の再構成
ワークフロー実行中に「残りのステージ構成を変えたい」場合も同じコマンドが使えます。
1
/aidlc compose "market-researchはスキップして、直接requirements-analysisに入りたい"Adaptive Composerは現在の進捗を考慮し、完了済みステージには触れず、まだ未実行のステージについてのみ再構成を提案します。
6. いつAdaptive Composerを使うべきか
迷ったらこの表を見てください。
| 状況 | 対応 |
|---|---|
| 9つのスコープの説明を読んで、しっくりくるものがある | そのスコープを使う。Adaptive Composerは不要 |
| どのスコープも微妙にフィットしない | /aidlc compose を使う |
| 実行中に「このステージ要らなかった」と気づいた | In-flight recomposeを使う |
| SonarQube等の静的解析レポートから修正フローを構成したい | /aidlc compose --report <path> を使う |
多くの場合、静的スコープで十分です。
feature（新機能）、bugfix（バグ修正）、mvp（最小構成のプロダクト）。タスクの性質が明確であれば、既存スコープがそのまま使えます。Adaptive Composerは「テンプレートの隙間」を埋めるためのものです。毎回使う必要はありません。
7. まとめ
この記事では静的スコープの課題と、それを補うAdaptive Composerの仕組みを見てきました。
- 静的スコープ: あらかじめ定義されたEXECUTE/SKIPグリッド。汎用テンプレートとして多くの場面で機能する
- Adaptive Composer: タスクの特性から動的にグリッドを提案する仕組み。テンプレートに当てはまらない時に使う
- ARS: Adaptive Composerが内部で使う5軸のスコアリング。各ステージの要否を判断する根拠になる
- 人間が最終判断: Adaptive Composerの提案には必ず承認ゲートがあり、人間が確認してから始まる
静的スコープとAdaptive Composerは対立するものではなく、補完関係にあります。タスクの性質が明確で既存スコープがフィットするならそれを使い、フィットしない場面でAdaptive Composerを使う。そういう使い分けです。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 5AI-DLC Workflow V2のAdaptive Composer: スコープを"選ぶ"から"作る"へ This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article