ハクソク

世界を動かす技術を、日本語で。

Cal.comがクローズドソースに移行します

2026年4月16日原文(cal.com)

概要

  • Cal.comは オープンソース から クローズドソース への移行を発表
  • 主な理由は AIによるセキュリティリスクの増大
  • AIが 脆弱性発見 を加速し、攻撃リスクが高まっている現状
  • 一部コードは MITライセンス でCal.diyとして公開継続
  • 将来的な オープンソース復帰 の可能性も示唆

Cal.comのクローズドソース移行に関する声明

  • Cal.comは 創業当初からオープンソース を重視した企業理念
  • しかし、 AI技術の進化 によりセキュリティ状況が大きく変化
  • 従来は 高度なハッカー が長時間かけて脆弱性を発見・悪用
  • 現在は AIがオープンソースコードを自動スキャン し、脆弱性を迅速に特定
  • オープンソースは 攻撃者に設計図を渡す ようなリスク増大
  • AIセキュリティ企業が 脆弱性発見の自動化サービス を提供
  • 各プラットフォームごとに脆弱性の発見内容が異なり、 信頼できる基準の不在
  • この不確実性により「 オープンソース継続によるリスク受容」か「 クローズドソース化によるリスク低減」の選択を迫られる
  • ユーザーと顧客データ保護のため、 クローズドソース化を決断

オープンソースへの思いとCal.diyの公開

  • オープンソースへの情熱 は失われていないことを強調
  • MITライセンス でCal.diyバージョンをコミュニティ向けに公開
  • 本番環境コードベースは 大規模なリファクタリング を実施済み
  • Cal.diyは 開発者・ホビイスト・実験志向ユーザー向け に提供

AIとセキュリティリスクの急速な変化

  • 先進的なAIモデル は脆弱性発見スピードを飛躍的に向上
  • 例として、AIが BSDカーネルの27年前の脆弱性 を数時間で発見・悪用コード作成
  • オープンソース継続は アプリケーション・顧客・機密データ すべてに重大なリスク
  • あらゆる手段でリスク低減 を図り、現時点ではクローズドソース化が最善と判断

今後の展望

  • 将来的なオープンソース復帰 も視野に入れていることを明言
  • 現時点では 顧客保護を最優先 とする方針

Hackerたちの意見

これってなんか変な反応だね。セキュリティの決定ってより、ビジネスの決定って感じがする。AIのおかげで、自分でホスティングするソフトウェアが信頼性高くなってきてるから、OSSプロジェクトのホスティングサービスにお金を払うインセンティブが減ってきてる気がする。

└

AIは確かに悪いことをするための言い訳としてかなり使われてるね。スタッフを大量に解雇したい？ - AI 消費者製品部門を切りたい？ - AI ソースを奪いたい？ - AI

└

彼らの製品はコモディティ化が進んでるね。

└

うーん、納得いかないな。もしセキュリティレポートが欲しくないなら、無視して自分たちの道を進めばいいじゃん。AIを責めるのは、ソースを閉じるための言い訳に過ぎないよ。もしAIに自分たちのコードを学ばせたくないなら、もう手遅れだよ。遺伝的アルゴリズムやファジングをAIに組み込めば、何百万倍も早く学習できるから、人間が学ぶ必要なんてないんだ。

└

人々は「プロ」機能を有効にしたり、LLMを使ってそれを簡単に実装するための適切な拡張ポイントを見つける方法を見つけていると思う。セキュリティは見せかけに過ぎないよ。

その考え方はわかるけど、なんか「隠れていることで安全」みたいな感じがする。いつからそれが正しいモデルだって決めたんだろう？

└

ここに共同創業者がいるよ。隣の16歳の息子が、君のオープンソースプロジェクトをハックするのに15分と100ドルのClaudeコードクレジットがあればできるってさ。

└

これは隠蔽によるセキュリティじゃなくて、攻撃面をできるだけ減らすことだよ。

└

不明瞭さによるセキュリティは、それが唯一の防御層、または主要な防御層である場合に問題になるだけだよ。徐々に抑止力や遅延を加える層としては、全く有効な戦術だと思う。（ここでの理由についてはコメントしないけどね。）

これ、ちょっとクレイジーだね。LLMがコードの脆弱性を見つけるのがそんなに得意なら、コミットした後、リリースする前に自分のコードに対してLLMを走らせるのが解決策じゃない？そうすれば、公開する前にペンテスティングの準備ができるし。もしLLMが欠陥を見つけられなければ、そのコードをリリースしても大丈夫ってことだよね。数年前、教室でリーナスの法則を持ち出したら、みんなに否定されたんだ。今やLLMによってそれが実現されてしまったのは残念だよね。 https://en.wikipedia.org/wiki/Linus%27s_law

└

LLMが見つけた問題を全て解決して「全てグリーン」の反応を得ることは十分可能だけど、それでも攻撃者がLLMが見つけられなかった問題を見つけることがある。彼らは別のモデルを使ったり、違うプロンプトを使ったり、君より多くのお金を使ったりするかもしれない。これは対称的なゲームじゃないんだ。防御側は毎回運が必要だけど、攻撃者は一回だけ運が良ければいいんだから。

└

もちろん、出荷する前にLLMによる監査はある程度必要だよね、一般的なPRプロセスの一部として。でも、脆弱性を見つけるためには何千回もセッションが必要かもしれないし、セキュリティチェックに時間がかかって変更を出荷するのを止めたくはないよね。

Hacker Newsで議論の続きを見る