✍️ 필사 모드: 時間と生産性トラッキングツール 2026: Toggl・Clockify・Wakatime・RescueTime・Rize 徹底比較 — あなたの時間はどこへ消えているのか

「測定できないものは改善できない。そして、測定した全てが重要なわけでもない。」

プロローグ — 8 時間働いたのに 4 時間しか働いていない気がするのはなぜか

夜 7 時、パソコンを閉じようとして妙な感覚が走ります。たしかに朝 9 時から机に向かっていたのに、「今日つくったもの」と胸を張れる何かが思い浮かばない。Slack に返信、会議、PR レビュー、ちょっと Twitter、また PR、また Slack…。気づけば外は暗い。

これが 2026 年でも変わらない平凡な風景です。モニターは 2 枚に増え、AI アシスタントがコードの半分を書いてくれているのに、「ほんとうに働いた時間」の体感はむしろ減っている。

ここに対する答えは 2 つです。ひとつ、自分の手で時間を書き残す。 ふたつ、コンピュータに勝手に書かせる。 前者が Toggl と Clockify の世界、後者が Wakatime、RescueTime、Rize、Timing の世界。そしてこの記事の半分は、「どちらがより正直なのか」をめぐる議論です。

この記事で扱うツール:

章立て:

1 章 · 手動 vs 自動の永遠の論争

時間追跡の世界における最大の分岐点はここです。スタート/ストップボタンを手で押すのか、それともコンピュータに任せるのか。

手動追跡の美徳は「意識」です。 タイマーを押した瞬間、脳がコンテキストをつかみます。これから 30 分はこの仕事をする、という約束が背中を椅子に押し付けてくれます。そして終わったとき、「ところで本当にこの 30 分でその仕事をしたのか」と自問する習慣ができます。つまり追跡そのものが集中の道具です。Toggl が「まだ作業中ですか?」という通知を出すのも、この発想にもとづいています。

自動追跡の美徳は「正直さ」です。 手で書こうとすると人は自分に甘くなります。会議に入り、Twitter に流れ、また会議に戻ってきたのに、レポートには「会議 60 分」とだけ書いてある。自動追跡は、その全てのコンテキスト切り替えを容赦なく記録します。初週は衝撃が走ります。「自分はそんなに Slack を見ていたのか」と。

うまくやっている人はだいたい両方使います。 手動は請求とディープワーク振り返りに、自動は「一週間がどこへ流れたのかの全体像」に。後段のワークフロー章で組み合わせ方を扱います。

第三の選択肢もあります。半自動。 Toggl Desktop の autotrack や Timing のルールベース分類のように、コンピュータが候補を投げて人間がラベルだけ整える方式です。怠け者には自動、正直者には手動の良いところを組み合わせた形と言えます。

              正直さ ↑
                 |
       自動  ────|──── Rize.io / RescueTime
                 |
                 |   Wakatime (コードのみ)
                 |
                 |
       半自動 ───|──── Timing / Toggl Autotrack
                 |
                 |
       手動 ────|──── Toggl Track / Clockify / Hourglass
                 |
            意識 ←  →  便利さ

よくある誤解。自動追跡は「より良い道具」ではありません。 自動はデータをたくさん集めるだけ。そのデータをどう見るかが本当の価値です。なので良い自動追跡は良いレポートとコーチングを必ず備えます。

2 章 · Toggl Track — 手動追跡のクラシック

Toggl Track は 2006 年にエストニアで始まった会社で、時間追跡市場における「Google」のような位置を占めています。誰かが時間追跡を始めたいと言えば、まず推薦される名前です。

なぜクラシックなのか:

• スタート/ストップボタンが全プラットフォームにあります。Web、デスクトップ(Mac・Windows・Linux)、モバイル(iOS・Android)、ブラウザ拡張。
• エントリにプロジェクト、クライアント、タグ、請求可フラグを付けられます。
• レポートが本当にきれい。ドーナツチャート、棒グラフ、週次カレンダー — クライアントに送れる水準です。
• デスクトップアプリには autotrack と idle detection が組み込まれています。席を外している間タイマーが回っていれば、「この時間を外しますか?」と聞いてくれます。

価格(2026 年時点):

• Free: 5 人まで、基本追跡とレポート。個人で一生使うには十分。
• Starter: 1 ユーザーあたり月 10 ドル前後。請求、プロジェクトテンプレート、ソート済みレポート。
• Premium: 1 ユーザーあたり月 20 ドル前後。時給、優先サポート、監査ログ。
• Enterprise: 別途見積。SSO、カスタム契約。

Toggl が輝く場面:

• フリーランスの時間給請求。クライアントに送る PDF レポートが整っています。
• 一人コンサル。5 人まで無料の方針で永久無料運用が可能。
• 小さなチームの使用分析。誰がどのプロジェクトにいくら使ったかを即座に。

Toggl の弱点:

• 「時間がどこから漏れているか」を知りたいとき。自動機能はおまけで、RescueTime や Rize に大きく劣ります。
• 言語別・プロジェクト別の開発者向け自動集計。これは Wakatime の領分。
• 大規模チームの人事評価向け。Toggl は「従業員監視」を積極的に拒否しています。これは美徳ですが、その用途なら他のツールを見るべきです。

ひとこと: 手動追跡という枠で最も信頼できる標準。迷ったらまずここから始めましょう。

3 章 · Clockify — 真面目な無料代替

Clockify はセルビアの CAKE.com が作ったツールで、「永久無料」を旗印に市場へ入ってきました。最初は「Toggl のコピー」と言われていましたが、2020 年代を通じて独自色を持つ本格的な競合に成長しました。

Clockify の差別点:

• 無制限ユーザーの無料プラン。Toggl が 5 人までなのに対し、Clockify は 100 人のチームすら無料で動かせます。代理店が愛用する理由。
• スクリーンショット自動取得、非活動検出、強制スタート/ストップなど、監視機能 を積極的に搭載。美徳か悪徳かは会社の文化次第。
• シンプルな請求・見積モジュール内蔵。
• セルフホスト可能な数少ないメジャー製品(Enterprise 専用)。

価格(2026 年時点):

• Free: 無制限ユーザー、基本追跡。
• Basic: 1 ユーザーあたり月 4 ドル前後。請求可時間、プロジェクトテンプレート。
• Standard: 1 ユーザーあたり月 6 ドル前後。インボイス、時間承認。
• Pro: 1 ユーザーあたり月 9 ドル前後。スクリーンショット、活動追跡、自動ロック。
• Enterprise: 1 ユーザーあたり月 15 ドル前後。SSO、監査、セルフホスト。

Clockify が勝つ場面:

• 30 から 100 人規模の代理店。Toggl なら月数百ドルが、Clockify なら無料か激安。
• 従業員の時間をインボイスに正確に対応させる必要のある時給制ビジネス。
• セルフホストが必要なセキュリティ重視組織。

Clockify の弱点:

• 自動追跡の深さ。RescueTime や Rize と比べると活動追跡は単純です。
• デザイン。Toggl の方が美的に一段上というのが一般的評価。

ひとこと: Toggl が高いなら Clockify が答えです。100 人のチームが無料で動くという一点で多くの欠点が許されます。

4 章 · Wakatime — 開発者向けの自動追跡

Wakatime は 2013 年に Alan Hamlett が一人で始めたツールです。現在は数万人の開発者が毎日データを送る、事実上の標準です。

動作の仕組み:

• IDE プラグインを入れます(VS Code、JetBrains、Vim、Emacs、Neovim、Sublime、Xcode、Android Studio など 60 以上)。
• プラグインがキーストロークの活動、ファイル、言語、プロジェクトを検知して Wakatime のサーバーに送信。
• ダッシュボードで「今日 8 時間コーディング、内 Python 4 時間、TypeScript 3 時間、議事録のマークダウン 1 時間」のように自動集計されます。

愛される理由:

• 本当に「タダで」書き残してくれる道具です。忘れて生活していても、1 か月後にダッシュボードを開けばデータが積み上がっています。
• プロジェクト別・言語別・時間帯別の統計が自動で出ます。
• GitHub README にウィジェットとして貼り付けられる。「今年 Rust に 487 時間使った」みたいな自慢ができる。
• チーム機能で誰がどのコードベースにどれだけ触れているか見えます。ただし人事評価には使わないこと(プライバシー章参照)。

価格(2026 年時点):

• Free: 直近 14 日の統計。
• Basic: 月 9 ドル前後。フル履歴。
• Premium: 月 14 ドル前後。詳細分析、外部連携。
• 学生は無料。

Wakatime が勝つ場面:

• 自分のコーディング時間を客観的に見たい開発者。
• 「今年いちばん使った言語は何か」みたいな振り返り。
• OSS メンテナ — スポンサーに無償労働時間を見せるとき。

Wakatime の弱点:

• コーディング外の時間。会議、デザイン、リサーチは捕捉されません。
• コンテキスト理解。同じ IDE 内の「本当に働いている時間」と「ファイルを開いたまま Twitter を見ている時間」が区別されない。

オープンデータ文化: Wakatime の大きな魅力のひとつは、多くの開発者が自分の統計を公開している点です。GitHub プロフィールに貼ったウィジェット、「今週のコーディング時間」のツイート、ブログサイドバーのライブ統計。これらが一種の同調圧力かつ責任感の道具として機能します。

ひとこと: 開発者ならとりあえず入れておきましょう。送信するデータを止めたり減らしたりもできるので、まず 1 か月集めてから取捨選択を判断してください。

5 章 · Codetime と Pulse for VS Code — Wakatime のライバル

Wakatime の成功を見て、似たアプローチが複数登場しました。

Codetime(Software.com)

• VS Code 中心で始まり、JetBrains、Atom などへ拡大。
• 音楽連携(Spotify と組み合わせて「何を聴きながら何を作っていたか」を可視化)が差別点。
• 無料、広告なし。ビジネスモデルがどう成立しているかが常に話題。

Pulse for VS Code

• VS Code 専用の軽量ローカル追跡。
• データがクラウドへ送られないオプション — プライバシー優先。
• GitHub の草のような日次ヒートマップ。

Wakatime vs Codetime vs Pulse の選び方:

無難な出発点は依然として Wakatime。例外は「自分のデータがどこにあるかを 100% コントロールしたい」場合 — その時は Pulse です。

6 章 · RescueTime と Rize.io — すべてを見る自動追跡

コーディング以外の時間も見たいならこのカテゴリ。バックグラウンドで「いまどのアプリのどのウィンドウにいるか」を記録します。

6.1 RescueTime — 元祖

2008 年に登場。PC 時代からこの仕事をしてきたツールです。

• カテゴリ: 「ソフトウェア開発」「コミュニケーションとスケジュール」「エンタメ」などに自動分類。
• 生産性スコア -2(非常に非生産的)から +2(非常に生産的)をカテゴリ毎に付けます。ユーザーが調整可。
• 「FocusTime」という集中モード — 非生産サイトをブロック。
• 価格: Lite 無料、Premium 月 12 ドル前後。

長所: 歴史が長くデータベースが巨大。たいていのアプリやサイトは既に分類済み。 短所: UI に 2014 年の匂いが強い。レポートは時代感あり。

6.2 Rize.io — 新顔

2021 年ごろ登場し、2023-2025 年に急成長したツール。RescueTime の精神的後継と評されます。

• よりクリーンな macOS ネイティブ UI。
• ディープワーク測定に焦点 — 同じアプリに留まっていた連続時間ブロックを強調。
• コンテキスト切り替え回数をカウント — 1 日 200 回切り替えていればそのまま表示。
• 「Notifications」コーチング — 会議が長すぎる日に「休憩しませんか?」のようなナッジ。
• 価格: 月 10 から 15 ドル前後。

長所: デザインが本当に良い。データを見たくなる作り。ディープワークというコンセプトに焦点を当てたのも差別点。 短所: 比較的新しいので分類完成度は RescueTime ほどではない。macOS 優先なので、Windows / Linux ユーザーには合いません。

6.3 RescueTime vs Rize.io

ひとこと: Windows / Linux なら RescueTime、Mac なら Rize もしくは Timing を先に試しましょう。

7 章 · Timing — Mac ユーザーのルールベース自動化

Timing はドイツの一人開発者 Daniel Alm が作る macOS 専用の自動追跡ツール。最大の特徴は、データが全てローカルに留まり、クラウドを経由しないことです。

動作の仕組み:

• アプリ、ドキュメント、URL を自動記録。
• ユーザーが「このドメインは work、このアプリは design、このフォルダのファイルはクライアント A のプロジェクト」のようなルールを書きます。
• 一度ルールを書いておけば、以降のデータは自動分類されます。

良い理由:

• データが外に出ません。NDA や守秘契約のある現場でも使えます。
• ルール言語の表現力が高い。URL マッチ、正規表現、フォルダパス — 真面目な追跡者にはどこまでも深い。
• iCal とつないで「会議に確保した時間 vs 実際に会議に居た時間」を比較できます。

価格(2026 年時点):

• 買い切りとサブスクの両方を提供。
• Productivity 月 9 ドル前後、または年 70 ドル前後。
• Professional 月 12 ドル前後、または年 100 ドル前後。
• 30 日の無料トライアルが太っ腹。

Timing が勝つ場面:

• 1 台の Mac で全てを完結させる単独ユーザー。
• プライバシー要求の厳しい現場(弁護士、医療、政府、コンサル)。
• ルールを書く時間を惜しまない精密追跡派。

限界:

• Mac のみ。Windows / Linux / モバイルなし。
• ルールを書く意思がないと真価の半分も発揮できません。

ひとこと: Mac ユーザーでプライバシーが大事なら第一候補。データをクラウドへ送りたくない人たちの安全基地です。

8 章 · TickTick・Things 3・Hourglass — タスクと時間の結合

純粋な時間追跡ではなく、「やること + 時間」をひとつに結ぶカテゴリも存在します。

TickTick

• ToDo アプリ + ポモドーロタイマー + カレンダー連携。
• タスクの横の時計アイコンを押すと 25 分タイマー。終了すると自動的にそのタスクへ時間が積み上がります。
• 価格: 無料 / プレミアム月 3 から 4 ドル前後。

Things 3

• macOS / iOS 限定の優雅な ToDo アプリ。
• 時間追跡自体は弱いものの、他の追跡アプリとの相性は良好。
• 買い切り — Mac 約 50 ドル、iOS 約 10 ドル、iPad 約 20 ドル。サブスクなし。

Hourglass

• 単一機能のツール。スタートでタイマーが回り、ストップで終わる。
• レポートも請求もなし。
• 無料か激安。
• 「タイマー以外はいらない」というミニマリスト向け。

組み合わせの例:

• Things 3 でタスク管理 + Toggl Track で請求可時間。
• TickTick ひとつで両方(ただし請求とレポートは弱い)。
• Hourglass + 紙のノート — 最低予算の組み合わせ。

9 章 · Cosmos と AI 時代の「Granola for time」

2024-2025 年に新しく登場したツールで興味深いのが Cosmos です。会議自動要約ツール Granola の時間追跡版と評されます。

Cosmos のコンセプト:

• 活動を自動記録(RescueTime / Rize と類似)。
• その上に AI が毎晩「今日 1 日」を要約。「午前はコードレビュー 3 時間、午後は会議 4 件と PR 2 件、18 時以降 Twitter 47 分」のような形。
• 自然言語検索。「先週火曜の ABC プロジェクトにいくら使った?」と質問できます。
• カレンダー連携。会議ブロックと実滞在時間が並べて見えます。

興味深い理由:

• データ収集は RescueTime 時代に解かれた問題です。
• 本当に難しいのはそのデータから「で、何をするか」を導くことで、LLM がそれを初めて自然に解き始めています。

注意点:

• 新しいツールなので、会社の継続性とプライバシーポリシーの安定性は未知数。
• AI 要約はハルシネーションを起こします。「ABC に 5 時間」が実は 3 時間ということがあり得る — 必ず元データを確認すること。
• 市場の動きが速い。1 年後 Cosmos の席に別の名前があるかもしれませんし、Rize / RescueTime が AI レイヤを吸収しているかもしれません。

ひとこと: アーリーアダプターが試す価値あり。メインはまだ RescueTime か Rize に置き、Cosmos は補助として 1 四半期ほど回してみる、くらいが妥当です。

10 章 · プライバシーの現実チェック

自動追跡は本質的に監視ツールです。99% は自分が自分を監視しているだけですが、残り 1% — 会社が従業員を監視するケース — が常に影のように付いて回ります。

個人利用時のチェックリスト:

1. どのデータを集めるか。 キーストローク? アクティブウィンドウ? マウス位置? スクリーンショット? ツール毎に異なります。
2. データはどこへ行くか。 ローカル? ベンダーのクラウド? 米国・EU・その他?
3. 誰が見るか。 自分だけ? マネージャーも? チームメンバーも?
4. 削除できるか。 1 か月前の誤追跡データを消せる必要があります。

ツール別の一般的な答え:

会社が強制してきたとき:

• スクリーンショット・キーストロークを強制するツールは、労働権の観点から問題視されつつあります。国や州によっては事前同意・通知が必須です。
• 個人ノート PC なら、本人の同意なしに追跡ソフトを強制できません。
• 会社支給 PC では会社方針が優先されるのが普通ですが、監視範囲は雇用契約・社内方針に明示されるべきです。

特に開発者にとって重要なこと:

• Wakatime はデフォルトでファイル名とプロジェクト名をクラウドへ送ります。これがクライアントの NDA 違反になり得ます。プロジェクト単位で追跡を切るか、セルフホストするか、匿名化オプションを有効化しましょう。

11 章 · 実戦ワークフロー — フリーランス・ディープワーク・ADHD

ツールはあくまで道具で、本当の価値はワークフローに宿ります。代表的な 3 シナリオ。

11.1 フリーランス: 時間からインボイスへ

構成: Toggl Track + カレンダー。

ワークフロー:

1. 新規クライアントが来たら Toggl にクライアントとプロジェクトを作成。
2. 作業前にタイマーを押す。説明欄に「PR レビュー - 認証モジュール」のような一行を入れる。
3. 席を外すときに止める。Toggl Desktop の idle detection がよく助けてくれます。
4. 月末に Toggl のレポート → CSV / PDF エクスポート。請求可時間だけ自動フィルタ。
5. インボイスツール(Hopper、Bonsai、または Google Sheets)に貼り、クライアントへ送信。

見落としやすい点:

• 返信メールや見積書作成も請求可時間になり得ます。抜かさないこと。
• 会議準備時間が請求可かどうかを契約書に明示。
• 複数クライアントを同時に抱えるなら、コンテキスト切替コストをどこかに割り振るべきです。

11.2 ディープワーク測定: 本当に集中したのは何時間か

構成: Rize.io(または RescueTime) + 手書きメモ。

ワークフロー:

1. 毎朝「今日深くやる 3 件」を紙に書く。
2. Rize / RescueTime はバックグラウンドで全活動を自動記録。
3. 昼と夕方の 2 回、Rize ダッシュボードで「午前のディープワークブロック」が何分だったか確認。
4. 週次振り返り — 「今週のディープワーク総量 12 時間、先週は 18 時間。何が違った?」

現実的な期待値:

• 平均的な開発者の 1 日のディープワーク時間は 2 から 4 時間あれば良い方。8 時間はほぼ不可能。
• 会議が 4 から 5 件入る日は、ディープワークは 0 に近い。
• このデータを誰に見せるかには慎重に。自己振り返り用であって、上司への報告用ではありません。

11.3 ADHD への対処: コンテキスト切替を可視化する

ADHD のある開発者にとって、時間追跡の最大の価値は請求ではなく 自己認識 です。

構成: Wakatime + Rize + 手書き日記。

なぜ役立つか:

• Wakatime がコーディング時間、Rize が全体時間を捉える。
• コンテキスト切替回数が「自分の脳がどれくらい散らばっていたか」の客観指標になる。
• 「今日 47 回切り替えた、昨日は 23 回。何が違った?」と自問できる。
• 薬、睡眠、カフェイン、会議密度と切替回数の相関が、1 か月後に見えてきます。

コツ:

• 自己責めの道具にしないこと。ADHD の脳は「47 回」を見て「私はもう駄目だ」へ走りがち。あのデータは システムデバッグの道具 であって、人格判定の道具ではありません。
• 分析しすぎないこと。週 1 回 30 分の振り返りで十分。分析で仕事ができなくなれば本末転倒です。

12 章 · コスト要約と意思決定フレーム

2026 年時点の代表価格を一行で:

意思決定フロー:

1. あなたは誰?

   • フリーランス / コンサル → 請求可時間が肝 → Toggl か Clockify。
   • フルタイム開発者 → 自己振り返りが肝 → Wakatime、加えて任意で Rize / RescueTime。
   • チームリード → チーム生産性指標 → Clockify(低予算)か Toggl(高品質)。
   • デザイナー / 一般オフィスワーカー → Rize.io か RescueTime。

2. 手動か自動か?

   • 意識的な追跡が必要 → 手動(Toggl・Clockify・Hourglass)。
   • 正直なデータが必要 → 自動(Wakatime・RescueTime・Rize・Timing)。
   • 両方 → 組み合わせ。

3. プライバシー感度?

   • 非常に敏感 → Timing(ローカル)、またはセルフホストの Clockify・Wakatime。
   • 普通 → クラウドツールいずれも OK。
   • 会社強制 → まず契約を確認。

4. OS は?

   • Mac のみ → Timing か Rize。
   • Windows / Linux / 混在 → RescueTime、Wakatime、Toggl、Clockify。
   • モバイル含む → Toggl か Clockify。

エピローグ — 何を測るかを決めてから測れ

時間追跡は結局のところ、自分との対話だ。
ツールは答えをくれない。
ツールはより良い問いを投げるためのデータをくれるだけだ。

今日の 8 時間のうち、本当の仕事は何分だったか。
その会議は本当に必要だったか。
コンテキスト切替を強いたのは誰か。
ディープワークはいつ可能だったか。

答えが現れるのではなく
問いがだんだん鋭くなる。
それが良い追跡だ。

開始チェックリスト

• 1 つのツールで開始し、最低 2 週間は毎日使う。
• 最初の 1 週間は分析しない。データだけ集める。
• 2 週間後に最初の振り返り。「想定と最も違う部分」を探す。
• 1 か月後、合わないなら未練なく乗り換える。
• 時間追跡そのものに 1 日 30 分以上は使わない — 本末転倒です。

よくあるアンチパターン

• 「完璧な分類」に執着する — 80% 正しければ十分。
• タイマー付けっぱなしで寝てしまい 8 時間「作業」が記録される。
• データを自己鞭打ちの道具に使う。
• チームメンバーに数値を強制開示させる。
• 1 週間に 3 回もツールを乗り換える。

次回予告

次回は、追跡の成果を活かす方法を扱います。週次振り返りテンプレート、週 30 分で終わる PPP(Progress / Plans / Problems)の書き方、会議時間を 50% 削るカレンダー交渉術 — データが揃った後に何ができるかの実戦編です。

参考 / References

• Toggl Track 公式: https://toggl.com/track/
• Clockify 公式: https://clockify.me/
• Wakatime 公式: https://wakatime.com/
• RescueTime 公式: https://www.rescuetime.com/
• Rize.io 公式: https://rize.io/
• Timing (macOS) 公式: https://timingapp.com/
• TickTick 公式: https://ticktick.com/
• Things 3 公式: https://culturedcode.com/things/
• Codetime by Software.com: https://www.software.com/
• Pulse for VS Code: VS Code Marketplace で「Pulse time tracking」を検索。
• Cal Newport「Deep Work」 — ディープワーク概念の原典。
• Anders Ericsson「Peak」 — 意図的な訓練と測定の科学。
• 「How to Track Your Time as a Developer」 — 開発者時間追跡ワークフローの集成。