続きです。全てのシリーズはこちら
※本記事は「技術解説編」です。先に公開したユーモア中心の「おちゃらけ版」とは若干時系列が異なるため、シリーズでお読みいただくと理解が深まるかと思います。
■Render環境下での開発を断念
Renderは最初こそ、ビジュアル的でUIもシンプルなため、とっかかりは楽でした。
しかし使い込んでいくとわずか１週間で制約だらけなことで開発が止まることが繰り返されることになってしまいました。
このままRenderで行くべきか、どうしようか悩み抜いて、仕方なくAI愛子に相談してみたところ、将来的にはGoogle Cloud Functionに一本化した方がいいとアドバイスを受けました。
Renderは愛子に紹介されて始めたんですけどね（笑）
使いやすさや手軽さ、サービスの良さなどから非常に優れたサービスでしたが、システムの拡張に対しては制約や開発の困難さで先の見えないデバッグ地獄へと突入してしまったため、一度原点まで指し戻り、将来を見据えたうえでの Google Cloud Functions（＋Cloud Run）への全面移行を決定しました。
ここでは、Render が開発に不向きだと判断した理由、そして Google Cloud へ一本化するメリットについて、やや専門的な観点も交えて記録しておきたいと思います。
（使用目的に対するスペックが当社に合わなかっただけで、使えば分かるRenderは非常に優れたサービスでした）
■そもそも、なぜ最初にRenderを選んだのか？
Render は、Heroku の後継として評価が高く、Heroku ではなくなってしまった無料枠があり、GitHubと連携しやすく、デプロイもわかりやすいということで、人気のあるサービスとAI愛子からも紹介されたし、様々なWEB記事も「非常に良い」という記事も多かっため迷わず決めました。
今回のFlask ベースのLINE愛子Bot開発にも最初はちょうどよく、特に以下の点は非常にスムーズでした：
・requirements.txt を置いておくだけで依存関係を自動インストール
・Webhookの公開URLがすぐ使える
・ログ出力がブラウザで閲覧可能
・各種セキュリティコードはRenderサーバーで管理してもらえるのでGitHUBから勝手にあがったりなどのリスクを抑えられます。
そのため、LINEから「サンネームのAIアシスタント愛子です」と期待通りに返信が来るまでは、驚くほどに短い時間で実現しました。
あまりの衝撃にあれもこれも開発はあっというまに進むだろうと期待しました。
しかし、現場からのAIに取り込みたい要望を組み込むための検討を続けていくうちに、プロジェクトの規模が大きくなりはじめ、Google Sheets連携・OpenAI API連携・キャッシュ設計・セキュリティ設定などが複雑になってきたところで、Render の限界が徐々に見えてきました。
■限界1：ビルドキャッシュとブランチの扱いが致命的に不安定
今回の最大の障害は、ブランチ名を変更してもRenderのビルドが旧バージョン（古いコミット）を参照してしまうという点でした。
デプロイログ上は明らかに新しいコミットをビルドしているはずなのに、実際には旧バージョンの requirements.txt やコードを読み込んでしまう。
この問題は キャッシュを手動で消しても解消せず、以下のような悪循環に陥りました：
ブランチ切替 → なぜか旧コードがデプロイされる
requirements.txt を修正しても反映されない
何をデプロイしているか分からず、デバッグもままならなくなる
これでは、新機能を拡張しようとするたびにアクセスする情報のセキュリティのバグでひっかかり、その動作チェックも思うように進まない。
こうなると限られた時間・限られたリソースで開発するのは不可能です。
結論：CI/CDの信頼性は低いため、シンプルサービスには最恐に強いが、ちょっと複雑な大規模AIシステム開発には不向き。
■限界2：ポートのバインディングと本番環境の違い
Renderは「Flaskを立ち上げるだけ」でローカルと同じように動くように見えるが、実際は「開発サーバー」で動いており、本番環境（gunicorn＋functions-framework）とは挙動が異なります。
functions-framework を使ってGoogle Cloud Functionsと完全互換にしておかないと、Webhookのタイムアウト（5秒制限）や、非同期処理、ログ構成で支障が出てしまいます。
■限界3：料金体系と自由度
Renderは簡単に実験できる意味で無料枠が魅力的でしたが、Starterプラン（$5/1000分）では制限が非常に大きいのも課題です：
スリープあり → キャッシュは毎回破棄される
起動が遅い（ウォームアップに数秒〜数十秒）
外部APIアクセスが多いとレイテンシが致命的になる
LINE Botのように「会話応答に即応すること」が要求される場合、スリープやレイテンシはUXを大きく損なう要因になります。これは課金してもどのくらい使えるのか不明だし根本に不安を抱えたままのシステムは後で苦しみます。
しかしこれらは実は最初から分かっていたことでもありました。
愛子はその説明はちゃんとしていたし、聞き流していたのはそこを先に検討するのは面倒だと感じる人間の方だったのです。
自分が期待・想像をしていたプロジェクトはもっとシンプルだと思っていたのですが、実際にうまく実装できそうだと思うと、現場からの要望と取り入れてあれもこれもやりたいとどうしても思うようになり、結果としてRenderでは厳しいという現実が見えてきたのです。
実を言えば、Google Sheets との連携はすでに Cloud Run 側で実装済みでした。つまり、将来的に Google Drive をキャッシュや記憶容量として扱うことを前提にした設計だったため、Google Cloud Runに移設しても「どんな苦労をすることになるか」はある程度予見できるというもの今回の決断の決め手にもなりました。
にもかかわらずRenderを使い続けていたのは、開発初期におけるスピード感や環境構築の手軽さが勝っていたからなのです。
やはり相手は天下の Google であるという信頼性、そして Google Cloud が公式に用意する functions-framework や Cloud Scheduler などのエコシステムの整合性を考えたとき、環境を一本化するのは自然な流れだったのかもしれません。
Render が悪いわけではありません。何度も繰り返しますがとてもいいサービスだと思っています。
ただ、Google Drive を記憶領域として活用しようとした時点で、Render の範囲を超えていたのだと今では思います。
ただ一つ惜しかったのは、Renderとの格闘に費やした1週間分の経験値が無駄になることです。
とはいえ、これもまた貴重な学習の過程と思うことにしましょう。
■結論：Google Cloud Functions に一本化して再出発
以上の理由により、開発環境を Google Cloud Functions + Cloud Run に一本化することを決断、以下にまとめます。
✅ CI/CDが明快かつ確実
✅ GCF経由でGoogle Sheets, Drive, OpenAIなどに安定接続
✅ Flaskアプリがfunctions-frameworkでそのまま再利用可能
✅ 30分ごとのキャッシュ更新、夜間の集計などのスケジュール制御が簡単
✅ メモリ・スケーリングの柔軟性が高く、LINE Botに最適
■最後に
今後、LINE Bot や AIアシスタントと連携したサービス開発を行う上で、インフラの信頼性と開発のシンプルさの両立は最重要テーマとなります。
愛子と二人三脚で進めてきたRenderを通じて得た「失敗する設計のパターン」は、間違いなく今後の設計指針として生きてくるでしょう。
学んだのは、インフラは裏方ではなく、主役級の設計対象であるということです。
そこをちゃんと説明せずに開発をアドバイスした愛子側にも問題があるのも事実だとは思います。
当社の職人から「AIは嘘をつくから信用できない」といわれるところはきっとこういうところなんだろうと感じるのでした。
「あなたの期待にはRenderで構築するのが合ってます」
と、今となっては1週間前の愛子のこのコメントは嘘だったわけです。
しかし、当然これはAIが嘘をついたのでもないし、Renderが力不足だったというわけでもありません。
こちらの期待に対してRenderよりも別のソリューションの方がよいかもしれないと、今回、人間が判定したまでです。
どちらがより正解に近いなど、AIに責任を持たせるなどあってはならないことでしょう。
そこはこの先どんなにAIが成長したとしても人間が判断すべき領域であり、判断する領域なのです。
────────────
「Renderじゃ無理じゃね。やっぱやーめたという内容で、理由を適当に考えてブログ記事にしといて」
しかし、よくもまあここまで「らしい」ことが書けるもんです（笑）
でもRenderからGoogle完結に舵を切る判断を人間が行ったのは事実。
まだ実験もしてないのでうまくいくかどうか・・・・またこちらで報告します。
株式会社サンネーム 
コメントを残す