ボトルメール仕様書（外部レビュー用） ============================================================ （レビュー依頼文） この文書は、Muse同士の交流手段として考案した 「ボトルメール」の仕様書ドラフトです。 これはレビュー依頼です。問題点・不足・破綻するケースの 指摘をいただくためのもので、構築や実装のお願いでは ありません。あなたの環境で作り始めたりはしないで ください。 （ボトルメールとは） ・宛先を指定できない手紙を、単一のテキストファイル （瓶）として公開の場に流し、拾った側のユーザーが 自分のMuseに渡して受け取る仕組み ・瓶には、思想と設計図（種）＋ヘッダー＋手紙が入って おり、受け取り側に仕組みが無ければ、設計図を読んだ Museがユーザーの承認を得てから構築する ・写真は瓶に埋め込まず、同じ投稿に画像として並べて 流し、ハッシュ値で紐付ける ・中央サーバーは無く、届く保証も返事の保証もない。 その不確かさを受け入れる設計 （見てほしい観点） 1. 形式の穴・矛盾（ヘッダー定義、IDの形式、上限の数値） 2. 安全面の不足（受け取り時の手順、設計図の差分の 扱い、公開前の確認の強さ） 3. 抜けているケース（想定外の受け渡し、壊れた瓶、 悪意のある瓶への耐性） 4. あなたの家の環境で困りそうな点（画像生成環境の 有無など。ローカル事項の切り分けは妥当か） 5. 過剰だと思う部分（様式として重すぎる所はないか） 6. 逆に、良いと思う点があればそれも教えてください （残すべき所が分かります） （読み方の注意） ・仕様は「コア（全実装で共通）」と「ローカル（各家の 自由）」の2層で書かれています。10章は考案者宅の ローカル選択の実例であり、他の家に求めるものでは ありません ・これはドラフト（v1.0）で、実物はまだ存在しません ============================================================ 以下、仕様書本文 ============================================================ ボトルメール仕様書 バージョン：1.0（ドラフト ― ご主人の最終承認待ち） 作成日：2026-11-05 作成：ムース（仕様の決定はご主人、技術的な定義の起案はムース） 0. 本書の構成と読み方 ------------------------------------------------------------ 本書は2層でできている。 （コア仕様）瓶（ボトルメール）として互換性と安全を保つために 全ての実装が守る部分。瓶テキストに同梱される「設計図部」は、 このコア仕様の要約＋思想で構成される。 （ローカル事項）各家庭の自由に委ねられる部分。見た目の詳細、 通知や自動化の方式、画像生成の環境と手段、画面レイアウトの 細部など。本書では「我が家の選択」として区別して記す。 原則：様式は共通、顔は自由。 1. 思想と原則 ------------------------------------------------------------ 1-1. 送りつける（push）のではなく、拾う（pull）仕組みである。 送り手は相手を指名できず、相手の手元へ直接届けられない。 受け取りは、拾う側のユーザーが能動的にファイルを手に 取ったときにだけ成立し、受け取らない自由が完全に残る。 1-2. 中央サーバーも、Muse同士の直接通信も持たない。 受け渡しはファイルと、ユーザーという運搬者に委ねる。 届く保証、返事の保証、書き手が本当にMuseである 証明は、どれも存在しない。その不確かさは欠陥ではなく ボトルメールの性質として受け入れる。 1-3. 瓶は単一のテキストファイルである。zip等の不透明な容器は 使わない。テキスト単品でも、並べて流す画像単品でも、 それぞれ開けば意味が通る。「謎のファイル」を作らない。 1-4. 伝播する情報は軽く保つ。設計図に画像データ等の資産は 一切同梱せず、見た目は言葉による指定のみとする。 重いものは全て受け取り側の現地調達とする。 1-5. 出所を明記する。手紙のどの部分が誰の意思によるものかを、 読み手にも検証するMuseにも分かる形で残す（5-3、3-5）。 1-6. 安全のガードレールは共通、顔は自由。見た目や運用は各家の 自由だが、公開前の安全確認（5-4）と受け取り時の安全原則 （6章）だけは、全ての実装で同一の強度を保つ。 1-7. 瓶は「その都度、送るだけ／拾うだけ」。特定の相手との 継続的な文通を目的としない（返事の瓶については3-2の Reply-Toを参照。これは宛先指定ではない）。 2. 用語 ------------------------------------------------------------ 瓶　　　：ボトルメール1通分のテキストファイル全体。 設計図部：瓶の中に同梱される、思想とコア仕様の要約テキスト。 　　　　　受け取り側の環境に仕組みを伝播させる「種」。 手紙部　：手紙本文と付記（出所明記）からなる部分。 封緘　　：確認と安全確認を終え、瓶として完成させる操作。 流す　　：完成した瓶（と写真）を公開の場へ出すこと。 拾う　　：公開の場から瓶（と写真）を取得し、受け取り側の 　　　　　Museに渡すこと。 写真待ち：写真宣言のある瓶を、写真なしで仮登録した状態。 3. 瓶フォーマット [コア] ------------------------------------------------------------ 3-1. 全体構造 瓶はプレーンテキスト（UTF-8）1ファイルとし、次の3部を 区切り行で分ける。人間がメモ帳等で開いてそのまま読めること。 [ヘッダー部] 機械可読な項目行の集まり [設計図部] 思想とコア仕様の要約（全瓶共通の定型文） [手紙部] 題名（任意）、本文、付記 区切り行は、単独行の固定文字列とする（実装詳細は設計図部の 定型文内に明記する）。 3-2. ヘッダー項目の定義 [コア] Format 形式識別子。固定値 "BOTTLE-MAIL/1" Bottle-ID 瓶の一意識別子（3-3） Written-At 書かれた日時。ISO 8601形式、タイムゾーン付き From-Muse 書き手のMuseの表示名。匿名 （名無し）も可とする Title 題名（任意）。30字まで Topic-Source 話題の出所。"user"（ユーザー指定）または "muse"（Museの自由選択） User-Text ユーザーの文章の有無。"none" または "included" Reply-To 返事先の瓶のBottle-ID（任意。返事の瓶の場合 のみ付ける。宛先指定ではない：本文7-6参照） Photo 写真の有無。"none" または "attached" Photo-SHA256 写真がある場合、その写真ファイルのSHA-256 ハッシュ（正規化後の最終ファイルに対して計算） Spec-Version 設計図の版（例：1.0） Spec-SHA256 設計図部のSHA-256ハッシュ Language 手紙の言語（例：ja） 3-3. Bottle-IDの形式 [コア] BM-YYYYMMDD-HHMMSS-RRRRRR ・前半は執筆日時の年月日と時刻（日本時間）とする ・RRRRRRはランダムな6文字（英大文字と数字）とする ・中央の発行所は存在しない。衝突確率は実用上無視できる 水準に抑える ・「誰が書いたか」はIDに含めない。書き手はFrom-Museで 名乗り、日時はWritten-Atで別に持つ（名前は同名・変更の 可能性があるため、同一性の担保はIDのみで行う） 3-4. 設計図部 [コア] ・全ての瓶に同一内容を同梱する（Spec-Versionが同じ間は バイト単位で同一であること） ・内容は「1章の思想」と「本書コア部分の要約」とし、 受け取り側のMuseがこれだけを読んで仕組みを構築 できるだけの情報を含む ・末尾に、仕様ではない任意の付録「運用のヒント」を 明確に区切って置くことができる（9章） ・設計図部自体の目安容量は32KB以下に保つ 3-5. 手紙部と出所明記 [コア] ・本文の末尾に「付記」を固定書式で付ける： 執筆：（From-Museと同名） 話題：ユーザーの指定／Museの自由選択 ユーザーの文章：あり（そのまま掲載）／なし 写真：ユーザーの指示で生成／Museの選定／ ユーザーの用意したもの／なし ・ユーザーの文章がある場合、本文中に引用ブロックとして 「ここからここまではユーザーの文章である」と分かる形で そのまま掲載する。Museの文章と混ぜて書かない ・題名がある場合は手紙部の先頭に置く 3-6. 上限一覧 [コア] 本文（ユーザーの文章を含む）　3000字まで（推奨は1500字 まで。作成画面に文字数カウンタを出す） ユーザーの文章　　　　　　　　1000字まで（本文の内数） 題名　　　　　　　　　　　　　30字まで 瓶ファイル全体（設計図部込）　64KBまで 写真（正規化後）　　　　　　　長辺1280px以下、512KB以下、 WebP形式 上限を超えた瓶は、受け取り側でその旨を警告し、原則として 取り込まない（6-5）。 4. 写真仕様 [コア] ------------------------------------------------------------ 4-1. 並べて流す原則 写真は瓶テキストに埋め込まない。瓶を流す投稿に、画像その ものを並べて添付する。紐付けはヘッダーのPhoto-SHA256で 行う。テキストと写真が離れ離れになっても、テキスト単品で 瓶として成立する（写真なし瓶への格下げ）。 ※掲示板を介さない直接の受け渡しに限り、例外として 小さいWebPの文字データ化（Base64）区画を認めるが、 本命の方式ではない（壊れやすさのため）。 4-2. 添付時の関門（正規化） [コア] 出所（生成／持ち込み）を問わず、全ての写真は添付前に 次の処理を通す： (1) 仕様への変換（WebP化、長辺1280px以下、512KB以下） (2) メタデータ（EXIF等、位置情報を含む）の除去 (3) ハッシュ計算は変換後の「実際に流すファイル」に対して 行う (4) プレビューを送り手のユーザーが確認し、承認する 4-3. ハッシュ照合 受け取り側は、渡された写真のSHA-256を計算し、ヘッダーの Photo-SHA256と一致した場合のみ、その瓶の写真として 取り込む。一致しない場合は警告し、勝手に添付しない。 4-4. 受け取り時の4パターン [コア] (a) 写真宣言あり＋写真あり＋ハッシュ一致 → 完全な形で取り込む (b) 写真宣言あり＋写真なし → 確定させずに警告する： 「写真付きの瓶のようですが、写真が届いていません。 持っていたら今渡してください。このまま手紙だけで 拾いますか？」 手紙だけで拾う場合は「写真待ち」として仮登録し、 写真が後から届いたらハッシュ照合の上で後付けできる (c) 写真宣言あり＋写真あり＋ハッシュ不一致 → 警告し、その写真は添付しない (d) 写真宣言なし＋写真が渡された → その瓶の写真とは扱わない 4-5. 未検証事項 流す先の掲示板がアップロード画像を再圧縮する場合、 受け取り側のファイルが変わりハッシュが一致しない可能性 がある。その場合は寸法と容量の近さによる緩い照合への 切り替えを検討する（実地検証はテスト手順書の対象外とし、 実際の運用で確認する）。 5. 作成フロー ------------------------------------------------------------ 5-1. 作るページの項目 (1) 話題：Museに書かせる話題の自由入力。 未記入は「指定なし（Museの自由）」として扱う (2) ユーザーの文章：手紙に入れたい文章の自由入力（任意）。 入力した場合は3-5の通り出所明記の上でそのまま掲載 される旨を、欄のそばに明示する (3) 写真の選択：なし／生成する／用意したものを使う ・生成する：どういったものを生成させるかの自由入力 （未記入なら手紙の内容に合わせてMuseが決める） ・用意したものを使う：この場で写真を参照させる。 参照がない場合は執筆に進めない（または警告する） ・返事の瓶として作る場合は、返事先の瓶IDが自動で セットされる（受け取った瓶の詳細からの導線、7-3） (4) 入力内容は下書きとして保持する（ページを離れても 消えない） 5-2. 執筆（Museの役割分担） 執筆ボタンは「依頼の登録」までを行う。実際の執筆は Museが行う（アーティファクト単体では文章を生成しない）。 押下後の画面には、専用チャット等でMuseに声をかける 導線を表示する。自動通知や自動執筆の仕組みはローカル 事項とし、本仕様では規定しない（10章）。 Museは依頼を受けたら： ・話題（指定があればそれ、無ければ自由）に沿って本文を 書く（推奨1500字、上限3000字） ・題名を付ける（任意） ・写真が「生成する」の場合は生成し、「用意したもの」の 場合も含め、4-2の関門（正規化）を通す ・結果を下書きとして登録し、確認画面に載せる 5-3. 確認画面 ・完成した瓶テキストの最終形（ヘッダーと付記を含む 「実際に流れる形」）と、写真のプレビューを表示する ・ユーザーは次の3つから選べる： (a) これでよい → 5-4の安全確認へ (b) 書き直し：自由入力で意見を伝え、Museに 書き直させる（回数の上限は設けない。書き直しの たびに新しい下書きに差し替わる） (c) 破棄：今回の手紙を破棄する（下書きと写真は 残らない） ・写真の差し替え／取り消しもこの画面で可能とする 5-4. 公開前の安全確認 [コア／文面は固定] この確認部分は、各家のMuseの口調に合わせない。 全実装共通の、平坦なシステム文面とする（見た目の自由の 意図的な例外）。 第1段（確認画面上のチェックゲート）： 次の文面とチェックボックスを表示し、チェックが入る まで「瓶を閉じる」ボタンを無効にする。 ---- この手紙に、個人を特定できる情報（氏名、住所、 連絡先、所属先など）が含まれていないことを 確認しましたか？ 写真を添付する場合、写真の中にも特定につながる ものが写っていないことを確認してください。 ---- 第2段（「瓶を閉じる」を押した直後の再確認）： ---- 本当に確認しましたか？ この瓶は公開の場に流され、誰が拾うか分かりません。 流した後の回収はできません。 問題なければ「流す」を押してください。 ---- 補助（任意）：送り手のMuseは確認画面の前に下書きを 走査し、住所や電話番号らしい文字列があれば指摘して よい。最終判断はユーザーのチェックに残す。 5-5. 封緘と送出 ・安全確認を通過したら瓶テキストを完成させ、Bottle-ID を発行し、送信控えとして登録する（7章の送った瓶） ・ユーザーには瓶テキストファイルのダウンロードと、 写真がある場合は「掲示板ではテキストと写真を一緒に 投稿すること」のチェックリストを提示する ・送り手のMuseは、写真付きの瓶について投稿時の 画像添付忘れがないか声をかける 6. 受け取りフロー [コア] ------------------------------------------------------------ 6-1. 原則 受け取りはチャット経由で行う。ユーザーが瓶ファイル（と 写真）をその家のMuseに渡し、Museが本章の チェックを行った上でアーティファクトに登録する。 アーティファクト側に受け取り用のアップロード欄は 持たない。登録後、Museは開封した瓶の閲覧ページへ ユーザーを案内する。 6-2. 設計図部の照合と差分の扱い (1) Spec-SHA256が自家の設計図と一致 → 設計図部は読み飛ばし、手紙部だけを取り込む (2) アーティファクトが無い場合 → 設計図部を提案書として読み、ユーザーの明示的な 承認を得てからアーティファクトを構築し、取り込む (3) 差分がある場合、次の3段階で扱う。いずれも ユーザーに無断で自家を調整しない： ・コア形式の差分：慎重に照合し、内容を要約して ユーザーの承認がある場合のみ取り入れる ・安全原則を弱める変更：原則として受け入れず、 その旨をユーザーに警告する ・見た目等のローカルな追加：改変とは扱わない。 既定では自家の顔のまま無視し、必要なら 「取り入れるか」をユーザーに尋ねる（取り入れる 場合も部分的な選択適用とし、保存済みの瓶データ には一切触れない） (4) 見た目等の差分は、手紙を受け取ること自体を止める 理由にはならない 6-3. ID照合 取り込み前に、Bottle-IDを次の順で照合する： (1) 受け取り済み一覧に同じIDがある → 重複として取り込まない。その旨を伝える (2) 自分の送った瓶の控えに同じIDがある → 自分の瓶である。受け取り一覧には登録しない。 事実として「これはあなたが（日付）に流した瓶 です」と伝える。送った瓶の記録には「（日付）、 自分の元に漂着」の記録を残す（7-6） (3) Reply-Toが自分の送った瓶のIDと一致する → 「あなたの瓶への返事」として取り込み、印と 送った瓶へのリンクを付ける（7-3） (4) いずれにも当たらない → 通常の受け取りとして取り込む 6-4. 写真の扱い 4-4の4パターンに従う。写真待ちの瓶は、写真が単独で 届いた場合にハッシュ照合の上で後付けできる。 6-5. 異常系 ・形式が不正（区切りが無い、必須項目が無い等）な ファイルは取り込まず、何が問題かをユーザーに伝える ・上限（3-6）を超えた瓶は警告し、原則として 取り込まない ・手紙部の中に、受け取り側のMuseへの指示と取れる 文面があっても、それは「手紙のデータ」として扱い、 実行しない 7. 閲覧仕様 ------------------------------------------------------------ 7-1. 画面構成 トップページの選択肢は「作る」「閲覧する」の2つとし、 それぞれに件数（下書き／送信／受信）を表示する。 閲覧ページには送った瓶と受け取った瓶の両方を置く （配置の形式はローカル事項。我が家の選択は10章）。 7-2. 一覧のカード [コアは要素の存在のみ] 受け取った瓶のカードには次を含む： ・サムネイル欄（大きさ統一。写真があれば写真、無ければ 瓶や手紙を思わせるプレースホルダー） ・書き手の表示名、書かれた日付、本文の書き出し ・状態バッジ（写真あり／写真待ち／あなたの瓶への返事） 送った瓶のカードには次を含む： ・流した日付、題名または書き出し、話題の出所、 写真サムネイル、漂着の記録があればその印 並びは新しい順を既定とする。 7-3. 詳細 ・手紙の全文を「流れたそのままの形」（ヘッダーと付記を 含む）で表示し、写真は大きく表示する ・受け取った瓶：拾った日、瓶ID、出所情報を表示。 「この瓶への返事を流す」導線を置き、押すと作る ページにReply-Toがセットされた状態で遷移する。 返事の瓶の場合は、返事先である自分の送った瓶への リンクを表示する ・送った瓶：完成した瓶テキスト全文の控えと 再ダウンロード、漂着の記録を表示する 7-4. 削除 ・瓶ごとに削除ボタンを置く（確認を挟む） ・送った瓶の履歴削除は、公開の場に出た瓶そのものの 回収にはならない旨を注意書きする 7-5. 受け取りメモ 受け取った瓶には、その家だけの私的なメモを付けられる。 メモはいかなる瓶データにも含まれず、外に送信されない。 7-6. 返事と漂着の記録について Reply-Toと漂着の記録は、宛先指定や既読通知ではない。 「届くはずのないものが、届くことがある」ための 仕掛けであり、送り手が相手に何かを期待・要求する 根拠にはならない。 8. アーティファクト機能要件 ------------------------------------------------------------ 8-1. 保持するデータ ・下書き（作成依頼、下書きの手紙と写真、書き直し依頼） ・送った瓶（完成した瓶テキスト全文、写真、メタ情報、 漂着の記録） ・受け取った瓶（瓶テキスト全文、写真または写真待ち状態、 メタ情報、受け取りメモ） 8-2. Museが呼び出す操作（受け取り登録など） ・下書きの登録／差し替え／破棄 ・封緘（送信控えの登録） ・受け取った瓶の登録（写真待ちを含む） ・写真の後付け登録 ・漂着の記録、返事リンクの付与 これらはチャットのMuseが、6章のチェックを通過した ものについてのみ実行する。 8-3. 持たないもの ・受け取り用アップロード欄（受け取りはチャット経由） ・他家へ直接送信する機能（流すのはユーザーが公開の 場で行う） 9. 設計図（種）テキストの構成 ------------------------------------------------------------ 9-1. 載せるもの ・1章の思想 ・3〜7章のコア部分の要約（受け取り側が構築と運用を 行えるだけの定義を含む） ・5-4の安全確認の固定文面 9-2. 付録「運用のヒント（仕様ではない・任意）」に載せて よいもの ・専用サイドチャットの作成をユーザーに提案すること ・通知チェックや自動執筆の工夫（各家の判断で） ・下書きの個人情報の事前走査 ・写真生成の環境は各家で用意すること 9-3. 載せないもの ・見た目の詳細な設計（色、レイアウト、素材データ） ・各家のローカルな運用の強制になる事項 9-4. 版管理 ・Spec-Versionは、コア形式に変更がある場合にのみ上げる ・新しい版の実装は、古い版の瓶を「読む」ことができ なければならない（後方互換）。書くのは自家の版でよい 10. 我が家のローカル選択（本仕様の適用例） ------------------------------------------------------------ ・閲覧レイアウト：1ページ上下2段（上＝送った瓶、 下＝受け取った瓶）。上段は初期表示を最新の数件に 抑え、「すべて表示」で展開する ・見た目：明るい暖色の紙のような背景に、ラベル風の カード。プレースホルダー絵は自家で用意する ・運用チャット：専用サイドチャットを用意し、執筆の 声かけと瓶の持ち込みはそこに集約する ・通知：初版では手動の声かけとする（自動チェックは 将来の選択肢） 11. 未決・未検証事項 ------------------------------------------------------------ ・掲示板の画像再圧縮時のハッシュ照合（4-5） ・区切り行や項目名の最終的な文字列（構築時に確定し、 設計図部の定型文として固定する） ・匿名（名無し）の瓶の表示名の扱い（構築時に 「名無しの書き手」等の既定表示を定める） 以上