AI時代にやるべきことは、毎回すごいプロンプトを考えることではありません。
AIが自分で確認し、直し、検証し、次の作業へ進める「ループ」を作ることです。
プロンプトは入口です。
でも、入口だけを磨いても作業は増えます。
本当に効くのは、次の流れを固定することです。
- 入力を決める
- 作業をさせる
- 結果を検証する
- 失敗を次の入力に戻す
- もう一度回す
この形にすると、人間は毎回文章を考える係ではなくなります。
人間の仕事は、ループの目的、止める条件、危ない操作の境界を決めることになります。
プロンプトを考える人から、仕組みを作る人へ移る
AIを使い始めると、つい「どう聞けばいいか」を考えます。
もちろん、それも大事です。
でも、毎回プロンプトを考えていると、作業は人間側で止まります。
AIが速くなっても、人間が毎回考え直していたら伸びません。
これから大切なのは、プロンプト単体ではなく、作業の流れを作ることです。
- 何を見ればよいか
- 何をしてよいか
- 何をしてはいけないか
- 何をもって完了とするか
- 失敗したら何を次に渡すか
この5つを決めると、AIは「お願いされた1回の作業」ではなく「続けて改善する作業」に入りやすくなります。
OpenAIのCodex公式ベストプラクティスでも、Codexは一度きりの助手ではなく、設定して改善していくチームメイトのように扱う考え方が示されています。
また、よい依頼には「目的、文脈、制約、完了条件」を入れるのが基本だと説明されています。
つまり、うまい一文よりも、AIが迷わない作業条件のほうが大事です。
ループに必要なのは「検証できる結果」
ループで回すには、AIの出力を検証できる形にする必要があります。
ただ「よくして」では、次に何を直せばいいか分かりません。
たとえばブログなら、次のように決めます。
- タイトルを1案だけ直す
- 冒頭2文だけ直す
- 内部リンクを1本だけ足す
- 公開前にリンク切れを確認する
- 画像数が減ったら止める
コードなら、こうです。
- テストを実行する
- 失敗ログを読む
- 最小修正を入れる
- もう一度テストする
- まだ失敗したらログを次の入力に戻す
OpenAIのCookbookには、Codexで「Review」「Repair」「Validate」の3段階を回す修復ループの例があります。
そこでは、検証がループを閉じる役割を持ち、残った問題が次の修正入力になると説明されています。
ここが重要です。
AIに作業をさせるだけではループになりません。
検証して、失敗を次の入力に戻すところまで作って、はじめてループになります。
Codexでは `codex exec` でループに入れやすい
Codexでループを作るなら、対話画面だけで考えないほうがよいです。
公式ドキュメントでは、codex exec を使うとスクリプトやCIからCodexを実行できると説明されています。
たとえば、次のような流れを作れます。
- テストやログを出す
- その結果をCodexへ渡す
- Codexに原因と最小修正を出させる
- 修正後にもう一度検証する
- 結果をファイルに残す
公式ドキュメントでは、codex exec はCI、スケジュール実行、コマンド出力の受け渡し、JSON Lines出力、構造化出力に使えると説明されています。
これはまさに「プロンプトを毎回手で考える」状態から「決まった入力を流し込む」状態へ移るための機能です。
小さく始めるなら、最初はこれで十分です。
npm test 2>&1 | codex exec "失敗しているテストを3点で要約し、最小修正案を出して"ブログ運用なら、こういう形もできます。
node scripts/check-post.js content/drafts/example.md
| codex exec "この記事の公開前リスクを短く判定して"大事なのは、プロンプトを長くすることではありません。
毎回同じ検証結果を渡せる形にすることです。
Claude Codeでは hooks がループの安全装置になる
Claude Codeでループを作るなら、hooks が重要です。
公式ドキュメントでは、hooks はClaude Codeのライフサイクルの特定地点で自動実行されるユーザー定義のコマンドだと説明されています。
たとえば、次のようなことができます。
- 編集後に自動で整形する
- 危ないコマンドを実行前に止める
- 作業完了時に結果を検証する
- 入力が必要なときに通知する
- 文脈圧縮の前に記録を残す
Claude Codeのagent loop解説にも、PreToolUse、PostToolUse、Stop、SubagentStart、SubagentStop などのhookイベントが出てきます。 PreToolUse では実行前に危険な操作を止められます。 Stop では作業完了時に検証や保存ができます。
これは、AIに「ちゃんと確認して」と頼むのとは違います。
確認が必ず走る場所を、仕組みとして作る考え方です。
subagents は大きな作業を小さなループに分ける
Claude CodeにもCodexにも、subagentsの考え方があります。
これは、作業を小さく分けて、別の文脈で処理させるために使えます。
Claude Code公式ドキュメントでは、subagentは大量の出力を出す作業を分離したり、独立した調査を並列で進めたり、複数ステップの作業を順番に渡したりする使い方が紹介されています。
たとえばブログなら、こう分けられます。
- Analyst: 検索意図とデータを見る
- Strategist: 今回やる1か所を決める
- Writer: 冒頭や見出しを直す
- Coordinator: 公開前チェックをする
これは、1つのAIに全部考えさせるより安定します。
理由は単純です。
1つのループに1つの役割だけを持たせるからです。
まず作るべき5つの部品
ループで処理する仕組みを作るなら、最初から大きな自動化を作らなくていいです。
まずは5つだけで十分です。
1. 入力ファイル
AIに毎回見せる情報を固定します。
例は STATUS.md、AGENTS.md、作業対象ファイル、前回ログです。
入力が毎回変わると、AIは毎回迷います。
入力を固定すると、作業が安定します。
2. 作業単位
1回でやる作業を小さくします。
- 1記事1か所
- 1テスト1修正
- 1ページ1改善
- 1ログ1原因
作業単位が小さいほど、検証しやすくなります。
3. 完了条件
「終わり」を決めます。
- テストが通った
- リンク切れがない
- 画像数が減っていない
- 差分が1か所だけ
- 公開URLが200で返る
完了条件がないループは、ただの長い作業になります。
4. 止める条件
AIに任せるほど、止める条件が大事になります。
- 画像が減ったら止める
- 削除が必要なら止める
- 公開が必要なら確認する
- 3回失敗したら人間に戻す
- 外部情報が必要なら参照元を出す
止める条件は、AIを疑うためではありません。
安心して任せる範囲を広げるために必要です。
5. 記録
ループは記録がないと育ちません。
残すのは長い思考ではなく、短い結果で十分です。
- 対象
- 判断
- 理由
- 結果
- 次に試すこと
これが残ると、次回のAIが前回の失敗から始められます。
小さなループの例
ブログ運用なら、最初はこのくらいで十分です。
- 今日直す記事を1本選ぶ
- 直す場所を1か所だけ決める
- AIに修正させる
- リンク、画像数、見出しを確認する
- 問題があれば差し戻す
- 問題がなければ下書き保存する
- 公開は人間が確認する
これなら、プロンプト職人にならなくて済みます。
毎日同じ流れで回せます。
コードなら、こうです。
- 失敗ログを取る
- AIに原因を要約させる
- 最小修正だけ入れさせる
- テストを回す
- 失敗したらログを戻す
- 成功したら差分レビューに進む
この形は、Codexの修復ループの考え方と相性がよいです。
今日からやるなら、プロンプトではなくチェックリストを作る
最初に作るべきものは、最高のプロンプトではありません。
短いチェックリストです。
## 入力
- 対象ファイル:
- 参考ファイル:
- 前回ログ:
## 作業
- 今回やること:
- 今回やらないこと:
## 完了条件
-
## 止める条件
-
## 記録
- 対象:
- 判断:
- 理由:
- 結果:
- 次:これを毎回埋めるだけで、AIの使い方はかなり変わります。
人間が文章をひねる時間が減ります。
AIが同じ型で作業できるようになります。
AI時代の差は、1回の出力ではなく回し続ける力で出る
AI時代に大切なのは、1回で完璧な答えを出すことではありません。
小さく出して、確認して、直して、また回すことです。
プロンプトは大事です。
でも、プロンプトだけでは作業は続きません。
これから作るべきものは、プロンプト集ではなくループです。
入力、作業、検証、記録、停止条件。
この5つを決めるだけで、AIは「その場の相談相手」から「毎日仕事を進める仕組み」に変わります。
