Claude Codeで”1人マーケ運用”を作る｜業務をスキルに部品化し、GitHubで共有する（実践編③）
目次 クリックで開く
AIに単発で頼むのは、慣れるほど物足りなくなります。依頼のたびに「うちのブランドはこう言い回す」「このデータはこう読む」と前提を説明し直し、同じ頼み方をしても出力の質はその日ごとにブレる。極めつけは、自分以外の人が同じことを再現できないことです。時短のつもりが、指示を書く手間と手直しでかえって時間を溶かしている——そう感じ始めたら、それが次の段階に進むサインです。
ここで一度、立ち止まって考えたいことがあります。「あの人しかできない」と言うとき、私たちはその人の中に特別な才能が宿っていると思いがちです。けれど、その人が実際に握っているのは、魔法のような成果物ではなく、頭の中で毎回なぞっている“手順”のほうです。だとすれば、時短の次の一歩は明快で、繰り返す業務を「スキル」に部品化し、頭の中の手順そのものを外へ取り出して資産にすればいい。さらにそのスキルをGitHubでチーム共有すれば、「あの人しかできない」という属人化まで、仕組みで解けます。
スキル化とは、成果物ではなく”手順”を資産にすること。「あの人しかできない」を、才能ではなく仕組みで解く発想です。
この記事は、当社がClaude CodeのスキルとGitHubでこれをどう組んでいるかの実践記録です（クライアント情報はすべて匿名化しています。以下の画面例も、匿名化した説明用のサンプルです）。役割はいつもと同じで、スキル化したClaude Codeが”実行”し、人はディレクションに回ります。
なぜ”スキル化”なのか ― 単発プロンプトの限界
もう少し、単発プロンプトの何が苦しいのかを具体で見てみます。たとえば「競合を調べて」と頼むと、ある日は5社・ある日は3社、出典URLを付ける日もあれば付けない日もある。そのたびに「うちのブランドの言い回し」「このデータの読み方」「レポートの体裁」を前置きで書き足すので、指示はいっこうに短くなりません。そして同じ言葉で隣の人が頼んでも、同じ品質は返ってこない——。
この三つの症状、前提の再入力コスト・品質のブレ・再現性のなさは、別々の問題に見えて根は一つです。前提と手順が、指示のたびに揮発してしまう。頭の中にある”暗黙の段取り”に毎回依存しているから、書き直す手間が消えず、出力が揺れ、他人が再現できない。三つ目の再現性のなさは、そのまま属人化の別名でもあります。
だとすれば打ち手は一つです。繰り返す業務については、前提・手順・出力形式・確認方法を、一度きちんと固定してしまう。「また同じ説明を書いているな」と感じた瞬間が、いちばん分かりやすいスキル化の合図です。逆に、月に一度あるかないかの単発作業まで無理に部品にする必要はありません。繰り返しの頻度こそが、スキルにするかどうかの最初の物差しになります。
“スキル”とは何か ― 入力・処理・出力・確認を固定した手順の部品
では、”手順を資産にする”とは具体的にどんな形をとるのか。架空の「競合調査スキル」で考えてみます。入力は”対象カテゴリと自社の該当URL”、処理は”上位ページを開いて見出し構成と論点を書き出す”、出力は”自社と競合の差分を並べた表”、確認は”主張には必ず出典URLを添える”。ここまで決めてあるから、呼び出すときは「競合を調べて」の一言で済み、返ってくる形もいつも同じになります。プロンプトが短くなるのは、長い前提をスキル側に預けているからです。
ここに、単発の指示とスキルを分ける一線があります。ここでいうスキルとは、入力（何を渡すか）／処理（どう進めるか）／出力（どんな形で返すか）／確認（何をもって合格とするか）の四点をそろえた、再利用できる”手順の部品”のこと。その場かぎりの口頭のお願いが、誰が読んでも同じ作業に落ちる手順書へ変わります。四点がそろって初めて、”部品”として繰り返し使えるようになります。
見落とされがちなのが、四つ目の「確認」です。入力・処理・出力だけだと、それらしいけれど検証されていない出力が平気で返ってきます。「数値の主張には出典を付ける」「事実は推測で埋めない」といった合格条件をスキル自身に持たせておくと、誰が呼んでも品質の下限がそろう。単発の指示との本質的な違いは、この合格条件を毎回持ち歩けることにあります。プロンプトのコピペ集がスキルになりきれないのは、たいていこの一点が抜けているからです。
マーケ運用を”スキル”に分解する ― 粒度の考え方
スキルを一つ作れたら、次は業務全体をどう刻むかです。当社では、マーケ運用をレイヤーで部品化しています。調査／制作／分析／品質管理／オペレーションという業務の層でざっくり割り、その一つ一つを小さなスキルにする。単体では小さくても、組み合わさると”1人マーケ運用”として機能します。
刻む単位の基準は、「1スキル＝1つの成果物、または1つの判断」です。診断スキル（数値から弱点を出す）、リライトスキル（1記事を意図に沿って加筆する）、レポートスキル（定例を1枚にまとめる）——このくらいの粒度なら、単体でも使えて、繋いでも使えます。
粒度は、大きすぎても小さすぎても効きません。「競合を調べて、記事まで書いて、公開する」を1本に詰め込むと、調べる・書く・公開するのそれぞれに人の判断が挟まるため、途中が気に入らないと全部やり直しになります。逆に「見出しを1つ書く」だけをスキルにすると、呼び出す手間のほうが中身より重くなり、結局は手作業に戻ってしまう。「これは1つの成果物と言えるか」「途中に人の判断が2回以上挟まっていないか」を物差しにすると、ちょうどいい大きさに落ち着きます。判断が二回以上挟まるなら、そこはスキルを分ける合図です。
もう一段の設計として、ログインやブラウザ操作のようなどのスキルでも使う共通処理は、専用スキルに切り出して委譲します。こうしておくと、分析スキルは”取得と分析”だけに専念でき、共通処理を直したいときも一箇所を直せば済む。この”共通部分を外に出す”発想が、次の話にそのままつながります。
スキルが増えたら、共通原則を”正本”にまとめる（DRY）
スキルが5本、10本と増えると、今度はスキル間で原則がバラつく問題が顔を出します。「数値だけで結論を出さず、必ず実物——検索クエリ・実際の記事・競合ページ——を開いて確かめる」「仕様は推測せず公式情報で裏を取る」「提案は結論から書き、主要因は3つに絞る」。こうした分析の共通原則を各スキルにコピペしていると、方針を一つ直すたびに全スキルを開いて直す羽目になります。10本あれば10箇所、直し忘れも必ず出る。これは早晩、破綻します。
ここで効くのが、プログラミングでいうDRY（Don’t Repeat Yourself＝同じことを繰り返し書かない）の発想です。共通原則は一つの”正本”にまとめて各スキルはそこを参照させ、チャネル固有の差分だけを各スキルに持たせる。正本を1箇所直せば、全スキルの品質が同時に底上げされます。手順を資産にするなら、その資産は重複なく整理されているべきで、スキルが増えるほどこの”正本”の効きは大きくなる。原則は正本に、手順は各スキルに——この住み分けが、規模が増えても崩れない運用の背骨になります。
CLAUDE.md ＝ 全スキルが共有する”運用方針書”
正本で”分析の原則”をそろえても、出力のトーンや判断基準まではまだバラつきます。スキルをバラバラに作れば、丁寧語とぶっきらぼうが混じり、承認が要る操作の線引きもスキルごとにズレる。これを土台からそろえるのが CLAUDE.md——いわば会社の運用方針書です。プロジェクトの入り口に置いておくと、どのスキルを呼んでも最初にここが読まれ、全員が同じ前提から動き出します。
書くのは、特定の作業手順ではなく、全スキルに共通して効くことだけです。文章のトーン（ですます・実務家の一人称・煽らない）、外してはいけない禁止事項（顧客名を出さない・数字を盛らない・自己卑下しない）、データをどのフォルダに置き鍵は .env に分離するといった置き場所の約束、スキル名は「動詞＋対象」で揃えるといった命名規則、そして人の承認が要る操作はどれかという判断基準。個々のスキルが”作業”なら、CLAUDE.mdは全員が共有する記憶にあたります。
コツは、スキルに書くことと、CLAUDE.mdに書くことを分けること。迷ったら「これは1つの作業の話か、全作業に効く話か」で振り分けます。この線引きがあいまいだと、あとで触れる”肥大化”のもとになる。とりわけ禁止事項をここに一元化しておくと、「顧客名は出さない」「数字は盛らない」がどのスキル経由でも効くので、匿名化のような外せない約束を、人の注意力に頼らず守れるようになります。
GitHubでスキルを共有する ― 属人化を解く
スキルの真価は、チームで共有したときに出ます。スキル一式とCLAUDE.mdをGitHubのリポジトリに置き、push と pull で全員が同じ最新スキルを使えるようにする。ここでようやく、”手順を資産にした”ことの見返りが効いてきます。
構成に凝る必要はありません。リポジトリの入り口に CLAUDE.md を置き、skills/ の下に「1スキル1フォルダ」で手順を並べ、認証情報は .env に分けて .gitignore で共有対象から外す。これだけで”手順は共有し、鍵は各自の環境に置く”形になります。フォルダを見れば何のスキルがあるか分かる、くらいの素直さがちょうどいい。
更新の回し方は、ソフトウェア開発の作法がそのまま使えます。誰かが競合調査スキルを改善したら、その変更をプルリクエストとして出し、レビューを経てから取り込む。すると改善がチーム全員に一度に行き渡り、しかも「いつ・誰が・なぜ変えたか」が履歴として残る。うまくいかなかった変更は、前のバージョンに戻すだけで復旧できます。個人のメモを各自のPCに散らかしていては、こうはいきません。
そして冒頭の属人化——「あの人がいないと回らない」——が、ここで仕組みとして解けます。新しく入った人は、リポジトリを clone するだけで、ベテランと同じ手順・同じ前提の運用を、その日から再現できる。ノウハウが個人の頭の中ではなく、共有された部品の側に貯まっていくからです。冒頭で「あの人が握っているのは手順だ」と書きましたが、その手順を全員が取り出せる場所に置いた瞬間、”あの人しかできない”は自然に消えます。人が抜けても運用が止まらない状態は、こうして作ります。
.env に分離して .gitignore する。スキルは”手順”だけを共有し、”鍵”は各自の環境に置く。“3回やったらスキル化” ― スキルの育て方
ここまで読むと、いきなり立派なスキル群を設計したくなるかもしれません。ところが最初から完璧を狙うと、たいてい過剰になって、結局使われません。手順は机上で設計するものではなく、使いながら見つけるもの。おすすめは「3回やったらスキル化」という順番です。いきなり部品を作らず、3回の実作業を通して型を見つけます。
1回目は、手順メモ。作業しながら「何を見て・何をして・何を確認したか」を、走り書きでいいので言葉に残すだけ。2回目は、テンプレ化。そのメモを、次も同じようになぞれる形に整えます。ここで初めて、”毎回変わらない共通部分”と”案件ごとに変わる部分”が見分けられる。3回目で、部品化。入力・処理・出力・確認を固定し、正式なスキルに落とします。3回待つ理由は単純で、1回目の思いつきで作ると例外だらけの設計になり、2回でようやく共通点が、3回目で安定した型が見えてくるからです。
安定したら、GitHubに置いてチーム共有へ進みます。1本目が回り始めたら2本目を足し、片方の出力をもう片方の入力に繋ぐと、運用が点から線へつながっていく。型は、作るものというより育てるもの——この「使ってから固める」リズムが、無理なく積み上げるいちばんのコツです。
1日の実働イメージ
スキルが揃うと、1人でもこう回ります。朝は gsc-weekly と competitor-scan で状況を把握し、その日に手を入れる場所を決める。昼は article-draft で制作し、fact-check と anonymize で事実確認と匿名化のQAをかける。夕方は weekly-report で定例を1枚にまとめる。実行の大半はスキルが担い、前工程の出力をそのまま次工程の入力に渡せます。たとえば competitor-scan が出した差分表を、コピー&ペーストの往復なしにそのまま article-draft へ流し込む。1日の中で作業が滑らかに繋がっていきます。
ただし、動かしてはいけない線が一本あります。人がやるのは「どの示唆を採るか」「この提案は本当に相手の課題に答えているか」という、判断と最終確認。手順化できる”実行”はスキルへ、文脈と責任が要る”判断”は人へ。スキルが何本増えても、この分担だけは動かしません。
むしろ、実行が速く安定するほど、人は判断に時間を割けるようになります。1日の終わりに残る仕事が「作業」から「意思決定」へ移っていく——これが、スキル化のいちばん実感しやすい効果です。忙しさの総量が減るというより、時間の使い先が変わる、という手応えに近いものです。
つまずきやすい所 ― 4つの落とし穴
最後に、実際にハマりやすい落とし穴を4つ。どれも”型を持ったからこそ”起きる、運用の副作用です。まず粒度ミスは前述のとおりで、大きすぎると再利用できず、小さすぎると呼び出しコストに負けます。似た罠が過剰な抽象化で、まだ2回しかやっていない作業を”あらゆる場合”に備えて汎用化すると、条件分岐だらけで誰も呼べないスキルになる。汎用化は、繰り返しが実際に3回来てからで十分です。
地味に効いてくるのがメンテ放置です。外部の仕様や自社の方針が変わったのにスキルを直さず回すと、”それらしいが古い”出力を量産してしまう。だからこそ確認（合格条件）をスキルに持たせ、たまに実物と突き合わせる習慣が要ります。そしてCLAUDE.mdの肥大化。何でも書き足していくと、長すぎて誰も読まない方針書になる。膨らんできたら、全体に効く前提だけを残し、個別の手順はスキル側へ戻す。使われていないスキルを畳むのも、立派なメンテです。四半期に一度、使っていないスキルとCLAUDE.mdを見直す日をあらかじめ決めておくと、放置と肥大化はかなり防げます。型は、増やすことより、生きた状態に保つことのほうが、じつは難しいのです。
まとめ：単発の効率化から、再現できる運用へ
Claude Codeの本当の効きどころは、単発の時短ではありません。業務をスキルに部品化し、GitHubで共有して”組織で再現できる運用”に変えること——言い換えれば、成果物ではなく手順のほうを資産にすることにあります。CLAUDE.mdで前提を揃え、スキルで手順と合格条件を固め、GitHubで属人化を解く。そこに「鍵は共有しない」という最低限のセキュリティの型を重ねれば、少人数でも安全に、運用を回し続けられます。
始め方は、拍子抜けするほど地味で構いません。まず、いつもやっている定型作業を1つ選び、手順メモから始める。1つが回り始めれば、任せられる範囲は自然に積み上がっていきます。単発の効率化で止まるか、再現できる運用まで育てるか——その分かれ道は、いつも、この最初の1スキルにあります。
関連ガイド（実践編シリーズ）
よくある質問（スキル化とGitHub共有）
Q. Claude Codeの「スキル」と「プロンプト」の違いは？
A. プロンプトは都度の指示、スキルは前提・手順・出力形式を固定した定型の指示書です。繰り返す業務はスキル化すると、呼び出しが短く済み、品質が安定し、チームで再現できます。
Q. GitHubでスキルを共有するメリットは？
A. 属人化の解消、バージョン管理（誰がいつ何を変えたか）、プルリクエストでのレビュー、新メンバーがcloneするだけで同じ運用を再現できることです。
Q. スキルをGitHubで共有するときのセキュリティ上の注意は？
A. 認証情報（APIキー・パスワード）をスキルに絶対に入れないこと。鍵は.envに分離してgitignoreし、スキルは手順だけを共有します。
Q. 何人規模から有効ですか？
A. 1人でも業務を部品化するメリットは大きく、GitHub共有を加えるとチームの属人化解消に効きます。まず1スキルから始め、育ててから共有するのが安全です。
“スキル×GitHubで回すAI運用”の構築・定着支援
業務のスキル化、CLAUDE.mdでの方針統一、GitHubでのチーム共有、鍵を共有しないセキュリティ設計まで支援します。無料のご相談から。
AI・業務自動化
ChatGPT・Claude APIを活用したAIエージェント開発、n8n・Difyによるワークフロー自動化で繰り返し業務を削減します。まずはどの業務をAI化できるか診断します。