コンテンツにスキップ
LinkedInX

Vibe Codingを3か月続けて分かった開発と保守の違い

パステルのリング惑星と軌道を背景に「Vibe Codingを3か月続けて分かった開発と保守の違い」を配置した記事カバー パステルのリング惑星と軌道を背景に「Vibe Codingを3か月続けて分かった開発と保守の違い」を配置した記事カバー

この記事で学べること

  • Vibe Codingの技術・設計・運用フェーズで課題がどう変わるか
  • AIへ意図を伝える条件整理と、後半を支えるハーネス整備の役割
  • 作る段階から保守・検証・引き継ぎへ備えるための判断点

Vibe Codingは開発と保守で課題が変わる

AI Learning PlaygroundをVibe Codingで作り始めてから3か月で、作れることと維持できることは別だと分かりました。差がはっきり出たのは、公開後に既存ページを壊さず直す場面と、同じ指摘が別の作業で戻る場面です。同じ順序で進む読者は、公開前の段階で検証、ルール化、引き継ぎをどこに置くか決めておけます。

この記事では、「開発・設計・運用で課題がどう変わり、何を公開前から準備するか」という問いに焦点を当て、対象期間の変化、確認できた学び、次の作業へ移せる判断を扱います。

最後まで読むと、「開発・設計・運用で課題がどう変わり、何を公開前から準備するか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。

Vibe Codingは技術・設計・運用で時間のかかる作業が変わる

Vibe Codingの重心がコード生成から意図の言語化、検証、保守へ移る3段階

AI Learning Playgroundの構築を始めてから約3ヶ月が経ちました。この記事では、Vibe Codingでサイトを作り続けた期間を振り返り、技術・設計・運用の3つのフェーズで得た気づきを整理します。

「Vibe Codingは簡単だ」とも「難しい」とも言い切れないのが正直な感想です。どの部分に時間がかかり、どの部分が想定よりスムーズだったかを、できるだけ具体的に書きます。

技術フェーズ:AIはコードを速く書けるが、意図を伝えるのに時間がかかった

最初の1ヶ月は、Astro + Starlightの環境をAIと一緒に構築する技術フェーズでした。

AIはコードを生成するのが速い一方、私が何を求めているかを正確に伝えることに時間がかかりました。「ナビゲーションを多言語対応にしてほしい」という指示では、AIが生成するコードの方向性が毎回少し異なりました。「日本語と英語のどちらを基準にするか」「URLの構造をどうするか」「翻訳がない場合の表示はどうするか」という前提条件を一つずつ確認しながら指示を組み立てる必要がありました。

この経験から学んだのは、「コードを書いてほしい」ではなく「この条件でこの動作を実現するコードを書いてほしい」という形で、条件を先に整理してから指示することです。

設計フェーズ:ハーネス(AIに渡すルール、作業手順、検証方法をまとめた仕組み)の整備に時間をかけた結果、後半が楽になった

2ヶ月目は、CLAUDE.mdやshared/ルールファイルなど、AIへの指示を構造化する「ハーネス」の整備に集中しました。このフェーズは、作業の進捗が目に見えにくく、「本当に必要な作業なのか」という疑問を持ちながら進めた部分もありました。

しかし3ヶ月目に入ると、ハーネスを整備した効果が明確に出ました。AIが毎回同じ確認を必要とせず、指示の量が減りました。「このルールはCLAUDE.mdに書いてある」と一言添えるだけで、AIが参照し、適切に対応する可能性が高まりました。

設計への投資は、最初は無駄に見えることがあります。しかし長期的に繰り返す作業がある場合、その投資は後から回収できます。

運用フェーズ:「作ること」より「維持すること」が難しかった

3ヶ月間を通じて、最も難しかったのは作ることではなく維持することでした。

記事を書き続けること、ハーネスを更新し続けること、AIが生成したコードの変更を定期的にレビューすること。これらは一度行えばよいものではなく、継続的に必要な作業です。

特に記事の品質を一定に保つことは、最初に想定していたよりも手間がかかりました。一つの記事を書き上げるだけなら短時間でできますが、記事間の一貫性を保ち、翻訳と内容が対応しているかを確認し、古くなった情報を更新するという作業が積み重なります。

Vibe Codingではコーディングより意図の言語化に時間がかかった

Vibe Codingで最も時間がかかったのは、コーディングではなく指示の精度を上げることでした。

「何を作るか」を自分の中で明確にし、その意図をAIに正確に伝え、生成された結果が意図と合っているかを確認する、この一連のプロセスの質が、作業全体の効率に直結します。コードを書く能力よりも、「自分が何を求めているかを言語化する能力」の方が、Vibe Codingにおいては重要だと感じています。

まとめ:保守に備えるルールと検証を公開前から置く

3か月の経験から得た結論は、Vibe Codingではコードを書く速さより、意図を言葉にし、繰り返す確認をルールへ戻す力が保守を左右するということです。最初の行動として、公開前の作業から繰り返しそうな確認を1つ選び、担当者、確認方法、失敗時の戻し先を記録します。

  • ハーネスのさらなる整備(特にレビュープロセスの自動化)
  • 記事の多言語対応精度の向上
  • 読者からのフィードバックを記事更新に反映する仕組みの構築

この振り返りはAI Learning Playgroundを3か月運用した範囲に限られ、他の規模やチームで同じ効果が出ることまでは確認できていません。引き続き実際の経験をもとに記事を書いていきます。