個人でBitwardenを使うだけなら、アカウントを作って拡張機能を入れれば終わります。詰まるのは会社で配ったあとです。誰が何を見られるのかを分ける、退職者のアクセスを確実に止める、デプロイスクリプトから値を取り出す。この記事では、bitwarden.sh でのセルフホスト構築、クラウドで先に組織を作らないとライセンスが通らない制約、SAML 2.0とOIDCでのSSO構成、SCIMでの失効経路、そして bw コマンドでCI・CDへ値を渡すところまでを、公式ドキュメントの記載とコマンドで示します。
まとめ｜Bitwardenを組織で使う前に確定させる4つの前提条件
先に結論を並べます。ひとつ目は、セルフホストにできるプランが限られる点です。組織のセルフホストに関する公式ドキュメントには「Only Families and Enterprise organizations can be imported to self-hosted servers」と書かれています。Teamsプランを契約して自社サーバーへ持ち込む計画は、この一文で崩れます。
ふたつ目は、自社サーバーだけでは組織が完結しないことです。課金の都合上、組織はまずBitwardenのクラウドWebボルトで作成し、そこで得たライセンスファイルを自社サーバーへアップロードする流れになります。閉域網に置く構成でも、ライセンス同期のために globalSettings__enableCloudCommunication を有効にする前提が残ります。
3つ目はプラン境界です。ビジネス向けの料金ページでは、Teamsが年払いで1ユーザーあたり月額4ドル、Enterpriseが同6ドル。SCIMはTeams以上で使える一方、SSOの解説ページではSSOがEnterprise向け機能として説明されています。IdPログインを前提にするなら、検討の入口からEnterpriseで見積もることになります。
4つ目は守備範囲です。Bitwardenは人が使う認証情報の金庫であって、アプリケーションが実行時に取りに行くシークレットストアとは設計が違います。この線引きを曖昧にしたまま導入すると、あとでCI・CDの構成が歪みます。組織としてのパスワードポリシーの決め方そのものはパスワード管理のベストプラクティスの記事に整理しました。
セルフホスト構築の要件とbitwarden.shでのインストール手順
自社サーバーへ置く判断をしたなら、最初に確認するのはスペックとポートです。ここを読み違えると、動いた後にメモリ不足で落ちるか、証明書の取得で止まります。
最小2GB・推奨4GBのスペックとポート80と443の開放条件
Linux向けの標準デプロイ手順が示す最小構成は、x64の1.4GHzプロセッサ・メモリ2GB・ストレージ12GB。推奨はx64の2GHzデュアルコア・メモリ4GB・ストレージ25GBです。DockerはEngine 26以上が条件で、Composeはインストールスクリプトが入れます。開放するのは80番と443番の2つ。80番を閉じたままにすると、Let’s Encryptでの証明書発行が通りません。
データベースは既定でMSSQL Expressのコンテナが同梱され、外部のMSSQL 2019以上を指す構成も選べます。ユーザー数が数十人の規模なら同梱のままで足りますが、バックアップ運用を既存のDB基盤に寄せたい場合は外部指定にしておくほうが、あとの引き継ぎが楽になります。
インストールIDの取得からinstallとstartまでの実行コマンド
事前に https://bitwarden.com/host でインストールIDとキーを取得します。有効なメールアドレスが要り、この2つはインストーラの対話プロンプトで入力します。ドメイン名は後から変えると再設定が必要になるため、証明書と一緒に先に決めておいてください。
curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" && chmod 700 bitwarden.sh
./bitwarden.sh install
./bitwarden.sh start
./bitwarden.sh updateself
./bitwarden.sh updateinstall はドメイン・証明書の取得方法・インストールIDを順に聞き、./bwdata 配下に構成一式を展開します。start で各コンテナが起動。更新は2段構えで、updateself がスクリプト自身を、update がコンテナ群を上げます。サーバー本体の版はGitHubのリリース一覧で追え、実測時点では 2026.8 系が並んでいました。
global.override.envに書くSMTPとクラウド通信の設定値
起動しただけではユーザーを招待できません。招待メールがSMTP経由で飛ぶため、./bwdata/env/global.override.env を編集して再起動する工程が必ず入ります。
globalSettings__mail__smtp__host=smtp.example.co.jp
globalSettings__mail__smtp__port=587
globalSettings__mail__smtp__ssl=false
[email protected]
globalSettings__mail__smtp__password=CHANGE_ME
globalSettings__disableUserRegistration=true
globalSettings__enableCloudCommunication=true
[email protected]編集後は ./bitwarden.sh restart で反映します。disableUserRegistration を true にすると、招待された人以外の自己登録を止められます。社外に公開するホスト名で運用するなら、ここは先に閉じておくほうが安全です。adminSettings__admins に書いたアドレスだけが管理ポータルへ入れます。
クラウドで先に組織を作成しライセンスを持ち込む手順と料金の実額
セルフホストの構築が終わっても、この段階ではまだ個人ボルトが使えるだけです。共有コレクションもグループも、組織を有効にしないと出てきません。
Teamsが自社サーバーへ持ち込めない制約と回避できる選択肢
公式ドキュメントが対応対象としているのはFamiliesとEnterpriseです。Teamsは自社サーバーへインポートできません。つまり「安いTeamsを契約して社内サーバーに置く」という節約の筋は成立しないので、判断は次の2択に整理されます。
クラウド版のTeamsで運用し、サーバーの面倒を見ない。あるいはEnterpriseを契約して自社サーバーへ持ち込み、SSOやKey Connectorまで含めて統制する。1ユーザーあたり月額で2ドルの差ですが、100人なら年間で2,400ドルの差になります。ここは人数に掛け算して先に出しておくべき数字です。
ライセンスファイルの取得とアップロードで特に詰まりやすい確認箇所
手順自体は3ステップです。クラウドのWebボルトで組織を作る、組織の課金設定からライセンスをダウンロードする、自社サーバー側の管理画面でアップロードする。詰まるのは、クラウド側の組織とセルフホスト側のインストールIDが結び付いていないケースです。ライセンスはインストールIDに紐づいて発行されるため、サーバーを作り直してIDが変わったなら、ライセンスも取り直しになります。
もうひとつ引っかかるのが globalSettings__enableCloudCommunication です。閉域網に置く要件があると、ここを false のままにしがちですが、公式はライセンス同期に必要と明記しています。完全にオフラインで動かす構成では、期限切れの検知やサブスクリプションの反映が手作業になる点を運用設計に織り込んでください。
SSO連携をSAML 2.0とOIDCで構成するときの復号方式の判断
SSOを入れる目的は、社員に覚えさせる認証情報を減らすことです。ただしBitwardenのSSOには、他のSaaSにはない論点がひとつあります。ボルトの中身は端末側で復号する設計なので、IdPで認証が通っても復号鍵の出どころを別に決める必要があります。
マスターパスワードを残すかKey Connectorへ寄せるかの判断
既定の構成は、SSOでログインしたうえでマスターパスワードによる復号を残す形です。運用は素直で、失敗しても戻せます。一方、マスターパスワードそのものを社員から無くしたいならKey Connectorを使いますが、前提が重くなります。Enterprise組織であること、Dockerで配備したセルフホスト環境であること、そして稼働中のSSO実装があることの3つが要件です。
加えて、公式には「currently, there is not a way to re-create master passwords」と書かれています。一度マスターパスワードを外すと現状は戻せません。必要になるのは、暗号化済みユーザー鍵を保管するデータベース（MSSQL・PostgreSQL・MySQLなどから選択）と、鍵を暗号化・復号するRSA鍵ペア、そしてその鍵ペアの保管先です。保管先はHashiCorp Vault・クラウドのKMS・オンプレのHSMから選ぶ形で、公式自身が「専任チームとインフラを持つ企業にのみ推奨」と書いています。パスワードを外す方向の設計思想についてはパスワードレス認証の分類記事で方式ごとの実装難度を比較しました。
信頼済みデバイスによる復号を選ぶ条件と運用上の落とし穴への対策
Key Connectorの手前にあるのが、信頼済みデバイスによる復号です。一度承認した端末が鍵を保持し、新しい端末は既存の端末か管理者の承認で登録します。Key Connectorのような外部インフラを持たずにマスターパスワード入力を減らせるため、多くの組織にとってはこちらが現実的な着地点になります。
落とし穴は端末を全部失ったときです。承認できる端末が1台も残っていない状態では、管理者側での復旧手続きが必要になります。端末更改を一斉に行う運用をしているなら、旧端末を初期化する前に新端末を承認しておく順序を、手順書に明記しておいてください。IdP側の選定そのものはIDaaSの比較記事とシングルサインオンの実現方式の記事に整理しています。
SCIMでユーザーの招待と失効を自動化する連携の設定と前提条件
人の出入りが年に数人なら手動招待で回ります。数十人規模の異動が定期的に発生するなら、SCIMを繋いでIdP側の操作だけで完結させるほうが、退職者のアカウントが残る事故を減らせます。
対応する5つのIdPとグループ同期を使うための前提条件と設定範囲
SCIMの公式ドキュメントが挙げる対応IdPは、JumpCloud・Microsoft Entra ID・Okta・OneLogin・Ping Identityの5つです。利用条件はTeams以上の組織。管理コンソールの設定画面でSCIMを有効化し、発行されるSCIM APIキーとエンドポイントをIdP側のプロビジョニング設定へ入れる流れになります。
注意したいのが、グループへの割り当てです。公式は「Group provisioning must be used in order to assign synced users to groups」としています。ユーザーだけを同期してもコレクションの権限は付かないため、グループプロビジョニングを有効にして、Bitwarden側のグループとコレクションの対応を先に設計しておく必要があります。SCIMの仕様そのものはSCIMの解説記事にまとめました。
退職者のアクセスを止めるまでの経路と手動運用との実際の時間差
SCIMを繋いだ場合、IdP側でユーザーを無効化するとBitwarden側のアクセスも取り消されます。人事システムからIdPへの連携が組んであれば、退職処理の翌日には金庫の扉が閉まる状態になります。
ただし、閉まるのは「その人が今後アクセスできない」ところまでです。その人が既に見ていた共有パスワードは、頭の中にも手元のメモにも残り得ます。共有コレクションに置いた本番系の認証情報は、退職の都度ローテーションする運用とセットにしないと、失効の自動化だけでは守り切れません。ここはSCIMの設定ではなく、パスワード側の更新手順として書き下す領域です。
CLIとbw serveでCI・CDへ認証情報を渡す実装の手順と注意点
ここからが、個人向けの解説記事にはほぼ出てこない部分です。Bitwardenには公式のCLIがあり、スクリプトから値を取り出せます。ただし取り回しには癖があります。
APIキーでログインしBW_SESSIONを取り回すスクリプトの書き方
CLIの公式ドキュメントによれば、導入は npm install -g @bitwarden/cli のほか、Chocolateyの choco install bitwarden-cli、Snapの sudo snap install bw、ネイティブ実行ファイルの直接配置から選べます。自動実行では対話入力を避けたいので、メールとマスターパスワードではなくAPIキーでログインします。
export BW_CLIENTID="user.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
export BW_CLIENTSECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export BW_PASSWORD="master-password-here"
bw config server https://vault.example.co.jp
bw login --apikey
export BW_SESSION="$(bw unlock --passwordenv BW_PASSWORD --raw)"
bw sync
bw get password "deploy-db-prod"押さえどころは3点あります。bw login と bw unlock は別物で、ログインしただけではボルトは開きません。unlock が返すセッションキーを BW_SESSION に入れるか、各コマンドへ --session で渡す必要があります。そしてローカルのボルトはキャッシュなので、直前に更新した値を取るなら bw sync を挟んでください。セルフホスト構成では bw config server の指定を忘れると、クラウド側へ認証しにいって失敗します。
bw getとjqでパイプラインへ値を渡す最小の実装例と注意点
単一の値なら bw get password <名前> で足りますが、項目のカスタムフィールドや添付ファイルを扱うならJSONで取り出して jq で抜くほうが確実です。連続で叩く場合は bw serve でローカルにREST APIを立てると、都度の起動コストを避けられます。
bw list items --search "deploy" --session "$BW_SESSION" | jq -r '.[].name'
bw get item "$ITEM_ID" --session "$BW_SESSION" | jq -r '.login.password'
bw get item "$ITEM_ID" --session "$BW_SESSION" | jq -r '.fields[] | select(.name=="api_key") | .value'
bw serve --port 8087 --hostname 127.0.0.1 &
curl -s http://127.0.0.1:8087/list/object/items | jq -r '.data.data[].name'bw serve は待ち受けたポートに対して認証を要求しない点に注意してください。--hostname 127.0.0.1 を明示し、共有ランナーやマルチテナントのホストでは使わない前提にします。値の更新側は bw get template と bw encode を組み合わせ、bw edit item <id> へ流す形が公式の作法です。
GitHub Actionsのシークレットと併用する場合の役割分担
実務でよく起きるのが、CIのシークレットストアとBitwardenの二重管理です。切り分けの目安は単純で、人が日常的に開いて見る認証情報はBitwarden、ワークフローが自動で読むだけの値はCI側かクラウドのシークレットマネージャに置きます。
- name: Fetch secret from Bitwarden
env:
BW_CLIENTID: ${{ secrets.BW_CLIENTID }}
BW_CLIENTSECRET: ${{ secrets.BW_CLIENTSECRET }}
BW_PASSWORD: ${{ secrets.BW_PASSWORD }}
run: |
npm install -g @bitwarden/cli
bw config server https://vault.example.co.jp
bw login --apikey
export BW_SESSION="$(bw unlock --passwordenv BW_PASSWORD --raw)"
echo "DB_PASS=$(bw get password deploy-db-prod)" >> "$GITHUB_ENV"この書き方でも動きますが、結局CI側にAPIキーとマスターパスワードを預けることになります。ブートストラップの認証情報を1組に減らせるだけで、機密が減るわけではありません。自動更新の仕組みまで含めて考えるなら、AWS Secrets Managerのローテーションと料金の記事で比較した設計のほうが、パイプライン用途には素直に収まります。
Bitwardenを採用しない場面と他方式へ切り替える判断の基準
ここまでの内容を踏まえて、採用条件と見送る場面を言い切ります。判断の軸は機能の多寡ではなく、誰がその値を読むのかです。
アプリケーションのシークレット管理に使うべきでない具体的な判断条件
採用してよいのは、人が読む認証情報を組織で共有・失効させたい場合です。SaaSの管理者アカウント、取引先から渡された接続情報、共用のサーバー証明書のパスフレーズ。こうした「人の手を経由する」情報の管理では、SCIMによる失効の自動化まで含めて費用対効果が出ます。
見送るべきなのは、実行中のアプリケーションが動的に取得するシークレットを任せたい場合です。Bitwardenのボルトは端末側で復号するモデルで、動的シークレットの発行やリース期限による自動失効の仕組みを持ちません。データベース接続情報を都度発行して短命にしたいならHashiCorp Vaultの解説記事で扱った方式、クラウド上のIAMと統合したいならAWS Secrets Managerが担当領域です。自社プロダクト側の会員認証やID連携そのものを作り直す段階なら、認証基盤・ID管理システムの開発支援として認証方式の選定から実装まで引き受けています。
Vaultwardenを本番の社内基盤に置くかどうかの線引き
Rustで実装された互換サーバーのVaultwardenは、コンテナ1つで動き、公式サーバーが要求するスペックよりずっと軽い構成で立ちます。組織機能もライセンスなしで動く点が評価されがちです。
ただし社内の本番基盤として置くなら、条件を付けます。第一に、公式のサポート契約もSLAも付きません。第二に、公式サーバーの仕様変更に追従する保守は自分たちの仕事です。第三に、公式のライセンス体系を経由しない構成のため、監査でライセンス根拠を問われる調達要件とは相性が悪くなります。検証環境や小規模チームの実験なら妥当な選択ですが、退職者の失効を統制の一部として説明する必要がある組織では、Enterpriseを契約して公式サーバーで組む判断のほうが後の説明が短く済みます。
よくある質問
Bitwardenの組織導入で検索されている質問に、公式の記載を根拠に答えます。
Bitwardenのセルフホストは無料でできますか？
サーバーソフト自体はインストールIDとキーを取得すれば無償で立てられ、個人ボルトの範囲なら追加の費用は要りません。ただし共有コレクションやグループなどの組織機能を動かすにはライセンスが要り、自社サーバーへ持ち込めるのはFamiliesとEnterpriseだけです。組織で使う前提なら、無料でのセルフホストは選択肢に入らないと考えてください。
BitwardenのTeamsとEnterpriseはどちらを選ぶべきですか？
料金ページの記載では、年払いで1ユーザーあたりTeamsが月額4ドル、Enterpriseが月額6ドルです。IdPでのSSOログイン、Key Connector、自社サーバーへのライセンス持ち込みを使う予定があるならEnterpriseになります。SCIMによるプロビジョニングとディレクトリ同期だけならTeamsでも動くため、SSOを当面入れない組織はTeamsから始めて差し支えありません。
BitwardenのCLIでCI・CDのパスワードを取得できますか？
取得は可能です。bw login --apikey でAPIキーによる非対話ログインを行い、bw unlock --passwordenv が返すセッションキーを BW_SESSION に入れてから bw get password を呼びます。連続でアクセスするなら bw serve でローカルにREST APIを立てる方法もあります。ただし bw serve は待ち受け先に認証を要求しないため、127.0.0.1へ限定してください。
BitwardenとVaultwardenの違いは何ですか？
Vaultwardenは有志が開発している非公式の互換サーバー実装で、Rustで書かれ軽量なコンテナ1つで動きます。公式クライアントから接続でき、組織機能もライセンスなしで利用可能です。一方で公式のサポートとSLAは付かず、仕様変更への追従は自分たちの保守作業になります。監査でライセンス根拠が問われる環境では公式サーバーを選ぶほうが説明が簡潔です。
Bitwardenで退職者のアクセスを止められますか？
SCIMを繋いでいれば、IdP側でユーザーを無効化した時点でBitwarden側のアクセスも取り消されます。対応IdPはJumpCloud・Microsoft Entra ID・Okta・OneLogin・Ping Identityで、Teams以上のプランが条件です。ただし失効させても、その人が過去に閲覧した共有パスワード自体は変わりません。退職時のパスワードローテーションを別手順として用意しておく必要があります。
関連記事
- パスワード管理のベストプラクティス｜NIST最新指針と企業ポリシー設計を解説：ツール選定の前に決めるポリシー側を整理した記事です。
- SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装を解説：本記事のSCIM章の前提になる仕様を扱います。
- シングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説：SSO構成を決める前の方式比較に対応します。
- HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説：アプリケーション向けシークレット管理の対比先です。
- AWS Secrets Managerとは？料金・ローテーションと採用判断を実装者目線で解説：CI・CDから読む値の置き場所を検討する際の比較対象です。
- 二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断を解説：ボルト自体を守る認証方式の整理です。
