「その仕組み、FileMakerで作りますか？ それともスクラッチで書きますか？」
私はSIerでFileMakerとWeb系開発（Laravel/Rails）の両方を10年以上担当してきて、この質問に何度も答えてきました。外注見積200万円の案件管理アプリをkintoneで2週間・月5万円に置き換えたこともあれば、逆に「ローコードで始めたのが失敗だった」と設計をやり直したこともあります。
そして最近、この判断基準は一度壊れました。Claude Codeの登場で「スクラッチは遅い」という前提が崩れたからです。この記事では、私が実案件で使っているローコード（FileMaker/kintone） vs コード（Claude Code併用）の判断フローを、成功例・失敗例つきのチートシートとしてまとめます。
前提条件
- 私の環境: FileMaker Pro / FileMaker Server、kintone、Claude Code（MAXプラン）、Laravel / Rails、MySQL
- 想定する対象: 中小企業の業務システム（ユーザー数〜50名、レコード数〜数十万件）
- 対象外: 大規模基幹システム、不特定多数向けのtoCサービス（これらは最初からコード一択です）
結論: 判断フロー（チートシート）
先に結論のフロー図を置きます。迷ったらここに戻ってください。
このフローの背骨は機能比較ではなく、2つの問いです。
- 誰が使うか — 社内だけか、社外に公開するか
- 誰が育てるか — 業務担当者が自分で直すのか、エンジニアが保守するのか
ツールの機能一覧を並べて悩むより、この2軸で考えたほうが判断がブレません。これが10年やってきた私の結論です。
早見表: FileMaker / kintone / コード＋Claude Code
| 観点 | FileMaker | kintone | コード＋Claude Code |
|---|---|---|---|
| 得意領域 | 帳票・現場入力・オフライン | 部門横断の情報共有・ワークフロー | 外部公開・複雑ロジック・大量データ |
| 初期リリース速度 | ◎ 数週間 | ◎ 1〜2週間 | ○ Claude Codeで大幅短縮（後述） |
| 小修正の速度 | ◎ 当日〜数日 | ◎ 当日 | ○ CI/CDが整っていれば当日 |
| UI自由度 | ◎ ピクセル単位 | △ 標準UIに縛られる | ◎ 完全自由 |
| 日本式帳票（見積書等） | ◎ レイアウト機能が強い | △ プラグイン頼み | ○ 実装は自由だが工数増 |
| 外部連携 | ○ Data API / ODBC(ESS) | ◎ REST APIが素直 | ◎ 制約なし |
| スケール限界 | 数十万レコードで設計力が問われる | レコード数・API回数に制限 | 設計次第 |
| バージョン管理・テスト | △ 実質不可 | △ 実質不可 | ◎ Git・自動テスト |
| 育てる人 | 業務担当者〜内製チーム | 業務担当者 | エンジニア |
ローコードが勝った場面
Excelの限界が来た顧客管理をFileMakerで3週間
ある中小企業の案件で、Excel管理の顧客データが3,000件を超えて破綻しかけていました。市販CRMは高額なうえ業界特有の項目に合わない。私はFileMakerで検索・一覧・帳票出力・商談履歴つきのカスタム顧客管理を3週間で構築しました。月次レポートの作成時間は半日→10分（担当者の作業日報の実績値から集計）。「Excelに戻れない」という反応で、まさに「市販品では合わないが、フルスクラッチは高すぎる」というFileMakerの得意ゾーンでした。
外注見積200万円の案件管理をkintoneで2週間
別の現場では、営業部門の案件管理アプリを外注すると200万円という見積もりでした。私はkintoneで案件・商談履歴・タスク・日報の4アプリを連携させ、2週間でリリース。プロセス管理でステータス遷移を可視化した結果、案件の把握漏れが月5件→ゼロになりました。kintoneは「完璧を目指さず、とりあえず動くものを出して使いながら直す」進め方と相性が抜群です。
ローコード最大の武器は「変更のスピード」
決定打になった経験がもう1つあります。ITベンダーに外注していた現場では、小さな画面修正でも見積→発注→開発→テストで2ヶ月かかっていました。FileMakerを導入し、業務に詳しいメンバー2名に3日間の研修をして内製体制に切り替えたところ、小規模改修が2ヶ月→当日対応に（リードタイムは依頼日とリリース日の差分で記録）。外注開発費も年間300万円→50万円になりました。業務を知っている人が直接システムを触れるので、要件定義の伝言ゲームが消えるんです。
失敗談: ローコードでも設計からは逃げられない
良い話ばかりではありません。私がFileMakerで顧客・案件・作業・請求の4テーブル構成を組んだとき、リレーション設計を甘く見た結果、データ不整合が頻発しました。「ローコードだから雑に作っても何とかなる」は幻想です。
結局ER図を描き直し、主キー・外部キーを正規化ルールに沿って修正し、テーブルオカレンスをTOG（Table Occurrence Group）方式で整理してようやく不整合ゼロになりました。リレーショナルDB設計の基本はローコードでもコードでも同じ——これはツール選定以前の話で、どちらを選んでもサボった分だけ後で払うことになります。
境界を越える: ローコード×コードのハイブリッド
実務では「どちらか一方」で終わらないケースが多いです。私の現場で効いたのは、FileMakerの顧客データとMySQLの売上データの突合でした。以前は毎月末にCSVエクスポート→Excelで結合に4時間かけていましたが、FileMakerのESS（外部SQLソース）でMySQLに直接接続してリレーションを張ったところ、この作業自体が不要になりました。
FileMaker側では、集計にExecuteSQLを使うとリレーションを増やさずに済みます。
/* 今月の受注金額を集計（FileMakerの計算式） */
ExecuteSQL (
"SELECT SUM ( amount ) FROM projects
WHERE order_date >= ? AND order_date < ?" ;
"" ; "" ;
Date ( Month ( Get ( CurrentDate ) ) ; 1 ; Year ( Get ( CurrentDate ) ) ) ;
Date ( Month ( Get ( CurrentDate ) ) + 1 ; 1 ; Year ( Get ( CurrentDate ) ) )
)
kintoneはREST APIが素直なので、コード側から叩くハードルが低いのも強みです。
# kintone REST API: アプリID 123 の進行中レコードを取得
curl -s -X GET "https://your-subdomain.cybozu.com/k/v1/records.json" \
-H "X-Cybozu-API-Token: YOUR_API_TOKEN" \
-G --data-urlencode 'app=123' \
--data-urlencode 'query=status in ("進行中") order by 更新日時 desc limit 100'
このAPI連携部分のコードこそ、Claude Codeに書かせるのが一番おいしい領域です。私はローコードの「入力・画面」とコードの「連携・集計」を分担させる構成に落ち着きました。
Claude Codeが動かした境界線
かつての私の判断基準は「エンジニアが常駐できないならローコード一択」でした。スクラッチは初期構築も保守も遅かったからです。しかしClaude Codeを使い始めてから、コード側の初期構築スピードがローコードに肉薄するようになり、境界線が動きました。
それでもローコードの牙城が崩れない領域はあります。私の目安はこうです。
- ローコードが残る: 業務担当者が自分で直す前提の社内システム。特に日本式帳票（FileMaker）と部門横断ワークフロー（kintone）
- コードに寄せる: 外部公開、Git管理・自動テストが必要、レコード10万件超、外部連携3系統以上、アルゴリズムが複雑
逆に言うと、「エンジニアしか触らないのにローコードで作る」のは、Claude Code時代にはむしろ不利になりつつあります。バージョン管理もテストもできない資産が残るだけだからです。
迷ったときの判断手順（5ステップ）
- 既製SaaSで要件の8割を満たせるか調べる（作らないのが最速）
- 「誰が使うか」を確定する（社外公開が1ミリでもあればコード側に倒す）
- 「5年後に誰が育てるか」を名指しで決める（担当者名が出ないなら作らない）
- データ量と連携先を数える（10万レコード・連携3系統が私の閾値）
- それでも迷うならローコードで捨てる前提のプロトタイプ→検証後に本実装
まとめ
- 判断軸は機能比較ではなく「誰が使うか × 誰が育てるか」の2軸
- ローコードの本当の武器は初期速度より変更のスピード（2ヶ月→当日）
- ただし設計の基本（正規化・リレーション）はローコードでも省略できない
- 実務の最適解はハイブリッド: ローコードの画面×コードの連携をAPI/ESSで繋ぐ
- Claude Codeはコード側の速度を引き上げ、「エンジニアしか触らないローコード」の存在意義を薄めた
結局のところ、今回いちばん伝えたいのは「ツールの優劣ではなく、システムを育てる人の顔が浮かぶかどうかで選ぶ」という一点です。私自身、FileMakerもkintoneもClaude Codeも手放す気はなくて、案件ごとにこのフローを回しています。境界線はこれからも動くはずなので、この記事も定期的に自分で書き直すつもりです。
正直、ここに辿り着くまでにリレーション設計を甘く見て作り直したり、「ローコードで十分」と言い切って後からAPI連携の壁にぶつかったり、何度か遠回りしました。同じところでハマる人が減れば、この記事を書いた意味があります。みなさんの現場では、ローコードとコードの境界線をどこに引いていますか？ 「うちはこう分けている」があれば、ぜひコメントで教えてください。