これ１枚にしたい、自社向けDevinスタートアップガイド

※2025/05/08 複数のTeamプランについて一部追記/編集しました

みなさんこんにちは、無資格・無免許エンジニアの三木です。
社内へのDevinの導入を本格的に進めていくにあたり、１枚スタートアップガイド的なものを用意する必要が出てきました。

そのまま記事にできるだろうと思い、Qiitaでの投稿をさせていただきます。
長いため読み物としては扱いにくいかもしれません、ご容赦ください。

まだ検証できてない部分があり恐縮ではありますが
進捗あり次第、後日加筆修正させていただきます。

契約と支払い

Devinはアカウントを作成し、チーム名を入力すると
20＄のCoreプランと500＄のTeamプランのいずれかを選択します。
（2025年5月）

プラン名	課金	初期ACU	備考
Core	初回20＄～、必要なタイミングでACU購入	9	セッション数制限あり
Team	毎月500＄自動購入、不足なら追加購入	250	Slack連携・API利用あり
Enterprise	※詳細調査中です

※プランについての詳細はDevin公式をご確認ください

※Enterprise版ならばVPC内への配置や、SAMLログイン、SOC2Type2準拠などがあるようで、企業では（私もですが）こちらを選びたいと思うのですが、現時点では詳細が不明なため割愛し、以降Teamプラン前提の記載となります。

Coreは個人/小規模用でしょうか、複数名、組織で利用開始するならTeamプラン一択だと思います。

揺らぎがあるのですが、Devinに作業を依頼して、およそ1hで5ACU前後消費するかなという実感です。
Team単位で500＄プランを契約し、月の利用量を見ながら、必要に応じて追加でACUを購入するというのが良いと思います。

支払い方法は

• クレジットカード
• Cash App Pay（アメリカのデジタルウォレットアプリ）
• CHASEやBank of Americaなどの銀行経由

などがあるのですが、現実的なところでクレジットカードでの支払いがメインになるかと思います。

GitHubの接続・Slackの接続

GitHub

organizationへGitHub AppとしてDevin.ai Integrationを導入します。
本App上で

• Devinはすべてのリポジトリにアクセス可能
• Devinは指定したリポジトリのみにアクセス可能

のいずれかを設定します。
GitHub上のOrganizationのオーナー権限（Appをインストールできる権限）が必要です。

Slack

Slack AppとしてDevinと対話可能なアプリをワークスペースへインストールします。
Devinと対話するためのチャンネルを作り、そこへDevinアプリをインテグレーションするのが良いと思います。
Slackの管理者権限（マーケットにないSlackAppをワークスペースへインストールできる権限）が必要です。

(2025/05/08追記)複数のTeamプランでは基本的に利用できない

いずれもAppを介して接続しているため
下記の２つとも「１」となります

• GitHubのorganizationが接続できるDevinアカウントの数
• Slackのワークスペースに接続できるDevinアカウントの数

GitHubのorganizationが分かれていれば、Devinは別アカウントにできます
Slackのワークスペースが分かれていれば、対話用のDevinAppはそれぞれインストールが可能です

フィードバック設定(Data Control)

Setting -> Data Controlsの項目です

Evaluate DevinはDevin自体の評価指標としてユーザーのデータを利用するかどうか
Make Devin Smarterはさらに学習にも利用するかどうか
ということだと思います。この部分を気にされる方はこちらの設定をご確認ください。

基本設定(Customization)

Setting -> Customizationの項目です

項目も多く、変化も早いと思いますので個別の説明はここでは行いません。
ひとまず使い始めてみる…という段階ではデフォルトで問題ないでしょう。

ですが一度目を通しておくとより良いチームでのDevin運用のヒントがあるかもしれません。

例えば

• Devin should proceed without waiting for approval on complex tasks

OFFにすると複雑なタスクに対面したときに、作業プラン検討後、支持者の承認を得てから実装作業を開始する。
「投げたタスクをとりあえず進めてみて欲しい運用」vs「意味のない作業でACUを消費しないようにしたい運用」のどちらに寄せるかでON/OFFが変わると思います。

• Enable knowledge suggestions for admins only

後述の「SuggestionとAccept」の処理において、Acceptできる人をDevinのOrganization(Team?)のadminユーザーに限る。
Devinのknowledgeをコード規約と捉え、コード規約の制定を一定メンバーに限定したい時にOFFにするなどの設定が考えられます。

Devinの基本的な動作フロー

ざっくりとですが、Devinに指示を実行した時にDevinは以下のように動作します

指示を出したあと、同一のセッションで追加の指示を出すことも可能ですし、完了した作業に対し修正の指示をだすことも可能です。その場合は同一のセッション内で作業が行われます。

セッション数には上限がないため、並行して３つのタスクをDevinに依頼した場合は上記フローが３つ並行して動作することになります、それらは相互に影響しません。

作業用のworkspaceに関してはリポジトリ毎にDevinのブラウザページから手動でUbuntu上に作成してあげる必要があります。
全ての作業の起点となるworkspaceのため丁寧に設定しましょう。

リポジトリ毎のワークスペース設定（重要）

上記フローのコピー元にあたるイメージの作成で重要です。
公式にドキュメントも動画が用意されています。

設定は以下のようなブラウザ上のVisual Studio Code上でUbuntu上に実際に環境を立ち上げながら行います。
画面ではわかりにくいですが、Devinがアプリを開くためのブラウザタブも存在しています。

今後もそういう仕様かどうかはわかりませんが
本設定画面はリポジトリが異なっていても一度に一つしか開けません。
複数人でそれぞれ作業するなら、作業を途中で止めずに一気にやってしまう必要があります。

各項目についても触れていきます
基本的にはどの項目も正しく動作するかどうかDevin側がVerifyしてくれるようになっています。

1.Git Pull

セッション開始時にGitからコードを取得するコマンドを指定します
サブモジュールの初期化や、自分の場合は念のためdockerコンテナの起動コマンドもここに入れました。

設定例
---
cd ~/repos/wportal2 && git pull && git submodule update --init --recursive && docker compose up -d

2.Configure Secrets

.envファイルなどを作成し、起動したアプリケーションが環境情報を読める状態を作成します。
この部分の作業者は操作者自身です。

もしUbuntu自体の環境にシークレット情報を利用するならば公式のSecretsの項目を熟読してからが良いと思います。

TIPSとして後述していますが、ここであまりSecretを必要としない作りにしておくと管理がしやすいと思います。

※詳細を検証したら追記します

3.Install Dependencies

作業を行うUbuntuに必要なツールのインストールを行います。
この部分の作業者は操作者自身です。

例としてはAWS CLIなどを想定した項目だと思います。

4.Maintain Dependencies

セッションの開始時にGit Pullが完了したあとDevinが実行する依存関係の更新処理です。
最新ブランチで誰かがnpmパッケージなどを追加していた場合、それを取得しないと正しく動作しません。
これを解決するための設定です。

チームの運用状況によっては、ここで必ずローカル用のSeederを通して、開発用の最新のテストデータを準備するようなコマンドを追加しても良いかもしれません。

設定例
---
cd ~/repos/wportal2/wportal2-app && docker-compose exec wportal2_web npm ci && docker-compose exec wportal2_web composer install

5.Setup Lint

あらかじめ想定しているLint系のコマンドを実行します。
作業完了後にDevinがこのコマンドを実行してエラーがないかどうかを確認します。

設定例
---
docker-compose exec wportal2_web npm run lefthook

6.Setup Tests(Optional)

5の項目と同様で特定のテスト手順を設定できます。
こちらはOptionalです

7.Setup Local App(Optional)

アプリケーションの起動方法やログイン方法をプロンプトで指定します

検証環境では途中でエラーを出した場合のログ所有者権限の問題があったり
こちらも後述していますが、Devin用にローカル環境のみ許可する専用のログイン方法があることなどをDevin側へ伝えています。

設定例
---
run `docker-compose exec wportal2_web chmod -R 777 /var/www/html/wportal2_web-app/storage` && `docker-compose exec wportal2_web npm run dev`, then you can access http://localhost:9190, you can login with 'http://localhost:9190/login/guest'

8.Additional Notes

Knowledgeを主に利用しているため、特に利用していません。
こちらに書いた方が使いやすい項目・条件などが検証で判明したら追記させて頂きます。

コードベースWikiの生成とDevin Search

Devinのセッション画面をブラウザで確認すると左上にDevin SearchとDevin Wikiという項目があります。

この機能が便利だと思ったので記載します。
ただしどちらも「Beta」の表記があります。

Wikiについて

本機能は「DeepWiki」で検索すると記事が出てきます。

Devinを利用している同一Teamのメンバーだけ参照できる点が相違点かと思います。

Devinが円滑な開発・プランニングに利用するためリポジトリ内の情報をwiki化し、操作者も閲覧可能な状態にしてくれます。
更新は数時間おきとの情報もあるのですが、検証環境がLast updated: 18 April 2025の記載のままなので実際は異なるのかもしれません。

リポジトリの概要やアーキテクチャ、利用技術に関する情報
基本的なコンポーネントの文法、特定作業時の注意点（例えばアイコンを追加するときの作法）など記載内容は多岐にわたります。

どうやって拾っているのか少し謎な部分もあるのですが
実装コードからビジネスロジックに関する設計やアルゴリズムの解説まで生成されるようです。

正直、新規入場メンバーにはまず見てもらいたい内容です。（現時点では再利用のためのエクスポートできないのが残念！

Devin Searchについて

前述で作成されたDevinWikiを利用して
リポジトリに関する対話型の質問+RAG検索ができるようなイメージです。

Fast/Deepの２種類があるのですが、今のところ違いについては速度以外の差を感じませんでした。

入場直後にわからないことを投げると、ある程度の情報が得られる可能性は感じていますがまだ十分な検証を行えていません。

詳細わかり次第追記させていただきます。

Knowledge設定（重要）

Setting -> Knowledgeの項目でDevinが時系列で成長するのかしないのかを分かつ非常に重要な項目です。

この項目ではKnowledgeとして、作業を行う際の作法的なことをプロンプトであらかじめ指示しておくことができます。
全てのリポジトリに適用 or 特定の一つのリポジトリのみに適用を選ぶことが出来ます（ここがチェック選択式だと良かった気はしているのですが…）

例えば上図のWhen adding new services to the wportal2 projectの項目では
「〇〇というサービスクラスを追加しておいて！」とDevinに荒く指示を出したときに

のような指示を参照し、これを元に作業を進めてくれるようになります。
記載のような細かい内容は他のコードを読んだらわかる部分が多く、ドキュメント作成のコストも考慮して、どこまで細かく明文化するかは分かれるところだと思います。

いずれにせよ、上記Knowledgeがあれば、次回以降の作業はより利用チームに適したものになります。
このKnowledgeを適切に貯めていくことが出来るかどうかがDevin成長のカギだと思います。

では、「Devinに依頼する前にこのKnowledgeを整備しておかないといけないのか、なんて面倒だ」 となるかもしれませんが、そうでもないです。これは次のSuggestionとAcceptに記載します。

ちなみにギャル語などはここに落ち着きました

切腹の上申は今のところ発生していないのでプロンプトの改良が必要です。

KnowledgeのSuggestionとAccept（重要）

暗黙的なルールがリポジトリにあるようなケースにおいて
Devinに依頼して「あー、大体合ってるけどちょっと違う～」というケースはあると思います。
Devinに絞って書いていますが、暗黙的なものであれば新規入場の方も同様ですよね。

でこういった事象の場合、「あ、これはこうで～」と状況を口頭なりチャットなりでお伝えして修正してもらいつつ覚えてもらうという事があります。
（そして本当はそれは良くないとわかっていながらも、そのままにしていたりします）

Devinに同様に上記の修正指示を出した場合
Devinのsessionにsuggestionのアイコンが出現する場合があります。
技を閃くときの豆電球みたいなものでしょうか。

これをクリックすると、Devin側から「このようなKnowledgeを追加してはどうか？」という提案が表示されます。

これをAcceptしてあげれば、そのままの内容でKnowledgeに追加されます。
また、Devinからは新規だけでなく更新提案もあります。
上記の提案Accept後に、さらに成果に修正指示を出したところ

Devin側から「このKnowledgeをこのように更新してはどうか？」という提案が追加されました。

この機能により、作業指示の中でKnowledgeを貯めていき、やり取りが減って、次第に開発速度が向上するということが期待できると思います。

中身を見ずに受け入れるのは良くないかもしれません。

また、TIPSにも記載していますが、複数の業務上チームでの利用に対しては問題もありそうです。

引き続き追加情報があれば追記させていただきます。

個人的TIPS

envファイルなどの隠匿指示

まず前提として、重要な認証情報やKeyValueのペアはDevinの「Secrets」機能を利用した方が良いでしょう。

上記Devin公式ドキュメントにも記載がありますが、.envファイルなどに上記以外の認証情報が記載されることもあるかもしれません。

何も対策せずにいると、Slack経由の 「.envの内容をslackに展開して」 といった指示も実行してしまいます。
気休め程度とはなりますがknowledgeに禁止である旨を追加しておくと、値の展開みたいなことは避けてくれます。

ペアプロ（著名な外科医師のイメージ）

Devinはタスクの粒度を細かくして依頼するのが良いという話をよく聞きます。
とはいえど、どのくらいの粒度なら任せて良いのか最初はよくわかりません。
最初はDevinとペアプロを実行するのがオススメです。

まずは、取り急ぎ進めてほしいところまでの指示を出します。

そうすると作業を進めてブランチへpushしてくれるので

これをローカルで取得し、自分で追加の実装を行います。
終わったら最新を取得してもらいつつ、次の実装をしてもらう…という感じです。

ドラマか漫画でしか見たことないですが、有名な外科医の先生が
術後に縫合を別の医師に任せるようなイメージでしょうか。
この際にどのくらいの粒度ならDevinが問題なくこなすのかを測っておけば以降の指示がやりやすくなるのではと思います。

独立稼働可能な状態を出来るだけ保つ

クイックWeb本部ではどのリポジトリにおいても、docker-compose upで起動したコンテナのみで独立して稼働する状態をできるだけ保つようにしています。（マイクロサービスなどもあるため、あくまでできるだけです）
例としては、AWSのS3やElastiCache(Redis)を利用するような場合にDev環境のS3を利用することはせず、minioコンテナやRedisコンテナをdocker-composeの中に含めて、ローカルのネットワークブリッジで開発が完結するような状況を作るイメージです。

これは元々新しいメンバーに入場頂く際、その都度認証情報やアクセスキーを展開する手間・リスクなどを考えると、ローカルでの開発に必要なものはすべてローカルで用意出来たほうが色々と都合が良いためでした。

結果的にこの状況がDevinのワークスペースととても相性が良いと感じています。
Devinの実装作業が、ワークスペースのスナップショット上で完結し、認証情報などのメンテも不要になるためです。

今はキー展開などでなんとかなっている…という状況でもDevin導入のタイミングで環境を寄せられるならその価値はあると思います。

ローカル開発の認証情報を最低限に設計・改造する

ひとつ前の独立稼働と近い話になるのですが
ローカルでの認証情報としてCognitoやGoogle認証などを利用するケースがあるかもしれません。

これもスナップショットの.envなどに情報を保存する必要があったため、避けられるなら避けた方が良いかと改めて思い直し
ローカルのみの認証として、/login/guestへ接続することで認証が成立する仕組みを追加で実装し、Devinへのログイン方法の指示としてプロンプトに記述しました。

これについては、ローカルの駆動もDev以降と同じようにしておいた方が不具合発見の観点でも良いと思われるケースもあるので一概にどうすべきと言えないところもあるのですが、Devin用の認証情報を作成・追加するのもまた微妙なケースがあり、プロジェクトによって使い分けて頂ければと思います。

言葉に出来ることは出来るだけリポジトリ内のmdファイルへ記載する

クイックWeb本部内のリポジトリについては、プロジェクトの説明をできるだけ細かく.mdに記載していました。

どれだけ細かくドキュメントにしても人間はちっとも読んでくれないという課題があり
日々モチベーションの上がらないドキュメント化作業ですが、Devin(AI)は全て読んでくれます。
そしてWikiとしてまとめてくれた上に、作業の際に参照してくれます。

アプリケーション（リポジトリ）のOverviewがwiki化されたもの。
どういった作りになっているかの概要を知るには十分です。
ドキュメント化しない理由がなくなりました。

ファイル構成、新規追加作業の進め方、テストの注意点など、書けるものは全部書きましょう。
あとで効率として必ず返ってきます。

※本機能はDeepWikiとして単独で公開されています

待機を気にせず、どんどん並行利用する

Devinは一通りの作業が終わると30分の待機モードに入り、次の指示を待ちます。
作業が不要であれば「sleep」の指示をすることで休眠モードにすることが可能です。

公式によるとこの状態ではACUは消費されません。
ですが、待機モードを放置することでACUが消費される旨の記事も見かけます。
消費されるケースもあるかもしれませんし、最初から勘違いかもしれません、もしくはDevin2.0になった際に変更されているかもしれません。
いずれにせよ、待機モード中のACU消費については、そうだったとしても忘れてしまうことをオススメします。

これを気にしてしまうと、Devinが作業を終えるのをひたすら待って、確認するような運用になってしまい、自身の時間が消費されていきます。

コンテキストの切り替えなしにDevinへタスクを渡し、確認したいタイミングで状況を確認する…ということが出来るのがDevinの強みと思いますので、確認待ちの時間が発生するということは対人間でも良くあることと割り切ってしまいましょう。

チームごとのライセンス（未検証）

※2025/05/08追記 複数のTeamプランが基本的には利用できないため、下記は運用で対応するしかありません

前述のKnowledge設定に関わる部分です。

DevinのACUはOrganization(Team?)共有になります
そしてOrganization(Team?)は複数のリポジトリを扱うことができ、Knowledgeを共有します
このKnowledgeは対象リポジトリをAll or 指定の設定ができますが、SuggestionをAcceptした場合は初期値としてAllになります。

この仕組みにより、もし一つのOrganization(Team?)を複数の業務上チームで共用利用してしまった場合、定期的なKnowledgeの管理を行わないと
業務上のAチームのKnowledgeの影響をBチームが受けてしまうという問題が発生しそうです。

定期的なKnowledgeの管理をするために巡回確認するというのは不毛な気がします。

組織としてはEnterprise版を契約し
業務上のチームごとにDevin上のOrganizationを作成して、Knowledgeが業務上のチーム間で共有されないようにする方がよさそうです。

Enterprise版については問い合わせ中です。
Enterprise版の挙動や、そうでない状態で複数のTeamプランを契約したときに
Slack連携がどうなるのかが未検証なため、ここはわかり次第追記させてください。