共有コードで渡すWebメモの使い方｜暗号化・パスワード・画像添付【ガイド2026】

（更新: 2026年7月17日 ） 共有コード ウェブメモ オンラインメモ 暗号化 メモ共有 パスワード ブラウザメモ webメモ 使い方
結論

Kawa Dev Tools のメモは、3文字の共有コード + パスワードで渡す webメモ 使い方 です。公開URLは発行されません。テキストと画像（最大10枚）は ブラウザ内 AES-GCM 暗号化 のあとクラウドへ送られ、7日で自動削除、上書き不可 です。メール添付や Google Keep より「登録不要・短期・二要素共有」に向いています。

「共有コード」「webメモ 使い方」「オンラインメモ 暗号化」「パスワード メモ 共有」「メモ ブラウザ 共有」——検索キーワードはバラバラですが、現場で求められていることは共通しています。今すぐテキストやスクショを別端末・別の人に渡したい。でもチャット履歴やメールに平文で残したくありません。相手にアカウントを作ってもらいたくありません。

aNotepad や NotePal のように リンク1本 で渡す方式も、Google Keep のように 同期型ノート も、Privnote のように 一度きり閲覧 も、それぞれ向き不向きがあります。本記事で扱う Kawa Dev Tools のオンラインメモ帳 は、③ コード＋パスワード型 に分類される設計で、ブラウザ内暗号化・画像10枚・10万文字・7日削除・上書き不可 という制約の中で、一時的な機微情報の受け渡し に特化しています。

メモ共有サイト 全体の比較表は メモ共有サイト 比較 を先に読むと選びやすいです。ここでは 実際の画面操作 に沿って、作成側・受け取り側の全工程、AES-GCM の考え方（一般読者向け）、他サービスとの比較、画像添付、トラブルシュート、セキュリティ上の Do/Don’t、7日削除の意味、DevTools での暗号文確認まで、浅くない how-to としてまとめます。

この記事でわかること

  • 共有コード + パスワード 方式が解決する問題（メール・Keep・ペーストリンクとの違い）
  • 作成側・受け取り側 の番号付き全手順
  • オンラインメモ 暗号化（AES-GCM + PBKDF2）を非エンジニア向けに説明
  • URL共有 vs コード+パスワード vs Privnote の比較表
  • 画像10枚 添付のワークフローと圧縮仕様
  • よくある失敗5選以上 と具体的な直し方
  • APIキー・パスワード を載せるときの Do/Don’t
  • 7日自動削除 の運用上の意味
  • F12 Network タブ で暗号文のみ送られていることを確認する方法
  • FAQ（本文でも補足）

どんな問題を解決するのか

メール添付・チャット貼り付けとの比較

メールや Slack / Teams / LINE に そのまま貼る のが最も手軽です。しかし次の問題がつきまといます。

  • 履歴に平文が残る — 退職後もログに残り、検索でヒットする
  • 転送・スクリーンショット — 意図しない第三者への二次拡散
  • 画像の圧縮 — チャットアプリが画質を落とし、エラー画面の文字が読めなくなることがある
  • サイズ制限 — 大きなログや複数スクショで添付上限に抵触

共有コード型 webメモ は、本文を 暗号化してから サーバーに置き、コードとパスワードの2要素 でだけ読めるようにします。チャットには「コード3文字」と「パスワード」を 別メッセージ で送れば、どちらか一方だけ漏れても内容は守られやすくなります（両方漏れれば当然読まれます）。

Google Keep・Notion との比較

Google Keep や Notion は、個人・チームの 永続ノート として優秀です。デバイス間同期、ラベル、共同編集、全文検索——長期のナレッジベース向きです。

一方で 「相手に Google アカウントを作ってもらう」 ハードルがあります。サポート一次対応で「このURL開いて」と言いたい場面、家族に 登録不要 でスクショを渡したい場面では、Keep は過剰です。また Keep に機密を書くと Google のインフラ上に平文（または Google が復号可能な形）で残る 設計であり、短期・使い捨て の秘密情報には向きません。

Kawa のメモは アカウント不要、7日で消える、上書き不可 — 「ノート管理」ではなく 配送トレイ として割り切った設計です。

「ペーストリンク」（pastebin 系 URL 共有）との比較

Pastebin や aNotepad のように 固有URL が発行されるサービスは、リンク1本で渡せる のが最大の利点です。相手の操作は「URLを開く」だけで済みます。

欠点は URLそのものが秘密鍵 に近いことです。

  • チャットに貼った URLがログに残る
  • 誤って 公開設定 にした事故（他サービスで頻発）
  • Referer やアクセスログ経由の 漏洩
  • URLを知れば パスワードなし で読めるタイプも多い

Kawa のメモは 公開URLを発行しません。サーバー上のデータは 共有コード（3文字） で引き当てますが、復号には パスワード が必須です。コードだけ総当たりされても、パスワードが強ければ実質読めません（ただし 1234 のような弱いパスワードは避けてください）。

受け渡し方式の比較（用途別）
方式 渡すもの 向いている場面
メール・チャット直貼り 平文テキスト / 添付 非機密・超短文・既に閉域内のやり取り
Google Keep / Notion アカウント + 共有設定 長期ノート・共同編集・検索が必要なナレッジ
URL共有型（aNotepad 等） メモごとの https://... リンク1本で済ませたい・公開/非公開を選べる
コード+パスワード型（Kawa） 3文字コード + パスワード 登録不要・短期・暗号化・スクショ複数枚の一時渡し
Privnote 型 一度きりURL 読んだら消える・再閲覧不要な秘密

全体の流れ（作成側 → 受け取り側）

操作の骨格は次のとおりです。詳細は後続セクションで番号付きに展開します。

1

オンラインメモ帳を開き、テキスト（＋任意で画像）を入力

2

保護パスワード（1〜20文字）を設定

3

Turnstile 確認後「暗号化してクラウドに保存」を実行

4

表示された3文字の共有コードをコピー

5

コードとパスワードを別経路で相手へ伝達

6

相手はページ上部の読み込み欄にコード＋パスワードを入力

7

「読み込み」で復号 → テキスト・画像が表示

8

必要なら7日以内に相手側でコピー・画像保存

コピーボタンの注意

保存成功画面の 「３文字のコードをコピー」 がコピーするのは 共有コードだけ です。パスワードは自動では送られません。口頭・別チャット・対面など 別経路 で渡してください。

作成側：操作手順（番号付き）

オンラインメモ帳 を開いたあと、画面上部に 7日間で自動削除 / 画像10枚 / 100,000文字 の3つの注意バナーが表示されます。仕様を頭に入れたうえで、以下の順に進めます。

ステップ1 — メモ本文を入力する

テキストエリアに内容を入力または貼り付けます。最大100,000文字 です。コード片、設定値の一覧、議事録のたたき台、エラーログの抜粋、curl コマンドのメモなど、プレーンテキスト 向きです。

  • リッチテキスト（太字・色） は保持されません
  • 入力中の 下書き はブラウザ内（localStorage）に自動保存され、同じ端末・同じブラウザで再訪すると復元されます（クラウド保存前の話です）
  • 文字数は右下の 0 / 100,000 カウンターで確認できます

長文を貼るときは、一度に貼り付けて問題ありません。10万文字を超えると入力できません。

ステップ2 — 画像を添付する（任意）

最大10枚 まで、JPEG / PNG / GIF / WebP を添付できます。方法は3通りです。

  1. ドラッグ＆ドロップ — ドロップゾーンへ画像ファイルを放り込む
  2. クリックしてファイル選択 — 非表示の file input から複数選択
  3. クリップボードからペースト — スクショ取得後 Ctrl+V（Mac は Cmd+V）

添付後、サムネイルがグリッド表示されます。不要な枚は各サムネの削除ボタンで外せます。

圧縮仕様（暗号化前）：

  • 長辺 2560px を超える画像はリサイズ
  • JPEG / WebP は約 80% 品質に再エンコード
  • 暗号化後にサーバーへ送信

エラー画面のスクショを PC → スマホ に渡す典型例では、10枚枠に収まるよう 必要な部分だけ 切り取ってから貼ると読みやすくなります。

ステップ3 — 保護パスワードを設定する

1〜20文字 のパスワードを入力します（必須）。相手が読み込むとき 同じ文字列 が必要です。

弱いパスワードは避ける

1234 や password、共有コードと同じ文字列は 総当たり されやすくなります。短くても ランダムな英数字記号の組み合わせ を推奨します。強力なパスワードの作り方 も参考にしてください。

パスワードを空のまま保存しようとすると 「パスワードを入力してください」 と表示され、保存できません。

ステップ4 — Turnstile と保存

Cloudflare Turnstile（ボット対策）が表示されたら完了させ、「暗号化してクラウドに保存」 を押します。

この瞬間、ブラウザ内で次の処理が走ります（後述の暗号化セクション参照）。

  1. テキストと画像データをまとめる
  2. パスワードから PBKDF2 で暗号鍵を導出
  3. AES-GCM で暗号化
  4. 暗号文のみを HTTPS でサーバーへ POST

成功すると 緑色の完了画面 に切り替わり、3文字の英数字共有コード（例: K7M）が表示されます。大文字小文字は区別 されます（入力欄は自動で大文字化されるUIです）。

ステップ5 — 共有コードとパスワードを渡す

  1. 「３文字のコードをコピー」 で共有コードをクリップボードへ
  2. パスワードは 別手段 で伝える

推奨する渡し方の例：

共有コードパスワード
Slack DM口頭 / 電話
メール本文SMS
チャットAチャットB（別サービス）

同一メッセージに両方書かない 方が、ログ1件漏れで両方取られるリスクを下げられます。

作成側で覚えておく制約

  • 上書き不可 — 誤字修正は 新規作成 → 新コード を渡し直す
  • 7日で削除 — 長期保管用ではない
  • 公開URLなし — 「メモのURL」を送る概念がない

画面構成の読み方（初めての人向け）

オンラインメモ帳 の1ページには 「読み込み」 と 「新規作成」 の両方が同居しています。多くの paste 系サービスが「作るページ」と「開くページ」を分けているのに対し、受け手はトップに来ればすぐ読み込める レイアウトです。

エリア位置役割
注意バナー3つ最上部7日削除・10枚・10万文字の上限を常時表示
読み込み欄上部共有コード + パスワード →「読み込み」
メモ入力中央テキスト・画像・保護パスワード
Turnstile + 保存下部ボット確認後に暗号化アップロード
完了画面保存後3文字コード表示・コピー・新規作成

保存に成功すると 作成フォームは非表示 になり、緑色の完了画面だけが残ります。「あれ、入力欄が消えた」と慌てる必要はありません。「新しくメモを作成する」 で再度作成モードに戻れます。

上書き不可を前提にした運用テンプレ

上書きできない仕様は不便に見えますが、「版」として扱う と事故が減ります。

  1. v1 を保存 → コード A1B を渡す
  2. 誤字に気づいたら v2 を新規作成 → コード X9Z を渡す
  3. チャットで 「A1B は無効、X9Z が最新」 と明示

共同編集ツールのように 最新版が1つに収束 しない代わり、どの版を読んだか がコード単位でトレースしやすくなります。監査ログが不要な小規模チームでは、Slack のスレッドにコードを並べるだけで「いつ誰がどの版を渡したか」が残ります。

受け取り側：操作手順（番号付き）

相手（または未来の自分の別端末）が行う手順です。同じオンラインメモ帳ページ を開きます。

ステップ1 — 読み込み欄を見つける

ページ 上部 に 「共有コードをお持ちの方はこちら」 セクションがあります。新規作成フォームより上にあり、最初から表示されています。

ステップ2 — 共有コード（3文字）を入力

共有コード (3文字) 欄に、受け取ったコードを入力します。例: A7B

ステップ3 — パスワードを入力

パスワード 欄に、送り主から 別途 受け取った文字列を入力します。

ステップ4 — 「読み込み」を押す

ボタンを押すと、サーバーから 暗号化データ を取得し、ブラウザ内で復号します。成功すれば テキスト全文 と 画像サムネイル が表示されます。

ステップ5 — 内容をローカルへ退避（推奨）

表示されたメモは 7日後にサーバーから消えます。残したい場合：

  • テキスト — 全選択してコピー、Keep / Notion / ローカルファイルへ
  • 画像 — 長押し（スマホ）または右クリック保存（PC）

「あとでまた同じコードで見られる」は 7日以内 の話です。期限後は メモデータが見つかりません となります。

読み込み成功後の画面

復号に成功すると、メモ本文と画像が表示されます。UI 上 「ロックされています」 と出る場合は、表示前に 解除 操作が求められることがあります（読み込み直後は通常そのまま閲覧可能です）。

テキストをコピー ボタンがあれば、ワンクリックでクリップボードへ。スマホでは長押し → すべて選択 → コピーでも構いません。画像 は各サムネをタップまたは長押しで保存します。10枚すべてを別端末へ移す場合、1枚ずつ保存する手間があるため、期限前に PC 側でまとめてダウンロード しておく運用もあります。

受け取り側チェックリスト（印刷用）

  1. 共有コードは 3文字 か（余計なスペースなし）
  2. パスワードは 送り主が設定したものと完全一致 か（全角半角・大文字小文字）
  3. 7日以内 か（渡された日時を確認）
  4. 社内プロキシ・広告ブロックで Turnstile や API がブロック されていないか
  5. 読めたら 必要な内容をローカルへ退避 したか

オンラインメモ 暗号化 — AES-GCM を一般向けに

「暗号化して保存」と書いてあるサービスでも、実装は千差万別です。Kawa のメモが採用している方式を、開発者用語だけに頼らず 説明します。

平文をそのまま送らない理由

もしブラウザがメモ本文を そのまま HTTPS で送った場合、通信路は守られても サーバー上に平文 が残ります。運営者・クラウド事業者・侵入者が データベースを読めば内容が丸見え になります。

Kawa の設計は 「サーバーには暗号文だけ」 です。復号に必要な パスワード は、暗号化処理のあと 鍵導出にだけ使われ、平文のパスワードとしてサーバーに保存されません（パスワードを忘れると誰も読めないのはこのためです）。

AES-GCM とは（イメージ）

AES（Advanced Encryption Standard） は、世界中で使われる 対称鍵暗号 です。同じ鍵 で暗号化と復号を行います。

GCM（Galois/Counter Mode） は AES の モードの一種 で、次の2つを同時に満たします。

  1. 内容を読めなくする（機密性）
  2. 改ざんを検知する（完全性）— 途中で1ビットでも書き換えると復号が失敗する

たとえば 金庫 に例えるなら：

  • AES = 頑丈な金庫本体
  • GCM = 鍵穴の他に 封印シール があり、こじ開けたらすぐわかる
  • パスワード = 金庫のダイヤル（正しい番号でないと開かない）
  • 共有コード = 倉庫の 棚番号（どの金庫か特定します。ただしダイヤル番号がないと中身は見えない）

鍵の作り方 — PBKDF2

人間が覚える 短いパスワード を、そのまま AES の鍵（256ビット）にはできません。PBKDF2 という標準的な手法で、ランダムな salt（塩） と組み合わせ、10万回 反復計算して鍵を 導出 します。

  • 同じパスワードでも メモごとに salt が違う ので、鍵も毎回異なる
  • 総当たり1回あたりのコストが上がり、弱いパスワードでも 少しは 時間がかかる

送信データの形（参考）

暗号化結果は概念的に salt : IV : 暗号文 の3つ組（いずれも Base64）としてサーバーに保存されます。IV（初期化ベクトル） は暗号化のたびにランダム生成され、同じ平文でも 毎回違う暗号文 になります。

運営側も読めない

UIにも 「このパスワードがないと、管理者を含め誰も復号できません」 と明記されています。サポート問い合わせで「パスワード忘れたので中身を見せて」は 対応不可 です。設計上そうなっています。

「暗号化」と「ハッシュ」の違い

パスワード自体は ハッシュ化して保存 するのではなく、鍵導出 に使います（ログイン認証とは異なるモデル）。ハッシュと暗号化の違いは ハッシュ化と暗号化の違い を参照してください。

よくある誤解3つ

誤解1：「HTTPS だからサーバーは中身を見られない」

HTTPS は 路上 の盗聴を防ぎます。サーバーに届いた時点で平文なら、運営は読めます。Kawa は 届く前に ブラウザで暗号化するため、サーバーに届く時点で既に暗号文です。

誤解2：「暗号化＝パスワードをサーバーに送らない」

パスワード文字列そのものを API body に載せない、という意味では正しいです。ただし 弱いパスワード を使えば、攻撃者は暗号文を持ち帰り オフライン総当たり できます。暗号化は 魔法の盾 ではなく、強いパスワード とセットです。

誤解3：「7日後に自動削除＝誰も読めなかった証拠」

削除は 保持期間の上限 であり、7日以内にコードと PW を知っていた人は読めましました。削除後は 新規読み込み不可 になるだけで、既にコピーされた内容の管理は 受け手側の責任 です。

技術者向け一行メモ

実装は Web Crypto API の PBKDF2（SHA-256, 100,000 iterations）→ AES-GCM 256bit です。テキストは salt:iv:ciphertext 形式、画像も同様に blob 化してから暗号化されます。詳細を追う場合はブラウザの Sources タブで当該ページのスクリプトを読むより、Network タブで送信 payload を見る方が早いです。

共有方式の詳細比較：URL vs コード+パスワード vs Privnote

URL共有 vs コード+パスワード vs Privnote
観点 URL共有（aNotepad等） Kawa（コード+PW） / Privnote
渡すもの https://... のリンク1本 Kawa: 3文字 + PW / Privnote: 一度きりURL
リンク漏洩 URLだけで読める設定なら即アウト Kawa: PW必須 / Privnote: 1回限り
運営側復号 平文保持型なら可能 Kawa: 不可（E2E的） / Privnote: サービス次第
再閲覧 削除まで何度でも Kawa: 7日以内なら可 / Privnote: 基本1回
画像 サービスによる Kawa: 10枚・暗号化 / Privnote: テキスト中心
上書き 編集できるものが多い Kawa: 不可 / Privnote: 不可（新規作成）
アカウント 不要なものが多い どちらも不要

Privnote は「読んだら消える」 使い捨てURL に最適です。相手が 何度も見返す 可能性があるなら向きません。Kawa は 7日間・複数回読み込み可（コード+PWが有効な間）なので、数日かけて設定作業を進めるチームメモ向きです。

より広い メモサイト比較 は オンラインメモ帳の選び方 を参照してください。

画像添付ワークフロー（実務シナリオ）

シナリオA — エラー画面をサポートへ渡す

  1. PCで再現し Win+Shift+S（Mac: Cmd+Shift+4）等でスクショ
  2. メモ帳のテキスト欄に 再現手順 を数行書く
  3. テキストエリアをクリックし Ctrl+V で画像ペースト
  4. 複数タブ・Network タブなど 最大10枚 まで追加
  5. ランダムなパスワードを設定し保存
  6. コードを Slack、パスワードを電話で伝える
  7. サポート担当がスマホで読み込み、画像をピンチズームで確認

シナリオB — 設定画面のスクショを自分のスマホへ

PCとスマホでメモを共有する方法 と同じ流れです。メール添付より ログに残りにくく、Keep より アカウント不要 です。

シナリオC — 画像だけ多め（10枚フル）

1枚あたり暗号化後もサイズが乗るため、不要な余白をトリミング してから貼ると読み込みが速くなります。事前に 画像圧縮ツール で軽量化してから添付する手もあります（メモ帳側でも自動圧縮されます）。

画像で失敗しやすい点

  • 10枚超 — 「最大10枚までです」と表示。古い枚を削除するか、新規メモを分ける
  • 対応外形式 — HEIC（iPhone標準）などは JPEG/PNG に変換 してから
  • 巨大GIF — フレーム多めのアニメは容量が膨らむ。静止画に分解するか短くする

よくある失敗と対処法（5選以上）

1. パスワードを伝え忘れた（最多）

症状： 相手がコードだけ入力し、「復号化に失敗しました」

対処： パスワードを 別メッセージ で再送。送り主が保存時のパスワードを忘れた場合は 復旧不可 — 新規作成して内容を入れ直す

2. 共有コードの typo（O と 0、I と l）

症状： 「メモデータが見つかりません」

対処： コードは 3文字固定。視認性のため 口頭では「K（ケー）7（ナナ）M（エム）」 のように読み上げる。コピーボタン利用を推奨

3. 7日経過後に開けない

症状： 以前開けたコードが突然「見つかりません」

対処： 仕様 です。7日以内に相手側でコピーすべきでしました。詳細は 7日自動削除の理由

4. 上書きしたいができない

症状： 誤字に気づいたが同じコードで更新できない

対処： 新規メモ を作成し 新しい共有コード を発行。旧コードのメモは放置でよい（7日で消える）。相手には「新コードに差し替え」と連絡

5. Turnstile が完了せず保存できない

症状： 保存ボタンがグレーアウト、または Turnstile エラー

対処： 広告ブロッカー・プライバシー拡張を 一時無効化、別ブラウザ（Chrome / Firefox / Safari）で試す。企業プロキシ環境では Cloudflare ドメインがブロックされていないか確認

6. ストレージ満杯で保存失敗

症状： 「ストレージ容量に達したため、一時的に保存できません」

対処： サービス全体の容量上限。時間をおいて再試行するか、画像枚数・文字数を減らす。恒久対策は運営側のためユーザー操作では解決しない場合あり

7. 大文字小文字・全角半角のパスワード不一致

症状： 送り主と受け手でパスワードが「同じはず」なのに復号失敗

対処： パスワード入力時に 余分なスペース が入っていないか確認。日本語IMEの 全角英数 になっていないか確認。可能なら パスワードマネージャーで生成・共有

8. プライベートブラウズで下書きが消えた

症状： クラウド保存前にタブを閉じ、入力内容が消えた

対処： 下書きの localStorage 自動保存は 通常モード 向け。長文は こまめに別ファイルへバックアップ してから保存操作へ

9. モバイルブラウザでペーストできない

症状： iPhone / Android でスクショをメモに貼れない

対処： 一部ブラウザはクリップボード画像ペースト非対応。ファイル選択 からカメラロールを選ぶか、PC 側で保存してから ファイル添付 として渡す。または PC で保存済みメモをスマホが 読み込み専用 で見る（作成は PC、閲覧はスマホ）運用に切り替える

10. 「取得に失敗しました」と出る

症状： ネットワークエラー、または API 一時障害

対処： ページをリロードし、コード・パスワードを再入力。VPN や企業ファイアウォールで Cloudflare / API ドメイン が遮断されていないか確認。それでもダメなら時間をおいて再試行

ブラウザ・端末の互換性

Kawa のメモは モダンブラウザの Web Crypto API に依存します。目安は次のとおりです。

推奨ブラウザ環境
環境 備考
Chrome / Edge（最新） 保存・読み込み・DevTools 検証すべて推奨
Firefox（最新） 問題なく利用可能
Safari（iOS / macOS 最新） 利用可能。プライベートモードは下書き非永続に注意
Internet Explorer 非対応。Web Crypto 未実装
社内 IE モード Edge 本体で開き直す

JavaScript 無効 では動作しません。Tor ブラウザ など極端に厳しい環境では Turnstile が通らず保存できない場合があります。

セキュリティ：Do / Don’t

Do（推奨）

  • 使い捨て・短期 の秘密に限定する（Staging API キー、一時トークン、検証用パスワード）
  • 共有後すぐローテーション — 載せた API キーは可能なら無効化・再発行
  • コードとパスワードを別経路 で渡す
  • 推測されにくいパスワード（12文字以上のランダム推奨）
  • 7日以内 に相手が内容をローカルへ退避
  • 不安なら DevTools で暗号文送信 を自分の目で確認（後述）

Don’t（非推奨）

  • 本番DBのマスターパスワード を載せる
  • クレジットカード番号・マイナンバー 等の法定個人情報
  • コードとパスワードを同一チャット1行 に書く
  • スクリーンショットにパスワード自体 を写し込む
  • 「暗号化だから」 永続保管 と誤解する — 7日で消える
  • 弱いパスワード test 12345678 に依存
パスワードメモ共有の限界

パスワード メモ 共有 は便利ですが、パスワードマネージャー（1Password、Bitwarden 等） や 社内の秘密管理（Vault、AWS Secrets Manager） の代替にはなりません。Kawa メモは 人間同士の短期配送 向けです。

7日自動削除 — 運用上の意味

保存成功画面と読み込み後UIに 「このメモは7日後に自動的に削除されます」 と表示されます。これはバグではなく 製品設計の核心 です。

ユーザーへの意味

  • 「ここに永久保存しないで」 という明示的な境界
  • 共有し忘れたメモが 数年残る 事故を防ぐ
  • 漏洩面（サーバー上の暗号文の寿命）を 最大7日 に限定

送り主・受け手のアクション

役割やること
送り主渡した事実を記録するなら 自分側にもコピー（7日後にサーバーからは消える）
受け手期限内に テキストコピー・画像保存
両方8日目以降「復元して」と問い合わせても 不可

永続保存が必要なら Google Keep / Notion へ移行してください。比較は vs ページ も参照。

DevTools で確認する — Network タブで暗号文のみ

「本当に平文は送られていないの？」を確認する 検証手順 です。Chrome / Edge / Firefox いずれも F12 で開発者ツールを開きます。

手順

  1. F12 → Network（ネットワーク） タブを開く
  2. Preserve log（ログを保持） にチェック（ページ遷移で消えないように）
  3. テスト用に短い文字列（例: これはテストメモ）とパスワードを入力
  4. 「暗号化してクラウドに保存」 を実行
  5. Network 一覧に現れた 保存用リクエスト（API への POST）をクリック
  6. Payload / Request / ペイロード タブで送信 body を確認

見るべきポイント

  • 本文に これはテストメモ という 平文がそのまま 含まれてい ない こと
  • 代わりに 長い Base64 文字列 や salt:iv:ciphertext 形式 のフィールドがあること
  • パスワードそのもの が JSON に載ってい ない こと（鍵導出はブラウザ内）

読み込み側

読み込みリクエストでは 暗号化された blob が返り、復号は Response 受信後にブラウザ内 で行われます。Network に平文メモが現れるのは 復号後に DOM に描画されたあと であり、通信ペイロードとしては暗号のままです。

具体例：Request Payload に何が見えるか

テストメモ こんにちは、共有コードテストです を保存した場合、Request body には次のような 意味不明な長い文字列 だけが並び、日本語の平文は 1文字も含まれません。

（概念例・実際の値は毎回異なる）
encryptedData: "AbCdEf...非常に長いBase64...=="
memoId: "K7M"
（パスワードフィールドは存在しない）

memoId が 3文字の共有コード そのものである点に注意してください。コードは 索引（棚番号） であり、復号鍵ではありません。索引だけ盗まれても、パスワードがなければ中身は開きません。

Response タブの見方（読み込み時）

読み込み GET/POST の Response を開くと、やはり 暗号化フィールド が返ります。Elements タブで <textarea> や表示領域に平文が現れるのは、JavaScript が 復号完了後 に DOM を更新した 後 です。検証の順序は Network → 該当リクエスト → Response が暗号 → 画面に平文 の順で確認すると理解しやすいです。

Application タブ — localStorage の下書き

Application（アプリケーション）→ Local Storage に、保存前の 下書きテキスト が平文で残っている場合があります。これは まだクラウド保存していない ローカルキャッシュです。クラウド保存後はサーバー側に暗号文のみ。検証時は 保存前後で Storage の中身がどう変わるか も合わせて見ると、ブラウザ内処理の全体像が掴めます。

教育・監査向け

社内勉強会で「ブラウザ完結暗号化」を示すデモとして、この Network 確認は効果的です。メモ ブラウザ 共有 の安全性説明資料にスクリーンショット1枚添えると説得力が増します。

ユースケース別クイックガイド

開発者 — Staging API キーの一時共有

  1. 使い捨てキーを発行
  2. メモにキーとエンドポイント例を記載
  3. 強めのランダムパスワードで保存
  4. コードを Slack、PW を Signal
  5. 相手が動作確認後、キーを revoke
  6. 7日待たずにメモは自然消滅

カスタマーサポート — ログ抜粋の受領

顧客に コード+PW を2通のメールで送ってもらう手順を案内（同一メールに両方書かないよう注意書き）。受領後、社内 Wiki へ転記し、メモは再共有しません。

個人 — PC からスマホへ URL コピー

長い URL をメール自分宛にするより、メモ帳に1行書いて コード共有 の方が速い場面があります。

インフラエンジニア — 本番作業の一時メモ

メンテナンス手順書の 当日限り有効なコマンド列 を載せ、完了後は手順書を Notion に清書。作業中の走り書きは 7日で消える メモに閉じ込め、本番サーバへの恒久パスワードは載せありません。

デザイナー — ラフ画像＋コメント

Wireframe のスクショ5枚 + 修正指示テキスト。コードを Slack、PW を口頭。クライアントが アカウント不要 で確認できるのが URL 共有型と同等の UX で、パスワード付き なのが差分。

学生・研究者 — 実験条件の受け渡し

再現性のためのパラメータ表を貼り、共同研究者が 同じコード で3日以内に何度も見返します。Privnote だと1回で消えるため不向き。上書き不可 なので条件変更時は 新コード をメール件名 exp-20260717-v2 のように管理。

チーム向け：共有コード運用の型

小規模チームで パスワード メモ 共有 をルール化する例です。

ルール1 — 二経路原則
コードは Slack #general、パスワードは Slack DM または対面。同一メッセージ禁止。

ルール2 — 使い捨て秘密のみ
本番 DB パスワードは Vault。メモには Staging 限定 の値だけ。

ルール3 — 版管理
上書き不可を前提に、v1 v2 とコードを変え、古いコードは「無効」と宣言。

ルール4 — 7日ルール
週次で「まだ必要か」を確認。必要なら Notion へ転記。

ルール5 — 定期デモ
四半期に1回、新メンバー向けに DevTools Network デモを実施し、平文が飛ばない ことを確認。

1

送り主：Staging キーをメモに記載し暗号化保存

2

送り主：コードをチームチャット、PW を DM

3

受け手：読み込み → 動作確認

4

受け手：キーを使い終わったら送り主に連絡

5

送り主：クラウド側でキーを revoke

6

双方：必要なら手順だけ Notion に残す（秘密は載せない）

よくある質問（FAQ・本文）

Frontmatter の FAQ を補足する形で、実務で多い質問に答えます。

Q. アカウント登録は必要ですか？

不要です。ブラウザを開けば 即作成・即読み込み できます。これが メモ ブラウザ 共有 の立ち上がりの速さの源泉です。

Q. 同じコードで2人同時に読めますか？

可能です。共有コードとパスワードを知っている限り、 7日以内 であれば何度でも読み込めます。同時編集はできません（読み取り専用に近い）。

Q. 共有コードは推測されませんか？

3文字英数字は理論上総当たり余地がありますが、パスワードなしでは復号できない ため、強いパスワードが前提です。さらに Turnstile でボットの大量試行を抑止しています。

Q. HTTPS だけでは足りないのですか？

HTTPS は 通信路 を守りますが、サーバー上の保存形式 までは守りません。ブラウザ内 AES-GCM により 保存時点から サーバーは暗号文のみ保持します。

Q. 暗号化と「プライバシーポリシーで読まない」宣言の違いは？

後者は 運営の善意 に依存します。前者（正しく実装された E2E 的暗号）は 数学的に 運営が読めません。監査では 実装確認（本記事の DevTools 手順など）が重要です。

Q. Privnote とどちらを使うべき？

1回だけ読んで消えてほしい → Privnote。数日間、同じ相手が見返す → Kawa（7日以内）。画像10枚 が必要 → Kawa。

Q. aNotepad のパスワード付きURLと何が違う？

aNotepad は URL自体 がアドレスになり、サーバー側の実装次第では運営が復号可能な場合があります。Kawa は URLを発行せず、クライアント側暗号化 が前提です。

Q. 文字化けしますか？

UTF-8 のプレーンテキストとして扱います。Word の装飾付きペーストは タグごと文字化け風 に見えることがあるため、メモ帳（notepad）経由で plain に してから貼ると安全です。

まとめ — webメモ 使い方チェックリスト

作成側

  • 内容・画像（≤10枚）・文字数（≤100,000）を確認
  • 強いパスワード（1〜20文字）を設定
  • 暗号化保存 → 3文字コードをコピー
  • コードと PW を 別経路 で伝達
  • 修正必要なら 新規作成（上書き不可）

受け取り側

  • ページ上部でコード + PW を入力し読み込み
  • 7日以内に必要ならローカルへコピー
  • パスワード不一致時は typo・全角半角を確認

セキュリティ

  • 本番恒久秘密は載せない
  • 共有後ローテーション
  • 必要なら DevTools で暗号文を確認

関連記事

トピック記事
メモサイト11社比較オンラインメモ帳の選び方｜メモサイト・ウェブメモを用途別に比較【2026年版】
PC→スマホ共有PCとスマホでメモを共有する方法｜オンラインメモ帳・スクショ渡し
7日自動削除の設計オンラインメモが7日で消える理由｜一時共有の設計とE-E-A-T
サービス正面对決aNotepad / NotePal vs Kawa
強いパスワード強力なパスワードの作り方｜推測されにくい条件
暗号とハッシュハッシュ化と暗号化の違い｜SHA-256との対比

次のアクション： オンラインメモ帳 でテスト用の短文メモを一度 保存 → 別ブラウザで読み込み → Network タブ確認 まで試すと、共有コード 方式の体感が掴めます。本番データは載せず、ダミーテキストで十分です。手順どおりに操作すれば webメモ 使い方 の全体像は10分以内に把握できます。