こんにちは、新卒3年目でビジネスイノベーション統括本部ITD1-3の堀川です。 愛用しているキーボードは GoForty v2のOrtho配列 です。 今回、私が普段の業務で使用しているTypeScriptをテーマにした大型カンファレンス『TSKaigi 2026』の参加レポートを書かせていただきました！ 去年の参加レポート記事に引き続き、カンファレンスの様子や感想、魅力などを発信していきます TSKaigi2025で分かったTypeScriptの流行 ↑今年の愉快なTSKaigi参加メンバーたち カンファレンス概要 情報区分 カンファレンス詳細 イベント名 TSKaigi 2026 開催日 2026/05/22、2026/05/23 開催場所 ベルサール羽田 京急空港線羽田空港第3ターミナル駅から徒歩5分 ミッション 学び、繋がり、"型"を破ろう セッション感想 ここでは私が参加したセッションの中で、特に面白かったものを自分なりの理解を交えて紹介します セッション感想① 実践TanStack Start: 新規プロダクトを開発して確立した、サーバーとクライアント境界の設計パターン セッション概要 https://2026.tskaigi.org/talks/26 スピーカー Shimmy スライド資料 https://speakerdeck.com/kaminashi/practical-tanstack-start-server-client-boundary-patterns?slide=3 Next.js と同じ React 向けフルスタックフレームワークである  TanStack Start  に関するセッションです。まだ v1.0 未満でコミュニティや事例が少ない中、 実際に採用した新規プロダクトの設計知見 を聞ける貴重な内容でした。 loader と Server Functions の責務設計 TanStack Start を使う上で核心となるのが、この2つの責務をどう分けるかという問題です。 役割 loader ページ描画「前」に走る処理を書く場所 Server Functions クライアントから呼び出せるサーバー側の処理 Next.js ではこの2つの挙動がフレームワーク側であらかじめ決まっています。一方 TanStack Start は、どちらに何を書くかを 開発者自身が決める 設計です。 この違いは開発体験にも現れます。Next.js はキャッシュ挙動がフレームワーク内部で自動的に決まるため、「なぜデータが古いまま表示されるのか」を調べるために内部実装を読み込むことも少なくありません。TanStack Start はすべての挙動を自分たちのコードに明示する設計のため、 動作への理解を保ったまま開発できる というメリットがあります。 設計パターン：loader 編 loader 内の取得は最小限に留め、各コンポーネントが必要なデータを自分で取得する というアプローチです。 // loader では認証情報から tenantId だけを取り出すexport const Route = createFileRoute("/_authed/orders")({ loader: ({ context: { session } }) => ({ tenantId: session.tenantId }), component: OrdersPage,});// 各コンポーネントが useQuery で必要なデータを取得するfunction OrdersPage() { const { tenantId } = Route.useLoaderData(); const { data } = useSuspenseQuery(ordersQueryOptions(tenantId)); return ( <> <NotificationBadge /> {/* 子の中で useQuery */} <OrdersTable orders={data} /> <Recommendations /> {/* 子の中で useQuery */} </> );} // loader では認証情報から tenantId だけを取り出す export const Route = createFileRoute ( " /_authed/orders " )( { loader : ({ context : { session } }) => ( { tenantId : session . tenantId } ) , component : OrdersPage , } ) ; // 各コンポーネントが useQuery で必要なデータを取得する function OrdersPage () { const { tenantId } = Route . useLoaderData () ; const { data } = useSuspenseQuery ( ordersQueryOptions ( tenantId )) ; return ( <> < NotificationBadge /> { /* 子の中で useQuery */ } < OrdersTable orders ={ data } /> < Recommendations /> { /* 子の中で useQuery */ } </> ) ; } 設計パターン：Server Functions 編 ① 横断関心事は Middleware へ切り出す ログ出力や認証チェックなど、複数の Server Functions に共通する処理は handler に直接書かず、Middleware として分離します。 export const loggerMiddleware = createMiddleware({ type: "function" }).server( async ({ next, functionId }) => { const requestId = crypto.randomUUID(); logger.info({ requestId, functionId }, "handler:start"); return next({ context: { requestId } }); },); export const loggerMiddleware = createMiddleware ( { type : " function " } ) . server ( async ({ next , functionId }) => { const requestId = crypto . randomUUID () ; logger . info ( { requestId , functionId }, " handler:start " ) ; return next ( { context : { requestId } } ) ; }, ) ; ② handler にはロジックや I/O の詳細を直接書かない handler は「受け取って委譲する」だけにとどめ、実装の詳細は別の関数に任せます。 export const saveOrder = createServerFn({ method: "POST" }) .middleware([loggerMiddleware]) // 横断関心事 .inputValidator(saveOrderInputSchema) // 入力の検証 .handler(async ({ data }) => upsertOrder(data), // ロジックは別関数へ委譲 export const saveOrder = createServerFn ( { method : " POST " } ) . middleware ([loggerMiddleware]) // 横断関心事 . inputValidator (saveOrderInputSchema) // 入力の検証 . handler ( async ({ data }) => upsertOrder (data) , // ロジックは別関数へ委譲 この設計により責務が自然と分離され、人間にも AI にも読みやすいコードベースが実現できます。 まとめ もし TanStack Start を新規プロダクトへ導入するとしたら、Next.js との最大の違いは「フレームワークに動作を任せるか、自分たちで明示するか」という設計思想の差です。 使い分けの目安としては、SEOや高速な初期表示が求められるサービス、またはチームに Next.js の知見が豊富な場合は Next.js が無難です。一方、複雑なサーバー／クライアント間のデータフローを自分たちで制御したい場合や、コードベースの挙動を隅々まで把握したい場合は TanStack Start が向いているといえます。 Next.js に慣れ親しんでいるほど、最初は自由度の高さに戸惑うかもしれません。しかし今回紹介した設計パターンを最初から取り入れることで、コードベースの見通しを保ったまま開発をスタートできます。 「なぜこの挙動になるのか」を把握したまま開発したい新規プロダクトにおいて、TanStack Start は有力な選択肢になりそうです。 セッション感想②　AI時代に考える、Branded Types で実現する堅牢な型付け セッション概要 https://2026.tskaigi.org/talks/62 スピーカー 池奥裕太 / @yuta-ike スライド資料 https://www.docswell.com/s/4136989/Z6NJ78-tskaigi2026#p1 TypeScript の中でもさらに厳格な型定義を行う Branded Types について、その意義と具体的な魅力をわかりやすく解説したセッションでした。 型チェックの意義 まず前提として、型チェックには4つのパターンがあります。 実装 型チェック 評価 正しい 通る 嬉しい 間違っている 通らない 正常 正しい 通らない よくある・辛い 間違っている 通る 一番避けたい 「実装が間違っているのに型チェックが通る」とは、たとえば次のようなケースです。 <em>// 足し算関数 (number + number → number)</em>function add(a: number, b: number): number { return 0; // 常に 0 を返す} < em > // 足し算関数 (number + number → number)</em> function add ( a : number , b : number ): number { return 0 ; // 常に 0 を返す } 足し算を期待しているのに常に  0  が返ってくる実装ですが、戻り値の型は  number  として正しいため、型チェックでは検知できません。 これは極端な例ですが、AI に実装を依頼した際に「パッと見は問題なさそうだが、よく読むと意図した処理になっていない」という経験をした方もいるのではないでしょうか。こうした問題に対処するために、より厳格な型定義が求められます。そこで有効なのが Branded Types です。 Branded Types とは 同じ構造を持ちながら意味合いの異なる型（例： User  と  Book ）を区別するために、架空のプロパティ  __type  を付与して型を識別する手法です。 User  型を期待する引数に  Book  型を渡そうとすると、型チェックでエラーになります。 function createUser(user: User) { ... }const book: Book = { id: getUUID(), name: "吾輩はエンジニアである", date: new Date(2000, 0, 1),} as Book;createUser(book); // TypeError: Book 型を User 型に代入できない function createUser ( user : User ) { ... } const book : Book = { id : getUUID () , name : " 吾輩はエンジニアである " , date : new Date ( 2000 , 0 , 1 ) , } as Book ; createUser (book) ; // TypeError: Book 型を User 型に代入できない プロダクト開発における Branded Types の使いどころ セッションでは、Branded Types を効果的に活用するための方針として2つが紹介されていました。 ① ドメインモデルを区別する 変数名で区別できれば理想的ですが、AI が  FailedUploadingFileId  のような丁寧な命名を常にしてくれるとは限りません。せいぜい  FailedFileId  程度になることも多いでしょう。Branded Types と型チェックを組み合わせることで、その区別をコードレベルで担保できます。 ② 値の状態や属性を表現する たとえばバックエンドへ送る  string  型の値に対して、「型チェック済み」「ドメインチェック（記号を含まないなど）済み」という条件を本当に満たしているかどうかは、通常の型定義だけでは保証できません。Branded Types を使うことで、こうした「チェック済みの状態」を型として表現できます。 Branded Types によって型安全なコードを書くことで、コードの前後を読まなければ判断できなかった要素を、型定義を見るだけで把握できるようになります。 まとめ AI コーディングが普及した今、コードを書く速さよりも「AI が生成したコードを正しく検証できるか」が重要になっています。Branded Types が注目されている背景には、まさにこの変化があると考えています。 型定義を厳格にしておくことで、AI が生成したコードが意図通りかどうかを、コードを細かく読まなくても型チェックの段階で検知できるようになります。「関数の引数・戻り値の型を厳格に定義する」「副作用を持たせない」といった方針がレビューコスト削減につながる事例として挙がっている中で、Branded Types はこうした流れと特に相性の良いアプローチです。 「AI に実装を任せる機会が増えた」と感じている方ほど、導入を検討する価値があるといえるでしょう。 企業ブース 今年も1日目にかなりの数を回らせていただきました！ 去年とは違い、スタンプラリーは企業名別に区切られておらず、どのブースに行っているかの進捗を忘れてしまうことがしばしばありました... (今年はラムネがとても多かったです。嬉しい) セッション感想に力を入れ過ぎて、文字数がかなり多くなってしまったので、今回は1社さんだけの紹介になります... テイラー株式会社 テイラー株式会社は、TSKaigiに参加されている企業の中で特に印象に残った会社です。TypeScriptの特徴的な事業活用事例を持つ会社で、その内容がとても興味深かったのでご紹介します。 具体的には、エンタープライズ向けの大規模なERPを10倍の速さで構築できる、世界初のヘッドレスERPプラットフォームを事業として提供しています。 会社ページ ERP（Enterprise Resource Planning）とは、企業の基幹業務（会計・在庫・人事・販売など）を一元管理するシステムのことで、MicrosoftやFreeeなどのサービスが有名です。 しかも、このプラットフォームは会社独自のReactアプリケーションフレームワークで開発されており、その保守運用はもちろん、専門エンジニアとして開発サポートも担っているとのことでした。 独自フレームワーク（app-shell）のリポジトリ 会社の事業として独自のフレームワークを開発するだけでなく、その開発サポート、つまりテックリード的なことも担っているというのは、エンジニアとして琴線に触れるものがありました。 TSKaigiに参加して 去年よりもAIの活用をからめたセッションもありましたが、それ以上に型定義を厳格にするBranded Typesや最近出てきたTanstack Startに関する内容が複数あったのが驚きでした。 特にBranded Typesに関してはAIに実装を任せることが多くなったからこそ、型チェックを通した品質の担保に注目されているのかな、と感じています。 去年に引き続き、セッションや企業ブースでTypeScriptやフロントエンドの流行を学ぶことができ、とても貴重な経験になりました！ 業務はもちろんプライベートでの開発モチベにも繋がったので、これからも開発に励んでいきたい所存です。 おまけ 去年に引き続き、サプライ品がとても良かったので、社員証に付けさせていただいてます！ 今年は先端がカラビナ(?)になっており、付けやすくなっていました。ありがとうございます。 また、1日目のオープニングが終わった直後、見覚えのあるキーボードを見かけてお声かけした際、Xで一方的に存じ上げてた某モテるWeztermの人とお話しすることができました！ モテるターミナルにカスタマイズしよう（WezTerm） 特徴的なキーボードは名刺になります() ←Weztermの方のキーボード　　私のキーボード→

こんにちは、エス・エム・エスでカイポケコネクトのSREをしている 小笠原翔太 です。 2026年7月10日に開催された SRE NEXT 2026 のスポンサーセッションで、「 PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用 」というタイトルで発表しました。 発表スライドも公開していますが、せっかく取り組みについて文章をまとめたのでテックブログにも展開しようと思い、まとめ直したものがこちらの記事となります。発表内容に加えて、ブースで展示していた現在のpreview環境のアーキテクチャについての補足説明も加筆しているので、そちらは発表との差分となっています。 はじめに 全体の話はひとことでいうと、 既存プロダクトにPR単位で使い捨てられるpreview環境を導入し、1年間運用してきた話 です。 目次 はじめに 目次 カイポケコネクトと開発フェーズ カイポケコネクトとは システムアーキテクチャ 開発フェーズ 当時のリリースフロー リリーストレインの課題 1. リリース周期が長い 2. QA環境の利用が詰まる 3. 担当者の負担が大きい 解決策： 検証作業を分離して並列化する preview環境をどう設計したか 必須要件 インターフェース設計 アーキテクチャ デプロイフロー サービス構成 設計時に考えたこと 運用してどうだったか 狙いどおりリリース頻度を高められた 段階的に改善しながら育てた 結果的に利用が伸びた 運用してわかったこと 1. 複製機構の利用技術についてわかったこと 2. 複製「できない」外部サービスとの付き合い方が難しい 3. preview環境の想定外な需要が見えた まとめ 付録: 現在のアーキテクチャの紹介 カイポケコネクトと開発フェーズ カイポケコネクトとは 最初に、私たちが扱っているシステム「カイポケコネクト」は、介護/障害福祉事業者向け経営支援を行うSaaSプロダクトです。 システムアーキテクチャ カイポケコネクトのシステムアーキテクチャは、拡張性と独立性を保つためドメインごとにアプリとDBを分割して設計しています。 利用されている技術スタックと本番系の基盤構成は次のとおりです。 レイヤー 技術スタック 本番系の基盤構成 フロントエンド React / Next.jsによるSPA CloudFront + S3 バックエンド Kotlin / Spring Boot / GraphQL ECS Fargateでホスティング。5つのタスクでGraphQL APIを構成 DB PostgreSQL RDS Aurora PostgreSQL また、本体サービスとは別の複数の社内サービスとも連携しており、バックエンドのコンテナ数から考えると中規模サイズのシステムと捉えてもらうと良さそうです。 開発フェーズ プロダクトは初期の開発フェーズが完了し、プロダクトの価値を拡大する「機能追加・サービス拡大フェーズ」へ移行しようとしているタイミングでした。 そのため、 プロダクト開発の生産性を支えるために機能開発を加速させる必要があった というのが背景です。 当時のリリースフロー そのような開発の事情があるなかで、当時のリリースフローは以下のようになっていました。 当時のリリースフロー デプロイ先のAWS環境はDev, QA, Staging, Productionの4つ用意してそれぞれ使い分けていました。 まず開発フェーズでは、開発者がPRを用意してテストが通ればmainにマージしてDev環境にデプロイしていました。Dev環境は開発者が最初にデプロイするAWS環境で、少し壊れやすいのですがアプリの動作検証や基盤の構成変更の検証を行う用途で利用されていました。 一方で、本番系へのリリースフェーズでは、それとは別で リリース担当やリリースマネジャーが主導してデプロイする方式 を取っていました。 具体的には以下の流れでリリースが行われていました。 リリース担当がリリースするrevisionを決めてコードフリーズを行い、そのrevisionでQA環境へデプロイする 全QAメンバーがQA環境を占有して検証作業を実施 リリース担当がリリースタグを作成し、Staging環境へデプロイする リリース担当がテストランナーでE2Eテストを実行する リリース担当がリリースタグを作成し、Production環境へデプロイする QA環境はバージョンを固定して検証を行うための専用環境、Staging環境はE2Eテストを実行して意図しないデグレが発生しないことを保証するための環境という建付けでした。 つまり、いわゆる リリーストレイン方式でリリース していました。 リリーストレインの課題 このプロジェクトにおけるリリーストレインには大きく以下3つの課題がありました。 1. リリース周期が長い 最も大きな課題はリリース周期が長いこと です。このプロジェクトのリリースサイクルは2週間に一度でした。 開発スピードに対してリリースサイクルが長いため、価値提供の大きなボトルネックになっていました。またリリース時には2週間分の差分がまとめて本番へ反映されます。そのためリリースのタイミングで事故が起きやすく、問題発生時の切り分けも難しい状態でした。 2. QA環境の利用が詰まる 次の課題としてはQA環境の利用が詰まるという問題がありました。QA環境は検証用の占有環境として利用され、かつ 全QAメンバーが直列に検証作業を行うためどうしても長期間ロックされてしまいます 。結果的に検証期間が長引き、当時は1週間ほど環境を確保するようになっていました。 検証作業を効率的に実施できず、その間は新しいリリースもブロックされる構造になっていました。 そのため、 今後開発を加速させようとしたときに、ここの詰まりによってスケールできなくなることが容易に想像できました 。 3. 担当者の負担が大きい リリーストレインのもう1つの問題として、取りまとめを行う人の負担が大きいという人的な問題もありました。リリース担当やリリースマネージャーがリリースを主導する必要があるのですが、そこに 運用作業とリスク管理の負荷が集中 していました。 ミスを防ぐための手動プロセスや手順も増えがちで、運用が重厚になっていました。さらに、リリースされる差分のすべてを把握することが困難でした。そのため、問題発生時の対応に手間取ったり、チームをまたいだ調整コストが増えたりして、担当者を疲弊させていました。 解決策： 検証作業を分離して並列化する 解決策として考えたのは「 リリースフローから検証作業を分離して並列化する 」ことです。 以下の図は検証作業を分離・並列化したときのリリースフローの概念図です。 検証作業を分離・並列化したリリースフロー これまでリリースフェーズで行っていた QA環境での検証作業をすべて開発フェーズに移行 しています。 開発フェーズで開発者がPRを作成したあとに専用の検証環境を立ち上げ、QAメンバーがPRごとに検証作業を並列で実施できるようにします。 そして、リリースフェーズでは、Dev環境にデプロイした後は毎日定時にGitHub Actionsのscheduled workflowを起動します。このジョブはStaging環境へのデプロイからE2Eテストの実行、production環境へのデプロイまでを連続して実行する軽量なワークフローです。 また、リリースフラグを導入することで、PO（プロダクトオーナー）が任意のタイミングで新機能をリリースできるようにします。 この方式に変更することで次の効果を狙います。 リリースが毎日できる ：隔週から毎日へと頻度が上がり、価値提供が高速化。デプロイごとの変更差分が小さくなり、原因特定も容易になる QAのシフトレフトと並列化 ：検証作業を開発フェーズに移すことでリリースを安定化させ、チームや機能ごとに検証作業を並列化することで詰まりを解消する プロセスの軽量化 ：重厚なリリース手順を廃止し、リリースフローを自動化・軽量化する。リリースフラグを導入することでデプロイと新機能の有効化（機能リリース）を分離する 先ほど紹介したリリーストレインの主要課題をすべて解決できるようになっています。 preview環境をどう設計したか 先ほど述べた、リリース改善施策実現に必要な構成要素の1つが、検証作業を行うための環境（私たちはこれをpreview環境と命名）でした。 この章ではそのpreview環境をどう設計したかについて説明します。 必須要件 まずQAプロセスで必要な要件は以下3つでした。 十分な数の環境を 容易に 作れること 利用チームが 任意のバージョンをデプロイできる こと DBを使い捨てできること ーデータが汚れることを気にせず占有して使えること インターフェース設計 次に利用者のインターフェースの設計についてですが、こちらはVercel等のSaaSの開発者体験を参考にして以下のように設計しました。 GitHubのイベントをトリガー に、preview環境を自動で構築・更新・破棄する PRのコメントに自動で 各種アクセス情報を付与 する 以下はpreview環境を立てたPRのサンプルです。 preview環境を立てるPRのサンプル PRにラベルを付けると環境構築が始まり、完了するとbotがコメントでアクセス方法を案内する、という開発者体験になっています。 このようにインターフェースを作った理由は、以下を狙ったためです。 開発者とQAのスムーズな連携 ：開発者がPRに実装をまとめ、それをQA担当者へ渡すことでスムーズに検証作業に移ることができる ライフサイクル管理のしやすさ ：環境がPRに紐づくため、不要な環境の消し忘れを防いだり、クリーンな環境管理が可能になる アーキテクチャ 次にpreview環境のアーキテクチャを紹介します。全体像は以下のようになっています。 preview環境のアーキテクチャ全体図 デプロイフロー まず、preview環境のライフサイクルはGitHub Actionsのワークフローで以下のように管理します。 PRにpreviewラベルを付与 : PRの先頭のコミットハッシュを利用して環境を構築する PRにコミットをプッシュ : 差分が入ったコンポーネント（FE/BE/DB）のみ更新処理を行う PRをマージ、クローズまたはpreviewラベルを外す : 環境を削除する サービス構成 次にサービス構成ですが、 preview環境ごとにフロントエンド/API/DBを1セットずつ用意する ようになっています。 ドメインは https://preview-N.kaipoke.com （NはPR番号）を環境ごとに払い出しており、そこからアクセスできます。 フロントエンドはSPAなので、シンプルにCloudFrontとS3で配信しています。リクエストのホスト名に応じてアセットを出し分けるようにLambda（CloudFunction）を挟んでいます。 APIへのアクセスはCloudFrontとALBを介してmirage-ecsコンテナのproxy機能でハンドリングされ、ホスト名ごとにリクエストを各環境に振り分けています。環境ごとにバックエンドとDBが1セットずつ用意されており、バックエンドのECSタスクは mirage-ecs で、DBはSaaSの Neon でそれぞれ構築・管理しています。 なお、バックエンドは一環境あたりECSタスクが全部で5個動いており、内部でGraphQLのfederationを組む構成です。 モニタリングは本番系と同じくDataDogを利用して、トレースやログ、基盤のメトリクスを確認できるようにしています。 このような仕組みによって、 PRごとの環境をAPIやDBまで独立した形で複数個準備できるように作っています 。 参考情報ですが、環境の初期構築にかかる時間は2026/07/14時点で 10分程度 です。 設計時に考えたこと 設計にあたっては、以下3つの原則を守るようにしていました。 要件が不明確なうちから作り込まない ：初期段階での過剰な設計や実装を避けるため 運用・開発の負担が少ない技術を選ぶ ：当時は アプリ開発者のリソースが逼迫 しており、開発者の負担を極力抑える必要がありました 最初から完璧を目指すのではなく継続的に提供価値を高めていく ： 仕組み作りに使えるSREのリソースが当時少なかった ため、小さく作って継続的に提供価値を高めていく方針を採用 運用してどうだったか 実際に1年ほど運用してどうだったか、振り返っていきます。 狙いどおりリリース頻度を高められた まず 当初の狙いにしていたリリース頻度を高めることには成功 しました。 以下は月別のデプロイ回数の推移を表したグラフです。 月別デプロイ回数の推移 リリース方式を切り替えた2025年10月ごろから、 月2回だったデプロイが月20回前後まで増えました 。営業日は毎日リリースできるようになったことがわかります。 これはpreview環境以外の施策との合わせ技による成果ではありますが、 サービス拡大期の開発効率の向上に貢献できた と考えています。 段階的に改善しながら育てた そして、設計方針に従ってpreview環境は導入後に要件を適宜見直しながら改善しました。 以下のグラフはpreview環境に関するPRの月別件数推移を表しています。 preview環境に関するPRの月別件数 全体のタスク量は多く、PR総数も結果的に 200件超となっていた のですが、対応を段階的に行うことで少人数（設計から導入初期までは担当一人）でも早期に仕組みを開発に展開でき、その後の改善も継続することができました。 設計時に置いた「小さく作って継続的に改善する」という原則が、うまく機能した と感じています。 結果的に利用が伸びた 結果的にpreview環境の利用数は順調に伸びました。以下は月別のpreview環境を利用したPRの件数推移のグラフです。 preview環境を利用したPRの月別件数 導入当初は80件ほどだった利用件数が2026年6月は160件程度まで利用が伸びている ことがわかります。 あとでも触れますがこれは当初想定の用途以外の利用が増えたことも理由となっています。 運用してわかったこと 次に運用してわかったことや気付きについて大きく3つ紹介します。 1. 複製機構の利用技術についてわかったこと 今回、バックエンドの複製には mirage-ecs というコンテナ管理の軽量なOSS、DBの複製にはSaaSの Neon を使いました。 まずmirage-ecsは、既存のECS Fargate構成とデプロイの仕組み（ecspresso）にアドオンする形で導入できました。ecspressoの作者が作ったツールのため、 親和性が高くデプロイの仕組みをそのまま維持することができました 。 ツール導入で学習すべき新しい概念が少なく、メンテナンスも簡単で、開発チームへの負担を最小限に抑えながら導入できたのは非常によかったです。現在まで、他ソリューションへの置き換え検討が必要となる問題も出ておらず、安定して運用できています。 次にNeonですが、直感的で扱いやすいWeb UIや高速なブランチ機能、各種管理機能が充実しており、 DB複製機能の初期導入にかかる工数を大幅に削減できた のは良かったです。 一方で、サーバ配置先の制約による性能課題がありました。DBの配置先は最寄りでもSingaporeリージョンのため、SQL実行時のレイテンシーが大きくなり、 結果として一部のページで表示に時間を要する点が課題として残ってしまいました 。 機能検証においては無視しても問題ないということでしばらくはそのまま利用していましたが、動作がもっさりするのでなんとかしたいという声が多く出る状況でした。 そのため、現在はtokyoリージョンに立てたAurora Serverless v2（RDS）を利用する方式をメインに運用しています。付録にてそちらのアーキテクチャについては補足します。 2. 複製「できない」外部サービスとの付き合い方が難しい 2つ目の気づきですが運用してみて実感したのは、 プロダクト本体の複製よりも、複製できない外部サービスの扱いが難しい 、ということです。 本体の複製は開発チームでコントロールできるのですが、利用している外部サービス（連携する社内サービス含む）には様々な制約があり、それぞれ妥協案を作って運用していく必要がありました。 例えば認証基盤については契約プランの制約でテナントを新規作成できなかったため、既存テナントに相乗りする形で対応しました。 結果的に（特に不便なく運用できているものの）Dev環境のDBをコピーする方式を選択せざるを得なくなりました 。 ある社内サービスではアーキテクチャ上の制約により、環境複製の難易度が高くすぐには実現できませんでした。 結果的に既存環境に相乗りし、preview環境向けのデータを識別できるようにアプリを改修してもらい、運用でカバーする形になりました 。 また他の社内サービスでは、契約プランや予算管理上の制約があるため環境の複製ができないため、特定のpreview環境にのみ期間限定で連携するというような運用になりました。 これらの外部サービスに共通する課題は2つあります。1つは、 連携が増えるたびに運用の取り決めや調整を個別に行う必要があり、対応コストの増加につながる 点です。もう1つは、 自チームだけではコントロール・解決できない他部署・他チームの仕様や予算制約が絡むケースも多く、難易度を引き上げている点 です。 preview環境を有用な状態で維持するためには外部のサービスをうまく検証用途で動かし続けるための工夫という、技術以外の課題をクリアしていく必要がある点に注意が必要だと強く感じました。 3. preview環境の想定外な需要が見えた 3つ目の気づきはpreview環境の想定外な需要が見えたことです。 当初はQAプロセスでの利用を想定していたのですが、実際は 全体の8割が開発チームの自主的な動作確認・検証目的で利用 されていました。QA引き渡しでの利用は予想に反して全体の20%にとどまっていたのです。 開発者のユースケースには例えば以下がありました。 リスク回避 ：Dev環境へのデプロイ前の早期リスク検知 DB migrationの確認 ：DB migrationの簡単で安全な検証に利用 AIを活用した並列開発 ：複数PRを互いに影響させず同時に検証 ローカル代替 ：一時的にローカルがうまく起動できない場合などに代替の検証環境に利用 つまり 「容易に立てられる検証環境」の存在自体が、開発体験（DX）にとって実は大きな価値になっている ことが運用してから初めてわかりました。設計時は実際にどのくらい使われるか見えておらず、これは運用後の一番大きな気付きでした。 まとめ 既存プロダクトにpreview環境を導入・運用して見えてきたことは、次の3点です。 環境運用の実現性 ：今回の技術スタックでも、中規模システムのpreview環境は十分に運用できることがわかりました。少人数で運用でき、開発負担も小さく抑えることができました 外部連携の課題 ：本体の複製以上に、複製できない外部サービスとの連携設計が重要になることがわかりました 導入後の進化が大切 ：今回のように導入してから改善していくアプローチでは、運用に乗ってからの継続的な改善こそが本番となります。プロダクトの成長に合わせて育てていくことが重要です preview環境というコンセプト自体は目新しくありませんが、既存プロダクトへ導入して1年間運用してきた知見が、読んでいただいた方の参考になれば嬉しいです。 なお、発表資料は Speaker Deck で公開していますのでそちらも適宜参照してください。 付録: 現在のアーキテクチャの紹介 当日の発表スライドではお見せできなかったのですが、ブースで展示・紹介していた現在のアーキテクチャは以下のようになっています。 現在のアーキテクチャ全体図 先に紹介したアーキテクチャとの違いは DBの複製機構がNeonからAurora Serverless v2（RDS）を利用した形に変わっている ところです。 サービスごとに1つインスタンスを用意し、preview環境ごとに内部的にPostgreSQLのデータベースを作り、dump/restoreでDev環境のデータを流し込んで作っています。 Neonで利用者によく使われていたWeb UIについては、自作して提供しています。 Web UIの画面サンプル（接続ページ） Web UIの画面サンプル（テーブルビュー） データベースの中身を気軽に閲覧したり、テーブルの値をGUIで編集する、SQLを実行するなどの機能を持った軽量なDBのwrapperツールとなっています。以前は自力でこのようなツールを作るのは工数的に難しかったのですが、生成AIの力を借りることで要件の緩い社内ツールであれば数日で作成できるようになっていて大変ありがたい限りです。 なお、RDS方式はNeonと比較すると新しいデータベースを作るのにかかる時間は少し大きくなっています。これはdump/restoreで複製を行っているためで、現状は最大4分程度かかっています。データ量が増えるとCopy on Write方式でクローンするNeonに優位性が出る可能性もあり、このあたりは利用実体を確認しながら都度調整していく必要があると考えています。

こんにちは、ミイダス Tech Officeです。 ミイダス株式会社のテックチームが直近で開発した機能を現場のエンジニアから共有する「MIIDAS Tech LIVE」。 第14回目の開催となる今回は2つのリリース情報をお届けしました。 採用マッチングサービス「ミイダス」は、独自の診断ツールで採用のミスマッチを減らす中途採用サービスです。メインの採用関連の機能に加え、診断や研修、組織サーベイの支援金の検索機能など、幅広い機能開発が行われています。 MIIDAS Tech LIVE #14 (2026/06/24 12:00〜) ## 📢 概要 MIIDAS Tech LIVEでは、ミイダス株式会社のテックチームが直近で開発した機能を現場のエンジニ miidas-tech.connpass.com