kintone の利便性と弱点

大学や自治体、企業の現場で急速に広がったローコード基盤 kintone の強みと限界について、ChatGPT との会話ログをそのまま公開します。

user:

kintone はそんなに便利？

gpt-5:

kintone は、かなり「刺さる組織には刺さる」タイプの業務アプリ基盤です。 特に、

• Excel + メール + 手作業 + 属人化
• 「ちょっとした業務システム」が大量にある
• 情シスが弱い
• でも現場は改善したい

という組織では強いです。

一方で、「何でもできる魔法の道具」ではなく、向き不向きはかなりあります。

何が便利なのか

kintone は雑に言うと、

「Excel でやっていた業務を、Webアプリ化する」

ためのローコード基盤です。

例えば：

• 研究費申請管理
• 備品管理
• 問い合わせ管理
• 進捗管理
• 学会参加申請
• 原稿管理
• 学生指導記録
• 実験予約

みたいな、「業務の流れはあるが、専用システムを作るほどではない」ものを高速に作れます。

強いところ

1. 非エンジニアでも作れる

フォームをGUIで作って、

• テーブル
• ステータス
• 承認フロー
• 通知
• 権限

などを設定できます。

つまり、

「Excel職人」がそのまま「業務アプリ職人」になれる

のが大きい。

2. 「とりあえず動く」が異様に速い

普通の業務システム開発だと：

• 要件定義
• DB設計
• フロントエンド
• 権限
• 認証
• デプロイ

が必要ですが、kintone は最初からかなり揃っています。

なので、

「明日から試したい」

が本当にできる。

3. Excel 地獄をかなり減らせる

多くの組織では、

• Excel が最新版かわからない
• 誰が更新したかわからない
• メール添付で壊れる
• マクロがブラックボックス

という問題があります。

kintone はデータベース型なので、

• 同時編集
• 履歴
• 権限
• 一元管理

が比較的まともです。

逆に弱いところ

1. 本格システムには厳しい

例えば：

• 大規模ERP
• 高速トランザクション処理
• 複雑な会計
• 超高度なワークフロー
• 巨大データ

みたいなのは苦手。

「軽〜中量級業務システム」が主戦場です。

2. 作る人のセンスに依存する

Excel と同じで、

• 命名規則が崩壊
• アプリ乱立
• 権限ぐちゃぐちゃ
• フィールド定義が不統一

になりがちです。

なので、

「野良DX」

が大量発生することがあります。

3. 結局 JavaScript が欲しくなる

最初はノーコードで始めても、

• ちょっと複雑なUI
• 自動処理
• 外部連携

をやり始めると、かなり JavaScript を書きたくなります。

すると突然、

「ローコードのはずが普通に開発してる」

状態になる。

日本企業で強い理由

kintone は、日本企業の

• 稟議
• ハンコ文化
• 細かい承認
• Excel運用
• 部署ごとの独自業務

との相性が良いです。

海外SaaSは、

「業務を標準化しろ」

という思想が強いですが、kintone はむしろ

「そのカオス業務をまずデジタル化しよう」

寄り。

ここが日本で普及した大きな理由です。

大学・研究室との相性

実はかなり良いです。

大学や研究室って、

• 例外処理が多い
• ローカルルールが多い
• 人の入れ替わりが多い
• でも専用システムを作る予算はない

ので、kintone 的な「半手作りシステム」が合うことが多い。

特に：

• 研究室運営
• 共同研究管理
• 機器予約
• 学生進捗
• 科研費事務

あたりは相性が良いです。

ただし「銀の弾丸」ではない

失敗例も多くて、

• 「全部 kintone でやる」
• 「設計なしで増殖」
• 「担当者しかわからない」
• 「Excelより複雑」

になることもあります。

なので本質的には、

「小規模業務システムを高速に試作・改善する道具」

として使うと強い、という感じです。

user:

典型的なワークフローは？

gpt-5:

典型的には、

「入力 → 状態管理 → 承認 → 通知 → 集計」

を、Excel とメールの代わりに一つのWebアプリで回す感じです。

kintone の基本単位は「アプリ」で、各アプリが

• 一覧表
• 入力フォーム
• データベース
• ワークフロー

を兼ねています。

例えば、かなり典型的な「出張申請」を例にすると：

1. フォーム作成

管理者がGUIで項目を作る。

• 氏名
• 所属
• 出張先
• 日程
• 予算
• 理由
• 添付ファイル

など。

ここはほぼ Google Form 的です。

2. レコード入力

利用者が申請。

すると1件が「レコード」として保存される。

Excel 的には「1行」。

3. ステータス管理

ここが kintone 的な肝です。

例えば：

下書き
↓
申請中
↓
指導教員承認
↓
事務承認
↓
完了

みたいな状態遷移を設定できる。

4. 権限設定

状態ごとに：

• 誰が見られるか
• 誰が編集できるか
• 誰が承認ボタンを押せるか

を変えられる。

例えば：

• 学生：自分の申請だけ編集可能
• 教員：研究室メンバーを承認可能
• 事務：全件閲覧可能

など。

5. 通知

状態が変わると：

• メール
• kintone通知

が飛ぶ。

例えば：

「あなた宛の承認依頼があります」

6. 一覧・検索

全部DB化されているので、

• 「未承認だけ表示」
• 「2025年度だけ」
• 「科研費Aだけ」

みたいな検索ができる。

ここで Excel 地獄からかなり解放される。

7. 集計・グラフ

簡易的な：

• 件数集計
• 円グラフ
• 月別推移

も作れる。

8. 外部連携（欲しくなる）

そのうち：

• Slack通知
• Teams
• Google Calendar
• 会計システム
• SSO
• API連携

をやりたくなり、JavaScript や REST API を触り始める。

ここから「軽い業務改善」から「ちゃんとしたシステム開発」へ寄っていく。

実際の現場で多い構成

実運用では、

マスタ管理アプリ
    ↓
申請アプリ
    ↓
承認アプリ
    ↓
集計アプリ

みたいに複数アプリを関連付けます。

つまり：

• 教員マスタ
• 予算マスタ
• 学生名簿

などを別アプリ化する。

すると、だんだん「簡易ERP」っぽくなっていく。

なぜ現場にウケるのか

重要なのは、

「現場担当者が自分で直せる」

ことです。

普通の業務システムだと、

現場 → 情シス → SIer → 修正

ですが、kintone だと：

現場担当がその場で項目追加

できる。

この速度感がかなり大きい。

逆にハマる罠

典型的には：

最初

便利！

↓

半年後

アプリが80個ある

↓

1年後

誰も全体構造を理解していない

↓

2年後

このJavaScript誰が書いた？

になります。

つまり、

「Excel の無秩序さを Web 化できてしまう」

のが強みでもあり弱みでもあります。

user:

微妙に昔のMS Accessっぽい雰囲気が

gpt-5:

かなり近いです。 実際、多くの人が

「現代のクラウド版 Access」

みたいな印象を持っています。

ただし、完全に同じではなく、

• Access 的な部分
• Access では弱かった部分
• 逆に Access より弱い部分

があります。

かなり Access 的なところ

1. 「業務DBを現場が作る」

これが本質的に同じです。

例えば：

• 顧客管理
• 在庫管理
• 申請管理
• 実験記録
• 問い合わせ台帳

みたいな、

「専用システムを作るほどではないが、Excelではつらい」

領域。

これは昔の Microsoft Access が得意だった世界そのものです。

2. 「Excelの次」

Access って昔、

Excelでは限界
↓
でも本格DBは重い
↓
じゃあAccess

というポジションでした。

kintone もかなり近い。

3. 「現場主導」

Access 文化って、

「総務の○○さんが作った謎システム」

が大量に生まれる世界でした。

kintone もまさにそうです。

ただし、Access と違う重要点

1. クラウド前提

Access は：

• ローカルMDB
• ファイル共有
• ネットワークドライブ

文化でした。

なので：

• 壊れる
• 同時編集事故
• バージョン衝突

が多かった。

kintone は最初からWeb + クラウドDBなので、そのへんがかなり改善されています。

2. ワークフローが強い

Access は「DBアプリ作成ツール」寄りでしたが、kintone は：

• 承認
• 通知
• 権限
• ステータス管理

が最初から強い。

つまり、

「業務フロー」

をかなり意識している。

これは日本企業向けSaaSっぽい。

3. マルチユーザー前提

Access は実は：

「複数人で本格運用」

がかなり苦しかった。

kintone は最初から：

• ブラウザ
• 権限
• 同時利用
• モバイル

前提。

逆に Access の方が強かったところ

面白いのですが、昔の Access は意外と「開発自由度」が高かったです。

例えば：

• SQL直書き
• VBA
• フォーム制御
• レポート印刷
• ローカル処理

など。

下手すると「小規模業務システム開発環境」でした。

kintone は逆に、

「自由すぎない」

よう制限されています。

なので：

• 超複雑UI
• 高自由度画面
• 特殊帳票

はむしろ苦手。

歴史的に見ると

実は系譜としてかなり近いです。

Excel
↓
Access
↓
グループウェア
↓
クラウドSaaS
↓
kintone

みたいな流れ。

特に日本企業では、

• 「現場が自分で作る」
• 「情シス不足」
• 「業務が特殊」

という文化が強いので、Access 的需要がずっと存在している。

kintone はそのクラウド時代版と言える面があります。

なので、「なんか Access っぽい」はかなり本質を突いています。

user:

逆に kintone で運用上不自由するところは？

gpt-5:

かなりあります。 kintone は「軽量業務アプリ基盤」としては強いのですが、使い込むほど、

「あ、ここは本格システムじゃないんだな」

という限界が見えてきます。

典型的には次のあたりです。

1. リレーショナルDBとしては弱い

ここは Access とも共通です。

例えば：

• 複雑JOIN
• 正規化
• 多対多関係
• 高度な集計
• SQL自由記述

がかなり弱い。

典型的につらくなる例

研究費
  ↔ 教員
  ↔ 学生
  ↔ プロジェクト
  ↔ 出張
  ↔ 成果物

みたいな関係が増えると、

「関連レコードの参照地獄」

になりやすい。

2. UI自由度が低い

kintone のUIはかなり「決まった形」です。

なので：

• 複雑ダッシュボード
• 高度なインタラクション
• 特殊入力UI
• リアルタイム画面更新

などは苦しい。

よく起きること

最初：

標準UIで十分

半年後：

ここだけちょっとカスタムしたい

1年後：

JavaScriptで画面改造

2年後：

もはや何のフレームワークかわからない

3. 帳票が弱い

日本業務で超重要なのに、ここが意外と弱い。

例えば：

• 請求書
• 稟議書
• 見積書
• 学内様式
• ハンコ位置固定PDF

など。

kintone 標準では：

「帳票文化」

への対応が弱め。

なので結局、

• プラグイン
• 外部サービス
• PDF生成カスタム

に頼りがち。

4. バージョン管理が弱い

これはエンジニアが嫌がる点。

例えば：

• 誰が設定変えた？
• いつ権限変えた？
• JavaScript差分どこ？
• 本番反映どう管理する？

が弱い。

結果

本番で直接編集

文化になりやすい。

Access 的。

5. 「アプリ乱立問題」

これは本当に多い。

kintone は作るのが簡単なので、

「とりあえず作る」

が加速する。

すると：

• 同じデータが5箇所
• 命名不統一
• マスタ不整合
• 似たアプリ大量発生

になる。

6. 性能限界

小〜中規模向けなので、

• 巨大データ
• 超大量レコード
• 複雑検索
• 高頻度API
• 重い一覧

は徐々につらくなる。

特に：

「全部kintoneに入れる」

をやると危険。

7. JavaScript地獄

kintone の怖いところは、

「簡単にカスタマイズできる」

こと。

つまり：

• jQuery断片
• 野良コード
• CDN依存
• 属人plugin

が増殖しやすい。

そして典型的に

退職者しかわからない

状態になる。

昔の Access VBA にかなり近い。

8. ガバナンスが難しい

現場主導が強みですが、逆に：

• 情シス統制不能
• セキュリティばらばら
• 権限設計崩壊
• データ定義不統一

が起きやすい。

9. 「あと少し」が永遠に続く

これはローコード全般の宿命。

最初：

80点を1日で作れる

でも、

残り20点

が異様に重い。

すると：

• plugin追加
• JS追加
• API追加

が積み上がり、

「普通に開発した方が早かったのでは」

ゾーンに入ることがある。

実は向いている用途はかなり限定的

強いのは：

• 中規模以下
• 業務フロー中心
• 定型入力
• 多少雑でも回る
• 現場改善

です。

逆に弱いのは：

• 厳密DB設計
• 複雑UI
• 高性能要求
• 長期大規模運用
• 高度内部統制

つまり kintone は、

「Excel と本格システムの間」

を埋めるのは非常に得意だけれど、

「本格システムそのもの」

にはなりきれない、

という理解がかなり正確です。

user:

ある程度、向いている人数の規模がありそうですね

gpt-5:

かなりあります。 kintone は実際、

「人数規模」よりも、 「業務複雑性 × 統制要求」

で限界が来るタイプです。

ただ、経験的にはかなり典型的なレンジがあります。

かなり向いている規模

数人〜数十人

ここは非常に強いです。

例えば：

• 研究室
• 小規模企業
• 部署単位
• 学科事務
• プロジェクトチーム

など。

なぜ強いのか

この規模だと：

• 「顔が見える」
• 暗黙知で回る
• 多少雑でも困らない
• 管理者1人でも把握可能

だから。

つまり、

「柔軟性 ＞ 厳密統制」

が成立する。

一番ハマるのは「50〜300人くらいの部分最適」

実はここが kintone の黄金レンジです。

例えば：

• 中小企業
• 部署横断業務
• 大学の特定部局
• 病院の一部門
• 工場の現場改善

など。

この規模の特徴

ここでは：

• Excel限界は来ている
• でもSAPは重すぎる
• 情シス人数が少ない
• 現場改善ニーズは強い

ので、

「軽量業務基盤」

として非常に刺さる。

逆に厳しくなる領域

数百〜数千人規模

ここから：

• 権限管理
• データ整合性
• ガバナンス
• 監査
• 標準化

が急激に重要になります。

すると、

「現場が自由に作れる」

が逆に危険化する。

典型的崩壊パターン

最初：

営業部で導入

↓

便利なので：

他部署も使う

↓

2年後：

アプリ数 300

↓

3年後：

誰も全体構造を理解していない

大企業での実際の使われ方

面白いのですが、大企業でも：

「全社基盤」

ではなく、

「周辺業務」

として使われることが多いです。

つまり：

• SAP
• Oracle
• 基幹システム

は別にあり、

kintone は：

• 現場改善
• 申請補助
• 一時DB
• 部門独自運用

を担当する。

大学だと特にありがち

大学は：

• 部局自治
• ローカルルール
• 小規模組織の集合体

なので、kintone 的なものと相性が良い。

ただし全学展開すると：

• 学部ごとに別文化
• 権限複雑
• 人事異動
• 長期保守

で急に厳しくなる。

実は「人数」より重要なもの

本当に重要なのは、

1. 業務が標準化されているか

標準化されているほど：

• ERP
• 専用SaaS

が強い。

逆に：

• 例外多い
• ローカル運用多い

ほど kintone 向き。

2. データ整合性要求

例えば：

• 会計
• 在庫
• 人事給与

みたいに、

絶対にズレてはいけない

領域は苦手。

3. 保守体制

kintone は：

「現場で育てる」

思想なので、

• 面倒を見る人
• 改善を回す人

がいないと崩壊しやすい。

なので、かなり雑に言うと：

くらいの感覚はあります。

user:

この記事では、この規模でうまくいっているように書いているけど、実際のところはどう？

200超アプリが全庁で稼働　埼玉県庁はなぜkintoneをDX基盤に選んだのか

gpt-5:

これは、かなり「本当にありえる成功例」だと思います。 ただし重要なのは、

「埼玉県庁の全業務が kintone 化された」

ではなく、

「特定種類の庁内ワークフローを共通基盤化した」

という点です。

ここを誤解すると、「kintoneで巨大組織全部いける」と見えてしまう。

実は、この事例はかなり kintone 向き

記事を読むと、中心は：

• 照会回答業務
• 進捗管理
• 部局横断の情報共有
• 承認フロー
• 集約
• 可視化

です。

これは kintone が最も得意な領域です。

逆に、やっていないはずのもの

おそらくですが、埼玉県庁でも：

• 人事給与
• 財務会計
• 住民DB
• 税
• 基幹住民サービス
• 大規模データ処理

を kintone に載せているわけではない。

そこは別の基幹系があるはずです。

つまり構造としては：

基幹システム
    ↑
kintone が周辺業務を接続

に近い。

13,000人でも成立する理由

ここが面白いところです。

「13,000人利用」と言っても、

13,000人が同じ巨大アプリを使う

とは限りません。

実際には：

• 小規模アプリが多数
• 各部局で局所利用
• 共通ワークフローだけ統一

である可能性が高い。

むしろ「200アプリ」は少ないくらい

実は、13,000人規模で200アプリは、

「かなり統制されている」

印象です。

野放図運用だと：

2000アプリ

くらいまで簡単に増えます。

なので、おそらく：

• DX推進部門
• 標準化ルール
• 命名規則
• 権限管理
• テンプレート化

をかなりやっているはず。

成功の鍵は「用途制限」

この記事で重要なのは、

「照会回答業務」

を主ターゲットにしていることです。

これは行政組織で猛烈に多い。

例えば：

各課へ調査
↓
Excel回収
↓
メール催促
↓
最新版不明
↓
集約地獄

という業務。

kintone はここに非常に強い。

行政との相性も実は良い

行政には：

• 定型フォーム
• 承認フロー
• 部局横断照会
• 履歴保持
• アクセス権

が大量にある。

しかも：

• 業務は多い
• 専用システム化は困難
• Excel依存が強い

ので、

「Excelを脱する共通基盤」

としてはかなり合理的。

ただし、本当に難しいのはここから

記事を見る限り、今は：

業務の電子化・共通化

フェーズです。

問題は次の段階。

危険領域1：アプリ増殖

今後：

• 各部局独自カスタム
• JS改造
• plugin依存
• 独自運用

が増えると、

「第二のAccess帝国」

化するリスクはある。

危険領域2：人事異動

自治体で怖いのはこれです。

kintone の真価は：

現場主導改善

ですが、自治体は：

• 2〜3年異動
• 担当変更
• 非IT職員

なので、

作った人がいない

問題が起きやすい。

危険領域3：統制 vs 現場自由

kintone は：

「現場が自由に作れる」

のが強み。

でも自治体規模では：

• セキュリティ
• 個人情報
• 監査
• 権限
• 保存年限

が重い。

つまり：

自由に作れる

と

統制したい

が衝突する。

なので、本当に成功かどうかは「5年後」

ローコード基盤は、

1年目

爆速で成果

↓

3年目

乱立開始

↓

5年目

保守体制勝負

になりやすい。

逆に、この事例がかなり賢いと思う点

記事の範囲では、

「全庁共通の照会回答業務」

という、

• 横断性が高く
• 定型化しやすく
• Excel依存が強く
• 基幹系ではない

ところに集中している。

これは非常に筋が良い。

なので総合すると：

• 「13,000人でkintoneは無理」という話ではない
• ただし「全業務をkintone」は危険
• この事例は比較的 kintone の得意領域を選んでいる
• 真の勝負は長期保守とガバナンス

という感じです。