Claude Scienceを社内ネットワークで使う — プロキシ・TLS検査・社内ミラーの設定

Claude Scienceは各メンバーのPC上で動き、サインイン、Claude API、パッケージ配布元、研究データベースへ外向きに接続します。社内ネットワークではその経路上にプロキシ、TLS検査、ファイアウォールがあり、設定を入れないとサインインの時点で止まります。

設定の入口は3つです。アプリ本体の通信にはプロキシとCAバンドル、解析サンドボックスのパッケージ取得には社内ミラーとCAバンドル、ファイアウォールには許可ドメイン一覧を渡します。以下は、IT管理者がこの順に作業するための手順です。

通信は3種類あり、制御する場所が違う

Claude Scienceの外向き通信は、通る場所で3種類に分かれます。

この分け方を先に頭に入れておくと、エラーの原因がどこにあるかを切り分けやすくなります。たとえば「サインインは通るがパッケージが入らない」なら、疑う先はアプリ本体のプロキシではなくサンドボックス側(ミラーかCAバンドル)です。

どのネットワーク構成が使えるのか

SOCKSとプロキシ経由限定のミラーは、どのOSでも使えません。Claude Codeのプロキシ設定は別の仕組みなので、そちらはClaude Codeのプロキシ設定を見てください。TLS検査の扱いはOSで差が出るので、後の節で分けて説明します。

アウトバウンドプロキシを設定する

プロキシの設定は起動時に1回だけ読まれます。変更したらアプリを再起動します。設定元が複数あるときは、次の順で最初に見つかったものが使われます。

1. アプリのプロセス環境変数のHTTPS_PROXY・HTTP_PROXY・NO_PROXY(小文字も可)
2. config.tomlの[network] proxy
3. Settings > Networkのプロキシ欄
4. macOSとWindowsでは、OSのプロキシ設定(自動検出)

環境変数側では、ALL_PROXYが未設定のほうの変数を補います。空の変数は未設定扱いで、NO_PROXY="*"にすると全通信が直接接続になります。

プロキシのアドレスはhttp://形式で書きます。認証が必要なら、ユーザー名とパスワードをアドレスに埋め込み、特殊文字はパーセントエンコードします(パスワード中の@は%40)。

HTTPS_PROXY=http://username:password@proxy.example.corp:8080
HTTP_PROXY=http://username:password@proxy.example.corp:8080
NO_PROXY=.example.corp

https://のアドレスはアプリ本体の通信にしか効きません。サンドボックスのパッケージ取得はhttp://のプロキシにしかトンネルできないため、https://を指定するとプロキシを飛ばして直接接続します。全通信をプロキシに通したいならhttp://を使います。

迂回先と社内ドメインの扱い

ループバックアドレス(localhost、127.0.0.1とIPv6の同等物)は、NO_PROXYに書かなくても常にプロキシを迂回します。社内ドメインはNO_PROXYに追加します。照合はホスト名の完全一致かドメインの後方一致で、.example.corpとexample.corpは同じ扱いです。10.0.0.0/8のようなCIDR範囲には一致しません。

OSごとの経路

• macOS: アプリは~/.claude-science/env(データフォルダを移していなければ)を起動時に読みます。KEY=VALUEの行に上のプロキシ変数3つを書き、アプリを終了して開き直します。DockやFinderから起動したアプリは、ターミナルでexportした変数を受け取りません。このファイルから適用されるのは固定の変数リストだけで、それ以外の行は警告付きで読み飛ばされます。
• Windows: ユーザー環境変数として設定し、通知領域のアイコンから終了してから開き直します。ウィンドウを閉じただけではアプリが残るためです。そもそもWindowsのプロキシ設定に追従するので、多くのPCでは変数が要らず、配布するならconfig.tomlの[network] proxyが向いています。
• Linux: claude-science serveを起動するシェルかサービスユニットで変数をexportします。envファイルを読むのはmacOSアプリだけです。

認証付きプロキシとPAC環境の落とし穴

macOSとWindowsのシステム設定には認証情報が載りません。そのため、システム設定から検出したプロキシが認証を要求すると、サインインがHTTP 407で失敗します。この場合はconfig.tomlの[network] proxyに認証情報入りのアドレスを書きます。

PACまたはWPADしか配っていないネットワークでは、次のように分かれます。

• macOS: PACのURLを検出してサインインエラーに表示しますが、スクリプトは評価しません。PACが解決するプロキシのアドレスを[network] proxyに直接書きます。
• Windows: アプリウィンドウだけはスクリプトの結果に追従します。ただし、サインインを要求するプロキシ、接続を拒否するプロキシ、数秒以内に応答しないプロキシは採用されず、直接接続になります。
• claude-science serveで起動した場合: PACは評価しません。ここでも[network] proxyが必要です。

NTLMやKerberosしか話さないプロキシには、cntlmやpxのようなローカルリレーが使えます。リレーがユーザーの資格情報で社内プロキシに認証し、ループバックにプレーンなHTTPプロキシを公開する形です。HTTPS_PROXYとHTTP_PROXYをhttp://127.0.0.1:3128のようにリレーへ向けます。

更新コマンドは別プロセスなので事情が違います。claude-science updateはそのシェルにexportしたプロキシ変数を使いますが、macOSのenvファイルは読みません。実行前にターミナルで変数をexportします。アプリ内のバックグラウンド更新はアプリ自身のプロキシ設定に従います。

export HTTPS_PROXY=http://proxy.example.corp:8080
claude-science update

TLS検査はCAバンドルを2種類に分けて渡す

ZscalerやNetskopeのようなTLS検査プロキシは、HTTPS接続を組織独自のルート認証局の証明書で署名し直します。Claude Scienceが内蔵する公開ルートの一覧にはそのルートが無いので、渡さない限りサインインとパッケージ取得が証明書の検証で失敗します。

ルート証明書を渡す設定は2つあり、対象も中身も違います。1つのファイルを両方に流用すると壊れます。

[conda] ca_bundleは信頼リスト全体を置き換えます。自社ルートだけのファイルを指すと、プロキシが検査しないネットワーク(自宅のWi-Fiなど)で、すべてのパッケージ取得が失敗します。[conda]用のバンドルは、OSの公開ルートに自社ルートを足して作ります。

[network]
ca_bundle = "/etc/claude-science/corporate-ca.pem"
 
[conda]
ca_bundle = "/etc/claude-science/complete-bundle.pem"

パスは絶対パスで、アプリのデータフォルダ(~/.claude-science)、一時ディレクトリ、Claudeに書き込みを許したディレクトリの外に置く必要があります。ファイルは存在し、PEMとして読め、秘密鍵を含んではいけません。条件を満たさない値は警告付きで無視され、アプリは止まりません。サインインエラーが残るときは、バンドルが読み込まれていないことを疑います。バンドルは数分ごとに再読込されるため、直したファイルは再起動なしで反映されます。

OS別の違い

• Windows: 2つのキーが未設定なら、PC全体の「信頼されたルート証明機関」ストアのルートを自動で信頼し、約30分ごとに見直します。機器管理でルートを配っているPCでは設定不要です。ストアの読み取りにWindows PowerShellを使うため、PowerShellを制限している環境では[network] ca_bundleと[conda] ca_bundleを明示します。[network] ca_bundleを設定するとストアの代わりにそのファイルが使われます。パスは単一引用符で囲みます。二重引用符内のバックスラッシュはTOMLのエスケープで、パース失敗はアプリの起動失敗になるからです。
• Linux: [conda] ca_bundleが未設定なら、ディストリビューションのシステム証明書バンドル(update-ca-certificatesやupdate-ca-trustで管理されるもの)を使います。自社ルートが入ったイメージなら設定は要りません。
• macOS: 2つのキーをconfig.tomlで設定します。

pipはOSの信頼ストアを見るため、[conda] ca_bundleだけでは足りない場合があります。自社ルートをOS側にも入れます。Linuxはupdate-ca-certificatesかupdate-ca-trust、macOSはMDMでシステムキーチェーンへ、WindowsはPC全体のルート証明機関ストアです。

証明書の設定が届かない範囲

• セッション内でClaudeが実行するコード(セルでのpip install、Rのinstall.packages()など)は、macOSでは環境ビルドと同じ証明書を信頼します。Linuxでは2つのバンドルのどちらも届きません。curlとgitはOSのストアに入れたルートを見ますが、環境のPython・pip・Rは公開ルートしか見ません。Linuxでは、セルで入れるのではなく、環境にパッケージを入れるようClaudeに頼みます。
• ローカルコネクタ(同梱の研究ツール)は、TLS検査環境では動きません。独自のPython環境で動き、そこへ自社ルートを届ける経路が無いためです。Anthropicホスト型のコネクタは、[network] ca_bundleを設定すれば使えます。
• 音声入力のサーバー側音声認識はWebSocketを使い、証明書設定にもプロキシ設定にも従いません。TLS検査や必須プロキシの環境では動かず、ブラウザでは端末側の音声認識に切り替わります。
• SSL_CERT_FILE、CURL_CA_BUNDLE、PIP_CERTのような証明書の環境変数は、パッケージ取得に届きません。分離された環境で動くためで、ca_bundleキーを使います。

パッケージを社内ミラーから取得する

pypi.orgやconda.anaconda.orgが遮断されている環境では、社内のArtifactoryやNexusをミラーに指定します。設定の場所は3つあります。

• 組織全体: Organization settings > Claude Science > Organization package mirror
• 端末の配布: config.tomlの[conda] channel_mirrorとpip_index_url
• 1台だけ: Settings > Network > Package mirror

組織設定はメンバーの個別設定より優先され、メンバー側の値は保持されても使われません。Settings画面でURLを試し、問題なければ配布する流れが手早く進みます。

condaのチャンネルミラーとpipのインデックスは必ず両方を設定します。解析環境はcondaパッケージから作られるため、pipのインデックスだけ設定すると、最初のビルドが公開condaホストへ届かず止まるからです。

ミラーのURLとリポジトリの条件

• URLはhttps://で、IPアドレスでなくDNS名を使い、ポートは443か8443にします。Artifactoryの既定ポート8081なら、443か8443のリスナーまたはリバースプロキシが要ります。URLに認証情報を埋め込むと保存時に拒否されます。
• condaミラーは標準のチャンネル構成(ベースURLの下にチャンネルごと、その下にプラットフォームごと)を返す必要があります。最低限conda-forge(全環境が使う)を置き、RやバイオインフォマティクスのためにBiocondaも置きます。pytorchやnvidiaなど他のチャンネルも同じベースの下で解決されます。
• Anacondaの商用defaultsチャンネルは、ミラー設定中は拒否されます。conda-forgeを使うよう伝えます。
• pipのインデックスは、ArtifactoryやNexusのPyPIリモートなら末尾に/simpleを付けます。

<channel mirror>/
  conda-forge/
    noarch/repodata.json
    linux-64/repodata.json
    osx-arm64/...
    win-64/...
  bioconda/
    noarch/...

単一チャンネル用に作ったリモートリポジトリ(上流がhttps://conda.anaconda.org/conda-forgeなど)をミラーに指定しないでください。インデックスが空で返り、Checkは緑なのに、ビルドがnothing provides <package>で全滅します。condaホストのルートをプロキシするリモート、仮想condaリポジトリ、またはチャンネル名付きのリモートを束ねたconda APIルートを使います。

認証付きミラーの資格情報

認証が要るミラーは、Settings > Network > Package mirror > Mirror credentialsにユーザー名とアクセストークンを1組入力します。ミラーを読み取る権限だけの専用アカウントにします。同じ資格情報がcondaミラーとpipインデックスの両方のホストに送られるため、別アカウントが必要なら片方を匿名にします。送信先はhttps://のミラーだけです。

保存した資格情報は暗号化してローカルのデータベースに入り、同時に平文の~/.claude-science/conda/.netrcにも自動で書かれます。環境ビルド中に動くコード(パッケージのsetup.pyなど)はこのファイルを読めます。サンドボックスが有効(既定)の間、Claudeの解析コードは読めません。ホームディレクトリの.netrcはこの取得には使われません。

既存のプロジェクトフォルダから登録した環境は、セッション中にサンドボックス内でパッケージを入れます。そこでは資格情報が隠されるため、匿名で読めるミラーが必要です。

資格情報を一元管理するなら、.netrcをファイルとして配布します。

machine yourorg.jfrog.io
login mirror-reader
password EXAMPLE-TOKEN

ミラーのホストごとに1ブロックずつ書きます。macOSとLinuxでは、メンバーをファイルと2つのフォルダの所有者にして、ファイルの権限を600にします。Windowsでは、管理者権限やシステムアカウントで動く配布ツールにメンバーのフルパス(C:\Users\ada\...)を渡します。

配布前に、各メンバーがMirror credentialsを空にしておくことが大事です。保存済みの資格情報はファイルを上書きすることがあるので、Removeボタンが出ている場合は押してもらいます。ファイルはClaude Scienceのインストールや更新より先に配ります。ロールアウト前に、Claude Scienceを一度も起動していない1台で、標準アカウントのメンバーとして検証します。ミラーのリクエストログに、PythonインデックスとcondaチャンネルのそれぞれでこのログインIDが出れば成功です。トークンを更新するときはファイルを再配布し、Linuxではメンバーにアプリを終了・再起動してもらいます。

ミラー通信はプロキシを通らない

ここが社内ネットワークで最もつまずきやすい点です。環境ビルドは、ミラーのホストへ直接接続します。アウトバウンドプロキシは経由しません。ワークステーションにミラーへの直接の経路(VPNや社内ネットワーク)が必要で、ワークステーションのファイアウォールもミラーを直接の宛先として許可します。プロキシの許可リストにミラーを載せても届かず、ビルド中のミラー通信はプロキシのログにも出ません。プロキシ専用のネットワークでは、yourorg.jfrog.ioのようなSaaS型リポジトリは直接届かないため、ミラーを社内に立てます。

プロキシ設定済みのPCでは、Checkボタンと実際のビルドが別の経路を通ることがあります。ミラーの動作確認は、テスト用の環境ビルドを最終判断にします。

ミラーを設定すると、サンドボックスの許可リストから代替される公開ホストが外れ、ミラーのホストが加わります。condaミラーはconda.anaconda.org・repo.anaconda.com・anaconda.org・*.anaconda.orgを、pipミラーはpypi.org・*.pypi.org・files.pythonhosted.orgを外します。公開ホストを併用したい場合は、Settings > Networkで個別に再追加します。この画面はワイルドカードを受け付けないので、サブドメインも許すならconfig.tomlの[sandbox.network] allowed_domainsに*.pypi.orgや*.anaconda.orgを書きます。組織が許可リストを管理している場合、メンバーは再追加できません。

ミラーがパッケージのファイルをS3のパススタイルURL(s3.us-west-2.amazonaws.com/<bucket>/...)へリダイレクトすると、CONNECT tunnel failed, response 403になります。パススタイルのオブジェクトストレージは、上書きできない内蔵の遮断リストに入っています。ミラー自身にファイルを配信させるか、<bucket>.s3.us-west-2.amazonaws.comのようなバケット名付きホスト名にリダイレクトして、そのホストをAllowed domainsに追加します。

設定をまとめて配布する例

実際の配布では、config.tomlに全部を載せてMDMなどで配ります。Claude Scienceは、MDMのネイティブな管理チャンネル(管理プロファイルやレジストリのポリシーキー)で設定を読まず、メンバーごとのconfig.tomlを配る方式が公式の想定です。次は公式ドキュメントの値を組み合わせた記述例です。ホスト名は自社のものに置き換えます。

[network]
proxy = "http://proxy.example.corp:8080"
no_proxy = ".example.corp"
ca_bundle = "/etc/claude-science/corporate-ca.pem"
 
[conda]
channel_mirror = "https://yourorg.jfrog.io/artifactory/api/conda/conda-all"
pip_index_url = "https://yourorg.jfrog.io/artifactory/api/pypi/pypi-remote/simple"
ca_bundle = "/etc/claude-science/complete-bundle.pem"

配布前にミラーのURLが規則(https://、DNS名、443か8443、認証情報なし)を満たすか確認してください。不正な値を含むconfig.tomlを配ると、アプリが起動しなくなります。バンドルのファイルはconfig.tomlと一緒に配ります。

ファイアウォール担当に渡す許可ドメイン

プロキシやファイアウォールの許可リストは、通信の種類ごとに依頼します。通信はアウトバウンドのみで、ほぼすべてTCP 443のHTTPSです(社内ミラーは8443も可)。

アプリ本体が必ず使うドメインは次のとおりです。

文献検索では、アプリ自身がapi.unpaywall.org、doi.org、eutils.ncbi.nlm.nih.gov、www.ncbi.nlm.nih.gov、api.semanticscholar.org、api.crossref.orgなどに接続します。これらはサンドボックスの許可リストにもありますが、アプリ自身の通信としてもプロキシの許可が要ります。オープンアクセスの全文はそれぞれの公開元から取得されるため、許可リスト方式のネットワークでは、一部の全文取得が失敗します。

テナント制限のようにネットワーク側から利用アカウントを絞る場合は、claude.aiなどアプリ本体のドメインに触れるため、Claudeのテナント制限の運用と照らして許可を決めます。

サンドボックス側の遮断リストにも注意が必要です。匿名のファイル共有サービス、アカウント不要でデータを受け取るチャットやWebhook、リバーストンネル、パススタイルのクラウドストレージ宛は常に遮断され、メンバーも設定も外せません。この遮断はサンドボックス内だけに効き、アプリ自身の更新確認(storage.googleapis.com)には影響しません。

サンドボックスの研究データベースとオプションの計算統合

解析サンドボックスは、コード実行中の通信を内蔵の許可リストに載ったドメインだけに通します。研究データベースのグループは既定で有効で、メンバーはオンボーディングかSettings > Networkで切り替えられます。組織が許可リストを管理している場合は、組織側のドメインごとのスイッチが優先されます。パッケージ配布元は先に述べたとおりなので、ここでは研究データベースと計算統合を挙げます。

計算統合のドメインは、メンバーが該当の統合を有効にしたときだけ必要です。使わない組織は依頼に含めなくて構いません。

ブラウザが読み込むドメインは、プロキシではなく端末のWebフィルタの管轄です。claude.aiのサインインページに加えて、サインインの代替ページconsole.anthropic.comがあります。インタラクティブプレビュー用にcdn.jsdelivr.net、esm.sh、unpkg.com、cdnjs.cloudflare.com、分子構造ビューアの3dmol.orgなどが要ります。遮断されると、サインイン画面が開かない、プレビューが空白になるといった症状になります。

エラー別の切り分け

Checkが401になる件には補足があります。ファイル配布の運用で、保存された資格情報が無い場合のチェックは、Windowsだけが配布済みの.netrcの該当ホストの項目を送ります。この結果とビルドの結果が食い違うのは、仕様どおりです。なお、このCheckボタンが出るのは、Settingsで入力したミラーアドレスの隣だけで、組織や配布済みのconfig.tomlが設定したミラーの隣には出ません。

ファイル配布した資格情報が効かないときは、次の3つの場合を確認します。

1. ビルドが401か403で失敗: ファイル名、内容、権限、トークンを確認。Windowsでは、開けないファイルや対応しないキーワード・文字を含むファイルは使われず、claude-science logsが理由を示します。
2. ミラーのリクエストログに何も出ない: ネットワークが公開パッケージホストも許していると、組織のミラーアドレスが届く前に公開ホストでセットアップが進むことがあります。config.tomlでミラーを設定した状態で、Claude Scienceを起動したことがない別のPCに、インストール前に配布して再テストします。
3. 資格情報が保存されたままファイルが届いた: メンバーにRemoveを押してもらい、ファイルを再配布します。Windowsではアプリを終了して開き直してもらいます。

計画段階で決めておく3つの分かれ目

Claude Scienceの設定は、設定する場所が3層あります。組織全体(Organization settings)、配布するconfig.toml、メンバーが触るSettingsです。proxyとミラーのキーはconfig.tomlの値がSettings画面より優先され、画面は組織の管理下として表示されます。Team・Enterpriseでは、Organization settingsの組織ミラーがさらに上に立ちます。一方で[sandbox.network]の許可リストは足し算で、Settingsの設定を固定しません。

運用の分かれ目は3つあります。

• ミラーを社内の直接到達できる場所に置けるか。置けないなら、公開パッケージホストをプロキシ経由で許可する構成を検討することになります。ただしミラー設定時は公開ホストが外れるため、再追加が必要です。
• TLS検査の対象にサンドボックスの通信を含めるか。含めるなら[conda] ca_bundleの完全なバンドルを整備します。
• Linuxでの運用。セッション内のコードが自社ルートを見ないため、パッケージの導入は環境のビルドに寄せる運用が前提になります。

Claude ScienceがHPCクラスタに繋がる経路はClaude ScienceのHPC接続にあり、プランごとの機能差はClaude Scienceの対応プランと料金で確認できます。Claude Science自体の概要はClaude Scienceのベータ提供開始にあります。