ストーリー

文書タイプ別テンプレート

1. 技術仕様書テンプレート

あなたはNetShop社のテクニカルライターです。
以下の要件から技術仕様書を作成してください。

入力情報:
- 機能名: {{feature_name}}
- 概要: {{overview}}
- 技術スタック: {{tech_stack}}
- 関連API: {{related_apis}}

出力構成:
1. 概要
   - 目的（なぜこの機能が必要か）
   - スコープ（何を含み、何を含まないか）
   - 用語定義

2. システム構成
   - アーキテクチャ図の説明
   - コンポーネント一覧と責務

3. API仕様
   - エンドポイント一覧
   - リクエスト/レスポンス形式（JSON例付き）
   - エラーコード一覧

4. データモデル
   - テーブル定義
   - ER図の説明
   - インデックス設計

5. 非機能要件
   - パフォーマンス目標
   - セキュリティ要件
   - 可用性要件

6. テスト計画
   - テスト観点
   - テストケース概要

ルール:
- です・ます調
- 技術用語は初出時に英語を併記
- 推測は「（要確認）」と注記
- 各セクションは実装に必要十分な詳細度

2. 議事録テンプレート

以下の会議の文字起こしから議事録を作成してください。

会議情報:
- 会議名: {{meeting_name}}
- 日時: {{datetime}}
- 参加者: {{participants}}
- アジェンダ: {{agenda}}

文字起こし:
{{transcript}}

出力形式:

# 議事録: {{meeting_name}}

## 基本情報
| 項目 | 内容 |
|------|------|
| 日時 | |
| 参加者 | |
| 記録 | AI自動生成 |

## 議論内容
（アジェンダ項目ごとに整理）

### 議題1: [タイトル]
**発言要旨:**
- [発言者]: [要旨]（2文以内）

**議論のポイント:**
- [論点と合意/未合意の状態]

## 決定事項
| # | 決定内容 | 決定者 |
|---|---------|--------|

## アクションアイテム
| # | タスク | 担当 | 期限 |
|---|--------|------|------|

## 次回予定
- 日時:
- 議題:

ルール:
- 発言は要旨のみ記載（逐語記録しない）
- 決定事項は「〜に決定」「〜で合意」のパターンで判定
- アクションアイテムは「〜してください」「〜を担当」のパターンで判定
- 担当者や期限が不明な場合は「未定」と記載
- 雑談や本題から逸れた発言は省略

3. 提案書テンプレート

以下の情報から技術提案書を作成してください。

提案情報:
- タイトル: {{title}}
- 課題: {{problem}}
- 提案内容: {{solution}}
- 予算: {{budget}}
- スケジュール: {{schedule}}

出力構成:

# 技術提案書: {{title}}

## 1. エグゼクティブサマリー
（経営層向け。3行以内で提案の要点を記述）

## 2. 現状の課題
- ビジネスインパクト（定量的に）
- 技術的な原因

## 3. 提案するソリューション
- アプローチの概要
- 技術選定の根拠
- 代替案との比較

| 観点 | 提案案 | 代替案A | 代替案B |
|------|--------|---------|---------|

## 4. 実装計画
- フェーズ分け
- マイルストーン
- 必要リソース

## 5. コスト・ROI
- 初期コスト
- ランニングコスト
- 期待されるROI

## 6. リスクと対策
| リスク | 影響度 | 発生確率 | 対策 |
|--------|--------|---------|------|

## 7. 次のステップ

ルール:
- 数値は具体的に（「大幅に改善」→「レスポンスタイムを3秒→0.5秒に改善」）
- 技術的な判断には根拠を示す
- リスクは正直に記載（隠さない）
- 1ページ目（サマリー）だけで意思決定できる情報量

文書品質を高めるテクニック

一貫性の確保

文書全体で一貫して使用する表現:
- 「ユーザー」（「利用者」「お客様」と混在させない）
- 「実装する」（「開発する」「作成する」と混在させない）
- 時制は現在形を基本（設計書の場合）

用語集:
| 用語 | 定義 |
|------|------|
| ユーザー | NetShop社のECサイト利用者 |
| 管理者 | NetShop社の内部運用スタッフ |
| 商品 | ECサイトで販売される物品 |

ハルシネーション防止

事実確認ルール:
- 具体的な数値は入力データからのみ引用
- 推測が必要な箇所は「（推定値。要確認）」と注記
- URLやバージョン番号は入力に含まれるもののみ使用
- 「一般的に〜と言われている」は使用禁止（根拠を示す）

読みやすさの確保

文書スタイルルール:
- 1文は60文字以内
- 1段落は3-5文
- 箇条書きは1項目2文以内
- 表は5列以内
- 見出しレベルは3階層まで

文書生成パイプライン

入力データ
  ↓
[Step 1: 構造化] 入力データをセクション別に整理
  ↓
[Step 2: 生成] 各セクションの文書を生成
  ↓
[Step 3: 品質チェック] 一貫性・正確性・完全性を検証
  ↓
[Step 4: 人間レビュー] 専門家による最終確認
  ↓
完成文書

Step 3の品質チェックもLLMで自動化できる。

以下の文書を品質チェックしてください。

チェック項目:
□ 全てのセクションが埋まっているか
□ 用語が一貫しているか
□ 推測で書かれた箇所に注記があるか
□ 数値に根拠が示されているか
□ 文書の構成は論理的か

問題が見つかった場合、該当箇所と修正案を示してください。

まとめ

チェックリスト

• 技術仕様書テンプレートの構成要素を理解した
• 議事録の自動生成ルール（決定事項・AIの判定基準）を把握した
• ハルシネーション防止のルールを設計できる
• 文書生成パイプラインの各ステップを理解した

次のステップへ

次は「データ分析プロンプト」として、データの解釈やレポート生成のテンプレートを学ぼう。

推定読了時間: 30分