AI駆動開発時代でも、弊社がFileMakerプラットフォームを重要な開発基盤の1つとして持ち続ける3つの理由
こんにちは。ライジングサン・システムコンサルティングの岩佐です。
ここ1〜2年で、生成AIを活用したソフトウェア開発は、一気に現実的なものになってきました。弊社でも、Cursor などのAIエディタを活用しながら、一般的なWebアーキテクチャでの開発を進める機会が明らかに増えています。実際、案件によっては GCP / TypeScript / Angular / Cloud Functions for Firebase といったスタックで実装することも、すでに珍しくなくなってきました。
そうなると、自然にこうした問いが出てきます。
「FileMakerは、AI駆動開発の時代にも、本当に必要なのか？」
結論から言えば、弊社にとって答えは Yes です。
ただし、その意味は少し変わりました。以前のように、「何でも FileMaker で作る」という発想ではありません。汎用的な SaaS プロダクトや、一般的な CRM / SFA のようなアプリケーションをゼロから提供するのであれば、最初から一般的な Web アーキテクチャで構築した方が合理的な場面も多いと思います。わざわざ FileMaker のライセンス料をユーザ企業に負担していただいてまで、FileMaker で作る必然性がないケースも、確かにあります。
それでもなお、私たちは今後も FileMaker プラットフォームを重要な開発基盤の1つとして持ち続けるつもりです。そこには、感覚的な愛着ではなく、きちんと論理的な理由があります。
本記事では、その理由を3つに整理してみたいと思います。
0. 私たちは「FileMakerだけの会社」ではなくなっている
弊社の最近の傾向としましては、案件ごとに FileMaker と Web をハイブリッドに融合し、ビジネス要求とコストバランスに最もマッチする構成を考える場面が増えています。
例えば先日カットオーバーした介護施設向けの案件では、バックエンド DB は FileMaker でありながら、フロア業務向けのモバイル機能は GCP / Angular / Cloud Functions for Firebase という、一般的なWebアーキテクチャで実装しました。
この案件では、【通所介護計画書】や【個別機能訓練加算計画書】といった法定書類の作成業務は、PC の広い画面が必要であり、業務密度も高いため、FileMaker WebDirect 側で実装しています。一方、利用者のバイタル入力や、個別機能訓練の実施記録入力等は、iPhone / iPad で使う前提の Web アプリケーションとして実装しました。
もしこれをフル FileMaker で作れば、現場スタッフを含めた全員分のライセンスが必要になります。一方で、全てをWebで開発した場合、複雑な罫線の入り組んだ帳票の実装や、極めて複雑な入力操作を求められるユーザインタフェース構築、そして３年に１回の介護保険制度改定に伴う継続的な仕様追加・仕様変更を考慮すると、開発費用、及び運用・保守費用は想像以上に高価になることは、想像に難しくありません。
しかし、業務ごとに実行基盤を分けることで、FileMakerのライセンスフィーは節約しつつ、現場スタッフ全員がソフトウェアを使った業務の効率化を実現することが可能です。このようなWebアーキテクチャとFileMakerプラットフォームのハイブリッド構成は、特に多店舗展開・多拠点展開の業態で、大きなライセンスフィーの節約効果を実現できます。
つまり、私たちの現在地は「FileMaker か Web か」の二択ではありません。
「どの業務を、どの基盤で動かすのが最も合理的か」を設計すること。
そこが出発点です。
それでは、わざわざバックエンドをFileMakerで作ること無く、「Webフルスタックで実装すればよいのでは？」という疑問も出てきます。しかし、FileMaker には他の基盤で簡単には代替しにくい役割があります。以下、その3つを順に書いていきます。
1. ユーザ企業と開発会社の「共通言語」として機能するから
FileMaker を使い続ける最大の理由の1つは、ユーザ企業様と弊社とのあいだに、非常に強い「共通言語」を作りやすいことです。
これは、単に画面が早く作れるとか、ローコードで便利だとか、そういう話だけではありません。もっと本質的には、「どんなソフトウェアを作るか」という合意形成のやり方そのものが、FileMaker を使うことで大きく変わる、という話です。
1-1. 成功した内製化支援の本質は、RFPではなく「動くプロトタイプ」にあった
弊社がこの10年で取り組んできた内製化支援の中でも、特に象徴的だったのが、樫山工業様の事例です。
この事例では、製造現場の部門内で閉じるソフトウェアは現場主導で完全内製し、部門横断のシステムや基幹系と連携するシステムは、内製とアウトソーシングを組み合わせる、という形が採られていました。
ここで非常に面白いのが、役割分担です。
「どんなソフトウェアを作るか」という要件定義にあたる部分は、樫山工業様の情シス部門のご担当者様が FileMaker を使って自らプロトタイプを作り、社内で合意形成を行う。 次に、合意を得た FileMaker のプロトタイプを弊社が受け取り、完成版のプロダクトへと仕上げていく。
このフォーメーションでは、一般的な RFP や設計書ベースの受託開発と比べて、手戻りが圧倒的に少なくなります。
理由はシンプルです。文書ベースの要件定義では、画面遷移や入力感、一覧の見え方、帳票の雰囲気、例外ケースの扱いなど、実際に触って初めて分かることが大量に残ります。一方、FileMaker で作られたプロトタイプには、そうした業務アプリとしての手触りがかなり含まれています。
例えば、
- 一覧の並び順が違うと現場では使い物にならない
- 帳票で1項目欠けるだけで法定書類として成立しない
- 入力手順が1画面増えるだけで現場運用が止まる
といった差分は、文書レビューだけでは見落とされやすく、実際に動くソフトウェアを、エンドユーザ自身が、実業務に即して操作した時に、はじめて顕在化します。
つまり、FileMaker のプロトタイプは、単なるモックアップではありません。かなり実行可能な仕様書に近いものになります。
1-2. 「Whatを決める道具」と「Howを仕上げる道具」がつながっている
このやり方が強いのは、社内側が FileMaker で作ったプロトタイプと、開発会社側が受け取って仕上げる完成版との距離が近いからです。
例えば、Figma でUIのモックを作り、それをもとに別の技術スタックで本番実装する、という流れは一般的な合意形成フローの１つだと思います。しかし、この場合は「見た目としての合意」は得られても、データ構造や検索の癖、運用時の入力導線、帳票や集計の都合などが、後からずれてくることが少なくありません。
一方、FileMaker では、社内側が作る試作品の時点で、すでに業務システムとして重要な構造がかなり表現されます。中には数カ月、社内でプロトタイプを動かしていただいたおかげで、貴重な実データが蓄積されているケースもあります。
だからこそ、弊社のような外部開発会社がそれを受け取ったときにも、「何を作るのか」をすばやく理解しやすい。
この「What を決める道具」と「How を仕上げる道具」が、同じ文脈の中にあること。
これが、FileMaker を共通言語として使う価値だと感じています。
1-3. AI時代になると、この価値はむしろ強くなる
一見すると、AI駆動開発の時代には、こうした FileMaker ベースのプロトタイピングは不要になるようにも見えるかもしれません。自然言語で要件を伝えれば、AI がアプリケーションをある程度作ってくれるからです。
しかし、実際には逆だと思っています。
AI が粗く作ったものを、現場が見て、「これは違う」「ここは使いにくい」「この項目が足りない」と具体的に修正していくには、やはり動くプロトタイプが必要です。そして、そのプロトタイプをエンドユーザ自らが、ある程度自分たちで触れることが重要です。
このようにユーザ企業自身が、自ら手を動かし、プロトタイプシステムを持ちて社内間での合意形成を構築する基盤として、FileMaker は極めて有効な開発プラットフォームだと考えています。
2. 医療・介護・製造業のような専門業務を、「日本語のまま」実装できるから
FileMaker を使い続けるもう1つの大きな理由は、物理 DB やビジネスロジックを、日本語のまま実装できることです。
これは一見すると地味な話に見えるかもしれませんし、普段、汎用的なプログラミング言語で開発をされているエンジニアさんは「ルー語みたいで気持ち悪い」と思うかもしれませんね（笑）
しかし、実際にこれは、かなり大きな価値があります。
2-1. 英語の物理名は、専門業務では想像以上に脳内リソースを消費する
例えば、介護・医療・製造業のように、業務そのものが専門用語の塊でできている領域があります。
通所介護計画書、個別機能訓練計画、要介護認定履歴、診療行為識別、製造命令、e.t.c…
こうした言葉は、単なるラベルではなく、そのまま業務の意味そのものです。
ところが、一般的な Web アーキテクチャで DB 設計や API 設計を行うと、どうしても物理テーブル名・フィールド名は英語になります。
もちろん、英語で命名すること自体が悪いわけではありません。国際化や汎用性の観点では合理的ですし、一般的なソフトウェア開発では自然な慣習です。
ただ、日本の専門業務システムを作る場面では、これが意外と大きな認知負荷になります。
functional_training_plan を見て、個別機能訓練計画のことだと即座に頭の中で結びつけられるか。
care_level_certification_history を見て、要介護認定履歴のことだと一発で想起できるか。
例えば介護業務では、「通所介護計画書」と「個別機能訓練計画」は、どちらも”計画”という言葉を含みますが、制度上の位置づけも、作成目的も、参照される場面も異なります。これを care_plan や training_plan のような英語の物理名に置き換えること自体は可能です。しかし実際には、実装を読むたびに「これはどの帳票のことか」「どの記録や加算とつながるのか」を頭の中で補わなければならない場面が出てきます。
しかも、こうした補完は、人によって微妙に解釈がずれることがあります。現場でははっきり別物として扱っている概念でも、英語にした瞬間に、実装の中では少し輪郭がぼやけてしまうことがあるのです。
こうした変換は、1回1回は小さくても、積み重なるとかなり脳のリソースを使います。
2-2. FileMaker は「業務用語」と「実装用語」の距離が極端に短い
FileMaker の良さは、テーブル名・フィールド名だけでなく、スクリプト名や関数名まで、日本語を含んだ形で実装できることです。
例えば 通所介護計画書.update のような名前を、そのまま実装として成立させることができます。
これはかなり大きいです。
その名前を見た瞬間に、
- どの業務概念を扱っているのか
- 何をする処理なのか
- どの画面や帳票に近いのか
が、ほぼそのまま頭に入ってきます。
つまり、業務を理解することと、実装を理解することの距離が非常に短い。
これが、FileMaker の本質的な価値の1つだと思っています。
2-3. 現場スタッフ・情シススタッフ・開発エンジニア、そしてAIの全員にとって都合が良い
この「日本語で実装できる」という特徴は、単に開発者がラクをするための話ではありません。
現場スタッフが見ても分かる。 情シススタッフが見ても分かる。 弊社のエンジニアが見ても分かる。 そして、後述するように、AI エージェントにとっても理解しやすい構造を作りやすい。
要するに、業務言語と実装言語のズレを小さくできるのです。
このズレが小さいことは、設計や保守や会話の認知コストを全体として下げます。派手ではありませんが、実務では非常に効くポイントです。
その意味で、FileMaker は「日本語で考え、日本語で議論し、日本語で実装し、日本語で保守しやすい」基盤だと言えます。
特に専門用語の多い業界では、この価値は思った以上に大きいと感じています。
3. AI駆動開発と対立するどころか、むしろ相性の良い使い方があるから
ここまで読むと、「でも FileMaker は AI駆動開発と相性が悪いのでは？」と感じる方もいるかもしれません。
この点については、半分は Yes、半分は No だと考えています。
確かに、一般的な Web 開発と比べると、FileMaker そのものの開発体験は、今の AI コーディング支援の流れに完全には乗っていません。Cursor や Devin のようなツールが最も力を発揮しやすいのは、やはり HTML / CSS / JavaScript / TypeScript / Python といった、広く共有されたテキストベースのコード資産です。
しかし、だからといって FileMaker が AI時代に不利かというと、実際にはそう単純ではありません。
3-1. Webビューアを積極活用してきた弊社の文脈では、AIとの協業はすでにかなり進んでいる
弊社では以前から、FileMaker の Webビューアを積極的に活用し、その中で Webix などの JavaScript UI ライブラリを使った、リッチな操作性の業務アプリケーションを多数開発してきました。
この構成では、Webビューア内で動く部分は純粋な HTML / CSS / JavaScript です。つまり、AI が最も得意とする領域が、そのまま FileMaker の中に埋め込まれている、とも言えます。
特に、弊社が以前から情報発信してきた FullCalendaer や Chat.js を Webビューアに組み込む実装体験は、生成AI と非常に相性が良いです。
その意味で、弊社は FileMaker を使いながらも、実はかなり早い段階から「ハイブリッドな AI 駆動開発」に向いた開発スタイルを持っていたのだと思います。
3-2. TypeScript が、日本語の業務世界と Web の実装世界の「通訳」になってくれた
もう1つ大きかったのが、FileMaker をバックエンド DB としつつ、Web バックエンドを TypeScript で実装したときの経験です。
このとき強く感じたのは、TypeScript が「英語の実装世界」と「日本語の業務世界」のあいだの通訳層として機能してくれる、ということでした。
例えば、TypeScript 側では functional_training_plan のエンドポイントを GET で取得しても、FileMaker から OData API で取得したレスポンス JSON のキー、つまりフィールド名は日本語のままです。
素の JavaScript だと、ここで変換漏れや理解漏れが起きやすくなります。しかし、TypeScript では API 境界のレスポンス型を定義し、日本語キーと内部の型とを対応づけることで、この問題をかなりきれいに整理できます。
例えば、FileMaker 側のレスポンスに 利用者ID 訓練マスタID 実施日 といった日本語キーが含まれていたとしても、Web アプリケーションの内部では、それを patientId trainingMenuId performedAt のような内部型に変換して扱えます。
つまり、API 境界では日本語の業務語彙を壊さずに保ちつつ、アプリケーション内部では整理された型安全な世界を維持できる、ということです。
要するに、
- API 境界では日本語
- アプリケーション内部では整理された型
- 両者の対応は型定義と mapper に集約
という形にできるわけです。
これは人間にとって読みやすいだけでなく、AI にとっても理解しやすい構造になっていました。
3-3. 「型付き翻訳レイヤー」は、人間だけでなくAIの認知負荷も下げる
このプロジェクトでは、LLM との協業がかなりスムーズでした。その理由の1つは、まさにこの翻訳レイヤーにあったのではないかと思っています。
通常、業務システムのコードベースには、
- 英語のテーブル名
- 日本語の業務用語
- UI 文言
- API のレスポンスキー
- 現場で使う略称
が混在しがちです。こうなると、人間にとっても AI にとっても、「この言葉は何を指しているのか」を毎回推論しなければならなくなります。
ところが、型定義や mapper を1箇所にまとめておくと、そこが「業務語彙辞書 + 境界仕様 + 変換ルール」として機能します。人間も AI も、まずそこを読めば、システム全体の語彙対応を低い認知負荷で理解できます。
これは、弊社の中ではかなり重要なベストプラクティスだと感じています。
FileMaker が持っている「日本語の業務ドメインをそのまま表現しやすい」という強みと、TypeScript が持っている「その業務ドメインを安全に翻訳しやすい」という強み。
この2つを組み合わせることで、AI との協業もかなり安定させることができました。
つまり、FileMaker は AI時代に取り残される基盤なのではなく、使い方次第で、むしろ AI と相性の良い開発基盤の一部になり得る、ということです。
4. だから弊社にとって、FileMakerは「万能基盤」ではなく「重要基盤」である
ここまで書いてきたことをまとめると、弊社が FileMaker を使い続ける理由は、次の3つに整理できます。
- ユーザ企業と開発会社の共通言語として、動くプロトタイプによる合意形成を支えられるから
- 医療・介護・製造業のような専門業務を、日本語のまま実装し、認知負荷を下げられるから
- Webビューアや TypeScript との組み合わせにより、AI駆動開発とも十分に両立できるから
大事なのは、これらの理由が「何でも FileMaker で作るべきだ」という話ではないことです。
むしろ逆で、汎用的な Web アプリケーションや SaaS プロダクトについては、最初から一般的な Web アーキテクチャを採用した方が合理的なケースも多いと、私たちは考えています。
その上でなお、FileMaker にしか出しにくい価値がある領域が確かに存在する。
私たちは、すべての案件に FileMaker を適用したいとは考えていません。
逆に言えば、こうした条件が活きにくい案件については、必ずしも FileMaker を前提にする必要はないとも考えています。私たちが目指しているのは、「何でも FileMaker で作る」ことではなく、FileMaker が本当に価値を発揮する領域に絞って活用していくことです。
だからこそ、弊社にとって FileMaker は、唯一の基盤ではなくても、重要な基盤の1つであり続けます。
5. おわりに：AI時代になったからこそ、FileMakerの役割が見えやすくなった
AI駆動開発の時代になって、一般的な Web アーキテクチャの価値は間違いなく高まりました。弊社自身も、その恩恵を大きく受けています。
一方で、その変化があったからこそ、逆に「それでも FileMaker を使う理由」が、以前よりはっきり見えるようになってきたとも感じています。
汎用アプリを作るための基盤としてではなく、 専門業務を顧客と共創するための基盤として。 業務言語と実装言語のズレを小さくするための基盤として。 そして、日本語の業務ドメインを壊さずに、AI と協業するための基盤として。
そういう役割において、FileMaker は今でも十分に重要です。
私たちはこれからも、FileMaker に固執するのではなく、Web や AI と組み合わせながら、適材適所で使っていこうと考えています。