AI-DLC Workflow V2のSpaceとIntent: 複数の作業を1つのワークスペースで整理する
機能開発の途中で緊急バグが飛び込んできた。AI-DLCのワークフロー状態はどうなる？ V2ではIntentという仕組みで作業ごとに進捗が独立しています。切り替え1つで、どのステージまで進んだか、どんな決定をしたかを丸ごと復元できます。SpaceとIntentの構造を見ていきましょう。シリーズ第17回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 17AI-DLC Workflow V2のSpaceとIntent: 複数の作業を1つのワークスペースで整理する This article
1. はじめに
この記事はAI-DLC Workflow V2（以降V2）シリーズの第17回です。ここまでのシリーズでは、5フェーズ・33ステージの全体構造、スコープ、エージェント、Memoryといった個々の仕組みを見てきました。
では、それらの仕組みが生み出す成果物やナレッジは、ディスク上でどう整理されているのでしょうか。1つのプロジェクトで複数の作業を並行して進めたい時、どうなるのでしょうか。
今回のゴールは、V2のワークスペース構造を支える2つの概念、Space（スペース） と Intent（インテント） を理解することです。この記事を読み終えると、以下が分かるようになります。
aidlc/ディレクトリが何を保持しているか- Intentがどう作られ、切り替わり、並行して存在するか
- Spaceが複数チームの共存をどう実現するか
- マルチリポジトリ構成でのワークスペースの配置
- 何がgitにコミットされ、何がローカルに留まるか
2. ワークスペースの全体像
まず全体像から見ていきましょう。
V2をインストールすると、プロジェクトルートにハーネス固有のエンジンディレクトリが1つ配置されます。Claude Codeなら
.claude/、Kiroなら.kiro/、Codexなら.codex/です。ここで重要なのは、エンジンディレクトリの中身を意識する必要はないという点です。/aidlcを実行するだけで動きます。エンジンとは別に、AI-DLCが生成・管理する情報はハーネスに依存しない
aidlc/ディレクトリにまとまります。「何のハーネスで動かしているか」ではなく、「何に取り組んでいるか」で整理されている構造です。では、2つのチームと複数の進行中Intentを持つワークスペースの全体像を見てみましょう。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
my-project/
│
├── .claude/ エンジン（ツール、フック、スキル、エージェント）
│ （.kiro/ や .codex/ の場合もある。ハーネスごとに1つ）
│
├── aidlc/ AI-DLCの生成物。ハーネス中立、gitにコミット
│ ├── active-space ← カーソル: 現在のスペース（gitignored、ユーザーごと）
│ └── spaces/
│ ├── default/ ★ ほとんどの人が使う唯一のスペース
│ │ ├── memory/ チームの作業方法（プラクティス）
│ │ │ ├── org.md フレームワークデフォルト
│ │ │ ├── team.md チームのプラクティス
│ │ │ ├── project.md プロジェクト固有プラクティス
│ │ │ ├── phases/ フェーズごとのルール
│ │ │ └── templates/ 出力フォーマットのオーバーライド
│ │ │
│ │ ├── knowledge/ エージェントが読むドメインナレッジ
│ │ ├── codekb/ リポジトリごとのコードナレッジ
│ │ │ └── <repo>/
│ │ │
│ │ └── intents/ 作業ごとに1サブディレクトリ
│ │ ├── active-intent ← カーソル: 現在のインテント（gitignored）
│ │ ├── intents.json レジストリ（全インテントの一覧）
│ │ ├── 260620-inventory-api/ ✓ 完了
│ │ └── 260624-export-bug/ ◷ 進行中
│ │ ├── aidlc-state.md ライフサイクル状態
│ │ ├── audit/ 決定トレイル
│ │ └── inception/requirements-analysis/requirements.md
│ │
│ └── payments-team/ 別のスペース（別チーム）— 同一構造
│ └── memory/ knowledge/ codekb/ intents/
│
├── repo-a/ コードリポジトリは兄弟として配置
└── repo-b/ Intentは複数のリポジトリにまたがれるこのツリーから読み取るべきポイントは3つです。
1.
aidlc/spaces/<space>/ が1つのチームの自己完結した世界。 プラクティス（memory/）、ナレッジ、コードナレッジ、Intentのレコードがすべて1つのスペースの下にまとまります。ソロ開発者や単一チームなら、spaces/default/だけを見れば十分です。2.
intents/<YYMMDD>-<label>/ が1つの作業のレコード。 ワークフローの1回の実行につき1ディレクトリが作られます。<YYMMDD>はUTC日付のコンパクト表記で、レコードが時系列にソートされます。アイデンティティはレジストリ内のUUIDv7で保持されるため、同日同名のIntentも衝突しません。3. 2つのカーソルが「今どこにいるか」を記録。
active-spaceとactive-intentはgitignoreされるユーザーローカルなポインタです。チームメイトが同時に異なるIntentで作業しても、互いのカーソルを上書きしません。3. Intent: 作業ごとに1つ
では、Intentの仕組みを詳しく見ていきましょう。
IntentはV2ライフサイクルの1回の実行を表します。1つのタスクにスコープされ、そのタスクの状態、監査トレイル、成果物を保持するレコードディレクトリを所有します。各Intentはスペースの
intents.jsonレジストリに1行を持ち、uuid（UUIDv7）が正規のアイデンティティ、slugが人間可読な短い名前です。自動生成
Intentを明示的に作成するコマンドはありません。作業を記述するだけでV2が自動生成します。
1
/aidlc Build a REST API for inventory management新しいワークスペースでこれを実行すると、V2がIntentを生成し、
aidlc/spaces/default/intents/260624-inventory-api/にレコードディレクトリを作成し、アクティブIntentに設定して最初のステージを開始します。2番目の作業を開始する
ここがワークスペースモデルの真価を発揮する場面です。機能開発の途中で無関係なバグへの対応が必要になったとしましょう。何もアーカイブせず、新しい作業を記述するだけです。
1
/aidlc Fix the timeout on the export endpointIntentがすでにアクティブな場合、V2はこれが現在の作業の続きではなく新しい無関係な作業だと認識し、2番目のIntentを開始するかどうか確認します。
1
2
3
▸ This looks like new work, separate from "inventory-api". Start a second intent?
(1) Yes — start a second intent (scope: bugfix)
(2) No — this continues the inventory-api workYesを選択すると、V2は2番目のIntentを生成してそちらに切り替えます。最初のInventory-apiのレコードディレクトリ、状態、進捗は中断した場所にそのまま保持されます。Noを選択すると、メッセージはアクティブIntentの一部として処理されます。
ここで重要なのは、V2が確認なしに2番目のIntentを生成することはないという点です。ゲートへの回答や要件の修正であれば、アクティブIntentに留まります。
切り替え
スペース内のIntentを一覧し、スラグで切り替えます。
1
2
/aidlc intent 全Intentを一覧
/aidlc intent export-bug "export-bug" に切り替え切り替えは
active-intentカーソルを移動するだけです。次に/aidlcを実行すると、そのIntentを停止した場所から再開します。同じステージ、同じ状態、同じ監査トレイルです。ライフサイクル
Intentの状態は
intents.jsonのstatusフィールドで管理されます。作業中はactive、全ステージが完了するとcompletedです。あるIntentで作業中に別のIntentに切り替えても、元のIntentの進捗は失われません。戻ってきた時に中断箇所から再開できます。4. Space: チームごとに1つ
続いてSpaceを見ていきましょう。
Spaceは1つのチームの完全な世界です。独自の
memory/（プラクティス）、knowledge/（ドメインナレッジ）、codekb/（コードナレッジ）、intents/（作業レコード）を持ちます。defaultで十分
ここまでの内容は、自動的に作成される
defaultという名前の単一スペース内で行われています。ソロ開発者や単一チームであれば、スペースに名前を付けることはなく、この概念を意識する必要はありません。複数チームが1つのプロジェクトを共有する時
では、どんな時にSpaceを分けるのでしょうか。複数のチームが1つのプロジェクトを共有していて、チームごとにプラクティスやナレッジを独立して持ちたい場合です。追加は簡単で、
default/の横に同じ構造のディレクトリがもう1つ増えるだけです。既存のファイルを移動する必要はありません。コマンド
Spaceの操作はIntentと同じ形式です。
1
2
3
/aidlc space 全スペースを一覧
/aidlc space create payments-team 新しいスペースを作成
/aidlc space switch payments-team アクティブスペースを切り替え新しく作成されたSpaceは、フレームワークのデフォルト（
org.md）と空のteam.md / project.mdで開始します。他のチームのプラクティスを継承するのではなく、ゼロから獲得していく設計です。切り替えの影響
スペースを切り替えると、2つのことが連動します。
- V2のリゾルバー: 次に開始するIntent、エージェントが読み込むプラクティスとナレッジは、切り替え先のスペースから取得されます。
- ハーネスのルール読み込み: ハーネスのネイティブなルールインクルードが新しいスペースの
memory/を指すようになり、次のターンからそのチームのプラクティスで動作します。
defaultのみの環境ではこの切り替えはノーオペレーションであり、コミット済みファイルが変更されることはありません。5. マルチリポジトリ構成
Intentは単一のリポジトリに限定されません。複数のリポジトリをどう配置するか見ていきましょう。
兄弟配置
コードリポジトリはワークスペースと同じディレクトリの直下に並べます。どれか1つの内部にネストするのではなく、フラットに並列配置します。
1
2
3
4
my-project/
├── aidlc/ # ワークスペース
├── checkout-api/ # リポジトリA ┐
└── checkout-web/ # リポジトリB ┘ 同じ階層に並列配置、自動検出される自動検出
リポジトリセットはIntent生成時にキャプチャされます。ワークスペースルート直下の子ディレクトリで独自の
.gitを持つものをV2が自動検出し、Intentのintents.jsonレコードに記録します。追加の設定は不要です。repos.json: セットの宣言
自動検出には兄弟リポジトリが既にクローンされている必要があります。チームメイトがワークスペースを新規チェックアウトした場合、どのリポジトリをクローンすべきか知る手段が要ります。
ワークスペースルートにオプションの
repos.jsonマニフェストを置くことで対応できます。1
2
3
4
5
6
7
{
"org": "your-github-org",
"repos": [
{ "name": "checkout-api", "branch": "main" },
{ "name": "checkout-web" }
]
}orgフィールドはデフォルトのクローンホストを提供します。urlが未指定のリポジトリはgit@github.com:<org>/<name>.gitからクローンされます。branchは新規クローンのチェックアウトブランチを指定し、省略するとリポジトリのデフォルトが使われます。ここで重要なのは、マニフェストは便利ツールであり、第二の真実のソースではないという点です。ランタイムではディスクの状態が勝ちます。マニフェストが駆動するのは
aidlc-workspace-syncツール（不足リポジトリのクローン、gitignoreの更新）と、宣言とディスクの乖離を報告する--doctorチェックのみです。6. コミットされるものとされないもの
aidlc/ディレクトリはgitにチェックインされます。では、何がgitignoreされるのか整理しましょう。| Gitignored（ユーザーローカル） | 理由 |
|---|---|
aidlc/active-space | スペースカーソル。コミットすると切り替えのたびにチームメイト間で競合する |
…/intents/active-intent | Intentカーソル。同上 |
…/intents/<id>/runtime-graph.json | 派生物。ランタイムが再生成する |
.aidlc-*、aidlc/.aidlc-sessions/ | マシンローカルなランタイム状態 |
それ以外はコミット対象です。
memory/**: チームのプラクティスknowledge/**: ドメインナレッジcodekb/**: コードナレッジintents.json: Intentレジストリ- 各レコードの
aidlc-state.md、audit/シャード、成果物
経験則は明快です。カーソルとランタイムのスクラッチはローカル、共有する作業はコミット。 この分離により、チームメイトが同時に異なるIntentで作業してもgitの競合が発生しません。
7. マルチIntent運用の実践パターン
概念を理解したところで、実際の運用パターンを見ていきましょう。
パターン1: 割り込み対応
機能開発中に緊急バグが報告された場面です。
1
2
3
4
5
6
7
# 機能開発中（Requirements Analysisまで進行済み）
/aidlc intent
◷ notification-system (scope: feature, stage: requirements-analysis)
# 緊急バグ報告
/aidlc Fix the payment timeout causing order failures
# → V2が新しいIntentの開始を提案 → Yesで切り替えバグ修正が完了したら、元のIntentに戻ります。
1
/aidlc intent notification-systemRequirements Analysisの途中から再開されます。どのステージまで進んだか、どんな回答をしたかはレコードディレクトリに保存されているため、復元に手作業は不要です。
パターン2: 並行開発
複数の独立した機能を進める場面です。
1
2
3
4
5
6
/aidlc intent
Active space: default
Intents:
◷ notification-system (scope: feature, stage: requirements-analysis)
✓ payment-timeout-fix (scope: bugfix, completed)
◷ export-csv (scope: feature, stage: code-generation)各Intentが独立したライフサイクルを持ち、どのステージまで進んでいるかが一目で分かります。
共有されるもの、分離されるもの
同じスペース内のIntentが共有するのは以下です。
memory/: プラクティス（全Intentに適用）knowledge/: ドメインナレッジ（全エージェントが参照）codekb/: コードナレッジ（Reverse Engineeringの結果が蓄積）
言い換えれば、あるIntentで蓄積されたコードナレッジや、Learning Loopで学んだ補正ルールは、同じスペース内の別のIntentにも反映されます。
一方、レコードディレクトリ（状態、監査、成果物）はIntent固有です。あるIntentの成果物が別のIntentに影響することはありません。
同時実行について
active-intentカーソルはファイルシステム上の1つのファイルです。同じワークスペースで2つのチャットウィンドウを開いて別々のIntentを進めると、このファイルの書き換えが競合します。現在の仕組みでは、1つのワークスペースで同時にアクティブなセッションは1つになります。Intent間の切り替えはシーケンシャルに行います。あるIntentで作業を中断し、別のIntentに切り替え、そちらが終わったら戻る。この「切り替えて戻る」フローが基本です。
Intentとgitブランチの関係
もう1つ整理しておきましょう。Intentの切り替えはV2のワークフロー状態（どのステージまで進んだか、どんな決定をしたか）を切り替えるものであり、gitブランチを自動的に切り替えるわけではありません。
Ideation・Inception phaseではコードを生成しないため、ブランチの分離は問題になりません。Construction phaseに入ると、V2はBolt（作業の実行単位）ごとにgit worktreeを自動作成し、ブランチレベルでコード変更を分離します。
つまり役割分担はこうです。Intentはワークフロー状態の分離を担い、gitブランチの分離はConstruction phaseのworktree機構が担います。
複数の作業を物理的に同時進行させたい場合は、ワークスペース自体を分ける（プロジェクトディレクトリを別に用意する）ことで対応できます。
8. まとめ
この記事ではV2のワークスペース構造を支える2つの概念を見てきました。
- Intent: 1つの作業に対応するライフサイクルの実行単位。自動生成され、複数保持でき、スラグで切り替え可能。ワークフロー状態の分離を担う
- Space: 1つのチームの世界。プラクティス、ナレッジ、Intentレコードを包含する。ソロや単一チームなら
defaultだけで完結
設計思想は明快です。カーソル（今どこにいるか）はユーザーローカル、共有する作業（成果物やプラクティス）はgitコミット。この分離により、チームメイト間の競合なしに作業の切り替えが実現されています。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 17AI-DLC Workflow V2のSpaceとIntent: 複数の作業を1つのワークスペースで整理する 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