1. データ主権
Vercel + Supabase 上に御社専用環境を構築。コードもデータもインフラも御社所有。AIONIX 社はデプロイ支援のみ実施し、運用後はソースもデータも持ち出しません。
Source: 戦略 §1 / docs/strategy/aion-strategy.md
Security & Legal Admissibility
セルフホスト × 暗号学的監査
× 日本規制準拠を、コードで証明する。
御社所有の Vercel + Supabase 環境に、pgcrypto sha256 hash chain・FORCE RLS 90 テーブル・AES-256-GCM envelope 暗号化を実装済。電子帳簿保存法・個人情報保護法・ J-SOX 職務分掌を schema レベルで強制し、改ざん耐性と法的 admissibility を両立します。
hash chain (sha256)FORCE RLS × 90 tablesAES-256-GCM envelopeappend-only personaJ-SOX SoD trigger
Pillars
セキュリティ 5 本柱
データ主権・暗号学的監査・列レベル immutability・多重 RLS・envelope 暗号化。 それぞれ migration / lib のコードで実装済の項目だけを掲載しています。
実装済
2. 暗号学的監査チェーン
audit.event / persona_decisions / ambient_observations など 6 テーブルに pgcrypto sha256 hash chain (prev_hash → row_hash) を BEFORE INSERT トリガで自動付与。中途行を改竄すると以降の chain が破綻し、検知可能。
Source: migration 00000000001900 + 2000 backfill
実装済
3. Append-only Persona 記録
経営判断ログ persona_decisions の choice / reasoning / context / decided_at / founder_id は DB トリガで UPDATE 拒否。半年後の追記 (outcome_after) のみ列レベルで許可。物理削除は全テーブルで禁止。
Source: migration 1900 §2 列レベル immutability trigger
実装済
4. 多重 RLS (FORCE Row Level Security)
core / accounting / sales / crm / purchasing / inventory / hr / project / production / audit / aion / packs の 90 テーブルに FORCE RLS を一括適用。postgres / supabase_admin オーナー権限でも RLS が剥がれず、service_role 漏洩でも全テナント横断は不能。
Source: migration 1900 §3 FORCE ROW LEVEL SECURITY
実装済
5. Envelope 暗号化 (AES-256-GCM)
ambient_observations.raw (Slack DM / Gmail / Meet / 通話書き起こし) を Application 層で AES-256-GCM 暗号化。per-record 12-byte IV + 16-byte 認証 tag + AAD=companyId:kind で copy-paste 攻撃も検出。keyVersion で年次キーローテーション。
Source: lib/crypto/envelope.ts + docs/strategy/encryption-strategy.md
Japanese Regulatory Compliance
5 つの日本規制への準拠
設計時点で日本の法規制を schema と RLS ポリシーに織り込んでいます。 「あとから対応」では間に合わない構造的要件を、初期から baked-in。
適格請求書 (インボイス) 制度
取引先マスタに登録番号 (qualifiedInvoiceRegNo) を保持。請求書発行時に qualified flag + 税率別合計を分離記録。非適格仕入の経過措置 (80% → 50% → 0%) を税コードマスタの valid_from/valid_to で自動切替。
core.partner.qualifiedInvoiceRegNo / sales.invoice / accounting.tax_code
電子帳簿保存法 (令和 6 年改正)
core.attachment は sha256 hash chain で改ざん検知。検索 3 軸 (取引年月日 / 取引金額 / 取引先) を schema レベルで保持。物理削除なし、反対仕訳 (赤伝) は明示的 domain event。Phase 2 で JIPDEC 認証 TSA タイムスタンプ。
core.attachment / sales.invoice / migration 1900 hash chain
消費税 (税法改正への config 対応)
税コードは accounting.tax_code マスタの行 (10% / 軽減 8% / 不課税 / 免税 / 経過措置) で表現。valid_from/valid_to で時系列バージョニング。税率改正は config 更新のみで対応し、code 変更を伴わない。
accounting.tax_code (valid_from/valid_to)
マイナンバー法
個人番号は hr.individual_number に分離保管し pgsodium で列レベル暗号化。アクセスは step-up MFA を必須化、全 read を audit.event に記録。要配慮個人情報の混入は redact パイプラインで取込前にマスク。
hr.individual_number / lib/ai/redact.ts
J-SOX 職務分掌 (SoD)
仕訳の承認・記帳は requireDistinctActor() でアプリ層強制、加えて RLS ポリシーで 起票者 ≠ 承認者 を DB レベルで保証。service_role bypass 経路もアプリ層でカバー。証跡は audit.event hash chain で改ざん耐性付き。
lib/auth/permissions.ts / migration 1900 FORCE RLS
Roadmap
Phase 別 改ざん耐性ロードマップ
Now (実装済) は事業者内部の改ざん耐性、Phase 2 で第三者保証 (TSA / 多重署名)、 Phase 3 で long-term verifiability (blockchain / 信託) を追加。
Now — Phase 0
実装済アプリ内改ざん耐性
- pgcrypto sha256 hash chain (6 テーブル)
- FORCE Row Level Security (90 テーブル)
- persona_decisions 列レベル immutability trigger
- AES-256-GCM envelope (AAD + keyVersion)
- audit.event + core.domain_event 二重記録
- proposal_audit guard trigger (AI 提案 append-only)
事業者自身が誠実に保管した電磁記録として一次受容性は確保。第三者保証は次フェーズ。
Phase 2 — AIONIX Pro
計画 (2026 Q4 - 2027 Q1)第三者保証 anchoring
- OpenTimestamps anchor (Bitcoin mainnet)
- 国内 TSA 連携 (セイコー / アマノ JIPDEC 認証, RFC 3161)
- 監査人 2-of-N 多重署名 (会計士 / 弁護士)
- proposal_audit への public-key 署名 + 顧客側独立検証
- etax_exporter (検索 3 軸 CSV + TSR 同梱)
税務調査 / 商業訴訟で「第三者検証可能な改ざん耐性」を主張可能。
Phase 3 — AIONIX Eternal
計画 (2027 Q2+)Long-term verifiability
- Ethereum / Polygon contract anchoring (Merkle root 月次記録)
- pgsodium + Shamir Secret Sharing (5 分割 / 3 復元)
- 家族信託 PDF の sha256 を Ethereum L1 に on-chain anchor
- JIPDEC 認証 TSA との 20 年 SLA (国税庁 7 年保存義務を超過)
- 公証人 + 信託会社 + 法律事務所の冗長化
創業者死亡後の事業承継訴訟で 20 年スパンの判断ログ証明を可能にする。
Compliance Posture
認証 + DPA への姿勢
自社認証は中期計画。短期は「御社側で取得する際の支援」と「クラウド事業者の認証継承」で構成します。
自社認証取得
SOC 2 Type II / ISO 27001 / ISMS は中期計画 (2027 Q1+)。現在は Vercel + Supabase 各社の取得済認証を継承する形で安全管理措置を構成。
顧客側認証取得の支援
御社が SOC 2 / ISMS を取得する際、AIONIX 環境のセキュリティ記述書 + 監査証跡サンプル + RLS / 暗号化の技術仕様書を Pack Enterprise で提供。
DPA (Data Processing Agreement)
Anthropic / OpenAI / Google Cloud / Supabase それぞれの委託契約モデルを取りまとめた DPA テンプレを /legal/dpa で提供。Zero Retention 契約は御社名義で締結可能。
個人情報保護法 31 条 (安全管理措置)
技術的措置 (RLS / 暗号化 / hash chain) + 組織的措置 (audit / 役割分担) + 物理的措置 (Supabase 東京リージョン強制) + 人的措置 (アクセス権棚卸) の 4 軸で対応。
Worker Privacy & Consent
個情法 × 労働者監視への配慮
Slack / Gmail / Meet / 通話の ambient 取得は、技術より先に「目的明示・同意・必要最小限」の 3 要件で運用します。
3 要件: 目的明示 + 同意 + 必要最小限
労働判例 (関西電力事件・日本 IBM 事件) に基づく社員監視 3 要件。AIONIX は就業規則改定モデル条文 + 個別同意書テンプレを顧客に提供。
片側同意 / 両側同意の判定フロー
Slack DM / Gmail / 社内 Meet は片側同意で運用可。外部参加者を含む通話・会議は録音前に同意プロンプト発行 → 同意得られず時は文字起こしを揮発で破棄。listener に組込予定 (Phase 2)。
録音・取込包括同意 (就業規則テンプレ)
Pack Premium で就業規則改定モデル条文 + 監修サービスを提供。新規 source 連携時の個別同意書も同梱。実テキストは顧客側顧問弁護士の最終監修を前提。
弁護士法人との業務提携
医療 / 士業 / 労務の 3 領域で国内法律事務所と業務提携。労使紛争 / 個人情報保護委員会 24h 速報 / 税務調査時の法務サポートを提供 (Pack Enterprise)。
本セクションの内容は AIONIX 内部ガイドラインです。具体的な就業規則改定 / 同意書 / 通知文書は、 顧問弁護士監修のもと顧客側で最終化する前提で提供します。
AI Governance
AI は推奨、決定は人間
AIONIX の AI 機能はすべて「提案を出すだけ」。書き込みは人間の承認が必須、提案の根拠は append-only で保存します。
AI は推奨を出すだけ、決定権は人間
全 AI 書き込みアクションは人間の承認ゲート (proposal_audit.approved_by) を必須化。AI は提案行を生成し、人間が確認・採用・却下する 2-step ワークフロー。
Evidence + Rationale の完全保存
全 AI 提案に context (入力) / rationale (理由) / confidence (信頼度) を proposal_audit に保存。トリガで append-only。説明責任 (accountability) を DB レベルで担保。
Guardrails (prompt injection / data exfil)
lib/ai/guardrails で prompt injection 検出と外部送信前の PII 漏出検査を実施。違反は is_misaligned フラグで強制隔離 + 別 audit ログ。
Redact (PII 自動マスク)
lib/ai/redact で取込時点に マイナンバー / クレジットカード / 健康情報を正規表現 + 分類器で検出 → マスク後 raw に保存。要配慮個人情報を Anthropic / OpenAI に送信しない。
Persona Drift Check (月次)
persona_models のバージョン履歴を月次で diff し、創業者本人の意思と乖離 (drift) していないかを自動レポート。乖離検知時は人間レビューを必須化。
Next Step
セキュリティ要件を、
技術的に検証する。
SOC / 法務 / 情シスチームでの個別レビューに対応します。 hash chain の検証 SQL や RLS ポリシー全件の出力、envelope 復号デモも提供可能です。