ローコードでAccessは置き換えられる？再現できない機能の限界

結論：ローコードで「ほぼ再現できる」業務と「かなり難しい」業務がある

kintoneやPower AppsなどのローコードツールはAccessの多くの業務を置き換えられますが、すべてではありません。当社がよく見る「再現しにくい」機能として、ミリ単位の印刷レイアウト（帳票）、入り組んだVBAのイベント処理、大量データの集計性能の3つが挙がります。逆にローコードが明確に得意なのは、多人数同時利用、モバイルからのアクセス、素早い立ち上げです。

「ローコードならAccessより安く早く作れる」は状況次第で正しいですが、「Accessの機能をそのまま再現できる」は別の話です。以下では再現が難しい機能を整理し、ローコードが向く領域との対比を示します。特定ツールの個別仕様は変わることがあるため、断定的な評価は避け、一般的な傾向と当社の経験を基に記述しています。

再現が難しい機能の比較表

まず全体像を一覧で確認します。「難しい」はゼロではなく、追加開発や外部ツールを組み合わせれば解決できるケースもあります。その分のコストと工数が増える、という意味での「難しい」です。

帳票・印刷レイアウトの再現が難しい理由

Accessのレポートは、グループヘッダー・明細行・グループフッター・ページフッターをmm単位で配置し、条件付き書式や計算フィールドを組み込んで印刷できます。請求書の合計欄がページをまたぐときの改ページ制御なども設定できます。

ローコードツールの多くは、Webブラウザの画面をそのまま印刷するか、スクリーンショット的な出力を基本設計にしています。kintoneの公式ヘルプには「印刷用画面のレイアウトを変更することはできません」と明記されており、請求書や納品書のような会社固有の帳票形式に対応するには、帳票プラグインや連携サービス、あるいは個別開発が必要になる場合があります。Power Appsも2021年以降に印刷機能が追加されていますが、Access風のレポートデザイナーはなく、ミリ単位のレイアウト制御は標準機能の範囲外です。

帳票の本数が多いほど移行コストに直結します。当社の経験では、複雑な帳票を複数持つAccessの移行でローコードを選ぶ場合、帳票の再現だけで別途費用が発生するケースが少なくありません。

VBAのイベント処理はなぜ移植しにくいか

Accessはフォームを開いたとき（Open）、レコードを移動するとき（Current）、値を変更する前後（BeforeUpdate / AfterUpdate）など、数十のイベントにVBAコードを仕込めます。「金額フィールドを変えたら自動的に税額を計算して別フィールドに入れ、入力チェックを走らせて、状況に応じてボタンの活性・非活性を切り替える」——こういった連鎖がVBAで実現されています。

Power AppsやkintoneにはAccessのVBAをそのまま実行する機能はありません。Power Appsは宣言型のPower Fx（数式言語）で動き、ループや逐次処理の書き方がVBAとは根本的に異なります。kintoneはJavaScriptで拡張できますが、AccessのBeforeUpdate相当のイベントフックをすべてカバーするわけではありません。移植というよりも再設計が必要で、VBAの規模が大きいほど工数が膨らみます。

VBAをPower FxやkintoneのJavaScriptへそのまま完全に自動変換できる公式移行ツールは確認できません（SSMAはテーブル・インデックス・多くのSELECTクエリなどは移行できますが、フォーム・レポート・VBAは変換対象外です）。既存のロジックがどれだけ複雑かを先に把握しておくことが、移行の見積もり精度を上げるうえで重要です。ブラックボックス化したAccessの解析手順の記事も参考にしてください。

大量データの集計と件数制限

Accessは明示的な行数上限なくSQLクエリでデータを集計できます（データベース2GB・クエリのレコードセット1GBなどのサイズ上限はあります）。データ量やクエリ設計、端末性能によっては、比較的大量の集計をローカルで処理できる場合があります。

Power Appsでは、処理を「委任（delegation）」できない場合、Power Appsがローカルで処理できる行数に上限があります（既定500件で設定変更可、最大2,000件）。委任できない集計関数はデータ全件ではなく上限分のみを対象にするため、意図せず不正確な結果になることがあります。Microsoft Learnの公式ドキュメントでも委任の制約として明記されています。DataverseやSQL Serverで委任可能なクエリに設計し直すことで回避できる場合がありますが、設計の変更と追加コストが伴います。

kintoneも大量レコードの処理には特性があります。APIの1回の呼び出しで取得できる件数が限られており、クロスアプリの集計（複数のアプリをまたいだ合計など）は標準機能だけでは難しいケースがあります。

ローコードが得意な領域——適材適所のもう一面

ここまでを読むと「ローコードはダメ」と聞こえるかもしれませんが、それは違います。Accessが苦手なことをローコードはよく解決します。

多人数同時利用はその典型です。Accessは同時更新が増えると書き込み競合や待ち時間、変更の上書きが発生しやすく、現実的に快適に使える人数は5〜10人程度（当社経験）が目安です。ローコードツールはAccessの共有ファイル方式に固有のこうした問題を受けにくく、多人数利用に対応しやすい傾向があります。モバイル対応もAccessにはなく、現場でのスマートフォン入力や外出先からのデータ参照を求めるなら、ローコードが有力な選択肢になります。当社の経験では、要件が限定された部署単位のアプリが数週間で稼働し、ITチームへの依存を抑えられたケースもあります。

移行先の詳細な比較はAccessの移行先を比較（kintone・Power Apps・Webシステム・FileMaker）でも整理しています。移行先ごとに向くケースと費用感が異なります。

「ローコードで全部再現しよう」でなく「業務ごとに分けて考える」

同一のAccessシステムの中に、ローコードで十分な業務とそうでない業務が混在することは珍しくありません。在庫の入力と参照はkintoneで十分でも、その月次集計と帳票出力はWebシステムで作る——といった切り分けをするケースもあります。

当社の考え方は「移行先を先に決めない」です。まず現状のAccessが何を持っているか（テーブル・クエリ・フォーム・帳票・VBAの規模と複雑さ）を把握してから、機能ごとに最適な移行先を当てはめる順番で進めると、余計なコストが減ります。全面移行しない選択肢——ハイブリッド段階移行でこの考え方を詳しく解説しています。

自社のAccessがローコードに向いているかどうか判断したい場合は、無料の解析可否チェックで現状を把握するところから始めてみてください。帳票の本数・VBAの規模・利用人数・データ量を確認するだけで、移行先の選択肢がかなり絞れます。

よくある質問

Q. kintoneでAccessの帳票を再現するのは完全に無理ですか。

標準機能の範囲では難しいです。ただし、kintone向けの帳票プラグインを追加契約すれば対応できるケースもあります。プラグインの費用とAccessの帳票を作り直す工数を比較したうえで判断することをお勧めします。帳票の種類や複雑さによって向き不向きが変わります。

Q. VBAが多いほど移行費用が高くなりますか。

傾向としてはそうです。ローコードへ移行する場合、VBAロジックは変換ではなく再設計になります。行数が多くても単純な繰り返し処理なら工数は少なく、行数が少なくても複雑な条件分岐や外部連携を含む場合は多くなります。コード行数よりロジックの複雑さで変わります。

Q. Power Appsに移行すれば必ずMicrosoft 365と連携しやすくなりますか。

連携しやすくなる場面は多いですが、利用するライセンスや接続先のデータソースによって変わります。Power AppsはAccessからの移行時に確認すべきライセンス上の注意点もあるため、導入前の整理が欠かせません。「Microsoft 365を使っているから自動的にPower Appsが使える」は必ずしも成立しません。

Q. ローコードが向かない場合、Webシステムへの全面移行しか選択肢はありませんか。

そうではありません。バックエンドのデータだけSQL Serverへ移してフロントエンドはAccessのまま継続する構成（アップサイジング）や、業務を機能単位に分けて段階的に移行する方法もあります。「全面移行か現状維持か」の二択ではなく、ローコードで対応できる部分だけローコードに任せることも選択肢の一つです。詳しくはAccessをWebシステム化するの記事を参照してください。