# PRISM — 技術アーキテクチャ --- ## 1. 全体構成 ``` ┌──────────────── 外部システム（顧客側・読み取り専用） ────────────────┐ │ GitHub/GitLab Slack/Teams Google Workspace 見積・請求 現場報告 │ └──────┬──────────────┬───────────────┬──────────────┬──────────┬──────┘ │ Webhook/API │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ① Ingestion Layer │ │ ・コネクタ（ソース別アダプタ） │ │ ・正規化：すべてを「Signal」という単一スキーマに落とす │ │ ・冪等化：同一イベントの重複取り込みを source_id で排除 │ └──────────────────────────┬──────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ② Signal Store（イベントソーシング） │ │ ・追記のみ。削除しない。すべての推定は再計算可能 │ │ ・PostgreSQL + pgvector（自然文シグナルの意味検索用） │ └──────────────────────────┬──────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ③ Inference Layer（本プロダクトの心臓部） │ │ Stage 1: ルールベース判定（構造化シグナルのみ・LLM不使用） │ │ Stage 2: 小型LLM判定（自然文シグナルの分類・抽出） │ │ Stage 3: 大型LLM判定（Stage 2 の確信度が閾値未満のケースのみ） │ │ 出力: ProjectState { phase, progress, delay, cause, confidence } │ └──────────────────────────┬──────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ④ Correction Loop │ │ ・人間の訂正を Correction イベントとして Signal Store に追記 │ │ ・案件テンプレート単位のルール調整 ＋ few-shot 例として蓄積 │ └──────────────────────────┬──────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ⑤ Translation Layer（3階層ビュー生成） │ │ ・同一 ProjectState から役割別のビューモデルを生成 │ │ ・集約方向は下→上のみ（上→下の要求を発生させない） │ └──────────────────────────┬──────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ⑥ Analytics Layer │ │ ・稼働率 / バス係数 / プロセスマイニング（α-algorithm系＋LLM要約） │ └──────────────────────────┬──────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ ⑦ Automation Layer（Phase 4） │ │ ・提案 → ドライラン → 承認 → 実行 の4段。全実行にロールバック手段 │ └─────────────────────────────────────────────────────────────────────┘ ``` --- ## 2. 中核データモデル ### Signal（すべての入力はこれに正規化される） | フィールド | 型 | 説明 | |---|---|---| | `id` | uuid | | | `source` | enum | github / slack / calendar / drive / billing / field_report / correction | | `source_id` | text | 元システムのID。冪等化キー | | `occurred_at` | timestamptz | 発生時刻（取り込み時刻ではない） | | `actor` | text | 誰が（内部IDへマッピング。個人評価には使わない） | | `project_hint` | text[] | 案件推定のヒント（リポジトリ名、チャンネル名、顧客名など） | | `kind` | enum | commit / pr_merged / review / message / event / file_update / phase_change / report | | `payload` | jsonb | ソース固有の生データ | | `text` | text | 自然文があればここ（pgvector で埋め込み） | ### ProjectState（推定の出力） | フィールド | 型 | 説明 | |---|---|---| | `project_id` | uuid | | | `phase` | text | 案件テンプレートで定義されたフェーズ | | `progress` | numeric | フェーズ内進行度 0〜1 | | `delay_days` | numeric | 計画との差分 | | `cause` | text | 遅延原因の推定（1行） | | `confidence` | numeric | 0〜1。**必ず付与する** | | `evidence` | uuid[] | 根拠となった Signal のID列。**説明可能性のために必須** | | `estimated_at` | timestamptz | | **`evidence` を必須にする設計が重要。** 「なぜそう推定したのか」を Signal 単位まで辿れないと、 訂正のときに人間が納得できず、訂正学習ループが回らない。 --- ## 3. 推定エンジンの段階設計（コストと精度の両立） ``` Signal 到着 │ ├─ Stage 1: ルールベース（LLM不使用・コストゼロ） │ 例) PR が main へ merge → 実装フェーズの進行度を加算 │ Jira のラベルが「検証中」へ遷移 → フェーズ確定 │ → 構造化シグナルだけで確信度 0.9 以上に届くならここで終了（全体の約6割を想定） │ ├─ Stage 2: 小型LLM（差分のみ投入） │ 例) Slack 発言「仕様の回答待ちです」→ 待ち状態を検出、原因を抽出 │ → 確信度 0.75 以上ならここで終了（約3割） │ └─ Stage 3: 大型LLM（残り約1割のみ） 複数の矛盾するシグナルの解釈、原因の因果推論 → それでも 0.70 未満なら「要確認」として人間へ ``` ### コスト試算【仮説】 | 項目 | 想定 | |---|---| | 1案件あたりの月間シグナル数 | 400件 | | Stage 2 に回る割合 | 35% = 140件 | | Stage 3 に回る割合 | 8% = 32件 | | 1社（25案件）あたりの月間推論コスト | 数千円レベル | → 粗利率75%の前提（`03_business_model.md`）は成立する見込み。 → **ただしこの試算は【要確認】。実際のシグナル量が10倍なら設計を見直す必要がある。** --- ## 4. 「監視ツールにしない」ための技術的担保 運用ルールだけでは守れない。**アーキテクチャで不可能にする。** | 担保 | 実装 | |---|---| | 個人生産性スコアを算出しない | ProjectState に個人単位の集計フィールドを**持たせない**。actor は案件への紐付けと属人化分析にのみ使用 | | 個人間比較を作れない | API に「メンバー横断のランキング取得」エンドポイントを実装しない | | 勤務時間を推定しない | Signal の `occurred_at` は案件状態の推定にのみ使用。稼働時間の逆算処理を実装しない | | 稼働率は"競合検出"用途に限定 | 稼働率は「同週に何案件のクリティカルパス上にいるか」から算出。労働時間からは算出しない | | 透明性 | 「何を見て、何を見ないか」を設定画面に常設表示（モックに実装済み） | **この5点は仕様として凍結する。** 顧客から「個人別に見たい」と要望が来ても実装しない。 1度でも実装したら、開発者の信頼を永久に失い、Zero-Input の入口（開発者の協力）が閉じる。 --- ## 5. セキュリティ・コンプライアンス | 論点 | 方針 | |---|---| | 権限 | 全コネクタ読み取り専用。書き込みは Phase 4 の自動化実行時のみ、明示承認付き | | データ保存 | 国内リージョン。テナント分離は論理分離＋行レベルセキュリティ | | LLM への送信 | 顧客データを学習に使わないエンドポイントのみ使用。送信前にPII（氏名・メール・電話）をマスキング | | ログの保持 | Signal は追記のみ。顧客の要求で案件単位の物理削除に応じる | | オンプレ / VPC 対応 | Enterprise プランで対応（【要確認】リベラウェア様の要件） | | SSO / SCIM | Enterprise プランで対応 | | 監査ログ | 誰がどのビューを見たかを記録（＝経営層の閲覧も記録される。片側だけ透明にしない） | --- ## 6. PoC 設計（Phase 0 の中身） ### 入力 - リベラウェア様の**過去6ヶ月分**のログ（GitHub / Slack / Calendar。匿名化可） - 同期間の**実際の案件状況**（PMの認識ベース。答え合わせ用の正解データ） - 案件2〜3件の**業務プロセス実地観察**メモ ### 手順 1. 過去ログを Signal に正規化して投入 2. 各週末時点での ProjectState をバックテストで推定 3. PMの認識（正解データ）と突き合わせ、一致率を算出 4. 遅延の検知タイミングを、実際に問題が発覚した日と比較 5. 確信度のキャリブレーション曲線を描く（確信度0.9帯の実精度は本当に90%か） ### 合否ライン（`04_go_to_market.md` と同一。事前合意する） | 指標 | 合格ライン | |---|---| | フェーズ推定の一致率 | 80% 以上 | | 遅延検知のリード | 実発覚より 3日以上早い | | 誤検知率 | 20% 未満 | | 確信度の校正 | 0.9帯の実精度 85% 以上 | ### PoC で分かってしまう可能性のある不都合な真実 - **シグナルが薄い案件がある。** 現場作業中心の案件は GitHub にも Slack にも痕跡が少ない。 → その場合、F-02 一言報告ボットが必須機能に昇格する（Phase 1 に前倒し）。 - **案件とシグナルの紐付けが難しい。** リポジトリ名・チャンネル名が案件と1:1でない場合、`project_hint` の設計が想定より重くなる。 → 案件マスタとの手動マッピングを初回だけ人間がやる設計に落とす（1回だけなら許容される）。 --- ## 7. リスク登録簿 | # | リスク | 影響 | 発生確度 | 対策 | 検証時期 | |---|---|---|---|---|---| | R1 | AIの進捗推定精度が実用に耐えない | **致命的** | 中 | 確信度の明示、要確認への振り分け、段階的移行（まずシグナル集約表示から） | Phase 0 | | R2 | 連携できないデータがある | 大 | **高** | 一言報告ボット、Excel定期取込、「繋がった分だけ価値が出る」設計 | Phase 0 | | R3 | 監視ツールだと受け取られる | 大 | 中 | §4 の技術的担保＋導入手順の固定化 | Phase 1 | | R4 | 既存ツールとの共存に失敗 | 中 | 低 | 置き換えを求めない。Jira の上に乗るレイヤーとして設計 | Phase 1 | | R5 | LLM推論コストが想定を超える | 中 | 中 | 段階的推論、差分推論、キャッシュ。シグナル量を Phase 0 で実測 | Phase 0 | | R6 | 案件とシグナルの紐付けが機械化できない | 中 | 中 | 初回のみ人間がマッピング。以降は学習 | Phase 0 | | R7 | 大手（Atlassian等）が同機能を実装 | 中 | 中 | 訂正データとプロセステンプレートの蓄積で先行。中堅×現場混在セグメントに集中 | 継続 | | R8 | プロセスマイニングが「見えたが変わらない」で終わる | 大 | 中 | 提案を必ず「試す/あとで」の2択アクションに接続。分析単体で終わらせない | Phase 3 | **R1 と R2 は Phase 0 で必ず潰す。R2 の発生確度は"高"であり、実質的には「起きる前提」で設計すべき。**