顧問先から毎月届く会計資料を仕分けて、不足している書類の督促文を作る
顧問先から届いた資料を入力に、書類の種類ごとに仕分け、その顧問先の必要書類リストと突き合わせて不足を出します。担当者の作業は、届いたものを開いて何が来たかを確かめることから、不足の一覧を見て督促文を送ることに変わります。
- 利用ツール
- AWS Textract/Azure AI/ChatGPT/Claude/Gemini/Google Apps Script/Google Document AI/Make/n8n/Power Automate
- 対象業界
- 士業
- 対象部門
- 経理/総務
- 対象業務
- 内容確認・チェック/分類・仕分け
- 主な課題
- 人手が足りない/属人化している/期限・対応漏れが起きる
- AIで行う処理
- 分類
- 主な効果
- 品質標準化/対応スピード向上/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 顧問先から資料が届く(メール、ストレージ、チャット、郵送)
- アシスタントがメールを開き、添付を1つずつ開いて中身を見る
- 「これは9月分の通帳の写し」「これは8月分の請求書」と判別する
- 顧問先ごとのフォルダに、月別に整理して保存する
- その顧問先の必要書類リスト(担当者の頭の中か、台帳のメモ)と照らす
- 不足があれば、督促のメールを書いて送る
- 台帳に受領の記録を付ける
- 顧問先から資料が届く
- 自動毎朝、顧問先用のメールボックスとストレージの新着を確認する
- 自動届いた書類をOCRで読み取る
- 自動書類の種類(通帳の写し/請求書/領収書/売上帳/給与明細など)を判別する
- 自動対象月を判別する
- 自動顧問先ごとのフォルダに、種類と月で整理して保存する
- 自動その顧問先の必要書類リストと突き合わせ、不足を出す
- 自動月の10日、20日、25日に、不足がある顧問先の一覧と督促文の下書きを作る
- 人担当者が一覧を確認し、督促文を送る(または顧問先に電話する)
- 人判別できなかった書類を人が分類する
- 自動台帳に受領の記録を付ける
各工程の詳しい説明を読む
- 顧問先から資料が届く(メール、ストレージ、チャット、郵送)
- アシスタントがメールを開き、添付を1つずつ開いて中身を見る
- 「これは9月分の通帳の写し」「これは8月分の請求書」と判別する
- 顧問先ごとのフォルダに、月別に整理して保存する
- その顧問先の必要書類リスト(担当者の頭の中か、台帳のメモ)と照らす
- 不足があれば、督促のメールを書いて送る
- 台帳に受領の記録を付ける
問題は4つあります。
(a)何が届いたかを開くまで分からない。 ファイル名が「IMG_2847.jpg」「スキャン_20260910.pdf」のことがほとんどです。250件の顧問先から、月に1,000枚以上の書類が届きます。 1枚ずつ開いて判別する作業が、そのまま時間になります。
(b)何月分かが分からない。 通帳の写しは何ページか続けて送られ、どこからどこまでが当月分かを読まないと分かりません。前月分が混ざっていることも、翌月分が先に来ることもあります。
(c)必要書類が顧問先ごとに違う。 給与がある先とない先、消費税の課税事業者かどうか、現金商売かどうかで、必要な書類が変わります。この対応が担当者の記憶に依存しています。 担当が代わると、何が必要かが分からなくなります。
(d)督促が遅れる、または漏れる。 「まだ来ていないな」と気づくのは、多くの場合、記帳に着手したときです。月半ばに気づけば余裕がありますが、月末に気づくと締めがずれます。忙しい月ほど、気づくのが遅れます。
- 顧問先から資料が届く
- 【自動】 毎朝、顧問先用のメールボックスとストレージの新着を確認する
- 【自動】 届いた書類をOCRで読み取る
- 【自動】 書類の種類(通帳の写し/請求書/領収書/売上帳/給与明細など)を判別する
- 【自動】 対象月を判別する
- 【自動】 顧問先ごとのフォルダに、種類と月で整理して保存する
- 【自動】 その顧問先の必要書類リストと突き合わせ、不足を出す
- 【自動】 月の10日、20日、25日に、不足がある顧問先の一覧と督促文の下書きを作る
- 【人】 担当者が一覧を確認し、督促文を送る(または顧問先に電話する)
- 【人】 判別できなかった書類を人が分類する
- 【自動】 台帳に受領の記録を付ける
自動化されるのは「開いて何かを判別する」「整理して保存する」「必要書類と照らす」の3つです。督促を送るのは人です。
8番目の「月の10日、20日、25日」が、この構成の効きどころです。 記帳に着手したときではなく、決まった日に不足が分かります。
02今回想定するシステム構成
顧問先 │ メール添付 / ストレージへのアップロード / 写真 ▼ 受領用のメールボックス・共有ドライブ │ ▼【トリガー】毎朝7時(時間主導型トリガー) Google Apps Script │ ├──▶ Gmail / Google ドライブ ── 新着の添付・ファイルを取得 │ ├──▶ Azure AI Document Intelligence(prebuilt-read) │ └─ 印刷文字・手書き文字を抽出 │ ├──▶ Claude API(構造化出力) │ ─ 書類の種類を判別 │ ─ 対象月を判別 │ ─ 顧問先を特定(差出人・書類の記載から) │ ├──▶ 顧問先ごとのフォルダへ保存(種類_年月_連番) │ └──▶ 受領台帳(スプレッドシート)を更新 │ ▼【毎月10日 / 20日 / 25日】 不足一覧 + 督促文の下書き │ ▼【人が確認して送信】担当者が督促する
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 実行環境 | Google Apps Script | Power Automate、Make、n8n |
| OCR | Azure AI Document Intelligence(prebuilt-read) | Google Document AI、AWS Textract |
| 生成AI | Claude API(構造化出力) | OpenAI API、Gemini API |
| 保管 | Google ドライブ | SharePoint、Box |
| 受領台帳 | Google スプレッドシート | Excel Online、会計事務所向けの管理システム |
会計事務所向けの資料回収SaaSを先に検討してください。 顧問先がスマートフォンのアプリから書類を送り、種別を選び、事務所側で受領状況を管理できる製品があります。顧問先に新しいアプリを使ってもらえるなら、そちらのほうが確実です。
自前で組む価値があるのは、顧問先に新しい手段を強いられない場合です。高齢の経営者がスマートフォンのアプリを入れてくれない、これまでどおりメールで送りたいと言われる。この構成は、届き方を変えないまま、事務所側の手間だけを減らすやり方です。
03どうやって実装するのか
処理の起点を決める
毎朝7時に、前日から当日朝までに届いたものを処理します。Google Apps Script の時間主導型トリガーを使います。1分おきから月1回まで指定できますが、実行時刻は多少ばらつきます(午前7時のトリガーなら7時から8時の間で実行時刻が選ばれます)。資料の仕分けに分単位の正確さは要りません。
加えて、毎月10日・20日・25日に不足一覧を作る別のトリガーを設定します。日次の仕分けと、月次の不足チェックを分けるのが要点です。
なぜ届いた瞬間に処理しないのか。 顧問先は、通帳の写しを何枚かに分けて連続で送ってきます。1枚ずつ処理すると、「1ページ目だけ届いた」という記録が残り、後から続きが来たときに整合を取り直すことになります。1日分をまとめて処理するほうが、判別が安定します。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| メールの添付 | PDF、画像、Excel | Gmail(受領用アドレス) |
| ストレージのファイル | 顧問先がアップロードしたファイル | Google ドライブの共有フォルダ |
| メール本文 | 「9月分の資料です」といった記述 | Gmail |
| 顧問先マスタ | 顧問先名、担当者、メールアドレス、決算期 | 顧問先管理の台帳 |
| 必要書類リスト | 顧問先ごとに必要な書類の種類 | 顧問先管理の台帳 |
| 受領台帳 | 顧問先×月×書類種別の受領状況 | スプレッドシート |
| 過去の受領実績 | その顧問先が例年どの書類を送ってくるか | 受領台帳 |
「必要書類リスト」を作ることが、この構成の前提です。 顧問先ごとに必要な書類が決まっていなければ、不足の判定ができません。この整備が、実装の中で一番時間のかかる作業です。
データの取得方法を決める
メールの添付: Apps Script の GmailApp で、受領用アドレスの未処理ラベルが付いたスレッドを取り、添付を取得します。処理後にラベルを付け替えます。
ストレージ: 顧問先ごとの受領フォルダを共有し、DriveApp で新着ファイルを取得します。顧問先ごとにフォルダを分けておくと、顧問先の特定が不要になります。 これだけで判別の負担が大きく減ります。
OCR: Azure AI Document Intelligence の prebuilt-read モデルを使います。PDFとスキャン画像から印刷文字と手書き文字を抽出し、段落、行、単語、位置、言語を検出します。WordやExcel、PowerPoint、HTMLからのテキスト抽出にも対応します。手書きかどうかの判定結果が信頼度とともに返ります。
通帳の写しには手書きの書き込みが多くあります。 「〇〇社入金」「家事按分」といったメモが手書きで入っていることがあり、これが仕訳の手がかりになります。手書きの検出結果を保存しておくと、後で担当者が確認できます。
有料プラン(S0)ではPDFとTIFFで2,000ページまで、ファイルサイズは500MBまで処理できます。無料プラン(F0)では先頭2ページしか処理されず、ファイルサイズも4MBまでなので、通帳の写しのような複数ページの書類には使えません。
AIへ渡す前に整形する
- 画像の品質確認 … スマートフォンで撮った写真は、傾き、影、ピンぼけがあります。OCRの結果が短すぎる(文字がほとんど取れない)場合は、判別に回さず「読み取れない」として人に回します
- 複数ページの結合 … 通帳の写しは、連続して送られた複数の画像が1冊分であることがあります。送信日時が近く、同じ顧問先からのものをまとめて扱います
- 顧問先の特定 … フォルダで分かれていればそれを使います。メールの場合は差出人アドレスで顧問先マスタを引きます。一致しなければ、書類の記載(社名)から候補を出し、人に選ばせます
- 重複の検出 … 同じ書類が再送されることがあります。ファイルのハッシュと、OCR結果の先頭部分で重複を判定します
- 会計資料でないファイルの除外 … 顧問先からのメールには、会計資料以外の添付(案内状、契約書)も混ざります
AIに処理させる
OCRとAIで役割を分けます。
OCR(Document Intelligence)にさせること: 文字の読み取りだけ。金額の抽出も、項目の構造化もここではしません。
AIにさせること:
| 処理 | 内容 |
|---|---|
| 書類種別の判別 | 通帳の写し/請求書(受領)/請求書(発行)/領収書/売上帳/給与明細/その他 |
| 対象月の判別 | 書類に記載された日付から、何月分かを判定する |
| 顧問先の照合 | 書類に書かれた社名が、想定している顧問先と一致するかを確認する |
| ページの範囲 | 通帳の写しが何ページ分か、どの期間をカバーしているか |
| 判別できない理由 | 読み取れない、種別が特定できない、月が書かれていない |
| 督促文の下書き | 不足している書類の名前と、期限を入れた文面 |
金額や取引内容の抽出はしません。 それは記帳の工程で会計ソフトが行います。ここで判別するのは「何の書類が、何月分、届いたか」だけです。役割を広げると、判別の精度が落ち、確認の手間が増えます。
指示内容を固定する
あなたは会計事務所の資料受領を担当する担当者です。
OCRで読み取った書類のテキストから、書類の種類と対象月を判別してください。
【厳守事項】
- 金額、取引先名、勘定科目を抽出しないでください。
この処理で必要なのは、書類の種類と対象月だけです。
- 対象月が書類に書かれていない場合は、推測しないでください。
target_month を null にし、reason に理由を書いてください。
ファイルの送信日から推測してはいけません。
- 書類の種類が判別できない場合は document_type を unknown にし、
読み取れた特徴(表の見出し、印字されている語)を features に書いてください。
- 通帳の写しの場合、記載されている期間の最初の日と最後の日を
period_from / period_to に書いてください。
読み取れないページがあれば unreadable_pages に記載してください。
- 書類に記載された社名が、想定している顧問先名
「{expected_client_name}」と異なる場合は、
client_name_match を false にしてください。
表記の揺れ(株式会社の前後、旧字体)は一致として扱って構いません。
【想定している顧問先】{expected_client_name}
【この顧問先が例年送ってくる書類】{past_document_types}
【OCRで読み取ったテキスト】{ocr_text}
【手書きと判定された箇所】{handwritten_spans}
【ファイル名・送信日時】{file_meta}
「送信日から対象月を推測してはいけない」の指示が必要です。 9月10日に届いた資料は8月分のことが多いのですが、7月分が遅れて届くこともあります。推測で8月分として記録すると、8月分が届いたことになり、督促が止まります。 これは不足を見逃す方向の誤りなので、避けなければなりません。
出力形式を固定する
{
"document_type": "bankbook | invoice_received | invoice_issued | receipt | sales_ledger | payroll | other | unknown",
"target_month": "",
"period_from": "",
"period_to": "",
"client_name_match": true,
"page_count": 0,
"unreadable_pages": [],
"features": [],
"confidence": "high | medium | low",
"reason": ""
}
target_month を null にできる形にするのが重要です。空文字で返させると、後段がそれを「今月分」として扱う実装になりがちです。
confidence が low のものは、自動で保存せず、人の確認に回す列に入れます。
システムへ連携する
保存: 顧問先ごとのフォルダに、{書類種別}_{対象年月}_{連番}.pdf の形で保存します。判別できなかったものは _要確認 フォルダに入れます。 顧問先のフォルダに紛れさせると、担当者が「届いている」と誤解します。
受領台帳: スプレッドシートに、顧問先×書類種別×対象月の受領状況を記録します。列は、顧問先コード、書類種別、対象月、受領日、ファイル名、判別の確信度、確認済みか、です。
不足一覧: 毎月10日・20日・25日に、必要書類リストと受領台帳を突き合わせて不足を出します。顧問先ごとに1行にまとめ、不足している書類名を並べます。
督促文: 顧問先ごとに下書きを作ります。送信は人が行います。 理由は2つあります。ひとつは、すでに電話で「今月は遅れる」と聞いている顧問先に督促を送ると失礼になること。もうひとつは、顧問先との関係は事務所の資産であり、自動送信のメールに任せる部分ではないことです。
会計ソフトへの連携はしません。 この構成は受領の管理までです。
人が確認する
判別の結果は全件、担当者が受領台帳で確認します。 ただし、確認は「一覧をざっと見る」程度で、1件ずつ開き直すことはしません。
必ず人が見る必要があるのは次の3つです。
confidenceが low のものtarget_monthが null のものclient_name_matchが false のもの
この3つが _要確認 に入り、人が分類します。 想定では、月1,000枚のうち100枚程度がここに入ります。
督促文は全件、担当者が読んでから送ります。 顧問先の状況(体調、繁忙、前月の行き違い)を知っているのは担当者です。
例外に対処する
| 起きること | 対応 |
|---|---|
| 写真がぼけて読めない | OCRの結果が短い場合は判別に回さず、_要確認 に入れる。推測で種別を付けない |
| 対象月が書かれていない | target_month を null にし、人に回す。送信日から推測しない |
| 顧問先の社名が違う | client_name_match を false にし、人に回す。別の顧問先の資料が誤って送られてくることがある |
| 通帳の写しが複数回に分けて届く | 同じ顧問先の近い時刻のファイルをまとめて扱う。ページの期間で連続性を確認する |
| 前月分・翌月分が混ざる | 対象月ごとに分けて記録する。「9月分の資料」と書かれていても、中身が8月分なら8月分として記録する |
| 同じ書類が再送される | ハッシュとOCR結果の先頭で重複を判定し、台帳を二重に更新しない |
| 会計資料でない添付が混ざる | other に分類し、顧問先フォルダの _その他 に入れる |
| 郵送・持参で届いた資料 | 事務所でスキャンして受領用アドレスへ転送する運用にする |
| 顧問先が資料を送る先を間違える | 担当者個人のアドレスに届いた分を、受領用アドレスへ転送する運用にする |
| 必要書類リストが顧問先で変わった | 台帳のリストを更新する。更新しないと、不要な督促が毎月出る |
| 顧問先が廃業・契約終了した | 必要書類リストから外す。外さないと不足として出続ける |
記録を残す
この業務では、書類の保存そのものが事務所の責務です。
- 受領した書類の原本(顧問先ごと・月ごとに整理)
- OCRの抽出結果
- AIの判別結果と確信度
- 人が分類を直した件(直す前と直した後)
- 督促を送った日時と、送った担当者
- 受領台帳の更新履歴
「人が分類を直した件」が精度の実測値になります。 「通帳の写しを請求書と判別した」が月に何件あるかを数えます。特定の顧問先で誤りが集中するなら、その顧問先の書類の形式に問題があります。
顧問先の会計資料は、顧問契約上の守秘義務の対象です。保存場所へのアクセス権限を、担当者と管理者に限定してください。
04実装レベルの3段階
半自動化で効果の大半が出ます。 「開いて何かを判別する6分」と「必要書類との照合3分」が消えるためです。 本格構成の「督促の時期の最適化」は、規模が大きい事務所でなければ不要です。 顧問先250件なら、月3回の一覧で足ります。
05工数削減シミュレーション
導入後 250件 × 3.6分 ÷ 60 = 15 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 顧問先が150件以上あり、毎月の記帳代行または月次巡回のために資料を預かっていること。顧問先からの資料がメール添付、クラウドストレージ、写真のいずれかで届いていること。顧問先ごとに必要な書類の種類が決まっていること。
- 顧問先が50件未満で、担当者が誰から何が届いていないかを把握できている場合。すでに会計事務所向けの資料回収SaaSを導入し、書類種別ごとの受領管理と督促の自動送信ができている場合。顧問先の大半が紙の資料を郵送してくる場合(先に電子での受け渡しに移行する必要がある)。
07最小構成で試す方法
- 顧問先ごとの必要書類リストを作る(担当者に聞き取り、台帳に書く)
- 先月届いた資料を50枚選ぶ(顧問先と書類の種類をばらばらに)
- Document Intelligence Studio に1枚ずつ投入し、文字が読めるかを確認する
- 読み取れたテキストを生成AIに貼り付け、書類種別と対象月を判別させる
- 担当者が「この判別は正しいか」を1枚ずつ確認する
1番目が本体です。 必要書類リストを作るだけで、不足の確認が担当者の記憶から台帳に移ります。AIを入れなくても、ここに効果があります。 そして、リストが無ければこの構成は成り立ちません。
判断の目安は次のとおりです。
| 判別の正確さ | 判断 |
|---|---|
| 種別の正解が8割以上、対象月の正解が8割以上 | 進めてよい |
| 種別は当たるが対象月が外れる | 対象月の判別を諦め、_要確認 に回す設計にする。種別の仕分けだけでも効果がある |
| 写真の読み取りが5割未満 | 顧問先に撮影の依頼をする(明るい場所で、正面から、1ページずつ)。この依頼だけで大きく変わります |
3番目の行が重要です。 判別の精度はOCRの精度に引きずられ、OCRの精度は写真の品質に引きずられます。顧問先への撮影の依頼が、技術的な改善より効くことがあります。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 写真がぼけて読めない | 顧問先に撮影の依頼をする(明るい場所、正面、1ページずつ)。技術より先にこれ |
| 対象月を送信日から推測してしまう | プロンプトで禁止し、null で返させる。不足を見逃す方向の誤りは避ける |
| 判別できない書類が顧問先フォルダに紛れる | _要確認 フォルダに分ける。顧問先フォルダに入れない |
| 別の顧問先の資料が届く | client_name_match を false にして人に回す。自動で保存しない |
| 通帳の写しが複数回に分かれる | 1日分をまとめて処理する。届いた瞬間に処理しない |
| 必要書類リストが古い | 更新の担当と時期を決める。古いと不要な督促が毎月出る |
| 無料プランのOCRで2ページしか処理されない | 有料プラン(S0)を使う。無料プラン(F0)は先頭2ページ・4MBまで |
| OCRの費用が想定より高い | 顧問先ごとのフォルダ分けとファイル名の運用で、OCRに回す枚数を減らす |
| 担当者個人のアドレスに資料が届く | 転送の運用を決める。顧問先に受領用アドレスを案内する |
| 督促が自動で送られて顧問先が不快に感じる | 送信は人が行う設計にする。下書きまでで止める |
| 契約終了した顧問先が不足に出続ける | 台帳から外す運用を決める |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 顧問先の通帳、請求書、領収書、給与明細。顧問先の財務情報と、従業員の給与情報が含まれます。 税理士法上の守秘義務の対象です。
- 外部AIへの入力可否が最大の論点 … 顧問先の会計資料を外部サービスに渡します。顧問契約における守秘義務と、再委託の扱いを確認してください。 顧問先への説明と同意が必要かどうかも、事務所として判断する事項です。税理士会や顧問弁護士に確認することを勧めます
- 渡す情報を減らす設計 … 書類種別と対象月の判別に、金額や取引先名は不要です。OCRの結果全体を渡すのではなく、先頭の一定量(種別と日付が読み取れる範囲)だけを渡す構成にできます。給与明細については、個人名と金額を除いたうえで種別の判別だけを行う設計を検討してください
- 給与明細の扱い … 従業員の氏名と給与額が含まれます。外部サービスへの入力を避ける選択もあり得ます。 ファイル名や送信元で種別が分かるなら、OCRに回さない分岐を作ってください
- 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます。顧問先の情報を扱う以上、ここは必須の条件です
- 保管場所のアクセス権限 … 顧問先ごとのフォルダを、担当者と管理者に限定してください。事務所全員が全顧問先の資料を見られる状態にしない
- 自動実行してよい範囲 … 仕分け、保存、不足の検出、督促文の下書きまでです。督促の送信は人が行います
- 顧問先への説明 … この仕組みを使うことを顧問先に伝えるかどうかを決めてください。伝えないまま外部サービスに資料を渡すことは避けるべきです
誤りが起きた場合のリスクは、届いていない書類を届いたと記録して督促が止まること、別の顧問先のフォルダに資料を保存することです。後者は守秘義務に関わります。
10まず何から始めるか
1〜2週目:必要書類リストを作る
AIより先にこれです。 顧問先250件について、毎月必要な書類の種類を台帳に書きます。担当者12名に聞き取ります。この作業に2週間かかりますが、これがこの構成の土台です。
リストができた時点で、受領状況を手で記録する運用を始めてください。AIを入れなくても、不足の把握が担当者の記憶から台帳に移ります。
3週目:顧問先に撮影と送付の依頼をする
写真で送ってくる顧問先に、撮影の依頼をします。明るい場所で、正面から、1ページずつ。あわせて、受領用のアドレスを案内し、ファイル名に月と書類名を入れてもらえるか依頼します。この依頼だけで、判別の精度が変わります。
4週目:OCRと判別を試す
先月の資料50枚で、Document Intelligence Studio の読み取りと、生成AIの判別を試します。種別と対象月の正解率を数えます。種別が8割を超えれば進めます。対象月が外れるなら、対象月の判別は諦めて _要確認 に回す設計にします。
2か月目:仕分けと保存を自動化する
毎朝の仕分けと保存までを Apps Script で作ります。督促の下書きは、まだ作りません。 仕分けの精度が安定してから足します。
3か月目以降: 月3回の不足一覧と督促文の下書きを足します。人が分類を直した件を毎月数え、多い書類種別について判別の条件を見直してください。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Azure AI Document Intelligence の prebuilt-read モデルが、PDFやスキャン画像から印刷文字と手書き文字を抽出し、段落・行・単語・位置・言語を検出すること。手書きかどうかの判定結果が信頼度とともに styles に返ること。PDF・画像(JPEG/PNG/BMP/TIFF/HEIF)・Office文書・HTMLに対応。有料(S0)ではPDF/TIFFで2,000ページ・500MBまで、無料(F0)では先頭2ページ・4MBまでしか処理されないこと | Microsoft Learn: Read model OCR data extraction | 2026-09-15 |
| Google Apps Script に時間主導型トリガーがあり、1分おきから月1回までの間隔で関数を実行できること。実行時刻は多少ばらつく(午前9時の定期トリガーは午前9時から10時の間で実行される) | Google Apps Script: Installable triggers | 2026-09-15 |
| Claude API の構造化出力が、JSON Schema で指定した形式に沿った応答を保証すること。列挙値を定義でき、必須項目が必ず存在することが保証される | Claude Docs: Structured outputs | 2026-09-15 |
顧問先の会計資料を外部の生成AIサービスへ渡すことが、税理士法上の守秘義務との関係でどう扱われるかは、この記事では判断していません。 所属する税理士会または顧問弁護士に確認してください。顧問先への説明の要否も同様です。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0072)についてのご相談はこちらから。
