はじめに
kintoneは、エンタープライズ企業が全社基盤として採用することを想定し、その運用に必要な機能やオプションを提供しています。
本記事では、kintoneのエンタープライズ企業への導入支援で得られた実績・知見をもとに、設計・運用・性能面の技術的なポイントを整理して紹介します。
解説動画
目的
kintoneは部門単位や業務単位での迅速なアプリ構築に強みをもつプラットフォームとして評価されてきました。
一方で、全社規模での利用を想定する場合には、レコード件数の増加、同時アクセス数の拡大、複雑な業務要件への対応など、設計および運用面で考慮すべき技術的なポイントが増えてきます。
これからkintoneを全社基盤として活用することを検討している方、およびすでに導入済みで利用範囲の拡大を計画している方に向けて、本記事が技術的な判断材料の一助となることを目指しています。
cybozu.comアーキテクチャ
cybozu.com構成概要
cybozu.comは、サイボウズが運用するSaaS基盤として提供されています。
そのため、インフラ構成や性能を利用者が個別に設計・検証する必要はなく、基盤の運用や管理はサイボウズが責任を持って行っています。
cybozu.comは、インフラリソースを複数のお客様が共有するマルチテナント方式を採用しています。
また、cybozu.comで提供している各サービス(kintoneやGaroonなど)ごとに大量のリソース(CPU、メモリなど)が必要となることから、基盤上には各コンポーネントのインスタンスが多数稼働しています。
2025年からKubernetesや分散ストレージ、および内製ソフトウェアを採用した新しいアーキテクチャへ移行し、柔軟なリソース配分が可能になりました。
これにより、サービス単位での負荷分散やリソース最適化が実現し、安定したパフォーマンスの提供とスケーラビリティの向上に寄与しています。
特にストレージにおいては、サーバーがもつローカルNVMe SSDを直接利用することで、高いIOPSと極めて低いI/Oレイテンシを実現しています。
また、ハードウェアとソフトウェアによる自動修復(オートヒーリング)のしくみが導入されているので、可用性が高く、サービスの成長に合わせて機動的にスケールできます。
システム構成・スケーラビリティ
Kubernetesクラスタ方式の採用により、kintoneの成長に合わせた機動的な運用が可能です。
利用状況に応じてアプリケーションサーバーを複数台用意する構成にできるほか、cybozu.comで提供している各サービス(kintoneやGaroonなど)ごとに、リソース(CPU、メモリなど)を割り当てることが可能となっています。
本図はシステム構成の一部を抜粋したイメージです。
冗長構成などの詳細は含まれていません。
ストレージのI/O性能
cybozu.comのストレージ基盤では、NVMe SSDやHDDなど、特性の異なる複数種類のストレージを提供しています。
特に高い処理能力が求められるkintoneのデータベースでは、ネットワークを介する外部ストレージではなく、物理サーバーが直接搭載しているローカルNVMe SSDを活用しています。
自社開発のソフトウェアを通じてローカルディスクを直接利用することで、ネットワークによるオーバーヘッドを排除し、高いIOPS(1秒あたりの読み書き回数)と極めて低いI/Oレイテンシを実現しています。
このアーキテクチャの刷新により、大量のデータ処理を伴うkintoneのバックエンド処理が劇的に高速化されています。
本図はシステム構成の一部を抜粋したイメージです。
冗長構成などの詳細は含まれていません。
稼働実績
cybozu.comは、99.99%レベルの高い稼働率で運用されており、基盤の可用性はサービスとしてサイボウズが責任を持って管理しています。
毎月の稼働率および定期メンテナンスダウンタイムの実績については、稼働実績ページを参照してください。
cybozu.com:稼働実績
稼働率
| 月 | ログイン | サイボウズ Office | Garoon | kintone | メールワイズ | サイボウズドットコムストア |
|---|---|---|---|---|---|---|
| 2026年2月 | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% |
| 2026年1月 | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% |
| 2025年12月 | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% |
| 2025年11月 | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% |
| 2025年10月 | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% | 99.99% |
ダウンタイム
| 月 | ログイン | サイボウズ Office | Garoon | kintone | メールワイズ | サイボウズドットコムストア |
|---|---|---|---|---|---|---|
| 2026年2月 | 1分 | 14分 | 21分 | 1分 | 12分 | 0分 |
| 2026年1月 | 1分 | 16分 | 1分 | 1分 | 14分 | 0分 |
| 2025年12月 | 2分 | 57分 | 10分 | 2分 | 20分 | 1分 |
| 2025年11月 | 1分 | 14分 | 6分 | 1分 | 11分 | 0分 |
| 2025年10月 | 1分 | 14分 | 3分 | 1分 | 11分 | 0分 |
上表は2026年2月時点での稼働実績となります。
データスケール
レコード件数の考え方
kintoneにおけるレコード件数の制約について、1アプリあたり100万件が限界というイメージを持たれているケースがあります。
実際には、適切に設計・運用することで、100万件規模のデータでも問題なく運用できます。
そのため、100万件を超えるなら検討対象外と早期に判断してしまう必要はありません。
大量データを前提とした業務設計や将来活用まで視野に入れることが重要で、kintoneの価値をより高めることが可能です。
近年注目されているAI活用やBI活用においては、十分なデータ量の確保が前提となります。
kintoneを単なる業務アプリケーションとしてではなく、信頼性の高いデータソースとして位置付けることで、その価値を高めることができます。
- AIに学習・推論させるためのデータソースとして
- BIで分析するための中間データとして
- 傾向分析や予測モデルの元データとして
最も重要なのは、これらのデータを現場レベルのメンバーも容易に参照・活用できる状態にしておくことです。
日常業務の中でkintoneにより整理・構造化されたデータは、そのままAIや分析基盤へ連携できる点に大きな意味があります。
また、「1つのアプリに大量にデータがあればよい」という考え方ではなく、用途ごとに適切にアプリを分け、データ構造を整理しておくことが重要です。
そうすることで、AIが参照すべきデータソースを特定しやすくなり、より精度の高い活用が可能になります。
kintoneは単なる業務アプリではなく、将来的なAI活用や高度な分析を見据えたデータ基盤としても位置付けられる存在です。
中長期的なデータ活用の視点で導入いただくことが大切になります。
| 項目 | 説明 |
|---|---|
| これまでのkintone | スタンダードコースなど、これまで1つのアプリに保存できるデータ件数の上限が100万件であると認識されていた |
| これからのkintone |
|
警告
保存可能なレコード件数と、実運用における操作性能は必ずしも一致しません。
アプリ設計、一覧ビューの条件、検索クエリ、フィールド構成、カスタマイズ、アクセス権の内容、APIのデータ取得条件によっては、応答性能に影響する場合があります。
API実行制限
API実行回数の上限
| コース | 制限 |
|---|---|
| スタンダードコース | 1日あたり1アプリにつき最大1万リクエスト |
| ワイドコース | 1日あたり1アプリにつき最大10万リクエスト |
スタンダードコースをご契約の場合、APIの実行回数上限が、「1日あたり1アプリにつき最大1万リクエスト」までとなります。
一方、エンタープライズ向けに提供している「ワイドコース」では、APIの実行回数上限が拡張されており、「1日あたり1アプリにつき最大10万リクエスト」までAPIを実行できます。
APIの実行回数上限が必要な理由
cybozu.comは、インフラリソースを複数のお客様が共有するマルチテナント方式を採用しています。
このため、APIの実行回数上限は、kintoneを安定して提供するためのしくみとして設けられているものとなります。
また、上限回数を超えるAPIリクエストが他のユーザー環境に重大な影響を及ぼす恐れがある場合には、API処理を中断することがあります。
APIの実行回数が上限を超える原因
APIの実行回数上限を超過する主な原因としては、不要なAPIリクエストの発生や設計上の問題が挙げられます。
たとえば、同じデータを繰り返し取得する、画面表示や操作のたびにAPIを呼び出すなど、必要以上にリクエストを発生させているケースが多い状況です。
上限超過は必ずしも利用状況の多さが原因とは限りません。
実装や運用に起因するケースも多いため、不要なAPI呼び出しの削減や処理の最適化といった対策が必要になります。
同時実行数の制限
APIの同時実行数は、ミリ秒単位の瞬間的なリクエストの重なりを指します。
そのため、APIが適切に設計され、過度な並列処理や長時間を要する処理を発生させない構成の場合は、エラーが発生するケースは多くありません。
数千人から1万人規模のユーザーが同時にシステムを利用する場合も同様です。
kintoneでは、1ドメインあたり同時に実行できるREST APIリクエスト数に上限が設けられており、目安として同時に処理可能なリクエスト数は、約100並列までとなっています。
この上限を超えてリクエストが送信された場合、「429 Too Many Requests」エラーが返却されます。
このエラーはシステム停止を意味しません。
過剰な同時リクエストを一時的に制御するためのスロットリング制御です。
時間を置いて再試行することで、多くの場合は正常に処理が継続されます。
本図は並列処理、長時間を要する処理をイメージした図となり、実際のシステム構成ではありません。
429 Too Many Requestsエラー事例
kintoneを20,000ユーザー規模で受注管理システムなど多岐にわたり利用している企業環境におけるkintone利用状況の一例になります。
本環境では、ピーク時間帯には1分間あたり約1,600件のAPIリクエストが発生しているものの、「429 Too Many Requests」エラーの発生は確認されていません。
大規模利用の場合も、利用用途が複数の業務に分散し、特定の1アプリにリクエストが集中しない構成なら、安定してAPIを実行できることを確認しています。
本データはお客様の利用状況に関するものですが、事例としての公開については、該当のお客様より許可を取得しています。
アプリ設計
大規模利用における設計ポイント
kintoneでは、信頼性と実績をもつリレーショナルデータベースを採用していますが、製品特性上、レコード件数が大規模になる場合には、事前の設計および運用面での配慮が重要となります。
特に、レコード件数が多くなるアプリでは、アプリのフィールド設定、アクセス権設計、レコード一覧の最適化などを適切に行わない場合、一覧表示やAPIの応答時間に影響する可能性があります。
100万レコードを超えるエンタープライズ環境での利用にあたっては、将来的なデータ量の増加を見込んだ設計を推奨します。
アクセス頻度が極めて低い場合や、API処理が限定的な場合はこの限りではありません。
しかし、安定運用のため設計として意識することが重要です。
kintoneの性能に関する詳細は、エンジニア向けに公開している「大規模運用のためのパフォーマンス設計ガイド」「パフォーマンス」および、kintone SIGNPOSTの「性能上の考慮点と改善策」も合わせて参照してください。
- cybozu developer network:kintone大規模運用のためのパフォーマンス設計ガイド
- cybozu developer network:パフォーマンス
-
kintone SIGNPOST:性能上の考慮点と改善策
エンタープライズ向けオプション
エンタープライズ向けに提供している「ワイドコース」では、リクエスト数や応答時間などのメトリクスを可視化し、システムの状況を把握できる「性能ダッシュボード」を提供しています。
さらに、kintoneアプリの一部機能の動作仕様を変更することで、レコード一覧表示など特定の操作の性能を向上させることができる「性能カスタマイズオプション」を提供しています。
性能ダッシュボード
性能ダッシュボードでは、各アプリや環境全体のパフォーマンスをモニタリングできます。
環境全体の負荷状況、リクエスト数、応答時間などの主要なメトリクスを、時系列グラフで確認できます。
これにより、アクセスが集中する時間帯や処理速度などの状況を可視化し、システムの稼働状況を把握できます。
性能カスタマイズオプション
kintoneアプリの特定の機能の動作を変更する代わりに、特定の操作の性能を向上させるための複数の性能最適化オプションを提供しています。
kintoneアプリのレコード削除やアプリ設定の見直しといった運用変更を行うことなく、既存の業務構成を維持したままパフォーマンスを引き出すことが可能です。
業務プロセスやデータ蓄積方針を変更せずに性能課題へ対応できるため、現場への影響を最小限に抑えながら、大規模の利用にも耐えうる安定した運用を提供します。
オプション例:レコード一覧表示用のデータ取得リクエストをリードレプリカに対して実行する
「レコード一覧表示用のデータ取得リクエストをリードレプリカに対して実行する」オプションを有効にすると、レコード一覧表示のデータ取得をリードレプリカに対して実行し、データベースにかかる負荷を分散し、軽減できます。
上記は性能カスタマイズオプションの一例です。他にも性能を向上させるためのオプションを提供しています。
外部システムのアプリ化
kintoneでは、外部システムで管理されているデータを、アプリ上からリアルタイムに参照・更新できる機能を提供しています。
これにより、これまで外部システムでしか管理できなかったデータを、kintoneへコピーすることなくリアルタイムに活用できます。
外部システムのデータは、kintoneアプリのレコード一覧画面で確認したり、レコード編集画面から編集したりできます。
また、外部システムのデータを参照元とした「ルックアップ」の設定や、「関連レコード一覧」の設定も可能です。
たとえば、kintone以外の環境に基幹システムやデータウェアハウスなどを構築している場合でも、kintoneへデータを移行する必要はありません。
外部システムにあるデータをアプリ上からリアルタイムに参照・更新できるため、既存のシステム構成を維持したまま、kintoneを業務アプリケーションのフロントエンドとして活用できます。
また、大量のデータをkintoneへ取り込む必要がなくなるため、kintone側のデータ量増加によるパフォーマンスへの影響を抑えながら、外部システムのデータを効率的に活用できます。
性能ダッシュボード、性能カスタマイズオプション、外部システムのアプリ化については、ワイドコース専用機能紹介ページも合わせて参照してください。
ワイドコース専用機能
今後の予定
分散型データベースを活用したアプリケーション構成を実現することで、数百万レコード規模でも安定した運用を支援するオプションの提供を予定しています。
本オプションと、性能カスタマイズオプションを組み合わせることで、より多くのアクセスや大量のレコード登録が発生する環境下においても、安定した運用が可能となる予定です。
警告
本内容は現時点の予定です。
変更・延期または中止となる場合があります。
おわりに
kintoneを特定の用途に特化したツールとして扱うという出口戦略は依然として有効ですが、高性能オプションやインフラ構成の最適化により、対応可能な規模の上限は以前よりも高く、柔軟になっています。
これにより、大企業での全社利用を前提とした運用やスケールにも対応しやすくなってきています。
kintoneには、現場で使いやすいという大きなメリットがあります。
業務改善をスピーディに進められる点にも高い価値があります。
さらに、蓄積された業務データは単なる保存にとどまりません。AIの学習・推論用のデータソースや、BIで分析するための中間データ基盤としても活用できます。
加えて、十分なデータ量と適切な設計がなされていれば、傾向分析や予測モデルの元データとしての活用も視野に入ります。
単なる業務アプリ基盤としてではなく、将来的なデータ活用基盤としての位置付けまで含めて設計することが求められます。
kintoneの強みと特性が明確な用途に適した高い実用性をもつツールとして位置付け、適材適所で活用していくこと。
それが、より複雑化するIT環境において、効果的かつ持続的に価値を生み出していくために必要だと考えています。
kintoneの導入をご検討中の方へ
ご利用環境や運用要件に合わせた導入方法をご案内します。
大規模運用における設計やセキュリティ、ガバナンスなどもサポートしています。
次のリンクからお気軽にご相談ください。
kintone導入相談窓口
