【開発記第3回】AIを「専門家」にする魔法。アレルギー判定精度を極限まで高めたプロンプトエンジニアリング

2026年1月26日

「AIに原材料を判定させる」と言うのは簡単ですが、実際にやってみると大きな壁にぶつかります。それは、食品表示の世界が**「白か黒か（安全か危険か）」だけで割り切れないグレーゾーン**に満ちているからです。

第3回では、Glu-Suppoの心臓部である「AIへの指示（プロンプト）」をいかに磨き上げ、ユーザーが納得できる回答を導き出しているかについて解説します。

1. 「二択」から逃れることで得た判定の安定性

開発初期、私は「安全」か「危険」かの二択でAIに答えさせようとしていました。しかし、これでは判定が全く安定しませんでした。

例えば**「蛋白加水分解物」**。これが小麦由来なのか、大豆由来なのか、パッケージの文字情報だけではAIでも断定できない場合があります。これを無理に「安全」と言い切ればリスクになり、「危険」と言い切れば食べられるものがなくなってしまいます。

そこで取り入れたのが**「CAUTION（注意）」**という第3の選択肢です。「成分の由来が特定しきれない場合」や「醸造過程でグルテンが分解されている可能性はあるが、重度の症状がある人は避けるべきもの（醤油など）」をCAUTIONに分類することで、AIの判定のブレを吸収し、ユーザーに誠実な回答を返せるようになりました。

2. 「なぜそう判断したか」をブラックボックス化しない

Glu-Suppoで最もこだわったのは、AIの判定結果と一緒に**「判定の理由」を必ずユーザーに提示する**ことです。

「安全です」という結果だけではなく、

「この製品には醸造醤油が含まれています。一般的に醸造過程で小麦タンパクは分解されますが……」
「この成分は小麦由来の可能性があります。体質に合わせてご判断ください」

といった根拠を添えるようにしました。これにより、ユーザーはアプリの判定を鵜呑みにするのではなく、自分の体質や許容量に合わせて「最終的な判断」を自分で行うことができます。

3. 将来の展望：パーソナライズされたアレルギー判定へ

現在は一律の基準で判定していますが、実はアレルギーの許容量は人それぞれです。「10グラムまでなら大丈夫」「微量でも絶対にダメ」など、ユーザーごとに異なるニーズがあります。

今後は、Geminiの柔軟な推論能力を活かし、**「ユーザーごとのカスタマイズ設定」**をプロンプトに組み込むアップデートを計画しています。プロンプトエンジニアリングの可能性は、まだまだ広がっています。

4. エンジニア向け：Response Schemaで「AIの気まぐれ」を制御する

AI（LLM）をアプリのバックエンドとして使う際に最も苦労するのが、回答形式の安定化です。「判定結果を教えて」とだけ頼むと、時には丁寧な文章で返ってきたり、時には箇条書きになったりと、プログラムで解析（パース）するのが非常に困難になります。

そこでGlu-Suppoでは、Gemini APIの 「Response Schema」 機能を活用し、AIの回答を厳格なJSON形式に固定しています。

実際のスキーマ定義（Go言語でのイメージ）

バックエンドのGo言語側では、以下のような構造を定義し、Geminiに「この形でしか返さないでください」と制約をかけています。

type AnalysisResponse struct {
    Status string `json:"status"` // SAFE, CAUTION, DANGER
    Reason string `json:"reason"` // 判定の具体的な理由（日本語）
}

 model.ResponseSchema = &genai.Schema{
        Type: genai.TypeObject,
        Properties: map[string]*genai.Schema{
            "status":       {Type: genai.TypeString},
            "reason":       {Type: genai.TypeString},
        },
    }

これによるメリット

パースエラーの撲滅: 回答が必ず決まったJSON形式で返ってくるため、アプリ側で「解析に失敗してクラッシュする」というリスクを最小限に抑えられます。
ロジックの単純化: 文末が「〜です」「〜だ」といった表記の揺れを気にする必要がなくなり、status フィールドの値を見るだけで即座にUI（緑・オレンジ・赤）を切り替えられます。
トークンの節約: 「はい、判定結果は以下の通りです」といった不要な枕詞を削ぎ落とし、純粋なデータだけを受け取れるため、わずかですがコストとレスポンス速度の向上にも寄与しています。

「AIを自由な知能として使うのではなく、厳格なAPIインターフェースとして定義する」。これが、不安定なAIを堅牢なアプリに組み込むためのプロンプトエンジニアリングの極意です。