dev-agent-teamシリーズの6本目。 Claudeが便利機能を出したら自作ワークフローは不要になるのかで 「型 vs エンジン」の判断軸を作った。今回はその判断軸を実際に運用して、 新しく出た機能を選り分けた話。
- 新機能は「取り込む」といっても深さが違う——全部を手順化しない
- 情報注記／影響確認／推奨明文化の3段階に振り分けた
- セキュリティ機能は「足す」より「自分のデータフローへの影響確認」が本義
前回（PR #16）、
Claude Code本体の新機能を「型（何を・なぜ）」と「エンジン（どう動かすか）」の
レイヤーに分けて評価する判断軸を docs/native-tooling-integration.md に作った。
ただ、判断軸は作って終わりではない。本体は新機能を出し続けるので、
出るたびにその軸にかけて選り分ける運用が要る。
今回の改善（PR #18）は、
native-feature-watch という定期ウォッチのroutineで拾った5つの新機能を、
その判断軸で評価して取り込んだ記録だ。
ポイントは「取り込む」の解像度——5つとも扱いが違う。
1. 「取り込む」にも深さがある
新機能が出ると、つい「便利そうだからフローに組み込もう」となる。 だが前回の大原則——人間ゲートはエンジンに越えさせない／型の骨格は動かさない—— を守るなら、多くの機能は手順そのものを変えずに済む。
今回、取り込みを次の3段階に振り分けた。
- 情報注記 — 「そういう設定・挙動がある」と案内するだけ。キットのロジックは変えない
- 影響確認 — 自分のキットのデータフローに照らして、影響の有無を確かめて記録する（特にセキュリティ機能）
- 推奨として明文化 — キットの既存原則（最小権限など）と整合する機能を、具体的な推奨設定に落とす
重要なのは、どれも「手順・Stop Condition・Human Decision Pointは不変」という点だ。 新機能で型を強化することはあっても、骨格は動かさない。
2. 実際に選り分けた5つ
拾った機能と、振り分けた扱いはこうなった。
- ① Sonnet 5 / 1M context — 前提バージョンのNOTEに追記しただけ。 使えるモデルが増えたという事実の反映で、手順には触れない。
- ②
autoMode.classifyAllShell— Phase 5/6の/goal機械的ループで使える推奨設定として案内（§2.5新設）。 前回定めた「/goalは機械的サブループ限定」の中で効く設定なので、案内に留める。 - ③ auto modeの破壊的コマンド自動ブロック — 情報注記（§2.6新設）。 キット側のガードレールと方向が同じなので、「本体にもこういう安全弁がある」と記すだけ。
- ④ Cross-Session Messaging Security — 影響確認が本義。 詳細は次節。
- ⑤
disallowed-tools（Skills frontmatter） — 最小権限の 推奨として明文化（§6）。詳細は後述。
5つのうち、手順に踏み込んだものはひとつもない。 ①③は事実の注記、②⑤は既存原則の範囲での案内・推奨、④は影響確認。 「新機能ラッシュ＝フロー改修ラッシュ」にはならない、という運用の実演だ。
3. セキュリティ機能は「取り込む」より「影響確認」
いちばん考えどころだったのが ④ の Cross-Session Messaging Security だ。 セッションをまたいだメッセージ授受のセキュリティに関する本体の変更で、 これは「機能として足す」のではなく「自分のキットに影響があるかを確かめる」のが本義になる。
そこでキット内でセッション/エージェント間のデータ授受がどこにあるかを洗い出した。 該当するのはDynamic Workflowだけ——複数subagentのfindingsをsynthesizeに集約する経路で、 しかも集約専用・後段に人間レビューゲートがある。 この形なら今回のセキュリティ変更の影響を受けない、と確認できた。
セキュリティ機能に対しては、「便利だから入れる」ではなく「自分のデータフローに照らして影響を評価し、結果を記録する」のが正しい向き合い方だ。
合わせて、workflowのコメントに「エージェント間で受け渡すデータはuntrusted扱い」 であることを明文化した。影響なしを確認した上で、前提を言語化して残す—— これも「取り込み」の一形態だが、手順は1行も変わっていない。
4. 最小権限（least-privilege）の一貫性
⑤ の disallowed-tools は、Skillのfrontmatterで使えるツールを絞れる機能だ。
これはキットが元々持っていた最小権限の原則と真正面から噛み合う。
実は同じパターンを、以前routineで Write / Edit を
外したときに使っている。「そのエージェントに不要な書き込み権限は最初から与えない」という発想だ。
今回はそれを、ネイティブSkill化するときの推奨設定として具体化し、
どのSkillでどのツールを外すかの対象マッピングまで示した。
ただしここでも線引きがある。safe-refactoring や
legacy-modernization のように実際にファイルを編集するSkillは対象外。
編集が仕事のものから編集権限を奪っては本末転倒だ。
「最小権限」は「全部から権限を剥がす」ではなく、
役割に必要な権限だけを残すという意味で一貫させている。
5. まとめ
今回は新しい仕組みを足した回ではなく、 作った判断軸を回して、新機能の取り込みの深さを決めた記録だ。
- 「取り込む」には深さがある——情報注記／影響確認／推奨明文化を使い分ける
- セキュリティ機能は「足す」より「自分のデータフローへの影響を確認して記録する」
- 最小権限は「全部剥がす」ではなく「役割に必要な分だけ残す」で一貫させる
- 新機能で型を強化しても、手順・Stop Condition・Human Decision Pointは動かさない
判断軸を持っていると、新機能ラッシュに振り回されずに済む。 「便利そう」を全部フローに突っ込むと型はすぐ太って使えなくなるが、 軸にかけて『これは注記』『これは影響確認だけ』と振り分ければ、骨格は軽いまま強化だけ拾える。 前回は判断軸を作る話、今回はそれを運用する話—— 型は作るより使い続けるフェーズで効いてくる、と改めて感じている。
リポジトリはこちら: fecot/dev-agent-team