入力と、その場の確認はAppSheetに任せ、記録の確定とマスタの元データはアプリの外で守ります。任せてよいのは、毎朝用意した行に店舗が数字を入れること、POSとの差額とその理由を式で確かめること、マネージャーの確認と月次のロック、小口現金の申請から精算までの管理です。一方、データの保存先をGoogleスプレッドシートにしたAppSheetでは、シートを編集できる人がアプリを通さずに数字を直せます。アプリのロックも、アプリの中でしか効きません。そこで、シートを編集できる人を絞り、確定した数字は会計ソフトに入れてそちらで締め、店舗や決済手段のマスタは元データ（正本）を1か所に決めます。
この記事の要約
この記事は、はてなベースが経理業務の改善を手がけた、多店舗の飲食チェーン（以下、D社）の事例をもとにしています。D社の店舗では、現金の出入りを紙の帳票や出納帳に書き、本社の経理が写真などで受け取ってExcelに集計していました。そこで、この日報をAppSheetに移す仕組みを作りました。
店舗の現金は、手続をそろえることが統制の出発点になる業務です。実施基準（財務報告に係る内部統制の評価及び監査に関する実施基準）も、多店舗に展開する小売販売業務では手続を定型化する必要があり、現金取扱規程などの手引きが作られる、と例に挙げています。
AppSheetは、Googleスプレッドシートなどのデータをもとに、コードを書かずに入力画面やボタンを作れるGoogleの製品です。以下では、Googleスプレッドシートを「シート」、シートを自動で動かすGoogleのスクリプト（Google Apps Script）を「GAS」と書きます。
店舗の入力と、その場の確認はAppSheetに任せる
店舗が毎日数字を入れる画面と、入れた数字をその場で確かめる式は、AppSheetに任せられます。D社では、本社の経理がExcelに転記していた数字を店舗がアプリに直接入れ、差額の計算から理由の確認、マネージャーの確認までをアプリの中で済ませる設計にしています。
では、店舗は何をどう入力するのでしょうか。D社では、「店舗×日付×決済手段」ごとに1行を持つ「決済別明細」という表を使います。毎朝、GASが店舗ごとに登録された決済手段の数だけ、その日の行を先に作ります。休業日として登録した日は行を作りません。そのため店舗の担当者は、表に並んだ行に、POSの金額と、端末の金額または数えた現金の額を入れるだけで済みます。
なぜ、わざわざ行を先に作るのでしょうか。AppSheetでは、新しい行はフォームの画面から1件ずつ足すのが基本だからです。一方、すでにある行なら、決めた欄だけを一覧や詳細の画面から直接書き換える設定ができます。D社では表の形で毎日入力したいという要望が強かったので、空の行を毎朝用意して差を埋めました。
ただ、この形には注意点が2つあります。1つは、GASの毎日の自動実行が、指定した時刻から1時間のうちのどこかで動くことです。開店の準備に間に合うよう、早めの時間帯を指定します。もう1つは、GASがシートに直接書いた行はAppSheetを通らないので、それをきっかけにAppSheetの自動処理（Bot）は動かないことです。通知を送りたいなら、時刻を決めて動かすBotを使います。
差額は、端末の金額または数えた現金の額からPOSの金額を引いて、アプリの式で出します。差額があれば、店舗はその理由を登録します。理由は1つの行に複数登録でき、理由ごとの金額の合計が差額と合うと「差額一致」の欄が「はい」になります。なお、釣銭は、金種ごとの枚数を入れる金種表で数えます。
とはいえ、差額一致が見ているのは、実は理由の合計が合っているかどうかだけなのです。POSの金額も店舗の担当者が手で入れるので、現金に合わせて入れれば差額は0になります。なので、POSの締めの画面の写真を添えてもらい、本社の経理がときどきPOSの集計と突き合わせる確認は残すべきです。
差額の理由は、マネージャーが確認します。D社では、差額の明細に「確認した人」と「確認した日時」の欄を足し、マネージャーがボタンを押すとその2つが記録されます。このボタンと「未確認の差額報告」の一覧は、マネージャーの画面にだけ出し、店舗の入力画面には出していません。さらに、入力した本人には押せない条件をボタンに付けておくと、自分の入力を自分で確認することも防げます。自動計算を統制として頼るときに何を確かめるかは、承認フローや自動仕訳をITACとして評価する記事で扱っています。
承認後の書き換えはアプリの式で止め、ロールごとに画面を開いて確かめる
月次の承認と、承認した月のロックも、AppSheetの式で作れます。ただし、式が意図どおりに効いているかは、ロールごとに画面を開いて確かめるまで分かりません。
D社では、マネージャーが月次の承認をした月は、決済別明細の金額の欄を編集できないようにしています。AppSheetには、列ごとに「この条件のときだけ編集できる」という式を書く機能（Editable_If）があり、そこに「その月が承認済みでないこと」を書きます。注意したいのは、止まるのが条件を書いた欄だけだという点です。行の削除や差額の理由の表は、別に止める必要があります。また、この条件はボタン（アクション）による書き換えまでは止めないので、金額を書き換えるボタンにも同じ条件を付けます。見える行のほうは、セキュリティフィルタという機能で店舗ごとに絞ります。ログインした人のメールアドレスから店舗を引き、自店の行だけをサーバーから端末に送る仕組みです。
では、式を書けば安心なのでしょうか。実は、ここに落とし穴があるのです。AppSheetが標準で持つロールは管理者と一般の2つだけなので、マネージャーのような役割は従業員のマスタに持たせ、条件式でそれを引きます。D社では、マスタにはロールを「マネージャー」と登録していたのに、月次承認の条件式は「Mgr」という文字だけを見ていました。式としてはエラーなく動くので、画面を見ただけでは気づきません。この誤りは、作る途中で見つけて直しました。
そのため、店舗の担当者・マネージャー・本社の経理のロールごとに、見える行と押せるボタンを1つずつ確かめる手順を、使い始める前に決めておきます。AppSheetの編集画面には、別の人としてアプリを開くプレビューの機能があります。しかし、ボタンによる更新などは実際の動きと違うことがあるので、最後はロールごとの実際のアカウントで開いて確かめます。式を直したら、同じ確認をやり直します。権限の設定を変えた記録の残し方はSaaSの設定変更を記録に残す方法の記事で、誰に何の権限があるかを定期的に見直す手順は権限の棚卸の進め方の記事で扱っています。
もう1つ、最初に確かめたいのがタイムゾーンです。D社では、作り始めた時点で、データを置いたシートのタイムゾーンが米国太平洋時間になっていました。日報は「どの日の売上か」でまとめるので、日付の境目がずれると、GASが作る行の日付や月次のロックの対象が狂います。なので、シートとGASのタイムゾーンは東京にします。なお、AppSheetの「今日」の日付は使う人の端末のタイムゾーンで決まり、時刻で動かすBotにも別にタイムゾーンの設定があるので、そちらも確かめます。
書き換えられない記録は、シートの権限と会計ソフトの締めで守る
あとから書き換えられない記録は、AppSheetだけでは作れません。アプリの外で、シートを編集できる人を絞り、確定した数字を会計ソフトに入れて締めることで守ります。
なぜ、アプリのロックだけでは足りないのでしょうか。理由はシンプルで、データの保存先がシートだからなのです。アプリの式で編集を止めても、シートを編集できる人は、アプリを通さずにセルを書き換えられます。自店の行だけを見せる設定も、シートを開ける人には関係ありません。公式ヘルプも、セキュリティフィルタは完全なセキュリティ対策ではないとし、列の編集の条件もセキュリティの仕組みではないと書いています。
一方で、AppSheetの利用者には、シートの共有は要りません。というのも、既定の設定では、アプリはアプリを作った人のアカウントでシートを読み書きするからです。そこで、シートを編集できる人を、アプリの管理者とGASを直す担当者に絞ります。店舗の人や本社の経理にシートを共有しないことが、いちばん効く対策です。
それでも、シートの編集者が数字を直すことは止められません。シートには版の履歴とセルの編集履歴がありますが、追える範囲には限りがあります。まず、既定の設定では、アプリからの変更はすべてアプリを作った人の名前で残るので、アプリの利用者の操作と管理者の直接の修正を見分けられません。また、行の追加や削除は編集履歴に表示されない場合があり、版を戻すとセル単位の履歴も消えます。シートの保護も、ヘルプ自身がセキュリティ対策ではないとしています。AppSheetの操作の記録（Audit History）は、Enterprise Plus以外のプランでは7日で消えます。つまり、誰が確認したかは、差額の明細の「確認した人」「確認した日時」のように、行の中の欄で残すしかありません。
最後の守りは、会計ソフトの締めです。月次の承認を終えた数字は会計ソフトに仕訳として入れ、会計ソフトの側で月を締めます。freee会計の月締めでは、締めた期間の日付で仕訳を登録・編集・削除できなくなります（2026年11月時点の法人プランでは、本締めはスタンダード以上、仮締めはアドバンス以上）。ただし、締めは後から解除でき、仮締めなら管理者は編集もできるので、解除したときは理由と承認を残します。さらに、APIから送る取引に締めがどう効くかはヘルプに書かれていないので、本番の前に1件流して確かめます。編集部の見立てでは、改ざんできない記録まで求めるなら、方式を選ぶ段階で、記録を追記だけで残せる自社開発のアプリなどにするほうが筋がよいです。表計算ソフトやCSVでつなぐ部分の統制は、Excelの集計やCSV連携の統制の記事で扱っています。
マスタは1か所を正本にし、毎朝の行を作れる場所に置く
店舗・決済手段・従業員とロールのマスタは、どこか1か所を正本にします。D社では、すでにシートで持っていた店舗のマスタを正本にし、毎朝GASが行を作る日報もシートに置きました。マスタをシートにしたのは、本社が同じマスタを2か所で更新したくないと考えたためです。
AppSheetには専用のデータベース（AppSheet Database）もあります。しかし、そのデータをシートの関数やGASから直接読み書きする方法は、公式ヘルプに見当たりません。
| 観点 | シートに置く | AppSheet Databaseに置く |
|---|---|---|
| 既存のマスタ | 本社のシートをそのまま正本にできる | 本社のシートと二重に更新する |
| GASとのつながり | GASで行を作り、マスタを読める | 直接読み書きする方法がヘルプに見当たらない |
| 行数の上限 | 1つのシートで10万行以内が目安 | Coreのプランは1つのデータベースで2,500行まで |
では、マスタだけをシートに置き、日報はAppSheet Databaseに置けばよいのでしょうか。確かに、1つのアプリで両方を使う組み合わせもできます。それでもD社がシートを選んだのは、毎朝GASが行を作る仕組みと、行数の上限があったからなのです。AppSheet DatabaseはCoreのプランだと、1つのデータベースで2,500行までです。たとえば10店舗で決済手段が4つなら1日40行になり、約2か月で上限に届きます。
もっとも、シートに置けば、前の節で見た「シートを直接書き換えられる」問題を抱えます。AppSheetはデータをすべて端末に読み込むので、行が増えるほど同期も遅くなります。同じ例なら1年で約1万5,000行になるので、過去の年度は別のシートに移します。
この判断の前に、はてなベースは方式を3つ示し、それぞれの利点と弱点を並べてD社に選んでもらいました。比べたのは、店舗が表の形で入力できるか、社内の誰が仕組みを直せるか（保守）、データを誰が見られて誰が直せるか（セキュリティ）の3点と、利用者の数に応じた費用です。AppSheetの費用は利用者1人あたりの月額で、2026年11月時点の公式の料金表ではCoreが1人月10米ドルです。ただし、Google Workspaceの多くのエディションにはCoreが含まれています。保守の点では、経産省の追補版もコラムで注意を促しています。ノーコードのツールによるシステム化が情報システム部門の管理外で広がると、引き継ぎやセキュリティ対策が難しくなるとし、ツールの把握と文書化を求めています。D社は、店舗が表の形で入力でき、社内で手直しがしやすく、既存のマスタを生かせるAppSheetとGASの組み合わせを選びました。
小口現金は申請から精算までをアプリで回し、freeeに送る前に経理が中身を確かめる
小口現金も、同じアプリの中で、申請・承認・精算の流れとして回します。AIで読み取った内容は、経理が確かめてからfreeeに送ります。
D社では、店舗が小口現金で払ったものを申請し、承認者が承認すると、本社の経理が精算します。1件ごとに「申請中」「承認済み」「差し戻し」「精算済み」のような状態を持ち、承認・差し戻し・再申請・精算済みにするボタンで状態を進めます。承認待ちの一覧と小口現金出納帳も、アプリの中で見られます。
レシートは、AIで日付・支払先・金額などを読み取ります。ただし、読み取った内容はそのまま帳簿に入れず、経理が中身を確かめてから、APIでfreee会計に取引として送ります。読み取りに誤りがないか、私的な支出が紛れていないかは、結局のところ人が見るしかないのです。freeeとの連携は、freeeの検証用環境で2店舗分を送り、取引が登録されることを確かめた段階です。レシート1枚を1つの取引にするか、店舗の画面に明細まで見せるか合計だけにするかといった細部は、店舗と経理の使い方を見ながら決めていきます。freee会計の導入の段階でマスタや連携をどう決めるかは、freee会計の導入の進め方の記事で扱っています。
では、撮影したレシートの紙は捨ててよいのでしょうか。紙を捨てるには、電子帳簿保存法のスキャナ保存の要件を満たす必要があります。紙をどうするかは、作り始める前に決めておきます。国税庁の一問一答では、スマートフォンでの撮影もスキャナに含まれ、解像度、タイムスタンプ（訂正・削除の履歴が残るシステムなら代えられる）、検索などの要件が並びます。そのため、アプリの画像の欄に保存しただけで要件を満たすとは限らず、紙を捨てる運用にするなら、税理士に確かめてから決めます。
読み違えやすいポイント
- 「アプリで自店の行しか見えないから、データは守られている」は誤りです。見える行の制限はアプリの中だけで、シートを開ける人には全店の行が見えます
- 「月次のロックをかければ、確定した数字は変わらない」も誤りです。止まるのは条件を書いた欄だけで、ボタンによる書き換えや、シートの編集者・GASによる書き換えは止まりません
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。