1Passwordの保管庫共有をフリーランスエンジニア視点で整理する——案件ごとの分離と契約終了時の即時剥奪
1Passwordの保管庫共有機能を、フリーランスエンジニアがクライアント案件でDB接続情報やAPIキーを扱う実務視点で整理。保管庫を案件ごとに分ける設計、契約終了時にアクセスを即座に切る方法、1Password非ユーザーとの安全な共有(Psst!)まで解説。
※ 本記事にはプロモーションが含まれています。記事内リンクから申し込みがあった場合、筆者に紹介報酬が発生します。内容は独自調査に基づいており、報酬によって評価が変わることはありません。 #PR
エンジニアのゆとです。
フリーランスで複数のクライアント案件を並行してやっていると、DBの接続情報・APIキー・サーバーのSSH鍵といった機密情報を、Slackやメールで平文のまま送られてくることがまだある。逆に自分から渡す側になったとき、案件が終わった後もその情報がクライアントの手元に残り続けているのも気持ちが悪い。
1Passwordの「保管庫（Vault）共有」機能はこの問題への回答になるはずだが、検索してヒットする記事のほとんどは個人・家族向けの一般的な使い方か、企業の情報システム部門向けの管理者ガイドのどちらかで、「フリーランスが単発の案件ごとにアクセス範囲を分けて、契約終了と同時にきれいに切り離す」という粒度の話は手薄だった。今回はその視点で整理する。
前提: 「アイテム共有」と「保管庫共有」は別物
1Passwordには機密情報を他人と共有する方法が2種類あり、まずここを混同しないことが重要になる。
| 方式 | 何を共有するか | 向いている場面 |
|---|---|---|
| アイテム共有（Psst!含む） | ログイン項目1件だけ | 単発でパスワード1つだけ渡したい、相手が1Password非ユーザー |
| 保管庫共有 | フォルダ単位で複数アイテムをまとめて | 案件が続く間、DB接続情報・APIキー・SSH鍵など複数の機密情報を継続的に共有する |
案件単位で複数の機密情報を扱うフリーランスの実務では、後者の「保管庫共有」を基本線にした方が管理コストが低い。アイテムを1つずつ共有すると、案件終了時に「渡した項目を全部覚えていて、1つずつ共有解除する」羽目になる。保管庫ごと権限を切れば、それだけで案件に紐づく全項目へのアクセスが一括で切れる。
案件ごとに保管庫を分ける設計
自分がやっている運用は単純で、クライアント1社（または1案件）につき保管庫を1つ作るというルールだけを徹底している。
Personal（自分専用、非共有）
├── クライアントA案件
│ ├── DB接続情報（staging/production）
│ ├── AWS APIキー
│ └── デプロイ用SSH鍵
├── クライアントB案件
│ └── ...「全案件共通の開発ツール」用に別の保管庫を1つ作ることはあるが、それ以外は基本的に案件＝保管庫で1対1にする。理由は単純で、権限管理の単位が保管庫だからだ。項目を細かく分けたところで、共有の可否は保管庫単位でしか制御できない。案件をまたいで保管庫を共用すると、片方の案件が終わったときに「この項目はどの案件のものだったか」を思い出しながら個別削除する作業が発生し、消し忘れがそのままセキュリティリスクとして残る。
保管庫の作成自体は数クリックで完了する。
- 1Passwordアプリまたは1Password.comで「新規保管庫」を作成
- 保管庫名をクライアント名や案件名で分かるように命名（自分は
[クライアント名]_[開始年月]の形式にしている） - 招待するメンバーのメールアドレスを指定し、アクセス権限を選択して共有
アクセス権限は「編集者」ではなく用途で選ぶ
保管庫を共有する際、1Passwordは権限レベルを細かく設定できる（Business/Teamプラン）。フリーランスがクライアントと共有する場合に迷いやすいのがここで、基本方針は「相手が実際にその情報を更新する必要があるか」で決める。
- 閲覧のみ（View Items）: クライアント側の担当者が本番DBの接続情報を確認したいだけなら、これで十分。誤って値を書き換えられるリスクを排除できる
- 編集可能（Edit Items）: 双方でパスワードのローテーションを担当する運用なら必要になるが、フリーランス⇔クライアント間では基本的に不要なケースが多い
- 管理者（Manage Vault）: 保管庫のメンバー招待・削除まで相手に委ねることになるため、自分が窓口である限りは付与しない
案件開始時に「相手は見るだけでいいのか、それとも更新もするのか」を最初に決めておくと、後から権限を絞る面倒な調整が発生しにくい。
契約終了時にアクセスを即座に切る
フリーランスの実務で一番効くのがここだ。案件が終わったとき、渡した機密情報へのアクセスをどう終わらせるかには2つの選択肢がある。
- 保管庫からメンバーを削除: 保管庫自体はそのまま残り、相手のアクセス権だけが失われる。案件終了後も自分側で情報を参照し続けたい場合はこちら
- 保管庫ごとアーカイブ・削除: 案件データそのものが不要になった場合はこちら。ただしBusinessプランでは削除前に監査ログで最終アクセスを確認できる
見落としやすいのは、APIキーやDB接続情報自体は1Password側で無効化されるわけではないという点だ。1Password側のアクセス権を切っても、相手が事前にキーの値をメモしていれば、そのキー自体は生き続ける。契約終了時のチェックリストとしては、1Password側のメンバー削除と同時に、クラウド側（AWS IAMキーのローテーション、DBパスワードの変更など）も必ずセットで行う必要がある。1Password共有の解除は「アクセスの窓口を閉じる」だけであって、「値そのものを無効化する」機能ではないことを理解しておくと事故を防げる。
1Password非ユーザーのクライアントと共有する（Psst!機能）
保管庫共有は双方が1Passwordを使っている前提の機能だが、クライアントによっては1Passwordを導入していないことも珍しくない。この場合に使えるのが「Psst!」と呼ばれる単発共有機能で、相手のアカウント有無に関係なく、有効期限付きのリンク1本で機密情報を渡せる。
- 共有リンクには自動で有効期限（最短1時間〜最長30日）とアクセス回数の上限を設定できる
- 受け取り側は1Passwordアカウント不要でブラウザから閲覧できる
- リンクを開いた形跡はアクティビティとして送信側から確認できる
これは案件開始時にクライアントから初期パスワードを1回だけ受け取る、あるいは自分から初期のステージング環境URLとパスワードを1回だけ渡す、といった単発のやり取りに向いている。逆に、案件期間中ずっと更新が発生するDB接続情報などは、有効期限が切れるたびに再送する手間が発生するため、前述の保管庫共有の方が向いている。
SSH鍵・API連携との組み合わせ
保管庫共有はUIからの手動操作を前提にしているが、フリーランスエンジニアの場合はSSH鍵の管理やCLIからの機密情報取得と組み合わせる場面の方が多い。案件ごとに保管庫を分けていれば、op CLIやSSH Agent連携でも保管庫名を指定して対象を絞り込める。
op item list --vault "クライアントA案件"このように保管庫単位でスコープを切れることが、案件ごとに保管庫を分離しておく設計のもう一つの利点になる。SSH鍵をコミット署名にまで使う設定や、Claude Code側からシークレットを安全に読み出す設定は別記事にまとめてある。
複数の機密情報管理サービスと比較検討している場合は、こちらの比較記事も参考になる。
Businessプランなら監査ログで「誰がいつアクセスしたか」を残せる
個人・ファミリープランには存在しないが、Businessプランには保管庫ごとのActivity Logがある。誰がいつその保管庫のアイテムを閲覧・編集・共有したかが記録されるため、クライアントから「本当に必要な担当者だけがアクセスしていたか」を問われた場合の説明材料になる。
フリーランス1人で契約している場合はIndividualプランで十分なケースが多いが、複数のクライアントと同時並行で機密情報を扱う量が増えてきたら、監査証跡が残せるBusinessプランへの切り替えを検討する価値がある。
FAQ
保管庫を共有すると、共有相手は他の保管庫の中身も見られますか
見られない。1Passwordの保管庫は独立した単位で、共有した保管庫の中身だけが相手に見える。自分のPersonal保管庫や、他クライアントの保管庫は完全に隔離されている。
クライアントが1Passwordの有料プランに入っていなくても保管庫を共有できますか
共有される側（招待されるメンバー）が同一のFamily/Businessアカウント内にいる必要はあるが、単発の情報共有だけなら前述のPsst!機能でアカウント自体が不要なケースもある。継続的な保管庫共有を行いたい場合は、招待する側・される側どちらかが対応プランに入っている必要がある。詳しい条件は案件開始前に公式サポートで確認するのが確実。
保管庫から削除したメンバーは、それまで見ていた情報を今も持っている可能性がありますか
ある。1Passwordのアクセス権削除は「これから見られなくする」機能であり、それまでにコピー・メモされた値までは遡って消せない。契約終了時は1Password側の権限剥奪と同時に、対象のパスワードやAPIキー自体をローテーションすることが安全側の運用になる。
案件ごとに保管庫を分けると管理する保管庫の数が増えすぎませんか
増える。ただし、それは「消し忘れ」というリスクをなくすためのトレードオフだと考えている。案件が完全に終了して不要になった保管庫はアーカイブしてしまえば一覧には表示されなくなるので、運用中の保管庫数が際限なく増え続けるわけではない。
まとめ
1Passwordの保管庫共有は、フリーランスエンジニアが複数クライアントの機密情報を並行して扱う上で「案件ごとにアクセス範囲を物理的に分離できる」点が一番効く。案件＝保管庫で1対1にしておけば、契約終了時のアクセス剥奪も保管庫単位の操作1つで完結する。
ただし1Password側のアクセス権を切ることと、実際のパスワード・APIキーを無効化することは別問題だという点は忘れずに。契約終了時のチェックリストには、必ずクラウド側でのキーローテーションもセットで入れておきたい。
1Passwordをまだ使っていない場合は、14日間の無料トライアルから保管庫共有を試してみるのが早い。
