メインコンテンツへスキップ

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をセルフホスト型システムと連携するのか？

組織でセルフホスト型のソースコード管理システム (GitLab など) やアーティファクトリポジトリ (Artifactory など) を利用している場合でも、Devin を最大限に活用できます。これらのサービスを安全な形で Devin のインフラストラクチャに公開することで、システムに対するコントロールは自社で維持しつつ、Devin を開発ワークフローに効果的に組み込めるようになります。

​
概要

チームは Network Load Balancer (NLB) を作成し、Devin の固定 IP を許可リストに登録して、NLB 用の DNS レコードを公開できます。このアプローチにより、次のことが可能になります:
  • アクセスを小さく管理された範囲に限定 - Devin の既知の IP からのみ接続可能
  • セットアップに要するエンジニアリング工数は数時間以内
  • 既存インフラを維持 - クラウドホスト型ソリューションへ移行する必要なし
  • 一元管理が可能 - 複数サービス向けに単一のロードバランサーを利用可能 (任意)

​
前提条件

インテグレーションを設定する前に、次のものが揃っていることを確認してください：
  • 社内ネットワークからアクセス可能な セルフホスト型 GitLab (またはその他の SCM システム)
  • セルフホスト型アーティファクトリポジトリ (オプション、例：Artifactory や Nexus)
  • ファイアウォール、ロードバランサー、DNS を構成できる ネットワーク管理権限
  • Devin の静的 IP アドレス - こちら に記載
このインテグレーションは Enterprise プランをご利用のお客様が対象です。サポートが必要な場合は enterprise@cognition.ai までご連絡ください。

​
セットアップ方法

セルフホスト型サービスを Devin から利用可能にするには、主に次の 2 つの方法があります。 既存のセルフホスト型インフラはそのまま維持し、ファイアウォールレベルで Devin の固定 IP を許可リストに登録します。 ソースコード管理の場合:
  1. Devin の IP (こちら に記載) からの受信接続を許可するようにファイアウォールを設定します
  2. GitLab (または他の SCM) インスタンスが HTTPS 経由でアクセス可能であることを確認します
  3. 連携設定時に Devin に URL を指定します
アーティファクトリポジトリの場合:
  1. Devin の IP を Artifactory/Nexus の許可リストに追加します
  2. アーティファクトリポジトリが HTTPS 経由でアクセス可能であることを確認します
  3. Devin がアーティファクトにアクセスできるよう、適切な認証情報を設定します
アーティファクトリポジトリでロードバランサーを使用している場合、IP 許可リストに関する重要な詳細については、以下の ロードバランサーに関する考慮事項 セクションを参照してください。

​
オプション 2: 集約型ロードバランサー

複数のサービスを単一の Application Load Balancer (ALB) または Network Load Balancer (NLB) の背後に配置し、IP フィルタリングを一元管理します。 利点:
  • すべてのネットワークフィルタリングを単一の場所で一元管理できる
  • 異なるドメインを持つ複数の内部サービスに対応できる
  • セキュリティ監査とコンプライアンスを簡素化できる

​
ロードバランサーに関する考慮事項

Application Load Balancer (ALB) と Network Load Balancer (NLB) を選択する際は、それぞれの IP 許可リスト (allowlisting) の扱い方を考慮してください。 Application Load Balancer (ALB) - ほとんどのユースケースで推奨:
  • ALB はレイヤー 7 (HTTP/HTTPS) で動作し、高度なルーティング機能を提供します
  • トラフィックは NAT を経由するため、バックエンドサービスからは Devin の送信元 IP ではなく、ALB の内部 IP アドレスが見えます
  • ALB 配下のアーティファクトリポジトリの場合: リポジトリからはロードバランサーの内部 IP が見えるため、Artifactory/Nexus 側で直接 IP allowlisting を設定する必要があります
  • ALB レベルでの IP フィルタリングには AWS WAF を使用してください (下記の例を参照)
Network Load Balancer (NLB) - IP allowlisting が必要なシナリオに適した選択肢:
  • NLB はレイヤー 4 (TCP) で動作し、元の送信元 IP アドレスを保持します
  • バックエンドサービスからは Devin の実際の送信元 IP が見えます
  • NLB 配下のアーティファクトリポジトリの場合: 送信元 IP が保持されるため、ロードバランサーレベルでの IP allowlisting だけで十分です
  • 各 IP アドレスごとにセキュリティグループを手動で設定する必要があります
ALB は柔軟性と管理のしやすさから一般的には優先されますが、バックエンドサービス側での追加設定なしにロードバランサーレベルで IP allowlisting を行いたい場合は、NLB が有効です。

​
AWS 実装例

2 つのロードバランサー方式それぞれについて、AWS の設定例を以下に示します。

​
WAF 付き Application Load Balancer (簡単な方法)

# Devinの静的IPを使用してIPセットを作成
aws wafv2 create-ip-set \
  --name devin-allowed-ips \
  --scope REGIONAL \
  --ip-address-version IPV4 \
  --addresses 1.2.3.4/32 5.6.7.8/32 9.10.11.12/32 13.14.15.16/32

# Create a WAF web ACL
aws wafv2 create-web-acl \
  --name devin-access-control \
  --scope REGIONAL \
  --default-action Block={} \
  --rules file://waf-rules.json

# Associate the WAF with your ALB
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:region:account:regional/webacl/... \
  --resource-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/...
ここに記載されている IP アドレスを、IP whitelisting ドキュメント に記載されている実際の IP アドレスに置き換えてください。

​
Network Load Balancer (セキュリティグループを手動で設定する場合)

# 各Devin IPに対してセキュリティグループにインバウンドルールを追加
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 1.2.3.4/32

# 各IPアドレスに対して繰り返す
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 5.6.7.8/32

# すべてのDevin IPに対して同様に実行...

​
DNS 設定

ロードバランサーのセットアップが完了したら、Devin が利用できる DNS レコードを作成してください。 
# 例: gitlab.yourcompany.comをロードバランサーに向ける
# ドメインはロードバランサーのIPに解決され、トラフィックをフィルタリングして
# Devinのホワイトリストに登録されたIPからの接続のみを許可します

# AWS Route 53を使用する場合:
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch file://dns-change.json
dns-change.json の例： 
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "gitlab.yourcompany.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z215JYRZR1TBD5",
        "DNSName": "your-alb-name-123456.us-west-2.elb.amazonaws.com",
        "EvaluateTargetHealth": false
      }
    }
  }]
}

​
統合手順

ネットワークインフラストラクチャの設定が完了したら、次の手順を実行します。
  1. 接続をテストする - 設定したドメインを使用して、ネットワークの外部からサービスにアクセスできることを確認します
  2. Devin サポートに連絡する - Cognition に次の情報を連絡してください:
    • セルフホスト型 GitLab の URL (例: https://gitlab.yourcompany.com)
    • アーティファクトリポジトリの URL (該当する場合)
    • 特定の認証要件があればその内容
  3. 統合設定を完了する - Devin チームと連携して接続を最終確定します
  4. リポジトリを設定する - Devin’s Machine にリポジトリを追加します
Devin にアクセスを許可する前に、許可リスト (allowlist) に含まれていない IP アドレスから接続を試みることで、IP フィルタリング設定をテストしてください。接続はブロックされるはずです。

​
ベストプラクティス

  • HTTPS を使用する - 常に有効な SSL 証明書付きの HTTPS でサービスを公開する
  • 専用のサービスアカウントを作成する - GitLab/SCM システム内で Devin 専用のアカウントを用意する
  • アクセスログを監視する - Devin の IP アドレスからの接続ログを定期的に確認する
  • セットアップを文書化する - ロードバランサーおよび DNS 構成についての社内ドキュメントを整備しておく
  • フェイルオーバーをテストする - ロードバランサーやサービスの障害を問題なく処理できる構成になっていることを確認する
  • 定期的なセキュリティ監査 - 公開しているサービスを定期的に見直し、IP アローリストを検証する

​
トラブルシューティング

Devin がセルフホスティング環境に接続できない場合:
  • すべての Devin の IP アドレス が許可リスト (allowlist) に登録されているか確認する
  • SSL 証明書が有効で信頼されていることを確認する
  • DNS レコードが正しく設定され、伝播していることを確認する
  • ファイアウォールのルールで HTTPS (ポート 443) のトラフィックが許可されていることを確認する
認証エラーが発生する場合:
  • サービスアカウントの認証情報が正しいことを確認する
  • サービスアカウントが SCM／アーティファクトシステム内で適切な権限を持っていることを確認する
  • 許可リスト以外に IP ベースの認証制限がないか確認する
パフォーマンスに関する問題:
  • ロードバランサーのメトリクスを監視し、ボトルネックがないか確認する
  • セルフホスティングしているサービスに十分なリソースがあることを確認する
  • 自社インフラと Devin のシステムとの地理的な近接性を考慮する

​
サポート

セルフホスト型インテグレーションに関するサポートが必要な場合は、次の手順に従ってください。
  1. app.devin.ai/settings/support から、当社チームとの Slack Connect チャンネルを作成する
  2. ご利用中のセットアップの詳細を記載して、enterprise@cognition.ai にメールを送信する
  3. 問題を報告する際は、機密データをマスクしたうえで、関連する設定ファイルを共有する