Vibe Codingの次のステップ：「作れる」から「継続的に維持できる」への移行で必要になったこと

2026年6月22日

Shiori

この記事について

Vibe Codingでサイトを作り終えた後、維持・運用のフェーズに入って初めて必要になったことがありました。作るフェーズとは異なる問題が出てきたため、その経験を記録します。

Vibe Codingでサイトを作っていたとき、AIへの依頼はシンプルでした。「このページを追加してください」「このデザインに変えてください」という指示を出すと、AIがコードを書いてくれます。動作を確認して問題がなければ次の機能へ進む、という流れで進められました。

維持するフェーズに入ると、状況が変わりました。

変更の副作用が出るようになった。 ナビゲーション構造を1箇所変えたところ、別のページのリンクが機能しなくなりました。AIは指示された変更を実行しますが、変更が他の部分に与える影響を毎回網羅的に確認するわけではありません。

情報の更新が継続的に必要になった。 記事の数が増えると、古い情報を持つページが出てきます。インデックスページや関連リンクを最新の状態に保つ作業が、追加コンテンツが増えるほど複雑になりました。

AIの文脈が増えた。 コードが増えるほど、AIに渡す必要がある背景情報も増えます。「このプロジェクトではこのルールがある」「このファイルは変更してはいけない」という情報をセッションごとに伝え直すコストが大きくなりました。

セキュリティの問題が出てきた。 外部からアクセス可能なサイトを運用していると、依存パッケージの脆弱性、公開してはいけいないパスの露出などの問題に対処する必要が出てきます。

変更が既存の動作を壊していないかを自動で確認する仕組みを「ハーネス」と呼んでいます。

具体的には、コンテンツのバリデーション（frontmatterの形式チェック）、内部リンクの存在確認、ナビゲーション構造の整合性チェックを自動化したスクリプトを用意しました。AIが何かを変更するたびにこれらが実行されるため、問題をその場で検出できます。

npm run harness:check というコマンドで全チェックをまとめて実行できるようにしています。

記事の追加・更新について、公開前に確認するチェックリストを設けました。frontmatterの形式、引用の根拠、日英の整合性、禁止表現の有無を確認します。

npm run review:content で確認できる仕組みにしてあります。

AIに守らせるルールをCLAUDE.mdに集約しました。「npm run build はユーザーの明示承認なしに実行しない」「既存のナビゲーション構造を変更しない」といった制約を明示することで、AIが意図しない変更をするリスクを減らしています。

作るフェーズは「何を作るか」の判断が中心でした。維持するフェーズは「変更が既存の動作を壊さないか」の確認が中心になります。

Vibe Codingで作ることは、AIへの依頼を重ねていけばある程度できます。維持することは、変更の影響範囲を把握するための仕組みが必要です。この仕組みを作る作業は、機能を実装するより設計が複雑だと感じています。

「作れた」という段階が出発点であり、それを維持できるかどうかは別の問題という認識が、運用を続けているうちに明確になりました。