■ 1. 記事公開の経緯
- Embulk のメンテナー:
- いちおうまだメンテナー権限は持っている
- プロジェクトはメンテナンス・モードとして実質的にメンテナンスを終了しており、個人としてもなかば降りている
- 発端となった2024年7月のPR:
- なかばメンテナーを降り、プロジェクトをメンテナンス・モードとした理由の一つ
- このPRをきっかけにオープンソース活動についていろいろ考えてしまった
- 当時公表を避けた理由:
- 背景について証拠や確信がなく、さらすような真似はやめておこうと考えた
- ただし、わかる人ならたどりつける程度には旧Twitterなどでボヤいていた
- 二年後に公開する理由:
- Embulk はメンテナンス・モードに入り、PRの主も活動を止めたため事実を共有してよい頃合いと判断
- 2024年時点でこんなことがあったという記録を残す程度の意味はある
- 記事の原型は当時から書きかけていたもので、成仏させる気持ちも込みで公開する
- 推測がまったくの誤解だった場合、当該アカウントの中の人には謝罪する
■ 2. オープンソース活動の痛み
- 複数の利害関係者がいるオープンソース・プロジェクトのメンテナンスは、特に近年けっこうセンシティブ
- 気軽な貢献キャンペーンへの懐疑:
- Hacktoberfest のような呼びかけや、改善の余地に「プルリクチャンス」と雄叫びを上げる人たちがいる
- すべてのプロジェクトとメンテナーがこうした活動を歓迎しているわけではない
- typo修正から気軽にプルリクにチャレンジという類のキャンペーンには強く懐疑的な立場をとる
- メンテナーの負荷:
- やってくるPRに対して想像以上にいろいろなことを考えるし、考える必要がある
- それだけでけっこう疲れ、もうやってらんねーよと感じる開発者も特に近年は多い
- 推測の正否は今も正直わからないが、メンテナーがここまで考えざるをえない環境になっていることは確かで、その傾向は二年でさらに加速している
■ 3. 問題のPRへの違和感: 2024-07-02
- PR自体は不自然ではない:
- おかしな提案ではなく、言っていることも間違っていない
- タイミング次第では素直にマージしていたかもしれない
- 覚えた違和感:
- たった一行のためにここまでしっかりしたDescriptionを書くものか
- "Original Code" と "Updated Code" は変更そのもので、必要性が疑わしい
- PRの主である logresearch というアカウントが何者かわからない
- 違和感を覚えた以上、それを見なかったことにしてマージするわけにもいかない
■ 4. 新規アカウントへの警戒
- ログリサーチ＝サンの素性:
- アカウント名 logresearch 以外に名前は設定されていない
- PRを送る数日前にできたばかりの新しいGitHubアカウント
- あちこちの著名なJavaプロジェクトに、ログ処理に関係する小規模な変更をだいたい一つずつ送っていた
- 警戒レベルが上がった理由:
- 近年、新しく作られたばかりのアカウントはどのソーシャルなサービスでも警戒対象の一つ
- 新しいGitHubアカウントの最初の活動がそれと見れば、なおさら警戒する
■ 5. 動機の推測
- PRの送り方への疑問:
- それなりの規模のコードベースを探索して、見つかる修正候補が一つだけとは考えにくい
- 貢献目的なら、他プロジェクトへ移る前に同じプロジェクトで見つかった他の点にも言及するはず
- 推測される動機:
- 対象のプロジェクトに貢献したいよりも、より多くのプロジェクトに関与したいという動機を持っていた
- 研究者仮説:
- logresearch という名からは、どこかの研究者か研究室の学生がありそう
- 論文でアピールするために貢献プロジェクトの数を稼ぎたいということはしばしばある
- 本当にそうだと確認できればマージしてもよかった
- それならどこそこの研究機関の誰それと名乗るのが常識であり礼儀で、その点でまだ違和感が残った
- 名乗らないことへの評価:
- 公開できない研究プロジェクトでも、非公開のメールなどで名乗るもの
- 本職の研究者ならプロ失格であり、学生なら失格なのは指導教員のほう
- 研究機関が判明したら、そこの研究倫理審査委員会などへの通知を考えるレベル
- 好意的解釈の限界:
- 研究者仮説は攻撃的ではない研究という前提に立った、さらに好意的な解釈でしかない
- 大学の研究であっても、過去に研究倫理の面で問題になった事件が実際にある
- 悪意を仮定すれば、攻撃対象にできるプロジェクトを探していた疑いもある
■ 6. XZ 事件の記憶
- 2024年3月の事件:
- Jia Tan と名乗る開発者が約3年かけてXZ Utils のメンテナーの信頼を得た
- その末に仕掛けたバックドアが、リリース直前に発見された
- このPRが届いたのは2024年7月であり、将来的なサプライチェーン攻撃を狙っていた可能性は看過できない
- Embulk の当時の位置づけ:
- いくつかの企業のデータ基盤でそれなりに大規模に使われ、現実のデータを捌いていた
- Apache License, Version 2.0 のOSSであり、セキュリティ事故が起きてもプロジェクトとして保証する必要はない
- だからといって、攻撃の可能性を疑ったものを無警戒に受け入れるわけにもいかない
■ 7. 想定される攻撃と保留の判断
- 判断の難しさ:
- どれだけ疑いの目で見てもこのPR単体は明らかに潔白
- コミュニティ・ベースのオープンなプロジェクトという体裁からは、即座に却下するのもよくない
- 気の長い攻撃の可能性:
- XZ と同様の長期潜伏型は、このPR単体からは判断しようがない
- ただし一つの新規アカウントから複数プロジェクトにPRを投げる、わかりやすく怪しまれる方法を選ぶかは疑問
- GitHub Actions 実行権限の取得:
- "Require approval for first-time contributors" が当時のGitHubのデフォルト設定
- 一度PRをマージしたユーザーからの次回以降のPRでは自動実行が許される
- これを利用して複数リポジトリで実行権限の奪取を狙っていた可能性がある
- いずれも受け入れる材料としても却下する材料としても弱い:
- 前者は受け入れれば長期的な警戒が必要だが、このご時世ではいずれにせよ大差ないかもしれない
- 後者はGitHubの設定の問題なので穴をふさいで受け入れてもよいが、同様の穴を見落としている可能性がある
- 決定打に欠けるため、この日はなんの反応もせず保留した
- 保留という選択:
- メンテナーは決定もコミュニケーションも意図的に保留することがある
- PRに反応がないと騒ぎ立てる人が、メンテナーの視点からどう見られているかは想像してみてよい
■ 8. 他プロジェクトの対応
- 2024年7月2日の時点で、直後にマージしたプロジェクトはなかった
- 分かれた対応:
- 即座に無言でcloseしたプロジェクトがあった
- botっぽいのでCIの実行権限を渡したくないとしてcloseしたプロジェクトがあった
- テストがないとしてbotが自動closeしたプロジェクトがあった
- ログリサーチ＝サンは、単なるtypo修正でありテストは不要だと反論した
- 詰め寄る様子は、なんだかXZ事件を思い出させる
- メンテナーとしての葛藤:
- どうにもあやしいが、悪意だと断定できるほどの情報はない
- マナーのなっていない善意の研究者という可能性も依然として否定しきれない
- 善意の貢献を無下にはしたくないが、背景に悪意があるなら却下したい
- こういうことを考えるのがいちばん疲れ、コードの良し悪しや理想のアーキテクチャの与太話のほうが何倍も楽しい
■ 9. 翌日の展開: 2024-07-03
- botのcloseへの食い下がり:
- 自分たちはbotではなく、ログ出力文の品質向上に注力する研究者だと主張した
- 自動検出ツールを実世界のデータに使う機会が欲しいと述べた
- 必須の変更とは思えないとしてcloseしたメンテナーにも食い下がり、ログ出力文の品質を自動的に維持する研究だと説明した
- 食い下がった結果、可読性でも修正でもコード改善は歓迎するとしてapproveされたケースがあった
- approveされたプロジェクトには、さらにtypo修正のPRを上乗せしていた
- ログリサーチ＝サン発のPRは、さらに多くのプロジェクトに拡大していた
- CLAへの対応:
- CLA (Contributor License Agreement) を求められて、ちゃんとサインしたところは少し興味深い
- 別のプロジェクトではメールからサインし、その証跡がコメントに残っている
- コメントから言語圏を推察できてしまうが、その推察自体に大した意味はない
■ 10. AI の関与という見立て
- 2026年現在から振り返って読む人は、AI slop の一言で終わりかもしれない
- 当時からそれっぽいと思っていたし、今もたぶんそうだったのではないかと思っている
- 2024年7月という時期の意味:
- 「CLINEに全部賭けろ」より半年以上も前の出来事
- これをAIが普通にできるという認識は、当時そこまで一般的ではなかった
- 周囲に話すと、ここまでやれちゃうんですかねえという反応も当時わりとあった
■ 11. 『割に合わねえな』
- AIの力でやったと想定したとき、コミュニティ・ベースのOSSを個人に近い努力でメンテし続けるのはもう割に合わないと感じた
- レビューや確認にAIを活かす余地があるという見方は当時からあり、実際に大きく効率化したことは現在では多くの人が知るとおり
- 効率化の比率:
- AIがレビュー・確認やコミュニケーションを効率化する比率より、コードの生成を効率化する比率のほうが圧倒的に大きい
- それは現在でも変わっていない
■ 12. 生成と確認の比率変化
- AIがコミュニティ・ベースのOSSにもたらした最大の作用は、効率化そのものより生成コストと確認コストの比率の変化
- チームや組織に閉じた変化であれば同じ組織内の話であり、調整できなくはない
- ただし組織内においてすら、その調整はそんなに簡単ではなかったという指摘は多い
- オープンに貢献を受け付けるプロジェクトではそうもいかない:
- 確認に使えるのは限られたメンバーの限られたリソースでしかない
- お手軽に低コストで貢献を送りつけてくるリソースは外界から無限にわいてくる
- そうするインセンティブを持つ人も、善意にせよ我欲にせよ悪意にせよ無限にいる
- 多くのオープンソース・コミュニティは、確認より生成に微妙に高いコストがかかるというバランスのおかげで幸運にも成り立っていただけ
■ 13. 疲弊とメンテナンス・モード
- 当時に至った結論:
- 個人で持続するのはもう無理である
- 本当に続けるなら、個人とコミュニティの力ではなく組織のリソースを費やす必要がある
- 組織にリソースを費やす気がないなら、破滅的に終わるよりは軟着陸で終わらせるべき
- その行き着いた先がメンテナンス・モード
- 現在、多くのオープンソース・プロジェクトが実際に疲弊していることは多くの人が知るとおり
- GitHubの方針転換:
- PRを受け付けないpublic repositoryの存在を許さないという思想の強さで長年知られていた
- その GitHub が2026年に "Disable pull requests entirely" や "Restrict pull requests to collaborators" を提供した
■ 14. 大学名義の調査メール: 2024-07-04
- この日、目に見えたログリサーチ＝サンの活動はなかった
- 個人のメールアドレス宛に、関係なさそうに見える調査依頼メールが届いた:
- 二か国の大学の研究チームを名乗っていた
- GitHub Actions のワークフロー失敗が起きる原因と解決策を理解したいという内容
- 10分程度のGoogle formアンケートへの回答を求め、結果は匿名化して公開するとしていた
- 怪しいと判断した理由:
- 送り主は名乗っているが、ログリサーチ＝サンのトピックとは関係がない
- 悪意の可能性を考慮に入れると、昨日の今日というタイミングは関係ないと断ずるには怪しすぎる
- 大学の研究チームを名乗りながら、送り主のメールアドレスは大学ドメインではなく @outlook.com
- 研究トピックとしては特定企業の特定サービスに寄りすぎており、これはややイチャモンでもある
- 大学の片方は推察された言語圏、もう片方はまったく別の言語圏だが、いずれも自称でしかなく、両者の関連を想起させる程度のもの
- ログリサーチ＝サンとの関係の有無にかかわらずアウト判定とし、この日は無視を決め込み、その後も返信もフォーム記入もしていない
■ 15. activity の非公開とブロック: 2024-07-05
- この日まではGitHubのユーザーページでactivityが見えており、そこからPRを追っていた
- この日、ログリサーチ＝サンは activity を private にした
- 悪意ありと推認・断定した理由:
- activity を private にする理由は、自分の他のPRを追跡されると不都合がある以外にない
- こういう活動を始めて最初は見せていたのに、数日後から隠すという経緯も不自然
- これは悪意を示す証拠には一切ならず、これを理由に追及することはできず、善意だった可能性も依然ゼロではない
- オープンソース・プロジェクトの立場:
- やってきたPRにすべて付き合う義理はない
- 公平性のようなものを担保する義務もない
- 極論、提案者個人が気に食わないからという理由で却下しても本来はかまわない
- 公開済みのコード一式は公共物と呼べても、プロジェクトへの提案を公共的に受け入れる必要は一切ない
- 結論としてPRをcloseし、会話をlockし、@logresearch をプロジェクトとしてブロックした
■ 16. その後の経過
- ログリサーチ＝サンはその後も一ヶ月ほど散発的に活動を続け、それから活動を止めたようだ
- activity は private でも検索には引っかかるため、他のPRを眺めることはできる
■ 17. メンテナーという「人」
- 記事で伝えたいメッセージ:
- オープンソース・プロジェクトの先にはメンテナー、つまり「人」がいる
- このことをより多くの人に意識してほしい
- 悪意ある攻撃が論外であることは前提
- メンテナーには「あなた」と「悪意ある人」の区別はつかず、AIの時代ではなおさらである
- PRを送る前の自問:
- 自分が暗黙に持っているコンテキスト抜きで他人が見たらどう見えるかを振り返る
- このPRは自分の意図以外にどう解釈しうるか
- 自分の意図は正しくそのまま伝わるか
- そもそも自分の意図はなんだったか
- AIもちゃんとそう指示すればそれなりに考えるし、議論にも付き合ってくれる
■ 18. AI 任せの「貢献」
- バグ修正はメンテナーにボランティアでやらせるより自分が費用を払ってAIにやらせればコスト持ち出しの関係が真っ当になる、という発言は経験者としてまったくの的外れ
- 現行コードの背景と制約もわかっていない第三者が雑にAIに生成させたコード断片から、意図と背景を遡って推測するのはメンテナーにとって苦痛
- 送り主に意図を質問してもAIに答えさせた回答しか返らないなら、そこに送り主がいる必要はなく、メンテナーが直接AIと話せばよい
- どうせAIにやらせるなら、背景と制約をわかっているメンテナーが最初から自分でAIにやらせるほうが圧倒的に安くて早くて上手い
- AI前提で本当に貢献したい場合の作法:
- 不具合なら、問題を精確に再現する手順をしっかり書く
- 機能要望なら、要望の背景となる明確なユースケースをしっかり書く
- 費用と労力を気にするなら、メンテナーがAIを走らせるための実費だけ持つのがベスト
- そういう金銭的な仕組みが欲しい
■ 19. トロフィーではない
- 自分のPRとして履歴に自分の名前を残したいと思う人は、本当に欲しいのが貢献したというトロフィーではないか自問すべき
- オープンソース・プロジェクトへの貢献は、貢献者のトロフィーではない
- これはAI以前からそうだったが、今はAIの力で簡単にトロフィーが手に入るという二重の勘違いをしやすい時代
- オープンソース・プロジェクトの位置づけ:
- そのへんの地面に自然に生えている野草ではない
- 好き勝手していい実験動物ではない
- 経験を積ませてくれる無料のサンドバッグでもない
■ 20. 自分でやるか、人を尊重するか
- AI生成コードの受け入れに消極的なプロジェクトは古い、もっと受け入れるべきだと主張する人が一定数いることは想像に難くない
- それに対する回答:
- AIの力で簡単だというなら、自分でメンテナーをやればよい
- オープンソースなのだから、今すぐfork して始められる
- 実際にそれをやって継続的にメンテナンスしている人は応援するし、正しくチャレンジだと思う
- 特に、自分で一から始めたのではなく他者のプロジェクトをforkして継続するのは本当にチャレンジ
- やらずに言っている人は、その「自分ではやっていない」ことが答えであり、障壁になっている「なにか」をやっているのがメンテナー
- 他者に、つまり「人」に委ねるのであれば「人」を尊重すべき
- 一人でやれることの範囲は拡大したが、他者と一切の無関係を通せるほどではない
- これからどれだけAIが強くなろうと、私たち自身が「人」であることは辞められず、人と人の間で生きなければならないことにも変わりはない
■ 21. fork の時代という予想
- オープンソース・ソフトウェアについては、いずれ本当にみんながfork するようになっていくかもしれない
- かつての規範:
- オープンソース・ソフトウェアへのローカルパッチを持つのは悪手とされていた
- upstream に正しく還元するのが善きソフトウェア・エンジニアの振る舞いとされていた
- 前提の変化:
- メンテナー側は、来るもの来るものみんなを相手にしていられる状態ではなくなっている
- 利用する側にも、いちいちメンテナーとやり取りするのは面倒だという人がいる
- 最新版への追従が大変という課題は、今ならAIに追従を指示するだけでだいたい解決する
- 想定される形:
- 仕事のリポジトリに third_party/ を掘り、外部のOSSのコピーを持つ
- そこでローカルの変更を好きなように加え、更新が必要ならAIに追従を指示する
- PRのマージを催促する必要もなく、メンテナーがPRに煩わされることもなくなる
- これはWin-Winではないか
■ 22. 昔への回帰
- Git やGitHub より前、オープンソースという言葉が生まれる前後の時代:
- ソースコードの .tar.gz が大学などのFTPサーバーに置かれて公開されていた
- 誰かが書いた .patch ファイルは別の大学のFTPサーバーやメーリングリストに流れていた
- 使いたい人は当てたいパッチを拾い集め、手元で当ててビルドして使っていた
- 今も一部のLinuxディストリビューションはそれに近いという話がある
- fork の時代は、そんな時代に戻るだけなのかもしれない
- それがいいことなのかは議論の余地がある:
- 99%は同じコードを世界のあちこちで独立してAIにメンテさせるのは電力の無駄遣いにも思える
- セキュリティ対応をどうするのかという話もある
- 個人的にもちょっと寂しいような気がする
- それでも、メンテナーにあれこれ押し付ける人であふれる世界よりはマシかもしれず、そうでなければみんな辞めてしまう
- このソフトウェア・エンジニアの世界がどういう業界であってほしいかは、私たち自身が考えなければならないこと