はじめに
「もう少しよくして」「もっと説得力を出して」。何度か頼み直した結果、文章は力強くなったのに、最初になかった実績まで加わっていた。
これも、起こり得る失敗を説明するための例です。修正を重ねることと、内容が正しくなることは同じではありません。何を検査し、どの結果を受けて直し、どこで止めるのか。今回は、その繰り返しを設計します。
ループエンジニアリングの発想を借りる
ループエンジニアリングを扱う2026年8月の論文では、システムがエージェントの実行を促し、機械で判定できる停止条件で実行を区切る仕組みが論じられています。状態の記録、予算、人への引き継ぎも論点です。ただし、これはソフトウェア開発を中心とした探索的研究で、確認した版には査読中と記されています。arXiv「Loop Engineering: Building Blocks, Adoption, and Impact」
普通のチャットで修正を頼むことが、そのまま論文の自律ループと同じになるわけではありません。ここでは、その発想を借りて、人が確認を担当する小さな「作成→検証→修正」の手順をつくります。
先に、合格と保留を決める
架空の「まちのWeb相談室」の記事を例にします。資料Aの確定仕様は、小規模事業者向けのWeb制作、相談後の個別見積もり、公開後の更新は別契約の三点です。料金の金額、納期、実績件数は未確認とします。
この例なら、合格条件を次のように決められます。
- 料金・実績・対応範囲の主張に、資料の根拠がある。
- 個別見積もりと別契約の条件が抜けず、他の段落とも矛盾しない。
- 本文は600〜800字で、初めて依頼する人に必要な説明がある。
- 未確認事項を本文の事実として補わず、別の一覧に残している。
さらに、今回は修正を最大2回までと決めてみます。これは一般的な推奨回数ではなく、試すための例です。2回で重要な条件を満たせなければ、人に相談して保留します。回数や時間の上限に達したことを、合格の代わりにはしません。
同じ誤りを、きれいに繰り返さない
例えば、下書きに「月額1万円から」と書かれていたら、「もっと正確に」とだけ返さず、根拠がない箇所を指定します。
「資料Aには料金の金額がありません。『月額1万円から』を削除し、相談後に個別見積もりとなることを伝えてください。新しい金額は補わないでください。ほかの契約条件は保持してください。」
これは実験結果ではなく、修正依頼の文例です。AIの返答が「修正しました」で終わっても、そこで確認を終えず、実際の本文を読み直します。削除した価格が別の段落に残っていないか、代わりに根拠のない「最短3日」などが増えていないかも見ます。
別のAIに採点させる方法を使っても、同じ不正確な資料に頼っていれば、同じ結論になる可能性があります。AI同士の賛成票ではなく、承認された仕様との照合を判断の中心に置きます。
修正記録は、次の判断に使う
| 版 | 見つけた問題 | 対応・判断 | 再確認すること |
|---|---|---|---|
| 初稿 | 根拠のない金額がある | 金額を削除し、個別見積もりと記す | 本文全体に未確認の価格が残っていないか |
| 修正1 | 別契約の条件が抜けた | 更新は別契約と明記する | 他の段落が「更新込み」と読めないか |
| 修正2 | 合格条件の確認が未了 | 合格条件を満たせば人が最終確認へ、未達なら保留 | 未確認事項と掲載内容が区別されているか |
この表も説明用の架空の記録です。実際の作業では、見つかった問題と対応をそのまま書きます。直した箇所だけでなく、すでに合格した条件が壊れていないかを再確認するために使います。
自動化する場合は、回数・時間・費用の上限や停止判定を実行システム側にも実装します。チャットに「2回で止めて」と書くだけで、利用料金や外部操作が確実に制限されるとは限りません。
繰り返しが役立ったかを確かめる
初稿と最終稿で、根拠のない主張と必須条件の抜けを同じ基準で数えます。それに加え、確認にかかった時間、修正回数、分かる範囲の利用費用を残してみてください。
文章が長くなっただけなら、よくなったとは言い切れません。誤りは減っても確認時間が大幅に増えるなら、対象を絞る余地があります。終わりのない修正より、必要な確認を終えたことが分かる手順を目指します。
次回は、こうした作業を複数の担当や工程へ分けるとき、どうつなげるかを考えます。
