GitHub連携・制作管理 / 非公式Figmaガイド
FigmaとGitHubのバージョン管理
設計変更とコード変更の履歴を分けて確認します。
figmaguide.jp はFigma公式サイトではありません。Figmaの公式発表、料金、機能、仕様、提供範囲は必ず公式情報で確認してください。このサイトでは、FigmaをWebデザイン、LP設計、Codex連携、AIガイド群での制作確認に使うための考え方を整理しています。
このページでできること
Figma設計、Codex実装、GitHub管理、PR確認、Secrets注意をつなげます。 設計変更とコード変更の履歴を分けて確認します。
Figmaで確認すること
Figmaでは、見た目だけでなく、目的、読者、導線、余白、スマホ表示、公開前の安全注意を分けて確認します。AIに任せる前に、人間が決める範囲を整理します。
役割分担の比較表
| 確認すること | Figmaで見ること | AIサイト群での役割 |
|---|---|---|
| 目的 | 何を設計するページかを決める | ChatGPTで文章、Figmaで設計、Codexで実装へつなぐ |
| レイアウト | 見出し、余白、カード、CTA、画像配置を見る | Canva素材やCodex実装へ渡しやすくする |
| スマホ確認 | 390px前後で読めるか確認する | Codex公開前チェックへつなぐ |
| 安全注意 | 共有範囲と未公開情報を確認する | HALやGitHub Secrets注意へつなぐ |
チェックリスト
- PRとdiffを確認した
- Secretsや.envをcommitしない
- privateでも安全と思い込まない
- Figma公式サイトではない前提を明記している
- 個人情報、会社情報、顧客情報を入れていない
- 公式ロゴ、公式画像、公式UIスクリーンショットを使っていない
- 料金、仕様、提供範囲、成果を断定していない
安全注意
個人情報、会社情報、顧客情報、APIキー、token、Secrets、.env を掲載しないでください。Figmaファイルを外部AIへ渡すときは、伏せる情報と共有してよい情報を分けてから相談します。
AIサイト群の導線
何を「版」として扱うか決める
デザインの履歴管理でつまずくのは、何をもって1つの版とするかが決まっていないためです。次のどれかに決めてください。
- 共有した時点 — 誰かに見せた形を版とする。あとで「どれを見せたか」を辿れます
- 実装に渡した時点 — 開発と対応が取れます
- 日付で区切る — 単純ですが、意味のある区切りになりません
実務では1番目か2番目が使えます。3番目は運用が続きません。区切りに意味が無いと、あとで見返す理由が生まれないためです。
名前の付け方を先に決める
履歴に名前を付けられる場合、書き方を統一してください。後から探せるかどうかが変わります。
- 何を変えたか — 「配色調整」「導線変更」
- 誰に渡したか — 「◯◯様確認用」
- 実装との対応 — 対応する画面名や課題番号
「修正」「更新」だけの名前は付けないでください。全部の履歴が同じ名前になり、探せなくなります。1行でよいので、何を変えたかを書いてください。
戻せる状態を保つ
履歴があっても、戻せなければ意味がありません。次を確認しておいてください。
- どこまで遡れるか — プランによって保存期間が変わることがあります
- 戻した時に何が失われるか — コメントや共有設定は戻らないことがあります
- 戻す前に今の状態を複製できるか
3番目を習慣にしてください。戻した後で「やっぱり今の方が良かった」となる場面は珍しくありません。複製を1つ作ってから戻せば、どちらも失いません。
チームで運用する時に決めること
1人で使う分には自由ですが、複数人で触ると決め事が要ります。
- 誰が版を確定させるか — 全員が付けると意味が薄れます
- 作業中のファイルをどう区別するか — 名前か置き場所で分ける
- 過去の版をいつ整理するか
1番目を決めておかないと、履歴が「誰かが何かした記録」の羅列になります。版を付ける人を決めるだけで、履歴が読めるものになります。