TL;DR

LINEチャネルとトークンは有効で、コードは筆者の環境に移せば動いた。
確定できた問題は1点、LINEに登録されたWebhook URLが、
調査していたGASプロジェクトのものではなかったこと。
同じコードを持つ別プロジェクトのURLは、dogetを叩いても同じ応答を返す。
URLが応答することは、正しく繋がっている証拠にならない。
切り分けの決め手は、GASの「実行数」ログ。叩いてもログが増えないなら、そのURLは今見ているプロジェクトに届いていない。

何が起きたか

「グループで話しかけても、返事が来ない」。
福祉施設に導入予定のBot（GAS + LINE Messaging API + Gemini）が一度も返事をしないという相談で、担当者が2日試行錯誤したあと、筆者が調査を引き継いだ。

コードは筆者の環境で動作実績あり。LINE側の応答設定も正しい。デプロイのアクセス権も「全員」。全部シロに見えるのに、動かない。

構成は4部品しかない

LINEグループの発言
 → ① LINE側設定（Webhook利用ON・応答メッセージOFF）
 → ② Webhook URL（GASのウェブアプリURL）
 → ③ GASコード（doPost → Gemini → reply API）
 → ④ スクリプトプロパティ（トークン2つ）
 → 返信

沈黙の原因はこの4つのどれかで、それ以外はない。まず同じコードを筆者のGASと筆者のLINEチャネルで動かしたら、あっさり返事が来た。

③ GASコードはシロ。 ① LINE側設定（Webhook利用ON・応答メッセージOFF）も設定を見比べてほぼシロ。

残るは② Webhook URLと④ スクリプトプロパティ（トークン2つ）。

罠：失敗に見えるものが2つある

LINE Developersの「検証」ボタンは「302 Found」のエラーを出すが、
GASのウェブアプリはリダイレクトを返すため、正しく繋がっていてもこれは出うる。
判断材料として弱い。（筆者もこのエラー状況でBotは返事をしている）

Webhook URLをブラウザで開くと「スクリプト関数が見つかりません: doGet」と返る。デプロイは生きているように見える。だが、同じコードを持つ別プロジェクトのURLもまったく同じ応答を返す。URLの応答は、どのプロジェクトに繋がっているかを何も証明しない。

なお、ブラウザで開いた分は実行数に「doGet 失敗」として記録される。
これは故障ではない。

このコードにdoGet関数が無いため、GETは必ず失敗になる。LINEが送るのはPOSTだけなので、Botの動作にも影響しない。

ここで重要なことは、『doget』を叩いたら、『実行』に何かしらログが残ること、
そのものである。

決め手：実行数ログ

GASエディタ左メニューの「実行数」に、答えが出ていた。

このプロジェクトには、外部からdoGetを叩いた
記録が実行数に残ることを7/3以前に確認できていた。

ところが、7/5以降、LINEに登録されているURLを叩いても、ログは増えなかった。

同じ操作で、残るはずの記録が残らない。
そのURLは、今見ているプロジェクトに届いていない。

Webhookは最初から別の場所に飛んでいた これが沈黙の直接原因だった。

復旧

壊れた環境の修復には権限の壁があったため
（他人のプロジェクトはデプロイ操作を弾かれる場合がある）、

動作実証済みの筆者のGASに本番チャネルのトークンを入れて繋ぎ替えた。
作業はトークンの差し替えとURLの貼り替えの2つ、それで復旧した。

もちろん今は仮で私のGASで稼働しているので、将来的には相手方施設のドライブに
お引越しをする必要はあるだろう。

想定外のURLがどの操作で登録されたのかは、
最後まで特定できていない。

多重ログイン自体が毒というより、
「意図しないアカウントでGASを開いてデプロイしてしまう」　とURLが曖昧になる。

①トラブル対応中に「新しいデプロイの発行し直し」「別アカウントでのGAS作り直し」が繰り返され、URLとプロジェクトの数が増えていたこと、

②そして増やしたあとに『実行数』で「通信が届いたか」を確認する手順がなかったこと。

・・・『AIの対処療法の構造の穴』として言えるのはここまで、
それで対策には十分だった。

経緯の解明と問題の解決は、切り離していい。

APIで配線を確認する

トークンさえあれば、相手の画面を見なくても配線を確認できる。

function 診断() {
  const token = PropertiesService.getScriptProperties().getProperty('LINE_ACCESS_TOKEN');
  const opt = { headers: { Authorization: 'Bearer ' + token }, muteHttpExceptions: true };

  const info = UrlFetchApp.fetch('https://api.line.me/v2/bot/info', opt);
  console.log('① bot info: ' + info.getContentText());

  const ep = UrlFetchApp.fetch('https://api.line.me/v2/bot/channel/webhook/endpoint', opt);
  console.log('② webhook: ' + ep.getContentText());
}

①が401 → トークンが無効
①のdisplayNameが想定と違う → チャネルの取り違え
②のendpointが想定と違う → URLの取り違え。active: false ならWebhook利用がOFF

復旧後にこの診断を元の環境で実行したところ、トークンは有効だった。壊れていたと確定できたのは、やはりURLの接続だけだった。

予防策

コードの更新は「デプロイを管理」から既存デプロイの編集で行う。
URLが変わらないので、貼り替え作業そのものが消える。
「新しいデプロイ」はURLを変えたい時だけ。
URLを貼り替えたら、実行数ログで「ログが増えること」をその場で確認する。
doget応答が返ることは確認にならない。
AIによる対処法リストを実行する前に『この手順のどこで、直ったと確認できるのか』を問う。
確認手順のない対処法は、状態を変えるだけで何も教えてくれない。

チェックリスト（Botが沈黙したとき）

「実行数」を開き、メッセージ送信の直後に新しい行が増えるかを見る
増えない → 通信が届いていない。Webhook URLとLINE側の「Webhookの利用」を疑う
増えて「失敗」 → 通信は届いている。コードかスクリプトプロパティを疑う
実行数の「doGet 失敗」に慌てない。ブラウザでURLを開いた痕跡で、doGet関数が無いコードでは仕様。むしろ「叩けばログに残る」ことの確認になる
URLが応答しても、正しく繋がっている証拠にしない
「検証」の302だけで不通と断定しない。成否は実行数ログで見る
デプロイ前に、右上のアカウントと開いているプロジェクト名を見る。別プロジェクトのURLを貼ると、沈黙するか、「管理していないプロジェクトが本番として動く」かのどちらかになる
壊れた環境に固執しない。実証済みのGASとトークンへの差し替えで、経緯不明のまま復旧できる