なぜソフトウェア業界には多くの規制が必要なのか

Why the software industry needs a lot of regulation

［画像: チャットGPTの画像、2026年9月10日 03:00:14 PM］

構造エンジニアは、承認した設計図に物理的な印鑑を押しますが、設計上の問題で建物が倒壊した場合、彼らは直接的かつ個人的な責任を負います。一方、ソフトウェアエンジニアは、数百人もの命を奪う可能性のあるコードをデプロイしても、それに見合うレベルの責任を負うことはほとんどありません。なぜこれが正しくなく、持続可能でもないのか、その理由を説明します。

規制は血によって書かれると言われますが、1928年にセントフランシスダムの崩壊で約400人が死亡するまで、カリフォルニア州では土木技師の免許制は義務化されませんでした。ソフトウェアの設計上の欠陥はすでにそれ以上の犠牲者を出しており、未来は私たちの仕事をさらに危険なものにするでしょう。すでにロシアによるウクライナ侵攻では、自律型ドローンが誰を殺すかについてソフトウェア駆動の意思決定を迫られており、コードが今後の戦争の大きな部分を占めることは明らかです。AIモデルも、ほぼすべての産業で安全クリティカルなシステムに不可欠なコンポーネントになりつつあります。それらが意識を獲得するという終末論的な予測には懐疑的ですが、犠牲者は、災害の原因が悪意のあるスカイネットであれ、単に無能なエンジニアリングであれ、気にしないでしょう。

すでに多くの血が流れており、今後も流れるでしょう。それなのに、なぜソフトウェアエンジニアリングはこれまでのところ規制を免れてきたのでしょうか？ここにいくつかの障壁があります。

• ダムを建設するよりも、コードを書き始める方がはるかに簡単です。米国には約200万人のソフトウェアエンジニアがいるのに対し、土木エンジニアは約20万人です。多くのコーダーは独学で、正式な資格を持っていません。ソフトウェアエンジニアリングの実践者を制限することは機能しません。
• ソフトウェアには物理的な場所がありません。橋は一箇所に建設されるため、当局はそこで起こっていることを非常に簡単に観察・制御できます。コードやモデルは世界中のどこでも作成でき、同様にグローバルに展開されるため、どの国にも明確な管轄権がなく、ましてやその国境内でどのようなソフトウェアが展開されているかを知る方法もありません。
• ソフトウェアエンジニアリングは、非常に協調的で反復的なプロセスです。ユーザーのニーズについて学び、さまざまな目標を最適化するにつれて、システム設計は常に進化しています。高層ビルには、建設が始まる前に合意された設計があり、変更はまれで軽微であるため、建設プロセスを遅らせることなくチェックできます。私たちの業界に同じ土木工学のワークフローを適用する実用的な方法はありません。従うべき簡単なテンプレートがありません。
• 大手テクノロジー企業でさえ、エンジニアは重要な安全決定を下す権限を持っていません。経営者が致命的な欠陥のある自動運転ソフトウェアを出荷したい場合、彼らはあらゆる反対意見を却下できます。あなたが立ち上がって辞職したとしても、経営者は誰でも他の誰かを雇うことができ、経営者にも新しいエンジニアにも何の責任もありません。
• 多くのソフトウェアプロジェクトには、単一の明確な所有者がいません。オープンソースフレームワークにはレビュー担当者のチームがいる場合があり、商用コードベースは時間の経過とともに多くの手を経由します。権限のこの分散により、問題が発生した場合に誰が責任を負うのかを判断するのが困難になります。
• 私たちの業界の文化は非常に個人主義的です。私たちは「速く動いて、物事を壊す」ことを重視しており、シリコンバレーは世界を支配するソフトウェア企業を構築することに非常に成功してきたため、その精神の成功に反論するのは困難です。私たちは長い間、私たちがアンダードッグであるという認識から恩恵を受けてきました。社会は私たちの行動の負の結果を広く許容してきました。

これらすべてが、どのような規制も非現実的であることを意味するのでしょうか？私は、長期的には私たちの仕事に対して責任を問われることになるだろうと確信しています。そして、問題は、私たちが主導権を握って自分たちで何かを始めるのか、それともその機会を逃して外部の人々によってルールを決定されるのか、ということだけだと考えています。データセンターに対する超党派の反発を見れば、テクノロジー企業が私たちが慣れ親しんできた公衆からの寛容さを失っていることは明らかです。過去に私たちを守ってきたロマンチックな神話がその力を失えば、私たちは他のどの業界と同じように規制されるでしょう。

私は、イノベーションを窒息させることなくリスクを軽減するフレームワークを構築する機会があると信じていますが、私たちの時間は急速に失われています。具体的なステップとして、以下を提案します。

• 米国のほとんどのコンピュータサイエンスの学位には、倫理に関する必須のコンポーネントさえありません。ましてや倫理規定への同意はありません。あなたの力を善のために使うことを誓うことは強制できませんが、少なくとも卒業時にこれを義務付ければ、誰も警告されなかったと言うことはできないでしょう。
• 外からの圧力なしに、私たち自身で認められた専門的な認定構造を確立できるはずです。強制される必要はありませんが、卓越性の証として、またシニアエンジニアリング職にとって望ましいものとして宣伝できるだけで、かなりのソフトパワーを与えることができます。可能性の一つは、すでに多くのものを提供しているACMを直接利用することです。
• ソフトウェア業界全体に新しい規制を導入してすべてを解決しようとするのではなく、健康や運輸など、すでに強力な規制がある分野で、私たちが望むルールのプロトタイプを作成することから始めることができます。
• ソフトウェアプロジェクトには単一の明確な所有者がいるべきだというプロフェッショナルな規範を確立したいと考えています。その所有者は、安全に影響を与える決定を拒否する権限を持つべきです。通常はテックリードです。これが機能することは知っています。Appleでは、どんなに小さなタスクや問題であっても、直接責任者（DRI）がいました。所有エンジニアを再割り当てしたり解雇したりするのを経営者に止めさせることはできませんが、結果を確実にすることはできます。例えば、所有エンジニアが広く認識されている倫理規定を参照して異議を申し立てたことを記録できれば、会社に対する将来の訴訟が成功する可能性が高まります。訴訟による規制は私の好むアプローチではありませんが、それがアメリカのやり方です。
• 航空業界にはASRSがあります。これは安全インシデントを匿名で報告する方法であり、NASAはそのデータを使用して危険なパターンや傾向を特定します。ソフトウェアのために同様のシステムを確立することは価値があるでしょう。特に、内部告発者保護を備えた匿名性が保たれれば、危険なパターンや傾向を特定し、安全ガイドラインをデータに基づいて積極的に策定し始めることができます。
• ソフトウェアはグローバルかもしれませんが、収益はローカルです。安全に関心のある多くの大組織は、ソフトウェアに多額の費用を費やしています。もし彼らが購入する製品に品質基準を要求すれば、多くのサプライヤーがそれらを実装するでしょう。これは、最大の購入者の多くが政府部門にいるため、明確な政治的推進力が必要になります。

これが正しいロードマップかどうかはわかりませんが、自分たちで提案を考え始めなければ、すぐに業界外の人々が考え出すルールに翻弄されることになるだろうということはわかっています。私は安全性を最も明白な危険として対処すべきことに焦点を当てましたが、ソフトウェアとAIはあらゆる種類のことに計り知れない影響を与えています。例えば、ソーシャルメディアが政治にどれほどの影響力を持っているかを見ることができます。Metaが反ICEメッセージを抑制することを決定した場合、それらのシステムに関与するエンジニアがどのように行動すべきかについての明確な期待があることを望みます。

前進するための最善の方法について個人的な考えはありますが、それらはほぼ間違いなく間違っているか、少なくとも大幅に改善される可能性があります。規制は、より広いコミュニティによって推進されるものでなければなりません。だからこそ、私は最近、テクノロジーが公共の利益のために構築できると信じ、そのために協力する意思のある人々（エンジニア、創業者、デザイナー、経営者、投資家）を結集するAlliance for Principled Techの設立を支援しました。もしあなたがそう思うなら、ぜひご参加ください。

私たちは、これらのシステムがどのように構築されるのか、そして私たちの社会の方向性を静かに決定するアーキテクチャ上の選択が何であるかを知っています。私たちが構築したいルールと、私たちが支持したい価値観を明確にし、協力することが急務です。