📝

有名どころMCPを試してみる - その2 GitHub

に公開

めあて

Gemini CLIのMCPにGitHubを登録して、Issueドリブンな開発をさせてみる

前提

WSL(Debian)環境でGemini CLIがセットアップ済の状態から始めます。

MCPはhttps://github.com/github/github-mcp-serverで公開されている公式のものを使用します。
このMCPの説明は不要だと思います。githubのリポジトリやプルリクエスト、Issueの操作をMCPを通して実施することを試してみます。

手順

GitHubで新規プロジェクトを作成

まず、Issueや成果物を管理するプロジェクトを作成します。README.mdのみがある状態になりました。

GEMINI.mdの作成

Gemini CLIに対してIssueドリブンな開発プロセスをさせるため、その具体的なプロセスを記載したGEMINI.mdファイルを作成します。GEMINI.mdはGemini CLIが実行時に自動的に読んでくれるコンテキストを記述したファイルです。(自分で記述してもよいですが、Gemini CLIに要件を伝えることで作成させることもできます。下記内容はほぼGemini CLIに依頼して作成した内容です。)

GEMINI.md
## 1. プロジェクト概要

このプロジェクトは、Pythonを使用して仮想通貨の自動売買を行うボットを開発することを目的としています。

- **リポジトリURL:** https://github.com/dng3brs/crypto_bot_proto

コードベースはGitHubで管理し、すべての開発タスクはGitHubのIssueで管理します。

## 2. GitHub操作

**すべてのGitHub操作(Issue作成、ブランチ作成、プルリクエスト作成など)は、MCP(Gemini)を通じて行います。** 開発者が直接Web UIやGitコマンドで操作することは原則として禁止します。これにより、開発プロセスの一貫性と自動化を担保します。

## 3. 開発ワークフロー

当プロジェクトの開発は、すべてGitHub Issueを起点として進行します。**プロジェクトの初期セットアップや構成変更など、コード変更を伴ういかなる作業も、必ずIssueを作成してから開始してください。**これにより、タスクの明確化、進捗の可視化、そして成果物のトレーサビリティを確保します。

### Step 1: Issueの作成

すべての開発作業(機能追加、バグ修正、リファクタリング等)は、まずGitHub Issueを作成することから始めます。

- **目的:** 開発タスクの要件、背景、ゴールを明確に定義します。
- **記載事項:**
    - **Title:** タスク内容を簡潔に表現してください。(例: `〇〇取引所のAPIと接続する`)
    - **Body:**
        - **背景 (Background):** なぜこのIssueが必要なのか、どのような課題を解決するのかを記述します。
        - **要件 (Requirements):** 実装すべき機能の仕様を箇条書きで具体的に記述します。
        - **前提事項 (Prerequisites):** このタスクに着手するための条件や、依存する他のIssueがあれば記述します。
        - **テストケース (Test Cases):** 実装が完了したことを確認するための具体的なテストシナリオを記述します。成功ケースと失敗ケースの両方を想定してください。

### Step 2: ブランチの作成

Issueを作成後、そのIssueに対応する作業ブランチを作成します。

- **ブランチ命名規則:** `feature/issue-<issue番号>`
- **例:** Issue番号が`#10`の場合、ブランチ名は `feature/issue-10` となります。

### Step 3: 実装とテスト

作成したブランチ上で、Issueに定義された要件に基づき実装を行います。

- 実装完了後、Issueに記載されたテストケースをすべて実施し、期待通りに動作することを確認してください。
- 新しいコードには、可能な限りユニットテストを追加してください。

### Step 4: プルリクエストの作成

実装とテストが完了したら、`main`ブランチ(または開発用の`develop`ブランチ)に対してプルリクエストを作成します。

- **タイトル:** `[#<issue番号>] <Issueのタイトル>` の形式で記述します。
- **本文:**
    - `Closes #<issue番号>` を記載し、マージ時に自動でIssueが閉じるように設定します。
    - 実装内容の概要や、レビューしてほしい点を記述します。

### Step 5: コードレビューとマージ

- 作成されたプルリクエストは、チームメンバーによるコードレビューを受けます。
- レビューでの指摘事項を修正し、承認(Approve)されたら、プルリクエストをマージします。

## 4. コミットメッセージの規約

コミットメッセージは、変更内容が一目でわかるように、以下の形式を推奨します。

```
<type>: <subject>

<body>
```

- **type:** `feat` (新機能), `fix` (バグ修正), `docs` (ドキュメント), `refactor` (リファクタリング), `test` (テスト追加・修正)など。
- **subject:** 変更内容の要約を50文字以内で記述します。
- **body:** (任意)変更の具体的な理由や詳細を記述します。

**例:**
```
feat: Binance APIへの接続機能を追加

- binance-connectorライブラリを使用
- APIキーとシークレットキーは環境変数から読み込むように実装
```

リポジトリに対するアクセストークンの作成

GitHub MCPはアクセストークンで認証・認可するため、トークンを作成します。コード、issue、プルリクエストに対する権限を付けています。

~/.gemini/settings.jsonにMCPの設定を追記

Gemini CLIからGitHub MCPを利用するための設定を追記ます。作成していたアクセスキーはここの記述で使用します。

{
  "theme": "Default",
  "selectedAuthType": "oauth-personal",
  "mcpServers": {
    "github": {
      "command": "docker", "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"], "env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"}
    }
  }
}

リポジトリをローカルにclone

ここまでで、Issueドリブン開発をする準備ができたので、リポジトリをローカルにcloneして開発を始めます。

最初のIssueを作成し、タスク実行してみる

Gemini CLIをプロジェクトフォルダで実行し、最初のプロンプトを指示します。

プロンプト
プロジェクトの最初のIssueを作成し、実行してください。最初のタスクはプロジェクトの初期セットアップです。

- Pythonの仮想環境をセットアップ
- プロジェクトの基本的なディレクトリ構造を作成
- 主要なファイル(main.py, requirements.txtなど)を空の状態で作成
- .gitignoreファイルを作成し、仮想環境のディレクトリやキャッシュファイルなど、バージョン管理に不要なファイルを指定

Gemini CLIからは、下記の流れで実行確認が行われます。

  • Issueの作成
  • ブランチの作成
  • python仮想環境作成コマンドの実行
  • プロジェクトのサブディレクトリの作成
  • 空ファイルの作成
  • .gitignoreの作成
  • gitへのcommitおよびpush
  • プルリクエストの作成

ここまできたら、GitHubのWebからプルリクエストを開き、内容を確認します。
自分でマージを実行してもよいですし、Gemini CLIでマージとIssueのクローズを指示してもよいです。

次のタスクをプロンプトで指示

プロンプト
プロジェクトの初期セットアップができました。
それでは次の開発タスクを始めましょう。
次のタスクは、仮想通貨売買を自動化するうえで重要な、取引方針を検討し、ドキュメント化することです。
このドキュメントstrategy.mdは、今後botを実装するうえでの中心的な設計資料となります。
どのような指標を用い、どのような条件で売買取引を実行するのか、を定めます。

いくつかの実行確認を経て、strategy.mdのプルリクエスト作成まで行われました。レビューしてマージします。

このように、issue作成とその開発作業、そしてプルリクエストまでをGemini CLIに実施してもらい、プルリクエストのレビューのみ人が行う、という開発プロセスができました。

Discussion