Vibe Codingを3か月続けて分かった開発と保守の違い
この記事で学べること
- 3か月の変更履歴から確認できる、開発と保守で扱う作業の違い
- AIへ渡す条件、共通ルール、検証手順を整理する役割
- 変更記録から分かることと、工数や効果の測定に別途必要な記録
Vibe Codingの開発と保守を変更履歴から振り返る
Vibe Codingは、AIへ文章で条件を伝えながらソフトウェアを作る進め方です。AI Learning Playgroundの2026年3月22日〜6月21日の変更履歴には、記事・文書、画面・スタイル、AI向けのルールや検査の変更が残っています。コードを生成するだけでなく、作成した内容と、それを支える仕組みの両方を更新する作業を確認できます。
本記事では、この3か月の記録と、現在のリポジトリ（コード、文書、変更履歴をまとめて管理する場所）にある仕組みから、開発と保守の違いを整理します。最後まで読むと、保守に備えて何を記録し、どの効果を別途測る必要があるか判断できます。各月に何を最も難しく感じたか、どの作業に最も時間を使ったかは、変更履歴だけからは判断しません。
開発から保守へ備える条件・ルール・検証
図は、開発から保守へ備える作業の関係を表しています。各月の作業時間や重要度の変化を測った結果ではありません。以下では、技術、設計、運用を、時系列の段階ではなく確認する対象として分けます。
技術：AIへ渡す動作条件と確認方法
このサイトは、サイトを作るAstroと、文書サイトの画面を整えるStarlightを使っています。日本語と英語のページを扱うため、言語の基準、ページのアドレス、翻訳がない場合の扱いなどを決める必要があります。これらの方針は、共有ルールや設定ファイルで確認できます。
たとえば「ナビゲーションを多言語対応にする」という依頼でも、どの言語を基準にし、どのページへ移動させるかで必要な動作が変わります。AIへ渡す条件と、できた画面を確かめる方法を一緒に整理することが、保守時の確認にもつながります。これは依頼を組み立てる例であり、過去に同じ会話をしたという記録ではありません。
設計：共通ルールと自動検査の役割分担
リポジトリには、最初に読む指示ファイルのCLAUDE.mdとAGENTS.md、共通ルールを置くshared/、ルールの一部を確かめる自動検査があります。AIに渡すルール、作業手順、検証方法をまとめる仕組みを、ここでは「ハーネス」と呼びます。
共通ルールは、別の作業でも参照する方針を残す場所です。自動検査は、設定や記事が定めた条件を満たすか確かめます。ルールを書いたことと、それを守るか検査することは別の役割です。整備の負担を、その後の説明や修正の削減で取り戻せたかは、作業時間を比較しなければ判断できません。
運用：記事・翻訳・画面を更新し続ける作業
変更履歴には、記事・文書、画面・スタイル、ルール・手順・検査の変更が、同じ期間に重なって残っています。最後の期間でも、記事だけ、設定だけという一種類の作業には限られていません。
現在の検査にも、記事の構造、日英の対応、内部リンク、画面の既存ルールを確かめる処理があります。新しい内容を作ることに加え、変更後も必要な条件が保たれているかを確かめる対象があると分かります。ただし、履歴の件数だけでは、公開後の不具合や手戻りが何件あったかは分かりません。
Git履歴で確認できる3か月の変更量
2026年3月22日〜6月21日のGit履歴には、別々に進めた変更を統合したときの記録を除いて、148件のコミットがありました。コミットは、記事追加や修正、設定変更などをまとめて保存した変更記録です。この期間を3つに分け、どの対象に変更があったかを数えました。リポジトリにはこの期間より前の履歴もあるため、この表の初日をサイト開発の開始日とは扱いません。
| 対象期間（2026年） | 全コミット | 記事・文書を変更 | 画面・スタイルを変更 | ルール・手順・検査を変更 |
|---|---|---|---|---|
| 03/22〜04/21 | 48 | 27 | 21 | 20 |
| 04/22〜05/21 | 23 | 13 | 14 | 9 |
| 05/22〜06/21 | 77 | 65 | 22 | 33 |
各列は、その種類のファイルを1つ以上変えたコミットの件数です。同じコミットが複数列に入るため、列を足して全件数にはできません。たとえば最後の期間は77件のうち65件が記事・文書の変更を含み、22件が画面・スタイル、33件がルール・手順・検査の変更を含んでいました。内容と実装の両方を更新していたことが履歴から確認できます。
集計は2026年10月13日に確認した履歴に固定し、各変更に記録された日時を日本時間へ換算しています。記事・文書、画面・スタイルとサイト設定、AI向けのルール・作業手順・自動検査を対象にしました。
この数字は変更記録の件数であり、修正にかかった時間、失敗回数、手戻り件数、AIごとの成果を測った値ではありません。一つのコミットへ複数の修正をまとめる場合も、記事を新しく追加する場合もあります。
変更履歴で分かることと別途測る必要があること
確認できるのは、3か月の間に記事・文書、画面、共通ルールや検査の更新が続いたことです。どの月に最も時間がかかったか、説明が何回減ったか、保守が開発より難しかったかは、この集計からは分かりません。
ハーネスの3層設計の記事では、教訓ログに残した不具合と、その再発条件を検出する仕組みの例を扱っています。ログやコミットの件数に加え、作業時間や手戻りを評価するなら、1件ごとの時間、修正理由、比較する作業の条件を別に残す必要があります。
まとめ：保守に備える条件・ルール・検証の記録
この3か月の履歴が示すのは、サイトを維持する作業が記事、画面、ルールや検査にまたがることです。コードを作れたことと、変更後も必要な動作や記事の対応を確かめられることは、別の確認対象になります。
保守への備えとして残すのは、AIへ渡す動作条件、繰り返し使うルール、確認方法、失敗時の戻し先です。これらの整備で時間や手戻りが減ったかを判断するには、変更件数とは別の測定が必要です。この一つのサイトの記録だけから、他の規模やチームで同じ効果が出るとは判断できません。