この記事の概要（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

この記事ははてなブログからのクロスポストです。