AIの自律度でツールを3階層に並べる——エージェンシー・ラダーで自作キットの位置を定める

dev-agent-teamシリーズの7本目。 前回（新機能は「取り込む」だけじゃない）で、 新機能を「型 vs エンジン」の軸で選り分ける運用の話を書いた。 今回は、その一段上——そもそも機能を並べる「軸」自体を借りてくる話。

X上で「1%しか知らないClaudeの17機能」という機能まとめが流れてきた。 17個の機能カタログそのものは、正直このキットの射程外のものが多い （Chrome拡張やDesign、Artifactsなど、Claude Codeの開発プロセスとは別の世界の話だ）。

だが、そのまとめが機能を並べるのに使っていた軸—— 「AIの自律度（エージェンシー）が上がる順に並べる」という発想—— これは借りる価値があった。 今回の改善（PR #19）は、 機能一覧ではなくこの分類軸だけを抜き出して、 自作キットの位置づけ説明に据えた記録だ。

1. エージェンシー・ラダー——自律度で3段に分ける

docs/native-tooling-integration.md に「エージェンシー・ラダー」という節を新設した。 AIがどれだけ自分から動くか（＝エージェンシー）で、機能を3つのTierに並べる。

• Tier 1（人間起点） — 人が明示的に指示して、はじめてAIが動く。従来のプロンプト実行の世界。
• Tier 2（継続学習） — プロジェクトの文脈・規約をAI側に溜めていき、指示の解像度を上げていく段階。
• Tier 3（AI起点） — AIが人間の指示を待たずに先へ進む。自律ループや並列ファンアウト、定期実行がここに来る。

Claude Code本体の /goal（自律ループ）、Dynamic Workflows（並列オーケストレーション）、 Scheduled routine（定期実行）は、いずれもTier 3に位置づけられる。 AIが自分から回り始める駆動力だからだ。

2. 自作キットは「Tier 3に線引きを持ち込む型」

この軸に乗せると、dev-agent-teamが何者なのかがきれいに言語化できた。

dev-agent-teamは、Tier 3（AI起点）に「AIが先に動いてよい区間」と「必ず人間が確認する区間」の線引きを持ち込む型である。

Tier 3のエンジンは強力だが、放てば承認も確認もスキップして突っ走る。 このシリーズで繰り返し書いてきた大原則—— 人間の承認ゲートはエンジンの自律ループに越えさせない——は、 まさに「Tier 3をそのまま使わず、線を引いて使う」ということだった。 自律度が最大の階層でこそ、型（どこで止まるか・誰が判断するか）が要る。

CONCEPT.md にも、段階導入の語り口として1段落を足した。 いきなりTier 3に飛びつくのではなく、Tier 2で文脈を固めてから、 Tier 3のエンジン併用へ1段ずつ上がる——という導入順の指針だ。 梯子（ラダー）は下から登るもので、飛び級すると足を踏み外す。

3. あえて転記しなかったもの

ここでも線引きを明確にした。元ネタは17機能のカタログだったが、 コンシューマ製品側の機能（Cowork / Chrome拡張 / Design / Projects / Artifacts など）は 一切転記していない。

理由は、それらがClaude Codeの開発プロセスという本キットの射程の外にあるからだ。 「便利そうな機能を全部リストに載せる」と、 このキットが大事にしている「型（何を・なぜ）vs エンジン（どう動かすか）」の境界が すぐに曖昧になる。借りたのはあくまで分類の軸だけで、中身は持ち込まない。

4. まとめ——「一覧」より「軸」を借りる

今回は新しい仕組みを足した回ではなく、自分の立ち位置を測る物差しを1本増やした回だ。

• 他人の「機能一覧」は射程外でも、その裏の「分類軸」は借りられる
• AIの自律度で並べると、ネイティブ機能はTier 3（AI起点）に集まる
• 自作キットの役目は、Tier 3に「AIが動く区間 / 人間が確認する区間」の線を引くこと
• 梯子は下から登る——Tier 2で文脈を固めてからTier 3のエンジンへ

情報の洪水の中では、機能を1個ずつ追うより、 それを並べる軸を1本持っておくほうが長く効く。 軸があれば、次に出る新機能も「これはTier 3だな、なら線引きが要る」と即座に置き場所が決まる。 次回は、この線引きを文章の約束から、permissions/hooksという「仕組み」へ 固め直した話を書く。

リポジトリはこちら: fecot/dev-agent-team