Gemini 3.7 Flashとは、Googleが2026年8月に公開した軽量モデルのことです。

月に何百件という単位で届く書類を、誰がどの順番でさばいているでしょうか。軽量で安価なモデルは、この手数の多い工程にこそ効きます。本記事では、Gemini 3.7 Flashを大量文書の処理に使えるかどうかを、士業事務所が自前で見極めるための検証工程を7つに分けて示します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。Gemini 3.7 Flashは2026年8月13日に発表されました（出典: Google Introducing Gemini 3.7 Flash）。

軽量モデルの位置づけと、料金・コンテキストの前提

まず前提を押さえます。Gemini 3.7 FlashはGoogleが主力の実務向けモデルとして位置づけたもので、コーディングやエージェント用途での改善が前面に出ています（出典: Google Introducing Gemini 3.7 Flash）。士業事務所にとって重要なのは、その改善そのものよりも、単価とコンテキストの組み合わせです。

コンテキストウィンドウは前世代と同じ規模が維持されており、100万トークンを超える長文を扱えます。料金は、100万トークンあたりの入力と出力の単価で示され、導入時の価格は上位モデルより大幅に低い水準です。ただし、導入価格には適用期間が設けられているとされ、期間後の単価は上がる見込みが示されています。適用期間と単価は改定されうるため、契約前にGemini APIの料金ページの表示を確認してください。この点は要確認の領域です。

単価とコンテキストを同時に見る理由は、士業の文書が長いからです。契約書、通達、申請書の添付一式、決算書類。どれも書類1件あたりの分量が大きく（分量の根拠は自事務所の実測に置いてください）、分量が大きいほど入力トークン数が増えます。単価が安くてもコンテキストが小さければ分割の手間が増え、コンテキストが大きくても単価が高ければ大量処理に回せません。両方が揃って初めて、件数の多い工程に当てられます。

この組み合わせが意味するのは、長い文書を、安く、大量に処理できるという条件が揃ったことです。士業の業務には、この条件が効く工程が確かに存在します。届いた書類の分類、様式の判別、必要項目の抜き出し、台帳への転記の下準備。どれも判断の重さは中程度以下で、件数が多い工程です。

一方で、注意すべき点もあります。軽量モデルは、判断が重い作業では上位モデルに劣る場面が出ます。条文の解釈が絡む作業、例外規定の見落としが致命傷になる作業、微妙な表現の差が結論を変える作業。こうした工程に安さだけを理由に軽量モデルを当てると、確認工数が増え、結果として高くつきます。どの工程に当てるかの見極めが、導入の成否を分けます。

もうひとつ、事務所として押さえておきたい前提があります。無償枠と有償枠でデータの取扱いが異なる場合があるという点です。利用規約とデータの取扱いに関する記載は、Gemini APIの利用規約を含む公式ドキュメントで確認します。顧問先の情報を扱うのであれば、無償枠での試用と本番運用を明確に分ける必要があります。試しに使ってみた段階で顧問先データを入れてしまう事故が、実際に起きやすい局面です。

大量文書処理の適性を見極める7工程

事務所で検証するための工程を7つに分けます。以下の区分は、筆者が支援先での導入手順をもとに整理したものです。

第1工程は、処理量の実測です。ここで挙げる件数や時間の根拠は、すべて自事務所の実測値に置き換えてください。対象にしたい業務について、月あたりの件数、1件あたりの分量、現状の所要時間を測ります。感覚ではなく実数で押さえます。ここが曖昧なままだと、導入後に効果を測れません。既存の業務日報や受付簿から拾えることが多い数字です。

第2工程が、処理の分解です。根拠は第1工程で測った自事務所の実測値に置きます。1件の処理を、分類、抽出、転記、確認という粒度に分けます。分解すると、機械に任せられる部分と、人が判断する部分の境目が見えます。丸ごと自動化しようとすると失敗するため、部分ごとに可否を判断します。

第3工程は、出力形式の固定です。大量処理では、出力が後続の処理に流れます。形式が揺れると、そこで例外対応が発生し、自動化の利点が消えます。項目名と順序、該当なしの場合の表記、区切り文字までを指定し、形式から外れた出力を機械的に検出できる状態にします。

第4工程が、小規模な試行です。いきなり全件を流さず、30件程度で試します。件数の根拠は自事務所の月間処理量に合わせて決めてください。ここで見るのは精度だけでなく、出力の安定性です。同じ入力を複数回流して、形式と内容がぶれないかを確認します。

第5工程は、誤りの型の把握です。どこで間違えるかには型があります。手書き部分の読み取り、似た様式の取り違え、日付表記の揺れ、数字の桁。型が分かれば、その部分だけを人が確認する設計にできます。全件を人が確認する運用では、導入の意味が薄れます。

第6工程が、確認工程の設計です。全件確認、抜き取り確認、例外のみ確認という選択肢があります。誤りの型と、誤りが与える影響の大きさで決めます。申請期限に関わる項目のように、誤ると取り返しがつかない項目は全件確認、参考情報として使う項目は抜き取り確認、といった濃淡を付けます。有資格者の確認が要る成果物では、確認の工程を手順の中に明示します。

第7工程は、運用への落とし込みと再検証の計画です。決めた運用を手順書に書き、モデルが更新されたタイミングで再検証する時期をあらかじめ決めます。軽量モデルは更新の周期が短く、料金も改定されます。一度決めて放置する運用は、いずれ実態と合わなくなります。

検証に使えるプロンプト例を2本示します。実在の顧問先名や個人名は入れず、架空の表記に置き換えて使ってください。

あなたは書類を分類するツールです。以下の文書について、
指定したカテゴリのいずれかに分類し、判断根拠となった記載を示してください。
分類できない場合は「判別不能」と出力し、推測で分類しないでください。

【カテゴリ】
A: 申請書類 / B: 添付資料 / C: 通知・決定書 / D: 請求書・領収書 / E: 上記以外

【出力形式】
カテゴリ記号 / 判断根拠となった記載（15字以内） / 文書内の所在（ページまたは行）

【注意】
- 記載内容の当否は判断しないでください
- 複数のカテゴリに該当しうる場合は、両方の記号を併記してください

【文書】
（ここに固有名詞を伏せた文書を貼り付け）

あなたは定型書類から項目を抽出するツールです。
以下の項目だけを抽出し、記載がないものは「記載なし」と出力してください。
推測による補完、単位の換算、日付の書式変換は行わないでください。
原文の表記をそのまま出力してください。

【抽出項目】
1. 書類の標題
2. 作成日または発行日（原文の表記のまま）
3. 提出先または宛先
4. 金額に関する記載（複数ある場合はすべて）
5. 期限に関する記載（複数ある場合はすべて）

【出力形式】
項目番号 / 抽出した文字列 / 文書内の所在

【文書】
（ここに固有名詞を伏せた文書を貼り付け）

この7工程を回すと、どの粒度までなら任せられるかが数字で見えます。全件を任せて全件を確認する運用は、工数が減りません。任せる部分と確認する部分を分け、確認の濃淡を設計するところまでが検証の範囲です。ここまで設計して初めて、単価の安さが事務所の利益につながります。

検証の記録は、工程名、処理件数、誤りの件数、誤りの型、確認にかかった時間、概算費用の6列で残すと扱いやすくなります。同じ形式で再検証すれば、モデルの更新による変化を追えます。とくに誤りの型は、次回の検証で真っ先に見る観点になるため、具体的に書き残してください。

大量処理の検証でもうひとつ効くのが、失敗した件の扱いを先に決めておくことです。判別不能として返ってきた件、形式から外れた件、人が確認して誤りが見つかった件。これらをどこに集め、誰が後追いするかを決めておかないと、自動化の裏で処理されない書類が溜まります。実務では、例外だけを集めた一覧を毎日確認する担当を置き、その一覧が増え続けていないかを週次で見る運用が取られます。例外の件数が減らない場合は、プロンプトか前処理に原因があるため、検証工程に戻ります。

処理の自動化を業務システムと接続する段階では、別の検討が加わります。どこにログを残すか、失敗したときにどこで止めるか、人がいつ介入するか。段ごとにログを残す設計にしておくと、問題が起きた箇所を特定できます。コンピュータ操作まで踏み込む場合の判断軸は、コンピュータ操作を事務所に入れるかの7判断軸で整理しました。

大量処理ほど、投入する情報の線引きが効いてくる

ここが軽量モデル特有の論点です。単価が安いと、大量の生データをそのまま流したくなります。しかし、量が増えるほど、外部へ出る情報の総量も増えます。この二つは同じ方向に動くため、意識して切り離す必要があります。

職種ごとの守秘義務の根拠条文を確認しておきます。税理士については、税理士法第38条が、正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、または窃用することを禁じ、税理士でなくなった後も同様であるとしています（原文は e-Gov法令検索 税理士法 で確認できます）。司法書士については、司法書士法第24条が、正当な事由がある場合でなければ、業務上取り扱った事件について知ることのできた秘密を他に漏らしてはならないと定めています（原文は e-Gov法令検索 司法書士法 で確認できます）。行政書士については、行政書士法第12条が、正当な理由がなく業務上取り扱った事項について知り得た秘密を漏らすことを禁じ、行政書士でなくなった後も同様であるとしています（原文は e-Gov法令検索 行政書士法 で確認できます）。自分の職種の条文を原文で確認する作業を省かないでください。

次に、ベンダー側の取扱いです。確認項目は四つあります。入力データがモデルの学習に使われるか。使われないとして、どの期間保持されるか。保持されたデータに誰がアクセスしうるか。データの所在地はどこか。この四点を、契約している枠に対応する公式ドキュメントで確認します。無償枠と有償枠で扱いが異なる場合があるため、Gemini APIの利用規約を含む公式の記載に当たってください。

三つ目が、大量処理特有の設計です。件数が多い工程では、前処理で非識別化を自動化する構成が現実的になります。氏名、連絡先、口座番号、マイナンバーに該当する部分を機械的に落としてからモデルに渡す。この前処理は、正規表現やルールベースの処理で組めます。生成AIに非識別化そのものを任せると、落とし漏れが起きたときに気づけないため、確定的な処理で行う設計が安全です。

四つ目が、記録です。記録の粒度は自事務所の処理量を根拠に決めます。誰が、いつ、どの業務で、どの種類の情報を、何件投入したか。大量処理では件数が多いため、1件ずつの記録ではなく、バッチ単位の記録にします。バッチの定義と、記録に残す項目を先に決めておくと、運用に乗ります。

個人情報保護法の改正で執行面の強化が進んでいる点も、あわせて押さえる論点です。令和8年の改正法が公布されており、課徴金制度の導入などが含まれます（出典: 個人情報保護委員会 令和８年 改正個人情報保護法について）。大量処理の設計は、この流れとあわせて検討する領域になります。事務所規程への落とし方は生成AI利用ガイドラインを事務所規程に落とす7項目で具体化しました。

運用に乗せたあとの見直しについても触れておきます。大量処理は、始めた時点の前提が変わりやすい領域です。顧問先が増えれば件数が変わり、様式が改訂されれば誤りの型が変わり、担当者が替われば確認の粒度が変わります。四半期に一度、誤りの件数と確認時間の推移だけでも振り返る場を設けると、前提のずれに気づけます。数字を見る場がないと、うまくいっていない状態が惰性で続きます。

軽量モデルの導入で起きやすい3つの失敗

失敗の型を三つ挙げます（いずれも筆者が支援の現場で見た事例をもとにした整理です）。

一つ目は、安さを理由に判断の重い工程まで任せてしまうケースです。条文の解釈が絡む作業や、例外規定の見落としが致命傷になる作業を軽量モデルに任せると、確認工数が増えます。削減した費用を、人の時間が食いつぶします。工程ごとの向き不向きを検証で押さえてから割り当ててください。

二つ目は、試用段階で顧問先データを入れてしまうケースです。無償枠で手軽に試せることが、かえって事故の入口になります。検証は非識別化した素材か公表文書で行い、本番運用に移る前にデータの取扱いを確認する。この順番を事務所のルールにしておくと防げます。

三つ目は、導入価格の期間終了を見落とすケースです。導入時の単価が期間限定である場合、期間後に単価が上がります。月次の費用が想定の倍になってから気づくと、運用の見直しに追われます。料金ページの表示を定期的に確認する担当を決め、更新時期を年間計画に入れておく組み立てが向いています。

費用と工数の見積もり方

見積もりの考え方を置きます。以下は筆者が中小事務所を想定して置いた試算で、根拠は各事務所の実測に置き換えてください。

1件あたりの入力が5,000トークン、出力が500トークンの処理を月に1,000件回すと、入力500万トークン、出力50万トークンになります。これに公表されている単価を掛ければ、月額の概算が出ます（単価はGemini APIの料金ページで確認してください）。軽量モデルの単価水準であれば、この規模でも費用は限定的に収まります。

効果の側は、工数で測ります。以下の数値の根拠は筆者の想定であり、自事務所の実測に置き換えてください。1件あたりの所要時間が現状で6分、導入後に確認だけで2分になるなら、1件あたり4分の削減です。月1,000件なら、月あたり4,000分、およそ66時間の削減になります。この時間を人の時間単価で金額に直し、AIの費用と比較します。件数が多い工程ほど、単価の安さと削減時間の両方が効いてきます。

検証そのものにかかる工数の根拠も筆者の想定値です。処理量の実測に2時間、処理の分解と形式設計に3時間、試行と記録に3時間、誤りの型の整理と確認設計に3時間で、合計11時間前後を見込む組み立てが現実的です（この工数も筆者の想定値です）。体制としては、実務担当者が検証を回し、有資格者が確認設計に加わる形が回りやすくなります。

軽量モデルが実務の標準になると何が起きるか

三つ挙げます。

第一に、事務作業の外注構造が変わります。これまで外部に出していた入力作業や分類作業の一部が、事務所内で完結するようになります。外注費の削減と引き換えに、設計と確認の工数が事務所に残ります。どちらが安いかは、件数と誤りの影響の大きさによって変わります。

第二に、前処理の重要性が上がります。非識別化、形式の正規化、重複の除去といった処理は、モデルの性能に関係なく効きます。むしろ軽量モデルを使う場面ほど、前処理の質が結果を左右します。ここは従来のシステム開発の知見が活きる領域です。

第三に、所員の役割が確認と設計に移ることです。書類をさばく手数が減るぶん、どこを確認するか、どう流すかを決める仕事の比重が上がります。この移行は、担当者にとって仕事の質が変わることを意味します。新しい役割を明示しないまま自動化だけを進めると、現場の納得感が得られません。導入の説明では、何が楽になるかだけでなく、代わりに何を担うのかをあわせて伝える設計が要ります。

第四に、モデルの更新周期と事務所の運用周期のずれです。モデルは数か月単位で更新されますが、事務所の手順書は年単位で見直されることが多い構造です。この周期のずれを埋めるために、再検証の時期を年間計画に組み込む運用が要ります。

よくある質問

Gemini 3.7 Flashはいつ発表されたのでしょうか

2026年8月13日に発表されました（出典: Google Introducing Gemini 3.7 Flash）。仕様や提供状況はGemini APIのモデル一覧で確認できます。

料金はどのくらいですか

導入時の単価は上位モデルより低い水準で示されていますが、適用期間が設けられているとされ、期間後の単価は変わる見込みです。契約前にGemini APIの料金ページの表示を確認してください。

どんな業務に向いていますか

判断が軽く件数が多い工程に向きます。書類の分類、様式の判別、定型項目の抽出、転記の下準備などが該当します。条文の解釈が絡む工程や、例外規定の見落としが致命傷になる工程は、上位モデルや人の判断に寄せる設計が取られます。

顧問先の書類を大量に投入してよいですか

判断の出発点は、自分の職種の守秘義務の条文、契約している枠のデータ取扱い、顧問先への説明の三点です。大量処理では、前処理で氏名や連絡先を機械的に落としてから投入する構成が現実的です。非識別化は確定的な処理で行い、生成AIに任せない設計が安全です。

精度はどのくらい期待できますか

業務と素材によって変わるため、自事務所の素材で実測するのが確実です。精度の数字より、どこで間違えるかという誤りの型を把握するほうが、運用設計には役立ちます。型が分かれば、その部分だけを人が確認する設計にできます。

無償枠で試してもよいですか

試用自体は可能ですが、投入する素材の選び方に注意が要ります。無償枠と有償枠でデータの取扱いが異なる場合があるため、検証は非識別化した素材か公表文書で行い、顧問先の情報を扱う前にGemini APIの利用規約を含む公式の記載を確認する順番が安全です。

検証にはどのくらい時間がかかりますか

処理量の実測から確認工程の設計まで、7工程をひととおり回して10時間前後を見込む事務所が多い構成です。時間の根拠は各事務所の実測に置き換えてください。最も時間がかかるのは、誤りの型を把握する工程です。ここを丁寧にやるほど、確認の濃淡を設計しやすくなり、運用に乗ってからの工数が下がります。

上位モデルと併用できますか

併用する構成が一般的です。件数の多い前処理を軽量モデルで回し、判断の重い工程だけを上位モデルに渡す。工程ごとに割り当てを決めておけば、費用と精度の両方を管理できます。

参考文献

• Google Introducing Gemini 3.7 Flash
• Gemini API モデル一覧（公式ドキュメント）
• Gemini API 料金ページ（公式ドキュメント）
• Gemini API 利用規約
• 個人情報保護委員会 令和８年 改正個人情報保護法について
• e-Gov法令検索 税理士法
• e-Gov法令検索 司法書士法
• e-Gov法令検索 行政書士法

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/