Phase 10
Governance & Maintenance

Introduction

デザインシステムは、更新され続けて初めて機能する

Design Principlesを一度作成しても、 新機能、画面改修、AIによる実装、例外対応が積み重なると、 少しずつルールと実装の差が広がります。

新しい色が画面へ直接追加される。 同じ役割のカードが別名で増える。 仕様書と実装が違うまま放置される。 こうした小さな差が、製品全体の一貫性を壊します。

この章で定義するもの

01 — Governance Principles

1ガバナンスの原則

最上位ルール

02 — Ownership

2管理責任者と役割

Design Principles管理者

Knowledge OS Design Principlesには、必ず1名以上の管理責任者を設定します。

主な責任

小規模体制の場合

1人が複数の役割を兼任しても構いません。 ただし、役割ごとの確認項目は省略しません。

03 — Versioning

3バージョン番号

形式

MAJOR.MINOR.PATCH

例：
1.0.0
1.1.0
1.1.1
2.0.0

文書状態

版の表示場所

• 文書表紙
• ファイル名
• 変更履歴
• AI向け指示テンプレート
• リリース記録

04 — Change Log

4変更履歴

変更履歴に必要な項目

変更履歴の粒度

• 意味や実装が変わる変更は必ず記録する。
• 誤字修正もPATCHとして記録する。
• 「修正」「改善」だけで済ませない。
• なぜ変更したかを残す。

05 — Change Process

5追加・変更・廃止のルール

標準フロー

廃止の3段階

1. 非推奨として明記する
2. 新規利用を禁止し、既存利用を移行する
3. 利用箇所がなくなった後に削除する

禁止事項

• 実装を先に変更し、設計書を後回しにする
• 影響調査なしで共通部品を変更する
• 移行計画なしで既存部品を削除する
• AIの提案だけを理由にルールを追加する

06 — New Component Approval

6新規コンポーネントの承認条件

承認条件

• 既存コンポーネントでは解決できない
• 2画面以上で再利用する可能性がある
• 役割と責務が1つに絞られている
• 状態・サイズ・アクセシビリティが定義されている
• Phase 3のDesign Tokenのみを使用する
• Lucide Iconsを使用する
• 使用例と禁止例がある
• テストがある

申請に必要な情報

07 — Exceptions

7例外を認める条件

Design Principlesから外れる必要がある場合は、 例外申請として記録します。

例外を認められる条件

• 法令・契約・外部仕様への対応が必要
• 既存業務を停止できない
• 技術的制約で直ちに準拠できない
• 利用者検証により標準ルールが適さないと分かった

例外申請に必要な情報

08 — Deprecation

8非推奨コンポーネントと廃止予定UI

非推奨一覧に必要な情報

廃止予定UIの例

• Bootstrap Tableを使った旧資料一覧
• 英語見出しを含む旧設定画面
• Bootstrap Icons（bi-robotなどのbi-*クラス）。新規利用は禁止し、対象画面の改修時にLucide Iconsへ移行する（bi-robot → Bot / MessageCircleQuestionなど用途別に置換）
• Lucide以外のその他の旧アイコン
• 画面ごとに独自実装された旧ダイアログ
• 色だけで状態を示す旧バッジ

移行ルール

1. 新規実装で使用しない。
2. 既存利用箇所を一覧化する。
3. 代替部品へ段階的に移行する。
4. 利用箇所が0件になったことを確認する。
5. コード・設計書・ヘルプから削除する。

09 — AI Distribution

9Cursor・Claude・Codexへの読み込ませ方

正式版の渡し方

• Current状態の最新版だけを渡す
• バージョン番号をプロンプトに明記する
• 対象タスクに必要な章を指定する
• 変更履歴を必要に応じて添付する
• 旧版を参照しないよう明記する

共通プロンプト

Knowledge OS Design Principles v1.0.0の正式版に従ってください。

参照対象：
- Phase 3：UI Design System
- Phase 4：Screen Guidelines
- Phase 5：AI Development Rules
- Phase 6：Content Design & Terminology
- Phase 7：Trust, Privacy & AI Safety
- Phase 8：States, Permissions & Failure
- Phase 9：Accessibility & Quality Assurance
- Phase 10：Governance & Maintenance

旧版、過去のスクリーンショット、非推奨コンポーネントを
新規実装の根拠にしないでください。

AIごとの参照範囲

10 — Spec vs Implementation

10設計書と実装が異なる場合

差異の扱い

設計書と実装に差が見つかった場合は、 次のどちらかを正式に決定します。

差異解消フロー

1. 差異を記録する。
2. なぜ差が生じたか確認する。
3. 利用者・業務・技術への影響を評価する。
4. どちらを正とするか決定する。
5. 設計書・実装・テスト・ヘルプを更新する。
6. 変更履歴へ記録する。

禁止事項

• 「実装が動いているから正しい」と判断する
• 設計書だけを更新し、実装を放置する
• 差異を既知の問題として無期限に残す
• AIが変更した内容を確認せず新仕様とする

11 — Documentation Sync

11スクリーンショット・ヘルプ更新

更新が必要な条件

• 画面レイアウトが変わった
• ボタン名が変わった
• 操作手順が変わった
• 状態表示が変わった
• 設定項目が追加・削除された
• エラー対応方法が変わった

スクリーンショット更新ルール

• 正式版の画面だけを使用する。
• 個人情報や実データを含めない。
• 表示倍率と画面サイズを揃える。
• 古い画面画像を同じ記事内に残さない。
• 画像だけでなく説明文も更新する。

ヘルプ更新ルール

1. 実装変更と同じタスク内で更新する。
2. 実際の画面名・ボタン名と一致させる。
3. 旧手順を削除する。
4. 検索キーワードを更新する。
5. 変更履歴を残す。

12 — Release Check

12リリース前チェック

Design System確認

• 最新版のDesign Principlesを参照している。
• 新しい色がDesign Tokenへ追加されている。
• 新しい共通部品がPhase 3へ追加されている。
• 非推奨部品を新規利用していない。
• 例外が記録されている。

実装確認

• ビルドが成功している。
• 型チェックとlintが成功している。
• 主要画面を確認している。
• Empty、Loading、Errorを確認している。
• アクセシビリティ確認が完了している。

文書確認

• Design Principlesを必要に応じて更新した。
• 変更履歴を更新した。
• ヘルプを更新した。
• スクリーンショットを更新した。
• AI向けテンプレートの版を更新した。

リリース記録

【Design Principles Version】
1.1.0

【変更した章】
Phase 3 / Phase 4 / Phase 6

【追加した共通コンポーネント】
DocumentStatusCard

【非推奨化した部品】
LegacyDocumentTable

【例外】
なし

【ヘルプ更新】
完了

【スクリーンショット更新】
完了

13 — Design System Audit

13Design System監査

監査対象

• 色・余白・文字サイズ
• ボタン・カード・ダイアログ
• Lucide Icons
• 日本語文言
• 状態表示
• アクセシビリティ
• 非推奨部品の残存
• 設計書と実装の差異

監査方法

監査結果

• 問題箇所
• 影響範囲
• 優先度
• 修正担当
• 修正期限
• 再確認日

14 — Quarterly Review

14四半期ごとの見直し

見直し項目

• 新しく増えた画面・機能を確認する。
• 重複コンポーネントを確認する。
• 例外の期限を確認する。
• 非推奨部品の移行状況を確認する。
• 利用者からの問い合わせを確認する。
• アクセシビリティ問題を確認する。
• AIによる実装のばらつきを確認する。
• ヘルプと画面の差異を確認する。

見直し結果の分類

四半期レビュー記録

【期間】
2026年7月〜9月

【確認した画面】
ホーム、資料、検索、AIに聞く、設定

【主な問題】
状態カードが3種類に重複

【決定】
DocumentStatusCardへ統合

【期限】
2026年10月31日

【Design Principles更新】
Phase 3、Phase 8を更新予定

15 — AI Governance Rules

Cursor・Claude・Codex向けガバナンス指示

共通指示

Knowledge OS Design PrinciplesのCurrent版のみを参照してください。

変更前に確認すること：
- Design Principlesのバージョン
- 対象章
- 既存コンポーネント
- 非推奨コンポーネント
- 既存の例外
- 変更履歴

変更時のルール：
- 新しい色はDesign Tokenへ追加する
- 新しい共通コンポーネントはPhase 3へ追記する
- 既存ルールと異なる実装は例外として記録する
- 設計書と実装のどちらか一方だけを変更しない
- ヘルプとスクリーンショットを同時に更新する
- 非推奨部品を新規利用しない
- 完了報告にDesign Principlesへの影響を書く

完了報告に追加する項目

• 参照したDesign Principlesのバージョン
• 変更した章
• 追加したDesign Token
• 追加・変更した共通コンポーネント
• 非推奨化した部品
• 例外の有無
• ヘルプ更新の有無
• スクリーンショット更新の有無

16 — Review Checklist

ガバナンス・保守チェックリスト

版管理

• 正式版が1つに定まっている。
• バージョン番号が表紙とファイル名にある。
• 旧版がArchivedとして区別されている。
• AIへ渡す版が明確である。

変更管理

• 変更理由が記録されている。
• 影響範囲が確認されている。
• Design Principlesと実装が同時に更新されている。
• 移行期限が設定されている。

コンポーネント

• 既存部品で解決できないことを確認した。
• 新規部品がPhase 3へ追記されている。
• 非推奨部品の代替が定義されている。
• 利用箇所が追跡できる。

文書・ヘルプ

• 変更履歴を更新した。
• スクリーンショットを更新した。
• ヘルプを更新した。
• AI向けプロンプトを更新した。

監査

• 四半期レビューを実施した。
• 例外の期限を確認した。
• 非推奨部品の移行を確認した。
• 設計書と実装の差異を確認した。

Definition of Done

Phase 10の完成条件

• Design Principlesの管理責任者が決まっている。
• バージョン規則が決まっている。
• 変更履歴の形式が決まっている。
• 追加・変更・廃止フローが決まっている。
• 新規コンポーネント承認条件がある。
• 例外申請と期限管理がある。
• 非推奨一覧と代替部品が管理されている。
• AIへ渡す正式版が定まっている。
• 設計書と実装の差異解消ルールがある。
• ヘルプ・スクリーンショットの同期ルールがある。
• リリース前チェックがある。
• Design System監査がある。
• 四半期レビューが予定されている。

Closing

製品の一貫性は、運用で守る

優れたDesign Principlesを作っても、 更新方法が決まっていなければ、少しずつ使われなくなります。

新しい機能、新しいAI、新しい開発者が加わっても、 同じ製品として成長できるようにすることが、 Governance & Maintenanceの役割です。

最終原則

1. Design Principlesを製品仕様として扱う。
2. 管理責任者を明確にする。
3. 正式版を一つにする。
4. 変更理由と影響を残す。
5. 設計書と実装を同時に更新する。
6. 新規部品を無秩序に増やさない。
7. 非推奨と廃止を段階的に管理する。
8. AIへ同じ版を渡す。
9. ヘルプと画面を同期する。
10. 定期監査と四半期見直しを行う。

Knowledge OS Design Principles v1.0.0
Phase 10 — Governance & Maintenance
Governance, Versioning and Design System Operations