はじめに
こんにちは、ミツカリのたなしゅんです。 皆さんはプログラミングの際に3rdPartyなライブラリを導入していますでしょうか？ ミツカリではお客様へ価値を届けるまでのスピードを早めるため、積極的にライブラリは使わせていただいています。
ミツカリでは社内のコミュニケーションにSlackを利用しており、アプリからSlackへデータを投稿する機能も有しています。
backendのrubyからslackへ投稿する際にslack-ruby-clientというライブラリを使わせていただいています。
slackのfiles_uploadのAPIのV1が2025/3/11をもって利用できなくなりました。
前述のライブラリはしっかりとV2へのアップデートに対応してくれました。
弊社のGemfileでslack-ruby-clientをアップデートすればこの件は解決！
と思いきや、なんと弊社が利用していた他のライブラリが原因でアップデートができませんでした。
Gemは同一のライブラリを複数バージョン共存させることができません。 そのため、以下のような条件になるとライブラリのアップデートができなくなってしまいます。
- ライブラリAがライブラリXのバージョン1.0.0にまでしか対応していない
- ライブラリBのバージョン1.0.0ではライブラリXのバージョン1.0.0に対応している
- ライブラリBのバージョン2.0.0ではライブラリXのバージョンは2.0.0以上を要求する
今回の弊社の例ですと、ライブラリBがslack-ruby-clientです。 BのアップデートがAによって阻害されていました。
我々はライブラリを利用させてもらっている立場ですので、ライブラリが将来的にアップデートされるかどうかの責任は制作者様ではなく、利用する側にあります。
結果、アップデートの阻害要因となっているライブラリAを脱却する作業に多くの時間を使ってしまいました。
前置きが長くなってしまいましたが、ここからが本題です。
ライブラリの選定基準をどう持つか
我々はライブラリを導入する際、何を見てそのライブラリの導入可否を判断すべきでしょうか？ ライブラリAが事前に将来的に使い続けられるものではないという判断が導入時にできていれば今回の工数は必要なかったでしょう。
私が判断に使える材料だと考えられるものは以下です。
- リポジトリ管理元
- コントリビュータの人数
- リポジトリのスターの数
- アップデート頻度
- issueやPRが渋滞していないか
順に見ていきましょう。
※ライブラリがビジネス利用可能なライセンスであるかどうかなど、導入すべきかの手前である導入可能かという点についてはこの記事では触れません。
リポジトリ管理元
まず最初に検討すべきはリポジトリの管理者が何者なのかです。 最も信頼性が高いと考えられるのは何かのサービスの公式のものでしょう。 例えば、AWSは公式でSDKを出していますね。
これはAWSが存続している限りは更新されていくと思って良いでしょうから問題なく利用していいと考えます。
次に信頼性が高いと考えられるのは企業製のものです。 例えばYJITというRailsを事前コンパイルして高速化するというライブラリがありますが、これはShopifyさんが作成したものです。 大きな企業が運営しているものなのである日突然消えたり、アップデートが滞ることはまずないと思えます。
最後に個人の開発者様が好意で公開しているリポジトリです。 こちらはもしかしたらその方の気分次第では更新が止まってしまうかもしれませんね。 もちろんその方はあくまで好意で公開していて、我々は利用料を払っているわけでもないので、責めるべき理由にはなりません。 ビジネスで取り入れるにはリスクがついて回ります。
コントリビュータの数
公式産や企業産でなくてもコントリビュータが多い場合は開発は活発だと考えられます。 ひとりの開発者に依存しないので開発が止まるリスクも低減されるでしょう。 コントリビュータはGitHub上ではここから確認できます。
これまでの経験や個人的な感覚ですが、信頼性の高いものだと少なくとも30人程度はコントリビューターがいるイメージがあります。 それに満たないものだとアップデートされなくなるリスクが高いかもしれません。 ちなみに今回脱却することになったライブラリは10人でした。
リポジトリのスターの数
Githubのリポジトリにはスター機能、いわゆる"いいね"があります。 スター数はリポジトリの右上から確認が可能です。
これも感覚値になってしまいますが、300程度はほしいところです。 特に100未満だとかなりリスクが高いと感じます。 ちなみに今回脱却することになったライブラリは25スターでした。
アップデート頻度
デフォルトブランチへの直近のコミット履歴を見てみましょう。 コミット履歴が直近1ヶ月以内にない場合は開発が活発でない可能性があります。 完成されたライブラリはアップデートされないのでは？と考えられる方もいるかもしれませんが、プログラミングの世界は常にアップデートされていっています。 そのため、ライブラリがアップデートを不要とする世界は今はないでしょう。 ライブラリ側も別のライブラリに依存していることも多いですから、依存先のライブラリのアップデートに対応していく、といったことも必要です。 そのようにライブラリ間の関連性を考えるとどのライブラリも月イチくらいでアップデートされていかないと置いていかれていると感じるものです。
issueやPRが渋滞していないか
こちらは数だけでは判断できない部分になります。多く使われるライブラリであるほどissueの起票やPRの作成も活発になるため、
issueがたくさん起票されている = 開発が活発ではない
これは誤りです。issueの数ではなく、issueが放置されていないかを見ましょう。 1年前に起票されたissueがメンテナーからコメントもなく放置されているなどの状況だと導入リスクは高いでしょう。 逆にissueが多いこと自体は利用ユーザが多く、不具合や課題、追加実装のリクエストが活発なことが多いです。
また、PRについても同様です。メンテナー以外が変更をリクエストすることもOSSであればよくありますが、メンテナーが放置しているといつまで経ってもマージされません。そのような状態になっていないかもよく調査すべきでしょう。
マルウェアがライブラリに仕込まれる事件
x.comGitHub Actionsでファイルの差分とかを得る
— azu (@azu_re) 2025年3月15日
- uses: tj-actions/changed-files
の全部のバージョンにマルウェアが入ってる問題
。
全部のタグが書き換えられているので、SHAで指定する以外は現状対応方法がない。
- https://t.co/mr7T3yl6gw
- https://t.co/lIiKzApAis
- https://t.co/fIBRBWh2mk
少し話が逸れますが、上記のような事件がありました。 マルウェアを仕込んだコミットハッシュにすべてのタグが付け替えられるというものです。 これはrubyのライブラリではなく、GitHub Actionsですが、似たようなことはあり得なくないと思うのでここに共有します。 詳細は把握できておりませんが、メンテナーのリポジトリの管理体制が甘かったのかな？という印象です。 ここまでに書いたポイントとはまた異なる視点ですが、ライブラリを通じたハック被害を受けないように、我々利用側も注意しなければなりませんね。
まとめ
上記のようなポイントを導入前にしっかりと確認し、将来的に信頼できるライブラリかどうかは厳しくチェックしていきたいですね！ まだどんなポイントで判断すればいいか迷っている方への参考になれば幸いです。
横道です
弊社が利用していたライブラリAについて、なんでそんなもの使ってたの？ちゃんとしてないの？と思われるかもしれません。 会社のメンツのために少しだけ言い訳をさせていただくと、ライブラリAが出た当初に利用を始めたため導入当時はスター数は少なくても仕方がないと割り切っていたのと、さすがに出た当初は開発も活発だったためリスクを感じていなかったという点がありました。ですが、ニッチな領域だったため、開発は下火になっていってしまったという背景があります。もちろん、もっと早い段階で見切りをつけられた瞬間はあったはずですので、それはこれからはもっと気を付けていきたい部分です。
現在、ミツカリではITエンジニアを募集しています。ライブラリ選定ももちろんやれます！ 興味のある方はぜひお気軽にご連絡ください！
