オープンソースの「甘いわな」 その自由がもたらす“不自由な現実”：OSSの“理想と現実”

無償で利用でき、ベンダーロックインを回避できるOSSの人気が高まっているが、業界の専門家は、過剰な期待は禁物だと警告する。その背景にはどのような問題があるのか。

[Aaron Tan，TechTarget]

　2025年5月末にシンガポールで開催されたカンファレンス「ATxEnterprise」において、オープンソースソフトウェア（OSS）がテーマとなったパネルディスカッションが行われた。OSSの可能性について壇上で議論が交わされたが、業界のリーダーたちはOSSに対する無邪気な期待にくぎを刺し、導入の際の注意事項とその対策について語った。

　オープンソースデータベースベンダーPingCapのチーフアーキテクト、サニー・ベインズ氏は、企業間でOSSの採用が進んでいる主な理由として、無料で提供されていること以外に、“コントロールのしやすさ”を挙げる。プロプライエタリ（ソースコード非公開の商用製品）なソフトウェアの場合、ユーザー企業はベンダーに縛られがちだが、OSSにはそれがない。

　ベインズ氏は、「全てのプログラムのソースコードを公開し、コピー、改変、再配布を許可するべきだ」という“自由ソフトウェア運動”を推進したリチャード・ストールマン氏の有名なエピソードを引き合いに出す。「ストールマン氏は、不具合を起こしたプリンタのデバイスドライバ（制御ソフトウェア）を自分で修正しようとしたが､ソースコードが非公開だったためにそれができなかった。このことから分かるように、ソースコードが公開されているOSSには、ユーザー企業自らが問題をすぐに修正できるという大きな利点がある。ベンダーのパッチ（修正プログラム）配布を待つ必要がない」と語った。

　しかし、OSSには以下で挙げる課題があり、適切なコントロールを欠けば、重大な問題を引き起こす。

OSSの“見過ごせない”問題点とは？　対策は？

チェックが不可欠

　オープンソースのAPI（アプリケーションプログラミングインタフェース）ゲートウェイを提供するKongのエンジニアリングエグゼクティブ、サジュ・ピライ氏は次のように語る。「プロプライエタリソフトウェアは、ベンダーの保証やセキュリティが組み込まれた“製品”だ。しかしOSSは、あくまでも有志による“プロジェクトの成果物”なので、そのままの使用や再配布にはリスクがある。ソースコードに問題があったり、顧客の暗黙の期待に沿っていなかったりすれば、ユーザー企業や公共インフラに深刻なダメージを与える可能性がある。本番環境に投入するには、チェックや改良のための多大な労力が必要だ」

　ソフトウェアのリライアビリティー（信頼性）テストツールを提供するWatermelon SoftwareのCTO（最高技術責任者)、ハルプリート・シン氏は、OSSを導入する場合、リスク軽減のために、結合テスト（複数の機能やコンポーネントを組み合わせたときの動作テスト）や、スケーラビリティ（拡張性）と信頼性のテストなど、多層的な検証の仕組みが必要だと語る。「全てのテストをクリアできなければ、悪用されかねない脆弱（ぜいじゃく）性の懸念を払拭できない」と警告する。

規制の厳しい業界での制限

　インドの銀行IDFC FIRST Bankで、生成AI（AI：人工知能）部門のチーフマネジャーを務めるシュバム・アグニホトリ氏は、銀行のような規制の厳しい業界でのOSSの使用は困難だと指摘する。「金融機関は、コンプライアンスやセキュリティ上の要件が多いので、OSSをそのまま使うことは不可能だ。改良のための膨大な作業が必要になる」

　対策として、Kongのピライ氏は、OSSで十分なのか、ベンダーからのサポートが組み込まれたOSSを基にした商用版の方がいいのか、事前の検討を企業に勧める。

ライセンス

　 別の課題がライセンスだ。シン氏は「利用するオープンライセンスについてしっかり理解しておくべきだ」と語る。同氏は、Watermelon Softwareが提供するツールの中核だったOSSのライセンスが変更されてしまい、やむを得ず古いバージョンを使用した経験を紹介した。

　対策として、シン氏は「OSSを採用する場合、アーキテクチャと設計に、不測の事態に対応できるだけの柔軟性を持たせる必要がある」と語る。そして、こうしたリスクに対する“保険”として、商用版の使用を勧める。

　別の対策として、ピライ氏は、OSSのライセンスを精査する仕組みの導入を勧める。Kongでは、開発者がライブラリ（プログラムの部品群）を導入して、ソフトウェア部品表（SBOM）が変更された場合、関連するライセンスについて法務およびコンプライアンスチームが精査する仕組みがあり、承認なしでは使用できないという。

　ベインズ氏は、ライセンスを“地雷”に例え、慎重な取り扱いの必要性を強調し、PingCapが取った対策を紹介した。同社はライセンスのトラブルを避けるために、提供する製品の中核だったストレージ技術をオープンソースソフトウェア管理団体Cloud Native Computing Foundation（CNCF）に寄贈したという。これは、特定の企業にライセンスを握られないための逆転の発想とも言える。

併せて読みたいお薦め記事

オープンソースのメリット

• いまさら聞けない「オープンソースデータベース」の定義とメリット
• 企業が“シングルベンダー”ではなく「マルチクラウド」を信奉し始めた理由

生成AIの影響は？

　生成AIがOSSに与える影響についても話題として取り上げられた。パネリストたちは、生成AIの有用性を認めつつも、安易に信頼するのでなく、ソースコード検証の必要性を強調した。

　シン氏は次のように語る。「AIモデルが事実に基づかない回答を出力するハルシネーションの可能性がある以上、絶対的な信頼はできない。AIが生成したソースコードには、その機能を保証する何らかの追加の仕組みが必要だ」

　アグニホトリ氏は、単一のコードベースで構成されたモノリシックアーキテクチャのソフトウェアを、生成AIを使ってマイクロサービス化（疎結合で独立した部品に分割する）した自身の経験を紹介した。「ソースコードの見た目は本当に美しかったが、ソフトウェアとしては使えなかった。生成AIは開発者の代替となるレベルに達していない」と語る。

　ピライ氏は、AIによって開発者の役割が変化すると予想する。「ソースコードを書くのではなく、AIが書いたソースコードのレビューを担当するようになるだろう」と語る。

　ベインズ氏もそれに同意する。「PingCapはAIを活用して質問に答えるサポートチームの負担を軽減している。AIが最前線に立つのではなく、一歩引いたサポート役を担う。プログラミングにおいてもそうなるだろう」

　最終的に、パネリストたち全員が、OSSはソフトウェア開発とイノベーション創出の原動力ではあるものの、導入時の落とし穴を回避するためには、デューデリジェンス（適正な評価手続き）、ライセンス、セキュリティ、継続的な管理への投資が必要であるとの結論で一致した。

翻訳・編集協力：雨輝ITラボ（株式会社リーフレイン）