■ 1. AI活用デザインで失われる意思決定
- 最終デザインだけが残る問題:
- AIチャットやAIコーディングツールを使い、提案や修正指示を重ねながらデザインする機会が増えている
- なぜその修正をしたのか、なぜその案を採用したのか、どの案を検討して見送ったのかが後からたどれない
- 担当交代時に発生した探索コスト:
- プロダクトの担当デザイナーが変わったとき、なぜこの画面になったのかを確認するために過去資料やSlackを大量に遡った
- 経緯を知っていそうなメンバーへの確認も必要になった
- 記憶依存がもたらす弊害:
- 修正の意図や判断基準が担当者の記憶に依存すると、別のメンバーは推測でしか説明できない
- 同じ議論を繰り返しやすくなる
- デザイナー、エンジニア、プロダクト担当者の間で判断の前提や優先した条件を共有することも難しくなる
■ 2. DDRという考え方
- DDR(Design Decision Record):
- デザインに関する重要な意思決定と、その背景や検討内容を記録するもの
- ADRからの適用:
- ソフトウェア開発には重要なアーキテクチャ判断とその背景や結果を記録するADR(Architecture Decision Record)がある
- DDRはこの考え方をデザイン上の判断へ適用する呼び方として扱う
- 記録対象は完成画面の説明ではない:
- なぜ変更が必要だったのか、どの判断を採用したのか、どの案を比較したのか、変更によって何に影響するのかを整理する
- 後から確認できる形にまとめる
■ 3. DDRの記録項目
- 規格は未確立:
- 業界横断のOpen Standardな規格として定められたものは現時点で存在しない
- ADRの思想を参考にしながら、チームの運用に合わせて構成する
- 基本情報の項目:
- 記録ID、記録日、担当者を記録する
- 関連スコープとして、どのデザインや運用の範囲に関係するかを記録する
- 変更種別として、表記調整、意味変更、判定基準変更、ルール逸脱の承認記録のいずれかを記録する
- 関連ファイルとして、判断に関係するファイルや資料を記録する
- 判断内容の項目:
- 背景として、何を含めたいのか、現状のどこが判断しづらいのかを記録する
- 決定内容として、変更後に採用する判断基準を記録する
- ルール逸脱時の記録として、逸脱した内容、許容理由、根本原因、再発防止策を記録する
- 比較した代替案として、採用案と比較した選択肢を記録する
- 影響と追跡の項目:
- 影響範囲として、ルール、ドキュメント、レビュー運用への影響を記録する
- 検証計画として、代表ケースと、PassまたはNeeds Fixを見分ける方法を記録する
- フォローアップとして、次の版へ含めるか、保存先、実装予定、再発確認の予定を記録する
■ 4. 自動記録という発想
- 手作業運用は形骸化する:
- デザイン確定後に毎回手作業で整理する運用はコストがかかり、形骸化しやすい
- 対話履歴は資産:
- AIとの対話には、デザイン案が確定するまでにデザイナー自身が行った比較、修正、判断が豊富に含まれている
- これを資産とせず、その場限りのものとして捨ててしまうのは非常にもったいない
- 同じ作業ターンでの下書き生成:
- AIエージェントとデザイン作業を行う同じ作業ターンで、対話コンテキストと変更差分を解析しDDRの下書きを自動生成する
- 記録を別の作業として追加せず、普段のAIエージェントによる作業フローに組み込む
- 下書き生成まで自動化し、記録の負担を下げることを重視した
■ 5. 構築した環境
- 前提とする環境:
- Figma等のデザインツールに加え、AIコーディングエージェントを用いたデザインも行っている
- 紹介する仕組みは、AIコーディングエージェントによるデザイン作業とGit管理のドキュメント運用を組み合わせた環境を前提とする
- AIが作業時に参照する指示ファイルを説明上instructions.mdと表記する
- 実際のファイル名や配置は、利用するAIツールやチームのリポジトリ構成に合わせて読み替える
- 各要素の役割:
- AIエージェントはデザインの検討・修正を対話しながら進める
- instructions.mdはDDRを作成する条件と、対話履歴・変更差分をFMTへ整理する手順を定義する
- templates/ddr.mdは記録項目を定めたFMTであり、AIが下書きを作るときの出力形式になる
- docs/ddr/は生成・確認済みのDDRを保存し、過去の判断を参照するための記録場所になる
- GitリポジトリはFMTやDDRを含む判断材料を、変更履歴とともに管理する
- .husky/pre-commitなどのpre-commit hookは、コミット前に意味のある変更に対応するDDRが存在するか検査する
- 統合による効果:
- AIコーディング環境、AIエージェントによる作業、テンプレートへの出力、Gitのコミット前チェックをつなぐ
- これにより実装(デザイン)フローにDDRの記録を組み込める
■ 6. 自動記録処理の流れ
- 7段階のフロー:
- デザイナーがAIエージェントにデザインの検討や修正を依頼する
- AIエージェントが作業時にinstructions.mdを参照する
- DDRの記録対象となる変更であれば、対話コンテキストと変更差分を使って情報を整理する
- AIエージェントがDDRの下書きを生成する
- 人間が下書きを確認し、必要に応じて補完する
- DDRを保存し、後から参照できる状態にする
- pre-commit hookで、意味のある変更にDDRが作成されているかを検査する
- 都度指示によるDDRの生成も可能
■ 7. instructions.mdとhookの役割分担
- 役割を分離する方針:
- AIにDDRを作らせる部分と、記録漏れを検出する部分を分けている
- instructions.mdの役割:
- DDRの作成条件と手順を示して記録させる
- 誤字や体裁の変更ではなく、ルール、判定基準、エージェントの実行フローなどに意味のある変更が入ったときに作成する
- AIが対話履歴や変更差分を読み取り、DDRに記述する内容を整理する
- 生成したDDRは、作業中の判断理由が残っているうちに保存する
- pre-commit hookの役割:
- instructions.mdだけでは記録漏れを機械的に防げない
- Gitで変更を履歴として確定する直前に自動実行されるチェックである
- 成果物をGitで管理していれば、デザイン作業であってもこのタイミングでDDRの有無を確認できる
- 対象範囲に実質的な変更があるのに新しいDDRが含まれていなければ、コミットを止めてDDRの作成を促す
- 組み合わせの効果:
- 対話の文脈を使った柔軟な記録と、Git操作を利用した記録漏れの検査を組み合わせられる
- 人間による確認が前提:
- 生成されるのはあくまでDDRの下書きであり、内容は人間が確認し、必要に応じて補完するのがよい
■ 8. AIチャットツール利用時の運用
- 会話の区切りで下書き生成を依頼:
- ChatGPTやGeminiなどGitと直接連携しないツールでは、会話の区切りでAIにDDRの下書き生成を依頼する
- 会話の最後にこの対話からフォーマットに沿ってDDRの下書きを作るよう指示し、生成内容を人間が確認して保存する
- 背景へ戻れる情報を添える:
- DDRに会話の共有URLや関連する対話の抜粋など、判断の背景へ戻れる情報も添えておくとよい
- 低コストな導入:
- 自動で履歴を取得したりhookで検査したりする仕組みがなくても始められる
- まずは同じフォーマットで記録する流れを作れば低コストで始められる
■ 9. 今後の展望
- 複数人による意思決定の取り込み:
- ここまでの仕組みは個人のAIエージェントとの対話を主な入力にしている
- 会議やSlackなど、AIとの対話以外でも意思決定は発生する
- こうした判断をどのように拾い、DDRとして残すかは今後の課題
- 会話の文脈や合意内容をどこまで記録するかも含め、チームの資産として活用できる形を検討していく
- 蓄積したDDRの一元管理:
- DDRが大量に増えると、必要な判断を探し出すこと自体が難しくなる
- 複数のプロダクトやプロジェクトをまたいでも、記録の粒度や分類を保ちながら過去の背景へたどり着ける状態が必要
- 複数プロダクト間で横断的に発生するデザイン課題をDDRから拾えれば、デザインシステムやプロセスの改善に活かせる
■ 10. まとめ: 意思決定の資産化
- 概念の理解が出発点:
- DDRの概念や思想を知ることで、デザインの判断理由を残すために何を整理すればよいかが分かる
- 小さくても記録を積み重ねることで、次の担当者や次の判断を助ける資産になる
- 継続には仕組みが必要:
- 記録の重要性を共有するだけでは形骸化しやすい
- 記録にかかる手間を小さくし、AIに下書き生成を任せて人間は確認と補完に集中できる仕組みが継続的な運用につながる
- 目指す姿:
- 担当者やプロダクトが変わっても知見が受け継がれる状態を目指す
- 個々のデザイン判断が、組織全体の次の意思決定を支えるデザイン資産になることを目指す