既存の AI書類チャット（Cloudflare Workers）と Shachihata Cloud / SDX を前提に、9画面のUI設計をどう実装に落とすかを整理したもの。未確定事項は末尾にまとめた。
| 項目 | 決定 | 設計への影響 |
|---|---|---|
| 主対象の業務 | 建設業許可 | 条項分割の規則は様式番号ベース。現在のSDXの19件（無人航空機中心）は参照元にならない |
| 第1段階の範囲 | 9画面すべて | 出典検証はbbox、承認ゲートはシヤチハタAPIに依存。依存先が揃う順に着手する |
| 助言の提供 | 初期から有効 | パイプライン4段目を第1段階に含める。記録と助言は別ブロックで表示 |
| 利用人数 | 2〜3名 | 承認ゲートは他者レビューとして成立。担当者と承認者のロール分離が必要 |
| 参照案件の選定 | 自動選択＋差し替え | 画面3の初期状態を「選ばれた状態」に変更。選定理由の表示が必要 |
| 事務所標準 | 自動抽出＋人が確認 | 抽出結果を承認する画面が新規で必要（既存の9画面になし） |
| 差分レビュー | AI由来の変更のみ必須 | revision.originでai／humanを区別し、aiの未レビューをブロック |
三層に分ける。SDXを主データストア、Cloudflare側を作業データと検索インデックス、Shachihata Cloud を承認と証跡。既存資産をそのまま活かせる形。
| 層 | 置き場所 | 持つもの |
|---|---|---|
| 案件台帳 | SDX（既存シート） | 案件名、案件種類、契約当事者、案件開始日時、原本ファイル、抽出全文 |
| 作業データ | Cloudflare D1 | 条項、出典位置、ドラフト、差分履歴、レビュー状態、AI相談スレッド |
| 検索 | Cloudflare Vectorize | 条項単位の埋め込みベクトル + 案件ID / 条項IDのメタデータ |
| 原本キャッシュ | Cloudflare R2 | SDXから取得したPDFの作業用コピー、OCR中間結果、書き出し済み成果物 |
| 承認・押印 | Shachihata Cloud | 申請、決裁、タイムスタンプ、監査証跡 |
SDXとD1は 案件ID（SDXの _id）で紐づける。D1側はSDXの内容を複製せず、参照とオフセットのみを持つ。SDXにAPIがあることは確認済みのため、WorkerからSDXの行を直接読み書きする前提で設計する。
出典表示と差分レビューを成立させるための最小構成。clause の位置情報が出典表示の精度を決める。
| テーブル | 主な列 | 役割 |
|---|---|---|
document | id, sdx_row_id, sdx_file_name, doc_type, ocr_status, ocr_version, page_count | SDXの1ファイルに対応。ocr_versionで処理済みバージョンを管理し、座標の追装対象を絞る |
clause | id, document_id, seq, label, text, page, bbox, split_method, confidence | 条項1つ。labelは「第3条」等、bboxは原本上の座標（nullable）、split_methodはrule／llm。出典表示の実体 |
draft | id, case_id, status, template_id, assignee, approver, approved_at | 作成中の申請書1件。statusが承認ゲートを制御。担当者と承認者を別に持つ |
draft_field | id, draft_id, key, value, source_clause_id, confidence, flag | ドラフトの1項目。source_clause_idで出典に接続、flagが要確認表示 |
revision | id, draft_field_id, before, after, origin, actor, reason, reviewed_at | 追記のみ。originがaiの行はreviewed_atが入るまで承認に進めない |
thread / message | id, draft_id, role, body, cited_clause_ids | AI相談。引用した条項IDを保持し、後から出典を再表示できる |
office_standard | id, key, expected, rationale | 事務所標準。ドラフトとの不一致検出に使う |
consent | id, client_id, scope, granted_at, revoked_at | 依頼者の同意状態。未同意の案件はLLM送信をブロック |
llm_call_log | id, case_id, purpose, model, token_count, created_at | 送信ログ。監査と事故時の調査用 |
bbox はnullableとし、座標がなくても全画面が動く状態で作る。後から座標を入れる際は再分割せず、既存の条項テキストと突き合わせて座標だけを埋める。条項IDが変わらないため、差分履歴とAI相談の引用リンクが切れない。逆に再分割すると、それまでの履歴の参照先が全て壊れる。ocr_version で未処理の文書を特定できるようにしておく。既存の2段構成を維持したまま、段の中身を条項単位に置き換える。将来の助言機能は4段目として追加する。
clauseへ格納 → 埋め込み生成 → Vectorizeへ登録。Queues経由の非同期処理。Workerの実行時間制限があるため同期にしない。設計済みの9画面が、それぞれどこのデータで動くか。
| # | 画面 | データ出所 | 備考 |
|---|---|---|---|
| 1 | 案件ダッシュボード | SDX | 既存シートをほぼそのまま表示 |
| 2 | 書類取り込み | SDX → R2 → D1 | パイプライン1段目。進捗表示が必要 |
| 3 | 参照案件の選択 | Vectorize + SDX | 自動選択された状態で開く。選定理由と差し替えUIが必要 |
| 4 | AI相談・書類セット | 既存Worker + D1 | 既存資産の延長。2ブロック構成に変更 |
| 5 | 差分エディタ | D1（draft_field / revision） | 新規実装。clauseの位置情報に依存 |
| 6 | 案件比較 | D1 + SDX | 新規実装 |
| 7 | 出典検証 | D1 + R2（原本PDF） | page / bboxで原本の該当箇所を表示 |
| 8 | 承認ゲート | D1 → Shachihata Cloud | ワークフローAPI経由で申請 |
| 9 | 書き出し・引き渡し | R2 + Shachihata Cloud | 押印済みPDFを受け取りSDXへ書き戻す |
| 10 | 事務所標準の確認 設計済 | D1（office_standard） | 自動抽出した標準を人が承認する画面。新規で必要 |
実装着手前に確定が必要なもの。上ほど影響範囲が大きい。
split_methodがllmの条項は出典表示に「分割は自動推定」の印を付け、確認すべき箇所を絞る方針。bboxがあれば矩形ハイライト、なければページ単位表示＋テキスト一致箇所のハイライトに落とす。座標を返す日本語OCRサービスの選定は第2段階の判断でよい。