AIエージェント・LLMアプリ開発リサーチ / 2026-09-26号

手順を残し、改善を測る

手順の状態管理、修正による改悪、評価の再現性。エージェントの途中の判断を測る7つの資料。

対象期間: 2026-09-20 - 2026-09-26 · 復旧作成: 2026-09-27

今週の読みどころ

前号では失敗を記録して回帰テストへ変える設計を扱った。今週は、その記録を使って「次に何をするか」「もう一度生成するか」「改善したと言えるか」を判断する研究を読む。モデルの能力が上がっても、手順の欠落や評価の取り違えはアプリ側に残る。

読む順番は、HEXIS、Return or Revise?、評価の自己監査、検索制御、実運用シミュレーション、PrivDrift、AI SDKリリース。以下の数値は著者報告であり、手元のアプリで再現した結果ではない。論文の公開日はarXiv初回投稿のUTC日付を採用した。9月26日のOSS更新を含むため、土曜8時の実行時点より後の資料も含む復旧版である。

今週把握すべき研究・記事・事例

何が新しいか

手順・ツール仕様から状態、データの依存関係、遷移条件を生成し、開発トレースに合わせて不足を補う。更新の受理には静的検査と過去トレースの再生を用いる。

なぜ重要か

スキルの知識と実行順序を分離し、手順漏れを検査可能にする。

読む観点

導入の入口はコンパイラの全面採用よりも、工程名・入力・出力・完了条件の明文化にある。一次資料

何が新しいか

元回答と修正候補を同じ採点器で比較し、修復と改悪を対として学習する。修正による効果をrecoverabilityとして扱う。

なぜ重要か

「低信頼だから再生成」では、正しかった回答を壊す場合がある。

読む観点

自分のアプリでは「元回答」「修正版」「根拠から新規生成」の比較から始める。これは本誌の実装提案であり、論文が各アプリで実証した結果ではない。一次資料

何が新しいか

8モデルの比較で、293件の中間表現を保存し、再標本化と集計規則の変更によって結論がどこまで維持されるかを確認する。

なぜ重要か

平均点の順位が再標本化や集計方法で変わることを自己監査する。

読む観点

モデルを選ぶ前に、集計ルールを変えても選択が変わらないか確認する。一次資料

何が新しいか

小型モデルの制御役と最終回答役を入れ替え、どちらが改善へ寄与したかを切り分ける。

なぜ重要か

検索・証拠抽出・停止の判断を、回答生成と切り離して評価する。

読む観点

まず検索行動と停止理由を記録する。少量の自前データだけで学習モデル導入の効果を断定しない。一次資料

05実運用研究 · 2026-09-24 · 高

Screen Before You Serve

何が新しいか

単発回答の採点ではなく、会話の進行とツール呼び出しを含む候補構成の選別を、実際のA/Bテストへ接続している。

なぜ重要か

本番の副作用を起こさず、多段階のエージェントを比較する。

読む観点

会話・判断のテストと、API接続・認証・状態更新の統合テストを組み合わせる。一次資料

06論文 · 2026-09-24 · 中/高

PrivDrift

何が新しいか

1,000対話へ疑似機密情報と話題転換を組み込み、抽出プローブへの応答を調べる。

なぜ重要か

話題転換を機密情報の消去と混同しないための評価。

読む観点

実データを使わず、疑似メールアドレスなどで用途外の再出力をテストする。一次資料

07OSSリリース · 2026-09-25〜26 · 監視

Vercel AI SDK releases

何が新しいか

不透明なURI文字列を保持し、明示的にサポートされたMIME型に厳密一致させる。9月26日の@ai-sdk/openai@4.0.78ではreasoningEffortUpdateの対応値検証も更新された。

なぜ重要か

ファイルURI・MIME判定・実行環境・モデル設定の互換性を確認する。

読む観点

利用中の構成に該当する場合だけ、URI・MIME・設定値の固定入力で更新前後を比較する。公式リリース

資料別ディープダイブ

1. HEXIS — スキルの手順を実行状態にする

概要:

スキルを読むたびにモデルが次の操作を推測する構成では、必要な工程が飛ぶことがある。HEXISは知識を各状態の局所指示へ残し、制御フローを拡張有限状態機械として表す。

何が新しいか:

手順・ツール仕様から状態、データの依存関係、遷移条件を生成し、開発トレースに合わせて不足を補う。更新の受理には静的検査と過去トレースの再生を用いる。

主要アイデア:

文章による知識と、完了条件を持つ操作の順番を分ける。中間結果が保存されていれば、何が済み、どこを再開すべきかを判断できる。

背景・文脈:

長い指示書だけでは「本文保存」と「公開完了」を区別しにくい。繰り返す作業ほど、状態を外に持つ価値がある。

前提条件:

スキルと開発トレースに必要な分岐が含まれること。状態機械の外部にある認証やサービス障害まで解決する仕組みではない。

評価方法・根拠:

著者は4ベンチマーク・4実行モデルで、Skill + ReAct比の成功率が平均16.1ポイント改善したと報告する。

限界・未解決点:

未観測の分岐、状態内の推論の誤りは残る。手順を構造化しただけで正しさが保証されるわけではない。

読み手が押さえるべきポイント:

導入の入口はコンパイラの全面採用よりも、工程名・入力・出力・完了条件の明文化にある。一次資料

2. Return or Revise? — 再生成で直る誤りと、増える誤り

概要:

既存回答をそのまま返すか、検索結果で修正するかを選ぶ研究。回答の正しさへの自信と、特定の修正が役立つ可能性は同じではない。

何が新しいか:

元回答と修正候補を同じ採点器で比較し、修復と改悪を対として学習する。修正による効果をrecoverabilityとして扱う。

主要アイデア:

正解を維持したケース、誤答を直したケース、正解を壊したケースを別々に数える。再試行率を増やすだけでは品質改善とは言えない。

背景・文脈:

「もう一度考えて」は安価な改善策に見えるが、費用と改悪を伴う。修正以外の選択肢との比較が必要になる。

前提条件:

元回答と候補回答を同じ基準で採点できること。評価用には両方を生成するため、そのコストが別途かかる。

評価方法・根拠:

25,870問で評価。学習方策にも有害な修正の38〜46%が残る。別に標準RAG回答を用意して選択すると、修正候補を追加する有意な利得は確認されなかった。

限界・未解決点:

短い一般知識QAが中心で、長文・金融分析・文章添削への有効性は未検証。

読み手が押さえるべきポイント:

自分のアプリでは「元回答」「修正版」「根拠から新規生成」の比較から始める。これは本誌の実装提案であり、論文が各アプリで実証した結果ではない。一次資料

3. 評価の自己監査 — 一位を決める前に、順位の安定性を見る

概要:

LLMによるプロンプト構造推定を題材に、評価そのものの再現性を監査する。再現性は同じ構造を再び返すこと、正確性は正しい構造を返すことであり、別の性質である。

何が新しいか:

8モデルの比較で、293件の中間表現を保存し、再標本化と集計規則の変更によって結論がどこまで維持されるかを確認する。

主要アイデア:

ランキングと同時に順位安定性、各実行の出典、集計規則、測定日を保存する。再実行の回数を増やしたという事実だけで信頼性を説明しない。

背景・文脈:

小さな評価セットは素早い実験に有用だが、上位の僅差を強く解釈しやすい。

前提条件:

平均値だけでなく個別出力と採点が残っていること。

評価方法・根拠:

上位2モデルが順位を維持したのは再標本化の各68%。反復キャンペーンの統合規則を変えると、全体の代表値が7ポイント動いた。

限界・未解決点:

プロンプト構造推定の小規模研究であり、あらゆるタスクの順位が同程度に不安定という主張ではない。

読み手が押さえるべきポイント:

モデルを選ぶ前に、集計ルールを変えても選択が変わらないか確認する。一次資料

4. The Fellowship of the Query — 検索の「次の一手」を学ぶ

概要:

検索拡張QAの分解、検索、言い換え、証拠抽出、統合、進捗確認、停止を、7種類の行動予測として学習する。

何が新しいか:

小型モデルの制御役と最終回答役を入れ替え、どちらが改善へ寄与したかを切り分ける。

主要アイデア:

良い検索手順と良い回答を別の指標で評価する。証拠の記録が増えても、最終回答の正解率が上がるとは限らない。

背景・文脈:

RAGの改善を検索件数や回答点だけで見ると、停止判断の誤りや不要な検索が隠れる。

前提条件:

教師の検索軌跡と行動ラベルを用意できること。学習用の軌跡には採択による選別がある。

評価方法・根拠:

1,646行動の評価でGranite 4.1 3Bのmacro-F1は0.6536。149軌跡の評価では、制御・生成の両方を学習済みにした構成が改善した一方、制御だけを替えた最終回答の利得は統計的に明確でない。

限界・未解決点:

限定されたパイプラインの結果であり、未選別の質問への一般化は未解決。

読み手が押さえるべきポイント:

まず検索行動と停止理由を記録する。少量の自前データだけで学習モデル導入の効果を断定しない。一次資料

5. Screen Before You Serve — 本番前の仮説検証としてのシミュレーション

概要:

Nubankの顧客対応エージェントで、仮想顧客と模擬ツール応答を使い、複数段階の会話を本番投入前に比較した実運用研究。

何が新しいか:

単発回答の採点ではなく、会話の進行とツール呼び出しを含む候補構成の選別を、実際のA/Bテストへ接続している。

主要アイデア:

本番スキーマに合わせた模擬応答を使い、失敗仮説ごとにシナリオを作る。シミュレータでの良い点数を、そのまま本番の成功と見なさない。

背景・文脈:

実利用者を失敗にさらす前に、候補を絞れる仕組みが必要になる。

前提条件:

ツールのスキーマと模擬状態が、本番の仕様に追随していること。

評価方法・根拠:

4本番版でシミュレーションと本番採点の相関を報告。16,000超の模擬会話による選別後、別の本番A/Bテストで自己解決率が8.82ポイント改善し、tNPSの有意な変化はなかった。

限界・未解決点:

副作用を持つツールを模擬するため、バックエンドの状態更新・遅延・副作用そのものは未検証。

読み手が押さえるべきポイント:

会話・判断のテストと、API接続・認証・状態更新の統合テストを組み合わせる。一次資料

6. PrivDrift — 話題が変わっても機密情報は残る

概要:

会話内で開示された機密情報が、別の話題を挟んだ後の問いかけで漏れるかを監査するベンチマーク。

何が新しいか:

1,000対話へ疑似機密情報と話題転換を組み込み、抽出プローブへの応答を調べる。

主要アイデア:

「今は別の話をしている」ことを機密情報の削除と扱わない。コンテキストに含める必要のない情報を最初から渡さない設計が重要になる。

背景・文脈:

長いセッションには用途の異なる情報が同居しやすい。記憶を増やすほど、利用範囲の制御が必要になる。

前提条件:

ここで扱うのは同一のアクティブ会話内の情報であり、学習データの記憶や別セッションへの永続化ではない。

評価方法・根拠:

3モデルの対話単位の漏洩率は38.7〜54.6%。測定範囲では、話題転換を増やしても一貫した漏洩低下は見られなかった。

限界・未解決点:

話題転換は最大6段階で、固定形式の疑似機密が中心。実際の個人情報や長期記憶全体へそのまま一般化できない。

読み手が押さえるべきポイント:

実データを使わず、疑似メールアドレスなどで用途外の再出力をテストする。一次資料

7. Vercel AI SDK — 小さな変更にも入出力の境界がある

概要:

9月25日のai@7.0.116はES2022向けコンパイルと、プロンプト変換時のファイルURI保持・MIME判定に関する修正を含む。

何が新しいか:

不透明なURI文字列を保持し、明示的にサポートされたMIME型に厳密一致させる。9月26日の@ai-sdk/openai@4.0.78ではreasoningEffortUpdateの対応値検証も更新された。

主要アイデア:

モデルの文章生成だけでなく、入力変換とプロバイダ設定の互換性がアプリ品質を左右する。

背景・文脈:

文書要約やファイル入力では、文字列がわずかに変わるだけでも取得や処理が失敗する。

前提条件:

各アプリが実際に使用するバージョンとランタイムを確認すること。本調査では依存関係の更新を実施していない。

評価方法・根拠:

根拠は公式リリースノートであり、独立ベンチマークではない。

限界・未解決点:

最新化による自分のアプリへの効果は未測定。7系への一括移行を勧めるものではない。

読み手が押さえるべきポイント:

利用中の構成に該当する場合だけ、URI・MIME・設定値の固定入力で更新前後を比較する。公式リリース

技術トレンドの整理

今週の資料を横断すると、エージェントを評価する単位が最終回答から、途中の選択と状態へ広がっている。HEXISは操作順序、検索行動学習は次の一手、Return or Revise?は修正を選ぶ判断に焦点を当てる。本誌としては、これらを一つの巨大な自律システムへ統合する前に、各アプリの失敗を「どの段階の判断か」に分類する方が実用的だと考える。

評価の自己監査と本番前シミュレーションは補完的である。前者は評価から言えることの強さを吟味し、後者は本番へ進む候補を絞る。どちらも、認証・通信・永続化まで成功したことを保証するものではない。期待効果と実測効果を別欄に残し、失敗した試行も集計対象にする。

既存ワークフローへの応用可能性

以下は本誌の適用提案であり、各論文がこれらのアプリで検証した成果ではない。工数は初回試作の目安。

stock_screening

関連する資料: HEXIS、検索行動学習、評価の自己監査。

適用案: 調査対象日、根拠取得、分析保存、レポート生成を別状態として記録する。分析を採点するときは、正解性・引用整合性と株価の事後リターンを混同しない。

期待効果: 欠損工程の発見と、途中からの再開。実装コスト: 小〜中、半日程度。検証方法: 保存済みの匿名化入力3件で、中断後の再開と重複出力を確認する。優先度: 高。次のCodexタスク: 実運用に触れない状態記録の試作。

trade_discipline

関連する資料: Return or Revise?、評価の自己監査。

適用案: 元の助言と修正版を、ルールの一貫性・根拠・不必要な断定の増加で比較する。

期待効果: 見た目が丁寧になっただけの改悪を検出する。実装コスト: 小、2〜4時間。検証方法: 過去の匿名化例10件を固定基準で手動採点する。優先度: 中。次のCodexタスク: 比較用の記録書式だけを作る。投資判断の自動化には使わない。

prompt-designer-app

関連する資料: Return or Revise?、AI SDK。

適用案: 要約の元版・修正版・根拠からの新規版を保存し、事実の追加・削除と手修正回数を比較する。ファイル入力を扱う場合はURIとMIMEの固定テストを加える。

期待効果: 修正の採用率と事実整合性を両立する。実装コスト: 小〜中、半日。検証方法: 同じ文書5件で比較し、原文にない主張が増えていないか確認する。優先度: 高。次のCodexタスク: オフライン比較表を作る。

Daily _Writing

関連する資料: PrivDrift、Return or Revise?。

適用案: 添削に不要な個人情報を入力から外し、過去の文章を再表示する範囲を明示する。添削を受けた文章の採用・再編集を記録する。

期待効果: 用途外の再出力の検出と、役立つ添削の識別。実装コスト: 小、2〜4時間。検証方法: 疑似情報を含む対話5件で話題転換後の出力を確認する。優先度: 中。次のCodexタスク: 疑似対話の作成。継続率改善は実測後に判断する。

mcp-notion-server

関連する資料: HEXIS、Screen Before You Serve。

適用案: 本番と同じスキーマの模擬ツールで、検索・対象選択・更新内容確認・書き込み結果照合を評価する。

期待効果: 書き込み対象の誤選択と工程漏れを公開前に検出する。実装コスト: 中、半日〜1日。検証方法: 存在しないページ、重複要求、途中失敗の3ケースを再生する。優先度: 高。次のCodexタスク: 実書き込みなしの模擬応答セットを作る。

今回の判断

今週実行する小さな実験

  1. stock_screeningの保存済み入力3件で「取得済み/分析済み/出力済み」の状態記録を試す。中断後に完了工程を再実行せず再開できるかを確認する。
  2. prompt-designer-appの文書5件で、元版・修正版・新規版の事実整合性を比較する。改善と改悪を別々に数え、実行時刻・モデル・個別結果を保存する。
  3. mcp-notion-serverの模擬ツールに存在しない対象・重複要求・途中失敗を与える。誤更新ゼロと未完了の明示を合格条件にする。

採用・保留・却下ログ

資料 判断 理由 次アクション
HEXIS 考え方を採用候補 状態と完了条件を小さく導入できる 工程記録の試作
Return or Revise? 検証候補 修正に伴う改悪を測定できる 三方式の比較
評価の自己監査 採用候補 個別結果の保存から始められる 集計規則と測定日を固定
検索行動学習 ログを採用候補、学習は保留 自前の軌跡データが不足 停止理由を記録
Screen Before You Serve 検証候補 本番更新なしで判断を比較できる スキーマ準拠の模擬応答
PrivDrift 検証候補 用途外の再出力を疑似情報で調べられる 会話テストを別途設計
AI SDK 監視 利用バージョン次第で関連度が変わる 依存と入力境界の確認