中小企業診断士・ITコーディネータの大澤真介です。
合同会社オンザウェイの代表をしています。
「”やりたい”を”できている”に変える実装支援」をテーマに、中小企業のご支援に取り組んでいます。
8ヶ月前、研究会で紹介していた運用
2025年8月、私は中小企業診断士の研究会で、Claudeのプロジェクト機能の活用方法を紹介していました。
そのとき推していたのが、「プロジェクトの共通指示を作成するプロジェクト」という、ちょっとややこしい運用でした。
Claudeにはプロジェクトという機能があり、プロジェクトごとに「共通指示」と呼ばれる役割設定を書き込めます。一度書いておけば、そのプロジェクト内のすべての会話に同じ役割が適用される。便利な機能です。
現在は、ChatGPTにもGemini（個人向け）にも同様の機能がありますが、当時はClaudeだけに実装されている機能でした。
この一連のチャットの流れの集約とプロジェクト内やり取りにだけ適用されるカスタム可能な共通指示というのが、当時私がClaudeを最優先して利用していた理由の一つでした。
ただ、この共通指示を書くこと自体が難しい。何を書けば良いのか、どこまで書けば良いのか、迷う方が多い。
そこで私は、「共通指示を上手に書くClaude」をプロジェクトとして用意しておく運用を提案していました。
新しいプロジェクトを立ち上げるとき、まずそのプロジェクトに相談すると、ヒアリングをしてくれて、最適な共通指示を生成してくれる。
生成された指示文を、新しいプロジェクトの「共通指示」欄にコピペして使う、という流れです。
同じ思想で、私は他にも「役割プロジェクト」をいくつか用意していました。
note記事を書くプロジェクト
自己PRや公募書類を作るプロジェクト
議事録を作るプロジェクト
そして、それぞれの「案件プロジェクト」が別にある。
つまり、私のClaudeのプロジェクト一覧は、役割プロジェクトと案件プロジェクトの2階建てになっていたわけです。当時はこれが最適解だと思っていました。
3ヶ月後、Anthropic自身が新しい設計を出してきた
ところが2025年11月、状況が変わりました。
Anthropic（Claudeを開発している会社）が、Skillsという新しい仕組みを発表したんです。
そして同月、Anthropic公式ブログに「Skills explained: How Skills compares to prompts, Projects, MCP, and subagents」という記事が出ました。プロジェクトとSkillsの違いを明確に説明したものです。
その記事の中に、私の運用を直接書き換える一文がありました。
If you find yourself copying the same instructions across multiple Projects, that’s a signal to create a skill instead.
引用元: Skills explained | Claude
（複数のProjectで同じ指示をコピペしていることに気づいたら、それはSkillを作るべきサインです）
「役割プロジェクト」というのは、まさにこの「同じ指示を複数のProjectで使い回したい」という発想の解決策でした。
私が研究会で紹介した「プロジェクト共通指示を作成するプロジェクト」、
これも、同じ役割を別のProjectに移植するための仕組みです。
公式の言い方をそのまま借りるなら、これらは全部「Skillsを作るべきサイン」だった、ということになります。
正直、最初に読んだときは少し動揺しました。研究会で紹介した運用が、3ヶ月で旧式になった。
ただ、Anthropic公式の説明を読み込んでいくうちに、これは設計が変わったというより、そもそもプロジェクトが担うべきでなかった役割を、Skillsという新しい層が引き取ったのだと整理できました。
公式の定義を整理するとこうなります。
Projectsは「ナレッジと文脈の置き場」。特定の案件・テーマに紐づく素材と会話履歴を入れる場所。
Skillsは「やり方の定義」。会社のブランドガイドライン、議事録の作り方、コードレビューの手順など、Claudeがどう動くべきかを記述したもの。
「役割」はSkillsで定義する。「案件」はProjectsで管理する。これが2026年現在のAnthropicが推奨する設計です。
移行は3ヶ月前から始めていた
実は、Skillsへの移行は今回が初めてではありません。
2026年1月、私は「Claude『Skills（Agent Skills）』の使いどころを見極める」という記事を書きました。そのときに、「プロンプト工場」と呼んでいた最初のひとつ──プロジェクトの共通指示を作成する運用──を、Skillsに移行したことを報告しています。
当時はそこで一旦止まっていました。他の役割プロジェクト（note記事、自己PR、議事録）については、まだProjectのまま運用していたんです。
その記事の最後に、私はこう書いていました。
一度「Skillsに向いていない」と判断しても、ワークフローを見直すことで判断が変わることもあります。
https://note.com/genial_canna9391/n/n22024add80e2
今回の記事は、まさにこの結論を自分自身で実証した話です。1月の時点では「これはProjectで残す」と判断していたものが、3ヶ月使っているうちに「やっぱりSkillsに移したほうがいい」と思える瞬間が来た。
ちなみに、1月の記事では「これはSkillsにしない」と判断していたものも、その後Skillsに切り出しました。
ひとつは、厳密な文字数調整プロセスです。Pythonで3段階に文字数を合わせていく手順を、`strict-character-count`というスキルにしました。
当時は「他の作業と組み合わせて使うから、パーソナライズ設定に置いておきたい」と書いていました。
でも、実際に運用していると、文字数を厳密に合わせたい場面は限定的です。発動するときに発動してくれれば十分でした。
もうひとつは、2in1形式PDFという特殊なファイルを解析する処理。
これも`binary-file-handler`というスキルに切り出しました。
当時は「発動の確実性が心配」と書いていましたが、実際には発動条件さえ明確に書いておけば、必要な場面で、ほぼ確実に動きます。
両方とも、パーソナライズ設定から外せたので、設定全体が軽くなりました。これも、1月の記事の結論で書いた「ワークフローを見直すことで判断が変わる」の実例です。
私の3つの役割プロジェクトを、Skillsに移行した
8ヶ月かけて、研究会で紹介したものを含めて「役割プロジェクト」を、最終的にすべてSkillsに置き換えました。
1月に移したプロンプト工場（`project-instruction-generator`）に加えて、残りの3つもこの3ヶ月で移行しています。
① note記事を書くプロジェクト → `note-article-oozawa` スキル
このnote記事を書くために使っているスキルです。プロジェクトに書いていた指示文を、SKILL.mdというファイル形式に整理し直しました。冒頭はこんな構成です。
---
name: note-article-oozawa
description: 大澤真介（中小企業診断士/ITコーディネータ）のnote記事作成スキル。
「note記事を書いて」「ブログ記事を作成して」「noteの下書きを作って」など
のリクエスト時に使用。中小企業・小規模企業向けのIT/生成AI活用をテーマと
した記事を、大澤さんの文体・スタイルで作成する。
---
# note記事作成スキル（大澤真介）descriptionに発火条件を書いておくと、私が「note記事を書きたい」と話しかけたときに、Claudeが自動でこのスキルを読みに行ってくれる。プロジェクトに入っていなくても起動する。これが大きい。
私は自社開発も含めて案件単位のプロジェクトを作成していますが、そのプロジェクト内のやり取りをしながら「この内容、noteに書きたいな」と思った時に、特別な準備を必要とせずnoteの記事作成に入ることができます。
② 自己PR・公募書類を作るプロジェクト → `profile-detail-prompter` スキル
公募申込書、セミナーの自己紹介、プレスリリース。固有情報の正確さが命の文書を書くときに動くスキルです。発動キーワードはこう設計しています。
このスキルは、私の詳細プロフィールファイルのアップロードを促し、固有情報の事実確認プロセスまで含めて動きます。プロジェクトに入っていたときは、案件プロジェクトに毎回最新のプロフィールファイルを再アップロードしていました。
③ 議事録を作るプロジェクト → `meeting-minutes` スキル
会議の書き起こしから議事録を生成するスキルです。中身の一部を引用します。
## 執筆ルール（最重要）
### 1. 事実記録の原則
- 記録するもの: 実際に発言・共有された内容のみ
- 記録しないもの: 推測、解釈、議事録作成者の意見
- 不明確な点は「確認が必要」と明記する
- 「〜と思われる」「〜の可能性がある」等の推測表現は使わない案件ごとに別プロジェクトを使うので、「議事録の作り方」をスキルとして外に出しておかないと、毎回同じ指示を書き直す羽目になる。
当初、議事録作成という「役割プロジェクト」を使っていましたが、そのプロジェクトに必要なコンテキストを毎回アップロードする必要があり、徐々に使わなくなっていました。
改めて、`project-instruction-generator`の話を
研究会で紹介していた、あの再帰的な運用。1月の記事では「Project Instructionsを作成して」のトリガーで動かす、という運用を紹介しました。中身の一部を見せます。
### Step 2: 提案型ヒアリング
重要な原則:
- ナレッジから読み取れることは聞かない
- 0ベースで質問しない
- 自分の分析結果を述べた上で、選択肢を提示する研究会で紹介していたときは、「専用プロジェクトを作って、新規プロジェクトの設計を相談する」という運用でした。今は、どのプロジェクトにいても、関連ファイルをアップロードしたうえで、まず最初に「このプロジェクトの共通指示を作って」と話しかけるだけで、このスキルが起動して、ナレッジを分析し、選択肢付きでヒアリングしてくれて、その結果を元に最適な共通指示を作成してくれます。
また、プロジェクトが進行していく中で共通指示の内容を柔軟に書き換えることも「このセッションでのやり取りを踏まえて、共通指示の更新を提案して」と書くことで、新しい共通指示を作成してくれます。
専用プロジェクトに入る必要すらなくなりました。これは8ヶ月前の私が想像していなかった世界です。
2026年4月、私のClaudeはこう設計されている
ここまで書いてきた話を整理します。今のClaudeは、設計の場所が3つに分かれています。
8ヶ月前の私は、1階と3階の2階建てで運用していました。1階の個人設定で「私は中小企業診断士です」を伝え、3階のプロジェクトに役割と案件を全部突っ込んでいた。
でも、3階に役割を書くのは無理がありました。
同じ役割を複数の案件で使いたいときに、コピペするしかない。
修正するときは全プロジェクトを開いて共通指示を直すか、役割プロジェクトを作り直す。
これが「役割プロジェクト」を別建てにする運用に発展した理由です。
2階のSkillsができたことで、役割が住むべき場所が決まりました。役割は2階。案件は3階。設定の重複が消えました。
経営者がClaudeを始めるとき、どこから手を付けるか
ここから先は、これからClaudeを使い始める経営者の方への提案です。
先日の記事で、私は「経営者ほど最上位プランを1ヶ月だけ試してほしい」と書きました。実際に試し始めた方からよく聞かれるのが、「で、何から設定すれば良いんですか」という質問です。
おすすめの順番はこうです。
最初に、1階のパーソナライズ設定を書く。
自分が何者で、誰に向けて話していて、どんな判断軸を持っているか。これを書いておくと、すべての会話の質が変わります。3行でも構いません。私の場合は「中小企業診断士・ITコーディネータ」「中小企業の実装支援が仕事」「リユース業20年の経験」あたりを最初に入れました。
具体的な書き方や、私の実際の設定を見たい方は、3月に書いたパーソナライズ設定の記事を読んでみてください。設定例も載せています。
次に、繰り返しやる作業をSkillsにする。
メールの下書き、議事録の整理、提案書の構成チェック。月に何度か同じ指示を出している作業があれば、それは2階に上げる候補です。
ただ、Skillsを最初から自分で書くのは難しい。Anthropicの公式が、ブランドガイドラインのテンプレートなど、すぐ使えるSkillsを公開しています。「Anthropic公式Skillsライブラリ」で見つかります。まずそこを覗いて、自分の業務に近いものを試すところから始めるのが現実的です。
ちなみに、Skillsを作るためのSkill自体も、Anthropicは公式に出しています。`skill-creator`というスキルで、ヒアリングしながら設計を支援してくれる、いわばSkillの作成パートナーです（GitHubで公開されています）。
私の場合は、もう少しシンプルな運用になるように、独自の「スキル作成Skills」も作っています。
ただ、こうした専用ツールを使わなくても、最初の草稿は対話の中で生まれます。
Claudeとよくやっているやり取りに、最後一言「このやり取りをSkillにして」と添えるだけで、SKILL.mdの草稿ができてくる。完璧じゃなくていい。後から手直しすればいいんです。
最初の1個は、対話の中から生まれる。これがいちばん身近な始め方です。
Skillsにすべきもの・しなくて良いものの判断基準は、1月のSkills記事に書いています。あわせて読むと迷いが減ると思います。
3階のProjectsは、案件が始まったときに作る。
「補助金申請のご支援」「来月のセミナー準備」「〇〇社向け業務改善」など、明確な目的と期間がある仕事に対して用意します。役割をここに書く必要はもうありません。
3階建てを意識するだけで、設計のミスが激減します。
ちなみに、Skillsはもう”Claudeだけの話”ではなくなった
1月のSkills記事で、私はAgent Skillsがオープンスタンダードとして公開されたことに触れました。その時点で、Microsoft（VS Code、GitHub）やCursor、Gooseなどが対応を始めていました。
それから3ヶ月。2026年4月現在、状況はさらに進んでいます。ChatGPTを運営するOpenAIもCodexでSkillsを採用、GoogleのGemini CLIも対応、JetBrainsのJunie、Block GooseやAmp、OpenCode──各種の集計によれば、30を超えるAIツールが同じSkills仕様に対応しています。
これは、Anthropicが2024年にMCP（Model Context Protocol）でやったのと同じ戦略の二度目です。「自社専用の囲い込み」ではなく「業界全体の共通基盤」にすることで、競争領域をモデル性能の勝負に移す。
今回も同じパターンで、わずか3ヶ月で業界標準として定着しつつあります。
中小企業の経営者にとって、これは何を意味するか。
今、自社の業務に合わせて作るSkillは、Claudeでしか動かないノウハウではなく、業界標準として作る資産になりつつあるということです。
仮に半年後に別のAIツールに乗り換えるとしても、Skillsという形で残しておけば、そのまま持っていける可能性が高い。
これは、私が今Skillsへの移行を急いでいる理由のひとつでもあります。
まとめ：8ヶ月で運用が変わる世界で仕事をしている
8ヶ月前の自分が研究会で紹介していた運用を、今の自分はもう使っていません。
これは恥ずかしい話ではなく、ツールがそれだけ速く進化しているという事実です。
完璧な設計を待っていたら、永遠に動き出せません。
私は2025年8月の段階の最善で動き、2026年1月で一部を更新し、2026年4月でまた書き換えました。来月にはまた書き換えているかもしれません。
ただ、3階建ての構造そのものは、もう少し長く有効だと思っています。
パーソナライズ設定で「自分」を、Skillsで「やり方」を、Projectsで「案件」を扱う。
この役割分担はAnthropic自身が公式に整理した設計なので、しばらく根本から変わることはないでしょう。
8ヶ月前の自分の運用を、今の自分が更新する。
それを記事にして発信する。
走りながら更新していくのが、AI時代の発信の作法だと思っています。
この記事で紹介したSkillsは、すべて自分の業務のために自分で作ったものです。
別の言い方をすれば、自分の仕事のやり方を、Claudeに渡す業務マニュアルにしたということです。
新人に渡すマニュアルと、考え方は同じ。
違うのは、相手が24時間動くClaudeで、しかもそのマニュアルは業界標準として、ツールを乗り換えても使える資産になりつつあること。
「同じ指示を毎回書いている」「複数のプロジェクトに同じ役割を貼り付けている」と感じている方は、それがSkillsを作るタイミングです。
一緒に最初のSkillsを作りませんか？
この記事はnoteでも公開しています。
実装支援・DX推進・生成AI活用のご相談は、お気軽にお問い合わせください。
→ お問い合わせはこちらから