01
公式 · 高 · 自己改善
Building self-improving tax agents with Codex
何が新しいか専門家修正、プロダクトトレース、評価セット、Codexタスクを1つの改善ループとして設計している。
なぜ重要か`stock_screening` の誤り修正や根拠不足を、次回の評価データに変換できる。
読む観点1件の修正をすぐ実装せず、類似失敗を束ねて検証可能な小タスクにする。
EDITOR'S NOTE
今週の読みどころ
エージェント改善の焦点は、モデルを信じることではなく、専門家修正、プロダクトトレース、評価セット、Codexタスクをつなぐ証拠のループへ移っている。
Theme 01
修正を評価へ変える
Tax AI事例は、現場修正を失敗分類とeval targetへ変換してからCodexに渡す実装パターンを示す。
Theme 02
記憶は変化を持つ
EvoArenaは、静的記憶だけでは環境変更に弱いことを示す。ユーザールールはpatch履歴で扱う。
Theme 03
根拠は値単位へ
金融文書やSEC資料では、ページ引用だけでなく値、行、セル単位の根拠確認が品質指標になる。
WHAT TO READ THIS WEEK
今週把握すべき研究・記事・事例
02
論文 · 高 · Memory
EvoArena: Tracking Memory Evolution for Robust LLM Agents
何が新しいか環境変化を含むタスクで、記憶をpatch履歴として管理するEvoMemを提案する。
なぜ重要か`trade_discipline` のルール変更や `Daily _Writing` の課題変化を、古い記憶と混ぜず扱える。
読む観点memory itemに有効期間、上書き元、変更理由を持たせる。
03
論文 · 高 · RAG
Uncertainty-Aware Hybrid Retrieval for Long-Document RAG
何が新しいかdense/sparseと複数粒度を、検索結果分布の信頼度でクエリごとに融合する。
なぜ重要かSEC文書やNotion検索で、断片の精度と親文書の文脈を両立しやすい。
読む観点細粒度ヒットを親チャンクに昇格し、回答に親IDと引用箇所を残す。
04
論文 · 中 · Tool Use
HyperTool: Beyond Step-Wise Tool Calls
何が新しいか決定的な複数ツール処理を1つの外側ツール呼び出しに畳むMCP風インターフェースを示す。
なぜ重要か`mcp-notion-server` のread-only検索や正規化処理で、不要なLLM判断を減らす発想になる。
読む観点write系では監査性が落ちるため、まず副作用のない処理に限定する。
05
論文 · 高 · Codex運用
Toward Instructions-as-Code
何が新しいかinstruction fileは置くだけでは改善せず、構造化された指示ほどagentic PR成功に寄与しやすい。
なぜ重要かCodex自動化の品質は、モデルより指示ファイル、検証手順、禁止事項に左右される。
読む観点指示ファイルを保守・レビュー・テストされる開発資産として扱う。
06
論文 · 高 · Agentic PR
Understanding the Rejection of Fixes Generated by Agentic PRs
何が新しいかAI agent PRの却下理由を分類し、実装不正確、CI失敗、実装不能、低優先度などの失敗を示す。
なぜ重要か今週のCodexタスクを、成功条件と検証方法つきで設計する根拠になる。
読む観点タスクには、方針ヒント、禁止アプローチ、検証コマンドを含める。
07
公式 · 高 · Document AI
LlamaParse Granular Bounding Boxes
何が新しいかline、word、cell単位の座標を返し、明示的にページ上にあるテキストだけに根拠を付ける。
なぜ重要か金融文書では、回答の引用だけでなく、値がどこから来たかをユーザーが検証できる必要がある。
読む観点`stock_screening` の数値主張にpage/span/bbox相当を保存する。
08
公式 · 中 · Codex / Cost
Codex updates, app permissions, and production model routing
何が新しいかCodexはweb search、MCP schema互換、Goal、worktree、inline reviewが進み、Vercelは低コストモデルのproduction投入を示した。
なぜ重要かツールschema、承認、評価セットがないままモデルやツールを増やすと品質が崩れる。
読む観点低コストモデル採用は、評価済みの粗い分類や下書きから始める。
DEEP DIVE
技術トレンドの整理
- 本番修正を評価データに変換する仕組みが、エージェント改善の中心になっている。
- 記憶は静的なRAG indexではなく、変更履歴と有効期間を持つ状態管理に近づいている。
- ツール呼び出しは、細かく見せるだけでなく、決定的処理を畳んで判断点だけをLLMに渡す設計が出てきた。
- instruction file、MCP schema、実行ログ、承認ポリシーは、agentが働く環境のコードとして管理する必要がある。
- 文書AIでは、答えの自然さより、値単位の根拠、引用、座標、再現性が競争軸になっている。
APPLICATIONS
既存ワークフローへの応用
High Priority
stock_screening
主張、数値、source、evidence_span、失敗分類を評価JSONL化する。期待効果は、根拠不足と数値不一致の削減。検証は過去10銘柄、主張20件でsource coverageとunsupported claim rateを見る。
High Priority
trade_discipline
取引ルールや月次方針変更をmemory patchとして保存する。現在有効なルールと過去傾向を分け、ルール適合率と過剰助言率で比較する。
High Priority
mcp-notion-server
ツールをread-only、write、destructive、external-auth、long-runningに分類し、dry-run、承認、ログ、戻り値schemaを棚卸しする。
Medium Priority
prompt-designer-app / Daily _Writing
テンプレートや文章課題をinstruction asset、memory patchとして扱う。まず高優先アプリでschemaを固めてから流用する。
DECISIONS
今回の判断
採用候補
trace-to-eval loop、memory patch、Instructions-as-Code、値単位の根拠保持。
検証候補
UMG-RAG風の粒度融合、read-only HyperTool風ワークフロー、低コストモデルの限定ルーティング。
保留
完全自律の自己改善、HyperTool本格導入、Vercel集計だけを根拠にしたモデル切替。
却下
LLM judge単独ゲート、source evidenceなしの金融分析、抽象的instruction fileだけの品質改善期待。
NEXT TASKS
今週実行する小さな実験
- `stock_screening` の過去レポート1件から、主張20件を `claim, value, source, evidence_span, failure_type, expected_fix` の評価JSONL案に変換する。
- `mcp-notion-server` の全ツールをリスク分類し、dry-run、承認、ログ、戻り値schemaの不足を3件だけ修正候補化する。
- `trade_discipline` にmemory patch schema案を作り、サンプル3件で現在有効な記憶と過去傾向を分けて出力できるか確認する。
REFERENCES