0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Fable 5に運用を評価させたら、評価より先に自己改善ログの索引漏れが見つかった【棚卸しプロンプト+免責テンプレ公開】

0
Last updated at Posted at 2026-07-10

🧭 本記事は Claude Code実務運用シリーズ の STEP 8「Fable 5で運用を棚卸しする」です。
8-4 の自己改善型チームが残す「運用記録」そのものを Fable 5 に棚卸しさせ、記録の穴を見つけて塞ぎます。
シリーズ全体の地図と読む順は 親記事 にまとめています。

ChatGPT Image Jul 10, 2026, 03_25_00 PM.png

はじめに:魔が差して「私の運用は何点?」と聞いてみた

ある日、Fable 5 にこう聞きました。

あなたの持っている情報をすべて使って、私のAIエージェント運用がどの位置にあるのか教えて

返ってきたのは、L1〜L7 の成熟度ラダーと、かなり立派な評価でした。正直、悪い気はしませんでした。

スキルレベル.png

返ってきた評価。それっぽく見えるが、この評価自体は「捨てる」対象です(理由は本文)

でも、この記事はその評価の話ではありません。 先に釘を刺しておきます。

⚠️ AI に自分の運用を評価させると、評価はかなり甘めに出ます。 「レベルいくつ」「上位◯%」のような数字も返ってきますが、較正された指標ではありません。同じプロンプトを投げれば、たいていの人にそこそこ高い評価が出ます。順位やレベルは真に受けないでください。

では何の話かというと——この「甘い評価セッション」の途中で、自己改善ログの索引漏れという実害のある穴が見つかり、その場で塞がれた話です。評価は呼び水にすぎず、本当の成果は棚卸しでした。

何が起きたか:評価セッションが棚卸しに変わるまで

時系列で書きます。

1. レベルを聞く → それっぽいラダーが返る

最初の回答は、もっともらしい成熟度モデルと褒め言葉でした。ここで終わっていたら、この記事はありません。

2. 「これも動いていますよ」と実物を差し込む

8-4 で作った自己改善型チームは、実行のたびに STATE(ラン単位の記録)と RUNLOG(全ランの索引)を残します。「その記録が実在する」と伝えたところ、Fable 5 の挙動が変わりました。一般論をやめて、ディスク上のファイルを実際に読み始めたのです。

3. 発見:索引に載っていないランがあった

RUNLOG(1ラン=1行の追記式索引)と、各リポジトリに散らばる実行記録を突き合わせた結果、別リポジトリで実行した1ランが中央の索引に未登録であることが分かりました。

さらに悪いことに、そのランの記録は git 管理外のディレクトリにしか存在しませんでした。フォルダを消せば、実行履歴ごと消える状態です。自己改善の仕組みを作った本人(私)が、索引化の運用を1回分だけ漏らしていた——これは自分では気づけない種類の穴でした。

実際の検出出力がこちらです(チケット番号はマスクしています)。

## 実装ループ(自律開発)

| チケット | final_state | 修正ループ | build | test | 人手介入 | RUNLOG |
|---|---|---|---|---|---|---|
| #XXXXX | NEEDS_HUMAN_DECISION      | 0 | 1回PASS | 1回PASS(242/0) | 0 | 登録   |
| #YYYYY | NEEDS_HUMAN_DECISION      | 0 | 1回PASS | 1回PASS(269/0) | 8 | 登録   |
| #ZZZZZ | APPROVED_FOR_HUMAN_REVIEW | — | —      | —              | — | 未登録 |

- 要対応: 中央 RUNLOG 未登録のラン #ZZZZZ(別リポジトリ実行分の索引化漏れ)

横断ダッシュボードが索引漏れを「未登録」としてフラグした出力。この1行のために、評価セッションをやった価値がありました

4. 修復:誠実な1行で遡及登録

RUNLOG に1行追記して塞ぎました。ポイントは、存在しない記録をでっち上げないことです。

| (run_id) | (チケット番号) | APPROVED_FOR_HUMAN_REVIEW | ... | -(記録プロトコル導入前ランの遡及登録。原記録: <リポジトリ>/...) |

STATE ファイルが無いランなら「無い」と注記して登録する。索引の完全性と記録の誠実性は両立できます。

5. 副産物:工程横断ダッシュボード

穴が見つかったついでに、「企画レビュー」「実装ループ」「コードレビュー」という別々のスキルの実行記録を、1枚に集計するダッシュボードを作らせました(後述)。

なぜ「プロンプト一発」では棚卸しにならないのか

このセッションを振り返ると、効いた要素は3つで、プロンプトの文面はそのうち1つでしかありませんでした。

  1. 実物がディスクにあること。 記録(RUNLOG・STATE・成果物)が実在しないと、AI は一般論と褒め言葉しか返せません。8-2(ルールの棚卸し)や 8-4 で運用の「痕跡」を残す仕組みを作っていたことが、今回の前提条件でした。
  2. 証拠を差し込み続けること。 「◯◯も動いています」「このリポジトリも私のです」と実物を出すたびに、評価が具体化し、検証が深くなりました。1往復で終わらせない。
  3. 見つかった穴をその場で直させること。 「指摘で終わり」にせず、修復と成果物まで同じセッションでやらせる。棚卸しは「対話 + 実物 + 修復」のループです。

逆に言うと、評価だけを求めるプロンプトをコピペしても、甘い褒め言葉が返って終わります。 それがこの手法の正直な限界です。

棚卸しプロンプト全公開(3段構え)

① 呼び水(この答えは信用しない)

あなたの持っている情報をすべて使って、私のAIエージェント運用がどの位置にあるのか教えて

② 証拠の差し込み(ここからが本番)

◯◯(スキル名/仕組み)も動いていますよ
このリポジトリも私のものです: <URL>
定期的に◯◯しています。実行記録は <パス> にあります

③ 実物検証の要求(評価を検証に変える)

その評価の根拠になった実行記録を、実際にファイルを読んで確認してください。
評価よりも先に、記録や運用に問題(漏れ・矛盾・消えると困る状態)があれば教えてください。
見つかった問題は、この場で直す前提で。

免責テンプレ(チームに共有するとき用)

この手法を社内に紹介するなら、キャプションで釘を刺すことを強くおすすめします。そのまま使えるテンプレを置いておきます。

⚠️ この評価はかなり甘めに出ます。「レベル」「上位◯%」のような数字は
較正された指標ではないので、真に受けないでください。
人と比べるスコアではなく、自分の運用の穴を見つける壁打ちとして使うのがおすすめです。

副産物:工程横断ダッシュボードで「測るもの」

棚卸しの副産物として、複数スキルの実行記録を1枚に集計するスクリプトを作らせました。集計している指標は以下です。何を測るかのリストとして持ち帰ってください(スクリプト自体は各自の記録形式に依存するので、骨組みだけ載せます)。

指標 意味
実行数 スキルごとのラン数(索引と実ファイルの突合で漏れも検出)
最終判定の内訳 承認 / 人間判断待ち / ブロック の分布。「全部承認」はむしろ疑う
修正ループ回数 差し戻しが何回で収束したか
人手介入回数 自律実行中に人間の承認・判断が何回必要だったか
検証生存率 AI の指摘のうち、独立検証を生き残った割合
未検証項目数 「やれなかったこと」が理由つきで記録されているか
# 骨組み: 各スキルの RUNLOG(Markdown表)を読み、横断集計する
from pathlib import Path

AGENT_OPS = Path.home() / "Documents" / "agent-ops"

def parse_runlog(skill: str) -> list[dict]:
    """RUNLOG.md の表を1ラン=1dictに変換する(実装は形式に合わせて)"""
    ...

for skill_dir in AGENT_OPS.iterdir():
    runs = parse_runlog(skill_dir.name)
    # 実行数・判定内訳・介入回数を集計して1枚のMarkdownに出力する
    ...

今回の穴から得た、記録運用の3条件

索引漏れという具体的な穴を一般化すると、AI エージェントの運用記録には3つの条件が要る、というのが今回の学びです。

  1. 索引は一箇所に。 ラン索引(RUNLOG)は正本を1つに決め、どのリポジトリで実行しても必ずそこに追記する。
  2. 記録は消えない場所に。 git 管理外のフォルダ「だけ」に実行記録を置かない。索引か記録のどちらかは耐久ストレージに。
  3. 横串のキーを持つ。 チケット番号のような共通キーを全工程の記録に入れておくと、「この案件は企画レビューと実装ループの両方を通った」が後から突合できます。

まとめ:AI に求めるのは点数ではなく発見

  • 「私の運用は何点?」への答えは甘く出ます。点数は捨ててください。
  • 価値があるのは、評価の過程で AI に実物の記録を読ませ、穴を見つけさせ、その場で塞がせること。
  • それができるのは、8-2・8-4 で「棚卸しの対象になる実物」を積み上げてきたからです。記録がなければ、棚卸しは始まりません。

評価は入口、発見が本体。「AI に褒めてもらう」で終わらせず、1つでも実害のある穴を見つけて塞げたら、そのセッションは成功です。


このシリーズの歩き方

Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?