AnthropicのScion、Mononokeを意図的に盗用していたと内部告発

More on Anthropic's Scion ripping off Mononoke

AnthropicのScion、Mononokeを意図的に盗用していたと内部告発

AnthropicのScionがMononokeのBonsaiデータモデルを意図的に盗用していたと、元開発者が内部情報を基に告発。changesetの構造や用語まで酷似し、Scionという名称もBonsaiの音節を逆にしたものだと指摘。クレジット表記の欠如が問題であり、コピー自体は許容されるが、意図的な盗用は看過できないとしている。

ScionがMononokeに意図的かつ露骨に盗用したという確認を非公開で得た。特に人員の重複があった。これは意図しないオマージュであるはずがない。
  1. nickg-anthropic

    こんにちは!ブログ記事の原著者です。ここで少し誤解を解いておきたいと思います。

    Saplingとクレジットしたのは、Meta自身がMononokeサーバーを含むシステム全体を外部向けにそう呼んでいるからで、その慣習に従いたかったからです。これを明確にするため、脚注を追加します。[編集: 対応済み]

    Scionを作る際には多くのものからインスピレーションを受けており、たとえばMononokeのBonsaiデータモデルにある優れたアイデアもその一つで、それを曖昧にする意図はまったくありませんでした。また、https://martin.kleppmann.com/2015/03/04/turning-the-database... からも強く影響を受けており、たとえばこれは「derived data」という概念を同じ言葉で説明しています。

    また、単にClaudeにバージョン管理システムを作らせたわけではありません。私たちのユースケースで何が機能し何が機能しないかについて多くの調査を行い、既存の大規模なGitリポジトリから来たこと(MononokeのようにMercurialからではない)により、これらのデータ構造のいくつかを超えた多くの新機軸が必要でした。

    意図としては、データモデルの各点で私たちが分岐した箇所を逐一比較対照する深みにはまり込むことなく、Mononokeにクレジットを与えることでした。Anthropicには元Metaの従業員が多くおり、Mononokeのおかげでソース管理の使用がいかに楽しかったかに触発されています。これはあなたとそちらのソース管理チームに大きな功績があるものです。私たちは最初からその経験を北極星として、私たちの(異なる)ニーズに対応する決定を下してきました。

  2. MeetingsBrowser

    > 今や私のデフォルトの想定では、Anthropicの公開エンジニアリングプレゼンは大部分が悪意ある盗用だ。それは残念だ。

    まったく同感です。

    人類史上最も影響力のある技術に取り組んでいると主張する会社が、時間を割いて、やや効率的なバージョン管理システムを書いたことを自慢するなんて、と不安になりました。

    実際にはそのサイドプロジェクトを自分たちで作らず、他人から盗用したという事実は、人類を新時代へと導くという彼らの善意ある使命にも疑問を投げかけます…

  3. fcarraldo

    オープンソースのMononokeとEdenFSは、Metaの外では実際にはほとんど動きません。数年前に大規模なモノレポで検討し、動かないと判断して棚上げしました。もし人員やエージェントのチームがあれば、Saplingのコードベースを採用するのではなく、おそらくゼロから作っていたでしょう。

    オープンソースでありながら実際には使えないMITライセンスのプロジェクトについて、これほど大騒ぎするのは少しばかげているように思えます。ソースコードをどうしろと?鑑賞しろと?

  4. jfrbfbreudh

    > 「Scion」という名前でさえ、「Bonsai」の音節を逆にして「B」を落としている!これは偶然かもしれないし、そうでないかもしれない。

    は?

  5. espeed

    オープンソースプロジェクト向けの現代的なソース管理システムを再設計するなら、何百万人もの開発者が自分のコンピュータ上でコーディングエージェントを走らせていたり、Claude Code/Google/OpenAIのコーディングエージェントアカウントを持っていたりすることを考慮する必要があります。そしてLinuxリポジトリや他の多くのGitHubリポジトリの証拠からも、オープンソースプロジェクトはコーディングエージェントが提出するバグ報告で溢れかえっています。もし私がバグ報告やパッチを受け入れるなら、提示された問題とそれが問題である理由、望ましい状態や修正とそれが好ましい理由を知りたいし、パッチが提供されるなら、検証可能な来歴の証明が欲しいです。つまり、コーディングエージェントの署名済みセッションで、生成に使われたプロンプトと変更されたコードが対になったものです。こうすれば、オープンソースのメンテナンスは真に分散化できるようになります。

この日のほかの記事

2026-10-15