データにも計画が必要です — ストレージ、フォーマット、成長の話

こんにちは、チェウォンです。

前回は3Min APIがどう始まったか — 繰り返される電話、一度きりのバックエンド、散らばったデータ — についてお話ししました。今日はこのサービスを設計するとき、最も多くの時間を費やしたことについてお話しします。

データのことです。

ダッシュボードやリアルタイムアラートのような目に見える機能ではなく、静かだけれどすべての土台となるもの — データがどんな構造で保存され、最終的にどう活用されるか。この部分を初期段階で間違えると、その先のすべてが難しくなります。

会社ごとにデータの保存方法が違う

早い段階で気づいたことがあります。一緒に仕事をするすべての会社が、データの整理方法が違ったのです。物流会社は追跡番号、出発地、目的地、重量といったフィールドを使い、ECサイトは注文ID、商品名、数量、価格を管理します。

同じ業種でもまったく同じ構造を使うケースはほとんどありませんでした。各社のデータベース — 情報が保存されるシステム — にはそれぞれ独自の「スキーマ」がありました。スキーマとは設計図のようなものです。どんな種類のデータがどこに入るか、何が必須か、どんなフォーマットであるべきかを定義したものです。

そのためAPIで連携しようとすると、最初の質問はいつも同じでした。「データフォーマットをどう合わせますか？」

JSON：共通言語

ここでJSONの登場です。初めて聞く方もご安心ください — これから何度も耳にすることになるので、今理解しておくと良いですよ。

JSONは「JavaScript Object Notation」の略です。名前にJavaScriptとありますが、コーディングとは関係ありません。人間とコンピューターの両方が読める、構造化されたデータの書き方にすぎません。

こんな感じです：

{
  "company": "サンライズ物流",
  "order_id": "ORD-20260301",
  "items": 12,
  "delivered": true
}

これだけです。波括弧の中に、左側が名前（キー）、右側が値。軽量で、柔軟で、そして最も重要なのは — APIのデファクトスタンダードだということです。2つのシステムがインターネットを通じて会話するとき、ほとんどの場合JSONで話しています。

3Min APIがJSONをコアデータフォーマットとして選んだのは、この普遍性のためです。取引先がJSONでデータを送り、私たちがJSONで保存し、後でレコードをダウンロードするときもJSONで受け取れます。変換プロセスなし。フォーマット合わせの苦労もなし。

技術的な概念でひとつだけ覚えておくなら、これです。APIとJSONは、ビジネスが成長しパートナーが増えるほど、何度も登場します。

ちょっと待って — JSONをそのまま保存できるの？

いい質問です。はい、できます。JSONを厳格な行と列に変換せず、そのまま保存するよう設計されたデータベースがあります。「ドキュメントデータベース」や「NoSQLデータベース」と呼ばれるもので、MongoDBがおそらく最も有名でしょう。

3Min APIも内部的に同様の方式を使っています。エンドポイントにデータが届くと、JSONペイロード全体を柔軟なドキュメント形式で保存します。従来のデータベーステーブルを事前に定義する必要はありません。受け取りたいデータの形を記述するだけで、残りは私たちが処理します。

でも万能ではない

正直に言いましょう — JSONフォーマットでデータを保存することは、あらゆる状況に完璧なわけではありません。

メリット：セットアップが信じられないほど速い。数分でデータの受信を開始できます。取引先が新しいフィールドを追加しても、何も作り直す必要なく対応できます。生まれつき柔軟です。

デメリット：その同じ柔軟性が、注意しないと問題になり得ます。厳格なスキーマを持つ従来のデータベースには、一貫性を強制するという利点があります。すべてのレコードが同じ形なので、検索、ソート、分析が簡単です。

柔軟なフォーマットでは、データ構造を頻繁に変更すると、レコードごとに形が少しずつ異なってきます。あるものはフィールドが5つ、あるものは8つ。あるものはorder_date、あるものはdate_ordered。時間が経つとこの不整合がデータを扱いにくくします — 特に後で分析しようとするときに。

実践的なアドバイス：本番稼働前に計画を立てる

だからこそ、本番に入る前にサンドボックス環境を十分に活用することを強くお勧めします。

エンドポイントを初めて作るとき、取引先と時間をかけてデータ構造を協議してください。テストデータをやり取りしながら、フィールド名、型、全体的な形が双方にとって正しいか確認してください。サンドボックスはまさにこのために存在します — 何も永続的ではなく、ミスしてもコストがかからない安全な空間です。

双方ともフォーマットが正しいと確信できたら、本番にデプロイしてください。そこから実際のデータが流れます。

そして将来データフォーマットを大きく変える必要が出たら？既存のエンドポイントを変更しないでください。新しいものを作ってください。エンドポイント数に制限はないので、ビジネスに必要なだけ自由に作れます。こうすれば過去のデータはクリーンで一貫性を保ちつつ、新しいフォーマットはフレッシュスタートできます。

大きな視点：データはビジネス資産

ここですべてがつながります。

3Min APIを通じて流れるすべてのAPIコールは、実際のビジネス取引の記録です — 受けた注文、依頼された配送、確定した予約。時間が経つとこれらの記録が積み重なって、価値あるものになります。あなたのビジネスの物語を語るデータセットです。

だからアーカイブ機能を作りました。データをJSONLファイルとしてダウンロードできます — 1行に1つのJSONレコード — そして必要な方法で活用できます。

何ができるかって？思っている以上にたくさんあります：

• ExcelやGoogleスプレッドシートで開いてさっと概要を把握
• BIツール（Metabase、Redash、Google Looker Studioなど）に取り込んでダッシュボードを作成
• AIアシスタントに渡して自然言語で質問
• データアナリストやコンサルティング会社に渡して専門的に分析

目標は単にデータを保存することではなく、インサイトに変えることです。どの商品が最も速く売れているか？どの取引先が最も多くの注文を送ってくるか？事前に計画できる季節的パターンはあるか？

直感ではなく実際のデータに基づいて意思決定すると、ビジネスはより強い基盤の上で成長します。うまくいっていない部分は改善し、うまくいっている部分はさらに強化する。そして大きな決断の時 — 新市場への進出、人員増強、新しいツールへの投資 — 数字が裏付けてくれます。

3Min APIを使うすべてのチームにそうなってほしいのです。AからBへデータを移すパイプではなく、ビジネスを理解し成長させる基盤であること。