学習塾で毎月届く手書きの入塾申込書を読み取り、生徒・保護者・学校・受講講座・引落口座の有無を生徒台帳の項目にそろえ、記入漏れと読み取りに自信のない欄を教室長に返す
各教室で受け取った手書きの入塾申込書を読み取り、生徒・保護者・学校・受講講座・口座振替の手続きの有無を生徒台帳の項目にそろえます。記入漏れと読み取りに自信のない欄は、その日のうちに教室長へ返します。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 教育
- 対象部門
- 総務
- 対象業務
- データ入力・転記/内容確認・チェック
- 主な課題
- 入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 保護者が教室で申込書を書き、教室長が受け取って目で見る
- 教室長が申込書をスキャンし、本部へメールで送る。原本は教室で保管する
- 本部の事務が、数日分たまったところで1枚ずつ開き、生徒台帳に打ち込む
- 受講講座の □ を見て、講座の一覧と照らし、学年と曜日が合っているかを見る
- 記入漏れや読めない字、講座の矛盾があれば、教室長にメールで問い合わせる
- 教室長が保護者に電話で聞き、本部へ返事をする
- 口座振替の依頼書が出ていない生徒を、請求の担当に知らせる
- 人教室長が申込書を受け取り、教室の複合機でスキャンして、共有ドライブの教室ごとの取込フォルダに保存する
- 自動Apps Script の時間主導型トリガーが10分おきに各教室の取込フォルダを見て、新しいファイルを拾う
- 自動Document AI が申込書を読み、項目名と値の組・チェックボックス・信頼度を返す
- 自動Apps Script が口座振替の欄の番号らしい値と、配慮が要ることの欄を伏せる
- 自動Gemini API が、申込書の欄を生徒台帳の項目に写す
- 自動Apps Script が必須の欄を点検し、受講講座を講座の一覧と、学校名を学校の一覧と照らす
- 自動生徒台帳の下書きの行と、教室ごとの差し戻しの一覧に書き込み、教室長にチャットで知らせる
- 人教室長が差し戻しの一覧を見て、保護者がまだ教室にいるうちか、その日のうちに聞き直す
- 人本部の事務が `complete` の行と、教室長が埋めた行を確かめて台帳の確定の列に移す
各工程の詳しい説明を読む
- 保護者が教室で申込書を書き、教室長が受け取って目で見る
- 教室長が申込書をスキャンし、本部へメールで送る。原本は教室で保管する
- 本部の事務が、数日分たまったところで1枚ずつ開き、生徒台帳に打ち込む
- 受講講座の □ を見て、講座の一覧と照らし、学年と曜日が合っているかを見る
- 記入漏れや読めない字、講座の矛盾があれば、教室長にメールで問い合わせる
- 教室長が保護者に電話で聞き、本部へ返事をする
- 口座振替の依頼書が出ていない生徒を、請求の担当に知らせる
(a)本部での打ち込みが月初に集中する。 入塾日は月初が多く、申込書も月末から月初に固まって届きます。3人の事務が、請求の締めと重なる時期に打ち込みます。
(b)講座の選び間違いに気づくのが遅い。 学年に合わない講座、開講していない曜日、科目は選んだのにコースが無い。気づくのは4番の照合のときで、初回の授業の前日ということもあります。
(c)教室長との問い合わせが行き来する。 5番と6番は、メールと電話で数日かかります。教室長は授業の合間にしか返事ができず、事務は返事を待つ一覧を手で管理しています。
(d)手書きの字が読みにくい。 学校名の略し方、メールアドレスの英字と数字、フリガナの小さい字。メールアドレスの1文字違いは、保護者への連絡が届かないまま気づかれません。
- 【人】 教室長が申込書を受け取り、教室の複合機でスキャンして、共有ドライブの教室ごとの取込フォルダに保存する
- 【自動】 Apps Script の時間主導型トリガーが10分おきに各教室の取込フォルダを見て、新しいファイルを拾う
- 【自動】 Document AI が申込書を読み、項目名と値の組・チェックボックス・信頼度を返す
- 【自動】 Apps Script が口座振替の欄の番号らしい値と、配慮が要ることの欄を伏せる
- 【自動】 Gemini API が、申込書の欄を生徒台帳の項目に写す
- 【自動】 Apps Script が必須の欄を点検し、受講講座を講座の一覧と、学校名を学校の一覧と照らす
- 【自動】 生徒台帳の下書きの行と、教室ごとの差し戻しの一覧に書き込み、教室長にチャットで知らせる
- 【人】 教室長が差し戻しの一覧を見て、保護者がまだ教室にいるうちか、その日のうちに聞き直す
- 【人】 本部の事務が
completeの行と、教室長が埋めた行を確かめて台帳の確定の列に移す
8番目が、この設計の分かれ目です。 教室長は申込書を受け取ってから十数分で差し戻しの一覧を見られます。 保護者が面談の後に教室に残っていれば、その場で書き足してもらえます。
9番目で確定を本部に残すのも、意図してのことです。 台帳に入った生徒から月謝の請求が始まります。読み違えた講座で請求が始まると、保護者からの信頼にひびきます。
02今回想定するシステム構成
入塾申込書(手書き、表裏1枚) │ 教室の複合機でスキャン ▼【トリガー】Apps Script の時間主導型トリガー(10分おき) Google Apps Script ── 形式・ページ数・教室の確認 ▼ Google Document AI(Form Parser) │ 項目名と値の組・チェックボックス・信頼度を返す ▼ Google Apps Script ── 口座の番号らしい値と、配慮が要ることの欄を伏せる ▼ Gemini API ── 生徒台帳の項目に写す │ 生徒/保護者/学校・学年/受講講座/入塾日/口座振替の手続きの有無 ▼ Google Apps Script ── 必須の欄の点検、講座の一覧・学校の一覧との照合 │ complete/missing/not_detected/unreadable/course_conflict ├──▶ 生徒台帳の下書きの行 └──▶ 教室ごとの差し戻しの一覧(教室長にチャットで通知) ▼ 【教室長が聞き直し、本部の事務が確かめて台帳に確定】
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Form Parser) | Azure AI Document Intelligence |
| 生成AI | Gemini API(申込書の欄の生徒台帳の項目への対応付け) | Claude API、OpenAI API |
| 差異計算 | Google Apps Script(必須の欄の点検、講座の一覧・学校の一覧との照合) | Python |
| 連携 | Google Apps Script(取込フォルダの監視、伏せる処理、一覧の書き込みと通知) | Python |
| 保管 | Google ドライブ(共有ドライブ)、Google スプレッドシート | 塾向けの生徒管理の製品 |
新しく作るのは、申込書の欄の一覧と講座の一覧の照合用の列です。 欄の一覧には、欄の名前と必須かどうかを並べます。講座の一覧には、講座ごとに対象の学年と開講の曜日の列を足します。
土台は Document AI の Form Parser です。 公式のプロセッサ一覧では、OCRのテキストに加えて、キーと値のペア(エンティティとチェックボックス)、表、一般的なエンティティを抽出するとされ、言語の一覧で日本語(ja)は手書きに対応する言語として示されています。 申込書の多くの欄が □ なので、チェックボックスをキーと値の組で返す形がそのまま使えます。
Form Parser には、この題材で効く注意書きが2つあります。 1つは、ラジオボタンの読み取りに対応しないこと。「続柄 父・母・その他」を○で囲む形の欄は読めません。もう1つは、値の入っていないキーと値の組(空欄の用紙など)を確実には読み取れないことです。キーが返ってこないことを空欄と決めつけない設計にします(第7章)。
03どうやって実装するのか
処理の起点を決める
教室長が申込書を受け取り、その場でスキャンして教室の取込フォルダに保存することを起点にします。 ファイル名は「教室コード_受付日_連番」にし、教室の複合機の保存先を共有ドライブの教室ごとのフォルダにします。Apps Script の時間主導型トリガーが10分おきに、6教室の取込フォルダを順に見ます。
1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。1枚ごとに Document AI と Gemini API を呼ぶので、1回に8件までとし、残りは次の実行に回します。 処理済みのフォルダへ移すのは、下書きと差し戻しの一覧への書き込みまで成功したときだけにします。
本部へのメールでの送付はやめます。 メールに添付された申込書は、受信箱に個人の情報が残り、誰が開いたかも追えません。 共有ドライブのフォルダに置けば、権限と履歴で管理できます。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 申込書のPDF | 表と裏の2ページ。教室コード、受付日 | 教室の取込フォルダ |
| 読み取り結果 | 項目名と値の組、チェックボックス、全文のテキスト、要素ごとの信頼度 | Document AI(Form Parser) |
| 申込書の欄の一覧 | 欄の名前、必須かどうか、表裏のどちらにあるか | 本部で用意する一覧 |
| 講座の一覧 | 講座名、科目、コース、対象の学年、開講の曜日、教室 | 本部の講座の一覧に列を足す |
| 学校の一覧 | 地域の学校の正式な名前と、よくある略し方 | 本部で用意する一覧 |
| 生徒台帳 | 在籍中の生徒、兄弟姉妹の在籍 | スプレッドシート |
質を決めるのは、講座の一覧の「対象の学年」と「開講の曜日」の列です。 この2列が無ければ、受講講座の矛盾は照合できません。講座の名前だけの一覧では、教室長の頭の中の決まりが表に出てきません。
生徒台帳は、兄弟姉妹の在籍を照らすために読みます。 申込書で「兄弟姉妹の在籍あり」に印があるのに台帳に該当が無ければ、兄弟の割引の扱いを確かめる行として差し戻しの一覧に載せます。 割引をするかどうかの判断は本部の事務が行います。
データの取得方法を決める
読み取りは、Apps Script から Document AI の処理の API を呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。
| 取るもの | 応答のどこから | 何に使うか |
|---|---|---|
| 項目名と値の組 | pages[].formFields[] の fieldName と fieldValue | 氏名、フリガナ、生年月日、学校名、学年、電話番号、メールアドレス、住所、入塾日 |
| チェックボックス | formFields の fieldValue の valueType(filled_checkbox/unfilled_checkbox) | 受講講座の科目・コース・曜日、兄弟姉妹の在籍、口座振替の依頼書の提出 |
| 全文のテキスト | text と、各要素の textAnchor | キーと値の組で取れなかった欄の拾い直し |
| 信頼度 | 各要素の layout の confidence | 手書きの字の読み取りが確かかの判定 |
口座振替の欄は、ここで Apps Script が扱います。 申込書に口座の番号を書く欄を設けている塾では、その欄の値を記号に置き換えてから Gemini API に渡します。 台帳に要るのは「依頼書を出した」の □ の印だけで、番号を読む必要はありません。配慮が要ることの欄(アレルギーなど)も、同じく伏せて、教室長が原本で確かめる項目にします。
受講講座の □ は、科目・コース・曜日の3つの組で読みます。 申込書の講座の欄は「英語 □標準 □発展 □月 □水 □金」のように並んでいるので、同じ行にある印を1つの講座の選択としてまとめます。 まとめるのは位置での規則で、AIに任せません。
AIへ渡す前に整形する
- 形式の確認 … Document AI の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。教室の複合機の保存形式は PDF にします
- 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。6教室の複合機をすべて300dpiにそろえます
- 圧縮の確認 … 非可逆の形式は画質と精度を落とすことがあるとされています。「高圧縮」の設定を使いません
- 表裏の確認 … 2ページあることを確かめます。裏面のスキャンを忘れたものは、教室長に読み込み直しを頼みます
- 向きの確認 … 逆さのページは向きを直します
- 重複の検知 … 同じ生徒の氏名と生年月日の申込書が直近にあれば、後のものに「書き直し」の印を付けます
4番目を軽く見ないでください。 裏面が無いと、口座振替の □ と兄弟姉妹の在籍が not_detected になり、本当は書いてある保護者に聞き直すことになります。 ページの数で先に弾きます。
AIに処理させる
させるのは、申込書に書かれた文字と印を、生徒台帳の項目に写すことだけです。 必須の欄がそろっているか、講座の選び方が正しいかの判断はさせません。
| 写す項目 | 当たるものの例 | 判断できないときの扱い |
|---|---|---|
| 生徒の氏名・フリガナ・生年月日 | 「生徒氏名」「ふりがな」「生年月日」 | 読みにくい字は読めたまま写し unclear |
| 学校名・学年 | 「学校名」「学年」 | 書かれたとおりに写す。 学校の一覧との照合はしない |
| 保護者の氏名・続柄 | 「保護者氏名」「続柄」 | 書かれていなければ空 |
| 電話番号・メールアドレス | 「電話番号」「メール」 | 英字と数字を書かれたとおりに。 直さない |
| 住所 | 「住所」 | 書かれていなければ空 |
| 入塾日 | 「入塾日」「開始月」 | 書かれた表記のまま |
| 受講講座 | 科目・コース・曜日の印(Apps Script がまとめたもの) | 印の組をそのまま写す |
| 口座振替の依頼書 | 「依頼書を提出した」の □ | 印がどちらにも無ければ unknown |
右端の列が、この構成でいちばん大事な区別です。 学校名とメールアドレスは、それらしく整えたくなる欄です。「○○中」を「○○市立○○中学校」に直すのは学校の一覧との照合の仕事で、AIの仕事ではありません。
| させないこと | 理由 |
|---|---|
| 必須の欄がそろっているかの判断 | 欄の一覧で決め、Apps Script が行う |
| 講座の選び方の正誤の判断 | 講座の一覧の学年と曜日で照合する |
| メールアドレスの「修正」 | よくあるドメインに寄せると、届かないアドレスになる |
| 学年や学校の推定 | 生年月日から学年を埋めると、書き漏れが消える |
| 口座振替の手続きの有無の推定 | □ の印だけで決める |
4行目がいちばん起きやすい失敗です。 学年の欄が空でも、生年月日があれば学年は計算できそうに見えます。AIに埋めさせると、保護者が書かなかったという事実が消え、留学や飛び級のような例外も見えなくなります。 学年の計算が必要なら、Apps Script が別の列に「生年月日から見た学年」として出し、書かれた学年と比べます。
指示内容を固定する
あなたは学習塾の本部で、保護者が手書きした入塾申込書を読み、
生徒台帳に写すための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。
【やること】
1. 書類が入塾申込書かを判断してください。
口座振替の依頼書、アンケート、別の塾の書類なら、
写さずに document_type を other にしてください。
2. 生徒の氏名・フリガナ・生年月日・学校名・学年、
保護者の氏名・続柄・電話番号・メールアドレス・住所、入塾日、
受講講座の印の組、兄弟姉妹の在籍、口座振替の依頼書の提出の印を写してください。
3. 読み取り結果の中の [MASKED] は伏せた値です。そのままにしてください。
【厳守事項】
- 文字は書かれたものをそのまま入れてください。
メールアドレスと電話番号の英字・数字を直さないでください。
- 学校名は書かれたとおりに写してください。正式な名前に直さないでください。
- 書かれていない欄は空にしてください。
生年月日から学年を、住所から学校を推し量って埋めないでください。
- 読みにくい字は、読めた文字のまま value に入れ、unclear を true にしてください。
- チェックボックスの印がどちらにも無いときは unknown にしてください。
- 記入がそろっているか、講座の選び方が正しいかについて書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。
【読み取り結果(キーと値の組、チェックボックス、全文。口座の番号と配慮の欄は伏せてあります)】{ocr_result}
【申込書の欄の一覧】{form_fields}
「メールアドレスの英字・数字を直さない」を明記しないと、AIはよくある綴りに寄せます。 「gmall」を「gmail」に直すのは親切に見えますが、保護者が本当にその綴りのアドレスを使っていれば、連絡が届かなくなります。 直す判断は、教室長が保護者に確かめてからです。
出力形式を固定する
Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、Interactions の response_format に JSON スキーマを渡すと、そのスキーマに従う応答を生成させられるとされ、enum で値の候補を限り、required で必須の項目を決められます。
{
"document_type": "enrollment_form | other",
"student": {
"name": { "value": "", "unclear": false },
"kana": { "value": "", "unclear": false },
"birth": { "value": "", "unclear": false },
"school": { "value": "", "unclear": false },
"grade": { "value": "", "unclear": false }
},
"guardian": {
"name": { "value": "", "unclear": false },
"relation": { "value": "", "unclear": false },
"phone": { "value": "", "unclear": false },
"email": { "value": "", "unclear": false },
"address": { "value": "", "unclear": false }
},
"start_date": { "value": "", "unclear": false },
"courses": [{ "subject": "", "level": "", "days": [""] }],
"sibling_enrolled": "yes | no | unknown",
"direct_debit_form": "submitted | not_submitted | unknown",
"evidence": [{ "field": "", "text": "", "confidence": 0 }]
}
1つ目の理由は、AIの仕事と点検の仕事を別の層に置けることです。 JSONはAIが埋め、必須の欄の点検と講座の照合は Apps Script が規則で行います。
| 状態 | 付ける条件(Apps Script が決める) |
|---|---|
complete | 必須の欄がそろい、unclear が無く、講座の照合と学校の照合が通る |
missing | 必須の欄のキーが見つかり、その近くに値が無い |
not_detected | 必須の欄のキーそのものが見つからない |
unreadable | 値はあるが unclear が立っている、または信頼度が基準を下回る |
course_conflict | 講座の対象の学年が書かれた学年と合わない、開講していない曜日に印がある |
school_unmatched | 学校名が学校の一覧のどれとも合わない、または候補が2つ以上ある |
debit_pending | direct_debit_form が submitted 以外 |
2つ目の理由は、差し戻しの一覧を状態ごとに分けて出せることです。 教室長に返すのは missing・not_detected・unreadable・course_conflict で、debit_pending は請求の担当へ、school_unmatched は本部の事務へと、見る人ごとに一覧を分けます。教室長に全部を返すと、本部で片付く問い合わせまで教室長の電話になります。
3つ目は、not_detected を空欄と決めつけずに済むことです。 Form Parser は空欄のキーと値の組を確実には読み取れないとされているので、キーが返ってこない欄は、教室長が原本を見て、空欄か読み取りの漏れかを決めます。 公式にも、構文として正しいJSONでも値はアプリケーションの側で検証するよう書かれています。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 教室の取込フォルダ | Apps Script の時間主導型トリガー | 新しい申込書のPDFを拾う |
| Document AI | API呼び出し | 項目名と値の組・チェックボックス・信頼度を返す |
| Gemini API | API呼び出し(構造化出力) | 伏せた後の読み取り結果から、台帳の項目への対応付け |
| 講座の一覧・学校の一覧 | スプレッドシートの読み取り | 講座の矛盾と学校名の照合 |
| 生徒台帳 | スプレッドシートへの書き込み | 下書きの列にだけ書く。確定の列は本部の事務が移す |
| 差し戻しの一覧 | スプレッドシートへの書き込み | 教室ごと・見る人ごとに、受付番号と不足の内容 |
| チャット | 教室ごとのスペースへの通知 | 「差し戻しが○件あります」と一覧へのリンクだけ |
チャットの通知には、生徒の名前も不足の内容も書きません。 件数と一覧へのリンクだけにし、中身は権限のある一覧で見てもらいます。 教室のチャットには講師のアルバイトも入っていることがあるためです。
人が確認する
人が見るのは、差し戻しの一覧と、complete 以外の行だけです。 complete の行は、本部の事務が一覧で流し見て確定の列に移します。全件を原本から読み直す設計にすると、第10章の6.0時間には収まりません。
- 教室長が差し戻しの一覧を見る …
missingとcourse_conflictは保護者に聞き直します。保護者が教室にいれば、その場で書き足してもらいます not_detectedとunreadableは原本を見る … 書かれていれば下書きに入れ、空欄なら保護者に聞きます- 本部の事務が
school_unmatchedを決める … 学校の一覧に足すか、候補から選びます - 請求の担当が
debit_pendingを見る … 依頼書が届くまで、最初の月の請求の方法を決めます - 本部の事務が確定する … 確かめ終えた行を台帳の確定の列に移します
1番目を受付の日のうちに回すことが、この構成の目的です。 翌週の問い合わせでは、保護者はもう申込書に何を書いたか覚えていません。
目標は、120件をならして1件3分です。 差し戻しが要るのは2割前後という想定で、それより多い月は、申込書の様式か教室の複合機の設定に問題があります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 続柄などを○で囲んでいる | ラジオボタンは対象外。unknown として人へ。 様式の次の版で □ に直す |
| 必須の欄のキーが返ってこない | not_detected。空欄と決めつけず、原本で確かめる |
| 裏面がスキャンされていない | ページの数で弾き、教室長に読み込み直しを頼む |
| 講座の行で印が複数のコースに付いている | course_conflict。どちらかを選ばず教室長へ |
| 口座振替の依頼書が申込書と一緒にスキャンされた | 依頼書のページを Document AI に渡さず、別の保管場所へ移して請求の担当に知らせる |
| 入塾申込書でない書類 | document_type が other。点検せず教室長へ |
| APIが応答しない、6分を超える | 取込フォルダに残す。処理済みへ移すのは書き込み成功時だけ |
5行目がいちばん大事な例外です。 口座振替の依頼書には口座の番号と届出印があり、申込書と同じ流れに乗せると、伏せる対象の外から番号が渡ります。 依頼書は教室で別に扱い、取込フォルダに入れないよう教室長に周知します。
記録を残す
- 元の申込書のPDFと、教室コード・受付日・スキャンした日時
- Document AI が返した
DocumentのJSONの全文 - Gemini API に渡した伏せた後の読み取り結果と、返ってきたJSON
- Apps Script が付けた状態と、そのとき照らした講座の一覧の版
- 教室長が聞き直した記録(いつ、どの欄を、誰が)と、本部が確定した日時
04実装レベルの3段階
半自動化で、1件10分が6分程度になります。 打ち込みは下書きの確認に変わりますが、講座の照合と教室長への問い合わせが本部の手作業のまま残ります。本格構成で3分になり、この段階が本記事の想定です。 差が大きいのは、問い合わせが本部を通らず、教室長に直接、受付の日のうちに届くからです。 段階を飛ばさないでください。 半自動化の下書きを1か月分見ると、not_detected の多い欄と、○で囲む欄が分かります。申込書の次の版でそこを直してから本格構成に進むほうが、差し戻しの空振りが減ります。
05工数削減シミュレーション
導入後 120件 × 3分 ÷ 60 = 6 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 教室が複数あり、各教室で受け取った手書きの入塾申込書を本部の事務が生徒台帳へ打ち込んでいる学習塾。記入漏れや講座の選び間違いに気づくのが初回の授業や最初の引落しの直前で、教室長への問い合わせが行き来している場合。申込書の様式が全教室で共通で、□ に印を付ける欄が多い場合。Google Workspace を使っている場合。
- 入塾の申込みがほとんどウェブのフォームに移り、紙の申込書が月に数件しか無い場合。教室が1つで、教室長が自分で台帳に入れている場合。申込書の様式が教室ごとにばらばらで、共通の欄の一覧を作れない場合。なお、受講講座の案内や料金の説明、入塾を受け入れるかの判断は、この構成では代替できません。
07最小構成で試す方法
- 先月の申込書から、字の癖の強いもの、講座の選び間違いがあったものを含めて20枚を選ぶ
- 生徒と保護者の氏名・住所・電話番号・メールアドレスと、口座の欄を紙で隠してからスキャンする
- 20枚を1枚ずつ、手元のAIサービスの画面に貼り付ける
- 「この入塾申込書から、学校名・学年・入塾日・受講講座(科目・コース・曜日)・兄弟姉妹の在籍・口座振替の依頼書の提出の印を表にしてください。書かれたとおりに写し、書かれていない欄は空にし、ほかの欄から推し量らないでください」と指示する
- 出てきた表を、台帳にすでに入っている値と1欄ずつ突き合わせる
| 出てきた内容 | 判断 |
|---|---|
| 印と値が正しく写り、空欄が空のままだった | OCRとワークフローの連携に進む |
| 学校名を正式な名前に直した、学年を推し量った | 指示の書き方で直る。構成は有効 |
| □ の印や手書きの字が読めない枚数が多い | 申込書の様式と複合機の設定が先。 AIの問題ではない |
2番目を省かないでください。 試す段階でも、生徒と保護者の個人の情報を外のサービスへ出さない手順を最初から作ります。 氏名を隠しても、講座の印と学年の読み取りは確かめられます。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| キーが返ってこない欄を空欄と決めつける | missing と not_detected を分ける。 空欄の組は確実に読めないとされている |
| 生年月日から学年を埋める | 書かれた学年だけを写させ、計算した学年は別の列に |
| メールアドレスをよくある綴りに直す | 「直さない」と明記し、unclear を立てさせる |
| ○で囲む欄が読めない | ラジオボタンは対象外。様式を □ に直す |
| 講座の印を行ごとにまとめられない | 位置の規則でまとめ、複数のコースに印があれば course_conflict |
| 口座振替の依頼書が一緒に流れる | 取込フォルダに入れない運用と、ページの見出しでの検知 |
| 裏面のスキャン忘れ | ページの数で先に弾く |
| 差し戻しが全部教室長に行く | 状態ごとに見る人を分ける |
| チャットの通知に個人の情報が出る | 件数とリンクだけにする |
上の3行が、この構成の失敗のほとんどです。 どれも「書かれていないものを埋める」か「書かれたものを整える」誤りで、台帳の値が、保護者が書いたものと違ってしまいます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 子どもの氏名・生年月日・学校名、保護者の氏名・連絡先・住所、兄弟姉妹の在籍、そしてアレルギーなど配慮が要ることの情報と、口座振替の手続きです。
- 利用目的を申込書に明示する … 個人情報保護委員会のガイドラインでは、申込書など本人から直接書面で個人情報を取得する場合、あらかじめ本人に利用目的を明示しなければならないとされ、申込書・契約書等の例が挙げられています。申込書の利用目的の欄に、生徒台帳の作成と連絡に使うことを書いておきます
- 未成年の生徒の情報は保護者の同意で扱う … 同じガイドラインでは、未成年者が同意の結果を判断できる能力を有していない場合などは、親権者や法定代理人等から同意を得る必要があるとされています。申込書は保護者が書き、保護者の署名を得ます
- Gemini API は有料の枠で使う … 公式の利用規約では、有料のサービスではプロンプトと応答を製品の改善に使わないとされる一方、無料のサービスでは改善に使われ、人が読むことがあるとされ、機密の情報や個人情報を送らないよう求めています。請求先のアカウントを付けたプロジェクトから呼びます
- 口座の番号と配慮の欄を生成AIに渡さない … どちらも Apps Script が伏せてから渡します。口座振替の依頼書は取込フォルダに入れません
- チャットと差し戻しの一覧に出す情報を絞る … 通知は件数とリンクだけ、一覧は教室長と本部の事務だけが見られる権限にします
- この構成は入塾の受け入れと講座の案内を代替しない … どの講座を勧めるか、矛盾のある申込みをどう直すかは、教室長が保護者と話して決めることです。 この構成が出すのは、申込書に何が書かれていたかという事実と、規則の照合の結果だけです
誤りが起きた場合のリスクは、読み違えた講座や連絡先で台帳が確定することと、書いた保護者への誤った聞き直しの2つです。 前者はAIに整えさせないことと本部の確定で、後者は not_detected を分けることで防ぎます。
10まず何から始めるか
1週目:講座の一覧と申込書の欄の一覧を整える
講座の一覧に対象の学年と開講の曜日の列を足し、申込書の欄の名前と必須かどうかを一覧にします。申込書に ○ で囲む欄があれば、□ に直した新しい版を作り、利用目的の欄の書き方も見直します。
2週目:20枚で試す
先月の申込書から20枚を選び、個人の情報を隠してから手元のAIサービスで表にさせます。学年や学校名を整えていないか、□ の印を正しく読めているかを最優先で見ます。
3週目:教室の複合機と取込フォルダをそろえる
6教室の複合機を300dpi・PDFで共有ドライブの教室ごとの取込フォルダに保存する設定にします。口座振替の依頼書は取込フォルダに入れないことを、教室長に周知します。
4週目:取込フォルダから台帳の下書きまでをつなぐ
Apps Script で取込フォルダを見張り、Document AI を呼び、口座の番号と配慮の欄を伏せて Gemini API を呼び、生徒台帳の下書きに書き出すところまで作ります。この時点では点検をせず、写した値と伏せた後のテキストだけを見ます。
2か月目: 必須の欄の点検、講座と学校の照合、見る人ごとの差し戻しの一覧とチャットの通知を足します。3か月目以降: 1件10分が何分になったかを実測します。記入漏れと講座の矛盾が、申込みを受けた日のうちに教室長へ返るようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Form Parser がOCRのテキストに加えてキーと値のペア(エンティティとチェックボックス)、表、一般的なエンティティを抽出すること。言語の一覧で日本語(ja)が手書きに対応する言語として示されていること | Google Cloud: Processor list | 2026-10-06 |
| チェックボックスのモデルがラジオボタンに対応しないこと。値の入っていないキーと値の組(空欄の用紙など)を確実には読み取れないこと | Google Cloud: Form Parser | 2026-10-06 |
formFields が fieldName と fieldValue を持ち、チェックボックスが valueType の filled_checkbox/unfilled_checkbox で返ること。textAnchor と信頼度が返ること | Google Cloud: Handle the processing response | 2026-10-06 |
| 対応形式が PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などであること。スキャンは最低200dpiが望ましく300dpi以上が一般に最もよいこと。非可逆の形式で精度が落ちうること | Google Cloud: Supported files | 2026-10-06 |
Interactions の response_format に JSON スキーマを渡して応答の形を固定でき、enum と required を使えること。値はアプリケーションで検証すべきこと | Gemini API: Structured outputs | 2026-10-06 |
| 有料サービスではプロンプトと応答を製品の改善に使わず、無料サービスでは改善に使われ人が読むことがあり、機密の情報や個人情報を送らないよう求めていること | Gemini API 追加利用規約 | 2026-10-06 |
| Apps Script の1回の実行が6分までであること | Apps Script: Quotas for Google Services | 2026-10-06 |
| 本人から直接書面に記載された個人情報を取得する場合はあらかじめ利用目的を明示しなければならず、申込書・契約書等が事例に挙げられていること。未成年者等が判断できる能力を有していない場合などは親権者や法定代理人等から同意を得る必要があること | 個人情報保護委員会: 個人情報の保護に関する法律についてのガイドライン(通則編) | 2026-10-06 |
申込書の利用目的の書き方と、生徒・保護者の情報の扱いは、自社の個人情報の取扱いの規程に従って決めてください。 本記事は各製品と個人情報保護委員会の公式ページで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0593)についてのご相談はこちらから。
