Excelをやめるかどうかを決めるとき、社内から出てくる声は、だいたいこの3つに集まります。
「まだ使えてはいるんです。ただ、誰が最新版を持っているのか分からなくなってきました」
「行数の上限が来たら移そうと思っていました。でも、まだ全然そこまでいっていないんですよね」
「移すとしても、どこに移せばいいのかが分かりません。比べ方が分からないので動けないままです」
結論を先に言います
脱Excelの移行先は、行数の上限ではなく「権限をあとから分けられるか」と「同時に何人が触れるか」の2つで決まります。行数の上限に実務で到達する会社はほとんどなく、先に壊れるのは権限と同時編集だからです。
そして、ここがあまり書かれていないところなのですが、移した先にも上限があります。知らずに移すと、Excelで困っていたことが形を変えて戻ってきます。だから比べるべきなのは機能一覧ではなく、各製品が公式に出している上限のほうかなと思います。
この記事で持ち帰れること
- Excelの公式上限のうち、実務で先に当たるのはどれか
- 移行先の候補を、公式仕様の上限で横に並べて比べる方法
- 「あとで部署ごとに権限を分ける」が、できなくなる境目
- 自動化を乗せるときに、先に確認しておく時間の上限
- 上限を超えたことが誰に届くのか、という運用側の設計
- 移行＝新しいツールを買うこと、とは限らないという話
先に当たる上限は、行数ではない
Microsoftの「Excel specifications and limits」（https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3）には、1つのワークシートの上限が 1,048,576 rows by 16,384 columns と書かれています。セル1つに入る文字数は 32,767 characters、数式の長さは 8,192 characters、数値の精度は 15 digits、1シート内のハイパーリンクは 65,530 です。
正直なところ、このうち中小企業の実務で当たる数字はほとんどありません。100万行を使い切る前に、別のところが先に動かなくなります。
同じページの「共有ブック（Share Workbook）」の項目には、Users who can open the file at the same time が 256 と書かれています。これは共有ブック機能を使ったときの、同時にファイルを開けるユーザー数の上限です。あとは、開いているブックの数やウィンドウの数は Limited by available memory とされていて、固定の数字が決まっていません。つまり環境次第で変わる、ということが公式に書かれているわけです。
ただ、実際にご相談をいただく会社がぶつかっているのは、256人ですらありません。「誰が最新版を持っているか分からない」という、上限表のどこにも載っていない崩れ方です。ファイルが2つに分かれ、片方だけ更新され、月末にどちらが正しいのか誰も言えなくなる。この状態は上限表を眺めていても判断できないので、移行の決め手になりません。Excelの壊れ方そのものは原価管理のExcelが崩れる本当の理由で4つの型に整理しているので、そちらも合わせて見ていただければと思います。
移した先にも上限がある。公式仕様で比べる
ここが本題かなと思います。移行先の候補にも、公式に書かれた上限があります。
Microsoft Learnの「SharePoint limits」（https://learn.microsoft.com/en-us/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits）には、A list can have up to 30 million items and a library can have up to 30 million files and folders. と書かれています。3,000万件です。容量だけ見れば、まず困りません。
問題はその次の一文です。
When a list, library, or folder contains more than 100,000 items, you can't break permissions inheritance on the list, library, or folder. You also can't reinherit permissions on it.
アイテムが100,000件を超えると、そのリスト・ライブラリ・フォルダでは権限の継承を切れなくなり、継承し直すこともできなくなると書かれています。ただし、同じ段落には続きがあります。However, you can still break inheritance on the individual items within that list, library, or folder, up to the maximum number of unique permissions in the list or library とあり、そのリスト内の個別アイテム単位であれば、個別権限の上限の範囲内で継承を切ることは引き続きできます。
つまり、できなくなるのは「リストやフォルダというまとまりごと、まとめて権限を分ける」というやり方のほうです。実務に置き換えると、「とりあえず全社で1つのリストに入れておいて、あとから部署ごとにまとめて切り分ける」という進め方が取りにくくなる、ということになります。アイテムを1件ずつ設定していく道は残りますが、件数が多い業務でそれを運用で回すのは現実的ではないかなと思います。ここが実際の分かれ目になります。
同じページには、個別権限についても The supported limit of unique permissions for items in a list or library is 50,000. However, the recommended general limit is 5,000. とあります。サポートされる上限は50,000でも、推奨は5,000です。この2つの数字の差は、設計のときに見落としやすいところかなと思います。
あとは、同じページから拾えるものとして、リストアイテムへの添付ファイルは 250 MB、バージョンは 50,000 major versions and 511 minor versions、1つのサイトコレクションに置けるリストとライブラリは合わせて 2,000、同期は no more than 300,000 files が推奨、復号後のフォルダパスとファイル名の合計は 400 characters を超えられない、と書かれています。
| 確認する軸 | Excel（公式仕様ページの記載） | SharePoint / Microsoft Lists（公式仕様ページの記載） |
|---|---|---|
| 件数の上限 | 1シート 1,048,576行 × 16,384列 | 1リスト 3,000万アイテム / 1ライブラリ 3,000万ファイル・フォルダ |
| 権限をあとから分けられるか | — | リスト・ライブラリ・フォルダ単位では、100,000アイテムを超えると継承を切れず、戻せもしない（個別アイテム単位なら上限の範囲内で可能） |
| 個別権限の目安 | — | サポート上限 50,000 / 推奨 5,000 |
| 人数に関する上限 | 共有ブックで「同時にファイルを開けるユーザー数」が 256 | 「1サイトコレクションあたりの利用者数」が 2,000,000 |
| 履歴の持ち方 | — | 50,000 メジャーバージョン / 511 マイナーバージョン |
| 添付・ファイルの上限 | 1セルに入る文字数 32,767 / 数式の長さ 8,192 / 数値精度 15桁 | リストアイテムへの添付 250 MB / アップロード 250 GB |
この表の作り方そのものが、今回いちばんお伝えしたいことです。機能の有無ではなく、「あとから変えられなくなるのはどこか」で並べる。そうすると、移行先を選ぶ基準が「今できること」ではなく「将来できなくなること」に変わります。
自動化と「動く場所」の上限から逆算する
Excelから移すとき、だいたい同時に「この作業も自動化したい」という話になります。ここにも上限があります。
Microsoft Learnの「Power Apps system requirements and limits」（https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/limits-and-config）には、Request limits として These limits apply to each single outgoing request と前置きしたうえで、Timeout 180 seconds と Retry attempts 4 が示されています。ただし同じページに The retry value might vary. For certain error conditions, retrying isn't necessary. という注記もあるので、リトライ回数は固定だと思わないほうがいいかなと思います。
この180秒は「1回の外向きリクエストごと」の上限です。「夜間に一気に流す」という設計は、この上限から先に決める必要があります。1件ずつ回せば足りても、まとめて投げると切れる。自動化の実行時間の上限という論点は、Google Apps Scriptで業務システムを作る限界でも同じ構造で書いています。
もう1つ、見落としやすいのが「どこで動かすか」です。同じページには Power Apps doesn't support the nested embedding of canvas apps in native desktop, mobile, or other non-browser clients. とあります。つまりSharePointのページに埋め込んだcanvasアプリは、ブラウザ以外のクライアントでは入れ子の埋め込みがサポートされないということです。モデル駆動アプリについても Power Apps doesn't support embedding a model-driven app or page within an IFrame in another application. と書かれています。
ネットワーク側も書かれています。Power Apps doesn't support running with a proxy enabled. This limitation can cause unpredictable behavior. とあり、ZscalerやBlue Coatはリクエストのヘッダーを落とすと具体名で挙げられています。さらにブラウザのローカルネットワークアクセス制限については、Microsoft Support can't resolve these networking problems. と明記されています。公式がここまで書くのは珍しいので、プロキシのある社内環境では検証を先に通しておくべきだと思います。
「使える」と「自社の環境で使える」は別です。ここを確認しないまま進めると、作ったあとで動かないことが分かります。
上限を超えたことが、誰に届くか
上限は、超えたときに気づける形になっていないと意味がありません。
cybozu developer networkの「kintone APIリクエスト数の超過メールが届いたら？」（https://cybozu.dev/ja/kintone/tips/best-practices/performance/kintone-api-request-limit-exceeded-guide/）には、kintoneで1日に実行できる1アプリあたりのAPIリクエスト数に上限が設定されていること、そして上限を超過すると「サイボウズドットコムストアの管理者メールアドレス宛に超過メールが送信されます」と書かれています。
さらに、「上限回数を超えたAPIリクエスト実行が他のユーザーの環境に重大な影響を及ぼす場合、API処理を中断することもあります」とあります。止まる可能性があることが、公式に書かれているわけです。
ここで確認しておきたいのは数字ではなく、通知の宛先がストアの管理者メールアドレスであるという点です。その宛先を日常的に見ている人がいなければ、通知は届いていても誰にも読まれません。移行の設計では、上限そのものより「超えたことが誰に届くか」を先に決めるべきだと思います。
部署別・業種別の使いどころ
同じ「脱Excel」でも、どこから手を付けるかで難易度がまったく変わります。弊社がご相談を受けるときに見ている順番を、部署と業種で整理しておきます。
| 部署・業種 | Excelが先に崩れるところ | 移行先を選ぶときに最優先で見る上限 |
|---|---|---|
| 経理・財務 | 月次の締めで複数人が同じ表を触る | 同時編集と履歴。誰がいつ直したかが残るか |
| 総務・人事 | 部署ごとに見せたい範囲が違う | 権限の継承。100,000アイテムの境目に当たらない設計にできるか |
| 営業 | 外出先からスマホで見たい・入れたい | ブラウザ以外のクライアントで動くか |
| 製造・倉庫（複数拠点） | 拠点ごとに別ファイルができて集計できない | 入力形式を1つに固定できるか。拠点ごとの権限分け |
| 建設・工事 | 案件ごとにファイルが増え、添付が重い | 添付の上限とパス長の上限 |
| 店舗・サービス | シフトと在庫が別の表に散る | 入力の場所を1か所に減らせるか |
実際の案件でも、ここが効いています。複数拠点の在庫をkintoneで一元管理した案件では、拠点ごとに別ファイルができて集計できない状態を、7つのアプリに分けた構成で「誰が入力しても同じ形式になる」ようにしました。結果として担当者が交代しても運用が続く状態になっています。詳しくはkintoneによる在庫管理の制作事例に書いています。
あとは、足すのではなく減らす選択もあります。あるkintone運用案件では、外部サービス（トヨクモのFormBridge・kViewer・DataCollect）に月9万円かかっていたのを、自社開発のシステムに置き換えて廃止し、年間約108万円を削減しました。新しいソフトを入れた結果ではなく、入力する場所を1か所に減らした結果です。ほかの制作事例も合わせて見ていただけるとイメージしやすいかなと思います。
CodeClimbの見解
ここまでは各社の公式仕様に書かれていることを並べました。ここからは弊社の解釈と経験で、出典のある事実とは分けて書きます。
「Excelはもう使うな」とは思っていません。上の数字を自分で並べておいて言うのですが、行数の上限に実務で到達しないのであれば、そこから「使うな」は導けないかなと思います。弊社でも集計や試算では今も使っています。問題はExcelそのものではなく、複数人が同時に触る業務をExcelに載せ続けていることのほうだと考えています。
判断の順番としては、「権限をあとから分けられるか」を最初に置くのが実務的だと思います。件数は増えてから足せますが、権限の設計は後戻りが効きにくいからです。SharePointの100,000アイテムの話は、まさにその後戻りが効かなくなる例として分かりやすいかなと思います。
自動化の上限は、製品が変わっても構造が同じです。弊社がよく使うGoogle Apps Scriptにも1回の実行時間の上限があり、アカウントの種類によって6分と30分の違いがあります。Power Appsの180秒も同じ構造の話で、「1回で何秒まで動けるか」から処理の分け方を決めるのが結局いちばん手戻りが少ないと感じています。
通知については、自社で痛い経験をしています。弊社の夜間の定期ジョブが、成功した晩を「失敗」と記録し、逆に起動しなかった晩は異常の一覧にそもそも載らない、という状態になっていました。通知の送信行が失敗を捨てる書き方になっていた時期もあります。怖いのは失敗そのものではなく、失敗が届かないことだと思います。kintoneの超過メールの宛先を確認しておくべきだとお伝えしているのは、自分たちがここで転んだからです。
効果は「時間」で出ることが多いです。弊社自身、見積書と請求書づくりは1件15分かかっていたものが、今は1分もかかりません。やったことは高度な自動化ではなく、入力する場所を1か所にして、そこから先を機械に任せただけです。脱Excelの効果も、だいたいこの形で出てくるかなと思っています。
比較表の人数の行についても、ひとこと補足しておきます。Excel側の256は「同時にファイルを開けるユーザー数」として書かれている数字で、SharePoint側の2,000,000は「1サイトコレクションあたりの利用者数」として書かれている数字です。同じ「人数」でも数えているものが違うので、この2つを並べて大小を比べることには意味がないと考えています。表に並べたのは、人数という軸で各社が何を上限として公開しているかを見るためです。
なお、料金での比較は今回あえて入れていません。製品ごとに課金体系の考え方が違い、エディションごとの原文を突き合わせない限り、横並びの数字にすると実態とずれるためです。同じ理由で、各社の細かい制限値も、原文に到達して確認できたものだけを書いています。
よくある質問
Q. 100,000アイテムを超えてしまった既存のリストは、どうすればいいですか
公式ページには、その状態ではリスト・ライブラリ・フォルダ単位で継承を切ることも継承し直すこともできないと書かれています。一方で、同じ段落には個別アイテム単位であれば個別権限の上限の範囲内で継承を切れるとも書かれています。ただ、件数の多い業務でアイテムを1件ずつ設定していくのは運用が持たないので、現実的にはリストを分けて件数を下げる前提で設計をやり直す方向になるかなと思います。ここは「超えてから対処する」が効きにくい領域なので、移行の初期に、将来どこまで増えるかを概算しておくことをおすすめします。
Q. 社内にプロキシがあります。先に何を確認しておくべきですか
Power Appsの公式ページは、プロキシを有効にした状態での実行をサポートしないと明記し、ヘッダーが落ちる製品名まで挙げています。ブラウザ側のローカルネットワークアクセス制限についてはサポートでは解決できないとも書かれています。ですので、実際に業務で使う端末・ブラウザ・ネットワークで、小さな画面を1つ作って通してみるのが確実です。情報システムの担当者がいる場合は、ブラウザポリシーを変更できるかどうかも先に確認しておくと話が早いかなと思います。
Q. 移行先を1つに決めきれません。並行運用は避けるべきですか
弊社は、むしろ最初は並行させることが多いです。ただし並行させるのは期間を区切ったうえで、入力は新しい側だけに寄せる形にします。両方に入力できる状態を残すと、Excelのときと同じ「どちらが最新か分からない」に戻るためです。1業務だけ切り出して、入力の場所を先に1か所へ移す、という進め方が結果的にいちばん速いかなと思います。
まとめ
- Excelの公式上限は1シート1,048,576行だが、実務でそこには当たらない。先に崩れるのは同時編集と「最新版の所在」
- 共有ブックで同時にファイルを開けるのは256ユーザー。ブック数やウィンドウ数は公式に「利用可能なメモリ次第」とされている
- SharePoint / Microsoft Listsは1リスト3,000万アイテム入るが、100,000アイテムを超えるとリスト・ライブラリ・フォルダ単位では権限の継承を切れず、戻せもしない（個別アイテム単位なら上限の範囲内で可能）
- 個別権限はサポート上限50,000に対して推奨は5,000。この差を設計時に見ておく
- Power Appsは1回の外向きリクエストが180秒で切れ、リトライは4回（変動しうると注記あり）。自動化は上限から逆算する
- ブラウザ以外のクライアントでの入れ子の埋め込みは非対応。プロキシ環境は公式が「サポートでは解決できない」と書いている
- kintoneはAPIリクエスト数の上限超過時にストア管理者メールへ通知が飛び、場合によってはAPI処理が中断する。宛先を見る人を先に決める
- 移行は「新しく買う」ではなく「入力する場所を減らす」でも成立する
上限から逆算した移行先の設計を、一緒に決めませんか
CodeClimbは、ツールを売る側ではなく実際に業務システムを作る側として、Excel・紙からの脱却をご支援しています。製品を先に決めてから業務を合わせるのではなく、今の業務のどこが先に壊れているかを見て、そこから移行先と上限を決める進め方です。
「まだ移すべきか分からない」という段階からでも構いません。業務システム開発・DX支援のサービス内容をご覧いただいたうえで、お問い合わせから今の状況をお聞かせください。1業務だけ切り出して小さく始める形もご提案できます。
出典
https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3 ｜ Microsoft サポート ｜ 参照 2026-10-02
https://learn.microsoft.com/en-us/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits ｜ Microsoft Learn ｜ 2025年11月
https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/limits-and-config ｜ Microsoft Learn ｜ 2026年1月
https://cybozu.dev/ja/kintone/tips/best-practices/performance/kintone-api-request-limit-exceeded-guide/ ｜ cybozu developer network ｜ 2026年1月
