FileMakerエンジニア
昨今、ソフトウェア開発にAIを活用するケースがかなり増えてきました。
これまで、アプリケーションを開発する方法として、主に「プロコード」「ローコード」「ノーコード」という3つのアプローチがありました。
ノーコードやローコードには、プロコードと比較して開発期間を短縮できることや、プログラミングの専門知識が少ない非エンジニアでも開発に参加できるというメリットがありました。
しかし、生成AIの登場によって、プログラミングの知識がない人でも、自然言語で指示するだけでアプリケーションを開発できるようになってきました。
これまでノーコードやローコードが担ってきた「非エンジニアでも開発できる」という価値は、AIによってどのように変化しているのでしょうか。
本記事では、プロコード・ローコード・ノーコードそれぞれの特徴を整理し、AIの普及によってアプリケーション開発がどのように変わりつつあるのかを解説します。
そして、この時代だからこそ Claris FileMaker （クラリスファイルメーカー）というプラットフォームを選ぶ理由についてもお伝えします。
目次
３つの開発アプローチ
プロコードとは？
プロコードとは、プログラミング言語を使って、開発者がソースコードを直接記述する開発手法です。
Java、Python、JavaScript、C#などのプログラミング言語を使用し、アプリケーションの機能やデータ処理、画面表示、システム連携などを実装します。
プロコードの最大の特徴は、開発者がシステムの構造や処理を細かく制御できることです。
既存のフレームワークやライブラリを活用しながら、独自の要件に合わせて柔軟に開発できるため、複雑な業務システムや大規模なアプリケーションの開発にも適しています。
一方で、プログラミングやシステム設計に関する専門知識が必要となり、開発者のスキルによって開発効率や品質が左右されることがあります。
また、開発だけでなく、テストや保守、セキュリティ対策などにも相応の工数が必要です。
ローコードとは？
ローコードとは、GUI による操作やあらかじめ用意されたコンポーネント、テンプレートなどを活用し、必要最小限のコーディングでアプリケーションを開発する手法です。
画面の部品や処理の流れを視覚的に組み立てながら開発できるため、すべての処理をコードで記述する必要がありません。
一方で、標準機能だけでは実現できない処理や、独自の要件に対応するために、一部コードを記述するようなこともできます。
つまり、ローコードは視覚的な開発によって効率化しながら、必要に応じてコードによる柔軟な拡張も行える開発手法です。
業務アプリケーションや社内システム、データ管理ツールなど、ある程度決まった構造を持つアプリケーションの開発で活用されています。
プロコードと比較して開発を効率化しやすく、ノーコードと比較すると、より複雑な要件にも対応しやすい点が特徴です。
ただし、プラットフォームの仕様や制約を理解する必要があり、独自の処理を追加する際にはプログラミングの知識が求められる場合があります。
ノーコードとは？
ノーコードとは、プログラミングコードを直接記述せず、GUIによる操作やドラッグ＆ドロップ、テンプレートなどを活用してアプリケーションを開発する手法です。
開発者は、画面上に必要な部品を配置したり、データや処理のルールを設定したりすることで、アプリケーションを構築します。
そのため、プログラミングの専門知識がない人でも、比較的簡単にアプリケーションを開発できる点が大きな特徴です。
例えば、社内の申請フォームやタスク管理ツール、簡単なデータベースアプリケーションなどは、ノーコードツールを活用することで、短期間で開発できる場合があります。
従来であればエンジニアに依頼していた業務改善ツールを、現場の担当者自身が作成できるようになることも、ノーコードの大きな価値です。
一方で、実現できる機能は利用するツールに依存します。
独自性の高い機能や複雑な処理、大規模なシステムの構築には、制約が生じる場合があります。
AIが普及したことで変わったこと
ここまで、プロコード・ローコード・ノーコードそれぞれの特徴を整理してきました。
従来、これらの開発手法には、ある程度明確な使い分けがありました。
- プロコード：柔軟性や自由度を重視する開発
- ローコード：開発効率と拡張性を両立する開発
- ノーコード：専門知識がなくても実現できる開発
それぞれ、このような開発に適しているという考え方です。
しかし、生成AIの普及によって、この使い分けにも変化が生まれています。
1. 非エンジニアでもコードを書いて開発できるようになった
従来、プログラミングの知識がない人がアプリケーションを開発するには、ノーコードやローコードのようなツールを利用することが有力な選択肢でした。
しかし、現在では AI に自然言語で指示することで、プログラムのコードを生成してもらえるようになっています。
例えば、「顧客情報を登録・検索できるWebアプリケーションを作成して」と指示すれば、AI が画面やデータ処理、必要なコードなどを生成し、アプリケーションの構築を支援してくれます。
もちろん、生成されたコードを実行するための環境設定や、動作確認、エラーの修正などが必要になる場合もあります。
それでも、非エンジニアが開発に参加するために、必ずしもノーコードやローコードを使う必要はなくなってきています。
2. 簡単なアプリケーションはAIだけでも開発しやすくなった
AI の普及によって、特に大きく変化しているのが、簡単なアプリケーションの開発です。
例えば、次のようなものです。
- タスク管理アプリケーション
- 顧客情報や商品情報を管理するツール
- データを登録・検索・編集するWebアプリケーション
- CSV ファイルを読み込んで集計するツール
- 社内業務を効率化するための簡易ツール
これまでは、こうしたアプリケーションを素早く作成するには、ノーコードツールが有力な選択肢でした。
しかし、AI を活用すれば、実現したい機能を文章で説明し、生成されたアプリケーションを確認しながら改善していくことができます。
「検索機能を追加して」「デザインを変更して」「このデータも表示して」といった指示によって、段階的に機能を追加していくことも可能です。
そのため、簡単なアプリケーションを素早く作るという目的では、AI を活用した開発が有力な選択肢になっています。
ノーコード・ローコードのメリットはなくなったのか？
ここまでを見ると、AI の普及によってノーコードやローコードのメリットはなくなりつつあるようにも思えます。
確かに、「プログラミングの知識がなくても開発できること」や「開発期間を短縮できること」だけに注目すると、AIによってその優位性は小さくなっています。
しかし、ノーコードやローコードの価値が完全になくなったわけではありません。
例えば、ノーコードやローコードのプラットフォームには、認証、権限管理、データ管理、外部サービスとの連携、公開環境などが標準機能として用意されている場合があります。
また、組織で利用する場合には、管理者による統制や監査、運用ルールへの対応も重要です。
AIでコードを生成できたとしても、それらの機能を適切に構築し、安全に運用できる状態にすることは別の問題です。
そのため、開発するアプリケーションの用途や利用環境によっては、ノーコードやローコードを利用する方が効率的な場合もあります。
重要なのは、単純に「AI があればノーコード・ローコードは不要」と考えるのではなく、AIによるコード生成と、ノーコード・ローコードが提供する開発基盤や管理機能を比較し、目的に合った手法を選択することです。
AI によってコードを作るハードルが下がったからこそ、生成された成果物が本当に要件を満たしているのかを判断する能力が重要になっています。
単にアプリケーションを「作れる」ことと、実際の業務で「安心して使い続けられる」ことは別だからです。
AI での開発の危険性
保守性
AI で開発したシステムは、保守が非常に難しくなることがあります。
その理由として、開発ルールが定まっていないことや、実装方法が統一されていないことなどが挙げられます。
また、エンジニアであっても、AIが自身の技量を超える技術を使ってコードを生成した場合、その内容を十分に理解できないことがあります。
さらに、どの言語で開発されているかによっては、社内にその言語を読める人がおらず、修正のたびに外部へ依頼しなければならないこともあります。
例えば、AIに「Webアプリを作って」と頼むと、React や Next.js、Python の FastAPI など、AIが選んだ言語やフレームワークでコードが作られます。
選んだのが人ではなくAI なので、なぜその技術を使ったのかを説明できる人が社内にいない、という状態が起こりやすくなります。
また、こうしたフレームワークは多くの外部ライブラリに依存しており、JavaScript のプロジェクトでは、インストールされるパッケージが数百個になることも珍しくありません。
作った本人がいなくなったとき、あるいは AI に「直して」と頼んでも直らなかったとき、そのコードを引き継げる人がいるかどうかが、保守性の大きな分かれ目になります。
古いバージョンや非推奨
システムを開発するときに必ず直面するのがバージョンです。
プログラミング言語のバージョンや、フレームワーク、ライブラリ、さらにそれらを動かす OS やサーバーにも、それぞれバージョンとサポート期限があります。
例えば、次のようなものは、すでにサポートが終了しています。
- Python 2.7（2020年1月1日にサポート終了）
- PHP 7.4（2022年11月28日にサポート終了）
- Node.js 16（2023年9月11日にサポート終了）
- CentOS 7（2024年6月30日にサポート終了）
サポートが終了すると、新しい脆弱性が見つかっても修正版は提供されません。
そのため、プロコードで作ったシステムは、数年ごとに言語やライブラリのバージョンを上げ、動作確認をやり直す必要があります。
しかも、バージョンを上げると、これまで使えていた書き方や機能が「非推奨」や「廃止」になり、コードの書き換えが必要になることもあります。
AI で開発する場合は、さらに注意が必要です。
AI は学習した時点の情報をもとにコードを生成するため、すでに非推奨になった書き方や、サポートが終了した古いバージョンのライブラリを使ったコードを、そのまま提案することがあります。
動いているように見えても、実は古い部品で組み立てられている、ということが起こり得るのです。
脆弱性
脆弱性については、最近のニュースでも大きく取り上げられています。
IPA（情報処理推進機構）が毎年公表している「情報セキュリティ10大脅威」でも、組織向けの1位は「ランサム攻撃による被害」であり、その侵入口の多くはシステムの脆弱性や設定の不備です。
脆弱性には様々な要因があります。
大きく分けると、次の2つです。
自分たちが書いたコードに潜む脆弱性
データベースに直接不正な命令を実行されるなど、入力値検証や認証設計に不備がある状態です。
例：SQLインジェクション、クロスサイトスクリプティング（XSS）、認証やアクセス制御の不備
自分たちが使っている部品に潜む脆弱性
昨今のニュースで報道されましたPHPの言語そのものに脆弱性がありシステムの作りに関係ない脆弱性です。
例：言語本体、フレームワーク、ライブラリ、OS、Webサーバーの脆弱性
Webアプリケーションのセキュリティ指標として広く使われている「OWASP Top 10（2021年版）」でも、
1位「アクセス制御の不備」
3位が「インジェクション」
6位が「脆弱で古くなったコンポーネント」
と、この2つの関連する内容が入っています。
1つ目の「自分たちが書いたコード」については、プロコードでは開発者がすべての入力、すべての画面、すべての処理について、攻撃される可能性を考慮しながら開発しなければなりません。
1か所でも対策が漏れていれば、そこが侵入口になります。
しかし、すべてのパターンを網羅するのは、熟練のエンジニアでも簡単ではありません。
AIが生成したコードも例外ではなく、一見正しく動くコードの中に、入力値のチェック漏れや、認証の抜けが含まれていることがあります。
コードを読めない人がAIで開発した場合、その問題に気づくこと自体が困難です。
2つ目の「使っている部品」については、自分のコードに問題がなくても、使っている部品に脆弱性が見つかれば、システム全体が危険にさらされます。
代表的な例が、2021年12月に公表された Java のログ出力ライブラリ「Apache Log4j」の脆弱性（CVE-2021-44228、通称 Log4Shell）です。
深刻度を表す CVSS のスコアは最高値の10.0で、世界中の企業が、自社のシステムのどこで Log4j が使われているのかを調べ、急いで更新する対応に追われました。
公開される脆弱性（CVE）の件数は年々増えており、2024年には年間約4万件に達しています。
プロコードでは、こうした情報を常に追いかけ、自分たちのシステムに関係があるかを判断し、関係があれば修正・テスト・リリースまでを自分たちで行わなければなりません。
これは開発が終わった後も、システムを使い続ける限りずっと続く作業です。
AI の時代だからこそ Claris FileMaker を選ぶ理由
Claris FileMaker はローコードツールであり、非エンジニアでも開発できます。
最近では、AIを活用した開発も少しずつできるようになってきており、自然言語で Claris FileMaker
のファイルを開発することができるようになってきています。
そして、先ほど挙げた脆弱性については、 FileMaker では開発時に気にする必要がほとんどありません。
それは、脆弱性の原因となる「コードを書く部分」と「部品を管理する部分」の両方を、開発元であるClaris社が引き受けてくれるからです。
脆弱性につながるコードを、そもそも書かない
Claris FileMaker では、テーブル、フィールド、レイアウト、スクリプトをGUIで作成します。
データの検索や登録は、Claris FileMaker の機能として提供されているため、開発者がSQL文を組み立てたり、HTML を出力する処理を書いたりする必要がありません。
つまり、SQLインジェクションやXSSのような「書いたコードの不備」から生まれる脆弱性が、そもそも入り込みにくい構造になっています。
また、ログイン処理やパスワードの保存、通信の暗号化といった、プロコードで最も間違いが起きやすい部分も、すべて Claris FileMaker の標準機能です。
開発者が自分で実装する必要はなく、AI が生成したコードに認証の抜けがないかを心配する必要もありません。
言語やライブラリのバージョン管理をしなくてよい
プロコードでは、言語、フレームワーク、ライブラリのバージョンを自分たちで管理し、脆弱性が見つかれば修正しなければなりませんでした。
Claris FileMaker では、こうした内部の部品はすべてClaris社が管理しています。
脆弱性が見つかった場合は Claris が修正し、FileMaker Pro や FileMaker Server のアップデートとして提供されます。
開発者が Log4Shell のときのように「自社のシステムのどこに何が使われているか」を一から調べる必要はなく、提供されたアップデートを適用すれば対応が完了します。
さらに、FileMaker Cloud を利用すれば、サーバーの運用やアップデートも Claris 側で管理されるため、利用者の負担はさらに小さくなります。
また、Claris FileMaker のアップデートでは過去に作ったファイルとの互換性が重視されており、言語であれば場合によってはバージョンアップによりコードを書き直す、ということが珍しくありませんが Claris FileMaker では基本的にありません。
.fmp12 形式のファイルは FileMaker 12（2012年）から使われ続けており、10年以上前に作ったファイルを最新の Claris FileMaker で開いて使い続けている企業も少なくありません。
Claris FileMaker のファイル自体がセキュリティに優れている
Claris FileMaker の大きな特徴は、セキュリティの仕組みがファイルそのものに組み込まれていることです。
Claris FileMaker のファイル（.fmp12）には、データだけでなく、画面、スクリプト、そしてアカウントとアクセス権の設定までが1つにまとまっています。
そのため、ファイルをどこにコピーしても、どのサーバーに置いても、設定したセキュリティがそのまま有効です。
具体的には、ファイル単体で次のような保護ができます。
アカウントとアクセス権セット
ユーザーごとにログインを必須にし、「閲覧のみ」「データ入力のみ」など、操作できる範囲を設定できます。
また、新たな権限を作成することでテーブル、レコード、フィールド、レイアウト、スクリプト単位で、「見せる・見せない」「編集できる・できない」を細かく制御できます。
拡張アクセス権
FileMaker Pro、FileMaker Go、WebDirect、Data API など、どの経路からの接続を許可するかを、アクセス権セットごとに設定できます。
使わない接続経路はすべて閉じておくことができます。
保存時の暗号化（AES-256）
ファイルを暗号化すると、暗号化パスワードを知らない限り、ファイルを開くことはできません。
万が一ファイルそのものが盗まれたとしても、中のデータを読み取られることはありません。
ファイルアクセスの保護
許可していない別の Claris FileMaker ファイルから、自分のファイルのデータを参照されないように制限できます。
外部認証への対応
Microsoft Entra ID や Google アカウント、Claris ID などを使ったログインにも対応しており、社内のアカウント管理と連携できます。
プロコードで同じことを実現しようとすると、認証、権限管理、暗号化を一つひとつ設計・実装し、それぞれに脆弱性がないかを確認しなければなりません。
Claris FileMaker では、これらが Claris によって作られ、検証され、アップデートされ続けている機能として、最初からファイルの中に備わっています。
開発者がやるべきことは、シンプルに2つだけ
もちろん、Claris FileMaker を使えば何もしなくても安全、というわけではありません。
ただし、開発者がやるべきことは、プロコードと比べてずっとシンプルです。
アクセス権を正しく設定すること
完全アクセス権のアカウントには強力なパスワードを設定し、利用者には必要最小限の権限だけを与えます。
Claris が提供するアップデートを適用すること
FileMaker Server や FileMaker Pro のアップデートを適用し、サーバーには正式な SSL 証明書を設定します。
FileMaker ServerをはじめとするClaris製品自体の脆弱性を検知・修正・検証する作業は、すべてClaris社が担ってくれます。
開発者は、業務の課題を解決するアプリケーションづくりに集中できるのです。
AIによって誰でもアプリケーションを「作れる」時代だからこそ、作ったものを「安心して使い続けられる」Claris FileMaker を選ぶ価値は、これまで以上に大きくなっていると考えています。
まとめ
AI の普及によって、アプリケーション開発のあり方は大きく変わりつつあります。
従来は、プログラミングの専門知識が必要なプロコード、開発効率と柔軟性を両立するローコード、専門知識がなくても開発できるノーコードというように、それぞれの手法に特徴がありました。
しかし、現在では AI がコードの生成や修正を支援してくれるため、非エンジニアであっても、簡単なアプリケーションであれば比較的容易に開発できるようになっています。
その結果、ノーコードやローコードの価値は、単に「コードを書かずに開発できること」から、標準機能による開発効率化、運用基盤、管理機能、組織的な統制などへと広がっています。
一方で、AI やプロコードで作ったシステムは、保守、バージョン管理、脆弱性対策を、使い続ける限り自分たちで担わなければなりません。
Claris FileMaker であれば、脆弱性への対応は Claris が引き受け、アクセス権や暗号化といったセキュリティの仕組みはファイルそのものに備わっています。
開発者は「アクセス権を正しく設定する」「アップデートを適用する」という2点を押さえるだけで、安全なシステムを使い続けることができます。
これからは、特定の開発手法にこだわるのではなく、AI、プロコード、ローコード、ノーコードを目的に応じて使い分けることが重要になるでしょう。
そして、開発のハードルが下がる時代だからこそ、何を作るべきかを考え、生成されたものを正しく評価し、安全に運用できる能力が、これまで以上に求められるのではないでしょうか。
また、株式会社ブリエでは、FileMakerを活用したシステム開発や運用支援を行っています。
業務システムのセキュリティについてのご相談もお気軽にお問い合わせください。
多岐にわたる業種での経験を経て、現在はFileMakerを中心に活躍中のエンジニアです。ローコード開発を得意としながらも、Django、React、Flutterなどの技術にも挑戦し、幅広い開発スキルを習得。常に自分の技術を磨き、より良いソリューションを提供できるよう、継続的にスキルアップを図っています。多彩な技術を駆使して、クライアントのニーズに応える柔軟性と、迅速かつ効果的な開発力が強みです。
