LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

kintoneカスタマイズ外注とは — 標準機能の限界と外注が必要になる3つの場面

kintoneカスタマイズ外注とは、サイボウズが提供するクラウド型業務アプリプラットフォーム「kintone（キントーン）」において、ノーコードの標準機能では対応できない要件を、外部のITベンダーや開発会社に委託して実装する取り組みを指します。

kintoneはノーコードでアプリを構築できる点が強みです。一方で、外部システムとのリアルタイム連携・複雑なバリデーション処理・専用UIの構築といった要件には、JavaScript APIやREST APIを用いた開発が前提となります。これらの実装は専門的な知識が求められるため、内製よりも外注が現実的な選択肢となります。

標準機能でできること・できないこと

kintoneの標準機能では、フォームの作成・レコード管理・通知・ワークフロー・スペースによるコミュニケーションが利用できます。これらはノーコードで設定でき、Excelや紙運用からの移行に適しています。

一方で標準機能の範囲では対応が難しいケースがあります。具体的には、他社SFAやERPとのリアルタイムデータ同期・帳票PDFの自動生成・一覧画面へのグラフ描画・複数アプリをまたいだ集計計算などです。これらの要件を実現するには、JavaScript APIまたはREST APIを使ったカスタマイズ開発が必要になります。

JavaScript APIとREST APIで広がるカスタマイズ範囲

サイボウズ開発者ネットワーク（cybozu.dev）が公開するkintone JavaScript API^*1では、レコード一覧・詳細・作成・編集画面のイベントをフックして任意の処理を実行できます。たとえば入力値のリアルタイムバリデーション・フィールドの表示/非表示切り替え・外部ボタンの追加が可能です。

kintone.proxy関数を使えば、kintone外部のAPIとのセキュアな通信もJavaScriptから実行できます。これにより、Google MapsやSlack・社内の別システムとの連携をkintone画面上から直接トリガーできるようになります。

REST API^*2はkintoneの外部からレコード・アプリ・スペースのCRUD操作を行うためのインターフェースです。夜間バッチ処理・基幹システムとの双方向データ同期・外部BIツールへのデータ連携といった用途に使われます。APIリクエスト数の上限はプランによって異なり、スタンダードコースでは1アプリあたり1日10,000回、ワイドコースでは100,000回となっています^*3。

プラグイン・Webhook・外部API連携の実装は専門知識が前提

kintoneプラグインは、カスタマイズコードをパッケージ化して複数のアプリや環境に配布できる仕組みです。セキュリティポリシーにより署名付きパッケージとして提供する必要があり、開発にはCLIツールの習熟とJavaScript・マニフェストファイルの設計知識が求められます。

WebhookはkintoneのレコードイベントをHTTPリクエストで外部サーバーに通知する機能です。連携先となる外部サービスのAPI仕様理解・受信サーバーの構築・エラーハンドリング設計が必要となるため、情報システム担当者が個人で実装するには技術的なハードルがあります。外注を検討する3つの典型的な場面は、外部システム連携・プラグイン開発・Webhookを用いたリアルタイム通知の自動化です。

kintoneカスタマイズ外注の費用レンジ — 規模別の市場参考値と内訳

以下に示す費用レンジは、市場参考値であり一次資料による根拠のある公式データではありません。実際の費用は要件・開発会社・契約形態によって大きく異なります。相見積もりを複数社から取ることで、自社の要件に適した価格を把握するようにしてください。

小規模カスタマイズ：単一アプリ・フィールド制御・バリデーション追加

単一のkintoneアプリに対してJavaScriptコードを追加し、特定のフィールドの表示/非表示を動的に切り替えたり、入力値の整合性チェックを画面上で行ったりする改修が小規模カスタマイズに該当します。コード量は数十〜数百行程度が多く、開発期間は数日から数週間です。

コストが小さくても、納品後の保守が契約に含まれているかどうかは確認が必要です。kintoneはサイボウズが定期的にプラットフォームを更新するため、JavaScriptの実装がアップデート後に動作しなくなるリスクがあります。

中規模カスタマイズ：外部API連携・帳票出力・一覧カスタム表示

外部の会計システムや在庫管理ツールとkintoneをREST APIで接続し、データを双方向に同期する実装は中規模に分類されます。帳票PDFの自動生成・カスタムダッシュボード表示・複数アプリをまたいだ集計ロジックなども同様です。

この規模では、kintone.proxy関数や外部サーバーを経由した連携アーキテクチャの設計が必要になります。スタンダードコースのAPIリクエスト上限（1日10,000回/アプリ^*5）を超えるアクセス頻度が見込まれる場合は、設計段階でワイドコースへのプラン変更またはリクエスト数の最適化を検討する必要があります。

大規模カスタマイズ：複数システム連携・プラグイン開発・保守契約込み

ERPや人事システムなど複数の基幹システムとkintoneを統合し、データを一元管理する構成は大規模カスタマイズです。プラグインとして開発し社内の複数部門・複数環境に展開するケースも含まれます。

この規模では開発費だけでなく、継続的な保守・運用委託の費用も見積もりに含めることが大切です。kintone側の仕様変更だけでなく、連携先システムのAPIバージョンアップや認証方式の変更にも対応する必要があるため、対応可能な体制を持つベンダーの選定が品質に直結します。

外注先の選び方 — 認定パートナーと受託開発会社の比較

kintoneカスタマイズの外注先は大きく2つに分けられます。サイボウズが認定するkintoneパートナーと、kintone開発の実績を持つ受託開発会社・SES会社です。それぞれに特性があり、自社の要件と照合して選定することが求められます。

サイボウズ認定パートナーを使うメリットと限界

サイボウズはkintoneの公式パートナー制度を運用しており、認定を受けた企業はkintoneの販売・導入支援・カスタマイズ開発を提供しています。認定パートナーはサイボウズから技術情報・サポート・トレーニングを受けており、製品の最新仕様に追随しやすい点が強みです。

一方で、認定パートナーはkintone導入支援を専業とする企業が多く、複雑な外部システム連携やフルスクラッチ開発の規模になると対応できないケースがあります。また、パートナー企業の規模・技術力・対応可能な業種は企業によって異なるため、個々のパートナーの実績確認が必要です。

受託開発・SES各社の強みと失敗パターン

受託開発会社はkintoneを含む幅広いシステム開発の実績を持ち、外部API連携・データ設計・インフラ構築まで一体で対応できる場合があります。プラグイン開発や複数システム統合など、技術的に複雑な要件では受託開発会社の方が適していることがあります。

失敗パターンとして多いのは、kintone固有のAPI制限やセキュリティポリシーを把握していないベンダーに依頼するケースです。たとえばkintone外部の任意のサーバーへの直接HTTPリクエストはkintoneのJavaScript環境では制限があり、kintone.proxyを経由する実装が必要です。この仕様を知らないベンダーが設計すると、後工程での手戻りが発生することがあります。

継続保守・運用委託まで対応できるかを選定軸にする

kintoneカスタマイズは「開発して終わり」ではなく、サイボウズによるプラットフォーム更新への追随・利用者からの改修要望への対応・連携先システムの仕様変更対応が継続的に発生します。初回の開発だけを依頼して保守体制が存在しない状況になると、次の改修時に再度ベンダー探しからやり直す必要が生じます。

外注先の選定では、保守・運用委託まで一貫して対応できるかどうかを初期の選定段階で確認することが、中長期のコスト抑制につながります。保守範囲・対応SLA・月額費用感を見積もり時点で提示できるベンダーが、継続関係を前提として動けるパートナーの目安となります。

kintoneカスタマイズ外注の進め方 — 5ステップ

外注を成功させるために必要な5つのステップを整理します。ステップを飛ばして本開発に入ると、要件の取り込み漏れや費用の大幅超過につながるため、順番通りに進めることが大切です。

ステップ1：標準機能で代替できない要件を確定する

最初に行うべきは、「外注しなければ実現できない要件」を特定することです。kintoneの標準機能・計算式・関連レコードルックアップなどで代替できるケースは、外注せずに解決できます。外注が必要な要件だけを絞り込むことで、初期費用を抑えられます。

要件の棚卸しでは、利用部門の担当者と情報システム部門が協力して、「現在の業務フローのどのステップが標準機能では実現できないか」を具体的に書き出します。この段階で曖昧なまま進むと、ベンダーへの説明が不十分になり、見積もりの精度が下がります。

ステップ2：RFPを作成してAPI制限・プランを明示し複数社に相見積もる

要件が確定したら、RFP（提案依頼書）を作成してベンダーに提示します。RFPには、使用しているkintoneのプラン（スタンダード/ワイド）・連携する外部システム名とAPI種別・想定するレコード件数と更新頻度・必要なセキュリティ要件を明記します。

特に重要なのは、APIリクエスト数の制約です。スタンダードコースでは1アプリあたり1日10,000回、ワイドコースでは100,000回という上限が設けられています^*5。この情報をRFPに含めることで、ベンダーがアーキテクチャ設計を適切に行えるようになります。相見積もりは3社以上から取ることで、費用相場と技術アプローチの比較が可能になります。

ステップ3：PoCでスモールスタートして技術実現性を確認する

本開発に入る前に、最も技術的不確実性が高い部分だけをPoC（概念実証）として先行開発します。外部APIとの認証・データ変換・kintone.proxyを経由した通信などが典型的なPoC対象です。

PoCを通じて「この要件はkintoneのAPI制限内で実現できる」という確認が取れてから本開発に移行することで、後工程での設計変更コストを抑えられます。PoCのスコープを小さく保ち、2〜4週間以内に結果が得られるよう設計するのが実務上の目安です。

ステップ4：本開発・テスト・受け入れ確認を段階的に行う

本開発は要件定義書・基本設計・詳細設計・実装・テストの順に進めます。kintoneの無料開発者ライセンスを活用することで、本番環境に影響させずに開発・テストを行えます^*4。テスト環境での動作確認後、本番環境への移行前に情報システム担当者による受け入れ確認を実施します。

受け入れ確認では、要件定義書に記載した各要件が実装されているかをチェックリストで検証します。不具合が発見された場合の修正対応期間・無償保証範囲をあらかじめ契約に明記しておくことが、後のトラブル防止につながります。

ステップ5：継続保守とkintoneバージョンアップへの追随体制を確立する

リリース後の保守体制の確立が最終ステップです。kintoneはサイボウズによって定期的にプラットフォームが更新されるため、JavaScriptカスタマイズが更新後も正常に動作するかを確認する運用プロセスが必要です。

保守契約では、対応する変更の種類（バグ修正のみか改修も含むか）・月あたりの対応工数上限・SLA（応答時間・解決時間の目安）を明確にします。外注先が継続してkintoneバージョンアップ情報を把握し、事前に動作確認を行える体制を持っているかどうかを、選定段階で確認することが大切です。

外注を失敗させる3つの落とし穴

kintoneカスタマイズの外注では、事前に対策を講じなければコストや品質に大きな影響を与える落とし穴が3つあります。それぞれの落とし穴と対策を整理します。

落とし穴1：APIリクエスト上限を無視したアーキテクチャ設計

kintoneのREST APIにはプランごとに1日あたりのリクエスト数上限があります。スタンダードコース（1,800円/ユーザー/月）では1アプリあたり1日10,000回、ワイドコース（3,000円/ユーザー/月、最低1,000ユーザー）では100,000回です^*3,*5。

外部システムとの同期頻度が高い連携を設計する際、この上限を考慮しないとリクエスト数が上限を超え、連携が停止するリスクがあります。対策として、設計段階でピーク時のリクエスト数を見積もり、上限との余裕を確認することが必要です。上限を超える見込みの場合はリクエスト数の最適化（差分更新・バッチ処理）またはプランのアップグレードを検討します。

落とし穴2：kintoneアップデートで動作しなくなるJavaScript実装

kintoneのJavaScript APIは、サイボウズの更新ポリシーに基づいて廃止予定のAPIが告知されることがあります^*1。外注したカスタマイズが廃止予定のAPIを使っている場合、将来のkintoneアップデートで動作しなくなるリスクがあります。

対策は2つです。1つ目は、外注先が最新の開発者ドキュメントに準拠した実装を行っているかを納品時にコードレビューで確認すること。2つ目は、保守契約にAPIバージョン追随の対応を明示的に含めることです。

落とし穴3：保守対象が不明確なまま契約する「仕様凍結リスク」

初期開発の費用だけで契約し、保守範囲を定めないまま納品を迎えると、連携先システムの仕様変更・利用者からの改修要望・バグ発生時の対応で都度スポット費用が発生します。中規模以上のカスタマイズでは、こうしたスポット対応の累積が初期開発費を上回るケースがあります。

保守範囲を「納品後〇ヶ月の無償バグ対応」「月〇時間以内の改修対応を月額〇万円で提供」のように具体化して契約することが、長期的なコスト管理に有効です。仕様変更が生じた際に追加費用の算出根拠が明確になり、ベンダーとの認識齟齬を防げます。

まとめ — kintoneカスタマイズ外注を成功させる3つの判断軸

本稿では、kintoneカスタマイズ外注の費用レンジ・外注先の選び方・5ステップの進め方・失敗パターンを整理しました。要点を3つに集約すると次の通りです。

第一に、kintone固有のAPI制限（プランごとのリクエスト上限・JavaScript APIの仕様）を把握したうえで要件を固めることが、見積もり精度と設計品質の前提となります。第二に、費用だけでベンダーを選ぶのではなく、継続保守・バージョンアップ追随まで対応できる体制があるかを選定段階で確認することが、再委託コストの抑制につながります。第三に、PoCでスモールスタートして技術実現性を検証してから本開発に進むことが、後工程での手戻りリスクを低減します。

kintoneカスタマイズの外注を検討している場合は、要件の棚卸しとRFP作成の段階から、API制限・保守体制・プランとの整合性を意識して進めることをお勧めします。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：サイボウズ開発者ネットワーク「kintone JavaScript API ドキュメント」（2026年確認）
2. *2　出典：サイボウズ開発者ネットワーク「kintone REST API ドキュメント」（2026年確認）
3. *3　出典：サイボウズ「kintone 料金プラン」（2026年確認）
4. *4　出典：サイボウズ開発者ネットワーク「kintone 開発者ネットワーク」（2026年確認）
5. *5　出典：サイボウズ開発者ネットワーク「kintone REST APIの共通仕様」（2026年確認）

Tweet