Claude Media
Claudeのoperationsプラグインでrunbook・変更管理・ベンダー評価を整える
CoworkClaude Codeチュートリアル

Claudeのoperationsプラグインでrunbook・変更管理・ベンダー評価を整える

Anthropic公式のoperationsプラグインで、runbook・変更申請・ベンダー評価を下書きする手順。READMEと実体の食い違い、接続先の実態もあわせて解説します。

読了目安 約10分

operationsプラグインは、Anthropicがknowledge-work-pluginsとして公開している業務プラグインの1つです。runbook、変更申請、ベンダー評価、キャパシティ計画といった運用部門の定型文書を、Claudeに下書きさせるために作られています。導入は2行、使い始めは/operations:runbook 月次締め処理のような1行です。

ただしREADMEとリポジトリの実体にはずれがあり、接続先の「同梱」の意味も読み方に注意が要ります。この記事では導入から3つの代表的な使い方、そのずれまでを順に扱います。

operationsプラグインでできること

READMEによると、運用チーム向けにベンダー管理・プロセス文書化・変更管理・キャパシティ計画・コンプライアンス追跡・リソース計画を支援するプラグインです。主にCowork向けに設計されていますが、Claude Codeでも動作します。単体でも使え、ITSMやプロジェクト管理ツールをつなぐと強化されるという作りです。

リポジトリのskills/ディレクトリには、次の9個が並んでいます。plugin.jsonのバージョンは1.3.0です。

スキル作るもの
runbook作るもの繰り返し作業の手順書
change-request作るもの影響分析とロールバック計画つきの変更申請
vendor-review作るものコスト・リスク・推奨判断つきのベンダー評価
process-doc作るものフローチャート・RACI・SOP
capacity-plan作るもの稼働率分析と人員計画
status-report作るもの経営層向けの進捗報告
risk-assessment作るものリスク登録簿
compliance-tracking作るもの監査・認証の追跡
process-optimization作るものボトルネックの分析と改善案

表の上6つ(runbookからstatus-reportまで)は、READMEで「コマンド」として載っています。残る3つは「スキル」側の記載です。この区分のずれは後半で扱います。

導入と呼び出し方

Claude Codeでは、マーケットプレイスの追加とプラグインの導入を別々に行います。

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install operations@knowledge-work-plugins

Coworkでは、プラグイン一覧から対象を選んで導入します。一覧の操作はCowork公式プラグイン3種を試す記事に、部門別プラグイン全体の構成はClaude部門別プラグインの使い方にまとめています。

呼び出し名は、Claude Codeの公式ドキュメントで/プラグイン名:スキル名と定義されています。operationsなら/operations:runbookの形です。反映されないときは/reload-pluginsコマンドで、セッションを閉じずに読み込み直せます。

runbookを作る — 「具体的すぎる」くらいが正解

/runbookは、繰り返す作業の手順書を作ります。引数はプロセス名か作業名です。READMEの例は/runbook monthly close processで、一度手順を説明すると、チェックリスト・トラブルシュート・エスカレーション経路つきの手順書になるとされています。

出力の見出しは決まっています。

手順

runbookの出力構成

  1. 1

    冒頭の管理欄

    Owner、Frequency(Daily・Weekly・Monthly・As Needed)、Last Updated、Last Runを置きます。

  2. 2

    Purpose と Prerequisites

    用途と、必要な権限・ツール・入力データをチェックボックスで並べます。

  3. 3

    Procedure

    各ステップに「実行するコマンドや操作」「Expected result」「If it fails」を1組ずつ書きます。

  4. 4

    Verification から History まで

    完了確認、Troubleshooting表(症状・原因・対処)、Rollback、Escalation表、実行履歴が続きます。

SKILL.mdのTipsには3点あります。「Run the script」は手順ではなくpython sync.py --prod --dry-runのように書くこと、各ステップの失敗パターンを入れること、手順に不慣れな人に実際にたどらせて詰まった箇所を直すことです。

実際の依頼文は、次のように手元の事実を先に渡すと、Procedureが具体的になります。以下は入力例で、出力そのものではありません。

/operations:runbook 月次の請求データ取り込み
 
担当: 経理オペレーション / 頻度: 毎月第3営業日
実行場所: 運用サーバー
手順メモ: 会計システムからCSVを出力 → sync.py --dry-run で差分確認
          → 問題なければ --prod → 件数を管理シートと突き合わせ
失敗時の連絡先: 経理リード(Slack #acct-ops)

手順メモが粗くても構いません。Claudeが埋めた「Expected result」と「If it fails」は推測を含むので、実際にたどった人が直す前提で扱うのが安全です。

変更申請(change-request)— ロールバックまで一枚にする

/change-requestは、変更の説明を渡すと、影響分析・リスク評価・ロールバック計画・承認ルートを含む申請書を作ります。SKILL.mdは内部で「Assess・Plan・Execute・Sustain」の4段階の枠組みを使うと書いており、伝え方の原則として「whatの前にwhy」「失うものも認める」を挙げています。

出力の主な節は次のとおりです。

節中身
Impact Analysis中身Users・Systems・Processes・Costの4領域をHigh/Med/Low/Noneで評価
Risk Assessment中身リスクごとに発生確率・影響・緩和策
Implementation Plan中身ステップ・担当・期限・依存関係
Communication Plan中身相手・伝える内容・チャネル・時期
Rollback Plan中身発動条件(Trigger)・手順・戻せたことの確認
Approvals Required中身承認者・役割・状態(Pending)

SKILL.mdのTipsは、影響を「全員」と書かず「請求チームの200人」のように具体化すること、自信があってもロールバックを書くことを求めています。Claudeに渡す入力でも、対象人数・停止時間帯・戻す条件を先に書くと、表が空欄の羅列になりません。

~~chat(Slackなど)がつながっていれば関係者への通知文の下書きやチャンネル投稿、~~ITSMがつながっていれば申請チケットの自動作成まで進みます。つながっていなければ、申請書の本文までが成果物です。

ベンダー評価(vendor-review)— 総保有コストで見る

/vendor-reviewは、ベンダー名と状況(新規・更新・比較)、契約条件や提案書を渡すと評価書を作ります。SKILL.mdが評価の柱に置くのは、コスト、リスク、パフォーマンス、比較マトリクスの4つです。

コストはライセンス費だけでなく、導入・移行、研修、保守、解約時のデータ移行まで含めた総保有コスト(TCO)で見ます。出力のCost Analysisには、初年度合計と3年合計の行があります。結論はProceed(進める)・Negotiate(交渉する)・Pass(見送る)のいずれかに、理由と交渉材料が添えられます。

くらべる

vendor-reviewへの渡し方

渡すもの

新規の評価

ベンダー名と提案書。SKILL.mdは、提案書をアップロードすれば価格・条件・SLAを抜き出せると案内しています。

渡すもの

更新・比較

現在の支払額と、比較したいベンダー名。「Compare Vendor A vs Vendor B」で並列の比較表になります。

~~procurement(調達ツール)が未接続なら、契約条件や過去の支出は自分で渡す必要があります。調達ツールは、リポジトリ側にも同梱の接続先が無い領域です。

残る3スキルと、判断の目安

capacity-planには稼働率の目安が書かれています。担当者は75〜80%、マネージャーは60〜70%、オンコール・サポートは50〜60%で、100%で計画する、会議や休暇を数えない、といった落とし穴も列挙されています。risk-assessmentは発生確率と影響の3×3マトリクスでLow・Medium・High・Criticalを割り当てます。status-reportは緑・黄・赤の状態と、判断が必要な事項(Decisions Needed)の節を持ちます。

process-docとrunbookは、使い分けに迷いやすい組み合わせです。READMEの例ではprocess-docが業務プロセス全体の文書(フロー図・RACI・SOP)、runbookが繰り返す作業の実行手順です。誰が責任を持つかを決めたいなら前者、コマンドを順に叩く手順なら後者、と分けると重複しません。

READMEと実体のずれ、接続先の実態

READMEの「Commands」には6件、「Skills」にはvendor-management・process-optimization・change-management・risk-assessment・compliance-tracking・resource-planningの6件が載っています。一方、リポジトリにcommandsディレクトリは無く、skills/の9ディレクトリに集約されています。vendor-management・change-management・resource-planningの3つは、skills/に同名のディレクトリがありません。READMEの区分けは、整理前の構成のまま残っていると読めます。

接続先も、文書ごとに食い違います。

くらべる

接続先の記載の違い

Included servers

CONNECTORS.md

ITSMはServiceNow、チャットはSlack、メールはGmailとMicrosoft 365、オフィススイートはMicrosoft 365など。調達(Procurement)は同梱なしで、Coupa・SAP Ariba・Zipが「Other options」です。

実際の定義

.mcp.json

slack・google calendar・gmail・notion・atlassian・asanaの6件だけです。google calendarとgmailはurlが空文字で、ServiceNowとMicrosoft 365は定義がありません。

.mcp.jsonにServiceNowの定義が無いため、ServiceNowを使う組織は、プラグインを入れただけではITSM連携が成り立たず、MCPサーバーを自分で足す形になります。ServiceNow側の接続手順はClaude ServiceNow連携の使い方にあります。

READMEはさらに、operations/.claude/settings.local.jsonに会社名・チーム・報告頻度・承認ルート・準拠フレームワーク・会計年度開始月を書いておけると説明しています。

{
  "company": "Your Company",
  "team": "Operations",
  "reportingCadence": "weekly",
  "approvalChain": ["Manager", "Director", "VP"],
  "complianceFrameworks": ["SOC 2", "ISO 27001"],
  "fiscalYearStart": "January"
}

未設定ならプラグインが対話で尋ねる、とも書かれています。ただし、9本のSKILL.mdにはこのファイルへの言及がありません。approvalChainがchange-requestの承認者欄に反映されるかは、SKILL.mdからは読み取れないため、実際に/operations:change-requestを試して承認者欄を確かめるのが確実です。

プラグインを導入する手順そのものや、マーケットプレイスの仕組みはClaude Codeプラグイン完全ガイドに詳しくあります。

まとめ

operationsプラグインの価値は、運用文書の「見出しの型」が最初から揃っている点にあります。runbookはExpected resultとIf it failsをステップごとに強制し、変更申請はロールバックと承認欄まで一枚に収めます。外部ツールとの連携は、CONNECTORS.mdの表ではなく.mcp.jsonの6件が実態です。まずは接続なしで/operations:runbookを1本、実在の作業で試し、自社のITSMや調達ツールが必要かを、その出力を見てから決められます。

この記事を共有:XはてブLinkedIn

関連する記事

Cowork をもっと見る →