概念を知らずに、
同じ構造を自力で構築していた
2026/3/29
「それ、名前がついてますよ」
Claude CodeにSkills/Subagentsという機能があることは、知っていた。
ただ、「エージェントに付随する何かだろう」という程度の理解だった。最近よく名前を見かけるようになってきたな、いずれ着手しよう——そう思ったまま、深く調べていなかった。
プランナーエージェントを設計し終えた後、ようやくその解説記事をちゃんと読んだ。Skillsとは必要なときだけ呼び出される知識の外部化。Subagentsとは独立した責務を持つ実行単位。そしてその組み合わせが、エージェントの精度と制御性を両立させる——という内容だった。
読みながら、少し止まった。
これ、自分がさっき作ったやつだ。「それ、名前がついてますよ」って記事に言われた気がした。
私が半日かけて作ったもの
プランナーエージェントの設計に、半日かかった。
作り始めてから最初の1時間は「そもそも作る必要があるか」の検討に使った。ManusやOpenClawのような汎用エージェントツールはすでにある。調べた結果、「それCoworkでいいんじゃない？」というものがほとんどだった。私がやろうとしているのはエージェントを「動かすこと」ではなく、自分の開発フローと判断基準を持った固有の役割を編制することだ——そう確認してから、自作することにした。
設計中に決めたルールを一部だけ書き出す。
- 「完了かどうかの判断はしない。ログの記載をそのまま反映する」——書かなければ、エージェントが自己判断で完了扱いにする
- 「不明な場合はNAと記入する、仮の数字は入れない」——書かなければ、適当な数字が入る
- 「外部依存ブロッカーの解除確認は保守エージェントが担当。プランナーは保留のまま追跡しない」——責務の境界を書かなければ、越えてくる
- 「ドライラン（計画だけ出せ）→確認→このまま実行せよ、という流れを定型とする」——実行前に確認する構造を、フォーマット自体に埋め込む
できあがったファイルは合計551行・約2万文字だった。エージェントへの命令は116行で、残りは設計判断と学びの記録だ。「動かす」指示より、「思い通りに動かすための設計判断」の方がはるかに多い。
既存概念と並べると、ほぼ同じだった
翌日に読んだSkills/Subagentsの記事と、自分が作ったものを並べてみた。
| 私が設計したもの | 対応する概念 |
|---|---|
| プランナー・実装者・監査役の三権分立 | Multi-Agent Orchestration / Subagents |
| 責務の境界を明示し、越境を禁止する | Separation of Concerns |
| ドライラン→承認→実行の分岐構造 | Dry-run pattern |
| ルールより構造でコンフリクトを消す | Data-Driven Design |
名前がついていた。
「知らなかったこと」は失敗だったのか
ここで正直に書いておく必要がある。
Skills/Subagentsは、ファイルを1枚置けば動く。.claude/agents/ にMarkdownを置いて、名前と役割を書けばそれがsubagentになる。入口だけ見れば、難しくない。
ただ、「動く」と「思い通りに動く」は全然別の話だ——これは前回の記事で書いた通りだ。
私が半日かけてやったのは、ファイルを置くことではない。「完了の定義とは何か」「ドライランと実行をどう分けるか」「責務の境界はどこに引くか」を、自分の文脈で一つひとつ考え、言語化することだった。その積み上げが551行・2万文字になった。
だから問いを立て直す。「概念を先に知っていれば早かったか」。
正直に言う。早かったと思う。
「愚者は経験に学び、賢者は歴史に学ぶ」という言葉がある。自分が好きな言葉だ。他人の失敗や先人の知恵から学べる人間の方が、自分で痛い目を見ないと動けない人間より賢い——という意味だ。
その基準で言えば、今回の自分は愚者の側だった。Skills/Subagentsという概念がすでにあった。設計の先人がいた。それを「いずれ着手しよう」と後回しにして、自力で同じ構造を発明した。半日を使って。
ただ一つだけ言い訳をするなら——「思い通りに動くすための設計判断は、概念を知っていても自分で積み上げるしかない部分だ。入口を早く知れた分、その先に早く進めた、というだけの話だったかもしれない。
それでも、先に知っておくべきだった。
PMの経験が、言語より先に構造を作った
コードが書けないと、構造で考えるしかない。
私のPM10年の仕事は、要件定義・ステークホルダー間の責務の明示・意思決定の言語化・「完了」の定義の合意——まさにこれだった。エージェント設計でやっていることと、構造が同じだ。
「完了かどうかの判断はしない。ログの記載をそのまま反映する」——これは、プロジェクト管理で「進捗は担当者の主観でなく、定義された状態で確認する」と言い続けてきたことと同じだ。
「責務の境界を書かなければ、越えてくる」——組織でも、AIでも、境界を明文化しなければ人（エージェント）は善意で越境する。
非エンジニアがAIエージェントを設計できるとしたら、それはコードを書けるからではない。構造を言語化できるからだ。PMの仕事はそのための訓練だった、と今になって思う。
思考の精度が問われる、という話の続き
前回の記事で書いた。「AIが賢くなるほど、人間側に求められるのは技術ではなく、思考の精度だ」と。
今回のエピソードは、その続きだ。
概念を知らずに同じ構造を発明できたのは、ラッキーではない。自分の問題として構造を考え続けた結果だ。逆に言えば、概念の名前を先に覚えても、自分の問題として考えていなければ、形だけの実装になる。
AIエージェントの文脈でも、PMの文脈でも、構造を考える力は同じところから来る。
「何を作りたいか」「何をやらせないか」「判断が割れたときどうするか」——これを自分の言葉で答えられるかどうかだ。
概念の名前は、後からついてくる。
プランナーエージェントを設計してから1週間が経った。実際に使い続けてみてどうだったか——その話は近いうちに書く予定だ。