こんにちは。ロリポップ・ムームードメイン事業部の nacal です。ゲームサーバーのホスティングサービス ロリポップ! for Gamers を開発しています。for Gamersのテストの方針は、2年前におおよそ決まりました。当時の判断は次の記事で公開されています。短期間での新規プロダクト開発における「コスパの良い」Goのテスト戦略（GMO Developers）その方針は、「実際にちゃんと動くのか」を担保しながら、テストをコスパ良く書くことです。外部サービスと通信するとラージテストになるので、スタブサーバーに置き換えて1台のマシンの中で完結させます。スタブを書く工数はかかりますが、安定して速く走るテストと引き換えにその工数を受け入れていました。ただし決済は例外でした。決済サービスにはテストサーバーがあり、それを使えば簡単にテストを書けます。記事には、スタブサーバーの実装コストも含めて考えた結果、外部と通信するコストを受け入れたと書いてあります。いま読み返しても妥当な判断です。テストの総量が少ないうちは、数分の遅れは許容できます。記事の最後には課題も挙がっています。テストの実行時間が10〜20分に増えたこと、flaky testが増えたこと、ラージテストが無計画に増えたことです。その対策として、スタブサーバーの実装を進めてラージテストを削減する、と書かれています。2年経って、その課題に自分が取り組むことになりました。サービスが育つとテストは増え、CIの待ち時間も伸びます。開発の進め方も変わりました。AIエージェントに実装を任せる比率が上がり、PRを出すまでの時間は短くなっています。一方でCIの実行時間は変わりません。手を動かしている時間よりCIを待っている時間のほうが長くなると、待ち時間の長さが急に気になり始めます。しかも決済のテストは遅いうえに、外部の都合でも落ちます。テストサーバーのレートリミットに引っかかるケースもその1つです。flaky testのなかでも、いちばん対処しにくい種類でした。取り組んだ内容は、記事に書かれていたとおりです。httpstubを使って決済APIのスタブサーバーを書き、runnで書いたシナリオテストをそこに向けました。runnはYAMLで書いたランブックを上から順に実行するツールです。スタブは顧客とカードの情報を状態として保持し、3

WebhookとはカラーミーショップにWebhookを導入した理由要件定義で考えたポイント 通知の取りこぼしを既存APIで補えるか確認する登録主体はショップオーナーに限定する登録できる配信先URLの数に上限を設ける設計方針 Standard Webhooksの採用カラーミーショップ特有の考慮点 thin payloadの採用Outboxパターンの採用ユースケースに合わせたリトライ戦略配信状態と試行履歴の記録負荷対策と非同期処理ワーカー設計セキュリティ: 配信先を信用しないHTTPクライアントの防御設計 SSRF（Server-Side Request Forgery）レスポンス遅延によるスレッド占有巨大レスポンス対策: ストリーミング処理とサイズ制限参考にした先行事例 Svix他サービスのWebhook仕様と比べてまとめこんにちは。GMOペパボが運営するECサイト構築サービス「カラーミーショップ」を開発しているyukyan、kosuke、keiです。カラーミーショップに、受注が作成されたことを配信先へHTTPで通知するWebhook機能を実装しました。この記事では、Webhookの送信機能を開発するにあたり、何を検討し、どう設計・実装したかを紹介します。Webhookを開発するときの参考になれば幸いです。WebhookとはWebhookは、サーバ側でイベントが発生した際に、あらかじめ登録されたURLへHTTP POSTを送信する仕組みです。配信先がAPIを呼び出して変化を確認する方式に対し、Webhookではイベントが発生した側から配信先へ通知します。通知を受け取ったシステムは、それをきっかけに次の処理を始めることができます。たとえばGitHubでは、プッシュやプルリクエストの作成をWebhookで通知できます。他にも、外部のCIサーバでテストを実行したり、Slackにメッセージを送ったり、課題管理システムを更新したりできます。カラーミーショップにWebhookを導入した理由カラーミーショップには受注や商品を取得する公開APIがありますが、イベントが発生したことを外部へ通知する仕組みがありませんでした。今回の例では、受注の作成を通知する仕組みはありませんでした。そのため、公開APIを定期的に呼び出すポーリングで、取得済みのデータと比較して新しい受注を検知する必要があ

SUZURI・minne事業部 minneグループのtossy（@tshk_sakai）です。2026年10月よりシニアエンジニアになりました。このエントリーでは、AI・MLのシニアエンジニアとして何に取り組むのかを、これまでの経緯とあわせて紹介します。AIに任せ切る仕組みづくりで品質とスループットが落ちないサービスへシニアエンジニアとして、AIに任せ切る仕組みづくりによって、minneを少人数でも品質とスループットが落ちないサービスへ転換します。人が担ってきた仕事をAIに任せるとき、難しいのは「AIを使うこと」そのものではありません。どこまで任せてよいかを決めることです。AIの出力には誤りが含まれます。そのため、任せ切るには次の3つを仕組みとして作り込む必要があると考えています。どこまで任せてよいかを、定量評価で見極める誤りを前提にしたガードレールと計測を、本番品質で作り込む実績に基づいて、任せる範囲を段階的に広げる1つ目は研究で身につけた「AIの不確実性を定量評価し、判断する力」、2つ目はWebエンジニアとして身につけた「本番品質で完遂する力」です。3つ目は、この2つを掛け合わせて回し続けることで実現できます。精度を評価できても本番へリリースできなければユーザーに価値は届きませんし、リリースしたとしても評価できなければどこまで任せてよいかを決められません。私の強みは、研究開発とWebエンジニアの両方の経験を踏まえて事業への貢献を行えることです。この強みを活かし、AIに任せる範囲を広げていきます。これまで研究開発からWebエンジニアへ私は2021年5月にペパボへ入社し、ペパボ研究所で研究開発に取り組みました。業務と並行して九州大学の博士課程で自然言語処理の研究を続け、2026年9月に博士課程を終え、博士の学位をいただきました。働きながら学位を目指した経験は、きのこカンファレンスin関西で発表しています。ペパボ研究所では作品の特徴を分類するモデルのオフラインでの定量評価に取り組みました。しかし、サービスへの導入には至らず、ユーザーへ価値を届けられませんでした。オフライン評価で見えない部分はリリース後にしかわかりません。この反省から、評価だけを追うのではなく、ガードレールや計測を先に用意してリリースを止めない設計へと考え方を変えました。2024年5月からはminneの

2026年度に新卒エンジニアとして入社しました、ロリポップ・ムームードメイン事業部 第一事業開発チームのゆっきーです。8月25日にリリースした「ロリポップ！AIゲートウェイ」の開発を担当しています。今回の開発では、Codex+エージェント群による自律的な開発ループを構築しました。人間が寝ている間もエージェントがコードを書き、レビューし、テストする。プロジェクト発足から提供開始までの約7週間で、GitHub上に約600件のIssueを起票し、そのうち約450件をクローズしました。この記事では、Issue起票からレビュー、E2Eテスト、クローズまでを自動で回す仕組みの全体像と、運用して見えた成果・課題を紹介します。「ロリポップ！AIゲートウェイ」とは「ロリポップ！AIゲートウェイ」は、複数のAIプロバイダが提供するLLMを1つのAPIキーで利用できるマネージドAIゲートウェイです。2026年8月25日に提供を開始しました（プレスリリース）。ロリポップは「動かす・届ける・つなぐ・使う」の4機能で構成されるAIインフラ基盤の構築を進めています。「ロリポップ！AIゲートウェイ」は「使う」を担うサービスとして、国内で不足していた日本円対応・日本語サポートの国産AIゲートウェイを提供するために開発されました。この記事では開発プロセスに焦点を当てます。なぜ自律型開発ループに至ったか私は以前からCodexをカスタマイズし、日常的に開発に活用しています。Codex CLIはオープンソースで、動作を確認しながら連携を作り込めます。この点が決め手となり、「ロリポップ！AIゲートウェイ」の開発でも早い段階でCodexを採用しました。ただ、最初から自律型開発ループの完成形を描いていたわけではありません。当初は、Issue単位でAIエージェントに実装を任せ、テストと独立レビューを通せば安全に開発できると考えていました。しかし、実際の利用パターンをすべて想定し、必要なテストケースを漏れなく定義することは難しいと気づきました。実際、テストが通っていても、開発環境でブラウザから操作すると使えないケースが何度も見つかりました。そこで、マージとデプロイの後に、実際の画面を操作するE2Eテストを追加しました。問題が見つかった場合は、E2Eテストを担当したエージェントが同じセッションで通信ログ・サーバーログ・

こんにちは、ロリポップ・ムームードメイン事業部 第三事業開発チーム 兼 技術部 技術基盤チームプリンシパルエンジニアのじっぱー(@buty4649)です。最近はもっぱらELDEN RING NIGHTREIGNだけをプレイしていて他のゲームや趣味に手を付けられない今日この頃です。さて、私が携わっているロリポップ！ゼロトラストリンク(以下、ZTL)は、離れた場所にある機器同士をVPN機器なしで直接つなぐサービスです。接続したい機器に専用のクライアントアプリケーションをインストールし、GoogleアカウントやApple Account、MicrosoftアカウントといったサービスのアカウントでSSOすれば、すぐに利用できます。また、機器同士は暗号化された専用のネットワークを利用して通信するため盗聴や改ざんの心配はありません。2026年9月28日には、企業向けの上位プランプレミアムプランの提供を始めました。アクセスルールで使えるグループ数の上限が300に広がり、部署や役割ごとに細かくアクセスを制御できます。10月15日からは、どの機器がいつどこへ接続したかを記録するフローログもプレミアムプラン向けに提供する予定です。あわせて、Microsoft Entra IDとのSSOとSCIMの連携、管理操作ログ、MDMを使った社用デバイスの接続先制限といった、組織向けの管理機能も追加しました。詳しくはプレミアムプランの提供開始と組織向け管理機能の拡充についてをご覧ください。この記事では、ZTLの社内での活用事例として、パブリックエンドポイントを付けていないAmazon RDS(以下、RDS)へ、手元のPCから安全に接続する方法を紹介します。RDSにどうやってつなぐか？ZTLを利用してRDSに接続する事前準備中継用EC2インスタンスの設定 Tips：認証トークンでログインする手元のPCから接続するまとめRDSにどうやってつなぐか？RDSは、インターネットから直接届かないようにプライベートサブネットへ置くのが基本です。一方で、データの調査やメンテナンスのために、開発者が手元のPCからRDSへつなぎたい場面はよくあります。手元のPCからRDSへつなぐ方法としては、次のようなものが考えられます。VPC内で起動したAWS CloudShellから接続するEC2などに踏み台サーバを置き、SSH

本記事は、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を提供すること自体が我々にとって初めてだったでした。そのため、

はじめにこんにちは。SUZURI・minne事業部 minneグループのtossy（@tshk_sakai）です。2026年8月6日に、ハンドメイドマーケットminneで「minneコンシェルジュ」を公開しました。minneコンシェルジュは、AIエージェントと対話することで作品を探すことができる機能です。今回、AIエージェントの実行基盤にAmazon Bedrock AgentCore（以下、AgentCore）を採用しました。AgentCoreは2025年10月にGAとなった新しいマネージドサービスで、AIエージェントを迅速に本番環境へ導入できるサービスです。この記事では、minneコンシェルジュのアーキテクチャと、AIエージェントを本番サービスへ導入する際の工夫を紹介します。minneコンシェルジュとはminneコンシェルジュは、会話をすることで新しい作品に出会える機能です。minneには1800万点を超える作品があり、キーワード検索やカテゴリ検索などで作品を探せます。海外や日本のECサイトでは、サイト上のAIアシスタントへ相談して商品を推薦してもらう体験が広がりつつあります。しかし、これまでminneでは「母の日に3,000円くらいで上品なアクセサリーを贈りたい」のような会話をしながら作品を探すことは提供できていませんでした。そこで、minneで作品を探す際に、対話でユーザの要望を確認しながら、作品を提案する機能を提供することを目指しました。なぜAmazon Bedrock AgentCoreを選んだかminneのサービスの大部分はAWSで稼働しており、既存の資産を活用することで、開発工数をなるべく少なくしたいと考えました。既存の資産を用いることで、認証やIAMによる権限制御、監視等の仕組みをそのまま活用できます。AgentCoreは、エージェントの本番運用に必要な要素を複数提供しており、要素を自由に組み合わせることで状況に応じた開発が可能です。AgentCore Runtime：エージェントのサーバレス実行基盤AgentCore Memory：会話履歴の保存先AgentCore Identity：認証、認可の管理AgentCore Gateway：外部APIなどをMCPサーバとして公開AgentCore Observability：エージェントの動作状況の監

はじめにこんにちは。SUZURI・minne事業部 minneグループにてエンジニアリングリードをしているkazuです。minneでAI前提のプロダクト開発組織づくりを進めています。これまでは個別の仕組みについて書いてきました。PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少しずつなんとかしていくClaude Code Actionで複数リポジトリを横断して情報を参照し調査・実装を進めてもらおう整備してきたのは次の2つです。PRサイズラベルの自動付与・AIレビューによるApprove・条件付きauto mergeの3段構えを入れたことClaude Code Actionがリポジトリを横断してソースコード・issue・PRを参照できるようにしたこと前者は人のレビューが追いつかなくなったためです。エンジニアはエージェントを並列に動かし、CSやディレクターもClaude Code Action経由でPRを出すようになりました。後者はminneのコードがRails・Next.js・iOS・Androidに分かれており、片側だけでは調査を完結できないためです。これらの仕組みを整備したうえで、組織とプロセスの側がどう変わってきたかを短くまとめます。2026年9月時点の現在地です。はじめにAI自律マージ率Webとモバイルで越境するモバイルのリリースを2週間に1回から1週間に1回へ自動マージのバックテストおわりにAI自律マージ率詳細は前回の記事に書きました。AIのレビューでリスクを評価し、ユーザー影響が小さいものはAIエージェントが自律的にマージできるよう進めています。その仕組みが「PRサイズラベルの自動付与 → AIレビュー＆Approve → 条件付きauto merge」の3段構えです。人間の手を介さずAIのApproveからマージまで完了したPRの割合は、直近30日で次のとおりです。プラットフォーム AI自律マージ率 Android 94% iOS 65% サーバーサイド 74% 全体 83% 分母は、その期間にマージされたPRの全件です。auto mergeの対象条件を満たしたPRだけに絞ってはいないので、そもそも自動マージの対象外だったPRも含んだ数字になります。Webとモバイルで越境するいまのチームはWebエンジニア2人、モバイルエ

はじめに2026年度に新卒エンジニアとして入社した、たてけんです。ペパボの開発では日々の業務でデータベースに触れる機会が多くあります。その土台となるDBモデリングを学ぶため、2026年度の新卒エンジニア研修では、igaigaさんをお招きし、特別講義を開催しました。当日は、DBモデリングの講義と、図書館の蔵書貸出管理を題材にした演習、そして「AI時代の（設計に関する）成長戦略」の講義という構成でした。この記事では、参加した新卒エンジニアそれぞれの視点から、当日の学びをお届けします。igaigaさんによる過去のワークショップの様子は、『DBモデリングとRSpecのワークショップを行いました』をあわせてご覧ください。はじめに講師紹介：igaiga（五十嵐邦明）さんなぜigaigaさんをお招きしたのか講義：DBモデリング 「誰が・何を」から名詞を洗い出す演習：図書館の蔵書貸出管理を設計する モデリングで一番悩んだ点みんなの発表を聞いて感じたこと講義：AI時代の（設計に関する）成長戦略 「遭遇率が上がる」＝成長チャンスAIが出した設計を「評価する」側へみんなの感想 keithkimatakeimaruのーらゆっきーしんおわりに講師紹介：igaiga（五十嵐邦明）さん講師を務めてくださったigaiga（五十嵐邦明）さんは、Ruby・Railsを専門とするエンジニアです。『パーフェクトRails』『Railsの教科書』『Railsの練習帳』など、多くのエンジニアが学びの入り口にしてきた著書を執筆されています。今回の講義や演習も、igaigaさんが公開されている『Railsの練習帳』のDBモデリング基礎講座をもとに進めていただきました。加えて、「AI時代の（設計に関する）成長戦略」と題した講義もしていただきました。なぜigaigaさんをお招きしたのか新卒エンジニア研修を担当した、はるおつです。ペパボの新卒エンジニア研修では、ここ数年igaigaさんにDBモデリングの特別講義をお願いしています。実際に動き、見た目がそれらしいものをすぐに作るということは、AIエージェントの台頭によってますます容易になっています。一方で数年先を見通したDBモデリングについては、今はまだ人間がAIと並走して適切に判断する力を求められている領域だと感じています。Railsチュートリアルを終えたばかりの新卒エ

技術部データ基盤チームの@zaimyです。ペパボでは、クラウドや物理サーバーなど複数のプラットフォームにまたがるコストを社内ダッシュボードで可視化しています。このダッシュボードに供給するコストデータを、FinOps Foundation1が策定する共通仕様FOCUSに沿って正規化する層をdbtで構築しました。その結果、ダッシュボード側のSQLは約10分の1（数百行から数十行）に縮小し、新しいコストソースの追加が容易な定型作業になりました。FOCUSを実際のデータ基盤に適用した事例はまだ少ないようです。この記事では、コスト可視化をFinOpsの共通スキーマで統一したいデータエンジニアやSREの方に向けて、正規化層の設計判断と、共通スキーマに揃えたことで何が容易になったかを紹介します。ペパボのコスト可視化基盤課題はソースごとにバラバラなコストデータFOCUSとはFOCUSコスト層の設計 課金期間はソースのnativeな粒度のまま持つnative通貨を保持し、換算列を併設する組織固有の軸もx_拡張カラムに乗せるデータマートも請求の最小粒度を保持する新しいコストの追加が定型作業になった クラウド以外のコストも同じ受け皿に乗る共通スキーマの上に機能が積み上がる得られたものと工夫のまとめまとめペパボのコスト可視化基盤前提として、ペパボのコスト可視化の構成を簡単に紹介します。社内データ基盤「Bigfoot」に各プラットフォームのコストデータを収集し、dbtで変換してBigQueryのテーブルとして提供しています。可視化はCloud Run上のStreamlitで運用している社内ダッシュボード基盤が担っています。コスト用のダッシュボード（「Bigfootを使ったbillingの可視化」ということで社内では「Billingfoot」と呼んでいます）が、BigQueryのコストテーブルを参照する構成です。コストの発生源は従来8種類ありました。Google CloudやAWSなどのパブリッククラウド、社内で構築したプライベートクラウド、データセンターの物理サーバー、種々のSaaSやIaaSです。これらをひとつのダッシュボードで横断的に見ていました。課題はソースごとにバラバラなコストデータ問題は、これらのコストデータが「各ソースのAPIから取得した形のまま」BigQueryに置かれていたこ

はじめに2026年度に新卒エンジニアとして入社した、たてけんです。ペパボの開発ではAIエージェントを日々の業務に取り入れることが当たり前になりつつあります。2026年度の新卒エンジニア研修では、みのるんさんをお招きし、特別講義とハンズオンを開催しました。当日は、生成AIの全体像をつかむ講義「AI最前線！AWSでLLMアプリ構築入門」と、Amazon Bedrock 上で RAG と AIエージェントを実際に組み立てるハンズオンという構成でした。この記事では、参加した新卒エンジニアそれぞれの視点から、当日の学びをお届けします。はじめに講師紹介：みのるん（御田稔）さんなぜみのるんさんをお招きしたのか講義：AI最前線！AWSでLLMアプリ構築入門 AIエージェントの「作り方」が変わったハンズオン：RAG＆AIエージェントを実際に組んだ まずはRAGを作ってみるAIエージェントを組み、触って学ぶみんなの感想 keithkimataしんmaruのーらゆっきーたてけんおわりに講師紹介：みのるん（御田稔）さん講師を務めてくださったみのるん（御田稔）さんは、KDDIアジャイル開発センター株式会社のテックエバンジェリストです。日本人初のAWS AI Hero・AWS Samurai に選出され、『Amazon Bedrock 生成AIアプリ開発入門』『やさしいMCP入門』などの著書でも知られています。AWSと生成AIの最前線を走る方に直接教えていただける、貴重な機会となりました。なぜみのるんさんをお招きしたのか新卒エンジニア研修を担当した、はるおつです。講義当日までの研修でRuby on Rails、データモデリング、インフラと仮想化、CI/CD、運用監視までの研修は終えていました。つまり、受講者はコードを書いて動かすためのスキルセットの基本は備わっている状態でした（研修の詳細は新卒エンジニア研修2026の記事をご覧ください）。社内では、「Claude Codeに住む」を掲げて、普段の業務をClaude Code経由で行うという取り組みがあります。それほど、AIが前提になって仕事をしている人が多く、「AIを使う」ということは十分にできていると言えます。一方で、RAGが何をしていて、AIエージェントがツールをどう選ぶのかは、使うだけでは見えにくいポイントです。それを自社のサービスに載せ