こんにちは。kickflow エンジニアの芳賀と申します。
AIエンジニア界隈、すごく盛り上がっていますよね。
私としてもお仕事がなくなってしまうのではないかと戦々恐々としております（笑）

そんな中、弊社にも Devin ちゃんがジョインしております。
本記事ではDevinを開発で活用した事例についてご紹介します。

Devinとは

もうみなさんすでにご存知かと思いますが…

Devin is a collaborative AI teammate Built to help ambitious engineering teams achieve more.

Devin（デビン）は協働型AIチームメイトであり、意欲的なエンジニアリングチームがより多くを達成できるよう支援するために構築されました。

とのことで、コーディング、実行、テストまでできる
自律的なソフトウェアエンジニアだそうです。
コードのリファクタリングやPull Requestのレビュー、ユニットテストと様々なことができます。

と、Devinが翻訳してくれました。
若干もったいない使い方ですが、これだけでも私は大助かりです（笑）

実際に私もフロントエンドのコードを共通化するために一旦 Devinに当ててみて、方向性が同じだったら
細かい箇所の修正などをしてPull Requestを出す、ということができています。

使った印象としては、「明瞭な指示をきっちりやってくれる新入社員」といった感じでしょうか。
初回の指示内容が大切だと思っており、事細かに書けばその通り動いてくれますし、「曖昧な指示から具体化する」といった対話方法だと途中でコミュニケーションのズレが発生し、うまく伝えきれなかったことが多かったです。
「自分の中でゴールを明らかにし、そこに到達するまでのステップを明瞭化して伝える」というのが一番のキモかなと思っております。
…なんだか書いててマネジメント論みたいな文体になってしまいましたね。

さて、次のセクションから実際の開発で活用した事例についてご紹介いたします。

実際の事例

kickflowはバックエンド（Rails）とフロントエンド（Nuxt）の2段構成になっています。
両者の間のAPI呼び出しで、想定していないパラメータを渡される可能性がありました。
それを防ぐため、「内部用APIにOpenAPI導入プロジェクト」が発足しました。

本開発によって得られる恩恵としては以下があります。

OpenAPIで定義することでRspecでリクエストパラメータを検証できる（重要）
明文化されることによる
- 不具合発生の抑止
- API理解の促進

この件については、チーム内の皆が「やったほうがいい」と思いつつ、後回しにしてしまっていました。
というのも、最低でも240個のエンドポイントに対してスキーマファイルを書く必要があるからです。

わぁ・・・
人間では無理だぁ・・・

けど、この作業、Devinにとっても向いていると思いませんか？
ということでここでDevinの登場というわけです。

やったこと

作業の整理

実際にエンドポイント1つに対しての作業をトレースすると以下になります。

ブランチを切る
対象のエンドポイントからスキーマファイルを作成する
対象のエンドポイントのコントローラーを探す
見つけたコントローラーから API の定義を転写する
Rspec でコケていたら修正する
Pull Request を出す

こちらを数件私で作業し、問題ないことを確認しました。
どうせならすべてDevinにお任せしたいところでしたが、Devinに依頼する際に例があるとないのではDevinに結構な性能差が出るので作業しました。
ここからDevinの適用へ移ります。

Devinへの適用

ということで、下地はできました。
前章の手順をDevinに適用するために最適化していきます。
具体的には以下のプロンプトになりました。
ここで前章で作成したファイルを「お手本」として参照させることでDevinの精度を上げています。

- （ファイル名）を作成してください
- 各パラメータは（コントローラー名）の（メソッド名）を参照してください
- yaml の書き方は「（手作業で作ったファイル名1）」や「（手作業で作ったファイル名2）」を参照してください
- （ルートのスキーマファイル名）に（ファイル名）のAPIを参照するパスを追記してください
- ブランチは（ブランチ名）から切り出してください
- PR の向き先は（切り出した元のブランチ名）にしてください
- PR のタイトルは（タイトル名）にしてください
- PR の Assignee に（ユーザー名）を追加してください

※ 括弧が多くて恐縮ですが、この部分がプロンプトの変数になる箇所です

実際に以下のような形でSlackから依頼しました。

すると対象ブランチからブランチを切り、よしなに処理をしてくれた後にPull Requestを作成してくれます。変更が足りていない場合はPull Requestからコメントすることでいい感じに直してくれます。

結果、無事に作業をDevinにお任せすることができました。

Devinの展開

さて、ここからが本領発揮です。
先ほどのプロンプトを自身の担当しているエンドポイントすべてに適用していきます。
開発対象のエンドポイントはスプレッドシートでまとめられているので、
そこに列をちょこっと足し、
プロンプトの変数を記入して、
プロンプトと合成することで、
プロンプトを一気に作成してしまいます。
画像の左側がエンドポイント、右側がプロンプトになっております。

あとはこれをSlackで流してPull Requestを確認、簡単ですね。
作業が終わってしまいました。Devinのレスポンスを待っている間はお茶でも飲んでまったりしておきましょう。

所感

開発を通して感じたこととして「あ、終わっちゃった」ということです。
それほど簡単に終わりました。体感にはなりますが、手作業で約30分かかるところがDevinだと約10分ほどで終わったかな、と思います。

また、この手のAIを利用する際は事前の準備がすべてを決めると感じております。
冒頭で、「自分の中でゴールを明らかにし、そこに到達するまでのステップを明瞭化して伝える」と書かせていただきましたが、まさにこれです。
自分でも「よくわからないこと」はDevinにとっても「よくわからないこと」です。ある程度の設計力や段取り力、先を見通す力が求められるのかもしれません。
対話的にやるのであれば、ClineでAntropicを利用するのがオススメです。