はじめて OSS にコントリビュートした話

この記事は一休.com Advent Calendar 2025 の 20 日目の記事です。

ひと月以上前のことですが、はじめて OSS にコントリビュートしました。チャレンジしてみたいという気持ちは以前からありつつも、なかなか最初の一歩を踏み出せずにいましたが、実際にやってみると意外とできたのでその過程を書いていきたいと思います。

なお実際の取り組みの際はこちらの記事をかなり参考にさせていただきました。

動機や背景

冒頭にも書いた通り、私は以前から OSS コントリビュートしてみたいと考えていました。その理由はぼんやりしていますが以下のようなものです。

• OSS コントリビュートしている人はすごそう！
• 普段使わせてもらっているツールにすこしでも役に立ちたい
• コーディングは好きだが作りたいものやアイデアが特にないので、OSS はコーディングの目的にできそう
• 技術力を高めたい

その一方で「自分の実力で本当に取り組めるのか」や「英語でのやり取りがある」といった不安もあり、心理的なハードルの高さからなかなか行動に移すことができずにいました。

きっかけ

弊社が Vue Fes Japan 2025 のスポンサーをしていた関係で、Vue Fes の懇親会に参加させていただきました。そこで上に挙げた記事の著者である magurotuna さんと主に OSS コントリビュートについて色々会話させていただいたことでモチベーションがぐっと向上し、勢いのまま取り組むことにしました。

実際にやったこと

1. OSS の選定

まず大前提としてコントリビュートする OSS を決める必要があるので以下のような観点から選定しました。

• どの言語で書かれているか (あまり不慣れな言語は避けたい)
• 普段使っているライブラリやツール (親しみがある)
• (できれば)アクティブで発展途上のプロジェクト
• Good First Issue のラベル(後述)を使用している

これらの条件から Biome という TypeScript の linter や formatter の機能を持つツールにコントリビュートしようと考えました。Biome に使用されている Rust は日常の業務でもバックエンド開発に使用しており、ある程度コードに馴染みがあります。また、もっと Rust の力をつけたいというモチベーションも理由のひとつです。

2. 取り組めそうな issue を探して担当になる

先述の Good First Issue のラベルがついた issue を一通り眺めます。

issue が立てられると OSS の管理メンバーが確認し、比較的簡単であったり短時間で対応できそうだったりするものには Good First Issue というラベルをつけます。この文化がある OSS の方が、最初のうちは取り組みやすいと思います。

初めて見た日はちょうどよさそうな Good First Issue には全部担当者がアサインされていたので、そこから一週間程度新しい issue を watch していました。Good First Issue は人気なのですぐ売り切れてしまうのです。

そうこうするうちに私が見つけて取り組むことにした issue はこちらです。詳しい issue の内容は後の節に記述しますが、issue の内容がわかりやすく、影響範囲も狭そうと感じたのでこれに決めました。この段階ではまだ Biome の中身や linter がどう動くかなどを全く知らない状態でした。

取り組みたい issue を決めると、issue にやりたい旨のコメントを書いて、自分にアサインされるという流れで担当が決まります。基本的に早い者勝ちになっています。

2.5 コントリビューションガイドラインを読む

issue を探してる間にもできることはあります。

OSS の中にはコントリビューションガイドを用意しているものが多いです。コントリビューションガイドとは、コントリビューター向けに、テストの方法やコミットメッセージ・PR のルールなどが書かれているものです。

私は issue を探すのと並行してこちらを読み、開発の流れを把握できました。Biome の場合は CONTRIBUTING.md というファイルに記載されています。

私の場合は読んでみただけですが、今振り返るとこのタイミングで build や test が実際に動くか試せると、なおよかったです。

3. issue の内容を理解する

少し横道にそれましたが、いよいよ issue に取り組みます。今回の issue の内容を簡単に説明すると、TypeScript の型定義に対して、ある条件を満たしたときに readonly をつけた方がいいと伝える機能の表示が壊れているというものです。

actual

- fieldName:·number;
+ readonly·
+ fieldName:·number;

expected

- fieldName:·number;
+ readonly·fieldName:·number;

上のように readonly の後ろに不要な改行が入ってしまっていた suggestion を下のように修正することが今回のゴールです。

ChatGPT を利用してコードベースでの理解を進めつつ、Biome Playground で正常パターンと異常パターンの具象構文木(CST)の差分を睨んでいました。

AI によって初見のコードを読むことの障壁が低くなっていると感じており、実際かなり助けられました。さらにコードを読むだけでなく、Biome がどのように動いているか(CST を走査して云々)のような概要について聞ける点もよかったです。

さまざまな型定義のパターンを試しながら挙動を確認しました。その結果、readonly 修飾子を挿入する際に fieldName の token が持つ先頭の改行が不要であるにも関わらず削除されていないことに気づきました。これが原因で readonly と fieldName の間でも改行されてしまっているのだろうと推定しました。

4. コードの修正およびテスト

ここまで原因がわかれば、コードベースの理解を進めていたこともあり、概ねどこを修正すればよさそうかはわかっていました。そこでその周辺をさらに深掘りしてみると、今回の対象ルールの別パターンで私がやりたかったものと同様の改行の削除がされていたので、それを参考にコードを修正しました。

コードを修正するとテストも追加して、今回の修正が想定通り動くこと・今までのテストが壊れずに通ることの二点を確認します。この辺りはコントリビューションガイドの通りにスムーズにおこなうことができました。

5. PR の作成からリリースまで

テストが通ればいよいよ PR を作成します。PR の作成にも OSS ごとにルールがあるのでそれに従います。

Biome の管理メンバーは活発で、PR を作成するとすぐ反応をいただけました。はじめての OSS コントリビュートで不安だったので、このような点からも活発な OSS を選択する方がよいと感じました。

私が作成した PR は、内容は OK でコメント修正と changeset の追加を依頼されました(コントリビューションガイドには changeset についての記載もありましたが自分の修正に対して必要と読めていませんでした……)が、その対応をするとあっけなく approve と merge をされ、その５日後くらいにはリリースされました 🎉

まとめと感想

今回の記事では、私がはじめての OSS コントリビュートをした経験について書きました。やってみる前の不安に対して、意外とあっさり完了できたことや、多くの人に使われるツールで自分のコードがリリースされたことの嬉しさが印象的です。

今回取り組むにあたって特によかったと思う点は以下のようなところです。

• モチベーションが高まったときに勢いで行動した
• 普段使っているツール・言語の OSS を選んだことで親しみが持てた
• Good First Issue のラベルがあり、選定の助けになった
• コントリビューションガイドが整備されていて開発やテストが容易だった
• できる見通しが立つ前から「やります！」と言うことで自らやるしかない状況にした

その後追加のコントリビュートはできていない状態ですが、今後も技術を通じてコミュニティに貢献できればと思っています。

---

これは後日知ったのですが、同じチームの先輩も Biome に貢献したことがあると聞き、とてもびっくりしました