kickflow でエンジニアをしている川島です。
2026年7月、kickflow の全 API レスポンスを支えるシリアライザ約190ファイルを、ActiveModelSerializers（以下 AMS）から Alba へ一斉に切り替えました。
この記事では、大規模な置き換えを壊さずに進めるために何をしたかを、時系列で紹介します。
続きを読むDisk I/O Budget 枯渇と監視を作り直した話
新規事業本部でバックエンドエンジニアをしている渡辺です。
本記事では、検証用の Preview 環境で起きたDB障害の調査と、監視を作り直すまでの記録をまとめます。
ひとことで言えば、DB が急に詰まってログインなどが不安定になった障害です（本番の実ユーザーへの影響はありません）。
学びが多かったのは復旧よりも、主要メトリクスが正常に見えて原因特定に遠回りした過程でした。
- 1. 前提となるアーキテクチャ
- Disk I/O Budget という別軸のリソース上限
- 2. 何が起きたのか（症状）
- 3. なぜ「DB は正常」と読み違えたか
- 4. ログとメトリクスを時系列で突き合わせる
- 5. 仮説としての障害の連鎖
- 確度の整理
- 6. 実施した対応と、残した課題
- 7. 監視を異常が判断できる形に作り直す
- Before / After
- 8. おわりに
kickflow QAチームの「AI実行」
こんにちは、kickflow QAチームのNです。
kickflowのQAでは、機能変更ごとに用意したテストケースを、QAチームが内製したテスト管理ツール「KickRail」で管理しています。
KickRailを作った背景や仕組みについては、以前の記事「テスト管理ツール「KickRail」を内製した話」で詳しく紹介しています。
最近は、実行条件が整ったテストケースの一部をAIに実行してもらっています。
私たちはこの取り組みを「AI実行」と呼んでいます。
この記事では、AI実行で何をしているのかと、AIの結果をQA担当が使える形にするための工夫を簡単に紹介します。
続きを読むTROCCOで開発生産性の指標を小さく始めてみた
こんにちは。CREチームの西山です。
kickflowでは開発チームの生産性の指標として、GitHub GraphQL API から取得したプルリクエスト（以下、PR）数などの計測・集計を今期から始めました。
開発チームのマネージャーからの依頼を受け、CREチームでTROCCOを使ってデータ基盤を整備した事例をご紹介します！
計測のゴール
開発生産性の文脈では、いわゆる「Four Keys（デプロイの頻度、変更のリードタイム、平均修復時間、変更失敗率）」で評価しているチームもあるのではないかと思います。
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
いきなり Four Keys を導入するのではなく、まずは小さく計測を始めてみることにしました。
今回はエンジニアごとのPR数とAI活用度を計測対象としています。
レビューもチケット管理もAIと仕組みに任せる ─ 開発チームから作業を減らす仕組みのつくり方｜AI DevEx Conference 2026 登壇レポート
こんにちは。kickflowでエンジニアリングマネージャをしている森本です。
AIでコードを書く速度が上がっても、レビューやチケット管理といったコーディング以外の「作業」は自動では減りません。 kickflowの開発チームは、この作業をAIと仕組みに任せてきました。 例えば、影響の小さいPRのレビューとマージはAIに任せ、マージまでの滞留時間は約5時間から26分になりました。
この取り組みを、2026年7月22日に開催されたAI DevEx Conference 2026で「開発チームから作業を減らす仕組みのつくり方」というタイトルで発表しました。
本記事では、発表の概要と、スライドには書いていない裏話や補足を紹介します。
続きを読むVitest 組み込みの VRT を kickflow で動かしてみた
こんにちは、kickflow でエンジニアをしている芳賀です。
kickflow のフロントエンドは、Nuxt と Vuetify で構築しています。 コンポーネントテストは happy-dom の上で動かして挙動を検証していますが、スタイルはテストの対象外です。 つまり CSS やテーマの変更で見た目が崩れても、型チェックにもテストにも引っかからず、人の目だけが頼りです。 Vuetify のバージョンアップのたびに「どこか崩れていないか」を目視で追うのは、正直つらいですよね。
そんな折、Vitest 4 に VRT（Visual Regression Testing）が組み込まれたと知り、調査から PoC まで一気にやってみました。 結論から書くと、VRT 専用の小さなプロジェクトを 1 つ足すだけで動きました。 ただ、途中で 4 回転びました。 この記事はその記録です。
続きを読むMetabase MCPの「たぶん」を減らすために、dbtの資産を活かしてセマンティックタイプを整備した
こんにちは。CREチームの西山です。
最近は業種や職種を問わず、AIが様々な業務で活用されるようになってきましたが、kickflowでは全社員にClaudeアカウントが付与されていることもあり、データ分析の現場でもAIを使う場面が増えてきました。
今回は、AIを使った分析の精度をさらに高めるために、Metabaseにセマンティックタイプとメタデータを整備した話を紹介します。
データ分析における課題とMCP利用の広がり
kickflowのデータ分析基盤のスタックは、データウェアハウスにBigQuery、BIツールにはMetabaseを使用しています。
各チームの分析者は、プロダクトの機能改善や新規機能の検討、顧客のヘルススコアの把握などの業務でデータ分析を行っています。 UIでクエリを構築できるMetabaseのクエリビルダーを使うこともあれば、SQLを直接書いて集計や分析を行うこともあります。
一方で、分析者向けにデータウェアハウス上にあるテーブルの定義書などのドキュメントはこれまで整備されておらず、分析者からの依頼を受けてCREチームが分析要件に対するクエリの正当性レビューやクエリの修正などに対応していました。
さらに最近は、社内で利用しているSaaSのMCPの導入や利用が積極的に行われており、Metabase MCPも分析者の間で積極的に使われるようになっていました。 ただ、Metabaseのテーブルに特別な付加情報を与えていたわけではないため、MCPが返す回答はデータ構造から解釈した「想定」の域を出ません。
AI利用による分析を加速させるためには、この「想定」から脱却してより精度を高める必要が出てきました。
続きを読む