このポスト、かなり本質を突いている
正直、この投稿は「Claudeが社内で流行っている」という話より、AIエージェント時代のセキュリティの地雷をかなり端的に言い当てていると思う。
非エンジニアでもClaude CoworkやClaude Codeを利用して業務を行っています。
ここで重要なのは、AIが“質問に答えるだけのチャット”ではなく、実際にPCや開発環境に触る前提の道具になってきたこと。
ClaudeのCoworkは、Claude Codeと同じエージェント型の仕組みをClaude Desktop側でも使えるようにしたもので、単発の応答ではなく、複数ステップの作業をまとめて実行する方向に寄っています。 Claude ヘルプセンター+1
だからこそ、投稿にある「.env にシークレットキーを置くと危ない」という一文が効いてくる。
昔なら .gitignore していれば一応は回っていた運用が、AIがローカルのファイルやコマンドに触る前提になると、急に心許なくなるんですよね。
何がそんなに危ないのか
Claude Codeの公式ドキュメントを見ると、設定で Read(./.env) や Read(./secrets/**) を明示的に拒否できるようになっています。つまり公式側も、環境ファイルや秘密情報ファイルは保護対象として扱う前提で設計しているわけです。 Claude
さらに認証ドキュメントでは、Claude Code自身の資格情報はmacOS上で暗号化されたKeychainに保存され、apiKeyHelper のような仕組みでキー取得を外部化できることも案内されています。 Claude+1
ここ、けっこう大事です。
AnthropicのヘルプではAPIキー管理の基本として環境変数やSecretsの利用が案内されていますが、それは主にアプリやクラウド実行の文脈の話です。ローカルでAIエージェントがコマンド実行まで担う場面では、「環境変数に載せれば十分安全」とは言い切れない局面が出てくる。実際、Claude Codeで環境変数が意図せず露出しうるという報告も公開されています。これは“危険が確定した”と断定するより、脅威モデルが変わったと見るのが自然だと思う。 Claude ヘルプセンター+1
1日でOSSを作った、の価値が大きい
この投稿で個人的にいちばん面白いのは、「危ないよね」で終わらず、チームのメンバーが1日でOSSを作ったところです。
実際、この問題意識にかなり近い公開例として、3月1日に公開された macOS Keychain 管理CLI「LLM Key Ring（lkr）」があります。これはキーをKeychainに保存し、lkr exec で子プロセスにだけ環境変数として注入する設計で、標準出力やファイル、クリップボードへ生値を出さないことを基本にしています。さらに非対話環境での生値出力を防ぐTTYガードも入っています。 Zenn
これ、地味だけどかなり筋がいい。
AIエージェント時代の防御って、巨大なセキュリティ製品を入れることだけじゃなくて、こういう「平文を置かない」「必要な瞬間だけ注入する」「人間とエージェントで経路を分ける」みたいな、小さくて鋭い設計の積み重ねなんですよね。
そして、この種のツールが1日でOSSとして形になるのも象徴的です。
AIが広がるほど、新しい不具合や抜け穴は増える。でも同時に、現場のエンジニアがそれを見つけて、すぐ直して、公開して、周りが取り込める速度も上がっている。
AI駆動開発で本当に変わるもの
Cursor、Claude Code、GitHub Copilotみたいなツールの比較って、つい「どれが賢いか」に寄りがちです。
でもこれからは、どれが安全に運用できるかも同じくらい大きな論点になると思う。
非エンジニアまでCoworkを使うようになると、エンジニアの役割も少し変わります。
コードを書く人であることはもちろん大事なんだけど、それ以上にAIが触っていい範囲を設計する人、秘密情報の流れを分離する人、事故が起きにくい初期設定を配る人が強くなる。
個人的には、将来の技術スタック選定でも
「AIを導入できるか」ではなく「AIを安全に常用できるか」 が分かれ目になるんじゃないかなと思っています。
だからこの投稿は、単なるClaude活用自慢ではなくて、
「社内にAIが浸透した次の瞬間、運用の弱点はどこに出るのか」
そこまで含めて見えているのが面白い。
便利さの話は派手です。
でも本当に後から効いてくるのは、たいていこういう地味な設計です。そこに先回りしてOSSまで出しているのは、かなりいい動きだと思う。