Claudeでフィードバックスキルを作る｜10ペアから始めるskill.mdの書き方

レビューや添削の仕事をAIに任せようとして、途中で手が止まった経験はないでしょうか。私も何度かあります。「自分がどうやって指摘しているか」を手順書として書き出そうとすると、3行目くらいで止まるのです。

止まる理由ははっきりしています。レビューは手順ではなく判断でできているからです。手順書に書けるのは「まず全体を読む」までで、その先の「この提案書のここが引っかかった」は条件と結論の形になっていません。だから書けません。

ところが、書けないものを集める方法はあります。過去に自分がやったレビューの、対象物と実際に返したフィードバックをペアで10組並べる方法です。判断そのものは言語化できなくても、判断の入口と出口なら手元に残っています。あとはその10組をClaudeに読ませて、共通する傾向を抜き出してもらえば、自分のレビュー観の仕様書ができあがります。

この手順の面白いところは、職種が変わっても同じ形で回ることです。顧客への提案書レビュー、コードレビュー、契約書チェック、企画スライドの添削、論文の査読。この5つは対象物も専門知識もまるで違いますが、「対象物を読む、観点で照らす、指摘を書く」という3工程はまったく同じです。だから同じ7ステップでスキルにできます。

この記事では、10ペアの集め方から、傾向を抽出するプロンプト、完成したSKILL.mdの実物、そして職種ごとに追加すべき観点までを順番に扱います。あわせて、契約書レビューにおける弁護士法72条、査読における研究助成機関のポリシー、顧客資料を扱うときの個人情報保護法の注意点といった、技術記事ではあまり触れられない「越えてはいけない線」も同じ表に載せます。ここを知らないままスキルを配ると、便利さより先に事故が来ます。

読み終えたら、自分の実務データを10組そろえるところから着手できるはずです。

レビューという仕事は、手順書ではなく判断でできている

レビュー業務をスキルにするとき、手順書を書こうとすると失敗します。理由は、レビューが手順ではなく判断でできているからです。この章では、判断そのものではなく「判断の入口と出口」を10組集めて逆算するという発想に切り替えます。この10組が、以降の全ステップの材料になります。

「自分のやり方を書き出す」で手が止まる理由

Claudeにレビューを任せたいと思ったとき、たいていの人はまず手順書を書こうとします。私も最初はそうでした。テキストエディタを開いて、こう書き始めます。

1. 提案書を最初から最後まで読む
2. 気になったところに印をつける
3. 指摘を書く

3行目で止まります。「気になったところ」とは何なのか、自分でも説明できないからです。実際にレビューしているときは1秒で「これは根拠が弱い」と判断しているのに、その判断がどんな条件でどう働いているのかは、意識に上がってきません。

これは能力の問題ではありません。どうやら、熟練した判断ほど手続きとして意識されなくなるようです。自転車に乗れる人が「どうやってバランスを取っているか」を説明できないのと同じ構造だと思います。認知心理学ではこの状態を暗黙知と呼びます。持っているけれど、言葉として取り出せない知識のことです。

つまり、レビューをスキルにしようとして手が止まるのは、取り出せない場所から取り出そうとしているからです。ここを変えます。

判断は取り出せなくても、入口と出口は残っている

自分の判断そのものは言語化できません。しかし、判断の入口と出口なら、すでに手元にあります。

• 入口: レビューした対象物（提案書、プルリクエスト、契約書ドラフト、スライド、論文原稿）
• 出口: 実際に返したフィードバック（メール、Slack、コメント、赤入れ、査読コメント）

この2つを1組にして、10組そろえます。判断のプロセスは空白のままですが、入口と出口が10組あれば、その空白に何が入っていたかは推測できます。推測する作業は、Claudeがかなり得意な部類の仕事です。

言い換えると、こうなります。手順書を書こうとするのは「自分の頭の中を内省で取り出す」アプローチです。10ペアを並べるのは「自分の過去の行動を証拠として並べ、そこから規則性を逆算する」アプローチです。後者のほうが、圧倒的に楽で、しかも精度が出ます。

この発想は私の思いつきではなく、Anthropic公式のスキル作成支援スキル（skill-creator）にも同じ考え方が入っています。このスキルは、ユーザーが「これをスキルにして」と言ったとき、まず会話履歴から「使ったツール、手順の順序、ユーザーが入れた修正、観測された入出力フォーマット」を抽出せよ、と指示しています。手順を聞き出すのではなく、残っている痕跡から逆算する設計です。

なぜ10ペアなのか、そして10という数字の正直な位置づけ

先に断っておくと、10という数字に厳密な根拠はありません。私の経験則です。ここを誇張しても読者の役に立たないので、根拠のある部分とない部分を分けて書きます。

根拠がある部分は、公式ドキュメントが推奨する評価の作り方です。Anthropicのスキル作成ベストプラクティスは、「広範なドキュメントを書く前に評価を作れ」（Create evaluations BEFORE writing extensive documentation）とした上で、最低3つのシナリオを用意することを勧めています。つまり、公式が明言しているのは「3つの評価」であって「10のサンプル」ではありません。

では、10という数字はどこから来たのでしょうか。実務で試した範囲では、次のような感覚があります。

• 3〜4組: 傾向は出るが、たまたまその案件に固有だった観点を「いつもの観点」と誤認しやすい
• 10組前後: 「毎回言っていること」と「そのときだけ言ったこと」が分離しはじめる
• 20組以上: 精度は上がるが、集める手間が急に重くなり、着手しないまま終わる

要するに10は、精度と着手しやすさの折り合いがつく点です。5組しか集まらないなら5組で始めても構いません。始めないより、粗くても回したほうが早く良くなる気がします。

集める10組の中身は、バラつかせるほど良い

同じ種類の案件を10組集めると、その種類にだけ効くスキルになります。避けたいのは「たまたま同じ業界の提案書ばかり10本」という状態です。次の3軸でばらつかせると、後の抽出がうまくいきます。

1. 対象の性質: 業界、規模、技術スタック、契約類型など、対象物そのものの違い
2. 出来の良し悪し: よく書けていたもの、平凡なもの、大きく直したものを混ぜる
3. 結論の向き: 承認したもの、条件付きのもの、差し戻したものを混ぜる

とくに3番目が効きます。褒めたケースが1件も入っていないと、抽出されるのは「粗探しの観点」だけになり、できあがったスキルが何を出しても厳しいことしか言わなくなります。厳しい指摘しか返さないスキルは、実務で使うとかなり邪魔になります。

ここまでが発想の転換です。次は、この考え方が職種をまたいで成立することを確認します。

提案書もコードも契約書も、フィードバックとしては同じ形をしている

顧客提案書、コードレビュー、契約書チェック、スライド添削、論文査読。この5つは対象物も必要な専門知識もまるで違いますが、「読む、観点で照らす、書く」という3工程は共通です。この章では5事例を1枚の表に並べて、自分の業務がどこに当てはまるかを確認します。

5つの仕事を並べて見る

レビュー業務と一口に言っても、扱う対象はまったく違います。コンサルタントが見るのは事業計画で、エンジニアが見るのはコードの差分です。専門知識は共有できません。

それでも、仕事の形は同じです。5つ並べてみます。

事例	インプット（読むもの）	アウトプット（返すもの）	スキル化で効くところ	既製の専用ツール
顧客提案書・事業案レビュー	提案書、企画書、事業計画（スライドやPDF）	改善点、想定リスク、確認したい質問リスト、追加調査の提案	シニアのレビュー観点を若手が使える	ほぼ存在しない
コードレビュー	プルリクエスト、コミット差分	バグの指摘、可読性、性能、セキュリティ、命名規約	自チーム固有の規約と過去の指摘を載せられる	多数（GitHub Copilot code review、CodeRabbit ほか）
契約書・法務ドキュメント	契約書ドラフト、秘密保持契約書、業務委託契約書	リスク指摘、修正案、自社ひな形との条項比較	過去の修正パターンの再現、一次チェックの分担	多数（LegalOn Cloud、GVA assist、MNTSQ ほか）
資料・スライドレビュー	企画書、報告書、社内提案スライド	論理の飛躍、データ根拠の不足、見出しの弱さ	上長の目線を先回りで当てられる	ほぼ存在しない
論文・研究レビュー	論文ドラフト、研究計画書、学会発表要旨	論理構成、先行研究の引用、実験設計、統計処理の指摘	属人的な査読観点の継承	一部（投稿前チェック系）

対象物も専門性もばらばらですが、工程を抽象化すると3つに収束します。

1. 対象物を読んで、構造を把握する
2. 自分が持っている観点のリストで、その構造を照らす
3. 引っかかったところを、相手に伝わる形で書く

このうち2番目が、その人固有の資産です。1番目と3番目は、モデルがもともと得意です。つまりスキルに書くべきなのは、ほとんど2番目だけになります。ここが分かると、SKILL.mdに何を書いて何を書かないかの判断がぐっと楽になるのではないでしょうか。

既製ツールがある領域と、ない領域

上の表を見ると、コードレビューと契約書レビューには専用ツールが揃っていて、提案書レビューとスライドレビューにはほぼ何もありません。この差は、対象物のフォーマットが機械可読かどうかで決まっています。差分も契約書も構造が安定しているので、製品として成立します。一方、事業案のスライドは会社ごとに形式がばらばらで、製品化しにくいのです。

では専用ツールがある領域では自作スキルに意味がないかというと、そうでもありません。役割が違います。

• 既製ツール: 業界共通の観点を、網羅的に、毎回同じ品質で当てる
• 自作スキル: 自分たちの規約、過去に指摘したこと、この顧客特有の事情を当てる

たとえばコードレビューなら、SQLインジェクションやnull安全のような一般的な観点は既製ツールに任せたほうが速くて確実です。一方で「うちのプロジェクトでは日時は必ずUTCで保持して表示層で変換する」といった規約は、外部のツールは知りません。ここが自作の出番になります。両方使って構いませんし、実際そのほうが効きます。

公式ドキュメントも、コードレビューを「自由度の高い仕事」に分類している

Anthropicのスキル作成ベストプラクティスには、スキルに持たせる自由度（degrees of freedom）を3段階で設計せよ、という指針があります。

• 自由度が高い場合: 複数のやり方が正しく、文脈で判断が変わる。テキストの指示で書く
• 自由度が中くらい: 望ましい型があるが、多少の変化は許容される。パラメータ付きの手順で書く
• 自由度が低い場合: 手順が壊れやすく、順序を間違えると事故る。固定コマンドを指定する

この文書のなかで、自由度が高い側の例として挙げられているのがコードレビューです。挙げられている手順も「構造を分析する、バグや境界条件を確認する、可読性の改善を提案する、プロジェクトの慣習に沿っているか確かめる」という、ゆるい書き方になっています。

公式が使っている比喩がわかりやすいので紹介します。両側が崖の細い橋を渡るような仕事なら、通る場所を1センチ単位で指定するべきです。障害物のない野原を歩くような仕事なら、方角だけ伝えて任せたほうが良い結果になります。レビューは後者です。指摘の観点は渡しますが、どう組み立てるかは任せます。ここを間違えて手順を細かく縛ると、想定していた指摘しか出てこない、融通の利かないスキルができあがります。

つまり5事例のうち、データベース移行のような「低自由度」に該当するものは1つもありません。全部が野原側です。5事例が全部そちら側であることには実利があって、プログラムを書かなくても、マークダウンのテキストだけでスキルが完成します。

次の章から、実際に手を動かす部分に入ります。

ステップ0〜4｜判断の材料を10ペア集めて、並べる

ここからが実作業です。全7ステップのうち、この章では準備にあたる0から4までを扱います。作業時間の目安は、10ペアで2〜3時間といったところです。地味ですが、ここの質がそのまま完成品の質になります。

ステップ0: 先にメモリーを切って、匿名化の方針を決める

手を動かす前に、必ず先にやることがあります。顧客の資料や社内の非公開文書を扱うので、順序を逆にすると取り返しがつきません。

やることは2つです。

1つ目は、Claudeのメモリー機能を切ることです。Claudeアプリの設定から、チャットの記憶と過去会話の参照をオフにします。メモリーがオンのままだと、顧客Aの提案書の内容が、後日まったく別の会話にこっそり混ざる可能性があります。この挙動は「モデルが学習した」わけではなく、保存された内容が次回の入力に足されているだけなのですが、情報が混ざるという結果は同じです。仕組みの詳しい話はClaudeのメモリーは「学習」ではないで3層モデルとして整理しているので、社内で説明が必要な場合はそちらを参照してください。

2つ目は、匿名化の方針を先に決めることです。個人情報保護委員会が2023年6月2日に出した生成AIサービスの利用に関する注意喚起は、事業者が個人情報を含むプロンプトを入力する場合、特定された利用目的の達成に必要な範囲内かを十分に確認することを求めています。さらに、本人の同意なく個人データを含むプロンプトを入力し、それが「応答結果の出力以外の目的で取り扱われる場合」には法違反となる可能性がある、としています。

実務的にいちばん安全なのは、そもそも個人データを入れないことです。次のように機械的に置換します。

株式会社◯◯ → A社
田中部長 → 担当者B
2,400万円 → 金額X
2026年3月末 → 期日Y
自社製品名 → 製品P

置換の対応表は手元のテキストファイルに残し、Claudeには渡しません。この置換をやっておくと、後で同僚にスキルを配るときにも、元データを一緒に配れるようになります。

なお、Claude Codeのスキルはローカルのファイルなので、ファイル自体が外に出るわけではありません。ただし実行時の会話はAPIを通ります。

もうひとつ知っておいたほうがよいのは、Anthropicの公式ドキュメントが「Agent SkillsはZDR（Zero Data Retention：やり取りしたデータをAI提供側に残さない契約）の対象外」と明記している点です。原文は “Agent Skills is not covered by ZDR arrangements.” で、スキルの定義と実行データは通常のデータ保持ポリシーに従って保存される、と続きます。ZDR契約を結んでいる会社の担当者ほど、ここは誤解しやすいので確認しておくとよいでしょう。

ステップ1: 10組を選ぶ

過去のレビュー履歴から10組を選びます。選定基準は前の章で書いた3軸（対象の性質、出来の良し悪し、結論の向き）です。

選ぶときのコツをひとつ挙げます。「自分が良いレビューをした」と思う案件だけを選ばないことです。急いでいて雑になった回や、後から見返して指摘が的外れだった回も混ぜます。理由は、そういう回にこそ「自分が何を優先して何を捨てているか」が出るからです。丁寧にやった回だけを集めると、実際には毎回できていない理想像がスキルになり、使うたびに現実との差でストレスが溜まります。

ステップ2: インプットをテキストにする

対象物がスライドやPDFの場合、テキストに起こします。Claudeに投げるだけですが、指示にひとつ条件を足すと後が楽になります。

添付の提案書をテキストに書き起こしてください。条件は3つです。

1. スライドの順番と見出し階層は元のまま保つ
2. 図表やグラフは、見た目の説明ではなく「そこで何を主張しているか」を書く
   （例:「棒グラフ」ではなく「導入企業数が3年で4倍になったと主張するグラフ」）
3. 数値と固有名詞は、私が渡す置換ルールに従って置き換える

置換ルール:
株式会社◯◯ → A社 / 田中部長 → 担当者B / 金額はすべて 金額X

2番目の条件が肝心です。レビューで引っかかるのはたいてい「グラフの主張と本文の結論がずれている」といった内容の問題であって、グラフの種類ではありません。見た目だけ書き起こすと、その情報が抜け落ちます。

コードレビューの場合は、差分そのものがテキストなのでこの工程は省略できます。ただし、差分だけでは判断の文脈が失われるので、プルリクエストの説明文と、関連する課題管理チケットも一緒に保存しておきます。

ステップ3: アウトプットをテキストにする

実際に返したフィードバックを集めます。メールの本文、Slackのスレッド、ドキュメントのコメント、会議で口頭で伝えた内容のメモ、赤入れしたファイル。形式はばらばらでかまいません。

ひとつ推奨があります。インプットとは別のセッションで作業することです。理由は単純で、片方のセッションに両方の生データを置くと、後で「どちらのセッションに顧客名の生データが残っているか」を追いにくくなるからです。作業を分ければ、片付けも分けられます。

口頭で伝えた内容しか残っていない場合は、記憶で書き起こして構いません。正確な再現より、「どういう観点で何を言ったか」が残っていることのほうが重要です。

ステップ4: 1対1で並べて保存する

集めたものを、対応がわかる形で保存します。

feedback-skill-data/
├── case001_input.md
├── case001_feedback.md
├── case002_input.md
├── case002_feedback.md
├── ...
├── case010_input.md
├── case010_feedback.md
└── replacement-table.md   ← 置換の対応表。Claudeには渡さない

連番でそろえておくと、後で「3番のケースの指摘がうまく反映されていない」といった会話ができます。日付や案件名をファイル名にすると、それ自体が顧客情報になってしまうので避けます。

ファイルの先頭に、1行だけメモを足しておくと後の抽出精度が上がります。

<!-- case003_feedback.md -->
結論: 条件付き承認 / レビュー時間: 約40分 / 相手: 初回提案の外部パートナー

（以下、実際に返したフィードバック本文）

結論の向きとレビューにかけた時間が入っていると、「重い指摘をするときと軽く流すときの境目」までClaudeが拾えるようになります。手順書を書こうとしていたら、この種類の情報は出てこなかったはずです。

ここまでで材料がそろいました。次はいよいよ抽出です。

ステップ5〜6｜傾向を抜き出して、SKILL.mdに落とす

ここが山場です。集めた10ペアをClaudeに読ませて傾向を抽出し、その結果をSKILL.mdという1枚のファイルに落とします。実際に使うプロンプトと、できあがるファイルの実物を載せます。あわせて、公式ドキュメントが定めている制約（nameは64文字以内、descriptionは1,024文字以内、本文は500行以内）も確認します。

ステップ5: 10ペアから傾向を抽出する

材料をすべて添付して、次のように頼みます。

添付は、私が過去に行ったレビューの記録です。case001からcase010まで、
それぞれ input（レビュー対象）と feedback（私が返した指摘）が対になっています。

この10ペアを読んで、私のフィードバックの傾向と特徴を抽出してください。
次の5点に分けて出力してください。

1. 頻出する指摘の観点（何回出てきたかも添えて）
2. 観点どうしの優先順位（複数見つかったとき、私が先に書いているのはどれか）
3. 指摘の書き方の型（切り出し方、根拠の示し方、代替案を出すかどうか）
4. 私が意図的に指摘していないこと（気づいていそうなのに触れていない領域）
5. 使わない言い回し、避けている表現

推測が入る部分は「推測」と明示してください。
10ペア中1回しか現れていない観点は、頻出とは分けて書いてください。

最後の2行が効きます。これを入れないと、たまたま1回出ただけの観点まで「あなたの特徴です」と自信たっぷりに返ってきます。回数を書かせておけば、こちらで取捨選択できます。

4番目の「指摘していないこと」は、思ったより価値があります。たとえば提案書レビューで、誤字脱字に一度も触れていないなら、それは見落としではなく「そこは自分の仕事ではない」という判断です。この情報がスキルに入ると、出力のノイズが目に見えて減ります。

返ってきた結果は、そのまま信じない

抽出結果を受け取ったら、3点だけ自分で確認します。ここを飛ばすと、もっともらしいが自分のものではない観点が混ざったまま固定化します。

1. 挙がった観点のうち、「言われてみればそうだ」と思えるものはいくつあるか。ゼロなら材料が足りていない可能性が高い
2. 逆に、自分では大事だと思っているのに挙がっていない観点はないか。あれば、その観点が出るケースが10ペアに含まれていなかったということなので、1件追加する
3. 優先順位の記述が、実際の自分の感覚と合っているか

3番目がずれることは、わりとよくあります。「セキュリティを最優先している」と抽出されたが、実際は「レビュー時間が長い案件だけそうしていた」というような場合です。気づいたら、その条件を明示して伝え直します。

ステップ6: SKILL.mdに落とす

確認が終わったら、そのまま同じ会話でスキル化を頼みます。

この特徴を再現するスキルを SKILL.md 形式で作ってください。条件は次のとおりです。

- frontmatter は name と description のみ。name は動名詞形で、小文字英数字とハイフンのみ
- description は三人称で書き、「何をするか」と「どんなときに使うか」の両方を入れる
- 本文は 500 行以内。長くなる部分は別ファイルに分ける前提で、SKILL.md からリンクする
- 観点は箇条書きで並べ、手順として細かく縛らない
- 出力フォーマットのテンプレートを含める
- 私が避けている言い回しは、禁止事項として明記する

Anthropicのドキュメントには「Claudeはスキルの形式をもともと理解しているので、特別なシステムプロンプトや『スキルを書くためのスキル』は必要ない」と書かれています。実際、上の指示だけで整った形が返ってきます。

出てくるものは、だいたい次のような形です。提案書レビューの例で示します。

---
name: reviewing-client-proposals
description: 顧客の提案書・事業計画をレビューし、改善点・想定リスク・確認質問を指摘としてまとめます。提案書、企画書、事業計画、ピッチ資料のレビューや壁打ちを依頼されたとき、あるいは「この提案どう思う」と相談されたときに必ず使ってください。
---

# 顧客提案書レビュー

## レビューの観点（優先順に確認する）

1. 収益の前提: 単価と数量の根拠が、外部データか実績のどちらに紐づいているか
2. 想定顧客の解像度: 「誰が、どんな場面で、いくら払うか」が1文で言えるか
3. 実行体制: 提案内容に対して、実行する人員と期間が釣り合っているか
4. 競合の扱い: 競合を挙げているか、そして差分が機能ではなく顧客価値で語られているか
5. 撤退条件: うまくいかなかった場合の判断基準が書かれているか

観点1と2で問題が見つかった場合、それ以降の指摘は補足として扱います。
土台が崩れているときに枝葉の指摘を並べても、相手が動けないためです。

## 指摘しないこと

- 誤字脱字、体裁の崩れ（別の担当が見ます）
- デザインの好み
- 金額の妥当性そのもの（根拠の有無だけを見て、金額の是非は判断しません）

## 出力フォーマット

### まず結論
承認 / 条件付き / 差し戻し のいずれかと、その理由を2〜3文で。

### 直したほうがよい点
最大5件。各件を次の形で書きます。
- 該当箇所（引用）
- 何が問題か
- どう直すと良くなるか（代替案を必ず1つ出す）

### 確認したい質問
相手に聞かないと判断できない点。最大3件。

### よく書けている点
1〜2件。ここは省略しません。

## 書き方の決まり

- 断定を避けた表現（〜かもしれません、〜の可能性があります）は、
  推測であることを明示したいときだけ使います
- 「必ず」「絶対に」は使いません
- 相手の努力を否定する言い方をしません。事実と影響だけを書きます

このくらいの分量で十分に機能します。長く書けば良くなるものではありません。

公式仕様として押さえておく5点

ここで、公式ドキュメントに書かれている制約を確認しておきます。知らずに書くと、動くけれど起動しないスキルができあがります。

第一に、frontmatter（ファイル冒頭の --- で挟まれた設定欄。日本語ではフロントマターと呼びます）で必須なのは name と description の2つだけです。name は最大64文字、小文字の英数字とハイフンのみ、XMLタグは使えず、予約語である “anthropic” と “claude” は含められません。description は空にできず、最大1,024文字です。

第二に、description の書き方が起動精度をほぼ決めます。公式は「必ず三人称で書く」と明記しています。良い例として「Excelファイルを処理してレポートを生成します」にあたる書き方（原文：”Processes Excel files and generates reports”）が、避けるべき例として「私がExcelファイルの処理をお手伝いします」にあたる書き方（原文：”I can help you process Excel files”）が挙げられています。descriptionはシステムプロンプト、つまりClaudeが会話の前提として常に読んでいる指示文に差し込まれるため、人称がずれると発見の妨げになる、という理由です。

第三に、description には「何をするか」と「いつ使うか」の両方を書きます。Claudeは100個を超えるスキルのなかから1つを選ぶので、選択の材料はここにしかありません。Anthropic公式のskill-creatorには、この点について率直な記述があります。「現在のClaudeにはスキルを過小起動する傾向がある。使ったほうがよい場面でも使わない。これに対抗するため、スキルの説明は少し押しつけがましく書いてほしい」という趣旨です。実際、上のサンプルで末尾に「必ず使ってください」と入れているのはこの理由からです。

第四に、SKILL.mdの本文は500行以内に収めます。公式は、最適な性能を出すには本文を500行未満に保つこと、と書いています（原文：”Keep SKILL.md body under 500 lines for optimal performance”）。超える場合は別ファイルに分けて、SKILL.mdからリンクします。このとき参照は1階層までにします。SKILL.mdから advanced.md、advanced.md から details.md といった多段の参照にすると、Claudeが head -100 のような部分読みで済ませてしまい、内容が欠けたまま進むことがあるためです。

第五に、なぜ500行なのかは、読み込みの仕組みを知ると納得できます。ここで出てくるトークンとは、AIが文章を処理するときの単位のことで、日本語なら1文字あたり1個前後と考えておけば十分です。公式が示している3層の構造は次のとおりです。

層	読み込まれるタイミング	トークンの消費	中身
メタデータ	常時（起動時）	スキル1つあたり約100トークン	frontmatterの name と description
本文	そのスキルが起動したとき	5,000トークン未満	SKILL.mdの本文
同梱ファイル	必要になったとき	読むまでゼロ	参照ファイルやスクリプト

つまり、スキルを100個入れておいても常時のコストは1万トークン程度で、実際に使うものだけが本文を読み込みます。この設計のおかげで「たくさん作っても重くならない」わけですが、逆に言えば起動した1個の本文は確実に文脈を占有します。だから本文は短いほうがよい、という話です。

なお、簡潔さを重視する考え方は、Claude 5世代のモデルではさらに強まっています。細かいルールを列挙するより判断の余地を残したほうが結果が良くなる、という変化についてはClaude Opus 5とコンテキストエンジニアリング新ルールで扱っています。レビュー用スキルはその典型で、観点だけ渡して組み立ては任せるほうが、指摘の質が上がります。

どこに置くか

Claude Codeで使う場合、置き場所は2つです。

• ~/.claude/skills/reviewing-client-proposals/SKILL.md は個人用で、すべてのプロジェクトで有効になります
• .claude/skills/reviewing-client-proposals/SKILL.md はプロジェクト用で、そのリポジトリでのみ有効になります

チームで共有するコードレビュー用スキルなら後者、自分の提案書レビュー観点なら前者、という使い分けになります。ディレクトリ名がそのままコマンド名になるので、/reviewing-client-proposals で直接呼び出せます。ファイルの追加や編集はセッションを再起動しなくても反映されます。

claude.aiのウェブ版で使いたい場合は、ディレクトリをzipにまとめて設定画面からアップロードします。ここでひとつ注意があります。公式ドキュメントは、カスタムスキルは面をまたいで同期しないと明記しています（原文：”Custom Skills do not sync across surfaces”）。claude.aiに上げたものはAPI側には現れませんし、Claude Codeのファイルはその両方と別管理です。同じスキルを3か所で使いたければ、3か所に置く必要があります。

職種ごとに足す観点と、越えてはいけない線

7ステップは共通ですが、職種ごとに足すべきものと、事前に確認すべき外部ルールがあります。ここを飛ばすと、便利さより先に問題が来ます。

職種別のカスタマイズ表

事例	一緒に置く参照ファイル	追加で書く観点	先に確認する外部ルール
顧客提案書レビュー	自社の提案フォーマット、過去の失注理由メモ	提案の前提と顧客の意思決定プロセスの噛み合い	秘密保持契約の範囲、個人情報保護委員会の注意喚起
コードレビュー	コーディング規約、アーキテクチャ決定記録、過去の障害報告	自チームの命名規則、性能要件の閾値、依存追加の判断基準	社内のソースコード外部送信ポリシー
契約書レビュー	自社ひな形、過去の修正履歴、譲れない条項の一覧	自社が飲めない条項の線引き、業界慣行との差	弁護士法72条と法務省ガイドライン
資料・スライドレビュー	社内テンプレート、過去に承認された資料の実例	想定読者の階層、決裁に必要な情報の粒度	特になし
論文・研究レビュー	投稿先の投稿規程、分野の報告ガイドライン	統計手法の前提確認、先行研究の網羅性	投稿先・助成機関の生成AI利用ポリシー

参照ファイルは、SKILL.mdと同じディレクトリに置いてリンクします。この構成にしておくと、本文を短く保ったまま、必要なときだけ規約や過去事例が読み込まれます。前の章で見た3層構造の3層目にあたる部分で、読み込まれるまでトークンを消費しません。

reviewing-pull-requests/
├── SKILL.md              ← 観点と出力フォーマット。ここだけ起動時に読まれる
├── coding-standards.md   ← 命名規則と禁止パターン
├── past-incidents.md     ← 過去の障害と、そのとき見落とした観点
└── perf-thresholds.md    ← 性能要件の数値

契約書レビュー: 弁護士法72条をどう考えるか

契約書レビューのスキルを作るとき、必ず話題になるのが弁護士法72条（非弁行為の禁止）です。ここは正確に押さえておく価値があります。

経緯を簡単に整理します。2022年6月と10月、AI契約書レビューサービスについてグレーゾーン解消制度を使った照会がなされ、法務省は「弁護士法第72条本文に違反すると評価される可能性がある」との回答を出しました。この回答が業界に波紋を広げ、その後2023年8月1日に、法務省大臣官房司法法制部がAI等を用いた契約書等関連業務支援サービスの提供と弁護士法第72条との関係についてというガイドラインを公表しています。

ガイドラインが示した枠組みは、72条違反が成立するには5つの要件がすべてそろう必要がある、というものです。要件は「弁護士または弁護士法人ではない者が」「報酬を得る目的で」「訴訟事件その他一般の法律事件に関して」「鑑定その他の法律事務を行い」「業とすること」です。

このうち実務上の分かれ目になるのが3番目の「事件性」です。ガイドラインは、訴訟や行政庁への不服申立てに準ずる程度に権利義務について争いや疑義があるかどうかを基準に置き、そのうえで「通常の業務に伴う契約の締結に向けての通常の話合いや法的問題点の検討については、多くの場合『事件性』がない」と整理しています。また、弁護士が自分の業務をサポートするツールとして使う場合は、通常72条違反にはならないとされています。

自作スキルの文脈に引き寄せて考えてみます。自社の法務担当者が、自社が締結する契約書を自分でチェックするためにスキルを使う場合、この使い方は「報酬を得る目的で」「業とする」のどちらにも当たらないので、通常は問題になりません。一方、他社の契約書レビューを請け負って対価を得る形にすると、話が変わってきます。ここは自己判断せず、一次情報にあたるか、社内の法務・顧問弁護士に確認してください。規制改革の議論の経緯は、AI・契約レビューテクノロジー協会が規制改革推進会議に提出した資料にまとまっています。

論文査読: 投稿先と助成機関のポリシーが先

学術系はもっとはっきりしています。米国国立衛生研究所（NIH）は2023年6月23日の通知NOT-OD-23-149で、査読者が生成AIツールを使うことを全面的に禁止しました。「査読者はNIHの助成申請書およびR&D契約提案書を分析・批評するためにAIツールを使うことを禁じられる」という内容で、理由は守秘義務です。AIツールはデータがどこへ送られ、保存され、閲覧され、将来どう使われるかの保証がない、という説明が付いています。

出版社ごとの方針は分かれていて、支援的な用途なら認めるところもあれば、NIHのように例外なしのところもあります。出版社ポリシーの比較のようなまとめが公開されているので、投稿先や査読を引き受ける機関の規程を先に読むのが確実です。

ここで線引きをはっきりさせておきます。禁止されているのは、他人の未公開原稿を評価するためにAIを使うことです。自分が書いた原稿を、自分で投稿前に点検する用途は、この制約に当たりません。むしろ査読で指摘されがちな観点をスキルにしておくと、投稿前の自己点検はかなり楽になります。研究室で先輩が後輩の原稿を見るときの観点をスキル化する、といった使い方も同様に問題になりにくい領域です。作るときは「誰の原稿を、誰の権限で見るか」を先に確定させてください。

顧客資料: 匿名化を前処理として設計に組み込む

顧客の提案書や事業計画を扱う場合、前の章で触れた個人情報保護委員会の注意喚起が効いてきます。ポイントは、本人の同意なく個人データを含むプロンプトを入力し、それが応答結果の出力以外の目的で扱われる場合には法違反の可能性がある、とされている点です。裏返すと、「機械学習に使われないことを十分に確認する」ことが求められています。

現実的な対処は2段構えです。契約面では、利用しているプランのデータ利用条件を確認し、必要ならエンタープライズ契約を検討します。運用面では、そもそも個人データを入れない設計にします。ステップ0で決めた置換ルールを、スキル本体にも書き込んでおくと徹底しやすくなります。

## 前提

このスキルに渡される資料は、事前に匿名化されているものとします。
実名・実社名・実金額が含まれていることに気づいた場合は、
レビューを始める前にその旨を指摘してください。

こう書いておくと、匿名化を忘れて投げたときにClaude側が止めてくれます。人間の運用ルールだけに頼るより確実です。

なお、スキル自体の安全性も確認しておく価値があります。公式ドキュメントは「信頼できる提供元のスキルだけを使う」と明記し、とくに外部URLからデータを取ってくるスキルはリスクが高いと注意しています。取得した内容に悪意ある指示が含まれる可能性があるためです。他人が公開しているスキルをそのまま社内に入れる前には、SKILL.mdと同梱ファイルを一通り読む習慣をつけてください。この種のガバナンスを誰が持つのかという話は、情シスが遅い会社と進む会社の分岐点でも扱っています。

ステップ7｜使いながら直す、配る、ほかのツールでも動かす

スキルは作った時点が完成ではありません。ここからが本番です。

微妙だったところを、具体的に伝え直す

使ってみると、たいてい何かがずれます。指摘が細かすぎる、優先順位が違う、褒めるところが機械的、といった具合です。そのとき、スキルを直接編集するより、Claudeに直してもらうほうが速いです。伝え方に型があります。

このスキルを使ってレビューしたところ、次の点が微妙でした。

- 状況: 3人チームの小規模な提案書に対して使った
- 出た出力: 実行体制の指摘が5件中3件を占めた
- 期待していたこと: 規模が小さい案件では体制の指摘は1件にまとめたい
- 理由: 小規模案件では体制が薄いのは前提で、指摘しても打ち手がない

この観点が反映されるようにスキルを改善してください。

「微妙でした、直してください」だけだと、ふわっとした修正が返ってきます。状況、出た出力、期待、理由の4点を書くと、狙ったところが直ります。この4点は、そのまま自分が部下にフィードバックするときの型でもあります。同じことをスキルにやっているだけです。

書く担当と使う担当を分ける

Anthropicのベストプラクティスに、面白い進め方が書かれています。スキルを改善する相手のClaude（文書では Claude A と呼ばれています）と、実際にそのスキルを使って仕事をするClaude（Claude B）を分ける、という方法です。

流れはこうです。まずClaude Aにスキルを書いてもらいます。次に別のセッションで、そのスキルを読み込ませたClaude Bに実際の仕事をさせます。Claude Bの振る舞いを観察して、うまくいかなかった点をClaude Aに持ち帰り、Aに直してもらいます。直したものを、またBで試します。

なぜ分けるかというと、書いた本人のセッションで試すと、会話の文脈が効いてしまって「スキルの記述だけで動いたのか」が判定できないからです。ドキュメントには、Claude Aからの改善提案として「always filter よりも MUST filter のような強い言い方にする」「ルールをもっと目立つ位置に移す」といった具体例が挙がっています。

観察するときの着眼点も示されています。次の4つを見ると、構造の問題が見つかります。

• 予想外の順序でファイルを読んでいないか
• 参照したはずのファイルを読み飛ばしていないか
• いつも同じファイルばかり読んでいないか（それならSKILL.md本体に書くべき内容です）
• まったくアクセスされないファイルがないか

評価を先に作る

もうひとつ、公式が強く推している進め方があります。「広範なドキュメントを書く前に評価を作れ」というものです。手順は次の5段階です。

1. スキルなしで代表的なタスクをやらせ、どこで失敗するかを記録する
2. その失敗を突くシナリオを3つ作る
3. スキルなしの状態を基準として測っておく
4. 基準を超えるのに必要な最小限の指示だけを書く
5. 実行して比べ、直す

レビュー業務に翻訳すると、こうなります。まず、スキルを入れずに素のClaudeに提案書を1本レビューさせます。出てきたものと、自分が実際に書いたフィードバックを比べます。差がどこにあるかを3つ挙げます。その3つが埋まるまでスキルを書いて、それ以上は書きません。

ここで注意したいのが、レビューの出力は主観的なので、機械的な合否判定になじまないことです。skill-creatorにもその区別が書かれていて、ファイル変換やデータ抽出のように客観的に検証できる出力はテストケースの恩恵が大きく、文章のスタイルのように主観的な出力はテストケースが必要ないことが多い、とされています。フィードバックスキルは後者寄りです。数値で測ろうとせず、10ペアのうち3件を手元に残しておいて、そこに対する出力を自分の目で見比べるくらいが現実的です。

配る、そして他のツールで動かす

SKILL.mdはただのマークダウンファイルです。だから配れます。Gitのリポジトリに入れても、社内のドキュメント基盤に置いても、zipで渡してもかまいません。どれでも動きます。この「ファイルなので配れる」性質が、社内展開のときにいちばん効きます。

配布まわりで知っておくべき制約が2つあります。

1つ目は、前の章でも触れた面をまたいだ同期がないことです。claude.aiにアップロードしたスキルはAPI側には現れませんし、Claude Codeのファイルはその両方と別です。共有の範囲も違い、claude.aiは個人単位、APIはワークスペース全体、Claude Codeは個人かプロジェクトかプラグインという分かれ方をします。

2つ目は、フォーマットが特定のツールに閉じていないことです。Claude CodeのSkillsはAgent Skillsというオープン標準に準拠していて、この標準は複数のAIツールで動くことを前提にしています。

標準そのものは「SKILL.mdを含むディレクトリ」という最小限の定義しか持ちません。だからfrontmatterを name と description の2つに絞っておけば、移植で困る場面はほとんどありません。逆に、allowed-tools（そのスキルが使えるツールの事前承認）や context: fork（別プロセスで隔離実行する指定）といったClaude Code固有の拡張を使うと、その部分は他ツールで無視されます。移植を前提にするなら、標準の範囲で書いておくのが安全です。

実務では、Claude Code以外のコーディングエージェントや、MCP（Model Context Protocol：AIが外部ツールとやり取りするための共通規格）に対応したツールに同じファイルを置いて動かす形が増えています。試すときは、まず観点の箇条書きと出力フォーマットだけの最小構成で動かしてみて、ツール固有の記法が必要になったら足す、という順序が失敗しにくいです。

スキルが個人の資産から組織の資産に変わるとき

最後に、少し先の話をします。

フィードバックスキルは、作った本人にとっては単なる時短ツールです。しかし同じ職場で3人がそれぞれ自分のレビュー観をスキルにすると、性質が変わります。3人の観点の差分が、初めて目に見える形になるからです。「Aさんは撤退条件を必ず見ているが、Bさんは見ていない」といったことが、ファイルの差分として現れます。

ここまで来ると、議論の対象が「誰のレビューが正しいか」ではなく「うちのチームとして何を必ず見るか」に移ります。属人化の解消の本質は、こういう順序にあるのではないでしょうか。マニュアルを先に作って配るのではなく、各自の判断を先に見える化して、そこから共通部分を抜き出します。この順番が逆になっているせいで形骸化しているマニュアルを、私は何度か見たことがあります。

一方で、他人が作ったスキルをそのまま使わされると、人はあまり使いません。自分で少し手を入れる余地が残っているほうが定着します。この現象と、組織展開で何を設計すべきかは別の記事で扱う予定です。あわせて、スキルをどう積み上げて再利用可能な構造にするかという設計論も、稿を改めて書きます。

なお、職種を特化させた形で判断ルールを抽出する具体例としては、AI Skillsでコピーライターの判断ルール抽出で、コピーライティング業務に絞った実装を扱っています。この記事の7ステップを、1職種の中でどこまで深掘りできるかの参考になるはずです。

私たちDeskrexが開発しているSnorbeは、ナレッジグラフに記憶を積み上げながら、複数のエージェントが自律的に調べて考えるリサーチAIです。レビューの観点を1人分スキルにするところから、複数のスキルを組み合わせて調査や分析まで一気に回すところへ進みたくなったとき、新しい選択肢になります。フィードバックスキルのような「判断の型」を、個人の手元ではなく組織単位で回すための土台として使ってみてください。

よくある質問

実際に手を動かした人からよく出る質問を、7つにまとめました。

Q1. 10ペアも用意できません。少ない数でも作れますか

作れます。3〜5組でも傾向は出ます。ただし、そのときは「たまたまその案件に固有だった観点」が混ざりやすいので、抽出結果を受け取ったら「これは本当に毎回言っていることか」を1件ずつ自分で確認してください。数が少ないほど、確認の手間は増えます。実務では、まず5組で作って使いはじめ、違和感が出るたびに1組ずつ足していく進め方が現実的です。

Q2. SKILL.mdとCLAUDE.mdは、どう使い分ければよいですか

CLAUDE.mdは常に読み込まれるので、書いた内容は毎回コンテキストを消費します。スキルの本文は、そのスキルが起動したときだけ読み込まれます。だから、常に守ってほしい短い事実や制約はCLAUDE.mdに、特定の作業のときだけ必要な長い手順や観点はスキルに置く、という分け方になります。Anthropicのドキュメントも「CLAUDE.mdの一節が事実ではなく手順に育ってきたら、スキルにする頃合い」という趣旨の説明をしています。レビュー観点は手順側にあたるので、スキルが向いています。

Q3. スキルを作ったのに、Claudeが自動で使ってくれません

ほとんどの場合、原因は description です。公式のskill-creatorにも「現在のClaudeにはスキルを過小起動する傾向がある」と明記されていて、対策として説明文を少し押しつけがましく書くことが推奨されています。「何をするか」だけでなく「どんな言葉が出てきたら使うか」を具体的に並べてください。たとえば「提案書、企画書、事業計画、ピッチ資料のレビューを依頼されたとき、あるいは『この提案どう思う』と相談されたときに必ず使ってください」といった書き方です。それでも起動しない場合は、/スキル名 で直接呼び出せます。

Q4. 顧客の資料を使ってスキルを作るのは、法律上問題ありませんか

匿名化を前提にしてください。個人情報保護委員会が2023年6月2日に公表した注意喚起は、本人の同意なく個人データを含むプロンプトを入力し、それが応答結果の出力以外の目的で扱われる場合には法違反となる可能性があるとしています。会社名・人名・金額・固有の製品名を機械的に置換してから作業すれば、この論点自体を回避できます。加えて、AnthropicのドキュメントはAgent SkillsがZDR（ゼロデータ保持）契約の対象外であることを明記しているので、ZDRを結んでいる会社も別途の確認が必要です。秘密保持契約の条項も、AI利用に触れているかを確認してください。

Q5. 契約書レビューのスキルを作るのは、弁護士法に触れませんか

自社の法務担当者が自社の契約書を自分でチェックする用途であれば、通常は問題になりません。弁護士法72条の違反成立には5つの要件がすべてそろう必要があり、そのなかに「報酬を得る目的で」と「業とすること」が含まれるためです。2023年8月1日に法務省が公表したガイドラインは、通常の業務に伴う契約締結に向けた話合いや法的問題点の検討には多くの場合「事件性」がないと整理しています。ただし、他社の契約書レビューを請け負って対価を得る形にすると判断が変わる可能性があります。事業として提供する場合は、必ず顧問弁護士に確認してください。

Q6. できたスキルは、Claude以外のツールでも動きますか

frontmatterを name と description の2つに絞っておけば、多くの場合そのまま動きます。Claude CodeのSkillsはAgent Skillsというオープン標準に準拠していて、この標準は「SKILL.mdを含むディレクトリ」という最小限の定義しか持ちません。中身はただのマークダウンなので、他のコーディングエージェントやMCP対応ツールに置いても解釈されます。ただし allowed-tools や context: fork のようなClaude Code固有の拡張は、他のツールでは無視されます。移植を前提にするなら、最初から標準の範囲で書いておくと安全です。

Q7. 既製のAIレビューツールがあるのに、自作する意味はありますか

役割が違います。既製ツールは業界共通の観点を網羅的に、毎回同じ品質で当てるのが得意です。自作スキルが担うのは、自分たちの規約、過去に指摘したこと、この顧客特有の事情といった、外部のツールが知りようのない部分です。コードレビューであれば、一般的な脆弱性の検出は既製ツールに任せ、「この案件では日時をUTCで保持する」といったプロジェクト固有の規約を自作スキルで見る、という併用が現実的です。どちらかを選ぶ問題ではありません。

この記事で参照した一次情報

本文中の仕様・数値・法令解釈は、次の資料を確認して書いています。2026年7月時点の内容です。

• Anthropic「Agent Skills」概要（3層のトークンコスト、frontmatterの制約、サーフェス間の非同期、ZDRの適用外）: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Anthropic「Skill authoring best practices」（500行ルール、descriptionの書き方、自由度の設計、評価駆動開発、Claude A/Bパターン）: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
• Claude Code ドキュメント「Extend Claude with skills」（配置場所、コマンド名の決まり方、追加のfrontmatter）: https://code.claude.com/docs/en/skills
• anthropics/skills リポジトリ（公開スキル17個、skill-creatorの実装）: https://github.com/anthropics/skills
• Anthropic Engineering「Equipping agents for the real world with Agent Skills」: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• Agent Skills 仕様（オープン標準）: https://agentskills.io/specification
• NIH「The Use of Generative Artificial Intelligence Technologies is Prohibited for the NIH Peer Review Process」NOT-OD-23-149: https://grants.nih.gov/grants/guide/notice-files/NOT-OD-23-149.html
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）: https://www.ppc.go.jp/files/pdf/230602_kouhou_houdou.pdf
• JIIMA「AI契約関連業務支援サービスと弁護士法72条について」（法務省ガイドラインの解説）: https://www.jiima.or.jp/im/im_bn/ai-contract-support-law72
• AI・契約レビューテクノロジー協会「契約自動レビューシステムと弁護士法72条に関して」（規制改革推進会議提出資料）: https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/2210_01startup/221111/startup02_01.pdf