Claude Codeはターミナルで動作しますが、実行環境の依存関係、ディレクトリ権限、認証情報の保管、企業プロキシにも準備が必要です。本記事では、ローカルで用意すべき項目と、チームで設定を共有する方法を実務の順序に沿って説明します。
Claude Codeはターミナルで使うツールで、インストール後は1つのコマンドですぐに使い始められます。そのため、ネットワークだけに注意が向きがちです。実際に詰まりやすいのは別の点で、ランタイムのバージョンが正しいか、プロジェクトディレクトリに書き込み権限があるか、鍵をどこに置くか、社内プロキシをどう通すか、そしてチームで同じ設定をどう共有するかです。
まず実行環境と依存関係をそろえる
最初に公式ドキュメントで現在要求されているランタイムのバージョンを確認し、指定どおりにインストールします。公開されて数日しかたっていないバージョンを試しに使うのは避けます。パッケージマネージャーもチームに合わせてください。npm、pnpm、yarnを混在させると、ロックファイル同士が競合しやすくなります。gitと基本的なコマンドラインツールも必須です。この種のツールはリポジトリを読み、コマンドを実行し、テストを走らせるため、どれかが欠けるとその場でエラーになります。
インストール後は、まず空のディレクトリで3つを確認します。ファイルを読めること、ファイルを変更できること、テストを実行できることです。小さなディレクトリなら環境の問題がすぐに表面化します。業務コードの中で切り分けるより、はるかに低コストです。
プロジェクトディレクトリ、権限、境界
ユーザーのホームディレクトリやディスク全体のルートから起動しないでください。明確なリポジトリルートを指定し、読み書きの範囲をプロジェクト内に限定します。どうしても広い範囲が必要な場合は、恒久的に開放するのではなく、その都度の一時的な許可を使います。
コミット前には .gitignore を確認します。ローカルで生成されたキャッシュ、ログ、一時スクリプトはバージョン管理の外に置きます。チームで起こりやすい重大な問題は、コードの書き間違いよりも、ローカルデバッグで生成された機密ファイルをうっかりコミットしてしまうことです。
鍵と認証情報の置き場所
APIキーやアクセストークンなどは、環境変数またはOSの認証情報管理機能を使い、ソースコード、設定ファイル、スクリプトのコメントには書かないでください。.env 自体も .gitignore に追加し、リポジトリには各項目の意味を説明するサンプルファイルだけを置きます。
個人用の認証情報とチーム用の認証情報は分けます。複数人が同じkeyを共有すると、問題が起きたときに誰が使っていたのか追跡できません。ローテーションの周期は事前に決めておきます。定期的に変更し、退職・離任当日に変更し、漏えいの疑いがあれば直ちに変更します。漏えいを発見したら、まず無効化してから調査し、先にログを削除しないようにします。
企業プロキシとネットワーク環境に合わせる
社内ネットワークでこの種のツールを使う場合、問題は単に接続できるかどうかではなく、プロキシと証明書にあることが多いです。企業ゲートウェイがTLSインターセプトを行うと、証明書チェーンが信頼されず、ツールがそのままエラーになることがあります。その場合はIT部門から社内ルート証明書を受け取り、正しい信頼ストアにインストールしてください。検証を一時的に無効化する方法は避けます。
ログイン処理ではブラウザが開くため、コマンドラインとブラウザはできるだけ同じ出口を使うのが望ましいです。さらに、その出口は固定され、安定し、制御できる状態にします。この3つのうち1つでも欠けると、再ログインの繰り返しやCAPTCHA認証が起きやすくなります。ノードを頻繁に切り替えるより、1つのノードを固定したほうが認証を誘発しにくい傾向があります。後者のほうが継続利用しているユーザーの挙動に見えるためです。
出口が実際に有効かどうかは、コマンドラインでプロキシ指定を付け、IP確認サービスへ1回アクセスすれば確認できます。
curl -x http://127.0.0.1:7897 https://ipinfo.io
表示されるアドレスが想定どおりなら問題ありません。ブラウザのタイムゾーンと言語も出口の地域に合わせるのが望ましく、片方が北米を示しているのにもう片方がUTC+8という状態は避けます。
チームで設定を共有する方法
共有するのは構造であって、鍵ではありません。作業ディレクトリの取り決め、プロキシの振り分けルール、実行を許可するコマンド範囲、コードスタイルの制約は、リポジトリ内のコミット可能な設定ファイルにまとめます。鍵は各自のマシンで環境変数から注入します。
新しいメンバーはドキュメントに従えば、同僚へ一人ずつ確認しなくても作業を始められます。チームで複数のIDや複数の環境を同時に使う場合は、PurpleMarkで各環境のブラウザ状態を固定することもできます。どのログイン操作がどの環境で行われたかを、後から追跡できます。
まとめ
この種のツールで問題が起きる場合、原因はツール自身のbugではなく、前提条件がそろっていないことが少なくありません。ランタイムと依存関係、ディレクトリ権限、鍵の保存場所、プロキシ出口、設定共有という5点を小さなプロジェクトで先に整えておけば、その後の繰り返しの調査時間を減らせます。
