LOG_002実証2026.07.25

AIが書いたコードを、別のAIにレビューさせた

当社のコーポレートサイトに、記事の下書きを公開前に確認できる機能を追加しました。実装したのはAIです。そして書き上がったコードを、別のAIに「粗探しをする側」として読ませました。

結果は指摘が2件。どちらも、気づかないまま公開していたら困る種類のものでした。その一部始終を記録しておきます。

これまで、記事を書いてから公開するまでの間に、実際の見た目を確かめる方法がありませんでした。管理画面の編集欄では、見出しの大きさも、画像の収まりも、スマホでの改行位置も分かりません。公開して初めて「ここが崩れている」と気づく、ということが何度かありました。

そこで、下書きのまま本番と同じ画面で確認できる仕組みを作ることにしました。編集画面のボタンを押すと、その下書きがサイト上で表示される——それだけの機能です。

ただし、それだけの機能にも落とし穴があります。下書きは公開前の情報なので、他人に見えてはいけません。「自分だけが見られる」を成立させる部分に、慎重さが要ります。

当社では、実装するAIとは別のAIに、敵対的な立場でコードを読ませています。「問題がないか確認して」ではなく、「どこが壊れるかを探せ」という頼み方です。

今回の指摘は2件でした。1件目が特に効きました。要約すると、こういう問題です。

記事Aの下書きを開き、次に記事Bの下書きを開く。そのあとAのタブに戻って再読み込みすると、Aは下書きではなく公開版が表示される。しかも何のエラーも出ません。

これは地味に見えて、いちばん困る壊れ方です。編集者は「Aの下書きを確認した」と思っている。でも実際に見ていたのは公開版で、直したはずの箇所は画面に映っていない。確認したつもりで、確認できていない。プレビュー機能が果たすべき役割そのものが失われます。

2件目は、有効期限の扱いが噛み合っておらず、時間が経つと「プレビュー中のようで中身は公開版」という宙ぶらりんの状態になる、というものでした。性質は1件目と同じで、やはり「別のものが黙って表示される」系です。

どちらも修正しました。ここまでは、AIのレビューが素直に効いた話です。

問題はこの先です。修正が終わり、実際の下書きで動作を確認して、あとは公開するだけ——という段階まで来ていました。

そこで、こういう指示を出しました。「未公開の新規下書きだけでなく、すでに公開済みの記事を編集した下書きでも試してください」。

理由は単純で、日常的に多いのは後者だからです。新しく記事を書き下ろすより、公開済みの記事を直して確認する方が回数は多い。テストが片方に偏っていたので、もう片方も確かめたかっただけでした。

そして、そこでバグが出ました。

公開済み記事の下書きは、1本残らずプレビューに失敗していました。原因を追うと、使っていたシステムの仕様に行き当たります。下書きを保存すると、公開版の情報にも同じ更新時刻が書き込まれる。つまり「更新時刻が違えば下書き」という判定方法が、そもそも成り立たない前提だったのです。

これは説明書を読んでも書いていない挙動でした。実際に両方を取得して並べてみて、初めて分かった。判定方法を変えて解決しましたが、あの1回の指示がなければ、公開済み記事のプレビューが全滅した状態のまま世に出ていました。

今回の経験から、はっきりしたことが2つあります。

1つは、AIに敵対的なレビューをさせる価値です。「確認したつもり」を生むバグは、書いた本人（AIでも人間でも）には見えにくい。正常に動く経路を辿ってしまうからです。別の立場で読ませると、こういう穴が出てきます。

もう1つは、それでも足りない部分があることです。AIのレビューが見ていたのはコードの中の整合性でした。一方で私が出した指示は、「この機能を実際に使うとき、どういう操作が多いか」という現場の話です。どちらか片方では届かない場所に、今回のバグはありました。

作るのはAI、疑うのもAI。それでも「実際にどう使われるか」を持ち込むのは、まだこちら側の仕事だと感じています。裏を返せば、その一言さえ出せれば、実装もレビューもAIに任せられる時代になったということでもあります。

機能そのものは、いま本番で動いています。記事を書いて、下書きのまま見た目を確かめて、納得してから公開する。地味ですが、毎回の作業が確実に楽になりました。

AI開発コードレビューmicroCMS内製

「これ、うちでもできる？」と思ったら。