本開発（Phase-2）提案書：Excel 一元化・統合営業台帳

金額はすべて税抜の概算です。Cloudflare の料金は本書作成時点で把握している公開価格を元に、1ドル＝150円で換算しています。提出前に最新の料金表で再確認します。人日単価は後述の前提によります。

0. 要約

• 主案（A案）は初期 90万円＋変動枠上限10万円（最大100万円）、月額 約7万円です。 部長決裁の範囲（初期100万円以内）と月額10万円以内に収めています。
• Phase-1 で作った Workers＋D1 の台帳、CSV 取込、同期履歴、SFA 補完、月次出力をそのまま土台にします。作り直しはしません。本開発で足すのは次の4つです。
  1. デモ認証を撤去し、Cloudflare Access と Entra ID のシングルサインオンに置き換える
  2. 3系統のモックアダプタを実 API 版に差し替える（Dynamics 365、Teams、Knowledge Suite）
  3. Excel ファイルを直接取り込み、原本を R2 に保存する
  4. 閲覧ログと定期実行を追加する
• 外部連携は読み取りを主案にします。Teams への書き戻し、AI、承認フロー、過去データの台帳化の拡大は、100万円を超えるオプション（B案）として分けました。B案は社長決裁になるため可能性は低いと見ています。本番運用の結果を見てから、次年度予算で要否を判断していただく想定です。
• 15年分・2TB の過去データは、原本のまま R2 に保管して目録から検索できるようにします。D1 に台帳化するのは直近3年度だけです。
• 金額が確定するかどうかは、先方の API 仕様にかかっています。Dynamics 365 の製品種別、Teams 上の見通しファイルの形式と置き場所、Knowledge Suite の API 可否の3点です。確認事項は §11 に並べました。

1. 現状整理：Phase-1 で実証できたこと / まだモックのこと

Phase-1 は Cloudflare Workers（Hono）＋ D1 の単一 Worker 構成です。自動テストは Vitest と @cloudflare/vitest-pool-workers（Miniflare 上の D1）で動いていて、ユニット6件と API 7件がすべて成功しています。公開デモでは 2026年9月25日に GET / と GET /api/health が 200、閲覧者のログインも 200 を返すことを確認しました。

1.1 実証できたこと（本開発でそのまま使う）

ここで分かったのは、台帳の形と画面の使い方は D1 だけで十分に表現できるということです。連携先の違いは IntegrationAdapter の中に閉じ込められます。本開発で API ルートや画面をほとんど変えずに済むのはこのためです。

1.2 まだモックのこと、本番前に直すこと

2. 本開発のゴールとスコープ

2.1 ゴール

要件の「目的」と「達成すべきゴール」を、検収できる形に言い換えました。

1. 10〜20個の Excel に散っている6領域のデータを、1つの画面で期間・顧客・製品・担当者から探せる
2. 月初の前月売上取込（Dynamics 365）、Teams の見通しの取得、SFA の全案件チェック（月2回）に手作業が要らない。担当者は確認と補完だけをする
3. 管理者でなくても、閲覧者として必要な数字と月次資料を自分で見られる
4. 個人情報を含むので、誰が何を見たかを後から追える

効果の目安として、SFA まとめ資料の更新（月2回×2日）は「確認のみ・月1日程度」まで減らすことを目標にします。年間では約36人日の削減です。月初の資料作成と Teams からのダウンロード作業は、ヒアリングで現状を測ってから目標に加えます。

2.2 スコープ（主案 A）

2.3 受入基準（主案）

• 11月初と12月初の2回、月初処理（前月売上の取得と月次資料の生成）が手作業なしで完了し、Dynamics 365 側の合計と一致する
• Teams の見通しの変更が1時間以内に台帳へ反映される
• Knowledge Suite の案件が、未入力・低精度の一覧と補完記録に反映される。補完済みは次の取込で上書きされない
• 先方の Excel サンプル10本が取込プロファイルで取り込め、エラー行が一覧で確認できる
• Entra ID に登録された利用者以外は画面にも API にも到達できない。閲覧者は更新できない
• 閲覧とダウンロードの記録が管理画面で確認できる

3. 目標アーキテクチャ（Cloudflare 中心）

図と詳細は PHASE2_ARCHITECTURE.md にまとめました。要点は次のとおりです。

D1 を正本に選んだ理由。 利用者は約20名で、書き込みは取込と同期がほとんどです。D1 の上限（1DB 10GB、単一リージョンへの書き込み）で困る量ではありません。Postgres＋Hyperdrive は、台帳が数GBを超える、重い集計が常時必要になる、といった要件が出たときに初めて検討します。月額の固定費が増えるため、主案には入れていません。

Power Platform を主案にしない理由。 先方は Microsoft 製品を使っているので、Power Apps と Dataverse は自然な選択肢です。ただ、Premium ライセンスは公開価格で1ユーザー月額20ドル前後で、20名では月6万円程度になり、月額10万円の予算の大半を占めます。Knowledge Suite の標準コネクタも見当たりません。プロトタイプがすでに動いていることも合わせ、Cloudflare を主案にしました。

3.1 環境

Cloudflare アカウントは先方名義にし、受託者はメンバーとして参加する形を提案します。公開デモは受託者側のアカウントにあるので、実データを扱う前に停止するか Access で保護します。workers.dev のままでも Access はかけられます。独自ドメインは任意です。

3.2 スキーマの追加（マイグレーション 0002 の方針）

• users：password 列を削除し、メールアドレスを Access の ID と突き合わせるキーにする。active と last_seen_at を追加
• employees：社員マスタ。owner_name の自由入力をやめ、Dynamics 365 と Knowledge Suite の担当者 ID を持つ
• master_mappings：外部コードと台帳コードの対応表（システム、種別、外部キー、台帳 ID）。対応が付かない行はデータ品質の一覧に出す
• import_profiles：ファイルごとの列対応、シート名、見出し行の位置
• import_jobs：r2_key、sha256、source_type（xlsx / csv）を追加
• sync_runs：trigger（cron / manual）、attempt、retry_of、error_code を追加。差分取得の位置は sync_cursors に持つ
• access_logs：閲覧・ダウンロードの記録
• archive_files：R2 に置いた過去ファイルの目録（年度、種別、元のパス、サイズ、ハッシュ）
• report_files：定期生成した月次資料の保存先
• settings：乖離の閾値（現在は src/quality.ts L45 の30%固定）や低精度判定の金額（L23 の10万円固定）を管理画面から変えられるようにする
• mock_external_records：本番では使わない。テスト用のフィクスチャに移す

4. 外部連携の本番化計画

アダプタの形（src/adapters.ts L19–L23 の IntegrationAdapter：pull と任意の push）はそのまま残し、中身だけを実 API 版に差し替えます。環境変数から「実 API 版」と「モック版」を選ぶファクトリを置き、テストと開発ではモックを使い続けます。実 API 版で共通に持つのは次の4つです。

• トークン取得：Entra ID のクライアント資格情報フロー。有効期限内はキャッシュする
• HTTP 再試行：429 と 5xx は Retry-After に従い、1回の実行の中で最大3回まで再試行する
• 対応表：master_mappings で外部コードを台帳コードに変換する。変換できない行は取り込まずに品質一覧へ出す
• 冪等性：外部 ID で upsert する。同じ実行を何度繰り返しても結果が変わらない

失敗した実行は sync_runs に残し、次の定期実行で自動的にやり直します。管理者は外部連携画面の「取得」ボタン（既存の POST /api/sync/:system/:direction）で即時に再実行できます。失敗が2回続いたら管理者に通知します。通知手段は、管理者へのメールか Teams のワークフロー（Webhook 受信）のどちらかで、テナントのポリシーを確認してから決めます。

4.1 Microsoft Dynamics 365（前月売上）

4.2 Microsoft Teams（月次見通し）

Teams のチャネルにあるファイルの実体は SharePoint のドキュメントライブラリに保存されているので、Microsoft Graph から読みます。

確認が要ること。 見通しの正本を Teams に置き続けるのか、台帳に移すのかによって B案の中身が変わります。第1回の打ち合わせで決めたい事項です。

4.3 Knowledge Suite（SFA 案件）

5. データ移行

5.1 方針

• 台帳化（D1）するのは直近3年度（FY2025〜FY2027）だけです。月次の計画・見通し・実績で数十万行、容量は1GB未満と見込んでいます。
• 15年分・2TB 級の過去データは原本のまま R2 に置き、目録（archive_files）から年度・種別・ファイル名で探してダウンロードできるようにします。中身を解析して台帳に入れるのは、必要な年度が決まった時点で B案か個別見積とします。
• 台帳化は、先方と受託者で作業を分担します。

5.2 手順

1. 棚卸し（先方）：10〜20個のファイルを、こちらが用意する一覧表に記入していただきます。記入項目はファイル名、用途、更新頻度、担当、行数、個人情報の有無です。
2. 分類（共同）：6領域に入れるファイルと、原本保管だけのファイルに分けます。
3. 取込プロファイル（受託者）：主案では10本まで作ります。11本目以降は、Phase-1 からある列対応の画面で管理者が自分で対応を付けられます。見出しの別名は src/templates.ts に追加していけます。
4. 月別ファイルの統合：売上計画は「年月＋顧客＋製品＋担当」のキーで upsert し、年度は fiscalYearOf で付けます。1年分を別の Excel にまとめ直す作業は要らなくなります。
5. 名寄せ：「(株)」と「株式会社」のような表記ゆれは master_mappings で吸収します。対応が付かない行は import_row_errors に残り、先方で直して再取込できます。取込は冪等です。
6. 並行稼働：11月と12月の月末をまたいで、Excel と台帳を並行して運用します。そのうえで Excel の更新を止める日を決めます。

5.3 2TB の格納

6. セキュリティ・個人情報・監査

6.1 デモ認証は本番に残さない

Phase-1 の認証はプロトタイプ専用です。本番のリリース前に、次をすべて撤去または置換します。

置き換え後は次の流れになります。

1. Cloudflare Access が Entra ID でサインインさせる。MFA は Entra の条件付きアクセスで強制する。Access のポリシーでは「営業台帳利用者」グループだけを許可する
2. Worker は Cf-Access-Jwt-Assertion ヘッダーの JWT を、チームドメインの公開鍵（https://{チーム名}.cloudflareaccess.com/cdn-cgi/access/certs）と aud で検証する。メールアドレスのヘッダーだけを信用することはしない
3. 検証したメールアドレスで users 表を引き、ロール（管理者 / 閲覧者）を決める。表にない人は、Access を通過していても拒否する
4. requireUser と requireAdmin（src/auth.ts L68、L74）の呼び出し側はそのまま使えるので、API ルートの書き換えは要らない

6.2 シークレット管理

• クライアントシークレットと API キーは wrangler secret put で Workers のシークレットに入れます。wrangler.toml とリポジトリには置きません。
• Entra のアプリは、Dynamics 365 用と Graph 用に分けます。付与するのは最小権限（読み取りと Sites.Selected）だけです。
• シークレットは12か月ごとに更新します（Entra の上限は24か月）。期限の1か月前に通知し、更新作業は保守に含めます。
• デプロイ用の Cloudflare API トークンは、Workers、D1、R2 の編集だけに絞って CI のシークレットに置きます。

6.3 個人情報と監査

7. AI（任意）

要件では「AI活用に興味がある（マストではない）」とされています。そこで主案には入れず、B案に次の範囲だけを置きます。

やる範囲（B案）

• 月次資料のコメント下書き：KPI と乖離の一覧（findAnomalies の結果）を Workers AI に渡し、3〜5行の所見の下書きを作る。数字は台帳の値を差し込むだけで、AI には計算させない。画面では「下書き」と明示し、人が直してから使う
• 自然言語から検索条件への変換：「9月に青葉向けで計画を下回っているもの」のような文を、期間・顧客・担当者の条件（JSON）に変える。検索そのものは今の SQL で行う。入口は Phase-1 の /api/ai/ask（src/app.ts L363）で、入出力はそのまま保つ

やらなくてよい範囲

• 入力漏れや異常値の検知。assessDeal と findAnomalies のルールで足りていて、説明もしやすい
• 2TB のアーカイブを Vectorize で意味検索すること。索引の作成と維持の費用が効果に見合わない
• AI による台帳の自動修正や自動補完。補完は人が確認する今の流れを保つ
• 売上予測モデル
• 外部の LLM サービスへのデータ送信

費用は Workers AI の無料枠（1日10,000 Neurons）でほぼ収まります。利用回数には上限を設けます。日本語の品質はモデルによって差があるため、検証環境で Phase-1 の架空データを使って評価してから採用を決めます。

8. 開発・導入スケジュール

選定（2027年3〜5月）を経て、納期の2028年1月に収まる計画です。作業量は約20人日ですが、先方の確認やアプリ登録の手続きを待つ期間を含めて7か月に分けています。

毎年9月の予算取りに合わせ、2027年9月の時点でB案の要否を判断する材料（検証環境での試用結果）をお出しします。

9. 概算（税抜）

9.1 主案 A（初期100万円以内・月額10万円以内）

人日単価は 4.5万円（ニアショアとオフショアの併用を想定）で見積もっています。Phase-1 の台帳、取込、同期履歴、補完、月次出力を流用するので、新しく作るのは連携、認証、移行、運用の部分だけです。

• 単価が5万円の場合は小計がちょうど100万円になり、変動枠が残りません。その場合は #7 の .xlsx 化を外して SpreadsheetML のままにし、#8 の台帳化を直近2年度に縮めて、約2人日を減らします。
• 仕様が想定より重かった場合は、変動枠を使う前に Must と Should の入れ替えを先方にご相談します。上限は超えません。

月額（主案）

Microsoft 365 / Dynamics 365 / Knowledge Suite は先方の既存契約で足りる前提です。アプリケーションユーザーや API 利用に追加のライセンスが必要になった場合は別途ご相談します。Cloudflare のセルフサービス契約はクレジットカード払いです。請求書払いが必要なら、受託者が立て替えて請求する形も選べます。

9.2 オプション B（100万円超・決裁リスクあり）

• A案と合わせると初期は約157.5万円になります。要件に「100万円を超えると社長決裁となり、決裁が下りる可能性は低い」とあるとおり、一括で発注いただくのは難しいと考えています。
• 月額は、Workers AI と Queues の実費（数千円）と保守の増額（8万円）で約9万円です。月額の上限には収まります。
• 決裁基準を避けるための分割発注は提案しません。B案の各項目は、本番運用の結果を見て要否を判断する独立した改善です。必要なものだけを、2027年9月の予算取りで次年度（FY2028）の予算として正規に審議いただく想定です。

10. リスクと前提条件

11. 次のアクション（先方への確認事項チェックリスト）

連携

• Dynamics 365 の製品種別とバージョン、環境 URL、検証用サンドボックスの有無
• 「前月売上」として使っている帳票またはテーブル（請求書明細か、出荷か、受注か）と、月初に確定するタイミング（何営業日目か）
• Entra ID テナント管理者の窓口と、アプリ登録・管理者同意の社内手続き
• Teams の見通しファイルのチーム名とチャネル、ファイル形式（Excel / Lists）、シート構成、同時編集の運用ルール
• 見通しの正本を Teams に残すか、台帳に移すか
• Knowledge Suite の契約プラン、API の利用可否と条件、CSV エクスポートの項目

データ

• 10〜20個の Excel の一覧（ファイル名、用途、更新頻度、担当、行数）と、サンプルの提供（個人情報はマスキングで可）
• 顧客コード、製品コード、担当者の正本をどのシステムに置いているか
• 2TB の内訳（Excel / PDF / 画像など）と今の保管場所、アップロードに使える回線
• 台帳化する年度の範囲（主案は直近3年度）

セキュリティ・運用

• 個人情報の取扱規程：国内保管が必須か、保持期間、閲覧ログの保存期間
• 利用者約20名の一覧と、管理者にする人数
• 閲覧者に顧客担当者名を表示してよいか
• Cloudflare アカウントの名義、支払い方法（カード / 立替請求）、独自ドメインの要否
• AI 利用に関する社内ポリシー（B案を検討する場合）

こちらで進めること

• ReadyCrew 経由で WEB 会議を設定し、公開デモをご覧いただきながら上記を確認する
• 回答を受けて見積を確定し、2027年1月までに正式な提案書を提出する
• 実データを扱う前に公開デモを停止するか、Access で保護する

付録：Phase-1 から本開発への差分（ファイル別）