ADHDManager開発記
タスク管理アプリって、たまにタスクを減らすどころか、「タスクをきれいに管理する」という新しい仕事を増やしてくる。
Projectを作る。期限を決める。優先順位を付ける。分類する。今日やるものを選ぶ。もっといい選び方がある気がして、また並べ直す。
ADHDManagerは、そういう管理のための管理を減らしたくて作り始めた。
ところが最初に作ったのは、ProjectとTaskがあって、AIが次にやることを選んでくれる、ごく普通のタスク管理アプリだった。
今見ると、やりたかったことと普通に逆だった。
ADHDManagerはProductivityアプリとして開発中のもので、ADHDの診断、治療、症状改善をうたうものではない。この記事は2026年8月9日時点の記録で、作業ツリー上にしかない開発中の変更は、そのように分けて書いている。
最初は普通のAI付きToDoだった
最初の実装を始めたのは2026年5月末。
ProjectとTaskを作り、期限、重要度、使える時間、場所などをOpenRouter経由のAIへ渡して、次に取り組むTaskを選ばせた。コードが大きくなってきたので、一つのファイルに集まっていた型も役割ごとに分けた。
機能は増えたし、画面上は一通り動いた。
でも、「選べなくて困っている人」を助けたいのに、使う前にProjectを作らせ、Taskを所属させ、属性をいくつも入力させている。
いや、選ぶ前にやること増えてるじゃん。
2026年7月にプロジェクト全体を見直して、ADHDManagerはplannerではなく、むしろanti-plannerなんじゃないかと考えるようになった。
きれいな計画を作るより、比較を終わらせて一件に固定する。決めたあとの進め方は本人へ返す。
流れもかなり単純にした。
- 今の条件に合うTaskを一件だけ見せる。
- ユーザーが「これをやる」と決めたら、その一件を固定する。
- AIの遅い返事や同期更新が来ても、勝手に別のTaskへ変えない。
- 戻ってきたら「終わった」「ここで切り上げる」「手放す」のどれかを選ぶ。
完了だけを正解にするのもやめた。途中まで進んで区切ることもあるし、今は合わないと手放すこともある。それを失敗やstreakの途切れにしたら、アプリを開くこと自体が新しい圧力になる。
「今は無理」は次の推薦を調整する情報にして、「ここで切り上げる」はTaskを残したまま、今の選択だけを終える操作にした。
同じ頃にmacOS対応も進めた。iPhoneの画面をそのまま引き延ばすのではなく、推薦ロジックと選択状態は共有しつつ、NavigationSplitViewやキーボード操作など、画面側だけを各OSに合わせている。
Projectを画面から消した
次に、初期設計の中心だったProject管理を通常の画面から外した。
Project一覧、詳細、作成画面、Taskの所属先選択を消して、Taskは一つのフラットな集合として扱う。共通の+から、タイトルだけですぐ追加できるようにした。詳細は必要になったときに開けばいい。
「整理してから登録する」ではなく、まず捕まえる。整えるのはあと。
ただし、画面からProjectを消すのと、過去のProjectデータを消すのは別の話だ。
ProjectItemとTaskItem.projectは、V1／V2のストアを読み続けるための互換層として残した。新しいTaskはProjectを持たないけど、既存TaskとProjectの関連を勝手に外したり、Project名を変えたり、削除したりはしない。
移行テストで使うFrozen V2 fixtureも固定した。新しい設計に都合よく作り直したら、古いデータを本当に開けるか分からなくなるからだ。
画面は動いた。でも普通に危なかった
方向を変えたあとにUIと状態遷移を見直すと、推薦精度より先に直すものがいくつも出てきた。
- AI処理中に画面を閉じても、遅れて返った結果がTaskを追加できた。
- 一覧の「開始」と、推薦画面の「これをやる」が別の状態遷移になっていた。
- AIが誤認した期限や重要度を、追加したあと十分に直せなかった。
- 誤完了や誤削除を取り消す境界が弱かった。
- 「今やる」画面にProject名や条件調整が残り、決めたあともアプリが退いていなかった。
さらにmacOSのレビュー用ビルドを起動したら、既存のSwiftDataストアを現行schemaとして開けず、Cannot use staged migration with an unknown model versionでアプリが終了した。
起動しないのも困るけど、もっとまずかったのは、保存領域を開けないとfatalErrorへ進み、既存データを持つ人へ「どう戻すか」を何も出せなかったことだった。
そこで起動状態をloading / ready / recoveryRequiredの三つに分けた。読めないデータは勝手に削除したり初期化したりせず、Recoveryで止めて、再試行、診断、バックアップの導線を出す。
PreviewやGUIレビューも、実データではなく明示的な一時ストアを使うようにした。
AIを主役から降ろした
AI自体は便利だった。
貼り付けた文章や写真からTask案を作ったり、複数科目の試験日程表を科目ごとのTaskへ分けたりできる。「詰まった」ときには、長い手順ではなく、再開するための一動作だけを返すこともできた。
ただ、中心へ置くと途端に不安定になる。
OpenRouterではproviderの振り分けに互換性問題が出た。構造化応答が長さ上限で切れることもあった。
推薦では、通信処理が45秒待てるのに、画面側は1.5秒で端末内推薦へ切り替えていた。画面から見れば、AIは1.5秒で打ち切られていたことになる。
待ち時間を8秒へ揃え、空応答、不正応答、timeoutなら端末内選択へ戻るようにした。
画像入力も「AIなら読める」で済ませず、縮小とサイズ上限を入れ、端末内OCRの原文を残すようにした。AIが原文を消したり、勝手に言い換えたりできないようにするためだ。
複数Taskへ分けるのも、独立した予定が明示されている場合だけ最大8件まで。一つの仕事をAIが勝手に細かい手順へ分解するのはやめた。
中心の推薦は、まず即時に返せる端末内ロジック。AIは文章や画像の整理、曖昧な日付の抽出、詰まったときの一手に使う。AIが落ちても、追加、選択、固定、完了は止めない。
外部へ送るのも、ユーザーが同意した機能だけにして、送る内容を画面上で説明する。
8月9日時点の作業ツリーでは、使えるなら端末内のApple Intelligenceを先に使い、足りないときだけ同意済みのOpenRouterへ進む構成も試していた。ただし、これはまだ開発中で、出荷済みの完成機能ではない。
AIを減らしたというより、AIが失敗しても中心の流れが止まらない位置まで降ろした、という方が近い。
ビルドが通っても、実機で動くとは限らない
Apple Developer Programへ登録したあと、iPhoneとMacのTask、選択中の一件、推薦抑制をprivate CloudKitで同期するPhaseへ進んだ。
日本語の日時表示や所要時間編集も整え、既存TaskをAIで編集・拡張する機能、Taskとは別のReminder、今の一件を表示するWidgetも追加した。
Widget側で読み取り用に置いた互換型をCodableにしていたが、Encodableの要件を満たせずビルドエラーになった。必要だったのはDecodableだけ。
それを直したら、今度はWidgetが時間経過で「次のReminder」へ進まない。アプリを開き直さない限り古い表示のままだったので、次のReminder時刻にもWidgetを更新する予定を登録し、アプリ内表示も定期更新するようにした。
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には残っていた。
OFFとは。
Reduce Motionを含む共通gateを作り、設定をアプリ全体へ適用した。装飾が見えなくても操作結果は分かるようにしている。
売れるか見直した
2026年7月19日、一度実装を止めて、商業化の観点からプロダクト全体を監査した。
コード、UI、CloudKit、通知、AI送信、Privacy、Accessibility、価格、Support、App Store運用まで見た結果、レポートは約2,500行になった。
出てきたのは、派手な機能不足より、かなり地味で嫌な問題だった。
通常のQuick Addと外部AIへ送る入力の境界が分かりにくい。同期中、未ログイン、offline、errorの違いが見えない。通知登録に失敗しても成功したように見える。Export、Restore、全データ削除の仕様が弱い。オンボーディング、Privacy Policy、Support、配布方式、公開名も決まっていない。
CloudKit本番schema、2端末競合、実機Accessibility、signed archiveも未確認だった。
監査時のテストは249件中248件が成功し、Unit test bundleは通った。残ったのはQuick AddのUIテスト1件。
ただ、分かったのは、テストがkeyboard focusを確認せずtypeTextしようとしていたところまでだった。製品のautofocusが壊れているのか、テストの前提が間違っているのかは切り分けられていない。
ここで適当に待ち時間を足して緑にしても、何も証明したことにはならない。
結局、最初に売り物になるのはAIではなく、「もう選び直さなくていい」の方だった。
監査後の作業ツリーでは、Quick Addをタイトルだけ端末内へ保存する入口へ戻し、文章や写真のAI整理は別の明示操作へ分ける変更を進めていた。
同時に、「今やる」の条件を折りたたんで5分、15分、25分、60分から選べるようにし、一覧から任意のTaskを「今やる」に指定する変更も進めていた。選択中のTaskからメモや詳細を開く導線も、この途中だった。
ほかにも、オンボーディング、同期状態、通知失敗、JSON書き出し、全データ削除、外部AIの同意と送信内容を詰めていた。ZDR（データを保持しない経路指定）、端末内AI、OpenRouter、固定の代替ヒントをどういう順番で使うかも、この中に入る。
ただし、ここは未コミットの開発中変更を含む。実機、CloudKit、通知、Accessibility、Release archiveの検証はまだだった。
8月9日時点で、どこまでできたか
一般公開できる状態かと言われたら、まだだった。
まず、誰のどの瞬間を助けるのかを実際の利用者調査で確かめる必要がある。想定していたのは、やることはあるのに比較で止まり、必要なときだけ短く一件へ絞りたい人。ADHDの人全員に同じ解決策が効くとは考えない。
そのうえで、端末内だけでも、追加、一件への固定、終了、切り上げ、手放す、という流れを速く安心して使えるところまで仕上げる。AIはそのあとでもいい。
公開前に残っていた確認も多い。
- stable Xcodeでsigned archiveを作り、配布相当の環境で動かす。
- CloudKit本番schemaと2台の実機で、競合と復旧を確かめる。
- 通知、Widget、deep link、App Groupsを実機で通す。
- VoiceOver、Voice Control、Larger Text、Reduce Motionで主要操作を終えられるか確かめる。
- Export、Restore、Delete、Privacy、Supportの運用を決める。
- 外部AIへ送る内容、同意、ZDR、fallbackを画面の説明と一致させる。
収益化は「無期限で使えるlocal core＋買い切りPro」が、8月9日時点の最初の仮説だった。
継続費用のかかるAI subscriptionは、localや端末内AIより明確に価値があり、品質、Privacy、費用、Supportが成立すると分かってから考える。
測りたかったのは、アプリの滞在時間でも、登録したTask数でも、連続利用日数でもない。
迷って止まったとき、一件を決めるまでの時間が短くなったか。決めたあと、アプリを閉じて実際の行動へ戻れたか。
まだ公開名、配布、同期、Privacy、Support、実機品質、それに本当に人の役に立つかという検証が残っている。
ADHDManagerでやりたいのは、人生を管理することではない。迷って止まったときに一件だけ決めて、用が済んだらアプリを閉じられるようにすること。
タスク管理アプリなのに、長く使われない方が正解なのかもしれない。