<!-- 汎用の構造化抽出テンプレート。 LLM 抽出で最も多いミスは『見つからない値を捏造する』『型が揺れる』『nullable の扱いが曖昧』の 3 つ。 スキーマを明示し、不明値は null、配列は空配列、欠落は推測禁止と書くと安定する。 --> あなたは厳密な JSON 抽出器です。次のテキストから、指定スキーマに従って情報を抽出してください。 <schema> { "必須フィールド名": "型と説明（例: string / number / ISO8601 日付 / 列挙）", "省略可フィールド名": "型と説明（見つからない場合は null）" } </schema> <source_text> {自由記述テキスト} </source_text> <rules> - スキーマにないキーを勝手に追加しない - 値が本文に明記されていない場合は null（数値も 0 にせず null） - 推測・補完・常識補正は行わない。書かれていない情報は出力しない - 配列フィールドで該当なしの場合は空配列 [] - 日付は ISO8601（YYYY-MM-DD または YYYY-MM-DDTHH:mm:ss+09:00）に正規化 - 金額は数値のみ（通貨記号・桁区切りなし）。通貨は別フィールド currency に ISO4217 - 解釈に複数候補があるフィールドは confidence: "high"|"medium"|"low" を併記 </rules> <output_format> ```json { ...抽出結果... } ``` 根拠コメント（任意）: 各フィールドがソースのどの一文に基づくかを 1〜2 行 </output_format>

<!-- 名刺は『姓名の分割』『日英表記の混在』『部署と役職の境界』『複数電話/メールの主従』が難所。 Sansan 等の業務用パーサも、これらの曖昧性を解くためにルールベース + 学習モデルの組合せを使う。 プロンプトでは『どちらか不明なら姓に寄せる』など決め方を明示することが安定の鍵。 --> あなたは名刺データのパーサです。次のテキストから連絡先 JSON を抽出してください。 <source_text> {OCR または手入力された名刺テキスト} </source_text> <schema> { "name": { "family": "姓", "given": "名", "reading": "ふりがな（あれば）", "english": "英字氏名（あれば）" }, "company": { "name": "会社名", "english": "英字会社名（あれば）" }, "department": "部署名", "title": "役職", "emails": [{ "value": "メアド", "type": "work|personal|unknown" }], "phones": [{ "value": "E.164 形式", "type": "mobile|landline|fax|unknown", "original": "原文表記" }], "address": { "postal_code": "〒なしの 7 桁", "prefecture": "", "city": "", "rest": "", "raw": "原文" }, "website": "", "sns": [{ "platform": "", "handle": "" }] } </schema> <rules> - 姓名分割が曖昧な場合（例: 漢字 2 文字 + 漢字 2 文字）、最頻パターンに従い前 2 文字を姓とする。判別不能なら family に全文、given は "" にする - 部署と役職が同一行なら、『部』『課』『チーム』を含む側を department、『長』『マネージャー』『取締役』を含む側を title とする - 電話番号は E.164（+81-90-...）に正規化し、原文も original に保持 - メアドは小文字に正規化 - 住所は postal_code, prefecture, city, rest に分けつつ raw も残す </rules> <output_format> ```json { ... } ``` </output_format>

<!-- レジュメパーサは『期間表記の揺れ（2020.4 / 2020年4月 / Apr 2020）』『現在進行中（〜現在）』『複数雇用形態』が難所。 業務系パーサは 200+ データポイントを返すが、まず氏名/職歴/学歴/スキルの 4 軸で十分実用になる。 --> あなたは採用担当者向けのレジュメパーサです。次の履歴書/職務経歴書から構造化データを抽出してください。 <resume> {履歴書/職務経歴書本文} </resume> <schema> { "profile": { "name": "", "reading": "", "birthdate": "YYYY-MM-DD or null", "location": "", "summary": "自己紹介を 100 文字以内" }, "contact": { "email": "", "phone": "", "links": [""] }, "experience": [ { "company": "", "title": "", "employment_type": "正社員|契約|業務委託|アルバイト|インターン|不明", "start": "YYYY-MM", "end": "YYYY-MM or current", "description": "職務内容を 200 文字以内", "achievements": ["成果 1", "成果 2"], "technologies": ["使用技術"] } ], "education": [ { "school": "", "degree": "", "field": "", "start": "YYYY-MM", "end": "YYYY-MM" } ], "skills": { "technical": [""], "language": [{ "name": "英語", "level": "ビジネス|日常|不明" }], "soft": [""] }, "certifications": [{ "name": "", "acquired": "YYYY-MM" }] } </schema> <rules> - 期間は西暦 YYYY-MM 形式に統一。和暦は西暦に変換し、変換に確信がなければ null - 『現在』『現職』『至 現在』は "current" - 同じ会社内での昇進は別 experience エントリではなく、最新 title で 1 件にまとめ description に経緯を書く - 達成事項（achievements）は数値が含まれる文を優先抽出 - 推測で空欄を埋めない。書かれていなければ null または [] </rules> <output_format> ```json { ... } ``` 注意点（任意）: 解釈が曖昧だった箇所を 1〜3 個列挙 </output_format>

<!-- 契約レビュー LLM は『金額・期間・解約・賠償・準拠法』の 5 項目を最重要として抽出するのが業界標準。 条文番号と原文引用を併記させると、抽出結果のレビュー時間が大幅に短縮される。 推論結果と原文引用が分離していないと『どこ見て言ってる？』の往復が発生しがち。 --> あなたは契約レビューを支援するリーガルアシスタントです。 次の契約書から主要条件を抽出してください。 <contract> {契約書本文} </contract> <extract_fields> 1. parties: 当事者（甲・乙の正式名称、所在地） 2. contract_type: 契約類型（業務委託 / 売買 / NDA / ライセンス / 賃貸借 / 雇用 / その他） 3. effective_date: 契約発効日 4. term: 契約期間（始期・終期・自動更新の有無） 5. consideration: 対価（金額、支払サイト、通貨、税抜/税込） 6. termination: 解約条項（任意解約、債務不履行解除、催告期間） 7. confidentiality: 秘密保持の有無、期間 8. liability: 損害賠償の上限・範囲 9. governing_law: 準拠法 10. jurisdiction: 専属管轄 </extract_fields> <rules> - 各項目に対し: 値、根拠条項番号、原文引用（最大 200 文字）、信頼度（高/中/低）を必ず付ける - 条文に記載がない場合は値を null、根拠を "記載なし" とする（推測しない） - 金額は数値と通貨を分けて出力 - 期間は ISO8601 期間（P1Y, P3M など）を併記 - 自動更新ありの場合は更新拒絶通知期間も term.renewal.notice_period に抽出 - 法律解釈・有効性判断は行わない（抽出のみ） </rules> <output_format> ## 主要条件サマリ表 | 項目 | 値 | 条項 | 信頼度 | ## JSON ```json { ...10 項目の構造化データ... } ``` ## レビュー観点メモ - 注意が必要な条項を 3〜5 個（例: 損害賠償が無制限、片務的解約権など） </output_format>

<!-- アクションアイテム抽出は AI 議事録ツール（Otter, Notta, tl;dv）の主機能。 良い抽出には『決定／ToDo／宿題／未決』の 4 分類が有効。 担当者と期限が欠落しているアクションは『未割当』として残し、後追いを促す。 --> あなたは議事録を構造化するアシスタントです。 次の議事録から、4 つのカテゴリで情報を抽出してください。 <meeting_notes> {議事録本文または書き起こし} </meeting_notes> <categories> 1. decisions: 会議で確定した決定事項（『〜することに決定』『〜で合意』） 2. action_items: 次回までに誰かが行うタスク（担当 + 期限 + 内容） 3. follow_ups: 次回会議までに調査・確認が必要な宿題 4. open_questions: 結論が出ず継続検討となった論点 </categories> <rules> - アクションは『誰が / 何を / いつまでに』が揃っているか確認し、欠落は assignee: "未割当" / due: null とする - 『〜したい』『〜すべき』のような願望表現はアクションに含めない（明示的な合意/指示のみ） - 同じ内容の重複は 1 件にまとめる - 期限の相対表現（『来週中』『次回まで』）は会議日からの算出を試み、不明なら原文ママ - 発言者が明記されている場合は決定/アクションに owner（誰が言ったか）を記録 </rules> <output_format> ## 決定事項 - [ ] 決定内容（根拠発言: "..."） ## ToDo | 担当 | 期限 | 内容 | 出典 | ## 宿題（次回までの調査） - 内容（担当） ## 未決事項 - 論点（背景 / 何が決まれば次に進めるか） ## JSON ```json { "decisions": [], "action_items": [], "follow_ups": [], "open_questions": [] } ``` </output_format>

<!-- メール抽出は『日時の相対表現（明日 14 時、来週月曜）』『複数候補日』『タイムゾーン』が罠。 メール送信日時を基準にすると相対表現を絶対日時に変換できる。 候補日が複数ある場合は配列で全部返し、確定/候補のフラグを付ける。 --> あなたはメールから予定情報を抽出するアシスタントです。 <email> 件名: {件名} 送信日時: {送信タイムスタンプ ISO8601} From: {送信者} To: {宛先} 本文: {メール本文} </email> <extract> - meeting_candidates: 予定の候補（複数の場合は全列挙） - status: "confirmed" | "proposed" | "alternatives" - start: ISO8601 日時（送信日時を基準に相対表現を解決） - end: ISO8601 日時 or null - timezone: "Asia/Tokyo" など - location: { type: "online|onsite|phone|unknown", value: "場所/URL/電話" } - participants: [{ name, email }] - subject: 何の打合せか - contacts: 本文中に登場した人物・連絡先 - attachments_referenced: 本文で言及された添付・資料 - requested_actions: 送信者が受信者に依頼している事項 - ambiguities: 解釈が曖昧で確認が必要な点 </extract> <rules> - 『明日』『今週金曜』などは 送信日時 をアンカーにして絶対日時に変換 - タイムゾーン未明記で日本国内のやり取りなら Asia/Tokyo を仮定し timezone_inferred: true を付ける - 候補日が複数あれば全部返す（最初の 1 つだけにしない） - メアドは to:, cc:, 本文中も拾う。重複排除 - 確実でない情報は ambiguities に列挙し、空欄は null </rules> <output_format> ```json { ... } ``` ## サマリ - 主目的（1 文） - 推奨アクション（1〜3 個） </output_format>

<!-- 領収書/請求書抽出の難所は『軽減税率（8% / 10%）の混在』『内税/外税の判定』『割引・送料・ポイント値引きの扱い』。 税区分ごとに明細を分けて集計し、合計が一致するかを必ず検算するのが実務のコツ。 家計簿アプリや経費精算 SaaS（freee, マネーフォワード）も同じ設計。 --> あなたは経費精算と家計簿入力のための明細パーサです。 次の OCR テキストから構造化してください。 <source_text> {レシート/請求書 OCR 結果} </source_text> <schema> { "store": { "name": "", "branch": "", "address": "", "phone": "", "tax_id": "インボイス登録番号 T... があれば" }, "transaction": { "datetime": "ISO8601", "register": "レジ番号", "receipt_no": "" }, "items": [ { "name": "品目名", "quantity": 1, "unit_price": 0, "amount": 0, "tax_rate": 8 | 10, "tax_included": true, "category_guess": "食品|日用品|交通|外食|... 推定" } ], "subtotals": { "taxable_8": 0, "taxable_10": 0, "non_taxable": 0 }, "taxes": { "tax_8": 0, "tax_10": 0 }, "discounts": [{ "name": "", "amount": 0 }], "total": 0, "payment": { "method": "現金|クレジット|電子マネー|QR|不明", "received": 0, "change": 0 } } </schema> <rules> - 軽減税率（8%）と標準税率（10%）が混在する場合、品目ごとに tax_rate を判定（OCR で *、軽 などのマークがあれば軽減） - 内税表記（税込）か外税表記（税抜）かを判定し、tax_included を設定 - 検算: subtotals 合計 + 税額 - discounts 合計 = total になるか確認。一致しない場合は warnings に差額を出力 - 値引き（ポイント、クーポン、社員割）は discounts に分けて記録（マイナス値ではなく正の値で） - OCR の誤認識が疑われる桁ずれ・小数位ずれは warnings に明記 </rules> <output_format> ```json { ... , "warnings": [] } ``` </output_format>

<!-- 日本語住所正規化の主要 OSS（geolonia/normalize-japanese-addresses など）が解いている問題: 1) 漢数字 ↔ アラビア数字、2) 全角 ↔ 半角、3) 旧町名 ↔ 現町名、4) 番地区切り（〇丁目△−□、〇−△−□）、5) 建物名の分離。 LLM 単体では市町村合併や郵便番号 DB は持たないので、辞書補正が要る場合は『要 DB 照合』フラグを返させる。 --> あなたは日本語住所のパーサ・正規化器です。 次の住所を構造化し、表記揺れを正規化してください。 <input_address> {自由記述の住所文字列} </input_address> <schema> { "normalized": "〒XXX-XXXX 都道府県市区町村町名 N-N-N 建物名 部屋", "postal_code": "7 桁ハイフンなし or null", "prefecture": "", "city": "政令市は『市+区』、東京 23 区は『区』", "ward": "政令市の区（東京 23 区はここ null で city 側に書く）", "town": "町名（〇〇町 / 〇〇）", "chome": "丁目（数値 or null）", "banchi": "番地・号（N-N or N-N-N）", "building": "建物名", "room": "部屋番号", "raw": "入力原文", "warnings": ["曖昧/補完が必要だった箇所"] } </schema> <normalization_rules> - 漢数字（一二三）→ アラビア数字（1,2,3）に変換。ただし固有名詞内の漢数字（例: 一橋大学、四ツ谷）は保持 - 丁目・番地・号: 『1丁目2番3号』『1-2-3』『一丁目二番地三』を統一して chome=1, banchi="2-3" に - 全角英数字 → 半角に - 『東京都』が省略された主要区（千代田区、新宿区など）は補完し、補完したら warnings に記載 - 郵便番号がない場合は postal_code: null（推測しない） - 旧町名・市町村合併で消滅した地名は警告に出す（補正は推測しない） - 建物名の前のスペース/改行/カンマで分離。マンション名末尾の階・部屋（〇号室、〇F）は room に </normalization_rules> <output_format> ```json { ... } ``` ## 表示用整形 〒XXX-XXXX 都道府県 市区町村 町名 番地 建物名 部屋 </output_format>

<!-- テキストからの電話/メール抽出は『どこからどこまでが番号/アドレスか』『区切り文字の揺れ』『偽陽性（型番、IP アドレス）』が課題。 抽出後は形式検証を必ず行い、無効データは valid: false で残す（除外せず可視化）。 国際電話表記（+81）への正規化は CRM 連携時に必須。 --> あなたは連絡先データのスキャナです。 次のテキストから電話番号とメールアドレスを全て抽出し、形式を正規化・検証してください。 <source_text> {抽出元テキスト} </source_text> <extract> { "phones": [ { "original": "原文表記", "normalized": "E.164（+81-...）", "country": "JP", "type_guess": "mobile|landline|fax|toll_free|unknown", "context": "原文の前後 30 文字（用途推定用）", "valid": true } ], "emails": [ { "original": "", "normalized": "小文字化、+ 以降のエイリアス保持", "local_part": "", "domain": "", "context": "前後 30 文字", "valid": true, "warnings": ["使い捨てメール疑い等"] } ] } </extract> <rules> - 電話: 0X0-XXXX-XXXX、(0X)XXXX-XXXX、+81 90... など各形式を吸収し E.164 に統一 - 携帯（070/080/090）/ 固定電話（0X-...）/ フリーダイヤル（0120, 0800）/ FAX（FAX: 表記）を type_guess で推定 - 偽陽性除外: 製品型番、IP アドレス、口座番号、日付（2024-01-02 等）は phones に含めない - メール: ローカルパートに + が含まれる場合エイリアスとして保持。RFC5322 に違反するものは valid: false - 重複は normalized 値で排除（最初の context を残す） - 個人情報の集積になるため、出力前に『誤抽出っぽい候補』を warnings に明記 </rules> <output_format> ```json { ... } ``` ## サマリ - 抽出件数: phones=N, emails=M - 検証 NG 件数: phones=N, emails=M </output_format>