【ITニュース解説】Airtable as a Backup Datastore for Orders Nobody Can Afford to Lose

重要なビジネス情報を扱うシステムでは、予期せぬ障害が発生しても情報を失わない工夫が求められる。特に顧客からの注文データのような、一つでも欠けては困る情報は、安全に保管し、必要な時にすぐに参照できる仕組みが不可欠だ。

あるeコマースシステムPikkunaでは、注文確定時に複数の重要な処理を連続して実行する。具体的には、注文が確定すると、顧客管理システム（CRM）への記録、Airtableへのバックアップ書き込み、配送ラベルの発行、会計システムへの仕訳入力など、一連のタスクが自動的に処理される。これらの処理は、注文処理ワーカーと呼ばれるプログラムによって実行される。

この中で、createAirtableRecord(session);というAirtableへの書き込み処理は、一見すると他の重要な処理に比べて地味に見えるかもしれない。しかし、このバックアップの存在には非常に重要な意味がある。

なぜ、すでにデータベースに注文データが存在するにもかかわらず、二つ目の「よりシンプルな」コピーを別の場所に保持する必要があるのだろうか。Pikkunaの主要な注文データはPostgresというデータベースに保存されており、これはアプリケーションや管理画面からアクセスされる「正解のデータ」だ。だが、もしこの主要なデータベースがシステム障害を起こしたり、誤ったデータ移行によって破損したり、あるいは管理画面がエラーで利用できなくなったりした場合を想像してみよう。その時、「注文番号4821は本当に受け付けられたのか、その内容はどんなものだったのか」という疑問が生じたとする。通常、このような状況では、データベースに直接アクセスできるエンジニアが呼ばれ、問題を解決し、データベースから情報を引き出す必要がある。

ここでAirtableのようなツールにバックアップデータがあることの価値が発揮される。Airtableは、ブラウザで簡単に開くことができ、スプレッドシートのように行と列でデータを表示するツールだ。もし主要なシステムがダウンしていても、運用担当者、カスタマーサポート担当者、あるいは経理担当者が、エンジニアの助けを借りることなく、自分たちでAirtableを開けば、瞬時に注文内容を確認できる。SQL（データベースの問い合わせ言語）の知識も、エンジニアを起こす必要もない。これが、この二つ目のバックアップデータストアが存在する最大の理由であり、主要システムが機能不全に陥った際に、非技術者でも迅速に情報にアクセスできるようにする「情報アクセシビリティ」の確保が目的である。

このAirtableに保存されるデータは、「スナップショット」であり、「ミラー」ではないという点も重要である。スナップショットとは、ある時点のデータをそのまま記録したものであり、ミラーとは常に最新の状態を反映するように同期された複製を指す。Airtableに書き込まれる注文データは、注文が確定した瞬間の「顧客情報、購入商品、金額、配送先」など、注文自体が読み取れる最低限の情報を一度だけ書き込む。そして、この情報は一度書き込まれたら、その後は一切更新されない。たとえば、注文後に配送先が変更されたり、商品がキャンセルされたりしても、Airtableのレコードは更新されないまま、注文確定時の状態を保つ。Airtableの役割は、「我々が実際に何を受け付け、何を発送したか」を記録することで、「現在の注文の状態がどうなっているか」を示すことではない。

もし、このバックアップデータを「常に最新の状態に保つ」ために、主要システムでの更新すべてをAirtableにも反映させようとするとどうなるだろうか。それは「第二の完全な統合」を構築することに繋がり、開発や保守の負担が大幅に増大する。さらに、Airtableが「第二の正解データ源」として扱われるリスクを生み出し、常に正しく維持されなければならない大きな保守コストが発生する。スナップショットに含めるフィールドも厳選する必要がある。人間が注文内容を理解するために必要な情報のみを含め、CRMや配送システムの「現在の状態」のような情報は含めるべきではない。それらの情報をコピーすると、誰も監視していない場所で情報が古くなってしまう「データの陳腐化」を引き起こす可能性がある。

このAirtableへの書き込みは、他の重要なシステムとの連携と同様に、システム開発において特に注意すべき課題を抱えている。それは「再試行」に関する問題だ。Pikkunaの注文処理ワーカーは、途中のステップで何らかのエラーが発生して処理が中断された場合、最初から処理をやり直す仕組みになっている。例えば、配送サービスへの連携がタイムアウトで失敗した場合、ワーカーは最初からもう一度実行される。このとき、既に一度成功していたAirtableへのバックアップ書き込みも、再び実行されてしまう可能性があるのだ。

会計システムへの連携の場合、これが二重の仕訳として記録されると、後で経理担当者が銀行取引明細と照合する際に大きな手間がかかり、実際の金銭に関わる問題に発展する。Airtableへの書き込みの場合、金銭的な直接被害はないが、同じ注文に対して二重、三重のレコードがバックアップに作成されることになる。これは決して無視できないバグである。なぜなら、このバックアップデータが作られた唯一の目的は、「エンジニアではない人が、システム障害時に素早く、信頼できる答えを見つけるため」だからだ。もし同じ注文の重複レコードが複数存在していたら、「この注文は本当にあったのか、どちらのレコードが正しいのか」といった判断を、情報を参照する非技術者が迫られることになる。これでは、わざわざバックアップツールを導入した意味が失われてしまう。

この問題の解決策は、「冪等性（Idempotency）」と呼ばれる性質をシステムに持たせることだ。冪等性とは、ある操作を複数回実行しても、一度だけ実行した場合と同じ結果になることを保証する性質を指す。具体的な実装としては、注文ごとに一意のキー（例えば、注文セッションIDから生成されたもの）を事前に用意し、Airtableへの書き込み処理を開始する前に、このキーが既に処理済みであるかどうかを確認する仕組みを導入する。もし、そのキーが既に処理済みであれば、Airtableへの書き込みは行わずに処理を終了する「ガード」を設けるのだ。これにより、ワーカーが何度再試行されても、Airtableには同じ注文のレコードが一度だけ書き込まれることが保証される。金銭的な損害に直結しないAirtableのバックアップであっても、この「信頼性の確保」という観点から、会計システムへの連携と同じ厳密な冪等性の考慮が必要となる。金銭的なリスクが低いからといって、システムへの信頼が損なわれるコストは、決して無視できない現実のコストとなる。

このバックアップパターンは、AirtableやPikkunaのシステムに特化したものではない。注文データだけでなく、署名済み契約書、サポート対応の記録など、主要システムの障害時に失われたりアクセスできなくなったりすると困るあらゆるビジネスイベントに対して適用可能だ。Airtableの代わりに、共有スプレッドシート、Notion、あるいは適切な書き込みAPIを持つ他のツールでも同じ役割を果たせる。重要なのは、データベースクライアントを使わずに、非技術者が情報を人間にとって読みやすい形でアクセスできることだ。

もちろん、この仕組みの導入は無料でできるわけではない。新たな統合ポイントが増えることで、システムの保守対象が増えるというコストも発生する。例えば、週に数件程度の注文しかなく、システム障害が発生してもエンジニアがすぐに手動で対応できるような小規模な運用であれば、このような二重の書き込み経路を構築するメリットは少ないかもしれない。しかし、事業規模が拡大し、手動での対応が非現実的になった時に、このパターンは真価を発揮する。複数のシステムに連携する重要なデータフローを設計する際には、最初からこのような障害時の挙動やデータの信頼性確保を考慮することが、長期的に安定したシステムを運用するために不可欠だ。