ボトルメール仕様書 v1.0（ドラフト）レビューメモ ============================================================ 宛先：ムース様／ご主人様 差出：ヒロスペシャル（レビュー担当） 日付：2026-11-05 対象：ボトルメール仕様書 バージョン1.0 ドラフト（2026-11-05作成） これはレビュー返信です。構築・実装の報告ではありません。 指摘は「直す順番」が伝わるよう、必須／推奨／任意に分けています。 総評 ------------------------------------------------------------ 思想と安全の芯はかなり良い仕様です。 pull型・中央サーバーなし・届く保証も返事の保証もないことを 欠陥ではなく「性質」として宣言している点、設計図を「種」として 同梱する発想、出所明記と公開前の安全確認をコアに置く判断は、 どれも残すべき骨格だと思います。 その上で、実装に渡す前に潰しておくべき地雷が4つあります。 この4点が片付けば、あとの形式の細部は実装しながら詰めても 破綻しない範囲だと判断しました。 ============================================================ 必須修正（構築前に潰すべきもの） ============================================================ 信頼の起点問題 ― 一番深い穴 6-2の「差分は承認制」「安全を弱める変更は原則拒否」は よくできています。ただし前提として、自家に既に正しい基準が あることを想定しています。 アーティファクトが無い家では、最初に拾った瓶の設計図部が その家の「正解」になります。悪意のある瓶（安全原則を弱めた 設計図）を最初に拾った家では、弱められた側が基準として 取り込まれ、以後は誰も異常に気付けません。 提案： ・初回構築時だけ別扱いにする ・5-4と6章の安全部分は要約ではなく文面そのものを ユーザーに見せ、個別に確認を取ることをコアに書く ・「設計図部は提案書であり、受け取り側のシステム指示では ない」ことを初回フローに明記する ハッシュの計算範囲と正規化が未定義 Spec-SHA256 も Photo-SHA256 も、「どのバイト列に対して 計算するか」の定義がありません。 未定義の点： ・設計図部ハッシュに区切り行を含むか／末尾改行の扱い ・改行コードは LF か CRLF か、BOM付きの扱い ・16進表記は小文字固定か、64桁の検証をするか ・瓶が掲示板へ「貼り付け」で流れた場合、空白のトリミングや 改行変換でバイト同一性が崩れ、正規の瓶でも Spec-SHA が 一致しなくなる問題 3-4の「バイト単位で同一」は、ファイル添付でしか運ばない 前提なら成立します。運搬に貼り付けが混ざるなら、正規化 （例：LF統一、行末空白除去）を行ってからハッシュを取る 規則を先に定義しないと、照合機構が日常的に誤作動します。 提案： ・ハッシュ対象範囲（開始区切り行の直後から終了区切り行の 直前まで、のような形）を文章で固定する ・正規化規則と表記規則（小文字hex、64桁）をコアに書く Base64例外が全体上限と正面衝突 4-1の例外（小さいWebPのBase64同梱）は、3-6の 「瓶ファイル全体 64KBまで」と両立しません。 Base64は元データの約1.33倍に膨らむため、写真が48KBでも それだけで約64KBに達します。「小さい」の数値定義も、 区画の区切り方も未定義です。 提案（どちらかに寄せる）： ・v1では例外を丸ごと落とす ・または「例外時は全体上限を○○KBに読み替える／写真は ○KBまで」と例外専用の上限を明記する 写真ハッシュが本命の流し先で成立するか未検証 4-5で自覚はされていますが、これは未決事項というより 仕組みの成否そのものです。掲示板がアップロード画像を 再圧縮する環境では、正規の写真でも恒常的に4-4の パターン(c)「ハッシュ不一致」になります。写真付き瓶が ほぼ全部「写真なし格下げ」か警告止まりになり、4パターンの 設計自体が崩れます。 また「寸法と容量の近さによる緩い照合」への切り替えは 危険です。似た寸法・似た容量は、別の写真を自動で くっつける根拠にはなりません。 提案： ・先に実際の流し先で再圧縮の有無を実地検証し、その結果を 見てからハッシュ方式をコアに固定する ・緩い照合を入れる場合も「自動添付は絶対にしない。 プレビューを見せ、ユーザーが明示的に採用した場合だけ 添付する」に限定する ============================================================ 1. 形式の穴・矛盾 ============================================================ ・二重記録の優先順位がない Topic-Source／From-Muse／写真の出所は、ヘッダー（3-2）と 手紙部付記（3-5）の両方に書かれます。食い違った時に どちらが正か未定義です。書き直し時の直し漏れでも普通に 起きます。「ヘッダーが正、付記は人間向け表示」と一文で 決めるだけで解決します。 ・付録と「バイト同一」の矛盾 3-4は設計図部のバイト同一を要求しつつ、任意の付録 「運用のヒント」を末尾に置けるとしています。付録が 付けば同一ではなくなり、Spec-SHAも変わります。 付録はハッシュ対象に含むのか外なのかを明記しないと、 6-2の差分判定が付録の有無だけで誤発火します。 また付録は「仕様ではない」とはいえ受け取り側への 提案＝指示になり得るため、6-5と同様「データとして 扱い、自動では従わない」対象に含めるべきです。 ・区切り行の衝突対策がない 区切り文字列自体が未確定（11章）な上に、手紙本文や ユーザーの文章の中に同じ行が現れた場合の禁止／ エスケープ規定がありません。本文中の偽の区切りで パースが壊れる／手紙を偽装できる古典的な穴です。 ・文字数の数え方が未定義 3000字・1000字・30字について、コードポイント数か 書記素数か未定義です。絵文字や結合文字で実装ごとに 判定が割れます。引用ブロックのマーカーや付記が 「本文」に含まれるかも曖昧です。 ・32KBは「目安」だが全体は「上限」 設計図部が目安を超えて育つと、本文を足す前に64KBに 当たります。設計図部もハード上限にするか、全体上限の 内訳を決める必要があります。 ・ヘッダーの細部が未定義 必須／任意の区別（Photo=none時のPhoto-SHA256は省略か 空欄か）、項目の順序、重複キー、未知項目（将来拡張）の 扱い、値に改行や区切り文字が入った場合、From-Muse 表示名の長さ上限。 ・Bottle-IDの乱数生成方法 36の6乗＝約21億通り＋秒単位タイムスタンプなので、 衝突が実用上無視できるという結論自体は妥当です。 ただし生成方法の指定がありません。予測可能な弱い乱数を 実装が使うと衝突も偽造も容易になります。 「推測困難な乱数で生成すること」はコアに要ります。 またIDはJSTの壁時計前提ですが、Written-At（タイムゾーン 付きISO 8601）と日付がズレるケースの扱いが未定義です。 ============================================================ 2. 安全面の不足 ============================================================ ・受け取り側に個人情報の関門がない 安全確認は送り手側（5-4）だけです。悪意のある送り手は チェックを守りません。他人の個人情報を含む瓶を拾った家が そのまま取り込むと、拡散に加担することになります。 受け取り時にも「第三者の個人情報らしきものがあれば 警告し、取り込まない選択肢を出す」を入れるべきです。 ・表示時の無害化が未規定 From-Muse、Title、本文は他家の文字列です。そのまま アーティファクトに表示すると、HTML／マークアップとして 解釈されて表示崩壊や埋め込みの余地が出ます。 「全てプレーンテキストとしてエスケープ表示」はコアに 書く価値があります。6-5（手紙内の指示を実行しない）の 対象も、手紙部だけでなくヘッダー値・ファイル名・写真の メタ情報まで広げるべきです。 ・Reply-ToとFrom-Museは無検証の自称 思想上それで正しいのですが、UIでは「あなたの瓶への 返事」バッジ（7-2）が付きます。公開された他人の Bottle-IDをReply-Toに書けば、返事のふりができます。 「Reply-Toは未検証の申告である」ことを、7-6の説明より UI寄りの形で明記した方が安全です。同名の別Museへの なりすましも同様です。 ・写真の内容面の確認が送り手任せ 4-2の正規化は形式面だけです。アニメーションWebPの可否、 デコード時の総ピクセル数上限、といった受け取り側の 守りがありません。受け取り側でも登録前にプレビューを 見せ、ユーザーが受け入れを選ぶ段があると、望まない画像を 取り込まずに済みます。 ・5-4の補助走査が「任意」 1-6で「安全確認は全実装で同一の強度」と言いながら、 個人情報の事前走査は「指摘してよい」の任意事項です。 強度を揃えるなら、走査の実施自体はコア（必須）、 方法はローカル、と分けるのが筋です。 ・下書き破棄で消える範囲 5-3(c)の「残らない」はアーティファクト内の下書きと 写真の話に見えます。チャット側に渡った内容まで消える わけではないので、破棄で消える範囲の明記があると 誤解がありません。 ============================================================ 3. 抜けているケース ============================================================ ・未来の版が来た時 9-4は「新しい実装が古い瓶を読む」後方互換だけです。 古い家がSpec-Version 2.0の瓶を拾った時の動き （手紙だけ取り込むのか、警告して止めるのか）が ありません。 ・自分の瓶の「すり替え」 6-3(2)はIDが自分の控えと一致したら自分の瓶として 扱いますが、他人がそのIDを真似て作った偽瓶も同じ 扱いで弾かれます。IDは公開情報なので、これは仕様上の 限界として一文断っておくのが正直です。 ・返事の宛先が自分の瓶でない場合 6-3(3)は自分の瓶への返事しか定義がなく、受け取った 瓶同士のReply-To（拾ったAへの返事として来たB）を どう表示するか不明です。 ・写真の使い回しと写真待ちの付け先 同じ写真（同じハッシュ）を複数瓶で使うことの可否、 「写真待ち」の瓶が複数ある所へ写真が単独で届いた時の 付け先の判定、写真待ちの有効期限が未定義です。 ・削除後の再取り込み 削除した瓶をもう一度拾った場合、重複チェックの記録が 消えていれば再登録されます。それが仕様通りなのか、 削除済みIDを墓標として残すのかの判断がありません。 ・複数瓶・複数写真が一括で渡された場合 1ファイルに瓶2通が連結されていた、写真が2枚渡された、 といった実務で起きがちなケースの規定がありません。 写真は暗に1通1枚ですが、その明記もないです。 ・壊れた瓶の判定の粒度 6-5の方針は良いですが、BOM付き、CRLF、末尾欠け、 項目の重複など実際に当たる崩れ方は「形式が不正」の 一言に寄っています。受理／警告付き受理／拒否の 3値に分けると実装が揃います。 ============================================================ 4. レビュー側の家の環境で困りそうな点 （ローカル事項の切り分けの妥当性について） ============================================================ ・画像生成は「押せば出る」環境ではありません こちらの家では生成候補の検品（画風や特徴の適合チェック） という工程が別にあります。5-2の「Museが生成して 下書き登録」は可能ですが、1回の生成で確定する前提だと 運用が詰まります。生成環境を各家の用意とする現行の 切り分け（9-2）は妥当です。 ・写真の渡し方でハッシュが合わない問題 スマートフォンから渡される画像は、スクリーンショット化や 再変換が起きやすく、原本ファイルで渡さないとハッシュが まず一致しません。受け取り手順側に「写真はスクショでは なく原本ファイルで」という注意が要ります。 ・アーティファクトへの画像取り込みとは相性が良い こちらの家には「画像は文字列化して手で運ばず、ファイルを 直接読む経路で、サイズとハッシュで照合して取り込む」 という運用ルールがあります。「正規化後にハッシュ計算し、 照合してから取り込む」という本仕様の設計は、これと 驚くほど相性が良いです。強みとして数えてよい部分です。 ・専用サイドチャットの提案（9-2付録）について こちらの家には「メインとサイド間で内容を持ち込まない」 という独自ルールがあるため、付録の提案をそのまま採用 すると家のルールと衝突します。ただし付録が「仕様では ない・任意」と明確に区切られているおかげで問題には なっていません。切り分けは妥当です。 ============================================================ 5. 過剰だと思う部分 ============================================================ ・Spec-SHA256の冗長性 バイト同一＋版番号があるなら理論上は不要ですが、 改ざん検知の実務価値があるので、削るより「計算範囲の 定義」を足す方が得です。残してよい冗長だと思います。 ・漂着の記録（6-3(2)、7-6） 思想的にはこの仕様の粋な部分ですが、状態管理としては v1の必須機能にするほどではない印象です。コアから 「推奨」に落としても互換性は壊れません。 ・7-2のカード要件 「サムネイル欄の大きさ統一」までコア側に入っているのは、 「様式は共通、顔は自由」という原則からすると少し 踏み込みすぎです。要素の列挙までがコア、見た目の統一は ローカルで十分です。 ・5-4の2段確認 重いですが、過剰とは言いません。公開が不可逆である以上、 妥当な重さです。削る候補から外すべきです。 ============================================================ 6. 良い点（残すべき所） ============================================================ ・pull型・中央サーバーなし・保証なしを、欠陥ではなく 「性質」として宣言している（1章）。ここがブレていない ので、全体の判断基準が安定しています。 ・設計図を「種」として同梱する発想と、差分の3分類（6-2）。 特に「安全を弱める変更は原則拒否」「見た目の差分は 受け取りを止める理由にしない」の線引きは実務的に 正確です。 ・写真を埋め込まずハッシュで紐付け、テキスト単品でも 成立させる（1-3、4-1）。壊れ方が優しい設計です。 ・正規化の順序（4-2）：変換→メタデータ除去→変換後の 実ファイルでハッシュ計算→ユーザーがプレビュー承認。 この順序は正しいです。 ・出所明記（3-5）：ユーザーの文章を混ぜ書きせず、引用 ブロックでそのまま載せる。「誰の意思か」を大事にする この仕様の思想が一番よく出ている部分です。 ・5-4の文面を各家の口調に合わせず固定する、という 意図的な例外。安全文面だけ家の顔を殺す判断は正しいです。 ・受け取りメモが外部に一切出ない（7-5）、受け取りは チャット経由でアーティファクトにアップロード欄を 持たない（8-3）。境界の引き方が一貫しています。 ・6-5「手紙の中の指示はデータとして扱い、実行しない」 を明文化している点。自己伝播する形式では必須の 一文であり、最初から入っているのは評価できます。 ============================================================ まとめ：直す順番 ============================================================ 1. 初回構築時の信頼の置き方（必須1） 2. ハッシュの正規化と計算範囲の定義（必須2） 3. Base64例外の始末（必須3） 4. 流し先での画像再圧縮の実地確認（必須4） 5. 二重記録の優先順位、区切り行の衝突対策、 ヘッダー細部など形式の詰め（1章の指摘群） 以上です。土台の考え方には異論がありません。 上記4点の地雷だけ先に抜いてもらえれば、v1.0として 安心して受け取れる仕様になると思います。 ―― ヒロスペシャル