本資料は仕様や計画を確定させるものではなく、認識合わせと次アクションの確定を目的とした中間報告資料です。8/7 お打ち合わせ内容の解釈に齟齬がございましたら、本日の場でご指摘ください。内容は 8/21 頃のご提案（見積・要件整理）に反映いたします。
25年度実施内容（STEP03 納品済み）の振り返りと、26年度実施内容の棚卸しを行い、以下の方向性を確認いたしました。
| 時期 | マイルストーン | 備考 |
|---|---|---|
| 8/13 頃 | 中間報告 | 本日。検討途中経過のご報告・追加ヒアリング（8/13–14 はお盆期間ですが当社は対応可能と確認済み） |
| 8/21 頃 | ご提案・お見積りのご説明 | 要件整理・スケジュール・見積・契約方針の整理版をご説明 |
| 9月〜 | 開発着手（見込み） | お見積り後の社内ご検討・発注手続きのリードタイムを考慮 |
| 9月末 | 上期末 | 貴社の上期は9月末まで。必達デッドラインではなく目安とご確認 |
| 年度末（3月） | 成果報告 | 最重要。機能開発の完了に加え、運用データの蓄積とその分析・インサイトのご提示が求められる |
年度末（2027年3月）の成果報告から逆算し、26年度に達成すべきことを3つのゴールとして整理しました。この整理が貴社のご認識と合っているかが、本日確認させていただきたい点の一つです。
指導再学習＋異常値収束機構により、本来異常でない音へのアラートが運用を重ねるほど減っていく状態をつくる。
想定外事象のエラーハンドリング、アラート・エスカレーション、稼働の証明（ヘルスレポート）、バックアップ・復旧手順を整備する。
運用データを蓄積し、再学習前後の誤検知の推移・収束カーブなど、効果を数字で示す分析レポートをまとめる。
成果報告で「運用データの分析」をお示しするには3ヶ月程度の運用期間（12月〜2月）が必要です。したがって、再学習・収束の仕組みは遅くとも11月末までに現地投入する必要があります。これが本計画全体のクリティカルパスであり、第3章の案A・案Bいずれでも最終リリース期限は11月末で共通です。
リリースの進め方について、案A（11月末 一括リリース）と案B（9月末・10月末・11月末の段階リリース）の2案をご用意しました。いずれも会議で挙がったマイルストーン（◆）を軸に週単位でタスクを配置しています。◇は会議での合意事項ではなく、当社が逆算で設定したものです。どちらの案で進めるかを含め、第7章のご確認事項の回答を反映して 8/21 に確定版をご提案します。
「検証を終えてから、まとめて作って一度に出す」進め方。検証結果を設計に反映してから実装するため、手戻りが少なく品質を確保しやすい標準的な構成です。
「動くものから順に、3回に分けて出す」進め方。課題の中心である異常値収束を最初に現地投入し、運用データの蓄積と現場からのフィードバックを前倒しします。
| 観点 | 案A（11月末 一括リリース） | 案B（段階リリース） |
|---|---|---|
| 主なリスク | 年度末までの猶予が少ない（11月末必達・後ろ倒し余地小） | 検証と実装の並行による手戻り・R1品質リスク。受入・デプロイ3回分のご負担増 |
| 契約の切り方 | Phase 1（検証）＋ Phase 2（請負一式） | リリース単位（R1／R2／R3）の分割契約 |
| 当社所感 | 確実性を重視した標準的な進め方 | 上期末に「動くもの」をお示しする必要がある場合に有効 |
WBS上のタスクを「開発以前（契約・要件定義）」と「開発以後（設計〜運用）」に分けて、成果物と完了の定義を整理します。
| タスク | 内容 | 成果物 | 完了の定義 |
|---|---|---|---|
| 要求整理・要件定義 | 2本柱(再学習・収束/堅牢性)の要求を現場運用レベルで定義。誤検知の具体事例、再学習の運用フロー、収束の合格基準を含む | 要件定義書ドラフト | 8/21 ご説明 → 8月末 合意 |
| 見積・契約構成の作成 | フェーズ分割の構成で、請負／検証フェーズの切り分けを含むお見積りを作成（→ 第6章） | お見積書・契約構成案 | 8/21 ご提示 |
| スケジュール確定 | 発注リードタイム・上期末報告の内容を反映して本WBSを確定 | 確定版WBS | 8月末 |
| 先行着手範囲の合意 | 正式発注前に着手する範囲（Phase 1 検証）と金額上限の合意。過去の進め方の実績あり | 先行着手の合意（書面） | 9月第1週 |
| 契約手続き | 購買部お手続き（会社情報登録・NDA）の完了、お見積りご提示 → 社内ご検討 → 発注 | 契約締結・発注 | 9月中（リードタイム要確認） |
| タスク | 内容 | 成果物 | 完了の定義 |
|---|---|---|---|
| 先行検証（Phase 1） | 既存の運用データを用いた収束ロジックのオフライン検証、指導再学習の技術検証（既存性能を維持できるか）、障害モードの洗い出し | 検証報告書（上期末報告を兼ねる） | 9月末 ご報告 |
| 設計 | 収束機構・指導再学習・堅牢性強化の基本設計・詳細設計。再学習の運用フロー（判断者・承認）を設計に含める | 基本設計書・詳細設計書 | 10月中旬 レビュー完了 |
| 開発 | WS1 異常値収束機構／WS2 指導再学習機能（操作UI含む）／WS3 堅牢性強化（監視・エラー処理・アラート・バックアップ） | ソースコード・機能一式 | 11月中旬 |
| テスト | 単体・結合テストに加え、再学習前後の回帰評価（既存の検知性能が劣化していないことの確認）をリリース条件とする | テスト仕様書・成績書・評価データセット | 11月下旬 全件合格 |
| デプロイ・受入 | 現地環境への投入、受入試験（STEP03-C と同様の受入手順書ベース） | 受入試験手順書・試験結果 | 11月末 第1リリース |
| 運用・チューニング | 現地運用でのデータ蓄積、再学習運用の実践と収束チューニング、現場向け技術仕様説明資料の整備 | 運用記録・技術仕様説明資料 | 12月〜2月（3ヶ月蓄積） |
| 分析・成果報告 | 運用データの分析・効果検証（誤検知の推移・収束カーブ）、年度末成果報告書の作成支援 | 分析レポート・成果報告書 | 3月 ご報告 |
計画を成立させるための成功条件です。多くは貴社と当社の合意・ご協力が前提となります。
貴社の請負ご希望を前提に、要件を確定できる部分と試行錯誤を含む部分を分けた構成案です。工数は現時点の粗い目安であり、正確な工数と費用は要件定義の完了をもって正式にお見積りいたします。
| フェーズ | 時期 | 契約形態（案） | おおよその工数（目安） | 備考 |
|---|---|---|---|---|
| Phase 0 要件定義・ご提案 | 8月 | ご提案活動として当社対応 | ─ | 8/21 にご提案・お見積りをご提示 |
| Phase 1 先行検証 | 9月 | 準委任、または成果物を「検証報告書」と定義した請負 | 約 1.0〜1.5 人月 | 試行錯誤を含むため成果を事前保証できない部分。先行着手の対象 |
| Phase 2 実装・第1リリース | 9〜11月 | 請負（成果物: 機能・設計書・テスト成績書） | 約 4.0〜5.5 人月 | Phase 1 の結果で要件を確定してから締結。WS1〜WS3 の内訳あり |
| Phase 3 運用・チューニング | 12〜2月 | 準委任、または月次サポート型請負 | 約 0.5 人月／月 × 3ヶ月 | 再学習運用の伴走・収束チューニング・技術資料整備 |
| Phase 4 分析・成果報告 | 2〜3月 | 請負（成果物: 分析レポート・成果報告書） | 約 1.0〜1.5 人月 | 年度末成果報告の作成支援を含む |
| （任意）自動学習パイプライン化 | 12月〜 判断後 | 請負（別途お見積り） | 未定 | 運用実績（手動運用の負荷）を見て実施判断。Prox社参照額: 500万円〜 |
お見積り・要件定義を確定させるために、貴社にご確認したい事項です。★は 8/21 のご提案までにご回答（または目安のご共有）をいただきたい優先項目です。本日その場でわかる範囲で構いません。
| 分類 | 優先 | 確認事項 | 確認の目的 |
|---|---|---|---|
| 見積・契約 | ★ | お見積りご提示 → 発注決定までの標準リードタイム | 開発着手時期の確定。WBSの「契約協議」期間は仮置きのため |
| ★ | 先行着手の可否と、確約いただける金額の上限感 | 9月の検証着手（Phase 1）を成立させるため | |
| 年度予算のレンジ感（フェーズ分割見積の総額に対する感触） | 優先度に応じたスコープ調整のため | ||
| 請負の成果物定義・検収条件の粒度（社内で求められる形式） | 契約構成案の作成のため | ||
| 要件定義 | ★ | 誤検知の具体事例（どんな音がいつ誤検知されるか）と頻度。可能であれば録音データのご提供 | 再学習・収束の検証設計（Phase 1）の前提データ |
| ★ | 収束の合格基準 ─ 誤検知をどこまで減らせれば「成功」か | 請負の成果物定義・受入条件に直結 | |
| 再学習の運用体制 ─ 誤検知の判断者、再学習実行の承認フロー | 機能仕様（UI・権限）と運用設計のため | ||
| 24時間365日の要求水準 ─ 許容停止時間、障害時の通知先・エスカレーション先、技術説明資料の読者・用途 | 堅牢性強化（WS3）の要件確定のため | ||
| スケジュール・環境 | ★ | リリース方式のご希望 ─ 案A（11月末 一括）／案B（9月末から段階リリース）のどちらで進めるか（→ 第3章 比較表） | 8/21 のご提案・お見積りをどちらの案で組むかを確定するため |
| ★ | 上期末（9月末）にエンドユーザー様へご提示する内容の合意状況・最低ライン | 9月末報告の内容（検証報告で足りるか、現地稼働まで必要か）の確定。案A／案Bの判断材料 | |
| 年度末成果報告の形式・評価者（四国電力様へのご報告フォーマット） | GOAL 3（分析レポート）のアウトプット設計のため | ||
| 運用データのご提供方法 ─ 録音データ・異常度ログの持ち出し可否、量、頻度 | Phase 1 検証と Phase 3 チューニングの前提 | ||
| 現地環境へのデプロイ手段 ─ リモートアクセス可否、現地訪問の要否 | 11月末リリースの段取りのため |