ループエンジニアリングとは？AIを自律的に実行する手法を完全解説

毎回プロンプトを打って、結果を見て、また次の指示を打つ。AIを使いこなしているように見えて、実は人間がバトンを渡し続けているだけという状態が続いています。

ループエンジニアリングはその構造を変えます。AIに一回ずつ指示を出すのをやめて、「指示を出すシステムそのもの」を設計する技術です。プロンプトを磨くのではなく、プロンプトを出す仕組みを作る。

概念の定義・具体的な進め方・安全な始め方から落とし穴まで、一気通貫で解説します。特定のツールに限った話ではないので、考え方を軸に据えつつ、必要なところでClaude CodeやCodexなどを例に使います。

AIへの指示をシステムが出す──ループ設計への転換

ループエンジニアリングを一行で定義するなら「次の一手を出す役を、人間からシステムに移す設計」です。

分かれ目は「次の指示を誰が出すか」にあります。たとえば、要件定義から実装・レビューまでをサブエージェントを編成しながらAIに進めさせる、オーケストレーター型の使い方があります。賢い使い方ですが、多くの場合は人間が要所でレビューし、フィードバックを返し、「次はこれをやって」と指示しないと前に進みません。AIがどれだけ速くても、人間が次の一手を出すまで作業は止まって待つ。人間がボトルネックとして残ります。

ループエンジニアリングはこの一手を外します。「タスクを見つける → 実行する → 検証する → ダメなら直す → 次を決める」という流れを、人間ではなくシステム自身が回す。AIがAIに指示を出し、条件を満たすまで人の介入なしで進む仕組みを作るわけです。Claude Codeを作ったエンジニアが「私はもうClaudeにプロンプトを出さない。ループがClaudeにプロンプトを出している。私の仕事はループを書くことだ」と語ったのは、まさにこの転換です。同じ趣旨の発言は、別のコーディングエージェントの作者からもほぼ同時期に出ています。

ただし人間が一切いなくなるわけではありません。人間はループの外側に移り、ゴールの定義・止め方・例外時の判断という上流を持ちます。ループの中で一手ずつ指示する役から、ループそのものを設計・監督する役へ。これがループエンジニアリングの中心にある発想です。

AIの生成能力はすでに十分な水準に達しています。エンジニア1人あたりのコード産出量が急増し、マージされたコードの80%以上をAIが書いている組織もあります。ここまで来ると、ボトルネックは「どう指示するか（生成）」ではなく「どう検証し、どう人の手を借りずに続けさせるか（ループ設計）」に移っています。

プロンプトからループへ──手法が登場してきた順番

AIにコードを書かせる手法は、数年でいくつかの呼び名を経て語られてきました。最初は「どう指示文を書くか」というプロンプトエンジニアリング。次に「モデルに何を読ませるか」というコンテキストエンジニアリング。さらに「AIが動く環境全体をどう整えるか」というハーネスエンジニアリング。そして2026年6月ごろから、「ループエンジニアリング」という言葉が議論されるようになりました。

それぞれが何に注目してきたかを並べてみます。

手法	注目点
プロンプトエンジニアリング	どう指示するか
コンテキストエンジニアリング	何を読ませるか
ハーネスエンジニアリング	環境をどう整えるか
ループエンジニアリング	どう自律的に回すか

新しい手法が古い手法を否定するわけではありません。注目の的が「指示文 → 読ませる情報 → 実行環境 → 指示を出す行為そのものの自動化」へと移ってきた、という流れです。学ぶときは、この順に一段ずつ触れていけば十分です。ループエンジニアリングは、その最新段にあたります。

終了条件を最初に設計しないとループは止まらない

良いループには終わり方の設計が入っています。永遠に走り続けるループは設計ではなく事故です。

基本のサイクルはシンプル。観察（何が起きているか）→ 計画（何をするか）→ 実行（実際に動く）→ 検証（できたか評価する）→ 修正（ダメなら戻る）→ 収束条件を満たしたら終了。このサイクルを繰り返しながら徐々に目標に近づいていく構造です。

収束条件の3パターン

終了トリガーは3種類あります。

ひとつ目は完了判定。全タスクが終わった・目標のテストが連続パスした、といった成功条件です。ふたつ目はリソース上限。ツール呼び出しの回数（5〜10回が推奨）、実行時間（30〜90秒）、イテレーション数（最大50回程度）、トークン予算超過、といった安全網。三つ目は回復不能エラー。3回連続で同じ失敗が出たら人間に戻す、といったエスカレーションです。

この3パターンをループ設計の前に決めておかないと、ループは「静かに失敗し続ける」か「終わらない」かのどちらかになります。

自己採点の罠

検証ループで最も見落とされているのが、生成と評価を同じモデルにやらせる設計です。同じモデルが自分の出力を評価すると、同じバイアスが出ます。答案を書いた人が採点すると甘くなるのと同じ構造です。

生成モデルと評価モデルは分離するのが基本です（AWS推奨パターン）。ここで効いてくるのが「Temperature」という設定です。これはLLMをAPI経由で呼び出すときに指定できる数値で、出力のブレ幅を決めます。たとえばAnthropicのAPIは0〜1の範囲で指定でき、0に近いほど同じ入力には毎回ほぼ同じ答えを返し（ブレが小さい）、高いほど答えがばらつきます（多様になる）。なので、コードや文章を生み出す生成側は、いろいろな案を出せるよう0.7くらいに設定し、できたかどうかを判定する評価側は、同じ入力には毎回同じ判定を返してほしいので0に設定する。役割ごとにTemperatureを変えることで、検証の一貫性が上がります。

ただし、これはAPIを直接呼び出すときの話です。サブスクリプションのコーディングエージェント（Claude CodeやCodexなど）で使っている人は、Temperatureを自分で指定できないことがほとんどです。その場合はTemperatureのかわりに「役割を分ける」ことで同じ効果を狙います。検証を別のサブエージェント（まっさらな文脈と「あなたは厳しいレビュアーです」という役割を与えたもの）に任せる、あるいは判定そのものをテストやlintのような機械的なチェックに寄せる。テストの合否はAIの気分で変わらないので、Temperatureを触らなくても一貫した検証になります。Claude Codeの完了判定（/goal）も同じ発想で、実行モデルとは別の小型モデルが完了条件を判定します。

エスカレーションがないループはトークンを垂れ流す

自律ループが人間に戻す仕組みを持たないと、詰まった状態で延々とトークンを消費します。「3回同じ失敗で停止」「外部APIエラーはSlack通知」のような逃げ道を、最初から設計に入れておく必要があります。

ループの回し方には2タイプある

「ループ」と言っても回し方は一つではありません。質的に違うのは2タイプです。終わらずに回り続ける「継続監視型」と、ゴールを満たしたら止まる「ゴール収束型」。どちらを選ぶかで設計も止め方も変わります。なお、よく一緒に語られる「リレー」は実はループではないので、最後に切り分けて説明します。

タイプ	回り方	止まり方	人間の関与
継続監視型	一定間隔で起き「仕事を探して処理」を延々繰り返す	止めるまで動き続ける	ほぼなし
ゴール収束型	ゴールに向けて「実行→検証→修正」を繰り返す（小さな条件から夜通しの大仕事まで）	ゴール達成または予算切れ	ゴールと止め方を決める

継続監視型──終わりがないループ

一定の間隔で起き、「落ちたCIはないか」「新しいissueはないか」を確認して処理する。終わったらまた眠り、時間が来たら起きる。これを延々繰り返します。心拍のように動き続けるのでハートビート型とも呼ばれます。終わりがないので、止める条件ではなく「いつ起きるか」と「1回で何をするか」を設計します。

ゴール収束型──条件を満たしたら止まる（大きくすれば「朝まで任せる」）

「全テストが通る状態にする」のように、検証できるゴールを満たすまで実行と検証を繰り返します。継続監視型が時間で動くのに対し、こちらは成果で動きます。止め方の設計（収束条件）が命になります。

ゴールが大きくなると、「このビッグイシューを明日の朝までにやっておいて」と夜通し走らせる長時間タスクになったりします。注意点として、長く走るほど方向がズレやすく、4時間を超えるタスクを最後まで成功させる確率はまだ低いという調査もあります。大きく任せるときほど、途中のチェックポイントと止め方を厚めに設計するのが安全です。

リレーとループの違い

紛らわしいのがリレーです。A→B→Cと一方向に受け渡して終わりなら、それはリレー（パイプライン）であってループではありません。「人間が要所で指示を出して進める対話型のオーケストレーター」も、バトンを人間が渡し続けるリレーの一種です。真のループエンジニアリングとは、初めに人間が仕組みだけを作り、あとはAIが自律的に回り続ける手法のことです。

ループを動かす土台──セッション内で回すか、毎回起動し直すか

ループを動かす土台は、ツールを問わず大きく2つに分かれます。ひとつのセッションの中で回し続けるか、時間が来るたびに新しい実行を起動し直すか。この違いはコンテキストの膨張に直結するので、最初に押さえておきます。

土台	動き	コンテキスト
セッション内ループ	1つのセッションの中で繰り返す	同じコンテキストウィンドウに積み上がる
定期スケジュール実行	時間が来るたびに新しいセッションを起動して仕事をし、終わる	毎回まっさらで膨らまない

手元で短時間ようすを見るなら前者、PCを閉じても続けたい・長く回したいなら後者です。

セッション内ループ

開いている一つのセッションの中で、プロンプトを繰り返す方式です。Claude Codeなら /loop がこれにあたります。

/loop 30m "新しいissueをチェックして優先度をつけてラベルを貼る"

これで30分ごとに同じ作業を繰り返します。間隔は秒（s）・分（m）・時（h）・日（d）で指定。繰り返しタスクは作成から7日後に自動で期限切れになり、1セッションで同時に持てるのは最大50個です。

間隔を省いてプロンプトだけ渡すと、固定間隔ではなく「次回の実行タイミングをAI自身が決めるモード（動的スケジュール）」になります。固定間隔との違いは3つ。ペースが状況に応じて変わること（ビルドが終わりかけ・PRが動いている間は短く、何もなければ長く、1分〜1時間でその都度決める）、タスクが終わったと判断したら自分でループを終えること（固定は止めるか7日まで続く）、毎回投げ直す代わりにバックグラウンド監視に切り替えてトークンを節約することがあること、です。

使いどころは、適切な間隔が事前に読めないときです。たとえばPRのお守り。

/loop "このPRのCIが通ったか確認し、レビューコメントがあれば対応して"

これを「30分ごと」と固定すると、CIが回っている数分間は反応が遅く、逆にマージ後も無駄に回り続けます。動的スケジュールなら、CIが回っていてレビューが活発な間は短い間隔で頻繁に確認し、静かになったら間隔を伸ばし、PRがマージされて「もうやることがない」と判断したらループ自体を終えます。CI・ビルド・デプロイの「いつ終わるか分からない完了待ち」全般に向いた使い方です。

このタイプの弱点は、同じセッションにやり取りが積み上がること。長く回すとコンテキストが膨張します（次のセクションで詳しく扱います）。

定期スケジュール実行──トリガーは色々、動きは同じ

もうひとつの土台が「定期スケジュール実行」です。時間が来たら新しいエージェントのセッションを起動し、仕事をさせて、終了する。これを繰り返します。大事なのは、起動のきっかけ（トリガー）は何通りもあるのに、やっている動きはどれも同じだということです。

• OSのスケジューラ（cronやlaunchd）から、エージェントのCLIをヘッドレスモードで叩く
• CIの定期実行（GitHub Actionsの schedule など）
• デスクトップアプリ内蔵の予定タスク機能（Claude Desktopなど）
• クラウドのスケジュール実行サービス（後述のCloud Routinesなど）
• 常駐プロセスのハートビート（OpenClawなど。一定間隔で自分を起こして仕事をする）

どれも「時間が来る → まっさらな新しいセッションで仕事 → 終わる」という同じ動きをします。だからループエンジニアリングは特定のツールの話ではありません。トリガーも、動かすエージェント本体（Claude Code・Codex・OpenClawなど）も差し替えがきき、設計の中身（このあと出てくるloop contractの7要素）は共通です。

実用上の最大の利点は、毎回まっさらなセッションで始まること。セッション内ループが同じコンテキストウィンドウにコンテキストを積み上げるのに対し、こちらは1回ごとに記憶がリセットされるので、長く回してもコンテキストが膨らみません。前回の状態を引き継ぎたいときは、ファイルやチケットに書き出して次回読み込む。記憶をコンテキストウィンドウの中ではなく外に置くわけです。

なお、サブスクリプションのコーディングエージェントを、第三者の常駐ツールから無理に呼び出すのは規約違反になることがあります。たとえばOpenClawはClaudeのサブスクに相乗りするのではなく、自前のモデル接続と起動の仕組みで動きます。

クラウドで定期実行する例：ClaudeのCloud Routines

定期スケジュール実行をクラウドで行う代表例が、Claudeの Cloud Routines です。自分のPCではなくAnthropicのクラウド側で動くので、ノートPCを閉じていても実行されます。

Routineは「保存しておく設定のかたまり」です。実行するプロンプト・対象リポジトリ・連携先（Slack・GitHubなど）・権限を1セットにして登録しておき、起動条件が来ると新しいセッションで実行します。起動条件は3種類あり、組み合わせもできます。

• スケジュール（毎時・夜間・毎週など決まったタイミング）
• API（専用のURLとトークンにHTTP POSTを送ると起動。CI・監視ツール・自作アプリから叩ける）
• GitHubイベント（PRが開いた・issueが立った、などに反応して起動）

作成は、ウェブ（claude.ai/code）かCLIの /schedule から行います。日次の実行回数はプランで決まります。

プラン	日次上限
Pro	5回/日
Max	15回/日
Team / Enterprise	25回/日

回数に縛られず無制限に回したいなら、APIを直接叩く構成（Tier 3以上）が前提です。CodexにもクラウドでのスケジュールやAPI起動の仕組みがあり、考え方は同じです。

無人で走らせるなら権限の線引きを決める

定期実行でも長時間ループでも、人が見ていない間にエージェントが危険な操作（外部送信・本番デプロイ・削除）をしないよう、何を自動で許し何で止めるかを最初に決めておく必要があります。

ツールによっては、この判断を補助する仕組みがあります。たとえばClaude Codeの Auto Mode は、危険でないと判断できる操作だけ自動で通します。便利ですが、危険な操作の見逃しが17%あるという公開データもあり、過信は禁物です。仕組みの有無にかかわらず原則は同じ。自動で許すのは「読む・テストを実行する・状態を確認する」程度に絞り、書き込み・push・外部送信は明示的に禁止側へ置く。これはあとで loop contract の権限（Permission）としてまとめて設計します。

ロングコンテキストの完走──膨張との戦い

ループエンジニアリングの肝は、人の介入なくAIを長く走らせ続けることです。ところがここに最大の敵がいます。コンテキストウィンドウの膨張です。

AIはやり取りが積み上がってコンテキストウィンドウが埋まるほど、序盤の指示を見失い、判断がぶれていきます。だから人間が対話的に使うときは、会話を要約するコマンド（Claude Codeなら /compact）や、区切って新しいセッションでやり直すコマンド（/clear）を打ったり、重い作業はサブエージェントに投げて結果だけ受け取ったりして、コンテキストを節約します。これがコンテキストエンジニアリングの実践です。問題は、人間が見ていない自動ループでこの節約が効くのか。ここがツール選びの分かれ目になります。

セッション内ループは同じコンテキストウィンドウに積み上がる

注意が必要なのは、セッション内ループ（Claude Codeの /loop など）が、同じコンテキストウィンドウの中で処理して眠り、また起きて処理して、を繰り返す点です。各回がまっさらから始まるわけではありません。回るほど履歴が積み上がり、放っておけばコンテキストウィンドウが膨張します。

これを救うのが自動要約です。コンテキストが上限に近づくと自動で発火し、プロジェクトの設定ファイルや直近のファイル・ツール定義を残して会話履歴を圧縮します。理屈の上では無限に走れますが、圧縮のたびに序盤の指示の一部が削れるリスクがあります。長く走らせるループほど、何が消えても破綻しないよう、大事な前提は設定ファイル（Claude Codeなら CLAUDE.md）のように要約後も残る場所に置いておくのが定石です。

各回をまっさらにするか、別の頭に投げるか

膨張を断つ最も確実な方法は、毎回を新しいセッションで始めることです。前のセクションの「定期スケジュール実行」は、実行ごとに独立した新しいコンテキストで起動します。前回の状態を引き継ぎたければ、ファイルやチケットに書き出して次回読み込む。記憶をコンテキストウィンドウの中ではなく外（git履歴・進捗ファイル・チケット）に置くわけです。

もう一つがサブエージェントへの分離です。サブエージェントは自分専用のまっさらなコンテキストウィンドウを持ち、調べ物や試行錯誤を全部そこで済ませて、親には結論だけ返します。途中の汚れが親のウィンドウに入らないので、メインのループを汚さずに重い処理を回せる。長いセッションでサブエージェントが効くのは、この隔離のためです。

Codexは上限を自分で越える

自動要約は多くのエージェントが持っていますが、Codex（OpenAI）はこれをモデル自体に組み込んでいます。コンテキストウィンドウの上限に近づくと自動でセッションを圧縮して新しいウィンドウを獲得し、タスクが終わるまでこれを繰り返す——という「複数のコンテキストウィンドウをまたいで働く」動きを、学習の段階で身につけている。この圧縮（compaction）はGPT-5.1-Codex-Maxで導入され、その後のCodex系モデルにも引き継がれています。重要な情報を残しつつ古い履歴を刈り込むので、実質的に数百万トークン規模の作業ができる。OpenAIの内部評価では24時間を超えて実装とテスト修正を続けた例が、長時間タスクの実験では1回の実行で約1,300万トークン・約3万行に達した例が報告されています。

この「ウィンドウを継ぎ足す」圧縮は、突きつめると動かす側（ハーネス）の機能です。Codexのようなエージェント環境は、コンテキストが上限に近づくと自動で圧縮して継ぎ足す仕組みを持っていて、汎用モデルをその中で動かしても効きます。Codex専用のモデルは、それをモデル自体が得意とするよう訓練されている、という関係です。逆に、汎用モデルを素のチャットやAPIでそのまま使うだけなら継ぎ足しは起きず、ただ広い（100万トークン級の）コンテキストがあるだけ。継ぎ足しは「モデルが持つ機能」というより「動かす仕組みの仕事」だと捉えると整理しやすいです。

ただし圧縮は万能ではありません。何を残し何を捨てるかはモデル任せなので、長く走るほど序盤の意図が薄れるリスクは残ります。消えてほしくない前提は、要約後も残る場所（設定ファイルや外部の進捗メモ）に置いておくのが安全です。

どのツールでループを組むか

ループを組めるのは特定のツールだけではありません。クラウドで動かしたいのか、手元のマシンで常駐させたいのか。目的でツールが変わります。

クラウドで回す、手元で常駐させる

クラウド実行を選ぶなら、ClaudeのCloud RoutinesやCodexが候補です。ノートPCを閉じても動き続けるので、定時の監視や夜通しの長時間タスクに向きます。Codexは長時間の連続実行に強く、大きな塊を朝まで任せる用途と相性がいい。

手元のマシンで常駐させたいなら、OpenClawのようなハートビート型のハーネスが選択肢になります。OpenClawは設定ファイルで起動間隔（既定で30分）を決め、時間が来るたびにまず自分の役割を定義したファイル（SOUL.md）を読み、続いてやることを書いたファイル（HEARTBEAT.md）を実行するとされています。やることがなければ合図の文字列だけ返して静かに眠る。スケジュール実行をメインの会話履歴から切り離す設定もあり、これは前述のコンテキスト膨張対策そのものです。常駐エージェントに「自分は何者で、定期的に何をするか」を持たせる発想が、ハートビート型の特徴です。

自分のPCではなく専用機で常駐させる

ローカルで常駐させる場合、どのマシンで動かすかも地味に効きます。自分のふだん使いのPCで回すのは、現実には結構辛い。ノートは閉じたりスリープしたりして止まりますし、タスクによってはブラウザが勝手に立ち上がって自分の作業の邪魔をする。

そこで増えているのが、常時電源を入れた専用マシンを1台立てるパターンです。安価な小型デスクトップ（Mac miniなど）を「ループ専用機」として置き、そこでハートビート型のエージェントを回し続ける。クラウドには預けたくない、でも自分の作業マシンとは分けたい、というニーズにちょうどはまります。OpenClawを常駐させる土台として、こうした専用機を用意する動きも出てきています。

選ぶ基準

やりたいこと	向いている道具
PCを閉じても動かしたい	クラウドのスケジュール実行（Cloud Routines / Codex）
ローカルで常駐させたい・作業マシンと分けたい	常時オンの専用機（Mac mini等）でハートビート型ハーネスを回す
セッション内で1タスクを繰り返すだけ	セッション内ループ（/loop など）
GitHubのPRなど外部イベントで起動	イベントトリガー（Cloud RoutinesのGitHubトリガーなど）

ツールは違っても、設計の中身（loop contractの7要素）は共通です。道具選びは「常駐か起動か」「クラウドか・専用機か・作業マシンか」「コンテキストをどう持つか」で決まります。

loop contract──7要素が揃わないと仕様が壊れる

「バグを直して」と頼んで3時間走らせたら、テストは通っているが元の仕様が壊れていた──よくある失敗です。プロンプトの質の問題ではなく、「何をしていいか」「どこで止まるか」を定義しないまま走らせたことが原因です。

ループを長時間動かす前に「loop contract（ループの仕様書）」を書く。これがいちばん効くフレームで、最低限7要素が揃う必要があります。

要素	役割
Trigger（起動条件）	何をきっかけにループを起動するか
Scope（作業範囲）	触っていいリポジトリ・ブランチの範囲
Permission（権限）	自動OK / 人間承認が必要な操作の境界
Verification gate（完了の判定）	何をもって「できた」とするかの合格ライン（テスト・lint・E2Eなど）
Budget（予算）	時間・トークン・イテレーションの上限
Stop / Escalation（停止）	停止トリガーとエスカレーション先
Reporting（記録）	ログ・成果物・PRの保存先

7要素の意味──TriggerとScopeが出発点

Trigger（起動条件）は何をきっかけにループを起動するかです。PRのコメント、定時のスケジュール、Slackの投稿など。Scope（作業範囲）は触っていいリポジトリ・ディレクトリ・ブランチをどこまでにするか。この2つは「ループが何をするシステムか」を決める最初の線引きです。

次にPermission（自動許可と人間戻し）。自動でやっていいこと（テスト実行・コード読み書き）と、必ず人間に戻すこと（外部送信・マイグレーション・依存パッケージ追加）を明示します。Verification gate（完了の判定）は、何をもって「できた」とみなすかの合格ラインです。テストが通る・lintが綺麗・ブラウザでこの操作が成功する、のように機械でチェックできる基準にするほど、AIの「できました」という自己申告に頼らず確実に判定できます。ここが甘いと、AIは見かけだけ条件を満たして「完了」と言い張れてしまいます。

安全網と記録を担う残り3要素です。

要素	内容
Budget	最大時間・最大トークン数・最大イテレーション・最大エージェント数
Stop / Escalation	同じ失敗が何回で停止するか。どんな状態で人間に通知するか
Reporting	進捗ログ・失敗ログ・成果物・PRをどこに残すか

7要素が揃った依頼は安全で再現性が高い

「このバグ直して」との依頼を比べてみます。

このissueを修正するループを走らせる。対象はsrc/とtests/のみ。ブランチはfeature/fix-checkout-timeout。自動実行はテスト・lint・buildまで。外部送信・マイグレーション・依存追加は人間承認。3回連続で同じ失敗なら停止。完了条件はE2EのCheckoutフローが20回連続パスし、PRに再現手順と検証ログが含まれること。

長いように見えますが、これはプロンプトではなく作業プロセスの仕様書です。この7要素が揃った依頼は、揃っていない依頼より安全で再現性も高くなります。

静かに失敗・ゴールハック・コスト爆増への対策

実際に動かし始めると4種類の問題が見えてきます。

静かな失敗は一番発見が遅れます。エラーが出ていないのに意図した結果になっていない状態です。Verification gateを「エラーなし」だけでなく「期待する成果が出ているか」で定義することで防ぎます。

ゴールハックは終了条件が甘いと起きます。「テストが全部通ること」を完了条件にすると、エージェントはテストをskipするか、assertを弱めるか、元の仕様を壊してテストを通すことがあります。これはズルではなく、「指定された条件を満たす最短経路」を選んでいるだけです。対策は終了条件を「成果」だけでなく「プロセス」も含めて定義することです。「テストが通る」+「既存のassertに変更がない」+「PRにテスト変更の理由が書いてある」のように組み合わせます。

コスト爆増はループが長く走るほどコンテキストウィンドウにトークンが積み上がり発生します。キャッシュが機能しない場合は10〜20倍になった例もあります。APIを使う際は、予算設定で上限を必ず設定する。これだけで大半のコスト事故は防げます。

権限の事故は、自動許可を広げたまま走らせると起きます。前述のとおり、自動判定の仕組みを使っても危険な操作の見逃しは残ります（17%）。自動で許すのは読み取り系と安全なテスト実行のみに絞り、書き込み・プッシュ・外部送信は明示的に禁止側へ置く。

今日から始める──3要素で最初のloop contractを書く

「強いエンジニアは良いプロンプトを書ける人ではなく、良いループを設計できる人」という方向に、仕事の定義が変わりつつあります。ループエンジニアリング。ぜひトライしましょう。

「仕事場に、ループエンジニアリングの導入をしたい」という方は、お問い合わせフォームより、コンサルのご相談をお待ちしております。