2025/07/01 追記
本記事は「AI駆動でOSSコントリビュートは可能か？」という実験的な試みです。

次の記事で @rana_kualu さんからご指摘いただいたように、AIが生成したコードを安易に他人のリポジトリへPRすることは、レビュアーの大きな負担となりかねず、十分なコードの精査や配慮が必要です。

https://qiita.com/rana_kualu/items/6b1f09786038e894970e#_reference-7757f1aec3a84f43bcc3

本記事では、リポジトリ管理者の迷惑にならないよう good first issue かつ軽微なUIバグの修正タスクを対象としています。

導入

後半記事です👇

この記事で伝えたいこと

生成AIの登場でOSSコントリビュートの敷居が下がって楽しくなってきた
メンテナーからAIで拾えなかった観点のレビューがもらえる（生成AI時代を生きるジュニアエンジニアにとってはとても貴重）

最近「バイブコーディング」という言葉を耳にする機会が増えました。

バイブコーディングとは、自然言語だけでAIに指示を出し、基本的には自分でコードを書かずに開発を進めるスタイルのことです。流れに身を任せるという意味もあるようです。

そんな中で、ふと次のようなことを考えていました。

「エンジニア歴も1年経ったので、敷居が高いと思い避けてきたOSSコントリビュートにもそろそろ挑戦してみたい」
「AIでバイブコーディングができるなら、バイブOSSコントリビュートもできるんじゃないか？」

つまり、自分ではコードを書かず、OSS探し、issue選び、調査、設計、実装、リポジトリ固有の自動テストやコードチェック、レビュアーとのやりとりといった全ての工程で、AIのサポートを受けてマージまで持っていくことをゴールに据えて挑戦してみることにしました。

結果として、コードはほぼ一行も書かずにPRがマージされる という面白い体験ができたので、共有したいというのが本記事のモチベーションです。

こちらが対象のPRです👇

使ったAIツール

Cursor
o3, 4o, DeepResearch
deepwiki

いざ参る

OSS探し

まずは、対象となるOSSを探すところからスタートです。
コツは、deep Research を活用して、自分の技術スタックにマッチし、取り組みやすいOSSを見つけること。

117件検索して、11分も考えてくれましたね。こうして初めにヒットしたものがAntennaPodというOSSアプリでした。

AntennaPodはAndroid向けの人気ポッドキャスト管理アプリで、オフライン再生や細かな再生設定、プライバシーへの配慮など、ポッドキャストの包括的な管理・再生機能を提供しています。

さっそくGoogleストアからインストールして使ってみたところ、非常に便利で驚きました。普段からポッドキャストをよく聴くこともあり、気づけばすっかりヘビーユーザーです。

deepwikiでOSSの構造を素早く把握する

続いて、プロジェクト全体の構造を把握するために、deepwikiを使ってアーキテクチャの概要を調べていきます。やることはシンプルで、リポジトリURLの github.com の部分を deepwiki.comに書き換えるだけです。すると以下の画面に遷移するので、「アーキテクチャの概要について教えて」というようなプロンプトを入力するだけです。各モジュールの責務や依存関係、レイヤードアーキテクチャの採用状況、データベース設計の概要など、リポジトリ内のコードベースに基づいた情報を網羅的にドキュメント化できます。

また、任意の観点で追加質問を投げることも可能で、ドキュメントが整備されていないOSSでも効率的に内部構造を理解できる点が大きな強みです。
コードリーディングの初動を大幅に効率化してくれる優秀なAIツールだと思います。

deepwikiの詳細についてはこちら👇

issue選び

プロジェクトの全体像をざっくり把握したところで取り組む issue 探しを始めていきます

OSS活動初心者のために、good first issue というタグが用意されており今回はその中から未着手のものを選んでみることにしました。
選んだ issue がこちらです

内容

👆のような、1年のポッドキャスト聴取傾向をまとめてくれる Echo 機能が対象です。

2024年版の AntennaPod Echo で、こんなメッセージが表示されました

あなたは今年、購読中のポッドキャストのうちX%を聴いています。
久しぶりに〇〇（ポッドキャスト番組名）をチェックしてみませんか？

一見ありがたいレコメンドですが、実はこの〇〇というポッドキャスト、2021年を最後に更新されておらず、すでに全話聴き終わっていたものでした。

この表示を見たユーザーは

もう聴くものがないのに、なぜこの番組を勧めてくるの？
非アクティブさを責められている？

と思ってしまったと。

もちろんこれはバグではなく、「過去に好きだった番組をもう一度聴き直すのもアリだよね？」という趣旨なのかもしれません。
でも、せっかくなら

今も配信が続いていて、まだ聴いていないエピソードがある番組をおすすめしてくれたら、もっと嬉しい。

この体験を通じて、ユーザーは

この番組おすすめアルゴリズム、もう少し工夫できるのでは？

と提案してくれました。

以上が issues の概要です。

ブランチ準備

まずはブランチを切るところからやってもらいましょう。

Cursorくんがブランチを作ってチェックアウトしてくれました。ブランチの命名をよしなに決めてくれるのが地味に便利です。

調査 - 実装方針の検討

次に関連ファイルの調査へと進んでいきます。

下記のように対応すべき箇所と次の実装方針を出力してくれました。

ここで、AIの提案通りにそのまま実装へ進むこともできますが、AIの出力を十分に理解しないまま進めてしまうと、意図しない方向にミスリードされて遠回りになることがあります。
そのため、僕は必ずAIの調査内容と実装方針がコードベースで正しいかどうかを確認するようにしています。AIの出力を完全に理解できない場合は、不明点を洗い出して切り分け、自分で調べたり、ChatGPTに質問したりして、理解を深めるようにしています。

なお、本筋から少し外れた内容を確認したい場合には、Cursorでスレッドを切り替えることで、これまでのやりとりの文脈を保ちつつ、スムーズに質問できるので便利です。

調査内容と実装方針を精査し、対応箇所の洗い出しと処理の流れを整理したものが、以下のプロンプトです。

このように、能動的かつ具体的なプロンプトを与えた方が、AIからの回答精度が高くなると感じています。

実装 - 理想の挙動を伝える

調査と実装方針が定まったので実装に取り掛かっていきます。

下記プロンプトは、実装指示 + Debug方法も聞いちゃってますが、本当は分けた方がよかったです...

AIに実装指示を与えるときに意識したこととしては
まず、変更後の状態、すなわち理想の挙動、理想のロジックを指示する

XXXというロジックに改善したい

続いて現状の状態を指示する

現状のロジックは以下のようにXXXとなっている
該当のコードを抜粋

実装してくれました✨
問題なさそうなので動作確認を行ったところ、バグが見つかりました。
この不具合についても、AIに調査させて原因を特定していきます。

バグ調査 - デバッグはバイブでOK

思い返すと、バグ解決は本当の意味でバイブコーディングしていたと思います。
流れに身を任せてCursorに言われるがままに原因を調査しました。

個人的にはバグ解決は、頭使わずにバイブコーディングしても大きな問題はないのかなと思います。
あらぬ方向にミスリードされたとしてもなんだかんだ全件デバッグプリントして読み込ませれば大体のバグは解決できるんじゃないかと思ってます。まあ時間はかかりますが。

回答を得ましたがちょっと的外れな気がして再度イシューを読ませて考え直させています。

バグが解消されれば問題ないので、AIの提案に身を任せます。

動作確認してもバグが解消されていなかったため、バグの内容をそのまま伝えていきます。

デバッグログを追加してもらいました。が、Logcatにデバッグログが出力されませんでした。なのでそのまま伝えます。

なんか追加してくれました。

無事、デバッグログが出力されました！ログをそのまま貼り付けて報告します！

ログを読み取って考えられるバグの原因を考えてくれました。

全件出力用のデバッグコードを追加する提案に乗ります！

全件出力デバッグの結果得られたログを貼り付けて考えさせます。

バグ解消

なるほど！ここにきてバグの原因が完璧にわかりました！
Feed（つまりポッドキャストの番組）のタイトルとIDは取得できている。しかし、Feedに各エピソードが紐づいていない。そのため、Feedに紐づくエピソードリストを明示的にロードしてあげる必要があるということでした。
原因がわかったところで（Cursorもわかってる）そのまま修正を適用させていきます。

修正が完了し、動作確認をしたところ問題なくタイトルが表示され、バグが解消されました！！！

お掃除 - デバッグコードの後始末

無事バグを解決できたので、デバッグコードのお掃除をしてもらいます。

Pull Request に向けた準備

一通り修正が完了したのでプルリクエストに向けて準備をしていきます。
PRにあたって必要なことを聞いてます。リポジトリ固有のルールでテストコードなど書かないといけないのかなと疑問に思ったので、issueのリンクとともにそれをそのまま聞いています。

今回は実装内容が、UIの一部ロジックの修正であり、ユニットテストが必要という雰囲気ではありません。レビュアーに指摘された時、対応すればいいと思う、と答えてくれました。特にユニットテストのテストは必要ないみたいですね。

加えてPR本文も考えてくれました。
チェックしてみたところ、今回の実装内容、詳細、動作確認テストについて書かれており、このまま貼り付けられるレベルの文章だと思いました。

実際、このPR後レビュアーの方とのやりとりがスムーズに行えたので、過不足なく変更内容を伝えられているのだと思いました

commit & push - Git操作もAIで

続いて、commitとpushもやってもらいましょう。ステージングには自分で挙げていたので、コミットからお願いしています。

pushがうまくいかなかったようです。
OSSを自分のリポジトリにForkせず、直接OSSのリポジトリに向けてpushしていたのが原因でした、本来はForkした自分のリポジトリを経由して、OSSのブランチにPRが送信されるようでした。

初めてのOSS活動でこの辺のやり方がよくわかっていなかったのですが、AIが丁寧に教えてくれたおかげて詰まることなく対処できました。
こういう細かいところで詰まって時間が溶けるという出来事が、AIとともに開発することで簡単に回避できるのは大変ありがたいと感じています。

無事、Forkした自分のリポジトリへのpushが完了してPRのボタン（あの緑のボタン）が出てきました👏

ということで再度、commitとpushもやってもらいます。

しれっとコミットメッセージもよしなな英語で書いてくれるのがありがたい

これでプルリクエストが作成できました⭐️

自動テスト実行 - CIを通して最終チェック

あとはチェックリストに従ってテストコード、文法チェックを行っていきます。
テストコードは問題なく通り、リントで引っかかった箇所は改行や空白も修正しました。

全てチェックし終わり、PR完了 !!!

まとめ

英語でのやりとりやコミュニケーションのノリが分からなくても、AIが補完してくれるため、言語の壁を超えたOSS活動に取り組みやすくなっている
調査・設計フェーズでは、AIの出力をうのみにせず、自分で検証・判断する力が求められる
実装フェーズでは、AIに「ゴール（理想の状態）」をはっきり提示することが精度の高い出力につながると実感
バグのトラブルシューティングにおいては、ある程度流れに任せてバイブコーディングしても意外となんとかなると感じた

少し長くなってしまいましたが、この後の「レビュアーとのやりとり」や「修正プロセス」については、後半の記事で紹介します。
AIと協働して作成したコードにレビューを受けることで、現状のAIではカバーしきれない観点や判断軸が見えてきて、とても勉強になりました。

後半記事です