生産性という麻薬
なんとなく、ここのところの IT 業界全体というか AI を中心とした開発全体について思うところがあったため、
それをなんとか言語化したもの。
こういうポエムを書くのは初めてだったけれど、なんとなく自分の中のモヤモヤ感を吐き出せた。
果たしてこの先の IT 業界はどうなっていくのだろうか。
導入
生産性という言葉は、この競争社会において非常に強力な力を持っている。
- コード行数を N % 削減した
- ブランチの生存期間が N 分の 1 になった
- N 日で M 万行のコードを実装した
こういった強烈に誘引性をもつワードが繰り返されてきました。
jQuery といったライブラリ、Ruby on Rails といったフレームワーク、CI/CD というデリバリー手法、そして最近のバズワードとなっている AI です。
これらが強力な誘引性を持つのはなぜでしょうか？
僕は「やらないと自分が死ぬという生存本能」があるからだと考えています。
現状維持による相対的な死
生産性は上げ続けなければ相対的に衰退します。
競合他社が生産性を上げ続けるため、それに追いつかないと自分が置いていかれるからです。
現状維持の先には、業績不振による死だけが待っています。
クラウドインフラを例に挙げると AWS、Google Cloud、Microsoft Azure、Oracle Cloud があります。
Wiki サービスであれば Esa、Notion、Helpfeel Cosense、DocBase など数え切れないくらいあります。
勤怠管理システムであれば、聞いたこともないようなサービスが大量に見つかります。
競合がまったくいないサービスの方が稀で、どんなサービスも常に競合がいるものです。
だから、生産性の向上は非常に重要な要素です。
向上しない道は、ありません。
生産性の向上は、常に正の影響だけを与えるのか？
しかしながら、生産性の向上は果たして正の影響だけを与えるのでしょうか？
「生産性を向上する」以外の副作用はないのでしょうか？
そんなことはありません。
目を背けてはいけない、負の側面もあります。
負の側面として、しばしばセキュリティや運用が犠牲になります。
ここで、効率化のトレードオフとしてセキュリティや運用が犠牲になる例を考えてみます。
信頼によって守られる OSS
OSS は非常に効率的です。
どこかの誰かが作成して、それを利用者が修正・改修してより良いものにしていく。
車輪の再発明を防ぎ、一定以上の品質の実装をそのまま借りることができる。
しかし、前提として OSS という文化は信頼で成り立っています。
- OSS メンテナは、脆弱性が検出されたときに、迅速に対応してくれるだろう
- OSS メンテナは、他者からの Pull Request を適切にレビューして良い実装のみ取り込んでくれるだろう
- OSS メンテナは、生涯にわたって悪意ある実装を意図的に実装することはないだろう
こういった前提のもと、僕たちは OSS を利用していますが、最近はそれが破綻してきています。
メンテナンスが放棄される OSS は多く存在します。
OSS を狙って悪意ある Pull Request を出す攻撃者も多く、それをうっかり取り込んでしまうこともあります。
さらには、OSS メンテナが自分で悪意あるコードを仕込む事件だって起きています。
npm ライフサイクルスクリプトによる攻撃
OSS の信頼性低下の影響を最も受けているのはおそらく Node.js の npm パッケージです。
npm にはライフサイクルスクリプトという仕組みがあり、パッケージインストール時に自動でスクリプトを実行できます。
これにより、パッケージインストールと同時に何らかのセットアップ処理を行いたいときに便利である一方で、攻撃者にとっても非常に便利な仕組みとなってしまっています。
リポジトリを侵害してスクリプトを改ざんできてしまえば、あとはそのパッケージに依存するプロジェクトでライフサイクルスクリプトが発火するのを待つだけです。
そして npm パッケージは、他の言語のパッケージ管理システムと比較しても、非常に多くの依存を生みやすくなっています。
これは npm 自体の仕組みの問題というより、文化的側面が強いです。
非常に短く単純な実装であったとしても（それこそ数行程度の） npm パッケージとして公開し、それに依存することが文化として根付いています。
そのため、1つのパッケージを追加するだけで大量の依存が生まれます。
依存が多ければ多いほど、侵害されたパッケージに依存してしまう確率も高くなります。
これと前述のライフサイクルスクリプトの問題が噛み合わさって、攻撃者にとって非常に狙う価値の高い仕組みとなってしまっています。
さらには、フロントエンドは JavaScript（Node.js）の一強となっています。
最近では Rust などの別言語から WASM を出力してフロントエンドで呼び出す方式もあります。
しかし依然として Node.js の利用は根深く、別の言語や別のエコシステムに乗り換えることは難しいです。
ライフサイクルスクリプトの問題は、npm の --ignore-scripts を使用したり、pnpm に移行すれば改善します。
ですが、依存性が非常に大きい問題は、簡単には解決できません。
GitHub Actions のタグ参照運用
GitHub には GitHub Actions という組み込みの CI 基盤があります。
GitHub Actions では Actions を呼び出す際にタグを参照する方法が一般的に根付いています。
以下のように、@v6 や 0.35.0 という部分がタグで、Git のタグバージョンを指します。
steps:
- uses: actions/checkout@v6
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@0.35.0
with:
# 省略
タグは、特定のコミットハッシュ値に別名を付ける仕組みです。
コミットハッシュ値は人間には理解しづらいフォーマットであるため、それを人間に分かりやすい名前で参照できるようにするのにタグが利用されます。
ですが、タグは上書きが可能なため、同じ名前のタグが別のコミットハッシュを参照する場合があります。
このタグの上書きを悪用して攻撃されたのが Trivy サプライチェーン攻撃の1つの trivy-action です。
0.0.1～0.34.2 のタグ参照が書き換えられて、悪意あるバージョンのコミットハッシュを参照するようになりました。悪意あるバージョンに書き換えられていた時間帯に、タグ参照で trivy-action を利用した場合、悪意ある処理が実行されてしまうわけです。
この攻撃を防ぐためには、タグではなくコミット SHA を指定する（SHA Pinning）ことが推奨されます。
コミットが書き換えられるとコミット SHA は変わるため、万が一書き換えられるとパッケージの取得に失敗するようにはなると思いますが、少なくとも悪意あるコードを参照することはなくなります。
（ただし、利用している actions が内部的にコミット SHA などではなくタグなどでバイナリを取得している場合はそれでもダメだが）
以下のような指定方法です。
steps:
- uses: foo/bar@637b79b93a822d436f00c67c0a134f04f52b5729 # v1.0.0
これは「タグでバージョンを参照する」という GitHub Actions の文化を悪用した攻撃です。
つまり、前述の「OSS の信頼」が崩れたことを意味します。
OpenClaw を狙ったサプライチェーン攻撃
最近の例では、OpenClaw のサプライチェーン攻撃が挙げられます。
OpenClaw という AI エージェントは 2025 年 11 月に初版が作成された新しいプロジェクトです。
これは非常に強力で、Claude Code といったターミナル上で使用する AI エージェントよりもずっと多くの作業を自動化できる。
一方で、多くの作業を自動化できるということは、それだけの権限を OpenClaw に与えることを意味します。
メールの購読や送信の権限を与えたとして、OpenClaw が勝手に誰かにメールを送ってしまった場合、誰がその責任を負うのでしょう？
さらに、OpenClaw には ClawHub というエコシステムが存在します。
サードパーティのスキルやプラグインを導入できる仕組みなわけですが、これも攻撃者にとっては非常に狙う価値が高い箇所になっています。
一度侵害できてしまえば、OpenClaw の強い権限を持ってあらゆる作業ができるようになるわけです。
攻撃者なら狙いたくなりますよね？
実際に OpenClaw は大規模なサプライチェーン攻撃も確認されており、
2026 年時点ではセキュリティリスクが非常に高いプロジェクトと言えます。
OpenClaw の脅威については以下の記事がとてもよくまとまっています。
新しい仕組みは別のセキュリティリスクを生む
これらの仕組みは効率化をもたらし、セキュリティリスクの改善にも貢献します。
OSS はバグや脆弱性に気付いた第三者が報告や修正をしてくれたりします。
GitHub Actions のタグ参照は、安定バージョンが自動的に反映されるため、手動更新より素早いです。
これらは、ある側面ではセキュリティリスクを下げる効果を持っています。
しかし、別のセキュリティリスクを同時に生んでいることを理解しなければいけません。
これもまたトレードオフです。
VPN ソフトのような、セキュリティソフトを導入することが、別のセキュリティリスクを生むケースと似ているかもしれません。
そして、新しい仕組みを導入したことで発生した別のセキュリティリスクに対策をしていない人が、被害を受けるのです。
予見できなかったのか、気づかない振りをしたのか
これらは予見できなかったことでしょうか？
いいえ、予見できたはずです。
OSS は赤の他人が大勢関わって作られています。
大量のライブラリが必要になるような複雑なプログラムの中に、一片たりとも悪意がないとは言えません。
npm ライフサイクルスクリプトや Python の setup.py は、
ニーズがあるのは分かる一方で使用するのにリスクがあります。
GitHub Actions も同様です。
OpenClaw は強力な自動化を可能とする一方、多くの権限を明け渡さなければいけません。
大いなる力には大いなる責任を伴います。
強い権限を明け渡すことは、その分だけリスクを背負うということです。
安全に使うには適切な運用設計・権限設計が必要です。
これらの道具はいずれも便利で効率的ですが、同時にリスクを伴います。
使う側はそのリスクに備える責任があるはずです。
例えば、以下のような対策ができるでしょう。
- 悪意あるコードが交じる前提で対策をする
- 秘匿情報をローカルに持たない
- コンテナ化
- ライフサイクルスクリプトの禁止
- ツールインストール時はチェックサムも検証をする
- バージョンをコミット SHA まで指定して使用する
- など
- 脆弱性情報を収集して、常にリスク評価をし続ける
- フルアクセス権限を発行するのではなく、必要最小限の権限とスコープを AI に渡す
言うなれば、こういった対策をできないならば、使うべきではないのです。
すべての対策をできなくとも、何の対策をしていて、何のリスクを許容するか理解していなければならないはずです。
しかしながら、きちんと対策をせずに便利さだけに注目して、リスクから目をそらして使う人が大勢いるから、被害がいつまでも減らないのです。
予見できなかったのではありません。
気づかない振りをしたのです。
これは発案者が悪いのではありません。
僕たちソフトウェアエンジニアの文化が、気づかない振りを後押ししたのです。
README に書かれているバージョン指定のない curl <URL> | bash を実行したり、
厳密なインストールバージョン指定ができない homebrew でツールをインストールしています。
それに、何の疑いももちません。
セキュリティを軽視する会社
セキュリティ軽視は何もソフトウェアエンジニアだけで起きている事象ではありません。
会社だってそうです。
効率を高める施策や新機能開発には関心が高い一方で、セキュリティ対策には関心が薄く、予算もあまり確保しない。
ゼロトラストと世間で広く言われるようになった一方で、いまだに VPN ソフトの運用ミスや脆弱性を突かれてインシデントになる事例が後を絶たない。
自社サービス会社も、SIer に発注する顧客も、セキュリティを過小評価しています。
2026 年にはいって、すでに 3 つも大規模なサプライチェーン攻撃が発生しています。
- 2026年2月28日 Trivy
- 2026年3月24日 LiteLLM
- 2026年3月31日 Axios
攻撃が成功してしまうリスクは、どんどん高まっています。
おそらくは、攻撃者側も AI などを駆使して高度化しているのでしょう。
こういった近年の重大インシデントの傾向を踏まえて、セキュリティ予算を増加する企業が増えたとの調査結果もあります（Assured調べ）。
ですが、セキュリティインシデントはここ数ヶ月や 1 年で起きたものではありません。
SolarWinds サイバー攻撃（2020年）、Log4j 脆弱性（2021年）、XZ Utils バックドア（2024年）など以前から様々な攻撃やインシデントが報告されています。
もっと早く対策に臨む機会があったはずです。
セキュリティインシデントが発生してしまったとき、その影響は単にサービス停止で済む話ではありません。
ブランドイメージを毀損し、ユーザの情報を危険にさらし、あらゆる関係者に多大な被害をもたらす。
「もしも」が起きたときの影響は計り知れません。
にも関わらず、セキュリティは蔑ろにされています。
当たり前品質は話題にならない
こういったセキュリティや可用性は、当たり前品質と呼ばれます。
あっても満足度はあまり上がらないが、ないと不満が高まる要素です。
そして、その対となるは魅力的品質です。
便利な機能、美しい UI などは魅力的品質です。
この 2 つの品質を比較したとき、当たり前品質は話題になりにくいです。
新サービス・新機能リリースといった情報は大々的に発表される一方で、
何十年もインシデントを起こさず安定して提供できているサービスには光も当たりません。
楽天が大規模な通信障害を起こしたときは大々的にニュースに取り上げられる一方で、
大きな障害を起こしていない他の通信事業者はニュースにすらならない。
ユーザの関心は「安定して使える」ことにないのだとするならば、なんと虚しいことでしょうか。
ユーザに関心を持たれないのであれば、予算が取られず、開発されないのも、当然の帰結と言えるでしょう。
目に見える生産されたものばかりが、人々の関心を集めるのです。
生産性という麻薬
僕はこの生産性至上主義の現状を「生産性という麻薬」と呼びたいです。
生産性に取り憑かれて危機意識を失い、セキュリティという法律を蔑ろにし、顧客価値という免罪符のもとで物づくりに励む。
開発ロードマップにはセキュリティ対策は並ばず、起案されても優先度を落とされて何年も放置される。
そして大規模な問題が発生してからようやく検討し始めるのです。
セキュリティ対策がほとんど評価に反映されない一方で、新機能リリースは高く評価されて利益を生む。
高い可用性を実現しても、厳密な統制管理の元で安全でセキュアな開発・運用をしても、感謝はされず話題にもならない。
そんな環境で誰がセキュリティを守るというのでしょう？
生産性は、非常に強力なインセンティブです。
会社も、ユーザも、僕たち開発者も生産性に囚われています。
10 倍の生産性は 10 倍の価値を生むわけではない
AI の登場によって、コードを生成する速度は飛躍的に上昇しています。
ですが、仮に生産性が 10 倍になったとして、10 倍の価値を生み出しているのでしょうか？
生産速度が 10 倍になるということは、ゴミを生み出す速度も同様に早くなるということです。
強豪ひしめく IT 業界では、開発速度は非常に重要です。
しかし、サービスの供給速度が上昇する一方で、消費者の消費速度や物理法則という限界は変わりません。
供給が無限に増え続ければ、相対的に個々の物の価値は失われます。
見た目だけの供給ばかりが増えた先に待っているのは、価値のないゴミの山だけです。
N 日で M 万行のコードを実装した。
こういったキャッチーなメッセージの裏で、生成されたコードはユーザに価値を届けられているのでしょうか？
生産性は手段であって目的ではない
僕は生産性を高めるなと言いたいわけではありません。
今の時代で、OSS や AI ツールを使わずに全部手書きで実装するなどしていたら、他社に置いていかれて死ぬだけです。
ただし履き違えてならないのは、生産性は手段であって目的ではないことです。
- ユーザにこの機能を素早く提供したい
- ユーザからのフィードバックをすぐにサービスに反映して改善したい
- サービスに異常が発生したら即座に切り戻したい
といった、様々な目的を実現するための手段の 1 つが、生産性の向上なのです。
「ユーザに価値を届ける」という目的を果たしてこそ、初めて生産性は意味をなすのです。
生産する行為自体には、なんの意味もないのです。
ユーザの役に立たない機能を増やすことは、ユーザの価値になるでしょうか？
動くけれど脆弱性だらけのサービスを提供して、ユーザは喜ぶでしょうか？
答えは否です。
これらはただ害悪なだけです。
ユーザ体験を悪くし、ユーザの情報を危険に晒し、会社の信用を失わせます。
提供しない方がマシです。
作ることは、常に正の影響を与えるとは限らないのです。
さて、生産性という数字だけを高らかに謳う人々は、果たして価値のあるものを生み出しているのでしょうか？
作るだけが価値ではなく、作らない価値もまたあることを理解しているのでしょうか？
生み出して終わりではなく、運用し続けるという価値を創出しているのでしょうか？
ただ見栄えが良いハリボテを作るだけの行為を、価値の創出と誤認していないでしょうか？
そうした生産性という数字だけに囚われた果てにあるのは、破滅だけです。
安定運用という見えない価値を軽視する僕たち
ところで、僕たちが毎日使っている電気、ガス、水道、インターネットというライフラインは、常に安定して利用できています。
それに感謝したことはありますか？
例えば水道です。
蛇口をひねってすぐに飲める衛生的な水が、いつでも手に入る国は少ないです。
安定して使えることは、何事にも代えがたい価値なのです。
その裏にどんな苦労があるか考えたことはありますか？
きっと、ないのでしょう。
物理インフラという身近なものにすら価値を感じない僕たちが、
ソフトウェアという実態のないものに価値を感じるはずがありません。
安定運用に感謝をしないならば、同様にセキュリティ対策にも感謝しないでしょう。
そして、十年後も、百年後も僕たちは変わらないでしょう。
生産性という麻薬で身を滅ぼすそのときまで。
]]>
