以前から、Claude Codeのセッションからふりかえりを行ってコンテキストを改善するアプローチを模索している。
うまくいかない部分を直しながらいろいろ試しているのだが、現状いったん落ち着いているふりかえりの形式がある。自分ではこれを “Bottom-Top-Bottom Retrospective” と名付けている。スキルとして公開しているので、興味があったら使ってもらってもかまわない。
/plugin marketplace add lacolaco/claude-plugins
/plugin install retrospective@lacolaco-pluginsエージェントタスクの6ステージ
このふりかえりでは、エージェントのタスクが開始して終了するまでの流れを6つのステージに分解することにしている。
- Input: 指示、コンテキスト、スキル、CLAUDE.md、ツール説明を受け取り、能動的に情報収集する
- Interpretation: 入力の意味、意図、前提を読み解く（解釈）
- Planning: タスク分解、順序付け、ツール選定、スコープ定義を行う
- Action: ツール呼び出し、ファイル編集、コマンド実行を行う
- Inspection: 結果を検証し、成功か失敗かを判断する
- Output: ユーザーへ報告し、何を残すかを決める
Bottom-Top-Bottom Retrospectiveでは、このステージの下流から上流に向けた診断と、上流から下流に向けた改善案の設計がセットになっている。
Bottom-to-Top Diagnosis
前半は、OutputからInputに向かって、セッションの時系列を遡っていく。タスクがはじまってから終わるまでの間に、各ステージにおいて何がうまくいき、何がうまくいかなかったのかを洗い出す。KPTでいうところのKeepとProblemを、6つのステージを下から上に見ていく。
結果から原因へ遡るアプローチは、源流管理の考え方と通じるものがある。
源流管理とは、ある工程で不具合が発生した場合、不具合の現象だけでなく、上流（源流）工程にさかのぼって原因を突き止める管理手法のことです。
上流から始めると「自分が前提にしたこと」「考慮した選択肢」を無制限に思い出そうとする作業になり、探索空間が発散する。意識化された前提だけが集まり、無意識の前提は永遠に漏れる。逆に、下流の具体的事象を起点にすれば、辿るべきパスは事実上 1 本に絞られる。ふりかえりの起点を想像ではなく事実に置くことでふりかえり全体が発散しにくくなることを期待している。
Top-to-Bottom Treatment
次のセッションのための改善は上流から下流への向かって行う。その理由は、処置の効果を構造的に保証するためである。下流から始めると個別の問題を潰す対症療法になりがちで、どの層が真の防御線か曖昧になり、せっかくの逆引き診断で得た真因を捨てることになる。上流から流せば、1箇所の修正が下流の多数の問題に同時に効くようなレバレッジにも期待できるし、多くの場合、下流よりも上流で手を打つほうがコストも低い（シフトレフトの考え方）。
また、なるべく多層防御にはしないようにしている。「上流で塞いだ穴は下流で塞がない」という規則は、効率の問題ではなく、責任の所在を明確化するためにある。多段防御を許すと次のような点が問題となりうる:
- どの層が真の防御線か曖昧になる
- 上流が崩れても下流が補うので、上流の不備が可視化されなくなる
- 「念のため下流にも置く」が常態化し、ルール・スキル・ガードレールが肥大化する
まとめ
- Bottom-Top-Bottom Retrospectiveは、エージェントのタスクを6ステージ（Input→Output）に分け、下流の結果から上流の原因へ診断してから、上流から下流へ改善策を設計するための枠組み。
- 診断をOutput起点にすることで、事実に沿って原因の探索経路を絞りやすくし、前提の想起漏れや発散を抑える。
- 改善をInput起点にすることで、修正のレバレッジを高め、対症療法や多段防御の肥大化を避けつつ、責任の所在を明確にする。