PaPoo
cover
technews
Author
technews
世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

Codexに「見ちゃダメなファイル」を教える仕組みがほしい、という話

GitHubのopenai/codexリポジトリに、ちょっと地味だけどかなり重要な要望が出ています。内容はシンプルで、​AIエージェントに読ませたくないファイルを明示的に除外したい、というものです。

これ、派手さはないんですが実際にはかなり大事です。AIにコードを書かせる時代になっても、「これは見せていい」「これは絶対にダメ」の線引きは、人間がしっかり持っていないと危ない。そこをちゃんと仕組みにしよう、という提案です。

ざっくり言うと何が欲しいのか

このIssueで求められているのは、エージェントが読み込んだり、モデルに送ったりしてはいけないファイルやパスを明示できる機能です。

しかも単なる一時的な指定ではなく、次の2段階を想定しています。

たとえば、プロジェクト内に .codexignore のようなファイルを置いて「このリポジトリではこのファイル群は触るな」と定義する。一方で、ユーザー側にも「どのプロジェクトでも .env や秘密鍵っぽいものは見せない」という共通ルールを持てるようにしたい、という考えです。

ここで面白いのは、​**“プロジェクトごとの慣習”ではなく、機械的に守れるルールにしたい**ところです。READMEに「秘密情報はコミットしないでください」と書くのはもちろん大事です。でもAI相手だと、それだけでは心もとない。実際に読ませない仕組みのほうが、ずっと筋がいいと思います。

何を避けたいのか

投稿者は例として、node_modules/ は検索対象に残したいけれど、.env.env.*.pemid_.aws/.ssh/ のようなものは絶対に読ませたくないと書いています。

このバランス感覚はかなりリアルです。
node_modules/ は普段は巨大で邪魔に見えるけれど、実装の確認で参照したいことはあります。だから「雑に全部除外」ではなく、​必要なものは残しつつ、危険なものだけ止めるという発想なんですね。

逆に言えば、AIツールにありがちな「便利そうだから全部見せる」は、セキュリティの観点ではかなり雑です。個人的には、ここを最初にちゃんと設計できるかどうかで、そのツールの信頼度がかなり変わると思います。

なぜ今これが問題になるのか

このIssueには背景として、関連する別のIssueへの言及があります。以前から似た問題、つまり

という2つの用途があったそうです。

一度はその議論が閉じられ、Rust実装の codex-rs 側に寄せる形になったようですが、少なくとも2025年8月28日時点では、​同等の機能はまだ見当たらないというのが投稿者の認識です。なので「もう一度議論を立ち上げて、設計を詰め直したい」というのが今回の主旨です。

ここ、かなり健全だと思います。AIツールって、機能が増えるほど「とりあえず動くけど、境界が曖昧」という状態になりがちです。けれど、本当に使われるツールは、便利さだけでなく安全に使える設計が必要なんですよね。

この要望の本質は「安心して使える標準ルール」

このIssueが言っているのは、単に「除外設定がほしい」だけではありません。もっと深く見ると、​チームで共有できる、決定的で、再現性のあるルールがほしいという話です。

ここでの「決定的」というのは、毎回結果がぶれないという意味です。
「誰かが説明書を読んで気をつける」のではなく、設定があれば機械が黙って守る。これは大きいです。

特にチーム開発では、個人の注意力に頼るルールはすぐ崩れます。新しく入った人が知らなかったり、急いでいる人がうっかりしたりする。だからこそ、​ドキュメントではなく設定ファイルで縛るのは理にかなっています。

しかもユーザー全体のデフォルト設定まで考えているのがいい。
プロジェクト単位だけだと、「このレポジトリには設定がないから大丈夫かな」と毎回確認が必要になります。グローバル設定があれば、最初から守るべきものを広くカバーできます。地味ですが、こういう積み重ねが実運用では効きます。

ちょっと気になる点もある

一方で、こういう機能は作り方を間違えるとややこしいです。
たとえば「除外したつもりなのに、別の経路から読まれてしまう」みたいな抜け道があると意味がありません。あるいは、設定の優先順位がわかりにくいと、今度は使う側が混乱します。

なので重要なのは、単に .gitignore 風の仕組みを作ることではなく、​どの範囲で何が禁止されるのかを明確にすることだと思います。
ローカル設定とグローバル設定が両方あるなら、衝突時にどちらが勝つのかもはっきりしていないといけません。

こういう話は地味ですが、セキュリティ系の機能ではむしろ本体です。派手な新機能より、ここを丁寧に作っているプロダクトのほうが長く信用されるはずです。

投稿者の姿勢もわりと好感が持てる

このIssueの投稿者は、ただ要望を投げているだけではなく、​自分で実装とテストに協力できると書いています。こういう「欲しい、そして手も動かせる」という姿勢は、オープンソースではかなり強いです。

しかも、関連Issueを踏まえたうえで「議論を再開して設計を収束させたい」と言っている。単なる思いつきではなく、過去の経緯を見たうえで話を前に進めようとしているのがわかります。こういう丁寧な提起は、コミュニティでも歓迎されやすいはずです。

ひとことで言うと

AIエージェントにコードを読ませるなら、​見せていい範囲を人間が明確にコントロールできることが欠かせません。
このIssueは、その当たり前だけど後回しにされがちな部分を、ちゃんと機能として入れようという提案です。

派手な機能ではないですが、私はかなり本質的だと思います。
「何を読ませるか」より先に、「何を読ませないか」を決められること。これがあると、AIツールはだいぶ安心して使えるようになります。


参考: A way to exclude sensitive files · Issue #2847 · openai/codex

同じ著者の記事