Skill で組み立てる自律 AI システム開発

Skill で組み立てる 自律 AI システム開発 ── 規律と連鎖を仕組み化する ── 2026-07-09 IT 系の濃ゆい話をする会 #21

自己紹介 • カキギカツユキ • ネット通販の会社で 業務システムの開発運用 • 売掛金・買掛金管理業務 も担当 • ボッチ情シス（情シスは実質ひとり） • クソザコトレーダー

今日の構成: 3 つの論点 1 2 3 なぜ規律が要るか 何を部品化するか どう運用に組み込むか 自律 AI 開発で起きる、一貫性 ・連鎖・視点の問題を整理す る。 Skill / Agent / Hook / Orchestrator を、再利用でき る規律ユニットとして見る。 Validating / SOT / 段階導入で、 作った仕組みを腐らせない。

このトークの主題 AI に「全部やらせる」のではなく、 AI が従う「規律 (Skill)」を組み立てる • 自律 AI 開発 = Loop で AI が動き続ける状態 • そのまま回すと「やったり / やらなかったり」「設 計と実装が乖離」 • 解決は Skill = 再利用可能な規律ユニット を積み上げ ること • 本日のゴール: Skill / Agent / Hook の 設計パターン を 持ち帰る

論点 1 / 3 なぜ規律が要るか 自律 AI 開発で起きる、一貫性・連鎖・視点の問題を整理する

自律 AI 開発で繰り返しぶつかる壁 壁 症状 一貫性 セッションごとに違う 規律 TD D / レビューが気まぐれ 連鎖 分析 → 実装 → 運用が手作業 成果物 手順書や Try が腐る 視点 1 視点で盲点が残る → プロンプト工夫では限界。仕組み が要る

論点 2 / 3 何を部品化するか Skill / Agent / Hook / Orchestrator を、再利用できる規律ユニットとして見る

解決アプローチ: 3 層の規律ユニット Skill Agent タスクに応じて自動発動する 専門ナレッジ。 Progressive Disclosure で必要なときだけ投入。 特定ロールの 視点 を持つ専門家。並列起動で多 視点レビュー。 Hook Orchestrator PreToolUse / PostToolUse / Stop 等のイベントで動 く 自動化スクリプト。pre-commit や通知と連動 。 複数 Skill を 連鎖実行 するハブ Skill。フェーズの 順序と引数を保持。 → 「Skill = レゴブロック」「Orchestrator = 設計図」

規律ユニットの全体像 → AI が動く前に、従う規律を部品として組む

Skill の解剖 skills/<name>/ ├── SKILL.md ├── references/ ├── templates/ └── scripts/ # 発動条件+手順+出力 # 詳細仕様(必要時のみ) # 成果物テンプレート # ヘルパースクリプト SKILL.md の本質 • 発動条件 (description): どんな入力で呼ばれるか • 手順: AI が辿るチェックリスト的ワークフロー • 出力契約: 成果物のフォーマット (MD / Issue / PR / コード) → プロンプトをファイルに固定し、セッションを越えて再利用

Skill のカテゴリ設計 プレフィックス 役割 例 orchestrating-* 複数 S k ill を連鎖実行するハブ analy sis / develop ment / operation analyzing-* 上流分析 (戦略 / 要件 / 設計) requirem ents / dom ain- m odel / architecture developing-* TD D 実装 / リリース backend / frontend / release operating-* 環境構築 / CI/C D / 運用 setup / cicd / deploy / docs validating-* 成果物の監査 (放置防止) iteration - plan / operating - setup creating-* ドキュメント生成 adr / journal / iteration- report planning-* / tracking-* 計画と進捗 releases / prog ress → 動詞 + ハイフン + 対象 の命名規則で発動の解像度を上げる

Agent: 視点を分離する agents/<role>.md • 役割定義 + プロンプト + 利用可能ツール • Skill が「何をやるか」、Agent が「どの視点で見るか」 • XP チーム全体 の役割を Agent として分離 XP チームロール programmer interaction-designer tester technical-writer architect user-representative product-manager executive project-manager

論点 3 / 3 どう運用に組み込むか 連携パターン・設計原則・段階導入で、作った仕組みを腐らせない

連携パターン (1) Skill → Agent 並列レビュー review-skill (Skill) ├── agent-A (視点 1) ──┐ ├── agent-B (視点 2) ──┤ 並列実行 ├── agent-C (視点 3) ──┤ └── agent-D (視点 4) ──┘ ↓ 統合 レビュー報告書 (高 / 中 / 低 で分類) • 1 セッションで 補完関係の指摘 が集まる • TDD では拾えない UX / セキュリティ / ドキュメントの盲点を捕捉 • 視点を増やすほど 網羅性 が上がる (矛盾は驚くほど少ない)

連携パターン (2) Orchestrator が Skill を連鎖 orchestrating-analysis → creating-adr → analyzing-architecture → analyzing-domain-model → analyzing-data-model → analyzing-review (5 視点並列) → planning-releases • 各 Skill は 単機能 / 副作用なし • Orchestrator が フェーズの順序 を保持 • 自律ループ (Ralph Loop 等) と組み合わせて 長時間自律実行 が可能

Orchestrator による連鎖実行 → フェーズ順序と並列視点を Skill 側に閉じ込める

連携パターン (3) Validating で「放置」を断つ operating-setup → 手順書 operating-script → スクリプト validating-operating-setup ← ここがキモ □ 章別チェックリスト □ 証拠列必須 (バージョン / パス / 検出結果) □ A/B/C/D 4 バケツ分類 □ 着手提案 → AI に「やったはず」を許さない番人 Skill を置く

Validating Skill は品質ゲート → 生成と監査を分けるから、成果物が腐りにくい

連携パターン (4) Hook で機械化する PreToolUse → deny-check / 安全ガード PostToolUse → fourmolu / lint / format pre-commit → 型チェック + テスト (Domain だけ高速) Stop → 通知 / ジャーナル自動生成 • レビュー頼みを コードレベルで強制 に変える • {-# DEPRECATED #-} 等の 言語機能 も Hook と同等の規律装置 • 「忘れる」を物理的に不可能にする

設計原則 (1) Single Source of Truth • 計画ドキュメント = SOT、GitHub / Issue は 同期先 • syncing-* Skill で片方向同期 • Issue 本文には 受入基準を直書き (リンクだけだと劣化) • AI に編集対象を 1 つに絞る ことで「どっちが最新?」を排除 → AI は SOT を更新 → Skill が他システムへ伝播

設計原則 (2) Progressive Disclosure • SKILL.md は 薄く (発動条件 + 手順骨格) • 詳細仕様は references/ に分離し、必要時だけ AI が読む • コンテキストウィンドウを 節約 しつつ深い知識を提供 • 「全部読ませる」のではなく「必要な分だけ」 SKILL.md (薄い) ──── references/deep-spec.md ──── templates/output.md ──── scripts/helper.sh

設計原則 (3) 動詞ベースの命名 良い例 悪い例 analyzing-requirements requirements validating-iteration-plan plan-checker creating-adr adr-tool orchestrating-development dev-workflow → 動詞 で始めると AI が「いつ発動するか」を判断しやすい → Skill = 動作 (動詞) であり、リソース (名詞) ではない

設計原則 (4) Skill の責務分離 種別 例 不変条件 生成系 (crea tin g - * / an alyz in g - *) 成果物を作る テンプレートに従う 連鎖系 (orch estra ting - *) S kill を順序づける 引数 / 順序を保持 監査系 (va lid ating - *) 成果物を検査する 改変しない・着手提案のみ 同期系 (sync in g - *) 外部システムへ伝播 S OT を変えない → 生成 / 連鎖 / 監査 / 同期 を混ぜないことで責務が明瞭になる

自律ループとの組み合わせ [Loop 制御 (Ralph Loop 等)] ↓ 引数 = orchestrating-development IT3 [Orchestrator Skill] ↓ 順次起動 [個別 Skill] → [Agent 並列起動] → [Hook で品質ゲート] ↓ 完了報告 → 次の Skill [end-of-life 検出 → ループ離脱] • ループは タスク枯渇 を検知して抜けるのが安定運用のコツ • AI 単独完結 / 環境依存 / 人手作業 を 事前分類 すれば no-op が減る

自律ループの安定運用 → タスクが尽きたら抜ける、品質ゲートで戻す

新しい Skill を生む着眼点 「やったはずなのに腐る」工程に Skill が宿る 腐るもの 対応 S k ill の役割 手順書 valid ating - o perating - setup (実施状況の差分) 計画ドキュメント valid ating - iteration- p lan (上流設計との整合性) 設計判断 creating - ad r (なぜその設計にしたかを残す) コミットに載らない判断 creating - jo urnal (物語として残す) 進捗 tra cking - p rog ress (バーンダウン + メトリクス) → 定型作業 + 放置リスク のペアが新 Skill の種

実プロジェクトでの効果 (例: 1 人 + AI 体制) 指標 整合性検証で計画段階で撲滅した不整合 数値 2 IT 合計 3 5 件 多視点レビューで検出した指摘 Sp rint0:4 2 / 実装後:2 3〜3 1件 1 イテレーションのテスト増加 1 17 → 20 7 → 3 00 件 自律ループ 1 日のベロシティ 設計ドキュメント → 1 人 + AI でチーム規模の生産物を維持できる ≒ 20 SP 1 0 種を 1 Skill 連鎖で整合

アンチパターン やってしまいがち なぜダメか 大きな 1 つの S kill にすべて詰める 再利用 / 監査 / 差し替えが不能 S kill が成果物を直接外部システムへ書く S OT が二重化する Va lid atin g を生成系に組み込む 「自分を自分でレビュー」で盲点が残る A g ent を 1 人だけ使う 視点の偏りを温存する ループ離脱条件を決めない n o- o p を延々と繰り返す

段階導入のロードマップ 1 最小構成 git-commit + creating-adr 2 分析強化 analyzing-* + 多視点レビュー 3 開発強化 developing-* + PR レビュー 4 運用強化 operating-* + validating-* 5 計画強化 planning-* + syncing-* 6 自律化 Loop + Hook + 品質ゲート

他プロジェクトへ持ち込むカスタマイズ点 • agents/: XP 以外でも可。組織の実ロールに合わせる • orchestrating-*: フェーズ定義をプロジェクトのライフサイクルに合わせる • analyzing-tech-stack: 言語 / FW に応じた設計判断テンプレ • developing-*: TDD のアプローチ (インサイドアウト / アウトサイドイン) を選択 • operating-*: CI / IaC / バックアップの環境固有設定 • Hooks (settings.json): pre-commit / 通知 / セキュリティを段階導入 → 最小テンプレ + プロジェクト固有 Skill の上乗せ が基本戦略

まとめ • 自律 AI 開発の本質は 「規律ユニット」の組み立て • Skill / Agent / Hook / Orchestrator の 4 部品 で構成する • 命名は 動詞、責務は 生成 / 連鎖 / 監査 / 同期 に分離する • 「やったはずなのに腐る」工程に Validating Skill を置く • SOT は 1 つ、同期は片方向、視点は並列に増やす • 規律はレビュー頼みではなく コードレベルで機械化 する AI を信じる前に、AI が従う規律を組み立てよう

ご清聴ありがとうございました 質問・議論歓迎です