これを手作業で記述する必要はありません。 環境を設定する最も簡単な方法は、Devinのセッションを開始し、リポジトリの設定を依頼することです。Devinがプロジェクトを解析し、依存関係をインストールしたうえで、設定案を提示します。あとはタイムラインの提案カードで Approve をクリックします。このガイドは、Devinが生成した内容を理解したい場合、カスタマイズしたい場合、または設定を一から作成したい場合に向けたものです。
Devin は専用の VM 上で動作します。各セッションは、マシンイメージ (ツール、リポジトリ、dependencies があらかじめインストールされた保存済みの スナップショット) から起動します。Settings > Devin’s Environment で環境設定を編集することで、そのイメージに何を含めるかを制御できます。
environment.yaml は 3 つのセクションで構成されています。
Section 目的 実行されるタイミング 実行されるか initializeツールをインストールし、依存関係をコンパイルする ビルド 時のみ — 結果はマシンイメージに保存されます はい maintenance依存関係を最新の状態に保ち、認証情報の設定を作成する ビルド 時 + 各セッションの開始時 はい knowledge環境設定に関連する簡単なメモ (例: lint/test コマンド) セッション開始時に読み込まれます いいえ — 参照用メモのみ
時間がかかる処理や、一度だけ実行すればよい処理には initialize を利用します。たとえば、パッケージマネージャーのインストール、グローバル CLI ツールのインストール、ネイティブ依存関係のコンパイル、システムパッケージの追加などです。
結果はマシンイメージに保存され、セッション開始時に再度実行されることは ありません 。
initialize : | curl -LsSf https://astral.sh/uv/install.sh | sh npm install -g pnpm
複数行文字列は set -e を付けた 1 つの bash スクリプトとして実行されるため、どこか 1 行でも失敗するとビルドは停止します。行継続には \ を利用するか、ビルドログに個別に表示される名前付きステップのために展開形式 に切り替えてください。
シークレット ファイルは、マシンイメージが保存される前に削除されます。initialize 内のコマンドがシークレット値を設定ファイルに書き込むと (例: 認証トークンを .npmrc に書き込む) 、その値がイメージ内に残ってしまう可能性があり、セキュリティリスクになります。認証情報を書き込む処理は、代わりに maintenance に配置してください。maintenance では、シークレット が各セッションごとに新たに読み込まれます。
名前付きステップが必要な場合は、リスト形式を利用します。名前付きステップにすると、ビルドログのデバッグがしやすくなります。何かが失敗したとき、単なる行番号ではなく、どのステップで失敗したのかがわかります。
initialize : - name : Install uv run : curl -LsSf https://astral.sh/uv/install.sh | sh - name : Install system packages run : | sudo apt-get update -qq sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq libpq-dev ffmpeg
名前付きステップと名前なしステップは混在させることができます。run のないステップはスキップされます。
後続のステップで使用する環境変数を設定するには、KEY=VALUE 形式の行を $ENVRC ファイル (GitHub Actions の $GITHUB_ENV と同様) に書き込みます。$ENVRC に書き込まれたすべての変数は、後続のステップと Devin セッションに対して自動的にエクスポートされます。
initialize : - name : Configure environment run : | echo "NODE_ENV=production" >> $ENVRC echo "CI=true" >> $ENVRC
依存関係を最新の状態に保ち、認証情報の設定ファイルを書き込むために、maintenance を利用します。
これはビルド中 (initialize の後) および 各セッションの開始時、最新のコードを pull した後に実行されます。セッション開始のたびに実行されるため、コマンドは高速で、差分更新で済むものにしてください。
maintenance : | npm install pip install -r requirements.txt
npm ci ではなく、npm install を利用してください。npm ci は node_modules を削除し、毎回すべてを最初から再インストールします。npm install は差分更新で済むため、依存関係に変更がない場合は大幅に高速です。
設定ファイル (.npmrc、settings.xml、pip.conf) にシークレットを書き込むステップは、initialize ではなく maintenance に含めてください。これにより、各セッションの開始時に認証情報を最新の状態に保てます。
maintenance : - name : Install dependencies run : npm install - name : Configure private registry run : npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
knowledge は、今構築した環境を Devin が実際に利用するために必要な、ちょっとしたセットアップ情報を記載するために使います。たとえば、lint コマンド、テストコマンド、あるいは開発サーバーの起動方法などです。これはメインの Knowledge 機能と同じものではありません。 Devin に覚えておいてほしいことの大半 — アーキテクチャ、慣例、注意点、チームのワークフローなど — には、独立した Knowledge 機能を使ってください。こちらのほうがトリガーがより充実しており、編集もしやすく、プロジェクト全体の一般的な前提情報を置くのに適しています。environment.yaml の knowledge セクションは、このファイル内の環境設定に直接ひもづく短いメモだけに使ってください (例：“lint コマンドは npm run lint”) 。このセクションは任意であり、ほとんどの環境では必要ありません。各エントリは参照用のメモであり、実行はされません 。短く保ってください：
knowledge : - name : lint contents : | Run `npm run lint` to check for errors. Run `npm run lint:fix` to auto-fix. - name : test contents : | Run `npm test` for the full suite. Run `npm test -- --watch` during development. - name : startup contents : | Run `npm run dev` to start the dev server on port 3000.
Devin は 3 つの設定階層をサポートしています。各階層のコマンドは厳密に加算される ため、ビルド 時に順番に実行され、下位レベルで上位レベルの設定を上書きしたり変更したりすることはできません。
レベル 設定する場所 ここに記載する内容 例 Account-wide (Enterprise)Enterprise Settings > Environment すべての組織で必要なインフラ CA 証明書、社内プロキシ、VPN、DNS 組織全体 Settings > Environment > Organization-wide setup すべてのリポジトリで共有するツールやセットアップ 言語ランタイム (pnpm、uv)、Docker 認証、共有 CLI ツール Repo-specific Settings > Environment > [リポジトリ] プロジェクト固有のセットアップと knowledge npm install、lint/test/ビルド コマンド、アーキテクチャに関するメモ
何をどこに置くかの判断基準:
Enterprise 内のすべての組織で必要な場合 → account-wide
組織内のすべてのリポジトリで必要な場合 → 組織全体
1 つのリポジトリでのみ必要な場合 → repo-specific
各組織には 1 つのマシンイメージ があります。これは、ツール、リポジトリ、依存関係があらかじめインストールされた VM のスナップショットです。設定されているすべてのリポジトリが、その 1 つのイメージにクローンされ、セットアップされます。各セッションはクリーンなコピーから起動されます。
ビルドでは、次の順序で新しいマシンイメージが作成されます。
1. Enterprise config (runs in ~): a. initialize b. maintenance 2. Org-wide config (runs in ~): a. initialize b. maintenance 3. Clone all repositories (up to 10 concurrent) 4. For each configured repo, in the order shown in Settings (runs in ~/repos/<repo-name>): a. initialize b. maintenance 5. Health check, then image is saved
レイヤーは積み上げ式 です。repo固有のコマンドでは、組織全体またはEnterpriseの設定でインストールされたツールを利用できます。下位レベルでは、上位レベルで設定された内容を上書きできません。
ビルドには通常5〜15分かかります。個々のコマンドは1時間でタイムアウトし、ビルド全体は2時間でタイムアウトします。
各セッションでは、マシンイメージのクリーンなコピー が起動します。セッションが終了すると、すべての変更は破棄されます。
セッション開始時には:
Enterprise および組織全体の maintenance が (~ で) 実行されます。
関連するリポジトリの最新のコードが取得されます。
前回のビルド以降の依存関係の変更を反映するため、そのリポジトリの maintenance が再度実行されます。
そのリポジトリの knowledge エントリが Devin の前提情報に読み込まれます。
Knowledge はリポジトリごとです。 5 つのリポジトリを設定している場合、Devin が参照できるのは、現在作業しているリポジトリの knowledge エントリだけです。ステータス 意味 Success すべてのステップが完了しました。マシンイメージの準備ができています。 Partial 一部の リポジトリ は失敗しましたが、コアビルドは成功しました。セッションは動作しますが、一部の リポジトリ は完全にはセットアップされていない可能性があります。 Failed コアビルドが失敗しました (例: クローンの失敗、Enterprise/org のセットアップ失敗) 。 Cancelled 新しいビルドにより置き換えられました。 Skipped 設定変更は検出されませんでした。
Environment Settings UI では、リポジトリは 3 つの状態で表示されます。
状態 意味 Configured initialize/maintenance/Knowledge の YAML 設定があります。マシンイメージ で完全にセットアップされています。 Included マシンイメージ にクローンされていますが、カスタム設定はありません。Devin はコードにアクセスできます。 Available org からアクセスできますが、Environment には追加されていません。クローンもされていません。
Included と Configured の違い: “included” の リポジトリ は、Devin がコードにアクセスできるようクローンされていますが、カスタムのセットアップコマンドはありません。“configured” の リポジトリ には、initialize/maintenance/Knowledge の instructions が明示的に設定されています。次の場合、新しいビルドがトリガーされます。
$VARIABLE_NAME 形式でシークレットを参照します。Settings > Secrets maintenance : - name : Configure private registry run : npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
シークレットは、ビルドおよびセッション中に環境変数として利用できます。シークレットファイルはマシンイメージが保存される前に削除されますが、initialize 中にコマンドによってシークレットの値が設定ファイルに展開された場合、その展開後の値がイメージ内に残る可能性があります。認証情報は代わりに、各セッションで新たに読み込まれる maintenance に常に記述してください。
シークレットの管理について詳しくは、Secrets & Site Cookies を参照してください。
複数の リポジトリ を設定すると、それぞれに対応する YAML が Settings に作成されます。ビルド 中は、すべての リポジトリ が同じイメージ内でセットアップされ、別々のディレクトリにクローンされ、依存関係もそれぞれ個別にインストールされます。セッション 中は、アクティブな リポジトリ のメンテナンスと Knowledge のみが対象になります。
2 つのリポジトリが競合した場合はどうなりますか？ 各リポジトリのコマンドはそれぞれ独自のディレクトリで実行されるため、依存関係の競合はまれです。2 つのリポジトリがグローバルツールの異なるバージョンをインストールしたり、共有ファイル (~/.bashrc など) を変更したりする場合は、最後に実行されたものが有効になります。これを避けるには、共有ツールのインストールを組織全体設定に含めてください。モノレポでは、すべてのサブプロジェクトを対象とする1つのYAMLを作成します。後続のステップの作業ディレクトリを変更せずにサブディレクトリでコマンドを実行するには、サブシェル を利用します：
initialize : - name : Install pnpm run : npm install -g pnpm - name : Install uv run : curl -LsSf https://astral.sh/uv/install.sh | sh maintenance : - name : Frontend deps run : (cd packages/frontend && pnpm install) - name : Backend deps run : (cd packages/backend && uv sync) - name : Shared library run : (cd packages/shared && pnpm install) knowledge : - name : structure contents : | Monorepo with three packages: - `packages/frontend` — React app (TypeScript, pnpm) - `packages/backend` — Python API (FastAPI, uv) - `packages/shared` — Shared TypeScript utilities
丸括弧 (cd ... && ...) は重要です。これによりコマンドがサブシェル内で実行されるため、次の手順では作業ディレクトリがリセットされます。
マルチリポジトリ構成とモノレポ構成の使い分け: コードが 1 つの Git リポジトリにある場合は、サブシェルを使った 1 つの YAML を利用します。複数の Git リポジトリにまたがっている場合は、Settings で各リポジトリを個別に設定します。
YAML リファレンス フィールドのリファレンス表、実行の詳細、プリインストールされたツール、用語集。
設定例 Node.js、Python、Java、Go、モノレポ、Enterprise 向けパターンなど、コピー＆ペーストで使える使用例。
トラブルシューティングと FAQ ビルド 失敗のデバッグ、対話型セットアップからの移行、よくある質問への回答。
Enterprise 環境のセットアップ 権限、ビルド の継承、複数orgの管理、Enterprise への移行。
