🦐

【第4回 金融データ活用チャレンジ】生成AIも“前処理8割”：PDF→Markdown変換から提案書作成までの挑戦記録

に公開
signate
Dataiku
生成 AI
Claude
fdua
tech

1. はじめに

第4回金融データ活用チャレンジ（コンペ）に参加しました。

本コンペでは、仮想の建設・工事関連企業10社分の有価証券報告書や財務データ等をもとに、「生成AIをバディ（相棒）として活用し、データに基づいた価値ある提案書を作成する」ことに取り組みます。

本記事では、コンペでの私の生成AI活用における工夫について、主にプロセスやプロンプトの観点から説明します。

https://prtimes.jp/main/html/rd/p/000000035.000103937.html

2. プロセスの全体感

プロセスの工夫は以下の通りです。

  • 前処理（工夫①②）: AIにとって読みやすくて処理しやすいように、データを整える
  • 提案書作成（工夫③④）: AIが文脈（コンテキスト）を保持しやすいように、1つのプロンプトに提案書作成～評価のプロセスを織り込む
  • 全体（工夫⑤）: AIとデータ授受しやすいように入出力を基本的にMarkdownに統一したうえで、各プロセスで人が検証（必要に応じて修正）

前処理でAIと徹底的にやり取りしてデータを整え、プロンプトを磨くことで、効率と質の両立を目指しました。

全体を通じて、生成AIは「Claude Opus 4.6」を活用しました。
また、財務データの前処理（工夫②）において、「Dataiku」を活用しました。

以下、各プロセスにおけるプロンプトの工夫について、説明していきます。
長めの記事になっていますので、目次で関心のある箇所からお読みいただければと思います。

3. 工夫①: 📑【前処理】有価証券報告書PDFをAIが読みやすいMarkdownに変換

有価証券報告書のPDFをMarkdown（一部 HTML）に変換する前処理です。
PDFには、結合セルを含む複雑な表、ページをまたいで分断されている表、透かし文字等も含まれており、AIの読み取り精度を下げる要因になります。

3-1. 📐 見出しレベルの統一

まず、PDFの見出しレベル（「第一部」「第1」等）から、Markdownの見出しレベル（# ## 等）へ変換するルールを、事前に定義しました。AIが変換時に見出しレベルを「勝手に判断」する余地を最小化するためです。

プロンプト抜粋
| PDFの見出し形式 | Markdown |
| --- | --- |
| 第一部 | # |
| 第1   | ## |
| 1     | ### |
| (1)   | #### |
| ①     | ##### |
| ア.   | ###### |

3-2. 🔢 通し番号・箇条書き・段落・記号の統一

見出し以外のテキスト（通し番号・箇条書き・段落・記号）についても、変換ルールを事前に定義しました。

プロンプト抜粋
- PDFに、通し番号と考えられる部分がある場合は、番号なしリストとして出力し、文頭に原文の通し番号を残す
- PDFに、箇条書きと考えられる部分がある場合は、番号なしリストとして出力する
- PDFで段落が分かれている箇所は、空行で区切る
- PDFでマイナス記号 △ が使われている場合は - として出力する

3-3. 🧩 複雑な表へのHTMLによる対応

Markdown記法では結合セルを表現できません。そこで、表はHTMLの表形式（ <table> タグ）に変換し、rowspan / colspan で結合セルを表現しました。

プロンプト抜粋
- 表 の場合: HTMLの表形式 に変換する
  - 表内の 結合セルは結合したまま、HTMLの rowspan / colspan で表現する
  - 表内のテキストは適切なHTMLタグを使用する（改行が必要な場合は <br> を使用）
- テキスト の場合: markdown記法 に変換する

変換前後のイメージ:

3-4. 🔖 ページをまたいだ表の復元

ページをまたいで分断されている表は、同一タイトル、かつ、列構成が同一の表が連続している場合、1つの表として統合するルールを設けました。

プロンプト抜粋
- PDFは、表・テキストがページをまたいで分断され、ページ冒頭で同一表のヘッダーが繰り返される構造であるため、以下を厳密に行うこと
    - 同一タイトルかつ列構成が同一の表が連続している場合、それらは1つの表として統合する
    - ページ冒頭に繰り返される表ヘッダー行は、2回目以降は削除する
    - 分断された表は、行を正しく接続し、完全な1表として復元する（読み順よりも、表の連続性を優先する）

変換前後のイメージ:

3-5. 🧹 透かし文字の除去

透かし文字が含まれていたため、透かし文字はすべて無視し、抽出・転記・再現を一切しないというルールを設けました。

プロンプト抜粋
- PDFには「空白・サンプルデータ」等の透かしが含まれるため、以下を厳守すること
    - 透かし文字はすべて無視し、抽出・転記・再現を一切しない
    - 透かし文字を本文（表・テキスト）の一部と誤認しない
    - 黒文字で記載されている実際の本文（表・テキスト）のみを対象とする

変換前後のイメージ:

3-6. ✂️ ページ範囲を分割した変換

有価証券報告書は数十ページに及びます。
全ページを一度に変換すると構造が崩れるリスクがあるため、ページ範囲を分割して変換しました（例: 1〜21ページ、22〜40ページ、41〜55ページの3分割）。
分割箇所は、あらかじめ人が有価証券報告書を確認し、見出しがある部分など、区切りの良いページで分割するよう、プロンプトに記載しました。

プロンプト抜粋
# 命令
- 以下の対象ページについて、同一の処理を実行してください。

## 対象ページ
- 22～40ページ（PDFのページ番号）

3-7. 🔄 セルフチェックの組み込み

変換精度を高めるため、プロンプトにセルフチェックを組み込みました。

プロンプト抜粋
## 手順
1. PDFのページ左上から右下の順に、要素 [表, テキスト] に応じて変換を行う
   (略)
2. PDFとの整合性をセルフチェックし、手順1に誤りがあれば修正する
3. 変換結果のみ を 1つのコードブロック に正確に出力する

3-8. 🖥️ 変換結果の確認

変換後のMarkdownファイルは、前述の図のように、コードエディタ（Cursorを使用）でレンダリング（人が見られる形式に変換）し、人の目で変換ミスがないか確認（必要に応じて修正）しました。

（参考）工夫① PDF→Markdown変換のプロンプト全文

プロンプト全文
# 命令
- アップロードしたPDF「securities_report_12044.pdf」（要素 [表, テキスト] が混在）について、下記 [対象ページ, 手順, 留意点] を全て遵守し、**本文（黒文字で記載されている表・テキスト）については1文字も過不足なく**、PDFの**読み順（左上から右下）・段落構造・表構造**を正確に再現するように、**markdown**（表は **HTMLの表形式**）に変換し、**コードブロック（markdown）のみに出力**してください

## 対象ページ
- 1～21ページ（PDFのページ番号）
	
## 手順
1. PDFのページ左上から右下の順に、要素 [表, テキスト] に応じて以下の変換を行う
    - **表** の場合: **HTMLの表形式** に変換する
        - 表内の **結合セルは結合したまま、HTMLの rowspan / colspan で表現**する  
        - 表内のテキストは適切なHTMLタグを使用する（改行が必要な場合は `<br>` を使用）
    - **テキスト** の場合: **markdown記法** に変換する
        - PDFの見出し構造に応じて、以下の形式対応で見出しレベルを固定する（# の数を勝手に変えないこと）
            | PDFの見出し形式 | markdown |
            |---|---|
            | 第一部 | # |
            | 第1 | ## |
            | 1 | ### |
            | (1) | #### |
            | ① | ##### |
            | ア. | ###### |
        - PDFに、上記以外の通し番号と考えられる部分がある場合は、**番号なしリストとして出力し、文頭に原文の通し番号を残す**
        - PDFに、箇条書きと考えられる部分がある場合は、番号なしリストとして出力する
        - PDFで段落が分かれている箇所は、空行で区切る
        - PDFでマイナス記号 `△` が使われている場合は`-` として出力する
2. PDFとの整合性をセルフチェックし、手順1に誤りがあれば修正する
3. **変換結果のみ** を **1つのコードブロック** に正確に出力する（前後に説明文などを付けない）

## 留意点
- markdownは CommonMark、HTMLは Living Standard の仕様に準拠すること
- PDFは、表・テキストがページをまたいで分断され、ページ冒頭で同一表のヘッダーが繰り返される構造であるため、以下を厳密に行うこと
    - **同一タイトルかつ列構成が同一の表**が連続している場合、それらは1つの表として統合する
    - ページ冒頭に繰り返される表ヘッダー行は、2回目以降は削除する
    - 分断された表は、行を正しく接続し、完全な1表として復元する（読み順よりも、表の連続性を優先する）    
- PDFには「空白・サンプルデータ」等の透かしが含まれるため、以下を厳守すること
    - 透かし文字はすべて無視し、抽出・転記・再現を一切しない
    - 透かし文字を本文（表・テキスト）の一部と誤認しない
    - 黒文字で記載されている実際の本文（表・テキスト）のみを対象とする
- 括弧の種類 `(`, `（`, `[`, `〔`, `)`, `）`, `]`, `〕` などは、PDFに記載されている種類を正確に保持すること
- 脚注がある場合は、原文の直後など意味的に対応が明確な位置に出力すること（表内の `（注）1` などの記載は、省略せず、そのまま記載すること）

4. 工夫②: 📊【前処理】財務データに関する追加特徴量をDataikuで効率的に作成

財務データCSVを基に特徴量（財務指標）を追加する前処理です。
当該前処理を行わず、提案書作成時に生成AIに追加特徴量（財務指標）の計算させると、ハルシネーションが起きるリスクがあります。

4-1. 🔙 評価観点から逆算した財務指標追加

はじめに、「よく使う財務指標を片っ端から追加する」のではなく、コンペの評価観点から逆算して、必要な指標を選定しました。

コンペの評価観点は5つ（「過去分析と未来提案の接続」「地域特性の考慮」「販路・商流の理解」「近未来への対応（GX/DX）」「需要減退・人材不足対応」）あり、それぞれを満たす分析に必要な指標は何か、という問いから出発しました。
この問いに対し、AIを活用して、一般的な財務指標に加え、建設業特有の指標も含め、選定しました。

プロンプト抜粋
- 前述の提案書を作成（企業の現状を分析し、経営課題を抽出し、課題に対する打ち手を検討し、将来の成長につながる戦略を、提案書として文書化）するために、上記の **{評価観点} との繋がりを意識**して、 **財務データ（financial_data.csv）をもとに追加すべき特徴量を検討**してください
選定した指標の概要
| カテゴリ | 主な指標 |
|---|---|
| 収益性 | 売上総利益率、営業利益率 等 |
| 安全性 | 自己資本比率、流動比率 等 |
| 効率性 | 総資産回転率、1人当たり売上高 等 |
| キャッシュ・フロー | FCF、営業CFマージン 等 |
| 建設業特有指標 | 完成工事総利益率、完成工事高比率 等 |
| DX/GX関連 | 研究開発費比率、減価償却費比率 等 |

4-2. 📋 Dataikuとの連携を効率的に行うタスクリスト設計

選定した特徴量の追加にはDataikuを活用します。

Dataikuの、ノーコードでも効率的に設計できることや、計算過程や結果を人が確認しやすいこと等を重視し、Dataikuを前処理工程で戦略的に活用しました。

まず、選定した指標の情報を、効率的にDataikuに連携するための事前準備として、AIを活用（以下プロンプト抜粋）し、タスクリスト（追加する特徴量の一覧）を作成するようにしました。

プロンプト抜粋
- 当該特徴量は、DataikuのPrepare Recipeを活用して追加するので、そのために必要な情報を、下記 {タスクリストフォーマット}（markdown）で出力してください

## タスクリスト出力例
| 項番 | 財務諸表カテゴリ | Dataiku機能 | タスク | 具体的内容 | 優先度 | 理由 | ステータス |
|---|---|---|---|---|---|---|---|
| 1 | 収益性 | Prepare Recipe | 営業利益率（％） | Create a new column '営業利益率（％）' 
  calculated as: (営業利益 / 売上高) * 100 
  when 売上高 is not null and 売上高 is greater than 0, otherwise null | 🔴最重要 | 評価基準「XXX」に直結する | |

このタスクリストの設計には、以下の意図を込めています。

  • 👉 Dataikuとの連携: Dataikuに連携する数式を、具体的内容列に記載させることで、後続のDataikuでの追加特徴量作成を、効率的に行うことができます
  • 📎 評価観点との紐づけを明示: なぜこの指標を選定するのかの根拠を理由列に明示しています
  • ✓ ステータス列は空欄: Dataikuでの追加特徴量作成の進捗状況を人が管理する際にステータス列を使います

作成されたタスクリストは、「Notion」を活用して蓄積・管理しました。
NotionはWYSIWYG（What You See Is What You Get: 見たままが得られる）エディタのため、Markdownのタスクリストがそのまま視覚的なテーブルとして表示され、進捗状況の管理が直感的に行えます。

AIを活用し作成したタスクリストのイメージ（AI出力をNotionに貼り付け）:

4-3. 🚀 追加特徴量をDataikuで効率的に作成

作成したタスクリストを元に、Dataikuで特徴量を実際に追加していきます。

ここでは、Dataikuの「Generate Recipe」機能を活用することで、効率的に特徴量を作成しました。

Generate Recipe機能の活用ポイント:

  • 自然言語でのプロンプト入力: タスクリストの具体的内容列に記載された計算式を、そのまま自然言語のプロンプトとしてDataikuに入力できます
  • Dataiku用の式・出力列を自動生成: プロンプトから、Dataikuの構文に準拠した計算式と出力列が自動的に生成されます
  • 一括処理可能: 複数の追加特徴量の計算式をコピー&ペーストすることで、ある程度の件数をまとめて処理することができます

この仕組みにより、35個の特徴量作成にかかる時間を大幅に削減できました。

  • Dataikuでの作成時間: 約1分 / 35特徴量
  • 人手での作成時間（想定）: 約105分 / 35特徴量（※ 3分 / 1特徴量と仮定）
  • ⏱️ 特徴量作成の時間を約99%削減（105分→1分）

Dataiku「Generate Recipe」機能の活用イメージ:

4-4. ✅ 追加特徴量の作成結果の生成AIによる検証

Dataikuで特徴量を追加した後は、正しく作成されているか生成AIを使って検証しました。
具体的には、特徴量を含むCSVファイルを生成AIに入力し、タスクリストの計算式と突合し、その結果を人が確認しました。（想定通りの結果とならない場合はDataikuで再作成）

プロンプト抜粋
# 命令
- 添付「financial_data_dataiku_all.csv」の通り、dataikuで特徴量を追加しました。
- タスクリスト通り計算されているか、タスクリストの項目毎に確認し、
  根拠とともに、タスクリストと同様の表形式で出力してください。
AI出力抜粋
## サマリ
- 検証対象: financial_data_dataiku_all.csv
- 検証方法: タスクリストの計算式に基づきPythonで再計算し、Dataikuの出力値と全行比較
  （略）
## 検証結果一覧
| 項番 | 財務諸表カテゴリ | Dataiku機能 | タスク | 検証結果 | 根拠 |
|------|------------------|-------------|--------|----------|------|
| 1 | 安全性（中間計算） | Prepare Recipe | 有利子負債合計 | ✅ OK | `流動負債_短期借入金 + 流動負債_1年内返済予定長期借入金 + 固定負債_長期借入金 + 固定負債_社債` で再計算した値と全行一致を確認 |
  （略）

5. 工夫③: 📝 提案書作成プロンプトはシングルターン × 自己評価ループ

5-1. 1️⃣ シングルターンの狙い

提案書作成プロンプトは、役割設定、評価観点、使用データの優先順位、提案書の構成、引用ルール、作業手順、自己評価基準等を、1つのプロンプトに集約しています。
（本記事では、“シングルターンプロンプト”と呼ぶこととします）

プロンプトを分割すると文脈が途切れるリスクがあります。
特にこのコンペでは「過去3年の財務・事業分析（Past）と、未来への成長戦略（Future）が一貫した因果関係で論理的に接続されているか」が評価のポイントとされており、この「一貫した因果関係」はAIが全体を通して把握している状態でないと実現しにくいと考え、シングルターンプロンプトを採用しました。

5-2. 🗂️ 使用データの優先順位の明示

提案書で使用するデータについて、優先順位を明示することで、生成AIがデータを参照する際の再現性を確保するようにしました。

プロンプト抜粋
# 使用データと優先順位

## 優先1: 有価証券報告書
- securities_report_12044.md（第25期：2024年4月1日～2025年3月31日）

## 優先2: 財務データ（CSV）
- financial_data_dataiku_12044.csv
- 必須: 後掲 {## 引用ルール ### 1. 財務データ} に記載の通り、引用を行うこと

## 優先3: 外部データ（JPX公式サイト）
## 優先4: その他外部データ（信頼性の高い情報源のみ）

このプロンプト入力しているMarkdown（.md）とCSVは、前述の工夫①②で前処理した成果物です。
前処理によって生成AIが読みやすい形に整えたデータを、明確な優先順位とともに生成AIに渡すことで、提案書作成の質を高めるようにしました。

5-3. 📖 引用ルールの明示

AI出力の説明性と検証可能性を確保するため、引用ルールを細かく定めました。

まず、Dataikuで作成した追加特徴量については、プロンプト内に計算式の一覧を直接記載し、AIがその式を引用する形にしました。

プロンプト抜粋
## 引用ルール
### 1. 財務データ
以下の財務指標を使用する際は、以下の式を引用すること

（略）
有利子負債合計 = 流動負債_短期借入金 + 流動負債_1年内返済予定長期借入金 + 固定負債_長期借入金 + 固定負債_社債
売上総利益率（％） = (売上総利益 / 売上高) * 100
（略）

また、外部データについては、「情報源名、URL（可能な場合）、取得年月」を引用する形にしました。

プロンプト抜粋
## 引用ルール
### 3. 外部データ（その他）
例: 茨城県の建設工事受注高は前年比+XX.X%（出所: 国土交通省「建設工事受注動態統計調査」、https://www.mlit.go.jp/...、2025年3月公表）

5-4. 🔬 定性要件の具体化

生成AIに「地域性を意識して」と伝えても、AI出力の説明性や安定性に欠けます。
そこで、定性的な要件を具体化しました。

プロンプト抜粋
## 必須要件
1. 地域性の徹底: 茨城県の固有名詞（自治体名、大学名、産業団地名等）を最低5箇所以上使用
2. 業界深掘り: 元請/下請、官公庁/民間の構造分析を必須化
3. GX具体策: 低炭素工法、建機電動化等の具体的技術名を明記
4. DX ROI: 投資額と削減効果を試算
5. 人材実効策: 大学名、資格名、ビザ種類等の具体名を明記
6. 銀行ソリューション: ABL、グリーンローン等の商品名を明示

5-5. 🔁 作業手順と自己評価ループ

提案書作成の作業手順について、生成AIにお任せではなく、プロンプトの中に明示するとともに、生成AIによる自己評価ループも組み込みました。
ポイントは以下の通りです。

  • 作業手順をプロンプト内に記述: 「データ収集 → 提案書ドラフト作成 → 自己評価 → 改善 → 最終出力」を一貫した文脈の中で処理させています
  • 自己評価基準にはコンペの評価観点をそのまま採用: 評価観点と同じ基準でAI自身にチェックさせることで、出力前に質を底上げしています
  • 無限ループ防止: 「A評価への改善が難しい場合でも出力を優先する」を明示しています
  • 自己評価結果も提案書と同時に出力: 自己評価結果も提案書と同時に出力させたうえで、当該自己評価結果部分は、人が最終確認するプロセスで削除します
プロンプト抜粋
# 作業手順（自己評価ループ付き）

## フェーズ1: データ収集・分析
1. **データ読み込み**: 有価証券報告書、CSV、外部データを収集
2. **地域性調査**: 茨城県の産業政策、統計データを web_search で取得
3. **業界動向調査**: 建設業界の最新トレンド（GX/DX/人材）を web_search で取得

## フェーズ2: 提案書ドラフト作成
4. **構成に沿った執筆**: 現状分析30% + 提案70%のバランスを厳守
5. **文字数管理**: 各セクションの字数目安を意識し、18,000字前後に収める
6. **品質確認**:
   - 計算式の記載漏れチェック
   - URL/出所の記載漏れチェック
   - 固有名詞（地名、大学名、商品名等）の具体性チェック
   - 定量目標の明示チェック

## フェーズ3: 自己評価と改善（必須）

**重要**: 提案書ドラフト完成後、最終出力前に以下の自己評価を必ず実施すること。

7. **自己評価の実施**: 下記の評価基準5項目に基づき、ドラフトをA/B/Cで自己採点する
8. **B以下の項目がある場合**: 該当箇所を特定し、改善を反映する
9. **改善後の再評価**: 全項目がA評価であることを確認する。ただし、A評価への改善が難しい場合でも、出力することを優先する
10. **文字数の最終確認**: 18,000文字前後に収まっていることを確認する。ただし、18,000文字前後に収まっていない場合でも、出力することを優先する

### 自己評価基準

以下の5つの視点に基づき、A（優れている）、B（標準的）、C（改善が必要）の3段階で自己評価を行うこと。

| 評価視点 | 評価項目 | 評価のポイント（高評価の基準） |
| :--- | :--- | :--- |
| 1. 全体構成 | 過去分析と未来提案の接続 | 過去3年の財務・事業分析（Past）と、未来への成長戦略（Future）が一貫した因果関係で論理的に接続されているか。 |
| 2. 地域性 | 地域特性の考慮 | 企業の所在地（商圏、人口動態、行政施策）を踏まえ、画一的ではない地域密着型の提案ができているか。 |
| 3. 業界特性 | 販路・商流の理解 | 官公庁／民間、元請／下請などの販路特性を把握し、それに応じた具体的な分析・提案となっているか。 |
| 4. 業界課題1 | 近未来への対応 (GX/DX) | 低コスト工法、環境技術（GX）、省力化技術（DX）など、技術トレンドへの投資や対応策を提案できているか。 |
| 5. 業界課題2 | 需要減退・人材不足対応 | 工事需要の変化や深刻な人手不足（2024年問題、外国人材受入等）に対し、実効性のある解決策（歩掛管理の高度化、採用・定着策等）を示せているか。 |

## フェーズ4: 最終出力

11. **最終版提案書の出力**（Markdown形式）
12. **最終自己評価結果の出力**（以下の形式）
```
## 最終自己評価結果

### 総合評価: [A/B/C]
（理由を1〜2文で）

### 項目別評価
- **全体構成**: [A/B/C] — （1文コメント）
- **地域性**: [A/B/C] — （1文コメント）
- **業界特性**: [A/B/C] — （1文コメント）
- **業界課題1 (GX/DX)**: [A/B/C] — （1文コメント）
- **業界課題2 (人材/需要)**: [A/B/C] — （1文コメント）
```

実際のAI出力では、以下のような自己評価結果が得られました。

AI出力抜粋
## 1. エグゼクティブサマリー

茨城あずま建設株式会社（以下「同社」）は、茨城県水戸市に本社を置く東証スタンダード上場の総合建設会社であり、2023年の土浦アーバン開発吸収合併を経て売上高121億円規模に成長した。しかし、第25期（FY2025）は資材価格高騰と労務費上昇により営業利益率が3.0%へ低下、営業CFも▲82百万円と2期連続のマイナスとなり、収益力と資金創出力の回復が喫緊の課題である。
（略）

## 最終自己評価結果
### 総合評価: A
（略）
### 項目別評価
- 全体構成: A --- FY2023→2025の収益性悪化要因分析から、
  受注選別・歩掛改善・GX/DX投資という改善パスを因果関係で接続した。
- 地域性: A --- 茨城県の半導体産業集積（TSMC、JX金属、ルネサス）、
  つくば学園都市、鹿島臨海工業地帯等の固有名詞を10箇所以上使用。
- 業界特性:  A --- （略）
- 業界課題1 (GX/DX): A --- （略）
- 業界課題2 (人材/需要): A --- （略）

5-6. 📄 MarkdownからWordへの効率的な変換

提案書はWordファイルで提出する必要があります。
提案書をMarkdownで作成した後、Wordファイルへの変換も、Markdownの提案書を作成した生成AI（Claude）のチャット内で、以下プロンプトを実行することで、効率的に行いました。

プロンプト抜粋
# 命令
- 出力された提案書を、構造・書式を完全保持したまま、Microsoft Word互換の正式な .docx ファイルとして出力してください
  - 単なる整形済みテキストではなく、Wordのスタイル機能（見出し・箇条書き・段落番号等）を使用して構造化すること
## 変換ルール
- Markdownの意味構造を変更しないこと
- 見出し階層を保持すること（レベル変更禁止）
- Wordの見出しスタイル（見出し1, 見出し2, 見出し3…）を使用すること
- リストのインデント構造を保持すること
- 「-」「*」のリストはWordの箇条書きスタイルに変換すること
- 番号付きリストはWordの自動段落番号機能に変換すること（単なる数字文字列にしない）
- 太字（**）はWordの太字書式に変換すること
- 斜体（*）はWordの斜体書式に変換すること
- 水平線（---）はWordの段落罫線に変換すること
- プレーンテキスト化しないこと
- HTMLへ変換せず、docx構造として出力すること
- OpenXML準拠の正式なdocx形式とすること

変換前後のイメージ:

この作成結果（画面右側の提案書Word）を人が最終的に検証・一部修正のうえで提出しました。

6. 工夫④: ➡️ 1社目用プロンプトを他の9社へ横展開

コンペでは10社分の提案書が必要です。
1社目のプロンプト完成後、当該プロンプトを基に、残り9社はAIを活用して「プロンプト書き換え」をする方式で効率化しました。

具体的には、“1社目”の提案書作成プロンプトと、2社目の有価証券報告書（Markdown）・財務データ（CSV）をAIに入力し、プロンプトを書き換えさせます。（3社目以降も同様）

プロンプト抜粋
# 命令
- 添付のプロンプト（書き換え前）を基に、
  添付のMarkdownファイル（securities_report_71768.md（有価証券報告書））
  およびCSVファイル（financial_data_dataiku_71768.csv（財務データ））に基づいて書き換え、
  コードブロックのみにmarkdownで、プロンプト（書き換え後）を正確に出力してください。

書き換え前（1社目: コード12044）と、AIによる書き換え後（2社目: コード71768）の差分を抜粋します。

プロンプト（書き換え前）抜粋
# 役割
あなたは、地域金融機関の事業支援部門に所属する、建設業界専門のコンサルタントです。
茨城あずま建設株式会社に対する実行支援型の成長戦略提案書を作成してください。

## 優先1: 有価証券報告書
- securities_report_12044.md（第25期：2024年4月1日～2025年3月31日）

### 公的機関
- 茨城県庁: 産業政策、人口統計、公共投資計画
  - 例: いばらき成長戦略、県の建設工事動向
プロンプト（書き換え後）抜粋
# 役割
あなたは、地域金融機関の事業支援部門に所属する、建設・不動産業界専門のコンサルタントです。
株式会社高知ミライ・ホールディングスに対する実行支援型の成長戦略提案書を作成してください。

## 優先1: 有価証券報告書
- securities_report_71768.md（第28期：2024年4月1日～2025年3月31日）

### 公的機関
- 高知県庁: 産業政策、人口統計、公共投資計画
  - 例: 高知県産業振興計画、県の建設工事動向、南海トラフ地震対策

プロンプトの構造はそのまま維持しつつ、企業名・所在地・ファイル名・地域固有の情報が自動的に書き換わります。
人間は差分を確認するだけで済むため、質と効率を両立するよう工夫しました。
3社目以降も同様の手順で横展開しています。

7. 工夫⑤: ⚙️ Markdown活用と多層的検証プロセス

7-1. 🔗 AIとのデータ授受をMarkdownに統一

全体を通じて、AIとのデータ授受やツール間のデータ受け渡しがしやすいように、データは基本的にMarkdownに統一しました。
AIの出力（Markdown）を、用途に応じて以下のツールで管理し、AIへの次の入力に繋げるよう工夫しました。

  • Cursor:
    • PDF変換結果の確認・修正・蓄積（前述3-8）
  • Notion:
    • AI入力・AI出力の管理全般（最終的に、コンペの提出物に定められているプロンプトログに転記）
    • タスクリストの進捗状況管理（前述4-2）

7-2. 🙆 多層的な検証プロセス

また、全体を通じて、人による多層的な検証プロセスを組み込んでおり、主なものは以下の通りです。

プロセス 人による検証
📑有価証券報告書PDF変換 PDF変換結果を、人が検証し、変換ミスがあれば手修正（前述3-8）
📊特徴量追加 特徴量追加結果を、AIに一次検証させたうえで人が検証し、想定通りの結果とならない場合はDataikuで再作成（前述4-4）
📝提案書作成 提案書作成結果を、人が最終的に検証・一部修正のうえで提出（前述5-6）

8. まとめ・感想

本コンペを通じて私が得られた学びを、KPT（Keep / Problem / Try）フレームワークで整理します。

Keep（継続したいこと）

生成AI活用においても“前処理8割”の意識が重要

  • 生成AIとともに、試行錯誤を重ねながらプロンプトを磨き、前処理に注力したことで、提案書作成における効率と質の両立を目指すことができました
  • この“前処理8割”の意識は、今後も持ち続けたいと思います

Problem（課題として感じたこと）

人手によるデータ授受が依然として多い

  • 生成AI活用により、提案書作成自体は効率化できましたが、AIとのデータ授受や、ツール間のデータ受け渡しで、手作業が多く発生しました
  • データをMarkdownに統一することで一定の効率化は図ったものの、プロセス全体の効率化には至っていません

Try（今後学んでいきたいこと）

プロセス全体の効率化のための理解を深める

  • “前処理8割”の意識は維持しつつ、プロセス全体の効率化のため、ノーコード中心のAIエージェントや、自然言語での指示が可能なAIコードエディタといった領域について、理解を深めていきたいと思います

謝辞

最後に、このような貴重な学びの機会を提供いただいた、主催・事務局・協賛企業の皆さまに、心より感謝申し上げます。

9. 更新履歴

  • 2026/02/18: 公開
  • 2026/02/23: 軽微な修正（誤植の修正、見やすさの改善）

Discussion