はじめに
10X ソフトウェアエンジニアの野々村です。元々アプリケーション開発者としてサーバーサイドを中心に仕事をしてきましたが、最近は協業する小売事業者様から受領したデータをネットスーパーに掲載できる状態へ加工する商品データパイプラインの開発に主に携わっています。
10x.co.jp
10XでもDevin AIを利用し始めて1ヶ月程度が経ったので、適用事例と展望について紹介します。
前提
Devin AI とは
Cognition AI社によって提供されるAIエージェントSaaSです。2024年12月に一般利用が開始され、各所で導入事例が紹介されています。
devin.ai
Devin AIの特性として、以下のようなタスクが得意とされています。
実装の検証が容易である
参考実装にアクセス可能である
Devin AIと適用領域の特性のマッチング
10Xでは私が開発に携わる商品データパイプライン領域においてDevin AIの特性がマッチするのではという仮説があり、導入検証を行いました。
弊社の商品データパイプラインは大きく、「小売事業者様から受領したデータを計算処理に渡すための共通フォーマットにクレンジング・結合・絞り込み・整形を行う箇所」と「検証されたデータセットを元に共通の計算処理を行う箇所」の2層で構成されています。
前者の小売事業者様に近いレイヤーは、小売事業者様ごとに個別のパイプラインが実装されています。一方で完全なワンオフではなく、開発者の認知負荷を削減するため、一定のルールに基づいた共通構造が実装されています。
商品データパイプラインのイメージ図
そのため、「ある小売事業者様向けのパイプラインで実装した内容を他のパイプラインに水平展開する」ようなタスクが頻繁に発生します。このようなタスクは以下のような点でDevin AIに依頼しやすいタスク群でした。
事前定義されたスキーマによって型制約を与えつつ実装が進められ、自動化された単体テストや結合テストで回帰試験が可能である → 作業中および作業完了後の検証容易性を担保できる
あるパイプラインへの実装を参考実装として渡してDevin AIに指示を出せる → 参考実装のアクセス容易性を担保できる
効果測定
導入による影響と費用対効果
商品データチームではスクラムを採用して1週間毎にSprintを回しています。4週間の消化StoryPointの比率からDevin AIを利用して対応したStoryPointを観測すると、概ね20-30%程度 の消化StoryPointへの貢献が見て取れました。
商品データチームはEMを含め4人で運営しているため、20-30%は単純計算でエンジニアを1人追加した程度のインパクトと言えます。
一方で費用についてですが、Devin AIの料金はACUと呼ばれる計算量の単位で決まります。
devin.ai
記述時点（2025/3/17）では$500/250ACUsが月間の基本料金であり、以降は$2/ACUの従量課金です。
検証期間中利用したACUは400ACUs程度でした。金額換算では$800程度になります。¥150/$で換算すると¥120,000程度となります。
開発ツールへの出費としては安くありませんが、開発生産性へ与える影響との比較で言えば破格と評価しています。
導入時の工夫
使い始めるためのドキュメントを整備する
AIエージェントを利用した開発は開発者の受け入れコストが小さくありません。自分の手元で完結するコーディングとは異なるマインドセット、ワークフローを要求しますし、そもそも仕組みの理解やサービスの仕様について理解しておく必要もあります。
まずは使ってもらわなければ妥当な検証が行えないため、社内でのプラクティスをまとめた手引を作成し、少しでも初回利用のハードルを下げてもらえるようにしました。
実際に作成した手引の目次（一部）
最小権限を付与する
Devinは高い自由度を持ちます。ミニマムでも対象GitHub Repositoryへのwrite権限を持つため破壊的な変更を実行できますし、例えばインターネットアクセス環境とブラウザを持つため、認証情報を持てば多くの環境にログインして作業することができます。しかしセキュリティ的に、あるいは本番オペレーターとして信頼できる水準では必ずしもないという事例も共有されています。
note.com
note.com
一方でDevinへのタスク委譲を考えると一定の権限付与は避けられません。例えば商品データパイプラインにおいては、BigQueryへのwriteができないと修正後のパイプラインにおいてスキーマの一貫性が保たれているかの検証ができません。
このようなケースにおいて、Google CloudのProjectレベルの権限を付与するのではなく、データセット単位の権限付与を行うことで意図せぬ開発環境への影響が起こらないようにしました。具体的にはDevinが作成するデータセットは所定のprefixを設定する運用とし、Google CloudのIAM Conditionsを用いて特定データセットへのみwrite権限を持つように定義しました。
cloud.google.com
10XではIAMをTerraform管理しているため google_project_iam_member resourceを用いて以下のように実現しています。
registry.terraform.io
resource "google_project_iam_member" "${resourceName}" {
project = "${projectId}"
role = "roles/bigquery.jobUser" # クエリ発行のために最低限jobUserが必要
member = "serviceAccount:{devin's ServiceAccount}"
}
resource "google_project_iam_member" "${resourceName}" {
project = ${projectId}
role = "roles/bigquery.dataEditor"
member = "serviceAccount:${devin's serviceAccount}
condition {
title = "only_owned_dataset"
description = "商品データパイプライン用のDevinは自分用のdatasetのみ編集可能"
expression = "resource.name.startsWith(\"projects/${projectId}/datasets/dbt_devin_sandbox_\")"
}
}
またDevin AIはSlack Appを用いたSlack Integration機能を持ちますが、このAppは参加したチャンネルの全メッセージの読み取り権限を持つため、所定のDevin連携用チャンネル以外では参加させない運用とし、予期せぬ情報漏えいを防ぐようにしました。
DevinによるPull Requestのレビュールールをチームで決定する
Devinが作成したPull RequestはGitHub上ではbot userが作成したものとなります。商品データチームの所管Repositoryでは、CodeOwnerによる1 approvalでマージ可能な運用としていたため、Devinが作成したPull Requestを依頼者がapproveすることで実質的なセルフレビューでのマージが可能になってしまいます。
これに対し我々のチームでは以下のような運用を決めて運用しています。
原則、依頼者 + 1名のapprovalでマージ可能とする
本番影響のないドキュメンテーション、テストコードの修正に限り依頼者のレビューでマージして良い
ドキュメンテーションの補填や欠けているテストの充足などもDevin AIに期待する役割に含まれるため、それらの速度を落とさず、一方で安全に本番運用を進めるために上記のようなルール設定としました。
Knowledgeは定期的にリポジトリにdumpさせる
Devin AIでは作業に必要な知識・コンテキストを Knowledge という形で登録することができます。
docs.devin.ai
作業毎にDevin AI側から更新を提案してくれるなど非常に便利な機能です。一方でチームのスタンスとして、今後Devin以外のAIエージェントやツールへの転換も十分あり得ると考えています。そのため、Devinに対し定期的に Knowledge をまとめたものをドキュメントにまとめてRepositoryに追記させ、重複するようになったKnowledgeは削除するような運用を取っています。
これにより、ロックインを避ける形でAI ReadableなRepositoryへの磨き込みを進めています。
今後の課題
適用範囲の拡大
今回の検証期間では商品データチームが主要なユーザであり、適用範囲はdbt, GitHub Actions等限定的でした。現在、terraformにて管理されるinfrastructure resourceやDartで実装されたアプリケーションコードへの適用を進めています。
開発チームのパフォーマンスへ与える影響については引き続き測定が必要ですが、特にDartのような静的型付けをもつ言語においては、SQLを主体とするdbtより直接に、高い表現力で値への要求を表現できるため、精度の向上が期待できるのではと考えています。
一方で技術的な課題として認証情報の使い分けがあります。DevinにSecret管理の機能はあるもののグローバルに利用可能なため、チームごとに最小権限で運用しようとすると一工夫が必要です。
docs.devin.ai
現状はSnapshotとして認証情報を保持した状態を保存し、作業指示する際に指定するような運用を想定していますが、改善の余地があります。
レビュー運用の仕組み化
上述の通り、現状のマージルールは運用によってカバーにしていますが、GitHub Actionsによる仕組み化を進めています。具体的には、Commit author および co-author*1 によるapproveしかない場合はfailするようなGitHub Actionsを実装し、GitHubのRuleSetにおいてrequiredとすることで、安全に運用できる状態を作ろうとしています。
導入しての所感
チームの生産性に与える影響はスケールアウト的
Devinを利用しての作業は概ね作業依頼と成果物のレビューというサイクルで成り立ちます。
Devinを使い倒すのであれば、例えばDevinに対して3件の作業を並列に依頼し、これを順次レビューしていくという方法も可能でしょう。一方でDevinに渡せるのは比較的ゴールの明らかな、複雑度の小さいタスクがメインとなるため、このようなタスクばかりを大量に消化するという場面も限定的です。
実際はDevinに定型的なタスクを依頼している裏で人間が複雑度の高いタスクを請け負う（あるいはDevinに渡すための最初の参考実装を作る）という働き方が最もうまく回るように感じました。
この場合、複雑なタスクと並行に簡単なタスクを進められるため、開発者の能力を高めるというよりは、既存の開発者と並列に作業を進めてくれるメンバーが追加されたような捉え方のほうが近いと考えます。
従って、今より複雑な課題が解けるというよりは、今までは後回しになりがちだった事にも適切に取り組めるようになるという工数制約の解消を期待する場合に、うまくフィットしそうです。
投機的な依頼という付き合い方
今のところDevinが作成する成果物は、常に100点を取ってくれるわけではありません。細かいところで意図と違う事をしてしまったり（ベタ移植して欲しいところを手直ししてしまったり、必要なコメントを消してしまったり…）、そもそも作業方針が期待と異なることも間々あります。
Knowledgeという形式で必要な知識を伝授したり、RepositoryにAIエージェント向けのヒントを拡充することである程度は精度を高められますが、それでも本番環境にリリース可能な成果物を常に生み出せるようになるまでにはしばらく時間がかかりそうです。
それまでの付き合い方として、投機的な依頼という付き合い方をチーム内には推奨しています。
依頼を投げてみて、人が作業すると4hかかるはずだった作業がうまくすると5-10minで完結する。もし細かいところが期待と異なっても、それを手直しすれば30minで対応できることがあります。
AIエージェントに確信を持って依頼できるタスクと、複雑度が高すぎて振りづらいタスクの中間に、できるかも知れないが完璧にはやれないかもしれないタスクが無数に存在します。これらを投機的に依頼してしまうことで、期待値としてのパフォーマンスは大きく伸ばしうると感じました。
We are hiring!
この記事では10Xの商品データチームにおけるDevin AIの導入について事例を紹介しました。
開発ツールとして考えると必要な費用が小さいツールではありませんが、開発生産性への影響は非常に大きいと捉えています。
生成AIの発展に伴いエンジニアリングの手法は大きな変革期を迎えつつありますが、この波を乗りこなしてともに10Xを作るメンバーを募集しています。
興味がおありのところがあれば、お気軽にカジュアル面談からお声がけください。
open.talentio.com
id:syou6162
