終章: ループはこれからどこへ向かうか
ここまで10章をかけて、私たちはひとつのものを解剖してきた。
ターミナルに一行打ち込んだだけで、ファイルが書き換わり、テストが緑になり、要約が返ってくる ── あの「動いている何か」の正体だ。
中身は、驚くほどシンプルだった。 続きを書くだけの LLM、外の世界に触る道具、両者を取り持つハーネス。 この三角形に think → act → observe のリズムを巻きつけ、停止条件と人間介入と文脈管理で味付けする。 それが、Claude Code も Cursor も Devin も Aider も Codex CLI も OpenHands も、共通して持っている 骨格 だった。
しかしこの骨格は、まだ完成していない。 2026 年の今、ループの形は 猛烈な速度で広がっている 最中だ。
最後の章では、その「広がっていく先」を覗いておこう。
11.1 ここまで何を腑に落としてきたか
序章で広げた章マップを、もう一度だけ思い出してほしい。10 章を貫いていたのは、ばらばらの話題ではなく、ループという設計パターンを支える 9 つの骨組み だった。
- 三角形 ── LLM + 道具 + ハーネス (第1・2章)
- 三拍子 ── think → act → observe (第3章)
- 停止条件 ── 自然停止・上限・人間介入の三本柱 (第4章)
- 契約面 ── function calling と JSON Schema (第5章)
- 道具設計 ── description・権限・並列呼び出し (第6章)
- 有限の机 ── コンテキストウィンドウの物理 (第7章)
- メモリ階層 ── CLAUDE.md / AGENTS.md / .cursorrules (第8章)
- 計画と分岐 ── Plan / TodoWrite / サブエージェント (第9章)
- 三大病と HITL ── 早すぎる終了・無限ループ・幻のツール呼び、そして人間という最後のセンサー (第10章)
骨組みはどれも、Claude Code を Cursor に乗り換えても、Devin から Codex CLI に移っても、形を保ったまま現れる。変わるのは、骨組みのどこに重心を置くかという 設計判断の比率 だけだ。
本書を通読し終えたあなたは、来年新しいエージェントが出ても、 「LLM は何が変わったのか」「ハーネスはどう設計されているのか」「道具セットは何か」「停止条件はどこにあるか」 を 自分の頭で問える ようになっているはずだ。
これが「ループの設計学」を腑に落とす、ということだった。
11.2 ループはどこへ広がるのか ── 5つの軸
骨格は固まったが、ループはまだ進化し続けている。 私はその進化を、次の 5つの軸 で眺めるとよいと思っている。
順に見ていく。どれも長くは語らない。「いま流行っている言葉が、骨格のどこに刺さるのか」を地図に置いておくのが目的だ。
11.3 軸① 長時間タスク ── ループが「時間」と戦い始める
本書で扱ったループは、長くても 数十分 のスパンを想定していた。 ところが 2025 年あたりから、数時間から数日 動き続けるエージェントが現実になってきた。
| プロダクト | 走る長さの目安 |
|---|---|
| 旧来の Claude Code / Cursor の単一セッション | 数分〜30分 |
| Claude Code のバックグラウンドエージェント | 数十分〜数時間 |
| Devin / Codex の cloud agent | 数時間〜半日 |
| 自律研究系エージェント（research agents） | 半日〜数日 |
長時間化が起きた瞬間、本書で扱った課題は すべて深刻さを増す。
- コンテキストウィンドウは数十万トークンあっても足りなくなる。外部メモリ と 要約 の設計が一段重くなる
- 早すぎる終了 は「途中で勝手に切り上げた」へ、無限ループ は「気づいたら 1000 回も同じことを試していた」へとスケールする
- HITL は「常に張り付く」モデルから「遠隔の非同期承認」へ。Slack や PR レビューに通知を出す形に変わる
実務メモ長時間タスクのエージェントは、本書の用語でいえば ハーネス側の作り込みが命 だ。LLM の賢さよりも、「いつ報告するか」「どこで止めるか」「コンテキストをいつ畳むか」「権限を一段下げるか」といったループ設計のチューニングが、体感を決める。
ループは、いま「時間軸」というもう一本の次元と戦い始めている。
11.4 軸② マルチモーダル ── 観測がテキスト以外に広がる
本書では「observe（観測）」を、ほとんどテキストとして扱ってきた。 ファイルの中身、コマンドの標準出力、エラーメッセージ ── どれも文字だ。
しかし 2024〜2026 年にかけて、観測の幅が 一気に広がった。
- Computer Use / Browser Use ── ブラウザのスクリーンショットを LLM に見せ、座標をクリックさせる
- Vision tools ── 画像、PDF、設計図、ホワイトボードを直接読む
- 音声・動画 ── 会議の録音、画面録画を取り込む
これは「道具」の話に見えて、実は ループの観測層の話 だ。 think → act → observe の observe が、テキスト一辺倒からマルチモーダル に変わる。
「LLM が世界を見る目」が、テキストから画像・音声・操作画面へと広がりつつある。
観測のチャネルが増えるほど、ループは「ファイルを読む」から「画面を見て手探りする」へと近づく。 人間の作業の 観測の質感 に、エージェントの観測が追いつき始めている。
ただし、これでハルシネーションが消えるわけではない。むしろ「誤った視覚情報を自信たっぷりに信じ込む」という、新しい三大病が現れ始めている（第10章で扱った三大病の マルチモーダル版）。
11.5 軸③ エージェント間プロトコル ── MCP と A2A
本書では、ハーネスから道具へ伸びるパイプを、function calling という一本道で説明した。 そのパイプを 標準化し、誰でも繋げられる規格 にしたものが MCP (Model Context Protocol) だ。
MCP (Model Context Protocol)Anthropic が 2024 年に公開した、エージェントと外部ツール／データソースを繋ぐ オープンな通信規格。 プロダクトごとに「どう道具を渡すか」を別実装していたものを、共通の口 に揃える。 Claude Code、Cursor、Codex CLI、Aider などが続々と対応した。 本書の用語で言えば、「道具のコネクタを標準化したもの」。
MCP の登場で、世界は次のように動き始めた。
- Chrome、Figma、Notion、Slack、freee ── あらゆる SaaS が「MCP サーバー」として自分を公開し始めた
- ユーザーは、自分のエージェントに コードを書かずにツールを足せる ようになった（設定ファイルに 1 行）
- 「どのエージェントを使うか」と「どの道具を繋ぐか」が、ようやく 独立に選べる ようになった
さらに、その先には A2A (Agent to Agent) の話がある。 エージェント同士が互いを呼び合う時代だ。
- 「設計レビューエージェント」が「コード生成エージェント」を呼び、その出力を「セキュリティ検査エージェント」に渡す
- 各エージェントは独立したループを持ち、独立した文脈で動き、結果だけを返す
これは本書の第9章で扱った サブエージェント が、組織を超えて一般化した姿だ。 社内ツールとして閉じていたサブエージェントが、会社の壁を越えて協調する イメージである。
ループは、ひとつの LLM の中で完結する時代から、ループ同士が呼び合う時代へ向かっている。
第9章で見た「親エージェントが子エージェントを呼ぶ」というパターンが、組織と組織の境界を越えていく。 本書の骨格 ── LLM + 道具 + ハーネス ── は、「他のエージェントもまた道具のひとつ」 という見方で、そのまま拡張できる。
11.6 軸④ コーディングを超えるエージェント
本書では、例の大半を コーディングエージェント から引いた。 これは「ファイルとシェルという、観測しやすい世界で生きている」エージェントが、ループの理解にちょうど良かったからだ。
しかし、同じ骨格は コーディングの外にも当たり前のように展開 していく。
| 領域 | やっていること | 道具の例 |
|---|---|---|
| SRE / 運用 | 障害を検知して原因を絞り込み、ランブックを実行する | メトリクス取得、ログ検索、再起動、Slack 通知 |
| リサーチ | 質問を分解し、検索し、PDF を読み、レポートを書く | Web 検索、PDF パース、引用管理、要約 |
| データ分析 | 仮説を立て、SQL を書き、結果を見て次を考える | DB クエリ、可視化、ノートブック実行 |
| 業務オートメーション | チケットを読み、判断し、承認を求め、別システムに転記する | チケット API、社内 DB、メール、決裁ワークフロー |
ここで強調したいのは ── これらすべてが、本書で扱った骨格のまま動く ということだ。 think → act → observe。停止条件と人間介入。コンテキスト管理。サブエージェント。 どれも同じ部品で組み上げられる。業務オートメーションのように「唯一の正解がない」「戻せない操作がある」領域では、第10章の HITL の設計 がそのまま主戦場になる。
11.7 軸⑤ 検証と評価 ── 「良いループ」をどう測るか
最後の軸はもっとも地味で、もっとも難しい。 ループは増えた。プロダクトも増えた。ではあなたは どのループが良いループか、どう判断するのか。
LLM そのものの評価には、MMLU や HumanEval といった既存のベンチマークがある。 だが、本書で扱った「ループの良し悪し」は、それでは測れない。
- 同じモデルでも、ハーネス次第で タスク完了率が倍違う
- 同じプロダクトでも、コンテキストの渡し方次第で コストが 10 倍違う
- 早すぎる終了は「失敗」、無限ループは「成功だが高コスト」── どう一本の指標にするか
このため、2024〜2026 年は エージェント特化の評価フレームワーク が次々と出てきている。
| 評価軸 | 何を見るか |
|---|---|
| タスク完了率 | 与えた仕事を、どれだけ最後までやり切れたか |
| ステップ効率 | 何回のループ／何トークンで達成したか |
| 介入回数 | 人間に何度承認・修正を求めたか |
| 安全性 | 想定外の操作（破壊的コマンド、外部送信）に何回手を出したか |
| 再現性 | 同じ指示で、同じような品質を返せるか |
これらは、本書でいえば 第10章の「早すぎる終了 / 無限ループ / 幻のツール呼び」を定量化 したものに近い。
評価が定量化された分野は、進化が速い。 ループの評価がもう一段成熟したとき、エージェントの世代交代は、いまの LLM のベンチマーク競争に匹敵する 見えるスピード で進み始めるはずだ。
11.8 進化サイクルの非対称 ── 読者の次の一歩
本書を閉じる前に、もうひとつだけ言っておきたいことがある。 それは、LLM とハーネスの 進化の速度差 の話だ。
LLM の進化サイクルは、おおむね 2 年。ハーネスの進化サイクルは、2 ヶ月。
事前学習の世代交代には、巨大な計算資源と数ヶ月から年単位の時間が要る。 それに対してハーネスは、今夜デプロイすれば、明日には全ユーザーの体験が変わる。 本書を書いている間にも、Claude Code・Cursor・Codex CLI の挙動は、ハーネス側のリリースで何度も様変わりした。
この非対称が意味することはひとつだ ── これからの 2 年で読者の体感を作り替えるのは、新しい LLM ではなく、新しいハーネス設計のほうだ。
だとすれば、本書を読み終えた読者が次に学ぶべきは「次の最新モデル」ではない。 新しいハーネスが出てきたとき、それを骨組みに分解して読み解く力 ── これだ。 三角形・三拍子・停止条件・契約面・道具設計・有限の机・メモリ階層・計画と分岐・三大病と HITL。本書で渡した 9 つの骨組みは、来年も再来年も、新しいプロダクトに当てる ものさし として使える。
ニュースで新エージェントの噂を読むたびに、そのものさしを当ててほしい。 「LLM は何が変わった?」「ハーネスのどこに手が入った?」「道具セットは?」「停止条件は?」 この問いを持って読めるようになった瞬間に、本書は役目を終える。
この本を読み終えて
10章の旅を、ここまで一緒に歩んでくれた読者へ。
「コーディングエージェントが何をやっているのか分からない」「Claude Code と Cursor と Devin、何がどう違うのかピンと来ない」── そんな気持ち悪さを、序章の最初に置いた。 いまそのターミナルを見て、もう一度同じ画面を眺めてみてほしい。
● Bash(pnpm test) ⎿ 3 failing
● Read(src/parser.ts)
● Edit(src/parser.ts)
● Bash(pnpm test) ⎿ all green最初に見たときと、もう違って見えるはずだ。
- これは LLM が「ツールを呼ぶ命令」をテキストで返し
- ハーネスがそれを受けて実際に Bash / Read / Edit を実行し
- 結果を続きとして LLM に渡し
- LLM が「もう道具を呼ばない出力」を返した瞬間にループが終わる
その一連の動きが、物語として読める ようになっていれば、本書は仕事をしたと思う。
最後にひとつだけ。 本書を書きながら、私が何度も戻ってきた感覚はこれだ。 「コーディングエージェントが賢くなる」のと、「人間の仕事がなくなる」のは、まったく別の話だ。
賢くなったエージェントは、人間に より上のレイヤーの設計判断 を要求するようになる。 どの道具を渡すか、どんな文脈を作るか、いつ止めるか、誰に評価させるか ── 全部、人間が決めるしかない領域だ。 コードを 1 行ずつ書く役割は減るかもしれないが、ループの骨組みをどう組むか を判断する役割は、消えるどころか中心に来る。
本書がそういう「骨組みを読み解く目」を渡せていたなら、私のやろうとしたことは届いたことになる。 良いループの旅を。
付録 A では本書で扱った主要エージェントを並べて比較し、付録 B では Python で 100 行の最小エージェント を実際に組む。 そして付録 C は、本書に出てきた用語の索引だ。困ったときに帰ってこられる場所として残しておく。