はじめに こんにちは、BASE株式会社で PHPer をしている @meihei です。 直近で New Relic の Terraform 管理を改修し、AI を使いながら New Relic を利用しやすい環境を整えました。設計思想や具体的な取り組みなどをお話します。 背景 一度アーカイブされた Terraform 管理 BASE では以前から New Relic を導入しており、BASE BANK では New Relic を Terraform で管理する取り組みもありました。 devblog.thebase.in ただし、この取り組みで使っていたリポジトリは、現在アーカイブされています。運用を続けるには New Relic と Terraform の両方に詳しい人が継続的に関わる必要があり、メンテナンスをし続けていくには難しさがありました。 New Relic 活用の広がりと Terraform 化の再開 しかしその後、社内ではサービスレベルマネジメントの取り組みが少しずつ進み、New Relic を活用する場面も増えていきました。 devblog.thebase.in devblog.thebase.in また、New Relic のダッシュボードを Terraform で管理し、「動く仕様書」として扱う取り組みも始まりました。 devblog.thebase.in こうして New Relic の Terraform 化が再び始まりました。本格的に New Relic を活用するようになったが故に、その管理・保守運用をコードで管理するモチベーションが高まったことが理由の一つです。ただし、この時点で実装されていたのはダッシュボードのみであり、Service Level などの New Relic の他の機能まで広く Terraform 管理するには、まだ実装とメンテナンスのコストが大きい状態でした。 Agentic AI が変えたこと 時は過ぎ、現在は Agentic AI の広がりによって、Terraform の実装や変更案の作成が以前よりやりやすくなっています。New Relic Provider の仕様を調べたり、Terraform コードを読み解いたり、既存の New Relic リソースを import して Terraform 管理へ移す作業までも AI に支援してもらうことで進めやすくなりました。そして、これまでやりたかった New Relic の監視設定を Terraform で管理することの現実味が高まりました。 一方で、AI の支援によって Terraform が書けるようになったとしても、それを継続的に安全に運用できるとは限りません。むしろ、Terraform で管理する対象が増えるほど、コードの構造、所有権、レビューのしやすさ、安全性、設定意図の共有が重要になります。 特に New Relic の監視設定は、運用体制と強く結びつきます。どのチームがどの領域に責任を持つのかという監視設定の所有権をコード上で表現しやすいことが重要になります。 また、監視設定の所有権を 現在の 組織構造だけを前提に設計すると、将来の変更に弱くなります。組織は時間の経過とともに変化し、運用体制もそれに合わせて変わります。Agentic AI の普及によって事業環境の変化が速くなるでしょうし、組織や責任範囲の見直しも増える可能性があります。そのため、監視設定の所有権は、変化を前提に表現できる形にしておく必要があります。 今回目指したこと 今後は、New Relic や Terraform に詳しい一部のメンバーだけでなく、各領域のエンジニアや AI の支援を受けた開発者が、監視設定の変更に関わる場面が増えていくと考えています。 その前提では、Terraform を書きやすくするだけでは不十分です。誰がどの監視設定に責任を持つのか、どの経路でレビューするのか、危険な変更をどう検知するのか、そして設定の意図をどう共有するのかを、継続的に保てる構造が必要になります。 今回の取り組みでは、New Relic の Terraform 管理を「AIに書かせる」ことではなく、人間と AI が継続的に安全に変更できる構造へ整えることを目指しました。 課題 まず、再設計する前の New Relic のダッシュボードのみが管理された Terraform リポジトリは以下のような構成になっていました。 ├── .github/ ├── modules/ # 再利用を目的とした共通 module │ └── dashboard/ │ └── standard_feature_dashboard/ # 共通レイアウトのダッシュボードを生成する module ├── services/ # プロダクト・サービスごとの Terraform 設定 │ └── base/ │ ├── prod/ # 環境ごとの設定 │ │ ├── checkout/ # 決済領域 │ │ │ └── dashboards/ # 決済領域のダッシュボード設定。base/prod/main.tf からローカル module として読み込まれる │ │ │ └── hoge_dashboard.tf # 共通 module を呼び出して、1つのダッシュボードを定義するファイル │ │ ├── item/ # 商品領域 │ │ ├── order/ # 注文領域 │ │ └── main.tf # サービス x 環境単位の Terraform エントリポイント。各領域のローカル module を読み込む │ └── dev/ └── README.md # プロジェクト全体の説明 既存構成では、標準化されたダッシュボードを作成するための共通 module がありました。もともと、ダッシュボードが標準化されず乱立・属人化し、メンテナンスが困難になっていたため、共通 module によるアプローチは有効でした。また、領域ごとにディレクトリが分かれており、2026年以降の組織図（ ECのコア機能を軸にした組織設計 ）とマッチし、保守運用すべきコードも明確になっています。 課題1：ガードレール未整備 New Relic の Terraform 管理が始まってまだ間もないということもあり、Terraform 運用に必要なガードレールは十分に整っていませんでした。 今後、New Relic や Terraform に詳しくないエンジニアが変更に関わることを考えると、レビューだけに依存せず、品質とセキュリティを機械的に担保できる仕組みが必要でした。 課題2：共通 module の運用と開発速度のボトルネック 共通 module を使うと標準化や再利用性が高まる反面、利用者（このリポジトリでは module を呼び出す領域）ごとの差異を埋めるため複雑さが増したり、変更に対して柔軟さが欠けることがあります。 また、ある時点の共通 module で利用者が目的を達成できない場合「共通 module を改修する」「共通 module を使わない回避策で作成する」という判断が必要になります。これらはどちらも、変更したい領域の外側にある関心事を考える必要があります。 たとえ AI によって Terraform の実装や変更案の作成がしやすくなったとしても、共通 module の存在はこのような追加の判断が必要となり、結果として判断を行う人間がボトルネックとなってしまいます。 課題3：New Relic の UI 上でダッシュボードを変更できない ダッシュボードの共通 module では newrelic_one_dashboard を使っていました。Terraform のリソースとしては newrelic_one_dashboard の他にも newrelic_one_dashboard_json があります。この2つにはダッシュボードを HCL で書くか JSON を書くかという違いがあります。 New Relic の UI 上ではダッシュボードを GUI Editor か JSON で編集ができ、そのダッシュボードの Export は JSON 形式のみです。そのため HCL で書かれたダッシュボードは簡単に New Relic の UI 上で変更することができませんでした。 一方で newrelic_one_dashboard_json にして、Export したダッシュボードをそのまま使う運用だと、最初の目的のダッシュボードの標準化が難しいという課題がありました。 課題4：運用には New Relic の専門知識が必要 New Relic の設定では、システムの振る舞いや異常検知の条件を New Relic 側の表現に落とし込む必要があります。一方で、開発や事業の会話はユーザージャーニーやユビキタス言語を中心に行われます。この対応関係が暗黙知のままだと、New Relic に詳しい人以外が監視設定の意図を理解しづらくなりますし、AI による生成物の精度も悪くなります。 取り組み Terraform 管理の方針 課題には明確に答えられるものもあれば、トレードオフを伴うものもあります。そこでまずは以下の方針を決めました。 New Relic は UI での編集も許容する。Terraform は UI での変更もコードでの変更も両方を取り込む形で管理する。 サービスや組織構造の変化に追従しやすいことを優先し、なるべくフラットで質素な構成に寄せる。 1は、New Relic の UI Editor での編集のしやすさに加え、New Relic 最新機能もいち早く取り入れやすくするための判断です。UI 操作で機能を理解したうえで Terraform 管理に移す、という流れを想定しています。 2は背景でも述べた通り、Agentic AI の普及によって事業環境の変化が速くなることを前提に、組織や責任範囲の見直しが増えることを想定した判断です。 この方針の上で、課題に対して4つの取り組みを行いました。 取り組み1：ガードレールの整備 まずは、課題1を解決するために、Terraform の CI/CD を整備しました。 User Key を発行した New Relic ユーザーの権限を最小化 アクセストークンなどの Secrets を GitHub から AWS に移行 AWS へは OIDC で最小権限でアクセスするように変更 GitHub Actions のバージョンは SHA Pinning で固定 Dependabot での更新は cooldown 期間を設ける tflint と secretlint を導入 重要な部分は CODEOWNERS でレビュー必須に このうち SHA Pinning や Dependabot の cooldown は、 tj-actions/changed-files の侵害（CVE-2025-30066） のようなサプライチェーン攻撃への備えです。悪意あるバージョンの多くは公開から間もない時期に発見されるため、 新しいバージョンの適用をあえて遅らせる cooldown はシンプルですが有効な対策になります。 speakerdeck.com これは AI 専用の仕組みではなく、人間が変更しても AI が変更しても、危険な変更を検知しやすくするための土台となります。 取り組み2：共通 module を廃止 続いて課題2を解決するために、現時点では共通 module を廃止しフラットな構成に寄せることにしました。 ファイル名に prefix をつけるだけというシンプルな作りと CODEOWNERS で、責任範囲や所有者を表現するようにしました。 ├── services/ │ └── base/ │ ├── prod/ │ │ ├── main.tf # エントリポイント │ │ ├── item_alerts.tf # 商品領域のアラート │ │ ├── item_dashboards.tf # 商品領域のダッシュボード │ │ ├── item_service_levels.tf # 商品領域の Service Level │ │ ├── item_*.tf # 商品領域その他 │ │ ├── checkout_*.tf # 決済領域 │ │ ├── order_*.tf # 注文領域 │ │ ├── notifications.tf # 共通の通知設定 │ │ ├── ... # .github/CODEOWNERS services/base/*/item*.tf @baseinc/item-team services/base/*/checkout*.tf @baseinc/checkout-team services/base/*/order*.tf @baseinc/order-team ※ ディレクトリ構成中のファイル名やチーム名は例です。 各ファイルでは New Relic のリソースを定義するだけとなっています。 なお、module を全否定しているわけではありません。大量の同種リソースを扱う必要が出てきた時にはスコープを限定した状態で module の導入を改めて検討する余地を残しています。 取り組み3：標準化されたダッシュボード作成のスキル化 共通 module を廃止しようとすると「標準化されたダッシュボードを作成するための共通 module」をどう取り扱うかが関連して問題になります。こちらは AI が New Relic ダッシュボードを作成する時に、標準化されたダッシュボードを生成する Skill（Agent Skills）を用意して対応しました。 背景で紹介した「動く仕様書」の記事では標準化を共通 module というコードの制約で担保していましたが、これを Skill とレビューという生成時の規約で担保する形に置き換えたことになります。 そしてダッシュボード自体を HCL で書く必要性もなくなったため、JSON で書くようにし、 newrelic_one_dashboard_json を使うことで課題3も解決しました。JSON でダッシュボードを管理する方法は New Relic 公式ブログでも紹介されています 。 またダッシュボードの本体が JSON で書かれることで、フロントエンドのコードから呼び出しやすくなり、モックデータで HTML を生成するツールを作って CI から社内 HTML ホスティング環境にアップロードするようにしました。 devblog.thebase.in モックデータで HTML を生成して、それをベースに PR の議論が進んでマージされた例です。 取り組み4：ユビキタス言語と New Relic の監視設定をつなぐ Catalog file これはまだ PoC ですが、用語マッピングファイルとして Catalog file を用意しました。 Catalog file は、ビジネスやプロダクトの言葉と、New Relic の監視設定を対応づけるための翻訳レイヤーです。 イメージとしては、フロントエンドとバックエンドの間にあるインターフェースを理解するために OpenAPI を使うようなものです。 現時点では、OpenAPI のような厳密な契約を最初から目指すのではなく、ユーザージャーニーやユビキタス言語と、New Relic の監視設定を対応づけるための薄い翻訳レイヤーとして用意しました。 たとえば item（商品）領域の Catalog file では、次のような対応関係を表現します（クラス名などの値は例です）。 domain : item critical_user_journeys : - id : item_register name : 新しい商品を追加できること # 社内で管理している SLO 一覧と結合するためのキー code_paths : backend : - 'ItemController::register' service_levels : - tf : newrelic_service_level.item_register_success # Terraform の state アドレス 実は最初は、ユーザージャーニーの説明や目標値、オーナーなども Catalog file に持たせようとしていました。しかし実際に書いてみると、それらは社内の SLO 管理ドキュメントや Terraform 側にすでに存在する情報で、Catalog file に転記するとどちらかが必ず古くなります。 そのため現在は、Catalog file には他のどこにも存在しない情報（ユーザージャーニーとコードと New Relic リソースを結びつける対応関係）だけを持たせ、それ以外は結合キーと参照リンクで済ませる形を試しています。 これにより、AI に New Relic の Terraform 設定だけを読ませるのではなく、人間が普段使っているユーザージャーニーやユビキタス言語を起点に、New Relic で観測できる設定へ変換しやすくすることを目指しています。 とはいえ、これが翻訳レイヤーとして機能するのか、持たせる情報の粒度はこれで良いのかは、まだ検証の途中です。Catalog file は別ファイルとして存在する以上、現実のシステムや New Relic の設定と乖離するリスクも常にあり、今後は Terraform や New Relic の実態との差分を機械的に検査していくことも課題になります。 再設計後の構成 最終的に現在の Terraform リポジトリは以下のような構成になりました。 ├── .claude/ │ └── skills/ │ └── newrelic-dashboard # 標準ダッシュボードを作成するための Claude スキル ├── .github/ │ └── CODEOWNERS # 領域ごと担当チームをオーナーに設定する ├── services/ # プロダクト・サービスごとの Terraform 設定 │ └── base/ │ ├── prod/ # 環境ごとの設定 │ │ ├── item_alerts.tf # 商品領域のアラート設定を管理 │ │ ├── item_dashboards.tf # 商品領域のダッシュボードを管理 │ │ ├── item_service_levels.tf # 商品領域の Service Level を管理 │ │ ├── checkout_*.tf # 決済領域 │ │ ├── order_*.tf # 注文領域 │ │ ├── dashboards/ # ダッシュボード本体の JSON。領域ごとにディレクトリを分ける │ │ │ └── item/ │ │ │ └── hoge_dashboard.json │ │ └── main.tf # サービス x 環境単位の Terraform エントリポイント │ └── dev/ ├── observability-catalog/ │ ├── domains/ # ドメインごとのユビキタス言語と New Relic の監視設定の対応関係を定義する │ │ └── item.yml │ └── applications.yml # リポジトリと New Relic を対応付けるための定義書 ├── tools/ │ └── dashboard-viewer/ # ダッシュボード JSON をモックデータで描画するローカル viewer └── README.md # プロジェクト全体の説明 執筆時点では、ダッシュボード6枚に加えて、Service Level 15本とその burn-rate アラートなど、通知設定までが Terraform 管理下に入っています。ダッシュボードだけだった半年前と比べると、管理対象は New Relic の監視設定ひと通りに広がりました。 まとめ New Relic の Terraform 管理を再開するにあたり、AI に書かせることではなく、人間（組織）と AI が継続的に安全に変更できる構造を整えることを目指しました。 ガードレールで、誰の変更であっても機械的に検証される土台を作る 共通 module を廃止したフラットな構成と CODEOWNERS で、所有権を組織の変化に追従しやすい形で表現する ダッシュボードは JSON と Skill で、UI での編集しやすさと標準化を両立する Catalog file で、ユビキタス言語と監視設定の対応関係を明示する 組織も事業環境も変わり続ける前提に立つと、監視設定の管理は「一度作って終わり」にはなりません。変更に関わる人（と AI）が増えても壊れない構造を先に用意しておくことが、これからの New Relic 運用の土台になると考えています。 BASE では「オブザーバビリティ × AI」な取り組みにも挑戦しています。 一緒に進めていく仲間を募集しています。興味のある方は、ぜひお気軽に採用情報をご確認ください。 binc.jp

はじめに 2026/7/20（月・祝）、BASE株式会社から 登壇 & ゴールドスポンサーとして協賛した PHP Conference Japan 2026が開催されました。 今回はPHP Conferenceに初参加したメンバーが多かったため、初参加ならではの感想コメント、会場やスポンサーブースの様子についてお届けします！ BASEのスポンサーブースの紹介 今年は Yell Bank と PAY ID がロゴをリニューアルしたため、それにちなんで「BASEロゴ検定〜あなたもBASEのGEEKになろう〜」と題して、BASEが展開するサービスのロゴにまつわるクイズ企画を実施しました！ ↑ブログ投稿用に、ご回答いただいた中から厳選させていただいて貼っていますが、写真にない付箋が100枚くらいありました。 非常に多くの方にご回答いただき、ノベルティとして用意していました「BASEロゴ今治ミニタオル」も14時頃に配布終了してしまいました。（お渡しできなかった方、すみません…！） 今回作成したクイズのうち問１〜問３までは、イベント当日に受付で入場者に配られるチラシにロゴの説明として回答を掲載していました。 また、問４はエクストラ問題としてチラシには答えが載っていない問題を用意していました。そのように説明すると「我こそは」と真剣に考えてくださる方が多く、みなさん楽しんで挑戦してくださいました。（この問題の答えはこちらの PAY ID ロゴリニューアル のブログに掲載されています） ノベルティとしてお配りしていたBASEロゴ今治ミニタオル。こだわって作成しているため嬉しいお声をたくさんいただけてたいへん嬉しかったです。 登壇の紹介 かがの（ @ykagano ） speakerdeck.com 今回は購入に失敗したインシデントについてお話しさせていただきました。 ポイントとしては以下の2点と考えています。 クラス名をシリアライズして保存する設計による、クラス削除の影響漏れ 擬似乱数の消費位置を変更したことによる、キー衝突の確率変動 発生原因を深掘りすると複数の要因が重なって発生した、学びのあるインシデントでした。 特に2は資料では割愛していますが、擬似乱数の消費位置を突き止めるために、AIを使って発生パターン（シード43億通り × 消費位置15まで）の総当たりを行い、エラーが発生した2つのキーの消費位置がどちらも5であることを確認しています。 インシデントはなるべく発生させないようにしたいですが、インシデントを通してPHPの擬似乱数の仕組みを知ることができたのはよかったと思います。 PHP Conferenceでの登壇は初めてで緊張しましたが、たくさんの方にお聞きいただきありがとうございました。また次回の開催時にも参加させていただきます。 現地で見たセッションから得た学び・感想（ @wakana ） ブーススタッフとして従事していた時間が長かったため数個のセッションしか見ることができませんでしたが、その中でも特に印象に残ったセッションの感想です。 （登壇の詳細については、登壇者様からアップロードされている資料や、後日公開予定となっているイベント公式アーカイブをご覧ください） Laravelで学ぶ Webアプリケーションチューニング入門　Ryo Tomidokoro氏 speakerdeck.com こちらのセッションでは、Laravelでのアプリケーション開発・運用を例に取ったアプリケーションのチューニング方法の基礎、考え方について発見・再確認することができました。 印象に残った学びは以下です。 「なんか遅い気がする」ではなく、「APIのレスポンス返却が普段より500ms遅くなっている」などの定量的な数値に変換することで議論が行えるようになり、調査を開始することができる。 ブラウザに表示されるまでの経路のうち、Webアプリケーションが占める割合は一部でしかない。Webアプリケーションを改修すると決める前に、プロファイラーを使って本当にWebアプリケーションが遅いことを特定する。 Webアプリケーションが遅いことがわかったら、New Relicやdatadogなどのプロファイラーを使って遅い処理を特定する。ボトルネックは往々にして解決が難しい事が多いが、そこに向き合うことが重要。 ボトルネックから目を逸らすな。 ボトルネックの特定や、改修にあたっては日頃から自分の中に使える手札を増やしておくことが大事。（スライド内で紹介されていたものの一部抜粋） PHP で学ぶ Cache の距離の話 / study_cache_with_php PHPerのための計算量入門/Complexity101 for PHPer 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 個人的にも直近の業務ではプロファイラーツールを用いてチューニングのための分析を行うことが増えてきていたため、タイミングよく今の自分に必要な発表を聞くことができました。 日々の手札を増やしていけるよう、一層精進していきたいと思いました。 そして「ボトルネックから目を逸らすな」肝に銘じます 💪 セレンディピティ～AIで答えが出る時代に、なぜコミュニティへ行くのか？ 小泉岳人 氏 www.docswell.com こちらのLTでは、「AI時代にわざわざコミュニティに足を運ぶ意義はどこにあるのか」という点を伺うことができました。 個人的に、別のカンファレンスやその後の懇親会でも耳にすることが増えてきたテーマだったため、視聴前から興味の強い発表でした。 こちらのLTでは、主に次のような学びを得ることができました。 問いに対する答えを知るだけならAIで行うことができてしまうが、コミュニティに来ると思いがけない出会い（人・情報・etc…）に心を動かされることがある 様々な発表を聞いて、すぐに答えの出ない問いや考えを得て、それを持ち帰ることで、 自分の中で問いを育てることができる 問いを育てながら何度も足を運ぶことで、仲間を作ることができる 特に印象的だったフレーズは「 問いを育てる 」というものでした。 AIを使った開発がスタンダードになり、なんでもすぐにAIに聞くのが当たり前になったいま、自分で考える力が落ちてきているのではと、個人的にも危機感を持っていたタイミングでした。 そんな中で聞いた「 問いを育てる 」というフレーズは、これまでの自分にはなかった視点で、シンプルながら強く心に残りました。 この発表が一日のタイムテーブルの最後に置かれ、直後に懇親会が控えていたことも、「コミュニティに集まる意義」を物語るような構成に感じられて感動しました。 実際、その後の懇親会では、普段よりもさらに深く交流を楽しむことができたと感じています。 参加メンバーからのコメント wakana 今回初めてPHP Conferenceに参加することができました！ ブーススタッフとして朝早くから集まり、カンファレンス後の懇親会まで参加しました。1日を通してとても楽しく充実していて、帰る頃には学生時代の文化祭後のような清々しい疲労感がありました。 スポンサーブースではたくさんの来場者の方とお話することができ、「サービス使ってます！」「ノベルティかわいい！」といった嬉しいお声をいただいたり、さらには「今の仕事を進めるうえで困っていることがあり、BASEさんではどのように解決していますか？」といったディープな内容のお話まで楽しく交流させていただきました。 他のスポンサー企業様のブースにお邪魔した際も、近い悩みを共有できて立ち話が思わぬ盛り上がりを見せました。実は当日の朝までは夜の懇親会に参加しない予定だったのですが、「来られるならぜひお話ししましょう」とお声掛けいただいたのをきっかけに、その場でチケットを購入しました（笑）。おかげで、今後の共同イベントをご一緒する予定の会社様のエンジニアの方とも交流を深められ、思い切って参加して本当によかったと感じています。 セッションで得られる学びはもちろんですが、コミュニティの温かさやウェルカムな雰囲気は、これまで参加したイベントの中でもダントツでした。 ぜひまた参加したいです！ 白数（ かじゅ ） 今回、PHP Conferenceにスポンサーブーススタッフとして初めて参加しました。 スポンサーブースの企画段階から関わり、「あれはどう？」「これはどう？」とメンバーでわいわい意見を出し合いながら、楽しく準備を進めることができました。 実施した「BASEロゴ検定」をきっかけに、1人でも多くの方にBASEが運営するサービスについて知っていただけたら嬉しいです。 当日は、初めてお会いする方々と企画や会話を通じて交流し、セッションもいくつか聴くことができました。 PHPコミュニティの活気を直接感じられる貴重な機会となりました。 三佐和 初参加の PHP Conference でした！ 普段 PHP をあまり書いていない身としては、「参加しても大丈夫かな…」と最初は少し不安もありましたが、スポンサーブースの企画から当日まで携わることができ、とても貴重な経験になりました。 当日はブースに来てくださった方々がクイズを通して BASE のサービスに興味を持ってくださる様子を見ることができたり、普段利用しているサービスの感想を直接聞けたりと、来場者の方々と雑談を交えながらお話しする時間がとても楽しかったです。 また、スタンプラリーにも参加してみましたが、各社それぞれ企画だけでなくノベルティにも個性や特色が表れていて、ブースごとに異なる雰囲気を楽しめたのが印象的でした。 今回のカンファレンスを通して、技術だけでなく、人と人、企業同士がつながることの魅力や、イベントづくりの面白さを感じることができました。 また機会があればぜひ参加したいです！ 地引 初めてPHP Conferenceに参加しました！ 私はスポンサースタッフではなく、インターン生として先輩（Capi(かぴ) さん）と一緒に一般参加させていただきました。 現地で参加したセッションはどれも刺激的で、ものづくりやコーディングを純粋に楽しんでいる熱量あふれる方々の発表がとても印象的でした。AI時代ならではの開発の工夫や考え方にも触れることができ、ものづくりの面白さを改めて実感しました。 懇親会では、BASEの先輩方が本当に温かく、他社のエンジニアの方や先輩のお知り合いの方をたくさん紹介してくださいました。周りに学生が少なく緊張していたのですが、いろいろな方と交流するきっかけを作っていただけたことがとても嬉しく、改めてBASEの温かさを感じました。 技術的な学びだけでなく、新しい人とのつながりやコミュニティの温かさも感じられるイベントで、参加してよかったと心から思える一日でした。 またぜひ参加したいです！ おわりに カンファレンスのクロージング後、一日ブーススタッフお疲れ様、そしてかがのさんLTお疲れ様でした〜！ということでみんなでパシャリ。（一般参加として来ていた Capi(かぴ) さん 地引さん も加わってくれました！） ブーススタッフとして参加したメンバーの内半分以上が初参加というフレッシュな構成でしたが、全員の協力のおかげで何事もなく終えることができました。 また、PHP Conference の運営スタッフのみなさまも、お忙しい中、多くの時間をイベント準備に割いてくださったことと思います。 こんなに貴重な機会をいただけたことに、この場を借りて心より感謝申し上げます。 BASEではエンジニアを募集しています。よろしければ、採用情報もぜひご覧ください！ binc.jp

こんにちは、バックエンドエンジニアのかがの（ @ykagano ）です。 BASEは2026年7月20日(月・祝)に開催されるPHP Conference Japan 2026に今年もゴールドスポンサーとして協賛します。 PHP Conference Japan 2026について PHP Conference Japanは、PHPエンジニアのためのカンファレンスとして毎年開催されている日本最大級のPHPカンファレンスです。 今年は7月20日(月・祝)に大田区産業プラザPiOで開催されます。 phpcon.php.gr.jp 昨年の様子はこちらをご覧ください！ devblog.thebase.in 現在、大田区産業プラザは改修工事中とのことで、少しだけ狭い会場での開催となるようですが、 例年以上の熱量で盛り上げていきましょう！ スポンサーブースについて カンファレンス期間中、スポンサーブースを出展しています。 ブースでは「〜あなたもBASEのGEEKになろう〜」をテーマにクイズを出題し、回答を付箋に書いていただき、共有ボードに掲示する参加型の企画を実施します！ 企画にご参加いただいた方にはささやかながらノベルティをプレゼントいたします！ 皆さまのご参加をお待ちしています！ セッションの紹介 今年はBASEから私、かがのが登壇予定です。 「2年前に削除したPHPクラスが、ある日突然決済をエラーにした」 by ykagano 17:00〜 トラック1 - 2F 小展示 LT(5分) fortee.jp 削除時には検索もテストも完了していたはずのPHPクラスが、2年の時を経て決済エラーを引き起こしました。 なぜ削除時に気づけなかったのか、どのように爆発したのか、そしてどう修正したのかを、実際のインシデントを基にお話しします。 おわりに 連休最終日の開催ですが、暑さに気を付けつつ一緒に楽しみましょう！ PHP Conference Japan 2026でみなさまにお会いできることを楽しみにしています！ BASEはカンファレンスやイベントへの参加や登壇を積極的に支援しています。 もしご興味がありましたら、採用情報もご確認いただけると幸いです。 binc.jp

はじめに こんにちは! BASE株式会社でバックエンドエンジニアをしている若菜( __wakanaction__ )です。 2026年6月25日に幕張メッセで開催された AWS Summit Japan 2026 にて、New Relic ブースのミニシアターで「SLOをサービス品質の共通言語にするために取り組んできたこと」というテーマで登壇してきました。 本記事では、発表の概要にくわえて、当日お伝えしきれなかったことの補足をお届けします。 登壇の概要 本発表は、私と同僚の小笠原の2名で内容を作成しました。 発表資料はこちらです。 speakerdeck.com 発表でお伝えした内容は、大きく2つあります。 1つめは、これまでの取り組みの詳細と、得られた手応えです。BASEでは「主要SLO」という指標を作り、事業部全体への展開とエンジニアによる運用の両軸で同時にスタートさせました。 これにより、サービスレベル活動への事業部全体の認知を獲得でき、これから本格展開していくための地盤を固めることができました。 2つめは、いま見えている課題とこれからの展開です。現状では、まだエンジニア以外の組織から能動的に意見をもらうまでには至っていません。そこでこれからは、カスタム属性をサービスレベル活動で使える基盤を作り、ビジネスサイドで追っているKPIを表現したサービスレベルを作れるようにしていきます。サービスレベルをより身近に感じてもらい、品質の可視化のメリットを体感してもらうことで、「能動的にSLOを作成したい」と思ってもらえることを目指しています。 なお、ここに至るまでの道のりは、当日は話す時間が限られていたためお話しできていませんが、過去の記事 BASEにおけるサービスレベルマネジメントのこれまでとこれから で詳しく紹介されています。こちらもぜひ合わせてご覧ください。 登壇内容の補足 当日は初めての外部登壇ということで緊張もあり、大事なメッセージをいくつか言いそびれてしまいました。この場を借りて補足させていただけたらと思います。 主要SLOに込めた意図 発表では、事業部全体で意識するものとして「主要SLO」という指標を設けたことをお話ししました。 そしてこれを設定するにあたり、事業部全体に向けて下記のようなメッセージを込めていました。 サービスの品質という曖昧なものに、具体的な定義と数値を与える 機能や体験の異なるさまざまなサービスを、数値をもって横並びに比較できるようにする 確たるデータをもとにした評価・改善のサイクルを回せるようにする 上記の思想を基に、主要SLOを「エンジニア以外の人にも数値をわかりやすく追ってもらえるように、エンジニアが運用するSLOを一段抽象化した概念」という形で展開しました。 エンジニアの運用と、事業部全体への周知・承認ルートの確保を同時に進めた意図 発表の中で、BASEでは、エンジニアによるSLO運用の開始と、事業部全体の定例での周知・承認ルートの確保を同時に進めた、というお話をしました。 この点の補足として、この進め方に込めた期待には次の3つがありました。 運用を開始するエンジニアたちに、サービスレベル活動がBASE事業部としても推進している活動であると認識してもらうこと エンジニア以外のメンバーがサービスレベル活動に興味を持ったときに、上長に話を通しやすくすること そして、エンジニアがエンジニア以外を巻き込んでサービスレベル活動を拡大していくときに、話がスムーズに進むようになること つまりこの同時進行は、サービスレベル活動をさらにスムーズに拡大させていくための布石でもありました。 初めての外部登壇を終えて 前述のとおり、今回が初めての外部登壇ということもあり、当日はとても緊張していました。 しかし、終わってみると「もっと上手くできた」「もっとこの点について語りたい」などの気持ちが湧き、これからのサービスレベル活動をますます頑張っていくための励みになりました。 そして、貴重な登壇の機会をいただき、準備の段階から当日まで手厚くサポートいただいたNew Relic社の皆様には大変感謝しております。 当日はキーノートセッションの裏の時間帯だったにもかかわらず、たくさんの方が発表を見に来てくださり、とても嬉しかったです。 今後も引き続きサービスレベル活動の推進に懸命に取り組んでいきたいと思います。 おわりに AWS Summit Japan 2026 の New Relic ブースでの登壇についてご紹介しました。 BASEでは、SLOをはじめとしたサービス品質への取り組みを一緒に進めていく仲間を募集しています。興味のある方は、ぜひお気軽に採用情報をご確認ください。 binc.jp

はじめに こんにちは、バックエンドエンジニアの小笠原（ @yukineko_819 ）です。 Checkout Reliabilityチームに所属し、負荷試験環境の構築や購入ロジックの最適化など、購入体験の信頼性向上に向けた取り組みをしています。 今回は、「どのショップでも、いつでも安定して購入できる」という購入体験を守るために、購入時のクレジットカード決済へ流量制御（以降、レートリミッタ）を導入した話をご紹介したいと思います。とくに、 特定のショップに購入が集中しても、ほかのショップでは決済ができる状態にする ために、アクセス集中の影響をできる限り抑え、全体の購入可用性を平準化する設計をどう考えたか、というところが中心になります。 あるショップにアクセスが集中している時、ほかのショップで購入ができない まずは、私たちが解きたかった問題からお話しさせてください。 一般的に、決済処理には安定稼働のために単位時間あたりに捌ける流量の上限が設定されており、これを決済流量制限（以降、決済レートリミット）と言います。平常時であればこの決済レートリミットを意識することはほとんどありません。しかし、大型の販売イベントや限定商品の販売といったケースで、特定のショップに対してごく短期間に購入が一気に集中している時、この決済レートリミットが問題になります。 このとき、購入が集中しているショップの決済で決済レートリミットに達すると、まったく無関係なほかのショップにも影響が及んで制限がかかり、購入できなくなってしまう可能性があります。 これは購入者から見れば、自分にもショップにも何の落ち度もないにもかかわらず購入できない、というマイナスの体験となってしまいます。ネットショップの買い物体験として、これほど避けたいものはないでしょう。 いつでも買えるカートを目指して そこで私たちが目指したのは、特定のショップに購入リクエストが集中している状況でも、ほかのショップではいつもどおり購入できる状態を保つことでした。これを実現するために、次の2つを満たすレートリミッタの設計を考えました。 1. 流量を自分たちで把握して制御する ひとつめは、流量を自分たちでカウントして能動的に制限をかけることです。決済レートリミットに到達しているか否かわからないまま決済を実行するのではなく、安定して捌ける範囲の上限を自社側で定義し、あえて能動的に流量を絞る方針を取りました。 2. その他のショップの取り分を「引き算」で残す ふたつめは、アクセス集中ショップとその他のショップを分けて管理することです。これまではアクセス集中ショップが流量を独り占めしてしまい、その他のショップの決済が通らなくなってしまう危険がありました。そこで、あえてアクセス集中ショップに本来の上限値よりも少しだけ低い上限を設定し、残った流量をその他のショップが使えるようにする、という方針を取りました。 この設計のポイントは、その他のショップ用の流量を予め確保しておくのではなく、アクセス集中ショップの上限値にキャップをかける形にしたことです。アクセス集中ショップといっても常に上限に張り付いているわけではありませんし、その他のショップでの購入がたまたま同時刻に重なってリクエスト数がはね上がる可能性もあります。この方針は、その他のショップ側の流量に不要な制限をかけてしまわないようにするという意図があります。 図1: アクセス集中の影響を抑え、その他のショップの取り分を「引き算」で残す どう作ったか ここからは、より具体的な処理フローの話に移りたいと思います。 決済を実行する直前に、1トークンを要求する レートリミッタをどこに挟むべきか検討した時、私たちは決済処理を実行する直前に挟むことにしました。 決済処理は、その実行前にレートリミッタへ「1トークンください」と要求します。このレートリミッタの実体は、専用のRedis上でアトミックに実行される Luaスクリプトで、古典的なトークンバケットとして振る舞います。 なぜLuaなのかというと、「トークンの回復 → トークン残量を確認する → トークンを消費する」という一連の判定をひとつのアトミックな操作にまとめたかったからです。こうしておけば、同時に大量のリクエストが来ても、競合することなく正しくカウントできます。 このレートリミッタは、トークンが残っていればトークンを消費してOKを返し、制限と判定されればNGを返します。レートリミッタを呼び出したアプリケーション側は、判定がOKであればそのまま外部APIを実行して決済に進みます。NGであれば外部APIを実行することなく、決済を諦めて処理をエラーで終了させます。 グローバルバケットとアクセス集中ショップ用バケットの2段構成にする ただ、総量を制御するだけでは足りません。先着順でトークンを奪い合うと、アクセス集中ショップが全てのトークンを独占してしまい、その他のショップが締め出されてしまうからです。これでは今までと何も変わりません。 そこで中核になるのがアクセス集中ショップ用に別途専用のトークンバケットを用意するという方法です。 全ショップが共通のグローバルバケットからトークンを消費する アクセス集中ショップだけアクセス集中ショップ用バケットからも追加で消費する アクセス集中ショップ用バケットの上限をグローバルバケットより小さく設定する ポイントは、アクセス集中ショップではないショップ向けのバケットを明示的に確保しているわけではない、というところです。あえてアクセス集中ショップ側を絞ることで、その差分がその他のショップの取り分として引き算で自動的に残るようにしています。 この設計には、 work-conserving （余力を遊ばせない）という嬉しい性質があります。アクセス集中ショップがなければグローバルバケットは誰でも使えるので、トークンが余ることはありません。アクセス集中ショップが現れて初めて、その分だけアクセス集中ショップ用バケットの制約が効き始める、というわけです。 判定のルールを整理すると、次のようになります。 アクセス集中ショップ ： グローバルバケットとアクセス集中ショップ用バケットの両方に空きがあってはじめて許可。 その他のショップ ：グローバルバケットに空きがあれば許可。 図2: その他のショップはグローバルバケットだけ、アクセス集中ショップは両方の空きが必要 なお、レートリミッタが制限と判定したときはトークンを消費しないようにしています。これは、弾いたリクエストでトークンを消費してしまうと本来なら通せたはずの後続のリクエストにまで影響が及んでしまうからです。 アクセス集中ショップをどう見分けるか アクセス集中ショップをどう判定するか、という点にも少し工夫が要りました。 素朴に閾値だけで判定すると、ショップの状態が閾値の前後で行ったり来たりしてしまい、挙動が安定しません。 そこで、ショップごとに単位時間あたりの決済リクエスト回数をカウントし、一定以上に達したらアクセス集中ショップと判定するようにしました。さらに、一度アクセス集中ショップと判定されたらしばらくはそのフラグを引き継ぐクールダウン期間を設けています。このクールダウン時間は、実際の過去のリクエストの状況を分析して決定しました。 Off → Observe → Enforce、3つのモードで段階的に出す 決済という事故が許されない経路に新しい制御、それも決済を能動的に遮断する機能を入れるわけですから、リリースの手順は慎重に検討しました。いきなり遮断するようなことはせず、フィーチャーフラグで3つのモードを切り替えられるようにして段階的にリリースできるように設計しました。具体的には、以下の3つのモードを管理画面から瞬時に切り替えられるような作りにしました。 Off ：完全な機能OFF状態。Redisにも通信しない、完全に無害な状態で本番に導入する。 Observe ：制限の判定はするが、制限はせずに全て許可する状態。「もし遮断していたら、いつ・どれだけ弾いていたか」を記録するだけにとどめる。このモードで誤って制限してしまうケースがないかを本番のデータで実測する。 Enforce ：制限の判定を行い、遮断も実行する状態。この状態で初めて本格的なレートリミッタの挙動がリリースされる。 万が一 Enforce で誤った遮断が起きても管理画面からフラグを即座にObserveへ戻すだけで、デプロイなしに誤遮断を解除することができます。さらに、この状態の計測自体は継続することで、何が起こったか後から分析できるように情報を残すこともできます。この「デプロイなしで止められる」「後から分析できるデータも残せる」という安心感は、本番に投入していくうえで大きく効いたと感じています。 レートリミッタで決済を止めないようにする 当然ですが、流量制御のために導入したレートリミッタ自身が新たな障害点になってしまっては本末転倒です。レートリミッタの不調で決済全体が止まってしまうのは、避けたい事態の中でも最悪の部類だといえます。 そこでRedisに異常があったときは判定をスキップして決済を通すfail-open方針にしました。「厳密に上限を守ること」よりも「決済を止めないこと」を優先する、という価値判断です。あわせて、判定にかけるタイムアウトはごく短期間に設定し、Redisが重くなったときも素早く安全側に倒れて、決済の本流の足を引っ張らないようにしています。 すべての判定を観測する 最後は観測の話です。すべての判定経路で、レートリミッタの呼び出し毎に1つのイベントを記録するようにしました。 記録しているのは、どのモードで動いていたか（Off / Observe / Enforce）、許可したのか制限したのか、制限判定の理由（グローバルバケットで弾いたのか、アクセス集中ショップ用バケットで弾いたのか）、処理にかかった所要時間、そしてfail-openが発生したかどうか、といった情報です。 特に Observe モードで記録した「もし遮断していたら弾いていたはずの量」は、Enforce へ昇格してよいかを判断するための一次データになります。また、レートリミッタが事前に遮断したものと、決済処理そのものが失敗したものとでは意味がまったく異なるので、ログには専用のタグを付けて、両者をはっきり区別できるようにしています。 おわりに 今回は、購入時のクレジットカード決済に流量制御を導入した話をご紹介しました。 やったことを一言でまとめると、 特定のアクセス集中ショップに購入が集中しても、その他のショップに影響が及ばないように、限られた決済の流量を能動的に制御することで受け止められるようにした 、ということになります。決済の流量を1つのグローバルカウンタで測って制御しつつ、アクセス集中ショップ用バケットによってアクセス集中ショップの流量に少しだけきつめの制限を設け、その他のショップの決済分を引き算で残す。そして3つのモードで安全に段階リリースし、万が一レートリミッタ自身が不調になってもfail-openで決済を止めない。 ひとつ補足しておきたいのは、これは「決済の処理能力がこれ以上伸ばせないから絞っている」という話ではない、ということです。実は、既存の実装を整理することで、レートリミッタを導入してもなお、単位時間あたりに捌ける決済の流量そのものはむしろ増えています。だからこそ今回、思い切ってアクセス集中ショップに制限を設けるという判断ができました。レートリミッタ導入前と比べても、アクセス集中ショップが単位時間あたりに購入できる流量はむしろ増えているのです。 そのうえで、限られたリソースのバランスを短期的に取るための手段として、レートリミッタによる制御を併用している、という位置づけです。一部のショップへのアクセス集中でシステム全体が不安定になれば、影響を受けるのはほかのショップだけでなく、アクセスが集中しているショップ自身も同じです。全体を安定して動かし続けることこそが、結果的にすべてのショップの購入機会を守ることにつながると考えています。 もちろん、ここで満足しているわけではありません。処理能力そのものの引き上げや、ほかの選択肢の検討も含めて、「どのショップでも、いつでも買いやすいカート」を目指して改善を続けていきます。 派手な機能ではありませんが、「どのショップでも、いつでも購入できる」という当たり前を裏側で支える仕組みとして、地味に効いてくれるものになったのではないかと思っています。今回のような改善はユーザーの目に直接見えるものではありませんが、快適な購入体験のために、Checkout Reliabilityチームではこういった細やかな改善を引き続き積み重ねていきます。 BASE では、「どのショップでも、いつでも購入できる」という当たり前を、こうした地道な設計と運用で支えていく仲間を募集しています。カートや決済まわりの信頼性に興味がある方は、ぜひお気軽に採用情報をご確認ください。 binc.jp

CTO の川口( id:dmnlk )です。 最近、社内で「とりあえず HTML にして置いておくね」という会話を当たり前のように耳にするようになりました。きっかけは、社内 HTML をホストするだけのささやかな環境をひとつ用意したことです。たったそれだけのことなのに、気づけばエンジニア以外のメンバーまで使い始め、社内の情報の流れそのものが変わっていきました。 この記事では、なぜそんな環境を作ったのか、どう作ったのか、そして実際に何が変わったのかを書きます。 きっかけ：AI が生むドキュメントは「流通するが、読まれない」 AI コーディングが日常になって、社内には実装計画 (plan) や設計メモのようなドキュメントが一気に増えました。Claude Code などに計画を立てさせると、その plan ファイルがそのまま成果物として共有されます。これ自体はとても良い変化でした。 ただ、困ったことがひとつありました。 流通はするのに、人間が読むのに適していない のです。 Markdown やテキストのまま Slack や Git に流れてくる とにかく長く、構造はあるはずなのにプレーンテキストだと頭に入ってこない リンクや図が活きず、コードブロックと地の文が地続きで視線が迷子になる 「内容は良いはずなのに、最後まで読む気にならない」。AI が書いたドキュメントが増えれば増えるほど、この摩擦が社内のあちこちで起きていました。 なぜ Notion ではなく HTML だったのか 「読みやすく共有したいだけなら Notion に貼ればいいのでは」とも考えました。実際、しばらくはそうしていました。けれど、どうもしっくりきませんでした。 自由度が足りない 。レイアウトや見せ方が Notion の枠に収まってしまう 凝った表現や、AI に「読みやすい形に整形して」と頼んだときのアウトプットを、そのまま再現できない 結果として「読みやすくしたいから貼り直す」手間が発生し、誰もやらなくなる 一方、AI に「この plan を読みやすい HTML にして」と頼むと、見出し・目次・強調・配色まで含めて、驚くほど読みやすい 1 枚の HTML を出してくれます。 HTML はそのまま渡せばそのまま表示できます 。この「変換を挟まない素直さ」が、Notion にはない強みでした。 足りないのは「その HTML を、社内の人だけがサッと見られる置き場所」だけです。それなら作ろう、と考えました。他社事例を多く見るタイミングでもあり、自作することに決めました。 最近、社内でHTMLで共有する事が多くなってきたので、空き時間にサクッと社内でHTMLを共有するサービスを作った。公開範囲を柔軟に設定できたり、Slackで簡単に共有できたり、esaやNotionに埋め込みで貼り付けれたり、かゆいところに手が届く感じで非常に便利。 Goodpatch社内のみです。 pic.twitter.com/iQPEXY5kT0 — 土屋尚史 / Goodpatch (@tsuchinao83) 2026年6月3日 ssss-app.com https://t.co/yBJmpJId6P — 鈴木慎吾 / TSUMIKI INC. (@shingo2000) 2026年6月15日 作ったもの：GCS + Cloud Run + IAP 構成はできるだけ薄く、運用に手がかからないことを最優先にしました。 保管: Google Cloud Storage (GCS) — HTML と付随アセットをそのまま置くだけです。バケットにアップロードすれば、それが 1 つのページになります。 配信: Cloud Run — GCS の中身を返すだけの薄いサーバーを 1 つ置きます。フルマネージドなので、アクセスがなければゼロまでスケールインし、コストもほぼかかりません。 認証: Identity-Aware Proxy (IAP) — この環境の肝です。Cloud Run の手前に IAP を噛ませ、社内の Google Workspace アカウントを持つ人だけがアクセスできるようにしました。社内の人はすでに Google にログインしているので、URL を開くだけで（追加ログインなしで）中身が見えます。逆に、社外の人にはそもそも到達できません。 昔は IAP を利用するには Load Balancer などが必要で大変でしたが、今は Cloud Run に IAP を直接設定できるため、低コストで実現できました。 ポイントは、 認証を自分たちで実装していない ことです。社内ドキュメントのホスティングで一番こわいのは「うっかり世界に公開してしまう」ことですが、そこを IAP に丸ごと預けられます。「Google にログインできる社内の人だけ」という、最初から欲しかったアクセス制御が、ほぼ設定だけで手に入りました。 あとは「HTML をアップロードしたら社内 URL が発行される」という体験さえ整えれば、書き手は中身に集中できます。 何が起きたか：エンジニアから、全職種へ 最初の使われ方は、ごく素朴なものでした。 エンジニアが plan を読みやすくするため だけに使っていたのです。AI が出した実装計画を HTML にして置き、URL を共有します。レビューする側も「これは読む気になる」と言ってくれます。それだけでも十分に元は取れていました。 変化が面白くなったのは、ここからです。 その URL を見たエンジニア以外のメンバーが、「自分の資料もこうやって置けるの?」と気づき始めました。やがて 財務・経理のメンバーが、自分たちの資料を HTML にして共有する ようになっていきました。スプレッドシートや長い文章ではなく、要点が整理された 1 枚の読みやすいページとしてです。 気づけば、社内の情報共有のデフォルトが少し変わっていました。 「資料を作る＝読みやすい 1 枚にまとめて、URL で渡す」が自然な選択肢になった 部署をまたいで「あの URL 見た?」という会話が増えた AI に整形を任せられるので、 読みやすい資料を作るコスト自体が下がった 「読みやすく共有する」ことのハードルが下がると、共有される情報の量と質が両方とも上がります。情報の流れが変わるとは、こういうことかと実感しました。 運用してわかったこと 薄く作って正解でした。 凝った CMS にせず「HTML を置くだけ」にしたことで、書き手は自由に表現でき、運用側もほぼメンテ不要です。 認証を IAP に寄せたのは精神的に大きいです。 社内ドキュメントを置くうえで「公開事故が構造的に起きにくい」という安心感が、気軽さを支えています。 置きっぱなしのドキュメントが肥大化しないよう、デフォルトでは 7 日で自動削除されるようにしました。 API を用意し、CI 環境からも受け付けられるようにして、パフォーマンスレポートなどを CI で更新できるようにしました。 MCP も簡易的に作り、Claude Code や Codex などから手軽にアップロードできるようにして、敷居を下げました。 重要なこと 社内で広く使われるようになった一因は、システムの名前だと思っています。キャッチーな名前にすると、社内の文脈に浸透しやすくなります。元々「ファイルをポンと置きたい」くらいの気持ちで始めたので、サービス名は「pon」にしました。すると社内では「資料を pon しました」といった形で話題に上がるようになり、一気に広まったように思います。社内ツールの名前は、想像以上に重要です。 まとめ 社内に HTML をホストする環境を作ったのは、「AI が生む読みづらいドキュメントを読みやすくしたい」という小さな動機からでした。GCS + Cloud Run + IAP という薄い構成で、認証は IAP に任せきりです。技術的には派手さのない仕組みです。 それでも、エンジニアの plan 共有から始まった使われ方がエンジニア以外の職種にまで広がり、社内の情報の流れそのものを少し変えていきました。「読みやすく共有するコストを下げる」だけで組織の情報の流れはこんなに変わるのか——というのが、作ってみての一番の発見です。 似たような「ドキュメントは増えたのに読まれない」課題を抱えている方の参考になれば嬉しいです。

はじめに こんにちは、BASE株式会社 Product Governance（通称：プロガバ）チームの緒方です。 突然ですが、皆さんは「IT統制」や「ガバナンス」と聞いてどんなイメージを持ちますか？ 「開発スピードが落ちそう」「お堅い事務作業」……そんな風に思われがちなこの領域ですが、我々は少し違います。 今回は、私たちがどのような思いで「守り」を「攻め」に変える仕組み作りをしているのか、その裏側をお話しします。転職を考えている方も、そうでない方も、新しいキャリアの形としてご一読いただければ幸いです。 3年半で激変した、BASEのIT統制を取り巻く環境 前回、 IT統制についてのブログ を投稿させていただいてから早くも3年半が経過しました。この間、BASEグループは目まぐるしい変化を遂げています。 2024年のwant.jp、2025年のEストアー、そして2026年のPortと、次々と新たな仲間がグループに加わりました。これだけでも大きな変化ですが、同時に「PAY.JP」や「YELL BANK」といった既存プロダクトも右肩上がりで業績を拡大しています。 （「 事業計画及び成長可能性に関する事項 」より抜粋） 事業が広がり、複雑さが増せば、当然ながらJ-SOX（内部統制報告制度）における評価対象範囲も年々広がっていきます。 「異なる文化やシステムを持つ組織でどこまで共通の整備を行っていくべきか？」 「急成長する決済・金融事業の信頼性をどう担保するか？」 BASEの行動指針である「Move Fast」を維持しながら、上場企業としての「信頼性」を鉄壁なものにする。この難易度の高いミッションに、かつてないほどやりがいと魅力を感じつつ、日々取り組んでいます。 結局、プロガバって何をする人？ 私たちの役割を一言で言えば、 「プロダクトの成長を支える、ガバナンスの設計者」 です。 大きく2つのミッションがあります。 開発現場と監査の「最高の通訳」になる 監査法人や内部監査室が求める「守り」の基準と、エンジニアが求める「開発の自由度」。この一見相反する両者の間に立ち、エンジニアリングの知識をフル活用して「これなら現場も納得できるし、統制も取れる」という最適解を導き出します。 ガバナンスを「仕組み」で解決する（Engineering for Governance） プロダクト開発のスピード、業務スピードを落とさないためにも「手作業でチェックして承認をもらう」ような面倒なプロセスは徹底的に排除します。以下は主な具体例です。 GitHub Actions / GAS / Slack App を駆使した証跡取得の自動化 AI（LLM） を活用したシステムログチェックの効率化 非エンジニア部門に対する内部監査室と連携した業務フローの再構築やシステム化の提案 「ルールを押し付けるのではなく、ルールを意識しなくて済む仕組みを作る」 ことを目指しています。 ここで働くからこそ得られる「プロガバの魅力」 IT×会計・監査のハイブリッドキャリア 技術スタック（AWS, GitHub, SQL等）を維持しながら、ビジネスの根幹である経理・法務・監査の深い知識が身につきます。この両方の言語を話せる人材は市場価値が極めて高く、エンジニアとしてのバックグラウンドを活かした「唯一無二の専門性」を築くことができます。 グループ全体を俯瞰する「鳥の目」が手に入る 特定の機能開発や一つのプロダクトにとどまらず、グループ各社の事業成長や組織構造を横断的に見渡すことができます。経営層に近い視点で「組織がどう動いているか」を肌で感じ、プロダクトを俯瞰して捉えられるのは、このポジションならではの醍醐味です。 AI時代だからこそ光る、代替不可能な「人間力」 昨今、多くの業務がAIに置き換わろうとしていますが、プロガバの仕事の核は「正解のない問いに、人間としての納得感を持って答えを出すこと」にあります。 ルールを自動化する仕組みはAIで作れるかもしれませんが、「このリスクをどう解釈し、開発現場の熱量を削がずにどう落とし込むか？」という高度な判断や、ステークホルダーとの泥臭い調整は、人間にしかできません。ここで得られる経験やビジネススキルは、AIには当面取って代わられない、一生モノの武器になると確信しています。 おわりに 現在、BASEグループではこの「Product Governance（プロガバ）」を一緒に作り上げていく仲間を強く求めています。 「ガバナンスの経験はないけれど、技術を使って組織を良くすることに興味がある」 「エンジニアとしての経験を、より経営に近い領域で活かしてみたい」 そんな思いをお持ちの方、まずは難しく考えず、カジュアルにお話ししてみませんか？ 👉 [Product Governance の求人詳細・応募はこちら] open.talentio.com また、プロガバ以外にも、BASEグループではさまざまな職種・ポジションで募集を行っています。 「BASEという会社そのものに興味が湧いた」 という方も、ぜひ一度採用ページを覗いてみてください。 👉 [BASE株式会社 採用サイト] binc.jp

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEがブロンズスポンサーとして協賛しているカンファレンス、 TSKaigi 2026 のご紹介となります。 2026.tskaigi.org TSKaigi 2026 概要 私たちは、誰かの発表を聞くだけでなく、他の誰かに向けて発表することもまた学びの一つだと考えています。 参加者、登壇者、スタッフ、スポンサーをはじめ、TSKaigi に関わるすべての人たちが互いに学び合い、新たな繋がりを生み出し、型にとらわれないエンジニアとして生き生きと活躍できる世界を目指します。 TSKaigi 2026 公式サイト TSKaigiは「TypeScript」をテーマとした日本最大級の技術カンファレンスです。 2026/5/22（金）- 5/23（土）の2日間、ベルサール羽田空港＆オンラインで開催されます。 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in TSKaigi 2026 協賛の背景 BASEでは複数のプロダクトでTypeScriptを採用しており、日々の開発において欠かせない技術のひとつになっています。 そうした背景もあり、TypeScriptに関する知見が集まるコミュニティや、その盛り上がりを支える取り組みを応援したいという思いから、今年もTSKaigiに協賛しています。 2025年から2年連続で協賛しており、今後もコミュニティとの関わりを大切にしていきたいと考えています。 おわりに 昨年同様、今年も参加予定のメンバーがいますので、後日イベントレポートをお届けできればと思っています。楽しみにお待ちください。 TSKaigi 2026で、みなさまにお会いできることを楽しみにしております！ よろしければ、ぜひ採用情報もご覧ください。 binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第3回の記事です。 先に第1回、第2回を読んでいただくのをおすすめします。 継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像 - BASEプロダクトチームブログ 継続的な負荷テスト環境をBASEに構築しました 〜 第2回: 負荷生成ツールの構築と運用 - BASEプロダクトチームブログ こちらは第1回から紹介しているBASEの負荷テスト環境の構成図です。 負荷テスト環境の構成図 本記事では、モックツールとして採用したWireMockの選定理由から、実際の構築・運用方法までを紹介します。 モックツールの選定 モックツールも要求事項は負荷生成ツールと基本的には同じでした。 以下は第2回の記事からの要求事項の引用です。 OSSである クラウドはコストとセキュリティの両面でハードルが上がるため 分散実行が可能である 継続的負荷テスト環境としてスケーリングは必要 Web UIがある レポート品質が高い 学習コストが低い メンバーの誰もが利用できるようにしたい 実績が豊富である OSSが今後も保守される可能性が高い こちらもOSSの比較表を参考として整理しました。 ツール 分散実行可能 Web UI 学習コスト 実績が豊富 特徴 WireMock △（自前スクリプトが必要） △（標準UIなし） ○（機能が豊富） ◎ 業界標準。機能は強いが、UIと分散は独自実装が必要 MockServer △（状態は共有できない） ○ ○（機能が豊富） ○ UIあり・機能も豊富 Smocker △（分散は想定されていない） ○ ○（YAML/JSON定義が直感的） △ UI特化・軽量。個人/小規模チーム向け モックツールは他にも多数あるのですが、実績や保守性がWireMockとMockServerが突出しているように感じたため、まずこの2つを候補としました。 そして他のツールもWeb UIをそれぞれ実際に触ってみた結果、SmockerのUIが使いやすく思えたため候補に加えた形です。 しかし保守性を考えると実績の豊富なWireMockが良いと思っており、UIの課題と分散実行の部分をクリアできないかと調査を進めました。 継続的な負荷テストを実施するためには、複数のモックサーバーに対して、スタブの設定を容易かつ即時で変更できるUIが必要と考えていたためです。 WireMockのサードパーティのUIも探しましたが、複数のWireMockインスタンスに即時で反映できるようなUIはありませんでした。 そのため、個人的にWireMock HubというOSSを作ることにしました。 ykagano.github.io スタブの編集がUIから行え、複数のWireMockインスタンスに即時で反映できる機能をメインに実装しています。 WireMockと組み合わせることで、使い勝手の良い負荷テスト用のモックツールとなります。 wiremock.org WireMockの構築 ECSに構築しました。 下図では負荷テスト用にWireMockを2台起動しています。 Nginxは外部APIのRate-Limiter（流量制限）を再現するために使用しています。 ECSでのWireMockの構成 またその後ろにWireMock HubのAll-in-One版を起動しています。 1つのコンテナの中にNginx + WireMock Hub + WireMockを内包しています。 負荷テストのために、Web UIを持つWireMock Hubがスタブデータの管理とWireMockへの同期を行います。 負荷テスト用のWireMockは負荷テスト利用時にだけ起動していますが、WireMock Hubだけを日常的に起動しておくこともできます。 こうすることで負荷テスト以外の場面でも、外部APIの異常系のテストなどでWireMock Hubの内包するWireMockをUI付きで日常的に使用することができます。 今回負荷テスト環境を構築しましたが、副産物として、日常的にWireMockを使用できるようになったものとなります。 WireMock Hubの構成 WireMock HubはSQLiteのDBを持っています。 プロジェクトの配下にWireMockのインスタンスとスタブが紐付く構造にしています。 そのため、プロジェクトの持つスタブをインスタンスに対して入れ替えることも可能になっています。 プロジェクト ├─ インスタンス └─ スタブマッピング 実際にWireMock Hubに登録しているプロジェクトです。 WireMock Hubのプロジェクト画面 次はインスタンスです。 WireMock Hubのインスタンス画面 例えば、過去のプロジェクトで使用したスタブをもう一度使いたいという時に、プロジェクトの持つスタブを同期させて入れ替えることも、追記して他のプロジェクトで同期したスタブと同居することもできます。 このように、WireMock HubはWireMockを1台だけ利用したい場合にも便利に使えるようになっています。 WireMock Hubからのスタブ登録 WireMock Hubからのスタブの登録方法は以下の3種類があります。 UIでのスタブ編集（下図 Create Newボタンや編集アイコンボタン） スタブファイルのインポート機能（下図 Importボタン） プロキシ機能を使ったレコーディング機能（下図サイドメニューのRecording） WireMock Hubのスタブマッピング画面 このうち、負荷テスト環境の構築時は、主にレコーディング機能とインポート機能を使っていました。 レコーディング機能 レコーディング機能はWireMockが標準搭載している機能です。 まだ何もスタブに登録していない場合、レコーディング機能はとても役に立ちます。 WireMock Hubのレコーディング画面 レコーディング画面でTarget URLを指定して開始すると、WireMockが対象のURLに対するプロキシ（中継サーバ）になります。 この状態でBASEシステムと外部システムの間にWireMockを挟んで通常のリクエストを通すことができます。 図にするとこのように右上から通常の購入リクエストがBASEシステムに入ってきますが、 BASEシステムが左のWireMockに外部サービスへのリクエストを投げて、結果、外部サービスにリクエストが到達します。 WireMockがプロキシとして外部サービスに通信している図 こうすることで、WireMockに実リクエストが記録されます。 レコーディングを停止するとWireMockには記録された実リクエストがスタブとして登録されます。 WireMockのリクエストログにも記録されているため、リクエストログからWireMock Hubにスタブ登録することも可能です。 その後、汎用的なスタブにするための調整は必要ですが、レコーディング機能を使えば、スタブデータを手で書くことなく登録できます。 インポート機能 インポート機能はWireMock HubからWireMockのJSON形式とOpenAPI形式の両方がインポートできます。 WireMock形式のJSON例 { " mappings ": [ { " request ": { " method ": " GET ", " url ": " /test " } , " response ": { " status ": 200 , " headers ": { " Content-Type ": " application/json " } , " body ": " { \" message \" : \" success \" } ", " fixedDelayMilliseconds ": 2000 } , " priority ": 5 , " persistent ": true , " name ": " テストだよ ", " scenarioName ": " test ", " requiredScenarioState ": " Started ", " newScenarioState ": " Step_2 ", " metadata ": { " hub_isActive ": true } } ] , " meta ": { " total ": 1 } } 例えばレコーディング機能で記録したスタブを、WireMockのJSON形式でエクスポートしておけば、以降はClaude Codeで編集することができます。 例えばモニタリングツールに記録された外部APIの通信時間の平均をスタブの遅延時間（fixedDelayMilliseconds）に一律で設定するといったこともできますし、実際にこうしたスタブの設定調整をClaude Codeを通して行っています。 WireMock HubからWireMockへの自動同期 WireMock HubはWireMockとは疎結合なアプリケーションとして設計しています。 そのため、ECSでWireMockを再デプロイした場合、WireMock Hubに登録していたWireMockインスタンスのIPアドレスが変わってしまうことになります。 毎回、WireMockインスタンスのIPアドレスを調べて再登録せずに済むように、WireMock Hubにはインスタンスの再登録APIを用意しています。 下図が同期処理のシーケンス図となります。 LambdaのAPI経由でインスタンスIPリストを取得し、WireMock HubのAPIに渡すことで、インスタンスIPアドレスを更新し、WireMock Hubのプロジェクトに紐付くスタブをWireMockに自動同期します。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant gha as GitHub Actions participant tf as Terraform participant ecs as ECS Fargate<br/>(WireMock Worker) participant sd as Service Discovery<br/>(Cloud Map) participant lambda as Lambda<br/>(wiremock-sync) participant hub as WireMock Hub %% Phase 1: Terraform デプロイ Note over gha, ecs: Phase 1: Terraform デプロイ gha ->> tf : wiremock-hub apply activate tf tf ->> hub : WireMock Hub デプロイ activate hub tf -->> gha : apply 完了 deactivate tf gha ->> tf : wiremock apply activate tf tf ->> ecs : WireMock Worker デプロイ activate ecs ecs ->> sd : タスクIP自動登録（HEALTHY） note right of sd : wiremock-worker.cart-load-test.local<br>→ 172.20.10.x tf -->> gha : apply 完了 deactivate tf %% Phase 2: GitHub Actions による Lambda invoke Note over gha, lambda: Phase 2: Lambda invoke gha ->> lambda : aws lambda invoke activate lambda %% Phase 3: Lambda 処理 Note over lambda, sd: Phase 3: Service Discovery からインスタンス取得 lambda ->> sd : discover_instances（HEALTHY のみ） activate sd sd -->> lambda : インスタンスIPリスト返却 deactivate sd %% Phase 4: Hub API → スタブ配信 Note over lambda, hub: Phase 4: Hub API 呼び出し → スタブ配信 lambda ->> hub : POST /hub/api/projects/{id}/instances/bulk-update note right of hub : {"instances": [...], "syncStubs": true} hub ->> hub : インスタンスIP更新 hub ->> hub : プロジェクトのスタブ定義を取得 hub ->> ecs : POST /__admin/mappings（各 Worker） ecs -->> hub : スタブ登録完了 hub -->> lambda : 同期結果 lambda -->> gha : 完了 deactivate lambda deactivate ecs deactivate hub この仕組みによって、WireMock側の再デプロイをしても、負荷テストに必要なスタブは常に担保されます。 おわりに WireMockはノーコードでスタブが作れますので、開発中APIの代替や異常系の通信テストなどにも便利です。 今回作ったWireMock環境は、カート機能だけでなく、社内で誰でも使えるモックツールとして日常的に使っていければと思います。 全3回の記事を最後までお読みいただきありがとうございました！ モックを使ったテストに興味がありましたらぜひ採用情報をご覧ください！ binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ 2026/4/11（土）に開催されたPHPカンファレンス小田原2026にブース出店し、今年は「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施しました。 こちらの特設サイトからスタンプラリーをすることができます（5/11までの限定公開）。 odawara2026.thebase.in 当日のスタート地点となっていたUMECOのスタンプ獲得画像です。 UMECOでのスタンプ獲得 BASEをご利用のショップオーナーにご協力いただき、UMECO周辺の実店舗をスタンプラリーのチェックポイントとさせていただきました。 ご協力いただいたショップオーナーの皆さまありがとうございました！ スタンプラリーサイトの実績 早速ですが、スタンプラリーサイトの実績についてです。 4/11のアクセスユーザー数とスタンプ獲得数がこちらになります。 対象 件数 アクセスユーザー数 75 スタンプ獲得数 63 スタンプ種類数 6 今回のイベント参加者は150名ほどと伺っていたので、約半数の方にアクセスいただけて嬉しいです。 スタンプを全種類獲得された方はまだいませんが、ご自身のスマホでほとんどの方が最初のスタンプは取っていただけたようです。 当日は暑かったため、散歩するにはあまり向いていなかったと思います。それにも関わらずスタンプを獲得していただいた皆さまありがとうございました。 以降はスタンプラリーサイトの企画から実装についてお話ししていこうと思います。 スタンプラリーサイトの企画 私はこれまで何度かブーススタッフを担当してきましたが、企画段階から参加したのは今回の小田原イベントが初めてでした。 今回のスタンプラリーサイトの企画が、これまでと大きく方向性が変わったのは同僚の 02さん （@cocoeyes02）からの一言がきっかけだったと思います。 Slackでの02さんの投稿 こちらの発言の後、ブレインストーミングをして、アイデアを持ち寄った後、最多投票だったのがシンプルスタンプラリーでした。 Figmaの付箋 この段階ではまだどうやってやるかは決まっておらず、ボード型のマップにするのか、パンフレット型のマップにするのか色々と話し合った結果、今はバイブコーディング（AIへ会話的にコードを高速生成させる開発スタイル）もあるので、スタンプラリーサイトを作ってみようということになりました。 スタンプラリーサイトの実装 スタンプラリーサイトはClaude Codeを使って実装しました。 実装期間は合計で3日程度でした。 技術スタック 技術スタックは以下を使用しています。 レイヤー 技術 フロントエンド HTML / CSS / Vanilla JavaScript フロントエンドデプロイ S3 + CloudFront マップ Leaflet.js + OpenStreetMap バックエンド AWS Lambda (Node.js) フロントエンドはビルドのないシンプルな作りとなっており、バックエンドもサーバーレスです。 データの永続化 当初、LocalStorageにスタンプ獲得を記録するプロトタイプを作ったのですが、会社で同僚の パンダさん （@Panda_Program）に見せたところ、LocalStorageに値を入れて小田原にいないのにスタンプを獲得されてしまいました。 そのため、簡単に偽装ができないように、スタンプの獲得判定はバックエンドで行うようにしました。 デザイン WebサイトをAIで生成すると人間があまり選ばないようなデザインになる部分がありました（影を付けたり角丸にしたり濃い色を使ったり）。 この辺りは一つずつ確認した上で、なるべくシンプルなデザインになるように修正していきました。 工夫した点 チェックポイントを目立つように工夫しました。 チェックポイントの100m以内に近づくと光るようにしています。 100m以内にあるチェックポイント 50m以内に近づくとスタンプ獲得ボタンが表示されます（これも光ってます）。 50m以内にあるチェックポイント 本当はスタンプが獲得できるようになったらスマホを振動させることもしたかったのですが、 Vibration API  にSafariが対応していないことから実装は見送りました。 今回こうした普段作っているものと方向性の違うアプリケーションを作成するのは、色々と考えるところがあって面白かったです。 おわりに スタンプラリーサイトはまだ2週間近く公開予定ですので、小田原に行かれた際にはぜひご利用ください。 BASEではこのように技術イベント・カンファレンスへのスポンサー協賛活動に取り組んでいます。 ブース企画などにご興味がある方はぜひ採用情報をご覧ください！ binc.jp

はじめに 2026/4/11（土）、BASE株式会社も竹スポンサーとして協賛したPHPカンファレンス小田原2026が開催されました。今回は参加メンバーのコメント、会場やスポンサーブースの様子についてお届けします！ PHPカンファレンス小田原2026 概要 PHPカンファレンス小田原は「小田原の地でつながる、気張らないカンファレンス」をスローガンに、参加したエンジニアが新たな知識を共有し合い、互いに学び、成長できる場所をつくれるイベントです。 phpcon-odawara.jp スポンサーブース 今年はBASEらしさと小田原らしさの両方を感じてもらえる企画にしたいという思いから、「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施しました。 PHPカンファレンス小田原は、地元に寄り添ったカンファレンスで、一方、BASEはスモールチームをエンパワーメントするという思想を持っています。今回のスタンプラリー企画は、地域コミュニティを大切にするカンファレンスの思想と、スモールチームを応援するBASEの思想がうまく調和した企画になったと感じています。 ご参加いただいた方々からも好評の声をいただけて、とても嬉しかったです！ スタンプラリーサイトを制作したykaganoさんの記事も近日公開予定ですので、ぜひそちらもお楽しみに！ 本企画にあたり、ご協力いただいたショップオーナーのみなさまのおかげで、とても有意義な企画となりました。心より御礼申し上げます。また、スタンプラリーにご参加いただいた方や、感想をお寄せいただいたみなさまにも感謝申し上げます。 登壇者コメント プログラミングをするパンダ 参加してくださった皆様フィードバックありがとうございました！前半は皆さんに面白いと思ってもらえるかなと想像していたものの、後半は「みんなどこかで聞いた話だったり、Claude のバージョンアップで陳腐化した話かも」とちょっと不安だったんですが、AIを使った開発の失敗とその分析を共有してもらってよかったとあってホッとしました。全体的に楽しんでもらえたようで何よりです。 参加者の方、登壇者の方、スポンサーの方、スタッフの方皆様ありがとうございました。来年も小田原でお会いできるのを楽しみにしています！ speakerdeck.com 川口将貴 PHPカンファレンス小田原はコミュニティ色の強いPHPカンファレンスの中でも特に地域コミュニティ含めた温かさが感じられる好きなカンファレンスです。 なので自分の発表もなるべくそれに即したものを話すようにしていますが、受け入れていただけたようで何よりです。 参加者、運営の皆様ありがとうございました。 speakerdeck.com 現地で見たセッションの感想 @02 Past, Present, Future: The PHPUnit Story by Sebastian Bergmann 氏 PHPカンファレンス小田原2026のキーノートは、PHPUnitのメインメンテナであるSebastian Bergmann氏が、PHPUnitを軸に過去から未来までを個人的に振り返る内容でした。 特にエピソードも踏まえ、失敗から多くのことを学び続けてきた姿勢や、PHPUnitが多くの人に使われつづけてきたからこそ時にはNoを言う必要があるメンテナの苦悩など、興味深い話が多かったです。 PHPUnitがみんなに使われているからこそ、様々な需要が出る中で、どれをマージしたら誰がよりよくなって誰が負担増えてしまうのか、判断し続けるの大変よなあ・・・ コミッターの尊敬するところ #phpcon_odawara #kama — 02 (@cocoeyes02) 2026年4月11日 また、OSS開発を通じて世界中のPHPのテストコードに貢献し続けてきたSebastian Bergmann氏が、「重要なのは技術のスキルではなく、共感すること。これまで開発してきた人のコードに現時点で問題があったとしても、悪意を見出さず、敬意を示し、その時点で最善を尽くしていたのだと考えること」と語っていたのが、とても印象に残りました。 セバスチャンレベルのエンジニアが、ソフトウェア開発最も重要なものは技術のスキルではなく共感力って言ってくれるのとても心動かされるものがある #phpcon_odawara #kama — 02 (@cocoeyes02) 2026年4月11日 スライドはこちらに公開されています。是非ご覧ください。 phpunit.expert イベント全体の感想 @InoueTorata 自分は今年で2回目の参加ですが、前回に引き続き熱量のあるカンファレンスで、カンファレンス自体もそうですが、懇親会もとても豪華で賑やかで楽しまさせてもらいました！ 告知タイムの長蛇の列からも界隈の盛り上がりを感じますね ※ 画像はFutoshi Endo氏のX投稿より引用 告知タイムの列 、過去一多い気がする 素晴らしい〜🔥 #phpcon_odawara pic.twitter.com/lbMAixQYtk — Futoshi Endo 🎮 (@Fendo181) 2026年4月11日 こんな楽しいカンファレンスを作り上げて下さったスタッフの皆さん、スピーカーの皆さんにも大変感謝です！ @izuhara 私自身、小田原在住ということもあり、このカンファレンスには気づけば3年連続で参加しています。 普段はあまり言語コミュニティに積極的に関わるタイプではないのですが、このイベントは全体的にゆるくて、それでいてちゃんと熱量もあるのがいいところ。初めてでも居心地がよくて、コミュニティの温かさを感じられるのが印象的です。 特に印象に残ったのは、登壇後すぐに行われる1分間フィードバック。その場でリアルタイムに感想や気づきを共有できるのは、発表者にとっても聞き手にとってもすごくいい仕組みだと思います。聞きっぱなしにならず、その場でしっかり消化できる感じがあって、イベント全体の密度も上がっている気がしました。 @TakeuchiYusuke 昨年、PHP Conference Japanに参加して、今回小田原は初の参加となりました。私はエンジニアではないのですが、コミュニティの空気感やワイワイとしたお祭り感が好きで参加しています。 小田原は居住地からそれなりに近いところなので、ブースのお手伝いをしますよ！というノリで参加したのですが、イベント自体が地域に根付いたコンセプトになっており、Japanとは違った楽しさを感じることができました。 特に印象に残ったのは、有限会社アリウープの柏岡さんのスポンサーLTでした。技術的な話というよりもものづくりがビジネスとして昇華されることの難しさが生々しく語られた内容でした。プロダクトやサービスを生み出せても、それを価値に転換することには想像以上の壁が存在していて、改めて世の中のユーザーに使われているプロダクトやサービスには途方もない努力や時間、試行錯誤が積み重なっているのだなと感じました。 おわりに 協賛活動や社員のスピーカー参加を通じて、小田原という地域やPHPコミュニティの盛り上がりに少しでも関われていれば嬉しく思います。弊社としても、大変有意義な時間となりました。 スタッフのみなさまには、業務でお忙しい中にもかかわらず、多くの時間をイベント準備に割いていただいたことと思います。このような貴重な機会をいただいたことに、この場を借りて心より御礼申し上げます。 スポンサーLTやエレベーターピッチでもお伝えしたとおり、BASEではエンジニアを募集しております。よろしければ、採用情報もぜひご覧いただけますと幸いです。 binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第2回の記事です。 先に第1回を読んでいただくのをおすすめします。 継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像 - BASEプロダクトチームブログ こちらは第1回で紹介したBASEの負荷テスト環境の構成図です。 負荷テスト環境の構成図 本記事では、負荷テストツールとして採用したLocustの選定理由から、実際の構築・運用方法までを紹介します。 負荷生成ツールの選定 負荷テストのリクエスト元となる負荷生成ツールの選定を行いました。 選定の際は、まず今回の要件として以下の通りまとめました。 OSSである クラウドはコストとセキュリティの両面でハードルが上がるため 分散実行が可能である 継続的負荷テスト環境としてスケーリングは必要 Web UIがある レポート品質が高い 学習コストが低い メンバーの誰もが利用できるようにしたい 実績が豊富である OSSが今後も保守される可能性が高い こうした観点から参考として整理したOSSの比較表が以下となります。 ツール名 分散実行可能 Web UI レポート品質 学習コスト 実績が豊富 特徴 Locust ◎（Master/Worker が標準） ◎ ○ Web UI 低 ○ OSSで最も簡単にクラスタ構成可能。Pythonでシナリオが柔軟。中規模負荷に強い。 Taurus ○（バックエンドの Locust/JMeter/k6 を分散実行管理） △ ○（バックエンド依存） 低〜中 △ CI/CDで分散テスト統合運用。YAMLでテストランナー統一。チーム利用に最適。 JMeter ○（分散実行あり、構成は複雑） △（要プラグイン） ◎ HTMLレポート 中 ◎ GUI派に最適。歴史が長く安定。大規模負荷にも実績豊富。 k6 OSS △（K8s/CIで水平スケール。自動クラスタなし） ✕ △（外部連携で補完） 低〜中 ○ K8sベースのスケール前提なら実質分散可能。軽量で高性能。 Gatling △（OSS版は限定的。分散は Gatling Enterprise 推奨） ✕ ◎ HTMLレポート 中〜高 ○ Scala/Java DSLで高精度なシナリオ記述。レポートが非常に詳細。高スループット計測に強い。 k6、JMeter、Locustは自身で使ったことがありました。 k6は軽量ですが、Web UIがなく、分散環境で実行した場合、サーバーごとに出力されるレポートの収集が必要なのが懸念でした。 JMeterはテストシナリオを作るための構成が独特で理解に時間がかかるため、学習コストが高いと感じていました。 LocustはWeb UIから容易に実行でき、Pythonでテストシナリオを書く体験が良かったので、今回もLocustを選定することにしました。 Locustの公式ドキュメントはこちらを参照ください。 https://locust.io/ Locustの構築と実行 ECSに構築しました。ECSはAWSのコンテナ管理サービスです。 LocustはMasterとWorkerのタスクに分かれて起動します。 MasterはWeb UIとWorkerの管理を行い、Workerが実際の負荷をリクエストします。 Workerの数を増やすことで、負荷リクエストの上限も増やすことができる構成です。 ECSでのLocustの構成 Classごとに実行が可能で、ProfileでGold環境とBronze環境を切り替えられるようにしています。 Locustの実行画面 実行結果はWeb UIからRPS、Response Times、User数がチャートで見れます。 Locustの実行結果 実際に負荷テストを実行する際は、急激な負荷増加によるスパイクを避けつつ安定状態を観測するため、30秒程度で全てのUserがRamp upするようにして5分間の負荷をかけています。 そして5分の間、応答速度が安定的であるかどうかチャートを見ながら確認しつつ負荷テストを行っています。 Terraformを用いたインフラのコード化 Locustを配置している負荷テスト環境のインフラは Terraform で管理しています。 Terraformはインフラの構成を「設定ファイル」として記述できるOSSです。 AWSコンソールから設定せず、Terraformを用いてコード管理することで以下のメリットがあります。 負荷テスト環境で使用しているリソースをコードから確認できる コードベースでAIに環境構築を依頼できるため、構築が早い 環境の起動と破棄がGitHub Actions（GHA）から実行できる これにより、負荷テスト環境を使用する時だけ起動し、使い終わったら破棄するといったこともできます。 しかし、負荷テスト環境の構築を始めた当初、チーム内にTerraformを使用したことのある知見がなかったため、メンバーから提案をいただき、まずAIにAWSの基礎知識を含めた学習用コンテンツを作ってもらうことから始めました。 AIは主にClaude Codeを使用しています。 こちらが学習コンテンツの一部ですが、このような資料を作っていました。 学習コンテンツ また環境構築自体も、Claude Codeに設計書を書いてもらい、チーム内でレビューをし、何度も修正を繰り返した上で、Claude CodeにTerraformのコードに落とし込んでもらうという形で進めました。 作成されたコードのレビューはチーム全員で行い、全員が負荷テスト環境について知識を揃えるようにしました。 また今回Terraformのフォルダ構成として、以下の通りcoreとruntimeという二つのフォルダに分けています。 core：常設リソースの配置場所で、destroy不可に設定して常設リソースを保護します runtime：一時的なリソースの配置場所で、destroy可能とすることでコストを削減します これにより、インフラの起動時間の短縮とコストの削減を両立させることができます。 今回はTerraformの構成についての知見も得ることができ、良い経験になりました。 負荷テストシナリオの作成 LocustではPythonでテストシナリオを書くことができます。 下記はClaude Codeに書いてもらったサンプルコードからの抜粋ですが、コードの組み立て方は実コードとあまり変わらないため、イメージしやすいかと思います。 """Locust による会員登録フローの負荷テストシナリオ""" import json import os import random import string from locust import HttpUser, between, task DEBUG = os.getenv( "DEBUG" ) == "1" def random_email (): """テスト用のユニークなメールアドレスを生成する""" rand = "" .join(random.choices(string.ascii_lowercase + string.digits, k= 10 )) return f "test_{rand}@example.com" def log_response (label, response): if not DEBUG: return code = response.status_code mark = "✓" if 200 <= code < 300 else "✗" print (f " {mark} [{code}] {label}" ) if code >= 400 : print (f " body: {response.text[:200]}" ) class UserRegistration (HttpUser): """新規会員登録フローのシナリオ""" wait_time = between( 1 , 3 ) @ task def register (self): email = random_email() # 1. 仮登録（メール送信リクエスト） with self.client.post( "/api/v1/signup" , json={ "email" : email}, catch_response= True , ) as r: log_response( "signup" , r) if r.status_code != 200 : r.failure(f "signup: {r.status_code}" ) return token = r.json().get( "confirmation_token" ) if not token: r.failure( "signup: token missing" ) return # この後の処理は省略 今回、テストシナリオを商品や決済方法毎にいくつか作成しました。 作成方法としては過去にk6のJavaScriptで書かれたテストシナリオを流用し、Claude CodeにPythonのコードに変換してもらいました。 変換後のコードが正しいかどうかを検証するために、Playwrightを使用しました。 Playwrightはブラウザを自動操作できるOSSのテストツールです。 Claude CodeをPlaywright MCP（MCPは外部ツールと連携するための共通規格）に接続して、開発環境での購入画面に実際にアクセスしながら、通信しているAPIを確認し、APIコールがテストシナリオのコードと一致しているか検証する形で行いました。 実際に指示したプロンプト Playwright MCPで下記URLにアクセスして、 購入フローをトレースしながらコールされているAPIが scenario/*****.py の シナリオに記載されている内容と一致しているかチェックしてください https://*****/items/12939562 こうしたClaude Codeを用いたテストシナリオの作成により、作業時間を大幅に短縮することができました。 Locustの週次での自動実行 GHAから自動実行する際は、ECSでLocustを起動した後、起動したLocustに対してLambda経由でLocustの負荷テスト実行APIを叩くようにしています。 そして負荷テストの完了結果はログ収集サービスであるCloudWatch Logsをポーリングして、結果ログを取得するようにしています。 以下がそのシーケンス図になります。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant GHA as GitHub Actions participant Lambda as Lambda<br/>(locust-control) participant CWL as CloudWatch Logs participant Master as Locust Master<br/>(ECS) participant Worker as Locust Worker<br/>(ECS x N) Note over GHA: Locust Master/Worker の<br/>デプロイ完了後 GHA->>Lambda: Lambda を非同期で呼び出す<br/>（ユーザー数・実行時間等を指定） Lambda-->>GHA: 即時応答（202） Note over GHA: CloudWatch Logs のポーリングを開始<br/>（30秒間隔で結果ログを監視） Lambda->>Master: Worker の接続状況を確認<br/>（10秒間隔・最大120秒） Master-->>Lambda: 接続済み Worker 一覧 Lambda->>Master: テスト開始を指示<br/>（POST /swarm） Master-->>Lambda: 開始成功 Master->>Worker: テストシナリオを配信 Note over Worker: 負荷テスト実行中... Note over Lambda: 指定時間が経過するまで待機 Lambda->>Master: テスト停止を指示<br/>（GET /stop） Master->>Worker: 停止指示 Master-->>Lambda: 停止完了 Lambda->>Master: テスト結果を取得<br/>（GET /stats/requests） Master-->>Lambda: 統計データ（JSON） Note over Lambda: サマリを抽出<br/>（全体集計 + POST /orders） Lambda->>CWL: サマリをログに出力 GHA->>CWL: サマリログを検索 CWL-->>GHA: テスト結果（JSON） GHA->>GHA: Slack に結果を通知 こうしてLocustを毎週、自動実行することで、Locustを継続的に使用できる状態を保てるようにしています。 おわりに LocustはWeb UIからすぐに負荷テストを開始できるのが非常に便利です。 複数のテストシナリオを組み合わせて実行することもできます。 今後、BASEの決済や販売方法のテストシナリオを拡充した上で、テストを並走させることで、本番をよりシミュレーションした負荷テストを実施していければと考えています。 こうした負荷テストの仕組みに興味がありましたら採用情報もぜひご覧ください。 binc.jp

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ Checkout Reliabilityチームはカートの信頼性を向上させるためのチームです。 今回、BASEのカート機能を安定的に提供するために、継続的な負荷テスト環境を構築しましたので第1回として、本記事では全体像を紹介します。 全3回の記事を予定していますので、よろしくお願いします。 BASEの負荷テスト BASEではこれまで負荷テストは必要に応じて都度実施していました。 k6 というオープンソースソフトウェア（以降OSS）の負荷テストツールを使って、BASEのカートへの商品追加から購入完了までのシナリオの負荷テストを行い、負荷が高まっても機能的な問題がないことを確認していました。 しかし、この都度実施の負荷テストには以下の課題がありました。 負荷テストの課題 1. 以前作成したテストシナリオがシステムの仕様変更で動かない状態になっている k6のテストシナリオはJavaScriptで書けるのですが、例えば購入可能な状態にするために必要なAPIやパラメータが一つ増えていたりすると修正が必要になります。 2. 外部APIの仕様変更で、外部APIに見立てたモックのコード修正が必要になっている 商品を購入する際には、BASEから社外の決済APIを呼び出しているのですが、開発環境とはいえ、社外の決済APIに負荷をかけるわけにはいかないため、決済APIの応答に見立てたモックを用意しています。そのため、この社外APIの仕様が変更になるとモックの方もコード修正が必要となります。 3. 新機能を作成した後、改修の度に負荷テストを行っておらず、現在のキャパシティ（負荷に対する許容量）が分からない 当時行った負荷テストの記録は残っているのですが、仕様変更があった今も同じキャパシティを維持できているのかは負荷テストをしてみないと分かりません。しかし、再度負荷テストをするためには、前述のハードルがあります。 これらの課題を解決して、継続的に負荷テストを行えるようにしよう、というのが今回の取り組みです。 負荷テスト環境の要件 継続的な負荷テスト環境として求めた要件は以下となります。 1. 負荷テストを自動で定期実行し、結果をレポートできる 定期的に負荷テストを行うことで、仕様変更によるエラー等を早期に検知できることを求めました。 2. 負荷生成ツールもモックもスケールアウトできる k6のようなシステムに負荷を与えるためのツールを負荷生成ツールと呼びます。この負荷生成ツールとモックの両方を今後システム規模が大きくなっても追従して高負荷を与えられるように、負荷生成ツールやモックの台数を増やす機能を求めました。 3. モックがノーコードで更新できる これまで使っていたモックはPHPによる独自実装をしていました。これだと仕様が変わるとコードの変更が必要です。今回はOSSのモックツールを使用することで、コードの変更をせずにモックの仕様を更新できる機能を求めました。 ベストプラクティスの調査 これらの要件に加え、負荷テスト環境としてのベストプラクティスを調査したところ、下記の記事を見つけました。 引用： 負荷テストの全体像を理解しよう｜AWS（第1回/全3回） ベストプラクティスの部分を抜粋します。 実際のワークロードを使用して負荷テストを行い、自身のワークロードが本番環境でどう動作するのかを確認すること 本番環境同等のサイズの環境を利用して試験を行うこと。また、本番環境同等の量・バリエーションのデータを、本番環境データを匿名化したり模擬的に作成したりして用意すること ユーザーの実際の行動をリプレイ、もしくはプログラム的に再現することで、大規模にアーキテクチャ全体に対して負荷をかけること デリバリーパイプラインの一環として負荷テストを自動的に実行し、事前に定義した性能目標と比較して評価し、要求性能を満たせるかどうかを継続的に保証すること ベストプラクティスに書かれていることは、私が負荷テスト環境に求めた要件とほとんど同じですが、負荷テストの考え方が間違っていない裏付けとして非常に参考になりました。 負荷テストツールの選定 こうした考え方を元に、継続的な負荷テスト環境の要件を満たすための負荷テストツールを選定しました。 負荷生成ツールには Locust を選定しています。 また外部APIのリクエストを受けるために WireMock を選定しました。 それぞれの詳細については第2回以降の記事で説明したいと思います。 負荷テスト環境の構成 最終的に負荷テスト環境の構成は下図となっています。 左が負荷生成ツールとモックツールを使用する負荷テストツール。 右が既存のBASEシステムと同等の負荷検証システム（簡略）となります。 負荷テスト環境のシステム構成図 実際のリクエストと同様にインターネットを跨いでリクエストを処理するようにしています。 ここからは負荷テストの構築にあたり進めた内容についてお話しします。 キャパシティプランニング 負荷テスト環境を構築するために、キャパシティプランニングを行いました。 まず以下の2点を確認しました。 BASEのGMV（流通取引総額）がこの先どれぐらい増加する想定なのか 現時点での本番環境での最大負荷はいくつなのか 1に関しては事業計画を参照すれば分かりますが、2に関しては、どこの負荷を基準とするかを検討しました。 BASEのカート機能には注文APIがありますので、そのAPIに対する負荷を基準にすることにしました。 またBASEではこれまでrpm（requests per minute）を基準にしていましたが、今回は高負荷状態を基準にするため、rps（requests per second）を基準にすることにしました。 ここでは注文APIの過去の最大負荷を仮に1,000rpsとします。 また事業計画として2年後のGMVが仮に1.5倍になるとします。 そうすると、2年後にはrpsも1.5倍の1,500rpsが最大負荷として想定されます。 しかし、あくまで成り行きで増える見積もりとなるため、上ブレすることも考えて多めに見積もりを行いました。 増加分の500rpsを2倍にして上振れ含め1,000rpsになるため、 2,000rpsを目標値 とします。 このような考え方で、今回構築するシステムの負荷テスト可能なキャパシティとして設定しました。 負荷テスト環境の構築 キャパシティプランニングでは、注文APIの負荷を仮に2,000rpsと設定しましたが、2,000rpsはあくまで注文API単体の負荷となります。 今回購入のワークロードを対象としているため、そのワークロードでは20を超えるAPIを利用しており、全体としては数万rpsの負荷が想定されました。 こうした要素を加味して、負荷テスト環境のシステム要件を決めていきました。 Gold環境 本番と同等の負荷検証システムは、既に以前から使っているGoldという名前の環境があったため、それを今回も利用することにしました。 しかしこのGold環境は、本番と同等のDBを使用するため、本番相当のデータ量の準備に数時間かかるという課題がありました。 負荷テスト環境は最終的に負荷テストの定期実行までを見据えていました。 負荷テスト環境の起動後、負荷テストを実行し、負荷テスト環境の破棄まで行う想定です。 しかし、定期実行が準備だけで数時間かかるとなると、コンテンツのデリバリー途中でタイムアウトする可能性もあります（実際にこのデータ準備の処理が何度か止まっていることがありました）。 再実行が頻繁に必要になってくると定期実行に支障が出ます。 DBが巨大すぎるため、Gold環境での定期実行は難しいことが分かってきました。 巨大なDBは存在するだけで多大なコストがかかるため、定期的に数時間利用するだけでも多大なコストがかかります。 定期実行ではこの課題を解決する必要がありました。 Bronze環境 本番同等の環境で負荷テストを行うというベストプラクティスには反するのですが、Gold環境での定期実行の課題を解決するため、負荷テストを自動で定期実行し、結果をレポートするための環境として本番よりスペックの低い縮小環境も今回用意することにしました。 この縮小環境には Bronze と名付けました。 命名理由としてはすでにSilver環境を別用途で使っていたためです。 このBronze環境があれば、テストシナリオの修正と確認もBronze環境で容易に行えます。 最終確認としての負荷テストはあくまでGold環境を使用しますが、定常的に必要最小限のキャパシティを担保するには、Bronze環境でも十分要件を満たせると考えました。 Bronze環境では開発環境のデータベースをそのまま流用することにしました。システムの仕様としては、本番環境の構成を縮小した形で仕様を決めていきました。 Gold環境とBronze環境の比較 項目 Gold環境 Bronze環境 目的 本番想定の最終的な負荷検証 継続的な負荷テスト・定点観測 スペック 本番同等 本番より縮小 データ量 本番同等（大規模） 開発環境のデータを流用 起動時間 数時間（データ準備に時間がかかる） 比較的短時間 コスト 高い 低い 実行頻度 必要に応じて実施 定期実行（週次） 主な用途 最終確認・性能限界の検証 早期検知・継続的な品質担保 メリット 本番に近い精度の検証が可能 手軽に何度でも実行できる デメリット コスト・準備時間が大きい 本番との差異がある Bronze環境で継続的に異常検知を行い、最終的な性能検証はGold環境で行う、という役割分担にしています。 チームでの構築 今回、チームで負荷テスト環境の構築を進めていきました。 草案は私の方で作成しましたが、設計は全員で行いました。 その後、Bronze環境の構築、AWSインフラとLocust環境の構築、WireMock環境の構築と3つに分かれて構築を行いました。 私は主にBronze環境の構築を行ったのですが、BASEのテスト環境を1セット作成する作業のため、BASEのシステムに対する解像度を上げることができ、非常に良い経験を得られました。 Bronze環境での継続的負荷テスト 毎週月曜に以下のスケジュールで負荷テストを自動実行しています。 時刻 内容 AM3:00 アプリケーションの自動デプロイ AM7:00 負荷テストの自動実行 負荷テストの自動実行はGitHub Actionsのワークフローで行っています。 以下のジョブが40分程度で実行されます。 負荷テスト開始の通知 Bronze環境の起動 負荷テストツールの起動 負荷テストの実行（メインシナリオ1） 負荷テスト結果の通知 負荷テストの実行（メインシナリオ2） 負荷テスト結果の通知 負荷テストツールの停止 Bronze環境の停止 負荷テスト完了の通知 負荷テスト結果はSlackに投稿されます。 以下はレポート内容の例ですが、注文API（post_orders）に対するrpsとAPI全体（aggregated）のrpsを見れるようにしています。 post_orders: requests=2000 failures=0 avg_time=20ms avg_rps=8.0, aggregated: requests=80000 failures=400 avg_time=500ms avg_rps=300.0 これで毎週最新のアプリケーションでキャパシティの定点観測ができる状態になりました。 本番と同等の挙動ではないですが、もしパフォーマンスの低下があれば週次で検知できます。 また今後負荷テストを実施したい場合にも、すぐに使える環境があるため、負荷テスト実施のハードルも下がってくれるのではないかと期待しています。 Gold環境での本番想定の負荷テスト Gold環境での負荷テストは当初パフォーマンスが想定したよりも出ませんでした。 本番と同等の環境ではありますが、本番と仕様や設定が一部異なっていたため、それらを本番と揃える作業が必要でした。 また本番と挙動が異なる部分もありました。 これは外部APIの通信時間を細かく本番と合わせたり、外部APIが本来持っているRate Limit（一定時間内にリクエスト回数の上限を設ける機能）の機能を再現するための仕組みを入れることで徐々に解決していきました。 負荷テストは実行してパフォーマンスが出ない場合にどこが原因か調査しボトルネックを見つけることも大事ですが、パフォーマンスをもっと出すためにはどうすればいいかは、仮説を立てる必要があります。 そのため、負荷テストの実施前に負荷改善の仮説DBをNotionに作成し、この辺りを改善すればより早くなるのではないか、といった仮説をチーム内で思い付いたものがあれば、確度が低くても良いのでどんどんDBに入れていくことにしました。 今後はこの負荷テストの結果と仮説を元に、BASEのカートの安定性をより高めるための施策を実施していく予定です。 おわりに 今回の記事では、継続的な負荷テスト環境の全体像と設計方針について紹介しました。 第2回では負荷生成ツールの構築と運用について、第3回ではモックツールの構築と運用についてお話しする予定です。 順次公開しますので、ご期待いただければと思います。 このようなシステム環境で働きたいエンジニアの方はぜひ採用情報をご覧ください！ binc.jp

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEが竹スポンサーとして協賛しているカンファレンス、 PHPカンファレンス小田原2026 のご紹介となります。 phpcon-odawara.jp PHPカンファレンス小田原2026 概要 PHPカンファレンス小田原は「小田原の地でつながる、気張らないカンファレンス」をスローガンに、参加したエンジニアが新たな知識を共有し合い、互いに学び、成長できる場所をつくれるイベントです。 2026/4/11（土）、おだわら市民交流センター「UMECO」で開催されます。 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in 登壇メンバーのご紹介 BASEで活躍しているメンバーのうち、2名が登壇予定です。ぜひ聞きにいらしてください。 レガシーPHP転生 〜父がドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜 プログラミングをするパンダ （ @Panda_Program ） 会場：かま 14:45〜 fortee.jp スポンサーLT 川口将貴（ @dmnlk ） 会場：かま 15:35〜 ブースのご紹介 当日はBASE株式会社としてスポンサーブースの出展も行います。 今年は「UMECO周辺のBASEショップを巡ろう！ 小田原ショップスタンプラリー」と題した企画を実施予定です。 BASEをご利用のショップオーナーの中には、ネットショップだけでなく、並行して実店舗を運営されている方もいらっしゃいます。会場であるUMECO周辺にも実店舗を構えているショップがありますので、カンファレンスで小田原にお越しの際は、ぜひ足を運んでみてください。 BASEのブースでお会いできることを楽しみにしております。 おわりに PHPカンファレンス小田原 2026 のチケットはこの記事掲載時点ですでに完売しているそうです。後日こちらのブログでも参加レポートをお届けする予定です。楽しみにお待ちください。 PHPカンファレンス小田原 2026で、みなさまにお会いできることを楽しみにしております！ 発表を見てBASEで働くことに興味を持った方は、ぜひ採用情報もご覧ください。 binc.jp

はじめに Architecture Design Grp で エンジニア をしている大塚です。 New Relic Advance: Tokyoというイベントに参加してきました。 New Relicのこれからについて、さまざまな発表がありましたので、簡単にまとめさせていただきました。 今回はCEOなどの登壇もあり、見応えのあるイベントでした！ TL;DR New Relicが日本リージョン（国内データセンター）を追加予定で、データ保管要件とレイテンシ面でメリット 生成AI（Analyzer + MCPなど）でアラート調査の初動を短縮し、運用定着を加速する事例が紹介された New Relic Lensで外部DBやDWHなどにクエリし、NRQLで既存データと結合して分析できる イベント概要 日程：2026/03/12 16:00 ~ 18:00 会場：八芳園 全体の所感 New RelicのCEOなどが登壇するようなイベントで、今まで参加したイベントとは雰囲気がだいぶ違いました。 生成AI時代なので、AIの活用を加速させる内容が多かったです。 AI for New RelicとしてAIアシスタントやSRE Agentなどの紹介があり、インシデントなどの対応フローの自動化などが大きなトピックでした。 New Relic for AIとしてMCPの紹介や、ほかプラットフォームとの統合についての紹介もありました。 基調講演でもAIとNew Relicのデータを用いてインシデントやアラート対応を効率化させるという話があったので、BASEでも取り込んでいこうと感じました。 セッション / トピック 1) 日本リージョン追加！ newrelic.com 日本にNew RelicのDCを設立するというお話です。 セキュリティやプライバシー要件的にNew Relicに保存できなかった（海外リージョンのため）データも日本国内にデータが保存されるようになることで、より幅広いデータを集約することが可能になります。 レイテンシなどのパフォーマンスにも寄与するような大きなトピックでした。 2) 生成AIで加速させるNew RelicのEnabling speakerdeck.com blog.kinto-technologies.com New Relicを組織に浸透させるための取り組みにAIを組み合わせて、活用を加速させるというお話でした。 勉強会やドキュメントなどのコンテンツをいくら揃えても、それぞれのエンジニアにはそれぞれのタスクがあるので、時間を使って活用してもらうのは難しいという課題が挙げられていました。 New Relicを用いて、計装→検知→調査→解消までのサイクルは回せるようになるが、結局は人の目や手で対応をする必要があるので非効率という課題が残ってしまっていました。 その課題に対してNew Relic Analyzerという仕組み（AIによる分析）を導入することで、初期調査の時間が大幅に短縮され、MCPを用いた対話型にすることで日常業務への定着も進んだとのことでした。 BASEではアラートはSentryで調査はNewRelicという構造になっているので、現状を維持しても良いがNew Relicを活用できていない部分も大きいと感じました。 インシデントやアラートの対応サイクルを改めて見直し、AIを導入した新しい仕組みづくりをしてみても良いかもしれない。。。 3) New Relic Lens docs.newrelic.com New Relic外のデータソースに対してクエリを実行することが可能になりました。 クエリ結果に対してNRQLでNRDBのデータとjoinして分析・可視化できるようです。 現状対応しているのは以下 クラウド データ ウェアハウス : Snowflake 、 Redshift 、 ClickHouse リレーショナルデータベース : PostgreSQL 、 MySQL 、 SQL Server ドキュメントデータベース : MongoDB 、 Elasticsearch スプレッドシート : Google Sheets データレイク : Iceberg メトリクスと監視 : Prometheus 、 AWS CloudWatch BASEでの活用の今後の展望 アラート対応やインシデント対応の実態調査 New Relic Analyzer的な機能の実装が可能かどうか New Relic Lensを利用してNew RelicからMySQLのデータをクエリできるようにする（可能か？の調査から） 最後に 生成AIの活用が進む中で、アプリケーション監視についてもこれらの技術を用いる必要性を感じました。 今回のイベントの内容はBASEでも活用できる内容が多かったので、積極的に取り入れることで社内のAI Observabilityを向上させていきたいと思います。 こうした生成AIを活用した取り組みは各社行っていると思いますが、BASEでも積極的に開発やサービスに取り入れています。 binc.jp

はじめに BASE Order Section でWebアプリケーションエンジニア をしている Capi(かぴ) です。 2026/3/20（金）- 3/22（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2026 が開催されました。今回はPHPerKaigi 2026に参加したメンバーのコメントや感想をお届けします！ PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年もゴールドスポンサーとして協賛しました。 登壇者コメント 川島慧 モジュラモノリスを導入してから4年が経ち、「そろそろ答え合わせができるのでは」という気持ちで今回の発表に臨みました。 「何を解決しようとしているのか分からないままマイクロサービス（orモジュラモノリス）を開始しようとするのはほとんど悪いアイディアだ」という、技術主導は大抵誤りであるという意識を４年前からずっと持って挑んできました。結果的に思いがけないつまづきもありましたが、無事に解決するべきIssueの解像度が上がった４年間でした。 スライド中では「AIに要約させながら読むことを推奨」と書いたのですが、アップロード後に試してみると、意外なことにChatGPTやGeminiでは何度訂正させても全く違う内容が返ってきました。どうやら100枚超のスライドをAIに要約させるのはまだ難しいようです。ClaudeとNotebookLMだとある程度うまくやってくれます。 個人的にはかなり痛手です。これほどの文量を読むエンジニアは今の時代にまずいないので、ほとんどの人に届かない内容になってしまったと思います。スライドを読む際はご自身の目でしっかり読んでいただくか、動画を見るか、ClaudeまたはNotebookLMあたりににお願いするのがおすすめです（個人の感想です）。 speakerdeck.com プログラミングをするパンダ セール開始のバッチのパフォーマンスをチームで改善したという話を共有しました。発表後に「うちでも遅いバッチがある」という話を聞いたり、「しっかり遅いことに気づいて改善に持っていける体制が作られているのが素晴らしい」とお褒めの言葉をいただいたりしました。 特にポストモーテム共有会をやっているということが今回のバッチの改善の起点になったのですが、その取り組みがとても良いと言ってもらうことが多く、ポストモーテム共有会も別のメンバーが始めていたので大変ありがたいなと思っています。 スライドの最後の方でも触れましたが、今回の発表を機にもう一段改善できるところを見直そうと思うので、さらに早くできるのではないかなと思っています。当日発表を聞きに来てくださった方、ありがとうございました。そうでない方もぜひスライドを一度ご覧ください。皆様のお役に立てれば幸いです。 speakerdeck.com 02 PHP8.5に追加されたarray_first / array_lastの歴史的背景について話しました。5分という短い時間で7年分の議論の流れを追いましたが、重要な話はできるだけ削らずに伝えられたと思います。 さまざまな観点から議論を重ねて未解決の疑問をなくす必要がある一方で、発散した議論はスコープを絞ったり、特定の観点を重視して仕様を決めたり・・・仕事の進め方やファシリテーション、マネジメントなど、普段のプロダクト開発で重要な力が、RFCの採択においても重要だという所感を感じました。 PHP Internalsの議論の流れを追う中で学びが多く、今回のarray_first / array_last以外の議論も追ってみたいと思いました。興味を持った皆さんも、まずは参考文献のURLからarray_first / array_lastの議論を追ってみてください！ speakerdeck.com パンフレット記事執筆者コメント meihei 「カンファレンスが終わったあとに」というパンフレットを寄稿しました。先日のPHPerKaigiでは多くの学びがあったかと思います。それらを自分の中で、またチームメンバーとともに知識として再構築し、今後さまざまな機会で活かせる武器にしてもらえたら嬉しいです。 パンフレットはマンガで解説していますので、お気軽にお読みください！ 現地で見たセッションを一部紹介 当日イベントに参加した自分含む弊社メンバーが現地で見たセッションのうち特に気になったセッションのレポートです！ 1. 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 by 武田 憲太郎さん 高トラフィックを捌く技術的な解決を自信持って行うためにできることを紹介していただきました。アプリケーションコードよりもミドルウェアの話が中心でした。 Keep Alive、Persistent Connection、コネクションプール… 単語は知っているけれど自分が使いこなせていないものがたくさん出てきて非常に勉強になりました。スライドには図やグラフ、コードが添付されていたので難しい内容でも理解しやすかったです。興味のある方はぜひスライドだけでもみていただきたいです。オススメです。 自分は登壇の中で武田さんがおっしゃっていた「計測は仮説を持って行う」という言葉が印象に残っています。また、登壇を聞きながらシステムの接続はとても奥が深く技術者の腕の見せ所なのではないかと考えました。 (BASE Order Section @Capi) 2. プログラミング言語論から覗くPHPの正体 by うさみけんたさん 「PHPがどんな歴史を積み重ね、今の書き方になったのか」を紐解いていきました。PHPがゆるふわ言語というのは自分もなんとなく理解していますが、想像以上にゆるふわ言語であることを知り、PHPらしさを再度認識する良い機会になりました。 また、登壇の中ではPHP作者Rasmus Lerdorf(ラスマス・ラードフ)氏の発言を取り上げていました。言語作者の人となりを知るのも面白いなと登壇を聞きながら考えました。なぜ言語が作られたのか、どんな思想で言語が成長してきたのかを知ることでその言語への愛着が強まります。 登壇で出てきたこのスライドが自分は好きです笑 (BASE Order Section @Capi) 3. 俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために by 髙橋直規さん 持続可能なチーム開発を目指す中で、「アーキテクチャを刷新する必要があるが、トップダウンで決めるのは避けたい」という背景から、「最強アーキテクチャ決定戦」を開催したという内容のライトニングトークでした。 2人程度で似たようなイベントを開催したことはありましたが、経験値に差があるチームで実施したことはなかったため「すべての処理を神メソッドで実現する」という提案のハードルを下げるための工夫や、イベントの流れなど開発チームの運営において大変参考になる内容が多かったです。（Pay ID Engineering Section 岡部 @rerenote） 4.AI時代の脳疲弊と向き合う ~言語学としてのPHP~ by さくらいさん 日々の業務の中で、何かしらAIとやりとりする機会が増えています。その中で、抽象的な内容を具体的な表現に落とし込む場面が以前より多くなっていると感じていました。また、AIと長時間やりとりした後に強い疲労感を覚えることも増えてきています。 このライトニングトークでは、こうした疲れがどこから生じるのか、そしてその対策について解説されていました。対策の中でも「意識して時間を使い分ける」はすぐに実践できそうだと感じ、早速取り入れています。以前と比べて、疲労感を覚える場面が少なくなってきたように感じています。（Pay ID Engineering Section 岡部 @rerenote） おわりに 去年に引き続きレポーターとしてPHPerKaigiに参加させていただきました。 今年も協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。

はじめに こんにちは！Pay ID Engineering Sectionの岡部（ @rerenote ）です。 今回はBASEがゴールドスポンサーとして協賛しているカンファレンス、 PHPerKaigi 2026 のご紹介となります。 phperkaigi.jp PHPerKaigi 2026 概要 PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 PHPerKaigi 2026 公式サイト 2026/3/20（金）- 3/22（日）の3日間、中野セントラルパークカンファレンス&ニコニコ生放送で、オフライン及びオンラインのハイブリッド開催となります。チケットは下記よりお買い求めいただけます。 チケットショップ | PHPerKaigi 2026 #phperkaigi - fortee.jp 昨年の模様はこちらの記事をご覧ください。 devblog.thebase.in 登壇メンバーのご紹介 BASEで活躍しているメンバーのうち、3名が登壇、1名がパンフレット記事掲載予定です。ぜひ聞きにいらしてください＆パンフレットもぜひご覧ください。 モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について 川島慧（ @nazonohito51 ） 3/21（土）Track C 15:35 登壇者メッセージ モジュラモノリスを題材にしていますが、主題は組織とアーキテクチャの力学の分析です。ただの苦労話や事例紹介ではなく、背後にある構造を読み解きます。 fortee.jp 大規模ECサイトのあるバッチのパフォーマンスを改善するために僕たちのチームがしてきたこと プログラミングをするパンダ（ @Panda_Program ） 3/22（日）Track C 11:00 fortee.jp なぜarray_firstとarray_lastは採用、array_value_firstとarray_value_lastは見送りだったか 02（ @cocoeyes02 ） 3/22（日）Track A 16:05 fortee.jp カンファレンスが終わったあとに meihei（ @app1e_s ） パンフレット掲載 fortee.jp PHPerトークン ここで、PHPerKaigiで行われる「PHPerチャレンジ」のPHPトークンをお知らせします。BASEからは3つのPHPerトークンを用意しました。今回はBASEのサービスに関する内容からピックアップしています。 #ネットでお店を開くならベイス♪ thebase.com 誰でもかんたんに使えて、自分だけのネットショップを開設できるネットショップ作成サービス「BASE（ベイス）」のCMで使用されているフレーズです。 はじめての方でもかんたんに自分だけのネットショップがすぐに作成でき、ネットショップに必要な決済手段も、多様な決済方法をスピーディーに導入可能。 #ECのカクシゴト www.youtube.com 「ECのカクシゴト」は「BASE」公式YouTubeチャンネルの1つ。“ひとり開業の裏側”をテーマに、個人やスモールチームでネットショップを運営するショップオーナーの開業ストーリーや人生、日々の暮らしに密着したドキュメンタリー形式の動画を配信しています。 実際にネットショップを運営する個人やスモールチームのオーナーたちに密着し、「なぜECという働き方を選んだのか」「副業から始まり、起業に至るまでの過程」「ものづくりと暮らしのバランス」など、表からは見えないさまざまな価値観や選択肢に光を当てていきます。 毎週金曜日に新しい動画が配信されていますので、ぜひご覧ください。 #好きが、買える。ペイアイディー payid.jp 「BASE」をご利用のショップと購入者をつなぐ、BASE唯一の購入者向けショッピングサービス「Pay ID（ペイ アイディー）」。「Pay IDアプリ」を通じて、ショップは集客・販促をおこない、購入者はお気に入りショップのフォローや商品通知など、スムーズな購入体験を得ることができます。 お気に入りショップでのお買い物をサポートする「ショッピングアプリ」、スムーズでクイックなお支払いを実現する「決済」の2つの領域でサービスを提供しています。 おわりに PHPerKaigi 2026で、みなさまにお会いできることを楽しみにしております！ 発表やパンフレットを見てBASEで働くことに興味を持った方は、ぜひ採用情報もご覧ください。 binc.jp

はじめに こんにちは！ BASEでバックエンドエンジニアをしている、かがの（ @ykagano ）です。 昨年まではCartチームにいたのですが、今年から部署名が変わりまして、現在はCheckout Reliabilityチームにいます。 これはBASEのECカートの信頼性を守るためのチームです。 決済の安定性を高めるために日々活動をしていますが、それについてはまた別の記事で書かせてください。 さて、QRコード決済サービスとして日本で一番シェアの大きいPayPayといえば、皆さまもご存知かと思います。 今回は、2026年1月28日にサービスリリースしたこのPayPay導入についてお話しさせていただきます。 BASEはなぜ決済手段を増やすのか まずBASEがなぜ決済手段を増やすのかですが、そもそも決済手段が増えるとどういう良いことがあるのかからお話ししたいと思います。 ECにおいて購入体験の中で最も重要なポイントのひとつが「決済」です。 商品を見つけてカートに入れても、最後の支払いでつまずいてしまうと、その時点で購入は完了しません。 特に近年はクレジットカードだけでなく、QRコード決済や後払いなど、ユーザーごとに「普段使っている支払い方法」が多様化しています。 そのため、ショップ側が対応している決済手段が少ないと、それだけで購入機会を逃してしまう可能性があります。 SBペイメントサービス株式会社による「決済手段のEC利用実態調査結果」でも、「よく利用する決済手段がない場合、男女ともに約6割が購入せず離脱する」という結果になっています。 www.sbpayment.jp ECサイトで物品もしくはデジタルコンテンツ・サービスを支払う際に、よく利用する決済手段がない場合どうするかを尋ねたところ、男女ともに56.5％以上が、そのECサイトでは購入せず離脱する傾向にあることが分かりました。また、そのうち44.8％以上※2の人は他のECサイトもしくは実店舗で購入する意向があることから、購買意欲が高い人でも決済手段の不足が要因で離脱しており、ユーザーのニーズに応じた決済手段を取りそろえることは購買率を上げる重要な要素であると言えます。 つまり、決済手段を増やすことは単に「選択肢を増やす」というだけではなく、ユーザーが安心して購入を完了できる環境を整えることにつながります。 これはショップオーナーにとっては購入率の向上につながり、BASEにとってもより多くの取引を支える基盤を強化することになります。 今回PayPayがBASEに導入されたことは、こうした背景からも多くのショップ様にとって望まれていた機能追加だったと考えています。 BASEでのPayPay導入方法 PayPayは「BASEかんたん決済」に追加される形で提供されます。 PayPayを利用するには、この「BASEかんたん決済」の利用申請が必要です。 「BASEかんたん決済」の利用申請をもとに、PayPayで審査が行われます。 その後、可決された場合はPayPayを利用開始いただけます。 なお決済手数料は 4.6% + 40円 です（グロースプランの場合、決済手数料は 3.9% のみ）。 これは既存のAmazon Pay や PayPal決済と同じ決済手数料となります。 その他、詳細については下記ヘルプページをご参照ください。 help.thebase.in BASEでの支払い方法 BASEのカート画面で支払い方法に「PayPay」を選択して、購入完了ボタンを押していただく形となります。 その後、「PayPay」の手続き画面に遷移しますので、「PayPay」アプリで認証・支払いすると、BASE側に自動で戻り、購入が完了します。 PayPayは現在、BASEのWebショップのみが利用可能となっていまして、Pay IDアプリには未対応となります。 またPayPayで支払いが可能な商品は通常商品のみとなっており、デジタルコンテンツや予約販売や抽選販売など、通常商品以外の商品には利用できないようになっていますのでご注意ください（取り扱いについては今後変更になる場合があります）。 その他、詳細については下記ヘルプページをご参照ください。 help.thebase.in PayPay導入の開発について PayPayの導入はService Reliabilityチーム（以降SRチーム）にて開発いただいてます。 私自身はPayPay導入の開発に直接関わっていたわけではないのですが、導入後のカートシステムの運用を行う前提で設計や実装レビューに入らせていただきました。 今回BASEにPayPayが導入されることになり、システムの開発が始まったのが、2025年10月8日になります。この日に開発メンバーでキックオフを行い、設計を始めていきました。 実装にはPayPayのスマートペイメント機能を利用しています。 初回はユーザーの連携が必要ですが、2回目以降は同じ端末からの操作であれば再度連携せずに支払いをすることができます。 詳細はPayPayの公式ドキュメントをご参照ください。 developer.paypay.ne.jp PayPayはクレジットカード決済とは異なり、ユーザー操作後にBASEとは非同期で決済結果が確定するフローを含んでいます。 そのため「決済をいつ確定させるか」「どの状態をもって成功とみなすか」を慎重に設計する必要がありました。 今回は「注文が完了した時には決済も確定している」というBASEの体験を維持するために、PayPayの画面で決済をしたあと、BASEの画面に戻ってきた後にPayPayの決済結果が正常に完了していることを確認してからBASEに注文を作成するようにしました。 BASEでは複数の決済手段を扱っているため、特定の決済に依存しすぎない形での実装が求められます。 PayPayも既存の決済と同じインターフェースに乗せることで、カート・注文・発送といった関連機能への影響を最小限に抑えています。 私がレビューをしている中で特に意識したのは、「PayPay側で一時的な障害が発生しても、注文や決済状態が不整合を起こさないこと」です。 この辺りは特に注意してレビューをさせていただきました。 もし何らかの原因によって決済が失敗した場合も不整合が起こらない仕組みとなっておりますので、安心してご利用いただければと思います。 おわりに 開発期間としては約3ヶ月でリリースすることができたのですが、これほど早くリリースできたのもSRチームの皆さまの頑張りのおかげです。 本当にありがとうございました。 PayPay決済はまだBASEで開始したばかりですが、今後利用数、利用率ともに高くなるものと思いますので、より安定的に運用できるように改善を重ねていきます。 BASEではこうした決済の仕組みにも関わっていけますので、ご興味がありましたら採用情報をぜひご覧ください。 binc.jp

はじめに 先日、New Relic 社主催の New Relic Meet Up for Digital に弊社のメンバー 6 人が参加してきました。 以前も New Relic 社主催の FutureStack Tokyo 2023 でも Game Day がありましたが、今回はこちらに参加していないメンバーでの参加となりました。 前回 BASE で Game Day に参加したブログはこちら！ devblog.thebase.in コンテンツ この Meet Up では基調講演、GameDay Lite、懇親会という流れで進行されていました。 AI 時代の「オブザーバビリティ」戦略 AI時代には開発スピードがどんどん上がり、それに伴いコードの大規模化や不確実性などの課題が新たに生まれ、オブザーバビリティの重要性がもっと上がるというお話しでした。 New Relic パスポイントやセッションリプレイなど、まだ使えていない便利な機能を知れたのでどんどん使っていきたいです。 GameDay Lite 3~4人のシャッフルチームで、障害が発生した想定のWebアプリケーションに対して New Relic を使って解決していくゲームを行いました（回答式）。 高得点を叩き出した上位チームには景品が渡されていて、弊社の @takashi.nohara さんのチームが見事 3 位に入賞していました🎉 参加レポート @yunamiyaa Product dev Order Section Architecture Design の宮坂 @yunamiyaaです。 今回のミートアップでは、4人1組のチームでNew Relicを使ったトラブルシューティングに挑戦しました。 私たちのチームは、普段から業務でNew Relicを使い込んでいるメンバー3名と、ちょうど会社で導入が決まったばかりの未経験メンバー1名という構成でした。初心者のメンバーに「調査のコツ」や「画面の見方」を教えながら進めることで、自分たちにとっても基本に立ち返る良い機会になり、改めて「なぜこの手順で調査するのか」を言語化できました。 同じNew Relicというツールを使っていても、他社のエンジニアとディスカッションする中で、エラーを探す手順やダッシュボードの使い方が会社ごとに異なることに驚きました。それぞれの組織の文化やシステム構成に合わせた工夫があり、「うちではこうやっている」という情報交換がとても刺激的でした。 さらに、New Relic社の方から具体的なケースに対する追跡方法を直接教えていただけたことが大きな収穫でした。 「あ、そんな追い方があるんだ！」という発見が多く、普段の業務では気づけなかった機能の活用法や、より効率的な調査パターンを知ることができました。自社の中だけでは得られなかった新しい視点をたくさんもらえた、非常に有意義なミートアップでした。 @Torata BASE ProductDev / Item Section でエンジニアをやっているTorataです。 自分は直近で New Relic に触れる機会があり、今後も New Relic を継続して学んでいく必要があると感じていたタイミングで、今回の Game Day に参加しました。 初めて見る機能や、見たことはあるものの目的がよく分かっていなかった機能に、ゲーム感覚で触れられたのがとても楽しかったです。 また解説では、「どの意図を持って何を見るのか」という観点から、調査を深掘りしていくプロセスまで聞けたのが大きな学びになりました。 賞を勝ち取ることはできませんでしたが、今回学んだことを業務で活用し、賞を狙えるようになるくらい使いこなしていきたいです💪 @meihei BASE の Item Scalability Group でエンジニアをしている江間 @meihei です。 Item Scalability Group では、アプリケーションからインフラストラクチャ・データベースまで横断的に監視してボトルネックを探すため、日頃から New Relic を使っています。チョットワカルつもりで GameDay に参加しましたが、初めて触る機能や UI が結構ありました。 また、チームが３人だったこともあり、横に並んで New Relic を触っていました。はじめましての方もいる中、とても良い形で協力プレーが出来てとても楽しかったです。 最初の講演も GameDay Lite も非常に学びが多かったです。New Relic の設定でまだやっていない事がいくつか見つかったので、ここで得た知識を活用していきたいと思います。 GameDay中のチームWの様子。中央の一人がNew Relicの画面を触りながら、横二人が問題や資料を開き、限られた環境の中で効率化をしていた。 @Otsuka BASEのOrder Secの大塚です。 GameDay形式でのイベントへの参加は初めてでした。 New Relicは普段から触っており正直自信があったのですが、なかなか苦戦してしまいました。 その分普段活かしきれていない機能についての活用方法なども学ぶことができたので、今後に活かしていきたいと思います。 @wakana Product Dev/Checkout Section の @wakana です。 私は普段の業務中から New Relic を使用しており、主にAPM, Service Level, Dashboard, Browser, Logs などの機能を用いて、監視業務や可観測性の向上に取り組んでいます。 今回、New Relic Game Day への参加は初めてでしたが、事前にグループ分けされたほかの参加者の方と4人1組でチームを組み、クイズ形式の課題にNew Relicを活用して答えていく協力型の形式で、とても取り組みやすく感じました。 内容としても全て実践的で充実した内容となっており、参加前から知っていた・使ったことのある機能は4割ほどで、残りは初めて見るページなどが多かったため、とても刺激になりました。 一部、とても魅力的でありながらBASEでまだ導入ができていない機能などもあったため、今後よりオブザーバビリティの民主化を社内で進めていくうえでぜひ導入を進めていきたいと感じました。 @nohara BASEのCheckout Sectionのエンジニア、野原です。普段の業務では New Relic を利用しています。今回は理解を深めるために、New Relic の GameDay に参加しました。 今回が初めての参加だったのですが、想定とは少し違い、他社の方々とランダムに4人チームを組んで課題に挑戦する形式で、とても新鮮でした。特に、初対面のメンバーと短時間でチームワークを築いていく体験が印象に残っています。まず最初に、4人チームの中で誰が回答を記録・提出するかを決め、その後はそれぞれの知見を持ち寄りながら課題に取り組みました。 初めて目にする機能やUIも多くありましたが、メンバー同士で相談しながら進めることで、なんとか回答することができました。最初は順位をあまり意識していなかったのですが、第1ステージで2位だったのは意外でした。第2ステージでは一部、回答が間に合わなかった問題もあったため、最終順位が3位だったのは正直驚きでした。今回学んだ内容は、ぜひ今後の業務にも活かしていきたいと思います。 また、最初の発表もとても勉強になりました。これからはAIの時代ということで、今後はAIの活用も積極的に取り入れていきたいと感じています。業務の中でも、引き続き New Relic を活用していく予定です、これからもどんどん勉強します。 GameDayのチーム賞で見事二位に入賞。左から二人目がBASEメンバーのnohara。 おわりに AI時代でのオブザーバビリティへの向き合い方や、New Relicの機能に関する新たな知識を沢山学べた１日でした。 当日のイベント進行や準備をしていただいたNew Relic社の皆様、ありがとうございました！ これからもどんどん New Relic を使っていきたいと思います！

CTOの川口 ( id:dmnlk ) です。 これはBASE Advent Calendar25日目の記事です。 毎年ながら僕は立候補してないのに勝手に日程が組み込まれてました。 BASE社では2027年卒の学生を対象に新卒採用を始めました。 今まで基本的に行っていなかったことです。対象はエンジニア職、デザイナー職、ビジネス職です。 2025年中には就活を終えている大学生が多いということも知り、自分が新卒だった頃と比べててだいぶ進行が早いことに驚いています。 採用面接を行っていく中で必ず聞かれることとして「どうしてこのタイミングで新卒採用を始めたのか？」というものがあります。 特にエンジニア職においてはAIによるコーディングが大きな流れとなっており、インターン経験があれど実務経験が乏しい所謂ジュニアエンジニアをなぜこのタイミングで採用を始めるかというのは当然の疑問だと思いますし学生の方には不安も大きいのかもしれません。 もちろん面接中にそれを同じように答えているのですが来年以降の方も踏まえてここで明文化しておこうと思い記事にしています。 コロナ禍が起きた2020年以降、BASE社ではリモートワークを主としたハイブリッドワークを行ってきました。 ここでリモートワークの是非を言及するつもりはなく各社ごとに合わせた働き方や組織があるかと思います。 自分はBASEにかれこれ8年ほど在籍していますが、最近自社がどういう文化を持った組織かといったことを認識しづらくなったと感じています。 特にこの部分は中途面接でよく聞かれており、今のところ答えられている部分ではあるのですがどうしても文化面といった部分に希薄化を感じています。 もちろん文化が色濃ければ濃いほどいいというものではありませんが、開発組織のトップであるCTOたる自分がその組織について自分の言葉で話せなくなっていることには危機感があります。 中途採用したメンバーも定期的に入社していただいていますが、中途で入ってきたメンバーが文化を作っていくといった力学は働きづらいように思いますしそれを求めすぎるのは何か違うのではないかと思います。 自分が新卒で入った会社は大きなインターネット企業の子会社ですが、そこグループ全体で反対に企業文化が外から見ても中から見ても非常に強い会社です。 斜に構えた新卒であった自分はその空気感といったものに怪訝な気持ちでいたものですが、今思い返すと朱に交われば赤くなるといったように一定その会社のマインドや風土といったものに影響され今の考え方があります。 もちろんその企業もコロナ禍でリモートワークをやっていたようですし、内部では文化は変わったり薄まったりしたのかもしれませんが外から見る限りは未だに強い流れがあると思います。 思い返しその源泉はなんだったのだろうと考えると、もちろん社長や経営陣の強いリーダーシップもありますが新卒を毎年積極的に採用し全社がその採用に協力し入社した新卒を全社で育て早い段階から抜擢し伸ばしていたところにあったのではないかと考えています。 そのような点も踏まえ、BASEの開発組織として新卒を採用しボトムアップで文化醸成を図っていきたいというのが自分の考えとなります。 実務能力という点においてはあまり自分ではジュニアという括りで捉えてはいません。 インターン経験を一旦除いて考えると大規模Webサービスや数十人規模での組織での開発の仕方など経験が不足しているのは当然です。 ですが、それは単純な経験の差というだけであり1~2年もあれば優秀な方であれば容易に習得できうるものですし、事実自分もそうでした。 AIによるバフがあることによりジュニアエンジニアの能力向上のチャンスはより強くなっています。優秀な人物であればそのバフは数倍以上の効果を見せるはずです。 逆にいうとその変化を緩やかにしか利用できないシニアエンジニア達はすぐに追いつかれてしまうかもしれませんし、組織コミットも希薄になっている以上企業や組織としてどちらが重用されるかは明白です。 これからのジュニアエンジニアは、いかに変化に柔軟に適応できるかが重要なのではないかと思います。 受け入れる私たち企業側も、AIを前提とした開発が主流になっていくなかでどのように能力を引き上げていくかはまだ手探りの課題があるでしょう。 基礎となる技術が変わるわけではないのでその部分をしっかり理解したメンバーがきちんと何が重要でどこをAIに移譲していくか考慮した研修などを設計していく必要があります。 かのRuby on Railsの作者DHHもブログエントリで、「常にジュニアの開発者を採用し続ける」と明言しています。 We'll always need junior programmers AIを前提としていく開発業界の中で優秀な開発者の需要は否応なく上がり続けるのは自明であり、AIが開発者の全ての仕事を奪い廃業になっていく未来は見えません。 それはOpenAIやAnthorpicのようなモデルプロバイダーだけでなく、私たちWebサービスの開発でも同様です。 そうした中でBASE社として、ユーザーの経済活動を支え続けるプラットフォームを開発運用して成長していきたい新卒の方に期待を持って今後も新卒採用を続けていく予定です。 もちろん中途採用の方も募集していますので、気になる方はいつでもお声がけください。 採用情報 | BASE, Inc. では、皆様良いお年を。