---
title: Skill で組み立てる自律 AI システム開発
tags: 
author: [Katuyuki Kakigi](https://www.docswell.com/user/k2works)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4EMYLMMKEW.jpg?width=480
description: Skill で組み立てる自律 AI システム開発 by Katuyuki Kakigi
published: July 01, 26
canonical: https://www.docswell.com/s/k2works/K8NNEE-2026-07-01-160009
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4EMYLMMKEW.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/PER9KVV6J9.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/P7XQLZZDEX.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/37K9L88D7D.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LJ3W322PJ5.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/8JDK4ZZ3EG.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/VEPKMDDP78.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/27VV911V7Q.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/5JGLZ2217L.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/47QYLPPNEP.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/KE4WDYY3J1.jpg)

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
→ 動詞 + ハイフン + 対象 の命名規則で発動の解像度を上げる


# Page. 12

![Page Image](https://bcdn.docswell.com/page/L71YZ66ZJG.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/G7WG9WW6E2.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4JZL955RE3.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/YE6WK991EV.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GE5MPNNLE4.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/97296553JR.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/DJY49KK87M.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/V7NYLRR9E8.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/YJ9P4MM373.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/GJ8DQLLLJD.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/LJLMXLLQER.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/47MYLM1K7W.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/P7R9KVL6E9.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PJXQLZWD7X.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/3JK9L8VDJD.jpg)

新しい 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 の種


# Page. 27

![Page Image](https://bcdn.docswell.com/page/LE3W32MPE5.jpg)

実プロジェクトでの効果 (例: 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 連鎖で整合


# Page. 28

![Page Image](https://bcdn.docswell.com/page/8EDK4Z637G.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/V7PKMDYPJ8.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/2JVV91GVJQ.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/5EGLZ281JL.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4JQYLP9N7P.jpg)

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