フィージビリティスタディ報告書作成エンジン（産業プロジェクト FS 報告書 · 対外納品完全オペレーションマニュアル）
スキル形態注記：本スキル = FS 報告書作成の「Word 完成版 + Excel 財務テンプレート」納品版。 成果物形態：①Word 報告書全文（表紙→本文→付属表、NDRC 2023 アウトライン準拠）②Excel 投資財務テンプレート（数式フル実装）。 同一業務ファミリーの兄弟スキル（納品形態で区分）：PPT 版 FS プレゼン資料、PDF 版 FS 報告書 — 別途整備中（計画、README スキルロードマップ参照）。 クイックスタート：クライアント/プロジェクト担当者が素材を提供 → 本エンジンの6ステップ → 3点セット（報告書docx + 財務テンプレートxlsx + 作成説明書docx）をチャットボックスに送信。 本エンジンは 2026-09 の実大規模案件（300億円海洋産業クラスター · 9分冊 · 20万字）の全フロープロセス実戦経験から構築され、すべての落とし穴情報を含んでいます。
v1.6 機能強化（今回）：①
report_qa.py（長文QA：キャッシュ/アサーション検証/正規表現による確認・修正）とpipeline_check.py（パイプライン自己診断）を新規追加。Python 標準ライブラリのみ、ゼロ依存で即実行可能。②「報告書品質3関門」と「納品前検証チェックリスト」を追加し、「感覚による納品」から「項目ごとのチェックによる納品」へ移行。③「改ページと画像の鉄則（Word レンダリング ≠ LibreOffice レンダリング）」と PDF 版納品を追加。④「修正稿と口径合わせ」章を追加し、クライアントからの戻し・数字変更で失敗しない。⑤ 財務シミュレーションの口径と4表クロスチェック表、感応度分析要件を追加。
一、トリガー条件と位置づけ
トリガー：クライアント/委託元から「フィージビリティスタディ報告書」「プロジェクト提案書」「資金調達デューデリジェンス報告書」の依頼。クライアントが断片的な素材（プロジェクト名/場所/規模/数枚の画像）を提供し、投資家向け・審査向け・招商向けの正式報告書が必要な場合。
兄弟スキルとの役割分担：
| スキル | 用途 |
|---|---|
| 本エンジン | 対外納品クライアント向け FS（コンプライアンスのゴールドスタンダード＝NDRC 2023 アウトライン） |
| report-production-pipeline | 汎用報告書作成パイプライン（5フェーズ+自己診断スクリプト）、本エンジンのStep2～4と同型 |
| feasibility-study-writing | 内部意思決定/ビジネスプラン検証 |
| mh-calculation | 財務シミュレーションエンジン（17表、本エンジンのシミュレーションでこれを呼び出す） |
商業納品のレッドライン（ステルスOEM）：
- クライアント自身が署名して納品。我々は内容のみを提供——作成機関・日付・捺印欄はすべて空白にし、クライアントが記入。
- AIの痕跡を絶対に残さない（ファイル名に「最終版/AI/デュアルモデルレビュー」を含めない、メタデータを消去、本文にAI記号なし）。
- 資格・捺印：クライアントに、資格を持つエンジニアリングコンサルタント会社と提携して捺印するよう促す（コンプライアンス上のレッドライン＋顧客獲得の入口）。
- 価格アンカー：「速さ＋専門性」を売りに。カスタム標準グレードは 8千～1.5万元、3千元以下の低価格帯は扱わない。
二、業界のゴールドスタンダード：2つのアウトライン（まず判定してから執筆）
国家発展改革委員会 「発改投資規〔2023〕304号『投資プロジェクトフィージビリティスタディ報告書作成アウトライン及び説明』」——FS を作成する唯一のコンプライアンスベンチマーク。
| 判定 | 政府投資プロジェクト（汎用アウトライン11章） | 企業投資プロジェクト（参考アウトライン10章） |
|---|---|---|
| 出資 | 政府投資/資本金注入/特別債 | 企業自己調達/市場ベース融資 |
| 典型的なクライアント | 城投/プラットフォーム/政府プロジェクト | 民間企業/産業投資/混合所有制 |
| 強調事項 | 建設の必要性/社会的便益/資金バランス | 市場需要/収益性/ビジネスモデル |
完全な章ごとの要件は references/（gov-dagang-2023.md 政府版、ent-dagang-2023.md 企業版）を参照。執筆時は章ごとに対照すること。
判定セルフチェック（誤判定＝全書き直し、まずこの4問に答える）
- 資金の出所は：財政資金/特別債/政府プラットフォーム出資 → 政府版；企業自己調達/商業融資/市場ベース融資 → 企業版。
- 誰に見せるのか：発改委の承認/認可、財政資金申請 → 政府版；銀行の融資審査、投資家の意思決定、招商 → 企業版。
- 誰のニーズに応えるのか：公共ニーズ（地域の脆弱性解消/民生/上位計画のハード要件）→ 政府版；市場需要と収益性 → 企業版。
- これらの章があるか：パフォーマンスマネジメント計画、カーボンピークアウト・カーボンニュートラル分析 → 政府版固有。ビジネスモデル/マーケティング戦略/競争分析のウェイトが高い → 企業版。
混合出資（政府資本金＋企業自己調達）の場合：審査/認可の観点を主軸とし、企業財務の論証は「投融資と財務計画」章に組み込み、概要で二重観点を明記する。
三、6ステップワークフロー（全プロセス）
Step 0：素材棚卸 + 判定 + 受注3質問（0.5h）
執筆前にまず3点を確認：
- 用途（プロジェクト承認/銀行融資/招商ロードショー/内部意思決定）→ 版式の深さとアウトラインを決定
- 事業者の性質（政府プラットフォーム/民間企業）→ 政府版か企業版かを決定
- デッドライン → モードA（完全版7-15日）かモードB（初版クイック納品1-3日）を決定 ⭐
素材棚卸「既存 vs 不足」、不足は一度に質問して往復を避ける。投資見積りがない → 業界ベンチマークで推定し「○○業界の慣行による」と注記。用地/立地がない → 公開計画を調査。クライアントからの情報が少ない → モードBで進める。
完了基準：判定結論を一文で書き留める（政府版/企業版 + 根拠）。素材不足リストを文書化。モードA/Bを明確にする。
Step 0.5：資料要求リスト（3バッチ、一度に要求し、書きながら質問しない）
| バッチ | 内容 | 不足した場合の結果 |
|---|---|---|
| 第1バッチ 数量・価格・投資基礎 | 建設内容と規模、設備リストと見積もり、地価/賃料、水道・光熱費、人件費 | 不足の場合は「事前検討版」のみ提供、投資見積りは業界慣行とする |
| 第2バッチ 主体とコンプライアンス・権利確認 | 営業許可証/主体文書、用地予備審査と立地、環境アセス/エネルギーアセス/水保全/社会安定性評価、海域使用等の承認と手続き状況 | 不足の場合はコンプライアンスモジュールは「手続き中」と記述、レビューで指摘される |
| 第3バッチ 市場と受注実証 | 意向注文/枠組み契約、上流下流契約、同種プロジェクトの運営データ、政策根拠文書 | 不足の場合は市場分析は公開データのみ、深さは低下 |
リストテンプレート：references/data-request-list.md。リスト送付時に併せて説明：「第2バッチが不足の場合は事前検討版のみ提供可能」——これは専門性を示すとともに、二次請求の手段でもある。
Step 1：インターネット調査・デューデリジェンス（必須！1-3h、4ルート並行）
検索せずに書くな。 FS が「通用する」ものと「テンプレートの決まり文句」の分かれ目＝すべての主張にデータ/政策の裏付けがあるかどうか。
- 政策面：省市の産業政策/特別計画/業界参入条件 → 「[業界] 十五五 計画」「[省市] 産業政策 [業界]」を検索
- 市場面：業界規模/成長率/競争環境 → 証券会社レポート/業界団体/統計局、複数ソースのクロスチェック
- 地域面：立地予定地の産業団地/土地/インフラ/同種プロジェクト → 「[都市] [業界] 産業団地」を検索
- ベンチマーク面：同種プロジェクトの投資効率/収益率 → mh-calculation の業界ベンチマークと対照
各キーデータに出所（機関＋年＋リンク）を付け、執筆時に引用元を明記。データがない場合無理に書かず、「デューデリジェンスで確認が必要」と記述し、業界レンジを提示する。
データ取得チャネル（ページ難易度順、最初のレベルで諦めない）：
- 第一段階：通常のスクレイピング/検索エンジンの要約 —— 政策原文、ニュース、公開レポート
- 第二段階：アンチスクレイピングバイパス付きスクレイピング（JSレンダリング、Cloudflareチャレンジ処理）—— 政府サイト、業界団体、レポートサイト
- 第三段階：ブラウザ実制御（クリック/ページめくり/フォーム入力）—— インタラクションが必要なデータ（検索システム、公示データベース）
- 取得した生データはファイルに保存して痕跡を残す（
<プロジェクト名>/調査/以下に出所ごとに命名）、執筆時に再確認可能、修正時に再検索不要。
完了基準：キーとなる数字がすべて「誰が言ったか、何年か、どの口径か」に答えられる。生データがファイルに保存され、再確認可能。
Step 2：分担執筆（モデルマトリックス——これが20万字の大著を生み出す鍵）
1つのモデルに全文を一気に書かせるな。 役割を分担：
- 主脳（現在の対話モデル）：構造の骨組みを構築、総論/概要/戦略論証を執筆、最終的な組み立てと校閲
- 拡充モデル（より強力なモデルAPI、例：DeepSeek V4 Pro / 千問 max）：財務評価、市場分析など重要な章を深く拡充——章ごとに「現状＋拡充要求＋例」を入力、max_tokens を大きく設定（12000+、そうしないと reasoning が出力を0にしてしまう）
- シミュレーションモデル：mh-calculation を呼び出して IRR/NPV/投資回収期間を計算（手計算禁止）
- レビューモデル（賢いモデルが全文を読んで欠点を指摘）：千問/豆包に、経験豊富な実務家として全文を読んでもらう（要約ではなく）論理の穴/口径の矛盾/データの不自然さを探す
- ビジュアルモデル（組版検収、Step 4 参照）：Mimo 2.5 / DeepSeek Vision / GLM-4V / 千問VL でクロスチェック
経験則：同一キーで2段階を呼び出せる（flash日常用/pro本番用）。レビューには全文の実際のテキストを与え、要約を与えてはならない。そうしないと意味がない。
執筆前にまず章リストを作成（各章＝何を述べるか｜何に基づいて述べるか｜どこから来たか）、証拠が空白の章は Step 1 に戻して補完する。証拠なしで書き始めることを許すな。 リストテンプレートは templates/report-plan.md。
完了基準：章リストの3列がすべて揃い、空白がない。各章の初稿にデータ、出所、論理の閉じたチェーンがある。
Step 3：品質3関門（AI初稿 → 納品可能の間の関門、飛ばすな）
| 関門 | 何をする | 通過できない場合の対処 |
|---|---|---|
| ① リフレクション | プロセスを振り返る：データは完全か？出所は信頼できるか（一次/二次）？論理に飛躍はないか？ | データを補完、出所を変更、論証を補強 |
| ② レビュー | リストに従って項目をチェック：結論と証拠は一致しているか？過度な推論はないか？反対意見に応答しているか？数字/名称/日付は正確か？口径は統一されているか？ | 項目ごとに修正、「大体OK」では済ませない |
| ③ 修正 | 修正後必ず修正箇所を再度スキャン（新たなエラーが入っていないか重点確認）、さらに全文の旧口径残存を再スキャン | 再スキャンで通過しなければもう一度やり直す |
リスト化バージョン：templates/review-checklist.md。機械で実行可能な最低限のチェック：
python3 scripts/pipeline_check.py 報告.md # 出所表示/不確実性開示/反対視点/結論/構造/数字口径
python3 scripts/pipeline_check.py 報告.md --strict --json # 終了コードが0以外＝重大な問題あり、自動化に直接組み込み可能
草稿作成とレビューは同じセッションで完了してはならない——自分が書いたものは自分では間違いに気づきにくい、これは認知の法則であって態度の問題ではない。視点を変える/モデルを変える/少なくともセッションを変える。
Step 4：組版エンジニアリング（AI初稿 → プロフェッショナル納品版、scripts でワンクリック）
AI が生成した docx をそのまま納品する＝素人の証。scripts パイプラインで処理：
# 1) ゼロから骨組みを作成：表紙+署名ページ+自動目次+ヘッダー・ページ番号（スタイル体系は内蔵済み）
python3 scripts/gen_report_docx.py "プロジェクト正式名称" "" 出力.docx
# （中間引数＝作成機関、対外納品では常に空文字列を渡して空白にする）
# 2) 既存の初稿/クライアントdocx：表紙などを追加（表紙/署名ページ/目次フィールド）→ scripts/face_docx.py --help 参照
python3 scripts/face_docx.py 入力.docx 出力.docx "プロジェクト正式名称" "" "KY-2026-×××"
# 3) 組版クレンジング（AI痕跡除去+スタイル再構築+テーブル美化）⭐ 最もよく使う
python3 scripts/docx_polish.py 入力.docx 出力.docx "プロジェクト正式名称" --title "報告書タイトル"
# 4) 財務テンプレート（数式完備、青＝入力）⭐ プロフェッショナル版 v2（三線表+5色セマンティック+表紙・説明）
python3 scripts/gen_model_xlsx_v2.py 出力.xlsx "プロジェクト名" 総投資額万元 達産収入万元 建設期間 運営期間
# 例: python3 scripts/gen_model_xlsx_v2.py テンプレート.xlsx "××プロジェクト" 3000000 600000 4 16
# 5) 作成説明書と資料要求リスト（1-2ページ、納品3点セットの1つ）
python3 scripts/gen_shuoming.py 出力.docx "プロジェクト名称" "約300億元"
4.1 改ページと画像の鉄則（Word レンダリング ≠ LibreOffice レンダリング——血と涙の教訓）
核心認識：LibreOffice で PDF に変換して組版を自己チェックするのと、Word/WPS で開いた効果は異なる。クライアントの 90% は Word/WPS を使用。改ページ/画像の切れのような問題は Word エンジンでのみ顕在化するため、先に XML を確認してから結論を出せ。
| 症状 | 根本原因 | 修正 |
|---|---|---|
| 画像が細い線/隅だけ表示される | Normal スタイルの lineRule="exact" 固定行間が行内画像を切り取る（Word 特有、LO では切り取らない） | 本文スタイルの行間を atLeast に変更（視覚的な行間は維持するが画像が押し広げられるのを許可）；画像を含む段落は明示的に spacing line=240 lineRule=auto を設定 |
| 1ページに1行しかない/広い空白がある | テーブルの各行に cantSplit（改ページ禁止）が設定されている→大きなテーブルが収まらず丸ごと次ページに飛ばされる | ヘッダー行のみ cantSplit を設定、データ行はすべて改ページを許可；ヘッダー行に tblHeader を追加（改ページ時にヘッダー行を自動繰り返し） |
| テーブルが Word の異常な改ページを引き起こす | テーブルの総幅が版面を超えている（A4版面=8730 twips、左マージン3cm） | gridCol を等比で ≤8700 twips に縮小 |
| 本文の断片/孤立行（ページ末尾に2行だけある） | 段落がちょうどページをまたいで2行だけ残る | 該当段落に keepLines を追加（段落内改ページ禁止）、段落全体を次のページに移動 |
| 最終ページの孤立行（「（全文完）」が単独で1ページを占める） | 付録の大きなテーブルの後、最後の段落が収まらず最終ページに押し出される | 末尾のマークを直接削除するか、前のテーブルを圧縮 |
| 表紙の「作成機関：______」の下線 | 下線スペースプレースホルダー run（<w:u>+スペース） | 機関名が記入されている場合下線スペースの run を削除し、プレースホルダーの下線を残さない |
修正後は必ず再レンダリングして確認：fitz でページごとにスキャンし、max_y<350 の「ほぼ空のページ」と画像幅>200pt を確認して完全を確認。
4.2 PDF 版納品（投資家向け読書形態）
- LibreOffice
soffice --headless --convert-to pdfでOK、タイトルアウトラインが自動的にブックマークになる（766個＝プロフェッショナルレベル） - ページ番号フィールド/目次フィールドがプレースホルダーとしてレンダリングされるのは正常（Word の F9 でリフレッシュされる）——PDF は LO レンダリングで影響なし。docx はクライアントに Word で開いて F9 を押すよう指示
- 大きな docx（>10MB、画像多数）はスマートフォン/IM プレビューで画像が表示されない場合がある → 納品時に PDF 版を添付 + Word で開くよう指示
Step 5：報告書 QA（数字と口径の自動健康診断）
python3 scripts/report_qa.py stats 報告.docx # サイズ健康診断：ページ数/段落数/文字数/内蔵画像
python3 scripts/report_qa.py grep 報告.docx "旧口径|旧数字" # 正規表現検索（表のセルも含む、表のスキャン漏れ＝数字の半分をスキャン漏れ）
python3 scripts/report_qa.py check 報告.docx baseline.json # アサーション検収：禁止語句は0ヒット必須、必須項目は必ず出現
python3 scripts/report_qa.py cache 報告.docx # プレーンテキストキャッシュを構築、修正期間中に繰り返しチェック、 ~14 倍高速
- 修正稿納品前に、クライアントの要求を1つ1つアサーション（禁止語句/必須出現）にして、1つのコマンドで全件ヒットを証明——人の目で3回スキャンするより信頼性が高い
- アサーションセットが空の場合は明示的に警告を出し、「0/0 全緑」の擬陽性を防止
Step 6：ビジュアル検収 + 納品（3点セット + 二重出力）
ビジュアル検収（納品前の最後のゲート）：AI 組版の問題は文字検査では見えない。レンダリングして画像にし、ビジュアルモデルに「実際に見て」もらう必要がある。単一モデルはごまかしたり誤判定したりする → 2つ以上のモデルでクロス検証し、問題を座標データで確認してから修正する。
# 環境変数はどれか1つを選択（順序推奨：無料 → 安くて速い → 予備）
export ZHIPU_API_KEY=... # ① GLM-4V-Flash（無料、速度1.6秒/ページ）——最優先
export DASHSCOPE_API_KEY=sk-... # ② qwen3-vl-flash（百煉千問ビジュアルFlash、安くて速い）
export MIMO_API_KEY=... # ③ シャオミ Mimo 2.5（ネイティブマルチモーダル）
export DEEPSEEK_API_KEY=... # ④ DeepSeek vision（予備——DeepSeek は主に執筆作業用、ビジュアルは使用を最小限に）
python3 scripts/vision_check.py 報告.docx # docx→重要なページをレンダリング→マルチモデルレビュー（①→②→③→④の順に自動試行）
納品（3点セット）
プロジェクト名_FS報告書_v1.0.docx ← 報告書本体（表紙→目次→本文→付属表）
プロジェクト名_財務テンプレート_v1.0.xlsx ← 投資財務テンプレート（数式完備、青＝入力）
プロジェクト名_作成説明書_v1.0.docx ← 1-2ページの説明書
納品時に一言添える：「データ更新の場合は、財務テンプレートの入力セル（青色）を修正するだけで、ドキュメント側の再計算は自動で行われます。ご質問があればお気軽にどうぞ。」
四、修正稿と口径合わせ（クライアント戻しで慌てるな）
4.1 共通パターンと対処
| クライアント戻しパターン | よくある原因 | 対処 |
|---|---|---|
| 「この数字、前と違うよ」 | 口径が変わった（例：投資額が含税→税抜きに） | 修正履歴を確認し、口径変更があったら全表を再計算し、変更箇所をまとめてクライアントに通知 |
| 「この部分は古い計画を参照してる」 | 参照文書のバージョンが古い | クライアントから最新版をもらい、該当箇所をすべてもう一度調査・書き直し |
| 「この結論は強引だ」 | データの裏付けが不十分 | データを補強するか、論理の飛躍を修正 |
| 「この章はいらない」 | 章のアウトラインに合わない | 該当章を削除し、後続の章の引用を更新 |
| 「この章を追加してほしい」 | クライアントが新しい観点を要求 | 新章を作成し、クロスリファレンスと目次を更新 |
4.2 口径変更の処理手順
- 何が変わったかを明確にする：単一数値の変更か、口径全体の変更か（例：投資額が固定資産投資のみ→総投資に）
- 影響範囲を特定する：口径が変わった場合、その数値が関わるすべての記述場所とテーブルを洗い出す（
grepで検索、テーブルも含む） - データの整合性を確認する：変更後、財務テンプレートの数値がすべて連動して更新されているか確認
- 口径をクライアントに通知する：変更点を文書にして、誤解を防ぐ |
4.3 バージョン管理の提案
- 各修正版のファイル名に日付とバージョン番号を含める（例：プロジェクト名_FS報告書_v1.0.docx、プロジェクト名_FS報告書_v1.1.docx）
- 各版の変更履歴を別ファイルで管理する（
変更履歴.md） - 重要な修正は、修正前の DOI をバックアップとして保持する
五、付加価値サービスと追加料金のオプション
5.1 有料オプションリスト
| オプション | 内容 | 推奨価格帯 |
|---|---|---|
| 追加章（例：リスク分析詳細版） | 10ページ以上の専門的な分析章 | 3000-5000元/章 |
| 複数シナリオシミュレーション | 楽観的/悲観的/基準の3シナリオの財務比較 | 2000-4000元 |
| 投資家向けエグゼクティブサマリー | 3-5ページのエグゼクティブサマリー | 2000-4000元 |
| 英語版翻訳 | 報告書本体の英語翻訳 | 5000-10000元 |
| PPT版変換 | 同じ内容のプレゼンテーション資料 | 3000-6000元 |
| データルームの構築 | 投資家向けの整理されたデータルーム | 5000-15000元 |
5.2 追加料金の設定方針
- 基本料金に含まれない作業は明確に「有料オプション」とし、基本納品物とは別に提示
- クライアントが急ぎの場合は「エクスプレス料金」を設定（例：3日以内の納品は 30％ 増）
- 長期メンテナンス契約を結ぶ場合は、単発受注よりも 20-30％ ディスカウント
六、参考資料とテンプレート
references/gov-dagang-2023.md：政府投資プロジェクト FS アウトライン（11章38節）references/ent-dagang-2023.md：企業投資プロジェクト FS アウトライン（10章37節）references/data-request-list.md：クライアントへの資料要求リストテンプレートtemplates/report-plan.md：章ごとの執筆計画テンプレートtemplates/review-checklist.md：品質レビューチェックリストscripts/pipeline_check.py：パイプライン自己診断スクリプトscripts/report_qa.py：報告書 QA スクリプト（キャッシュ/アサーション/正規表現）scripts/gen_report_docx.py：報告書 docx 生成スクリプトscripts/face_docx.py：表紙など追加スクリプトscripts/docx_polish.py：組版クレンジングスクリプトscripts/gen_model_xlsx_v2.py：財務テンプレート生成スクリプト（v2）scripts/gen_shuoming.py：作成説明書生成スクリプトscripts/vision_check.py：ビジュアル検収スクリプト
七、注意事項と免責事項
- 本スキルは FS 報告書の作成を支援するためのものであり、金融・法律・税務等の専門家のアドバイスに代わるものではありません。
- 納品物の内容に関するすべての責任は、クライアント自身のレビューと承認の後、クライアントに帰属します。
- 本スキルの使用により生じたいかなる損害についても、作成者は責任を負いません。
- 本スキルは AI モデルの支援を受けて作成されていますが、最終的な内容の正確性とコンプライアンスについては、ユーザー自身が確認することをお勧めします。
本ドキュメントは v1.7.0 に対応しています。最新情報は GitHub リポジトリ を参照してください。