🧭 本記事は 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実務運用シリーズ ― 暴走させない、から仕組みにするまで。

◀ 前の記事: 【output style全文公開】Sonnet / OpusをFable 5的な振る舞いに寄せる：公式スニペットをコピペで移植する
▶ 次の記事: Claude Codeは「コードを書くAI」で終わらせるな：公式 document-skills でPDF・Excel・Word・PowerPointまで自動化する
🔍 あわせて読む: ループエンジニアリングでClaude Codeを実務に：Redmineチケット駆動開発のQA・開発・レビュー・統括エージェント設計 ― 改善対象となるエージェントチームの設計
🗺 シリーズ全記事の地図(親記事)