Pythonプロトタイプ完成とRust移行の決断 - Day 15

Posted at 2026-05-21

はじめに

Day 14では、連載の一区切りと今後の開発目的について書きました。

今回はPythonプロトタイプの完成の報告とバックエンドをRustへ移行する決断とその経緯について書きます。

Day 13で報告したgoals機能のチケット制への全面改修が完了しました。これによりPythonプロトタイプとして当初計画していた機能が一通り揃いました。

実装済みの機能は以下の通りです。

機能	ファイル	内容
時間記録	times.py	開始・終了・合計時間の計測。月別CSV自動出力
チケット管理	goals.py	親→子→孫の3階層チケット。作成・ステータス更新・completion_flag自動算出
ファイル操作	file_operations.py	OSパス自動判定・CSV/JSONL読み込み
APIハブ	main.py	FastAPIによるエンドポイント定義

このタイミングで本番機能の実装を開始することにした理由は3点あります。

1. 開発当初からの方針

本番用バックエンドにはRustを使用する想定で開発を進めていました。Pythonはあくまでもロジックとデータ構造を確認するためのプロトタイプという位置づけです。

2. NN機能実装前に移行するコストが最小

NN機能をPythonで実装した後にRustへ移行しようとすると、PyTorchからBurnへの変換作業が発生します。プロトタイプの規模が小さい現時点で移行することで、書き直しのコストを最小化できます。

3. 3D描画時のボトルネック回避

フロントのUI方針変更（後述）に伴い、3D描画を実装する場合に現在のスタックではAPI通信を行う部分でボトルネックが発生すると判明しました。

goals機能の実装を通じて、フロントの操作性について再検討を行いました。

当初はVS Codeをモデルにしたマウス操作中心のUIを想定していましたが、ゲームコントローラー的に限定されたキーの組み合わせで全操作を完結させる独自UIに変更します。

3Dゲームのようにユーザーの操作に応じて画面が動的に変化する設計を目指します。Three.jsによる3D描画はTypeScript側で完結させ、Rustバックエンドでは描画計算を行わない方針です。

PythonプロトタイプはTauri標準のIPC（コマンド方式）で連携していたFastAPIとは設計思想が異なります。HTTPサーバーは不要になり、TauriのIPCコマンド方式でフロントとバックを繋ぐ設計になります。

Rust版でもPythonプロトタイプで確定した以下の設計判断は引き継ぎます。

今日はPythonプロトタイプの完成とRust移行の決断について書きました。

プロトタイプを作ったことでデータ構造・API設計・フロントとバックの責務分離の判断が確定しました。Rust版ではこれをベースに本番品質の実装を進めていきます。

次の記事はRust版の実装が進んだ段階で公開します。

リポジトリはOSS公開準備中です。公開後にこの記事へリンクを追加します。

この記事は連載「クラウドに依存しないマイルストーン管理ツール開発記」のDay 15です。