結論：仕事のデータをNotionのようなクラウドのサービスに預けていると、たまにAIからそのデータを読めなくなることがあります。サービス側の障害でも、つなぎ込みの不調でも起こります。そこで月に一度でいいので、丸ごと控え（バックアップ）を自分のパソコンに落としておく。このとき、人が目で見るための控えならExcelでよいのですが、「万一のときに元に戻すためだけ」の控えなら、JSON（ジェイソン）という形式のほうが確実です。そして落とすときは、中身（データ本体）だけでなく”器”（項目の定義）も一緒に落としてください。経理でいえば、仕訳データだけを控えて勘定科目マスターを控え忘れる、という事故を防ぐ話です。
■ よくある場面
顧客リスト、案件の一覧、契約の管理表――こうしたものを、Notion（クラウド上の、Excelとメモ帳を足したようなサービス）や類似のサービスで管理している会社は増えています。項目を決めて表にしておくと、AIがそこを直接読み書きできるので、「この行の状況を更新して」と言うだけで済むからです。便利です。
ただし、AIと外部サービスをつなぐ仕組み（MCPと呼ばれる、AIと外のサービスをつなぐ連絡通路のようなものです）は、いつも確実につながるとは限りません。サービス側が落ちることもあれば、認証が切れることもある。そうなるとその日は手が止まります。クラウドそのものが使えなくなる事態まで想定すれば、なおさらです。
だから「読めなくなった日のために、手元に控えを持っておく」。ここまでは誰でも思いつきます。問題は、どんな形で控えるかです。ここを間違えると、控えがあるのに戻せない、ということが普通に起こります。
■ まず分かれ道：その控え、人が見ますか？
ここが全部の入口です。
人が開いて眺めるなら、Excelでいい。見やすさが目的なので、行と列に並んでいるのがいちばんです。
でも「元に戻すためだけ」の控えなら、話が変わります。誰も開かないのだから見やすさは要らない。要るのは、戻したときに一字一句そのままよみがえること、それだけです。
この用途だと、実はExcelは向いていません。Excelのセルは、何を入れても「ただの文字列」になってしまうからです。「空欄」が、もともと空欄なのか、数字を入れる欄がたまたま空なのかも区別がつかない。改行を含む長い文章もセルの中で崩れやすい。戻すときに「これは数字の列だったっけ、文字の列だったっけ」と推測する羽目になります。推測が要る控えは、控えとして失格です。
■ JSONとは何か――構えなくていい話です
JSONは、プログラムがデータをやり取りするときの標準的な書き方です。難しそうな名前ですが、中身はただのテキストファイルで、メモ帳で開けます。
イメージとしては、Excelが「表」なのに対して、JSONは「項目名と値をセットで並べたメモ」です。
取引先名: A社
ステータス: 契約中
月額: 300000
契約終了日: 2027-03-31
こういう組を、件数のぶんだけ並べたものだと思ってください。実際の書き方にはカッコや引用符といった記号が付きますが、読めなくても困りません。人が読むためのファイルではないので、そのままでいいのです。大事なのは、この形なら「300000は数字」「契約終了日は日付」という区別が保たれたまま保存され、そのまま元のサービスに戻せる、という点です。
■ いちばん大事な話：「中身」だけでなく「器」も控える
ここが今回の本題です。
控えを取るとき、多くの人はデータ本体（各行の中身）だけを落とします。でもそれだけでは戻りません。項目そのものの定義――これを「スキーマ」と呼びます――も一緒に落とす必要があります。
経理の言葉に置き換えると、いちばん腑に落ちると思います。
・データ本体＝仕訳データ。「8/20 旅費交通費 1,200円」といった個々の記録
・スキーマ（器）＝勘定科目マスター。どんな科目が存在するか、その一覧そのもの
仕訳データだけをバックアップして、勘定科目マスターを取っていなかったらどうなるか。その期に一度も使わなかった科目が、まるごと消えます。「貸倒引当金繰入」を今期たまたま1本も切らなかったら、仕訳データのどこにもその名前は出てきません。復元した会計システムには、その科目が存在しないことになります。
まったく同じことがクラウドのデータでも起きます。たとえば案件の進み具合を「初回接触／面談済／提案中／交渉中／受注」と定義してあるとして、そのうち「交渉中」の案件がたまたま今1件もなかったとします。データ本体だけを控えていたら、「交渉中」という段階が存在すること自体が控えに残りません。復元した表は、途中がぽっかり抜けた不完全なものになります。ステータスの選択肢、部門の一覧、区分の分類――使用頻度の低いものほど、この穴に落ちます。
だから控えは、中身と器で1セット。難しい操作は要りません。「データだけでなく、項目の定義（スキーマ）も一緒に出して」と一言添えるだけです。
■ 「安いほうがいい」の落とし穴
最近はAIの利用料が気になるところなので、「いちばん安い形式は？」と考えたくなります。実際に手元のデータで測ってみました。同じ中身を別の形式で書いたときの分量です。
・JSON 約75KB ＝100
・CSV／TSV（表形式） 約41KB ＝55
たしかにCSVのほうが半分近く軽い。JSONは項目名を1件ごとに繰り返し書くので太るのです。
でも、ここで安さを取るのは間違いです。
理由はシンプルで、この控えファイルは、普段は一度も開かれないからです。読むのは「クラウドが落ちた日」だけ。しかもそのときはプログラムで読み込んで戻すので、AIに全文を読ませるわけではありません。読まれないファイルの料金を半分にしても、半分になるのはゼロです。
料金が本当に効くのは、控えを取るときではなく、AIにデータを読ませて質問するときのほうです。そしてそこでの正解は形式を変えることではなく、全部を渡さないこと。「今月の分だけ」「この取引先だけ」と絞ってから渡す。ここを直すほうが、形式を変えるより桁違いに効きます。
安さを理由に復元性を捨てると、いざというときに戻せない控えが手元に残ります。それは一番高い買い物です。
■ まとめ
・クラウド（Notion等）に大事なデータを置いているなら、月1回でいいので手元に丸ごと控えを落とす
・分かれ道は「人が見るか」。見るならExcel、戻すためだけならJSON
・JSONはメモ帳で開けるただのテキスト。読めなくてよい。数字・日付・空欄の区別が保たれるのが利点
・中身だけでなく”器”（スキーマ＝項目の定義）も一緒に落とす。仕訳データだけ控えて勘定科目マスターを控え忘れるのと同じ事故が起きる
・形式を「安さ」で選ばない。読まれない控えの安さに意味はない。料金は「渡す量を絞る」で削る
控えは中身と器で1セット。安さの話は、控えるときではなく読ませるときにしてください。
