ChatGPT Agent はローカルファイルを直接読めない：境界と安全な渡し方

ChatGPT Agent は、~/Downloads/report.pdf、C:\Users\me\Desktop\contract.docx、手元のプロジェクトフォルダのようなローカルパスを、書いただけで直接読めるわけではありません。製品環境で動く Agent から見ると、そのパスはあなたのPC上の住所であって、自動でマウントされた作業ディレクトリではありません。扱えるのは、あなたが明示的にアップロードしたコピー、承認済みアプリから渡されたデータ、repo や workspace に置かれたファイル、セッション内で生成されたファイル、または別のローカルツールが制御して渡したコンテキストです。

最初に考えるべきことは「どんなプロンプトならディスクを見せられるか」ではなく、「この作業に必要な権限は何か」です。PDF の要約なら、機密情報を消したコピーをアップロードするだけで足ります。コードを変更するなら、repo、branch、diff、review が必要です。ローカルで test を走らせる、dev server を起動する、未コミットの状態を見るなら、Codex、Claude Code、または別のローカル coding agent に切り替える場面です。.env、SSH key、API token、顧客データ、DB、未公開コード、ログイン済みブラウザが関わるなら、まずマスク、fixture、隔離 workspace、または停止を選びます。

この問題を「どこかにローカルファイル許可のスイッチがあるはず」と見てしまうと危険です。アップロードはコピーの境界、コネクタはサービスとアカウントの境界、repo は version control の境界、ローカル agent は workspace と command の境界、bridge は追加ソフトウェアで作る信頼境界です。境界がPC本体に近づくほど、権限は狭く、ログは明確に、取り消しは簡単にしておく必要があります。

まず結論

安全な順番は、ファイルがどこにあるかを決め、Agent に必要なのが読み取り、書き込み、コマンド実行、ネットワーク、ブラウザセッションのどれかを分けることです。単なる読み取りならコピーで済むことが多く、実ファイルの変更や実行が必要なら、製品面を変えるか、権限を絞った workspace に移します。

重要なのは、ChatGPT Agent が「ファイルを扱えない」という話ではありません。扱えるファイルの渡し方を明示する必要がある、という話です。コピーを渡して読ませることと、あなたのPCのフォルダを見回らせることは別です。前者は入力の共有、後者は環境の委任です。

タスクを一文で書くと判断しやすくなります。「この PDF を読む」「この repo の branch で3ファイルを直す」「npm test を走らせる」「localhost:3000 を確認する」「ログイン済み画面で送信する」。書き込み、command、network、session、顧客データが出てくるほど、ChatGPT Agent の通常のファイル渡しではなく、より強い管理が必要な委任になります。

ファイルの場所を分ける

「ファイルアクセス」という言葉だけでは粗すぎます。アップロードしたコピー、接続アプリの文書、GitHub repo、Agent のセッション内ファイル、ブラウザでダウンロードしたファイル、ローカルディスクの実パスは、それぞれ違う契約です。ここを混ぜると、要約だけで済む作業が、PC への広い委任に見えてしまいます。

アップロードしたコピーは、単発の読み取りに向いています。ChatGPT は添付された PDF を読み、CSV を説明し、契約書を比較し、表を整え、場合によっては修正版を作れます。ただし元のローカルファイルがライブ接続になるわけではありません。ディスク側で後から編集しても、会話内のコピーには自動反映されません。この制約は不便ではなく、むしろ安全な性質です。渡す範囲を人間が決められるからです。

接続アプリは、サービス、アカウント、workspace policy の経路です。ファイルが Google Drive、Gmail、Notion、GitHub、社内ナレッジベースにあるなら、connector は承認済み範囲のデータを渡せます。ここで確認するのは、どのアカウントが接続され、どの role があり、管理者が何を許し、どの action に確認が必要かです。クラウド上の1ファイルを読めることは、デスクトップや Downloads を読めることを意味しません。

repo route は、履歴、review、再現性が必要なときに向いています。コード、docs、設定を扱うなら、repo が作業対象、branch、変更範囲、test を定義します。ただしローカルの未コミット変更、秘密情報、ローカルサービス、本機だけの状態は repo route から見えない場合があります。その依存があるなら、まず最小の差分を repo に入れるか、ローカル workspace で制御して作業します。

セッション内で生成されたファイルは、Agent 側の環境にあります。sandbox、container、workspace の中でファイルを作ったり一覧したりできても、それはあなたの個人PCを見ている証拠ではありません。terminal や filesystem という言葉を見たら、どの host なのか、どの path が mount されているのか、どのデータをユーザーが明示的に渡したのかを確認します。

ブラウザでダウンロードしたファイルも別扱いです。ブラウザのダウンロード先は普通あなたのPCです。そのファイルを Agent に読ませるには、アップロードする、接続済みサービスに保存する、またはローカル agent の workspace に入れる必要があります。ブラウザ操作とローカルファイル権限は同じではありません。

ツール名ではなく権限で選ぶ

読み取り、書き込み、コマンド実行、ネットワーク、ブラウザセッションは別々に考えます。読み取りだけの作業に、書き込み権限や shell 権限を渡す必要はありません。契約書の要約、CSV の説明、報告書の整理、文言チェックは、アップロードコピー、接続文書、repo の読み取り、またはマスク済み抜粋から始めるべきです。

修正版ファイルが必要なだけなら、「コピーを入れて、新しいコピーを出す」形で済むか確認します。文書、表計算、スライド、議事録の多くはこれで十分です。元ファイルは手元に残り、Agent は確認可能な出力を返します。人間が内容を見てから置き換えるので、実ファイルへの予期しない書き込みを避けられます。

実プロジェクトのファイルを変更し、依存関係を入れ、test を走らせ、local server を起動するなら、ChatGPT Agent にファイルを渡す問題ではなく、ローカル作業の委任です。Codex や Claude Code のようなローカル coding agent は、プロジェクトの近くで動けるから便利です。その分、sandbox、approval、network 制限、secret path の deny、diff review が必要になります。

ネットワークやログイン済みブラウザも独立した権限です。Web ページを操作できる Agent が、ファイルシステムも読めるとは限りません。ローカルファイルを読める環境が、cookie、SSO、管理画面を使ってよいとも限りません。ファイル、アカウント、操作、確認を分けて扱います。

判断に迷う場合は、必要な authority を明文化します。読み取りだけなのか、書き込みなのか、コマンドなのか、ネットワークなのか、ログイン済み session なのか。どれかが増えたら、同じUIの中で雑に進めず、より狭い route に戻すか、ローカル workspace へ移すべきです。

最小権限で止まる

アップロード、connector、repo、local agent、bridge の前に、5つだけ確認します。読むだけか。書く必要があるか。コマンドを実行するか。ネットワークを使うか。ブラウザセッションで動くか。各「はい」はリスクを増やします。各「いいえ」は渡してはいけない権限です。

1つのファイルで足りるのにフォルダ全体を渡さないでください。構造だけ確認できればよいのに顧客データを渡さないでください。.env、SSH key、API token、keychain、ローカルDB、医療・法務・財務記録、未公開コード、cookie、ログイン状態を、整形や要約のために露出させないでください。

安全な形はたいていもっと狭いです。必要なファイルだけをコピーする。アップロード前に secret、個人情報、顧客IDを消す。構造確認には fixture を使う。コード変更は branch、diff、review、test を通す。writable workspace でも secret path は deny する。connector や bridge は作業後に取り消す。

最小権限は形式的なセキュリティ用語ではありません。「このコピーを読んで」から「このディレクトリを書き換えて」へ進む瞬間に、Agent は実状態を変えられます。削除、上書き、誤送信、秘密情報の混入、不要なネットワークアクセスは、後でプロンプトを直しても消えません。

停止も正常な選択です。ファイルに secret があるなら、まず送らない。顧客データなら脱敏する。production database なら schema と fake data にする。ログイン済みブラウザが必要なら、test account や操作確認を挟む。露出範囲を説明できないなら、作業を進めない方が安全です。

ChatGPT Agent で足りる場面

ファイルを元の場所から切り離せるなら、ChatGPT Agent で十分なことが多いです。PDF を要約する、2つの契約書を比較する、CSV の列を説明する、承認済み connector から文書を読む、添付資料をもとに新しいファイルを作る、といった作業です。

共通点は、Agent が元ファイルの後続変更を監視する必要がないこと、隣のフォルダを探す必要がないこと、ローカル test を走らせる必要がないこと、結果を実パスへ直接書き戻す必要がないことです。人間が入力を明示し、Agent が確認可能な出力を返します。

connector も有効ですが、ファイルがもともとサービス内にある場合に限って考えます。クラウド文書、メール添付、repo issue、社内 knowledge base などです。connector の境界はアプリ、アカウント、role、確認操作です。PC のローカルディスクではありません。

編集が必要でも、新しいファイルとして返せるならこの範囲に収まります。Agent が作った修正版を見て、採用するかどうかを人間が決める。原本を直接変えないので、誤操作時の被害も限定できます。

Codex、Claude Code、ローカル agent に切り替える場面

実プロジェクトの状態に依存するなら、ローカル workspace へ切り替えます。複数の source file を変更する、uncommitted changes を見る、test を走らせる、package script を実行する、dev server を起動する、ローカル config を読む、localhost を確認する、といった場面です。

Codex local、Claude Code、その他の local agent は、選ばれた workspace の中で読み書きし、コマンドを実行できるから役に立ちます。だからこそ、最初から full access にしないことが大切です。read-only または workspace-scoped から始め、approval を残し、network を制限し、.env、key、DB、private folder を除外します。

広い coding-agent 比較が必要なら Claude Code vs Codex が役に立ちます。ローカルファイルの判断だけならもっと単純です。明示的なデータ経路で足りるなら ChatGPT Agent。live files、commands、tests が必要なら local agent。安全な境界を説明できないなら停止です。

local agent でも全権委任は避けます。project root、branch、変更ファイル、実行コマンド、test 結果、diff review を残します。可能なら disposable copy や fixture を使い、必要が証明されるまで書き込みや network を広げません。

bridge を使うべき場面

local bridge は、あなたのPC上で別のソフトウェアを動かし、特定のフォルダ、内部サービス、ローカルDB、操作だけを Agent に渡す仕組みです。強力ですが、ChatGPT Agent の標準能力ではありません。bridge が存在する時点で、信頼境界は bridge software、設定、scope、log、取り消し手段に移ります。

bridge を検討する条件は4つです。upload、connector、repo、local agent で安全に解けない。bridge が必要な path、service、action だけを公開する。読み取り、書き込み、command、network が別々に制御される。アクセスが記録され、時間制限され、取り消せる。1つでも欠けるなら、bridge を広げる前に設計を戻します。

bridge はプロンプトの裏技ではなく、内部インフラとして扱います。secret directory を拒否する。credentials を公開 tree の外に置く。最初は read-only にする。outbound network を限定する。作業用 workspace を使う。誰が、いつ、何のために、どの path と action を許されたかを記録します。

社内データや顧客情報を扱う場合、技術的に接続できることと、共有してよいことは別です。承認、監査、脱敏、test account、data handling rule が必要なら、それを先に満たします。便利さだけで bridge を標準経路にしてはいけません。

ファイルが見えない時の切り分け

Agent がファイルを開けないと言ったら、最初にプロンプトを変えるのではなく、どの route を与えたつもりだったかを確認します。

ローカルパスだけを貼ったなら、ファイルをアップロードするか、local agent に移します。C:\Users\me\Downloads\report.pdf はあなたのPCには意味がありますが、クラウド側やブラウザ側の agent environment には届きません。

すでにアップロードしたなら、アップロード完了、添付の残存、ファイル名、依頼内容を確認します。「このコピーを読んで」と「元のフォルダのファイルを書き換えて」は別作業です。

connected app のファイルなら、connector の有効化、アカウント、scope、workspace policy、action confirmation を確認します。connector が使えないからといって、同期済みローカルフォルダを丸ごと渡す必要はありません。より狭い共有や export copy が使えるかを先に見ます。

repo のファイルなら、repo、branch、path、同期状態、権限を確認します。ローカル未コミットの変更は、commit、push、添付、または workspace へのコピーをしない限り見えないことがあります。

ブラウザでダウンロードしたファイルなら、それはまずあなたのPCにあります。分析するには明示的に渡す必要があります。

機密ファイルなら、切り分けの答えは「権限を増やす」ではなく「渡さない」かもしれません。脱敏、fixture、controlled workspace、停止を優先します。

FAQ

ChatGPT Agent は Desktop や Downloads のファイルを読めますか？

ローカルパスだけでは読めません。コピーをアップロードする、承認済み app を使う、repo/workspace route を使う、または live local files が必要な場合だけ local agent に切り替えます。

アップロードはローカルファイルアクセスと同じですか？

違います。アップロードは会話や workspace にコピーを渡すだけです。元の path、同じフォルダ、hidden file、後からの変更への継続アクセスは与えません。

connector はPC全体を公開しますか？

公開しません。connector は接続されたサービスやアカウントのデータを、許可された範囲で扱います。ローカルファイルシステムの一般権限ではありません。

repo の作業はどうすればよいですか？

読み取りや versioned な変更は repo route が向いています。ローカル test、script、service、未コミット状態が必要なら、workspace を絞った local coding agent を使い、approval と review を残します。

full access を使うべきですか？

狭い route では解けず、リスクを意図的に受け入れ、backup、log、review、rollback を用意できる場合だけです。missing file の普通の解決策ではありません。

Agent の terminal は自分の terminal ですか？

必ずしもそうではありません。sandbox や agent environment の terminal かもしれません。host、mount、workspace root、渡されたデータを確認してください。

bridge は最善の解決ですか？

多くの場合は最後の選択肢です。upload、connector、repo、local agent で安全に処理できない特定の local resource があり、scope、log、revocation、secret deny を設計できる時だけ使います。

機密ファイルはどう扱うべきですか？

初期状態ではアップロードも bridge もしません。secret を消し、fixture を作り、controlled local workspace を使うか、作業を止めます。Agent に見せられることと、見せてよいことは別です。