外部調査にGrokBotを使い、追加の調査費用を抑えながら情報を集められるか。その結果をローカルの連携基盤と非公開のGitHub Issueを介して、後続の検証担当へ渡せるか。9月19日から25日にかけて、設計だけだった経路を実際に通して確かめた。

今回は「情報が届いたこと」と「情報が正しいこと」を分けて扱う。調査担当が集めた内容は未検証のまま渡し、次の担当が一次情報と照合する。

GrokBotが情報収集を担い、検証を別の担当へ渡すことで、調査のたびに高い費用のかかるAIへ長い検索結果を読ませずに済むかを試した。実行記録にはウェブ検索9回、発見事項9件、根拠資料21件が残った。収集して引き渡す経路は通った。

一方、この記録だけでは実際の利用料金、ほかの方法と比べた総費用、失敗時の再試行費用は判断できない。「無料で収集できた」「従来より安くなった」とはまだ結論づけない。300秒で時間切れとなる例もあり、使い続ける費用を考えるには、成功率と再試行回数も測る必要がある。

ローカルの実装担当に読み取り専用の作業を渡す試験では、作業番号、追跡番号、実行上の制約、結果のコメントをIssueで往復できた。次に、外部調査を担当するAIから連携基盤を通じ、調査結果を後続の検証担当へ渡す試験も完了した。

後者の実行記録では、発見事項9件、根拠資料21件、ウェブ検索9回が記録され、結果の形式確認も通過した。調査結果は「未検証」と明示して引き継いだ。件数や形式の合格は、発見事項の正しさを証明するものではない。

優先度の高い根拠11件を公式の一次情報で再確認し、9件を後続の資料へ反映したとの作業報告もある。関連するデータ確認17件、統合確認10件、自動テスト22件は通過したとの報告。ただし今回の週次確認では、ローカルの元記録へ再接続できず、この反映部分を独立には再検証できていない。

前回から続けていたJevによる文脈保持の試験は、安全上の条件に従って途中で停止した。120件を予定したうち2件の段階で止め、入力トークンの削減は0%。本番の連携も無効のままとし、現方式は採用しないと決めた。

削減効果が出ないまま採用へ進めず、停止条件を実行できたことも今回の確認結果に含める。

長時間の調査が300秒で時間切れになった場合、途中までの結果を確実に保存できるかは未確認。互いに矛盾する根拠を保持して検証担当まで届ける自動の経路も、まだ実証できていない。複雑な矛盾の判断は現時点ではAIまたは人間へ引き継ぐ。

また、完了済みのIssueがGitHub上では開いたままになっている。本文で完了と分かっていても、監視処理が再取得して二重実行しないかを、複数の監視担当や再起動を含めて確かめる必要がある。

今週の証跡はIssueとローカル試験が中心で、プルリクエストや自動実行の実績はない。週次確認時にはローカルの読み取り口へ接続できなかったため、GitHubに残る要約とローカルの原本を突き合わせる作業も残った。

まず強制的な時間切れでも途中結果を保存し、矛盾する根拠を消さずに引き渡し、再試行で二重に実行されないことを確認する。次に、完了済みのIssueを複数の監視担当や再起動後も再び取得しないかを試す。

原本に接続できない日でも、結果の形式、件数、内容の照合値、テストの要約だけは確認できるよう、秘密やローカルの実際の保存先を含まない短い証跡を残す方法も検討する。

次の調査では、検索回数に加えて実行時間、失敗・再試行回数、実際の利用料金を同じ単位で記録し、既存の調査方法と比べる。

今週の判断は「調査から検証担当への受け渡しは通った。低コストで運用できるか、時間切れ・矛盾・二重実行に耐えられるかは未確定」。経路を使い続ける条件は、次の計測と異常系試験で決める。

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を分離して再評価する。