はじめに
こんにちは！テクノロジー統括本部 プロダクト開発本部 開発2部 在庫管理チームでバックエンドエンジニアをしている、25卒の大石（umaidashi18）です。4月に入社したばかりですが、すでに内定者インターンを始めていたので、その期間の取り組みについて記事にします。
弊社の CTO であり CTO 協会理事でもある kyuns さんは、企業を変革させていくときのキーワードとして2つの DX を掲げています。
- 企業のデジタル変革を意味する「Digital Transformation（DX）」
- ソフトウェア開発者にとっての働きやすい環境と高速な開発を実現するための文化・組織・システムが実現されているかを意味する開発者体験「Developer eXperience(DX)」
また、先日発表された中期経営計画でも、AI Agent を用いて事業を推進していくための目標が記載されました。
この2つの DX と、中期経営計画の実現のためにも、弊社では AI ツールを積極的に活用していく必要があります。
バイセルのAI活用の現状
バイセルでは、これまでも社内向けツール「BuySell Buddy」を開発し、エンジニアだけではなく事業部の方々にも生成AIを使ってもらえる環境を整えていました。
また、2月上旬に Devin を導入し、3月末時点で約560件のタスクを依頼し、約2600ACUs を消費しています。
2月中頃には、 Cursor の Business プランを導入し、より手軽に AI を活用した開発に取り組めるようになりました。
AI ツールの活用事例
このような状況で、DevinやCursorといったAIツールを活用した開発の取り組みについて、社内で実施したハッカソンや1ヶ月間の業務利用で得られた知見を紹介します。
同じ内容で過去に登壇したので興味のある方は合わせてご参照ください。
Devin の活用事例
先述の通り、 Devin に依頼したタスクの量は600近くなり、依頼するタスクの種類や精度を向上させるためのノウハウが蓄積されてきています。
Devin の使用を開始した当初は次のようなプロンプトで、指示が曖昧で漠然としたタスクを与えていましたが、
最近では、タスクを分割したプロンプトを与えるようになり、エンジニアの習熟度が上がってきています。タスクの詳細も、 Jira を参照して具体的なタスクを与えるようになりました。
Devin に依頼したタスクを大きく分類すると、以下のようなタスクがありました。
- 実装系
- PR レビュー
- テスト関連
- コミュニケーション支援
- ライブラリー、パッケージの管理
- セキュリティ対応
- ドキュメント作成
- 動作確認
今回はその中から、開発チームで負担が大きく、取り組んでみて知見が多かった Devin による「動作確認」について詳細を紹介します。
動作確認
Cosmos プラットフォームの在庫管理サービス「Stock」を開発している在庫管理チームでは、リリース前に影響のある機能や画面について、検証環境にて手動テストを実施しています。これを、Devin に任せることで週次で担当しているエンジニアの負担を減らそうという取り組みを行いました。
手順
- Devin が検証環境にアクセスするための下準備
Cosmos プラットフォームでは、検証環境にて IP 制限をしているため Devin の IP アドレスをホワイトリストに追加する必要がありました。
併せて、 Cosmos プラットフォームのアカウントを管理している基盤サービスにて、Devin のアカウントを作成しました。
- Devin の Web アプリケーション上で、認証情報を Secret に登録
Cosmos プラットフォームの認証基盤を突破するための認証情報を Secret に登録しました。認証情報を使ってログインすることをプロンプトで指定することで、Devin が検証環境にアクセスできるようになりました。
- テスト項目をプロンプトで指示
テスト項目ごとに、操作ステップを明示的に書き、それに従ってテストを行うことをプロンプトで指示しました。
メリット・デメリット
メリットは、エンジニアが動作確認をする必要がなくなり、動作確認にかかっていた週に30分ほどの時間を、二人分削減することができました。
しかし、プロンプトの作成にかかる手間や、動作確認にかかるACU数などコスト面での課題も明らかになりました。
Devin にプロンプトによって動作確認の手順を指示する際に、「在庫を販売登録して」という指示だけではどの画面でどのような操作を行うのか Devin は知らないため、ステップバイステップで具体的な操作を指示する必要がありました。
Magic Pod や Playwright などの E2E テストツールにおいて動作確認手順を細かく定義する必要があるように、 Devin に任せてもその手間は解消できませんでした。 しかし、 Devin の Playbooks などを用いて指示を使いまわしたり、学習機能を活用することで、ある程度の効率化が見込めると感じています。
Cursor の活用事例
Cursor についてもPdM陣などを含め3月末時点で40人以上が使っています。
AI Agent / Tool を跨いだ Knowledge の共有
Cursor に関連して、 Devin や Cline を導入している在庫管理チームで、 AI Agent / Tool を跨いで共通の Knowledge を利用する取り組みについて紹介します
在庫管理チームでは、 Devin, Cursor (+Cline) といった複数の AI コーディングツールを同時に使用していますが、基本のコーディングルールや実装方針などはどのツールにおいても同じです。
そこで、在庫管理チームでは、 Cursor の公式が推奨している .cursor/rules/* に定義したルールをマスタとして、 Devin や Cline にはこれを読ませることで、共通の Knowledge を利用することにしました。
> Before Starting Work > - Be sure to read `.cursor/rules/project-structure.mdc` to understand the project structure before starting any tasks. > - Also, read `.cursor/rules/coding-guide.mdc` to understand the coding guidelines before proceeding with any implementation.
これにより、ツール間での Knowledge の共有が効率的に行えるようになりました。
メリット・デメリット
メリットとしては、Cursor の公式が推奨しているルールをマスタとして、 Devin や Cline にはこれを読ませることで、共通の Knowledge を利用することができるようになりました。
デメリットとしては、Devin には独自で Session から Knowledge をアップデートする機能があるため、Cursor の Knowledge と乖離してしまうことや、知見が蓄積されていくにつれて Devin と Cursor の使い分けが進むなどの理由で、必要な Knowledge がそもそも変わることが懸念されます。
AIツール普及の取り組みと成果
2月に利用を開始した Devin などの AI ツールを導入してすぐは、学習コストの高さなどから、特定のチームでしか十分に活用できていない状態が進んでいました。
そこで、 3/7 に Tech AI Hackason #1 を開催しました。
ハッカソンを通じて、それまで利用できていなかったエンジニアも Devin や Cursor, MCP などの AI ツールを体験することができ、その後の業務で積極的に活用する人が増えました。
当日の流れ
チームや個人での参加が認められ、約30人が事前にやることを決めた上で当日を迎えました。
テーマは各々で設定し、各チームが抱える課題解決に取り組む参加者や、より高度な使い方を模索する参加者もいました。
当日は、以下の流れでハッカソンが開催されました。
- はじめに
- もくもく作業タイム
- 中間発表
- もくもく作業タイム
- 最終発表
当日の様子↓
x.com本日、バイセルでは生成AIを用いたハッカソンを実施しています！
— BuySell Dev (@BuySell_Dev) 2025年3月7日
DevinやCursorを積極活用して、以前から欲しかったツールを開発したり、普段の業務を楽にできないか、皆で試行錯誤しています💪
今日1日でDevinのACUsを600近く使っていて少し肝が冷えますが……実際に触ってみるのが大事ですからね👍 pic.twitter.com/jfaAU16krC
ハッカソンの成果物のうち、共有できるものに絞っていくつか紹介します。
MCP Server の開発 by oishi
最近 X などで MCP が注目されているように、私も MCP のようなプロトコルを通じて LLM とつなぐ仕組みは、バイセルの2つの DX の達成に必要な要素だと感じているため積極的にキャッチアップしています。そのため、私は当日 MCP Server の開発を行いました。
開発した MCP Server は、Tools を使って CRUD 処理ができるシンプルな MCP Server と、ローカルに立てている API サーバーの Swagger 情報を解析して、自然言語からエンドポイントを特定し、実装に必要な型情報などを取得する MCP Server の2つです。
デバッグには公式が用意している Inspector を使用しました。
MCP Server の開発には、Cursor で Building MCP with LLMs を使用し、いわゆるバイブコーディングを行いました。ハッカソン特有の作って壊してのサイクルを高速に行い、AI に任せることで同時に発表資料の作成も行うことができました。
OpenAPI が整備されていれば、Swagger 情報からリクエスト情報を取得し、LLM が活用することは容易でした。今後の展望として、API サーバーの動作確認時に必要な API リクエストを Swagger からスキーマを取得し、そのスキーマに当てはめる値をデータベースから取得し、その値を用いて API リクエストを行うような MCP Server を開発したいと考えています。
Sentry 通知のエラー調査・修正の自動化
Sentry で検知されたエラーの調査・修正を自動化する取り組みを行いました。この取り組みでは、エラーが発生した際に Devin が自動的に調査を行い、修正可能な場合は PR を作成し、修正が困難な場合は issues にサマリーを報告する仕組みを構築しました。
Sentry と Devin を連携させるために、Google Cloud Functions を活用し、Sentry からの webhook を受け取り、Devin に転送する中継点として機能させることで、スムーズな連携を実現しています。Webhook のペイロード構造の解析は Devin に任せました。
今後の展望としてデータベースを参照した詳細な調査や Slack への自動報告機能まで実装したいと考えています。
開発過程での主な課題は、エラーが発生しないと動作確認ができないという点でした。このような自動化の取り組みは、エンジニアの作業負荷を軽減できると考えているため、今後も積極的に取り組んでいきたいです。
Cursor から Figma MCP Server に接続してコンポーネントを作る
MCP サーバーを活用して Figma のデザインから直接 React コンポーネントを生成する取り組みを行いました。Cursor のプロンプトに対象となるコンポーネントの Figma リンクを渡すことで、ピクセル単位の正確な情報を含むコンポーネントを自動生成することに成功しました。
実装されたコンポーネントは、チームで定めているコーディングガイドの一部（useMemo の使用やコンポーネントの外に margin を指定しないなど）に従った形で生成されることが確認できました。ただし、完全にコーディングガイドに準拠し、そのままマージ可能な状態まで持っていくことは今回のハッカソンでは達成できませんでした。
通常、UI コンポーネントの実装時にはスクリーンショットを参照することが一般的ですが、今回のように Figma と直接連携することで、より正確なピクセル単位の実装が可能になることが分かりました。
AI との協働 / 開発プロセスの変化
これまで紹介した通り、バイセルでは Devin、Cursor、その他のエージェントを開発支援ツールとして導入しています。私がこれらのツールを活用する中で、それぞれを人間がどのように使い分けるべきかについて考えた個人的な見解をまとめてみました。
考え方として、「どのようなタスク」に「どのようなツール」を使うかという2軸があると考えています。まずは「どのようなタスク」かについて考えてみます。
「どのようなタスク」
前提として、私の意見は kmagai さんの次の記事に大きく影響を受けています。
この記事では、AI をシステム開発に活かすコツとして、「完全情報」に近いタスクほど、AI の精度が高くなるということが書かれています。AI の精度を最大化するためには、人間がタスクを「完全情報」の状態にどれだけ近づけるかが鍵になります。逆に、「完全情報」から遠いタスクほど AI の精度が低くなり、人間が介入する必要が出てきます。
この考え方に基づいて、タスクを「完全情報」に近づけるためにどれだけのコストがかかるのか、どこまで完全情報に近づけられるのかによって、AIツールを使い分けるべきだと私は考えています。
「どのようなツール」
次に、「どのようなツール」を使うかという軸について考えてみます。
これまでにあげた Devin, Cursor, Cline を使い方・特徴などをもとに分類してみました。
※ 私の主観が含まれています
| Agent | 特徴 |
|---|---|
| Devin | 自律型、最後まで一人でやれる 人間は指示とその結果を見るのがメイン |
| Cursor Agent Mode | エディタ上で動作し、人間が適宜起動修正できる （3月頭時点で）Clineより制御がしづらい。暴走する |
| Cline | エディタ上で動作し、人間が適宜起動修正できる （設定によるが）都度指示することも可能 |
どれも AI によるコーディングを可能にするツールですが、それぞれのUIやコンセプトの違いから、人間の介入度合いやタイミングが異なります。
ツールの特徴を考慮すると、先述した「完全情報」に近いタスクは、AI の精度が高くなるという前提のもと、自律型で人間の介入度が低い Devin に任せるのが良さそうです。
逆に、「完全情報」から遠いタスクは、タスクを渡した時点での情報では AI が十分な精度を発揮してタスクを完了するのが難しいため、適宜人間が介入してタスクを修正していく必要が出てきます。そのため、 Cline や Cursor Agent Mode のような手元のエディター上で動作し、人間が適宜介入できるツールを使うのが良さそうです。
これらの考え方を図にまとめてみました。
最初のステップでは、 Cursor の Chat モード（現在の Ask）を使い、コードベースを読ませたり、 MCP Server を使用してコンテキストをふんだんに取り入れることで、タスクを「完全情報」に近づけることを目指します。
次のステップでは、最初のステップのアウトプットが「完全情報」に近いかどうかを判断し、その度合いによって使用するツールを振り分けます。
例えば、バグの修正などで原因がすべてわかっていて、何をするべきか明確で指示を出すだけであれば Devin に任せるのが良いです。
逆に、実装パターンに検討の余地があって完全情報ではない場合は、 Cline や Cursor Agent Mode に、
さらに完全情報からはほぼ遠く、AIに任せるとレビューにも大きなコストがかかる場合は、人間がやるというような使い分けが今の所現実的だと思っています。
まとめ
これまで紹介した通り、バイセルでは Devin や Cursor などの AI ツールを積極的に活用しています。Devin の活用範囲は広く、PR レビューや動作確認にも使用できます。Cursor についても、MCP Server を使用して、様々な可能性を引き出せることがわかりました。また、Devin や Cursor のツールをどういった場面で使い分けるかについて、私の考え方を紹介しました。
これらのツールを使用するためには学習コストがかかりますが、組織内で同期的なコミュニケーションを行ったり、ハッカソンを通じてキャッチアップする機会を設けることで利用率も上がり、導入も進みました。また、AI を活用することによる業務改善の余地も発見し、学習コストに対するリターンも見込めました。
これからは、冒頭に述べた「2つの DX」を達成するために、AI エージェントを介した業務オペレーションを構築する取り組みと、開発者体験の向上に挑戦していきます。
バイセルでは生成AIを活用してプロダクト作りを行うエンジニアを募集しています。Devin や Cursor をガンガン使用できる環境が整っていますので、気になった方はぜひご応募お待ちしています。
