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