2026-07-06 機械学習勉強会
今週のTOPIC[paper] Why Larger Models Learn More: Effects of Capacity, Interference, and Rare-Task Retention[paper] Autodata: An agentic data scientist to create high quality synthetic data[paper]SPREADSHEETBENCH 2: Evaluating Agents on End-to-End Business Spreadsheet Workflows[paper] Dissecting Post-Training: Uncovering the Complementary Roles of SFT and RL for Document ParsingメインTOPICLoop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your AgentsTL;DRなぜ「今」この概念が登場したのか4層スタック: Prompt → Context → Harness → Loopループの1ターンを構成する5つのmoveと6つの構成要素本論文の核心: Generator/Evaluator分離5つのアンチパターン（moveが1つ欠けると何が起きるか）実運用事例ループが静かに蓄積する4つの隠れたコスト最初のループを作るには（First-Loop Checklist）所感
今週のTOPIC
@Yuya Matsumura
[paper] Why Larger Models Learn More: Effects of Capacity, Interference, and Rare-Task Retention
大きなモデルは創発（ある時点では解けなかったタスクが解けるようになること）性を持つと言われる。そのメカニズムについて調査した論文。
パラメタが大きくなって「表現力」が大きくなることだけが理由ではないという主張。
① 行動レベルの証拠（パフォーマンスの向上）
予測通り、大きなモデルほど出現頻度が非常に低いタスクを学習できることが確認された。また、頻度を同じにしたままタスクが出現する間隔（ギャップ）を空けると、小さいモデルは学習できなった。これは、小さいモデルは「タスク間の忘却」が激しいことを示す。
出現頻度の高いタスクから学習されている様子（左はタスクの頻度、右側はサンプルの注入間隔）
② 表現レベルの証拠（タスク特徴量の獲得）
単にデータを丸暗記したのではなく、モデルの内部表現にタスクを解くための「特徴量」が形成されているかを調べた。
- 比較タスクでは「グローバルなトークンの順序」、加算タスクでは「フーリエモード」という特徴量が重要になります。
- 分析の結果、モデルの規模が大きく、かつタスクの頻度が高いほど、これらのタスク解決に必要な特徴量がモデルの内部表現（特定の層のニューロンなど）により多く形成されていることがわかりました。
③ 勾配レベルの証拠（干渉の減少と記憶の保持）
バッチの勾配（モデルを更新する方向）を分析した結果
- 小さいモデル（例：20M）では、一般的な言語モデリング（頻出タスク）を行う際の勾配と、注入した稀なタスクの勾配が激しく干渉し合っていた。つまり、稀なタスクを少し学習しても、すぐに一般的なテキストの学習によって上書きされていることが確認できた。
- 一方、大きなモデル（例：1B）では、一般的な言語モデリングの勾配と稀なタスクの勾配がほぼ直交（干渉しない状態）しており、稀なタスクの勾配方向が維持されていた。
“丸暗記”はネガティブな文脈で言及されることが多いけど、汎化のためには不可欠なステップのようである。
@Hiromu Nakamura (pon)
[paper] Autodata: An agentic data scientist to create high quality synthetic data
[pon] 良き合成データを求めて
従来の合成データ生成手法が静的なプロンプトやフィルタリングに依存していたのに対し、Autodataはデータサイエンティストの役割をAIエージェントに担わせ、生成、定性的検査、定量的評価、改善というサイクルを繰り返すことでデータの質を向上させる。
A specific implementation: Agentic Self-Instruct
「Agentic Self-Instruct」は、Autodataの枠組みにおける具体的な実装手法であり、AIエージェントが自律的に「高品質な学習データ」を生成・精査するプロセスを指す。
この手法は、単なるプロンプトによる生成ではなく、複数のLLMサブエージェントが連携する「循環型のループ構造」を採用している。このシステムは、メインの指揮官エージェントの下で以下の4つのサブエージェントが役割分担を行う。
Challenger（挑戦者）
- メインエージェントの指示に基づき、学習データ（問題）を生成する。
Weak Solver（弱学習器）
- 作成された問題に対して、基本的に「解くのに苦労する」ことが期待されるモデル。
Strong Solver（強学習器）
- 作成された問題に対して、基本的に「正解できる」ことが期待されるモデル。
Verifier/Judge（判定者）
- 問題やモデルの回答の質を評価し、その結果（知見）をメインエージェントにフィードバックする。
生成プロセスの特徴
- 難易度の最適化: 弱学習器が失敗し、強学習器が成功する（あるいは明確な回答精度の差が出る）問題を「良質なデータ」と定義し、判定結果に基づいてChallengerのプロンプトを逐次修正する。
- 反復的な改善: 一度生成して終わりではなく、判定者からのフィードバックを受けて問題を書き直すループを繰り返すことで、モデルの能力限界を押し上げるような挑戦的なタスクを抽出する。
- 計算リソースの活用: 推論時の計算リソース（inference compute）を積極的に使い、単なるデータ量の増大ではなく、データの「学習価値（Learning Value）」を高めることに特化している。
このアプローチにより、既存のSynthetic Data生成手法では対処が困難だった「難易度が高すぎて学習できない」または「易しすぎて学習効果が薄い」という課題を解消し、モデルの推論能力を効率的に引き上げることが可能となる。
実験
Computer Science (CS) 研究タスク
CS論文をソース資料として用い、CSの研究に関する質問に回答するタスクを検討。
- CSの研究に関する質問はオープンエンドであり、検証可能なタスクとは異なり、ルーブリックに基づく評価が必要となる。
- チャレンジャーは、コンテキスト、質問、参照回答、およびLLMジャッジが参照回答にアクセスすることなく回答をスコアリングするために使用する重み付け基準からなる自己完結型の評価ルーブリックを生成する。
Autodataを用いた「Agentic Self-Instruct」パイプラインは、Kimi-K2.6をメインオーケストレーター兼チャレンジャーとし、Qwen3.5-397Bを強力な「Strong」ソルバー、Qwen3.5-4Bを「Weak」ソルバーとして使用。
このプロセスは、論文の内容に基づき、以下のステップを反復します
- データ生成
- チャレンジャーがコンテキスト、質問、参照回答、および詳細な評価用ルーブリックを生成。
- 評価と分析:
- 質問は複数のソルバーで解かれ、ルーブリックに基づいて評価される。もしモデル間の性能差が不十分な場合、エージェントは失敗パターンを分析し、チャレンジャーのプロンプトを修正して再生成。
品質基準と結果の統計
CSタスクでは、Weakソルバーが正解しやすく、Strongソルバーとの性能差（Gap）が小さいという課題があった。これを解決するため、強いソルバーの平均スコアが、弱いソルバーの平均スコアが 、かつソルバーの試行全体における強いソルバーと弱いソルバーのギャップが パーセントポイントである場合にのみ、候補となる質問を合格とする
結果
表1によると、このループを通すことで、Weakソルバーの平均スコアが大幅に低下し、Gapが拡大していることがわかります 。これはより深い推論を要する難問が生成されていることを示唆している。
最終的にS2ORCコーパス（Lo et al., 2020）から1万件以上のCS論文を処理し、Agentic Self-Instructを用いて2,800件の合格例題を作成した。ループの最後でKimi-K2.6を用いた品質ベリファイア（論文固有の参照情報の漏洩、短いコンテキスト、または不適切な形式のルーブリックを持つ質問を除去する）がこのセットをさらにフィルタリングし、最終的に1,300件の高品質な合格例題を強化学習（RL）訓練用のAgentic Self-Instructデータとして保持した。
Agentic Self-Instruct Loop Analysis
反復的な改善プロセス:
データセット作成において、一つの良質な問題を作成するまでに平均して約6.59回の試行錯誤（ループ）が必要であった。これは、単なる一発のプロンプト生成ではなく、フィードバックを通じた進化的なアプローチが不可欠であることを示している。
失敗パターンの偏り:
生成プロセスにおける失敗の大部分（80%）は、「問題が簡単すぎる」という理由によるものであった。これは、4Bパラメーター程度の弱いモデル（weak solver）であっても正解できてしまい、モデルの学習を促進するほどの「難易度」や「識別能力」を備えていないことを意味する。
識別能力の向上:
ループを経ることで、弱いモデルのスコアは低下（0.677 → 0.458）する一方で、強いモデル（strong solver）のスコアは向上（0.696 → 0.772）した。この「識別能力のギャップ」が拡大したことは、モデルがより深い推論や具体的な技術的詳細を問うような、学習価値の高いデータを生成できている証拠である。
推論の深まり:
最初の生成試行では表面的な要約問題が作られがちであるが、ループによるフィードバックを通じて、論文内の特定のアルゴリズム手順や数値的根拠、設計のトレードオフを問うような、より難易度の高い問題へと最適化された。
RL Training Results
そこで、Qwen3.5-4BをGRPO（Group Relative Policy Optimization）で学習させた結果、Agentic Self-Instructは標準的なCoT Self-Instruct手法を上回る性能を示した。
表の結果（上のパネル）:
- Qwen3.5-4Bモデル（RLなし）と比較して、両方の手法で性能が向上している。
- Agentic Self-Instructを用いた場合、CoT Self-Instructを用いた場合よりも高い性能（mean@3およびbest@3の両方）を示している。
- 特に難易度の高い「Agentic test」においてその差が顕著である。
グラフの動向（下のパネル）:
- Train reward: Agentic手法は学習の初期から高い報酬を示し、CoT手法を上回っている。
- 「Val: CoT Self-Instruct mean@3」および「Val: Agentic Self-Instruct mean@3」の両方において、Agentic手法で学習したモデルが常に上回っている。
Agenticデータで学習したモデルは、CoTデータを用いたベースラインと比較して、持続的に高い報酬を獲得している。この結果は、データセットを増やすだけでなく、「データ生成に推論計算コストを投資すること」が、より強力な推論能力の獲得につながることを証明している。
Legal Reasoning Tasks
タスクの背景と課題
本タスクでは、Pile of Lawデータセットから抽出された court opinions（裁判所意見書）などをソースとして、LLMの法学的推論能力を向上させることを目的としました。ここではCSタスクと反対の 「データが難しすぎて学習が進まない」 という問題に直面した。
初期の課題: 標準的なCoT Self-InstructではWeakソルバーの平均スコアがわずか0.159と低く、GRPOでの学習信号が得られないという「知識の天井」が発生していた。
2. パイプラインの構成（動的なループジャッジ）
CSタスクのような固定閾値ではなく、より柔軟な「Loop Judge」を導入し、データポイントがGRPOに適しているかを判断する仕組みを構築しました。
- 抽出器の役割: 専門のエクストラクターが文書から論点や事実関係を構造化します。
- 動的な判断:
- 本論文のLegal Reasoningにおける「動的な判断」は、以下の3段階から構成される一種の「診断的ループ」を指しています。
- A. 多角的なスコアリング 単なる正解率を見るのではなく、ソルバーの出力を多面的に分析します。
- ロールアウトのパターン分析: Weakソルバーが5回生成した回答が、すべて同じ間違え方をしているのか、それともバラバラなのかを確認します。
- GRPOへの適性: もし5回ともすべてスコアが0点なら、「知識不足」と判断できます。逆にスコアが0から1の間で散らばっていれば、「学習可能な難易度（学習信号がある状態）」と判断します。
- B. エージェントによる「診断」 システム（Loop Judge）が、単なるプログラム的な評価だけでなく、LLMを用いて以下のような定性的な判断を下します。
- 「Weakソルバーはすべての回答で同じ定型文（boilerplate）を繰り返しているため、思考が停滞している」
- 「問題が複雑すぎるのではなく、問われている論点が抽象的すぎる」
- C. 「改善（IMPROVE）」の指示出し Loop Judgeは「不合格」と突き放すのではなく、何を変えるべきかをチャレンジャー（問題作成エージェント）に具体的に指示します。
- 指示例: 「Weakソルバーのロールアウトがすべて定型文になっている。質問をより具体的な『ステップごとの判決適用』を求める形式に修正せよ」
CSとの差
Agentic Self-Instructによる学習の最適化
このループを経たデータは、CSタスクとは逆に、「難易度を適正化し、学習しやすくする」ことで成果を上げました。
ループ導入後、Weakソルバーの平均スコアが0.159から0.283に向上しました。特筆すべきは、Weakソルバーのロールアウト標準偏差が7.93から12.63へ上昇したことで、RLの学習信号がより適切に提供されるようになった点です [6][7]。
強化学習（RL）トレーニングの結果
Agenticデータで学習したQwen3.5-4Bモデルは、PRBenchにおいて圧倒的な性能向上を見せました。
- 表4（PRBenchにおける結果）: AgenticデータでRL学習した4Bモデル（0.441/0.393）は、CoTデータで学習したモデル（0.377/0.343）を上回っただけでなく、学習前のより大規模なモデル（Qwen3.5-397B: 0.404/0.358）の性能をも上回りました [8]。
- 図5（トレーニングの動態）: 学習の全ステップにおいてAgentic法が報酬、検証データともにCoT法をリードし続けており、データの「難易度の調整」が単なる学習データ生成を超えた学習効率化に寄与していることを示しています [9]。
Scientific reasoning
タスクの構成と目的
本セクションでは、Principiaコレクション（MSC2020およびPHYSカタログに基づく数学・物理問題）をベースに、さらに難易度の高い問題を自動生成しました。
- モデル構成: WeakソルバーにQwen3.5-4B、StrongソルバーにQwen3.5-397B-A17Bを使用し、両者の中間領域を突くような難問の生成を目指しました。
- 比較条件: 以下の3つのデータソースを用いて、GRPOによる強化学習（RL）トレーニングを行い比較しました。
- CoT Self-Instruct: 原典であるPrincipiaコレクションをそのまま使用。
- Agentic: Autodataで生成されたデータ。
- Combined: 両者を合わせたデータ（データ量が2倍）。
学習結果と性能向上の特性
結果として、Agenticデータで学習したモデルが、すべての評価軸で最も高い性能向上（+3.20%）を達成した。
- 汎化性能の証明: Agenticデータで学習したモデルは、本人が見慣れていない「CoTデータ分布」に対しても+3.05%の改善を見せた。これは、「Agentic法で生成された高難度問題による推論訓練が、より平易な問題にも汎化する強力な推論スキルを構築した」ことを意味する。
- Principiaベンチマークでの成果: 全体で+1.04%の改善に加え、RealMathで+1.75%という高い成果を出した。これは、データ量が半分であっても、Combined（2倍のデータ）を上回る効率性を示している。
- 本実験の最も特筆すべき点は、「推論トークンの節約」。
- 切り捨て（Truncation）の減少: 65,536トークンの制限下で、ベースモデルは23.75%の確率で回答が途切れていましたが、Agenticデータでの学習後は4.09%まで劇的に低下した。
- 改善の要因分析: モデルが回答を完遂できるようになったこと（Truncation-fixed）が、精度向上の要因の約50%を占めている。
結論
Agentic Self-Instructは、単に「正解率を上げる」だけでなく、「冗長な推論を、限られた計算予算内で完遂できる効率的な推論へと変換する」という、学習プロセスの質的変容を促した。
Meta Optimization of the Data Scientist
「Meta Optimization of the Data Scientist」は、本論文において最も革新的なアプローチの一つであり、「データ科学者（Autodataエージェント）自身のプロンプトや戦略そのものを、同じ評価基準を用いて自動進化させる」という再帰的な最適化手法です。以下にその詳細をまとめます。
メタ最適化の目的
これまでのセクションでは、固定された「Agentic Self-Instruct」のフレームワークを使用してきましたが、本節ではデータ科学者エージェント自体の指示書（プロンプト）や戦略を、進化計算（Evolutionary Optimization）を用いて改善します。
目的は、手動のプロンプトエンジニアリングを排し、自動的にデータ品質を最大化する「研究ループ」を構築することです。
進化最適化アルゴリズムのプロセス
メタ最適化は、コードの差分を「変異」と見なし、世代交代を繰り返すことで行われます。
- 選択: ボルツマン分布を用いて、評価スコアが高い候補を優先的に親として選択します。
- 評価: 親のプロンプトを特定のCS研究論文のバッチでテストし、Weak/Strongソルバーの性能差（分離率）を測定します。
- 分析: LLMエージェントが、失敗した軌跡（なぜデータが分離しなかったか）を読み取り、根因分析（Root-cause analysis）を行います。
- 変異（コード修正）: 分析結果に基づき、コーディングエージェントが現在のプロンプトを改善する「diff（差分）」を生成します。
- 受理と継承: 改良されたプロンプトが検証データセットで親を上回った場合のみ、それを次世代の個体群に追加します。
発見された「自動改善」の知見（進化の成果）
233回の反復を経て、ベースライン（検証合格率62.1%）から最終的（79.6%）へと劇的な性能向上が見られました。この過程で、エージェントは自ら以下の洗練されたルールを発見しました。
- ドメイン特化の強制: 単なる一般的なCS知識ではなく、その論文固有の技術的洞察を問うよう指示。「読まずに答えられるなら質問が簡単すぎる」という自己テストを導入。
- コンテキスト漏洩の防止: ソルバーがコンテキストの単なる言い換えで正解できないよう、解法の説明をコンテキストから排除するルールを強化。
- ルーブリックの正の重み付け: 意外な発見として、負の評価（ペナルティ）よりも、正の評価（加点）の方が推論分離に効果的であることを突き止め、負の重みを排除。
- 構造化されたフォーマット: JSON出力の解析エラーを防ぐために厳格なスキーマを強制するプロンプトへと進化しました。
この実験は、「AIがAIのトレーニング手法を研究・改善する」というサイクルが実用レベルにあることを示しています。手作業でのプロンプト改善では到達し得なかった、細かい制約やエラー回避策がシステムに組み込まれたことで、モデルはより強固なデータ生成が可能になりました 。
結論
Autodataは、推論時計算量（Inference compute）を変換し、より高品質な訓練データへと昇華させる汎用的なアプローチである。単なるデータの増幅ではなく、エージェントによる反復的なデータサイエンスプロセスを通じて、モデルの学習価値を最大化する困難な例題を生成できる。今後は、さらなるタスクへの適応や、人間とAIの共同研究（Co-improvement）への発展が期待される。
トライ
@Kyohei Uto(kuto)
[paper]SPREADSHEETBENCH 2: Evaluating Agents on End-to-End Business Spreadsheet Workflows
@Ryuhei Kawabata
[paper] Dissecting Post-Training: Uncovering the Complementary Roles of SFT and RL for Document Parsing
[monoke]
- ICML2026 採択の論文。OvisOCR のチームが筆者
- PDF → Markdown の変換タスクで, SFT はほぼ効かず RL が効く現象を報告・分析した論文
- SFT memorize, RL generalize の OCR バージョン。大きな驚きは少ないけど堅実な
1. 問題設定
- 入力: 文書画像1枚（PDF をレンダリングしたもの）
- 出力: 構造を保ったテキスト。地の文はプレーンテキスト、表は HTML、数式は LaTeX
- モデル: 画像とテキストを両方扱える MLLM（マルチモーダル大規模言語モデル）。Ovis2.5-2B と Qwen2.5-VL-3B の小型2種で実験
- 評価: OmniDocBench。テキストは編集距離、表は TEDS（木構造の類似度）、数式は CDM（レンダリング画像の一致度）
ポストトレーニング（事前学習済みモデルへの追加学習）には2大方式がある：
- SFT（教師ありファインチューニング）: 正解出力を1トークンずつ真似させる。損失は交差エントロピー
- RL（強化学習）: モデルに出力させ、出力全体への報酬を最大化する。ここでは GRPO（1つの入力に8個の候補を生成し、グループ内の相対的な良し悪しで更新する critic 不要の方式）を使用。報酬は のみ
2. 出発点の謎と、犯人捜しの過程
高品質な合成データ 100k ペア（Markdown を機械生成 → HTML → PDF → 画像化するので正解が完全に正しい）で学習したのに、SFT はベースモデルからほぼ改善せず、RL は編集距離という単純な報酬だけで大幅改善した。
著者らは SFT が効かない原因の仮説を1つずつ潰していく（Figure 2）：
| 仮説 | 検証 | 結果 |
|---|---|---|
| 汎用能力の忘却が原因 | 汎用データ（VQA 等）50k を混ぜる | 効果なし |
| 表・数式の露出不足 | 表・数式特化データ 10k を追加 | 効果なし |
| データ量不足 | 100k → 300k に3倍増 | わずかな改善のみ |
| タスクの定式化が悪い | 出力を Markdown から JSON に変更 | 劇的改善（RL とほぼ同水準） |
JSON 化とは、Markdown 文字列を直接生成させる代わりに「各要素の種類（見出し/段落/表/数式）を分類し、その内容を読み順に書く」構造化オブジェクトを出させること。つまり構造の判断と内容の書き起こしを分離すると SFT は突然機能する。SFT の失敗はデータのせいではなく、学習タスクの設計のせいだった。
副次的な発見として、JSON 出力はトークンが増えるのに推論も速い（OmniDocBench 全体で 25,658 sec → 21,617 sec、15.70% 短縮）。Markdown 直接生成はフォーマット崩壊や繰り返しループで max tokens まで走りがちなのに対し、JSON の型が終了を安定させるため。
3. なぜそうなるか：目的関数の性質（本論文の理論パート）
鍵はエントロピー（予測しにくさ）で文書を2つに分けること。表のタグや 見出し記号のような構造は文書間で共通し予測しやすい（低エントロピー）。セルの中の数値や固有名詞のような内容は前後から予測できず、画像から写し取るしかない（高エントロピー）。
- SFT = forward KL 最小化 = mode-covering。SFT の損失は正解分布 P* からモデル π への KL 距離 の最小化と等価で、正解が起こりうる場所すべてに確率を配る「広く覆う」挙動になる。全文書で共通する構造パターンはすぐ覚える（実際、フォーマット崩壊率は 50.4% → ほぼ 0%）が、多様な内容側は確率が薄く広がってシャープに当てられない。だから SFT は構造学習係。
- RL = reverse KL 最小化 = mode-seeking。KL 正則化つき RL の目的は、報酬が誘導する目標分布 への逆向き KL の最小化と等価。全部を覆う必要はなく、高報酬の一点に確率を集中させる「探して尖る」挙動になる。報酬が最終的な書き起こし精度なら、内容の正確さに直結する。だから RL は内容仕上げ係。
ただし RL にも弱点があり、報酬が内容偏重だと構造指標（複雑な表の TEDS）で SFT-JSON に負けることがあり、壊れやすい JSON 出力に RL を直接かけると不正な JSON が報酬ゼロになって学習が崩壊しうる。
4. 提案手法：互いの弱点を相手の得意分野で埋める
Stage 1: Content-Enriched SFT（内容を足した SFT）。JSON パースを主タスクにしつつ、数式領域→LaTeX 書き起こし、表セル→HTML 抽出という内容集約的な補助タスクを混ぜて共学習する。構造だけに最適化させない。効果は Ovis で総合 71.58 → 82.43、数式 CDM 63.59 → 80.50（Table 1）。
Stage 2: Structure-Aware RL(構造を意識した RL)。報酬を全体編集距離1本から、要素別の分解報酬 （テキスト編集距離 + 表 TEDS/TEDS-S + 数式 CDM、重みは等分）に変更。長い段落の改善ばかりが報われ、短い数式の修正が埋もれる問題を防ぐ。効果は Ovis の CDM 42.69 → 72.20（Table 2）。ただし表・数式データを足さない分解報酬単体では TEDS が 71.3 → 60.97 に下がっており、報酬設計とデータ追加の併用が前提。
統合パイプライン（Stage 1 のモデルを Stage 2 の初期方策にする）の最終結果：
| モデル | 総合 | 数式 CDM | 表 TEDS |
|---|---|---|---|
| Ovis2.5-2B | 56.63 → 82.52 (+25.89) | +21.21 | +32.96 |
| Qwen2.5-VL-3B | 72.44 → 83.20 (+10.76) | +1.38 | +15.41 |
定性例（Appendix Figure 6）が分かりやすい：手書き解答つき試験用紙で、ベースはレイアウトを表と誤認+手書きを空欄化、SFT はレイアウトは直すが手書き解答を空欄のまま出力、SFT-RL は構造を保ったまま手書きの青ペン解答まで書き起こす。
5. 限界
- 実験は合成データのみ。ノイズの多い実スキャン（かすれたレシート等）への転移は未検証。
- モデルは 2B〜3B のみ。KL の議論はサイズ非依存だが、効果の大きさはスケールで変わりうる。
- タスクはパースまで。DocVQA や情報抽出への波及は未評価。
- RL は1プロンプトあたり8候補生成するぶん SFT より計算コストが高い。
- 報酬（編集距離等）はヒューリスティックで、意味的に正しい言い換えを罰しうる。
6. 実務への示唆
- 誤りの種類で処方を分けられる。「表の形が崩れる・JSON が壊れる」系は SFT（それも JSON 形式のタスク設計）の担当。「形は合うが中の数値・文字が違う」系は最終精度報酬の RL の担当。
- SFT が効かないとき、まずデータを増やす前に出力形式を疑う。この論文の最大の実務的教訓。Markdown 直接生成 → 要素分類+内容の JSON に変えるだけで +25.8 ポイント、しかも推論 15.70% 高速化。
- RL の報酬は要素別に分解する。全体編集距離1本だと長文の改善に支配され、数式・小さいセルが放置される
メインTOPIC
Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents
出典: 論文PDF（Google Drive） — Addy Osmaniのブログ発「Orange Book」ガイド（v260615, 2026年6月）をHuaShuが会議論文形式に再構成したworking note
TL;DR
- 2026年6月の同じ1週間に、Peter Steinberger・Boris Cherny（Anthropic）・Addy Osmani（Google Chrome）の3人が独立に同じ概念へ到達し、Osmaniが「Loop Engineering」と命名
- 定義: 「プロンプトを送る人間としての自分自身を置き換え、代わりにそれを行うシステムを設計すること」。実践者はループの「内側」（作業をする人）から「外側」（ループを構築する人）へ移る
- 中心的主張: ループは生成をほぼ無料にし、判断（judgment）だけが希少資源として残る。同じループでも、構築・運用する2人の人間によって正反対の結果を生む
提唱者の補足: Peter SteinbergerはOSSパーソナルエージェント OpenClaw の作者。「コーディングエージェントにプロンプトを打つのではなく、エージェントをプロンプトするループを設計すべき」という投稿は800万viewを超えた。Boris ChernyはAnthropicの Claude Code のリード（生みの親）。Addy Osmaniは『Learning JavaScript Design Patterns』の著者としても知られるChromeチームのエンジニアで、2026年6月7日のブログ記事で本概念を命名・定義した。
なぜ「今」この概念が登場したのか
3つの敷居（threshold）がほぼ同時に越えられたため、と論文は分析する:
- コーディングエージェントが未監督のまま非自明なタスクを完遂できる信頼性に到達した
- 主要ハーネスにスケジューリングのプリミティブ（、Cloud Routines、スケジュールトリガー等）が搭載された
- 1回のエージェント実行コストが、タイマーで繰り返し実行しても無駄にならない水準まで下がった
実践は命名に先行しており、Generator/Evaluator分離のようなパターンは「名前のない状態で」既に広く使われていた。
4層スタック: Prompt → Context → Harness → Loop
「XX Engineering」の各層は互いを置き換えるのではなく、下の層より一段大きい関心事を扱う形で積み上がる。
Loopが従来の3層と質的に異なるのは3つの動詞で表される: Runs on a timer（ボタン押下なしにスケジュールで目覚める）、Spawns helpers（草稿を書くサブエージェントとレビューするサブエージェントを分岐させる）、Feeds itself（ループの出力が次ラウンドの入力になる。この「会話をまたぐ記憶」こそがループたらしめる要素）。
「XX Engineering」系譜の補足: Prompt Engineeringは2023年頃に確立、Context Engineeringは2025年に「プロンプトの書き方からコンテキストウィンドウ全体の設計へ」という文脈で広まった用語（Karpathyらが支持）。Harness Engineeringはエージェントに与えるツール・権限・失敗回復・完了条件の設計を指し、Anthropicのエンジニアリングブログ等で2025〜2026年に体系化された。同著者のOsmaniは「vibe coding」（Karpathyが2025年2月に命名）の流行との類似も指摘しており、「用語は粗く聞こえるが、議論可能な働き方に転換させる」としている。
そして本論文で最も実務的に重要な洞察が、層が上がるほど失敗の影響範囲（blast radius）が拡大するという点。同じ「関数の戻り値の誤読」でも、Promptレベルなら人間がすぐ気づくが、Loopレベルでは誤読が状態ファイルに書き込まれ、翌朝「確立された事実」として何十ターンも積み上がる。
ミスのコストは「発見されるまでに生き延びたターン数」に比例してスケールする。そしてループは、構造上ターン数を最大化する機械である。Loop Engineeringの真の難しさはループを作ることではなく、それを止められるチェックをループの中に置くことにある。
ループの1ターンを構成する5つのmoveと6つの構成要素
1ターンは5つのmoveで構成され、どれか1つを欠いても回らない。特にDiscoveryの質がループ全体の質の天井を決める（無価値な作業を発見すれば、残り4つがどれだけ美しく実行されてもゼロに掛かる）。
moveが「1ターンで何が起きるか」を記述するのに対し、6つの構成要素（parts）は「それが回るために何が必要か」を記述する:
| Part | 内容 | 対応するmove |
|---|---|---|
| Automations | スケジュールやトリガーで動作。名前のついたスキルを呼ぶべきで、指示の羅列を貼ったcronジョブにしない | Scheduling |
| Worktrees | 1リポジトリ内で複数の独立した作業ディレクトリを与えるgit機構。並列性と共に価値がスケール | Handoff |
| Skills | プロジェクト知識を に永続化。「intent debt（意図の負債）」＝毎回プロジェクトを説明し直すコストを解消 | Discovery |
| Connectors | MCPを基盤に外部世界（issue tracker、DB、Slack）へループをつなぐ | Persistence / Discovery |
| Sub-agents | 書く側と判定する側を分離する。1つのエージェントがプレイヤーと審判を兼ねると、審判は身びいきする | Verification |
| Memory | 単一の会話の外に生きる永続状態（markdownファイルやボード）。忘れるのはエージェントであってリポジトリではない | Persistence |
MCP（Model Context Protocol）の補足: Anthropicが2024年11月に公開したオープン標準で、LLMアプリケーションと外部ツール・データソースを接続する共通プロトコル。2025年以降OpenAI・Google等も採用しデファクト化した。git worktree はで同一リポジトリから複数の作業ディレクトリを切り出せる組み込み機能で、複数エージェントの並列実行時の隔離手段として2025年以降エージェント運用の定番になった。
本論文の核心: Generator/Evaluator分離
ループ構築で最も難しいのは「エージェントを走らせること」ではなく「Noと言えるものをループの内側に置くこと」。そして、コードを書いた本人（エージェント）は最も「Noと言いにくい」当事者である。
- Anthropicのエンジニア（Prithvi Rajasekaran）の観察: エージェントに自分の出力を採点させると、品質が平凡でも自信を持って称賛する。これは知能ではなく「自分の宿題を自分で採点する」構造の問題
- コードが書かれた文脈には「そう書かれた理由」が詰まっているため、自己評価は結果ではなく自己説得の連鎖を見てしまう。ループの中ではこの欠陥が毎ターン増幅される
- 解決は、単独エージェントを自己批判的にすることではなく、ゼロからコードを見る・全く異なる指示を持つ独立したEvaluatorを懐疑的にチューニングすること（可能ならモデル自体も変える）
関連研究の補足: LLMの自己評価の脆さは研究でも裏付けがある。LLM-as-a-Judge研究では評価者LLMが自分自身の生成物を優遇する自己選好バイアス（self-preference bias）が報告されており（Panickssery et al., 2024 “LLM Evaluators Recognize and Favor Their Own Generations”）、Huang et al., 2024 “Large Language Models Cannot Self-Correct Reasoning Yet” は外部フィードバックなしの自己修正が機能しにくいことを示した。Self-Refine（Madaan et al., 2023）やReflexion（Shinn et al., 2023）のような自己フィードバック手法の限界を、独立した評価器と実行ベースの検証で補うのが本論文の立場。Generator/Evaluatorの発想自体はGAN（Goodfellow et al., 2014。生成器と識別器を敵対的に訓練する）からの借用と明言されており、銀行業務のmaker-checker原則（送金の入力者と承認者は別人でなければならない）の再発見でもある。
さらに、Evaluatorは「読む」だけでは不十分で「動かす」べきだとする:
Playwright MCPの補足: Microsoftのブラウザ自動化フレームワークPlaywrightをMCPサーバー化したもので、エージェントが実際にページを開く・クリックする・スクリーンショットを撮る・DOMを検査するといったQA操作を行える。これによりEvaluatorの判断根拠が「このJSXは良さそうだ」から「ボタンをクリックした、遷移した、これがスクリーンショットだ」という実行の証拠に変わる。
Claude Codeはこの構造を というプリミティブに落とし込んでいる。ポイントは、各ターン終了後に別の新鮮な小さいモデルが停止条件の成立を判定すること（完了を作業モデル自身に判定させない）:
ループの床（floor）はEvaluatorである。Generatorのレベルはループが何を生み出せるかを決め、Evaluatorのレベルはループが何を生み出さないかを決める。
5つのアンチパターン（moveが1つ欠けると何が起きるか）
5つのmoveのどれか1つをスキップすると、それぞれ固有の壊れ方をする。名前は奇抜だが、それぞれ「何が欠けて」「どんな症状が出るか」に1対1で対応している:
- The Blind Loop（盲目のループ）— Discoveryの欠落: 人間が毎朝「この3つのバグを直して」と仕事を手渡している状態。「実行」は自動化できているが、「何に取り組むかを見つける」が自動化されていない。何に取り組むかの選定こそがしばしば最も高くつく作業なので、見た目ほど時間の節約になっていない。症状は「人間が依然として毎朝、ループにやらせることを決めるのに時間を費やしている」。修正: 発見の手順をスキルとして教え込み、ループ自身に仕事を表面化させる（CI失敗・未解決issue・直近commitを自分で読ませる）
- The Tangled Loop（絡まったループ）— Handoffの欠落: 複数エージェントを並列で走らせるのに、全員に同じ作業ディレクトリを共有させるため、編集が衝突してマージが誰にも解けない絡まりになる。厄介なのは症状が並列実行時にしか現れないこと——単一エージェントで試している間は完全に正常に見え、5体のエージェントが同時に走った最初の朝に初めて発覚する。修正: タスクごとに独立したgit worktree
- The Nodding Loop（うなずくループ）— Verificationの欠落: 最も一般的な失敗。エージェントがコードを書き、同じエージェントが「良し」と宣言する。独立したチェックが無いため毎ターンの出力が自己承認され、もっともらしい間違いが機械速度で積み上がる。「ループがただ自分に頷いている」状態が名前の由来。修正: Generator/Evaluator分離
- The Amnesiac Loop（健忘のループ）— Persistenceの欠落: 良い作業を発見して実行するのに、結果がコンテキストウィンドウの中にしか存在せず、ウィンドウがフラッシュされた瞬間に全部忘れる。翌ターンは同じ作業をもう一度発見し直すか、最悪の場合、前回の試みと衝突する変更を作る。症状は「累積的な進捗がゼロ」——毎朝まったく同じ場所から始まる。修正: ディスク上の状態ファイル（忘れるのはエージェントであって、リポジトリは忘れない）
- The Manual Loop（手動ループ）— Schedulingの欠落: 他の4つのmoveが揃っていても、自動トリガーが無ければそれはループではなく人間が手で走らせるスクリプト。作った日は見事に動くが、人間の注意が逸れた瞬間に静かに止まる。症状は「最後の実行日 = デモした日」。修正: 人間の記憶に依存しない実トリガー（タイマーまたはイベント起動）
- 5つは独立ではなく、1つのmoveを欠くループは他も欠きがち。実務では「規律あるループは5つ全部を備え、拙速なループは目に見える成果を出すDiscoveryとHandoffだけを備え、安全性を生むVerification・Persistence・Schedulingを欠く」形にクラスタ化する
- 「何百ターンも一度もループが自分にNoと言っていない」こと自体が、本物のチェックが存在しないことの統計的証拠
実運用事例
① 個人スケール: Osmaniの朝のトリアージループ
② エンタープライズスケール: Stripeの「Minions」— 週1,300 PR
Zenn- 毎週1,300件以上のPRがマージされ、1行も人間の手で書かれていない。トリガーはSlackの@bot言及か絵文字リアクションという軽いもの
- 信頼性の秘訣はモデルが起動する前にある: 決定論的なオーケストレータが先に文脈を組み立てる（Jiraを引き、Sourcegraph+MCPで関連コードを特定）。ルール化できる部分は一切、確率的モデルに渡さない。どこにこの線を引くかがループの信頼性を決める
- 最も直感に反する点: Minionsはより強いモデルの上に構築されているわけではない。信頼性は制約の質から来るのであってモデルサイズからではない。エージェントの生成ステップと、スキップ不可能なハードコードされたゲート（リンタ実行、git commit）を織り交ぜる
- そして1,300件のPRは依然として人間がレビューしている——人間はループを離れたのではなく、書く側からレビューする側へ机を変えただけ
補足: MinionsはStripeエンジニアのSteve KaliskiがHow I AIポッドキャストで説明した社内システムで、Block（旧Square）製のOSSエージェントフレームワーク Goose のフォーク。サンドボックスはEC2上の使い捨てDevboxで、いわゆる「cattle, not pets」方式（環境を個別に可愛がらず、使い捨ての家畜として扱うクラウド運用の古典的メタファー）により1,000以上のエージェントが同時に動く。なお論文自身が「広く出回っている数字には注意。firsthandソースの方が派手な数字より信頼できる」と釘を刺している。
③ 「眠っている間に動く」は何に依存しているか
ローカルの とデスクトップのスケジュールタスクはマシンの起動が必要で、電源を切るとループも止まる。マシンを切ったまま動かすには Cloud Routines や GitHub Actions のスケジュールトリガーを使う:
| <empty-block/> | Cloud | Desktop | |
|---|---|---|---|
| 実行場所 | クラウド | マシン | マシン |
| マシン起動要否 | 不要 | 必要 | 必要 |
| セッション維持 | 不要 | 不要 | 必要 |
| 最小間隔 | 1時間 | 1分 | 1分 |
| ローカルファイル閲覧 | 不可 | 可 | 可 |
④ スケジューラ選択の実践
ローカルかクラウドかは好みの問題ではなく、ただ一つの問いから機械的に決まる: ループの作業はローカルマシンに紐づいているか、それとも離れられるか？
- ローカルが必須な例: ローカルの開発サーバーを毎分チェックするループ。クラウドは手元のPC上のプロセスを見られないし、最小間隔1時間を下回れない
- クラウドが正解の例: 午前3時にリポジトリのopen issueをスキャンして必要ならPRを開くループ。ノーPCは蓋を閉じられ、電源が切れ、持ち出されるので、この種の仕事をノーPCに縛ってはいけない
- 混同してはいけない: ローカル再実行は「私がここにいる間に追加ラウンドを回す」こと、クラウドスケジューリングは「私がいなくても走る」こと。この2つを混同すると、自律的だと思っていたループがノーPCの蓋を閉じた瞬間に静かに止まっていてがっかりすることになる
- ローカルは「高頻度 + ローカルファイルアクセス」をマシン常時起動と引き換えに買い、クラウドは「真の自律性」を粗い間隔と毎回のクリーンクローンと引き換えに買う。単一のスケジューラで全部は賄えない。成熟したループはしばしば両方使う——きめ細かい内側のチェックはローカル、夜間の一斉スイープはクラウド
出回っている数字への注意（原文の警告）: 「Claude Codeの約90%は自分自身で書かれている」といった主張や大規模マイグレーションの高速化事例の多くは又聞きの要約であり、目安程度に扱うべき。本noteの3事例（Osmaniのトリアージ、StripeのMinions、スケジューリング比較）はfirsthandソースに遡れるものだけを採用しており、その方が一つの派手な数字より信頼できると著者自身が釘を刺している。
⑤ 同じ能力、2つのツールチェーン
本noteのコマンドはClaude Code由来だが、能力自体は特定ツールに固有ではない。Codexも同じ5つの器官を別名で提供しており、一方向けに書かれたコネクタはもう一方に移植してそのまま使えることが多い:
| 能力 (Capability) | Claude Code | Codex |
|---|---|---|
| スケジューリング | worker | Automations tab |
| 条件成立まで実行 (Run until met) | automation rerun + judge | |
| 並列の隔離 | background worktree | |
| サブエージェント | ||
| 外部接続 | MCP + plugins | MCP connector |
| 明示的スキル | ||
| マシンオフでの実行 | Cloud Routines | cloud（計画中） |
教訓: Loop Engineeringは製品ではなく能力の集合（スケジューリング・条件成立まで実行・並列隔離・サブエージェント・外部接続・明示的スキル呼び出し）。問うべきは「どのブランドのコマンドか」ではなく「6つの部品がすべて揃っているか」。なお （条件が満たされるまで走る）と （単に間隔で再実行する）を混同しないこと。
ループが静かに蓄積する4つの隠れたコスト
- Verification debt（検証負債）: 節約された時間が未検証出力という負債に変わり、テストがカバーしない隙間に隠れて、ある朝一度に爆発する
- Comprehension rot（理解の腐敗）: ループが速く出荷するほど、実在するコードと頭の中の地図の乖離が広がる
- Cognitive surrender（認知的降伏）: ループが信頼できるほど、判断を外部委託し「もう気にかけたくない」に至る
- Token blowout（トークン爆発）: ヘルパーの孵化とリトライで、1つのバグが一晩スピンして予想外の請求書を生む
この4つは独立したリスクではなく四つの顔を持つ単一の破綻であり、相互に強化し合う:
防御のための運用規律は3つ:
①代表的なサンプルを毎日読む（説明できない変更は頭の地図が遅れているシグナル）
②出荷前にハードな上限を設ける（1回あたり予算・日次予算・最大リトライ。金の節約ではなく無制限リスクを有限リスクに変えるサーキットブレーカー）
③人間が確認するステップを0にしない (何ヶ月も判断を行使していなかった人間は、コードベースの理解（頭の中の地図）が古びていて、介入したところで「これは間違っている」と言える判断力そのものを失っている)
最初のループを作るには（First-Loop Checklist）
最初のループは「ほとんどシステムに見えないほど小さく」あるべき——タイマーで何かをチェックする小さなものから。
| 要素 | 自問すべきこと |
|---|---|
| Discovery source | 何をタイマーで読むか？（CI / issue / commit / 受信箱） |
| State file | どのディスクファイルがラウンドをまたぐ記憶を保持するか |
| Evaluator | Noと言える独立チェックはあるか |
| Isolation | 並列する各エージェントは自分のworktreeを持つか |
| Token cap | 暴走したら止める支出上限を設定したか |
| Human review | どのステップで人間が確認するために止まるか（全自動マージにしないか） |
構築手順の実例（Claude Codeの場合。各ステップが5つのmoveに対応する）:
Step 1: Scheduling — を走らせる（Claude Code v2.1.72以降）
Step 2: Discovery — CIとissueを読むトリアージスキルを書く（指示の壁をcronに貼るのではなく、名前のついたスキルに永続化する）
Step 3: Persistence — 状態ファイルを追加する（ループの記憶。これがラウンドをまたぐ引き継ぎを可能にし、健忘のループを防ぐ）
Step 4: Verification — Evaluatorを追加する（原文曰く「最も重要かつ最もスキップされやすいステップ」。各ターン後に別の新鮮な小モデルが条件成立を判定する）
Step 5: Handoff — 並列化のためのworktreeを追加する（発見ごとに1つの隔離されたworktree）
- 最初の2つ（Discovery, State file）はループが走れるかを決め、残り4つ（Evaluator, Isolation, Token cap, Human review）は走ったときにトラブルに巻き込まれるかを決める。初心者は最初の2つだけのループを出荷しがちで、それは誰も見ておらず誰も止められない「うなずくだけのループ」になる
- スキルには必ず「Stop」セクション（決してマージしない・削除しない、確信が持てないものは人間の受信箱へ）を書く。これはボイラープレートではなく、エンジニアの意図を恒久的に固定する唯一の場所
Appendix A（完全な注釈付きトリアージスキル）の補足: 原論文の付録には の完全版が掲載されている。6つの見出しのうち5つ（Read/Judge/Isolate/Verify/Persist相当）が5つのmoveに対応し、6つ目の「Stop」セクションがループには推論させない境界——「決してマージしない、決して削除しない、少しでも確信が持てないものは人間へ渡す（受信箱へ、PRへではなく）」——を明示する。本リポジトリのようにエージェントを日常運用しているチームにとって、Stopセクションを持たないスキルは暴走リスクのチェックリスト項目としてそのまま使える指摘。
所感
- Generator/Evaluator分離は、GAN・maker-checker・「作者はレビュアーになれない」という古典的知見のエージェントループへの再適用。「新しい問題は大抵、古い工学的知恵の再適用で解ける」構図はエージェント界隈で繰り返し現れる
- 「層が上がるほどblast radiusが拡大する」は本論文で最も実務的に重要な指摘。ループの怖さは間違うことではなく「間違いの発見までの時間がターン数に応じて伸びる」こと
- 一方で「判断だけが希少資源」という結論はやや楽観的。Evaluator自体の品質を設計・判断する能力や「そもそも何をループ化すべきか」の見極めも希少スキルであり、Evaluatorの懐疑性がモデル更新でドリフトしない保証も論じられていない
- 定量評価のない「フィールドノート」だが、バラバラに実践されていたパターンに共通の語彙と失敗パターン・処方箋を与えた点で参照価値が高い。First-Loop ChecklistとStopセクションの指摘は、自動化エージェントを運用しているチームなら即座に適用できる
スライド全編（29枚）はこちら: