1Password SSH Agent × Gitコミット署名でGitHub Verifiedにする完全ガイド（2026年版）
GitHub コミットが "Unverified" になる12の原因を診断フローチャートで網羅。1Password SSH Agentの設定からgitconfig、allowed_signers、agent.tomlまで macOS/Windows/WSL2 対応で解説。
エンジニアのゆとです。
GitHubにプッシュしたコミットに “Unverified” と表示されて、原因を探した経験がある方は多いと思う。
調べると「Signing Keyを登録していない」という記事がヒットする。でも登録したのに直らない——そんなケースが実は多い。原因が一つじゃないからだ。
この記事では1Password SSH Agentを使ったGitコミット署名の設定手順と、Verifiedにならない場合の12の原因を診断フローチャートで網羅する。macOS・Windows・WSL2それぞれの環境を1本でカバーする日本語記事が見当たらなかったので、2026年7月時点の最新情報でまとめた。
まだ1Passwordを導入していない方は、14日間の無料トライアルから試せる。
https://1password.partnerlinks.io/z5r1pmkqu36z
なぜGitコミット署名が必要か
署名がなくても日々の開発は問題なく動く。GitHubもエラーを出すわけじゃない。ただ、セキュリティ上の穴がある。
Gitはデフォルトでコミットの user.name と user.email を自由に設定できる。つまり誰でも他人の名前・メールアドレスを設定して、その人が書いたように見えるコミットを作れる。
# これだけで他人を騙ったコミットが作れてしまう
git config user.name "Linus Torvalds"
git config user.email "[email protected]"
git commit -m "feat: merge something important"オープンソースプロジェクトへのなりすまし攻撃や、企業内での改ざん検知という観点で、コミット署名はセキュリティポリシーとして求められるケースが増えている。
仕組み自体はシンプルで、公開鍵暗号を使う。コミット時に秘密鍵で署名し、GitHub上では対応する公開鍵で検証する。一致すれば “Verified” バッジが表示される。
署名には昔からGPGが使われてきたが、管理の手間が大きい。SSH鍵なら多くのエンジニアが既に持っていて、1Passwordと組み合わせると秘密鍵の管理まで一元化できる。
1Passwordで管理するメリット
1Password SSH Agentを使う最大のメリットは、秘密鍵がディスクに保存されないことだ。
従来の ~/.ssh/id_ed25519 は平文ファイルとしてディスクに存在する。パスフレーズを設定していても、マルウェアがファイルシステムにアクセスできれば取得できてしまう。
1Password SSH Agentの場合、秘密鍵は1Passwordの暗号化ストレージに格納される。SSH接続やGit署名のたびに1Passwordの認証（Touch IDまたはマスターパスワード）を求める。「使用確認」をONにすれば、接続ごとに許可ダイアログが出る。
まとめると：
- 秘密鍵がディスクに存在しない（紛失・盗難時のリスク最小化）
- 1Passwordのロック = SSH Agentのロック（ログアウト後は鍵が使えない）
- 鍵の追加・削除が1Password UIで完結
- GitコミットとSSH接続を同じ鍵で管理できる
GPGとの比較で言うと、GPGはWeb of Trustモデルを前提として設計されており、個人用途では管理コストの割に得られるメリットが少ない。SSH鍵は既存のインフラを流用できる分、導入コストが格段に低い。
STEP 1: SSH AgentをONにする（macOS / Windows）
macOS
- メニューバーの1Passwordアイコンをクリック
- Settings（設定）> Developer タブを開く
- “Use the SSH Agent” をオン
ここで一つ忘れがちな設定がある。エージェントの継続稼働だ。
- “Keep 1Password in the menu bar” → オン
- “Start at login” → オン
この2つが無効だと、再起動後にSSH Agentが起動せず、コミット時にエラーになる。「設定したはずなのに翌日から動かない」というパターンの多くがこれだ。
Windows
WindowsにはOpenSSHのAuthentication Agentサービスが既に存在する。これと1PasswordのSSH Agentが競合するため、先にOpenSSH Agentを無効化する必要がある。
- スタートメニューで「サービス」を検索して開く
- “OpenSSH Authentication Agent” を右クリック > プロパティ
- スタートアップの種類を「無効」に変更
- サービスを停止
その後、1Password Settings > Developer > “Use the SSH Agent” をオン。
STEP 2: SSHキーを1Passwordに追加する
1Passwordの設定が終わったら、SSH鍵を生成して保存する。
- 1Password を開く
- 新規アイテム > “SSH Key” を選択
- “Generate a New Key” をクリック
- キーの種類: Ed25519（RSAよりも短くて強い。特別な理由がなければこれ）
- 名前をつける（例: “GitHub SSH Key 2026”）
- Save
既存の ~/.ssh/id_ed25519 を1Passwordに移行したい場合は、“Import from file” から取り込める。移行後は元のキーファイルを削除しておくと管理がスッキリする。
まだ1Passwordを使っていない方はここから試せる（14日間無料トライアル）。
https://1password.partnerlinks.io/z5r1pmkqu36z
STEP 3: GitHub側の設定（認証キー + 署名キー）
Unverifiedになる最多原因がここだ。GitHub側でSSHキーを登録する際、“Authentication Key” と “Signing Key” の2種類があることを知らないまま Authentication Key だけ登録して終わっているケース。
設定の流れ：
- GitHub > Settings > SSH and GPG keys を開く
- “New SSH key” をクリック
- Key type: “Authentication Key” を選択
- 1PasswordからPublic Keyをコピーして登録（すでに Authentication Key を登録済みならここはスキップ）
- もう一度 “New SSH key” をクリック
- Key type: “Signing Key” を選択
- 同じ公開鍵をペーストして登録
「同じ公開鍵を2回登録するの？」という疑問を持つ方も多い。そうだ、同じ鍵で両方登録できる。GitHubはキーの用途（認証 / 署名）を別エントリで管理している。
公開鍵のコピー方法：
- 1Passwordでキーアイテムを開く
- “Public Key” フィールドの右にあるコピーアイコンをクリック
- “Configure with GitHub” ボタンが表示されていれば自動登録も可能
STEP 4: gitconfigを設定する（1PW自動設定 vs 手動）
1Passwordによる自動設定
SSH AgentをONにすると、1Passwordが gitconfig の変更を提案するダイアログを表示することがある。これを使えば手動設定なしで完了する。
ただし自動設定が走ったかどうかわかりにくいので、手動で確認・設定するほうが確実だ。
手動設定（macOS）
~/.gitconfig に以下を追加する：
[user]
signingkey = ssh-ed25519 AAAA...（1Passwordからコピーした公開鍵）
[gpg]
format = ssh
[gpg "ssh"]
program = /Applications/1Password.app/Contents/MacOS/op-ssh-sign
[commit]
gpgsign = trueop-ssh-sign のパスは1Passwordのインストール先によって変わる可能性がある。存在確認は：
ls /Applications/1Password.app/Contents/MacOS/op-ssh-sign~/.ssh/config の設定（macOS）
SSH AgentのソケットをSSHクライアントに伝える設定が必要だ。
Host *
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"このソケットパスは1Passwordが提供している固定値なので、そのままコピーして使える。
Windows / WSL2 のgitconfig
Windows側の op-ssh-sign は自動でパスが設定されることが多いが、WSL2からWindowsの署名バイナリを呼ぶ場合は次のセクションで詳述する。
STEP 5: 動作確認（git log —show-signature）
設定が完了したら、テスト用コミットを作って確認する。
echo "test" >> README.md
git add README.md
git commit -m "test: verify signed commit"コミット時に1Passwordの認証ダイアログが出れば正常に動いている。次に署名を確認する。
git log --show-signature -1うまくいっていれば以下のような出力が出る：
commit abc1234...
gpg: Signature made ...
gpg: Good signature from "[email protected]"
...“Good signature” が出ればローカル検証はOK。GitHubにプッシュして、コミット横に “Verified” バッジが表示されていれば完了だ。
バッジが出ない場合は後述の診断フローチャートで原因を特定できる。
WSL2環境での追加設定
WSL2はWindowsのSSH Agentに直接接続できないため、追加設定が必要だ。
1Passwordは op-ssh-sign-wsl.exe というWSL2専用のブリッジバイナリを提供している。gitconfig の gpg.ssh.program を以下に変更する：
[gpg "ssh"]
program = /mnt/c/Users/<USERNAME>/AppData/Local/Microsoft/WindowsApps/op-ssh-sign-wsl.exe<USERNAME> はWindowsのユーザー名に置き換える。
macOSとWSL2を使い分けている場合、gitconfig の設定を [includeIf] で環境別に切り分けると管理しやすい：
# ~/.gitconfig（共通設定）
[gpg]
format = ssh
[commit]
gpgsign = true
[includeIf "gitdir:/home/"]
path = ~/.gitconfig-wsl# ~/.gitconfig-wsl（WSL2専用）
[gpg "ssh"]
program = /mnt/c/Users/<USERNAME>/AppData/Local/Microsoft/WindowsApps/op-ssh-sign-wsl.exemacOS側は ~/.gitconfig 本体に program = /Applications/1Password.app/Contents/MacOS/op-ssh-sign を書いておけばいい。
agent.tomlで複数Vault・複数鍵を管理する
1Passwordに複数のVaultがあって、どの鍵を使うか制御したい場合は agent.toml で設定できる。
macOSのパス：~/.config/1Password/ssh/agent.toml
# Work VaultにあるすべてのSSHキーを使う
[[ssh-keys]]
vault = "Work"
# Personal Vaultの特定アイテムだけを使う
[[ssh-keys]]
item = "Personal GitHub Key"
vault = "Personal"
# 特定のアカウントに紐づくキーを使う
[[ssh-keys]]
account = "[email protected]"このファイルがない場合、デフォルトで全VaultのSSHキーが対象になる。複数のGitHubアカウントを持っていて「仕事用と個人用を分けたい」という場合に使う設定だ。
変更後は1Passwordのメニューバーアイコンから “Lock 1Password” → 再ログインで設定が反映される。
GitHub Verifiedにならない場合の診断フローチャート（12原因）
設定を完了したのに “Verified” にならない場合、原因は12パターンに分類できる。
診断ステップ1: ローカル署名を確認する
git log --show-signature -1“Good signature” が出るか出ないかで分岐する。
- “Good signature” が出る → カテゴリA・Bの問題（GitHub側・メール設定）
- “Good signature” が出ない → カテゴリC・Dの問題（gitconfig・環境）
カテゴリA: GitHub側設定ミス（最多）
A-1: Signing Key未登録GitHub Settings > SSH and GPG keys を開く。“Authentication Key” タイプのみで “Signing Key” タイプがない。
対処: STEP 3の手順でSigning Keyとして同じ公開鍵を別途登録する。これが全原因の中で最多だ。
A-2: 鍵が別のGitHubアカウントに登録されている複数のGitHubアカウントを持っている場合、Signing Keyが別アカウントに登録されている可能性がある。コミットするアカウントに紐づいているか確認する。
カテゴリB: メール設定ミス
GitHubのコミット検証はメールアドレスの完全一致で行われる。
git config user.emailこれがGitHubの Settings > Emails に登録されているメールと一致しているか確認する。
B-1: 大文字・小文字の不一致[email protected] vs [email protected] など。大文字小文字が違うだけで Unverified になる。
古いメールアドレスがgitconfigに残っている。
git config --global user.email "[email protected]"GitHubの「メールアドレスを非公開にする」設定をONにしていると、コミットには [email protected] 形式のアドレスが使われる。この場合、gitconfigのメールもそのnoreplyアドレスにする必要がある。GitHub の Settings > Emails にnoreplyアドレスが表示されている。
カテゴリC: gitconfig設定ミス
設定の現状確認：
git config --list --show-origin | grep -E "gpg|signing|sign"gpg.format=ssh になっているか確認。gpg のままだとGPGで署名しようとしてエラーになる。
ls "$(git config gpg.ssh.program)"ファイルが存在するか確認。パスが間違っていると op-ssh-sign: No such file or directory エラーが出る。
git config user.signingkey出力が空、または存在しない鍵文字列になっていないか確認する。
C-4: リポジトリローカルの設定がグローバルを上書きgit config --local --list | grep gpgリポジトリ内の .git/config にグローバル設定と矛盾する設定が残っていないか確認する。
git config commit.gpgsignfalse か空なら修正する：
git config --global commit.gpgsign trueまたは毎回 git commit -S で署名することも可能。
カテゴリD: 環境・バージョン問題
D-1: Gitのバージョンが古い（2.34未満）git --versionSSH署名（gpg.format = ssh）はGit 2.34以降で対応している。それより古いと unsupported value for gpg.format: ssh というエラーが出る。Homebrew環境なら brew upgrade git で最新化できる。
/Applications/1Password.app/... というパスはmacOSのパスなのでWSL2では動かない。WSL2では op-ssh-sign-wsl.exe を使う（前章参照）。
git log --show-signature -1 の出力に “No principal matched” や “No allowed signers” が出る場合、allowed_signers ファイルが未設定だ。ただしこれはローカル検証の話であって、GitHubの “Verified” 表示には影響しない。
チームで署名を相互検証したい場合は設定が必要。個人利用なら放置でも構わない。
設定する場合：
# ~/.ssh/allowed_signers
[email protected] ssh-ed25519 AAAA...（公開鍵）# ~/.gitconfig
[gpg "ssh"]
allowedSignersFile = ~/.ssh/allowed_signersよくある質問
認証キーと署名キーは同じSSH鍵でいいか？
技術的には同じ鍵を Authentication Key と Signing Key の両方に登録できる。セキュリティ上の完全な分離を求めるなら別鍵を使う方が望ましいが、個人用途では同じ鍵で十分だ。
重要なのは「Signing Keyとして別途登録する」こと。同じ鍵を使っていても、GitHub上でSigning Keyとして登録されていなければ Unverified になる。
allowed_signersは必須か？
GitHub上の “Verified” 表示には必要ない。allowed_signers はローカルでの git log --show-signature 検証に使うファイルだ。チームで署名を検証し合う場合や、CIで署名の整合性を確認したい場合は設定する。
個人プロジェクトでGitHubのバッジだけ気にしているなら、設定しなくても問題ない。
1Passwordを再起動するとSSH Agentが切れる？
“Keep 1Password in the menu bar” と “Start at login” を有効化していれば切れない。この設定が無効だと、ログイン後に1Passwordを手動起動するまでSSH Agentが起動しない状態になる。
毎朝「SSH接続できない」「コミットできない」という状態になる場合、ほぼこれが原因だ。STEP 1に戻って確認してみてほしい。
1PasswordはこちらのPartnerStackリンクから試せる（14日間無料、カード登録なし）。
