23年続くOSSの、9年越しのバグが直るまで

AI・機械学習チームブログリレー15日目の記事を三浦 (@mamo3gr) がお送りします。前日は須藤さんによるClaude Codeと安全に付き合うためのサンドボックス機能の検証でした。

www.m3tech.blog

私は先月まで半年間の育児休業を取得していたのですが、復帰してからというもの、AIエージェントの進化とそれに伴う開発プロセスの様変わりにびっくりしています。日進月歩の変化にキャッチアップしなくては…、と危機感を募らせつつ、今日は20年以上も続く老舗ソフトウェアへのコントリビュートに挑戦したエピソードを通して、ちょっとだけ世界を良くするために小さなことでも始めようよ、という話をします。

厳島神社の大鳥居。この神社は台風や高潮など自然災害のたびに大小の改修を経て、1400年以上の歴史を持つとされています

Emacsとorg-modeによるタスク管理
見積もり時間が空になるバグ
修正パッチの提出と挫折
フォロワー現る
世界をちょっとだけ良くする
We are hiring !!

Emacsとorg-modeによるタスク管理

Emacsは多くのハッカーに愛用されているテキストエディタですが（"Famous Emacs Users"などのワードでWeb検索すると名だたるメンバーのリストが見られます）、その代表的なプラグイン*1の1つに org-mode があります。org-modeは、メモ取りから論文まで至る各種文書の作成、タスクリストやプロジェクトの管理、文芸的プログラミングなど、幅広く使えるプレーンテキストのファイルフォーマットと、それを扱う機能群を指します。ちなみに、この使い勝手の良さのせいか、Vim*2やNeovim*3, Visual Studio Code*4といった他のテキストエディタやIDEにも移植されています（ただし機能面や安定性はやはり本家が充実しているように見えます）。

私は専ら、タスク管理にこのorg-modeを重用してきました（正確なタイミングは記録していないのですが、遅くとも2012年には使い始めていたようです）。Emacsの軽快な操作性をベースにしているので、思いついたら即座にタスクを書き出して頭をクリアにできますし、重要なタスクを選び出して翌日のタスクリストを作成するのに1分もかかりません。また、プレーンテキストなのでgrep検索やGitでの管理が容易なのも扱いやすいです。

見積もり時間が空になるバグ

このようにタスク管理に便利なorg-modeですが、ある日、意図した挙動をしなくなりました。org-modeで管理できるアイテムは大きく分けて、会議のように開始と終了の時間が決まった「予定」と、特に時間の決まっていない「タスク」があります。タスクはそれぞれ見積もり*5 (Effort) を入力でき、開催時間帯の決まっている予定は、その長さ（時間）に合わせて自動的にEffortが算出・表示されます*6。この自動算出が機能しなくなり、本来時間が表示されるべき列がポッカリと空欄になってしまったのです。翌日のタスクリストを作成するときには、タスクの見積もり時間と会議の所要時間を合計して業務時間（8時間）を超えないことを確認するので、Effortが自動算出されないのは困ります。

今日のタスク一覧。時間帯の記載があるアイテムが会議（予定）で、下段にまとまっているのがタスク

いわゆるカラムビュー。見積もり (Effort) と実績 (Clock) が見られますが、Effortはポッカリ空

ああでもないこうでもないと調査していると、Web検索の結果、なんと同じように困っている人を見つけました。

emacs.stackexchange.com

「どうやらバグらしい」という見立てとともにワークアラウンドまで回答されています。私は自分の設定が悪いのではないかと疑っていたので、このように疑問をフォーラムに投げ込んだり、それに回答されたりしているこの一連のやり取りに救われました。しかも回答者の方は、公式メーリングリストへバグ報告もされています*7（素晴らしい！）。

さて、ワークアラウンドも分かったので、あとは自分の設定ファイルにそれをコピペすればいいだけなのですが、ここではたと手が止まります。バグを回避するだけなのに数十行に及ぶ複雑なLispコードを設定ファイルに追加することになりますし、これが将来のバージョンでも継続して通用するかはわかりません。また、自分以外にも存在するであろう数多くのユーザーが今後も、同じように調査したり、ワークアラウンドの設定を追加したりすることになりそうです*8。じゃあ、いっそバグを直してしまったほうが、自分も含めてみんなハッピーじゃん、ということで、深いEmacs Lisp*9の知識もなかったものの、挑戦することにしたのです。

修正パッチの提出と挫折

git bisect で壊れたコミットを見つけた後、printデバッグするという地道な作業の結果、何とか問題点を突き止め、それを修正するためのパッチを提出できました。カラムビューを作成する際に、関数 org-columns--collect-values がタスク一覧における各行の duration（つまりEffort）を取ってくるはずなのですが、どういうわけかこの属性が消えてしまっているようでした。そこで、取得のタイミングで既存の関数を流用して再計算させてしまおう、というのがアプローチでした。

ちなみに、このプロジェクトは伝統的にメーリングリストを使っており、GitHubなどのホスティングサービスにPR (Pull Request) を出すのではなく、差分 (diff) をパッチでメール送信します。なお余談かつ手前味噌ですが、環境（バージョン）、バグを再現する最低限の設定と手順、バグ調査の結果で分かったこと・分からなかったこと（時間や知識の都合で追えなかった範囲）、修正の方針など、分かりやすく書かれています。

lists.gnu.org

実は、このパッチが取り込まれることはありませんでした。ケアできていないケースがあり、可能であればリファクタリングすべきというフィードバックをいただいたのですが、これ以上時間が取れませんでした。20年以上も開発されている*10コードベースに対して影響範囲を調査したり、過不足のない修正をしたりする難しさを体感しました。このパッチを作成したのは2022年のことですが、2026年の今なら、Claude CodeのようなAIエージェントのサポートを受けながら、当時よりもずっとラクに修正できたのかもしれません。

フォロワー現る

ふとある日、「そういえばあのバグはどうなったのだろう？また修正に再トライしてみようかな」と思い立って調べてみると、何と修正がコミットされているではありませんか！

cgit.git.savannah.gnu.org

コミットでは私のパッチへのリンクがあったり、修正方針の違いを論じたりしており、私の調査やパッチが多少なりとも寄与できたのではないかと考えています。属性 duration が消えてしまったのは関数 org-columns--collect-values がそれを回収する位置（行）を見失ってしまったのが原因のようで、同コミットではその位置を追加の引数として与えることで duration を取得できるようにしています。

ちなみに、このバグが発生したのはバージョン8.3（2015-08-05リリース）で、修正は2024-10-12にコミットされていることから、何と9年もの間壊れていたことになります（！）。

世界をちょっとだけ良くする

今回の経験を通じて、OSSへの貢献は必ずしも「完璧な修正パッチをマージさせる」だけではないと実感しました。9年越しのバグが解消されるまでの流れを振り返ると、そこにはいくつもの「小さな貢献」が連鎖していました。

声を上げる：「これ、おかしいよね？」とフォーラムやメーリングリストに投稿する。この投稿だけでも、誰かの時間や手間が救われます。
後に続く：先人の報告に対し「自分の環境でも再現した」「この辺が問題のようだ」と情報を足す。特定の個々人の問題ではない、という表明とともに、少しずつ解決に近づくための手がかりを増やせます。
バトンを託す：たたき台でも世に出すこと。私のパッチはマージされませんでしたが、その過程で共有された調査結果やアプローチは、別の誰かの役に立ったはずです。

もしみなさんの手元に、長年「仕方ない」と諦めている不具合や、自作のワークアラウンドで凌いでいるバグがあれば、それをどこかに報告したり、書き留めたりしてみてください。その一歩が、数年後の世界をちょっとだけ良くするかもしれません*11。

そういえば、実はこの修正コミットは2026年4月現在、正規のリリースにはまだ取り込まれていません（git tag --contains e2823be9d の結果が空であることから）。取り込まれたmainをビルドして使う必要があるのですが、その旨を冒頭のQ&Aサイト (StackExchange) にコメントしておきました。たぶんリリースブランチに取り込み忘れていると思うので、これから公式メーリングリストにも共有しないといけませんね。