このアプリを作った背景は前回ブログでも軽く触れましたが、自分自身の体験談と、とある大学時代の友人のお話との間に領域は大きく違えども共通する点があり、そこに問題の普遍性があると感じたためです。本投稿で、もう少し深堀りして紹介させていただきます。
改めて、「なぜ、NASEBANAL Recorderを作ろうと思ったのか」 - 汎用的なデータ管理に対する個人的欲求
前回ブログでも紹介の通り、本アプリの特徴の一つと見据えている点は「汎用性」です。
なぜその考えにいたったのか、背景を以下に記載します。
私は大学で情報処理を専攻の後、IT業界で勤務経験をもってきましたが、以前より、「いつかは一度シリコンバレーで生活してみたい。シリコンバレーからはGoogleのような会社が輩出されるが、日本との違いはどこにあるのか知りたい。」と考えていました。
「現代の二都物語」や「ベンチャーズインフラ」といった本も読んだりして、おぼろげながらにスタートアップを支える環境に違いがあるのだろうと感じながらも、その様子を実際に自分の目で見てみたい。
故に社会人になってからもアメリカのシリコンバレー近辺の大学で勉強したい、という目標の元、その必須条件でもある英語を仕事の傍ら、継続的に勉強してきました。
ただ、その留学に必要なTOEFLの点数を上げることに思いの外、苦戦しました。「とにかく時間をかけて勉強すれば、いつかは点数も上がるだろう。点数が低いということは、勉強時間が足らないのだろう」、そう思い、朝の就業前、昼食、仕事が終わった後と、自分なりにがんばり、多少は点数も伸びましたが、ある点数からなかなか伸びない、いわゆる停滞期を迎えました。テストを何回か受けて、共通して、リーディングは比較的よくできていたのですが、特にリスニングがなかなか伸びませんでした。
そのような状況下における自分の反応は、仕事の合間を塗っての勉強であり、結果として、点数を上げるために必要な勉強ではなく、勉強しやすい、もしくは勉強していて心地よい勉強に少し時間をかけすぎていたと、今となっては感じます。もう少し具体的には、隙間時間に勉強しやすく、やっていて心地よい単語の暗記やリーディングを続けていたわけです。限られた時間を使って、効率よく点数を稼ぐには本来的には、苦手な領域を直視し、その改善に時間をかけるべき、と途中で気づきました。
社会人経験を持ち、しばらくして、とある大学時代の友人と会話をする機会があり、そこでの会話でも同様のインサイトを得られました。その友人はテニスを小さい頃から精力的に取り組まれており、そんな彼が話していたのは、「大学時代にテニスでスランプに陥った時があった。その時は、とにかく走っていれば、うまくなるだろうと、よく走り込みをしていた。ただ、本当にうまくなるためには、課題を構造的に把握し、一つずつ問題を解消していく必要があることに気づいた」というメッセージでした。
自分の英語の学習も同じだったと感じると同時に、そこに、すなわち上達のための近道と言わずとも、合理的な道があり、故にそれを伝えることができる経験豊富なトレーナーやコーチに価値がでてくるものと言う考えに至りました。
人を育てる、ということにはまさに普遍的なプロセスがあるのではないでしょうか。
それは、
- 適切なレベルの目標を設定する
- 課題を構造分解する
- 分解された課題ごとの小さな目標に向けて効果的なトレーニングメニューを組む
- 成長をトラッキング（可視化）し、適宜軌道修正する
- small success（成功体験）を積み上げ、モチベーションを維持しながら、より高い目標にチャレンジする
メジャーリーグで成功する大谷翔平選手、将棋の藤井聡太棋士ともに、ベースとしての高いモチベーションを持ちながら、このサイクルを効果的に回すことで、他の人がたどり着けない高みに至ったのではないかと感じています。
NASEBANAL Recorderはこの「人を育てる」という思想の元に開発した、基礎としてのデータ集めおよび進捗管理を行うツールだと見ていただければと思います。
将来的にはRecorderを基礎として、より上位の（多層的な）目標管理とその実現のためのトレーニングメニューの管理機能の実装も目指したいと考えています。また、データ収集に関しても、人での判断は難しいような自動メトリクス収集ツールの拡充も目指したいと考えています。
もしかしたら、血圧管理ツール、TOEFLスコア管理ツールのような領域を絞った優れたツールはすでにマーケットにあるかもしれません。ただ、ツールごとにデータがバラけて管理されていると、複数データを組み合わせて見えてくる気づきは得られないでしょうし、何より個人的には、携帯に領域ごとに個別のアプリをインストールし、それぞれの操作を覚え、使いたいとは思いません。かといって、携帯から普遍的なツールとして、Excelでデータ編集し、関係者と共有したいとも思いません。
それが、NASEBANAL Recorderを作成した動機です。
個人情報保護のアプローチ
データ管理をするサービスを考えるには、やはりセキュリティに対する対応が必要不可欠です。
将来、大切な情報が部外者に漏洩する、ということがあっては、一大事です。
そこで考えたアクションは２つです。
- Cloudflareのサービスをフル活用したSecure by Designなサービス
- "Tokenization"の発想を応用したデータ管理アプローチ
まずサービスはCloudflare Stackを最大活用した実装としています。
結果、デフォルトでDDoS攻撃をブロックしながら、WAFのマネージドルールでデフォルトで主要なセキュリティリスクから保護されています。
ただ、それでも、ユーザー側でパスワード漏洩が発生すればサーバーサイドのセキュリティ保護では対応に限界があります。
そこで考えたのは「データ漏えいを防ぐことには引き続き最大の努力をかける必要があるものの、仮に漏洩したとしても、その意味がわからなければよいのでは」、ということです。
この考えは、データセキュリティの分野で広く使われている「Tokenization」の発想を応用したものです。
Tokenizationとは、クレジットカード番号などの機密データを、それ自体では意味を持たないトークン（代替値）に置き換える手法です。トークンから元のデータを逆算することはできず、元データとの対応関係はトークン化システム内で厳格に管理されます。仮にトークン化されたデータが流出しても、それ単体では機密情報にたどり着けない、というのが本質です。
ここで着目したのは、「そもそもデータの"意味"をユーザー自身だけが知っている状態にしておけば、トークン化システム自体が不要になるのではないか」という発想です。一見単純ですが、多くのサービスはより高度なデータ分析を提供するためにデータの意味を把握する必要があり、この思想で設計されたサービスは意外と少ないのではないでしょうか。
NASEBANAL Recorderは、ただデータを管理し、グラフ化の上、関係者と共有することを目的としたプラットフォームです。もちろん、自分の成果を公開したい、という場合には登録データにわかりやすいタグ名をつけ、かつSNS共有ページで、補足の説明コメントを追加し公開することで、他の人もわかるように共有することもできます。ただ、「自分だけのデータ管理」を志向する場合には、Tokenization的発想で、場合によってはデータを複数のセットに分割登録したり、それぞれのタグ名（メタ情報）に無為な文字列を設定することで、自分だけがわかる情報管理を実現することも可能です。
そのような構成であれば、仮に一部データが漏洩したとしてもその意味を理解することは難しいかと思います。
2ヶ月間の体重記録から見えてきたこと
そんな中、Claude Codeを用いた本格的アプリ開発の経験を積むために、NASEBANAL Recorderを作り、自分自身でドッグフーディングをしてみました。
最初に試したのは、子供のランニングタイムの記録管理と、自分自身の体重管理です。
私が利用しているスポーツジムには体重計があります。たまに乗って数字を確認しては、自分の大体の体重を把握しているつもりでしたが、詳細な記録はつけていませんでした。
NASEBANAL Recorderで体重を継続的に記録し始めてから、これまで見えていなかったパターンに気付くようになりました。正月明けに体重が増えているのは毎年なんとなく感じていたものの、その後の日々でどの程度の時間間隔で変動があるのかまでは把握できていませんでした。今回、記録を取り始めて分かったのは、ほんの数百グラムの変動でも、色々と気づきをもたらしてくれています。
具体的には、体重がほんの数百グラムでも増えている場合には「確かに最近ちょっと食べる量が増えたかも」と感じたり、ちょっとした意識で食べるものを調整すると、数週間後に、着実に数百グラムの単位で、体重が減ってきたり、といった感じです。
また、体重を測るタイミングも重要です。何か食べた・飲んだ後に測ると瞬間的に多くなりますし、その逆もあります。
なので、できるだけ、時間をあわせる形で計測することがポイントでもあり、定期的に計測しては、データとして管理することで、トレンドが掴める実感を持てました。
こうした微細なトレンドは、記録を取り、可視化して初めて見えてくるもの。それは体重に限った話ではなく、世の中にはきちんと数値として管理できていない領域がまだまだたくさんあるのではないでしょうか。
事前定義タグ（カテゴリー設定）の追加
ドッグフーディングの結果追加した機能が、記録した生データから派生指標を自動計算する「事前定義タグ」です。
まずはテスト的に私自身の興味領域でもあるHealth（健康）とFinance（資産）の2カテゴリを実装し、リリースしました。
※既述の通り、データを完全に他者がわからないように、とする場合にはこちらの機能のご利用は目的に合わなくなりますが、そうでない場合、この機能は多少の利便性向上につながるかと思います。利用するかどうかはユーザーのご判断次第です。
Health/BodyWeight（健康/体重）
体重タグのカテゴリとしてHealth/BodyWeightを選択すると、以下が自動生成されます：
- Health/BodyWeight — 標準単位（kg）に換算した体重
- Health/BodyWeight/BMI — 体重と身長から算出されたBMI
体重は身長に大きく影響されるため、健康的な体重を評価するにはBMIが一般的に用いられます。一方で、自分の体重は把握していても、自分のBMIを正確に答えられる人は意外と少ないのではないでしょうか。
BMIの適正値については様々な議論がありますが、先日見たとあるドキュメンタリーでは、加齢とともに筋肉量が減少し体重が落ちる傾向があるため、中高年のBMIは27程度を目安にするのがよい、という説明がありました。
そういった背景から、NASEBANAL RecorderにBMIの自動算出カテゴリーを追加しました。目標値を設定すれば、チャート上に破線の目標ラインが表示され、日々の推移と目標の両方を一つのグラフで確認できます。
Finance/InvestmentAssets（資産/運用資産額）
昨今、FIRE（Financial Independence, Retire Early）というコンセプトが広まり、「少しでも早く経済的に自立して、仕事のストレスから解放されたい」と考える人も増えているのではないでしょうか。
ただ、FIREを目指すにしても「目標」がある以上、日々の進捗をトラッキングし、必要に応じて軌道修正することが重要だと感じます。
資産トラッキング用タグのカテゴリとしてFinance/InvestmentAssetsを選択すると、以下が自動生成されます：
- Finance/InvestmentAssets — 選択した通貨（円、ドル、ユーロ、ポンド）での運用資産額
- Finance/InvestmentAssets/AnnualIncome — 想定利回りに基づく年間収益の推計
このカテゴリーを使えば、あとどの程度の資産を積み上げるべきかが一目で分かります。推計年間収益に目標値を設定すれば、ゴールまでの距離がどう縮まっているかを日々確認できる。目標に向かって着実に前進していることが見えると、気持ちも前向きになるはずです。
上記の2つ以外に事前定義タグのアイディアがある場合にはぜひ、お問い合わせでお知らせください！
その他特徴
セキュリティ対策に考える基本思想は既述の通りとなりますが、それ以外にアプリ作成にあたって、心がけたポリシーがいくつかあります。
- Vendor Lock-inの回避 — やめたいときにいつでもやめられるよう、CSV入出力機能とAPI機能を公開しています。データは常にあなたのものです。
- APIファースト — 実装アーキテクチャーとしては、Google Workspaceでも採用されているような、SSOによる認証に対応したAPIをフロントエンドから呼び出す共通的構成を取っています。今後サービスを追加した際にも、共通セッションでログインの手間を防ぎながら、PAT (Personal Access Token) でデータアクセスできる構成で実装しており、必要に応じてNASEBANAL Recorderの機能を外部アプリから呼び出すことも可能です。
- SNS共有ページの一元管理と「忘れられる権利」 — 画像・音声などのメディアファイルはPresigned URLを介して共有されており、一定期間（デフォルト1年）経過後は自動的にアクセスできなくなります。またSNS共有ページはいつでも自分で非公開に切り替え可能であり、それぞれのページのView数もご確認いただけます。
SNS共有ページのサンプル (BMI Trend: Jan–Mar 2026)
ぜひ recorder.nasebanal.com でお試しください。本サービスはCloudflareの無料枠を最大限活用しているため、当面の間は無料でご利用いただけます。
有料化の際には事前にアナウンスしますので、そのタイミングでプランをFreeに切り替えていただければ課金は発生しません。この機会にぜひ色々と試していただき、フィードバックをお聞かせください！