このブログでは、太字にしたつもりの記号が、そのまま本文に出てしまうことがありました。AI が書き終え、ビルドも通った後に、私が画面を開いて見つけていました。「できました」と言われても、結局は毎回見に戻る必要があります。
今は、出力した HTML にその記号が残っていたら失敗するスクリプトを置いています。AI が自分で実行すれば、私が画面を開く前に気づけます。用意したのは、記号が残ったページでは失敗し、直したページでは通る確認です。同じ不具合を試せるHugoの例題も載せました。
ビルドが通っても、記号が本文に残った
問題になったのは、次のような書き方です。
**「確認済み」**という表示です。
この形だと、Hugo が使う Markdown の処理では閉じ側の記号が太字の区切りにならず、読者にそのまま見えます。太字を閉じる記号の直前がかぎ括弧、直後が日本語の文字、という組み合わせでした。Markdown を HTML に変換する処理自体は成功するので、ビルドの終了コードは 0 です。
「ビルドを通して」と頼むだけでは見つかりませんでした。そこで、生成した記事本文を取り出し、コード例の外に記号が残っていないかを調べる check-post-output.pl を置きました。失敗したときに出るのは、対象の記事と、何が合っていないかです。
修正前に失敗し、修正後に通るか確かめる
例題一式をダウンロードする。展開した verifiable-environment-first フォルダに、最小のHugoサイト、問題のある記事、太字記号を取り除いた記事、検査スクリプトを入れています。HugoとPerlが必要です。テーマのダウンロードは要りません。
まずビルドします。以下は2026年9月22日、Hugo 0.165.0で確認した出力です。例題の実行であって、AIに修正を任せる実験ではありません。
$ hugo --source blog-site --quiet
$ echo $?
0
ビルドは通りました。そのまま、問題のある記事を検査します。
$ perl scripts/check-post-output.pl blog-site/content/posts/2026-09-22-broken.md
NG: blog-site/content/posts/2026-09-22-broken.md
ソースに ** が 2 個あるのに、本文の <strong> が 0。全部が閉じていないか、別のページを見ている。
$ echo $?
1
続いて、太字記号を外した記事へ同じコマンドを当てます。
$ perl scripts/check-post-output.pl blog-site/content/posts/2026-09-22-fixed.md
OK: blog-site/content/posts/2026-09-22-fixed.md（本文 626 文字, ソースの **=0, 本文 <strong>=0, 生の **=0, em ダッシュ=0, 禁止語=0）
$ echo $?
0
直した後に通ることだけを見ても、この不具合を検出できるかは分かりません。問題が残っている状態で失敗するところまで確認しておけば、AIにも同じ確認を渡せます。
このスクリプトは、本文を囲むHTMLや出力先をこのブログに合わせてあります。別のサイトで使うなら、取り出している本文と対象ファイルが合っているかを確かめてください。引数を渡さない場合などは何も検査せず終了するため、終了コードに加え、結果に目的の記事が出ていることも見ます。
「OK」が何を見ているかも確認する
検査を置いたら終わり、というわけでもありません。9月22日のこのブログの検索改善では、表示確認のスクリプトが「OK」を返したのに、撮影された画面は「記事を読み込んでいます…」のままでした。
横へのはみ出しや配色は確認していましたが、検索結果の取得が終わる前に撮影していました。見たかったのは、検索結果が並んだ画面です。結果の読み込み完了を待ってから確認し、取得に失敗した場合はエラーにするよう直しました。修正後は「指示」の検索結果12件が出た画面を確認できました。
| 確認したこと | それだけでは分からなかったこと |
|---|---|
| Hugoのビルドが成功した | 記号が読者にそのまま見えていないか |
| 記号の検査が通った | 目的の記事を実際に検査したか。文章が伝わるか |
| ページが開き、横にはみ出していない | 検索結果を読み込み終え、表示できているか |
「よく確認して」と一文足すよりも、今回見つけたい不具合で検査が止まるかを見るほうが、何を任せられるか分かります。検索画面では、結果が出るまで待つ、という条件が足りていませんでした。
毎回自分が見つけている不具合を、一つ移す
私の手元でまず任せられたのは、記事の内容を読む前の、記号の露出を探す作業でした。期待する状態をコマンドで確かめられれば、失敗を読んで修正するところまでAIに頼めます。
自分の作業で始めるなら、直近の修正で人が見つけた不具合を一つ選びます。その不具合が残った状態では失敗し、直した状態では通るコマンドを用意する。AIが同じ場所で実行できるよう、必要な依存関係や起動方法も揃えます。たとえば画面の確認なら、URLを渡すだけでなく、何が表示されるまで待つかも必要でした。
準備に時間を使うことを、最初から見込む
AWS の Clare Liguori 氏の講演「From AI-Assisted to AI-Native: Building a Frontier Development Team」でも、成果が出たチームの習慣として、開発をいったん減速してコードやエラーメッセージを整理すること、lintやローカルのモックサーバーですぐに検査できるようにすることが挙がっていました(8:26以降、2026-09-12に自動字幕で確認)。準備への投資を経営側が受け入れる必要もある、という話です(17:02以降)。
気になったのは、最初に開発を減速するところです。AI を入れたのだからすぐ速くなるはず、と思っていると、この準備には時間を使いにくい。エラーを読んでも原因が分からない、テストを動かすにも人の手が要る、という状態を先に直す話として読みました。
Claude Code の Best practicesも、テストやスクリーンショットなど、自分の仕事を検証する手段を与えるよう勧めています。GitHub Copilot cloud agent の Get the best resultsにも、開発環境でビルドやテストを実行できるようにする案内があります(ともに2026-09-22再確認)。
人の確認がどれだけ減ったかは、同じタスクで前後比較していません。文章が伝わるかどうかも、記号の検査では分かりません。それでも、毎回同じ記号を探す作業にはコマンドを使えます。次に「またこれか」と思う不具合を見つけたら、問題が残ったままでも検査を通り抜けていないか、まず確かめます。