AIコーディングというと、新しい画面を作ったり、大きな機能を一気に実装したりする話が目立ちます。
自分もCodexへ実装をお願いすることはかなり増えました。
ただ、個人開発を続けていると、本当に後回しになるのは別のところなんですよね。。
依存関係の更新、古い設定、使わなくなったコード、細かいQA。
やらないといけないのは分かっているけど、今すぐ困ってはいない作業 です。
そんな作業こそ、AIに調べてもらい、修正とテストを経てPR（GitHub上の変更提案）の形まで持ってきてもらえたら助かりそうです。そこで今回は、tsukurun-LabのBlogで実際に試してみました。
新機能より、後回しになる保守
新機能は、自分でも考えながら作りたいところがあります。
画面をどうするか悩んだり、実際に触って微調整したりするのは、個人開発の楽しい部分でもあります。
一方で保守は、必要なのにどうしても後ろへ回りがちです。
たぶん自分の場合、AIに全部作ってもらうことより、 この「あとでやる」を減らしてもらう方が嬉しい のかもしれません。
DoorDashの事例も、新機能ではなく片付けの話だった
AI Research Radarで、DoorDashのmulti-agent保守事例を見つけました。
対象は、使われなくなったfeature flag（機能のON/OFFを切り替えるための設定）の片付けです。
大量に残ったfeature flagを見つけて、影響を確認して、修正して、検証して、PRへする。
DoorDash側の評価では50件中45件がそのまま使えるPRになり、人間は最後の確認と取り込みを担当する構成だったそうです。
もちろん規模は自分のBlogとは全然違います。
ただ、「AIに派手なものを作らせる」というより、 ずっと残り続ける面倒な作業を、確認できる形まで持ってきてもらう 使い方はかなり気になりました。
全部を任せず、PRでいったん止める
この事例で一番いいなと思ったのは、AIがそのまま本番まで反映する形ではなかったことです。
候補を探す → 隔離した場所で直す → 自動検証する → PRを作る → 人間が確認する
最後はちゃんと人が見る。
自分も普段GitHubのPRを境界にしているので、今回もCodexにはまず下書き状態のPR（Draft PR）で止まってもらいました。その後の第三者レビューと本番反映の判断は別にしています。
AIへ強い権限を渡して全部自動化するより、この分け方なら今の運用を大きく変えずに試せます。
最初に見つかったのは、200なのに中身が違うURL
最初にCodexへお願いしたのは、tsukurun-LabのBlogで検索エンジン向けの設定がどうなっているかを調べることでした。新しく機能を増やすのではなく、後回しになっていた保守を1つ選び、変更を検証してPRまで作ってもらいます。
このBlogは、おとよ（アルパカログ）さんの astro-notion-blog をフォークして、自分の用途に合わせて手を加えてきたものです。既存のNotion連携や記事URLを壊さないことを先に条件にしました。
調査で分かったのは、 /robots.txt や /sitemap-index.xml へアクセスすると、HTTPの応答自体は200なのに、返ってくる中身がトップページのHTMLだったこと。存在しない記事URLも同じでした。
200だから問題ない、とは限らないんですね。。
そこで今回は、検索エンジンにサイト内のページを知らせるサイトマップと、巡回方針を書く robots.txt の整備だけに絞りました。存在しないURLを200で返してしまう問題は、配信全体の挙動に関わるので別の保守として残しています。
Codexには、調査からPR作成まで任せてみた
Codexは現状を調べたうえで、Astroの公式integrationである @astrojs/sitemap を採用しました。公開記事が増えたときも、ビルド時にサイトマップへ反映できる方法です。
robots.txt は環境で内容を分け、本番だけサイトマップの場所を案内し、公開前の確認用ページ（Preview）では Disallow: / を返すようにしています。Previewは別途 noindex のヘッダーでも検索登録を抑える構成です。
変更前後のページHTMLやRSSをテスト用データで比較し、17ページと2つのRSSがバイト単位で一致することまで確認してくれました。公開12記事、未公開1件、未来日付1件を用意した検証でも、公開対象だけがサイトマップへ入っています。
もちろん、これは本番のNotionデータをそのまま再現したテストではありません。まずは既存の画面や記事URLに余計な変更を加えていないか、確認できる範囲を広げるための検証です。
最初のDraft PRを作るところまでは、報告上 約9分32秒 でした。ただし、これは最初の依頼からPR作成までの時間で、後述するレビュー、追加検証、本番反映は含みません。自分が指示や確認に使った時間、利用トークンや料金も未計測です。
ちなみに、初回のGitHubへのpushは、メールアドレスの公開保護設定で拒否されました。Codexが変更記録（commit）に使うメールアドレスを公開用ではないnoreplyアドレスに直して、再試行しています。実装案の差し替えは0回でしたが、実作業にはこういう小さな引っかかりもありました。
CIが通っても、まだ確かめたいことが残っていた
最初のPR #19 ができたところで、今度はChatGPTとのチャットで、変更したコードと、GitHub上で自動実行されるチェック（CI）の結果を確認しました。
最初のCIは、lint（コードの書き方の確認）と通常のビルドが成功していました。ただ、Blogを配信しているCloudflare Pagesの本番環境でだけサイトマップを生成する設計なので、 通常のビルドが通っても、本番用サイトマップが正しく作られることまではCIで確かめられていません 。
ここは気になったのでCodexに追加で頼み、本番相当とPreview相当のビルド検証を追加してもらいました。更新後は既存のESLint・Buildに加え、SEO用の2ジョブも成功。本番相当とPreview相当のテストは各7件成功、比較用データのない各1件は意図的にスキップしています。
コードが正しくても、配信されているかどうかは別です。
実際、PR #19のPreviewが見つからず、Cloudflareの管理画面を確認してみると、Previewの自動デプロイが以前の特定ブランチだけに限定されていました。今回のブランチを追加すると、ようやくPreviewが作成されました。
Previewで robots.txt が Disallow: / を返し、本番用サイトマップXMLが配信されていないことを確認。さらにPowerShellでHTTPヘッダーを調べると、 x-robots-tag: noindex も付いていました。
ここは Codexがコードとテストを整え、チャット側で第三者レビューを行い、最後に自分がCloudflareの設定・画面を確認した 部分です。以前書いた ChatGPT×Codexの役割分担 を、そのまま保守作業にも当てはめた形になりました。
本番では20 URLのサイトマップが返ってきた
確認が終わったあと、自分が本番反映を承認し、チャット側からPR #19を本番用の main ブランチへ取り込みました。Cloudflare Pagesの本番デプロイとGitHub CIは、どちらも成功しています。
公開サイトの robots.txt にはサイトマップの場所が表示され、 sitemap-index.xml から実際の サイトマップ へたどれるようになりました。2026年10月25日の確認では、20 URLの中に公開済みのBlog記事12本が含まれていました。
Home、Blog一覧、記事、RSSの通常の配信も確認でき、既存の「いいね」APIも読み取りのGETで正常に応答しました。いいねの書き込みまで再検証したわけではありません。
これはあくまで、 サイトマップが正しく生成・配信されたという結果 です。検索エンジンに登録されたか、検索順位やアクセスが増えたかまでは、まだ分かりません。Google Search Consoleでの状態確認もこれからです。
9分で終わったのは、最初のPRまで
今回、AIに保守を任せるときの境界が少し見えた気がします。
Codexは、問題の発見、修正範囲の選択、実装、テスト、PR作成まで進められました。一方で、通常のCIで何が確認できていないかを考えることや、Cloudflare管理画面でPreviewの対象ブランチを確認すること、本番へ反映するかの判断は別に必要でした。
最初のPRを作る速さだけを見ると、かなり便利です。でも、それをそのまま「保守が9分で完了」と書いてしまうと、今回の作業とは違ってしまいます。
それでも、後回しになっていた保守を 自分がレビューできる形まで持ってきてもらう 使い方には、手応えがありました。全部を任せて忘れるのではなく、PRを境目に一度止める。今の自分には、こういう使い方が合っていそうです。
まだ、存在しないURLがトップページを返す問題や、末尾スラッシュ付きの転送先とcanonical URLが揃っていない問題は残っています。Search Consoleの確認も必要です。
次の保守も、また同じように小さく切り出してPRまで任せてみたいところです。面倒な作業が1つずつ片付いていくなら、新機能を増やすのとは違う意味で、Blogを続けやすくなりそうです。