「動けばいい」で書いたコードが、あとで自分の首を絞めることがあります。今回は、LINEと連携する自作のAI秘書botを作っていたときに、APIトークンをコードに直書きしてしまった話を書きます。恥ずかしい話ですが、同じように自分でAIツールを組んでいる方には、きっと役に立つと思うのです。
「とりあえず動かしたい」が招いたこと
秘書botの開発は、Claude Codeと一緒に少しずつ機能を積み上げていく作業でした。LINEからのメッセージを受け取り、Google Apps Script経由で処理し、返信を返す。仕組みそのものはシンプルですが、動作確認のたびに認証周りでつまずくと、集中力が切れてしまうんですよね。だから最初のうちは、LINEのアクセストークンをスクリプトの中に直接書いていました。変数に代入するだけの、いちばん手っ取り早いやり方です。うん。まさに「とりあえず動けばいい」の典型でした。
直書きの何が危ないのか
その場では何も起きません。むしろ快適です。でも、コードというのは一度書くと、驚くほど長く生き続けます。Gitの履歴に残り、バックアップに残り、誰かと画面共有したときにも映り込みます。GASのスクリプトはブラウザ上でも編集できてしまうので、共有設定を一つ間違えるだけで、トークンごと他人の目に触れる可能性もあるのです。動画制作の現場で編集画面を録画したり、作業の様子をそのまま共有したりする機会が多い僕にとって、これは他人事ではありませんでした。
しかも厄介なのは、あとから「トークンをコードから削除」しても、それだけでは安全にならないという点です。一度でも公開されたコミット履歴やログに残ってしまえば、そのトークン自体はもう「知られているかもしれないもの」として扱う必要があります。消した、では終わらないのです。
切り出し先を決める
実際に僕がやった整理は、動かしている環境によって置き場所を分けるというものでした。
- Google Apps Scriptで動かしている部分は、コード中の変数ではなく「スクリプトプロパティ」（PropertiesService）に保存し、コードからは参照だけする形に変更
- Node.js側で動かしている部分は、.envファイルに切り出し、dotenvで読み込む形に統一。.envは当然.gitignoreに入れて、リポジトリには一切含めない
この作業自体は、コードの動きを何も変えません。見た目としては地味な作業です。けれど「トークンが平文でコードの中に存在するかどうか」という一点だけで、リスクはまったく違うものになります。
公開履歴に残った鍵は、再発行する
整理の途中で、旧バージョンのbotそのものを廃止するタイミングがあり、そこでハードコードされていたLINEトークンを完全に除去するコミットを作りました。ただ、そこで終わりにはしませんでした。過去のコミット履歴に一度でも載ったトークンは、コードから消しただけでは「安全になった」とは言えないからです。LINE Developersの管理画面からトークンを再発行し、古い方は無効化しておきました。面倒ではありますが、ここを省略すると、せっかくの整理が意味を持たなくなってしまうのです。
自分でAIツールを作る事業者だからこそ
自分でAIツールを組む事業者として、最低限これだけは守ろうと決めたことがあります。
- トークンやAPIキーは、書いたその日のうちに環境変数か専用の保存先に移す
- 一度でも人に見せた・公開履歴に残ったキーは、消すのではなく再発行する
- 外部と連携するbotほど、認証情報の置き場所を一覧にしておく
今は誰でも、Claude Codeのようなツールを使えば、業務用のAI秘書やbotを自分の手で組めてしまう時代です。それはとても良いことだと思う一方で、セキュリティの基本を教わる機会がないまま、いきなり本番運用に踏み込んでしまうことも起こり得ます。僕自身、動画制作が本業で、コードは独学に近い状態です。だからこそ「動けば正解」で終わらせず、認証情報の置き場所と再発行のタイミングだけは、最低限のルールとして持っておきたいと思っています。
自社の業務にAIツールを組み込みたい、けれどセキュリティ面が不安、という方は、ご相談はお問い合わせからどうぞ。
この記事を1枚で（グラレコ）
