ビルド後はここを見る：Expoダッシュボードでの最新ビルド特定とキー管理の基礎

CLIでビルドし、社内配布やストア公開の準備が進むと、「ダッシュボード側で何を確認・管理すべきか」が次の課題になります。

どのビルドが最新？失敗の原因は？
アプリのSlug/ID/Ownerはどこで確認？
ストア提出用の署名鍵（credentials）は安全に管理できている？

本記事は、すでにビルド・テスト公開を経験した人向けに、Expo公式サイト（Dashboard）へログインしたあとに見るべき画面とポイントを運用視点で整理します。スクリーンショットに近いUIを前提に、メニューの意味・確認項目・トラブル時の導線までをやさしく解説します。

Projects（プロジェクト一覧）
Recent activity（最近のビルド履歴）
Project詳細（Slug/ID/Owner）
1. Credentials
Environment variables / Members / Billing（補足）
まとめ（記事末尾用）
外部リンクの候補

Projects（プロジェクト一覧）

Expoにアクセス。

目的：アプリ単位で全体状況を素早く把握し、詳細に潜る入口にします。
画面の読み方

カード（例：qr-app / calc）
- サムネ・アプリ名のほか、直近のビルド結果（例：Android build completed 19 days ago / failed 1 month ago）が一行で分かります。
New projectボタン
- 新規作成の入口。既存運用中は誤操作防止のため権限設計を見直すと安心です。

Recent activity（最近のビルド履歴）

Expoにアクセス。

Build（ビルド）
その行のビルド結果と種類。左のアイコンで成功/失敗、その下にビルド名（例：Android Play Store build）とバージョン/ビルド番号（例：1.0.0 (2)）が表示。
※ここで（「Android」＝対象のOS」）（「Play Store」＝配布先）「版数はいくつか」を判断します。
Commit（コミット）
そのビルドを作ったソースコードのコミットID（短縮ハッシュ）。
※「どの変更を含むビルドか」を特定し、リポジトリの履歴と突き合わせます。

Profile（プロファイル）
ビルドプロファイル（例：production）。ビルド設定の束の名前で、証明書やフラグが紐づく。
※本番用か検証用かの判定に必須。誤配布の有無をここで確認。
① よく使う3つ
development：開発・デバッグ用（実機で動作確認を素早く回す）
preview / internal：限定配布・QA用（社内/テスター向け）
production：本番配布・ストア提出用
➁厳重に全て使用する場合は、development → internal → preview → staging → production の順で試すと良いです。
Runtime（ランタイム）
実行時ランタイムの指定。画像の例ではNone（特定のRuntime指定なし）。
※特殊なランタイム/SDKを使う構成かどうかの確認に使います。
※種類
None：未設定。Updatesの互換判定を使わない状態。
SDK連動（policy: “sdkVersion”）：sdk-51 のように Expo SDK に連動。
アプリ版連動（policy: “appVersion”）：1.0.0 など アプリのバージョンに連動。
カスタム固定文字列：任意の文字列（例：rn-2025-q3）。手動で切り替える運用。
Channel（チャネル）
配信チャネル（リリースレーン）。例ではNone。Updatesを活用している場合はproduction/preview等が入る。
※どの利用者群に配ったか（配信レーン）を判定します。

運用チェック

「失敗表示」が赤帯で出ていないか。出ていればRecent activityへ直行して原因を追います。
テスト用・本番用でカードが乱立してきたら、命名規約（app-name-envなど）を揃え、Pin Projectや説明文で見分けやすくします。

Project詳細（Slug/ID/Owner）

プロジェクトに入ると、冒頭に以下が並びます。

Slug：アプリの一意な短名。EAS設定やリンクで使われます。プロジェクト名／app.json(app.config)から決まる。
ID：内部的な識別子。問い合わせや自動化で参照することがあります。Expo側が自動採番で決まる。
Owner：所有アカウント（個人 or 組織）。公開・権限管理の起点になるため、誤りがないか必ず確認します。アカウント作成時に決まる。
Pin Project：よく使うプロジェクトを上部固定。運用効率が上がります。

ベストプラクティス

Slugは途中変更の影響が大きいので、初期のうちに最終形へ寄せる（calc, qr-app など簡潔で不変名）。
Ownerは個人→組織へ早めに移行すると、鍵や請求の属人化を防げます。

Credentials

Expoにアクセス。

Expo/EAS 側で指紋を取得（アップロード鍵の元）

手順（Dashboard）
- 対象のProjectを選択。
- 左のメニューから、Credentialsを選択。

該当のパッケージ名（例：com.myproject.qrapp）を選択します。
画面に表示される、Android upload keystoreから、 SHA-1 / SHA-256 をコピーして控える

Google Play Console 側で指紋を取得

Google Play Consoleにアクセス。

手順（Console）
1. Expoで確認したパッケージ名（例：com.myproject.qrapp）を基に、該当アプリを開く。
2. 左のメニューから、テストとリリース → アプリの完全性（App integrity）を選択。

Play アプリ署名↠設定を選択。

ページ内の 「アップロード鍵の証明書（Upload key certificate）」 セクションで
SHA-1 / SHA-256 をコピーして控える

先ほど控えたExpo側の値と、SHA-1/256 が一致していれば、Play Console の Upload key と Expoの Android keystoreが同一であることを確認できます。以上でチェック完了です。

※本画面には互換表示としてMD5/SHA-1/SHA-256が出ます。確認はSHA-1/SHA-256で行えば十分です。MD5は参考情報です。

Environment variables / Members / Billing（補足）

Environment variables：APIキー・エンドポイント・フラグを環境ごとに切替。Expo UpdatesやCIと組み合わせると配布後の挙動制御が楽になります。
Members：ロール（管理者/開発者/閲覧）を明確化し、最小権限を徹底。
Billing/Receipts：課金の透明性を確保。部署横断で使うなら請求書のダウンロード運用を決めておきます。

まとめ（記事末尾用）

本記事では、ビルド後にダッシュボードで何を確認するかを、運用視点で整理しました。
まず Projects で対象アプリを特定し、Project詳細（Slug/ID/Owner） を控えて参照情報を固定します。次に Recent activity／Builds を使って 最新の成功ビルド を特定し、表示される バージョン／ビルド番号／Commit／Profile を記録します。最後に Credentials を開き、Expo側（Android keystore）と Google Play Console（Upload key） の SHA-256 を照合して、同じ鍵で署名できているかを確認します（MD5は参考表示で判断不要です）。
補足として Environment variables／Members／Billing を定期点検しておくと、権限や課金、機密情報の事故を未然に防げます。