担当者が毎日触る画面と、誰が何を見られるかの設定、押すボタンは AppSheet に任せます。台帳はスプレッドシートに置き、フォルダを作る、カレンダーに予定を入れる、議事録を取り込むといった裏の作業は GAS に任せます。そして、そのすべてに同じ顧客IDを通してつなぎます。この分け方で、協力者や専門家の手を借りながら、税理士事務所の顧客ポータルのデモ環境を作るところまで、1日で仕上がりました。自動処理の登録、権限の設定、旧システムからの移行はこれからです。
この記事の要約
経理3年目の世戸田さんは、自分が所属する税理士事務所で、顧客の情報の基盤を作り直す作業に取りかかりました。それまで顧客の管理は kintone で行い、資料は共有ドライブの顧客フォルダに置き、やり取りには Slack を使っていました。目指したのは、顧客IDひとつで、フォルダ・予定・議事録がつながる状態です。
手元にあったのは、外部の協力者と共有した1枚の構成図でした。AppSheet と GAS、それに Google Workspace を組み合わせる案です。「で、この図のどこまでを AppSheet がやってくれるんだろう」。世戸田さんの最初の疑問はそこでした。
この記事は、実際に税理士事務所で組んだ顧客基盤の記録をもとに、架空の世戸田さんの話として書いています。作ったもの、作った順番、つまずいた点は記録のとおりです。
AppSheet は、スプレッドシートを読み込ませると、表の列から入力フォームや一覧の画面を持つスマホアプリを自動で作る、Google のノーコードの道具です。以下では、Google のサービスを操作する小さなプログラム（Google Apps Script）を「GAS」と書きます。
担当者が触るのは AppSheet だけにし、裏の作業は GAS に任せた
世戸田さんが最初に決めたのは、担当者が触る場所を AppSheet の1か所に絞ることでした。そのうえで、見える部分は AppSheet、裏方は GAS、記録はスプレッドシートと、3つに役割を分けました。
AppSheet が受け持つのは、スマホと PC の画面です。入力のフォームと一覧、担当分だけが見える権限、「確認しました」のようなボタンがここに入ります。画面の下にはホーム・顧客・予定・議事録・検索の5つのタブを並べ、顧客をタップすると、その顧客の予定や議事録、定款や申告書がまとめて見えるように設計しました。
一方で、Drive にフォルダを作る、カレンダーに予定を入れるといった作業は GAS に任せました。たとえば顧客を1件登録すると、GAS が共有ドライブに顧客フォルダと13区分のサブフォルダを作ります。また、予定を入れると、共通のカレンダーに Meet の会議つきで登録します。さらに、Meet の Gemini のメモを1時間ごとに議事録として取り込む処理も GAS が担います。
GAS は作業を終えると、できたフォルダや予定のIDとURLをスプレッドシートに書き戻します。つまり、スプレッドシートは顧客・予定・議事録の台帳であり、どこに何があるかの索引でもあるのです。GAS の実行は、作成も更新もエラーも、すべて操作ログのシートに残します。そのため、フォルダの作成に失敗した顧客は、ホーム画面の「要対応」に出る設計にしました。管理者は操作ログで理由を確かめ、「フォルダを再発行」のボタンを押せば作り直せます。
「裏方まで全部 AppSheet の中でやればいいのに」。世戸田さんも、最初はそう思いました。けれども、AppSheet の自動処理（Bot）は、決まったきっかけで決まった処理を動かす仕組みで、その処理の1つとして GAS の関数を呼べます。だから、Drive やカレンダーを細かく操作する部分は GAS に書き、AppSheet からはそれを呼ぶだけにする。世戸田さんはこの分担を選びました。
あわせて、自動処理で呼ぶ GAS は、URL で開ける Web アプリとしては公開せず、Bot から直接呼ぶ形にしました。こうしておけば、URL が外に漏れても外から実行されることはありません。例外は予定ガントの画面で、これは GAS の Web アプリとして作り、社内のアカウントだけが開けるようにしています。
この分け方の良いところは、担当者が AppSheet しか見なくていい点です。裏で何が動いていても、使う人の入口は1つで済みます。
顧客IDを1本通すと、予定がそのまま工数になる
台帳・フォルダ・カレンダーをつなぐ鍵は、顧客IDです。世戸田さんは、同じ顧客IDをどのデータにも持たせることを最初に決めました。
AppSheet の中では、予定・議事録・書類の表にある「顧客ID」の列をにし、参照先を顧客マスタにしました。こうすると、顧客の詳細画面に、その顧客の予定や議事録が自動で並びます。台帳はスプレッドシートのまま、画面の上で表どうしがつながるわけです。
しかし、つなぐ相手はスプレッドシートの中だけではありません。Drive のフォルダやカレンダーの予定にも、目に見えない形で顧客IDを付けました。世戸田さんはこれを「メタ情報規約」としてまとめ、顧客ID・書類の種類・規約の版の3つを共通のキーにしています。書類の背表紙に貼るラベルのようなもので、ファイルを開かなくても、どの顧客の何の書類かが分かります。
この規約には、もう1つねらいがあります。それは、キーの付け方を事務所をまたいでそろえておけば、一度作ったツールがどこでもそのまま使えることです。この点は、協力者と事務所横断で標準にしていく方針です。
さらに、顧客IDの付いた予定は、そのまま工数の記録になります。カレンダーの予定から顧客ごと・担当者ごとの時間を集計する設計なので、担当者が別に日報を書く必要がなくなります。打合せも、記帳や決算の作業の割り当ても、すべて予定として入れる。予定を中心にすると決めたことで、工数の集計まで1本の線でつながる設計になりました。
もう1つ、細かいところでは、顧客IDの列はスプレッドシートで「文字列」にしました。数値のままだと、先頭の0が落ちたり、番号が計算に使われる数字として扱われたりするからです。
扱いに迷いやすいのが、顧客の機微な情報です。そこで、顧客マスタには、暗証番号や口座のような機微な情報を持たせないと決めました。設定用のシートにも機微でない値だけを置き、IDやトークンは GAS の側の保管場所に分けています。
1日でどこまで作れたのか？
答えは、協力者や専門家の手を借りて、デモ環境を作り、動きを確かめるところまでです。自動処理の登録と権限の設定、実際の顧客の移行は、まだ終わっていません。
まず世戸田さんは今の運用を調べるところから始めました。kintone の顧客管理と案件・タスク、共有ドライブの顧客フォルダの構成、Slack の運用を見たうえで、要件・データ・画面・GAS・構築手順・移行・論点の設計書を書き、GAS も作って模擬の環境で試しました。
続く午後は、協力者との打ち合わせで方針を固めました。決まったのは、顧客フォルダに議事録の区分を新しく作ること、Gemini の議事録を自動で取り込むこと、Slack は連携できる環境なら連携すること、freee とは連携しないことです。顧客60社分のダミーデータと、スマホ画面の完成イメージもこの時間に作りました。
ところが途中で、世戸田さんは大きな方針を1つ変えることになりました。顧客マスタの正本をスプレッドシートに置き、kintone は最初の1回だけ顧客を引き継ぐ元にしたのです。運用では kintone を使いません。そのため、kintone と同期する関数を、初回だけ移行する関数に作り替えました。半日で、さっそくの手戻りです。
続けて、担当者別・顧客別に作業の割り当てと打合せを横棒で並べる予定ガントを足しました。空いている日をドラッグすると予定が入り、担当者がスマホで「確認しました」を押すと、管理者の画面で斜線が消える流れです。
最後に、協力者や専門家の力も借りて、デモ環境を組みました。Drive に9シートのスプレッドシートを作ってダミーデータを入れ、GAS を紐づけ、AppSheet のアプリを作成しました。そのうえでアプリには5つの表を足し、顧客IDの参照、一覧に出す名前、列の型、カレンダーと議事録の画面を設定しました。
最後に結合テストを流すと、顧客フォルダの13区分、Meet つきの予定、議事録のドキュメントが、Google 上でできました。かかった時間は約48秒です。
ちなみに、プログラムを書いたのは GAS だけでした。AppSheet の本体は、すべて設定の画面で組めています。
つまずいたのは、型の自動判定とアカウントの切り替えだった
作業の中で、世戸田さんがつまずいた点は4つありました。最後の1つを除けば、作り始める前に知っていれば避けられたものです。
- 列の型の自動判定が外れた。AppSheet は列の型を推測しますが、「6月」と入った決算月が日付に、ファイル名と JSON のメタ情報がファイルの型に判定された。表を足したら、保存の前に型を必ず見直す
- GAS を既存のスプレッドシートに紐づけるとき、指定の仕方を誤ると新しいスプレッドシートが作られてしまった。既存のシートに入れるときは、紐づけ先だけを指定する
- ブラウザに Google アカウントが複数あると、Apps Script が別のアカウントで開いた。URL でアカウントを指定し、事務所のアカウントで開く
- フォルダの発行に約48秒かかった。13区分を作り、台帳に書き戻す処理で、顧客が増えるとシートの読み直しも重くなる。まとめて書き込む形に直す余地がある
3つ目は、別のアカウントの世戸田さんが、勝手に作業を始めていたようなものでした。とはいえ、いちばん気づきにくいのは1つ目の型の判定です。というのも、アプリはエラーなく動くので、入力の画面を開くまで誤りが見えないからです。
このほか、これから進める Bot の設定には、先に確かめておきたい点があります。AppSheet の公式ヘルプでは、Bot から呼べる GAS はスプレッドシートに紐づかない単独のスクリプトだけで、紐づいたスクリプトにはいまのところ対応していません。呼んだスクリプトはアプリの所有者の権限で動き、この機能は Core 以上のプランで使えます。今回は GAS をスプレッドシートに紐づけたので、Bot をつなぐ段階で置き場所を見直す必要がありそうだ、というのが編集部の見立てです。また、AppSheet からの書き込みでは、スプレッドシートの編集をきっかけに動く仕組みが動かない点も、ヘルプに書かれています。
AppSheet に向くのは、台帳と画面と決まった後処理の業務
編集部の見立てでは、AppSheet が向くのは、台帳があり、それを画面から入力・確認し、登録したあとに決まった処理が続く業務です。顧客を登録したらフォルダを作る、予定を入れたらカレンダーに載せる、という今回の形がまさにそれに当たります。
反対に、重い処理と秘密の保管は、AppSheet とスプレッドシートの外に出す計画です。e-Tax へのログインや郵送、PDF 化のような長く複雑な処理は、この先の段階で Google のクラウド上の実行環境に置く予定です。電子申告の暗証番号のような秘密も、暗号化して保管するサービスに移し、スプレッドシートには置きません。
具体的には、とが、その置き場所の候補です。AppSheet からは顧客IDだけを渡して呼ぶ形を考えています。さらに、Claude などの AI から顧客IDで予定・議事録・資料を照会できるようにすることも、この段階で検討しています。
規模の点でも、限りはあります。実際、今回の作りでは、顧客が増えるほどシートの読み直しが重くなることが、結合テストの時点で分かっていました。台帳が大きく育つ業務なら、最初から書き込みをまとめる作りにするか、データの置き場所自体を検討したほうがよいでしょう。スプレッドシートで集計や連携を組むときの統制の考え方は、Excelの集計やCSV連携の統制の記事で扱っています。
会計ソフトとのつなぎ方も、業務によって答えが変わります。今回は freee とは連携しないと決めました。一方、店舗の現金の日報を AppSheet に移し、確かめた取引だけを会計ソフトに送る形を選んだ例は、店舗の現金管理をAppSheetに移すときの線引きの記事にまとめています。
画面・台帳・裏方を分け、顧客IDでつなぐ
「この図のどこまでを AppSheet がやってくれるのか」。冒頭の疑問に、世戸田さんは自分で答えを出しました。AppSheet に任せるのは、担当者が触る画面と、見える範囲の設定と、ボタンです。台帳はスプレッドシートに、フォルダやカレンダーを操作する裏の作業は GAS に任せ、どこにも同じ顧客IDを通します。
とはいえ、世戸田さんの基盤は、まだ版 0.1 です。残っているのは、Bot で GAS を自動で呼ぶ設定、担当分だけが見える権限と使う人の招待、そして kintone からの実際の顧客の引き継ぎです。権限をどう見直していくかは権限の棚卸の進め方の記事で、設定を変えた記録の残し方はSaaSの設定変更を記録に残す方法の記事で扱っています。
これから同じことに取り組むなら、最初に決めるのは画面ではなく、顧客IDの番号と、それを何に持たせるかです。これが編集部の勧めです。そこさえ決まれば、画面はあとから AppSheet の設定で足していけます。
明日から試せること
まずは、この3つから試してみてください。
- 顧客IDの番号を決め、スプレッドシートではその列を「文字列」にしておく
- AppSheet で表を足したら、保存の前に列の型が合っているかを見直す
- 予定や議事録の顧客IDの列を Ref 型にし、顧客の詳細画面にまとめる
AppSheet での業務の作り直しをご相談ください
どの業務をアプリに任せ、どこを GAS やスプレッドシートに残すか、顧客IDの通し方や今のシステムからの移し方まで、エンジニアと会計の専門家が一緒に整理します。