AI Engineer World's Fair 2026 に見る Agent Loop と Evals の潮流

Author:

ttyfky

2026-07-07

はじめに

AI Engineer World's Fair 2026 の参加レポートに続く 2 本目の記事です。

参加レポートでも触れた通り、今回の World's Fair ではトラックの垣根を越えて繰り返し登場したテーマが 2 つありました。エージェントを回し続ける仕組みとしての Loop と、その結果を評価する Evals です。

生成そのものが速く安くなった今、価値の源泉は「どう生成するか」から「どう回し続け、どう評価するか」へ移りつつあります。本記事ではこの 2 つのテーマを、個別のセッションまで踏み込んで整理します。

テーマ: Agent Loop

20 個のターミナルではなく、より良いループを

The future is not 20 terminals. It's better loops.

Loop というテーマを最も象徴していたのが、OpenClaw の作者である Peter Steinberger 氏がキーノートで触れたこの言葉です。

氏は今年の初めまで、10 以上のターミナルを並べてエージェントを監視し、指示を逐次キューイングする働き方をしていたそうです。それが今では、長期タスクを委任する「マネージャー」へと変化したと言います。その過程でボトルネックが GPU → トークン → 人間のアテンションへと順に移っていったという整理が、とても腑に落ちました。エージェントを並列で走らせようとすると、最初は GPU、つまり実行環境がボトルネックになります。環境をスケールさせて解消すると、次はエージェント群が消費するトークンの量とコストがボトルネックになる。それも予算やモデル選択で解消していくと、最後に「買い足せない資源」として、エージェントの出力に目を通し、次の方向を判断するために人が割ける時間と意識、つまりアテンションが残る、という順序です。

エージェントの生成速度が人間の監視速度を超えた時点で、エージェントがコードを生成する様子を眺めること自体が時間の無駄になります。代わりに紹介されていたのは次のような形です。

OSS プロジェクトに Issue が起票される
マネージャーエージェントが、プロジェクトのルール・ノート・ビジョンに照らして対応すべきかを判断する
対応する場合はワーカーエージェントを作り、調査・実装・テスト・別エージェントによるレビューまでを委任する
人間には PR と証跡(動画や実際に動くビルド)が届き、一度レビューしてコメントを残すだけでよい

人間の仕事は方向付けと意思決定に集中し、反復はエージェントが回す。「20 個のターミナル」ではなく「より良いループ」を設計することが次のエンジニアリングのフロンティアだ、という主張です。

現在、特に US 側ではチーム立ち上げ期ということもあり私もハンズオンでプロジェクトに入っているのですが、マネージャーエージェント部分を私自身が担っており、まさに複数のターミナル・worktree を用いて実装やレビューのエージェントに指示を与えている状態です。この私の作業部分を言語化・再現可能にし、より精度の高いループを設計することが、今後の私の課題だと感じました。

ループを設計するとは、何を手放すか

カンファレンス後に、Anthropic から次の記事が公開されていました。

Getting started with loops (Claude Code チーム) では、ループを「停止条件を満たすまで作業サイクルを繰り返すエージェント」と定義したうえで、トリガーと停止条件、使うプリミティブによって 4 つに分類しています。

Turn-based: 人間のプロンプトが起点の通常の対話。エージェントは一区切りごとに結果を返し、続けるかどうかは人間が次のプロンプトで判断する。検証手順をスキルとして書き出しておけば、人間が担っていた確認作業をエージェントに渡せる
Goal-based: 「Lighthouse スコアを 90 以上に、5 回試したら止める」のような検証可能な完了条件と試行上限を渡し、達成するまで自動で反復させる。反復を続けるか止めるかの判断を手放す
Time-based: 一定間隔で同じプロンプトを再実行する。毎朝の Slack 要約のような定期作業や、PR のレビュー対応・CI 修正のような外部システムとのやり取りに向く
Proactive: イベントやスケジュールが起点で、人間はリアルタイムには介在しない。バグレポートのトリアージや依存関係の更新のような、定型化された仕事の流れを丸ごと任せる

この分類が示唆的なのは、段階が進むごとに人間が手放すものが増えていく構造になっていることです。 turn-based では検証を、goal-based では停止条件を、time-based ではトリガーを、そして proactive ではプロンプトそのものをエージェントに渡します。

記事の後半では、ループの品質とトークン消費を保つための指針も具体的に書かれています。完了条件はテストの通過数やスコア閾値のような決定的なものにする、レビューは新しいコンテキストを持った別エージェントに任せてバイアスを避ける、個別の失敗を直すだけで終わらせず、以降の全ての反復が改善されるようにルールへエンコードする、実行間隔は監視対象の変化頻度に合わせる、といった内容で、カンファレンスの各セッションで語られていた潮流が、そのまま実践ガイドの形に落ちてきていると感じました。

規律あるループ: 情報収集から回帰テストへ

では「良いループ」とは何か。複数のセッションで共通して語られていたのが、次のような運用ループです。ここで収集する情報は、エージェントとの対話履歴、生成した成果物、オブザーバビリティにおけるトレースやログ、失敗の痕跡まで広く含みます。

本番でエージェントを走らせ、実行の記録となる情報を収集する
集めた情報を評価(eval)にかけ、問題を発見する
問題をクラスタリングする。単発の失敗はノイズの可能性があるため過剰反応せず、同じパターンの失敗が集まったら強いシグナルとみなす
クラスタから修正を作り、回帰テストやルールに追加する
デプロイして同じループを繰り返す

印象的だったのは、このループ自体の自律化が進んでいることです。あるセッションでは、流れてくる実行記録を常時監視し、問題をクラスタリングして重要度順にランク付けし、修正 PR の作成まで自動で提案する長期稼働エージェントが紹介されていました。
少し前まで人間がこれらの記録を読み、修正を書いていた作業が、「エージェントが実行記録を読み、エージェントが PR を書き、人間が承認する」形へ移り、将来は完全自律に近づいていくという見立てです。

ループの並列化は「数を増やせば勝ち」ではない

一方で、ループの並列化は簡単ではありません。 Cursor が公開している数百エージェント並列の実験 (Scaling long-running autonomous coding) では、最初に試した「全エージェントが同格で、共有ファイルとロックで自己調整する」方式が破綻したと報告されています。ロックの保持しすぎや解放忘れがボトルネックになり、20 エージェントを走らせても実質 2〜3 エージェント分のスループットしか出ず、最終的にはプランナーとワーカーを分離した階層構造に移行したそうです。

必要なのはタスク分割、依存関係管理、所有権、マージ戦略といった、人間の組織設計に近い agent ops です。会場でも "Agents Are Where Microservices Were in 2015. We're Making All the Same Mistakes." と警鐘を鳴らすタイトルのセッションが組まれており、ループの数を増やす前に構造を設計せよ、というのが今年のトーンでした。

テーマ: Evals

生成が速く安くなるほど、検証がボトルネックになる

Evals トラックの前提となる問題意識は明快です。 AI は人間がレビューできる速度を超えてコードや成果物を生成するため、テストと検証が新たなボトルネックになっている、というものです。

これを裏付けるデータとして、2 日目のセッションでは、AI コードレビューの Greptile が自社でレビューした数百万件の PR を分析した結果が紹介されていました。 AI 生成 PR の急増と品質の同等性という数字が気になり、後から調べてみると、同社ブログの Rise of the Overnight Agents に詳細が公開されていました。エンドツーエンドで AI が生成した PR の割合は 2025 年 2 月の 1% 未満から 2026 年 4 月には 27.6% まで増えた一方、差し戻し率・重大バグの発生率・レビュー往復回数は人間の PR と同水準で、差し戻し率が人間より低いエージェントすらあります。興味深いのはエージェント別のエラー傾向で、権限チェック漏れ(IDOR)を人間の 1.75 倍の頻度で混入させるエージェントもあれば、 N+1 クエリを 3.45 倍の頻度で作り込むエージェントもあります。総量として品質が同等でも、失敗の仕方はエージェントごとに癖があります。これはタスクに応じたモデル選択や、モデルの癖を相殺する多層検証の根拠になります。

検証を後工程にしない: 3 つのループに組み込む

エンタープライズ視点で説得力があったのは、Sonar CEO の Tariq Shaukat 氏によるキーノート "In the Land of AI Agents, the Verifiers Are King" です。 LLM は長時間のエージェントタスクをこなせるようになったものの、成功率は 50〜80% に留まり、機能要件を満たしても複雑性・バグ・脆弱性を残し続けます。導入初月に追加コード行数が 3〜5 倍に増えるものの、その増加は 2 ヶ月ほどで消え、蓄積した技術的負債が以降の開発速度を押し下げる、というカーネギーメロン大学の研究も紹介されていました。

処方箋として提示されていたのが、検証を 3 つのループに組み込む設計です。

エージェントの内ループ: 生成の現場に文脈と制約を与え、逐次検証を挿入して問題をその場で修正する
CI ループ: アルゴリズム検証(静的解析・既知パターン)と生成的検証(意図・業務ロジックの意味理解)を組み合わせて PR を審査する
レビュー・メンテナンスループ: 自動修復エージェントで負債を増やす速度で消し続ける

異なるモデルで相互検証してバイアスを相殺する、という多層化の考え方も含め、「ゼロトラスト」をコード検証に適用する整理だと理解しました。実績として AI 由来の本番障害が 44% 減ったという数字も紹介されていました。この枠組みが気になり後から調べてみると、Sonar はこれを Agent Centric Development Cycle (AC/DC) として公開しており、公式ドキュメントに Guide → Verify → Solve の 3 段階として詳細がまとまっています。

「正しさを事前に定義する」から「差分を事後に判断する」へ

テストの書き方そのものを変えるアプローチも印象的でした。 Meticulous CEO の Gabriel Spencer-Harper 氏によるセッション "Why AI Didn't Actually Make You Ship Faster" です。従来のアサーションベースのテストでは、feature flag、ユーザーロール、設定の全組み合わせを事前に定義することは不可能です。

これに対して提示されていたのが差分ベースの網羅的検証です。本番環境の実際のユーザー操作フローを数千〜数万パターン記録し、コード変更のたびに CI 上で再生して、操作の各瞬間のスクリーンショットを変更前後で比較する。開発者は提示された視覚的な差分を見て「意図した変更か、意図しないバグか」を判断するだけでよい、という仕組みです。決定論的に改造したブラウザエンジンと、コード行とユーザーフローの対応インデックスによって成立しており、「正しい挙動を事前に定義する」発想から「変更による差分を事後に判断する」発想への転換と言えます。

検証可能性が信頼をつくる

もう 1 つ、評価というテーマを一段抽象化して捉えていたのが、 Amazon AGI Lab の Antje Barth 氏によるキーノート "Perception Agents" です。エージェントのボトルネックはもはや「ツール操作の能力」ではなく、「検証不能な知的業務における信頼性」にある、という問題提起がこのセッションの出発点でした。クリックや入力、API 呼び出しといった個々の操作はこなせるようになった一方で、複数のシステムをまたぎ、期待値の曖昧な業務を端から端まで安定して完走することはまだできていません。そのうえで、コーディングエージェントが最初に信頼を勝ち取ったのは、コードには「動かしてテストできる」という検証可能性があったからだ、という指摘が続きます。

裏を返すと、ブランド整合性やデザインの質のような「単体テストが存在しない」知的業務では、タスクの成功率が 80% あっても現場は採用しません。5 回に 1 回落ちる仕組みは信用されないからです。このギャップを埋めるために、エージェントが人間と同じ画面(ピクセルと構造)を見て、デザイン仕様やユーザーフローに照らして自分の成果物を監査する、という方向性が提示されていました。

また、運用面では評価を開発時だけで終わらせない議論もありました。従来の SRE 指標(レイテンシ・エラー率)は HTTP 200 を返しながら誤った回答をする生成 AI の健全性を測れないため、コスト・安全性・品質の三層のメトリクスを本番で継続的に監視する。 Evals は開発時のベンチマークから、本番運用の継続的な計測へと範囲を広げています。

2 つのテーマに共通する潮流

Agent Loop と Evals は密接に関わるテーマです。

ループを回すには、各周回の終わりに「今回の出力は良かったのか」を判定する仕組みが要ります。つまり評価はループの構成要素です。また、評価自体もループを活用して、発見した問題は修正・回帰テスト・ルールに変換し、フィードバックのサイクルを増やし情報を蓄積し精度を高めます。

今年のカンファレンス全体を貫いていたのは、「生成が速く安くなるほど、評価とループの設計が価値の源泉になる」という構図でした。エージェントの実行記録を読み、失敗をクラスタリングし、ルールとテストに変換し、次の周回に活かす。この一連の設計と運用が、エージェント時代のエンジニアリングの主流になっているようです。

Belong での実践に向けて

Belong では AI-DLC として、 AI とともに開発するプロセスに仕様・設計のチェックポイントを設け、 AI の推論過程と成果物をセットでリポジトリへ永続化する取り組みを進めてきました。今回のカンファレンスで得た示唆は、この延長線上としてプロセスの向上に活かせそうです。完了条件の検証可能な記述、検証の自動化、失敗のルール化といった論点を、私達のチェックポイント設計に順次織り込んでいく予定です。

「速度向上が数ヶ月で消えるか、複利で効き続けるか」の分水嶺はこうした地道な設計にあるというのが、今回のカンファレンスの一貫したメッセージでした。

まとめ

本記事では AI Engineer World's Fair 2026 から、Agent Loop と Evals という 2 つのテーマを整理しました。

ボトルネックは GPU からトークン、そして人間のアテンションへ移った。監視ではなく委任のためのループ設計が次の領域
良いループは、情報収集 → 評価 → クラスタリング → 修正 → 回帰テスト化という規律を持ち、その自律化が進んでいる
検証は後工程ではなく、エージェントの内ループ・CI・レビューの三箇所に組み込む
評価はベンチマークから、差分ベースの網羅的検証や本番の継続的な計測へと広がっている
Loop と Evals は表裏一体であり、「評価とループの設計」がエージェント時代のエンジニアリングの中核になる

参加レポートで触れた「Building is easier, generating value is still hard」に立ち返るなら、生成の容易さに満足せず、価値の検証までを設計に含めることが、私達に求められている変化だと感じています。次の記事では、この Loop と Evals の上に成り立つ概念として会期中に繰り返し語られた Software Factory を深掘りします。