kintone比較の見方｜Power Platform・Pleasanter・Airtableを業務で選ぶ

kintoneを比較するとき、多くの人は最初に料金表や機能一覧を見ます。

Power Platformと比べる。

Pleasanterと比べる。

Airtableと比べる。

API、権限、通知、フォーム、ダッシュボード、ワークフロー、料金、ユーザー数、レコード数を見る。

それ自体は必要です。

ただし、比較表だけで結論を出すと、実務ではよくずれます。

同じ「業務アプリを作れる」ツールでも、前提が違うからです。

kintoneは、現場の業務台帳を作り、一覧、コメント、通知、権限、プロセス管理を組み合わせて育てる使い方に向きます。

Power Platformは、Microsoft 365、Dataverse、SharePoint、Teams、Power Automateの運用と一緒に見る必要があります。

Pleasanterは、OSSやオンプレ、自社管理のサーバー、拡張開発、バックアップまで含めて検討します。

Airtableは、チーム単位の企画、制作、進行管理、軽い業務データの共有に使いやすい一方、全社の正本DBにするなら権限と管理ルールを別に考える必要があります。

つまり、比較で見るべきなのは「どの製品が高機能か」だけではありません。

その業務を誰が変えるのか。

誰が権限を直すのか。

どのデータを正しいものとして扱うのか。

Microsoft 365や社内サーバーとどう関係するのか。

外部支援をどこまで前提にするのか。

ここを決めてから比較表を見ると、判断はかなり変わります。

kintone比較は、製品名の勝ち負けではなく、「業務データの正本、作成者、運用者、連携先」を決める作業です。

この記事では、kintone、Power Platform、Pleasanter、Airtableを、料金・権限・連携・保守の読み方から整理します。

kintoneでできること・できないことの判断基準はこちら
kintoneのデメリットと対策はこちら
Power Platform・Airtable・Pleasanterなど候補別の使い分けはこちら
kintoneデータベースの設計方法はこちら
kintoneセキュリティ設計はこちら
kintone API連携の設計方法はこちら
kintone連携サービス選定の設計方法はこちら

先に結論：比較表は「自社の業務条件」で読む

比較表は便利です。

しかし、表の列を上から順に見ていくだけでは選べません。

業務条件が違うと、重要な列が変わるからです。

たとえば、10人の部門で問い合わせ管理を始める場合と、全社でMicrosoft 365を軸に申請や通知を統一する場合では、見るべき項目が違います。

社内サーバーで持つ必要がある業務と、外部パートナーも含めて軽く進行管理したい業務でも違います。

最初に見るべき条件は、次の4つです。

条件	決めること	比較表で見る列
誰が作るか	現場担当、業務責任者、情シス、外部支援のどれか	画面作成、変更のしやすさ、管理機能
誰が運用するか	項目追加、権限、通知、連携を誰が直すか	管理者権限、変更履歴、監査、保守手順
どのデータを扱うか	顧客、案件、申請、履歴、添付、マスタのどれか	データ量、権限粒度、検索、関連付け
何とつなぐか	Microsoft 365、会計、CRM、チャット、基幹、社内DB	API、コネクタ、Webhook、手動CSV、認証

この4つが決まると、比較表の読み方が変わります。

現場が自分たちで変え続けるなら、kintoneのアプリ作成、一覧、通知、権限、プロセス管理を見ます。

Microsoft 365の中で使うなら、Power Platformの環境、Dataverse、SharePoint、Teams、Power Automate、ライセンスを見ます。

自社サーバーやOSSが前提なら、Pleasanterのエディション、インフラ、更新、バックアップ、開発者の引き継ぎを見ます。

少人数チームの進行管理なら、Airtableのビュー、共有、編集権限、プラン制限を見ます。

比較表は「全部入りの製品」を探すためではなく、自社の業務条件に合わない列を早めに見つけるために使います。

比較表の前に業務条件を決める

ツールを比較する前に、業務を1枚の表にします。

ここで作る表は、製品比較表ではありません。

自社側の条件表です。

確認する条件	書く内容	判断に効くこと
業務名	問い合わせ管理、案件管理、申請、制作進行など	ツールではなく業務単位で考えられる
1件の単位	1問い合わせ、1案件、1申請、1タスクなど	レコード設計やテーブル設計が決まる
入力者	現場、営業、管理部、外部メンバーなど	画面の簡単さ、権限、外部共有を見る
判断者	承認者、確認者、管理者、情シスなど	プロセス管理や承認の重さを見る
正本データ	顧客、案件、申請、履歴、請求前確認など	どのツールで編集してよいか決まる
更新頻度	毎日、週次、月次、都度など	通知、一覧、連携頻度を見る
データ量	レコード数、添付容量、将来の増え方	上限、検索、バックアップを見る
外部連携	Microsoft 365、会計、CRM、チャット、基幹など	API、コネクタ、認証、エラー対応を見る
保守担当	現場管理者、情シス、外部パートナーなど	変更ルールと委託範囲が決まる

この表がないまま製品比較をすると、議論がぶれます。

「Power PlatformはMicrosoft 365と相性がよい」

「kintoneは現場が作りやすい」

「Pleasanterはオンプレで使える」

「Airtableはビューが使いやすい」

どれも一面では正しいです。

しかし、自社の業務条件に当てると、結論は変わります。

Microsoft 365を使っていても、情シスがPower Platform環境を管理できないなら、アプリが増えた後に止まります。

現場がkintoneを触れるとしても、正本データと権限を決めなければ、似たアプリが増えます。

Pleasanterをオンプレで持てても、バックアップや更新を引き受ける人がいなければ危険です。

Airtableで早く始めても、正式な業務DBにするなら、誰が項目や権限を管理するかを決める必要があります。

比較表の前に、自社側の表を作る。

これが最初の作業です。

現場ユーザーが作るなら何を見るか

現場ユーザーが業務アプリを作る場合、比較表では「作れるか」だけでなく「直し続けられるか」を見ます。

現場が作るアプリは、最初から完璧にはなりません。

入力項目が足りない。

一覧の条件が変わる。

通知先を変えたい。

承認前に別の確認を入れたい。

担当者の見方と管理者の見方を分けたい。

こうした変更が起きます。

そのため、次の列を見ます。

見る列	読み方
フォーム作成	現場が項目を追加しても壊れにくいか
一覧・ビュー	担当者別、期限別、状態別に見方を分けられるか
コメント・履歴	判断理由や確認経緯をレコードに残せるか
通知	次に動く人へ絞って知らせられるか
プロセス管理	申請、確認、差し戻し、完了を表せるか
アクセス権	アプリ、レコード、項目のどこで分けるか
変更管理	誰が設定変更し、誰が承認するか

kintoneは、この領域で検討しやすいツールです。

業務台帳をアプリ化し、一覧、コメント、通知、権限、プロセス管理を組み合わせやすいからです。

ただし、現場が作りやすいことと、現場だけで管理してよいことは別です。

顧客マスタ、案件マスタ、請求前確認、個人情報、外部連携を持つなら、業務責任者や管理者の関与が必要です。

Power Platformでも、現場ユーザーがアプリを作ることはできます。

ただし、Microsoft 365の環境、Dataverseを使うか、SharePointリストで足りるか、Power Automateのフローを誰が保守するかを見ます。

Airtableも、チーム内で素早く表やビューを作りやすいです。

ただし、正式な業務台帳にするなら、Base、Table、View、Interface、権限、課金対象ユーザーの扱いを見ます。

Pleasanterは、現場だけで完結させるより、情シスや開発者が保守に関わる前提で見た方が現実的です。

情シスが管理するなら何を見るか

情シスが管理する場合は、作成画面よりも運用統制を見ます。

特に重要なのは、次の項目です。

見る列	読み方
環境管理	本番、検証、部署別環境を分けられるか
ユーザー管理	退職、異動、外部メンバーを扱えるか
権限管理	組織、グループ、ロール、項目単位を説明できるか
監査・履歴	誰がいつ何を変えたか追えるか
バックアップ	事故時にどこまで戻せるか
連携管理	認証、接続先、API、失敗時の再実行を管理できるか
保守範囲	情シスが見る範囲と現場に任せる範囲を分けられるか

Power Platformは、Microsoft 365を社内基盤として使っている会社で検討しやすくなります。

Microsoft Learnでは、Power Appsはアプリ、サービス、コネクタ、データプラットフォームを含むスイートとして説明され、Dataverse、SharePoint、Microsoft 365、Dynamics 365、SQL Serverなどのデータにつなげられるとされています。

Microsoft Learn：What is Power Apps?

この特徴は、Teams、SharePoint、Power Automate、Microsoft Entra IDなどの運用と合わせて見たときに意味があります。

一方で、Microsoft 365を使っているだけでPower Platformが自動的に合うわけではありません。

環境を誰が作るか。

Dataverseを使うか。

SharePointリストで足りるか。

フローの所有者が退職したらどうするか。

ライセンスがどのユーザーに必要か。

ここまで説明できる必要があります。

kintoneを情シスが管理する場合も、似た論点があります。

アプリを誰が作ってよいか。

アプリ名やフィールド名のルールをどうするか。

権限表をどこに残すか。

プラグインやJavaScriptを誰が更新するか。

連携サービスの契約やトークンを誰が持つか。

情シスが管理するなら、ツール比較は「便利そうか」ではなく、運用統制を説明できるかで読みます。

データ量で見る

データ量は、料金表の次に見落とされやすい比較軸です。

最初は数百件でも、1年後には数万件になる業務があります。

添付ファイルが増える業務もあります。

問い合わせ、作業履歴、点検記録、申込、日報、制作物、契約前確認は、日々増えます。

データ量を見るときは、現在の件数だけでは足りません。

見ること	読み方
1か月の増加件数	1年後、3年後に何件になるか
添付ファイル	画像、PDF、Excel、メール添付をどこに置くか
履歴の持ち方	1レコードに追記するか、履歴アプリや別テーブルに分けるか
検索の仕方	全文検索、条件検索、ビュー、関連レコードのどれで探すか
集計の仕方	標準グラフ、外部BI、スプレッドシート出力のどれを使うか
削除・保管	何年残すか、退避するか、バックアップするか

kintoneでは、アプリ分割と関連レコードの設計が効きます。

1つのアプリに顧客、案件、履歴、明細、添付を詰め込むと、画面も権限も重くなります。

顧客マスタ、案件、履歴、添付管理、請求前確認などに分ける方が説明しやすいことがあります。

kintone関連レコードの設計方法はこちら
kintoneテーブルの設計方法はこちら
kintone添付ファイルの設計方法はこちら

Power Platformでは、Dataverse、SharePoint、SQL Serverなど、どこにデータを置くかで設計が変わります。

Pleasanterでは、サーバー、DB、バックアップ、更新、容量監視まで自社側で見る範囲が増えます。

Airtableでは、プランごとのレコード数、添付、API、共同編集者の扱いを見ます。

データ量は、初期費用よりも後から効いてきます。

比較表でデータ量を見るときは、現在の件数ではなく「1年後に誰が探し、誰が保管し、誰が消せるか」まで読みます。

料金の読み方

料金は、月額だけで判断しない方がよいです。

見るべきなのは、課金単位と追加費用です。

公式情報は変わるため、実際の見積時には各社のページを確認します。

サイボウズ：kintone料金
Pleasanter公式：プリザンターの特長と利用スタイル
Airtable Support：Airtable plans overview

料金表は、次のように読みます。

見ること	読み方
ユーザー単価	利用者全員か、編集者だけか、外部メンバーも含むか
最小ユーザー数	小さく始めるときに最低契約が合うか
コース差	API、プラグイン、拡張、管理機能がどのコースから使えるか
外部利用	ゲスト、社外共有、フォーム、公開画面に別費用があるか
連携費用	コネクタ、連携サービス、API実行、追加ライセンスが必要か
インフラ費用	クラウド利用料、サーバー、DB、バックアップ、監視が必要か
保守費用	社内工数、外部支援、プラグイン更新、改修費が必要か

kintoneは、ユーザー単位のコース、ゲストユーザー、外部サービス連携やプラグインの可否を見ます。

Power Platformは、Microsoft 365に含まれる範囲と、追加のPower Appsライセンス、Dataverse、コネクタ、Power Automateの扱いを分けます。

Pleasanterは、Community Edition、Enterprise Edition、クラウド版、自社サーバー運用のどれかで費用構造が変わります。

Airtableは、編集権限を持つ共同編集者、プランごとのレコード数、添付容量、API、管理機能を見ます。

安く見えるツールでも、運用担当者が毎月手で直すなら高くなります。

高く見えるツールでも、既存のMicrosoft 365運用や情シス体制に乗るなら、全体では説明しやすいことがあります。

料金比較は、月額だけでなく、作成、移行、教育、連携、保守、棚卸しまで含めます。

権限の読み方

権限は、ツール比較で最も実務差が出ます。

同じ「権限設定あり」でも、何をどこまで制御できるかは違います。

次の観点で読みます。

権限の観点	見ること
アプリ単位	誰がアプリを見られるか、作れるか、管理できるか
レコード単位	自部署、自分担当、状態、金額条件で分けられるか
項目単位	個人情報、原価、添付、承認項目を分けられるか
外部共有	ゲスト、取引先、パートナーにどこまで見せるか
管理者権限	設定変更者とデータ閲覧者を分けられるか
履歴	誰がいつ見たか、変えたか、戻せるか

kintoneでは、アプリ、レコード、フィールドのアクセス権をどう組み合わせるかが重要です。

権限を細かくできることより、社内で説明できることを優先します。

Power Platformでは、Dataverseのセキュリティロール、環境、所有者、共有、Microsoft Entra IDとの関係を見ます。

Pleasanterでは、組織、グループ、ユーザー、サイト、テーブルの管理と、自社運用の責任を見ます。

Airtableでは、ワークスペース、ベース、インターフェース、テーブル、フィールドの編集権限を見ます。

権限設計で危ないのは、例外をすべて設定で吸収しようとすることです。

部署、役職、担当者、ステータス、金額、外部メンバーを全部1つのアプリやBaseで抱えると、誰が何を見られるかを説明しづらくなります。

その場合は、ツールを変える前に、業務を分けます。

受付用。

管理用。

履歴用。

外部共有用。

マスタ用。

権限は、製品の機能表だけでなく、アプリ分割やデータ分割とセットで読みます。

連携の読み方

連携は、「つながるか」ではなく「どちらが正本か」で読みます。

APIやコネクタがあるだけでは足りません。

次の表を先に作ります。

決めること	例
正本	顧客はkintone、商談はCRM、請求は会計、通知はTeamsなど
更新方向	kintoneから外へ送る、外からkintoneへ戻す、片方向参照にする
更新キー	顧客ID、案件ID、契約番号、外部システムIDなど
更新タイミング	即時、日次、承認後、月次締め後など
失敗時対応	再実行、保留、手動修正、通知、ログ確認など
変更禁止条件	承認後、請求済み、締め後、外部送信済みなど

kintoneは、外部サービス連携、API、Webhook、連携サービスを組み合わせやすいです。

ただし、連携後にどちらを直してよいかを決めないと、二重更新になります。

Power Platformは、Microsoft 365、Teams、SharePoint、Outlook、Dataverse、Power Automateとの近さが強みになります。

一方で、フローが増えると、所有者、接続、認証、エラー通知、再実行を管理する必要があります。

Pleasanterは、自社システムや社内DBと近い場所に置く判断ができます。

その分、サーバー、ネットワーク、認証、バックアップ、更新作業も自社側の論点になります。

Airtableは、チームの周辺SaaSとつなぎやすい一方、正式な正本DBとして使うなら、同期範囲と編集場所を限定した方が安全です。

連携比較で見るべきなのは、コネクタの数ではありません。正本、更新方向、更新キー、失敗時対応を説明できるかです。

保守の読み方

保守は、導入後に最も差が出ます。

比較表には「ノーコード」「ローコード」「アプリ作成」などの表現が並びます。

しかし、実務で大事なのは、作った後に誰が直すかです。

保守で見ること	確認すること
項目追加	現場が足してよいか、管理者承認が必要か
一覧変更	個人ビューと共有ビューを分けるか
権限変更	異動、退職、外部メンバー追加に対応できるか
通知変更	通知先や条件を誰が見直すか
連携変更	API、認証、接続先、項目マッピングを誰が直すか
プラグイン更新	バージョンアップや契約管理を誰が見るか
棚卸し	未使用アプリ、重複項目、古いビューをいつ消すか

kintoneは、現場が変えやすいからこそ、変更ルールが必要です。

Power Platformは、環境やフローの管理者が必要です。

Pleasanterは、サーバーとアプリの両方を見られる人が必要です。

Airtableは、チームが自由に作れる分、正式運用に入る前に命名、権限、共有、削除ルールを決める必要があります。

保守担当が決まっていないツールは、最初は動いても、半年後に詰まります。

項目が増える。

ビューが増える。

通知が増える。

連携が増える。

担当者が変わる。

この変化に誰が対応するかまで含めて、比較表を読みます。

Power Platform・Pleasanter・Airtableとの違いを業務条件で読む

ここまでの条件を使うと、各ツールの違いは次のように読めます。

業務条件	kintoneを見やすい場合	他ツールを見やすい場合
現場が業務台帳を育てたい	入力、一覧、通知、権限、状態管理を現場と業務責任者で見たい	Microsoft 365標準運用や自社サーバー要件が強い
Microsoft 365が中心	Teams通知やPower Automate連携は組めるが、kintoneを正本にする理由が必要	Power Platformで環境、認証、フローを管理しやすい
オンプレやOSSが必要	SaaS前提が合わない場合は慎重に見る	Pleasanterで自社管理、拡張、サーバー運用を検討する
少人数チームで早く始めたい	後で部門横断の業務DBにするなら候補になる	Airtableで表、ビュー、外部共有を軽く始めやすい
権限が複雑	アプリ分割、レコード権限、フィールド権限で表せるかを見る	Dataverse、Pleasanter、自社DBなどの管理設計を見る
外部連携が多い	正本と更新方向が説明できるなら候補になる	Microsoft 365中心ならPower Platform、自社DB中心ならPleasanter
保守担当が弱い	外部支援と運用ルールをセットで入れる	情シス主導やSaaS管理の体制に合わせて選ぶ

この表で大事なのは、kintoneを無理に選ばないことです。

kintoneが向く業務は多いですが、すべての業務をkintoneに寄せる必要はありません。

Microsoft 365の中で完結する申請や通知なら、Power Platformの方が自然な場合があります。

社内サーバーで持つ必要があり、開発者が保守できるなら、Pleasanterを候補にする意味があります。

チームの制作進行や軽いプロジェクト管理なら、Airtableで十分な場合もあります。

反対に、部門をまたぐ業務台帳、案件、問い合わせ、申請、作業履歴、請求前確認を現場で育てるなら、kintoneは見やすい候補になります。

選定チェックリスト

最後に、選定前のチェックリストを置きます。

この表に答えられない場合は、製品比較より先に業務整理をした方がよいです。

質問	答えられないと起きること
1レコードは何を表すか	顧客、案件、履歴、明細が混ざる
正本データはどこか	同じ情報を複数ツールで編集する
入力者は誰か	画面が現場に合わない
確認者は誰か	ステータスや承認が形だけになる
見せてよい範囲はどこまでか	権限が後付けで複雑になる
Microsoft 365との関係は何か	Teams通知やSharePointとの役割が曖昧になる
オンプレやOSS要件は本当に必須か	必要以上に保守が重くなる
外部連携は片方向か双方向か	データ不一致が起きる
失敗時に誰が直すか	連携エラーが放置される
半年後に誰が棚卸しするか	アプリ、ビュー、項目が増え続ける

チェックの結果は、次のように読むとよいです。

答えの傾向	候補の読み方
現場が作り、業務責任者が管理し、部門横断の台帳にしたい	kintoneを中心に見る
Microsoft 365、Teams、SharePoint、Power Automateが業務の中心	Power Platformを強く見る
自社サーバー、OSS、オンプレ、拡張開発が前提	Pleasanterを強く見る
少人数チームの企画や制作進行を軽く回したい	Airtableを強く見る
顧客、案件、請求、会計、通知が混ざっている	先に正本と連携方向を分ける

このチェックリストで候補が1つに決まらないこともあります。

その場合は、無理に1つへ寄せず、役割を分けます。

申請受付はkintone。

Teams通知はPower Automate。

社内DBはPleasanter。

企画段階の進行表はAirtable。

請求は会計ソフト。

このような分担は十分にあり得ます。

重要なのは、同じデータを複数の場所で編集できる状態にしないことです。

Bitlightに相談できること

Bitlightでは、kintoneを単体のアプリ作成ツールとしてではなく、業務アプリ選定と運用設計の一部として整理できます。

相談できる内容は次の通りです。

• kintone、Power Platform、Pleasanter、Airtableの比較軸整理
• 現場ユーザー、情シス、外部支援の責任分担
• 顧客、案件、申請、履歴、マスタの正本整理
• 料金、権限、連携、保守の比較表作成
• Microsoft 365、Teams、SharePoint、Power Automateとの分担
• オンプレ、OSS、自社サーバー要件の整理
• アプリ分割、権限表、通知、一覧、プロセス管理の設計
• API連携、連携サービス、手動CSV運用の切り分け
• 導入後の棚卸し、変更申請、管理者引き継ぎの設計

kintoneを選ぶべきかどうかは、製品だけでは決まりません。

既存のMicrosoft 365運用、自社サーバー要件、現場の変更力、情シスの管理範囲、外部支援の使い方で変わります。

比較表は、最後に見る資料ではありません。

自社の業務条件を書き出し、料金、権限、連携、保守の列を読み直すための資料です。

この順番にすると、kintone比較は単なるツール選びではなく、使い続けられる業務アプリ構成の設計になります。