こんにちは。CREチームの藤原です。
Claude Codeの「スキル」という仕組みを使って、運用業務の自動化を進めています。作り始めて11日で10本、5か月で30個近く。実現できたポイントは、AIを使い始める前から続けていた運用の習慣でした。
私の担当業務と、AIに任せるまで
建設DXサービス「SPIDER+」の運用対応を担当しています。現場データの削除などの定型作業を、お客様からの依頼書をもとに実施しています。
これらは、お客様が管理画面からはできない作業です。そのため運用スクリプトを人がサーバーで実行して対応します。出力を確認しては、手順書に沿って次のコマンドを打つ ― という「システムの外側」の手作業です。
手順そのものは決まっているのに、人が張り付かないと終わらない。この手間を減らして、空いた時間を別の作業に回したい、とずっと思っていました。そこにAIという相棒ができたので、この手作業をまるごと任せてみることにしました（この1年の変化は、同じチームの大畑の記事にまとめています）。 techblog.spiderplus.co.jp
この「ツールはあるが、人が操作しないと動かない」領域を、AI自身に操作させています。
依頼件数でいえば、チームの定型作業の9割以上をスキルが処理しています。この記事では、そこまで早く作れた理由と、運用に乗せるまでにやったことを書きます。
スキルは「AI向けに書き直した作業手順書」
Claude Codeの「スキル」は、ざっくり言えばAIに渡す作業手順書です。Markdownで「依頼内容を確認し、条件に応じたコマンドを実行する。判断が必要な場面では一旦止めて人に聞く」と書いておくと、AIがそれを読んで処理を進めます。
既存の運用ツールを作り直す必要はありません。これまで人が叩いていたスクリプトを、そのままAIに叩かせます。
短期間で作れて、運用に乗せた3つの秘密
理由を後から数えると3つありました。1つ目が「スキルを早く作れた」ことに、2つ目と3つ目が「作ったスキルに実際の作業を任せられるようになった」ことに効いています。
理由1：手順書が、つねに最新の状態で手元にあった
AIに任せたい作業があるなら、まず「手順書」が必要です。幸い、私たちの手元にはそれがすでにありました。
CREチームでは、作業依頼ごとにGitHubのissueを作成し、対応内容をそこに記録する ― という運用を以前から続けていたからです。急いでいるときでも、まず作業記録だけは残しておいて、落ち着いてから手順書に起こす。次はその手順書を見ながら作業し、記録と違うイレギュラーなパターンが出てきたら、その場で手順書を更新する。これをずっと繰り返していました。
つまり、スキルを書き始める時点で、書き写す元がすでに揃っていました。スキル作りで一番重いのは「普段は暗黙にやっていることを言語化する」工程ですが、それは日々の運用のなかで、AIとは関係なく先に済んでいたことになります。おかげで、AIのためにゼロから手順を洗い出す必要がありませんでした。
理由2：いきなりスキルにせず、まずAIと並走した
手順書があるからといって、そのまま書き写せば動くわけではありません。そこで、スキルにしたい作業があるときは、先にAIと一緒に1件やり切ります。
私 : 今日はこの作業をやりたい
AI : この手順書を使います。まず対象の照合からですね
私 : OK、やって
AI : 照合しました。依頼書とデータに差異はありません
私 : 次は何をやるの？
AI : 次は削除前の空き容量の確認です
私 : OK
この往復を最後までやってから、スキルに書き起こします。
最初から全自動を目指すと、たいてい失敗します。手順書に書いていない分岐に当たる、出力の読み方を間違える ― 人が実行するときには起きないつまずきが出てくるからです。並走は、それを1件分先に洗い出す作業です。ここを通しておくと最初の1本の完成度が上がり、作り直しが減ります。
やってみると、依頼書とデータの照合は判断が要り、空き容量の確認や完了報告の組み立ては機械的に決まる ― という境目が見えてきます。この境目が分かってはじめて、どこまでAIに任せてよいかを決められます。
理由3：長くなったら、短くする
実運用のフィードバックを反映し続けると、スキルはどんどん肥大化します。
そうすると、手順を飛ばす・前提の確認を省く・書いてあるはずの中断条件を見落とす、といったポカが増えます。AI自身が読み切れなくなるからです。
そこで、複数のスキルで共通して使う処理は共通の部品として切り出し、役割ごとにファイルを分けて、スキル本体を短く保つようにしました。この整理そのものもAIにやらせています。ただしスキル全体を読んで組み替える作業なので、ここだけは高性能なモデルを指定します。そのほうが分割の精度が上がりました。
短く保つようにしてから、ポカは目に見えて減りました。安心して任せられる範囲が広がり、後始末に取られていた時間も次のスキルに回せます。
スキルは作って終わりにしない
人がやっていた「イレギュラーが出たら、その場で手順書を更新する」を、スキルにも持ち込みました。1件動かして、引っかかったところをその場で直す。ここで言う「1件」は依頼1件 ― スキルを最初から最後まで1回動かす単位です。その1件が終わるたびに自問する項目を、スキルの末尾に書き足してあります。
継続的改善
作業完了後、以下を自問すること。
詰まった箇所はなかったか
手順どおりにやってエラーになった箇所はなかったか
説明が曖昧で判断に迷った箇所はなかったか
該当があれば、その場でこのスキルを修正してコミットする。
どれかがあれば、その場で直してコミットする。なければ何もしない。それだけです。
あとでまとめて直そうとすると、たいてい忘れます。違和感を覚えた瞬間が一番よく分かっているので、その場で書き足してしまうのが結局は早い。この5か月で、コミットは600件を超えました。
動かして分かったことーAIに任せたあと
理由2で「動かしてみないと分からないことがある」と書きました。では、実際に何が出てきたのか。ここからはその中身です。「現場データの削除」という作業を例に説明します。
「どう進めるか」より「どこで止まるか」を書く
現場データの削除のスキルで一番工夫したのは「依頼書とデータが食い違ったとき、どう振る舞うか」でした。依頼書に書かれた現場名とデータベース上の現場名が微妙に一致しない、というのは意外とよくあります。単純に止まってしまうと、そこから先は結局人が引き取ることになり、自動化の意味が薄れます。
そこで今は、差異を検出したらいったん作業を止め、サポート担当への確認メッセージの下書きまでAIに作らせます。この場面で人が手を入れるのは、その文面を確認して承認するところだけです。返信が来たかどうかはAIがスレッドを読みに行って判断し、確認が取れていれば、照合からやり直して削除を再開します。
このスキルで一番行数を割いているのは「どう進めるか」ではなく「どこで止まるか」です。場面ごとの中断条件を書き並べたうえで、全体のルールとして「少しでもおかしいと思ったら止まって人に聞く」を手順書の先頭に置いています。
- 依頼書の書式がいつもと違う
- 件数が多すぎる
- IDが空欄になっている
- 照合で差異が出た
自動化というと最後まで走り切らせることを考えがちですが、安心して任せられるようになったのは、止まり方を決めてからでした。依頼を拾いに行くところも同じで、同じコマンドを一定間隔で繰り返す仕組みを使い、後続の作業が止まらないように30分おきに未対応の依頼を探させています。
スキルで足りなければ、スクリプトに移す
スキルは文章です。書き落とせばそこは埋まりませんし、書いたことが間違っていればそのとおりに動きます。それが表に出たことが2度ありました。
1件目は、書き落としでした。不備が複数あったとき、最初に見つけた分だけをお客様に確認して作業を進め、あとから別の不備が出て、もう一度確認をお願いすることになります。サポート担当から「2度顧客確認するのは避けたい」という依頼が来ました。人間なら無意識に不備を全部洗い出してから一度に聞くので、「送る前に不備を全件確認する」とは手順書に書いていなかったのです。明文化されていない挙動は、たまたま当たっているだけです。対策として、このルールを手順書に明記したところ、以降は安定して運用できています。
2件目は、書いてあるとおりに動いた結果でした。当時のスキルには「パターンが異なる場合は別々の投稿に分けて送る」と書いてあり、AIはそのとおりに確認を2通に分けます。その2通の下書きをまとめて承認したところ、AIは片方だけへの承認と読み違え、もう1通が送られないまま処理が止まりました。幸い、削除を実行する前に気づいたため実害はありません。対策として、パターンが混在しても確認は必ず1通にまとめることにし、さらにその1通を組み立てる作業そのものをスクリプトに移しました。拾った差異の件数と文面の件数が合わなければ、送る前に止まります。
つまり、信頼度には3段階あります。動いているように見える ＜ スキルに書いてある ＜ スクリプトで強制されている。言語化は必要ですが、文章である以上、書き落としも書き間違いも残ります。判断が要る部分（パターンの特定やデータベースとの照合）はAIに残したまま、機械的に決まる部分だけをスキルから取り上げてコードに移す。そうするほど全体は安定していきました。こうして補助スクリプトは50本ほどになり、別のスキルでは624行あったものが321行まで減っています。
並列にしていいものと、してはいけないものを分ける
依頼が立て込むと、複数の作業を同時に進めたくなります。Claude Codeにはサブエージェントという仕組みがあり、作業を分割して並列に走らせることができます。
ここでも一度つまずきました。並列で走らせたエージェントの報告があいまいだと、呼び出した側が「終わったのかどうか」を判断できず、同じ報告を二重に投稿してしまう ― という事故です。対策として、次のルールを共通で追加しました。
- 1エージェントにつき1件だけ担当させる
- 完了・未完了を必ず明示して返す
- 報告があいまいなときは元の記録を見に行ってから次に進む
ただし、同じサーバーに対する作業だけは並列にしていません。データベースのロックがぶつかるおそれがあるので、そこは1件ずつ順番に流します。速さより、確実に終わることを優先した部分です。この仕組みが入ってからは、月あたりの削除依頼が1.5倍ほどに増えた時期も、そのまま吸収できています。
取り返しがつくかどうかで線を引く
自動化を進めるほど、逆に「ここは渡さない」の線引きが大事になります。今のところ、次のようなものは意識的に人の手元に残しています。
- 本番データベースのシステムテーブルへの直接操作
- 後戻りしにくい削除の最終実行（実行そのものは、必ず人が確認してから）
- 人がレビューして実行する前提で書かれた運用スクリプト（AIに叩かせるものは別に用意する）
- クラウド環境の設定変更や削除といった、書き込みを伴う操作
判断の軸にしているのは「取り返しがつくかどうか」です。取り返しがつく作業は自動化してよく、取り返しがつかない作業は、たとえ手順が完全に決まっていても人の確認を挟みます。
ただし完全な白黒ではありません。データベースの更新文やサーバーの再起動のように、単体では任せきれない操作でも、人がその場で出力を見ている状況なら実行させる、という中間の運用もしています。逆に、完了報告のような定型の連絡は、以前は送信前に自分で確認していましたが、今は確認なしで自動送信しています。危ないところに確認を寄せて、安全なところからは手を引く。これが線引きの実際です。
これから
こうした積み重ねで、定型の運用作業の多くは、依頼の受け取りから完了報告までがひと続きになりました。人が手を入れるのは、要所の確認だけです。以前はチームで分担していた削除依頼を、いまはほぼ一人で引き受けられるようになっています。それでいて、1件あたりに自分が拘束される時間は増えていません。
30個という数は、うまく設計して並んだものではありません。手順書を作り続ける運用が先にあり、AIと並走してから書き起こし、長くなったら短くする ― その繰り返しで積み上がったものです。
まだスキル化できていない作業も残っています。手順書がないものです。今後試したいのは、手順書を先に書くのではなく、自分が作業しているところをそのままAIに観察させて、手順書ごと起こしてもらうというやり方です。運用の知識がない人でも自分の作業を自動化できるようになれば、この取り組みはもっと広がるはずだと思っています。
参考
- Claude Code 公式ドキュメント docs.claude.com
最後に
スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
