目次
「AppSheetで作った現場アプリのデータを、GASで集計する」——中小企業のDXでは定番の組み合わせです。どちらもGoogle Workspaceの中で完結し、コストも抑えられます。
ただ、この連携には静かに壊れるポイントがあります。アプリ側とスクリプト側で、同じはずのカテゴリ名が一文字だけ違う。それだけで、一括処理の一部が黙って落ち続けます。しかもエラーは全件ではなく「一部」なので、動いているように見えてしまう。
実案件（匿名）でも、カテゴリ名の中黒（・）の有無という差が、数ヶ月のあいだ誰にも気づかれないまま処理エラーを生み続けたことがありました。この記事では、なぜこれが起きるのか、どう設計すれば防げるのかを整理します。
この記事の結論
- 文字列で照合する設計は、記号や全角半角の差でいつか必ず壊れる
- 照合キーはIDで持ち、画面に出す表示名と完全に分離する
- 連携部のテストは、きれいなテストデータではなく実データで突合する
何が起きたか：中黒ひとつで一括処理が半分落ちる
AppSheetで入力された現場データを、GASが定期的に読み取って集計・転記する仕組みがありました。処理はカテゴリごとに分岐しており、GAS側のコードには「このカテゴリ名ならこの処理」という対応表が書かれていました。
問題は、アプリ側の選択肢に登録されたカテゴリ名と、GAS側の対応表に書かれたカテゴリ名で、中黒の有無が食い違っていたことです。人が画面で見比べても、まず気づきません。しかし機械にとっては完全な別文字列で、そのカテゴリの行だけ対応先が見つからず、処理がスキップされていました。
やっかいだったのは、これが全件エラーではなかった点です。他のカテゴリは正常に処理されるため、日々の運用では「動いている」ように見えます。ログには「一部エラー」と出るものの、件数が全体の一部であるうちは「たまたま入力ミスの行があったのだろう」と流されてしまう。結果として、数ヶ月にわたって発覚しませんでした。
AppSheetとGASでデータが一致しない原因とは
原因は「バグ」ではなく、設計として文字列を照合キーに使っていることそのものにあります。人間には同じに見えて機械には別物になる差は、業務データの中に無数に潜んでいます。
| ゆれの種類 | 例 | 気づきやすさ |
|---|---|---|
| 中黒・記号の有無 | 「営業・企画」と「営業企画」 | ほぼ気づけない |
| 全角半角 | 「A1」と「Ａ１」 | 気づきにくい |
| 前後のスペース | 「東部」と「東部 」 | まず気づけない |
| ハイフン類の違い | 全角ダッシュとマイナス記号 | ほぼ気づけない |
| 表記の揺れ | 「株式会社◯◯」と「（株）◯◯」 | 見れば気づく |
とくに末尾のスペースは、コピー&ペーストで簡単に混入し、画面上ではまったく判別できません。
さらに厄介なのが、選択肢の名前は運用の中で必ず変わるという点です。「わかりにくいから名前を変えよう」というのは現場のごく普通の改善です。AppSheet側で名前を直した瞬間、GAS側の対応表との一致が崩れる。悪気のない改善が、連携を壊す引き金になります。
つまり、文字列照合の設計は「いつか壊れる」ではなく「運用が続く限り必ず壊れる」構造だということです。
なお、AppSheetやGASの仕様は変わるため、機能の詳細は最新情報を公式サイトで確認してください。
表記ゆれの対策｜キーはIDで持ち、表示名と分離する
対策は3つです。順番に効きます。
1. 照合キーはIDで持つ
カテゴリや区分の照合は、名前ではなく変わらないIDで行います。「CAT001」のような、業務上の意味を持たない値が理想です。意味を持たせると、意味が変わったときに値を変えたくなり、結局ゆれが戻ってきます。
IDにしておけば、表示名を「営業・企画」から「営業企画部」に変えても、連携側は何も直さずに動き続けます。
2. 表示名と照合キーを完全に分ける
現場が見る画面には、わかりやすい日本語の名前を出します。裏側でデータを受け渡すのはIDだけ。この2つを1つの列で兼ねさせないことが要点です。
マスタ表を1つ用意し、そこにIDと表示名を並べて持たせる。AppSheetは表示名を見せながらIDを保存し、GASはIDだけを見る。名前を変える自由と、連携の安定を両立できます。
3. どうしても文字列で照合するなら、正規化する
既存の仕組みですぐにID化できない場合もあります。その場合は、照合の直前に文字列をそろえる処理を必ず挟みます。前後の空白を除去する、全角半角をどちらかに統一する、比較対象の記号を除去する——といった処理です。
ただしこれは応急処置です。ゆれの種類は事前に洗い出しきれないため、正規化の抜けが新たな不一致を生みます。根本対策はIDで持つことだと理解したうえで使ってください。
連携部のテストのやり方｜実データで突合する
設計を直しても、テストの方法が甘いと同じことが起きます。今回の件が数ヶ月見つからなかった直接の理由は、テストが手作りのきれいなデータで行われていたことにあります。
開発時に用意するテストデータは、当然ながら正しい表記で入力されます。現場が実際に入れた、コピペ由来の空白や、途中で名前が変わったカテゴリは含まれません。だから開発中はすべて通り、本番で一部だけ落ちるのです。
連携部のテストでは、次の3点を押さえてください。
- 実データで全件突合する：本番のスプレッドシートから実際のデータを取り、照合が成立するかを全行で確認します
- 不一致行を必ず出力する：「一致した件数」ではなく「一致しなかった行の一覧」を出します。件数がゼロであることを目視で確認します
- 一部エラーを成功扱いにしない：処理が一部でも落ちたら、通知が飛ぶようにします。ログの中に埋もれる形では、誰も見ません
3つ目が特に重要です。今回の件が長期化した原因は、技術ではなく**「一部エラー」を異常として扱う仕組みがなかったこと**にあります。全件成功以外は異常、という基準にしておけば、初日に気づけました。
中小企業がこの設計から学べること
この話はAppSheetとGASに限りません。kintoneとスプレッドシート、会計ソフトと販売管理——システム同士をつなぐ場所には、必ず「何をキーに突き合わせるか」という設計判断があります。
そこで安易に「取引先名」「商品名」「部署名」といった人が読める文字列を選ぶと、同じ問題が起きます。名前は変わるもの、揺れるものだからです。
導入時に確認すべきは、次の2点だけです。
- 連携の照合キーは、IDか名前か
- 一部エラーが出たとき、誰かに通知が届くか
この2つが押さえられていれば、連携は静かに壊れなくなります。
よくある質問
Q. AppSheetとGASの連携でデータが一致しないのはなぜですか？ カテゴリ名などの文字列でデータを照合しているためです。中黒の有無、全角半角、前後のスペースといった見た目でほぼ判別できない差があると、人には同じに見えても機械上は別物と判定され、照合に失敗します。
Q. 表記ゆれによる照合エラーを防ぐ方法はありますか？ 照合キーを表示名から切り離し、変わらないIDで持つのが基本です。画面に出す名前は自由に直せる一方、IDは固定されるため、記号や表記が揺れても連携が壊れなくなります。
Q. 連携部分のテストは何をすればいいですか？ 手で作ったきれいなテストデータではなく、現場で実際に入力された実データで突合してください。全件を照合し、一致しなかった行を必ず一覧で出力し、件数がゼロであることを確認します。
まとめ
- AppSheetとGASの不一致の多くは、中黒・全角半角・スペースなど目に見えない表記ゆれが原因
- 文字列で照合する設計は、名前が変わるたびに壊れる。照合キーはIDで持ち、表示名と分離する
- テストは実データで全件突合し、「一部エラー」を成功扱いにしない通知の仕組みを入れる
RENOYでは、AppSheetやGASを使った業務自動化の設計・開発に加えて、「すでに動いている仕組みが正しくつながっているか」の点検も行っています。「エラーは出ているが原因がわからない」「一部だけ処理されていない気がする」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。