株式会社Koinobori

CASE 06 | 社内チェックの自動化

作り方:生成AIで作成動き方:プログラムが判断

経費精算書の誤りを、
平日の毎朝、本人に知らせる。

社員が毎月出す経費精算書を、会社に置いたMac mini 1台が平日の朝9時に読み、記入の誤りがあれば本人に Slack で知らせます。 直るまで毎日届き、精算するものが無い月は何も届きません。

要点:株式会社Koinobori が自社で作った、経費精算書を確かめる仕組みです。 社員が共有ドライブに置いた精算書(Google スプレッドシート)を、会社に置いた Mac mini 1台が平日の朝9時に読み取り専用で読み、日付・金額・登録番号・合計欄など17の項目を確かめます。 誤りがあれば本人に Slack の DM で知らせ、直るまで毎日届きます。同じ文面は精算の担当者にも届きます。 判定はすべて、生成AIで作ったプログラムが毎回同じ基準で行います。2026年9月7日から毎朝動いています。

確かめる項目
17項目
上の欄4・明細10・合計欄3
動いている場所
Mac mini 1台
会社に設置
動く時間
平日の朝9時
土日祝は休み
稼働
2026年9月〜
9月7日の朝から

WHY — なぜ作ったか

誤りは、書いた本人がいちばん早く直せる。

REASON 01

書いている途中で、気づけるように

誤りは、月末にまとめて見つかるより、書いている途中で気づけるほうが直しやすい。月の途中でも毎朝すべての項目を確かめ、本人に直接知らせます。

REASON 02

紙はそのまま、データでも置く

2026年9月分から、紙の提出は続けたまま、同じ精算書を共有ドライブにもスプレッドシートで置いてもらうことにしました。データで読めるので、機械で確かめられます。

REASON 03

担当者にも、同じ文面を

本人に届いたのと同じ文面が、精算の担当者にも届きます。要約も伏せ字もしないので、何を指摘されたかを聞かなくても分かります。

ARCHITECTURE — 構成

ドライブを読んで、Slack で知らせる。

社員の精算書は共有ドライブに置かれ、会社の Mac mini が平日の朝に読み取り専用で読みます。確かめた結果は、直すところがあるときと、すべて合格になったときだけ、Slack で本人に届きます。

入口(共有ドライブ)

  • 社員ごとのフォルダ

  • 精算書(Google スプレッドシート)

  • 月ごとのシート(例:26年9月)

フォルダの直下だけを読みます。領収書を入れるサブフォルダは読みません。

Mac mini(会社に設置)

  1. 1

    平日の朝9時に動き出す

    土日祝は休み

  2. 2

    対象の月を決める

    月末〜翌月5日は前月分、6日からは当月分

  3. 3

    精算書を読む

    読み取り専用。値・数式・セルの結合をまとめて1回で

  4. 4

    対応表を組み立てる

    ほかの提出分から「支払先と登録番号」「区間と運賃」

  5. 5

    17項目を確かめる

    🔴 直すところ/🟡 確認のお願い

  6. 6

    送るかどうかを決める

    直すところがある/すべて合格になった、のどちらか

送信(Slack)

本人への DM

2回目からは同じスレッドに

精算の担当者へ、同じ文面

本人が担当者なら二重に送らない

送らないとき:精算するものが無い月・合格を伝えたあと

Mac mini まわりの、ほかの経路

仕組みの異常は、管理する側へ

ドライブが読めない、社員のフォルダが1つも見つからない、といったときは、全員に誤って知らせずに、その日は止まります。通信の一時的な不調でなければ、管理する側に Slack で知らせます。

宛先の表は、この Mac mini の中だけに

誰にどの Slack で送るかの対応表は、この Mac mini の中にだけ置いています。プログラムの保管場所には入れていません。

使っている技術

  • Mac mini
  • Python
  • Google Sheets API・Drive API(読み取りのみの権限)
  • Google Workspace(共有ドライブ)
  • Slack(本人への DM)
  • cron(平日の朝9時)
  • 祝日の判定(jpholiday)

17 CHECKS — 確かめること

上の欄・明細・合計欄を、17の決まりごとで。

🔴 は直すところで、直るまで毎日届きます。🟡 は確認のお願いで、初めての1回だけ載せます。

申請書の上の欄(4項目)

申請日
記入があり、対象の月の日付か(ひな型の「20●●年●月●日」のままは🔴)
所属部署
決まった部署名のどれかか
氏名
記入があるか(ひな型のままは🔴)
シート名
対象の月(例:26年9月)か

明細(10項目)

  1. 1

    支払日

    日付として読めるか。対象の月より後(まだ払っていない日付)は🔴、前の月の分は🟡

  2. 2

    目的

    選択肢のどれかか

  3. 3

    金額

    1円以上の数字か(空・0・マイナスは🔴)

  4. 4

    登録番号の形

    「T+13桁」で、先頭の検査用数字の計算が合うか

  5. 5

    支払先と登録番号

    これまでの提出と同じ番号か(初めての支払先や食い違いは🟡)

  6. 6

    登録番号の空欄

    🟡で確認をお願いする(在来線・税務署・印紙売捌所は確かめない)

  7. 7

    領収書の有無と提出形式

    「あり」なのに提出形式が空欄なら🔴

  8. 8

    往復・片道の金額

    在来線だけ。これまでの実績から片道の運賃が1つに定まる区間で、片道はその運賃と、往復はちょうど2倍と合っているか

  9. 9

    同じ日・同じ区間・同じ金額の片道が2行

    🟡(「往復」1行にまとめられる案内)

  10. 10

    定期券の期間

    備考に期間が書いてあるか

合計欄(3項目)

  • 合計欄の値が、明細の合計と合うか
  • 合計の計算範囲に、すべての明細が入っているか
  • 計算範囲の外に、金額が書かれていないか

ファイルそのもの

Excel(.xlsx)で置かれている、または新しい様式になっていないときも🔴で知らせます(17項目とは別)。

登録番号の検算

適格請求書発行事業者の登録番号は、T のあとの先頭1桁が検査用の数字です。残り12桁を右の桁から順に1倍・2倍・1倍…として足し合わせ、9で割った余りを9から引いた数が、先頭の1桁と一致します。実在の番号で確かめてから使っています。

MESSAGE — 届く文面(例)

行番号と内容の、両方で指す。

📋 精算申請書チェック|2026年9月分

○○さん、9月分の精算申請書に 2件 直していただきたい点があります。

■ 明細

🔴 8行目(9/4 ○○鉄道株式会社(A駅〜B駅))

「往復」の金額が、この区間の実績と合いません

🔴 12行目(9/12 ○○株式会社)

証憑「あり」ですが提出形式が空欄です

■ 確認だけお願いします

🟡 10行目(9/8 ○○商店)

この支払先は初めてです。登録番号をご確認ください

📄 26年9月のシートを開く

※ 名前・支払先・駅は架空の例です。

6 RULES — 誤った指摘を出さないために

間違いを指摘する仕組みが、間違えないように。

  1. 1

    わからないときは、黙る

    これまでの提出で、同じ区間に違う運賃が記録されていたら、その区間の金額は確かめません。経路の違いや、IC カードと切符の差を、誤りと言わないためです。

  2. 2

    正しい金額は、書かない

    通知は「合いません。ご確認ください」までにして、正しい運賃は書きません。もとにしている対応表が間違っていたら、間違った金額へ誘導してしまうからです。

  3. 3

    確かめる精算書を、材料にしない

    支払先と登録番号、区間と運賃の対応表は、毎朝、確かめる精算書以外の提出分から組み立て直します。確かめる精算書自身を材料に入れると、誤りをそのまま正解として覚えてしまうからです。同じ登録番号が2つの支払先に付いていたら、どちらが正しいか機械には決められないので、その番号は対応表から外します。

  4. 4

    🟡 は、一度だけ

    確認のお願い(🟡)は、初めての1回だけ載せ、翌日からは繰り返しません。直さなくてよい指摘が毎日並ぶと、直すべき🔴が埋もれるからです。

  5. 5

    直しようのないことは、言わない

    精算するものが無い月(精算書やその月のシートが無い、明細が0件)は何も届きません。前の月の締切に間に合わなかった経費を翌月に載せるのは正しいやり方なので、🔴ではなく🟡で1回だけ伝えます。

  6. 6

    読めないときは、全員に送らない

    ドライブが読めないときは、全員に誤って知らせず、その日は止まります。様式が想定と違う精算書は、全部の行を誤りにせず、「確認できませんでした」と1件だけ伝えます。

稼働初日に、決まりを1つやめました

当初は、精算書をまだ出していない人にも毎朝知らせる決まりでした。稼働初日に「その月に経費が無ければ、シートを作らないのが普通」と分かり、その日のうちにやめました。直しようのない催促が続くと、🔴 そのものが読み飛ばされるようになるからです。この仕組みは「書かれたものが正しいか」だけを見て、提出の管理は人の仕事として分けています。

TIMELINE — 原案から稼働まで

箇条書きの原案から、18日で毎朝の仕組みに。

  1. 2026年8月20日

    代表が、確かめてほしい点を箇条書きで書く(原案)

  2. 8月21日

    試作を検証用の精算書に当て、Slack への通知まで通す

  3. 8月26日

    精算書のひな型の現物を読み、選択肢や列の使い方を仕様に合わせ直す

  4. 8月28日

    本番用を作り、わざと誤りを仕込んだ精算書で🔴12件・🟡4件を検出

  5. 9月4日

    平日の朝9時の自動実行を登録

  6. 9月7日(月)

    最初の朝。同じ日に「未提出を毎朝知らせる」決まりをやめる

確かめ方

わざと誤りを仕込む

誤りのパターンを一式仕込んだ検証用の精算書で🔴12件・🟡4件を検出し、正しく書いた精算書では合格の文面が出ることを確かめました。検証用のファイルは名前に【テスト】を付け、本番の確認からは外しています。

正しい書き方を、誤りと言わない

同じ日・同じ区間で「在来線」と「特急券・新幹線」を別の行に書く、税務署の登録番号を空欄にする、といった正しい書き方が素通りすることも確かめています。

32件の自動テスト

対象の月の決め方(月末・年またぎ・うるう年)、登録番号の検算、対応表の組み立て方などを、ドライブや Slack につながずに確かめるテストが32件あります。

HOW IT RUNS — 動くときの判断

作るのは生成AI、判定するのはプログラム。

この仕組みは、社員に「ここが違います」と伝えるものです。誤った指摘は、一度で信用を失います。

受発注の文面の下書きを確かめる社内の別の仕組みで、書式や敬称の判定を AI に任せたところ、実際には無い誤りを指摘したり、誤りを見落としたりすることがありました。そこで精算書の確認では、17項目すべてを決まりごと(プログラム)で判定しています。

判定のしかた 17項目すべてプログラム(生成AIで作成)

CASE 05 の Koibumi と同じく、仕組みは生成AIで作り、毎回同じ結果が要る判定はプログラムに任せています。

MORE

ほかの取り組みも、あわせて。

CASE 05 | もう1つの実例

生成AIで作った、会員へのメール配信の仕組みです。送信前の5つの関所で誤送信を防いでいます。

会員へのメール配信の事例を見る →

生成AI・ローカルLLM構築支援

当社自身が運用している、ローカル LLM と業務自動化の実例を10件掲載しています。

事例の一覧へ →

経営者コラム

自社で AI や自動化を運用する中での、工夫や失敗を記録しています。

経営者コラムを読む →

※ 本ページは、当社が自社の業務のために作った仕組みの事例紹介です。文面の例に出てくる名前・支払先・駅は架空です。

KOINOBORI ECOSYSTEM

私たちが運営するサイト