🤖
【GitHub MCP Server】AI Agentと始める初めてのOSS貢献

2025/05/01に公開
 概要https://github.com/dataform-co/dataform
最近、GoogleのDataform（BigQuery用のデータ変換ツール）というオープンソースプロジェクトのCLIに貢献する機会がありました。

この記事では、GitHub CopilotとGitHub MCP Serverという2つのToolの力を借りて、どのようにOSS貢献を行ったのかについて紹介します。

 はじめにエンジニアとして力がついてくるとOSS貢献に興味が出てくる人もいると思います。

一定技術力が上がってきて自分が使っているツールに不満が出てきたり、業務でものすごくOSSを使っているのにOSS貢献がなく、フリーライド状態になっているのが気まずかったり、人によって理由は様々あるかと思います。

しかし、OSS貢献をするには、次のステップを踏む必要があり、私を含め初心者にはハードルが高いと私は考えています。
既存ツールの改善点を見つける
関連Issueを探し、なければ作成する
プロジェクトの実装を理解し、変更すべき箇所を特定し、PRを投げる
Maintainerからのレビューに対応する
しかし、これらの多くの部分をAI Agentに任せることで人間は実装に集中することができ、非常に少ない労力でOSS貢献ができるようになります。

本記事では、最近の私のOSS貢献の経験を通じて、AI Agentがどのように役立ったかを詳しく説明します。

 貢献の概要今回実装したのは、Dataformのformatコマンドに--checkフラグを追加する機能です。この機能は、CI/CDパイプラインやプリコミットフックでコードフォーマットを検証するために非常に役立ちます。
具体的には以下の機能を実装しました。(変更差分は+166/-12行)
フォーマットされていないファイルを検出する
実際にファイルを変更することなく、フォーマットが必要なファイルをレポートする
フォーマットが必要なファイルがある場合はExit Code 1を返す
PrettierやESLint、Blackなど他のコードフォーマットツールにも同様の機能があり、これによりDataformもモダンなCI/CDパイプラインや開発ワークフローに適合するようになりました。

 今回マージされたPRhttps://github.com/dataform-co/dataform/pull/1962

 AI Agentとの協業プロセス
 1. プロジェクト理解フェーズ最初の課題は、大規模なプロジェクトの中でどこに手を入れるべきか理解することでした。ここでAI Agentが非常に役立ちました。
GitHub CopilotとGitHub MCP Serverを使って、
コードベースの全体的な構造を理解

formatコマンドの実装がどこにあるのかを特定

--checkフラグの仮実装
などを行いました。

これは特にTipsでもなんでもないですが、デフォルトのGPTからClaude 3.7 Sonnetに変更したところ、コンテキスも深く読んでくれるしバリバリ編集してくれるし、体験がとても良かったです。

GitHub MCP Serverは、GitHub上のコンテキストを効率的にAI Agentに与えてくれるので、体感ではローカルのプロジェクトを読ませるより遥かに効率が良いという印象でした。
GitHub MCP Serverの設定方法以下をプロジェクト直下に置くと、serversの上にStartボタンが出ます。

Dockerをsudoなしで実行可能であれば、それを押すだけで実行可能です。

すると、上のダイアログにGitHub Tokenをペーストするように要求されるので適当なPersonal Access Tokenをペーストします。

今回の場合は、OSSなのでPublic Repository Readというデフォルト権限で問題ありません。

.vscode/mcp.json
{
    "inputs": [
      {
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub Personal Access Token",
        "password": true
      }
    ],
    "servers": {
      "github": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
}

 2. Issue作成フェーズ
 2-1. Issue作成--checkフラグをAI Agentに仮実装してもらった結果、変更量が少なかったためこれなら自分でも自信を持って実装できると確信し、Issueを作成しました。

Issue自体もほぼ全てAI Agentに作成してもらって自分は内容を確認しただけです。

我ながら要点がまとまっていて、良いIssueが作成できたと思います。
作成したIssueの一部

 Example Usage
# Check if files are formatted correctly without modifying them
dataform format --check

# Check specific files
dataform format --check --actions="definitions/my_model.sqlx" 
https://github.com/dataform-co/dataform/issues/1961#issue-3010898684

 2-2. Issueに対する返信コメントへの対応!自分がほしいと思っている機能がMaintainer目線で魅力的でないこともある。

レビューはMaintainerの時間を奪うので、Feature Requestにはレビューをしてもらうだけの十分な理由が必要
Maintainerからのコメント
Could you please elaborate on what problem we are trying to solve here? I think here is a difference between formatting and linting. The existing format command is actually formatter and it supposed to be used when we want to fix the file. It should be used in a pre-commit stage, not afterwards.

What actual problem we are trying to solve by adding --check? If we run it in some pipeline and see that some sqlx file is not properly formatted, what should we do in this case? This code is already in the repository in the wrong format.,

https://github.com/dataform-co/dataform/issues/1961#issuecomment-2821806079
自分としては、--checkは必須の機能だったのですが、Maintainerとしては必要性がいまいち感じられなかったらしく、上記のように実装意図やformatとlintの違いなどについて質問がありました。

返信では、質問にきちんと答える姿勢が伝わるように内容を切り分け、一つ一つの質問を引用しそれぞれ丁寧に返答するように心がけました。

また、この返信作成にもAI Agentを活用しました。
作成してもらった返信の一部
Could you please elaborate on what problem we are trying to solve here?
Check‑only mode lets us fail fast in CI/CD without mutating fles.

Teams that can’t enforce pre‑commit hooks (monorepos, GUI clients, corporate policies) still need a deterministic way to block unformatted code before merge.

https://github.com/dataform-co/dataform/issues/1961#issuecomment-2822673596
この返信を持ってIssueが認められたため、 実装フェーズに移ります。

 3. 実装フェーズ実装の初期段階は、全てAI Agentを活用しました。

というのも、プロジェクトの全体像が見えずどこに手をつけていいかもわからなかったためです。

AI Agentの実装は一発で想定の動作を満たすことができ、それからコードレビューを行うことでプロジェクトの構造を理解することができました。

たったこれだけで実装フェーズ終了です。

 4. レビュー対応フェーズプルリクエストを提出した後、メンテナーからのフィードバックに対応する際も、AI Agentを活用しました。
PRをGitHub MCP Server経由で読みに行き、Maintainerの意図をAI Agentに効率的に伝える
そのレビューコメントに従って、AI Agentにコードを修正してもらう
それを最後に人手でレビューする
特にレビュー作業で重たかったのは、テストを実装し、手元で環境を再現してローカルテストを実行することでした。

AI Agentを活用することで環境構築はすぐにボタンぽちぽちで終わるものの、コード側に不備があり、原因をコメントアウトするまでローカルでデバッグすることができず、非常に苦労しました。
ただ、手元でテストをローカル実行できるようになる頃には、自分が出したPR周りのコンテキストはほとんど理解できるようになっており、その後の細かいレビュー対応は自力で行いました。

最後にテストを分離してほしいという依頼があり、それの実装後無事マージされました。

 学んだこと
 AI Agentの強み
コンテキスト理解: 大規模コードベースの中から関連するコードを素早く見つけ出す能力は特に優れていました

パターン認識: プロジェクト固有のコーディングスタイルやパターンを理解し、一貫性のある変更提案をしてくれました

ドキュメント参照: 外部ライブラリやフレームワークの使い方を提示してくれました

 自己成長ポイントAI Agent活用しつつも、以下の点で自分自身のスキルが向上しました
OSSプロジェクトへの貢献プロセスの理解
大規模コードベースでの変更管理
コードレビューへの対応スキル
テスト駆動開発の実践

 まとめAI Agentは特に初めてのOSS貢献において、プロジェクトのコンテキスト理解や最初の一歩を踏み出す手助けとして非常に強力です。

しかし、最終的には自分自身でコードを理解し、実装を進める能力が求められます。

Maintainerは時間をかけてレビューをしてくれているわけなので、なんとなくの実装をPRに出すのは時間の浪費ですし、失礼にあたります。

AI Agentを活用してコードを書かせるにしても、最後は自分で全てを理解し、自分の責任で説明可能でなければPRを投げてはいけません。
今回の経験から、AI Agentとプログラマーの協業は、それぞれの強みを活かした効果的なアプローチだと感じました。

AI Agentがコンテキスト把握や初期実装をサポートし、人間がプロジェクトの目的や細かな調整、最終的な品質担保を担当するという形が理想的です。
これからOSS貢献を始めたい方も、AI Agentをうまく活用することで、貢献のハードルを下げることができるでしょう。

みんなでOSS貢献して、よりより世界を実現していきましょう！
概要

はじめに

貢献の概要

今回マージされたPR

AI Agentとの協業プロセス

1. プロジェクト理解フェーズ

2. Issue作成フェーズ

2-1. Issue作成

Example Usage

2-2. Issueに対する返信コメントへの対応

3. 実装フェーズ

4. レビュー対応フェーズ

学んだこと

AI Agentの強み

自己成長ポイント

まとめ

Discussion
