#6 概要と設計方針

この章はLaravelでお問い合わせフォームを作るための「概要と設計方針」を解説します。

このページでは、これから作成するアプリの「全体像」を把握してもらい、学習の目的地やポイント、開発するアプリの完成形についてイメージを固めていただきます。

初心者の方も安心して取り組めるように段階を追って進めていきますので、ぜひこの記事を読んでから動画に進んでください！

なぜ設計を行うか

Laravelで機能を作り始めると、「とりあえずルートを書いて、コントローラを用意して、Bladeをつなげて…」という流れに乗って、手を動かすこと自体が目的になってしまう瞬間があります。

ですが、本来アプリ開発というのは、【動くコード】を作ることではなく、意味のある機能を設計して、それを実装することが目的です。

お問い合わせフォームのように「ユーザーの入力 → 確認 → 完了」という流れを作る場合、ページ構成・ルーティングの分担・バリデーションの処理位置・データの保持方法など、実装前に考えるべき項目がいくつも存在します。

こうした要素を先に整理しておくことで、次のようなメリットが生まれます。

• コードを書き始める前に“何を作っているのか”が明確になる
• Bladeやコントローラの責務がぶれずに済む
• 状態管理（セッションやフラッシュメッセージ）が意図通りに動く
• 今後の機能追加（ログイン連携やDB保存）にも対応しやすくなる

つまり、設計は“きれいなコードを書くため”ではなく、目的に合った正しい流れを作るための地図づくりなんです。

Laravelは自由度が高いぶん、「書けるけど設計されていないコード」が生まれやすいという側面もあります。

「とりあえずコードを書いてみる」ということも非常に大事ですが、ここは一旦、まずは機能の目的と構成を明確にすることで、Laravelをより実践的に活用できる土台を整えていきましょう。

お問い合わせフォームの仕様設計

全体像

ここで開発の流れを図でイメージしておきましょう。

[トップページ] → [詳細ページ]
         ↘
     [お問い合わせページ]
　　　　　　　↘
           [確認ページ]
                  ↘
               [thanksページ]    

上記のようにページが遷移していきます。

ページの動きとしては、トップページではお問い合わせされた内容を確認することが可能で、詳細ページにアクセスできます。

また、トップページからお問い合わせページへ遷移することが可能で、入力した内容に問題がなければ確認ページ、その後、thanksページへと遷移します。

以下では実際に作成するページをすべて挙げておりますので、一度アプリを作成する前に目を通しておいてください。

ビュー

Laravelにおけるビュー（view）とは、ユーザーに表示される画面の見た目や構成を定義する部分です。

HTMLやCSSといったフロントエンド要素をLaravelのテンプレートエンジンである Blade を使って管理することで、動的で柔軟な画面設計が可能になります。

ビューは“ユーザーが目で見る場所”ですが、それ単体では意味を持ちません。ルートやコントローラとつながることで、「どこにアクセスしたら、どんな画面が出るか」というアプリの動きが成立します。

今回作成するのは、以下の5ページです。

ルーティング

アプリ開発におけるルーティングは、「ユーザーがどこにアクセスしたら、どんな画面が表示されるのか」という導線の制御レイヤーです。

ルートは画面単位で分けることで、責任が明確になります（入力／確認／完了）。

データベースへの保存処理は画面と分離し、POST処理専用のルートで安全かつ管理しやすくなっています。

それを踏まえて、今回のフォームでは、以下の6つのルートが設計されています。

/（トップページ） → 一覧表示

• 表示画面：index
• 役割：管理者側のダッシュボードとして、お問い合わせ履歴の一覧を表示するページ

/show/{id} → 詳細表示

• 表示画面：show
• 役割：一覧から選んだ個別の問い合わせ内容を表示する詳細ページ
• {id} によって、どのレコードを表示するかが動的に決まる

/contact → 入力ページ（ユーザー）

• 表示画面：contact
• 役割：ユーザーが氏名・メール・内容を入力するフォーム画面

/contact/confirm → 確認ページ

• 処理：POST送信後に表示される確認画面
• 役割：入力された内容を表示し、「この内容でよければ送信」という確認を取るステップ
• データはセッションを通じて保持する構成が想定される

/contact/store → 保存処理（非表示）

• 処理：POSTで送信されたデータをDBに保存する処理専用ルート
• 表示は行わず、保存完了後に /thanks へリダイレクトする想定

/thanks → 完了ページ

• 表示画面：thanks
• 役割：送信が完了したことを明示するサンクス画面
• UX的に「処理が終わった」ことを安心して確認できるページ

データベース

Laravelでお問い合わせフォームを構築する際、単なる入力と表示だけでなく、ユーザーが送信した内容を記録として残すために、今回はデータベースに保存する設計を採用します。

フォーム送信を単なる一過性の処理として終わらせず、管理可能な“履歴データ”として永続的に記録することで、機能としての完成度が格段に高まります。

そのため、まずは入力項目とそれに対応する保存先テーブルの構成を設計していきます。

今回使用するテーブル名は contactsテーブルという名前で、フォームから送信されたデータを保存する専用のテーブルです。

テーブル構成と各項目の役割

フォームとバリデーション

お問い合わせフォームでは、ユーザーが「名前」「メールアドレス」「年齢」「性別」「関心のある分野」「お問い合わせ内容」を入力して送信します。

その際、入力ミスや不正な値があった場合には正しく検出し、再入力を促す必要があります。これがバリデーションの役割です。

フォームには次の項目を設けます。それぞれは contacts テーブルと一致しており、保存対象となるデータです。

入力項目とその構成

バリデーション

モデル

Laravelにおけるモデル（Model）は、データベースの1つのテーブルと対応し、データの保存・取得・変換といったロジックを担う役割です。

今回の場合、フォームで送信されたお問い合わせデータは contacts テーブルに保存されるため、それを扱うモデルとして Contactモデル を定義します。

モデルを設計段階で扱うことで、コントローラー側から「何が保存・取得できるか」が明確になり、DB構造とロジックの対応関係が整理されます。

また、バリデーション → 保存 という処理の流れも自然につながり、FormRequestとの連携がスムーズになります。

設計時にモデルの責務を定義しておくことで、今後リレーションや絞り込み条件の追加にも柔軟に対応でき、拡張性の高い構成を維持することができます。

コントローラー

Laravelのコントローラー（Controller）は、ビューやモデルの間をつなぐ“操作の司令塔”です。

ユーザーがページにアクセスしたとき、ボタンを押したときなどの動作に応じて、何を表示するか／何を保存するか／どこへ遷移するか──といった処理を制御します。

今回の設計では、ContactController が以下のような責務に分かれて機能を担います。

主なアクションとその設計意図

まとめ

この章では、お問い合わせフォームを Laravel で構築するにあたって、画面構成（ビュー）・ルーティング・データベース・バリデーション・モデル・コントローラーまで、実装前に必要な設計をひと通り整理しました。

各機能の責任を明確に分離したことで、「どの画面がどんな役割を持ち」「どのURLで動き」「どうデータが保存されるか」の流れが見えるようになり、無駄のない構成と、今後の拡張性を備えた設計基盤が整いました。

次章では、この設計に沿って実装を進めていくための README編 に入ります。具体的なセットアップ手順や、開発環境の前提を整理しながら、いよいよ機能を動かしていく準備を整えていきましょう。

  次章 #7 Read MeとMarkDownに進む