日常点検

公開した製品は、コードを一行も変えなくても壊れていきます。依存に脆弱性が見つかり、外部サービスの仕様や課金条件が変わり、ドメインや証明書の期限が近づき、リンク先が消えます。壊れてから利用者に教えられるのか、点検で先に気づけるのか。この差が、運用の質を決めます。

何を点検するか

変更していないのに壊れる場所には型があります。依存の既知の脆弱性（依存関係）。ドメインと証明書の期限（Webの構造）。外部サービスの仕様変更。フォーム送信やログインといった主要な操作が今日も通ること。表示速度の劣化とリンク切れ。確認はClaudeに任せられますが、フォーム送信のような書き込みを伴う確認は本番のデータを汚さないよう、プレビュー環境やテスト用のデータで行います（環境の分離）。

この製品の主要な操作を一通り試して、壊れているところがないか報告して。修正はまだしないで
依存の脆弱性、リンク切れ、開発者ツールのエラーがないか点検して

点検と修正を分ける

点検のついでに修正まで進むと、確認していない変更が本番へ混ざります。点検ではコードと設定を変更せず、見つかった問題は範囲を決め直してから既存の製品を修正するの手順で直します。取り消せない操作の前に確認を挟むというClaudeへの権限の考え方と、同じ分離です。

SkillとPluginで習慣にする

同じ点検の手順を毎回言葉で説明するのは無駄です。弊社では点検の手順をSkill（Claudeに追加する再利用可能な手順書）にまとめ、短い呼び出しで実行しています。点検に限らず、開発、テスト、保守の手順もSkillとPlugin（SkillやMCP、エージェント設定をまとめて配布する単位）として整備し、実際の運用を視野に入れた開発ではこれらを活用していきます。

その全体像、つまり人とAIで製品開発を継続運用する方法は、次のセクションの製品で扱います。