社内ツールをノーコード（スプレッドシート＋Apps Script・kintone）で作るか、開発するか。分かれ目になる6つの実装上の条件

この記事の結論：社内ツールをノーコード（Googleスプレッドシート＋Apps Script、kintone など）で作るか、開発するかは、機能の多さではなく「実装上の6つの条件」で決まります。①同時に書き込む人数と衝突、②件数と増え方、③自動処理の実行時間と回数の上限、④人によって見せる範囲を変える必要、⑤外部サービスとのつながり、⑥直す人と変更の記録です。6つのどれにも当たらないうちはノーコードのままがよく、当たったときも、全部を作り直す前に「データの正本をどこに置くか」を決め直して、上限に当たった部分だけを外へ出すのが手堅い進め方です。

この記事は、大阪・兵庫をはじめとする中小企業で、社内の管理表や申請の仕組みを自分たちで作ろうとしている担当者と、その相談を受ける開発者に向けた判断の記録です。数字は Google と サイボウズ の公式ドキュメント（2026年10月2日に確認）からとっています。どこかの会社の導入例をもとにした話ではありません。

ノーコードか開発かは、6つの条件のどれに当たるかで決める

分かれ目は、作りたい機能の数ではなく、ツールの外側にある条件で決まります。下の6つのどれにも当たらなければノーコードで十分で、1つでも強く当たるなら、その部分は開発を考えます。

この表は、どのノーコードの道具にも共通する見方です。以下では、スプレッドシート＋Apps Script と kintone で、それぞれどこに上限があるかを具体的に見ていきます。

① 同時に書き込む人が増えると、行のずれと上書きが起きる

同時に書き込む人が増えたときに先に困るのは、スプレッドシートを正本にしている場合です。人が手で行を足したり並べ替えたりしている表に、Apps Script も書き込むと、スクリプトが覚えていた行番号と実際の行がずれます。

Apps Script には、同じ処理が同時に走らないようにする LockService という仕組みがあります。フォームの送信を受けて表に1行足す処理なら、ロックを取ってから書き込めば、2件が同時に届いても順番に処理されます。

function appendRequest(row) {
  const lock = LockService.getScriptLock();
  // 30秒待っても取れなければ例外にして、送信した人に再送を頼む
  lock.waitLock(30000);
  try {
    const sheet = SpreadsheetApp.getActive().getSheetByName('申請');
    sheet.appendRow(row);
  } finally {
    lock.releaseLock();
  }
}

ただし、ロックが守るのはスクリプト同士の順番だけで、人が画面で直接書き換える操作は止められません。「人も書く、スクリプトも書く、しかも同じ行」という使い方になったら、①に当たったと考えます。kintone はレコードという単位で記録するので行番号のずれは起きにくく、この点ではスプレッドシートより粘れます。

② 件数が増えたときに当たる上限は、道具ごとに違う

件数の上限は、スプレッドシートでは「1ファイルのセル数」、kintone では「APIで一度に読み出せる範囲」という形で現れます。

セル数の上限は列数×行数で効くので、列の多い表ほど早く当たります。その前に、関数や条件付き書式が多いと、開くだけで重くなるのが先に来ることもあります。古い年度を別のファイルに分けて済む業務ならノーコードのままで構いませんが、「過去の分も含めて、いつでも検索・集計したい」なら②に当たります。

kintone の offset の上限は、外部から全件を読むプログラムを書くときに効きます。サイボウズの開発者向け資料では、件数が多い場合の読み出し方（カーソルを使う、レコードの番号で区切る）が案内されています。こうした読み出しを書き始めた時点で、すでに開発の領分に入っています。

③ 自動処理は、実行時間と1日の回数の枠に収まるかで決まる

Apps Script と kintone の連携は、どちらも「1回あたり」と「1日あたり」の上限を持っています。自動処理が増えてきたら、まずこの枠に収まるかを計算します。

Google は、Apps Script の割り当てがいつでも予告なく変わる可能性があると明記しています。上限ぎりぎりで組んだ処理は、ある日止まるかもしれない前提で考えます。たとえば「毎朝、前日の申込者全員に確認のメールを送る」処理は、件数が増えるとメールの受信者数の枠に当たり、送れなかった人が出ても気づきにくくなります。

判断の目安は、上限そのものではなく「止まったときに業務が止まるか」です。止まっても翌日に手で回せる集計ならノーコードのままでよく、止まると顧客に連絡が届かない処理なら、③に当たったとみなして外に出します。

④ 人によって見せる範囲を変えるなら、スプレッドシートの共有では足りない

スプレッドシートで見せる範囲を分けられるのは、基本的にファイルの単位です。保護された範囲は「編集」を止める仕組みで、ファイルを開ける人には、保護した行や列も見えています。

そのため、たとえば「営業担当は自分の顧客だけ、経理は請求の列だけを見る」という要件が出た時点で、スプレッドシート1枚では作れません。ファイルを分けて関数で連携させる手もありますが、分けたファイルの共有設定を誰かが間違えると、見えてはいけない行が見えます。

kintone は、アプリ・レコード・フィールドの単位でアクセス権を設定できます。人によって見せる範囲が違う業務は、スプレッドシートより kintone のほうが向いています。それでも、アクセス権の条件が「この顧客の担当と、その上長と、同じ案件に入っている人」のように込み入ってくると、設定の組み合わせを誰も追えなくなります。条件を言葉で1行に書けなくなったら、④に当たったと考えます。

⑤ 外部サービスからの通知を受けるなら、取りこぼしの扱いを先に決める

決済、予約、LINE などの外部サービスは、出来事が起きると、こちらのURLに通知（Webhook）を送ってきます。この通知を受ける側には、「署名を確かめる」「同じ通知が2回届いても1件として扱う」「失敗したら後でやり直す」という仕事があります。

Apps Script でも、公開したWebアプリで通知を受けること自体はできます。困るのは、受けた後の扱いです。1回6分の実行時間や同時実行の枠の中で、同じ通知の2回目を見分ける記録を持ち、失敗したものをやり直す仕組みまで作ると、ノーコードの手軽さはほとんど残りません。

外部からの通知を受ける必要が出たら、その受け口だけを開発し、受けた結果をノーコードの側に書き込む形にすると、全体を作り直さずに済みます。

⑥ 直す人が作った人以外になるなら、変更の記録を残せる形にする

ノーコードの社内ツールでいちばん長く効いてくるのは、作った人がいなくなったときに直せるかどうかです。スプレッドシートの関数や Apps Script は、誰がいつ何のために変えたかが残りにくく、「なぜこの列があるのか誰も分からない」状態になりやすい道具です。

Apps Script のコードは、Google が公開している clasp というコマンドラインの道具を使うと、手元のファイルとして書き出して Git で管理できます。変更の理由を履歴に残せるようになるので、作った人以外が直す前提なら、ノーコードのままでも最初に整えておきたい作業です。

それでも、テストを書いて動きを確かめる、本番と別の環境で試してから反映する、という手順が必要になったら、⑥に当たったと考えます。その時点で、開発のやり方で管理したほうが、結果として手間が少なくなります。

分かれ目を越えたら、まず「データの正本」をどこに置くかを決め直す

条件に当たったときに最初に決めるのは、作り直すかどうかではなく、データの正本（いちばん正しい記録）をどこに置くかです。正本の場所が決まれば、ノーコードで残す部分と開発する部分の境目が自然に決まります。

A から C への移り方で避けたいのは、正本が2か所ある期間を長く続けることです。スプレッドシートにも新しいシステムにも入力している状態は、どちらの値を信じればよいか決められなくなる原因です。B や C に移るときは、移る日を決めて、その日から前の正本は読むだけにします。

ノーコードで作るうちから、移しやすい形にしておく5つの作法

ノーコードで作るときも、次の5つを守っておくと、後で開発に移るときの手間が大きく変わります。どれも、作る手間はほとんど増えません。

1. 1件ごとに、変わらない番号を振る：行番号ではなく、申請番号や顧客番号の列を作り、一度振ったら変えない
2. 1行に1件だけを書く：1つのセルに複数の値を改行で入れない。明細が複数あるなら別のシートに分ける
3. 日付と時刻は決まった形で入れる：「10/3」「10月3日」を混ぜず、日付の型で入力する
4. 選択肢は一覧から選ばせる：入力規則やドロップダウンで、表記の揺れを最初から防ぐ
5. スクリプトと関数の役割を書き残す：シートの先頭に、どの列を誰が入力し、どの列を何が書き込むかを書く

1〜4 が守られていれば、データを移すときの作業は項目の対応づけが中心になります。守られていない表を移すときの整え方は、スプレッドシートの表を新しいシステムに移す記事に書きました。

判断に迷ったときは、条件を1つずつ書き出して確かめる

判断の手順は、今の使い方を6つの条件に当てて、当たったものだけを書き出すことです。迷ったときは、次の順に確かめます。

1. その道具を毎日使う人と、同時に書き込む人の人数を書く（①）
2. 今の件数と、1年で増える件数の見込みを書く（②）
3. 自動で動いている処理を一覧にし、止まったときに困る処理に印を付ける（③）
4. 見せてはいけない人がいるデータがあるかを書く（④）
5. 外部のサービスから届く通知や、外部へ送るデータを書く（⑤）
6. 作った人がいなくなったときに、誰が直すかを書く（⑥）

当たった条件が1つなら、その部分だけを外に出す形で十分なことが多く、3つ以上当たるなら、正本を開発したシステムに移す C の形を検討します。

株式会社bundlyzeでは、社内で使う業務システムの要件を決める段階から、稼働したあとの保守運用までを受け持っています。ノーコードで続ける部分と開発する部分の線をどこで引くかを一緒に整理するときの進め方は、業務システム開発のサービスの案内にまとめてあります。

出典（公式の資料／2026年10月2日に確認）

• Google Apps Script「Google サービスの割り当て」：1回の実行時間6分、トリガーの合計実行時間、メールの受信者数、同時実行数。割り当ては予告なく変わる可能性がある点
• Google Apps Script「Lock Service」：コードの一部が同時に実行されるのを防ぐ仕組み
• Google ドライブ ヘルプ「Google ドライブに保管可能なファイル」：スプレッドシートは1,000万セル、または18,278列（列 ZZZ）まで
• cybozu developer network「kintone REST APIの共通仕様」：1日のリクエスト数、同時リクエスト数、一度に扱えるレコード数、offset の上限
• kintone ヘルプ「一覧にアクセス権を設定できますか？」：一覧ではなく、レコードとフィールドのアクセス権で見える範囲を絞る点
• cybozu developer network「offsetの制限値を考慮したkintoneのレコード一括取得について」：件数が多いときの読み出し方
• clasp（Google が公開している Apps Script のコマンドラインの道具）：Apps Script のコードを手元に書き出して管理する