Penpotとは？オープンソース設計ツールの特徴・使い方・違いを徹底解説

Penpotとは、ウェブサイトやアプリケーションの画面設計、試作品作成、部品管理、開発者への受け渡しをひとつの流れで扱える、オープンソースの設計プラットフォームです。公式サイトでも、Penpotはデジタル製品を大規模に作るチーム向けのオープンソース設計プラットフォームとして説明されており、設計、コード、人工知能を使った作業の連携を重視しています。つまりPenpotは、単に画面をきれいに作るための道具ではなく、製品開発そのものを前に進めるための共同作業環境だと考えると理解しやすいです。

近年の製品開発では、デザイナーだけが画面を作り、開発者が後からそれを見て実装するという分断された進め方では、修正の往復が増えやすくなっています。色、余白、文字サイズ、部品の状態、画面遷移などを正確に共有できないと、完成画面が設計意図からずれてしまいます。Penpotは、こうした設計と実装の間にあるズレを減らし、デザイナー、開発者、企画担当者が同じ設計情報を見ながら会話できる点に価値があります。

さらにPenpotは、クラウドで使えるだけでなく、自社環境に置いて運用する選択肢もあります。公式のリポジトリでは、Penpotがブラウザ利用または自社運用に対応し、SVG、CSS、HTML、JSONなどの標準技術と連携することが説明されています。外部サービスだけに依存せず、設計データの管理方針を組織側で決めたい企業にとって、この自由度は大きな意味を持ちます。

1. Penpotとは

Penpotとは、画面設計、試作品作成、共同編集、設計資産の管理、開発者向け確認をまとめて行える設計ツールです。ここでは、Penpotを初めて知る人でも全体像をつかめるように、何をするための道具なのか、どのような現場で使われるのか、なぜオープンソースであることが重要なのかを整理します。

1.1 Penpotの意味

Penpotは、ウェブサービス、業務システム、スマートフォンアプリ、管理画面などの画面を設計するためのツールです。画面上に文字、図形、画像、ボタン、入力欄、一覧、カードなどを配置し、完成後の見た目や使い方を開発前に確認できます。単なる画像作成ではなく、利用者がどの順番で情報を読み、どの操作を行い、どの画面へ進むのかまで考えるための環境です。

Penpotの特徴は、設計したものを開発者が読み取りやすい形で確認できる点にあります。開発者は、画面を見ただけでは正確な余白や寸法を判断できませんが、Penpotでは検査機能を使って、要素の値や構造を確認できます。このため、設計者の意図を実装側へ伝えるときに、説明文や画像だけに頼らず、より具体的な情報を共有しやすくなります。

1.2 Penpotで扱う作業

Penpotでは、最初のラフな画面案から、完成に近い画面設計、操作の流れを確認する試作品、再利用できる部品、開発者向けの検査情報まで扱えます。たとえば、新しい会員登録画面を作る場合、入力欄、説明文、送信ボタン、エラー表示、確認画面への遷移をひとつの設計ファイルの中で整理できます。

また、Penpotはチーム作業にも向いています。デザイナーだけでなく、開発者、企画担当者、品質管理担当者、顧客担当者が同じ設計を確認できるため、画面に対する認識をそろえやすくなります。特に、画面を何度も修正しながら開発する現場では、Penpotのように共有しやすい設計環境があると、意思決定の速度が上がります。

1.3 Penpotが必要とされる背景

現代の製品開発では、画面の見た目だけでなく、使いやすさ、開発しやすさ、保守しやすさが同時に求められます。どれほど美しい画面でも、開発者が実装しにくかったり、後から変更しにくかったりすると、製品全体の品質は上がりません。Penpotは、設計と開発の間にある情報の断絶を減らすために役立ちます。

また、デザインツールの利用料金、データ管理、外部サービス依存を見直す企業が増えていることも、Penpotが注目される背景です。オープンソースであり、自社運用も選べるPenpotは、設計資産を長期的に管理したい組織にとって有力な選択肢になります。単に無料で使えるからではなく、組織が設計環境を自分たちの方針に合わせて持てることが重要です。

1.4 Penpotの利用者

Penpotの主な利用者は、画面設計を行うデザイナー、設計内容を実装する開発者、製品の流れを確認する企画担当者です。デザイナーは画面を作り、開発者は検査情報やコード断片を確認し、企画担当者は試作品を見ながら要件の不足を確認できます。このように、ひとつの設計ファイルが複数の役割をつなぐ中心になります。

特に、少人数で素早く製品を作るチームでは、Penpotの価値が出やすいです。大きな資料を何枚も作って説明するより、実際の画面と遷移を見せながら話したほうが早く伝わります。開発者が早い段階で設計に参加できるため、実装段階で「これは作りにくい」「状態が足りない」といった問題を早めに発見できます。

1.5 Penpotの位置づけ

Penpotは、画像編集ソフトでも、単なる図表作成ツールでもありません。ウェブやアプリの製品開発に必要な画面、部品、操作、設計値を管理するための設計プラットフォームです。完成画像を作ることだけを目的にするのではなく、その後の開発、修正、運用まで考えた設計を行うために使われます。

この位置づけを理解すると、Penpotの強みがわかりやすくなります。画面を作るだけなら多くのツールがありますが、オープンソース、自社運用、標準技術との親和性、開発者連携を同時に重視できるツールは限られています。Penpotは、設計をチームの資産として扱いたい場合に特に力を発揮します。

2. Penpotが選ばれる理由

Penpotが選ばれる理由は、単に無料で使えるからではありません。オープンソースであること、自社運用できること、設計と実装を近づけられること、チームで共同作業しやすいことが組み合わさり、長期的な開発環境として評価されています。

2.1 オープンソースである安心感

Penpotはオープンソースの設計ツールであり、仕組みや開発の方向性を確認しやすいという利点があります。閉じた商用ツールでは、料金、仕様、利用条件、保存形式が変わったときに利用者側が大きく影響を受けますが、オープンソースであれば、透明性を持ってツールを評価しやすくなります。

この安心感は、長期的に設計資産を管理する企業にとって重要です。短期的な作業だけなら、どのツールでも大きな差を感じないかもしれません。しかし、何年も使い続ける設計資産、複数部署が参照する部品、開発と連動する設計値を管理する場合、ツールの透明性と継続性は大きな判断材料になります。

2.2 自社運用を選べる自由度

Penpotはクラウド利用だけでなく、自社運用も選べます。自社運用を選ぶと、設計ファイルの保存場所、アクセス権限、バックアップ、監査、社内規定への対応を自分たちで設計できます。公式サイトでも、自社運用の導入方法や企業向け利用が案内されています。

もちろん、自社運用には保守負担もあります。サーバーの更新、障害対応、容量管理、バックアップなどを考える必要があります。それでも、設計データを外部サービスだけに置きたくない企業や、情報管理を厳密にしたい組織にとって、自社運用できることは大きな価値になります。

2.3 開発者と会話しやすい設計

Penpotは、設計と開発の連携を重視しています。公式ヘルプでは、検査機能を使って距離、プロパティ、コード断片、書き出し情報などを確認できると説明されています。さらに、選択したレイヤーからCSS、SVG、HTMLのコード断片を取得できることも案内されています。

この機能により、デザイナーは「この見た目にしてください」と感覚的に伝えるだけでなく、開発者が具体的な値を確認できる形で設計を渡せます。開発者側も、余白や色を目視で推測する必要が減り、設計ファイルを確認しながら実装を進めやすくなります。

2.4 チームの認識をそろえやすい

製品開発では、関係者が同じ画面を見ているつもりでも、実際には違う完成イメージを持っていることがあります。企画担当者は機能の流れを重視し、デザイナーは見た目と体験を重視し、開発者は構造と実装しやすさを重視します。Penpotは、こうした視点の違いを同じ設計ファイル上で確認しやすくします。

認識合わせが早くなると、開発後の大きな手戻りを減らせます。画面の配置、遷移、状態、エラー表示を開発前に確認できれば、「実装してから初めて問題に気づく」という状況を避けやすくなります。チーム全体で同じ情報を見ながら意思決定することが、Penpotの実務的な強みです。

2.5 設計資産を育てやすい

Penpotでは、画面を一度作って終わりにするのではなく、部品や設計値を再利用しながら設計資産を育てられます。ボタン、入力欄、カード、ナビゲーション、文字スタイル、色、余白などを整理しておくと、新しい画面を作るときに同じルールを使えます。

この考え方は、サービスが成長するほど重要になります。最初は数画面しかない製品でも、機能追加を続けると画面数は増え、部品も増えます。設計資産を整理しないまま進めると、似ているが少し違う部品が増えて、保守が難しくなります。Penpotを使えば、設計の一貫性を保ちながら拡張しやすくなります。

3. Penpotで作れるもの

Penpotでは、ウェブサイト、アプリ画面、管理画面、試作品、設計部品、設計トークンなどを作れます。ここでは、実際にPenpotを使うとどのような成果物を作れるのかを、現場での利用場面に近い形で説明します。

3.1 ウェブサイトの画面

Penpotでは、企業サイト、製品紹介ページ、採用ページ、記事ページ、問い合わせページなどのウェブサイト画面を設計できます。見出し、本文、画像、ボタン、フォーム、カード、一覧などを配置し、利用者が情報を自然に読める流れを作ります。単に見た目を飾るだけでなく、情報の優先順位を整理することが大切です。

ウェブサイトの設計では、画面幅ごとの見え方も重要です。パソコンでは横並びに見せる情報でも、スマートフォンでは縦に並べる必要があります。Penpotであらかじめ複数の画面幅を想定して設計しておけば、開発時に大きな修正が発生しにくくなります。

3.2 アプリケーション画面

スマートフォンアプリやウェブアプリケーションの画面設計にもPenpotは使えます。ログイン、会員登録、一覧、詳細、設定、通知、検索、決済など、利用者が操作する画面を順番に作成できます。アプリケーションでは、画面の美しさだけでなく、迷わず操作できる流れが重要です。

特にアプリケーション画面では、状態の設計が欠かせません。読み込み中、入力エラー、空の一覧、通信失敗、保存完了、権限不足など、通常状態以外の画面を考えておかないと、実装時に判断がばらつきます。Penpotで状態ごとの画面を作っておくと、開発者も仕様を理解しやすくなります。

3.3 管理画面

Penpotは、社内向けの管理画面や業務システムの設計にも向いています。管理画面では、一覧、検索条件、絞り込み、表、詳細表示、編集画面、確認画面など、多くの情報を整理して見せる必要があります。見た目の華やかさよりも、情報の探しやすさと操作のわかりやすさが重要です。

業務システムでは、利用者が毎日長時間使うこともあります。そのため、余白、文字サイズ、ボタンの位置、操作導線が作業効率に直結します。Penpotで画面を作り、実際の業務フローに沿って確認すれば、開発前に使いにくさを発見しやすくなります。

3.4 試作品

Penpotでは、複数の画面をつなげて試作品を作れます。試作品を作ると、ボタンを押した後にどの画面へ進むのか、入力後に確認画面が必要なのか、戻る操作が自然かどうかを確認できます。公式の試作品ページでも、画面遷移や流れ、動作を早い段階で検証する用途が説明されています。

試作品は、開発前の合意形成に役立ちます。静止画だけでは、操作の流れを想像しにくい人もいますが、試作品なら実際に近い形で確認できます。関係者が早い段階で操作感を確認できれば、開発後の大きな方向転換を避けやすくなります。

3.5 設計部品

Penpotでは、ボタン、入力欄、カード、メニュー、タブ、見出し、通知、モーダルなどを部品として管理できます。部品を再利用すれば、画面ごとに同じ要素を作り直す必要がなくなり、見た目と操作感の一貫性を保ちやすくなります。

部品管理は、製品が成長するほど重要になります。小さなサービスでは手作業で調整できても、画面数が増えると管理しきれなくなります。Penpotで部品を整理しておけば、新しい機能を追加するときも、既存の部品を使いながら効率よく画面を作れます。

4. Penpotの画面設計

Penpotの画面設計では、情報の配置、視線の流れ、余白、色、文字、部品の使い方を整理します。ここでは、実際に画面を作るときに意識すべき考え方を説明します。

4.1 情報の優先順位

画面設計で最初に考えるべきことは、何を一番伝えたいのかです。見出し、説明文、画像、ボタン、補足情報がすべて同じ強さで並んでいると、利用者はどこを見ればよいかわからなくなります。Penpotでは、要素の大きさ、位置、色、余白を調整しながら、情報の優先順位を視覚的に整理できます。

情報の優先順位が明確な画面は、利用者にとって理解しやすくなります。たとえば、登録画面なら「何を入力するのか」「なぜ必要なのか」「次に何を押すのか」がすぐにわかる必要があります。Penpotで設計する段階から、利用者の視線と判断の順番を意識することが重要です。

4.2 余白の設計

余白は、画面の見やすさを左右する重要な要素です。要素同士が近すぎると情報が詰まって見え、離れすぎると関係性がわかりにくくなります。Penpotで余白を確認しながら設計すると、画面全体のリズムを整えやすくなります。

余白は感覚だけで決めると、画面ごとにばらつきが出ます。たとえば、部品内の余白は8px、部品同士の余白は16px、画面区切りの余白は32pxのように段階を決めておくと、デザイナーが変わっても同じ規則で作業できます。開発側でも同じ余白値を使えば、設計と実装の差を減らせます。

4.3 文字の設計

文字は、情報を伝えるための中心です。見出し、本文、補足、注記、エラー文、ボタン文字など、それぞれの役割に応じて大きさ、太さ、行間を決める必要があります。Penpotでは、文字の見え方を画面上で確認しながら調整できます。

文字設計で重要なのは、種類を増やしすぎないことです。画面ごとに微妙に違う文字サイズを使うと、統一感が失われ、開発側の管理も難しくなります。見出し、本文、小さい補足、ボタン文字など、必要な種類に絞って設計すると、製品全体の読みやすさを保ちやすくなります。

4.4 色の設計

色は、ブランドの印象だけでなく、操作の意味や状態を伝える役割を持ちます。主要な操作には目立つ色、補助的な操作には控えめな色、警告には注意を促す色、成功には安心感のある色を使うと、利用者が画面の意味を理解しやすくなります。

Penpotで色を整理するときは、見た目の好みだけでなく、用途ごとに意味を決めることが大切です。たとえば「青色」ではなく「主要操作色」、「赤色」ではなく「エラー色」のように考えると、後から色を変える場合でも役割を保ちやすくなります。

4.5 状態の設計

実際の画面には、通常状態だけでなく、読み込み中、入力エラー、無効状態、選択中、空状態、完了状態などがあります。Penpotでこれらの状態を事前に設計しておくと、開発時に判断がぶれにくくなります。

状態の設計を後回しにすると、実装時に開発者がその場で見た目を決めることになります。結果として、画面ごとにエラー表示や無効状態の見た目が違ってしまうことがあります。Penpotで状態を整理しておけば、利用者にとっても開発者にとってもわかりやすい画面になります。

5. Penpotの試作品作成

Penpotの試作品作成は、静止した画面を実際の操作に近い形で確認するために使います。開発前に流れを試せるため、要件の不足や使いにくさを早い段階で見つけやすくなります。

5.1 画面遷移の確認

試作品では、ボタンやリンクを押したときにどの画面へ進むのかを確認できます。たとえば、会員登録画面から確認画面へ進み、確認画面から完了画面へ進む流れを作ることで、利用者の操作を具体的に見せられます。

画面遷移を確認すると、静止画だけでは見えなかった問題に気づけます。ボタンの位置がわかりにくい、戻る操作が不自然、確認画面が多すぎる、説明が足りないといった課題は、実際に流れを触ってみることで発見しやすくなります。

5.2 操作感の確認

試作品は、画面の操作感を確認するためにも重要です。ボタンが押しやすい位置にあるか、次に行う操作が自然に見えるか、入力から送信まで迷わず進めるかを確認できます。設計者が頭の中で想像するだけではなく、実際に近い動きとして試せる点が大きな価値です。

操作感の確認は、開発前に行うほど効果があります。実装後に「やはりこの流れは使いにくい」と気づくと、コードの修正や仕様変更が必要になります。Penpotで試作品を作り、早い段階で検証すれば、手戻りを小さくできます。

5.3 関係者への説明

試作品は、デザインや開発に詳しくない関係者への説明にも向いています。文章や静止画だけでは、完成後の画面を想像しにくい場合がありますが、試作品なら実際の操作に近い形で理解できます。

特に、社内承認や顧客確認が必要な案件では、試作品があると説明がスムーズになります。関係者が同じ流れを見ながら意見を出せるため、「どの画面のどの操作について話しているのか」が明確になります。

5.4 利用者テスト

Penpotで作った試作品は、利用者テストにも使えます。実際の利用者に近い人に触ってもらい、どこで迷うのか、どの説明が足りないのか、どの操作がわかりにくいのかを確認できます。

利用者テストでは、作り手の思い込みを見つけることが重要です。作り手にとっては自然な言葉や配置でも、初めて見る人には伝わらない場合があります。Penpotの試作品を使えば、開発前にそうした問題を発見し、改善できます。

5.5 開発前の合意形成

試作品は、開発前の合意形成を強く助けます。画面の見た目、操作の順番、入力内容、完了までの流れを関係者が確認できるため、開発開始後の認識違いを減らせます。

合意形成が不十分なまま開発に入ると、完成後に大きな修正が必要になることがあります。Penpotで試作品を作り、事前に確認しておけば、開発者も安心して実装に進めます。

6. Penpotと開発者連携

Penpotの強みのひとつは、開発者との連携を考えやすいことです。ここでは、設計した画面をどのように開発へつなげるのか、検査機能やコード確認をどのように活用するのかを説明します。

6.1 検査機能

Penpotの検査機能では、要素の寸法、位置、距離、スタイル、コード断片などを確認できます。公式ヘルプでは、検査機能によって測定値、プロパティ、CSS、SVG、HTMLなどを確認できると説明されています。

この機能により、開発者は設計ファイルを見ながら、どの値を使えばよいかを判断しやすくなります。画像だけを渡される場合と違い、余白や文字設定を具体的に確認できるため、実装時の推測を減らせます。

6.2 寸法と距離の確認

画面実装では、要素の幅、高さ、上下左右の距離が重要です。これらが設計と少しずれるだけでも、完成画面の印象は大きく変わります。Penpotで寸法と距離を確認できれば、開発者は正確な値を参照できます。

特に、カード一覧、フォーム、管理画面、ダッシュボードのように要素が多い画面では、余白の一貫性が品質に直結します。Penpotの検査機能を使うことで、画面全体の整い方を実装にも反映しやすくなります。

6.3 色と文字設定の確認

開発者は、Penpot上で色や文字設定を確認し、実装に反映できます。色コード、文字サイズ、太さ、行間などを設計ファイルから確認できれば、デザインと実装の差を小さくできます。

色や文字設定は、画面品質を左右する細かな要素です。少し違う色や文字サイズが増えると、製品全体の統一感が崩れます。Penpotで設計値を明確にし、開発側でも同じ値を使うことが重要です。

6.4 コード断片の扱い

Penpotでは、選択した要素からCSS、SVG、HTMLなどのコード断片を確認できます。ただし、これらは常にそのまま本番コードとして使うものではなく、設計値や構造を理解するための参考として扱うのが安全です。

実際の開発では、使用している枠組み、部品設計、命名規則、アクセシビリティ、保守性を考えてコードを書く必要があります。Penpotのコード断片は、実装の出発点として使い、最終的には開発プロジェクトの方針に合わせて整えるべきです。

6.5 受け渡しの削減

Penpotを使うと、デザイナーが開発者向けに大量の説明資料を作る負担を減らせます。設計ファイルの中に画面、状態、寸法、色、文字、コード情報がまとまっていれば、開発者は必要な情報を自分で確認できます。

受け渡し作業が少なくなると、デザイナーは画面改善に集中しやすくなり、開発者は実装に集中しやすくなります。チーム全体として、説明のための作業ではなく、製品を良くするための作業に時間を使えるようになります。

7. Penpotの設計トークン

設計トークンとは、色、文字、余白、角丸、影などの設計値に名前を付け、再利用しやすくする仕組みです。Penpotは設計トークンを重視しており、公式ヘルプでは、設計トークンが単一の情報源として機能し、W3C DTCG形式に沿って扱えることが説明されています。

7.1 設計トークンの役割

設計トークンは、デザイナーと開発者が同じ設計値を共有するための共通言語です。たとえば、主要な青色を毎回「#2563eb」と書くのではなく、「主要操作色」のような意味を持つ名前で管理すれば、どの場面で使う色なのかがわかりやすくなります。

この仕組みを使うと、設計変更に強くなります。ブランド色を変える場合でも、値そのものを差し替えれば、同じ役割を持つ箇所へ一貫して反映できます。設計トークンは、単なる便利機能ではなく、製品全体の保守性を高めるための仕組みです。

7.2 色トークン

色トークンでは、主要操作色、補助操作色、本文色、背景色、境界線色、警告色、成功色などを整理します。色を見た目の名前だけで管理すると、将来変更するときに意味がわかりにくくなるため、用途で名前を付けることが重要です。

たとえば、「青」ではなく「主要操作色」として管理すれば、その色が何のために使われるのかが明確になります。将来、主要操作色が青から緑に変わったとしても、役割は変わらないため、設計と実装の両方で変更を管理しやすくなります。

7.3 文字トークン

文字トークンでは、見出し、本文、補足、注記、ボタン文字、エラー文などの文字設定を整理します。文字サイズ、太さ、行間、字間を用途ごとに決めておくと、画面全体の読みやすさを保ちやすくなります。

文字設定を画面ごとに自由に決めると、製品全体で見出しの大きさや本文の読みやすさがばらつきます。Penpotで文字トークンを整理しておけば、デザイナーが複数人いても同じ規則で画面を作れます。

7.4 余白トークン

余白トークンは、画面の整い方を管理するために使います。小さい余白、中くらいの余白、大きい余白を段階的に決め、部品内、部品同士、画面全体で使い分けると、視覚的な一貫性が生まれます。

余白は見た目の印象だけでなく、情報の関係性を伝える役割もあります。近い要素は関連して見え、離れた要素は別のまとまりとして見えます。余白トークンを使えば、この関係性を設計と実装の両方で保ちやすくなります。

7.5 開発への反映

設計トークンは、開発側ではCSS変数や設定ファイルとして扱うことができます。Penpotで管理している名前と、開発側の名前を近づけることで、会話や修正がスムーズになります。公式の設計トークン関連ページでも、Penpotが標準形式での読み書きや開発との共有を重視していることが説明されています。

設計トークンを開発へ反映すると、画面ごとに個別の値を持つ必要が減ります。色や余白を一元管理できるため、製品全体の変更に強くなり、デザインシステムの保守もしやすくなります。

コード例：CSS変数で設計トークンを表現する

:root {  --color-action-primary: #2563eb;  --color-action-primary-text: #ffffff;  --color-text-body: #111827;  --color-surface-default: #ffffff;  --color-border-default: #d1d5db;  --space-small: 8px;  --space-medium: 16px;  --space-large: 24px;  --radius-medium: 12px;  --font-size-body: 16px; } .primary-button {  background-color: var(--color-action-primary);  color: var(--color-action-primary-text);  padding: var(--space-small) var(--space-medium);  border-radius: var(--radius-medium);  font-size: var(--font-size-body);  border: none; }

8. Penpotの自社運用

Penpotは、自社環境に置いて運用できる点が大きな特徴です。自社運用はすべてのチームに必要なものではありませんが、情報管理、社内規定、長期運用を重視する企業にとって重要な選択肢になります。

8.1 自社運用の意味

自社運用とは、Penpotを外部のクラウドサービスとして使うだけでなく、自分たちの管理する環境に設置して使うことです。これにより、設計データの保存場所、アクセス管理、更新方針、バックアップ方針を組織側で決められます。

特に、機密性の高い製品、社外秘の画面、顧客情報に関係する業務システムを扱う場合、自社運用の価値は高くなります。外部サービスに依存しないことで、社内の情報管理方針に合わせやすくなります。

8.2 自社運用の利点

自社運用の利点は、設計環境を自分たちで管理できることです。ユーザー権限、保存場所、ネットワーク制限、バックアップ方法を組織のルールに合わせられるため、情報管理を重視する企業に向いています。

また、長期的な視点でも自社運用は意味があります。外部サービスの料金変更や仕様変更の影響を抑えられるため、設計資産を長く安定して管理したい場合に検討しやすい選択肢になります。

8.3 自社運用の負担

自社運用には、当然ながら保守負担があります。サーバーの構築、更新、監視、障害対応、バックアップ、復旧手順の整備などを行う必要があります。ツールを置けば終わりではなく、継続的に管理する体制が必要です。

この負担を軽く見積もると、導入後に問題が起きやすくなります。Penpotを自社運用する場合は、開発部門、情報システム部門、デザイン部門が連携し、誰が何を管理するのかを事前に決めておくべきです。

8.4 クラウド利用との選び分け

Penpotを初めて試す場合は、クラウド利用から始めるほうが簡単です。環境構築をせずに操作感やチームとの相性を確認できるため、導入判断を早く行えます。

一方で、本格的に設計資産を管理したい場合や、社内規定に合わせた運用が必要な場合は、自社運用を検討する価値があります。最初はクラウドで試し、効果を確認してから自社運用へ移行する段階的な進め方も現実的です。

8.5 運用前に決めること

自社運用を始める前には、利用者数、保存容量、権限設計、バックアップ頻度、障害時の対応、更新手順を決めておく必要があります。これらを決めないまま導入すると、利用者が増えた後に管理が難しくなります。

また、設計ファイルは重要な業務資産です。誤って削除された場合や、サーバーに問題が起きた場合に復旧できるよう、バックアップと復旧の確認を事前に行うことが重要です。

9. PenpotとFigmaの違い

PenpotとFigmaは、どちらも画面設計や試作品作成に使えるツールですが、思想や運用の自由度に違いがあります。ここでは、単純な優劣ではなく、どのようなチームにどちらが向いているのかを整理します。

9.1 運用思想の違い

Penpotは、オープンソース、自社運用、標準技術との親和性を重視する設計ツールです。設計環境を自分たちで管理したいチームや、デザインと開発の関係を近づけたいチームに向いています。

Figmaは、広く普及しているクラウド型の設計ツールで、利用者の多さ、周辺機能、共同作業のしやすさに強みがあります。すでにFigmaを使っているチームが多いため、人材採用や外部パートナーとの連携では有利な場面もあります。

9.2 データ管理の違い

Penpotは自社運用を選べるため、設計データの管理方針を組織側で決めやすいです。機密性の高い画面や社内システムの設計を扱う場合、保存場所やアクセス制限を自分たちで制御できることは大きな利点です。

Figmaはクラウド利用が中心であり、導入しやすく管理負担が少ない一方、データの置き場所やサービス仕様については提供側の仕組みに依存します。どちらが適しているかは、チームの情報管理方針によって変わります。

9.3 開発者連携の違い

Penpotは、CSS、SVG、HTMLなどの標準技術と近い形で設計情報を扱える点が特徴です。公式ヘルプでも、検査機能からコード断片やプロパティを確認できることが説明されています。

Figmaにも開発者向けの受け渡し機能がありますが、Penpotはオープンソースと標準技術への親和性を前面に出している点が違います。開発者が設計ファイルを読み取り、実装へつなげることを重視するチームでは、Penpotの思想が合いやすいです。

9.4 学習と移行の違い

Figmaに慣れているデザイナーにとって、Penpotの基本的な画面設計の流れは理解しやすい部分があります。画面を作り、部品を使い、試作品を作るという考え方は似ているため、完全に新しい分野を学ぶわけではありません。

ただし、細かな操作、命名、部品管理、共有方法、設計トークンの扱いは異なります。移行する場合は、既存ファイルをどう扱うか、チームの教育をどう進めるか、設計ルールをどう整理するかを計画する必要があります。

9.5 違いの一覧

PenpotとFigmaの違いは、「どちらが絶対に優れているか」ではなく、チームが何を重視するかで判断すべきです。自社運用、透明性、標準技術を重視するならPenpotが合いやすく、普及度、外部連携、既存利用者の多さを重視するならFigmaが合いやすい場面があります。

以下の一覧は、導入検討時に見るべき主な違いを整理したものです。表だけで判断するのではなく、自社の情報管理、開発体制、設計資産の扱い方に合わせて検討することが重要です。

10. Penpotが向いているチーム

Penpotは、すべてのチームに同じように向いているわけではありません。ここでは、Penpotの特徴を活かしやすいチームや組織の条件を説明します。

10.1 開発者と近いチーム

Penpotは、デザイナーと開発者が日常的に会話しながら進めるチームに向いています。設計ファイルの中で寸法、余白、色、文字、コード断片を確認できるため、実装前の認識合わせがしやすくなります。

デザイナーが完成画面だけを渡し、開発者が後から推測して実装する流れでは、細かなズレが起きやすくなります。Penpotを使えば、設計中から開発者が参加しやすくなり、実装しにくい点や不足している状態を早く見つけられます。

10.2 自社運用を重視する組織

情報管理を重視する組織には、Penpotが合いやすいです。設計データを自社環境で管理できるため、社内規定や顧客契約に合わせた運用を設計しやすくなります。

ただし、自社運用には技術的な管理が必要です。情報システム部門や開発部門が運用に関われる体制がある場合、Penpotの自由度を活かしやすくなります。

10.3 設計資産を育てたいチーム

Penpotは、デザインシステムや設計トークンを育てたいチームに向いています。部品、色、文字、余白を整理し、複数の画面で再利用できるようにすると、製品全体の一貫性を保ちやすくなります。

設計資産は、短期的には作る手間がかかります。しかし、画面数が増えるほど効果が出ます。新しい画面を作るたびに一から考える必要がなくなり、品質と速度の両方を高められます。

10.4 受託開発チーム

受託開発では、顧客、デザイナー、開発者の認識合わせが重要です。Penpotで画面と試作品を共有すれば、完成イメージを早い段階で確認できます。

また、開発者が設計値を確認しやすいため、受け渡しの説明負担も減ります。顧客確認、社内レビュー、開発実装を同じ設計ファイルを中心に進められるため、案件管理がしやすくなります。

10.5 教育や学習の現場

Penpotは、画面設計と実装の関係を学ぶ教材としても使いやすいです。学生や初学者は、画面を作るだけでなく、余白、色、文字、部品、コードへの接続を同時に学べます。

特に、将来ウェブ制作やアプリ開発に関わる人にとって、設計と実装を分けて考えすぎないことは重要です。Penpotを使えば、見た目の設計がどのようにコードへつながるのかを実践的に理解できます。

11. Penpotの始め方

Penpotを始めるときは、いきなり大きな案件で使うより、小さな画面から試すほうが安全です。ここでは、初めてPenpotを使う人がどの順番で学べばよいかを説明します。

11.1 小さな画面を選ぶ

最初に作る画面は、ログイン画面、問い合わせ画面、簡単な紹介ページのような小さなものが向いています。要素が少ない画面なら、操作方法、配置、文字設定、共有、検査機能を短い時間で体験できます。

最初から複雑な管理画面や多機能アプリを作ろうとすると、ツールの学習と設計判断が同時に発生し、混乱しやすくなります。まず小さく作り、Penpotの流れを理解してから、実際の業務へ広げるほうが失敗しにくいです。

11.2 画面幅を決める

画面を作る前に、どの端末向けに設計するのかを決めます。パソコン向け、スマートフォン向け、タブレット向けでは、余白、文字サイズ、情報量、ボタンの位置が変わります。

画面幅を決めずに作り始めると、後から配置を大きく直すことになります。最初に主要な利用環境を決め、その幅に合わせて画面を作ることで、設計の方向性が安定します。

11.3 色と文字を決める

画面を作る前に、主要色、背景色、本文色、境界線色、見出し文字、本文文字を決めておくと、作業中に迷いにくくなります。最初から多くの色や文字種類を作る必要はありません。

色や文字が多すぎると、画面の統一感が崩れやすくなります。最初は少ない種類で始め、必要に応じて追加するほうが管理しやすいです。Penpotでは、こうした設計値を整理しながら画面を作れます。

11.4 部品を作る

ボタン、入力欄、カード、見出しなど、何度も使う要素は部品化すると効率的です。部品を作っておけば、新しい画面を作るときに同じ見た目を再利用できます。

部品を作るときは、通常状態だけでなく、無効状態、選択状態、エラー状態も考えると実務に近くなります。実際の製品では状態の違いが多いため、最初から意識しておくと開発時に役立ちます。

11.5 共有して確認する

画面を作ったら、関係者に共有して意見を集めます。デザイナーだけで確認するのではなく、開発者、企画担当者、利用者に近い人にも見てもらうことで、見落としを減らせます。

共有するときは、「全体的にどう思うか」ではなく、「入力の流れは自然か」「ボタンは見つけやすいか」「説明文は足りているか」のように具体的に聞くと、改善につながる意見を得やすくなります。

12. Penpotから実装へつなげるコード例

Penpotで作った設計は、開発側でコードに反映して初めて実際の製品になります。ここでは、Penpotで決めた設計値をどのようにCSSやHTMLへ落とし込むかを説明します。

12.1 ボタン設計

Penpotで主要ボタンを設計したら、開発側では同じ色、余白、角丸、文字サイズを使って部品化します。ボタンは多くの画面で使われるため、最初に共通部品として作る価値が高いです。

主要ボタン、補助ボタン、危険操作ボタンのように役割を分けておくと、画面ごとの判断が楽になります。見た目の違いだけではなく、どの場面で使うのかを決めておくことが重要です。

コード例：主要ボタン

<button class="button button-primary">  無料で始める </button>

.button {  display: inline-flex;  align-items: center;  justify-content: center;  min-height: 44px;  padding: 0 20px;  border-radius: 12px;  font-size: 16px;  font-weight: 700;  cursor: pointer; } .button-primary {  background-color: #2563eb;  color: #ffffff;  border: 1px solid #2563eb; } .button-primary:hover {  background-color: #1d4ed8; }

12.2 カード設計

カードは、記事一覧、商品一覧、お知らせ一覧、機能紹介などでよく使われる部品です。Penpotでカードを設計するときは、見出し、本文、画像、リンク、補足情報の順番を整理する必要があります。

開発側では、カードを再利用可能な部品として実装すると便利です。画面ごとにカードを作り直すのではなく、同じ構造を使いながら内容だけを変えることで、保守しやすくなります。

コード例：カード部品

<article class="card">  <h3 class="card-title">Penpotで画面設計を始める</h3>  <p class="card-text">    オープンソースの設計ツールを使い、デザインと実装の距離を縮めます。  </p>  <a class="card-link" href="/guide/penpot">詳しく見る</a> </article>

.card {  padding: 24px;  border: 1px solid #d1d5db;  border-radius: 16px;  background-color: #ffffff; } .card-title {  margin: 0 0 12px;  font-size: 20px;  line-height: 1.4; } .card-text {  margin: 0 0 16px;  font-size: 16px;  line-height: 1.8; } .card-link {  font-weight: 700;  text-decoration: none; }

12.3 入力フォーム設計

入力フォームは、利用者が直接操作するため、設計と実装の差が出やすい部分です。Penpotでは、ラベル、入力欄、補足文、エラー文、送信ボタンをまとめて設計しておくと、開発者が実装しやすくなります。

特に重要なのは、エラー状態を最初から作ることです。通常状態だけを設計していると、実装時にエラー表示の位置や色をその場で決めることになり、画面ごとにばらつきが出ます。

コード例：入力欄とエラー表示

<label class="field">  <span class="field-label">メールアドレス</span>  <input class="field-input is-error" type="email" aria-describedby="email-error">  <span class="field-error" id="email-error">    正しいメールアドレスを入力してください。  </span> </label>

.field {  display: grid;  gap: 8px; } .field-label {  font-size: 14px;  font-weight: 700; } .field-input {  min-height: 44px;  padding: 0 12px;  border: 1px solid #9ca3af;  border-radius: 10px;  font-size: 16px; } .field-input.is-error {  border-color: #dc2626; } .field-error {  color: #dc2626;  font-size: 14px; }

12.4 余白設計

Penpotで余白を整理したら、開発側でも同じ余白規則を使うことが重要です。部品内の余白、部品同士の余白、セクション間の余白を共通化すると、画面全体が整いやすくなります。

余白を個別に書くと、後から変更するときに大変になります。CSS変数として管理すれば、画面全体の余白を一貫して調整でき、設計変更にも対応しやすくなります。

コード例：余白の共通化

:root {  --space-1: 4px;  --space-2: 8px;  --space-3: 16px;  --space-4: 24px;  --space-5: 32px; } .section {  padding: var(--space-5) var(--space-4); } .stack {  display: grid;  gap: var(--space-3); }

12.5 設計値の共通化

Penpotで決めた設計値は、開発側でも共通化して使うべきです。色、文字、余白、角丸を画面ごとに直接書くと、後から変更するときに多くの修正が必要になります。

設計値を共通化すれば、デザイナーと開発者が同じ名前で会話できます。「主要操作色を変える」「本文文字を調整する」「余白を一段階広げる」といった変更が、感覚ではなく明確な作業として扱えるようになります。

コード例：設計値をまとめる

:root {  --color-primary: #2563eb;  --color-danger: #dc2626;  --color-text: #111827;  --color-border: #d1d5db;  --radius-small: 8px;  --radius-medium: 12px;  --radius-large: 16px;  --font-small: 14px;  --font-body: 16px;  --font-heading: 24px; }

13. Penpotの運用ルール

Penpotをチームで使う場合、操作方法だけでなく運用ルールが重要です。ファイル名、部品名、権限、レビュー、古い設計の扱いを決めることで、設計資産を長く使いやすくできます。

13.1 ファイル名

ファイル名は、後から見つけやすい形にする必要があります。製品名、機能名、画面種別、日付、状態を含めると、どのファイルが何のためのものか判断しやすくなります。

たとえば「新しい画面」という名前では、時間が経つと内容がわからなくなります。「会員登録_スマートフォン_2026改善案」のように意味が伝わる名前にすれば、チーム内で探しやすくなります。

13.2 部品名

部品名は、見た目ではなく用途で付けることが重要です。「青いボタン」ではなく「主要ボタン」、「赤い文字」ではなく「エラー文」のように名付けると、役割が明確になります。

用途で名前を付けると、将来見た目が変わっても名前を変えずに済みます。主要ボタンの色が青から緑に変わっても、主要操作を表す役割は変わらないため、設計システムを保守しやすくなります。

13.3 レビュー方法

Penpotで作った画面は、見た目だけでなく、操作性、実装可能性、状態の不足、文言のわかりやすさをレビューする必要があります。レビュー観点を決めておくと、毎回の確認品質が安定します。

開発者は、設計の最後だけでなく途中から参加するほうが効果的です。実装しにくい配置、足りない状態、部品化したほうがよい要素を早めに指摘できるため、開発時の手戻りを減らせます。

13.4 権限管理

チームでPenpotを使う場合、誰が編集できるのか、誰が閲覧だけなのかを決める必要があります。全員が自由に編集できる状態は便利ですが、重要な部品や設計ルールが壊れる危険もあります。

特に、設計システムの中核になる部品やトークンは、管理者を決めて変更するほうが安全です。自由に作業できる領域と、厳密に管理する領域を分けることで、柔軟性と品質の両方を保てます。

13.5 古い設計

製品開発では、古い設計ファイルが残り続けることがあります。古い案と最新案が混ざると、開発者や関係者が誤った画面を参照してしまう危険があります。

古い設計には、明確に「旧案」「参考」「使用停止」などの印を付けるべきです。最新ファイルへの案内も入れておけば、後から見た人が迷わず正しい設計を確認できます。

14. Penpot導入時の注意点

Penpotは便利なツールですが、導入すれば自動的にチームが改善するわけではありません。ここでは、導入前に注意すべき点を説明します。

14.1 既存ツールからの移行

すでに別の設計ツールを使っている場合、Penpotへの移行には計画が必要です。既存ファイル、部品、画像、共有リンク、レビュー手順をどう扱うかを決めなければ、移行後に混乱します。

すべての設計資産を一度に移す必要はありません。まず新規案件や小さな画面からPenpotを使い、チームが慣れてから移行範囲を広げるほうが現実的です。

14.2 操作学習

Penpotは直感的に使える部分もありますが、部品管理、試作品作成、検査機能、設計トークンなどは学習が必要です。導入時に教育を省くと、メンバーごとに使い方がばらつきます。

短い勉強会、共通テンプレート、命名規則の説明を用意すると、導入が安定します。特にチーム利用では、個人の操作力よりも、全員が同じルールで使えることが重要です。

14.3 自社運用の管理

自社運用を選ぶ場合は、技術的な管理が必要です。サーバー更新、バックアップ、障害対応、利用者管理を誰が担当するのかを決めておかなければなりません。

自社運用は自由度が高い一方で、責任も大きくなります。導入前に、運用担当、復旧手順、更新頻度、バックアップ方法を決めておくことで、安定して使いやすくなります。

14.4 コード断片への過信

Penpotで確認できるコード断片は便利ですが、そのまま本番実装へ貼り付ければ完成するとは限りません。公式ヘルプでも、コード断片を確認できることは案内されていますが、実際の開発ではプロジェクトの設計方針に合わせる必要があります。

本番コードでは、保守性、アクセシビリティ、部品設計、状態管理、命名規則を考える必要があります。Penpotのコード情報は参考として使い、最終的な実装は開発者が整えるべきです。

14.5 ルール不足

Penpotを導入しても、命名規則や部品管理のルールがなければ、設計ファイルは散らかります。似たようなボタン、似たような色、重複した部品が増えると、どれが正しいのかわからなくなります。

導入初期から完璧なルールを作る必要はありませんが、最低限の方針は必要です。ファイル名、部品名、色名、レビュー方法だけでも決めておくと、後から整理しやすくなります。

15. Penpotを活用する実践手順

Penpotを効果的に使うには、単に画面を作るだけでは不十分です。小さく始め、部品を整理し、開発者を巻き込み、設計値を共通化し、継続的に改善する流れが重要です。

15.1 小さく始める

Penpotを導入するときは、最初から全社で使うのではなく、小さな案件から始めるほうが安全です。ログイン画面、問い合わせ画面、記事カード、設定画面など、範囲が明確な画面を選ぶと学習しやすくなります。

小さく始めれば、操作方法、共有方法、レビュー方法、開発者との受け渡しを短い期間で確認できます。問題が出ても影響範囲が小さいため、改善しながら運用を作れます。

15.2 部品を整理する

画面が増える前に、よく使う部品を整理することが重要です。ボタン、入力欄、カード、見出し、通知、メニューなどを部品化しておけば、新しい画面を作る速度が上がります。

部品整理を後回しにすると、似たような部品が増えて管理が難しくなります。最初は少ない部品でよいので、使いながら改善し、必要に応じて種類を増やす方針が現実的です。

15.3 開発者を巻き込む

Penpotを活用するなら、開発者を最後の受け渡し段階だけで呼ぶのではなく、設計途中から参加してもらうべきです。実装しにくい配置や不足している状態を早めに見つけられます。

開発者が設計段階で意見を出すと、完成後の手戻りが減ります。デザイナーと開発者が同じ設計ファイルを見て会話することで、現実的で実装しやすい画面を作れます。

15.4 設計値を共通化する

色、文字、余白、角丸などの設計値は、Penpot上で整理し、開発側でも同じ考え方で管理するべきです。設計値を共通化すると、画面ごとの差を減らし、製品全体の一貫性を保ちやすくなります。

共通化の目的は、単に作業を楽にすることではありません。将来の変更に強くし、複数人で作業しても品質を保てるようにすることが本質です。

15.5 改善を続ける

Penpotの運用は、一度決めて終わりではありません。実際に使う中で、部品名、ファイル構成、レビュー方法、設計トークンの扱いを改善していく必要があります。

最初から完璧を目指すと、導入が重くなります。まず使い、問題を見つけ、少しずつ直していくことで、Penpotは単なる設計ツールではなく、チームの製品開発基盤になります。

おわりに

Penpotとは、オープンソースで使える画面設計プラットフォームであり、デザイナーと開発者の距離を縮めるための実務的な道具です。画面を作るだけでなく、試作品、部品、設計トークン、検査機能、自社運用を組み合わせることで、製品開発全体の品質と速度を高められます。

特に、設計と実装のズレを減らしたいチーム、自社運用で設計データを管理したい組織、長く使えるデザインシステムを育てたい企業には、Penpotが強い選択肢になります。ただし、導入時には操作学習、運用ルール、保守体制、既存ツールからの移行計画も必要です。

Penpotをうまく使うためには、小さく始めて、部品を整理し、開発者を早めに巻き込み、設計値を共通化することが大切です。そうすれば、Penpotは単なる画面作成ツールではなく、チームが継続的に良い製品を作るための設計資産になります。