Claude Code の Skills・Hooks・MCP 使い分けで業務を自動化する実践レシピ

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

業務自動化の役割マップを一枚で押さえる

ここからは Claude Code を業務に当てる前に、登場する仕組みがそれぞれ何を解決するかを一枚の地図にして渡します。先に役割の境界を掴めば、自分のタスクをどこに置けばよいか迷いません。

まず前提として、プロジェクト直下の CLAUDE.md は常に読み込まれる共通の前置きとして効きます。プロジェクトの約束事や禁止事項、口調の指示はここに一度だけ書き、以下の 5 つの仕組みはその上に重ねて動くと考えてください。

この地図を頭に置いたうえで、次の章で代表的な業務を入口にどの仕組み同士を組むかを逆引きしていきます。

業務から逆引きする組み合わせの選び方

役割の地図を掴んだら、次は逆に「この業務をやりたい」から組み合わせを引く順番にします。仕組みの定義を覚えるより、自分のタスクをどこに置くかが先に決まる方が手は動きやすいからです。

代表的な業務ごとに、まず組むべき仕組みを一覧にしておきます。

この並びを見ると、主役は常に 1 つで、残りは補佐に回っているのが分かります。すべての仕組みを同時に使う必要はなく、業務ごとに「軸」と「支え」を選ぶのが定石です。

もうひとつ、ここで読者の現在地を確認させてください。同じ「業務自動化」でも、個人 PC で完結させたい副業層と、社内のリポジトリやアカウントを使う社内利用層では置ける前提が違うからです。

トークンの管理場所、実行時間、誰の責任で動かすか、どれも変わります。仕組みの選び方も、その制約から逆算する形に変わります。

そのため、ここから先のレシピ章は副業層と社内層の 2 系統に分けて進めます。

次の章『個人PCで完結する副業向け自動化レシピ』では cron や常時稼働 PC を前提にした運用を扱います。後ほどの『社内 CI で動かす業務自動化レシピ』では GitHub Actions と Channels を前提にした組み方を扱います。

個人PCで完結する副業向け自動化レシピ

ここからは、個人 PC だけで完結させたい人向けの自動化レシピに入ります。会社の CI やクラウドを挟まず、手元の Mac か Windows、Linux で動かす前提です。

各レシピで共通する条件を、ここで一度だけ宣言します。以降の章では前提を繰り返さず、差分だけを扱います。

この後、散らかったファイル整理・月次の帳票作成・MCP を使ったスクレイピングの 3 つを順に降ろします。手応えが出やすい順に並べたので、最初の『散らかったファイルを Skills で整理する』から触ってみてください。

① 散らかったファイルを Skills で整理する

最初のレシピを Skills にするのは、時刻でも外部イベントでもなく「読者が頼んだ瞬間」に発火させたい仕事だからです。ダウンロードフォルダの掃除は毎週決まった時刻に動かしたいわけではなく、「散らかってきたな」と思った瞬間に頼んで動いてほしい類の作業です。Skills は description の自然文に依頼文が当たると自動でロードされるので、cron も常駐プロセスも要りません。

置き場所は、個人 PC で完結させるなら ~/.claude/skills/<skill-name>/SKILL.md の 1 ディレクトリだけ用意します。SKILL.md の冒頭 frontmatter で発火条件と権限を絞るのが、このレシピの肝です。

---
name: tidy-downloads
description: ダウンロードフォルダや作業フォルダが散らかってきたときに呼び出し、種類別ディレクトリへ移動して古いファイルを退避する整理タスク。
allowed-tools: Read, Bash(ls:*), Bash(mv:*), Bash(mkdir:*)
---

description には「いつ自分がこれを呼びたいか」を読者目線の動詞と対象で書きます。曖昧だと別の依頼でも誤発火し、狭すぎると当たりません。

SKILL.md の本体には、拡張子別の振り分け先、何日以上アクセスのないファイルを _archive/ に逃がすか、実行前に対象一覧を見せて承認を取るかを、自然な手順として書き下します。文章で書いてあれば Claude Code 側がそれを読んで実行するので、シェルスクリプトとして固める必要はありません。

呼び出すときは、対話セッションで自然文として頼めば十分です。

ダウンロードフォルダが散らかってきたので、tidy-downloads で整理しておいて。

description の語彙と依頼文が噛み合っていれば、スキル名を明示しなくても発火します。発火しない場合は、ショートカットを増やすより先に description の文を読者目線で書き直すのが筋です。

ここまでで、ファイル整理は時刻にも外部イベントにも縛られない、依頼ベースの軽い仕事として手元に残ります。次の章では、逆に依頼を待たずに毎月決まったタイミングで動かしたい仕事を、どう載せ替えるかを扱います。

② 月次の帳票作成を Routines で定期化する

前の章のファイル整理は「散らかってきたな」と思った瞬間に頼む依頼ベースの仕事でした。月次の経費集計や売上レポートは逆で、依頼を忘れていても月初に勝手に動いてほしい仕事です。だからこそトリガを Routines 側に渡し、何を作るかという中身は Skills 側に置く、という分担にします。

Desktop アプリで動かす場合は、コマンドパレットから Scheduled Tasks を開き、新規タスクに実行するプロンプトと cron 式を登録します。たとえば毎月 1 日朝 9 時に月次経費レポートを作らせるなら、cron 式は次の 1 行で済みます。

0 9 1 * *

登録するプロンプトは「月次経費集計の Skill を呼び出して、先月分を所定フォルダに出力して」のような 依頼文だけにします。テンプレ・計算式・検算ルールは依頼文に書き込まず、Skills 側の手順書として残します。トリガと中身を 1 か所に固めると、フォーマット変更のたびに Routines の登録を触ることになって運用が荒れます。

Skills 側には、出力先の年月フォルダ名、合計と内訳の突き合わせ、税区分ごとの集計、欠損行があれば中断する条件を、自然な日本語の手順として書いておきます。プロンプト埋め込みの計算式より、文章として残したルールの方が後で読み直したときに直しやすくなります。

次の章では、依頼でも時刻でもなく、外部サイトのデータが手元に入ってきてから動かしたいタイプの仕事を、MCP でどう組むかを見ていきます。

③ MCP でスクレイピング業務を組む

競合の価格表や求人サイトの一覧を定期的に取得したい場面では、Web アクセス専用の MCP サーバを Claude Code に繋ぎ、能動 fetch の窓口として使い分けます。ここでの差分は「外部ネットワークと利用規約が絡む」点に集中させます。

MCP サーバの登録は claude mcp add で行います。Bright Data の Web Scraper を例にすると、ローカル設定として次のように追加します。

claude mcp add brightdata --scope local \
  -- npx -y @brightdata/mcp-server

この段階で API キーは環境変数として渡し、コマンドラインや CLAUDE.md にトークンそのものを書かないことが前提です。トークン管理の具体は後ほどの『トークンと OAuth スコープの管理』の章で扱います。

実行側は claude -p の非対話モードに固定し、プロンプトから MCP ツールを呼ばせます。読み取り対象 URL とレート制限は、プロンプト内で必ず明示します。

claude -p "brightdata の MCP ツールで以下の URL を 1 件ずつ 5 秒間隔で取得し、\
結果を ./scrape/out/YYYY-MM-DD.jsonl に追記してください。\
対象: https://example.com/list?page=1〜5" \
  --allowed-tools mcp__brightdata__*

取得結果の整形・重複排除・前回差分との突合は、MCP には任せず Skills 側の責務に切り分けます。たとえば scrape-normalize のような Skill を別途用意し、jsonl を読み込んで CSV / Markdown に整形するロジックをそこに置きます。MCP は「外から取ってくる」、Skill は「形を整える」と役割を分けると、サイト構造が変わったときに修正範囲が Skill 側に閉じます。

社内 CI で動かす業務自動化レシピ

ここまでは副業層の小さな運用として、個人 PC 上で cron や MCP を組み合わせるレシピを見てきました。ここからは社内利用層に切り替え、複数人で共有するリポジトリと CI 基盤を前提にしたレシピを扱います。

社内利用層では「誰がいつ走らせるか」「どこに資格情報を置くか」「業務時間外に勝手に動いてよいか」という制約が同時にかかります。次の 2 つのレシピで共通する前提を、ここで一度だけ整理しておきます。

この 3 点を満たした上で、各レシピは差分だけを書きます。次の章の「Issue や PR を起点に CI で呼ぶ」では workflow YAML のトリガ設計を、その次の「Slack 通知と承認フローを組む」では Channels と Slack App の経路を、それぞれ独立に扱います。

① Issue や PR を起点に CI で呼ぶ

1 つ目のレシピは、Issue や PR のオープンをきっかけに Claude Code を呼ぶ最小構成です。on: issues だけを書いて types を指定しないと、ラベル付け・コメント編集・再オープンなど全アクションで workflow が発火し、bot 自身のコメントに反応して無限ループする事故も起きます。

これを避けるため、トリガは types: [opened] で「新規作成された瞬間だけ」に絞るのが定石です。再オープン時にも走らせたい場合は types: [opened, reopened] を明示し、コメントを契機にしたい時だけ別イベントとして on: の兄弟キーに issue_comment を追加します。types を省略しないことが事故を 1 段階減らします。

name: claude-code-on-issue
on:
  issues:
    types: [opened]
  pull_request:
    types: [opened]
permissions:
  contents: read
  issues: write
  pull-requests: write
jobs:
  run-claude:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Code
        env:
          CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          ISSUE_BODY: ${{ github.event.issue.body || github.event.pull_request.body }}
        run: |
          npx -y @anthropic-ai/claude-code -p "$ISSUE_BODY" > result.md
      - name: Post result as comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const body = fs.readFileSync('result.md', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body,
            });

Issue や PR の本文は run の shell に直接展開せず、必ず env 経由で渡してスクリプトインジェクションを避けます。結果は同じ Issue / PR にコメントとして返し、レビューや次のアクションは GitHub のタイムライン上で完結させます。Slack へ通知したい運用は経路が別なので、後ほどの章で扱います。

② Slack 通知と承認フローを組む

Slack 連携は2方向あります。Slack 起点で Claude Code を叩く方向(Channels)と、処理結果を Slack に投げ返す方向(Workflow からの通知出力)です。承認フローはこの2方向を同じレーンで動かします。

Slack App のスコープは grant 段階で絞ります。承認用途なら通知投稿の chat:write と絵文字承認の reactions:read 程度で足り、users:read.email や admin.* 系は要求しません。

Channels の到達確認は実運用前に必ず通します。Slack の Event Subscriptions が enabled でも、Channels 側で受ける event 種別が一致しないとメッセージは届いても起動しません。検証用 channel で、決まったキーワードから reply 返却までを手で1往復通してから自動化を組みます。

承認フローの肝は、承認待ちを pending として外部に残す設計です。Slack に承認要求を投げて返信を同期で待つと、session が長時間ぶら下がり、トークン枯渇や CI タイムアウトを招きます。代わりに、CI で生成した変更差分を Slack に投稿した時点で、対応する Issue や Pull Request に awaiting-approval のような label を付け、session は一度終了させます。

承認者が Slack で reaction を押す / approve と返信した時点で、Channels 経由で別 session が起動し、続きの処理(merge や本番デプロイ)を実行します。承認の証跡は Slack スレッドと Issue label の両方に残り、後追いも容易です。

通知側は、承認要求用の channel と CI 失敗通知用の channel を分けるのが定石です。混ぜると承認者が重要な要求を見落とすため、投稿内容も承認用は1スクロールで読める量に絞ります。

Routines と Channels の経路を使い分ける

ここまでで副業 PC のレシピと社内 CI のレシピを並べてきましたが、どちらでも繰り返し出てきたのが「いつ動かすか」と「どこから情報が入ってくるか」という 2 つの問いです。本章ではその判断軸を、Routines と Channels という 2 つの surface に当てて整理しておきます。

判断の起点になるのは、データの流れる向きです。Routines は決まった時刻に Claude Code 側から情報を取りに行く能動 fetch の経路で、Channels は外部で発生したイベントを session に push してもらう受動 push の経路にあたります。同じ Slack 通知でも、毎朝定時にレポートを投げるなら Routines、ユーザの発言を起点に session を起こすなら Channels、と分かれるのはこの向きの違いが理由です。

次に効くのが、運用環境の前提です。Routines を選ぶ時点で、PC を常時稼働させて手元の cron に寄せるのか、クラウド側のスケジューラに逃がすのかを決める必要があり、社内データに触るかどうかでも置き場所が変わります。Channels はその点では外部イベントを受け取るだけなので環境制約は緩い反面、誰がどの App からトークンを発行するかという権限設計に判断が寄ります。

さらにもう一段、内側に Hooks があります。Channels が「外から内へ」push する surface なら、Hooks は session 内部の lifecycle に対して発火する surface で、能動 fetch の MCP を含めて 3 方向の流れを 1 枚で持っておくと、レシピを後から組み替える時の道しるべになります。次の章ではまず Routines 3 経路を具体的な軸で並べ、その後で Channels と Hooks の対称な役割を見ていきます。

① Routines 3 経路の使い分け

Routines を「定期実行の箱」とまとめて捉えると、実際の運用で詰まります。経路は3つあり、それぞれ前提が違います。

社内データに踏み込まない軽い定例なら Cloud Scheduled Tasks が一番楽です。手元のファイルやローカル MCP を触る運用なら cron + claude -p が現実解、対話の途中で組んだ自動化をそのまま回したい時だけ /loop を使う、と逆引きすると迷いません。

② Channels と Hooks の対称な役割

Channels と Hooks は名前が似ているせいで混同されがちですが、データが流れる向きが真逆です。ここに能動 fetch の MCP を並べると、業務自動化で使う 3 つの surface の関係が 1 枚に収まります。

つまり Channels は「外から声をかけてもらう窓口」、Hooks は「自分の動きに合わせて自動で挟む処理」、MCP は「必要になったら外へ取りに行く手」という分担です。

この 3 つを混ぜずに区別しておくと、レシピを後で組み替える時に迷いません。たとえば Slack の承認待ちが詰まっているなら手を入れるのは Channels、コミット直前の安全確認を増やしたいなら Hooks、外部 DB から最新値を引きたいなら MCP、と入口が一意に決まります。どの向きの問題かを先に切り分けることが、サーフェスを増やしすぎない一番の近道になります。

運用に乗せる前に潰す落とし穴と多層防御

ここまでで Routines・Channels・Hooks・MCP の経路は整理できたので、いよいよ実際の業務に載せる段階に入ります。ただし、その手前で必ず潰しておきたい落とし穴がいくつかあります。

陥りがちなのが「Hooks を仕込んでおけば安全に自動化できる」という発想です。Hooks は lifecycle に介入できる強力な仕組みですが、それ単体で運用上のリスクを封じ切ることはできません。公式の hooks-guide も「制御点の一つ」として位置付けており、設計の現場でも同じ結論に行き着いています。

そのため、運用に乗せる前提として 設計層・pre-commit・server side の hook・CI 上の Gitleaks を組み合わせる多層防御を最初から織り込んでおく必要があります。Hooks はあくまで多層のうちの一層であって、git や CI と並べて初めて機能します。

この後は次の 3 つの観点で落とし穴を順に潰していきます。まず権限と過剰トリガの設計、次に個人 OAuth トークンや API キーの管理、最後に秘密情報を漏らさないための多層防御です。レシピを動かす前にここを通過させておくと、後で運用を止めずに済みます。

① 権限と過剰トリガの設計

最初に潰したいのは、権限を広く取りすぎた設定 と 発火条件をゆるくしたトリガ です。気を抜くと業務が突然止まる / クレジットが数倍に膨らむ事故が手前で混ざり込みます。

Skills 側は、SKILL.md で 読み書きの対象ディレクトリを明示的に限定 し、それ以外を触らせない方針にします。書き込み先をホワイトリストで 1〜2 箇所に絞れば、暴走しても被害は局所化できます。

Hooks 側は、matcher と発火条件を「必要な瞬間だけ動く」形に削ります。GitHub Actions なら on: pull_request の types は [opened] のみとし、reopened / synchronize を入れず、bot user と draft PR を除外して二重発火を手前で止めます。

Routines 側は、頻度の初期値を 週次 / 月次 に固定し、毎時ループや分単位の繰り返しは設計段階で reject します。/loop は手元のセッション内に限定し、サーバ常駐ジョブとして長期間動かさない判断を先に置きます。

この 3 軸を最小に絞れば、「動かない」「払いすぎた」の事故の大半は運用前に手前で止まります。

② トークンと OAuth スコープの管理

権限の次に落とすのは、トークンそのものの置き場所と寿命です。前の章で潰した過剰トリガとは別軸で、鍵が切れる・鍵が広すぎるの2つが業務を止める実害になります。

運用に乗せる前に決めるべき項目は3つだけです。

スコープは「最初に取った範囲」をそのまま使わない前提で組み直します。個人 OAuth は対象 repo を絞り、GitHub Actions の secret は workflow 単位で参照可能な範囲を狭め、Channels から渡す Slack の権限は通知に必要なものだけに削ります。広いスコープのトークンを長寿命で持つ状態は、漏れた瞬間に被害が最大化するため、寿命とスコープは必ずセットで縮めます。

トークン枯渇で止まる典型は、月次バッチが深夜に走る直前に失効するパターンです。失効14日前に通知が来る経路(Slack / メール)を最低1本確保し、再発行手順を README か Skills 側に短く残しておくと、当番が変わっても復旧できます。

③ 秘密情報を漏らさない多層防御

前の節ではトークンを「どこに置くか」を扱いました。ここでは置いた後の話、つまり秘密情報をうっかりコミットや出力に混ぜない仕組みを考えます。

結論から言うと、Claude Code の Hooks 1 層だけで防ぐのは無理筋です。Hooks はあくまで session 内の lifecycle に挟まる仕掛けで、人が手動で git add した瞬間や、CI 上で別プロセスがログを吐いた瞬間は守備範囲の外にあります。Hooks を入れたから安心、という設計は最初の事故で破綻します。

そこで、現場で機能している置き方は次の 4 層を重ねる形になります。

4 層を重ねる狙いは、1 層をすり抜けても次の層で止まる冗長性です。ローカルの pre-commit は開発者が --no-verify で外せますし、server hook は新規リポジトリで設定漏れが起きます。CI 上の Gitleaks は履歴全体を走査できる反面、検知タイミングが PR 段階まで遅れます。それぞれが補い合う関係なので、どれか 1 つに統一しません。

そのうえで、本記事の前半で扱ったレシピごとに「どの層が効くか」を意識して接続します。Skills でファイル整理や帳票生成を回す経路では、Skills 自体が秘密を読まなくて済むよう設計層で出力テンプレから値を抜く方針が一番効きます。MCP でスクレイピングや外部 API を叩く経路は、結果ファイルにトークンや個人情報が混ざりやすいので、pre-commit と CI の二重走査を必ず通す前提で運用します。Channels から Slack の発言を session に流す経路では、Slack 側のメッセージに秘密情報が含まれた状態で session ログに残るリスクがあるので、ログ保存先の権限を絞り、定期的に CI 側の検査対象に含めます。

この 3 つを潰した状態を運用の出発点として、次の章ではコスト面の論点に進みます。

クレジット分離を踏まえた運用設計の論点

ここまで権限・トークン・秘密情報の落とし穴を見てきましたが、最後に残るのがコストです。

2026年6月15日に Agent SDK 専用のクレジット枠が会話用とは別枠として切り出され、自動化を回す側には「枠が月末まで持つのか」「処理が集中して途中で切れないか」という不安が共通して残ります。コスト把握そのものが運用設計の論点になっている、というのが現在地です。

料金の数字や具体的なプランは変化が速いため、本記事では扱わず別記事にまとめています。ここでは設計側の打ち手だけに絞ります。

中心になるのは、定期実行と外部 push の頻度を最初から狭く始めておくことです。

頻度設計は、後で広げる前提で狭く始める方が安全側に倒れます。

Claude Code 業務自動化のまとめ

コストの頻度設計まで降ろしたところで、ここまでの地図を 1 枚に畳んで、次に手を付ける入口を決めます。

本記事では次の順で論点を進めてきました。

次に手を動かす入口は、自分がどちら側の制約で読んでいたかで分けると迷いません。

最初の 1 surface を自分の業務で実際に動かしてしまえば、残りの Hooks や MCP、Channels は同じ地図の上で組み合わせとして足していけます。