本文へスキップ
NeoLogic
NeoLogic

請求書は今のまま、受付だけブラウザへ。FileMakerを全部やめない移行の選び方

請求書の印刷は残し、取引先からの受付だけをWebへ移す方法もあります。3つの業務例と比較表で、継続利用・WebDirect・一部Web化・全面移行を選び、見積り前にそろえる条件を整理できます。

FileMakerの請求業務を残し、Webの受付とつなぐ構成。

FileMakerを使い続けるか、WebDirectか、Web移行かは、残す業務と変えたい業務を分けて選びます。ブラウザを使いたい業務が一つだけなら、請求締めと印刷を残し、取引先の受付だけを変える案から考えられます。

「取引先からの受付だけブラウザにしたい。でも、毎月の請求書は今のまま出したい」。FileMakerを引き継いだとき、まず分けたいのは、残す業務と変えたい業務です。画面が古く見えることや、レイアウト数の多さだけでは、作り直す理由にはなりません。

会社のFileMakerを全部やめる必要はありません。既存画面を使うWebDirectと、別のWeb画面を作ってつなぐ一部Web化では、準備も保守する範囲も変わります(出典:Claris「FileMaker WebDirect architecture」)。

以下の3業務は、公開資料を基にした架空の整理例です。候補を選ぶ説明の後に、調査担当者が確かめる環境・権限・データの項目をまとめます。

受付だけWebにしても、締めた請求書は変えない

B02の取引先受付をWebへ分けるなら、B01の請求締めまで一緒に作り替える必要があるかを先に確かめます。次は、受付番号R-101から請求番号I-051へ渡す架空の確認例です。画面が開くことに加え、一件の注文が最後までどう扱われるかを調べます。

試す場面 記録する結果 方針を決める材料
R-101を受け付け、FileMakerへ渡す Web側の受付番号と既存側の注文番号が対応し、請求対象は一件 番号の対応を保存できるか
受付後に通信が途切れ、利用者が再送する 登録済みの結果を照会でき、同じ受付が二件にならない 照会先と再送の条件
I-051を締めた後、R-101の数量を訂正する 訂正前の請求書、訂正理由、次の処理が追える 締め後の修正を既存側と新画面のどちらで扱うか

この表はFileMakerでの実行結果ではありません。現行ファイルと連携先で試し、スクリプトの名前だけでなく、受付番号・注文番号・請求番号をそろえて記録します。再送の調べ方は注文登録後に応答が途切れる再現教材で確認できます。

Clarisの構成説明では、WebDirectはServerまたはCloudにあるカスタムAppへブラウザから接続する方式です(2026年10月26日確認)。ブラウザ化の後も残る管理と、別のWeb画面との連携を増やす管理を、上の三場面に照らして比べてください。

先に、三つの業務の行き先を分ける

次の3件は想定例です。想定版はPro 26.0.2/Server 26.0.2です。「残す・接続・移す」は候補であり、不足情報が解消するまで確定しません。

候補の理由は、次のように業務の困り事から考えます。

  • 請求締め・印刷は、今の帳票で取引先の指定書式に対応でき、社内で支障なく使えているため、継続利用を候補にします。
  • 取引先受付は、相手がFileMaker Proを持たず、入力する項目も社内用より少ないため、受付用のWeb画面を候補にします。既存画面をブラウザで使うWebDirectで足りるかも比べます。
  • 備品貸出は、担当者のPCでしか更新できず、申請者も空き状況を確認できない想定です。他の業務から独立していることを確かめたうえで、申請から返却までブラウザで扱う方法を候補にします。
業務ID・用途 FileMakerの画面 候補 先に確かめること
B01 請求締め・印刷 販売管理.fmp12/請求入力・請求書印刷 残す:現状維持 会計へ正しく取り込めたか/夜間に送れなかった分の扱い/帳票の見本
B02 取引先受付 販売管理.fmp12/受付入力 接続:一部Web化 誰がログインするか/受付内容の保存先/送信失敗時の確認/既存画面で足りるか
B03 備品貸出申請 貸出管理.fmp12/貸出申請・返却一覧 移す:対象業務の全面移行 年度末の作業/他のFileMakerからの参照/旧環境へ戻す方法

利用確認状態は「未確認」「一部確認」「確認済み」などに分け、確認者、日付、見た資料を残します。「担当者が知らない」と「使われていない」は別です。記入例のB03も、独立した業務という仮定を置いた段階で、停止や削除を決めたものではありません。

残す業務と変える業務で、四つの方法を比べる

ここで比べるのは、既存FileMakerの利用・移行方針です。現状維持は必要な改修を含む継続利用、WebDirectは既存FileMakerのブラウザ利用、一部Web化は別Webアプリと残す部分の連携、全面移行は対象業務を別基盤へ移す方針と定義します。業務ごとに併用できます。

表の「向く条件」「見送る条件」は、公式仕様を参照した判断材料です。必要な機能や速度、費用は利用する環境で確かめます。

方法 どこを変えるか
現状維持・必要な改修 今の画面や帳票を使い、困る箇所を直す
WebDirect FileMakerを残し、対応する画面と処理をブラウザで使う
一部Web化 受付などを別のWeb画面にし、残すFileMakerとつなぐ
対象業務の全面移行 その業務の画面・処理・データを別の基盤へ移す

データの置き場所と、移行を見送る条件

比較項目 現状維持 WebDirect 一部Web化 全面移行
利用者 既存の利用者・端末を中心に継続 権限を与えたブラウザ利用者 別Webの利用者とFileMaker利用者 対象業務の利用者を新基盤へ移す
画面・帳票 既存を活用し、必要箇所を改修 既存レイアウトを基に互換性を確認 対象画面を新設し、残す帳票は継続 必要機能・帳票を新基盤で再設計
データ所在 FileMaker・既存の外部データ FileMaker・既存の外部データ 正本と更新元をデータごとに固定 対象データを新基盤へ移す
外部依存 既存連携を確認して維持・更新 端末内処理と外部接続を再確認 新旧間の連携・再送・照合を設計 連携先・認証・定期処理を組み直す
既存資産の扱い レイアウト・スクリプト等を継続 既存定義を活用し、非対応部分を調整 残す部分と作り直す部分を分割 定義は調査資料に使い、別途実装
保守の分担 FileMakerと周辺環境を保守 FileMakerとブラウザ利用環境を保守 両基盤と連携部分の担当を決める 移行後は新基盤。旧環境の終了も管理
向く条件 業務に合い、更新・保守を続けられる 既存業務のままブラウザ利用を増やす 受付など切り分ける業務が明確 対象全体を再設計する理由がある
見送る条件 必須の業務変更に対応できない 必須処理の機能差を解消できない 更新競合や連携障害を管理できない 照合・切替・復元条件がそろわない

この表は、Claris「データベースのスキーマのドキュメント化」、Claris「Using FileMaker WebDirect」、Claris「レイアウトとレポートの作成と管理」、Claris「ステップ 2: FileMaker WebDirect 機能の理解」、Claris「ステップ 8: カスタム App の関数、スクリプト、およびスクリプトトリガのレビュー」、Claris「FileMaker WebDirect architecture」の公式説明をもとにしています。

WebDirectでは、既存機能の対応状況を確かめる

WebDirectでは利用者に対応する拡張アクセス権を設定し、ホスト側も準備します。一方、Proの表形式やカスタムメニューは同じようには使えません。対応しないスクリプトステップが飛ばされ、その後の処理が続く場合もあるため、「エラーが見えなかった」だけで合格にしません(出典:Claris「Using FileMaker WebDirect」/Claris「ステップ 2: FileMaker WebDirect 機能の理解」/Claris「ステップ 8: カスタム App の関数、スクリプト、およびスクリプトトリガのレビュー」)。

端末内の決まったフォルダへファイルを置く処理も注意点です。WebDirectのスクリプトはクライアントのファイルシステムへ直接アクセスできず、保存・出力したファイルはブラウザのダウンロード先へ渡されます。B01の会計CSV出力は実行場所を確かめ、印刷、添付、権限ごとの操作まで対象環境で検証してから利用範囲を決めます。

請求業務をWebDirectで試すなら、「請求発行」を押した後に、次を続けて見ます。ボタンが押せたことだけで、元の仕事を再現できたとは判断しません。

場面 見る結果
請求明細の入力 必要な画面操作がブラウザでもできるか
請求確定・会計CSV出力 必要な処理が飛ばされず、会計に渡すCSVができるか
CSVの保存と受け渡し ブラウザのダウンロード先から、決めた担当が会計へ渡せるか
印刷・添付・権限 帳票が収まり、添付を開け、利用者ごとの制限が働くか

印刷を残し、受付だけ変える判断もできる

取引先受付(B02)は、既存の画面と権限設計で要件を満たせるならWebDirectも候補です。取引先向けに別の受付体験が必要なら、一部Web化を比べます。その場合は、どちらを正本にし、誰がどこから更新するか、送信失敗を誰が直すかを先に決めます。FileMaker側の請求・印刷を残すことと矛盾しません。

備品貸出(B03)の「全面移行」は、貸出申請という対象業務の全体を指す想定です。会社のFileMaker全体を廃止する意味ではありません。年度末処理や他ファイルからの参照が見つかったら、切り離せるという仮定を見直し、連携を残す案へ戻します。

調査担当者用:環境・処理・データのチェックリスト

候補を決める前に、今の処理を誰の権限で調べられるか、帳票とデータを引き継げるかを調べます。ここからは、棚卸し表へ記入するための項目です。

1. 環境と権限から、取得できる資料を分ける

最初に、FileMaker Proの版、共有先がServerかCloudかとその版、OS、プラグイン、管理担当を記録します。「FileMakerを使っている」だけでは調査条件が揃いません。端末側だけの更新を先に決めず、接続先との対応も調べます。2026年版のProは26系です。利用中の版は端末とホストで個別に見ます(出典:Claris「Claris FileMaker Pro リリースノート」/Claris「Claris FileMaker Server Release Notes」/Claris「Claris FileMaker Cloud Release Notes」)。

ファイルの完全アクセス権と、Server・Cloudの管理権限は別の欄に記入します。構造XMLとDDRの作成には、対象ファイルをProで開き、完全アクセス権を持ち、高度なツールを利用できる状態にする必要があります。引継担当に権限がなければ、管理者に出力を依頼し、未取得の範囲を残します。

資料 何を見るか 取り違えないこと
構造XML テーブル・計算・レイアウト・スクリプト等の定義 レコードデータは含まれません
DDR(HTML/XML) 構造と参照関係を見るレポート 構造XMLとは別の出力。復元用バックアップではありません
レコードのエクスポート 許可された範囲の実データ・出力条件 選択したレコード・項目の出力。構造一式は別途保存します
復元用バックアップ ファイルと必要な添付等の保存対象・復元記録 構造資料やCSVで代用できると判断しません

この表は、Claris「データベースのスキーマのドキュメント化」とClaris「FileMaker Pro からのデータのエクスポート」をもとにしています。

なお、レコードをXML形式でエクスポートする機能もあります。拡張子だけで判断せず、構造保存のXMLとレコード出力のXMLを区別します。資料には対象ファイル、取得日時、出力したProの版、除外した要素を添えます。XMLの差分を比べるなら出力元のProの版をそろえます。構造資料にも機密情報が含まれ得るため、共有先は必要な担当者に限定します。

2. レイアウトを、入力・印刷などの用途に結び付ける

レイアウトはデータの見せ方です。同じデータを、入力用、請求書印刷用、集計用の複数の画面に表示できます。同じフィールドを表示しているなら、入力用で変えた内容が印刷用にも反映されます。レイアウトを複製した数を、そのまま移すデータの種類として数えないようにします(出典:Claris「レイアウトとレポートの作成と管理」)。

棚卸し・4方式比較のExcelでは、業務IDを付け、ファイル、レイアウト、用途、利用者、頻度、スクリプト、テーブル、接続先を同じ行で追います。レイアウト名だけで決めず、請求書なら締日、再発行、用紙、出力先、誰が合格を判断するかまで聞きます。月次・年次だけ使う帳票も対象です。

3. ボタンの先から、計算・トリガ・外部参照を辿る

DDRや構造XMLは、名称の一覧を作るためだけでなく、重要業務から依存関係を辿る補助に使います。どのテーブルを読み書きし、どの関係や計算を使い、どのスクリプトが別の処理を呼ぶのかを、業務IDへ戻して記録します。外部ファイルやプラグインがあれば、実行される端末・ホストも調べる対象にします。

たとえばB01は「請求発行」ボタンから「請求確定」「会計CSV出力」へ進む想定です。請求と請求明細の関連、対象期間、再発行時の扱い、CSVの出力先まで追います。テーブル名だけでは対応が分からない場合は、レイアウトが参照する関係上の名称と、実データを持つ基本テーブルを管理者に照合してもらいます。

ボタン以外の起動も忘れません。スクリプトトリガは、画面やオブジェクトの操作、ファイルを開く・閉じるといったイベントでも処理を起動できます。画面上のボタンが消えていても、そのスクリプトが別の経路から呼ばれていないかを調べます(出典:Claris「スクリプトトリガの設定」)。

さらにServerには定期実行の仕組みがあります。B01では、毎日02:00(JST)に未送信分を再出力する処理がある想定です。日中の操作観察だけでは拾えないため、管理者にスケジュール、実行履歴、OS側処理や外部システムからの呼出しを問い合わせます。見つからないものは「調べた範囲では未確認」と記録し、不要と断定しません(出典:Claris「Scheduling administrative tasks」)。

4. レコード・添付・外部送信は、構造とは別に確かめる

データ確認では、基本テーブルごとの件数、集計した時点、抽出条件、識別用のID、空欄・重複、親子の関連をそろえます。件数を比較するときは、全件か検索結果か、明細か小計かも固定します。エクスポートは対象レコードや出力フィールドを選ぶため、出力できたことだけでは全件を移せた証拠になりません(出典:Claris「FileMaker Pro からのデータのエクスポート」)。

PDFや写真などの添付は、オブジェクトフィールドの内部保存か外部保存か、実体の所在、件数、開けるかを別に記録します。移行用の文字コード、日付、改行、コードの先頭ゼロも照合項目です。

外部送信には、送信先、実行条件、使う権限、失敗時の再送、受信側での受け取りの見方を付けます。B01なら、CSVが作られたことと会計側で取り込まれたことを分けます。B02なら、受付番号を手掛かりに、未達と重複を見つけられる設計が必要です。認証情報そのものは棚卸し表へ書かず、管理担当と保管ルールを記録します。

まず、残したい帳票と変えたい受付を一つずつ選び、今の困りごとを書き出します。見積りへ渡す順序は下図のとおりです。環境記録から構造資料、業務別の棚卸し、実運用の観察、方式候補へ進みます。権限不足は管理者への取得依頼へ、依存関係の不明点は棚卸しへ戻します。最後に、範囲と合否条件を受渡し先とそろえます。

環境・権限の把握から業務の棚卸し、実運用・データの照合、方式比較、見積条件の受渡しへ進む5工程。各工程の担当と、不足情報があるときの戻り先を示す図。

図 判断と受渡しの流れ。実線は次の工程へ進む順序、破線は不足情報があるときの戻り先。

見積り前に、移す範囲と戻し方を決める

方式名だけで見積りを依頼せず、並行運用中の入力先と期間、帳票の合格見本、認証・権限、データ照合の対象と許容差、切替後に増えた入力を戻す方法、判断者と期限を渡します。継続保守、移行開発、新旧連携、並行運用の費用も同じ対象期間で比べ、根拠のない金額や削減率は置きません。

照合と切り戻しの具体化は、システム移行の切り戻し|新しい注文と訂正の扱いで説明しています。Accessも併用している場合は、FileMakerと混ぜずに、Access・VBAのWeb移行|残す範囲の決め方で別に整理してください。

棚卸しの結果、残す帳票と変える受付の間で連携や記録の課題が残る場合は、業務ID、そろった資料、不足情報を添えてご相談ください。

外出先の入力だけをWebへ移し、今の帳票を残す範囲は、FileMakerのWeb移行で具体例を紹介しています。

移行費用を判断するときは、現状維持や部分改修を含む36か月の比較も使えます(古いシステムを直すか作り直すか|36か月費用の比較)。

FileMakerの調査と移行の相談窓口

参考出典

仕様確認日:2026年9月15日。Clarisの公開ヘルプと2026年版(26系)のリリースノートを参照しています。

あわせて読む