見出し画像

【第7回】「朝、スプレッドシートを開いたら、昨日のデータが1件も入っていなかった…」

~沈黙するシステムに“声”を与え、24時間戦える《鉄壁の司令塔》へ進化させた対話の記録~

🟥 恐怖の「沈黙」 ― Before の世界

想像してみてください。

あなたは、この自動化システムを運用する担当者です。

昨日の夕方、取引先から届いた大量の注文書PDFを、いつものように Google Drive の指定フォルダへ保存して帰宅しました。

「あとは夜のうちに、GASがAIに読ませて、スプレッドシートに整理しておいてくれるはず」

翌朝。

コーヒーを片手に、期待を込めてスプレッドシートを開くと……

最終行は、昨日の日付のまま。

1件も入っていません。

「え? トリガーが動いてない?」

慌てて Drive を見に行きますが、ファイルは手付かずで残ったまま。

GAS からのエラー通知メールも届いていません。

つまりこれは、

“エラーで止まった”のではなく、“黙って仕事を放棄した”状態。

これが、エラーハンドリングのないシステムが引き起こす**「沈黙」**です。

開発者はエディタのログを見に行けますが、スプレッドシートしか見れない現場の人には分かりません。

「壊れたの? もう信用できない…」

現場には不信感だけが残ります。

今回のテーマは、この「沈黙」を破り、

システムに “声(ログ)” を与え、もし途中で倒れても**「ここまでやりました、続きはここからです」と引き継ぎができる “鉄壁の安全装置”** を実装すること。

そのための、**“私(非エンジニア)とAIの対話の記録”**を公開します。


🟦 【哲学】知識ゼロから生まれた「もしも設計」

私はプログラマーではありません。

**「try...catch」**という単語すら、この開発を始めるまで知りませんでした。

今回の《鉄壁システム》は、私の知識ではなく、

**「現場で起きたリアルなトラブル」を元に、AI(Gemini)へぶつけた「素朴な疑問」**の積み重ねから生まれたものです。

ここからは、私とAIの“安全装置づくり”の対話を、4つのフェーズで紹介します。

Phase 1:沈黙を破る ― Try...Catch(例外処理)

私:「エラーが出た時、黙って止まるのやめてくれない?

エディタを開かなくても分かるように、スプレッドシートに“何が起きたか”書いておいてほしいんだけど。」

AI:「それなら Try(やってみる)...Catch(捕まえる) を使いましょう。」

私:「どういう仕組み?」

AI:「『Try』の中で仕事をして、もし失敗したら“赤いエラー画面”でシステムごと落ちるのではなく、

エラー君を『Catch』で捕まえて、ログシートの列に『〇〇エラー』と書き込むんです。」

私:「なるほど! それなら現場の人も“あ、このファイルだけ読み込めなかったのか”と自分で気づけるね!」

Phase 2:衝突を防ぐ ― LockService(排他制御)

私:「でも待って。ログを書いてる最中に、別のトリガー(処理)が動いてデータを書き込もうとしたら? 行がズレたりしない?」

AI:「その通りです。だから LockService(ロックサービス) を使いましょう。」

私:「排他制御ってやつ?」

AI:「はい。これは**“トイレの鍵”**と同じです。

誰かが用を足している(処理)をしている間は、入り口に『使用中』の鍵をかけます。その間、他のトリガーはドアの前で待つか、諦めて帰ってもらう仕組みです」

Phase 3:鍵の回収 ― Finally(最後の約束)

AI:「ただし注意点があります。

処理の途中でエラーが出て止まると、**鍵がかかったまま(デッドロック)**になります。そうなると、しばらく誰もシステムを使えなくなります」

私:「うわ、最悪じゃん! 自分がかけた鍵で自分も閉め出されるってこと?」

AI:「だからこそ Finally(最後に必ず) が必要なんです。

成功しても、失敗しても、最後の力を振り絞って『必ず lock.releaseLock()(鍵を開ける)』を実行してから終了する。そういう遺言のようなコードを書くんです」

Phase 4:限界への挑戦 ― Commander(司令塔)

私:「ところで、今後PDFが100枚一気に来ることもあるんだけど。

GASって一度に何分まで動けるの?」

AI:「最大6分です。大量に来ると、処理の途中で**“時間切れ強制終了”**になります。」

私:「じゃあ、一度に全部やろうとせず、“少しずつ処理して次回に引き継ぐ”仕組みが必要だね。」

AI:「作りましょう。時間を管理する**“司令塔(Commander)”**です。

ストップウォッチを見ながら、締め切り時間が来たら『今日はここまで!』と安全に止まり、残りは次回にまわす。そんな賢い指揮官を置くのがベストです。」


こうして私は、専門知識ゼロのまま

「例外処理・排他制御・バッチ処理」

というプロレベルの仕組みに辿り着きました。

必要なのは技術用語の暗記ではありません。

「もしこうなったら現場が困るよね?」という想像力だけです。


🟩 【実践:無料エリア】安全装置の「基本の型」

まずは、AIが教えてくれた

Try(やる) → Catch(報告する) → Finally(鍵を返す)

の基本形を、小さなコードで体験してみます。

🔧 実験:わざとエラーを起こしてみる

以下のコードをGASエディタに貼り付けて実行してみてください。

JavaScript

function testSafety() {
  var lock = LockService.getScriptLock();
  
  try {
    // 1. 鍵をかける(他の人は5秒待つ)
    if (lock.tryLock(5000)) { 
      Logger.log("鍵をかけました。処理を開始します。");
      
      // 2. ここでわざとエラーを起こす!
      throw new Error("意図的なエラー発生!"); 
      
      Logger.log("この行は実行されません");
      
    } else {
      Logger.log("他の人が使用中です。");
    }
    
  } catch (e) {
    // 3. エラーの捕獲(ここでログに残す)
    Logger.log("エラーを捕まえました: " + e.message);
    
  } finally {
    // 4. 何があっても最後に必ず鍵を返す(ここが命!)
    lock.releaseLock();
    Logger.log("鍵を返却しました。安全に終了します。");
  }
}

✅ この型が“安全装置のすべての土台”

  • try: 本来やりたい処理を書く場所。

  • catch: 失敗した時だけ動く、報告書を書く場所。

  • finally: 成功・失敗に関わらず、絶対に実行される場所。 ここで鍵を返さないと、システムは「開かずの扉」になります。

この構造さえ理解できれば、もうGASのエラーは怖くありません。

🔵 次回予告

次回はいよいよシリーズの最終回。

この「小さなスプレッドシート」から始まったシステムを、会社全体へどう展開するか?

そして、**“AIと共に働く未来”**をどうデザインするか。

Good Ruler流DXの集大成となる総括をお届けします。お楽しみに!


🟧 【有料エリア】完コピ可能!《鉄壁の司令塔(dailyScheduler)》実装セット

お待たせしました。

ここからは、上記の**「排他制御 × エラーログ × 時間管理」のすべてを統合した、“本番運用版”の完成コード**を提供します。

このコードを導入するだけで、あなたのシステムは以下のように生まれ変わります。

  • 2重起動ゼロ: ボタン連打やトリガー重複によるデータ破損を防ぐ。

  • 沈黙ゼロ: エラーが起きても止まらず、「日本語」でログを残す。

  • タイムアウト対策: 6分の壁が来る前に自律的に終了し、次回へ引き継ぐ。

まさに、「業務システム」としての完成形です。

ここまで読んでくださったあなたへ。

記事の続きには、私がGeminiと共に作り込み、あらゆるエラーに対処できるよう調整した**「完全版コード」**を置いておきます。

「もし動かなかったらどうしよう」という不安を少しでも減らせるよう、丁寧に仕上げました。
もしよろしければ、このコードをあなたのプロジェクトのお守り代わりに使っていただけると嬉しいです。

---✂--- ここから先は有料エリア ---✂---

⚠️ ご購入前に必ずご確認ください

本シリーズで紹介するシステムは、**Google Workspace(Business Standard 以上のプラン)**の利用を前提に構築しています。

具体的には、以下の環境を組み合わせて動作します。

  • Google Apps Script (GAS) の実行環境

  • Google Gemini API の利用権限

  • Google スプレッドシート および AppSheet

上記環境がない場合、記事内の構成をそのまま再現することはできません。あらかじめご自身の環境をご確認ください。

🔐 AI利用に関する重要な注意事項

本シリーズでは、Gemini APIを利用して帳票データの処理を行います。 設定や契約プランによっては、入力データがサービス改善や学習に利用される可能性があります。そのため、実務への適用にあたっては以下のルールを必ず徹底してください。

  1. 個人情報(氏名・住所・電話番号等)をそのまま送信しない

  2. 取引先情報・価格・原価などの機密情報をそのまま送信しない

  3. 実運用では必ず「マスキング・ダミー化・匿名化」を行う

  4. 利用規約およびデータ取り扱いポリシーを事前に確認する

❗ 重要事項

実データをそのままAIに送信することは、情報漏洩のリスクを伴います。本記事の内容を実務に適用する際は、必ず自社のセキュリティポリシーおよび法令に従い、ご自身の責任のもとで運用してください。

本シリーズは、あくまで**「仕組み」と「設計思想」の共有**を目的としています。安全な環境設計を前提にご活用ください。


【最終確認】 上記の技術前提、およびセキュリティ上の注意事項について、内容を十分にご理解いただけない場合は、本記事の購入をお控えください。 > 現場の安全と責任ある運用のために、あらかじめご了承をお願いいたします。

ここから先は

3,272字
この記事のみ ¥ 1,200
Amazon Payで支払うと最大2%還元のチャンス! 9/30まで

ようこそ、Good Ruler 思考ログと道具箱へ 気付けば、営業DXの実験記録や『Good Rul…

道具箱プラン(実際のコード+アップデート配布)

¥3,980 / 月

よろしければ応援お願いします! いただいたチップはクリエイターとしての活動費に使わせていただきます!