Claude Code と Codex CLI、2つの AI コーディングエージェントのハードニング・チートシートを公開しました。
2つを並べて書いたことで見えてきたことを、少し書いておきたいと思います。
エージェントが動く場所は、あなたの端末
AI コーディングエージェントは、クラウド上の API を呼ぶだけのツールではありません。ユーザーの端末上で動作し、シェルコマンドを実行し、ファイルを読み書きし、場合によっては外部サービスと通信します。
しかも最近は「コーディング」エージェントという名前に反して、用途がプログラミングに閉じなくなっています。ドキュメントの作成やレビュー、データの整理・分析、調査業務。開発者以外のメンバーが日常的に使い始めている組織も珍しくありません。
つまり、エージェントの設定を強化するということは、その端末——ひいては端末がアクセスできるコードベース、認証情報、社内ネットワーク——を保護することと同義です。利用者が増えるほど、この問題は大きくなります。
「お願い」では止められない
「CLAUDE.mdや、AGENTS.md に『これこれはやらないで』と書いておけばいいのでは？」——これはよく聞く話です。
答えは NO です。instruction 系のファイルはあくまでプロンプトの一部であり、セキュリティの強制力はありません。エージェントが読み込んだ外部コンテンツに悪意ある指示が含まれていれば、instruction の内容は上書きされ得ます。「起きてほしくないこと」に対しては、お願いではなくポリシーとして強制する必要があります。
それが、設定ファイルのハードニングを最初に行うべき理由です。
設計思想は違う、守るべきものは同じ
今後どう発展するかは分かりませんが、このリリース時点での話として、それぞれのツールの設計思想の違いが見えてきました。
Claude Code の settings.json は、deny / ask / allow という3段階のパーミッションルールとサンドボックスで多層防御を構成します。deny に入れたコマンドは、ユーザーが「はい」を押しても実行されません。疲れていても、急いでいても、判断を間違えない。それが deny の価値です。
一方で deny ルールには穴もあります。Read(**/.env) を deny にしても、cat .env は Bash 経由で通る。deny ルールの Read と Bash は別のレイヤーです。そこで、サンドボックスが実装されたという経緯だと思われます。OS レベルでファイルとネットワークのアクセスを分離することで、deny の隙間を埋めることが実現されています。
Codex CLI の config.toml は、sandbox / approval / network / history という4つの軸で構成されています。この構造自体が多層防御を体現している。sandbox の設定が甘くても approval で止まる。approval をうっかり通しても network が閉じていれば外にデータが出ないというわけです。
特に印象的だったのは、ネットワークアクセスはデフォルトで閉じている点です。必要なときだけ profile で開ける——つまり「開けるのが例外」という世界観。そして一番広い sandbox モードの名前が full-access ではなく danger-full-access であること。広げる側が危険であることを、名前で伝えてくる。些細に見えますが、こういうところに設計者の姿勢が出ます。
ツールの設計思想は異なりますが、守るべきものは同じです。
「どこまでやらせるか」を明文化する
結局のところ、ハードニングとは「このエージェントに、どこまでやらせるか」を設定として明文化する作業です。
この判断を、疲れているときの自分や急いでいるときの自分に委ねてはいけません。急いでいると許可プロンプトに安易に「はい」を押しがちですし、よくわからなくてYes/Noを判断できないこともある。だから deny が要るし、サンドボックスが要るし、profile が要る。
どんなに設計が優れていても、設定する人間が「面倒だから全部開ける」をやったら意味がありません。チートシートは、そういうもったいない使い方を減らすためのガイドです。
組織での展開に向けて
AI コーディングエージェントの導入が進む組織では、利用者ごとにセキュリティ設定がばらつきがちです。ある人は deny を設定し、ある人はデフォルトのまま。ある人はサンドボックスを有効にし、ある人は存在すら知らない。
チートシートとテンプレート設定ファイルを社内の利用ガイドラインに組み込むことで、チーム全体のベースラインを揃えることができます。テンプレートをそのままコピーするのではなく、「なぜこのルールが必要か」を理解した上で選ぶことが大事です。チートシートにはその判断材料も書いてあります。
いずれも CC BY-SA 4.0 ライセンスで公開しています。社内研修やオンボーディングの資料としてもお使いください。フィードバックや追加提案は GitHub の Issue やプルリクエストで歓迎します。
自組織への導入や設定の最適化、チーム向けのトレーニングについては、弊社でもご相談を承っております。お気軽にお問い合わせください。
Claude Code
Codex CLI