社内稟議書の自動ドラフト生成：Dify による構造化出力とプロンプト設計の実践

はじめに

日本企業において、稟議書は意思決定プロセスの中核をなす文書である。新規ツールの導入、予算の申請、外部ベンダーとの契約締結――あらゆる重要な意思決定は稟議書を通じて承認を得る必要がある。しかし、稟議書の作成には相当な時間がかかる。背景の整理、費用対効果の算出、リスクの洗い出し、関連部署との調整事項の記載など、1 件の稟議書に数時間から丸一日を費やすことも珍しくない。

本稿では、Dify を活用して稟議書のドラフトを構造化された形式で自動生成し、人間による確認・修正を経て承認フローに乗せるシステムの設計を解説する。ポイントは「うまい文章を書くこと」ではなく、組織の承認フォーマットに沿った、欠落のない構造化出力を安定して生成することにある。

背景と課題

稟議書作成の現実的な課題

なぜ「自動生成」ではなく「自動ドラフト」なのか

稟議書は組織内の公式な意思決定文書であり、最終的な責任は申請者と承認者にある。AI が生成した内容をそのまま提出することは、以下の理由で適切でない。

• 数値の正確性: 予算額・ROI・投資回収期間は AI が推測してはならない
• 組織固有の文脈: 過去の経緯や社内政治的な配慮は AI には判断できない
• 責任の所在: 稟議書の内容に対する責任は申請者が負う

したがって、AI の役割は「構造を整え、草稿を生成し、不足項目を明示する」ことに限定し、最終化は人間が行う設計とする。

全体アーキテクチャ

flowchart TD
    A[申請者: 要件を入力] --> B[入力情報の構造化ノード]
    B --> C[稟議タイプ判定]
    C --> D[テンプレート選択]
    D --> E[LLM ドラフト生成]
    E --> F[不足項目チェック]
    F --> G{不足項目あり?}
    G -->|Yes| H[不足項目リスト提示<br>+ 暫定ドラフト出力]
    G -->|No| I[完全ドラフト出力]
    H --> J[Human-in-the-Loop:<br>申請者が確認・補完]
    I --> J
    J --> K[最終稟議書出力]
    K --> L[承認ワークフロー連携<br>API / メール / Slack]

稟議書の構造化フォーマット設計

標準フィールド定義

稟議書のドラフト生成において最も重要なのは、出力フォーマットの安定性である。自然文の長文ではなく、固定フィールドの構造化出力を基本とする。

{
  "ringi_title": "Dify Enterprise 版 導入に関する稟議",
  "applicant": {
    "name": "",
    "department": "",
    "position": "",
    "date": "2026-04-12"
  },
  "background": {
    "current_situation": "現状の課題を記述",
    "trigger": "稟議提出のきっかけ"
  },
  "purpose": "本稟議の目的を1-2文で記述",
  "proposal": {
    "overview": "提案の概要",
    "scope": "適用範囲・対象部門",
    "timeline": "想定スケジュール"
  },
  "cost": {
    "initial_cost": "初期費用（税込）",
    "running_cost": "月額/年額ランニングコスト",
    "total_budget": "稟議申請金額",
    "budget_source": "予算科目",
    "payment_terms": "支払条件"
  },
  "expected_benefits": {
    "quantitative": "定量的な効果（工数削減○時間/月 等）",
    "qualitative": "定性的な効果"
  },
  "roi": {
    "payback_period": "投資回収期間",
    "calculation_basis": "算出根拠"
  },
  "risks": [
    {
      "risk": "リスク項目",
      "probability": "高/中/低",
      "impact": "高/中/低",
      "mitigation": "対策"
    }
  ],
  "alternatives": [
    {
      "option": "代替案",
      "pros": "メリット",
      "cons": "デメリット",
      "reason_not_selected": "不採用理由"
    }
  ],
  "approval_items": "承認を求める事項を明確に記述",
  "attachments": ["見積書", "製品資料", "PoC報告書"],
  "compliance_check": {
    "personal_data": "個人情報の取扱い有無",
    "security_review": "セキュリティ審査の要否",
    "legal_review": "法務確認の要否"
  },
  "missing_fields": ["未入力または情報不足のフィールド一覧"]
}

稟議タイプ別のフィールド調整

プロンプト設計：バージョン別の比較

Version 1: 自由生成型

System Prompt:
あなたは社内稟議書の作成をサポートするアシスタントです。
ユーザーの入力に基づいて稟議書のドラフトを作成してください。

結果の傾向:

• 文章としては読みやすいが、フィールドが不安定
• 必須項目（予算・リスク等）が抜け落ちやすい
• 承認システムやフォームに直接取り込めない形式になりがち

Version 2: テンプレート拘束型

System Prompt:
あなたは社内稟議書の作成支援アシスタントです。
以下のフィールドに従って、構造化された稟議書ドラフトを JSON 形式で出力してください。

必須フィールド:
- ringi_title: 稟議件名
- background: 背景・現状の課題
- purpose: 目的
- proposal: 提案概要
- cost: コスト（初期費用、ランニングコスト、合計）
- expected_benefits: 期待効果（定量・定性）
- risks: リスクと対策
- approval_items: 承認を求める事項

すべてのフィールドを必ず出力してください。
情報が不足している場合は、そのフィールドに "【要入力】" と記載してください。

結果の傾向:

• フィールドの網羅性が大幅に向上
• ただし「【要入力】」が多すぎると、ドラフトの実用性が低下
• 入力情報が少ないと、推測で埋めてしまうケースがある

Version 3: 構造化 + 不足検出 + 安全制約型（推奨）

System Prompt:
あなたは社内稟議書の整理・構造化アシスタントです。
以下のルールに厳密に従ってください。

【役割の定義】
- あなたは稟議書の「整理者」であり、「意思決定者」ではありません
- 入力情報に基づいてドラフトを構造化する役割のみを担います

【出力ルール】
1. 指定された JSON フォーマットで出力すること
2. 入力情報に含まれない数値（予算額、ROI、期間等）は絶対に推測・捏造しないこと
3. 情報が不足しているフィールドは "【要確認】" と明記すること
4. missing_fields に不足項目を一覧として出力すること
5. 金額には必ず税込/税抜を明記すること
6. 根拠のない効果の誇張は行わないこと

【フォーマット】
{上記の JSON フォーマットを挿入}

【重要な禁止事項】
- 予算額の推測禁止
- ROI の捏造禁止
- 投資回収期間の推測禁止
- 存在しない比較データの生成禁止

結果の傾向:

• フィールドの網羅性と正確性のバランスが最も良い
• 不足項目が明示されるため、申請者が何を補完すべきか明確
• 捏造リスクが大幅に低減

入力情報の設計

なぜ自由テキスト入力だけでは不十分か

「Dify を導入したい。稟議書を作って」という自由テキスト入力だけでは、ドラフトの品質は低くなる。最低限の構造化された入力を求めることで、出力品質は飛躍的に向上する。

推奨する入力フォーム

Dify Workflow の開始ノードで以下の入力変数を定義する。

添付ファイルからの情報抽出

見積書や提案書が添付された場合、Dify の VLM / パラメータ抽出ノードを使って、金額・ベンダー名・契約条件などを自動抽出し、稟議書ドラフトに反映する。

flowchart LR
    A[見積書PDF] --> B[VLM / テキスト抽出]
    B --> C[パラメータ抽出ノード]
    C --> D["金額: ¥3,600,000<br>ベンダー: ○○株式会社<br>期間: 12ヶ月"]
    D --> E[稟議書ドラフトに反映]

Human-in-the-Loop の設計

人間による確認が必要なケース

確認フローの設計

Dify Human-in-the-Loop ノードの表示例:

━━━━━━━━━━━━━━━━━━━━━━
稟議書ドラフト: 確認をお願いします
━━━━━━━━━━━━━━━━━━━━━━

■ 件名: Dify Enterprise 版 導入に関する稟議

■ 不足項目:
  ⚠ 初期費用が未入力です
  ⚠ 投資回収期間の算出根拠がありません
  ⚠ セキュリティ審査の要否が未回答です

■ ドラフト内容:
  [JSON / Markdown 形式のドラフトを表示]

■ アクション:
  [承認して次へ] [修正して再生成]
━━━━━━━━━━━━━━━━━━━━━━

下流システムとの連携

承認ワークフローへの接続

稟議書ドラフトが確定したら、Dify Workflow の HTTP Request ノード を使って社内の承認システムに連携する。

API 呼び出し例（kintone 連携）

curl -X POST 'https://{subdomain}.cybozu.com/k/v1/record.json' \
  -H 'X-Cybozu-API-Token: {api_token}' \
  -H 'Content-Type: application/json' \
  -d '{
    "app": 123,
    "record": {
      "稟議件名": {"value": "Dify Enterprise 版 導入"},
      "申請部門": {"value": "情報システム部"},
      "申請金額": {"value": "3600000"},
      "ステータス": {"value": "ドラフト確認済み"}
    }
  }'

実装上のベストプラクティス

やるべきこと

1. 出力フォーマットを先に確定する — プロンプトより先に、どの JSON フィールドが必要かを定義する
2. 不足項目を明示的に出力させる — missing_fields を必須フィールドとして定義する
3. 稟議タイプ別にプロンプトを切り替える — SaaS 導入と人員採用では必要項目が異なる
4. 金額フィールドには安全制約を設ける — 推測禁止を明示的にプロンプトに記載する
5. Human-in-the-Loop を必ず組み込む — 完全自動提出は許容しない

やってはいけないこと

1. 「稟議書を書いて」だけの自由テキスト入力で運用する — 入力の構造化が出力品質を決める
2. AI に予算額や ROI を推測させる — 承認者の信頼を損ない、制度全体の信用が崩壊する
3. すべての稟議タイプに同一テンプレートを適用する — タイプ別の最適化が必要
4. 自然文の長文で出力する — 下流システムに接続できない

導入ステップ

まとめ

社内稟議書の自動ドラフト生成において最も重要なのは、「うまい文章を書くこと」ではなく、組織の承認フォーマットに沿った構造化出力を安定して生成し、不足している情報を明示することである。

Dify の Workflow を活用すれば、入力の構造化 → タイプ判定 → テンプレート選択 → ドラフト生成 → 不足検出 → 人間確認 → システム連携という一連のフローを、ノーコードで構築できる。特に Version 3（構造化 + 不足検出 + 安全制約型）のプロンプト設計を採用することで、AI が数値を捏造するリスクを抑えつつ、申請者の作成工数を大幅に削減することが可能である。

稟議書は日本企業における意思決定の「インターフェース」であり、その品質は組織の意思決定速度に直結する。AI による構造化ドラフト生成は、このインターフェースの標準化と高速化を実現する有効なアプローチである。