16 ポイント 投稿者 choigeon0501 2026-06-08 | 16件のコメント | WhatsAppで共有

サービスに会員登録の本人確認を組み込むたびにSMS送信コストが負担になるため、発想を逆転させて作った携帯電話認証APIです。

従来のSMS認証は、サービスがユーザーに認証SMSを送信します(MT, Mobile Terminated)。1通あたり9〜50ウォンに月額基本料までかかるため、ユーザーが増えるほどコストが大きくなり、契約・審査のために連携完了まで1〜2週間かかることもあります。

OCTOMOはこの方向を逆にしました(MO, Mobile Originated)。ユーザーが自分の携帯電話から指定された番号へ認証コードをSMSで送り、サービスは受信したメッセージをAPIで照会するだけです。SMSを送る主体がユーザーであるため、サービス側には送信コストが発生せず、ユーザーが実際にその端末からSMSを送ったという点で所持認証になります。

フローとしては、認証ボタンを押すとSMSアプリが宛先番号と認証コードがすでに入力された状態で開き、ユーザーは送信ボタンだけ押せばよい方式を推奨しています。(sms: ディープリンクで処理するためフロントエンドで実装する部分ではありますが、モバイルではこれが定石です。) 番号の入力ミスやコードの打ち間違いが起きないので、失敗率も一緒に下がります。

APIは実質的にエンドポイント1つです。
POST /octomo/v1/public/message/exists

  • 入力: 携帯電話番号 + ユーザーが送ったコード
  • 出力: 直近5分以内に該当コードのSMSを受信したかどうか (verified: true/false)

連携フローは「ボタンをタップ → SMSアプリ自動起動(番号・コード自動入力) → ユーザーが送信 → このAPIを呼び出してtrueになれば通過」程度なのでシンプルです。別途アプリのインストールやSDKは不要で、REST呼び出しだけで済み、Node/Java/Pythonのサンプルをドキュメントに入れてあります。

正直な制約も書いておきます。

  • ディープリンクで入力の手間はなくしましたが、ユーザーが送信ボタンをもう一度押すという操作ステップは残ります(送信コスト0ウォン・所持認証強化とのトレードオフ)。
  • 韓国国内の携帯電話番号ベースのため、海外ユーザーは対象外です。
  • ユーザーには自身の料金プランのSMS料金が適用されます(無制限プランなら実質無料)。

特に「このフローだとユーザー離脱が大きくならないか」といったUX面の懸念や、セキュリティ観点での指摘を聞きたいです。フィードバック歓迎です.

16件のコメント

 
channprj 2026-06-09

ああ、ある種のMO認証なのですね。このような本人認証や携帯電話占有認証のようなサービスは、金融監督院など主要な関係機関の法的要件を満たして効力を持つのかについて言及されると、さらに良いと思います。応援しています!

 
choigeon0501 2026-06-10

応援ありがとうございます!

 
pleasantlife 2026-06-15

良いサービスを作ってくださってありがとうございます!
SMS受信の有無が直近5分以内で固定されていますが、
これより短くしたい場合や長くしたい場合もあると思うので、
受信有無の確認時間をAPIのパラメータ内で指定できるようにするのも
良いのではないかと思いました!

 
choigeon0501 2026-06-16

ご意見ありがとうございます!ご指摘いただいた点を検討し、より良いサービスへ改善してまいります!

 
nemorize 2026-06-11

社内でその機能を作って使っているうちに、
似た形のSaaSもあわせて運営してみようかと考えたことがあったのですが、
これは法的な問題が少しあるのではないかと思いました。

自社名義で契約した電話番号を使う権利を顧客に販売する形になってしまうので、
これって電気通信事業法違反になるのでは?という考えが浮かんだんですよね...

 
hshim 2026-06-10

フィーチャーフォン時代には、発信番号を自由に変えられたのを思い出しますね
当時だったら効力のない技術だったでしょうが、時代が変わることで活用できる技術になったのが面白いですね

 
choigeon0501 2026-06-10

ご関心をお寄せいただきありがとうございます!

 
sleeplesshan 2026-06-09

おお、いいアイデアですね

 
choigeon0501 2026-06-10

ありがとうございます!

 
ifmkl 2026-06-09

旧・公認認証書の発行時には、おっしゃっていた方法どおり、特定の数字をSMSで返信する形式の認証を行っていますね。

 
yeobi222 2026-06-09

すでにこの方式でユーザー自身に送信させる認証方式も少数ながら使われているので、特に概念自体へのフィードバックは不要な気がします。
個人的には認証番号を受け取って入力するより好みの方式です。
どうせ法的な本人認証が必要なものはPASSを搭載しなければならないはずなので、それは別の話として…

 
winterjung 2026-06-08

本人確認と占有認証では、それぞれ満たすべき法的要件が異なるため、本人確認を使わなければならないケースがあると理解しています。どのような場合にこの占有認証だけでもよいのかについて、もう少し詳しく書かれているとよかったですね。

 
choigeon0501 2026-06-08

フィードバックありがとうございます!
ご指摘のとおり、本人認証と占有認証では満たす要件が異なるため、
どのような場合に占有認証だけで十分なのか、その基準をドキュメントでより明確に整理して追記します。
的確にご指摘いただき、ありがとうございます!

 
hmmhmmhm 2026-06-08

おお、一度はあってほしいと思っていたものですが、APIがとても使いやすくできていますね...!
「ユーザーが自分の携帯電話から指定された番号に認証コードをSMSで送信し」
この部分が少し紛らわしいのですが、OCTOMOが提供する番号にSMSを送るよう案内する、ということですよね?

 
choigeon0501 2026-06-08

はい、その通りです! OCTOMOが提供する番号宛てに認証コードをSMSで送信するようご案内いただければ大丈夫です。

アプリ環境では sms: ディープリンクを活用し、ユーザーが認証ボタンを押した際にメッセージアプリが自動で開くように実装されることをおすすめします!

Web環境では現在、認証コードをSMSで送信する方式を提供しており、あわせてQRコード方式も開発中です。
ユーザーがQRコードを読み取ると自動的にメッセージアプリへ切り替わるよう実装しています!

ありがとうございます!

 
hmmhmmhm 2026-06-08

わあ、とてもいいですね……サイドプロジェクトでうまく使わせていただきます(笑)