受験生と保護者からの入試の問い合わせに、募集要項を根拠にチャットで一次回答する
受験生と保護者から届く入試日程・出願資格・学費・奨学金・オープンキャンパスの質問に、受付中の年度の募集要項とFAQを根拠にWebチャットで一次回答します。根拠が無い質問と、合否や成績に関わる質問は職員へ回します。
- 利用ツール
- Amazon Kendra/Azure AI/Azure OpenAI Service/Claude/Gemini/OpenSearch
- 対象業界
- 教育
- 対象部門
- カスタマーサポート/マーケティング
- 対象業務
- 問い合わせ対応/情報検索
- 主な課題
- 人手が足りない/問い合わせが多い/営業フォローが追いつかない
- AIで行う処理
- 対話
- 主な効果
- 品質標準化/対応スピード向上/工数削減/機会損失防止
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- RAG・個別開発(大)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- フォームとメールに届いた問い合わせを、担当者が朝と夕方に確認する
- どの入試区分・どの学科・どの年度の話かを文面から読み取る。分からなければ聞き返す
- 募集要項のPDF、学費と奨学金の案内、学生便覧、過去の返信例を開いて該当箇所を探す
- 返信文を書く。合否や成績に関わるものは室長に相談する
- 返信を送り、対応記録の表に日付・話題・担当者を入力する
- 同じ人から何度も質問が来ていると気づいた担当者だけが、個別相談の案内を添える
- 受験生または保護者が、公式サイトのチャットに質問を書く
- 自動年度台帳(どの文書のどの年度が受付中かを決めた表)を読み、検索の絞り込み条件を作る
- 自動検索基盤が、受付中の年度の文書だけを対象に、該当する箇所を探す
- 自動生成AIが、見つかった箇所だけを根拠に回答文を作り、根拠の番号と引用を返す
- 自動回答に出た年度・日付・金額が引用元にそのまま書かれているかを、プログラムで照合する
- 自動照合を通ればその場で回答を返す。通らなければ回答を止め、職員へ回す
- 自動合否・成績・受験上の配慮など、個別の判断が要る質問は、答えずに職員へ回す
- 人職員が引き継がれた質問に、会話の要約を見て返信する
- 自動週に1回、同意を得て紐づけた申込者ごとに質問の回数と話題を数え、フォロー候補の一覧を作る
- 人広報担当が一覧を見て、個別相談を案内する相手を決める
各工程の詳しい説明を読む
- フォームとメールに届いた問い合わせを、担当者が朝と夕方に確認する
- どの入試区分・どの学科・どの年度の話かを文面から読み取る。分からなければ聞き返す
- 募集要項のPDF、学費と奨学金の案内、学生便覧、過去の返信例を開いて該当箇所を探す
- 返信文を書く。合否や成績に関わるものは室長に相談する
- 返信を送り、対応記録の表に日付・話題・担当者を入力する
- 同じ人から何度も質問が来ていると気づいた担当者だけが、個別相談の案内を添える
(a)前年度の要項で答えてしまう。 公式サイトには過去の募集要項のPDFが残り、FAQには年度が書かれていません。 過去の返信例を下敷きにすると、前年度の日程や検定料がそのまま残ります。出願の締切を1日間違えるだけで、受験生には取り返しがつきません。
(b)学費と奨学金は、どの文書のどの年度かが複雑。 学費は入学する年度ごとに決まり、受験生に関係するのは翌年度の入学者の金額です。一方、学生便覧は在学生向けで、今年度の版です。奨学金も、入学前に予約する制度は募集要項に、在学生向けの制度は学生便覧に載っています。 どの文書を見るかを間違えると、制度そのものが違う答えになります。
(c)返信が遅れ、答えが人によって揺れる。 夜間と週末の質問は翌営業日まで待たせます。出願期には返信まで2日かかる日もあります。同じ質問に、条件を添える担当者と添えない担当者がいます。
(d)質問の多い人を拾えない。 何度も質問してくる人は、進学先として真剣に考えている人です。しかし、同じ人からの質問かどうかは担当者の記憶に頼っていて、個別相談への案内は偶然に任されています。
- 受験生または保護者が、公式サイトのチャットに質問を書く
- 【自動】 年度台帳(どの文書のどの年度が受付中かを決めた表)を読み、検索の絞り込み条件を作る
- 【自動】 検索基盤が、受付中の年度の文書だけを対象に、該当する箇所を探す
- 【自動】 生成AIが、見つかった箇所だけを根拠に回答文を作り、根拠の番号と引用を返す
- 【自動】 回答に出た年度・日付・金額が引用元にそのまま書かれているかを、プログラムで照合する
- 【自動】 照合を通ればその場で回答を返す。通らなければ回答を止め、職員へ回す
- 【自動】 合否・成績・受験上の配慮など、個別の判断が要る質問は、答えずに職員へ回す
- 【人】 職員が引き継がれた質問に、会話の要約を見て返信する
- 【自動】 週に1回、同意を得て紐づけた申込者ごとに質問の回数と話題を数え、フォロー候補の一覧を作る
- 【人】 広報担当が一覧を見て、個別相談を案内する相手を決める
5番目が、この設計の分かれ目です。 前年度の文書を検索から外していても、回答文に日付を書くのは生成AIで、会話に書き込まれた前年度の日付に引きずられることもあります。 数字が引用元と一致しないかぎり返さない関門を最後に置きます。
10番目を人に残しているのも意図してのことです。 質問の多さは関心の高さの目安にすぎず、家庭の事情で学費を心配している人に、営業のような案内を送るのは逆効果になり得ます。
02今回想定するシステム構成
受験生・保護者(公式サイトのチャット画面) │ 申込完了メールから開いた場合のみ、同意のうえで受付番号を付ける ▼【トリガー】メッセージの送信 チャットのバックエンド(自社で用意する小さなアプリ) ├──▶ 年度台帳を読む ── 受付中の年度と文書の種類から絞り込み条件を作る ▼ Azure AI Search(ハイブリッド検索+フィルター) │ 募集要項/学費・奨学金の案内/FAQ/オープンキャンパス案内 │ └─ target_year と year_status で受付中の年度だけに絞る ▼ Azure OpenAI Service(構造化出力) │ 回答文・根拠の番号と引用・引き継ぎの理由・話題の分類 ▼ 年度・日付・金額の照合(バックエンドのプログラム) ├── 通る ───▶ その場で回答 └── 通らない/個別判断 ──▶ 既存の問い合わせフォームへ要約つきで引き継ぐ【人】 ▼ 会話の記録 ──▶ 週次でフォロー候補の一覧【人が案内を判断】
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 検索基盤 | Azure AI Search(ハイブリッド検索とフィルター) | OpenSearch、Amazon Kendra |
| 生成AI | Azure OpenAI Service(構造化出力) | Claude API、Gemini API |
| 埋め込み | Azure OpenAI Service の埋め込みモデル | 検索基盤側の埋め込み機能 |
| 連携 | 公式サイトに置くチャット画面と、自社で用意するバックエンド | 既存のチャットツールの外部連携機能 |
| 集計 | 会話記録の週次集計(スプレッドシートへの書き出し) | 募集広報の管理システムの集計機能 |
名簿と問い合わせフォームは、新しく足すものではありません。 名簿には書き込まず、フォロー候補は別の表に出します。新しく作るのは年度台帳です。 文書の種類ごとに「受付中の年度」「公表の状態」を持つだけの小さな表ですが、この構成の正しさはここで決まります。
土台になるのは Azure AI Search です。 データをAIに接続するフルマネージドのクラウドサービスで、エージェントや大規模言語モデルが根拠のある回答を生成できるようにするものとされています。フルテキスト検索とベクター検索を組み合わせたハイブリッド検索と、フィルターを同じ要求の中で使えます。
ハイブリッド検索を選ぶのは、入試の質問に固有名詞と日付が多いからです。 公式の解説では、専門用語や日付に対するクエリでは、完全一致を識別できるキーワード検索のほうがよく働くとされています。「総合型選抜」は言葉どおりに、「学費を分けて払えますか」は「分納」と書かれた箇所に意味で当てたい。その両方を1回の検索で並行して行い、1つの順位にまとめます。
フィルターは、年度を取り違えないための仕組みの本体です。 フィルターは値にもとづく条件で、キーワード検索では実行前に、ベクター検索では実行前または実行後に文書を含めたり除いたりするものとされています。そして一致が正確な場合にのみ成功します。 意味が近いかどうかで判断する検索と違い、「2027」と書いた条件に「2026」の文書が紛れ込むことはありません。
一方、Azure OpenAI の「On Your Data」(検索と回答生成を一体で行う機能)は使いません。 2026年10月14日に廃止されると明記されており、構造化出力も「持ち込みデータ」のシナリオでは現時点でサポートされていないとされています。 検索はバックエンドから直接呼び、その結果を渡して構造化出力で回答を受け取る2段の形にします。
03どうやって実装するのか
処理の起点を決める
受験生がチャットにメッセージを送信したときに動きます。 1通ごとに、年度台帳の読み込み、検索、回答生成、照合までを行い、その場で返します。夜間と週末の質問に翌営業日まで待たせないことが、この構成の効果の半分です。
文書側の更新には別のきっかけを置きます。 募集要項やFAQを差し替えたら、担当者が年度台帳を更新し、それを合図に検索のインデックス(検索用に整理した文書の索引)を作り直します。台帳と索引が食い違う時間をつくらないため、2つは同じ手順の中で行います。 フォロー候補の一覧は、毎週月曜の朝に前週の会話記録から作ります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 質問と会話履歴 | 受験生の質問文、同じ会話の直前数往復 | チャット画面 |
| 年度台帳 | 文書の種類ごとの受付中の年度、公表の状態(公表済み・公表前)、次の年度の公表予定時期 | 広報室が管理する表 |
| 募集要項 | 入試区分・学科ごとの日程、募集人員、出願資格、検定料、試験科目 | 検索基盤の索引 |
| 学費・奨学金の案内 | 入学年度ごとの納入金、分納の可否、入学前に予約する奨学金 | 検索基盤の索引 |
| FAQ・オープンキャンパス案内 | 広報室が作った質問と回答、開催日程と申込方法 | 検索基盤の索引 |
| 受付番号 | 資料請求・オープンキャンパス申込者の番号(同意した人のみ) | 申込完了メールのリンク |
質を決めるのは年度台帳です。 9月時点では、募集要項と学費は「2027年度入試・2027年度入学者」が受付中、学生便覧は在学生向けの「2026年度」です。文書によって正しい年度が違うことを、人の記憶ではなく表に持たせます。
学生便覧は、受験生への回答の根拠から外します。 奨学金の名前が似ているだけで入学前の制度と取り違えるためです。学生生活の質問には、受験生向けに書き直したFAQで答えます。
データの取得方法を決める
索引に入れる文書は、1節ごとに次の項目を持たせます。 Azure AI Search はJSON形式の文書に対してのみインデックスを作成できるとされているため、PDFやWebページは節ごとに分けてJSONにしてから入れます。
| 項目 | 中身 | 絞り込みに使うか |
|---|---|---|
doc_type | guideline(募集要項)/tuition(学費・奨学金)/faq/open_campus | 使う |
target_year | 入試年度または入学年度(例 "2027") | 使う |
year_status | current/previous/archived | 使う |
exam_category | 入試区分 | 使う |
department | 学科 | 使う |
content | 本文 | 使わない(全文検索とベクターの対象) |
source_url | 公開ページまたはPDFの場所とページ | 使わない |
絞り込みに使う項目は、索引を作る最初の時点で決めます。 公式の解説では、既存のフィールドを後から絞り込み可能に変更することはできず、フィールドの追加か索引の作り直しが必要とされています。
値の書き方も固定します。 テキストのフィルターは完全一致のみで、大文字と小文字も区別されるとされています。"2027" と "令和9年度" が混ざると、同じ年度の文書が絞り込みから落ちます。年度は西暦4桁の文字列だけと決めます。
検索時には、バックエンドが年度台帳から次のような絞り込み条件を作って検索要求に付けます。
year_status eq 'current' and search.in(doc_type, 'guideline,tuition,faq,open_campus', ',')
search.in は、区切った文字列の一覧とフィールドを照合する関数です。条件は生成AIに作らせず、台帳の値からプログラムで組み立てます。 会話から作らせると、「去年の要項では」と書かれただけで前年度が対象に入ります。
ハイブリッド検索の要求では、フィルターをクエリ処理の開始時と終了時のどちらで適用するかを vectorFilterMode で選べます。この構成では開始時に適用する側を選びます。 終了時に適用すると、前年度の節で上位が埋まり、絞り込んだ後に候補がほとんど残らないことがあります。
AIへ渡す前に整形する
- 節ごとに分ける … 募集要項は入試区分と学科の見出しで分けます。混ぜると隣の区分の日程と取り違えます
- 表を文章に直す … 学費の表は「2027年度入学者 看護学科 初年度納入金 ○円」のように1行ずつ文章にします
- 本文にも年度を書き込む … 各節の先頭に「2027年度入試 一般選抜」のような1行を足します。項目としての
target_yearとは別に、生成AIが読む本文そのものに年度を残すためです - 和暦を西暦に直す … 「令和9年2月1日」は「2027年2月1日」とし、元の表記も括弧で残します
- 前年度の節の扱いを変える … 新しい要項を入れたら、前年度の節を
previousに書き換えます。前年度の倍率を聞かれる場面があるため、削除はしません - 質問文の個人情報を伏せる … 氏名、電話番号、メールアドレス、高校名を伏せ字にしてから検索と生成に渡します
3番目を軽く見ないでください。 節の本文に年度が無ければ、生成AIは回答文に年度を書けず、読み手は今年のことか去年のことかを判断できません。
AIに処理させる
させるのは、渡された節だけを根拠に回答文を書くこと、根拠の番号と引用を添えること、答えられないときにその理由を分類すること、質問の話題を1つ付けることです。
| 質問の種類 | させること | 職員へ回す条件 |
|---|---|---|
| 入試日程・募集人員・検定料 | 節に書かれた日付と金額をそのまま示す | 該当する区分・学科の節が無い |
| 出願資格 | 要項に書かれた基準を示す | 本人の評定や資格で出願できるかの判断を求められた |
| 学費・分納 | 入学年度を明示して金額を示す | 家計の事情に踏み込んだ相談 |
| 奨学金 | 入学前に予約する制度の条件を示す | 採用される見込みを聞かれた |
| オープンキャンパス | 日程と申込方法を示す | 定員に空きがあるかなど、その時点の状況 |
| 合否・成績・受験上の配慮 | 答えない | 常に職員へ |
右端の列が、答えないことの線引きです。 「評定平均3.4ですが出願できますか」には、要項の基準は示せても、本人が満たしているかの判定は職員が高校の書類を見て行います。
| させないこと | 理由 |
|---|---|
| 前年度の情報を今年度として答える | 締切や金額が1年ずれると、出願に直接ひびく |
| 公表前の年度の日程を推測する | 「例年どおりなら」が確定情報として読まれる |
| 合格の可能性の予測、出願資格の判定 | 大学として責任を持てない |
| 渡された節に無い情報の補足 | 一般的な知識では、この大学の制度とずれる |
いちばん起きやすいのは2行目です。 新しい要項の公表前の春先には、受付中の年度の文書がまだありません。任せると、前年度の日程から「例年1月中旬です」と書きます。 台帳で公表前と分かっている種類については、回答を作らせません。
指示内容を固定する
あなたは○○大学入試広報室の問い合わせ窓口です。受験生とその保護者に、
下の【根拠の節】だけを使って日本語で答えてください。
【今回の回答で有効な年度】
{registry}
(例: 募集要項=2027年度入試(公表済み)、学費=2027年度入学者(公表済み)、
オープンキャンパス=2026年度実施分)
【厳守事項】
- 根拠の節に書かれていないことは答えないでください。一般的な大学の知識で補わないでください。
- 日付・金額・募集人員は、根拠の節の文字列をそのまま書いてください。
計算したり、言い換えたり、四捨五入したりしないでください。
- 回答には必ず年度を書いてください(例「2027年度入試の一般選抜では」)。
- 質問者が「去年」「前回」の情報を書いてきても、それを根拠にしないでください。
根拠は【根拠の節】だけです。
- 有効な年度が「公表前」の文書について聞かれたら、日程や金額を推測せず、
turn_type を handoff、handoff_reason を year_unpublished にしてください。
- 次の質問には答えず、turn_type を handoff にしてください。
合否・合格の可能性・倍率からの予測/本人が出願資格を満たすかの判定/
成績・評定の個別の評価/奨学金の採否の見込み/受験上の配慮・健康に関わる相談/
苦情
- 入試区分や学科が分からず答えが決まらないときは、turn_type を clarify にして、
どの区分・学科かを1つだけ聞き返してください。
- citations には、使った節の chunk_id と、根拠にした文をそのまま写してください。
- 病名や家庭の事情など、答えるのに不要な個人的な内容は回答文で繰り返さないでください。
【根拠の節】
{chunks}
【会話の直前の流れ】
{history}
【質問】
{question}
「質問者が書いた前年度の情報を根拠にしない」を明記しないと、会話に引きずられます。 保護者が「去年は1月8日からでしたよね」と書けば、今年度の節と食い違っても「1月8日から」に寄せることがあります。
「計算しない」も同じ理由です。 「4年間でいくらですか」と聞かれると足し算をして答えます。計算が合っていても、要項に無い数字は後段の照合を通りません。 年ごとの金額を並べて示すだけにします。
出力形式を固定する
次のJSONスキーマを構造化出力に指定して受け取ります。
{
"type": "object",
"properties": {
"turn_type": { "type": "string", "enum": ["answer", "clarify", "handoff"] },
"topic": { "type": "string",
"enum": ["exam_schedule", "eligibility", "exam_fee", "tuition",
"scholarship", "open_campus", "campus_life", "other"] },
"answer_year": { "type": ["string", "null"] },
"answer_text": { "type": "string" },
"citations": { "type": "array", "items": {
"type": "object",
"properties": {
"chunk_id": { "type": "string" },
"quote": { "type": "string" }
},
"required": ["chunk_id", "quote"],
"additionalProperties": false } },
"handoff_reason": { "type": ["string", "null"],
"enum": ["no_evidence", "year_unpublished", "result_related",
"personal_eligibility", "scholarship_outcome",
"accommodation", "complaint", null] },
"clarify_question": { "type": ["string", "null"] }
},
"required": ["turn_type", "topic", "answer_year", "answer_text",
"citations", "handoff_reason", "clarify_question"],
"additionalProperties": false
}
1つ目の理由は、形が崩れないことです。 構造化出力は指定したJSONスキーマに従わせる機能で、厳密な準拠ができなかった以前のJSONモードとは対照的だとされています。すべてのフィールドを必須にし、additionalProperties: false を設定することが求められるため、省略したい項目は null を許す型で表しています。
2つ目は、照合をプログラムで行えることです。 回答文を読まずに次の規則を当てられます。
| 照合 | 通らないときの扱い |
|---|---|
turn_type が answer なのに citations が空 | 回答を止めて no_evidence として職員へ |
citations の chunk_id が、今回渡した節に無い | 回答を止める |
quote が、その節の本文にそのまま含まれない | 回答を止める |
answer_year が年度台帳の受付中の年度と違う | 回答を止める |
answer_text に出た日付・金額が、引用した節のどこにも無い | 回答を止める |
「引用が1件以上」をプログラムで見るのは、配列の minItems が構造化出力でサポートされないキーワードとされているためです。 スキーマで表せない条件は、受け取った後に確かめます。
3つ目は、topic と handoff_reason がそのまま週次の集計に使えることです。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| チャット画面 | 公式サイトに埋め込む | 質問を受け、回答または引き継ぎの案内を返す |
| 年度台帳 | バックエンドが読む | 受付中の年度と公表の状態を取得する |
| Azure AI Search | 検索要求(REST API) | 絞り込み条件付きのハイブリッド検索で節を返す |
| Azure OpenAI Service | 構造化出力を指定した呼び出し | 回答・引用・引き継ぎの理由・話題を返す |
| 問い合わせフォーム | 既存の受付へ送る | 引き継ぎ時に、会話の要約と handoff_reason を添える |
| 会話記録 | バックエンドが書く | 受付番号、話題、turn_type、照合の結果 |
名簿の管理システムには書き込みません。 会話から名簿を自動で書き換えると、本人が知らないうちに属性が付きます。引き継ぎは既存のフォームの受付に合流させ、職員は今までと同じ場所で要約から読み始めます。
人が確認する
人が見るのは、職員へ回ってきた質問と週次の一覧です。 全件を確認すると、第10章の36.7時間には収まりません。
- 引き継がれた質問に返信する …
no_evidenceは、FAQに足すべき質問かもあわせて判断します - 照合で止まった回答を読む … 引用の不一致か年度かを見ます。年度なら台帳か索引の更新漏れを疑います
- 翌朝に前日の回答を抜き取りで読む … 1日20件ほどを読み、答え方の揺れを見つけます
- 週次のフォロー候補を判断する … 案内する相手を決め、案内は職員が送ります
2番目を省かないでください。 年度で止まる件が続くなら、台帳か索引のどちらかが更新されていません。止まった回答は、仕組みのずれを知らせる警報です。
フォロー候補の規則は、最初は単純にします。 同じ受付番号で1週間に質問3件以上、または学費・奨学金・特定学科の出願方法について2回以上。すでに個別相談を予約している人と、引き継ぎで職員が対応中の人は一覧から外します。
例外に対処する
| 起きること | 対応 |
|---|---|
| 受付中の年度の文書がまだ無い(公表前) | 日程・金額を答えず、公表予定時期を案内して職員へ |
| 前年度の情報を明示的に聞かれた(前年度の倍率など) | その質問に限り previous の節を検索し、回答に「前年度の実績」と明記 |
| 学年から入試年度がずれる(「今は高校2年生です」) | 対象年度の文書が無ければ year_unpublished として扱う |
| 入試区分・学科が分からない | 1つだけ聞き返す。2回聞いても決まらなければ職員へ |
| 検索で節が1件も見つからない | no_evidence として職員へ。FAQに足す候補として記録 |
| 生成AIの応答が返らない、形式が崩れる | 「入試広報室からご連絡します」と返し、フォームへ引き継ぐ |
| 病名や障害に触れる相談が書かれた | 答えずに職員へ。専用の窓口を案内する |
上の3行が、年度の取り違えに関わる例外です。 2行目は、禁じ過ぎると「去年の倍率は?」にも答えられません。前年度の節は、質問者が前年度と明示したときだけ使い、回答に年度を必ず書かせます。
記録を残す
- 質問文(伏せ字にした後のもの)と、回答文・
turn_type・topic・handoff_reason - そのときの年度台帳の内容と、検索に付けた絞り込み条件
- 検索で返った節の
chunk_idと、生成AIが引用した節のchunk_id - 照合の結果(通った/止まった、止まった理由)
- 受付番号(同意した人のみ)と、同意した日時
- 職員が引き継ぎに返信した日時と、FAQに足したかどうか
2つ目を残すのは、「チャットで聞いた日程と違った」と連絡があったとき、台帳の更新漏れか生成AIの誤りかを切り分けるためです。 会話記録の保存期間は名簿と同じ規程に合わせ、入試年度が終わったら受付番号との紐づけを外します。
04実装レベルの3段階
半自動化で、1件6分が3分程度になります。 探す時間はほぼ無くなりますが、職員が下書きを読んで送る作業が全件に残ります。本格構成で平均2分になり、この段階が本記事の想定です。 差が大きいのは、チャットで完結する質問に職員が触れなくなるためです。 段階を飛ばさないでください。 半自動化を1〜2か月動かすと、下書きが外れる質問の型と、FAQに足りない質問が分かります。職員が毎日見ているうちに年度台帳の運用を固め、それから受験生の前に出します。
05工数削減シミュレーション
導入後 1,100件 × 2分 ÷ 60 = 36.7 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 受験生と保護者からの問い合わせが通年で月数百件以上ある私立大学・短期大学・専門学校・私立高校。募集要項・学費と奨学金の案内・FAQが文章として整っている場合。資料請求やオープンキャンパスの申込者を名簿として持ち、個別相談への誘導を広報の成果として追っている場合。入試区分や学科が多く、同じ質問への答えが担当者によって揺れている場合。
- 問い合わせが月数十件で、担当者1名の返信で足りている場合。募集要項が紙とPDFしかなく、年度ごとの版を区別して管理できていない場合(先に資料の版管理を整えるほうが効く)。問い合わせの大半が合否や成績、受験上の配慮など個別の判断を要するもので占められている場合。なお、出願資格の個別の認定や合否に関わる判断は、この構成では代替できません。
07最小構成で試す方法
- 過去3か月の問い合わせから50件を選ぶ(うち10件は、前年度と今年度で答えが変わる質問にする)
- 今年度の募集要項と学費の案内から、該当する節の文章を手でコピーしておく
- 手元の生成AIの画面に、節の文章と質問を貼り、「この文章だけを根拠に答えてください。書かれていないことは『分からない』としてください。回答には年度を書いてください」と指示する
- 出てきた回答を、当時の職員の返信と突き合わせる
- 同じ10件について、前年度の要項もあわせて貼ったときに、どちらの年度で答えるかを確かめる
5番目が、この構成の必要性を確かめる試験です。 前年度と今年度の文書が両方目の前にあると、生成AIは質問の言い回しに近いほうを使います。ここで取り違えが出れば、検索の段階で年度を絞る設計が必要だということが分かります。
| 出てきた内容 | 判断 |
|---|---|
| 今年度の節だけを貼ったときは正しく答えた | 検索基盤と年度台帳の構築に進む |
| 両年度を貼ると前年度で答える件がある | 想定どおり。絞り込みを検索側に置く理由になる |
| 節を貼っても答えが要項とずれる | 節の切り方か、表を文章に直す前処理を見直す |
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 前年度の要項で答える | 絞り込みを検索側に置く。生成AIへの指示だけで防ごうとしない |
| 台帳を更新したのに索引が古い | 台帳の更新と索引の作り直しを同じ手順にし、完了を確認してから公開 |
| 年度の値の表記がばらばらで絞り込みから落ちる | 西暦4桁の文字列だけにする。完全一致で大文字小文字も区別される |
| 後から学科で絞りたくなった | 既存のフィールドは後から絞り込み可能にできない。最初に項目を決め切る |
| FAQに年度が無い | FAQを1問ずつ年度に紐づけ直す。紐づけられないものは索引に入れない |
| 学生便覧の制度と入学前の制度を取り違える | 学生便覧は受験生への回答の根拠から外す |
| 回答に書かれた金額が要項に無い | 計算を禁じ、引用元に無い数字は照合で止める |
| 公表前に「例年どおり」と答える | 台帳の公表前の状態を見て、回答を作らせない |
| 質問の多い人に一律で案内を送る | 一覧までにして、案内するかは広報担当が決める |
| On Your Data を前提に組んでしまう | 2026年10月14日の廃止が明記されている。検索を直接呼ぶ2段の構成にする |
上の3行が、この構成の失敗のほとんどです。 どれも「年度の絞り込みが正しく効いているか」という同じ一点から出ています。生成AIの指示で守るのではなく、台帳・索引・絞り込みという仕組みで守れているかどうかで、運用に乗るかが決まります。
下の2行も早く効いてきます。 一律の案内は、質問の多さを関心の高さと取り違えます。On Your Data は手軽さから選ばれやすいのですが、構造化出力と併用できず、この構成の照合が組めません。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 受験生と保護者の質問文、そこに書かれうる氏名・高校名・成績、そして受付番号で紐づく資料請求やオープンキャンパスの申込情報です。質問者の多くは未成年です。
- 紐づけの目的を、申込の時点で具体的に示す … 個人情報保護委員会のガイドラインでは、利用目的は単に抽象的・一般的にではなく、本人が一般的かつ合理的に想定できる程度に具体的に特定することが求められています。「チャットでの質問の回数と話題をもとに、個別相談のご案内に利用します」と、チャットを開く前に示し、同意した人だけを紐づけます
- 分析のような扱いは、とくに具体的に書く … 同じガイドラインでは、閲覧履歴や購買履歴を分析して広告配信に使う場合、「マーケティング活動に用いるため」では足りない例として挙げられています。質問の話題を数えて案内先を選ぶのは、これに近い扱いです
- 健康や障害に関わる相談をチャットで受けない … 受験上の配慮の相談は、専用の窓口へ案内します。チャットの記録に病名が残らないよう、答えずに引き継ぎます
- 外部へ渡す範囲を伏せ字の後の質問に限る … 検索と生成に渡すのは、氏名・連絡先・高校名を伏せた質問文です。受付番号も生成AIには渡しません。 紐づけはバックエンドの記録の側で行います
- 合否や出願資格の判断をさせない … この構成が出すのは、要項に書かれた基準までです。本人が満たしているかの判断は、書類を見る職員の仕事です
- 画面に「募集要項の記載が優先します」と示す … 回答ごとに根拠の節と年度も表示します
誤りが起きた場合のリスクは、前年度の日程や金額を伝えることと、答えてはいけない質問に答えることの2つです。 前者は台帳と絞り込みの更新漏れで起き、後者は引き継ぎの条件の漏れで起きます。どちらも生成AIの賢さではなく、仕組みの側で防ぐものです。
10まず何から始めるか
1週目:年度台帳を作る
文書の種類ごとに、受付中の年度、公表の状態、次の年度の公表予定時期を1行ずつ書きます。あわせて、公式サイトに残っている前年度のPDFとFAQを洗い出します。 年度の書かれていないFAQが何問あるかを数えるのが最初の成果です。
2週目:50件で試す
過去の問い合わせから50件を選び、第8章の手順で試します。前年度と今年度で答えが変わる10件で、両年度の文書を貼ったときにどちらで答えるかを最優先で見ます。
3週目:答えない質問の線を決める
合否、出願資格の個別判断、奨学金の採否、受験上の配慮について、どこから職員へ回すかを入試広報室と入試の判定を担う部署で決めます。 ここが決まらないうちに公開すると、答えてよいかの判断を生成AIに任せることになります。
4週目:索引を作り、職員向けの下書きから始める
絞り込みの項目を決めて索引を作り、職員が質問を入れると根拠付きの下書きが出るところまで作ります。この段階では受験生に直接は返しません。
2か月目: 照合の規則を足し、職員向けの下書きで年度の取り違えが出ないかを毎日見ます。3か月目以降: 公式サイトのチャットを公開し、週次のフォロー候補の一覧を始めます。次の年度の募集要項の公表で、台帳の更新と索引の作り直しを一度通しで行い、取り違えが出なかった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Azure AI Search がデータをAIに接続するフルマネージドのクラウドサービスで、根拠のある回答の生成を支えること。ハイブリッドのクエリとフィルターを備えること。JSON形式の文書にのみインデックスを作成できること | Microsoft Learn: Azure AI 検索の概要 | 2026-09-25 |
フィルターが値にもとづく条件で、キーワード検索では実行前、ベクター検索では実行前または実行後に適用されること。一致が正確な場合にのみ成功すること。テキストのフィルターは完全一致で大文字小文字を区別すること。search.in が多数の値との照合に推奨されること。既存のフィールドを後から絞り込み可能に変更できないこと | Microsoft Learn: テキスト クエリ フィルター | 2026-09-25 |
ハイブリッド検索がフルテキストとベクターのクエリを並列で実行し、結果を1つの順位にまとめること。製品コード、専門用語、日付、人の名前ではキーワード検索がよく働くこと。フィルターを処理の開始時または終了時に適用でき、vectorFilterMode で指定する例があること。セマンティックランク付けが省略可能であること | Microsoft Learn: ハイブリッド検索の概要 | 2026-09-25 |
| Azure OpenAI On Your Data が2026年10月14日に廃止されると明記されていること。Azure AI Search のフィルターを指定できること。セマンティック検索に追加の価格が適用されること | Microsoft Learn: Azure OpenAI でデータを使用する | 2026-09-25 |
構造化出力が指定したJSONスキーマに従わせる機能で、以前のJSONモードと異なること。すべてのフィールドを必須にし、additionalProperties: false を設定すること。null との共用体で省略可能な項目を表せること。minItems・pattern などがサポートされないこと。持ち込みデータのシナリオでは構造化出力がサポートされないこと | Microsoft Learn: 構造化出力を使用する方法 | 2026-09-25 |
| 利用目的を、本人が一般的かつ合理的に想定できる程度に具体的に特定する必要があること。閲覧履歴や購買履歴を分析して広告配信に使う場合の適切な例と、「マーケティング活動に用いるため」が不適切な例であること。取得時の利用目的の通知・公表 | 個人情報保護委員会: ガイドライン(通則編) | 2026-09-25 |
募集要項の内容と、どの質問を職員へ回すかは、各学校の入試広報室と入試の判定を担う部署で決めてください。 本記事は上記の公式ページで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0233)についてのご相談はこちらから。
