@aramassa/ai-rules 0.1.2 → 0.1.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,190 @@
1
+ ---
2
+ type: development-rules
3
+ category: chrome-extension
4
+ focus: javascript-patterns
5
+ language: javascript
6
+ applyTo: "**/*.js"
7
+ ---
8
+
9
+ # Chrome Extension Manifest V3 - JavaScript/Service Worker Patterns
10
+
11
+ ## Service Worker パターン
12
+
13
+ ### イベント駆動型設計
14
+
15
+ Service Worker はイベント駆動型のアーキテクチャを採用し、永続的な状態を持たずに動作します。主要なイベントリスナーの設定が必須となります:
16
+
17
+ - **chrome.runtime.onInstalled**: 拡張機能のインストール、更新、有効化時の初期化処理を実装
18
+ - **chrome.action.onClicked**: 拡張機能アイコンクリック時の動作を定義
19
+ - **chrome.runtime.onMessage**: 他のコンポーネントからのメッセージ受信処理を設定
20
+ - **chrome.alarms.onAlarm**: 定期実行や遅延実行のタイマーイベントを処理
21
+
22
+ Service Worker クラスの初期化では、constructor でイベントリスナーの設定を行い、各イベントハンドラーは bind() でコンテキストを適切に管理します。非同期処理では Promise を適切に返し、エラーハンドリングを確実に実装することが重要です。
23
+
24
+ 初回インストール時には chrome.storage.local を使用してデフォルト設定を保存し、拡張機能の基本状態を確立します。
25
+
26
+ ### 状態管理パターン
27
+
28
+ Service Worker の短命な性質により、永続的な状態管理には chrome.storage API の活用が必須です。
29
+
30
+ **chrome.storage.local**: 無制限の容量でローカルデータを保存し、高速アクセスが可能です。大容量データや一時的なキャッシュに適しています。
31
+
32
+ **chrome.storage.sync**: デバイス間同期が可能ですが、容量制限(100KB総容量、8KB/アイテム)があります。ユーザー設定や重要な設定データの同期に使用します。
33
+
34
+ 状態管理クラスでは静的メソッドを使用してデータの保存、読み込み、削除を統一的に処理します。sync ストレージ使用時は事前にデータサイズを検証し、容量制限を超える場合はエラーを発生させます。
35
+
36
+ 設定の同期では JSON.stringify() でサイズを測定し、制限内であることを確認してから保存処理を実行します。
37
+
38
+ ## declarativeNetRequest API JavaScript パターン
39
+
40
+ ### 動的ルール管理
41
+
42
+ 動的ルールは実行時に chrome.declarativeNetRequest.updateDynamicRules() API を使用して管理されます。
43
+
44
+ **ルール追加**: addRules パラメータに新しいルール配列を指定してルールを追加します。各ルールには一意の ID と適切な優先度を設定する必要があります。
45
+
46
+ **ルール削除**: removeRuleIds パラメータに削除対象のルール ID 配列を指定してルールを削除します。
47
+
48
+ **ルール取得**: getDynamicRules() メソッドで現在有効な動的ルールの一覧を取得できます。
49
+
50
+ **制限事項**: 動的ルールには数量制限があり(通常 5000 ルール)、この制限を超えないよう管理が必要です。また、セッションルールは拡張機能の再起動時にリセットされるため、永続化が必要な場合は動的ルールを使用します。
51
+
52
+ ルール管理クラスでは、ブロッキングルールの追加、特定ルールの削除、現在のルール状態取得などの操作を統一的なインターフェースで提供します。
53
+
54
+ ## コンテンツスクリプトパターン
55
+
56
+ ### DOM 操作の実装
57
+
58
+ コンテンツスクリプトはウェブページの DOM に直接アクセスし、ページコンテンツとの相互作用を処理します。
59
+
60
+ **初期化プロセス**: document.readyState をチェックして、ページの読み込み状況に応じて適切なタイミングで処理を開始します。読み込み中の場合は DOMContentLoaded イベントを待機し、完了済みの場合は即座に処理を実行します。
61
+
62
+ **DOM 処理**: ページ内の特定要素(data 属性を持つ要素など)を querySelectorAll で取得し、各要素に対して必要な処理を適用します。動的に追加される要素に対応するため、MutationObserver を使用してDOM の変更を監視します。
63
+
64
+ **変更監視**: MutationObserver は childList と subtree オプションを有効にして、ページ全体の要素追加を監視します。新しく追加された要素は nodeType が ELEMENT_NODE であることを確認してから処理します。
65
+
66
+ **メッセージ通信**: chrome.runtime.onMessage.addListener でメッセージを受信し、アクションタイプに応じて適切な処理を実行します。非同期処理の場合は return true を設定して、適切なレスポンスタイミングを管理します。
67
+
68
+ **エラーハンドリング**: すべての処理は try-catch でラップし、エラー発生時は適切なエラーレスポンスを送信します。
69
+
70
+ ## メッセージパッシングパターン
71
+
72
+ ### 一回限りのメッセージ
73
+
74
+ 一回限りのメッセージ通信は chrome.runtime.sendMessage() と chrome.tabs.sendMessage() を使用します。
75
+
76
+ **Popup から Service Worker への通信**: chrome.runtime.sendMessage() でメッセージオブジェクトを送信し、Promise として非同期レスポンスを受け取ります。メッセージには action、data、timestamp を含めて識別と処理を容易にします。
77
+
78
+ **コンテンツスクリプトへの通信**: chrome.tabs.sendMessage() で特定タブのコンテンツスクリプトにメッセージを送信します。タブ ID を指定して対象を明確にし、適切なレスポンスを受け取ります。
79
+
80
+ **エラーハンドリング**: 通信失敗時(受信側が存在しない、タブが閉じられた等)は適切にエラーをキャッチし、ユーザーに適切なフィードバックを提供します。
81
+
82
+ **タイムアウト管理**: 長時間レスポンスがない場合のタイムアウト処理を実装し、UI の応答性を保ちます。
83
+
84
+ PopupManager クラスでは統一的なメッセージ送信インターフェースを提供し、エラーハンドリングとログ出力を共通化します。
85
+
86
+ ### 長期間接続パターン
87
+
88
+ 長期間接続は chrome.runtime.connect() を使用して持続的な通信チャネルを確立します。
89
+
90
+ **接続確立**: chrome.runtime.connect() で名前付きポートを作成し、双方向通信チャネルを開きます。接続名(name パラメータ)で通信の目的を明確にします。
91
+
92
+ **メッセージハンドリング**: port.onMessage.addListener でメッセージを受信し、適切な処理を実行します。メッセージは port.postMessage() で送信します。
93
+
94
+ **接続監視**: port.onDisconnect.addListener で接続の切断を監視し、必要に応じて自動再接続を実装します。Service Worker の短命な性質により接続が切断される場合があるため、堅牢な再接続機能が重要です。
95
+
96
+ **リソース管理**: 不要になった接続は適切に切断し、メモリリークを防ぎます。また、接続状態を追跡して無効な接続での送信を避けます。
97
+
98
+ PersistentConnection クラスでは接続の確立、メッセージ送受信、自動再接続機能を統合的に管理し、アプリケーションロジックから通信の詳細を隠蔽します。
99
+
100
+ ## Offscreen API パターン
101
+
102
+ ### Offscreen ドキュメントの作成
103
+
104
+ Offscreen API は Service Worker から DOM 操作や特殊 API(クリップボード、音声再生等)にアクセスするための仕組みです。
105
+
106
+ **既存確認**: chrome.runtime.getContexts() で既存の Offscreen ドキュメントを確認し、重複作成を避けます。contextTypes に 'OFFSCREEN_DOCUMENT' を指定して検索します。
107
+
108
+ **ドキュメント作成**: chrome.offscreen.createDocument() で新しい Offscreen ドキュメントを作成します。url でHTML ファイルを指定し、reasons で使用目的(DOM_PARSER、CLIPBOARD 等)を宣言し、justification で具体的な利用理由を説明します。
109
+
110
+ **ライフサイクル管理**: 使用後は chrome.offscreen.closeDocument() で適切に終了し、リソースを解放します。同時に存在できる Offscreen ドキュメントは1つのみです。
111
+
112
+ **メッセージ通信**: Service Worker から Offscreen ドキュメントへの通信は chrome.runtime.sendMessage() を使用し、target フィールドで送信先を識別します。
113
+
114
+ OffscreenManager クラスでは Offscreen ドキュメントの作成、終了、メッセージ送信を統一的に管理し、適切なライフサイクル制御を提供します。
115
+
116
+ ## テスト戦略
117
+
118
+ ### Service Worker テスト
119
+
120
+ Service Worker のテストでは Chrome API のモック化と イベント駆動型動作の検証が重要です。
121
+
122
+ **API モック**: global.chrome オブジェクトで Chrome 拡張機能 API をモック化し、addListener、set、get などのメソッドを Jest の jest.fn() でモック関数として定義します。非同期 API は mockResolvedValue() で適切な戻り値を設定します。
123
+
124
+ **イベントリスナーテスト**: 各イベントリスナー(onInstalled、onMessage等)が適切に登録されることを確認し、expect().toHaveBeenCalled() でリスナー登録を検証します。
125
+
126
+ **非同期処理テスト**: async/await を使用して非同期処理を適切にテストし、chrome.storage の操作やメッセージ処理の結果を検証します。インストール時の初期化処理では、適切なデフォルト値が設定されることを確認します。
127
+
128
+ **エラーハンドリング**: 異常系のテストケースも含め、API 呼び出し失敗時の適切なエラーハンドリングを検証します。
129
+
130
+ テストではモック環境の設定、テスト対象クラスのインスタンス化、期待される動作の検証という流れで構造化します。
131
+
132
+ ### E2E テスト
133
+
134
+ E2E テストでは実際のブラウザ環境で拡張機能の動作を検証します。
135
+
136
+ **Puppeteer 設定**: ヘッドレスモードを false にして実際の拡張機能読み込みを確認し、--load-extension と --disable-extensions-except フラグで対象拡張機能のみを有効化します。dist ディレクトリにビルド済みの拡張機能を配置します。
137
+
138
+ **コンテンツスクリプト注入テスト**: 対象ページ(example.com 等)にアクセスし、page.evaluate() でコンテンツスクリプトが正常に注入されたことを確認します。window オブジェクトの拡張機能固有プロパティの存在を検証します。
139
+
140
+ **ポップアップ操作テスト**: 拡張機能の popup.html に直接アクセスし、UI 要素のクリック、結果の表示を確認します。chrome-extension:// スキームで拡張機能 ID を指定してアクセスします。
141
+
142
+ **非同期処理**: page.waitForSelector() で動的に生成される要素の出現を待機し、適切なタイムアウト設定で安定したテストを実行します。
143
+
144
+ **テスト環境管理**: beforeAll でブラウザとページを初期化し、afterAll で適切にリソースを解放します。各テストは独立して実行できるよう設計します。
145
+
146
+ ## デバッグ
147
+
148
+ ### Service Worker デバッグ
149
+
150
+ Service Worker の効果的なデバッグには適切なログ設定とストレージ管理が重要です。
151
+
152
+ **デバッグログ設定**: Logger クラスで統一的なログ管理を実装し、タイムスタンプ、ログレベル、メッセージ、関連データを構造化してコンソール出力します。開発環境では詳細ログをストレージに保存し、後から確認できるようにします。
153
+
154
+ **ストレージログ**: chrome.storage.local にデバッグログを保存し、最新 100 件のみを保持してストレージ容量を管理します。ログの保存に失敗した場合も適切にエラーハンドリングします。
155
+
156
+ **Chrome DevTools**: chrome://extensions/ の「サービスワーカー」リンクから DevTools を開き、コンソールログ、ネットワーク、ストレージを確認します。
157
+
158
+ **リアルタイム監視**: Service Worker の活動状況、イベント発生、エラー情報をリアルタイムで監視し、問題の早期発見に活用します。
159
+
160
+ **ログレベル管理**: log、info、warn、error の適切なレベル分けで、問題の重要度を明確化し、効率的なデバッグを実現します。
161
+
162
+ ## パフォーマンス最適化
163
+
164
+ ### Service Worker 最適化
165
+
166
+ Service Worker の短命な性質を考慮した効率的なイベントハンドリングが重要です。
167
+
168
+ **デバウンス処理**: 高頻度で発生するイベント(タブ更新等)にデバウンス処理を実装し、不要な処理の実行を抑制します。Map オブジェクトで複数のデバウンス処理を管理し、各キーに対して個別にタイムアウトを設定します。
169
+
170
+ **効率的なイベント処理**: タブ更新イベントでは changeInfo.url が変更された場合のみ処理を実行し、不要なイベント処理を避けます。デバウンス関数で遅延実行を設定し、連続する変更を適切に統合します。
171
+
172
+ **メモリ効率**: 不要なイベントリスナーの削除、タイムアウトの適切なクリア、リソースの確実な解放を実装します。
173
+
174
+ **バックグラウンド処理の最適化**: 重い処理は適切に分割し、Service Worker の実行時間制限内で完了するよう設計します。
175
+
176
+ OptimizedBackground クラスでは debouncedHandlers Map でタイムアウト ID を管理し、debounce メソッドで統一的な遅延処理を提供します。
177
+
178
+ ### メモリ管理
179
+
180
+ 拡張機能の長期安定動作にはメモリ効率的なデータ管理が必要です。
181
+
182
+ **LRU キャッシュ実装**: Map オブジェクトでキャッシュを実装し、最大サイズ(maxCacheSize)を設定して容量制限を管理します。容量上限に達した場合、最も古いエントリ(LRU: Least Recently Used)を自動削除します。
183
+
184
+ **アクセス順序管理**: キャッシュアクセス時にエントリを削除・再追加することで、アクセス順序を更新し、LRU アルゴリズムを実現します。Map の反復順序特性を活用してエントリの新旧を判定します。
185
+
186
+ **メモリ効率**: 不要になったデータは即座に削除し、メモリリークを防ぎます。定期的な clear() でキャッシュ全体をリセットし、長期実行時のメモリ蓄積を回避します。
187
+
188
+ **データサイズ管理**: 大きなオブジェクトのキャッシュ時は適切なサイズ制限を設定し、メモリ使用量をコントロールします。
189
+
190
+ DataManager クラスでは静的メソッドでキャッシュ操作を統一し、set、get、clear の基本操作でメモリ効率的なデータ管理を提供します。
@@ -0,0 +1,110 @@
1
+ ---
2
+ type: development-rules
3
+ category: chrome-extension
4
+ focus: manifest-configuration
5
+ language: json
6
+ applyTo: "**/manifest.json"
7
+ ---
8
+
9
+ # Chrome Extension Manifest V3 - Manifest Configuration
10
+
11
+ ## manifest.json 設計指針
12
+
13
+ ### 必須構造
14
+
15
+ manifest.json ファイルは拡張機能の設定と権限を定義する中核ファイルです。Manifest V3 では以下の要素が必須となります:
16
+
17
+ - **基本情報**: manifest_version(必ず3)、name、version、description の設定
18
+ - **background**: service_worker フィールドでバックグラウンドスクリプトを指定し、type: "module" で ESM モジュールとして動作させる
19
+ - **action**: 拡張機能アイコンの設定、ポップアップ HTML、タイトル、各サイズのアイコンファイルを定義
20
+ - **permissions**: 基本的な API 権限(storage、activeTab など)をリスト形式で列挙
21
+ - **host_permissions**: 特定ドメインへのアクセス権限を別途定義
22
+ - **content_scripts**: 注入するスクリプトファイル、対象URL パターン、実行タイミングを設定
23
+
24
+ アイコンは 16px、32px、48px、128px の4サイズを用意し、用途に応じて適切なサイズが自動選択されます。
25
+
26
+ ### 権限設計のベストプラクティス
27
+
28
+ - **host_permissions の分離**: API 権限と Host 権限を明確に分離する
29
+ - **最小権限の原則**: 必要最小限の権限のみを要求する
30
+ - **動的権限**: `chrome.permissions` API を使用した実行時権限要求の検討
31
+ - **権限の透明性**: ユーザーが権限の目的を理解できる説明を提供する
32
+
33
+ ## declarativeNetRequest API 設定
34
+
35
+ ### 静的ルール定義
36
+
37
+ declarativeNetRequest API は静的ルールファイル(rules.json)で基本的なネットワーク制御を定義します。
38
+
39
+ **ルール構造**: 各ルールは一意の id、優先度(priority)、実行するアクション(action)、適用条件(condition)で構成されます。
40
+
41
+ **アクションタイプ**:
42
+ - **block**: 指定されたリクエストをブロック
43
+ - **redirect**: 別のリソースにリダイレクト(拡張機能内のファイルまたは外部URL)
44
+ - **modifyHeaders**: リクエスト/レスポンスヘッダーを変更
45
+ - **upgradeScheme**: HTTP を HTTPS にアップグレード
46
+
47
+ **条件指定**: urlFilter でURLパターンを指定し、resourceTypes で対象リソース(script、image、xmlhttprequest など)を限定します。ワイルドカード(*)を使用してパターンマッチングを行います。
48
+
49
+ **優先度**: 複数ルールが同一リクエストにマッチした場合、priority の高いルールが優先されます。数値が大きいほど高優先度です。
50
+
51
+ 静的ルールは manifest.json の declarative_net_request フィールドで rules.json ファイルを指定して読み込まれます。
52
+
53
+ ### 必須 manifest.json サンプル構造
54
+
55
+ ```json
56
+ {
57
+ "manifest_version": 3,
58
+ "name": "拡張機能名",
59
+ "version": "1.0.0",
60
+ "description": "拡張機能の説明",
61
+
62
+ "background": {
63
+ "service_worker": "background.js",
64
+ "type": "module"
65
+ },
66
+
67
+ "action": {
68
+ "default_popup": "popup.html",
69
+ "default_title": "拡張機能タイトル",
70
+ "default_icon": {
71
+ "16": "icons/icon16.png",
72
+ "32": "icons/icon32.png",
73
+ "48": "icons/icon48.png",
74
+ "128": "icons/icon128.png"
75
+ }
76
+ },
77
+
78
+ "permissions": [
79
+ "storage",
80
+ "activeTab"
81
+ ],
82
+
83
+ "host_permissions": [
84
+ "https://example.com/*"
85
+ ],
86
+
87
+ "content_scripts": [
88
+ {
89
+ "matches": ["https://example.com/*"],
90
+ "js": ["content.js"],
91
+ "run_at": "document_end"
92
+ }
93
+ ],
94
+
95
+ "content_security_policy": {
96
+ "extension_pages": "script-src 'self'; object-src 'self'; img-src 'self' data: https:",
97
+ "sandbox": "sandbox allow-scripts"
98
+ },
99
+
100
+ "declarative_net_request": {
101
+ "rule_resources": [
102
+ {
103
+ "id": "rules",
104
+ "enabled": true,
105
+ "path": "rules.json"
106
+ }
107
+ ]
108
+ }
109
+ }
110
+ ```
@@ -0,0 +1,258 @@
1
+ ---
2
+ type: development-rules
3
+ category: desktop-app
4
+ focus: electron
5
+ language: javascript
6
+ framework: electron
7
+ ---
8
+
9
+ # Electron 開発ベストプラクティス:2025年版セキュア・高性能デスクトップアプリケーション開発ガイド
10
+
11
+ ## 概要
12
+
13
+ Electronは、Web技術(JavaScript、HTML、CSS)を用いてクロスプラットフォームのネイティブデスクトップアプリケーションを構築するための強力なフレームワークです。しかし、その力を責任を持って活用するには、セキュリティ、パフォーマンス、アーキテクチャに関する現代的なベストプラクティスへの厳格な準拠が不可欠です。
14
+
15
+ 本ガイドは、2025年における「セキュリティ第一」および「パフォーマンス・バイ・デザイン」という考え方で、セキュアで高性能、かつ保守性の高いデスクトップアプリケーションを構築するための包括的な指針を提供します。
16
+
17
+ ## 1. セキュリティ基盤:最小権限の原則とコンテキスト分離
18
+
19
+ ### 1.1 必須セキュリティ設定
20
+
21
+ **重要**: Electronはホストシステムへの特権アクセスを許可するため、XSSのような脆弱性がサンドボックス化されたブラウザ環境よりもはるかに深刻な影響を及ぼす可能性があります。
22
+
23
+ #### webPreferences必須設定
24
+
25
+ BrowserWindowを作成する際は、以下のセキュリティ設定を必須とします:
26
+
27
+ - `nodeIntegration: false` - レンダラープロセスでのNode.js APIアクセスを無効化
28
+ - `contextIsolation: true` - コンテキスト分離を有効化(Electron 12以降はデフォルト)
29
+ - `sandbox: true` - プロセスをサンドボックス化(推奨)
30
+ - `webSecurity: true` - Web標準のセキュリティ機能を維持(デフォルト)
31
+ - `allowRunningInsecureContent: false` - HTTPSページでのHTTPリソース実行を禁止(デフォルト)
32
+ - `experimentalFeatures: false` - 実験的機能を無効化
33
+
34
+ ### 1.2 contextBridgeによる安全なAPI公開
35
+
36
+ contextIsolationが有効な環境では、contextBridgeモジュールのみを使用してAPIを安全に公開します。
37
+
38
+ #### 危険な実装(避けるべき)
39
+
40
+ preloadスクリプトでipcRenderer全体を公開することは危険です。これにより任意のIPCメッセージ送信が可能になってしまいます。
41
+
42
+ #### 安全な実装(推奨)
43
+
44
+ 特定の名前付きアクションのみを公開し、制限された機能セットを提供します。以下の原則に従います:
45
+ - 特定の機能に限定したメソッドを提供
46
+ - 引数の検証を行う
47
+ - リスナーの適切な管理機能を提供
48
+
49
+ ### 1.3 IPC送信元検証とメインプロセス保護
50
+
51
+ メインプロセスで受信するすべてのIPCメッセージは送信元を検証する必要があります。以下の原則に従います:
52
+
53
+ - 送信元URLの検証を実行
54
+ - 信頼できるオリジンのリストを管理
55
+ - 不正な送信元からのリクエストは拒否
56
+ - エラーハンドリングによる適切な例外処理
57
+
58
+ ### 1.4 コンテンツセキュリティポリシー(CSP)
59
+
60
+ 厳格なCSPは重要な防御層となります。実装方法は2つあります:
61
+
62
+ #### HTMLファイル内での設定
63
+
64
+ HTMLファイルのheadセクションにmetaタグを使用してCSPを設定します。script-src、object-src、img-srcなどの適切なディレクティブを指定します。
65
+
66
+ #### プログラマティックな設定
67
+
68
+ session.defaultSession.webRequest.onHeadersReceivedを使用してHTTPヘッダでCSPを設定します。レスポンスヘッダにContent-Security-Policyヘッダを追加することで動的に制御できます。
69
+
70
+ ### 1.5 権限リクエストの制御
71
+
72
+ デフォルトですべての権限リクエストを拒否し、必要なもののみを許可します。以下の原則に従います:
73
+
74
+ - session.defaultSession.setPermissionRequestHandlerを使用
75
+ - 送信元のオリジンを検証
76
+ - 信頼できるオリジンからのリクエストのみ処理
77
+ - 許可する権限を明示的に指定(notifications、mediaなど)
78
+ - デフォルトはすべて拒否
79
+
80
+ ## 2. パフォーマンス・アーキテクチャ設計
81
+
82
+ ### 2.1 プロセスモデルの理解と活用
83
+
84
+ Electronのマルチプロセスアーキテクチャを正しく理解することが高性能アプリケーションの鍵です。
85
+
86
+ #### メインプロセスの役割(制限事項)
87
+
88
+ - **やるべきこと**: ウィンドウ管理、システムイベント処理、IPCルーティング
89
+ - **やってはいけないこと**: CPU集約的な処理、ブロッキングI/O、同期的な長時間実行タスク
90
+
91
+ #### 悪い例:メインプロセスでの重い処理
92
+
93
+ app.on('ready')イベント内で重い処理を同期的に実行すると、メインプロセスがブロックされアプリ全体がフリーズします。
94
+
95
+ #### 良い例:非同期処理とワーカー活用
96
+
97
+ createWindow()を先に実行してUIを表示し、重い処理は別プロセス(Worker Threads)で非同期実行します。
98
+
99
+ ### 2.2 非同期処理の徹底
100
+
101
+ #### ブロッキング操作の回避
102
+
103
+ 同期I/O操作(fs.readFileSyncなど)はメインプロセスをブロックするため避けるべきです。代わりにPromiseベースの非同期I/O(fs.promises.readFile)を使用します。
104
+
105
+ #### 同期的IPCの回避
106
+
107
+ ipcRenderer.sendSyncはレンダラープロセスをブロックするため使用を避け、代わりにipcRenderer.invokeによる非同期IPCを使用します。
108
+
109
+ ### 2.3 CPU集約的タスクの処理
110
+
111
+ #### Worker Threadsの活用
112
+
113
+ worker_threadsモジュールを使用して、重い計算処理を別スレッドで実行します。メインスレッドとワーカースレッドの判定により、同一ファイル内で両方の処理を記述できます。ワーカー側では計算結果をparentPort.postMessageで返します。
114
+
115
+ #### 専用BrowserWindowの活用
116
+
117
+ 非表示のBrowserWindowを作成して、専用のレンダラープロセスで重い処理を実行することも可能です。この場合はnodeIntegrationを有効にし、IPCを通じてタスクの配布と結果の収集を行います。
118
+
119
+ ### 2.4 メモリ管理とリーク防止
120
+
121
+ #### 適切なクリーンアップ
122
+
123
+ Reactなどのフレームワークを使用する場合、useEffectのクリーンアップ関数内でイベントリスナを適切に削除します。window.electronAPI.removeAllListenersを使用してリスナーを削除し、メモリリークを防止します。
124
+
125
+ #### メモリ監視
126
+
127
+ setIntervalを使用してメモリ使用量を定期的に監視し、閾値を超えた場合は警告を出力します。必要に応じてglobal.gc()でガベージコレクションを手動実行できます。
128
+
129
+ ## 3. 現代的な開発ワークフロー
130
+
131
+ ### 3.1 ビルドツールの選択:Webpack vs Vite
132
+
133
+ #### Vite + electron-vite(推奨:新規プロジェクト)
134
+
135
+ 新規プロジェクトでは`npm create electron-vite@latest`を使用してプロジェクトを作成します。Viteは高速な開発サーバーとビルド機能を提供し、electron-viteはElectron専用の設定を簡素化します。
136
+
137
+ vite.config.jsでmain、preload、rendererの各プロセス用の設定を分離して記述します。メインプロセスとプリロードスクリプトはCommonJS形式、レンダラープロセスは通常のVite設定を使用します。
138
+
139
+ ### 3.2 TypeScript統合
140
+
141
+ #### 型定義の整備
142
+
143
+ TypeScript環境では、ElectronAPIの型定義を適切に作成します。src/types/electron.d.tsファイルを作成し、contextBridgeで公開するAPIの型を定義します。globalのWindow interface拡張により、レンダラープロセスでタイプセーフなAPI呼び出しが可能になります。
144
+
145
+ ### 3.3 セキュアなファイルシステムアクセス
146
+
147
+ レンダラープロセスは直接ファイルシステムにアクセスすべきではありません。
148
+
149
+ メインプロセスでdialog.showOpenDialogを使用してファイル選択ダイアログを表示し、選択されたファイルを安全に読み込みます。ファイルの種類制限(filters)を設定し、キャンセル処理も適切に行います。読み込み結果はパスと内容をオブジェクトで返し、レンダラープロセスに送信します。
150
+
151
+ ## 4. 外部リンクとプロトコルの安全な処理
152
+
153
+ ### 4.1 shell.openExternalの安全な使用
154
+
155
+ 外部リンクを開く際は、必ずメインプロセスでURL検証を行います。
156
+
157
+ preloadスクリプトでは単純なAPIを公開し、実際の検証はメインプロセスに委譲します。メインプロセスでは以下の検証を実行します:
158
+
159
+ - URLパースの確認
160
+ - 許可されたプロトコル(http:、https:、mailto:)のチェック
161
+ - 危険なローカルファイルURL(file:)の防止
162
+ - エラーハンドリングと適切なレスポンス返却
163
+
164
+ ## 5. 機密データの暗号化保存
165
+
166
+ ### 5.1 safeStorageの活用
167
+
168
+ Electronの`safeStorage`モジュールを使用して機密データを暗号化保存します。暗号化が利用可能かどうかをisEncryptionAvailable()で確認し、利用可能な場合のみ暗号化を実行します。
169
+
170
+ 認証情報保存時は、JSONオブジェクトを文字列化してからencryptStringで暗号化し、ファイルに保存します。読み込み時はファイルの存在確認後、暗号化データを読み込んでdecryptStringで復号化し、JSONとしてパースして返します。
171
+
172
+ ## 6. 依存関係とサプライチェーンセキュリティ
173
+
174
+ ### 6.1 依存関係の監査
175
+
176
+ 定期的にnpm auditコマンドでセキュリティ監査を実行します。脆弱性が発見された場合はnpm audit fixで自動修正を試みます。より詳細な脆弱性チェックにはnpx better-npm-audit auditを使用します。
177
+
178
+ ### 6.2 Electronバージョン管理
179
+
180
+ package.jsonでElectronのバージョンを管理し、定期的なアップデートチェックを行います。npm outdated electronでバージョン確認、npx electronegativityでセキュリティ分析を実行するスクリプトを設定します。
181
+
182
+ ## 7. 開発・デバッグベストプラクティス
183
+
184
+ ### 7.1 開発時のDevToolsアクセス制御
185
+
186
+ 開発時のみDevToolsを有効化し、本番環境では無効化します。process.env.NODE_ENVを使用して環境を判定し、webPreferencesのdevToolsオプションを制御します。
187
+
188
+ 本番環境では右クリックメニューも無効化し、context-menuイベントをpreventDefault()で阻止します。これによりユーザーがDevToolsにアクセスすることを防げます。
189
+
190
+ ### 7.2 ログとエラーハンドリング
191
+
192
+ electron-logライブラリを使用して適切なログ管理を行います。開発環境ではdebugレベル、本番環境ではwarnレベル以上のみを記録します。
193
+
194
+ 未処理例外をprocess.on('uncaughtException')でキャッチし、ログに記録します。レンダラープロセスのエラーはIPCを通じてメインプロセスに送信し、一元的にログ管理します。
195
+
196
+ ## 8. テスト戦略
197
+
198
+ ### 8.1 セキュリティテスト
199
+
200
+ セキュリティテストでは、レンダラープロセスにNode.js APIが公開されていないことを確認します。executeJavaScriptを使用してrequire、process、globalが未定義であることをテストします。
201
+
202
+ IPC送信元検証のテストでは、不正なオリジンからのメッセージが適切に拒否されることを確認します。テスト環境でElectronアプリを起動し、セキュリティ設定が正しく動作することを検証します。
203
+
204
+ ## 9. パッケージ化とデプロイメント
205
+
206
+ ### 9.1 electron-builderでの安全な配布
207
+
208
+ electron-builderを使用してアプリケーションを配布する際は、適切なセキュリティ設定を行います。
209
+
210
+ build設定では以下を指定します:
211
+ - appId:アプリケーション固有の識別子
212
+ - productName:アプリケーション名
213
+ - files:配布に含めるファイルと除外するファイル(テストファイルや型定義ファイルを除外)
214
+
215
+ macOS用設定では:
216
+ - hardenedRuntime:セキュリティ強化のため有効化
217
+ - entitlements:権限設定ファイルの指定
218
+
219
+ Windows用設定では:
220
+ - certificateFile:コード署名用証明書ファイル
221
+ - certificatePassword:環境変数からパスワード取得
222
+
223
+ ## セキュリティチェックリスト
224
+
225
+ ### 必須設定項目
226
+
227
+ - [ ] `nodeIntegration: false`
228
+ - [ ] `contextIsolation: true`
229
+ - [ ] `sandbox: true` (可能な場合)
230
+ - [ ] `webSecurity: true`
231
+ - [ ] 厳格なCSPの実装
232
+ - [ ] 権限リクエストハンドラの設定
233
+ - [ ] IPC送信元の検証
234
+ - [ ] contextBridgeによる安全なAPI公開
235
+ - [ ] shell.openExternalの適切な使用
236
+ - [ ] 機密データの暗号化(safeStorage)
237
+ - [ ] 依存関係の定期的な監査
238
+ - [ ] Electronバージョンの最新化
239
+
240
+ ### パフォーマンス項目
241
+
242
+ - [ ] メインプロセスでのブロッキング処理の排除
243
+ - [ ] 非同期I/Oの使用
244
+ - [ ] CPU集約的タスクのworker_threads活用
245
+ - [ ] 適切なメモリ管理とクリーンアップ
246
+ - [ ] イベントリスナの適切な削除
247
+ - [ ] 大きなオブジェクトの参照解除
248
+
249
+ ### 開発環境項目
250
+
251
+ - [ ] TypeScript型定義の整備
252
+ - [ ] 適切なビルドツール設定
253
+ - [ ] 開発時のホットリロード
254
+ - [ ] セキュリティテストの実装
255
+ - [ ] 本番環境でのDevTools無効化
256
+ - [ ] 適切なログ管理とエラーハンドリング
257
+
258
+ このガイドに従うことで、セキュアで高性能、かつ保守性の高いElectronアプリケーションを構築することができます。
@@ -0,0 +1,47 @@
1
+ ---
2
+ type: prompt
3
+ category: todo-planning
4
+ focus: workflow-management
5
+ ---
6
+
7
+ # TODO Plans 作成ルール
8
+
9
+ ## 基本ルール
10
+
11
+ - 今後の計画を立てる際は、必ず `todo_plans/` に記載する
12
+ - ファイル名規則は、`YYYYMMDD_[タイトル].md`
13
+ - 計画が不要になった場合は削除する。Git の履歴で過去の計画は追跡できるため、アーカイブせずにリポジトリをすっきり保つ
14
+
15
+ ## ワークフロー管理
16
+
17
+ ### todo_plans の役割
18
+
19
+ #### todo_plans段階
20
+
21
+ - **目的**: 将来の計画とアイデアの整理
22
+ - **期間**: プロジェクトのアイデア段階
23
+ - **成果物**: 計画の概要と方向性
24
+ - **品質基準**: 実現したいことが明確に記述されている
25
+
26
+ ## 実践ガイドライン
27
+
28
+ - 将来実装したい機能やアイデアは、必ず todo_plans/ に記載する
29
+ - 計画の内容は、実現したいことと大まかな方向性を記述する
30
+ - 詳細な実装方法は不要。コンセプトレベルで十分
31
+ - 計画が変更されたり不要になった場合は、ファイルを削除してリポジトリを整理する
32
+
33
+ ## ファイル名規則の例
34
+
35
+ ```
36
+ todo_plans/
37
+ ├── 20250911_API機能拡張構想.md
38
+ ├── 20250911_パフォーマンス改善アイデア.md
39
+ └── 20250911_新機能企画書.md
40
+ ```
41
+
42
+ ## 注意事項
43
+
44
+ - todo_plans は「将来やりたいこと」「検討したいアイデア」の整理段階
45
+ - 具体的な実装計画ではなく、方向性やコンセプトを記録する
46
+ - 実装に着手する際は、別途 change_plans でより詳細な計画を立てる
47
+ - 長期的なビジョンや中期的な目標の管理に活用する
package/dist/cli.d.ts CHANGED
@@ -1,3 +1,6 @@
1
1
  #!/usr/bin/env node
2
- export {};
2
+ /**
3
+ * Recursively scans a directory for YAML files and returns their relative paths
4
+ */
5
+ export declare function findYamlFilesRecursively(dir: string, baseDir?: string): Promise<string[]>;
3
6
  //# sourceMappingURL=cli.d.ts.map
package/dist/cli.d.ts.map CHANGED
@@ -1 +1 @@
1
- {"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":""}
1
+ {"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AAygBA;;GAEG;AACH,wBAAsB,wBAAwB,CAAC,GAAG,EAAE,MAAM,EAAE,OAAO,GAAE,MAAY,GAAG,OAAO,CAAC,MAAM,EAAE,CAAC,CAyBpG"}