Skip to Content
Docs08. コーディングエージェント企業システム環境の制約と対応(閉域網・監査・持ち込み承認)
中級se-practiceenterprise-constraintsair-gapped更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

企業システム環境の制約と対応(閉域網・監査・持ち込み承認)

この記事の目的

顧客資産を扱う企業システム開発で、AI コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。を導入する際の環境・商流の制約を整理し、「顧客のコード・データをどのツール経路で扱ってよいか」を判断できるようになります。制約の類型・提供形態の選択肢マップ・判断フレーム(契約 → 分類 → 経路)・承認を取るための説明資料の型を持ち帰れる状態を目指します。技術的な防御(権限・サンドボックスモデルが生成したコードの実行やコンピュータ操作を、本番システムから隔離された使い捨て環境(ネットワーク・資源制限付き)で行う仕組み。)は 権限・秘密情報・破壊的操作への対策 が、規制の地図は 業界別規制マップ が正本で、本記事は**その手前の「そもそも渡してよいか・どの形態で使うか」**に絞ります。

最終確認日: 2026-07。 本記事のうち個別ツールの提供形態(閉域網・自社ホスト・ZDR・データ残留対応地域)は変化が非常に速いため、代表例は「2026-07 時点」の一般類型として読み、採用時は各社公式ページと調査メモ research/se/enterprise-offerings.md で必ず再確認してください(後述の「変わりやすい項目(定点観測)」)。

対象読者

  • 顧客データ・ソースコードを扱う受託開発で、AI コーディングエージェントの持ち込み可否を判断する SE・アーキテクト
  • 閉域網・オンプレ・監査要件のある環境で、AI 活用の提供形態を選定するテックリード・情報システム担当

前提知識

本文

概要: 制約 → 形態 → 判断の順で考える

企業システム環境での AI 活用は、「使えるか」を制約から考えます。本記事は (1) 制約の類型を押さえ、(2) 提供形態の選択肢を知り、(3) 渡してよいかの判断フレームを回す、という順で構成します。技術防御は 権限・秘密情報・破壊的操作への対策、規制の入口は 業界別規制マップ に委ね、ここは可否と形態の判断に集中します。

制約の類型

企業システム開発で AI 活用を縛る制約は、おおむね次の 5 つに整理できます。

制約内容効いてくる場面
顧客データ・秘密保持契約顧客データ・ソースコードの外部送信・保存の禁止/制限どのツール経路で何を渡してよいかの可否
持ち込みツールの承認未承認ツールの利用禁止・承認プロセスそもそも使い始められるか
閉域網・オンプレ環境インターネット非接続・外部 API 到達不可クラウド型が原理的に使えない
監査証跡・ログ保全誰が何をしたかの記録・保全の義務監査ログ・統制のあるツールが要る
多重請負での責任分界どの会社の誰が承認・責任を持つか承認の抜け・責任の所在

要点は、これらが技術以前の制約だということです。ツールの機能がいくら優れていても、契約・承認・ネットワークで許されなければ使えません。まずこの 5 つを自分の案件で棚卸しします。

提供形態の選択肢マップ

制約に対して、AI コーディングエージェントの提供形態は大きく 3 類型に分かれます(2026-07 時点の一般類型)。閉域網への適性がそれぞれ違います。

類型何を顧客側に寄せるか閉域網適性代表例(2026-07 時点・要再確認)
①SaaS + 契約ベンダー管理のクラウドを、契約(データ保護・学習オフ・ZDR)と設定で保護低(閉域網は不可。回線と契約に依存)主要な商用エージェントの Business/Enterprise プラン
②クラウド経由顧客のクラウドテナント・リージョン境界内に寄せ、プロキシ/ゲートウェイで統制中(顧客クラウド内に限定。完全 air-gapped ではない)顧客クラウドのマネージド基盤(VPC/VPC-SC・リージョン固定)+ 企業プロキシ経由
③自社ホストソフトも推論も顧客環境内。外部送信ゼロが可能高(OSS + ローカルモデルは完全 air-gapped 可)OSS エージェント + ローカル/専有モデル(自社ホスト推論)

実行 runner / VM の自社ホストと、推論・モデル通信の自社ホストは別です。自社 runner でも推論が SaaS なら①、顧客クラウドの推論なら②で、③とは扱いません。認証・索引・テレメトリ・更新取得も含めてデータフローを確認します。

判断の勘所は、**「どこまで顧客環境内に寄せる必要があるか」**です。契約と設定で足りるなら①、リージョン・テナント境界が要るなら②、外部送信が一切許されない(閉域網)なら③、と制約に応じて選びます。

閉域網という最難関

制約の中で最も厳しいのが閉域網(air-gapped network) — インターネットから物理的・論理的に隔離され、外部 API に到達できないネットワークです。

  • クラウド型は原理的に使えない: 閉域網では、外部の推論 API に到達できないため、SaaS 型(①)・クラウド経由(②)のいずれも成立しません。「ZDR だから安全」という話以前に、通信そのものが通らない
  • 真の air-gapped は自社ホスト + ローカルモデルのみ: 外部送信ゼロを確実に満たせるのは、OSS エージェントをローカル/自社ホストのモデル(自社環境内で動く推論基盤)と組み合わせる類型③だけです。この構成なら外部ベンダーへの送信・残留・学習利用を避けられますが、自社内の保存・ログ・学習利用・アクセス権の管理は必要です
  • 統制は自作が要る: 類型③の OSS 構成には、SSO・監査ログ・ポリシー強制といった企業統制が標準では備わりません。監査要件がある場合、統制はネットワーク分離・プロキシ・ログ基盤・端末管理で運用側が担保するか、統制を備えた商用の自社ホスト版を検討します
  • 商用で閉域に寄せる選択肢は限られ、変化が速い: 一部の商用エージェントは VPC・シングルテナント・政府向け認証などで閉域に寄せられますが、対応状況は流動的です(自社ホスト提供を新規停止した例もあります)。個別の可否は必ず最新の公式情報で確認します(下記 TODO)

渡してよいかの判断フレーム(契約 → 分類 → 経路)

「この顧客のコード・データを、このツールに渡してよいか」は、次の 3 段で判断します。

  1. 契約(渡してよいか): まず顧客との契約・秘密保持契約・規程を見ます。外部送信・保存が許されるか、AI 利用に関する取り決めがあるか。ここで NG なら、技術がどうであれ渡せません(顧客・プロジェクトへの導入合意形成で合意を取る)
  2. 分類(何を渡すか): 渡す対象を機微度で分類します。公開可能な自社コード / 顧客のソースコード / 個人情報・業務データ、では扱いが変わります。判断に不要な機微情報はマスキング・抽象化します
  3. 経路(どの形態で渡すか): 分類に見合った提供形態(①②③)を選びます。機微度が高い・閉域網なら③へ、契約と設定で足りるなら①②へ。経路が契約の要求(残留・学習・リージョン)を満たすかを確認します

この順序が肝です。経路(ツール選定)から入らないことが要点です。契約で不可なものは、どんな高機能ツールでも使えません。

承認を取るための説明資料の型

持ち込みツールの承認を得るには、判断者が可否を判断できる材料を出します。技術的な詳細より、次の 3 点を明確にするのが効きます。

  • データフロー: 何が・どこへ・どの経路で流れるか(顧客環境 → ツール → モデル、の図)。「顧客のコードがどこまで出るか」を一目で示します
  • データ残留: 送ったデータがどこに・どれだけ保存されるか(保持期間・ZDR の有無・保存リージョン)。「送った後に残るか」を示します
  • 学習利用: 送ったデータがモデルの学習に使われるか(既定・オプトアウト条件)。「自社/顧客の資産が他に流用されないか」を示します

この 3 点(フロー・残留・学習)を、使う提供形態について具体的に埋めた資料が、承認・監査の共通言語になります。個別ツールの現況は公式ドキュメントと調査メモ research/se/enterprise-offerings.md を基に埋めます。

変わりやすい項目(定点観測)

本記事のうち、次の項目は変化が速く、四半期ごと(および本記事の改訂時)の再確認が必要です。

調査メモ research/se/enterprise-offerings.md(2026-07-08 時点)に、この定点観測の詳細な対象と出典を記録しています。

実務での注意点

アンチパターン

  • ツール選定(経路)から入る → 契約で不可なのに高機能ツールを検討して手戻りする → 契約 → 分類 → 経路の順で判断する
  • 閉域網で「ZDR だから安全」と考える → そもそも外部 API に通信が通らず成立しない → 閉域網は自社ホスト + ローカルモデル(類型③)で外部送信ゼロにする
  • 提供形態の対応状況を古い情報で断定する → 自社ホスト提供の停止・ZDR 条件の変更を見落とす → 採用時に公式と調査メモで最新を確認する
  • 現場担当の口頭 OK でツールを持ち込む → 顧客情報システム部門・自社の承認漏れが後で発覚する → 持ち込みツールの承認プロセスを通す
  • 承認資料に技術詳細だけ並べる → 判断者が可否を判断できない → データフロー・残留・学習の 3 点で示す

チェックリスト

  • 案件の制約(顧客データ・持ち込み承認・閉域網・監査・責任分界)を棚卸しした
  • 契約 → 分類 → 経路の順で、渡してよいかを判断している(経路から入っていない)
  • 渡す対象を機微度で分類し、不要な機微情報をマスキング・抽象化した
  • 選んだ提供形態(①SaaS+契約 / ②クラウド経由 / ③自社ホスト)が制約に合っている
  • 閉域網要件がある場合、自社ホスト + ローカルモデルで外部送信ゼロを満たしている
  • 承認資料をデータフロー・残留・学習利用の 3 点で用意した
  • 個別ツールの提供形態を最新の公式情報・調査メモで確認した

関連トピック

参考資料

TODO・未確認事項

保守・運用フェーズでの活用顧客・プロジェクトへの導入合意形成