AIエージェントが繰り返す小さな判断をJevに任せることで、処理時間や費用を減らせるのではないか。

画面操作の次の一手、使用するAIの振り分け、AIへ渡す情報の選別を順に試した。情報の選別で回答品質が低下したため、その後は重要情報の保持も検証した。

Codexの画面操作機能で操作候補を取り出し、Jevが次の操作を選び、Codexが実行する構成を試した。

実際のAPIを使った評価は15件中15件成功し、誤操作は0件だった。この範囲では操作の安全性や成功率に問題は見られなかった。

一方、所要時間は通常の画面操作に対して約2倍前後となった。もともと数秒で終わる判断に外部APIへの問い合わせを追加したため、通信と判断の待ち時間が速度上の利点を上回ったと考えられる。

画面操作の高速化には採用しないと判断した。

作業内容を「軽い実行処理」「標準的な推論」「高度な推論」「人間による確認」の4種類へ振り分ける用途を評価した。

| 指標 | Jev | 固定ルールのプログラム | |---|---:|---:| | 人工的に作成した課題の正答数 | 240 / 240件 | 240 / 240件 | | 処理時間 | 中央値 約269ms | マイクロ秒単位 |

同じルールを通常のプログラムで実装した比較対象も全件正答した。今回の課題では品質差がなく、外部の判断モデルを使う利点は確認できなかった。この用途も採用を見送った。

検索やエージェントの実行で集まった参考情報から、必要なものだけをJevで選ぶ方式を試した。ここで大きな削減効果が出た。

| 指標 | 人工データによる初期評価 | 最終回答まで生成した比較評価 | |---|---:|---:| | 参考情報の候補数の削減率 | 約70% | 約81% | | 入力トークンの削減率 | 推計 約65% | 実測 約54.5% | | 必須と指定した情報の保持 | 100% | 欠落0件 | | Jevの処理時間 | — | 約300ms |

トークンは、AIが文章を処理する際の量を表す単位。初期評価の削減率は推計であり、その後に実際の回答生成まで通して入力トークン数を測定した。

ただし、100件の回答比較で5件に重大な品質低下が生じた。必要な事実自体は残っていても、出典や周辺情報とのつながりが落ち、最終回答に必要な関係を保てなかった。

参考情報には、事実、出典、制約、反証、重複情報、指示など、それぞれ異なる役割がある。「必須情報を残せた」という指標だけでは、回答品質を保証できなかった。

入力は大きく減らせたが、この選別方式は採用しないと判断した。

次に、必ず残すべき情報を判定する方式を試した。各候補について、意味の重要性、原文のまま残す必要性、出典、矛盾、指示、後から再取得できるか、情報が古くなっていないかを判定した。

会話や資料を要約・圧縮した際に重要情報が落ちた場合だけ、元の情報を補い直す構成にした。

情報の保持を優先できた一方、判断が不確かな候補をすべて残した結果、評価したケースでは最終的なトークン削減率が0%となった。今回の方式では、品質を守りながら入力を減らす効果は得られず、採用を見送った。

今回試した範囲では、JevをAIエージェントの汎用的な高速化手段として採用する根拠は得られなかった。一方、参考情報の選別には実測で50%以上の入力削減が見られた。ただし品質低下を伴っており、そのまま使える成果ではない。 次の論点は、Jevに任せる判断の範囲をどこまで狭めるかにある。広い文脈をまとめて削る方式より、対象と判定基準を限定した分類や採点が適する可能性はあるが、これは今後の仮説とする。

同じ実験の中で、Gitを介してAI同士が結果を受け渡す運用も試した。

ローカル側のAIが実験結果を非公開のGit保管先に記録し、人間は「Gitを更新した」とだけ伝える。レビューを担当するAIがその記録を直接読み、次の判断を行う。

この運用では、長い実験ログや背景説明を人間がAI間でコピー＆ペーストする作業をほぼ省けた。今回、成立を確認できた協業方法として残す。

出典や制約などの重要な付帯情報は固定ルールで常に保持し、Jevには「重複している」「古くなっている」「後から再取得できる」本文だけを判定させる構成を候補とする。

ほかに、引用・出典の不足確認、範囲を限定した情報抽出、ツールが返した結果の検証も候補になる。いずれも今回の採用判断とは分け、未検証として扱う。

次回は入力の削減率に加え、出典や情報同士の関係が最終回答まで維持されるかを確認する。品質が低下した場合は元の構成へ戻す。

ChatGPTとローカル開発環境を、人間のコピー＆ペーストに依存せず接続できるか検証した。

今回は、指示や結果の要約を運ぶControl Planeと、必要なローカル情報を取得するData Planeを分離した。公開範囲は接続方式と観測結果に限定し、基盤全体の構成は扱わない。

ChatGPT
├─ Control Plane → GitHub → Local Relay → Local Agent
└─ Data Plane    → Secure MCP → Local Gateway → Files / Git

Control Planeは小さなtask、state、result summaryを扱う。Data Planeはファイルをクラウドへ複製せず、必要な箇所だけをローカル環境から検索・部分取得する。

Data Planeの初期toolをsearch_files、read_file、git_statusの3つに限定した。MCPはread-only、deny-winsを基本とし、binary、secret-like content、path traversal、任意commandを拒否する。

一度に全経路を接続せず、Control PlaneとData Planeを分けて確認した。Tunnel credentialは短期かつ最小権限で使用し、検証後に停止した。

Secure MCP Tunnel経由でsearch、partial read、git statusまでの実E2Eが通過した。ローカルファイル本文を事前にクラウドへ配置せず、必要な情報だけを取得できた。

Private repositoryは初回接続時に404となり、接続対象の許可範囲を見直した。Windows側ではCLI導入にも追加作業が発生した。

また、read-only toolがChatGPT側でdestructive、open-worldとして分類された。実装上の権限ではなくMCP tool annotationとの不一致が原因で、readOnlyHint、destructiveHint、openWorldHint、idempotentHintを実態に合わせて修正したところ解消した。

ChatGPTからローカルのFiles / Gitへ到達するData Planeは、限定したread-only範囲で成立した。Control Planeと分離したことで、配送経路と参照経路を個別に切り分けられる状態になった。

これは接続成立の確認であり、ローカル情報全体を安全に公開できることを意味しない。公開範囲、deny rule、取得量は引き続き個別に管理する。

次はResearch Planeを分離し、Local Context、External Research、Local Implementationを独立した経路として扱えるか検証する。

ルール文書の読込が複数箇所へ分散すると、追加のツール呼出とコンテキスト再投入が発生し、トークン消費が増加する。

READMEの軽微なtypo修正を対象に、rule read fan-outだけを分離した隔離条件でBaselineとExperimentalを比較した。

品質と安全性の低下は、この隔離runでは確認されなかった。

rule read fan-outが主要なtoken cost driverである可能性は支持された。ただし観測は隔離環境における1回のみであり、一般的な改善効果とは判断しない。

cache条件やtask categoryによる影響は未確定。結果を他のタスクへ一般化しない。

自然発生する通常タスクを対象にtelemetryを蓄積し、cache条件とtask categoryを分離して再評価する。