GitHubが「Unverified」になる12原因——1PasswordでSSH署名を完全解決する【2026年版】
1PasswordのSSH AgentでGitコミット署名を設定したのにGitHubが「Unverified」のまま——その原因12パターンをカテゴリ別診断フローで完全網羅。macOS・Windows・WSL2対応、agent.toml日本語解説、認証キーと署名キーの分離設計まで2026年最新UIで解説。
※ 本記事には1Passwordのアフィリエイトリンクが含まれています。記事内リンクから申し込みがあった場合、筆者に紹介報酬が発生します。内容は独自調査に基づいており、報酬によって評価が変わることはありません。 #PR
エンジニアのゆとです。
1Password CLIでVault管理を始めて、ついでにSSH Agentも有効化した。セキュリティ周りを整備している気分になっていたところで気づいた——GitHubのコミット履歴を見ると、ずっと「Unverified」のままだった。
設定はしたはずなのに。
原因は、gitconfigに書いてあるメールアドレスの大文字と、GitHubに登録してあるメールアドレスの大文字が違っていた（B-1型、詳しくは後述）。これで1時間溶かした。
で、その後に調べたら「Unverified」になる原因がほかにも山ほどあることがわかった。日本語でまとまっている記事が2023年のDevelopersIO記事1本しかなく、しかも原因が1つしか載っていない。12通りある。
この記事では、1Password SSH Agentの基本設定から始まって、「Unverified」になる12の原因をカテゴリ別に整理した診断フローまでを一本で解説する。macOS・Windows・WSL2の3環境対応。2026年7月時点の最新UIで書いた。
なぜGitコミット署名が必要か
まず前提として。Git のコミットには user.name と user.email を好きに設定できる。つまり「Linus Torvalds」名義でコミットを作ることが誰でもできる。これはなりすまし攻撃の古典的な手法で、オープンソースプロジェクトへのサプライチェーン攻撃に悪用されてきた。
SSHキーによるコミット署名は、この問題への暗号学的な回答だ。署名付きコミットはGitHub上で「Verified」バッジが表示される。これは「このコミットを作った人物は、対応する秘密鍵を持っていた」という証明で、名義だけでの偽造はできない。
「フリーランスの個人プロジェクトで誰になりすまされるんだ」という話はある。でもセキュリティ意識の高いチームや企業との共同開発では、すべてのコミットに署名を求めるルールになっていることが増えている。先に設定しておいて損はない。
1Passwordに話を戻すと、SSHキーをVaultで管理することの利点は「秘密鍵がディスクに存在しない」こと。~/.ssh/id_ed25519 のような平文ファイルを作らなくていい。Touch IDで解除するたびに、1Passwordが都度メモリ上でキーを扱う。詳細は1Password CLIでシークレットをVault管理する方法に書いた。
STEP 1: SSH Agentを有効化する（macOS / Windows）
macOS
- メニューバーの1Passwordアイコン > 設定（またはCmdキーで直接）
- 「Developer」タブを開く
- 「Use the SSH Agent」をオン
- 「Keep 1Password in the menu bar」と「Start at login」を有効化
この2つが有効でないと、PCの再起動後にSSH Agentが動かなくなる。地味に見落としやすい。
次に ~/.ssh/config を設定する。
Host *
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"このソケットパスは1Password固有のもの。/run/user/1000/p11-kit/ssh-agent.socket 等のシステム標準パスとは別物なので注意。
動作確認：
ssh -T [email protected]
# Hi username! You've successfully authenticated...Windows
WindowsのSSH Agent設定には一つ前置き作業がある。WindowsにはOpenSSH Authentication Agentというサービスが組み込まれているが、これが動いていると1Passwordのエージェントと競合する。先に無効化する必要がある。
- サービスアプリ（
services.msc）を開く - 「OpenSSH Authentication Agent」を見つける
- スタートアップの種類を「無効」に設定
- 実行中であれば「停止」する
- 1Password設定 > Developer > 「Use the SSH Agent」をオン
対応クライアントはMicrosoft OpenSSH互換クライアントのみで、PuTTYはサポートしていない。Git for Windows はバージョン2.33以上が推奨だが、SSH署名機能を使うには2.34以上が必要。インストール済みのバージョンは git --version で確認できる。
STEP 2: GitHub側の設定——ここが最多ミスポイント
SSH Agentを有効化しただけでは署名はできない。GitHubの設定側でもう一つ作業が必要で、これが「Unverified」の最大の原因になっている。
GitHubのSSHキー管理では、キーに2種類の「タイプ」がある。
- Authentication key — SSH接続（git clone / git push）のための鍵
- Signing key — コミット署名の検証のための鍵
これらは別々に登録する必要がある。SSH接続用にキーを登録済みだからといって、署名用に自動的に使われることはない。同じ公開鍵を両方のタイプで登録することは可能だ。
登録手順：
- GitHub Settings > SSH and GPG Keys
- 「New SSH key」をクリック
- Key typeのドロップダウンで 「Signing key」 を選択
- 公開鍵（
ssh-ed25519 AAAA...で始まる文字列）を貼り付ける - Titleを入力して保存
Authentication keyとSigning keyのどちらかしか登録されていない状態は、よくある。特に「SSH接続はできているのにVerifiedにならない」という状態の人は、ほぼここが原因。
GitHub Actions等のCI/CDでも1Passwordを使っている場合は、GitHub Actions × 1Password × Claude Code のシークレット管理も参考になる。
STEP 3: gitconfigを設定する
GitHubに署名キーを登録したら、今度はローカルのgitconfigにどのキーで署名するかを設定する。
1Passwordの自動設定を使う（推奨）
1Password 8以降では、署名設定をGUIから自動的に適用できる。
- 1Password で対象のSSHキーアイテムを開く
- 「Configure Git Commit Signing」をクリック
- 「Edit Automatically」を選択
これで4つのgitconfig設定が自動的に書き込まれる。楽で確実。
手動で設定する場合
# 公開鍵を確認する
op item get "Your SSH Key" --fields "public key"~/.gitconfig に以下を追記する（または git config --global コマンドで設定）：
[user]
signingkey = ssh-ed25519 AAAA...（公開鍵の文字列）
[gpg]
format = ssh
[gpg "ssh"]
program = /Applications/1Password.app/Contents/MacOS/op-ssh-sign
[commit]
gpgsign = trueWindows の場合、gpg.ssh.program のパスは：
program = C:/Users/<USERNAME>/AppData/Local/Microsoft/WinGet/Packages/AgileBits.1Password_Microsoft.Winget.Source_.../op-ssh-sign.exeインストール方法によってパスが変わる可能性がある。確実なのは where op-ssh-sign で探すこと。
commit.gpgsign = true を忘れると、コミット時に -S フラグを毎回つけないと署名されない。自動署名させるなら必須の設定。
一点、user.email の設定が後で重要になる。ここに書くメールアドレスはGitHubに登録しているメールアドレスと完全一致させる必要がある。大文字小文字のぶれも含めて。（B-1型の原因、詳しくは診断フローのセクションで）
STEP 4: 動作確認
設定が終わったら実際に署名つきコミットを作って確認する。
# テスト用コミット
git commit -m "test: add signing"
# 署名の確認
git log --show-signature -1git log --show-signature の出力に以下が含まれれば成功：
gpg: Signature made ...
gpg: Good signature from "[email protected]"GitHubにpushしてコミット履歴を見たとき、コミットの横に「Verified」バッジが出ていれば完全に設定できている。
「Verified」が出ない場合は後述の診断フローへ。
allowed_signersの設定（ローカル検証用）
git log --show-signature で error: gpg.ssh.allowedSignersFile needs to be configured というエラーが出た場合は、ローカル検証用の設定が必要。
# ~/.ssh/allowed_signers を作成
echo "[email protected] ssh-ed25519 AAAA..." > ~/.ssh/allowed_signers
# gitconfigに追記
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signersここで一つ整理しておく。allowed_signers はローカル検証用のファイルで、GitHubの「Verified」表示とは直接関係がない。GitHub上の検証はGitHubサーバーサイドで行われる（Signing keyとして登録済みの公開鍵と照合）。allowed_signers は git log --show-signature でローカルに検証するためのもの。設定しなくてもGitHub上は「Verified」になれる。ただ設定しておくとローカルでも確認できて便利。
WSL2環境での追加設定
WSL2からGit署名を使う場合は、少し設定が追加で必要になる。
gpg.ssh.program のパスをWSL用のものに変更する必要がある：
# WSL2 用の gitconfig 設定
git config --global gpg.ssh.program "/mnt/c/Users/<USERNAME>/AppData/Local/Microsoft/WindowsApps/op-ssh-sign-wsl.exe"<USERNAME> は実際のWindowsユーザー名に置き換える。このパスはWindowsのMSIXパッケージ形式でインストールした場合のデフォルト。パスが見つからない場合は：
# Windows側でパスを確認
where.exe op-ssh-sign-wsl.exeまた、WSL2からSSH接続自体を1Password Agent経由にする設定も必要：
# ~/.ssh/config（WSL内）
Host *
IdentityAgent /mnt/c/Users/<USERNAME>/AppData/Roaming/1Password/agent.sockmacOSのソケットパスとは異なるので注意。WSL2環境でmacOS用の設定をそのままコピーした場合（D-2型）は、このパスのミスが原因で動かない。
agent.tomlで複数Vault・複数鍵を管理する
1Password SSH Agentに複数のSSHキーが入っている場合、デフォルトではすべての鍵がサーバーへの接続時に提示される。これを細かく制御するのが agent.toml だ。
ファイルパス：
- macOS/Linux:
~/.config/1Password/ssh/agent.toml - Windows:
%LOCALAPPDATA%/1Password/config/ssh/agent.toml
デフォルトではこのファイルは存在しない。作成するとSSH Agentの動作を上書きできる。
# 仕事用VaultのSSHキーをすべて公開
[[ssh-keys]]
vault = "Work"
# 個人用Vaultの特定キーのみ
[[ssh-keys]]
item = "Personal GitHub Key"
vault = "Personal"
# 特定のアカウントのキーのみ
[[ssh-keys]]
account = "[email protected]"使えるフィルター軸は vault（Vault名）、item（アイテム名）、account（1Passwordアカウントのメールアドレス）の3つ。TOML形式で、キー名はすべて小文字が必須。
重要な仕様が2点ある。
- ファイルを編集しても1Passwordの再起動は不要。agent.tomlは即時反映される
- セクションの順序 = サーバーへの鍵提示順序。複数の鍵がある場合、上から順に試される
フリーランスで複数クライアントのリポジトリを扱っている場合、[[ssh-keys]] のセクションをVault単位で分けておくと管理しやすい。
1Passwordのセキュリティ設計の考え方については1Password × AI Agentのセキュリティ設計も参照。
GitHubが「Unverified」になる12の原因——診断フロー
ここが記事の核。「Unverified」の原因をカテゴリA〜Dに分類して整理した。設定を終えてもVerifiedにならない場合は、上から順に確認すると原因にたどり着ける。
カテゴリA: GitHub側の設定（最多原因）
まずGitHub設定画面（Settings > SSH and GPG Keys）を確認することから始める。
A-1: Signing Key未登録
Authentication keyしか登録しておらず、Signing keyを登録していない。
- 確認: SSH keysの一覧に「Signing Key」タイプの項目があるか
- 修正: 同じ公開鍵を「Signing key」タイプで追加登録する
これが全原因の中で最多。「SSH接続は動いているのにVerifiedにならない」という状態のほぼ全件がここ。
A-2: 複数GitHubアカウントで鍵が違うアカウントに登録
個人アカウントに登録した鍵で会社アカウントへのリポジトリにコミットしている（またはその逆）。
- 確認:
git log --show-signatureでコミットのメールアドレスを確認し、どのGitHubアカウントに登録しているかを照合する - 修正: コミット対象のアカウントにSigning Keyを登録する
カテゴリB: メールアドレスのミス
カテゴリAに問題がない場合は、メールアドレスを確認する。
B-1: メールアドレスの大文字小文字不一致
GitHub登録: [email protected] / gitconfig: [email protected]
これが僕が踏んだやつだ。大文字小文字の違いだけで「Unverified」になる。1Password公式Docsにも明記されている地雷。
- 確認:
git config --show-origin user.emailでどのファイルにどの値が設定されているか確認 - 修正: GitHubのアカウント設定ページで確認したメールアドレスを、完全に同じ文字列でgitconfigに設定する
B-2: メールアドレス自体の不一致
gitconfigに設定しているメールアドレス自体が、GitHubアカウントのメールと異なる。
- 確認:
git config --show-origin user.emailの値をGitHub設定と照合 - 修正:
git config --global user.email "[email protected]"
B-3: GitHubの「メールアドレスを非公開にする」設定
GitHubでプライバシー設定として「Keep my email address private」をオンにすると、コミットには [email protected] 形式のnoreplyアドレスが使われる。
gitconfigに本来のメールアドレスを書いていると、署名の照合で使うメールが一致しない。
- 確認: GitHub Settings > Emails で非公開設定とnoreplyアドレスを確認
- 修正: gitconfigの
user.emailをnoreplyアドレスに変更するか、メール非公開設定をオフにする
カテゴリC: gitconfigの設定ミス
C-1: gpg.format が ssh でない（またはgpgのまま）
古い設定や別のツールの設定が残っている場合。
- 確認:
git config --show-origin gpg.format - 修正:
git config --global gpg.format ssh
C-2: gpg.ssh.program が未設定または間違い
- 確認:
git config --show-origin gpg.ssh.program - 修正（macOS）:
/Applications/1Password.app/Contents/MacOS/op-ssh-sign
App Store版とダイレクトダウンロード版でパスが同じかどうかは確認が必要。心配なら find /Applications -name "op-ssh-sign" 2>/dev/null で探す。
C-3: user.signingkey が未設定または無効な値
公開鍵の文字列が設定されていない、またはコメントや改行が混じっている。
- 確認:
git config --show-origin user.signingkey - 修正:
ssh-ed25519 AAAA...の形式で公開鍵を設定する。ssh-プレフィックスから始まる完全な文字列が必要
C-4: リポジトリローカルのgitconfig設定がグローバルを上書きしている
.git/config に古いGPG設定が残っていて、グローバル設定を上書きしているケース。
- 確認:
git config --show-origin --list | grep gpgでどのファイルから読まれているかを確認 - 修正: ローカル設定を削除するか、グローバルと一致させる
C-5: commit.gpgsign = false または未設定
自動署名がオフのまま。コミット時に -S フラグをつけたコミットだけVerfiedになり、普通のコミットはUnverifiedになる。
- 修正:
git config --global commit.gpgsign true
カテゴリD: 環境・バージョン問題
D-1: Git 2.34未満
SSH署名サポートは Git 2.34 から。それ以前のバージョンでは unsupported value for gpg.format: ssh というエラーが出る。
- 確認:
git --version - 修正: macOSなら
brew upgrade git。Homebrew版が入っていない場合はbrew install gitしてPATHを通す
D-2: WSL環境でmacOSのop-ssh-signパスを使っている
macOSの設定をWSLにコピーした場合に発生。/Applications/1Password.app/... というパスはWSL上には存在しない。
- 修正:
gpg.ssh.programをop-ssh-sign-wsl.exeのWSL用パスに変更する（WSL2セクションを参照）
D-3: allowed_signers の設定エラー
error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification というエラーが git log --show-signature で出る。
- 修正:
~/.ssh/allowed_signersを作成し、gitconfigのgpg.ssh.allowedSignersFileに設定する
繰り返しになるが、これはローカル検証用の設定であり、GitHub上のVerified表示には影響しない。
診断フロー（チェック順序）
問題が起きているときに確認する順序：
① GitHub Settings > SSH keysに「Signing key」タイプがあるか？
→ ない → A-1 を修正
↓ ある
② git config --show-origin user.email を実行。GitHubのメールと完全一致か？
→ 不一致 → B-1/B-2/B-3 を確認
↓ 一致
③ git config --show-origin gpg.format が "ssh" か？
→ 違う → C-1 を修正
↓ ssh
④ git config --show-origin gpg.ssh.program が設定されているか？
→ 未設定/間違い → C-2 を修正
↓ 正しい
⑤ git config --show-origin user.signingkey が設定されているか？
→ 未設定 → C-3 を修正
↓ 設定済み
⑥ git --version が 2.34 以上か？
→ 未満 → D-1 を修正この順番で確認すると、原因がどのカテゴリかに絞り込める。
認証キーと署名キーは同じでいいか——セキュリティの考え方
GitHubで同じ公開鍵をAuthentication keyとSigning keyの両方に登録することは技術的に可能で、多くの人がそうしている。これが安全かどうかを整理しておく。
同じ鍵を両方に使う場合
メリットは管理のシンプルさ。1つの鍵を1Passwordで管理すれば十分で、Signing key用に別のアイテムを作る必要がない。
リスクの側面から見ると：SSH接続用の秘密鍵が漏洩した場合（たとえば1Passwordアカウントへの不正アクセス）、攻撃者は署名用の鍵も手に入れることになる。過去のコミットに対して攻撃者が署名できる状態になる可能性がある。
ただし実際には、秘密鍵が漏洩した時点でSSH接続への不正アクセスも可能になるため、署名キーの独立性だけを担保しても攻撃面の縮小効果は限定的とも言える。
署名専用キーを分ける場合
GitHub以外のコードレビューシステムや、企業のコンプライアンス要件で「署名キーとアクセスキーを分離すること」と規定されている場合は分離が必要になる。
運用として分ける場合は、1Password内に「GitHub Auth Key」と「GitHub Signing Key」の2つのSSHキーアイテムを作成し、gitconfigの user.signingkey にSigning Key側の公開鍵を設定する。
結論
個人開発・小規模チームで1Passwordを適切に使っているなら、同じ鍵を両方に使っても実用上は問題ない。企業ポリシーや特定のコンプライアンス要件がある場合は分離を検討する、という判断基準で整理できる。
FAQ
Q1. 1Password 個人プランでもSSH Agentは使えますか？
使えます。SSH AgentはPersonal / Family / Business / Teamsすべてのプランで利用可能です。チームでVaultを共有したり、管理者レベルのアクセスログを見たりする場合はBusiness / Teams以上が必要ですが、SSH Agentと署名機能はPersonalプランで十分です。
Q2. git commit -S で署名しても GitHub上が「Unverified」のままです。
最初に確認すべきはGitHub Settings > SSH keys に「Signing key」タイプのキーが登録されているかどうかです（A-1）。次に git config user.email の値がGitHubに登録しているメールアドレスと完全一致しているか確認してください（B-1/B-2）。この2つで解決するケースが大半です。
Q3. WSL2では1Passwordの1Touchが使えないのですか？
WSL2からSSH Agentを使う場合、認証はWindows側の1Passwordアプリを経由します。WSL2のターミナルからSSH操作をすると、Windowsの通知としてTouch IDプロンプトが表示されます。WSL2内でネイティブなTouch ID認証は使えませんが、Windows側の1Passwordが起動していれば署名操作自体は問題なく動作します。
Q4. 複数のGitHubアカウント（個人・会社）を使い分けたいです。
agent.toml でアカウント別にVaultを分けて設定するのが整理しやすいです。gitconfigの includeIf ディレクティブを使ってディレクトリごとにgitconfigを切り替え、そのgitconfigで user.email と user.signingkey を対応するアカウントのものに設定する組み合わせが一般的です。
Q5. 既存のGPGキー（PGP）で署名している場合、1PasswordのSSH署名に移行すべきですか？
技術的にはどちらでも機能します。SSH署名のほうが設定が単純で、Vaultで管理しやすい点があります。GPG/PGPは既存のキーサーバー管理や有効期限管理が絡む場合、移行コストと恩恵を比較して判断してください。新規に始めるならSSH署名のほうがシンプルです。
Q6. allowed_signersはどんな場面で役立ちますか？
チームリポジトリのローカルコピーで git log --show-signature を使って、誰のコミットが誰の鍵で署名されているか確認したい場合に使います。チーム全員の公開鍵をallowed_signersに登録しておくと、ローカルで署名検証できます。GitHubの「Verified」表示はGitHub側が管理しているため、ローカルのallowed_signers設定とは独立しています。
関連記事
