カスタムSF Symbols：可変テンプレートと必須の3つのソース

Appleは6,900以上のSF Symbolsを提供しており、SF Symbolsアプリも無料で使えます。それでも多くのアプリでは、いずれAppleが用意していないアイコンが必要になります。ブランドマーク、分野固有のグリフ、システムの語彙に収まらない独自アクションなどです。

その場合、静的なSVGを置くのではなく、カスタムSF Symbolを作るのが正しい道筋です。カスタムSF Symbolsなら、システム側の仕組みをそのまま利用できます。Dynamic Typeに合わせて拡大縮小され、Symbol Effectsアニメーションに対応し、4つのレンダリングモードで描画され、SF Proのタイポグラフィに揃い、アプリごとの追加コードなしでアクセシビリティ設定にも従います。静的SVGには、こうした利点がありません。

この記事では、WWDC 2021のSF Symbols 3で導入されたSF Symbolsアプリの可変テンプレートを軸に、作業の流れを見ていきます¹。焦点は「必須となる3つの元デザインとは何か、なぜ必要なのか」です。テンプレート形式こそが、この作業の成否を左右する土台であり、デザイナーもエンジニアも最初に見落としやすい部分だからです。その後のSF Symbols 4、5、6、7では、可変カラー、Magic Replaceの遷移、グラデーション対応、アニメーション効果などが追加されました。ただし、可変テンプレートの中核である3ソース構造は、SF Symbols 3以降ずっと安定しています。

要点

• カスタムSF Symbolsは、SF Symbolsアプリから書き出したテンプレート（File > Export Template、または⌘E）を出発点にします²。テンプレートはSVGで、サイズ調整用のシステム定義ガイドと、置き換え対象となる仮のシンボルデザインが含まれています。
• 可変テンプレートで必要な元デザインは3つだけです。Ultralight-Small、Regular-Small、Black-Smallです。残りの24種類（3つのスケール × 9つのウェイト）は、SF Symbolsアプリが自動で補間します³。
• 最も重要なのはパス互換性です。3つのソースすべてで、各パスのアンカーポイント数、開始点、方向が一致していなければなりません。これが崩れると、補間で壊れたグリフが生成されます。
• カスタムシンボルは、4つのレンダリングモード（monochrome、hierarchical、palette、multicolor）とレイヤー構造（primary、secondary、tertiary）に対応します。Symbol Editorのレンダリングインスペクターペインで、サブパスを各レイヤーに割り当てます。
• 最終的には、シンボルファイルをXcodeのアセットカタログにSymbol Image Setとして追加します。SwiftUIでは、シンボル名を使ってImage(_:)から参照します。残りはシステムが処理します。

可変テンプレート

SF Symbols 3（WWDC 2021）で、可変テンプレートが導入されました³。これは3つの元デザインを1つのSVGファイルに収め、そこからSF Symbolsアプリが27種類の完全なグリッドを生成する形式です。必要な3つのソースは次のとおりです。

• Ultralight-Small。 最も細いウェイト、最も小さいスケール。
• Regular-Small。 中間のウェイト、最も小さいスケール。
• Black-Small。 最も太いウェイト、最も小さいスケール。

アプリはこの3つを使って、残りの24セル（Ultralight-Medium、Regular-Medium、Black-Medium、Ultralight-Large、Regular-Large、Black-Large、さらに各スケールでの中間ウェイト）を補間します。元のパス構造に互換性があれば、補間は自動で行われます。

SF Symbols 3で可変テンプレートが導入される前は、カスタムシンボルでは27種類すべてを手作業で描く必要がありました。可変テンプレートによって、それが「3つを作り、あとは補間する」作業に変わりました。これは、現実的に進められるデザイン作業になるか、プロジェクトを止めてしまう負担になるかの違いです。

互換データの要件

パス補間では、3つの元パスが同じ形状を同じ順序で記述している必要があります²。

• アンカーポイント数が同じ。 Regularウェイトの正方形に4つのアンカーがあるなら、見た目の曲率が違っていても、UltralightとBlackにも4つのアンカーが必要です。
• 開始点が同じ。 パスの最初のアンカーは、3つのウェイトすべてで概念上同じ位置に置きます。たとえば、常に左上の角から始めます。
• 方向が同じ。 3つのパスは、形状を同じ順序でたどる必要があります。時計回りならすべて時計回り、反時計回りならすべて反時計回りです。

このいずれかを満たしていないと、補間の不具合が出ます。折れ、誤った重なり、消えるストロークなどです。SF Symbolsアプリは一部を表面化してくれます。バリエーションプレビューでは補間結果を確認できます。ただし、微妙な問題は最終的に書き出したアセットで初めて現れることもあります。

実務では、まずRegular-Smallを作り、同じパスの骨格を使ってストローク幅を細くしたUltralight、太くしたBlackを派生させるのが堅実です。この作り方なら、アンカーポイント数、開始点、方向が構造的に保たれます。各ウェイトを別々に描くと互換性の問題が起きやすく、結局は作り直すよりデバッグに時間がかかります。

作業の流れ

コンセプトから実際に使えるアセットまで、手順は5つです。

1. 似ている既存シンボルを探す

SF Symbolsアプリのライブラリには6,900以上のシンボルがあります。作りたいものに構造が近いシンボルを探します。たとえば、円の中に要素があるもの、四角形にオーバーレイがあるもの、線に装飾が付いたものなどです。テンプレートを書き出す作業では、既存シンボルのジオメトリが出発点になります。

2. テンプレートを書き出す

File > Export Template…、または⌘Eを使います。テンプレートの種類には「Variable」を選びます。書き出されるのはSVGファイルです。そこにはシンボルの3つの元ウェイトに加え、SF SymbolsがSF Proのテキストに揃えるために使うキャップハイト、ベースライン、視覚上の余白を示す参照ジオメトリが含まれています。

3. テンプレートのパスを置き換える

SVGをベクターエディター（Sketch、Figma、Illustrator、Affinity Designer、Inkscape）で開きます。テンプレート内の名前付きレイヤーには、3つの元デザインが入っています。レイヤー名とキャップハイト／ベースラインの揃え方を保ったまま、それぞれを独自デザインに置き換えます。

ここで重要になるのがパス互換性です。各ウェイトを描き直すのではなく、同じパスの骨格から作り、ストローク幅や塗りの太さを変えてください。ベクターツールで複製して調整する流れが、一番無理のない方法です。

4. 再読み込みして検証する

変更したSVGをSF Symbolsアプリにドラッグして戻します。アプリが27種類のバリエーションを生成し、バリエーショングリッドに表示します。各ウェイトとスケールの組み合わせを、複数のズームレベルで確認してください。補間の不具合は、中間ウェイトで現れることが多く、最初は見落としがちです。

複数の視覚要素を持つシンボル（本体とバッジ、円と内部形状など）では、レンダリングインスペクターペインを開き、サブパスをレイヤー（primary、secondary、tertiary）に割り当てます。このレイヤー割り当てによって、hierarchical、palette、multicolorモードでの描画が決まります。

5. Xcodeに追加する

シンボルファイル（SF Symbolsから書き出した.svg）を、Xcodeのアセットカタログにドラッグします。XcodeはこれをSymbol Image Setとして扱います。コードからは次のように参照します。

Image("MyCustomSymbol")
    .symbolRenderingMode(.hierarchical)
    .foregroundStyle(.tint)

Image(_:)（systemName:パラメータなし）は、アセットカタログから読み込みます。システムシンボルで使える.symbolRenderingMode、.foregroundStyle、.symbolEffect、Dynamic Typeの挙動は、正しく作られたカスタムシンボルにも同じように適用されます。

レンダリングモードとレイヤー構造

SF Symbolsが公開している4つのレンダリングモードは、カスタムシンボルでもシステムシンボルと同じように動作します⁴。

• Monochrome。 単色（foregroundStyle）です。最も単純で、最もよく使われるモードです。
• Hierarchical。 単色ですが、レイヤーごとに不透明度が変わります。レンダリングインスペクターペインで定義したレイヤーには、事前設定された不透明度が適用されます。開発者は1つの色を指定するだけで、視覚的な階層を得られます。
• Palette。 レイヤーごとに明示的な色を指定します。開発者が複数のforegroundStyle引数を渡すと、それぞれのレイヤーに別々の色が適用されます。
• Multicolor。 レイヤーごとに固定色を使います。カスタムシンボルでは、Symbol EditorのMulticolor設定でデザイナーが割り当てた色が使われます。

hierarchical、palette、multicolorを機能させるのはレイヤー構造です。レイヤー割り当てのないカスタムシンボルでは、すべてのパスがprimaryレイヤーにまとめられます。monochromeでは描画されますが、他のモードでは視覚的な階層が出ません。奥行きが役立つシンボルでは、数分かけてレンダリングインスペクターペインでレイヤーを割り当てる価値があります。

よくある失敗

カスタムシンボルの失敗ログでよく見るパターンは3つあります。

パス互換性の違反。 最も多い問題です。「Regularウェイトではきれいに見える」のに中間ウェイトで表示が崩れるシンボルは、ほぼ必ずパス互換性に問題があります。診断するには、SF Symbolsアプリのバリエーショングリッドを開き、中間ウェイトのバリエーションを見ます。折れや、期待どおりに補間されていないストロークがあるなら、3つの元パスのどれかが互換性を破っています。

ベースラインまたはキャップハイトのずれ。 テンプレートのベースラインガイドを尊重せずに作ったシンボルは、テキストの横に置いたときに不自然に見えます。視覚的には、.bodyスタイルのTextとインラインに置いたとき、シンボルが高すぎたり低すぎたりします。修正するには、テンプレートの参照ジオメトリを使い、シンボルの光学的中心をキャップハイトの中点に合わせます。

レイヤー割り当てがない。 内部構造が豊かなシンボル（複数の視覚要素を持つもの）でも、レイヤー割り当てがないと正しく見えるのはmonochromeだけです。hierarchicalやpaletteモードを選んだアプリでは、平坦な出力になります。修正するには、レンダリングインスペクターペインを開き、各サブパスをレイヤーに割り当てます。主要な形状はprimary、アクセントはsecondary、3段目の細部はtertiaryにします。

このパターンがiOS 26以降のアプリに意味すること

要点は3つです。

1. アプリ内アイコンには、生のSVGではなくカスタムSF Symbolsを使う。 カスタムシンボルの作業には確かに設計上の手間がかかります。それでも、Dynamic Type、Symbol Effects、レンダリングモード、アクセシビリティといったシステム統合を考えると、長くUIに残るアイコンには十分に見合います。静的SVGが向いているのは、単発のマーケティング素材です。中核的なUIではありません。

2. 1つの骨格から設計し、パス構造ではなくストロークの太さを変える。 パス互換性の違反は、カスタムシンボルで最も重要な失敗要因です。防御的な設計プロセスは、まず1つのウェイト（Regular-Small）から始め、同じパスジオメトリを使ってストロークを細くしたUltralightと、太くしたBlackを派生させることです。この作り方なら、互換性は構造的に保たれます。

3. レンダリングモードの恩恵を受けるシンボルでは、レイヤーを明示的に割り当てる。 monochromeでしか意味を持たないシンボルは、SF Symbolsシステムの半分から自ら外れているようなものです。レンダリングインスペクターペインでの作業は数分で終わります。その結果、システムシンボルと同じようにhierarchical、palette、multicolorモードに参加できるシンボルになります。

Appleエコシステムの関連記事群はこちらです。型付きのApp Intents、MCPサーバー、ルーティングの論点、Foundation Models、実行時LLMと開発支援LLMの違い、3つのサーフェス、信頼できる唯一の情報源パターン、2つのMCPサーバー、Apple開発のためのフック、Live Activities、watchOSの実行時契約、SwiftUIの内部構造、RealityKitの空間的な考え方、SwiftDataスキーマの規律、Liquid Glassパターン、複数プラットフォームへの出荷、プラットフォームマトリクス、Vision framework、Symbol Effects、Core ML推論、Writing Tools API、Swift Testing、Privacy Manifest、プラットフォームとしてのアクセシビリティ、SF Proタイポグラフィ、visionOSの空間パターン、Speech framework、SwiftDataマイグレーション、tvOSフォーカスエンジン、@Observableの内部構造、SwiftUI Layout protocol、私が書かないと決めていること。ハブはAppleエコシステムシリーズにあります。AIエージェントとiOSのより広い文脈については、iOSエージェント開発ガイドをご覧ください。

FAQ

SF Symbolsアプリは必要ですか。それとも別の方法でカスタムシンボルを作れますか。

SF Symbolsアプリは公式ツールであり、検証済みかつApp Store互換のカスタムシンボルを生成できる唯一のツールです。サードパーティ製ツールやオンラインコンバーターもありますが、出力されるSVGがテンプレート形式の要件を満たすとは限りません。本番アプリでは、SF Symbolsアプリを使ってください。

Windowsでカスタムシンボルを作れますか。

SF SymbolsアプリはmacOS専用です。書き出したSVGテンプレートの編集自体は、ベクターエディターがあればどのプラットフォームでもできます。ただし、書き出しと再読み込みの手順にはmacOSが必要です。多くのチームでは、少なくとも1人のデザイナーがmacOSでその手順を担当できます。リモートチームでは、SVGファイルをバージョン管理や共有ストレージ経由で受け渡しします。

カスタムシンボルで.symbolEffectをサポートするにはどうすればよいですか。

シンボル構造が正しく作られていれば、ほとんどのSymbol Effectsは自動で動作します。bounce、pulse、scaleなどは、シンボルの出所に関係なく適用されます。.replaceのコンテンツ遷移では、遷移元と遷移先のシンボルが互換性のある構造を持っている必要があります。たとえば、レイヤー数が近く、全体形状も似ていることが重要です。この関連記事群のSymbol Effectsの記事では、効果の語彙を詳しく扱っています。

XcodeのSymbol Image Setと通常のImage Setは何が違いますか。

Symbol Image Setは、シンボルの完全なテンプレート（27種類すべてのバリエーション）を取り込み、SF Symbolsのレンダリングパイプライン経由で公開します。Dynamic Typeに合わせて拡大縮小され、レンダリングモードに参加し、.symbolEffectでも動作します。通常のImage Setは、静的なラスター画像またはSVGリソースであり、そうした仕組みには参加しません。カスタムSF SymbolsにはSymbol Image Setを使ってください。

カスタムシンボルはvisionOSやwatchOSでどのように扱われますか。

システムシンボルと同じです。各プラットフォームが期待するサイズ（watchOSでは小さめ、visionOSでは大きめ）で描画され、プラットフォームのアクセシビリティ機能に参加し、色や効果の慣例にも従います。カスタムシンボルの作成は一度だけで済み、クロスプラットフォームの挙動は自動です。この関連記事群のAppleプラットフォームマトリクスとvisionOSの空間パターンの記事では、プラットフォームごとの考慮点を扱っています。

App Storeレビューへの影響はありますか。

ありません。カスタムSF Symbolsは、他のAsset Catalogアセットと同じようにレビューされます。視覚スタイルのガイドライン、たとえばAppleのUIパターンになりすまさないこと、ブランド商標を侵害しないことは、他のカスタムアートワークと同様に適用されます。それ以外では、標準的な画像アセットとして扱われます。

参考文献