ドキュメントに戻る
アーキテクチャ

技術的決定とトレードオフ

Tauri、SQLite、専用LLMプロキシが選択された理由とそのコスト。

10分 で読めます

すべてのアーキテクチャにはトレードオフが伴います。このドキュメントはPlanToCodeの主要な技術選択、それらが提供する利点、導入されるコストや制限について説明します。

トレードオフマトリックス

技術選択とその利点・コストの視覚的比較。

技術トレードオフマトリックス
Click to expand
技術スタック決定を示すシステムアーキテクチャ概要。

デスクトップ向けTauri v2

TauriはRustバックエンドとWebベースのフロントエンドを提供し、ネイティブパフォーマンスと小さなバイナリサイズでクロスプラットフォームデスクトップアプリを実現します。

Benefits

  • 小さなバイナリサイズ(Electronの200MB以上に対して約15MB)
  • ファイル操作とジョブ処理のネイティブRustパフォーマンス
  • きめ細かい権限を持つ機能ベースのセキュリティモデル
  • macOS、Windows、Linux向けの単一コードベース
  • システムAPIへのアクセス(PTY、キーチェーン、通知)

Tradeoffs

  • Electronより小さなエコシステム
  • バックエンド開発のRust学習曲線
  • プラットフォーム間のWebViewレンダリング差異
  • IPCイシューのデバッグツールが未成熟

ローカル永続化向けSQLite

SQLiteはセッション、ジョブ、ターミナル出力、設定を含むすべてのローカル状態を保存します。これによりオフライン操作と高速クエリが可能になります。

Benefits

  • 設定不要の組み込みデータベース
  • ローカルデータへの高速クエリ
  • オフライン操作を可能に
  • 単一ファイルのバックアップとリストア
  • 同時アクセス用のWALモード

Tradeoffs

  • 組み込みのレプリケーションや同期なし
  • 大きなターミナルログがデータベースを肥大化
  • 手動のスキーママイグレーションが必要
  • シングルライター制限(WALで軽減)

Implementation: consolidated_schema.sqlに約10テーブルのスキーマ。リポジトリがrusqliteで型付きアクセスを提供。

専用LLMプロキシサーバー

すべてのLLMリクエストはAPIキーを管理し、リクエストを正規化し、使用量を追跡し、課金を処理するサーバープロキシを経由します。

Benefits

  • APIキーがサーバーから離れない
  • すべてのプロバイダーに単一リクエストフォーマット
  • 集中化された使用量追跡と課金
  • クライアント更新なしでプロバイダーフェイルオーバー
  • コンテンツフィルタリングとレート制限

Tradeoffs

  • サーバーインフラストラクチャが必要
  • リクエストにネットワークレイテンシを追加
  • サーバーが単一障害点に
  • プロバイダー統合のメンテナンスが必要

Implementation: server/src/handlers/proxy/のハンドラーを持つActix-Webサーバー。provider_transformers/のトランスフォーマーがリクエストを正規化。

モバイル向けWebSocketリレー

デスクトップとモバイルクライアントはデバイスリンク、ターミナルストリーミング、ジョブ同期のためにWebSocketリレーを通じて接続します。

Benefits

  • リアルタイム双方向通信
  • 直接P2Pネットワーキング不要
  • NATとファイアウォールを超えて動作
  • 複数のリンクされたデバイスをサポート

Tradeoffs

  • 永続的なサーバー接続が必要
  • リレーが大きなペイロードにレイテンシを追加
  • 接続管理の複雑さ
  • 再接続とハートビートロジックが必要

Implementation: device_link_ws.rsがセッション追跡、ハートビート、ターミナル出力用のPTC1バイナリフレーミングを持つリレーを実装。

運用上の影響

  • Tauri:各プラットフォーム用に別々のビルドが必要。CI/CDはクロスコンパイルまたはプラットフォーム固有のランナーを使用する必要あり。
  • SQLite:データベースファイルがターミナル出力とともに増大。長時間実行インスタンスには定期的なクリーンアップが必要な場合あり。
  • LLMプロキシ:サーバーダウンタイムがすべてのLLM操作をブロック。本番環境には監視と冗長性が必要。
  • WebSocket:再接続ロジックが複雑さを追加。クライアントは接続切断を適切に処理する必要あり。

セキュリティ境界

アーキテクチャは露出を制限する明確なセキュリティ境界を作成します:

  • APIキーはサーバーボールトに保存され、クライアントには送信されない
  • JWTトークンはJWKSローテーション付きですべてのリクエストで検証
  • 機能ベースの権限がファイルシステムアクセスを制限
  • LLMに送信されるコンテンツには明示的なユーザー承認が必要
  • 監査ログがユーザーコンテキスト付きですべてのLLMリクエストを追跡

再検討すべき時

要件が大幅に変更された場合、これらの決定は再検討が必要な場合があります:

  • ブラウザのみのアクセスが必要な場合、TauriのWebベース代替を検討
  • マルチデバイス同期が重要な場合、サーバーサイドジョブストレージを検討
  • プロバイダーロックインが許容される場合、直接APIコールでレイテンシを削減可能
  • モバイルが主要な場合、デバイスリンクの代わりにネイティブアプリを検討