影響ありません。

VSCode の各 Claude Code セッションは、それぞれ起動時の作業ディレクトリ（cwd）を独立して保持します。新規セッションでフォルダを変更しても、すでに動作中の他の3セッションの作業ディレクトリ・コンテキスト・メモリ参照先は変わりません。

ただし注意点：

• 同じファイルを複数セッションで編集すると、後勝ちで上書き競合が起きます
• git 操作（branch切替、commit、reset 等）は同一リポジトリ内なら全セッションに影響します
• .claude/settings.json の変更は同フォルダを開いている他セッションの次回読み込みに反映されます

フォルダ切替自体は安全です。

@tybys/wasi/wasm-util というパッケージ名は不正です（npm スコープ付きパッケージは / を1つしか含められません）。正しくは @tybys/wasm-util の typo と思われます。これに修正して続行します。

Tailwind v4 では tailwindcss init -p コマンドが廃止されたため、設定ファイルを手動作成します。

セットアップ完了しました。

作成場所: C:/Content_Factory/P0600_MART/wf-quality-prototype4/quality-dashboard/

実行内容:

1. ✅ Vite + React-TS プロジェクト作成
2. ✅ 本番パッケージ 15個インストール（react / echarts / zustand / lucide-react / simple-statistics / ml-cart 等）
3. ✅ 開発パッケージ 18個インストール（vite-plugin-singlefile / tailwindcss / typescript-eslint 等）
4. ✅ vite.config.ts を GAS 単一ファイル出力用に書き換え
5. ✅ src/index.css を Tailwind 用に書き換え
6. ✅ tailwind.config.js / postcss.config.js を作成

スクリプトからの修正点（2箇所）:

• @tybys/wasi/wasm-util → @tybys/wasm-util（npm スコープパッケージ名はスラッシュ1つまで。typo と判断）
• npx tailwindcss init -p はコマンド廃止（Tailwind v4）のため、設定ファイルを手動作成

注意: Tailwind v4 が入りましたが、src/index.css はスクリプト指示どおり v3 構文（@tailwind base/components/utilities）です。v4 では @import "tailwindcss"; が推奨されます。npm run dev 実行時にエラーが出る可能性があります — 出たら修正方針を報告します。次に進めますか？

起動方法:

cd C:\Content_Factory\P0600_MART\wf-quality-prototype4\quality-dashboard
npm run dev

起動手順（PowerShell）:

cd C:\Content_Factory\P0600_MART\wf-quality-prototype4\quality-dashboard
npm run dev

実行すると Vite がローカルサーバーを起動し、コンソールに表示される URL（通常は http://localhost:5173/）をブラウザで開いてください。

その他のコマンド:

用途	コマンド
開発サーバー起動	npm run dev
本番ビルド（GAS用単一HTML生成）	npm run build
ビルド結果のプレビュー	npm run preview
Lint チェック	npm run lint

停止方法: ターミナルで Ctrl + C

可能です。vite-plugin-singlefile を入れているので、ビルドすると HTML 1ファイルにすべて（JS/CSS/画像/WASM）が埋め込まれた状態で出力されます。これをブラウザで直接開けば開発サーバー不要です。

手順:

cd C:\Content_Factory\P0600_MART\wf-quality-prototype4\quality-dashboard
npm run build

ビルド後、生成された dist\index.html をエクスプローラーでダブルクリック（または下記コマンド）で開けます。

start dist\index.html

メリット / デメリット:

	サーバーレス（build → HTML直開き）	dev サーバー（npm run dev）
サーバー起動	不要	必要
配布のしやすさ	HTML 1個を渡すだけ	不可
ホットリロード	なし（変更のたび npm run build）	あり（自動反映）
起動速度	ビルド数秒〜十数秒	即時
GAS への貼付け	そのまま使える	不可

注意:

• file:// で開くため、外部 API 通信や一部の fetch がブラウザのセキュリティ制限で動かない場合があります（CORS / Mixed Content）。
• 開発中は npm run dev、配布・GAS埋込みは npm run build の使い分けが楽です。

CORS / Mixed Content 回避策

原因の整理

問題	発生条件	内容
CORS	file:// または異なるオリジン間で fetch/XHR を使う	サーバーが Access-Control-Allow-Origin を返さないとブラウザが拒否
Mixed Content	https:// ページから http:// リソースを読む	ブラウザが自動ブロック

---

回避策（用途別に推奨順）

① ローカルHTTPサーバーで開く（最も簡単・推奨）

file:// を http://localhost にするだけで CORS の多くが解消します。

cd C:\Content_Factory\P0600_MART\wf-quality-prototype4\quality-dashboard
npm run build
npx serve dist          # または: npx http-server dist -p 8080

ブラウザで http://localhost:3000(serve) / http://localhost:8080(http-server) を開く。

② Vite の dev サーバー proxy を使う（開発中のAPI通信）

vite.config.ts にプロキシ設定を追加。ブラウザは同一オリジン宛てに通信するため CORS 発生せず。

export default defineConfig({
  // ...既存設定
  server: {
    proxy: {
      '/api': {
        target: 'https://example.com',
        changeOrigin: true,
        secure: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
})

クライアント側は fetch('/api/users') のように相対パスで呼ぶ。

③ GAS WebApp をAPIサーバーにする（このプロジェクト向け）

vite-plugin-singlefile で出力した HTML を GAS にデプロイすれば、同一オリジン（script.google.com）から google.script.run で GAS 関数を呼べるため CORS 自体が発生しません。

// クライアント
google.script.run
  .withSuccessHandler(data => console.log(data))
  .getEmployeeList();

このプロジェクトの本来の使い方はこれです。

④ サーバー側で CORS ヘッダーを返す（API側を制御できる場合）

// 例: Express
app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  next();
});

GAS の場合は doGet で ContentService.createTextOutput(...).setMimeType(...) を返し、必要に応じて setHeaders() を使用。

⑤ Mixed Content 専用の対処

• 配信元を https に統一（最善）
• API 側を https 化できないなら、上記②のプロキシ経由で逃がす

⑥ 開発時のみブラウザで CORS を無効化（非推奨・最終手段）

# Chrome を CORS 無効で起動（個人検証のみ。常用厳禁）
chrome.exe --disable-web-security --user-data-dir="C:\temp\chrome-no-cors"

通常ブラウザでの閲覧と分離するため --user-data-dir を必ず指定。

---

このプロジェクトでの推奨

状況	選択
開発中、外部APIを叩く	② Vite proxy
開発中、GAS関数を叩く	GAS にデプロイして③
ローカル動作確認のみ	① npx serve dist
配布（GAS WebApp として）	③

はい、その理解で正しいです。

整理すると以下の通りです：

コマンド	用途	サーバー	CORS/Mixed Content
npm run dev	開発（ホットリロード付き）	Vite が http://localhost:5173 を起動	✅ 同一オリジン扱い・proxy も使えるので問題出にくい
npm run build	GAS 貼付け用の単一 HTML を生成（dist/index.html）	不要	─（生成のみ）
npm run preview	dist/ を本番相当で確認	Vite が http://localhost:4173 を起動	✅ http:// なので CORS 問題出にくい
npm run lint	コード静的チェック	不要	─

停止: ターミナルで Ctrl + C

---

補足：先ほどの「サーバーレスで開く」との関係

• dist/index.html をダブルクリックで開く方法（file://）→ CORS / Mixed Content が出やすい
• npm run preview または npx serve dist → 同じ dist/index.html を http://localhost 経由で開くので問題が出にくい

つまり、「サーバーレスで開ける」けれど、外部通信があるなら npm run preview を使うのが安全、という結論です。

通常の開発フロー：

1. 開発中 → npm run dev
2. 仕上がりを本番相当で確認 → npm run build → npm run preview
3. GAS にデプロイ → dist/index.html の中身を GAS の HTML ファイルに貼付け

予告していた Tailwind v4 構文の問題です。src/index.css を v4 構文に修正します。

修正内容:

src/index.css の冒頭を v4 構文に変更しました。

- @tailwind base;
- @tailwind components;
- @tailwind utilities;
+ @import "tailwindcss";

理由:

• 元のスクリプトは Tailwind v3 を前提に書かれていました（@tailwind base/components/utilities は v3 構文）
• 実際にインストールされたのは Tailwind v4 で、ディレクティブ方式は廃止され @import "tailwindcss"; 1行に統一されています
• エラーメッセージ Cannot apply unknown utility class 'bg-slate-950' は、ユーティリティクラスが読み込まれていないために発生していました

確認方法:

ブラウザを再読み込みするだけで自動反映されます（Vite の HMR）。エラーオーバーレイが消えれば成功です。

消えない場合はターミナルで Ctrl + C → npm run dev で再起動してください。

---

補足：v4 では tailwind.config.js も不要

Tailwind v4 は CSS ファースト設定に変わり、tailwind.config.js の content 指定なしでも自動でソースを検出します。今ある tailwind.config.js は無害ですが、不要であれば削除可能です（カスタムテーマを追加するなら残してOK）。

意図を取り違えていました。wf-quality-prototype と同じアプリ内容を、新しい npm セットアップで動かしたい、ということですね。

現状の wf-quality-prototype4 は Vite の初期テンプレートのままです。wf-quality-prototype のソース（src/, index.html, public/ など）をコピーする必要があります。

まず元プロジェクトの構成を確認します。

判明した状況：

問題点

wf-quality-prototype で使われている依存パッケージのうち、ユーザー提供の npm スクリプトに含まれていないものがあります。

パッケージ	wf-quality-prototype	提供スクリプト
recharts（チャート）	✅ 使用中	❌ 未インストール（代わりに echarts）
papaparse（CSV パーサ）	✅ 使用中	❌ 未インストール
@types/papaparse	✅ 使用中	❌ 未インストール

このため、ソースをそのままコピーすると import エラーで動きません。

対応方針（要判断）

A案：仕様優先（推奨）

• src/, index.html, public/ をコピー
• 不足している papaparse recharts @types/papaparse を追加インストール
• → 元と同じ動作。npm スクリプトに2行追加する形

B案：スクリプト優先

• ソースを recharts → echarts、papaparse → 自前パーサに書き換え
• → 大規模改修が必要。「仕様は変更せず」に反する

C案：丸ごと複製

• wf-quality-prototype をフォルダごとコピーして wf-quality-prototype4 にリネーム
• → npm スクリプトでの再生成という指示から外れる

---

A案で進めてよろしいですか？ その場合、以下を実行します：

1. wf-quality-prototype/src/ index.html public/ を wf-quality-prototype4/quality-dashboard/ に上書きコピー（既存の index.css は v4 構文を維持）
2. npm install papaparse recharts と npm install -D @types/papaparse を追加実行
3. npm run dev で起動確認

ご指示ください。

作業完了しました。以下を実行してください：

cd C:\Content_Factory\P0600_MART\wf-quality-prototype4\quality-dashboard
npm run dev

実行内容:

1. ✅ wf-quality-prototype/src/ index.html public/ を上書きコピー
2. ✅ papaparse recharts を本番依存に追加
3. ✅ @types/papaparse を開発依存に追加

ブラウザで http://localhost:5173/ を開いて、元の wf-quality-prototype と同じ画面が表示されるか確認してください。エラーが出たら内容を共有してください。

制約への適合性を確認するため、ソースコードを検査します。

制約適合性チェック結果

#	制約	結果	詳細
1	Windows 11 PC	✅ 適合	Node.js / Vite / npm はすべて Windows 11 で動作。OS 依存コードなし
2	Google Workspace のみ	⚠️ 注意	現状は外部サービス未使用。ただしサーバー機能なし＝Google Workspace 統合（GAS連携等）も未実装
3	Gemini API キー不可	✅ 適合	コード/依存関係に Gemini / OpenAI / Anthropic 等の AI API 呼出しなし
4	ファイルサーバーなし	✅ 適合	サーバー不要のフロント完結型。vite-plugin-singlefile で HTML 1ファイル化可能
5	ファイル共有は Google Drive のみ	✅ 適合（条件付き）	配布物は HTML 1ファイル → Drive で共有可能。ただし現状は Drive 連携コード未実装
6	外部データ送信不可	✅ 適合	コード内の fetch() は **/sample-*.csv（同一オリジンの相対パス）のみ**。外部 URL への送信なし

---

詳細所見

**fetch() の用途確認（src/quality/load*.ts）:**

fetch('/sample-defects.csv')         // ← 同一オリジン（public/ 内のCSV）
fetch('/sample-scope.csv')
fetch('/sample-review-records.csv')
fetch('/sample-test-progress.csv')

すべて自身に同梱された CSV を読むだけ。外部送信なし。

依存パッケージの安全性:

• すべてビルド時/ランタイム時にネットワーク通信しないライブラリ群
• react recharts echarts papaparse simple-statistics ml-cart zustand lucide-react 等
• AI/クラウド系SDK（gemini, openai, googleapis, firebase 等）なし

配布形態と Google Workspace 親和性:

• npm run build で dist/index.html 1ファイルが生成される（vite-plugin-singlefile 効果）
• この HTML を Google Drive にアップロード → 「アプリで開く → ブラウザでプレビュー」または GAS の HTML テンプレートに貼付けて WebApp 化 が可能
• いずれも外部サービス不要

---

改善余地（任意）

現状の警戒点： 制約には適合していますが、「Google Workspace のみ利用可能」「ファイル共有 Google Drive のみ」を能動的に活かす実装はまだない状態です。今後以下の方向性が考えられます：

1. GAS WebApp 化 → dist/index.html を GAS のスクリプトファイルに貼付け、google.script.run で Sheets/Drive/Calendar API を呼ぶ
2. CSV 入力を Google Sheets に置換 → public/*.csv を Sheets に置き、GAS 経由で取得
3. 結果出力を Drive 保存 → DriveApp.createFile() で帳票PDF生成

ご希望があれば、上記の Google Workspace 統合実装をお手伝いできます。

結論：6項目すべての制約に適合しています。

追加制約への適合性チェック

#	追加制約	結果	詳細
7	スプレッドシートは遅いため、JSON/CSV を極力使う	✅ 完全適合	データ入力は CSV 4本、Sheets 連携コード一切なし

---

詳細

現在のデータソース構成（src/quality/）:

読込関数	入力ファイル	形式
loadDefectsFromPublicCsv	public/sample-defects.csv	CSV
loadScopeFromPublicCsv	public/sample-scope.csv	CSV
loadReviewRecordsFromPublicCsv	public/sample-review-records.csv	CSV
loadTestProgressFromPublicCsv	public/sample-test-progress.csv	CSV

すべて CSV ファイルで、papaparse で高速パース。Sheets API への呼び出しはゼロ。

性能的にも理想的:

• CSV は HTML と同じく vite-plugin-singlefile でビルド時に Base64 埋込み可能（assetsInlineLimit: 100000000 設定済み）→ ネットワーク往復ゼロ
• Sheets API のレート制限・レイテンシ（数百 ms〜秒）と無縁
• ローカル fetch のみなので即時表示

---

結論：7項目すべての制約に適合

特に追加制約7は本構成の中核設計と完全に一致しています。CSV ベースで全データを処理しており、スプレッドシート連携を持ち込まない限りこの優位性は維持されます。

将来の運用方針の助言（任意）:

• データ更新は Drive 上の CSV を直接編集 または Sheets で編集 → CSV エクスポート → Drive 配置
• 大量データ（数万行〜）になる場合は JSON 化（圧縮効果あり） も選択肢
• どうしても Sheets 参照が必要な場合は、GAS 側でバッチ処理 → CSV/JSON にキャッシュ出力 → フロントは CSV/JSON のみ読む構成にすると性能維持できます

エッジAI組み込みの可否：完全に可能（むしろ理想的構成）

実は、ユーザー提供の npm スクリプトに既にエッジAI用のパッケージが含まれています。コメントの「エッジAI、WASM」がこれです。現在 wf-quality-prototype4 には既にインストール済みで、活用待ち状態です。

---

既にインストール済みのエッジAI関連ライブラリ

パッケージ	用途	用例
simple-statistics	統計解析	異常検知、回帰、相関、確率分布
ml-cart	決定木（CART）機械学習	不具合分類、優先度予測、リスクスコア
@tybys/wasm-util	WASM ランタイム補助	高速計算（C/Rust製モデルの実行）
**@emnapi/***	Node-API for WASM	ネイティブモジュールのブラウザ実行
@napi-rs/wasm-runtime	Rust→WASM 実行環境	Rust製MLモデルの呼出し

これらはブラウザ内で完結して動き、外部API通信ゼロ。制約6（外部送信不可）と完璧に整合します。

---

このプロジェクトに自然に組み込めるエッジAIユースケース

既存データ（不具合、レビュー記録、テスト進捗、スコープ）から見て、以下が自然な拡張です：

#	機能	使用ライブラリ	データ源
1	不具合の異常スパイク検知（Z-score / IQR）	simple-statistics	sample-defects.csv
2	品質劣化の早期警報（ARIMA風移動平均、Trend検定）	simple-statistics	テスト進捗 + 不具合
3	不具合の重大度予測（決定木分類器）	ml-cart	不具合履歴
4	サブシステム別リスクスコア（Naive Bayes / 線形回帰）	simple-statistics	スコープ + 不具合
5	出荷判定支援（信頼度成長モデル：Goel-Okumoto等）	自前 + simple-statistics	不具合の発見/混入フェーズ
6	根本原因クラスタリング（K-means）	simple-statistics	root_cause_category
7	テキスト類似不具合の検出（TF-IDF + コサイン類似度）	自前 or natural	不具合タイトル
8	レビュー指摘パターン学習（決定木）	ml-cart	レビュー記録

---

さらに高度なエッジAI（WASM活用）

ブラウザ内で本格的な機械学習モデルも動きます：

技術	npm パッケージ例	性能
TensorFlow.js（WebGPU）	@tensorflow/tfjs	中〜大規模NN、WebGPUで高速化
ONNX Runtime Web	onnxruntime-web	学習済モデル(.onnx)をブラウザ実行
Transformers.js（Hugging Face）	@huggingface/transformers	BERT/GPT系をWASMで実行
WebLLM	@mlc-ai/web-llm	LLM をブラウザGPUで動作

→ モデルファイル（.onnx, .bin）を public/ に置けば、外部送信なしで完結

---

制約適合性（再確認）

制約	エッジAI組込み後
1. Windows 11	✅ ブラウザ内動作のためOS非依存
2. Google Workspace のみ	✅ 外部AIサービス不使用
3. Gemini API キー不可	✅ クラウドLLM一切不要
4. ファイルサーバーなし	✅ モデルもブラウザに同梱
5. ファイル共有 Google Drive のみ	✅ HTML+モデルを単一ファイル化して Drive 共有可
6. 外部データ送信不可	✅ これがエッジAI最大の利点
7. JSON/CSV 優先	✅ 既存CSVをそのまま学習・推論データに使用可

結論：制約6（外部送信不可）と制約3（Gemini不可）を満たすうえで、エッジAIは "選択肢" ではなく "唯一解" です。

---

推奨：最初の組込みステップ

最小コスト・最大効果の順に：

Step 1（1〜2時間）： simple-statistics で不具合の異常検知

• 例：日次の不具合発生数の Z-score を計算 → 閾値超過で QualityAlertDashboard にアラート表示

Step 2（半日）： ml-cart で重大度予測

• 既存不具合の severity をラベル、subsystem/function_name/injected_phase を特徴量として学習
• 新規不具合入力時に severity を自動推定

Step 3（1日）： 信頼度成長モデルで出荷判定

• ShippingJudgmentPanel に Goel-Okumoto モデルの信頼度予測を追加

Step 4（2〜3日）： ONNX Runtime Web で本格モデル

• 過去案件データから学習した分類モデル（.onnx）を public/model.onnx に配置
• ブラウザ起動時にロード → 推論

---

組み込みを始めるなら、Step 1（異常検知）から着手するのが投資対効果最大です。ご希望があれば、QualityAlertDashboard.tsx への異常検知ロジック追加から実装開始します。どうしますか？

ご指摘の通り、エッジAIを効果的に動かすにはデータの整理が不可欠です。現状の CSV/型定義がどこまで揃っているか、また11カテゴリのうち何が不足しているかを正確に把握するため、まずコードベースを調査します。

調査完了しました。判明した状況：

11カテゴリのうち：

• ✅ 整備済み 7件：工程定義、サブシステム構成、機能構成、開発規模、テスト項目数、バグ管理、レビュー記録
• ⚠️ 部分的 2件：工程別進捗（テスト工程のみ）、工程別品質（閾値のみで履歴データなし）
• ❌ 完全に欠落 2件：要員情報、要員稼働情報

エッジAIを実装する前に、欠落している情報の追加と既存データの正規化が必要です。プランを書く前に、スコープを確認させてください。

ご回答を踏まえて、最後に既存の aggregate.ts と型定義を確認してから計画書を書きます。

計画書を作成します。

エッジAI（Edge AI）とは

一言で

「AI 推論を、サーバー（クラウド）ではなく、エンドユーザー側のデバイス（ブラウザ・スマホ・IoT機器）で完結させる技術」 のことです。

---

通常のクラウドAI vs エッジAI

【クラウドAI】
ユーザーPC ──データ送信──→ クラウドAPI（OpenAI/Gemini等）
            ←──結果受信──
   ↑ ネット必須・データ流出リスク・APIコスト・遅延

【エッジAI】
ユーザーPC（ブラウザ内で推論完結）
   ↑ ネット不要・データ流出ゼロ・無料・即応答

比較表

観点	クラウドAI	エッジAI
推論実行場所	OpenAI/Google のサーバー	ユーザーのブラウザ/PC
ネットワーク	必須	不要
データ流出	API へ送信される	一切外に出ない
API キー	必要	不要
月額コスト	利用量課金	ゼロ
応答速度	数百ms〜数秒	数ms〜数十ms
モデル更新	自動	配布時に同梱
モデル規模	巨大（GPT-4等）	小〜中規模（数MB〜数百MB）
学習	通常は事前学習済みを使用	ブラウザ内で軽量学習も可能

---

本プロジェクトでエッジAIが必須な理由

ユーザーの制約と完全一致：

制約	エッジAIで満たせる理由
❌ Gemini API キー不可	API 自体を使わない
❌ 外部データ送信不可	ブラウザ内完結なので送信ゼロ
❌ ファイルサーバーなし	モデルも HTML に埋込み可能
✅ Google Drive のみ	HTML 1ファイル＋モデル を Drive で配布

---

エッジAIで使える「学習・推論手法」の階層

【軽量】 ─────────────────────────────────→ 【重量】

統計手法          古典機械学習         ニューラルネット      LLM
（小数MB）       （数MB〜数十MB）     （数十〜数百MB）    （数百MB〜GB）
─────────────   ─────────────────   ───────────────   ─────────
Z-score          決定木 (CART)       CNN/RNN           Phi-3
移動平均         ランダムフォレスト   TensorFlow.js      Llama-3 8B
回帰分析         XGBoost              ONNX Runtime      WebLLM
ベイズ推定       SVM                                    Transformers.js
クラスタリング   K-means

本プロジェクトに既にインストール済み：

• simple-statistics ← 統計手法（最軽量・即使える）
• ml-cart ← 決定木（古典ML）
• @tybys/wasm-util / @napi-rs/wasm-runtime ← WASM経由で重量モデルも動かせる土台

---

リスク予測へのエッジAI活用方法

「リスク予測」を品質管理の文脈で具体化すると、本プロジェクトでは以下の8種類のリスクが扱えます：

A. 将来リスクの予測（時系列予測）

#	予測対象	入力データ	手法	出力例
1	残バグ件数の予測（信頼度成長モデル）	不具合発見履歴	Goel-Okumoto / S字曲線回帰	「あと120件埋まっている見込み」
2	収束予測（いつ解決し終わるか）	バグ発見/解決ペース	移動平均＋回帰	「現ペースで6/15に収束」
3	品質劣化トレンド検知	日次バグ密度	Mann-Kendall検定 / 線形回帰	「過去10日で悪化傾向（p<0.05）」

B. 異常リスクの検知（アノマリー検知）

#	予測対象	入力データ	手法	出力例
4	品質スパイク検知	日次バグ件数	Z-score / IQR	「本日13件は通常の3.2σ超」
5	異常サブシステム検出	全サブシステムの密度	ロバスト統計	「サブシステムB が外れ値」

C. 属性リスクの分類（分類予測）

#	予測対象	入力データ	手法	出力例
6	新規バグの重大度予測	過去バグの発見工程・サブシステム・要員	決定木 (ml-cart)	「このバグは Critical の可能性 78%」
7	再発リスクの高い根本原因の予測	レビュー記録	Naive Bayes	「『仕様漏れ』が今後増える兆候」
8	出荷可否のリスクスコア	全指標の加重和	ロジスティック回帰	「出荷リスクスコア 0.73（赤）」

---

本プロジェクト向け「リスク予測」具体3シナリオ

シナリオ1：出荷判定リスク（最も実用的）

【現状】 ShippingJudgmentPanel が閾値超過の有無だけ判定
【AIで強化】
  入力: バグ密度推移、未解決Critical数、テスト消化率、信頼度成長カーブ
  処理: ロジスティック回帰 で出荷リスクスコア (0〜1) を算出
  出力: 「出荷リスク 0.73 ／ 主因：未解決Criticalの増加トレンド」

シナリオ2：サブシステム別リスクランキング（早期警報）

【現状】 RankingTable がバグ密度の単純比較
【AIで強化】
  入力: 各サブシステムの (バグ密度, 開発規模, テスト消化率, 要員稼働日数)
  処理: K-meansで「健全/警戒/危険」の3クラスタに分類
  出力: ランキングに「危険度クラスタ」をバッジ表示
       「サブシステムC は 3週連続で危険クラスタ」

シナリオ3：日次品質アラート（先回り検知）

【現状】 QualityAlertDashboard が静的な閾値ベース
【AIで強化】
  入力: 過去30日のバグ発見数の時系列
  処理: 移動平均 + Z-score で異常検知
  出力: 「本日のバグ発見15件は過去30日平均比 3.5σ超 ⚠️」
       「サブシステムD で連続3日 高水準（要調査）」

---

リスク予測のためのエッジAI処理フロー

┌──────────────────────────────────────────────────┐
│ ブラウザ（HTML 1ファイル内で完結）                  │
│                                                    │
│  CSV読込 → 集計 → 特徴量抽出 → モデル推論 → 可視化  │
│  (papaparse) (aggregate) (qualityTime  (simple-   │
│                          Series.ts)    statistics │
│                                        / ml-cart) │
│                                                    │
│  ※ 一切のデータがブラウザの外に出ない              │
└──────────────────────────────────────────────────┘

---

段階的な実装アプローチ（推奨順）

Phase	投資コスト	リスク予測効果	利用ライブラリ
Phase 1	数時間	⭐⭐⭐	simple-statistics（Z-score / 移動平均）
Phase 2	半日	⭐⭐⭐⭐	simple-statistics（信頼度成長モデル）
Phase 3	1日	⭐⭐⭐⭐	ml-cart（重大度予測の決定木）
Phase 4	2〜3日	⭐⭐⭐⭐⭐	ONNX Runtime Web（事前学習済みモデル）

---

結論

エッジAI = 「外部送信ゼロで、ブラウザ内に閉じた AI 推論」

本プロジェクトでは：

• ✅ 制約をすべて満たす唯一の AI 実装手段
• ✅ 既に必要なライブラリがインストール済み
• ✅ リスク予測の 8つの具体的ユースケース に適用可能
• ✅ 投資対効果が高いのは 出荷判定リスクスコア と 品質スパイク検知

質問の意図次第で、次に進める方向は2つあります：

1. 概念をもう少し深掘りする（具体例を1つ動くデモで見たい等）
2. リスク予測の実装プランに進む（先ほどのデータ整備プランに、Phase 1〜2 の実装も追加する）

どちらに進めますか？

エッジAI 概念の深掘り — 動く具体例で理解する

最も基本的な「Z-score による異常検知」を、実際のコードと一緒に追ってみます。これがエッジAIの最小単位の動き方です。

---

お題：「今日のバグ件数は異常か？」を判定する

ステップ1：素材データ（過去14日間の日次バグ件数）

日付         件数
05/01        3
05/02        5
05/03        4
05/04        2
05/05        6
05/06        4
05/07        5
05/08        3
05/09        4
05/10        5
05/11        4
05/12        6
05/13        3
05/14       18  ← 今日（異常か？）

人間の目には「14 はおかしい」と一目瞭然ですが、AI（統計）はこれをどう判定するかを見てみます。

---

ステップ2：エッジAIの処理（ブラウザ内 JavaScript）

import * as ss from 'simple-statistics';

// 過去14日間のデータ（今日を除く13日分）
const history = [3, 5, 4, 2, 6, 4, 5, 3, 4, 5, 4, 6, 3];
const today   = 18;

// ---- ① 統計量を計算 ----
const mean = ss.mean(history);                  // 平均
const std  = ss.standardDeviation(history);     // 標準偏差

// ---- ② Z-score を計算 ----
const z = (today - mean) / std;

// ---- ③ 閾値で判定 ----
if (Math.abs(z) >= 3) console.log('🚨 重大異常');
else if (Math.abs(z) >= 2) console.log('⚠️ 注意');
else console.log('✅ 正常');

---

ステップ3：結果

平均 = 4.15
標準偏差 = 1.21
Z-score = (18 - 4.15) / 1.21 = 11.4

判定: 🚨 重大異常（11.4σ 超）

何が起きたか：

ブラウザ内で、外部APIを一切呼ばずに、「今日の値は通常の 11.4 倍以上ばらついている」と AI（統計モデル）が判定しました。

これがエッジAIの本質です — 数学的なモデル（ここでは正規分布の仮定）を使い、ブラウザ内で完結した推論を行う。

---

視覚化するとこうなる

件数
20 ┤                                      ★ ←今日(18)
18 ┤                                      │
16 ┤                                      │
14 ┤                                      │
12 ┤                                      │
10 ┤
 8 ┤    ┌─ 平均+3σ (7.78) ───────────────│──┐ 異常領域
 6 ┤●     ●           ●                  │
 5 ┤  ●     ●  ●     ●  ●                │
 4 ┤    ●         ●   ●     ●  ●         │
 3 ┤●         ●           ●           ●  │
 2 ┤      ●                              │
 0 ┴──────────────────────────────────────┴─
   05/01            05/07           05/14

過去13日のデータから「±3σ の正常範囲」を学習し、今日の値がそれを大きく超えたので異常判定。

---

ここで起きていることを「AI らしく」言い換える

一般的なAI用語	このコード内では
学習（training）	mean(history) と standardDeviation(history) の計算
モデル	mean=4.15, std=1.21 という2つの数値
推論（inference）	(today - mean) / std の計算
推論結果	Z-score = 11.4
閾値判定	Math.abs(z) >= 3
学習データ	過去13日分の件数配列
説明可能性	「平均より11.4σ上だから異常」と即座に説明可

つまり「AI = 巨大NN」ではなく、「データから自動で判断ルールを作る数学モデル」全般がAIの本質です。エッジAIはその中で 「ユーザー側で完結するもの」 を指します。

---

より進んだエッジAIの例（同じくブラウザ内完結）

例A：移動平均でトレンド検知

// 過去7日の移動平均を計算
const ma7 = ss.mean(history.slice(-7));
const ma14 = ss.mean(history.slice(-14));

if (ma7 > ma14 * 1.3) console.log('📈 悪化トレンド');

例B：決定木で重大度予測（ml-cart）

import { DecisionTreeClassifier } from 'ml-cart';

// ---- 過去のバグ事例を「学習」----
const X = [
  // [サブシステムID, 発見工程ID, 担当者経験年数]
  [0, 4, 2],   // システムテスト・新人
  [0, 2, 5],   // 基本設計・ベテラン
  [1, 4, 1],   // ...
];
const y = ['Critical', 'Low', 'Critical', 'Medium', ...];

const clf = new DecisionTreeClassifier();
clf.train(X, y);

// ---- 新しいバグの重大度を「予測」----
const newBug = [0, 4, 1];  // システムテスト・新人
console.log(clf.predict([newBug]));  // → ['Critical']

これも全てブラウザ内・データ送信ゼロ。

例C：信頼度成長モデル（Goel-Okumoto）

// 「累計バグ発見曲線」をS字カーブにフィッティング
// → 残存バグ数を予測
function goelOkumoto(t, a, b) {
  return a * (1 - Math.exp(-b * t));
}

// 観測データから a, b をフィッティング（最小二乗法）
// → a が「総バグ数の予測値」、現時点までに見つけた数を引けば「残バグ数」

---

このプロジェクトの既存パッケージで何ができるか（再整理）

パッケージ	できること	具体例
simple-statistics	統計推論全般	Z-score / 移動平均 / 線形回帰 / 相関 / 分位数
ml-cart	決定木による分類・回帰	重大度予測 / 担当者リスク予測
@tybys/wasm-util 等	WASM 経由で他言語モデル実行	Rust/C++製 推論エンジン

---

エッジAIで「やってはいけないこと」

❌ NG	理由
数百MBのモデルを HTML に埋込む	起動が遅すぎる
ブラウザ内で巨大データの学習	メモリ枯渇・タブ凍結
学習データをサーバーに送る	エッジAIの定義から逸脱
過学習した小モデルで判定	データが少ないと統計の前提が崩れる

→ 適材適所で、「軽量モデル」「ブラウザ内推論」「外部送信なし」 の3条件を守るのがコツ。

---

まとめ

• エッジAI = ブラウザ/PC内で完結するAI推論
• 巨大NNでなく、統計手法や軽量MLも含む広い概念
• 上記の Z-score の例は 5行のコードで動く本物のエッジAI
• 説明可能・高速・無料・データ流出なし
• 本プロジェクトの制約（外部送信不可・APIキー不可）に対する 唯一解

---

次のステップ候補

1. このZ-scoreの例を実際にブラウザで動かして見る（5分で実装可能）
2. 「リスク予測」に話を戻して、データ整備＋AI実装プランを進める
3. 別のエッジAI技法（決定木 / 信頼度成長モデル）も同様に深掘りする

どれにしますか？

Python の python-pptx でパワーポイントを生成します。まず環境を確認します。

パワーポイント生成完了しました。

出力ファイル: edge-ai-explained.pptx（60KB / 11 スライド）

スライド構成:

#	タイトル	主な図解
1	エッジAI 入門（表紙）	プロジェクト概要・制約
2	エッジAIとは — 一言で	定義 + 3つのキーワードカード
3	クラウドAI vs エッジAI	データフロー比較図（双方向矢印 vs 内包構造）
4	詳細比較表	8項目の比較テーブル（赤/緑色分け）
5	制約適合性	7制約 → エッジAI回答の対応表
6	インストール済みライブラリ	軽量→重量の階層図 + パッケージ表
7	Z-score 異常検知の流れ	4ステップフロー + 計算結果
8	Z-score 視覚化	14日分の折れ線グラフ + 異常閾値線
9	リスク予測 8ユースケース	A/B/C カテゴリ別の表
10	リスク予測 3シナリオ	現状→AI後 の変化図 × 3
11	まとめ + ロードマップ	Phase 0〜4 の段階的計画

デザイン:

• ダークテーマ（深紺背景 + 紫アクセント）
• 全スライド共通のタイトルバー + ページ番号
• 図形（矢印・角丸ボックス）と実データグラフを組み合わせ

開く方法:

start C:\Content_Factory\P0600_MART\wf-quality-prototype4\docs\edge-ai-explained.pptx

スライドの内容や配色を調整したい場合は、build_edge_ai_ppt.py を編集して再実行すれば反映されます。

Z-score（標準得点）とは

一言で

「ある値が、平均から標準偏差の何倍ぶん離れているか」を表す数値

「σ（シグマ）何個ぶん離れている？」を計算したものです。

---

計算式（とてもシンプル）

        観測値 − 平均
Z =  ────────────────
         標準偏差

例：

• 平均 = 4.15
• 標準偏差 = 1.21
• 観測値（今日の値）= 18

Z = (18 − 4.15) / 1.21 = 11.4

→「今日の値は、平均から σの11.4倍 離れている」

---

何のために使うのか

異なる単位・スケールのデータを「揃えて比較」するため

例	元の値	Z-score	意味
身長 175cm（平均170, σ5）	175cm	+1.0	平均より少し高い
体重 80kg（平均70, σ10）	80kg	+1.0	平均より少し重い

→ 単位が違っても 「Zが1.0」 = 同じくらい平均から離れている と比較できる。

---

Z-scoreが大きいほど「珍しい」

Z-score の大きさは「珍しさ」の指標です。正規分布を仮定すると：

\	Z\	の値	範囲内に収まる確率	はみ出る確率（珍しさ）	判定
1σ 以内	約 68%	32%	普通
2σ 以内	約 95%	5%	やや珍しい
3σ 以内	約 99.7%	0.3%	★異常の境界★
4σ 以内	99.994%	0.006%	かなり異常
6σ 以内	99.9999998%	ほぼゼロ	極めて異常

つまり Z = 11.4 は「正規分布で起きる確率が事実上ゼロ」 → 明らかに異常と機械的に判定できる。

---

視覚的に理解する

          正規分布（ベルカーブ）
            ／￣￣￣＼
           ／  68%   ＼       ← ±1σ 内
          ／   95%    ＼      ← ±2σ 内
         ／   99.7%    ＼     ← ±3σ 内
       ／                ＼
   ─────┼─────┼─────┼─────┼─────┼─────
       -3σ   -2σ   -1σ  平均  +1σ   +2σ   +3σ  ……  +11.4σ
                                                       ↑
                                                    今日の値
                                              （ここまで離れている）

---

「機械学習」との関係

Z-score は最も基本的な 教師なしの異常検知手法です：

• 学習 = 過去のデータから 平均と標準偏差を計算する
• モデル = mean=4.15, std=1.21 という2つの数値
• 推論 = 新しい値を (x - mean) / std で変換
• 判定 = |Z| ≥ 3 なら異常

→ ニューラルネットも複雑な数式も使わない、最も軽量な「学習＋推論」のサイクル。

---

強みと弱み

✅ 強み

• 超軽量（5行のコードで動く）
• 解釈しやすい（「3σ超えたから異常」と即説明可能）
• 学習データが少なくても機能する（30件ほどあれば十分）
• ブラウザ内で瞬時に計算できる → エッジAIに最適

⚠️ 弱み

• 正規分布を仮定している（極端に偏ったデータには不向き）
• 外れ値に引っ張られる（過去データに既に異常値があると平均/標準偏差が歪む）
• トレンドや季節性は捉えない（時系列の傾きには対応しない）
• → 改善版として 修正Z-score（中央値ベース） や MAD法 がある

---

本プロジェクトでの応用例

適用先	データ	Z-scoreの使い方
日次バグ件数の異常検知	過去30日のバグ件数	今日のZが3超ならアラート
サブシステム別の異常検出	全サブシステムのバグ密度	Zが2超のサブシステムを「警戒」表示
要員別レビュー指摘数の偏り検出	各レビュアの指摘数	Z<-2の人は「見落とし疑い」
テスト消化ペースの異常	日次テスト消化件数	Z<-2なら「進捗遅延の兆候」

---

簡単な数値例（手計算してみる）

データ：[3, 5, 4, 2, 6]

ステップ1: 平均 = (3+5+4+2+6) / 5 = 4.0
ステップ2: 偏差 = [-1, 1, 0, -2, 2]
ステップ3: 偏差² = [1, 1, 0, 4, 4]
ステップ4: 分散 = (1+1+0+4+4) / 5 = 2.0
ステップ5: 標準偏差 = √2.0 ≈ 1.41

新しい値 = 8 のZ-scoreは？
   Z = (8 - 4.0) / 1.41 = 2.83

→「平均から2.83σ離れている」 → やや異常レベル

---

まとめ

• Z-score = (値 - 平均) ÷ 標準偏差
• 「平均から何σ離れているか」を数値化
• |Z| ≥ 3 で「統計的に異常」とみなすのが慣例
• 計算が極めて単純（足し算・引き算・割り算だけ）
• だからエッジAI（ブラウザ内推論）に最適
• 異常検知の 最初の一歩 として標準的な手法

「σ5」の読み方

基本の読み方

「シグマ ご」 または 「シグマ ファイブ」 と読みます。

ただし、文脈によって読み方が変わります。

---

文脈別の読み方

① 統計用語として「σ=5」「標準偏差が5」を意味する場合

σ = 5

読み：「シグマ いこーる ご」 / 「ひょうじゅんへんさ ご」

意味：標準偏差の値が「5」である、ということ。

例：先ほどの説明で「平均170, σ5」と書いた箇所 → 「シグマ ご」（標準偏差が 5cm の意）

---

② 「5σ」「5シグマ」と書く場合（順序が逆）

5σ

読み：「ご シグマ」 / 「ファイブ シグマ」

意味：「平均から標準偏差の5倍ぶん離れている」という距離・基準を表す。

例：「3σ ルール」=「さん シグマ ルール」（±3標準偏差以内に約99.7%が収まる）

---

表記の使い分け（重要）

表記	読み方	意味
σ = 5	シグマ いこーる ご	標準偏差の値が5
5σ	ご シグマ	標準偏差の5倍ぶん
σ5	シグマ ご（曖昧）	文脈で判断（通常は前者）
±3σ	プラスマイナス さんシグマ	標準偏差の3倍の範囲

---

ビジネス/品質管理でよく使う「○σ」表現

表記	読み方	意味
3σ	さん シグマ	99.7% が収まる範囲（一般品質基準）
6σ（シックス・シグマ）	ろく シグマ／シックス・シグマ	100万回中3.4回しか不良が出ない高品質基準（製造業の有名な改善手法）
5σ発見	ごシグマ はっけん	物理学で「新発見」の信頼基準（例：ヒッグス粒子の発見）

---

Σ（大文字シグマ）との違い

記号	読み方	意味
σ（小文字）	シグマ	標準偏差 / 1個の値の散らばり
Σ（大文字）	シグマ（同じ読み）	総和（足し算）の記号

例：Σx =「シグマ えっくす」=「xを全部足す」

---

先ほどの説明文中での読み方

> 「身長 175cm（平均170, σ5）」

→ 「シグマ ご」 と読みます。

意味：「標準偏差が5cm」=「人々の身長は平均170cmを中心に、おおよそ±5cmの範囲にばらついている」

> 「Z = 11.4σ」

→ 「ぜっと いこーる じゅういってんよん シグマ」

意味：「平均から標準偏差の11.4倍ぶん離れている」

---

まとめ

• σ = シグマ（標準偏差を表すギリシャ文字）
• σ5 は通常「シグマ ご」と読み、「標準偏差の値が5」を意味
• 5σ は「ご シグマ」と読み、「標準偏差の5倍の距離」を意味
• 順序で意味が変わるので、文脈に注意

「平均から標準偏差の11.4倍ぶん離れている」の意味

まずキーワード「標準偏差」を理解する

標準偏差 (σ) = データのばらつき度合い（散らばり）を1つの数値にしたもの

例で理解する

過去13日間のバグ件数：

3, 5, 4, 2, 6, 4, 5, 3, 4, 5, 4, 6, 3

ここから計算すると：

• 平均 = 4.15 （だいたい毎日4件くらい）
• 標準偏差 σ = 1.21 （平均から ±1.21件くらいの範囲で日々ばらつく）

つまり「毎日 4.15件 ± 1.21件くらいの範囲に収まる」のがいつもの状態。

---

視覚的に「いつもの範囲」を見る

  バグ件数
   8 │
   7 │
   6 │ ●           ●           ●
   5 │   ●     ●     ●   ●
   4 │     ●     ●     ●     ●     ●  ← 平均 4.15
   3 │ ●         ●           ●         ●
   2 │     ●
   1 │
   0 ┴────────────────────────────────
      05/01           05/07         05/13
                                    
   [平均 4.15]  ← 中心線
   [σ = 1.21]  ← この幅でいつもばらついている

   いつもの範囲（±1σ）   = 2.94 〜 5.36
   ちょっと広めの範囲(±2σ) = 1.73 〜 6.57
   かなり広めの範囲(±3σ) = 0.52 〜 7.78  ← ここを超えたら異常

---

「σの何倍離れているか」を測る

「いつものばらつき（σ）」を 物差し にして、「今日の値はどのくらい遠くにあるか」を測ります。

今日の値 = 18

平均からの距離 = 18 - 4.15 = 13.85件

これは σ（=1.21）の何倍？
        ↓
  13.85 ÷ 1.21 = 11.4倍

→ 「標準偏差の11.4倍ぶん離れている」=「いつものばらつき幅 (1.21) の 11.4 倍も遠くにある」

---

物差しに例えた図解

基準幅（σ = 1.21）を 1メモリ とする物差し
                                                          
  ├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤ → 今日の値 (18)
  0  1  2  3  4  5  6  7  8  9 10 11 11.4
  ↑ 平均(4.15)                          
                                                          
  「いつもの幅(σ)を11.4個ぶん離れた場所」にある

ものさしの 1メモリ = 1.21件分のずれ。今日の値はそこから 11.4メモリも離れている、ということ。

---

「いつものばらつき」と比べてどれくらい異常か

Z-score	意味	起こる頻度（正規分布）
1σ	いつもの範囲内	3日に2回（68%）
2σ	やや珍しい	20日に1回（5%）
3σ	異常の境界	370日に1回（0.3%）
4σ	かなり異常	約16,000日に1回
6σ	極めて異常	約5億日に1回
11.4σ	天文学的に異常	宇宙の年齢でも起きないレベル

Z=11.4σ は、もはや「偶然のばらつき」では絶対に起きない値 ということ。

→ 必ず何か原因がある（バグ多発、機能リリースの問題、データ入力ミスなど）

---

別の例で理解：身長で考える

状況	値	計算	結論
平均170cm, σ=5 の集団	175cm	(175-170)/5 = 1σ	平均より少し高め（普通）
同上	180cm	(180-170)/5 = 2σ	上位2.5%（やや高い）
同上	185cm	(185-170)/5 = 3σ	上位0.15%（かなり高い）
同上	200cm	(200-170)/5 = 6σ	NBA選手レベル（超異常値）
同上	227cm	(227-170)/5 = 11.4σ	歴史上 数人レベル

Z=11.4σ は、「身長227cm の人を見つけた」と同じくらいあり得ない値。

---

バグ件数で言い換えると

「毎日4件くらいしか出ないシステムで、突然18件出た」というのは：

• 普段の感覚： 「今日は2〜6件かな」
• 実際： 「18件」
• ばらつき(σ=1.21) の 11.4 倍もズレている
• 偶然では絶対に起きないレベル
• → 何か重大な問題が発生していると機械的に断言できる

---

まとめ

「平均から標準偏差の11.4倍ぶん離れている」とは：

1. 「いつものばらつき幅 (σ)」を物差しにして測ったとき
2. その物差し11.4個ぶんも遠くにあるということ
3. = 統計的に「ありえない値」
4. = 異常（必ず何か原因がある）

この「σを物差しにして遠さを測る」という考え方が Z-score の本質 です。Z-score = いつもの幅から何倍離れているか、をひと目で示す指標。

基準となる標準偏差値

結論：固定の「絶対基準」はなく、データから毎回計算します。

ただし、何σを「異常」とみなすかの閾値（しきい値）には、業界標準のいくつかの基準があります。

---

大切な区別

用語	意味	値
標準偏差 σ の値	データのばらつき幅	データごとに変わる（バグ件数なら 1.21、身長なら 5cm 等）
Zの判定閾値	「何σ超えたら異常とするか」	基準値あり（2σ, 3σ, 6σ 等）

質問の「基準となる標準偏差値」は 後者（判定閾値） のことだと理解して回答します。

---

業界別の標準的な「異常判定閾値」

① 一般的な統計・品質管理

閾値	名称	用途	異常確率
±2σ	警戒線（warning）	早期警報・要注意	5%
±3σ	管理限界（最も標準）	異常検知の事実上のデフォルト	0.3%
±2.7σ	NIST推奨	機械学習の異常検知	約 0.7%

② 製造業・QC（品質管理）

閾値	名称	出典
±3σ	シューハート管理図（CCC）	統計的工程管理（SPC）の世界標準
±2σ	注意限界	上位ライン
6σ（シックス・シグマ）	不良率 3.4PPM	モトローラ発祥、GE が世界に普及

③ 物理学・科学研究

閾値	用途
3σ	"evidence"（証拠）レベル
5σ	新発見の公式基準（ヒッグス粒子の発見など）

④ 金融・リスク管理

閾値	用途
2σ（95%信頼区間）	VaR（バリュー・アット・リスク）標準
2.33σ（99%）	厳しめのVaR

---

本プロジェクト（品質ダッシュボード）での推奨基準

ソフトウェア品質管理の文脈では、3σルール が事実上の標準です。

Zの絶対値	判定	表示色	アクション
\	Z\	< 2	正常	🟢 緑	通常監視
**2 ≤ \	Z\	< 3**	警戒	🟡 黄	担当者に注意喚起
**\	Z\	≥ 3**	異常	🔴 赤	即時アラート・原因調査
\	Z\	≥ 6	重大異常	⚫ 黒	システム停止級・要緊急対応

> 先ほどの例「Z = 11.4σ」は 赤を遥かに超える非常事態レベル に該当。

---

なぜ「3σ」が標準なのか

正規分布で「±3σ以内に 99.73% が収まる」性質から：

全データの分布
                 ┌─────────────┐
                 │   99.73%    │
                 │  (±3σ内)     │
                 │             │
       ←0.135%─→│             │←─0.135%→
   ────────────┴─────────────┴────────────
              -3σ            +3σ

  → 「±3σ を超えたら、起きる確率 0.27%」
  → 1000日に約3回しか起きない
  → 「滅多に起きない＝異常」と判定して妥当

→ 「1000回に1〜3回しか起きない事象」を「異常」と定義するのが、人間の感覚にも合致するため業界標準になった。

---

注意：基準は「データの性質」で調整すべき

固定で 3σ にするのが万能ではありません：

データの性質	推奨閾値	理由
正規分布に近い（多数のサンプル）	±3σ	標準ルールが有効
偏った分布（バグ件数のように下限0で右に裾が長い）	±2σ または 修正Z-score	通常の3σでは検知できないことがある
サンプル数が少ない（30件未満）	±2σ	σ自体が不安定
ノイズが多い（例：センサーデータ）	±4σ	誤検知を減らす
安全性が極めて重要（医療・原子力）	±2σ または事象確認の二段構え	見逃しを避ける
ビッグデータ（数百万件）	±5σ または ±6σ	データ量が多いと3σ超もよく起きる

---

本プロジェクトの「バグ件数データ」での具体的推奨

バグ件数は「下限0で右に裾が長い分布」になることが多いため、以下の二段構えを推奨：

Phase 1（最初の実装）：
  - シンプルな ±3σ ルール
  - 異常判定ロジックが分かりやすい
  - 既存の ml-cart や simple-statistics で実装容易

Phase 2（精度向上）：
  - 修正Z-score（中央値 + MAD ベース）に変更
  - 過去の異常値が平均/標準偏差を歪める問題を回避
  - simple-statistics の medianAbsoluteDeviation を使用

修正Z-score（参考）：

import * as ss from 'simple-statistics';

const median = ss.median(history);
const mad = ss.medianAbsoluteDeviation(history);
const modifiedZ = 0.6745 * (today - median) / mad;

if (Math.abs(modifiedZ) >= 3.5) console.log('🚨 異常');

---

設定可能な閾値（実装イメージ）

AppConfig.ts のような設定ファイルで切り替え可能にしておくのがベスト：

export const ANOMALY_THRESHOLDS = {
  warning: 2.0,    // 警戒（黄）
  critical: 3.0,   // 異常（赤）
  severe: 6.0,     // 重大異常（黒）
};

→ 運用しながら現場感覚と合うように調整できる。

---

まとめ

質問	答え
標準偏差σ自体の固定基準値は？	なし（データから毎回計算）
「異常」とみなすZの閾値は？	±3σ が業界標準
警戒レベルは？	±2σ
重大異常は？	±5σ または 6σ
本プロジェクトでの推奨	3σ から開始、後に修正Z-score へ移行

要するに「3σルール」を覚えておけば 9 割の場面で困りません。残り1割（特殊なデータ分布や高精度が必要な場面）で別の手法に切り替える、というのが実務の流れです。

白系背景に変更し、統計初心者向けのAppendixを追加した新版を生成します。スクリプト全体を書き直します。

ファイルが PowerPoint で開かれているため書き込めません。別名で出力します。

パワーポイント更新完了しました（89KB / 全 22 スライド）。

出力: edge-ai-explained.pptx

主な変更点

① 全スライドを白系背景に刷新

• 背景: 白 / 紙の色（#FFFFFF）
• ボックス背景: 極淡い灰（#F8FAFC / #F1F5F9）
• アクセント色は鮮やかさを保つ（紫 #7C3AED / 青 / 緑 / 赤）
• 罫線は薄灰で印刷映え重視

② Appendix（11スライド）を新規追加

統計初心者向けに、本編で出てきた概念をゼロから図解：

#	スライド	主な図解
Cover	Appendix表紙＋目次	10項目の一覧
A1	本Appendixの目的	3つの学習ポイントカード
A2	「ばらつき」とは	安定チームA vs 不安定チームB の棒グラフ比較
A3	平均 と 標準偏差σ	数式 + 数直線上の点と σ 幅の物差し
A4	σの読み方と表記	表記別の読み方表 + 大文字Σとの違い
A5	Z-scoreとは	物差しイラスト（-3σ〜+3σ） + 「今日の値」マーク
A6	Z-scoreと珍しさ	ベルカーブの段階表示 + 確率テーブル
A7	11.4σの意味	身長で例える（175cm→227cm の段階表）
A8	3σルール	99.7% を緑バー、両端の0.135% を赤バーで視覚化
A9	業界別の標準値	統計/製造/物理/金融/医療 の閾値比較
A10	プロジェクトでの推奨	Phase 1（3σ）→ Phase 2（修正Z-score）の移行図

③ 本編側にも案内追加

• スライド7（Z-score 流れ）に「※ Z-scoreの基礎を知らない方は Appendix A4〜A6 を先にご覧ください」と一行追加
• ページ番号表示を「X / 21」形式に統一

開く方法:

start C:\Content_Factory\P0600_MART\wf-quality-prototype4\docs\edge-ai-explained.pptx

ブラウザで動く対話式デモを単一HTMLファイルで作成します（CDN不使用・完全自己完結）。

エッジAIライブデモを単一HTMLファイルで作成しました（16KB / 完全自己完結）。

ファイル: zscore-demo.html

開く方法

start C:\Content_Factory\P0600_MART\wf-quality-prototype4\docs\zscore-demo.html

エクスプローラーからダブルクリックでも OK です。

このデモで体験できること

操作	リアルタイム反応
今日の値スライダー （0〜50） を動かす	Z-score・判定・グラフが即座に再計算
過去14日のデータを編集（カンマ区切り入力欄）	平均・σが再学習されて閾値線が動く
プリセットボタン：安定／不安定／完全一定／悪化トレンド	異なる「ばらつき度」で σの変化を体感

表示される要素

1. 計算結果カード — 平均 μ・標準偏差 σ・Z-score を大きく表示
2. 判定ボックス — 正常（緑）/警戒（橙）/異常（赤）/重大異常（黒）が色付きで切替
3. 計算式の展開 — 入力データから Z-score までの計算過程をすべて文字で表示
4. SVGバーチャート — 過去14日 + 今日のバー + 平均線 + ±2σ/±3σ閾値線

試してほしいシナリオ

シナリオ	操作	観察ポイント
本編の例を再現	デフォルトのまま（今日=18）	Z=11.4σ → 重大異常
平均より少し多い日	今日=7	Z≈2.4 → 警戒（黄）
通常範囲	今日=5	Z≈0.7 → 正常（緑）
プリセット「完全一定」	4が13日続く	σ=0 → どの値でもZ計算がゼロ問題（稀ケース）
プリセット「悪化トレンド」	データが右上がり	σが大きくなり、異常判定が鈍くなることを確認

エッジAIの実証ポイント

• CDN・外部APIゼロ — HTMLを file:// で開いてもネット切断状態でも完全動作
• DevToolsのNetworkタブで確認すると、リクエスト数 = HTML 1件のみ
• 計算は全てクライアント JavaScript — mean() standardDeviation() zScore() judgeAnomaly() の4関数で完結
• 反応速度 — スライダーを動かしながらリアルタイム更新（数msで完了）

これがまさに 「ブラウザ内で完結する AI 推論 = エッジAI」 の最小実証例です。

8つのエッジAIユースケース 設計解説

各機能について 「目的 → 入力 → 処理 → 出力 → UI統合先」 の順で設計します。

---

全体アーキテクチャ（共通基盤）

┌─ public/ ────────────────────────────────────────────┐
│  sample-defects.csv / sample-review-records.csv     │
│  sample-test-progress.csv / sample-scope.csv        │
│  sample-personnel.csv (新規)                        │
└──────────────────┬────────────────────────────────────┘
                   │ fetch + papaparse
                   ▼
┌─ src/quality/ (データ層) ─────────────────────────────┐
│  loadDefects.ts / loadReviewRecords.ts ...          │
│  qualityTimeSeries.ts (派生集計・新規)               │
└──────────────────┬────────────────────────────────────┘
                   │ Defect[] / ReviewRecord[] etc.
                   ▼
┌─ src/ai/ (新規・エッジAI層) ─────────────────────────┐
│  anomalyDetection.ts  (1)                           │
│  trendDetection.ts    (2)                           │
│  severityPredictor.ts (3)                           │
│  riskScoring.ts       (4)                           │
│  reliabilityGrowth.ts (5)                           │
│  rootCauseCluster.ts  (6)                           │
│  textSimilarity.ts    (7)                           │
│  reviewPatternLearn.ts(8)                           │
└──────────────────┬────────────────────────────────────┘
                   │ 推論結果（型付き）
                   ▼
┌─ src/components/ (UI層) ──────────────────────────────┐
│  既存パネルに AI 推論結果を統合                       │
└───────────────────────────────────────────────────────┘

設計原則:

• AI層は純粋関数のみ（state を持たない、入力→出力）— テストしやすい
• 既存コンポーネントを大改修しない、新規パネル追加 or 既存パネルに「AIインサイト」セクション追加
• すべて useMemo で計算結果をキャッシュ、データが変わった時だけ再推論

---

① 不具合の異常スパイク検知（Z-score / IQR）

目的

「今日のバグ件数は、過去の傾向と比べて異常か？」を機械的に判定し、見落としを防ぐ。

設計

入力データ：

type Input = {
  defects: Defect[];         // 全不具合
  windowDays: number;         // 学習に使う期間（デフォルト30日）
  targetDate: string;         // 判定対象日（デフォルト今日）
};

処理フロー：

1. defects[].opened_date を日付ごとにカウント → 日次件数の配列
2. targetDate を除く過去 windowDays 日分を「学習データ」とする
3. 平均・標準偏差を計算（simple-statistics）
4. ターゲット日の Z-score を算出
5. 同時に IQR（四分位範囲）も計算 → ロバスト判定
6. 両方の判定結果を返す（保守的に「両方ともOK」のときだけ正常）

出力型：

type AnomalyResult = {
  date: string;
  observed: number;
  mean: number;
  std: number;
  zScore: number;
  iqrBound: { lower: number; upper: number };
  judgment: 'normal' | 'warn' | 'critical' | 'severe';
  reason: string;  // 「Z=3.2σ かつ IQR上限超え」等
};

なぜ Z-score と IQR の二段判定？

• Z-score は正規分布前提 → バグ件数のような偏った分布で誤判定の可能性
• IQR（中央値ベース）は外れ値に強い
• 両方独立に異常と出たときのみ「真の異常」と扱う → 誤検知を減らす

UI統合先

QualityAlertDashboard.tsx に「AI 異常検知」セクション追加

• 過去30日の折れ線グラフに ±3σ ラインを重ねる
• 異常日にバッジ表示（赤/黄/緑）

---

② 品質劣化の早期警報（移動平均 + Trend検定）

目的

「品質がじわじわ悪化していないか？」を数値の絶対値ではなく傾きで検出。

設計

入力データ：

type Input = {
  defects: Defect[];
  testProgress: TestProgressRow[];
  recentDays: number;         // 検定対象期間（デフォルト14日）
  baselineDays: number;       // 比較基準期間（デフォルト30日）
};

処理フロー：

[A] 移動平均（短期 vs 長期のクロスオーバー検出）
    ・MA7（直近7日平均）と MA30（直近30日平均）を計算
    ・MA7 > MA30 × 1.3 → 短期悪化トレンド

[B] Mann-Kendall トレンド検定（増加・減少の単調性検定）
    ・直近14日のバグ件数の順位ペアを集計
    ・正規化された S統計量を算出（自前実装、~30行）
    ・|Z| > 1.96 (p < 0.05) なら有意な傾向あり

[C] テスト消化率とのクロス分析
    ・テスト消化が進んでいる中でバグ密度が増えている → 悪化シグナル
    ・テスト消化が止まっている中でバグが減っている → 単に休止しているだけ

出力型：

type TrendAlert = {
  movingAverage: { short: number; long: number; ratio: number };
  trendTest: { sStatistic: number; zStatistic: number; pValue: number; trend: 'up' | 'down' | 'flat' };
  context: 'genuine_deterioration' | 'normal_progress' | 'paused' | 'recovering';
  warning: string;  // 「過去14日で品質が単調に悪化（p=0.03）」等
};

なぜ Mann-Kendall？

• 正規分布を仮定しないノンパラメトリック検定 → バグ件数に向く
• 順位ベースなので外れ値に強い
• 自前実装が容易（30行程度・simple-statistics 不要）

UI統合先

QualityAlertDashboard.tsx または SecondaryAnalysisPanel.tsx に「トレンド警報」カード追加

• 矢印アイコン（↗ 悪化 / → 安定 / ↘ 改善）+ p値表示

---

③ 不具合の重大度予測（決定木）

目的

新規バグ起票時に、過去パターンから自動で重大度を提案して見落としを防ぐ。

設計

入力データ（学習用）：

type TrainingExample = {
  features: [
    subsystemId: number,      // サブシステムを数値化
    foundPhaseId: number,     // 発見工程
    injectedPhaseId: number,  // 混入工程
    rootCauseId: number,      // 根本原因
    componentLength: number,  // コンポーネント名の長さ（複雑性プロキシ）
  ];
  label: 'Critical' | 'High' | 'Medium' | 'Low';
};

処理フロー：

[A] 学習フェーズ（アプリ起動時に1回）
    ・全 defects[] を上記特徴量に変換
    ・8:2 で train/test 分割
    ・ml-cart の DecisionTreeClassifier でフィット
    ・テストデータで accuracy / confusion matrix を算出
    ・モデルを useMemo にキャッシュ

[B] 推論フェーズ（新規バグ入力時）
    ・入力 form の値を特徴量ベクトルに変換
    ・clf.predict([features]) で重大度ラベル取得
    ・clf.predictProbability で各クラスの確率も取得
    ・「Critical の可能性 78%」のように確率付きで表示

[C] 説明可能性
    ・決定木は分岐ルールが見える
    ・「このバグは『発見工程=システムテスト』かつ『サブシステム=B』なので Critical 候補」と理由を表示

出力型：

type SeverityPrediction = {
  predicted: Severity;
  probabilities: Record<Severity, number>;
  reasoning: string;        // 「発見工程=ST かつ 担当=新人 → Critical 78%」
  modelAccuracy: number;    // テストデータでの精度（信頼性表示用）
};

なぜ決定木？

• ルールが可視化できる → 「なぜそう予測したか」を人間が理解できる
• 少ないデータ（数百件）でも機能する
• ml-cart はブラウザで動く軽量実装

UI統合先

新規バグ入力モーダル（既存実装次第）または SecondaryAnalysisPanel.tsx

• 入力中にリアルタイムで「AI予測：Critical 78%」を表示
• 提案を受け入れる/無視するボタン

---

④ サブシステム別リスクスコア（線形回帰 / Naive Bayes）

目的

複数の指標（バグ密度・規模・テスト進捗等）を1つのスコアに集約してランキングと比較を容易に。

設計

入力データ：

type SubsystemFeatures = {
  subsystem: string;
  bugDensityPerKloc: number;
  criticalOpenCount: number;
  testExecutionRate: number;     // 0-1
  reviewIndentRate: number;      // レビュー指摘率
  developmentSizeKloc: number;
  daysWithoutBugClose: number;   // 解決ペースの遅延
};

処理フロー：

[A] アプローチ1: 重み付き線形結合（最もシンプル）
    score = w1 * bugDensity + w2 * criticalOpen - w3 * testRate + ...
    ・初期重みは経験則で設定（AppConfig.tsで調整可能に）
    ・simple-statistics の sampleStandardDeviation で各指標を z-score 化してから加重

[B] アプローチ2: Naive Bayes（出荷可否ラベル付きデータがある場合）
    ・過去案件の「出荷可否（OK/NG）」を教師データとする
    ・各特徴量の事前確率・条件付き確率を学習
    ・新規サブシステムに対し P(NG | features) を出力

[C] アプローチ3: ロジスティック回帰（最も精度高い）
    ・出力を 0〜1 の確率として解釈可能
    ・simple-statistics には未実装 → 自前で勾配降下法（~50行）

出力型：

type SubsystemRisk = {
  subsystem: string;
  riskScore: number;       // 0-1（または 0-100）
  cluster: 'healthy' | 'warning' | 'danger';
  topContributors: Array<{ feature: string; weight: number }>;  // 寄与度TOP3
};

最初は線形結合から始めるのが推奨：

• 重みが手動で説明できる
• 教師データ不要
• 後でロジスティック回帰に置き換え可能（API互換）

UI統合先

RankingTable.tsx に「リスクスコア」列を追加

• 0-100 のバー表示 + 色分け（緑/黄/赤）
• 行クリックで「寄与度TOP3」モーダル表示

---

⑤ 出荷判定支援（信頼度成長モデル）

目的

「残バグはあと何件あるか？いつ収束するか？」を予測。出荷の Go/No-Go 判断材料に。

設計

入力データ：

type Input = {
  defects: Defect[];
  startDate: string;      // テスト工程の開始日
  asOfDate: string;       // 判定基準日
};

処理フロー：

[A] 累積バグ発見曲線の構築
    ・テスト開始日からの経過日 t と、その日までに発見された累計バグ数 N(t) のペアを生成

[B] Goel-Okumoto モデルへのフィッティング
    モデル式: N(t) = a × (1 − exp(−b × t))
    ・a = 総バグ数の予測値（最終的に何件出るか）
    ・b = バグ発見率（収束の速さ）
    ・最小二乗法で a, b を求める（自前で勾配降下、~40行）

[C] 残バグ数 = a − N(現在)
    ・「あと120件埋まっている見込み」と表示
    ・95%信頼区間も提示（ブートストラップ法で）

[D] 収束日予測
    ・95% 検出に達する日 t = -ln(0.05)/b ≈ 3/b
    ・「現ペースで6/15に95%収束」と表示

[E] 出荷判定スコア
    ・残バグ予測数 < 閾値 AND 収束日 < 出荷予定日 → 「Go」
    ・それ以外は「No-Go」+ 理由

出力型：

type ShippingPrediction = {
  modelParams: { a: number; b: number };
  totalBugsPredicted: number;
  remainingBugs: number;
  remainingBugsCI95: { lower: number; upper: number };
  convergenceDate: string;
  judgment: 'go' | 'caution' | 'no_go';
  reasoning: string;
};

なぜ Goel-Okumoto？

• ソフトウェア信頼度モデルの古典・業界標準
• パラメータ2つだけ → 少ないデータでも安定
• 物理的に意味がある（a=総数, b=発見率）→ 説明しやすい

UI統合先

ShippingJudgmentPanel.tsx をAI予測値で強化

• S字曲線とフィット結果をチャートで表示
• 「あと N 件 / 収束日 D」のサマリーカード

---

⑥ 根本原因クラスタリング（K-means）

目的

類似する根本原因を自動でグルーピングし、抜本対策の対象を浮き彫りにする。

設計

入力データ：

type Input = {
  defects: Defect[];
  k: number;  // クラスタ数（デフォルト3、エルボー法で自動決定も可）
};

処理フロー：

[A] 各 root_cause_category について以下の特徴量ベクトルを構築
    [
      発生頻度（件数）,
      平均解決日数,
      Critical率,
      影響サブシステム数,
      影響工程数（混入→発見の幅）,
    ]

[B] 各特徴量を z-score 化（normalize）

[C] K-means クラスタリング（自前実装 ~80行 or simple-statistics）
    ・初期重心: K-means++（外れ値耐性）
    ・収束判定: 重心変動が閾値以下 or max iteration 到達

[D] クラスタへのラベル付け（重心の特徴から自動命名）
    ・「頻発・低重大度クラスタ」「希少・高影響クラスタ」「中位安定クラスタ」等

[E] エルボー法で最適 k 自動推定
    ・k=2,3,4,5 で総距離 SSE を計算
    ・SSEの減少率が緩やかになる k を採用

出力型：

type RootCauseCluster = {
  clusterId: number;
  label: string;             // 自動命名 or 手動命名
  members: string[];         // root_cause_category 名のリスト
  centroid: number[];        // 特徴量空間での重心
  characteristics: string;   // 「頻発するが影響軽微」等
};

UI統合先

新規パネル RootCauseClusterPanel.tsx または SecondaryAnalysisPanel.tsx

• バブルチャート（X=頻度, Y=Critical率, 色=クラスタ）
• クラスタごとの「対策優先度」テーブル

---

⑦ テキスト類似不具合の検出（TF-IDF + コサイン類似度）

目的

重複起票の防止と類似障害の横展開。新規バグタイトルを入力した瞬間に「似たバグが過去にあります」と提示。

設計

入力データ：

type Input = {
  defects: Defect[];
  queryText: string;       // 新規バグのタイトル
  topK: number;            // 上位何件返すか（デフォルト5）
};

処理フロー：

[A] 前処理（日本語対応）
    ・全角→半角統一、記号除去
    ・簡易トークナイザ（n-gram バイグラム/トライグラム）
      ※ MeCab等の形態素解析は重い → 文字n-gramで代替
    ・例: "ログイン失敗" → ["ログ", "グイ", "イン", "ン失", "失敗"]

[B] TF-IDF ベクトル化（自前実装 ~60行）
    ・全 defects[].title をコーパスとする
    ・Term Frequency × Inverse Document Frequency
    ・各 doc を疎ベクトルに変換

[C] クエリのベクトル化
    ・queryText を同じ前処理＋TF-IDF
    ・同じ次元（語彙数）の疎ベクトル

[D] コサイン類似度を全 doc と計算
    cos(q, d) = (q · d) / (||q|| × ||d||)

[E] 類似度上位 K 件を返す
    ・閾値以下（例: 0.3未満）はカット
    ・bug_id, title, similarity, status を返す

出力型：

type SimilarBug = {
  bug_id: string;
  title: string;
  similarity: number;        // 0-1
  status: DefectStatus;
  resolvedDate: string;      // 既に解決済みなら参考になる
};

なぜ自前実装？

• natural などのライブラリは英語前提が多い
• 文字 n-gram + TF-IDF は日本語にも有効で、軽量
• 数百件規模なら全文字数 × クエリで O(N × M)、ブラウザで瞬時

UI統合先

新規バグ入力モーダルにリアルタイム検索バー風UI

• 入力するごとに類似バグTOP5を表示
• クリックで該当バグの詳細表示

---

⑧ レビュー指摘パターン学習（決定木）

目的

「誰がレビュアの時、どこにどんな指摘が出やすいか」を学習し、レビューチェックリストの自動生成や指摘漏れの予兆検知に使う。

設計

入力データ：

type Input = {
  reviewRecords: ReviewRecord[];
  defects: Defect[];           // レビュー後に発見されたバグとの突き合わせ
};

処理フロー：

[A] 特徴量設計（review_record ごと）
    [
      reviewerId（数値化）,
      revieweeId,
      phaseId,
      subsystemId,
      documentPages,
      findingType（重大/軽微/提案）,
    ]
    ラベル: 「該当レビューの後にバグが発見されたか（Yes/No）」
            （レビュー対象のサブシステム×機能で時系列で突合）

[B] 決定木による学習
    ・ml-cart の DecisionTreeClassifier
    ・ラベル: バグ漏れあり / なし

[C] パターン抽出（決定木の経路を可視化）
    ・「レビュアA × 詳細設計フェーズ × 30ページ超 → バグ漏れ率72%」
    ・このルールを「指摘漏れリスクの高いパターン」として抽出

[D] 新規レビュー入力時のリアルタイム警告
    ・指摘ゼロのレビューに対して「過去パターンでは類似条件で平均3件指摘がある」と警告

出力型：

type ReviewPattern = {
  rules: Array<{
    condition: string;          // 「レビュアA AND 30ページ超」
    leakageRate: number;        // バグ漏れ確率
    confidence: number;         // ルールの信頼度（サンプル数ベース）
  }>;
  currentReviewWarning?: string;  // 「指摘漏れ可能性が高い」等
};

UI統合先

新規パネル ReviewPatternPanel.tsx

• ルール一覧テーブル（漏れ率の降順）
• レビュー入力フォームに「警告アイコン」表示

---

開発の優先順位（推奨）

優先度	機能	理由
★★★	① 異常スパイク検知	最も簡単・即効性あり・他の基盤になる
★★★	⑤ 出荷判定支援	経営判断に直結・差別化要素
★★	② 品質劣化早期警報	①の発展形・段階的に追加可能
★★	⑦ 類似不具合検出	運用効率改善・即体感できる
★★	④ リスクスコア	UI改善（既存ランキングを強化）
★	③ 重大度予測	データ量が必要・誤予測リスク
★	⑥ 根本原因クラスタ	分析向け・運用での即効性は中
★	⑧ レビュー指摘パターン	データの突合せが複雑・最後でよい

---

共通設計ルール

ルール	理由
AI関数は純粋関数	テスト容易性、再利用性
すべての入力に窓サイズ・閾値を引数化	運用しながら調整可能
出力に confidence / reasoning を含める	説明可能性（ユーザーに「なぜ」を伝える）
学習データ < 30件のときは AI 無効化	統計的に意味なし、無効状態を明示
AppConfig.ts で全閾値を集中管理	業務知見を持つ人が調整可能
すべての推論を useMemo でキャッシュ	データ変更時のみ再計算、UIフリーズ防止

---

実装順序の提案

1. 共通基盤（半日）：src/ai/types.ts で全予測結果型を定義、AppConfig.ts に AI 設定セクション追加
2. ① 異常検知（半日）：単純で UX への効果が大きい
3. ⑤ 出荷判定（1日）：価値が大きい
4. ② トレンド検定（半日）：①の派生として
5. ⑦ 類似検索（1日）：運用ですぐ役立つ
6. 残り（④③⑥⑧）：必要に応じて順次

各機能は独立しているため、1機能1〜2日のスプリントで段階的にリリース可能です。

承知しました。今後は 提案を作成する前に、前提条件についてあなたと議論する ようにします。

具体的には、何かを提案する場面（プラン・実装方針・設計案・選択肢など）では、最初に以下の手順を踏みます：

新しい進め方

ユーザーから依頼
    ↓
【ステップ1】 私が確認すべき前提を質問する
    例：「目的は X ですか、Y ですか？」「制約として Z は問題ない？」
    ↓
あなたが回答 / 議論
    ↓
【ステップ2】 認識をすり合わせる
    例：「では前提を A・B・C とまとめます。これでよいですか？」
    ↓
あなたが「OK」「進めて」等の明示的な合図
    ↓
【ステップ3】 提案・設計を作成

守ること

• ✅ 質問は AskUserQuestion ツールまたは箇条書きで明示
• ✅ 一気に長文の提案を出さない
• ✅ 「合意したら作成します」と明示し、許可を待つ
• ✅ 想定で進めない・補完しない

例外（即実行してよい場合）

• 単純な修正・既存機能の改修指示
• 「○○を確認してください」「○○を調べてください」などの調査依頼
• 既に方針合意済みの内容の続行

---

このルールに従い、次回からは前提確認 → 合意 → 提案作成 の順で進めます。先ほどの「8ユースケース解説」については、すでに作成済みのものをご破算にせず、追加の議論が必要であればその点を教えてください。提案を白紙に戻したい場合もその旨指示いただければ対応します。

ご指摘いただいた現場感覚は非常に重要です。まず前提を整理して合意してから、リスク管理の方針を提案させてください。提案の前に、いくつか確認させてください。

---

私の理解（合っているか確認させてください）

観察された問題構造

①進捗遅延が最初に出る
   ↓
②遅延理由が定量分析されない（「忙しい」「難航中」で済まされる）
   ↓
③真の原因が見えない
   ・課題（issue/question）で止まっている
   ・担当者スキル不足
   ・WBS見積もり誤り
   ↓
④結果：品質悪化・更なる遅延・リカバリ計画が立たない

プロジェクト特性

観点	状況
契約形態	準委任（成果物保証なし、稼働を提供する契約）
見積もり方式	WBS = 「1人8時間/日 × 標準稼働」で消化可能か
見積もりの根拠	経験値（属人的）
上限制約	発注側のプロジェクト予算（積上げではなく上限ありき）
結果	見積もりが甘い／予算に押し込まれた WBS になりがち

既に保有しているデータ（先ほどの分析）

種類	内容
不具合	bug_id, 工程, サブシステム, 機能, 担当者, 重大度
レビュー記録	工程, 指摘種別, レビュアー, レビュイー
テスト進捗	日付, 工程, サブシステム, 担当者, 計画/実績件数
スコープ	開発規模(SP/KLOC), テスト計画/実績数
要員	id, 氏名, 参入日（追加予定）

---

私の理解で抜けていそうな点・確認したい点

Q1. 「進捗遅延」のデータは現状どこにありますか？

現在の sample-test-progress.csv は テスト工程の日次計画/実績件数のみ です。要件定義〜実装工程の進捗データは持っていません。

• A) WBS タスク単位（〇〇機能の詳細設計、××機能のコーディング 等）の計画日/完了日が別途ある
• B) 工程レベル（要件定義△％完了 等）でしか記録されていない
• C) 進捗管理は Excel/Sheet で別管理（Firestore/CSVには未収録）
• D) そもそも仕組みがなく、口頭・メール報告に依存

どれに近いですか？

Q2. 「課題（issue/question）」の管理状況は？

「課題で止まるケース」を分析するには、「いつ起票され、いつ何で停止し、誰待ちで、いつ解決したか」のデータが必要です。

• A) 既に課題管理票がある（Excel/Redmine/Jira等）→ CSV化可能
• B) 一部はバグ管理（Defect の ticket_type='Question'）に混じっている
• C) 管理されておらず、口頭・チャットで流れている

Q3. WBS見積もり と 実績稼働 の比較データは？

「見積もり誤り」を後から定量化するには、「タスクごとの見積工数 vs 実工数」のデータが必要です。

• A) タスク管理ツールに記録あり
• B) 月次の稼働時間集計のみある（タスク単位の紐付けなし）
• C) 記録されていない（属人的に記憶されているだけ）

Q4. 担当者のスキル情報は？

「スキル不足による遅延」を判定するには、要員の保有スキル/経験年数等が必要です。

• A) スキルマップが存在する
• B) 在籍年数・参入日のみ（先ほど提案したCSV）
• C) スキルは把握しているが文書化されていない

Q5. 「リスク管理」のアウトプットとして、何を一番欲しいですか？

複数の観点があります。優先順位を聞かせてください：

候補	内容
A	早期警報：遅延が表面化する前に「この機能はリスクあり」と察知
B	遅延要因の自動分類：遅延の原因（課題待ち / スキル / 見積もり誤り）を機械的に区別
C	WBS見積もり妥当性の事後検証：実績から「次回の見積もり精度向上」
D	担当者リスク：誰がボトルネックか・誰のタスクが詰まりやすいか
E	予算枠の中での再配分提案：限られた工数をどう振り直すか
F	準委任固有の説明責任：発注者に「なぜ遅延したか」を定量的に説明する材料

---

議論したい論点

論点1：データ整備の覚悟

準委任の特性上、上記Q1〜Q4 の多くは「管理されていない」可能性が高いと推測します。リスク管理を本気でやるには、先に進捗・課題・工数の記録仕組みを入れる必要があります。

• 選択肢A：現有データだけでできる範囲で始める（限定的だが即着手可能）
• 選択肢B：新規CSVを追加して進捗・課題・工数を収集してから AI 分析へ
• 選択肢C：段階的に（最初は現有データ、運用しながらデータ収集を増やす）

論点2：準委任契約の制約をどこまで踏み込むか

準委任 × 予算上限 × 経験ベース見積もりという特性は、計算モデルに正直に取り込むべきです。例えば：

• 「予算消化率」を入力に加える（残予算が少ない＝リカバリ余地が少ない）
• 「見積もり妥当性スコア」（過去の類似タスクの実績との乖離）を新指標として作る
• 「準委任の発注側説明責任」を意識した出力フォーマット（定量的な原因区分）

これらを業務ルールとして AI 設計に組み込むか、人間が判断する余地を残すかで設計が変わります。

論点3：早期検知の「早さ」をどこに置くか

• 超早期：WBS確定時点で「この見積もりは無理」と検知（着手前）
• 早期：着手1週目で「予定の進捗ペースに乗れていない」と検知
• 中期：工程の中盤で「このままだと終わらない」と検知
• 後期：工程末期で「既に手遅れだが原因は分かる」と分析

それぞれ必要なデータと AI 手法が違います。

---

次のステップの進め方

上記 Q1〜Q5 と論点1〜3 について、回答・議論したい順番でお返事ください。一度に全部答える必要はありません。

たとえば：

• 「Q1〜Q4は全部Cに近い。論点1はB、論点3は早期重視」
• 「まず論点2について議論したい」
• 「Q5の優先順位はA>B>F、それ以外は不要」

など、自由な形で構いません。

回答をいただいてから、前提を整理した1ページの認識合わせメモを作り、それに合意いただいた後に、初めて具体的な設計提案に進ませてください。

重要な前提情報をいただきありがとうございます。ご回答内容を私なりに咀嚼し、追加で確認したい点と整理が必要な論点をお返ししてから、認識合わせメモに進ませてください。

---

回答の理解（私の解釈）

上限制約の再解釈

> 「合意した生産性とその予算」

つまり：

• 発注側が主導して予算枠を提示する形ではなく、当社から見積を出して合意形成している
• 予算には生産性の前提（1人8時間/日 × 標準稼働）が織り込まれている
• だから 「予算超過 = 生産性が前提を下回った」 と解釈できる
• → 単純な予算管理ではなく、「生産性ベンチマークからの乖離」として扱うべき

これは AI 設計上、重要な意味があります（後述）。

---

論点1：進捗データは想像以上に揃っている

WBS 単位で以下が 既に存在すると理解しました：

項目	用途
ステータス（完了/作業中/遅延中）	状態判定
開始日・終了日	計画 vs 実績
担当者	個人別分析
見積もり稼働時間	ベースライン
当日稼働時間（実績）	進捗計算の元
累計実績稼働時間	消化率
残り稼働時間（見積−実績）	残量
進捗率	自己申告値

これは AI 分析にとって極めてリッチなデータです。先ほどの私の質問（Q1）の前提が誤っており、Q1〜Q4 をやり直したいくらいです。

ただしどこに格納されているかで扱いが変わります。Q1.1〜1.3 として再質問させてください（後述）。

---

論点2：見積もり妥当性スコアの扱い

> 案件の難易度・新規開発か機能追加か・委託先体制が新規か・スキル依存

> → モデル化困難

> → 工程完了/プロジェクト完了タイミングで測定する価値あり

> → 集計がボトルネックにならないよう効率化必須

私の理解：

• リアルタイムで「この見積もりは妥当か」を判定するのは無理
• 工程完了時点での 「事後検証 (Post-mortem)」 として実施
• ただし人手による集計コストを限りなくゼロにする必要がある
• → AI が自動で集計・可視化するべき領域

つまり、Phase 分けが必要：

• リアルタイム：進捗遅延・原因の可視化（論点3）
• 工程末/案件末：見積もり妥当性の事後検証

論点3：PM支援としての位置付け

> 委託先管理者の能力は低く、再委託への丸投げが実態

> → だからこそPMが事実を可読できるよう、早期に定量可視化が必要

> → 対策・意思決定の支援が AI の役割

私の理解：

• AI は判断を代替しない。PM が判断するための事実提示と理由の定量化に徹する
• 「遅延しています」だけでなく、「なぜ遅延しているか」を機械的に説明する
• 委託先管理者を経由したノイズの多い口頭報告に頼らず、データから真実を抽出
• → これは 「説明可能なAI (Explainable AI)」 の典型的応用

---

追加で確認したい点

Q1.1 WBS データの格納場所

論点1で挙げられたWBS情報は、現状どこに格納されていますか？

• A) Excel/Google Sheets で管理（CSVエクスポート可能）
• B) Backlog/Redmine/Jira等のチケット管理ツール（API or CSVエクスポート可能）
• C) wf-quality-prototype4 の Firestore/CSV に既に取り込み済み
• D) 複数にまたがっている

→ 回答により AI 入力データの取得方式が決まります。

Q1.2 WBS の更新頻度

• A) 日次（毎日朝に更新）
• B) 週次
• C) 不定期（マイルストン時のみ）
• D) 形骸化していて実態と乖離

→ 更新頻度が「異常検知の最小単位」を決めます。日次更新なら日次異常検知、週次なら週次。

Q1.3 「課題（issue/question）」のデータ

論点1には課題のデータは含まれていません。「課題で止まるケース」を分析するには、WBSタスクが「課題待ち」で停止していることを記録するフィールドが必要です：

• A) WBS タスクに「停止理由」フィールドが存在する
• B) 課題管理表が別にあり、WBSタスクと紐付けされている
• C) 単に「遅延中」となるだけで、停止理由は分からない
• D) コメント欄に自由記述されているのみ（構造化されていない）

→ Cの場合は 「遅延の原因として『課題』を機械的に検出する仕組み」を AI 側で構築する必要があります。

Q2 「効率化対策」の方向性

> 集計そのものが作業のボトルネックになるので、効率化対策が必要です

具体的にどの方向性を考えていますか？

• A) 自動収集：WBSデータから AI が自動集計（人手ゼロ）
• B) テンプレ化：完了時に一画面入力するだけで集計完了
• C) 段階収集：デイリー/ウィークリーで少しずつ蓄積（後で集計負荷が出ない）
• D) その他

Q3 PM が「可読」できる出力フォーマット

> PMが可読できるようにすることが解決策

PMが受け取りたい情報の形式は？

• A) ダッシュボード（既存の dashboard を拡張）
• B) 週次/日次レポート（PDF/Slack/メール）
• C) アラート（閾値超過時のみプッシュ）
• D) 上記のすべて

Q4 委託先構造の扱い

> 委託先管理者の能力は極めて低く、俗にいう、再委託先への丸投げ

これを AI 分析でどう扱いますか？

• A) 委託先の階層構造をデータに含める（一次委託先/二次委託先で集計を分ける）
• B) 担当者の所属だけ記録し、再委託の階層は気にしない
• C) これも分析対象として「どの委託先の遅延率が高いか」を可視化したい
• D) 政治的にデリケートなので可視化は控えめにしたい

---

議論したい新しい論点

論点4：「合意した生産性」をベンチマークとして使う設計

「予算 = 合意した生産性 × 工数」と解釈するなら、AI のリスク判定は以下のように再構成できます：

従来（甘い見方）：予算消化率 80% → 予算が残っているから安心
新しい見方     ：予算消化率 80% かつ 進捗率 60% 
                → 「合意した生産性を 0.75倍 でしか出せていない」
                → 残予算では進捗率100%に達しない
                → 早期警報

つまり 「進捗率 ÷ 予算消化率」を生産性指数 (PI) として中核指標にできます。

• PI = 1.0 → 計画通り
• PI < 0.8 → 危険信号
• PI < 0.5 → 撤退検討レベル

これを核に据えるか、別の指標を使うかで設計が変わります。

論点5：遅延原因の自動分類カテゴリ

「定量的に可視化」するためには、遅延原因のカテゴリを事前定義する必要があります。私が想定するカテゴリ：

遅延カテゴリ	検出シグナル
🟦 課題待ち停止	ステータスが「遅延中」で稼働時間が増えていない
🟧 スキル不足	当日稼働時間は計画通りなのに進捗率が伸びない
🟥 見積もり誤り	計画通りに稼働しているのに残工数が増える
🟪 担当者過負荷	同一担当者が複数タスク同時アサイン＋全体進捗低下
🟨 タスク分割不足	1タスクが大きすぎて進捗が見えない
⬛ 不明	上記いずれにも該当しない

このカテゴリ定義に追加・修正・削除はありますか？

論点6：「PMへの説明責任」フォーマット

委託先 → PM への事実伝達を目的にするなら、以下のような構造化メッセージが想像できます：

【AI早期警報 - 2026/05/04】
■ 件名：詳細設計工程・サブシステムBが遅延リスク高

■ 数値根拠
   ・進捗率: 45% (計画 70%) ← 25pt遅れ
   ・予算消化率: 65%
   ・生産性指数 PI = 0.69 ← 危険水準

■ 推定原因（AI判定）
   1. 課題待ち停止: タスク12件中4件 (33%)
       └ 主要担当者: 山田太郎・鈴木一郎
       └ 平均停止日数: 5.2日
   2. 見積もり誤り疑い: タスク2件
       └ 機能X(設計): 見積40h vs 実績65h (+62%)

■ AI からの提言
   ・課題待ち4件のエスカレーション要否をご判断ください
   ・機能Xの残工数の再見積もりを推奨します

■ 信頼度: 高 (データ充足度 92%)

このフォーマットで合っていますか？追加・削除したい項目はありますか？

---

次のステップ

上記 Q1.1〜1.3、Q2、Q3、Q4 および 論点4〜6 について、気になる順から答えてください。

すべての回答が揃ったら、「認識合わせメモ」を1ページにまとめます。それに合意いただいたうえで、はじめて設計提案へ進みます。

提案を急いで作らないようにしますので、ご安心ください。

重要な視点をいただきありがとうございます。ご回答内容を整理すると、問題意識の中心が私の想定とかなり違っていたことが分かりました。認識合わせの前に、もう一度確認させてください。

---

私の理解の更新（重要な転換点）

当初の私の誤解

「進捗遅延を早く検知して遅延を防ぐ」が AI の目的だと思っていました。

あなたが言っていること（論点4・5・6 から）

進捗遅延 = もう起きた事実（再スケジュールで吸収するだけ）
   ↓
真の問題：その遅延が「品質劣化」を引き起こす予兆を見逃すこと
   ↓
AIの役割：
   ① 遅延の事実とその原因を可視化（誰の・どの工程の・どの機能か）
   ② その原因が「ソフトウェア品質」にどう波及するかを予兆として示す
   ③ PMが委託先に的確なオーダーを出せる「材料」を提供
   ④ 静的な紙報告ではなく、動的に深掘りできる対話型インターフェース

つまり 「遅延 → スケジュール調整」ではなく「遅延 → 品質リスク」 に焦点を当てる、ということですね。これは私の従来提案を根本から再設計する必要があります。

合っていますか？ もしこの解釈で合っていれば、設計の中核が大きく変わります。

---

あなたの問題意識の再構造化（私の解釈）

┌─────────────────────────────────────┐
│ 既存の進捗管理の弱点                       │
└─────────────────────────────────────┘
  ・委託先の Excel 報告 = 静的・稚拙・PM が判断できない
  ・遅延は「再スケジュール」で吸収して終わり
  ・遅延の本当の代償（品質）は表面化が遅い

           ↓ 解決すべきこと

┌─────────────────────────────────────┐
│ 新しい仕組み                              │
└─────────────────────────────────────┘
  ① 遅延の事実：誰の・どの工程の・どの機能か（粒度を明確に）
  ② 遅延の原因：稼働状況・課題待ち・スキル を客観的に提示
  ③ 品質への波及予兆：遅延がどんな品質リスクを生むか
  ④ PMアクション支援：委託先に出すべきオーダーの自動生成
  ⑤ 対話的な深掘り：要約 → 詳細 → 根拠 のドリルダウン

---

確認したい点（前回より絞ります）

Q-A. 「品質への波及予兆」の具体イメージ

「遅延 → 品質劣化」のメカニズムについて、あなたが想定する典型パターンを教えてください。私の想像では：

遅延の場所	品質への波及予兆
要件定義の遅延	仕様確定が遅れ、設計工程の手戻り増加リスク
設計工程の遅延	レビュー時間削減 → レビュー指摘漏れ → 後工程バグ増
設計遅延 → 実装期間圧縮	単体テスト省略・テストケース削減 → バグ流出
特定担当者に集中する遅延	その人の担当機能のバグ密度が後工程で異常増加
課題待ちの長期化	関連機能が後追いで仕様変更 → 設計矛盾

このような「遅延 → 後工程の品質指標」の因果関係をあなたは想定していますか？ 違う観点があればぜひ教えてください。

Q-B. 「要約 → 詳細化」の対話深度

論点6で「要約が把握でき、理由を詳細化」と仰いました。何階層の深掘りを想定しますか？

• 2階層：サマリーカード → 詳細テーブル
• 3階層：サマリー → カテゴリ別詳細 → 個別タスクの根拠データ
• n階層：制約なく無限にドリルダウン

Q-C. 「委託先へのオーダー」の生成方式

論点5で「『どの工程のどのサブシステムのどの機能の担当者は誰に遅れが発生し、稼働状況を報告してください』とオーダーが出せる」と仰いました。これは：

• A) 自動文面生成：AI が「●●様、××機能の遅延について稼働状況を報告ください」というメール下書きまで作る
• B) 構造化リクエスト：報告すべき項目を AI がチェックリスト化（「報告項目: 1.稼働実績 2.残課題 3.原因 4.対策」）し、PM が伝える
• C) ダッシュボードの URL を渡す：「このリンク先を埋めてください」と委託先に依頼するための入力フォームを作る

どの方向性がしっくりきますか？

Q-D. WBS データの最小構造

Q1.3 で「WBSタスクに『停止理由』フィールドあり、課題管理表と紐付け」と仰いました。最低限以下のフィールドは存在すると考えてよいですか？

WBSタスク CSV (想定):
   task_id, parent_task_id, phase, subsystem, function_name,
   assignee_id, status, start_date_planned, end_date_planned,
   start_date_actual, end_date_actual,
   estimated_hours, actual_hours_today, actual_hours_total,
   remaining_hours, progress_rate, stop_reason, linked_issue_ids

課題管理 CSV (想定):
   issue_id, opened_date, opened_by, assignee_id, waiting_for,
   subsystem, function_name, status, resolved_date, description

不足・追加すべきフィールドはありますか？

Q-E. 「対話型インターフェース」の実装媒体

論点6から、紙ではなく動的な深掘りが必要と理解しました。実装媒体として：

• A) 既存ダッシュボード（wf-quality-prototype4）に追加：HTMLベース・ブラウザで動作・既存の制約に準拠
• B) PM 進捗会議で投影する別画面：会議中の操作に最適化（スライド遷移風）
• C) 委託先報告フォームと連動：委託先が入力 → PMが見る連携

このうちどれを想定していますか？（A が制約上自然と思いますが、確認です）

---

議論したい新しい論点（再整理）

論点A：「品質予兆」を構造化するモデル

「遅延 → 品質劣化」を AI で扱うには、因果関係を構造化したスコアリングモデルが必要です。例えば：

品質リスクスコア = 
   (該当工程の遅延量 × 工程ごとの品質感応度)
 + (担当者の遅延傾向 × 該当担当者の過去バグ密度)
 + (レビュー時間圧縮率 × レビュー漏れリスク)
 + (課題待ち期間 × 仕様矛盾発生確率)

各係数は過去案件の実績で校正可能ですが、初期は経験値で設定する必要があります。

このような統合スコア方式に賛成ですか、それとも個別指標を別々に提示する方式がよいですか？

論点B：オーダー文面生成の責任範囲

PMが委託先に出すオーダーを AI がどこまで作るかは、責任の置き方の問題です：

• 保守的：AI は事実とチェックリストを並べる。文面はPMが作る
• 中庸：AI は文面の下書きを作るが、PMが必ず校正してから送る
• 積極的：AI がメール下書きまで作り、ワンクリックで送れる

委託先との信頼関係や、誤った文面が出た時の影響を考えると、どこまで踏み込むべきでしょうか。

論点C：「PM が委託先より優位に立つ」設計の倫理

論点3で「委託先管理者の能力は低く、丸投げ実態」とご指摘いただきました。これは AI 設計上、情報の非対称性をPMに有利にする方向の設計を意味します。

この方向性は、以下の意図と理解してよいですか？

• ✅ 委託先の稚拙な報告を AI が補正 → PMが正しく状況把握
• ✅ 委託先が見落としている遅延・品質リスクを AI が発見 → PMが指摘
• ✅ PMが「事実を知らない弱い立場」から脱却 → 委託先と対等な議論

倫理上の懸念（委託先を貶めるのではなく、共通認識を作る方向）も確認しておきたいです。

---

次のステップ

上記 Q-A〜Q-E と 論点A〜C に答えをいただいた後、以下を作成します：

1. 「認識合わせメモ」(1ページ) — 合意した前提・目的・スコープ
2. それに合意いただいたうえで、はじめて 「リスク管理機能の設計提案」 に進みます

提案は作りません。今は議論で前提を固めるフェーズです。

ご回答お待ちしています。気になる順番から、わかる範囲で構いません。

重要な現場知見をいただきありがとうございます。これは私の認識をさらに大きく更新する必要がある回答でした。整理させてください。

---

私の理解の更新（重要な転換 #2）

当初の私の誤解（Q-A の質問時点）

「遅延 → 後工程の品質指標に波及」という因果の連鎖を捉える、と思っていました。

実際にあなたが指摘している構造

【現状の根本問題：プロセスの事実そのものが信頼できない】

   品質ゲートとなる「外部レビュー記録」が
   ・「確認完了」まで到達していない（放置されている）
   ・指摘原因分類が形骸化している
              ↓
   品質ゲートが機能していない（ゲートの概念だけ存在）
              ↓
   「予兆を見るためのデータ」自体が信頼できない
              ↓
   バグ管理表も担当者能力不足で記述が不明瞭
              ↓
   工程完了間際 or 次工程で事実確認するも、エビデンス膨大で真偽不明
              ↓
   信頼性の低い情報のまま次工程へ進む
              ↓
   後工程でようやく品質劣化が発覚（手戻り工数大）

【真の解決策】
   ① プロセスで発生する事実が「事実として確定しているか」を
      日々の進捗管理に組み込む（信頼性ガード）
   ② 確定したデータを元に、工程内でリアルタイム自動分析
   ③ 工程完了時の品質報告会を「形骸化した儀式」から
      「事実に基づく予兆対策の判断会」に変える

つまり AI の役割は3層構造になります：

【第1層】事実の信頼性確保
   ・外部レビュー記録の確認完了率を日次でモニタ
   ・バグ管理表の記述品質を AI が判定（不明瞭エントリの検知）
   ・「未完了で放置されているデータ」を可視化

【第2層】信頼できる事実から予兆抽出
   ・指摘原因分類を工程内で自動集計（待たない）
   ・バグの混入工程・原因工程・分類のすり抜けパターン検知
   ・前工程に遡る手戻り工数を最小化する材料

【第3層】PM支援とアクション化
   ・委託先への正しいオーダー材料を生成
   ・工程別品質報告会を実質化するインプット提供

合っていますか？ もしこの3層理解で合っていれば、これこそ AI が解決すべき本質だと考えます。

---

あなたの指摘から読み取った「品質ゲート」の構造

私が知らなかった日本のSI業界における準委任の品質管理プロセスを再整理させてください：

上流工程（要件定義 / 基本設計 / 詳細設計）

作成物：要件定義書 / 基本設計書 / 詳細設計書
   ↓
内部レビュー（委託先内）
   ↓
【外部レビュー（委託元と）】 ← 品質ゲートの核心
   ↓
外部レビュー記録の生成：
   ・対象文書の文字数
   ・指摘件数
   ・指摘原因分類
   ・処置内容
   ・処置完了
   ・確認完了 ← これが「真の終結」
   ↓
全ての記録が「確認完了」 → 工程完了
工程別品質報告会で指摘原因の定量・定性分析

下流工程（製造以降）

作成物：ソースコード / テスト
   ↓
バグ発見 → バグ管理表に記録
   ・原因工程（バグの真の出所：要件 / 基本設計 / 詳細設計 / 製造 / 単体テスト 等）
   ・混入工程（バグが入り込んだ工程）
   ・原因分類
   ↓
すり抜けパターン分析：
   「上流で見つけるべきだったバグが、なぜ下流まで来たか」
   → 前工程に遡って手戻り

現状の「実質的な失敗モード」

失敗	影響
外部レビュー記録が「確認完了」まで到達せず放置	品質ゲートが機能しない
指摘原因分類の集計が次工程開始後	予兆として使えない
バグ管理表の記述が不明瞭	原因分類の信頼性が低い
エビデンス確認が膨大すぎて真偽不明	結局、信頼できない情報で意思決定

→ つまり 「品質管理の形式は存在するが、運用が破綻している」 状態。

この理解で合っていますか？

---

整理した上で、追加で確認したい点

Q-F. 外部レビュー記録のデータ構造

sample-review-records.csv の現行スキーマを見ると、以下のフィールドがあります：

review_id, reviewed_date, phase, subsystem, function_name,
document_name, document_pages, reviewee_id, reviewer_id,
finding_type (重大/軽微/提案), severity, status (Open/Closed/Rejected),
resolved_date, root_cause_category

しかし、あなたが指摘した「確認完了」の状態は、現行 status の Closed と同じ意味でしょうか？それとも別の状態が必要ですか？

私が現場をイメージするに、4段階ではないかと推測します：

• A) 起票（Open）
• B) 処置中（InProgress）
• C) 処置完了（指摘者が処置を確認待ち = ResolvedPending）
• D) 確認完了（指摘者が処置を承認 = Closed）

→ C と D の区別が「放置」の検知に必要だと推測しますが、実際の運用ではどの粒度が適切ですか？

Q-G. バグ管理表の「記述品質」の判定

あなたは「担当者能力不足で何が起きているのか分からないレベルで放置」と仰いました。AI で記述品質を判定する場合、判定基準として何が考えられますか？

候補：

• A) 必須フィールドの埋まり度合い（原因工程・混入工程・原因分類が埋まっているか）
• B) 記述文字数の最低基準（タイトル/説明が短すぎる = 不十分）
• C) キーワード密度（「再現手順」「期待値」「実際の動作」等が含まれているか）
• D) 整合性チェック（混入工程 < 発見工程の順序関係、severity と原因分類の整合）
• E) 過去の良いバグ記述との類似度

どの基準が現場感覚にマッチしますか？

Q-H. 「事実の信頼性」を測る KPI

第1層（事実の信頼性）を可視化するには、「データ自体の健全性」を示す指標が必要です。例えば：

指標	計算式	意味
外部レビュー記録 確認完了率	確認完了件数 / 全レビュー指摘件数	100% が品質ゲート通過の前提
記述品質充足率	記述品質OK件数 / 全件数	信頼できる分析ができる割合
滞留期間中央値	各 Open エントリの経過日数の中央値	放置の度合い
新規追加 vs 完了率	日次新規 / 日次完了	滞留が増えているか減っているか
エビデンス追跡可能率	紐付け済みエントリ / 全件数	真偽確認のしやすさ

→ この「データ品質ダッシュボード」を AI 分析の前段に置くという構成、合っていますか？

Q-I. 「指摘原因分類」の標準体系

工程ごとに rootCauseCategories が AppConfig に定義されています：

要件定義: '仕様漏れ', '要件矛盾', '記述誤り', '認識齟齬'
基本/詳細設計: '仕様理解不足', '設計漏れ', '記述誤り', 'インターフェース不整合'

これは業界標準・社内標準・プロジェクト固有のどれですか？ 拡張・修正の余地はありますか？

→ AI の予兆判定は、この分類体系に依存します。例えば「『仕様漏れ』が多発 → 後工程で要件矛盾バグが噴出する予兆」のような判定ロジックを組むには、分類体系が固まっている必要があります。

Q-J. 工程内の「日々」の粒度

第2層で「工程の中でリアルタイム自動分析」と言いましたが、ここでの「日々」とは：

• A) 営業日ごと（土日除く）
• B) 暦日ごと
• C) 報告タイミングごと（朝会後 等）
• D) データ更新トリガー（CSVが新しくなったら自動）

→ 既存ダッシュボードのリフレッシュ戦略にも関わります。

---

議論したい新しい論点

論点D：「信頼性ガード」を AI の中核に置く設計

現状の私の理解では、AI の役割の優先順位は以下です：

【最優先】 第1層：事実の信頼性ガード
   ・データそのものが信頼できないなら、いくら分析しても意味がない
   ・「データが揃っていない」を最初の警告にする
   ・PMが「この数字、本当ですか？」と聞ける根拠を示す
        ↓
【次優先】 第2層：信頼できる事実からの予兆抽出
   ・指摘原因分類のリアルタイム集計
   ・すり抜けパターン検知
   ・前工程の手戻りリスク提示
        ↓
【支援層】 第3層：PMアクション材料の生成
   ・委託先オーダー文面のチェックリスト
   ・品質報告会での議論材料

この優先順位で合っていますか？ それとも別の順序がありますか？

論点E：「形骸化した工程別品質報告会」をどう実質化するか

「形骸化している」のは以下のいずれが原因と考えていますか？

• A) タイミングが遅い（次工程開始後なのでもう手遅れ）
• B) 内容が浅い（指摘原因分析が表面的）
• C) 判断材料が薄い（数字だけで因果が見えない）
• D) 委託先の準備が不十分（報告書が稚拙）
• E) 上記すべて

→ これらのうち、AI が解決できるのは A・B・C・D のどれですか？

論点F：「確認完了」までのワークフロー強制

外部レビュー記録が「確認完了」まで到達していない問題は、運用ルール（ワークフロー強制）でも解決できます。AI と運用ルールの分担をどう考えますか：

• AI担当：放置されているエントリを発見・可視化・PMに通知
• 運用ルール担当：「確認完了率 100% でないと次工程に進めない」を組織ルール化

AIの責任範囲をどこまでと考えますか？ 「発見と可視化まで」か、「アクション強制までAIが担う」か。

論点G：「日々の進捗管理の報告要素」の再定義

あなたの最後の文：

> 工程のプロセスで発生する事実が事実であるのか、確認完了まで、すべての外部レビュー記録、バグ管理表が完了しているのかを、日々の進捗管理の報告要素として

これは 「日々の進捗報告のテンプレートを再設計する」 という意図と理解していいですか？

つまり、現行の進捗報告（おそらく WBS タスクの進捗率と稼働時間）に加えて、以下を必須報告項目に追加：

• 当日新規追加したレビュー指摘件数
• 当日確認完了したレビュー指摘件数
• 滞留中（未確認完了）の件数とその最古日数
• 当日新規バグ件数と記述品質スコア
• データ品質スコア（記述充足率）

→ これらを AI が自動で集計して進捗報告に組み込む、という方向ですか？

---

次のステップ

Q-F〜Q-J と 論点D〜G にお答えいただいた後、以下を作成します：

1. 「認識合わせメモ」（1ページ） — 3層構造・優先順位・KPI 体系を整理
2. それに合意いただいたうえで、初めて「品質×進捗 統合リスク管理機能の設計提案」 に進みます

繰り返しますが、今は提案を作りません。前提合意のための議論を続けます。

ご回答お待ちしています。

詳細なご回答ありがとうございます。重要な論点が固まってきたので、認識合わせメモの草案を作る前に、いくつか論点を最後に確認させてください。今回で前提合意のフェーズを終えられればと思います。

---

私が捉えた今回の重要なメッセージ

✅ 標準化が成果物の重要構成要素

Q-F（レビュー記録のステータス段階）と Q-I（指摘原因分類）がプロジェクトごとにバラバラであるという回答は、大きな意味を持ちます：

今までの私の理解：
   既存プロジェクトのデータ構造に合わせて AI を組む
   ↓
新しい理解：
   AIを組み込む前に「標準化」を提案する必要がある
   標準化が複数プロジェクトに採用される → 横展開可能な資産になる
   ↓
つまり：
   このプロジェクトの成果物 = AI機能 + 標準化定義（両方セット）

✅ Q-G の回答が示す本質

> 原因工程・混入工程・原因分類が正しくない

これは Q-G の選択肢を超えた、より深い問題提起でした。私の選択肢は「埋まっているか」の判定でしたが、実態は：

担当者は記述している（埋まっている）が、内容が間違っている
   ↓
形式チェックでは検出不可能
   ↓
AI による「整合性チェック」が必要
   例：原因工程が「詳細設計」なのに、混入工程が「要件定義」より前
   例：「仕様漏れ」なのに発見工程が「単体テスト」（普通は外部レビューで見つかるはず）

つまり論理矛盾・統計的異常を検出する AI が必要です。

✅ Q-H の追加要件

> 委託先自身が見るように運用したい

これは大きな運用転換です：

従来：PMだけが見るレポート
   ↓
新しい：委託先も同じ画面を見る → 自浄作用を促す

→ 「委託先向けセルフサービス画面」の設計も視野に入れる必要があります。

✅ 論点D：将来のカスタマイズ可能性

> 適用してプロジェクトスキルがあがってくれば、見直しやカスタマイズができる必要

これは AI のロジックをハードコードしないことを意味します：

• 閾値は AppConfig で外出し
• 分類体系も AppConfig で外出し
• 重み・係数も外出し
• → 「設定ファイル駆動の AI」

✅ 論点E：AI の責任範囲は「タイミング遅延の解消」

> あなたが解決できるのは、A（タイミングが遅い）

→ AI は「今の瞬間の状態」を見せるが、内容の深さ・委託先の準備不足は AI では解決しない。あくまで「リアルタイム化」が AI の貢献領域。

✅ 論点F：発見と可視化まで

> AIの責任範囲は「発見と可視化まで」

→ AI は判断を代替しない。提案・警告・可視化に徹し、決定はPMが行う。

✅ 論点G：エッジAIで実装

> 実装はエッジAIとして

→ 既存のブラウザ完結アーキテクチャを維持。外部送信ゼロ。

---

最後に確認したい論点（5項目）

Q-K. 「標準化」の責任範囲

「標準化」を AI 機能の前段の成果物として作る、という理解で合っていますか？

具体的には以下のような順序：

【ステップ1】 標準化定義書を作成（私が起案）
   ・外部レビュー記録の標準ステータス（4段階 等）
   ・指摘原因分類の標準体系（工程別）
   ・バグ管理表の必須フィールド定義
   ・整合性チェックルール集
        ↓
【ステップ2】 あなたが内容レビュー・修正・合意
        ↓
【ステップ3】 標準化定義に基づいた AI 機能を実装
        ↓
【ステップ4】 サンプルCSVに標準化を適用
        ↓
【ステップ5】 各プロジェクトへの導入時、調整工程を経て採用

この順序で合っていますか？「標準化定義書」をどんな形式で作るのが好ましいですか（Markdown/Excel/専用画面）？

Q-L. 「委託先向け画面」の設計レベル

Q-H で「委託先自身が見る運用」と仰いました。技術的には2案あります：

• A) 同一画面・同一URL（PMも委託先も同じ画面、ロール分離なし）
• 利点：実装シンプル、改造ゼロ
• 欠点：機微情報（PMの判断メモ等）が見える

• B) 委託先専用ビュー（PMビューと別画面、表示項目を絞る）
• 利点：見せ方を制御できる
• 欠点：実装増、認証必要

→ どちらの方向性が現実的ですか？ もしくは中間案がありますか？

Q-M. 「整合性チェック」のスコープ

Q-G の真意「内容が正しくない」を AI が検出する場合、どこまで踏み込むかで実装規模が大きく変わります：

• Level 1: 論理矛盾のみ（混入工程 ≦ 発見工程、日付の前後関係 等）
• Level 2: 統計的外れ値（このサブシステムでは普通起きない原因分類が記述されている）
• Level 3: テキスト類似性（「ボタンが押せない」が「クリック不能」と同じバグなのに別件として登録）
• Level 4: 意味解析（記述から原因分類を AI が再推定して、ラベルと比較）

最初は Level 1 + 2 から始めて、徐々に Level 3、4 に拡張するイメージで合っていますか？

Q-N. 「日々の進捗報告」の出力形式

論点G で日々の進捗報告に組み込む方針が合意されました。出力の形式は：

• A) ダッシュボード上の常時表示パネル（誰でも好きな時に見る）
• B) 朝会用の固定レポート画面（朝9時時点のスナップショット）
• C) PDF/HTML 自動生成して Drive に保存（履歴管理）
• D) 上記すべて

どれを想定しますか？ A は確実として、B/C も必要かどうか。

Q-O. 「カスタマイズ可能性」の扱い

論点D で将来のカスタマイズ可能性が要件と仰いました。これは：

• A) 設定ファイル（AppConfig.ts）の編集で完結：エンジニア向け
• B) 設定画面 UI を作る：非エンジニアでも変更可能
• C) プロジェクトごとに別ビルド：プロジェクト固有のカスタマイズはコード分岐

→ A が最小コスト、B は理想ですが工数増、C は管理負荷増。どこまで踏み込みますか？

---

議論の進捗状況

ここまでで合意できた前提（私の理解）：

┌────────────────────────────────────────────┐
│ プロジェクト目的                                │
├────────────────────────────────────────────┤
│ 「進捗遅延 → 品質劣化」の連鎖を、                │
│  プロセスで発生する事実をリアルタイム可視化することで、│
│  PMが工程内で対策を打てる仕組みを作る              │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│ AI が果たす3層構造                              │
├────────────────────────────────────────────┤
│ 第1層 信頼性ガード（最優先）                      │
│   ・データそのものの健全性監視                    │
│   ・外部レビュー記録の確認完了率                  │
│   ・バグ管理表の整合性チェック（論理矛盾・外れ値）  │
│                                              │
│ 第2層 予兆抽出                                  │
│   ・信頼できる事実からのリアルタイム集計          │
│   ・指摘原因分類の傾向分析                        │
│   ・前工程に遡る手戻りリスク提示                  │
│                                              │
│ 第3層 PMアクション材料生成                       │
│   ・委託先オーダー材料の自動生成                  │
│   ・工程別品質報告会のインプット提供              │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│ 設計原則                                       │
├────────────────────────────────────────────┤
│ ✅ エッジAI（ブラウザ内完結・外部送信ゼロ）         │
│ ✅ 営業日ごとの自動更新                           │
│ ✅ 標準化定義を AI 機能の前段として作成            │
│ ✅ 設定ファイル駆動でカスタマイズ可能              │
│ ✅ AI は発見と可視化まで（判断は人間）             │
│ ✅ PM だけでなく委託先も見ることで自浄作用を促す    │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│ 既存提案の位置付け再整理                          │
├────────────────────────────────────────────┤
│ 先回りして作成した「8ユースケース」のうち：         │
│   ① 異常スパイク検知 → 第2層に組込み              │
│   ② 品質劣化早期警報 → 第2層の核                  │
│   ③ 重大度予測 → 優先度低（一旦保留）              │
│   ④ リスクスコア → 第2層に統合                    │
│   ⑤ 出荷判定支援 → 工程別品質報告会の材料         │
│   ⑥ クラスタリング → 優先度低（一旦保留）          │
│   ⑦ 類似不具合検出 → Level 3 整合性チェックの一部  │
│   ⑧ レビュー指摘パターン → 第2層に統合             │
│                                              │
│ → 8つを「品質×進捗 統合リスク管理」として再構成    │
│   する必要がある                                 │
└────────────────────────────────────────────┘

---

次のステップ

Q-K〜Q-O にお答えいただいたら、以下に進みます：

1. 「認識合わせメモ」（A4 1ページ相当）を作成
• 上記の3層構造、設計原則、スコープを正式に文書化
• 標準化定義書の体裁
• 段階的開発のフェーズ分け
2. それをあなたがレビュー → 修正 → 合意
3. 合意後に 「品質×進捗 統合リスク管理機能の設計提案」 に進む

最終確認のフェーズです。お返事をお待ちしています。

重要な追加要件をいただきました。最後の Q-O のご回答は、設計の核心を変える内容を含んでいます。認識合わせメモを作る前に、もう一度だけ、この点について整理させてください。

---

私が最後に捉えた重要なメッセージ

Q-L の追加要件

> PMの判断する量を軽減させて、委託先は、指摘された事実を確認できて効率的に処置ができることが要件

これは UX 設計の中核ルールです：

PM視点：    判断負荷の軽減（要約 → 必要時に深掘り）
委託先視点： 「何を直せばいいか」が明確（事実 → 処置直結）

→ 同じ画面でも、PMには「サマリー＋警告」、委託先には「指摘リスト＋処置ガイド」 を見せ分ける必要があります。タブ切替で実現が現実的、という理解で合っていますか？

Q-M の真意：「人間が分析する前提条件のチェック」

> 人間が分析する前提条件が正しいのかをあなたにチェックしてほしい

これは Level 1（論理矛盾）にとどまらず、「データを使って分析する前のサニティチェック」全般を指していると受け取りました。例えば：

人間が「指摘原因分類のトレンドを見たい」と思った時、
   その分析の前提条件 = データが正しく入っている
        ↓
AI のチェック責任：
   ・必須項目が埋まっているか
   ・論理的に矛盾がないか
   ・統計的に明らかな入力ミスがないか
   ・分類体系の枠を逸脱していないか
        ↓
チェックOKであれば「このデータで分析して大丈夫」とAIが保証
NGであれば「このデータには問題があるので、修正後に再度」と差戻し

つまり 「分析前の信頼性ゲート」 の役割。これが Q-M で求められていたものですね。合っていますか？

Q-O の追加要件：「マスタ管理」が必要

> サブシステム構成、開発工程、機能一覧、サブシステム別機能別開発規模や、設計書・定義書の文字数などの登録も必要

これは AI 機能とは別の、独立したマスタ管理機能が必要という意味と理解しました。これは設計の前提を変える重要な追加です。

従来の理解：
   AppConfig.ts に分類体系・閾値が固定されている
   サブシステム/機能定義もコード内
        ↓
新しい理解：
   独立した「マスタ管理機能」が必要
   ・サブシステム構成
   ・開発工程定義
   ・機能一覧（サブシステム別）
   ・機能別開発規模（KLOC, SP）
   ・設計書/定義書の文字数（後述の指摘密度計算に必須）
   ・要員情報・スキル
   ・指摘原因分類体系
   ・閾値・係数
        ↓
保存方式の選択肢：
   A) ローカルストレージ（ブラウザ内）
   B) JSON ファイル（Drive 同期）
   C) Firestore（既存基盤を活用）
   D) Google Sheets を読み取り

→ 重大な質問：このマスタ管理機能は、現在の wf-quality-prototype4（ブラウザ完結）のスコープに収まるかを確認させてください。

ブラウザ完結のままだと、マスタを変更するたびにビルドし直す or ブラウザのストレージに保存する形になります。本格的な「マスタ管理」を実装するなら、Firestore など永続化基盤が必要になります。

---

最終確認したい3点

Q-P. マスタ管理の永続化方式

「設定」機能から登録するマスタの保存先は？

• A) ブラウザのローカルストレージ
• 利点：追加実装ゼロ、ブラウザ完結を維持
• 欠点：ブラウザを変えると見えない、PMと委託先で別データ、消える可能性
• B) Drive上のJSONファイル（手動同期）
• 利点：複数人で共有可能、エクスポート可能
• 欠点：手動アップロード/ダウンロードが必要
• C) Firestore に保存（自動同期）
• 利点：PMと委託先がリアルタイム共有、永続的
• 欠点：制約「外部送信不可」と矛盾しないか確認が必要（GoogleWorkspaceの一部として許容できるか？）
• D) Google Sheets に保存し、起動時に読込み
• 利点：人間が直接編集可能、馴染みのあるUI
• 欠点：Sheets は遅いのでQ7制約「JSON/CSV極力」と矛盾しないか

→ 制約条件と運用要件のバランスから、どれが最も現実的ですか？

Q-Q. マスタ機能と AI 機能の開発順序

マスタ管理機能の実装にはかなりの工数がかかります。AI 機能との順序は：

• A) マスタ機能を先に実装 → そのうえで AI 機能を組む（手戻りなし、初期工数大）
• B) AI 機能を先に CSV 直接読込で実装 → 後からマスタ機能を追加（早期成果、後で改修）
• C) 並行開発（リソースがあれば最速）
• D) マスタは最小限（必須項目だけ） → AI と並行

どの順序がプロジェクトの状況に合いますか？

Q-R. マスタ機能のスコープ

Q-O で挙げられたマスタ：

1. サブシステム構成
2. 開発工程
3. 機能一覧
4. サブシステム別機能別開発規模
5. 設計書/定義書の文字数

このうち、最初のリリースで必須なものはどれですか？ 全部だとスコープが大きいので、優先順位を伺います。

私の推測：

• 必須：1, 2, 3, 4（AI 分析の入力に必須）
• 第2優先：5（指摘密度の分母として必要だが、当面は省略可）
• 追加候補：要員マスタ、スキルマスタ、指摘原因分類体系、閾値設定

合っていますか？

---

認識合わせメモの更新草案（プレビュー）

最終確認用に、いただいた回答を反映した認識合わせメモのプレビューをお見せします。これでよければ、正式に Markdown ファイルとして起こします。

# 認識合わせメモ：品質×進捗 統合リスク管理 (Edge AI)

## プロジェクト目的
「進捗遅延 → 品質劣化」の連鎖を、プロセスで発生する事実をリアルタイムで可視化することで、
PMが工程内で対策を打てる仕組みを作る。

## AI が果たす3層構造

### 第1層：信頼性ガード（最優先・分析前提条件のチェック）
- データそのものの健全性監視
- 外部レビュー記録の確認完了率
- バグ管理表の整合性チェック（Level 1：論理矛盾の検出）
- 入力ミス・必須項目欠落・分類体系逸脱の検出
- AI が「このデータで分析して大丈夫」と保証する役割

### 第2層：予兆抽出
- 信頼できる事実からのリアルタイム集計
- 指摘原因分類の傾向分析
- 前工程に遡る手戻りリスク提示

### 第3層：PMアクション材料生成
- 委託先オーダー材料の自動生成
- 工程別品質報告会のインプット提供

## 設計原則
- ✅ エッジAI（ブラウザ内完結・外部送信ゼロ）
- ✅ 営業日ごとの自動更新
- ✅ 標準化定義書を AI 機能の前段として作成
- ✅ 設定機能経由でカスタマイズ（コード直接編集不可）
- ✅ AI は発見と可視化まで（判断は人間）
- ✅ PM だけでなく委託先も見ることで自浄作用を促す
- ✅ PM画面と委託先画面はタブで切替（同URL）
  - PM視点：要約＋警告（判断負荷を軽減）
  - 委託先視点：指摘リスト＋処置ガイド（処置直結）

## 出力形式
- A: ダッシュボード上の常時表示パネル
- B: 朝会用の固定レポート画面（営業日朝のスナップショット）
- C: 履歴の保存（後で振り返り可能）

## 必要なマスタ機能（独立した「設定」機能として実装）
- サブシステム構成
- 開発工程定義
- 機能一覧（サブシステム別）
- 機能別開発規模（KLOC, SP）
- 設計書/定義書の文字数（指摘密度の分母）
- 要員情報・スキル
- 指摘原因分類体系
- 閾値・係数
（※ 永続化方式は協議中）

## 段階的成果物
1. 標準化定義書（外部レビュー・バグ管理・分類体系・整合性ルール）
2. マスタ管理機能（設定）
3. AI機能（3層構造）
4. PMビュー / 委託先ビュー
5. 履歴管理機能

## 既存ユースケース提案の位置付け
- ① 異常スパイク検知 → 第2層
- ② 品質劣化早期警報 → 第2層の核
- ③ 重大度予測 → 一旦保留
- ④ リスクスコア → 第2層に統合
- ⑤ 出荷判定支援 → 第3層（品質報告会材料）
- ⑥ クラスタリング → 一旦保留
- ⑦ 類似不具合検出 → 第1層（整合性チェックの一部・将来拡張）
- ⑧ レビュー指摘パターン → 第2層に統合

---

次のステップ

Q-P, Q-Q, Q-R にお答えいただいたら、上記メモを正式な Markdown ファイルとして書き起こし、保存場所をご相談したうえで保存します。

そのうえで合意できたら、「品質×進捗 統合リスク管理機能の設計提案」 に初めて進みます。

ここで前提合意フェーズが終わるはずです。お返事をお待ちしています。

重要な制約条件の再確認ありがとうございます。これは Q-P（マスタ永続化方式）の選択肢を根本から絞り込む内容ですので、私の認識を更新して提案を再構成します。

---

制約条件を踏まえた選択肢の再評価

永続化方式	制約への適合性	評価
❌ Firestore	「外部データ送信不可」と矛盾（Google Cloud は Workspace ではなく GCP）	却下
⚠️ Google Sheets	Workspace内 / 共有可。ただし「性能が遅い」制約に抵触	マスタ管理には不適
✅ Google Drive上のJSONファイル	Workspace内 / 共有可 / 高速 / 制約と完全整合	本命
✅ ブラウザのローカルストレージ	完全ローカル / 高速 / 個人専用	補助的に併用
❌ ファイルサーバー	「サーバーなし」制約	却下
❌ 外部DB / SaaS	「外部送信不可」制約	却下

→ マスタ管理の永続化は「Drive 上の JSON ファイル」が唯一の現実解となります。

---

制約から導かれる新しい設計上の真実

真実1：単一HTMLで配布される「アプリケーション」

配布形態：
  単一HTML 1ファイル（vite-plugin-singlefile でビルド）
       ↓
  Drive に配置 → ユーザーがブラウザでDriveから直接開く
       ↓
  サーバー不要でアプリが起動

真実2：マスタ＝Drive上のJSON、アプリ＝単一HTML

Drive フォルダ構成例：
  /品質管理ダッシュボード/
     ├── app.html               ← アプリ本体（vite ビルド成果物）
     ├── masters/
     │    ├── subsystems.json
     │    ├── phases.json
     │    ├── functions.json
     │    ├── personnel.json
     │    └── thresholds.json
     ├── data/
     │    ├── defects.csv       ← 委託先がアップロード
     │    ├── reviews.csv
     │    ├── progress.csv
     │    └── wbs.csv
     └── history/
          └── snapshot_2026-05-04.json  ← 朝会用スナップショット

真実3：データの読込み方式

ブラウザから Drive 上のファイルを読む方法は2つ：

方式	利点	欠点
A) ユーザーがファイルを手動アップロード（input type=file）	認証不要・APIキー不要・制約と完璧に整合	毎回操作必要
B) Google Drive API 経由で自動読込	自動化可	OAuth認証必要・APIキー必要・制約抵触の可能性

→ A方式が制約と完全に整合します。「Driveから手動でファイルを開く・保存する」UXが基本になります。

真実4：書き込みも手動ダウンロード

マスタを編集した結果は、ブラウザ内で JSON を生成 → ユーザーがダウンロード → Driveに上書き という流れになります。

編集フロー：
  画面で「サブシステム追加」操作
       ↓
  ブラウザのメモリ上で JSON 更新
       ↓
  「保存」ボタン → blob ダウンロード（サーバー不要）
       ↓
  ユーザーが Drive にアップロード（または上書き）
       ↓
  次回起動時、ユーザーが新しい JSON を読み込む

これは煩雑ですが、制約を満たす唯一の方法です。

---

制約適合性の最終確認

制約	本提案での扱い
1. Google Workspace のみ	✅ Drive のみ使用、API使用なし
2. Gemini API キー不可	✅ AI推論は全てブラウザ内（simple-statistics, ml-cart）
3. 外部データ送信不可	✅ ファイル読込は手動upload、書込は手動download
4. ファイル共有サーバーなし	✅ Drive を共有手段とする
5. データ共有 Drive のみ	✅ マスタもデータも Drive 上
6. JSON 優先	✅ マスタは JSON、データは CSV（既存維持）
7. 単一HTML配布	✅ vite-plugin-singlefile で実現済み

---

認識合わせメモの再更新（最終プレビュー）

制約条件の再確認を反映して、認識合わせメモを更新したプレビューをお見せします：

# 認識合わせメモ：品質×進捗 統合リスク管理 (Edge AI)

## プロジェクト目的
「進捗遅延 → 品質劣化」の連鎖を、プロセスで発生する事実を
リアルタイム可視化することで、PMが工程内で対策を打てる仕組み。

## 配布・運用形態（制約準拠）
- 単一HTML（vite-plugin-singlefile でビルド）
- Google Drive に配置 → ブラウザで直接起動
- マスタ：Drive上のJSON / 手動アップロード読込・手動ダウンロード保存
- データ：CSV / 手動アップロード読込
- 履歴スナップショット：JSON / 手動ダウンロード保存
- サーバーゼロ・外部API呼び出しゼロ・ブラウザ内完結

## AI が果たす3層構造
### 第1層：信頼性ガード（最優先）
- データ健全性監視 / 整合性チェック (Level 1)
- 外部レビュー記録の確認完了率
- 必須項目欠落・分類体系逸脱・論理矛盾の検出

### 第2層：予兆抽出
- 信頼できる事実からのリアルタイム集計
- 指摘原因分類の傾向分析・前工程手戻りリスク

### 第3層：PMアクション材料生成
- 委託先オーダー材料・品質報告会のインプット

## 設計原則
- ✅ エッジAI（ブラウザ内完結・外部送信ゼロ）
- ✅ 営業日ごとの自動更新
- ✅ 標準化定義書を AI 機能の前段として作成
- ✅ 設定機能経由でカスタマイズ
- ✅ AI は発見と可視化まで（判断は人間）
- ✅ PM/委託先 はタブで切替（同URL・見せ分け）

## 出力形式
- A: ダッシュボード常時表示
- B: 朝会用スナップショット
- C: 履歴保存（JSONダウンロード）

## マスタ管理機能（独立実装）
保存方式：Drive上のJSONファイル
- subsystems.json（サブシステム構成）
- phases.json（開発工程）
- functions.json（機能一覧）
- scope.json（機能別開発規模・文字数）
- personnel.json（要員情報）
- categories.json（指摘原因分類体系）
- thresholds.json（閾値・係数）

## マスタ機能 vs AI機能の開発順序（要協議：Q-Q）
## マスタの最初リリース範囲（要協議：Q-R）

## 段階的成果物
1. 標準化定義書（Markdownで作成）
2. マスタ管理機能（最低限の必須項目から）
3. AI機能（3層構造、優先度に従って段階的）
4. PMビュー / 委託先ビュー（タブ切替）
5. 履歴管理機能

## 既存8ユースケースの位置付け
- ① 異常スパイク検知 → 第2層
- ② 品質劣化早期警報 → 第2層の核
- ③ 重大度予測 → 一旦保留
- ④ リスクスコア → 第2層に統合
- ⑤ 出荷判定支援 → 第3層
- ⑥ クラスタリング → 一旦保留
- ⑦ 類似不具合検出 → 第1層（Level 3 への将来拡張）
- ⑧ レビュー指摘パターン → 第2層に統合

---

残された3つの確認事項

制約再確認により Q-P は事実上「Drive 上 JSON」で確定しましたので、残るは Q-Q、Q-R、そして新たに浮上した Q-S を確認させてください。

Q-Q.（再掲）マスタ機能と AI 機能の開発順序

• A) マスタ機能を先に実装 → そのうえで AI 機能を組む（手戻りなし）
• B) AI 機能を先に CSV 直接読込で実装 → 後からマスタ機能を追加
• C) マスタは最小限（必須項目だけ） → AI と並行開発

Q-R.（再掲）マスタ機能の最初リリース範囲

候補のうち、最初に必須なものはどれですか？

1. サブシステム構成
2. 開発工程
3. 機能一覧
4. サブシステム別機能別開発規模
5. 設計書/定義書の文字数
6. 要員情報・スキル
7. 指摘原因分類体系
8. 閾値・係数

Q-S（新規）UX として「手動アップロード」運用は許容できますか？

制約上、データ・マスタの読込は毎回ファイル選択ダイアログを経由します。これは：

• A) 許容できる：起動時に1回ファイルを指定するだけなら問題ない
• B) 改善したい：「最近開いたファイル」のような工夫がほしい
• C) 別案を検討したい：例えば、HTMLにマスタを埋込み配布する方式も可能（変更時は再ビルド・再配布）

C案も技術的には可能です。マスタが頻繁に変わらないなら、HTML埋込み方式は煩雑さがゼロになります。

---

次のステップ

Q-Q, Q-R, Q-S にお答えいただいたら、認識合わせメモを正式に Markdown ファイルとして書き起こします。保存場所のご希望（例：C:\Content_Factory\P0600_MART\wf-quality-prototype4\docs\ 等）も教えてください。

メモが合意できたら、はじめて 「品質×進捗 統合リスク管理機能の設計提案」 に進みます。

これが前提合意フェーズの最終チェックとなります。お返事をお待ちしています。

ご回答ありがとうございます。

ただ、Q-R の最後の部分について、入力に重複があるようです。確認させてください。

---

確認したい点

Q-R の回答について

> Q-R.すべて。但し、「要員情報・スキル」ではなく、要員情報・スキル

この一文は、「要員情報・スキル」ではなく、要員情報・スキル と同じ表記が並んでいて、何をどう変更したいのか読み取れませんでした。

考えられる可能性：

• A) 「要員情報・スキル」を分離したい
• 「要員情報」（氏名、参入日、所属など）
• 「スキル情報」（保有スキル、レベル、経験年数など）
• → 別マスタに分けて管理する
• B) 「要員情報のみ」で「スキル」は不要
• スキルマスタは作らず、要員マスタだけにする
• C) 「スキル」の定義を変えたい
• 例：「スキル」ではなく「役割」や「経験案件」など別名
• D) 表記の打ち間違い
• 単に同じ表記が2回入っただけで、意図は別の文章

どれが正しい意図ですか？もしくは別の意図があれば教えてください。

---

Q-S（前回の質問・お答えいただいていません）

UX として「手動アップロード」運用は許容できますか？

• A) 許容できる
• B) 改善したい（最近開いたファイル機能等）
• C) HTMLにマスタ埋込み配布（変更時は再ビルド）

→ Drive上 JSON にする以上、毎回の起動時にファイル選択操作が必要になります。これが許容範囲か、別の方式を検討するかご指示ください。

---

ここまでで確定した内容（再掲）

質問	確定回答
Q-K. 標準化の責任範囲	OK（標準化定義書を私が起案 → レビュー → 合意 → 実装）
Q-L. 委託先向け画面	A（同URL・タブ切替） + PMの判断軽減 + 委託先の処置直結
Q-M. 整合性チェック	Level 1（論理矛盾） + 分析前提条件のチェック役割
Q-N. 出力形式	A（常時表示）+ B（朝会用）+ 履歴
Q-O. カスタマイズ	「設定」機能 + マスタ管理（コード直接編集なし）
Q-P. 永続化方式	Drive上のJSON（制約整合性により確定）
Q-Q. 開発順序	A（マスタ機能を先に実装 → そのうえで AI 機能）
Q-R. マスタ最初リリース範囲	すべて（1〜8、ただし要員情報・スキルの解釈要確認）

---

次のステップ

Q-R の意図確認 と Q-S（手動アップロードの許容性） にお答えいただいたら、認識合わせメモを正式な Markdown ファイルとして書き起こします。

この2点が確定すれば、本当に前提合意フェーズが完了します。

ご回答ありがとうございます。ようやく前提条件の全体像が見えました。

ただし Q-S のご回答は アーキテクチャ全体に大きな影響を与える追加要件を含んでいますので、認識合わせメモを書く前に、最後にもう一度だけ確認させてください。

---

Q-R の確定理解

> 「要員情報・スキル」ではなく、「要員情報・プロジェクト参入日」

→ スキル情報は不要（過去の議論でも「氏名と参入日のみ」と仰っていました）。要員マスタは最小構成で：

• assignee_id
• 氏名
• プロジェクト参入日

この情報のみとし、スキル属性は記録しないという意図ですね。これで合っていますか？

---

Q-S のご回答の重要な意味

> あなたに渡す前にpythonで事前にマート作成する必要があると想定しています

これは設計の前提を根本的に変える重要な追加要件です。私の理解：

従来の私の想定：
   委託先が CSV/JSON を Drive に置く
        ↓
   ブラウザがそれを直接読む
        ↓
   AI が分析

あなたの新しい設計：
   委託先が「生データ」（Excel等）を Drive に置く
        ↓
   【Pythonによる事前マート化処理】 ← 新しい段階
        ・データクレンジング
        ・複数ソースの統合
        ・正規化
        ・集計済みデータの作成（マート＝Data Mart）
        ↓
   マート化された JSON/CSV を Drive に保存
        ↓
   ブラウザがマートを読む
        ↓
   AI が分析

つまり、システム全体は 2段構成 になります：

1. データ加工層（Python・バッチ実行）
2. 可視化・AI分析層（ブラウザ・エッジAI）

---

この設計変更の含意（私の理解）

観点	従来想定	新しい想定
データの形	生データそのまま	マート化済み（クリーン・整形済み）
整合性チェック	ブラウザ内 AI が実施	Python が事前に実施 → 結果を AI が見るだけ
重複排除・正規化	ブラウザ内	Python で処理
集計処理	ブラウザ内	事前集計済みもありうる
ブラウザ側の役割	データ処理 + 可視化 + AI	可視化 + AI に集中（軽量化）
起動速度	データ量に依存	高速（マート化済み = 軽量）

→ ブラウザ側はマート前提で、データ処理ロジックは Python に寄せる設計が自然です。

合っていますか？

---

制約条件との整合性確認

新しい2段構成は制約条件と整合します：

制約	適合性
1. Google Workspace のみ	✅ Python はローカルPCで実行・Drive 共有
2. Gemini API 不可	✅ Python も AI APIを使わない
3. 外部送信不可	✅ Python ローカル実行・Drive アップロードのみ
4. ファイルサーバーなし	✅ Drive 経由
5. データ共有 Drive のみ	✅ Drive
6. JSON 優先	✅ Python 出力は JSON

→ Python による事前マート化は制約と完全整合します。

---

確認したい最後の点

Q-T. Python マート化処理の実行責任

Python スクリプトは誰が・どこで・いつ実行しますか？

• A) PMの PC で手動実行（PMが委託先から受け取った Excel を Python に通す）
• B) 委託先が手元で実行してから Drive にアップロード
• C) Google Apps Script で代替（Workspace内で完結）→ ただし性能制約あり
• D) 別案

→ 運用フローの責任分担に関わる重要な点です。

Q-U. Python マート化処理の実装範囲

Python はどこまで責任を持ちますか？

• A) 単純なデータ統合のみ（Excel → JSON の変換）
• B) クレンジング込み（重複除去・正規化・必須項目チェック）
• C) 整合性チェックも実施（論理矛盾検出・分類体系チェック）
• D) 集計処理まで（日次・サブシステム別の集計マート作成）
• E) 全部（A+B+C+D）

→ Python と ブラウザ側 AI の責任分担が決まります。

たとえば、整合性チェックを Python が事前にやるなら、AI 第1層（信頼性ガード）の役割は「警告の表示」のみになります。

Q-V. マート化のトリガー

Python マート化処理はいつ実行されますか？

• A) 営業日朝に自動実行（タスクスケジューラ等）
• B) PM が手動実行（必要時に都度）
• C) データ更新時に手動実行（委託先報告を受けたタイミング）

→ Q-J「営業日ごと自動更新」と関連します。マート化が朝に走るなら、ブラウザは朝の最新マートを読む形。

Q-W. Python スクリプトもプロジェクト成果物に含めるか

Python スクリプトはこのプロジェクトの納品成果物として作成・管理しますか？

• A) 含める（Python スクリプトも当方で開発・納品物として位置付け）
• B) 含めない（マート化処理は別途・別チームで対応）
• C) 並行開発（このプロジェクトとは別プロジェクトだが、私が並行で開発）

→ プロジェクトスコープの境界線として重要です。

---

認識合わせメモの再々更新（プレビュー）

新しい2段構成を反映したプレビュー：

# 認識合わせメモ：品質×進捗 統合リスク管理 (Edge AI)

## システム全体構成（2段構成）

### 段階1：データマート化層（Python）
  入力：委託先の生データ（Excel/CSV）
  処理：データクレンジング・統合・整合性チェック・正規化
  出力：マート化済み JSON/CSV → Drive 保存
  実行：（要協議：Q-T, Q-V）

### 段階2：可視化・AI分析層（単一HTML）
  入力：Drive 上のマート済みデータ（手動アップロード）
  処理：エッジAI（simple-statistics, ml-cart）
  出力：ダッシュボード / 朝会レポート / 履歴 JSON
  配布：単一HTML（vite-plugin-singlefile）

## プロジェクト目的（変わらず）
「進捗遅延 → 品質劣化」の連鎖を、プロセスで発生する事実を
リアルタイム可視化することで、PMが工程内で対策を打てる仕組み。

## AI が果たす3層構造（責任分担を再整理）

### 第1層：信頼性ガード
  - Python 段階：論理矛盾の検出・必須項目チェック・正規化
  - ブラウザ段階：警告の表示・データ品質スコアの可視化
  - （※ 整合性チェックは Python が主担当に変更）

### 第2層：予兆抽出（ブラウザ側）
  - 信頼できる事実からのリアルタイム集計
  - 指摘原因分類の傾向分析
  - 前工程手戻りリスク提示

### 第3層：PMアクション材料生成（ブラウザ側）
  - 委託先オーダー材料・品質報告会のインプット

## 設計原則（追加）
- ✅ 2段構成（Python + 単一HTML）
- ✅ ブラウザ側は「マート前提」で軽量化
- ✅ 重い処理（クレンジング・集計）は Python へ寄せる

## 制約適合性
すべての制約に整合（Drive 経由・外部送信ゼロ・GeminiAPI不要）

## マスタ管理（最初リリース範囲）
- subsystems.json（サブシステム構成）
- phases.json（開発工程）
- functions.json（機能一覧）
- scope.json（機能別開発規模・文字数）
- personnel.json（要員情報：assignee_id・氏名・参入日のみ）
- categories.json（指摘原因分類体系）
- thresholds.json（閾値・係数）
（保存方式：Drive上のJSON）

## 開発順序
1. 標準化定義書（Markdown）
2. マスタ管理機能（独立実装）
3. AI機能（3層構造、優先度に従って段階的）
4. PM/委託先ビュー（タブ切替）
5. 履歴管理機能

## 段階的成果物
- Python マート化スクリプト （要協議：Q-W）
- 標準化定義書（Markdown）
- マスタ管理機能
- AI機能（3層）
- ダッシュボード（PM/委託先ビュー）
- 朝会用スナップショット機能
- 履歴管理機能

---

次のステップ

Q-T, Q-U, Q-V, Q-W にお答えいただいたら、認識合わせメモを正式な Markdown ファイルとして書き起こします。

保存場所のご希望もお伝えください（候補：C:\Content_Factory\P0600_MART\wf-quality-prototype4\docs\）。

これが本当に前提合意フェーズの最終確認です。お返事をお待ちしています。

全ての前提条件が固まりました。前提合意フェーズが完了しました。

これより認識合わせメモを正式な Markdown ファイルとして作成します。

---

最終確認サマリー（合意した前提）

システム構成

段階1：Python マート化処理（別プロジェクト・私の納品物外）
   実行：Windows タスクスケジューラ（前日18時自動起動）
   実行PC：あなたのPC
   出力：私が指定する形式の JSON を、私が指定する場所に格納
   詳細：実データのある環境で別途検討
        ↓
段階2：単一HTML ダッシュボード（私の納品物）
   入力：Drive上のマート化済みJSONを手動アップロード
   処理：エッジAI（simple-statistics, ml-cart）
   出力：ダッシュボード / 朝会レポート / 履歴JSON

プロジェクトスコープの境界線

担当	私の責任	あなたの責任
Python マート化スクリプト	❌	✅（要件は私から提示）
マート JSON フォーマット定義	✅（要件として提示）	❌
単一HTML ダッシュボード	✅	❌
マスタ管理機能	✅	❌
AI 機能（3層構造）	✅	❌
標準化定義書	✅（起案）+ 議論	✅（レビュー・合意）

---

これから作成する認識合わせメモの内容

以下を C:\Content_Factory\P0600_MART\wf-quality-prototype4\docs\agreement-edge-ai-risk-management.md に保存します。

ファイル名は変更ご希望あれば教えてください。場所もこれでよろしいでしょうか。

メモの内容は、これまでの全質問・全回答を反映した以下の構成です：

1. プロジェクト目的
2. システム全体構成（2段構成）
3. AI が果たす3層構造
4. 設計原則
5. 出力形式
6. マスタ管理機能（最初リリース範囲）
7. プロジェクトスコープ境界線
8. 制約適合性チェック
9. 段階的成果物
10. 既存8ユースケースの位置付け再整理
11. 開発順序
12. 用語集（合意した用語の定義）

---

進め方の確認

以下の流れで進めます：

1. 認識合わせメモを作成（Markdownファイル保存）
2. あなたがレビュー → 修正コメント → 合意
3. 合意後に 「品質×進捗 統合リスク管理機能の設計提案」を作成（Markdownファイルとして別保存）
4. 設計提案の合意後に、標準化定義書の起案
5. 標準化定義書の合意後に、実装プラン作成
6. 実装プランの合意後に、コーディング開始

これでよろしいですか？ もし保存先・ファイル名・進め方に修正があればお知らせください。

修正がなければ、「進めてOK」とお返事いただいた時点で、認識合わせメモの作成に着手します。まだ作成しませんので、先に承認をお願いします。

承知しました。実行を開始します。

データ生成完了（マスタ7ファイル + 事実5ファイル）。次は Vite プロジェクトのセットアップです。

Now I'll create the main view components (Layer 1, 2, 3 and the layout).

✅ プロトタイプ構築完了

構築したもの

C:\Content_Factory\P700_ProjectManegement\
├── .claude/settings.local.json      # 権限設定（P700配下を全許可）
├── README.md                        # プロジェクト概要
├── docs/
│   ├── 01_agreement_edge_ai_risk_management.md   # 認識合わせメモ
│   ├── 02_design_proposal.md                     # 設計提案書
│   └── 03_standardization.md                     # 標準化定義書
├── scripts/
│   └── generate_dummy_data.py       # 疑似データ生成スクリプト
├── data/                            # マート（マスタ + 事実）
│   ├── masters/    7ファイル
│   └── facts/      5ファイル
└── dashboard/                       # Vite + React-TS ダッシュボード
    ├── src/                         # 全実装ソース
    │   ├── types/                   # 型定義（master/fact/ai）
    │   ├── data/                    # データ層（loader + zustand store）
    │   ├── ai/                      # AI 3層
    │   │   ├── stats.ts             # 統計ヘルパー（mean/std/Z-score/MK検定）
    │   │   ├── layer1_reliability.ts # 第1層 信頼性ガード
    │   │   ├── layer2_anomaly.ts    # 第2層 予兆抽出
    │   │   └── layer3_action.ts     # 第3層 PMアクション材料
    │   └── components/
    │       ├── pm/      PMビュー（5パネル）
    │       ├── vendor/  委託先ビュー（指摘リスト + 処置ガイド）
    │       ├── settings/ 設定（マスタ表示）
    │       └── common/   Card・StatusBadge
    └── dist/index.html              # 単一HTML 591KB（ビルド成果物）

動作検証結果

項目	結果
Python データ生成	✅ 12 JSON ファイル出力
TypeScript 型チェック	✅ エラーなし
Vite ビルド	✅ dist/index.html 591KB 生成
HTTP 配信確認	✅ HTML/JSON すべて 200 応答

データ規模

• サブシステム: 4 / 機能: 25 / 要員: 20名
• 外部レビュー: 300 件（要件定義/基本設計/詳細設計 各100件）
• バグ管理: 1,532 件（150〜250 × 7工程）
• WBSタスク: 175 件 / 課題: 34 件 / 進捗: 352 件
• 意図的に整合性違反データを混入（Layer1で検出するため：分類体系逸脱・必須項目欠落）

起動方法

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

ブラウザで http://localhost:5173/ を開いてください。

または本番ビルド版を：

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run preview

確認できる機能

📋 PMビュー

• 信頼性スコア（7チェック項目を一覧表示、総合スコア算出）
• 異常スパイク検知（Z-scoreチャート + ±3σ閾値線）
• レビュー指摘パターン（工程フィルタ付き上位12件）
• サブシステム別リスクスコア + Mann-Kendallトレンド検定
• 遅延タスク Top10 + 委託先オーダー文面自動生成（クリップボードコピー対応）

🔧 委託先ビュー

• 自データ品質スコア（PMが見ているのと同じ事実）
• 処置すべき指摘リスト（フィルタ付き）
• 処置ガイド（推奨フローを6ステップで提示）

⚙️ 設定

• マスタ管理（7種類のタブ切替）

合意した認識合わせメモ・設計提案書・標準化定義書をベースに、エッジAIプロトタイプの初期構築が完了しました。

「処置すべき指摘リスト」は、🔧 委託先ビュー タブにあります。

---

表示場所

ダッシュボード上部のタブから 「🔧 委託先ビュー」 をクリックしてください。

┌──────────────────────────────────────────────┐
│ 🤖 品質×進捗 統合リスク管理ダッシュボード      │
├──────────────────────────────────────────────┤
│ [📋 PMビュー] [🔧 委託先ビュー] [⚙️ 設定]    │  ← ここを選択
└──────────────────────────────────────────────┘

---

委託先ビュー の構成（上から順に）

┌─ 上段：自データ健全性 ─────────────────────────┐
│ あなた側のデータ品質スコア (例: 72/100)         │
│ 改善が必要な項目リスト                          │
└──────────────────────────────────────────────┘
┌─ 下段（左）：処置すべき指摘リスト ──────────┐ ┌─ 下段（右）：処置ガイド ─────┐
│ ID / 工程 / 機能 / 指摘 / 状態          │ │ 行クリックで詳細表示          │
│ R-001  詳細設計  受注登録 ... 未着手 🔴 │ │ 推奨処置フロー（6ステップ）  │
│ R-002  基本設計  在庫照会 ... 確認待ち  │ │                              │
│ ...                                    │ │                              │
└──────────────────────────────────────┘ └────────────────────────────┘

---

操作方法

1. 🔧 委託先ビュー タブをクリック
2. 中段左側の表が「処置すべき指摘リスト」
3. 上部のドロップダウンでフィルタ切替：
• 未完了のみ（デフォルト）— Open / InProgress / ResolvedPending
• 確認待ちのみ — ResolvedPending のみ
• すべて — 全件
4. 任意の行をクリックすると、右側の「処置ガイド」に詳細と推奨処置フローが表示されます

---

ダッシュボードが起動していない場合

以下を実行してから上記のタブを開いてください。

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

ブラウザで http://localhost:5173/ を開く。

別のアプリケーションが起動されています。

---

状況の説明

スクリーンショットの 「WF品質 可視化プロトタイプ」 は、今回構築した P700 ダッシュボードではなく、以前のセッションで構築した別のシステム（wf-quality-prototype 系列） です。

見分け方

項目	今回作成した P700	表示中のもの
タイトル	🤖 品質×進捗 統合リスク管理ダッシュボード	WF品質 可視化プロトタイプ
配色	白系（明るい）	ダーク（黒紫）
タブ	📋 PMビュー / 🔧 委託先ビュー / ⚙️ 設定	なし（単一画面）
データ	data/masters/*.json	public/sample-defects.csv
場所	C:\Content_Factory\P700_ProjectManegement\	C:\Content_Factory\P0600_MART\wf-quality-prototype*\

---

正しい起動方法

今回のダッシュボードを起動するには、以下を実行してください。

1. 別のターミナルが起動している場合は終了

VSCode の各ターミナルパネルで Ctrl + C を押して、現在動いている dev サーバーを停止してください。

2. P700 ダッシュボードを起動

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

3. ブラウザで開く

ターミナルに表示される URL（通常 http://localhost:5173/）をブラウザで開いてください。

※ 既に同じポートで他アプリが動いていると 5174、5175... と自動で変わります。表示されたURLをそのまま開いてください。

---

表示されるはずの画面

正しく起動すると、以下のヘッダーが表示されます：

┌─────────────────────────────────────────────────────────────┐
│ 🤖 品質×進捗 統合リスク管理ダッシュボード  Edge AI · Prototype │
│ 外部送信ゼロ · ブラウザ内完結 · 単一HTML配布                  │
│                       レビュー 300 / バグ 1532 / WBS 175    │
├─────────────────────────────────────────────────────────────┤
│ [📋 PMビュー] [🔧 委託先ビュー] [⚙️ 設定]                    │
└─────────────────────────────────────────────────────────────┘

「🔧 委託先ビュー」タブをクリックすると、処置すべき指摘リストと処置ガイドが表示されます。

---

確認したい場合

正しいダッシュボードがビルド済みかを確認するには：

ls C:\Content_Factory\P700_ProjectManegement\dashboard\dist\index.html

このファイル（591KB）があれば、以下でも動作確認できます：

start C:\Content_Factory\P700_ProjectManegement\dashboard\dist\index.html

ただし、file:// で開くと CORS 制約で JSON 読込みが失敗する可能性があるため、npm run dev か npm run preview 経由を推奨します。

現状：ドリルダウンは未実装

両パネルとも、現在は表示のみで行クリック動作はありません。

---

比較：現状のクリック対応状況

パネル	現状	該当コード
① 第3層：遅延タスクTOP10	✅ クリックで右側に委託先オーダー文面が生成される	ActionPanel.tsx
② 委託先ビュー：処置すべき指摘リスト	✅ クリックで処置ガイドが右に表示	VendorView.tsx
③ レビュー指摘パターン分析	❌ クリック動作なし	ReviewPatternPanel.tsx
④ サブシステム別リスクスコア	❌ クリック動作なし	RiskPanel.tsx

---

技術的に追加可能か：両方とも可能です

データはすべて masters と facts がメモリにあるため、行クリックで該当データを抽出して表示できます。

③ レビュー指摘パターン分析 の場合

「詳細設計 × 仕様理解不足 (22件)」の行をクリック → 該当する22件のレビュー記録一覧をモーダル/サイドパネルで表示

• 該当機能・指摘者・指摘日・現在状態などをテーブルで提示
• さらに行をクリックすると個別レビュー記録の詳細（書類名、ページ数、確認状態など）

④ サブシステム別リスクスコア の場合

「在庫管理サブシステム (リスク73)」の行をクリック → 当該サブシステムの詳細を表示

• 機能別のリスク内訳
• 該当バグ一覧（重大度別）
• 該当レビュー指摘一覧
• WBS遅延タスク一覧
• 「主要寄与要因 Top 3」の根拠データ

---

議論が必要な設計判断

このルールに従い、実装前に確認させてください：

Q1. ドリルダウンの深さ

• A) 1階層：行クリック → 該当レコード一覧モーダル
• B) 2階層：A → さらに個別レコード詳細モーダル
• C) 3階層：B → 関連データ（同機能の他バグ等）も辿れる

Q2. 表示形式

• A) モーダル（中央にポップアップ、背景暗く）
• B) サイドパネル（右からスライドイン）
• C) 別ペイン（同画面内に表示エリア追加、現状の③④パネルと同様）
• D) 別タブで開く

Q3. 対象は4パネル全部か

ドリルダウン未対応の他パネルも追加対象に含めますか？

パネル	追加候補か
第1層：信頼性ガード（7チェック項目）	クリックで affected_records の詳細表示
第2層：異常スパイク検知（Z-scoreチャート）	バーをクリックでその日のバグ一覧
第2層：レビュー指摘パターン	今回の対象
第2層：サブシステム別リスクスコア	今回の対象
第3層：遅延タスクTOP10	既に対応済み
委託先ビュー：指摘リスト	既に対応済み

Q4. 実装のスコープ

• A) 今回の2パネルのみ（最小、すぐ実装）
• B) PMビューの全パネルに統一実装（一貫性が高い）
• C) 第1層含むほぼ全画面（最大、工数大）

---

ご指示ください

上記 Q1〜Q4 にお答えいただければ、実装方針を確定します。

すぐ実装に入ってよい場合は「A/A/今回の2パネル/A」のように選択をお伝えください。

特に深く考えずに「全部対応・モーダル・1階層」でも構わなければ、最も多くのケースで自然な体験になります。

全パネルにモーダル形式のドリルダウンを実装します。

Now let me update each panel to add drill-down. Starting with ReviewPatternPanel and RiskPanel:

Now update AnomalyPanel to add bar-click drill-down:

Now build and verify:

ビルド成功。全パネルにドリルダウンを追加しました（602KB）。

✅ ドリルダウン実装完了 — 全パネル対応

追加した動作

パネル	クリック対象	モーダル表示内容
第1層 信頼性ガード	各カード（7チェック項目）	該当する レビュー / バグ レコード一覧（IDが格納されているもの）
第2層 異常スパイク検知	グラフのバー（または近傍）	クリック日に起票されたバグ全件
第2層 レビュー指摘パターン	表の行	該当する 工程×原因 のレビュー指摘一覧
第2層 サブシステム別リスクスコア	表の行	当該サブシステムの 🐛 バグ / 🔍 レビュー / 📅 WBS をタブ切替で表示
第3層 遅延タスクTOP10	（既存）行クリックで右側に文面生成	—
委託先ビュー 指摘リスト	（既存）行クリックで右側に処置ガイド	—

モーダルの仕様

• 中央にオーバーレイ表示（背景は半透明＋ぼかし）
• Esc キーまたは背景クリックで閉じる
• 右上 × ボタンでも閉じる
• 大量データはモーダル内スクロール対応（max-height制御）
• ヘッダーが sticky なので、長いリストでも列名が見える

確認方法

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

ブラウザで http://localhost:5173/ を開いてください。

📋 PMビュー の以下を試してみてください：

1. 第1層の「分類体系逸脱」カードをクリック → 違反レコード一覧
2. 異常検知グラフのバーをクリック → その日のバグ一覧
3. 「詳細設計 × 仕様理解不足 (22件)」の行をクリック → 該当22件
4. 「在庫管理サブシステム」の行をクリック → タブ切替で バグ/レビュー/WBS 詳細

Vite のキャッシュ破損が疑われるエラーです。index.html を確認した上で対処します。

✅ 修正完了

原因

vite-plugin-singlefile が dev サーバー起動時にも適用されていたため、Vite 8 の HTML proxy 処理と競合してエラーが発生していました。

行った修正

1. vite.config.ts — singlefile プラグインを build 時のみ適用するよう変更

plugins: [
  react(),
  ...(command === 'build' ? [viteSingleFile()] : []),
],

2. index.html — タイトルを「品質×進捗 統合リスク管理ダッシュボード」に変更

3. Vite キャッシュ削除 — node_modules/.vite を削除して破損キャッシュをクリア

動作確認結果

• ✅ Dev サーバー起動：エラーなし（5180番ポートで起動成功）
• ✅ 本番ビルド：602.80 KB の単一HTML出力成功

起動方法

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

ブラウザに表示される URL（http://localhost:5174/ 等）を開いてください。

ブラウザタブのタイトルが 「品質×進捗 統合リスク管理ダッシュボード」 に変わっていれば成功です。

エラーが続く場合は、ブラウザを Ctrl + F5（ハードリロード）してください。

二段階のドリルダウンと、エッジAIによる偏り検出を実装します。

ビルド成功。レビュー指摘パターン分析のドリルダウンに エッジAI偏り検出 を実装しました（610KB）。

✅ 実装完了 — エッジAI動的偏り分析付きドリルダウン

新しい挙動

「詳細設計 × インターフェース不整合 (19件)」をクリックすると、モーダルが以下の構成で表示されます：

┌── 🤖 エッジAI 偏り検出 ─────────────────────────────────┐
│ 【サブシステム】「受注管理」が 11件 (58%) で偏りあり    │
│ 【機能】「受注登録」が 4件 (21%) で集中                │
│ 【重大度】「Critical」が 1件 (Z=+2.5σ で異常集中)      │
└────────────────────────────────────────────────────┘

┌── 📦 サブシステム分布 ─┐ ┌── ⚙️ 機能分布(Top10) ─┐
│ ⚠ 受注管理   ████ 11   │ │ ⚠ 受注登録 ███ 4    │
│   顧客管理   ██   5    │ │   信用調査  ██  2    │
│   請求管理   █    3    │ │   ...                │
│ Z=+2.4σ 集中傾向       │ │                       │
└──────────────────────┘ └─────────────────────┘
┌── 🔥 重大度分布 ───┐ ┌── 📊 状態分布 ────┐
│ Medium ████ 12     │ │ 完了      ████ 12  │
│ High   ██   5      │ │ 確認待ち   ██  4   │
│ Critical █  1 ⚠   │ │ 未着手    ██  3   │
└──────────────────┘ └────────────────┘

[適用中: 受注管理] [受注登録] [全クリア]

📝 該当レビュー記録 (末端 4件)
ID         サブシステム  機能      ...
R-2026-...  受注管理     受注登録  ...

エッジAIの分析ロジック

指標	計算	用途
シャノンエントロピー	−Σ p log₂(p) を正規化	0=完全集中・1=完全均等
Gini係数	1 − Σp²	集中度の代替指標
Z-score	(observed − expected) / σ	カテゴリ別の異常集中検出
集中判定	rate ≥ expected × 1.5 AND count ≥ 2	⚠ マーク表示の閾値

すべて simple-statistics 不要、自前で完結したエッジAI実装です（biasAnalysis.ts）。

操作方法

1. クリック1：パターン表の行をクリック → モーダルが開く
2. エッジAI が即座に4視点（サブシステム・機能・重大度・状態）の偏り分析を実行
3. クリック2：偏り分布の行をクリック → 末端レコードリストがフィルタされる
4. 複数のフィルタを組み合わせ可能（AND条件）
5. 「全クリア」ボタンで一発リセット

⚠ マークの意味

• カテゴリの観測値が期待値の1.5倍以上、かつ2件以上 → 統計的に有意な集中
• バーが赤色で表示され、行頭に⚠が付く
• 「ここに偏りが集中している」とAIが判定した箇所

起動

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

ブラウザで PMビュー → 「🔍 第2層：レビュー指摘パターン分析」のいずれかの行をクリックして確認してください。

閾値設定をフォームUIに変更します。スライダー＋数値入力＋整合性チェック＋JSONダウンロード対応で実装します。

ビルド成功。閾値設定をフォームUIに刷新しました（617KB）。

✅ 閾値設定UI 改善完了

新しい構成（4セクション × 13項目）

┌── 🚨 異常検知 (Z-score 閾値) ────────────────────────────────────┐
│ 警戒 Z-score   [================●==========]  2.0σ │ 1σ → 4σ    │
│ 異常 Z-score   [=========================●===]  3.0σ │ 2σ → 6σ    │
│ 重大異常 Z-score[=================●============]  6.0σ │ 3σ → 10σ   │
└────────────────────────────────────────────────────────────────┘

┌── 📈 トレンド検定 ────────────────────────────────────────────────┐
│ p値 有意水準     [=========●===============]  0.05  │ 0.001→0.2  │
│ 移動平均比率 警戒[========●================]  1.3倍  │ 1.0倍→2.5倍 │
└────────────────────────────────────────────────────────────────┘

┌── 📋 信頼性ガード ─────────────────────────────────────────────────┐
│ 確認完了率 最低基準  [================●==========]  95% │ 50%→100%│
│ 滞留判定日数        [====●=====================]  7日  │ 1日→30日 │
│ 必須項目埋め率最低基準[==============●===========]  90% │ 50%→100%│
└────────────────────────────────────────────────────────────────┘

┌── 🎯 リスクスコア重み (合計 1.00) ──────────────────────────────────┐
│ バグ密度/KLOC      [===========●===]  0.30 │ 0 → 1                │
│ 未解決Critical数   [========●======]  0.25 │ 0 → 1                │
│ レビュー指摘密度    [====●==========]  0.15 │ 0 → 1                │
│ WBS遅延数          [======●========]  0.20 │ 0 → 1                │
│ 確認完了率         [==●============]  0.10 │ 0 → 1                │
└────────────────────────────────────────────────────────────────┘

⚠ 整合性チェック（リアルタイム）
  • 警戒Z-score は 異常Z-score より小さくしてください
  • リスクスコア重みの合計は 1.0 が推奨 (現在: 0.95)

[● 未保存の変更があります]    [↶ 元に戻す] [💾 thresholds.json をダウンロード]

主な機能

機能	説明
スライダー + 数値入力	同期して動く。スライダーで直感的に、数値入力で精密に
項目別ヒント	各閾値の意味を説明（業界標準・推奨値もコメント）
単位表示	σ / 日 / % / 倍 など適切な単位を表示
リアルタイム整合性チェック	warn < critical < severe / 重み合計=1 を自動検証
未保存マーカー	変更があると「● 未保存の変更があります」と表示
元に戻す	編集前の値にワンクリックで復元
JSONダウンロード	編集結果を thresholds.json としてダウンロード（Drive 配置用）

ヒント文の例

項目	表示されるヒント
警戒 Z-score	これ以上で「警戒」(黄)。一般的に 2σ
異常 Z-score	これ以上で「異常」(赤)。業界標準 3σ
確認完了率 最低基準	工程完了の品質ゲート条件
滞留判定日数	未完了でこの日数を超えると滞留扱い

ワークフロー

1. スライダーまたは数値入力で値を変更
2. 整合性違反があればリアルタイムに警告表示
3. 「💾 thresholds.json をダウンロード」で更新版JSONを保存
4. 保存したJSONをDrive上の data/masters/thresholds.json に配置
5. ダッシュボードを再読込で反映

起動

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

⚙️ 設定 → 閾値タブを開いて確認してください。

エッジAI偏り分析を「無制限ドリルダウン（パンくず型）」に再設計します。すべてのレコード集合に再利用可能な共通コンポーネントを作成します。

Now update ReliabilityPanel to use this:

ビルド成功。第1層 信頼性ガードを 無制限階層のエッジAI再帰偏り分析 に刷新しました（623KB）。

✅ 第1層 信頼性ガード ─ 多階層エッジAI偏り分析

新しい挙動

カードをクリックすると、フラットなリスト表示ではなく、何階層でも掘り下げられる偏り分析ビューが開きます。

┌── 階層0: 全件 (200件) ─────────────────────────────────────────┐
│ パンくず: [🏠 全件 (200)]                                      │
│                                                              │
│ 🤖 エッジAI 偏り検出                                          │
│  • 【サブシステム】「受注管理」が 47% で偏りあり                │
│  • 【発見工程】「単体テスト」が 35% で集中                     │
│                                                              │
│ ┌── 📦サブシステム分布 ──┐ ┌── ⚙️機能分布 ──┐                │
│ │ ⚠ 受注管理 ████ 94    │ │ ⚠ 受注登録 ██ 23 │                │
│ │   顧客管理 ██   42    │ │   信用調査 ██ 18 │                │
│ │   ...                  │ │   ...           │                │
│ └──────────────────────┘ └────────────────┘                │
│ ┌── 🔎発見工程分布 ───┐ ┌── 🐛混入工程分布 ─┐                │
│ │ ⚠ 単体テスト ███ 70 │ │ ⚠ 詳細設計 ███ 65 │                │
│ │   結合テスト ██  38 │ │   基本設計 ██  34 │                │
│ └──────────────────┘ └─────────────────┘                │
│ ┌── 🔥重大度分布 ────┐ ┌── 🏷原因分類 ─────┐                │
│ │   Medium  █████ 90  │ │   設計漏れ  ███ 52 │                │
│ │   High    ███   45  │ │   ...             │                │
│ └──────────────────┘ └─────────────────┘                │
│ ┌── 📊状態分布 ──────┐ ┌── 👤担当者分布 ────┐               │
│ │   Open  ████  60   │ │   ...             │                │
│ └──────────────────┘ └─────────────────┘                │
│                                                              │
│              [📋 この200件を一覧表示する]                      │
└────────────────────────────────────────────────────────────┘

「受注管理」をクリックすると…

┌── 階層1: サブシステム=受注管理 (94件) ────────────────────────┐
│ パンくず: [🏠 全件 (200)] › [サブシステム: 受注管理] ←active   │
│                                                              │
│ 🤖 エッジAI 偏り検出 (階層 2: 絞込済)                         │
│  • 【機能】「受注登録」が 23件 (24%) で偏りあり                 │
│  • 【発見工程】「単体テスト」が 38件 (40%) で強い集中           │
│                                                              │
│ （残った7軸の偏り分析を再表示。サブシステム軸は自動除外）         │
│ ┌── ⚙️機能 ─┐ ┌── 🔎発見工程 ─┐ ┌── 🐛混入工程 ─┐           │
│ │ ⚠ 受注登録 │ │ ⚠ 単体テスト  │ │ ⚠ 詳細設計    │           │
│ └──────────┘ └─────────────┘ └─────────────┘           │
│ ┌── 🔥重大度 ─┐ ┌── 🏷原因分類 ─┐ ┌── 📊状態 ───┐           │
│ ...                                                         │
└────────────────────────────────────────────────────────────┘

「受注登録」をクリックすると…

┌── 階層2: 受注管理 / 受注登録 (23件) ──────────────────────────┐
│ パンくず: [🏠 全件] › [受注管理] › [受注登録] ←active          │
│                                                              │
│ さらに残りの軸（発見工程・混入工程・重大度・原因分類・状態・担当）│
│ で再分析…                                                    │
│                                                              │
│ ※ 25件以下になったので「📝 末端レコード一覧」に自動切替表示    │
└────────────────────────────────────────────────────────────┘

主な機能

機能	説明
無制限階層	軸の数だけ何度でも掘り下げ可能（レビュー: 8軸 / バグ: 8軸）
動的再分析	フィルタ追加のたびに残った軸でAIが偏りを再計算
絞込済軸の自動除外	既に絞り込んだ軸は再分析の対象から外れる
パンくずナビゲーション	任意の階層に1クリックで戻れる
末端自動切替	残り20件以下になると自動でレコード一覧表示（手動切替も可能）
🏠 全件ボタン	一発で最初の階層に戻る
⚠ 集中マーク	期待値の1.5倍以上のカテゴリに自動付与

軸（dimensions）の定義

バグ管理ドリル（8軸）

📦サブシステム / ⚙️機能 / 🔎発見工程 / 🐛混入工程 / 🔥重大度 / 🏷原因分類 / 📊状態 / 👤担当者

レビュー記録ドリル（8軸）

📦サブシステム / ⚙️機能 / 📑工程 / 🔥重大度 / 🏷指摘種別 / 🧩原因分類 / 📊状態 / 👤レビュア

確認方法

cd C:\Content_Factory\P700_ProjectManegement\dashboard
npm run dev

PMビュー → 第1層 信頼性ガードのカードをクリック → 多階層偏り分析を体験してください。