はじめに
こんにちは。暑さに弱いINVOY カードのエンジニアの武内です。
開発現場への AI ツールの導入が最近ホットですが、OLTA でも導入がちゃんと進んでいることをアピールしつつ、OLTA での Devin の活用事例を共有しようと思い、今回の記事を書きました。
この記事は以下のような方におすすめです：
- Devin の活用事例や Tips を知りたい方
- OLTA の開発環境に興味のある方
導入の経緯
前提として、OLTA では Devin 導入以前から ChatGPT や GitHub Copilot を利用していました。その際の話は、以下の記事にまとめていますので、ぜひご覧ください。
2025 年の 3 月までは、上記の通り ChatGPT と Github Copilot の 2 つのツールがメインでしたが、Devin や Cursor の台頭を受けて OLTA でも 2025 年の 3 月から Devin の試験導入を開始しました。
なお、導入の際にはいきなり開発メンバー全員に導入するのではなく、まずは数名のメンバーで試験的に導入し、効果を検証した上で全体に展開する形をとりました。この検証期間の間には対象のメンバーには Devin での開発を優先してもらい、効果を検証しました。
結果的に開発の生産性の向上が十分に見込めると判断し、2025 年の 4 月からは全ての開発メンバーに Devin を展開しています。
Devin 導入時に大変だったこと
前提として、Devin は 1 台の仮想コンピューター上に複数のレポジトリをクローンして、指示内容に沿った作業をやってくれるものになっています。
Devin のユーザーである私たち開発者は、Devin に対して「XXX のレポジトリにおいて YYY という作業をして欲しい」といった指示を出すことで、Devin がその指示に従ってコードを自動で編集してくれます。
この際に発生する問題としては、組織内で開発者ごとにレポジトリの権限を切り替えていたとしても、Devin 経由であれば開発者全員が Devin 上でセットアップされているレポジトリにアクセスできてしまいます。 しかし、Devin を使って Github 上に PR を作成しても、その PR の Merge までは Devin 経由ではできないようになっているので、OLTA では現時点では問題なしと判断しています。
このあたりの権限管理を厳格に制御したい会社では、Devin 導入に慎重になる必要があるかもしれません。
Devin を使って感じたこと
Devin を使って感じたことは以下の通りです。
コードの品質向上
Devin はコードの品質を向上させるために、コーディングルールやベストプラクティスに従ってコードを生成してくれます。また、人間と違って Typo を行わないのも大きなポイントです。
テストコードの作成の時短
Devin はテストコードの作成もサポートしてくれます。これにより、テストコードの作成にかかる時間が大幅に短縮されました。テストケースの過不足があれば指摘して Devin に修正してもらってもいいですし、ローカルで自身で修正しても良いです。
タスクの同時並行
Devin にコードを書かせている間に開発者が他のタスクに取り組むことができるようになりました。これにより、Devin に実装をさせている間に次のタスクの実装方針を考えておくなど、開発の効率が向上しました。
非エンジニアによるコードの編集
OLTA では PdM やデザイナーにも Devin を使ってもらっていて、UI の変更や利用規約の更新などの作業を Devin に依頼しています。この点についてはまだ試験的な運用ではありますが、Devin を使うことで非エンジニアのメンバーでもコードの編集が可能になり、エンジニアの負担を軽減することができることを目指しています。
Ask Devin が便利
Ask Devin という機能を使って Devin にコードについて質問を投げることができます。これにより、設計や実装の方針についての壁打ちを Devin と行ったり、障害時の原因の特定や解決策の提案を Devin に依頼することができるようになりました。 また、エンジニアのリソースを使わずに PdM や CS などのメンバーが実装についての質問を投げることもできるので、エンジニアの負担を軽減することができます。
Devin 活用の Tips
次に Devin 活用にあたっての Tips を紹介します。
Knowledge でのコーディングルールの設定
Devin では Knowledge という機能が用意されています。ここにはレポジトリごとのコーディングルールなどを設定することができ、Devin が紐づくレポジトリで作業をする際に Knowledge に記載された内容に沿ってコードを生成してくれます。
例えば、OLTA では以下のような内容を Knowledge に記載しています。
例：
- 言語ごとのコーディングルール
- 各レイヤーのインターフェースが変わる際のモック生成などのルール
- ロギング方針
- テストコードの書き方
- セッションでの開発者とのやり取りのルール
- PR の Description の書き方
Slack 連携の活用
Devin は Slack との連携が可能です。これにより、Devin との実行計画の確認などのコミュニケーションを Slack 上で完結させることができます。
Devin に全てを任せない
Devin には作業の 8 割を任せて、残りの 2 割を人間が作業することが公式からも推奨されています。 個人的な体感としても、細かい書き方の修正やテストコードの過不足対応などを都度 Devin に任せてしまうと実行計画の組み立てから実装までにそれなりの時間がかかってしまいます。 ある程度のところまで Devin に実装させたら、あとは自分で実装を進めるという形で使うのが良さそうです。
フィーチャーブランチ内の作業してほしい箇所に都度コメントを入れて指示
例えば Devin に対して一回のメッセージで実装内容の全てを指示しようとすると、XXX.go の 100 行目でこんな作業をして、YYY.go の 200 行目でこんな作業をして、それから...といった形で長い指示を出すことになってしまいます。
このような長い指示を Devin に送る前に見直すのは辛いので、作業内容が複雑になるにしたがって Devin に指示を出すのが億劫になってしまいます。
それに、新しい関数の作成が含まれる際には自分が想定していたシグネチャとは異なる関数が作成されてしまうこともあり、Devin の成果物に対しての手直しが大変になることも少なくないです。
そのため、ケースバイケースではあるものの、このようなケースでは私はまずはフィーチャーブランチを切っておいて、そこでインターフェースの変更や必要な関数やモデル定義を仮で行います。
その上で、コード内に「ここでこんな作業をしてほしい」といった Devin への指示をコメントとして残しておきます。
このやり方だと、サービス層での作業内容はサービス層のファイルに、ハンドラー層での作業内容はハンドラー層のファイルにという形で作業して欲しい場所ごとにコメントを残しておくことができるので、指示内容の見直しも比較的楽になります。また、関数やモデルの定義についてもこの時点でやっておけば、Devin がそれに従って作業をしてくれるので、想定外の成果物が提出されるリスクも減ります。
欠点としては、実行計画を組み立てる前に Devin が作業ブランチを切り替えてコード精査を行うため、作業開始までの時間が長くなることが挙げられますが、たいした時間ではないので許容範囲内です。
Devin が向かない作業
最後に Devin が向かない作業を一つだけ紹介します。
スキーマ定義やエンドポイントの追加
ここらへんの作業については、結局のところスキーマ定義を Devin に伝わるようにプロンプトとして書くか、自らコードに書くかの違いでしかないので、Devin に任せるメリットはあまりないと感じています。 最終的に Devin の成果物を自分で確認するのであれば、最初から自分で書いた方が早いケースが多い印象です。
まとめ
OLTA では Devin を導入して以来、開発の生産性が向上し、コードの品質も向上しました。特に、Devin を使うことで非エンジニアのメンバーでもコードの編集が可能になり、エンジニアの負担を軽減することができることを目指しています。
また、現在 OLTA では Cursor や Claude Code の試験的な導入も進めています。 現在は効果を検証している段階ですが、こういった開発ツールに触れられる機会のある職場で働けているのはありがたく感じるところが多いです。
OLTA としてはこのようなツールの導入をトップスピードでできているわけではないですが、試してみたいツールについての声があがれば積極的に導入を進めていく企業文化があるので、興味のある方はぜひ OLTA の求人をご覧いただきつつ、カジュアル面談にもご応募いただけると嬉しいです。 ぜひAI開発支援ツールの活用状況について話し合いましょう💪
