[生成AI] LLMからLoopまで — AIエンジニアリングはなぜこう進化したのか

はじめに

ここ数年で、AIを扱う方法を指す言葉がずいぶん変わりました。「プロンプトをうまく書くことが大事だ」という話が盛んになったかと思えば、いつの間にか「コンテキストが重要だ」という声が上がり、最近では「ハーネス（harness）」や「ループ（loop）」といった言葉まで登場しています。

これらの言葉は、流行に乗って単純に入れ替わってきたわけではありません。それぞれが、直前の段階がぶつかった限界を乗り越えるために登場したのです。プロンプトだけでは対応できない壁があったからコンテキストが生まれ、コンテキストだけでも越えられない壁があったからハーネスが生まれました。つまり、名前が変わるたびに、その裏には「前の方法では解けなかった問題」がひとつずつ隠れています。

この記事では、LLM → Prompt → Context → Harness → Loop という流れを、「各段階とは何か、なぜ登場したのか、どんな問題があって次の段階に移ったのか」という視点から追っていきます。静的な分類というよりも、進化の物語として読んでいただけると嬉しいです。

この記事が進化の「流れ」に焦点を当てるなら、各概念を積み重なるレイヤーとして並べて比較した AIエンジニアリング4つのパラダイムの記事は、静的な「構造」に焦点を当てています。ぜひ合わせてご覧ください。

LLM — すべての出発点

話の出発点は、大規模言語モデル（LLM）そのものです。

LLMは根本的に、「これまでのテキストの次に来る最も確からしいトークンを予測する」モデルです。膨大なテキストで学習されたこの予測器は、翻訳・要約・コード生成など、以前はそれぞれ専用のシステムが必要だったタスクを、ひとつのモデルで自然言語の指示だけでこなせるようにしました。

ここで初期の核心的な問いが生まれます。

「この強力な予測器に、どう命令を下せば望む結果が得られるのか?」

オープンソースの小規模モデルはデータを追加学習するファインチューニング（fine-tuning）で、大規模な商用モデルはAPIコールとともに必要な知識を渡す方式で、それぞれ答えを模索しました。しかし多くの実務者にとって、モデル自体に手を入れることは現実的ではありませんでした。触れられるのは結局、モデルに渡す入力テキストだけだったのです。

まさにこの地点から、最初のエンジニアリングが登場します。

Prompt Engineering — どう伝えるか

Prompt Engineeringは、モデルに渡す指示文（プロンプト）をどう書くかという技術です。モデルの重みは固定されているので、調整できる唯一のレバーである「入力テキスト」をできる限り丁寧に磨こうという発想です。

同じ質問でも、聞き方によって答えが大きく変わることは、誰もが経験されているでしょう。「コードレビューして」よりも「シニアバックエンドエンジニアの観点でセキュリティの問題を中心にレビューして」と言ったほうが、ずっと具体的な答えが返ってきます。こうした経験が積み重なり、いくつかの定型的な手法が確立されました。

Few-shot: 求める結果のサンプルをいくつか見せてパターンを学習させます。
Chain-of-Thought: 「ステップごとに考えてみてください」と促して推論プロセスを引き出します。
Role Prompting: 「あなたは10年のキャリアを持つバックエンドエンジニアです」のように役割を与えます。
出力フォーマット指定: 「JSONで回答してください」のように結果の形式をあらかじめ指定します。

たとえば回答の範囲を絞りたい場合、以下のように「何を扱い、何を扱わないか」を明示する書き方があります。

要件のWhatとWhyだけを分析してください。
How（技術的な実装）については議論しないでください。

ところで — プロンプトはあくまで「お願い」である

プロンプトエンジニアリングには根本的な弱点があります。どれだけ丁寧に書いても、それは強制ではなくお願いにすぎないという点です。

"IMPORTANT: 絶対にこうしないでください" と大文字で強調しても、モデルがその指示に必ず従う保証はありません。単語ひとつ、文の順番ひとつが変わるだけで結果が変わるほど脆くもあります。そして決定的に、プロンプトをどれだけうまく書いても、モデルが実際のファイルを開いたり、最新のAPIレスポンスを確認したり、プロジェクトの現在の状態を把握したりすることはできません。

「うまく話しかけること」と「必要な情報を与えること」は、次元の違う問題でした。この限界が、次の段階を呼び込みます。

Context Engineering — 何を見せるか

関心の焦点が、「どう話すか」から「何を一緒に見せるか」へと移ります。これがContext Engineeringです。

比喩で言えば、プロンプトが「この問題を解いて」という質問だとすると、コンテキストは試験紙の隣に広げておく参考資料です。同じ問題でも、関連する教科書を開いて解くのと、何も見ずに解くのとでは結果が違います。プロジェクトの背景、関連コード、ファイル構造、これまでの作業履歴 — モデルが良い判断を下すために必要な材料を選んで渡すことが、コンテキストエンジニアリングです。

この時期、モデルは単純な質問応答器を超え、ツールを使い（tool calling）、記憶を持ち（memory）、自ら次のアクションを決める（ReAct）エージェントへと進化し始めました。エージェントが良い意思決定をするには良いコンテキストが不可欠だったため、コンテキストエンジニアリングは自然とエージェント時代の核心技術となりました。

肝心なのは「必要なものだけを選んで入れること」

コンテキストウィンドウは無限ではありません。詰め込みすぎると肝心な情報が埋もれ、コストも上がります。そのため、APIレスポンス全体を渡す代わりに必要なフィールドだけを抽出し、巨大な指示ファイルひとつの代わりに状況に合ったモジュールだけを読み込むような設計が重要になりました。

# レスポンス全体を渡すと不要なデータまで入ってしまう
curl -s https://api.example.com/comments | jq '.[].body'

# 必要なものだけを選んで渡すほうがずっと効率的
curl -s https://api.example.com/comments \
  | jq '.[] | select(.tag == "review") | .body'

ところで — 情報をうまく渡しても崩れる地点がある

コンテキストをどれだけ丁寧に設計しても、タスクが長く複雑になると成功率が急激に下がる現象が観察されます。代表的な問題としては、以下のようなものがあります。

Context Rot: 会話が長くなりコンテキストウィンドウを超えると、前半の内容を忘れてしまいます。
セッションの断絶: セッションが変わると記憶が消え、前の作業と衝突したり流れが途切れたりします。
ルールの脆さ: コンテキストにルールを書いておいても、それもやはり「プロンプト」なので一貫して守られるとは限りません。

結局、コンテキストエンジニアリングはモデルの判断材料を最適化するだけで、その判断が常に守られるよう強制したり、判断後の実行を安全に包んだりすることはできませんでした。良い材料を渡したからといって、料理が必ず成功するわけではなかったのです。

Harness Engineering — どんな制約の中で働かせるか

ここで登場するのがHarness Engineeringです。Harnessはもともと馬の力を安全に制御する馬具を意味します。つまりモデルを包んで正しい方向に制御する構造を作ろうということです。この考え方はよく、こう要約されます。

Agent = Model + Harness

モデルの性能と同じくらい、そのモデルを包んだハーネスの設計がエージェントの実際のパフォーマンスを左右するという意味です。この用語は2025年末にAnthropicが「effective harness」に言及したことで注目され、2026年初頭にMitchell Hashimotoが自身の AI導入記でこれを取り上げたことで広く知られるようになりました。

Hashimotoはハーネスエンジニアリングをこう定義しています。

「エージェントがミスをするたびに、そのミスを二度と繰り返さないよう解決策をエンジニアリングすること。」

核心は、お願いから強制への移行にあります。コンテキストエンジニアリングまでが「こうしてほしい」だったとすれば、ハーネスは「この範囲を超えることを最初から不可能にする」に近いものです。具体的には、おおむね以下のような方法があります。

最小権限の原則 — 必要な能力だけを与え、範囲を絞ります。読み取りは許可するが、削除や管理者コマンドはブロックする、といった具合です。ミスが起きても、その影響範囲があらかじめ制限されています。

{
  "permissions": {
    "allow": ["Bash(ls:*)", "Bash(cat:*)", "Read(/src/**)"],
    "deny": ["Bash(rm:*)", "Bash(sudo:*)"]
  }
}

自動検証（Hooks） — プロンプトで「テストを実行してください」とお願いする代わりに、コミット時点でlintやテストを構造的に強制します。通過できなければ次のステップに進めません。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit:*)",
        "hooks": [{ "type": "command", "command": "npm run lint" }]
      }
    ]
  }
}

検証ツールの提供 — Hashimotoが強調した点で、エージェントに自分で結果を確認できる手段を与えることです。自分の作業を検証する方法があれば、エージェントはたいてい自らミスを修正し、リグレッションを防ぎます。この地点で、すでにフィードバックループの種が見えます。

CLAUDE.md / AGENTS.md のような基準ドキュメントでセッション間の状態を外部に明示的に記録すること、危険な操作の前に承認ステップを設けることも、すべてハーネスに含まれます。

ところで — 安全な部屋を作っても、ドアを開けるのは人間だ

ハーネスはエージェントが働く「部屋」を頑丈に作ってくれます。しかしその部屋で仕事を始めさせるのは、依然として人間です。人間がプロンプトを入力して初めてエージェントが1サイクルを回し、結果を確認した人間が再び次のプロンプトを入力します。

タスクが反復的で長くなるほど、この「人間が毎回プロンプトを入力する」というボトルネックが目立ってきます。安全な部屋と有能な働き手は用意できているのに、肝心の仕事を回し続ける動力が人間のタイピングに縛られているのです。この最後のボトルネックを狙ったのが、Loop Engineeringです。

Loop Engineering — 誰がプロンプトを入力するか

Loop Engineeringは、発想をもう一段ひっくり返します。

「プロンプトをうまく入力する」のではなく、プロンプトを代わりに入力するメカニズムを設計する。

核心は、人間とエージェントの間の繰り返しを自動化することです。エージェントが自ら現在の状態を観察し → 次のアクションを決め → 実行し → 結果を評価し → 続けるか止めるかを判断する、このサイクルを人間の介入なしに回せるようにすることです。人間の役割は、毎ステップを指示することから、何を達成すべきか（ループの設計）へと移ります。

ハーネスエンジニアリングで登場した「自己検証 → 自己修正」のフィードバックループを、システムの中心軸へと引き上げたものとも言えます。実際の運用フェーズのループは、おおむね以下の要素で構成されます。

トリガー（Automation）: スケジュールやイベントによって、ループが自律的に開始されます。
ワークツリー（Worktree）: 複数のタスクが衝突しないよう、隔離された空間で並列に処理します。
スキル/プラグイン: エージェントが参照する手順書と外部ツールとの接続。
サブエージェント: 作成するエージェントと検証するエージェントのように役割を分担します。
状態/メモリ: 再起動を超えてタスクの状態を継続的に追跡します。

ところで — これはまだ完成した方法論ではない

Loop Engineeringは現在進行中の概念です。「実在するが、まだ完結した方法論ではない」という表現が正確です。人間がループから抜けるほどトークンコストが膨らみ、「結果が本当に正しいか」を検証する責任はむしろ重くなります。何より、人間が直接書いていないコードが積み上がっていく理解の負債（comprehension debt）という新たな課題が生まれます。

つまり人間が不要になったのではなく、役割が毎ステップの実行者からループ全体の設計者・監督者へと移ったにすぎません。そしてこれまでのパターンが繰り返されるとすれば、次の段階が何になるかは、おそらくこの新しい問題 — コストと理解の負債 — がどこで壁にぶつかるかが決めることになるでしょう。

進化の全体像

ここまでの流れをひとつの表にまとめると、以下のようになります。

段階	核心の問い	調整対象	登場を促した限界
LLM	どう命令するか	モデル自体	モデルは固定、入力だけ調整可能
Prompt	どう伝えるか	指示文	お願いにすぎず、情報も強制力もない
Context	何を見せるか	情報	判断は最適化できても、実行・強制はできない
Harness	どんな制約で働かせるか	環境・権限	部屋は安全でも、始めるのは人間の役割
Loop	誰がプロンプトを入れるか	繰り返し自体	コスト・理解の負債（進行中）

貫く2つの軸が見えます。

第一に、「お願い」から「強制」へ。プロンプトは守ってほしいというお願いでしたが、ハーネスは逃れられない制約になりました。

第二に、「人間が毎回介入」から「人間は設計のみ」へ。プロンプトの時代には人間が一言一句入力していましたが、ループの時代には人間がシステムを設計して一歩引きます。

ひとつ誤解しないでほしいのは、後の段階が前の段階を廃棄するわけではないという点です。ループの中でも、依然として良いプロンプトが必要で、良いコンテキストが必要で、頑丈なハーネスが必要です。後から登場したエンジニアリングは、先のものを包み込みながら増幅させる関係に近いです。この「積み重なるレイヤー」の構造は、AIエンジニアリング4つのパラダイムの記事でより詳しく扱っています。

まとめ

AIを扱う方法を指す言葉は、流行に乗って変わってきたのではなく、前の段階の限界が次の段階を生む形でつながってきました。

LLM: 固定された予測器。触れられるのは入力だけ。
Prompt: 入力を磨く。しかしお願いにすぎない。
Context: 情報を一緒に渡す。しかし強制はできない。
Harness: 制約で強制する。しかし始めるのは人間の役割。
Loop: 繰り返しまで自動化する。代わりに新たな負債を残す。

今、私たちはHarnessが定着し、Loopがちょうど議論され始めた地点に立っています。この記事の後にどんな名前が登場するかはわかりませんが、おそらくそれもLoopがぶつかった限界を乗り越えるための何かになるでしょう。新しい用語に出会うたびに「これは前の段階のどんな問題を解こうとしているのか?」と問いかければ、流行語の洪水の中でも流れを見失わずにいられると思います。