第20章：自作 vs Extensions の分岐点（ここが判断ライン⚖️）＋ランタイム表🧩⚙️
この章のゴールはこれ👇 「Extensionsで秒速導入 → でも、いつ自作に切り替えるべきか？」を“迷わず”決められる状態にすることだよ😎✨ （2026-02-20 時点の最新ドキュメントを参照して整理してるよ）(Firebase)
0) まず結論：判断のコアは “3つのコスト” 💸🧠🧯
Extensions は「最小メンテで動く」「必要な権限だけを付与する」思想で作られてて、インストール前に 有効化されるAPI / 作られるリソース / 付与権限 / 課金要件 を確認できるようになってるよ🧩🔍(Firebase)
でも、合わない時は合わない🙂 迷ったら、次の 3つのコストで比べるとブレない👇
- 開発コスト：仕様がExtensionに“そのまま”乗る？（乗らないなら自作が有利）
- 運用コスト：トラブル時に原因追える？更新・設定変更が怖くない？🪵
- 将来コスト：ロックイン・仕様変更・AIモデル変更に耐えられる？🔁
1) 10分で作れる「判断シート」テンプレ⚖️🧾
まずこれを1枚作ると、以後ずっとラクになるよ✨
| 観点 | Extensionsが勝つサイン🧩 | 自作が勝つサイン🛠️ | 自分の判定 |
|---|---|---|---|
| 要件フィット | ほぼそのまま使える | 例外が多い / 特殊な分岐が多い | ✅/❌ |
| 変更したい度 | パラメータ調整で十分🎛️ | ロジック改造が必要 | ✅/❌ |
| 障害対応 | ログ/リトライの方針が想像できる | 失敗時の“復旧手順”が組めない | ✅/❌ |
| セキュリティ | 付与権限が納得できる🔐 | 権限が強すぎて怖い | ✅/❌ |
| コスト | 使い方が単純で読みやすい💸 | トラフィック次第で読めない | ✅/❌ |
| ロックイン | 代替が効く / 乗り換え可能 | Extension依存のデータ構造になる | ✅/❌ |
| AI絡み | モデル/仕様変更に耐えられる🤖 | モデル差し替えが頻繁に必要 | ✅/❌ |
✅が多いほど Extensions、❌が多いほど自作寄り。 “引っかかった❌の数” が、だいたい判断ラインになるよ😆
2) 判断のための「公式チェックポイント」3つ🔍🧩
ここはガチで効くやつ👇（公式のインストール導線にそのまま入ってる）
(A) インストール時に表示される “仕様レビュー” を読む インストール中に APIs enabled / resources created / access granted / billing requirements を確認する画面が出るよ。ここを見ずに入れるのは危険⚠️(Firebase)
(B) “付与権限（サービスアカウント）” を納得するまで見る Extension は専用のサービスアカウントに必要なロールを付けて動く。 そして重要ポイント：そのサービスアカウントのロールを勝手に変更しないでね、って公式に書かれてる（動かなくなる原因になる）🛡️(Firebase)
(C) 更新・再設定・アンインストールの性質を知る
- Update：更新すると Extensionが作ったリソースやコードが上書き される（でも instance ID とサービスアカウントは基本そのまま）🔁
- Reconfigure：設定変更もできる（反映に数分かかることがある）🎛️
- Uninstall：削除可能（ただしデータや作成物の扱いは要注意）🧯(Google Cloud Documentation)
ここまで見れば「Extensionsで行けるか / 自作が安全か」がかなりハッキリするよ🙂
3) 迷ったら使う “二択フローチャート” 🧭⚖️
次の質問に YESが2つ以上なら、自作を強く検討🛠️
- Q1：ロジックを改造したい（パラメータじゃ足りない）？
- Q2：処理の失敗時に「自分のアプリの要件に合う復旧」をしたい？（例：部分成功、手動承認、再実行のUI…）
- Q3：データ構造がExtension依存になりそう？（将来の乗り換えが痛い）
- Q4：コストが読めない（大量イベント・画像・AI呼び出しで跳ねそう）？
- Q5：権限が強すぎると感じる？（最小権限にできない）(Firebase)
逆に、次が当てはまるなら Extensions が超強い🧩✨
- “よくある機能” で、仕様が典型パターン
- まず 最短で動くものを出したい
- 運用を軽くしたい（自分の保守ポイントを減らしたい）(Firebase)
4) 具体例で腹落ち：Resize Images はどこまでExtensionsでいける？📷➡️🖼️
Extensionsが向く（例）😆
- サムネ生成が固定（例：200x200、400x400）
- 命名ルールが単純
- 「アップロード → 生成 → 保存」だけでOK
自作が向く（例）🛠️
- 顔検出してトリミングしたい🙂
- 画像ごとに可変サイズ（ユーザー設定で無限）
- 透かし、モザイク、複数派生、キュー制御…など“処理パイプライン”化したい
- 失敗時に「後でやり直す」「管理画面で再生成」みたいな運用が必要
ポイントはね、**“画像処理そのもの”じゃなくて、周辺要件（運用・例外・再実行）**が増えた瞬間に自作が勝ち始める、ってこと😎
5) 「まずExtensions → 後で自作」へ逃げ道を作る🏃♂️💨
Extensionsを採用するなら、最初から“逃げ道”を用意すると安心だよ🧠
逃げ道の作り方（おすすめ）👇
-
入出力の契約を固定する
- Firestoreのフィールド名、Storageのパス規則などを “自分のアプリ側のルール” にしておく
-
Extensionの生成物を「中間生成物」として扱う
- 例：
thumb/は “今はExtensionが作るけど、将来は自作が作っても同じ場所に置く”
- 例：
-
設定（パラメータ）を記録しておく（後で再現できるように）🧾
- manifest で管理すると、環境差分を潰しやすい(Firebase)
6) 再現性の切り札：Extensions manifest で「設定をコード化」📦🧾
“人間の手作業”だと、いつか必ずズレる😂 manifest を使うと、Extensionsの構成や設定を エクスポートして再現できるよ（CLIで扱える）💻✨(Firebase)
Windows（PowerShell）の雰囲気例👇
## いま入ってる拡張の構成を manifest として書き出す（例）
firebase ext:export
## ローカルに入れる（まだデプロイしない）例：--local
firebase ext:install --local <publisher>/<extension-name>
## （ローカル評価後に）manifest から本番へ反映…みたいな運用につなげやすい
※コマンドの役割（export / install --local / configure / update）がまとめて説明されてるよ(Firebase)
7) “試すだけ”でも注意：Extensions Emulator は万能じゃない🧪⚠️
Extensions Emulator は 本番を汚さずに評価できるのが最高なんだけど、拡張によっては 実際のAPIを呼ぶケースがある（＝課金や外部影響の可能性）ので、そこだけは要注意だよ🧯(Firebase)
8) AI時代の追加ルール：AIが絡むなら「モデル寿命」も判断材料🤖📅
AI系のExtensionsやAI Logicを絡めるときは、モデルの提供状況・置き換えやすさが超重要🧠
たとえば Firebase AI Logic のドキュメントには、特定モデル（例：Gemini 2.0 Flash / Flash-Lite）が 2026-03-31 に retire予定、みたいな明確な期限が書かれてる。 こういうのがあると「将来モデル差し替えが必要 → 自作の方が柔軟」って判断になることもあるよ⚖️(Firebase)
さらに、ログ読解や原因切り分けは AI が強い💪
- Firebase コンソール上の Gemini in Firebase で、エラーやログの理解を支援できる
- 生成AIで環境構築や雛形作成をラクにする動きとして、
firebase initで AI 連携をセットアップする流れも公式に出てるよ（Gemini CLIの話題もここに絡む）🛸💻(Firebase)
9) ランタイム目安（2026）📌⚙️
「自作に切り替える」となった時に困りがちなのが“何のランタイムで書く？”問題。ここを表で固定しちゃおう😆
Cloud Functions for Firebase（Firebase側）
- Node.js：22 / 20（18はdeprecated）(Firebase)
- Python：
firebase.jsonでランタイム指定できる（例：python310/python311など）(Firebase)
Cloud Run functions（Google Cloud側。多言語で書きやすい）
- Node.js：24 / 22 / 20 など（runtime ID も明記）(Google Cloud Documentation)
- Python：3.14 / 3.13 / 3.12 …(Google Cloud Documentation)
- .NET：8（ほか 10 なども記載）(Google Cloud Documentation)
迷ったら：TypeScript/Nodeで揃える → どうしても必要になった時だけ .NET / Python へ、が事故りにくい👍
手を動かす🖐️（この章のワーク）🧾⚖️
- Extensions Hub で、気になる拡張を1つ選ぶ🧩
- インストール画面で出る APIs enabled / resources created / access granted / billing requirements をメモ📝(Firebase)
- さっきの「判断シート」を✅/❌で埋める
- ❌が2つ以上なら「自作にした場合の設計メモ」を3行で書く（例：入出力、再実行、ログ）
ミニ課題🎯
「拡張で行く or 自作にする」判断を1つ確定して、理由を **“3つのコスト（開発/運用/将来）”**で説明してみてね😆