WSL, Dockerが禁止。拡張機能ひとつ入れるにも申請。CLIを入れたいだけなのに管理者権限がない。AIツールも機能限定のチャットだけ。たまにこんな制約の現場を見かけます。

PCのセキュリティを管理するため、情報漏洩を防ぐため。どの立場の人も、良かれと思ってやっています。

ここで、特定の誰かを責める話ではなく、業界みんなの"あるある"として、一緒に考えてみたいのです。その制約、本当に長期のセキュリティにつながっているんだっけ？と。

この問いは、急速に切実になってきました。Claude Fable 5のようにモデルLLMの性能が上がり、AIを"使いこなす現場"と"触らせない現場"の差が、みるみる開きはじめています。攻撃側は、当然そのAIをフルパワーで使ってくる。エンジニアの手を縛るコストは、もう昔とは桁が違うのです。

寿司職人を給湯室に立たせていないか

「水道は給湯室にあります。包丁の利用には都度申請が必要です」。多くの職種には合理的な制約でも、寿司職人は腕を振るえません。

ソフトウェアエンジニアも、同じです。ソフトウェアとツールは、食材であり、包丁です。エンジニアに一般職と同じ利用制限をかければ、エンジニアとして機能できなくなります。

非エンジニアの会社がベンダーに外注しても事情は変わりません。せっかくスキル・信頼の高いベンダーを選んだのに、自社一般職向けのルールでそのエンジニアスキルにフタをしてしまう状況がよくあります。もったいない話です。

そもそもソフトウェアって、何？

「ソフトウェアのインストール・利用は事前に申請してください」。よくあるルールですね。でも律儀に守ろうとすると、哲学が始まります。

pip install は？
VSCodeやブラウザの拡張機能は？
curl | bash のワンライナーは？
docker run は「インストール」？
自分で書いたプログラムは？
Claude Codeにskillを足すのは？
Claude Codeが自動で入れるパッケージは？

ソフトウェアエンジニアにとって「インストール」の境界は曖昧です。しかも申請が必要かどうかを、誰が判断するのでしょう。迷って聞くと、責任を取れないので上へエスカレーション。最後に判断する人は、たいていエンジニアではありません。わからないから「念のため申請してください」に落ち着く。誰も悪くないのにこうなります。

しかも、めでたく許可が下りても、いざ使おうとすると包丁が鎖につながれ、まな板の端まで届かなかったなんてこともよくあります。

規制する側は、申請書に書かれた最小限しか許可しません。それが仕事だから当然です。でもエンジニアは、まさか「Python利用申請」で通したそのPythonが、プロセスからネットワークに出るだけで、また別の申請がいる—なんて思いもしません。同じ「許可」という言葉を、おたがい違う意味で握っている。

docker run のたびに申請、Pythonプロセスがネットワーク通信するたびに申請、現実的でしょうか。ここで一度、思い出したいのです。その申請、そもそも何を守りたかったんだっけ？と。

守るなら、「入口」より「抑える速さ」

最近のサプライチェーン攻撃を見ていると、「許可されたソフトウェアなら安全」は危ういです。信頼していた正規のライブラリが、ある日とつぜん攻撃の入口になることが現実によく起きています。

そもそも「安全なソフトウェアベンダーかどうか」を事前に外から判定するのは、かなり無理があります。「直近1年で情報漏洩があれば禁止」なんてルールだと、急成長中のベンダーはたいてい引っかかり、逆に実績のない怪しいベンダーが「事故ゼロだから許可」になる。本末転倒です。Microsoftが事故っても、禁止にはならないのに。

なので、入口で完璧に止めることより、攻撃されても素早く抑え込むことがだいじになります。

先月（2026年6月）のMicrosoftの事例では、狙われたリポジトリをごく短時間で無効化しました。これができる組織は日本にどれくらいあるでしょう。あるいは「min-release-age を入れよう」みたいなTipsが、社内で即座に共有され、実行に移せるか。申請を機械的にさばくだけの体制では、この速さは出せません。

そしてこの"速さ"を支えるのは、日々手を動かしているエンジニアです。脆弱性を見つけ、影響を測り、直し、確かめる。禁止リストだけでは、この力は育ちません。「ルールを守っているように見える」より、「セキュリティを守る」を目指したいですよね。

縛ると、育たない、残らない

エンジニアのスキルは、ちょっと書いて、入れて、試して、直して、その小さなくり返しで伸びます。「ちょっと試す」ができない環境は、この成長の芽を静かに摘んでしまいます。

そして、スキルのある人ほど「ここには、良くする余白がない」と感じます。改善しようにも申請で止まり、AIを使おうにも制限で乗らない。結果、できる人から順に、現場を離れていきます。

裏を返せば、思いきり力を出せる場所さえ用意できれば、そういう人にこそ選ばれる組織になれる、ということ。これは個人の資質ではなく、"どんな環境を渡すか"という組織設計の話です。

だから、統制された自由をデザインしよう

もちろん、何でも自由に、ではありません。情報漏洩や監査の対策もいります。顧客データを扱うなら、なおさらです。

禁止を積む発想ではなく「安全に開発できる環境」をちゃんと設計すること。たとえば

顧客貸与PCの案件は、開始前に開発環境の要件をすり合わせる
個人情報を含む本番データには アクセスできない 環境を用意する

ルールを押し付けることではなく、環境設計がセキュリティ対策そのものだと思うのです。

まとめ

開発体験の良さは、そのまま生産性の高さになり、AIの時代には、サイバー防御力の強さにもなります。エンジニア社員への福利厚生ではありません。サイバー防御力を高めることは、自組織を守るだけでなく、私たちの生活を支えるインフラを守ることにもつながります。

だから、開発体験を整えるのって、業界みんなで取り組むテーマだと思いませんか？

コンテキストエンジニアリングとかハーネスエンジニアリングとか、ループなんちゃらとか、AIの環境整備の話題がバズりやすいのですが、その前に人間エンジニアが働きやすい環境を整備していきませんか？これらバズっている単語の中身は、AI以前から人間に対して言えることだったはずです。