この記事の概要（2026年6月）: Claude Codeに「仕組み」を渡すための部品論をまとめたZenn Book Vol.4「コードを書けない私がClaude Codeに『仕組み』を渡すまで」を紹介する。「CLAUDE.mdに書いたのに守られない」「サブエージェントに指示を渡したのに動かない」というモヤモヤの正体を、Claude Codeが自分で動けるようになるための7つのレイヤー（CLAUDE.md／サブエージェント／スキル／Playbook／メモリ／設定・権限／MCP）として一章ずつ解剖した本だ。本書を貫く問いは「何を渡すか」と同時に「何を渡さないか」——渡しすぎないこと。価格900円、序章は無料公開。Vol.1〜3に続くシリーズ第4巻だが、単体で完結するように書かれている。
CLAUDE.mdに「書いたのに、守られない」——そのモヤモヤの正体
これは、コードを書けるかどうかの話ではない。Claude Codeに「何を、どこに、どう渡すか」という設計の話だ。だから普段コードを書かない人にも、書く人にも、同じように当てはまる。
Claude Codeを使い込んでいると、ある種の手詰まりにぶつかる。
CLAUDE.mdにルールを書いた。「日本語で応答すること」「コミット前にブランチを確認すること」——書けばセッションの最初に必ず読まれるのだから、その通りに動いてくれるはずだ。なのに、守られないことがある。サブエージェントに役割を渡して指示を出したのに、思ったように動かない。スキルやPlaybookを作り始めたが、どこまで書けばいいのか、判断の軸がない。
「書いたのに、効いている気がしない」。この感覚に、心当たりはないだろうか。
私自身、最初はこう思っていた。CLAUDE.mdは最初に読まれるファイルなのだから、書けば書くほど安全になるはずだ、と。これが半分は当たっていて、半分は外れていた。
外れていた半分の正体は——「渡す場所」の設計にある。
ルールが守られないのは、ルールの中身が悪いからとは限らない。「どこに、どんな形で渡すか」がずれていると、書いたものは読まれなかったり、読まれても効かなかったりする。CLAUDE.mdは「ルールを書けば効く場所」ではなく、「ルールが読まれる仕組みを設計する場所」だった。そして、これはCLAUDE.mdだけの話ではない。サブエージェントにも、スキルにも、Playbookにも、それぞれ固有の「渡し方の設計」がある。
Zenn Book Vol.4「コードを書けない私がClaude Codeに『仕組み』を渡すまで」は、この「渡す場所」を7つのレイヤーに分けて、一つずつ解剖した本だ。
Claude Codeに渡せる場所は7つに分かれている——本書の地図
「もっとうまく仕込めるはず」という感覚があっても、闇雲に何かを書き足せばいいわけではない。Claude Codeに「渡せる場所」は、構造的にいくつかのレイヤーに分かれている。本書はそのレイヤーを章の軸に据えている。
最初に断っておくと、7つすべてを一度に押さえる必要はない。章の重さは均等ではないし、あなたの今の関心に合わせて1〜2レイヤーから入れるように書かれている。地図はこうだ。
| レイヤー | 章 | 何を渡すか | 渡しすぎると何が起きるか |
|---|---|---|---|
| CLAUDE.md | 第1章 | 行動規範とトリガー条件 | 書きすぎるとAIが読まなくなる |
| サブエージェント | 第2章 | 役割という「読む目的のレンズ」 | 分けすぎると「誰に頼むか」の判断コストが増える |
| スキル | 第3章 | 実行手順・再現手順 | 「あとで使うかも」で作ったスキルが積み上がる |
| Playbook | 第4章 | 判断の地図（どこで分岐するか） | 古くなっても気づかれず、誤判断の根拠になる |
| メモリ | 第5章 | 「次に同じ失敗をしない」記憶 | 溜めすぎるとコンテキストを圧迫する |
| 設定・権限 | 第6章 | 許可範囲と境界線 | 「とりあえず全部許可」が事故の入口になる |
| MCP | 第7章 | 外部ツールへの接続能力 | 繋ぎすぎるとツール定義がコンテキストを食う |
この7つは、性質によって2種類に分かれる。
最初の6つ（CLAUDE.md〜設定・権限）は、自分で設計して作っていくものだ。上から順に積み上げていくイメージで並んでいる。CLAUDE.mdで土台のルールを渡し、サブエージェントで役割を分け、スキルで手順を畳み込み、Playbookで判断の地図を描き、メモリで失敗の記憶を蓄え、設定・権限で境界線を引く。
7つめのMCP（Model Context Protocol：外部ツールにClaude Codeを接続する仕組み）だけは性質が違う。これは自分で書いて設計するものではなく、既にあるものから選んで繋げるものだ。1〜6が「どう設計するか」を問うのに対し、MCPは「どう選ぶか」を問う。だから本書では別枠として扱っている。
右端の「渡しすぎると何が起きるか」の列に注目してほしい。本書がただの機能カタログと違うのは、この列があることだ。
本書を貫く問い——「渡しすぎない」という引き算
本書には、7つの章すべてを貫く一つの問いがある。
「何を渡すか」と同時に「何を渡さないか」——渡しすぎないこと、である。
仕組みを渡す本でありながら、本書はずっと引き算の話をしている。各レイヤーで、著者は同じ問いを繰り返す。何を渡し、何を渡さないか。どこまで渡すか。そして、渡しすぎたときに何が起きるか。エピローグでは、この問いがこう一本に束ねられる——「削る設計こそが、渡す設計だった」と。
なぜ引き算が要るのか。本書で扱う7レイヤーの設計は、抽象論から導いたものではない。90個のPlaybookと21件の事故記録から抽出した、実運用の産物だ（本書執筆時点の実測値）。数字が示すとおり、泥臭い経験の積み重ねから出てきている。
そのうち2つだけ、本書で実際に解剖されている例を挙げておく。
一つは、設定・権限を渡しすぎた事故だ。2026年4月、Zennへの自動同期を制御するフラグを、事前確認なしにデフォルトで有効へ切り替えてしまった。結果として、Zenn記事5本が一時的に非公開状態になった。「とりあえず許可しておけば便利だろう」という発想が、そのまま事故の入口になった例である。
もう一つは、スキルを「渡したのに使われなかった」例だ。2026年5月、それまでに作ったスキルを棚卸しして、3本を退役と判定した。今の環境では動かないもの、制作意図が整理できなくなったもの——「あとで使うかもしれない」で増やした道具は、たいてい使われないまま積み上がる。
足せば足すほど良くなるわけではない。CLAUDE.mdは長くなるほどAIが読まなくなる。Playbookは古くなっても誰も気づかない。メモリは肥大化してコンテキストを圧迫する。どのレイヤーにも、渡しすぎたときに効率を下げる固有のメカニズムがある。本書はそれを章ごとに名指しし、同時に「どう削るか」をセットで示す。これが、本書を他の活用術本と分けている一点だ。
4部作が揃った——シリーズ全体の地図と本書の位置
2026年6月、これでシリーズが4巻になった。
- Vol.1「コードを書けない私がClaude Codeで『AIチーム』を作るまで」: エージェントチームを設計するまでの記録。役割定義ファイルの書き方、分業設計、最初のチームを立ち上げるまでの試行錯誤
- Vol.2「コードを書けない私がClaude Codeで『AIチーム』を回すまで」: 「作った翌朝」から始まる記録。Playbook設計、三層品質ゲート、実際に起きた事故の詳細
- Vol.3「コードを書けない私がClaude Codeで『AIチーム』と書き続けるまで」: チームが回り始めた後の記録。「仕込む・書く・届ける・回収する」の4段ループ
- Vol.4「コードを書けない私がClaude Codeに『仕組み』を渡すまで」: チームを支えている「部品」そのものの解剖書
前3作との関係を一言で言うと、Vol.1〜3が物語と装置設計の記録だったのに対し、Vol.4は部品そのものの解剖書だ。Vol.1〜3で「AIチームを作り、回し、書き続ける」という物語が進んだ。その物語を裏側で支えていた部品——CLAUDE.md、サブエージェント、スキル、Playbook、メモリ、設定・権限、MCP——を一つずつ取り出して断面を見せるのが、Vol.4にあたる。
Vol.4から読み始めることは可能か？
可能だ。本書は単体で完結するように書かれていて、前巻への参照は各章でも最小限にとどめられている。Vol.1〜3を読んでいなくても、7つのレイヤーの解剖はそのまま読み進められる。「そもそもAIチームをどう作るのか」から知りたい場合はVol.1から読むと土台が固まるが、「Claude Codeの仕組みをどう設計するか」だけが知りたいなら、Vol.4単体で目的を果たせる。
なお、本書は「部品が何か」までで完結する。その部品を使って実際にどう日々の仕事を進めるか——日々の仕事をClaudeに任せていく体験——は、続くVol.5へ送られる予定だ。ただし本書を読み終えたあと、Vol.5を待つ必要はない。むしろ待たずに、自分の手で組み合わせを試してほしい、というのが本書のスタンスだ。
Zenn Book Vol.4はどんな人に向いているか
本書が向いている人
- Claude Codeを使い込んでいるが「もっとうまく仕込めるはず」と感じている方
- CLAUDE.mdを書いたが「効いているかどうかわからない」という方
- スキル・Playbookを作り始めたが、設計の判断軸がない方
- AIチームの運用を支える「部品」の設計思想を体系的に押さえたい方
向いていない人
- Claude Codeの実装テクニック・コードの書き方を求めている方（本書はノンプログラマー視点で、コードの書き方そのものは扱わない）
- 設定ファイルのサンプル集・コピペで使えるテンプレート集を期待している方（本書はCLAUDE.mdの全文転載などはせず、「なぜその形になったのか」という設計判断に焦点を当てている）
2点目を補足しておく。本書はあえて設定ファイルの全文を貼らない。それをやると「設定ファイルのサンプル集」に見えてしまい、読者が自分のプロジェクトに持ち帰れる部分が減るからだ。代わりに、構造——なぜ3層に分けるのか、なぜトリガーを表形式にするのか、なぜ役割別に分離するのか——という設計判断のほうに紙幅を割いている。
価格と無料公開範囲——序章を読んでから判断してください
価格: 900円（序章「何を渡す本なのか」は無料公開）
序章には、本書の核となる「装備の付与と業務の肩代わりは別物」という出発点、7レイヤーの全体地図、そして「渡しすぎない」という本書を貫く問いの予告が収まっています。購入前に序章を読んで、自分に必要な本かどうかを確認してください。
Vol.4 序章（無料）・購入はこちら
コードを書けない私がClaude Codeに「仕組み」を渡すまで
※本書の内容を実践するには、Anthropicの有料プラン（月額$20〜）の契約が必要です。
Vol.1・Vol.2・Vol.3はこちら
- Vol.1「作るまで」: https://zenn.dev/tottoko_hamu/books/leading-ai-agents-without-code（900円、序章+第1部は無料公開）
- Vol.2「回すまで」: https://zenn.dev/tottoko_hamu/books/operating-ai-team-without-code（900円、序章は無料公開）
- Vol.3「書き続けるまで」: https://zenn.dev/tottoko_hamu/books/writing-with-ai-team-without-code（900円、序章は無料公開）
Zennフォロー: 新刊・更新通知を受け取りたい方は、Zennで私（@tottoko_hamu）をフォローしてください。
ブログ購読: このブログ（blog.saitoko.net）の読者登録をしていただくと、新刊・新記事をお知らせします。
CLAUDE.mdを一行だけ直す——仕組みを渡す最初の一手
本書を読み終えたあと、最初にやってほしい一手がある。
自分のCLAUDE.mdを開いて、一行だけ直してみることだ。一行足すのでも、一行削るのでもいい。「書いたのに守られない」というモヤモヤの出口は、ルールを大量に書き足すことではなく、「何をどこに、どう渡すか」を一つずつ設計し直すところにある。その最初の一歩が、一行を直すことだ。
その一手が、仕組みを渡すという作業の始まりになる。
著者: saitoko / ブログ「コードを書かないSE日誌」(blog.saitoko.net) / Zenn: @tottoko_hamu
この記事は はてなブログ からのクロスポストです。