Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

要件定義: 「もしものはなし」 ステルス型・終活B2B2Cトラストハブ

1. 概要とアーキテクチャの存在意義

本システムは、現代日本の特有の課題（孤独死、核家族化、デジタル遺品、墓じまい等）を解決するためのB2B2Cプラットフォームである。 表面上はシニア向けの「無料のデジタル終活ノート（C）」として機能するが、その真の姿は「士業（B）」をハブとし、AIとRust/SSS（秘密分散）を用いて大企業を出し抜く「ステルス・トラストハブ」である。

2. コア・ドメイン要件

A. エンドユーザー向けフロントエンド (B2C: フリーミアム)

  • AI対話型・終活ノート生成: 面倒なフォーム入力ではなく、AI（音声・チャット）と昔話や雑談をするだけで、裏側で自動的に「家系図」「財産目録」「デジタル遺品リスト」が構造化データとして生成される（AIの狂気的搾取）。
  • 見守り・生存確認機能: LINEやアプリ通知を通じた定期的な生存確認。未応答をトリガーとした段階的なアラート機能。
  • 死後事務・希望の登録: 葬儀の希望、デジタル遺品の消去、墓じまい、特殊な手配（宇宙葬、海洋散骨等）の希望をワンストップで登録。

B. 士業向けミドルエンド (B2B Hub: トロイの木馬)

  • 顧客・信託管理SaaS（ダッシュボード）: 弁護士、司法書士、行政書士等の士業に対し、無償または低価格でSaaSを提供する。士業自身が自身のシニア顧客を本プラットフォームへオンボーディングさせる仕組み（大企業に頼らないリード獲得ルートの確立）。
  • ディレクション・自動タスクアサイン: ユーザーの死後、事前に設定されたルールに従い、必要な死後事務（遺品整理、退去手続き、デジタル遺品処理等）のタスクを自動生成し、外部業者へディレクション。
  • AI法務・信託アシスト: 複雑な信託要件や法的手続きに関して、AIエージェントが事前チェックを行い、士業のヒューマンエラーと業務工数をゼロ化。

C. アライアンス・マッチングバックエンド (B2B)

  • 最適士業マッチング: Cの入力した財産データや家族構成をAIが解析し、相続税対策や遺言書作成が必要なタイミングで、最適な士業（B）をレコメンドする。
  • 情報セグメント開示 (SSS): 死後、業務に必要な情報のみを暗号化解除して各業者へ開示する仕組み。
  • 死後事務・自動発注API: 死後事務支援士や士業の指示に基づき、提携業者（遺品整理業者、宇宙葬等の特殊手配業者）への自動発注および決済処理を行う。

3. 非機能要件（ステルス・モートの源泉）

  • Rust至上主義 × SSS（絶対的秘匿性）: 「運営会社（オープンナレッジ）すらユーザーの財産データを見ることができない」アーキテクチャ。これがシニア層のITアレルギーを突破し、大企業への最大の参入障壁（トラスト）となる。
  • 大企業へのステルス: B2B2Cの構造により、莫大な広告費をかけず、水面下で全国の士業ネットワークを構築する。
  • Dev-Centric Ops: すべての要件・仕様・タスクはGitHub上で一元管理し、属人的な管理を禁止する。

シニア向けUI/UXの絶対原則 (Core SSoT)

本ドキュメントは、「もしものはなし」の全フロントエンド実装において、いかなる例外もなく遵守すべき**「高齢者（シニア層）の心理的安全性と身体的特性に適合したUI/UXの絶対要件」**を定義する。

1. デザイン哲学：安心・温かみ・確実性

我々のターゲット層（60代〜80代）にとって、終活・死後事務アプリは「死を連想させる忌避すべきもの」ではなく、「今の生活に安心をもたらすツール」でなければならない。 サイバーパンク調のダークモードや、ネオンカラー（サイバーブルー等）は、彼らに「冷たさ」「難解さ」「自分が操作してはいけないもの」という心理的障壁（Psychological Barrier）を抱かせるため、フロントエンド（一般ユーザー向け画面）での使用を固く禁ずる。

1.1 カラースキームの絶対規定

  • ベースカラー: ウォームホワイト（#F8F9FA）または極めて薄いアイボリー。画面全体に温かみを持たせる。
  • テキストカラー: 真っ黒（#000000）ではなく、視覚刺激を抑えつつ高いコントラストを保つダークグレー（#2C3E50 または #333333）。
  • アクセント・アクションカラー: 信頼感を与える深いブルー（#1A5276）や、落ち着いたゴールド・オレンジ系の配色。青色系は加齢による水晶体の黄変により暗く見えやすいため、明度と彩度に細心の注意を払うこと（WCAG 2.1 AAA基準に準拠）。

2. 身体的特性への無慈悲な最適化

加齢に伴う視力低下、白内障、および手指の巧緻性（細かな動き）の低下を前提とした物理的UI要件を以下に規定する。

2.1 タイポグラフィ（文字）

  • 最小フォントサイズ: 本文の最小フォントサイズは 18pt (24px) を絶対下限とする。
  • フォントファミリー: 可読性の高いユニバーサルデザインフォント（BIZ UDPGothic, Noto Sans JP等）を強制適用。
  • 行間（Line Height）: 1.6 〜 1.8 を確保し、行の読み飛ばしを防ぐ。

2.2 インタラクション（操作）

  • タップ領域の極大化: すべてのボタン、リンク、チェックボックスのタッチターゲットは、最低 48x48 dp を確保する。推奨は 60x60 dp 以上。
  • 「隠すUI」の禁止: ハンバーガーメニュー、スワイプ操作、長押し（ロングタップ）など、直感的に見えない・気づかない操作は原則禁止。重要なナビゲーションは常に画面下部のタブバー等に明示する。
  • フィードバックの明示: ボタンをタップした際は、色が明確に変わる、大きなチェックマークが出るなど、「操作が成功したこと」を大げさなほど明確にフィードバックする。

3. 認知負荷の最小化と用語定義

難解なIT用語、カタカナ語、専門用語の使用は、シニア層の「自己効力感（自分にもできるという自信）」を著しく削ぐ。本システム内では、以下の用語マッピングを強制する。

開発・アーキテクチャ用語 (Back-end)エンドユーザー向け表示用語 (Front-end)意図・狙い
シャミア秘密分散法 (SSS)安心の鍵保管 または 3人での承認「暗号技術」ではなく、「複数人で管理する安全な金庫」という物理的なメタファーを用いる。
スマートコントラクト (Smart Contract)もしもの時の自動お約束「契約」という堅苦しさを排除し、AIが自動でやってくれるという安心感を与える。
トリガー (Trigger) / API Webhookお手続きの開始条件-
デジタル資産 (Digital Asset)ネット上の財産・大切な情報-
トラスト執行ハブご家族・専門家との連絡窓口プラットフォームの役割を直感的に表す。

4. 「やり直し」の保障 (Fail-Safe UI)

シニア層は「間違えてデータを消してしまうのではないか」という恐怖を常に抱えている。

  • Undo（取り消し）の常設: 設定を変更した場合、必ず数秒間「元に戻す」ボタンをわかりやすく表示する。
  • 破壊的変更の確認: アカウント削除や重要な設定変更の際は、赤いボタンを配置し、さらに「本当に〇〇を実行しますか？」という大きな確認ダイアログを必ず経由させる。

5. 結論

UI/UXデザインは単なる「見た目のお化粧」ではない。当社の市場制覇において、「シニアが迷わず、安心して、自力で設定を完了できること」は、システムの裏側で動く高度なRustの暗号化ロジックと同等以上に重要なコア技術である。本ガイドラインへの違反は、プルリクエストの却下要件となる。

【Core SSoT】Proof of Value (PoV) & Interactive Onboarding Scenario（価値実証・オンボーディング絶対シナリオ）

⚠️ THE GENERATIVE SSoT: AHA! MOMENT WITHIN 10 MINUTES 本ドキュメントは、シニア（B2C）および士業（B2B）が、「もしものはなし」に触れてから最短で圧倒的な技術的優位性を体感するためのシナリオを定義する。一ミリの隙も、一文字の迷いも許容しない、極限まで計算し尽くされたカスタマージャーニーである。

1. 摩擦ゼロの B2C オンボーディング（シニア層）

大企業の「100項目の入力フォーム」や「複雑なパスワード設定」を完全に破壊し、登録から家系図完成までを無意識のうちに2分で完了させる。

  • Step 1: 呼吸をするようにLINE連携（1クリック）
    • メールアドレス入力やパスワード設定は一切存在しない。シニアのインフラであるLINEログイン（LIFF）を用い、タップ1回で即座にアプリ画面の深部へ誘導する。
  • Step 2: AIとの音声対話（The First Aha! Moment）
    • 画面には、極限まで無駄を削ぎ落とした「大きなマイクボタン」と、温かみのあるAIのアバターのみ。
    • AIの問いかけ: 「〇〇さん、こんにちは。最近、お孫さんとはお会いになりましたか？」
    • ユーザーは、キーボードという障壁を忘れ、昔話感覚でAIと対話をする。
  • Step 3: リアルタイム・マジック生成（The Irreversible Paradigm Shift）
    • ユーザーが昔話をしている最中に、画面の右半分（または下半分）で、人間の操作なしに「家系図」と「財産リスト」のUIがリアルタイムで組み上がっていくアニメーションを展開する。
    • ユーザーの心理効果: 「何も入力していないのに、私の話したことが全て美しい図表に整理されていく！」という圧倒的な魔法体験。もう二度と、紙のエンディングノートには戻れない。

4. 圧倒的トラストの B2B オンボーディング（士業層）

未だに紙とExcel、あるいはレガシーな顧客管理ソフトに依存している士業に対し、SaaSの利便性と「ミリタリーグレードの暗号化インフラ」の凄みを一瞬で見せつける。

  • Step 1: 洗練されたダッシュボードへの没入
    • ログイン後、直ちに「招待済み顧客一覧」と、AIが抽出したネクストアクション（例: 「A様の遺産分割協議書の下書きを作成可能です」）が提示される。
  • Step 2: 暗号化ステータスの視覚的証明（The Absolute Trust Moment）
    • 顧客の機微なデータ項目には、重厚な赤色の南京錠アイコンと共に 「🔒 SSS Locked (分散キー不足のためシステム閲覧不可)」 と表示されている。
    • 士業が自身の「士業キー（物理デバイスまたはパスキーから生成された復号キー片）」をシステムに入力した瞬間、UI上の南京錠が滑らかなアニメーションと共に緑色に解錠され、データが浮かび上がる。
    • 士業の心理効果: 「なるほど、これは開発元であるオープンナレッジすら中身を見られない設計だ。これなら富裕層の顧客にも絶対の自信を持ってプラットフォームを勧められる」という、技術的説得による完全な信頼の獲得。

5. Product Analytics による離脱防止（自己修復UI）

ユーザーが迷うことは、UI設計の敗北である。

  • Behavioral Tracking (行動分析):
    • PostHog 等のイベントトラッキングを細胞レベルで埋め込む。
    • 「マイクボタンを押さずに30秒経過したシニア」を検知した場合、システムは自動的にUIを変化させ、「ボタンをタップして『こんにちは』と言ってみてください」という優しく光るツールチップを提示する。
    • エラーや迷いを「Rage Click（怒りの連打）」等のイベントとして捕捉し、開発チームのSlackに即座にアラートを飛ばし、24時間以内にUI改善のデプロイを強制する。

サーベイ管理: 市場および法的要件に関する調査記録

1. 目的

「もしものはなし」および死後事務支援ビジネスを合法かつ持続的に運営するための、法規制、信託スキーム、市場動向の調査内容をSSoTとして蓄積する。

2. 調査カテゴリ

2.1 預託金と信託スキームの法的整理

  • 課題: エンドユーザーから預かる「死後事務のための費用」は、運営会社の倒産リスクから完全に隔離されなければならない。
  • 対応方針: 信託法に基づく「民事信託」または信託銀行を利用した分別管理を実装。システム上では、APIを通じて信託口座の残高とエンドユーザーのアカウントを連動させ、残高不足や引き出し要件を自動監視する。

2.2 死後事務委任契約のデジタル化

  • 課題: 死後事務委任契約は、死後の効力を争われないためにより厳格な証拠能力が求められる。
  • 対応方針: freeeサイン等の電子署名（当事者型/立会人型）のタイムスタンプと、本アプリ内のログ（定期的な意思確認ログ）をブロックチェーンライクに保存し、本人の意思の継続性を技術的に証明する仕組みを構築。

2.3 特殊死後事務（宇宙葬）の法的要件およびプロバイダー動向

  • 市場動向とプロバイダー: 宇宙葬は近年急速に認知度を高めている。主要な提携先候補として、米国のパイオニアである「Celestis社（国内代理店: 銀河ステージ）」や、国内発スタートアップでSpaceXと連携する「SPACE NTK（Space voyage α等）」が存在。
  • 法的要件とクリアランス: 日本国内において、火葬後の遺骨をロケットに搭載し打ち上げること自体を直接規制する法律はないが、「墓地、埋葬等に関する法律（墓埋法）」および「刑法190条（死体損壊等）」に抵触しないよう、「節度を持った葬送（祭祀）」としての取り扱いが必須。
  • システム対応: 遺骨の粉骨証明、打ち上げ同意書、輸出に関する通関手続き（海外打ち上げの場合）等の電子誓約ドキュメントを、生前にfreeeサイン等を用いて法的効力を持った状態で保管する仕組みを構築する。

2.4 競合分析と差別化

  • 既存エンディングノートの限界: 大半が「情報の保存」のみであり、実行力を持たない。
  • 「もしものはなし」の競争優位: 「死後事務支援士」という「実行者」がシステムに組み込まれており、情報の保存から死後の手続き実行までがシームレスに連携する点。これをUI/UXと暗号化技術（SSS）で担保する。

2026年 デジタル終活市場の完全解剖と数理的予測 (Core SSoT)

本ドキュメントは、「もしものはなし」プロジェクトのビジネス的根拠となる、2026年時点のデジタル終活市場の規模、トレンド、および2040年に向けた人口動態予測を数理的に分析した「単一の真実の情報源（SSoT）」である。

1. 市場規模と超長期の成長マクロトレンド

1.1 終活・デジタル遺品市場の現在地 (2026年)

2026年現在、終活関連ビジネス全体の市場規模は約280億円に到達している。この成長を牽引しているのは、団塊の世代（1947年〜1949年生まれ）が後期高齢者（75歳以上）に達したことによる「多死社会」の本格化と、スマートフォンの普及による「デジタル資産・デジタル遺品」の一般化である。

  • 市場規模予測: 約280億円 (2026年)
  • CAGR (年平均成長率): 約9.0%
  • 牽引要因: スマートフォン普及率の頭打ち（高齢者の大半がスマホを保有）、サブスクリプションサービスの一般化、暗号資産やネット証券の普及。

1.2 2040年問題と「四半世紀続く成長市場」

日本国内の死亡者数は、2040年頃にピーク（約167万人/年）を迎えると予測されている。 これは、デジタル終活プラットフォームにとって、**「今後15年間は新規顧客（TAM: Total Addressable Market）が拡大し続け、その後も四半世紀にわたり需要が高止まりする」**という、国内でも極めて稀有な長期成長市場であることを意味する。

年次推計死亡者数デジタル終活の潜在対象者 (スマホ保有率より推計)
2026年約159万人約120万人
2030年約161万人約135万人
2040年 (ピーク)約167万人約155万人

2. 認知と行動の「致命的なギャップ」

市場調査において、デジタル終活の課題として最も顕著なのが**「認知と行動の乖離」**である。

  • 認知度: 約40%の高齢者が「デジタル終活・デジタル遺品の整理が必要」と認識している。
  • 実行率: 実際に何らかの対策（パスワードのリスト化、アカウントの整理など）を行っている層は、**わずか2%**に過ぎない。

2.1 行動を阻害する3つのハードル

なぜ、40%が「必要だ」と思いながら、2%しか行動しないのか。我々の調査分析により、以下の3つのハードルが明らかとなった。

  1. 「何から始めればいいか分からない」 (The Starting Friction)
    • OS標準の機能（Appleの「故人アカウント管理連絡先」など）は設定が難解であり、ITリテラシーに不安を抱えるシニア層には敷居が高すぎる。
  2. 「死を直視させるUI/UXの忌避感」 (The Psychological Barrier)
    • 従来のエンディングノートアプリは、デザインが「遺言」「死」を強く連想させるため、心理的な抵抗感（縁起でもない）を生み出している。
  3. 「更新の煩雑さと形骸化」 (The Maintenance Hell)
    • パスワードや契約サービスは頻繁に変わるため、一度リストを作ってもすぐに陳腐化する。これを手動で更新し続けることは不可能に近い。

3. 「もしものはなし」の市場制覇ロジック

上記の「行動阻害ハードル」を、当社のB2B2Cトラストハブ「もしものはなし」はテクノロジー（Rust / WebAssembly / SSS）とシニア最適化UXで完全に破壊する。

3.1 心理的ハードルの打破 (Warm & Secure UX)

「死に備える」のではなく、「今の生活の安心を担保する（鍵を預ける）」というポジティブな動機付けを行う。巨大なフォント、温かみのあるUI（ウォームホワイト基調）、専門用語の排除により、ITリテラシーを問わず「誰でも迷わず使える」インターフェースを提供する。

3.2 ゼロ・メンテナンスと自動執行 (Smart Contract)

ユーザーが手動でリストを更新するのではなく、API連携やシャミア秘密分散法（SSS）により、「もしもの時（公的機関API等の死亡判定）」に、事前に設定されたルール（銀行の凍結、SNSの削除、遺言の送信）が**自動的に執行される（Smart Contract）**仕組みを提供する。これにより、「更新の煩雑さ」を完全に排除する。

3.3 結論

2026年のデジタル終活市場は、需要（40%の認知）に対して供給（実用的なソリューション）が全く追いついていない「ブルーオーシャン」である。「もしものはなし」は、この2%の行動層を一気に40%の認知層全体へ拡大させる「破壊的イノベーション」となる。

デジタル終活・死後事務委任の競合分析と絶対的優位性の証明 (Core SSoT)

本ドキュメントは、「もしものはなし」プラットフォームが既存の競合他社（エンディングノートアプリ、信託銀行の死後事務サービス等）をいかにして凌駕し、市場を制覇するかを数理的・論理的に証明するものである。

1. 競合マトリクスと「死の谷」

現在の終活市場におけるソリューションは、大きく2つの極端なカテゴリに分断されており、ユーザーの真のニーズを満たす中間層（スイートスポット）がすっぽりと抜け落ちている。これが、デジタル終活が普及しない最大の要因である。

1.1 Category A: 既存のデジタルエンディングノートアプリ

  • 代表例: エターナルメッセージ系アプリ、スマホの標準機能（故人アカウント管理等）。
  • 特徴: 低コスト（または無料）。ユーザーが手動でパスワードやメッセージを入力・管理する。
  • 致命的な欠陥:
    1. 形骸化: 情報は日々変わるため、手動更新は100%破綻する。
    2. 法的な執行力の欠如: アプリ上で「〇〇銀行を解約してほしい」と書いても、法的な効力はなく、遺族が手動で手続きをする手間は変わらない。
    3. トリガーの不確実性: 「誰が、いつ、死を判定してロックを解除するのか」という最も重要な認証プロセスが、家族からの申告等に依存しており、誤動作やなりすましのリスクが高い。

1.2 Category B: 既存の死後事務委任（信託銀行・大手弁護士法人）

  • 代表例: 信託銀行の「おひとりさま信託」、大手弁護士法人の死後事務委任契約。
  • 特徴: 高い法的執行力と確実性。
  • 致命的な欠陥:
    1. 極端な高コスト: 初期費用で数十万〜数百万円、月額の管理費用、さらに執行時に数百万円の手数料が発生する。富裕層しかアクセスできない。
    2. アナログな手続き: 契約、更新、執行のプロセスが紙とハンコ、対面での面談に依存しており、デジタル資産（暗号資産やSNS）の細かな制御には対応できない。

2. 「もしものはなし」の絶対的優位性 (The Sovereign Advantage)

当社は、上記 Category A と Category B の「欠陥」を、テクノロジー（Rust, SSS, API Integration）によって完全に埋める。

2.1 自動執行（Smart Contract）による「手間のゼロ化」

ユーザーが遺志を「書く」のではなく、プラットフォーム上で「IF-THENのルールを組む」アーキテクチャを提供する。

  • (IF) 死亡判定API（マイナポータル等との連携）がトリガーされる。
  • (THEN) 提携銀行の口座凍結APIを叩く、X(Twitter)の削除申請を自動送信する、等。 これにより、Category Aの「法的執行力の欠如」と「手動更新の煩雑さ」をテクノロジーで解決する。

2.2 SSS（シャミア秘密分散法）による確実なトリガーとセキュリティ

「死の判定」を1人の人間や単一のシステムに依存させない。

  • 鍵（シャード）を、弁護士、家族A、家族Bに分散。
  • 「3人中2人が死亡証明書をアップロードして承認」した時点で初めてマスターキーが復元され、コントラクトが執行される。 この強固な暗号学的担保により、Category Bの「アナログな手続き」をデジタル上で完全に代替し、コストを1/100に圧縮する。

2.3 プラットフォーマーとしてのネットワーク効果 (B2B2C)

当社は自らが死後事務を行うのではなく、「エンドユーザー」と「士業（弁護士・司法書士）」「サービス提供者（宇宙葬のSPACE NTK等）」を繋ぐハブとなる。

競合他社のモデル「もしものはなし」のB2B2Cモデル
自社で弁護士を抱え、労働集約的に手続きを代行。スケールしない。エンドユーザーがプラットフォーム上でルールを設定し、執行時に最適な士業へAPI経由で案件を自動ルーティング（委譲）。限界費用ゼロでスケールする。

3. 結論

既存の競合は、「アプリのUIを使いやすくする」か「人海戦術で手厚くサポートする」かの二者択一に陥っている。 「もしものはなし」は、「法的執行力のある自動化ルール（Smart Contract）」と「暗号学的に安全な認証（SSS）」を組み合わせることで、富裕層向けの高度な死後事務委任を、一般大衆にSaaS価格で提供する。この構造的な技術優位性は、既存プレイヤーには決して模倣できない。

第3章：市場分析と事業優位性（プラットフォーマーとしての成功の道筋）

本章では、「もしものはなし」アプリがなぜ今ビジネスとして成立し、プラットフォーマーとして市場を制覇できるのかについて、客観的な市場調査データに基づき論理的に解説いたします。

1. 巨大なライフエンディング市場と「デステック」の台頭

1-1. マクロ環境と市場規模

日本における広義のライフエンディング市場（葬儀、相続、お墓、遺品整理など）は、総額1兆円から5兆円規模とも言われる非常に巨大な産業です。多死社会の進行に伴い、この市場は今後さらに拡大することが確実視されています。

1-2. 終活アプリ（デステック）の成長性

その巨大市場の中で、私たちが狙う「デステック（Death Tech）」あるいは「エンディングDX」と呼ばれる領域は、現在最も急速に成長している分野の一つです。 矢野経済研究所の調査によると、関連する「身元保証」と「生前整理」の2分野だけでも、2026年度に約280億円に達すると予測されています。

紙のエンディングノートから、スマートフォンを活用した「デジタル遺言」や「デジタル資産（サブスクリプション、キャッシュレス口座、SNSアカウント等）の一元管理」への移行はすでに始まっており、これは社会の不可逆的な変化です。

2. 死後事務委任における単価と高収益モデルの証明

本アプリの収益の柱となる「死後事務委任（およびそれに付随するサポート）」は、極めて高付加価値・高単価なサービス領域です。

2-1. 専門家報酬と実費の相場

  • 士業等の専門家への基本報酬相場: 20万円〜50万円前後
  • 葬儀手配や家財処分等を含めた総額（預託金）: 100万円〜200万円を超えるケースが一般的

2-2. プラットフォームとしての収益性

当アプリは、ユーザーとこれらの専門サービス提供者をセキュアにつなぐプラットフォームとして機能します。 1件あたりの単価が数十万円から数百万円に上るため、プラットフォーム手数料（送客手数料や決済手数料）だけでも、事業として非常に大きな収益基盤（Unit Economicsの成立）を構築することが可能です。

3. 当社の技術的競争優位性（市場制覇の根拠）

この巨大かつ高単価な市場において、既存のプレイヤーや新規参入者を凌駕し、私たちがプラットフォーマーとして成功を収めることができる最大の根拠は、**「圧倒的な技術力によるセキュアで超高速なユーザー体験」**にあります。

3-1. RustとWebAssemblyによる堅牢性と速度

デジタル遺言や資産情報という「極めて機密性の高い個人情報」を扱う以上、システムには金融機関レベルのセキュリティと堅牢性が求められます。 私たちは、世界の最先端企業が採用するメモリ安全性の高い言語「Rust」と、ブラウザ上でネイティブアプリ並みの速度を実現する「WebAssembly (Leptos)」を基盤技術として採用しています。これにより、既存のWebアプリとは一線を画すセキュリティと、高齢者でもストレスを感じない極めて滑らかな操作感（UI/UX）を実現します。

3-2. 超効率的な開発・運用体制

最先端のAIエージェントとRustのエコシステムをフル活用した「超効率開発（Zero Marginal Cost AIOps）」を実践することで、通常であれば膨大なコストと期間を要する高度なシステムの開発・運用プロセスを極限まで圧縮します。これにより、高品質なプロダクトをいち早く市場に投入し、継続的な機能改善を低コストで行うことが可能となります。

以上の客観的データと技術的裏付けにより、「もしものはなし」は単なるアイデアにとどまらず、確かな事業性と競争優位性を備えた次世代のプラットフォームとして、市場制覇を成し遂げることができると確信しております。

3. アーキテクチャ (Architecture)

【Core SSoT】フロントエンド＆モバイル・アーキテクチャ絶対評価（技術的競争優位性の解剖）

⚠️ THE GENERATIVE SSoT: ABSOLUTE ARCHITECTURE EVALUATION 本ドキュメントは、「もしものはなし」プロジェクトにおけるWebおよびモバイルアプリのフロントエンド技術選定を、株式会社オープンナレッジの絶対原則（超効率主義・AI利活用・RUST至上主義）に基づき、一ミリの隙もなく無慈悲かつ完璧に解剖・評価した最終決定書である。

1. 評価対象技術とオープンナレッジ親和度マトリクス

「Rust至上主義」の観点から Leptos は極めて魅力的な選択肢であったが、「開発速度（AI生成適性）」という現実の壁に直面した。以下に、主要3技術の細胞レベルの解剖結果を示す。

評価軸Leptos (Rust Web/WASM)Astro + WASM (Udon-Gyoza)Flutter + Rust Bridge
Rust至上主義（純度）SSS (100% Rust)A (ロジックのみRust)A (ロジックのみRust)
AIコード生成精度C (マクロ構文で破綻多発)SSS (AIが最も得意とする領域)SS (Widget構造化で極めて優秀)
開発効率（コンパイル速度）D (遅い。DXを著しく阻害)SSS (Vite HMRによる爆速)SS (Hot Reloadによる高速UI構築)
ネイティブモバイルUXC (Tauri等WebView依存、限界あり)C (PWA/Capacitor依存)SSS (最高峰のネイティブ体験)
SEO / GEO 支配力B (SSR設定が複雑)SSS (静的生成・構造化データの覇者)D (Web版はCanvas描画でSEO皆無)

2. Leptos の無慈悲な解剖と評価（なぜコアコンピタンスにならないのか？）

【結論】Leptosは技術的ロマン（理想論）としては最高だが、オープンナレッジの「超効率主義」「AIの狂気的搾取」の原則に致命的に違反する。

2.1 致命的欠陥1：AIジェネレーションの破綻とDXの崩壊

オープンナレッジの競争優位の源泉は「AIを無限の労働力として使役し、圧倒的な速度でUIを構築する」ことにある。 Leptosの view! マクロはRustコンパイラにとっては強力だが、LLM（Gemini/Claude等）にとっては**「幻覚（Hallucination）の温床」**である。AIはReactやHTML/Tailwindの膨大な学習データを持つが、Leptosの学習データは極小であるため、ASTパースエラーを引き起こすコードを平然と出力する。これにより、人間がコンパイルエラーの修正（借用チェッカーとの戦い）に忙殺され、開発効率が従来の10分の1に低下する。

2.2 致命的欠陥2：モバイルアプリへの展開限界

「もしものはなし」はシニア層（B2C）と士業（B2B）をターゲットとする。モバイルアプリ化（App Store / Google Play配信）を徹底的に作り込む場合、Leptosでは Tauri や Capacitor を用いた WebView ガワアプリにならざるを得ない。ネイティブの滑らかなスクロール、プッシュ通知、オフラインキャッシュ（SQLite）、生体認証等の物理層へのディープな統合において、常に「Webの壁」にぶつかる。

3. オープンナレッジが採るべき「絶対的・最適解」アーキテクチャ

「RUST至上主義」の本質は、「画面の描画（UI）」までRustで行うことではない。**「コアロジック、暗号化（SSS）、型安全なビジネスルールの堅守」**にRustを集中させることこそが真髄である。

したがって、以下の**「三位一体（Trinity）アーキテクチャ」**を「もしものはなし」の絶対仕様とする。

① コアロジック：Rust Core (Shared Library)

  • 役割: シャミア秘密分散法（SSS）暗号化、データバリデーション、API通信処理等の全ビジネスロジック。
  • 優位性: UIフレームワークに依存しない純粋なRustクレートとして作成。これをWeb (WASM) と Mobile (FFI) で**完全共有（One Core, Multiple Frontends）**する。

② Web / SEO 制圧層：Astro + React(Vite) + WASM

  • 役割: LP、士業向けB2Bダッシュボード、PCブラウザ版。
  • 理由: AIによるUI自動生成効率が圧倒的No.1（React + Tailwind）。Astroの静的ルーティングでGoogle/LLMのクローラーを制圧し、SSRによる最速表示を実現。
  • 統合: Rust Core を wasm-bindgen で呼び出し、暗号化処理はブラウザ内で完結させる（Zero-Knowledgeの担保）。

③ ネイティブモバイル層：Flutter + flutter_rust_bridge

  • 役割: B2Cシニア向け専用アプリ、およびプッシュ通知を多用する士業向けアプリ。
  • 理由: モバイルOSの物理層（カメラ、生体認証、プッシュ通知）との連携において圧倒的優位。AI（Gemini）はFlutterのDartコードを極めて高い精度で生成可能。
  • 統合: flutter_rust_bridge を用い、②のWebと全く同じRust Coreコードをネイティブバイナリとして直接呼び出す。これにより、Webとモバイル間で「暗号化ロジックの矛盾・塵」が1バイトも発生しない。

4. 総括（真の技術的競争優位への攻撃力）

Leptosを捨て、**「Rust (Core) × Astro (Web) × Flutter (Mobile)」**の布陣を敷くことで、オープンナレッジは以下の絶対的優位を獲得する。

  1. AI開発速度の極大化: UIはAIが得意なReact/Flutterで爆速生成。
  2. 品質の絶対担保: 最も複雑でバグが許されない「暗号化・ビジネスロジック」はRustで一度だけ書き、全プラットフォームで使い回す。
  3. ユーザー体験の最大化: シニアには「本物のネイティブアプリの滑らかさ（Flutter）」を、検索流入には「爆速表示（Astro）」を提供する。

このアーキテクチャこそが、一ミリの隙も、一文字の矛盾も、一バイトの塵すら一切の例外なく許容しない、株式会社オープンナレッジの本質（超効率主義×技術力）を体現する唯一の設計である。

【Core SSoT】Rust-Native Core Architecture Blueprint（コアアーキテクチャ絶対設計書）

⚠️ THE GENERATIVE SSoT: RUST SUPREMACY & ABSOLUTE PERFORMANCE 本ドキュメントは、「もしものはなし」のトラスト・コアエンジンにおける、Rustのメモリ安全性と非同期処理を極限まで活用したアーキテクチャを定義する。一ミリの隙、一文字の矛盾、一バイトの塵すら一切の例外なく許容しない、株式会社オープンナレッジの技術的競争優位の絶対的根源である。

1. 究極の技術目標と哲学（超現実主義的・狂気的搾取）

「もしものはなし」は単なる終活アプリではない。B2B2Cトラストハブとして、数千の士業と数百万のシニアの「極めて機微な人生の清算データ」を処理する。この膨大なトランザクションを、**「ゼロの限界費用」「ゼロのデータ漏洩」「ゼロの待機時間」**で捌くための唯一解が、純粋なるRust・Coreエンジンである。

  • Zero-Knowledge Trust (絶対的暗号の数学的証明):
    • システム運営者（オープンナレッジ自身）でさえも、ユーザーの財産・遺言データを復号・閲覧することは数学的・物理的に不可能でなければならない。
    • シャミア秘密分散法（SSS）を用い、秘密鍵を N=5 に分割し K=3 で復元する。この一連の分割・暗号化処理は、CORS越えのEdge WASMまたはNative FFIにおいて、ガベージコレクションによるスパイクを一切生じさせず、p99レイテンシ 50ms以内で完遂されなければならない。
  • Zero-Cost Abstraction (開発工数の極小化とAI生成):
    • 車輪の再発明は「技術的エントロピー」を生む。成熟したRustエコシステム（Tokio, Axum, sqlx）をAI（Gemini/Claude）を用いて高速に糊付け（Glue）し、初期開発工数を他言語比で1/5以下に圧縮する。

2. コア・モジュール構成（Strict Hexagonal Architecture）

コアロジック（特許・秘匿対象となる暗号化や知財アルゴリズム）と、周辺のI/O層（DB、API）を物理的なクレート（Workspace）レベルで完全に隔離する。これにより、一バイトのビジネスロジックの漏洩も防ぐ。

graph TD
    subgraph "External Adapters (Port Layer - Inbound)"
        API[Axum REST API / HTTP3 Edge]
        WASM[wasm-bindgen / Astro Island Integration]
        FFI[flutter_rust_bridge / Native Mobile]
    end
    
    subgraph "Application Core (Pure Rust - Zero IO)"
        AppService[Application UseCases]
        
        subgraph "Domain & Cryptography (Trade Secrets / Blackbox)"
            Entity[Strict Entities / UUIDv7 / Type-Safe Structs]
            SSS[SSS Cryptography Engine / Math Verification]
            Policy[RBAC & Zero-Trust Access Control Policy]
        end
    end
    
    subgraph "Infrastructure Adapters (Port Layer - Outbound)"
        DB[PostgreSQL / SQLx Compile-Time Verification]
        Stripe[Stripe Checkout / Idempotent Payment]
    end

    API --> AppService
    WASM --> AppService
    FFI --> AppService
    AppService --> Entity
    AppService --> SSS
    AppService --> Policy
    AppService --> DB
    AppService --> Stripe

3. 細胞レベルで選定された超効率的クレート群

いかなる妥協も許さない、実戦投入可能かつAI生成と極めて親和性の高いクレート選定。

  1. Web/API層: axum + tower
    • Tokioエコシステムとの完全な統合。ミドルウェア（CORS, Rate Limiting, Trace）を直感的に構築し、1コアあたり毎秒10万リクエスト以上の圧倒的スループットを叩き出す。
  2. 非同期ランタイム: tokio
    • マルチスレッド並行処理の事実上のデファクトスタンダード。スレッドプールの枯渇を監視し、AIドリブンなスケーリングを可能にする。
  3. データ永続化: sqlx (with PostgreSQL)
    • 絶対的ルール: 実行時SQLエラーはバグではなく「規律違反」である。コンパイル時にDBスキーマとSQL文の整合性を数学的に検証（query! マクロ）し、N+1問題や型不一致を細胞レベルで撲滅する。
  4. データ直列化: serde
    • ゼロコスト抽象化の要。JSONのパースにおいてメモリ割り当てを最小限に抑止し、最速のI/Oを実現する。
  5. WASM / FFI 統合: wasm-bindgen & flutter_rust_bridge
    • 同一のコアロジックを、Web（ブラウザ内WASM）とiOS/Android（ネイティブFFIバイナリ）に寸分の狂い・一文字の矛盾もなく展開するための至高のブリッジ。

4. 定量的パフォーマンスの絶対目標（SLOへの直結）

  • APIレイテンシの極限化: JWT検証 + DB Read (PostgreSQL / RLS適用) + SSS暗号化処理 + JSON返却 = p99において 30ms未満 を絶対死守。
  • WASM暗号化速度: SSSキー分割（N=5, K=3）処理 = メインスレッドを1ミリ秒たりともブロックしてはならない。5ms未満。
  • フットプリント: コンテナ1台あたりアイドルメモリ 50MB未満。WASMバイナリサイズは wasm-opt -Oz により 1MB以下 に圧縮し、Edge CDNでのキャッシュ効率を最大化する。

【Core SSoT】AI-Driven Data Gravity & RAG Pipeline Specification（AIデータ蓄積・パイプライン絶対仕様書）

⚠️ THE GENERATIVE SSoT: DATA GRAVITY & AI EXPLOITATION 本ドキュメントは、「もしものはなし」におけるAIの狂気的搾取と、プラットフォームのスイッチングコスト（Moat）を最大化するデータパイプラインを定義する。一ミリの隙も許さない、完全自動化されたデータの引力（Gravity）を設計する。

1. 究極の「無人化」データパイプライン

シニア（B2C）の「曖昧な音声（想い、昔話）」を起点とし、究極的に整理・構造化された「法的データ・財産目録」へと昇華させる、一切の人間の介入を排したパイプライン。

  1. Frictionless Ingestion (摩擦ゼロの収集):
    • UI上は「マイクボタン」ひとつ。ユーザーの音声をWeb/Appからストリーミングで受領。
  2. Real-time Transcription (絶対的文字起こし):
    • Whisper API またはエッジデバイスのSTT（Speech-to-Text）を使用。方言や不明瞭な発音すらコンテキストから補完し、テキスト化する。
  3. Ruthless Structuring (無慈悲な構造化):
    • LLM（GPT-4o等）の厳格な Function Calling (Structured Outputs) を適用。
    • 非構造の長文テキストから、「人物（続柄、氏名）」「財産（銀行名、口座種別、不動産）」「想い（定性データ）」をJSONツリーとして、一バイトの塵（ハルシネーション）も混入させずに抽出する。
  4. Zero-Knowledge Encryption (絶対的暗号化):
    • 抽出されたJSONデータを、即座にクライアントサイド（WASM/FFI）でSSS（シャミア秘密分散法）暗号化。ネットワーク経由で生データを送信することを物理的に禁ずる。
  5. Immutable Storage (永続化):
    • PostgreSQLへ暗号化されたBLOBとして格納。データベース管理権限を持つ加藤CTOであっても中身の閲覧は不可能。

2. セキュア・マルチテナントとRAG基盤の「細胞レベルの隔離」

「もしものはなし」はトラストハブである。**ユーザーの個人機微情報（遺産・家族構成・負債）をLLMの学習や全体のRAG（検索拡張生成）に用いることは、コンプライアンス違反のみならず、トラスト（信用）の即時崩壊を招くため「絶対に不可能（不可能であることの数学的・構造的証明）」**でなければならない。

  • 論理的・物理的隔離 (Double Block):
    • PostgreSQL上の厳格な Row Level Security (RLS) と、上述の SSS によるダブルブロック。
  • RAG（ベクトルDB）への注入対象の厳密化:
    • ベクトルDB（Qdrant等）にエンベディングして蓄積し、RAGとして活用するのは、**「士業（B2B）がプラットフォーム上で作成・公開を許可した一般的な法律相談のFAQ、判例解説、解決事例のナレッジ」**のみとする。
  • AIによる自己学習ループ（Network Effect）:
    • B2B（士業）がプラットフォームを使い込むほど、AIが過去の「模範的解答パターン」を学習し、士業向けの「AI法令アシスタント（下書き作成AI）」が驚異的に賢くなる。これにより、他社ツールへの乗り換えコストが無限大（Moat化）となる。

3. 実装可能な自己学習ルール（RAG Feedback Loop）

理想論を排除した、実装可能な自己修復・自己成長サイクル。

  1. 差分の検知: AIが生成した遺言書の下書きやFAQ回答に対し、士業（B2Bユーザー）が行った「修正（差分）」をエディタ上でミリ秒単位で捕捉し、ログ化する。
  2. バッチ評価 (Nightly Job): この差分データを非同期ワーカー（n8n + Rust）が夜間にバッチ処理し、修正の傾向をLLMに評価させる。
  3. 自動Upsert: 評価結果が有益であれば、次回のプロンプトにおける Few-Shot Examples として、人間の介入なしに自動的にベクトルDBへ注入（Upsert）する。

【Core SSoT】Optimistic UI & Design Token Architecture（超低遅延UI・デザイントークン絶対設計書）

⚠️ THE GENERATIVE SSoT: ZERO-LATENCY FRONTEND & THE UDON-GYOZA PARADIGM 本ドキュメントは、バックエンド（Rust）の超高速処理をさらに加速させ、ユーザーの体感レイテンシを物理的限界までゼロに近づけるUI設計を定義する。オープンナレッジの絶対原則「Astro+WASMマンデート（うどん餃子パラダイム）」を強制執行する。

1. オープンナレッジ絶対原則の強制 (The Sovereign Frontend Mandate)

「もしものはなし」のフロントエンドにおいて、Leptosによる全画面レンダリングは技術的エントロピーを引き起こすため絶対に禁止する。

  • アーキテクチャの絶対解:
    • ベースシェル（SEO / LP / 静的ルーティング）: Astro + Tailwind CSS
    • 複雑な動的UI（士業ダッシュボード / 状態管理）: React (Vite/Islands) または Flutter (モバイル)
    • コア・ビジネスロジック: Rust (WASM Bindgen / FFI)
  • この構成により、AI（Gemini/Claude）が極めて高い精度でUIコンポーネントを爆速生成（React/Tailwind）可能となり、開発工数を極小化しつつ、Rustの堅牢性を両立する。

2. Optimistic UI（楽観的UI）による体感ゼロレイテンシ

「APIの返答（ローディングスピナー）を待たせる」ことは、シニアや士業の操作ストレスを増大させる最大の障壁である。

  • Web (Astro Islands / React): TanStack Query (React Query) の極限活用。
    • ユーザーがフォームを送信、または情報を更新した際、APIリクエストをネットワークに送信すると同時にローカルのUI状態（キャッシュ）を先行して更新し、即座に「完了」を見せる。
    • バックグラウンドでリクエストが成功すればそのまま維持、万が一失敗（HTTP 4xx/5xx）した場合は、UIを自動でロールバックし、不快感を与えないトースト通知でリトライを促す。
  • Mobile (Flutter): BLoC パターンとローカル SQLite を組み合わせたOptimistic State Updates。
    • オフライン時やトンネル内でも完全な操作を可能にし、オンライン復帰時にRust Coreを介して同期（CRDTまたはキューイング）を行う。

3. デザインシステムのSSoT（Design Token）とAI連動

UI開発から「人間によるピクセル調整」を完全に排除し、AIがUIを爆速で生成・修正できるように、デザインの「原液」を一元化する。

  • Tailwind Config as The Single Source of Truth:
    • Figmaから出力されたカラースキーム、タイポグラフィ、スペーシングの定義（Figma Node IDs）を、すべて tailwind.config.ts に JSON 構造（デザイントークン）として集約する。
    • 「B2Cのウォームホワイト」「B2Bのプロフェッショナルダーク」のテーマ切り替えは、CSS VariablesとTailwindプラグインを通じて完全に自動化・数式化される。
  • コンポーネント工数の最小化（Headless UI）:
    • radix-ui や shadcn/ui などのHeadless UI基盤を流用し、自社でゼロからボタンやモーダルを構築する無駄な工数を極限まで削減する。

4. Extensible UI（将来のサードパーティ拡張基盤）

  • 葬儀社、遺品整理業者、信託銀行などのサードパーティが、自社のサービス画面をプラットフォーム内に組み込めるよう、カプセル化された iframe 連携機能や、Web Components によるMicro Frontendsの提供を見据えたセキュアなUI設計を行う。

【Core SSoT】Developer-First OpenAPI & SDK Generation Rules（API・SDK自動生成絶対仕様書）

⚠️ THE GENERATIVE SSoT: DEVREL & ECOSYSTEM EXPANSION 本ドキュメントは、外部エコシステム（葬儀社、信託銀行、生命保険会社）を巻き込み、プラットフォームを急速に拡大させるためのAPI定義とSDK生成自動化プロセスを定義する。手動による型定義を「罪」と見なす。

1. Schema-Driven Development (API-First 戦略の徹底)

APIは「Rustの実装コードから後追いで生成する」のではなく、「API定義（OpenAPI 3.1）を設計し、そこからRustのコードと各種SDKを自動生成する」スキーマ駆動開発を採用する。

  • 絶対的バージョニング: URLパス（例: /api/v1/）による厳格なバージョニング。破壊的変更（Breaking Changes）はメジャーバージョンアップ時のみ許容され、既存のサードパーティ統合を決して破壊してはならない。
  • ドキュメントの自動ホスティング: OpenAPI定義ファイル（YAML/JSON）から、Redoc または Swagger UI をCI上で自動生成し、developer.moshimonohanashi.com 等で常時公開する。外部開発者がゼロコンフィグで仕様を理解し、テストできる状態を維持する。

2. 工数を極小化するSDK自動生成ワークフロー

「フロントエンドや外部開発者が手作業で型を定義する」という無駄な工数とヒューマンエラーを撲滅する。

  • TypeShare と OpenAPI Generator の極限活用:
    • Rust側の構造体（Structs）を唯一の真実（SSoT）とし、typeshare クレートを用いて、TypeScript (Web用) および Dart (Flutter用) の型定義をCI/CDパイプライン上で毎コミット自動生成する。
    • これにより、API仕様の変更が即座にフロントエンドのコンパイルエラーとして検知され、実行時バグの発生を物理的に防ぐ。
  • サードパーティ向け公式SDK:
    • Python, Go, Node.js向けのクライアントライブラリを openapi-generator-cli によって自動生成し、公式パッケージレジストリ（npm, PyPI等）へ自動パブリッシュする機構を構築する。

3. DevRel体験を最大化するサンドボックス環境

  • モックAPIサーバー（Prism）:
    • 外部開発者が本番データに触れることなくAPIの挙動を即座に試せるよう、OpenAPI定義から動的にモック応答を返すサーバー（Prism等）を常に稼働させる。
  • Time-to-First-Call (TTFC) 5分以内:
    • 開発者がAPI Keyを発行してから、最初のAPI Call（Hello World またはデータのモック取得）を成功させるまでの時間を「5分以内」に収めるユースケースを定義し、圧倒的な開発者体験（DevRel）を提供する。

【Core SSoT】Extreme Observability & SLO Manifesto（超観測性・SLO絶対定義書）

⚠️ THE GENERATIVE SSoT: ZERO-DOWNTIME OBSESSION & AIOps 本ドキュメントは、士業やユーザーからの「技術的信用」を絶対的に担保するため、Rustアプリケーションの超観測性と、AIによる自己修復（Zero Marginal Cost AIOps）の運用ルールを定義する。

1. サービスレベル目標 (SLO: Service Level Objective)

「もしものはなし」B2BダッシュボードおよびコアAPIに対する、いかなる言い訳も通用しない厳格なSLO。

  • 可用性 (Availability): 99.99% (月間ダウンタイム 4.38分以内)
  • レイテンシ (Latency): 99%のAPIリクエストが 100ms 以内に応答すること（※意図的に遅延させるAI推論やサードパーティ通信を除く）
  • エラー率 (Error Rate): HTTP 5xx エラーが全リクエストの 0.05% 未満であること

2. 超観測性 (Extreme Observability) アーキテクチャ

Rustのゼロコスト抽象化の特性を活かし、極めて低負荷で高解像度なテレメトリをシステム全体から搾り取る。

  • tracing クレートによる細胞レベルの可視化:
    • Rustバックエンド内の全HTTPリクエスト、関数呼び出し、DBクエリ、SSS暗号化ステップを tracing によって構造化ログおよびスパン（Span）として記録する。
  • OpenTelemetry の絶対統合:
    • 収集したテレメトリデータを OpenTelemetry Protocol (OTLP) 経由で Datadog, Honeycomb, または Grafana (Loki/Tempo) へストリーミング送信。
    • 「ユーザーがフロントエンドのボタンをクリックした瞬間」から「Rustでの暗号化処理」「PostgreSQLへのクエリ実行」に至るまでの**完全な分散トレース（Distributed Tracing）**を実現し、パフォーマンスのボトルネックやエラー原因を数秒で特定可能にする。

3. Zero Marginal Cost AIOps とエラーバジェットの強制

人間の運用エンジニアが深夜に叩き起こされるレガシーな運用を完全に排斥する。

  • AIドリブン自動修復（Auto-Healing）:
    • SentryやDatadogのクリティカルアラートをWebhookで受け取り、n8n.ok.st (中枢神経系) がインフラ（AWS/GCP/Alibaba）の再起動やリソース拡張、あるいはDBフェイルオーバーを人手を介さずに自動で実行する。
  • エラーバジェットの絶対ルール:
    • 月間のSLOバジェット（許容ダウンタイム4分）を使い果たした場合、新機能の開発をいかなる理由があろうとも即座に凍結する。
    • バジェットが回復するまで、全エンジニアリソースを「信頼性向上（技術的負債の返済）」のタスクのみに強制アサインするというビジネスルールを、例外なく適用する。

【Core SSoT】Pro/Craftsman Implementation Grimoire（プロフェッショナル/職人向け 究極実装魔導書）

⚠️ THE GENERATIVE SSoT: STRICTLY FOR SYSTEM ARCHITECTS & CRAFTSMEN 本ドキュメントは、非エンジニア（ビジネスサイド）向けの抽象論を一切排除し、加藤CTOをはじめとするオープンナレッジの「狂気的な技術職人」のみに向けて書かれた、細胞レベルの実装手順書（Grimoire）である。妥協・例外・甘えは一切許容されない。

1. Rust-Core ⇔ WASM (React) ⇔ FFI (Flutter) 間の完全型同期 (TypeShare Pipeline)

フロントエンドエンジニアが手動でAPIの型（TypeScript）を書くことは「罪」である。すべての型定義の源泉（SSoT）はRustの構造体でなければならない。

1.1 実装指令

  1. Rust構造体の定義: projects/moshimo-no-hanashi/core/moshimo_core/src/models/ にドメインモデルを定義。 
    #![allow(unused)]
fn main() {
use typeshare::typeshare;
use serde::{Serialize, Deserialize};

#[typeshare]
#[derive(Serialize, Deserialize)]
pub struct SeniorAsset {
    pub asset_id: uuid::Uuid,
    pub encrypted_payload: String, // SSS暗号化済みBLOB
    pub is_locked: bool,
}
}
  2. DevSecOpsコンパイラの駆動: コミットフック（lefthook）内で typeshare を強制起動し、apps/b2b_dashboard/src/types/generated.ts にTSのInterfaceを自動吐き出しさせる。型が一致しなければコミット自体をHard-Failさせる。

2. PostgreSQL Row-Level Security (RLS) によるデータ隔離の物理的強制

「士業（Professional）」と「顧客（Senior）」、「業者（Alliance）」が同一のテーブル（例: assets テーブル）を参照するB2B2Cモデルにおいて、アプリケーション側のWHERE句（where user_id = ?）でアクセス制御を行うことは脆弱性の温床である。データベースレベルで物理的に遮断する。

2.1 実装指令

  1. Supabase / PostgreSQLのRLS強制有効化: 
    ALTER TABLE assets ENABLE ROW LEVEL SECURITY;
  2. Jwt Claimsのバインディング: Rust (Axum) のミドルウェアでJWTをパージし、PostgreSQLのセッション変数（request.jwt.claims）に role と tenant_id をセットする。
  3. 無慈悲なポリシー定義: 
    -- 顧客本人は自分のデータのみアクセス可能
CREATE POLICY "Senior can view own assets"
  ON assets FOR SELECT TO authenticated
  USING (auth.uid() = owner_id);

-- 士業は「委任契約（delegation）」が成立している顧客のデータのみアクセス可能
CREATE POLICY "Professional can view delegated assets"
  ON assets FOR SELECT TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM delegations
      WHERE delegations.professional_id = auth.uid()
      AND delegations.senior_id = assets.owner_id
      AND delegations.status = 'active'
    )
  );

3. Shamir’s Secret Sharing (SSS) のEdge(WASM)実装

最大のトラスト（我々運営すらデータを見られない）を担保するため、暗号化・復号化の処理は「サーバー（Rust API）に送信する前」つまり、クライアントのブラウザ上（Astro/React内で動作するWASM）で完結しなければならない。

3.1 実装指令

  1. 純粋Rust（no_std 互換推奨）でのSSS実装: shamir-secret-sharing クレート（または独自実装）を用い、シニアが入力したデータをJSON文字列化し、AES-GCM-SIV等で暗号化。その「AESの鍵」をSSSで N=5 に分割する。
  2. WASMへのコンパイルとバインディング: wasm-bindgen を用いて、TS側から以下のインターフェースで呼び出せるようにする。 
    // TS側からの呼び出しイメージ
import { encrypt_and_split } from "moshimo_core_wasm";

// 生のJSONデータを渡し、5つのキーシェアと暗号化BLOBを受け取る
const { encrypted_blob, key_shares } = encrypt_and_split(JSON.stringify(assetData), 5, 3);
  3. キーの分散保管ロジック:
    • Share 1 & 2: シニアのデバイス（WebAuthn / パスキーのSecure Enclave）
    • Share 3: 担当する士業のデバイス
    • Share 4 & 5: オープンナレッジのデータベース（PostgreSQL） ※ オープンナレッジ単体では 2つしかキーを持たないため、K=3の条件を満たせず、数学的に絶対復号不可能。

4. Whisper AI ✕ LLM Structured Output による「摩擦ゼロ構造化」

シニアの曖昧な音声を、Rustがパース可能な厳格なJSON構造体へと変換する「不可逆なパイプライン」。

4.1 実装指令

  1. 音声ストリーミング受領: フロントエンド（MediaRecorder API）からRust (Axum) 宛に音声をチャンクでWebSocketまたはHTTP/3ストリーミングで送信。
  2. WhisperによるSTT: OpenAI Whisper API（またはローカルRust推論）でテキスト化。
  3. GPT-4o / Claude 3.5 Sonnet による JSON Schema 強制 (Structured Outputs): LLMに対し、あらかじめ定義したRustの構造体から生成した JSON Schema (TypeShare で生成可能) をプロンプトとして渡し、「このスキーマに一文字の狂いもなく合致するJSONのみを返せ」と強制する。ハルシネーションを型レベルでブロックする。

5. 契約・財務・請求 (Business)

title: “もしものはなし 契約・レベニューシェア仕様書 (SSoT)” description: “Yrzu41合同会社様との共同事業における、客観的データに基づいた契約・請求仕様と、freeeAPI連携による自動分配アーキテクチャの定義” domain: “business”

もしものはなし 契約・レベニューシェア仕様書 (SSoT)

THE GENERATIVE SSoT 本ドキュメントは、株式会社オープンナレッジとYrzu41合同会社間の「もしものはなし」共同事業における財務・契約の正確な情報源（SSoT）として機能します。 当社が導入しておりますfreee会計およびfreeeサイン APIを用いたシステム連携により、手作業によるミスを排除し、透明性の高い公正な業務執行を前提としております。

1. 財務分配モデル (The Revenue Share Architecture)

当プロジェクトでは、市場の標準的なデータと、オープンナレッジ側がインフラ構築・保守・サーバー代等の運用経費を全額負担する事業構造に基づき、以下の数値にて契約をご提案いたします。

A. 初期開発費用 (Initial Development Fee)

  • 金額: 5,000,000円（消費税10%別途: 税込5,500,000円）
  • 妥当性の根拠:
    • 一般的なB2B2Cプラットフォーム（決済機能、厳格なユーザー認証、複雑な事業者管理機能を含む）をゼロからフルスクラッチで開発する場合、開発費用の相場は1,000万円から数千万円に上ります。
    • 本システムは、極めて秘匿性の高いデジタル遺言や個人情報を扱うため、金融機関レベルの暗号化アーキテクチャ（SSS等）と堅牢なRustバックエンドを採用いたします。この要件において「500万円」という評価額は、初期MVPとしてパートナー様の負担を極力抑えた、市場標準に照らし合わせても非常に良心的な水準となっております。
  • 請求・支払条件:
    • freeeサインでの電子契約締結後、当社システムのfreee会計API連携により、インボイス制度に対応した請求書を自動発行いたします。
    • 支払期日: 請求書発行日より14日以内。
    • 振込手数料: 誠に恐縮ですが、Yrzu41合同会社様にてご負担をお願い申し上げます。

B. 継続レベニューシェア (Perpetual Revenue Share)

  • 分配率: 40% （オープンナレッジ取り分） / 60% （Yrzu41合同会社取り分）
  • 分配率の根拠:
    • SaaSやプラットフォームの共同事業において、開発側が開発費の一部を負担し、かつサーバー代・保守運用費の全額を負担するケースでのレベニューシェア相場は、一般的に30%〜50%とされております。
    • 当プロジェクトでは、AWS/Google Cloud等のクラウドインフラ費用、システムの保守運用費、および万が一の障害対応コストを、オープンナレッジが全額自己負担いたします。この運用負担には、システムの継続的な品質改善やアップデートに関する技術投資も含まれており、当社は妥協なくリソースを投下いたします。パートナー様に対する月額のシステム保守費用等の追加請求は一切発生いたしません。このリスク構造を鑑みますと、40%という分配率は双方にとって利益を最大化できる公正な基準であると確信しております。
  • 計算ベース:
    • **「決済手数料控除後の総売上高（Net Revenue）」**を計算の母数とさせていただきます。
    • 計算式: (エンドユーザーからのStripe決済総額 - Stripe決済手数料(約3.6%)) × 40%
  • 精算サイクルと自動化:
    • 月末締め、翌月15日までにStripe APIにて売上を集計いたします。
    • Webhooks連携により自動で配分額を計算し、freee会計API経由でYrzu41合同会社様宛にレベニューシェア請求書を自動送付いたします（翌月末払い）。

2. 契約における基本的な取り決め

2.1 著作権および知的財産権の帰属

  • 本システムを構成するソースコード（Rust, WebAssembly等）、データベーススキーマ、およびインフラ構成図の著作権は、株式会社オープンナレッジに帰属いたします。
  • Yrzu41合同会社様に対しては、本契約が継続している期間に限り、本システムの独占的利用権を許諾いたします。

2.2 瑕疵担保責任（契約不適合責任）とSLA

  • 無償対応範囲: システムの明らかなバグ（仕様書との不一致）につきましては、納品から1年間、無償で修正対応を行います。もちろん、運用保守スキーム内において継続的な品質改善に努めてまいります。
  • 免責事項: クラウドプロバイダー（Google Cloud等）の大規模な障害、Stripe等外部APIの仕様変更による停止、および宇宙葬アライアンス企業のサービス終了等、当社の制御が及ばない事象による機能不全につきましては、誠に恐れ入りますが免責とさせていただきます。

2.3 監査権 (Audit Rights)

  • 共同事業としての透明性を確保するため、Stripeの決済ダッシュボードに対するRead-Onlyアクセス権限を双方で共有し、売上状況を常に相互確認できる体制を構築いたします。

3. 宇宙葬（Space Burial）等 外部サービス提携に関する免責条項

  • 本システムは「SPACE NTK」や「Celestis」等と業務提携を行う想定ですが、ロケット打ち上げの失敗・延期、または国際情勢による輸送遅延に関して、本システムおよび株式会社オープンナレッジは補償の責任を負いかねます。この点につきましては、エンドユーザー様向けの同意書（生前契約）に必ず条項を組み込み、freeeサイン経由で同意を取得する仕様といたします。

共同事業・システム開発およびレベニューシェアに関する基本契約書

本契約書（以下「本契約」という）は、株式会社オープンナレッジ（以下「甲」という）とYrzu41合同会社（以下「乙」という）との間において、「もしものはなし」プロジェクト（以下「本プロジェクト」という）に関するシステム開発、保守運用、および共同事業における収益分配（レベニューシェア）に関する権利義務関係を明確にするため、以下の通り合意し締結する。

第1章 総則

第1条（目的）

本契約は、甲および乙が共同して、デジタル終活・死後事務委任を目的としたB2B2Cプラットフォーム「もしものはなし」（以下「本システム」という）を構築・運営し、相互の利益を最大化することを目的とする。

第2条（役割分担）

  1. 甲の役割は以下の通りとする。 (1) 本システムの要件定義、基本設計、詳細設計、実装、テスト、およびデプロイ（システム開発業務）。 (2) 本システム稼働のためのクラウドインフラ（AWS、Google Cloud等）の構築、維持管理、および利用料の全額負担。 (3) 本システムの運用、保守、障害対応、およびセキュリティアップデート。 (4) freee会計およびfreeeサインAPI連携による、請求・分配・契約管理の自動化基盤の構築と維持。 (5) 中小企業診断士およびITストラテジストの知見に基づく、データドリブンな事業戦略アドバイザリー、プライシング戦略の助言、および本システムの改善提案（テクニカル・コンサルティング業務）。
  2. 乙の役割は以下の通りとする。 (1) 本プロジェクトにおけるビジネスモデルの企画・検証。 (2) エンドユーザーに対するマーケティング、集客、およびカスタマーサクセス業務。 (3) 士業（弁護士、司法書士、行政書士等）およびアライアンス企業（SPACE NTK、Celestis等）との事業提携交渉および契約締結業務。

第2章 システム開発および初期費用

第3条（初期開発業務および対価）

  1. 甲は、乙に対し、本システムの初期MVP（Minimum Viable Product）開発を行い、これを納入する。
  2. 本システムの初期開発における仕様は、別途甲乙間で合意した要件定義書（GitHubリポジトリ等での電磁的記録を含む）に基づくものとする。
  3. 乙は、甲に対し、初期開発業務の対価（以下「初期開発費用」という）として、金5,000,000円（消費税別途10％：税込5,500,000円）を支払うものとする。
  4. B2B2C決済機能、高度なユーザー認証、シャミア秘密分散法（SSS）を用いた暗号化アーキテクチャ、およびRustバックエンド等の複雑性を伴う本システムの市場開発相場（1,000万円〜数千万円）を鑑み、本条第3項に定める初期開発費用は、甲が開発コストの一部を特別に負担・減免した評価額であることを甲乙双方は確認する。

第4条（支払条件）

  1. 甲は、本契約締結後速やかに、freee会計APIを通じてインボイス制度に適合した電子請求書を発行し、乙に対して初期開発費用を請求する。
  2. 乙は、前項の請求書の発行日の属する月の末日（金融機関休業日の場合は前営業日）までに、甲が指定する銀行口座に初期開発費用を振り込んで支払うものとする。なお、振込手数料は乙の負担とする。
  3. 乙が前項に定める期日までに初期開発費用の支払いを遅滞した場合、甲は入金が確認されるまでの間、本システムの開発業務を一時停止することができる。当該停止により生じたスケジュールの遅延について、甲は一切の責任を負わない。
  4. 乙が本条に基づく支払いを遅滞した場合、乙は甲に対し、支払期日の翌日から完済に至るまで、年14.6%（年365日日割計算）の割合による遅延損害金を支払うものとする。

第5条（納品および検収）

  1. 甲は、合意した開発スケジュールに基づき、本システムを稼働可能なサーバー環境（本番環境）にデプロイし、乙にシステムへのアクセス権限を付与することで納品とする。
  2. 乙は、納品後14日以内（以下「検収期間」という）に、本システムが要件を満たしているか検収を行う。
  3. 前項の検収は、別途合意した要件定義書に記載された機能要件を満たしているか否かのみを基準として行われるものとし、乙の主観的なデザインの好みや仕様外の要望を理由とする検収不合格は認められないものとする。
  4. 乙が検収期間内に書面（電子メール等を含む）による異議を申し立てなかった場合、または乙が本システムを本番利用（エンドユーザーへの提供等）に供した場合、その時点で検収は合格したものとみなす。

第3章 運用保守およびレベニューシェア

第6条（運用保守費用の負担）

  1. 本システムの稼働にあたり発生するサーバー費用、データベース利用料、ドメイン維持費、SSL証明書費用、およびシステムの通常保守・障害対応にかかる人的リソースの費用の一切は、原則として本契約継続期間中、甲が全額自己負担するものとする。乙に対して月額の固定保守費用の請求は行わない。
  2. 前項にかかわらず、事業環境の急激な変化等により、甲が負担するサーバーインフラ費用等の実費が、連続して3ヶ月間、甲が受領するレベニューシェア分配額を上回った場合、甲および乙はインフラ構成の見直し、機能制限、または費用負担のあり方について誠実に協議し、システム運用の中断または条件変更を行う権利を有するものとする。

第7条（レベニューシェアの定義および分配率）

  1. 本システムの運用を通じて得られる収益について、甲および乙は以下の分配率に基づきレベニューシェアを行う。 (1) 甲の分配率：40％ (2) 乙の分配率：60％
  2. 前項の分配の算定基礎となる「総売上高（Net Revenue）」は、エンドユーザーからStripe等の決済代行サービスを通じて支払われた決済総額から、当該決済代行サービス事業者へ支払う決済手数料（約3.6%）、ならびにエンドユーザーへの返金（Refund）およびチャージバック等による回収不能金を控除した後の金額を指すものとする。
  3. 甲が前条に基づく運用保守費用等の経費リスクを全額負担することを鑑み、本条に定める分配率（40%）が公正かつ正当な基準であることを甲乙双方は合意する。

第8条（収益分配の計算および支払手続）

  1. 本システムの収益分配は、毎月末日を締日とし、翌月15日までに前月分の総売上高および分配額を確定する。
  2. 売上の集計および計算は、Stripe APIおよび甲のシステムにおけるWebhooksフック等のプログラムにより自動化して行われるものとする。
  3. 甲は、確定した分配額（甲の取分：40%）に基づく請求書を、freee会計API経由で乙に対して自動発行・送付する。
  4. 乙は、当該請求書を受領した月の末日（金融機関休業日の場合は前営業日）までに、甲が指定する銀行口座に分配金を振り込んで支払うものとする。振込手数料は乙の負担とする。
  5. 乙の口座（Stripeアカウント等）に直接入金されず、甲の口座に入金される売上が存在する場合、甲は自己の取分（40%）を控除した残額（60%）を、乙が指定する銀行口座に翌月末日までに振り込むものとする。この場合の振込手数料は甲の負担とする。

第9条（監査権および透明性の確保）

甲および乙は、相互の信頼関係を維持し収益報告の正確性を担保するため、決済プラットフォーム（Stripe等）の決済ダッシュボードに対し、互いにRead-Only（閲覧専用）のアクセス権限を付与・共有することに合意する。

第4章 権利の帰属および責任

第10条（知的財産権の帰属）

  1. 本プロジェクトにおいて甲が開発・提供した本システムに関するソースコード、アーキテクチャ、データベーススキーマ、プログラムノウハウ、および汎用的な機能モジュールにかかる著作権（著作権法第27条および第28条の権利を含む）、特許権その他の知的財産権（以下「システム知財」という）は、すべて甲に100％帰属するものとする。
  2. 本プロジェクトのサービス名称（「もしものはなし」）、ロゴマーク、乙の実体験に基づくチェックリスト等の独自のコンテンツ、および本システムを通じて蓄積されたエンドユーザーの顧客データにかかる権利（以下「ビジネス知財」という）は、すべて乙に帰属するものとする。
  3. 甲は、乙に対し、本契約が有効に存続し、かつ乙が第8条に基づくレベニューシェアを遅滞なく支払っている期間に限り、乙のビジネス知財を運営する目的において、甲のシステム知財の独占的な利用を許諾する。

第11条（瑕疵担保責任／契約不適合責任）

  1. 本システムに仕様書との明らかな不一致または重大な不具合（契約不適合）が発見された場合、甲は、納品（検収完了日）から1年間に限り、無償でこれを修補する義務を負う。
  2. 前項にかかわらず、甲は第6条の運用保守の一環として、本契約継続期間中、本システムの継続的な品質維持、軽微な不具合の修正、および必要に応じたシステムの更新に努めるものとする。
  3. 本条第2項における「システムの更新」とは、既存機能の品質維持を目的とするものに限る。乙が要件定義書に記載のない新機能の開発、大幅なUI/UXの改修、または外部連携機能の追加等を要望する場合は、保守の範囲外とし、甲乙間で別途有償での開発契約、またはレベニューシェア分配率の見直しを協議するものとする。

第12条（免責事項）

甲は、以下の各号に定める事由により生じた本システムの停止、障害、またはデータ喪失等について、乙およびエンドユーザーに対して一切の損害賠償責任を負わないものとする。 (1) AWS、Google Cloud等のクラウドプロバイダーに起因する物理的・基盤的な大規模障害。 (2) Stripe、freee、その他本システムが連携する外部APIの仕様変更、提供終了、または障害。 (3) SPACE NTK、Celestis等、乙が提携する宇宙葬アライアンス企業または外部サービス事業者の役務提供の遅延、失敗（ロケット打ち上げの失敗・延期等）、またはサービス終了。 (4) 天災地変、戦争、暴動、労働争議、通信回線の事故、その他不可抗力によるもの。 2. いかなる理由による場合であっても、本契約に関連して甲が乙または第三者に対して負担する損害賠償責任の総額は、甲の故意または重過失による場合を除き、損害発生の直接の原因となった事由が生じた日の前日から起算して過去12ヶ月間に甲が本契約に基づき実際に受領したレベニューシェア分配額の総額、または第3条に定める初期開発費用のいずれか高い金額を上限とする。

第13条（外部サービス提携に関する特別免責）

  1. 本システムが、宇宙葬等の特定の外部サービスをエンドユーザーへ提供するための手配（API連携等）を行う場合であっても、甲および本システムは単なる情報伝達・プラットフォーム機能を提供するのみであり、役務そのものの履行に関する責任は当該外部サービス事業者が負うものとする。乙は、エンドユーザー向けの利用規約または同意書（生前契約等）において、本条の免責事項を明確に規定し、freeeサイン等を通じて必ず同意を取得しなければならない。
  2. 前項の定めに反し、乙が免責条項の規定または同意取得を怠ったことにより、エンドユーザーまたは第三者から甲に対してクレーム、損害賠償請求等の訴訟が提起された場合、乙は自己の責任と費用においてこれを解決し、甲に生じた一切の損害（合理的な弁護士費用を含む）を補償するものとする。

第5章 契約期間および解除

第14条（契約期間）

本契約の有効期間は、契約締結日から1年間とする。ただし、期間満了の1ヶ月前までに甲または乙のいずれからも書面（電子メールを含む）による契約終了の申し出がない場合は、さらに1年間自動的に更新されるものとし、以後も同様とする。

第15条（中途解約）

  1. 甲は、少なくとも3ヶ月前までに乙に対し書面で通知することにより、本契約を中途解約することができる。
  2. 乙は、本システムの初期開発において甲が大幅なコスト負担（投資）を行っていることを鑑み、本契約締結日から起算して満2年間（以下「ロックイン期間」という）は、原則として本契約を中途解約することができない。
  3. 前項にかかわらず、乙がロックイン期間中に自己の都合により本契約の中途解約を希望する場合、乙は甲に対し、初期開発費用の本来の市場価値との差額および甲の将来利益の喪失の補填として、違約金（買取代金）として金5,000,000円（税別）を一括で支払うことにより、即時に本契約を解約することができる。

第16条（契約解除）

甲または乙は、相手方に以下の各号のいずれかに該当する事由が生じた場合、何らの催告を要することなく直ちに本契約を解除することができる。 (1) 本契約の重大な条項に違反し、相当の期間を定めて催告したにもかかわらず是正されないとき。 (2) 破産手続、民事再生手続、会社更生手続、特別清算開始の申立てがあったとき、または自ら申し立てたとき。 (3) 支払停止もしくは支払不能に陥ったとき、または手形交換所の取引停止処分を受けたとき。 (4) 差押え、仮差押え、仮処分、競売の申立て、または公租公課の滞納処分を受けたとき。 (5) その他、本契約を継続し難い重大な背信行為があったとき。

第17条（契約終了後の措置）

  1. 本契約が期間満了、解約、解除その他の事由により終了した場合、乙に対する本システムの利用許諾（第10条第2項）は当然に消滅し、乙は本システムの利用を直ちに中止しなければならない。
  2. 契約終了時におけるエンドユーザーのデータ保護およびシステム移行に関する措置については、甲乙協議の上、別途定めるものとする。ただし、移行にかかる作業費用は原則として乙の負担とする。
  3. 本契約の終了事由の如何を問わず、甲は乙に対し、本システムのソースコード、アーキテクチャ詳細、およびサーバーの環境構築スクリプト等を開示、提供、または引き渡す義務を一切負わないものとする。

第18条（秘密保持）

甲および乙は、本契約に関連して相手方から開示された技術上、営業上、その他一切の機密情報を厳重に保持し、相手方の事前の書面による承諾なしに第三者に開示、漏洩し、または本プロジェクト以外の目的に使用してはならない。本条の義務は、本契約終了後も3年間存続するものとする。

第19条（反社会的勢力の排除）

  1. 甲および乙は、自らまたはその役員（実質的に経営を支配する者を含む）が、現在および将来において、暴力団、暴力団員、暴力団関係企業、総会屋、社会運動標榜ゴロ、政治活動標榜ゴロ、特殊知能暴力集団等、その他これらに準ずる者（以下、総称して「反社会的勢力」という）に該当しないこと、および反社会的勢力と不適切な関係を有していないことを表明し、保証する。
  2. 甲または乙は、相手方が前項の表明保証に違反した場合、何らの催告を要せず直ちに本契約を解除することができる。

第20条（準拠法および管轄裁判所）

本契約の成立、効力、履行および解釈については日本法を準拠法とし、本契約に関する一切の紛争については、東京地方裁判所を第一審の専属的合意管轄裁判所とする。

第21条（協議事項）

本契約に定めのない事項、または本契約の条項の解釈について疑義が生じた事項については、甲および乙は誠意をもって協議の上、解決するものとする。

以上、本契約の成立を証するため、本契約書（電磁的記録）を作成し、甲乙合意の上、freeeサイン等を用いた電子署名により締結する。

締結日：令和　年　月　日

【甲】 大阪府高槻市野見町２番２号 株式会社オープンナレッジ 代表取締役 加藤 明生 （法人番号：2120901032920）

【乙】 大阪府高槻市高槻町１番２３号ネオ常磐５０１ Ｙｒｚｕ４１合同会社 代表社員 平井 聡 （法人番号：7120903006141）

【Core SSoT】日本型・終活プラットフォーム「ステルス・モート」戦略

本ドキュメントは、「もしものはなし」が大手企業（イオンライフ、鎌倉新書など）に認知される前に、圧倒的かつ不可逆的な参入障壁（Moat）を構築するための**「ステルス・トロイの木馬戦略」**を定義する。宇宙葬などの特殊機能は、あくまでプラットフォーム上のワン・オブ・ゼム（多数ある選択肢の一つ）に過ぎない。

1. 現代日本の「終活」ペインと大企業の構造的弱点

日本の終活市場は、核家族化、孤独死の増加、デジタル資産のブラックボックス化、墓じまい等、極めて現代的かつ深刻な課題に直面している。 しかし、既存の大手企業はこの課題に対して「本当にユーザーに寄り添った解決策」を提供できない。なぜなら、彼らのビジネスモデルが「自社の高額な葬儀枠への誘導」や「士業・業者からの高額な送客手数料（リード販売）の搾取」に依存しているからである。

我々はこの**「大企業の利益相反構造」**そのものを弱点として突き、フリーミアムとRust至上主義を武器に、ステルスで市場のど真ん中を制圧する。

2. ステルス・モート戦略（トロイの木馬）

大企業が「莫大な広告費でC（一般消費者）を集めようとしている」間に、我々は**「B（士業：弁護士・司法書士・行政書士）」をハブとしたトロイの木馬戦略**を展開する。

2.1 B2B SaaSの無償（または低価格）提供による「士業の囲い込み」

地方の士業は、大手ポータルサイトによる「高額な送客手数料」に疲弊している。我々は彼らを搾取するのではなく、彼らの業務効率を劇的に向上させる**「顧客・信託管理SaaS（B2B Hub）」**を提供する。 士業は自身の既存の優良顧客（シニア層）を、自らの手で「もしものはなし」プラットフォームへと招待（オンボーディング）する。我々は広告費ゼロで質の高いC（一般消費者）を獲得できる。

2.2 フリーミアムによる「圧倒的UX」の提供（B2C）

エンドユーザー（C）に対しては、無料で使える「AIヒアリング型・デジタル終活ノート」を提供する。面倒な入力作業は不要。シニアが対話型AIと「昔話」をするだけで、裏側で自動的に家系図、財産目録、デジタル遺品リストが生成される（AIの狂気的搾取）。 大手企業には、自社のマネタイズを遅らせてまで、このような圧倒的なフリーミアム・インフラを作る体力も柔軟性もない。

3. RUST至上主義 × SSS（秘密分散）による「究極のトラスト」

シニア層がITプラットフォームを敬遠する最大の理由は、「自分の銀行口座や財産情報を、運営会社（IT企業）に見られるのが怖い」というPsychological Barrier（心理的障壁）である。

我々はこれを、**Rust言語とシャミア秘密分散法（SSS: Shamir’s Secret Sharing）によって技術的・数学的に粉砕する。 「運営会社である株式会社オープンナレッジでさえ、あなたのデータの中身を復号して見ることは物理的に不可能です。暗号を解けるのは、あなたが死んだ後に、あらかじめ指定した士業や家族のうち『3人中2人』がパスキーを持ち寄った時だけです」 この「運営も見れない（Zero-Knowledge Proof的アプローチ）」**という事実こそが、大企業の「規約で守ります」という口約束を凌駕する絶対的なトラスト（信頼）となり、最大の参入障壁となる。

4. 収益モデル（マネタイズ・ポイント）

我々はフロントエンド（エンディングノート入力等）では一切課金せず、以下のタイミングで収益を確保する。

  1. 士業への送客・マッチング手数料: AIがシニアの財産状況を分析し、「相続税対策」や「遺言書作成」が必要と判断したタイミングで、プラットフォーム内の最適な士業（B）をレコメンドする。成約時に手数料（またはシステム利用マージン）を徴収する。
  2. 死後事務の手数料: ユーザーの死後、プラットフォームから自動的に死後事務（遺品整理、デジタル遺品消去、墓じまい、特殊な手配としての宇宙葬など）が外部業者へディレクションされる。この受発注のハブ機能としてトランザクション・マージンを徴収する。

5. 結論

大企業が「葬儀のネット販売」に固執している間に、我々は**「Rust×SSSによる絶対的セキュリティ」と「AIによる超効率的ヒアリング」**を実装したプラットフォームを士業経由でステルスに普及させる。大企業が我々の存在に気づき、ビジネスモデルを転換しようとした時には、すでに全国の士業と優良シニア層のトラスト（信頼とデータ）は「もしものはなし」の強固なRustインフラ内にロックインされており、手出し不可能な状態（Checkmate）となっている。これが、我々の追求する超現実主義・技術的競争優位の真髄である。

【Core SSoT】「もしものはなし」 プロダクト・ロードマップ＆機能マトリクス

本ドキュメントは、「もしものはなし」プロジェクトにおける、本日のMVP（プロトタイプ）から長期的な将来像に至るまでの全機能開発ロードマップを徹底的にリストアップ・詳細化したものである。 「超効率主義」「AIの狂気的搾取」の原則に従い、本日の時点でプロトタイプはほぼ完成の域に達している。

1. MVPで実装する機能（本日お見せするプロトタイプ／ほぼ完成済）

【ステータス：実装完了・デモ可能】 営業（テストマーケティング）の最強の武器として、大企業のUIを凌駕するフロントエンド体験を最速で構築済み。

  • B2C向け（シニア層）
    • AI対話型フロントエンド（Web / iPadアプリ両対応）: フォーム入力を完全に排し、マイクボタン一つでAIと昔話ができるUI。
    • リアルタイム・データ抽出モック: 会話内容から「家系図（推定相続人）」や「財産目録」が自動で構造化されるアニメーション処理。
  • B2B向け（士業層）
    • 顧客管理ダッシュボードUI（Web / iPadアプリ両対応）: ダークモード基調のSaaS画面。
    • 暗号化・トラスト可視化モック: SSS（シャミア秘密分散法）による「Locked (キー分散状態)」と「Decrypted (復号化状態)」の視覚的表現。
    • 顧客ステータス一覧: 「AIヒアリング進捗」「生存確認状況」の可視化。

2. リリース時機能（初期ローンチ / Day-1）

【ステータス：次期開発フェーズ（Rustバックエンド結合）】 実際に士業が顧客を招待し、セキュアにデータを預かることができる「トラストハブ」としてのミニマム・インフラ。

  • B2C向け
    • 本番AI（LLM）結合: 実際のOpenAI API等を用いた、高度な対話とプロンプトエンジニアリングによる正確な遺産情報の抽出。
    • クライアントサイドSSS暗号化: ブラウザ（WASM）内でデータをSSSで暗号化し、運営（サーバー）には暗号化済みのデータと分割キーの一部しか送信しないゼロ知識証明の実装。
  • B2B向け
    • 招待URL・QRコード発行: 士業が自身の顧客をプラットフォームへ安全に誘導する機能。
    • Stripe B2B決済連携: 士業からの月額SaaS利用料、またはマッチング時の決済処理の自動化。
  • インフラ・基盤
    • Rust (Axum) バックエンド API & PostgreSQL データベースの商用環境デプロイ（AWS/GCP）。

3. 直近で実装する機能（ローンチ後 3ヶ月以内）

【ステータス：グロース＆定着フェーズ】 シニア層のエンゲージメント向上と、士業の業務をさらに巻き取る機能。

  • B2C向け
    • LINE連携（LIFFアプリ化）: Webブラウザだけでなく、シニアが最も使い慣れたLINEアプリ上からそのままAIと対話・生存確認ができる機能。
    • 生存確認（死活監視）アラート: 一定期間アクセスがない、またはLINEの応答がない場合に、段階的に家族や士業へアラートを飛ばす機能。
  • B2B向け
    • freeeサインAPI連携: 抽出された財産目録を元に、「死後事務委任契約書」や「任意後見契約書」等の法的なPDFを自動生成し、電子署名までプラットフォーム内で完結させる機能。

4. 年末までに実装する機能（2026年12月目処）

【ステータス：収益最大化フェーズ】 B2B2Cのトラストハブとして、プラットフォーム内での受発注とトランザクション収益を爆発させる。

  • 最適士業 AIマッチング機能: C（一般消費者）が入力した情報をAIが分析し、「この方は相続税対策が必要」と判断した場合に、プラットフォーム内の最適なB（士業）をレコメンドする機能。
  • 死後事務・自動発注API（V1）: ユーザーの死亡（および指定人数のキーによる復号）をトリガーとして、遺品整理業者等への「タスク自動アサイン・発注通知」を行うシステム。

5. 1年以内に実装する機能（2027年夏目処）

【ステータス：エコシステム制圧フェーズ】 士業だけでなく、外部の「特殊サービス業者」をエコシステムに組み込む。

  • アライアンス向け Open API（特殊手配）: 宇宙葬（SPACE NTK）や海洋散骨などの特殊な死後事務を提供する業者が、本プラットフォームから直接受注・決済を受け取れるAPIゲートウェイの公開。
  • デジタル遺品・自動消去連携: ユーザーの死後、生前に連携しておいたGoogleアカウントやSNSアカウントの「自動削除リクエスト」または「追悼アカウント化」を、APIを通じて自動実行する機能。

6. 長期的な将来に実装する機能（2028年以降）

【ステータス：グローバル・インフラ化】

  • グローバル終活ハブ（多言語・多法域対応）: 日本の法制・慣習（トロイの木馬戦略）で確立したモデルを、同様の高齢化・核家族化課題を抱える東アジア・欧米圏へ展開。
  • ブロックチェーン・スマートコントラクト連携: SSS暗号化に加え、死後事務の執行確約と遺産（暗号資産等含む）の分配を、イーサリアム等のスマートコントラクトで100%自律的かつ不可逆的に執行する究極のトラスト・プロトコル化。

【Core SSoT】IP Defense & Tech-Blackbox Strategy（知財防御・ブラックボックス化絶対戦略書）

⚠️ THE GENERATIVE SSoT: UNFAIR ADVANTAGE & DEFENSE 本ドキュメントは、「もしものはなし」の技術的優位性を法（特許）と構造（秘匿）の両面から守り、大企業や競合他社が絶対に模倣できない「難攻不落の防壁（Moat）」を構築するための戦略を定義する。

1. 知財戦略の3層境界モデル (Open / Patent / Blackbox)

システム全体を以下の3層に明確に分類し、オープンとクローズの境界線を細胞レベルで定義する。

  1. Open (完全オープン領域 - API, SDK, UI層):
    • 対象: OpenAPI仕様、フロントエンド（React/Flutter）の表示用コンポーネント、サードパーティ連携用SDK。
    • 目的: 外部開発者やアライアンス企業（葬儀社・生保）が極めて低い学習コストで連携できるよう徹底的に公開し、プラットフォームのネットワーク効果とデータグラビティを加速させる。
  2. Patent (特許出願領域 - ビジネスモデル, UI/UXの連動):
    • 対象: 「AIを用いた自動財産抽出と士業ダッシュボードへのセキュア連携モデル」「SSS（秘密分散）とスマートコントラクトを組み合わせた死後事務執行プロセス」。
    • 目的: 資金力のある大企業が同一のビジネスモデルで強引に参入することを牽制するための「法的防壁（Legal Moat）」。
  3. Blackbox (ブラックボックス領域 / 絶対秘匿 - コアアルゴリズム):
    • 対象: SSS暗号化のキー分割・復元アルゴリズムの独自実装部分、AIプロンプトエンジニアリングのシステムプロンプト（The Grimoire）、データクレンジング・パイプラインの詳細。
    • 目的: 特許として公開することすらリスクと見なす。ソースコード上で完全に秘匿（Trade Secret）とし、競合に中身のアルゴリズムを一切推測させない。

2. リバースエンジニアリングへの絶対的耐性（WASM & Native）

オープンナレッジの知財（Rust Core）をクライアント環境（ブラウザ/スマホ）に配布する際の、技術的防御策。

  • WASM（Web）の極限難読化: RustコードからWASMをコンパイルする際、単なるビルドではなく wasm-opt -O3 による極限の最適化と、デバッグシンボル・関数名の完全削除（strip = true）を強制する。これにより、ブラウザのDevToolsでWASMを解析されても、元の暗号化ロジックの解読を数学的・物理的に極めて困難にする。
  • Native（Flutter）の強固な保護: Flutterアプリ内のDartコードおよびRust FFIバイナリに対して、本番ビルド時の高度な難読化（Obfuscationコマンドフラグの必須化）を適用し、APK/IPAファイルの逆コンパイルによる知的財産（IP）の抽出リスクを封殺する。

3. Need-to-Knowの原則とコードアクセス分離

内部犯行やヒューマンエラーによる漏洩を防ぐ、冷徹なアクセス制御ルール。

  • リポジトリアクセスの厳格な分離: 株式会社オープンナレッジ内および外部委託メンバーであっても、「Blackbox領域（Rust Coreの暗号化ロジック等）」を含む ok-sys の深層ディレクトリへのアクセス権限は、加藤CTOおよび極限られたコアメンバー（AIエージェント含む）のみに制限する。
  • バイナリ配布によるカプセル化: フロントエンドエンジニアやUIデザイナーには、コアロジックをコンパイル済みのWASMバイナリ、または動的モックAPIとして提供する。これにより、「UIを作るために暗号化ロジックのソースコードを読む必要がある」という状態を構造的に防ぎ、内部アルゴリズムの漏洩を完全に遮断する。

【Core SSoT】Ultimate Business Moat & Customer Journey（ビジネス競争優位性と究極の顧客体験 絶対設計書）

⚠️ THE GENERATIVE SSoT: BUSINESS ARCHITECTURE & UNFAIR ADVANTAGE 本ドキュメントは、「もしものはなし」が単なる終活アプリや宇宙葬のプラットフォームにとどまらず、**「超高齢化社会における最大のトラスト・インフラストラクチャ」**として市場を独占するためのビジネスルール、競争優位性、および顧客体験のすべてを細胞レベルで解剖・定義する。

1. ビジネス視点（The Ultimate Business Perspective）

1.1 「点」のビジネスから「面」のプラットフォームへの進化

従来の終活・葬儀ビジネスは、ユーザーが亡くなったタイミングでのみ収益が発生する「点のビジネス（狩猟型）」であった。 「もしものはなし」はこれを完全に破壊し、**B2B2Cトラストハブとして「面のビジネス（農耕型・継続型）」**へと転換する。

  • B2B（士業）からの定額収益（SaaS Subscription）: 弁護士、司法書士、税理士に対し、既存の紙やExcelによる顧客管理を代替するセキュアなSaaSダッシュボードを提供し、安定した月額収益（MRR）を獲得する。
  • B2C-B2B2B マッチング手数料（Transaction Fee）: シニア（B2C）の財産情報と死後の希望（宇宙葬、遺品整理、ペット信託など）を、最適な専門家や業者にAIが自動マッチングし、成約時の高額な手数料（テイクレート）を自動徴収する。

1.2 ゼロ・カスタマー・アクイジション・コスト（CAC=0）戦略

オープンナレッジ（プラットフォーム側）が自ら多額の広告費を投じてシニアを集客する（B2Cマーケティング）ことはしない。 **「SaaSを導入した士業（B2B）が、自身の既存顧客（シニア）に対して『より安全で便利なシステム』として自発的に招待する」**構造を作る。これにより、プラットフォーム側のシニア獲得単価（CAC）を物理的にゼロにする。

2. ビジネス的競争優位性（The Ultimate Moat / 経済的堀）

大企業（既存の信託銀行や大手IT企業）が巨額の資本を投じても絶対に模倣・追従できない3つの防壁（Moat）。

  1. データ引力とAI自己学習による「スイッチングコストの無限大化」 (Network Effects Moat)
    • 士業が本プラットフォームで遺産分割協議書や遺言の下書きを生成すればするほど、AIがその士業「特有の言い回しや法的解釈」を学習する。他社ツールへ乗り換えると「AIがゼロから学習し直し」になるため、一度定着した士業は二度と離脱できない。
  2. 「運営すら見られない」というゼロ知識証明 (Cryptographic Trust Moat)
    • Rust-Coreで実装されたSSS（シャミア秘密分散法）により、ユーザーの財産データはプラットフォーム運営会社（オープンナレッジ）であっても復号不可能である。大企業の「個人情報を活用します」という規約への不信感を逆手に取り、「我々すら見られないからこそ、世界一安全である」という絶対的な信頼（トラスト）を構築する。
  3. フリクション・ゼロのUI/UX (UX Moat)
    • シニアに対して「タイピング」や「パスワード設定」を一切要求しない。LINE連携とWhisper AI（音声認識）によって「話すだけで終わる」体験を提供し、ITリテラシーの壁を完全に破壊する。

3. ユーザーストーリー（Actors & Core Value）

本システムには3つの明確なアクターが存在し、それぞれの「痛み（Pain）」を極限まで解消する。

👤 Actor 1: The Senior (知識提供者・資産保有者 / B2C)

  • Pain: 「エンディングノートを買ったが、手が痛くて書けない」「誰に何を伝えていいか分からない」「自分の死後、子供たちが争わないか不安」
  • User Story: 私はシニアとして、キーボードを一切使わず、日常会話のようにAIに昔話をするだけで、自動的に美しい家系図と法的効力を持った財産目録が完成し、自分の死後確実に家族へ想いが伝わる安心感を得たい。

👔 Actor 2: The Professional (士業・信託管理者 / B2B)

  • Pain: 「認知症が進んだ顧客の財産把握が困難」「エクセルでの顧客管理が限界」「セキュリティ要件が厳しく、クラウド化に踏み切れない」
  • User Story: 私は士業として、ミリタリーグレード（SSS）のセキュリティで守られたSaaSダッシュボードを用い、顧客の資産状況をリアルタイムに把握し、AIの力で法務ドキュメント作成の工数を1/10に圧縮し、より多くの富裕層顧客を抱えたい。

🏢 Actor 3: The Alliance Provider (死後事務・宇宙葬等の実行業者 / B2B)

  • Pain: 「見込み客の獲得（マーケティング）に莫大なコストがかかる」「生前契約が途中で破棄されるリスク」
  • User Story: 私はサービス提供業者として、「もしものはなし」のプラットフォームから、**確実に死後事務のニーズが確定した顧客（API連携による自動発注）**を受け取り、広告費ゼロで安定した売上を獲得したい。

4. 究極のカスタマージャーニーとシナリオ (The Absolute Journey)

「シニアがプラットフォームに触れてから、死後の事務が完了するまで」の完全なシナリオ。

Phase 1: 摩擦ゼロのオンボーディングと「魔法」の体験

  1. 招待: 士業（弁護士）からシニアのLINE宛に「安全な資産管理システムのご案内」リンクが届く。
  2. 認証: シニアがリンクをタップ（LIFF起動）。パスワード設定なし、1秒で認証完了。
  3. The Aha! Moment: 画面のAIキャラクターが「〇〇さん、はじめまして。最近の楽しかった思い出を教えてください」と話しかける。シニアがマイクに向かって話すだけで、画面上で瞬時に家系図と財産リストが組み上がっていくアニメーションが展開される。

Phase 2: データグラビティとトラストのロックイン

  1. 確認とロック: AIが整理した「遺産の分け方」や「宇宙葬の希望」をシニアが承認する。
  2. SSS暗号化: 承認された瞬間にRust Coreがデータを暗号化。シニアのスマホ（パスキー）、士業のデバイス、サーバーにキーが分散（N=5, K=3）して保管される。
  3. 士業の業務圧縮: 士業側のダッシュボードには、AIによって「完璧に構造化された財産目録」が届く。士業は1クリックで正式な法的ドキュメントを出力し、公証役場へ提出する手配を完了する。

Phase 3: 死後事務の自動執行（The Smart Contract Execution）

  1. 死亡検知: 数年後、士業または家族の申告（将来的には行政API等との連動）により、シニアの死亡がプラットフォームに確定登録される。
  2. 分散キーの統合: 規定されたポリシー（K=3の条件）が満たされ、暗号化されていた「死後事務の希望データ」がロック解除される。
  3. 自動発注と決済 (API Gateway): 提携業者（宇宙葬サービス等）のAPIに対し、即座に発注リクエストが送信される。同時に、Stripe/スマートコントラクトを介して信託口座から業者の口座へ資金が自動送金される。

5. 絶対的なビジネスルール (Strict Business Rules)

システムを崩壊させないための、冷徹かつ厳格なルール。

  1. Rule of Data Sovereignty (データ主権のルール):
    • 財産データの最終的な所有権は「シニア（B2C）」にある。士業であっても、シニアの同意（キーの提供）がなければ勝手にデータを書き換えることはできない。
  2. Rule of Zero Recovery (復元不可のルール):
    • もし必要なキー（K=3）が物理的・論理的に完全紛失した場合、データは二度と復元できない。オープンナレッジ社は「データベースの管理者」であっても「復元者」にはなれない。これを免責事項のトップに明記し、逆に「それほど安全である」というブランド価値に昇華する。
  3. Rule of Monetization (収益徴収のルール):
    • プラットフォーム内で行われたマッチングおよび決済において、手数料（テイクレート）はStripe Connect等を通じて**「資金の流れの中で自動的に中抜き（Split）」**される。請求書ベースのレガシーな回収作業は一切行わない。
  4. Rule of Feature Freeze on SLO Violation (SLO違反時の新機能凍結ルール):
    • 士業の業務を止めることはプラットフォームの死を意味する。月間の許容ダウンタイム（99.99% = 約4分）を超過した場合、全エンジニアリソースを新機能開発から止め、信頼性向上に強制アサインする。

【Core SSoT】Ultimate Shukatsu & Post-Mortem Checklist（究極の終活・死後事務 実務チェックリスト）

⚠️ THE GENERATIVE SSoT: MASTER CHECKLIST MATRIX 本ドキュメントは、「もしものはなし」プラットフォームを駆動する中核データ（実務ノウハウ）である。シニア（B2C）、士業（B2B）、および実働業者（B2B）間をAIがシームレスに連携させるための、**「漏れが許されない絶対的なタスクマトリクス」**を定義する。

🧭 フェーズ1：現状把握と意思決定（AIヒアリング・フェーズ）

シニアがシステム（LINE等）に音声入力を行い、プラットフォーム上に「現在の状況」と「死後の希望」を構造化データとしてマッピングする段階。

1.1 基本情報と連絡先の整理

  • 緊急連絡先の指定：自身に万が一のことがあった場合、第一に連絡すべき人物のリスト化。
  • 訃報の連絡先リスト：亡くなった際に知らせてほしい親族、友人、関係者のリスト作成。
  • 知らせてほしくない人の指定：トラブル防止のため、あえて連絡しない人物の指定。

1.2 資産・負債（プラスとマイナス）の完全マッピング

  • 預貯金口座のリストアップ：銀行名、支店名、口座番号、Webログイン情報の整理。
  • 証券・金融商品のリストアップ：証券会社、保有株式、投資信託、暗号資産のウォレット情報。
  • 不動産のリストアップ：自宅、投資用物件、山林や農地などの権利証の所在。
  • 負債（マイナス財産）の整理：住宅ローン、カードローン、個人間の借入金、連帯保証人の有無。
  • 貸金庫の有無：貸金庫の場所と、開錠に必要なカード・鍵の所在。

1.3 医療・介護に関する意思表示（ACP：人生会議）

  • 延命治療の希望：尊厳死の宣言書（リビングウィル）の作成要否。
  • 臓器提供・献体の意思：ドナーカードの有無、献体登録の有無。
  • かかりつけ医・服用薬の記録：持病、アレルギー、現在の担当医の情報。
  • 介護施設の希望：認知症になった場合に入居したい施設や、予算の希望。

1.4 デジタル遺品とサブスクリプションの棚卸し

  • スマートフォン・PCのパスワード：デバイスのロック解除手段の記録（または物理的な破棄の希望）。
  • SNS・メールアカウント：X(旧Twitter)、Instagram、Facebook等の追悼アカウント化、または即時削除の希望。
  • サブスクリプションの解約リスト：Netflix、Amazon Prime、月額制アプリ等のリスト。

🛡️ フェーズ2：法的防御と契約の組成（士業ダッシュボード・フェーズ）

フェーズ1で収集したデータを元に、士業がダッシュボード上で「法的拘束力のある契約」へと昇華させる段階。

2.1 財産の承継（遺言書の作成）

  • 公正証書遺言の作成：自筆証書ではなく、極限までリスクを排除した公正証書遺言のドラフト作成（AI生成）。
  • 遺言執行者の指定：プラットフォーム上の士業、または信頼できる第三者の指定。
  • 遺留分の配慮：相続トラブルを防ぐため、法定相続人の遺留分を侵害しないかAIによる自動チェック。

2.2 生前のサポート契約

  • 見守り契約の締結：定期的な電話や訪問による安否確認（アプリのログイン履歴等を用いた自動見守り）。
  • 財産管理委任契約の締結：身体が不自由になった際、銀行での引き出しや支払い代行を士業へ委任。
  • 任意後見契約の締結：認知症等で判断能力を喪失した際に備えた、公的な後見人の事前指定。

2.3 死後の事務手続き（死後事務委任契約の締結）

  • 死後事務委任契約書の作成：遺言ではカバーできない「死後の手続き」に関する委任状の作成。
  • 解除制限特約の付与：相続人が勝手に死後事務契約を解除し、宇宙葬等の本人の希望を握りつぶすことを防ぐ特約の記述。
  • 預託金の決済ロック：死後事務にかかる費用（葬儀代、報酬など）をStripe/信託口座等で事前にロック・エスクロー化。

🚀 フェーズ3：死後事務発動・即時対応（API・スマートコントラクト発動）

シニアの死亡がシステム上で確定登録（ロック解除）された直後に、自動的に実行される初動タスク。

3.1 遺体・葬儀・埋葬の手配（アライアンス業者への自動発注）

  • 遺体の引き取り・搬送：病院や警察からの遺体引き取り手配。
  • 葬儀・火葬の手配：生前の希望（直葬、家族葬、宇宙葬等）に基づく、葬儀社へのAPI自動発注。
  • 納骨・散骨の手配：永代供養墓への納骨、海洋散骨、宇宙葬の実行業者との連携。
  • ペットの引き渡し：ペット信託に基づき、事前に指定した新しい飼い主や保護団体への引き渡し手配。

3.2 関係機関への通知と行政手続き

  • 死亡届の提出：役所への死亡届および死体火葬許可証の交付申請。
  • 親族・関係者への死亡通知：システムから、リストアップされた関係者宛へ訃報の自動送信。
  • 年金受給停止の手続き：年金事務所等への死亡報告（不正受給防止）。
  • 介護保険証・健康保険証の返還：市区町村への資格喪失届と保険証の返納。

🧹 フェーズ4：解約・精算手続き（士業による事務遂行）

生活インフラや契約関係のクローズ作業。

4.1 住居・生活インフラの清算

  • 賃貸借契約の解約：アパート・マンションの大家・管理会社への解約通知。
  • 公共料金の停止・精算：電気、ガス、水道の停止および未払い分の精算。
  • 原状回復と敷金精算：賃貸物件の明渡し、修繕費用の精算。
  • 施設・病院の未払い金精算：入院費用や老人ホームの未払い費用の最終精算。

4.2 各種契約・ライセンスの返納

  • 運転免許証・パスポートの返納：警察署等への返納手続き。
  • クレジットカードの解約：カード会社への死亡連絡と解約。
  • 携帯電話・インターネット通信の解約：プロバイダへの解約連絡（デバイスの処分は後述）。

🗑️ フェーズ5：遺品整理・デジタル遺品消去

物理的・データ的な「生きた証」の整理と消去。

5.1 物理的な遺品整理

  • 遺品整理業者への発注：家財の処分、不用品の回収手配（API自動発注）。
  • 形見分けの発送：指定された人物へ、特定の遺品（時計、宝石、手紙など）を梱包・発送する手配。
  • 特殊清掃の手配：（孤独死等の場合）原状回復のための清掃業者の手配。

5.2 デジタル遺品の完全消去（データの火葬）

  • オンライン口座の閉鎖：証券、FX、暗号資産口座の残高移行およびアカウント削除。
  • SNSアカウントの削除・追悼化：希望に基づき、Facebook、X等の追悼アカウント化、またはアカウント自体のデリート申請。
  • ローカルデバイスの物理破壊・初期化：PCやスマートフォンのデータを専用ツールで完全消去、または物理的破壊。

💰 フェーズ6：最終承継と業務完了

すべての事務が完了し、最終的な資産移動が行われる最終フェーズ。

  • 相続財産の引き渡し：死後事務にかかった実費と士業の報酬を差し引いた残余財産を、遺言執行者（または相続人）へ引き渡す。
  • 業務完了報告書の作成：システムが実行履歴のログを収集し、自動的に死後事務完了報告書（PDF）を生成。
  • 報告書の交付とアカウントの永眠：相続人へ報告書を交付し、プラットフォーム上のシニアのアカウントステータスを「Deceased（永眠）」としてアーカイブ・ロックする。

2026/07/18 「もしものはなし」 キックオフ・システム戦略合意・契約締結ミーティング

開催概要

  • 日時: 2026年7月18日
  • 参加者: オープンナレッジ代表、Yrzu41合同会社代表
  • アジェンダ目的: 「死後事務支援士」ハブビジネスの完全なシステム化要件の合意、レベニューシェアの確定、UI/UXデモ（Leptosモック）の確認、およびその場での契約・請求・入金フローの完了。

アジェンダ

1. 【戦略合意】「死後事務支援士」ビジネスモデルとシステムの融合

  1. システムによる「業務の限界費用ゼロ化」: お客様対応、提携士業への振り分け、信託口座の分別管理など、アナログで発生する業務を全てAIエージェントと暗号化システム（Rust/SSS）に代替させる。
  2. プラットフォーム戦略: 本システムは単なるエンドユーザー向けエンディングノートではない。「もしものはなし」アプリを通じて集めた顧客情報を、セキュアに死後事務支援士および士業へパスするための「B2B2Cトラストハブ」である。

2. 【デモ】Leptos + Rust による高精細ハリボテデモ実演

  1. UI/UXの優位性: オープンナレッジのWeb/App統合アーキテクチャ（Leptos）による、ネイティブアプリ同等のパフォーマンスとデザイン性。
  2. 画面構成:
    • エンドユーザー向け「預託金・死後事務進捗ダッシュボード」
    • 死後事務支援士向け「顧客トラッキング・士業アライアンス管理画面」

3. 【契約・財務】レベニューシェアモデルの最終確定と契約・請求

  • 初期開発着手金: 5,000,000円（税別）
    • 根拠: 「もしものはなし」の全インフラ費用、サーバー保守、死後事務支援システムの24時間365日稼働保証をオープンナレッジが全額自己負担することに対する、ハイリスク・フルコミットメントの初期費用。
  • 継続レベニューシェア: 40%（オープンナレッジ） / 60%（Yrzu41合同会社）
    • 計算ベース: 決済手数料（Stripe等）控除後の「粗利益（Net Revenue）」から算出。
    • 免責・コスト: オープンナレッジは自己の40%からサーバー代・保守代を全額負担。追加の月額請求は一切なし。
  • 契約・請求の自動化フロー:
    • 本日のMTG後、即座に freeeサイン にて「02_revenue_share_and_contract_specification_ssot.md」に準拠した契約書を送信。
    • 締結と同時に、freee会計 API 経由で着手金のインボイス請求書を自動発行・送付。
    • Goal: 本日中の契約締結と着手金請求の完了。入金確認をもって開発開始。

アクションアイテム・Next Steps

  • freeeサインの承認（Yrzu41合同会社）
  • 請求書の受理・振込手続き（Yrzu41合同会社）
  • 開発環境（GitHubリポジトリ等）の完全稼働（オープンナレッジ）

【Moshimo-no-hanashi】第1回 定例キックオフ・ミーティング 進行および絶対議事録（AGENDA）

⚠️ THE GENERATIVE SSoT: KICKOFF & STRATEGIC ALIGNMENT 本資料は、株式会社オープンナレッジおよびYrzu41社間の第1回定例MTGにおける、一切の無駄を排除した超現実的な進行プロセス、議論の焦点、およびタスクアサインを定義する。一ミリの妥協も許さない、無慈悲なスケジューリングと合意形成を行う。

会議の基本情報

  • 日時: 2026年8月24日（本日）
  • 場所: オンライン / またはオープンナレッジ・オフィス
  • 参加者: 加藤明生（OK社CTO）、平井聡（Yrzu41社社長）、他関係者
  • 本会議の絶対目標: 「宇宙葬」という単一機能への依存を完全に捨て、B2B2Cトラストハブとしての「もしものはなし」の技術的・ビジネス的優位性（Moat）について完全合意し、直ちに行動（実装と営業）へ移ること。

1. 会議の進め方（ファシリテーション・ルール）

  1. Vision Alignment (5分): 「もしものはなし」は単なる終活アプリではなく、士業のレガシー業務を破壊する「SaaS」であり、大企業が絶対に模倣できない「軍事レベル暗号化（SSS）インフラ」であることを再確認する。
  2. The “Aha!” Demo (15分): 言葉での説明を一切排し、稼働するMVPプロトタイプをiPad等で実演する。B2C（シニア）の「音声だけで家系図ができる」魔法と、B2B（士業）の「暗号化が視覚的に解ける」トラスト体験を共有する。
  3. Architecture & 7 SSoTs (15分): オープンナレッジが構築した「7つの絶対設計書」を共有し、システム開発において「理想論を排除した超現実的なRust/AIドリブン開発」が行われることを確約する。
  4. Action & Homework (10分): 両社が「次回のMTGまでに絶対に完了させるべきタスク（宿題）」を明確にアサインし、完了条件を定義する。

2. AGENDA（アジェンダ）と詳細内容

AGENDA 1: 究極のMVPデモ／本番同等プロトタイプの実演

「超効率主義」「AIの狂気的搾取」の原則により、**本日の時点ですでにプロトタイプは「本番リリース水準」に近い品質（WebアプリおよびiPad/モバイルビューとして稼働）**に達している。 本デモは、今後の士業向け営業において、相手に一切の反論を許さない最強の武器となる。

【デモの動かし方】

  • 開発機（Mac）のターミナルで以下を実行。 cd /Users/workspace/ok/ok-sys/projects/moshimo-no-hanashi/apps/stealth_moat_demo && npm run dev -- --host
  • iPadを同一Wi-Fiに繋ぎ、ブラウザから http://<MacのローカルIP>:5173 へアクセスし、フルスクリーンモードでプレゼンを実施する。

AGENDA 2: アーキテクチャの絶対決定と「7つのSSoT」の共有

オープンナレッジが細胞レベルで定義した「もしものはなし」の技術的堀（Moat）。

  1. Rust-Native Core: ガベージコレクションを持たないRustによる、50ms以内のSSS暗号化処理。
  2. Astro+WASMマンデート（うどん餃子パラダイム）: Leptosを棄却し、AI生成と相性の良いAstro/ReactでUIを爆速構築。モバイルはFlutter。
  3. Zero Marginal Cost AIOps: 運用に人間を介在させない、n8nによる自動復旧とエラーバジェット管理。
  4. IP Defense (知財防御): WASMの極限難読化により、競合大企業にアルゴリズムを絶対にリバースエンジニアリングさせない。

AGENDA 3: 長期的な将来を見据えた「全実装機能リスト」の合意

👉 参照: プロダクト・ロードマップ＆機能マトリクス

  • MVP（最短実装）: B2C音声入力（Whisper AI連携）、B2Bダッシュボード（React）、SSS暗号化コア（Rust）、Stripe決済（士業からの徴収）。
  • 直近（年末まで）: LINE(LIFF)連携による摩擦ゼロ登録、freeeサインを用いた委任契約の自動化。
  • 1年以内: B2C-B2B間のAI自動マッチング、外部業者（遺品整理・葬儀等）向けOpen API。
  • 長期的将来: 秘密分散キーとスマートコントラクト（ブロックチェーン）を連動させた、法的拘束力のある完全自動死後事務執行。

3. 議論すべきポイント（Critical Discussion Points）

本日の会議において、ふわふわした理想論を排除し、以下について「Yes/No」あるいは「具体値」で合意を取り付ける。

  1. プライシング戦略（B2B）:
    • 士業（弁護士・司法書士）から月額いくら徴収する設計にするか？（例: 導入費無料・月額1万円＋成約手数料10%など）
    • この価格帯を実証するため、直近のヒアリング先（テストユーザー）はどう確保するか？
  2. 法的免責事項（Zero-Knowledgeの代償）:
    • SSS暗号化により、オープンナレッジ運営側でも顧客データを復号できなくなる。これは「ユーザーがマスターキーを紛失した場合、データは永遠に失われる（運営でも救済不可）」ことを意味する。このリスクを「究極のプライバシー保護」という強みに転換するための、利用規約や営業トークの方向性。
  3. 「宇宙葬」のポジショニング:
    • メインの売りにするのではなく、「プラットフォームが提供する多数の出口戦略（死後事務）の一つ」として扱うことの最終合意。

4. 宿題とするべき内容（Action Checklists & Homework）

両社に対する容赦のないタスクアサイン。次回定例MTG（1〜2週間後）までに必ず完了させる。

🔴 Yrzu41（ビジネス・セールス）への宿題

  • 着手金の決済: freeeから発行された初期開発費用（500万円）の請求書に対する振込処理の完了。
  • MVPデモを用いたヒアリングの実施（最低3〜5件）: 構築したiPadデモを持って、実際の士業（弁護士・司法書士等）へ営業をかけ、「このUIとセキュリティなら月にいくら払えるか」のリアルな金額感と要望を持ち帰る。
  • アライアンス打診: 「もしものはなし」から送客を受けた場合に対応可能な葬儀・遺品整理業者（宇宙葬含む）との事前握り。

🔵 オープンナレッジ（開発チーム）への宿題

  • フィードバックの即時反映: Yrzu41の営業ヒアリングで出たUIの要望を、24時間以内にデモ環境へ反映させる（AI生成の極限活用）。
  • Rust/Axum コアAPIのスキーマ設計: TypeShareを用いたフロントエンド（TypeScript）とバックエンドの型同期パイプラインの構築完了。
  • SSS（シャミア秘密分散法）のPoC実装: 実際にRust上で文字列がN=5に分割され、K=3で復元できることを証明するモジュール（テストコード）の作成。
  • DBスキーマ（PostgreSQL）の構築: RLS（Row Level Security）を用いたマルチテナントデータ構造の初期定義。

5. 顧客サポート (Customer Support)

6. 法務 (Legal)

【Core SSoT】インシデント・レポート：DNSドリフトによるサイトダウン障害とDNSガバナンス

⚠️ THE GENERATIVE SSoT: POST-MORTEM & INFRASTRUCTURE GOVERNANCE 本ドキュメントは、2026年10月2日に発生した docs.moshimo.ok.st へのアクセス障害（タイムアウト）に関する徹底的な原因調査、および二度と人為的ミスを許容しないための絶対的な再発防止策（DNSガバナンス）を定義する。

1. 障害の事象と徹底的な原因分析 (Root Cause Analysis)

1.1 事象

https://docs.moshimo.ok.st/ へブラウザからアクセスすると、ページが表示されず「ネットワークタイムアウト（Connection timed out）」となる。

1.2 徹底的な調査と原因特定

デプロイスクリプト（deploy_secure_docs.nu）は正常に完了していたが、外部からのアクセスのみが遮断されていた。ネットワークレベルでの調査（dig および whois）を実施した結果、以下の致命的な**「DNSの不整合（DNSドリフト）」**が特定された。

  • 正解のIPアドレス: ap01.ok.st = 163.44.119.9 (ConoHa VPS / 本番Nginxサーバー)
  • 誤った設定（現在のDNS）: docs.moshimo.ok.st = 121.83.117.238 (OPTAGE Inc. / eo光の一般回線IP)

【結論】 Cloudflare等のDNS管理画面において、docs.moshimo.ok.st のAレコードが、本番サーバー（ap01.ok.st）ではなく、**加藤CTOの自宅またはオフィスのローカル回線（eo光）のIPアドレスに向いたまま放置されている人為的ミス（設定漏れ）**が根本原因である。 デプロイ処理自体は ap01.ok.st へIP直指定でアップロードを行っていたため「成功」していたが、閲覧者（ブラウザ）は誤ったIP（eo光のルーター）へリクエストを送り、ポート443が開放されていないためタイムアウトしていた。

2. 絶対的な再発防止策 (Recurrence Prevention)

インフラ設定におけるヒューマンエラーをシステムレベルで遮断するため、以下のガバナンスを即時適用する。

2.1 [ルール] サブドメインの Aレコード(IP直打ち) の絶対禁止

今後、*.ok.st のサブドメインを発行する際は、IPアドレスを直接指定する「Aレコード」での運用を固く禁ずる。 必ず、親サーバー名への**「CNAMEレコード」**として登録しなければならない。

  • ❌ 誤: docs.moshimo.ok.st -> A -> 163.44.119.9 (IPが変わると死ぬ)
  • ✅ 正: docs.moshimo.ok.st -> CNAME -> ap01.ok.st (ap01のIPが変わっても追従する)

2.2 [実装] デプロイ時の DNS Validation 強制

deploy_secure_docs.nu 実行時に、単にファイルを転送するだけでなく、「デプロイ先のドメインが、本当に本番サーバーのIPを向いているか」をデプロイ前にチェックし、一致しなければHard-Failさせるロジックを組み込む。

3. 即時復旧のためのアクション (Immediate Remediation)

本障害を解決し、直ちに会議用資料を閲覧可能にするための手順。

  1. DNSレコードの修正 (加藤CTO タスク): Cloudflare または DNSレジストラ（ムームーDNS等）の管理画面に入り、docs.moshimo.ok.st のレコードを以下のように修正する。
    • タイプ: CNAME
    • 名前: docs.moshimo
    • ターゲット: ap01.ok.st
  2. 反映の確認: 手元のターミナルで dig docs.moshimo.ok.st を実行し、163.44.119.9 が返ってくればDNSの修正は完了。
  3. ブラウザ確認: 再度 https://docs.moshimo.ok.st/ へアクセスすれば、先ほどデプロイした資料が即座に表示される。