非エンジニアがClaudeのAgent Skillsでオペミス対応を仕組み化してみた
こんにちは、非エンジニアのHaradaです。
先日、チーム内でちょっとしたオペミスが発生しました。
それをきっかけに「これ、AIで仕組み化できるのでは？」と思い立ち、ClaudeのAgent Skillsを使って、オペミス対応用のスキルを作成しました。
※本記事では、ClaudeのAgent Skillsを便宜上「Claude Skills」または「スキル」と呼びます。
きっかけ：オペミスの後処理が、毎回そこそこ大変だった
私のチームでは、業務の1つとして社内検証環境の払い出し作業を行っています。
先日、その作業において一部の設定手順が漏れ、利用者が一時的に対象環境へアクセスできない状態になりました。
社内検証用途だったこと、またすぐにリカバリーできたことから、影響は限定的でした。
同じような経験がある方もいるかもしれませんが、そこからが大変で…
オペミスが発生すると、報告書の作成やレビュー会の実施に向けて、様々な調査や確認が必要になります。
これが毎回地味に大変なのです。
具体的には…
- どこまで影響が出たか（誰が・何にアクセスできない状態だったか）を確認する
- 上長や関係者に、何が起きて・どれくらいの時間・どう対応したかを報告する
- 障害報告書を決まったフォーマットで書く
- レビュー会に向けて再発防止策を考える
項目自体はどれも難しくないのですが、心理的・工数的な負荷が大きい作業だな～と毎回思っていました。
加えて、レビュー会では「手順のXXが見づらかったから間違えた」「手順にXXを加えよう」といった、手順ベースの恒久対応（同じミスを繰り返さないための再発防止策）に寄りがちでした。
もちろん手順の改善も大事ですが、それに加えて、確認観点の整理や仕組み化もできるのではないかと考えていました。
ひらめき：これらはAIでできるのでは？
弊社では、技術ブログにAIが自動でレビューコメントをくれる仕組みがあります。
私自身も、技術ブログのレビューで何度か指摘をもらう中で、「AIは決まった観点でチェックする用途と相性がよさそうだな」と感じていました。
オペミス対応も、これに当てはまるのでは？と思いました。
- まず何を止める・戻すか（応急対応）
- どう影響を確認するか（監査ログの見方）
- どう再発を防ぐか（恒久対応）
- どう報告するか（障害報告書）
上記の情報をAIに渡しておけば、ミスが起きたときに「こういうことがあった」と話すだけで、
対応の順序と報告書の下書きまで出してくれて工数削減につながるのでは？と考えました。
「スキル」って？
普段、私はClaudeのプロジェクト機能をよく使っていて、スキルを作るのは今回が初めてでした。
プロジェクトとスキルの違いがよく分からなかったので、調べた結果が以下です。
| プロジェクト | スキル | |
|---|---|---|
| 役割 | 知識・背景情報を覚えさせる場所 | 動き方・手順を固定する仕組み |
| 適用範囲 | そのプロジェクト内に限定 | 利用可能な環境では、複数のチャットやプロジェクトで使い回せる |
| 同じ内容を複数箇所で使いたい時 | プロジェクトごとにコピペが必要 | 1つ作れば横断的に使い回せる |
一度スキルを作ってしまえば、関係する話題になったときにAIがそのやり方を参照しながら回答してくれて
毎回長い指示を打ち込まなくてよくなる、というイメージで
今回はプロジェクトよりもスキルの方が適切だと考えました。
参考：
実際に作ってみる
作り方も、AIに「オペミス対応のスキルを作りたい」と相談するところから始めました。
会話しながら、以下のような構成に落ち着きました。
- 入口のメモ：オペミスについて言及があったら、どういう順番で対応するか（事実の聞き取り → 種別の判定 → 暫定対応 → 恒久対応 → 監査ログ確認 → 報告書作成）
- 業務ごとの手順メモ：クラウドや業務の種別ごとに、「本来あるべき正しい状態」「ミスが起きやすいポイントとその応急対応」「監査ログの確認方法」をまとめたもの、各クラウドサービスの公式ドキュメントで公開されている仕様やベストプラクティス
- 報告書のテンプレート：社内で使っている報告書フォーマットをベースにテンプレート化
材料として、普段使っている作業手順書や台帳（PDFやドキュメント）をAIに読み込ませました。
（※読み込ませる資料は社内ルールに従い、機密情報・個人情報・アカウント情報などを含まない形に整理したうえで利用しました。）
すると、手順の中から「ここが間違えやすい」というポイントをAIが拾い出してくれ、それを暫定対応方法とセットでまとめてくれました。
ポイントとして、恒久対応（再発防止）については、AIの思い込みで書かせず、必ずクラウドの公式ドキュメントを参照して根拠を付けるようにお願いしました。クラウドの仕様は変わるので、ここは大事なポイントです。
構成イメージは以下です。
incident-response-skill/
├── SKILL.md
├── references/
│ ├── cloud-project-setup.md
│ └── access-control-checklist.md
└── templates/
└── incident-report-template.md
※ファイル名や内容は公開用に汎用化しています。
使ってみた
出来上がったスキルに、実際のミスの内容を話しかけてみました。すると、
- ミスの種別を判定して
- 暫定対応を出して
- 公式ドキュメントを参照して恒久対応（再発防止策）を提案して
- 障害報告書の下書きを、あらかじめ用意したテンプレートに沿って作成
まで、一通りの流れをサポートしてくれました。
ゼロから書いていた報告書が下書きの状態で出てくるだけで、体感がだいぶ変わります！
もちろん、権限の削除やメール送信みたいな“実際に影響が出る操作”はAIに代行させず、「提案 → 人が確認 → 実行」の順にしています。止血のつもりの操作でさらにミスが起きたら本末転倒なので、ここは人の手を残すようにしました。
レビュー会はまだですが、これまでは原因や再発防止策を一から議論するため、つい長引いてしまうこともありました。
しかし、恒久対応のたたき台をAIに作ってもらい、その内容をレビュー会で確認しながら、追加のアイデアや実現性を議論する場にできれば、
工数削減につながるうえに、内容もこれまでより充実するのではと考えています。
| AIに任せたこと | 人が確認したこと | |
|---|---|---|
| 事実整理 | ヒアリング項目の洗い出し | 実際の事実確認 |
| 暫定対応 | 対応案の提示 | 実行可否の判断 |
| 監査ログ確認 | 確認観点の提示 | ログの実確認 |
| 恒久対応 | 公式ドキュメントをふまえた案出し | 採用判断 |
| 報告書 | 下書き作成 | 最終内容の確認・提出 |
チームに配る
作ったスキルは、ファイル1つにまとめて書き出せました。
私の環境では、作成したスキルをファイルとして共有し、受け取ったメンバーが保存することで利用できました。
個人で作ったものを、そのまま横展開できるのは便利ですね！
まずは狭い範囲で利用してみて、使い勝手のフィードバックをもらいながら今後は育てていく予定です。
やってみて思ったこと
非エンジニアでも、自分の業務のやり方を文章で書けるなら、それがそのままスキルにできます！
「コードが書けないから」と身構えていた私にとって大きな進歩です！
今回作ったスキルもまだ改善途中ですが、まず自分がよくやる定型作業から試してみるのがおすすめです。
