次郎の貝塚

技術ブログのような何か

About | Profile | Source Code | RSS

投稿日時 2026-04-19 17:19:00 +0900 | カテゴリー 雑記

前の記事 2025年振り返り | 次の記事

生産性という麻薬

なんとなく、ここのところの 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 は多く存在します。 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 を呼び出す際にタグを参照する方法が一般的に根付いています。 以下のように、@v60.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 は、信頼が崩れたときに破綻する。 でも他人が作った OSS をいきなり信頼できますか? フリーマーケットで見ず知らずの人が「自作の超便利な Android アプリを作ったのでインストールして使ってください!」と言われていて、それを自分の端末にインストールできますか? 目の前の見ず知らずの人が信頼できる人だったとして、明日同じフリーマーケットで別の人に会ったとして、その人も信頼できるのでしょうか?

npm ライフサイクルスクリプトや Python の setup.py は、ニーズがあるのは分かる一方で明らかに危険なことは言うまでもありません。 GitHub Actions も同様です。 OpenClaw なんてコンセプトの時点でセキュリティリスクしかないと思っています。

しかし、それでも人々はこれらを利用します。 もちろん、きちんとリスクを理解して、対策をして利用している人もいるでしょう。 ですが、多くの人は効率や便利さだけに注目して、リスクから目をそらしているのです。

予見できなかったのではありません。 気づかない振りをしたのです。 これは発案者が悪いのではありません。 僕たちソフトウェアエンジニアの文化が、気づかない振りを後押ししたのです。

生産性という麻薬

僕はこの生産性至上主義の現状を「生産性という麻薬」と呼びたいです。

生産性に取り憑かれて危機意識を失い、セキュリティという法律を無視し、顧客価値という免罪符のもとで物づくりに励む。 生産性や効率化を目指して、あらゆるリスクを過小評価して実装し、後追いで問題が起きてから対処する。

会社は効率を高める施策には関心が高い一方で、セキュリティ対策には関心が薄く、予算もあまり確保しない。 ゼロトラストと世間で広く言われるようになった一方で、いまだに VPN ソフトの運用ミスや脆弱性を突かれてインシデントになる事例が後を絶たない。 自社サービス会社も、SIer に発注する顧客も、セキュリティを過小評価しているのです。

新サービス・新機能リリースといった情報は大々的に発表される一方で、何十年もインシデントを起こさず安定して提供できているサービスには光も当たらない。 楽天が大規模な通信障害を起こしたときは大々的にニュースに取り上げられる一方で、大きな障害を起こしていない他の通信事業者はニュースにすらならない。 ニュースにならないのが「安定して使えることは人々の関心事でないから」だとするならば、なんと虚しいことでしょうか。

ユーザが「安定して使えること」を価値ではなく当たり前と認識してしまうのであれば、 供給者が生産性という麻薬に取り憑かれてしまうのも当然の帰結なのでしょう。

10 倍の生産性は 10 倍の価値を生むわけではない

AI の登場によって、コードを生成する速度は飛躍的に上昇しています。 ですが、仮に生産性が 10 倍になったとして、10 倍の価値を生み出しているのでしょうか? 生産速度が 10 倍になるということは、ゴミを生み出す速度も同様に早くなるということです。

強豪ひしめく IT 業界では、開発速度は非常に重要です。 しかし、サービスの供給速度が上昇する一方で、消費者の消費速度や物理法則という限界は変わりません。 供給が無限に増え続ければ、相対的に個々の物の価値は失われます。 見た目だけの供給ばかりが増えた先に待っているのは、価値のないゴミの山だけです。

僕は生産性を高めるなと言いたいわけではありません。 今の時代で、OSS や AI ツールを使わずに全部手書きで実装するなどしていたら、他社に置いていかれて死ぬだけです。 ここで重要なのが、生産性は手段であって目的ではないことです。

といった、様々な目的を実現するための手段の 1 つが、生産性の向上なのです。 「ユーザに価値を届ける」という目的を果たしてこそ、初めて生産性は意味をなすのです。 生産する行為自体には、なんの意味もないのです。

ユーザの役に立たない機能を増やして、何の価値があるでしょうか? 動くけれど脆弱性だらけのサービスを提供して、ユーザは喜ぶでしょうか?

答えは否です。 これらはただ害悪なだけです。 ユーザ体験を悪くし、ユーザの情報を危険に晒し、会社の信用を失わせます。 提供しない方がマシです。 作ることは、常に正の影響を与えるとは限らないのです。

さて、生産性という数字だけを高らかに謳う人々は、果たして価値のあるものを生み出しているのでしょうか? 作るだけが価値ではなく、作らない価値もまたあることを理解しているのでしょうか? 生み出して終わりではなく、提供し続けるという価値を創出しているのでしょうか? ただ見栄えが良いハリボテを作るだけの行為を、価値の創出と誤認していないでしょうか?

そうした生産性という数字だけに囚われた果てにあるのは、破滅だけです。

安定運用という見えない価値を軽視する僕たち

ところで、僕たちが毎日使っている電気、ガス、水道、インターネットというライフラインは、常に安定して利用できています。 それに感謝したことはありますか?

例えば水道です。 蛇口をひねってすぐに飲める衛生的な水が、いつでも手に入る国は少ないです。 安定して使えることは、何事にも代えがたい価値なのです。 その裏にどんな苦労があるか考えたことはありますか?

きっと、ないのでしょう。 物理インフラという身近なものにすら価値を感じない僕たちが、 ソフトウェアという実態のないものに価値を感じるはずがありません。

そして、十年後も、百年後も変わらないでしょう。 生産性という麻薬で僕たちが身を滅ぼすそのときまで。

前の記事 2025年振り返り | 次の記事