BRAID OS システム要件定義書

最終更新: 2026-04-25 版: v2.0（仮説ユニット起点 / 議論のホワイトボード）

v1.2 からの根本的な転換: 「画面に何を置くか（8 機能）」起点 → 「何を決断させるか（3 仮説ユニット）」起点。BRAID OS は固定の設計書ではなく、岩田社長との議論で 5 要素が連動して書き換わるホワイトボード として再定義する。

0. 最重要原則

BRAID OS は「議論のホワイトボード」である。固定の設計書ではない。

0.1 3 つの絶対原則

1. 解決策は岩田氏の note Vol.36-111 から抽出する（我々は考案しない）
2. 課題も解決策も「仮説」である（4/30 商談で岩田氏にぶつけて確定）
3. 5 要素は連動する（どこかがズレたら、他の 4 要素も書き換わる）

0.2 設計判断の単一ルール

「それがないと仮説ユニットの 5 要素のどれかが書けなくなるか？」 → YES → 残す → NO → 削る（例外なし）

0.3 絶対にやらないこと

• 新しい解決策を我々が考案する（note から抽出する）
• 主観的な予測値を出す（-40% 等）
• タブ・段階展開ボタン・装飾グラデーション・ブランド SVG を画面に置く
• デモをプレゼンスライド化する（BI ツール / ホワイトボードであり続ける）

1. 仮説ユニットという最小単位

1.1 仮説ユニットの構造

BRAID OS が扱う最小単位は 「仮説ユニット」。5 つの要素を一本線で繋いだセット。

[1] 課題（仮説）
   ↓ これを解くのは？
[2] 解決策（岩田氏の note から抽出）
   ↓ そうすると、何が決められるようになる？
[3] 決断シーン
   ↓ その決断のために、何が見える必要がある？
[4] 情報要件
   ↓ それを、実データ／UI でどう表す？
[5] 画面

  各要素の横に「ここ違う？」欄
  → ズレを言語化すれば、5 要素が連動して書き換わる

1.2 各要素の定義

1.3 「ここ違う？」欄の役割

• 4/30 商談で岩田社長が見て、各要素のズレを言語化してもらうための欄
• 5 要素のどこかにズレが書かれたら、他の 4 要素も連動して書き換わる
• ズレ = 仮説の進化。書き込みログを残すことで、仮説の歴史が見える

1.4 ユニット間の接続

3 つのユニットは独立しない。互いに接続して、グループ全体の判断系を形成する：

• ユニット ❶ の配分決定が ❷ の TAKIBI 事業投資に影響
• ユニット ❷ の学びが ❶ の新規事業評価に引用
• ユニット ❸ で社長が整理した判断基準が ❶ の支援に使われる

2. 3 つの仮説ユニット（v2.0 時点の仮置き）

2.1 ユニット ❶ ポートフォリオ投資配分

2.2 ユニット ❷ 地方・産地共創

2.3 ユニット ❸ 属人化・暗黙知

3. 機能要件 — 13 機能（v1.2 の 8 機能 + 新規 5 機能）

各機能は仮説ユニットの [5] 画面 に紐付く。機能単独で意味を持たない。

3.1 ユニット ❶ Group（4 機能）

3.2 ユニット ❷ Community（4 機能）

3.3 ユニット ❸ Individual（4 機能）

3.4 共通（1 機能）

機能総数: 13 機能

v1.0 (32) → v1.1 (9) → v1.2 (8) → v2.0 (13)

v2.0 で機能数が増えたのは、「画面起点」から「決断起点」に変えた結果、v1.2 で抜けていた機能（情報成熟度判定 / 社長時間配分 / PJ 進捗モニタ / 迷子パターン検出 / 語録浸透度）が必要だと判明したため。各機能は仮説ユニットの [4] 情報要件 から逆算で導出されている。

4. 議論のホワイトボードとしての画面構造

4.1 全体構造

┌─────────────────────────────────────────────────┐
│ BRAID OS  議論のホワイトボード v0.1   三星グループ │
├─────────────────────────────────────────────────┤
│ ❶ 投資配分  ❷ 共創  ❸ 属人化  （アンカーリンク）│
├─────────────────────────────────────────────────┤
│                                                   │
│  ┌─ ユニット ❶ ────────────────────────────┐  │
│  │ [1] 課題      │  ここ違う？               │  │
│  │ [2] 解決策    │  ここ違う？               │  │
│  │ [3] 決断シーン│  ここ違う？               │  │
│  │ [4] 情報要件  │  ここ違う？               │  │
│  │ [5] 画面      │  ここ違う？               │  │
│  └─────────────────────────────────────┘  │
│                                                   │
│  ┌─ ユニット ❷ ────────────────────────────┐  │
│  │ ...                                          │  │
│  └─────────────────────────────────────┘  │
│                                                   │
│  ┌─ ユニット ❸ ────────────────────────────┐  │
│  │ ...                                          │  │
│  └─────────────────────────────────────┘  │
│                                                   │
└─────────────────────────────────────────────────┘

4.2 1 ユニットのレイアウト

─────────────────────────────────────────────
ユニット ❶ ポートフォリオ投資配分
─────────────────────────────────────────────

[1] 課題（仮説）              │ ここ違う？
事業ポートフォリオの投資配分が │ [textarea]
不透明                        │
                              │
─ ↓ これを解くのは？ ─        │
                              │
[2] 解決策（岩田氏の note 由来）│ ここ違う？
Vol.108 BRAID 2026「束ねる」    │ [textarea]
Vol.91 スピードアップ           │
Vol.97 創造性への投資           │
Vol.84 MAZEる                  │
                              │
─ ↓ そうすると、何が決まる？ ─ │
                              │
[3] 決断シーン                │ ここ違う？
次期 FCF ¥180M を、どの事業に │ [textarea]
配分するか（四半期）           │
                              │
─ ↓ そのために、何が見える？ ─ │
                              │
[4] 情報要件                  │ ここ違う？
① 5 社損益                    │ [textarea]
② 各社投資中案件              │
③ 配分余地                    │
④ 過去類似案件の結果          │
⑤ 社長時間の配分              │
                              │
─ ↓ 実データ/UI でどう表す？ ─ │
                              │
[5] 画面                      │ ここ違う？
GV-01 5 社財務統合ビュー       │ [textarea]
GV-02 案件成熟度判定           │
GV-03 社長時間配分ビュー       │
GV-04 過去類似案件ドリル       │
[簡易プレビュー画面]            │

4.3 [5] 画面欄の扱い

• 各機能（GV-01 等）は名前と 1 行説明のみ
• 簡易プレビュー画面は 1 ユニットあたり 1 枚（v1.2 の Scene 画面を簡易化）
• プレゼンスライド化しない（BI ツール / ホワイトボードであり続ける）

5. データ要件（v1.2 の 6 ソース + 1 追加）

6. 技術要件（v1.2 と同じ）

• LLM: Claude Sonnet 4.6
• RAG: Cloudflare Vectorize（Vol.36-111 をインデックス化）
• フロント: HTML + 最小 CSS（Tailwind CDN 任意）
• バック: Cloudflare Workers + D1
• ホスティング: Cloudflare Pages
• 認証: Cloudflare Access + Google SSO

AI モジュール: LLM / RAG / GUARD の 3 つ

7. 非機能要件

8. 数字の原則

出す数字: 実データ or 計算式で根拠が示せるもののみ 出さない数字: 主観予測、仮置き %、未稼働シミュレーション

数字タグ（ドリル内で表示）: SAMPLE / REAL / ESTIMATE / DESIGN / MIXED

9. フェーズ計画

10. スコープ外（絶対に入れない）

• タブナビ／段階展開ボタン
• 月次推移チャート／AI 部長 3 人／30PJ 一覧 UI／14 社マップ／ひつじ 50 社図／螺旋図／語録クラウド／プリセット 5 人
• 「岩田語録メトリクス」等の副題・世界観コピー
• 背景グラデーション／装飾アニメ／ブランド SVG ロゴ
• スパークライン（数字だけで十分）
• 新しい解決策の考案（note 抽出のみ）
• 主観的な予測値（-40% 等）
• プレゼンスライド化（デモは BI / ホワイトボード）

13 機能以外を入れないことが品質を守る。

11. リスクと対応

12. 4/30 商談での使い方

12.1 進行（再定義書 § 5.4 より）

1. 上記 3 つの仮説ユニットを岩田社長に提示
2. 1 ユニットずつ「ここ違う、という箇所を教えてください」と問う
3. 出たズレを、その場で該当欄に書き込む（例：[3] 決断シーンのズレ → 「本当は配分額じゃなくて "配分すべき順序" を決めたい」）
4. 書き込んだズレを見て、5 要素のどこが連動して崩れるかを確認
5. その場で仮説を修正し、次のユニットへ進む

12.2 商談で確認する 7 問（再定義書 § 7.2）

1. ❶：投資配分の意思決定で、今一番「情報がそろっていない」と感じる案件は何か
2. ❶：5 社を同じ物差しで見たい、と感じる頻度はどのくらいか
3. ❷：TAKIBI の 30 PJ のうち、「もっとこうすればよかった」と思う失敗は
4. ❷：次の 1 年で新規共創 PJ を何本立ち上げたいか
5. ❸：社員からの相談で、同じ質問が繰り返されるのはどんな内容か
6. ❸：社長自身の時間で、「手放せるはずなのに手放せない」業務はどれか
7. 全体：BRAID 2026 で「束ねる」の優先順位は（5 社 / コミュニティ / 14 社 のどれから）

12.3 解決策の Vol 確認問い

• 「❶ に対する解決策として、Vol.108・Vol.91・Vol.97 を中心に抽出しましたが、主軸として合っていますか？」
• 「❷ の解決策は Vol.79・Vol.98 が中心で、クロッシングのネットワーク化で合っていますか？」
• 「❸ の解決策は Vol.107・Vol.100 で、仕事の地図の動的実装 + AIShingo で合っていますか？」

13. 変更履歴

14. 関連ドキュメント

• 10_要件/BRAID OS 再定義書.md v0.1（本書の上位文書、最重要）
• 10_要件/UIUX設計書.md v2.0（議論のホワイトボード UI 仕様）
• 20_成果物/demo-braid-os/index.html v2.0（仮説ユニット UI プロトタイプ）
• 10_要件/提案書10枚設計.md（4/30 商談で使う本体）
• 00_北極星.md（岩田氏の判断基準）
• 40_参考/岩田真吾_人物プロファイル.md（語録・禁句）