コンテンツにスキップ
開発コンテナ

トラブルシューティング

コンテナが起動しない

Section titled “コンテナが起動しない”

”Conflict. The container name is already in use”

Section titled “”Conflict. The container name is already in use””
Terminal window
docker rm -f devcontainer
docker compose up -d

AIツールが動作しない

Section titled “AIツールが動作しない”

”claude: command not found”

Section titled “”claude: command not found””

イメージが古い可能性があります。最新版をプルして再起動してください：

Terminal window
docker compose pull
docker compose up -d

Claudeが “Not logged in” と表示する

Section titled “Claudeが “Not logged in” と表示する”

エントリポイントは ~/.claude.json にオンボーディングフラグを設定します。ファイルが存在しない場合：

Terminal window
echo '{"hasCompletedOnboarding": true}' > ~/.claude.json

Claudeが “Invalid API key” と表示する

Section titled “Claudeが “Invalid API key” と表示する”

実際に設定されている値を確認してください：

Terminal window
echo "$ANTHROPIC_API_KEY"

よくある原因：

  • LiteLLMプロキシキーが未設定または無効 — プロキシモードを使用している場合、.env の LITELLM_API_KEY に正しいプロキシ認証情報が含まれていることを確認し、コンテナを再起動してエントリポイントが ANTHROPIC_API_KEY を導出できるようにしてください。
  • OAuthトークンまたはプロキシモードの不一致 — 認証モードは1つだけ使用してください。CLAUDE_CODE_OAUTH_TOKEN が設定されている場合、LiteLLMプロキシモードより優先されます。

APIリクエストが401で失敗する

Section titled “APIリクエストが401で失敗する”

APIキーが正しく設定されていることを確認してください：

Terminal window
echo "$ANTHROPIC_API_KEY"

プロバイダーに直接呼び出しを行い、動作を確認してください。

Claudeが “model not found” と表示する

Section titled “Claudeが “model not found” と表示する”

モデルはプロバイダーとAPIキーによって決定されます。利用可能なモデルについてはプロバイダーのドキュメントを確認してください。

GitHub CLI

Section titled “GitHub CLI”

”gh: not authenticated”

Section titled “”gh: not authenticated””

gh CLIには GH_TOKEN 環境変数が必要です。.env ファイルに追加してください：

GH_TOKEN=ghp_your-token-here

github.com/settings/tokens でトークンを作成してください。きめ細かいトークン（推奨）または repo スコープ付きのクラシックトークンのどちらも使用できます。.env を更新した後、コンテナを再起動してください。

HTTPS git cloneが401で失敗する

Section titled “HTTPS git cloneが401で失敗する”

GH_TOKEN が設定されている場合、エントリポイントは gh auth setup-git を実行してHTTPS用のgit認証ヘルパーを設定します。HTTPS操作が失敗する場合：

  1. トークンが有効であることを確認：gh auth status
  2. 認証ヘルパーが設定されていることを確認：git config --global credential.helper
  3. コンテナを再起動してエントリポイントを再実行

SSH vs HTTPS

Section titled “SSH vs HTTPS”

コンテナ内では両方の認証方法を共存させることができます：

  • SSH（.env の SSH_PRIVATE_KEY）— git@github.com: URLを使用します。組織がSSHを強制している場合に必要です。
  • HTTPS（.env の GH_TOKEN）— https://github.com/ URLを使用します。セットアップが簡単で、鍵の管理が不要です。

両方が設定されている場合、gitはリモートURLに一致するプロトコルを使用します。既存のクローンを切り替えるには：

Terminal window
# SSHからHTTPSへ
git remote set-url origin https://github.com/owner/repo.git


# HTTPSからSSHへ
git remote set-url origin git@github.com:owner/repo.git

権限の問題

Section titled “権限の問題”

/workspaceまたは/homeで “Permission denied”

Section titled “/workspaceまたは/homeで “Permission denied””
Terminal window
sudo chown -R $(id -u):$(id -g) /workspace ~

npm installがEACCESで失敗する

Section titled “npm installがEACCESで失敗する”

エントリポイントは ~/.npm-global にユーザー書き込み可能なnpmグローバルプレフィックスを自動設定するため、実行時の npm install -g コマンドは sudo なしで動作するはずです。それでもEACCESエラーが発生する場合は、手動で修正を適用してください：

Terminal window
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
export PATH="$HOME/.npm-global/bin:$PATH"

ビルドの問題

Section titled “ビルドの問題”

ビルドに非常に時間がかかる

Section titled “ビルドに非常に時間がかかる”

初回ビルドではベースイメージ（約1 GB）をダウンロードします。以降のビルドではキャッシュが使用されます。毎回遅い場合：

Terminal window
docker builder prune

“No space left on device”

Section titled ““No space left on device””
Terminal window
docker system prune -a --volumes

警告： これはこのプロジェクトのものだけでなく、すべての未使用コンテナ、イメージ、ボリュームを削除します。

ネットワーク

Section titled “ネットワーク”

コンテナ内からインターネットに接続できない

Section titled “コンテナ内からインターネットに接続できない”
Terminal window
ping -c 1 8.8.8.8
nslookup google.com
curl -I https://github.com

DNSが失敗する場合、ホストの /etc/docker/daemon.json に以下を追加してください：

{
  "dns": ["8.8.8.8", "8.8.4.4"]
}

その後、Dockerを再起動してください。

リモートディスプレイ（noVNC）

Section titled “リモートディスプレイ（noVNC）”

noVNCで黒い画面が表示される

Section titled “noVNCで黒い画面が表示される”

Xvfbが起動していない可能性があります。コンテナ内で確認してください：

Terminal window
ps aux | grep Xvfb

実行されていない場合、ENABLE_VNC が false に設定されていないことを確認し、コンテナを再起動してください。

“Cannot open display” または “No display” エラー

Section titled ““Cannot open display” または “No display” エラー”

DISPLAY 環境変数が設定されていない可能性があります。確認してください：

Terminal window
echo "$DISPLAY"

:99 と表示されるはずです。空の場合、.env または devcontainer.json に DISPLAY=:99 を追加して再起動してください。

ポート6080の接続が拒否される

Section titled “ポート6080の接続が拒否される”

noVNCが実行されていない可能性があります。コンテナ内で確認してください：

Terminal window
ps aux | grep -E 'novnc|websockify'

実行されていない場合、ENABLE_VNC が true（デフォルト）であることを確認し、コンテナログを確認してください：

Terminal window
docker compose logs dev | grep -i vnc

ポート6080が既に使用中

Section titled “ポート6080が既に使用中”

docker-compose.yml でホストポートを変更してください：

ports:
  - "127.0.0.1:16080:6080"

Chrome DevTools MCP

Section titled “Chrome DevTools MCP”

Chromeのリモートデバッグが応答しない

Section titled “Chromeのリモートデバッグが応答しない”

共有Chromeインスタンスはポート9222で実行されているはずです。コンテナ内で確認してください：

Terminal window
# Chromeは実行されていますか？
curl http://localhost:9222/json/version


# Chromeのログを確認
cat ~/.local/share/chrome-browser/chrome.log


# シンボリックリンクを確認
ls -la /opt/google/chrome/chrome


# Chromeを手動で再起動
. /usr/local/lib/chrome-browser.sh
start_chrome_browser

シンボリックリンクが存在しない場合、最新のイメージをプルしてコンテナを再起動してください。

ブラウザプロファイルのロックエラー

Section titled “ブラウザプロファイルのロックエラー”

共有ブラウザアーキテクチャでは、プロファイルロックエラーは発生しないはずです。発生した場合、古いChromeプロセスがロックを保持している可能性があります：

Terminal window
# 古いChromeプロセスを強制終了
pkill -f 'chrome.*remote-debugging-port' || true


# ロックファイルを削除
rm -f ~/.cache/chrome-devtools-mcp/chrome-profile/SingletonLock


# Chromeを再起動
. /usr/local/lib/chrome-browser.sh
start_chrome_browser

chrome-devtools-mcpツールが重複する

Section titled “chrome-devtools-mcpツールが重複する”

chrome-devtools-mcpサーバーは ~/.claude/settings.json にグローバルに登録されています。リポジトリごとの .mcp.json でも登録している場合、ツールが重複して表示されます。リポジトリごとの .mcp.json ファイルから chrome-devtools-mcp エントリを削除してください：

Terminal window
# リポジトリごとの設定を確認
cat .mcp.json

グローバル登録を使用するために、リポジトリごとの .mcp.json から chrome-devtools-mcp キーを削除してください。

すべてをリセット

Section titled “すべてをリセット”
Terminal window
docker compose down -v
docker rm -f devcontainer 2>/dev/null
docker compose pull
docker compose up -d

これによりボリューム内のすべてのデータが破棄されます。リポジトリの再クローンとツールの再設定が必要になります。