Keeper Commander CLIは、Keeperのパスワード保管庫（ボルト）と管理コンソールの機能をターミナルから操作するための公式ツールです。PyPIのパッケージ名は keepercommander、コマンド名は keeper で、2026年9月26日公開の18.1.6が執筆時点の最新版です。この記事では、インストールからログイン、レコード操作、SSH鍵の管理、スクリプトへのシークレット受け渡しまでを、18系の実際のコマンド定義と照合して説明します。
まとめ：Keeper Commander CLI 18.1の要点
- 導入はmacOSとWindowsなら公式のpkg／exe、Linuxはpip（
pip install keepercommander）。PyPI上の対応Pythonは3.8以上です。 - 日本のデータセンターを使う契約では、ログイン時に
--server JPを付けます。既定はUSです。 - 18.0.3以降、ログイン情報は既定でOSのキーチェーンに保存されます。サーバーやCIでは
--config-fileでconfig.jsonに切り替えます。 - スクリプトから毎回パスワードを聞かれないようにするには
this-device persistent-login onとthis-device registerを実行します。この設定はアカウントの全デバイスに及びます。 - Commander内蔵の
ssh・ssh-agentは18系でLegacy扱いになり、ヘルプ一覧から外れました。手元のSSH鍵管理はKeeper DesktopのSSHエージェントに寄せるのが公式の推奨です。 - アプリやCIに環境変数でシークレットを渡す用途は、Commanderではなく別パッケージのSecrets Manager CLI（
ksm exec）の担当です。
以下、導入手順から順に、つまずきやすい設定を具体的なコマンドとともに見ていきます。
Keeper Commander CLIの担当範囲とKeeperの他ツールとの違い
Commanderは「人がボルトと管理コンソールを操作する」ためのCLIです。ボルトのレコード操作に加え、企業テナントのユーザー・ロール管理、監査レポート、MSPの顧客テナント管理、KeeperPAMのゲートウェイ設定まで、管理コンソールの大半の操作を持っています。18.1.6で keeper help を実行すると、Record・Sharing・Reporting・MSP・Enterprise・KeeperPAMなどのカテゴリに分かれた数百のコマンドが表示されます。
一方、Keeperには用途の近いツールが複数あり、名前で混同されがちです。
| ツール | 配布 | 主な用途 | 認証の単位 |
|---|---|---|---|
| Keeper Commander | pip／pkg／exe | ボルト操作・管理者作業 | ユーザーのログイン |
| Secrets Manager CLI（ksm） | pip（1.5.0） | アプリ・CIへのシークレット注入 | KSMアプリのトークン |
| Keeper Desktop | 各OSのアプリ | GUIのボルト・SSHエージェント | ユーザーのログイン |
判断の軸は「誰が使うか」です。人が対話的に操作するならCommander、無人のプロセスが秘密情報を読むならksmを選びます。Commanderの資格情報をCIに置くと、その人のボルト全体をCIに預けることになるためです。
Keeper Commander 18系で変わった挙動
2026年5月1日の18.0.0以降、ネット上の解説記事と実際の挙動が食い違う箇所が出ています。古い手順どおりに進めて戸惑いやすいのは次の3点です。
ログイン情報の保存先がOSキーチェーンへ移行（18.0.3〜）
18.0.3のリリースノートに「OS-native keychain storage for Commander configuration」が追加され、現行ドキュメントも「By default, Commander stores login data in the native OS keychain」と書いています。新規にログインする場合、以前の解説にある「~/.keeper/config.json に保存される」は既定の挙動ではなくなりました。ファイル保存になるのは、--config-file を付けたとき、環境変数 KEEPER_CONFIG_STORAGE=file を設定したとき、18.0.3より前からの認証情報入りconfig.jsonを引き継いだとき（ソース上は勝手に移行しない作り）です。キーチェーンが使えない環境（Secret Serviceの無いヘッドレスLinuxなど）でも、自動でファイル保存に戻ります。
ssh・ssh-agent・connectがLegacyコマンドに分類
18.1.6のソース（command_categories.py）では ssh・ssh-agent・connect・rdp・rsync などが「Legacy Commands」に入り、keeper help の一覧には出てきません。コマンド自体は残っていて実行できますが、公式ドキュメントはSSH用途にKeeper DesktopのSSHエージェントかKeeperPAMを勧めています。18.1.0では connect のSSHプロキシ引数にシェルインジェクションの修正が入っており、使うなら最新版に上げておくべきです。
パスワードなど機微情報の既定マスクと解除オプション
18系のグローバルオプションには --unmask-all（既定のマスクを無効化）があり、get コマンドにも --unmask があります。値を画面に出したいときだけ明示的に外す設計なので、スクリプトでパスワードだけを取り出すなら後述の --format password を使います。
Keeper Commander CLIのインストール手順（macOS・Windows・Linux）
バイナリ版とpip版の選び分け
GitHub Releasesの18.1.6には、keeper-commander-mac-arm64-v18.1.6.pkg・keeper-commander-mac-x86_64-v18.1.6.pkg・keeper-commander-windows-v18.1.6.exe の3種類が置かれています。Linux向けのバイナリは無く、Linuxはpipでの導入になります。公式ドキュメントの対応OSは、macOS 10.15以降、Windows 11以降とWindows Server 2016以降、LinuxはUbuntu（現行版と最新LTS）・CentOS・RHEL・Rockyです。
Pythonを普段使わない端末ならバイナリ、スクリプトからCommanderをPythonライブラリとしても呼ぶならpipが向いています。公式は「We release updates weekly」としており、実際に18.1.1から18.1.6まで8月14日〜9月26日の約6週間で6回リリースされています。pip版は pip install --upgrade keepercommander で追従できます。
pipでのインストールとバージョン確認
システムのPythonとの衝突を避けるため、公式手順どおり仮想環境に入れます。
python3 -m venv keeper-env
source keeper-env/bin/activate
pip install keepercommander
keeper --version
# Keeper Commander, version 18.1.6仮想環境を使わず pip3 install --user keepercommander で入れた場合、macOSでは ~/Library/Python/<版>/bin にPATHを通さないと keeper が見つかりません。Windowsのexe版は管理者権限が必要で、ダウンロード後にファイルのプロパティで「ブロックの解除」が要る場合があると公式が注記しています。
ログインと認証情報の保存先
初回ログインとデバイス承認・JPリージョンの指定
Commanderの接続先は既定でUSデータセンターです。日本リージョン（keepersecurity.jp）で契約している場合、指定しないとアカウントが見つかりません。選べるのはUS・EU・AU・CA・JP・GOVの6つです。
keeper shell
Not logged in> server JP
Not logged in> login [email protected]1コマンドで済ませるなら keeper --server JP login [email protected] でも同じです。新しい端末では「Device Approval Required」と表示され、email_send（メールで承認コード）、keeper_push（他デバイスへのプッシュ通知）、2fa_send のいずれかで端末を承認します。
SSOと2FAのログインフロー
SSO（SAML 2.0）を設定した企業アカウントでは、ログイン時にSSOのURLが表示されます。o で既定ブラウザを開き、ログイン後に表示されるトークンをコピーして p で貼り付ける流れです。2FAを有効にしている場合はTOTPやFIDO2キーの選択肢が出ます。コードの前に 2fa_duration=forever または 2fa_duration=30_days を入力すると、その端末で2FAを聞かれる頻度を下げられます。macOSのTouch IDとWindows Helloは biometric register で登録でき、パスワードと2FAの入力を省略できます。
OSキーチェーンとconfig.jsonの使い分け
個人のPCでは既定のキーチェーン保存のままで問題ありません。サーバー・Docker・CIなどキーチェーンの無い環境では、--config-file を付けるか環境変数 KEEPER_CONFIG_STORAGE=file を設定してファイル保存にします。
keeper shell --config-file
# または
export KEEPER_CONFIG_STORAGE=file
keeper login --config-file [email protected]config.jsonの場所は、ソース（utils.get_default_path）上の優先順位で決まります。カレントディレクトリにconfig.jsonがあればそれを使い、無ければ --data-dir、環境変数 KEEPER_DATA_HOME、既存の ~/.keeper、OS標準のユーザーデータ置き場（macOSは ~/Library/Application Support/.keeper）の順に探します。--config や環境変数 KEEPER_CONFIG_FILE で明示すれば迷いません。
永続ログインで毎回のパスワード入力を省く設定
this-deviceの設定とtimeoutの単位
cronやバッチでCommanderを実行する際、認証の入力要求を避ける選択肢の一つが「永続ログイン（Stay Logged In）」です。ログイン後、最初の2行で永続ログインを設定し、続く2行でタイムアウトの設定と現在値の確認を行います。
this-device persistent-login on
this-device register
this-device timeout 7d
this-devicethis-device を引数なしで実行すると、Persistent Login・Device Logout Timeout・Enterprise Logout Timeoutなどの現在値が確認できます。timeoutの単位は y（年）・mo（月）・d（日）・h（時間）・mi（分）で、数字だけなら分として扱われます。10m と書くと「m is not allowed as a unit」でエラーになるので、10分なら 10mi です。1分未満を指定すると警告が出て既定値に戻ります。
永続ログインの影響範囲とconfig.jsonの使い回し
公式ドキュメントは、永続ログインを有効にするとそのアカウントのWebボルト・モバイル・デスクトップアプリにも「ログインしたまま」が及ぶと明記しています。この設定は他の端末にも影響しますが、自動ロックや非アクティブ時のログアウトが無効になることを意味しません。各端末のタイムアウト設定と管理者ポリシーも確認してください。自動化には専用のサービス用アカウントを作り、個人アカウントでは有効にしないでください。
もう1つの落とし穴が複製です。同じconfig.jsonを2台目の端末で使うと、両方のセッションが失効し永続ログインが壊れます。コンテナやサーバーに移す場合は、作成した元の端末からconfig.jsonを削除するよう公式が指示しています。
keeper shell・1コマンド実行・run-batchの使い分け
Commanderの実行形態は3つです。対話的に何度も操作するなら keeper shell でシェルに入り、My Vault> のプロンプトでコマンドを打ちます。18系には全画面のボルトブラウザ keeper supershell（vim風キー操作）もあります。
シェルスクリプトから1つだけ呼ぶなら、keeper の後にコマンドを続けます。複数のコマンドを順に流すときは、コマンドを1行1つ書いたファイルを run-batch に渡します。
keeper search "github" --format=json
keeper --batch-mode run-batch -d 2 nightly.txt
# nightly.txt（#で始まる行は無視される）
sync-down
password-report --format csv --output report.csvrun-batch の -d はコマンド間の待機秒数で、APIのスロットリング回避用です。-n を付けると実行せずに内容だけを確認できます。
レコードとフォルダを操作する基本コマンド
ls・tree・search・getでの検索と取得
ボルトはフォルダ階層になっていて、cd で移動し ls で中身を、tree で全体の構造を表示します。search は語順を問わない部分一致で、-c r でレコードだけ、-c s で共有フォルダだけに絞れます。
cd "Infra/Production"
ls -l
search prod db -c r
get "本番DB" --format passwordget の --format は detail・json・password・fields の4種類です。password はパスワードの値だけを出力するので、DB_PASS=$(keeper get "本番DB" --format password) のようにシェル変数へ受け取れます。
record-addのフィールド記法と$GENによる生成
レコードの作成は record-add で、-t にタイトル、-rt にレコード種別を指定し、フィールドを 種別=値 の形で並べます。$GEN を値に書くと、パスワードやTOTP、鍵ペアをCommanderが生成します。
record-add -t "本番DB" -rt login --folder "Infra" login=admin 'password=$GEN:rand,24' url=https://db.example.co.jp
record-add -t "検証サーバー" -rt login login=deploy 'password=$GEN:passphrase,6'
rti -lt loginbashやzshから1コマンドで実行する場合、$GEN を二重引用符で囲むとシェル変数として展開されて空になります。単一引用符で囲むのが確実です。どのフィールドを持てるかは rti -lt <種別>（record-type-info）で確認でき、ラベルに . や = を含むときの書き方は record-add --syntax-help に載っています。
個別レコードの共有は share-record、共有フォルダの権限は share-folder、Keeperアカウントを持たない相手への受け渡しは one-time-share を使います。
share-record -e [email protected] -a grant -w --expire-in 7d "本番DB"
one-time-share create "検証サーバー" -e 1h --output stdoutshare-record の --expire-in は期限付き共有で、--dry-run を付けると権限の変更内容だけを表示します。ワンタイム共有のURLは期限（-e）を必ず短く設定し、チャットに貼ったまま残さない運用にします。
SSH鍵の管理と接続：Keeper DesktopとCommanderのssh-agent
SSH鍵をKeeperに保存するレコード種別と形式
Keeper DesktopのSSHエージェントが鍵を認識するのは、レコード種別が「SSH Key」「Server」「PAM User」のいずれかで、Private Keyフィールドに有効な形式の鍵が入っている場合です。対応形式はPEM・OpenSSH（ssh-keygen の既定）・PKCS#8の3つで、パスフレーズ付きの鍵も扱えます。Commanderから新規に鍵を作るなら、SSH Key種別（内部名 sshKeys）で鍵ペアを生成します。
record-add -t "prod-web01" -rt sshKeys login=ec2-user 'keyPair=$GEN:ed25519' host=10.0.0.5:22生成した公開鍵は同じレコードのkeyPairフィールドに入るので、get "prod-web01" で表示して接続先の authorized_keys に登録します。秘密鍵はローカルのファイルに書き出さずに済みます。
Keeper DesktopのSSHエージェントを使う手順
Keeper Desktopの「設定 > 開発者（Settings > Developer）」でSSHエージェントを有効にし、使う鍵をドロップダウンで選びます。「Launch SSH Agent on startup」を選ぶとログインのたびに自動で起動します。ボルトがロック解除されている間に鍵を利用でき、鍵の使用時には承認が求められます。ただし「Don’t ask again」を選ぶと、その鍵に対する後続の要求を毎回承認する必要はなくなります。SSHエージェント機能は全Keeperユーザーが使えると公式が明記しており、Windows・macOS・Linuxに対応しています。GitHubへの認証やGitコミットへの署名にも使えます。
GUIで有効にしただけでは、ターミナルの ssh や git はKeeperのエージェントを見に行きません。macOSとLinuxでは、Keeperのエージェントが待ち受けるUnixドメインソケットを環境変数 SSH_AUTH_SOCK に設定します。ソケットのパスはKeeper Desktopの画面に表示されるものを使い、常用するならシェルの起動ファイル（~/.zshrc など）に書きます。
export SSH_AUTH_SOCK='/path/to/keeper-ssh-agent.sock'
echo $SSH_AUTH_SOCK
ssh-add -lWindowsでは、KeeperのエージェントがOpenSSH標準と同じ名前付きパイプ（\\.\pipe\openssh-ssh-agent）で待ち受けます。同時に動けるのは片方だけなので、WindowsのOpenSSH Agentサービスが動いている場合は先に停止します。手順の詳細は公式のSSH AgentのEnvironment Setupにあります。
Commanderのssh-agentとsshコマンド（Legacy）
Keeper Desktopを入れられないサーバーでは、Commanderの ssh-agent が代わりになります。
keeper ssh-agent start
# 表示された行を別のターミナルで実行
export SSH_AUTH_SOCK=...
ssh [email protected]18.1.6のソースでは、ssh-agent start はボルト内の全レコードを走査し、keyPairフィールド、秘密鍵用のシークレットフィールド、ノートの順にPEM形式の秘密鍵を探して読み込みます。ssh <レコード> は「SSH Key」か「Server」種別のレコードを指定して直接接続するコマンドです。どちらもLegacy扱いで、公式は直接接続（line-of-sight）向けと位置づけています。セッション記録や踏み台経由の接続が必要ならKeeperPAMの領域です。
SSH認証の試行上限と接続先ごとの鍵指定
SSHエージェントに鍵を多く載せると、「Too many authentication failures」で接続が切られることがあります。sshdの MaxAuthTries は既定で6で、エージェントは鍵を順に試すためです。Keeperの公式ドキュメントもこの制限に触れています。対策は ~/.ssh/config で接続先ごとに使う鍵を固定することです。
Host prod-web01
HostName 10.0.0.5
User ec2-user
IdentityFile ~/.ssh/prod-web01.pub
IdentitiesOnly yesIdentitiesOnly yes と公開鍵ファイルの IdentityFile を組み合わせると、エージェントが持つ鍵のうち該当する1本だけが提示されます（man ssh_configの記載どおり）。秘密鍵はKeeperに置いたまま、公開鍵だけをローカルに置けば済みます。
環境変数・シークレットをスクリプトへ渡す方法
チームで共有する .env の中身をKeeperに置き、スクリプトから読みたいという用途には、2つの方法があります。
手元で一時的に使うなら、Commanderの get --format password やJSON出力を使います。ただし、取得した値を .env ファイルに書き出すと平文のファイルが残り、Keeperに置いた意味が薄れます。
アプリやCIが継続的に読むなら、Secrets Manager CLI（PyPIの keeper-secrets-manager-cli、2026年8月13日公開の1.5.0はPython 3.10以上）の ksm exec を使います。環境変数に keeper:// 形式の参照を入れておくと、実行時に実際の値へ置き換えて子プロセスに渡します。値は子プロセスの環境変数に入るため、そのプロセスを検査できる同一ユーザーや管理者から読める可能性があります。
# Commander側：KSMアプリを作り、共有フォルダを割り当て、ワンタイムトークンを発行
secrets-manager app create ci-app
secrets-manager share add --app ci-app --secret <共有フォルダUID>
secrets-manager client add --app ci-app
# 実行環境側：Python 3.10以上の専用仮想環境で実行
python -m pip install keeper-secrets-manager-cli
ksm profile init --token XX:XXXXXXXX
export DB_PASSWORD="keeper://<レコードUID>/field/password"
ksm exec -- ./deploy.shこの例のKSMアプリが読めるのは割り当てた共有フォルダ内のレコードです。KSMでは個別のレコードをアプリに割り当てることもできます。KSM経由で取得できるKeeper内の情報は、アプリに割り当てた範囲に限定されます。ただし、取得された認証情報の権限によっては、接続先のDBやクラウドにも被害が及びます。同じ用途を他の製品で組む場合との比較は、1Password CLIの使い方：op runでの秘密情報注入とCIのサービスアカウント運用やdotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順が参考になります。
管理者向けコマンド：Enterprise・MSP・監査レポート・Service Mode
管理者権限のあるアカウントでは、管理コンソールの操作をスクリプト化できます。よく使うのは次のコマンドです。
| コマンド（別名） | 用途 |
|---|---|
| enterprise-info（ei） | テナントのノード・ユーザーを木構造で表示 |
| enterprise-user（eu） | ユーザーの追加・ロック・削除 |
| audit-report（ar） | 監査ログのレポート |
| compliance | コンプライアンスレポート |
| security-audit | パスワード強度などのセキュリティ監査 |
| msp-info（mi） | MSPの管理対象企業とライセンス |
| service-create | CommanderをREST APIサービスとして起動 |
レポート系は契約によって実行できるかどうかが変わります。公式ドキュメントでは、audit-report にARAM（Advanced Reporting & Alerts Module）、compliance にCompliance Reportingのアドオンが必要とされています。msp-info はMSP型のアカウントとMSP管理者権限が前提です。
Service Modeは、Commanderの操作をHTTPのAPIとして他システムから呼べるようにする機能です。18.1系ではService Modeの権限周りの修正が続いており、18.1.5ではLegacyコマンド経由の制限回避を塞ぎ、18.1.6では自身の設定レコードへのアクセスを遮断しています。Service Modeを本番で使うなら、少なくとも18.1.6に上げてください。
Keeper Commander CLIを使わない方がよい場面
Commanderは管理者と開発者の手作業を減らす道具ですが、次の使い方は避けるべきです。
- CIやアプリの本番ランタイムに、個人アカウントのconfig.jsonを置く使い方。ボルト全体が露出し、永続ログインが個人のスマホにも及びます。代わりにksmを使います。
- 永続ログイン用のconfig.jsonを複数のサーバーで使い回す使い方。同じ永続セッションを別サーバーで再利用すると失効し、バッチが認証できなくなります。
- 取得したパスワードをファイルやログに書き出す使い方。
--unmask-allを付けたままのログ収集も同じ問題を起こします。
数十人規模でパスワード共有をするだけなら、GUIのボルトとチーム機能で十分です。この用途でCLI導入の効果を判断するなら、繰り返し作業の自動化や、管理コンソールでは手間のかかる一括操作があるかを基準にします。
Keeper Commander CLIに関するよくある質問
Keeper Commander CLIは無料で使えますか？
Commander本体はGitHubで公開されているOSSで、PyPI上のライセンスはMITです。ただしCommanderはKeeperアカウントを操作するツールなので、ボルトの機能はアカウントの契約プランに従います。Enterprise・MSP・KeeperPAM系のコマンドは、その機能を契約し、管理者権限を持つアカウントでないと実行できません。
Linuxでも使えますか？
使えます。公式の対応OSはUbuntu（現行版と最新LTS）・CentOS・RHEL・Rockyで、Linux向けのバイナリは無いためpipで入れます。デスクトップ環境の無いサーバーではOSのキーチェーンが使えないので、--config-file か KEEPER_CONFIG_STORAGE=file でファイル保存を選び、config.jsonのパーミッションを絞ってください。
keeper shellとkeeperコマンドの直接実行はどう違いますか？
keeper shell は一度ログインして対話シェルに入り、続けて複数のコマンドを打つ形態です。keeper ls のように直接実行すると、そのコマンドだけを実行して終了します。スクリプトから呼ぶ場合は直接実行か run-batch を使い、永続ログインを設定しておくとパスワードを聞かれません。
KeeperのSSHエージェントはどこで有効にしますか？
Keeper Desktopアプリの「設定 > 開発者」画面で有効にします。対象の鍵をドロップダウンで選び、「Launch SSH Agent on startup」で自動起動にできます。デスクトップアプリを入れられないサーバーではCommanderの ssh-agent start が使えますが、18系ではLegacyコマンドの扱いです。
Keeper Commanderのバージョンを確認・更新するには？
keeper --version か、シェル内で version を実行します。pipで入れた場合は pip install --upgrade keepercommander で更新し、バイナリ版はGitHub Releasesから新しいpkg／exeを入れ直します。公式は毎週の更新を案内しており、セキュリティ修正も含まれるため、月に1回は確認する運用が現実的です。
