業務システムの内製化を進めるなら、FileMaker と AI エージェント前提の Web 開発のどちらを軸にすべきか

こんにちは。株式会社フルーデンスの小巻です。

AI エージェントの進化によって、業務システムの内製化の進め方は大きく変わりつつあります。本記事では、FileMaker のような統合型ローコード基盤と、AI エージェント前提の Web 開発を比較し、どちらを主軸に据えるべきかを整理してみたいと思います。

目次

1. はじめに
2. なぜ今、内製化が重要なのか
3. 前提として押さえたい比較軸
4. FileMaker の強みと向いている場面
5. AI エージェント前提の Web 開発の強みと考慮事項
6. これから何が変わるのか
7. 担当者が交代した場合の備え
8. まとめ

1. はじめに

AI エージェントの進化によって、以前は外注や専門職に頼ることが多かった業務システム開発にも、新しい選択肢が出てきました。私自身も実際に AI エージェントを業務や開発支援で使う中で、従来の「ローコードか、フルスクラッチか」という二択では整理しきれない変化を感じています。

たとえば最近の AI エージェントでは、「QR コードを生成する FileMaker プラグインを作って」と伝えるだけで、1 行もコードを手で書かずに動く成果物が出てくる場面もあります。技術支援先でも AI エージェントを活用した内製化支援を進める中で、「FileMaker とどう使い分けるべきか」という問いが、以前よりずっと現実的になってきたと感じています。

現時点の私の結論としては、これから新たに内製化を進めるなら、主軸は AI エージェント前提の Web 開発に置く方が合っていると考えています。

ただし、これは「今すぐ FileMaker から移行を検討すべき」という意味ではありません。すでに FileMaker に大きな資産がある企業、IT 担当者が少ない企業、移行リスクを取りにくい企業では、引き続き FileMaker が有力な選択肢になる場面もあります。

また、この記事は単純に点数を付けて優劣を決めるためのものではありません。金額だけでなく、引き継ぎやすさ、外部支援を受けやすさ、運用を続けながら改善しやすいかも含めて、「どこを主軸に置くと無理が少ないか」を整理するための記事です。

この記事では、感覚的な好き嫌いではなく、次のような判断基準をもとに比較していきます。

2. なぜ今、内製化が重要なのか

以前は、業務システムを自社でフルスクラッチ開発するのは、多くの企業にとって現実的ではありませんでした。専門のエンジニアを採用し、長い開発期間と継続的な保守体制を前提にする必要があったからです。

そのため、プログラミング経験が少ない企業でも取り組みやすい手段として、FileMaker のようなローコードツールが広く使われてきました。これは今でも十分に妥当な選択肢だと思います。

一方で、AI エージェントの登場により、従来より少ない人数でも設計、実装、レビュー、改善のサイクルを回しやすくなってきました。内製化のハードルが下がったというより、内製化に取り組める企業の範囲が広がったと捉えた方が正確かもしれません。

ただし、AI エージェントは魔法ではありません。内製化がうまくいきやすいのは、少なくとも次のような条件がそろう会社だと考えています。

また、すべてを内製化する必要はありません。競争優位につながる部分を内製化し、汎用的な業務は SaaS を使う方が合理的なことも多くあります。

3. 前提として押さえたい比較軸

この記事で比較しているのは、単純な「FileMaker vs AI ツール」ではありません。実際には、次の 2 つを比較しています。

この整理を先にしておかないと、途中で比較軸がずれて見えてしまいます。重要なのは、どちらが絶対に優れているかではなく、自社にとって何を最優先にするかだと思います。

なお、ここで挙げている比較軸は、厳密な採点表として使うためのものではありません。実際には、初期費用や運用費だけでなく、担当者が替わったときの再建コスト、外部支援を受けやすいか、どこまで安全に改善し続けられるかまで含めて見ておく必要があります。

また、両者に共通する課題もあります。

この共通点を踏まえたうえで、それぞれの特徴を見ていきたいと思います。まずは、立ち上がりの速さや既存資産との相性という観点から FileMaker 側を見ていきます。

4. FileMaker の強みと向いている場面

FileMaker の強み

FileMaker の最大の価値は、業務アプリを短期間で形にしやすいことです。

特に、「小さく始めてすぐ現場で使いたい」「専任エンジニアはいないが、担当者が少しずつ育てたい」という状況では、今でも有力な選択肢だと思います。

私自身も、この「素早く業務アプリを形にできること」は FileMaker の非常に大きな価値だと考えてきました。実際、Claris のインタビュー記事「素早く開発することで、時間という価値を提供できる技術。」でも、その価値についてお話ししています。

1 番大きな理由は、素早く開発ができることです。例えば、iOS の機能を活用したシステムをつくる時、ネイティブアプリを 1 から開発しようとすると、かなり難易度が上がり、時間もかかります。

FileMaker は iOS の様々な機能を数行のスクリプトで利用でき、効率よく開発することができます。

ほしいと思ってから使えるようになるまでの制作期間中はシステムが使えないため、お客様にとっては機会損失につながってしまいます。時間というなかなか見えづらい価値も提供できることは、 FileMaker の最大の価値だと感じています。

素早く開発ができるもう一つの理由として、ヒアリングから納品までのプロセスを 1 人で担当できる、ということもあります。他言語の開発だと、フロントエンド、バックエンド、デザインのそれぞれに専門知識が求められ、チームを組むことが多いです。

お客様にとって、課題をいち早く解決できることは、何よりも嬉しいことだと思います。機会損失を回避し、「時間」を価値として提供できることが、FileMaker の良さであり、多くの選択肢の中から私が FileMaker を選ぶ理由でもあります。

だからこそ現在、AI エージェント前提の Web 開発の実装スピードが大きく向上し、この優位性に迫り、要件によっては上回る場面も出てきていることを、大きな変化だと感じています。FileMaker の価値がなくなったわけではありませんが、最大の強みだった「初速の速さ」は、以前ほど決定的な差ではなくなってきました。

長期運用で見えてくる課題

ここからは、初速の話だけではなく、「主軸として長く使う場合に何が効いてくるか」という観点で見ていきます。一度動き始めたあとに、改善、引き継ぎ、外部連携が増えると、見え方が変わってきます。

これは FileMaker の価値を否定する話ではありません。FileMaker は、人が使う業務画面を短期間でまとめて作ることにとても強いツールです。ただ、AI エージェントや外部サービスと連携しながら継続的に改善していきたい場合は、工夫が必要になる場面が増えてくるかもしれません。

ライセンスとベンダー依存の観点

長年 FileMaker を使ってきた立場だからこそ、ライセンスに関する構造的な課題についても率直に触れておきたいと思います。これは FileMaker に限った話ではなく、特定ベンダーの統合型プラットフォームに依存する場合に共通して起こりうる問題です。

AI ベンダーにも価格改定やサービス変更のリスクはありますが、AI は標準的なテキストベースのコードを扱うため、相対的にサービスの切り替え余地を残しやすい構造です。一方、統合型のローコードプラットフォームはデータや画面が密結合しているぶん、移行コストが高く、実務上の選択肢が狭くなりやすい面があります。

AI エージェント連携の補足

ここは少し技術寄りの話になりますが、AI エージェントが外部からデータを読み書きする前提で考えると、もう少し意識しておきたい点があります。

FileMaker が引き続き向いている場面

次のようなケースでは、FileMaker を軸にする判断は依然として合理的です。

つまり、判断すべきなのは「全面移行か、全面維持か」ではなく、どこを残し、どこから見直していくかだと思います。

5. AI エージェント前提の Web 開発の強みと考慮事項

AI エージェント前提の Web 開発の強み

次に、AI エージェント前提の Web 開発を見ていきます。ここでは、初速だけでなく、リリース後の改善や分業のしやすさも含めて考える必要があります。

この違いは、初回リリースよりも、2 回目、3 回目の改善のときに効いてきます。内製化は作って終わりではないので、継続的に改善しやすい構造であることは大きな利点だと思います。

導入前に知っておきたい点

一方で、こちらは「速く作れるから有利」とだけ見ると判断を誤りやすいです。AI エージェント前提の Web 開発にも、知っておいた方がよい点があります。

この記事で伝えたいのは、FileMaker の課題だけを見て判断するのではなく、AI 側にもレビューできる人、設計できる人、責任を持つ人が必要だということです。どちらを選ぶにしても、この点は変わりません。

もし社内にレビューできる人がいない場合は、外部の専門家に定期的にレビューしてもらう体制を前提に進めた方が安心です。AI はとても強力ですが、品質保証の責任まで自動で引き受けてくれるわけではありません。

現時点の私の見立て

それでもなお、これから新たに内製化を始めるなら、主軸は AI エージェント前提の Web 開発に置く方が合っていると考えています。

理由は、単に「今速いから」ではありません。変更履歴を追える構造、第三者がレビューしやすい設計、外部サービスや API との接続のしやすさ、人材の確保しやすさ、そして AI の進化の恩恵を受け続けやすいこと。これらは時間が経つほど効いてくる要素であり、ローコードプラットフォームでは構造的に実現しにくい部分です。

6. これから何が変わるのか

ここは少し先の話に見えるかもしれませんが、本題から外れた一般論ではありません。なぜ中長期では AI エージェント前提の Web 開発に分があると考えているのか、その背景にある変化を整理したいと思います。

今後は、非エンジニアの方でも AI を日常的に使いながら業務を進めることが当たり前になっていくのではないかと思います。すると、システムに求められる価値も少しずつ変わってきます。

すでに、こうした動きは始まっています。

たとえば、Goodpatch の土屋尚史氏が公開した note「全社へのClaude Code大号令 — 1ヶ月で200個のアプリと300件のナレッジから見えたこと」では、事業部メンバーのほぼ全員が Claude Code を使ってアプリを作り、多くがデプロイまで到達したことが紹介されています。営業、デザイナー、人事などの非エンジニアも含めて、組織全体で「自分で作って出す」体験が広がっていた点は、とても示唆的です。

ほぼ半数が、「作れるかどうか」ではなく「何を作るか」が勝負だと気づいたのです。

私はこの点がとても重要だと感じています。AI によって実装のハードルが下がるほど、差がつくのは実装速度そのものではなく、課題設定、言語化、設計、レビュー、運用の質です。この変化は、単に「非エンジニアでも作れるようになった」という話よりも、内製化の本質に近い変化だと思います。

ここで重要なのは、特定のツール名そのものよりも、AI エージェントを前提にした開発体験が、すでに一部の企業では組織的な実践フェーズに入り始めていることだと思います。

さらに、要件整理やアーキテクチャ設計のような上流工程まで AI が支援し始めています。たとえば、Claude Code の Feature Dev プラグインでは、作りたいものを伝えるだけで、AI エージェントが要望や要件を整理し、非機能要件の考慮までサポートしてくれます。

これからは、単に画面を作ることだけではなく、次のような点が重要になってくると考えています。

加えて、AI エージェントの適用範囲も広がりつつあります。現時点ではプロトタイプや社内ツールが中心ですが、実際の業務では小さなアプリでカバーできるケースが多く、大規模なシステムが必要な場面はそれほど多くありません。今後は社内ツールから顧客向けサービスへと、AI エージェント前提の開発が使われる領域は広がっていくと考えています。

また、今後はサービスやシステムの利用者が、人間だけでなく AI エージェントにも広がっていくはずです。そうなると、「誰に向けてサービスを設計するか」という視点も変わってきます。画面だけで完結するシステムではなく、API を中心に機能を分け、データ構造を明確にし、AI エージェントからも扱いやすい構成を意識することが、これからの設計では重要になってくると考えています。

Microsoft Research の職業研究でも、AI の適用が進むほど、人間側の価値は「判断」「設計」「責任」に寄っていくことが示唆されています。内製化でも同じことが言えると思っていて、差がつくのは「AI を使っているかどうか」よりも、AI を使った上で何を判断できるかではないかと考えています。

7. 担当者が交代した場合の備え

経営者の方が特に気にされるのが、担当者が辞めてしまった場合のリスクです。ここは、初速よりも重要な判断軸になることが多いと感じています。

FileMaker の場合

担当者が辞めた場合、次のようなことが起きやすくなります。

そのため、引き継ぎが急に発生すると、まず「何が止まると業務に影響するのか」を棚卸しするところから始めることになり、復旧より前に前提の整理に時間がかかることがあります。

結果として、「動いているから触らないでおこう」という状態になりやすく、改善が止まってしまうことがあります。

AI エージェント前提の Web 開発の場合

こちらも属人化は起こり得ますが、対策の選択肢が比較的多いのが違いです。

たとえば、主要画面、権限、外部連携、障害時の運用手順が残っていれば、AI の補助を受けながら第三者が部分的にキャッチアップしやすくなります。

もちろん、雑に作ってしまえばこちらも同じです。ただ、退職リスクに備える仕組みを作りやすいのは、現状では Web アプリ側だと考えています。

どちらを選んでも必要な対策

どちらの方式でも、次の対策は共通して必要です。

8. まとめ

これまで見てきた内容を踏まえると、これから新たに内製化を進めるなら、私はAI エージェント前提の Web 開発を主軸に置く方が、中長期では合っていると考えています。

そう考える理由は次の 5 つです。

ただし、この結論が向くのは、業務を言語化できる人がいて、基本的な仕組みを学ぶ意欲があり、運用まで責任を持てる会社です。逆に、既存資産の停止コストが高い場合や、まず小さく仕組み化したい段階では、FileMaker を残す判断の方が現実的なこともあると思います。

一方で、現在 FileMaker でうまく回っている企業が、すぐに全面移行する必要はありません。まずは新規の小さな案件や、差別化につながる部分から AI エージェント前提の開発を試してみて、残す部分と置き換える部分を見極めていくのが現実的だと考えています。

結局のところ、重要なのは「AI を使えるかどうか」ではなく、AI を使った上で何を判断し、どう設計し、どう運用するかだと思います。

内製化の進め方を整理したい場合

自社の状況に照らして「どこを残し、どこを見直すべきか」を整理したい場合は、第三者の視点を入れるのも有効だと思います。本記事で触れたような、AI エージェントを活用した業務システムの内製化について、技術的な支援を行っています。実装だけでなく、業務の整理、要件化、レビュー体制づくり、FileMaker からの段階的な見直しまで対応可能です。

「何から始めるべきか整理したい」「自社に合う進め方を判断したい」という方は、お気軽に無料相談からご連絡いただければと思います。