1Password CLIがVPSのSSHで固まる・毎回サインインを求められる原因 — Service Accountsは個人プランでは使えない話【2026年版】
VPSにSSHしてClaude Codeを動かす時、1Password CLIのop signin/op runが固まる・毎回パスワードを求められる問題を整理。原因は生体認証がSSH越しに届かないこと。Service Accountsでの解決策と、個人・Familyプランでは使えない制約、現実的な回避策まで書いた。
※ 本記事には1Passwordのアフィリエイトリンクが含まれています。記事内リンクから申し込みがあった場合、筆者に紹介報酬が発生します。内容は独自調査に基づいており、報酬によって評価が変わることはありません。 #PR
エンジニアのゆとです。
VPSにSSHで入ってClaude Codeを動かす。よくある構成だ。で、そのVPS上で1Password CLIを叩いてAPIキーをVaultから取ろうとすると、op signinがやたら固まったり、op runのたびにマスターパスワードを聞かれたり、聞いたこともない認証タイムアウトのエラーが出たりする。
これ、ローカルMacで1Password CLIを使っていた人ほど戸惑う。ローカルではTouch IDでスッと通っていたものが、SSH越しだと急に不安定になる。
この記事では、なぜVPS/SSH環境だと1Password CLIの認証が引っかかるのか、Service Accountsという「本命の解決策」がなぜ個人・Familyプランのユーザーには使えないのか、そして個人プランのまま現実的にどう回避するかを整理した。CI/CDパイプラインの話ではなく、フリーランスが自分のVPSにSSHして対話的にClaude Codeを使うケースに絞って書いている。
この記事の対象 — CI/CDではなく「対話的SSH利用」
先に住み分けをはっきりさせておく。
1Password CLIをGitHub ActionsのようなCI/CDパイプラインで自動実行する話は、別記事の「1Password CLI × Claude Code で .env を Vault化する完全ガイド」で扱っている。あちらはサービスアカウントトークンをGitHub Secretsに登録して、人間が介在せず完全自動でシークレットを注入する構成が前提だ。
この記事が扱うのはそれとは別のシナリオで、「毎日SSHでVPSに入って、Claude Codeと対話しながらコードを書く」という、人間が能動的に操作する開発スタイルの話だ。この場合、CI/CDのように完全headless自動化する必要はなく、代わりに「毎回の認証がいちいち面倒」という別の困りごとが発生する。
VPS上でClaude Codeを動かす前提や環境構築自体は、「Hostinger VPS に Claude Code を入れて開発環境を1時間で作る」で書いた通り。この記事はその先、「シークレット管理で1Password CLIを使おうとしたら詰まった」というピンポイントの話になる。
症状 — 3パターンに整理できる
VPS上で1Password CLIを使おうとして詰まる症状は、実はざっくり3パターンに分けられる。
パターン1: 毎回パスワードを求められる
$ op run --env-file=.env.vault -- python script.py
Enter the password for [your-email] at my.1password.com:セッションが切れるたびに、Emailとシークレットキーとマスターパスワードの入力を求められる。1Passwordの公式コミュニティでも「op signinが毎回パスワードを要求してくる（VS Code Tunnel経由のheadless Linuxボックスで）」という報告がある。
これは実は「壊れている」わけではない。デスクトップアプリとの生体認証連携がない環境では、CLIは素のアカウント認証（Email + Secret Key + Master Password）にフォールバックする。それが仕様通りに動いているだけ、というのがこのパターンの正体だ。
パターン2: 認証タイムアウトで固まる
[ERROR] authorization prompt timed outこれは1Passwordコミュニティでも「Windows Helloなしの環境でSSH Agentがタイムアウトする」という報告や、「authorization timeout when using CLI」という別スレッドが立つほど、それなりに件数のある症状だ。
原因は、CLIが「デバイスの生体認証確認」を待とうとして、待てど暮らせど応答が返ってこないまま一定時間でタイムアウトすること。SSH越しのリモート環境には生体認証センサーもデスクトップアプリの通知UIも存在しないので、待っても永遠に応答は来ない。
パターン3: サインイン自体がハングする
コマンドが返ってこず、Ctrl+Cで止めるしかない状態。1Passwordの生体認証チェーンの一部（D-Bus・Polkit・システム認証フレームワークなど）がLinux環境で正しく構成されていないと起きる。VPSのようなミニマル構成のLinuxディストリビューションでは、そもそもこれらのコンポーネントが入っていないことも多い。
原因 — 生体認証チェーンはSSH越しに届かない
3パターンとも根っこは同じで、1Password CLIの「デスクトップアプリ統合」機能が、ローカルマシンの生体認証ハードウェア（macOSならTouch ID、WindowsならWindows Hello、LinuxならSystem authentication）を前提に設計されているせいだ。
ローカルMacでopコマンドを叩くと、裏で1Passwordデスクトップアプリに認証リクエストが飛んで、Touch IDで指をタッチすると通る。この一連の流れは同じマシン内で完結しているから成立する。
ところがVPSにSSHで入ってopコマンドを叩くと、認証リクエストの送り先が「今操作しているSSHセッションの向こう側」ではなく「VPSというマシンそのもの」になる。VPSにはTouch IDセンサーもデスクトップアプリもない。だから生体認証は原理的に成立しようがなく、CLIは別の認証手段（素のパスワード認証、あるいはタイムアウト）に頼らざるを得ない。
「WSL2から1Passwordが使えない」という似た症状もあるが、あれは同一物理マシン内でWindows側のデスクトップアプリと連携できる可能性がある分、まだ状況がマシだ。VPSは物理的に別のマシンなので、ローカルの生体認証と原理的に橋渡しする方法がない。
本命の解決策 — Service Accounts、ただし個人・Familyプランでは使えない
CI/CDや自動化用途で1PasswordがVPS/headless環境向けに公式に用意しているのが、Service Accounts（サービスアカウント）というトークンベースの認証方式だ。生体認証を一切使わず、OP_SERVICE_ACCOUNT_TOKENという環境変数1つで認証が完結する。
# ローカル（1Password Business管理画面）でサービスアカウントを作成
op service-account create "VPS Claude Code" \
--expires-in 90d \
--vault Development:read_items
# 発行されたトークンをVPS側の環境変数に設定
export OP_SERVICE_ACCOUNT_TOKEN="ops_xxxxxxxxxxxxxxxx"
# サインインなしでいきなり使える
op read "op://Development/Anthropic API/api_key"これだけ見ると理想的な解決策に見える。実際、CI/CDの文脈では標準的な方法だ。
ただしここに大きな制約がある。Service Accountsは1Password TeamsまたはBusinessプランでしか作成・管理できない。個人向けのIndividualプラン、家族向けのFamilyプランでは、CLIのop service-account createコマンド自体が使えない。
さらに、Service Accountsがアクセスできるのは共有Vault（Shared Vault）だけで、個人用のPersonal VaultやFamilyプランのPrivate/Employee Vaultにはそもそもアクセスできない設計になっている。つまり「個人プランのままBusiness機能だけつまみ食いする」という抜け道も存在しない。
フリーランスエンジニアが個人契約で1Passwordを使っているケースは多いはずで、「VPSでClaude Codeを自動化したいからService Accountsを」と思って調べても、そもそもプランの壁で門前払いされる、というのがこの話の一番地味に厄介なポイントだ。
記事が見つかりません:
個人・Familyプランでの現実的な対処
Business/Teamsに上げる予定がないなら、次の3つの選択肢で現実的に折り合いをつけることになる。
対処A: 素のアカウント認証を受け入れる（一番シンプル）
VPS側では「デスクトップアプリとの統合」をそもそも試みず、Email・Secret Key・Master Passwordでの認証に統一する。
# VPS上で1Password CLIをアカウント追加
op account add --address my.1password.com --email you@example.com
# 以降はセッションが切れるたびにパスワード入力
op signin生体認証を使わない分、体験としては地味だが、確実に動く。セッションのデフォルト有効期限は30分程度なので、頻繁に打鍵作業が発生するのが唯一のデメリット。
対処B: セッションタイムアウトを伸ばす
セッション切れの頻度そのものを下げる方向の対処。
# 環境変数でセッションタイムアウトを延長
export OP_SESSION_TIMEOUT=7200 # 120分または1Passwordアプリ側の「セキュリティ > 自動ロック」設定でロック時間を調整する。これだけで「毎回パスワードを打つストレス」はかなり軽減できる。1回のSSH作業セッションが2時間以内に収まるなら、実質1回のサインインで作業を終えられる計算になる。
対処C: サードパーティのSSHフォワーディングツール（存在は知っておく）
コミュニティには、ローカルマシンのTouch ID認証をSSHトンネル経由でリモート側に中継する、op-forwardのようなオープンソースツールも存在する。ローカル側で小さなHTTPデーモンを立てて、リモート側のopコマンドを透過的にフォワードする仕組みだ。
存在は知っておく価値があるが、正直に書くと自分はまだ実運用で試せていない。シークレットの受け渡しをサードパーティのツールに任せる構成になるので、採用するなら「誰が作っていて、どういう経路でトークンが流れるか」を自分で読んでから判断してほしい。VaultへのアクセスをトンネリングするツールはVault漏洩のリスクと直結する部分なので、便利さだけで飛びつく場所ではない。
結論 — 自動化するならBusiness、対話的に使うだけなら個人プランで十分
整理すると、判断基準はシンプルだ。
Claude CodeをVPS上でsystemd常駐させて完全自動化したい、複数人のチームでVaultを共有したい、なら素直にBusinessプランへの移行を検討する価値がある。Service Accountsによる完全headless認証は、その用途では投資対効果が高い。
一方で「自分ひとりが、たまにVPSにSSHして対話的にClaude Codeを使う」だけなら、個人プランのままで十分回る。対処A・Bの組み合わせ（素のアカウント認証＋セッションタイムアウト延長）で、多少の不便を飲み込めば実用上困らない。
僕自身は今のところ後者のスタイルで、Businessプランに上げるほどのニーズはまだない。VPS作業が週に数回程度なら、2時間セッションで足りることがほとんどだ。
関連記事
FAQ
Q1. VPSに1Passwordデスクトップアプリをインストールすれば解決しますか？
しません。多くのVPSはGUIのないヘッドレス環境なので、そもそもデスクトップアプリ自体をインストールできないか、インストールできても意味のある形で生体認証センサーと連携できません。デスクトップアプリ統合は「同じマシンにTouch ID等のハードウェアがある」ことが前提の機能です。
Q2. Service Accountsを個人プランで使う裏技はありますか？
現時点ではありません。op service-account createはTeams/Businessプランのオーナー・管理者権限が必要なコマンドで、CLIレベルでプランを判定してブロックしています。個人プランのままVaultだけBusinessプランに移行することもできないため、Service Accountsが必要なら契約プラン自体の変更が必要です。
Q3. 1Password Connect Server（セルフホスト）なら個人プランでも使えますか？
Connect ServerもBusiness以上のプランで提供される機能です。個人プランでの完全headless自動化という文脈では、現状Service Accountsと同じ壁にぶつかります。
Q4. WSL2でも同じ問題が起きますか？
起きますが、事情は少し違います。WSL2は物理的に同じWindowsマシン上で動いているため、Windows側の1Passwordデスクトップアプリと連携できる可能性があります。VPSは物理的に別マシンなので、この橋渡しの選択肢自体がありません。
