株式会社TIMEWELLの濱本 隆太です。
この記事の要点を先に書いておきます。**Claude Codeは「エンジニア向けのコーディングツール」ではなく、手順を書いて渡せば実行してくれる作業環境です。**組織で使ううえで鍵になるのは、Skills（手順書）、Hooks（強制力のある自動処理）、Subagents（作業を切り出す専門役）の3つ。そして2026年8月現在、設定は階層化され、プラグインとして社内配布もできます。つまり「個人が勝手に使う便利ツール」で終わらせず、チームの資産にする道具立ては揃っています。
難しいのはツールの操作ではありません。自社の仕事のどれを手順書に落とし、どのルールを強制にするかを決めるところです。そこだけは誰かが決めないと進みません。
この記事は2026年2月に公開したものを、2026年8月にAnthropicの公式ドキュメントで全面的に確認し直して書き直しています。初版には現在の仕様と食い違う記述がいくつかあったため、該当箇所は本文中で明示的に訂正しました。
Claude Codeとは何か
Claude Codeは、Anthropicが提供するコマンドライン上で動くAIエージェントです。ターミナル、デスクトップアプリ、Webアプリ、VS CodeやJetBrainsの拡張機能として動きます。
ブラウザのチャットとの決定的な違いは、あなたのファイルとコマンドに直接触れることです。チャットは文章を返すだけですが、Claude Codeはファイルを読み書きし、コマンドを実行し、Webを調べ、その結果を見てまた次の手を打ちます。
この性質のため、用途はコーディングに限りません。決まった手順のある知的作業なら、だいたい任せられます。議事録から報告書のドラフトを起こす、フォルダ内の資料を横断して整合性を確認する、Excelの束から集計表を作る。実際、当社ではコラム記事の品質チェックや、社内資料の表記ゆれ検出をClaude Codeに任せています。
なお2026年8月時点の最新モデルはClaude 5系（Opus 5、Sonnet 5）とHaiku 4.5です。初版執筆時から世代が変わっているため、モデル名を見かけたら日付を確認してください。この分野は半年で常識が変わります。
鍵になる3つの機能
Skills：作業手順を「教科書」としてAIに渡す
Skillsは、特定の作業手順を書いたMarkdownファイルです。.claude/skills/ の下に、スキル名のフォルダを作り、その中に SKILL.md を置きます1。
.claude/
skills/
proposal-writing/
SKILL.md
SKILL.md の冒頭には、そのスキルが何をするものかを1行で書いた description を置きます。Claudeはこの説明文だけを常時読んでおき、関連する作業が来たときに初めて本文を読み込みます。これを漸進的開示（progressive disclosure）と呼びます。全部を最初から読み込ませないので、手順書が長くなってもAIの作業領域を圧迫しません。
---
description: 提案書のドラフトを作る。構成・トンマナ・必須項目を含む。提案書やRFP回答の作成時に使う。
---
提案書は次の構成で書く。
1. 顧客の課題認識（顧客の言葉をそのまま使う）
2. 打ち手の全体像
...
実務上いちばん効くのは、「毎回同じ説明を貼り付けている」ものをスキルにすることです。CLAUDE.mdのような常時読み込まれるファイルに手順を書き足していくと、だんだん肥大化して読まれなくなります。手順はスキルに切り出したほうが結果的にうまくいきます。
補足として、以前は「カスタムコマンド」という別の仕組みがありましたが、現在はスキルに統合されています。.claude/commands/deploy.md と .claude/skills/deploy/SKILL.md はどちらも /deploy として動きます1。既存のファイルはそのまま使えるので、慌てて移行する必要はありません。
SkillsはAgent Skillsというオープン標準に沿っているため、他のAIツールでも同じ資産が使える見込みがあります。社内で書いた手順書が特定ツールに縛られにくい、という意味では地味に重要な性質です。
Hooks：例外なく実行させる
Skillsが「こうしてほしい」というお願いだとすると、Hooksは「必ずこうする」という強制です。指定したイベントが起きた瞬間に、決めた処理が走ります。
**初版の訂正：**設定ファイルの場所について、初版では ~/.claude.json と書いていましたが、これは誤りです。正しくは以下の階層構造を持つ settings.json です2。
| 場所 | 適用範囲 | 共有 |
|---|---|---|
~/.claude/settings.json |
自分の全プロジェクト | しない（自分のマシンのみ） |
.claude/settings.json |
そのプロジェクト | する（リポジトリにコミット可） |
.claude/settings.local.json |
そのプロジェクト | しない（gitignore） |
| 管理ポリシー設定 | 組織全体 | する（管理者が配布） |
この階層こそが、後で述べるガバナンスの土台になります。**チームで守らせたいルールは .claude/settings.json に書いてリポジトリに入れる。個人の好みは settings.local.json に置く。組織として例外を許さないものは管理ポリシーで配る。**この3層で、強制の強さを使い分けられます。
イベントは細かく用意されています。ツールを使う前（PreToolUse）、使った後（PostToolUse）、ユーザーが発言した時（UserPromptSubmit）、セッション開始時（SessionStart）、サブエージェントの開始・終了（SubagentStart / SubagentStop）など2。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "npm run lint:fix" }
]
}
]
}
}
処理の種類もシェルコマンドだけではありません。HTTPリクエストを飛ばす、MCPサーバーのツールを呼ぶ、LLMに判定させる、サブエージェントに検証させる、の5種類があります2。「この変更が社内規程に反していないかAIに判定させてから通す」といった使い方が、設定だけで書けるということです。
当社では、コラム記事を書いたあとに出典の質をチェックする処理をこの仕組みで動かしています。人間が忘れても走るので、品質のばらつきが減りました。
Subagents：作業を切り出して、権限を絞る
Subagentsは、特定の作業を別のAIに任せる仕組みです。.claude/agents/ にエージェントの定義ファイルを置きます3。
利点は3つあります。
ひとつめは作業領域の節約。調査のようにログや検索結果が大量に出る作業を別のAIに任せると、本体の会話が汚れません。返ってくるのは要約だけです。
ふたつめは権限の制限。使えるツールを絞れるので、たとえばレビュー担当のエージェントには読み取りだけを許可し、書き込みを与えない、という設計ができます。これは事故を防ぐうえで実務的に効きます。
みっつめはコスト制御。エージェントごとに使うモデルを指定できるので、単純な作業はHaikuのような軽いモデルに回せます3。全部を最上位モデルで回す必要はありません。
非エンジニアの業務にどう効くか
ここまで読んで「結局エンジニア向けでは」と思われたかもしれません。しかし3機能とも、本質は繰り返す仕事を言語化して構造にすることです。プログラミングの知識は要りません。
| 機能 | 業務での使い方 |
|---|---|
| Skills | 提案書の構成とトンマナを定義しておく。プレスリリースの必須項目と書き方を定義しておく。月次レポートの集計手順を定義しておく |
| Hooks | 資料を書き出したあとに表記ゆれチェックを自動で走らせる。「社外秘」を含むファイルを触ろうとしたときに警告を出す |
| Subagents | 市場調査を、Web検索とファイル書き込みだけ許可したエージェントに任せる。競合の機能比較表作成を専任エージェントに任せる |
要は、優秀な新人に渡すための業務マニュアルを書く作業です。違うのは、書いたマニュアルが即座に実行されるところだけです。
裏を返すと、マニュアルが書けない業務は自動化できません。「なんとなくやっている」仕事をAIに渡そうとすると、まずその言語化で止まります。ここが実際のプロジェクトで一番時間を使うところで、ツールの習熟よりずっと本質的です。
法人利用で本当に論点になること
初版では、この章で「Claude Codeには利用状況を監査・管理する仕組みがない」と書きました。**この記述は現在の仕様と異なるため、訂正します。**設定の階層、権限モード、プラグイン配布といった仕組みは用意されています。
そのうえで、法人導入で実際に論点になるのは次の3つだと考えています。
1. どこまでを自動で許すか
Claude Codeはローカルでコマンドを実行できます。これが最大の価値であり、同時に一番慎重に設計すべきところです。
対策は「使わせない」ではなく、権限の設計です。プロジェクトの settings.json に許可・拒否のルールを書いてリポジトリに入れれば、チーム全員に同じ規律が効きます。PreToolUse フックで危険なコマンドを止めることもできます。ここを設計せずに全社展開すると、たしかに事故ります。逆に言えば、設計すれば済む話です。
2. ノウハウを個人のPCに置いたままにしない
SkillsもCLAUDE.mdも設定も、放っておけば個人のマシンの中にあります。せっかく良い手順書を書いた人がいても、隣の人は使えません。異動や退職で消えます。
これは技術の問題ではなく運用の問題です。チームで使うものはプロジェクトの .claude/ に置いてリポジトリで共有する、という一線を最初に引いておくだけで、かなり変わります。
3. 誰が何を決めるのか
一番効くのに一番放置されがちなのがこれです。どの業務をスキル化するか、どのルールを強制にするか、書いた手順書は誰がレビューするか。これを決めないまま各自に任せると、似て非なるスキルが乱立して、結局誰も使わなくなります。
ツールの導入より、この意思決定の設計のほうが難しく、成果を左右します。
プラグインで社内に配る
前章の課題に対する、いまの答えがプラグインです。
プラグインは、Skills・Subagents・Hooks・MCPサーバーの設定などをひとまとめにして配布できる単位です4。ルート直下に .claude-plugin/plugin.json というマニフェストを置き、skills/、agents/、hooks/ といったディレクトリを並べます。
my-plugin/
├── .claude-plugin/
│ └── plugin.json
├── skills/
│ └── proposal-writing/
│ └── SKILL.md
├── agents/
└── hooks/
└── hooks.json
配布はマーケットプレイス経由で行います。Anthropicが公式マーケットプレイスとコミュニティマーケットプレイスを運営していますが、マーケットプレイスは非公開リポジトリでもホストできます4。つまり、社内専用のプラグイン置き場を作って、チームの手順書・レビュー基準・禁止事項をバージョン管理しながら配れます。
これが実務的に何を意味するか。「Aさんの環境でだけ動く便利設定」を「入れれば誰でも同じ品質で動く社内標準」に変えられるということです。プラグインのスキルは /プラグイン名:スキル名 という形式で名前が衝突しないようになっているので、複数チームのプラグインを同時に入れても混ざりません。
初版で「野良AIエージェントが乱立する」と書いた懸念は、この仕組みで相当程度は塞げます。塞げないのは、繰り返しになりますが「何を標準にするか決める」ところです。
導入を進めるときの順番
実際にやってみて、この順番が効率的でした。
- **一人が自分の仕事で使い倒す。**まず効果を体感しないと、何を標準化すべきか分かりません
- 繰り返している指示をSkillsに切り出す。「毎回これを貼っている」に気づいたら、それが最初のスキルです
- **絶対に守らせたいものだけHooksにする。**最初から強制を増やしすぎると、動かなくなったときに原因が追えません
- **チームで使うものをリポジトリの
.claude/に移す。**ここで初めて「個人の道具」から「チームの資産」になります - 複数チームに広げる段階でプラグイン化する。
1から3までは自力で進められます。4以降で決めごとが増えるので、外の目を入れると早いことが多いです。
AI導入の伴走はWARPで
TIMEWELLでは、WARPというAIコンサルティングサービスを提供しています。大手企業でDX・データ戦略を担ってきたメンバーが、月次で伴走する形です。
この記事で扱った論点――どの業務をスキル化するか、どのルールを強制にするか、権限をどう設計するか、社内標準をどう配るか――は、まさにWARPで一緒に決めていく領域です。ツールの使い方ではなく、自社の仕事をAIが実行できる形に翻訳する作業だと考えていただくのが近いと思います。
現状の棚卸しから始めたい方は、AI導入レディネス診断で自社の準備状況を確認するところからでも構いません。3分程度で終わります。
具体的な進め方の相談はこちらで受け付けています。
まとめ
- Claude Codeはコーディングツールではなく、手順を渡せば実行する作業環境。非エンジニアの業務にも応用できる
- Skillsは手順書、Hooksは強制力のある自動処理、Subagentsは権限を絞った専門役。この3つが中核
- Hooksの設定は
settings.jsonの階層構造で管理する。ユーザー / プロジェクト / ローカル / 管理ポリシーで強制の強さを使い分けられる（初版の~/.claude.jsonという記述は誤りでした） - 法人利用の論点は「どこまで自動で許すか」「ノウハウを個人PCに置かない」「誰が何を決めるか」の3つ
- プラグインとマーケットプレイス（非公開リポジトリ可）で、手順書を社内標準として配れる
- 一番難しいのはツールの操作ではなく、自社の仕事を言語化して、何を標準にするか決めること
Footnotes
-
Anthropic「Extend Claude with skills」 https://code.claude.com/docs/en/skills （2026年8月1日確認） ↩ ↩2
-
Anthropic「Hooks」 https://code.claude.com/docs/en/hooks （2026年8月1日確認） ↩ ↩2 ↩3
-
Anthropic「Create custom subagents」 https://code.claude.com/docs/en/sub-agents （2026年8月1日確認） ↩ ↩2
-
Anthropic「Create plugins」 https://code.claude.com/docs/en/plugins （2026年8月1日確認） ↩ ↩2
