AIに記事を書かせたら、AIより先に評価条件が壊れた——ループエンジニアリング実践記

先日、「ループエンジニアリングについて、ループエンジニアリングで書いてみた」という記事を公開しました。

調査資料を整理し、構成を作り、初稿を書き、批判的なレビューと事実確認を行い、修正する。記事のテーマを、そのまま記事の制作方法にも使ってみる実験です。

完成稿だけを見れば、それなりに整った一本の記事です。

でも、今回いちばん面白かったのは完成稿よりも、そこへ至る途中でした。

初稿は一見すると、もう完成しているように見えました。必要な見出しがあり、中心となる主張があり、実際に起きた失敗も書かれている。僕自身も、悪くないと思っていました。

ところが、批判的な編集者としてレビューさせると、MAJORが6件、MINORが6件。さらに事実確認では、参考にした記事の日付が一日ずれ、ワークフローとループの説明も単純化しすぎていると分かりました。

AIに記事を書かせる仕組みを作ったはずが、AIより先に、人間が作った評価条件や説明の粗さが見つかっていく。

今回は、その修正過程を制作ログとして残します。

初稿は「間違い」ではなかった

最初に断っておくと、初稿はひどい文章ではありませんでした。

冒頭では、AIが作った資料はきれいに整っているのに、作った本人が説明できないことがある、という違和感から始めています。そして、ループエンジニアリングを次のように説明していました。

AIへの一回の頼み方ではなく、作る、確かめる、直す、止めるまでを仕組みにすること。

この記事の中心となる考えも、制作中に起きた「不足0件なのに不合格になった」という失敗も、すでに初稿へ入っていました。

つまり、材料はあったのです。

問題は、その材料が読者へ届く順番と、僕自身がどこまで文章の責任を引き受けられるかでした。

「不足0件」なのに、不合格になった

文章のレビューへ進む前に、制作の仕組み自体でも問題が起きました。

不足している情報を整理する工程で、必要な材料は揃っていたため、「未解決のMUSTは0件」と記録しました。ところが検証器は、文章の中に「MUST」と「不足」という言葉があることだけを見て、「未解決の不足がある」と判定しました。

0件なのに、不合格です。

評価条件を厳しく作れば品質が上がると思っていました。でも、判定方法が雑なら、正しい成果物も落とします。反対に、指定された言葉だけを入れれば、中身が弱くても通過できるかもしれません。

そこで、0件と1件以上を区別して判定するように検証器を直しました。

ここで分かったのは、完了条件を決めるだけでは足りないということです。その条件をどう判定するか、その判定自体が正しく動くかも確かめなければならない。

記事のレビューを始める前に、まず評価する側がレビューされることになりました。

レビューで最初に言われたこと

批判的レビューで最も大きかった指摘は、次のものでした。

この記事で最も独自性のある制作実験へ到達するまでが長い。

初稿は、ループエンジニアリングの定義、プロンプトとの違い、完了条件の説明を一通り終えてから、ようやく今回の実験へ入っていました。

説明としては順番どおりです。でも、読者から見れば、前半は一般的な用語解説にも見えます。記事の中でしか読めない失敗談が後半に埋まっていたのです。

そこで完成稿では、導入の段階でこう予告しました。

すると、AIより先に、人間が作った評価条件の方が二度、三度とつまずきました。

結論を先に全部言うのではなく、「このあと実際に何かが起きる」と知らせる。これだけで、定義の説明を読む意味が少し変わりました。

抽象的な問題提起を、一つの場面へ変えた

初稿の導入では、AIが作った制度や設計をそのまま組織へ当てはめると、細かな事情が抜け落ちる、と書いていました。

僕が以前から感じていた問題ではあります。ただ、そのままでは話が大きすぎます。他人や組織を外側から批判しているようにも読めます。

レビューでは、「本人がどこで、どんな感覚を持ったのかが見えない」と指摘されました。

そこで、完成稿では一つの場面に絞りました。

「なぜこの項目が必要なんですか」「何を根拠にこの結論を出したんですか」と聞かれた途端、説明する人が画面を見返しながら言葉に詰まる。

さらに、「ただ、これは他人事でもありません」と続けました。

僕自身も、問いを深めることは好きなのに、仮説ができて検証へ進む段階で、また問いへ戻ってしまうことがあります。
AIへ雑に任せることと、考えすぎて何も出さないこと。一見すると反対ですが、どちらも完了条件を決めていないという点では似ています。

ここが入ったことで、記事はAI活用への一般的な批判から、自分自身を含めた話へ変わりました。

分かりやすさのための説明が、不正確だった

初稿では、プロンプト、ワークフロー、ループを初心者向けに次のように分けていました。

• プロンプトは一回の頼み方
• ワークフローは処理の順序
• ループは出来上がったものを評価する仕組み

分かりやすくはあります。ただし、ワークフローの中にも分岐、評価、反復は含まれます。「ワークフローには評価がなく、ループにだけある」と受け取られる可能性がありました。

そこで完成稿では、別々のものとして線を引くのではなく、次のように直しました。

ループは、結果を次の入力へ戻すフィードバックに注目します。

そして、ループを「作業結果を見て次の行動を変え、決めた完了条件へ近づけるワークフロー」と説明しました。

初心者向けだから単純にしてよい、とは限りません。分かりやすさのために削った部分が、別の誤解を生むこともある。ここは、レビューだけでなく事実確認を入れた意味が大きかったところです。

事実確認で、一日ずれていることが分かった

事実確認では、文章の中から事実として読める主張を抜き出し、VERIFIED、PARTIALLY_VERIFIED、UNVERIFIED、OPINIONに分類しました。

公開を止める重要なUNVERIFIEDは0件でした。ただし、そのままでは出せない表現が四つありました。

例えば、調査資料ではAddy Osmaniによる「Loop Engineering」の公開日を6月7日としていましたが、公開ページを確認すると6月8日でした。

また、初稿の「2026年に広がった新しい言葉」という表現も、広がりの規模までは確認できませんでした。そのため、完成稿では「少なくとも2026年6月以降、実務者による発信で目立つようになった」と範囲を限定しています。

一日の違いで記事の主張が崩れるわけではありません。それでも、確認できることを確認せずに出せば、「評価と検証が大事だ」と書いている記事そのものが、主張に反してしまいます。

指摘は、すべて機械的に採用しなかった

レビューの役割は、書き手の代わりに正解を決めることではありません。

今回、ほとんどの指摘は採用しました。一方で、「構成は93点だった」という記述については、削除せずに残しました。

自己採点の数字は、読者によっては内輪のゲームに見えます。レビューでも、その危険を指摘されました。

それでも数字を残したのは、93点でも人間が承認しなければ本文へ進まなかった、という事実が、人間の役割を説明する具体例になると考えたからです。

代わりに、「評価項目上は93点」「形式上通過したという意味でしかない」と限定しました。

指摘を受け入れることと、指摘されたとおりに直すことは同じではありません。何を残し、何を捨てるかを決めるところにも、人間の仕事がありました。

初稿から完成稿へ、何が変わったのか

大きな変更をまとめると、次のようになります。

文章の骨格は同じです。主張も大きくは変えていません。

でも、初稿は「必要な項目が入った文章」で、完成稿は「僕が根拠と判断を説明できる文章」へ少し近づいたと思います。

ループは、文章をきれいにするためだけのものではなかった

最終評価は93点でした。

事実の正確性は25点中24点。初心者への分かりやすさは20点中18点。著者独自の視点は20点中20点。一方、「過度なAI文章感がないこと」は10点中7点でした。

合格基準は超えています。それでも、全体が少し長いことや、表や対句が整いすぎて見えることは残りました。

ここで、もう一度修正を続けることもできます。ただ、AI文章感を消そうとして文章を崩し続ければ、それは別の「終われないループ」になります。

だから、これ以上は自動で直さず、最後は人間が読み、本人の言葉として公開できるかを判断しました。

今回のループがしたのは、文章を完璧にすることではありません。

どこに問題があるかを見えるようにし、何を直すかを記録し、どこから先は人間が引き受けるのかを決めることでした。

初稿は間違いではなかった。でも、初稿を「できました」と呼ぶだけでは見えなかったものがあった。

作る。確かめる。直す。そして、止める。

ループエンジニアリングについて書いたことで、結局いちばん学んだのは、やはり「終わり」の決め方だったのだと思います。