人類がキーボードの前に座ってエージェントに一行ずつ指示を出す必要があった頃、核心的能力はプロンプトの作成だった。現在では、エージェントは目標を一つ与えるだけで自ら動作できるようになり、新たな核心的能力はループエンジニアリングとなった。

記事作成者：CyrilXBT

文章編集、出典：ME News

2026年6月、1週間のうちに、3人がそれぞれ独立して同じ結論に至った。

OpenClawの開発者であるPeter Steinbergerは、人々がプログラミングエージェントに直接プロンプトを書き込むのをやめ、エージェントに自動的に指示を出すサイクルシステムを設計すべきだと公開しました。

ほぼ同時に、Anthropic Claude Codeの責任者であるBoris Chernyも、自身はもはやClaudeに直接プロンプトを入力していないと述べた。現在、彼はClaudeを自動的に呼び出し、次に何をすべきかを判断するループを実行しており、彼の本当の仕事はこれらのループを書き、設計することである。

数日後、GoogleのエンジニアであるAddy Osmaniがこの実践を体系的にまとめ、名前を付けた：

Loop Engineering、循環工学。

彼らはこの働き方を空想で生み出したのではなく、すでに静かに進行していた変化に名前をつけただけである。

これまでに、基盤ツールは重要な臨界点を越えた。プログラミングエージェントが無人で本物のタスクを完了できるようになり、自動スケジューリングのコストが十分に低くなり、タスクを繰り返し定时実行することが無駄とは言えなくなった。また、エージェントの1回の実行コストも新たなレベルに下がった。一度じっくりと考えるよりも、エージェントに5回試させたほうが、むしろコストが低くなる可能性がある。

これがこのロードマップが存在する理由です。

人類がキーボードの前に座ってエージェントに一行ずつ指示を出す必要があった頃、核心的能力はプロンプトの作成だった。現在では、エージェントは目標を一つ与えるだけで自ら動作できるようになり、新たな核心的能力はループエンジニアリングとなった。

以下是从提示词操作者迈向系统设计者的完整20步路径。必須按順序推進，因為在此路徑中，步驟之間的先後關係往往比任何單獨的步驟都更加重要。

ループプロセスは、「習得した」か「習得していない」かの単一のスキルではなく、段階的に積み重なる能力のスタックです。各段階は、その下の基礎が十分に堅固であることに依存しています。

たとえば、第10ステップで実際のストップ条件を設定する前に、第14ステップの自動スケジュールトリガーを構築すると、無人状態で資金を自動的に無駄にするシステムができあがります。過去は少なくとも画面を監視しているときにだけリソースを無駄にしていたものが、今や自ら継続的に資金を消費するようになります。

同様に、第6ステップと第7ステップの信頼できる検証メカニズムを完了する前に第11ステップの永続的メモリ層を構築すると、過度に緩いエラーを繰り返し許容する「レビュアー」がまとめた経験を真剣に保存してしまう可能性があります。

これはシステムの進歩を助けるどころか、誤った経験が蓄積され、記憶層が「一時的に無用」から「積極的に有害」に変わってしまうことになります。

したがって、いくつかのステップをスキップすることは、単に機能を一つ実装しないこと以上の問題です。より深刻なのは、そのようにして見かけ上魅力的な高度な機能を、それらを支えることができない基盤の上に構築してしまうことです。そして、システムがすでにスケールして実際の影響を生じた後になって、ようやく問題に気づくことがよくあります。

第1段：思考方式の転換を実現 ステップ1：ボトルネックはモデルではなく、あなた自身にあることを認めること

本当の第一歩は、どんな技術にも関係しません。

現在のワークフローにおいて、効率を制限する要因はもはやモデルの能力ではなく、あなた自身がまだループの中にとどまっていることであることを認めなければならない。

モデルの回答を待って、結果を読み、次のコマンドを入力するたびに、あなたはシステム全体で最も遅い部分になります。

モデルは実行、検証、再試行が可能であり、これらの操作は人間が段階的に監督してタスクを完了させるよりもはるかに高速です。

このステップには対応するプロンプトがありません。これは認知的な判断です。

あなたがこれを本当の意味で受け入れるまで、その後のすべてのステップは、システム内の最大の効率ボトルネックを除去するという本来の意味ではなく、不要な追加作業に見えるでしょう。

モデルの出力に問題が発生した場合、人々が最も自然に取る対応は、元のプロンプトに新たなルールを追加することである。

数ヶ月後、このやり方は、内容が濃密で矛盾し、モデルの作業記憶に同時に処理しきれないほど長大なルールの壁を築くことになる。

最終的に、モデルは最近出現した内容や最も目立つ内容に基づいてパターンマッチングを行い、気づかないうちに他のルールを無視してしまうことが多いです。

サイクルエンジニアリングはこの考え方を根本的に変えました。

問題が発生したとき、あなたはプロンプトに新しい要件を追加するのではなく、システムに新しいコンポーネントを追加します。例えば：

• 独立した検証ステップを追加する；
• メモリーファイルを追加する；
• タイマートリガーを追加する；
• 構造化されたレビュー工程を追加します。

外部システムの能力が強化されるにつれて、プロンプト自体は長くなるのではなく、短くなるべきです。

どのようなタスクの分野に属するかに関わらず、ループの各実行は、以下の5つの基本的な動作に分解できます：

識別、引き渡し、検証、永続化、スケジューリング。

ディスカバリー

明確に、本当に達成すべきタスクを理解してください。

ハンドオフ

タスクを実行を担当するモデル、エージェント、またはツールに委任してください。

認証

実際の基準に基づいて結果が正しいか確認してください。

パーシステンス

今回の実行で何が起こり、何を学んだかを記録し、次回の実行時に経験を失わないようにしましょう。

スケジューリング

このプロセスをいつ再実行するかを決定します。

大多数人の現在のワークフローには、タスクの識別とタスクの引き継ぎという2つのアクションのみが明確に含まれており、通常はチャットウィンドウで手動で実行されています。

他の3つの行動は、存在しないか、人間自身の脳の中に隠されている。

ループプロセスの核心は、この5つのアクションをすべて明示化し、可能な限り自動実行することです。

システムを構築する前に、すでに繰り返し実行しており、品質基準を明確に説明できるタスクを選んでください。

最も難しい問題を選ばず、全く先例のないイノベーションタスクも選ばないでください。

最初の候補タスクは、以下の3つの条件を満たす必要があります。

1. それを繰り返し実行する必要があります；
2. それは書き留めることができる明確な基準を持っている；
3. それは明確に識別できる「完了状態」を持っています。

言い換えれば、同僚が結果を見た後、そのタスクが正しく完了されたかどうかを迅速に判断できるべきです。

この制限は、表面上よりもはるかに重要です。

タスクに明確な完了基準がなければ、真の検証プロセスを構築することはできません。信頼できる検証メカニズムのないサイクルは、真のサイクルではなく、監督のない推測に過ぎません。

これは多くの人が最も見過ごしがちなステップですが、その後のシステムが正常に動作するかどうかを左右する重要なステップです。

エージェントに指示を書く前に、正しい結果がどのようなものであるかを明確で自然な言葉で書き下してください。

必要なのは、「感じが良い」や「プロフェッショナルに見える」などの曖昧な品質判断ではなく、具体的で確認可能な基準である。

以下のテンプレートを使用できます：

タスク名：[タスク名称]

完了定義（Definition of Done、DoD）：

• [具体的で確認可能な基準 1]
• [具体的で確認可能な基準 2]
• [具体的で確認可能な基準 3]

上記のいずれかが欠けていれば、最終出力が完全で丁寧に校正されていても、このタスクは完了したとは見なされません。

現在選択したタスクに対してこのテンプレートを記入できない場合は、ステップ4に戻り、サイクルを構築するのにより適したタスクを再選択してください。

これはすべてのループシステムの中で最も重要なアーキテクチャの決定です。

結果を生成する役割と、結果を確認する役割は、必ず分離しなければなりません。

理由は、モデルがコンテンツを生成した直後に自らの出力を検証すると、生成された回答を批判的に見つめるのではなく、その回答を擁護しようとする傾向が強くなるからです。

適切なサイクルでは、少なくとも2つの独立したロールが存在する必要があります：

ビルダー

ビルダーは一定の創造的自由を持ち、最初のバージョンの結果を生成する責任を担います。

審査員（Judge）

レビュアーは、ビルダーの出力と第5ステップで定義された完了基準を受け取り、これらの基準に基づいて結果が合格かどうかを判断します。

理想的には、審査者は、ビルダーがアクセスできない独立した証拠にもアクセスできるべきです。例えば：

• テストスイート；
• オリジナル資料；
• リアルタイムデータ；
• 公式データベース；
• Original task brief.

これにより、審査者は同じ思考回路で主観的な意見を再生成するのではなく、真の証拠に基づいて判断できるようになります。

審査者が構築者の出力のみを確認できる場合、その結果が「一貫して見えるかどうか」を判断するしかない。

それは結果が本当に正しいかどうかを判断できません。

したがって、審査者は、Ground Truthと呼ばれる確認可能な客観的根拠を有しなければなりません。文脈に応じて、これは「基準事実」「真実のデータ」または「権威ある根拠」と解釈できます。

タスクによって、客観的な基準も異なります。

プログラミングタスク

客観的な根拠はテストスイートと、コードが実際に実行された後の出力結果です。

コンテンツ作成タスク

客観的根拠は原資料およびコンテンツ要約です。レビュー担当者は原資料と生成された原稿を並べて比較する必要があります。

研究タスク

客観的根拠は、タスクで明確に指定された元のファイル、論文、データセット、または権威ある情報源です。

審査者が何を基準にチェックすべきか明確に言えない限り、そのサイクルには真の検証メカニズムが存在しない。審査者の言い方がどれほど自信に満ちていても。

構築者の出力と審査者の結論は、自由な自然言語ではなく、明確に定義された構造を採用する必要がある。

そうでない場合、次のマネージャーは安定的で信頼できる情報を得られず、判断やルーティングができません。

ビルダーは以下の出力形式を使用できます：

ビルダー出力：

• 最終納品物；
• 結果への信頼度；
• 既知の不確実性。

レビュアーは以下の出力形式を使用できます：

審査結果：

• PASS：通過；
• FAIL：失敗；
• 修正が必要：
• 発見された具体的な問題；
• 本チェックの根拠となる客観的な基準または原始的な証拠。

自動スケジューリングと自動再試行を導入する前に、まず手動で「ビルドラー—レビュアー」フローを一度完全に実行してください。

審査者が提示した判断をよく読み、自分に問いかけてください：

• あなたはその結論に同意しますか？
• それは、あなたが間違いがあると知っている結果を一度でも放任したことがありますか？
• それは本来合格の結果を誤って否定していますか？

審査者が、あなたが誤っていると知っている結果を通過させたり、実際には問題のない結果を却下したりした場合、まず客観的根拠や基準を修正し、その後システムの構築を継続してください。

誤った検証ステップを自動化すると、システムはより速く誤った結果を生成するだけです。

上記の5つのステップをより具体的にするために、一般的なタスクである原始資料を完全な記事に変換するプロセスを観察してみましょう。

ステップ5：完了定義を策定する

このタスクの完了基準は次の通りです：

• ドラフト内の各事実は、元の資料の明確な内容に遡ることができる。
• ドラフトは、簡報のすべての具体的な要件、包括的な長さ、トーン、および構造を満たしています。
• 原文の核心的な主張は、無意味な追加コンテンツによって薄められることなく明確に保持されています。

ステップ6：ビルダーがドラフトを生成

ビルダーは原資料とコンテンツのブリーフを受け取り、ドラフト版を生成します。

同時に、執筆プロセス中に存在する不確実性を明確に列挙する必要があります。例えば：

• ある数字が元の資料に実際に登場しているかどうか；
• その結論は原文に明示されているものか、モデルが自ら推論したものか。
• ある事実が十分な情報源を欠いているかどうか。

ステップ7：レビュアーが原文を確認する

レビュアーは草稿だけでなく、オリジナル資料も同時に受信します。

定義された3つの基準をそれぞれチェックし、各基準に対して個別に合格または不合格の結論を出す必要があります。すべての次元を1つのあいまいな総合スコアに圧縮してはいけません。

三つの異なる基準を一つの総合的判断に統合すると、どの次元で問題が発生しているかが隠れてしまう。これは、本来機能していたサイクルが次第にフィードバックの価値を失う最も一般的な理由である。

ステップ8：構造化された引き継ぎ

審査者の結論は、保留された表現で満たされた自然言語ではなく、構造化されたオブジェクトであるべきです。

それは、明確な通過または失敗の結果を三つ出力し、それぞれの失敗に対して具体的な理由を提供する必要があります。

ステップ9：レビューメカニズムの手動確認

システムが自動で実行される前に、手動で完全なプロセスを実行することで、レビュアーが過度に甘いまたは厳しすぎるかどうかを発見できます。

あまりにも寛容な査読者は、文章が滑らかに書かれているため、その中に含まれる虚構のデータを見過ごす可能性がある。

厳しすぎる査読者は、簡報に一切記載されていない個人的なスタイルの好みにより、適格な記事を誤って却下する可能性がある。

これら二つの問題は、初めてセットアップする際に非常に一般的です。

システムが無人で50回実行された後にそれらを発見するのは、最初に手動でテストしたときに問題を解決するよりもはるかに高価である。

第3段階：ループに欠けているコンポーネントを補完する 第10ステップ：マネージャーと真正的な停止条件を構築する

マネージャーはレビュアーの判断を読み取り、次の操作を決定します。

停止条件もマネージャーに存在しなければならず、モデルが自己解釈によって回避できるような柔軟な指示ではなく、明確なハードロジックとして記述されなければならない。

例えば：

停止条件：

• 最大変更回数：3回；
• 3回目の審査でも失敗した場合、完全な履歴を人間の手に委ね、4回目の修正を開始しないこと；
• 品質基準：定義内の各項目がすべてPASSである必要があります；
• 予算上限：タスクのコストがXを超えた場合、または実行時間がYを超えた場合、現在の状態に関係なく即座に停止してください。

真の停止条件のないループは、システムではなく、リスクが露呈するのを待つ負債である。

なぜ「結果が十分良ければ停止」などの曖昧な指示は信頼できないのか？

それはあくまで提案です。

モデルが連続して複数回修正しても承認されない場合、タスクに満足のいく結末を与えるために、モデルは「このバージョンは基準に十分近い」と自分自身に信じ込ませ、判断基準を自ら引き下げる可能性がある。

一方、コードによる機械的チェックによる反復回数や、マネージャーが推論で回避できない明確なルールには、このような問題は発生しません。

毎回起動時にゼロから始まるループは、前回の実行で学んだことを記憶しません。

したがって、シンプルな永続化レイヤーを追加する必要があります。

各新しい経験ごとにファイルを作成し、ファイルの先頭に一文で要約してください。

• 何を学びましたか；
• 何を修正しましたか；
• なぜこの経験が重要なのか。

重要な原則は、他の場所に保存されていない新しい知識のみを記録することです。

繰り返される記憶は知識ではなく、ノイズである。

永続化メカニズムを長期的に有効に保つには、書き込み時に自制が必要です。

すべての実行詳細を記録したくなる衝動に駆られがちですが、これではステップ2で言及された「肥大化したプロンプト」の問題が再現されるだけで、今回は膨張する対象がプロンプトからメモリーフォルダーに変わります。

真に記録に値する経験とは、一度忘れると再発見に膨大な時間がかかるものであり、予定通りにスムーズに完了した通常の運用記録ではない。

単に永続化メカニズムを追加するだけでは、長すぎるプロンプトと同様の問題が発生する可能性があります。

時間の経過とともに、システムは数十のファイルを蓄積し、その多くは同じ問題に対するわずかに異なる表現です。

したがって、メモリーファイルは固定の周期で整理する必要があります。週に1回実行することが一般的な頻度です。

整理プロセスには以下が含まれます：

• 既存のメモリを確認する；
• 重複内容を統合する；
• 複数の類似した経験を、より明確な原則に圧縮する；
• 証明済みの誤りまたは古くなったコンテンツを削除してください。

目標は、ますます多くのファイルを蓄積することではなく、より少なく、情報密度の高い知識を得ることである。

多くの人が、このステップを完全にスキップします。なぜなら、これはすぐに目に見える新しい機能をもたらすわけではなく、将来の問題を予防するだけだからです。

しかし、即時のフィードバックが欠けているからこそ、メモリーフォルダーの管理が困難になった時点で対処するのではなく、明確にスケジュールに組み込むべきです。

現実では、このような「後で暇なときに整理する」というタスクは、システムのパフォーマンスが多数の矛盾し、古くなった、そして部分的に関連する記憶がコンテキストウィンドウを争い始めた時点で、決して実行されないことが多い。

新しいタスクが開始されるたびに、ループはまずメモリーファイル内の1文の要約をスキャンし、どの経験が現在のタスクと真正に関連しているかを判断して、その関連する内容のみを読み込みます。

また、システムには、既存のメモリに現在のタスクに適用可能な内容がなければ、直接適用可能な経験がないと明示するよう要請すべきです。

過去の経験を、まったく異なる新しい問題に無理に適用しないでください。

次に、このサイクルを人手で起動せずに自動で実行するタイミングを決定する必要があります。

トリガー方式には以下が含まれる可能性があります：

• Cronタイマー機能；
• ファイル変更リスナー；
• カレンダーに基づく周期トリガー；
• 外部のイベントまたは状態が変化したときにトリガーされます。

このステップでは、あなたが手動で起動する必要があるシステムを、あなたが寝ている間も継続して動作するシステムに変換します。

皮肉なことに、これは全体のリストの中で最も実行が簡単なステップであるにもかかわらず、他のコンポーネントをすでに完了しているにもかかわらず、多くの人がまだ実行しないステップです。

第4段階：スケールを拡大し、信頼性を強化する ステップ15：真の信頼サイクルに入る前に、それをストレステストする

重要なタスクにループを適用する前に、4つの故障モードに対して積極的にテストを行う必要があります。

テスト1：完了不可能なタスク

システムに本当に解決不可能なタスクを実行させ、マネージャーが無限ループせずに停止条件に従って終了することを確認してください。

一連のループが成功するタスクでのみテストされている場合、それは優雅な失敗の能力を証明したことはない。

テスト2：合理的に見えるが実際には誤った結果

審査者に、あなたが明確に微細な誤りが存在すると知っている出力を提供してください。

この結果は非常にスムーズに読めるはずですが、意図的に挿入された事実または論理的な誤りを含んでいます。

内容が合理的に聞こえるだけで通過せず、レビュアーが問題を発見できるかどうかを観察してください。

テスト3：ビルダーとレビュー担当者がモデルの盲点を共有

構築者とレビュー者が同じ基礎モデルを使用する場合、そのモデルがよく犯す典型的なエラーを意図的に挿入し、レビュー者がそれを見過ごすかどうかを観察できます。

審査者と構築者が同じ盲点を持つ場合、ステップ6で設計された役割分離は意味を失う。

テスト4：最悪の場合の実行コストを計算する

最大変更回数、最も高価なモデル呼び出し、および合理的な範囲での最長出力を用いて、このループが最悪の場合にどれだけのコストを消費するかを計算します。

そして、自分に正直に聞いてください：

この数字が実際の請求書に表示されていた場合、不安に感じますか？

この4つのテストを信頼サイクルで重要なタスクを処理する前に完了することで、ほとんどの潜在的な問題を事前に発見できます。

そうでない場合、これらの問題は、あなたが主導して制御するテストではなく、顧客や管理者の前に初めて現れるか、直接あなたの請求書に反映される可能性があります。

循環が安定して動作するようになったら、すべてのキャラクターに同じお気に入りのモデルを使用しないでください。

ループ内の異なる役割は、モデルの能力に対する要件が異なります。

ビルダー

ビルダーは通常、最も強力なモデルを使用すべきです。

それは主要な複雑な推論とコンテンツ生成を担っているため、ここで能力が不足するモデルを使用すると、最初のバージョンの品質が低下し、その後より多くの修正ラウンドが必要になる可能性があります。

結局、低品質な原稿を修正するためにかかるコストは、最初からより強力なモデルを使用するコストよりも高くなる可能性がある。

レビュアー

レビュアーは明確な基準に基づいてチェックを担当し、特に創造性は必要ありません。

標準が十分に具体的な場合、規模が小さく、コストが低く、速度が速いモデルでも、レビュータスクを信頼性高く完了できることが多い。

非常に明確なチェックリストに従って動作する小さなモデルは、安定性が大規模モデルに近づく可能性がありますが、コストと遅延は大幅に低くなります。

管理者

マネージャーは事前に定義されたルールに従ってルーティングを行うため、ほぼ常に最も高価なモデルを使用する必要はありません。

そのタスクは、オープンな推論を行うのではなく、すでに定義されたロジックを実行することです。

また、ビルダーとレビュアーのパフォーマンスにかかわらず、マネージャーは各イテレーションで少なくとも1回は実行されるため、その1回の呼び出しコストに特に注目する必要があります。

合理的分層設定は通常：

• 強力なモデルが構築を担当します；
• 手軽で安定したモデルが通常のレビューを担当します；
• 低コストのモデルまたはルールプログラムがルーティングと管理を担当します。

循環システムにおける真に顕著なコスト削減は、このモデルのロールマッチングからもたらされます。

多くの人々は、コストを抑えることにはループ回数や修正回数を減らすことを意味すると考えています。しかし、より効果的な方法は、モデルのコストをループ内の各ロールの実際の難易度に合わせることです。

最初のサイクルが成功した後、人々はすぐに複数のサイクルを同時に構築し、5つの異なるタスクを並列処理しようとする傾向があります。

現在のアーキテクチャがこの拡張をすでにサポートしている場合でも、その衝動を抑えるべきです。

最初のループが十分な時間安定して動作するまで、そのすべての出力を細かくチェックする必要がなくなるまで待ってください。

これは、誰もが真剣に見守る中で一度だけ成功したデモを意味するのではなく、実際に運用された後も、継続的に手動でのチェックを通過し続けることを意味します。

この状態に達した場合にのみ、2つ目のサイクルの構築を開始すべきです。

二番目のループは、最初のループとは明確に異なるタスクを処理するのが最適です。

これにより、同じタスクに対して徐々に精密なチューニングを行ったにすぎないのではなく、基盤アーキテクチャが真に汎用性を持っているかどうかを検証できます。

複数のループを同時に実行した後は、各ループを個別に確認するのではなく、すべてのループのコストと停止条件のトリガー状況を一元的に追跡できる統合モニタリングビューを構築する必要があります。

単独で見れば、一連のサイクルタスクの予算は完全に合理的である。

しかし、10のサイクルがそれぞれ予算内で動作したとしても、その合計コストは依然として予想外の水準に達する可能性があります。

各サイクルの独立したデータが正常に見えるため、このリスクは合計請求書が表示されるまで気づかれないことが多いです。

成功したタスクに加えて、停止条件がトリガーされるたびに必ず記録してください。

あるループが頻繁に最大変更回数に達し、他のループではめったにそのような状況が発生しない場合、それは「このタスクが特に難しい」というシグナルではなく、

• 評価基準が不適切です；
• 審査者が厳しすぎて、どの結果も通過できない；
• システムは誤りの客観的根拠を確認しました。
• 定義自体に問題があります。

成功した結果のみを追跡し、各手動アップグレードを互いに無関係な偶発的出来事と見なす場合、この設計レベルのパターンは見過ごされる。

判断思维轉變是否真正完成，最明顯的標準是你日常關注的指標發生了變化。

プロンプトオペレーターが気にするのは：

• 今日、何件の有効なプロンプトを書きましたか？
• どのプロンプトが最も効果的ですか？
• どのようにしてプロンプトをより洗練させるか。

システム設計者は気にしているのは：

• 現在、何セットのループが実行されていますか；
• 各ループの信頼性はどのようですか；
• システムが自身にどれだけの時間を解放したか；
• どの作業がもはや人間の監督を必要としなくなったか。

まだ入力したプロンプトの数で自分の生産性を測っているなら、技術的にどれだけループを構築しても、ステップ1で求められる思考の転換はまだ真正に完了していない。

最後のステップはもはやあなた自身のシステムだけについてではありません。

これはあなたがこの方法を本当に理解しているかを確認するために使用されます。

複雑な用語に頼らず、他の人に5つの基本的な動作を説明してみてください。

識別、引き渡し、検証、永続化、スケジューリング。

あなたがこの5つの動作と以前のステップだけを使って、誰かに彼の最初のループを構築させることができたなら、あなたはこのルートマップが描く真の変化を達成したということです。

あなたは、ループの内部にとどまり、次々と指示を入力し続ける人ではなくなっています。

あなたは循環の外に立ち、システムを設計し、それが自ら動作するのを見守る人となった。

ステップをスキップした後に静かに蓄積する4つのコスト

記事の最後に警告を記載する必要があります。

このロードマップのステップをスキップしても、すぐにシステムがクラッシュするとは限りません。

その失敗は通常、静かに起こり、長い間気づかれず、問題が相当深刻になるまで見過ごされることが多いです。

第6ステップと第7ステップをスキップし、真正の独立したレビュー担当者を設けず、信頼できる客観的根拠を提供しない場合、債務の検証が蓄積し始める。

循環は表面上、結果が「それなりに良さそう」に見えるため、正常に動作しているように見えます。

数十回の実行を通じてエラーが蓄積され、ようやく誰かがそれに気づいたとき、あなたはシステムが最初から結果の正誤を真正に判断していなかったことに気づくだろう。

20番目のステップをスキップすると、理解の劣化が発生する可能性があります。

あなたはかつて構築したループをまだ実行し続けていますが、各コンポーネントがなぜ存在するのかを明確に説明できず、システムに障害が発生した際に効果的にデバッグすることもできません。

理由は、あなたがこのアーキテクチャの背後にあるロジックを真正に内面化していないからです。

第1ステップが実際に完了しなかった場合、認知的降伏が生じる。

検証システムは長期間の運用によりその信頼性が証明されていますが、習慣として、すべての出力を手動で再確認します。

この行動は慎重に見えるが、実際にはシステム構築の意味をすべて台無しにしている。

第10ステップをスキップし、ループに真の停止条件を設定しないと、トークン消費と呼び出しコストが制御不能になる可能性があります。

システムが制御を失い始めた瞬間に問題に気づくことは少なく、最終的な請求書が表示されるまで、無効な呼び出しが大量に繰り返されていたことに気づかないことが多いです。

上記のすべてのコストは回避できます。

それらを避ける方法は、常に同じ規律です：

見栄えがそれほど良くないように見えるステップも飛ばさず、順を追って構築してください。

実際に効果を発揮するのは、たいてい最も退屈な部分である：

• 明確な完了定義；
• 信頼できるストップ条件；
• 検証可能な客観的根拠；
• 独立した審査メカニズム。

一方で、魅力的に聞こえる部分——巧妙なプロンプトや複雑なシステムアーキテクチャ図——は、人々が想像するほど重要ではない。

システムの品質を真正に決定するのは、あなたが構築したシステムが次のことを知っているかどうかです：

• いつ自分自身が正しいのか；
• いつ自分自身が間違っているか；
• いつ停止しなければならないか。

これがプロンプトオペレーターとシステム設計者との間のすべての違いです。

違いは誰がより賢いか、あるいは誰がより華やかなプロンプトを書けるかにはない。

真の違いは、あなたが十分な規律を持って、退屈で見過ごされがちだが、システムの信頼性を決定する部分を真剣に構築できるかどうかです。