スマートフォンを回転させて画面をテストすると、レイアウトがきれいに適応したり、崩れたりします。テキストが再流れ、ボタンがジャンプし、モーダルが突然間違ったエリアを隠したり、動画プレイヤーが予想どおりに動作したりします。その小さな瞬間は ポートレート向き デザイン用語としての終わり、製品決定としての始まり。
モバイル向けに開発している場合、明確な答えが必要です。 「ポートレート向けの向き」クラスルームでの定義だけではなく、開発者用の定義。レイアウトへの影響、回転のサポート時期、ロック時期、ウェブアプリ、ネイティブアプリ、Capacitorプロジェクトでの扱いを考慮せずに、脆弱なユーザー体験を生み出さないようにする方法。
目次
- ポートレート向きの理解
- ポートレートとランドスケープの基本的な比較
- さまざまなメディアで使用される一般的な用途
- Web上でのオリエンテーション管理
- モバイルアプリのオリエンテーション管理
- 画面回転のベストプラクティス
ポートレート向きの理解
ユーザーは画面の回転を最初に認識します。開発者は、回転がインターフェイスを破壊するときに認識します。

ポートレート向き 画面の高さは幅より大きい ということです。それが本質です。それは視覚芸術から来ています。人々の顔と上半身の肖像画は通常、垂直にフレームされていました。 同様の概念は、ページデザイン、写真、デジタルインターフェイスに持ち込まれました。.
そのより広い歴史についての良い参考資料は
Wikipediaのページ向きの概要
ビルダーの重要な点は、ポートレート向きは画面サイズ、デバイス、ファイル形式に依存しないことです。
A feed, article view, settings screen, or chat thread is usually read more naturally in a vertical frame. That’s one reason orientation choices are directly connected to mobile app user experience decisions, not just visual styling.
Treat portrait as a layout context, not just a device position. Where junior developers often get confused
The usual confusion is mixing up
orientation with resolution or 画面の向きと解像度を混同するのはよくある間違いです。 画面の向き. これらは関連しているものの、同じものではない。
- 向き 向き
- 解像度 解像度
- アスペクト比 端末の向きは、端末の向きが異なる場合でも、同じ向きの状態を共有することができます。 したがって、対応性のあるUIロジックは、より具体的な質問をする前に、「高さが幅より大きいか?」と尋ねる必要があります。
ポートレート対ランドスケープの基本的な比較
この概念を理解する簡単な方法は、構成を通じて行うことです。ポートレート画は、人物や他の高い主題に焦点を当てます。水平方向の絵は幅、背景、周囲の空間を捉えます。UIも同様です。
ポートレートとランドスケープの向きを比較する視覚的なガイド、コンテンツとデバイス表示の最適な使用方法を詳しく説明しています。

In imaging and UI design, portrait orientation is the rectangle where 高さが幅を超えているしたがって、長い辺は垂直です。 これは、水平方向とは逆のものです。 SLR Loungeの用語解説 技術的な定義と、その形状が高さの多い対象物や垂直構造に合う理由について説明しています。
1つの表の差異
| 向き | 形状 | 最適なフィット | context: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Message key `native_build_builder_compare_fit_feature` (Native Build Builder Compare Fit Feature). |
|---|---|---|---|
| 典型的な効果 | 肖像 | 高さが幅を超えている | __CAPGO_KEEP_0__ |
| 横向 | 高さより幅が広い | 動画、地図、ダッシュボード、広いシーン | 横方向のコンテキストを表示する |
基本的なことですが、製品レビューの際にトレードオフをしながら、役に立つことがあります。
ユーザーにとっての変化
ポートレートは、注意を狭める傾向があります。側面のコンテンツを減らし、上から下へのフローを促します。なぜなら、ソーシャルフィード、記事ページ、オンボーディングステップ、チャットインターフェイスはポートレートで綺麗に感じられるからです。
水平方向は逆の効果を与えます。幅が広がり、スプリットビュー、タイムライン、ギャラリー、メディア再生、データ重視の表面、インマーシブビューなどに役立ちます。レイアウトが横方向の比較を必要とする場合、この水平形式はよりゆとりがあります。
ポートレートは通常、焦点です。ランドスケープは通常、コンテキストです。
開発者にとっての変化
最も大きな間違いは、幅の広い形式をポートレートの拡大版として扱うことです。それではありません。情報の階層はしばしば変わります。
例えば:
- 横向き横向きの場合、ダッシュボードはカードを 1 列に積み重ねることができます。
- より広い向き同じダッシュボードは、フィルターやサイドパネルを表示するために複数の列にシフトするかもしれません。
- 横向き支払いフォームでは、大きなタップターゲットと 1 つの明確なフローを優先します。
- より広い向き同じ画面は、フィールドが垂直方向に圧縮されすぎると不快な感じがします。
インマーシブモバイルレイアウトを開発しているエンジニアは、エッジハンドリング、セーフエリア、フルスクリーンベHAVIORについて考える必要があります。調整している場合、 Capacitor エッジレスディスプレイ設定 利用可能なスペースをユーザーがどのように認識するかは、向きによって異なります。
さまざまなメディアで共通の使用例
ポートレート向きは、モバイル画面以外の場所でも見られます。 それは重要なことです。 その概念はソフトウェアで始まったわけではありません。 そして、ソフトウェアだけに属するものではありません。

写真と印刷物
プロのポートレート写真は明らかな例です。 垂直枠が人物の顔と体に合うことが多いのは、広い枠ではありません。 同じ論理がファッション写真、本の表紙、ポスター、雑誌の表紙にも当てはまります。
印刷物のデザインでは、読み物が上から下に移動するようにするために、ポートレートが使用されます。 その形状は、目がページを自然に下に移動するように助けます。
文書と日常のコミュニケーション
ほとんどのレポート、履歴書、手紙、内部ドキュメントは、ポートレートで設計されています。 それは、ポートレートが常に良くないからではなく、垂直ページが段落、見出し、リスト、署名のシーケンスを読むのに適しているからです。
PDFをエクスポートしたことがある人は、広い表が突然読めなくなったことがあるでしょう。 それはポートレートの限界を示しています。 あるコンテンツは、水平形式で表現する方が良いでしょう。 重要なのは、枠をコンテンツ構造に合わせることです。
モバイル製品とアプリのフロー
このような状況では、ポートレートは多くのチームにとってデフォルトのメンタルモデルになります。
ユーザーが繰り返し開く画面を考えましょう:
- チャットアプリ: メッセージは垂直に積み重ねられます。
- ソーシャルアプリ: 投稿、コメント、動画は上向きのフローで消費されます。
- リテールアプリ: 検索結果と製品リストは下方向にスクロールします。
- 銀行アプリ: 残高、取引、確認フローは通常垂直セクションに配置されます。
それらのパターンは偶然ではありません。ポートレートは一手での使用、指のスクロール、線形タスクの完了をサポートしています。
モバイルUIの多くは、インターフェイスが直立のデバイスを前提としているため、直感的です。
それが意味するのは、すべての画面がポートレートでなければならないということではありません。メディアビューア、地図、大きなチャート、カメラベースのワークフローは、より広いフレーミングが必要な場合があります。ただし、日常のタスクフローでは、ユーザーは通常ポートレートから始めます。
ウェブ上でのオリエンテーション管理
A web bug は最初は小さく見えます。アプリは正面のビュー ポートできれいに読み込まれます。ユーザーが端末を回転させると、グラフがフラッシュし、サイド バーが間違ったブレーク ポイントで表示され、キーボードが送信ボタンを隠します。ウェブのオリエンテーションは実際には状態についてです。ビュー ポートの形状が変わり、UI が予測可能な方法で反応する必要があります。
開発者にとって、これは 2 つのジョブを分離することを意味します。CSS はレイアウトの変更を取り扱います。JavaScript は動作の変更を取り扱います。モバイル向けに同じプロジェクトをパッケージングする場合、このウェブ層はまだ重要です。 Capacitor を使用してウェブ アプリをモバイル アプリに変換することは、ウェブ オリエンテーションの取り扱いが必要なくなりません。ウェブ オリエンテーションの基盤がより重要になります。 プラットフォームは、2 つの主なツールを提供します。Screen Orientation __CAPGO_KEEP_0__ は、オリエンテーションタイプと変更イベントを公開し、Web App Manifest はインストール済みアプリが、望ましい正面モードとして "landscape" または "portrait" を宣言できるようにします。
The platform gives you two main tools. The Screen Orientation API exposes orientation type and change events, and the Web App Manifest lets an installed app declare a preferred upright mode such as portrait, portrait-primaryCSS を使用してレイアウトが適応するようにします。 portrait-secondaryCSS で始めましょう。幅と高さが役割を入れ替える場合、最も安価で最も信頼できる方法で反応することができます。 これは、画面の形状に対する進歩的な強化と似ています。最初は、窄い正面のレイアウトをデフォルトとして開始し、ビュー ポートが幅が広くなるにつれて、セカンダリ UI にスペースを追加します。.
時間を節約するためのいくつかの実践があります。
時間を節約するためのいくつかの実践があります。
/* Default portrait-friendly layout */
.page {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
.sidebar {
display: none;
}
@media (orientation: landscape) {
.page {
grid-template-columns: 280px 1fr;
}
.sidebar {
display: block;
}
}
時間を節約するためのいくつかの実践があります。
時間を節約するためのいくつかの実践があります。
- __CAPGO_KEEP_0__から始めましょう: 主に端末を直立状態で使用する人々が多い場合、基本レイアウトをその状態に設定してください。
- 固定高さを避けましょう: 端末を回転させると、ブラウザのUIや仮想キーボードが表示される場合など、垂直空間が急激に減少します。
- 実際のインタラクション状態をテストしましょう: フォーム、固定ヘッダー、ボトムシートなど、回転中に失敗することが多いです。静的なスクリーンショットでは問題ありません。
JavaScriptを使用する必要がある場合:
CSSはボックスを並べ替えることができますが、グラフを再構築したり、ジェスチャーハンドラーをリセットしたりすることはできません。
JavaScriptを使用する必要がある場合:
function logOrientation() {
const type = screen.orientation?.type;
console.log('Current orientation:', type);
}
logOrientation();
screen.orientation?.addEventListener('change', () => {
logOrientation();
const isPortrait = window.innerHeight > window.innerWidth;
if (isPortrait) {
document.body.classList.remove('wide-mode');
} else {
document.body.classList.add('wide-mode');
}
});
回転がデータの表示またはインタラクションロジックを変更する場合、JavaScriptは対応する必要があります。回転がスペースや配置のみを変更する場合、CSSが対応する必要があります。
実践的なルールが、ジュニアチームが複雑さを避けるのに役立ちます。CSSがすでにうまく処理できるレイアウト決定を、JavaScriptで強制するのを避けましょう。
PWAの場合、好みの向きを設定してください
__CAPGO_KEEP_0__で作られたPWAが、ほとんど立ち上がった状態で使用される場合、manifestにそれを宣言してください。
{
"name": "My App",
"short_name": "MyApp",
"display": "standalone",
"orientation": "portrait"
}
これは好みであり、レスポンシブデザインの代替ではありません。ブラウザがインストールされたアプリがどのように開かれ、どのように動作するかを理解するのに役立ちます。
ブラウザが許可する場合、実行時にはオリエンテーションロックを要求することもできます:
async function lockPortrait() {
try {
await screen.orientation.lock('portrait');
console.log('Orientation locked');
} catch (err) {
console.log('Lock failed:', err);
}
}
これを慎重に使用してください。良くないルールは、タスク自体を破るような回転をロックすることです。例えば、ガイド付きのキャプチャフローまたは物理的な位置の厳密な制約があるスクリーンなどです。ほとんどの場合、インターフェイスを適応させる方が、デバイスとユーザーを尊重する良いエンジニアリングの選択です。
モバイルアプリのオリエンテーション管理
モバイルアプリはブラウザのタブよりも多くのことができます。アプリ全体のデフォルトの画面方向を宣言し、タスクがそれを要求する場合にのみ、画面単位で動作を変更することができます。その程度の制御は便利ですが、チームが回転を広く制限することで、単純なアプリがrigidな感じになるという共通の間違いも生み出します。

良いメンタルモデルはここで役立ちます。アプリ全体の設定はデフォルトのポリシーです。画面単位のcodeは例外層です。ポリシーを広い意図に使用し、例外を使用するのは、回転デバイスがユーザーが試みているタスクを完了するのを妨げる場合のみです。
ネイティブプラットフォームの制御
Android では、オリエンテーションは__CAPGO_KEEP_0__ AndroidManifest.xml 活動のために:
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />
This works like a top-level config flag. It is simple, predictable, and easy to enforce across the whole activity. The tradeoff is scope. If only one screen needs upright mode, applying that rule globally is usually too blunt.
On iOSでは、サポートされる方向はXcodeのターゲット設定とアプリメタデータを通じて設定されます。アプリ全体でサポートするものを定義し、特定のビュー コントローラーで厳格な要件がある場合に動作を細かく調整することができます。
That split matters for cross-platform teams. Native config answers, “What should this app generally allow?” Runtime code answers, “What should this screen do right now?”
Programmatic control in Capacitor apps
If you build with Capacitor, dynamic control usually belongs in code, close to the route or view that needs it. A sign-in screen may be easier to use in portrait. A media screen or camera flow may need to allow rotation based on how the device is held.
If you build with __CAPGO_KEEP_0__, dynamic control usually belongs in __CAPGO_KEEP_1__, close to the route or view that needs it. A sign-in screen may be easier to use in portrait. A media screen or camera flow may need to allow rotation based on how the device is held. Capacitor screen orientation plugin for Capacitor apps 画面方向プラグインは、画面の方向を読み取ることができ、特定のモード(例:ポートレート)で制限を適用し、ユーザーがフリックスクリーンに戻ると制限を解除することができます。
import { ScreenOrientation } from '@capgo/capacitor-screen-orientation';
async function lockLoginScreen() {
await ScreenOrientation.lock({ orientation: 'portrait' });
}
async function unlockForMedia() {
await ScreenOrientation.unlock();
}
async function checkCurrentOrientation() {
const result = await ScreenOrientation.orientation();
console.log(result);
}
パターンは簡単です。制限を適用するには、画面がアクティブになるタイミングで行います。画面がアクティブでなくなったら制限を解除します。ルーターベースのアプリでは、方向の変更をページライフサイクルハックに結びつけることが多く、ランダムなコンポーネントに散らばった呼び出しを散らばすのではなくします。
画面固有の制限を慎重に選択してください。
回転が入力、配置、またはユーザーの焦点を混乱させる場合、固定の直立モードを使用してください。
一般的な例としては次のとおりです。
- 認証画面: 入力が安定していて、ユーザーが入力するときに画面が動かないようにします。
- 決済や確認のステップ: 高注意力タスク中のレイアウトの変更が少ないようにします。
- キオスクまたはガイドドワークフロー: インターフェイスが一貫した表示を必要とする場合に使用します。
デバイスの回転を自由にさせて、タスクに役立つ場合にのみ、追加の幅や異なるグリップが必要な場合に使用してください。
メディアプレイバック、地図、ゲーム、カメラビュー、密集データ画面などの典型的な例があります。
ジュニアチームのための便利なルールは単純です。デバイスの方向を変えることでスペースが変化する場合、レイアウトシステムがそれを処理するようにします。デバイスの方向を変えることでタスクが変化する場合、画面固有のオリエンテーションcodeが正当化される可能性があります。
Capgoはここで実用的な理由で言及されています。 Capacitorプロジェクトでは、画面の向きの制御は小さなUIの詳細から始まり、すぐにアプリの動作に変わります。向きの制御を動作として扱いましょう。デフォルトの柔軟性を維持し、制限を慎重に適用し、画面が制限を必要としなくなったら制限を削除してください。
画面向きのUXベストプラクティス
画面向きの扱いはUXの決定から始まり、技術的な決定が2番目です。 codeは通常は簡単です。難しいのは、自然に感じる動作を選択することです。
短いチェックリストが役立ちます:
- 主な状況に設計しましょう: ほとんどのユーザーが直立で始まる場合、ポートレートの強いバージョンのインターフェイスを使用しましょう。
- より多くの表示モードをサポートすることで、価値が加わる場合: 回転をブロックしないでください。画面が幅が広くなることで価値が加わる場合。
- 明確な理由でロックする場合: フォーム、チェックアウト、またはセキュアフローではロックを許可できます。コンテンツ画面ではロックを許可しません。
- 回転中に状態を保存しましょう: ユーザーは入力、スクロール位置、または選択されたタブを失わないでください。
- 実機で両方のオリエンテーションをテストしてください: シミュレータは不快なトランジション、キーボードの重なり、セーフエリアの問題をミスします。
より広いレイアウトの決定のために クロスプラットフォームのUIとUXのガイドラインはCapacitorアプリに適しています。 レイアウトテストとよく相性が良いのは、同じ画面が異なるデバイスサイズとプラットフォームの慣習に合わせて、ネイティブに感じる必要があるからです。
主なメッセージは簡単です。Portraitオリエンテーションとは何かと尋ねる場合、単に「垂直」ではありません。フレーミングのルール、レイアウトの状態、ユーザーの期待です。良いアプリはそれをそう扱います。
Capgoアプリを配信し、制御されたオリエンテーション動作と迅速なリリース後の修正が必要な場合、Capacitorは見る価値があります。 Capgo コンテキスト: HTMLテキストのフラグメント。親キーはsubmitting_a_pr_to_capgo。ページ/エリア: Capgoのマーケティングウェブサイト。役割: ウェブサイトのコピー。見つかった場所: contributing.astroページ。