保険代理店の募集人向けに、保険会社の商品パンフレットと約款から、改定点を押さえた理解度テストと解説を作る

処理の起点を決める

共有ドライブの「テスト作成」フォルダを、Apps Script の時間主導のトリガーで1時間ごとに見ます。 資料は業務の合間にまとめて置かれることが多く、すぐに処理する必要はありません。 1時間の間隔なら、改定の資料と旧版を続けて置く時間も取れます。

1件の単位は「サブフォルダ」にします。 業務管理部は資料ごとにサブフォルダを作り、新版の資料一式と、改定なら旧版を入れます。サブフォルダの名前の末尾に「_ready」を付けたときに処理の対象にします。 ファイルを1つずつ置いている途中で動き出すと、旧版が無いまま「新商品」として設問が作られるためです。

処理が終わったサブフォルダは、名前の末尾を「_done」に変えます。変えるのは下書きの一覧に書き出せたときだけにし、途中で失敗したものは「_ready」のまま残します。

入力データを集める

質を決めるのは、旧版の資料です。 旧版が無いと、AIは「変更点のご案内」の要約だけから改定点を問うことになり、案内に書かれていない細部の変化を拾えません。 旧版は、保険会社のサイトから消える前に共有ドライブに残しておく運用にします。

過去の設問は、重複を避けるために渡します。 同じ商品の同じ点を毎回問うと、募集人は答えを覚えてしまいます。正答率が低かった点は、問い方を変えてもう一度問うよう方針のシートに書いておきます。

募集人の名前や成績は、AIに渡しません。 設問を作るのに要るのは資料と方針だけです。

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

PDFは大きさで渡し方を変えます。 パンフレットのような小さいものは、base64にしてリクエストに直接入れます。約款のように大きいものは Files API で上げてから、その uri を渡します。 Files API に上げたファイルは48時間保存されるとされているので、同じ資料で設問を作り、解き直すまでを48時間のうちに終えます。

旧版と新版は、1回のリクエストに並べて入れます。 公式の説明では、資料とプロンプトの合計がモデルのコンテキストに収まる範囲で、複数のPDFを1回で渡せます。指示の中で、どちらが新版かをファイルの順と名前で明示します。

AIへ渡す前に整形する

1. ファイルの確認 … PDFであること、パスワードが掛かっていないことを確かめます
2. 新旧の見分け … ファイル名の決まりで新版と旧版を分け、決まりに合わないものは処理せず業務管理部に戻します
3. ページの向きの確認 … 横向きのページは向きを直します。公式の説明でも、正しい向きにそろえることが勧められています
4. 約款の範囲の絞り込み … 約款が数百ページあるときは、変更点のご案内に挙がった条項の前後を優先して渡す範囲を決めます
5. 過去の設問の取り出し … 同じ商品の過去の設問を、題目と正答率だけにして渡します

4番は、設問の焦点を保つためです。 約款を全部渡すと、AIは目に付いた細かい条項から設問を作ることがあります。募集人が顧客に説明する場面で使う点から外れた設問は、正解しても役に立ちません。ただし範囲を絞りすぎると改定の細部を見落とすので、変更点のご案内に挙がった条項は必ず含めます。

AIに処理させる

1回目の呼び出しでは、次の2段階を1回でさせます。

2回目の呼び出し（解き直し）では、設問と選択肢だけを渡します。 正解と解説は渡さず、資料を見て答えと根拠のページを返させます。1回目の正解と一致しなければ「正解が割れた」とし、人に回します。

1行目がいちばん起きやすい失敗です。 「告知義務違反があった場合の扱い」のような問いは、一般的な説明で正解を作れてしまいます。根拠の文を写させ、写せない設問は作らせないことで、資料の外から来た設問を止めます。

指示内容を固定する

あなたは保険代理店の業務管理部で、募集人向けの理解度テストを作る立場です。
渡した資料だけを根拠にしてください。資料に書かれていないことを問わないでください。

【資料】
1つ目以降のPDFのうち、ファイル名が「新_」で始まるものが新版、「旧_」で始まるものが旧版です。
【資料の情報】{product_info}
【出題の方針】問数：{n}問／改定点の問：{ratio}以上／四択
【過去に出した設問の題目】{past_topics}

【やること】
1. 募集人が顧客に説明すべき点（保障の範囲、支払われない場合、特約の付け方、
   引受の条件、手続き）を書き出してください。
2. 旧版があるときは、新版と比べて変わった点を書き出してください。
   変更点のご案内にない変化も、資料どうしを比べて見つかれば書き出してください。
3. 書き出した点ごとに、根拠の文を資料からそのまま写し、資料名とページを付けてください。
4. 書き出した点から設問を作ってください。正解は1つだけにしてください。

【厳守事項】
- 根拠の文を資料から写せない点は、書き出さず、設問も作らないでください。
- 一般的な保険の知識で設問や正解を作らないでください。
- 旧版に無い記載を、推測で「変わった」としないでください。
- 他社の商品との比較、おすすめの顧客、保険料の計算を問わないでください。
- 過去に出した題目と同じ点を問うときは、問い方を変えてください。
- 誤りの選択肢は、資料の記載を取り違えやすい形（旧版の扱い、似た特約の扱い）で作ってください。

「根拠の文を写せない点は書き出さない」を論点の段階に置いているのが要です。 設問の段階で根拠を求めると、AIは先に作った設問に合う文を探しにいき、近い文を根拠として写してしまいます。 論点を書き出す時点で根拠を写させれば、根拠の無い論点はそもそも生まれません。

誤りの選択肢の作り方を指定しているのは、テストの意味を保つためです。 明らかにおかしい選択肢では、理解していなくても正解できます。旧版の扱いを誤りの選択肢に置くと、改定を知らない募集人だけが引っかかります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "product": "",
  "points": [
    { "point_id": "P1", "kind": "explain | change",
      "summary": "", "quote": "", "source_file": "", "page": 0,
      "old_quote": "", "old_page": 0 }
  ],
  "questions": [
    { "q_id": "Q1", "point_id": "P1", "stem": "",
      "choices": ["", "", "", ""], "answer_index": 0,
      "explanation": "" }
  ]
}

1つ目の理由は、設問と論点を point_id で結べることです。 業務管理部は設問を見て、論点の quote と page から資料のページを開けます。改定点の問なら、old_quote と old_page で旧版の該当箇所も開けます。

2つ目は、検査をプログラムでできることです。 スキーマでは kind を enum、quote と page を required にし、choices は minItems と maxItems で4つに固定します。ただし公式のページは、スキーマに合ったJSONでも値が正しいとは限らないので、アプリケーションの側で確かめるよう案内しています。Apps Script では次を確かめます。

3つ目は、確定した設問をそのまま Forms API の形に移せることです。 choices が選択肢、answer_index の選択肢が correctAnswers、explanation が whenWrong の解説になります。

下書きの一覧には、1問を1行にして次のように並べます（商品名と内容は架空の例です）。

「印」の列を左端に置くのは、確定の作業を上から順に進められるようにするためです。 並べ替えで印の付いた行を上に集め、quote の全文は行を選んだときに右の列で読めるようにします。

システムへ連携する

テストへの変換は batchUpdate を2つの段に分けます。1段目で updateSettings によりテストにし、2段目で設問ごとの createItem を並べます。1問の createItem は次の形です。

{
  "createItem": {
    "item": {
      "title": "改定後の〇〇特約を付けられる契約の条件として、正しいものはどれか",
      "questionItem": {
        "question": {
          "required": true,
          "grading": {
            "pointValue": 10,
            "correctAnswers": { "answers": [ { "value": "選択肢2の文" } ] },
            "whenRight": { "text": "正解です。新_約款 p.48" },
            "whenWrong": { "text": "解説の文。新_約款 p.48、改定前は旧_約款 p.45" }
          },
          "choiceQuestion": {
            "type": "RADIO",
            "options": [ { "value": "選択肢1の文" }, { "value": "選択肢2の文" } ]
          }
        }
      }
    },
    "location": { "index": 0 }
  }
}

correctAnswers の値は、選択肢の文と1字も違わないようにします。 公式の説明では、回答は文字列として採点され、正解の値と完全に一致する必要があるとされています。選択肢の文を変数1つから両方に入れるように組めば、食い違いは起きません。location の index は、並べる順に0から振ります。

フォームは、業務管理部が下書きの一覧で「確定」に印を付けた設問だけで作ります。 印を付けた後に、一覧のメニューから「テストを作る」を押す形にします。作るのは未公開の状態までで、公開と募集人への送付は人が行います。

APIキーは、Apps Script のスクリプトのプロパティに置き、コードに書きません。

人が確認する

すべての設問を、業務管理部が確定してから使います。 見る順番を印で決めます。

1. 「根拠なし」「正解が割れた」を先に見る … 資料のページを開いて確かめ、直せる設問は直し、直せない設問は外します
2. 改定点の問を見る … old_quote と quote を並べ、本当に変わった点かを確かめます
3. 残りの設問を流し読む … 問い方が募集人に通じるか、選択肢が紛らわしすぎないかを見ます
4. 保険会社の担当に聞く … 資料を読んでも正解が決まらない点は、設問から外し、保険会社に問い合わせます

2番を省かないでください。 改定点を取り違えた設問は、誤った改定内容を全募集人に教えることになります。 テストは理解を確かめる道具であると同時に、出した問題そのものが教材になります。

目標は、1件をならして30分です。 印の無い設問は流し読みで済むので、時間の大半は印の付いた設問と改定点の問に使います。印の付く設問が半分を超える件が続くなら、指示か資料の渡し方に問題があります。 そのときは、どの印が多いかを数え、「根拠なし」が多ければ約款の範囲の絞り込みを、「正解が割れた」が多ければ問い方の決まりを見直します。

例外に対処する

「問数に届かないまま出す」のは、意図してのことです。 問数を満たそうとすると、AIは根拠の薄い設問で数を埋めます。少ない問数で正確なテストのほうが、多い問数で1問誤っているテストよりよいからです。

記録を残す

• 処理したサブフォルダと、資料のファイル名・版
• AIに渡した指示と、返ってきたJSON（論点と設問）
• 解き直しの結果と、正解が割れた設問
• 業務管理部が直した点、外した設問とその理由
• 公開したフォームと、確定した設問の一覧（設問の台帳）
• 設問ごとの正答率と、点数の低かった募集人へのフォローの記録

最後の行が、教育の体制の記録になります。 「いつ、どの改定について、誰が理解を確かめられ、誰に補ったか」を残しておくと、研修をしたという記録だけでなく、理解したかを確かめた記録になります。

正答率の低い設問は、次の出題の方針に戻します。 同じ点を問い方を変えてもう一度問い、それでも低ければ、資料の書き方か朝礼での説明に問題があると考えます。