1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIで紐解くAWS AI-DLC v2:協働のトポロジー

1
Last updated at Posted at 2026-07-30

本記事の位置づけ — 本記事は、awslabs/aidlc-workflows リポジトリの規範ルールおよび利用ガイドを素材として、筆者が AI を活用して読み解き、まとめた解釈です。AWS が公式に発表した方法論ではなく、一次資料の翻訳・要約でもありません。

シリーズ — 本記事は AIで紐解くAI-DLC v2 シリーズの一部です。

参照した版Claude Code 実装を対象に、2026 年 7 月 27 日時点のコミット 9f91454(AIDLC_VERSION 2.5.11、core/)を参照しています。Claude Code 以外の実装(Kiro CLI/Kiro IDE/Codex CLI/opencode)は対象外で、記述が異なる場合があります。OSS 実装は更新が続いているため、最新の状態は公式リポジトリをご確認ください。


概要

AI-DLC v2 の各ステージには、主担当(Lead)と補佐(Support)が割り当てられます。ではその2者は、ステージが走っているあいだ実際にどうやって協働するのか。従来この問いに答えはありませんでした。補佐は「コンダクターが自分の中で引き受ける観点」で、独立した参加者ではなかったからです。

いま、それを決めるフィールドがあります。ステージのフロントマターの mode で、誰が誰と話すかという協働のかたち(トポロジー)を指します。実際に走るのは4つ。全員の役を1人で引き受ける inline、下書きを囲んで検分する subagent、順に手を入れる pipeline、一斉に意見を出す mob です(スキーマはもう1つ agent-team を受け付けますが、将来のための予約でランタイムを持ちません)。

本記事では、この4つが何を変えるのか、協働の記録がなぜファイルとして残るのか、そして意見が割れたとき誰が決めるのかを読み解きます。


不変の役割と、可変の関係

まず変わらない部分を整理します。役割は4つのトポロジーすべてで同じです。

  • 主担当 … そのステージの produces 成果物を所有する
  • 補佐 … 自分の作業を書く参加者
  • レビュアー … 終わったあとに外から検証する(宣言されたステージだけ)

そしてやり取りはすべてコンダクターを経由します。参加者どうしのやり取りは、すべてコンダクターが行った委譲と、コンダクターが持ち帰った返答でできています。エージェントが互いを呼ぶことはありません。委譲するのはコンダクターだけです。

変わるのは関係の張り方です。補佐が独立に動くのか、誰が誰の作業を見られるのか、意見が割れたらどうするのか。mode はそこを決めます。

4つのかたち

mode 関係 出荷数
inline コンダクターが全員の役を自分の文脈で引き受ける 28
subagent ハブとスポーク。下書きを囲んで各自が検分する 2
pipeline 鎖。順に手を入れ、最後の段が仕上げる 1
mob 一つの部屋。一斉に意見を出し、異議は記録される 1

32ステージのうち28は inline です。支配的なのは従来どおりの形で、残る4つが実際に別のエージェントを起動します。

inline

コンダクターが主担当と補佐のペルソナを自分の文脈に読み込み、主担当の出力をまず作り、そこへ各補佐の観点を重ねて統合します。補佐を起動してはいけないと明記されています。起動は他の3つのために取ってあります。

subagent

ハブとスポークです。まず主担当を起動して下書きを作らせ、次に各補佐をその下書きに対して起動します。このとき補佐どうしは互いを見ません。ある補佐に渡す指示に、別の補佐の作業は含まれません。最後にもう一度主担当を起動して統合させます。

作法の発見のステージがこの形です。パイプラインデプロイが下書きを書き、品質・デベロッパー・DevSecOps が互いに見えない状態で検分し、人との面談で判断を埋め、主担当が統合します。

pipeline

鎖です。主担当を先頭に、補佐が宣言された順に1体ずつ動き、各段が上流の作業をすべて見ます。段が成果物を直接書き換えてもよく、直列なので衝突しません。最後の段が成果物を完成させます。

リバースエンジニアリングがこの形です。デベロッパーが走査し、アーキテクトが統合して書く2段の鎖で、以前からそういう構造だったものに名前が付きました。順序そのものが意味を持つ場合のかたちです。

mob

一つの部屋に見立てた形で、境界の付いたラウンドとして走ります。ラウンド1では全補佐を主担当の下書きに対して並行に起動し、このとき互いを見ません。各自が自分の作業を書き、主担当が統合します。

ユーザーストーリーがこの形です。プロダクトが主担当で、デザイン・デベロッパー・品質が並行して意見を出します。


各自が書く記録

subagentmob では、起動された補佐が自分のファイルを書きますpipeline は後述のとおり例外です)。置き場所は決まっています。

<記録ディレクトリ>/<フェーズ>/<ステージ>/contributions/<エージェント名>.md

エージェントごとに別ファイルなので、並行して起動しても衝突しません。中身も決まっていて、1行目に書き手を示す印、続いて統合できる形で書いた内容、そして立場の表明(同意か異議か、それぞれ一行の理由付き)が並びます。

成果物を編集するのは主担当だけです(pipeline は例外で、鎖の各段が直接書き換えます)。実際の共同作業の場で、各人が自分のメモを書き、まとめ役が本文に反映する形に近いものです。

そしてこのファイルはステージの記録の一部として残ります。異議が返答テキストの中で流れて消えることはなく、ディスクに残ります。

pipeline だけは contribution ファイルを求めません。鎖が成果物に加えた編集そのものが協働の記録になるからです。

異議の仕分け

mob には、意見が割れたときの手順があります。ラウンド1で残った異議を、種類で仕分けます

判断の問題(どちらの立場も筋が通る。範囲・リスクの取り方・優先順位など)は、ステージの途中で人に問います。構造化された設問として提示し、人の裁定を受けてから統合を続けます。承認の場で事後に承認するのではなく、人も部屋の参加者として扱う、という考え方です。

知識の問題(詳しい者が決着させられる)はラウンド2に回します。異議を出したエージェントに、修正後の下書きと他の参加者の立場を渡して、取り下げるか維持するかを確認します。ラウンドは最大2つです。

仕分けを経ても維持された異議は、承認ゲートの完了報告に逐語で引用されます。人が判断するときに、反対意見がそのまま目に入るようにするためです。

無人で走る自律モードの構築中は、途中で人に問う手順を飛ばします。異議は記録され、最後のバッチのゲートで表に出ます。無人のループを止めないためです。

並行できない環境での約束

すべてのハーネスが並行起動をできるわけではありません。できない環境では、subagent のスポークも mob のラウンド1も順番に走ります

ただし渡す指示は変えません。各参加者が見られるものは、トポロジーが許した範囲のままで、隣の作業が見えるようにはなりません。

不変なのは「誰が何を見られるか」という約束で、同時に動くことではない、と明記されています。並行性は実装の都合にすぎず、設計の本質ではありません。

完了の証拠としての記録

contribution ファイルには、もう一つの役割があります。完了の決定論的な証拠です。

mob と、補佐を宣言した subagent のステージでは、宣言された補佐のファイルが欠けていたり、1行目の印を欠いていたりすると、そのステージを完了にできません。正当に走ったのにファイルを失った場合のための逃げ道として、環境変数で外せます。

これは品質を判定しているわけではありません。中身の良し悪しは見ず、「起動されたはずの参加者の作業が残っているか」だけを見ます。宣言した成果物がディスクに無いと完了を拒む仕組みと同じ性格の、証拠を求める前提条件です。止める力は承認ゲートだけが持つ、という構図は変わりません。この線引きは別記事「限界と注意点」で扱います。

主担当だけが戻る往復

レビュアーが NOT-READY を返したときは、主担当だけが呼び戻されます

集まるのは一度きりで、直す往復は主担当とレビュアーの間で行われます。全員を集め直すことはしません。レビュアーの判定と往復の仕組みは別記事「レビュアー」で扱います。

まとめ

mode が変えたのは、エージェントの編成ではなく関係の張り方です。役割は4つのトポロジーすべてで同じで、やり取りがコンダクターを経由することも変わりません。

そのうえで目を引くのは、協働の記録をファイルとして残したことです。誰が何を書き、誰がどこで異議を唱えたかがディスクに残ります。返答テキストの中で消えないので、あとから追えます。しかもそのファイルが、そのまま完了の証拠として機械的に検査されます。記録のために作ったものが、検証にも使われている形です。

もう一つは、意見が割れたときに人を部屋へ入れたことです。判断の問題はステージの途中で人に問い、知識の問題だけをもう1ラウンド回す。残った異議は承認の場に逐語で持ち込まれます。人を最後の承認者に留め置かず、議論の参加者として扱う設計になっています。

参照元

ファイル 内容
core/aidlc-common/protocols/stage-protocol.md §5 Multi-agent stages(ensemble topologies)。4トポロジーの定義、役割が不変であること、コンダクターがバスであること、contribution ファイルの構造、mob の異議の仕分け、並行できないハーネスでの約束、完了の証拠
core/tools/aidlc-stage-schema.ts mode の許容値と、pipelinemob が空でない support_agents を要求する検証。agent-team が予約である旨
core/aidlc-common/stages/inception/practices-discovery.md subagent(ハブとスポーク)の実例。主担当と3体の補佐
core/aidlc-common/stages/inception/reverse-engineering.md pipeline(2段の鎖)の実例
core/aidlc-common/stages/inception/user-stories.md mob の実例。主担当と3体の補佐
CHANGELOG.md 2.5.0:三役アンサンブル。出荷トポロジーが 28 inline/2 subagent/1 pipeline/1 mob であること、AIDLC_DISABLE_ENSEMBLE_EVIDENCE

関連記事

前の記事: 並列実行
次の記事: プラグイン機構
目次: AIで紐解くAI-DLC v2

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?