「kintoneでなんとかなる」と言う社長判断の落とし穴｜3年後に必ず後悔する3つのこと

「kintoneでいい」が、3年後の負債になる

DX投資の社内検討で頻繁に出る発言がある。「うちはまだ早い、kintoneでなんとかなるんじゃないか」。社長や決裁者がノーコード／SaaSへの過剰な期待を口にし、担当者が反論しきれずに案件がフェードアウトする。3年後、業務量は増え、レコード数は限界に近づき、誰も全体像を把握していない仕組みが社内に残る。

結論を先に言う。2026年時点で「kintoneでなんとかなる」が成立する場面はほとんどない。生成AI駆動開発（AIファースト開発）が出てきたことで、開発スピード・初期費用・拡張性・撤退コストのどの軸でも、kintoneより生成AI開発の方が安くて早い。「kintoneかフルスクラッチか」を悩んでいる時点で、議論の前提が古い。

本記事では、kintoneを選んだ場合に3年後に必ず後悔する3つのこと、生成AI開発が現代の標準になった理由、それでもkintoneを選ぶ前に確認すべき問い、そして「kintone」発言の裏にある本当の動機を整理する。

前提：もう生成AI開発の方が安くて早い、どのケースも

「kintone vs フルスクラッチ」の二択が成立していたのは、スクラッチ開発が「数百万〜数千万、半年〜1年」を意味していた時代の話だ。要件定義に数ヶ月、設計に数ヶ月、実装に半年、合計で1年がかり、初期費用1,000万超。これと比較すると「kintoneで月額数万円・即日スタート」が魅力的に見えた。

この前提は崩れている。生成AI駆動開発では、要件をユーザーストーリーに落とせば1〜2週間でプロトタイプ、1〜3ヶ月で本番運用が可能だ。初期費用0円から始められるサービスもある。「kintoneで早く始める」と「生成AI開発で早く始める」を比較したとき、初期費用も期間もほぼ同等、3年後の拡張性と撤退コストでは生成AI開発が圧倒する。

これはBeekleの事業ポジショントークではなく、構造的な事実認識だ。コード生成のコストが下がり、要件定義からデプロイまでをAIが伴走する開発手法が現場に降りてきた結果、kintoneを選ぶ合理性のある領域は急速に狭まっている。

かつてノーコード／SaaSが向いていた領域（と、それがなぜ狭まったか）

kintoneやSaaSが力を発揮していた領域は明確だった。

• レコード規模が予測可能：年間の追加レコード数が数千〜数万のオーダーで、5年後の規模が見える
• 業務フローが完全に標準化されている：申請・承認・台帳管理など、業界横断で共通したプロセス
• 例外処理が皆無：本流の流れだけで業務の8割以上が回り、例外は手作業で対応できる
• 部署横断の連携が浅い：1部署内で完結する、もしくは他部署との連携がCSV取り込み程度

4条件すべてを満たす業務は、現実にはほとんどない。1つでも崩れる業務にkintoneを当てると、3年後の負債が大きくなる。そして4条件を満たす業務であっても、生成AI開発で同じものを作る方が、3年後の選択肢が広い。kintoneでも持つ業務は、生成AI開発でも持つ。逆は成立しない。

後悔1: レコード数増加で詰まる

kintoneは1アプリあたりのレコード数の制限がある。プランによって異なるが、現実的な使用感での限界は数十万レコード規模だ。「最初は数千件だから問題ない」と判断した業務が、3年後に月次100万レコード追加される事業に成長することがある。

レコード数が膨らむと、検索が遅くなる、集計が止まる、画面が表示されない、APIエラーが頻発する。最初は「重い」程度だが、ある閾値を超えると「使えない」に変わる。

この時点で取れる選択肢は3つしかない。古いレコードを別アプリに退避する（業務が分散して管理不能になる）、有償プランに上げる（年間コストが想定を大きく超える）、別システムに移行する（kintoneで蓄積した業務知識をすべて作り直す）。どれも、最初に生成AI開発で小さなシステムを作っていれば避けられた工数だ。

後悔2: 業務ロジックの分岐が複雑化して保守不能になる

kintoneは業務フローのプロセスをアプリ内のフィールドと条件分岐で表現する。最初は「申請→承認」だけでも、3年経つと条件分岐が増える。「金額50万円以上は部長承認、それ以上は役員承認」「特定取引先は与信確認後の自動承認」「年度末は経理承認を経由する」といった分岐が、フィールド設定とプラグインの組み合わせで実装されていく。

この実装は、設計した本人しか把握できない状態に陥る。担当者が異動・退職すると、誰も全体像を理解していないシステムが残る。新しい分岐を追加しようとすると、既存の動作が壊れる。バグの再現条件が分からない。修正のために設定を触ると、別の業務が止まる。

この状態を「kintoneブラックボックス」と呼ぶ。コード化されていない業務ロジックが、設定画面の組み合わせとして散らばっており、リバースエンジニアリングできない。生成AI開発で同じ業務を作っていれば、分岐はコードに書かれており、AIに「この分岐の意図は？」と聞けば説明が返ってくる。

後悔3: 部署横断の連携が来た時、撤退も移行もできない

3年経つと、kintoneで管理している業務に「他部署と連携したい」要望が来る。営業部の案件管理を経理部の請求業務と連携させたい、人事部の労務管理を情シスの権限管理と連携させたい、製造部の在庫データを販売部のEC基盤と連携させたい。

kintone同士の連携、外部APIとの連携は技術的には可能だ。だが連携を増やすほど、上で述べた「分岐の複雑化」と「レコード数の増加」が同時に起きる。連携先のシステムが変わるたびにkintone側も触る必要があり、保守工数が階段状に伸びる。

この段階で「別システムに移行しよう」と決断しても、3年分の業務知識がkintoneの設定画面に閉じ込められている。移行プロジェクトは事実上のシステム再構築になり、当初kintoneを選んだときの「安く早く始める」メリットが完全に消える。3年前に生成AI開発を選んでいれば、この移行プロジェクトそのものが不要だった。

なぜ「もう生成AI開発の方が安くて早い」と断定できるのか

4軸で見ると、構造的に生成AI開発が圧倒している。

• 初期費用：従来のスクラッチ開発は要件定義から数百万、本番化まで1,000万超が相場だった。生成AI駆動開発では、要件をユーザーストーリーに落とした時点でAIがコード生成し、初期費用0円から始められるサービスもある。kintone導入の初期設定費用と同等か、より安い
• 開発速度：要件定義→プロトタイプ→本番化までを1〜2週間でひと回しできる。kintoneでアプリを設計するのと同等か、それより速いケースも多い。「速さでkintoneを選ぶ」理由がもう成立しない
• 拡張性：レコード数制限や分岐の複雑化に縛られない。最初からデータベース設計とコードベースで作るので、3年後にレコード数が爆発しても、業務ロジックが分岐しても、保守可能な状態を維持できる。これは構造的な差で、kintoneでは追いつけない
• 撤退コスト：データはRDBに入っており、ロジックはコードで読める。担当者が異動・退職しても、別ベンダーや社内エンジニアが引き継げる。kintoneブラックボックスとは対極の状態

「生成AI開発はまだ要件定義の手間がかかる」という反論は、kintoneも同じだ。kintoneアプリの設計には、フィールド定義、ワークフロー設計、権限設定、ビュー設定が必要で、これは事実上の要件定義になる。違いは、その要件定義の成果物がコードに落ちるか、設定画面に閉じ込められるかだけだ。

それでもkintoneを選ぶ前に確認すべき3つの問い

kintoneを選ぶ合理性が残るとすれば、極めて狭い領域だ。決裁者は次の3つの問いに、自信を持ってYESと答えられる場合だけkintoneを選ぶべきだ。

• 5年後のレコード規模が、確実に低位で推移するか：年間追加レコードが数千件、累計でも数万件以内に収まると言い切れるか
• 業務分岐がこの先も発生しないと言い切れるか：金額・取引先・期間等での条件分岐が、向こう3年で増えないと断言できるか
• 部署横断連携の予定がゼロか：他部署のシステム改修計画と接続する予定が、向こう3年でないか

3つすべてYESなら、kintoneでも持つ。1つでもNOなら、生成AI開発の見積もりを取り直す。「とりあえずkintoneで」と判断した場合、それは投資判断の保留であって、判断ではない。

「kintone」と言うとき、本当は何を言いたいのか

社長が「kintoneでなんとかなる」と発言する裏には、ほぼ例外なく以下の動機がある。

• 専門外の投資判断を間違えたくない：システム開発投資は「自分が見えていない領域」だから、決断を遅らせたい
• 現状で困りきっていない：スプシ運用やExcelで動いている。痛みは感じているが、止まっていない
• 追加投資のタイミングを見極めたい：今期は別の投資があり、来期以降に回したい
• 担当者を信用しきれていない：DX担当が「これくらい必要」と言ってきても、判断材料が手元にない

動機は正当だ。問題は、これらの動機が「kintoneで十分」という誤った技術判断の形で言語化されることだ。本来は「投資判断を保留したい」「もっと判断材料がほしい」と言うべきところを、「kintoneでなんとかなる」と言ってしまう。担当者は技術的な反論をしようとして、決裁者の本当の不安に答えられない。

解決策は、技術論で殴り合うことではない。決裁者の本当の動機を言語化して、判断材料を揃えること。「投資を保留する場合の3年後リスク」「現状運用を続けた場合の業務工数増加見込み」「生成AI開発で最小投資から始める場合の概算費用と期間」を並べて、社長が事実ベースで判断できるようにする。

「kintoneでいい」を、事実ベースの判断に変える

2026年時点で、kintoneとフルスクラッチの二択を悩むこと自体が古い。生成AI駆動開発が出てきた現代では、kintoneを選ぶ場面は「業務が完全に標準化され、5年スパンでも変わらない少数のケース」だけだ。それ以外は生成AI開発の方が安くて早い。

判断する前に、3つの問い（レコード規模・分岐の予測・部署横断連携）に自信を持ってYESと答えられるかを書き出す。3つすべてYESならkintoneでも持つ。1つでもNOなら、生成AI開発の見積もりを取る。これが2026年時点の決裁者の判断だ。

関連記事：生成AIで1〜2週間プロトタイプを作る4ステップ ／ 初期費用0円でシステム開発を始める方法 ／ 生成AI駆動開発（AIファースト開発）とは ／ DX・システム開発で失敗する典型5パターン ／ 「作ったのに使われないシステム」を防ぐ要件絞り込み術