100の実験｜No.010 続編
こんな人に役立つ実験です
- GASのWebアプリを、自分以外の人にも使ってもらいたい
- 自分には見えるのに、相手には見えない状態で困っている
- AIと一緒に不具合を調べる進め方を知りたい
はじめに
自分のアカウントでは開けるのに、別の人のアカウントではページが開かない。GASで小さなWebアプリを作っていると、コードを見直しても原因が見つからないことがあります。
今回は、家族で使うYouTube動画整理ツールで起きたアクセス障害を、Codexと一緒に切り分けました。調べて分かったのは、問題がコードの書き間違いだけではなく、Googleアカウントのセッション取得と認証方式の設計にあったことです。
この記事では、実際に試した確認手順、うまくいかなかった対応、最終的に設計を変更した理由を記録します。
今回検証したのは、AIエージェントと一緒に原因不明のアクセス障害を切り分け、認証方式を見直し、実際に利用者が使える状態まで持っていけるかということです。
今回作ったもの
今回の成果物は、夫用ページが安定して開けるようになった既存ツールの改善版です。
主な変更点は以下です。
- メールアドレス照合による認証方式を見直した
- URLに専用の合言葉（アクセストークン）を埋め込む方式へ変更した
- 夫婦のページ両方が安定して開ける状態にした
- 夫用のカテゴリタブを本格稼働させた
- 「注目動画」タブを正しく動かした
- 注目動画に日本語コンテンツを優先するための言語フィルタを追加した
結果として、夫のページでは「仕事・旅行・エンタメ・ゲーム」のカテゴリタブと、「注目動画」が機能するようになりました。
注目動画では、Mac mini、リモート接続、MacBook Air、AIソロプレナーの4キーワードを扱っています。
なぜこのテーマにしたのか
前回の実験で、カテゴリタブと「後で見る」機能の方向性はかなり見えてきました。
ただし、実際に使う人のページで開けなければ意味がありません。
今回は、夫用ページを新設したものの、開発用URLが開けないという問題から始まりました。
最初は、Config_Usersに登録しているメールアドレスの照合ミスを疑いました。
しかし、何度確認・修正しても解決しません。
この時点で、単なる入力ミスではなく、認証方式やデプロイ設定そのものを見直す必要が出てきました。
今回の設計
最終的には、Googleアカウントのメールアドレスを取得して照合する方式をやめました。
代わりに、URLに専用の合言葉（アクセストークン）を埋め込む方式に切り替えました。
この設計にした理由は、Google Apps ScriptのWebアプリ環境では、Session.getActiveUser().getEmail() がブラウザやアカウント状態によって安定しない場合があるためです。
メールアドレス照合に依存すると、設定は正しくても画面が開けない可能性があります。
一方で、アクセストークン方式なら、正しいURLを開ける人は表示できるというシンプルな仕組みにできます。
もちろん、これは本格的なログイン認証ではありません。
ただ、今回のような家族内・個人運用の小さなツールでは、環境に依存しにくい現実的な方法だと判断しました。
AIエージェントに任せたこと
今回、AIエージェントには以下を任せました。
- アクセス不能の原因切り分け
- Config_Usersのメールアドレス照合の確認
- Web Appのデプロイ設定の確認
Session.getActiveUser().getEmail()の挙動に関する仮説整理- アクセストークン方式への設計変更
- 夫ページのカテゴリ表示確認
- 注目動画データの混入原因調査
- 日本語コンテンツ判定ロジックの追加
- 削除事故や不要文字混入時の原因特定
- ログをもとにした復元・修正方針の整理
一方で、人間側で判断したこともあります。
- ページを実際に開いて確認すること
- デプロイ設定を画面上で確認すること
- メールアドレス照合方式を諦める判断
- アクセストークン方式を採用する判断
- 日本語動画を優先したいという運用方針
- 過去のバージョン履歴から必要な関数だけを復元すること
実際にできたこと
今回の作業は、大きく3つに分かれました。
アクセス不能の切り分け
最初に疑ったのは、Config_Usersに登録したメールアドレスの照合でした。
しかし、メールアドレスを何度確認しても、ご主人用ページは開けませんでした。
次に確認したのが、Web Appのデプロイ設定です。
そこで、「アクセスできるユーザー」が「自分のみ」に変わってしまっていたことがわかりました。
この設定を修正したことで一歩前進しましたが、まだ別のエラーが残りました。
次に出てきたのが、
Googleアカウントのメールアドレスを取得できませんというエラーです。
デプロイの公開範囲設定自体は正しくなっていたため、原因はGoogle側のセッション取得の仕組みにあると判断しました。
最終的に、Session.getActiveUser().getEmail() に依存する認証方式から、URLに専用の合言葉を入れるアクセストークン方式へ変更しました。
これにより、「正しいURLを開けば必ず表示される」という、ブラウザ環境に依存しにくい仕組みになりました。
夫ページの本格稼働
アクセス問題が解決したあと、夫のページを実際に見てみると、新たな不具合が見つかりました。
主な症状は以下です。
- 自分のページで「未分類」タブに40件も動画が集まっている
- 夫のページで「旅行」カテゴリが0件のまま
- 夫ページの「注目動画」タブが0件
調査の結果、「注目動画」用に集めた動画データが、誤って通常のジャンル分けロジックにも混入していたことがわかりました。
注目動画由来の動画は、本来ジャンル分けの対象外です。
しかし、それが漏れて通常カテゴリ側に流れ込み、「未分類」に大量に押し込まれていました。
該当箇所を修正し、通常のカテゴリ表示と注目動画の扱いを分離しました。
注目動画が海外動画ばかりになる問題
「注目動画」タブでは、さらに別の問題も見つかりました。
表示される動画が、日本語ではなく英語やドイツ語の動画ばかりだったのです。
原因は、検索キーワードにありました。
Mac mini、MacBook Airなどのキーワードは英語表記です。
そのため、YouTube側の検索が世界中の英語圏動画を多く拾ってしまっていました。
そこで、タイトルや説明文に日本語の文字が含まれているかを判定し、日本語が含まれない動画を除外する仕組みを追加しました。
導入後は、日本語動画が明確に増え、狙いに近い注目動画タブになりました。
今回発生したトラブルと対処
今回も、実装中にいくつかのヒヤリハットがありました。
中核関数を削除してしまった事故
一時的な検証用コードを片付ける作業中、行数を思い違えたまま削除操作を行ってしまいました。
その結果、「注目動画」機能の中核となる関数を3つ、丸ごと消してしまう事故が発生しました。
ただし、今回はすぐに異常に気づくことができました。
過去のバージョン履歴から該当部分だけを正確に復元し、問題を解決しました。
この経験から、検証用コードの削除は、想像以上に慎重に行う必要があると感じました。
余計な文字列がコードに混入した問題
別の検証作業中には、キーボード操作の誤操作によって、コードの中に余計な文字列が混入しました。
具体的には、Page_Down という単語がコード内に紛れ込み、機能全体が一時的にエラーになりました。
これもログからすぐに発見し、修正できました。
今回のように、原因が小さな入力ミスでも、コード全体が動かなくなることがあります。
ログ確認の重要性を改めて感じました。
同じトラブルが起きたときの確認順
今回の経験から、GASのWebアプリが別のアカウントで開けないときは、次の順番で確認すると原因を絞りやすいと感じました。
- Webアプリの公開範囲を確認する
- 開いているURLが開発用か本番用か確認する
- 利用者のGoogleアカウントとブラウザ環境を確認する
- セッションからメールアドレスを取得できているかログで確認する
- コード修正だけで解決しない場合は、認証方式そのものを見直す
これは今回の実験から得た確認順です。すべてのアクセス障害に同じ原因が当てはまるわけではありませんが、コードだけを何度も直す前に、公開設定と利用環境を確認することが大切です。
使ってみた感想
今回は、これまでで一番長引いたトラブルシューティングだったと感じました。
最初は、メールアドレスの照合がうまくいっていないだけだと思っていました。
しかし実際には、Web Appの公開範囲、Googleアカウントのセッション取得、ブラウザ環境、認証方式の設計が絡んでいました。
特に、Session.getActiveUser().getEmail() が期待通りに動かない可能性があることは、実際に詰まってみないとわかりにくい部分でした。
最終的に、メールアドレス照合という考え方そのものをやめ、アクセストークン方式に切り替えたことで解決できたのは大きかったです。
また、夫のページを実際に見たことで、カテゴリ表示や注目動画の問題も発見できました。
作ったものは、実際に使う人の環境で見ないと、本当の問題が見えてこないと感じました。
わかったこと
今回わかったのは、不具合の原因がコードそのものだけにあるとは限らないということです。
アクセスできない原因は、メールアドレスの入力ミスではなく、デプロイ設定やGoogle側のセッション取得仕様、認証方式の選び方にありました。
また、注目動画が海外動画ばかりになる問題も、コードのバグというより、検索キーワードとYouTube検索の性質によるものでした。
AIエージェントと一緒に進めることで、原因を一つずつ切り分け、最終的には設計変更まで踏み込めました。
一方で、削除事故や誤入力のようなヒヤリハットもありました。
AIと一緒に作業していても、人間側の操作ミスは起こります。
だからこそ、バージョン履歴、ログ確認、実行前の目視確認が大切だとわかりました。
次に改善したいこと
今後改善するなら、以下を試したいです。
- アクセストークン方式の管理ルールを整理する
- URLを共有する相手と用途を明確にする
- トークンが漏れた場合に変更できる手順を作る
- 夫ページ専用の設定確認チェックリストを作る
- 注目動画の日本語判定をさらに精度よくする
- 日本語動画が少ない場合の代替表示を検討する
- 検証用コード削除前のバックアップ手順を固定化する
- Apps Scriptエディタでの実行前確認ルールを明文化する
今回の結論
AIエージェントと一緒に、原因不明のページ非表示トラブルを切り分け、認証方式そのものを見直すことで、ご主人用ページを安定して開ける状態にできました。
ただし、今回の解決策であるアクセストークン方式は、本格的なログイン認証ではありません。
今回の成果物は完成版の認証システムではなく、個人・家族内で使うGASツールを、実際に動く形へ近づけるための現実的なMVP改善として記録します。
実験データ
- 実験番号：No.010 続編
- テーマ：AIエージェントと一緒に「ページ非表示トラブル」は解決できるか？
- ステータス：修正・本番反映済み
- 使用AI：Codex
- 成果物：夫婦の両方で安定して開ける既存ツールの改善版
- 使用技術：Google Apps Script（GAS） / HTML / CSS / JavaScript / Googleスプレッドシート / アクセストークン方式
- GitHubリポジトリ：なし
- 公開URL：非公開または内部運用
- 今回の結論：AIエージェントと一緒に、長引いたアクセス障害を切り分け、認証方式の設計変更まで踏み込んで解決できた
AIやGASで作った小さな仕組みが「自分の環境では動くのに、利用者には使えない」という状態になったときは、コードだけでなく、公開設定や運用方法も含めて整理する必要があります。「どこから確認すればよいか分からない」という場合は、お問い合わせから状況をお聞かせください。
コメント