病院の医事課・総務課の職員から出る院内規程・委員会の決定・院内通知の質問に、いま有効な文書を根拠に答えて該当箇所を示す

処理の起点を決める

起点は2つあります。 1つは職員がTeamsの問い合わせ用チャネルに質問を書いたとき、もう1つは文書の台帳に新しい文書や改定が登録されたときです。前者が回答案を作り、後者がインデックスを更新します。

質問の受け口はチャネル1本にします。 電話や個別のチャットで届いた質問も、総務課の担当者がチャネルに書き写してから回します。受け口が分かれると、記録が残る質問と残らない質問ができ、第3章の（d）が解決しません。

インデックスの更新は台帳の登録を起点にし、ファイルの保存を起点にしません。 共有フォルダには改定案や下書きも置かれます。ファイルが置かれただけで検索対象にすると、決まっていない改定案を根拠に答えることになります。 台帳に施行日が入った時点で取り込みます。

入力データを集める

質を決めるのは台帳と用語の対応表です。 台帳の施行日と廃止日が空だと、改定前の版を外せません。用語の対応表がないと、職員が窓口で使う言葉と規程の言葉がずれて、キーワード検索に引っかかりません。 ベクトル検索がある程度補いますが、院内の略語は補えないことがあります。

過去の回答は、検索の候補には入れません。 回答は当時の版に基づいており、そのまま根拠にすると改定後に古い答えを再生産します。担当者が確認するときの参考として、横に並べるだけにします。

データの取得方法を決める

文書の読み取りは、Azure AI Document Intelligence のレイアウトモデル（prebuilt-layout）で行います。 PDF、画像、Word（DOCX）、Excel、PowerPoint、HTML を入力でき、テキスト・表・選択マークと、タイトル・セクション見出し・ページヘッダー・ページフッターなどの段落の役割を返します。

Markdown で受け取るのは、条の区切りを見出しとして残すためです。 規程は「第1章」「第3条」「2」のように階層を持ち、Markdown の見出しとして出てくれば、そこで分割できます。v4.0（2024-11-30）では表が HTML の表として出力され、結合セルや複数行の見出しも表せるとされています。手数料表のように結合セルを含む表が崩れにくくなります。

台帳は総務課の表計算ファイルか、リストで持ちます。 取り込みの処理は、台帳の行を1件ずつ読み、対応するファイルを読み取りに回します。台帳に無いファイルは取り込みません。

AIへ渡す前に整形する

1. ページヘッダー・フッター・ページ番号を外す … 段落の役割で判定します。各ページに印刷された「○○病院 総務規程」の行が条文の途中に挟まると、検索の一致がずれます
2. 条項単位に分割する … 見出しで区切り、1つの条を1件の文書にします。長い条は項で分け、条の見出しを各件の先頭に付け直します
3. 台帳の属性を付ける … 文書番号、種別、施行日、廃止日、所管部署、閲覧グループを各件に持たせます
4. 議事録は決定事項だけを切り出す … 議事録のうち「決定事項」「承認事項」の節だけを取り込み、議論の経過は取り込みません
5. 用語の対応表を同義語として登録する … 院内の呼び名で検索しても規程の用語に当たるようにします
6. 埋め込みを作る … 条項ごとの本文から埋め込みを作り、ベクトルのフィールドに入れます
7. パスワード付きの文書を確かめる … レイアウトモデルでは、パスワードでロックされたPDFは提出前にロックを解除する必要があります

4番目を省かないでください。 議事録の議論の部分には「〜という意見があった」「〜は見送る」が並びます。取り込むと、見送られた案を根拠に答えることがあります。 決定事項の節だけに絞ります。

日本語のフィールドには日本語アナライザーを付けます。 Azure AI Search には ja.microsoft と ja.lucene があり、アナライザーはデータを読み込む前、インデックスの作成時に設定します。 公式の説明では、日本語は単語の区切りにスペースを使わないため、言語に依存しない既定のアナライザーでは文字列全体が1つのトークンとして扱われる可能性があるとされています。後から変えるとインデックスを作り直すことになるので、最初に両方を試して決めます。

AIに処理させる

させるのは、検索で集めた候補だけを根拠に、質問への回答案を作り、根拠にした箇所をそのまま写すことです。

効力の順と日付は、AIに渡す前にプログラムで並べ替えておきます。 AIには「上から順に新しく、効力が強い」と伝えるだけにします。候補の並びそのものが判断の材料になるので、AIが日付を比べる場面をなくします。

2行目がいちばん起きやすい失敗です。 「時間外の預り金」と聞かれて院内に記載が無いと、生成AIは一般的な病院の運用をもっともらしく書きます。院内の文書に無いことは「見つからない」と返させ、所管部署へ回す材料にします。

指示内容を固定する

あなたは病院の総務課で、職員からの院内のルールの質問に答える担当の補助です。
下の【候補】だけを根拠に回答案を作ってください。候補に無いことは書かないでください。

【候補の並び】
候補は、効力の強い順（規程 → 要領 → 委員会の決定 → 院内通知）、
同じ種別の中では施行日の新しい順に並んでいます。廃止された版は含まれていません。
後の文書が前の文書の内容を変えている場合は、後の文書を優先してください。

【status の選び方】
- answered .... 候補の中に質問への答えがある
- partial ..... 答えの一部だけがある。足りない部分を missing_points に書く
- not_found ... 候補の中に答えが無い
- conflict .... 同じ種別・同じ時期の候補どうしで内容が食い違っている
迷ったときに answered を選ばないでください。

【厳守事項】
- quotes には、根拠にした箇所を候補の本文からそのまま写してください。
  言い換え、要約、句読点の変更をしないでください。
- quotes に写した箇所の範囲を超える説明を、answer に書かないでください。
- 一般的な病院の運用、法令、他の病院の例で補わないでください。
- 候補の本文にある「○年○月から」の記述で新旧を判断しないでください。
  新旧は候補の並び順で決まっています。
- 規程の解釈が分かれうる場合は、解釈を決めずに interpretation_needed を true にしてください。
- 候補に無い場合は status を not_found にし、answer は空にしてください。
- 質問に個人の患者や職員の情報が含まれていても、answer に繰り返さないでください。

【質問】{question}
【質問者の所属】{department}
【用語の対応表】{glossary}
【候補】{candidates}

「候補の本文の日付で新旧を判断しない」を明記しないと、本文の記述を根拠に順番を入れ替えます。 規程の附則に「この規程は令和5年4月1日から施行する」とあり、通知の本文に「令和4年度の運用を改め」とあると、年度の数字だけを比べて規程のほうを新しいと判断することがあります。 並びは台帳の日付で決めてあるので、それに従わせます。

「迷ったときに answered を選ばない」は、部分的な答えを完全な答えとして返させないためです。 規程に原則があり、例外が委員会で決まっていない質問は partial です。answered で返すと、職員は例外が無いと受け取ります。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力（response_format に json_schema と strict: true）で、この形を守らせます。

{
  "question_id": "",
  "restated_question": "",
  "status": "answered | partial | not_found | conflict",
  "answer": "",
  "quotes": [
    { "doc_no": "", "doc_type": "rule | guideline | committee | notice",
      "clause": "", "effective_date": "", "text": "" }
  ],
  "missing_points": [],
  "interpretation_needed": false,
  "route_to": ["所管部署の名前"]
}

1つ目の理由は、引用を照合できることです。 quotes の text が、検索で集めた候補の本文にそのまま含まれるかをプログラムで確かめます。含まれない引用が1つでもあれば、回答案を担当者に出す前に needs_review の印を付けます。

2つ目は、status で回し先を機械的に決められることです。

3つ目は、スキーマの制約に合わせやすいことです。 公式の説明では、構造化出力ではすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定します。省略しうる項目は null との組み合わせで表します。minItems や maxLength などのキーワードは使えないため、引用の件数や文字数の上限はプログラムの側で確かめます。

なお、構造化出力は「Bring your own data（On your data）」のシナリオでは使えないとされています。 そのため、この構成では検索を自前の処理で行い、候補を本文としてプロンプトに入れてから構造化出力で受け取ります。

システムへ連携する

閲覧の範囲は、検索のフィルターで絞ります。 公式のセキュリティ フィルターのパターンでは、グループの識別子を入れる Collection(Edm.String) のフィールドを filterable にし、search.in 関数で質問者の所属するグループに一致する文書だけを返します。人事や医療安全の委員会の決定は、関係者だけが見られるようにします。

ただし、このフィールドは認証や認可の仕組みではありません。 公式の説明でも、プリンシパルは単なる文字列で、retrievable を false にしても難読化やフィールド単位の保護にはならないとされています。すべての検索要求にフィルターを必ず付ける処理を、連携の側で1か所にまとめます。

台帳への書き込みはしません。 食い違いや廃止漏れを見つけても、台帳を直すのは所管部署です。

人が確認する

総務課の担当者は、すべての回答案を確認してから返します。 院内のルールは患者の対応や会計に直結するため、確認なしで返す設計にはしません。

1. 引用の版を確かめる … 引用の文書番号と施行日が、いま有効な版かを台帳で確かめます
2. 引用が質問に答えているかを読む … 条項は合っていても、質問の場面と違う条を引いていることがあります
3. 回答案を短く直す … 引用の範囲を超える説明が入っていれば削ります
4. partial・not_found・conflict を所管部署へ回す … 回すときは、引用と足りない点を添えます
5. 返した回答を確定として記録する … 直した箇所も残します

1番目を省かないでください。 台帳の廃止日の入れ忘れは、運用を始めたばかりの時期にいちばん多く起きます。引用の施行日を見て「この改定は聞いたことがない」と感じたら、台帳を疑います。

目標は、240件をならして1件5分です。 answered の確認は数分、conflict は所管部署への連絡文を書くので長くかかります。

例外に対処する

上から3行目は、異常ではなく発見です。 規程と通知が食い違っているのは、改定のときに関係する文書を直しきれていなかったということです。この構成を回すと、まずこの種の食い違いが見つかります。 件数を数えて、規程の見直しの材料にします。

記録を残す

• 質問の本文、質問者の所属、受け取った日時
• 検索の条件（フィルターに使った閲覧グループ）と、上位の候補の文書番号・条項・施行日
• 生成AIの出力全文（status、answer、quotes）と、引用の照合の結果
• 担当者が直した箇所と、確定した回答
• 所管部署へ回した質問と、その返事
• conflict と not_found の件数と、関係した文書

2つ目で「そのときの候補」を残すのは、版が後から変わるためです。 改定の後に「前はこう言われた」と言われたとき、当時どの版を根拠にしたかが分かれば、答えが変わった理由を説明できます。

最後の行は、規程の見直しの材料です。 not_found が続く分野は、院内にルールが無いか、あっても見つからない言葉で書かれています。