Claude Code × DevContainer における ssh / Git 設定まわりの気づき

AI駆動開発

Last updated at 2026-05-09Posted at 2026-03-18

前置き

この記事は私がClaude Codeで個人開発をするにあたりChatGPTと壁打ちした記録を基にAIライティングしたものです。あくまで私が行き着いた方法に過ぎないことをご容赦ください。

はじめに

この記事は、前回まとめた Claude Code × DevContainer × GitHub 運用設計の続編です。
前回は、AI エージェントに実装から commit・push・Pull Request 作成までをどこまで任せるか、そのための認証・署名・権限制御の全体設計を整理しました。

一方、実際に環境を組み始めると、運用設計だけでは見えてこない細かな落とし穴がいくつかありました。特に印象的だったのが、DevContainer における Git 設定の共有と、ssh / Git 署名まわりの挙動です。

本記事では、その中でも特にハマりやすかった

DevContainer が .gitconfig を共有する挙動
agent 用リポジトリで local Git 設定を確認する重要性
ssh 鍵の共有範囲
Claude Code 側での読み取り制御
Copy Git Config 設定の見え方

といった点を、実際の試行錯誤をもとに整理します。

前回の記事をまだ読んでいない場合は、先に Claude Code × DevContainer × GitHub 運用設計を参照すると、今回の話がつながりやすくなります。

なお、DevContainer の基本的な考え方や devcontainer.json の役割は、VS Code 公式の Create a Dev Container と Developing inside a Container が全体像の把握に役立ちます。

開発環境構成

今回の開発環境は次の構成です。

DevContainer
Node.js + pnpm
Claude Code
GitHub CLI
Git SSH commit signing

構成を単純化すると次のようになります。

Developer
  ↓
VS Code
  ↓
DevContainer
  ↓
Claude Code
  ↓
Git / gh CLI
  ↓
GitHub

この構成では AI エージェントが

Git 操作
CLI 実行
コード編集

を行う可能性があるため、権限設計が非常に重要 になります。

発端となった違和感

最初の違和感は、DevContainer 内で Git の署名鍵を確認したときでした。

git config --show-origin user.signingkey

すると次のように表示されました。

file:/home/node/.gitconfig ssh-ed25519 AAAA...

agent 用に clone したリポジトリを開いているにもかかわらず、/home/node/.gitconfig が参照されています。

さらに cat /home/node/.gitconfig を確認すると、その中身は agent 用ではなく、ホスト側の .gitconfig 相当でした。

ここで初めて、DevContainer がホストの Git 設定をコンテナに共有している ことに気づきました。

`.gitconfig` 共有の仕様

DevContainer では、Git をコンテナ内でも使いやすくするために、ホスト側の Git 設定や資格情報を共有する仕組みがあります。
この挙動は VS Code 公式の Sharing Git credentials with your container に記載されています。

その結果、コンテナ内では一見すると独立したファイルに見える

/home/node/.gitconfig

が、実質的には ホストの .gitconfig を反映したもの になっている場合があります。

便利な仕様ではありますが、AI エージェントを動かす文脈では注意が必要です。
なぜなら、コンテナ内のツールが .gitconfig を参照できるということは、Claude Code のようなエージェントも、権限さえあればその内容に到達できるからです。

`Copy Git Config` 設定の見え方

今回特に混乱しやすかったのが、VS Code 側の Copy Git Config 設定の見え方です。

当初は、DevContainer を開いているとこの設定項目が見当たらず、Local 側に戻したときにだけ表示されるように感じました。しかし後から確認すると、設定そのものが消えていたわけではありませんでした。

実際には、VS Code を DevContainer で開くと設定画面のタブ構成が変わります。

Local で開いた場合は User / Workspace
DevContainer で開いた場合は User / Remote / Workspace

のように、Remote タブが追加されます。

そのため、同じ Copy Git Config でも

Local 側では User 配下で確認できる
DevContainer 側では Remote タブを含む構成の中で見える
しかも Modified in User のように、値自体は User 設定由来であることが示される

という見え方になります。

つまり、ここで起きていたのは

設定が消えた
Local に戻らないと存在しない

ということではなく、設定ターゲットの違いによって UI 上の見え方が変わっていた ということです。

とはいえ、これは十分に混乱しやすい挙動です。

Remote 接続中は設定タブ構成が変わる
User と Remote のどちらに値があるのかが直感的でない
実際の値は User 設定なのに、Remote 側の画面でも項目が見える

このため、.gitconfig 共有の有効状態を誤認しやすい点は注意が必要です。

Local で開いた場合

Remote で開いた場合

AIエージェント利用時の注意点

.gitconfig には、次のような情報が含まれることがあります。

user.name
user.email
user.signingkey
includeIf
credential helper
alias

これらは秘密情報そのものではない場合もありますが、個人用設定や組織用設定の構造を AI エージェントに見せる ことになります。

また、署名設定が global config から読み込まれると、agent 用に分離したつもりでも

個人署名鍵
会社署名鍵
別用途の Git 設定

が混在する可能性があります。

agent 用 Git 設定の確認

今回の学びとして最も重要だったのは、agent 用に clone したリポジトリでは、そのリポジトリの .git/config が本当に使われているか確認した方がよい という点です。

確認には次のコマンドが使えます。

git config --show-origin user.signingkey
git config --show-origin gpg.format
git config --show-origin commit.gpgsign
git config --show-origin gpg.ssh.program

理想は、必要な署名設定が次のように表示されることです。

file:.git/config

もし

file:/home/node/.gitconfig

となっているなら、global config が使われています。

今回も、agent 用リポジトリを開いていたにもかかわらず、[gpg] や [commit] の設定が local に存在しておらず、不足分を global config から補っていました。

つまり、

agent 用 clone を使っている
だから agent 用設定だけが効くはず

ではなく、

local に無い設定は global から継承される

という Git の基本動作を踏まえて、署名設定一式を local に閉じ込める必要がある ということです。

Git 署名設定の分離

そのため、agent 用リポジトリでは署名設定を .git/config に閉じ込めました。

git config --local user.name "Agent"
git config --local user.email "agent@example.com"
git config --local gpg.format ssh
git config --local user.signingkey "ssh-ed25519 AAAA..."
git config --local commit.gpgsign true
git config --local gpg.ssh.program ssh-keygen

このように設定しておくことで、

global .gitconfig 依存の回避
agent 用署名設定の独立
DevContainer 再起動時の挙動の安定化

が期待できます。

ssh 鍵共有範囲の制限

当初はホスト側の .ssh 全体をコンテナにマウントしていました。

"source=${localEnv:HOME}/.ssh,target=/home/node/.ssh,type=bind"

しかしこれは、すべての ssh 鍵をコンテナに見せる 状態です。

そこで次のように変更しました。

"source=${localEnv:HOME}/.ssh/agent,target=/home/node/.ssh,type=bind,readonly"

これにより、

agent 用鍵のみ共有
他の秘密鍵へのアクセス抑制
AI エージェントから見える範囲の最小化

が実現できます。

DevContainer での環境変数やマウントの扱いは、VS Code 公式の Environment variables も参考になります。

注意：この方法はホストマシンにマウントしていることに変わりないため、ホストマシンの.ssh/agent以下にAIエージェントの秘密鍵を置いてある状態で悪意のあるインストールスクリプトが実行されてしまうと秘密漏洩に繋がる可能性があります。そのため、基本的にマウント自体を避けた方が良さそうです。下記はClaude Code Docsからの引用です。

開発コンテナは実質的な保護を提供していますが、すべての攻撃に完全に耐性のあるシステムはありません。 --dangerously-skip-permissions で実行する場合、開発コンテナは、~/.claude に保存されている Claude Code の認証情報を含む、コンテナ内でアクセス可能なものを悪意のあるプロジェクトが流出させることを防ぎません。信頼できるリポジトリで開発する場合にのみ開発コンテナを使用し、Claude のアクティビティを監視してください。 ~/.ssh やクラウド認証情報ファイルなどのホストシークレットをコンテナにマウントすることは避け、リポジトリスコープまたは短期間有効なトークンを使用してください。

筆者の場合、1Passwordに秘密鍵を退避させるなどの対策はしていますが、それでも十分ではない可能性があります。対応については別途こちらの投稿をしました。

Claude Code permission による `.gitconfig` 保護

Claude Code 側でも、.gitconfig へのアクセス経路を絞りました。

settings.json において、次の操作を ask permission に設定しました。

Bash(cat ~/.gitconfig)
Read(~/.gitconfig)

これにより、AI エージェントが .gitconfig を読み取ろうとした場合に、明示的な許可が必要になります。

DevContainer 側でホスト設定が共有されていたとしても、Claude Code 側で読み取りにブレーキをかける という二段構えにできます。

DevContainer 運用時の確認項目

今回の経験から、DevContainer で AI エージェントを使う際は、少なくとも次を確認した方がよいと感じました。

`.gitconfig` 共有状態

Copy Git Config が有効になっていないか確認します。
ただしここで重要なのは、設定は消えるのではなく、Local と DevContainer で見え方が変わる という点です。

Git 設定の参照元

次のコマンドで、署名設定や Git 設定の参照元を確認します。

git config --show-origin --get user.signingkey
git config --show-origin --get gpg.format
git config --show-origin --get commit.gpgsign

ssh 鍵の共有範囲

.ssh 全体ではなく、agent 用鍵だけをマウントする設計を検討します。

Claude Code permissions

.gitconfig や秘密情報に到達しやすい操作は ask permission を検討します。

最終構成

今回最終的に採用した構成は次の通りです。

項目	設計
ssh 鍵	`~/.ssh/agent` のみマウント
Git 署名	repo local config に分離
`.gitconfig`	Claude Code 側で ask permission
Git 設定確認	`git config --show-origin` で参照元を確認
DevContainer 設定	`Copy Git Config` の有効状態を確認

まとめ

Claude Code × DevContainer の組み合わせは、AI エージェント開発環境として非常に強力です。

一方で、今回強く印象に残ったのは、DevContainer が .gitconfig を共有する仕様だけでなく、その設定の見え方も分かりにくい という点でした。

特に次の点は見落としやすいポイントです。

Copy Git Config は消えるのではなく、設定ターゲットによって見え方が変わる
DevContainer では Remote タブが加わるため、User と Remote の関係を誤認しやすい
agent 用 clone を開いていても、local に足りない設定は global から継承される

そのため、AI エージェント環境では

agent 用リポジトリの .git/config が本当に使われているか確認する
ssh 鍵の共有範囲を最小化する
.gitconfig の読み取りを permission 管理する
Copy Git Config の有効状態を確認し、UI の見え方に惑わされない

といった対策が重要です。

前回の記事が AI に PR 作成まで任せるための全体設計 だとすると、今回の記事は その設計を実装に落とし込むときに見えてくる足元の罠 を整理したものです。

DevContainer は便利ですが、AI エージェントと組み合わせるときは、便利さの裏で何が共有され、どの設定ターゲットで有効になっているかを明示的に把握すること が大切です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up