CASE STUDY ・ WEBサービス ・ FaxFlow（仮称）
- React
- Node.js
- TypeORM
- MySQL
- AWS S3
- Redis
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
専用機をなくしても、FAX業務の責任は残る
対象となった事業者は、企業間の文書交換を支えるクラウドFAXサービスを提供するため、利用者が専用機や専用回線に依存せず、ブラウザから送受信できる基盤を必要としていました。対象業務には、宛先の選択、文書の添付と変換、送信処理、送達状況の確認、受信文書の閲覧・保存が含まれます。
難しいのは、操作をWebへ置き換えることだけではありません。Office文書や画像を送信可能な形式へ変換し、相手先の状態に左右される処理を管理し、利用者が現在の状態を判断できるようにする必要があります。受信側では、紙の置き場所を電子ボックスの閲覧権限と保管ルールへ置き換える必要もあります。
送信・受信を一画面に集めるだけでは足りない
状態名を表示するだけでは不十分です。送達済みと判断する条件、再送の上限、重複送信を防ぐ方法、閲覧権限、保管期間を業務ルールとして決め、受入テストへ落とし込む必要があります。
- 文書変換
Office文書、PDF、画像を受け付け、FAX送信に使う形式へ変換する。変換前、変換中、変換失敗を区別する。
- 送信処理
送信要求をキューへ登録し、順番に処理する。再試行してよい失敗と、人が確認すべき失敗を運用で分ける。
- 受信管理
受信文書を電子ボックスへ集め、差出元、ページ数、既読状態など、確認に必要な情報と結び付ける。
- 送達管理
変換中、送信中、送達済み、失敗などの状態を表示し、利用者が次の対応を判断できるようにする。
AMELAが担当した範囲と設計判断
AMELAは、クラウドFAX送受信基盤の新規構築に参画しました。公開用ケース資料で確認できる構成は、フロントエンドがReact、管理画面がVue／Nuxt、バックエンドがNode.js、Express、TypeORM、MySQLです。送信キューにはRedis、文書保管にはAWS S3を使う構成が示されています。
実装対象として確認できる主な機能は、宛先選択、文書添付、送信用ファイルへの変換、非同期送信、再試行、受信ボックス、閲覧・保存、送信履歴、送達状態の表示です。
- 領域 01変換と送信を分離課題
画面操作と文書変換・送信処理を切り離す
解決策時間のかかる処理を状態として追跡する
- 領域 02送信要求をキューで管理課題
送信順序と再試行をバックエンド側で扱う
解決策利用者が画面を開いたまま待つ前提を避ける
- 領域 03受信文書を電子ボックスへ集約課題
文書本体と差出元・ページ数・既読状態を結び付ける
解決策検索・閲覧・保存の入口をそろえる
- 領域 04送達状態を利用者へ返す課題
変換・送信・送達・失敗を区別する
解決策次の操作を判断する材料を画面へ返す
この事例の根拠と読み方
- 根拠：移行元のAMELA開発ストーリー、公開用デモ、画面資料、CMSに保存された案件情報を照合しました。
- 対象期間：2026年8月19日時点で確認できる公開用ケース資料を対象としています。
- 確認できること：AMELAが新規構築に参画したこと、文書変換、非同期送信、受信ボックス、送達管理の対象機能、技術構成、処理状態を分ける設計方針を確認できます。
- 確認できないこと：構築期間、開発工数、送信件数、送達率、処理時間、コスト削減額、業務時間の削減、稼働率、可用性、SLA、法令・各業界規制への適合性は公開資料だけでは確認できません。
- 公開上の扱い：守秘義務に基づき、企業名、プロジェクト名、システム画面は仮名またはモックに置き換えています。画面内の企業名、電話番号、文書名、日付、件数、割合、秒数は説明用であり、実績値として使用していません。
読者が使える実践ツール
クラウドFAXを比較するときは、機能名ではなく『正常時に何を確認でき、失敗時に誰が動くか』を一枚にまとめます。次は請求書と発注書を扱う企業を想定した一般的な記入例であり、FaxFlowの実際の運用設定ではありません。
- 対象文書：請求書と発注書／入力はPDFとOffice文書／送信できない形式と容量上限は契約前に確認する
- 送信受付：送信要求ごとに受付番号を発行／利用者は受付済みと送達済みを区別して確認する
- 変換失敗：変換失敗は送信へ進めない／文書形式とエラー理由を担当者へ通知して差し替える
- 送信失敗：自動再試行の対象と上限を定義／上限後は業務担当者が宛先と文書を確認して再送を判断する
- 重複防止：同じ宛先・文書の再送時に警告／受付番号と操作履歴で二重送信の有無を確認する
- 受信権限：経理用と受発注用の受信箱を分ける／閲覧・保存・削除の権限を役割ごとに設定する
- 保管と削除：保存期間、バックアップ、削除責任者を定義／法務・情報管理部門が自社要件を確認する
- 受入確認：正常送信、変換失敗、相手先話中、再送、重複操作、未読管理、権限外閲覧をテストする
自社向けに書き換えるときは、各行に『対象』『状態』『自動処理』『人の判断』『通知先』『残す履歴』を設定してください。特に、システムが再試行する範囲と、人が送信内容を確認して再送する範囲は分けて検討する必要があります。
公開用デモで確認できることと、適用時の注意点
公開用デモでは、宛先選択と文書添付、受信ボックス、送信履歴と送達状態を画面上で確認できます。これは、送信、受信、管理を一つの業務フローとして扱う構成と、処理状態を利用者へ返す考え方を示します。
一方で、デモ画面だけでは、実際のFAX網との接続方式、送達済みの判定条件、文書変換の再現性、暗号化、本人確認、監査ログ、保存期間、障害時の復旧、業界ごとの法令・規制、料金、SLAは確認できません。導入時には、画面機能とは別に、接続先、例外処理、セキュリティ、運用責任を受入条件へ含める必要があります。
導入判断で先に決めること
クラウドFAXでは、専用機の有無だけで製品を比較せず、文書が送達されるまでの状態、失敗時の再送責任、受信文書の閲覧・保管権限を先に定義することが重要です。この三点が決まれば、自動化する処理と人が確認する例外を分けられます。
文書業務と運用責任の整理から検討する場合は、AMELAのDXコンサルティング支援もご覧ください。
