AIに仕事を頼むなら『完了条件』を先に決める必要があった

「できました」と報告が返ってきた記事で、公開前に見直すと、決めていた条件を満たしていない箇所が残っていた ― これが何度かあった。報告が雑だったわけではない。

この連載の記事は、企画の一部から本文の執筆、図の組み立て、ビルドしての表示確認まで、AIに任せて作っている。1人での運用で、期間は約10日（2026-08-24〜09-03）。作業そのものは、任せた範囲で進んでいる。詰まったのは「作業が終わったかどうか」の判定のほうだった。

原因は、完了条件が「ちゃんと動く」「読みやすい」のような、測れない書き方だったことだ。測れない基準は、作った側も確かめる側も、それぞれの感覚で「できている」と解釈できてしまう。

そこで、着手前に完了条件を一覧にして、各条件へ「このコマンドを実行して、こうなればOK」「この画面をこう開いて、この要素が見えればOK」という確認手順を1対1で対応づけた。手順を書けない条件は、測れる形に書き直すか、人間が目で見る事項として別に分けた。

やってみると、確認役の判定がぶれなくなり、手戻りが出ても「どの条件のどこがFAILか」が具体的に分かるようになった。「読みやすさ」や「説得力」のような測れないものは、最後まで人間の確認に残った。

きっかけ・仮説

記事2で、「実装する担当に、できたかどうかを判定させない（確認は別の担当がやる）」という話を扱った。今回はその続きにあたる。

ただ記事2の時点では、その「完了」が「ちゃんと動く」「読みやすい」のような測れない書き方でも通っていた。手戻りが残ったのはそこだ。

記事2の芯は「誰が合否を判定するか」だった。今回の芯は「その判定を、何に対して行うか」だ。

そこで立てた仮説はこうだ。各完了条件に「何をどう実行して、どうなればOKか」という確認手順を1対1で対応づけ、手順を書けない条件は測れる形に直すか、人間の確認事項として分離すれば、確認が機能する。

どこまで言えるかも先に線を引いておく。確かめられたのは、1人が約10日、記事制作という狭い範囲で回してみた限りのことだ。手戻りが何回減ったか、記事が増えても完了条件の一覧を保守し続けられるか、他の種類の作業や多人数の現場でも同じことが言えるかは分からない。件数も時間も測っていないので、書くのはその範囲で見えたことだけになる。

やったこと（検証方法）

手順は5つ。

記事ごとに、着手前に完了条件の一覧を作る。作業を始める前に、「これができたら完了」という項目を書き出す。
各条件に確認手順を1つずつ付ける。コマンドを実行して結果を見る形か、具体的な操作の手順（この画面をこう開いて、この要素を見る）にする。
「動く」「正しい」「読みやすい」で終わっている条件は、測れる形に書き直す（下の表）。
書き直せない条件（美的な良し悪し・説得力など）は、人間が目で見る事項として別枠に分ける。無理に数値化しない。
確認役は、その手順をなぞってPASS / FAILを出す。作った本人の「できました」という自己申告では通さない。

「動く」「正しい」で終わっている条件は、次のように書き直した。

測れない条件（書き直し前）	測れる条件（書き直し後）
ビルドが通ること	決めたビルドコマンドの終了コードが0で、対象ページのHTMLが生成される
見出しの構成が正しいこと	本文の大見出しがちょうど8個で、決めた並び順と一致する
内部の情報が混ざっていないこと	決めた語の一覧で、本文と表示後のHTMLを検索して該当が0件

一方で、「読みやすい」「説得力がある」「図が分かりやすい」は、確認手順の形にできなかった。これらは測れる条件へ書き直すのをあきらめ、人間が見る事項として分けた。

測り方について。数値の指標は用意していない。手戻りがどう起きるか、確認役の判定がどれだけ安定するかを、実感ベースで見た。

起きたこと（検証結果）

曖昧な条件のときと、確認手順を付けたときで、起きたことが違った。

	曖昧なとき	確認手順つきのとき
完了条件の書き方	「動く」「正しい」「読みやすい」で終わる	各条件に実行手順と合格ラインが1つずつ付く
AIの動き	一通り作って「できました」と報告する	動き自体は変わらない
確認役の判定	「たぶん大丈夫」でぶれる	手順をなぞって同じ結論になる
手戻り	報告の後に条件の未達が見つかる	FAILの位置が具体的で、戻し先を選べる
かかるコスト	後の工程で増える	着手前に条件を書く分だけ前倒しで増える

曖昧な条件のときは、「できました」の報告のあとに、条件を満たしていない箇所が見つかった。確認役も、測れる基準がないので「たぶん問題ない」で通しがちだった。

確認手順を付けたときは、判定がぶれなくなった。FAILが出ても、どの条件のどこで引っかかったかが具体的に分かるので、「作り直す」のか「完了条件そのものを見直す」のか、戻し先を判断できた。

副作用もあった。完了条件を書くコストが増えた。ほんの数行を直すような小さい作業では、条件と手順を書くほうが作業本体より重い。これは記事2で書いた所感と同じだ。

もう一つ詰まったのは、測れない条件を無理に数値化しようとして、本質からずれた指標を作りかけたことだ。「読みやすさ」を文字数や1文の長さで測ろうとして、途中で「これは読みやすさそのものではない」と気づいた。結局、そこは人間の確認へ回すと割り切った。

わかったこと

「完了」は、作った側が宣言するものではなく、事前に決めた「測れる状態」と「それを確かめる手順」のことだった。この2つが無いと、「できました」は解釈の余地が残る言葉のままだ。

記事2では、判定する人を実装役から切り離した。それでも判定の当て先が「ちゃんと動く」「読みやすい」のままだと、確認役は結局「たぶん大丈夫」に戻った。役割を分けたことが効いたのは、当て先が測れる形になって、確認手順がそこに1対1で結びついてからだった。

そして、全部は測れない。美的な良し悪しや説得力は、確認手順の形にできない。それを無理に数値へ押し込めず、人間が見る事項として切り出すこと自体が、完了条件の設計の一部だった。

弱いところもある。対象は約10日、記事制作だけ、1人。条件の一覧が、今やっている作業に最適化されすぎているかもしれない。条件と手順を書く時間のコストは測っていない。記事の本数が増えたときに、一覧を保守し続けられるかも、まだ分からない。

実際どうなん？（まとめ）

作業を任せること自体は、この連載でずっとやっている。引っかかったのは、その成果を「完了」と認めるところだった。「できました」という報告をそのまま受け取れるようにするには、完了の基準を着手前に測れる形で書き出し、その一つ一つに「何をどう実行すれば合格か」という確認手順を結びつけておく必要があった。

いまはこの連載の記事を、着手前に完了条件の一覧を作ってから進めている。「完了条件さえ書けば手戻りが消える」わけではない。ただ、FAILが出たときに「どの条件のどこか」を指させるようにはなった。

補足・注記

実際の画面のスクリーンショットは載せていない。完了条件の一覧は内部のファイル名・パス・識別子を含んでいて、適切に伏せても掲載に適さないからだ。書き直しの例と結果の対比を示す表で代替した。