はじめに
ここ1〜2年で、AIに仕事をさせるための「エンジニアリング」の名前が次々と生まれました。
- プロンプトエンジニアリング
- コンテキストエンジニアリング
- ハーネスエンジニアリング
- ループエンジニアリング
どれもバズワードに見えますが、並べてみると 「人が設計する対象の単位」がだんだん大きくなっている という、きれいな一本の流れになっています。
この記事では、4つをGIFアニメと図でざっくり掴めるように整理します。
この記事の結論（3行）
- プロンプト ⊂ コンテキスト ⊂ ハーネス ⊂ ループ の 入れ子構造 で理解すると迷わない
- 外側に行くほど「1つの指示」→「1回の呼び出し」→「1回の実行」→「繰り返される実行」と単位が大きくなる
- 人の役割は「AIに指示を打つ人」から「AIが働く仕組みを設計する人」へ移っている
全体像：4つは入れ子になっている
| 層 | 設計の単位 | 一言でいうと | 主な成果物の例 |
|---|---|---|---|
| プロンプト | 1つの指示 | どう頼むか | プロンプト、テンプレート |
| コンテキスト | 1回のモデル呼び出し | 何を見せるか | AGENTS.md / CLAUDE.md、ルール、検索結果の渡し方 |
| ハーネス | 1回のエージェント実行 | 周りの仕組みをどう作るか | ツール、スキル、サブエージェント、フック、MCP設定 |
| ループ | 繰り返される実行 | 誰が・いつ動かすか | スケジュール、停止条件、状態ファイル、予算、検証エージェント |
この「4層」の整理は、ループエンジニアリングを調査した論文（Lulla ほか, 2026）の Table 1 をベースにしています。論文では 各層は1つ前の層を包含する と説明されています。
ここからは内側から順に見ていきます。
① プロンプトエンジニアリング —「どう頼むか」
何をするものか
LLMへの 指示文そのもの を工夫して、望む出力を得る技術です。ChatGPT の登場直後から最も注目されてきた、いちばん内側の層です。
基本テクニック
| テクニック | 中身 |
|---|---|
| 役割を与える | 「あなたは〇〇の専門家です」 |
| タスクを明確にする | 曖昧な動詞（まとめて・いい感じに）を避け、ゴールを書く |
| 制約を書く | 文字数、対象読者、禁止事項 |
| 出力形式を指定する | 箇条書き、JSON、Markdown 表など |
| 例を見せる（Few-shot） | 期待する入出力の例を1〜数個添える |
| 考えさせる | 結論の前に手順や根拠を書かせる |
| 区切りを明示する |
<article>…</article> のように入力データとの境界を示す |
Before / After
この記事を要約して
# 役割
あなたは技術ブログの編集者です。
# タスク
<article> 内の記事を、AI初心者向けに要約してください。
# 制約
- 3行以内、1行40字以内
- 専門用語には短い説明を添える
# 出力形式
- Markdown の箇条書き
# 例
- RAG＝検索結果をモデルに渡して答えさせる手法
<article>
（ここに記事本文）
</article>
同じモデルでも、頼み方だけで出力の質が大きく変わる のがポイントです。
限界
プロンプトは「1回の指示」の最適化です。エージェントのように 何十ターンもツールを使いながら動く ようになると、指示文だけでは足りなくなります。そこで次の層が登場します。
② コンテキストエンジニアリング —「何を見せるか」
何をするものか
Anthropic は 2025年9月の記事「Effective context engineering for AI agents」で、コンテキストエンジニアリングを プロンプトエンジニアリングの自然な発展形 と位置づけました。
プロンプト（指示文）だけでなく、モデルが1回の推論で見る すべてのトークン を設計対象にします。
なぜ必要か：コンテキストは「有限の資源」
コンテキストウィンドウが大きくなっても、詰め込めば詰め込むほど良いわけではありません。トークンが増えるほどモデルの注意が分散し、重要な情報を見落としやすくなります（いわゆる コンテキストの劣化／context rot）。
Anthropic の記事の核心は、望む結果を最大化する「小さくて信号の濃い」トークンの集合を見つけること です。
代表的なテクニック
| テクニック | 中身 | 具体例 |
|---|---|---|
| キュレーション | 関係ない情報を入れない | 古いログ・無関係なファイルを除外 |
| ジャストインタイム取得 | 全部を先に読み込まず、必要な時にツールで取りに行く | コード全体ではなく grep で該当ファイルだけ読む |
| 圧縮（Compaction） | 上限が近づいたら履歴を要約して置き換える | 長い会話 → 要約＋未完了タスク |
| 構造化ノート | ウィンドウの外にメモを書き、後で読み戻す | TODOリスト、NOTES.md
|
| サブエージェント | 調査などを別のコンテキストで行い、要点だけ受け取る | 調査担当が要約だけを返す |
| 指示の高さ（altitude）調整 | 細かすぎるif文も、ふわっとしすぎた指示も避ける | 原則＋少数の良い例 |
身近な例：AGENTS.md / CLAUDE.md
コーディングエージェントでは、リポジトリに置く エージェント向けの README がコンテキストエンジニアリングの代表的な道具です。
# プロジェクト概要
- Next.js + TypeScript の社内ダッシュボード
# よく使うコマンド
- テスト: `pnpm test`
- 型チェック: `pnpm typecheck`
# ルール
- 新しいAPIは必ず `src/api/` に置く
- 変更後は必ずテストと型チェックを通す
コンテキストファイルは書けば書くほど良いわけではありません。毎回読み込まれるのでトークンを消費します。コンテキストファイルがタスク成功率をほとんど上げず、推論コストを2割以上増やしたという研究もあります（一方で実行時間やトークンが減ったという研究もあり、評価は割れています）。「毎回必ず必要な情報」だけ に絞るのがコツです。
③ ハーネスエンジニアリング —「周りの仕組み」を作る
Agent = Model + Harness
ハーネス（harness）はもともと 馬具 のことです。馬（モデル）の力を、目的の方向に安全に引き出すための装備、というイメージです。
ハーネス＝エージェントのうち、モデル以外のすべて（LangChain の「Agent = Model + Harness」という整理）と定義されることが多く、2026年に入って一気に広まった言葉です。2026年2月には OpenAI が、Codex チームが約5か月間、手書きのコードなしで約100万行規模のプロダクトを作った実践を公開しました。4月には Martin Fowler のサイトで Birgitta Böckeler（Thoughtworks）が利用者向けの解説記事を公開しています。
Addy Osmani は、要旨として次のように述べています。
そこそこのモデル＋良いハーネスは、すごいモデル＋悪いハーネスに勝つ
ハーネスの構成要素
| 要素 | 役割 | 例 |
|---|---|---|
| ルール・指示書 | 毎回読み込む前提知識 | AGENTS.md / CLAUDE.md |
| ツール / MCP | 外の世界に作用する手段 | ファイル操作、API、ブラウザ |
| サンドボックス | 安全に実行する隔離環境 | コンテナ、VM |
| フック・権限 | 実行前後の自動チェック、危険操作のブロック |
rm -rf を禁止、編集後に自動フォーマット |
| 検証 | 出力を「信じずに」機械で確かめる | テスト、リンター、型チェック、CI |
| メモリ / 状態 | セッションをまたいで進捗を引き継ぐ | 進捗ファイル、TODO |
| サブエージェント | 作業を分担し、コンテキストを分離する | 調査担当、レビュー担当 |
コンテキストエンジニアリングが「モデルに何を見せるか」なのに対し、ハーネスエンジニアリングは「エージェントがどう動くか」——環境・ガードレール・フィードバックを設計します。
1回の実行の中で起きていること
考え方のコツ：失敗を「ハーネスの改善」に変える
ハーネスエンジニアリングで最も大事な習慣は、エージェントのミスを、その場限りの失敗ではなく「仕組みを直すシグナル」として扱う ことです。
- 同じミスを2回したら → ルールに1行足す
- 危険な操作をしかけたら → フックでブロックする
- 「完了しました」と言うのに壊れていたら → 検証（テスト）を必須にする
プロンプトをいじる前に、仕組み側で再発しないようにできないか を考えます。
Böckeler は、コーディングエージェント製品に最初から組み込まれている部分（システムプロンプトなど）と、利用者が上に積み上げる部分を区別しています。私たちが日々触るのは主に後者（いわゆる outer harness）です。
④ ループエンジニアリング —「誰が・いつ動かすか」
何をするものか
ループエンジニアリングは 「エージェントにプロンプトを打つ人」を自分から仕組みに置き換える 設計です。
- ハーネスは 1回の実行 を支える
- ループは 何回もの実行を、時間をかけて統治する
- 何をきっかけに起動するか（定期実行、CI失敗、Issue作成…）
- 結果をどう検証し、どう保存するか
- いつ止めて、いつ人間に引き継ぐか
用語の誕生（2026年6月）
この言葉は2026年6月上旬、ほぼ同時期の複数の発信から広まりました。
- Claude Code の作者 Boris Cherny が、もう自分ではプロンプトを打っておらず「My job is to write loops」と語る
- OpenClaw 作者の Peter Steinberger が「エージェントにプロンプトを打つな、ループを設計せよ」という趣旨の投稿
- Addy Osmani がブログでこの実践を loop engineering と命名
前身としては、2025年に Geoffrey Huntley が紹介した Ralph Wiggum ループ が有名です。最も素朴な形は、文字どおりの無限ループでした。
while :; do cat PROMPT.md | claude-code ; done
毎回まっさらなコンテキストでエージェントを起動し、進捗はファイルに残す——という発想です。その後、Claude Code や Codex などのツールにも、繰り返し実行やゴール指定のコマンドが組み込まれていきました。
よく設計されたループの部品
以下は、前述の論文が実務者の記事や議論をまとめた「よく設計されたループに共通する部品」です（Osmani 自身は、定期実行、worktree、スキル、コネクタ、サブエージェントの5つと、状態ファイルを挙げています）。
| 部品 | 役割 | 例 |
|---|---|---|
| トリガー | 実行を始めるきっかけ | 毎晩2時、CI失敗、Issue作成 |
| 停止条件 | 「終わった」を機械で判定できる形にする | テストが全て通る、Lintエラー0 |
| 状態（State） | 実行をまたいで進捗を残す |
STATE.md、PR、実行ログ |
| 検証エージェント | 作る人とチェックする人を分ける（maker / checker） | レビュー専用のサブエージェント |
| 予算・停止スイッチ | トークンや時間の上限、緊急停止 | 1回あたりのトークン上限 |
| 制約 | 無人実行で変更してよい範囲 | 本番設定は触らない、PRまで |
| エスカレーション | 人に引き継ぐ条件 | 3回失敗したら通知 |
Osmani の言葉を借りると、ポイントは 「the agent forgets, the repo doesn't」。エージェント自身は毎回忘れても、リポジトリ（状態ファイル）が覚えている、という設計です。
シンプルなループの疑似コード
MAX_RETRY = 3
TOKEN_BUDGET = 200_000
def nightly_loop():
state = load("STATE.md") # 前回の続きから
task = pick_next_task(state)
used = 0
for attempt in range(1, MAX_RETRY + 1):
result = run_agent(task, context=state) # ← 中身はハーネス
used += result.tokens
verdict = run_verifier(result) # 作る人 ≠ チェックする人
if verdict.passed: # 停止条件
open_pull_request(result)
save("STATE.md", state.done(task))
return
if used > TOKEN_BUDGET:
break
task = task.with_feedback(verdict.reasons) # 失敗理由を次に渡す
notify_human(task, reason="上限に到達") # エスカレーション
自律度は段階的に上げる
Osmani はループを、人が何を手放すか で4種類に整理しています。
| 種類 | 人が手放すもの |
|---|---|
| ターン型 | （なし）毎ターン人がレビュー |
| ゴール型 | 停止条件の判定 |
| 時間型 | 起動のきっかけ（トリガー） |
| プロアクティブ型 | プロンプトそのもの（何をやるか） |
いきなり無人運転にせず、「レポートだけ」→「検証付きで修正」→「無人実行」 と、検証が信頼できると分かってから段階的に任せるのが定石です。
よくある失敗
- コスト暴走：CI修正ループが48時間で約800万トークンを消費した、という報告も
- 無限修正ループ：直す→壊す→直す…を繰り返す
- 検証の形骸化：中身を見ずに合格を出す「verifier theater」
- レビュー疲れ：PRが増えすぎて、人の承認がただのハンコになる
- 理解の負債：リポジトリの中身と、自分の理解の差がどんどん開く
「結局 cron ジョブの言い換えでは？」という懐疑的な声も根強くあります。新しいのはトリガーの仕組みではなく、非決定的な AI ワーカーを、検証・予算・エスカレーションで安全に囲う設計 の部分だ、という見方が妥当でしょう。
実際どれくらい使われている？
前述の論文（2026年時点で査読中のプレプリント）では、約3.7万のOSSリポジトリを調べ、自律的なエージェントループが動いているリポジトリを217件確認しています。用途は PRの自動レビュー と 定期的なIssueトリアージ が中心でした。一方、議論で推奨される状態ファイルをコミットしているリポジトリはほぼ無く、実践はまだ発展途上 と言えそうです。
4つを並べて比較
| プロンプト | コンテキスト | ハーネス | ループ | |
|---|---|---|---|---|
| 問い | どう頼む？ | 何を見せる？ | どんな環境で動かす？ | 誰が・いつ動かす？ |
| 単位 | 1つの指示 | 1回の呼び出し | 1回の実行 | 繰り返される実行 |
| 人の役割 | 指示を書く | 情報を選ぶ | 仕組みを作る | 仕組みを回す仕組みを作る |
| 失敗したときの直し方 | 言い回しを変える | 渡す情報を変える | ルール・フック・検証を足す | 停止条件・予算・検証を見直す |
| 代表的な成果物 | プロンプト | CLAUDE.md、検索設計 | スキル、フック、MCP | スケジュール、STATE.md、検証エージェント |
大事なのは「どれか1つ」ではなく「全部が入れ子」だという点です。
ループの中ではハーネスが動き、ハーネスの中ではコンテキストが組み立てられ、その中にプロンプトがあります。外側の層を作っても、内側の層が雑だと全体が崩れます。
どこから始めるか（実践ステップ）
- プロンプト：役割・タスク・制約・出力形式・例の5点を書く癖をつける
-
コンテキスト：プロジェクトに短い
AGENTS.md/CLAUDE.mdを置く。長くしすぎない - ハーネス：テスト・リンターを「エージェントが自分で回せる」状態にする。ミスが出たらルールかフックに反映する
- ループ：まずは「毎朝レポートだけ出す」ループから。検証が信頼できてから修正・無人実行へ
おわりに
- プロンプト：どう頼むか
- コンテキスト：何を見せるか
- ハーネス：どんな仕組みの中で動かすか
- ループ：誰が・いつ動かすか
と、設計の対象はどんどん外側へ広がっています。2026年7月には早くも「次はグラフ（ループ同士をつなぐ構造）だ」という議論まで出ていて、言葉の流行はまだ続きそうです。
ただ、名前が変わっても本質は 「AIが確実に良い仕事をできる環境を、人が設計する」 という一点です。まずは手元のプロジェクトで、一番内側から一段ずつ外へ広げてみてください。
参考文献
- Anthropic, Effective context engineering for AI agents（2025年9月）
- OpenAI, Harness engineering（2026年2月）
- Birgitta Böckeler, Harness Engineering for Coding Agent Users（martinfowler.com, 2026年4月）
- Addy Osmani, Agent Harness Engineering（2026年4月）
- Addy Osmani, Loop Engineering（2026年6月）
- Geoffrey Huntley, Ralph Wiggum as a "software engineer"（2025年7月）
- Gergely Orosz, What is "loop engineering?"（The Pragmatic Engineer, 2026年7月）
- Lulla ほか, Loop Engineering: Building Blocks, Adoption, and Impact（arXiv, 2026）
- IBM, What is loop engineering?