はじめに この記事はBASEアドベントカレンダーの9日目の記事です。 devblog.thebase.in 基盤グループの @okinaka です。最近は、メール配信基盤の構築を担当しています。 今回は LocalStack の EventBridge Scheduler にある制約と、その対処法についてお話しします。 LocalStack と AWS EventBridge Scheduler 私が担当しているメール配信基盤は、AWS のサービスを組み合わせて作られています。 開発には Docker 上で AWS サービスをエミュレートした LocalStack を活用していて、私のお気に入りのツールです。特に Lambda 関数は、AWS サービスとの連携を前提としているため、ローカルでの動作確認には必須と言っていいかもしれません。 それに加えて最近のお気に入りの一つに AWS EventBridge Scheduler というサービスがあります。 EventBridge というサービスがありますが、それとは別のものです。 AWS EventBridge Scheduler には以下の特徴があります。 フルマネージドのサーバーレスなスケジューラーです。 AWSサービスや標準HTTP/Sエンドポイントを自動的に起動するスケジュールタスクを簡単に作成・管理できます。 Lambda、SQS、SNS、Step Functionsなど、200以上のAWSサービスを直接ターゲットとして呼び出すことができます。 メール配信では、日時を指定してメール配信するスケジュール機能として採用することにしました。一度限りのスケジュールを設定するのにとても有用です。（定期実行にも対応しています） LocalStack にある制約 ありがたいことに LocalStack は、EventBridge Scheduler にも対応しています。 LocalStack は、よくできたエミュレーターですが完全に本物のAWS の挙動に対応しているわけではありません。初めのうちは喜んで開発を進めていたのですが、実装を進めているうちに以下の制約があることに気づきました。 EventBridge Scheduler in LocalStack only provides mocked functionality. It does not emulate actual features such as schedule execution or target triggering for Lambda functions or SQS queues. (LocalStack の EventBridge Scheduler はモック機能のみを提供します。スケジュール実行や Lambda 関数や SQS キューのターゲットトリガーといった実際の機能はエミュレートされません。) https://docs.localstack.cloud/aws/services/scheduler/#current-limitations 肝心のスケジュール実行ができないなんて困ってしまいました。ただ、これで諦めてしまうのはもったいないです。 開発環境なので、実装方法はこだわらなくても動いてくれればよいので、足りない部分を補うような仕組みを用意してみました。 制約の対処方法 LocalStack は EventBridge (rule の方) にも対応しているので、これで Lambda 関数を定期実行することでスケジュール実行の代わりをさせます。 今回は、ターゲットとして SQS のキューに Input の内容を送る仕組みを作ってみます。 構成 (シーケンス図) 本来は EventBridge Scheduler にスケジュール作成すれば、SQS に送ってくれるのですが、LocalStack では、間に EventBridge と Lambda を挟む構成になっています。 本来のアプリから Scheduler にスケジュールを作成 EventBridge Rule が毎分 Lambda を起動 Lambda は Scheduler から情報を取得し、期限超過なら SQS へ投入後、スケジュールを削除 実装 Go 言語の Lambda 関数コードの例です。 このコードは一回限りの実行 ( at 式 )のみに対応しています。( cron や rate などの繰り返しには未対応です） package main import ( "context" "errors" "strings" "time" "github.com/aws/aws-lambda-go/lambda" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/service/scheduler" "github.com/aws/aws-sdk-go-v2/service/sqs" ) var ( schClient *scheduler.Client sqsClient *sqs.Client ) func init() { // aws クライアントの初期化 cfg, err := config.LoadDefaultConfig(context.TODO()) if err != nil { log.Fatalf( "unable to load SDK config, %v" , err) } schClient = scheduler.NewFromConfig(cfg, func (o *scheduler.Options) { o.BaseEndpoint = aws.String( "http://localhost.localstack.cloud:4566" ) }) sqsClient = sqs.NewFromConfig(cfg, func (o *sqs.Options) { o.BaseEndpoint = aws.String( "http://localhost.localstack.cloud:4566" ) }) } func handleRequest(ctx context.Context) error { var maxResults int32 = 10 var nextToken * string // 有効なすべてのスケジュールを取得 for { resp, err := schClient.ListSchedules(ctx, &scheduler.ListSchedulesInput{ MaxResults: &maxResults, NextToken: nextToken, }) if err != nil { return err } for _, sch := range resp.Schedules { // スケジュールの詳細を取得 s, err := schClient.GetSchedule(ctx, &scheduler.GetScheduleInput{ Name: sch.Name, GroupName: sch.GroupName, }) if err != nil { return err } // スケジュールの必須フィールドが存在することを確認 if s.ScheduleExpression == nil || s.ScheduleExpressionTimezone == nil || s.Target == nil || s.Target.Arn == nil { return errors.New( "schedule is missing required fields" ) } loc, err := time.LoadLocation(*s.ScheduleExpressionTimezone) if err != nil { return err } t, err := timeFromAt(*s.ScheduleExpression, loc) if err != nil { return err } // スケジュールの実行時間が過ぎている場合、ジョブを実行 if t.Before(time.Now()) { // ジョブの実行 (SQS にメッセージを送信) queueUrl := queueUrlFromArn(*s.Target.Arn) _, err = sqsClient.SendMessage(ctx, &sqs.SendMessageInput{ QueueUrl: &queueUrl, MessageBody: s.Target.Input, }) if err != nil { return err } // ジョブの実行後、スケジュールを削除 _, err = schClient.DeleteSchedule(ctx, &scheduler.DeleteScheduleInput{ Name: s.Name, GroupName: s.GroupName, }) if err != nil { return err } } } if resp.NextToken == nil { break } nextToken = resp.NextToken } return nil } // "at(2025-12-24T12:00:00)" のような at 式から時間を抽出する関数 func timeFromAt(expr string , loc *time.Location) (time.Time, error ) { expr = strings.TrimSpace(expr) if !strings.HasPrefix(expr, "at(" ) || !strings.HasSuffix(expr, ")" ) { return time.Time{}, errors.New( "not an at expression" ) } body := strings.TrimSuffix(strings.TrimPrefix(expr, "at(" ), ")" ) t, err := time.ParseInLocation( "2006-01-02T15:04:05" , body, loc) if err != nil { return time.Time{}, err } return t, nil } // ARN からキュー名とリージョンを抽出し、QueueUrl を生成する関数 func queueUrlFromArn(arn string ) string { parts := strings.Split(arn, ":" ) if len (parts) < 6 { return "" } region := parts[ 3 ] queueName := parts[ len (parts)- 1 ] // LocalStack用のURL return "http://sqs." + region + ".localhost.localstack.cloud:4566/000000000000/" + queueName } func main() { lambda.Start(handleRequest) } LocalStack を利用するための Docker の compose.yml の例です。 services : localstack : container_name : "${LOCALSTACK_DOCKER_NAME:-localstack-main}" image : localstack/localstack ports : - "127.0.0.1:4566:4566" # LocalStack Gateway - "127.0.0.1:4510-4559:4510-4559" # external services port range environment : - DEBUG=1 # トラブルシューティングに役立つため、DEBUGログをonに設定 - SERVICES=events,lambda,scheduler,sqs volumes : - "${LOCALSTACK_VOLUME_DIR:-./volume}:/var/lib/localstack" - "/var/run/docker.sock:/var/run/docker.sock" LocalStack の環境を整えるための初期化スクリプト( init.sh ) の例です。 Lambda 関数のビルド&デプロイと EventBridge (rule) の設定を行います。 LocalStack の設定には awslocal コマンドを使用します。 #!/bin/bash set -ex # Lambda 関数の名前 func_name =localstack-schedule-executor # Lambda 関数のビルドとパッケージング GOARCH =arm64 GOOS =linux CGO_ENABLED = 0 go build -o bootstrap main.go zip ${func_name} .zip bootstrap # LocalStack 上にデプロイ awslocal lambda create-function \ --function-name ${func_name} \ --architectures arm64 \ --runtime provided.al2023 \ --handler bootstrap \ --zip-file fileb:// ${func_name} .zip \ --role arn:aws:iam::000000000000:role/lambda-role \ --timeout 30 # create-function 実行完了まで待つ sleep 5 # EventBridge ルールの作成とターゲットの設定 awslocal events put-rule \ --name schedule-execution-rule \ --schedule-expression ' rate(1 minute) ' awslocal lambda add-permission \ --function-name ${func_name} \ --statement-id schedule-execution-permission \ --action ' lambda:InvokeFunction ' \ --principal events.amazonaws.com \ --source-arn arn:aws:events: ${AWS_DEFAULT_REGION} :000000000000:rule/schedule-execution-rule awslocal events put-targets \ --rule schedule-execution-rule \ --targets ' [{"Id":"1","Arn":"arn:aws:lambda: ' ${AWS_DEFAULT_REGION} ' :000000000000:function: ' ${func_name} ' "}] ' # SQS のキューを作成 (確認用) awslocal sqs create-queue --queue-name test-queue 実行してみます。EventBridge Scheduler に値をセットして様子を見ます。(例では日本時間の 12/24 12:00 に設定) $ docker compose up -d $ sh init.sh $ awslocal scheduler create-schedule \ --name test-schedule \ --schedule-expression ' at(2025-12-24T12:00:00) ' \ --target ' {"RoleArn": "arn:aws:iam::000000000000:role/schedule-role", "Arn":"arn:aws:sqs:us-east-1:000000000000:test-queue", "Input": "test" } ' \ --flexible-time-window ' { "Mode": "OFF"} ' \ --schedule-expression-timezone ' Asia/Tokyo ' 実際に SQS キューにメッセージが入るのかを確認します。 $ awslocal sqs receive-message --queue-url http://sqs.us-east-1.localhost.localstack.cloud:4566/ 000000000000 /test-queue { " Messages " : [ { " MessageId " : " 73db45fd-e1b1-4376-bdaf-348e1a6411cb " , " ReceiptHandle " : " NWVjMDAyZDMtNjlhYi00ZGVlLWE3MjAtNjQ5ZTc1ODlhOGJkIGFybjphd3M6c3FzOnVzLWVhc3QtMTowMDAwMDAwMDAwMDA6dGVzdC1xdWV1ZSA3M2RiNDVmZC1lMWIxLTQzNzYtYmRhZi0zNDhlMWE2NDExY2IgMTc2NDI0MzIyNC4xNDMzNTgy " , " MD5OfBody " : " 098f6bcd4621d373cade4e832627b4f6 " , " Body " : " test " } ] } 完全なエミュレートではありませんが、これで必要な機能を実現できました。 やったね! おわりに LocalStack の足りない機能を、既存のものを組み合わせて補えることが面白いなと思い紹介しました。いずれは公式でサポートされることになるとは思いますが、それまでのつなぎとして参考になれば幸いです。 明日は、BASEアドベントカレンダーは @FujiiMichiro さんの記事です。お楽しみに！ BASE株式会社ではエンジニアを採用募集中ですのでご興味あれば下記の採用ページをご覧ください。 binc.jp

はじめに この記事は BASE アドベントカレンダー8日目の記事です。 devblog.thebase.in ネットショップ作成サービス BASE のプロダクト開発チームでエンジニアリングマネージャー（EM）をしている髙嶋です。 「開発生産性」という言葉は、一見共通言語のようで非常にブレやすく、定義も難しいものです。その辺については、昨年のアドベントカレンダーの記事で弊社開発担当役員の藤川も触れています。 devblog.thebase.in 今年はその開発生産性というビッグワードにいきなりフォーカスするのではなく、まずはそれを分解した「開発量」を増やそうと開発組織一丸となって取り組んできた1年でした。何がユーザーにとっての価値となるかはデリバリーしてみないと分からないゆえに、開発スピードを上げていかなければならないという前提があると考えています。そのため、まずはいわゆるレベル1生産性と呼ばれるような足元のアウトプットをしっかりと増やしていこうというものです。 私たちのチーム（数十名規模）でも、その方針に沿う形でハイスループットな開発組織になることを目指し、様々な取り組みをしてきました。この記事では、その1年の歩みについてご紹介したいと思います。ざっくりこの1年でのタイムラインを示すと以下の通りです。 内製ツールで計測基盤を構築する 各チームごとに振り返りの場で計測結果を分析し、改善活動へとつなげる 開発組織外へのレポートフローを作成し、組織横断で現状および起こった変化に対する目線を合わせられるようにする 改善活動のスピードと質をさらに高めるために外部ツールを導入する それでは、それぞれについて行間を埋めながら話を進めていこうと思います。 まずは計測して振り返る とにもかくにも計測基盤がないことには、チームで同じものを見て会話をするといった取っ掛かりを作ることができません。手始めとして内製ツールを利用し、スプレッドシート上で開発スタッツに関するデータを見られるようにするところから始めました。BASE のプロダクト開発組織全体としての数値、あとは各チームごとの数値を、下図のような形式で参照できるようにしました。 これを材料に各チームごとに振り返り会のような場でボトルネックを探ってもらい、改善活動を推し進めていくといった流れです。つまり計測する仕組みと、それを活用する仕掛けを用意したという格好です。プルリクのレビューを最優先にする、プルリクのサイズを適度に小さくするといったことに代表されるような、地道なアクションを一歩ずつ進めていくことで、その結果は着実に数値上でも表れていきました。 開発組織外とのコミュニケーションと組織状況の把握 自動取得できる開発スタッツ系以外の項目も加えて、月次で各種数値を Notion 上に蓄積し、全体のトレンドを把握できるようにしました。さらにそれを月次事業報告として開発組織外にもレポートするフローを作り、開発組織外との目線合わせもできるような体制を構築していきました。開発組織外にも適切に情報を届けることは、全社レベルでの組織運営観点からのフィードバックを得られるようにしたり、非エンジニアも巻き込んだ改善活動に取り組みやすい体制にしたりするために、非常に重要なことだと考えています。 ※PD Div：Product Dev Division という BASE のプロダクト開発組織の略称 加えておおよそのトレンドや開発 PJ との因果関係といったものも大まかには把握できるようになり、組織として次に目指す方向性を検討する材料の一つにできていると感じます。1年という期間を通じてモニタリングしてきたことで、開発組織としてのリズムをより解像度高く捉えられるようになったことには大きな意味がありました。 内製ツールから外部 SaaS ツールへ 年初からそうした取り組みを始めて半年が経過しようかという頃、改善が進んできたからこそ、内製ツールにおける運用だと以下のような課題が目立つようになってきました。 取得できるデータに限りがあって課題の深堀りがしづらく、改善アクションの精度向上が難しい メトリクスの悪化に気付くきっかけ（アラート）がなく、対処が後手に回りやすい チームのスタッツを相対的に評価する指標や基準がない ツールのメンテナンスコストが継続的にかかり、対応も属人的になってしまっている こうした課題を解決し、改善活動のスピードと質をさらに高めることを目的に、Findy Team+ の導入を決定しました。いきなり有償ツールを入れるのではなく、改善が進んでそれをより発展させるためにツールを入れるという順番になったことは、とても良かったポイントの一つだと考えています。ただしここで一つ懸念としてあったのが、実際に各チームで活用していこうとすると、多機能であるがゆえにどこからどう使えばいいか迷いやすくなってしまうのではないかということです。そのため現場任せにせず、組織として意思を持って活用を進めるために、最初は推奨する活用フローと機能スコープを提示することにしました。 今では基本的な使い方が定着したことで、各チームの課題や開発スタイルに応じてチューニングをしたり、より応用的な活用ができないかといった検討も進めているところです。ちなみにいくつか計測している指標の中でも、サイクルタイムはコミュニケーションの効率化指標として注目して追ってきた項目です。それが下図のように右肩下がりとなってからは安定した状態を維持できていることからも、一定成果が出ている状態にあると言えるのではないかと考えています。 ※Findy Team+ 画面より引用 実は2年前にも取り組んだことはあった いわゆる「開発生産性を上げよう」といった取り組みは、実は2年前の2023年にも取り組んだことがありました。やっていることの内容自体は、その当時と今回とで実はそこまで大きな差分はないのかもしれません。前回は半年程度で立ち消えとなってしまいましたが、今回は1年以上継続しており、来年もその発展をさせていこうという状況です。 では一体何が違ったのでしょうか。それは結局のところ、今回の場合は開発組織全体としての方針が、組織図上の先から先まで張り巡らされていたという前提が大きかったのではないかと考えています。私の立場で言うと一開発部署の一中間管理職となるわけですが、自部署だけで声を挙げて取り組んでいこうとするのではなく、まず会社としての意思が先にあり、それにアラインする形で取り組むんだということで覚悟が違った部分はあったと思います。もちろん自部署だけでスコープを区切って物事を進めやすくするといった手段はよくある話かと思いますし、今回も日々の活動としてはそのような形となっています。しかしながら大前提となる方針が会社レベルで先に示されたことで、自部署内での取り組みに対しても助けになったのは間違いありません。 まずは開発スタッツの計測から始めてみようとしたのが前回だったのですが、探索フェーズと考えればそれ自体がダメだったとは思っていません。ただし組織として目指したい方向性や日々変化する組織状況に対する解像度がマネージャー各人の中でもまだ低かったこともあり、改善が一定進んだときに「さて、ここからどうしよう」となってしまったのかなと思っています。12月4日の @tanden の記事でも、そうした悩みについては書かれています。 devblog.thebase.in 今回は幹がしっかりとあり、それゆえ中長期的な活動にすることを見据えて、計測基盤一つをとっても意思を持って整備しにいったことが今につながっていると考えています。 おわりに 開発量向上を旗印に1年をかけて様々な取り組みを進めてきましたが、組織として前進した部分は素直に認めつつ、伸びしろがあるのも間違いはないので今後も着実にレベルアップを図っていきたいと思っています。また本文脈においても生成 AI とどう付き合っていくかは無視できない観点の一つですが、ただ量が出せればいいというわけではなく、当然ながらそこには質や成果が伴ってくることも重要です。目先の数値にとらわれすぎず、エンジニア一人ひとりが納得感を持って前向きに開発に取り組める状態を作ること、一方で自分たちを客観的に見て内省するための仕組みと機会を用意し、より良いチームとなって顧客への価値提供サイクルを早めていくことが求められるのだろうと思います。 BASE では、今後のプロダクト成長を支える技術戦略や開発基盤の構築をリードしていただけるエンジニアを募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。 binc.jp 明日の BASE アドベントカレンダーは @okinaka さんの記事です。お楽しみに！

この記事はBASEアドベントカレンダー 2025 の 7 日目の記事です。 エンジニアの右京です。BASE では今年、表示速度の改善を目標にすべてのショップへ Cloudflare を導入しました。これは、その過程や技術面の簡単な解説です。 記事は前後半になっており、この記事は後半で、Cloudflare Workers を利用したコンテンツのキャッシングの話題となります。 前半はこちら: Cloudflare でショップページをちょっとだけ速くしてみた - 導入/SSL for SaaS 編 ショップページのレスポンス速度を改善したい レスポンス速度を改善するにあたって、Cloudflare Workers を利用して前段でコンテンツをキャッシュするアプローチが有効なことは事前にイメージがついていました。この方針について特に以下の記事が参考になりました: zenn.dev しかし、現状のショップページが前段でキャッシュされることを想定して作られているわけではありません。例えば在庫数は、アクセス毎にサーバーサイドで都度計算を行い HTML として書き出しているため、長くキャッシュを持ってしまうと「商品ページは在庫がある表示なのにカートに商品が入らない」といったことが起こってしまいます。他には、時間経過によって販売状態が変化する商品であったり、抽選販売への応募期間といった時刻が関係するものも、現状の実装では長くキャッシュすることができません。 一方で、実際の購入フローでは必ずカートでの購入操作がある上、厳密な在庫や時刻に関する処理はカートで行われるので、ショップページに在庫数などがリアルタイムに反映され続ける必要というのは実はそこまでありません。そこで、数秒であればこのズレは納得できる範囲だろうと判断し、まずは小さく始めることができ、かつ大きな効果が期待できる「商品ページを数秒間マイクロキャッシングする」を実装することにしました。 最終的にはほとんど静的な作りにし、長くキャッシュを持つことで高速なレスポンスにするという目標はありつつも、まずはアクセススパイク時のインフラ面への負荷を抑えることを主軸としていきます。 Cloudflare Workers の設計と実装 まず、Cloudflare を利用する上での大前提として「Cloudflare ありきの設計にはせず、何かあった場合は外せるようにする」ということを設定しました。これには Workers 単体での障害程度であれば Workers を外すことでサービスを維持できるように、最悪 Cloudflare をやめることになってもサービスを維持できるように、という想いがあります。 ストレージの選択 当初想定していた Workers KV ではなく Cache API を採用することにしました。Cache API は前半でも登場した Cloudflare の Cache (あいまいさ回避のため以後 Cf Cache と呼ぶ)を Workers から操作できる API で、同一 DC 内であれば高速な書き込みと読み出しが行えます。 developers.cloudflare.com Cf Cache を Workers から扱うもう一つの方法として fetch を行う際に独自のフィールドを持った Request を利用する、というものがあります。 developers.cloudflare.com Cache API と fetch を比較した場合、性能だけを見ると fetch の方が次の 2 点で優秀です: Cache API では Tiered Caching が働かない fetch は同一のリクエストと判定できる場合リクエストをまとめてくれる(Request Collapsing) その上で今回 Cache API を選択したのは、その柔軟さにあります。Cache API は Cf Cache に乗せる API と Origin(BASE の Web アプリケーション本体) へのリクエストが分かれているので、キャッシュする前に Header を加工したいようなケースで有効になります。 また、これは自分の調査検証不足もあると思うのですが、 Request Collapsing を利用するにはレスポンスがキャッシュできる前提が必要であるような挙動をします。シークレット EC 機能を実現する際に、Request Collapsing を利用するとどうしてもどこかがキャッシュされてしまったため、Cache API を利用することにしました。 次に Workers KV を見送った理由ですが、書き込み制限と反映の遅延にあります。 KV は同一キーには 1 秒間に一度しか書き込みできず、かつその仕組み上反映が最大で 60 秒遅延します。 developers.cloudflare.com この特性から、今回の「数秒のマイクロキャッシング」には適していない判断としました。ただし KV を完全に利用していないわけではなく、後述する X-Webapp-Version のストアには KV を利用しています。コンテンツの更新頻度が頻繁ではないデータを、長期間に渡って信頼できるソースとして扱うことに向いているようです。 そして、KV ではなく Cf Cache を使う最大の利点が「 Cache-Control を元々うまく扱える」というところで、コアとなる仕組みはこれを活用した設計になっています。 Cache-Control を利用したキャッシング よく max-age=86400 などが指定されている Response Header で、コンテンツをキャッシュする際の挙動を指示するためのものです。このディレクティブにはいくつか CDN 向けのものがあります。 www.cloudflare.com CDN 向けのものに s-maxage というディレクティブがあり、これが今回のコアとなっています。 s-maxage は端的に言えば CDN 用の max-age で、例えば s-maxage=2 であれば 2 秒間 CDN にキャッシュできる、ということを示しています。 Cf Cache はこれを扱えるので、Header に Cache-Control: s-maxage=2 を持つ Response を Cache API から put することで、 2 秒間生存するキャッシュを作ることができます。作られたキャッシュは match で取り出せるので、これらを合わせると次のようなコードで Workers でのキャッシュを実現できます: export default { async fetch ( request , env , ctx ) { const cache = caches . default ; const cacheKey = new Request (( new URL ( request . url )) . toString () , request ) ; const cachedResponse = await cache . match ( cacheKey ) ; if ( cachedResponse ) { return cachedResponse ; } const newResponse = await fetch ( request ) ; // Cache-Control: s-maxage=2 ctx . waitUntil ( cache . put ( cacheKey , newResponse . clone ())) ; return newResponse ; } } Origin がキャッシュしたいページで Cache-Control: s-maxage=2 を返すと、Workers でこのコードを通って 2 秒間コンテンツがキャッシュされます。この s-maxage と合わせて 3 種類の Cache-Control を Origin が返すことでキャッシュをコントロールしています: s-maxage=N - コンテンツを N 秒間キャッシュする private - CDN にキャッシュできないことを示すディレクティブ、公開だがキャッシュしたくないページ、未対応のページで使用 no-store - CDN にもローカルにもキャッシュしない、シークレット EC で使用 上記のコードは一見すべてのレスポンスをキャッシュするように見えますが、 Cache API は Cache-Control がキャッシュできないことを指示していたり、 Set-Cookie が含まれている場合にはそのコンテンツをキャッシュしません。実際のコードでは put する条件として s-maxage を含んでいることを条件にしてはいますが、このままでも Origin がキャッシュ可能なレスポンスを返さない限りは何もしないようになっているので、安心して利用することができます。 この実装をコアとして、Origin との整合性を担保するための仕組みと、 Cache Stampede を緩和するための機能を加えています。 キャッシュキーの設計 ショップページでは一つの URL からユーザーの環境や設定に合わせた複数のレスポンスが返されるため、 Request Header や Cookie からキャッシュに利用するキーを計算することで、URL に対して複数のキャッシュを紐づけています。このキーにはキャッシュの世代管理のための値も含まれていて、Origin がデプロイされた場合にキャッシュのパージを行うのではなく、利用するキャッシュの参照を切り替える方式を取っています。 ざっくりと次のようなキーになっています: shop . example . com / items / 1234 ? webapp_version = xxxx - yyyy - zzzz & accept_language = ja , en & i18n_language = ja & i18n_currency = JPY webapp_version はキャッシュの世代管理のための値で Origin から取得します。Origin にはデプロイ毎に一意の値が割り振られており、ショップページのすべてのレスポンスと専用の API に X-Webapp-Version という独自の Response Header を含んでいます。 X-Webapp-Version: d8643bc9-02ae-49db-b37f-81c26e77cb39 Workers から定期的に API をコールして最新の値を取得していて、Workers ではこの値に一致するキャッシュのみを有効なものとして扱っています。また、各ページのレスポンスにもこれを含んでおくことで、早い段階でのデプロイの検知や、Blue / Green デプロイ中で Origin が新旧を混合で返す状態でも古いキャッシュを作成しないようにしたり、ということに役立てています。 accept_language には BASE でサポートしている日本語と英語にあわせて、Request Header の Accept-Language を ja,en もしくは en,ja に丸めた値が入ります。 Accept-Language をそのまま使用してもよいですが、種類が増えキャッシュヒットレートが下がってしまうので Workers で丸めています。 i18n_language と i18n_currency はユーザーが選択した言語と通貨の情報で、Cookie に入っています。 Origin ではこの Cookie の値が accept_language よりも優先され、指定された言語と通貨で HTML をレンダリングするため、キャッシュを細かく分ける必要があります。 基本的には静的な作りにしていく方針ですが、言語通貨のようにどうしてもユーザーによってレスポンス内容を変えたい場合はキャッシュキーを拡張して対応します。 X-Fresh-For stale-while-revalidate な動作を実現するための仕組みで、 s-maxage と組み合わせて使用します。コンテンツが新鮮な時間を表す Response Header で、任意の値が Origin から返されます。 Cache-Control: s-maxage=10 X-Fresh-For: 2 キャッシュから取得した Response の Age とこの値を比較し、指定されていた分の時間が過ぎていたら、ユーザーにはキャッシュが古いことを表す STALE 状態でキャッシュを返し、バックグラウンドでキャッシュの更新をします。上記であれば、最大 10 秒間キャッシュし 2 秒を超えた時点でアクセスがあれば更新を行う、という動作になります。 キャッシュが切れた際にオリジンへのアクセスが再度集中してしまう、 Cache Stampede を緩和する仕組みとして導入しました。キャッシュ時間を s-maxage のみの場合よりも遥かに長くすることができ、 STALE している間に次のキャッシュを作ることで、キャッシュが完全にない状態を減らすことが目的です。 概念としては次のようなコードで実装されています(このコードは動作しません)。さっきは Cache API と fetch からの Cf Cache 利用を比較していましたが、ここではこの 2 つを組み合わせていることがポイントです。 STALE 状態のキャッシュは「キャッシュできるコンテンツである」という前提があることになるので、安全にリクエストをまとめることができます。 const cachedResponse = cache . match ( cacheKey ) ; if ( isStale ( cachedResponse )) { ctx . waitUntil (() => { const revalidateKey = cacheKey + `&revalidate= ${ cacheResponse . header . get ( 'X-Cache-Id' )} ` ; const newResponse = fetch ( request , { cf : { cacheKey : revalidateKey , cacheTtl : 1 } }) ; newResponse . headers . set ( 'X-Cache-Id' , uuid ()) ; cache . put ( cacheKey , newResponse ) ; }) ; } return cachedResponse ; キャッシュされてから時間が経ったものを検知すると、アクセスに対しては古いレスポンスを返しつつ、裏で更新を行っています。この時に再検証用のキャッシュキーを別途作り、それを使って Request Collapsing の利用を目的とした fetch を呼び出し、その結果を Cache API で実際に使用するキャッシュとして改めて put します。このような実装にすることで、複数の再検証リクエストが一つにまとまり、Origin へ到達するリクエストを削減することが可能になりました。 2025/12/15 追記: この利用方法の場合、 Request Collapsing は fetch のレスポンスが Cf-Cache-Status: MISS の場合に動作するようです。 MISS ではなく Cf-Cache-Status: EXPIRED となる場合、リクエストがまとめられていないことがあります。実際に動作しているものは Response にユニークな Id を割り振ったものをキャッシュし、更新リクエストに含めています。上記のコードも修正済みです。 Cache-Control には stale-while-revalidate ディレクティブがあり、これを利用したいと考えていたのですが、Cache API ではこれを利用できないという制約があり独自に実装するような形になりました。例えば s-maxage=2, stale-while-revalidate=10 の場合、キャッシュとしては STALE になりつつも 12 秒間生存してほしいのですが、Cache API の場合は 2 秒でキャッシュが蒸発してしまいます。キャッシュ時間自体を伸ばすためには s-maxage を伸ばす必要があり、このような形になりました。 developers.cloudflare.com Origin 側の変更点 Workers だけではキャッシュが動作しないようになっているので、ここまでに解説してきた各種 Response Header を Origin が返すように改修を行いました。CDN でのキャッシュを禁止する Cache-Control: private をすべてのページで返すことを基本としつつ、キャッシュしたいページでは次のように返します: Cache-Control: s-maxage=6 X-Webapp-Version: d8643bc9-02ae-49db-b37f-81c26e77cb39 X-Fresh-For: 2 キャッシュ動作に関して Origin は Response Header を追加しただけで、これによって動作がなにか変わることはありません。Workers がなくなっても動き続ける設計を達成できたように思います。 また、商品の特性によってキャッシュ時間をコントロールすることも可能なので、例えば販売前→販売開始のようにステータスが遷移する時刻をまたぐ場合直前には s-maxage を短く設定するようにしています: Cache-Control: s-maxage=1 X-Webapp-Version: d8643bc9-02ae-49db-b37f-81c26e77cb39 ただし、さすがに既存機能のコードをまったく変更せずに、とはいかなかったので事前にいくつか以下のような調整を行っていました: 言語通貨設定が CakePHP の Session 機能に依存していたため、 Plain な Cookie での実装へ変更し、Cloudflare Workers でも読み出せるように 商品の閲覧履歴を CakePHP の Session 機能から localStorage を用いたものに変更 一部ログイン状態によってラベルやメニューが変更される箇所の改修、元々非ログイン状態の表示に統一したい認識があったため、これにあわせて変更 query として付与させる referrer 情報を事前にサーバー側で処理するコードがあったため、クライアント側で処理ができるように調整 効果 まず、レスポンス速度についてです。キャッシュの導入以前の商品ページは、利用している拡張機能やアクセスの状況にもよりますが、Chrome DevTools で確認する限りでは大体 600ms ~ 2s 程度のサーバー応答待ち時間(Waiting for server response の値)がありました。 キャッシュが有効な場合はこの値が大きく改善され、100ms ~ 150ms 程度で安定するようになります。平均的に 1 秒を超えてくるようなショップだと、1/10 程度になったことになります。ただしあくまでキャッシュが存在する前提なので、すべてのアクセスでこの恩恵を受けられるわけではありません。 では、キャッシュがどの程度働いているかをとある日のアクセススパイクを含む 30 分で見てみます。縦軸がキャッシュヒット率(%)、横軸が時刻、赤が全体のキャッシュヒットレート、緑が HIT 、青が STALE でそれぞれ返した割合です。 12:00 頃にアクセスが集中し、キャッシュヒット率が 80-90% 付近まで跳ね上がっています。具体的な数字で言えば、商品ページ毎にざっくり 50,000 程度のアクセスがあり、そのうち 40,000 を HIT 、5,000 を STALE で返しているようなイメージ感で、高いものだと 90% のリクエストキャッシュから返しています。このログには Bot も含まれているのですべてが人間に向けて返されたものではありませんが、Origin への到達を 90% キャッシュで捌けていると考えるとそれなりに効果があるように思えます。 このタイミングで商品ページにアクセスすると 100ms 程度でレスポンスが返ってくるので、全体でみるとちょっとだけショップページが速くなったことになります、なりませんか？ おわりに ということでショップページがちょっとだけ速くなった話でした。ショップページは改良の余地が多くがあり、Cloudflare の活用もまだまだこれからです。こういった領域に興味が湧きましたら採用情報もぜひご覧ください。 binc.jp 明日は @takashima です、お楽しみに！

この記事はBASEアドベントカレンダー 2025 の 6 日目の記事です。 エンジニアの右京です。BASE では今年、表示速度の改善を目標にすべてのショップページへ Cloudflare を導入しました。これは、その過程や技術面の簡単な解説です。 記事は前後半になっており、この記事は前半で、Cloudflare を導入〜直後までの話題となります。 モチベーション ショップページの表示が遅いことに尽きます。サービスが大きくなり、機能が増えていく中で処理が増え、速度が犠牲になってしまうのはある程度は仕方ないことだとは思います。とはいえレスポンスを返し始めるまでに 1 秒以上かかるようなケースもザラにあり、そこにアクセスのスパイクが重なると 10 秒以上返ってこない、オートスケーリングや手動でのスケーリングが都度必要… と、成り立ってはいるものの「良い」とは言えない状態でした。 一方でオーナーが利用する管理画面とは異なり、ショップページは在庫などの一部のデータを除けば、利用者によって変わる表示も極一部で、ほとんど静的サイトのような作りになっています。そこで、Edge Worker でのコンテンツのキャッシュがスピード面でもインフラ面でも効果が期待できるだろうということで Cloudflare の導入検討を始めました。 vs CloudFront BASE は基本的に AWS に乗っかって動いているので、 Cloudflare の特に Workers への対抗馬として CloudFront + Lambda@Edge / Functions があります。今回検討していた時点では技術面では以下の点を考慮して、採用を見送りました: 独自ドメインの証明書の問題 CloudFront をショップページとして扱う場合、証明書を CloudFront に配置する必要がある 具体的な数値は出せないが、現状のドメインをすべてカバーするためには複数のディストリビューションを管理する必要があり、現実的ではない コンテンツをキャッシュすることを前提とした設計 CDN なので当たり前といえばそうだが、あくまでキャッシュされているコンテンツに対する操作という印象 BASE では特定の会員のみが利用できるシークレット EC 機能を同じ仕組みの上で提供しているので、キャッシュ前提となるのが扱いづらい KV やストレージの自由度 コンテンツのキャッシュ以外にも何かしらのメタ情報はストアできる必要があるだろうという前提があった CloudFront KeyValueStore があるものの、Edge Worker からは読み取り専用 Cloudflare の Workers KV と比べるとどうしても取り回しが難しいように感じた 現在ではどうかというと、AWS 側でもこれらを解決するようなソリューションが発表されており、状況が変わっていることに注意が必要です。 aws.amazon.com Cloudflare を導入する 当然ですが、 Cloudflare が BASE のアプリケーション(Origin と呼ぶ)よりもエンドユーザーに近い位置で動作する必要があります。そのため、これまで Internet → Origin だった経路を、 Internet → Cloudflare → Origin に変更する必要があります。ここで問題になるのがショップページのドメインです。 ショップページのドメインには 2 つのパターンがあります: BASE の管理ドメインのサブドメイン base.shop / base.ec / theshop.jp のようなドメインを BASE が管理 これのサブドメインとして、例えば example.base.shop でショップページを配信 オーナーの持ち込み独自ドメイン 独自ドメイン App で CNAME を利用して任意のドメインでショップページを配信 前者の場合は特に問題はなく、経路変更を行うだけで済みます。詳細な内容はそれぞれの都合で異なると思うので割愛しますが、Origin に Cloudflare からアクセスされるサブドメインを新たに用意しておき、DNS 設定を切り替えることで経路が次のように変更されます: [導入以前] Internet ──▶ example.base.shop(Origin) [切替後] Internet ──▶ example.base.shop(Cloudflare) ──▶ from-cloudflare.base.shop(Origin) from-cloudflare の部分をユーザーが作ったり上書きできないようにしておく必要はありますが、大した問題ではないでしょう。このタイプのドメインは特にメンテナンスを必要とすることなく、無停止で移行していきました。 問題は後者のオーナーの持ち込みドメインです。前述のように CNAME で管理されており、オーナーが設定した DNS では CNAME cname.thebase.in となっています。Cloudflare を通すという理由でこれをすべてのオーナーに変更してもらうのは現実的ではないので、なんらかの方法で設定を維持したままドメインが Cloudflare へ解決される必要があります。ここで登場するのが SSL for SaaS です。 Cloudflare SSL for SaaS developers.cloudflare.com qiita.com ドキュメントの説明にもある通り、カスタムドメインをサポートする機能です。簡単に言ってしまうと、 持ち込みドメインをBASE 管理下にあるドメインと同様に from-cloudflare.* へ転送する機能です。 developers.cloudflare.com Custom Hostname を作成し、 SSL 証明書が発行された状態で cname.thebase.in が Cloudflare を向くようになると、持ち込みドメインが Cloudflare を通過してから Origin へ到達するようになります。 この切り替えは停止メンテナンスで行ったのですが、メンテナンス中にすべてのアクティブな独自ドメインを Custom Hostname として登録し、証明書の発行を終えるのは現実的ではなかったため、事前に Pre-validation という仕組みを使って移行の準備を進めていました。 developers.cloudflare.com Pre-validation を使うと、現行のアプリケーションを稼働させたまま Cloudflare 側に SSL 証明書を配置しておくことができます。BASE では HTTP Tokens の方を使用していて、Custom Hostname を作成すると Cloudflare の Dashboard もしくは API から検証用の http_url と http_body を得ることができます。 { " result ": [ { " id ": " 24c8c68e-bec2-49b6-868e-f06373780630 ", " hostname ": " app.example.com ", // ... " ownership_verification_http ": { " http_url ": " http://app.example.com/.well-known/cf-custom-hostname-challenge/24c8c68e-bec2-49b6-868e-f06373780630 ", " http_body ": " 48b409f6-c886-406b-8cbc-0fbf59983555 " } , " created_at ": " 2020-03-04T20:06:04.117122Z " } ] } https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/pre-validation/ より引用 ドキュメントでは ownership_verification_http というフィールドでそれが返ってきていますが、このフィールドは少し時間が経過すると使用することができず、そのタイミングまでにレスポンスを準備できない場合は ssl フィールドに含まれる http_url と http_body を使う必要がありました。 { " result ": { " ssl ": { " status ": " pending_validation ", " http_url ": " http://app.example.com/.well-known/acme-challenge/uVKCkPGJZt2PewfPPQxSRe8QTDDyq_DzOLZ4AK5T1Vg ", " http_body ": " uVKCkPGJZt2PewfPPQxSRe8QTDDyq_DzOLZ4AK5T1Vg.LNFwUG0womdgXgxKtKU4B6bqUXvBkIouc5BNejjQTh0 " , }, } } 定期的にこの URL に Cloudflare からアクセスがあり、 http_body の内容を返すことができれば検証に成功し、Custom Hostname が有効になって SSL 証明書が配置されます。簡単に図にすると以下のようになり、一時的に SSL 証明書が 2 つになります: [Origin] app.example.com [Internet] ────────────────▶ 元々ある SSL 証明書 ◀──────────────── アプリケーションの動作 create apps.example.com ◀──────────────── ドメインの登録や更新をトリガーに作成 [Cloudflare] /.well-known/acme-challenge/uVK... ────────────────▶ ◀──────────────── uVK.... apps.example.com の SSL 証明書が事前に発行される 移行準備中 ──────────────────────────────────────────────────────────────────────────── 切り替え後 [Internet] [Origin] │ app.example.com 元々あった SSL 証明書は不要に │ │ ▼ from-cloudflare.* [Cloudflare] ────────────────▶ アプリケーションの動作 SSL証明書 切り替えメンテナンスの事前準備として、すべてのドメインを事前に Cloudflare に登録、 SSL 証明書が発行された状態にしておき、実際のメンテナンスでは NS の切り替えのみにすることで、比較的短い時間での切り替えが完了しました。 また、これ以降は SSL 証明書の管理を Cloudflare が行ってくれるようになります。自前での更新が不要になるので、これも利点の一つと言えるでしょう。 切り替え直後のトラブル 過去の動作との不整合で一部個別対応が必要なケースはあったものの、特に大きな問題はなく切り替えを終えることができました。ただ、少し想定外だったことが 2 つあったので、それを書いてこの記事は締めようと思います。 Cloudflare を通った時点でデフォルトのキャッシュが動作する 何も設定をしていない場合、一般的にキャッシュできるとみなされるアセットのキャッシュが自動的に始まります。デフォルトの挙動は以下で確認することができます: developers.cloudflare.com 殆どの場合は困らないと思いますが、動的に JS を作成したり、ビルド済み JS をアプリケーションから配信している場合は注意が必要です。影響は軽微だったものの一部動的に生成されているものがあり、これが原因で不具合が発生しました。 この設定は Cache Rules を作成することで上書きすることができます。切替時はすべてを Bypass する設定にしておくのが無難に思いました。 developers.cloudflare.com O2O 管理している Cloudflare より前に別の Cloudflare がいる状態です。Cloudflare のアイコンがオレンジなので Orange-to-Orange というらしいです、可愛いですね。 developers.cloudflare.com この状態が存在することを認識していないと、「キャッシュをしていないはずなのに Cloudflare がキャッシュを返している」という状態になったときに混乱します、しました。 これは持ち込まれるドメインの DNS が Cloudflare の場合に起こります。CNAME を設定する際に自身の Cloudflare でも Proxy をするという設定があり、これを使うとオーナー側の Cloudflare でコンテンツをキャッシュできるようになります。こうなると、こちらが管理できる範囲よりユーザーに近い場所でキャッシュが起こってしまい、基本的には手が出せない状態になってしまうので、個別でなにかしらの解決をする必要があります。 おわりに 明日は続けて Cloudflare Workers でのコンテンツのキャッシュについて書きます。よろしくお願いします！

はじめに この記事はBASE Advent Calendar 2025の5日目の記事です。 devblog.thebase.in こんにちは！Pay IDのEngineering Sectionでエンジニアリングマネージャーを務めている岡部（ @rerenote ）です。今回はPay ID…ではなく、社内の有志で活動している iikanji-conference-toudanチームによる「技術イベント・カンファレンスのスポンサー活動」について、今年の取り組みをまとめてご紹介します。 iikanji-conference-toudanチームとは？ iikanji-conference-toudanチームは技術イベント・カンファレンスへBASEから登壇する人たちを応援するために立ち上げられました。社内の有志メンバーで構成されています。 登壇資料のレビュー相談をはじめ、こういう技術イベントがあったよ、こういう発表がおもしろかったよなどのカジュアルトーク、スポンサーブース出展時にはブース企画なども行なっています。 2025年のスポンサー活動一覧 「登壇するメンバーをもっと後押ししたい！」という思いから、技術イベント・カンファレンスへのスポンサー協賛活動に取り組みました。協賛活動を通してBASEメンバーのトークを見つけてもらうきっかけ作りにもなっています。 協賛したのはBASEで採用しているPHP、TypeScriptのカンファレンス。今年はこの2つの技術領域でコミュニティとの繋がりを深める一年になりました。カンファレンス運営のみなさま、参加者のみなさま、このような場をいただき本当にありがとうございました。 各イベントの詳細は、以下のレポートにまとめています。登壇者コメントや参加メンバーによるレポート、ブース企画についての内容もありますので読んでいただけたら嬉しいです。 PHPerKaigi 2025（3/21-3/23） devblog.thebase.in PHPカンファレンス小田原 2025（4/12） devblog.thebase.in TSKaigi 2025（5/23-5/24） devblog.thebase.in PHP Conference Japan 2025（6/28） devblog.thebase.in おわりに 私は過去に個人で勉強会を主催したり、技術イベントやカンファレンスのスタッフとして数年活動していた背景があり、技術コミュニティやカンファレンスという場そのものがとても好きです。iikanji-conference-toudan に参加している一番の理由は、そうした好きな場所に、少しでも貢献できたら嬉しいと思っていることが大きいのかもしれません。 BASEでは会社全体でOSSやコミュニティを応援する文化があり、このような活動を行えることにいつも感謝しています。 2026年もイベント・カンファレンスでの登壇を応援したり、スポンサー活動を通してコミュニティを盛り上げていければと思っておりますので、どうぞよろしくお願いいたします。 プロダクト開発も好きだけど技術コミュニティも好き！という方でBASEに興味を持っていただいた方は、エンジニア募集中ですので採用情報もぜひ覗いてみてください！ binc.jp 明日のBASEアドベントカレンダーは @yaakaito さんの記事が登場する予定です！お楽しみに！

はじめに この記事はBASEアドベントカレンダーの4日目の記事です。 devblog.thebase.in EC作成サービスBASEのプロダクト開発チームでエンジニアリングマネージャー（EM）をしている @tanden です。 私たちのチームではこの1年ほど、開発組織のケイパビリティをどう可視化し、継続的に改善していくかについて考え方の整理と運用に取り組んできました。「今の組織はどこが強みで、どこに伸びしろがあるのか？」を共通の視点で語れるようにするため、SPACEのようなフレームワークにヒントを得ながら、組織を立体的に捉えるための「補助線」を引くことを目指しました。 この記事では、私たちが整理した「開発組織のケイパビリティ可視化」のコンセプトと運用方法について紹介します。まだ取り組みの途中ですが、組織運営のヒントになれば幸いです。 ケイパビリティ可視化の取り組み振り返り EC作成サービス BASE のプロダクト開発組織ではこれまで、Four Keys を開発チームのケイパビリティ指標として捉え、Google Apps Script などを用いてプルリクエストのマージ数やリードタイムを計測し、改善につなげてきました。 マージ数やリードタイムは今も継続して追いかけている重要な指標で、計測と振り返りをセットで運用することで一定の成果を得られています。 一方で、複雑さが増すプロダクト開発・運用の実態を捉え、組織として継続的に改善サイクルを回していくには、これらの指標だけでは不十分ではないか——そんな考えが徐々に生まれていきました（課題感に共感いただける方もいるのではないでしょうか）。 そんな中で、これまでの取り組みを振り返りから、主に以下の3点が課題として挙がりました。 組織としての方向性や全体像が曖昧だった 本来であれば「どんな組織を目指すのか」という前提に沿って指標を選ぶべきでしたが、その背景や全体像を描き切れていませんでした。 プルリクエストの指標だけでは複雑な開発を捉えきれない マージ数やリードタイムは重要ですが、プロダクト開発を多面的に理解し、改善サイクルを回すには要素がやや不足していました。 一定の改善ラインを越えると伸びしろが見えづらくなる プルリクエスト関連の指標は、ある程度最適化されるとそれ以上の改善余地が小さくなり、チームの状態把握はできても、次のアクションにつながりにくくなっていました。 ケイパビリティ可視化のコンセプトと目的 そこで私たちは、これまでの反省を踏まえつつ、開発組織のケイパビリティ可視化の枠組みづくりに取り組むことにしました。 「汎用的な生産性や開発力指標は存在しない」という前提のもと、上記3つの課題を反転させるため、以下のコンセプトのもと進めました。 個別指標の妥当性よりも、開発組織の能力の全体像と方向性を描いてから指標の位置づけを明らかにする 複数指標を利用して組織の能力や状態を多面的に測れるようにし、定期的に計測指標を入れ替えることで改善のきっかけを提供し続ける 指標を達成できるかどうかよりも、改善後の組織やチーム・個人の理想状態をイメージできるかどうかを重視する 上のコンセプトを満たしつつ、対話を通じた未来へのアクションプラン作りと改善の実行・計測のサイクルを回すこと目的に、ケイパビリティ可視化の取り組みを進めました。 『サーベイフィードバック入門 p.28』（中原淳著）を参考に作成 開発組織の4つのケイパビリティ 開発組織のケイパビリティ可視化を進めるために、まず開発組織のあるべき姿を描いていく必要があります。開発組織のあるべき姿を描くために、この取り組みの中では Evidence Based Management（EBM） という考え方を参考に、全社やプロダクト開発組織において定義されているミッション・ビジョン・バリューと整合させる形で、開発組織のケイパビリティを4つの分野に整理しました。 サービス価値の維持 ユーザーが今現在価値を感じて利用しているサービス上の機能提供を維持し続けること。 全社におけるミッションやビジョンとの整合性 「人生のオーナーを増やす社会基盤」（基盤=いつ・いかなる状況でも利用できる信頼性が高いもの） プロダクト開発組織のミッションやビジョンとの整合性 「ショップが成長していくことを支えるサービスであり続ける」 「トラフィックを適切に受け止めて、決済を無事に完了させる」 素早い価値提供 新しい価値を提供するまでに必要な時間を限りなく短くすること。 全社におけるミッションやビジョンとの整合性 価値提供スピードについての言及はないが、スタートアップとしてのスピード感で価値提供・価値創出を行い、社会基盤の構築を目指すことは暗黙的な前提 プロダクト開発組織のミッションやビジョンとの整合性 ハイスループットなプロダクト開発組織を目指す 新しい価値の実現 まだ実現できていない価値（機能や体験）をテクノロジーの力で実現すること。 全社におけるミッションやビジョンとの整合性 「あたらしい決済で、あなたらしい経済を」 プロダクト開発組織のミッションやビジョンとの整合性 「多様なニーズに応える機能改善をし続ける」 「サービスの成長にチャレンジしていく」 参考として、BASEグループとプロダクト開発組織のMissionやVision、Foundationがまとまっている会社紹介資料を掲載させていただきます。 手前味噌ですが素敵なMission / Vision / Foundationなのでご覧いただけると嬉しいです。 speakerdeck.com speakerdeck.com 組織・ワークエンゲージメント 組織体制（組織）やワークエンゲージメントは上の3つのケイパビリティを支える土台として位置づけます。仮に上の3つのケイパビリティを高いレベルで実現できるスキルや経験を有していたとしても、ネガティブな雰囲気で溢れ疲弊した組織では、もてる力を十分に発揮することはできません。 プロダクト開発に直接関わるケイパビリティだけでなく、組織に関する指標やワークエンゲージメントの可視化と改善も目指しています。 組織における実際の運用 4つのケイパビリティ分野における理想像（未来づくり）を起点として、可視化と対話の流れを作るために、組織が日々運用しているOKRと結びつけることをまず目指しました。 開発組織として達成したい目標（Objective）がどのケイパビリティ領域に紐づいているのかを明確にすることで、以下のつながりを意識しやすくなります。 いま自分たちは組織として何を伸ばそうとしているのか / どんな課題があるのか その施策をやる理由は何なのか KPIが示す変化はどの能力の成長を意味しているのか 事業目標とOKR（施策含む）、ケイパビリティ領域のマッピングは、以下の画像のようなイメージになります。 このように事業目標、OKR、ケイパビリティを重ね合わせることで、それらが一本の線でつながり、チームの前進をより的確に捉えられるようになります。 実際にやってみてどうだったのか 実際に運用を始めてみると、上記以外のメリットや取り組みの難しさもでてきました。ここでは簡単にご紹介できるものに限りますが、いくつか共有させてください。 施策の偏りに気づける 大規模なプロダクトを日々運用する上で、システムのパフォーマンス改善や利用パッケージのアップデートなど、今あるシステムを維持するだけでもやるべきことは山積みです。EC作成サービスBASEの運用においても同様で、「サービス価値の維持」分野の施策が多くなりがちでした。一方で、そこばかりに力を割いてしまうと、Four Keys計測の取り組みが後回しになるなどの弊害が生じます。 そのため、OKR施策を検討する際には、まず1年間の最重要領域を決め、その領域に優先的に施策の枠を確保し、残りを他の領域に割り当てるようにしています。 ちなみにFY2025では「素早い価値提供」分野を最重要領域と定めて取り組みを進めてきました。詳細については、12月8日のアドベントカレンダーでEMの @takashima から共有させて頂く予定です。 「新しい価値の実現」分野は難しい 「新しい価値の実現」分野は、定義にある通り「まだ実現できていない価値（機能や体験）をテクノロジーの力で実現すること」を目指すことになります。この分野は、普段の開発とは異なる技術スタックやそれらを使ったUI/UXの検証など、開発研究・R&Dの要素を含みます。成果が不確実な試行錯誤が必要であり、難易度も高いため、どうしても後回しになってしまっているのが現状です。 とはいえ、AI活用をはじめ、やるべきことはたくさんあります。プロダクト開発組織として引き続き取り組んでいきたいテーマです。 おわりに プロダクト開発組織のケイパビリティ可視化の取り組みについて紹介しました。4 つのケイパビリティ領域を定義し、それらを OKR と結びつけることで、組織として何を伸ばそうとしているのか、施策の意図や成果がどの能力に紐づくのかをより明確に捉えられるようになったのではないかと感じています。開発組織の目標管理や成長を考えるための新しい「補助線」として、読者の方の参考になれば幸いです。 まだ道半ばではありますが、これからも組織の未来づくりと可視化、そして対話のサイクルを重ねながら、プロダクトと開発組織の継続的な成長を目指していきたいと考えています。 BASEでは、今後のプロダクト成長を支える技術戦略や開発基盤の構築をリードしていただけるテックリード候補を募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。 open.talentio.com 明日のBASEアドベントカレンダーは @rerenoteさんからの記事です。お楽しみに！

はじめに この記事は🎄🎅 BASE PRODUCT TEAM BLOG Advent Calendar 2025 🎅🎄の3日目の記事です。 devblog.thebase.in こんにちは！ BASE 株式会社 Pay ID 兼 BASE PRODUCT TEAM BLOG 編集局メンバー の @zan_sakurai です。 私の所属する Pay ID では一部のアプリケーションでGoを採用しており、日々Goらしいコードを書くことを意識して開発を行っています。 読者のみなさまは「Goらしさ」という言葉を聞いたことがある、もしくは使ったことはありますか...？ 私も日々の開発シーンで聞いたことも使ったこともありますが、実際に「Goらしさとは何か？」と問われると、私も正直言葉に詰まってしまいます...。 とはいえ「Goらしさ」とは曖昧なままではあるのもよろしくないので、 本記事では一旦「Goらしさ」/「Goらしいコード」とは、Goの言語仕様だけでなく、Goの設計思想や慣習に沿ったコードを指すこととして、 Go の特徴の一つである interface を題材に、今回は「Goらしい」 interface の書き方について掘り下げてみたいと思います。 「Goらしい」 interface を書く Go の interface の特徴は多岐にわたりますが、 今回は Go Wiki: Go Code Review Comments#Interfaces に記載されている内容を掘り下げていこうと思います。 具体的なコード例はGo Code Review Commentsがとても良くまとまっているので、そちらもぜひ御覧ください。 ステップ1: interface が本当に必要になるまで書かないのが「Goらしい」 Go Wiki: Go Code Review Comments の Interfaces の章には以下のように記されています。 Do not define interfaces before they are used: without a realistic example of usage, it is too difficult to see whether an interface is even necessary, let alone what methods it ought to contain. 引用元: Go Wiki: Go Code Review Comments#Interfaces 端的にまとめてしまうと必要性が出てきたらinterfaceを定義せよ、という旨です。 私のようなJavaなどのOOP言語からGoに来た人は、最初に抽象型を定義してから具体的な実装を作る傾向があるかもしれませんが、 Goでは具体的な実装を行ってから必要性が出てきた時に初めてinterfaceを定義するのが「Goらしい」書き方のようです。 過度な抽象化による複雑化、いわゆる「インターフェース汚染」などと巷では呼ばれていますが、このようなことを避けるために、interfaceを書くタイミングに慎重になることが推奨されているようです。 Go Code Review Comments の例を参考に、ステップ1を踏まえたコードを書いてみました。 package consumer import "interfaceidioms/step1/producer" // 何らかの処理を行う構造体 // producerパッケージのThingerを内部に持つ type ThingerConsumer struct { t producer.Thinger } // 何らかの処理を行うメソッド func (tc ThingerConsumer) DoSomething(input producer.Input) bool { return tc.t.Thing(input) } // いわゆるファクトリ関数 // consumer.NewThingerConsumer(producer.NewThinger()) のような使われ方が想定される. func NewThingerConsumer(t producer.Thinger) ThingerConsumer { return ThingerConsumer{t: t} } package producer // 何らかの入力データを表す構造体 type Input struct { Content string } // 何らかの処理を行う構造体 type Thinger struct { // snip... } // 何らかの処理を行うメソッド func (t Thinger) Thing(input Input) bool { return input.Content == "" } // いわゆるファクトリ関数 func NewThinger() Thinger { return Thinger{} } 特に何の変哲もない?コードですが、ステップ1を踏まえたコードになっています。 「Goらしい」interfaceを書く上での最初のステップは、 本当にinterfaceが必要になるまで書かないこと です。 ステップ2: 消費する側に interface を定義すると 「Goらしい」 ステップ1で 本当にinterfaceが必要になるまで書かないこと を述べましたが、実際にinterfaceを書く必要性が出てきた場合、どう書くと「Goらしい」のでしょうか？ またまた Go Wiki: Go Code Review Comments の Interfaces の章からの引用ですが、以下のように記されています。 Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values. The implementing package should return concrete (usually pointer or struct) types: that way, new methods can be added to implementations without requiring extensive refactoring. 引用元: Go Wiki: Go Code Review Comments#Interfaces これも端的にまとめてしまうと、interfaceは実装を提供する側ではなく、消費する側のpackageに定義すべき、という旨が記載されています。 この点も私のようなJavaなどのOOP言語からGoに来た人は、実装を提供する側でinterfaceを宣言したくなるかもしれませんが、 Goでは消費する側でinterfaceを定義するのが「Goらしい」書き方のようです。 Go では明示的にimplementsを宣言せず、Duck Typing的に暗黙的にinterfaceを満たすので、 ステップ1で直接呼びだしている箇所も後からinterfaceに置き換えるリファクタリングは容易です。 また、消費する側が使うメソッドだけをinterfaceに含めば良いので、小さなinterfaceを定義できます。(いわゆるインターフェース分離の原則。) 小さなinterfaceですので、テスト時に必要な振る舞いだけを持つinterfaceを満たすモック実装を用意するのも容易です。 Go Code Review Comments の例を参考に、ステップ2を踏まえたコードを書いてみました。 package step2goodconsumer import "interfaceidioms/step1/producer" // step1で使ったproducerパッケージの変更はなく、そのままstep2goodconsumer側でinterfaceを定義できる. // Thinger interface を定義 // これがいわゆる消費者側のinterface. type Thinger interface { Thing(input producer.Input) bool } // 何らかの処理を行う構造体 // producerパッケージのThingerを内部に持つ type ThingerConsumer struct { // interface型を使うように変更 t Thinger } // 何らかの処理を行うメソッド func (tc ThingerConsumer) DoSomething(input producer.Input) bool { return tc.t.Thing(input) } // いわゆるファクトリ関数 // DIなりでよしなに入れ替えよう. func NewThingerConsumer(t producer.Thinger) ThingerConsumer { return ThingerConsumer{t: t} } 実際のstep1との差分も少なく、step2goodconsumer側の判断でproducerの変更なく、容易に interface を使った書き方にリファクタリングできることがわかります。 $ diff -u --label "step1/consumer.go" --label "step2/consumer.go" \\ step1/consumer/consumer.go step2goodconsumer/consumer.go --- step1/consumer.go +++ step2/consumer.go @@ -1,11 +1,18 @@ -package consumer +package step2goodconsumer -import "interfaceidioms/step1/producer" +import "interfaceidioms/step1/producer" // step1で使ったproducerパッケージの変更はなく、そのままstep2goodconsumer側でinterfaceを定義できる. + +// Thinger interface を定義 +// これがいわゆる消費者側のinterface. +type Thinger interface { + Thing(input producer.Input) bool +} // 何らかの処理を行う構造体 // producerパッケージのThingerを内部に持つ type ThingerConsumer struct { - t producer.Thinger + // interface型を使うように変更 + t Thinger } // 何らかの処理を行うメソッド @@ -14,7 +21,7 @@ } // いわゆるファクトリ関数 -// consumer.NewThingerConsumer(producer.NewThinger()) のような使われ方が想定される. +// DIなりでよしなに入れ替えよう. func NewThingerConsumer(t producer.Thinger) ThingerConsumer { return ThingerConsumer{t: t} } 「Goらしい」interfaceを書く上での次のステップは、 消費する側に interface を定義する です。 番外編: Accept interfaces, return structs / Accept Interfaces, Return Concrete Types Accept interfaces, return structs という言葉を聞いたことはありますか？ いわゆる interfaceを受け入れ、具体的な型を返す、というidiomです。 この際に改めて原典を探ってみましたが、詳しく言及しているようなものはあまりないように見受けられました。 もし原典をご存知の方がいらっしゃいましたら、ぜひ教えてください。(以下触れている箇所) https://go-proverbs.github.io/ https://github.com/go-proverbs/go-proverbs.github.io/issues/37 https://github.com/google/styleguide/blob/gh-pages/go/decisions.md ステップ1とステップ2を踏まえた上で、ですとproducer側でinterfaceを定義するケースはまだないので、自ずと Accept interfaces, return structs になるのかと思います。 余談 今回はあえて、producer側で定義するinterfaceについては触れませんでした。 実際に https://github.com/golang/go で標準ライブラリのコードを見てみると、producer側でinterfaceを提供しているケースも多々あります。 続編を書こうと思いますので、ご期待いただけますと幸いです。 さいごに 最後に改めて「Goらしい」 interface を書くステップをまとめます。 本当にinterfaceが必要になるまで書かないこと 消費する側に interface を定義する 読者のみなさまが「Goらしさ」に触れるきっかけの一助になれば幸いです。 参考資料 Go Wiki: Go Code Review Comments Effective Go https://go-proverbs.github.io/ https://github.com/go-proverbs/go-proverbs.github.io/issues/37 https://github.com/google/styleguide/blob/gh-pages/go/decisions.md 宣伝 Pay ID ではエンジニアを募集中です！ご興味があれば採用情報もぜひご覧ください！ open.talentio.com 明日は、BASEアドベントカレンダーは @tanden さんの記事です。お楽しみに！

はじめに この記事はBASEアドベントカレンダーの2日目の記事です。 devblog.thebase.in こんにちは、 BASE Feature Dev1 Group で PHPer をしている @meihei です。今日は Gopher です。 この記事では、外部サービスの Webhook を AWS Lambda (Function URLs) で受け取り、SQS にいれる設計と実装、そして、それら全体が正常に稼働しているかを監視するやり方について書きます。 1. 前提とアーキテクチャ 前提として BASE が連携する外部サービスでイベントが発生した際、その通知を Webhook 経由で受け取り、必要なユースケースを後続ワーカーが実行できるようにつなぐ仕組みを設計します。 技術要件 外部サービスの中には EventBridge の Partner Event Source を利用して直接イベントを受信できるものもあります。しかし、今回の対象サービスは EventBridge 連携に対応していないため Webhook を利用しています。Webhook の正当性については、署名ベースの検証によって確認しています。 また、Webhook を受信するエンドポイントは BASE の PHP アプリケーションサーバーでは処理せず、サーバーレス環境（Lambda）で受信する方針としています。後続のワーカーは、既存のコンテナ基盤上で稼働する PHP プロセスによって実行されます。 ビジネス要件 今回は、BASE から外部サービスへ API 経由で商品連携を行った後に、商品審査ステータスの変更が発生し、その審査ステータスを受け取って BASE 側の連携ステータスを更新するユースケースについて解説します。 ここで求められるビジネス要件は以下のとおりです。 許容遅延 ：リアルタイム性は必須ではありませんが、できる限り早く反映されることが望ましい。 処理漏れへの対応 ：処理漏れは設計上許容せず、万が一発生した場合は必ず SQS Dead Letter Queue （以下、DLQ）に退避させ、後続の運用フローで確実に回収できるように。 二重通知への対応 ：外部サービスから同一イベントが複数回送られたとしても、後続ワーカー側で冪等性を担保し、重複処理を許容。 通知順序のズレ ：順序入れ替わりは発生するものとして扱い、最終的に正しい状態へ同期されていれば問題なし。 これらの要件から最終的に以下のような構成になりました。 SQS は Standard Queue を使用し、外部サービスのシークレットキーなどは AWS Systems Manager のパラメータストアを利用しています。 2. インフラ（Terraform＋lambroll） 本構成で必要となるAWSリソースは以下の通りです。 *1 IAM: Lambda 実行用の Role と Policy Lambda: Webhook を受信する Lambda Function（Function URLs） SQS: イベントを後続ワーカーへ受け渡すための Main Queue と Dead Letter Queue Systems Manager & KMS: 外部サービスのシークレットキーを保管するためのParameter Store と KMS Key BASE ではインフラ構築に Terraform を、Lambda のデプロイには lambroll を利用しています。これらは別々のリポジトリで管理されていて、アプリケーションエンジニアでも安全かつ容易に AWS リソースを管理でき、Lambda のコードは継続的デリバリーが可能な体制になっています。 Terraform 編 Terraform は一般的な AWS 構築を行いますが、Lambda だけは異なります。 aws_lambda_function のリソースは Lambda を作成する時と、削除する時だけに使用し、最初にダミーファイルをデプロイします。その後は source_code_hash や runtime , environment などの情報に差分を検出しても変更を適用しないように設定しています。これらは lambroll 側で行います。 また、 BASE では Terraform をモジュール化して管理しており、インフラエンジニアや SRE でなくても、必要なパラメータを入力すれば標準的な AWS リソースを安全に作成できるようになっています。 例えばこんな感じです。 // lambda.tf module "lambda_hogehoge_integration_webhooks" { source = "../modules/lambda" function_name = "hogehoge-integration-webhooks" ... } // sqs.tf module "hogehoge_integration_webhooks" { source = "../modules/sqs_dead_letter" name_sqs = "hogehoge-integration-webhooks" dead_letter_queue_arn = module.hogehoge_integration_webhooks_dead.sqs_arn ... } module "hogehoge_integration_webhooks_dead" { source = "../modules/sqs" name_sqs = "hogehoge-integration-webhooks-dead" ... } module からアタッチするポリシーも設定出来るので、送信先 SQS への sqs:SendMessage 、シークレットを格納している SSM Parameter Store への ssm:GetParameter 、そして Parameter Store 経由で Secrets Manager のシークレットを参照するための kms:Decrypt だけをアタッチして、最小権限になるようにします。 また、Lambda Function URL の設定は lambroll 側ではなく Terraform 側で定義しました。 lambroll 編 lambroll は、AWS Lambda に特化したシンプルなデプロイツールです。Terraform でインフラ（関数そのものや IAM ロール、Function URL など）を作成しつつ、アプリケーションコードのビルドとデプロイは lambroll に任せることで、役割を分離しています。 github.com まず、Terraform で作成した既存の Lambda 関数を、Lambda 専用リポジトリ側から管理できるように初期化します。 lambroll init --function-name hogehoge-integration-webhooks --download このコマンドにより、対象の関数設定を取得し、 lambroll 用の設定ファイル（ function.json ）が手元に生成されます。 { " Architectures ": [ " arm64 " ] , " Environment ": { " Variables ": { " APP_KEY ": " {{ must_env `APP_KEY` }} ", " APP_SECRET_NAME ": " {{ must_env `APP_SECRET_NAME` }} " } } , " Handler ": " bootstrap ", " Runtime ": " provided.al2023 ", ... } function.json では Terraform で ignore の設定をしている環境変数やランタイムを指定します。 コードを書き換えた後の Go のビルドとデプロイは次のように実行します。 go build -v -o ../build/bootstrap lambroll deploy --src="build" この一連のフローは GitHub Actions 上から自動でビルドとデプロイが走るようになっています。 3. 実装（Go） Lambda のコードは Go 言語で実装しています。後続ワーカーはドメインロジックを担うため BASE のアプリケーションと同じ PHP を採用していますが、Lambda 側ではビジネスロジックを持たないため採用言語に強い制約はありません。 今回は外部サービスの公式ドキュメントが Go のサンプルを提供していたこと、社内で Go の利用実績があることから、Lambda は Go で実装する方針としました。 次のようなディレクトリ構成で進めています。 hogehoge-integration-webhooks/ build/ bootstrap src/ go.mod go.sum main.go Makefile function.json .env まず、 init 関数では Lambda 起動時に一度だけ実行される初期化処理として、SQS クライアントの生成とシークレットの取得を行います。ここで作成したクライアントやシークレットはグローバル変数として保持し、各リクエスト処理で再生成しないようにしています。 func init() { ... // SQSクライアントを作成 sqsClient = sqs.NewFromConfig(cfg) // SSM Parameter Store から APP_SECRET を取得 ssmClient := ssm.NewFromConfig(cfg) withDecryptionc := true param, err := ssmClient.GetParameter(context.TODO(), &ssm.GetParameterInput{ Name: &appSecretName, WithDecryption: &withDecryptionc, }) appSecret = *param.Parameter.Value ... } main 関数では lambda.Start(handler) を呼び出し、実際のリクエスト処理は handler 関数に集約しています。 handler では署名の検証と SQS へのメッセージ送信だけを担当させ、ビジネスロジックは持たないようにしています。署名検証に失敗した場合は 404 を返すことで、認証まわりの情報を外部に漏らさないようにしています。 func handler(ctx context.Context, request events.LambdaFunctionURLRequest) (events.LambdaFunctionURLResponse, error ) { // 事前検証 ... // 署名を検証 if !verifyWebhookSignature(request.Body, authHeader, appKey, appSecret) { return events.LambdaFunctionURLResponse{ StatusCode: 404 , }, nil } // リクエストBodyをそのままSQSに送信 _, err := sqsClient.SendMessage(ctx, &sqs.SendMessageInput{ QueueUrl: &sqsQueueURL, MessageBody: &request.Body, }) if err != nil { log.Printf( "Failed to send message to SQS: %v" , err) return events.LambdaFunctionURLResponse{ StatusCode: 500 , }, err } // 成功の場合空で返す return events.LambdaFunctionURLResponse{ StatusCode: 200 , }, nil } 今回の Lambda は「受け取った Webhook を検証し、そのまま SQS に流す」ことだけに専念しており、後続のワーカーがビジネスロジックを実行する前提のため、リクエスト Body をそのまま SQS に送信するシンプルな実装としています。 もしビジネス要件の異なる複数種類の Webhook を単一のエンドポイントで受け取る必要がある場合は、この handler 内でイベント種別（リクエスト Body 内の値）などに応じて送信先のキューを振り分ける構成にすると、FIFO Queue が使用可能後になったり、後続のワーカーを用途ごとに分離しやすくなります。 4. 監視・運用 前提として BASE では New Relic でも AWS サービスのインフラの観測を行っています。 New Relic では以下の様なダッシュボードを用意し、ひと目でサービスの状態が把握出来るようになっており、万が一異常が起きてもアラートを設定していて slack へ通知されるようにしています。 ダッシュボード編 この連携の状態を把握するための「入り口」として New Relic のダッシュボードを用意しています。ダッシュボードを開けば、構成・ステータス・関連リソースへの導線がひと目で分かるようにすることを意識しています。 まず、ダッシュボードの一番上には全体構成が分かる図を配置します。New Relic では Mermaid 記法でダッシュボード内に図を記述できるため、 Lambda Function URL → Lambda → SQS → ワーカー というイベントの流れを示した簡単な構成図を載せています。 参考: Mermaid記法でダッシュボードにアーキテクチャ図など視覚的な表現が可能に！ #AWS - Qiita 次に、この連携に関わる周辺情報へのリンクをまとめた Markdown テキストを置きます。具体的には、対象 Lambda 関数や SQS キューの AWS コンソールへのリンク、関連する GitHub リポジトリ、ドキュメントなどを並べておき、運用時にここからすぐに辿れるようにしています。 その下には、主要なメトリクスをサービスの流れに沿って並べます。入口となる Lambda については Invocations 、 Duration 、 Errors 、 Throttles を New Relic 経由で可視化し、エラーやスロットルの有無をすぐ確認できるようにしています。SQS については、 SentMessages ／ ReceivedMessages ／ DeletedMessages といったトラフィックの傾向に加えて、 ApproximateAgeOfOldestMessage 、 ApproximateNumberOfMessagesNotVisible 、 ApproximateNumberOfMessagesVisible を配置し、キュー滞留や詰まり具合を一目で判断できるようにしています。 （LatencyのSLOはうまく計測出来ておらず、0となってしまっている…） これらを「入口 → キュー → 下流ワーカー」の順番で並べることで、どのレイヤーで異常が起きているかを直感的に追えるダッシュボード構成としています。 アラート設定と運用 New Relic アラートでは、各レイヤーで重要なメトリクスを監視対象として、異常を最速で検知し、slack へ送るようにしています。 Lambda では Errors と Throttles を監視し、失敗が発生した場合は Slack へ即時通知されるようにしています。Lambda の失敗時は、外部サービス側の Webhook リトライが発生しているかの確認を行います。 SQS 側では ApproximateAgeOfOldestMessage と ApproximateNumberOfMessagesVisible をアラート条件に設定し、キューの滞留や処理遅延が発生した場合に通知します。これにより、下流ワーカーの負荷増大を早期に把握できます。 さらに、DLQ にメッセージが入った場合は、件数が１件以上であることをトリガーとして Slack に通知しています。 5. まとめ 今回の構成は、Webhook を受け取り、後続ワーカーへ処理を引き渡すことを目的としたシンプルなアーキテクチャでした。入口となる Lambda Function URL は軽量で扱いやすく、ビジネスロジックを後続ワーカー側へ集約したことで責務が明確になり、機能追加や修正にも柔軟に対応できる構造になっています。 今回の事例が、今後の設計や運用を進める際の参考になれば幸いです！ BASE ではアプリケーションエンジニアが設計からインフラ・監視まで幅広く活躍することが出来ます。興味があれば採用情報もぜひご覧ください！ binc.jp 明日は、BASEアドベントカレンダーは @zan_sakurai さんの記事です。お楽しみに！ *1 : Cloudwatch Logsもありますが、ここでは省略して書いています。

この記事は BASEアドベントカレンダー の一日目の記事です。 こんにちは！BASE株式会社で開発担当の役員をしている、えふしんです。 僕も今、BASEグループ全体を視野に「AIを経営資源としてどうアップグレードするか」を日々考えています。 2025年の締めくくりにふさわしく、 今日は“生成AIの憂鬱”について書いてみたいと思います。 AIツールが乱立する時代に、企業は何を選び、どこから撤退するべきか 2024年から2025年にかけて、企業のIT環境は一気に騒がしくなりました。 Slack に AI がつき、Notion に AI がつき、 Google に Gemini が載り、 Microsoft は Copilot を標準にし、 そして OpenAI は ChatGPT Enterprise を大々的に展開し始めています。 どのサービスも「今度こそ、これ一つで生産性が劇的に上がります」と主張する。しかし、企業の中に身を置いていると、そんなに単純な話ではないわけです。 Enterprise SaaSは、Enterpriseプランなどの高額なプランにAI拡張機能を載せています。これは数年後のAIプロダクトの風景では多分ありえない光景で、「あたりまえのAI時代」の前段階が故に高付加価値機能として置かれていると考えます。 もちろん、これはAI発展のストーリーの１ページで、OSSだって最初からOSSが生まれてくるのではない。プロプライエタリな製品を大企業がお金を払って普及させてくるからこそ、クローンとしてOSS化して多くの人が使えるようになり世界が拡がるというのは、ここ数十年のITの歴史ではないでしょうか。Linuxを使うユーザーが、インストールされている素敵なライブラリ一つ一つに適切なアウトカムを認識して使っているなんてことはないわけです。 だからと言って、この流れを無視して、ある意味フリーライドできる時が来るまで待つのも違うと思ってしまうわけです。これぞAIバブル。 この流れをどう乗りこなしていくか。未来と現状のギャップ。発展途上の過渡期だからこそ、“生成AIの憂鬱”が広がっています。 AIの導入はワクワクより「疲労」のほうが先に来る Slack AI を買うべきか？ Notion AI の方が効果が高いのか？ Copilot や Gemini はどうする？ ChatGPT Enterprise を入れるべきか？ 気づけば、どのSaaSも「AI検索できます」「自然言語で仕事ができます」と言い始め、企業はコア実装である生成AIが類似なものであろう複数のAI機能に同時に課金するような状況に追い込まれている。 こうした“AI疲れ”は、技術的な問題というより、意思決定する側の負担が大きすぎるところに原因がある。導入判断だけでなく、撤退判断がもっと難しい。 導入時には派手に謳われた生成AI機能も、いざ組織に入ってしまうと、多少期待外れだったとしても「使い慣れたツールをやめたくない」という声が必ず出る。生成AIが汎用的が故に、特定のユースケースが恩恵を受けてしまったところから、引き剥がすのは難しい。 その結果、企業の中には“サンセットできないツール”が静かに積み上がっていく。 意思決定者は、ここまで予測し、ある意味非情とも言える決断を覚悟しないと入れられません。それ故に撤退基準の仕組み化が必要という考え方もありますね。 なぜAIツールがこんなに乱立してしまうのか 理由は単純で、各サービスが「社内で最初に質問される場所」を狙っているからだと考えます。 Slack は会話の中心にいる。 Notion はナレッジの中心にいる。 Google はドキュメントの中心、Microsoft はメールと会議の中心。 そして OpenAI は「生成AIそのものの中心」にいる。 それぞれが「うちをAIの入口にしてほしい」と主張し、結果として企業側は、複数の“AIフロントエンド”と向き合わざるを得なくなる。 いずれ企業毎の重要な情報が集まっているコアとなるAIが中心となり、周辺のフロントエンドにさまざまなツールが存在する構造になるかもしれないが、今はまだ早い。 AI導入の本質は、生産性やコスト削減だけではない よくAI導入のメリットは「業務効率化」「コスト削減」と語られる。 もちろんそれも重要だが、2025年現在の企業にとって、もっと重要な価値がある。 それは 新人のレバレッジではないでしょうか。 生成AIを使うと、まだ経験が浅いメンバーでも、会話ログからプロジェクトの背景を掴んだり、文章の下書きを素早く用意したり、技術的な不明点を自分で解消したりできる。 結果として、組織は「人を増やさずに回る領域」を増やせる。 （人員削減という言葉は使わないが、チームが肥大化しないという“健全さ”を保つためにAIは効く） この“レバレッジ”は、AI導入における一番の価値だと思っています。 ソーシャルではシニアの方が恩恵を受けて、新人が採用されなくなったり入り込む余地がなくなるんじゃないかと言われているが、僕は必ずしもそうだとは思っていません。 「生成AIの憂鬱」を超えるために、企業がすべきこと AIツールは導入しただけでは価値になりません。組織文化と技術構造が噛み合って初めて成果につながります。 導入でも撤退でも重要なのは、「どのレイヤーでどのAIが本当に必要か」 を冷静に見極めること。 Slackでのキャッチアップには Slack AI が向いている。 会社ナレッジには Notion AI が向いている。 横断的な調査や下読みには ChatGPT Enterprise という選択肢もあるが、何をどこまで統合するかは組織の成熟度次第。 AIの時代は、ツールが増えること自体よりも、“どれを選び、どれを手放すか”の判断 が企業を悩ませる。 引き続き悩み続けます。皆さんのご意見もお聞きしてみたいです。 おわりに 生成AIによって、働き方も役割もこれから大きく変わっていきます。AIのセンスと自分の専門性を掛け合わせて、新しい価値をつくれる時代です。 BASEグループでも、そんな環境に一緒に取り組んでくれる仲間を探しています。もし興味があれば、採用情報もぜひ覗いてみてください。 binc.jp

こんにちは！BASE PRODUCT TEAM BLOG 編集部です。 そろそろ年の瀬ですが、みなさまいかがお過ごしでしょうか。 今年も恒例のBASEメンバーによるアドベントカレンダーを開催します！ 毎年公開しているアドベントカレンダーも今年で8回目を迎えます。 過去の様子 2024年のアドベントカレンダー 2023年のアドベントカレンダー 2022年のアドベントカレンダー 2021年のアドベントカレンダー 2020年のアドベントカレンダー 2019年のアドベントカレンダー 2018年のアドベントカレンダー 今年も1日1記事に限定せずたくさんのバラエティ豊かな記事を公開する予定です。 公開され次第以下のカレンダーも随時更新していきますので、ぜひお楽しみに！ 日付 執筆者 タイトル 2025年12月1日 @Shinichi Fujikawa 生成AIの憂鬱 2025年12月2日 @ema Webhook を AWS Lambda で受け取り SQS へ流す 〜設計から監視まで〜 2025年12月3日 @zan “goらしさ”について考えてみる #1 interface編 “Accept interfaces, return structs” を添えて。 2025年12月4日 @tanden プロダクト開発組織でのケイパビリティ可視化に向けた取り組み 2025年12月5日 @rerenote 登壇もコミュニティも応援したい！技術イベント協賛まとめ 2025年12月6日 @yaakaito Cloudflare でショップをちょっとだけ速くしてみた - 導入/SSL for SaaS 編 2025年12月7日 @yaakaito Cloudflare でショップをちょっとだけ速くしてみた - キャッシュ/Workers 編 2025年12月8日 @takashima 開発量向上の話 2025年12月9日 @okinaka LocalStack の EventBridge Scheduler にある制約とその対処法 2025年12月10日 @FujiiMichiro 「テキストレビューAI」導入による、ブランドデザインの最適化 2025年12月11日 @komaki 文字を読むのが苦手な自分との付き合い方 2025年12月12日 @ykagano 何か書く 2025年12月13日 @UenoKazuki AI での業務改善についてなにか書きたい 2025年12月14日 @02 最速振込にてmysql instant algorithmを使って無停止でテーブルにカラム追加した話をします 2025年12月15日 @Capi ツール導入を行う際に気をつけたいことを紹介します 2025年12月16日 @NojimaTomoya なんかかく 2025年12月17日 @izuhara 業務自動化でBASEを支えるCSEチームの変遷 2025年12月18日 @ImazekiShota 分析基盤におけるSQL自動生成の話 2025年12月19日 @OtsukaHiroki New RelicのダッシュボードをTerraformで出す話 2025年12月20日 @Satoshi Ohki OpenFeature OR Uber fx 2025年12月21日 @OgasawaraYuki BASEにおけるサービスレベルマネジメントのこれまでとこれから 2025年12月22日 @matzz(Yusuke Matsubara) 【2025年版】モニタ・キーボード・マウスの3種の神器のトレンドを考える or 社会人のための現代栄養素の基礎知識 →個人blog 2025年12月23日 @yaakaito 未定！！！！！！！！！！１ 2025年12月24日 @UedaHayato エンジニア組織の組織設計どうしてる？〜BASE事業開発チームの組織変遷〜 2025年12月25日 @mkawaguchi 未定です！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

はじめに CTOの川口 ( id:dmnlk ) です。 先日AWS Japan様にご協力いただきBASE社内で Amazon Bedrock AgentCore を利用したワークショップを開催したのでそのリポートです。 AWS Japan様と日々お話をさせていただく中で社内でのAgent開発を行うにあたり、そもそもAgentとはどういうもので何ができて何を利用できるかといった体系的な知識をまだ持ち合わせいないことを課題感として話しており せっかくなので Amazon Bedrock AgentCoreを使ったワークショップを開催しAgent開発に触れてもらうことができるのではないかと打診をいただき開催したものとなります。 Amazon Bedrock AgentCoreワークショップ このワークショップには全事業部から参加メンバーを募りました。 現状の業務で触れる機会のないメンバーにも新しい技術などに触れてもらう良い機会だと思ったため現在の業務内容に関わらず広く募りました。 その結果30名程度のメンバーが参加してくれました。 奇しくも Amazon Bedrock AgentCoreが開催日の一週間前にGA したこともあり触れやすかったのではないかと思います。 弊社オフィスにAWS Japanの方たちをお招きし、前半は座学でAgentとはなにかやAgentCoreがどのようなものかを講義いただき、途中から用意していただいたハンズオン環境でAgentCoreを利用したAgent開発を行いました。 特に準備は不要で各メンバーがそれぞれ使える環境が用意されていたので特に環境構築で詰まることなくワークショップに取り組めたのは良い体験でした。 ワークショップ自体は 下記リポジトリを基本とした形のようで後に見返すこともしやすいのは助かりました。 github.com 個人的に事前にAgentCoreは触れていたので、自分もサポートに回りつつ改めてAgentCoreを触るいい機会となりました。 Agent開発において動作させる環境や記憶装置などは必要だが開発するアプリケーションとは別に考えることが多く面倒が多いですが AgentCoreを利用することでそれらの苦労が減るというのは開発体験として心地の良いものです。 本番ワークロードではo11yなども重要になっていきますがそれらもケアされていることは安心に繋がります。 予算管理という側面ではAgentCoreの課金体系である 「CPU リソースについては、エージェントがアクティブに処理しているときに課金されます (LLM 応答を待機しているときの I/O 待機期間への課金はありません)」 というところはお気に入りな部分です。 実際にワークショップに参加したメンバーは普段はPythonを書いたりしないので不慣れな部分もあったようですが、皆基本的に問題なく進められたようで Agent開発の基本は抑えられて手札が増えたのではないでしょうか。 おわりに 必要があるから技術を学ぶというのはもちろんですが、必要になる前から事前に手札を増やし素振りをしていくことは重要ですのでこのような機会を設けられたのはエンジニアの知的好奇心を満たしつつ プロダクトにAIやAgentをどのように組み込めるかといった新たな視点をもたらすのにいい機会だったと思います。 ご協力いただいたAWS Japanの皆様に感謝しています。 これからもこのような機会は積極的に活用し日々の開発を超えた新しいプロダクトへの技術導入ができるようにしていきたいと思っています。 BASE株式会社ではエンジニアを採用募集中ですのでご興味あればご応募お待ちしております。 binc.jp

はじめに 本文中とサムネイルの画像に登場するキャラクターは、 PHPカンファレンス福岡2025 の公式キャラクターです。 公式のガイドラインのもと、配布されている素材を利用させていただいています。 Product Development Division で PHPer をしている ema （ @meihei ）です。 2025年11月8日に開催された PHPカンファレンス福岡2025 に参加し、BASEのエンジニアも2人登壇しました。また、開催の後日に社内でPHPカンファレンス福岡2025のふりかえり会を行いました。 この記事では登壇スライドの紹介と、そのふりかえり会の様子をお届けします！ 登壇者コメント かがの @ykagano 「決済システムの信頼性を支える技術と運用の実践」というテーマで登壇させていただきました！ speakerdeck.com 長年、決済システムを開発してきた経験から、特にクレジットカード決済における具体的な設計と運用のノウハウをお伝えさせていただきました。 なぜDB設計で非正規化が必要なのか 300 TPS 超の負荷テストとボトルネック対策 データの増加を見据えたバッチ設計 会場では発表内容について質問をいただいたり、知らない世界なので面白かったといった声をいただき、大変嬉しく思いました。 ご参加いただいた皆様、ありがとうございました！ meihei @app1e_s 「隙間ツール開発のすすめ」というテーマでLTをさせて頂きました。 speakerdeck.com 自分は普段から隙間を見つけてはツールを開発しているのですが、そのやり方やAI時代での開発の方法などを、自分の経験からまとめたスライドとなっています。 実例で挙げたように皆が必要なものは公式から提供されますが、まだ提供されていないものや自分だけが必要なものは、パパッと AI に書いてもらって作ると良いなって思っているので、そこのあなたも是非！ ふりかえり会 PHPカンファレンス福岡2025では良い発表が多かったので、それら知識が身になるように、ふりかえりによるグループ学習を行いました。 ふりかえりでは、よくあるフレームワークは使わずに輪読会で用いられるようなフォーマットを使いました（今回は retty さんの社内輪読会のやり方を参考にしています） engineer.retty.me やりかた ルール 適当に付箋を拾い、書いた人の話を聞きつつわいわい話す 近い内容の付箋だなと思ったら書いた人が自分で近くに寄せる 感想は青、気づき・学びは黄、疑問・深掘りは赤を使う 進め方 テーマの優先順位を決める 5分間付箋を貼る時間 1テーマ10〜20分話す 各発表のふりかえり FigJamで行い、計４つの発表について話しました。 予防に勝る防御なし（2025年版） - 堅牢なコードを導く様々な設計のヒント / 和田 卓人 さん BASEではどこでどう使われているか、他社の事例ではどうか、今後、自分たちのコードにどう活かしていけそうかを整理しながら話していました。 特に「SimpleとEasy」「ValidateとParse」については、「 Clojureと「Simple Made Easy」 」や「 Parse, don’t validate 」などの発表資料以外のところからも参考文献を持ってきて、白熱した議論となりました。 バグと向き合い、仕組みで防ぐ / __rina__ さん BASE社内のインシデント対応フローと見比べてどうか、エンジニアとQAの”変更”に対する意識の違いなどを話しました。 ポストモーテムは有志で行われているものの、インシデント対応チームで行っているわけでもなくフローにも組み込まれていないので、今後フローに組み込むように改善できないかなどの提案もありました。 AI 時代だからこそ抑えたい「価値のある」PHP ユニットテストを書く技術 / 河瀨 翔吾 さん ユニットテストの重要性を理解できたし、Before と After があって発表がわかりやすかったので「このパターンはどうなんだ？」などの具体的なところまで議論を行いました。 また、BASE内でのテストルールの確認や、コーディングルールの確認も行いました。 AI 時代だからこそ学ぶべき PHP の基礎 / めもり〜 さん 知識の幅を広げるためにどんなことができるかを振り返りつつ、今仕事でどんなことをやっているという話をしました。 テストやCIなどガードレールに関する話は、「予防に勝る防御なし（2025年版） - 堅牢なコードを導く様々な設計のヒント」や「AI 時代だからこそ抑えたい「価値のある」PHP ユニットテストを書く技術」でも同様の主張されているところがあり、発表を並べてふりかえり会を行ったからこそ、知識の結びつきが見えてきて学びがありました。 おわりに 今回で最後となるPHPカンファレンス福岡でしたが、感慨深くもとても楽しいカンファレンスでした。10年間、本当にお疲れさまでした！！ 開催の準備をしていただいたスタッフの方々、登壇してくださった皆様、カンファレンスに協賛してくれたスポンサーの皆様、そして、PHPカンファレンス福岡を盛り上げてくれたPHPerの皆様、ありがとうございました！ BASE ではカンファレンス登壇者が何名も在籍しています。興味があれば採用情報もぜひご覧ください！ binc.jp

はじめに こんにちは！BASE BANK Dept にいるフルサイクルエンジニアの02です。 今回はFull Cycle Developers Night #2 ～エンジニアはどこまでビジネスを知るべき？～というBASE株式会社(以下、BASE)、株式会社CARTA HOLDINGS(以下、CARTA)、MOSH株式会社(以下、MOSH)で共催したイベントについて、当日の様子をお届けします！ 開催したイベントについて base.connpass.com Full Cycle Developer(以下、フルサイクルエンジニア)とは、Netflixが2018年に提唱したエンジニアのあり方の一つです。フルサイクルエンジニアは、コードを書くだけでなく、設計から運用までソフトウェアプロダクトのライフサイクル全体に責任を持ちます。 Full Cycle Developers at Netflix — Operate What You Build devblog.thebase.in そんなフルサイクルエンジニアを主軸としたイベントが、Full Cycle Developers Nightです。今回は「エンジニアはどこまでビジネスを知るべき？」をテーマに、事業との向き合い方についてパネルディスカッションしました！ パネルディスカッションの様子 パネルディスカッションの前に、各パネラーから自社のビジネスモデルや組織形態について、スライドを用いて5分程度で解説してもらいました。 今回のテーマ「エンジニアはどこまでビジネスを知るべき？」では、ディスカッション中に各社のビジネスモデルや組織形態の話が出てくることが想定されました。そのため、事前に理解してもらった上でパネルディスカッションを始める流れにしました。 各パネリストとモデレーターの様子 パネルディスカッションでは、以下のようなテーマで話しました！ 「ビジネスサイド」具体的に誰を想像していますか？ どんな役割分担でどこまで意見をだしている？ どういった失敗から「ビジネスを知らねば」と思ったか？ フルサイクルエンジニアとして、企画をエンジニア発信で進めることはあるか？その場合、何を根拠に提案しているか？ コードを書く開発業務だけに集中したいエンジニアに、どうマインド変革を促せばよいか？ フルサイクルエンジニアの立場で、PdMにしてもらって嬉しかったこと・やりやすくなったことは何か？ 途中からは参加者からもXでテーマを募集し、盛り上がりを見せました！当日の盛り上がりは、Xのハッシュタグからもご覧いただけます！ #full_cycle_nightのタイムライン パネルディスカッション中の様子 おわりに Full Cycle Developers Night #3 も開催したいと思っています！フルサイクルエンジニアや事業との向き合い方に興味がある方は、ぜひFull Cycle Developers Night #3 でお会いしましょう！ BASE BANK Deptでは、事業をエンジニアリングするフルサイクルエンジニアを募集してます。 ご興味がある方は、ぜひ下記のURLから採用ページをご覧ください！ binc.jp

自己紹介 BASEでエンジニアインターンをしている吉川唯音です。趣味は音楽で、作曲や編曲をしています。この度10月9日をもって、インターンを無事に終えることになりました。約2ヶ月のBASEでのインターンを通して、感じたことや学んだことについて語っていこうと思います！ インターン入社の経緯 自分は普段から多様なクリエイターとの接点があり、周囲ではBASEを利用している方も多く、そのため以前からBASEという存在を知っていました。そうした背景もあり、サポーターズの1on1イベントに参加した際により強く興味を持ち、面談を経て応募に至りました。そして選考が進み、8月からインターンとして入社しました。初めてBASEを訪れた際には、大きなガラス張りのエレベーターとオフィスの開放感のある雰囲気に驚いたことを今でも覚えています。 BASEで実際にやったこと ショップ管理画面全体のデザインリニューアル開発 私はBASEで「ショップ管理画面全体のデザインリニューアル開発」にジョインし、フロントエンドの実装を担当しました。普段はReactを扱うことが多いのですが、BASEではVueを用いて開発を進めました。特に印象に残っているのは「デザインシステム」の考え方です。大規模なプロダクトであるからこそ、将来的な拡張性を意識し、一箇所の修正が全体に反映される仕組みや、新しい機能を追加しやすい設計が整えられていました。単なる見た目の調整ではなく、フロントエンドにおける本質的で重要な仕組みを体験できたと感じました。 ▲新管理画面 ▲旧管理画面 iOS 26 対策 2ヶ月目はiOS 26 対策にもジョインしました。iOS26のリリース前に、シミュレーターで検証や修正を進めました。プロダクトの規模が大きい分、前提知識や全体構造の理解が求められ、影響範囲を考慮しながらコードを書くことの難しさを強く実感しました。BASE独自に構築された仕組みや、フロントエンドの中枢にあたる部分に触れることは難しかったですが、実装していてとても面白いと感じました。 "プロダクト"とリリース体験 また、この経験を通じてAIエージェントに対する考え方も変わりました。AIは人間の意図や文脈を完全には理解できないからこそ、プロダクトの構造や本質を踏まえ、影響範囲を見据えた設計・実装を行うことがエンジニアにとって不可欠だと学びました。 インターン最終週には、自分が担当した実装箇所が無事にリリースされるのを見届けることができ、とても嬉しく感じました。実際にプロダクトとして動いている様子を見たときは、感動しました。長く続いていたプロジェクトに参加し、限られた期間の中でリリースの場面にも立ち会えたことは、本当に幸運であったと感じています。 インターンを通じて感じたこと 特に学びになったこと BASEでのインターンを通じて特に学びとなったのは、「 プロダクトに向き合う姿勢 」と「 実務としてのスクラム開発 」です。 入社してまず驚いたのは、プロダクトに対する考え方でした。「コードを記述する」ことにとどまらず、「なぜその機能を作るのか」「ユーザーはどのように利用するのか」といった背景までを深く考える文化があります。エンジニアだけでなく、デザイナーやPdMの方々と一緒に議論し、提案を交わしながらプロダクトを形にする。そこには「難しいことをシンプルにする」という思想が強く根付いており、これはプロダクト全体や日々の業務に反映されていると感じました。この経験を通して、エンジニアにはコードを書くことだけでなく、ドメインを理解し、本質的に価値のあるものを見極める視点が不可欠だと実感しました。 さらに、BASEのインターンで特に貴重だったのは、実際にエンジニアの方々と同じチームでスクラム開発に参加できたことです。レトロスペクティブやスプリントレビュー、デイリースクラムといったスクラムイベントに、開発メンバーの一員として加わりました。プロダクトのゴールに適切に向かえているか、チームの状況はどうかといった点について、日々活発に議論しながら開発を進める経験はとても刺激的でした。このように実務としてのスクラム開発を体験できたことは、他のインターンでは得られない、大きな学びとなりました。 こうした学びを自分なりにアウトプットし、自分が所属するコミュニティでの開発や自己開発にも取り入れるなど、より前向きにチャレンジできるようになりました。コミュニティ内部のインターンでは、フロントのデザインシステムによる共通化やレトロスペクティブのファシリテーション、開発するプロダクトに対して積極的に向き合っています！ BASEのすごいと思ったところ BASEに入社して最初に感じたことは、受け入れ体制がしっかり整っていることでした。入社前の面談では「今まで新卒を採用したことがなく、教育制度や受け入れ体制が十分ではない」と伝えられていましたが、実際には予想以上に丁寧に受け入れていただき、とても驚きました。インターン期間中はメンターとしてついていただいた先輩エンジニアに、開発業務から日々のサポートまで手厚くフォローしていただき、社会人経験の少ない私にとって非常に心強く感じました。 また、BASEの魅力を強く感じたのは「プロダクトに対する一貫した思想」と、充実した開発環境の両立です。ユーザー視点を大切にしながら「難しいことをシンプルにする」文化が根付いている一方で、Android実機をWebブラウザからリモート操作・管理できるツールがBASE内で用意されるなど、開発環境にはギークさもありました。こうした環境の中で、AIでは生み出せない価値やプロダクトへの愛着を肌で感じることができました。 インターンを考えている学生に向けて BASEでのインターンは、チームの一員として受け入れられ、実際の開発業務に携わることができます。そして他の企業では経験できない貴重な学びがあります。また、メンターランチでは費用補助があり、美味しいご飯を楽しみながら、インターン期間中に参加したPJ外の方と交流することができました。特にオムライスが美味しかったです。 さらに、BASEには1on1や全社集会、部活動といった制度が整っており、多くの社員の方々と関わる機会がありました。インターンとして参加する中で、さまざまな視点や刺激を得られる、とても恵まれた環境だったと感じています。 1on1では先輩エンジニアの方と技術的なお話をさせていただいただけでなく、人事・PdM・CSといった他職種の方々とも対話する機会をいただきました。将来のキャリアや就活についての相談から、BASEでの開発体制や技術に関する具体的なお話まで、幅広く学ぶことができました。 BASEで働くメンバーはとても親切で、多方面に優れていると感じました。だからこそ、エンジニアリングの実務だけでなく、カルチャー面でも多くの学びが得られるインターンだと強く感じました。ぜひBASEのインターンを通じて、その両方を体験していただきたいです！

はじめに BASEでソフトウェアエンジニアをしている Futoshi Endo（ @fendo181 ）といいます。 以前、同じチームの Kumar さんが以下のタイトルで記事を執筆されました。 「BASEでの開発体験を向上させるための取り組み」 devblog.thebase.in この記事では、生成AIの活用によって、メンバー全員がフロントエンドとバックエンドの両方を担当できるようになった、という挑戦について触れられていました。 今回のプロジェクトでは、メンバー全員がフロントエンドとバックエンドの両方を担当できるようにするということにチャレンジをしました。メンバーは以前から専門領域を広げたいという意欲を持っていましたが、学習コストやペアプログラミングにかかる時間的負担を考慮し、プロジェクトの進行を優先せざるを得ませんでした。 しかし今回、AIツールの活用によってこれが実現可能となりました。 自分はまさにこのプロジェクトのエンジニアメンバーの1人であり、AIツールの力を借りることで、バックエンドの領域から、フロントエンド開発に挑戦することができました。 この記事では、どのように生成AIを活用して学習・開発を進めたのか、具体的な体験をベースに紹介します。 AIを“頼れるエキスパート”として活用し、スキルを拡張する 今回のプロジェクトでは、主に React + TypeScript を用いた機能開発が中心でした。 プロジェクト初期は「フロントエンドもやってみたい」という気持ちはありつつも、ReactやTypeScriptの文法に不慣れな自分にとっては、 「何が分からないのかすら分からない」状態 で、不安の方が大きかったのを覚えています。 まず取り組んだのは、 Reactの公式ドキュメントのチュートリアル をベースにした写経です。 基本的な構文やライフサイクル、Hookの使い方などを手を動かしながら覚えていきました。 しかし、それだけでは実務のコードはなかなか読めるようにはなりません。 PRレビューにおいても、変更内容の意図が掴めずに苦労していたのが実情です。 そこで活用したのが、 ChatGPT や GitHub Copilot Chat といったAIツール です。 わからないコードの説明や、PR内容の要約、APIや型の補足など、質問を投げることでその場で壁打ちができる環境が構築できました。 その後は、技術書やサンプルコードを写経しながら実装力を強化し、壁にぶつかるたびにAIに質問を重ねることで、 学習のトライアンドエラーを高速に回すことができました。 特に印象に残っているのは、1ヶ月前は理解できなかったコードが、自分でAI Agentを活用し、出力されたコードの意図をすべて理解し、業務でも活用できるコードへと変わっていった実感です。 たとえば、最初はAIが生成したコードの正誤すら判断できませんでしたが、繰り返しのやり取りと経験の積み重ねによって、 「どの部分が怪しいか？なぜそうなるか？」を自然と説明できるようになっていた のです。 当初は「フロントエンドに関連する機能改善で20本ほどPRを出せたら十分」と考えていましたが、プロジェクト終盤には 60本以上のPRを提出 しており、予想以上の成果につながりました。 もちろん、新規ページ追加や、APIへリクエストを行う為のClient追加のような機能開発から、細かなUI調整や文言変更なども含まれていますが、ReactとTypeScriptの知識がほぼゼロの状態から始めた自分にとって、この実績は大きな自信になりました。 この経験から強く感じたのは、 生成AIは単なる効率化のツールではなく、学習の初動コストを下げ、スキル拡張を加速する存在である ということです。 今後、「生成AIでコードを書く」だけでなく、生成されたコードが正しいかを判断する能力＝レビュー力・設計力がますます重要になると考えています。 その意味で、AIとの理想的な関係性は以下のように整理できるのではないかと思っています。 得意な領域 → 生成AIを活用し、生産性を最大化する 不得意な領域 → 生成AIを“頼れるエキスパート”として活用し、学習のスピードを上げる AIと上手く付き合うコツは得意な領域では積極的に生成AIを活用し、生産性を上げ、不得意な領域では頼れるエキスパートとして活用し、学習をするのが良い近道なのではないかと思っています! まとめ 今回紹介したようにAIを活用することでこれまで専門外だったフロントエンド領域に挑戦することができました。一方で、AIを使う中で一貫して意識していたのが、 How（やり方）に偏りすぎないことの重要性 です。 Claude CodeやCodex CLIなど、AI Agentによるコードの自動生成は非常に便利ですし、私自身も Zennで記事 を書くほど積極的に活用しています。 しかし、ソフトウェアエンジニアとして本当に重要なのは、 「なぜその実装を選ぶのか？」「設計意図は何か？」というWhyの部分 です。 ユーザー体験、アーキテクチャ、保守性、チーム内の運用方針など、Whyを考慮することで、より本質的な開発ができると確信しています。 AIは間違いなく、これからのエンジニアにとって欠かせないパートナーになります。 だからこそ、自身の成長へつながる使い方と、上手く付き合っていくのがこれからのAI時代のエンジニアに求められるスキルセットだと思っています! 最後に宣伝で、BASEにおけるAI活用や開発スタイルにご興味を持っていただけた方がいれば、ぜひ採用ページもご覧ください！ binc.jp 今後も、プロジェクトで得た知見を継続的に発信していきます。 最後までお読みいただき、ありがとうございました! おわり!

はじめに こんにちは、BASE株式会社 上級執行役員 SVP of Development の藤川です。 今年、生成AIの活用は経営課題の一つとして大きな注目を集めています。 開発担当役員という立場としても、この変化を肌で感じる必要があると考え、何年ぶりかにソースコードと向き合い、実際にプルリクエストを出してみることにしました。 ソースコードから離れていた10年間 最後にBASEのソースコードを書いていたのは、2016年頃まで。 上場に向けて、採用活動や組織拡大がマネジメント課題として本格化し、マネージャ育成やエンジニア採用、IT内部統制、情報システム整備といった役割が増えていく中で、自然と現場のコードから離れていきました。 その後、システムは大きく進化していきました。 開発環境のDocker化、本番環境のコンテナ化、テスト導入、React/Vue.js採用、モジュラモノリス化、CakePHP依存度の低下、PHP5から7〜8への移行…。 自分が作った開発チームの人たちの手で、気付けば、今のコードやサーバ構成はすっかり「浦島太郎」状態になっていました。 CursorでBASEのコードをキャッチアップ 最初の壁は、この10年分の変化をどう取り戻すか。 以前からのBASEのシステム構造は頭に入っていたので、その知識をベースにAIを使いながらキャッチアップしていきました。 使ったのはAIエージェントアプリの「Cursor」です。 Dockerfileやドキュメントを一つひとつ読むには時間がかかりますが、これらの情報やソースコードを下地としてCursorに質問すると、必要な情報を整理してくれます。 合間の時間を活用しながら進め、ほぼ誰にも質問せずに1週間で開発環境を再現できました。 どうしてもわからない部分だけ、CTOにヒントをもらう程度で済みました。 特に驚いたのは、ソースコードだけを元に「BASE Apps」という概念をCursorが理解してくれたことです。 BASE Appsとは、抽選販売機能やTikTok Shop連携などの機能を、後からショップにインストールできる仕組みです。 使い始めのBASEはシンプルなまま、必要に応じて高い機能を追加できるようにすることで、お店の成長に合わせた柔軟な情報アーキテクチャを実現しています。 この構造をAIが説明してくれたとき、正直ちょっと感動しました。 実際にPRを出してみた 環境構築が終わり、手元のDocker環境でBASEの開発環境が動くようになったので、新入社員やインターンの人に割り当てられるオンボーディング用のチケットプールから、ちょっとした不具合修正のチケットを割り当ててもらいました。 チケットに書いてある要件をプロンプトとしてCursorに渡すと、修正案を生成してくれます。チケットに書いてある要件が適切かつ具体的であればあるほど、修正案の生成は精度が高くなります。 それを元にコードを書き換えてプルリクエストを出すことに成功しました。 コード自体は当社のエンジニアの仕事場ですから適当なコードは出せません。できるだけ丁寧に内容のチェックをしました。ここまではほぼほぼ短時間での作業なのですが気の使い所です。 エンジニアからは丁寧なレビューが返ってきましたが、振り返ると「必要以上に大きな修正だったかもしれない」と感じています。 理由は、フロントエンドとバックエンドが別リポジトリで管理されており、Cursorがそれぞれの中で最適解を導いた結果、全体としては少し大げさな修正になっていたためです。 今のCursorの管理単位はリポジトリ単位になるため、リポジトリ間の関係性については人間が俯瞰して補う必要があり、そこは甘かったなと痛感しました。また、その解像度でコードレビューをしてくれた当社エンジニアはマジですごいなと改めて思いました。 レビューを通じて感じたこと レビューの指摘自体は正しく、Webサービスの変更において最小限の修正が望まれるという考え方には納得です。 今回のケースではCursorが生成したコードは「動作的には正しい」ものでしたが、それが「チームとして最適なコード」であるとは限りません。 AIが導いた“技術的に正しい解”と、プロダクトとして“望ましい解”は必ずしも一致しない 。 このギャップは今回の大きな学びでした。 一方で、AIが生成したコードを人間が精緻にレビューするのは工数がかかります。 過剰にレビューするのは非効率にもつながり、今後は「どこまで人力で見極めるか」の基準づくりが重要になると感じました。 なお、今回のレビューは、上級執行役員からのプルリクエストということもあり、普段より丁寧に対応してくれた可能性があります（もしかすると警戒もあったかもしれません 笑）。普段のメンバー同士であれば、もう少し軽いレビューで済んだかもしれません。 なので、逆にこれほどの時間をつかってもらって申し訳ないなと思ったのが正直な感想で、アウトプットをCTOや開発チームに委ねていて、自分自身で責任を持ちきれない今の役割においては、気軽にプルリクは出せないなとも思いました。 生産性と責任のバランス AI活用で避けて通れないのが、「どこまで人間が最終責任を持つべきか」という課題です。 AIが出したコードが正しく動いているなら、そのまま通すべきか？ それとも品質を優先してさらに精緻化するべきか？ この答えは一つではなく、チームやプロジェクトによって変わります。 だからこそ、開発チーム全体でレビュー方針を共有し、最適なバランスを探ることが大切です。 そしてもう一つ、AI活用は Biz・PdM・エンジニアといった役割間の業務の「のりしろ」を増やす可能性 を秘めています。 MCPなどを活用してソースコードに直接アクセスし、コードを元データとして新規開発のプロトタイプを作ったり、企画検討や初期見積もりを高精度に進めたりする未来は、もう遠くありません。 役割を超えて協業するための「のりしろ」を増やすことが、AI時代の開発組織に求められる視点 だと感じています。 この「のりしろ」があることで、Biz・PdM・エンジニアが同じデータを共有し、より速く高精度な意思決定ができる未来が見えてきます。 将来的にはAIの処理性能が向上し、複数プロジェクトや複数Webサービスを横断してカバーできるようになるでしょう。 その時に備え、現時点での最適解を常に更新し続けるチームでありたいと考えています。 おわりに〜生成AIの可能性 今回、久しぶりにコードへ戻りPRを出す中で感じた一番の収穫は、現場を離れていたベテランエンジニアでも、AIを活用すれば短期間でキャッチアップできると実感できたことです。 採用やマネジメントに注力していたエンジニアリングマネージャにとっても、生成AIは「現場感を取り戻すための強力な手段」になり得ます。 小さな修正でも構いません。AIを足がかりにコードへ再び触れることで、意思決定の精度やチーム理解は大きく変わります。 ただ正直、今回は「PRを出すとレビューしてもらうのが申し訳なく、遠慮してしまう」気持ちもありました。 だからこそ、AIに任せきりにするのではなく、自分なりの意見を持つためにも、まずはコードに触れてみることが大切だと思います。 これはマネージャだけの話ではありません。 現場のメンバーも「今のやり方がベスト」と思い込まず、AIを取り入れることで新しい速度感や発想を手に入れられます。 AI活用への温度差は、やがて成果や成長速度の差に直結します。 AIは、現場とマネージャの距離を縮め、チーム全体を底上げするツールです。 重要なのは「使うかどうか」ではなく、 「どう使い、どう組織に取り込むか」 です。 半年後、一年後にチームとしてどこまでスピードと精度を高められるかは、いまどれだけ実践と学びを積み重ねられるかにかかっています。 AIをチームの戦力に変えるために、今のうちから試行錯誤を重ね、未来の開発組織の在り方を自分たちで形作っていくことが大切です。

CTOの川口 ( id:dmnlk ) です。 ブログタイトル通りイベントをやります。2025/08/06(水)19:00 〜 21:00です。 base.connpass.com BASEでは、サービス運営13年目を迎えた今だからこそ直面している技術的課題や、その乗り越え方について、現場のエンジニアが率直に語るイベントを開催します。 日々の開発に加えて、10年以上継続するサービスならではの知見や悩み、リアルなエピソードをお伝えする予定です。 参考までに、以下の記事で取り上げたようなトピックにも触れる予定です： devblog.thebase.in パネルディスカッションではあまり外部に出てこないプリンシパルテックリードと話します。 社内記事ではこういうのとか devblog.thebase.in 個人ではこういう記事とか書いてます。 yaakai.to 社内で一番Claude codeとかを触っているはずなんでそのあたりについても色々話を聞こうと思っています。 今回のイベントは採用活動の一環ですが、「今すぐ転職したい」という方だけでなく、 「ちょっと話を聞いてみたい」くらいの温度感の方も大歓迎です。 懇親会では技術的な雑談もできるので、ぜひ気軽にご参加ください。 なお、「connpassで登録すると転職活動がバレそうで不安…」という方は、XなどでDMいただければ個別に対応します。

CTOの川口 ( id:dmnlk ) です。 ブログタイトル通りイベントをやります。2025/08/06(水)19:00 〜 21:00です。 base.connpass.com BASEでは、サービス運営13年目を迎えた今だからこそ直面している技術的課題や、その乗り越え方について、現場のエンジニアが率直に語るイベントを開催します。 日々の開発に加えて、10年以上継続するサービスならではの知見や悩み、リアルなエピソードをお伝えする予定です。 参考までに、以下の記事で取り上げたようなトピックにも触れる予定です： devblog.thebase.in パネルディスカッションではあまり外部に出てこないプリンシパルテックリードと話します。 社内記事ではこういうのとか devblog.thebase.in 個人ではこういう記事とか書いてます。 yaakai.to 社内で一番Claude codeとかを触っているはずなんでそのあたりについても色々話を聞こうと思っています。 今回のイベントは採用活動の一環ですが、「今すぐ転職したい」という方だけでなく、 「ちょっと話を聞いてみたい」くらいの温度感の方も大歓迎です。 懇親会では技術的な雑談もできるので、ぜひ気軽にご参加ください。 なお、「connpassで登録すると転職活動がバレそうで不安…」という方は、XなどでDMいただければ個別に対応します。

はじめに こんにちは！Data Platformチームでデータエンジニアとして働いている @shota.imazeki です。 弊チームでは、従来の分析基盤を段階的に刷新する取り組みを進めており、その第一歩として、ECS上で動かしていたAirflowをAWS上のマネージドサービスである Amazon Managed Workflows for Apache Airflow（以下、MWAA）に移行しました。 もともとはインフラ管理の手間を減らすことが目的でしたが、結果としてバッチ処理時間が大幅に短縮されるという意外な効果も得られました。 この記事では、ECS上のAirflowからMWAAへの移行に至った背景や、工夫したポイント、得られた改善効果などを紹介していきます。 移行に至った背景 これまでBASEではECS上でApache Airflow v1を運用していましたが、運用負荷が高く、インフラ周りの管理には別チームの支援をお願いすることもありました。またECS用に稼働しているRDSのストレージ容量が逼迫しつつあったことも大きな課題の一つでした。 また、Airflow v1ではサポートされていないオペレーターや機能があり、ワークフローの設計・実装に制限が課されていました。従来の分析基盤を刷新していくにあたり、これらの制約は大きな障壁になると判断し、基盤の中核を担うオーケストレーションツールであるAirflowから着手することにしました。 その結果、Airflowのメジャーバージョンアップデートにあわせて、インフラ管理の負荷を軽減できるマネージドサービスであるMWAAへの移行を決断しました。 環境構築と移行準備 最初にMWAAの公式ドキュメントを参考にしながら環境構築を行いました。事前に必要なものとしては、バージョニングが有効化されたS3バケットのみで、それ以外のVPCやセキュリティグループ、IAMロールについてはMWAAのマネジメントコンソール上で作成しました。 参考: https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/get-started.html この環境構築の段階で工夫したことや躓いた点があったため、次にそれらについて触れていきます。 1. SSH鍵やAPIトークンなどの機密情報をSecrets Managerで管理する ECSで運用していた際は、Airflow上の環境変数やAirflow Variable, ConnectionにSSH鍵やAPIトークンなどを設定して管理してました。ただし、どこにどの情報を置くかの基準が曖昧になっており、管理が煩雑化していたため、移行に合わせて管理方法を見直しました。 MWAAでは S3にファイルとして配置して参照する方法 もありますが、以下の観点からSecrets Managerに統一しました。 セキュリティ管理の観点 情報更新時の作業負荷軽減と安全性向上 MWAAへの移行に伴い、機密性の高い情報は全てSecrets Managerに保存し、Airflowから直接参照する設計 に切り替えました。 MWAAのAirflow設定オプション MWAA環境構築時に、Airflow設定オプションで[カスタム設定を追加]を選択し、以下のキーと値のペアを追加します。 secrets . backend : airflow . providers . amazon . aws . secrets .secrets_manager. SecretsManagerBackend secrets .backend_kwargs: { " connections_prefix " : " airflow/connections ", " variables_prefix " : " airflow/variables " } MWAAからSecrets Managerへのアクセス設定 MWAAからSecrets Managerに安全にアクセスできるよう、IAMロールとポリシーを設定しました。セキュリティを考慮して、 airflow/* という名前の Secretsのみアクセスできるようにスコープを絞っています。 参考: https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/mwaa-create-role.html#mwaa-create-role-attach-json-policy { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Action" : [ "secretsmanager:GetResourcePolicy" , "secretsmanager:GetSecretValue" , "secretsmanager:DescribeSecret" , "secretsmanager:ListSecretVersionIds" ], "Resource" : "arn:aws:secretsmanager:{リージョン}:{アカウントID}:secret:airflow/*" }, { "Effect" : "Allow" , "Action" : "secretsmanager:ListSecrets" , "Resource" : "*" } ] } Secrets Manager側の設定 Secrets Managerにて、以下のように名前を付けて情報を保存します。複数のパラメータをまとめたい場合はJSON形式にしておくと、Airflow側で分割して取得する必要がなく便利でした。 airflow/connections/SSH_CONNECTION { "conn_id" : "SSH_CONNECTION" , "conn_type" : "ssh" , "host" : "192.0.2.0" , "login" : "centos" , "port" : 22 , "extra" : { "private_key" : "-----BEGIN RSA PRIVATE KEY----- \n <秘密鍵の内容は伏せています> \n -----END RSA PRIVATE KEY-----" } } airflow/connections/GCP_CONNECTION { " conn_type ": " google_cloud_platform ", " extra ": { " project ": " sample-project ", " keyfile_dict ": { " type ": " service_account ", " project_id ": " sample-project ", " private_key_id ": " abc123def456 ", " private_key ": " -----BEGIN PRIVATE KEY----- \n <秘密鍵の内容は伏せています> \n -----END PRIVATE KEY----- \n ", " client_email ": " sample-sa@example.com ", " client_id ": " 1234567890 ", " auth_uri ": " https://accounts.google.com/o/oauth2/auth ", " token_uri ": " https://oauth2.googleapis.com/token ", " auth_provider_x509_cert_url ": " https://www.googleapis.com/oauth2/v1/certs ", " client_x509_cert_url ": " https://www.googleapis.com/robot/v1/metadata/x509/sample-sa%40sample-project.iam.gserviceaccount.com " } } } airflow/variables/API_TOKEN abcdefg1234567890 DAGからの利用例 その後、DAGファイル上で以下のようにコードを書くことでSSH鍵やAPI_TOKENを利用することが可能になります。 from airflow.providers.ssh.operators.ssh import SSHOperator from airflow.providers.google.cloud.operators.bigquery import BigQueryExecuteQueryOperator from airflow.models import Variable # Secrets Manager に保存された SSH Connection を利用 ssh_task = SSHOperator( task_id= 'ssh_task' , ssh_conn_id= 'SSH_CONNECTION' , command= "echo 'Hello MWAA!'" , dag=dag, ) bq_task = BigQueryExecuteQueryOperator( task_id= 'bq_task' , sql= "select 'Hello MWAA!'" , use_legacy_sql= False , location= 'asia-northeast1' , gcp_conn_id= 'GCP_CONNECTION' , dag=dag, ) # Secrets Manager に保存された API トークンを取得 token = Variable.get( 'API_TOKEN' ) これにより、従来の環境変数やAirflow Connection、S3によるファイル管理と比較して、より明確かつ安全に機密情報を一元管理できるようになりました。 2. フォルダ構成の整理 MWAAではDAGファイル以外にも、以下のような共通リソースを利用するため、dagsフォルダ配下に用途ごとに整理しました。 dags/ ├── sample_dag1.py # DAGファイル ├── sample_dag2.py ├── plugins/ # カスタムオペレーター、フックなど │ └── custom_operator.py ├── sql/ # クエリファイル │ └── sample_query.sql └── common/ # 共通関数やユーティリティ └── utils.py MWAAのS3バケットでは、dagsフォルダ直下がPythonモジュールパスとして認識されるため、DAGファイルと同じ階層配下( dags/ )に共通リソースをすべてまとめています。 そのため、DAGファイル内では以下のようにシンプルにインポートできます。 from common.utils import some_function from plugins.custom_operator import CustomOperator SQLファイルの利用方法 Airflowで利用するクエリは以前から .sql ファイルで管理しており、この運用をMWAAでも継続しています。DAGのtemplate_searchpathにsqlフォルダを設定することでBigQueryExecuteQueryOperatorにファイル名を指定すればクエリを実行できます。 from airflow.providers.google.cloud.operators.bigquery import BigQueryExecuteQueryOperator # DAGオブジェクトの作成（詳細は省略、SQLファイルの検索パスのみ記載） dag = DAG( dag_id= 'base_dwh' , template_searchpath=[ '/usr/local/airflow/dags/sql' ], ) bq_task = BigQueryExecuteQueryOperator( task_id= 'bq_task' , sql= 'sample_query.sql' , # sqlディレクトリ配下のファイル use_legacy_sql= False , location= 'asia-northeast1' , gcp_conn_id= 'GCP_CONNECTION' , dag=dag, ) もちろんJinjaテンプレートにも対応しており、DAG実行時に動的に値を埋め込むことも可能です。以下は、Airflowの組み込みマクロ( {{ ds }} )と、DAG側から params を使って渡した値の両方を SQLファイル内で利用する例です。 -- sample_query.sql SELECT column1, column2 FROM `sample_dataset.sample_table` WHERE DATE (column_date) = ' {{ ds }} ' AND category = ' {{ params.category }} ' DAG側では、 params に値を渡すことで、SQLファイル内のJinjaテンプレートが展開されます。 from airflow.providers.google.cloud.operators.bigquery import BigQueryExecuteQueryOperator bq_task = BigQueryExecuteQueryOperator( task_id= 'bq_task' , sql= 'sample_query.sql' , use_legacy_sql= False , location= 'asia-northeast1' , gcp_conn_id= 'GCP_CONNECTION' , params={ 'category' : 'category1' }, # params で category を指定する例 dag=dag, ) 3. GitHub Actions で MWAA への自動デプロイ ECS時代もCircleCIを使ってCI/CDによるデプロイを行っていましたが、MWAAではS3にファイルを配置する方式になるため、移行にあわせてGitHub Actionsに切り替え、デプロイ方法も見直しました。 構築した内容 GitHub Actionsによって以下を自動化しました。 mainブランチへのマージ時に、DAGファイル・plugins・共通処理・SQLファイルなどに変更があれば、S3にアップロードする。 以下はそのGitHub Actionsのサンプルです。 name : Deploy MWAA DAGs on : push : branches : - main paths : - 'dags/**' jobs : deploy : runs-on : ubuntu-latest steps : - name : Checkout repository uses : actions/checkout@v4 - name : Configure AWS credentials uses : aws-actions/configure-aws-credentials@v2 with : aws-region : ap-northeast-1 # 使用している AWS リージョン aws-access-key-id : ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key : ${{ secrets.AWS_SECRET_ACCESS_KEY }} - name : Sync DAGs to S3 run : aws s3 sync dags/ s3://sample-airflow-dag-bucket/dags/ --delete - name : List uploaded DAGs run : aws s3 ls s3://sample-airflow-dag-bucket/dags/ なお、 requirements.txt が更新された場合はMWAA環境の更新が必要です。現在は手動で対応しているものの、今後はGitHub Actionsによる自動反映も検討しています。 ただし環境更新中は一時的にMWAAが停止するため、バッチ処理への影響がないタイミングで実行する必要があり、このあたりは慎重に検討していきたいと考えています。 4. requirements.txt で発生した問題と対処 MWAAでも外部APIを利用するために、requirements.txtにライブラリを記載してインストールしています。ECS時代から利用していたgoogle-ads, facebook-businessなどの広告系API用ライブラリも引き続き使用していました。 発生した問題 MWAAでrequirements.txtを更新した際、次のような問題が発生しました。 一部のライブラリ(google-ads, facebook-businessなど)のインストール時にエラーが発生 MWAAはpip installが1つでも失敗した場合、全てのインストールが中断される(All or Nothing)仕様 そのため、全てのDAGで必須なapache-airflow-providers-*系ライブラリがインストールされず、DAGが動作しなくなる 原因 Airflow公式が提供しているconstraintsファイルと requirements.txt に記載したバージョン指定が衝突していました。たとえば、MWAA v2.8.1(Python 3.10)の場合、以下のconstraintsファイルが適用されます。 https://raw.githubusercontent.com/apache/airflow/constraints-2.8.1/constraints-3.10.txt このconstraintsファイルに含まれるバージョンと異なるバージョン(google-ads==22.0.0 など)を明示的に指定してしまうと、バージョン衝突によってインストールエラー → 全てのインストールが失敗ということになります。 参考: https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html#constraints-files 対応策 ローカル環境でAirflowのconstraintsを適用した状態で pip install を検証するようにしました。 # 仮想環境を作成 rm -rf venv python -m venv venv source venv/bin/activate # pip / setuptools / wheel を最新化 pip install --upgrade pip setuptools wheel # constraints を適用してインストール pip install -r requirements.txt \ -c https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.10.txt 特に以下に注意しています。 MWAAのバージョンごとに対応するconstraintsファイルを適用すること インストールしたいライブラリがconstraintsファイルで制約されているか確認すること 必ずローカルでインストールが成功することを確認してから、MWAAに反映すること MWAAへの移行作業 デプロイやSecrets管理などの仕組みが整ったので、実際の移行作業自体は比較的シンプルでした。 移行の進め方 DAGごとに独立していたため、全てを一度に切り替えるのではなく1つずつ順に移行・動作確認 TriggerDagRunOperatorを用いたDAGのみ、まとめて切り替え 影響範囲の小さいDAGから順に移行することでリスクを抑制 v1の時は実装上の都合からBigQueryのクエリ実行やSlack通知などで自作していたOperator / Hookを以下の観点からAirflow公式のProviderに置き換え 保守・メンテナンスコストの削減 Airflowバージョンアップ時の互換性確保 Providerごとに細かな改善・バグ修正が取り込まれている その他 MWAAの動作環境(PythonバージョンやAirflowバージョン)に合わせて、コードの微修正も行いました。 機密情報の管理やDAG配置場所の変更も事前に行っていたため、その部分のコードの微修正のみでDAG本体の移行作業自体はスムーズに完了しました。 移行によって得られた意外な効果 MWAAへの移行を進めた主目的は「インフラ管理の手間削減」でしたが、思わぬ性能改善という効果も得られました。 処理時間の改善 もともと日次バッチとして実行していたデータ連携処理では、1日あたり約14時間の処理時間がかかっていました。MWAAに移行した結果、約9時間で完了するようになり、4〜5時間ほど短縮されました。 詳細に見ていくと、ECS側では各タスクの開始間隔にも約30秒の遅延があり、日次バッチ全体では約500タスク × 30秒 = 約4.2時間の待機時間が発生していました。MWAAではこの待機時間がほぼなくなっており、これによって処理時間が改善されたと考えています。 原因の考察 さらに調査したところ、ECSの方ではExecuterがSequentialExecutor(逐次実行)になっていましたが、MWAAではデフォルトでCeleryExecutor(並列実行)が使用されていたためでした。 ECS時代はシンプルさを優先して SequentialExecutor を使用しており、タスクは1つずつ実行していました。一方、MWAAではCeleryExecutor(またはKubernetesExecutor)がデフォルトで、タスクが依存関係に応じて複数同時に実行される構成となっています。これにより、独立して動作可能なタスクは自動的に並列実行され、タスク間の待機時間も解消されたため、全体の処理時間が大幅に短縮されたと考えています。 なお、ECS時代でもExecutorの設定を変更すれば並列実行による改善は可能だったかもしれません。ただし、そうした調整やメンテナンスを自前で行うことなく、マネージド環境がデフォルトで最適な構成にしてくれるのも、MWAAを選んだ大きなメリットだと感じました。 影響範囲 タスクが並列実行されることによる影響がないか、以下の観点で確認しました。 元データベースへの影響について MWAAへの移行によって処理の並列化が進みましたが、ETLツールとしてメインで利用しているEmbulk自体は逐次的に実行されるようになっているため、元データベースへの負荷が並列実行で急増することはありませんでした。単純に待機時間が減ったのみで、移行後も元DBへの負荷増加を心配することなく、安定して運用できています。 並列実行によるタスク間の影響 同じテーブルや同じファイルへの出力などをDAGのタスク内で行なっておらず、タスクの依存関係(task1 >> task2)をDAG内で明示していたために同時実行がなされても問題にはなりませんでした。今後もExecutorに依存しない(並列実行されても問題ない)堅牢なDAG設計を継続していきます。 今後の改善点 1. DAGsフォルダ直下のファイル整理 現在、 dags フォルダ直下にDAGファイルだけでなく plugins/ , sql/ , common/ といった複数のフォルダが混在している状態です。 将来的には、DAGファイルと共通リソースをより分かりやすく整理し、管理・メンテナンスしやすい構成に改善したいと考えています。 2. Terraformによるインフラ構成管理 MWAA環境やSecrets Manager、S3バケットなどのAWSリソースをTerraformで管理することで、環境構築や変更の再現性を高め、運用負荷の軽減を図りたいです。 現状は手動で設定している部分も多いため、IaC化による標準化・自動化が望まれます。 おわりに Airflowの移行によって、運用負荷の軽減だけでなく、思わぬ性能改善も得ることができました。 今後も基盤全体の改善を進めながら、より安定したデータ連携基盤を目指していきます。 最後となりますが、弊社ではデータエンジニアを募集しています。上記で述べた課題以外にもBASEの分析基盤には多くの課題があって、とてもやりがいのある仕事かなと思っております。ご興味のある方は気軽にご応募ください！ open.talentio.com

AWS SUMMIT JAPANにあった社名を書くボード はじめに BASE BANK Dept で Engineering Program Manager をしている大津です。 BASEでは多くのプロダクトでAWSを使用しており、BASE BANK Deptでもフルサイクルエンジニアの思想のもと、AWSに触れる機会が多いです。そのため、AWSのキャッチアップはとても重要です。 なぜフルサイクルエンジニアを目指すのか / FullCycleDeveloperNight#1 - Speaker Deck 今回はAWSの最新情報を得るため、2025年6月25日（水）〜26日（木）に開催されたAWS Summit Japan 2025に参加してきましたので、その様子をお届けします！ ちなみに昨年の参加レポートブログもありますので、そちらもぜひご覧ください。 devblog.thebase.in 基調講演 基調講演は大盛況で、本会場はもちろん、サテライト会場もほぼ満員の状況でした！ AWSやAWSを利用しているパートナー企業の発表に加え、AIに関してはAnthropic社のプレゼンテーションなど、魅力的なトピックが目白押しでした！ サテライトだけどなんとか座れた！ 基調講演聴講します✌️ #AWSSummit pic.twitter.com/nYXHUW1h2J — 02 (@cocoeyes02) 2025年6月25日 おお！anthropic 日本オフィス開設 #AWSSummit pic.twitter.com/COh5DFCeYM — 02 (@cocoeyes02) 2025年6月25日 ブース 会場には様々な種類のブースが設置されており、AWSについて詳しく知ることができる「AWS Expo」や、各社のAWS活用事例を詳しく学べる「Partner Solution Expo」などがありました！ バーチャルデータセンターツアー面白かった！ 実際のAWSデータセンターをVRで見れる！空調とか発電機とか諸々実物見れるの面白い #AWSSummit pic.twitter.com/k9jBQ2LvAh — 02 (@cocoeyes02) 2025年6月25日 去年もブースみたchaos kitty! なんとwebアプリ機能ができた他、7 月中には AWS Samplesで公開予定とのこと！ 社内でやりたいなーーー #AWSSummit pic.twitter.com/QFS1snXt9h — 02 (@cocoeyes02) 2025年6月25日 ポーカーライクなゲームでAWSについて学べる#スマポ！ 会場では自分のスマホでプレイできるよ！ 体にパターンを叩き込む感じがあって反射でパターン出せるようになりそうで良い #AWSSummit pic.twitter.com/M1Qoldh7lK — 02 (@cocoeyes02) 2025年6月25日 ちいかわの隣にゴリゴリのAWSアーキテクチャ図あるのすき #AWSSummit pic.twitter.com/4W8Hh55fxh — 02 (@cocoeyes02) 2025年6月25日 GameDay ゲームのようにAWSを体験できるワークショップGameDayにも参加してきました！ aws.amazon.com 今回のGame Dayのテーマはgenerative AIで、AWSが提供している様々なAIサービスを中心とした内容となっていました！ あまりにもGameDay参加したい欲が強くて最前列取ってしまった #AWSSummit pic.twitter.com/RgryNMNEOO — 02 (@cocoeyes02) 2025年6月26日 GameDay参加していきます！！ #AWSSummit pic.twitter.com/GnZR4ZGV0x — 02 (@cocoeyes02) 2025年6月26日 惜しくも上位入賞はなりませんでしたが、個人的にはあまりキャッチアップできていなかった分野だったため、とても勉強になりました！ GameDay 8位/22チームでした！残念！ #AWSSummit pic.twitter.com/IGk1mlgqno — 02 (@cocoeyes02) 2025年6月26日 もらった公式ノベルティ また、先着配布のクッションやAWS認定ステッカーなど、魅力的なノベルティグッズも多数いただきました！ サテライトだけどなんとか座れた！ 基調講演聴講します✌️ #AWSSummit pic.twitter.com/nYXHUW1h2J — 02 (@cocoeyes02) 2025年6月25日 そういえばまだもらってなかったからAWS認定ステッカーもろた #AWSSummit pic.twitter.com/rs2GBx3s9z — 02 (@cocoeyes02) 2025年6月25日 Flight Tagもろた！ #AWSSummit pic.twitter.com/QdqKyHf2Pp — 02 (@cocoeyes02) 2025年6月25日 おわりに 他にもセッションに参加したり、コミュニティブースでのLTを聞いたりと、このブログで書ききれないほど様々なコンテンツを見て、学び、体験してきました！ やはりAWS Summitは、AWSについてキャッチアップするのに最適なイベントだと感じます。来年もぜひ参加したいです！ BASE BANK Deptでは、AWSにも触れるフルサイクルエンジニアを募集しています。 まずはカジュアル面談からどうぞ！ open.talentio.com open.talentio.com binc.jp