Claude Code 解説書 — Thread 8 of 8
自動化・配布・応用
Hooks、Plugins、Marketplaces、Channels、CLI自動化、スケジュール実行、トラブルシューティングまでを体系的に解説する
スレッド8の全体マップ
スレッド8は「Claude Codeを個人の手元から解放し、チーム・組織・自動パイプラインに組み込む」ための7つのトピックを扱う。前半(8.1〜8.3)は自動化と配布の仕組み、後半(8.4〜8.7)は外部連携・CLI統合・運用を扱う。
図8.0 — スレッド8:7つのトピックの関係
Section 8.1
8.1Hooks — ライフサイクルイベントへの自動処理
Hooks(フック)とは、Claude Codeの特定のライフサイクルイベント発生時に自動実行されるスクリプトのこと。LLMの「判断」に依存せず、決定論的に(=必ず同じ条件で同じ結果になるよう)処理を挟み込める。
なぜHooksが必要か
Claude Codeはエージェントとして自律動作するが、「ファイル保存後に必ずフォーマッタを実行する」「特定のファイルへの書き込みを絶対に禁止する」といった例外なく守るべきルールは、LLMの判断に委ねるべきではない。Hooksは、こうしたルールを強制するための仕組みだ。
たとえば、PostToolUseイベントにprettier --writeを登録すれば、Claudeがファイルを編集するたびにPrettierが自動で走る。LLMに「フォーマットしてね」と頼む必要がない。
4種類のHook Type
図8.1 — Hookの4つのTypeと判断モデル
主要なHookイベント一覧
| イベント名 | 発火タイミング | 代表的な用途 |
|---|---|---|
SessionStart | セッション開始・再開・コンパクション後 | コンテキスト再注入 |
PreToolUse | ツール実行前 | コマンドのブロック・承認 |
PostToolUse | ツール実行後 | 自動フォーマット・ログ記録 |
Notification | Claude Codeが通知を送信するとき | デスクトップ通知 |
Stop | Claudeが応答完了 | タスク完了の自動検証 |
PermissionRequest | 許可ダイアログ表示時 | 特定操作の自動承認 |
ConfigChange | 設定ファイルの変更検知 | 監査ログ |
PreCompact / PostCompact | コンテキスト圧縮の前後 | 状態保存・復元 |
設定例:ファイル編集後に自動フォーマット
.claude/settings.json
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
}
]
}
]
}
}matcherは正規表現パターンで、ここではEditかWriteツールの実行後だけに絞っている。Hookはstdinで実行コンテキストのJSONを受け取り、jqで必要なフィールドを抽出する設計になっている。
入出力の仕組み
図8.1b — Hookの入出力フロー
Hookスコープの使い分け
| 配置場所 | スコープ | 共有 |
|---|---|---|
~/.claude/settings.json | 全プロジェクト共通 | ×(ローカルのみ) |
.claude/settings.json | 単一プロジェクト | ○(リポジトリにコミット可) |
.claude/settings.local.json | 単一プロジェクト | ×(gitignore対象) |
| Managed policy | 組織全体 | ○(管理者制御) |
Plugin hooks/hooks.json | プラグイン有効時 | ○(プラグインにバンドル) |
注意:Stop Hookの無限ループ
Stop Hookが常にok:falseを返すと、Claudeが永遠に止まれなくなる。入力JSONのstop_hook_activeフィールドがtrueの場合はexit 0で早期リターンすること。
Section 8.2
8.2Plugins — 拡張機能のパッケージング
Plugin(プラグイン)とは、Skills・Hooks・MCP・Subagents・LSPサーバーを1つのパッケージにまとめて配布可能にしたもの。個人カスタマイズからチーム標準ツールキットへの「昇格パス」を提供する。
Standalone設定 vs Plugin
| 観点 | Standalone (.claude/) | Plugin |
|---|---|---|
| スキル名 | /hello | /my-plugin:hello |
| 適用範囲 | 単一プロジェクト | 複数プロジェクト横断 |
| 配布方法 | 手動コピー | Marketplace経由で/plugin install |
| 名前空間衝突 | 可能性あり | 自動的に名前空間分離 |
| バージョン管理 | なし | セマンティックバージョニング |
プラグイン作成の最小手順
ディレクトリとマニフェストを作成
mkdir -p my-plugin/.claude-pluginmy-plugin/.claude-plugin/plugin.json を作成
スキルを追加
mkdir -p my-plugin/skills/deploymy-plugin/skills/deploy/SKILL.md を作成(frontmatter + 指示)
ローカルテスト
claude --plugin-dir ./my-plugin /my-plugin:deploy # 名前空間付きで呼び出し
変更を反映
開発中はファイルを修正後、/reload-plugins で再読み込みが可能。再起動不要。
既存設定からの移行
すでに .claude/commands/ や .claude/settings.json にカスタマイズを持っている場合、それらをプラグインに変換できる。コマンドファイルはそのまま commands/ へ、Hooksは hooks/hooks.json へコピーすればよい。形式はまったく同じなので、ファイルの配置場所を変えるだけだ。
Section 8.3
8.3Marketplaces — プラグインの発見と配布
Marketplace(マーケットプレイス)とは、プラグインのカタログ(一覧と配布基盤)のこと。スマートフォンの「アプリストア」と同じモデル:ストアを追加 → 欲しいプラグインを個別インストール。
マーケットプレイスの3層構造
公式 Anthropic
claude-plugins-official
自動追加・自動更新。LSP / 外部連携 / ワークフロー。
チーム / 組織
your-org/claude-plugins
GitHub/GitLab リポジトリ。社内ツール標準化に。
コミュニティ / ローカル
URL / ローカルパス
任意ソースから追加可。開発・実験用にも。
公式マーケットプレイスの主要カテゴリ
| カテゴリ | 代表的なプラグイン | 機能 |
|---|---|---|
| コードインテリジェンス | typescript-lsp, pyright-lsp | LSPによる型エラー即時検出・定義ジャンプ |
| 外部連携 | github, slack, notion | MCP経由の外部サービス接続 |
| 開発ワークフロー | commit-commands, pr-review-toolkit | Git操作・PR作成の自動化 |
| 出力スタイル | explanatory-output-style | Claudeの応答スタイルのカスタマイズ |
インストールスコープ
User — 自分の全プロジェクトに適用(デフォルト)。Project — リポジトリの全共同作業者に適用(.claude/settings.jsonに追記)。Local — 自分だけ、かつこのリポジトリのみ。Managed — 管理者がMDM等で強制適用。ユーザーは変更不可。
セキュリティ:プラグインはマシン上で任意のコードを実行できる。公式以外のプラグインは、ソースコードを確認した上で信頼できるものだけをインストールすること。
Section 8.4
8.4Channels — 外部イベントの受信
Channel(チャネル)とは、実行中のClaude Codeセッションに外部からイベントをプッシュする仕組み。MCP経由でメッセージを受信し、Claudeが自動で反応する「リアルタイム接続口」にあたる。リサーチプレビュー段階(v2.1.80以降)の機能。
図8.4 — Channelsの双方向通信フロー
利用手順(Telegramの例)
Telegramで BotFather にボットを作成しトークンを取得
プラグインをインストール
/plugin install telegram@claude-plugins-officialトークンを設定
/telegram:configure <token>チャネル有効化で再起動
claude --channels plugin:telegram@claude-plugins-officialペアリング & アクセスポリシー設定
ボットにメッセージ送信 → ペアリングコード取得 → /telegram:access pair <code> → /telegram:access policy allowlist
セキュリティ:各チャネルプラグインは送信者のallowlistを管理する。ペアリングしたIDだけがメッセージを送信でき、それ以外は無視される。Team/Enterpriseプランでは管理者がchannelsEnabled設定で機能自体を有効/無効にできる。
Section 8.5
8.5CLI自動化 — パイプラインとSDK
claude -p(非対話モード)とAgent SDKを使えば、Claude Codeをスクリプト・CI/CDパイプライン・プログラムから制御できる。Unix哲学に基づく「パイプで繋げる」設計が最大の強み。
① ワンショット
claude -p "query"
結果をstdoutに出力
② Unixパイプ
cat log | claude -p
stdinからデータ受信
③ 構造化出力
--output-format json
JSON / stream-json
④ Agent SDK
Python / TypeScript
完全プログラマティック制御
実例:CI/CDでのPRレビュー自動化
gh pr diff "$PR" | claude -p \ --append-system-prompt "Security review" \ --output-format json --allowedTools "Bash(git *),Read"
基本コマンド
# ワンショット実行
claude -p "auth.pyのバグを見つけて修正して"
# ツール自動承認付き
claude -p "テストを実行して失敗を修正" --allowedTools "Bash,Read,Edit"
# 構造化出力(JSONスキーマ指定)
claude -p "関数名を抽出" --output-format json \
--json-schema '{"type":"object","properties":{"functions":{"type":"array","items":{"type":"string"}}}}'
# 会話の継続
claude -p "コードベースをレビューして"
claude -p "DBクエリに絞って深掘り" --continueセッション管理
--output-format jsonで得られるレスポンスにはsession_idが含まれる。これを--resumeに渡せば、複数の会話を並列に維持して任意のタイミングで再開できる。たとえば、GitHub Actionsのジョブ間でセッションIDを受け渡し、マルチステップのレビューパイプラインを構成できる。
ヒント:対話モードのスキル(/commit等)は-pモードでは使えない。同等のことをしたい場合は、タスクを自然言語で記述する:claude -p "ステージされた変更を確認してコミットして" --allowedTools "Bash(git *)"
Section 8.6
8.6スケジュール実行 — /loop と cron
/loop(バンドルスキル)を使うと、Claude Code内でプロンプトを定期実行できる。デプロイ監視、ビルド状態チェック、リマインダーなどに使う。セッションスコープ(Claude Codeを閉じると消える)の軽量スケジューラ。
基本的な使い方
# 5分ごとにデプロイ状態をチェック /loop 5m デプロイが完了したか確認して結果を教えて # 末尾にintervalを指定するパターン /loop ビルドの状態をチェック every 2 hours # interval省略時はデフォルト10分 /loop PRのCIステータスを確認
ワンタイムリマインダー
自然言語でリマインダーを設定することもできる。内部的にはCronCreateツールでcron式に変換される。
# 絶対時刻指定 remind me at 3pm to push the release branch # 相対時刻指定 in 45 minutes, check whether the integration tests passed
仕組みと制約
| 項目 | 仕様 |
|---|---|
| スケジューラ精度 | 1分単位(cron式ベース)。秒指定は分に切り上げ |
| タイムゾーン | ローカルタイムゾーン(UTCではない) |
| 同時タスク上限 | 50個/セッション |
| 自動期限切れ | 作成から3日後に自動削除(繰り返しタスク) |
| 永続性 | なし。セッション終了で全消去 |
| ミス補完 | なし。Claudeがビジー中の発火はアイドル後に1回だけ実行 |
| ジッター | 周期の10%(最大15分)のランダムオフセット |
永続的なスケジューリングが必要なら:/loopはセッション内の軽量ツール。再起動をまたぐ永続的な定期実行には、GitHub ActionsのscheduleトリガーやDesktopアプリのスケジュール機能を使う。
cron式リファレンス
内部ツールCronCreateは標準5フィールドcron式を受け付ける:分 時 日 月 曜日
| cron式 | 意味 |
|---|---|
*/5 * * * * | 5分ごと |
0 * * * * | 毎時0分 |
0 9 * * * | 毎日9:00 |
0 9 * * 1-5 | 平日9:00のみ |
Section 8.7
8.7トラブルシューティング
Claude Codeの問題はほとんどの場合、インストール / 認証 / 設定ファイル / パフォーマンスの4カテゴリに分類できる。まずは/doctorコマンドを実行し、自動診断を確認するのが第一歩。
/doctor が検査する項目
インストール種別・バージョン・検索機能の動作、自動アップデートの状態と利用可能な最新バージョン、settings.jsonの構文エラー(不正なJSON、型の誤り)、MCPサーバーの設定エラー、キーバインド設定の問題、コンテキスト使用量の警告(巨大なCLAUDE.md、MCPトークン過大)、プラグイン・エージェントの読み込みエラー。
よくある問題と対処法
インストール系
| 症状 | 原因 | 対処 |
|---|---|---|
command not found: claude | PATHに~/.local/binが未追加 | echo $PATH | tr ':' '\n' | grep local/binで確認し、未設定なら追加 |
syntax error near '<' | インストールスクリプトがHTMLを返している | Homebrew (brew install --cask claude-code) で代替 |
| 低メモリLinuxでKilled | メモリ不足(512MB以下) | スワップ追加:fallocate -l 1G /swapfile |
認証系
| 症状 | 対処 |
|---|---|
403 Forbidden | サブスクリプション確認。環境変数ANTHROPIC_API_KEYが古いキーで上書きしていないかチェック |
OAuth error: Invalid code | コード有効期限切れ。再試行して素早くログイン完了する |
| WSL2でブラウザが開かない | BROWSER環境変数をWindowsのChromeパスに設定 |
パフォーマンス系
高CPU/メモリ — /compactでコンテキスト縮小。大きなビルドディレクトリは.gitignoreに追加。
検索が遅い/不完全 — システムripgrepをインストールし、USE_BUILTIN_RIPGREP=0を設定。
WSLでの検索結果不足 — プロジェクトをLinuxファイルシステム(/home/)に配置する。
設定ファイルの場所
| ファイル | 用途 |
|---|---|
~/.claude/settings.json | ユーザー設定(パーミッション、Hooks、モデル指定) |
.claude/settings.json | プロジェクト設定(ソース管理対象) |
.claude/settings.local.json | ローカルプロジェクト設定(コミットしない) |
~/.claude.json | グローバル状態(テーマ、OAuth、MCPサーバー) |
.mcp.json | プロジェクトMCPサーバー設定 |
設定の完全リセット:rm ~/.claude.json && rm -rf ~/.claude/ でユーザー設定を、rm -rf .claude/ && rm .mcp.json でプロジェクト設定を全削除できる。すべての設定・セッション履歴が消えるため、最終手段として使うこと。
まとめ — スレッド8の全体像
図8.8 — 自動化・配布エコシステムの全体フロー
スレッド8で扱った7つのトピックは、Claude Codeを「自分のターミナルで動くツール」から「チーム全体のインフラストラクチャ」へ進化させるための仕組みだ。
Hooks はライフサイクルの各ポイントに決定論的なルールを注入する。Plugins は再利用可能な拡張をパッケージとしてまとめる。Marketplaces はそのパッケージを組織やコミュニティに配布する。Channels は外部からのリアルタイムイベントをセッションに取り込む。CLI自動化 はclaude -pでパイプラインやCIに組み込む。スケジュール実行 は/loopでポーリング的な監視を実現する。トラブルシューティング は/doctorを起点に系統的に問題を診断する。
これらを組み合わせることで、個人の生産性向上だけでなく、開発チーム全体のワークフロー自動化が実現できる。
Support
homulaの支援体制
Claude Codeの自動化・プラグイン開発・CI/CD統合を含むAIエージェント導入を、homulaは包括的に支援しています。
AIエージェント・ブートキャンプ
3〜5日でClaude Codeを活用した自動化プロトタイプを構築。Hooks・Plugins設計からCI/CD統合まで。
エンタープライズ導入支援
組織全体のClaude Code運用設計、Managed Policy策定、セキュリティレビュー、CoE立ち上げを支援。
シリーズナビゲーション
← 前の章
並列処理 — SubagentsとAgent Teams
Coming Soon
シリーズトップ →
Claude Code完全解説書 全8章
よくある質問
Hooksは特定のライフサイクルイベント(ファイル保存後、ツール実行前など)で自動実行されるスクリプトで、単体の設定ファイルで定義します。Pluginsは、Hooks・Skills・MCP・Subagentsなど複数の拡張を1つのパッケージにバンドルし、名前空間を分離した上でインストール・配布可能にしたものです。Hooksは「単機能のルール強制」、Pluginsは「機能セットの再利用・共有」と考えると分かりやすいです。
対話モード専用のスキルコマンド(/commit等)は-pモードでは使えません。代わりに、同等のタスクを自然言語で記述します。例えば「claude -p 'ステージされた変更を確認してコミットして' --allowedTools 'Bash(git *)'」のように指示します。
いいえ。/loopはセッションスコープの軽量スケジューラで、Claude Codeのセッション終了時に全タスクが消去されます。再起動をまたぐ永続的な定期実行が必要な場合は、GitHub Actionsのscheduleトリガーやcronジョブでclaude -pを呼び出す構成を検討してください。
/doctorコマンドを実行するのが最初のステップです。インストール状態、バージョン、設定ファイルの構文エラー、MCPサーバーの接続、コンテキスト使用量などを自動診断します。それでも解決しない場合は/feedbackコマンドまたはGitHub Issuesで報告できます。
Channelsは実行中のClaude Codeセッションに外部からリアルタイムにイベントをプッシュする仕組みです。通常のMCPがClaude側からツールを呼び出す「プル型」であるのに対し、Channelsは外部サービス(Telegram、Discord等)からメッセージが届く「プッシュ型」の双方向通信を実現します。リサーチプレビュー段階(v2.1.80以降)の機能です。