ブラウザーのChatGPTで固めた指示を、作業中のVS CodeのCodex会話へ、本文をコピー＆ペーストせずに渡せるか検証しました。架空の短い本文では、PC内への保存、VS Codeでの添付、人間の送信操作を経たCodexでの読取まで成功しました。対象会話と内容の確認、依頼文の入力、送信は人間に残す構成です。

別経路として試したDotでは、Dot自身が作成したタスクの継続は成功しました。一方、人間が作成した既存VS Code会話はAPI読取でエラーとなり、その会話への受渡しは成立を確認できませんでした。

この記事では、保存・添付・送信をどう分けたか、接続ができても受渡し成功とは判断できなかった場面を説明します。環境構築を一から再現する導入マニュアルではなく、同様の連携を検証する際の成功条件を整理した記事です。

この記事に登場するもの

名称	今回の検証での役割
ChatGPT Work	ブラウザーで設計や修正方針を相談する側。本文ではWorkと略記する
Codex	VS Code上で調査・実装を依頼する側。受渡し先は作業中の既存会話
ローカルMCP	PC内で動かす自作サーバー。Workから受け取った指示本文を保存する
Secure MCP Tunnel	今回、WorkからローカルMCPへ接続するために使ったトンネル
Reporter	自作のVS Code拡張機能。保存ファイルを検証・コピーし、Codex入力欄へ添付する
Dot	今回、PC接続と調査タスクの作成・継続を試したAI機能。既存会話への別の受渡し経路として検証した

WorkとDotの名称は、検証時に利用した画面・機能に合わせています。以下の製品挙動は、この検証環境で確認した範囲です。

減らしたい操作と、残す操作

対象はWindows上のVS CodeとCodex、ブラウザー側のWorkです。Workで方針を整理し、人間が内容を確認してから、Codexへ実装や調査を依頼する役割分担を使っています。

減らしたいのは、長い指示本文を選択してコピーし、別の画面へ貼り付ける操作です。実装先の会話を選び、内容を確認し、送信する操作は人間に残します。

既存の会話には、それまでの調査結果や確定済みの判断があります。新しいタスクを実行できたとしても、それだけで作業中の会話へ追加指示を渡せたことにはなりません。そのため、「PC上で動いたか」に加えて、「対象の会話で続きを扱えたか」を確認しました。

接続、保存、添付、送信を分ける

今回の経路は、四つの役割に分けています。

添付はReporterが行い、ボタンの操作と送信は人間が行います。原本は次の保存で置き換わりますが、添付用コピーは指示ID別に保持するため、両者を図でも分けています。

役割	担当するもの	確認する結果
外部接続	トンネル	WorkからローカルMCPへ到達できる
保存	ローカルMCP	渡した本文と保存された本文が一致する
添付	VS CodeのReporter拡張機能	検証したファイルの参照をCodex入力欄へ追加できる
依頼・送信	人間	対象会話と添付を確認し、依頼文を付けて送信する

MCPは、AIアプリケーションが外部のツールやデータへ接続するための規約です。今回作ったMCPの仕事は、受け取った指示本文をファイルへ保存することです。保存した時点で、VS Codeの会話が自動的に更新されるわけではありません。

また、送るのはツールの引数として指定した本文です。Workのチャット全文や、それまでの判断経緯が自動的に丸ごと引き継がれる構成にはしていません。実装に必要な前提は、渡す指示の中へ含める必要があります。

ngrokでは、PC内への保存まで確認できた

最初の外部接続の検証ではngrokを使い、ローカルMCPへ短い架空文を保存できました。この段階で確認できたのは、ブラウザー側から外部接続を経由し、PC内の保存先へ本文が届くことです。

ただし、本文がPC内に届いても、既存のCodex会話へ渡す部分は別に必要でした。ngrokによる保存成功を、VS Codeまでの受渡し成功とは扱いませんでした。

その後の検証経路はSecure MCP Tunnelへ移し、現在の構成ではngrokを使っていません。ngrokで保存に失敗したから移行した、という結果ではありません。接続に成功した事実と、最終的に採用した構成を分けて記録しています。

保存原本と、Codexが読むコピーを分けた

現在のローカルMCPには、指示を保存するsave_instructionというツールを用意しています。本文は複数行を扱え、UTF-8で最大64 KiBです。初期検証の短文用ツールから、通常の指示を扱う形へ変更しました。

保存レコードは次の形式です。これは項目を説明するための架空の例で、実際の検証ログではありません。本文ハッシュだけは、例に記載した本文から計算しています。

{
  "schema_version": 1,
  "submission_id": "11111111-1111-4111-8111-111111111111",
  "instruction": "架空の説明用指示です。",
  "instruction_sha256": "c04d9d485eec54f02780469ea1ac4d68477960816fb174548caadf08163e69c1",
  "saved_at": "2026-10-03T00:00:00.000Z"
}

schema_versionは保存形式、submission_idは指示ID、instructionは本文、instruction_sha256は本文の照合値、saved_atは保存時刻です。

原本はinstruction-record.jsonの最新一件だけです。異なる本文を保存すると原本を置き換えます。未処理の指示を順番に蓄積するキューや、監査履歴ではありません。

一方、Codexへ添付するファイルまで同じ固定パスで上書きすると、添付後に次の保存が行われた際、Codexが読む内容が変わるおそれがあります。

そこでReporterは、原本を検証したうえで、PC内のLOCALAPPDATA配下へsubmission_id別のコピーを作ります。同じIDのコピーを別内容で上書きせず、既存コピーを再利用するときも原本との一致を確認します。

Reporterは本文のハッシュと、原本・コピーのファイル全体のハッシュを照合します。本文の検証部分は、実装のvalidateInstructionRecordから次のように抜粋できます。

const instructionSha256 = sha256(Buffer.from(record.instruction, 'utf8'));
if (instructionSha256 !== record.instruction_sha256) {
  throw new Error('instructionのUTF-8 SHA-256が一致しません。');
}

sha256はNode.jsのcryptoでハッシュを計算する関数です。recordの解析と形式検証は、この抜粋より前に行っています。

これらは内容の不一致を検出する処理です。送信者の認証や暗号化は提供せず、保存ファイルは平文です。

この構成には、外部のWorkからPC内へ指示を書き込む経路があります。接続側の認証はトンネル側で別に管理し、人間は送信前に対象会話と指示内容を確認します。この内容確認は、意図しない指示を実行させないための確認段階であり、接続の認証やPC内ファイルのアクセス制御を代替するものではありません。

保存側には、並行要求を順に処理する仕組みと、古い指示IDでの再試行が新しい原本を上書きしない仕組みもあります。関連の自動テストは行っていますが、Workからの実通信による並行運用まで成功した結果とは区別しています。

NAS上のパスを、そのまま渡すだけでは足りなかった

ロコリスでは、リポジトリをNAS上で扱っています。調査した経路では、VS Codeで開けるドライブ文字やUNCパスでも、Codexの実行環境から読めない場合がありました。

また、調査したchatgpt.addToThreadは、選択した本文そのものではなく、パスと行番号の参照を追加する動作でした。画面に内容が見えていることと、受け手がその参照先を読めることは別です。

採用したReporterでは、原本と一致するPC内コピーを作り、そのファイルURIをchatgpt.addFileToThreadへ渡しています。この処理はCodex入力欄へファイル参照を追加するところまでです。対象会話の選択や自動送信は行いません。

手動受渡しで、本文を読めたところまで確認した

2026年9月28日の接続検証では、次の流れを確認しました。

ローカルMCPを起動し、TCPの待受を確認する。
Secure MCP Tunnelの到達確認で、/readyzがHTTP 200になることを確認する。
Workから架空の短い本文を保存する。
VS Codeで対象のCodex会話を表示し、「Work MCP → Codex」を押す。
添付と会話を確認し、人間が読取依頼を入力して送信する。
Codexの応答で、本文と本文ハッシュの一致を確認する。

使った本文は「架空検証: Tunnel経由の接続確認」です。Codexはこの本文を正確に読み、instruction_sha256が本文のUTF-8 SHA-256と一致すると確認しました。

途中では、ファイルを添付しただけでCodexが「ご依頼内容が空」と返す場面もありました。添付ファイルがあることと、それを使って何をするかという依頼があることは別です。

そのため、添付後に「添付JSONを読み取り専用で確認し、instructionを返す」のような依頼文を人間が送る手順にしました。長い本文を貼り付ける操作は省けますが、送信まで全自動になった構成ではありません。

トンネルのready表示だけでは判断できなかった

成功する前に、Workのツール呼出しが二回Internal errorとなり、保存JSONが旧内容のままだったことがあります。失敗した時点のMCP稼働状態は確定していません。

後の確認では、MCP停止中にTCP待受がなく、起動後に/readyzがHTTP 200になることを確認しました。この結果から、トンネルのready表示だけでローカルMCPへ到達できると判断せず、待受と到達確認を分ける手順にしています。

また、Work側にエラーが返った場合は、保存原本も確認します。今回の本文、ID、保存時刻が更新されたかを調べ、保存が完了したのか、旧内容のままなのかを区別してから再試行します。

Dotでは、自身のタスク継続と既存会話への接続で結果が分かれた

Dotについては、別の受渡し経路として、PC上で調査を実行できるか、既存のVS Code会話を読み、その続きを扱えるかを検証しました。対象となる人間作成の検証会話は、VS Codeとデスクトップアプリの両方で表示できることを人間が確認しています。

その会話が画面に存在することを前提に、2026年10月3日の環境では次の結果になりました。

確認対象	結果
PC上での調査タスク実行	成功
Dotが作成した同じ調査タスクへの追加依頼	成功
その会話IDによるAPI読取	エラーで失敗
Dot作成タスクをVS Codeで開く経路	未確認
人間作成の既存VS Code会話への追加指示	成立を確認できず

人間が作成した会話の直接読取では、unsupported placement format version 1というエラーが返りました。今回の記録から、その原因は確定できません。また、調査したDot側と既存調査タスク側では、既存のローカル会話へ追加指示を送るために調査したmcp__codex_app__send_message_to_threadは、提供ツール一覧に存在せず、参照結果もundefinedでした。この結果は、調査した環境でそのツールを利用できなかったことを示しています。

この結果だけでDot全体が使えないとは判断していません。Dot自身が作成したタスクの継続は成功しています。ただし、今回必要な「人間が作業している既存VS Code会話への受渡し」には採用を保留しました。

固有文字列が見つかっても、会話を特定できたとは限らない

会話の照合では、検証用の固有文字列を使いました。しかし、その文字列は相談中のWork会話にも引用されていたため、検索結果の一致だけでは対象会話を識別できませんでした。

引用先の会話を送信先と取り違えないために、会話ID、直接読取した内容、実行環境を示す結果を分けて確認しました。本文にPC名やリポジトリ名が書かれていても、それだけで実際の実行場所を証明したことにはしません。

この用途では、候補を見つける検索と、送信先を確定する確認を分ける必要がありました。

新しいタスクを動かせても、既存会話への送信は別だった

Dotとは別に、Codex App Serverから直接投入する方法も調査しています。実行ファイルの解決後、使い捨ての会話でturn/startの受理と完了を確認しました。

一方、開いている既存VS Code会話のthread/resumeでは、別writerとの競合で送信前に停止しました。新しい会話で実行できた結果を、作業中の会話へ安全に追加指示を送れた結果には広げていません。

そのため、別App Serverから直接投入する方法は常用せず、既存の入力欄へファイルを添付し、人間が送信する構成を採用しています。

確認できた範囲と、運用上の制約

今回確認できたのは、架空の短い本文一件を使った手動受渡しです。通常の指示を保存する実装と関連テストは整っていますが、実データでの長期利用、PC再起動後の自動復旧、複数利用者の並行運用、第三者による初期導入まで検証済みとはしていません。

運用上は、次の制約があります。

保存原本は最新一件です。複数の未処理指示を蓄積する用途には、そのまま使えません。
保存原本と添付用コピーは平文です。認証、アクセス権、保管の扱いは別に考える必要があります。
現在のReporterは、対象会話の自動選択や送信を行いません。
保存されるのは指定した指示本文です。Workの会話履歴全体の同期ではありません。
Dotの結果は今回の環境での観測です。他の環境や将来の提供条件まで非対応と断定するものではありません。

現在の構成では、既存のTask Monitor監視機能へ受渡し処理を組み込んでいません。ローカルMCPは別プロセス・別保存先で動き、Reporterが添付を担当します。

ブラウザーとPCをつなぐ経路ができたら、次は「保存内容が一致したか」「受け手が読めたか」「正しい会話へ依頼できたか」を確かめる。この区切りで検証すると、保存までの成功を会話の引継ぎ成功と取り違えずに、採用できる範囲を判断できます。

関連記事・参考資料

今回の受渡しとは別に、複数Codexの状態監視と人間の承認状態を分ける構成は、次の記事で説明しています。

複数Codexの「実行中・エラー・承認待ち」をどう分けて監視するか――Locolisu AI Task Monitorの技術構成

MCP公式ドキュメント：What is the Model Context Protocol?