入社1年目でAI-OCR開発！？新卒が挑んだ“ゼロからの挑戦”

はじめに

こんにちは、スタイル・エッジの みかきち です！今年から新卒1年目として入社しました！！

私は普段、自社やクライアントのバックオフィス業務を支援するため、主にGoogle Workspaceの各種サービスであるAppSheetやGAS（Google Apps Script）を用いてアプリケーションを開発しています。
まだまだ学ぶことばかりですが、日々の業務や技術を通して得た気づきや学びを、このブログで少しずつ発信していけたらと思います。

この記事では、フォーマットがバラバラな書類の転記作業といった課題を解決するために開発した「AI-OCRシステム」の実例をご紹介します。
Google Workspaceのサービス（Googleフォーム, GAS）とGemini APIを組み合わせて、AIコーディング（AIによるコーディング支援）の力も借りながら、普段使っているツールだけでここまで業務を自動化できる、という方法をぜひご覧ください！

1. 課題：外注せざるを得なかった「手入力」の悩み

AI-OCRシステムを開発するきっかけとなったのは、とあるクライアント様から共有された一つの課題でした。

そこでは、フォーマットの異なる大量の書類（デジタルと手書きが混在）を、特定フォーマットに入力し直すという作業が日々発生していました。
この作業は非常に手間がかかるため、これまでは外部の業者に委託していたということです。

しかし、それには2つの大きな問題点がありました。

金銭的コスト：外注には費用がかかり続けます。
時間的コスト：外注し、作業が完了して戻ってくるまでにタイムラグが発生し、業務のスピードを妨げていました。

この非効率な「手入力」と「外注のタイムラグ」を解消することがミッションでした。

2. 解決策：Google Workspaceで作る「AI-OCR」の全体像

手入力と外注の非効率を解消するため、Gemini APIとGoogle Workspaceの各種サービスを連携させた、内製AI-OCRシステムを構築しました。
システムの全体像は非常にシンプルです。

処理フロー

アップロード：ユーザーがGoogleフォームに、データ化したいPDF書類をアップロードします。
起動：フォーム送信をトリガーにGASが起動します。
読取・整形： GASがGemini APIを呼び出し、PDFデータを読み取らせ、必要な情報を抽出・整形させます。
出力：整形されたデータが、自動でGoogleスプレッドシートに出力されます。
通知：すべての処理が完了したら、チャットツールでユーザーに通知します。

一見、簡単な仕組みに見えますが、このシステムを高精度かつ安定的に動作させるためには、2つの大きな課題を乗り越える必要がありました。

3. 実装ハイライト：立ちはだかった2つの技術課題

このシステムを安定稼働させる上で、私たちが直面した課題は大きく2つあります。

AIの精度問題：書類の「揺らぎ」にどう対応し、精度を安定させるか
GASの制約問題： 6分でタイムアウトする実行時間をどう乗り越えるか

それぞれの課題をどう解決したのか、具体的な実装ポイントをご紹介します。

ポイント①：高精度を実現する「多段階プロンプト設計」

AI-OCRの「心臓部」であるGemini APIには、「Gemini 2.5 Pro」を採用しました。Gemini 2.5 Flashモデルよりも、長文で複雑な書類の理解に優れていたためです。
ただ、「Gemini 2.5 Pro」でも対処しきれなかった大きな課題がありました。それは、書類のフォーマットや項目名の「揺らぎ」が大きすぎることでした。

例えば、同じ項目でも「合計金額」と「Total」のように表記が異なったり、手書きや低画質スキャンで文字自体が判読しづらかったりするケースです。
単純な「この項目を読み取って」というプロンプトでは、精度がまったく安定しませんでした。

解決策：処理を2段階に分割する

そこで、AIへの指示を一度に行うのではなく、処理を「①分類 → ②読取・整形」の2段階に分割する「多段階プロンプト設計」を採用しました。

Step1 (分類)：まずAIに「これはA形式か？ B形式か？」を内部的に判断させます。
- 工夫した点：この分類結果はユーザーには見せないため、「出力禁止」ルールを明示し、処理専用の「判定フラグ」だけを出力させるようにしました。
Step2 (読取・整形)：Step1の分類結果をトリガーに、「もしStep1がAならこの指示、Bならこの指示」と、自然言語で処理を分岐させます。
- 工夫した点：これにより、AIは一度に考える範囲が狭まり、混乱がなくなりました。結果、A形式ならA形式の読取に、B形式ならB形式の読取に集中でき、精度が劇的に向上しました。

安定化のためのテクニック

さらに、出力の安定性を確保するために、以下のようなテクニックをプロンプトに盛り込みました。

セクション化：プロンプトを「#条件」「#出力例」「#共通ルール」のようにセクション分けし、AIの可読性を上げ、指示の意図を明確に伝えます。
明示的な出力形式の指定：「必ずJSON形式で出力すること」「説明文やコードブロックは絶対に含めないこと」など、曖昧さを排除するルールを細かく設定し、出力形式を固定化しました。

# 役割
あなたは **{専門分野または職務名}** の専門家です。  
与えられた入力データ（または添付ファイル）を基に、指示されたステップを正確に実行してください。

# ワークフロー定義
## Step1
### トリガー
{いつ・どんな条件でこのステップが発動するかを記述}

### 指示
{このステップで行う処理内容を具体的に記述}

### 条件
- {実行時に必ず守るルールや前提条件を箇条書き}
- {内部処理／ユーザへの出力の有無なども明示}

### 出力例
```
{出力フォーマットの例を記載}
```

## Step2
### トリガー
{前ステップの結果や条件を満たしたときに実行}

### 指示
{このステップの主な目的を説明（例：データ抽出・分析・変換など）}  
以下の条件を順守して結果を出力してください。

### データ（抽出または生成する要素）
- 

### 共通条件
- {出力ルール（形式、空欄処理、禁止事項など）}
- {データ補正・整形ルール}
- {表記統一・書式制限など}

### 形式別条件（またはケース別条件）
#### Aの場合
{処理内容}

#### Bの場合
{処理内容}

#### Cの場合
{処理内容}

### 出力例
```
{期待する最終出力例（例：CSV行、JSON、テキストなど）}
```

# 最終的な出力例
```
{最終的な出力フォーマット例（シンプルな完成形）}
```

ポイント②：GASの6分の壁を突破する「タスクキュー構成」

もう一つの大きな壁が、GASの「実行時間6分の壁」です。

当初の構成では、Googleフォーム送信をトリガーに、1つのGASが「スプレッドシート作成 → OCR処理 → 通知」のすべてを一気通貫で行っていました。
しかし、GeminiによるOCR処理は「添付ファイル数」と「1ファイルあたりのデータ量」に比例して時間がかかります。ファイルが数件あるだけで、簡単に6分の上限を超え、処理がタイムアウトしてしまう問題が発生しました。

解決策：「タスクキュー構成」で処理を分割

この問題を解決するために、処理を2段階に分割し、時間差で実行する「タスクキュー構成」を採用しました。
GASはシングルスレッドなので並行処理（マルチスレッド）ができません。そこで、「1回の実行で1件だけ処理し、残りは次のトリガーに回す」という仕組みを構築しました。

構成の詳細

Step1：初期セットアップGAS (フォーム送信トリガー)
- 役割：フォームが送信されたら「即時」に実行されます。
- 処理内容：フォルダ作成、スプレッドシート生成、そして「後でOCR処理するために必要なメタ情報（ファイルIDなど）」をキュー（処理待ちリスト）に保存します。
- ポイント：時間のかかるGeminiの処理はここでは一切実行しません。数秒で処理を完了させます。
Step2：OCR実行GAS (時間ベーストリガー)
- 役割： 1分ごとに自動実行されます。
- 処理内容： Step1で保存されたキュー（メタ情報）を参照し、「未処理のファイル」を1件だけ検索します。該当ファイルが見つかれば、その1件だけOCR処理（Gemini API呼び出し）を実行し、結果をスプレッドシートに追記します。
- ポイント：このGASは、1件処理したら終了します。そして1分後にまた起動（LockService で同時実行は防止済み）し、次の「未処理ファイル」を探します。1回の処理が6分以内に収まることは確認できているので、何十枚のファイルがあっても安定的に処理できるシステムが完成しました。

4. 導入効果：AI-OCRがもたらした業務スピード

このシステムを導入した結果、クライアントの業務が改善されました。

業務スピードの向上：これまで外注し、データが戻ってくるまで待っていた作業が、クライアント自身の手元で即時完結できるようになりました。
コスト削減とコントロール：外注コストが不要になっただけでなく、「自分たちで業務をコントロールできている」という安心感にもつながりました。

クライアントからは「作業完了までの時間が大幅に短縮され、本当に助かる」という、嬉しいフィードバックを直接いただくことができました。

5. まとめ：AI-OCR開発で得た学びと今後の展望

最後に、このプロジェクトを通して私が得た学びと、今後の展望について共有します。

AIコーディングは「分割」と「明示」が鍵

複雑な処理を一度にAIへ指示すると、意図しない動作や誤補完が発生しがちです。

「機能単位で処理を分割する」「入力の背景や期待する出力形式を明示する」ことで、AIの精度と再現性は格段に向上しました。
これは、AI開発特有のテクニックというよりは、通常の開発における「責務分離」や「明確な仕様定義」といった基本思考と全く同じだと再認識しました。

ツールの「制約」こそが最適な設計を生む

GASの「実行時間6分」「シングルスレッド」といった制約は、一見すると厄介な制約です。

しかし、この制約を前提として「どう回避するか」を真剣に考えたからこそ、今回の「タスクキュー構成」というアーキテクチャにたどり着けました。
制約を理解することこそが、最適な設計を生み出すためのヒントになると学びました。

開発者の役割は「プログラマー」から「設計対話者」へ

生成AIの進化は凄まじく、今やコーディング補助だけでなく、要件定義やテストも支援できるレベルにあります。
今後は、開発者の中心的な作業が「コードを書くこと」から、「AIといかにうまく対話し、最適な設計を引き出すか」という方向に向かっていくと強く感じました。

今後の展望

今回のAI-OCR開発で得たプロンプトエンジニアリングやアーキテクチャのノウハウは、他の多くの業務にも応用可能です。
この知見をもとに、クライアントの属人化しがちな業務や手作業の多いプロセスに対し、AIや自動化ツールを活用した、より高度な効率化の提案・実装に挑戦し続けたいと考えています。
この記事が、Gemini APIの活用や業務改善のヒントを探している方々の、一助となれば幸いです。

また、本プロジェクトは、開発自体もそうですが、何より入社して1年目でやり遂げた初めてのプロジェクトということもあり、たくさんの苦労がありました。
その苦労については、いつか note の方にも綴りたいと考えています！

最後までお読みいただき、ありがとうございました！