--- title: "Keeper Commander CLIの使い方｜インストール・ログイン・主要コマンドとSSH鍵管理【v18.1対応】" url: "https://www.issoh.co.jp/tech/details/3685/" published: 2024-09-30 updated: 2026-09-29 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Keeper Commander CLIの使い方｜インストール・ログイン・主要コマンドとSSH鍵管理【v18.1対応】 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](https://github.com/Keeper-Security/Commander/blob/v18.1.6/keepercommander/command%5Fcategories.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 you@example.co.jp ``` 1コマンドで済ませるなら `keeper --server JP login you@example.co.jp` でも同じです。新しい端末では「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 svc@example.co.jp ``` 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-device ``` `this-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.csv ``` `run-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 password ``` `get` の `--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 login ``` bashやzshから1コマンドで実行する場合、`$GEN` を二重引用符で囲むとシェル変数として展開されて空になります。単一引用符で囲むのが確実です。どのフィールドを持てるかは `rti -lt <種別>`（record-type-info）で確認でき、ラベルに `.` や `=` を含むときの書き方は `record-add --syntax-help` に載っています。 ### share-record・share-folder・one-time-shareでの共有 個別レコードの共有は `share-record`、共有フォルダの権限は `share-folder`、Keeperアカウントを持たない相手への受け渡しは `one-time-share` を使います。 ``` share-record -e partner@example.co.jp -a grant -w --expire-in 7d "本番DB" one-time-share create "検証サーバー" -e 1h --output stdout ``` `share-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 -l ``` Windowsでは、KeeperのエージェントがOpenSSH標準と同じ名前付きパイプ（`\\.\pipe\openssh-ssh-agent`）で待ち受けます。同時に動けるのは片方だけなので、WindowsのOpenSSH Agentサービスが動いている場合は先に停止します。手順の詳細は公式の[SSH AgentのEnvironment Setup](https://docs.keeper.io/keeperpam/privileged-access-manager/ssh-agent#environment-setup)にあります。 ### Commanderのssh-agentとsshコマンド（Legacy） Keeper Desktopを入れられないサーバーでは、Commanderの `ssh-agent` が代わりになります。 ``` keeper ssh-agent start # 表示された行を別のターミナルで実行 export SSH_AUTH_SOCK=... ssh ec2-user@10.0.0.5 ``` 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 yes ``` `IdentitiesOnly 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のサービスアカウント運用](/tech/details/17930/)や[dotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順](/tech/details/12633/)が参考になります。 ## 管理者向けコマンド：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回は確認する運用が現実的です。 ## 関連記事 - [1Password CLIの使い方：op runでの秘密情報注入とCIのサービスアカウント運用](/tech/details/17930/) - [Bitwardenを組織で導入する手順：セルフホスト構築とSSO・SCIM・CLI連携を解説](/tech/details/17356/) - [HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説](/tech/details/15580/) - [OpenSSHとは？最新バージョンの確認方法とアップデート手順【2026年版】](/tech/details/10191/) - [dotenvxとは｜.envを暗号化してGitで安全に管理する仕組み・使い方・移行手順](/tech/details/12633/) --- 出典: [Keeper Commander CLIの使い方｜インストール・ログイン・主要コマンドとSSH鍵管理【v18.1対応】]()（株式会社一創）