シリーズ： Claudeで変わる仕事術 中級・第1弾 ／ 前回：番外編 「うまく使えない」の正体——AI選びとイメージの伝え方

初級編では、Claudeを使って仕事を前に進める感覚をつかんだ。 Chatで考えてもらう。 Coworkで作業してもらう。 Claude Codeでファイルを作る。 MCPで外部ツールとつなぐ。 最後は、提案書もExcelも英語資料もまとめて片付けた。

ここまで来ると、次に出てくる悩みはこれだ。

「毎回、同じ説明をしている気がする」

たとえば、記事をレビューしてもらうたびに、

• 読者はAI初心者
• 文章はやさしく
• 専門用語はかみ砕く
• 煽りすぎない
• 最後は実務に戻す

と説明する。

週報を作るときも、議事録をまとめるときも、提案書を直すときも同じ。

「前にも言ったよね」と思いながら、また同じ条件を書く。

中級編は、ここから始める。

うまく頼むだけではなく、うまくいった頼み方を"仕事の型"として残す。

そのための道具が、SKILLSだ。

1. SKILLとは何か

初級編は、Claudeに「やってもらう」シリーズだった。

中級編は、Claudeが動きやすい「仕組みを作る」シリーズにする。

Skillとは、Claudeに渡す「仕事の手順書」だ。

ただのプロンプトではない。 毎回の作業で使う前提、流れ、チェック観点、出力形式をまとめたもの。

人間で言えば、

「この仕事は、うちではこう進めてください」

と書いた業務マニュアルに近い。

2. Prompt・CLAUDE.md・Skillの違い

ここは最初に整理しておきたい。

それぞれ、AIが読むタイミングも違う。

PromptとCLAUDE.mdは、Claudeが必ず全文読む。 だから、長くなりすぎるとコンテキストを圧迫する。 特にCLAUDE.mdは毎回読まれるので、書きすぎに注意が必要だ。

Skillだけが必要なときだけ、必要な分だけ読む仕組みになっている。 だから、いくつ登録してもClaudeが重くならない。

もう少し日常の言葉にすると、こうだ。

Promptは「今日これをやって」。

CLAUDE.mdは「この職場では、基本的にこう働いて」。

Skillは「この種類の仕事は、この手順で進めて」。

たとえば、FamilyAIの記事をレビューしてもらう場合。

単発なら、Promptでいい。

この記事を読んで、AI初心者の読者に伝わりにくい部分を指摘してください。

でも、毎週記事を書くなら、それだけでは足りない。

毎回、読者像、文体、避けたい表現、見出しの粒度、レビュー観点を説明することになる。

それなら、記事レビュー用のSkillにしておく。

FamilyAIの記事レビューでは、以下を確認する。

- 読者はAI初心者の子育て中の親
- 専門用語はかみ砕く
- 便利さだけでなく、仕事や生活でどう使うかに戻す
- 煽りすぎた表現は弱める
- 最後に「今日から試せる一歩」を入れる

こうしておけば、次からは、

この記事をFamilyAI記事レビューのSkillで見て。

に近い頼み方で済む。

毎回の説明が減る。 しかも、仕上がりのブレも減る。

3. Skillに向いている仕事と、最初の3つ

何でもSkillにすればいいわけではない。

Skillに向いているのは、次のような仕事だ。

逆に、Skillにしなくていい仕事もある。

3回同じ説明をしたら、Skill化を考える。

1回目はPromptで試す。 2回目で条件を整える。 3回目で「これは型にできる」と判断する。

このくらいの軽さでいい。

最初に作るSkillは、この3つがおすすめだ。

① 議事録整理Skill

会議メモを入れると、決定事項・未決事項・担当者・アクション・期限に整理してくれるSkill。効果が分かりやすく、会議のたびに使える。

② 週報作成Skill

今週やったことを箇条書きで渡すと、成果・進行中・困っていること・来週やることに整えてくれるSkill。上司向け、チーム向け、自分用でトーンを変えてもいい。

③ 記事レビューSkill

下書きを渡すと、読者への伝わり方・見出し・具体例・表現・行動につながるかを確認してくれるSkill。継続的に発信する人には特に向いている。

今回のハンズオンでは、この「記事レビューSkill」を例にする。

4. 🛠️ 記事レビューSkillを作る

Skillの置き場所

まず、どこに置くかを決める。

Globalに入れすぎないことが大事だ。

GlobalのSkillは起動時にすべてのdescriptionが読まれる。 数が増えると、似た用途のSkillが競合して誤起動しやすくなる。 自分でも何があるか分からなくなる。

実用的な目安は、Globalは5〜10個まで。

迷ったらProjectに置く。「これは確実にどこでも使う」と確認できてからGlobalへ移す。

Claude Codeへの頼み方

Claude Codeに、まずこう頼む。

FamilyAIの記事レビュー用のSkillを作りたいです。

目的：
- AI初心者向けの記事を、読みやすく実務に役立つ形に整える

読者：
- AI初心者
- 子育て中の親
- 副業や起業に興味がある人

レビュー観点：
- 専門用語が難しすぎないか
- 具体例があるか
- 読者が今日から試せる行動につながるか
- 煽りすぎた表現になっていないか
- AIっぽい言い回しが残っていないか

出力形式：
- 良い点
- 直した方がいい点
- 見出しごとの改善案
- 最後に、修正版の導入文を1案

この内容をもとに、Claude Codeで使えるSkillの設計案を作ってください。

ここで見るべきなのは、仕事の流れが自分の実際の作業に合っているかだ。

1つの仕事に絞ること。

記事レビューSkillにSEO・SNS投稿・画像指示・誤字チェック・タイトル10案を全部入れたくなる気持ちは分かる。でも最初のSkillとしては重すぎる。型が大きすぎると、何をするためのSkillなのか分からなくなる。

たたき台

実際のSkillファイルはこんな形になる。

---
name: familyai-article-review
description: FamilyAI向けの記事下書きをレビューするときに使う。「記事レビュー」「下書き確認」「FamilyAI記事チェック」などと言われたら起動する。
---

# FamilyAI記事レビュー

## 使う場面

ユーザーが記事の下書きを渡し、
FamilyAI向けに読みやすくしたいときに使う。

## 確認すること

- 読者はAI初心者として読めるか
- 専門用語が説明なしで出ていないか
- 具体例があるか
- 煽りすぎた表現になっていないか
- 最後に読者が試せる一歩があるか

## やらないこと

- 記事全体を勝手に全面書き換えしない
- 読者を不安にさせる煽り表現を使わない
- 事実確認が必要な内容を断定しない

## 出力

1. 良い点
2. 直した方がいい点
3. 見出しごとの改善案
4. 修正版の導入文を1案
5. 公開前に人間が確認すべき点

これくらいで始めてよい。

Claude Codeに「この内容をClaude Codeで使えるSkill形式に整えてください」と頼めば、frontmatterも含めて整えてくれる。

実際の呼び出し方

Skillを作ったら、descriptionに書いたトリガー言葉で話しかけるだけだ。

この下書きを記事レビューして

FamilyAI記事チェックをお願いします

これだけでSkillが起動する。「どのSkillを使って」と明示しなくていい。 もし起動しない場合は、descriptionにそのトリガー言葉を追加すると解決することが多い。

使う前と使った後

Skillを作る前（毎回プロンプトで説明する）

この記事を読んで、改善点を教えてください。
読者はAI初心者の子育て中の親です。
専門用語はかみ砕いてください。
便利さだけでなく、実務に戻してください。
煽りすぎた表現は弱めてください。
良い点、直す点、導入文の改善案を出してください。
（毎回これを書く）

Skillを作った後（一言で呼び出せる）

この下書きを記事レビューして

指示の中身は同じ。でも、説明は0行になる。 しかも、Skillは毎回同じ観点で動くのでレビューの品質もブレない。

5. 良いSkillの条件

① 入口がはっきりしている

どんなときに使うSkillなのかが明確。

記事の下書きをレビューしたいときに使う

のように、使う場面が一言で言える。

② 出力形式が決まっている

毎回、同じ形で返ってくる。

1. 良い点
2. 直した方がいい点
3. 見出しごとの改善案
4. 修正版の導入文

のように決めておくと、読みやすい。

③ やらないことも書いてある

Claudeは、親切に広げてくれる。 でも、広げすぎると困ることがある。

だから、やらないことも書く。

- 記事全体を書き換えない
- 断定的すぎる表現にしない
- 読者を不安にさせる煽り表現は使わない
- 事実確認が必要な情報は「要確認」と明記する

「してほしいこと」と「しないでほしいこと」の両方を書く。

④ 人間の確認ポイントが残っている

Skillを作ったからといって、全部自動で正解になるわけではない。

だから、最後に確認ポイントを残す。

最後に、公開前に人間が確認すべき点を3つ挙げてください。

この一文があるだけで、使いやすさが変わる。

descriptionが一番大事な理由

Claude Codeは、Skillを3段階で読んでいる。

起動時はまず全Skillのdescriptionだけをざっと読む。 「この仕事に合いそうか」を判断して、合うものを選ぶ。 本文は、選ばれたSkillだけを読む。

だから、Skillをたくさん登録してもClaudeが重くならない。

ただし、トリガーの判断はキーワード一致ではなく意味が近いかどうかで判断される。

descriptionには、「いつ使うか」を、自分が実際に話しかける言葉で書くと精度が上がる。ここが曖昧だと、Skillを作っても呼び出されないことがある。

6. 使いながら育てる

Skillは、作って終わりではない。使いながら育てるものだ。

たとえば、記事レビューSkillを何度か使っていると、こう感じるかもしれない。

「毎回、タイトルの指摘が弱い」

そう思ったら、レビュー観点に追加する。

タイトルは、読者の悩みが入っているかを確認する。
ただし、過度に煽る表現にはしない。

「修正文が少し硬い」と感じたら、トーンを追加する。

修正文は、友人に説明するような自然なです・ます調にする。

「指摘が多すぎて読むのがつらい」と感じたら、出力形式を変える。

改善点は重要度順に最大5つまでに絞る。

毎回Promptを直すのではなく、Skillを直す。これが中級編の考え方だ。

Skill化する前のチェックリスト

まとめ

Claude Codeを使っていると、つい「次は何ができるか」に目が向く。

でも、中級で大事なのは、機能を増やすことだけではない。

一度うまくいった仕事を、次も同じ品質でできるようにすること。

その最初の一歩が、Skillだ。

次回は、AIにファイルを触らせるうえで避けて通れないテーマに進む。

Gitを怖がらずにAIと進める方法。

差分を見る。 小さくコミットする。 戻せる状態にしてから、AIに任せる。

Claude Codeを仕事に組み込むなら、ここからが本番だ。