Dayflow: 画面録画から作業日誌を自動生成するmacOSアプリの実力と境界

Dayflowが埋めようとしている穴は「どのアプリを使ったか」の先にある

既存の時間管理ツールの多くは、前面にあったアプリ名と滞在時間を記録する。READMEはこの限界を具体的に挙げている。Cursorを2時間開いていたとして、それが機能のリリース作業なのか、認証のデバッグなのか、プルリクエストのレビューなのか、環境構築で詰まっていたのかは、ウィンドウタイトルからは判別できない。Dayflowはこの区別を、画面の中身を解析して意味のある作業コンテキストに変換することで埋めようとしている。対象はmacOS 14以降を使い、タイマーの開始や作業メモの記述をせずに日々の記録を残したい人だ。とくに、日次スタンドアップや週次レビューのために記憶を頼りに報告を組み立てている開発者、そして画面履歴という機微なデータを扱うためプライバシー条件を重視する層を想定している。

画面チャンクから活動カードまでの流れ

READMEの機能表によれば、処理は段階的に進む。まず画面の軽量なチャンクをキャプチャし、それをユーザーが選んだAIプロバイダで解析し、その結果を活動カードとして日次のタイムラインに並べる。解析の入力は前面アプリの名前ではなく画面上の実際の内容であり、これによってChromeやSlack、YouTubeといったアプリの利用が、意味のある作業コンテキストとして扱われる。ここで重要なのは、解析エンジンが差し替え可能な設計だという点だ。ローカルモデルをOllamaまたはLM Studio経由で動かすか、Geminiを自分のAPIキーで使うか、ChatGPTやClaudeを各社のローカルCLIツール経由で呼ぶかを選べる。ローカルモデルを選べば解析はマシン上で完結し、クラウドを選べば解析に必要な活動データがその提供元へ送られる。この分岐がDayflowの設計上の中心であり、プライバシーと要約品質のトレードオフをユーザー自身が決める構造になっている。

保存先と削除の設計

録画、タイムライン、アプリのデータベースは、READMEによれば既定で ~/Library/Application Support/Dayflow/ に置かれる。画面履歴は機微な情報の塊なので、この保存先がローカルであること自体が採用理由になりうる。加えて、ストレージ上限を設定して古い録画を自動的に削除する仕組みが用意されているとREADMEは説明している。作業日誌としての価値を保ちながらディスクを圧迫し続けないための措置だが、この自動削除は録画に対して働くものであり、タイムラインやデータベースが同じように消えるかどうかはREADMEからは読み取れない。長期間の記録を検索可能な資産として残したい人は、削除対象の範囲を自分で確認する必要がある。また、ローカル保存はバックアップや複数マシン間の同期を提供するものではない。別のMacで同じ履歴を見たい場合、この構成では実現できない。

導入手順と必要な権限

配布はGitHub ReleasesのDayflow.dmgとHomebrewの2経路がある。Homebrewを使う場合は次の1行で導入できる。

brew install --cask dayflow

DMGの場合は開いてApplicationsへドラッグし、起動時にmacOSの画面収録およびシステムオーディオ録音の権限を求められたので許可する。この権限はDayflowの動作の前提であり、拒否すれば画面チャンクの取得自体が成立しない。要件はmacOS 14以降で、AIプロバイダは任意だ。GeminiのAPIキー、Ollama、LM Studio、Codex CLI、Claude Codeのいずれかを使う場合はそれぞれの準備が要る。ソースからビルドする場合はリポジトリをcloneし、Dayflow/Dayflow.xcodeproj をXcodeで開いてDayflowスキームを選択して実行する。一次言語はSwiftで、ビルド経路がXcodeプロジェクトとして提供されている点は、macOSネイティブのツールとして素直な構成だ。

画面収録権限という構造的な制約

Dayflowの仕組みは画面収録権限に依存している。これは機能の欠点というより、この種のツールが避けられない前提条件だ。組織の管理下にあるMacでは、MDMポリシーやセキュリティ設定によって画面収録権限が許可されない場合があり、その環境ではDayflowは動かない。個人のマシンでも、常時画面を記録される状態に抵抗がある人は少なくない。プライバシーを重視してローカルモデルを選んだとしても、記録そのものは行われているという事実は変わらない。また、画面の内容を解析する性質上、業務データや個人情報がタイムラインに取り込まれる可能性がある。ローカル保存と自動削除はリスクを下げるが、消すのはユーザー自身の操作だ。さらに、このアプリはmacOS専用であり、WindowsやLinuxの環境では選択肢にならない。クロスプラットフォームで活動を集約したい用途には根本的に合わない。

代替手段との設計思想の違い

代表的な比較対象はActivityWatchだ。ActivityWatchはウィンドウのタイトルやアクティブ時間といったメタデータを中心に記録し、画面の中身そのものをAIで解釈する設計ではない。どのアプリにどれだけ時間を使ったかという集計には強いが、Cursorの2時間が何だったのかという文脈は得られない。Dayflowは逆に、画面内容の解析にコストを払うことで文脈を得る。その代償として、画面収録権限、AIプロバイダの選択、解析コストまたはローカル推論の計算資源が必要になる。つまり両者は同じ土俵の競合ではなく、記録する対象の粒度が違う。アプリ使用時間の集計と請求や工数管理が目的ならActivityWatch系のメタデータ記録で足りる。作業内容の再構成やスタンドアップ用の要約が目的なら、Dayflowのアプローチに意味が出る。

チャットとエクスポートが示す出口の設計

Dayflowは記録して終わりではなく、記録を引き出す経路を複数用意している。自然言語で日・週・年の活動について質問し、タイムラインに基づいた回答を得るチャット機能、日次スタンドアップ用に前日のハイライトと今日のタスク、ブロッカーをまとめる機能、週次で集中時間やカテゴリ、アプリ使用、インタラクションのグラフを集計する機能がREADMEに列挙されている。加えて任意の期間をMarkdownとしてエクスポートできる。エクスポートは、Dayflowの外にデータを持ち出す唯一の明示的な経路であり、ステータス更新やクライアント向けメモ、個人の振り返りに使えるとされている。ツールにロックインされたくない人にとって、この出口があるかどうかは導入判断に効く。逆に言えば、Markdown以外の形式での連携やAPI経由の取り出しはREADMEには記載がない。

ライセンスと維持コストの見積もり

DayflowはMITライセンスで公開されている。この条件は、社内ツールへの組み込みや改変、再配布のハードルを低くする。ただしMITライセンスは無保証であり、動作の継続やサポートを約束するものではない。リポジトリはアーカイブされておらず、2026年9月9日時点でv2.4.2が最新リリースとして記録され、同日に最終プッシュがある。活発に見えるが、リリースノートの中身はこの材料からは確認できないため、アップグレードで何が変わったかは各リリースを自分で追う必要がある。維持コストで見落としやすいのは、AIプロバイダ側の変化だ。クラウドAPIの料金やモデル名、CLIツールの仕様はDayflowの外で動く。ローカルモデルを選んだ場合は、推論環境の更新とマシン資源が継続的なコストになる。MITライセンスであることは、これらの外部依存の面倒を見てくれるという意味ではない。

編集部の結論

毎日スタンドアップや週次レビューのために作業ログを手で書いているmacOS 14以降のユーザー、とくに画面内容を外部に出したくない人には候補になる。逆に、WindowsやLinuxを使う人、画面収録権限を常時与えたくない人、複数マシンの活動を1つのタイムラインに統合したい人には向かない。導入前に確認すべきは3点。macOS 14以降であること、~/Library/Application Support/Dayflow/ に蓄積される記録のサイズと自動削除の設定、そしてOllamaやLM Studioなどのローカルモデルで要約品質が自分の用途に足りるかどうかだ。クラウドAPIキーを設定した時点で、解析に必要な活動データはその提供元へ送られる。この境界を越えるかどうかが採用判断の分かれ目になる。

公式情報源

1. JerryZLiu/Dayflow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases