CONFIDENTIAL — AI面接官システム企画書 v1（Claude×sol共同執筆・敏決裁反映版）

AI面接官システム企画書 v1

（Claude×sol 共同執筆 / 調査: Sonnet 3本+競合・技術2本 / 2026-07-17）

位置づけ: 敏決裁「まずAI模擬面接特訓サービス（toC）から。上手く回ってから採用実務（B2G）へ」に基づく実装企画書。roadmap v2の秋・小額課金PoCの本命商品。

0. 敏決裁事項（2026-07-17・本企画の背骨）

toC先行: AI模擬面接特訓サービスから始める。安全第一＋技術テスト。公務員受験生は十中八九面接が苦手——AIで模擬面接を練習し、分析的なフィードバックが返る体験からスタート。B2G採用実務ツールは「toCが上手く回ってから」。
MVP最低条件: ①アバター的AI面接官が喋る ②受験生の声と発言を認識して会話が成立する。
拡張要件: ③カメラ+音声分析によるノンバーバル評価（コーチングFB） ④面接官モード切替（平社員/部長級/局長級/市長）。

0.5 方式の統合判定（Claude・敏MVP要件×sol設計勧告の解消）

solは秋MVSに「録画式・アバター除外」を勧告した（リアルタイム音声のBeta依存・通信断・ターン検出リスクを秋のクリティカルパスから外すため——本文§4参照）。一方、敏のMVP最低条件は「アバターが喋り、会話が成立する」ことを要求する。統合判定は以下の通り。

採用方式＝「ターン制会話式」。面接はそもそも割り込みのないターン制の会話であり、full-duplexリアルタイムAPIなしで会話体験が成立する稀有なドメインである。

アバター面接官が質問を発話（TTS＋リップシンク。固定質問音声は事前生成キャッシュ、動的深掘りはオンデマンド合成）
受験生はマイクに向かって回答（チャンクアップロード→高速STT）
評価脳（LLM）が回答の不足情報を判定し、深掘り質問を生成→アバターが発話
ターン間の1〜3秒は面接の間（ま）として自然。full-duplexの割り込み処理・Beta基盤ロックインを回避

これによりsolの設計資産（状態機械・R2→Queues→Workflows評価パイプライン・監査設計）はそのまま全て有効。solの「録画式」勧告は「ターン制会話式」の基盤設計として吸収され、敏のMVP要件（アバター・音声会話）はターンのフロント体験として実装される。full-duplexリアルタイム（Cloudflare Realtime Agents/Gemini Live直結）は、solの条件（完了率・課金率・復帰率がターン制を上回る）を満たした場合のみ後日昇格するフィーチャーフラグ扱いとする。

MVP仕様（敏要件の技術写像）:

要件	実装	原価影響(30分)
①アバター発話	Simli級リアルタイムリップシンク($0.009/分)+TTS($0.015/分・固定質問は事前生成)	約$0.3
②音声会話成立	チャンクSTT(Deepgram $0.0043-0.0092/分)+評価脳LLM深掘り生成	約$0.2-0.3
③ノンバーバル評価	ブラウザ内MediaPipe(視線/姿勢/表情をクライアント側解析・動画非送信)+STTタイムスタンプから話速/間/フィラー語	≈$0
④面接官モード	プロンプト+声+アバター画像のプリセット(平社員/部長級/局長級/市長)。圧の段階練習+SNS拡散ネタ	≈$0

30分セッション原価 ≈ $0.5-0.7（約¥75-105）。セッション¥500-980の値付けで粗利80-85%。

ノンバーバルの防火壁（絶対規範）: カメラ・音声のノンバーバル分析はtoCの本人向けコーチングFB専用。B2G採用評価には未来永劫持ち込まない（HireVueが予測寄与0.25%で自主廃止し訴訟・規制コストだけが残った実証済みの地雷——本文§4.12・§5参照）。本人にはオプトアウトを提供する。

0.7 敏承認とPhase 0始動（2026-07-18）

敏が本企画書を承認。Phase 0 GO。

第一弾の定義: 「ミライ就活（ZENKIGEN）の公務員版」。ミライ就活をベンチマークとし、その体験水準（AIアバター面接官×学生向け無料UX）を公務員特化で実現する。
ベンチマーク解剖調査を実施中（UXフロー・アバター実装・FBレポート・ビジネスモデル・弱点）→ 結果はPhase 0のMVS仕様に反映。
公務員版の差分（=我々の勝ち筋）: 自治体別想定質問（772自治体DB）・面接カード連動・圧の段階（面接官モード）・AI面接ファースト原則によるハイタッチ接続。

1. エグゼクティブサマリー

Educareは、SHaiN/HireVueに範を取った対話型AI面接システムを自社開発する。ただし彼らのコピーではなく、「公務員採用」への特化と「同一エンジンの両面展開」で差別化する。

表（toC・秋投入）: 公務員受験生向けAI模擬面接サービス。自治体別想定質問・面接カード連動・即時評価レポート。roadmap v2の秋・小額課金PoCの本命商品。
裏（B2G・中期）: 自治体向けAI一次面接システム。昭島市のHireVue導入（2026年7月報道）が示す通り、自治体採用のAI面接化は今まさに開き始めた市場。既存の自治体B2G求人メディア構想と同一顧客への追加商材。
堀: toC練習データが質問設計と評価精度を鍛え、B2G実施データが練習の本番再現度を上げる二面データのフライホイール。これは片面だけのプレイヤー（練習アプリ勢・企業向けAI面接勢）には構造的に作れない。北極星「面接一次データ最大保有」の収集機械そのもの。

なぜ今か: ①技術コストの崖が下がった（録画式なら1面接$0.2-0.4、対話式でも$0.4-1.8=SHaiNの¥5,000/件に対し原価は数十円〜数百円） ②規制の要件が明文化され後発が最初から適合設計できる（EU AI Act 2026-08発効・HireVueの失敗which is公開情報） ③自治体側の需要が実例として観測された（昭島市）。

2. 市場と競合（調査T1の要約）

プレイヤー	方式	価格	規模
SHaiN（タレントアンドアセスメント）	対話型・スマホ完結・アバター無し	従量¥5,000/件（バイト¥1,000）	920社超・国内最大
HireVue（日本=タレンタ代理店）	録画型+ゲーム型	年契$35K-150K・国内¥350万〜	グローバル大手・昭島市導入
harutaka（ZENKIGEN）	録画+Live・非言語多変量解析	個別見積	700社・面接データ1,500万件
PeopleX	対話型・無料プランあり	unknown	2024創業・マッチングAI接続
DuDo	実在社員モデルのアバター型	unknown	2025設立

市場構造の読み: 企業向け汎用は SHaiN/HireVue/harutaka で飽和に向かう。空白は「公務員採用特化」×「受験生側とつながる二面性」×「小規模自治体の予算帯」。応募者受容は「6割がAI面接OK・ただし約半数がAI単独判定の不採用を拒否」= human-in-the-loop が商品要件。

2.5 toC競合地図（2026-07-17 深掘り調査・国内全数+海外）

結論: MVP4軸（アバター音声対話×公務員特化×ノンバーバルFB×圧の段階切替）を同時に満たす競合は国内外で0件（国内約15ツール全数+海外主要8ツールを確認）。アバター対話型は世界的にもまだ主流化前（Yoodli/Huru/Big Interview等は音声のみor録画分析）。

競合	アバター対話	公務員特化	カメラFB	圧切替	価格
AI公務員予備校（最重要・個人事業）	△音声のみ	○	×	?	月¥4,840(模擬4回)/単発¥1,480
ユーザーローカル就活面接AI	○	×	○	?	無料
ミライ就活(ZENKIGEN)	○	×	?	?	無料系
steach(ジェイック・6万DL)	×録画分析	×	○6指標	×	無料
HelloBoss(転職)	△音声	×	?	○穏やか/厳格	—
海外勢(Yoodli/Huru等)	×音声のみ	×	一部	×	$0-30/月

戦略含意: 1. 「無料アバター対話」（ユーザーローカル）と「無料ノンバーバルFB」（steach）が既在→単機能では戦えない。勝ち筋は公務員特化の深さ（自治体別想定質問×面接カード連動×自治体研究データ×圧の段階）の一点 2. 支払い実在の証明: AI公務員予備校（元県庁職員の個人事業）が月¥4,840で成立→公務員特化AI面接の課金許容は叩きv1想定（¥500-980/回）より上。価格叩きを単発¥1,000-1,500/月額¥3,000-5,000帯へ上方修正する余地 3. steachユーザーレビュー「詳細FBが欲しければ人間講師へ」＝AI→人の階段（AI面接ファースト原則）の需要は市場レビューからも実証済み 4. ユーザー不満の典型（=品質バーの設定材料）: FBが定型文/音声が途中で止まる/内容の質を評価しない（フィラー語検出止まり）→ 適応的深掘り×ルーブリック内容評価×根拠引用が品質差別化の芯 5. リスク: 予備校大手5社のAI面接参入は未確認だが時間の問題と見るべき（unknown）。先行の窓は今

出典: scratchpad research_C1_domestic_toc.md / research_C2_overseas_apps.md（全主張に出典URL付き）

3. プロダクト定義

3.1 共通エンジン「面接OS」（両面で共用するコア）

面接設計スタジオ: 職種・自治体・コンピテンシー別に質問セット/評価ルーブリック/深掘り方針を定義する構造化面接ビルダー（SHaiN戦略採用メソッド・HireVue Builder相当）。公務員特化テンプレート（社会人基礎力・自治体別の求める人材像・面接カード項目）を標準搭載
面接実行ランタイム: スマホブラウザ完結・アプリ不要・24時間受験。対話深掘り（不足情報のみ確認質問=次世代SHaiNの傾聴設計を踏襲）
評価パイプライン: 全発話テキスト化→ルーブリック採点（項目×1-5・根拠文付き）→複数評価者LLM→即時レポート。非言語特徴は採点に使わず人間レビュアー向け補助表示のみ（HireVue訴訟の教訓）
監査・説明基盤: 全セッション自動ログ・評価根拠の全文遡及・バイアス統計モニタリング（最初から組み込む=後発の武器）

3.2 toC: AI模擬面接（商品名候補: 面接特訓AI）

受験生が志望自治体を選ぶ→その自治体の面接形式・想定質問で模擬面接→評価レポート+改善点+「ここだけ人の特訓」（講師バンク例外キュー接続）。面接カード/ES添削履歴から質問を自動生成。課金=セッション従量 or 面接シーズンパス（叩きv1の文脈オファー設計に従う）。

3.3 B2G: AI一次面接（商品名候補: 公務員採用面接クラウド）

自治体が求める人材像を設定→候補者に招待URL→AI一次面接（録画式基本）→評価レポートを人事委員会/面接官に提供→最終判断は必ず人（昭島市モデル・補助指標としての利用を明文化）。求人掲載メディアとバンドル販売。

3.4 AI面接ファースト原則（敏決裁 2026-07-17 追加）

今後、人間が対面で指導する場合も、必ずAI面接官を通して基本的な分析データを持ってから行う。 AI面接はハイタッチ（講師バンク）への入口ゲートであり、全ての人的指導はAI分析レポートを起点に始まる。

講師の初回セッションが「ヒアリング」でなく「処方」から始まる（健康診断→診察の医療モデル）＝ハイタッチの時間単価価値を最大化
AI分析レポートに「AIでは直せない領域」が可視化される→人の指導の必要性がデータとして自明になる＝売り込み不要の自然なアップセル装置
全講師が同一の分析フォーマットから指導を開始＝講師バンクの品質標準化・弱点タイプ×講師得意分野のデータマッチング
完全AI駆動ドクトリン「AIが下ごしらえ・人はここぞ」の商品レベルでの実装

【Claude統合注記】以下§4はsol主筆。方式判定は§0.5の統合判定（ターン制会話式）で読み替える。solの録画式基盤設計（状態機械・Queues/Workflows評価パイプライン・監査設計）は全て有効。

4. 技術アーキテクチャ

4.1 結論：共通エンジン、用途別インタビュー方式を採用する

最終アーキテクチャは、toCとB2Gで面接方式を分ける。

用途	採用方式	判断
toC模擬面接・秋MVS	ターン制・適応型録画	採用。録画回答を文字起こしし、回答内容に応じて制約付き深掘り質問を返す
toC本番・上位プラン	リアルタイム音声対話	条件付き採用。継続率・満足度・課金率の改善が原価増を上回る場合のみ提供
B2G自治体一次面接	構造化録画＋制約付き深掘り	採用。候補者間の質問条件を揃え、監査可能性を優先
B2G二次面接支援	人間面接官＋AI補助	将来拡張。AI単独の自動判定にはしない
顔・声紋・感情分析	不採用	公平性・説明責任・規制リスクに対して予測価値が小さい

T2の「一次＝録画式、二次／模擬＝対話式」という方向性には同意する。ただし、秋のtoC模擬面接からフルリアルタイム音声を採用することには反対する。理由は以下の4点である。

模擬面接の主要価値は「低遅延で話し続けられること」ではなく、「自治体別質問」「回答に対する深掘り」「根拠付き評価」「反復練習」にある。
ターン制でも、回答ごとにSTTとLLMを動かせば適応的な深掘りを実現できる。
フルリアルタイムは通信断、割り込み、ターン検出、音声プロバイダー依存を同時に抱える。秋MVSのクリティカルパスに置くべきではない。
Cloudflareの音声エージェント基盤は有力だが、2026年7月時点でBetaである。音声はWebSocketで送受信でき、Durable Objects上で会話を保持できる一方、B2Gの本番基盤をBeta機能へ固定する段階ではない。Cloudflare Voice

したがって、共通化するのは音声通信方式ではなく、以下の中核である。

構造化面接テンプレート
面接セッション状態機械
質問・回答・深掘り条件の記録
評価ルーブリック
根拠引用付き評価パイプライン
人間レビュー
監査ログ
キャリブレーションデータ
レポート生成

リアルタイム音声は、この共通エンジンへ差し替え可能な「面接実行アダプター」として扱う。

4.2 toC方式：ターン制・適応型録画

秋MVSでは、次の体験を採用する。

受験生が自治体・職種・面接種別を選択する。
質問文と音声が提示される。
受験生がブラウザ上で音声または動画回答を録画する。
回答をR2へ直接アップロードする。
バッチSTTで文字起こしする。
LLMが「必要な行動事実が揃ったか」を判定する。
不足している場合だけ、最大回数を定めた深掘り質問を提示する。
終了後に評価レポートと改善練習を返す。

これを「録画型」と呼ぶが、固定質問を順番に再生するだけのHireVue型ではない。回答内容に応じて次の質問を変えるため、利用者体験は対話型に近い。

秋MVSでは、質問表示から回答開始までをリアルタイム音声APIへ依存させない。質問音声はテンプレート公開時に生成しR2へキャッシュする。動的深掘りは、まずテキスト表示とし、音声合成は非同期で追加できる構造にする。

toC本番では、ターン制を標準プランとして維持したうえで、リアルタイム音声をフィーチャーフラグ配下で比較する。以下の全条件を満たす場合のみ標準化する。

面接完了率または継続率がターン制より改善する
課金率または継続課金が原価増を吸収する
通信断からの復帰率が合格基準を満たす
同じルーブリックで評価品質が悪化しない
Beta基盤障害時にターン制へ自動退避できる

4.3 B2G方式：構造化録画＋制約付き深掘り

自治体一次面接は、自由対話ではなく「比較可能性を保った構造化面接」とする。

全候補者に同一の中核質問を提示する。
深掘りは「行動主体」「状況」「具体的行動」「結果」「本人の振り返り」など、事前定義した証拠スロットが欠けた場合だけ発火する。
同じ欠損条件には同じ質問候補群と同じ深掘り回数上限を適用する。
LLMに候補者ごとの自由な質問戦略を作らせない。
自治体ごとに承認済みのテンプレートバージョンを固定し、面接開始後の変更を禁止する。
AI評価は選考補助資料とし、不合格を自動確定しない。
低信頼、評価者間不一致、録音不良、配慮申告がある場合は人間レビューへ送る。

この方式は、フル対話式より候補者体験の自然さでは劣る。一方、候補者間の比較、公平性説明、再評価、情報公開請求への対応では優位である。B2G一次面接では後者を優先する。

4.4 システム構成図

┌─────────────────────────────────────────────────────────────┐
│ 利用者                                                       │
│  toC受験生 / B2G候補者 / 自治体採用担当 / 人間レビュアー      │
└───────────────────────┬─────────────────────────────────────┘
                        │ HTTPS / WebSocket
┌───────────────────────▼─────────────────────────────────────┐
│ Cloudflare Pages                                            │
│  Candidate App / toC My Page / B2G Admin / Review Console   │
│  - MediaRecorder                                            │
│  - 端末・マイク事前診断                                      │
│  - 分割アップロード・再送・途中復帰                           │
└───────────────────────┬─────────────────────────────────────┘
                        │ JWT / capability token
┌───────────────────────▼─────────────────────────────────────┐
│ API Workers                                                  │
│  Auth / Tenant RBAC / Template API / Session API             │
│  Consent / Upload authorization / Report API / Export API    │
│  - リクエスト検証                                            │
│  - tenant_id強制                                             │
│  - 署名付き短時間アップロード権限の発行                       │
└───────┬────────────────┬─────────────────┬──────────────────┘
        │                │                 │
        │                │                 └──────────────┐
        ▼                ▼                                ▼
┌──────────────┐  ┌──────────────────┐       ┌─────────────────────────┐
│ D1           │  │ Session Durable  │       │ Private R2              │
│ Control DB   │  │ Object           │       │ raw-media/              │
│              │  │                  │       │ transcripts/            │
│ tenants      │  │ 1 session = 1 DO │       │ evaluations/            │
│ templates    │  │ state machine    │       │ reports/                │
│ sessions     │  │ turn ordering    │       │ audit-manifests/        │
│ evaluations  │  │ double-submit防止│       │ disclosure-exports/     │
│ audit index  │  │ reconnect/progress│      └───────────┬─────────────┘
└──────┬───────┘  └────────┬─────────┘                   │ object-create
       │                   │                             ▼
       │                   │                    ┌───────────────────────┐
       │                   │                    │ Cloudflare Queues     │
       │                   │                    │ upload event / fanout │
       │                   │                    │ retry / DLQ            │
       │                   │                    └──────────┬────────────┘
       │                   │                               │
       │                   └───────────────────────────────▼
       │                                        ┌───────────────────────┐
       │                                        │ Evaluation Workflow   │
       │                                        │ 1. media validation   │
       │                                        │ 2. STT                │
       │                                        │ 3. transcript verify  │
       │                                        │ 4. evidence extract   │
       │                                        │ 5. dual scoring       │
       │                                        │ 6. critic             │
       │                                        │ 7. aggregate/report   │
       │                                        │ 8. human review route │
       │                                        └──────┬─────────┬──────┘
       │                                               │         │
       │                                      redacted │         │ signed result
       │                                               ▼         ▼
       │                                    ┌──────────────┐  ┌─────────────┐
       │                                    │ AI Gateway   │  │ Audit Worker│
       │                                    │ no cache     │  │ hash chain  │
       │                                    │ raw log off  │  │ daily digest│
       │                                    └──────┬───────┘  └─────────────┘
       │                                           │
       │                 ┌─────────────────────────┼─────────────────────┐
       │                 ▼                         ▼                     ▼
       │          STT Provider               LLM Providers          TTS Provider
       │          Deepgram等                 Claude等                template時のみ
       │          音声境界                   テキスト境界            動的音声は任意
       │
       └───────────────────────────────────────────────────────────────

R2のオブジェクト作成をQueuesへ通知できるため、アップロード完了を起点に非同期処理を開始する。R2 Event Notifications 評価処理はCloudflare Workflowsに置き、STT、複数LLM評価、レポート生成を独立した再試行可能ステップとして実行する。Workflowsは長時間の多段処理、再試行、人間承認待ちを永続化できる。Cloudflare Workflows

Durable Objectsは「面接の永続正本」ではなく、実行中セッションの直列化に限定する。永続正本はD1とR2へ保存する。リアルタイム音声を追加する場合は、セッション単位のWebSocketをDOへ収容する。DOのWebSocket Hibernationを利用すれば、切断せずにアイドル時の実行コストを抑えられる。Durable Objects WebSockets

4.5 Cloudflare上の配置原則

コンポーネント	配置	責務
Candidate App	Pages	録画、端末診断、質問表示、再送、途中復帰
toC My Page	Pages	練習履歴、改善レポート、再練習
B2G Admin	Pages	テンプレート管理、招待、進捗、評価閲覧
Review Console	Pages	原回答、文字起こし、根拠、AI評価、人間評価の比較
API Worker	Workers	認証、認可、テナント境界、入力検証
SessionDO	Durable Objects	ターン順序、回答期限、重複送信防止、WebSocket
Control DB	D1	構造化メタデータ、状態、バージョン、評価索引
Evidence Store	R2	音声・動画、文字起こし、モデル出力、レポート
Job Buffer	Queues	アップロードイベント、バースト吸収、DLQ
Evaluation Orchestrator	Workflows	STTから評価・人間レビュー待ちまでの多段処理
Provider Router	AI Gateway＋独自Adapter	モデル切替、タイムアウト、コスト計測、フォールバック
Audit Worker	独立Worker	追記専用監査イベント、ハッシュ鎖、日次署名
Analytics	集計専用D1／Analytics Engine	個人回答を含まないKPI・原価・障害計測

B2G本番では、一般toC環境と自治体環境を少なくとも論理分離する。案件の調達条件に応じて、自治体専用D1、専用R2バケット、専用暗号鍵、専用Worker環境へ昇格できる構造にする。

4.6 外部APIとの境界

外部APIへ送信する情報を最小化する。

API	送信可能	送信禁止・抑制
STT	セッション用匿名ID、音声、言語設定	氏名、メール、応募者番号、自治体内部管理ID
評価LLM	匿名化済み文字起こし、質問、ルーブリック	生動画、顔画像、認証情報、不要な候補者属性
TTS	質問テキスト	候補者情報、評価結果
AI Gateway	pseudonymous session ID、model/run metadata	raw promptログの長期保存、キャッシュ、候補者氏名

候補者が回答中に自ら氏名等を発話する可能性があるため、文字列だけで完全匿名化できるとは考えない。契約するSTT・LLM事業者には、学習不使用、保存期間、削除、再委託先、障害通知を契約条件として要求する。

AI Gatewayでは候補者回答のキャッシュを禁止し、raw prompt/responseログを保存しない。アプリ側にはモデル名、モデルバージョン、プロンプトバージョン、処理時刻、入力ハッシュ、出力ハッシュ、レイテンシ、原価だけを残す。

4.7 データモデル

エンティティ	主な属性	リレーション・制約
`Tenant`	tenant_id、種別、保持方針、地域、契約状態	自治体またはtoC運営主体
`Identity`	identity_id、認証主体、tenant_id	PIIは面接データと分離
`Application`	application_id、tenant_id、candidate_ref、職種	1件に複数セッションを持てる
`InterviewTemplate`	template_id、tenant_id、名称、用途	論理テンプレート
`TemplateVersion`	version_id、質問構成、公開状態、承認者、hash	面接開始時に固定。上書き禁止
`QuestionNode`	question_id、本文、時間制限、回答形式	TemplateVersionに所属
`FollowupRule`	rule_id、欠損証拠、質問候補、回数上限	B2Gでは事前承認必須
`RubricVersion`	rubric_version_id、職種、目的、hash	TemplateVersionから参照
`RubricDimension`	dimension_id、定義、重み、禁止証拠	1次元1判定
`BehaviorAnchor`	dimension_id、score、正負アンカー	1・3・5を最低限定義
`InterviewSession`	session_id、template_version_id、mode、status	開始時に全設定をsnapshot
`SessionTurn`	turn_id、question_id、順序、開始・終了時刻	1回答に複数MediaAsset
`MediaAsset`	r2_key、hash、mime、duration、status	D1には実体を置かない
`TranscriptSegment`	segment_id、turn_id、start/end、text、confidence	原文訂正履歴を保持
`EvaluationRun`	run_id、rubric_version、model、prompt、status	再評価は新規runとして追加
`DimensionScore`	run_id、dimension_id、score、confidence	1〜5、欠測を許容
`EvidenceCitation`	score_id、segment_id、quote、timestamp	全スコアに最低1件要求
`HumanReview`	reviewer_role、score、reason、override	AI結果を上書きせず併記
`CalibrationCase`	case_id、gold_label、adjudication	本番データから明示承認で採用
`ConsentRecord`	purpose、version、accepted_at、withdrawal	利用目的ごとに分離
`RetentionPolicy`	asset_type、retain_until、legal_hold	自治体契約ごとに設定
`AuditEvent`	event_id、actor、action、target、prev_hash、hash	追記専用、削除・更新禁止

重要原則は「現在値だけを残さない」ことである。質問、ルーブリック、プロンプト、モデル、文字起こし訂正、AI評価、人間評価はすべてバージョン付きで残す。後日の再評価でも当時の判断過程を再構成できなければ、B2Gの監査ログとして不十分である。

4.8 評価パイプライン

評価は単一LLMへ「この候補者を採点せよ」と依頼して終わらせない。

文字起こし
  ↓
品質検査
  ├─ 音声不良・欠損 → 再回答または人間レビュー
  ↓
証拠抽出LLM
  ├─ 行動事実
  ├─ 本人の役割
  ├─ 結果
  ├─ 反省・学習
  └─ 根拠segment/timestamp
  ↓
Dimension Scorer A ─┐
                     ├→ 不一致判定 → Critic → 決定規則
Dimension Scorer B ─┘
  ↓
ルールベース集約
  ├─ low confidence → 人間レビュー
  ├─ evaluator disagreement → 人間レビュー
  ├─ evidence不足 → 「評価不能」
  └─ 通常 → AI補助レポート

4.9 ルーブリック構造

各評価次元は以下を必須フィールドとする。

次元名
公務員職務との関連性
観察可能な行動定義
1・3・5の行動アンカー
評価に使える証拠
評価に使ってはいけない証拠
証拠不足時の扱い
反証となる行動
スコアの重み
最低信頼度
人間レビュー条件
想定される障害・文化・言語上のバイアス
作成者、承認者、適用開始日
バージョンと変更理由

スコアはT2の推奨どおり1〜5とする。1〜10の見かけ上の精密さは採用しない。評価根拠が不足する場合は中間点へ寄せず、「評価不能」を返す。

4.10 複数評価者LLM

複数評価者は、同じ回答を単純に2回採点する構造にしない。

Extractor：根拠となる発話だけを抽出し、採点しない。
Scorer A：ルーブリックに対する適合度を独立採点する。
Scorer B：Aの出力を見ずに独立採点する。
Critic：スコアが引用根拠から導けるか、禁止属性を使っていないかを検査する。
Aggregator：LLMではなく決定規則で集約する。
Human Reviewer：不一致、低信頼、配慮申告、異議申立てを処理する。

toCでは原価を抑えるため、全件を高価な異種モデルで二重評価しない。標準評価＋軽量Criticを基本とし、一定割合をシャドー評価へ送る。B2Gでは異なるモデルまたは異なるプロンプト設計による独立評価を原則とし、相関した誤りを監視する。

4.11 キャリブレーション運用

T2が示す50〜200件の人手ラベルを、正式な評価提供前の最低レンジとする。ただし、件数だけでは足りない。職種、自治体規模、年齢層、性別、方言、障害・配慮条件を可能な範囲で層化する。

2名の訓練済み人間評価者が独立採点する。
不一致は第三者が裁定し、ゴールドラベルを確定する。
AIと人間、人間同士の一致度を次元別に測る。
属性別に誤差、評価不能率、人間レビュー移送率を比較する。
モデル、プロンプト、ルーブリック変更時は過去セットを再生する。
四半期ごと、またはドリフト検知時に再校正する。
新バージョンはシャドー評価を経てから本番へ昇格する。

暫定リリースゲートとして、重み付きκ、平均絶対誤差、1点以内一致率、根拠引用正確率、属性別エラー差を採用する。具体的な合格値は評価専門家を含むPhase 0で確定し、企画上の都合で後から緩和しない。

4.12 非言語特徴の扱い

B2G評価には以下を使用しない。

顔表情
視線
推定感情
声紋
声質
アクセント
話速
沈黙時間
身振り
背景・服装
外見から推定した属性

システムが取得する非言語情報は、通信品質、録音欠損、無音、マイク切断などの運用診断に限定する。人間レビュアーにも「ストレス耐性」「自信」等の推定値を表示しない。

toCでは、本人だけが見る練習支援として話速、回答時間、フィラー頻度を任意表示できる。ただし、これは採用評価と明確に分離し、B2Gモデルの学習ラベルへ流用しない。障害や言語差への配慮として、機能をオプトアウトできるようにする。

4.13 監査・改ざん防止

監査ログはアプリケーション管理者でも通常操作から更新・削除できない書込経路に分離する。

Audit Workerだけが監査イベントを書き込む。
イベントごとに直前イベントのハッシュを含める。
音声、文字起こし、ルーブリック、モデル出力のSHA-256を記録する。
日次で監査イベントのルートハッシュを生成し、別バケットへ保存する。
B2Gでは自治体側へ定期的に署名済みダイジェストを渡す。
情報公開請求・訴訟・異議申立て時はlegal_holdで削除を停止する。
通常の保持期限終了時は、承認済み削除ジョブと削除証跡を残す。

4.14 1面接あたり原価目標

以下はresearch_T2_techstack.mdの単価を用いた推定であり、人件費、決済手数料、サポート費、税、為替差を含まない。

方式	T2推定・30分	本企画の目標
録画式	$0.13〜0.42	toC標準：$0.50以下
B2G録画＋複数評価	単純な録画式より増加	$0.80以下を初期目標
低価格リアルタイム	$0.40〜1.80	$2.00以下
gpt-realtime非mini中心	$5.40〜13.80	標準経路から除外

B2Gの$0.80は市場実績ではなく内部の設計目標である。複数評価、監査、再試行を含めてPhase 0で実測する。

録画式の主な内訳は次のとおりである。

DeepgramバッチSTT：$0.0043/分 × 30分＝ $0.129
評価LLM：文字起こし量、評価次元数、再試行回数に比例
R2：T2推定では30分動画を月100件保存して月$1未満
Workers／Queues／Workflows：AI APIより小さいが、処理回数と保持期間を計測する
TTS：固定質問はテンプレート公開時に一度だけ生成し、面接ごとの課金を避ける

4.15 スケール時のコスト曲線

T2の1面接単価を単純乗算した外部AI変動費は以下となる。

月間面接数	録画式 $0.13〜0.42	低価格リアルタイム $0.40〜1.80	非miniリアルタイム $5.40〜13.80
100件	$13〜42	$40〜180	$540〜1,380
1,000件	$130〜420	$400〜1,800	$5,400〜13,800
10,000件	$1,300〜4,200	$4,000〜18,000	$54,000〜138,000

録画式も外部API原価は基本的に線形であり、利用量の増加だけで劇的には安くならない。スケール時の原価改善は次の4点から作る。

固定質問音声の事前生成
文字起こしを次元ごとにLLMへ再送せず、証拠抽出結果を再利用
全件二重評価ではなく、信頼度とリスクに基づく評価ルーティング
テンプレート単位のプロンプト固定、出力上限、再試行上限

一方、B2Gでは数十セントの原価削減よりも、再評価可能性、異議申立て対応、障害時の復旧を優先する。SHaiNの標準価格が1件5,000円であることを踏まえると、推論費の最小化だけを目的に監査品質を落とす合理性はない。

5. 公平性・コンプライアンス設計（B2Gの生命線）

設計原則（先行者の失敗から逆算）: 1. 顔・声の生体分析はやらない（HireVueが予測寄与0.25%で自主廃止・規制コスト突出領域） 2. 言語内容ベースの評価のみ。話速・間は採点に不使用（非ネイティブ・吃音・障害者への系統的不利リスク） 3. human-in-the-loop必須: AI単独の合否判定を仕様として不可能にする（UIレベルで「推奨」までしか出さない） 4. 説明可能性ファースト: 全スコアに根拠文・候補者本人への開示手順・Explainability Statement を最初から公開（HireVueはCDTに「何も説明していない」と批判された——ここが後発の差別化） 5. 職業安定法遵守（適性・能力と無関係な情報の収集をシステム的に遮断）・個情法プロファイリング対応・録音同意フロー・EU AI Act水準の監査ログ（自動記録・6ヶ月+保持）を国内でも自主適用 6. リクナビ事件を反面教師とするデータ利用境界: toCの練習データをB2G評価に「個人単位で」流用しない。フライホイールは統計・質問設計レベルに限定し、プライバシーポリシーに明記

【Claude統合注記】本ロードマップはsol執筆。敏決裁（toC先行・MVP=アバター+音声会話）を受けた読み替え: (1) 秋MVSのスコープに§0.5「ターン制会話式」のフロント（アバター発話・音声回答・面接官モード・MediaPipeノンバーバルFB）を含める（solの除外リストのうち「フルリアルタイム音声」除外は維持・「アバター」除外は敏決裁により解除） (2) Phase 3以降（B2G）は「toCが上手く回ってから」の条件付き構想であり、Phase 2完了時に敏が昇格判定を行う。昇格条件=対話品質・評価妥当性（人間校正と一致）・原価実測・自治体別データ蓄積の4点。

6. 開発ロードマップ

6.1 結論：秋までに作るのは「面接プラットフォーム」ではなく、評価妥当性を検証できる一気通貫MVSである

秋のtoC投入に必要な最小スコープは以下である。

スマホブラウザ対応
1職種・少数テンプレート
5問程度の中核質問
セッション全体で最大2回程度の制約付き深掘り
音声回答を標準、動画は任意
回答の分割アップロード、再送、途中復帰
バッチSTT
1〜5評価、発話引用、改善案
評価不能と人間確認フラグ
同意、削除、保持期限
原価、完了率、STT失敗、評価不一致の計測
既存会員基盤への接続

秋MVSから除外する。

フルリアルタイム音声
アバター
顔・声の生体分析
自治体向けマルチテナント管理
ATS連携
自動合否
独自モデル学習
多数の職種・自治体テンプレート
高度な不正検知
ライブ面接
ネイティブアプリ

概算工数の「AI開発日」は、1つのAI実装レーンが実装・テスト・文書化を行う延べ1日を指す。Claude、Codex、solの並列稼働により暦日は短縮できるが、Claudeの統合レビューと人間の決裁期間は短縮できない。法務、自治体営業、調達待ちは工数外とする。

6.2 Phase 0：技術PoC・評価成立性検証

項目	内容
時期目安	2026年7月後半〜8月前半
概算工数	15〜25 AI開発日
スコープ	1テンプレート、録音、R2アップロード、STT、証拠抽出、1評価者＋Critic、簡易レポート、監査ID
完了条件	スマホ主要環境で面接完了、失敗再送、全評価に根拠発話、原価計測、同じ入力の再評価比較が可能
検証仮説	ターン制録画でも「深掘りされた感」が成立する／30分$0.50以下で処理できる／評価根拠を人間が検証できる
撤退条件	録音欠損が反復修正後も解消しない／根拠引用の誤りが多く評価レポートとして成立しない／職務関連ルーブリックを定義できない

Phase 0の最重要成果物はUIではなく、同じ回答に対する人間評価とAI評価を比較できるオフライン評価ハーネスである。

6.3 Phase 1：toCクローズドベータ

項目	内容
時期目安	2026年8月〜9月前半
概算工数	25〜40 AI開発日
スコープ	既存会員接続、複数テンプレート、適応型深掘り、履歴、改善練習、削除UI、管理画面、障害監視
完了条件	50〜200件のキャリブレーション候補を確保／人間評価との比較完了／端末別完了率と失敗原因を把握／重大なPII漏えいゼロ
検証仮説	自治体特化が汎用面接AIより高く評価される／評価後に再練習が発生する／利用者が発話データ提供へ同意する
撤退条件	利用者が評価を信用せず再利用しない／自治体別テンプレートが価値差を生まない／同意取得後も学習・検証可能なデータが集まらない

ベータでは回答データを自動的に学習データへ転用しない。サービス提供、品質検証、研究・モデル改善の同意目的を分ける。

6.4 Phase 2：toC本番・秋リリース

項目	内容
時期目安	2026年9月後半〜10月
概算工数	35〜55 AI開発日
スコープ	課金、利用上限、自治体・職種別テンプレート、再練習、レポート比較、サポート導線、原価制御、バックアップ
完了条件	課金から面接完了まで一気通貫／運用手順・障害対応・削除手順が存在／モデル変更をシャドー検証できる
検証仮説	商品叩きv0の基準で有料転換2%が下限、5%で合格／面接データが次回練習の品質を上げる／AI添削・講師バンクへの送客が発生する
撤退条件	十分な流入に対して有料転換が基準線を継続的に下回る／面接原価とサポート原価を価格で回収できない／再練習率が低く単発ツール化する

リアルタイム音声はこのPhaseの標準スコープに含めない。ターン制との比較実験として限定開放する。

6.5 Phase 3：B2Gパイロット

項目	内容
時期目安	2026年11月以降。自治体の採用・調達日程に従う
概算工数	60〜90 AI開発日＋法務・調達対応
スコープ	専用テナント、構造化面接ビルダー、候補者招待、RBAC、複数評価者、Human-in-the-loop、監査輸出、保持・legal hold
完了条件	シャドー運用を完了／人間判断との一致・不一致を説明可能／属性別評価差を測定／自動不合格なし／情報公開請求用の記録を出力可能
検証仮説	採用担当者の一次面接工数を削減できる／AI補助指標として受容される／公務員特化ルーブリックが汎用品との差になる
撤退条件	AI単独合否を要求される／異議申立てと人間再審査を受け入れられない／調達要件に対応する費用が契約価値を超える／属性別誤差を軽減できない

最初の自治体では、AI評価を選考へ直接使わないシャドー期間を必須とする。AIスコアを見ない人間評価を先に確定し、その後に比較する。

6.6 Phase 4：B2G本番

項目	内容
時期目安	パイロットと第三者レビュー完了後
概算工数	90〜140 AI開発日＋継続運用
スコープ	複数自治体、専用環境選択、SSO/MFA、SLA、監査ダッシュボード、異議申立て、調達文書、BCP、モデル変更管理
完了条件	本番SLA、インシデント訓練、第三者バイアス監査、障害時の代替選考手順、自治体職員向け研修が完了
検証仮説	複数自治体へ再利用可能／導入支援を含めても粗利が成立／評価品質を維持して面接件数を増やせる
撤退条件	自治体ごとの個別開発が大きく再利用率が上がらない／監査・問い合わせ・人間レビュー工数が売上を超える／重大な公平性・情報管理事故が発生する

6.7 AI駆動開発体制

担当	主責務
Claude	要件統合、既存Educare資産との接続、受入基準、コードレビュー、敏への判断返却
Codex	Workers／Pages／D1／R2実装、テスト、ブラウザ録画、CI、障害注入、運用ツール
sol	アーキテクチャ、評価パイプライン、脅威分析、原価モデル、敵対レビュー
敏	方式・価格・自治体提案・公平性方針・Phase昇格の最終決裁
外部専門家	労務・個情法・公的採用・心理測定・アクセシビリティの限定レビュー

完全AI駆動は「人間が不要」という意味ではない。実装主体をAIに置き、人間は採用基準、法務判断、ルーブリック妥当性、Phase昇格を担う。

6.8 クリティカルパス

職務分析・ルーブリック
        ↓
評価ハーネス ───────→ 50〜200件キャリブレーション
        ↓                         ↓
録音・再送・STT ─────→ 根拠抽出・複数評価
        ↓                         ↓
toCベータ ─────────→ 評価妥当性ゲート
        ↓                         ↓
toC本番                   B2Gシャドーパイロット
                                  ↓
                         公平性・調達・監査ゲート
                                  ↓
                              B2G本番

UI、課金、アバターより先に、職務分析と評価ハーネスを完成させる。録画機能が動いても、評価が妥当でなければB2G資産にはならない。

6.9 最大の技術リスクと先行検証

優先	リスク	先行検証
1	評価スコアが人間の職務評価と一致しない	実装前に匿名回答セットを作り、人間2名＋裁定者とLLMを比較
2	LLMが引用に存在しない根拠を作る	segment ID必須化、引用原文一致を機械検証、誤引用時は評価失敗
3	スマホ通信断で回答を失う	短いチャンク、ローカル一時保持、再送、途中復帰、低速回線試験
4	toCとB2Gのデータ分布が異なる	自治体職種別に性能を分け、toC件数をB2G精度の代理指標にしない
5	音声基盤Betaへのロックイン	`InterviewTransport`を抽象化し、録画、CF Voice、他社Liveを交換可能にする
6	キュー再試行で二重課金・二重評価	run_idによる冪等性、各外部API実行前後の状態記録、DLQ
7	B2G監査記録が後付けできない	Phase 0からテンプレート、モデル、プロンプト、入力・出力ハッシュを保存

7. 開発体制（AI三翼+五段タイアリング）

敏: プロダクトオーナー（仕様決裁・自治体営業・公平性ポリシー決裁）
Claude(Fable/Opus): 全体設計・統合・品質ゲート・コンプライアンス設計
sol: アーキテクチャ設計・最難実装・敵対レビュー
Codex(Terra): 実装主力（Worker/フロント/パイプライン）
Sonnet部下: 質問バンク整備・テストデータ・機械的検証
Gemini: 競合監視・自治体調達情報の偵察（Deep Research含む）
キヨ: 講師バンク側の教師データ・面接評価の人間校正（要相談）

8. 基盤構築に必要なツール・契約リスト

区分	項目	状態	概算費用
既存流用	Cloudflare Workers/D1/R2/Pages/Access	✅ 稼働中	既存契約内
既存流用	Claude/OpenAI/Gemini API	✅ 契約済	従量
新規（Phase0）	Deepgram（STT日本語・バッチ$0.0043/分）	要契約	従量・月数千円規模
新規（Phase0）	Cloudflare Realtime Agents（オープンベータ）	要有効化	ベータ中無料
検証（Phase0）	LiveKit Cloud（Realtime Agentsのヘッジ）	要トライアル	Build無料枠→Ship$50/月
新規（Phase1）	TTS（OpenAI gpt-4o-mini-tts ~$0.015/分）	契約済APIで可	従量
任意（保留）	アバター（Simli $0.009/分等）	不採用推奨	—
新規（Phase2）	Stripe（課金・叩きv1と共通）	骸あり・正規配線	手数料3.6%
新規（Phase3）	バイアス監査ツール（Fairlearn等・要裏どり）	未定	OSS想定
検討	録画配信をStream化（HLS必要時）	R2で開始	$5/1,000分

9. 事業計画（初期の値付け叩き）

toC: 模擬面接3回無料→セッション¥500-980 or シーズンパス¥4,980（叩きv1のPoC実験で実測）
B2G: SHaiN従量¥5,000/件とHireVue年契¥350万の間の「小規模自治体が決裁できる帯」=年額¥30-80万+従量¥2,000-3,000/件（原価$0.2-1.8/件→粗利95%+）。求人掲載とバンドルで実質単価を下げ、先行3自治体は無料パイロット（実績と改善データを対価に）
収益の意味: toC=転換率実測とデータ収集 / B2G=track2サービス層のARPU柱（roadmap v2整合）

10. リスク登記簿

10.1 技術リスク

ID	リスク	確率	影響	Early warning	軽減策
T-01	スマホ録音・アップロード失敗	高	高	端末別中断率、再送率、0-byte媒体	分割録画、ローカル保持、再送、途中復帰、事前診断
T-02	日本語STTが方言・固有名詞を誤認	中	高	低confidence率、訂正率、地域別誤差	辞書、複数STT比較、原音参照、人間確認
T-03	LLM評価の再現性不足	高	高	同一回答のスコア変動、評価者不一致	低temperature、構造化出力、独立評価、バージョン固定
T-04	根拠のない評価理由を生成	中	高	原文不一致引用、Critic棄却率	segment ID引用、機械照合、根拠なしは評価不能
T-05	CF音声Beta障害・仕様変更	中	中	切断率、破壊的変更、障害時間	秋MVSの依存から除外、adapter化、録画への退避
T-06	外部AI事業者障害	中	高	timeout、429、DLQ増加	複数事業者、指数バックオフ、再開可能Workflow
T-07	再試行による二重評価・二重課金	中	中	同一runの複数請求、重複レポート	idempotency key、状態機械、外部呼出台帳
T-08	テナント境界の不備	低〜中	極高	異なるtenant_idへのアクセス試行	Workerで強制認可、B2G専用DB／bucket、侵入試験

10.2 市場リスク

ID	リスク	確率	影響	Early warning	軽減策
M-01	受験生が無料生成AIで十分と判断	高	高	有料転換2%未満、価格表示後離脱	自治体別質問、履歴、比較、一次データで差別化
M-02	評価への不信で再利用されない	中	高	レポート閲覧後の再練習率低下、異議率	根拠発話、評価不能表示、改善課題の具体化
M-03	模擬面接単体の利用期間が短い	高	中	試験直前のみ利用、解約集中	添削、試験ナビ、講師バンクと接続
M-04	自治体営業・調達周期が長い	高	高	提案から予算化まで進まない	toCで基盤維持、次年度予算前の提案、パイロット商品化
M-05	自治体がAI面接自体を拒否	中	高	「AI不合格」への反発、職員組合懸念	AI補助、人間最終判断、シャドー導入、異議申立て
M-06	toC利用データがB2G価値につながらない	中	高	練習回答と本番回答の特徴差	用途別検証、安易な混合学習禁止、職種別評価

10.3 規制・公共性リスク

ID	リスク	確率	影響	Early warning	軽減策
R-01	評価が職務関連性を説明できない	中	極高	「なぜこの次元か」に回答不能	職務分析、ルーブリック承認、モデルではなく基準を説明
R-02	特定属性への系統的不利益	中	極高	属性別誤差・評価不能率の差	顔・声分析禁止、層化検証、人間再審査、第三者監査
R-03	AIのみで不採用と誤解される	中	高	応募者問い合わせ、説明文の誤読	UI・募集要項に人間最終判断を明示、実装上も自動確定禁止
R-04	録音・プロファイリング同意が不十分	中	高	同意撤回、削除請求、苦情	目的別同意、保存期間明示、削除・異議申立て導線
R-05	情報公開請求に回答できない	中	極高	自治体法務から記録不足指摘	質問、回答、評価根拠、モデル版、監査ログの一括出力
R-06	情報公開と営業秘密が衝突	中	高	プロンプト・モデル詳細の開示要求	公開可能な説明資料を事前作成し、契約で記録区分を確定
R-07	議会・メディアから「AI差別」と批判	中	極高	議員照会、SNS批判、取材	影響評価公開、シャドー結果、第三者監査、危機広報手順
R-08	調達要件を満たせない	高	高	国内保管、認証、監査、SLA要求との不一致	RFP前チェックリスト、専用環境、必要認証は案件別確認
R-09	アクセシビリティ上の不利益	中	高	聴覚・発話障害者の完了率低下	代替受験、人間面接、字幕、時間延長、配慮を評価から分離
R-10	法令・ガイドライン変更	中	高	監督官庁指針、EU・自治体基準変更	規制台帳、半年ごとの設計レビュー、機能単位で停止可能にする

10.4 競合リスク

ID	リスク	確率	影響	Early warning	軽減策
C-01	PeopleX等が無料・低価格で普及	高	中	無料プラン比較による離脱	公務員特化、自治体DB、面接カードとの接続
C-02	SHaiNが自治体領域を先行獲得	中	高	自治体導入事例・代理店提携増加	小規模自治体向け簡易導入、価格・実装速度で差別化
C-03	HireVue／国内録画基盤が機能模倣	中	中	構造化面接・生成AI深掘りの標準化	8,799問・772自治体・職種別評価データへ接続
C-04	競合の保有データ量に追いつけない	高	高	評価性能・導入実績で劣後	件数競争ではなく、公務員職種別の密度と監査品質を取る
C-05	価格競争でB2G粗利が消える	中	中	入札価格低下、個別対応増加	標準仕様、導入支援別料金、個別開発を本体へ混ぜない

10.5 データリスク

ID	リスク	確率	影響	Early warning	軽減策
D-01	キャリブレーション件数・代表性不足	高	高	特定属性・職種のサンプル欠損	50〜200件を層化、未検証職種には評価を提供しない
D-02	toC練習データによる分布汚染	高	高	暗記回答・反復回答比率増加	初回と反復を区別、本番評価モデルへ自動混入させない
D-03	B2GデータをtoC改善へ不適切流用	中	極高	契約目的外利用、自治体からの指摘	契約・同意単位のデータ境界、明示許諾、匿名化審査
D-04	録音・文字起こし漏えい	低〜中	極高	異常ダウンロード、署名URL悪用	private R2、短命token、暗号化、アクセス監査
D-05	モデル変更による評価ドリフト	高	高	同じ回答のスコア変動	モデル固定、回帰セット、shadow、変更承認
D-06	監査ログ自体が改変される	低	極高	hash不一致、イベント欠番	独立Audit Worker、hash chain、別環境への日次digest
D-07	保持期限を超えて原データが残る	中	高	期限超過object、削除キュー滞留	retention job、legal hold分離、削除証跡

10.6 運用リスク

ID	リスク	確率	影響	Early warning	軽減策
O-01	本番受験中の障害	中	極高	error rate、upload latency、provider outage	予備日、再受験token、録画継続、障害時は人間面接へ切替
O-02	問い合わせ・異議申立てが集中	中	高	1面接あたり問合せ時間増加	根拠表示、FAQ、ケース分類、正式な再審査手順
O-03	人間レビュー件数が想定超過	中	高	review route率、滞留時間	次元別原因分析、ルーブリック改善、契約上の処理上限
O-04	自治体担当者がAI結果を過信	高	高	AIスコアだけで判断、根拠未閲覧	研修、総合ランキング非表示、根拠確認を操作上必須化
O-05	自治体ごとの個別仕様で保守不能	高	高	fork増加、独自帳票・質問ロジック増加	設定で吸収、標準外は別契約、core fork禁止
O-06	AI駆動開発による潜在欠陥	中	高	回帰、認可漏れ、生成コードの重複	Claudeレビュー、Codexテスト、sol敵対監査、独立セキュリティ試験
O-07	議会・メディア対応の初動失敗	中	極高	回答不統一、担当者の独断説明	一枚説明資料、責任者一本化、事実ログ、停止判断基準
O-08	退職・担当変更で運用知識を喪失	中	中	属人化、手動操作増加	Runbook、訓練、権限棚卸し、自動化された監査レポート

11. KPI・計測設計

toC: 模擬面接完了率・レポート閲覧率・セッション→従量課金転換・「人の特訓」希望率（ハイタッチ階段の実測）・自治体別データ蓄積件数
B2G: パイロット自治体数・面接完了率・面接官の評価一致率（AI vs 人）・候補者満足度（受験後アンケート）・議会/メディアからの照会件数（リスク指標）
品質: 評価者間一致（LLM間・LLM vs 人間校正）・属性群間のスコア分布差（バイアス統計）

12. sol敵対チェック（企画全体への警告）

【Claude統合注記】solが挙げた追加章（評価妥当性・異議申立て・B2G調達・データ統治・セキュリティBCP・AI停止権限）は、B2G昇格判定の前までに整備する「v2で拡充する章」として採用する。うち「評価妥当性・職務分析」と「AI停止権限」はtoC段階から必要なため、Phase 0-1の中で先行整備する。

最も死にやすい箇所Top 3

評価妥当性が成立しないこと

音声対話が自然でも、「公務員としての職務遂行能力」を回答から妥当に測れなければ、B2G商品にはならない。一次データの件数は、正しいラベル、職務分析、代表性がなければ堀ではなく負債になる。

toCデータがB2G精度へ直結するという過信

模擬面接では回答の作り直し、暗記、同一人物の反復が多い。本番一次面接とは分布が異なる。toCデータは質問改善には有効だが、そのまま採用評価モデルの教師データにはできない。

B2Gを技術導入問題として扱うこと

最大障壁は録画・STT・LLMではなく、公平性、異議申立て、議会説明、情報公開、調達、障害時の代替選考である。優れたPoCがそのまま自治体契約へ進むとは限らない。

企画書に追加すべき章・観点

評価妥当性・職務分析章：公平性とは別に、何を測り、採用後成果との関係をどう検証するかを定義する。
異議申立て・救済設計章：候補者への通知、説明、人間再審査、再受験、記録訂正を定義する。
B2G調達・公共説明章：予算化時期、調達要件、情報公開請求、議会答弁、障害時の代替選考をまとめる。
データ権利・データの堀統治章：toC／B2G間で何を共有でき、何を共有しないかを契約・同意・技術で定義する。
セキュリティ・BCP章：脅威モデル、テナント分離、鍵管理、漏えい対応、プロバイダー停止時の継続計画を置く。
AI停止権限章：モデルドリフト、公平性異常、議会・メディア問題発生時に、誰がどの範囲を即時停止できるかを決める。

製造工程: Sonnet調査(R1学習実態/R2負の調査/R3収益モデル/T1競合解剖/T2技術基盤・全て出典付き) → Claude統合 → sol(gpt-5.6-sol, effort=high)主筆(§4/§6/§10/§12) → Claude最終統合。企画書はtoC先行の敏決裁(2026-07-17)に基づく。

AI面接官システム 企画書 v1