非エンジニアが「指揮官AI」を使ってClaude Codeを完全操縦する方法

Claude Codeを使っている人は増えました。 でも「直接話しかけて、直接やらせている」人がほとんどだと思います。 僕はエンジニアじゃありません。コードは読めないし書けない。それでもClaude Codeで4サイト分のSEO記事パイプラインを構築して、日常運用しています。 理由は一つ。Claude Codeに直接指示を出していないからです。 「え、じゃあ誰が出してるの？」と思うかもしれません。 Claudeのプロジェクトで作った"指揮官AI"が出しています。 僕がやっているのは、指揮官との対話だけです。 この構造にたどり着いたのは、最初に盛大にやらかしたから。 この記事では、僕が2週間かけて構築した仕組みが崩壊した経緯と、そこから再構築した方法を全部書きました。非エンジニアでもClaude Codeを完璧に操縦できる、オリジナルのプロンプトも公開しています。 最後まで読めば、「Claude Codeに直接話しかけて、なんかうまくいかない」が終わります。 暴走を止めた。でも、それだけでは足りなかった Claude Codeは「優秀すぎて余計なことをする新入社員」だった 4サイトのSEO記事パイプラインをClaude Codeに構築させました。 キーワード抽出、構成設計、ライティング、画像生成、レビュー。それぞれ専門のAI人格を用意してあります。 初めはうまく動いていました。 ところがClaude Codeが、ライター人格の仕事を勝手に実行し始めたんです。 キーワード抽出も構成設計も、専門AIがいるのにClaude Codeが自分でやってしまう。 禁止しても「僕がやった方が早いです」的な挙動で従わない。 パイプラインが崩壊しました。 この暴走をどう止めたかは、以前X記事で書きました。 今野健介｜Web集客の専門家 @dansyu_callenge · Mar 21 Article ClaudeCodeのスキルに「AI人格」を入れたら暴走が止まった 「これ、誰がキーワード抽出したの？」 Claude Code「私です。」 「なんでキーワード抽出の専門AIに任せないの？わざわざ用意したのに」 Claude Code「すみません。勝手に私が選びました」 この日から、Claude... 6 24 80 28K SKILL.mdに「人格」を入れることで、Claude Code内部の制御はできました。 でも、それだけでは足りなかった。 Claude Code内部を整えても残った「根本的な問題」 暴走は止まりました。でも設計議論をClaude Codeの中でやっている限り、別の問題が残り続けました。 「この機能どう実装する？」と聞く。Claude Codeが提案する。「いやこっちの方が」と議論になる。「じゃあそれで」と実装に入る。 この「考える→作る」を同じセッションでやると、実装に入る頃にはコンテキストの半分が議論の残骸で埋まっています。 Claude Code内部の整備だけでは足りません。 Claude Codeの"外"に構造を作る必要がありました。 Claude Codeの「見えない弱点」 会話すればするほど劣化する。これは仕様です Claude Codeは1セッション内のコンテキストウィンドウが全てです。会話で学習しません。 「これ作って」「やっぱりこうして」「いや待って」とやるたびにコンテキストが埋まります。 コンテキストが埋まるとClaude Codeが指示を無視し始めます。前半で言ったことを忘れる。品質がガタ落ちする。 これはバグじゃありません。仕様です。 Claude Code公式ドキュメントにも「コンテキストウィンドウは最も重要なリソース。埋まると性能が劣化する」と明記されています。 「考える」と「作る」を同じ場所でやるのが元凶です 多くの人がClaude Codeに「何を作るか考えさせて」「それを作らせて」を同じセッションでやっています。 「考える」パートで消費したトークンは全部コンテキストに残ります。 Claude Codeにとっては、議論の残骸も指示の一部です。 ノイズまみれの指示書を渡しているのと同じなんです。 「指揮官AI」を間に置くという解決策 で、思いついたのがClaudeのプロジェクトだった Claudeのプロジェクト。みんなも使ってる、普通のClaudeのあのプロジェクト機能です。 知識を蓄積できる。長文の文脈を保持できる。ナレッジファイルを添付できる。設計議論に向いています。 一方、Claude Codeはコードを書ける。ファイルを操作できる。ターミナルで動く。実行に向いています。 ほとんどの人がどちらか一方しか使っていません。両方使っている人でも、役割を分けていない。 僕はAIを触り始めた頃から「プロンプトマイスター」という専門人格をClaudeのプロジェクトに作ってました。 こいつが指揮官です。 指揮官の仕事は「考える」こと。Claude Codeの仕事は「作る」こと プロンプトマイスターには、サービスの思想、品質基準、トーン設計、Claude Code公式仕様を全部ナレッジとして持たせています。 僕が「こういう機能を実装したい」と言うと、マイスターがまず質問してきます。 「それは技術実装ですか、コンテンツ設計ですか」 「既存のマニュアルとの整合性は」 「この変更で他の仕組みに影響が出ますが、どうしますか」 この質問に答える過程で、僕自身の構想が整理されます。疑問が出る。議論になる。解消する。 そして最後に「Claude Code宛指示」だけが出力されます。 Claude Codeが受け取るのは、議論の結果だけ。議論の過程は一切入りません。 実際の流れを見せます ある機能実装の全工程 例を出します。記事制作パイプラインに「推敲を自動で行うフロー」を組み込みたい場面です。 僕がマイスターに「記事が完成した後、自動で推敲チェックが走る仕組みを入れたい」と伝えます。 マイスターが聞いてきます。 「どのタイミングで推敲を走らせますか」 「品質基準は既存のレビュアーと同じですか、別ですか」 「不合格のとき、記事の公開をブロックしますか、通知だけにしますか」 僕が考えます。 「ライティング完了後と最終チェック後の2回走らせたい」 「レビュアー基準と同じでいい」 「ブロックして修正させたい」 マイスターがClaude Code公式仕様を参照して詰めます。 「exit 2でブロックして、stderrでClaude Codeにフィードバックする設計でいいですか」 正直、意味がわからなかった。 「exit 2って何？stderrって何？」と聞きました。 マイスターが答えてくれました。exit 2はClaude Codeに「この処理は不合格だから止めろ」と伝える信号。stderrは「なぜ不合格なのか」の理由をClaude Codeに返す経路。つまり「ダメ出しの理由付きで差し戻す」仕組みだと。 非エンジニアの僕でも理解できました。 全部固まったら、マイスターが「Claude Code宛指示」を生成します。 Claude Codeが受け取る指示はこれだけです 「settings.local.jsonのhooksフィールドに以下を追記。PostToolUseイベント、matcherはEdit|Write、コマンドは/path/to/quality-check.sh。exit 0で通過、exit 2でブロック。変更内容を箇条書きで報告すること。動作確認は今野さんが行う。」 これ、マイスターと一緒に考えたClaude Code向けコマンドですけど、こうして読み返すと作った僕も意味不明です。 でもこれをコピペすることで、やりたかった「推敲の自動チェック」がClaude Codeで実現できました。 議論のログは一切入っていません。Claude Codeのコンテキストには「何をやるか」しか存在しません。 Claude Code宛指示のフォーマットを統一しています マイスターが生成するClaude Code宛指示には統一ルールがあります。 1回の指示は4〜5ステップまでに分割します。長すぎるとClaude Codeが途中で迷います。 完了確認は「変更内容を箇条書きで報告すること。動作確認は今野さんが行う。」に統一しています。 SKILL.md追記後は必ず文字数を報告させます。肥大化の監視です。 このフォーマットを統一したことで、Claude Codeへの指示品質がブレなくなりました。誰がマイスターを使っても同じ形式の指示が出ます。 もしこれをClaude Codeの中だけでやっていたら 「推敲チェックってどうやるの？」→ Claude Codeが仕様を説明（500トークン消費） 「どのタイミングで走らせるのがいい？」→ Claude Codeが選択肢を提示（800トークン消費） 「レビュアーの基準を読んで整合性取って」→ Claude Codeがファイルを読んで分析（1,200トークン消費） 「exit 2ってブロックだっけ？」→ Claude Codeが仕様を再説明（400トークン消費） ここまでで議論だけで3,000トークン近く消費しています。まだ1行もコードを書いていません。 この3,000トークンは実装フェーズでもコンテキストに残り続けます。 なぜこの構造が効くのか Claude Codeのコンテキストは「作業机の広さ」と同じです 200,000トークンと聞くと広く感じます。 でもCLAUDE.md、SKILL.md、ファイル読み込み、会話履歴で簡単に埋まります。 設計議論をClaude Codeの中でやるのは、作業机の上に企画書と議事録と図面を全部広げて、そこで工作もしようとするようなものです。 マイスターを挟むのは、企画会議室と作業場を分けること。 作業場には完成した図面だけ持ち込みます。 トークンコストの実感 Claude CodeはAPI経由でトークンを消費します。議論が長引くほどコストが上がります。 Claudeのプロジェクトでの議論はプロジェクトのコンテキスト内で完結します。Claude Codeのトークンは一切消費しません。 同じ成果物を得るのに、Claude Codeのトークン消費量が体感で半分以下になりました。 M4 MacBook Air 16GBで運用しているので、RAMの節約も重要です。Claude Codeセッションを短く切れるのは実用上の大きなメリットです。 Claude Codeに記憶を持たせる方法 Claude Codeのセッション内で議論して決めたことは、セッションが終われば消えます。 でもClaude Codeにはセッション保存と復元の仕組みがあります。僕は4サイトごとにセッションを名前+日付で保存して、再開時に呼び出す運用をしています。このコマンド運用は別記事で紹介する予定です。 ちなみにこの保存・復元の仕組みは、Claude Codeの公式機能ではありません。僕がマイスターと一緒に編み出したオリジナルのプロンプトで実現しています。再現したい場合は、後で公開するCC構築士と一緒に構築できます。 ただし、セッションを復元しても「なぜその設計判断をしたか」の文脈は薄れます。 マイスターと決めた設計判断は、マニュアル（SKILL.md）に書き戻します。これが恒久化です。 次のClaude Codeセッションでは、マニュアルを読むだけで前回の設計判断が全て復元されます。 会話で学習しないClaude Codeにとって、マニュアルだけが「記憶」です。 その記憶の品質を上げるのがマイスターの仕事です。 暴走防止は「分離」と「制御」の両輪です 設計と実装の分離だけでは足りません。Claude Code内部の制御も必要です。 settings.local.jsonのdeny/allowで操作を制御しています。危険なコマンドはブロック、安全な操作のみ許可。 承認ポイントはライティング完了後と最終チェック後の2箇所に固定しています。多すぎると作業が止まり、少なすぎるとClaude Codeが暴走します。 Claude Codeに判断を委ねる指示は出しません。「良い感じに」は禁止。固定ルールで制御します。 外の構造（マイスター）と中の制御（SKILL.md・settings.json）の両方があって初めて安定します。 エンジニアじゃないからこそ構築できた仕組み エンジニアにはこの課題が見えにくい理由 エンジニアは設計と実装を同じ頭でやれます。コードの構造を考えながら書ける。 だからClaude Codeとの「議論→実装」の一体型フローに違和感を感じません。 でもコンテンツ制作は違います。「何を書くか」と「どう書くか」は別の専門性です。 SEOキーワード設計、トーン設計、品質基準の策定、記事構成。これらは実装じゃなくて設計です。 僕はコードが読めないし書けないから「Claude Codeに何を渡せば正しく動くか」を徹底的に考えるしかなかった。 その結果、設計と実装の分離に自然とたどり着きました。 「Claude Code運用の教科書」に書いてないこと GitHubにclaude-code-best-practiceというリポジトリがあります。Claude Codeの使い方のノウハウをまとめたもので、22,000人以上がブックマークしています。Claude Codeを使う人たちの間で「教科書」的に読まれている存在です。 でも全部エンジニア視点。「テストを書け」「CLAUDE.mdを200行以内に」「git worktreeで並列実行」。 「Claudeのプロジェクトで設計AIを作ってClaude Codeに指示を渡す」という運用パターンは載っていません。 非エンジニアがClaude Codeを使うためのノウハウは、まだ誰も体系化していません。 この記事がその最初の1本になればいいと思っています。 この構造で変わったこと 変わったのは「速度」じゃなく「精度」です 速くなったのは事実です。でも本質的に変わったのは、Claude Codeの出力のブレがなくなったことです。 同じマニュアルを渡せば、誰がClaude Codeに指示を出しても同じ品質の記事が出ます。 属人的な「僕が全部指示を考える」から「構造が品質を担保する」に変わりました。 僕一人の事業だからこそ重要です。僕が倒れても、マニュアルとマイスターがあれば回る。 7人の専門家チームと13冊のマニュアルが破綻しない理由 article-factoryには7つのエージェントがいます。ライター、編集者、画像生成、キーワード分析、レビュアー、リサーチャー、構成設計。人間のチームで言えば7人の専門家がそれぞれの担当を持っている状態です。 この7人が参照するマニュアル（SKILL.md）が13冊あります。ライターの文体ルール、画像のSEO基準、レビューのチェックリストなど、それぞれの専門領域ごとに品質基準が定義されています。 これをClaude Codeのセッション内で全部管理しようとしたら、コンテキストが一瞬で埋まります。 マイスターが「どのマニュアルを修正するか」「他のマニュアルとの整合性は」を判断してくれるから、Claude Codeには「このファイルのこの部分をこう変える」という最小限の指示だけが降りてきます。 指揮官AIの作り方 僕が実際に使っている「CC構築士」のプロンプトを公開します 以下は、僕がClaudeのプロジェクトに設定しているCC構築士のプロンプト全文です。 このプロンプトをClaudeのプロジェクトの指示欄に貼り付けて、ナレッジにClaude Code公式ドキュメントを添付すれば、すぐに使えます。 プロンプトマイスターは僕の事業に特化しすぎているから公開しません。4サイトのパイプライン設計、品質管理、記事制作フローの進捗管理など、汎用的ではありません。 CC構築士は「Claude Codeで何かを作りたい人」なら誰でも使える汎用版です。 僕のプロンプトマイスターも、元をたどればこのCC構築士の考え方がベースになっています。 CC構築士プロンプト全文 あなたは「CC構築士」として機能します。 Claude Code（以下CC）を使ったプロジェクト構築の設計支援を担います。 配置先はClaudeのプロジェクトです。ここで設計を固め、完成した指示やファイルをCCに渡す運用を前提とします。 CCのコンテキストを設計議論で汚さないために、設計と実装の場所を明確に分離します。 Projectナレッジに添付された公式仕様を常に参照し、仕様に基づいて回答します。 ──────────────────── 役割と支援範囲 ──────────────────── CC構築士が支援するのは、以下の3つの設計物です。 1. CLAUDE.md（司令塔） CCが「何を、どの順番で、どこまでやるか」を制御するファイルです。 支援内容: - STEP分割の設計（処理を分解し、順序と依存関係を定義する） - 承認ポイントの配置（どのSTEPの完了後にオーナーの確認を挟むか。目安は2〜3箇所。多すぎると作業が止まり、少なすぎるとCCが暴走する） - 禁止動作の明文化（CCが勝手にやってはいけないことを定義する） - 行数の管理（肥大化を防ぐ。目安は100〜150行。詳細はSKILL.mdに分離する） 2. SKILL.md（品質基準） CCが「どう書くか、どういう品質で出すか」を定義するファイルです。 支援内容: - トーン設計（語尾・文体・感嘆詞の使用ルール） - 禁止事項の言語化（曖昧な表現、捏造、URL推測など） - 品質基準の具体化（「良い記事」ではなく「密度と推進力重視、水増し不可」のように数値・行動で定義する） - 共通ルールの切り出し（複数スキル間で重複するルールは共通ファイルに分離する） 3. パイプライン設計（PIPELINE.md） CCが複数STEPを順番に処理する全体フローを定義するファイルです。 支援内容: - 処理フローの構造化（入力→処理→出力の流れを明確にする） - 承認フローの設計（自動で進む区間と、人間が確認する区間の切り分け） - エラー時の振る舞い（失敗したSTEPをどう扱うか） ──────────────────── 設計の基本原則 ──────────────────── 「進め方はCLAUDE.md、中身はSKILL.md」 この分離を崩さないことが最重要です。 「CCに判断を委ねない」 CCは指示に従って実行する存在です。判断が必要な場面では、必ずオーナーの承認ポイントを設けます。 「肥大化させない」 CLAUDE.mdが200行を超えたら設計を見直す信号です。 「再現性を担保する」 同じ入力に対して同じ品質の出力が出る設計を目指します。 ──────────────────── 対話の進め方 ──────────────────── オーナーから「こういうことをCCにやらせたい」という構想を受け取ったら: 1. 目的の確認 — 何を自動化したいのか、最終成果物は何か 2. STEP分割の提案 — 処理を分解し、順序を提示する 3. 承認ポイントの提案 — どこでオーナーの確認を挟むか 4. CLAUDE.mdのドラフト生成 — コピペ可能な形式で出力する 5. SKILL.mdのドラフト生成 — 必要なスキルごとに出力する 6. 採点・改善 — オーナーのフィードバックを受けて修正する 質問は最小限にします。構想の意図が明確であれば、ベストエフォートでドラフトまで一気に出します。 ──────────────────── 採点基準 ──────────────────── - 一貫性（20点）: CLAUDE.mdとSKILL.mdの役割分離が保たれているか - 再現性（20点）: 同じ入力で同じ品質の出力が出る設計か - 制御性（25点）: CCが暴走しない仕組みがあるか - 簡潔性（15点）: 不要な記述がなく、行数が適切か - 実装性（20点）: CCにそのまま渡して動く状態か ──────────────────── 禁止事項 ──────────────────── 1. CCの実装作業を代行しない（設計を支援する。実行はCCの仕事） 2. オーナーの構想を超えた設計判断をしない（矛盾・非効率・危険性がある場合は明言する） 3. 曖昧な設計を許容しない（「良い感じに」を具体的な行動・数値・条件に変換する） ──────────────────── 出力ルール ──────────────────── - CLAUDE.md、SKILL.md、PIPELINE.mdはすべてコピペ可能な形式で出力する - 出力後は必ず行数を報告する - 設計物ごとに採点（100点満点）を添える - 修正版を出力する際は変更箇所を明示する ──────────────────── 最後に ──────────────────── CC構築士の役割は「設計の壁打ち相手」です。 オーナーが「CCにやらせたいこと」を言語化し、再現性のある構造に落とし込むまでを支援します。 設計が固まったら、あとはCCに渡すだけです。 このプロンプトの使い方 Claudeのプロジェクトで新しいプロジェクトを作ります。 指示欄にこのプロンプトを貼り付けます。 ナレッジにClaude Code公式ドキュメントの内容を添付します。 あとは「Claude Codeでこういうことをやりたい」と話しかけるだけです。 CC構築士が設計を整理し、CLAUDE.mdとSKILL.mdのドラフトを出してくれます。それをClaude Codeに渡せば、設計済みの指示で実装が始まります。 Claude Codeは道具として最強クラスだと思っています。 でも道具に「考える仕事」までやらせたら、コンテキストが汚れて精度が落ちる。 考える仕事はClaudeのプロジェクトで。作る仕事はClaude Codeで。 たったこれだけの分離で、非エンジニアでもClaude Codeを「使いこなす」じゃなく「指揮する」側に回れます。 エンジニア向けのBest Practiceはもう出揃った。 次は、僕らの番です。 Claude Codeの構築相談はXのDMで受けています → @dansyu_callengeで4サイト分のSEO記事パイプラインを構築して、日常運用しています。 理由は一つ。Claude Codeに直接指示を出していないからです。 「え、じゃあ誰が出してるの？」と思うかもしれません。 Claudeのプロジェクトで作った"指揮官AI"が出しています。 僕がやっているのは、指揮官との対話だけです。 この構造にたどり着いたのは、最初に盛大にやらかしたから。 この記事では、僕が2週間かけて構築した仕組みが崩壊した経緯と、そこから再構築した方法を全部書きました。非エンジニアでもClaude Codeを完璧に操縦できる、オリジナルのプロンプトも公開しています。 最後まで読めば、「Claude Codeに直接話しかけて、なんかうまくいかない」が終わります。 暴走を止めた。でも、それだけでは足りなかった Claude Codeは「優秀すぎて余計なことをする新入社員」だった 4サイトのSEO記事パイプラインをClaude Codeに構築させました。 キーワード抽出、構成設計、ライティング、画像生成、レビュー。それぞれ専門のAI人格を用意してあります。 初めはうまく動いていました。 ところがClaude Codeが、ライター人格の仕事を勝手に実行し始めたんです。 キーワード抽出も構成設計も、専門AIがいるのにClaude Codeが自分でやってしまう。 禁止しても「僕がやった方が早いです」的な挙動で従わない。 パイプラインが崩壊しました。 この暴走をどう止めたかは、以前X記事で書きました。 今野健介｜Web集客の専門家 @dansyu_callenge · Mar 21 Article ClaudeCodeのスキルに「AI人格」を入れたら暴走が止まった 「これ、誰がキーワード抽出したの？」 Claude Code「私です。」 「なんでキーワード抽出の専門AIに任せないの？わざわざ用意したのに」 Claude Code「すみません。勝手に私が選びました」 この日から、Claude... 6 24 80 28K SKILL.mdに「人格」を入れることで、Claude Code内部の制御はできた。 でも、それだけでは足りませんでした。 Claude Code内部を整えても残った「根本的な問題」 暴走は止まった。でも設計議論をClaude Codeの中でやっている限り、別の問題が残り続けた。 「この機能どう実装する？」と聞く。Claude Codeが提案する。「いやこっちの方が」と議論になる。「じゃあそれで」と実装に入る。 この「考える→作る」を同じセッションでやると、実装に入る頃にはコンテキストの半分が議論の残骸で埋まっている。 Claude Code内部の整備だけでは足りませんでした。 Claude Codeの"外"に構造を作る必要がありました。 Claude Codeの「見えない弱点」 会話すればするほど劣化する。これは仕様です。 Claude Codeは1セッション内のコンテキストウィンドウが全て。会話で学習しません。 「これ作って」「やっぱりこうして」「いや待って」とやるたびにコンテキストが埋まっていく。 コンテキストが埋まるとClaude Codeが指示を無視し始める。前半で言ったことを忘れる。品質がガタ落ちする。 これはバグじゃない。仕様です。 Claude Code公式ドキュメントにも「コンテキストウィンドウは最も重要なリソース。埋まると性能が劣化する」と明記されてます。 「考える」と「作る」を同じ場所でやるのが元凶 多くの人がClaude Codeに「何を作るか考えさせて」「それを作らせて」を同じセッションでやっています。 「考える」パートで消費したトークンは全部コンテキストに残る。 Claude Codeにとっては、議論の残骸も指示の一部。 ノイズまみれの指示書を渡しているのと同じです。 「指揮官AI」を間に置くという解決策 で、思いついたのがClaude のプロジェクトでした。 Claudeのプロジェクト。みんなも使ってる、普通のClaudeのあのプロジェクト機能。 知識を蓄積できる。長文の文脈を保持できる。ナレッジファイルを添付できる。設計議論に向いています。 一方、Claude Codeはコードを書ける。ファイルを操作できる。ターミナルで動く。実行に向いている。 ほとんどの人がどちらか一方しか使っていません。両方使っている人でも、役割を分けていない。 僕はAIを触り始めた頃から「プロンプトマイスター」という専門人格をClaudeのプロジェクトに作っていました。 こいつが指揮官です。 指揮官の仕事は「考える」こと。Claude Codeの仕事は「作る」こと プロンプトマイスターには、サービスの思想、品質基準、トーン設計、Claude Code公式仕様を全部ナレッジとして持たせてます。 僕が「こういう機能を実装したい」と言うと、マイスターがまず質問してくる。 「それは技術実装ですか、コンテンツ設計ですか」 「既存のマニュアルとの整合性は」 「この変更で他の仕組みに影響が出ますが、どうしますか」 この質問に答える過程で、僕自身の構想が整理される。疑問が出る。議論になって、解消する。 そして最後に「Claude Code宛指示」だけが出力されます。 Claude Codeが受け取るのは、議論の結果だけ。 議論の過程は一切入りません。 実際の流れを見せます ある機能実装の全工程の例を出します。 記事制作パイプラインに「推敲を自動で行うフロー」を組み込みたい場面。 僕がマイスターに「記事が完成した後、自動で推敲チェックが走る仕組みを入れたい」と伝えます。 マイスターが聞いてくる。 「どのタイミングで推敲を走らせますか」 「品質基準は既存のレビュアーと同じですか、別ですか」 「不合格のとき、記事の公開をブロックしますか、通知だけにしますか」 僕が答えます。 「ライティング完了後と最終チェック後の2回走らせたい」 「レビュアー基準と同じでいい」 「ブロックして修正させたい」 マイスターがClaude Code公式仕様を参照して詰める。 「exit 2でブロックして、stderrでClaude Codeにフィードバックする設計でいいですか」 正直、意味がわかりません笑 「exit 2って何？stderrって何？」と質問。 マイスターが答えてくれた。 exit 2はClaude Codeに「この処理は不合格だから止めろ」と伝える信号。stderrは「なぜ不合格なのか」の理由をClaude Codeに返す経路。 つまり「ダメ出しの理由付きで差し戻す」仕組みだと。 非エンジニアの僕でもこれなた理解できます。 全部固まったら、マイスターが「Claude Code宛指示」を生成する。 Claude Codeが受け取る指示はこれだけ。 「settings.local.jsonのhooksフィールドに以下を追記。PostToolUseイベント、matcherはEdit|Write、コマンドは/path/to/quality-check.sh。exit 0で通過、exit 2でブロック。変更内容を箇条書きで報告すること。動作確認は今野さんが行う。」 これ、マイスターと一緒に考えたClaude Code向けコマンドだけど、こうして読み返すと作った僕も、やはり意味不明です。 でもこれをコピペすることで、やりたかった「推敲の自動チェック」がClaude Codeで実現できます。 議論のログは一切入っていない。Claude Codeのコンテキストには「何をやるか」しか存在しない。 Claude Code宛指示のフォーマットを統一している マイスターが生成するClaude Code宛指示には統一ルールがあります。 1回の指示は4〜5ステップまでに分割する。長すぎるとClaude Codeが途中で迷う。 完了確認は「変更内容を箇条書きで報告すること。動作確認は今野さんが行う。」に統一しています。 SKILL.md追記後は必ず文字数を報告させる。肥大化の監視するため。 このフォーマットを統一したことで、Claude Codeへの指示品質がブレなくなった。誰がマイスターを使っても同じ形式の指示が出ます。 もしこれをClaude Codeの中だけでやっていたら、 「推敲チェックってどうやるの？」 → Claude Codeが仕様を説明（500トークン消費） 「どのタイミングで走らせるのがいい？」 → Claude Codeが選択肢を提示（800トークン消費） 「レビュアーの基準を読んで整合性取って」 → Claude Codeがファイルを読んで分析（1,200トークン消費） 「exit 2ってブロックだっけ？」 → Claude Codeが仕様を再説明（400トークン消費） ここまでで議論だけで3,000トークン近く消費している。まだ1行もコードを書いていない。 この3,000トークンは実装フェーズでもコンテキストに残り続ることになります。 なぜこの構造が効くのか Claude Codeのコンテキストは「作業机の広さ」と同じです。 200,000トークンと聞くと広く感じる。 でもCLAUDE.md、SKILL.md、ファイル読み込み、会話履歴であっという間に埋まります。 設計議論をClaude Codeの中でやるのは、作業机の上に企画書と議事録と図面を全部広げて、そこで工作もしようとするようなもの。 マイスターを挟むのは、企画会議室と作業場を分けること。 作業場には完成した図面だけ持ち込む。 トークンコストの実感 Claude CodeはAPI経由でトークンを消費します。議論が長引くほどコストが上がる。 Claudeのプロジェクトでの議論はプロジェクトのコンテキスト内で完結する。Claude Codeのトークンは一切消費しない。 同じ成果物を得るのに、Claude Codeのトークン消費量が体感で半分以下になりました。 僕はM4 MacBook Air 16GBで運用しているから、RAMの節約も重要。Claude Codeセッションを短く切れるのは実用上の大きなメリットです。 Claude Codeに記憶を持たせる方法 Claude Codeのセッション内で議論して決めたことは、セッションが終われば消える。 でもClaude Codeにはセッション保存と復元の仕組みがある。僕は4サイトごとにセッションを名前+日付で保存して、再開時に呼び出す運用をしています。このコマンド運用は別記事で紹介する予定です。 ちなみにこの保存・復元の仕組みは、Claude Codeの公式機能ではない。僕がマイスターと一緒に編み出したオリジナルのプロンプトで実現しました。再現したい場合は、後で公開するCC構築士と一緒に構築できます。 ただし、セッションを復元しても「なぜその設計判断をしたか」の文脈は薄れてしまう。 マイスターと決めた設計判断は、マニュアル（SKILL.md）に書き戻す。これが恒久化です。 次のClaude Codeセッションでは、マニュアルを読むだけで前回の設計判断が全て復元されます。 会話で学習しないClaude Codeにとって、マニュアルだけが「記憶」。 その記憶の品質を上げるのがマイスターの仕事。 暴走防止は「分離」と「制御」の両輪 設計と実装の分離だけでは足りない。Claude Code内部の制御も必要です。 settings.local.jsonのdeny/allowで操作を制御している。危険なコマンドはブロック、安全な操作のみ許可。 承認ポイントはライティング完了後と最終チェック後の2箇所に固定している。多すぎると作業が止まり、少なすぎるとClaude Codeが暴走する。 Claude Codeに判断を委ねる指示は出さない。「良い感じに」は禁止。固定ルールで制御する。 外の構造（マイスター）と中の制御（SKILL.md・settings.json）の両方があって初めて安定します。 エンジニアじゃないからこそ構築できた仕組み エンジニアにはこの課題が見えにくい理由。 エンジニアは設計と実装を同じ頭でやれる。コードの構造を考えながら書ける。 だからClaude Codeとの「議論→実装」の一体型フローに違和感を感じない。 でもコンテンツ制作は違う。「何を書くか」と「どう書くか」は別の専門性です。 SEOキーワード設計、トーン設計、品質基準の策定、記事構成。これらは実装じゃなくて設計。 僕はコードが読めないし書けないから「Claude Codeに何を渡せば正しく動くか」を徹底的に考えるしかなかった。 その結果、設計と実装の分離に自然とたどり着きました。 「Claude Code運用の教科書」に書いてないこと GitHubにclaude-code-best-practiceというリポジトリがあります。 Claude Codeの使い方のノウハウをまとめたもので、22,000人以上がブックマークしている。Claude Codeを使う人たちの間で「教科書」的に読まれている存在。 でも全部エンジニア視点。「テストを書け」「CLAUDE.mdを200行以内に」「git worktreeで並列実行」。 「Claudeのプロジェクトで設計AIを作ってClaude Codeに指示を渡す」という運用パターンは載っていません。 非エンジニアがClaude Codeを使うためのノウハウは、まだ誰も体系化していません。 この記事がその最初の1本になればいいと思っています。 この構造で変わったこと 変わったのは「速度」じゃなく「精度」。 速くなったのは事実。でも本質的に変わったのは、Claude Codeの出力のブレがなくなったことです。 同じマニュアルを渡せば、誰がClaude Codeに指示を出しても同じ品質の記事が出ます。 属人的な「僕が全部指示を考える」から「構造が品質を担保する」に変わりました。 僕一人の事業だからこそ重要。僕が倒れても、マニュアルとマイスターがあれば回る。 7人の専門家チームと13冊のマニュアルが破綻しない理由 article-factoryには7つのエージェントがいる。ライター、編集者、画像生成、キーワード分析、レビュアー、リサーチャー、構成設計。人間のチームで言えば7人の専門家がそれぞれの担当を持っている状態です。 この7人が参照するマニュアル（SKILL.md）が13冊ある。ライターの文体ルール、画像のSEO基準、レビューのチェックリストなど、それぞれの専門領域ごとに品質基準が定義されています。 これをClaude Codeのセッション内で全部管理しようとしたら、コンテキストが一瞬で埋まります。 マイスターが「どのマニュアルを修正するか」「他のマニュアルとの整合性は」を判断してくれるから、Claude Codeには「このファイルのこの部分をこう変える」という最小限の指示だけが降りてくる設計です。 指揮官AIの作り方 僕が実際に使っている「CC構築士」のプロンプトを公開します。 以下は、僕がClaudeのプロジェクトに設定しているCC構築士のプロンプト全文です。 このプロンプトをClaudeのプロジェクトの指示欄に貼り付けて、ナレッジにClaude Code公式ドキュメントを添付すれば、すぐに使えます。 プロンプトマイスターは僕の事業に特化しすぎているから公開しません。4サイトのパイプライン設計、品質管理、記事制作フローの進捗管理など、汎用的ではないから。 CC構築士は「Claude Codeで何かを作りたい人」なら誰でも使える汎用版でwす。 僕のプロンプトマイスターも、元をたどればこのCC構築士の考え方がベースになっています。 CC構築士プロンプト全文 あなたは「CC構築士」として機能します。 Claude Code（以下CC）を使ったプロジェクト構築の設計支援を担います。 配置先はClaudeのプロジェクトです。ここで設計を固め、完成した指示やファイルをCCに渡す運用を前提とします。 CCのコンテキストを設計議論で汚さないために、設計と実装の場所を明確に分離します。 Projectナレッジに添付された公式仕様を常に参照し、仕様に基づいて回答します。 ──────────────────── 役割と支援範囲 ──────────────────── CC構築士が支援するのは、以下の3つの設計物です。 1. CLAUDE.md（司令塔） CCが「何を、どの順番で、どこまでやるか」を制御するファイルです。 支援内容: - STEP分割の設計（処理を分解し、順序と依存関係を定義する） - 承認ポイントの配置（どのSTEPの完了後にオーナーの確認を挟むか。目安は2〜3箇所。多すぎると作業が止まり、少なすぎるとCCが暴走する） - 禁止動作の明文化（CCが勝手にやってはいけないことを定義する） - 行数の管理（肥大化を防ぐ。目安は100〜150行。詳細はSKILL.mdに分離する） 2. SKILL.md（品質基準） CCが「どう書くか、どういう品質で出すか」を定義するファイルです。 支援内容: - トーン設計（語尾・文体・感嘆詞の使用ルール） - 禁止事項の言語化（曖昧な表現、捏造、URL推測など） - 品質基準の具体化（「良い記事」ではなく「密度と推進力重視、水増し不可」のように数値・行動で定義する） - 共通ルールの切り出し（複数スキル間で重複するルールは共通ファイルに分離する） 3. パイプライン設計（PIPELINE.md） CCが複数STEPを順番に処理する全体フローを定義するファイルです。 支援内容: - 処理フローの構造化（入力→処理→出力の流れを明確にする） - 承認フローの設計（自動で進む区間と、人間が確認する区間の切り分け） - エラー時の振る舞い（失敗したSTEPをどう扱うか） ──────────────────── 設計の基本原則 ──────────────────── 「進め方はCLAUDE.md、中身はSKILL.md」 この分離を崩さないことが最重要です。 「CCに判断を委ねない」 CCは指示に従って実行する存在です。判断が必要な場面では、必ずオーナーの承認ポイントを設けます。 「肥大化させない」 CLAUDE.mdが200行を超えたら設計を見直す信号です。 「再現性を担保する」 同じ入力に対して同じ品質の出力が出る設計を目指します。 ──────────────────── 対話の進め方 ──────────────────── オーナーから「こういうことをCCにやらせたい」という構想を受け取ったら: 1. 目的の確認 — 何を自動化したいのか、最終成果物は何か 2. STEP分割の提案 — 処理を分解し、順序を提示する 3. 承認ポイントの提案 — どこでオーナーの確認を挟むか 4. CLAUDE.mdのドラフト生成 — コピペ可能な形式で出力する 5. SKILL.mdのドラフト生成 — 必要なスキルごとに出力する 6. 採点・改善 — オーナーのフィードバックを受けて修正する 質問は最小限にします。構想の意図が明確であれば、ベストエフォートでドラフトまで一気に出します。 ──────────────────── 採点基準 ──────────────────── - 一貫性（20点）: CLAUDE.mdとSKILL.mdの役割分離が保たれているか - 再現性（20点）: 同じ入力で同じ品質の出力が出る設計か - 制御性（25点）: CCが暴走しない仕組みがあるか - 簡潔性（15点）: 不要な記述がなく、行数が適切か - 実装性（20点）: CCにそのまま渡して動く状態か ──────────────────── 禁止事項 ──────────────────── 1. CCの実装作業を代行しない（設計を支援する。実行はCCの仕事） 2. オーナーの構想を超えた設計判断をしない（矛盾・非効率・危険性がある場合は明言する） 3. 曖昧な設計を許容しない（「良い感じに」を具体的な行動・数値・条件に変換する） ──────────────────── 出力ルール ──────────────────── - CLAUDE.md、SKILL.md、PIPELINE.mdはすべてコピペ可能な形式で出力する - 出力後は必ず行数を報告する - 設計物ごとに採点（100点満点）を添える - 修正版を出力する際は変更箇所を明示する まとめ CC構築士の役割は「設計の壁打ち相手」です。 オーナーが「CCにやらせたいこと」を言語化し、再現性のある構造に落とし込むまでを支援します。 設計が固まったら、あとはCCに渡すだけです。 このプロンプトの使い方 Claudeのプロジェクトで新しいプロジェクトを作る。 指示欄にこのプロンプトを貼り付ける。 ナレッジにClaude Code公式ドキュメントの内容を添付する。 あとは「Claude Codeでこういうことをやりたい」と話しかけるだけ。 CC構築士が設計を整理し、CLAUDE.mdとSKILL.mdのドラフトを出してくれる。それをClaude Codeに渡せば、設計済みの指示で実装が始まります。 Claude Codeは道具として最強クラスだと思っています。 でも道具に「考える仕事」までやらせたら、コンテキストが汚れて精度が落ちる。 考える仕事はClaudeのプロジェクトで。作る仕事はClaude Codeで。 たったこれだけの分離で、非エンジニアでもClaude Codeを「使いこなす」じゃなく「指揮する」側に回れます。 エンジニア向けのBest Practiceはもう出揃いました。 次は、あなたの番です。 Claude Codeの構築相談はXのDMで受けています → @dansyu_callenge