社会保険労務士事務所で、顧問先に届く標準報酬の決定・改定の通知書を読み取り、社員台帳の標準報酬月額と照らして、台帳の更新漏れと給与計算への反映の要否を拾う
顧問先に届く標準報酬の決定・改定の通知書を Azure AI Document Intelligence で読み取り、被保険者ごとの標準報酬月額と改定年月を事務所の社員台帳と照らします。台帳の更新漏れと、給与計算で保険料を変える月を一覧にします。
- 生成AI
- Azure OpenAI Service/Claude/Gemini
- AIサービス
- Azure AI/Google Document AI
- 対象業界
- 介護/士業/小売/製造
- 対象部門
- 人事
- 対象業務
- 内容確認・チェック/台帳・マスタ管理
- 主な課題
- 入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/工数削減/機会損失防止
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 電子申請の結果と、顧問先から送られてきた通知書のファイルを、担当者がそれぞれ受け取る
- 通知書を開き、どの顧問先の、どの被保険者の通知かを確かめる
- 社員台帳を開き、被保険者ごとに健康保険と厚生年金保険の標準報酬月額、改定年月を見比べる
- 台帳と違えば、届出の控えを開いて、届けた報酬月額と決定の結果を比べる
- 台帳を直し、改定年月から保険料を変える月の給与を考える
- 給与計算の担当に、控除額を変える従業員と月を連絡する
- 届出をしたのに通知書が届いていないものは、担当者が覚えていれば問い合わせる
- 人顧問先から届いた通知書のファイルを、顧問先ごとの受領フォルダへ入れる。電子申請の結果も同じフォルダへ保存する
- 自動ファイルの保存をきっかけに中継の処理が動き、形式・ページ数・画像の大きさを確かめる
- 自動Azure AI Document Intelligence のレイアウトモデルで、通知書の文字と表を読み取る
- 自動生成AIが、通知書の種類、事業所、被保険者ごとの標準報酬月額(健保・厚年)と改定年月を項目に取り出す
- 自動中継の処理が、被保険者整理番号で社員台帳の行を引き、値を見比べる
- 自動届出の控えの一覧と照らし、`match` / `ledger_outdated` / `differs_from_filing` / `not_in_ledger` / `unreadable` を付ける
- 自動控除の方式と改定年月から、保険料を変える給与の月を計算し、締めを過ぎていれば差額の調整に印を付ける
- 自動届出をしたのに通知書が届いていないものを、毎週一覧にする
- 人担当者が `match` 以外の行を確かめ、台帳の更新を承認する
- 人担当者が、給与計算の担当へ控除額を変える従業員と月を連絡する
各工程の詳しい説明を読む
- 電子申請の結果と、顧問先から送られてきた通知書のファイルを、担当者がそれぞれ受け取る
- 通知書を開き、どの顧問先の、どの被保険者の通知かを確かめる
- 社員台帳を開き、被保険者ごとに健康保険と厚生年金保険の標準報酬月額、改定年月を見比べる
- 台帳と違えば、届出の控えを開いて、届けた報酬月額と決定の結果を比べる
- 台帳を直し、改定年月から保険料を変える月の給与を考える
- 給与計算の担当に、控除額を変える従業員と月を連絡する
- 届出をしたのに通知書が届いていないものは、担当者が覚えていれば問い合わせる
(a)1行ずつ見比べている。 通知書の1枚には何人分もの行が並び、台帳は別の画面です。行を目で追って、等級の数字と金額を左右で見比べる作業が、毎月数百行あります。 健康保険と厚生年金保険で標準報酬月額が違う人(上限や下限に当たる人)で、取り違えが起きます。
(b)届く経路で手順が違う。 電子申請の結果は担当者が見落としにくい一方、顧問先から写真で届いた通知書はメールに埋もれて処理が遅れます。 誰がどの通知書を処理したかも、記録に残っていません。
(c)保険料の変更が給与に遅れて入る。 5番目の「どの月の給与で変えるか」は担当者が頭の中で考えており、通知書の到着が遅れた月に、変更が1か月ずれて入ることがあります。 後から差額を精算するのは、顧問先の従業員への説明も含めて重い仕事です。
(d)届いていない通知書に気づかない。 7番目は担当者の記憶頼みで、届出をした一覧と届いた通知書を突き合わせる仕組みがありません。
- 【人】 顧問先から届いた通知書のファイルを、顧問先ごとの受領フォルダへ入れる。電子申請の結果も同じフォルダへ保存する
- 【自動】 ファイルの保存をきっかけに中継の処理が動き、形式・ページ数・画像の大きさを確かめる
- 【自動】 Azure AI Document Intelligence のレイアウトモデルで、通知書の文字と表を読み取る
- 【自動】 生成AIが、通知書の種類、事業所、被保険者ごとの標準報酬月額(健保・厚年)と改定年月を項目に取り出す
- 【自動】 中継の処理が、被保険者整理番号で社員台帳の行を引き、値を見比べる
- 【自動】 届出の控えの一覧と照らし、
match/ledger_outdated/differs_from_filing/not_in_ledger/unreadableを付ける - 【自動】 控除の方式と改定年月から、保険料を変える給与の月を計算し、締めを過ぎていれば差額の調整に印を付ける
- 【自動】 届出をしたのに通知書が届いていないものを、毎週一覧にする
- 【人】 担当者が
match以外の行を確かめ、台帳の更新を承認する - 【人】 担当者が、給与計算の担当へ控除額を変える従業員と月を連絡する
9番目が、この設計の分かれ目です。人が見るのは全行ではありません。 台帳が通知書どおりの行は件数だけ見て終わりにし、違いのある行と読み取れなかった行だけに時間を使います。
6番目で differs_from_filing を分けているのが、第1章の要点です。 届けた報酬月額から出るはずの等級と違う結果が出たら、台帳を直す前に届出の控えを確かめます。
02今回想定するシステム構成
通知書(電子申請の結果・顧問先からのスキャンや写真) │ 顧問先ごとの受領フォルダへ保存 ▼【トリガー】ファイルの保存 Azure Functions(中継の処理) ├──▶ 形式・ページ数・画像の大きさの確認 ▼ Azure AI Document Intelligence(レイアウトモデル、Markdown出力) │ 文字・表・単語ごとの信頼度 ▼ Azure OpenAI(Microsoft Foundry) ── 構造化出力 │ 通知書の種類/事業所/被保険者ごとの標準報酬月額・改定年月 ▼ Azure Functions ── 社員台帳・届出の控えとの照合、保険料を変える月の計算 ▼ 照合結果の一覧 ──【担当者が違いのある行だけ確認・承認】 ├──▶ 社員台帳の更新 └──▶ 給与計算の担当への連絡
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Azure AI Document Intelligence(レイアウトモデル) | Google Document AI |
| 生成AI | Azure OpenAI(Microsoft Foundry)(構造化出力で表の行を項目に取り出す) | Claude API、Gemini API |
| 連携 | Azure Functions(台帳の照合、保険料を変える月の計算) | Azure Logic Apps |
| 保管 | 事務所のファイルサーバー(通知書の原本と照合の控え) | Azure Blob Storage |
| 台帳 | 既存の社員台帳と給与計算ソフト | ― |
社員台帳と給与計算ソフトは、新しく足すものではありません。 この構成は台帳の更新の候補を出すところまでで、台帳と給与計算ソフトへは担当者の承認の後に反映します。最初の準備は、社員台帳に「控除の方式」と「給与の締め日」の列を足すことです。 これが無いと、保険料を変える月が計算できません。
読み取りには、レイアウトモデル(prebuilt-layout)を使います。 文字に加えて表と選択マークを取り出し、表の各セルには行と列の番号と、見出しの行かどうかが付きます。通知書は被保険者ごとの行が並ぶ表なので、表の構造のまま取り出せることが効きます。 outputContentFormat=markdown を指定するとMarkdownで返り、v4.0(2024-11-30)では表がHTMLの表で表されます。
日本語は、印刷の文字も手書きの文字も対応言語に入っています。 通知書は印刷ですが、顧問先が受付日や担当者名を手書きで書き込んで送ってくることがあります。入力はPDFと画像(JPEG/JPG、PNG、BMP、TIFF、HEIF)で、PDFとTIFFは最大2,000ページ、有料(S0)レベルで500MBまでです。
03どうやって実装するのか
処理の起点を決める
受領フォルダにファイルが保存されたことを起点にします。 フォルダは顧問先ごとに分け、どの顧問先の通知書かをフォルダで決めます。 通知書の事業所名から顧問先を推し量ると、同じ名前の会社や、支店ごとの事業所で取り違えます。
経路は2つあります。電子申請の結果は、電子申請のソフトから担当者が保存します。 顧問先から届いたスキャンや写真は、メールの添付を担当者が受領フォルダへ移します。どちらも同じフォルダに入れた時点から先は区別しません。
もう1つのトリガーは、毎週月曜の定時実行です。 届出の控えの一覧のうち、提出から一定の日数がたっても通知書の照合が済んでいないものを一覧にします。第3章の(d)を拾う仕組みです。処理が終わったファイルは処理済みフォルダへ移し、受領フォルダに残っている数をそのまま未処理の数にします。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 通知書のファイル | PDFまたは画像。受け取った日時と経路 | 受領フォルダ |
| 読み取り結果 | 文字、表のセル(行・列の番号と見出しかどうか)、単語ごとの信頼度 | Azure AI Document Intelligence |
| 社員台帳 | 被保険者整理番号、氏名、健保・厚年の標準報酬月額、改定年月、控除の方式 | 顧問先ごとのスプレッドシート |
| 届出の控えの一覧 | 届出の種類、提出日、被保険者、届けた報酬月額、見込みの等級 | 事務所の手続きの管理表 |
| 顧問先の情報 | 事業所整理記号、給与の締め日と支払日 | 顧問先の一覧 |
質を決めるのは、届出の控えの一覧です。 ここに見込みの等級が無いと、通知書と台帳が違ったときに、どちらが正しいかを決める材料がありません。月額変更届を出すときに、事務所が計算した見込みの等級を必ず記録します。
給与の締め日と支払日は、保険料を変える月の計算に使います。 顧問先ごとに違い、同じ顧問先でも部門によって違うことがあります。
データの取得方法を決める
読み取りは、中継の処理からレイアウトモデルを呼ぶだけです。
| 指定するもの | 値 | 理由 |
|---|---|---|
| モデル | prebuilt-layout | 表の構造(行・列・見出し)が要る |
outputContentFormat | markdown | 生成AIに表の形のまま渡せる |
| 言語の指定 | しない | 公式の案内では、言語が確かでない限り指定しないほうがよいとされている |
| 返ってくる値 | content(Markdown)、tables(セルごとの rowIndex・columnIndex・kind)、pages の単語ごとの confidence | 表の取り出しと、読み取りの確かさの判定 |
言語を指定しないのは、公式の注意に従うためです。 言語を指定すると、そのモデルだけを使うよう強制し、文字が不完全になったり誤ったりすることがあるとされています。通知書には英数字の整理記号と日本語が混在します。
読み取りの確かさは、セルに入っている単語の confidence で見ます。 中継の処理が、セルの文字の範囲(spans)に重なる単語を引き、その最小値をセルの信頼度とします。等級と金額のセルは、1文字の読み違いがそのまま保険料の違いになるので、ここを数値で押さえます。
社員台帳は被保険者整理番号で引きます。氏名では引きません。 通知書の氏名はカナと漢字の表記が台帳と違うことがあり、同姓同名もいます。
電子申請の経路で届く結果も、いったんPDFとして保存してから同じ読み取りに通します。 経路ごとに別の取り込み方を作ると、片方だけ様式の変更に追随できない期間ができます。読み取りの手順を1本にしておけば、直す場所も1か所です。 届出の控えの一覧は、手続きの管理表から顧問先と被保険者整理番号で引き、見込みの等級と提出日を照合の材料にします。
AIへ渡す前に整形する
- 形式の確認 … PDFまたは画像であることを確かめます
- ページ数とサイズの確認 … PDFとTIFFは最大2,000ページ、有料(S0)レベルで500MBが上限です
- 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります。範囲外は撮り直しを頼みます
- 文字の高さの確認 … 抽出する文字の最小の高さは、1024×768の画像で12ピクセルです。スマートフォンで遠くから撮った写真はこれを下回ります
- パスワードの確認 … パスワードでロックされたPDFは、提出前にロックを解除する必要があります
- ページの抜けの確認 … 通知書に「1/2」のようなページ表示があれば、そろっているかを見ます
- 重複の確認 … 同じ顧問先・同じ被保険者・同じ改定年月の照合が済んでいれば、二重に処理しません
4番目と6番目は、顧問先から写真で届く通知書のためにあります。 遠くから撮った写真の金額の欄は、文字の高さの下限に近くなります。2ページ目が抜けた通知書は、1ページ目の行だけが照合されて「全員済み」に見えます。
AIに処理させる
させるのは、読み取り結果の表から、被保険者ごとの行を項目に取り出すことだけです。 照合も保険料を変える月の計算も、中継の処理が規則で行います。
| 取り出すもの | やり方 | 判断できないときの扱い |
|---|---|---|
| 通知書の種類 | 表題から、資格取得時の決定・標準報酬の決定・改定不該当・賞与などを当てる | 決まらなければ other |
| 事業所 | 事業所整理記号と事業所名 | 読めなければ null |
| 被保険者整理番号 | 行ごとに、表のセルの文字をそのまま | 読めなければ null |
| 健保・厚年の標準報酬月額 | 列の見出しを根拠に、健保と厚年を分けて取り出す | 見出しで決まらなければ column_unclear |
| 改定(適用)年月 | 元号と年月の文字をそのまま | 西暦への変換はしない |
| 単位 | 列の見出しにある単位(円・千円)をそのまま | 見出しに無ければ null |
健保と厚年を列の見出しで分けさせるのが要です。 公式の案内には、厚生年金保険の上限が32等級・650千円、健康保険の上限が50等級・1,390千円の例が載っており、上限や下限に当たる人は2つの値が違います。 位置で取り出すと、2つの列を取り違えたまま台帳と一致したように見えることがあります。
| させないこと | 理由 |
|---|---|
| 台帳との照合 | 規則で決まる比較。AIに台帳を見せると、台帳の値に寄せて読む |
| 元号から西暦への変換 | 中継の処理が表で変換する。AIの換算の誤りを入れない |
| 単位の換算(千円→円) | 単位の取り違えは保険料の桁違いになる |
| 読めない数字の補い | 等級表から近い金額に寄せない |
| 随時改定に当たるかの判断 | 社会保険の判断は担当者が行う |
1行目が、いちばん効く設計です。 AIに台帳の値を渡して「違いがあるか」を聞くと、読みにくい数字を台帳の値に寄せて読み、違いが消えます。
指示内容を固定する
あなたは社会保険労務士事務所で、日本年金機構から届いた通知書の
読み取り結果から、被保険者ごとの行を取り出す立場です。
読み取り結果に書かれている文字だけを使ってください。推測で補わないでください。
【取り出す項目】
1. notice_type … 表題から次のいずれか:
acquisition(資格取得時の決定)/ standard(標準報酬の決定)/
not_applicable(改定不該当)/ bonus(賞与の決定)/ other
2. office … 事業所整理記号と事業所名
3. rows … 被保険者ごとの行。insured_no、name、health_amount、
pension_amount、effective_era_ym、unit
【厳守事項】
- 健康保険と厚生年金保険の金額は、列の見出しを根拠に分けてください。
見出しで決められないときは、両方を null にして column_unclear を true にしてください。
- 金額と番号は、セルの文字をそのまま value に入れてください。
桁を補う、近い等級の金額に直す、単位を換算することをしないでください。
- 年月は元号のまま書いてください。西暦に直さないでください。
- 単位は列の見出しにある単位をそのまま書いてください。無ければ null です。
- 各行に、根拠にした表の行番号 row_index をそのまま書いてください。
- 台帳と合っているか、届出が正しかったかは書かないでください。
- 標準報酬の通知書でないと判断したときは、rows を空にし、notice_type を other にしてください。
【読み取り結果(Markdown)】{layout_markdown}
台帳を渡していないことに注意してください。 渡すのは読み取り結果だけです。照合は、AIの出力を受け取った後に中継の処理が行います。 AIの役割を「表の行を項目に分けること」に絞ると、AIの誤りは「読み違い」だけになり、セルの信頼度で拾えます。
「近い等級の金額に直さない」を明記しないと、等級表に無い金額を等級表の金額に寄せます。 読み違いで等級表に無い数字が出たなら、それは読み違いの印として残すべき情報です。
出力形式を固定する
次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、このスキーマに従わせます。
{
"notice_type": "acquisition | standard | not_applicable | bonus | other",
"office": { "code": null, "name": null },
"rows": [
{ "row_index": 0, "insured_no": null, "name": null,
"health_amount": null, "pension_amount": null,
"effective_era_ym": null, "unit": null, "column_unclear": false }
]
}
構造化出力では、すべての項目を必須にし、省略したいものは null との共用体型で表します。 オブジェクトには additionalProperties: false が必要です。読めなかった値を空文字ではなく null で返させると、照合の側で「読めなかった」を機械で拾えます。
中継の処理は、この出力に次の値を足して照合の結果を作ります。
| 結果 | 条件 | 担当者の対応 |
|---|---|---|
match | 台帳の健保・厚年の金額と改定年月が通知書と同じ | 件数だけ見る |
ledger_outdated | 通知書と届出の見込みの等級が同じで、台帳だけが古い | 台帳の更新を承認する |
differs_from_filing | 通知書が届出の見込みの等級と違う | 届出の控えと報酬の集計を確かめる |
not_in_ledger | 被保険者整理番号が台帳に無い | 台帳の登録漏れを確かめる |
unreadable | 金額・番号のセルの信頼度がしきい値未満、または column_unclear | 通知書の画像で確かめる |
保険料を変える月は、規則で計算します。 控除の方式が「前月分を控除」の顧問先なら、改定年月の翌月に支払う給与から控除額を変えます。その給与の締め日を通知書の受領日が過ぎていれば retro_adjust: true を付けます。 この判断にAIは関わりません。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 受領フォルダ | 中継の処理のトリガー | ファイルの保存を検知する |
| Azure AI Document Intelligence | API呼び出し | 文字・表・単語の信頼度を返す |
| Azure OpenAI | API呼び出し(構造化出力) | 被保険者ごとの行を項目に取り出す |
| 社員台帳 | 読み取り、承認後の更新 | 照合と、承認された行の更新 |
| 届出の控えの一覧 | 読み取り | 見込みの等級と、届いていない通知書の検出 |
| 給与計算の担当 | 照合結果の一覧を共有 | 控除額を変える従業員と月 |
社員台帳への書き込みは、担当者が承認した行だけです。 ledger_outdated でも自動では書き込みません。台帳は給与計算と保険料の根拠で、誤った更新はそのまま顧問先の従業員の給与に出ます。
給与計算ソフトへは、この構成から書き込みません。 控除額の変更は、給与計算の担当が月の処理の中で入れます。この構成が出すのは「誰の、どの月の給与で変えるか」の一覧までです。
人が確認する
人が開くのは match 以外の行だけです。 順番を決めておきます。
differs_from_filingを最初に見る … 届出の控えと、報酬の集計を確かめます。届出の誤りなら、台帳を直す前に訂正の手続きを検討しますunreadableを画像で確かめる … セルの信頼度が低かった金額と番号を、通知書の画像で見ますledger_outdatedを承認する … 通知書と見込みの等級が同じことを確かめて、台帳の更新を承認しますretro_adjustの行を給与計算の担当へ伝える … 差額の調整が要る従業員と月を、顧問先への説明とあわせて伝えます
1番目を後回しにしないでください。 届けた内容と違う結果が出たことは、報酬の集計の誤りか、届出の記入の誤りか、事務所の見込みの計算の誤りのどれかです。台帳だけ直して終わると、同じ誤りが次の届出でも起きます。
承認した担当者の名前は、行ごとに記録します。 手続きの担当と給与計算の担当が別の人なら、承認した人と連絡を受けた人が後からたどれることが、差額の精算で効いてきます。
目標は、480行をならして1行1.5分です。 違いのある行が1割台という想定で、それより多い月は、写真の通知書が増えているか、見込みの等級の記録が抜けています。
例外に対処する
| 起きること | 対応 |
|---|---|
| 写真が傾いている・影が入っている | unreadable が増える。顧問先にスキャンでの送付を頼む |
| 2ページ目が抜けている | ページ表示で検知し、顧問先へ残りのページを頼む |
| パスワード付きのPDF | 提出前にロックを解除する必要がある。担当者が解除して入れ直す |
| 文字が小さすぎる | 1024×768の画像で12ピクセルが下限。撮り直しを頼む |
| 健保と厚年の列が見出しで分けられない | column_unclear として unreadable に回す |
| 被保険者整理番号が台帳に無い | not_in_ledger。資格取得の台帳登録の漏れをまず疑う |
| 届出をしたのに通知書が届かない | 毎週の一覧に出し、担当者が顧問先と年金事務所に確かめる |
| 標準報酬の通知書でない書類 | notice_type: other として担当者へ戻す |
| 読み取りのAPIが応答しない | 受領フォルダに残す。処理済みへ移すのは成功したときだけ |
上から2行目は、気づきにくい失敗です。 1ページ目の被保険者がすべて match だと、通知書全体が済んだように見えます。ページ表示を見て、そろっていない通知書は照合を保留にします。
記録を残す
- 元の通知書のファイルと、受け取った日時・経路(電子申請/顧問先からの転送)
- 読み取り結果のJSONの全文と、セルごとの信頼度
- 生成AIの出力と、照合の結果
- 照合のときに参照した社員台帳の行の値 … 更新前の値を残す
- 担当者が承認・修正した記録 … 誰が、いつ、どの行を、何から何に変えたか
- 保険料を変える月の計算結果と、
retro_adjustの有無 - 顧問先ごとの
unreadableの発生数
4つ目で更新前の値を残すのは、差額の精算に要るからです。 控除額を変えた月が後で問題になったとき、いつ台帳が変わったかが分からないと、精算の範囲が決まりません。
最後の行は、顧問先への依頼の材料になります。 特定の顧問先だけ unreadable が多いなら、写真で送っている可能性が高く、スキャンでの送付を頼む根拠になります。
04実装レベルの3段階
最小構成では、件数がさばけません。 1枚ずつ貼り付けるので、月480行には使えません。確かめるための段階です。 半自動化で、1行5分が3分程度になります。 行の一覧はできますが、台帳と見比べる作業と、保険料を変える月を考える作業が残ります。本格構成で1.5分になり、この段階が本記事の想定です。 差が大きいのは、照合と月の計算が、1行ずつの手作業だからです。 段階を飛ばさないでください。 半自動化の一覧を1か月見ると、写真で届く顧問先と、見込みの等級が記録されていない届出が分かります。そこを直してから照合を足すほうが、differs_from_filing の空振りが減ります。
05工数削減シミュレーション
導入後 480件 × 1.5分 ÷ 60 = 12 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 顧問先が100社を超え、資格取得や随時改定の通知書が毎月まとまって届く社会保険労務士事務所。顧問先ごとに社員台帳を持ち、給与計算の代行や保険料の控除額の連絡までを受けている場合。通知書が電子申請の公文書と、顧問先から転送される紙のスキャンに分かれて届き、確認の手順が人によって違う場合。
- 顧問先が数社で、通知書が月に数枚しか届かない事務所。社員台帳を持たず、届出の代行だけを受けている場合。給与計算ソフトに通知の内容を取り込む仕組みがすでにあり、手での照合が発生していない場合。なお、随時改定に当たるかどうか、届出の内容が正しかったかという社会保険の判断は、この構成では代替できません。
07最小構成で試す方法
- 先月に処理した通知書から20枚を選ぶ(健保と厚年の金額が違う人の載ったもの、写真で届いたものを入れる)
- その20枚について、当時の台帳の更新と、給与計算の担当への連絡の内容を確かめておく
- Document Intelligence Studio のレイアウトで20枚を読み取り、Markdownの結果を手元のAIサービスに貼り付ける
- 「この読み取り結果から、被保険者ごとに整理番号・氏名・健康保険の標準報酬月額・厚生年金保険の標準報酬月額・適用年月を、列の見出しを根拠に取り出してください。読めない値は空にし、金額を直さないでください」と指示する
- 取り出した行を、当時の台帳の値と突き合わせる
20枚は必ずやってください。 ワークフローを組む前に、「健保と厚年を列で取り違えないか」と「写真でどこまで読めるか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 当時の台帳の値と一致した | 中継の処理と台帳の照合に進む |
| 健保と厚年を取り違えた | 指示と見出しの扱いで直るか試す。直らなければ列の位置の対応表を足す |
| 写真の通知書で読めない行が多い | 受け取り方が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 その場合は、顧問先にスキャンで送ってもらった同じ通知書で読み直し、どこまで変わるかを見てください。読めない原因が写真なら、顧問先への依頼の文面を先に作ります。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 健保と厚年の金額を取り違える | 列の見出しを根拠に分ける。 決まらなければ column_unclear |
| 読みにくい数字が台帳の値に寄る | AIに台帳を渡さない。 照合は中継の処理で行う |
| 等級表に無い金額が等級表の金額に直る | 補いを禁じる。等級表に無い金額は読み違いの印として残す |
| 台帳が古いだけか、届出と違うのかが分からない | 届出の控えに見込みの等級を記録しておく |
| 保険料を変える月がずれる | 控除の方式と締め日を台帳に持たせ、規則で計算する |
| 2ページ目が抜けて「全員済み」に見える | ページ表示でそろっているかを確かめる |
| 写真の通知書が読めない | 文字の高さの下限を下回る。スキャンで送ってもらう |
| 顧問先を事業所名で推し量って取り違える | 受領フォルダを顧問先ごとに分ける |
| 氏名で台帳を引いて別人に当たる | 被保険者整理番号で引く |
| 元号の変換を誤る | 中継の処理の表で変換する。AIに変換させない |
| 届いていない通知書に気づかない | 届出の控えと照合の結果を毎週突き合わせる |
上の3行が、この構成の失敗のほとんどです。 どれも「それらしい値で一致してしまう」という同じ形をしています。一致した行は人が見ない設計なので、誤って一致した行は誰にも見つかりません。
下の行も早く効いてきます。 届いていない通知書は、照合の一覧のどこにも出てきません。無いものを見つけるには、届出の側から数える仕組みが要ります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 顧問先の従業員の氏名、被保険者整理番号、標準報酬月額(報酬の水準が分かる値)、事業所の情報です。顧問先から預かった個人データで、事務所の外へ出す範囲は顧問先との契約で決まります。
- 顧問先との契約で、外部のサービスで処理してよいかを確かめる … 委託の範囲と、利用するサービスのデータの扱いの条件を、導入の前に確かめてください
- 生成AIに渡すのは、通知書の読み取り結果だけにする … 社員台帳と届出の控えは渡しません。照合は事務所の中継の処理で行います
- 台帳への書き込みを自動にしない … 台帳は給与と保険料の根拠です。承認した行だけを反映します
- 社会保険の判断を代替させない … 随時改定に当たるか、届出が正しかったか、訂正の手続きが要るかは、社会保険労務士が判断することです。 この構成が出すのは、通知書と台帳の値の違いという事実だけです
- 顧問先からの送付経路を決める … 写真をメッセージアプリで送ってもらう運用は、読み取りの質だけでなく、個人データの送付経路としても見直す対象です
- 通知書の原本の保存を先に決める … 電子データで受け取る場合は紙の通知書が送られないとされています。どのファイルを原本として残すかを、顧問先と決めておいてください
誤りが起きた場合のリスクは、誤った標準報酬月額で保険料を控除することと、控除額の変更が遅れることの2つです。 前者は健保と厚年の取り違えや数字の補いで起き、後者は通知書の取り込み漏れで起きます。前者は列の見出しと信頼度で、後者は届出の側からの突き合わせで、設計で防ぎます。
10まず何から始めるか
1週目:台帳に2つの列を足す
給与計算も受託している顧問先から始め、社員台帳に「控除の方式」と「給与の締め日・支払日」の列を足します。150社を一度にそろえる必要はありません。通知書の多い上位20社から埋めます。
2週目:20枚で試す
先月の通知書から20枚を選び、Studio で読み取って手元のAIサービスで行を取り出します。健保と厚年を列で取り違えていないか、写真の通知書でどこまで読めるかを最優先で見ます。
3週目:届出の控えに見込みの等級を記録する
月額変更届と資格取得届を出すときに、事務所が計算した見込みの等級を手続きの管理表に記録する決まりにします。ここが無いと ledger_outdated と differs_from_filing を分けられません。
4週目:受領フォルダから行の一覧までをつなぐ
顧問先ごとの受領フォルダを用意し、読み取りと取り出しまでを自動で動かします。この時点では照合をせず、行の一覧だけを担当者に見てもらいます。
2か月目: 社員台帳と届出の控えとの照合を足し、differs_from_filing と unreadable の件数を毎週数えます。3か月目以降: 保険料を変える月の計算と、届いていない通知書の一覧を足し、1行5分が何分になったかを実測します。写真で届く顧問先が減り、retro_adjust の付く行が出なくなった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 随時改定が、変更後の報酬を初めて受けた月から起算して4カ月目の標準報酬月額から行われること。要件が固定的賃金の変動・2等級以上の差・支払基礎日数17日(特定適用事業所の短時間労働者は11日)以上の3つであること。上限・下限にわたる場合は1等級差でも対象となり、厚生年金保険の上限の例が32等級・650千円、健康保険の例が50等級・1,390千円であること。月額変更届を速やかに提出し、提出方法が電子申請・郵送・窓口持参であること | 日本年金機構: 随時改定(月額変更届) | 2026-10-08 |
| 決定通知書が提出された届書に基づく処理の結果を通知するものであること。健康保険・厚生年金保険被保険者標準報酬決定通知書、資格取得確認および標準報酬決定通知書、標準報酬月額改定不該当通知書、標準賞与額決定通知書などを電子データで受け取れること。電子データで受け取る場合は紙の通知書が送られないこと。電子申請を行った際の決定通知書は電子申請の経路で通知されること | 日本年金機構: 電子データで受け取れる各種情報・通知書の詳細 | 2026-10-08 |
| 事業主が毎月の給料から被保険者負担分の保険料を差し引くこと。当月支払う給料から前月の標準報酬月額にかかる保険料を差し引くことができ、例として5月の給料支払日には4月分の保険料を差し引くこと | 日本年金機構: 厚生年金保険料等の納付 | 2026-10-08 |
レイアウトモデル(prebuilt-layout)が文字・表・選択マークを取り出し、表のセルに行と列の番号と columnHeader かどうかが付くこと。outputContentFormat=markdown でMarkdownを返し、v4.0(2024-11-30)では表がHTMLの表になること。入力がPDFと画像(JPEG/JPG、PNG、BMP、TIFF、HEIF)で、PDFとTIFFは最大2,000ページ(Freeは最初の2ページ)、S0で500MBであること。画像が50×50から10,000×10,000ピクセル、文字の最小の高さが1024×768の画像で12ピクセルであること。パスワード付きPDFは提出前に解除が必要なこと | Microsoft Learn: Document layout analysis | 2026-10-08 |
| レイアウトモデルの対応言語に、印刷の文字・手書きの文字とも日本語(ja)が入っていること。言語が確かでない限り言語コードを指定しないよう注意されていること | Microsoft Learn: Language and locale support for Read and Layout | 2026-10-08 |
構造化出力でモデルが指定したJSONスキーマに従うこと。すべての項目を必須にし、省略したいものは null との共用体型で表すこと。additionalProperties: false が必要なこと | Microsoft Learn: Azure OpenAI で構造化出力を使用する方法 | 2026-10-08 |
随時改定への該当、届出の訂正、保険料の控除の取り扱いは、社会保険労務士と顧問先で判断してください。 本記事は日本年金機構のページと公開仕様で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0895)についてのご相談はこちらから。
