はじめに：前回のおさらいと今回のゴール
こんにちはクサハラです。
「AIが事務仕事を奪う」というニュースを見るたび、正直穏やかではいられません。子どもが大きくなるまでに自分の仕事がなくなっては困る。だったら奪われる側で怯えるより、使いこなす側に回りたい。そう思ってAIの勉強を始め、まずは練習として個人利用の資産管理アプリ作りに挑戦しています。
この記事は、全３回の記事の２回目です。
前回の記事では、Claudeで資産管理アプリを作ろうとしたところ、セキュリティ上の懸念で手が止まった経緯をお伝えしました。
Googleスプレッドシートとアプリを連携するために、スプレッドシートを「全員に公開」にする方法で進めていたことが判明。URLさえわかれば誰にでも中身が見られてしまう、というのはなんとも気持ちが悪い。ということで、設計を見直すことになった、という状況でした。
今回は、そのセキュリティ強化対策の顛末をまとめます。
先に結論から言えば、またもや失敗となってしまいました。
試み①：GASトークン方式ー「漏れるリスクがある」で断念
「セキュリティが気になるから見直してほしい」とお願いしたところ、Claudeから最初に提案されたのは、GAS（Google Apps Script）のトークンを使う方式でした。
GASは前回も提案されたのですが、よくわからないので避けた方式です。
今度こそちゃんと調べる！
GASとは、Googleが提供する、プログラムを書いて実行できる仕組みのこと。スプレッドシートやGmailなどのGoogleサービスを自動化したり、外部のアプリと連携させたりできます。オフィスで言うところのVBAのようなものだそうです。
この方式のざっくりした仕組みはこんな感じでした。
- GASでスプレッドシートのデータを取り出す「窓口」を作る
- アクセスできる人を限定するための「トークン（合言葉のようなもの）」を設定する
- アプリはそのトークンを使って、GASの窓口経由でデータを受け取る
これなら「全員に公開」にしなくて済みます。窓にはちゃんと鍵がかかっているので、誰でも通れるわけではありません。
GASのプログラムなんて自分では書けませんが、Claudeが書いてくれるというので、「うん、これでいいじゃん」と即決しそうになりました。
ただ、具体的に確認していくうちに、問題が見えてきました。トークンをどこかに保管しなければならない、という点です。
アプリのプログラムの中にトークンを書き込んでおく方法が一般的だそうですが、そうするとアプリのファイルを見られた場合に、トークンごと漏れてしまう可能性があります。
今回のアプリは個人利用で、誰かに共有しようとも考えていません。家のPCとスマホに入れるだけなので、使うのは自分と、せいぜい家族くらい。アプリの内部まで除かれるリスクはほとんどなさそうです。
ただ、将来的には業務用のアプリ開発も見据えています。今のうちに、もっとセキュリティの堅い方法を勉強しておいた方が、後々の役に立ちそうだと思い直しました。
というわけで、この方式は見送り、別の方法を探すことにしました。
試み②：Googleアカウント認証（OAuth）ー「やっぱり無理」だった顛末
別の方法を考えているときに思いつきました。
「GoogleスプレッドシートはGoogleのサービスなんだから、Googleアカウントにログインしている人だけが見に行けるようにできるんじゃないのか？」
アプリ自体もブラウザを立ち上げて使うのだし、そのブラウザがGoogleにログインしていれば、自動的にスプレッドシートも使える。とてもスマートな仕組み。素敵。
Claudeに「こんなことできる？」と投げかけると、「できますよ」と軽い調子で返ってきます。さも簡単に実装できそうな印象を受け、「じゃあそれで行こう」と決めました。
自分が思いついた案だったので、前のめりになってしまいました。後になって思えば、これが間違いでした。
具体的には、OAuth認証という仕組みを使う方法です。
OAuth（オーオース）とは、IDやパスワードそのものを渡さずに、他のサービス（アプリやサイト）へ自分のデータへの限定的なアクセス権を与えるための仕組みのこと。Webサービスでよく見る「Googleでログイン」「LINEでログイン」といったボタンが、まさにこれにあたります。
これなら、自分のGoogleアカウントでログインした人だけがスプレッドシートにアクセスできる構成になります。ログインできない人はアクセスできない、という当たり前の状態になるわけですから、セキュリティとしては、これまで通りGoogleのIDとパスワードを管理するだけです。これは最高。理想的。
Claudeがサクサクとコードを書き、出来上がってきたものにあれこれ注文をつけ、アプリはどんどん形になっていきます。Googleアカウントの設定もClaudeに教えてもらいながら一歩ずつ進め、うまくいかない場面でも、画面に表示されたエラー文言をそのままコピーして貼り付ければ、的確に対処法を教えてくれる。
AIの進歩は目覚ましい。未来はわが手の中に！
もうすぐ完成するぞ、とわくわくしていました。
ところが作業の終盤、画面の表示をまたClaudeに貼り付けて確認を求めたところ、返ってきたのは予想外の答えでした。
「この方法は、HTMLファイルをそのままブラウザで開く場合には対応が難しいかもしれません」
「できる」と言っていたはずのClaudeが、終盤になって「やっぱり無理かもしれない」と言い出したのです。
完全に無理だというのではなく、「やっぱり不安になってきた、無理かも」という印象だったのが、とても人間的で面白い。そうはいっても出来るんじゃない、だってできるって言ってたもん、と半信半疑でそのまま進めました。
結果として、ダメでした。
わたしが作っていたのは、HTMLファイルを自分のPCに置き、それをブラウザで開くだけのシンプルなアプリです。HTMLで作ったアプリをそのままブラウザで開く形式では、GoogleアカウントのOAuth認証は使えない、とのこと。
「先に調べといてよ」と、心からそう思いました。
AIは質問者を肯定することが多いように感じます。「こんなアイデアはどう？」と聞けば、「素晴らしい」と褒めてくれます。「できる？」と聞けば、なるべく「できます」という答えを返そうとするのかもしれません。
聞き方が悪かったのかもしれません。これは大きな反省点です。
反省してみたところで、作業がかなり進んでから「無理でした」となった徒労感は消えません。本当にこのアプリは完成するのか、素人がAIに頼ってアプリを作ろうというのがそもそも無理なのではないか、と不安にもなりました。
この失敗から感じたこと
今回の試みを通じて、AIを使ったアプリ開発の難しさを改めて実感しました。
一番大きな気づきは、AIの「できます」には、条件付きの場合がある、ということです。
ClaudeはOAuth認証について「できます」と答えました。それ自体、嘘ではないのでしょう。
OAuth認証は技術的には確かに可能な仕組みのようです。ただし、今回のようにHTMLファイルをローカルで開く形式では、Googleの仕様上うまく通らない、という落とし穴があったのです。Claudeはそこまで確認していなかったし、わたしはそんな落とし穴があるなんて思いもつきませんでした。
こうした「できます」の落とし穴は、多少の知識があれば防げたのだろうと思います。ですが、知識がないということは、そもそも何を確認すればいいかすら分からない、ということでもあります。
作っているアプリがどういう仕組みで動いているのか、自分がある程度把握していれば、「この構成でOAuth認証は本当に成立するのか？」と先にAIに確認できたはずです。しかし仕組みを理解していない状態では、AIが提示した答えにただ追従することになってしまいます。
ひとり総務としての限られた隙間時間で開発を進めていることもあり、「できるならそれでいい」と流してしまいがちなのですが、最低限、自分が理解できるところまでは質問を重ねる必要があったと反省しています。
「AIに丸投げするのは良くない」という基本的なことを、あらためて思い知らされました。
まとめと次回予告
今回の試みをまとめると、次のようになります。
- ①GASトークン方式：トークンの漏洩リスクが気になり見送り
- ②Googleアカウント認証（OAuth）：ローカルにアプリを置いて使う方式では、現実的に機能しないことが判明
次回は、ローカルではなくサーバー上にアプリを置く、という選択肢と、実際にアプリが動くようになるまでの過程をお伝えします。
最後まで読んでいただきありがとうございました。
後編もよろしくお願いします。
※本記事は筆者個人の体験・記録であり、特定の設定方法やツールの利用を推奨するものではありません。セキュリティに関する設定は、必ずご自身でも最新の情報をご確認ください。
コメント