こんにちは。SREグループの木村です。
SREグループでは、インフラの構成管理、監視、障害対応、開発チームへの支援を担っています。 手順は定まっていても状況ごとに判断がいる業務が多く、その判断基準はメンバーの経験に委ねられていました。 この基準をClaude CodeのSkillとして書き出し、チームでレビューできるようにしました。 チケット運用とダッシュボード確認の2つの事例と、Skillの定期実行基盤を紹介します。
チケットの書き方を揃える
SREグループでは、日々の業務をJiraのチケット駆動で進めます。 Kubernetesの運用タスク、障害対応の調査、他チームからの依頼、いずれもJiraチケットとして起票し、チームに共有します。
チケットの書き方はメンバーによってまちまちでした。 「何をやるか」だけが書かれて実施の背景が省かれていたり、ゴールが曖昧で完了の判断がつかなかったりします。 チケットはチームへの共有手段でもあるため、書き方が揃っていないと他のメンバーが状況を把握しづらく、過去のチケットを振り返っても判断の経緯が読み取れません。
そこで、起票と着手の両方をカバーするプラグインを作りました。
起票時には、Skillが対話形式で記載内容を収集します。 背景、やること、やらないこと、完了条件をテンプレートに沿ってClaudeが一問一答で聞き出します。 「何を聞くべきか」がSkillに定義されているため、項目の抜け漏れを防げます。 起票が終わると、起票プロセスとは別のサブエージェントがチケットを評価します。 起票時の会話を知らないClaudeが、チケットに書かれた情報だけを見て判断するため、作成者が暗黙の前提としていた情報の欠落が指摘として表面化します。 背景の明確さ、スコープの具体性、完了条件の客観性、スコープ外の境界の4観点でチェックし、不明確な項目には具体的な指摘と補完のための質問を返します。
作業に着手するときは、Commandが準備を引き受けます。 Jiraチケットの内容を読み取って要件を検証し、チケット内の参照リンクからConfluenceページや関連チケットを収集します。 さらに関連ワードでJiraとConfluenceを横断検索し、チケットに明示されていない背景情報も拾います。 集めた情報はコンテキストドキュメントにまとめ、リンク先をたどらなくても必要な背景が把握できる状態にします。 この土台の上で方針のブレインストーミングと実行計画の作成を行い、会話の中で不明確だった項目が明確になれば、作業者の解釈としてJiraにコメントを残します。
起票時の一問一答では、Claudeが観点を順に提示するため、起票者自身が気づけていなかった前提の曖昧さや考慮漏れが表面化します。 着手時には要件を自動検証するため、「進めてみたら前提が違った」という手戻りも減りました。
ダッシュボード確認の基準を定義する
SREグループでは、毎朝システムの状態を確認するためにDatadogダッシュボードの目視確認をする運用があります。 この運用では、前日や前週との比較で異常の有無を判断する定型作業を行っています。 ただし、何をもって「異常」とするかは担当者の経験に委ねられており、確認の深さも人によって違っていました。
この確認作業に、Skillによるレポート自動生成を導入しました。 メトリクス取得、ステータス判定、テンプレートに従ったレポート整形、Chatworkへの投稿までを実行します。 判定基準をSkillに定義しておくことで、担当者によらず同じ尺度で評価できるようになりました。
メトリクス収集には多数のAPIリクエストの並列実行が必要で、生データをすべてClaudeのコンテキストに載せるとトークン消費が膨大になります。 そのため、データの収集と判定はスクリプトとClaudeで役割を分けました。 スクリプト側で並列取得と数値計算を済ませ、整形済みのJSONだけをClaudeに渡します。 Claude側ではステータス判定とレポート生成だけを担います。 判定基準を自然言語で書ける点がClaudeを使う利点で、閾値ベースのアラートでは表現しにくい条件もSkillの文言として定義できます。 出力も数値の羅列ではなく、何が問題でどこを注視すべきかを文章にまとめられます。
このSkillの導入で目視確認そのものがなくなったわけではありません。 ただし、確認の起点がダッシュボードの巡回からレポートの読解に変わり、見落としの防止と判定尺度の統一につながりました。
Skillの定期実行基盤
自動レポート生成のように、Skillを人手なしで定期実行したい場面が出てきました。
SREグループでは、Skillをプラグインとして配布するためのマーケットプレイスを運用しています。 このマーケットプレイスのプラグインを実行できるClaude Codeのコンテナイメージを用意し、EKS上のCronJobとして動かすことで定期実行を実現しました。 自動レポート生成を含むいくつかのSkillが、この基盤の上で稼働中です。
この基盤は他のグループにも展開しており、セットアップ手順もSkillとして提供しているため、各チームが自律的に環境を構築できます。
まとめ
2つの事例に共通するのは、メンバーの経験や習慣に委ねられていた判断基準を、Skillの定義として外部化した点です。 チケットに何を書くべきか、メトリクスをどう評価すべきか。 Skillに書き出したことで、基準そのものがPRによるレビューと改善の対象になりました。
どちらも人手の作業をなくしたのではなく、判断の尺度を揃えた取り組みです。 SREの業務には閾値だけでは判定条件を表現しきれないものが少なくありません。 判断基準を自然言語で定義し、コードと同じくバージョン管理できる点が、Claude Codeをこうした標準化に使う利点です。