FAX番号を変えずにFAX業務をDXする――HylaFAXとAIで自社サーバーを作った理由

「いまどきFAXですか」と言われることがあります。

しかし、地方で食品製造業を営んでいると、注文書、納品連絡、原材料や資材の発注、取引先からの案内など、FAXは現在も日常業務の中で使われています。

こちらだけが「今日からFAXをやめます」と宣言しても、取引先がFAXを使っている以上、簡単には廃止できません。

さらに、私にとって大きかったのが、これまで使ってきたFAX番号を変えたくないという問題でした。

そこで、現在の電話回線とFAX番号はそのまま残し、RS-232C接続のモデムとHylaFAXを使って、受信後の処理だけをWeb、OCR、AI、タブレットへつなぐことにしました。

取引先には今までどおり同じ番号へFAXしてもらい、自社側の仕事だけを作り替える。

これが、今回の自社FAXサーバー構築の基本方針です。

FAX番号の変更は、思っている以上に影響が大きい

長年使ってきたFAX番号は、単なる連絡先ではありません。

• 取引先の販売管理・発注システム
• 過去に配布した注文書や申込書
• 商品案内、カタログ、名刺
• 請求書や納品書のひな型
• Webサイトや会社案内
• 担当者が個人的に保存している連絡先

こうした場所に登録されています。

番号を変更すれば、取引先へ案内を出せば終わりというわけではありません。何年も前の注文書をコピーして使っている会社や、担当者のアドレス帳に古い番号が残ったままの会社もあります。

特に注文FAXでは、番号変更の周知漏れが、そのまま注文の取りこぼしにつながる可能性があります。

クラウドFAXでも、既存番号を引き継げるサービスや、着信転送を使う方法はあります。固定電話の双方向番号ポータビリティも2025年1月から始まり、以前より選択肢は広がりました。

ただし、実際に番号を引き継げるかどうかは、利用中の回線、番号の発番元、地域、移行先事業者、クラウドFAX側の対応条件などによって変わります。また、転送方式では受信番号を維持できても、送信時にはクラウド側の別番号になる場合があり、転送料金も必要になります。

今回の構成では、回線契約と番号を移管せず、その回線へFAXモデムを接続します。したがって、取引先は従来の番号をそのまま使えます。システム導入のために、新しいFAX番号を周知する必要もありません。

これは、技術的な便利さ以上に重要な条件でした。

電子化するだけなら、ほかにも方法はある

FAXをパソコンで確認するだけなら、自前でサーバーを作らなくても方法はあります。

• クラウドFAXを契約する
• 受信FAXをメールへ転送できる複合機を使う
• ブラザーなどのネットワーク対応複合機で、PCから受信内容を確認する
• 既製のFAXサーバーや管理ソフトを導入する

受信したFAXをPDFで見られればよいのであれば、これらの方が導入は簡単です。Linux、モデム、電話回線、権限、バックアップ、障害対応まで自分で面倒を見る必要もありません。

それでも自前構築を選んだのは、今回必要としていたものが「FAXを画面で見ること」だけではなかったからです。

本当に必要だったのは、判別・検索・返信だった

私が特に重視したのは、次の機能です。

• 既存のFAX番号を変えずに受信と送信を続ける
• どの取引先から届いたFAXなのかを判別する
• 取引先名、FAX番号、受信日、本文から過去のFAXを検索する
• 受信FAXをメールで複数の宛先へ転送する
• パソコンでは文字やスタンプを配置する
• タブレットではスタイラスペンで直接書き込む
• 編集した原稿を、そのままFAXで返信する
• 送信待ち、送信済み、送信失敗などを一元管理する
• 誰が閲覧、編集、送信したかを記録する

つまり、FAX機をパソコンの中へ再現したかったわけではありません。

FAXという通信手段と番号は残しながら、その前後の業務を検索可能なデータ処理へ作り替えたかった。

以前からOCR検索には苦労していた

紙や画像として保存されたFAXは、後から探すのが大変です。

「以前、この取引先から同じ案内が来ていたはず」「この商品の注文が書かれたFAXはどれだったか」と思っても、画像のままでは受信日やファイル名を頼りに一枚ずつ開かなければなりません。

これまでもOCRを使って検索可能にする方法を試してきました。しかし、文字を読み取るだけでは業務用のFAX検索システムにはなりません。

• OCR結果と原本をどう結び付けるか
• 送信元をどの情報から判断するか
• 原稿内に複数ある電話番号・FAX番号をどう扱うか
• OCRに失敗した原稿をどう処理するか
• 取引先名、日付、分類、本文をどう検索するか
• AI APIの費用をどう抑えるか

FAX検索では、「文字が読めたか」よりも、「どの会社の、いつの、何の文書として保存するか」の方が重要でした。

FAX原本や業務履歴を、全面的に外部へ置きたくなかった

自前運用を選んだ理由には、データの置き場所もあります。

FAXには、取引先名、担当者名、注文内容、数量、価格、納品先、連絡先など、業務上重要な情報が含まれます。

クラウドへ保存することが直ちに危険という意味ではありません。専門事業者へ任せた方が、自社で雑に運用するより安全な場合もあります。

ただし、業務の中心になるデータを外部サービスへ集約するなら、保存場所、保存期間、解約時の書き出し、サービス終了時の移行、利用者や保存量の増加に伴う料金などを考える必要があります。

今回は、FAX原本、アドレス帳、OCR結果、送信履歴、操作履歴などは自社サーバー側へ保持する方針にしました。

AI OCRなどで外部APIを利用する部分はありますが、すべての文書を無条件に送り続けるのではなく、必要な条件を満たしたFAXだけを処理します。完全なローカル処理に固執するのではなく、保管主体は自社に残し、外部APIは必要な部分だけ使う構成です。

サブスクは、導入時よりも抜ける時が難しい

クラウドFAXを採用しなかった理由には、継続的な月額料金もあります。

月額料金そのものが悪いわけではありません。設備の故障対応、セキュリティ更新、冗長化などを事業者へ任せられるなら、料金を支払う価値があります。

問題は、業務の中核へ入ったサービスほど、値上げされたからといって簡単には抜けられないことです。

• 過去のFAXが蓄積される
• 取引先の連絡先が登録される
• 従業員が操作に慣れる
• 通知や承認の流れが固定される
• ほかの業務システムとの連携が増える

ここまで進むと、移行は単なるデータコピーではありません。操作方法、権限、検索、保存期間、社内教育までやり直す必要があります。

クラウドは「抜けられない沼」になりやすい。だから私はオンプレ（自前サーバー）で回している

全部をオンプレミスにすべきだとは考えていません。外部へ任せる価値が高い部分には課金し、業務の核、既存番号との接点、蓄積データはできるだけ自分で握るという考え方です。

完成したシステムの全体像

構成を単純化すると、次のようになります。

取引先のFAX機
      ↓ 今までと同じFAX番号
既存の電話回線
      ↓
OMRON ME5614D2（RS-232C）
      ↓
Debian 13 ＋ HylaFAX
      ↓
自社開発Webシステム
  ├─ 受信・送信FAX管理
  ├─ PDF表示・メール転送
  ├─ アドレス帳照合
  ├─ OCR・AI分類・全文検索
  ├─ タブレット書き込み
  └─ ユーザー管理・監査ログ
      ↓ 必要な文書・ページだけ
外部AI API

サーバー側はDebian 13のベアメタル環境です。HylaFAX、nginx、PHP 8.4-FPM、MariaDB、systemd、外部SMTPを組み合わせています。

FAXモデムには、RS-232C接続のOMRON ME5614D2を使いました。既存回線をそのまま使い、常時稼働する機器として接続経路を単純にするため、物理シリアルポートへ固定しています。

HylaFAXは「土台」であり、完成品ではない

HylaFAXは、電話回線とFAXモデムを使った送受信、送信キュー、受信ファイルの保存などを担当します。

しかし、HylaFAXをインストールしただけでは、社内の誰もが使えるFAX管理システムにはなりません。

• 受信TIFFをPDFへ変換する
• データベースへ登録する
• 受信箱へ表示する
• ページ画像を生成してプレビューする
• メール通知をキューへ登録する
• アドレス帳の番号と照合する
• OCR処理の要否を判断する
• 送信キューとWeb画面の状態を同期する
• 失敗時の再送や取消を扱う

FAX通信を動かす部分と、業務で使えるWebシステムにする部分は、別々の難しさがありました。

自前構築は、誰にでも勧められる方法ではない

• モデムや電話回線の調整が必要
• OS、HylaFAX、Webアプリの更新が必要
• 障害時に自分で切り分けなければならない
• バックアップと復元手順を用意する必要がある
• 外部公開するなら認証とセキュリティ設計が必要
• 運用担当者がいなくなると保守できなくなる

FAXをメールで受け取りたいだけなら、クラウドFAXや対応複合機の方が合理的です。

今回の自前構築は、既存番号の維持、送信元判別、全文検索、タブレット編集、返信、履歴管理までを自社業務に合わせたいという要件があったから成立しています。

まとめ

FAXを廃止できなくても、FAX機を中心に仕事を続ける必要はありません。

そして、システムを新しくするために、必ずFAX番号まで変える必要があるわけでもありません。

取引先には今までどおり同じ番号へFAXしてもらう。
自社側では、受信したFAXを検索可能な業務データへ変え、メールで共有し、タブレットから返信する。
そのために、既存回線とHylaFAXを土台に自社構築した。

次回は、既存FAX番号の回線をOMRON ME5614D2へ接続し、Debian 13上のHylaFAXで送受信するまでの構成を紹介します。

参考資料

• NTT西日本：双方向番号ポータビリティの開始について
• インターコム：FAX番号を変えずにクラウドFAXを利用する方法