創業者ノート
ありそうになかったプロジェクト
2026年9月
Health Mirror の開発に着手したのは、2026年の2月のことでした。
それから約1週間後には、スマホの上で端から端まで動作するようになっていました。
当時の私は「おお、本当に動いた。」と思ったのを覚えています。
実際には、まったく動いていませんでした。:)
けれど、その最初の1週間で、もっと重要かもしれないあることに気づかされました。
アイデアを思いついてから、それを実際につくるまでの距離が、突然ぐっと縮まったのです。
当時の私は、プリンシパル・プロダクトマネージャーでした。
私の仕事は、普段なら「何をつくるか」と「なぜつくるか」を定義することです。それを「どう実現するか」に落とし込むには、フルスタックのR&DチームやIT、運用担当など、多くの人たちと協働する必要がありました。
大規模言語モデル（LLM）は、私にとってその関係性を変えてくれました。一本道とはいかないものの、馴染みのない領域を案内してくれるAIパートナーが傍らにいる状態になったのです。:)
Health Mirror は、その新しいアプローチでどこまでいけるかという、私自身の実験になりました。
こうして、1週間でつくったアプリは現実に直面することになりました。
最初のバージョンは、AIの推論を含めたすべての機能をスマホの中に収めていました。
私はこのアーキテクチャを気に入っていました。ローカルで撮影し、ローカルで画像を準備し、ローカルでモデルを実行し、結果もローカルに保持する。
それから、これをiOSとAndroidの両方で動く本物のアプリにしようと試みました。
続く約1ヶ月間、私は主要な機能を支える依存関係のチェーンを揃えようと、技術的なモグラ叩きを続けることになりました。
ひとつの不互換を解決すれば、また別の問題が顔を出す。ひとつの依存ライブラリをアップデートすれば、別のどこかが動かなくなる。
1ヶ月に及ぶモグラ叩きの末、AIパートナーがついにこう言いました。「これ以上の提案はありません。このエコシステムは発展途上にあります。年内には可能になるかもしれませんが」
私たちは敗北を認めました。
プロジェクトのメモは、かなり断定的なものになりました。
## ⚠️ Known Constraints & Decisions
### ❌ Abandoned Approach
* TensorFlow.js + React Native (Expo)
* Reason: incompatible with modern RN/Expo architecture
さらにこう続きます。
## 🧠 Key Lessons Learned
* On-device AI with Expo + TFJS is not viable (current ecosystem)
* Native/runtime layer matters more than JS layer for ML
...
そこで、チームを変えることにしました。
2人目のAIパートナーを追加したのです。
私たち3人で、壁打ち相手としては十分なチームになりました。やがて、片方がアーキテクトに、もう片方がコーダーになりました。
同じ頃、私は自分のモデルについて、少し恥ずかしい事実に気づきました。:)
最初のバージョンでは、画像認識において排他的な選択を行うsoftmaxを使っていました。その後、1枚の画像に対して複数の独立したラベルを付与できるsigmoidへ移行した「つもり」になっていました。舌象のパターンを観察するには、その方がはるかに適していたからです。
しかし実際には、本物のsigmoidではなく、softmaxを使って擬似的に再現されたものだったのです。
そこで私たちは、モデルを再学習させました。
出力の精度を上げるために、もう一度再学習。
そして、もう一度。:)
4月に入る頃には、以前のアプローチを繕うのはやめていました。
私たちは、本格的な方針転換（ピボット）に踏み切りました。
本当にスマホの外へ出す必要がある、最小限の要素は何か？
その問いが、アーキテクチャの鍵を開けてくれました。
カメラでの撮影、画像のデコード、テンソルの準備、そして機械学習の推論を、iOSとAndroidの両方で互換性のあるひとつのモバイル依存関係のチェーンに無理やり通す代わりに、明確に切り分けられたひとつの機能だけをクラウドへ移しました。
推論。
それ以外はすべて、私が望んでいたとおり、スマホ側に残すことができました。
その設計の最も初期の案では、まだ推論サービスに画像を送信することを想定していました。当時のメモはこんな感じでした。
## 🔐 Privacy Design (MVP)
* Images sent to server for inference
* No persistent storage of images
* Processing done in-memory
* HTTPS required for production
## 🧭 Future Considerations (Post-MVP)
...
* Possible future migration: ONNX Runtime (on-device AI)
その後、デリケートな依存チェーンを壊すことなく、テンソル準備の工程も分離することに成功しました。これにより、推論のために元の画像をクラウドに送る必要すらなくなったのです。
送られるのは、数値化されたテンソルデータのみ。
クラウド側のサービスがモデルを実行し、予測の確信度スコアのリストを返します。
それ以外のすべては、スマホ側で組み立てます。
技術的な答えは大きく変わりました。
けれど、原則は変わりませんでした。
最初から、セキュリティとプライバシーを組み込みたかったのです。
私は、セキュリティ、プライバシー、そしてコンプライアンスに対して、純粋な情熱を持っています。
面白いと感じるのです。
ええ、どうやらそういう人も世の中にはいるようです。:)
CISSP（Certified Information Systems Security Professional）の試験に向けて勉強し、合格までしました。8つのサイバーセキュリティ分野を扱う資格で、プロダクトマネージャーというより、セキュリティやITを専門にする人たちのほうがずっとなじみがあります。
機会があるなら、セキュリティを実現するのは自分の責任のように感じています。
しかし、企業組織の中で長年過ごす中で、ずっと私をモヤモヤさせていたパターンがありました。
システムを作る。すべてを接続する。データを集める。
プライバシーとセキュリティは、大抵あと回しです。
その頃には、重要な決断の多くがすでに下されてしまっています。変更には多大なコストがかかり、経済的に不可能なことさえあります。
Health Mirror では、最初からきわめてシンプルな問いを投げかけることで、その順番を逆転させる機会がありました。
このデータは、本当にデバイスの外に出す必要があるのだろうか？
リリース前には、セキュリティとプライバシーのセルフレビューも行いました。誰かに義務付けられたからではなく、実際の実装とプライバシーポリシー、そして私たちが人に伝えていることを、きちんと一致させたかったからです。
数ヶ月間このやり方で構築してきたため、一致しているという手応えは十分にありました。それでも最後のチェックを行えば、見落としていた隙間に気づけるかもしれません。
私の「1週間でできたアプリ」は、結局さらに6ヶ月かかりました。
最初のプロトタイプからリリースまでの間には、他にもたくさんの冒険がありました。
けれど、一番私を驚かせたのはおそらくこれです。
AIは、魔法のようにすべての答えを与えてくれたわけではありませんでした。次の問題へと辿り着くスピードを、ずっと、ずっと、ずっと速くしてくれたのです。
最初のモデルがなぜ間違っていたかを理解できる程度の機械学習を学びました。最初のアプリがなぜ本物のアプリと言えなかったかを理解できる程度のモバイルエンジニアリングを学びました。気に入っていた設計をいつ手放すべきか判断できる程度のアーキテクチャを学びました。
そして、理解できない壁にぶつかったときは、私たち3人で調査し、自分たちの前提を疑い、新しいことを学び、もう一度試すことができました。
「1週間で動いた」アプリから6ヶ月後——フルタイムで仕事をしながら——Health Mirror は、ついに他の人々が実際にダウンロードできるものになりました。
私のsoftmaxはsigmoidになりました。
1つのAIパートナーは2つになりました。
完全オンデバイスだったアーキテクチャには、意図的に小さく作られたクラウドサービスがひとつ加わりました。
そして、私の実験はプロダクトになりました。
2月の頃に信じていたものとは、随分と違う道のりになりました。
この先に何が起こるのか、あのときは知らずにいてよかったと思っています。:)