STAGE 01
システムメール受信
取引先が利用者の業務メール宛に写真付き問い合わせを送信。利用者は専用アドレスへ Gmail に転送し、AWS は IMAP で定期的にメールを取得する。
Input
写真付きメール (取引先発)
Output
AWS で取り込んだメール
case-02
AI自動化試運用
写真付き問い合わせを、即答できるナレッジに
写真添付メールで届く部品問い合わせを、AI解析でナレッジ化。「営業案件」と「製品情報」の両輪で社内に蓄積し、属人化した対応の効率化と時間短縮につなげる。
Overview
このシステムは、何をしている？
Overview / 概要
プラント設備の部品・部材について、お客様から写真付きの問い合わせメールが届く。担当者は 専用アドレス に転送するだけ。 AI が画像を解析して製品を特定し、メールのやりとりは「営業案件」として、写真は「製品情報」として横断検索可能なナレッジに蓄積される。
Input入力
- 01
写真添付の問い合わせメール (プラント設備の部品・部材)
- 02
1 件あたり最大半日級の調査負荷
- 03
過去案件・ベテランの経験知 (社内に散在)
Output出力
- 01
横断検索可能なナレッジ (営業案件 + 製品情報、2 軸)
- 02
AI 解析による製品特定 (メーカー / 型式 / 仕様の候補)
- 03
返信文の雛形 (メール本文を AI 解析して自動生成)
Architecture
システム構成
サービスがどこに配置され、どう繋がっているか。
ZONE 01 — CLIENT
利用者のPC
人 / Humanメールクライアント
メール送受信
Web ブラウザ
社内ポータル (本システム) にアクセス
SMTP · メール送信
RelayGmail サーバー
外部 / 専用アドレスでメールを保管
IMAP · メール取得 (AWS が取得)
ZONE 02 — AWS · 本システム
AWS クラウド
本システムPostgreSQL
営業案件・製品情報の台帳
READ / WRITE
ORCHESTRATOR
Laravel / PHP
Web アプリケーション = 社内ポータル
ROUTESDB · STORAGE · AI
Amazon S3
写真・添付メールの保管
PUT / GET
HTTPS · API CALL
ZONE 03 — AI
AI 解析サービス
外部Anthropic Claude
画像解析 / AI チャット / 返信文生成
LEGEND人・端末外部サービス本システム (AWS)オーケストレーター双方向 / 単方向
Flow
データフロー
メール受信から返信まで、データはどこを通り、何に変わっていくか。
Case 02 · Data Flow5 stages
E2EActors
人利用者の操作AIAI 解析サービスシステム自動処理 / インフラ
- STAGE 02システム
データ保存
取得したメールから本文をデータベース (PostgreSQL) に、添付写真をファイルストレージ (S3) に分けて保存する。
Input受信メール
OutputDB レコード (本文) + S3 オブジェクト (写真)
- STAGE 03AI
AI 解析
保存された写真を AI 解析サービス (Anthropic Claude) に送信し、メーカー・型番候補などの解析結果を取得。結果はデータベースに保存される。
Input写真
Output解析結果 (メーカー・型番候補 等)
- STAGE 04人
確認・登録
利用者がブラウザで社内ポータルにアクセスし、AI 解析結果を確認。必要に応じて編集・確定し、製品情報として蓄積する。
InputAI 解析結果
Output確定済みの製品情報 (DB)
- STAGE 05人
返信
必要に応じて、ポータルから返信メールを作成して取引先へ送信する。
Input製品情報 + 内容
Output返信メール (取引先へ)
END OF FLOW
Insight
問題の本質
依頼者が口にする問題と、本当に解くべき問題は、たいてい違う場所にあります。
01
Surface
表面の問題
写真添付メールの問い合わせ対応に時間がかかる。1 件に半日消費することもある。
02
Core
実際に解くべき問題
問題の核は、知識が属人化し、案件のたびに調査をゼロからやり直す構造そのものです。
経験知を持つベテランは確認のたびに作業を中断され、自信のない担当者は心労を抱えて対応する。
会社には「過去の対応履歴」も「ベテランの経験」もあるのに、有効活用されていない。
03
Our Lens
info-flagの着眼点
ナレッジは「営業案件」と「製品情報」の両輪で蓄積する。
AIは「検索の入り口」として使い、最終判断は人が握る。完了したやり取りはシステムに戻すと自動で過去案件と結合される。
使うほど質が高まり、ベテランの経験知も自然に資産化されていく。
Design
設計のキモ
順序ではなく、並列の3本の柱。それぞれがこのシステムを支えている判断です。
三つの判断 / Three Decisions
01
Principle営業と製品、両軸でナレッジ化
メール本文には営業対応の文脈が、写真には製品の特定情報が宿る。両者を別軸で蓄積し、横断検索できるようにすることで、仕様から過去案件、過去案件から製品仕様、どちらの方向からもアクセスできる。
02
PrincipleAI は「入り口」、判断は人＋ベテラン
画像解析で製品候補を提示し、AI チャットで深掘り、足りなければベテランに依頼。AI に判断させず、人の判断を補助する位置取りに徹する。ベテランへの依頼も社内ポータル経由にし、回答が製品情報のアップデートとして残る形にした。
03
Principle使うほど質が高まる、自動結合の仕組み
対応が完了したメールをシステムに転送するだけで、AI が同じ案件と判断して既存案件に結合する。蓄積するためにわざわざ整理する手間をかけない——使えば使うほど、自然にナレッジが厚くなる設計。
Stack
使った技術・環境
Laravel / PHP（社内ポータル）PostgreSQL（営業案件・製品情報のDB）Amazon S3（写真・添付メールの保管）Anthropic Claude（画像解析・AIチャット・返信文生成）Gmail（外部メール中継 / IMAP取得）
Contact
聞いてみたいことがあれば、どうぞ。
中身まで見てもらった上で、「うちの場合は？」「これ応用できる？」と気になったら、聞かせてください。 具体的な問いから、もう一段踏み込んだ話ができます。
ご相談後に、こちらからしつこく営業することはありません。