Scribble at 2026-07-15 12:52:35 Last modified: unmodified

上に添付したのは、シカゴにある AI 導入コンサルティングなどを手掛けている企業のサイトで公開されているブログ記事だ。生成 AI の活用をサービスの主軸にしているが、自社のエンジニアによるブログ記事だけでなく、研究論文なども積極的に作成して公開しており、多くのスタッフが O'Reilly Media や Springer Nature から著書を出している。Hacker News でブログ記事の一つが取り上げられていたので、あまり upvote は増えていないようだが、ここでもご紹介しておこう。

この記事は、現代のオープンソース・ソフトウェアが直面している構造的な疲弊と、生成 AI の普及による危機の加速について論じている。デジタル資産の複製や配布にかかるコストは実質的にゼロであるという「ゼロ・コストの誤謬」により、ソフトウェアの維持管理にかかる莫大な人的コストが長年にわたって軽視されてきた。この主張は、ウェブサイトの運営やサーバの運用、あるいは情報セキュリティだとか個人データの管理などのコストも、ウェブ制作会社やネット・ベンチャーですら軽視されてきたという僕の批判とも認識が一致している。その結果、多くの保守担当者が無報酬で過酷な労働を強いられる一方で（事実、グロスで何十億というプロジェクトの電通案件ですら、サーバの保守費用なんて出ないし、見積もりに計上する習慣すらウェブの業界にはない。なぜなら、弊社では僕が20年も説得したり教育して、ようやくまともなレベルになったが、大半のウェブ・ディレクターがサーバの保守という業務を理解していないからである）、巨大企業が寛容なライセンス・モデルにタダ乗りして成果を一方的に搾取し、利益を上げるという持続不可能な状態が常態化している。これはアメリカの実情だが、日本でも DevOps なんてフレーズは単なる流行語でしかなく、実際にはそんな職能が確立している会社なんて一部の外資系だけだ。

さらに記事は、AI エージェントの台頭がこの状況を悪化させているという。コードを自動生成するハードルが極端に下がったことで、低品質なコードが AI フロップとして大量にリポジトリへ PR (pull request) されるようになり、コードの保守担当者は本来の開発作業ではなく、そのコードのレビュー作業に忙殺されるようになった。精神的な負担からプロジェクトへの新規貢献を締め切るケースも発生しており、これが次世代の保守担当者を育成する機会を奪っていて、AI への依存を助長する悪循環が生じる恐れがある。また、AI の流行に乗じて、短期間で人気を集めるプロジェクト（ChatGPT への API 接続を提供する単なるフロント・エンドを「新サービス」と言い張るガキが Hacker News にも増えていた時期がある）や、悪意のある投稿が安価に行えるようになったことで、これまでのソフトウェアの信頼性を担保してきた評価の指標も機能しなくなりつつある。

ライセンスの観点から見ると、ソフトウェアを広く普及させるために採用されてきた寛容なライセンスが、結果的に企業による搾取を助長した。その一方で、商業利用を制限する独自のライセンスへ移行しようとすれば、企業の調達プロセスにおける管理上の障壁や意図的なボイコットに直面し、コミュニティからの敵対的な反発も招くというジレンマがある。現状は、公共の資源が枯渇していくコモンズの悲劇 (tragedy of the commons) に例えられることがあるが、実際には自然発生した資源ではなく、コミュニティの善意によって築かれたリソースなり資産を、商業的な動機を持った企業が大規模に引き出しているという非対称性が問題の本質だ。確かに、Go や TypeScript は優れた処理系かもしれないし、Google や Microsoft がオープン・ソースのコミュニティで一定の役割を果たしている事実もあろう。でも、こういう大状況を考えると、やはり Go や TypeScript を哲学者でもあるエンジニアの僕が自分の道具として習得したり使うというのは、いかにも躊躇してしまうわけである。

こうした重圧に対する一つの対策として、外部のコードに依存してサプライ・チェーンのリスクや保守の負担を直接負うのではなく、仕様やアイデアのみを参考にして AI に必要なルーチンやアルゴリズムを局所的に生成させるという新しいアプローチも現れている。ただし、この方法は暗号化ライブラリなどの複雑なシステムには限界があり、元の保守担当者に対するクレジットや動機付けを奪ってしまいかねないというリスクも指摘されている。結論として、ブログ記事の著者はエンジニアリング組織に対して受動的な消費者であることをやめるよう警告している。依存するコードに対して能動的な所有権を持ち、サプライ・チェーンの厳格な監査を実施するとともに、事業の基盤を支えているプロジェクトに対して、単なる慈善事業ではなくリスク軽減の不可欠なプロセスとして公式な資金援助を行うことが、今後の時代を生き抜くために求められているという。

実際、僕は特に日本のオープン系ベンダーには強い不満を持っている。正直、日本の開発系ベンチャーの 99 % は単なるクレクレ君にすぎず、自社で利用しているツールや処理系のコミッターやメンテナーとして参加したり、あるいは協賛金を支出するといったことをしない。かといって、自力で何かオープン・ソースのツールを開発して公開するでもなく、そういう意味では都内でカスみたいなイベントだけはせっせと繰り返し、とりわけ IT ゼネコンと子会社の連中は「ロック・スター」のエンジニアに講演させたりして国内でのパブリシティやポジション・トーク、あるいは官公庁との癒着には熱心だが、有名なプロジェクトの「ユーザ会」と称するものを派手に立ち上げては10年もしないあいだに次々と消滅させたりゾンビ化させている。都内のエンジニアがやってることなんて、せいぜい Qiita や note などで学術的にもレベルの低い（そらそうだ。日本の開発ベンダーのエンジニアなんて修士すらもってないんだから）話題のツールのインストール手順を解説するといった愚にもつかない記事を量産するしか能がない、はっきり言って AI 以下のコンテンツしか書けないゴミだ。