AI-DLC Workflow V2のexpressスコープ: 要件からデプロイまでを一直線で通す最軽量スコープ
設計もレビューも要らない、とにかく速く動くものを一直線で作りたい。そんなときはどのスコープを選べばいいの？ 実は最近、`express`という最軽量スコープが新しく加わりました。過去のスコープ紹介では触れられていなかった、要件からデプロイまでを最短で通すこのスコープを見ていきましょう。シリーズ第25回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 25AI-DLC Workflow V2のexpressスコープ: 要件からデプロイまでを一直線で通す最軽量スコープ This article
1. はじめに
この記事はAI-DLC Workflow V2（以降V2）解説シリーズの第25回です。
スコープが「どのステージを実行するか」を決め、DepthとTest Strategyが「各ステージの密度」を決めるという3軸の制御を扱いました。今回はそのうちスコープの1つ、
express（エクスプレス）に絞って掘り下げます。expressは後から加わったスコープです。この記事を読み終えると、
expressが何を実行して何を省くのか、他の軽量スコープとどう使い分けるのか、そしてどんなときに選べばいい（逆に避けたほうがいい）のかが分かります。2. expressスコープとは（定義・位置づけ）
では、
expressスコープの定義から見ていきましょう。expressは、要件（requirements）からコード、テスト、デプロイまでを一直線でたどる軽量なスコープです。設計パス（design pass）とレビュアーの起動（reviewer dispatch）を行わない点が特徴です。ここでいう設計パスとは、ドメイン設計や機能設計など、要件とコードの間に挟まる設計ステージ群を指します。スコープ定義ファイルのフロントマター（先頭の設定ブロック）には、この性格が明示されています。
| 項目 | 値 | 意味 |
|---|---|---|
name | express | スコープ名 |
depth | Minimal | アーティファクトの詳細度は最小 |
keywords | express, lightweight | このスコープに対応づけられたキーワード |
description | "Lightest run: requirements to deploy, no design pass, no reviewers" | 要件からデプロイまで、設計パスもレビュアーもなし |
skeleton | off | ウォーキングスケルトンのセレモニーを行わない |
review_cap | none | ステージレビューを起動しない |
review_cap: noneによってレビュアーが無効化されるため、成果物完成後のレビューエージェントは起動しません。Reviewer Class（第22回で扱ったレビューの重さを制御する仕組み）でいう「none」に固定された状態です。Depthは
Minimalです。第14回 で見たとおり、Minimalは各ステージが核心的な決定事項だけを1〜2ページ程度で記録するレベルです。Test StrategyもデフォルトではMinimalを継承します。ただしMinimalであっても、要件駆動のユニットテストと、コンポーネントごとの正常系（happy-path）テスト1つは最低限求められます。テストが完全に省かれるわけではありません。位置づけとしては、V2のスコープ群の中で最も実行ステージ数が絞られた部類に入る軽量スコープの1つです。具体的な数は次の節以降で確認します。
3. expressで動くステージ／省かれるステージ
では、
expressが33ステージのうちどれをEXECUTE（実行）し、どれをSKIP（スキップ）するかを見ていきましょう。コンパイル済みのスコープグリッドによると、
expressのEXECUTE / Totalは10 / 33です。実行されるのは次の10ステージです。| フェーズ | ステージ | 実行条件 |
|---|---|---|
| Initialization | Workspace Scaffold | 常時 |
| Initialization | Workspace Detection | 常時 |
| Initialization | State Initialization | 常時 |
| Inception | Reverse Engineering | 条件付き（ブラウンフィールド時） |
| Inception | Requirements Analysis | 常時 |
| Construction | Code Generation | 常時 |
| Construction | Build and Test | 常時 |
| Operation | Deployment Pipeline | 条件付き |
| Operation | Deployment Execution | 条件付き |
| Operation | Observability Setup | 条件付き |
この10ステージ以外は、すべてSKIPされます。
流れを言葉にすると、Requirements Analysis（要件分析）が契約（要件）を確立し、Code Generation（コード生成）がそれを実装し、Build and Test（ビルドとテスト）が検証し、Operationの末尾（deploy tail）がデプロイと観測を担います。この間に設計ステージは挟まりません。
いくつか補足します。
- Reverse Engineering（リバースエンジニアリング）は条件付きです。既存コードがあるブラウンフィールドのプロジェクトで、その理解を提供するために動きます。グリーンフィールド（新規）ならスキップされます。
- Operation（Deployment Pipeline / Deployment Execution / Observability Setup）も条件付きです。デプロイするものが何もなければ自己スキップします。これらのステージは、設計成果物の生成ステージが意図的に省かれている状況で、承認済みの要件、ワークスペースのデプロイ設定、ビルド結果、そして先行する末尾ステージの成果物を利用して動作します。
- Swarm（スウォーム、並列Construction）の経路は構造的に到達不能です。
expressはUnits Generation（ユニット生成）をスキップするため、Unit DAG（ユニットの依存グラフ）が存在せず、並列実行の前提が成立しないためです。
つまり
expressは、設計とレビューという2つの重い工程を丸ごと省くことで、要件から動くものまでの距離を最短にしているスコープです。4. 他スコープとの比較・使い分け
次に、他の軽量スコープと
expressを並べて比較していきましょう。実行ステージ数だけを見ると近いスコープがいくつかありますが、性格は異なります。コンパイル済みグリッドの数値で比較します。
| スコープ | 実行ステージ数 | Depth | 性格 |
|---|---|---|---|
express | 10 / 33 | Minimal | 要件からデプロイまで一直線。設計パスとレビュアーなし |
poc | 8 / 33 | Minimal | 実現可能性の検証。最小構成 |
bugfix | 9 / 33 | Minimal | 既存コードのバグ修正 |
mvp | 23 / 33 | Standard | グリーンフィールドのMVP。設計ステージを含む |
expressとpocはどちらもDepthがMinimalで、実行ステージ数も近い軽量スコープです。pocが8ステージなのに対し、expressは10ステージで、Operationの末尾（デプロイと観測）まで含めている点が違います。pocは実現可能性を確かめること自体が目的なのに対し、expressは動くものをデプロイまで持っていくことを見据えています。bugfixは9ステージで、既存コードのバグ修正に焦点を当てたスコープです。expressが「新しく作って出す」方向なのに対し、bugfixは「既存の不具合を直す」方向です。mvpは23ステージ、DepthはStandardで、expressとは性格が大きく異なります。mvpは設計ステージを含み、アーティファクトの詳細度も高い、本格的な新規開発向けのスコープです。設計を残さずスピードを取るのがexpress、設計を含めてMVPとして育てるのがmvp、という使い分けになります。同じMinimal・実行ステージ数10のスコープとして
refactor（10 / 33）やsecurity-patch（10 / 33）もありますが、これらはそれぞれコードの再構成、脆弱性対応という別の目的に特化しています。ステージ数が同じでも、EXECUTEされるステージの顔ぶれと目的が違う点に注意してください。5. expressを選ぶべき／選ぶべきでない判断基準
では、どんなときに
expressを選び、どんなときに避けるべきかを見ていきましょう。選ぶべき場面
expressが向いているのは、設計の合意形成やレビュー工程よりも、要件から動くものまでの速度を優先したい作業です。定義ファイルのフロントマターが示すとおり、これは「最軽量の実行」を意図したスコープです。- 要件がすでにはっきりしていて、設計パスを挟むほどの複雑さがない作業
- レビュアーの起動を省いても差し支えない、影響範囲の小さい変更
- 要件からデプロイまでを一気に通したいケース
選ぶべきでない場面
一方で、
expressが省く工程が必要なプロジェクトには向きません。- 設計上の判断を残したい場合。
expressは設計ステージをスキップするため、ドメイン設計や機能設計の成果物は生成されません。設計の意思決定を文書として残したいなら、mvpなど設計ステージを含むスコープを選びます。 - レビューによる品質ゲートが必要な場合。
review_cap: noneによりレビュアーが起動しないため、成果物へのレビューエージェントの所見は得られません。レビューを効かせたいなら、レビューを含むスコープを選ぶか、Reviewer Classの設定を見直します。 - 並列Constructionを使いたい場合。前述のとおりUnits Generationをスキップするため、Swarmの経路には到達できません。
判断の軸を1文でまとめると、設計とレビューを省いて速度を取れる作業なら
express、それらの工程が成果物として必要なら別のスコープ、という切り分けになります。6. ワークフローの流れ
最後に、
expressを選んだときのワークフローの流れを軽く見ていきましょう。ここでは詳細な追体験はせず、全体像だけを押さえます。流れは、初期化を経て、要件分析で契約を固め、コード生成で実装し、ビルドとテストで検証し、条件が揃えばデプロイと観測に進む、という一直線です。
図のとおり、要件とコードの間に設計ステージは挟まりません。ブラウンフィールドのときだけReverse Engineeringが要件分析の前段に加わります。末尾のデプロイ・観測はデプロイ対象がある場合に進み、なければ自己スキップします。
各ステージの内部でどんな承認ゲートやアーティファクトが動くかは、他のスコープと同じV2の共通の仕組みに従います。
expressが変えているのは、あくまで「どのステージを通るか」という経路だけです。7. まとめ
この記事では、V2の最軽量スコープの1つである
expressを見てきました。expressは、DepthがMinimal、review_capがnone（レビュアーなし）、skeletonがoffという設定を持ち、33ステージのうち10ステージをEXECUTEします。要件分析、コード生成、ビルドとテスト、そして条件付きのデプロイ・観測を一直線でたどり、設計パスとレビュアーの起動を省きます。テストはMinimalでも、要件駆動のユニットテストとコンポーネントごとの正常系テストは残ります。軽量スコープの中での位置づけとしては、実現可能性検証の
poc（8ステージ）よりデプロイまで踏み込み、バグ修正のbugfix（9ステージ）とは目的が異なり、設計ステージを含むmvp（23ステージ）とは性格が大きく違います。選ぶかどうかの判断は、設計とレビューを省いて速度を取れる作業かどうかにかかっています。設計の意思決定やレビューの品質ゲートを成果物として残したいなら、それらを含む別のスコープを選ぶのが筋です。自分のタスクが「要件は固まっている、あとは一直線で動くものを出したい」に当てはまるなら、
expressが候補になります。Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 25AI-DLC Workflow V2のexpressスコープ: 要件からデプロイまでを一直線で通す最軽量スコープ 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