Google Stitch でUIを作り始めてから、ある種の悩みが繰り返し出てくるようになった。
「この情報、タブにすべきか、アコーディオンにすべきか。」
設定画面、商品詳細ページ、FAQセクション、プロフィール編集。情報を「折り畳む」必要がある場面は多い。でも Stitch でプロンプトを書くたびに、どちらの UIコンポーネントを指定すればいいか迷う時間が生まれていた。
この記事は、その迷いと向き合ってきた記録だ。Google Stitch を使いながら、タブとアコーディオンの使い分けについて自分なりの判断軸を作っていった過程を正直に書く。UIデザインの「正解」の話ではなく、Stitch というツールを通して自分の設計の考え方がどう変わったか、という話だ。
結論から言うと
タブとアコーディオンの使い分けについて、私が辿り着いた判断軸は「ユーザーがその情報をどの順番で・どの頻度で参照するか」だ。
一言で言えば、「並列で選ぶならタブ、縦に探すならアコーディオン」。この基準を持ってから、Stitch へのプロンプトが迷いなく書けるようになった。
タブUIとアコーディオンの定義——まず整理しておく
タブUIとは何か
タブUIとは、画面上部や左側に並んだ見出し（タブ）をクリックすることで、対応するコンテンツエリアを切り替えて表示するUIコンポーネントのことです。同時に表示できるのは原則1つのタブのみで、選択されていないタブのコンテンツは非表示になる。
代表的な使用例としては、商品詳細ページの「説明」「仕様」「レビュー」の切り替え、アカウント設定画面の「プロフィール」「セキュリティ」「通知」の切り替えなどが挙げられる。
実際に Stitch で「商品詳細ページのタブUI」と指定してプロンプトを送ってみると、タブ見出しとコンテンツエリアが整然と生成された。タブの数・ラベルまで自然な配置になっていて、修正の手間はほとんどなかった。
アコーディオンとは何か
アコーディオンとは、見出し行をクリックするとその下にコンテンツが展開し、もう一度クリックすると閉じるUIコンポーネントのことです。複数の項目が縦に並んでおり、各項目は独立して開閉できる。
代表的な使用例はFAQセクションだ。「よくある質問」の一覧が並んでいて、気になる質問だけをクリックして展開する、あの形式がアコーディオンの典型だ。他にも、サイドバーのカテゴリナビゲーション、料金プランの詳細説明、フォームの追加入力欄なども使われる。
Stitch でも「FAQ形式のアコーディオン」というプロンプトを書けば、開閉ボタン付きのアコーディオンレイアウトを素早く生成できる。ただし Stitch が出力するのはあくまで静的なデザインで、実際の開閉動作（JavaScriptの挙動）は別途実装が必要だ。
迷い始めたきっかけ——設定画面の設計で詰まった
「設定画面」でどちらを使うか迷った
SaaS ツールの設定画面を Google Stitch で設計しているとき、問題が起きた。設定項目のカテゴリが7種類あった。
- アカウント情報
- パスワード・セキュリティ
- 通知設定
- 支払い・請求
- チームメンバー
- API・連携
- プランの変更
最初は「タブで作ろう」と思ってプロンプトを書いた。Stitch は横並びに7つのタブが並んだUIを生成した。見た目は悪くない。でも実際にブラウザ幅を縮めるとタブが折り返し始めて、スマートフォン表示で崩れた。
次に「アコーディオンで作ろう」と切り替えた。7項目が縦に並んで、それぞれ開閉できる。スマートフォン表示でも崩れない。でもレビュアーから「よく使う設定項目に毎回スクロールしないといけない」というフィードバックが来た。
結局、「大カテゴリはサイドバーナビゲーション、各カテゴリ内の詳細項目はアコーディオン」という構造に落ち着いた。でもその結論に至るまで、3パターン試して2日かかった。
この迷いが「判断軸を作るきっかけ」になった
同じような迷いをその後も繰り返した。商品スペック比較表ではタブか、アコーディオンか。ヘルプページの構成では？オンボーディングの入力フローでは？
そのたびに「なんとなく」で決めていたのが、段々と効率が悪くなってきた。Stitch でプロンプトを書くとき、コンポーネントの選択で時間を取られるのは本末転倒だ。
そこで一度立ち止まって、「自分はどういう理由でタブを選び、どういう理由でアコーディオンを選んでいるのか」を言語化してみた。
私が辿り着いた判断軸——3つの問いで選ぶ
問い1：ユーザーは「どれかひとつを選ぶ」のか「必要なものを探す」のか
これが最も重要な問いだ。
ユーザーが「商品の説明が見たい」「レビューを確認したい」というように、選択肢の中からひとつを能動的に選ぶ動作をする場合は、タブが向いている。タブは「選択肢を横並びに並べる」構造なので、選択行動と相性がいい。
一方、「何か問題が起きたとき」「特定の情報が欲しいとき」というように、リストの中から必要なものを探す動作をする場合は、アコーディオンが向いている。FAQが典型例で、ユーザーは全部を読みたいわけではなく、自分の疑問に関係するものだけ開きたい。
実際に Stitch でこの判断軸を使うようになってから、プロンプトの迷いがほぼなくなった。「ユーザーが選ぶUI → タブ」「ユーザーが探すUI → アコーディオン」この2択で始められる。
問い2：カテゴリ間を「頻繁に行き来する」か「一度選んだら留まる」か
タブUIのもうひとつの強みは、カテゴリ間の切り替えコストが低いことだ。「説明を見てからレビューも確認する」という行動が自然に起きる場合、タブの方がユーザーにとってストレスが少ない。
アコーディオンはカテゴリ間の移動がタブより手間がかかる（閉じて → スクロールして → 開く）。頻繁に行き来する必要がある情報には不向きだ。
逆に、「見つけたら読んでそれで終わり」という情報（FAQの回答、規約の詳細など）はアコーディオンで問題ない。
問い3：モバイル表示で「横幅に余裕があるか」
実装観点の話だが、タブはカテゴリ数が増えると横幅を圧迫する。4〜5個以内に収まるならタブが機能するが、6個以上になるとスマートフォン表示で折り返したりスクロールが必要になる。
カテゴリが多い場合（6個以上）は、アコーディオンまたはサイドナビゲーションの方がモバイルフレンドリーだ。
Stitch でプロトタイプを作る際、モバイル画面サイズで確認する習慣をつけてから、この問いの重要性を身に染みて実感している。タブが5個以上あるデザインをモバイルで見ると、ほぼ確実に見た目が崩れる。
Google Stitch でタブとアコーディオンを生成するときのコツ
タブUIを生成するときのプロンプトの書き方
Stitch でタブUIを生成するとき、単に「タブUI」と書くより、以下の要素を含めると精度が上がる。
- タブの数と各ラベル（例：「説明」「仕様」「レビュー」「Q&A」の4タブ）
- デフォルトで選択されているタブ（例：「説明タブが選択されている状態」）
- タブコンテンツの大まかな内容（例：「説明タブには商品の特徴説明と画像が3枚」）
- スタイルの方向性（例：「アンダーライン型のミニマルなタブ」「背景色で区切るタイプのタブ」）
実際に「商品詳細ページ。説明・仕様・レビュー・Q&Aの4タブ。説明タブが選択された状態。アンダーライン型でミニマルなデザイン」とプロンプトを書いたとき、ほぼ修正不要のUIが生成された。
アコーディオンを生成するときのプロンプトの書き方
アコーディオンは「FAQ形式」と書くだけで自然に生成されやすい。ただし、より精度を上げるには以下を含めると良い。
- 項目数（例：「8つの質問と回答」）
- デフォルトの開閉状態（例：「最初の項目だけ開いた状態」「すべて閉じた状態」）
- 展開時の内容の密度（例：「各回答は2〜3文の短い説明」「リストを含む詳細な回答」）
- 開閉インジケーターのスタイル（例：「右端に＋/−アイコン」「シェブロン（∨）アイコン」）
「よくある質問セクション。8問。最初の1問だけ開いた状態。右端にシェブロンアイコン。各回答は2〜3文」というプロンプトで、実装に近い品質のアコーディオンが生成された。
判断軸を持って気づいたこと
「どちらでもいい」場面の方が多い
判断軸を作って気づいたのは、「どちらでも問題ない」場面が意外と多い、ということだ。
ヘルプページのカテゴリ一覧は、タブで作っても、アコーディオンで作っても、サイドナビで作っても、ユーザーは目的の情報に辿り着ける。大事なのはどのコンポーネントを選ぶかより、「ラベルが分かりやすいか」「コンテンツが適切に整理されているか」だ。
Stitch を使い始める前は、コンポーネントの選択自体を難しく考えすぎていた気がする。Stitch で素早くどちらのパターンも生成して「見比べる」ことができるようになってから、「これだ」と決める感覚が速くなった。
タブとアコーディオンを「組み合わせる」選択肢もある
また、タブとアコーディオンを組み合わせる構造が最適な場合もある。
先に書いた設定画面の例がそうだが、「大カテゴリはタブ（またはサイドナビ）、各カテゴリ内の詳細項目はアコーディオン」という二層構造は、情報量が多い画面で有効に機能する。
Stitch でこの構造を作るときは、「左サイドバーに7項目のナビゲーション、メインエリアにアコーディオン形式の詳細設定」というプロンプトを書く。2ステップに分けて生成してから合成する方法でも問題ない。
FAQ
Q1. Google Stitch でタブUIを生成するとき、タブの開閉動作（JavaScript）も出力されますか？
Stitch はHTMLとCSSのエクスポートに対応していますが、タブの切り替え動作を実現するJavaScriptは基本的に含まれません。Stitch が生成するのはデザインの静的な見た目です。実際に動くタブUIにするには、JavaScriptを別途追加するか、React等のフレームワークを使う必要があります。ただし Stitch の出力するHTMLはセマンティクスが整っているため、JavaScriptを追加する作業は比較的スムーズです。
Q2. タブが6個以上ある場合、どのように対処しますか？
タブが6個以上になるとモバイル表示で崩れやすくなります。この場合の対処法は主に3つです。1つ目は横スクロール可能なタブにする（スマートフォンで左右にスワイプして追加タブを見せる）。2つ目はドロップダウンで追加タブをまとめる。3つ目はサイドナビゲーションに切り替える。Stitch でプロンプトを書く際に「スクロール可能なタブバー」と指定すると、横スクロール型のタブデザインを生成してくれます。
Q3. アコーディオンの「全部同時に開ける」か「1つしか開けない」かはどちらが良いですか？
これはユースケースによります。FAQセクションなら「複数同時に開ける」方が便利で、ユーザーが複数の回答を比較しながら読めます。一方、設定項目の詳細説明のように「一度にひとつのコンテキストに集中してほしい」場合は「1つしか開けない（accordion exclusive）」方が適切です。Stitch でプロンプトを書く際に「同時に複数展開可能なアコーディオン」と指定できます。
Q4. タブとアコーディオン以外に「情報を折り畳む」方法はありますか？
はい、いくつかあります。ドロップダウンメニュー（選択肢の一覧を折り畳む）、エクスパンダブルカード（カードをクリックすると詳細が展開される）、サイドドロワー（画面端からスライドするパネル）、モーダルダイアログ（別レイヤーで表示する）などが代表例です。Stitch でこれらのコンポーネントを生成する際も、同様にプロンプトで具体的に指定すると精度が上がります。
Q5. Google Stitch はどのようなUIコンポーネントを生成できますか？
Stitch はプロンプトで指定できる範囲でほぼあらゆる静的UIコンポーネントを生成できます。タブ、アコーディオン、カード、モーダル、ドロワー、フォーム、ナビゲーション、テーブル、リスト、バナー、バッジ、ボタン、アイコンボタン、入力フィールド、チェックボックス、ラジオボタン、トグルスイッチ、スライダー、プログレスバー、ローディングスピナーなど広い範囲をカバーしています。具体的なコンポーネント名とスタイルをプロンプトに含めると生成精度が上がります。
Q6. Google Stitch でコンポーネントの再利用はできますか？
Stitch には Figma のようなコンポーネントライブラリ機能は現時点（2026年4月）でありません。同じデザインパターンを複数画面で使い回したい場合は、生成したデザインを参照画像として Stitch に読み込ませ「この要素と同じスタイルで○○を作って」と指示する方法が現実的です。コードとして書き出した場合は、CSSのクラスやReactコンポーネントとして再利用できます。
注意点・失敗しやすいポイント
1. タブに詰め込みすぎると「結局何を見ればいいかわからない」UIになる
タブに入れるコンテンツが多すぎると、ユーザーはどのタブを見れば目的の情報が見つかるか把握できなくなる。タブを使う場合、各タブのラベルは「1〜2語で内容が予想できる」ものにし、コンテンツのオーバーラップを避けることが重要だ。Stitch でプロンプトを書く際、タブラベルを具体的に指定するのはこのためでもある。
2. アコーディオンは「全部読んでほしい情報」に向かない
重要な情報がアコーディオンで折り畳まれていると、ユーザーが見落とすリスクがある。利用規約の重要条項、料金に関わる注意事項など「必ず読んでほしい」情報はアコーディオンではなく、展開した状態で表示する方がリスクが低い。
3. SEOの観点でアコーディオンに注意が必要な場合がある
折り畳まれたコンテンツはクローラーに読まれにくい場合がある（実装方法による）。重要なキーワードや説明文がアコーディオン内に入っている場合、SEOへの影響を確認すること。Google は折り畳みコンテンツもインデックスする方針だが、展開状態のコンテンツに比べて評価が低くなる可能性は否定できない。
4. アクセシビリティ対応を忘れずに
タブもアコーディオンも、キーボード操作・スクリーンリーダー対応が実装上必要だ。Stitch が生成するデザインはビジュアルのみで、アクセシビリティ属性（aria-expanded、role=”tabpanel”など）は開発時に追加が必要になる。設計段階で「このコンポーネントにはアクセシビリティ対応が必要」とコメントしておくと、開発への引き継ぎがスムーズだ。
まとめ
タブとアコーディオンの迷いは、突き詰めると「ユーザーの行動パターンをどう読むか」という問いに行き着く。
「選ぶUI → タブ」「探すUI → アコーディオン」「カテゴリが多い・モバイル対応が必要 → アコーディオンまたはサイドナビ」。この3つの問いを持ってプロンプトを書くだけで、Google Stitch での設計の迷いはぐっと減る。
何より大事なのは、Stitch で素早く両方のパターンを生成して「見比べる」ことだ。頭の中で考え込むより、Stitch に出させてから判断する方がずっと速い。「完璧なプロンプトを書いてから送る」より「とりあえず出してみる」が Stitch の正しい使い方だと思っている。
ツールの特性を活かして、設計の判断を「見ながら考える」プロセスに変えていく。そういう使い方の積み重ねが、自分なりの判断軸を育ててくれた気がしている。
