SystemNoteシリーズ開発運用ガイド V1

目的

SystemNote・PrismNote・和綴手帖を長期的に開発するために、

設計者の意図を正しく反映する
個別パッチを増やさない
無駄な修正を減らす
AIによる開発速度を活かす
将来の仕様変更に対応しやすくする
製品版の品質を安定させる

ことを目的とする。

1. 開発開始前

開発を始める前に、必ず次の4点を確認する。

1-1. 今回の目的

「何を直すか」ではなく、

なぜ直すのか

を最初に定義する。

例：

悪い例

スマホ時の右余白を5px減らして。

良い例

スマホ時に用紙幅を最大限利用したい。
個別px補正ではなく、全機能共通のページ余白設計として修正する。

1-2. 対象範囲

修正対象を明確にする。

例：

SystemNoteのみ
3製品共通
予定機能のみ
全モジュール共通
PCのみ
スマホのみ
1P / 2P共通

1-3. 変更禁止部分

既に完成している部分を不用意に変更しない。

必要であれば、

指定部分以外のデザイン・機能・データ構造は変更しない。

と明記する。

1-4. 完了条件

実装前に、

何をもって完成とするか

を決める。

例：

360px～1920pxで破綻しない
PC / スマホで操作可能
1P / 2Pで同じデータを表示
戻る操作でログイン画面へ抜けない
既存データを破壊しない

2. AIが最初に行うこと

コードをすぐ変更しない。

最初に既存構造を確認する。

確認対象：

HTML構造
CSS構造
JavaScript構造
共通処理
製品固有処理
データ構造
イベント処理
レスポンシブ処理
重複コード
過去のパッチ

そのうえで、

症状ではなく原因を特定する。

3. 実装判断の順番

修正要求を受けたら、必ず次の順番で考える。

設計意図
↓
原因
↓
共通化できるか
↓
影響範囲
↓
最小で構造的な修正
↓
テスト
↓
不要コード削除

禁止する流れ：

指示
↓
CSSを追加
↓
見た目が直った
↓
終了

4. 開発時の基本プロンプト

今後の開発開始時には、以下を基本プロンプトとして使用する。

SystemNote共通開発プロンプト

あなたはSystemNoteシリーズの長期開発担当者です。

今回の修正だけを局所的に直すのではなく、既存構造を確認し、設計意図を理解したうえで修正してください。

以下を必ず守ってください。

個別パッチを安易に追加しない
症状ではなく原因を修正する
共通化できるものは共通構造で修正する
同じ処理・CSSを重複させない
不要なコードを増やさない
修正後に不要になった旧コードを削除する
CSSは固定px中心ではなく、rem / em / % / fr / minmax / clamp等の相対設計を優先する
固定heightは必要最小限とし、原則min-heightを検討する
CSS Grid / Flexboxによる自然なレイアウトを優先する
JavaScript・CSS・HTMLの命名規則を統一する
同じ概念に複数の名称を使用しない
バージョン番号・fix・temp・patch等をクラス名や関数名に残さない
PC / スマホ / 1P / 2Pへの影響を確認する
SystemNote・PrismNote・和綴手帖で共通化できる変更は共通仕様として扱う
sourceコードは人間とAIの双方が理解できる可読性を維持する
製品配布時のみminify・圧縮する
データ形式・保存・バックアップをUIより重要な長期資産として扱う
指示に設計上の問題がある場合は、そのまま実装せず問題点を指摘する
過剰設計は避け、現在必要な最小構造で将来変更しやすくする
修正完了後は必ず回帰テストを行う

最終判断基準は、

「今回動くか」ではなく、

「製品全体として正しく、次回の変更を容易にするか」

としてください。

5. 個別修正の依頼方法

今後は、修正指示を次の形式にすると精度が上がる。

【目的】
スマホで用紙をできるだけ広く表示したい。

【対象】
全機能共通・スマホのみ。

【現象】
右側に不要な余白がある。

【希望】
個別のmargin補正ではなく、
共通ページレイアウトの構造として修正。

【変更禁止】
PC 2P表示、リング位置、タブ位置は変更しない。

【完了条件】
360 / 375 / 390 / 430pxで
横スクロールが出ず、
左右余白が自然に揃うこと。

この形式ならAIが意図を理解しやすい。

6. 新機能追加時

新機能を追加する場合は、いきなり実装しない。

まず以下を決める。

6-1. 機能の目的

例：

人生年表

目的：

人生で重要だった出来事だけを残し、
後から自分の人生を振り返れるようにする。

6-2. 既存機能との関係

例：

人生年表は独立データ入力を中心にせず、

予定
日記
記念日
アルバム

から参照する。

6-3. 共通データ

例：

sourceType
sourceId
date
title
personIds
imageIds

などを共通化する。

6-4. UI

SystemNoteの世界観に合わせる。

例：

登録
→ 人生年表に残す

お気に入り
→ しおり

画像アップロード
→ 写真を貼る

ログイン
→ 手帳を開く

7. CSS開発ルール

原則

文字：

rem

文字に比例するサイズ：

em

余白：

rem

ページ幅：

%
fr
minmax()
min()
max()
clamp()

罫線：

1px

避けるもの

margin-left: 7px;
top: -3px;
width: calc(100% - 14px);

などの局所補正。

必要な場合は、なぜ必要なのか確認する。

8. 命名規則

JavaScript

camelCase

例：

openPage()
saveEntry()
findPerson()
lifeTimeline
personIds

CSS

kebab-case

例：

.book-page
.page-title
.person-link
.life-timeline

状態：

.is-active
.is-open
.is-hidden

定数

UPPER_SNAKE_CASE

例：

APP_VERSION
SCHEMA_VERSION
MAX_IMAGES

禁止

fix2
new3
temp
rn28
v15-title
box1
data2
final-new

9. sourceと製品版を分離する

開発原本：

src/

製品配布版：

dist/

原本は読みやすさを維持する。

配布時に、

HTML minify
CSS minify
JavaScript minify
コメント削除
不要コード削除
ファイル統合

などを行う。

難読化は原則不要。

10. テストの基本構成

テストは4段階で行う。

第1段階

機能テスト

各機能について、

新規
編集
削除
保存
検索
フィルタ
戻る
ページ切替

を確認する。

第2段階

UIテスト

最低限以下を確認する。

PC

1280
1366
1440
1920

スマホ

タブレット

768前後
縦
横

第3段階

破壊テスト

正常なデータだけを使わない。

例：

長文

予定タイトル100文字以上
日記5,000～10,000文字
長い人物名
長い会社名

大量データ

予定数千件
家計簿1万件
住所録数千件
写真複数枚

画像

横長
縦長
大容量
複数画像

第4段階

実環境テスト

最低限：

Windows Chrome
Windows Edge
Firefox
macOS Safari
iPhone Safari
Android Chrome

11. 自動UIテスト

Playwright等を使用し、

主要操作を自動化する。

例：

ログイン
↓
予定を開く
↓
新規登録
↓
編集
↓
保存
↓
人生年表へ追加
↓
人物リンクを開く
↓
戻る
↓
TOP
↓
手帳を閉じる

この一連の操作を、

複数画面サイズで繰り返す。

12. AIによる探索型QA

固定テストだけでなく、

AIに、

SystemNoteを壊すつもりで自由に操作してください。

と依頼する。

AIは、

高速タブ切替
戻る連打
1P / 2P連続切替
モーダル連続開閉
画面幅変更
長文入力
大量登録
再読み込み
ロック
再ログイン

などを試す。

13. 不具合報告形式

AIが不具合を発見した場合、

以下の形式で記録する。

不具合ID：
重要度：

発生環境：
画面サイズ：
ブラウザ：

再現手順：

期待結果：

実際の結果：

原因候補：

修正方法：

影響範囲：

修正後確認：

14. 不具合重要度

A：販売不可

データ消失
ログイン不能
保存不能
操作不能
スクロール不能
復元不能

B：V1で必ず修正

重なり
文字切れ
ボタン切れ
モーダルはみ出し
戻る動作異常
1P / 2P不整合

C：販売後でも可

1～2pxの差
微妙な余白
軽微なアニメーション差
色の微調整

15. データテスト

最重要。

以下を必ず確認する。

登録
↓
終了
↓
再起動
↓
データ確認

さらに、

バックアップ
↓
全データ削除
↓
復元
↓
完全一致確認

まで行う。

16. スマホ特有テスト

特に確認する。

ブラウザ戻る
スワイプ戻る
ソフトキーボード
縦横回転
画面再読込
タブ復帰
スクロール
safe-area
画像選択
長押し
タップ領域

17. 修正後の回帰テスト

一つ直したら、その画面だけを確認しない。

例：

予定画面のページ余白を直した場合、

日記
家計簿
住所録
資産
アルバム

も確認する。

共通CSSを変更した場合は全機能確認。

18. 開発終了時

作業終了前に、

必ず以下を行う。

不要CSS削除
不要JavaScript削除
重複イベント削除
古いパッチ削除
使用されていないクラス確認
consoleエラー確認
自動テスト実行
主要画面確認
バックアップ確認
バージョン更新

19. 製品版ビルド

最終製品では、

src
↓
テスト
↓
minify
↓
dist
↓
製品版テスト
↓
ZIP

とする。

重要なのは、

minify前だけではなく、minify後の製品版もテストすること。

20. V1完成条件

SystemNote V1製品版は、

以下を満たして初めて完成とする。

Aランク不具合 0
Bランク重大不具合 0
PC主要ブラウザ正常
iPhone正常
Android正常
360～1920px主要表示正常
1P正常
2P正常
戻る操作正常
IndexedDB正常
バックアップ正常
復元正常
大量データ正常
長文入力正常
画像処理正常

21. 今後の開発サイクル

SystemNoteは以下を繰り返す。

要望
↓
設計意図確認
↓
既存構造調査
↓
設計判断
↓
実装
↓
自動テスト
↓
AI探索テスト
↓
実機テスト
↓
整理
↓
製品ビルド
↓
利用者の反応
↓
次の改善

最重要原則

AIに「直して」と頼むのではなく、
「設計意図を守りながら、最も構造的な方法で直して」と頼む。

テストは完成後に行うものではなく、開発工程の一部とする。

sourceは未来の開発資産、distは現在の製品。

一つの修正で一つの問題だけを直すのではなく、同種の問題が起きにくい構造へ改善する。

SystemNoteは短期開発ではなく、一生使える製品として長期開発する。

SystemNoteシリーズ 開発運用ガイド V1

目的