SPEC-DRIVEN AUTOBUILD ── 報告書 v1.0

F-Chair+ 代替 稼働計測ツール
仮称「OpenChair」 実行計画 & 要件定義書

月額約1万円の F-Chair+ を、Google無料枠 + Python で運用コスト 月額0円で代替する自作ツールの設計書です。スタッフ1〜5名・Windows/Mac混在環境を前提に、定期スクリーンショット・稼働時間計測・管理者ダッシュボード・無変化アラート/日報自動生成を実現します。

💰 運用コスト 月額0円 🖥 Windows / Mac 両対応 👥 1〜5名規模 🐍 Python + Google無料枠
作成日 2026-06-29 / 対象: 社内スタッフ稼働管理 / ベース調査: F-Chair+(fchair-plus.jp)公式・IT比較サイト

エグゼクティブサマリー

「結局いくらかかって、何ができて、どう作るのか」を1枚で。

月額 0 円

F-Chair+(推定 約1万円/月・1〜5名で年間12万円超)→ 自作で年間コスト 0円(開発工数のみ)

10分
スクショ間隔(ランダム)
15GB
Google無料枠で恒久運用
1本
クロスプラットフォーム
コードベース
~3週
MVP完成目安
✅ 結論:実現可能。ゼロコストで F-Chair+ の中核を再現できる。
常駐アプリがバックグラウンドで①着席/退席の稼働記録、②10分間隔ランダムスクショ、③Googleドライブ自動アップロード、④スプレッドシート集計、⑤無変化検知アラートを行う。管理者はブラウザでスプレッドシート+Driveフォルダを見るだけ。サーバー不要・課金なし。
⚠️ 唯一にして最大の注意点:法務・労務対応
従業員のPC画面監視は「監視ツール導入の事前通知+利用目的の明示+同意取得」が日本の労務・個人情報保護法上ほぼ必須。技術より先に運用ルールと同意書の整備が成否を分ける。詳細は §7。

1. リサーチ ― F-Chair+ 徹底分析

公式サイトおよびIT比較メディアを調査。代替すべき機能を分解し、自作版の要否を判定した。

1-1. F-Chair+ の機能棚卸しと自作版の方針

F-Chair+ 機能仕様(調査確定)自作版の扱い判定
ワンクリック着席/退席専用アプリで「着席」「退席」をワンクリック。中抜け対応。常駐アプリのトレイ/ウィンドウにボタン配置MVP必須
PC画面ランダム撮影着席中のみ、1時間に6回(平均10分間隔)ランダムに撮影し保存同等を再現(10分±ランダムで撮影)MVP必須
稼働時間記録・集計日別・月別の作業時間、タスク別記録、時間バー可視化稼働ログ→スプレッドシート集計MVP必須
管理者による閲覧管理者と本人のみ閲覧。部下の勤務一覧・スクショ確認Googleスプレッドシート+Driveフォルダ=ダッシュボードMVP必須
稼働無変化アラートPC画面に変化がないと管理者へ通知連続スクショの画像差分→閾値超で通知MVP対象
業務報告書の自動生成スクショ付き業務報告書を自動作成日次でHTML/PDF日報を自動生成MVP対象
プライバシーぼかし画面をぼかしメール等の文字を読めなくする画像にブラー処理を後付け可能にDEFER(v2)
GPS勤務位置情報着席中のみ移動経路を地図表示。プライバシーエリア機能監視色が強く社内利用では不要対象外
残業/深夜労働アラート規定時間超でメール通知稼働ログから閾値判定で通知DEFER(v2)
スマホアプリ着席スマホからも着席可能PC稼働計測が目的のため不要対象外
調査からの最重要インサイト: F-Chair+ の本質は「着席/退席という自己申告 × ランダムなスクショによる裏付け」の組み合わせ。GPSや特許機能は付加価値であり、中核(着席ログ+ランダムスクショ+集計閲覧)だけ再現すれば代替目的の8〜9割は達成できる。自作版はこの中核に集中する。

1-2. F-Chair+ の課金構造(=コスト削減の根拠)

2. ゼロコスト実現の仕組み

「なぜ0円で回るのか」を構成要素ごとに証明する。

必要な機能F-Chair+ の手段自作版のゼロコスト手段コスト
常駐・スクショ・着席UI専用SaaSアプリPython常駐アプリ(mss / Pillow / pystray)0円
スクショ保管SaaSサーバーGoogleドライブ無料15GB(rclone自動同期)0円
稼働ログ集約・集計SaaS管理画面Googleスプレッドシート(GAS Webアプリで追記)0円
管理者ダッシュボードSaaS管理画面(課金)スプレッドシート+Driveフォルダをブラウザ閲覧0円
アラート通知SaaSメールGmail SMTP もしくは GAS のメール送信(無料枠)0円
配布パッケージSaaSインストーラPyInstallerで .exe / .app 化(Python不要で配布)0円
サーバーSaaSクラウド不要(各PC→Googleへ直接。常時起動サーバーなし)0円
0円が成立する3つの根拠:
  1. Googleアカウントの無料枠(Drive 15GB、Sheets、Apps Script)で1〜5名・スクショ量を十分にまかなえる(容量計算は §6)。
  2. サーバーレス設計 ── 集約先がGoogle側なので、自社で常時起動マシンを持たない=電気代も追加0。
  3. すべてOSS/無償ツール ── Python・mss・Pillow・rclone・PyInstaller・GAS はすべて無料。

3. アーキテクチャと技術選定

「ツール形式(常駐アプリ)」というご希望を、混在OS・ゼロコストに最適化した構成。

3-1. データフロー全体像

スタッフPC常駐アプリ
着席/退席・撮影
ローカル一時保存スクショ+稼働ログCSV
自動同期rclone→Drive
GAS→Sheets
Google側集約Driveフォルダ
スプレッドシート
管理者ブラウザで閲覧
+日報+アラート

3-2. 技術選定(確定)

レイヤ採用技術選定理由(混在OS×ゼロコスト)
言語/ランタイムPython 3.11+Windows/Macで同一コード。OSS資産が豊富。
スクリーンショットmss高速・軽量・クロスプラットフォーム。マルチモニタ対応。
画像処理/圧縮PillowJPEG圧縮・リサイズ・(v2でブラー)。容量削減の要。
常駐UI(着席/退席)pystray + Pillowタスクトレイ常駐。F-Chairのワンクリック操作を再現。
DriveアップロードrcloneOAuth処理を内蔵。自前でAPI実装不要。堅牢な再送。
稼働ログ集約Google Apps Script WebアプリdoPostでスプレッドシートに行追記。サーバーレス・無料。
ダッシュボードGoogleスプレッドシート関数/ピボットで集計・グラフ化。学習コストほぼ0。
アラート/日報Gmail SMTP or GAS無変化検知時・日次でメール。無料枠内。
配布PyInstaller各OSで単一実行ファイル化。スタッフ側にPython環境不要。
設計思想: 「アダプタ+DRY_RUN」構成。アップロード・メール送信は DRY_RUN=true を既定とし、ローカル動作確認をキーなしで完走可能にする。Google連携が未設定でもローカル単体で全機能テストが通るため、安全に開発・検証できる(黄金ルール3:破壊的/外部送信操作の安全装置)。

4. 実行計画(開発ロードマップ)

spec-driven-autobuild の各フェーズに沿った、GO判定付き段階計画。MVP完成まで約3週間。

4-1. フェーズ別マイルストーン

Phase A:準備・PoC(1〜2日)

⏱ ゴール:技術成立の確認
  • Google個人/Workspaceアカウントで Drive・Sheets・GAS を準備
  • mssで1枚撮影 → Pillowで圧縮 → rcloneでDriveへ1枚アップロードを通す(疎通PoC)
  • GAS Webアプリに1行POST追記できることを確認

Phase B:中核アプリ実装(3〜5日)

⏱ ゴール:1台で稼働計測+スクショが完結
  • 着席/退席トレイUI(pystray)+稼働ログCSV記録
  • 着席中のみ10分±ランダムでスクショ→ローカル保存(命名規則:userID_YYYYMMDD_HHMMSS.jpg
  • OS復帰・スリープ・退席状態のハンドリング

Phase C:Google集約・ダッシュボード(3〜4日)

⏱ ゴール:管理者がブラウザで一元閲覧
  • rcloneでスクショをユーザー別Driveフォルダへ自動同期
  • 稼働ログをGAS経由でスプレッドシートに集約・日別/月別集計
  • スプレッドシートに時間バー/ピボットの閲覧ビュー作成

Phase D:アラート・日報(2〜3日)

⏱ ゴール:F-Chair上位機能の再現
  • 連続スクショの画像差分→無変化が閾値超でメール通知
  • 日次でスクショ+稼働サマリーのHTML/PDF日報を自動生成

Phase E:配布・容量運用・検証(2〜3日)

⏱ ゴール:スタッフ配布可能な状態=GO判定
  • PyInstallerで Windows .exe / Mac .app 生成、自動起動設定(タスクスケジューラ/launchd)
  • 古いスクショの自動削除(保持期間ポリシー)で15GB枠維持
  • E2E:正常系・スリープ復帰・ネット断・退席中無撮影 を検証

Phase F:本番移行(同意取得後・段階展開)

⏱ ゴール:1名で試験運用→全員展開
  • ※必須前提:スタッフへの事前通知・同意取得・運用ルール明文化(§7)
  • 1名で1週間パイロット → 問題なければ2〜5名へ拡大

4-2. GO判定基準(Phase E 完了=本番移行可)

ゲート合格条件
機能MVP全FR(FR-01〜FR-09)が受入基準を満たす
安全退席中は撮影されない/DRY_RUNで誤送信なし/古いデータ自動削除が動作
容量1〜5名・想定撮影量で15GB枠に収まる試算と実測が一致
クロスOSWindows・Mac両方で .exe/.app が正常起動・撮影・同期
法務同意書・運用ルールが整備され、スタッフ通知が完了

5. 要件定義書(SRS)

IEEE 29148 / ISO 25010 準拠。全Must要件に受入基準(AC)とテストID(TC)を接続。

5-1. 目的とスコープ

目的: 月額課金SaaS「F-Chair+」を、運用コスト0円の自作常駐ツールで代替し、社内スタッフ(1〜5名)の稼働時間とPC作業状況を、管理者がブラウザで一元把握できるようにする。

スコープ

区分内容
IN SCOPE着席/退席による稼働計測、10分間隔ランダムスクショ、Drive/Sheets集約、管理者ブラウザ閲覧、無変化アラート、日報自動生成、Win/Mac配布
DEFER(v2)プライバシーぼかし、残業/深夜アラート、タスク別記録の高度化
対象外GPS位置情報、スマホアプリ、リアルタイム画面ライブ配信

5-2. ステークホルダーと権限

役割権限
スタッフ(本人)自分の着席/退席操作、自分のスクショ・稼働の閲覧
管理者全スタッフの稼働一覧・スクショ・アラート・日報の閲覧
システム管理者(開発担当=あなた)Googleアカウント・rclone設定・配布パッケージ管理

5-3. 機能要件(FR)

Given-When-Then 受入基準付き。優先度:Must Should Could

ID機能受入基準(Given-When-Then)優先TC
FR-01着席/退席記録 常駐中、トレイの「着席」を押すと→稼働開始時刻が記録され状態が「着席中」になる。「退席」で終了時刻が記録される。 MustTC-01
FR-02中抜け対応 1日に複数回の着席/退席があっても→各区間が合算され実稼働時間として集計される。 MustTC-02
FR-03ランダムスクショ 着席中である限り→平均10分間隔(ランダム揺らぎ付き、1時間あたり約6回)で画面を撮影しローカル保存する。 MustTC-03
FR-04退席中の撮影停止 退席中またはアプリ未起動の間は→一切スクショを撮影しない。 MustTC-04
FR-05スクショのDrive同期 ネット接続時→ローカルのスクショがユーザー別Driveフォルダへ自動アップロードされる。切断中は保留し復帰後に再送する。 MustTC-05
FR-06稼働ログのSheets集約 退席/日次タイミングで→稼働区間がスプレッドシートに行追記され、日別/月別に集計される。 MustTC-06
FR-07管理者ダッシュボード閲覧 管理者がブラウザでスプレッドシート/Driveを開くと→全スタッフの稼働時間とスクショを一覧確認できる。 MustTC-07
FR-08無変化アラート 連続するスクショの画像差分が閾値未満の状態が一定回数続いたら→管理者へメール通知する。 ShouldTC-08
FR-09日報自動生成 1日の終了時→スクショ一覧と稼働サマリーをまとめたHTML/PDF日報を自動生成する。 ShouldTC-09
FR-10古いデータ自動削除 保持期間(既定60日)を超えたスクショは→自動削除し、無料15GB枠を維持する。 MustTC-10
FR-11自動起動 PC起動時→常駐アプリが自動起動する(タスクスケジューラ / launchd)。 ShouldTC-11
FR-12プライバシーぼかし 設定ON時→スクショに自動ブラーを適用し文字情報を判読不能にする。 Could / v2TC-12

5-4. データ要件

データ形式・保存先項目
スクリーンショットJPEG(圧縮)/ローカル一時→Driveユーザー別フォルダuserID, 撮影時刻, モニタ番号
稼働ログローカルCSV→スプレッドシートuserID, 着席時刻, 退席時刻, 稼働秒数, 日付
設定ローカル設定ファイル(JSON)userID, 撮影間隔, 保持日数, DRY_RUN, ぼかしON/OFF
日報HTML/PDF/Drive日付, 稼働合計, スクショ一覧, アラート有無

6. 非機能要件・容量設計

ISO 25010 の品質特性で定量化。0円運用が破綻しないことを数値で裏付ける。

6-1. 容量試算(15GB無料枠で回るか)

前提
撮影頻度6枚/時 × 8時間 = 48枚/日・人
1枚あたり(JPEG圧縮・リサイズ後)約 100〜150KB
1人1日48枚 × 150KB ≒ 約7MB
5人 × 稼働20日/月7MB × 5 × 20 ≒ 約700MB/月
保持60日で自動削除常時 約1.4GB 程度で頭打ち
結論: 5名フル稼働でも常時1.4GB程度。15GB無料枠に対して約9%。FR-10(自動削除)が効けば恒久的に0円で運用可能。万一不足しても保持日数短縮・解像度調整で容易に調整できる。

6-2. 品質特性(ISO 25010)

特性要件(定量)
性能効率性スクショ1回のCPU占有 <1秒、常駐時メモリ <150MB、業務PCの体感影響なし
信頼性ネット断時はローカル保留→復帰後100%再送。アプリ異常終了時も次回起動で復旧
使用性スタッフ操作は「着席/退席」2ボタンのみ。管理者は既存のスプレッドシート操作のみ
保守性OS差分はアダプタ層に集約、コア1コードベース。設定はJSON外出し
移植性Windows10/11・macOS両対応。Python不要の単一実行ファイルで配布
セキュリティDrive/Sheetsは管理者と本人のみ共有。退席中無撮影。保持期間後自動削除

8. リスクと未決事項

IDリスク/未決影響対策
R-01従業員監視への心理的反発目的説明・同意取得・着席中のみ撮影で透明性確保(§7)
R-02法令・労務対応の不備運用ルール/同意書を本番前に整備。社労士確認を推奨
R-03Google無料枠の規約・容量変更容量は9%使用で余裕。規約は一次ソースで定期確認
R-04Macのスクショ/常駐の権限(画面収録許可)初回に画面収録・アクセシビリティ許可手順を案内に明記
R-05スタッフによるアプリ停止/未起動自動起動(FR-11)+稼働ログの欠落で検知
R-06rclone/GASの初期設定がやや技術的システム管理者が一括セットアップ。手順書を整備

未決事項(次回確認)

9. 次のアクション

あなた(社長)にお願いしたいこと

  • 本報告書のレビュー=この方針でGOか判断
  • §8の未決4点(Googleアカウント種別・保持期間・通知先・ぼかし要否)の回答
  • スタッフへの導入説明・同意取得の意向確認

承認後にこちらで進めること

  • Phase A PoC(mss→Pillow→rclone→Drive 疎通)
  • SDD(詳細設計書)とCLAUDE.md・テスト計画の自動生成
  • 同意書・運用ルールのドラフト作成
  • MVP実装(Phase B〜E)
このまま進めてよければ、「GO」とだけお返事ください。未決4点の回答も一緒にいただければ、その内容を反映して詳細設計(SDD)と実装に着手します。方針変更・追加要望があればこの報告書のどこを直すか教えてください。