ロリポップ デプロイナウ インタビュー

【後編】GMOペパボの「集合知」でよりよいプロダクトへ ― エンジニアリングリード・深野悠吾さんに聞く、「ロリポップ!デプロイナウ byGMOペパボ」開発秘話

ロリポップ デプロイナウ インタビュー

本記事は、GMO Developers & Creatorsとのコラボレーション企画です。エンジニアの開発思想と技術選定に迫る同メディアのインタビューシリーズ「Engineering Journey」第5弾として、前編・後編の2本立てでお届けしています。開発背景やAI時代に国内でインフラを提供する意義について伺った前編は、GMO Developers & Creatorsに掲載中です。あわせてご覧ください。

自分の作ったアプリやサイトを、コマンドひとつで公開できる「ロリポップ!デプロイナウ byGMOペパボ」。本記事では、サービスの開発を担ったエンジニアリングリードの深野悠吾さんに、開発体制やエンジニアリングリードとしての意思決定、今後の展望などについて語っていただきました。

前編:https://developers.gmo.jp/technology/86381/

初めてのCLI提供でも、環境整備&継続的な改善でブラッシュアップ

——「ロリポップ!デプロイナウ byGMOペパボ」の開発体制と、AIとの分担について教えてください。

深野:開発体制については、 基本的にはチームメンバー全員がClaude Codeを使える状態なので、Claude Codeと一緒にアプリケーションを作っていく形で進めました。サイトを公開するにあたってどういう情報が必要で、それをどう持つかといったデータベース構造の議論などの設計部分は最初にエンジニアで固めましたね。

また「ロリポップ!デプロイナウ byGMOペパボ」は新しいサービスですから、AIがどう動くかを規定する土台も重要になります。ここもエンジニアがどういう命名規則にするか、フォルダ分けやファイルの参照先をどうするかなどのルールを策定し、AIがそのルールに従えるようMarkdownで整備しました。

その構造を使って実際にアプリケーションを作っていくという段階になって、あとはエンジニアがそれぞれAIを使いながら実装していくという体制にしています。まだコードが全くない状態からCIテストを自動実行させて、AIの書いたコードがちゃんと動くかどうかを早い段階で検知できるようにしたのも工夫した点ですね。

——CLIという提供形態そのものについては、どのように進めていったのでしょうか。

深野: CLIを提供すること自体が我々にとって初めてだったでした。そのため、提供方法をどう考えるか、CLIとしてどういう体験を提供すべきか、開発しやすいファイル構造とはどういうものか…といった知見はあまりありませんでした。

実は、「ロリポップ!デプロイナウ byGMOペパボ」はリリース後に中身を大きく変えているんです。当初提供していたものを今後運用していくのは大変だなと思ったので、まだユーザー数が少ない段階のうちに新しいバージョンとして出し直したんですよ。

具体的な改善点の1つが、ログインとデプロイの統合です。それまでは別々だったのですが、「デプロイコマンドだけさえ覚えていれば、ログインを忘れていてもデプロイできるように、ログインされていなかったらログインする処理があってもいいんじゃないか?」という議論から統合しました。

もう1つがビルドログです。デプロイしたときのビルドログがWeb上にしか出ていなくて、「AIにデプロイしてもらっても、AIはエラーが起きていることがわからない」という状態だったんです。

このログをAI側に示さないとAIに使ってもらえないので、リリース直前にビルドログの表示機能を追加し、CLIからもログを取得できるようにしています。

インタビュー中の深野悠吾さん。青い壁の会議室でノートPCの前に座り、やや上を見ながら開発体制やCLI提供の経緯について語っている

長年インフラを提供してきたGMOペパボだからこその「集合知」

——エンジニアリングリードとして、意思決定はどのような軸で行っていましたか。

深野: GMOペパボには、「エンジニアはこういう観点で行動しましょう」という指針を定義したエンジニアバリューというものがあります。今回の開発においては、その中の1つである「最高・最速の両立」が1つの軸になりました。文字通り、最高のものを最速で提供しましょうという考え方ですね。

何か機能が欲しいとなったとき、「今ある機能からこう実装すれば実現できるよね」という議論はもちろん行うのですが、そのうえで「実際のところ、本当に最高な状態は何なんだろう」ということをみんなで考える時間を取るんです。

最高の状態はこれだと定義したうえで、そこまでのギャップをどうすれば最速で埋められるのかを議論して意思決定を行っていました。

中には「それをやるには早すぎるかもしれない」という議論もありましたね。理想像としてこうした機能をつけたいという思いはあるものの、今のサービス規模で考えるとコストがかさんでしまうという問題です。ここに対しては「サービスインの段階ではオーバースペックすぎるんじゃないか」といった視点から考えていきました。

——外部からの知見を借りることはなかったのでしょうか。

深野: 結構ありましたね。チーム外の方からもらった「こうしたほうがいいんじゃないか?」というレビューを踏まえて決めていく場面も多かったです。

とくにインフラに関しては、GMOペパボにはさまざまな知見を持つパートナーが社内にいるんです。「こういうアーキテクチャにしようと思うのですがどうですかね?」と相談すると、「それだとサイトの公開数の限界がこの仕様に引っ張られてしまうよ」といった指摘を返してくれましたね。

同じような課題を持っていたり、その解決策を知っていたりする人がチーム外にいたので、そこはかなり頼らせてもらいました。最初はこれでいいだろうと思っていたものも、実際にサービスを運用する中で課題を見つけて教えてくれた方がたくさんいたんです。社内に深い知識を持った方が大勢いたのも心強かったですね。

こうした課題点などはAIとの壁打ちで考える部分もありますが、それでも自分たちがわかっている問題しか質問できないんです。知識が足りない状態で進めても、問題が発生したことに気づかずスルーしかねません。

「こういう問題もあるんだよ」という、自分たちの知り得ない課題が後から見つかるのは、やはり人によるレビューの中でしたね。

——これまでGMOペパボとしてインフラを提供してきた知見が、今回の「ロリポップ!デプロイナウ byGMOペパボ」の開発にも生かされたのですね。

深野: たとえば「ロリポップ!マネージドクラウド」というプランがあるのですが、これも「ロリポップ!デプロイナウ byGMOペパボ」と同様に、サイトにアクセスが来たときだけサイトが立ち上がる仕組みを持っているんです。

その運用やプラン開発で苦労したところを事業部CTOから共有してもらったので、「ここが大変だったから、「ロリポップ!デプロイナウ byGMOペパボ」ではこういう状態にしたいよね」という議論をかなり重ねることができました。

そうした議論の中で「AI時代のサービスとしてどうあるべきか」を話し合い、より良い形にブラッシュアップできたのは大きな収穫でした。社内でサービスを作るにあたって、長年インフラ領域でサービスを展開していたGMOペパボだからこそ知り得るノウハウや勘所といった知見がかなり役立ちましたね。

安全性とコストの線引き

——アーキテクチャの設計で、最も難しかった判断はどこにありましたか。

深野: 最後の最後まで悩んでいたのは、ユーザーの方が作ったプログラムを僕らが受け取り、サイトとして公開するためのビルド処理です。たとえばその中に悪意のあるプログラムが仕込まれていた場合、他の方に影響を与えてしまう可能性があります。

「いかにセキュアなビルド環境を整えるか」という部分は、開発チームの中でも最後まで議論された点でした。最終的には、ビルド環境を毎回使い捨てる形にして、常に安全・安心な状態を保ち続ける設計に落ち着いています。

リソースや費用の面は当然気になるところですが、ビルド環境については安全性を保つために多少の投資は行わねばならないと割り切りました。ここを削ると、守りたいものも守れなくなってしまいますからね。

一方で、公開中のサイトについては一定時間アクセスがなければスリープし、アクセスが来た時点で起動するという形にしました。本当に必要なときだけしか起動しないアーキテクチャにすることで、コストを削減しているという形です。

——Freeプランを持つ以上、「コストの読めなさ」はリスクになるように思います。ここはどう設計されたのでしょうか。

深野: 根本にあるのは、コストが予測できない状態はよくないよね、という考え方です。「たくさん使っていただいたとしてもこのぐらいの金額になるだろう」「1人当たりこれぐらいまでのコストならかけられる」といった基準値を決め、それを超えないようにプランの上限を決めたりしていました。ここも最後の最後まで議論していた部分ですね。

コスト自体は使われるけれども、どこかしらで必ず引っかかるようにしておいて、「これ以上は増えない」というところを担保している状態です。チーム内で何かを作るときにも、基本的には「かなり使っていただいたときのコストはどうなるか」という話が最初の議論に入ってきます。

どこまでコストをかけずにできるのかというところは、こちらとしても気にかけているところです。社内でも使用量を見ながら、日々調整を続けています。

ノートPCを操作しながら今後の展望を語る深野さん。会議室の窓から外の景色が見える

共有・公開の障壁を取り除き、さらなる機能拡充を追求

——今後のロードマップを教えてください。

深野: まず、チーム機能を実装したいと考えています。実際にいろんなサイトを運営していくならチーム開発が必要になってきますが、今は「チーム」という概念がありません。複数人のメンバーが参加して、一緒に共同作業できる形を目指していきたいですね。

長期的な構想としては、「ロリポップ!デプロイナウ byGMOペパボ」で公開するサイトを、ゼロトラストリンクのネットワーク上で共有したい相手にだけ共有できるようにしたいなと思っています。プライベートなネットワーク上に「ロリポップ!デプロイナウ byGMOペパボ」から公開するという形です。社内だけで使うツールを社内ネットワークで公開する…といった使い方ができるところまでできたらいいなと考えています。

海外の同種サービスと比べると、まだまだ機能面では伸びしろがあると感じています。だからこそ、これからもっと拡充していきたいです。また「ロリポップ!デプロイナウ byGMOペパボ」はローンチしたばかりなので、どうやって認知度を上げようかという議論もチーム内で起こっています。

——最後に、この記事をご覧の方へメッセージをお願いします。

深野: AIエージェントが作ったコードを公開することには、これまでハードルがあったと思います。それができるようになりましたので、ぜひ試していただきたいですね。

まだまだ機能が足りないところもあります。そういったものはぜひフィードバックしていただけると、チーム全員で見て、より良いサービスにしていこうと思っています。

ぜひ、いろんなところで発信してもらえるとありがたいです。

まとめ(後編)

「ロリポップ!デプロイナウ byGMOペパボ」のコマンドひとつという体験の裏側には、レンタルサーバーをはじめとするネットワークインフラを20年以上にわたり提供し続けてきたGMOペパボだからこそ積み上げられた集合知がありました。

AIでプロダクトを実装したとしても、使われていく中で自分たちでは気づけない課題が出てくることもあります。そしてその課題を正すのは、知識や経験を持つ人によるレビューに他なりません。GMOペパボでは、AIと走る速さと人が担う確かさの両輪が、「最高・最速の両立」を可能にしているのです。