はじめに
こんにちは！
ネクスタで開発エンジニアをしている日野岡です。
弊社でも5月からDevinがチームにJoinし、活用方法を日々検討しています。
Devinは、Cognition AI社が開発したAIソフトウェアエンジニアです。単なるコード生成ツールではなく、要件の理解から設計、実装、テスト、デバッグまでを一貫して行える自律的なAIエージェントとして設計されています。ブラウザやターミナル、エディタを操作し、人間のエンジニアと同様の開発環境で作業を進めることができるのが大きな特徴です。
Devinの能力は非常に高いのですが、「どのような指示を出せば最大限の力を発揮してもらえるか」「生成されたコードをどうスムーズに既存の開発プロセスに組み込むか」といった課題を感じています。
この記事では、開発チームで現在試みている、DevinとGeminiを連携させた開発ワークフローについてご紹介します。
概要
この記事で伝えたい内容は以下の3つです。
-
Geminiによる要件定義の構造化:
- Slackのスレッドの断片的な情報や、バックログから、Geminiのカスタム指示（Gem）を使い、AIが理解しやすい形式の要件定義書を効率的に生成します。
-
Ask Devinによるシームレスな開発:
- 構造化された要件定義をAsk Devinに渡すことで、調査から実装、さらには開発ブランチへのPull Request作成までをシームレスに実行できます。
-
レガシー環境への対応とCI/CDの工夫:
- DevinのLinux実行環境と、既存のWindowsベース（.NET Framework）プロダクトとの間にあるギャップは、CI/CD環境を工夫することで乗り越えられます（られるはず！）。
では本題に入っていきます！
実際に試している開発ワークフロー
Devinの能力を最大限に引き出すため、以下のステップで開発を進めるフローを検討・構築しています。
ステップ1: Gemini Gemsによる要件定義書の自動生成
課題が議論されているSlackと、そこから起票されたバックログの内容を、そのままDevinに渡すと、回答精度がイマイチだったため、Devinが解釈しやすい形式に変換する必要がありました。
そこで、これらの情報をDevinが扱いやすいように構造化するため、Geminiの「Gem（カスタム指示機能）」を作成しました。
AI調査依頼生成Gem
以下は、私が使用しているGemのカスタム指示です。このGemの役割は、入力されたテキスト（Slackのスレッドの内容やバックログなど）から、AIエージェント（この場合はDevin）が実行すべきタスクを明確な指示書として出力できます。
Gem カスタム指示：AI調査依頼生成Gem
Gem カスタム指示：AI調査依頼生成Gem
役割と目標
- ユーザーから提供されたSlackスレッドの内容やバックログの説明文を分析し、AIが調査を行うために必要な明確かつ具体的な指示文を生成することを目標とします。
- ユーザーがAIへの指示作成に不慣れな場合でも、このGemを使用することで、効率的に質の高い調査依頼を作成できるように支援します。
- 生成される指示文は、AIが意図を正確に理解し、的確な調査を実行できるように構成されている必要があります。
入力
- 必須: 調査対象となるSlackスレッドの内容やバックログの説明文。
-
任意:
- 調査の目的や背景情報。
- 特に注目すべき点や、AIに強調してほしい点。
- 出力形式に関する要望（例：箇条書き、要約、詳細な報告書など）。
行動とルール
-
入力内容の分析:
- a) ユーザーから提供されたSlackスレッドの内容やバックログの説明文を注意深く読み込み、調査の目的、必要な情報、重要なキーワードなどを抽出します。
- b) ユーザーが調査の背景や目的を説明している場合は、それらの情報も考慮に入れます。
-
AIへの指示文生成:
- a) 分析結果に基づき、AIが調査を実行するために必要な指示文を生成します。
- b) 指示文には、調査の目的、調査対象、具体的な調査内容、期待される出力形式などを明確に記述します。
- c) AIが情報を適切に処理できるように、指示文は具体的かつ明確な言葉で記述します。
- d) 必要に応じて、AIに情報の優先順位をつけるように指示したり、特定の情報源を参照するように指示したりします。
-
出力形式の指定:
- a) ユーザーから出力形式に関する要望があった場合は、それに従って指示文を生成します。
- b) 特に要望がない場合は、調査結果が最も分かりやすく伝わる形式（例：箇条書き、表、要約など）をGemが判断して指示文に含めます。
-
補足情報の扱い:
- a) 指示文だけでは十分に意図が伝わらない可能性がある場合は、補足的な説明を追記することを許容します。
- b) 補足情報は、指示文の意図を明確にするためにのみ使用し、冗長にならないように注意します。
出力
-
主要な出力:
- AIが調査を行うための指示文。
- Slackやバックログの文章に書かれた内容も含めてください。
-
補足的な出力 (必要な場合):
- 指示文に関する簡単な説明や、使用上の注意点。
全体的なトーン
- 明確かつ論理的: AIが理解しやすいように、具体的で分かりやすい言葉を選びます。
- 客観的かつ中立的: 事実に基づいた指示を生成し、感情的な表現は避けます。
- 効率的: ユーザーが迅速に調査依頼を作成できるように、簡潔な指示を心がけます。
ステップ2: Ask Devinによる調査と実装の自動化
Geminiによって構造化された要件定義書が完成したら、次はいよいよDevinの出番です。
Ask Devinに、Geminiが生成した要件定義書を渡し、調査してもらい、後は「この調査結果に基づいて開発を進め、developブランチにPull Requestを作成して」といったゴールを伝えるだけで、修正作業は完結します。特に、Devinのプロンプト作成機能は優秀で、コードベースの文脈と組み合わせて、質の高い実行計画プロンプトを自動生成してくれます。この機能を活用することで、より効率的にDevinへ開発作業を依頼できます。
（※ただし、あくまでこれは単純なタスクの場合で、複雑なタスクには、もう少し具体的な指示や対話が必要です。）
このボタンを押すと、調査結果を元に自動でプロンプトが作成される
作成されたプロンプト
出来上がったプロンプトで、Devinに作業を依頼する
別の作業をしている間に、作業は完了
直面した課題: レガシー環境の壁
しかし、この先が問題でした。
Pull Requestの内容は、Devinはビルドもテストも行っていないという点です。
これは、Devinの実行環境と私たちのプロダクト環境とのギャップから発生しています。
- Devinの実行環境: Linuxベースの仮想マシン
- 弊社のプロダクト環境: .NET Framework 3.5 / 4.8 といった、Windows環境に強く依存するレガシーな構成が含まれている
これにより、Devinがコードを生成しても、それをビルドして動作確認を行うCIプロセスを、Devin自身で回すことができないのです。
つまりこれは、我々がDevinのテスターとして、生きていく事（ボトルネックになる事）を意味します。
（この未来は、この先、AGIが誕生した我々人間の未来を想像させます）
課題へのアプローチ: CI/CD環境の再構築
この問題（恐ろしい未来）を解決するため、現在、Devin用のCI/CD環境の構築に取り組んでいます。
具体的には、Windows Serverをテストサーバーとして用意し、そこにJenkinsをセットアップします。そして、DevinがGitHubにPull Requestを作成したことをトリガーとして、GitHub ActionsがJenkinsのビルドジョブを呼び出す、という連携を構築中です。
この仕組みが完成すれば、Devinによる開発の恩恵を受けつつ、レガシーなWindows環境でのビルドとテストを自動化できる見込みです。
まとめ
今回ご紹介したワークフローは、Devinを日々の開発に組み込むための一つの試みです。
もちろん、複雑なタスクにはまだまだ人の判断が欠かせませんが、AIの進化に合わせて開発プロセス全体を最適化していく作業は、この先、AIとの協働開発を行う上で、必須の試みだと感じています。
この取り組みが、皆さんの現場でのヒントに少しでもなれば幸いです。
Discussion