Philosophy（設計思想）

Yarukoto / Peak Log / ツケカン / Stockee / Launchpad ——個人開発として作っているこれらのアプリ群には、共通する考え方がある。このページではその土台にある思想をまとめている。新しいアプリを作るときも、機能の追加や UI を直すときも、迷ったらここに立ち戻る。

---

1. なぜ作るのか（目的）

人間は忘れる。日々起きていること、考えたこと、やったこと、感じたこと——その大半は記録しなければ流れ去ってしまう。

このアプリ群が解こうとしているのは、シンプルに2つの問題である。

• 忘れたくないことを、忘れずに済むようにする
• 記録したものに、見たいときアクセスできるようにする

2. 何を記録するのか（対象）

記録対象は「自分という存在の総体」。

やるべきこと（Yarukoto）、感じたピーク体験（Peak Log）、貸し借り（ツケカン）、家の在庫（Stockee）——テーマは様々だが、どれも「自分」というひとつの存在の異なる側面である。アプリ群全体で、その総体を捉えようとしている。

3. アプリの役割（スコープ）

このアプリ群の主軸は 「記録する側」 にある。

データさえあれば、閲覧・分析・エクスポートは他の手段でもできる。しかし**「記録する」という行為だけは、その場でアプリがなければ成立しない**。だからアプリは記録の入口として最適化される。

ただし、閲覧・集計を切り捨てるわけではない。記録の価値は3つの層で同時に成立する。

• 記録した瞬間に: 書く行為そのものが脳内整理になる（タスクを言語化する、感情を書き出す）
• 思い出したいときに: 忘れた情報を外部記憶として参照できる
• 時間が経ってから: 1年後・2年後に振り返って楽しむ、集計・統計で俯瞰する

記録は「過去のため」だけでなく、将来の自分への贈り物でもある。

4. 記録の設計思想

4.1 分類はユーザーが手動で行う

自動分類には頼らない。分類はユーザー自身の手で行う。

ただしこれは「面倒を強いる」ことではない。逆である——白紙のメモ帳や ToDo リストに自由に書くより、最初から適切なカテゴリが用意されている方が、むしろ書きやすい。分類はユーザーへの負担ではなく、思考のガイドレールとして機能する。

Yarukoto でカテゴリをユーザーが手で作って仕分ける設計、Peak Log でピーク体験のタイプを選ばせる設計は、すべてこの考えに基づいている。

4.2 手軽さと情報量の両立

「手軽に記録できる」ことと「価値ある情報量を確保する」ことは、一見トレードオフに見えるが、両立を諦めない。

• 最低限の手軽さは常に保証する（書く意欲を削がない）
• 同時に、価値ある記録になるだけの情報を自然に埋められる UI を設計する
• 衝突したときの優先は文脈次第だが、理想は 「手軽にやればデータがちゃんと揃う」状態を UI で実現すること

分類選択肢を事前に設計しておくのは、この両立の具体的な手段のひとつ。「選ぶだけ」で構造化された記録が完成する。

5. アクセスの設計思想

記録したものは、見たいときに見たい情報へ辿り着けるようにする。

• 適切な検索条件
• アクセスしやすい導線
• 目的の情報まで最短で届くナビゲーション

ここでも、記録するときの「分類」が効いてくる。手動で仕分けたからこそ、後から効率的に探せる。入口の設計と出口の設計は地続きである。

6. アプリ群としての構造

アプリは1テーマ1アプリに分かれている。これは強い思想ではなく、作りたいものがそうなっているだけ——だが結果として、各アプリは特定テーマに最適化された記録器として独立できる。

一方で、横断的な統合は明確な思想として持っている。

• 各アプリは独立した記録器として存在する（Yarukoto はタスク、Peak Log はピーク体験、というように）
• その上に、複数アプリのデータを横断する統合レイヤーを別途置く（実装例: furikaeri-mcp）
• AI に渡して振り返りを生成する、その日にやるべきことを束ねる、といった統合は積極的に追求する

つまり、「記録は分散、振り返りは統合」 という二層構造で「自分という存在の総体」を扱う。

7. 設計判断のチェックリスト

機能や UI を決めるとき、以下に立ち戻る。

1. これは記録のしやすさに貢献するか？（入口）
2. これは見たい情報へのアクセスしやすさに貢献するか？（出口）
3. ユーザーが手動で仕分けることを支えているか、邪魔していないか？
4. 手軽さと情報量を両立させているか、片方を犠牲にしていないか？
5. 単独アプリの最適化と、横断統合の余地、両方を視野に入れているか？