ソースコードを自社管理下に置きながらAIコーディングを使う場合、まず決めたいのは「どの処理をどこで動かし、どの情報を送信できるか」です。エージェントの実行基盤をセルフホストすることと、モデルの推論まで社内に閉じることは、分けて設計する必要があります。
2026年9月17日訂正：旧版にあった、Claude Code等をそのまま内包するかのような説明と、セルフホストだけでコード持出がなくなるという説明を修正しました。監査対応の保証、根拠のない構築期間・費用の比較も削除しました。
以下は、同日に確認したCoderの現行公式資料（v2.37）に基づく構成の整理です。この前編では、公式仕様と導入時の確認項目を扱います。MacでCoderとローカルLLMを起動した結果は、続編の実機検証記事にまとめました。 コード修正・テスト・モデル停止時の挙動を実画面で紹介しています。全通信の計測や監査要件の検証は、続編でも未実施です。
Coder Agentsでは何がどこで動くのか
公式の概要によると、Coder AgentsはCoderの制御基盤内でエージェントの処理を実行する独自の仕組みです。Claude CodeやCodexを包んで動かすラッパーではありません。IDEや別のコーディングツールをWorkspaceで利用する構成とは、役割を分けて考えます。
構成を理解するときは、次の3か所を追います。
| 場所 | 主な役割 | 導入時に確認すること |
|---|---|---|
| Coderの制御基盤 | 会話の処理、モデルへの要求、ツール実行の依頼 | 接続先、認証情報、保存データ、管理者の権限 |
| Workspace | ファイルの読み書き、コマンド実行、ビルド等 | 読めるリポジトリ、実行権限、ネットワーク制限 |
| LLMの推論先 | 要求を受けてモデルの応答を返す | 運用主体、送信可能な情報、保存・利用条件 |
アーキテクチャの公式説明では、制御基盤が設定されたLLMへ会話を送り、必要に応じてWorkspaceで処理を実行し、その結果をモデルに返す流れになっています。WorkspaceからLLMへ直接接続しなくても、制御基盤から推論先への通信を確認する必要があります。
図は公式仕様に基づく概念図です。GH Mediaが稼働させた環境の測定図ではありません。見るべき点は、Workspaceの置き場所だけでは、モデルへ送る情報の行き先が決まらないことです。
「コードを外に出さない」を確認可能な要件にする
「社外に出さない」という要件を、そのまま製品名に置き換えると確認が曖昧になります。少なくとも、コード本文、プロンプト、コマンド出力、エラー、ログ等のうち、何をどこへ送ってよいかを決める必要があります。ツールが読み取った内容がモデルへの入力に含まれる場合も、同じルールで扱います。
考え方としては、次のように分けられます。
- 外部LLMへの送信を認める構成：送信する情報の範囲、契約上の利用条件、保存やアクセスの扱いを確認する。
- 社内の推論先を使う構成：対象モデル・APIの互換性を確認し、制御基盤やWorkspaceからの他の外向き通信も調べる。
- プロキシやゲートウェイを経由する構成：中継点だけでなく、最終的な推論先と、そこで扱われるデータまで追う。
これは要件を整理するための分類です。本記事で各構成の動作や閉域性を実証したものではありません。クラウド上の専用環境が自社要件を満たすかどうかも、所在国だけでなく接続・運用・契約の条件を含めて判断します。
モデル設定の公式資料では、プロバイダーや互換エンドポイントを設定できます。ただし、URLを保存できることだけでは、その接続先がCoderの使用するAPIやツール呼び出しに対応しているとは確認できません。実際の要求と応答を使った検証が必要です。
受託案件での実装コンポーネント
製品を組み合わせる前に、誰が何を確認するかを決めます。以下は構成検討時のチェック項目であり、動作確認済みの製品セットではありません。
| 検討する部分 | 確認する内容 |
|---|---|
| 制御基盤とWorkspace | 配置先、更新方法、バックアップ、接続経路 |
| モデル接続 | 認証、APIの互換性、送信先、利用できるモデル |
| IDと実行権限 | 誰の権限でリポジトリを読み、ファイルを変更し、処理を実行するか |
| ネットワーク | 制御基盤とWorkspaceそれぞれの許可先。パッケージ取得や外部ツールも含む |
| ログと会話データ | 必要な記録が取得できるか、閲覧権限、保管期間、削除・復元の方法 |
会話が保存されることと、組織が求める監査証跡を満たすことも分けます。「操作した人」「変更対象」「実行時刻」「モデルへの送信内容」のうち、どれが必要かを決め、取得できる範囲を実物で確認してください。保存期間や費用を、製品名だけから一律に決めることはできません。
小さく試すなら、最初に何を確かめるか
導入ガイドには、LLMプロバイダーとモデルの設定、管理権限、Workspaceのテンプレートなどの前提が示されています。準備が整ったら、機密を含まないテスト用リポジトリで確認する計画を立てます。
最初の課題は「小さな関数を修正し、そのテストを実行する」といった、結果を人が確認できるものが適しています。検証では以下を記録します。
- 環境と設定：Coderの版、モデル識別子、接続先、使ったテンプレート、入力した課題。
- 実際の結果：変更されたファイル、実行コマンド、テストの結果、途中で失敗した操作。
- データの行き先：制御基盤とWorkspaceの接続先、モデルへ送った内容を確認できる範囲。
- 権限の境界：許可していないリポジトリや操作へ進めないか。想定した制限が実際に効くか。
- 運用の確認：停止方法、エラー時の追跡、ログの閲覧、更新後に再確認する項目。
ここまでを確認して初めて、その条件で何ができたかを説明できます。 一度テストが成功しても、組織全体の安全性や生産性、すべてのモデルとの互換性まで証明したことにはなりません。
導入判断の前に揃えたい情報
検討の出発点は、対象業務、扱うデータ、許可できる推論先、必要な権限、残すべき記録です。その条件に沿って、既存環境を使うか、Coderを組み込むか、別の構成を検討するかを判断します。構築期間や費用は、対象人数・既存基盤・運用要件が揃ってから見積もります。
「自社のコードやデータをどこまで送信できるか整理したい」「導入候補を比較するための検証項目を決めたい」という段階では、現在の構成と制約を添えてお問い合わせフォームからご相談ください。
