【1Password移行③】Vault設計──最初に整理しておかないと後で詰む

1Passwordを使い始めるとき、最初にやっておくべきだったのに後回しにしてしまったことがあります。
それが「Vault設計」です。

最初は「とりあえず全部デフォルトVaultに突っ込めばいいか」と思っていたんですが、アイテムが増えてくるとカオスになってきました。
今回はその反省も込めて、設計の考え方を整理します。

Vaultとは

1PasswordのVaultは、アイテムをグループ分けするための「フォルダ」みたいなものです。
デフォルトでは「Private」というVaultが用意されていて、最初はそこにどんどん追加していくことになります。

個人プランなら複数Vaultを作れて、Vault単位でアクセス権限を管理することもできます。
チームプランだとメンバーへのVault共有もできますが、今回は個人利用の話です。

デフォルトのままだと何が起きるか

「Private」にだけ全部入れていくと、こんな状態になります。

• GitHubのSSHキーと、趣味のゲームのログイン情報が同じ場所にある
• AWSの本番アクセスキーと、ステージング環境のキーが見分けられない
• 「op://Private/GitHub/username」という参照パスが増えていくとVault名に意味がなくなる
• 100件超えたあたりで検索しないと目的のアイテムにたどり着けない

「全部1Passwordに入ってるから安全」は達成できてるんですが、「使いやすいか」は別の話でした。

Vault設計の考え方

いくつか試した結果、自分が落ち着いたのはこの3分割です。

Personal（個人）

仕事と関係ない個人のアカウント全般。
SNS、サブスクサービス、趣味のサービス等。
「仕事が終わっても必要なもの」が基準です。

Work（仕事）

仕事で使うサービスのアカウント。
Slack、GitHub、各種SaaSの認証情報等。
会社が変わったら不要になるものが基準です。

Infra（インフラ）

開発・インフラ系のシークレット。
SSHキー、AWSアクセスキー、APIトークン、DBパスワード等。
op run や op:// 参照でよく使うものをここに集める。

この分け方にした理由は、「op:// 参照パスを書くとき、Vault名に意味を持たせたかった」からです。

# こっちのほうが何を参照してるか分かりやすい
op://Infra/AWS-Prod/access-key-id

# Personal に全部入ってるとこうなる
op://Private/AWS-Prod/access-key-id

Vault名がドキュメントの役割を果たしてくれます。

アイテムのカテゴリ設計

1Passwordにはアイテムの「種類」がいくつかあります。
よく使うのはこのあたりです。

• Login：ユーザー名＋パスワードの組み合わせ（一般的なWebサービス）
• SSH Key：SSH秘密鍵の専用カテゴリ。SSH agentとの連携に使う
• API Credential：APIキーやトークン類
• Secure Note：フリーテキストで書けるメモ。複数のシークレットをまとめたいときに

SSHキーは必ず「SSH Key」カテゴリにしておくことで、SSH agentが自動的に認識してくれます。
「Login」に突っ込んでしまうとSSH agentに使えないので注意です。

命名規則もざっくり決めておく

アイテム名もある程度統一しておくと、op:// 参照パスが予測しやすくなります。
自分が使っているパターンはこんな感じです。

• SSHキー：SSH-GitHub、SSH-本番サーバー名
• AWSキー：AWS-アカウント名-環境名（例：AWS-MyProject-Prod）
• APIトークン：サービス名-Token（例：OpenAI-Token、Slack-Bot-Token）

完璧に統一できなくても、「だいたいこのパターン」くらいで十分です。
後から検索でたどり着けるなら問題ありません。

次回からいよいよ移行作業

Series Aはここまで。思想・設計編でした。

次の Series B からは実際の移行作業に入ります。
まずはSSHキーの移行から。~/.ssh/ にある鍵ファイルをまるごと1Passwordに移していきます。

今回は以上です！