「個人開発のSaaSで、認証ってどうやって実装するの？」
「ログイン機能は自分で作らないほうがいいって本当？」
個人開発のSaaSでは、認証が最初の大きな壁になります。
作りたい機能はもう頭の中にあるのに、ログイン画面とパスワード再発行で1週間溶ける、というのはよくある話ですよね。
先に結論をお伝えすると、2026年時点の個人開発ならClerk・Supabase Auth・Auth.js（NextAuth v5）の3つから選べば十分です。
この記事では3つの違いを判断できる形で比べたうえで、それぞれの実装手順と、あとから効いてくる落とし穴までまとめました。
この記事でわかること
- 個人開発のSaaSで認証を自作すべきでない理由
- Clerk・Supabase Auth・Auth.jsの違いと選び方
- それぞれで認証を実装する手順とコード
- 実装後につまずきやすい落とし穴と対策
個人開発のSaaSで認証を自作してはいけない理由
認証は「メールアドレスとパスワードを照合するだけ」に見えて、実際に必要な部品はかなり多いです。
ここでは、個人開発のSaaSで認証の自作をおすすめしない3つの理由を整理します。
認証を自作すると重くなる部分
- パスワードの保管とセッション管理は失敗が致命傷になる
- ソーシャルログインと2段階認証まで面倒を見ることになる
- 本来つくりたかった機能に時間が回らなくなる
【理由1】パスワード保管とセッション管理は事故ると取り返しがつかない
パスワードを預かるということは、漏れたときに他社のサービスまで巻き込む可能性を抱えるということ。
ハッシュ化のアルゴリズム選定、ソルトの付け方、総当たり攻撃への回数制限と、判断すべき点がずらりと並びます。
しかもこのあたりは正解が時代とともに動くので、一度書いて終わりにはできません。
セッション管理も同じで、Cookieに何を入れるか、有効期限をどう切るか、CSRF対策をどこに挟むかを全部自分で決めることになります。
厄介なのは、間違っていても普通に動いてしまうところなんですよね。
ログインはできてしまうのでテストは通り、問題が表に出るのは誰かに突かれたときだけ。
自作したパスワード認証で見落としやすい部分
- ハッシュ関数とコストパラメータが現在の推奨から古びていないか
- ログイン試行の回数制限とロックアウトの解除手段
- セッションの有効期限とログアウト時の失効処理
個人開発だと、こうした穴に気づくための監視も自分で用意しなければいけません。
ここが一番キツいところだと思っています。
「動いているから大丈夫」が通用しないのが、認証という領域の怖さですね。
【理由2】ソーシャルログインと2段階認証まで自分で面倒を見ることになる
メールとパスワードだけで済めばまだマシなのですが、実際にはそうなりません。
SaaSを公開すると、かなりの割合の人が「Googleでログイン」を探しにいきます。
用意していないと、それだけで登録をやめる人が出てしまうんですよね。
とはいえOAuthを自分で組むと、認可コードの受け取り・stateパラメータの検証・トークンの保管と更新まで一式が必要になり、プロバイダーが増えるたびにこの一式も増えていきます。
さらに法人向けに売ろうとすると、2段階認証を求められる場面が出てきますよね。
2段階認証を自作すると必要になる部品
- TOTPの秘密鍵の生成とQRコードの表示
- リカバリーコードの発行と使い捨て管理
- 端末を失くした人のための本人確認と解除手段
ここまで来ると、もはや本業がSaaSではなく認証基盤の開発になってしまいます。
認証サービスを使えば、この範囲はダッシュボードのトグルを切り替えるだけで終わりです。
削れる作業としては、かなり大きいと思いませんか。
【理由3】本来つくりたかった機能に時間が回らなくなる
個人開発でいちばん貴重なのは、平日の夜と週末しかない自分の時間ですよね。
認証を自作すると、ログイン・登録・パスワード再発行・メール認証・退会と、画面だけで5つは増えます。
そのどれも、あなたのSaaSの価値には直結しません。
訪れた人が「便利だ」と感じるのは、認証の先にある機能のほうだからです。
学習目的で一度書いてみるのは、すごく良い経験になると思います。
それと、お金をもらうSaaSに載せるかどうかは別の話として考えてみてください。
自作を選ぶ前に確認したいこと
- 認証まわりに使う時間を、そのぶん機能開発から削っていいか
- 脆弱性の報告を受けたとき、自分で直して再発防止まで書けるか
- ユーザーが増えたあとも、その状態を維持し続けられるか
3つとも「はい」と言えるなら自作でも構いません。
ただ、私の周りで自作を選んで幸せになった個人開発者は、正直ほとんど見ていないです。
個人開発のSaaS認証で使える3つの選択肢を比較する
2026年の個人開発で現実的な選択肢は、Clerk・Supabase Auth・Auth.js（NextAuth v5）の3つです。
無料枠・実装のラクさ・データの持ち方という3つの軸で違いを見ていきましょう。
個人開発で選ばれている認証の選択肢
- Clerkは画面ごと用意されていて最短で動く
- Supabase Authはデータベースの権限管理と一体になる
- Auth.jsは自分のデータベースに閉じたまま無料で使える
| サービス | 無料枠 | 実装の重さ | ユーザー情報の置き場所 |
|---|---|---|---|
| Clerk | 月間5万ユーザーまで無料 | 最軽量（画面が付属） | Clerk側 |
| Supabase Auth | 月間5万ユーザーまで無料 | 中くらい（画面は自作） | 自分のPostgres内 |
| Auth.js（NextAuth v5） | ライブラリ自体が無料 | 重め（設定と画面を自作） | 自分で用意したDB |
3つを実際に動かしてみると、ログインが成立するまでに自分で書くコード量にもはっきり差が出ます。
Clerkはコンポーネントを置くだけなので数十行、Supabase Authはクライアントの初期化とmiddlewareを合わせて100行前後といったところ。
Auth.jsは設定ファイルに加えてログイン画面まで自作するので、150行を超えることも珍しくありません。
効いてくるのは初回の差より、そのあとです。
2段階認証を足す、退会導線を作る、といった追加のたびに、自作範囲の広いほうが毎回作業を抱えることになります。
Clerkは画面ごと用意されていて最短で動く
Clerkは、ログイン画面・登録画面・プロフィール編集画面までコンポーネントとして提供される認証サービスです。
やることは、鍵を環境変数に入れて、アプリ全体を専用のプロバイダーで包み、ボタンを1つ置くだけ。
デザインもそこそこ整っているので、暫定のUIを自分で書く必要がありません。
無料プランは月間5万ユーザーまで使えるため、個人開発の規模なら当面は無料枠に収まると考えて大丈夫です。
ただし無料プランではClerkのブランド表記を外せません。
表記を消したい場合や、ユーザーが5万人を超えた場合はProプラン（月額25ドル・年払いなら月20ドル）に上がります。
Clerkを選ぶと自作しなくて済む画面
- ログイン・新規登録・メールアドレスの確認
- パスワード再発行と変更
- プロフィール編集と2段階認証の設定
弱点は、ユーザー情報がClerk側に置かれることですね。
自分のデータベースにユーザー一覧がないので、集計や検索をしたいならWebhookで同期する仕組みを別に作ります。
逆に言えば、そこさえ許容できるなら最短距離の選択肢です。
Supabase Authはデータベースの権限管理と一体になる
Supabase Authは、PostgreSQLをまるごと提供するSupabaseに最初から含まれている認証機能です。
登録したユーザーは自分のプロジェクトのauth.usersテーブルに入るので、他のテーブルと普通に結合できます。
ここがClerkとの一番大きな違いですね。
そしてPostgreSQLのRLS（行レベルセキュリティ）と組み合わせると、「自分の行だけ読める」という制御をデータベース側に書けます。
アプリのコードで条件分岐を書き忘れても、データベースが止めてくれる状態になるわけです。
Supabase Authを選ぶと得られること
- ユーザーと業務データを同じSQLで結合できる
- RLSでアクセス制御をデータベース側に寄せられる
- 認証・DB・ストレージが同じ無料枠に収まる
無料枠は月間5万ユーザーまで。
認証だけでなくデータベースとストレージも同じ枠に含まれるので、コスト面はかなり有利になります。
Supabase自体の始め方はSupabaseの使い方｜個人開発の始め方と料金・費用の目安で解説しています。
Firebaseと迷っている場合は、SupabaseとFirebaseの違いとは？個人開発での選び方に判断材料をまとめました。
Auth.js（NextAuth v5）は自分のDBに閉じたまま無料で使える
Auth.jsは、NextAuth.jsが名前を変えたオープンソースの認証ライブラリです。
外部サービスではなくライブラリなので、月額費用もMAU上限もありません。
ユーザーの行き先は、自分で用意したデータベースになります。
対応しているログイン方法（プロバイダー）は数十種類あり、GitHub・Google・Slackなど主要どころは設定を数行足すだけで足ります。
その代わり、ログイン画面もパスワード再発行のメールも自分で作ることに。
設定ファイルの書き方も他の2つよりクセがあるので、最初の1回は時間がかかると思ってください。
3つの選び分けの目安
- とにかく早くリリースしたい：Clerk
- データベースも一緒に用意したい：Supabase Auth
- 外部に依存したくない・費用をゼロにしたい：Auth.js
個人開発SaaSにClerkで認証を実装する手順
ここからは実際のコードです。
Next.js（App Router）で、ログインボタンが動くところまでを3つのステップで進めます。
Clerkで認証を動かすまでの流れ
- アカウントを作って鍵を環境変数に入れる
- アプリ全体を包んでmiddlewareを置く
- ログインボタンとユーザー情報の取り出しを書く
【ステップ1】アカウントを作って鍵を環境変数に入れる
まずClerkのダッシュボードに登録して、アプリケーションを1つ作ります。
このとき、使いたいログイン方法にチェックを入れてください。
メールアドレスとGoogleを選んでおけば、個人開発の入口としては十分です。
作成が終わると、2種類の鍵が表示されます。
Next.jsのプロジェクトに.env.localというファイルを作って、2つの鍵をそのまま貼り付けます。
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_xxxxxxxxxxxx
CLERK_SECRET_KEY=sk_test_xxxxxxxxxxxx鍵を貼り付けるときに気をつけること
- 頭に
NEXT_PUBLIC_が付くほうはブラウザに配られる公開鍵 - 付いていないほうは秘密鍵。クライアント側のコードから絶対に触らない
.env.localは.gitignoreに入っているかを必ず確認する
鍵の置き場所が決まったら、ライブラリを入れます。
npm install @clerk/nextjsここまでで下準備は終わりです。
ちなみにnpx -y clerk@latest initを実行すると、このインストールと鍵の書き込みをまとめて済ませてくれます。
【ステップ2】アプリ全体を包んでmiddlewareを置く
次に、アプリ全体をClerkProviderで包みます。app/layout.tsxを開いて、以下のように書き換えてください。
import { ClerkProvider } from '@clerk/nextjs';
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<ClerkProvider>
<html lang="ja">
<body>{children}</body>
</html>
</ClerkProvider>
);
}続いてプロジェクトのルート（appと同じ階層）にmiddleware.tsを作ります。
Next.js 16以降を使っている場合は、同じ内容をproxy.tsというファイル名で置いてください。
import { clerkMiddleware } from '@clerk/nextjs/server';
export default clerkMiddleware();
export const config = {
matcher: ['/((?!.*\\..*|_next).*)', '/', '/(api|trpc)(.*)'],
};このmiddleware.tsが、リクエストのたびにログイン状態を確認してくれる部分になります。
置き場所を間違えると静かに動かなくなるので、ファイルの階層だけは必ず確認してください。
ログインしていない人を弾きたいページがあるなら、この中に判定を書き足していく形です。
最初に決めておきたい保護範囲
- 誰でも見られる：トップ・料金・利用規約
- ログイン必須：ダッシュボードとアカウント設定
- 契約者のみ：課金プランで開放する機能
【ステップ3】ログインボタンとユーザー情報の取り出しを書く
あとはボタンを置くだけです。
ヘッダーになる場所に、以下のコンポーネントを並べてください。
import { SignInButton, UserButton, SignedIn, SignedOut } from '@clerk/nextjs';
export default function Header() {
return (
<header>
<SignedOut><SignInButton /></SignedOut>
<SignedIn><UserButton /></SignedIn>
</header>
);
}これでログイン画面もプロフィール画面も付いてきます。自分で書いたHTMLは10行もありません。
サーバー側でログイン中のユーザーを知りたいときは、auth()を呼びましょう。
import { auth } from '@clerk/nextjs/server';
export default async function Page() {
const { userId } = await auth();
if (!userId) return <p>ログインしてください</p>;
return <p>あなたのIDは {userId} です</p>;
}このuserIdが、あなたのSaaSでユーザーを識別する値になります。
データを保存するときは、この値を外部キーとして持たせておくのが基本の形です。
Clerkを入れたあとに足しておきたいこと
- Webhookで自分の
usersテーブルにユーザーを同期する ClerkProviderに日本語のロケールを渡して表示を日本語にする- 保存するすべてのデータに
userIdを持たせる
特に効いてくるのが1つ目です。
ユーザー情報がClerk側にあるので、同期しないと自分のデータベースで登録者数すら数えられません。
個人開発SaaSにSupabase Authで認証を実装する手順
Supabase Authは、画面を自分で書くぶんだけClerkより手数が増えます。
そのかわり、認証とデータベースの権限が最初からつながっているのが強みです。
Supabase Authで認証を動かすまでの流れ
- プロジェクトを作って@supabase/ssrを入れる
- middlewareでセッションを更新しGoogleログインを有効にする
- RLSを有効にして自分のデータだけ読める状態にする
【ステップ1】プロジェクトを作って@supabase/ssrを入れる
Supabaseでプロジェクトを作ると、それだけでPostgreSQLと認証機能が両方立ち上がります。
プロジェクトの設定画面からAPIのURLと匿名キー（anon key）を取り出して、.env.localに入れてください。
NEXT_PUBLIC_SUPABASE_URL=https://xxxxxxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6...匿名キーはブラウザに出しても問題ありません。RLSで守る前提の鍵だからです。
問題になるのは、同じ画面に置かれているもう1つの鍵のほうですね。
サービスロールキーの扱い
- RLSを無視して全データを読み書きできる管理者用の鍵
- クライアント側のコードには絶対に出さない
- サーバー側でも、本当に必要な処理だけに限定して使う
鍵の整理ができたら、ライブラリを2つ入れます。
npm install @supabase/supabase-js @supabase/ssrApp Routerでは、ブラウザ・サーバーコンポーネント・middlewareでCookieの触り方がそれぞれ違います。
その差を吸収してくれるのが@supabase/ssrなので、必ず一緒に入れておきましょう。
【ステップ2】middlewareでセッションを更新しGoogleログインを有効にする
Supabaseのセッションは有効期限が短く、定期的な更新が必要です。
この更新をリクエストごとにやってくれるのがmiddlewareの役割になります。
ここを書き忘れると、しばらく操作しないだけでログアウトされたように見えます。
初見だと原因がまったくわからない不具合なので、先に置いてしまうのが安全ですね。
Googleログインを足すのも難しくありません。Google Cloudでクライアントを作り、そのIDとシークレットをSupabaseの管理画面に貼るだけで有効になります。
アプリ側から呼ぶコードは数行で済みます。
await supabase.auth.signInWithOAuth({
provider: 'google',
options: { redirectTo: `${location.origin}/auth/callback` },
});ログイン状態を確認するときの注意
- サーバー側で
getSession()の結果を信用しない（Cookieを読むだけで検証しない） - ページを守る判定には
getClaims()を使う（署名を公開鍵で検証してくれる） - 最新のユーザー情報が必要なときは
getUser()で問い合わせる
戻り先の/auth/callbackには、受け取ったコードをセッションに交換する処理を1つ置きます。
ここまでで、メールとGoogleの両方からログインできる状態になりました。
あとは、読み書きの制御をデータベース側に寄せていきましょう。
【ステップ3】RLSを有効にして自分のデータだけ読める状態にする
Supabase Authの本領はここからです。作ったテーブルは、RLSを有効にするまで匿名キーで誰でも読めてしまいます。
公開前に必ず有効化してください。
alter table projects enable row level security;
create policy "自分の行だけ読める"
on projects for select
using (auth.uid() = user_id);auth.uid()は、いまリクエストしている人のユーザーIDを返す関数です。
これとuser_idカラムを突き合わせることで、他人の行が結果に混ざらなくなります。
アプリ側の条件分岐と違って、この防御はデータベースの中で効きます。
フロントエンドから直接クエリを投げられても、返ってくるのは自分の行だけ。
RLSでやりがちな失敗
- selectのポリシーだけ作って、insertやupdateを書き忘れる
- 開発中に一時的にRLSを切って、そのまま公開してしまう
- サーバー側の処理で安易にサービスロールキーを使ってしまう
個人開発SaaSでAuth.js（NextAuth v5）を選ぶときの実装手順
Auth.jsは、外部サービスに一切依存したくない場合の選択肢です。
費用はかかりませんが、そのぶん自分で書く範囲が広くなります。
Auth.jsを導入するときに押さえること
- 設定ファイルとルートハンドラーの2つを用意する
- 画面とメール送信は自分で作り込むことになる
設定ファイルとルートハンドラーを用意する
導入はパッケージのインストールから始まります。
v5はまだbetaタグで配布されているので、指定を忘れないでください。
npm install next-auth@beta
npx auth secret2行目のコマンドは、セッションの署名に使う秘密鍵を生成して.env.localに書き込んでくれます。次に、プロジェクトのルートにauth.tsを作りましょう。
ここが設定の中心になります。
import NextAuth from 'next-auth';
import GitHub from 'next-auth/providers/github';
export const { handlers, auth, signIn, signOut } = NextAuth({
providers: [GitHub],
});最後に、認証のリクエストを受け取るルートを1つ置きます。app/api/auth/[...nextauth]/route.tsに、たった2行です。
import { handlers } from '@/auth';
export const { GET, POST } = handlers;Auth.jsで最初に決めておくこと
- 使うプロバイダー（GitHub・Googleなど）
- セッションをCookieに持つか、データベースに持つか
- ユーザーを保存するならどのアダプターを使うか
これでsignIn()を呼べばGitHubログインが動きます。
プロバイダーを増やしたいときは、providersの配列に足すだけで済みます。
迷いやすいのはセッションの保存方式ですね。
初期状態は署名付きトークンをCookieに入れる方式で、管理画面から特定の人を強制ログアウトさせたいならデータベース方式に切り替えます。
画面とメール送信は自分で作り込むことになる
ここまでは短いのですが、実際のSaaSにするには足りない部分が残ります。
まず、本番に出せるログイン画面が付いてきません。
デフォルトの簡素なページはあるものの、そのまま有料サービスの顔にするのは厳しいです。
メールアドレスとパスワードで登録させたい場合は、さらに作業が増えます。
パスワードのハッシュ化も、再発行メールの送信も、自分の責任範囲になるからです。
Auth.jsが向いているとき
- ソーシャルログインだけで完結させられる
- すでに使っているデータベースとORMがある
- 外部サービスの値上げや仕様変更を避けたい
ユーザー情報をデータベースに保存するなら、アダプターの設定も必要になります。PrismaやDrizzleを使っているなら、対応するアダプターを入れて指定のテーブルを作る形です。
このテーブル構造は公式に決まった形があるので、自分の設計に合わせて勝手に列を削らないでください。
逆に、メールとパスワードの登録を最初から入れたいなら、ClerkかSupabase Authのほうが確実に速いですね。
個人開発SaaSの認証実装でつまずきやすい落とし穴
認証が動いたあとに効いてくる問題が、いくつかあります。
どれも後から直すと痛いので、実装する前に頭へ入れておいてください。
認証を入れたあとに困りやすいこと
- 認証ユーザーと課金の顧客IDが結びついていない
- 無料枠の数字だけを見て停止条件を見落とす
- 乗り換えるときにパスワードを持ち出せない
認証ユーザーと課金の顧客IDを結びつけていない
SaaSである以上、いつかは課金を入れます。
そのときに必要になるのが、認証のユーザーIDと決済側の顧客IDの対応表です。
Stripeを使うなら、cus_で始まる顧客IDとsub_で始まるサブスクリプションIDが発行されます。
これを自分のデータベースに、認証のユーザーIDと同じ行で持っておく必要があります。
持っていないと、「支払いは通っているのに機能が開かない」という問い合わせに手作業で対応することに。
ユーザーが10人ならまだしも、100人になると回らなくなりますよね。
認証と課金をつなぐために持っておく列
- 認証サービス側のユーザーID
- Stripeの顧客ID（
stripe_customer_id） - 契約状態と、その有効期限
認証を入れる段階でこの3つを用意しておくと、課金を足すときの作業がかなりラクになります。
決済側の実装は個人開発でStripeを導入する方法｜手数料3.6%と5つの手順にまとめました。
無料枠の数字だけを見て停止条件を見落とす
無料枠はMAUの数字だけで比べがちですが、実際に効いてくるのは停止条件のほうです。
たとえばSupabaseの無料プランは、1週間アクセスがないとプロジェクトが一時停止します。
公開直後でユーザーが少ない時期ほど、この条件に引っかかりやすいんですよね。
ClerkとSupabaseは無料枠の人数こそ同じ水準ですが、数え方も超過時の単価も違います。
ClerkはMRU（その月に認証が発生した継続ユーザー）という単位で数え、超過分は1人あたり月0.02ドル。
ここは公式の価格表を見て確認しておくのが確実です。
個人開発だと、無料枠を超えるころには売上も立っているはずです。
問題になりやすいのは金額そのものより、予告なく止まる条件を知らないまま公開してしまうことだと思っています。
あとから乗り換えるときにパスワードを持ち出せない
認証サービスを変えたくなる日は、意外とやってきます。
値上げ、機能不足、あるいは単に相性が悪かった、といった理由ですね。
このとき問題になるのが、パスワードのハッシュを持ち出せるかどうかです。
メールアドレスの一覧はたいてい書き出せますが、ハッシュは申請しないと出してもらえないことがあります。
持ち出せない場合、全ユーザーにパスワードの再設定をお願いすることに。
そこで一定数が戻ってこないので、実質的な解約と同じ影響が出ます。
乗り換えを軽くしておくコツ
- 自分のDBのユーザー行を主とし、認証側のIDは1列で参照する
- 認証サービスのIDを、他のテーブルの外部キーに直接使わない
- ソーシャルログイン中心にすると、移行時の痛みが小さくなる
技術構成そのものの決め方は個人開発SaaSの技術選定｜Next.jsを軸にした構成の決め方で扱っています。
個人開発のSaaS認証と実装方法に関するよくある質問
Q：個人開発のSaaSで認証を実装する方法として、結局どれを選ぶべきですか？
A：迷っているならClerkから試すのが早いです。1時間もあればログインが動くので、認証で悩む時間そのものが消えます。データベースをこれから用意するならSupabase Authを、すでにDBとORMが決まっているならAuth.jsを選んでください。
Q：無料枠を超えると、いきなり請求されますか？
A：いきなり止まることはなく、有料プランへの移行を促される形が一般的です。ClerkのProプランは月額25ドルから、Supabaseも同じく25ドルからで、そこに超過分の従量課金が乗ります。売上ゼロのまま超えることは、まず起きません。
Q：メールアドレスの確認は必須ですか？
A：有料のSaaSなら入れておいてください。確認していないアドレスで登録されると、請求書も再発行メールも届かなくなります。3つのサービスとも設定で有効にできるので、公開前にオンになっているか見ておくと安心です。
Q：退会したユーザーのデータはどう扱えばいいですか？
A：認証側のユーザー削除と、自分のDBのデータ削除は別処理になります。Clerkのようにユーザー情報を外部に持つ構成では、Webhookで削除イベントを受け取る仕組みが必要です。保存期間の考え方は利用規約にも書くので、公開前に決めておきましょう。
まとめ
個人開発のSaaSで認証を実装する方法は、2026年時点では3択に絞れます。
速さで選ぶならClerk、データベースごと面倒を見てほしいならSupabase Auth、外部依存を避けたいならAuth.jsです。
どれを選んでも、パスワードを自分で保管するコードを書くより安全で速く進みます。
そして忘れやすいのが、認証を入れた時点で課金と退会の設計も半分始まっているということ。
ユーザーIDをどのテーブルに、どういう形で持たせるか。
ここだけは最初に決めておく価値があります。
実装に入る前に決めておくこと
- ログイン方法はメールか、ソーシャルか、両方か
- ユーザー情報を自分のDBに置くか、外部に預けるか
- 課金の顧客IDをどのテーブルで受けるか
SaaS全体の進め方は個人開発によるAI搭載SaaSの始め方｜アイデアから法人化まで総まとめにまとめてあります。
認証はSaaSの入口であって、目的ではありません。
3つのうちどれを選べば、本当に作りたかった機能に今週の夜の時間を使えそうでしょうか。
作ったサービスから出てくるデータを扱えるようになると、打ち手の精度が変わります。本格的に学ぶルートを知りたい方は、データサイエンティストに未経験からなるには？おすすめスクール7選が参考になります。
