はじめに
Devinにコードを書いてもらうときに、なかなか思うようにコードを生成してくれないときがあります。今回は、どのようにしたらAIエージェントが意図したコードを書いてくれるか考えて行きたいと思います。
「Knowledge(ナレッジ)」について考える
Knowledge(ナレッジ)とは
DevinにはKnowledge(ナレッジ)があります。
ナレッジにコーディングルールや実装方針などを書くことで、Devinがナレッジを参照してコードを生成するようになります。
なので、ナレッジをしっかり書くことでエンジニアが意図したコードを生成してくれるようになります。
Knowledgeに書くこと
1. アーキテクチャ構成
- アーキテクチャの方針(例:Clean Architecture、MVVM)
- フォルダ構成とその意味(例:
presentation/は UI、domain/はロジックなど)
このプロジェクトでは Clean Architecture を採用しています。
- lib/
- common/:共通の例外処理・定数・ログ・拡張
- domain/:Entity, ValueObject, Repositoryインターフェース
- infrastructure/:API・DBアクセス・Repository実装
- presentation/:画面UI, ViewModel, State
2. コーディング規約
- プロジェクトで決まっているコーディング規約
- Lint設定(例:
flutter_lintsを使用)
- Dart公式のコーディング規約(Effective Dart:Style ガイドライン)を守ってください
- dart format による自動整形を必須とします。
- flutter_lintsを使用してください
3. 命名規則
- クラス名・関数名・変数名のスタイル(CamelCase, snake_case など)
- ファイル名とクラス名の対応ルール
- クラス名・型名:UpperCamelCase(例:UserProfilePage)
- 変数・関数名:lowerCamelCase(例:loadUserData)
- ファイル名・パッケージ名:snake_case(例:user_profile_page.dart)
- クラス名とファイル名は対応させる
4. 使用ライブラリと方針
- MTIライセンスのパッケージのみを使用して
- 具体的なパッケージ名を指定
- 使用パッケージ
- 状態管理:Riverpod
- データクラス:Freezed
- JSON変換:json_serializable
- アセット管理:flutter_gen
5. テスト方針
- 何を対象としてテストするのか(単体テスト、ウィジェットテスト)
- 使用するテストライブラリ (mockito)
- mockitoを使用してください
- lib/domainのentityとvalue_objectの単体テストを書いてください
6. コメント・ドキュメントルール
- コメントルールを書く
- コメント形式を書く
- publicなメソッドにはコメントを記載する
- 以下のコメント形式で書く
/// - param: [引数の内容]
/// - return: [戻り値]
7. Pull Request(PR)とレビューの基準
- PRタイトルや説明の書き方
- テストの追加義務
- 「feat: 〇〇」のようなPRタイトル(日本語)
- コード変更には必ずテストを含めること。
8. Gitブランチ戦略
- ブランチの命名規則、運用方針
- 例:
feature/xxx,bugfix/xxx,release/x.x.x
- main:リリース済み安定版
- develop:開発ブランチ
- feature/*:機能追加
- bugfix/*:バグ修正
9. コミットメッセージ規約
- Conventional Commitsなどを採用
- `feat: 新機能追加`
- `fix: バグ修正`
- `docs: ドキュメント修正`
「プロンプト」について考える
Devinのプロンプトとは
Devinにタスクを依頼するときに、プロンプトを入力してDevinに依頼します。
プロンプトが抽象的な場合、意図しない変更をDevinが行い、PRを作成してしまいます。
なので、変更の背景や変更について具体的な内容、明確な変更手順をプロンプトに書く必要があります。(Devinは公式でもジュニアエンジニアと言われているので、詳細に指示する必要がある)
Devin Spacesについて
タスクを実際に Deevin に実行させる前に、プロンプトを洗練・整理するための対話型プレイグラウンド機能です。(プレビュー機能で無料)
JiraやLinearと連携して使うことも可能です。(チケットにissue→Devin Spacesを書いて分析)
- Devin の信頼性評価機構(Confidence Scores):Devin の実行可否判断をセッション内で確認して修正することができる
- DeepWikiの統合:コードベースに関する解説やコード引用が Devin 内で直接参照可能
- Devin Spacesによる対話型タスク設計:対話しながらより明確なプロンプトを作成することができる
- Devin Spaces: https://app.devin.ai/spaces ※まだプレビューなので画面から行けない
プロンプトに書くこと
意図したPRを作成するために、エンジニアが詳細にプロンプトを設計する必要があります。
ただ、プロンプトに背景知識や手順などを1から細かく書くと多くの時間がかかります。
これに対して、以下を行うことで少ない時間で詳細なプロンプトを作ることができます。
※ テンプレートは「メタプロンプトテンプレートについて」を参照
-
Devin Spacesでメタプロンプト生成(AIがプロンプトを生成するためのプロンプト)
- メタプロンプトテンプレートを用意しておく
- メタプロンプトの作成のために「# 【コンテキスト】」、「# 【実行タスク】」をDevin Spacesで対話してたたき台を作ってもらう
- エンジニアはメタプロンプトの内容を確認・修正する
-
メタプロンプトからプロンプト生成する
-
エンジニアがプロンプトを確認・修正する
-
Devin Spacesでプロンプトが効果的かを評価
-
「このプロンプトをDevinで実行するときの信頼度を教えて」を冒頭につける
-
信頼度と改善点を伝えてくるので、改善→評価を繰り返す
このプロンプトをDevinで実行する際の信頼度について評価します。 信頼度評価: 非常に高い(95%以上) 高い信頼度の理由 ・・・・ 改善が必要な点 ・・・・
-
-
プロンプトをDevinで実行する
メタプロンプトテンプレートについて
Devinに機能を実装させるためのメタプロンプトのテンプレートを考えてみました。
「カウントアップ時に値をDBに保存するプロンプトのメタプロンプトを考えている。」などやりたいことをテンプレートを前につけて、メタプロンプト自体を生成するとたたき台も作ってくれます。
以下の情報より、Devinに渡すための効果的なプロンプトを生成してください。
Devinがタスク実行時に理解できるプロンプト形式で作成してください。
# 【コンテキスト】
## システムの概要
アプリケーションの概要・機能について書いてください。
(例:TODO機能を持つアプリです。)
## 技術スタック
どのような技術を使っているかを記載してください。
(例:言語:Dart(Flutter)、DB:SQLiteなど)
## アーキテクチャ
対象アプリのアプリアーキテクチャについて書いてください。
(例: MVVM, MVC, Clean Architectureなど)
## 設計原則
アプリで使用している設計原則について書いてください。
## 制限条件
セキュリティやパフォーマンスについて書いてください。
# 【実行タスク】
## タスクの目的・ゴール
タスクの目的・ゴールについて明確に書いてください。
タスクを実行したあとで、どのような結果になるか明確に記載してください。
(例:カウント保存機能が実装されることで、カウントが変更時されたらDBにカウントが保存される)
## タスク完了条件
タスクが完了する条件を記載してください。
(例:〇〇単体テストがクリアできている、+ボタンが押されたときに、DBに値が保存・更新されていることを確認する)
## 対象画面・モジュール
このタスクで対象となる画面や機能モジュールを記載してください。
(例:`CounterPage` ウィジェット、`counter_usecase.dart`)
## 機能概要
実装したい機能の概要について書いてください。
- どの画面にどんなボタンが追加されるか
- どのようなユースケースで機能が使われるか
- どのような処理の流れで実行されるか
## 実装概要
どのような機能実装の内容を想定しているか概要を書いてください。
## 参照ファイル・コード・クラス
今回のタスクで参照するファイルやクラスを書いてください。
(例:`README_ARCH.md`、`lib/main.dart`、`MainScreen`など)
おわりに
今回はDevinへのコンテキストとプロンプトについて考えていました。
先日あった「Devin Meetup Tokyo」でも有益な話が聞けたので、それらを踏まえて更に考えていきたいと思います!
参考