2026/9/17更新: 2026/10/26約11分で読めます

kintoneの標準機能で足りる？プラグイン・追加開発・移行の分かれ目

一覧や承認の設定で足りる部分と、外部連携が必要な部分をアプリごとに見極めます。CSVで更新するデータ、添付、コメント、履歴の違いも点検。プラグイン、個別開発、移行を比べる記入表付き。

影山湧亮 / NeoLogic株式会社代表取締役。元警視庁。現場業務の整理と生成AI活用・Webシステム開発を一貫して担当。

kintoneの標準機能で足りるかは、現行アプリと処理を整理し、標準設定、拡張、外部連携の順に必要性を見て判断します。移行は、データだけでなく承認や引継ぎの運用を持ち出せる条件から決めます。

たとえば、申請の承認待ちが埋もれる。受注票はプラグインがないと作れない。別システムへ移そうとCSVを開くと、受注1件が複数行に分かれている。同じ「kintoneでは足りない」という相談でも、直す場所は異なります。

プラグインの数だけで全面移行を決める必要はありません。

四つの方法は組み合わせられます。「承認は標準、帳票は拡張、顧客情報は連携」という併用も比較します。購買申請・受注票発行・受注明細管理の3アプリで考えてみます（想定例）。

受注一件が二行になっても、受注を二件にしない

受注明細管理を移すときは、CSVの行数と受注件数を分けます。たとえば受注O-101に明細01・02、O-102に明細01があるなら、受注は二件、明細は三件です。金額の合計だけでなく、「どの受注にどの明細が属するか」を照合します。

持ち出した内容	移行先で確かめること
O-101／01、O-101／02、O-102／01	二つの受注と三つの明細。明細番号だけで重複判定しない
同じファイルをもう一度取り込む	受注も明細も増えず、訂正する場合の扱いが分かる
O-101の明細02だけ数量を訂正	O-102は変わらず、訂正前後と再承認の要否が追える
添付と承認待ちの状態も持ち出す	添付を開け、次に処理する人が分かる。CSVの取得だけで完了にしない

これは特定の移行ツールで確認した結果ではなく、引き継ぎ時の確認例です。CSVで空欄になる項目が、前の行からの引き継ぎなのか、本当に未入力なのかも、実際の出力仕様で確かめます。

承認待ちの困り事は、移行前にステータス・作業者・アクションの設定と照合します（2026年10月26日確認）。「承認ボタンがある」だけでなく、代理者不在、差戻し、承認後の訂正を一件ずつ通し、標準設定で直せる部分を先に切り分けます。

現在のアプリと業務を整理する

アプリ名だけでなく、アプリID、扱う項目、入力する人、確定する人、次の仕事へ渡す条件をそろえます。「使いにくい」は、「申請後に誰の承認で止まっているか分からない」のように、入力から承認までの場面へ書き換えます。

購買申請では、申請者が用途・希望日・承認者を入力し、購買責任者が承認待ちを見ます。受注票発行では、受注担当が受注番号・顧客コード・帳票様式を扱います。受注明細管理では、受注番号と明細番号を組にして引き継ぎます。担当者と結果は、配布Excelの「確認記録」にアプリIDで対応付けます。

まず、困っているアプリから試す案を選びます。

表1　3アプリで先に試す案と、判断が変わる条件

困っているアプリ	まず試すこと	判断が変わる条件
購買申請（101）	標準の承認設定と承認待ち一覧	差し戻し・承認者不在・権限も含め、必要な運用を満たすか
受注票発行（202）	帳票拡張を比べ、顧客情報は販売管理から渡す	帳票の不足と二重入力を、それぞれ解消できるか
受注明細管理（303）	明細の別アプリ化と段階移行を比較	明細別に担当でき、添付や履歴・未完了処理も引き継げるか

管理元・取り出す情報・移行前の確認を含む全項目は、比較表と確認票（Excel）に記入できます。印刷用PDFもあります。分からない項目は「未確認」とし、アプリIDで担当者と確認結果を結び付けてください。

標準の承認や一覧で解決する

kintoneのプロセス管理は、処理状況を表す「ステータス」、その段階の担当を表す「作業者」、状態を進める操作の「アクション」で構成されます。フィールドの値に応じて、実行できるアクションを分けることもできます（出典：kintoneヘルプ「ステータス、作業者、アクションとは」、2026年9月15日時点）。

購買申請では「作成中→承認待ち→承認済み」を基本とし、差し戻しは作成中へ戻す案を置きます。申請者が申請し、指定された承認者が承認または差し戻しを行う設計です。誰がどの操作で「承認済み」を確定するかまで設定案に含めます。

一覧では、表示項目、抽出条件、表示順を設定できます。購買申請なら承認待ちのレコードを希望日順に並べ、担当者が見るべき列だけを残す案を試します。一覧は作業を見つけるために使います。閲覧・編集の権限も合わせて見ます（出典：kintoneヘルプ「一覧を追加する」、2026年9月15日時点）。

標準で足りると判断する条件は、通常の申請だけでなく、差し戻し後の再申請、承認者不在時の扱い、権限の異なる利用者からの見え方まで、社内の運用に合うことです。業務責任者が期待する結果を決め、管理者が検証用アプリで試します。代理承認などの要件が決まっていなければ、標準で可能とも不可能とも先に決めません。

プラグインと個別開発を比べる

拡張へ進むのは、標準設定で解消できない不足が残った部分です。受注票発行では、未発行の受注を見つけることと、取引先指定の帳票を出すことを分けます。前者は一覧の設定を検討し、後者だけを既存プラグインの継続・置換・個別開発の比較対象にします。FileMakerで作った仕組みを続けるか移すかを決める場合も、同じく足りない部分だけを比べます（FileMakerの継続・WebDirect・Web移行の選び方）。

契約コースも先に調べます。日本向けの公開料金表では、外部連携やプラグインなどの拡張はスタンダード／ワイドコースの対象です。JavaScript・CSSによるアプリのカスタマイズはライトコースでは使えず、PC用とスマートフォン用で分けて設定します（出典：サイボウズ「料金」／kintoneヘルプ「JavaScriptやCSSでアプリをカスタマイズする」、2026年9月15日時点）。

プラグインと個別開発は、同じ帳票・利用端末・利用期間で比べます。プラグイン側は提供元の対応範囲、更新方針、問い合わせ先、解約後に残るデータを調べます。個別開発側はソースコードと仕様書の引渡し、修正担当、製品更新に合わせた試験範囲、担当交代時の引継ぎを聞きます。初期費用だけでなく、利用料、変更費、試験と保守、終了時の回収作業を含めた比較案にします。

競合を調べるときは、同じ保存操作や同じフィールドを複数の拡張が扱っていないかを調べます。検証用アプリで単独利用と併用を比べ、帳票の改ページ、明細追加、取消後の再発行を確かめる設計です。導入数が多いだけで不具合があるとは断定せず、一つでも止まると業務が止まる依存を見ます。プラグインのバージョンと追加先は管理画面で確認できますが、見える情報は管理権限によって異なります（出典：kintoneヘルプ「プラグインの利用状況を確認する」、2026年9月15日時点）。

受注票発行で既存プラグインが必要な帳票と保守条件を満たすなら、継続が候補です。反対に、必須の例外に対応できず、修正と試験の担当を確保できるなら個別開発を比較します。どちらも「追加すれば解決」とせず、残った不足と合格条件を記録します。

外部連携の必要箇所を絞る

二重入力が問題なら、画面を作り直す前に、どの情報をどちらで確定するかを決めます。受注票発行の想定例では、顧客名・請求先住所は販売管理で確定し、顧客コードで照合してkintoneへ渡します。受注内容はkintone側で管理します。顧客情報まで両側で自由に変更する設計にはせず、修正は販売管理へ戻す運用案です。

連携メモには「項目、正しい情報を管理する場所、更新方向、照合する項目、実行時点、失敗時の担当」を残します。この例では「販売管理→受注票発行、顧客コードで照合、帳票発行前に反映を見る、失敗時は受注担当が発行保留」と記入します。リアルタイム化を前提にせず、仕事の締切に間に合うCSV受渡し、既製連携、APIによる処理を比べます。

APIはシステム同士で情報をやり取りする窓口です。同期する処理を決めたら、認証情報と必要な権限、契約上の利用条件、回数制限を調べます。再送しても同じ受注が二重登録されないこと、取消や顧客統合、反映漏れを検知できることを試験条件にします。送信できたことと、相手側に正しく反映されたことを分けて照合します。

標準連携に合わない明細照合や、失敗した処理の再実行待ちの管理まで具体化した場合は、ツール・API連携の開発と二重入力の解消の案内が次の相談先になります。相談時には受注票発行の比較表と、連携対象の項目・更新方向を渡すと、必要な範囲を絞れます。

移行する場合のデータを調べる

テーブルを含むCSVは、単純な一行一件ではありません

受注明細管理は、受注明細を別々に担当へ割り当てたいアプリとします。標準の別アプリ化では必要な運用を満たせない場合に、移行先での明細別管理を比較します。テーブルがあること自体は移行の理由ではなく、必要な処理と取り出しの条件が判断材料です。

テーブルを含むCSVでは、「レコードの開始行」列の星印から次の星印の直前までが1レコードです。テーブルの明細は複数行になります。架空例の受注O-001に明細2行、O-002に明細1行がある場合、ヘッダーを除くデータは3行でも、親レコードは2件です（出典：kintoneヘルプ「出力されたファイルに関する補足事項」、2026年9月22日時点）。

表2　受注明細管理から書き出したCSVの読解例（テーブル1つ）

レコードの開始行	受注番号	明細番号	商品コード	数量（個）
*	O-001	L-01	P-01	2
	O-001	L-02	P-02	1
*	O-002	L-01	P-03	4

受注番号はテーブル外、明細番号・商品コード・数量はテーブル内にある想定です。星印のある1行目と3行目が開始行で、間の2行目はO-001の続きです。書き出したCSVでは、継続行にも受注番号などテーブル外の値が入ります。受注番号の種類は2件、明細の行数は3件と数えます。移行先では親2件と明細3行を別々に照合し、明細は受注番号と明細番号の組でひも付けます。Excelの件数計算に加え、添付や未完了の処理も確認します。

移行・更新を担当する人へ：kintoneへCSVを書き戻す条件

読み込み用に作るファイルでは、継続行のテーブル外の項目を空欄にする形式もあります。書き出し結果の見本と区別し、下記の公式手順で準備してください。

元アプリへCSVで上書きする場合は、変更しない列も含め、対象テーブル内の全フィールドを指定する必要があります。再計算・再取得されるフィールドは例外です。更新キーと照合先を決め、変更分だけの行や列を渡してよいと考えないでください。また、添付フィールドを含むテーブルはファイルから一括更新できません。ルックアップの関連先を閲覧できない場合にも制限があります。これはkintone側の更新条件であり、移行先の取込仕様とは別です（出典：kintoneヘルプ「［テーブル］を含むレコードを登録・上書きするためのファイルを準備する」／kintoneヘルプ「［テーブル］に設定したフィールドで、使えない機能や操作できないことはありますか？」、2026年9月15日時点）。

添付・コメント・履歴は、取り出しと再現を分ける

添付ファイルと変更履歴は標準CSVには含まれません。コメントは別CSVに出せますが、kintoneへそのまま再入力することはできません。数値や文字の一覧を取り出せても、過去のやり取りや未完了の承認まで移ったとは判断できません。

移行担当者へ：添付・コメント・履歴・状態の取り出し条件

通常項目とテーブルのCSVを回収しても、それだけで移行は完了しません。添付ファイルは標準CSVの対象外です。個別に保存する方法、またはAPIでファイルの実体を取得する方法を検討し、アプリID・旧レコード番号とファイル名・保存先を対応付けます。APIでは取得対象に応じた閲覧権限も必要です（出典：kintoneヘルプ「kintoneにアップロードした添付ファイルを一括でダウンロードすることは可能ですか？」／cybozu developer network「ファイルをダウンロードする」、2026年9月15日時点）。

コメントは現行仕様では、コメント機能が有効なアプリで出力オプションを選ぶと、レコードとは別のCSVに書き出せます。ただし、書き出したコメントCSVをkintoneに再読込することはできません。移行先で投稿者、投稿時点、元レコードとの対応をどこまで保持するかを別に決めます（出典：kintoneヘルプ「レコードのデータをファイルに書き出す際の注意事項」、2026年9月15日時点）。

変更履歴は標準CSVでは出力できません。必要な期間と照会目的を決め、契約・権限を確保した旧環境での参照継続、必要箇所の記録、別の取得手段の可否を検討します。全履歴を再現できる根拠がない段階では「未確認」とします。ステータスと作業者は出力できてもCSVから再入力できないため、承認ルートの設定と、移行時に未完了の申請を誰が引き受けるかも別に設計します（出典：kintoneヘルプ「入出力できるデータの一覧」、2026年9月15日時点）。

受注明細管理の移行を確定するには、親・明細の件数一致に加え、添付の開封、コメントの対応、欠落履歴の扱い、未完了処理の担当まで業務責任者が見届けます。最後に更新を止める範囲、差分を回収する時点、切替失敗時に戻す条件を決めます。保存が必要な情報の回収や参照方法が決まる前に、旧アプリの削除や契約終了を進めないようにします。