OpenShipの鍵管理：2026年の保存先選び

OpenShipの鍵管理は、通常のAI API Keyなら環境ごとに分離できるプラットフォームのSecrets Vaultを優先し、サーバーの起動やSSH接続に必須の基盤用資格情報だけを対象サーバー側で管理するのが安全です。自社運用のサーバーに.envを置く場合も、リポジトリ、Dockerイメージ、ログ、クライアント用バンドルへ流出しないことを確認し、輪換後に新しい鍵で通信できるところまで検証してください。

症状：コードには鍵を書いていないのに、生成したイメージやログからAPI Keyが見つかる。
最速解決：現在のファイルだけでなく、Git履歴、イメージ層、ビルド出力、クライアントバンドルを調べ、発見した鍵は先に無効化します。

この判断が必要な人

OpenShipで初めてモデルAPI Keyを公開する個人開発者は、まずGitへの登録を止める必要があります。プレビュー、テスト、本番を管理する小規模チームは、環境変数の混在と権限の広がりを分けて考えてください。

本番リリースを担当する技術責任者は、鍵を保存する場所だけでなく、誰が変更できるか、いつ輪換したか、障害時に誰が再承認できるかまで決めておく必要があります。

最初に止める：鍵がコードの外へ漏れる経路

「ソースコードに書いていないから安全」は成立しません。たとえばDockerfileで ARG や ENV に鍵を渡すと、最終イメージに残る可能性があります。Docker公式資料も、ビルド引数や環境変数をビルド用の秘密情報に使わず、ビルドシークレットを利用するよう説明しています。 (docs.docker.com)

OpenShipの公開説明では、ビルドは手元のマシンまたはクラウド側で行われ、本番サーバーは生成済みのイメージを受け取る構成とされています。ただし、これは「アプリ実行時の鍵がイメージへ入らない」ことを自動的に保証する説明ではありません。鍵をビルド工程へ渡す必要がある場合は、実行時用の鍵と分離してください。 (openship.io)

確認する場所は次の順番です。

リポジトリの現在のファイルと過去のコミット履歴
Dockerfile、ビルド引数、キャッシュ、生成済みイメージの各層
CI/CDの出力、デバッグログ、失敗時のスタックトレース
NEXT_PUBLIC_ など、ブラウザーへ送られる変数
ソースマップ、静的ファイル、フロントエンドの生成物

Gitから文字列を削除しても、すでに漏れた鍵は使われ続ける可能性があります。先に無効化または輪換し、その後に履歴を整理するのが基本です。GitHubの公式手順でも、秘密情報を履歴から消す前に鍵を失効・輪換するよう案内されています。 (docs.github.com)

注意：本番用のモデル鍵をプレビュー環境の動作確認に流用しないでください。利用額だけでなく、プロンプトや顧客データが本番系へ到達する経路まで共有されます。

次に分ける：プレビュー、テスト、本番の環境変数

OpenShipの公式ページでは、Secrets Vaultについて暗号化保存、環境単位の管理、再デプロイなしの輪換、監査ログを案内しています。ただし、クラウド、セルフホスト、ハイブリッドのどの形で利用しているか、契約や現在のバージョンでどこまで使えるかは、管理画面と実環境で確認してください。公式説明を、そのまま自社環境で検証済みの安全機能とみなすべきではありません。 (openship.io)

プレビュー環境と本番環境で別の鍵を使うにはどうするか。

変数名を同じにしても、値の保存範囲を環境ごとに分けます。プレビューでは利用上限の小さい検証用API Key、テストではテスト用データベース、本番では本番専用の鍵を割り当て、プレビュー用の設定を複製するときに本番値が含まれないことを確認してください。

管理方法	環境分離	変更履歴・監査	事故時の責任
OpenShipの環境変数・Secrets Vault	管理画面の環境範囲に依存	機能と契約範囲を要確認	プロジェクト管理者と公開基盤の双方
サーバーの`.env`	ファイルとホスト単位で分離	自分で記録しない限り残らない	サーバー管理者
外部のSecrets Vault	ポリシー単位で分離しやすい	取得、変更、失効を記録しやすい	秘密情報管理者と実行環境

サーバーの.envは、アプリが起動する場所に近い一方、バックアップ、シェル履歴、構成管理、権限設定に管理漏れが生じやすい方式です。OpenShipの環境変数はチームで扱いやすい反面、管理画面の閲覧権限を持つ人、デプロイ権限を持つ人、クラウド側の運用者を分けて確認する必要があります。

サーバーの.envとプラットフォームの鍵管理は何が違うか。

前者は「そのホストに置いたファイルを誰が読めるか」が中心で、後者は「環境、プロジェクト、チーム権限、デプロイ経路をどう分けるか」が中心です。小規模な単一サービスならサーバー側でも成立しますが、プレビューと本番が増え、担当者が交代するなら、環境単位の管理と監査証跡を優先した方が運用しやすくなります。

輪換は保存ではなく、通信確認まで行う

「管理画面で保存済みになった」だけでは、API Keyの交換は完了していません。新しい値が実行中のプロセスへ渡ったか、既存のコンテナが古い値を保持していないか、旧鍵を失効してもリクエストが正常に処理されるかを確認します。

モデルAPI Keyの交換に再デプロイは必要か。

OpenShipは公式説明で、Secrets Vaultの鍵を再デプロイなしで輪換できるとしています。しかし、アプリが起動時にだけ環境変数を読み込む設計なら、プロセス再起動やローリング更新が必要になる場合があります。したがって、必要条件は「再デプロイ不要」という表示ではなく、新しいリクエストが新鍵で成功することです。 (openship.io)

輪換方式	長所	失敗しやすい点	合格条件
旧鍵を新鍵で直接上書き	操作が少ない	再起動前後で値が混在する	新旧の使用状況を確認できる
新旧鍵を一時併用	切り戻ししやすい	旧鍵の失効忘れが起きる	新鍵を確認後、旧鍵を失効する
外部Vaultから再取得	監査と分離を設計しやすい	取得権限や通信障害が増える	取得失敗時の復旧手順がある

OWASPは、鍵の作成、適用、テスト、完了という段階を分け、最小権限、失効、利用履歴を管理する考え方を示しています。輪換手順は次の順序に固定してください。 (cheatsheetseries.owasp.org)

新しいAPI Keyを発行し、権限と対象環境を確認します。
OpenShipまたは外部のSecrets Vaultへ新しい値を登録します。
アプリのヘルスチェックや実際の推論リクエストで新鍵を検証します。
実行中のプロセス、ワーカー、定期ジョブが新しい値を使っているか確認します。
旧鍵を失効し、失効後のリクエストが意図どおり拒否されることを確認します。
失敗した場合に戻せる期限と担当者を記録します。

権限を決める：閲覧、変更、公開、監査を分離する

チーム全員に鍵の閲覧権限を与える必要はありません。開発担当者は検証用環境の変更、リリース担当者は本番への反映、管理者は権限変更と監査確認というように、役割を分けます。

OpenShipの料金・機能表では、環境によってOwner、Admin、Deployer、Viewerなどの役割や、監査ログの保持範囲が異なると説明されています。また、MCPやAPIトークンは付与された権限の範囲で動作する設計が案内されています。これは有効な判断材料ですが、現在の契約、インストール版、クラウド版で実際に同じ入口が表示されるかは、権限テストで確認してください。 (openship.io)

役割	許可する操作	原則として許可しない操作
開発	プレビューの変数変更、動作確認	本番鍵の閲覧、失効
リリース担当	本番変数の反映、デプロイ、ロールバック	チーム全体の権限変更
管理者	メンバー、環境、監査設定の管理	日常的な鍵の直接利用
監査担当	変更履歴、利用記録、復旧記録の確認	鍵の値そのものの閲覧

MCP経由でAI Agentに操作させる場合は、管理者の個人トークンを渡さず、読み取り専用または対象プロジェクトだけに絞ったトークンを発行します。公式ドキュメントでも、トークンごとに利用可能なツールと対象範囲を制限できると説明されています。 (openship.io)

障害復旧を先に試す：バックアップと鍵を混同しない

アプリのデータを復元できても、起動に必要な鍵が戻らなければサービスは再開できません。逆に、秘密情報のバックアップを平文で保存すると、復旧用ファイルそのものが新しい漏えい経路になります。

復旧対象を次の3種類に分けて記録してください。

アプリデータ：データベース、オブジェクト、アップロードファイル
プラットフォーム設定：プロジェクト、環境名、デプロイ定義、権限
秘密情報：モデルAPI Key、データベース認証情報、SSH鍵、署名鍵

OpenShipのクラウド機能ではバックアップやポイントインタイム復旧が案内されていますが、セルフホスト環境では保存先、暗号化、復元担当者を自分で決める必要があります。バックアップが存在することと、秘密情報を安全に再承認できることは別の確認項目です。 (openship.io)

経験則：復旧テストでは、バックアップからサービスを起動するだけでなく、旧鍵を失効した状態から新鍵を登録し、誰がどの権限で再開できるかを確認してください。

最終判断：三層に分ければ迷いにくい

秘密情報の種類	推奨保存先	理由
モデルAPI Key、メールAPI Key	OpenShipの環境別Secrets Vault	アプリ環境とデプロイ操作をまとめて管理しやすい
SSH鍵、ホスト管理用トークン	対象サーバーまたは外部Secrets Vault	基盤アクセスとアプリ設定を分離できる
短期トークン、高感度の本番資格情報	外部Secrets Vaultを中心に分離	失効、監査、承認、復旧を独立させやすい

次のチェックを、初回公開前と輪換後の両方で実行します。

[ ] 本番鍵がGit履歴、Dockerfile、イメージ層に存在しない
[ ] フロントエンドへ送る変数とサーバー専用変数を分離した
[ ] プレビュー、テスト、本番で値と権限を分けた
[ ] 開発、公開、管理、監査の操作を別のアカウントで試した
[ ] 新鍵で実際のAPIリクエストが成功した
[ ] 旧鍵を失効しても、必要な処理を新鍵で継続できた
[ ] ログに鍵の全文が出ていない
[ ] サーバー障害後に、秘密情報を平文で戻さず再承認できる
[ ] OpenShipの現在の環境範囲、権限入口、監査機能を実画面で確認した

初めての運用では、Macstripeのヘルプセンターで接続方式や作業分担を確認し、構築担当者と公開担当者のアカウントを分けてください。遠隔のビルド環境を使う場合は、Macstripeの構成注文ガイドも参照し、秘密情報を個人の共有フォルダーへ集めない運用にします。

サーバーの.envだけに頼る方式は、環境の複製、担当者の交代、変更履歴、障害復旧で手作業が増えます。特にAI SaaSでは、プレビューと本番の鍵を混ぜたまま公開する事故や、個人のAPI Keyをチームで使い回す問題が起こりやすいため、アプリ用の鍵をOpenShip側または外部Vaultへ分け、基盤用資格情報だけを対象環境に残す方が管理しやすくなります。

Macstripeのレンタル環境を使う場合も、鍵を預ければ終わりではありません。ビルド端末の接続時間、担当者の権限、納品物への秘密情報混入、輪換後の再接続手順を分離して確認してください。短期の検証環境や一時的なビルド端末が必要なら、固定サーバーを増やすより、権限を限定したMacstripeの環境を使い、作業終了後にトークンを失効する運用が現実的です。

Macstripeの日本語トップから利用形態を確認し、長期運用では自社管理、短期検証ではレンタルというように、鍵の重要度と環境の寿命に合わせて選んでください。