はじめに

2026年8月31日、cybozu.comで障害が発生し、kintoneを含む複数サービスに一時的にアクセスしづらい状況が続きました。

cybozu.com 障害情報

公式発表によると、9:56から発生した内部システムの高負荷により、cybozu.com共通管理・kintone・Garoon・サイボウズ Office・メールワイズなど6サービスで断続的にアクセスしづらい状態となり、12:07に復旧しています。業務でkintoneを使っていた人にとってはヒヤッとする時間だったのではないでしょうか。

この一件で改めて感じたのは、「クラウドサービスだから安心」と「自分のデータを自分で守る」は別問題だということです。この記事では、なぜバックアップが必要なのか、kintoneのデータを実際にどう控えておくのか、そして控えたバックアップを"使える状態"にしておく方法までまとめます。

クラウドだから安心、ではない

kintoneは可用性の高いSaaSで、今回の障害も数時間で復旧しています。裏を返せば「よく出来たSaaSでも、数時間単位でアクセスできなくなることがある」という事実でもあります。しかも守るべきリスクは大規模障害だけではありません。

操作ミスによるレコードの誤削除・上書き
アプリ設定(フィールド・レイアウト・ビュー)の意図しない変更
退職者アカウントの権限整理時の巻き込み事故
障害・誤操作・契約プラン変更など、自分でコントロールできない要因

これらはベンダー側の可用性がどれだけ高くても防げません。「バックアップを取る」というのは、サービスの信頼性を疑うことではなく、自分たちの業務がSaaS 1社の状態に完全に握られないようにするためのリスクヘッジです。

kintoneのバックアップは、実は自分で組み立てるもの

kintoneには「ワンクリックで全部バックアップ」という単一機能はありません。用途に応じて例えば次のように組み合わせて取得します。

レコード、コメント: アプリのレコード一覧画面の「書き出し」からCSVでダウンロード(標準機能)
アプリ設定: REST APIでJSONとして取得
- フォームのレイアウト: GET /k/v1/app/form/layout.json
- フィールド定義: GET /k/v1/app/form/fields.json
- 一覧(ビュー)設定: GET /k/v1/app/views.json

つまり「バックアップを取る」だけでも、CSVが1〜2ファイルとJSONが2〜3ファイルに分かれた状態になります。定期的にこれらをまとめて取得するスクリプトを組んでおく、あるいは連携サービスを使う、という運用が現実的です。

バックアップを"使うタイミング"を先に決めておく — BCPの考え方

バックアップを取って見られるようにしておくのは大事な一歩ですが、それだけでは「kintoneが使えない間、実際に業務をどう回すか」の答えにはなりません。ここは事業継続計画(BCP)として、復旧までにどれくらいかかりそうかで対応を分けて考えておくのがおすすめです。

短時間・復旧が見込めるケース

今回のような数時間規模の障害は、ベンダー側の復旧を待てば元に戻ります。この場合の目的は「復旧するまでの間、必要な情報をすぐ参照できること」で、更新自体は復旧後にkintone側へまとめて反映すればよい、という整理ができます。次に紹介するバックアップビューアは、まさにこの**「kintoneは見れないが、いずれ復旧することが前提」**の構成で作っています。あくまで閲覧のための道具で、その場でデータを更新する機能はありません。

長時間・復旧が見込めない/わからないケース

一方、大規模災害や障害の長期化など「いつ復旧するか分からない」状況では話が変わります。過去のバックアップを閲覧できるだけでは、その間の業務(受注・問い合わせ対応・現場記録など)は止まったままです。この場合に備えて、事前に検討しておきたいこと:

紙やExcel等、オフラインでの一時運用への切り替え基準(どのタイミングで、誰が判断して切り替えるか)
アクセス不能期間中に発生した更新分の記録方法と、復旧後にkintoneへ反映する手順(二重入力・突合のルール)
止めてはいけない業務だけを続けるための代替手段(完全な代替システムでなくてもよい)
バックアップ自体の保管場所(kintoneにもアクセスできない前提なら、社内NASやクラウドストレージなど別経路に置いておく必要がある)

つまり、バックアップビューアは「短時間の不通に対する備え」であって、長期障害・災害時のBCPそのものではありません。両方を分けて、それぞれの基準や手順を事前に決めておくことが大事です。

「取っただけ」で終わりではない — 短時間の不通向けにビューアを作った

上記の「短時間・復旧が見込めるケース」に対する具体的な備えとして、バックアップを取った後どう確認するかをサンプルとして作成しました。障害時に「このCSV、いつのレコードで、どのフィールドがどの値だっけ」を確認するために、わざわざ別のkintoneアプリを作ってインポートし直すのは面倒ですし、そもそも障害中は復元先のkintoneも使えないかもしれません。

そこで、ブラウザだけでバックアップの中身をその場で閲覧できるビューアを作りました。OSS(Apache License 2.0)として公開しているので、自由に使ってもらえますし、Issue・プルリクエストも歓迎です。

サンプルデータを読み込んだ状態のデモはこちらからそのまま触れます。

単一の HTML ファイルなので、ダウンロードしてブラウザで開くだけで動きます。

レコード CSV を読み込むと一覧表示・検索・絞り込みができる
コメント CSV / layout.json / field.json / views.json を追加で読み込ませると、実際のフォームレイアウト通りにフィールドが並び、コメントも紐付いた状態で確認できる
kintoneの日時はUTCで書き出されるため、表示時にローカルタイムゾーンへ自動変換
Webサーバー越しに開けば、URLのクエリパラメータでファイルパスを指定して自動読み込みも可能

使ってみる(GitHubに詳しくなくても大丈夫)

エンジニアでない方向けに、手順だけ書いておきます。

まずは上のデモリンクを開いて、実際の画面を触ってみてください
自分のバックアップファイルで試したい場合は、リポジトリのページを開き、緑色の「Code」ボタン → 「Download ZIP」でファイル一式をダウンロード
ダウンロードしたZIPを展開し、中の index.html をダブルクリック(ブラウザが開きます)
開いた画面の「レコード」欄で、自分のバックアップCSVファイルを選んで「読み込む」を押すだけ

コメント・レイアウト・フィールド・ビューのファイルも同じ画面から選べますが、無くても動きます。プログラミングの知識やサーバーの用意は不要です。

もう少し詳しい使い方(クエリパラメータでの自動読み込みなど)は、リポジトリの README にまとめています。

http://localhost:8000/index.html?records=records.csv&comments=comments.csv&layout=layout.json&field=field.json&views=views.json

レコード CSV だけあれば最低限の一覧・検索は動き、他のファイルを足すごとに表示が正しく・詳しくなっていく作りにしています。サーバーもインストールも不要なので、「バックアップは取ってあるけど、いざという時にすぐ中身を確認する手段がない」を解消するのが狙いです。

まとめ

クラウドサービスの可用性が高くても、数時間のアクセス不能は起こり得る
kintoneには一括バックアップ機能が無く、レコードCSV・コメントAPI・アプリ設定APIを組み合わせて自分で用意する必要がある
取ったバックアップは、いざという時にすぐ中身を見られる状態にしておいて初めて意味を持つ
ただし「すぐ見られる」だけで足りるのは、復旧が見込める短時間の不通まで。長期化・災害時に備えたオフライン運用や代替手段は別途検討が必要

「バックアップを取る」の次の一歩として、「取ったバックアップをすぐ活用できるか」、そして「それでも足りない事態にどう備えるか」まで含めて考えておくと安心です。