AIに仕事をさせるより、「終わり」を決める方が難しかった

きれいなのに、なぜか信用しきれない

何度か、こんな場面を見ました。

AIで作られた資料は、驚くほどきれいに整っている。見出しがあり、表があり、要点も並んでいる。でも、「なぜこの項目が必要なんですか」「何を根拠にこの結論を出したんですか」と聞かれた途端、説明する人が画面を見返しながら言葉に詰まる。

見た目は完成しているのに、その中身を誰も引き受けられない。

僕は、この状態にずっと引っかかっていました。AIが作った制度や設計をそのまま組織へ当てはめた結果、現場の細かな事情が抜け落ちることもあります。

ただ、これは他人事でもありません。

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

今回「ループエンジニアリング」を調べて、そんな仮説が浮かびました。

AIに仕事をさせることよりも、何をもって完了とするかを決める方が難しい。

そこで、この仮説を説明するだけでなく、この記事自体をループで作ってみることにしました。

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

ループエンジニアリングとは何か

「ループエンジニアリング」は、少なくとも2026年6月以降、AIエージェントの実務者による発信で目立つようになった言葉です。

Addy Osmaniは6月8日、人間がエージェントへ逐次指示を出す代わりに、仕事を見つけ、依頼し、確認し、次の行動を決める仕組みを設計する考えとして紹介しました。その後、LangChainやIBMも、それぞれ異なる範囲でこの言葉を説明しています。

現時点では、確立した標準というより新興の実務用語です。AIの生成・評価・修正や、ソフトウェアのテスト自動化など、以前からある考え方との重なりも大きい。完全な新技術とも、ただの言い換えとも言い切れません。

僕はこの記事では、ひとまず次のように捉えます。

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

「プロンプトエンジニアリングは終わった。これからはループだ」と言い切るのは、少し大げさです。プロンプトはループの中でも使います。なくなるのではなく、その外側まで設計する範囲が広がる、と考える方が近いでしょう。

プロンプト、ワークフロー、ループの違い

会議メモを例にします。

プロンプトは、AIへの一回の頼み方です。

この会議メモを要約してください。

ワークフローにすると、要約し、メール形式へ整え、決めた場所へ保存する、といった処理の道筋になります。ワークフローの中にも、分岐や確認、反復を含めることはできます。

ループは、その中でも特に「結果を次の入力へ戻すフィードバック」に注目します。

会議メモを整理したあと、決定事項・担当者・期限・未決事項が揃っているかを確認する。不足があれば、その不足を次の指示へ戻す。条件を満たしたら終了し、最大回数に達しても判断できなければ人間へ返す。

つまり、ループはワークフローと排他的な別物ではありません。作業の結果を見て次の行動を変え、決めた完了条件へ近づけるワークフローと捉えると分かりやすいと思います。

同じプロンプトを何度も投げて「もっと良くして」と頼み続けるだけでは、終わりのないやり直しです。大事なのは回数ではなく、前回の失敗が次の一回へ反映されているかです。

「完成」は一つの条件では決まらない

では、何をもって完成とするのか。

今回の調査をもとに、僕は完了条件を五つに分けてみました。これは業界標準の分類ではなく、考えるための整理です。

ファイルがあり、文字数を満たしていれば、形式としては完成です。でも、初心者が読んでも分からなければ目的は果たせていません。読みやすくても、根拠のない事実を断定していれば公開できない。正確でも、一般論をきれいに並べただけなら、僕が書く理由は薄くなります。

反対に、条件を増やしすぎれば、いつまでも出せません。「もっと分かりやすく」「もっと独自に」「もっと正確に」と足し続ければ、永遠に未完成です。

完了条件は品質を守る線であると同時に、考え続けて止まる自分を、次へ進ませる線でもあるのだと思います。

ループについて、ループを使って書いてみた

今回の制作工程は二重になっています。

内側では、調査資料を整理し、不足を探し、構成を作り、採点し、本文を書き、批判的に読み、事実確認をして修正する。

外側では、制作中に起きた失敗を記録し、評価基準や指示、ループそのものを直す。

つまり、

ループエンジニアリングについて、ループエンジニアリングを使って記事を書く。

という実験です。

最初に、制作工程を10段階に分けました。構成が80点未満なら戻る。重要な未検証情報が残れば公開候補を作らない。同じ問題が二回続くか、修正が三回に達したら止める。構成完成時と公開前には、人間の承認を求める。

仕組みを作った時点では、なかなか良くできた気がしていました。

ところが、実際に回すとすぐ止まりました。

最初の停止――材料が入っていなかった

調査資料と著者メモを読む前提で仕組みを作ったのに、肝心の資料本文がまだ投入されていなかったのです。

一般知識から、それらしい構成を作ることはできたと思います。でも、「確認できない情報を推測で補わない」という条件に従い、最初の資料整理でHOLDになりました。

記事は一文字も進みませんでした。

作業としては失敗です。ただ、材料がないのに、あるような顔をして進むよりはいい。止まったことは、停止条件が機能した証拠でもあります。

二度目の停止――「不足0件」が不合格になった

資料を追加して再開し、不足分析に進みました。必要な情報は揃っていたため、「未解決の必須情報は0件」と記録しました。

ところが検証器は、文章の中に「必須」と「不足」という言葉があることだけを見て、「未解決の不足がある」と判定しました。

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

0件と1件以上を区別できるよう検証器を直しましたが、構成確認でも似たことが起きました。意味として要件を満たしていても、指定された言葉と一致しないため停止したのです。

ここで、少し笑ってしまいました。

AIを厳しく評価する仕組みを作ったつもりが、そのAIより先に、僕が書いた評価条件の雑さが露呈したからです。

評価を厳しくすれば品質が上がる、というほど単純ではありません。評価方法が雑なら、正しい成果物を落とします。逆に、指定された言葉だけを入れれば、中身が弱くても通過できるかもしれない。

完了条件を決めるだけでは足りない。完了条件をどう判定するかも、検証しなければならない。

これは、実際にループを回さなければ得られなかった学びでした。

人間はループのどこに残るのか

ループを作るというと、人間の仕事をどこまで自動化できるか、という話になりがちです。

でも僕は、人間の役割が消えるというより、位置が変わるのではないかと思います。

目的は何か。何は対象外か。どの証拠を信用するか。どこまでの失敗を許すか。何回で止めるか。例外を誰へ渡すか。そして、外へ出してよいか。

今回の構成も、評価項目上は93点でした。ただし、その数字は基準を形式上通過したという意味でしかありません。読みたい文章か。本人の言葉に見えるか。実験が後付けの演出に見えないか。数字は、そこまで保証してくれません。

だから構成段階では、人間が承認してから本文へ進みました。

細部を毎回確認しなくてもよい仕組みは作れます。しかし、「毎回確認しなくてよい」と「中身を理解しなくてよい」は別です。

UK NCSCは、AIエージェントを安全に導入する原則として、動作の可視性と意味のある人間監督を維持し、理解・監視・封じ込めができないものは導入準備ができていないとしています。NIST AI RMFも、文書化、人間によるレビュー、役割と責任の明確化を重視しています。

作業を手放すことと、責任を手放すことは同じではありません。

まずは会議メモで、小さく試してみる

最初から、長時間動くAIエージェントや複数のAIを組み合わせる必要はありません。

仕事でAIを使い始めた人なら、外部送信を伴わない「会議メモの品質確認」から試せます。

最初の指示は、これくらいで十分です。

以下の会議メモを、
1. 決定事項
2. 担当者
3. 期限
4. 未決事項
の4項目に整理してください。

原文に書かれていない内容は推測せず、
該当情報がなければ「記載なし」と書いてください。

次に、原文と整理結果を一緒に渡して確認します。

会議メモの原文と整理結果を比較してください。

確認するのは、
- 4項目の欠落
- 原文にない内容の追加
- 担当者や期限の取り違え
です。

問題があれば該当箇所だけを示し、
問題がなければ「確認完了」と書いてください。

不足があれば、その箇所だけ一度修正する。最大二周で止め、それでも判断できなければHOLDとして人間へ戻す。最後は人間が原文と照合してから保存し、いきなりメール送信や外部共有までは自動化しません。

そして、AIが直した箇所だけでなく、最後に自分が直した箇所を記録します。

数件試せば、自分の会議メモでは期限が抜けやすい、担当者をAIが推測しやすい、といった傾向が見えてきます。それを次の評価条件へ足せば、ループそのものを改善する外側のループも回り始めます。

会議メモ以外の仕事で試す場合も、最初に決めることは同じです。

AI時代に必要なのは、頼み方だけではない

プロンプトは、これからも重要です。ただ、よい頼み方ができれば、よい仕事が完成するとは限りません。

作る。確かめる。直す。止める。

そこまで設計して、ようやくAIの出力が再現可能な仕事へ近づいていきます。

今回の制作ループも、資料不足で止まり、評価器の読み違いで止まりました。さらに批判的なレビューでは、初稿が説明過多で、最も面白い実験まで遠いと指摘されました。事実確認では、参考資料の日付が一日ずれており、ワークフローとループの説明も単純化しすぎていると分かりました。

初稿は、形式上は完成していました。でも、公開できる完成ではなかった。

この違いこそ、今回ループを回して見えたものです。

AIに何を頼むかの前に、何をもって終わりとするかを書いてみる。

ループは、そこから始まるのだと思います。

主な参考資料

• Addy Osmani, “Loop Engineering”
• LangChain, “The Art of Loop Engineering”
• IBM, “What Is Loop Engineering?”
• Anthropic, “Building effective agents”
• UK NCSC, “Thinking carefully before adopting agentic AI”
• NIST AI RMF Core