金融、ヘルスケア、基幹システム開発など、厳格なセキュリティ要件が課されるソフトウェア開発組織において、コードベース特化型AIの導入は大きなトレードオフを伴います。Mutable.aiが提供する自動Wiki生成機能（Auto Wiki）、アーキテクチャ図の自動描画、行単位の根拠引用を伴う対話型検索は開発効率を飛躍的に高めますが、専有ソースコードをマルチテナント型のパブリックSaaSへ送信することは、重大なコンプライアンス違反リスクを引き起こします。
この課題を解決する現実解が、企業が制御するプライベートなAWS VPC（Virtual Private Cloud）内へのMutable.aiの隔離展開です。コード解析やベクトル検索をプライベートサブネット内に閉じ込め、AWS PrivateLink経由で基盤モデル推論を呼び出し、社内Gitリポジトリと閉域網接続することで、ソースコードを外部の共有モデル学習に一切利用させることなく、安全にコードベースインテリジェンスを活用できます。
1. 企業の脅威モデルとプライベート構成の目的
一般的なマルチテナントSaaS環境では、コードベースの処理において以下のような3大リスクが生じます。
- 共有モデルへの学習データ混入： 独自アルゴリズムや暗号ロジックがパブリックモデルの再学習データセットに混入するリスク。
- 公衆網経由のデータ漏洩： ソースコードの平文やAST（抽象構文木）がインターネットを経由することで発生する盗聴や構成ミスによる露出。
- 過度なリポジトリ認証情報の外部預託： 外部SaaSに対して全リポジトリの読み取り権限を付与することに伴うサプライチェーン攻撃リスク。
Mutable.aiのエンタープライズ機能は、シングルテナント構成での分離をサポートしています。組織専用のAWS VPC環境にデプロイすることで、AST解析、ドキュメント生成、ベクトル埋め込み、Auto Wikiのレンダリングに至る全パイプラインが自社境界内に保持されます。さらに技術的・契約的保証により、顧客コードが外部基盤モデルの学習にプールされることはありません。
2. 推奨されるVPCネットワークトポロジ
安全なAWS VPC構成では、データプレーン（コード解析および検索処理）をパブリックインターネットから完全に遮断します。
+----------------------------------------------------------------------------------+
| 企業専用 AWS VPC（閉域ネットワーク境界） |
| |
| [ プライベートサブネット A / B（コンピュート・検索層） ] |
| - Mutable.ai 構文解析・Auto Wiki 生成ワーカー（ECS / EKS コンテナ群） |
| - コードベース検索・チャットエンジン |
| - ベクトルおよびメタデータストア（AWS KMS 顧客管理キーで暗号化） |
| | |
| |-- (内部 HTTPS / ENI 通信) |
| v |
| [ インターフェイス型 VPC エンドポイント（AWS PrivateLink） ] |
| +-- com.amazonaws.<region>.bedrock-runtime --> 専用モデル推論サービス |
| +-- com.amazonaws.<region>.s3 --> Wiki 静的成果物・スナップショット |
| +-- com.amazonaws.<region>.secretsmanager --> Git アクセストークン・認証情報 |
| +-- com.amazonaws.<region>.kms --> エンベロープ暗号化・復号権限 |
| |
+----------------------------------------------------------------------------------+
^ ^
| (VPC ピアリング / Transit Gateway) | (PrivateLink / SSO 連携)
v v
+-------------------------------+ +--------------------------+
| 社内 Git リポジトリ | | 統合IDプロバイダ (IdP) |
| (GitHub Enterprise / GitLab) | | Okta / SAML / OIDC |
+-------------------------------+ +--------------------------+
アーキテクチャの必須要件
- パブリックIPv4およびインターネットゲートウェイの排除： ワーカーサブネットのルートテーブルには、インターネットゲートウェイ（IGW）やNATゲートウェイへ向かう
0.0.0.0/0のデフォルトルートを設定しません。 - AWS PrivateLinkによる閉域推論： ドキュメント生成や質問応答のためのLLM呼び出しは、AWSバックボーン内を通過するVPCエンドポイント（Amazon Bedrock Runtimeなど）を経由します。
- セキュアな社内連携： 社内Gitサーバーや社内IdPとの通信は、AWS Transit GatewayやVPCピアリングを経由し、特定のポート（HTTPS 443等）のみに制限します。
3. ステップ別セットアップ手順
ステップ1：隔離サブネットとセキュリティグループの設計
高可用性を確保するため、少なくとも2つのアベイラビリティゾーン（AZ）にまたがるプライベートサブネットを作成します。ルートテーブルにはVPCローカル宛先およびゲートウェイ宛先のみを設定します。
Mutable.aiコンテナクラスターに割り当てるセキュリティグループを厳格に定義します。
- インバウンドルール： 社内開発者ネットワークまたはTransit Gateway経由のCIDRブロックからのTCP 443ポートのみを許可します。
- アウトバウンドルール：
0.0.0.0/0宛ての全トラフィックを削除し、VPCエンドポイント用セキュリティグループ宛てのTCP 443ポートのみを許可します。
ステップ2：AWS PrivateLinkエンドポイントの作成
プライベートサブネット内に以下のインターフェイス型VPCエンドポイントを作成し、外部インターネットに出ることなくAWSサービスを利用可能にします。
- 推論エンドポイント：
com.amazonaws.<region>.bedrock-runtime（Amazon Bedrock上で稼働するClaudeやLlamaなどの認可済みモデルを呼び出し）。 - シークレット管理：
com.amazonaws.<region>.secretsmanager（Git連携トークンを安全に取得）。 - ストレージ連携：
com.amazonaws.<region>.s3（GatewayまたはInterfaceエンドポイント。生成されたMarkdown、ASTキャッシュ、構成図の永続化）。 - 暗号化鍵管理：
com.amazonaws.<region>.kms（データベースやS3オブジェクトの復号）。
各インターフェイスエンドポイントで「プライベートDNS（Private DNS）」を有効化し、SDKの標準エンドポイント名が自動的にサブネット内のENIプライベートIPに解決されるようにします。
ステップ3：エンドポイントポリシーによるアクセス制限
VPCエンドポイントにリソースポリシーを適用し、組織が承認したモデル以外へのアクセスを遮断します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificModelsForMutableAI",
"Effect": "Allow",
"Principal": "*",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet*"
}
]
}
ステップ4：社内Gitリポジトリ連携とWebhook自動化
Mutable.aiの強みは、コード変更に追従したAuto Wikiの自動更新です。オンプレミスまたはAWS内で稼働するGitHub Enterprise Server / 自社GitLabと接続します。
- AWS Transit Gatewayを通じて、Mutable.aiのVPCとGitホスティング環境をルーティング接続します。
- AWS Secrets Managerに最小権限のGit Appトークンを登録し、対象リポジトリのみに対する読み取り権限を付与します。
- 内部Application Load Balancer（ALB）でPR Webhookを受信し、Pull Requestが作成・更新された際に自動で差分を検知してドキュメント更新や変更要約を実行します。
ステップ5：保存時および転送時の暗号化
- 保存時（At-Rest）： AWS KMSの顧客管理キー（CMK）を使用し、ベクトルストア、キャッシュ、S3バケットを全暗号化します。キーは年次で自動ローテーションさせます。
- 転送時（In-Transit）： クラスター内部の全マイクロサービス間通信およびエンドポイント通信でTLS 1.3を強制します。
4. 運用検証とセキュリティ監査基準
本番運用開始時、セキュリティ監査担当者は以下の基準で閉域性の検証を実施します。
| 監査項目 | 検証手段とツール | 合格判定基準 |
|---|---|---|
| インターネット外部送信遮断 | CloudWatchでVPCフローログ（VPC Flow Logs）を解析 | パブリックIP宛て、あるいは認可外宛先への正常通信パケットが皆無（0パケット）。 |
| モデル学習不使用の確認 | Amazon Bedrockおよびベンダー契約条項の確認 | プロンプトおよび生成結果が基盤モデルの再学習データとして一切保持されないこと。 |
| リポジトリ権限の継承 | SAML 2.0 / OIDC（Okta等）による権限マッピング | 元のリポジトリ閲覧権限を持つ開発者のみが対応するAuto Wikiを閲覧可能であること。 |
| 鍵アクセス監査 | AWS CloudTrailのKMS Decryptログ | 復号リクエストの発行元がMutable.aiのIAMタスク実行ロールのみに限定されていること。 |
5. 設計上のトレードオフと実践的推奨事項
| 展開形態 | 主なメリット | 運用の考慮事項 | 推奨シナリオ |
|---|---|---|---|
| 完全自社VPC運用（セルフホスト構成） | データ完全主権；外部SaaSとの通信ゼロ | パッチ適用、コンテナ管理、障害対応を自社で負担 | 防衛、メガバンク、規制の厳しいヘルスケア基幹 |
| ベンダー管理型シングルテナントVPC（PrivateLink接続） | インフラ保守負担の極小化；新機能の自動追従 | クロスアカウント接続構成と監査契約の締結が必要 | 急成長中のフィンテック、エンタープライズSaaS開発 |
エンジニアリングリードへの実践的アドバイス
- コア共通ライブラリから段階的に展開する： 最初から全リポジトリを一括対象にするのではなく、社内で広く使われる共通モジュール2〜3件でAuto Wikiの生成精度とトークン消費量を検証します。
- CIパイプラインでシークレットを事前検知・除外する： ソースコードのコメントや設定ファイルに紛れ込んだAPIキーがAuto Wikiへ反映されないよう、インデックス前の静的解析ガードレールを導入します。
- 巨大モノレポでの増量更新を徹底する： 数十万行規模のリポジトリでコミットごとに全コードを再走査するとPrivateLinkの帯域と推論コストが増加します。Gitコミット差分に基づく増分インデックス構成を標準とします。