記事のサマリー（TL;DR）
- 8年8ヶ月・2,699件の Garoon エスカレーション問い合わせを Claude で分類。環境判定できた案件の73.5%（1,500件）がオンプレ版
- オンプレ案件の約3割がDB・性能・インフラ系。「Too many connections」「Lock wait timeout」「PHP メモリ不足」の3パターンが頻出
- 新規 Garoon 契約の86%はすでにクラウド版を選択。オンプレ版は販売・サポート終了が告知済みで、長期的な移行検討が必要
kintone × AI 分析の構成が示す、社内データ活用の現実的なアプローチ
サイボウズ社内でこの分析が成立した背景として注目すべき点は、約2,700件の調査履歴が kintone アプリで構造的に蓄積されていたことです。テキストデータが散在するファイルサーバーや Slack スレッドにあったとしたら、Claude への一括投入はそもそも難しかった。kintone のようなローコード型データベースを「社内ナレッジの一次格納場所」として活用し、そこに AI を接続するという構成は、業務 SaaS 導入企業が生成 AI を実務に組み込む際の現実的な出発点を示しています。
また、問い合わせ要約（summary）だけでは判別率が24.5%にとどまり、本文・スレッドコメントを段階的に追加して75.6%まで引き上げた試行錯誤のプロセスは、AI 分析の精度がインプットの設計に大きく左右されることを端的に示しています。「まず動かしてみて、精度を見ながら入力情報を追加する」という反復的なアプローチは、どの業種の社内データ分析にも応用できます。
詳細
データと分析方法
分析対象は、サイボウズ社内の「Siriusチーム」が管理する Garoon エスカレーション調査履歴です。
| 項目 | 値 |
|---|---|
| 分析対象期間 | 2017年10月〜2026年6月（約8年8ヶ月） |
| 総件数 | 2,699件 |
Siriusチームはカスタマーサポートの1次受けでは解決しきれない深掘り調査が必要な案件を担当するチームです。全2,699件の問い合わせを以下の2軸で Claude に分類させました。
- カテゴリ分類：Claude にカテゴリ体系の案（メール／DB・性能・障害／バージョンアップ／ワークフローなど20カテゴリ）を出してもらい、確認・調整した上で各レコードを1つに振り分け
- 環境分類：オンプレ／クラウド／不明の3区分で Claude が判定
環境判別率の推移
最初は「問い合わせ要約（summary）だけで分類できる」と想定していましたが、要約に環境を示すキーワードが書かれていないケースが大半で、判別率は24.5%にとどまりました。そこで段階的に情報源を追加するアプローチに切り替えました。
| 入力データ | 判別率 |
|---|---|
| 要約のみ | 24.5% |
| ＋ 問い合わせ本文（先頭2,000字） | 59.5% |
| ＋ 調査スレッドの先頭3コメント（最大2,500字） | 75.6%（2,040件） |
判別シグナルとして、オンプレなら「パッケージ版／マイナーバージョン明記／DB分割構成／db_error.log への直接言及」、クラウドなら「サブドメイン名／ドメインID（c+数字）／cybozu.com／クラウド移行ツール」などを根拠として使用。残り24.4%は「Garoon の仕様確認」「API 仕様の問い合わせ」など、そもそも環境を問わない案件が大半でした。
なお、ランダムサンプリングで中身を目視確認したところ AI の判定はおおむね妥当とのことですが、厳密な一致率は算出していないため、記事中の数字は「おおよその目安」として読む必要があります。
結果1：Siriusに上がる案件はオンプレが多い
環境を判定できた2,040件のうち、73.5%（1,500件）がオンプレ版、26.5%（540件）がクラウド版でした。
ただし、これは Garoon の問い合わせ全体の比率ではありません。問い合わせはオンプレ・クラウドともにカスタマーサポートチームが1次受けし、そこで解決する案件が大半を占めます。Sirius に上がるのは深掘り調査が必要な案件だけです。この数字は「深掘り調査が必要になる案件の中での比率」として読む必要があります。
年別の推移では興味深い動きもあります。2018〜2022年はクラウド比率がおおむね18〜25%で推移していましたが、2023年以降は30%を超えるようになりました。クラウド契約数の増加に加え、移行ツール関連やクラウド特有事象の調査が増えていることが背景です。
なお、新規に Garoon を契約するユーザーのうち 86%がクラウド版を選択しており、Garoon 全体としてクラウドへのシフトが進んでいます。
結果2：オンプレで目立つのはDB・性能系
カテゴリ別の比率を比較すると、オンプレとクラウドの違いが明確に現れました。
| カテゴリ | オンプレ | クラウド | 差 |
|---|---|---|---|
| DB・性能・障害 | 20.3% | 8.3% | 約2.4倍 |
| メール | 14.3% | 22.6% | — |
| バージョンアップ | 12.9% | 10.0% | — |
| インフラ | 8.3% | 2.2% | 約3.8倍 |
| メッセージ・掲示板 | 5.4% | 7.0% | — |
| ワークフロー | 4.7% | 10.9% | — |
オンプレで突出しているのは「DB・性能・障害」（20.3%）と「インフラ」（8.3%）。両方合計すると、Sirius に上がるオンプレ案件の約3割がインフラ・性能まわりです。
クラウド版ではデータベースやサーバー構成をサイボウズ側で管理するため、その層で出るトラブルが運用者の目に触れません。一方オンプレ版はサーバー環境を自社でコントロールできる反面、利用拡大による負荷増・ハードウェアの経年変化・ミドルウェアのバージョン差異など関わる変数も増えます。これはオンプレという構成上のトレードオフであり、運用の良し悪しの話ではありません。
結果3：オンプレで頻出する性能トラブル TOP3
「DB・性能・障害」カテゴリの中身を見ていくと、毎年同じパターンが繰り返し登場します。
① Too many connections（DB01040）
8年間で最も多く問い合わせ要約に登場したエラーコードです。
症状
- ある時刻を境に Garoon 全体が応答不能になる、または DB01040 のエラー画面が表示される
- db_error.log（Garoon 6.17.0 以降は garoon.log に集約）に
Too many connectionsが大量出力される
主な原因
- 同時接続ユーザー数の増加に対し、MySQL の
max_connectionsが不足している（朝の始業時間帯など、アクセスが集中するタイミングで顕在化しやすい） - 一部のスロークエリで接続が長時間保持され、空き接続が枯渇する
- アプリケーションサーバーやネットワーク側で処理が詰まり、DB コネクションが解放されずに溜まっていく
② Lock wait timeout exceeded（DB01205）
特定機能の処理で同じテーブルへの書き込みが競合し、ロック待ちがタイムアウトする事象です。
症状
- 処理が極端に遅くなる、または DB01205 のエラー画面が表示される
- db_error.log に
Lock wait timeout exceededが出る - ひどい場合は連鎖的に Too many connections につながる
主な原因
- 同じテーブルに対する同時更新の競合
- ロック粒度の粗い処理（古いバージョンほど発生しやすい）
- 長時間トランザクション
③ PHP Fatal error / メモリ不足によるスローダウン
DB エラーは出ないものの、アプリケーション側のメモリが不足して処理が中断されるパターンです。
症状
- 画面が真っ白になる
- error_log に
PHP Fatal error: Allowed memory size of N bytes exhaustedが出る
主な原因
- メールの大量データ処理・添付ファイルの一括ダウンロード・大量データの CSV 書き出しなどでの
memory_limit超過
3パターンに共通する対策
上記3パターンは症状やエラーコードが異なっても、有効な対策はおおむね共通しています。
1. Garoon を最新バージョンに更新する
バージョンアップでは内部処理の改善が継続的に入っています。テーブルへのロック取得方法の見直し、メモリ処理の改善など、「バージョンアップしただけで直った」というケースも実際にあります。古いバージョンで性能問題が出ているなら、まず最新版へのアップデート計画を立てることが最初の一手です。
2. サーバースペックを利用拡大に合わせて増強する
同時接続ユーザー数の増加に対して CPU・メモリ・コネクション数の上限が追いついていないと、上の3パターンのいずれかとして顕在化します。サイボウズのパートナー様向けサイト「CyPN」にユーザー数ごとの提案構成例や性能検証支援ツールが用意されているので、販売代理店・パートナー様はそちらを参考に実環境に合わせたサイジングを決めることが推奨されています。
3. 大量データ処理は業務時間外に実行する
一斉メール送信・添付ファイル一括ダウンロード・大量データの CSV 書き出しなど、負荷の高い処理は業務時間外に動かす運用にしておきます。
4. ウイルス対策ソフトのスキャン除外設定を確認する
Garoon が使う一時ファイル領域がウイルス対策ソフトに隔離されたり、リアルタイムスキャンの対象になっていると、動作不良・応答遅延・コネクション滞留につながります。CGI ディレクトリ配下・ドキュメントルート配下・MySQL インストールディレクトリ（files フォルダを除く）をスキャン除外に登録しておく必要があります。
オンプレとクラウド、それぞれの向き不向き
オンプレ版が向いているケース
| 観点 | 内容 |
|---|---|
| 閉域ネットワーク・セキュリティ要件 | LGWAN 環境など、外部ネットワークに接続できない要件があるとき |
| コンプライアンス・データ所在の管理 | 法令や社内規程でデータの保管場所を厳密に管理する必要があるとき |
| 更新タイミングを自社で握りたい | 機能変更や検証期間を自社スケジュールでコントロールしたいとき |
| 強いカスタマイズが必要 | サーバー側で踏み込んだカスタマイズや独自の連携処理を入れたいとき |
なお、Garoon オンプレミス版は販売・サポート終了が告知済みです。長期的には移行先の検討が必要になります。
クラウド版が向いているケース
| 観点 | 内容 |
|---|---|
| インフラ管理の負担を軽くしたい | サーバースペックの見直し、ミドルウェアのパッチ適用、バージョンアップ作業などをサイボウズ側に委ねたいとき |
| 性能の予兆検知を任せたい | SRE チームによる継続的な監視・改善に乗っかりたいとき |
| ログ収集の手間を減らしたい | 性能調査のたびにログ取得をしなくて済む環境にしたいとき |
| 新機能を早く使いたい | バージョンアップ作業なしで継続的に新機能を試したいとき |
選び方の整理
| 観点 | オンプレ | クラウド |
|---|---|---|
| セキュリティ・閉域要件 | LGWAN 等の閉域環境にも対応可能 | インターネット接続が前提 |
| 運用負担 | 自社で管理が必要 | サイボウズ側で対応 |
| カスタマイズ | 自由度が高い | 標準機能の範囲 |
| バージョンアップ | 自社のタイミングで制御できる | 継続的に自動更新 |
| 監視・障害対応 | 自社で実施 | サイボウズ側で実施 |
「守らなければならない制約や自由度を重視するならオンプレ、運用負担を最小化したいならクラウド」というのが、Sirius チームとしての切り分けです。