モダンなiOSナビゲーションパターン

 (frankrausch.com)
6 ポイント 投稿者 GN⁺ 2023-12-13 | 3件のコメント | WhatsAppで共有
  • iOSアプリのナビゲーションでは、ユーザーが現在位置と戻る経路を理解できるように、階層、オーバーレイ、ビュー内フローを明確に区別する必要がある
  • 構造的パターンは Drill-Down、Flat、Pyramid、Hub-and-Spoke に分かれ、ツリー探索・タブベースの分割・兄弟画面間の移動・ハブへの復帰のように、画面遷移の意味が異なる
  • オーバーレイは注意を引くための仕組みだが、モーダルかどうかと摩擦の度合いによって、背後の画面をどの程度ブロックするかや、ユーザーに求められる行動が変わる
  • 埋め込みナビゲーションは特定のビューやモーダル内に収めるべきで、状態変更や Step-by-Step フローが階層移動のように見えないよう設計する必要がある
  • タブは予測可能であるべきで、Cancel はデータを即座に破棄してはいけず、iOSアプリでは任意移動よりも明確な階層・状態・モーダル境界を保つほうが適している

iOSナビゲーションの3つの軸

  • iOSアプリは通常、複数段階の固定された階層ツリーで構成される
  • 構造的ナビゲーションは、ユーザーがどこから来たのか、階層の中でどこにいるのか、元の位置にどう戻るのかを理解できるよう支援する役割を持つ
  • オーバーレイはどのようなコンテキストの上にも表示でき、別のオーバーレイの上に重ねて表示されることもある
    • モーダルオーバーレイは、ユーザーの操作があるまで消えず、背後のインターフェースをブロックする
    • 非モーダルオーバーレイは、アプリをブロックしない
  • 埋め込みナビゲーションは、iOSの構造的・空間的モデルに合わせて、特定のビューやモーダルオーバーレイの中に含める形が適している

構造的ナビゲーションパターン

  • Drill-Down

    • Drill-Down は、情報のツリー構造を段階的なリストでたどるパターンである
    • アニメーション遷移は、列どうしの水平方向の移動を示唆する
      • 右への移動は、ツリー階層のより深い段階へ入る動作である
      • 左への移動は、上位階層へ戻る動作である
    • Drill-Down ナビゲーションはモデルレス (modeless) な構造なので、保存するかどうかの確認のような問いが階層探索を中断しない
    • Navigation Bar は現在画面のタイトルを表示し、リスト行の Disclosure indicator は、より深い階層に進めることを示す
    • Back ボタンは上位階層へ戻る明確な経路であり、スペースが許すなら一般的な “Back” ではなく親画面のタイトルをラベルに使うほうがよい
    • 画面左端から右へスワイプする操作は、Back ボタンと同じ役割を果たす
    • カスタム実装では、iOS標準のように screen-edge pan gesture で制御される、インタラクティブかつキャンセル可能な遷移を提供すべきである
    • 右から左へ読む言語では、探索方向とコントロール配置が読み方向に合わせてミラーリングされる
    • ツリー構造は、データベースのフィルタリングのために動的に作れる
      • 音楽アプリでは、Artist、Album、Genre のような異なる起点から同じアルバムへ Drill-Down でき、検索インターフェースも併用できる
    • Drill-Down は、macOS Finder スタイルの Miller columns の1画面1カラム版である

  • Flat

    • Flat パターンは、階層をルートレベルで分割し、tab bar で表示する
      • iPad では sidebar で表示できる
    • タブバー項目はアプリの主要機能を中心に選ばれ、ユーザーの期待とアプリに対するメンタルモデルを形成する
    • タブバー項目のうち1つは常に選択されており、アクティブな選択がアプリのメインコンテンツ領域に表示される内容を決める
    • 現在選択されているタブバー項目は、ユーザー操作なしにプログラムで変更されたり、インターフェース上の別のボタンをタップする形で間接的に変更されたりしてはならない
    • タブバーは、モーダルシートで一時的に隠れる場合を除き、アプリの全画面で継続して表示される
    • タブはフィルターとして使われたり、音楽・動画・写真ライブラリのような大規模コンテンツコレクションへの異なる入口として使われたりする
    • 各セクションは独自の下位階層のナビゲーション状態を保持する
    • タブバー項目は予測可能に動作すべきで、シートを表示したりアクションを実行したりしてはならない
    • ハンバーガーメニューは、タブバーとは対照的な、隠されたナビゲーション方式である

  • Pyramid

    • Pyramid パターンは、親画面に戻らずに同じ階層レベルの兄弟ビュー間をすばやく移動できるようにする
    • メディアアプリでは、兄弟ビュー間の移動に水平方向のスワイプジェスチャがよく使われる
    • iOS Mail アプリの Next Message と Previous Message の山括弧ボタンのように、ボタンを使うこともできる
    • iOS Photos アプリは Pyramid パターンの例である
      • 写真をタップして全画面で開き、左右にスワイプして隣接画像を切り替える
    • 小規模なコレクションでは、page control を使って、全項目数と現在項目の兄弟内での位置を視覚化する
    • iOS App Switcher は、アプリ間をすばやく移動する Pyramid パターンを実装しており、Home 画面を経由するより速いナビゲーションを提供する

  • Hub-and-Spoke

    • Hub-and-Spoke パターンは、階層の最上位に相互に関連しない大きなコレクションがある場合に適している
    • 全画面の子ビュー間を切り替えるには、常にまずハブへ戻る
    • iOS の Home 画面は、インストールされたすべてのアプリケーションのコレクションであり、OSにおける信頼できる中立状態として機能する
    • 画面下部の Home indicator は、学びやすく常時利用できる脱出口であり、見慣れた Home 画面インターフェースへ戻れるようにする
    • このパターンはアプリ内部ではほとんど使われない
      • OSレベルでアプリケーション間に存在するような強い分離と同程度の強い分離を、アプリ内部で必要とすることはほとんどないからである

オーバーレイナビゲーション

  • High-Friction Modal

    • High-Friction Modal オーバーレイは、シートや複数アクションを持つアラートダイアログのように、ユーザーが決定を下すまで背後の画面をブロックする
    • メール作成やカレンダーイベント作成では、Done や Send で進むか、Cancel で考え直すかの選択が必要になる
    • Cancel ボタンは、状態やデータを直接破棄してはならない
      • モーダルシートで Cancel をタップしたときは、安全策として追加の確認ダイアログを常に表示すべきである
      • アラートダイアログでの Cancel は、決して破壊的な操作であってはならない
    • モーダルは、メール作成やカレンダーイベント追加のような、特定の独立したタスクを完了することに集中する

  • Low-Friction Modal

    • Low-Friction Modal は、シート、メニュー、ポップオーバーのようにアプリの残り部分をブロックするが、「二者択一」の決定を要求しない
    • 閉じるボタンを押す、あるいはシートを下へスワイプするだけで消せるように、簡単に閉じられるべきである
    • context menu や popover の外側をタップすると消える
    • OK ボタンが1つだけのアラートダイアログは閉じやすいが、低摩擦は無摩擦と同義ではない
    • 単一アクションのアラートは、可能な限り避けるべきである
      • ユーザーフローを妨げ、インラインテキストや非モーダル通知に置き換えられることが多い

  • Non-Modal

    • Non-Modal オーバーレイは、画面の一部を覆うが、背後のインターフェースをブロックしない
    • 非ブロッキング方式なので、摩擦はほとんどないか、まったくない
    • OS通知のように、アプリ外部のトリガーに反応して表示されることがある
    • 自動で消える場合は、最小限の妨げで一目で把握できる周辺情報を提供すべきである
    • 一時的な非モーダルオーバーレイには、任意のインタラクションがある場合もある
      • 通知をタップしたり、消える前に音量インジケーターをスワイプして音量を変えたりできる
    • アプリケーションの残り部分をブロックせず、自動で現れたり消えたりもしないオーバーレイは、palette と呼ばれることがある

埋め込みナビゲーション

  • State Change

    • 1つのビューは複数の状態を持ちうる
    • リストビューは、ナビゲーション階層上の位置が変わったように見えないまま、empty、loading、populated の状態を持てる
    • 状態変更が、実際には階層的でもモーダルでもないことを確認すべきである
    • その場での状態変更では、全画面遷移を避けるべきである
    • 例としては、リストの編集モード、Webブラウザインターフェース、パン操作可能な街路地図、拡大可能な画像が含まれる
    • ビューオプションは、ユーザーの位置を変えずにコンテンツの表示方法だけを変える
      • list view と thumbnail view の切り替えは、同じコンテキストの同じ情報を異なる可視化でトグルするものである

  • Step-by-Step

    • Step-by-Step パターンは、ガイドツアー、設定フロー、オンボーディングチュートリアルのように、一連の画面を線形フローでつなぐ
    • オンラインストアの決済のように、多くのデータ入力が必要な過程でも複数段階が必要になる
    • 順序の中で前後に移動しても階層レベルは変わらず、この点が Drill-Down パターンと異なる
    • Step-by-Step シーケンスは、モーダルオーバーレイ内に収めて表示するほうがよい
      • この文脈での Back ボタンは、階層的な Drill-Down の Back ボタンとは目的が異なる
    • プロセスは通常、Done または Close ボタンで完了し、そのボタンは内包されたモーダルも閉じる
    • 選択したオプションによって、ステップ数や経路が変わることがある
    • Wizard and assistant は、このパターンの別名である
    • Step-by-Step プロセスは退屈に感じられることがある
      • ユーザーが頻繁に行うと想定されるなら、複数ステップを1つのビュー内の異なる状態として統合し、情報密度を高めてコンテキスト切り替えを減らすことを検討できる

  • Content-Driven

    • Content-Driven ナビゲーションは、ハイパーリンクやボタンがユーザーを別のページやビューへ瞬間移動させる方式である
    • ブラウザのWebナビゲーションはこの方式で動作する
    • iOSアプリでは、ハイパーテキストを表示するアプリ、没入型ゲーム、類似の非線形コンテンツを除けば、このパターンは避けたほうがよい
    • アプリでハイパーテキストコンテンツを表示する必要があるなら、戻る・進むコントロールを備えたブラウザインターフェースの中に収めることを検討できる
    • 独立したブラウザインターフェース内での状態変更は、アプリケーション階層で予期せず位置が変わるより理解しやすい
    • アプリ間の移動にはリンクを使える
    • Deep Links は、URL scheme やドメインに関連付けられた Universal Links を使って、あるアプリやWebサイトから別アプリの深い階層へユーザーを移動させる

参考資料

関連記事

3件のコメント

 
GN⁺ 2023-12-13
Hacker Newsのコメント

  • すでに何度も言われていることだが、こうしたパターンをうまく使っていたことが、ApolloがReddit公式アプリよりはるかに優れていた多くの理由の一つだった。
    ナビゲーション、ジェスチャー、動作が一貫していて、こういう概念が難しいわけでもない。ただ守るだけの注意を払えばいいのに、そうしないアプリがあまりにも多くて気が抜ける。

    • 良いアプリになるよう最適化されたアプリと、エンゲージメントと販売に最適化されたアプリの違いだ。
      スーパーが定期的に陳列棚を変えるのに似ている。ナビゲーション、ジェスチャー、動作が一貫していると、ユーザーは欲しいものをあまりに効率よく手に入れて退出できてしまう。
    • 公式Redditアプリほど混乱するアプリは見たことがないし、自分の知能は普通だと思っている。
      3万人規模のサブレディットを運営しているので、スマホでRedditを使える必要があるのだが、ほとんど不可能だ。あらゆる操作に動作が多すぎるし、今どこにいるのか分からず、本当にひどい。
    • Steve HuffmanがApolloを潰す形でRedditを駄目にしたのは、本当に恥ずべきことだ。
      数年前にすでにRedditをやめていたが、この件が最後の釘だった。
    • 公式Redditアプリは、定期的に道に迷う数少ないアプリの一つだ。
      メイン画面に戻るのに精神的エネルギーを使いすぎるので、ただ強制終了して開き直している。
    • Apolloでもサブレディット、ユーザープロフィール、投稿のようなレイヤーを無限に積み重ねて開けたので、混乱することはあった。
      数段階進むだけでも最初の画面に戻るには、そこに到達するまで延々とスワイプするか戻るを押す必要があって、かなり面倒だった。自分の知らない魔法のようなジェスチャーがあるのかもしれない。

  • 「iOSナビゲーションパターン」という言葉を見ると身構えてしまう。パターンなどなく、Androidと比べたときのiOSの最悪な点の一つだ。
    Androidでは戻る操作が簡単で、複数の意味を持つこともできる。1年以上iOSを使っているが、2種類ある戻る「パターン」のどちらかを目をつぶって試してから、手の届かない場所にあるボタンを探すことになる。それでも駄目なときがある。
    パターンを開発者に任せず、OSレベルで直すべきだ。開発者はユーザーにアプリの一部から離れてほしくない。例えばInstagram Reelsで戻る操作をしてみればいい。

    • 「Androidでは戻る操作が簡単で、複数の意味を持つこともできる」という点こそ、自分にとってはAndroidの最悪な点の一つだ。
      戻るボタンが何をするのか、まったく一貫性がない。開発者である自分でさえ、特定の状況で戻るが何をすべきか悩むことがある。前の画面に行くべきなのか、ドリルダウンナビゲーションで一段上に行くべきなのか曖昧で、両者が同じ場合もあるが、常にそうとは限らない。
      ときにはナビゲーション構造の一段上に行き、ときには前の画面に行き、ときにはダイアログを閉じ、さらにはアプリを閉じることもある。文脈次第でどの動作もあり得るし、複数が当てはまる場合はどれなのか不明確だ。知る唯一の方法は押してみて何が起こるかを見ることだけだ。
      曖昧なユーザーインターフェース要素は嫌いだ。何かをクリックするとき、どの動作が実行されるのか分かっていたい。
    • Androidのアクティビティスタック体験は、システム設計の中で最も気に入っている部分だ。
      深い一貫性を生み出していて、ナビゲーションが苦にならない。iOSにも同じやり方で組み込まれていたら本当に良かったと思う。
      アクティビティスタックはアプリをまたいで動作するため、複数のアプリが一緒に一つの作業を処理している場合でも、戻るジェスチャーは常に直前の画面に戻してくれる。
    • iOSの戻るボタンは、なぜあんなにあちこちに散らばっているのか分からない。
      あるときは左上、あるときは左下、あるときは右下にあり、別の場所に置くアプリもあるだろう。
      Androidには片手で使っているときでも常に届くOSの戻るボタンがある。この方式のほうがはるかに優れている。
    • 「パターンを開発者に任せず、OSレベルで直すべきだ」というのは、Appleにとって実質的に不可能だからやらなかったのだと思う。
      例えばビューの内容を変更できるなら、すべての内容を消して完全に新しい内容に置き換えることもできる。ユーザーの何らかの操作でこれが起きるなら、実質的には「新しい画面へ移動」したのと同じだ。しかし開発者が提案されたOS API呼び出しであるcreateNewViewを使わず、現在のビューの内容だけを変えたなら、OSレベルのジェスチャーは動作しない。
      ただしAppleは、審査を通す条件としてこのOS APIの使用を義務化することはできる。それでも何が「戻れる新しいビュー」で、何が「内容だけが変わった既存のビュー」なのかは、ある程度主観的だと思う。
    • 共有メニューが最悪だ。人があれをどうやって理解すればいいのか分からない。
      連絡先、アプリケーション、縦方向の項目、横方向の項目、下部のその他の項目が表示され、しかも上に引き上げる必要があると気づいて初めて見える。アプリごとに位置も違い、アイコンも「共有」や「コピー/貼り付け」とは何の関係もない。
      スマートフォンとともに育った人たちは、いつものように適応できる。導入当時に40〜50歳を超えていなければ、だいたい適応可能だ。現代的なものの大半はひどい設計で、しょっちゅう不安定だ。Apple TVもそうだし、Wi-Fiパスワードを変える話でもしようかという感じだ。バグ回避に必要なのに、なぜオン/オフボタンを押しても再起動しないのか分からない。

  • 関連性が十分あるかは分かりませんが、Mac と現在の iPadOS（[https://useyourloaf.com/blog/ipad-customizable-toolbars/](https://useyourloaf.com/blog/ipad-customizable-toolbars/））では、内蔵のツールバーコントロールが高度なユーザーによるカスタマイズに対応しています。
    Finder をはじめ、複数のネイティブアプリで試すことができます。
    強力な内蔵ウィジェットは Mac デスクトップでは過小評価されている要素であり、SwiftUI が支配的になっていく中で心配している部分でもあります。iOS にとっても大きな利点ですが、アプリが独自のデザインを被せようとすることがあまりに多いため、相対的に目立ちにくくなっています。
    ただ、自分の記憶違いかもしれませんが、昔の iOS アプリはタブバーのカスタマイズを標準でサポートしていなかったでしょうか。ツールバーとは明らかに別物ですが、タブの順序や実際に表示するタブを編集できるようにするのは、内蔵ツールバーのカスタマイズと精神的には同等のものに感じられました。ところが、もう何年も見ていません。
    ドキュメントによると、まだ存在しています。このパターンを今でも使っているアプリを知っている人がいるのか気になります: https://developer.apple.com/documentation/uikit/uitabbarcont...
    いずれにせよ、タブバーは素晴らしいです。私が使った Apple TV アプリの大半が採用している方式で、一貫した体験がとても良いです。

    • 初期の頃は、タブを入れ替えたり、欲しいものだけを入れたり外したりするのがかなり一般的でした。
      Facebook がまだまともだった頃、おそらく iOS 7 あたりでは、チャット、フィード、通知、グループといった項目をこのように変更できた記憶があります。
    • Apple Store や Music など、いくつもの Apple アプリは下部のタブバーを使っていますが、カスタマイズはできません。
      Apple 以外で思い浮かぶアプリは、ずいぶん前にどれも見つけにくいハンバーガーメニューへ移行してしまいました。
    • Mac ではもっと多くのアプリに標準ツールバーを使ってほしいです。
      カスタマイズできる点が良いのに、独自実装ではほとんど見かけません。
    • UITabBar はプログラマーの立場から見ても、カスタマイズが常に苦痛なほど制限されていましたし、ユーザーが直接変更できる点まで気にするプロジェクトはほとんどありませんでした。
      Apple が見た目を強く縛りすぎた結果、結局みんなが別のものに置き換えるようになったのだと思います。
    • Music アプリのような iOS アプリでツールバーを並べ替えられた機能が、今でも恋しいです。
      Apple Music のタブのうち 2 つは文字どおりまったく使っていません。プレイリストやアルバムへすぐ行けるようにできればいいのにと思います。

  • 最初の項目にある「ドリルダウンナビゲーションには状態がない」という表現は、逆に見えます。
    画面 N は以前に何をしたかに依存しており、そこへ戻ることもできるので、非常に状態の多い構造です。有用であるためには、内部状態を実際に追跡する必要があります。たとえばリストの内容は N-1 の状態に依存しますし、そうでなければひどいことになります。
    状態のない UI とは、1 段階のモーダルのようなものです。あるかないかのどちらかです。特に一時的で、「再開」する方法がないなら、より強く状態がないと言えます。
    ここ数年、「状態あり」という言葉をまったく違う意味で使う議論をかなり多く見てきましたし、最近は特に爆発的に増えています。そのため、ほとんど誰もその意味について合意できておらず、その事実を自覚している人も少ない、という結論に近づいています。
    皆さんにとって状態のある UIとは何なのか気になります。その違いが興味深いです。

    • 「状態のある UI」という表現が一般的に曖昧だという点には同意しますが、ナビゲーションの文脈では、通常、階層構造を状態なし、アクティビティスタックを状態ありと呼ぶのを聞きます。
      iOS のような階層構造では、すべての子が正確に 1 つの親を持つ必要があるため、現在のページさえ分かれば「戻る」ボタンが何をするか分かります。そのページにどう到達したかに関係なく、階層内で 1 段上の親ページへ移動します。
      Android のようなアクティビティスタックでは、現在のページだけでは十分ではなく、そのページにどう来たかを知る必要があります。「戻る」ボタンは履歴を戻ることを意味するからです。
      多くの Web サイトは両方をサポートしています。ブラウザの戻るボタンは状態を持ち、個人の履歴をたどりますが、パンくずリストのようなページ内ナビゲーションは通常状態を持たず、そのページに到達した特定の経路には依存しません。もちろん例外もあります。多くの検索インターフェースでは、項目に入ったあとページ内ナビゲーションで戻ると、親ページではなく直前の検索語へ戻るため、状態があると見なせます。
    • 私にとって状態のある UIとは、フロントエンドが自身の動作を管理するために変数を使うことを意味します。

  • ここで 1 つ不正確な表現が見えます。「画面左端から右へスワイプすると、戻るボタンを押すのと同じ」という部分です。
    自分で実装するなら、これはスワイプジェスチャではなくエッジパンジェスチャであるべきです。指に追従し、キャンセル可能なインタラクティブなパンでなければならず、そうでないと感触が狂います。

    • X/Twitter の iOS アプリと Reddit アプリには、この問題があるように思います。
      何かを一生懸命入力しているときに、スマホの端に少し触れただけでコメント全体が消えてしまうことがあまりにもよくあります。
    • 左から右へスワイプして戻るのは、「戻るボタン」を実装するひどい方法であり、絶対にすべきではありません。常に実際の戻るボタンがあるべきです。
      理由は左利きが存在するからです。左手の親指で行うには自然でも快適でもない動きです。左利きのために方向を逆にすることもできません。左から右へ読むなら、右スワイプは戻るではなく進むように見えるからです。
      全体として、スワイプでナビゲーションするのは好きではありません。iOS では特にひどいです。下から上へスワイプすると何らかのメニューが上がってきますが、そこには実際には重要なものが入っているのに、必要なときには見つけられず、Web ページをスクロールしているときにはしょっちゅう誤作動します。
      より一般的に言うと、iOS はナビゲートするのが悪夢のような、ひどく複雑な OS に退化してしまっており、Apple は UI/UX に再び真剣に取り組むべきだと感じます。主な問題は、そもそもスマートフォンに向いていない大量の作業を処理することが期待されている点に見えます。
    • Sailfish OS は、これをすべてのアプリで正しく一貫して処理しています。
      https://sailfishos.org/
      全体として iOS や Android よりもシンプルで優れていると感じます。

  • 視覚的なソフトウェアの面で苦労している人にとって、本当に良い資料です。
    図と明確な説明が素晴らしいです。

  • Frank Rauschは、最高のWikipediaアプリ「V for Wiki」を作った人物です。
    だから彼がiOSデザインとユーザー体験について語るなら、聞く価値があると思います。
    https://web.archive.org/web/20211223231349/https://v-for-wik...

    • それとは別に、V For Wikiにいったい何があったのかは分かりません。
      毎日使っていたのに、ある日突然動かなくなり、App Storeで探してみたら消えていました。本当に残念でした。

  • 「画面左端から右へスワイプすると戻るボタンを押したのと同じになる」という動作をオフにできるといいのですが。
    画面に収まらないWebページでよくある横スクロールをしている最中に、戻る操作が実行されてしまうことが多すぎます。

  • iOSはこの点をかなりうまくやっています。
    典型的なiOSアプリケーションは、複数段階の階層ツリーのような固定アーキテクチャを持っており、この厳格な構造のおかげでナビゲーションの選択肢が予測しやすくなります。構造的なナビゲーションパターンは、ユーザーに、自分がどこから来たのか、階層のどこにいるのか、元いた場所へどう戻ればいいのかについて確信を与えます。
    一方Androidでは、戻るジェスチャーがあるときは前のページに戻り、あるときはアプリを完全に閉じてしまいます。一貫性がなさすぎて、Androidを12年使った末にiOSへ乗り換えました。

    • 最初からそうでした。
      もう我慢できないと決心するまで、実に12年も耐えたというのが驚きです。

  • 初めてiPhone開発を始めた頃、つまり公式SDKが出たばかりの頃、AppleはHuman Interface Guidelinesに非常に厳格で、良いUIを作る要素や従うべき標準パターンについてのドキュメントもとても優れていました。
    ところが「フラット」デザインへ移行してから、それが完全に消えてしまったように思います。主な理由は、もはやそのドキュメントの内容が筋の通ったものではなくなったからだと思います。
    以前は「ユーザーインタラクションが明確に見えるようにせよ」のように非常にはっきりしていましたが、今では「これはクリック可能かもしれないし、単なるテキストかもしれないし、長押しが必要かもしれない」という状態になってしまいました。
 
genkino 2023-12-13

こんにちは！ 私もこの文章を同僚に共有していて気づいたのですが、네비게이션ではなく내비게이션が韓国語の正書法に合った標準語だそうです。笑 英語の発音を写したものなので、実際にはどちらが正しいと断言するのは少し難しいかもしれませんが、多くの方が見る場所ですし、せっかくなら標準語に合わせて書かれているとよいと思い、そっとコメントしてみました。
 
xguru 2023-12-14

この記事は GPT-4 が要約した内容です。GPT は「ナビゲーション」をうまく使っている一方で、時々表記が揺れているようです。修正しておきました（笑）