HylaFAX自社FAXシステム連載
- 第1回:FAX番号を変えずにFAX業務をDXする――HylaFAXとAIで自社サーバーを作った理由
- 第2回:HylaFAXでFAXサーバーを構築する――Debian 13とOMRON ME5614D2の実践記録
- 第3回:HylaFAXがRunning and idleなのに受信できない――T.30 T1 timeoutの原因を追った記録
- 第4回:HylaFAXの受信FAXをWeb管理する――FaxDispatch、PDF化、メール転送の実装
- 第5回:FAX OCRとAIで送信元判別・全文検索――アドレス帳照合でAPI費用を抑える設計
- 第6回:FAXへタブレットで書き込み、そのまま返信――HylaFAX Webシステムの実装
FAXをPDFで受信できるようにしても、返信のたびに印刷して紙へ書き込むのであれば、業務は半分しか電子化されません。
実際のFAX業務では、届いた注文書や確認書へ次のような追記をします。
- 数量や日付を修正する
- 確認済みの印を付ける
- 回答文を書く
- 該当箇所を丸で囲む
- チェックを付ける
- 会社名や定型文を押す
これをパソコン用PDF編集ソフトで行うと、ファイルをダウンロードし、編集し、別名で保存し、FAX送信画面へ再添付することになります。
紙へペンで書くより面倒になっては意味がありません。
そこで、受信FAXの表示、書き込み、PDF生成、返信送信までをWeb画面内で完結させました。
目標にした操作の流れ

受信FAXを開く
↓
タブレットで手書き・文字・スタンプを追加
↓
返信先番号と原稿を人が最終確認
↓
返信PDFを生成
↓
HylaFAXの送信キューへ登録
↓
既存FAX番号の電話回線から送信
↓
送信結果をWeb画面へ反映
操作する人がLinuxやHylaFAXを意識する必要はありません。
裏ではsendfaxを使っていますが、利用者には受信FAXを開き、書いて、宛先を確認し、送信するという流れだけを見せます。
タブレットで重視したこと
タブレットでは、マウス操作とは異なる問題があります。
- ペンで書こうとするとページがスクロールする
- 指操作とスタイラス操作を区別しにくい
- 小さなボタンを押しづらい
- 拡大表示中の座標とPDF上の座標がずれる
- 端末を回転すると表示倍率が変わる
- 書き込みが保存されたか分かりにくい
単にHTMLのcanvasへ線を書くだけでは、FAX返信として安定しません。
画面上の座標をPDF原稿上の座標へ変換し、表示倍率が変わっても同じ位置へ配置できるようにする必要があります。
用意した編集機能

手書きペン
スタイラスで、紙と同じように線を書きます。
FAXは白黒またはグレースケールで送信されるため、最終出力で読める線幅になるよう調整します。
テキスト
パソコンでは、複数行テキストを配置できます。
入力した文字は、位置、サイズ、回転を調整します。手書きしにくい長い回答や、日付、担当者名などに使います。
直線・囲み・チェック
注目箇所を示す線や囲み、チェックを追加します。
手書きだけでなく、整った図形を使えるようにすると、返信原稿が読みやすくなります。
定型スタンプ
よく使う回答や確認印を登録し、原稿へ配置します。
スタンプは移動、拡大縮小、回転ができます。
受信だけでなく、返信も既存の回線から行う
既存FAX番号を残した理由は、受信先を変えたくなかったからだけではありません。
Web画面からの返信もHylaFAXを通じて同じ電話回線へ送るため、システム移行のためにクラウドFAX用の別番号を新設する必要がありません。
相手先へ新しい番号を案内したり、「受信番号と送信元番号が違う」運用を追加したりせず、これまでのFAX連絡経路を保ったまま、社内側の操作だけを変えられます。
返信時の送信先を自動確定しすぎない
OCRとアドレス帳から送信先候補を出せても、候補番号へ自動送信するのは危険です。
原稿には、次のような複数の番号が書かれている場合があります。
- 会社代表FAX
- 担当部署FAX
- 注文専用FAX
- 問い合わせ先
- 別支店の番号
そのため、アドレス帳一致を上位に表示しても、送信直前には利用者が番号を確認します。
OCRは候補を出す。送信先の最終確認は人が行う。
FAXは送信後に取り消せません。便利さより、誤送信を防ぐ方を優先しました。
返信時は表紙なしを初期値にする
新規FAXでは、会社名、宛先、件名、送信枚数などを記載した表紙が必要になる場合があります。
一方、受信原稿へ回答を書き込んで返信する場合は、元の原稿自体に宛先や内容が含まれています。
毎回自動で表紙を付けると、不要な1ページが増え、相手側の紙と通信時間を消費します。
そのため、設定を分けました。
- 新規送信:必要に応じて表紙を付ける
- 返信送信:表紙なしを初期値にする
返信時にも「表紙を付ける」チェックは用意しますが、初期状態ではオフです。
新規送信にも対応する
返信だけでなく、新規FAXもWeb画面から送れます。
パソコンのファイルを送る
PDFや画像をアップロードし、送信先を選択してキューへ登録します。
複数ファイルを追加する場合は、ページ順を確認して一つの送信原稿へまとめます。
スマートフォンやタブレットで紙を撮影する
紙しかない原稿は、端末のカメラで撮影します。
撮影画像をそのまま送ると、台形にゆがみ、背景や机まで写り込みます。
そこで、OpenCVを使い、次の処理を行います。
- 原稿の四隅を検出する
- 遠近変形を補正する
- 背景を除去する
- A4比率へ整える
- FAX送信用PDFへ変換する
スキャナーがない場所でも、紙を撮影して送信できるようになります。
送信状態を画面へ戻す
送信ボタンを押した時点では、FAXはまだ送信完了していません。
HylaFAXのキューへ登録された後、相手先へ発信し、通信が成立して初めて完了です。
Web画面では、次の状態を表示します。
- 送信準備中
- 送信待ち
- 送信中
- 送信済み
- 送信失敗
- 取消
失敗時には理由を確認し、必要に応じて再送します。
認証とユーザー管理
FAXには取引先情報や注文内容が含まれるため、URLを知っていれば誰でも開ける状態にはできません。
Webシステムにはログイン機能とユーザー管理を追加しました。
権限は、少なくとも次の操作を分けて考えます。
- 受信FAXの閲覧
- メール転送
- 原稿編集
- FAX送信
- アドレス帳編集
- ユーザー管理
- システム設定
「閲覧できる人」と「外部へ送信できる人」を同じにしない設計が重要です。
監査ログを残す
紙のFAXでは、誰がいつ見て、何を書き、どの番号へ送ったかが残らない場合があります。
Web化したことで、次の操作を記録できるようになりました。
- ログイン
- FAX閲覧
- 既読・未読変更
- フォルダ移動
- メール転送
- 編集内容の保存
- FAX送信
- 送信取消
- アドレス帳変更
- ユーザー・権限変更
監査ログは利用者を監視するためではなく、誤送信や操作ミスが起きたときに事実を追えるようにするためです。
外部公開は必要最小限にする
タブレットから使えるWebシステムでも、インターネット全体へ公開する必要はありません。
基本は社内LANから利用し、社外から必要な場合はVPNなど、入口を限定する方が安全です。
特に管理画面、ユーザー管理、SMTP設定、APIキー、バックアップ領域は直接公開しません。
オンプレミスは、置けば安全になるわけではありません。更新、バックアップ、ログ確認、復元試験まで含めて運用です。
タブレット対応で得られた効果
- 受信FAXを取りに行く必要が減る
- 印刷せずに回答できる
- 外出先や別室でも確認できる
- 返信原稿がWebシステムへ残る
- 送信先と送信結果を追跡できる
- 紙の紛失や回覧漏れを減らせる
FAXという古い通信手段は残っていますが、社内側の作業は大きく変えられます。
まとめ
FAXを電子化する目的は、紙をPDFへ変えることではありません。
受信、確認、書き込み、返信、検索、履歴管理までを一つの業務フローとしてつなぐことです。
今回のシステムでは、HylaFAXを送受信の土台とし、Web上でPDFを表示し、タブレットから手書きやスタンプを追加し、そのまま返信できるようにしました。
新規送信ではファイルアップロードとスマートフォン撮影に対応し、返信時は表紙なしを初期値にしています。
FAXをなくせなくても、紙を中心にしたFAX業務はなくせる。
このシリーズで紹介したのは、FAXをパソコンで受信する方法ではなく、FAXを自社の検索可能な業務システムへ組み込むまでの記録です。
シリーズ内の記事
- 第1回:FAX番号を変えずにFAX業務をDXする――HylaFAXとAIで自社サーバーを作った理由
- 第2回:HylaFAXでFAXサーバーを構築する――Debian 13とOMRON ME5614D2の実践記録
- 第3回:HylaFAXがRunning and idleなのに受信できない――T.30 T1 timeoutの原因を追った記録
- 第4回:HylaFAXの受信FAXをWeb管理する――FaxDispatch、PDF化、メール転送の実装
- 第5回:FAX OCRとAIで送信元判別・全文検索――アドレス帳照合でAPI費用を抑える設計
- 第6回:FAXへタブレットで書き込み、そのまま返信――HylaFAX Webシステムの実装

コメント