株式会社ブレインパッドプロダクトユニットでRtoaster GenAIの開発をしている依田です。
今回はClaude CodeとGitHubを利用した開発についてのお話です。
対象読者
- 生成AI初心者の方
難しい設定なしでも、大きく開発者体験が向上します。ユーザープロンプトの実例を示しますので、よりリアルに生成AI活用のメリットをお伝えします！
本記事内のClaude Codeに関わる設定は、最適な状態になっていません。私自身初心者なので、その点にご留意ください。
環境情報
| 項目 | 仕様/バージョン |
|---|---|
| OS | macOS Tahoe 26.2 |
| Claude Code | 2.1.1 |
Claude Codeのインストール
VSCodeなどのエディタを利用している場合、エディタの拡張機能（例: Claude Code for VSCode）を利用するのも良い手段ですが、CLIからClaudeを呼び出せるようにしておくとより便利になります。
以下の公式サイトに記載されている手順に従って、インストールしましょう。
本記事ではCLI版ClaudeをClaude Codeと呼びます
gh コマンド
gh コマンドは、GitHubのCLIコマンドです。人間がGitHubの情報を見る際はブラウザを利用することがほとんどだと思います。
ですが、生成AIと gh コマンドは非常に相性が良いので、GitHubを使われている方はぜひインストールしましょう。
手順は以下の公式サイトをご参考ください。
設定
それぞれのコマンドをインストールしたら、あとは少しだけの設定を行います。
プロジェクト固有の設定を行う場合はプロジェクトルートのディレクトリに、プロジェクトを横断する設定はホームディレクトリに .claude/ ディレクトリを作成し、その中に下記のMarkdownファイルを作成します。
# GitHub 運用ルール
- **URL:** `https://github.com/Taketo-Yoda`
- **ツール:** GitHub操作（接続・起票・閲覧）には必ず `gh` コマンドを使用すること。
- **Issueベース開発:**
- 修正や機能追加はIssueの内容に基づいて実施する。
- Issue起票時は、AIが単独で実装・完結できるレベルまで詳細な技術仕様を記述すること。
Issueベース開発とは、Issue（課題チケット）を起点に開発を進める、一般的なGitHubの開発スタイルです。
下記のファイルはプロダクト固有ルールの一例です。
# Branch Rules
1. **Do not work directly on the `develop` branch**
- Always create a feature branch first
2. **Never work on the `main` branch**
- main is for production releases only
3. **Proper branch naming conventions**:
- Feature: `feature/<issue-number>-<short-description>`
- Bugfix: `bugfix/<issue-number>-<short-description>`
- Hotfix: `hotfix/<issue-number>-<short-description>`
- Documentation: `docs/<issue-number>-<short-description>`
以上で準備は完了です。
開発
CLIで claude コマンドを実行し、Claude Codeを起動します。
あとは雑に Issue#xxの開発をして とClaude Codeへお願いすればOKです。
下図が実例です。実際のIssueはこちら。
Claudeは gh コマンドを実行・情報を取得して作業を計画します。 その後、ステップバイステップで下図のように承認を依頼されるので、よしなに回答していきます。
下図のように、どんどんコードを直していってくれます。
たまに「Yes」と回答していくだけで、どんどん進みます。下図はテストまで進んだ様子。
Pull Requestとレビュー指摘対応
下図のように、Claude CodeはPull Requestまで出してくれます。
あとは、GitHubで人間が修正内容を確認します。いくつか指摘をコメントします。
Claudeに限らず、すべての生成AIは日本語を入力として渡すと、多くのトークン（文章を細かく区切った時の単位）を消費します。コスパよく生成AIに仕事を任せたい場合は英語を使いましょう。
GitHubでコメントを残したら、再びCLIに戻ってレビューした旨を伝えます。ここでも、具体的な指摘までは書きません。 PR#xxにコメントしたので、指摘対応して と言うだけでOKです。
下図は、それに対するClaude Codeの回答です。
これで開発は完了です ✅
入力したプロンプトも Issue#xxを開発して、PR#xxの指摘対応をしての2種だけです。
コードエディタの出番はありませんでした。
ただし、人間がコードを読まなくて良いわけではない点に留意して下さい。生成AIがコーディングをする場合は人間がレビューを、人間がコーディングする場合は生成AIがレビューをするなどのような棲み分けをしましょう。
以下の点は常に念頭に置いておく必要があります。
- 生成AIは成果物に対する責任を負わない
- 最終的なコードの品質を保証し、責任を負うのは人間の役目
追加で設定しておくと良いもの
Claudeに働いてもらっている間は退屈ですが、たまに承認を求めてきます。その際にアラーム音を鳴らすようにすると、完全に目を離していてもClaudeの要求をキャッチできます。
以下はMacにおける設定例です。
{
"hooks": {
"Notification": [
{
"hooks": [
{
"type": "command",
"command": "afplay /System/Library/Sounds/Blow.aiff"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "afplay /System/Library/Sounds/Glass.aiff"
}
]
}
],
}
}
詳しくは下記の公式フックリファレンスをお読みください。
Claude Code 2.1.0から、settings.jsonに言語設定も入れられるようになったので、合わせて設定することをお勧めします。
さらに開発者体験をよくするために
GitHub ActionsにClaudeを統合すると、本格的にCLIさえも触る必要がなくなりそうです。
最後に
生成AIを「エキスパート」にするか「道具」にするかは、人間側の使い方次第だと感じました。
Appendix
生成AIが自律的にコーディングできるよう、.claudeディレクトリに以下の2ファイルを配置していました。
1つ目はプロジェクト全体のコンテキストです。
2つ目は、より具体的な指示を記載しました。
instructions.mdは記述量が多くなっていますが、プロジェクトの規模が小さい内に、Claude Code自身に作らせ、以降はPull Requestで出たケアレスミスを追記させていくような形でファイルを成長させていきました。