本記事の位置づけ — 本記事は、
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 実装は更新が続いているため、最新の状態は公式リポジトリをご確認ください。
概要
14体のエージェントは、それぞれどのモデルで動くのか。以前は各エージェントのファイルにモデル名が直接書かれていました。いまは書かれていません。
代わりに宣言されているのは 階層（tier）です。値は3つで、そのエージェントの仕事がどれだけ判断を要するかを表します。モデル名ではなく、仕事の性質を書きます。
そして重要な原則が1つあります。階層は下げることはあっても、上げることはありません。 セッションで選んだモデルより良いものを勝手に使うことはなく、逆に勝手に落とすこともほとんどありません。
本記事では、3つの階層が何を区別しているのか、なぜモデル名を直接書かないのか、そして「下げるだけ」という原則が何を守っているのかを読み解きます。
3つの階層
| tier | どんな仕事か | 体数 |
|---|---|---|
judgment |
曖昧さの中で複数の制約を突き合わせる判断。出力が下流へ波及する | 9 |
balanced |
明示された基準に照らして新しい入力を判定する（レビュアーの形） | 2 |
templated |
方法論がすでにナレッジにあり、型に沿って出力する | 3 |
judgment はアーキテクト・デベロッパー・プロダクトなど9体です。設計判断がそのまま下流の工程を縛るので、ここが弱いと全体に効きます。
balanced はレビュアー2体です。レビューは「初めて見る成果物を、明示された基準に照らす」仕事で、判断の形が違います。
templated はデリバリー・パイプラインデプロイ・オペレーションの3体です。作るもの（デリバリー計画、CI/CD 設定、運用手順）の方法論はすでにナレッジに書かれていて、それに沿って埋める性格が強いためです。
モデル名を書かない理由
一次資料に明快な理由が書かれています。階層の名前は「ダイヤル」ではなく「仕事」を表すからです。
モデル名を直接書くと、新しいエージェントを足すときに「いま何が最良のモデルか」を知らないと分類できません。仕事の性質で名前を付けておけば、そのときのモデルの品揃えを知らなくても分類できます。
そしてもう1点、投影先は1つではありません。ビルドが階層を各ハーネスのやり方に翻訳します。
- Claude Code はエージェントファイルの
model:とeffort: - Codex は役割ごとの設定ファイルのモデルと推論の強さ
- Kiro はエージェントの JSON
- opencode はエージェントファイルの
model:とvariant:
書くのは1か所で、翻訳は投影先ごとに行われます。 モデル名を直接書いていたら、ハーネスが増えるたびに全エージェントを触ることになります。
セッションを引き継ぐという投影
Claude Code での投影が、この設計のいちばん分かりやすい現れです。3階層はそれぞれこう書き出されます。
| tier | model: |
effort: |
|---|---|---|
judgment |
inherit |
書かない |
balanced |
sonnet |
書かない |
templated |
sonnet |
medium |
judgment の9体は inherit を書きます。 これは「セッションのモデルに従う」という明示の値で、指定を忘れているのではありません。推論の強さのほうは書かず、キーを省くことでセッションの値を引き継ぎます。明示するか省くかは違っても、狙いは同じです。一次資料はそれを「利用者の上限を黙って下げない」と書いています。
強いモデルでセッションを開いたなら、判断を要する仕事も強いままで動きます。逆に軽いモデルを選んだなら、その選択が尊重されます。
balanced は中位のモデル（出荷設定では Sonnet 相当）を指定し、推論の強さは指定しません。templated だけが中位のモデルに加えて推論の強さを一段下げます。
下げるだけという原則
原則が明記されています。
階層が動かすのは下方向だけで、上方向へは動かない。しかも下げるのは型に沿った仕事のときだけ
つまりフレームワークが自分の判断で能力を落とすのは、templated の3体、そこ1か所だけです（中位のモデルに加えて推論の強さも下げます）。それ以外はすべて、セッションの選択をそのまま通すか、モデルだけを中位に留めるかのどちらかです。
ここは以前と変わった点でもあります。かつては9体に最上位のモデルが直接ピン留めされていました。強いモデルを固定で当てるのは一見有用ですが、利用者が別のモデルを選んでいても上書きしてしまいます。いまは選択を尊重する設計に変わっています。
上限の指定
逆に、意図的に能力を抑えたい場面もあります。費用を抑える、実験する、といった理由です。
そのために上限を設定できます。組織やプロジェクトの方針を書くファイルに階層の上限を書けば、それより上の階層はそこまで引き下げられます。ビルド時に環境変数で一度だけ効かせることもできます。
既定では上限は掛かっていません。 抑えるかどうかは利用者が明示的に決めるもので、フレームワークの初期値ではありません。
ハーネスによる再現度の差
投影先の事情で、できることが違います。
Kiro ではモデルのピンをすべて外しました。指定したモデル ID がその環境で有効になっていないと、委譲がまるごと失敗していたためです。エージェントを起動しようとするたびに失敗する状態は、階層による最適化よりはるかに大きな問題なので、全員がセッションのモデルを引き継ぐ形にしています。
その結果、いまの Kiro では階層の区別が投影に一切出ません。3階層ともモデルを指定せず、推論の強さを指定する場所も無いためです。宣言は同じでも、そこから何も再現されない状態です。
同じ宣言から出発しても、投影先の制約でどこまで再現できるかは変わる、ということです。
導入時の含意
この設計は、導入を検討する側に1つの含意を持ちます。
フレームワークはモデルの質を補いません。 判断を要する9体はセッションのモデルをそのまま使うので、軽いモデルで始めれば、設計判断も軽いモデルが行います。成果物の質はモデルの選択にそのまま出ます。
以前のように最上位モデルが固定で当たっていれば、利用者の選択に関わらず一定の質が出ました。いまはそうではありません。選択を尊重するということは、選択の責任も利用者に返るということになります。導入判断の観点は別記事「導入判断」で扱います。
まとめ
エージェント階層が変えたのは、宣言する対象です。モデル名という「いまの答え」ではなく、仕事の性質という「変わりにくい事実」を書くようにしました。だから新しいエージェントを足す人は、そのとき使えるモデルの顔ぶれを知らなくても分類できます。
そして投影の側で目を引くのは、セッションの選択をそのまま通す形を積極的に使っていることです。判断を要する仕事にはモデルを固定せず inherit を書き、推論の強さはキーごと省きます。どちらもフレームワーク側の判断で上書きしないための書き方です。
「下げることはあっても上げない」という原則は、そのための線引きです。フレームワークが自分の判断で能力を落とすのは、型に沿った仕事、1か所だけに絞られています。
参照元
| ファイル | 内容 |
|---|---|
core/tools/aidlc-tiers.ts |
階層の定義と投影。3階層が何を区別するか、Claude Code／Codex／Kiro それぞれのキーへの翻訳、「下げるだけ、上げない」の原則、名前が仕事を表しダイヤルを表さない理由、上限の指定 |
core/agents/（14ファイル） |
各エージェントの tier: 宣言。素のモデル名は持たない |
core/memory/org.md |
上限を書ける層のひとつ |
CHANGELOG.md |
2.3.1：階層の導入と、9体が最上位モデルのピンをやめてセッションを引き継ぐようになった経緯。2.2.15：その前段の modelOverride からの改名。2.5.6：Kiro でモデルのピンをすべて外した理由 |
関連記事
前の記事: プラグイン機構
目次: AIで紐解くAI-DLC v2