この記事でわかること
- Claude Skills が「便利なテンプレート機能」ではなく業務ナレッジの再定義である理由
- 人材不足で属人化していたAI操作を組織知に変える3つの設計フェーズ
- 自社で Skills 運用を立ち上げる際の落とし穴と、その回避策
Claude Skills とは何か
Anthropic は2025年10月16日に Claude Skills を発表し、12月18日には組織横断管理機能・パートナーディレクトリに加えて Agent Skills をオープン標準として公開 しました（Anthropic Blog: Skills）。同社は Skills を 「Claude が必要なときに読み込む、指示・スクリプト・リソースを束ねたフォルダ」 と定義し、「自社のオンボーディング資料として手元の専門知識を Claude にパッケージできる」と説明しています。
Skills には、ナレッジを 「全社で標準化したいもの」と「現場が試行錯誤しながら磨くもの」を別レイヤーで管理できる 仕組みが組み込まれています（Claude Code Skills 公式ドキュメント）。統制を強めたい領域と現場の自由度を残したい領域を切り分けて運用できる構造です。
加えて Skills は Agent Skills というオープン標準として2025年12月に公開されており、他のAI Agent ツールでも読み込める設計が用意されています。社内で書いた業務ナレッジを、ベンダー切り替えに伴って丸ごと書き直す必要が出にくい構造 —— ここが本記事の最初の論点になります。
業務ナレッジの新形態としての位置づけ
AI Agent を自社に入れたとき、多くのビジネスリーダーが直面するのが「汎用のAIをそのまま使っても、自社の業務にはフィットしない」というギャップです。
たとえば請求書チェックを Claude にやらせると、汎用的な観点は返してくれます。しかし「自社の検収基準で発注書と突合する」「子会社間取引は別扱いにする」といった自社固有の手順は、毎回プロンプトで補足する必要があります。担当者は事実上、毎回「業務ナレッジを口頭で渡している」状態に近い。
Skills はこのギャップを埋めるための仕組みです。自社の業務手順・参照資料・呼び出すべき定型処理を1つのフォルダにまとめ、Claude が必要な場面で自動的に読み込みます。具体例で見るとイメージしやすいでしょう。
- 議事録要約Skill: 自社の決裁フォーマット・参加者ロール・社内用語辞書を同梱し、誰が議事録を取っても同じ書式と要約軸に揃う
- 請求書チェックSkill: 自社の検収基準を文書で定義し、突合の確定処理は同梱したスクリプトで担保。AI が文章処理、数値の確定はコードで担保する構造
- 顧客提案書ドラフトSkill: 自社の提案書フォーマット・業界別の訴求軸・過去の受注事例を同梱し、誰が書き始めても自社の型に沿った初稿が出る
ここで重要なのは、Skill の中身は プログラミングの知識がなくても、日本語の業務マニュアルを書く要領で定義できる 点です。たとえば「議事録要約Skill」を作るなら、SKILL.md というファイルに次のような自然文を書くだけで動きます。
---
name: meeting-notes-summary
description: 月次経営委員会の議事録を、自社の決裁フォーマットに沿って要約する。
決裁事項・継続審議事項・要対応アクションの3区分で整理し、社内用語を正式名称に統一する。
---
# 議事録要約の手順
## 出力フォーマット
議事録は次の3区分で整理してください。
### 1. 決裁事項
- 会議で正式に決定された事項のみを箇条書きで記載
- 各事項に「決裁日」「決裁者」「次回レビュー予定」を必ず明記
- 「検討する」「方向性として了承」は決裁事項ではなく継続審議に分類する
### 2. 継続審議事項
- 結論が出なかった論点を「論点／論点提起者／次回までの宿題」の形式で記載
### 3. 要対応アクション
- 担当者と期限が明確な作業を、「担当者・作業内容・期限」のテーブル形式で記載
## 用語ルール
- 「経営会議」は必ず「月次経営委員会」と表記
- 「DX推進部」は必ず「デジタル変革本部」と表記
- 略称を使わず、正式名称で記載
ご覧の通り、これは社員研修で配る業務マニュアルとほぼ同じ書き方です。新人に「議事録はこう書いて」と説明する文章を、そのまま Claude に渡している、と捉えると分かりやすい。自社の業務に詳しい担当者であれば、エンジニアの手を借りずに業務ナレッジを Skill 化できる —— ここが「現場で使い始められる」最大の理由です。
業務ナレッジは元々、製造現場・コールセンター・金融オペレーションのような領域で、誰が担当しても同じ品質で実行できるよう手順書・マニュアルに落とし込んできた領域です。AI Agent が業務に組み込まれる段階に入って、業務ナレッジが書き換えるべき対象が変わりました。「人間が手順を読んで実行する」ための業務ナレッジから、「Claude が手順を読み込んで業務を遂行する」ための業務ナレッジへの転換です。これは経営の語彙では、業務ナレッジの新しい形態 と読むのが妥当です。
よくある見方： Skills はプロンプトを再利用しやすくするテンプレート機能で、便利な小道具に過ぎない。
実態は： Skills は、属人化していたAI操作を「組織資産」として再利用可能にする仕組みです。これまで現場でコピペ運用されてきたプロンプトや手順は、担当者の手元に閉じた個人スキルの段階に留まっており、ベテランが退職すれば手順ごと蒸発し、若手が育つまで業務が止まる という人材不足の典型的なリスクを抱えていました。Skills は、その個人スキルを 組織のリポジトリに登録し、誰が呼び出しても同じ品質で実行され、改廃の責任所在まで設計できる単位 に引き上げます。
Skills を業務ナレッジの新形態として捉えると、自社に持ち込む際の論点は技術選定ではなく 「人材不足にどう備えるか」 という経営課題に直結します。ベテラン層の知見が暗黙のうちに失われる、採用が難しい職種で業務が止まる、引き継ぎ資料が誰にも読まれない——こうした人材不足の典型問題に対し、業務ナレッジを Skill 化して組織側に持たせる設計が、構造的な防御策になります。
人材不足を乗り越える3つの設計フェーズ
3つのフェーズで段階的に進めます。ただし、ここで重要なのは 「人がすべて手作業で進めようとすると膨大な労力がかかる」 点です。人材不足の自社で人手をさらに割けば、本来の業務が止まります。棚卸しと設計はAI Agentに手伝わせ、最後の制定・廃止の責任だけ人が担保する ——AIに業務を任せる組織への移行と同じやり方を、Skill 整備にも採用するのが現実的です。
1. 担当者の頭の中にある運用を可視化する（棚卸しフェーズ）
最初のフェーズは、特定の担当者しか回せていないAI操作を可視化することです。多くの自社では、現場のリーダーが個人の Notion ページ・スプレッドシート・社内チャットの DM にプロンプトをためている状態が常態化しています。これは「個人スキル」の段階で、退職・異動でそのまま蒸発し、人材不足の影響をそのまま受けます。
ここを人が手で拾い集めようとすると、それだけで現場の負荷が跳ね上がります。散在しているプロンプトや手順データ（個人 Notion、共有ドライブ、過去の Slack スレッドなど）を集めて Claude に渡し、業務単位の棚卸し整理を手伝わせる のが現実的です。AI が「これは請求書チェック系」「これは議事録要約系」と仕分けの叩き台を作り、現場のリーダーが「これは違う」「これも入れる」と最終判断する分担にすれば、棚卸しそのものを軽い負荷で回せます。
棚卸しの観点は3つです。
- 業務単位: 「請求書チェック」「議事録要約」「コードレビュー」のように、繰り返し発生する業務単位で集める
- 役職単位: 「営業マネージャーが顧客リサーチに使う」「経理担当者が月次締めで使う」のように、役職別の使い回しを集める
- プロジェクト単位: 「新規プロダクト開発の要件定義」「監査対応」のように、プロジェクトで一時的に共有されていたものを集める
棚卸しの目的は「Skill 候補リスト」を作ることではなく、自社のAI業務標準化がどの粒度で起きているかの地図を描くこと です。地図ができないまま Skill 化を始めると、本人が個人で使い続けた方が早いケースまで Skill 化してしまい、組織側の運用負荷だけが増えます。
2. 再利用可能な単位を切り出す（設計フェーズ）
棚卸しで地図ができたら、どの単位で Skill を切り出すかを設計します。「組織全体で使うべき資産」と「現場の試行に開く資産」を別レイヤーで配置する構造設計が必須 になります。
このフェーズも、AIに下案を作らせれば負荷が大きく下がります。棚卸し結果を Claude に渡し、「再利用可能な業務単位の候補」「全社版／部署版／個人版のドラフト」を出させる のが現実的です。最初から完璧な設計を人が描こうとすると進まないので、AI に叩き台を作らせ、現場のリーダーと運用部門が「これは全社、これは現場の試行のまま」と判断する役割分担にします。
設計時に陥りやすい論点が「業務単位で切るか、役職単位で切るか」の判断です。「請求書チェック」を業務単位で1つの Skill にすると汎用性が高いが、自社の経理業務固有のルールを織り込むと役職単位（経理担当者向け）に分けた方が制度面に合致する、というトレードオフが発生します。この種の判断も、AI に両方のドラフトを書かせて比較するやり方が効きます。
3. 制定・改訂・廃止の責任を設計する（運用フェーズ）
最後のフェーズは、内部統制への接続です。Skills を組織資産として運用するには、誰が制定するか、誰が改訂するか、誰が廃止するか の責任設計が要ります。これは Skills 固有の論点ではなく、業務ナレッジの運用論をそのまま AI Agent に当てはめる作業です。
ここはAIに任せず、人が担保するフェーズ です。制定・廃止は監査時の説明責任に直結するため、誰が判断したかを人の名前で明示する必要があります。AI に「この Skill は廃止候補」「この Skill の権限範囲は広すぎる」と提案させることはできても、最終の決裁は人の権限と署名で行う、という線引きが運用の安定性を支えます。
Skills には、各 Skill が使えるツールの範囲を事前承認しておく仕組みが用意されています。承認範囲を広げすぎれば「Skill 経由で何でもできてしまう」状態が生まれ、絞りすぎれば毎回権限承認のポップアップで現場の運用が止まります。業務ナレッジでいう「決裁権限規程」と「権限委任表」を、Skill 単位で書き直す作業 が運用フェーズの中心になります。
この段階を内部統制部門・情報システム部門だけに委ねると、Skill の改廃が止まり「使われない業務ナレッジ」と同じ結末を迎えます。逆に現場任せにすると、誰も承認していない Skill が増殖し、監査時に説明できない状態になります。制定・改訂・廃止を「現場が起案／管理側が承認」の二段構えで設計する ことが、属人化解消と統制の両立点です。
アクションチェックリスト
| アクション | 内容 |
|---|---|
| AI操作の棚卸し | 現場でコピペ運用されているプロンプト・手順を、業務単位・役職単位・プロジェクト単位で可視化する |
| Skill 配置の設計 | 組織横断で使う資産と、現場の試行に開く資産を分けて配置する構造を設計する |
| Skills 運用ルールの整備 | 制定・改訂・廃止の責任所在を、既存の業務ナレッジ運用に接続する |
人材不足で属人化していたAI操作を、組織横断で再利用できる業務ナレッジ資産に作り替える支援を提供しています。棚卸し・設計・運用ルール整備まで、自社の現状に合わせて伴走します。
あわせて読みたい
FAQ
Q: Skills と単なるプロンプトテンプレートの違いは何ですか？
プロンプトテンプレートは「文字列の使い回し」で個人の手元に閉じます。Skills は、配置場所のスコープ設計（組織横断／個人／プロジェクト／プラグイン）と、自動起動・手動起動の切り替え、ツール利用権限の事前承認、実行可能なスクリプトの同梱までを含む業務ナレッジの単位です。さらに Skills のコア部分は Agent Skills というオープン標準に準拠しており、Claude Code 固有の拡張機能を避けて設計すれば、他のAI Agent ツールでも読み込めるため、ベンダー切り替え時の書き直しコストを構造的に下げられます。
Q: Skills の運用を始めるとき、最初に揃えるべき社内体制は何ですか？
業務ナレッジの所管部門（多くは業務改善・情報システム・内部統制のいずれか）が、Skill の制定・改訂・廃止の流れを既存の業務ナレッジ運用に接続する役割を担うのが妥当です。これに加えて、現場側で「Skill オーナー」を業務単位・役職単位で配置し、改廃の起案責任を持たせます。最初から完璧な体制を組まず、棚卸しフェーズで見えた優先業務3つ程度に絞って試行する ことが、運用が空転しない起点になります。
Q: Skills を組み込むと、現場の AI Agent 活用が止まりませんか？
統制を強くしすぎると確かに止まります。逆に統制を全くかけないと、属人化が組織横断に拡散するだけで業務ナレッジとして機能しません。両立の鍵は「現場が自由に書き込める個人・プロジェクトスコープと、組織が制定する組織横断スコープを分ける」という階層設計です。Skills のスコープ構造はこの両立のために用意されており、現場の自由度と組織の統制を別レイヤーで管理できる構造 になっています。