ADHDManager開発記
タスク管理アプリは、ときどきタスクを減らすどころか、「タスクをきれいに管理する」という新しい仕事を増やしてしまう。
Projectを作る。期限を決める。優先順位を付ける。分類する。今日やるものを選ぶ。そして、もっと良い選び方がある気がして、また並べ直す。
ADHDManagerは、そうした「管理のための管理」を減らすために始まった。しかし開発の初期には、まさにProjectとTaskを管理する、ごく普通のタスク管理アプリに近い姿をしていた。
そこから設計を何度も壊し、AIの役割を疑い、同期や通知の失敗に向き合い、商業化を前に立ち止まった。最終的に見つかった中心価値は、タスクをたくさん管理できることでも、AIが賢いことでもない。
迷いを一件まで減らす。本人が決めたら勝手に変えない。決まった後は、アプリが退く。
この記事は、その考えにたどり着くまでの記録である。成功した機能だけでなく、途中で捨てた前提、実際に起きた障害、テストでは証明できなかったこと、そして現在も残っている課題までを書いていく。
前提: ADHDManagerはProductivityアプリとして開発中のプロダクトであり、ADHDの診断・治療・症状改善をうたうものではない。本記事の内容は2026年8月9日時点で、未コミットの開発中変更も区別して記載している。
出発点——AIが「次にやること」を選んでくれたら
最初の発想は単純だった。
締め切りなどの外圧がないと動き出しにくい時、目の前に一つだけ「今はこれ」と出してくれるアプリがあれば、選ぶところで消耗せずに済むのではないか。
2026年5月末に始まった最初の実装へ、Project、Task、AI推薦UIが加わった。OpenRouter経由でAIを使い、期限、重要度、使える時間、場所などを見て、取り組むTaskを選ぶ。コードが大きくなると、一つのファイルに集まっていた型を役割ごとのファイルへ分割した。
技術的には、順当にアプリらしくなっていった。ただし、ここには早くも矛盾があった。
「選べなくて困っている人」を助けたいのに、最初にProjectを作らせ、Taskを所属させ、いくつもの属性を入力させていた。迷いを減らすアプリが、使い始める前に新しい判断を要求していたのである。
当時の実装が無駄だったわけではない。Taskの永続化、AI通信、推薦ロジック、iOS/macOSで共有できる基礎は、その後も残った。しかし、動く実装と、目的に合うプロダクトは別物だった。
最初の大きな方向転換——「管理」ではなく「選択を終わらせる」
2026年7月、プロジェクト全体を目的から見直した。
そこで言語化されたのが、ADHDManagerはplannerではなく、むしろanti-plannerだという考えだった。工程をきれいに計画するのではなく、比較を終わらせて、一件に固定する。その後の進め方は本人へ返す。
中核体験は、次の流れへ変わった。
- 現在の条件に合うTaskを一件だけ見せる。
- ユーザーが「これをやる」と決める。
- その一件を固定し、AIの遅い応答や同期更新が来ても勝手に差し替えない。
- ユーザーはアプリの外を含め、自分のやり方で進める。
- 戻って「終わった」「ここで切り上げる」「手放す」のどれかを選ぶ。
ここで重要だったのは、「完了」だけを成功にしなかったことだ。
途中まで進んで区切ることも、今は合わないと手放すこともある。それを失敗や連続記録の途切れとして扱えば、アプリを開くこと自体が新しい圧力になる。そこで「今は無理」は推薦を改善するための情報にし、「ここで切り上げる」はTaskを残したまま現在の選択だけを終える操作にした。
同時にmacOS対応も進めた。単にiPhone画面を広げるのではなく、推薦ロジックや選択状態は共有し、NavigationSplitViewやキーボード操作など、画面の殻だけをプラットフォームへ合わせる方針を採った。
この段階で、製品の軸は「AI付きToDo」から、選択状態を守るアプリへ移った。
実際に壊れていたもの——動く画面の裏で、信頼が欠けていた
方向性を変えた後、UIを細かく見直すと、推薦精度より先に直すべき問題がいくつも見つかった。
- AI処理中に画面を閉じても、遅れて返った結果がTaskを追加し得た。
- 一覧の「開始」と、推薦画面の「これをやる」が別の状態遷移だった。
- AIが誤認した期限や重要度を、追加後に十分修正できなかった。
- 誤完了や誤削除を取り消す境界が弱かった。
- 「今やる」画面にProject名、選択元、条件調整などが並び、決定後もアプリが退いていなかった。
さらに、macOSレビュー用ビルドを起動した時、既存のSwiftDataストアを現行のデータ形式（schema）として開けず、Cannot use staged migration with an unknown model versionでアプリが終了した。
一番の問題は、移行に失敗したことそのものではない。保存領域を開けない時にfatalErrorへ進み、既存データを持つユーザーへ復旧手段を見せられなかったことだった。
この経験から、保存失敗を「例外」ではなく、製品が扱うべき状態に変えた。起動をloading / ready / recoveryRequiredへ分け、読めないデータを黙って削除・初期化せず、再試行や診断、バックアップの導線を出す。PreviewやGUIレビューには明示的な一時ストアを使い、実データから隔離する。
この時に得た教訓は明快だった。
信頼性は、正常系が速く動くことではない。失敗した時に、入力や既存データを勝手に失わないことで作られる。
Projectを消す。ただし、データは消さない
次に行ったのは、初期設計の中心だったProject管理を製品から外すことだった。
Project一覧、Project詳細、Project作成、Taskの所属先選択を通常導線から削除し、Taskを一つのフラットな集合として扱う。主要画面の共通+から、タイトルだけですぐ追加できるようにした。詳細は、必要になった時だけ後から開く。
これは見た目の整理ではない。「整理してから登録する」を、「まず捕まえてから必要なら整える」へ反転させる変更だった。
ただし、ここで過去のProjectデータまで消すと、正しい思想のために既存ユーザーのデータを犠牲にすることになる。そこでProjectItemとTaskItem.projectは、V1/V2ストアを読み続ける互換層として残した。新規TaskはProjectを持たないが、既存Projectとの関連を自動で外したり、名前を変えたり、削除したりしない。
古い構造を物理的に消すことと、製品体験から退場させることを分けたのである。
移行テストには、出荷済みschemaを再現するFrozen V2 fixtureを固定し、都合よく作り直さないルールも設けた。新しい設計へ進みながら、古いデータを開けることを同じくらい重く扱った。
AIを主役から降ろす
AIは便利だった。貼り付けた文章や写真からTask案を作り、複数科目の試験日程表なら科目ごとのTaskへ変換できる。「詰まった」時には、長い手順ではなく、再開のための一動作だけを返せる。
一方で、AIを中心へ置くほど、プロダクトは不安定になった。
OpenRouterではAI提供元の振り分けに互換性問題が起きた。構造化応答が長さ上限で切れる場合もあった。推薦では、通信処理が45秒待てる設計なのに、画面側は1.5秒で端末内推薦へ切り替えており、「AIが返事をしない」ように見える待ち時間のずれも見つかった。待ち時間を8秒へ揃え、空応答・不正応答・timeoutでは安全に端末内選択へ戻すようにした。
画像入力でも、単に「AIなら読める」とは考えなかった。画像を縮小し、サイズ上限を設け、端末内OCRの原文を保存し、AIが原文を消したり言い換えたりできないようにした。複数Task化は、独立した予定が明示された場合だけ最大8件まで許可し、一つの仕事を勝手に手順へ分解することは拒否した。
こうしてAIの役割は、次第に限定されていった。
- 中心の推薦は、まず即時で決定的な端末内ロジックを使う。
- AIは、文章や画像の整理、曖昧な日付の抽出、詰まった時の一手を得意領域とする。
- AIが使えなくても、追加、選択、固定、完了という中核体験は止めない。
- 外部送信は同意した機能だけにし、送る内容を画面上で説明する。
現在の作業ツリーでは、利用可能なら端末内のApple Intelligenceを先に使い、それで足りない時だけ、同意済みのOpenRouterへ進む段階的な構成も試している。ただし、これはまだ開発中であり、出荷済みの完成機能ではない。
AIを減らしたのではない。AIが失敗しても製品の約束が壊れない位置まで、主役から降ろした。
同期、通知、Widget——ビルド成功では証明できないもの
Apple Developer Program登録後、iPhoneとMacのTask、選択中の一件、推薦抑制をprivate CloudKitで同期するPhaseへ進んだ。日本語の日時表示や所要時間編集も整え、既存TaskをAIで編集・拡張する機能、Taskと独立したReminder、現在の一件を表示するWidgetを追加した。
ここでも、小さく見える不具合が設計の弱点を教えてくれた。
Widget側の互換型は読み取りにしか使わないのにCodableへしていたため、Encodable適合がなくビルドエラーになった。必要なのはDecodableだけだった。さらに、最初のWidget実装は表示データを正しく作れても、時間が過ぎた時に「次のReminder」へ進まなかった。アプリを開き直さない限り表示が古いままだったので、将来のReminder境界を更新予定へ積み、アプリ内表示も定期更新するように直した。
そして、ここには今も越えていない境界がある。
xcodebuildが成功しても、App GroupsやWidgetKitの権限設定、通知許可、deep link、実機上のCloudKit競合までは証明できない。署名、provisioning、2台の実機、CloudKit本番schema、通知権限の拒否や取消しは、それぞれ別に確認しなければならない。
「テストが通った」と「ユーザーの端末で信頼できる」は、同じ言葉ではなかった。
楽しさを足す。ただし、義務にはしない
タスクを終えた瞬間に、ほんの短い光や触覚が返ってくる。その程度の楽しさは、操作の手応えになる。
そこでFocus SparkというPlay layerを追加した。完了だけでなく、「ここで切り上げる」「手放す」にも肯定的な反応を返す。点数、streak、通貨、ランキング、未達ペナルティは作らない。遊びのための永続データも増やさない。
最初の実装レビューでは、Dynamic Typeを大きくした時に48ptの装飾が終了文へ重なる懸念が見つかった。また、「遊びの演出をOFF」という設定が今やる画面だけに効き、Quick Addや一覧のspring、glow、hapticには残るという、設定名と実効範囲のずれもあった。
そのため、Reduce Motionを含む共通gateを作り、装飾を主要操作の唯一の状態表現にせず、設定OFFをアプリ全体へ適用した。
楽しさを足す作業で学んだのは、派手さではなく一貫性だった。小さな演出ほど、「消したい人が確実に消せる」「見えなくても操作結果が分かる」という約束が重要になる。
商業化監査——作れていることと、売れることの間
2026年7月19日、実装を止めて、商業化の観点からプロダクト全体を監査した。コード、UI、CloudKit、通知、AI送信、Privacy、Accessibility、価格、Support、App Store運用までを横断し、結果は約2,500行のレポートになった。
そこで見えたのは、「機能が足りない」よりも、「信頼の説明と失敗時の回復が足りない」という問題だった。
- 通常のQuick Addと、外部AIへ送る入力の境界が分かりにくい。
- 同期中、未ログイン、offline、errorの違いが利用者に見えない。
- 通知登録に失敗しても、成功したように見える経路がある。
- portableなExport、Restore、全データ削除の契約が弱い。
- オンボーディングがなく、初回に何を入力すれば価値を試せるか伝わらない。
- Privacy Policy、Support、配布方式、公開名、App Store上の表現が未決定である。
- CloudKit本番schema、2端末競合、実機Accessibility、signed archiveは未証明である。
テストでは249件中248件が成功し、Unit test bundleは通った。一方、Quick AddのUIテストが1件失敗した。ただし証明できたのは、テストがkeyboard focusを確認せずにtypeTextしようとしたことまでだった。製品のautofocusが壊れているのか、テストの前提が間違っているのかは切り分けられていない。
この失敗は象徴的だった。数字をきれいにするために製品側かテスト側を適当に直すのではなく、何が証明され、何がまだ分からないかを分ける必要がある。
監査の結論は、機能競争へ進むことではなかった。
最初に売るべきものはAIではない。「もう選び直さなくていい」という安心である。
今取り組んでいること——Trust repair
監査後の現在は、商用機能を増やす前に、中心体験と信頼を修復する作業へ戻っている。
作業ツリー上では、次の改善を進めている。
- Quick Addを、まずタイトルだけ端末内へ保存する入口に戻す。
- 文章・写真のAI整理を別の明示操作へ分け、生成結果を確認してから追加する。
- 「今やる」の条件を折りたたみ、5分・15分・25分・60分から選べるようにする。
- 一覧から任意のTaskを「今やる」に指定できるようにする。
- 選択中のTaskからメモや詳細を開けるようにする。
- オンボーディングで、一件を追加して固定する価値を短く説明する。
- 同期状態、通知失敗、JSON書き出し、全データ削除を利用者へ見せる。
- 外部AIの同意と送信内容を明確にし、ZDR（データ保持を許可しない経路指定）を安全側の既定へ寄せる。
- 端末内AI、OpenRouter、固定の代替ヒントを段階的に使う。
ただし、この一覧は「完成した機能一覧」ではない。未コミットの開発中変更を含み、実機、CloudKit、通知、Accessibility、Release archiveの検証はこれからである。
ここまでの開発で、完成度を誤認させる言い方そのものが信頼を損なうと分かった。だから現在地も、実装済み、検証済み、未確認を分けて扱う。
何に失敗し、何を学んだか
振り返ると、大きな失敗はクラッシュやビルドエラーだけではない。目的と手段を取り違えた瞬間にあった。
1. 「AIで選ぶ」を目的にしてしまった
AIは手段なのに、AIが返るまで待つUIや、モデル設定が中心になりかけた。必要だったのは賢い推薦ではなく、迷いを短く終わらせることだった。
2. 一般的なTask managerの常識を持ち込んだ
Project、階層、分類、豊富な属性は便利だが、このプロダクトでは開始前の判断を増やした。高機能であるほど目的に近づくとは限らなかった。
3. 正常系の成功を、信頼性と呼んだ
Build成功は、migration、entitlement、通知許可、同期競合、署名を保証しない。テスト成功も、実機の利用旅程やAccessibilityを自動的には証明しない。
4. 失敗を見えなくすれば、体験が滑らかになると思った
AI fallback、通知登録、CloudKit同期を静かに処理しすぎると、利用者には「何が起きたか分からない」状態が残る。滑らかさと不透明さは違う。
5. 設定の言葉と、実際の範囲がずれた
Play layerのOFF、AI送信の同意、「端末内」という表示など、小さな文言のずれが製品全体の信用へ影響した。設定は実装詳細ではなく、利用者との契約だった。
これから——機能を増やす前に、仮説を証明する
今後の優先順位は、すでにかなりはっきりしている。
まず、誰のどの瞬間を助けるのかを、実際の利用者調査で確かめる。想定しているのは、タスクを持っているのに比較で止まり、必要な時だけ短く一件へ絞りたい人だ。ADHDの人全員に同じ解決策が効くとは仮定しない。
次に、端末内だけでも中心の流れが成立する状態を完成させる。追加し、一件へ固定し、終えるか区切るか手放し、必要な時だけ戻ってくる。AIなしでもここが速く、安心して使えることが先である。
その上で、次を公開前の合格条件として証明する。
- stable Xcodeでのsigned archiveとTestFlight相当の動作
- CloudKit本番schema、2台の実機、競合と復旧
- 通知、Widget、deep link、App Groupsの実機確認
- VoiceOver、Voice Control、Larger Text、Reduce Motionでの主要操作完遂
- Export、Restore、Deleteと、Privacy・Supportの運用
- 外部AIへ送る内容、同意、ZDR、失敗時fallbackの一致
- UIテストのfocus問題を含む、主要stateの再現可能な検証
収益化は、現時点では「無期限で使えるlocal core＋買い切りPro」が最初の仮説である。継続原価のあるmanaged AI subscriptionは、localや端末内AIより明確に価値が高く、品質、Privacy、費用、Supportが成立すると分かってから判断する。
最適化したいのは、滞在時間でも、入力Task数でも、連続利用日数でもない。
迷って止まった時、一件を決めるまでの時間が短くなったか。決まった後、アプリを閉じて実際の行動へ戻れたか。
この二つを、プロダクトの成長より先に測りたい。
おわりに——作らないものが、プロダクトを形にする
ADHDManagerの開発は、機能を積み上げる歴史であると同時に、作らないものを決める歴史でもあった。
Projectを通常導線から外した。サブタスクや依存関係を作らなかった。AIを必須にしなかった。streakや罰を入れなかった。決定後の画面から、理由や候補や技術情報を退かせた。
残ったのは、とても小さな約束である。
一度に見せるのは一件だけ。
決めた一件は、勝手に変えない。
終わっても、区切っても、手放しても責めない。
必要な時だけ現れ、決まった後は退く。
まだ、商用リリースの準備が整ったとは言えない。名前、配布、同期、Privacy、Support、実機品質、そして本当に人の役に立つかという検証が残っている。
それでも、何を作るかより先に、何を守るかは見えてきた。
ADHDManagerが目指しているのは、人生を管理することではない。次の一歩を選ぶための摩擦を、ほんの少しだけ減らすことである。