【非エンジニアのためのClaude/Claude Codeシリーズ】営業マネージャーがClaudeの公式営業スキルを使わず、自分で作って育て、棚卸しした話
こんにちは。アカウント営業部でマネージャーをしている福島です。エンジニアではありません。メンバー6名のチームで、自分でも案件を持ちながらマネジメントをしています。
このシリーズの第2回で、HubSpotやSlackなどの営業ツールをClaude Codeにつないだ話を書きました（営業ツールをClaude Codeにつないでみた（MCP連携編））。今回はその続きです。
Anthropic公式には、営業向けのスキル（Claudeへの指示書のようなもの）が9本用意されています。結論から書くと、私はこれを1本も使っていません。しかも正直に書くと、比較検討した結果やめたのではありません。存在をちゃんと見ないまま、自分の業務に合わせて自作していました。
先日そのことに気づいて、公式9本を読んで答え合わせをしてみました。ついでに、自分が作ったものが本当に使われているのかも数えてみました。その結果が、自分でも意外だったので記事にします。
朝、「おはよう」と打つだけ
いま私の朝は、Claude Codeを開いて「おはよう」と打つところから始まります。すると、
- 今日のカレンダー（会議とToDoを区別して表示）
- 返信が必要なメールのスレッド
- 進行中案件で今日動かすべきもの
が整理されて、「今日のストーリー」として1枚のメモに出てきます。終業時は「おつかれ」と打つと、その日の商談メモが顧客ごとのファイルに整理され、完了したタスクが掃除されます。
この仕組みは、Claudeと会話しながら作りました。私が「朝はこの3つが見たい」「これは絶対にやらせたくない」と話し、Claudeがそれを指示書の形にしていく。決めるのは私、書くのはClaude、という分担です。逆に、出来上がったファイルの細部までは読み込んでいません。私が見るのは「使ってみて、期待どおりに動いたか」だけです。
あとから公式スキルを読んでみたら
公式の営業向けスキルは、account-research（企業調査）、call-prep（商談準備）、daily-briefing（朝のブリーフィング）、pipeline-review（パイプライン確認）など9本あります。中身はGitHubで公開されています（anthropics/knowledge-work-plugins の sales/skills）。以下は2026年7月時点で確認した内容です。公式のものは更新されるので、読む時点で中身が変わっている可能性があります。
全部読んでみて、わかったことが3つありました。
1つ目。公式スキルの実体は、いずれも「英語で書かれた指示書」でした。 9本のうち8本はテキストファイル1枚だけ。残る1本（資料作成用のもの）が3枚組で、それが一番長い。そしてこの9本には、プログラムが1行も入っていません（公式が配っているものには他にツール連携の部品なども含まれますが、少なくとも「スキル」と呼ばれている9本の中身は文章だけでした）。つまり「スキルを使う」とは、誰かが書いた仕事の手順書をClaudeに渡すことです。これは私にとって発見でした。手順書なら、自分の業務の言葉で決められます。文章に起こす作業はClaudeに任せられるので、書式を覚える必要もありません。
2つ目。9本は「案件と数字」で完結していて、「人」が出てきませんでした。
誤解のないように書くと、マネージャーの仕事が全部抜けているわけではありません。着地予測を作るスキルも、パイプラインを点検するスキルもあります。後者は「メンバー単位で見る」使い方が最初から想定されています。つまり数字のマネジメントは、公式の射程に入っています。
入っていないのは、人のマネジメントです。メンバーとの1on1、育成、商談への同行フォロー。9本のどこにも出てきません（人事向けの別プラグインには評価や組織設計のスキルがありますが、営業マネージャーが毎週やっている「人の仕事」ではありません）。私の業務時間の多くはここです。汎用品は「平均的な営業パーソン」向けに作られていて、私の仕事の中心はそこから外れていた、ということです。
3つ目。当然ですが、私の会社の「データの正しい読み方」は入っていません。 たとえば当社では、案件金額は顧客管理システム（CRM）に入力された値より、見積・請求を発行する基幹システムの数字が正、という運用ルールがあります。こういう「うちの会社ではこう」という知識は、公式スキルには入りようがない。そしてこれが一番大事なのですが──この種の知識は、Claudeに間違えられて初めて言語化されるものでした。
3つ目の話を、実際に怒った順にします。
1回目：「返事したよ」
朝のブリーフィングを使い始めて数日目。Claudeが「このお客様への返信が必要です。ボールはこちらにあります」と報告してきました。実際は、私が前日に返信済みで、先方からお礼まで届いていました。
原因を聞くと、Claudeはメール検索の結果だけを見て「未返信」と判断していました。検索は条件に合ったメールしか返さないので、スレッドの最後の数通が見えていなかったのです。
やったのは、プログラムの修正ではありません。指示書に日本語で1行足しただけです。
「要返信」と断定する前に、必ずスレッド全文を開いて最後の送信者を確認すること。
その後、同じ間違いには気づいていません。
2回目：「読めてんじゃん」
別の朝、カレンダーの予定のうち3件が「自己ブロック」とだけ表示されていました。実際はGoogle ToDoから入れたタスクの時間ブロックです。直後に私が「タスクは読めないの?」と聞くと、Claudeは「読めません」と答えました。読めていたのに、です。さっき自分で表示していた3件がToDo由来だと、自分で気づいていなかった。
ここで足したルールはこうです。
ToDo由来の予定には「📋ToDo」とラベルを付けて、会議と区別して表示すること。できること・できないことの説明は正確に。「時間指定のあるToDoは見える、時間なしのToDoは見えない」。
AIは「できること」を過小に申告することがある、というのは意外な学びでした。できないと言われた時点で諦めていたら、この機能は使えないままでした。
3回目：「なんで全部英語なん」
日次のブリーフィングを自動実行できるようにした直後、朝の報告が全部英語で届きました。仕組みの内部が英語で動いているため、長い処理の後は出力まで英語に引きずられるようです。足したルールは1行です。
私への報告・ファイルへの書き込みは常に日本語。長い処理の後は特に英語に引きずられやすいので、報告を書く前に言語を確認すること。
資産はスキルではなく「怒った記録」だった
3回怒って気づいたのは、価値があるのはスキル本体ではなく、失敗のたびに書き足したルールの蓄積だということです。私の環境には、こうした「間違えられて足したルール」が現時点で17本あります。全部、実際に間違えられて、指摘して、1〜3行の日本語で書き足したものです。期間にして2〜3か月分です。
公式スキルを使わなかった理由を後付けで整理すると、結局ここに行き着きます。汎用品には、私の失敗の記録が入っていない。私の運用では、モデルの違い以上に「うちの会社では・私の仕事ではこう」という注意書きが精度に大きく効きました。そしてこれは、使いながら書き続けた人にしか貯まりません。逆に言えば、コードが書けなくても貯められます。必要なのは、自分の仕事のやり方を日本語で説明することだけだからです。
ただ、ここまで書いていて自分に引っかかることがありました。この17本は、全部「実際に使って、間違えられて、直した」結果です。つまりルールが貯まるかどうかは、その仕組みがどれだけ運転されたかに丸ごと依存しているということです。動いていない仕組みには、1本も貯まりません。
では、私が作ったものは本当に動いているのでしょうか。
数えてみたら、自分は5本の状態を把握していなかった
ここからが、この記事で一番書きたかったことです。
私は「よく使っている」という感覚だけで話していたので、本当に動いているのかを実際に数えてみました。決まったタイミングで勝手に動くようにしたものが5本あります。この5本を、出力先の記録で1本ずつ確認しました。
【毎日動くもの：3本 → 全部生きていた】
- 朝の「おはよう」／終業の「おつかれ」……出力先のメモは毎日更新され続けている
- チームの日次差分レポート……前日の受注・失注・ステージ変更・新規案件を自動でまとめ、チームのチャンネルに投稿。数えたら17日間で13営業日、1日も欠けずに投稿されていた
毎朝チームのチャンネルに自動投稿される日次差分レポート（本記事用のダミーデータ）。集計だけでなく、CRMの入力漏れも指摘する
※本記事用に作成したダミーデータです。実在の企業・案件・担当者とは関係ありません。
【週に1回以上あくもの：2本 → どちらも投稿されていなかった】
- 週次サマリ……1回投稿されたきり、それ以降動いていない。これは止まっていた
- 滞留案件のチェック……1件も投稿されていない。ただし調べてみると、こちらは止まったのではなく月に1回の設定で、まだ初回の実行時刻が来ていなかっただけでした
作った時期は近く、出来にも大きな差はありません。それでも、毎日動く3本とは結果がきれいに分かれました。
そして自分でも情けなかったのが、この2本は数えるまで区別がついていなかったという点です。私の頭の中ではどちらも「たしか作ったけど、最近見ていないやつ」で同じ扱いでした。片方は死んでいて、片方はこれから動く。まったく違う状態なのに、投稿がないという見え方だけが同じなので、区別できていなかったのです。
「他人が見ているから続く」は間違いだった
最初、私はこう考えました。「日次差分レポートが続いているのは、チームのチャンネルに出るからだ。止まれば誰かが気づく。だから他人の目があるものは生き残る」と。
ところが、止まった週次サマリも同じチームのチャンネルに投稿されていました。メンバー全員に見える場所に出ていて、それでも1回で止まりました。つまり「他人の目に触れるかどうか」は関係なかった。もっともらしい説明でしたが、証拠が否定しました。
残ったのは頻度の差だけです。毎日動くものは全部生き残り、週に1回以上あくものは投稿が出ていませんでした。
そこで「じゃあ頻度を上げれば定着するのか」と考えかけて、やめました。順番が逆だと思ったからです。
使われなかったものは、必要性を疑ってよい。
止まった週次サマリは、メンバー全員に見える場所に出ていました。1回出て、それきり止まって、少なくとも表立って困ったという声は出ませんでした。存在を忘れていた、別の方法で補っていた、といった可能性はあります。それでも、当時の私たちの運用では優先度が低かったとは言えます。私が「便利そうだから」作っただけで、必要性を確かめていなかったのです。
一方で頻度が低いと、そもそもその判定材料がなかなか集まりません。滞留案件のチェックは、要るか要らないかを判断する材料が、まだ1件も出ていないわけです。毎日動くものは、合わなければすぐに気づけます。月に1回のものは、要るかどうかを知るまでに何か月もかかり、その前に忘れられます。
つまり頻度の差が効いていたのは、定着の話ではありません。要否を判断できるまでの速さの差でした。
私は「マネジメントに使えるスキルが公式にない」と偉そうに書きましたが、では自分が作ったチーム向けの仕組みを把握できていたかというと、していませんでした。1本は止まっていることに気づかず、もう1本は初回の実行前なのかどうかも把握していなかった。ここは正直、書いていて気まずいところです。
ただ、そこから引き出す教訓は「毎日動くものだけ作れ」ではないと思っています。私が作ったような簡単な指示書なら、初版は5分ほどで作れるからです。短時間で試せるものを、作る前に厳しく審査するのは費用対効果が悪い。気軽に作ってよくて、そのかわり定期的に棚卸しして捨てるほうが効きます。
そして棚卸しは、捨てるためだけの作業ではありません。前半に書いた17本のルールは、動いている仕組みの上にしか貯まりません。どれが資産になっていて、どれが1本も生んでいないのかを確かめる作業でもあります。
そして、この記事のために5本を数えたこと自体が、その棚卸しでした。やってみるまで、私は5本それぞれの状態を把握できていませんでした。半年に一度でいいので、自分が作ったものを並べて、動いているか、まだ要るかを数えてみてください。 厄介なのは、止まったことにも、要らなくなったことにも、そしてまだ一度も動いていないことにも、誰も気づかないという点です。
後半：作り方
ここからは再現手順です。前提として、Claude Code（またはClaudeのデスクトップアプリ）が使える状態と、必要ならツール連携（第2回参照）ができていれば十分です。
なお「コードを書く必要があるか」ですが、私は自分では1行も書いていません。ただし正確に言うと、CSVを集計してレポートを出すような処理では、Claudeが裏でプログラムを書いています。私はそれを読んでいませんし、読めません。ここは「自分で書かなくていい」であって「プログラムが存在しない」ではない、と正直に書いておきます。
【手順1】気軽に作る。そのかわり定期的に棚卸しする
私が作ったような簡単な指示書なら、初版は5分ほどで作れます。なので「本当に必要か」を作る前に厳しく審査する必要はありません。短時間で試せるものなら、思いついた段階で作っていい。
そのかわり、カレンダーに棚卸しの予定を入れてください。 半年に一度でいいです。やることは3つだけです。
- 自分が作ったものを全部並べる（意外と忘れています）
- 出力先を見て、まだ動いているかを確認する
- 動いていないものについて、まだ要るかを判断する。要らなければ捨てる
要らないものを捨てるのは失敗ではありません。短時間で試せるものなら、要らないと分かった時点で捨てるのが正しい運用です。私が2本の状態を把握できていなかったのは、この棚卸しをしていなかったからです。
【手順2】書式は調べない。会話で決めて、怒ったら1行足す
スキルの実体は、決まった場所に置くテキストファイルです。ただ、書式を自分で調べる必要はありません。部下に仕事を頼むときの粒度で話し、それをスキルとして保存してもらえば済みます。
「朝『おはよう』と言ったら、今日のカレンダーと未返信メールと進行中案件を見て、今日のストーリーを1枚のメモにまとめてほしい。会議とToDoは区別して。メール送信やカレンダー変更は絶対にしないで。報告は日本語で。これをスキルにして保存して」
ここで手を抜けないのは「何を見たいか」と「何をやらせたくないか」です。ここは業務を知っている自分にしか決められません。逆に、それをどうファイルに書くかは考えなくていい。
そして最初の指示は5行で構いません。運用して、間違えられたら、その場でClaudeに「いま何を間違えた? 再発防止のルールを1行で書いて、指示書に足して」と言う。これだけで指示書が育ちます。私の17本のルールは全部この方式で貯まりました。
逆に、最初に時間をかけて完璧な指示書を作ろうとすると、実際には起きない失敗への対策で分厚くなるだけです。書式や内部構造まで精読する必要はありません。ただし、何を読み、どこへ書き、何を禁止しているかは確認します。そのうえで、運用中は「怒った内容が1行として入ったか」と「次から直っているか」を見ます。
【手順3】「読み取りは必要な範囲、書き込みは関所」の線を引く
非エンジニアがAIにツールをつなぐとき、一番決めるべきはここです。私の線引きはこうです。
- 読み取り（メール・カレンダー・CRMを見る）：社内ルールと必要な範囲で許可。間違えてもデータは壊れない
- 書き込み（メール送信・顧客データの更新）：原則禁止。Claudeにはドラフト作成までやらせて、送信は必ず私が行う
- 例外にするもの：実害が小さく、取り消せるものだけ（私の場合はToDoリストへの登録のみ。それも一覧を見せてもらい、OKしたものだけ）
読み取りについて一点補足すると、「壊れない」＝「何でも見せていい」ではありません。見せた情報はAIの処理に乗るので、機密の範囲は書き込みとは別に考える必要があります（そこは会社のルールに従うべきところです）。私が言いたいのは、壊れるかどうかの線は書き込み側にあるということです。
この線を最初に決めておくと、AIの間違いは「報告の間違い」に留まり、「お客様に届く間違い」にはなりません。上司や情報システム部門に相談するときも、自分の線引きを説明できる状態から入れます。必要事項を確認したうえで細部まで読み込まずに運用できているのは、この関所を自分で決めているからです。任せる範囲は広く、任せない範囲は自分で線を引く。この2つはセットです。
【手順4】覚えさせるものは「1年後も正しいか」で選ぶ
数字や案件状況のような「すぐ古くなる情報」はAIに覚えさせず、毎回ツールから取りに行かせます。ファイルに残すのは「判断の記録」と「うちの会社ではこう、という注意書き」だけ。これも私が一度失敗して足した1行です。
まとめ
- 公式の営業スキルは「英語の指示書」。プログラムは入っていない。中身を読むと、自分の業務の言葉で置き換えられることがわかる
- 公式に入っているのは案件と数字のマネジメントまで。人のマネジメント（1on1・育成・同行フォロー）は自分で作るしかない
- 汎用品に入っていないのは、自社ルールと「自分の失敗の記録」。私の運用では、ここが精度に大きく効いた
- 決めるのは自分、書くのはClaude。書式は調べなくていいが、「やらせないこと」は自分で決める
- 自動で動かした5本を数えたら、自分は状態を把握できていなかった（1本は止まっていて、1本はまだ一度も動いていなかった）。使われていないものは必要性を疑ってよい。頻度の差は、要否を判断できるまでの速さの差だった
- だから作る前に厳しく審査するより、気軽に作って定期的に棚卸しして捨てるほうが効く
- 読み取りは社内ルールと必要な範囲に限り、書き込みには関所を置く
作ったら、しばらくしてから数えてみることをおすすめします。私は数えるまで、止まっていることにすら気づいていませんでした。
私と同じ非エンジニアの、特にチームを持っている方の参考になればうれしいです。
参考にした一次情報
- anthropics/knowledge-work-plugins の sales/skills（GitHub） — 本記事でいう「公式の営業向けスキル9本」はこれです。9本の本数、それぞれの中身がテキストであること、プログラムが含まれていないことは、2026年7月25日にこのリポジトリを確認した結果です。公式のものは更新されるので、お読みになる時点で変わっている可能性があります
- 営業ツールをClaude Codeにつないでみた（MCP連携編） — 本シリーズの第2回
なお本文中の「17本のルール」「5本のうち1本が止まっていた」「日次レポートが13営業日欠けなし」といった数字は、すべて私の環境を数えた実測値です。一般的な傾向ではなく、あくまで1人の非エンジニアの運用記録として読んでください。
