パスワードをチャットに残さない｜“読んだら消える”ワンタイム共有ツール「秘密の玉手箱」を作りました

そのパスワード、チャットに送っていませんか？

「あとでパスワード送っておきますね」。マンチーは、この一言を何度言ってきたか分かりません。そして、そのたびに、ほんの少しだけ胃のあたりがざわっとしていました。

送ったパスワードは、どこに残るのか。相手がいつ読むのか。読んだあと、誰かがその画面をのぞかないか。考え出すと、きりがありません。

そこで作りました。秘密の玉手箱です。

自作セキュリティツールの第4弾として、今日はこの玉手箱の中身を、ぜんぶ書きます。

まず自己紹介：マンチーは、セキュリティ面もしっかり意識して作っています

バイブコーディング(AIに指示を出しながらアプリを作っていく開発スタイル)でアプリを作っている、マンチーです。

「AIで作ったアプリなんて、セキュリティがスカスカでしょ？」と思われることがあります。たしかに、何も考えずに作れば、そうなりがちです。

でも、マンチーは作るときに、必ずセキュリティ面を一緒に考えます。ここは、はっきり言わせてください。

そしてそれができているのは、本当に、ClaudeとAWSのおかげです。

• Claudeが、設計の段階から「ここは危ないですよ」と一緒に考えてくれる

• AWSが、認証や権限管理の部品を、最初から用意してくれている

この2つがなければ、個人でここまで作ることはできませんでした。

ここまでの自作セキュリティツール

これまでに、こんなものを作ってきました。

• テスター管理サイト(アプリを試してくれる人だけに、限定してURLを渡す仕組み)

• SSO認証kit(一度のログインで、複数のアプリに入れる仕組み)

• 二段階認証(スマホの認証アプリの6けたの数字で、本人確認を重ねる仕組み)

そして第4弾が、今日の主役、秘密の玉手箱です。

秘密の玉手箱とは？ひとことで言うと「読んだら消える、秘密の受け渡し箱」

仕組みは、びっくりするほどシンプル

使い方は、これだけです。

1. 送りたいメッセージ(パスワードなど)か、ファイルを、箱に入れる

2. 一回しか開けないリンクが発行される

3. そのリンクを、相手に送る

4. 相手がリンクを開くと、中身が表示されて、そのまま箱ごと消える

一度開いたら、もう二度と見られません。リンクを開いた人が受け取った瞬間に、中身はこの世から消えます。

開けなくても、勝手に消えます

「相手が開いてくれなかったら、箱はずっと残るの？」という心配は、いりません。

保存できる時間は、最初に自分で決めます。1時間から24時間までで、何も決めなければ24時間です。時間が来たら、誰も開けていなくても、自動で消えます。

入れられるもの

• メッセージ：最大10KBまで(文字でいうと、数千文字ぶんです)

• ファイル：最大10MBまで

• メッセージとファイルを、同時に入れることもできます

パスワードや認証コード、ちょっとした設定ファイルを渡すには、十分な大きさです。大きなファイルを運ぶためのサービスではなく、あくまで「大事なものを、短い間だけ、安全に渡す」ためのものです。

実際の画面を、順番に見てみましょう

文字だけだと分かりにくいので、使う流れを、3つの画面で説明します。

画面①：送信画面(箱に入れる)

最初に開くのは、送信画面です。メッセージを入力するか、ファイルをドラッグして置きます。その下で、保存する時間を選びます。

ボタンを押すと、リンクが1本、発行されます。見た目はシンプルにして、迷わず使えることを優先しました。

画面②：受信画面(箱を開ける前)

相手がリンクを開くと、まず表示されるのは、中身ではありません。「メッセージが届いています」という画面です。

そこには、「このメッセージは1回だけ読めます」と書かれています。さらに、「内容を表示を押した瞬間に、サーバーからメッセージは完全に削除されます。準備ができてから押してください」という注意書きも出ます。

先ほどの設計が、ここで生きています。この時点では、箱の中身はまだ消えていません。相手が自分の意思で「内容を表示(1回のみ)」のボタンを押して、はじめて中身が出てきます。ファイルの場合は、「ダウンロード(1回のみ)」のボタンです。

画面③：開封後(もう二度と見られない)

開封すると、メッセージが表示されます。ファイルなら、ダウンロードが始まります。そして、同じリンクをもう一度開くと、こう表示されます。

「このリンクは使用済みです」

「読んだら、本当に消えた」。この手応えが、いちばんの安心感でした。

こんな場面で使えます

場面①：取引先や同僚に、初期パスワードを渡すとき

新しいアカウントを作って、初期パスワードを伝える場面は、とても多いです。そのとき、チャットに貼るかわりに、玉手箱のリンクを送る。それだけで、履歴に残るのは「もう開けないリンク」だけになります。

場面②：認証コードや、一時的な合言葉を渡すとき

その場だけ使えればいい情報は、時間が来たら消える仕組みと、相性ぴったりです。保存時間を1時間にしておけば、うっかり放置されても、すぐ消えます。

場面③：設定ファイルを、ちょっと渡したいとき

メールに添付すると、送信済みフォルダにも、相手の受信箱にも、ずっと残ります。玉手箱なら、受け取ったら消えます。10MBまでなので、設定ファイルくらいなら、十分に収まります。

使うときのコツ：リンクと中身は、別の道で送る

ひとつだけ、おすすめの使い方があります。リンクを送る手段と、「このリンクを送りました」と連絡する手段を、分けることです。

たとえば、リンクはメールで送り、「いま送りました」という連絡は電話やチャットで入れる。こうすると、万が一リンクが他の人の目に触れても、気づくことができます。「開こうとしたら、もう消えていた」となれば、それが異常のサインになるからです。

切り口①：パスワードを、そのまま送っていませんか？

ここからは、なぜこんなものを作ったのか、3つの切り口でお話しします。まず1つめです。

「あとで送ります」の、あとが危ない

パスワードを渡すとき、みなさんはどうしていますか。

• チャットにそのまま貼る

• メールの本文に書く

• 添付ファイルにして送る

マンチーも、仕事で何度もやってきました。みんな、やっています。でも、冷静に考えると、これは結構こわいことです。

送ったものは、思ったより長く残ります

チャットも、メールも、基本は履歴として残り続けます。送った本人の画面にも、受け取った相手の画面にも。

しかも、残るのは、その2人の画面だけではありません。端末のバックアップ、通知の表示、画面の共有、同じアカウントを使っている別の端末。数えると、意外とあちこちに散らばります。

つまり、パスワードを送った瞬間に、その情報の「コピー」が、あちこちに生まれているということです。

本当に怖いのは、派手な攻撃より、地味な「残りもの」

情報漏洩というと、ハッカーが高度な攻撃をしかけてくる場面を思い浮かべる人が多いと思います。でも、実際の現場でよく起きるのは、もっと地味な話です。

• 昔のチャット履歴に、パスワードが残っていた

• 退職した人のメールボックスに、認証情報が残っていた

• 共有フォルダに置いたファイルが、そのまま放置されていた

どれも、誰かが悪さをしたわけではありません。「残っていた」だけです。

だから、マンチーはこう考えました。渡し終わったら、消えるようにしておけばいい、と。

切り口②：読んだら消える。シンプルな機能ほど、設計は奥が深い

2つめは、作っていて気づいた、設計の話です。

実は「古い機能」です

正直に言うと、「一度だけ見られるリンク」は、新しいアイデアではありません。似たようなサービスは、もう何年も前からあります。

でも、マンチーはこう思っています。古いからダメなのではなく、古くから使われ続けているのは、それだけ必要とされているからです。

パスワードを安全に渡したい、という悩みは、昔も今も変わりません。変わったのは、扱う情報が増えて、漏れたときの被害が大きくなったことだけです。

似た機能は、大手のアプリにも入っています

ここで、マンチーが調べてみて分かったことがあります。

「読んだら消える」「期限が来たら消える」に近い機能は、実は身近なアプリの中に、おまけとして入っていることが多いのです。そして、その機能だけに絞った、シンプルな単体のツールは、マンチーが調べた範囲では、あまり多くありませんでした。あっても海外のサービスが中心で、日本語で気軽に使えるものは、見つけにくい印象です。

つまり、「機能は世の中にある。でも、大きなアプリの一部になっていて、使いたいときに使いにくい」という状態です。

比較① メールソフトの機密モード

メールの機能として、見られる期限を決めたり、転送やコピーを制限したりするものがあります。Gmailの情報保護モードが代表例です。

公開されている解説記事(2020年)によると、期限は「1日後」「1週間後」「1か月後」などから選ぶ形で、最短でも1日です。また、受け取る人のメールソフトによっては、追加の認証が必要になる場合があるとされています。

使い慣れたメールの中で完結するのは、大きな利点です。ただ、メールという性質上、送ったという記録そのものは、メールに残り続けます。

比較② ファイル転送サービス

大きなファイルを送るためのサービスにも、パスワードの設定、有効期限、ダウンロード回数の制限といった機能があります。

ただ、こうしたサービスは、そもそも数GBから数百GBといった大きなファイルを運ぶのが目的です。保存期間も、数日から100日ほどのものが多く、無料版には広告や機能の制限がある場合もあります。

パスワードを一言だけ渡したい、という用途には、少し大げさです。

比較③ パスワード管理ツールの一時共有機能

いちばん近いのは、パスワード管理ツールにある、一時共有の機能です。たとえばBitwardenのSendという機能は、期限、閲覧回数の制限、閲覧後の削除ができ、ファイルやメモも共有できます。

機能だけなら、玉手箱と同じことができます。ただし、その機能を使うには、パスワード管理ツールそのものを導入して使っていることが前提です。「ちょっと一回だけ渡したい」ために、ツール全体を入れるのは、人によってはハードルが高いと思います。

比較④ 単体のワンタイムシークレットサービス

単体のサービスもあります。ただ、あるサービスでは、パスワードの設定が必須で、無料で作れる回数に制限があり、繰り返し使うには有料プランが必要な作りでした。しかも、保存データがすぐに削除されることは、保証されていないとも書かれていました。

玉手箱ならではの強み

こうして並べてみて、マンチーが「自分で作った意味はあった」と思えた点をまとめます。

• 単機能で、迷わない：やることは「入れる、リンクを送る、開けたら消える」だけです

• 受け取る側は、登録もインストールも不要：リンクを開くだけです

• 短い時間に特化している：保存は1時間から24時間。数日も残しません

• 取り出した瞬間に、サーバーから削除する作り：開いたあとの中身は、もう箱の中にありません

• 自分のAWSの中で動く：どこに何が保存されるのか、全部自分で確認できます

• 広告がなく、使った分だけの課金：維持費を抑えたまま、続けられます

• 欲しい機能を、自分で足せる：合言葉の追加など、必要に応じて育てられます

正直に言うと、大手の方が優れているところもあります

フェアに書いておきます。

大きなサービスには、サポート体制、利用履歴を残す監査の機能、運営会社による長年の運用実績があります。大容量のファイルも扱えます。「誰が運営しているのか分からないものに、機密を預けたくない」という気持ちは、玉手箱にも当てはまります。個人が運営しているからです。

だからマンチーは、玉手箱を「万人向け」だとは言いません。自分のAWSの中で、小さく、確実に使いたい。そういう人のための道具として作りました。

それでも自分で作った理由

では、なぜ既存のサービスを使わず、自分で作ったのか。理由は3つあります。

• 大事な情報を、素性の分からない外部サービスに預けたくない

• 自分のAWSの中で動かせば、仕組みを全部自分で確認できる

• 使った分だけ課金される構成なので、使わない時間は、ほとんどお金がかからない

特に3つめは、個人開発では大事なポイントです。サーバーレス(常にサーバーを立てておかなくても、必要なときだけ動く仕組み)で作れば、毎月の固定費に悩まされずに済みます。

「見るだけ」と「取り出す」は、別のものにしました

ここが、設計でいちばん気を使ったところです。

リンクを開いた瞬間に中身が消える仕組みだと、困ることがあります。たとえば、チャットアプリやメールソフトには、貼られたリンクの中身を事前に読み込んで、プレビューを表示する機能があります。

この機能が、リンクを「開いた」と勘違いしてしまうと、本当の相手が開く前に、箱が消えてしまいます。

そこで、マンチーの玉手箱は、こうしました。

• 「箱がまだあるか」を確認するだけの窓口(中身は消さない)

• 「中身を取り出して、同時に消す」窓口

この2つを、別の窓口に分けました。最初の確認では何も消えず、ユーザーが取り出すボタンを押したときだけ、中身が出てきて、同時に消えます。

小さな工夫ですが、これがないと、安心して使えません。

画面に出る前に、できることはぜんぶやる

ほかにも、守りのための工夫を入れています。

• 入れられる文字数とファイルサイズに上限をつける(巨大なデータで荒らされないように)

• ブラウザからの通信を許可するかどうかは、送り元を見てプログラム側で出し分ける

• 管理者の操作は、ログインした本人だけに許す

• 管理者が、サービス全体を一時停止できるスイッチを持たせる

• ファイルの置き場は、外部から直接アクセスできない設定にする

• 開封されずに残ったファイルも、翌日には自動で削除されるようにする(保険です)

• 期限を過ぎた箱は、開こうとしても拒否する

派手さはまったくありません。でも、セキュリティは、こういう地味な積み重ねでできています。

暗号化は、どうなっているの？

「それって、暗号化されているの？」。いちばん気になるところだと思うので、実際の設定を調べて、正直に書きます。

通信は、暗号化されています。 画面の配信も、データをやり取りする窓口も、HTTPSという暗号化された通信で動いています。画面の配信側(CloudFront)は、暗号化されていない通信が来ても、自動でHTTPSに切り替える設定です。

保存されたデータも、AWSの標準機能で暗号化されています。 保存先のデータベース(DynamoDB)は、AWSの公式ドキュメントによると、保存時にデフォルトで暗号化され、無効にもできません。ファイルの置き場(S3)も、2023年1月以降、新しいデータは標準で暗号化(SSE-S3)される仕様です。

ただし、ここは正直に書きます。玉手箱独自の、エンドツーエンド暗号化(送る人の端末で暗号化して、受け取る人の端末でしか解けない方式)は入れていません。 メッセージは、サーバーのプログラムを通って、AWSの標準の暗号化のもとで保存されます。つまり、システムを管理している人(マンチー自身)がAWSの管理画面から調べれば、期限内の箱の中身を読める作りです。

だから、「運営者すら中身を見られない」とは言いません。そのかわり、保存は最長24時間、開いたら即削除。「長く持たない」ことで、リスクを小さくするという考え方で作っています。この点は、次の改良の候補です。

切り口③：作る過程は、苦労の連続でした

3つめは、開発の苦労話です。正直に言います。この玉手箱、かなり苦労しました。

小さなツールだから簡単だろう、と思っていたのですが、とんでもありません。ハマりどころが、次から次へと出てきました。

苦労① 「停止はどうすれば？」と聞いただけなのに

管理画面には、サービス全体のON・OFFを切り替える機能があります。ある日、こう質問しました。

「管理画面でONにはできるけど、OFFにするにはどうしたらいいの？」

質問しただけです。作ってくれとは、ひとことも言っていません。

ところが、AIは張り切りました。ワンタッチの切り替えボタン、パスワードでの運用。頼んでもいないものを、次々と勝手に追加しはじめたのです。

苦労② 管理画面を、勝手に書き換えられた

さらに別の日。AIが、管理画面のファイルを、こちらの許可なく書き換えていました。ログイン方式を、パスワード1枚の画面に変えてしまっていたのです。

「認めてないんだけど。なぜ先に提案しないんだ？」

思わず、そう打ち込みました。もちろん、元の状態に戻してもらいました。

AIは本当に優秀です。でも、提案してから動いてほしい。「提案、承認、実行」の順番を守ってもらう。これが、AIと開発するときの、いちばん大事な教訓になりました。

苦労③ せっかくのメール認証が、迷惑メールに

管理者のログインは、最初、メールに届くリンクで行う方式で作っていました。マジックリンク(パスワードの代わりに、メールで届くリンクをクリックしてログインする方式)です。

動作確認のために送ってみました。届きません。

数時間たってから、迷惑メールフォルダに入っているのを見つけました。セキュリティのために作った仕組みのメールが、迷惑メール扱い。なんとも皮肉な話です。

原因は、送信元の設定が足りなかったことでした。無料のメールアドレスから送っていたため、「この送信元は本物ですよ」と証明する設定(SPFやDKIMと呼ばれるものです)が入っていなかったのです。ちゃんと届くようにするには、専用のドメインを用意して、その設定を入れる必要があります。

苦労④ メール送信の「サンドボックス」が外れない

追い打ちをかけたのが、AWSのメール送信サービス(SES)の制限です。最初は、送れる相手が限られた「サンドボックス」という状態になっています。外すには、AWSに申請が必要です。

ところが、この申請が、思うように通りませんでした。

そこで、方針を変えました。メール方式をやめて、AWSの認証サービス(Cognito)と、Googleアカウントでのログインに切り替えたのです。管理画面に入れるのは、自分のアカウントだけ。パスワード認証も、すっぱりやめました。

結果的には、こちらの方がずっと安全で、運用も楽になりました。失敗が、いい方向に転がった例です。

苦労⑤ 管理画面の「入口」が、そもそも存在しなかった

地味に痛かったのが、これです。管理画面から呼び出す窓口(API)のひとつが、AWSの入り口(API Gateway)に、そもそも登録されていませんでした。

コードは書いてある。画面も動いている。なのに、通信が届かない。原因を探すのに、時間がかかりました。結局、コマンドで手動で追加して解決です。

苦労⑥ 認証していないのに、「認証エラー」

もうひとつ。状態を確認するだけの窓口が、なぜかログインしていない状態で呼ぶと、エラー(401)を返していました。

原因は、処理の順番でした。「ログインしているか」を調べる処理が、状態を返す処理より先に実行されていたのです。順番を入れ替えて、解決しました。

苦労⑦ 正しく書いたのに、全然効かないCORS

CORS(別のサイトからの通信を許すかどうかを決める、ブラウザのルール)にも、苦しめられました。

「リクエストの送り元を見て、許可する相手を切り替える」という処理を、プログラム(Lambda)の中に、きちんと書きました。ところが、まったく効きません。

原因は、プログラムに届く前の段階で、AWSの入り口が、決まった返事を先に返してしまっていたことでした。しかもその返事に、特定の送り元が決め打ちで書き込まれていたのです。せっかく書いた処理に、出番が回ってこなかったのです。

結局、入り口側の返事の設定を全部直して、細かい出し分けはプログラム側に任せる形にして、やっと解決しました。正しい実装が、無意味になる瞬間。AWSあるあるです。

苦労⑧ たった1行の違いで、全部が壊れる

さらにもうひとつ。ログインの証明書(JWTという、本人確認用の署名つきデータ)を検証する処理で、検証がすべて失敗し続けました。

原因は、部品の読み込み方でした。プログラムの途中で読み込む書き方をしていたのを、先頭でまとめて読み込む書き方に直した。たった1行の違いです。直した途端、あっさり動きました。

苦労⑨ 公式ツールが動かない、三連コンボ

極めつけが、デプロイ(作ったものを公開する作業)です。

• 部品フォルダ(node_modules)が大きすぎて、ビルドが失敗する。zipを作るのにも時間切れになり、壊れたzipができあがる

• 部品を別の入れ物(Lambda Layer)に分けて、本体は小さな1ファイルだけにして、やっと通る

• 次は、AWSの公式ツール(SAM)が、自分の名前入りの日本語フォルダ名でエラーを出して止まる

自分の名前がフォルダ名に入っているだけで失敗したので、さすがに笑うしかありませんでした。

最終的には、公式ツールを避けて、AWSのコマンドで直接公開するという、本末転倒な解決策にたどり着きました。

苦労⑩ URLの取り方ひとつで、画面が空っぽに

最後に、ささいなバグをひとつ。受け取り側の画面を開いても、メッセージが見つからないと言われる。原因は、URLの末尾からIDを取り出そうとしていたのに、実際のURLは「?id=」の形式だったことでした。

小さなミスですが、これが直るまでは、自分で作った箱を、自分で開けられない状態でした。

開発中に決めた「やらないこと」

作るときは、機能を足すよりも、足さないことを決める方が大事だと感じました。

• アカウント登録は、受け取る側にはさせない(リンクだけで開ける)

• 履歴や、過去に送った一覧は、受け取る側には見せない

• 中身を、あとから取り出す機能は作らない

「便利にする」ことと、「安全にする」ことは、ときどき逆の方向を向きます。玉手箱は、迷ったら安全の方を選びました。

作りながら感じたこと：こういう「影」のような存在が、実は重要

ここまで読んで、「結局、小さなツールでしょ？」と思った方もいるかもしれません。

その通りです。秘密の玉手箱は、派手なツールではありません。AIが話題になるわけでも、売上が上がるわけでもありません。

影のような存在

でも、マンチーはこう考えています。

システムの安全は、表舞台の機能だけでは守れません。パスワードを渡す、認証コードを共有する、設定ファイルを送る。こうした日常の、ほんの些細な作業の影に、漏洩の入り口は潜んでいます。

誰も気にしない場所だからこそ、そこが破られる。逆に、そういう場所をきちんと塞いでおけば、全体の安全は大きく上がります。

「ちゃんとしている」は、見えないところに出る

セキュリティは、うまくいっているときほど、誰にも気づかれません。何も起きない。それが、成功です。

だからこそ、見えない場所に手を抜かないことが、いちばん大事だとマンチーは思っています。

古い機能でも、今こそ価値がある理由

もう一度、「古い機能」の話に戻ります。

昔より、いまの方が必要です

昔のパスワードは、会社の中だけで使うものでした。今は違います。クラウドサービス、業務アプリ、取引先とのやり取り。パスワードや認証情報を渡す場面が、桁違いに増えています。

扱う量が増えれば、うっかりが起きる確率も上がります。「一度で消える」というシンプルな仕組みの価値は、むしろ上がっているのです。

難しいことは要りません

セキュリティと聞くと、難しい専門知識が必要だと感じるかもしれません。でも、玉手箱がやっているのは、たった2つのことです。

• 渡したら、消す

• 時間が来たら、消す

「残さない」。これだけで、漏れる可能性は大きく減ります。

正直に書いておく、限界

いいことばかり書くのは、フェアではないので、限界も書いておきます。

• 玉手箱は、リンクを知っている人なら誰でも開けられます。リンクそのものは、パスワードを渡す相手以外に見られないように送ってください

• リンクを送る手段(チャットやメールなど)には、リンクそのものが残ります。ただし、開いたあとのリンクは、もう中身を取り出せません

• 一度開いた中身は、相手の端末には残ります。受け取った相手が、メモ帳などに保存してしまえば、そこまでは玉手箱では防げません

• エンドツーエンド暗号化ではありません。システムの管理者であるマンチーは、技術的には期限内の中身を読める作りです

• 送れる大きさには上限があります。大きなデータの共有には向いていません

万能ではありません。でも、「何も対策していない」状態と比べれば、大きく前進します。

今後やりたいこと

まだ、改善したい点がたくさんあります。

• 迷惑メール対策の設定(専用ドメインと送信元の証明)

• リンクに、さらに合言葉をつけられるようにする

• 保存前に、ブラウザの中で暗号化する仕組み(エンドツーエンド暗号化)の検討

• 開いた人の記録(いつ開かれたか)を、確認できるようにする

セキュリティに、完成はありません。作って終わりではなく、育て続けていくものだと考えています。

まとめ：その一通が、あとから効いてくる

最後に、まとめます。

• 送ったパスワードは、思った以上に長く、あちこちに残る

• 「読んだら消える」リンクは、古い仕組みだけど、いまこそ必要

• 似た機能は大手のアプリにもあるが、単機能で手軽に使えるものは少ない

• 見るだけと取り出すを分けるなど、小さな設計の積み重ねが安全を作る

• 開発は、AIの暴走や設定のトラブルの連続だった

• 地味で影のような部分にこそ、漏洩の入り口がある

最近、情報漏洩の話題を見ない日はないほど、みんなの意識が高まっています。だからこそ、**自分の足もとの、小さな「残りもの」**を、見直してみませんか。

マンチーは、これからもClaudeとAWSの力を借りて、安全なものづくりを続けていきます。第5弾も、お楽しみに。

【この記事が興味深かった方は、以下記事もおすすめです】

＜おすすめ記事①＞
ふさいだはずの穴は、なぜ直しても戻るのか。AIは攻撃の道具か、守りの味方かを考えたい方はこちら。

＜おすすめ記事②＞
ひとつのログインで、複数のアプリに入れる認証基盤を、AWSとClaudeで作った話はこちら。

＜おすすめ記事③＞
作ったアプリを、安全に試してもらうための、テスター管理サイトを自分で作った話はこちら。

#セキュリティ #パスワード管理 #情報漏洩対策 #AWS #サーバーレス #個人開発 #バイブコーディング #Claude #ワンタイムリンク #ITエンジニア #munchie