第13章・キャップストーン

キャップストーン演習 — 自分だけのワークフローを設計する

これまで学んだ概念(第2章・第3章)とツール(第4章)、組織運営の感覚(第7章)、ワークスペース構造(第5章・第8章)を一つにまとめ、ごく小さな規模でも最初から最後まで自分自身で設計・実行する最後の演習である。正解は一つではない。本章は「何を作るか」ではなく、「どの順序で決めれば漏れなく作れるか」をガイドする。

この章で行うこと

自分が実際に繰り返している作業を一つ選び、ミニ・マルチエージェントチームの問題として再定義する
サブエージェントを作る前に、ガードレール(権限・承認ゲート)を決める
オーケストレーター・スペシャリスト・ハンドオフ契約を実際のファイルとして実装する
結果を検証し、計画と何が違っていたかを振り返る

この演習の目標

第4章§2ではあらかじめ決められたシナリオ(reviewer、writer)に沿って進め、第11章では決められたdomain(co-retail)でバリアント(variant)を作った。今回はシナリオもdomainも自分で決める。規模は小さくてもよい。実際に毎週繰り返している5分程度の雑務が一つあれば十分である。重要なのは、「この決定をなぜこの順序で下したのか」を自分自身で説明できるようになることである。

ステップ1 — 問題定義とチーム設計

質問1. 何を繰り返しているか?

最近繰り返し行っている作業を一つ思い浮かべる。例:「毎週議事録を読んでアクションアイテムだけ抜き出して整理する」「新しいブログ記事の下書きを書いてトーンを確認する」「PR説明を書いてチェックリストに漏れがないか確認する」。

質問2. この作業を単独のエージェントに任せた場合、第1章§2(単一エージェントの限界)で学んだ3つの問題のうちどれが生じるか?

コンテキスト過負荷か(複数の段階が一つのセッションで処理され混ざるか)、役割の衝突か(作成者が自分の成果物を自ら検証しなければならないか)、並列性の欠如か(独立した下位タスクが複数あるか)? この答えが第1章§3のチーム構成を決定する。

質問3. オーケストレーターとスペシャリストを何人に分けるか?

第1章§3~§4bを参考に最小構成を描いてみる。スペシャリストが一人だけでも構わない。オーケストレーター(メインセッション)とスペシャリスト(サブエージェント)一人だけでもチームである。各スペシャリストの入力と出力を一文で書き留める(「このエージェントはXを受け取ってYを出す」)。

ステップ2 — ガードレールを先に決める

第3章の原則どおり、サブエージェントを実際に作る前に権限から決める。以下の表を埋めてみる。

このスペシャリストができなければならない最小限の作業は何か?(例:ファイルの読み取りのみ / 読み取り+書き込み / 外部API呼び出し)
人の確認なしに絶対に実行されてはならない作業はあるか?(第3章の「破壊的・外部影響」段階に該当するもの。例:実際の送信、実際のコミット)
失敗した場合、再試行するのか、ロールバックするのか、人に引き渡すのか?(第2章§4の再試行・ロールバック・エスカレーション基準を参照)

この3つの質問への答えが、そのままサブエージェントのfrontmatterのtoolsフィールドと、オーケストレーターに指示する際に入れる「ここまでで止まる」という文言になる。

ステップ3 — サブエージェント定義とワークフロー実装

第4章§2の演習で行ったのと同じ方法で、Claude Desktop App(またはCode)にチャットで直接サブエージェントを作ってほしいと依頼する。以下は埋め込む空のテンプレートである。角括弧の部分を自分の答えに置き換えてチャット欄に貼り付ける。

Antigravity CLI(agy)ユーザーも同じ4ステップの構造で演習できる。ただしサブエージェント定義は.claude/agents/ではなくAGENTS.mdに記述し、Claudeのagentツールの代わりに/goalコマンドで役割ごとの作業を割り当てればよい。

[役割名]という名前のサブエージェントを.claude/agents/[役割名].mdに作って。
[このエージェントが行うことを一文で]。toolsは[ステップ2で決めた最小権限]のみを許可し、
modelは[第1章・第5章で学んだ基準で選んだティア]に設定して。

スペシャリストが二人以上いる場合は、D-1シナリオのようにそれぞれ作成した後、最後に「二つの段階を順番に進めて」または「同時に進めて」のようにオーケストレーション方式を明示的に指示する。どちらを選んだか、そして第1章§4bで学んだように、この選択がリクエストの依存関係によって変わることを自分で確認する。

ステップ4 — 検証と振り返り

実際に一度実行してみた後、以下の質問に答えてみる。

結果は期待した形式(ハンドオフ契約)どおりに出てきたか? そうでなければ、サブエージェントのdescriptionが曖昧だったのではないか?
ステップ2で決めたガードレールは実際に守られたか? もしかしてtoolsを必要以上に広く与えた箇所はないか?
このワークフローを定期的に繰り返す必要があるなら、第11章で学んだように、後でvariantや再利用可能なスキルに昇格させる価値があるか?

この振り返りまで終えれば、このハンドブックが最初から強調してきた循環(概念(第2章)→安全装置(第3章)→ツール(第4章)→組織・構造(第5章・第7章・第8章))を一人で一巡させたことになる。次に似たような繰り返し作業に出会ったときは、今回投げかけた質問を順番に再び投げかけるだけで、新しいワークフローを設計できる。

完了チェックリスト

セルフチェック

☐ 繰り返し作業を一つ問題として定義した

☐ 単一エージェントのどんな限界のためにチームが必要かを説明できる

☐ サブエージェントを作る前に権限と承認ゲートを先に決めた

☐ 実際にサブエージェントを作り、最低一度実行した

☐ 結果を検証し、何が予想と違ったかを書き出してみた

再現性検証

☐ 同一のリクエストを2回以上実行し、結果が一貫していることを確認した

☐ 異常な入力(空ファイル、誤った形式など)を与えたときにガードレールが機能するか確認した

☐ 実行前後のスナップショットを比較し、予期しないファイル変更がないことを確認した

修了後の次のステップ

このハンドブックはここで終わるが、実際の適用はこれからが本番である。今日設計したワークフローを実際の業務に適用してみると、次の3つの方向のいずれかへ自然につながっていく。

今週中に

☐ 今日作ったサブエージェントを実際の繰り返し業務にもう一度実行し、今回は結果を同僚と共有する

☐ このワークフローが組織内の他のチームにも役立つか、一人に聞いてみる

このワークフローが定着したら

☐ 第10章・第12章で扱った昇格手続きに従い、正式なvariantにすることを検討する — チーム全体が再利用できるようになる

☐ 第8章§5のL3プロジェクトアップグレード手続きを身につけておくと、以後共通標準が変わるたびに毎回手作業で反映しなくて済む

行き詰まったら

☐ 用語集で再登場した概念を調べてみる

☐ FAQで似たような症状を経験した事例がないか確認する

最も重要なのは「正解を暗記すること」ではなく、新しい繰り返し作業に出会うたびに、このハンドブックが示した順序 — 問題定義 → 限界の確認 → 権限設計 → 実装 → 検証 — を自分自身で改めて踏めるようになることである。