【2026年】目と耳を持ったAIで業務革命｜マルチモーダルAI実装ガイド

import base64

from openai import OpenAI

client = OpenAI() # 環境変数 OPENAI_API_KEY が必要

Base64エンコードで渡す（URL不要・権限問題ゼロ）

with open("receipt.jpg", "rb") as f:

b64 = base64.b64encode(f.read()).decode()

response = client.chat.completions.create(

model="gpt-4o",

messages=[{"role": "user", "content": [

{"type": "text", "text": (

'{"date":"YYYY/MM/DD","store":"店名","total":金額（数値のみ）,"items":["品名1","品名2"]}'

' の形式のみで返答してください。説明文は不要です。'

)},

{"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{b64}"}}

]}],

response_format={"type": "json_object"}, # JSON強制モード（gpt-4o-2024-08-06以降）

temperature=0 # 同一画像への出力ブレを最小化

)

print(response.choices[0].message.content)

→ {"date": "2026/03/15", "store": "セブン-イレブン 渋谷道玄坂店", "total": 1482, "items": [...]}

「目と耳を持ったAI」が変える、現場仕事の本質

最初にマルチモーダルAIを実案件に投入したとき、「ここまで使えるのか」と本当に驚きました。

GASでテキストAPIを叩いていた頃は、情報がすでにデジタル化されているものしか扱えませんでした。しかし現実のクライアント業務では「この紙の請求書」「現場スタッフが撮った写真」「会議後のホワイトボード」など、アナログ情報の方が圧倒的に多かったのです。その都度「人による入力作業」が発生し、それが自動化の最大のボトルネックになっていました。

マルチモーダルAIは、AIに「目と耳」を与えることでこの壁を突き崩します。

• 画像 → テキスト: 商品写真を撮るだけで、ECサイトの説明文とスペック表を自動生成。
• 動画 → テキスト: 1時間の研修動画をアップするだけで、テスト問題と要約マニュアルを作成。
• 音声＋画像 → アクション: 機械の異音とエラー画面を認識し、故障原因を特定して部品を発注。

クラウドソーシングでAI案件を200件以上こなしてきた経験から言うと、「人間が目で見て手で入力していた作業」こそが、マルチモーダルAIで最も費用対効果の高い自動化ターゲットです。テキスト処理AIとは別次元の、物理的な作業の自動化がついに始まっています。

ただし、最初から順調だったわけではありません。 初期の案件では「画像を送ればなんでも認識できる」と過信した設計をしてしまい、スキャン解像度が低い領収書での精度が68%しか出ず、クライアントから「使いものにならない」と指摘される事態になりました。解像度を150dpi→300dpiに改めて82%に改善しましたが、「AIへの過信」が招く設計ミスは今でも自分の戒めとして第一原則に据えています。

マルチモーダルAIの仕組み

マルチモーダル（Multimodal）とは、「複数の（Multi）様式（Modal）」という意味です。

人間が「リンゴ」を見たとき、「赤い」「丸い」「果物」という視覚情報と、「リンゴ」という言葉を脳内で結びつけるように、AIも画像データとテキストデータを同じ空間で理解します。これにより、「この画像の右下に写っている赤いものは何？」といった質問に答えられるのです。

ささげ業務83%削減を含む3つのマルチモーダルAI活用事例

事例1: ECサイトの「ささげ業務」完全自動化

アパレルや物販で最も手間がかかるのが、商品情報の登録（採寸、撮影、原稿作成）です。

• Before: スタッフが商品を採寸し、特徴を目視で確認してライティング。
• After: 商品写真を1枚撮ってAIに投げるだけ。AIが「色：ネイビー、素材：綿100%、特徴：ダブルボタンのジャケット」と認識し、SEOに強い紹介文を生成します。

実案件での成果： 都内の中古ブランドバッグEC（月商約450万円・スタッフ2名）にGPT-4oを使ったささげ業務自動化を導入したところ、1商品あたりの処理時間が平均15分→2分30秒（約83%削減）を達成しました。月間200商品を登録する規模では、月約40時間分の作業コストが丸ごと不要になった計算です。

クライアントの反応： 担当のMさん（30代・女性）に初めてデモを見せたとき、「え、本当にこれだけ？」と声を上げていました。それまで深夜残業で商品原稿を書いていたと聞いて、「これが自動化の本当の価値だ」と実感した瞬間でした。

この案件での失敗： 初回実装では、商品の状態（「スレあり」「色褪せあり」等）の区別でAIが迷うケースが頻発。「スレ」と「傷」を混同した誤記が連発しました。解決策として、プロンプトに状態ランク表（N/S/6/5/4/3/2/1の定義文）を丸ごと埋め込んだところ、誤記はほぼゼロになりました。「AIに判断基準を明文化して渡す」ことがプロンプト設計の核心だと学んだ案件です。

事例2: 現場点検・報告のワンタップ化

建設現場や店舗管理において、報告書作成は大きな負担です。

• 仕組み: 現場の不具合箇所（ひび割れや汚れ）をスマホで撮影し、音声で「ここに亀裂あり、要補修」と吹き込む。
• 結果: マルチモーダルAIが画像から破損レベルを判定し、音声と組み合わせて正式な「点検報告書（PDF）」を即座に発行します。

実案件での知見： 関東圏の内装仕上げ業者（社員12名）の案件で実装しました。60代のベテランスタッフから「スマホは苦手だけど、これは使える」と言ってもらえたのが印象的でした。1件あたり20〜30分かかっていた報告書作成が、撮影・音声入力込みで3〜5分に短縮。「デジタルが苦手な現場でも使いやすい」というのがマルチモーダルAIの本質的な強みだと実感した案件です。

事例3: 動画コンテンツのリサイクル（Re-purpose）

YouTube動画やウェビナーの録画データから、ブログ記事、X（Twitter）の投稿文、ショート動画用の台本を一度に生成します。Gemini 1.5 Proのような長尺動画対応AIを使えば、数時間の動画も数秒で解析可能です。

実案件での知見： オンラインスクールを運営するクライアントで実装。60分のウェビナー動画から、ブログ記事・SNS投稿10本・FAQ10問を自動生成するパイプラインを構築しました。コンテンツ制作コストが月換算で約60%削減できたという報告を受けています。

【実データ公開】API料金と日本帳票での精度検証

マルチモーダルAIを実務導入する前に気になるのが「コスト」と「日本語帳票での精度」です。実際に検証した数値を公開します。

GPT-4o Vision のAPI料金試算

GPT-4o（2026年3月時点）の画像入力コストは以下のとおりです。OpenAI公式Vision APIドキュメントに基づき算出しています。

| 処理内容 | 概算トークン数 | 料金（USD） |

|----------|--------------|------------|

| レシート1枚（標準解像度） | 約800〜1,500 tokens | 約$0.004〜$0.008 |

| A4請求書1枚 | 約1,500〜2,500 tokens | 約$0.008〜$0.013 |

| 商品画像1枚（説明文生成） | 約1,000〜2,000 tokens | 約$0.005〜$0.010 |

月間100件のレシートを処理しても約100〜200円程度です。人件費と比べれば、ほぼゼロコストで導入できます。

日本特有の帳票での精度検証

「コンビニレシート」「手書き領収書」「Excel系請求書PDF」の3種類でGPT-4oの読み取り精度を実際に検証しました。

| 帳票種類 | 読み取り精度 | 注意点 |

|---------|------------|--------|

| コンビニ印字レシート | 97%以上 | ほぼ完璧 |

| 手書き領収書 | 82%程度 | 崩し字・薄い文字で誤読あり |

| Excel系請求書PDF | 95%以上 | 罫線が複雑な場合に項目ずれあり |

精度の実態：GPT-4oの実際の出力例

「数値だけ見ても分からない」という方のために、実際にGPT-4oが返すJSON出力を帳票種別ごとに示します。

// ① コンビニ印字レシート（97%以上）の出力例

{

"date": "2026/03/15",

"store": "セブン-イレブン 渋谷道玄坂店",

"total": 1482,

"items": ["金の食パン 2枚切", "いろはす天然水 555ml", "プレミアムロールケーキ", "カフェラテ(M)"]

}

// ② 手書き領収書（崩し字あり）の出力例（82%精度）

{

"date": "2026/03/10",

"store": "田中商店",

"total": 3200,

"items": ["野菜詰め合わせ"]

}

// ↑ 「田中」の草書体「中」が誤読されるケースあり。数字「3」→「8」誤読も発生（実失敗例）

// ③ 解像度150dpi（失敗ケース）→300dpi（改善後）の比較

// 150dpi時: {"date": "", "store": "不明", "total": 8200, "items": []} ← 金額3200が8200に誤読

// 300dpi時: {"date": "2026/03/10", "store": "田中商店", "total": 3200, "items": ["野菜詰め合わせ"]}

失敗談： 初期導入時、手書き領収書の処理で「金額フィールドの誤読」が頻発しました。原因は画像解像度の低さでした。スキャン解像度を150dpi→300dpiに上げたところ、精度が68%→82%に改善。「画像品質がマルチモーダルAIの精度に直結する」ことを身をもって学んだ経験です。

なぜGPT-4oを選ぶのか：主要Vision API比較

「Azure AI VisionやGoogle Cloud Vision APIでもいいのでは？」という疑問は当然です。実際に3つのAPIを業務案件で比較検証した結果をまとめます。

| 比較項目 | GPT-4o Vision | Azure AI Vision（Document Intelligence） | Google Cloud Vision API |

|---------|:------------:|:----------------------------------------:|:-----------------------:|

| 料金（1,000リクエスト） | 約$4〜$10 | $1〜$1.50（事前学習モデル） | $1.50〜$3.50 |

| 日本語手書き精度 | ★★★★★ | ★★★（英語最適化） | ★★★★ |

| 出力フォーマット自由度 | ✅ プロンプトで自由設計 | ❌ 固定フィールドのみ | ❌ 固定フィールドのみ |

| 文脈推論（欠損補完） | ✅ あり | ❌ なし | ❌ なし |

| Makeとのノーコード連携 | ✅ 公式モジュールあり | △ HTTP経由で要設定 | △ HTTP経由で要設定 |

| 初期設定コスト | ✅ ゼロ（即API利用可） | △ 専用モデルのトレーニング推奨 | △ サービスアカウント設定要 |

| 多言語対応 | ✅ 100言語以上 | △ 限定的 | ✅ 多言語対応 |

GPT-4oを選ぶ理由は「柔軟性」にあります。

Azure AI VisionとGoogle Cloud Vision APIは、請求書・レシートといった定型フォーマットの大量処理に特化した専用OCRです。精度は高く料金も安いですが、「抽出できるフィールドが決まっている」制約があります。たとえば「商品名と金額を取り出す」以上の処理——「商品名から商品カテゴリを推定してタグを付ける」「日付が欠損しているので文脈から補完する」——はできません。

GPT-4oは料金こそ高めですが、プロンプト1本で出力フォーマットを自由に設計でき、文脈理解で欠損データを補完できます。 多品種・非定型な日本企業の帳票（手書き伝票、バラバラな請求書フォーマット）への対応力は、専用OCR APIを大きく上回ります。実案件でも「帳票が統一されていないクライアント」ほどGPT-4oの優位性が際立ちました。

> 使い分けの目安： 同一フォーマットの帳票を月10,000件以上処理するならAzureやGoogleの専用OCRがコスト最適。月1,000件未満・フォーマット多様・Make連携重視ならGPT-4oが最適解。

LINEレシートBot実装の全工程：MakeとGPT-4o Visionで家計簿を自動化

今回は最も身近なマルチモーダルAI活用として、「LINEにレシート画像を送ると、自動で家計簿（スプレッドシート）に入力してくれるBot」をMakeで作ります。

シナリオ全体フロー（5ステップ完全図解）

実装前にフロー全体を把握しておくと、各Stepでの迷いがなくなります。

【Makeシナリオ 全体フロー】

[ユーザー] LINEで画像送信

↓

[Step 2] ① LINE「Watch Events」（トリガー起動）

→ フィルター: message.type = image のみ通過

↓

② LINE「Download Message Attachment」

→ 画像バイナリ（data）を取得

↓

[Step 3] ③ Tools「Base64 Encode」

→ バイナリ → Base64文字列に変換

↓

④ OpenAI「Create a Completion」（GPT-4o Vision）

→ Base64画像 + プロンプト → JSON文字列を返す

↓

[Step 4] ⑤ JSON「Parse JSON」

↙ 成功 ↘ 失敗（JSON破損・解析不能）

[Step 4] ⑥ Sheets [Step 5] Error Handler（Resume）

「Add a Row」 → Sheets「Add a Row」（要確認）

↓ ↓

[Step 5] ⑦ LINE「Reply」（✅ 登録完了） ⑦' LINE「Reply」（⚠️ 要再送）

このフローを1つのMakeシナリオとして組み立てます。以降の各Stepで、上図の①〜⑦'に対応するモジュール設定を解説します。

Step 1: 必要なツール（Make・LINE・OpenAI API・Sheets）

• Make (旧Integromat): 自動化ツール。
• LINE公式アカウント: 画像の送信口として利用。
• OpenAI API (GPT-4o): マルチモーダルAIによる画像解析用。
• Google Sheets: データ保存用。

Step 2: LINEからの画像取得設定 (Make) ——フロー①②

Step 3: GPT-4o VisionでBase64エンコード画像を解析 ——フロー③④

ここが肝です。推奨方法はBase64エンコードです。LINEから取得した画像バイナリをそのままGPT-4oに渡せるため、外部URLのアクセス権限問題が発生せず、最も確実に動作します。

手順：

1. Makeの 「Tools」→「Base64 Encode」 モジュールを追加します。

2. 「OpenAI (ChatGPT & Whisper)」 モジュールを追加し、「Create a completion」 を選択します。

3. 以下のとおり設定します。

Model: gpt-4o

Messages:

Role: user

Content:

- Type: text

Text: |

このレシート画像を解析し、以下のJSON形式のみで出力してください。

余分な説明・マークダウン記法は一切不要です:

{"date": "YYYY/MM/DD", "store": "店名", "total": 金額（数値のみ）, "items": ["品名1", "品名2"]}

日付が読み取れない場合は "date": "" とし、金額が読み取れない場合は "total": 0 としてください。

- Type: image_url

Image URL: data:image/jpeg;base64,{{3.result}}

※ 3.result は Base64 Encodeモジュールの出力変数

Advanced settings:

Max tokens: 500

Response format: {"type": "json_object"} ← JSON強制モード（重要）

Temperature: 0

Step 4: JSONをパースしてスプレッドシートへ記録 ——フロー⑤⑥

GPT-4oから返ってくるJSON文字列を、Makeで項目ごとに分解してスプレッドシートに書き込みます。

1. 「JSON」モジュール→「Parse JSON」 を追加します。

3. Data structureは「自動生成」ボタンを押し、以下のJSONサンプルを貼り付けると型定義が自動生成されます。

{"date": "2026/03/25", "store": "セブンイレブン", "total": 1250, "items": ["お茶", "サンドイッチ"]}

4. 「Google Sheets」→「Add a row」 をつなぎ、各フィールドをスプレッドシートの列にマッピングします。

| Make変数 | Sheetsの列 | 備考 |

|----------|-----------|------|

Step 5: エラーハンドリングと精度向上の実装 ——フロー⑦⑦'

実運用では「AIが正しいJSONを返さないケース」や「画像が不鮮明で解析不能なケース」が数%発生します。本番投入前に必ず対策してください。

対策1: JSONパース失敗時のフォールバック

JSON Parseが失敗した場合（AIの返答が壊れたJSONなど）、処理を停止させずに「要確認」フラグをスプレッドシートに書き込んで続行させます。

1. JSONモジュールを右クリック→「Add an error handler」を選択

2. ハンドラータイプは 「Resume」（処理続行）を選択

3. ハンドラー内に 「Google Sheets」→「Add a row」 を追加し、以下のように固定値をマッピングします

| 列 | 書き込む値 |

|----|----------|

これにより、1件の失敗でシナリオ全体が停止するのを防ぎつつ、後から手動チェックできる運用フローが完成します。

対策2: 画像解像度の前処理（コスト削減）

実案件では、画像を送信前に短辺が768px以下になるようリサイズする前処理を挟むことで、1リクエストあたりのコストを約40%削減できました。Make上では「Image」モジュールのResizeを使うか、Webhookで受け取った後にGASで前処理してから渡す方法が現実的です。

対策3: LINE返信で処理結果を通知

ユーザー体験向上のため、解析成功・失敗どちらの場合も処理結果をLINEに返信する設定を追加します。

• 成功時：「✅ 登録完了｜{{store}}｜¥{{total}}｜{{date}}」
• エラーハンドラー側：「⚠️ 画像の読み取りに失敗しました。鮮明な画像を再送してください。」