AI Agent / LLM App Weekly Research
2026年7月第2週は、agentを長時間働く実行主体として扱うために、ハーネス、出力契約、事前ゲート、human approval、rollbackをどう設計するかを整理します。
EDITOR'S NOTE
今週の軸は、agentを「うまく応答するモデル」としてではなく、「権限、状態、検証、承認を持つ実行プログラム」として扱うことです。プロンプト強化だけではなく、契約とゲートをコード側へ移す動きがはっきり出ています。
OpenAIはCodexをChatGPT desktop appへ統合し、diff内編集、PR review、複数repo、desktop/browser/computer useを同じ作業面に置きました。
Vercel Agentは独立identity、read-only default、plan-scoped approval、sandboxを前提にし、agentを本番近くへ置くための設計を示しています。
CloudflareのAI Search例は、agentがknowledge baseへ書く前にhuman approvalを挟み、保存後もrollbackできる構成を示しています。
KEY MATERIALS
CodexがChatGPT desktop appへ統合され、diff内編集、PRレビュー、複数repo、computer useを含む作業面へ広がりました。
coding agentがファイル、Web、PR、ローカルアプリをまたぐほど、task境界と検証条件の明文化が必要になります。
機能採用より先に、allowed_paths、外部送信、承認必須操作、検証コマンドをmanifest化する観点で読むべきです。
agentがユーザー権限を丸ごと継承するのではなく、独立identityを持ち、read-only defaultからplan単位で承認を受けます。
MCP toolやNotion write toolでも、tool公開と呼び出し許可を分ける設計が必要です。
agent identity、approval、sandbox、audit trailを、自作tool serverへどう移植するかを見る。
agentがAI Searchを検索し、新規documentを保存する前にhuman approvalを待ち、誤保存はrollbackできます。
RAG memoryやNotion knowledge storeでは、保存の自動化より保存前の停止と取り消しが重要になります。
検索はread-only、保存はapproval required、保存後はrevert可能というwrite path設計を取り込む。
source boundary、entity routing、answer contract、trace、output hygieneをpromptではなくcode、manifest、schema、validatorへ移します。
金融分析や文章支援で守るべき制約を、prompt文面ではなくテスト可能なcontractとして扱えます。
stock_screening の投資助言表現禁止、根拠必須、ticker一致、内部trace非表示へ直結します。
toolが形式的に正しいcallを受け入れる環境では、agentがsilent wrong stateを作る。read-only pre-execution gateが効果を示します。
Notionや日誌DBへのwriteでは、形式の正しさと業務上の許可は別です。
write tool直前に、対象、状態、依頼scope、domain policyを決定的に確認する。
tool callのscopeは固定policyではなく、ユーザー依頼と対象文脈で決まるため、実行前にcheap judgeで判定します。
update_page という同じtoolでも、週次レポートと本番DBではリスクが異なります。
tool名だけではなく、依頼要約、対象resource、引数、直前traceをgateへ渡す。
繰り返しSOPを実行時code generationではなく、事前検証済みのversioned toolsへコンパイルします。
論文はp50 latency 42%削減、historical alarmsでerror rate最大53%削減を報告しています。
stock_screening のSEC取得、指標計算、スコア集計など、LLMに毎回考えさせないstepを探す。
agent改善の対象をmodelではなく、context構築、tool実行、検証、回復を担うharnessへ置きます。
週次自動化や既存アプリは、実行traceが蓄積するほどharness改善の候補を出せます。
自動進化はまだ保留し、まずtrace schemaと人間承認付きharness diffへ落とす。
452の公開benchmarkを業務活動と金融ドメインへ再整理し、識別力、coverage、recencyで重み付けします。
汎用leaderboardは、財務文書理解、リスク分類、根拠付き説明の能力を十分に反映しません。
stock_screening の評価を、リターンだけでなくLLM分析品質のdomain別fixtureへ分ける。
DEEP DIVE
OpenAIの発表で重要なのは、Codexが単独のcoding agentではなく、ChatGPT desktop appの中で、browser、local files、desktop apps、connected toolsと同じ作業面へ置かれる点です。diff内編集やPR reviewは開発者に直接効きますが、運用上は「どのrepoを触ってよいか」「外部送信してよいか」「どの検証を通すか」を作業単位で持つ必要が増します。
既存ワークスペースでは、Codexの機能採用より先に、タスク境界manifestを整えるのが現実的です。特にこの週次自動化は、Web調査、文書生成、公開、メール、Slackが連続するため、生成と配信の境界を明示する価値が高いです。
Vercel Agentは、agentが本番環境に近づくほど「何ができるか」より「どのplanへ一時的に何を許すか」が重要になることを示しています。独立identity、read-only default、plan-scoped approval、sandbox実行、audit trailは、MCP serverやNotion連携にも移植できる設計原則です。
mcp-notion-server では、検索と読み取りはread-only、ページ作成やDB更新はwrite、アーカイブや削除相当はdestructiveとして分類し、write以上は承認かpre-execution gateを通す設計が必要です。
Cloudflare AI Searchのチュートリアルは、agentがknowledge baseへ書き込むときに、人間承認とrollbackを前提にしています。これは Daily _Writing の個人記憶、週次リサーチのNotion記録、prompt-designer-app のテンプレート保存にそのまま関係します。
保存候補は直接writeするのではなく、source、理由、対象collection、revert actionを持つproposalとして残し、人間が承認・編集・破棄できる形にするのが安全です。
From Prompts to Contracts は、企業分析agentで守るべきsource boundary、entity routing、answer contract、trace、output hygieneをコード側のvalidatorへ移す研究です。これは stock_screening の「投資助言ではなく分析支援として出す」「tickerを取り違えない」「根拠を必ず出す」「内部traceを出さない」という要件に合います。
実験としては、まず llm_report_contract.yaml を作り、過去レポート10件で違反率を測るのが小さいです。
Reason Less, Verify More は、toolがwell-formed callを受け付けるだけでは不十分で、agentがsilent wrong stateを作ると示します。自己反省や強いreasoningに期待するより、write直前にread-only gateで現在状態とpolicyを確認する方が実装しやすい。
Notion DB更新、日誌更新、戦略タグ変更、公開ページ更新は、対象resourceとユーザー依頼のscopeを見て実行前に止める候補です。
Meta-Benchmarks for Financial-Services LLM Evaluation は、汎用leaderboardを金融業務にそのまま使う危うさを扱います。stock_screening では、投資成績KPIに加え、財務文書理解、根拠引用、リスク分類、反証提示、形式遵守のfixtureを持つべきです。
これは投資判断の改善を直接主張するものではなく、分析手順とLLM出力品質のgovernanceを良くするための評価設計です。
TRENDS
APPLICATIONS
LLMレポートcontractを作り、ticker一致、根拠URL、投資助言表現、リスク反証、内部trace漏れを検査します。期待効果は根拠不足と表現違反の削減。検証は過去レポート10件の違反率から始めます。
tool manifestでread/write/destructive、承認要否、対象resource、rollback可否を分類します。期待効果は誤更新と権限過大化の抑制。検証は許可5件、拒否5件のfixtureで行います。
日誌更新や戦略タグ変更の前に、対象取引ID、依頼scope、売買推奨表現の有無を確認するgateを置きます。今週は直接実装せず、Notion gateの後に回します。
文書要約の前処理、見出し正規化、要約対象外除外、出力スタイルcontract検証をvalidated tool候補として棚卸しします。
長期記憶は自動保存せず、保存候補queue、承認、編集、破棄、revert metadataを持つ形へ寄せます。今週は共通patternとして保留します。
調査、生成、公開、配信の境界を task_boundary.yaml にし、外部送信と公開操作を検証対象にします。
DECISIONS
From Prompts to Contracts の設計を stock_screening と trade_discipline に取り込む。prompt-onlyから脱却する。
Vercel Agentのidentity、plan approval、read-only defaultを mcp-notion-server のtool権限設計へ反映する。
Cloudflareのhuman-in-the-loop patternをNotion、RAG、長期記憶のwrite path設計へ採用候補にする。
Tool-Making は有望。まず stock_screening と prompt-designer-app の反復stepを棚卸しする。
TTHEの自動進化はproxy誤りが危険。trace schema整備と人間承認付きharness diffまでに留める。
汎用LLM leaderboardだけで金融分析modelを選ぶ方針は却下。業務能力別fixtureへ分解する。
SMALL EXPERIMENTS
mcp-notion-server のtool manifest草案を作る。各toolに risk_level、read/write/destructive、requires_approval、allowed_targets、revert_possible を付ける。stock_screening のLLMレポートcontract fixtureを10件作る。ticker一致、根拠URL、投資助言表現、リスク反証、内部trace漏れを検査する。task_boundary.yaml テンプレートをこのリポジトリに追加する。allowed_paths、external_actions、approval_required、verification、publish_targets を明示する。REFERENCE