本项目为中文项目，日语UI由AI翻译而来。

課題設定

AI日報アシスタントは、日々の作業を自動で記録し、あとから復盤しやすい時間軸に整理し、最終的に日報・週報・月報として出力するデスクトップ助手です。

作業中に何度も手動で打刻したり、退勤前にチャット履歴、ブラウザ履歴、ドキュメント、会議メモを探し回ったりする必要を減らすことを狙っています。必要な権限を許可し、記録をオンにしておけば、アプリは設定された間隔で作業コンテキストを取得し、AI が「何をしていたか」を要約・分類します。

最終的に残るのは、単なるスクリーンショットの山ではありません。編集できる時間線、分類された作業ログ、アプリ利用統計、ヒートマップ、そしてレポート生成に使える作業記憶です。

今日の作業ダッシュボード
今日の作業：記録件数、集中時間、アクティブ時間帯、詳細記録を一覧できます。

設計目標：思い出す、復盤する、報告する

思い出す負担を減らす

日報を書くときの負担は、「文章を書くこと」よりも「今日やったことを思い出すこと」にあります。AI日報アシスタントは、作業中の断片を自動で記録し、時間順に残します。これにより、退勤前にチャット、ドキュメント、ブラウザ履歴を何度も見返す時間を減らせます。

復盤しやすい記録に変える

作業は 1 日の中で細かく分散します。タイムライン、カテゴリ分布、時間帯ヒートマップ、アプリ統計を組み合わせることで、どの時間帯に何をしていたか、どのカテゴリに時間を使ったか、作業リズムがどう変化したかを確認できます。

報告の初稿を早く作る

記録済みの作業ログをもとに、日報、週報、月報を生成できます。テンプレートや追加要求を指定すれば、標準的な報告、簡潔な報告、技術向け報告、OKR 向けの整理など、用途に合わせた初稿を作成しやすくなります。

利用シーン

このツールは、毎日または定期的に作業報告を求められる人に向いています。

ユーザータイプ典型的な場面得られる価値
毎日 日報を書く人退勤前に進捗、問題、明日の予定を整理する実際の作業断片から報告を作るため、漏れと書き起こし時間を減らせる
開発、プロダクト、デザイン、運用などの知識労働者IDE、資料、会議、ブラウザ、チャットを行き来する分散した作業を連続した時間線として見直せる
管理者、プロジェクト責任者メンバーの進捗やタスク状況を把握したいレポートや集計により、進捗の透明性を高められる
フリーランス、コンサルタント、リモートワーカー作業量、成果、顧客別の進捗を説明するエクスポート可能な作業証跡と振り返り資料を作れる
個人の作業記憶を作りたい人自分の時間の使い方を把握したいアプリ統計、ヒートマップ、過去レポートから長期的な傾向を見られる

基本フロー

日常利用では、ユーザーが毎回細かく入力する必要はありません。

1. 記録を開始する
  -> 必要な権限を許可し、バックグラウンド記録をオンにする

2. 時間線が形成される
  -> 作業片が時刻、カテゴリ、摘要、ソース付きで保存される

3. 復盤する
  -> 分類分布、ヒートマップ、アプリ統計から投入状況を見る

4. レポートを生成する
  -> 日報、週報、月報テンプレートを選び、AI が初稿を作る

5. 必要に応じて編集・共有する
  -> Markdown、テキスト、JSON などで出力する

理想的な使い方はシンプルです。朝にアプリを起動し、日中は普通に作業し、退勤前にレポート画面を開く。中間の記録、分類、初稿生成はできるだけ自動化しつつ、最終的な編集権限はユーザーに残します。

全体像：記録、認識、可視化、レポート化

このツールの構成は、大きく 4 つのレイヤーに分けられます。

作業状態の取得
  -> アプリ名、ウィンドウタイトル、スクリーンショットを取得

AI による認識
  -> 画面内容から作業内容を要約し、分類する

作業ログの可視化
  -> タイムライン、ヒートマップ、アプリ統計として表示する

レポート生成
  -> 日報、週報、月報として Markdown 形式に整理する

トップ画面では、当日の記録件数、集中時間、アクティブ時間帯がすぐに確認できます。作業の全体量と時間帯の偏りを把握するための入口として設計されています。

この画面のポイントは、単に「何時間作業したか」ではなく、「どの時間帯に作業が発生したか」を同時に見せていることです。これにより、集中していた時間帯、空白時間、作業の山を直感的に確認できます。

作業タイムライン：低レベルログを意味のある作業記録へ

作業タイムラインは、このシステムの中核です。日付範囲や直近 30 分、直近 1 時間、今日といった条件で、記録された作業を時系列に確認できます。

作業タイムライン画面
作業タイムライン：分類別の時間分布と時系列ログをまとめて確認します。

技術的には、タイムラインは単なる一覧表示ではありません。各レコードには、少なくとも次のような情報が必要になります。

  • 記録時刻
  • アクティブなアプリケーション
  • ウィンドウタイトル
  • AI が生成した作業要約
  • 作業カテゴリ
  • 集中時間または継続時間
  • 認識に使ったコンテキスト

画面上では分類別の時間分布も表示されており、単発のログだけでなく、作業全体の傾向を把握できるようになっています。

この種の機能を安定して動かすには、記録処理と AI 認識処理を分離する設計が重要です。まずアプリ名とウィンドウタイトルだけで基礎ログを保存し、その後にスクリーンショット認識や AI 要約を非同期で追加する構成にすると、AI API の遅延や失敗があっても作業ログ自体は失われません。

時間帯ヒートマップ：作業リズムを可視化する

時間帯ヒートマップは、日別・時間帯別に作業量を可視化する画面です。

時間帯ヒートマップ画面
時間帯ヒートマップ：日別・時間帯別の作業量を色の濃淡で確認できます。

この画面では、作業がどの時間帯に集中しているか、どの日にどれくらい記録があるかを確認できます。単純な合計時間では見えにくい「作業リズム」を把握できる点が特徴です。

実装上は、活動ログを時間単位で集計し、以下のような指標を作ると扱いやすくなります。

  • 記録件数
  • 推定作業分数
  • アクティブだった日数
  • 1 日あたりの平均記録量
  • 時間帯ごとの集中度

ヒートマップでは、記録件数を色の濃淡で表す方法と、作業分数を色の濃淡で表す方法があります。記録件数は細かい操作の密度を把握しやすく、作業分数は実際の投入時間を把握しやすいという違いがあります。

アプリ記録：アプリ利用から作業文脈を読む

アプリ記録画面では、どのアプリをどれくらい使ったかを確認できます。

アプリ記録画面
アプリ記録：アプリごとの利用時間や利用傾向を確認する画面です。

アプリ利用統計は、作業内容を推定するうえで重要な補助情報です。たとえば、ブラウザだけでは用途が広すぎますが、ブラウザ、エディタ、ターミナル、チャットツールの組み合わせを見ると、開発、調査、連絡、資料作成などの文脈が見えてきます。

ただし、アプリ名だけで作業カテゴリを決めるのは危険です。同じブラウザでも、技術調査、メール確認、動画視聴、管理画面操作など用途は大きく異なります。そのため、実装では以下のような多段判定が適しています。

アプリ名による初期分類
  -> ウィンドウタイトルによる補正
  -> スクリーンショット AI 認識による意味理解
  -> ユーザー定義ルールによる最終調整

この設計により、ルールベースの安定性と AI の柔軟性を両立できます。

レポート生成：作業ログを提出可能な文章に変換する

レポート生成機能では、記録済みの作業ログから日報、週報、月報を作成できます。AI に全ログをそのまま渡して長文を書かせるだけでは安定しないため、より堅牢な構成は次の 2 段階です。

AI日報アシスタントのレポート生成画面
レポート生成画面。対象期間、テンプレート、生成ボタン、プレビュー領域をまとめて確認できます。
活動ログ
  -> 事実ベースの構造化サマリー
  -> 日報・週報として自然文に整形

最初に、作業内容、時間帯、カテゴリ、主要アプリ、継続タスクを構造化します。その後、AI に文章化を任せます。こうすることで、AI が存在しない成果を作り出すリスクを抑えられます。

過去レポート：生成結果を再利用可能なナレッジにする

過去レポート画面では、生成済みの日報や週報を一覧できます。

過去レポート一覧画面
過去レポート：日報、週報、月報を対象期間や種別で探せます。

レポートは一度生成して終わりではなく、あとから振り返るためのナレッジになります。そのため、保存時には本文だけでなく、以下のメタデータも残しておくと便利です。

  • レポート種別
  • 対象期間
  • 生成日時
  • 使用したモデル
  • 元になった作業記録数
  • レポート本文の Markdown
レポート詳細モーダル
レポート詳細：生成された本文をモーダルで確認できます。

このように、日々の作業ログをレポートとして蓄積していくと、週次レビューや月次振り返りにも転用できます。

Agent 連携：作業記録を外部自動化へ開く

Agent 連携画面では、ローカル HTTP 経由で外部ツールと接続する構成が示されています。

Agent 連携画面
Agent 連携：ローカル HTTP 経由で外部ツールや AI Agent が作業記録を参照できる構成です。

この機能は、作業記録を人間だけでなく、他の自動化ツールや AI Agent から利用できるようにするためのものです。たとえば、次のような API が考えられます。

GET  /api/activities
GET  /api/summary/today
POST /api/reports
GET  /api/reports/{id}

ただし、作業ログには個人情報や業務情報が含まれる可能性があります。そのため、Agent 連携はデフォルトで 127.0.0.1 のみに限定し、外部ネットワークに開放しない設計が望ましいです。書き込み操作やレポート生成操作には、ローカルトークンによる保護を入れるべきです。

今後の拡張余地

作業ログが蓄積されると、日報生成だけでなく、タスク管理、利用継続のフィードバック、外部 AI での再整理にも広げられます。ただし、これらはデータ共有やアカウント連携を伴いやすいため、基本機能とは分けて設計する必要があります。

タスク管理との接続

作業記録から次のアクションを抽出し、未開始、進行中、完了、期限超過、アーカイブなどの状態で管理する構想です。看板、ガント、優先度、プロジェクト、タグ、担当者、添付ファイルまで扱えると、個人の作業記録からチームの実行管理へ広げられます。

ランキングと勲章

連続利用、レポート生成、記録蓄積などを可視化することで、長期利用のモチベーションを作れます。ただし、ランキングは同期データと個人プロフィールの扱いが関係するため、ユーザーの明示的な同意が前提です。

外部 AI プラットフォーム加工

時間線やレポートを DeepSeek、豆包、腾讯元宝、ChatGPT などへ渡し、追加質問や二次整理に使う流れも考えられます。これは便利ですが、データが外部サービスへ送られるため、送信前の確認と脱敏が必要です。

設定画面：自動記録を安全に制御する

設定画面では、言語、外観、自動起動、自動記録、スクリーンショット間隔、自動一時停止などを設定できます。

設定画面
設定：自動記録、スクリーンショット、通知、除外アプリなどを制御する画面です。

自動記録型ツールでは、設定画面は単なる補助機能ではありません。プライバシーと使い勝手を左右する重要な制御面です。

  • 自動記録をオンにするか
  • スクリーンショットを保存するか
  • どの間隔で画面を取得するか
  • アイドル時に記録を止めるか
  • 通知を使うか
  • 除外アプリを設定するか

スクリーンショット保存は便利ですが、機密情報を残すリスクもあります。そのため、基本方針としては「AI 認識には使うが、元画像は保存しない」設定をデフォルトにするのが安全です。

AI モデル設定：OpenAI 互換 API を差し替え可能にする

AI モデル設定画面では、API エンドポイント、API Key、スクリーンショット分析モデル、レポート生成モデルを指定できます。

AI モデル設定画面
AI モデル設定：スクリーンショット分析モデルとレポート生成モデルを切り替えられます。

この設計の利点は、特定の AI ベンダーに固定されないことです。OpenAI 互換 API に対応していれば、ユーザーは用途やコストに応じてモデルを切り替えられます。

AIConfig
  - base_url
  - api_key
  - recognition_model
  - report_model

AIClient
  - recognize_screenshot()
  - generate_report()
  - test_connection()

重要なのは、API Key をログに出さないことです。接続テストやエラー表示でも、Key 全体を表示してはいけません。また、設定ファイルを GitHub や共有フォルダに含めない運用が必要です。

データ管理：ローカル保存とエクスポート

データ管理画面では、定期アップロード、クラウドデータ管理、アップロード履歴、データ書き出し、読み込み、履歴データ削除などの項目が確認できます。

データ管理画面
データ管理：アップロード、エクスポート、インポート、削除などのデータ操作を集約しています。

この種のツールでは、データはユーザーの作業履歴そのものです。したがって、エクスポート、インポート、削除、バックアップの設計は非常に重要です。

  • すべての作業データはデフォルトでローカル保存
  • クラウドアップロードは明示的にオンにした場合のみ
  • エクスポート前に個人情報確認を促す
  • 削除操作は確認ダイアログを出す
  • API Key や設定ファイルはエクスポート対象から分離する

技術アーキテクチャ案

このツールをクリーンに再設計するなら、以下のような構成が分かりやすいです。

Desktop Shell
  -> Local Web UI
  -> HTTP API
  -> Activity Service
  -> Window Collector
  -> Screenshot Service
  -> AI Service
  -> Report Service
  -> SQLite Repository

各サービスの役割は明確に分けます。

  • Window Collector: 前面ウィンドウ、プロセス名、タイトルを取得する
  • Screenshot Service: 必要なタイミングで画面を取得し、圧縮や一時保存を行う
  • AI Service: 認識、分類、レポート生成、接続テストを担当する
  • Activity Service: 作業ログの作成、更新、検索、集計を担当する
  • Report Service: 作業ログを Markdown レポートに変換する
  • Privacy Service: 除外アプリ、敏感情報フィルタ、ログ脱敏を担当する
  • Local Web UI: 操作画面と可視化を担当する

この分離により、AI API が失敗しても基礎ログは残り、UI が変わってもデータ処理層を再利用できます。

プライバシー設計の要点

作業記録ツールは便利である一方、扱う情報が非常に繊細です。特にスクリーンショット認識を使う場合、設計段階からプライバシーを前提にする必要があります。

  • データは原則としてローカル SQLite に保存する
  • スクリーンショットは分析後に削除し、必要な場合のみ保存する
  • API Key はログに出さず、可能なら Windows Credential Manager などのシステム資格情報ストアを使う
  • 除外アプリとホワイトリストを用意する
  • チャット本文、账号、密钥、完整 URL などは保存しないようにする
  • 外部 AI や云同步へ送信する前にユーザー確認を挟む
  • エクスポート時には設定ファイルと API Key を分離する

「データはユーザーの手元に置く」という方向性は、この種のツールにとって重要です。ただし、クラウドモデル、ランキング、協作、Web アカウント連携などの機能を入れる場合は、どのデータがどこへ送信されるかを UI 上で明示する必要があります。

実装上の制約と注意点

この種のツールには、明確な能力境界があります。できることとできないことを分けておくと、利用者に過度な期待を持たせず、安全な設計に近づけます。

  • 画面内容の識別には、OS のスクリーン録画やアクセシビリティ権限が必要になる場合があります。
  • チャットデータベース、ブラウザ履歴、ローカルファイルの中身を無断で読む設計にはすべきではありません。
  • AI 認識は分類ミス、要約漏れ、文脈誤認を起こす可能性があります。
  • すべての記録とレポートは、ユーザーが編集できる必要があります。
  • 外部サービス連携は、ログイン状態、ネットワーク、第三者サービスの UI 変更に影響されます。
  • サブスクリプション、ポイント、協作、ランキング、通知、クラウドモデルなどは、ローカル基本機能とは別の可用性条件を持ちます。

まとめ

AI日報アシスタントの価値は、AI に日報を書かせることだけではありません。その前段として、日々の作業断片を自動的に記録し、編集可能な時間線として残し、可視化し、最後に報告へ変換する一連の流れにあります。

目的を短く言えば、思い出す負担を減らし、復盤しやすくし、報告を早く作ることです。技術的に見ると、これはウィンドウ監視、スクリーンショット処理、AI 認識、ローカルデータベース、可視化 UI、レポート生成を組み合わせた作業記憶システムです。

今後クリーンルーム方式で再実装する場合は、可視機能とユーザー体験を参考にしつつ、コード、UI 文言、プロンプト、データ構造、アイコン、名称を独自に設計することが重要です。そうすれば、日報作成を楽にするという価値を保ちながら、より安全で拡張しやすいプロダクトへ育てられます。