DockerとプライベートGitHub App認証情報によるSweepのセルフホスト：安全なオンプレミス自動コード修正ガイド

金融、医療、インフラなどの厳格なコンプライアンスが求められるエンジニアリング組織において、自動コード修正エージェント（AI Coding Agent）の導入は、しばしば強固なセキュリティ障壁に直面します。企業ポリシーにより、コアビジネスのプロプライエタリなソースコードをマルチテナント型のパブリッククラウドへ転送することが禁止されているためです。オープンソースのAI開発者エージェントであるSweep（リポジトリ sweepai/sweep）のコンテナ化アーキテクチャは、この課題を根本から解決します。社内VPCやオンプレミスサーバーにDockerコンテナを展開し、専用のプライベートGitHub Appと企業内Webhookを連携させることで、コードベースのインデックス作成、構文木解析、ブランチ作成、コミット、Pull Request（PR）発行に至る全工程を社内ネットワーク内に完結させ、ソースコードの外部流出をゼロに抑えた自動化パイプラインを構築できます。

本ガイドでは、インフラ要件、GitHub Appの権限設定、Docker Composeによる展開、リバースプロキシの保護、ゼロダウンタイム運用まで、セルフホスト環境の構築手順を徹底解説します。

アーキテクチャの概要：セルフホスト版Sweepの動作原理

社内環境でSweepを安定運用するためには、コンテナ内サービスがGitHubリポジトリおよび大規模言語モデル（LLM）APIとどのように連携するかを把握することが重要です。

[GitHub / GitHub Enterprise]
       |
       |  1. Webhookペイロード（Issue作成・PRレビュー等）
       v
[リバースプロキシ / イングレス (TLS終端 & GitHub IP制限)]
       |
       |  2. HTTPポート8080転送（HMAC-SHA256署名検証）
       v
[Sweepコンテナ (`sweepai/sweep`)]
  ├── Webhook高速応答ハンドラー (FastAPI / Uvicorn)
  ├── 非同期タスクキュー (内蔵Redis + バックグラウンドワーカー)
  ├── コード解析エンジン (Ripgrep記号検索 + GitHub Linguist + AST解析)
  └── ワークスペース永続キャッシュ (`/mnt/caches`)
       |
       |  3. 最小限に絞り込んだプロンプトのみ外部送信
       v
[エンタープライズLLM API (OpenAI / Anthropic / 社内推論ゲートウェイ)]
       |
       |  4. コード差分・実行計画の生成結果
       v
[Sweep Git実行エンジン]
       |
       |  5. GitHub App秘密鍵でトークン発行、ブランチ作成・PR生成
       v
[対象GitHubリポジトリ (新規ブランチとPull Requestが自動生成)]

1. 社内Webhook受信と署名検証: 開発者がリポジトリで Sweep: 接頭辞付きのIssueを作成すると、GitHubはSweepインスタンスのポート8080にJSONペイロードを送信します。Sweepは環境変数 WEBHOOK_SECRET に基づき、HMAC-SHA256でリクエストヘッダーの署名を検証し、不正なリクエストを遮断します。
2. 非同期キューによるタイムアウト回避: GitHubはWebhook受信に対して10秒以内のHTTP応答を要求します。Sweepはリクエストを受け取ると直ちに内蔵Redisキューにタスクを投入し、HTTP 200を即時返却。重い解析処理はバックグラウンドのワーカーが非同期に処理します。
3. ローカルでのコード検索とインデックス化: コンテナ内には高速検索ツール ripgrep、言語判定ライブラリ github-linguist、構文解析器 tree-sitter が組み込まれています。クローンされたコードは一時領域で解析され、検索インデックスや中間状態はホストの /mnt/caches にキャッシュされます。
4. LLMプロンプトの組み立てと機密性維持: Sweepはタスク解決に必要なコードスニペットと指示のみをPromptにまとめ、設定された OPENAI_API_KEY または ANTHROPIC_API_KEY を呼び出します。ゼロデータ保持（Zero Data Retention）契約を締結した企業向けAPIアカウントを利用することで、コードベース全体を第三者の学習や保存に晒すことなく安全に推論を実行できます。
5. Git自動化とGitHub App認証: Sweepは設定されたGitHub App IDとRSA秘密鍵（GITHUB_APP_PEM）から短時間有効なInstallation Access Tokenを動的に生成します。権限を行使して最新ブランチから sweep/... ブランチをチェックアウトし、パッチをコミットしてPRを自動発行します。

サーバー要件と前提条件

Sweepは構文解析、Gitクローン、検索、モデル推論のオーケストレーションを同時に実行するため、以下の計算リソースを確保することを推奨します。

ハードウェアスペックの目安

• OS: Ubuntu 22.04 LTS、Ubuntu 24.04 LTS、またはエンタープライズLinux（RHEL 9 / Rocky Linux）。
• CPU: 最低4 vCPU（高速なRipgrep検索のため8 vCPU以上を推奨）。
• メモリ: 最低32 GB RAM（16 GBでは大規模リポジトリのAST解析時にOOMキルが発生するリスクがあります）。
• ディスク: 200 GB以上のSSDまたはNVMeストレージ（Gitの頻繁なI/Oやキャッシュ保存に高速ディスクが不可欠）。
• クラウドインスタンス例: AWS t3.xlarge、GCP e2-standard-8、または同等の社内仮想マシン。

ソフトウェアおよびネットワーク要件

• Docker Engine（v24.0以上）および Docker Compose（v2.20以上）。
• 送信（Egress）通信: LLMのAPIエンドポイント（api.openai.com や api.anthropic.com）へのTCP 443ポート接続。
• 受信（Ingress）通信: GitHubからのWebhookを受信可能であること。GitHub.com（パブリック）を利用する場合はTLS終端を備えたリバースプロキシ経由、GitHub Enterprise Server（GHES）を社内運用している場合は純粋なイントラネット接続で完結します。

ステップ1：プライベートGitHub Appの作成と設定

Personal Access Token（PAT）の代わりに専用のGitHub Appを使用することで、最小権限の原則（Least Privilege）を徹底し、監査ログの追跡性を確保できます。

1. GitHub Appの新規登録

1. 組織の管理者権限を持つアカウントでGitHubにログインし、組織の Settings > Developer settings > GitHub Apps > New GitHub App に進みます。
2. アプリケーションの基本情報を入力します：
   • GitHub App name: 組織内で識別可能な名前（例: Corp-Internal-Sweep）。
   • Homepage URL: 社内の管理ポータルまたはドキュメントURL。
   • Callback URL: 空欄のままで構いません。

2. Webhookの設定

• Webhook URL: リバースプロキシ経由のエンドポイント（例: https://sweep.internal.yourcorp.com/、検証時は http://<ホストIP>:8080）。
• Webhook secret: ターミナルで openssl rand -hex 32 を実行して強力な乱数文字列を生成し、安全に控えます。

3. リポジトリ権限の設定（Repository permissions）

以下の必要最小限の権限を付与します：

4. Webhookイベントの購読（Subscribe to events）

以下のイベントにチェックを入れます：

• Issues（Issueのオープン、編集、ラベル付け、アサイン）
• Issue comment（Issueコメントの作成）
• Pull request（PRの作成、同期、レビューリクエスト）
• Pull request review comment（コード行に対するレビューコメント）
• Check run（CIチェックの完了）

5. 秘密鍵の生成とアプリのインストール

1. Where can this GitHub App be installed? を Only on this account（この組織内のみ）に設定します。
2. Create GitHub App をクリックして作成を完了します。
3. 表示された設定画面から数値の App ID（例: 123456）をメモします。
4. 下部の Private keys セクションに移動し、Generate a private key をクリックして .pem 秘密鍵ファイルをダウンロードします。
5. 左側メニューの Install App を開き、Sweepを適用したい特定のリポジトリを選択してインストールします。

ステップ2：環境変数ファイル（.env）の構成

サーバー上にデプロイ用ディレクトリを作成し、Sweepのリポジトリを取得して設定ファイルを作成します。

mkdir -p /opt/sweep && cd /opt/sweep
git clone https://github.com/sweepai/sweep.git
cd sweep

ステップ1で取得した認証情報をもとに .env ファイルを作成します：

# GitHub App認証情報
GITHUB_APP_ID=123456
GITHUB_BOT_USER=corp-internal-sweep[bot]
WEBHOOK_SECRET=your_generated_webhook_secret_here

# GitHub App秘密鍵（エスケープされた単一行文字列、または改行を含むブロック）
GITHUB_APP_PEM="-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQEA...\n-----END RSA PRIVATE KEY-----\n"

# Sweepライセンスキー
# 評価用途では14日間の試用ライセンスキーが利用可能。商用環境では公式チームへの問い合わせが必要です
LICENSE_KEY=ABCDE-FGHIJ-KLMNO-PQRST-UVWXY

# 推論モデルのAPIキー（企業向けデータ非保持アカウントを推奨）
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ANTHROPIC_API_KEY=sk-ant-api03-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# コンテナポートおよびワーカー設定
PORT=8080
WORKERS=3

PEM形式に関する注意点: 環境変数に秘密鍵を1行で埋め込む場合は、実際の改行コードをすべて \n に変換してください。自動化スクリプトを使用する場合は、GITHUB_APP_PEM="$(cat /opt/sweep/github-app.pem)" のようにファイルから直接読み込ませることも可能です。

ステップ3：Docker Composeによるコンテナ起動

Sweepリポジトリには、Python 3.10、Redis、ripgrep、言語パーサーを包括したマルチステージ Dockerfile と docker-compose.yml が同梱されています。

主な構成内容は以下の通りです：

services:
  hosted:
    build:
      context: .
      dockerfile: Dockerfile
      target: base
    image: sweepai/sweep:local
    container_name: webhook
    env_file:
      - .env
    volumes:
      - .:/app
      - /mnt/caches:/mnt/caches
    ports:
      - "${PORT:-8080}:8080"
    restart: unless-stopped
    command: >
      sh -c ". bin/startup.sh"

コンテナの起動

ホスト側にキャッシュディレクトリを作成して権限を付与し、サービスを起動します：

sudo mkdir -p /mnt/caches
sudo chown -R 1000:1000 /mnt/caches

# イメージをビルドしてバックグラウンド起動
docker compose up --build -d hosted

コンテナの稼働ステータスとログを確認します：

# コンテナ状態の確認
docker ps -f name=webhook

# リアルタイムログの表示
docker compose logs -f hosted

ログ上に内蔵 redis-server の起動と、Uvicornワーカープロセスが 0.0.0.0:8080 で待機状態に入ったことが確認できれば起動成功です。

ステップ4：リバースプロキシとセキュリティ保護

本番環境において、平文のHTTPポート8080を直接開放することは推奨されません。DMZ領域にNginxリバースプロキシを配置し、TLS暗号化とGitHubのIPアドレスフィルタリングを導入します。

Nginx設定例

upstream sweep_backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name sweep.internal.yourcorp.com;

    ssl_certificate /etc/ssl/certs/sweep.internal.yourcorp.com.crt;
    ssl_certificate_key /etc/ssl/private/sweep.internal.yourcorp.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # GitHub公式のWebhook送信元IPアドレスのみを許可
    # 最新のCIDRは https://api.github.com/meta の "hooks" フィールドから取得可能
    allow 192.30.252.0/22;
    allow 185.199.108.0/22;
    allow 140.82.112.0/20;
    allow 143.55.64.0/20;
    # 社内検証用サブネット
    allow 10.0.0.0/8;
    deny all;

    client_max_body_size 50M;

    location / {
        proxy_pass http://sweep_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        proxy_connect_timeout 10s;
        proxy_read_timeout 120s;
        proxy_send_timeout 120s;
    }
}

補足: 社内専用のGitHub Enterprise Server（GHES）と同一セグメントで連携させる場合、外部公開IPやインターネット向け開放は一切不要です。社内DNSによる解決のみで完全に閉域化された運用が可能です。

ステップ5：エンドツーエンドの動作検証

デプロイ完了後、対象リポジトリで一連の動作テストを実施します：

1. Issueによるタスク指示: GitHub Appがインストールされたリポジトリで、タイトルに Sweep: を付けたIssueを作成します：

   Title: Sweep: utils/auth.py のトークン検証処理に境界値テストを追加
   Body: tests/test_auth.py に期限切れトークンと破損シグネチャを想定したpytestテストケースを追加してください。
   

2. Webhook処理の監視: サーバー側のターミナルでログを追跡します：

   docker compose logs -f hosted
   

   issues.opened イベントの検証成功後、短時間でリポジトリのクローンとコード解析が開始されます。
3. 実行計画コメントの確認: Sweepが該当Issueに対し、変更予定ファイルと修正手順を記載した計画コメントを自動投稿します。
4. Pull Requestの自動生成: 通常2〜5分以内に、Sweepは sweep/token-validation-tests といった専用ブランチを作成してコードをコミットし、詳細な説明付きでPRを自動発行します。
5. コードレビューによる再修正テスト: 生成されたPRのDiff画面で特定のコード行にレビューコメント（例:「Sweep: ここは例外送出ではなく真偽値を返してください」）を投稿すると、Sweepは差分修正を自動で行い、追加コミットをプッシュします。

運用管理：ゼロダウンタイム再起動とディスク保守

Sweepはバックグラウンドで長時間のコード検索やGit操作を行うため、単純に docker compose down を実行すると処理中のタスクが破壊される恐れがあります。

ゼロダウンタイム再起動（Graceful Redeployment）

Sweepリポジトリには安全な再デプロイスクリプトが用意されています：

# 最新コードを取得
git pull origin main

# 安全な再起動を実行
bash bin/redeploy.sh

このスクリプトは実行中のワーカープロセスの完了を待機し、安全にコンテナを切り替えます。

ディスクキャッシュのクリーンアップ

多数のリポジトリを処理すると、/mnt/caches 内に過去の作業ツリーやインデックスが蓄積されます。定期的なCronジョブで不要なデータを削除してください：

# 30日以上更新されていないキャッシュディレクトリを削除
find /mnt/caches -mindepth 1 -maxdepth 2 -type d -mtime +30 -exec rm -rf {} +

# 未使用のDockerビルドイメージを削除
docker image prune -f

比較表：セルフホスト版 vs 公式SaaSクラウド版

実運用のための推奨事項

1. 推論モデルの選定: Sweepのマルチファイル編集能力は、モデルの論理推論能力に強く依存します。Claude 3.5 Sonnet または OpenAI GPT-4o 以上のモデルを強く推奨します。7Bや8Bなどの小型オープンソースモデルを使用した場合、Diffのフォーマット崩れや構文エラーが発生しやすくなります。
2. 保守体制の確保: Sweepプロジェクトは初期にこのGitHub Webhook型エージェントをオープンソース化し、その後商業的にはIDE拡張機能へとフォーカスを広げました。そのため、このバックエンドをセルフホストする組織は、自社の社内PaaSとして自律的に依存関係の更新やチューニングを行う体制を想定してください。
3. 認証情報の定期ローテーション: ISO 27001やSOC 2のベストプラクティスに基づき、GitHub AppのRSA秘密鍵（.pem）および WEBHOOK_SECRET は90日ごとにローテーションを実施してください。

参考文献

• GitHub - sweepai/sweep: Sweep: AI coding assistant for JetBrains
• Self-Hosting Sweep via Docker
• Sweep Docker Compose Configuration
• Sweep Backend Dockerfile
• Registering a GitHub App - GitHub Docs