Claude Codeで「1人マーケ部門」を動かすという発想

速くなる理由は、文章生成ではなく“引き継ぎの消滅”にある

AIを使っても、仕事が思ったほど速くならない。

これは珍しい話ではありません。

文章は数分で出るのに、結局その前後で、
調査し、整理し、確認し、整え、投稿し、振り返る。

この引き継ぎの多さが、実働時間を食い続けます。

だから本当に変えるべきなのは、
「1本の文章をうまく書かせること」ではありません。

調査から公開、公開後の分析までを、
同じ文脈のまま流せるようにすることです。

ある実践例でも、調査、執筆、画像設計、事実確認、投稿、分析、予定管理、会計処理までを複数の skill に分けながら、共通の方針と共有データで束ねることで、業務全体をひとつの運用面として回していました。
重要なのは業務数の多さではなく、分離された能力を再結合している点です。

Claude Codeは、プロンプト置き場ではなく“運用面”になりうる

Claude Code は公式に、コードベースを読み、ファイルを編集し、コマンドを実行し、各種ツールと接続できるエージェント型の作業環境として位置づけられています。
さらに Skills、CLAUDE.md、Hooks、Permissions、MCP という拡張点があり、単発の会話ではなく、繰り返し仕事を回すための土台が用意されています。

ここで見方を変えると、Claude Code は「開発者向けAI」ではなく、
仕事を分解して再実行可能にするための作業OSとして読めます。

マーケティングでも同じです。

ネタを集める。
切り口を選ぶ。
記事を書く。
図を作る。
事実を確かめる。
SNSへ展開する。
反応を回収する。
次の企画へ返す。

この一連の流れは、人間の頭の中ではつながっています。
問題は、それが毎回会話のたびに切れてしまうことです。

速くなる本当の理由は、生成能力ではなく“再説明コストの削減”

多くの人は、AI活用を「文章生成を速くする技術」として理解しています。
しかし、実務で一番重いのはそこではありません。

重いのは、前工程の判断を次工程へ渡す作業です。

たとえば、調査で見つけたネタを記事化するとき、本来ならもう一度、
読者像、ブランドトーン、過去記事との整合性、使っていい表現、避けるべき言い切り、保存先、公開後の展開先まで説明し直す必要があります。

この“説明し直し”が、地味に大きい。

だから、1人マーケ部門を作るという発想の核心は、
AIの人格を増やすことではありません。

共通方針、共有データ、共通評価基準を持った専門技能群に分けることです。

実践例でも、ネタ台帳、展開台帳、公開実績台帳のような共有データ層を置き、そこを複数 skill が参照・更新することで、調査から執筆、公開後分析までをループ化していました。これは単なる自動化ではなく、外部状態を持った運用設計です。

構造で見ると、必要なのは4つだけです

この仕組みは、細かく見ると複雑に見えます。
ただし骨格はかなり単純です。

まず必要なのは、共通方針です。

誰に向けて、
どんなトーンで、
どこまで自動化し、
どこから確認を入れるのか。

これは毎回会話で説明するものではなく、
常設の前提として持つべきものです。

Claude Code では、こうした持続的な指示は CLAUDE.md と auto memory によってセッションをまたいで読み込まれます。公式 docs でも、CLAUDE.md は「毎回言い直していること」を書く場所として位置づけられています。

次に必要なのは、専門技能の分離です。

調査、執筆、図解、ファクトチェック、分析。
これらを1つの巨大プロンプトに詰め込むと、変更にも弱く、品質も揺れます。

Claude Code の Skills は、そうした定型作業やワークフローをモジュール化するための仕組みです。必要なときだけ呼び出せるので、常時全ルールを抱え込まずに済みます。

3つ目は、外部状態です。

ネタ、進行状況、公開履歴、反応。
これを会話履歴の中だけに置くと、セッションが変わるたびに溶けます。

だから、CSVでも Notion でも SQLite でもよいので、AIの外に状態を置く。

すると、AIは「覚えているから動く」のではなく、
参照できる状態があるから動くようになります。

4つ目は、評価回路です。

ここが抜けると、見かけ上は回っていても、実際には品質が崩れます。

誇張がないか。
出典は取れているか。
タイトルは強すぎないか。
サムネイルはトーンからズレていないか。
公開後の反応はどうだったか。

この評価を生成と分離しておくことで、改善ループが回り始めます。

ここで多くの人がやりがちな失敗

一番多い失敗は、CLAUDE.md に全部書くことです。

ですが公式 docs は、CLAUDE.md も auto memory も「強制設定」ではなく「文脈」として扱われると説明しています。
つまり、長く書けば書くほど必ず守られるわけではありません。
むしろ、具体的で簡潔な方が安定します。
また、.claude/rules/ を使って対象ファイルや用途ごとにルールを分ける設計も案内されています。

もうひとつの誤解は、Skill に allowed-tools を書けば安全になる、という見方です。これは少し違います。

allowed-tools は「その skill 実行中に承認を前倒しする」機能であって、利用可能なツール自体を制限するものではありません。
本当に止めたい操作があるなら、permissions 側で deny ルールを置く必要があります。

さらに、「毎回必ずこの確認を通したい」
という処理は、文章でお願いするだけでは弱いです。

Claude Code では hooks を settings JSON に書いて自動化できます。
しかも /hooks メニューは閲覧用で、追加や編集は settings 側で行う前提です。
つまり、品質ゲートを本気で安定化したいなら、
方針は CLAUDE.md、
技能は Skill、
強制は Hook、
境界は Permissions、
と分担した方がいい。

では、何から始めればいいのか

答えは、部門を作ろうとしないことです。
最初に作るべきなのは、たった1つの再現可能な業務セルです。

たとえば、毎週の投稿作成でもいい。
問い合わせ返信でもいい。
記事の構成作成でもいい。

その仕事について、
最初に何を確認し、
どの順番で進め、
どこで止まり、
何を成果物と見なすのかを、
Markdown で書き出す。

それだけで、かなり景色が変わります。

その次に、その業務セルが参照する共通ルールを CLAUDE.md に寄せる。
さらに、ネタや進行状況を外部ファイルに出す。

最後に、1つだけ評価を追加する。
ここまでできれば、もう単発プロンプトには戻りにくくなります。

なぜなら、AIに仕事を頼んでいる感覚から、
仕事が再開可能な構造に変わった感覚へ移るからです。

結び

Claude Codeで「1人マーケ部門」を作る、という言い方は刺激的です。
ただ、本質は人数の比喩ではありません。

本当に起きているのは、
バラバラだった業務を、
共通方針と外部状態と評価回路で束ね直し、
引き継ぎコストをほぼ消していることです。

AI時代の競争力は、1本の強いプロンプトにあるのではありません。

どこまで仕事を、
分解できるか。
外に出せるか。
再開できるか。
監査できるか。
改善できるか。

そこにあります。

Claude Code は、そのためのかなり強い土台を、すでに持っています。
CLAUDE.md、Skills、Hooks、Permissions、MCP、auto memory という現在の公式機能群を見ると、単発支援よりも、反復業務の運用面へ寄っていく設計がはっきり見えます。

#ClaudeCode #生成AI #AI活用 #業務自動化 #AIエージェント #プロンプト設計 #ハーネス設計 #マーケティング #コンテンツ設計 #note

この記事は、「Claude Code で何ができるか」の紹介ではなく、
仕事を再開可能な構造へ変えるには何が要るかを整理するために書きました。

そして、本当に差が出るのはこの先です。

skill の切り方、
CLAUDE.md に持たせる範囲、
状態を外に逃がす設計、
評価回路の置き方。

このあたりは、表の説明だけでは身につきません。

メンバーシップでは、そうした運用設計の中身を、
実務で使える粒度で継続的に深掘りしています。

「読む」だけでなく、自分の環境に持ち帰れる理解が欲しい方へ。