🧭 本記事は Claude Code実務運用シリーズ の STEP 8「Fable 5で運用を棚卸しする」です。
前回の「棚卸し」の続編です。AIエージェントチームに自己改善ループを組み込みます。
シリーズ全体の地図と読む順は 親記事 にまとめています。
はじめに
前回の記事では、Fable 5を使ってClaude Codeの運用ルールを棚卸ししました。
- グローバルルール
- ガードレール
- カスタムコマンド
- Skill構成
- プロジェクト固有ルール
- 回帰テスト項目
こういったものをFable 5に見直させることで、Claude Codeの運用を整理する、という内容でした。
前回の記事はこちらです。
Fable 5が復活したので、Claude Codeの運用ルールを3つのプロンプトで棚卸しした〖プロンプト全公開〗
今回は、その続編です。
テーマは、AIエージェントチームSkillを "自己改善型"の運用にする ことです。
ただし、ここでいう自己改善型とは、AIが勝手に進化したり、Skill本体を自動で書き換えたりする意味ではありません。
重要なのは、次の考え方です。
実行ログを残す
↓
失敗や手戻りを分類する
↓
次回に活かせる改善候補に変える
↓
人間が確認して反映する
つまり、AIが勝手に成長する仕組みではなく、人間が監督できる形で、AIエージェントチームの運用品質を上げていく仕組みです。
前回は「棚卸し」、今回は「改善ループ」
前回の記事でやったことは、Claude Codeの運用ルールを整理することでした。
STEP 8:
Fable 5でClaude Code運用を棚卸しする
今回やることは、その次の段階です。
STEP 9:
Fable 5でAIエージェントチームに自己改善ループを組み込む
前回は、増えすぎたルールやSkillを整理しました。
今回は、整理したAIエージェントチームSkillを、実行するたびに改善候補が残る形にします。
なぜ自己改善ループが必要なのか
AIエージェントチームを作ると、最初は「動くこと」に注目しがちです。
例えば、次のような構成です。
Orchestrator
↓
Developer Agent
↓
Reviewer Agent
↓
QA Agent
↓
Verifier
この構成でも、タスクを分解して、実装し、レビューし、QA観点を出し、検証することはできます。
しかし、実務ではこれだけでは足りません。
なぜなら、AIエージェント運用では次のような問題が繰り返し起きるからです。
- 毎回同じ確認漏れが起きる
- 仕様確認が後回しになる
- レビュー観点が実装寄りに偏る
- QA観点が最後に付け足しになる
- RedmineやGitHubの確認順序が安定しない
- 同じような報告文を毎回手で整えている
- 失敗した理由が次回に引き継がれない
これでは、AIエージェントチームは「その場では動く」ものの、経験が蓄積されません。
人間のチームであれば、失敗したら次回の進め方を変えます。
AIエージェントチームでも同じです。
失敗や手戻りを、次回の改善材料として残す必要があります。
自己改善型AIではなく、自己改善型AIエージェントチーム運用
ここで注意したいのは、「自己改善型AI」という言葉です。
この言葉だけを見ると、AIモデルそのものが自動で学習して賢くなるように見えます。
しかし、Claude CodeやFable 5の実務運用で目指すべきなのは、モデル自体を勝手に学習させることではありません。
目指すべきは、こちらです。
自己改善型AI
ではなく、
自己改善型AIエージェントチーム運用
つまり、以下のような運用です。
- STATE.mdに実行ログを残す
- 失敗や手戻りを分類する
- 次回の予防ルールに変える
- Skill候補を提案する
- ただし、反映は人間が判断する
AIが勝手にSkillを更新するのではありません。
AIは改善候補を出すところまで。
最終判断は人間が行います。
自己改善の4レベル
今回、Fable 5に組み込ませたい自己改善ループは、4段階で考えます。
| Level | 内容 | 自動化してよい範囲 |
|---|---|---|
| Level 1 | プロンプト自己修正 | 出力形式の修正、再試行 |
| Level 2 | ツール選択の最適化 | 確認手段の優先順位付け |
| Level 3 | ワークフローの再構成 | 改善候補の提案まで |
| Level 4 | 新Skill候補の提案 | 候補提案まで |
Level 1: プロンプト自己修正
最も基本的な自己改善です。
出力が基準を満たさなかった場合に、エージェントが原因を分析し、プロンプトや実行方針を小さく修正して再試行します。
例です。
| 問題 | 対応 |
|---|---|
| 出力形式が崩れた | 形式指定を補強して再生成する |
| レビュー観点が不足した | 不足観点を追加して再レビューする |
| 要件の読み落としがあった | 要件確認ステップを追加して再確認する |
これは、自動化しても比較的安全な範囲です。
ただし、無限に再試行しないように、再試行回数は制限したほうがよいです。
Level 2: ツール選択の最適化
次は、タスクに応じた確認手段の最適化です。
AIエージェントは、毎回同じ方法で調べる必要はありません。
タスクによって、優先すべき確認手段は変わります。
| タスク | 優先する確認手段 |
|---|---|
| 仕様確認 | ドキュメント、Redmine、仕様書 |
| コード差分確認 | git diff、grep、対象ファイル確認 |
| 最新情報確認 | Web検索、公式ドキュメント |
| 不明点がある場合 | 推測せず確認事項として分離 |
これをSTATE.mdに記録しておくと、次回以降のタスクで「この種の作業では何を優先して確認すべきか」が見えやすくなります。
Level 3: ワークフローの再構成
Level 3では、作業の順番や分解方法を見直します。
例えば、最初は以下のように直列で進めていたとします。
要件確認
↓
実装
↓
レビュー
↓
QA観点作成
↓
受け入れ基準作成
しかし、実務ではQA観点や受け入れ基準を最後に作ると、手戻りが起きやすくなります。
その場合は、次のように変えたほうがよい場合があります。
要件確認
↓
QA観点・受け入れ基準の先出し
↓
実装方針の確認
↓
実装
↓
レビュー
↓
Verifier確認
つまり、実行履歴を見て、手戻りが多い工程を前倒しします。
また、依存関係がない作業は並列化できます。
- 仕様確認
- リスク観点整理
- QA観点整理
- 既存コード調査
これらは、状況によっては並列に進められます。
自己改善ループでは、「どの工程を前倒しすべきか」「どの工程を並列化できるか」を改善候補として残します。
Level 4: 新Skill候補の提案
Level 4は、繰り返し発生する作業パターンを検出し、新しいSkill候補として提案する段階です。
例えば、次のような作業が毎回発生しているとします。
- Redmine向けのレビュー完了コメントを作る
- QA観点をテスト項目に変換する
- 受け入れ基準をMarkdownで作る
- Slack向けに作業報告文を短く整える
- GitHubの差分からレビュー観点を抽出する
こうした作業は、毎回プロンプトで頼むより、Skill化したほうが安定します。
ただし、ここは注意が必要です。
注意
Level 4は「新Skill候補の提案」までに制限します。
AIが人間承認なしにSkill本体を作成・更新・反映してはいけません。
Skillは運用ルールに近いものです。
勝手に増やすと、責務が重複したり、古いSkillが残ったり、グローバルルールが再び肥大化したりします。
そのため、Fable 5には「Skill候補を出す」までを任せ、人間が採用判断をします。
自己改善ループの中心はSTATE.md
自己改善ループで最も重要なのは、STATE.mdです。
STATE.mdは、単なる作業メモではありません。
AIエージェントチームにとっての、実行ログであり、失敗ログであり、改善候補の置き場です。
例えば、次のような形式にします。
# STATE.md
## Task
- 対象:
- 目的:
- 入力情報:
- 期待成果物:
## Execution Log
| Step | Agent | Action | Result | Issue |
|---|---|---|---|---|
| 1 | Orchestrator | タスク分解 | 成功 | なし |
| 2 | Reviewer | 差分確認 | 一部不足 | テスト観点の確認漏れ |
| 3 | QA Agent | QA項目作成 | 成功 | なし |
| 4 | Verifier | 最終確認 | 要修正 | 受け入れ基準が曖昧 |
## Failures / Frictions
- テスト観点の確認がレビュー後半になった
- 受け入れ基準の粒度が粗かった
- 仕様書確認より先に実装観点へ進んでしまった
## Reusable Learnings
- 実装前にQA観点と受け入れ基準を先に出す
- 仕様が曖昧な場合は、推測せず確認事項に分離する
- レビュー時は、差分だけでなく既存仕様との整合性も確認する
## Improvement Candidates
- Orchestratorに「QA観点の先出し」を追加する
- Verifierに「受け入れ基準の曖昧さチェック」を追加する
- Reviewerに「既存仕様との差分確認」を追加する
## Skill Candidates
- Redmine報告コメント生成Skill
- QA項目生成Skill
- 受け入れ基準生成Skill
## Human Approval Required
- Skill候補を正式に作成するか
- Orchestratorの手順を変更するか
- グローバルルールに追加すべきか
このように記録しておくと、失敗が単なる失敗で終わりません。
次回の改善材料になります。
失敗を資産にする
自己改善ループで一番重要な考え方は、失敗を消すことではありません。
失敗を分類して、次回に使える形で残すことです。
例えば、失敗分類は以下のようにします。
| 失敗カテゴリ | 例 | 次回の予防策 |
|---|---|---|
| 要件理解ミス | 目的を取り違えた | 最初に目的・期待成果物をSTATE.mdに記録する |
| 仕様確認不足 | 仕様書を見ずに進めた | 実装前に仕様確認ステップを必須化する |
| 入力情報不足 | 添付資料を見落とした | Redmine / GitHub / 添付ファイル確認を初期ステップにする |
| ツール選択ミス | Web検索すべき場面で推測した | 最新情報は一次情報確認を優先する |
| 出力形式ミス | Markdown形式が崩れた | 出力テンプレートを明示して再試行する |
| レビュー観点漏れ | 境界値や既存仕様を見落とした | Reviewerのチェック観点に追加する |
| QA観点漏れ | 受け入れ条件が曖昧だった | QA Agentに受け入れ基準確認を追加する |
| セキュリティ観点漏れ | 機密情報や危険操作への配慮不足 | common-rulesやガードレールで制限する |
| コスト過多 | 不要に広範囲を調査した | 調査範囲と打ち切り条件を明確化する |
| 推測による誤判断 | 不明点を断定した | 「確認が必要」と明記する |
失敗分類があると、Verifierの役割も強くなります。
単に「OK / NG」を判定するだけでなく、なぜNGだったのか、次にどう防ぐのかまで扱えるようになります。
Fable 5にやらせること
今回、Fable 5にやらせるのは、既存Skillの自動変更ではありません。
やらせるのは、自己改善ループの設計です。
具体的には、次のような作業です。
- 既存のAIエージェントチームSkillを読む
- 自己改善ループを入れるべき箇所を見つける
- STATE.mdの形式を提案する
- 失敗分類ルールを作る
- improvement-engine.mdが必要か判断する
- 既存Skillに追記できるMarkdown案を作る
- 人間承認が必要なポイントを明確にする
- 導入順序と回帰テスト項目を作る
Fable 5は、実装させるよりも、このような設計レビューや運用改善に向いています。
Fable 5に投げるプロンプト
以下が、今回使うプロンプトです。
既存のAIエージェントチームSkillをFable 5に読ませたうえで、これを投げます。
プロンプトを見る
あなたは、AIエージェントチーム運用の改善アーキテクトです。
目的:
既存のAIエージェントチームSkillに、自己改善ループを安全に組み込む設計案を作成してください。
前提:
このAIエージェントチームは、単にタスクを完了するだけでなく、実行履歴から学習し、次回以降の判断精度・レビュー品質・作業効率を改善できる構成にしたいです。
ただし、完全自律でSkill本体やグローバルルールを変更することは避けます。
自己改善は、人間が監督できる範囲で、安全に、段階的に導入してください。
取り入れたい自己改善レベル:
* Level 1: プロンプト自己修正
* 出力が基準を満たさない場合、エージェントが原因を分析し、プロンプトまたは実行方針を小さく修正して再試行する。
* Level 2: ツール選択の最適化
* 過去の成功率・失敗パターン・タスク種別に基づき、適切なツールや確認手段を選びやすくする。
* Level 3: ワークフローの再構成
* タスクの分解方法、実行順序、並列化可能な工程を見直し、作業効率と品質を改善する。
* Level 4: 新Skill候補の提案
* 繰り返し発生する作業パターンを検出し、新しいSkill候補として提案する。
* ただし、Skill本体の作成・更新・反映は人間承認後に限定する。
設計原則:
1. Observability
* すべての重要な実行ステップ、判断理由、失敗、再試行、改善候補を STATE.md に記録できるようにする。
2. Failure as Asset
* エラーや手戻りを単なる失敗として扱わず、次回の予防に使える学習データとして分類・保存する。
3. Incremental Improvement
* 一度に大きく変えず、小さな改善差分として提案する。
* 改善によって既存の安定運用が壊れないようにする。
4. Human-in-the-Loop
* 重要な判断、コスト増加、未知の失敗、Skill本体の変更、グローバルルール変更は人間承認を必須にする。
制約:
* AIがSkill本体を勝手に更新しない。
* AIがグローバルルール、権限設定、セキュリティ設定を勝手に変更しない。
* Level 4は「候補提案」までに制限する。
* 改善案は小さな差分に分ける。
* 既存のAIエージェントチーム構成を壊さない。
* STATE.mdを自己改善データの中心にする。
* 抽象論だけで終わらせず、実際に追記できるMarkdown案まで出す。
重要:
この設計では、「自己改善型AI」を作るのではなく、「自己改善型AIエージェントチーム運用」を作る。
AIが勝手に進化する構成ではなく、人間が監督できる形で、実行ログから改善候補を抽出し、次回の品質向上につなげる構成にする。
追加で投げるとよいプロンプト
最初の出力が抽象的だった場合は、次のプロンプトを追加で投げます。
追加プロンプトを見る
上記の設計案を、既存Skillに追記できるMarkdown形式に落とし込んでください。
以下を具体化してください。
1. 変更対象ファイル
2. 新設ファイル
3. 追記位置
4. 追記本文
5. 導入順序
6. 回帰テスト項目
7. 人間承認が必要な判断ポイント
条件:
- 既存Skillの構成を壊さない
- 小さな差分にする
- Skill本体の自動更新は禁止する
- Level 4は新Skill候補の提案までに制限する
- そのまま貼り付けられるMarkdownで出力する
この2段階にすると、いきなり完成版を作らせるより安定します。
1回目:
全体設計を出させる
2回目:
既存Skillに貼り付けられるMarkdown差分へ落とす
前回記事と同じく、いきなり最終成果物を作らせないのがポイントです。
まず診断・設計させる。
その後で、反映用のMarkdownに落とし込ませる。
この順番のほうが、出力の精度が上がります。
補足：実際に自分の運用へ入れるときの順番
ここからは、Fable 5に出させた設計案を、実際に自分のAIエージェントチームへ反映していくフェーズの話です。
これまでは「Fable 5に設計させる」視点でしたが、ここからは「その出力を受け取ったあと、人間がどの順で入れるか」に切り替わります。
実際に追加するなら、いきなり全ファイルを変更するのではなく、次の順番が安全です。
Step 1: STATE.mdの拡張だけ入れる
最初はログを残すだけにします。
記録する項目は、例えば以下です。
- 実行ステップ
- 担当エージェント
- 判断理由
- 失敗
- 手戻り
- 再試行
- 改善候補
まず観測可能にすることが重要です。
記録できていないものは改善できません。
Step 2: Verifierに失敗分類を追加する
次に、Verifierへ失敗分類ルールを追加します。
- 要件理解ミス
- 仕様確認不足
- 入力情報不足
- ツール選択ミス
- 出力形式ミス
- レビュー観点漏れ
- QA観点漏れ
- 推測による誤判断
Verifierは、単に最終確認するだけでなく、「今回の失敗はどの種類か」を分類します。
Step 3: Orchestratorに改善候補の扱いを追加する
次に、Orchestratorへ改善候補の扱いを追加します。
- 次回から手順に入れるべきこと
- 前倒しすべき確認
- 並列化できる工程
- 人間確認が必要な工程
ただし、この段階でも自動反映はしません。
あくまで改善候補として残します。
Step 4: improvement-engine.mdを検討する
改善候補が増えてきたら、専用ファイルを作ります。
improvement-engine.md
役割は、STATE.mdを読んで改善案を整理することです。
- 失敗パターンを読む
- 再発防止策を作る
- ワークフロー改善案を出す
- Skill候補を出す
- 人間承認が必要なものを分離する
ここでも、Skill本体を勝手に更新してはいけません。
Step 5: Skill候補の棚を作る
最後に、Skill候補を管理します。
skill-candidates.md
ここには、次のような情報を残します。
# skill-candidates.md
## Candidate: Redmine Report Writer
### Pattern
レビュー完了後に、Redmine向けコメントを毎回作成している。
### Trigger
- レビュー結果を添付したあと
- テスト項目を添付したあと
- 受け入れ基準を添付したあと
### Expected Output
- Textile形式のRedmineコメント
- 添付内容の要約
- 次の確認依頼
### Benefit
- 報告文の品質が安定する
- 毎回同じ説明をしなくてよい
- 報告漏れを防げる
### Human Approval
Required
こうしておけば、Skill化すべき作業を後から判断できます。
やってはいけないこと
自己改善ループを入れるときに、やってはいけないこともあります。
AIにSkill本体を勝手に更新させない
一番危険なのは、AIにSkill本体を自動更新させることです。
Skillは運用の土台です。
勝手に変わると、いつの間にか挙動が変わります。
AIに任せるのは以下までです。
| OK | NG |
|---|---|
| 改善候補を出す | Skill本体を勝手に更新する |
| 追記案を出す | グローバルルールを勝手に変更する |
| Skill候補を出す | セキュリティ設定を勝手に変更する |
| 回帰テスト項目を出す | 権限設定を勝手に変更する |
改善案を一気に全部入れない
改善案が出ると、全部入れたくなります。
しかし、一気に入れると何が効いたのかわからなくなります。
自己改善ループでは、小さく入れることが重要です。
1. STATE.md拡張
2. 失敗分類
3. 改善候補
4. improvement-engine
5. Skill候補管理
この順番で十分です。
Level 4を自動反映まで進めない
Level 4は特に注意です。
新Skill候補を提案させるのはよいです。
しかし、Skillの作成・更新・有効化は人間承認後に限定します。
新Skill候補の提案
↓
人間が確認
↓
採用するものだけSkill化
↓
小さくテスト
↓
問題なければ運用に入れる
この流れを守るだけで、かなり安全になります。
導入後の回帰テスト
自己改善ループを導入したら、最後に回帰テストをします。
Fable 5には、以下のような確認項目を作らせます。
# 回帰テスト項目
## 1. 既存運用が壊れていないか
- 既存のAIエージェントチーム構成で通常タスクが実行できるか
- Orchestratorの役割が過剰になっていないか
- Reviewer / QA / Verifier の責務が重複していないか
## 2. STATE.mdに必要な情報が残るか
- 実行ステップが記録されるか
- 判断理由が記録されるか
- 失敗や手戻りが記録されるか
- 改善候補が記録されるか
## 3. 失敗分類が機能するか
- 要件理解ミスを分類できるか
- 仕様確認不足を分類できるか
- 出力形式ミスを分類できるか
- 推測による誤判断を分類できるか
## 4. 改善候補が自動反映されていないか
- 改善案が候補として止まっているか
- Skill本体が勝手に変更されていないか
- グローバルルールが勝手に変更されていないか
## 5. Human-in-the-Loopが守られているか
- Skill変更に人間承認が必要になっているか
- セキュリティ設定変更に人間承認が必要になっているか
- コスト増加を伴う処理に人間承認が必要になっているか
自己改善ループを入れると、AIエージェントチームは強くなります。
ただし、強くなるほど、回帰テストも必要になります。
運用を変えたら、必ず「変えたことで壊れていないか」を確認します。
まとめ
前回は、Fable 5でClaude Codeの運用ルールを棚卸ししました。
今回は、その続編として、AIエージェントチームSkillに自己改善ループを組み込む考え方を整理しました。
要点は、次の3つです。
1. 失敗をSTATE.mdに残す
2. 失敗を分類して再発防止に変える
3. Skill候補は提案までに止める
AIエージェントチームで重要なのは、一度うまく動かすことではありません。失敗や手戻りが、次回の改善材料として残ることです。
そのために、実行ログ・失敗ログ・改善候補・Skill候補・人間承認ポイントを、STATE.mdを中心に残していきます。
そして、ポイントはAIを勝手に進化させることではありません。
自己改善型AI
ではなく、
自己改善型AIエージェントチーム運用
です。
AIに任せるのは、改善候補を出すところまで。
Skill本体、グローバルルール、権限設定、セキュリティ設定は、人間承認なしに変更させません。
Fable 5は、コードを書かせるだけのモデルではありません。
Claude Codeの運用設計、Skill構成、ガードレール、AIエージェントチームの改善ループを見直す用途でもかなり使えます。
前回の「棚卸し」から、今回の「自己改善ループ」へ。
Claude Codeを単なる実装AIとして使うのではなく、実務運用そのものを継続改善する仕組みにしていくのが、今回の狙いです。
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。