> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Devin Connect > Devin Connect は Devin に内部システムへの非公開アクセスを提供します。gateway をポリシープロキシとしてデプロイし、アウトバウンド専用トンネルまたは AWS PrivateLink 経由で接続します。 Devin Connect は現在**アーリーアクセス**段階です。機能や設定は今後変更される可能性があります。アーリーアクセスをご希望の場合は、Cognition の account team までお問い合わせください。 Devin Connect を使えば、リソースごとにネットワーク経路を用意することなく、Devin セッション から内部システム (ソース管理、アーティファクト registries、内部 API) にアクセスできます。自社ネットワーク内に軽量な gateway をデプロイすると、Devin はプライベート接続経由でそこに接続します。 **現在の gateway リリース: v0.0.2**

Devin Connect の機能

Devin Connect は 2 つの部分から構成されており、それぞれ独立して設定します。 **ネットワーク内のポリシープロキシ。** Gateway は、デフォルト拒否の 許可リスト を備えた HTTP CONNECT proxy です。`host:port` への接続リクエストを受け付け、設定したルートと照合し、お客様自身の DNS で名前を解決し、宛先へ接続してバイト列をそのまま中継します。Gateway も Devin のインフラストラクチャも、Devin VM とお客様のサービス間の TLS を終端したり検査したりすることはなく、すべての接続が監査ログに記録されます。 **Devin からそのプロキシへの非公開経路。** Devin は、どちら側も公開インターネットに何も露出させずにプロキシへ到達する必要があります。その方法は 2 つあり、いずれの場合もプロキシの動作は同一です。 * **リバーストンネル**: Gateway が TLS 経由で Devin 側のエンドポイントへアウトバウンド接続し、Devin はそのトンネルを通じて接続リクエストを送り返します。お客様のネットワークへのインバウンドは一切開放されず、クラウドプロバイダーとの統合も不要です。 * **AWS PrivateLink**: Gateway の前面に Network Load Balancer と VPC Endpoint Service を配置し、Cognition が専用テナント VPC 内の Interface VPC Endpoint からこれを利用します。トラフィックは AWS バックボーン内に留まり、Devin は非公開 IP 経由で Gateway へ直接接続します。 以下の [接続モード](#connectivity-modes) タブでいずれかを選択してください。このページのその他の内容は、どちらのモードにも共通して当てはまります。 いずれの場合にも成り立つ特性: * **専用のシングルテナント VPC。** Devin デプロイメントは独自の VPC 内で動作します ([Customer Dedicated Deployment モデル](/ja/enterprise/deployment/overview#customer-dedicated-deployment-architecture) を参照) 。Devin VM は、ルーティング対象の宛先向けトラフィックを、Cognition が設定した egress 制御を介して Gateway へ送信します。 * **デフォルト拒否を二重に適用。** ルートは Gateway 側と Devin 側の両方で適用されるため、片側の設定変更だけではアクセス範囲を広げられません。宛先をルーティングしても、セッションの権限が広がることはありません。あくまでセッションの [セキュリティプロファイル](/ja/product-guides/security-profiles) が許可している必要があります。 * **アプリケーションの TLS はエンドツーエンド。** Gateway は不透明なバイトストリームを転送するだけです。 * **DNS はネットワーク内に留まる。** ルートの宛先はお客様のリゾルバー (デフォルトでは Gateway ホストのシステムリゾルバー、または設定したネームサーバー) で解決されます。 * **1 つのデプロイメントですべてのルーティング対象の宛先をカバー。** サービスごとに個別の仕組みを構築する必要はなく、Devin の設定でホスト名と IPv4 範囲を追加するだけです。

接続モードの選択

| | リバーストンネル | AWS PrivateLink | | - | - | - | | インバウンドの公開 | なし。Gateway 側から外向きに接続します | インターネット上には公開されません。Endpoint Service には Cognition のアカウントからのみ到達できます | | クラウド要件 | `:443` へのエグレスが可能なネットワークであれば可 | Gateway を AWS 上で稼働させ、NLB と VPC Endpoint Service が必要 | | 接続の認証 | Devin が発行するエンロールメントトークン | Endpoint Service に設定した AWS アカウントの principal | | 通信経路 | 公開インターネット (TLS) 、または自社の VPN／Transit Gateway アタッチメント | AWS バックボーン | | リージョン間 | 該当なし | Endpoint Service で有効化すればサポート |

Devin Connect を設定する

どちらのモードでも、設定は Devin の Web アプリで行います。Enterprise 設定の「Devin Connect」ページから設定でき、適切な管理者ロールを持つユーザーが利用できます。1 つのアカウントに複数の gateway を作成でき、gateway ごとにそれぞれの宛先グループへのルーティングを担います。作成できるリバーストンネル gateway は最大 1 つまでですが、PrivateLink gateway は任意の数を作成できます。 1. 「Add gateway」を選択して名前を付け、接続方式を選びます。リバーストンネルの場合は「Tunnel」、AWS PrivateLink の場合は「Direct」を選択します。「Direct」の場合は、Interface Endpoint の DNS 名とポートも入力します ([AWS PrivateLink](#connectivity-modes) タブを参照) 。 2. gateway のカードで、Devin がその gateway 経由でアクセスする宛先ごとに「Add destination」を選択します。宛先には、完全一致のホスト名、または IPv4 アドレスや `10.20.0.0/16` のような CIDR を指定します。ワイルドカードはサポートされていません。1 つの宛先が所属できる gateway は 1 つだけです。 3. トンネル gateway の場合は、「Generate token」を選択して登録します。エンロールメントトークンは一度だけ表示され、Devin に保存されることはありません。「Regenerate token」を使えば、いつでもローテーションまたは失効できます。Direct gateway には認証対象となるトンネルがないため、この手順は不要です。 4. トンネル gateway の場合は、利用するプラットフォーム (Docker、Kubernetes、AWS ECS、ECS または EC2 上の Terraform、Linux ホスト) 向けのデプロイ用スニペットをコピーします。スニペットには、gateway の宛先から生成された、そのまま実行できる `config.yaml` が含まれています。宛先を変更した後は、スニペットを再度コピーしてください。 各トンネル gateway のカードには、現在の接続状態と最終接続日時も表示されます。

ホスト名と IPv4 の宛先

* **ホスト名**は、セッションの接続先の名前で照合されます。この名前は TLS SNI または HTTP の `Host` ヘッダーから取得されます。そのため、ホスト名でルーティングできるのは TLS とプレーンな HTTP のトラフィックのみです。名前解決には、Gateway がお使いの DNS を使用します。 * **IPv4 アドレスと CIDR** は接続の宛先 IP で照合されるため、SSH やデータベース接続を含むあらゆる TCP プロトコルをルーティングできます。これらのルートでは、Devin は社内のホスト名を解決しません。セッションから IP アドレスで接続するか、環境内で名前解決の手段を用意してください。たとえば、[ブループリント](/ja/onboard-devin/environment/blueprints)で `/etc/hosts` の項目を設定する方法があります。 Gateway 自体の `config.yaml` で IPv4 の宛先を許可するには、`ipv4` ルールを使用します。生成されるスニペットには、これらのルールがあらかじめ含まれています。

接続モード

Devin Connect reverse tunnel architecture Gateway は、テナントのエンドポイント `.gateway.devinenterprise.com:443` へ N 本の TLS トンネルを外向きに張ります。インバウンドポートを開放する必要は一切ありません。登録済みのトンネルが転送するのは Devin 側から Gateway へ向けて開かれたストリームのみで、Devin へのインバウンド経路にはなりません。 エンロールメントの流れは次のとおりです。 1. Devin が「Devin Connect」設定ページから、トンネル gateway 用のエンロールメントトークンを発行します。 2. `tunnel.auth_token_file` が指すパスに、そのトークンを Gateway ホスト上へ配置します。 3. Gateway が `.gateway.devinenterprise.com:443` へ接続し、Devin エッジのサーバー証明書を検証してトークンを提示します。 4. エッジがトークンを検証し (保存済みのダイジェストとの定数時間比較。生のトークンが Devin 側に保存されることはありません) 、トンネルを登録します。以降、gateway の接続先に対する Devin 側からの接続は、このトンネルを経由します。 トンネルは `tunnel` スタンザで設定し、`listen` アドレスを指定しないため、Gateway ホストはプロキシポートを一切公開しません。 ```yaml theme={null} tunnel: endpoint: acme.gateway.devinenterprise.com:443 gateway_id: gw-1 # エンロールメントトークン（1行）。接続試行のたびに再読み込みされるため、 # 再起動せずにローテーションできます。 auth_token_file: /etc/devin-gateway/tunnel-token # carrier: websocket # 既定値。WebSocketフレーミングを無効にする場合は `direct` を利用します。 # ca_file: corp-ca.pem # 社内TLSインスペクションプロキシがエッジ接続を # # 再署名する場合のみ指定します。 # egress_proxy: # 必要な場合のみ、顧客側の送信HTTP CONNECTプロキシを指定します。 # addr: proxy.corp.example:3128 ``` | フィールド | 説明 | | - | - | | `endpoint` | テナントのエンドポイント (`.gateway.devinenterprise.com:443`) 。 | | `gateway_id` | この Gateway インスタンスの識別子。ログとメトリクスで使用されます。 | | `auth_token_file` | 1行のエンロールメントトークンファイルへのパス。 | | `carrier` | `websocket` (デフォルト) または `direct`。いずれも同一のTLS接続内で同じプロトコルを実行します。`websocket` は、生のTLSを通せないエグレス経路向けにHTTP Upgradeフレーミングを付加します。 | | `ca_file` | Devin エッジ証明書を検証するためのPEM形式のCAバンドル。証明書を再署名する社内TLSインスペクションプロキシの背後にある場合にのみ必要です。 | | `egress_proxy` | 送信トラフィックがプロキシを経由する必要がある場合の、エグレスHTTP CONNECTプロキシ (`addr`、任意で `auth`) 。 | | `connection_pool` | `size` (1〜16トンネル、リロード可能) および `max_streams_per_connection` (2〜2048) 。 | このモードで追加で確認すべき項目: * Gateway から `.gateway.devinenterprise.com:443` および許可リストに登録した内部サービスへのエグレスを許可してください。インバウンドのルールは不要です。 * エンロールメントトークンはシークレットマネージャーに保存し、ファイルとしてマウントしてください。イメージ、バージョン管理下の設定ファイル、ログには決して埋め込まないでください。Gateway がトークンをログに出力することはありません。 * 必要に応じて、エグレスのCIDRレンジをCognitionに連携すれば、公開エンドポイントをIPレベルで制限できます (多層防御。認証のゲートはあくまでエンロールメントトークンです) 。 Devin Connect PrivateLink architecture Gateway はローカルの HTTP CONNECT リスナー上で allowlist proxy を提供し、Devin は PrivateLink 経由でそのリスナーに接続します。 1. `listen` アドレスを指定した Gateway を、AWS VPC 内の非公開サブネットにデプロイします。 2. その前段にリスナーポートを宛先とする Network Load Balancer を配置し、その NLB から VPC Endpoint Service を作成します。 3. Cognition の AWS account を allowed principal として追加し、endpoint service 名を Cognition に送付します。 4. Cognition が dedicated tenant VPC 内に Interface VPC Endpoint を作成し、その DNS 名をお客様に連絡します。これにより endpoint service へ接続リクエストが送信されるので、これを承認します (サービス側で自動承認を有効にしている場合は自動的に承認されます) 。 5. 「Devin Connect」設定ページで「Direct」接続の gateway を追加し、Interface Endpoint の DNS 名とリスナーポートを入力したうえで、Gateway が処理する宛先を追加します。同じ宛先を Gateway の `routes` にも設定してください。 endpoint service は Cognition の account からのみ利用でき、NLB は VPC 内部に閉じているため、公開リスナーは存在しません。アクセスは endpoint service 上の AWS principal と、Gateway 自身の default-deny の allowlist によって認可されます。 Gateway の configuration では、NLB が宛先とするポートを `listen` に設定します。 ```yaml theme={null} schema_version: 1 admin_listen: 0.0.0.0:9090 # NLB のターゲットとなるローカルの HTTP CONNECT リスナー。 listen: 0.0.0.0:8443 routes: - name: devin rules: - hostname: "git.corp.example" - hostname: "api.corp.example" ports: [443] ``` Cognition に提供する情報: * VPC Endpoint Service 名 (例: `com.amazonaws.vpce.us-west-2.vpce-svc-0abc123`) * NLB が公開するリスナーポート * Cognition の AWS account が Allowed principal として許可されていることの確認 * Gateway のリージョンと異なる場合、Devin の tenant が稼働するリージョンを endpoint service がサポートしているかどうか このモードでの追加のチェックリスト項目: * NLB のターゲットを複数のアベイラビリティーゾーンで実行してください。 * サービスが Devin の tenant とは別のリージョンにある場合は、endpoint service でクロスリージョンサポートを有効にしてください。手順は [Dedicated Deployment のプライベートネットワーキング](/ja/enterprise/deployment/dedicated_saas_private_networking#cross-region-privatelink-if-your-services-are-in-a-different-region)と同じです。

Configuration リファレンス

Gateway は単一の YAML ファイルで設定します。設定内容は厳密に検証され、fail-closed で動作します。つまり、検証に失敗した設定はファイル全体が拒否され、直前の設定がアクティブなまま維持されます。ファイルは 5 秒ごとにポーリングされ、ホットリロードされます。 ```yaml theme={null} schema_version: 1 # 管理リスナー (/healthz, /readyz, /metrics)。 admin_listen: 127.0.0.1:9090 # データプレーンリスナー。PrivateLink（direct）モード専用: `tunnel` セクションが # ない場合は必須、ある場合は拒否されます。 # listen: 0.0.0.0:8443 # ルートの宛先を解決するための顧客側 DNS（省略時はシステムリゾルバーを使用）。 dns: nameservers: ["10.0.0.2:53"] timeout: 5s # デフォルト拒否の 許可リスト。ルールには hostname と ipv4/ipv6 CIDR を指定できます。 # ports を省略した場合は任意のポートが対象になります。 routes: - name: scm rules: - hostname: "git.corp.example" - hostname: "artifacts.corp.example" ports: [443] - name: internal-api rules: - hostname: "api.corp.example" ports: [443] - name: build-hosts rules: - ipv4: "10.20.0.0/16" ports: [22] # Devin 側エッジへのアウトバウンドトンネル。PrivateLink モードでは省略します。 tunnel: endpoint: acme.gateway.devinenterprise.com:443 gateway_id: gw-1 auth_token_file: /etc/devin-gateway/tunnel-token ```

Routes (許可リスト)

いずれのルートにもマッチしなかった通信はすべて拒否されます。ルートのリストが空の場合は、すべてが拒否されます。ルートは記述順に評価され、最初にマッチしたものが適用されます。 | フィールド | 説明 | | - | - | | `name` | 一意のルート名。接続の audit logs に表示されます。 | | `rules` | 宛先のマッチングルール。いずれかのルールにマッチすれば、そのルートにマッチしたものとみなされます。`hostname` のマッチングは大文字・小文字を区別しません。`ipv4`/`ipv6` の CIDR ルールは、リテラル IP 宛の接続のみにマッチします。 | | `ports` | 許可する宛先ポート。省略した場合は任意のポートが対象となります。 | | `upstream_proxy` | このルートで経由する上流の HTTP CONNECT proxy (任意) (`addr`、任意で `auth`) 。 | hostnames は DNS 解決前に、リクエストされたとおりの名前でマッチングされます。そのため policy は、解決結果の IP ではなく名前に対して適用されます。

リスナー

| フィールド | 説明 | | - | - | | `admin_listen` | `/healthz`、`/readyz`、`/metrics` 用の管理リスナー。 | | `listen` | データプレーンの HTTP CONNECT リスナー。PrivateLink モードでは設定してください。トンネルモードでは省略します (この場合、接続リクエストは認証済みトンネル経由でのみ到着します) 。 | | `dial_timeout` | アップストリームターゲットへの接続 (ダイヤル) のタイムアウト (デフォルトは 10 秒) 。 |

DNS

| フィールド | 説明 | | - | - | | `nameservers` | ルートの宛先の名前解決に利用するDNSサーバー (`ip:port`) 。省略した場合はGatewayホストのシステムリゾルバーが使用されます。Gatewayはお使いのネットワーク内で動作するため、通常はこちらのケースになります。 | | `timeout` | クエリごとのタイムアウト (デフォルトは5秒) 。 | DNSがループバック、リンクローカル、または未指定のアドレスに名前解決するホスト名ルートは拒否されます。そのため、許可リストに登録された名前をGatewayホスト自体やメタデータエンドポイントに向けることはできません。

Gateway の実行

Gateway は、単一の静的バイナリを含む container image として提供されます (image は `FROM scratch` でビルドされ、非 root ユーザーで実行されます) 。設定は `/etc/devin-gateway/config.yaml` にマウントし、トンネルモードでは token ファイルを `tunnel.auth_token_file` で指定した場所にマウントしてください。 ```bash theme={null} gateway serve --config /etc/devin-gateway/config.yaml gateway validate-config --config config.yaml # 設定の厳密な検証 gateway doctor --config config.yaml # JSON形式の診断サマリー ``` `admin_listen` 上の運用エンドポイント: * `/healthz` — プロセスの死活確認。 * `/readyz` — 準備状態。 * `/metrics` — Prometheus メトリクス。 両モード共通のデプロイ時のチェックリスト: * Gateway はプライベートサブネットで実行してください。 * `/healthz` と `/readyz` をオーケストレーターのヘルスチェックに組み込んでください。 * Devin の設定にある各 gateway の接続先と、その Gateway の設定にあるルートを常に同期させてください。片方だけで許可されている接続先には到達できません。

ログ記録とSIEM統合

Gatewayは標準出力にログを出力します。標準出力が端末でない場合 (コンテナ環境では通常こちらになります) 、ログは機械処理しやすいJSON行形式で出力されます。SIEMに取り込むには、プラットフォームの標準的なログパイプラインを利用してください。コンテナのログドライバーやエージェント (CloudWatch Logs、Fluent Bit、Vector、Datadogエージェントなど) が標準出力を収集し、他のワークロードのログと同様に転送します。GatewayにSIEM固有の設定は必要ありません。 接続の監査イベントには次のものが含まれます。 * `conn_open` と `conn_close`。宛先ホストとポート、マッチしたルート名、クライアントアドレス、各方向の転送バイト数、継続時間を含みます。 * `deny`。宛先および理由 (例: マッチする許可リストルートがない) を含みます。 エンロールメントトークンがログに記録されることはなく、ペイロードの内容も記録されません。 Gatewayを使わないサービスごとの非公開の接続については、[Dedicated Deployment のプライベートネットワーク](/ja/enterprise/deployment/dedicated_saas_private_networking)を参照してください。デプロイメントモデルの概要については、[デプロイメントの概要](/ja/enterprise/deployment/overview)を参照してください。 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.