記事のサマリー（TL;DR）
- Yakumo チームは EM1名＋エンジニア6名の計7名で、アジア・北米向け kintone.com の全プラットフォームを開発・運用
- 本番／ステージング／開発の3環境に「plane」名前空間を設け、社外ユーザーと社内開発チームの双方に安定した体験を提供
- Kotlin をアプリケーション共通言語に採用し、GitOps（Argo CD）移行・JWT プロキシ・ドメイン横断データストアなどを現在進行形で推進中
kintone 国内利用企業が把握しておくべきグローバル基盤の実態
kintone は国内では「ノーコード業務アプリ」として広く普及していますが、海外版（kintone.com）は国内版とは独立したプラットフォームスタックで運営されています。Yakumo チームの存在が示すのは、同一プロダクトであっても「海外向け SaaS 基盤の設計・運用は別チームが専任で担う」という構造です。
国内で kintone と専用 UI を組み合わせた業務システムを構築・拡張している企業にとって重要なのは、kintone.com の信頼性がこのチームの SLO 監視とオンコール文化に支えられているという点です。マルチテナント特性を踏まえた SLO 見直しが継続的に行われており、特定テナントの負荷に引きずられないサービス品質の確保が設計上の明示的な目標となっています。
また SOC2 監査要件を踏まえた権限管理・責務分担の見直しが進んでいる点は、kintone を業務の根幹に組み込んでいる企業が「ベンダーのコンプライアンス対応状況」を評価する際の参考情報になります。
詳細
Yakumo チームとは
Yakumo チームの正式名称は「サービスプラットフォーム（Yakumo）チーム」。海外市場向けに kintone を提供するプラットフォームエンジニアリングチームで、2018年に立ち上がったプロジェクトを前身とします。チーム名「八雲（Yakumo）」は、クラウドアプリである kintone をクラウド基盤の上で動かすイメージから命名されました。開発用ドメインに .ninja を使うなど、随所に忍者モチーフが散りばめられています。
同チームが所属するプラットフォームエンジニアリング部には、以下の3チームが存在します。
| チーム | 担当領域 |
|---|---|
| サブシステムチーム | ユーザー管理・認証など製品横断機能 |
| サービスプラットフォーム（Neco）チーム | 国内向け複数製品（kintone、Garoon、Mailwise 等）の基盤 |
| サービスプラットフォーム（Yakumo）チーム | 海外向け kintone（kintone.com）の基盤 |
提供している体験
Yakumo チームの利用者は「社外」と「社内」の2種類に分かれます。
社外（kintone.com ユーザー）: https://MY-DOMAIN.kintone.com へのアクセスを通じて、世界中どこからでも kintone 機能を利用できる環境を保証します。
社内（kintone 開発チーム）: 開発中の kintone を本番環境から隔離された開発環境にデプロイする仕組み、E2E テスト環境、開発環境から本番環境までの段階的リリースを Pull Request で管理できるパイプラインを提供します。
其の壱：プラットフォームの提供
3環境×名前空間（plane）による安定運用
Yakumo チームは 本番・ステージング・開発 の3環境を管理しています。とりわけ開発環境は、kintone 開発チームが機能開発フローで日常的に使う環境であるため、”名前は開発環境だが実質的には本番” という性格を持ちます。
この複雑性に対応するため、各環境内に 「plane」という名前空間 を設けています。社外ユーザーや開発チームが利用する Master plane を安定稼働させつつ、インフラ変更の検証は Yakumo チーム専用の開発 plane で完結させます。開発用 plane には忍者をモチーフにした名前が付けられており、並行開発に対応できるよう複数用意されています。
インフラ・ミドルウェアの提供
マルチテナント SaaS の文脈で Yakumo チームが管理するミドルウェアは2種類です。
- Control plane サービス: kintone が正常動作する前提を整えるサービス群。データベーススキーマのマイグレーションサービスや、新規ユーザー向けのドメインプロビジョニングサービスがこれに該当します。
- Application plane サービス: kintone の機能仕様を実現するために協調動作するサービス群。ファイル管理サービス、メール通知サービス、バッチ処理・定期実行タスク管理サービスなどが含まれます。
実装言語の選定: Elasticsearch や Apache Flink をはじめとする JVM エコシステムとの親和性を考慮し、application plane・control plane の両方のコンテナアプリケーションに Kotlin を採用。Gradle のマルチプロジェクトとして統一管理しています。AWS Lambda へのデプロイ用アプリケーションや運用支援ツールには、実行環境への依存の少なさと配布容易性を理由に Go を採用しています。
其の弐：インフラのメンテナンス
プラットフォームの健全性維持のため、Yakumo チームは以下の構成要素を定期的に更新しています。
- AWS サービス: EKS、RDS、OpenSearch Service など
- その他ミドルウェア・クライアントライブラリ: Calico、Gatekeeper など
権限管理も重要な責務のひとつです。各ユーザーのアクセス権は Yakumo チームのみが操作できる kintone アプリで管理しており、その設定を IdP（Identity Provider）に反映する GitHub Actions ワークフローを定期実行することで、権限管理業務を安全・円滑に運用しています。権限管理のツールとして自社製品 kintone そのものを活用している点が特徴的です。
其の参：オンコール対応
アジア・北米を中心に世界複数国の本番ユーザーを抱えるため、Yakumo チームは SLO 監視をベースとした24時間・365日のオンコール体制 を維持しています。「開発から運用まで責任を持つチーム」という思想は、2018年のチーム発足当初から組み込まれており、現在も一貫して続いています。
ページング・エスカレーションには PagerDuty を利用。障害発生時はオンコール担当者が関係各所と連携しながら調査・暫定対応を行い、恒久対応とポストモーテムはチーム全体で実施します。定期的な障害対応訓練も行い、対応フローの形骸化を防いでいます。
マルチテナントアプリケーションの特性上、特定テナントの利用状況に引きずられないサービス品質を実現するため、SLO の継続的な見直しと運用改善にも取り組んでいます。
GitOps 移行（Argo CD）
歴史的に CIOps ベースで運用されてきたデプロイパイプラインを、直近数ヶ月で Argo CD を活用した GitOps ベースのデプロイ基盤 へ移行中です。SOC2 監査要件も踏まえた権限管理・責務分担の見直しと並行して進めています。
働き方と文化
2026年現在、Yakumo チームは EM 1名＋エンジニア6名の計7名 で構成されています。メンバーの勤務地は関東・東海・九州/沖縄と分散しており、全員がフルリモート勤務。現時点では海外拠点在住メンバーはいません。
開発スタイルは Epic ベースのスプリント（1週間）。四半期ごとに取り組む Epic は基本的にチーム自身が選定し、全タスクをチームで工数見積もりしたうえでスプリントに分解します。スプリントイベントはすべてオンラインで、毎日の朝会・夕会に加え、スプリント終了日には PM や部の EM を交えたスプリントレビューとチームふりかえりを実施します。
現在進行中の主要 Epic は以下の通りです。
- GitOps デプロイ基盤の提供: Argo CD 移行によるデプロイ運用性の向上
- JWT 認証を備えた HTTP リバースプロキシ: サービス間連携のセキュリティ・アクセシビリティ向上
- ドメイン横断型データストアサービス: サービス間データ連携の効率化
チームの文化を支える定期的な取り組みとしては、以下が挙げられます。
- Yakumo 合宿: 半年に1回のチームビルディング（2026年6月は静岡市で実施）
- Yakumo 勉強会: コードリーディング、技術書輪読、LT 会など状況に応じたスタイルで実施
- Yakumo 探索 day: 技術調査・試験実装に専念できる日を2週間に1度設定。心理的ハードルを下げることが目的
- KAIZEN: チーム見積もりを通さず任意のタイミングで小改善の PR を出せるルール。後回しにされがちな細かい改善をコードベースに継続的に反映する仕組み