はじめに
クロスマート株式会社でフロントエンドのタスクを主に担当しております。ナイスガイの福留です。
本日は、AI開発エージェントDevinの実運用における深掘り記事となります。
AIエージェントDevinの概要については以下をご覧ください。
また、以下の個人記事では各機能や、基本的な付き合い方について説明しています。
「導入してすぐ」の組織向けに以下記事を、
「導入後、数週間経過し、組織の幾人かが活用出来ている」フェーズの組織向けに本記事を執筆しています。
本記事では書かないこと（前提とする知識）
- Devinの概要
- Devinの基本機能
- Devinの契約プラン
- Devinへの仕事の頼み方
- Devinの得意なこと・苦手なこと
これらの項目については、上述した個人記事を読んでいただければわかりやすいかと思います。
本記事で書くこと
- Devinを開発組織に最適化する方法
- Devinによって開発組織以外にインパクトを与える方法
対象読者
- Devinが導入され、半分程度のメンバーがDevinを日常的にメンションするようになった組織のメンバー・管理者
Devinがメンションされ出した組織に向けて
特に今回深掘りしたいDevinの機能は以下となります。
- Devin Knowledge
- Playbooks
- Devin Wiki
- Devin Search
およそ、Devinを導入してすぐの状態の組織では、Knowledgeを編集・適宜更新しつつ、オンボーディングが進んでいくかと思います。
ジュニアレベルの小さな開発タスクをDevinに頼むために見つけ出し、チケットの中身をコピーし、開発者がSlackやweb上でDevinとコミュニケーションを取りながら、実装のみを進めるさせるようなユースケースを想定します。
これだとRooCodeやCline、CursorがSlackやGitHub上で動いているだけで、実際の使い勝手がそれらよりも劣ってしまうのではないかと思います。
きっと、「Devinに頼むよりCursorに作業させた方が楽で正確だよね」と感じているメンバーが多い組織は実は少なくないのではないかと思っています。
CursorやRooCode、Clineはエンジニアの「スケールアップ（作業の効率化）」であり、Devinを同じように使おうとすればそれらよりも効果は薄れます。
Devinはエンジニアの「スケールアウト（並列化）」です。
Devinが正しく「エンジニアのスケールアウト」であるために、以下の2点が特に重要なポイントではないかと考えます。
- Devinがあなたと同じだけの開発知識を持っていること
- Devinが高精度なソースコードの知識を使い、あなたをサポート可能なこと
Devinがあなたと同じだけの開発知識を得るために
Devinには、KnowledgeとPlaybooksという領域にプロンプトセットや手順等を記憶させる事が可能です。
本章ではそれらについて詳しく説明しますが、先にAIエージェントの記憶領域との向き合い方について私の考えを書かせてください。
Devinに与えるべき知識と、開発ドキュメントに残すべき知識を適切に区別することが重要です。
結論を先に出してしまうと、Devinに保存するべき知識は「ドキュメントはあるが、Devinに開発ドキュメントとしてそれを提供出来ない場合」のみです。
具体的には、社内管理画面のURLや、社内ツールの使い方などです。
アンチパターンとして、「DevinのKnowledgeに開発ルールや開発手順、コーディング規約をすべて登録してしまう」があると私は考えています。
それがアンチパターンとなり得る理由ですが、「開発に関わる誰もが知っておくべき知識」が人間の暗黙知とDevinの記憶領域に閉じてしまうからです。
Devinが開発を行う上で、必要なKnowledgeの内容は少なければ少ないだけ良いです。
開発に必要なドキュメントはREADMEや、AIエージェントを含む全メンバーが容易に閲覧出来る領域に保存するべきです。
DevinのKnowledgeに登録したくなる事があれば、その内容をDevinに属人化させて良いのかを一度考えてください。
Devin Knowlege
Devinがあらゆるセッションで参照できる指示やアドバイスの集合体です。 コードコンフォーマンスの実践、デプロイワークフロー、PRの命名規則、テストワークフロー、独自ツールとの連携方法などを事前に登録しておくことで、Devinはその内容を自動的に参照し、業務を効率的に遂行します。
System Knowledge（Built-in knowledge, Repo Indexes）と、その他のKnowledge（ユーザーが新規登録、編集出来るもの。また、作業の中で新規に学習したことを、ユーザーが希望すればKnowledgeに自動登録するもの）に分かれます。
情報が特定のコンテキストにのみ関連する場合は、特定のリポジトリにピン留めすることもできます。
弊社での使い方ですが、Knowledgeには以下の内容を保存しています。
- 各周辺ツールへのログイン方法
- ブランチ名、PR名のルール
- 依頼者の名前をブランチ名、PR名に含めるよう指示しています。
- 弊社ではそれらの命名グランドルールをnotionに保存しており、notionへのアクセスを毎回実行させるのも無駄なため、Knowledgeに登録しています。
- 動的な操作であるため、本来Playbooksでの運用が推奨されるものではありますが、Devinに基本的にPR作成までを任せており、「何も考えずに丸っと任せたい」ためKnowledgeで運用しています。
- master/mainブランチには絶対にマージしないという内容も含みます。
- 日時の扱いについて
- Node バージョン管理について
- fnmを使用するよう指示しています。同様にグランドルールに登録している内容です
- コミットフックについて
- husky等を使用しているプロジェクトでは、コミット前にプリコミットフックないし、指定されているコマンドを実行すること。
- エラーが出た場合はエラーを解消するまでコミットしないこと。といった内容です。
Playbooks
再利用可能な “プロンプトテンプレート” ライブラリを登録可能です。
よくあるタスク（テスト足りない箇所の網羅、翻訳ファイル同期など）を Markdown 形式で記述し、チーム／コミュニティライブラリに保存するとワンクリックで添付可能となります。 Slack や IDE 拡張から !macro で呼び出すこともできる。実行ログをタイムラインで巻き戻して改良→再保存するワークフローもサポートします。
どのようなものをPlaybooksに登録すべきか、Knowledgeとの違いは何かを記述します。
前提として、Knowledgeに手順を登録している場合、それが正確に実行される保証がありません。
禁止事項として登録しているものは制約として守られますが、Knowledgeから使用する知識はあくまでAIが指示を受けた際に「関連あると判断したもの」であるため、実際にタスクを実行するときに「本来使用して欲しかった知識」がスルーされることもあります。
例えば、実行してもらった作業を検証環境に反映して欲しい場合などに、
「その変更を検証環境に反映して欲しい」と依頼するとどうなるでしょうか。
Knowledgeには以下のような記述があるとします。
変更の検証環境への反映方法： 1. stagingブランチをcheckoutし、最新状態にする 2. 作業ブランチをmergeしpushする この作業を行うとき、PRのマージ対象は変更しないこと。
ほとんどの場合、正しく動作すると思われます。
ただ、これが「stagingにマージして欲しい」とか、「stgにpushしておいて」といった依頼方法になると、別の知識が使用される事があります。
Knowledgeには、登録・編集が可能なそれと、作業を実行していく中で学習して保存する、編集が不可能な「System knowledge」があります。
他のリポジトリでの作業中、「stg push」という言葉を別文脈で記憶していた場合はそちらが優先されてしまい、狙い通りの結果を得られないリスクがあります。
また、すべてをKnowledgeに登録して行ったとき、そのとき作業している内容とは関係無いKnowledgeが大きくなり、コンテキストを圧迫してしまうリスクもあります。
Playbooksをどう実用するか、に立ち戻りますが、「より深く狭いコンテキストでの確実に行ってほしい作業手順をコマンド化する」目的での使用を心掛けると良いかと思います。
例えば、弊社で登録済みのものとしては以下があります。
Macro: !view_jira ## Playbook: Jira へのアクセス ### 目的 タスク管理・進捗確認を行う ### 前提 Google アカウント (MAIL_ADDRESS / MAIL_ADDRESS_PASSWORD) ### 手順 1. https://〇〇△△/ にアクセス 2. Log in → Continue with Google を選択 3. MAIL_ADDRESS を入力 → Next 4. パスワードに MAIL_ADDRESS_PASSWORD を入力 → Next 5. Jira ダッシュボードが表示されればログイン成功 6. 画面のスクリーンショットを提供する ### 禁止事項 - メール＋パスワード方式でのログインは行わない - git や cd コマンド実行、ローカルアプリの立ち上げは禁止 - 上記以外の操作を一切行わないこと
キモとしては禁止事項の部分です。
これをKnowledgeに登録しようとすると、「こういうときは〇〇して良いが、こういう作業の時は〇〇は禁止」みたいな書き方になります。
コンテキストが深くなるので禁止事項が漏れたり、
OKのパターンなのに禁止事項として扱って作業が滞ったりする可能性があります。
Playbooksを適切に運用することで、禁止事項をしっかり禁止しやすくなります。
今回は関係の無いコマンドを一切使用禁止することで、セッションの実行時間の削減にも繋げています。
Playbooksの使用を最適化することで、トークンの節約にも繋がる可能性が高いです。
Devinがあなたをどのようにサポートするか
Devinをどう開発タスクを任せる以外の点で役に立てるか、という議題になります。
具体的には、Devinが「スケールアウト」である以上、開発エンジニアが開発エンジニアとして普段行っている業務のうち、開発タスク以外もなるべく多くを肩代わり出来る存在である必要があります。
具体的には仕様の調査や、チケットの読み込み、動作の確認を指します。
以下の機能群によって、開発エンジニアの業務のうち、難解ではない（熟達のエンジニアがわざわざやることではない）それらをDevinによってスケールアウトします。
Devin Machine
DevinはRooCodeのようにサクッとタスクを処理することは不可能です。
RooやClineはあなたのPC上で動きますが、Devinには自身の作業環境があります。
Devin Machineは、Devinの作業環境を指します。
リポジトリを教えてあげた後は、そのリポジトリの作業環境セットアップ手順を登録してあげることで、以降Devinは自身の環境でアプリケーションを立ち上げ、自走した開発が可能になります。
Devin Wiki
deepWikiを元にした、ポジトリのアーキテクチャ図、ソースへのリンクの存在する、超精密高濃度なドキュメントの自動生成機能です。
本当は弊社のDevin Wikiの画像を添付したかったのですが、実際のソースコードを元にめちゃくちゃ高精度な実装仕様が網羅的に全て書かれちゃっており、あまりにもセンシティブなので断念しました。
以下は代わりに探してきたvscodeのDeepWikiの内容ですが、アーキテクチャから各機能の実装の詳細な説明、さらには実装箇所へのリンクまでが添付されているのがわかります。
Devin Search
RAG 搭載 AI を使用して、DevinWikiと対話し、実装に対する質問が可能です。
超高精度超高密度なwikiをベースにしていることもあり、回答精度も段違いです。
さらには、Devin Searchは完全無料で使用可能です。
PRを作成する必要が無いケースや、実際の作業が全く無い調査タスクを超絶効率化します。
具体的な質問の内容と回答を例示します。
質問：クロスオーダー管理画面のパスワードリセットの方法を教えて
回答：
クロスオーダー管理画面のパスワードリセット方法について、コードベースから以下の情報が見つかりました。
## クロスオーダーのパスワードリセット機能概要
クロスオーダーシステムには複数のユーザータイプ（卸業者ユーザー、店舗ユーザー）が存在し、それぞれに対応したパスワードリセット機能が実装されています。
### 卸業者（サプライヤー）ユーザーのパスワードリセット
卸業者ユーザーのパスワードリセットは以下の流れで行われます：
パスワードリセットメール送信画面でメールアドレスを入力
登録されたメールアドレスにリセット用URLが送信される
メールのリンクからパスワードリセット画面にアクセス
新しいパスワードを設定
実装は主に xxx リポジトリにあります。
sequenceDiagram
actor User as 卸業者ユーザー
participant ResetPage as パスワードリセット画面
participant API as バックエンドAPI
participant Email as メールサービス
User->>ResetPage: メールアドレス入力
ResetPage->>API: パスワードリセットリクエスト
API->>Email: リセットURL送信
Email->>User: パスワードリセットメール
User->>ResetPage: リセットURLアクセス
ResetPage->>API: トークン検証
API->>ResetPage: 検証結果
User->>ResetPage: 新パスワード入力
ResetPage->>API: パスワード更新
API->>ResetPage: 更新完了
### 店舗ユーザーのパスワードリセット
店舗ユーザーのパスワードリセットも同様の流れですが、実装は xxx リポジトリにあります。
パスワードリセットの具体的な方法
1. 卸業者（サプライヤー）管理者によるリセット
卸業者の管理者は、自社のユーザーのパスワードをリセットできます。
ユーザー詳細画面で「パスワードをリセット」ボタンをクリック
SupplierUserForm.vue:8-15
確認ダイアログで「送信する」をクリック
SupplierUserForm.vue:48-59
2. 卸業者（サプライヤー）ユーザー自身によるリセット
ログイン画面の「パスワードをお忘れの方はこちら」リンクをクリック
メールアドレス入力画面でアドレスを入力して送信
PasswordResetMail.vue:34-41
受信したメールのリンクをクリック
パスワードリセット画面で新しいパスワードを入力
PasswordReset.vue:31-55
「確定する」ボタンをクリック
PasswordReset.vue:56-63
3. 店舗ユーザーのパスワードリセット
ログイン画面から「パスワード再設定」リンクをクリック
メールアドレス入力画面でアドレスを入力して送信
UserPasswordResetEmailPage.tsx:30-40
受信したメールのリンクをクリック
新しいパスワードを設定
user-password-reset-new-password.tsx:48-52
4. 管理者による店舗ユーザーのパスワードリセット
店舗の取引先情報画面から店舗ユーザーのパスワードをリセットできます。
店舗詳細画面で「パスワードをリセット」ボタンをクリック
ShopDetail.vue:67-76
確認後、パスワードリセットが実行される
## バックエンド実装
パスワードリセットのバックエンド処理は主に以下のファイルで実装されています：
メール送信処理
email.py:742-752
パスワードリセットAPI（卸業者ユーザー向け）
supplier_order.py:3270-3314
パスワードリセットAPI（店舗ユーザー向け）
shop_order.py:771-807
認証APIでのパスワードリセット処理
issue_reset_password_url_service.py:14-32
管理者（オペレーター）によるパスワードリセット
管理者（オペレーター）は、卸業者ユーザーと店舗ユーザーの両方のパスワードをリセットできます。
卸業者ユーザーのパスワードリセット（xorder-invoice-admin）
password-reset.vue:36-50
店舗ユーザーのパスワードリセット（xmart-web-api）
shop_order.py:1800-1845
Notes
クロスオーダーシステムは複数のリポジトリに分かれており、それぞれのユーザータイプ（卸業者、店舗、管理者）ごとに異なるパスワードリセット機能が実装されています。主要なリポジトリは xmart-web-api（バックエンド）、xxx（卸業者向けフロントエンド）、xxx（店舗向けフロントエンド）です。
※ 2025年5月現在、公式の機能ではウェブアプリからのみ使用可能で、APIやSlackからは使用できません。
Interactive Planning
セッションを開始すると、Devin がプロンプトを解釈し、コードベースを素早く検索して関連ファイルやコードスニペットを見つけます。
必要に応じて、Devin はこのコンテキストに基づいて、調整可能な詳細なプランを提案します。
コードベースの検索にもDevin Wikiを使っており、全ての回答に根拠を提示してくれます。
その計画で作業を進めた場合、依頼者の意に沿う結果になる信頼度がどの程度か、を併せて教えてくれるため、作業の実行前に依頼の精度を上げる事が出来ます。
Interactive Browser
Devinは自身のブラウザを持っています。
変更に際して、擬似的なE2Eを実行してもらう事が可能です。
....が、具体的な指示が必要（このボタンを押した後にこうして、画面遷移してからこのボタンを押してこうなることを確認して）なので、E2Eとしての運用は少し険しい道になるかと思われます。
この機能を使うことでMCPサーバーが使用されていないサービスをDevinにアクセスして使ってもらうことが可能であるため、AI連携が用意されていないサイトを自動で使ってもらうことなどが可能です。
Jira Integration
Jiraとの連携が可能になりました。
具体的には、JiraにDevinをアクセス出来るようにしておき、ラベルを設定することで、数分後にはDevinがそのチケットの概要を詳細化・同様にIntaractive Pranningした作業予定をコメントしてくれます。 そのまま人間が引き継ぐことも可能ですし、コメントに添付されるリンクを押して作業を開始させることも可能です。
開発組織で使いこなすために
Devinに与えている権限
各アプリケーション、開発ツールをDevinに使ってもらうために、弊社ではDevin用の会社メアドを発行しています。
同様に、Googleプロファイルにログイン出来るようにパスワードも教えてあげており、メールクライアントの操作も可能にしています。
Jira, Sentry, Figma, Googleアカウント, 検証環境の社内管理画面のログインID、パスワードも全てDevinのために用意したもので、タスク遂行中に必要となった場合は勝手にログインしてもらっています。
Devinへの仕事の頼み方
対象リポジトリ、作業内容を明示的に書くのが良いです。
私がDevinに作業を依頼するときは以下のテンプレートを使用しています。
対象リポジトリ：https://github.com/xxx チケット：https://xxx.atlassian.net/browse/xxx 作業内容： 〇〇画面において、「△△詳細を確認」モーダルを表示したとき、商品点数が多いとモーダルに収まっていない。収まるようにしてほしい。 モーダル中のテーブルコンポーネント中、headerは固定で、bodyのみをスクロール出来る形にしてほしい。 stagingへは反映せず、PR作成後は私に確認を依頼すること。
非エンジニアメンバーがDevinの恩恵を受けることができる未来のために
非エンジニアメンバーが現行の実装仕様を知りたいケースが実務上では多く存在するかと思います。
ここでは、特に非エンジニアのPdM、営業メンバー、CSメンバーにフォーカスします。
現在、以下のような事象が発生することはどの会社でも多いかと思っています。
- エンジニアへの緊急性の高い仕様質問
- 「この仕様どこで決めた？」「顧客はどの API 叩けばいい？」といった質問をイメージしています。
- 即座に回答出来ないような状況も存在するため、エンジニアの回答を待つ時間がBizサイドメンバーに発生してしまいます。緊急性の高いものでは回答を待つ時間そのものが課題かと思います。
- 仕様ドキュメントの散逸
- 仕様ドキュメントが継続的にメンテナンスされていなかったり、バラバラに作成されている場合です。
- Bizメンバーが仕様ドキュメントを探しづらい状況が形成されている組織は多いのでは無いでしょうか。
- ドメイン知識の属人化
それらの課題に対し、Devin Searchを全社的に使用可能になれば一つの大きな解決策になります。
が、上述した通り、
※ 2025年5月現在、公式の機能ではウェブアプリからのみ使用可能で、APIやSlackからは使用できません。
という状況です。
なので....
頼んでみたらSlackからDevin Searchを使えるようにしてくれた
以下、Devinのサポートチームとのチャットの内容です。
なんと、Slack経由でDevin Searchを使えるようにしてくれました！！！
非公式な機能でありつつ、特別に有効化してくれてるそうです！
（公開して良いのかは迷いましたが、聞いてみたらOKとのことで！）
Devinのいるチャンネルで、!ask {質問内容} するとDevinの使用メンバー以外にもDevinが回答してくれるようになりました。
使っている機能はDevin Searchなので、当然トークンの消費はありません。
Cognition様、本当に素敵な会社ですね！？
社内のAIツール開発メンバーと協力し、Bizメンバーから容易に質問出来る環境を構築中
弊社にはAI社内ツールに特化したチームが存在し、遊撃的に全社の業務効率化に貢献してくださっています。
そのAI研究室のメンバーに相談したところ、DifyとSlackワークフローを使い、Bizメンバーに質問しやすい・またわかりやすい回答をくれるSlack Botを構築してくれる事になりました。
私の思い描く、Devinが全社的に使われている理想の未来にグッと近づいた瞬間です。
ここ2,3日の間に相談させていただいたためまだ「上述した問題が解消されている」状況にはなっていませんが、
Devin SearchとAI研究室のメンバーのおかげで、【Bizメンバーが実装の仕様についての質問をAIに投げる → AIから迅速かつ、正確な回答を詳細に得られる】というフローの完成に近づきつつあります。
この場を借りてですが、本当にありがとうございます。
おわりに
最後の方は書いてる途中で改めて喜びが勝ってしまい変な構成になってしまいましたが、
以上が一旦現在・今後の弊社でのDevinの活用、運用になります。
最後まで読んでいただきありがとうございました。
新しいツールを積極導入している素敵な弊社です。
我らが開発チームに興味を持ってくださったら、以下採用ページもご覧いただきたいです！
