はじめに
AI駆動開発プロジェクトにおいて、効率的なGitワークフローの構築と遵守は品質とスピードを両立させる鍵です。しかし、チームメンバー全員が同じレベルでGitの作法を理解し、実践することは容易ではありません。この記事では、Windsurf上でClaude 3.7 Sonnetを活用し、構造化されたGitHub/Gitワークフロー指示プロンプトを使って、AIに開発フローの管理を支援させる方法を紹介します。
この組み合わせがいかに強力で、開発プロセスを変革するポテンシャルを持っているかをお伝えします。
GitHub/Git ワークフロー指示プロンプト ✖ Windsurf ✖ Claude 3.7 Sonnet が強すぎる！！
— Maki@Sunwood AI Labs. (@hAru_mAki_ch) February 27, 2025
これで
✅issueを作成
✅develop ブランチからissue用のブランチを作成
✅issue番号を付与してコミット
✅変更をプッシュ
✅issue をクローズ
✅develop ブランチにマージ
✅進捗レポートを issue に報告… pic.twitter.com/dR8DkCRLac
Windsurfとは
Windsurfは単なるAIコード補完ツールではなく、「AIフロー」という新しいパラダイムを実現した「エージェンティックIDE」です。これまでのAI活用には主に2つのアプローチがありました：
- コパイロット型: 開発者との協力を重視し、人間が常にループ内にいる方式。短いスコープのタスクに限定される。
- エージェント型: AIが独立して反復作業を行い、より大きなタスクを完了できる方式。ただし、協力的な側面が薄れる。
Windsurfはこの両方の長所を組み合わせています。AIが協力的かつ独立的であることを可能にし、開発者とAIが真に「マインドメルド（心を一つにする）」できるプラットフォームです。
GitHub/Gitワークフロー指示プロンプトの構造
今回活用したプロンプトは、GitHubとGitを使った開発フロープロセスを8つのステップに分解し、各ステップで実行すべきコマンドまで明示しています。
1. 📝 **gh コマンドで issue を作成してください**
```
gh issue create --title "✨ [タスク名]" --body "📋 概要：[概要説明]
🎯 目的：[目的]
📝 詳細：[詳細説明]
⏰ 期限：[期限]"
```
2. 📊 **進捗レポートを issue に報告してください**
```
gh issue comment [ISSUE_NUMBER] --body "🔄 進捗状況：[進捗率]%
✅ 完了した作業：[完了事項]
🚧 作業中：[進行中の事項]
🔜 次のステップ：[予定]"
```
3. 🔄 **develop ブランチに移動してください**
```
git checkout develop
git pull origin develop
```
4. 🌿 **このissue用のブランチを作成してください**
```
git checkout -b feature/[機能名]-[ISSUE_NUMBER]
```
5. 💻 **コミットは以下の点に注意してください**
- issue番号を付与してください (#[ISSUE_NUMBER])
- 日本語で内容を記述し、後から見たときに分かるようにしてください
- 絵文字を付与して可読性を上げてください
- こまめに分割してコミットしてください
```
git add [ファイル]
git commit -m "✨ #[ISSUE_NUMBER] [変更内容を日本語で]"
```
6. 🚀 **変更をプッシュしてください**
```
git push origin feature/[機能名]-[ISSUE_NUMBER]
```
7. ✅ **issue をクローズしてください**
```
gh issue close [ISSUE_NUMBER] --comment "🎉 完了しました！
✨ 実装内容：[実装した機能の概要]
🔍 レビュー結果：[レビュー情報]
📈 改善点：[将来的な改善案]"
```
8. 🔄 **最後は develop ブランチにマージしてください**
```
git checkout develop
git merge --no-ff feature/[機能名]-[ISSUE_NUMBER] -m "🔀 Merge: #[ISSUE_NUMBER] [タスク名]"
git push origin develop
```
さらに、コミットメッセージに使用する絵文字の例も含まれており、視覚的な情報でコミットの種類を瞬時に把握できるようになっています。
実際のワークフロー適用例
実際のプロジェクトでこのプロンプトを使用した例を見てみましょう。社内規定RAGエージェントのリファクタリングという具体的なタスクに対して、Claude 3.7 Sonnetが一連のGitワークフローを実行しました。
1. Issueの作成
> gh issue create --title "✨ 社内規定RAGエージェントのリファクタリング" --body "📋 概要：ファイル構造の整理とRAG機能の強化
🎯 目的：コードベースを整理し、社内規定RAGエージェントの機能を強化する
📝 詳細：
- 各エージェントを適切なディレクトリ構造に整理
- 社内規定RAGエージェントの実装を改善
- ドキュメントとREADMEの追加
- Docker環境の構築
⏰ 期限：2025-03-10"
Creating issue in Sunwood-ai-labs/agno-sample-company-Nyagora
https://github.com/Sunwood-ai-labs/agno-sample-company-Nyagora/issues/8
Claudeはプロジェクトの状況を分析し、リファクタリングの目的と詳細を的確に記述しています。期限も設定され、タスクの優先順位が明確になっています。
2. 進捗レポートの報告
> gh issue comment 8 --body "🔄 進捗状況：30%
✅ 完了した作業：
- ファイル構造の整理（エージェントを適切なディレクトリに移動）
- 社内規定RAGエージェントの基本実装
- Docker環境の構築（docker-compose.yml）
🚧 作業中：
- 社内規定RAGエージェントの機能強化
- アプリケーションとの連携調整
🔜 次のステップ：
- 変更をコミットしてプッシュ
- テストの実施
- ドキュメントの完成"
https://github.com/Sunwood-ai-labs/agno-sample-company-Nyagora/issues/8#issuecomment-2686480984
進捗状況を明確に記録することで、チームメンバーやステークホルダーは現在の作業状況を把握できます。完了した作業と今後のステップが明示されており、プロジェクト管理の透明性が高まります。
3-4. 作業ブランチの作成
> git checkout develop
M src/agents/base/base_agent.py
D src/agents/base_agent.py
D src/agents/inventory_agent.py
M src/agents/regulation/regulation_agent.py
D src/agents/regulation_agent.py
D src/agents/summary_agent.py
D src/agents/team_agent.py
D src/agents/translation_agent.py
M src/app.py
Already on 'develop'
Your branch is up to date with 'origin/develop'.
> git pull origin develop
From https://github.com/Sunwood-ai-labs/agno-sample-company-Nyagora
* branch develop -> FETCH_HEAD
Already up to date.
> git checkout -b feature/regulation-rag-8
Switched to a new branch 'feature/regulation-rag-8'
作業の基点となるブランチをdevelopから新規に作成し、issue番号を含む命名規則に従ったブランチ名を付けています。
5. こまめなコミット
Claudeは変更を適切に分割して、それぞれの変更内容に対応したコミットメッセージを作成しています。
> git add src/agents/base/base_agent.py src/agents/base_agent.py
> git commit -m "🔧 refactor #8: ベースエージェントを適切なディレクトリ構造に移動"
[feature/regulation-rag-8 b97eade] 🔧 refactor #8: ベースエージェントを適切なディレクトリ構造に移動
2 files changed, 3 insertions(+), 19 deletions(-)
delete mode 100644 src/agents/base_agent.py
> git add src/agents/regulation/regulation_agent.py src/agents/regulation_agent.py
> git commit -m "✨ feat #8: 社内規定RAGエージェントを適切なディレクトリ構造に移動し機能強化"
[feature/regulation-rag-8 4f3713e] ✨ feat #8: 社内規定RAGエージェントを適切なディレクトリ構造に移動し機能強化
2 files changed, 57 insertions(+), 50 deletions(-)
delete mode 100644 src/agents/regulation_agent.py
> git add src/agents/inventory_agent.py src/agents/summary_agent.py src/agents/team_agent.py src/agents/translation_agent.py
> git commit -m "🔧 refactor #8: 未使用のエージェントファイルを整理"
[feature/regulation-rag-8 afcb4a4] 🔧 refactor #8: 未使用のエージェントファイルを整理
4 files changed, 77 deletions(-)
delete mode 100644 src/agents/inventory_agent.py
delete mode 100644 src/agents/summary_agent.py
delete mode 100644 src/agents/team_agent.py
delete mode 100644 src/agents/translation_agent.py
> git add src/app.py
> git commit -m "🔄 update #8: アプリケーションのインポートパスを新しいディレクトリ構造に対応"
[feature/regulation-rag-8 10ab33c] 🔄 update #8: アプリケーションのインポートパスを新しいディレクトリ構造に対応
1 file changed, 18 insertions(+), 10 deletions(-)
> git add "src/agents/regulation/Nyagora社の人事規定.md" src/agents/regulation/README.md docker-compose.yml
> git commit -m "📚 docs #8: 社内規定ファイルとREADMEの追加、Docker環境の設定"
[feature/regulation-rag-8 1fede07] 📚 docs #8: 社内規定ファイルとREADMEの追加、Docker環境の設定
3 files changed, 138 insertions(+)
create mode 100644 docker-compose.yml
create mode 100644 "src/agents/regulation/Nyagora\347\244\276\343\201\256\344\272\272\344\272\213\350\246\217\345\256\232.md"
create mode 100644 src/agents/regulation/README.md
各コミットには：
- 適切な絵文字（🔧 refactor、✨ feat、🔄 update、📚 docs）
- issue番号の参照（#8）
- 日本語での具体的な変更内容の説明
が含まれており、コミット履歴から作業内容を容易に理解できるようになっています。
6. 変更のプッシュ
> git push origin feature/regulation-rag-8
Enumerating objects: 36, done.
Counting objects: 100% (36/36), done.
Delta compression using up to 16 threads
Compressing objects: 100% (28/28), done.
Writing objects: 100% (28/28), 6.76 KiB | 3.38 MiB/s, done.
Total 28 (delta 13), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (13/13), completed with 5 local objects.
remote:
remote: Create a pull request for 'feature/regulation-rag-8' on GitHub by visiting:
remote: https://github.com/Sunwood-ai-labs/agno-sample-company-Nyagora/pull/new/feature/regulation-rag-8
remote:
To https://github.com/Sunwood-ai-labs/agno-sample-company-Nyagora.git
* [new branch] feature/regulation-rag-8 -> feature/regulation-rag-8
7. Issueのクローズ
> gh issue close 8 --comment "🎉 完了しました！
✨ 実装内容：
- ファイル構造の整理（各エージェントを適切なディレクトリに配置）
- 社内規定RAGエージェントの機能強化
- 社内規定ファイルとREADMEの追加
- Docker環境の構築（PostgreSQL + pgvector）
🔍 レビュー結果：
- コードの可読性が向上
- ディレクトリ構造が整理され、メンテナンス性が向上
- RAG機能が正常に動作することを確認
📈 改善点：
- 将来的には他のエージェント（要約、翻訳、在庫管理）も同様の構造に整理する
- テストケースの追加
- エラーハンドリングの強化"
✓ Closed issue Sunwood-ai-labs/agno-sample-company-Nyagora#8 (✨ 社内規定RAGエージェントのリファクタリング)
Issueをクローズする際、実装内容、レビュー結果、将来の改善点を詳細に記録しています。これにより、タスクの完了状況と成果が明確になるだけでなく、将来の改善点も記録されています。
8. developブランチへのマージ
> git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
> git merge --no-ff feature/regulation-rag-8 -m "🔀 Merge: #8 社内規定RAGエージェントのリファクタリング"
src/agents/base_agent.py | 18 -----
src/agents/inventory_agent.py | 16 ----
...272\272\344\272\213\350\246\217\345\256\232.md" | 67 ++++++++++++++++
src/agents/regulation/README.md | 55 +++++++++++++
src/agents/regulation/regulation_agent.py | 90 ++++++++++++++--------
src/agents/regulation_agent.py | 17 ----
src/agents/summary_agent.py | 15 ----
src/agents/team_agent.py | 30 --------
src/agents/translation_agent.py | 16 ----
src/app.py | 28 ++++---
12 files changed, 216 insertions(+), 156 deletions(-)
create mode 100644 docker-compose.yml
delete mode 100644 src/agents/base_agent.py
delete mode 100644 src/agents/inventory_agent.py
create mode 100644 "src/agents/regulation/Nyagora\347\244\276\343\201\256\344\272\272\344\272\213\350\246\217\345\256\232.md"
create mode 100644 src/agents/regulation/README.md
delete mode 100644 src/agents/regulation_agent.py
delete mode 100644 src/agents/summary_agent.py
delete mode 100644 src/agents/team_agent.py
delete mode 100644 src/agents/translation_agent.py
> git push origin develop
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 300 bytes | 300.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To https://github.com/Sunwood-ai-labs/agno-sample-company-Nyagora.git
77efa23..882828e develop -> develop
最後に、--no-ffフラグを使用した非早送りマージにより、ブランチの履歴を明確に残しています。これにより、将来的にこの機能追加の全コミットを一括で把握することが容易になります。
Claude 3.7 Sonnetのユニークな貢献
このワークフローにおけるClaude 3.7 Sonnetの貢献は単なるコマンド実行の支援だけではありません。
1. 状況分析と理解
Claudeは最初にgit diff --statコマンドを実行してプロジェクトの変更状況を把握し、どのファイルが変更されているかを分析しました。その上で、適切なissueの内容を自動的に判断しています。
> git diff --stat
src/agents/base/base_agent.py | 4 +-
src/agents/base_agent.py | 18 -------
src/agents/inventory_agent.py | 16 ------
src/agents/regulation/regulation_agent.py | 90 +++++++++++++++++++------------
src/agents/regulation_agent.py | 17 ------
src/agents/summary_agent.py | 15 ------
src/agents/team_agent.py | 30 -----------
src/agents/translation_agent.py | 16 ------
src/app.py | 28 ++++++----
9 files changed, 78 insertions(+), 156 deletions(-)
2. 論理的なファイルグループ化
コミットの際、Claudeは関連するファイルを論理的にグループ化し、それぞれに適切なコミットメッセージを付けています。例えば：
- ベースエージェントの移動（構造変更）
- 規定エージェントの移動と強化（機能追加）
- 未使用ファイルの整理（リファクタリング）
- アプリケーションパスの更新（連携調整）
- ドキュメントとDockerの追加（環境構築）
各コミットは単一の論理的な変更に対応しており、コードレビューがしやすく、問題が発生した場合の原因特定も容易になります。
3. 詳細な進捗と完了レポート
進捗報告やissueクローズ時のコメントは、単に「完了しました」というだけでなく、具体的な達成内容、レビュー結果、将来の改善点まで含む包括的なものになっています。これはプロジェクト管理の観点から非常に価値のある情報です。
Windsurfを利用したAIとのシームレスな協働
Windsurfの「AIフロー」環境下では、Claudeが実行したGitコマンドとその結果、そして次のステップの判断が一連の流れとして自然に表示されます。この体験は従来のAIアシスタントとは大きく異なります：
- コンテキスト認識: Claudeはプロジェクト全体の状況を把握した上で作業を進めています
- 自律的判断: 各ステップで何をすべきかを自律的に判断しながらも、人間の介入を許容
- フィードバックループ: 各コマンドの結果を解析し、次のアクションを決定
- 説明と教育: 各ステップで何をしているかを説明し、開発者の理解を助ける
このアプローチの利点
GitHub/Git ワークフロー指示プロンプト + Windsurf + Claude 3.7 Sonnetの組み合わせによる主な利点は以下の通りです：
1. 一貫性の確保
チーム全体で同じGitワークフローが適用されるため、コードベースの一貫性が向上します。新人開発者でも、Claudeのガイダンスに従うことで、チームの標準に則った方法で作業できます。
2. 時間短縮
繰り返しのGit操作をClaudeに任せることで、開発者は実際のコード実装に集中できます。Claudeはissueの作成からマージまでの一連の流れを迅速かつ正確に実行します。
3. エラー削減
手動でのGit操作は人為的ミスが発生しやすいですが、Claudeは指示された手順を正確に実行します。特に複雑なマージやリベース操作での事故を防げます。
4. 知識移転
AIがGitの各操作を説明しながら進めるため、開発者（特に初心者）にとってはGitのベストプラクティスを学ぶ機会になります。
5. 詳細な記録
各ステップで詳細な情報がissueコメントやコミットメッセージに残るため、プロジェクトの進捗状況や変更履歴が明確になります。
実践のためのヒント
このアプローチを自分のプロジェクトに適用するための実践的なヒントをいくつか紹介します：
1. プロジェクト固有のワークフローを定義
紹介したプロンプトをベースに、自分のプロジェクトやチームに合わせたワークフローを定義しましょう。ブランチ命名規則、コミットメッセージのフォーマット、レビュープロセスなどを含めると良いでしょう。
2. テンプレートの作成
繰り返し使用する指示プロンプトはテンプレート化しておくと便利です。issue作成、PRレビュー、リリースプロセスなど、異なるシナリオ用のテンプレートを用意しておきましょう。
3. AIの判断をレビュー
完全に自動化するのではなく、重要なポイントでAIの判断を確認する習慣をつけましょう。特にマージ操作やissueクローズなど、取り返しのつかない操作の前には確認が重要です。
4. 継続的な改善
AIとの作業体験から学び、プロンプトやワークフローを継続的に改善していきましょう。うまくいかなかった部分や、より効率化できる部分を特定し、テンプレートを更新します。
まとめ
GitHub/Git ワークフロー指示プロンプト + Windsurf + Claude 3.7 Sonnetの組み合わせは、開発プロセスを根本から変革する可能性を秘めています。AI技術の進化により、これまで開発者が手動で行っていた多くの作業を自動化しながらも、人間の判断やクリエイティビティが生きる新しい開発スタイルが実現します。
GitHubでの作業はコードの実装以外にも多くの時間を要しますが、この組み合わせによって、開発者はより創造的な作業に集中できるようになります。また、チーム全体でのベストプラクティスの共有と適用が容易になり、プロジェクトの質と効率の両方が向上するでしょう。
Windsurfのような「AIフロー」を実現するプラットフォームと、Claude 3.7 Sonnetのような高度なAIモデルの組み合わせは、ソフトウェア開発の未来を形作る重要な要素となるでしょう。この記事で紹介したアプローチを試して、あなたの開発プロセスがどのように変わるか体験してみてください。
関連リンク: