【ITニュース解説】The Sheet Outlives AppSheet. Check That Its References Do.

AppSheet（アップシート）は、Google WorkspaceのGoogle Sheet（グーグルシート）のようなスプレッドシートをデータ元として、手軽にアプリを作成できるツールだ。似たようなツールにMicrosoft Power Apps（マイクロソフト パワーアップス）があるが、これとの大きな違いは、AppSheetがデータをGoogle Sheetに直接保存する点にある。Power AppsがデータをDataverse（データバース）という専用のリレーショナルデータベースに保存するのに対し、AppSheetは誰もがアクセスできるファイル形式でデータを手元に残せるため、「アプリのサブスクリプションを停止してもデータは手元に残る」という利点がよく語られる。これは一見すると非常に魅力的な点だが、本当にGoogle Sheetに残されたデータが、アプリがなくなった後も以前と同じ意味を保ち続けるのか、という疑問が残る。

この疑問の答えは、残念ながら「必ずしもそうではない」ということになる。AppSheetはGoogle Sheetにデータを書き込む際、単なる文字列や数値だけでなく、アプリ独自の形式で情報を記録することがある。このため、アプリが利用できなくなった後、スプレッドシートに残されたデータの中には、そのままでは意味をなさなくなったり、利用が難しくなったりする種類のものがある。

具体的には、AppSheetがGoogle Sheetに書き込むデータで注意すべきなのは、主に三つの種類だ。一つ目は、他の行を参照するための「Ref（リファレンス）列」だ。これは、例えば「顧客」テーブルの顧客IDを「注文」テーブルの顧客列に記録することで、どの顧客がどの注文をしたかを示すような関係を表現する。アプリが存在する間は、AppSheetがこの参照を管理してくれるが、Google Sheet自体には参照の整合性を保つ機能がない。つまり、参照先の顧客がGoogle Sheetから直接削除されても、注文テーブルに残された顧客IDはそのまま残ってしまう。これを「孤立参照」と呼び、アプリがなくなると、この孤立参照が指す先が存在しないため、データとしての意味が失われる。

二つ目は、複数の参照をリスト形式で保持する「EnumList of Ref（イーナムリスト・オブ・リファレンス）列」だ。これは、「P1 , P2 , P7」のように、複数のキーが特定の区切り文字（カンマとスペース）で連結されて一つのセルに保存される。普通のプログラムでカンマだけで分割しようとすると、例えば「Smith, John , Doe, Jane」のようなデータが正しく分割できず、意図しない結果になる可能性がある。AppSheetが使う特定の区切り文字を知らないと、これらのデータを正確に読み取ることができないのだ。

三つ目は、画像やファイルへのパスを保存する「Image or File（イメージ・オア・ファイル）列」だ。AppSheetは、Google Driveに保存された画像やファイルに対し、「Jobs_Images/3f9a1c7e.Photo.jpg」のような相対パスをGoogle Sheetに記録する。このパスは、アプリのデータが保存されているGoogle Drive上の特定のフォルダを基準としたものだ。アプリがなくなると、どのフォルダを基準にすれば良いのかが分からなくなり、結果として画像やファイルを特定できなくなる可能性がある。写真や署名のような、業務上非常に重要なファイルが失われると、データ全体の価値が大きく損なわれてしまうかもしれない。

これらの潜在的な問題を事前に検出し、アプリがなくなった後もデータが健全であることを確認するために、Apps Script（アップススクリプト）というGoogle Workspaceの自動化ツールを使って、スプレッドシート内で実行できる「監査スクリプト」が作成された。このスクリプトは、Google Sheetに保存されたAppSheetのデータを徹底的にチェックし、問題のある箇所を報告してくれるものだ。

監査スクリプトの主要な機能は、データの参照整合性、リスト形式データの解析、そしてファイルパスの解決という三つの柱からなる。まず、データの参照整合性をチェックするために、各テーブルのキー（ID）をインデックス化する。これは、Google Sheetの各シートをテーブルに見立て、それぞれのキー列からユニークなキーのリストを作成するものだ。このインデックスを利用して、孤立参照（存在しないキーを指している参照）を検出するほか、キー列自体に空白のキーや重複するキーがないかもチェックする。ここで重要なのは、Object.create(null)を使ってJavaScriptの組み込みプロパティ名（例: toString）とキーが衝突するのを防いだり、cell()関数で数値と文字列のキーを区別なく比較できるように文字列に変換してトリムしたりする工夫だ。また、EnumListのリスト形式データを正確に分割するために、AppSheetが実際に使用する「カンマとスペース」という区切り文字を厳密に指定して処理する。

次に、画像やファイルが適切に参照されているかをチェックする機能がある。Image or File列に記録された値が、完全なURLなのか、それともGoogle Drive上の相対パスなのかを判別する。相対パスの場合、指定されたGoogle Driveのルートフォルダ（通常はAppSheetアプリのデータフォルダ）から階層をたどって、目的のファイルが実際に存在するかを確認する。もしファイルが移動されていたり削除されていたりすれば、このスクリプトはそれを「見つからないファイル」として報告する。この処理では、getFoldersByNameやgetFilesByNameといったGoogle Driveの操作関数を使い、パスが指すフォルダやファイルを一つずつ探索していく。

この監査スクリプトの実行は非常に簡単だ。まず、AppSheetのアプリに関連するGoogle DriveのフォルダIDをスクリプト内に設定し、監査対象となるテーブル（シート）のキー列、参照列、リスト列、ファイル列を定義する。その後、スクリプトを実行すると、各テーブルのデータを読み込み、前述のキーのインデックス化、孤立参照の検出、不足ファイルの検出といった一連のチェック処理を自動的に実行する。そして、その結果を「Exit audit（終了監査）」という専用の新しいシートに一覧形式でレポートとして出力する。レポートには、どのテーブルのどの列で、どんな種類の問題が何件発生しているか、そして最初の5件のエラー内容が具体的な行番号と共に表示されるため、問題の全体像を把握し、修正が必要な箇所を素早く特定できる。

監査を行う上でいくつかの注意点もある。例えば、AppSheetのGoogle Sheetで列の名前を変更しても、スクリプトはそれが欠落した列とは判断せず、エラーになるだけで問題が報告されない可能性がある。スクリプトはこのような場合にエラーを発生させるように設計されているが、問題の報告を見逃さないようにする必要がある。また、Google Driveでは同じ親フォルダ内に同じ名前のフォルダを複数作成できるため、getFoldersByNameが意図しない方のフォルダを返してしまい、ファイルが実際には存在するのに「見つからない」と報告されるケースも考えられる。さらに、大量の画像ファイルをチェックする場合、Google Driveへのアクセス回数が多くなり、スクリプトの実行時間制限に引っかかる可能性もある。

AppSheetの「アプリがなくなってもデータは残る」という主張は、AppSheetの最も強力な利点の一つであることは間違いない。しかし、そのデータが、アプリが提供していたのと同等の「意味」を保ち続けるかどうかは、今回の監査スクリプトで検証する価値が十分にある。一度の実行と一枚のレポートシートで、アプリのサブスクリプションを解約した後、手元に残るのが価値のある記録なのか、それとも意味をなさない参照の山なのかを知ることができるだろう。もし厳密な参照整合性が必要なデータモデルであれば、この監査の結果は、Dataverseのような真のリレーショナルデータベースへの移行を検討するきっかけになるかもしれない。