WinForms×.NET Framework環境へのDevinの導入事例
株式会社ネクスタ / hino-ok
チームリーダー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
Teams | Devin Sessions、Ask Devin、Deep Wiki、Devin Review | 11名〜50名 | 2025年5月 | B to B |
| 利用プラン | Teams |
|---|---|
| 利用機能 | Devin Sessions、Ask Devin、Deep Wiki、Devin Review |
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2025年5月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
今回の設計における最大の論点は、「LinuxベースのDevin」と「Windows + .NET Framework前提のSmartF」という非対称性をどう吸収するかでした。
結論として、以下の3つのアプローチでこの課題を解決しています。
Jenkins on Windows Server を残した理由
MSBuild、NuGet復元、WinFormsビルドなど、どうしてもWindowsでないと動かない要素が多く残っていたためです。無理に移行せず、既存のローカル資産をそのまま活かす判断をしました。
GitHub Actions を中間層に置いた理由
PRやPushを起点としたイベントの共通化(正規化)と、Jenkinsジョブを綺麗に呼び出すための「ハブ」となる層が必要だったためです。
失敗時の自動修正ループ
ビルドやテストが失敗した際、自動でDevinへ修正依頼を投げ、再Pushから再実行までをエージェントのループ内に閉じ込めました。「人間が手を動かすのは方針決定のときだけ」という状態を、システムとして物理的に強制する設計にしています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
当社の主力プロダクト「SmartF」は、製造業向けの生産管理SaaSです。約1,500カラム・300機能という大規模なシステムであり、.NET Framework 3.5/4.8 や WinForms といったレガシー資産を内包する基幹システムでもあります。
当時は、「着手したいけれど工数の都合で優先度を上げづらいバックログタスク」がじわじわと積み重なっていく状況にありました。さらに、長年の改修の蓄積による属人化や、複雑なコードベースにおけるコードレビュー負荷の増大が、開発チーム全体の生産性を向上させる上での「天井」になっていました。
どのような状態を目指していたか
最終的に私たちが目指したのは、「人間は方針決定に集中し、調査・実装・PR作成・テスト実行はAIが自律的に回す」という世界観です。
レガシー環境でも走り切れる基盤の整備: .NET Framework / WinForms というレガシースタックであっても、AIエージェントがタスクを完遂できる環境を整え、レガシー保守と新規開発を無理なく並行できる体制を確立すること。
これらを通じて、結果として「人間の頭脳をより高付加価値な判断や設計に振り向ける」働き方への転換を目指していました。
導入の成果
改善したかった課題はどれくらい解決されたか
SmartFは、一部Windows依存のライブラリを使用している部分があり、ビルドにはWindows環境が必要です。下記のアーキテクチャ図の通り、別途ビルドサーバーを構築しました。GitHub Actionsを介して、DevinのPushと同時にそのサーバーへビルドと単体テストをジョブ投入する仕組みです。
この構成により、バックログタスクやシステムヘルプ起因の調査・修正、小規模な機能追加の多くはDevinで自動対応できるようになりました。
一方で、軽微な修正であってもACU(Action Units)を大幅に消費してしまうというコスト面のネックも浮き彫りになりました。そのため、現在はコードの直接修正にはあまり使用していません。代わりに、後述する「Ask Devin」やコードレビュー、設計レビューなど、対話や検証メインの運用にシフトしています。
どのような成果が得られたか
SmartFは巨大なモノレポ構造を採用していますが、「Ask Devin」がリポジトリ全体を俯瞰した解像度の高い回答を返してくれるため、新しくジョインしたメンバーのオンボーディング時間を大幅に短縮できました。
また、コードベースを深く理解した上での「Devin Review」や、「Devin Sessions」を活用した設計レビューは非常に効率的です。人間が見落としがちな観点も含めて質の高いフィードバックが得られるため、プロダクトの品質向上に大きく寄与しています。
導入に向けた社内への説明
上長・チームへの説明
当時(2025年5月時点)、Devinは「自律的にプルリクエスト(PR)を作成できる初のAIソフトウェアエンジニア」として技術系メディアを席巻し、世界中から大きな注目を集めていました。
当社においては、このポテンシャルに着目した経営層の迅速な判断により、先行投資としての導入が即座に決定。そのため、現場が綿密な費用対効果説明書を作り込んで稟議を通す、といった一般的なプロセスは経ていません。
しかし、これは決して「説明が不要だったから楽ができた」という意味ではありません。むしろ「まずは導入する。使いながら自分たちで最適な活用方法を見出せ」という、現場への期待値込みのトップダウンでした。そのぶん、導入後の具体的な検証や運用の仕組み化は、すべて現場主導のボトムアップで泥臭く積み上げていくことになります。
活用方法
- バックログタスクの依頼:バグ修正・小規模機能追加
- システムヘルプ起因の調査・修正:CSや業務側から上がってくる挙動の原因調査
- PRレビュー:Devin Review による事前レビュー
- 設計レビュー:Devin Sessionsを使用しての設計レビュー
- Ask Devin によるコードベース質問:新人オンボーディング、PdM・Bizからの仕様調査依頼にも活用
よく使う機能
- Devin Sessions
- Ask Devin
- Deep Wiki
- Devin Review
ツールの良い点
「裏で勝手に終わっている」という自律性。 他の作業に集中している間に、タスクを自律的に走り切ってくれる。
膨大なコードベースに対しても、Ask Devinの調査品質があれば、新人エンジニアやPdMが自分で直接質問して解決できます。
運用しながら育てる「Knowledge / Playbook」 「最初から完璧でなくて良い」という思想がベースにあるため、現場で使いながらPlaybookを継続的にアップデートし、仕組みをどんどん成熟させていくことができます。
ツールの課題点
これまで無料でガシガシ使えていた「Ask Devin」と「Devin Review」が、2026年4月より有料化されたことに伴い、少し運用を見直す必要が出てきました。
これまでは「気軽にコードベースを質問する」「とりあえずPRをレビューしてもらう」といったカジュアルな使い方ができましたが、今後はそのハードルが少し上がることになります。
この新しい料金体制でもDevinの価値を最大化できるよう、Ask DevinとDevin Reviewの利用ガイドラインを現在再整備中です。
今後の展望
現在、私たちはBlazorへの移行を進めています。 この移行が完了すれば、Devin SessionsのLinux環境でそのままCIを回せるようになります。
これまで課題だった環境の非対称性が解消されるため、今後はDevinをより効率的に、かつガシガシとフル活用していける環境が整う予定です。
株式会社ネクスタ / hino-ok
チームリーダー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社ネクスタ / hino-ok
チームリーダー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法

.jpeg)
