Claude Codeには、作業手順をまとめた「スキル」というMarkdownファイルを持たせられます。一度書けば2回目以降の同じ作業を安定して任せられる半面、この手順書は書いた瞬間から現実とズレ始めます。ツールの仕様が変わり、未検証の手順が残り、実測して書いたはずの記述にさえ誤りが混じるからです。
手順書を使った直後に、使ったClaude自身がその場で直してから作業を締める運用ルールを、実際に手順書が更新された例とあわせて紹介します。
背景・課題
Claude Codeでは、作業ノウハウを「スキル」というMarkdownファイルにまとめて持たせられます。一度書けば、2回目以降は同じ作業をClaudeに安定して任せられます。
ただ、運用を続けると手順書には劣化が積もっていきました。実地で踏んだ事故への対症療法は、節としてどんどん積み重なりました。
あるスキルは、リッチテキストエディタで見出しボタンを押すと本文全体が見出し化してしまう不具合を踏み、その回避策を細かく書き足す一方でした。試す機会がないまま「改善候補」として塩漬けになった仮説も残ります。
もっと厄介だったのは、実測にもとづいて書いたはずの記述にすら誤りが混じっていたことです。「実測確認済み」と明記した挙動が、翌日の別の実測で覆るという出来事も実際に起きました。
手順書は放っておくと現実からズレていきます。かといって、メンテナンスのための時間を別枠で確保するのは、日々の作業に追われると長続きしません。
やったこと
ルールは実質1行にまとめました。
スキルを使った作業で、記述と実測の食い違い・未検証項目の検証結果・新しい確実な発見が出たら、そのセッション中にスキル本体へ反映してから作業を締める。
反映するのは実測にもとづく内容だけです。推測は「未検証」と明記し、断定はしません。
安全網として、スキルやルールなど機密情報を含まない対象をallowlist方式でgit管理しました。Claudeが直接スキルを書き換える運用でも、追跡対象の変更は差分として残り、必要なら巻き戻せます。
実際にこのルールで手順書が更新された例を挙げます。
例1: 仮説から標準手順への昇格 あるスキルには「HTML一括ペースト方式が本命だが未実測」という改善候補が残っていました。次の投稿作業の冒頭でこの方式を小さくテストしたところ成功したため、そのまま本番の記事更新に投入しました。155個のブロックを丸ごと差し替え、機械的な突合で不一致0件を確認してから公開しています。
作業を終えた直後に、スキルの記述を「未実測の改善候補」から「実測済みの標準手順」へ書き換えました。従来なら数時間かかっていた作業が、この回は約15分で終わっています。
例2: 空振りも記録する 別の作業では、必要なログイン情報がどのブラウザプロファイルに残っているか分からず、2つのプロファイルを試して両方とも空振りに終わりました。この無駄足自体をスキルに書き加え、各プロファイルの状態と次回ログインする際の手順を残しました。次に同じ作業をするときは、迷わず必要な操作だけに進めます。
例3: 作業の型を抽出する 配布用のファイルを改訂すると、同じ内容のコピーが3か所に分かれているため同期作業が必要になります。この同期の手順を、確立したその場でスキルの新しい節として一般化しました。
3例合わせても、改善にかけた時間は数十分程度で、いずれも本来の作業のついでに発生しています。
結果
この運用を続けた結果、いくつかの数字が残っています。
- 記事更新作業は、従来の数時間から約15分に短縮しました（例1）
- 機械照合では不一致0件を確認しました
- 専用のメンテナンス枠は設けず、すべて本来の作業直後に反映しました
- git管理を始めた時点の追跡対象は44ファイルで、変更はすべて差分で追えます
数字だけでなく、質的な変化もありました。同じ失敗を二度目に踏むことがほぼなくなっています。事故や空振りが、次に同じ作業をするClaudeへの申し送りとして残るからです。
つまずきと対処
この仕組みを作る過程で、「改善案の反映まで全部自動化すべきか」も検討しました。結論は反対です。
1つ目の理由は、誤った教訓が混入したときのコストが大きいことです。スキルはその後の全セッションの行動を左右するため、間違った記述が1つ紛れ込むだけで、悪影響が繰り返し出ます。
背景で触れた「実測確認済み」の記述が翌日覆った出来事が、まさにこの例です。実測由来の記述ですらこうして食い違うのに、人が差分を確認しない自動書き換えでは、この種の誤りを見逃しやすくなります。
2つ目の理由は、質の高い改善は、使ったClaude自身がまだその場にいる間からしか出てこないことです。作業のログを後から別のプロセスに読ませて教訓を抽出させる方式も検討しましたが、その方式では文脈が薄れる分だけ推測が混ざりやすくなります。
3つ目の理由は、過去の失敗との整合です。以前、毎晩ログを整理する自動バッチ処理を動かしていましたが、トークンを消費するだけで内容が薄いという理由で停止した経緯があります。文脈の薄い自動処理は、同じ構図を繰り返します。
そこで採用したのは、「全自動」ではなく「ルール1行＋git管理」という組み合わせでした。改善の適用そのものを自動化するのではなく、いつ・誰が改善するかというルールだけを決めています。実際の編集内容は使ったClaude自身の判断に委ね、変更履歴はgitで検証できる状態に保っています。
まとめ
手順書のメンテナンスは「いつ・誰が直すか」の設計でほぼ決まります。もっとも文脈が濃いのは、その問題に実際に当たったClaude自身がまだ作業の場にいる瞬間です。そこを逃さず直すルールにしたのが、今回の答えでした。
この仕組みが今後もうまくいくとは限りません。スキルの数がさらに増え、セッション内での反映が回らなくなったら、別のやり方を再検討するつもりです。今のところは、現在の更新頻度なら手作業のルールで十分だと判断しています。
同じように手順書やナレッジベースをAIに持たせて運用している方には、参考になる部分があるかもしれません。こうしたAI運用の仕組み化については、AI導入支援サービスでご相談を承っています。気になる方はお問い合わせからお気軽にご連絡ください。
