同じ時刻に寝ても、
朝の目覚めは、
同じじゃない。

[ 出願までに考えたこと ]

思いつきを、
出願するまで。

発明は、ある日ひらめいて終わり——ではありませんでした。困りごとを疑って、思い出して、既にあるものを調べて、また考え直す。教え子と一緒にたどった道のりを、順番に残しておきます。

1. STEP 01 ｜ 困りごと

   「朝、どうしても起きられない」

   始まりは、授業の雑談でした。アラームは鳴っている。止めた記憶もある。でも次に気づくと30分経っている——という話。市販の目覚ましアプリはひと通り試した後でした。

   教え子のことば「アラームを増やしても意味がない。止めて寝てるだけだから。」
2. STEP 02 ｜ 最初の仮説を疑う

   「睡眠時間が足りないだけ」なのか？

   いちばんありそうな説明から疑いました。ところが、思い返してみると同じくらい寝ているのに、すんなり起きられる日と、まったくダメな日がある。時間の長さだけでは説明がつかない、というのが最初の手がかりになりました。

3. STEP 03 ｜ 思い出してみる

   話しながら、ここ最近の夜を一つずつ

   記録を取っていたわけではありません。話しながら、直近の夜を思い出していっただけです。「あの日は何時に寝た？」「その前は何をしてた？」「翌朝はどうだった？」——順番に並べていくうちに、「なんとなくそんな気がする」だった実感が、比べられる形になっていきました。

4. STEP 04 ｜ 気づき

   違いは「寝る前に何をしていたか」にあった

   同じ23時半に切り上げた日でも、プログラミングをしていた夜は寝つくのに1時間近くかかり、そのかわり朝は自然に目が覚める。動画を見ていた夜はすぐ寝落ちするのに、夜中に目が覚めて、朝は二度寝する。時刻ではなく、直前にやっていたことの種類が効いているらしい、と見えてきました。

   教え子のことば「時間じゃなくて、“何をしてたか”で朝が変わるってこと？」
5. STEP 05 ｜ 既にあるものを調べる

   「それ、もうあるんじゃない？」を先に潰す

   思いついたら、まず世の中を疑う。調べると、浅い眠りのときに鳴らす目覚ましも、スマホの操作から就寝を推定する仕組みも、すでにありました。ここで一度、素直にがっかりしています。

   ただし、よく読むと共通点がありました。どれも見ているのは眠ってしまった後か、せいぜい「寝ようとしている合図」まで。寝る前に何の作業をしていたかを予測の材料にしているものは見当たらない——ここが残っている、と分かりました。

6. STEP 06 ｜ 仮説を組み直す

   「作業の種類」を、機械に教えられる形にする

   人間の実感を、そのまま機械に渡すことはできません。そこで、使っていたアプリやサイトから作業を種類に分ける→作業を終えてから寝つくまでの時間を測る→翌朝どう起きたかを結果として記録する、という3点セットに分解しました。この3つが揃えば、あとは学習させられます。

   そしてもうひとつ大事な発見。この傾向は人によって違う。誰にでも当てはまる法則ではなく、その人専用に学習するしかない、という結論になりました。

7. STEP 07 ｜ 最初の難所

   そもそも「作業が終わった」のはいつ？

   実装を考えはじめて詰まったのがここでした。アプリを閉じた＝終わり、とすると簡単に誤判定が起きます。PCを閉じたあと、スマホで同じ続きをしていることが普通にあるからです。

   そこで、ひとつのイベントで決めるのをやめました。保存・終了・画面消灯・ロック・無操作といった複数の合図を重みづけして「終わったらしさ」を計算し、さらに別の端末で続きをしていないかを確かめてから確定する、という形に。

8. STEP 08 ｜ 二つ目の難所

   気持ちよく起きても、遅刻したら意味がない

   「起きやすい瞬間に鳴らす」を突き詰めると、予定に間に合わなくなります。当たり前ですが、これは発明として片付けておかなければいけない点でした。

   結論は、翌日の予定から逆算した『これ以上は寝ていられない時刻』を上限として先に決め、その手前で一番起きやすい瞬間を選ぶ。自由に選ばせるのではなく、枠を先に置く、という順番にしました。

9. STEP 09 ｜ 特許にできるのか

   「部品はぜんぶ既にある」という壁

   本格的に先行技術を調べると、要素はことごとく公知でした。操作ログからの就寝推定も、浅い眠りでのアラームも、作業内容の推定さえも、それぞれ別の特許があります。

   ここで教え子と話したのは、「新しい部品がないと発明じゃない、わけではない」ということ。誰も繋げていない繋ぎ方なら、それは新しい。実際に残ったのは、①作業を種類に分けて説明変数にする ②作業の種類から寝つくまでの時間を予測する ③翌朝の起き方を教師データにして個人別に学習する——この3点でした。

   教え子のことば「部品が全部あっても、組み合わせが新しければいいんだ。」
10. STEP 10 ｜ ことばにする

    請求項という、いちばん短い作文

    最後は書類です。思っていることを、広すぎず狭すぎない一文にする作業。広く書けば先行技術にぶつかり、狭く書けば誰でも避けられる。この綱引きを、独立項1つ＋従属項で少しずつ限定していく形に落とし込みました。

    図面も自分たちで引きました。全体構成、作業終了の判定、学習データの中身、予測の更新、アラームを決めるところ——提出した5枚が、考えたことの地図になっています。

11. STEP 11 ｜ 出願

    2026年7月19日、送信

    特許庁の「インターネット出願ソフト」から電子出願。弁理士は立てず、明細書も請求項も図面も自分たちの手で。困りごとの雑談から、特願2026-174849という番号がつくまでの記録です。

アラームは、
「時刻」しか知らない。

目覚まし時計は、私たちが眠る前に何をしていたかを知りません。スマートウォッチと連動して「浅い眠りのときに鳴らす」ところまでは既にありますが、それは眠ってしまった後の話です。

この発明の着眼は、その手前にあります。同じ23時30分に端末を閉じたとしても、直前にやっていたのが集中を要するプログラミングだったのか、寝落ち間際まで見ていた動画だったのかで、寝つくまでの時間も、夜中に目が覚めるかも、翌朝すんなり起きられるかも変わってきます。しかも、その傾向の大きさも向きも人によって違う。

ならば、作業の種類を入力の特徴量に、その夜の起き方（起床結果）を教師データにして、その人専用のモデルを学習させればいい。そうすれば、作業を終えた時刻が同じでも、作業の種類に応じて違う起床予測が出せます。あとは翌日の予定から逆算した「これ以上は寝ていられない時刻」を上限として、その手前で一番起きやすい瞬間にアラームを鳴らす——というのが、出願した仕組みです。

3つの、届いていなかったところ。

6つの部が、夜をつなぐ。

操作ログの取得から、アラームを鳴らす瞬間の決定まで。処理はサーバでも、端末やウェアラブルの中でも実行できます（本文の解析結果を送らず、端末側で算出した特徴量だけを使う構成も明細書に記載）。

実際に提出した、5枚。

※ 特許庁に提出した図面そのもの（様式に合わせたグレースケール）。

‹ ›

図1 — 全体構成

利用者端末・睡眠測定装置・サーバ装置・予定情報提供装置・アラーム装置の関係。サーバ装置の中に9つの機能部が並びます。

同じ23:30。違う朝。

明細書の実施例1・2より。作業を終えた時刻はどちらも23:30。違うのは、直前にやっていたことだけです。

※ 数値は明細書中の実施例として記載したものです。傾向の大きさも向きも利用者ごとに異なる、というのが本発明の前提です。

発明は、一度きりじゃない。

今回いちばん伝わったのは、特許が特別な人だけのものではない、ということでした。困っていることに気づく→なぜだろうと考える→すでにあるものを調べる→自分のことばにする。この順番さえ知っていれば、次のアイデアも同じように形にできます。

だから、これからも「あったらいいな」を口に出してほしいと思っています。思いついたことを黙って流さずに、もう一度、なんで？と聞き返せる人でいてほしい。1件目より2件目、2件目より3件目のほうが、きっと速く書けるようになります。

思いついたことを、
権利の形にするところまで。

この発明や、セキュリティ × AI × ものづくりの取り組みについてのお問い合わせは、お気軽にどうぞ。