職人向け究極実装魔導書）

⚠️ 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 実装指令

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,
}
}

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 実装指令

Supabase / PostgreSQLのRLS強制有効化:

ALTER TABLE assets ENABLE ROW LEVEL SECURITY;

Jwt Claimsのバインディング: Rust (Axum) のミドルウェアでJWTをパージし、PostgreSQLのセッション変数（request.jwt.claims）に role と tenant_id をセットする。

無慈悲なポリシー定義:

-- 顧客本人は自分のデータのみアクセス可能
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'
    )
  );

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

3.1 実装指令

純粋Rust（no_std 互換推奨）でのSSS実装: shamir-secret-sharing クレート（または独自実装）を用い、シニアが入力したデータをJSON文字列化し、AES-GCM-SIV等で暗号化。その「AESの鍵」をSSSで N=5 に分割する。

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);

キーの分散保管ロジック:
- 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 実装指令

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

Keyboard shortcuts

もしものはなし 開発ドキュメント (SSoT)

もしものはなし開発ドキュメント (SSoT)