AIエージェントで本当に重要なのはLLMではない？Harness EngineeringとLoop Engineeringから考える次世代AI開発
はじめに
AIエージェントについて調べていると、まず目に入ってくるのはLLMの性能です。
どのモデルが一番賢いのか。GPT系とClaude系ではどちらが強いのか。推論性能はどのモデルが優れているのか。コンテキストウィンドウはどれくらい必要なのか。もちろん、モデル選びは重要なポイントです。
ただ、実際にAIエージェントを開発していると、少し違う景色が見えてきます。モデルを高性能なものに変えただけでは、エージェントが劇的に優秀になるわけではないのです。
理由は単純で、AIエージェントはLLMそのものではないからだと思っています。
LLM
+
Context
+
Tools
+
Execution Environment
+
Memory
+
Evaluation
+
Feedback
+
Recovery
こうした複数の要素が組み合わさって、はじめてエージェントになります。そしてこれらをつなぎ、
考える → 行動する → 結果を見る → 評価する → 修正する → もう一度行動する
というループを回していく。この視点に立つと、これからのAIエージェント開発で重要になるのは「どのLLMを使うか」だけではなく、「LLMをどんな環境とループの中に置くか」なのではないか、と感じるようになりました。
この記事では、そのあたりをHarness Engineering、Loop Engineering、Agentic Workflow、Evaluation、Feedback Loopといったキーワードから整理してみます。
1. AIエージェントは「LLMにツールを付けただけ」ではない
AIエージェントを単純化すると、次のような流れをイメージしがちです。
User → LLM → Tool → Result
「このコードを修正してください」と依頼すると、LLMがコードを読んで、書いて、完了する。そんな動きを想像します。
しかし実際のソフトウェア開発は、これだけでは終わりません。コードを書いたあとには、ビルドして、テストして、失敗して、エラーを見て、原因を分析して、修正して、もう一度テストする、という工程が必ず発生します。
つまり実際のAIエージェントは、
目的 → 計画 → 実行 → 観測 → 評価 → 修正 → 再実行 ↺
というループを持つことになります。ここで大事なのは、「LLMの性能」だけではこのループ全体の質が決まらない、という点です。
2. AIエージェントの能力を決めるもの
AIエージェントの能力は、次のように分解すると考えやすくなります。
AI Agent
├── Model
├── Context
├── Tools
├── Execution
├── Observation
├── Evaluation
├── Memory
├── Recovery
└── Feedback Loop
それぞれ役割が違います。
Modelは推論や生成を担当します。Contextは、AIが判断するために必要な情報を提供する役割です。Toolsは、AIが外部世界に対して行動するための手段になります。Executionは、実際にコードを実行したりAPIを呼んだりする環境そのもの。Observationは、AIが実行結果を確認する仕組みで、Evaluationはその結果が正しかったのかを判断する仕組みです。Memoryは過去の状態や情報の保持を、Recoveryは失敗したときの復旧を担い、Feedback Loopが評価結果を次の行動に反映していきます。
この中でLLMが担当しているのは、あくまで一部分にすぎません。
3. Harness Engineeringとは何か
ここで登場するのがHarness Engineeringです。
Harnessという言葉は、もともと「馬具」や「安全装置」のような意味を持っています。AIエージェントの文脈では、AIが仕事をするための実行環境全体を設計すること、と考えると分かりやすいでしょう。
AI Agent
├── Git
├── Shell
├── Browser
├── API
├── Database
├── File System
├── Test Environment
├── Logs
├── Evaluation
└── Sandbox
こうした環境のことです。つまりHarnessは、AIそのものではなく、AIが働くための「場」を指しています。
4. なぜHarnessが重要なのか
非常に優秀なAIモデルがあったとしても、ファイルを読めない、コードを実行できない、テストできない、APIを呼べない、実行結果を確認できない、エラーを取得できない、過去の状態を確認できない——となると、できることには自然と限界が出てきます。
逆に、多少モデル性能が劣っていても、コードを読み、書き、実行し、テストし、エラーを取得し、修正して再テストする、という環境が整っていれば、かなり高度な仕事を任せられるようになります。
ここから見えてくるのは、AIの能力はモデルだけではなく、モデルが置かれている環境によっても決まる、という考え方です。
5. HarnessはAIを制限するものではない
Harnessというと、「AIにできることを制限する仕組み」だと思う人もいるかもしれません。
でも、実際はむしろ逆だと感じています。安全なHarnessがあるからこそ、AIに大きな自由度を与えられるのです。
サンドボックス、Git、自動テスト、ログ、ロールバック、権限管理。こうしたものが揃っていれば、AIにかなり自由にコードを書かせることができます。もし失敗しても、検出して、原因を確認して、修正して、再実行すればいいからです。
つまりHarnessは、AIを縛るための檻ではなく、AIに自由に仕事をさせるための安全装置だと捉えています。
6. Loop Engineeringとは何か
では、Loop Engineeringとは何でしょうか。
この記事では、AIが「実行 → 観測 → 評価 → 修正 → 再実行」というループを継続的に回せるように設計・改善すること、という意味で使っています。
ここで大事なのは、AIに正解を出させることだけを考えないことです。AIが間違えることを前提に、間違える→検出する→原因を理解する→修正する→再実行する、という仕組みを作っていきます。
7. AIエージェントでは「失敗しない」より「失敗から戻れる」が重要
AIは間違えます。これは避けられません。
コード生成でも、syntax error、type error、test failure、API error、dependency error、logic error、いろいろなエラーが発生します。
ここで「絶対に間違えないAIを作ろう」とすると、プロンプトやルールがどんどん複雑になっていきます。それよりも、間違えても自分で検出して修正できるAIを作ろう、と考えたほうが、エージェント設計としては自然だと思っています。
8. GenerateよりVerifyが重要になる
AIエージェント開発で個人的にとても重要だと感じているのが、Generate → Verifyという考え方です。
AIが「コードを書きました」と言っただけでは、まだ仕事は終わっていません。必要なのは、
Generate → Execute → Verify → Repair → Repeat
という流れです。コードを生成し、テストを実行し、失敗したらエラーログを取得して原因を分析し、修正して、また再テストする。この構造があると、AIは「コード生成器」から「ソフトウェア開発エージェント」に変わっていきます。
9. EvaluationがLoop Engineeringの中心になる
ループを回すためには、何をもって成功とするのかを定義する必要があります。これがEvaluationです。
ソフトウェアであれば、テストが全部通る、ビルドが成功する、型チェックが通る、Lintエラーがない、APIレスポンスが期待値と一致する、といった基準が考えられます。
リサーチであれば、情報源が存在する、複数ソースで確認できる、引用が正しい、矛盾が解消されている、といった観点になるでしょう。
評価できない仕事は、自律的なループにしにくい。これは経験的にも感じるところです。
10. 「AIにもっと注意させる」より「評価できる環境を作る」
AIが間違えたとき、「もっと注意してください」というプロンプトを追加するだけでは、根本的には解決しないことがよくあります。
そうではなく、コードを書かせて、自動テストにかけて、失敗したらその内容をAIに返して、AIが修正して、再テストする——この仕組みにすれば、AIの「注意力」に頼らずに、システムそのものがAIを改善方向へ導いてくれます。
これは、思っている以上に大きな違いです。
11. Prompt EngineeringからLoop Engineeringへ
これまでの生成AI開発では、Prompt Engineeringがとても重要でした。
「あなたは優秀なソフトウェアエンジニアです。以下のコードを分析し、バグを修正してください。必ずエッジケースも考慮してください。」——こういったプロンプトです。これは今でも大切な部分です。
ただAIエージェントでは、プロンプトに加えてツール、実行環境、テスト、評価、フィードバックが重要になってきます。「どう指示するか」から「どう仕事をさせるか」へと、重心が移っていく感覚があります。
12. Agentic Workflowという考え方
ここで重要になるのがAgentic Workflowです。
単純なAI処理であれば、
Input → LLM → Output
で完結します。Agentic Workflowでは、
Goal → Plan → Act → Observe → Evaluate → Reflect → Act → Observe → Complete
という形になります。AIが一度回答して終わるのではなく、目的達成まで何度も行動する。これがAgentic Workflowの特徴です。
13. AIエージェントの本質は「自律性」だけではない
AIエージェントという言葉を聞くと、人間が何もしなくても勝手に仕事をするAI、を想像しがちです。
でも本質は、必ずしもそこではないと思っています。重要なのは、AIが環境から情報を取得し、その情報を使って次の行動を決定できること。
Environment → Observation → Decision → Action → Environment
という循環です。この循環があるからこそ、エージェントは複数ステップの仕事を処理できます。
14. Human-in-the-loopからAgent-in-the-loopへ
従来のAIシステムでは、AIが出した結果を人間が確認して、修正して、また戻す、というHuman-in-the-loopが一般的でした。
これからは、AIが実行して、評価して、AI自身が修正して、再実行して、評価して、最後に人間が確認する——という構造が増えていくと感じています。
これはHuman-in-the-loopをなくすという意味ではありません。むしろ、人間がAIのすべての中間処理を見る必要をなくし、人間は重要な判断に集中できるようにする、という方向だと考えています。
15. AIエージェントに必要な「観測可能性」
Loop Engineeringで意外と見落とされがちなのがObservabilityです。
AIが何をしたのか分からなければ、失敗しても修正できません。何を実行したのか、どのツールを使ったのか、どんな引数だったのか、何が返ってきたのか、どこで失敗したのか。これらを追跡できる必要があります。
AIエージェントのログは、人間向けだけでなく、AI自身のフィードバックにも使われるものだと考えると腑に落ちやすいと思います。
16. Context Engineeringも重要になる
AIエージェントが賢く行動するためには、適切なコンテキストが欠かせません。
とはいえ、とにかく大量の情報を渡せばいい、というわけではなく、その時点で必要な情報を適切に提供することが大切です。
ソフトウェア開発であれば、README、Architecture、Coding Rules、Source Code、Tests、Previous Errorsといった要素があります。必要な情報を必要なタイミングで提供できれば、推論の質はぐっと上がります。このコンテキスト設計も、今後のAIエージェント開発では重要な領域になっていくはずです。
17. Tool Engineeringという考え方
AIエージェントはツールを使います。ただ「ツールがある」だけでは十分ではありません。
大切なのは、AIが正しく使えるツールを設計することです。巨大で複雑、引数が多い、結果が分かりにくい——そんなツールより、目的が明確で、入力がシンプルで、出力が構造化されていて、失敗理由が分かりやすいツールのほうが、エージェントにとっては扱いやすくなります。
AI時代には、Tool Engineeringという領域も自然と重要になっていくと感じています。
18. Memoryは「何でも保存する」ことではない
AIエージェントではMemoryも重要ですが、全部覚えさせればいい、というわけではありません。
何を保存するか、いつ保存するか、いつ取り出すか、いつ忘れるか。この判断が意外と難しいところです。短期コンテキスト、現在のタスク、セッション履歴、長期メモリ、プロジェクト知識といったように、情報を階層化して考える必要があります。
19. Recovery Engineeringという発想
AIエージェントは失敗します。だからこそ、Recoveryも設計対象になります。
Tool Errorが起きたら、リトライする、別のツールを試す、別のアプローチを取る、それでも駄目ならHuman Reviewに回す。こうしたフォールバックの発想です。
失敗を例外として扱うのではなく、通常の状態として扱う。これがRecovery Engineeringの根っこにある考え方だと思います。
20. これからのAIエンジニアは「AIの環境」を設計する
ここまでを整理すると、AIエンジニアの仕事の中身は少しずつ変わっていくのではないかと感じています。
これまでは、モデルを選ぶ、プロンプトを書く、回答を改善する、という流れでした。
これからは、モデルを選ぶことに加えて、Contextを設計し、Toolsを設計し、Execution Environmentを作り、Evaluationを作り、Feedback Loopを作り、Recoveryを作り、Observabilityを作る、という仕事に広がっていきます。
AIを使う人から、AIが働く環境を作る人へ。そんな変化が起きているように思います。
21. 「モデル性能 × Harness × Loop」という考え方
AIエージェントを考える上で、私は次の式が分かりやすいと感じています。
Agent Capability = Model Capability × Harness Quality × Loop Quality
厳密な数学式ではありませんが、考え方としてはかなり有効だと思っています。
どれだけ優秀なモデルでも、Harnessが悪ければ行動できません。Loopが悪ければ、失敗を検出できず、改善もできません。逆に、優秀なModelと優れたHarness、優れたLoopが組み合わさると、AIエージェントは大きな仕事を処理できるようになります。
22. だから「どのモデルが一番強い？」だけでは足りない
AIモデルの比較は、これからも重要なテーマであり続けると思います。
ただ、「GPTとClaudeのどちらが強いか」という問いだけでは、AIエージェント開発の全体像はなかなか見えてきません。本当に重要なのは、どのモデルか、どんなContextを与えるか、どんなToolsを持たせるか、どんな環境で実行するか、どう評価するか、失敗したらどう戻るか、といった要素の組み合わせです。
モデル選定は、AIエージェント開発の一部分にすぎない、と感じています。
23. では、どんなAIエージェントが強いのか
強いAIエージェントは、一発で完璧な回答を出すAIとは限りません。
むしろ、そこそこ正しい答えを出し、実行し、間違いを発見し、修正し、再実行し、さらに改善していく——そんなAIのほうが、複雑な仕事では力を発揮します。
これは人間の仕事とよく似ています。優秀なエンジニアも「一度も間違えない人」ではなく、「間違いを早く見つけて、早く修正できる人」です。AIエージェントも、同じ方向に進んでいくのかもしれません。
24. Harness Engineering × Loop Engineering
ここまでの内容を整理すると、次のようになります。
Harness Engineeringは、AIが仕事をする環境を作ること。Loop Engineeringは、AIが仕事を改善し続けるループを作ること。
この2つを組み合わせると、次のような構造になります。
┌──────────────┐
│ AI Agent │
└──────┬───────┘
↓
┌──────────────┐
│ Tools │
└──────┬───────┘
↓
┌──────────────┐
│ Execute │
└──────┬───────┘
↓
┌──────────────┐
│ Observe │
└──────┬───────┘
↓
┌──────────────┐
│ Evaluate │
└──────┬───────┘
↓
┌──────────────┐
│ Repair │
└──────┬───────┘
│
└──────────→ 再実行
この環境全体を設計するのがHarness Engineering、その中で改善ループを設計するのがLoop Engineering、という関係になります。
25. AIエージェント開発で今後重要になる領域
この考え方から見えてくる、今後重要になりそうな領域を挙げてみます。
Harness Engineering、Loop Engineering、Agentic Workflow、Context Engineering、Tool Engineering、Evaluation、Observability、Memory、Recovery、Human-in-the-loop、Agent-in-the-loop、AI Coding、Autonomous Software Engineering。
一見バラバラの技術に見えますが、実際にはすべて「AIにどう仕事をさせるか」という1つの問いにつながっていると感じています。
26. AIエージェント時代の開発者に必要なのは「プロンプト」だけではない
AIエージェント開発を始めると、最初はどうしてもプロンプトに注目します。これは自然なことです。
ただ、ある段階から「プロンプトを改善しても、これ以上は良くならない」という壁に当たります。そこで必要になるのが、プロンプトに加えてContext、Tools、Environment、Evaluation、Feedbackです。
プロンプトを改善するだけでなく、システムを改善する。そんな発想への転換が求められます。
27. これからは「AIを賢くする」より「AIが賢く働ける環境を作る」
これは、今後のAI開発でかなり重要になってくる考え方だと思っています。
AIそのものの性能は、モデルアップデートによって急速に変化していきます。一方で、どういう情報を与えるか、どういうツールを与えるか、どういう環境で実行させるか、どう評価するか、どう失敗から戻すか、という設計はアプリケーション側の資産として残り続けます。
モデルを交換しても価値が残るアーキテクチャを作ること。ここに重きを置いておきたいと感じています。
28. まとめ
AIエージェント開発では、LLMの性能だけを見ていると、本質を見失ってしまうことがあります。
AIエージェントは、Model、Context、Tools、Execution、Observation、Evaluation、Memory、Recovery、Feedbackというシステムです。そしてその中心にあるのが、Harness EngineeringとLoop Engineeringだと考えています。
Harness Engineeringは、AIが仕事をするための環境を設計すること。Loop Engineeringは、AIが実行・観測・評価・修正を繰り返して、仕事を改善できるようにすること。この2つが、これからのAIエージェント開発を支える土台になっていくはずです。
29. 最後に
AIエージェントについて考えるとき、「どのLLMが一番賢いのか」という問いは、これからも重要であり続けると思います。
ただ、それだけではありません。そのAIをどんな環境に置くのか。どんなツールを与えるのか。何をもって成功とするのか。失敗したらどう検出するのか。どうやって修正させるのか。どうやってもう一度実行させるのか。こうした問いこそが、本当は重要なのではないかと感じています。
AIエージェント時代のソフトウェア開発では、「AIを賢くする」だけでなく、「AIが賢く働ける環境を設計する」ことが重要になっていく。
Harness Engineering × Loop Engineeringは、そのための考え方として、これからさらに存在感を増していくキーワードなのではないでしょうか。
関連記事
このテーマをさらに掘り下げるなら、次のようなテーマも気になってくるはずです。
- AIエージェントとは何か
- Harness Engineeringとは何か
- Loop Engineeringとは何か
- Agentic Workflowとは何か
- AIエージェントの評価方法
- Context Engineeringとは何か
- AIエージェントのTool設計
- AIエージェントのMemory設計
- AIエージェントのObservability
- AIエージェントの失敗とRecovery
- Human-in-the-loopとは何か
- AIコーディングエージェントの設計
- 自律型ソフトウェア開発とは何か
この記事のポイント
最後に、この記事で伝えたかったことを3つにまとめておきます。
1つ目は、LLMだけではAIエージェントにならないということ。LLM、Tools、Context、Environment、Evaluation、Feedbackが揃って、はじめてエージェントとして機能します。
2つ目は、AIは失敗することを前提に設計するということ。Execute、Observe、Evaluate、Repair、Repeatというループを回せるかどうかが分かれ目になります。
3つ目は、これからのAI開発では「環境設計」が重要になるということ。AIそのものだけでなく、AIがどう働くかを設計することが、AIエンジニアリングの中心的な仕事になっていくと感じています。
AIエージェントの競争力は、モデル性能だけでは決まりません。どんなHarnessを作り、どんなLoopを設計するか。ここに、これからのAIエージェント開発の大きな差が生まれると考えています。
Tags
AI AIエージェント LLM 生成AI AgenticAI