一つの比較から始める

ChatGPT に「KV Cache とは何か」と聞くと、モデルが答えて会話は終わります。

Codex CLI に「このプロジェクトへテスト付きのユーザー認証 module を追加して」と伝えると、agent は自律的に作業を始めます。プロジェクト構造を読む → 既存コードを理解する → 実装を計画する → 認証ロジックを書く → テストを書く → テストを実行する → 失敗を見つける → 修正する → テストを通す → PR を作る、という流れです。数十 step に及ぶ間、あなたが介入しないこともあります。

基盤の LLM は同じでも、振る舞いはまったく違います。前者は LLM の従来の使い方、後者は agentic な使い方です。

この記事では、その転換の本質を説明します。単に「モデルが強くなった」のではなく、利用 paradigm が根本から変わり、その変化が周囲の engineering system 全体を作り替えています。

Agentic とは何か

Agentic は agent に形容詞の接尾辞 -ic を付けた語で、「agent の性質を持つ」という意味です。

一問一答だけの LLM は tool です。あなたがそれを使いますが、それがあなたのために行動するわけではありません。LLM を loop に入れ、自律的に 計画 → 判断 → 実行 → 観察 → 再判断 させると、目標へ向かって能動的に働く agent になります。

Agentic な LLM は通常、四つの特徴を持ちます。

1. 自律的な多段階実行。 一回の会話で終わらず、agent 自身が次の行動を決め、目標を達成するまで続けます。タスクは 10 step のことも 100 step のこともあります。

2. Tool の利用。 モデルは文章を生成するだけではありません。shell command の実行、file の読み書き、API call、database query、browser 操作ができます。LLM の「手」は keyboard から OS 全体へ広がります。

3. 環境認識と feedback loop。 Agent は自分の行動結果を観察します。テストは通ったか、command は失敗したか、画面は正しく描画されたかを見て、次の行動を変えます。行動 → 観察 → 推論 → 次の行動という閉ループです。

4. Session をまたぐ継続作業。 一回の会話で終わらず、複数の context window を越え、数時間から数日にわたる長期目標を進められます。

四つを同時に持つ LLM は、単なる chatbot ではありません。自分の作業 loop と tool を持ち、環境を認識し、継続的に進める「デジタルエンジニア」に近づきます。

Chat から Agent へ：連続変化ではなく相転移

この変化は直線的ではありません。「モデルが強くなったので、できることが増えた」だけではないのです。物理学の 相転移 に似ています。水を 100°C まで熱すると「さらに熱い水」になるのではなく、蒸気という別の状態になります。

LLM の chat から agent への転換も同じです。十分な instruction following、reasoning、信頼できる tool use という能力がしきい値を超えると、質問へ答える tool から自律的に働く存在へ変わります。そして周囲の engineering system に連鎖的な変化が起きます。

エンジニアの役割の変化

Chat paradigm では、エンジニアがコードを書き、LLM が補完、review、Q&A で支援します。人間が実行者で、AI は助言者です。

Agentic paradigm では、エンジニアが環境と制約を設計し、agent がコードを書く作業を実行します。人間は architect と supervisor、AI は executor になります。

OpenAI の Harness Engineering はこれを正確に表現しています。人間が方向を導き、agent が実行する。エンジニアの中心業務は、すべてのコードを自分で書くことから、環境を設計し、意図を明確にし、agent を信頼できるものにする feedback loop を作ることへ移ります。

技術 stack の進化

この paradigm shift は、三つの engineering discipline を順に積み上げました。

Prompt Engineering（2023〜2024）。 中心課題は、良い質問をどうするか。tool は system prompt、few-shot examples、CoT。比喩は、非常に賢いが字義どおりに受け取る同僚との話し方を学ぶことです。

Context Engineering（2025）。 中心課題は、正しい情報をモデルへどう見せるか。tool は RAG、MCP、構造化 context 管理。比喩は、同僚へ作業方法を教えるのではなく、正しい参考資料を用意することです。

Harness Engineering（2026）。 中心課題は、agent が長時間自律実行しても、どう信頼性を保つか。tool は architecture constraint linter、CI verification、observability feedback loop、permission control、documentation governance、entropy management。比喩は、資料を用意するだけでなく、職場全体、つまり席の配置、承認 flow、安全基準、品質保証を設計し、自分がいない間も複数の同僚が信頼性高く働けるようにすることです。

重要なのは、三つは置き換えではなく積み重ねである ことです。Prompt engineering は消えず、context engineering が prompt を古くしたわけでもなく、harness engineering が前二者を不要にしたわけでもありません。地層のように積み重なり、新しい層は下の層を前提にします。

なぜ Prompt と Context だけでは足りないのか

Prompt と context が重要なままなら、なぜ十分ではなくなったのでしょうか。

Agentic な LLM は、prompt と context だけでは処理できない三つの課題を持ち込みました。

課題1：操作の不可逆性

LLM が質問へ答えるだけなら、最悪の結果は誤った回答です。無視できます。しかし自律 agent は remote Git branch を削除し、authentication token を外部 server へ upload し、本番 database に migration を実行できます。これらは元に戻せないことがあります。

Prompt では安全を保証できません。system prompt に「本番データを削除しないで」と書くことは決定的な control ではありません。必要なのは、モデルの context 外にある 構造的な permission enforcement です。Claude Code auto mode はその例です。独立した classifier が実行前に危険な行動を遮断します。この classifier は agent の内部推論を意図的に見られず、agent に「説得」されて危険な操作を許すことを防ぎます。

課題2：実行時間と Context の劣化

Chat は数分、数千 token で終わることがあります。Agentic task は数時間実行し、複数の context window をまたぎ、数十万 token の履歴を生みます。

Context window が満杯になる前でも、signal が noise に埋もれることで性能は劣化します。token が増えるたびに注意を奪い合います。agent は constraint を忘れたから失敗するのではなく、蓄積した履歴が重要な constraint を隠すために失敗します。

解決策は context をさらに増やすことではありません。かえって悪化することがあります。必要なのは 構造化 context management、つまり progressive disclosure、階層化された文書、定期的な compaction、session 間の進捗 file です。これは prompt ではなく harness 層の仕組みです。

課題3：コードベースの Entropy 増大

Agent が大量のコードを自律生成すると、コードベースの既存 pattern を複製します。悪い pattern も含まれます。時間とともに style の不整合、重複ロジック、architecture の劣化が蓄積します。OpenAI はこれを entropy と呼び、agent が定期的に逸脱を探して refactoring PR を作る garbage collection を設計しています。

これも prompt だけでは解けません。linter と構造テストによる機械的な architecture constraint、そして自動化された code governance が必要です。

Agent の中核 Loop

Agentic 化の本質を理解すると、実際の仕組みは明快です。実装に関係なく、coding agent の中心には同じ loop があります。

while 目標が未完了:
    1. 観察（コード、文書、テスト結果、エラーを読む）
    2. 推論（観察と目標から次の行動を決める）
    3. 行動（tool を呼び、file を書き、command や API を実行する）
    4. 評価（結果を確認する。テストは通ったか、エラーはあるか）

Geoffrey Huntley はこれを Ralph Loop と呼びます。一つの agent が一つの process で一つのタスクを反復実行する loop です。彼は multi-agent を急いで作らないよう強調しています。複数の非決定的 agent が通信する、つまり非決定的な microservices は、すぐに混乱するからです。

OpenAI の Codex は、この loop に完全な observability system を加えています。agent は runtime logs、metrics、traces を見られるため、コードを書くだけでなく runtime problem を自律的に診断し修復できます。より大きな loop は、コードを書く → deploy → runtime を観察する → 問題を見つける → 修正する → 再 deploy する、となります。

Agentic 化が意味すること

AI application engineering へ移行する backend engineer にとって、影響は二つの側面に現れます。

利用者として：生産性 tool の形が変わる

Codex CLI でコードを書くことは、部下を管理することへ近づきます。目標を伝え、context を与え、境界を決め、成果を review します。AGENTS.md、プロジェクト文書構造、linter 設定、test suite は、単なる best practice ではなく、agent を管理する中核 tool です。

良い文書を書く能力が生産性の bottleneck になります。文書品質が agent の出力品質を直接決めるためです。System design 能力は最も重要な競争力になります。architecture constraint が明確なほど agent は信頼性高く働きます。これは backend engineer の強みです。

構築者として：作るものも Agentic になる

Telegram ReAct agent である hey!stalker は、それ自体が agentic system です。memory management、tool orchestration、context engineering という課題は、agentic 化の中核技術課題そのものです。

より広く見れば、AI Application Engineer や AI Agent Engineer への需要は、本質的に agentic system を構築し運用できる人 への需要です。理論だけでなく、実際に agent を作り、失敗を経験し、harness がなぜ必要かを理解していることが差別化になります。

今後注目すべき方向

Agentic system はまだ初期段階です。次の方向に注目する価値があります。

Agent の評価。 Agent が自律生成したコードの品質をどう評価するか。Anthropic は別の LLM にコードを採点させず、評価 agent が Playwright で生成画面を実際に操作する end-to-end test を使います。生成と評価は分離しなければなりません。agent が自分の仕事を評価すれば、常に肯定的になりがちです。

Multi-agent memory の信頼性。 複数 agent が knowledge base を共有するとき、hallucination や攻撃による汚染をどう防ぐか。blockchain consensus に似た仕組みを提案する研究があります。各 agent に reputation weight を持たせ、提出された memory は加重投票を通過して初めて書き込まれます。

Agent の安全 guardrail。 Claude Code auto mode は一つの方向を示します。独立 classifier が危険操作を遮断し、agent の推論を意図的に見られないため「説得」を防ぎます。入力層の injection detection と出力層の behavior classification を組み合わせる二層防御は、単一層だけを破るより end-to-end attack を難しくします。

Harness の標準化。 AGENTS.md は Linux Foundation 配下の open standard となり、60,000 以上の repository で使われています。文書構造、architecture constraint、observability integration、entropy governance といった harness の中核要素は、各社の試行錯誤から業界共通の実践へ移りつつあります。

一文でまとめる

LLM の agentic 化とは、単にモデルが強くなったことではなく、受動的な回答から自律的な仕事へ利用 paradigm が変わったことです。この変化により prompt と context engineering は必要なままですが十分ではなくなり、harness engineering という新しい discipline が生まれました。エンジニアの中核能力は「コードを書く力」から「agent が信頼性高く働く環境を設計する力」へ移ります。これは system design の経験を持つ backend engineer が得意とする領域です。

参考資料：

  • OpenAI, “Harness Engineering: Leveraging Codex in an Agent-First World”, 2026.02
  • Anthropic, “Claude Code Auto Mode: A Safer Way to Skip Permissions”, 2026.03
  • Anthropic, “Effective Harnesses for Long-Running Agents”, 2025.11
  • Geoffrey Huntley, “Everything is a Ralph Loop”, 2026.01
  • Mitchell Hashimoto, Harness Engineering concept, 2026.02
  • Softmax Data, “From Prompt Engineering to Harness Engineering: The Three Eras”, 2026.03