エージェントに仕事を任せる場面が増えるほど、「結果が合っているか」より「途中のどこを信じてよいか」が気になってきます。この記事は、最近まとめたノートの中から、エージェントの振る舞いを検証したり、人間との分担を考え直したりするのに役立った 7 本を選んで紹介するものです。論文の実装、学習ライブラリ、プログラミング言語、40 年以上前の古典、ソフトウェア見積もりの手法まで、方向はばらばらですが、根っこにある問いは同じだと思っています。
各項目の最後に、もう少し詳しく書いた元ノート（日本語ページ）へのリンクを置いています。
1. Agent Workflow Memory：うまくいった手順を「型」として覚えさせる
AWM（Agent Workflow Memory）は、エージェントが過去のタスクから共通のサブルーチンを抜き出し、具体的な値を落とした「ワークフロー」として記憶しておく手法です。ラベル付きの例があればそこから事前に抽出するオフライン設定、何もなければ自分の経験からその場で作っていくオンライン設定の二通りがあり、WebArena では成功率 35.6% が報告されています。毎回ゼロから考えさせるのではなく、再利用できる手順を明示的に持たせるという発想は、エージェントの動きを人間があとから追いやすくする意味でも筋がいいと感じました。
2. TRL の PRM Trainer：最終答えではなく各ステップに点をつける
PRM（Process Reward Model）は、推論の最終結果だけでなく途中の一歩一歩が正しいかを判定する報酬モデルです。Hugging Face の TRL には実験的 API として PRMTrainer が入っていて、prompt・completions・labels の 3 列からなるステップ単位のデータで学習できます。元になった GSM8K の研究では、答えが合っている解の中に紛れ込んだ推論ミスが 14.0% から 3.4% に減ったとされており、「正解したから中身も正しい」とは限らないことが数字で見えるのが印象的です。Qwen2-0.5B と Math Shepherd を使った最小構成の例もあるので、手元で試す入口としてちょうどいい分量です。
→ PRMTrainer のデータ形式と主要パラメータのまとめ
3. Bend：AI が書くコードを「証明」で縛る言語
Bend は、C に近い速度、GPU まで使う並列実行、Lean のような証明、Python 風の文法を一つにまとめようとしている言語です。個人的に一番おもしろかったのは LAWS.bend という考え方で、守るべき性質を法則として書いておくと、それを壊す変更は型検査（＝証明検査）を通らず、AI はやり直しを強いられます。ノートでは「証明付きの AGENTS.md」と表現されていて、自然言語で「バグを入れないで」と頼むよりずっと強い約束になります。中規模のコードベースでも検査が 1 秒程度で終わるとされているので、エージェントが変更のたびに回せる点も実用的です。まだ発展途上で、得意なのはバックエンド、動作環境は Linux と macOS が中心とのことです。
4. 「自動化の皮肉」：古典論文がいま刺さる理由
Lisanne Bainbridge の論文『Ironies of Automation』は 1983 年のものですが、エージェントの話をしているとしょっちゅう思い出します。自動化を進めるほど人間は普段手を動かさなくなって腕が落ちるのに、いざ機械が失敗したときに素早く引き継ぐ役目だけは人間に残る、という矛盾がその中心です。警報を増やすと緊急時にかえって混乱する、機械の判断が正しいかをリアルタイムで見抜くのは難しいのに責任は人間が負う、といった指摘も、そのまま今のコーディングエージェントのレビューに当てはまります。対策として挙がっている「止める・観察する・理解する・直す・再開する」の順序や、定期的な手動操作による訓練も、運用ルールを考えるときの素直なチェックリストになります。
5. Evidence-Based Scheduling：見積もりを「確率分布」として出す
EBS は Joel Spolsky が広めたスケジューリング手法で、タスクを 16 時間以内の粒度に分け、見積もりと実績の比（velocity）を記録し、それを使ったモンテカルロ・シミュレーションで納期の確率分布を描きます。単一の日付ではなく「50% ならこの日、95% ならこの日」と言えるのが肝で、会議や割り込みで失われる時間も過去の velocity に自然と吸収される、という割り切りがうまいところです。エージェントとは直接関係ないように見えますが、「申告ではなく実績のデータで信頼度を測る」という考え方は、エージェントの成功率や作業時間を評価するときにもそのまま使えます。
6. alphaXiv：論文を「誰が、何を根拠に」読んでいるかで探す
alphaXiv は、論文と研究者と所属機関をつなぎ、元の研究に基づいて質問に答えてくれる論文プラットフォームです。読むべき論文の見当をつける、そのテーマを誰が追っているかを知る、根拠つきで文献レビューを進める、といった使い方を想定していて、MCP サーバーやブラウザ拡張も用意されています。ノートには 2026 年 9 月末から 10 月初めの注目論文がまとめてあり、自分の誤りから立て直す方法をエージェントに学ばせる PivotOPD や、コーディングエージェントのチームが本当に協調していたかを実行記録で検証できる OpenCollab など、このテーマに近いものも並んでいます。
7. Conare：モデルに渡す「文脈」を一つの API で引いてくる
Conare は AI アプリ向けのコンテキスト基盤で、プロダクトのデータ、ユーザーの履歴、過去の意思決定をつないで、モデルやエージェントが必要な文脈を一つの API で取り出せるようにするサービスです。例として、Gmail・Slack・Notion・Linear にまたがる情報を引用し、三つの出典を根拠にした回答を返す流れが紹介されています。ノート自体は短めですが、エージェントの答えを信用できるかどうかは結局「何を見て答えたか」を示せるかにかかっている、という点で、ほかの 6 本とつながる一本です。
7 本を並べてみると、エージェントを信頼するための手がかりは「途中を見える化する」ことに集約される気がします。手順を記憶として残す AWM、ステップごとに採点する PRM、性質を証明で固定する Bend、実績から分布を出す EBS、出典を返す Conare。どれも、最終的な結果だけを見て判断しないための工夫です。そして Bainbridge が 40 年前に書いたとおり、その仕組みを見張る人間の腕を落とさない工夫も、同じくらい大事なのだと思います。