ノーコードで社内システムの認証を改善【2026年版】SSO・権限・料金

はじめに

「経費精算のパスワードを忘れました」「勤怠システムのIDが分かりません」。こうした問い合わせが続くと、管理部門の対応時間だけでなく、ログインできない従業員の業務時間も失われます。勤怠、顧客管理、案件管理などのシステムを増やすたびに、IDとパスワードの管理先が増えることが原因の一つです。

負担を減らすために全員で同じIDを使うと、今度は誰が操作したか分からなくなります。退職者の利用停止や部署異動時の権限変更が漏れれば、人事情報や会計データを本来見せるべきでない人に公開してしまう可能性もあります。ログインの手間と情報の保護は、同時に考える必要があります。

ノーコードで社内システムの認証を改善する場合は、既存のGoogleやMicrosoftのID基盤と、業務アプリ側の権限管理を組み合わせます。ログインの本人確認と、誰に何を許可するかは別の設計です。ボタンや画面を非表示にするだけでは、データへの不正なアクセスを防げません。

本記事では、ID/PW管理の隠れたコスト、既製SSOとノーコードの使い分け、認証方式の比較、料金、外注前の確認事項を整理します。製品の料金・仕様は2026年9月24日に公式情報を確認しました。専任の情報システム担当がいない企業でも、最初に何を棚卸しし、どの条件を開発会社へ伝えるべきかが分かります。

新しい仕組みへ切り替えるときは、利用者への案内も必要です。ログイン方法が変わる日、利用できない場合の連絡先、古いアカウントの扱いを決めておきます。担当者だけが設定を理解している状態を避け、日常の問い合わせに対応できる手順として残すことが、継続して使える社内システムにつながります。

ID/PW地獄と共有IDが生むコスト

ID/PWが分散すると、リセット対応、ログイン待ち、問い合わせの引き継ぎが繰り返し発生します。まず月の問い合わせ件数と平均対応時間を記録し、担当者の負担を把握します。使い回しや付箋への記録が生じていないかも確認します。

共有IDでは操作履歴が残っていても個人を特定できません。退職者が知っている共通パスワードを変更し忘れると、社外からアクセスが続く恐れもあります。個人単位のID、退職時の停止担当、異動時の権限見直しを決めることが改善の出発点です。

既製SSOとノーコードをどう選ぶか

SSOは、連携したアプリ間で認証の手間を減らす仕組みです。多数の既存SaaSを一括管理したい場合は、既製のID管理・SSO製品も候補になります。既製品が常に高額とは限らず、既存契約に必要な機能が含まれているかを先に調べます。

独自の勤怠・申請アプリを作るなら、ノーコード側に認証連携を組み込む方法があります。ただし、そのアプリを作っても既存の経費精算SaaSまで自動でSSO化されません。接続先の対応方式と契約プランを確認し、開発費に連携費・保守費も加えて比較します。

社内システム認証で決める5項目

認証基盤を決める前に、次の5項目を整理します。MFA（多要素認証）の設定に加え、利用停止後のセッションや外部委託先の利用期限も対象にします。ログインできることだけを合格条件にしないことが大切です。

項目	決める内容	確認する運用
SSO	利用するID基盤・対象アプリ・接続方式	ID基盤障害時の連絡先
MFA	必須対象・認証手段	端末紛失時の本人確認・復旧
RBAC（役割別権限）	閲覧・作成・編集・承認・削除の範囲	異動時の権限変更
ログ	記録対象・保管期間・閲覧担当	問題発生時の調査手順
退職者停止	IDとアプリの利用停止	既存セッション・共有先の確認

ノーコードで安全に実装する設計

Google・Microsoftアカウントと連携する

Google WorkspaceやMicrosoft Entra IDとの連携可否は、使用するプラグインや認証方式で確認します。Azure ADは現在のMicrosoft Entra IDです。個人用アカウントのログインと、会社が許可したユーザーだけの利用を区別します。

BubbleにはWorkOSの公式プラグインを使うSSO連携の選択肢があります。なお、Bubble開発者アカウント向けSSOと、作成したアプリの利用者向けSSOは別です。導入時には対象を取り違えないようにします。

業務に合わせた権限管理とアクセスログ

設計例として、A部署は担当案件の閲覧のみ、上長は部下の申請承認、アルバイトは本人の勤怠だけを許可します。画面の非表示だけではデータを保護できません。BubbleではPrivacy Rulesで取得範囲を制限し、更新ワークフローにも実行者と対象の認可条件を設けます。

アクセスログには時刻・利用者ID・対象レコード・操作結果を残す設計にします。IPアドレスや閲覧履歴は取得方法を個別に確認し、必要な処理へ記録を組み込みます。ログイン履歴だけで業務操作を追えるとは限りません。保存期間と削除権限も決めます。

たとえば上長の承認権限は、役職だけでなく申請者との所属関係も確認します。別部署の申請番号を指定しても承認できないようにし、本人が管理者用の属性を書き換えられないことも試験します。権限表には、許可する操作と拒否する操作の両方を記載します。

部署や取引先ごとに閲覧できる資料を分けたい場合も、同じ権限表を使って設計できます。ファイル単位の権限や承認フローの考え方は、社内ファイル共有システムの構築で解説しています。

社内システムのログイン認証を4方式で比較

認証方式はコストだけでなく、対象業務と管理体制で選びます。下表の無認証共有は運用の問題であり、Excelという製品自体が危険という意味ではありません。どの方式でも、安全性は設定と運用に左右されます。

比較軸	無認証・共有IDの運用	既製SSO・ID管理製品	フルスクラッチ	ノーコード開発
導入コスト	初期作業は少なくても管理負担が残る	ID数・接続・機能で変動	要件と実装範囲で変動	アプリ・連携・検証費が必要
導入スピード	開始しやすいが見直しが必要	対応済み接続先なら進めやすい	独自実装と検証期間が必要	既存部品が使える範囲で短縮可能
セキュリティ	本人識別・停止管理が難しい	集中管理機能を設定して利用	実装・監査・保守に依存	権限設定・連携検証に依存
SSOの利便性	共有パスワードはSSOではない	対応するアプリを連携	対応方式を実装	ID基盤・プラグイン等を連携
権限管理の柔軟性	個人別制御が難しい	接続先アプリの権限機能も確認	独自要件に合わせられる	対応機能内で業務別に設計

Firebase/Auth0/Clerk料金比較

認証サービスは、ノーコードツールとの接続可否を確かめて選びます。MAUは月間アクティブユーザー、ClerkのMRUは登録から24時間以上たって再訪したユーザーを数える指標です。人数とSSOの条件をそろえて比較する必要があります。

サービス・出典	2026年9月24日の公式表示	条件・別途確認事項
Firebase	Sparkは無料、Blazeは従量課金。Identity Platformは通常50,000 MAU、SAML/OIDCは50 MAUまで無料枠	無料枠はプロジェクト単位。SMSは別課金。超過単価・税・初期構築費・利用下限は採用構成で確認
Auth0	Freeは月0米ドル・25,000 MAUまで。B2C Essentialsは500 MAUで月払い35米ドルの表示	B2B・企業接続は別条件。税の扱い・初期導入費・最低契約条件は契約画面で確認。開発費は別
Clerk	Hobbyは無料・50,000 MRU/app。Proは年払い月額換算20米ドル、月払い25米ドル、50,000 MRU/app込み	Proは超過課金あり。税の扱い・初期導入費・最低契約条件は契約画面で確認。MFAはPro、追加接続等は別条件

無料プランの人数枠が大きくても、必要な企業向けSSOが同じ条件で使えるとは限りません。Auth0では企業接続等の有料継続にB2Bへの変更が必要な旨の注記があります。契約前に、実際の社員数と接続先を指定して見積もります。

外注前に決める範囲

公開前は一般社員・上長・外部ユーザー・停止済みユーザーで、他人のデータ取得や不正な更新が拒否されるかを検証します。APIやファイルの直接アクセスも確認します。ノーコード総合研究所へ相談する際は、社内システムの開発費用と併せ、権限表と保守範囲を整理すると要件を伝えやすくなります。

保守契約には、部署追加やMFA必須化への対応、プラグイン更新時の動作確認も含めて検討します。認証連携が停止すると業務も止まるため、障害の受付時間、調査担当、復旧までの連絡方法を合意します。設定を引き継げる資料の納品も依頼します。

まとめ

社内システムのID/PW管理を改善するには、ログインの手間、問い合わせ対応、共有ID、退職者の停止漏れを一緒に見直します。SSOを導入するだけで、アプリごとの閲覧・更新権限や操作履歴が自動的に整うわけではありません。本人確認と業務上の許可を分けて設計することが、安全性と利便性を両立する基本です。

ノーコードは、独自の勤怠や申請フローに認証を組み込みたい場合の選択肢です。一方、多数の既存SaaSをまとめたい場合には、既製のID管理製品も比較します。導入費だけでなく、接続先の契約条件、認証サービスの利用料、運用担当者の負担を含めて判断すると、必要な範囲を絞りやすくなります。

最初に、利用中のシステム、正とするID基盤、社員・外部ユーザーの人数、役割別の権限を一覧にします。次に、退職時の停止担当と実施時点、端末紛失時の復旧方法、ログの保存期間を決めます。認証基盤側を停止した後も、アプリの既存セッションで操作が続かないかを確認する手順が必要です。

開発会社との相談では、作りたいログイン画面だけでなく、部署異動、承認者変更、外部委託先の契約終了まで伝えます。公開後に誰が設定変更を行い、どこまで保守を依頼するかを合意しておけば、運用中の行き違いを減らせます。ノーコード総合研究所では、業務フローと認証・権限を合わせた社内システム開発を相談できます。まずは対象業務を一つ選び、権限表と利用停止の手順から整理してください。

費用の目安：生成AI×ノーコードで進む業務システム開発｜費用・期間・失敗回避の型を公開

群別サービス：受託開発