🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）
この記事にぜひ いいね❤️ していただけると励みになります 🙌
はじめに
AI駆動開発（AIDD）——開発プロセスの主語をAIにする、という流れが定着してきました。その次に語られ始めているのが「AI駆動企業」です。同じ原理を、開発だけでなく事業オペレーション全体と経営に広げる。営業・経理・企画・意思決定までAIエージェントが駆動し、人は判断・倫理・関係性に回る——そういう会社のかたちです。
絵としては分かる。では、それを実装するとしたら何を使うのか。この記事では、AI駆動企業の見取り図を、Devinの機能に1つずつ当てはめて、実装レベルまで降ろしてみます。部門はどの機能に、稟議はどの設定に、業務マニュアルはどの箱に——と、会社の要素をDevin公式ドキュメントの機能名まで翻訳していく作業です。
先に正直に断っておきます。これは実際に動かした記録ではなく、公式ドキュメントを読みながら構想を機能名に翻訳した設計マッピングです。 言えるのは「ドキュメント上は辻褄が合う」までで、「実際に組める」と言い切るにはこの先に実走が要ります。
先に3行でまとめると
- AI駆動企業とは 事業オペレーションの「主語」が人からAIエージェントに変わった企業。AIで効率化するのではなく、AIで動く前提に作り替える
- 会社の構成要素はDevinの機能名まできれいに降りる。業務マニュアルはPlaybooks、教育・引き継ぎはKnowledge、オーケストレーションはDynamic Workflowsに対応する
- 勝ち筋は 「プロンプトが上手い人材」ではなく「業務をエージェント単位に分解できる組織」。箱（道具）は揃っていて、足りないのは設計
この記事に出てくる用語の位置づけ
| 用語 | ざっくりの意味 |
|---|---|
| AIDD | AI-Driven Development。開発プロセスの主語をAIにする |
| AIDM | AI-Driven Management。同じ原理を事業と経営に広げる |
| オーケストレーター | 事業ルールを持ち、各エージェントに仕事を振る親役 |
| ドメインエキスパートAgent | 特定業務に特化した子エージェント |
| HITL | Human-in-the-Loop。実行前に人が承認する形 |
| Playbook | 繰り返すタスク用の「システムプロンプト」。定型手順を共有・再利用する |
| Knowledge | セッションをまたいで参照される、組織の文脈・ルール集 |
| ACU | Agent Compute Units。Devinの消費量の単位 |
🏢 AI駆動企業とは何か
定義はシンプルです。事業オペレーションの主語が「人」から「AIエージェント」に変わった企業。受注・採用・出荷・請求までの実行をAIエージェントが担い、人は判断・倫理・関係性に回る。会社のかたちが「人が回す会社」から「AIが方向を決める会社」へ変わる、という整理です。
ここで効いているのは**「主語」という言い方**です。AIを導入したかどうかではなく、業務を一文で書いたときに主語がどちらになるか——「担当者が請求書を作る」なのか「エージェントが請求書を作る」なのか。これなら自分の職場にそのまま当てはめて判定できます。
「速い馬車」ではなく「自動車」を発明する、というたとえがよく使われます。既存プロセスにAIを足すのか（Retrofit）、AIで動く前提で作り直すのか（Reimagine）。AIを「道具」としてではなく「動力源」として置くか、という区別です。
🗺️ 会社の要素は、エージェントと事業ルールに写像できる
この見方を突き詰めると、会社の構成要素は、エージェント・事業ルール・APIに写像できる、という発想に行き着きます。部門は専門特化したエージェントに、稟議は承認ゲートに、業務マニュアルは手順書に。組織図を「エージェント構成図」として描けるか、というわけです。
その写像先を、Devinの実機能で埋めるとこうなります。
| 会社の要素 | 対応する概念 | Devinでの実装 |
|---|---|---|
| 部門・役職 | ドメインエキスパート Agent | Dynamic Workflows の子Devin／CLIサブエージェント |
| 稟議・承認フロー | HITLゲート | 権限モード ＋ allow / ask / deny ルール（後述） |
| 業務マニュアル | 事業ルール・Skill | Playbooks ＋ Skills |
| 教育・引き継ぎ | 知識設計（メモリ／自動ナレッジ化） | Knowledge（repo等から自動生成・後述） |
| 監査・人事評価 | ログ監査・評価基準 | Enterprise API の監査ログ ＋ RBAC・SSO |
面白いのは、Devinの機能名が、もともと「会社の語彙」に寄せてあることです。「業務マニュアル」に対しては最初から Playbook（繰り返すタスクの手順書） という名前の箱があり、「教育・引き継ぎ」には Knowledge（新しい社員にオンボーディングするように組織の文脈を渡す） という箱がある。写像表の左右が、言葉のうえでほぼ揃います。
まず、2つの行をここで押さえておきます（稟議・教育はあとで1節ずつ掘り下げます）。
業務マニュアル → Playbooks。 Devinの Playbook は、公式で 「繰り返すタスク用のカスタムシステムプロンプト（a custom system prompt for a repeated task）」 と定義されています。Webアプリ上で作成し、Procedure（手順）／Specifications（完了条件）／Advice（補足）／Forbidden Actions（禁止事項）／Required from User（必要な入力） といった節を持てる。「手順・完了条件・禁止事項・必要な入力」という並びは、よくできた業務マニュアルの目次そのものです。!task-name のようなマクロで呼び出せ、組織横断で共有もできます。
部門・役職 → Dynamic Workflows の子Devin。 多数の専門特化エージェントが協調する構成は、Dynamic Workflows——公式いわく「Devinエージェントのチームをオーケストレーションする、決定論的なPythonスクリプト」——が担います。1つの調整役セッションが、既定では別VMで走る独立した子Devinを複数動かし、並列・パイプラインで処理をつなぎます。小さく分業するだけなら Devin CLI のサブエージェントも使えます。
監査・人事評価 → Enterprise API。 全アクションの追跡は、Enterprise API（api.devin.ai/v3/enterprise/*）が監査ログ・分析・ユーザー管理を横断で扱います。あわせて Custom Roles & RBAC、SSO（Okta / Microsoft Entra ID / SAML / OIDC）、IdPグループからのロール自動割り当てが揃い、権限境界を最初から配線に組み込めます。
📊 何がどう変わるのか
従来企業とAI駆動企業を並べると、変化がはっきりします。
| 観点 | 従来企業 | AI駆動企業（Devin） |
|---|---|---|
| 実行の主語 | 人 | AIエージェント（Devin） |
| 成長の上限 | 人員数（採用） | コンピュート量（並列セッション・ACU） |
| 24時間365日稼働 | 困難 | 既定（Automations ＋ クラウドセッション） |
| 人の役割 | 実行 ＋ 判断 | 判断・倫理・関係性、そして業務設計 |
| 改善ループ | 月次〜四半期 | 分〜時間 |
個人的に引っかかるのは成長の上限の行です。人員数からコンピュート量へ、という変化は、採用計画がそのまま予算計画になるという意味です。Devinでいえば「何人雇うか」ではなく「何セッション並列で回し、ACUをいくら使うか」。経営の意思決定の形そのものが変わります。
そして最大の差は、ひとことで言えば「改善ループの速度」だと思います。月次〜四半期の改善が、分〜時間で回る。ここが効いてきます。
🚀 開発で実証したものを、経営に広げる
AI駆動企業の骨格は、「AIDDで実証した手段と仕組みを、企業運営に適用する」です。
- AIDD（AI-Driven Development）：開発プロセスの主語をAIにする。コード生成・テスト・レビューをAIが駆動し、少人数×超高速の開発を実証する
- AIDM（AI-Driven Management）：同じ原理を事業オペレーション全体と経営に拡張する。営業・経理・企画・意思決定までAIが駆動し、人は判断・倫理・関係性に集中する
Devinはこの「開発での実証」を担うエージェントです。コードを書き、テストし、PRを出すところを自律的に回す。その実行エンジンを、開発 → 事業 → 経営へと広げていく、という順番です。開発での手応えが先にあるからこそ、経営に広げる話が地に足が着きます。
🧰 実装の道具は、Devinで一通り揃う
「AIで動く会社を作る」と言うと、巨大な内製が要りそうに聞こえます。ですが、必要な要素を並べてDevinに割り当てると、道具はおおむね揃っています。
| 必要な要素 | Devinでの担当 |
|---|---|
| 業務の実行（エージェント本体） | Devin（CLI ／ クラウドセッション） |
| 定型手順の共有 | Playbooks |
| 知識蓄積 | Knowledge（→ Skills / Plugins へ移行中） |
| Workflow（オーケストレーション） | Dynamic Workflows |
| 起動・トリガー | Automations（schedule / Slack・GitHub・Linear・webhook） |
| トレーサビリティ | セッション記録 ＋ Enterprise API の監査ログ |
| コスト最適化 | Usage Policies（ACU上限）＋ 利用状況の分析 |
実行も、手順書も、知識も、束ねる仕組みも、起動の入口も、監査も、コストの天井も、名前のついた機能として存在します。だから——足りないのはツールではなく、業務をエージェントに任せる設計です。
🔌 Devinで実装するときの、3つの勘所
とはいえ、図面まで降ろすと「名前のついた機能にそのまま収まる部分」と「自分で設計が要る部分」が見えてきます。特に効いてくるのが次の3点です。
① 外部イベントの受信：標準装備だった
「イベントが来たらエージェントを起こす」という入口は、自動化の要です。ここを自作しなくて済むのがDevinの強みでした。Automations が、**スケジュール（cron）とイベント（Slack / GitHub / Linear / webhook）**の両方のトリガーを持ち、条件や呼び出し回数の上限も設定できます。エージェントの中身（親子の分業・承認・安全な実行）を設計すれば、起動のきっかけは配線するだけです。
② 親子の協調：設定ではなく、コードで握る
「部門・役職」をエージェントのチームに写したとき、誰にどの順で何を振るかは自分で決める部分です。Devinの Dynamic Workflows は、これを決定論的なPythonスクリプトで書きます。並列もパイプラインもコードで制御でき、JSONスキーマで段をつなぎ、各呼び出しが記録されて再開もできる——手続き的にオーケストレーションを握る手触りです。
③ コストの上限：放置運用には天井が要る
イベント駆動で勝手に動く自動化を本番に置くなら、金額の天井を最初から設計に入れるべきです。Devinは Usage Policies で、メンバー単位・組織単位に月次のACU上限を設定します。どちらかの上限に達するとセッションが block され、ユーザーは「Request more」ボタンから増枠をリクエストできます（増枠は当該請求サイクル限りの一時的なもの）。上限はDesktop・CLI・クラウドの全サーフェスに効きます。なお、このper-userのACU上限はベータで、エンタープライズでの有効化が必要です。
🧠 知識は「事前に蓄える」から「使いながら蓄える」へ
AI駆動企業では、知識設計の重心が移ります。これまではAIに与える知識を事前に蓄える方式（RAG）で、知識の鮮度と網羅性は「人が事前に用意できた分」が上限でした。AI駆動企業では、AIに業務をさせることで知識が蓄える。実行ログや修正記録がそのまま知識源になり、使えば使うほど組織の知識が増えていく——暗黙知が、業務を回すだけで形式知化されていく状態を目指します。
Devinでこの役割を担うのが Knowledge です。公式では「新しい社員に組織の文脈をオンボーディングするようなもの」と説明され、コード規約・デプロイ手順・PR命名・テスト手順などをセッションをまたいで参照させます。効いてくるのは自動生成で、リポジトリへのアクセスを与えると README やファイル構成から知識を自動で作り、CLAUDE.md / AGENTS.md / .cursorrules などの既存ルールファイルも取り込みます。取得は trigger ベースで、どのセッションでどの知識が使われたかは「Accessed Knowledge」として表示されます。
「取り込み口（既存ルールファイル）」と「可視化（Accessed Knowledge）」が最初から付いているのが、この方向と相性のいいところです。
⚠️ ひとつ正確に書いておくと、公式ドキュメント上、Knowledge は Skills（Plugins）へ移行中の扱いになっています。今から設計するなら Skills も併せて見ておくのが安全です。この記事では写像の分かりやすさを優先して Knowledge の語で説明しています。
⚖️ 人の関与は、リスクで3段階に分ける
稟議の写像であるHITLゲートは、実務では「全部に人を挟む／全部自動」の二択ではなく、リスクの高さで関与の深さを設計するのがコツです。一般的な整理は3段階です。
| リスク | 関与モデル | 例 |
|---|---|---|
| 高 | Human-in-the-Loop（実行前に人が承認） | 顧客への送信、本番デプロイ、契約・支払い |
| 中 | Human-on-the-Loop（AIが実行、人は監視して必要時に介入） | 社内レポート生成、PR作成、在庫の自動発注 |
| 低 | Human-out-of-the-Loop（完全自動＋事後監査） | 社内検索・要約、下書き生成、分類・集計 |
これをDevinの権限の仕組みに寄せると、素直に対応します。Devin CLI は段階的な権限モードを持ち、
| モード | 挙動（ざっくり） |
|---|---|
| Normal（既定） | 読み取りは自動承認、書き込み・シェルは都度承認 |
| Accept Edits | ワークスペース内の編集は自動、シェル等は承認 |
| Smart | 高速モデルが安全性を判定。ただし rm・sudo・パッケージ導入・git破壊操作などは常に承認を要求 |
| Bypass | すべて自動承認 |
| Autonomous | OSレベルのsandboxと併用。シェル/fetchは自動、直接編集は承認 |
さらに allow / ask / deny ルールで粒度を切れ、deny が常に最優先（どんなに具体的な allow でも deny は上書きできない）。組織レベルの deny / ask はプロジェクト・ユーザー設定で上書きできません。高リスクは deny/ask で止め、低リスクは allow で通す——という粒度で、3段階がそのまま表現できます。
- 高リスク → 危険操作に
deny/ask。Normal で都度承認 - 中リスク → Autonomous ＋ sandbox で走らせ、ログで監視
- 低リスク →
allowで自動通過。Bypass 寄り
（Smart モードは段階的な提供中で、環境によってはまだ選択肢に出ないことがあります。また、この3段階への割り当ては私の寄せ方で、公式がこの3段階を定義しているわけではありません。）
🎯 勝ち筋の定義
当てはめ終えて、いちばん強く残ったのはツールの話ではありませんでした。
勝ち筋は「プロンプトが上手い人材」ではなく、業務をエージェント単位に分解できる組織にある。
Devinは「箱」を十分に用意してくれます。業務の実行も、手順書（Playbook）も、知識（Knowledge）も、起動の入口（Automations）も、承認の境界（権限ルール）も、ガバナンス（Enterprise API）も。ですが、箱の中身は組織が書くしかありません。Playbook に何を書くか、Knowledge に何を貯めるか、どのイベントで誰を起こしどこで人を挟むか、親子の分業をどう切るか——これらは全部、ツールが決めてくれない業務設計です。
成功する組織に共通しそうな要因を挙げるなら、経営トップの関与・業務設計の解像度・ガバナンス先行の3つ。特にガバナンス先行——スケールの前に権限境界・監査ログ・監視体制を整える——は、Devinなら権限ルールと Enterprise API で最初の配線に組み込めます。
📝 まとめと、経営の問いの書き換え
AI駆動企業の要点を5つに畳むと、こうなります。
- AIによる効率化ではなく、AIで動く企業を作る
- 業務プロセス全体をAIエージェントが実行する形へ移行する
- 使えば使うほど賢くなるための知識の蓄積（Knowledge）
- 人の役割は、判断・倫理・関係性と、業務設計
- いまある組織は、AIエージェント導入と知識設計から始める
そして最後に、経営の問いそのものが書き換わります。
「何人雇えば回るか？」から、「どのタスクをAIに任せ、人はどこに集中するか？」へ。
先の比較表にあった「成長の上限が人員数からコンピュート量へ」が、経営の問いの形で言い直されています。Devinで言えば、「採用枠」ではなく「Playbookの枚数」「並列セッション数」「ACUの予算」で事業の伸びを設計する、ということです。
おわりに
「AI駆動企業」という大きな絵を、Devinの機能名まで1つずつ降ろしてみました。分かったのは、写像表の左右が、思っていたよりまっすぐ繋がることです。業務マニュアルは Playbooks、教育は Knowledge、部門は Dynamic Workflows の子Devin、稟議は権限ルール、ガバナンスは Enterprise API。機能の名前がもともと会社の語彙に寄せてあるぶん、Devinはこの絵を描きやすい側だと感じました。
同時に、**図面に落として初めて見える「自分で書く部分」**もありました。起動の入口は Automations で埋まる一方、親子の協調はコードで握り、コストの上限は天井として設計する。「揃っているのは箱で、足りないのは設計」というのが、当てはめ終えての実感です。
ここで正直に書いておくと、私がやったのは図面を引くところまでで、まだ一度も実際に動かしていません。だから「組める」とは言い切れず、言えるのは「公式ドキュメント上は辻褄が合った」まで。見取り図と図面の次は、実走が要ります。
次は——今度こそ——どれか1行を実際に動かしてみます。Automations で小さなイベントを1つ受けて、Playbook を1枚持たせたDevinを起こすところから。
参考リンク
- Creating Playbooks（Devin Docs）
- Knowledge Onboarding（Devin Docs）
- Dynamic Workflows（Devin Docs）
- Scheduled Sessions / Automations（Devin Docs）
- CLI Permissions（Devin Docs）
- CLI Subagents（Devin Docs）
- Usage Policies（Devin Docs）
- Usage Tracking（Devin Docs）
- Enterprise Getting Started（Devin Docs）
- SSO Onboarding Guide（Devin Docs）
- API Overview（Devin Docs）