FE EXAM

フレームワーク(開発の土台となる骨組み)

アプリ開発の土台となる骨組みや共通の仕組みを提供するソフトウェア。

DIAGRAM
フレームワーク(枠組み)
開発者のコード
フレームワーク(決められた枠組み・骨組み)ルーティング・データベース接続・認証などの共通処理をあらかじめ用意開発者が書く部分画面の表示処理// ここに処理を記述開発者が書く部分入力データの検証// ここに処理を記述開発者が書く部分保存するデータ定義// ここに処理を記述制御はフレームワーク側 — 枠組みが開発者のコードを呼び出す(制御の反転)開発者は空欄(決められた箇所)に自分のコードを埋め込むだけ
解説

📌
フレームワークとは

骨組みの空欄に自分のコードを埋めるフレームワーク(骨組み)自分のコード自分のコード自分のコード

フレームワークとは、アプリ開発の基本構造や共通処理をあらかじめ用意した骨組み(土台)のことです。画面の表示の流れ、データベース(=データを保存する仕組み)への接続、ログイン認証といった「どんなアプリでも必要になる処理」が最初から組み込まれています。

開発者は、上の図解のように決められた場所に自分独自の処理を書き込むだけで済みます。土台がすでにあるため、ゼロから作るより圧倒的に速く、品質も安定します。

身近な例で考えると、建売住宅の「設計済みの家の骨組み」に似ています。基礎・柱・配管はすでに用意されていて、住む人は内装や家具という「自分の部分」だけを決めればよい──この骨組みにあたるのがフレームワークです。

📌
ライブラリとの違い(制御の反転)

ライブラリ自分部品自分が呼ぶフレームワークフレームワーク自分のコード枠組みが呼ぶ(制御の反転)

フレームワークとよく似た言葉にライブラリ(=再利用できる部品集)があります。両者の決定的な違いは「どちらが主導権(制御)を握るか」です。
ライブラリ:開発者が必要なときに部品を呼び出す(主導権は開発者側)
フレームワーク:枠組みが開発者のコードを呼び出す(主導権はフレームワーク側)

このように、ふつうは「自分が呼ぶ」はずの主導権が「呼ばれる」側に逆転する仕組みを制御の反転(IoC=Inversion of Control)と呼びます。「あなたから私たちを呼ばないで、私たちがあなたを呼びます」という関係です。

観点ライブラリフレームワーク
使う側開発者が呼び出す枠組みに沿って書く
主導権(制御)開発者側フレームワーク側
呼び出す方向自分 → 部品フレームワーク → 自分のコード
自由度高い決まりに従う
別名部品集制御の反転(IoC)

📌
代表的フレームワーク

言語ごとに定番のフレームワークがあるRailsSpringDjangoReactNext.js

プログラミング言語ごとに、定番のフレームワークが存在します。代表的なものは次のとおりです。
Ruby on Rails:Ruby言語の代表的なWebアプリ用フレームワーク
Spring:Java言語の業務システムで広く使われるフレームワーク
Django:Python言語のWebアプリ用フレームワーク
React:画面(UI)作りに使われるフレームワーク(厳密にはライブラリとも呼ばれる)
Next.js:Reactを土台にWebサイト全体を作るフレームワーク

どれも「よく使う処理は最初から用意し、開発者は中身を書くだけ」という考え方で作られています。適切なフレームワークを選ぶことで、開発のスピードと品質を大きく高められます。

📌
なぜフレームワークが必要なのか

ゼロから作ると…認証の仕組みを書くDB接続を書くルーティングを書く…FW使用で…自分の処理だけ書く共通部分は自動品質・速度アップ

フレームワークがなぜ生まれたのか、というと、どんなアプリでも必ず必要になる処理(ログイン認証・データベース接続・画面の遷移管理)を開発者が毎回ゼロから書くのは非効率で、バグも生みやすいからです。

フレームワークはこれらの共通処理をあらかじめ用意することで、開発者が本当に作りたい部分(自分のアプリ独自の機能)だけに集中できるようにします。
時間の節約:共通処理を書く手間が省ける
品質の安定:多くの人が検証した信頼性の高い仕組みを流用できる
チームでの協力:同じ骨組みを使うのでコードの場所が分かりやすい

身近な例で考えると、組み立てキット付きの家具に似ています。「脚の形を削り出す」ところから始めなくても、パーツと手順書が揃っているから短時間で高品質に仕上がります。毎回同じ作業を繰り返さないのが、フレームワーク誕生の理由です。

📌
フレームワークの利点と注意点

利点開発が速い品質が安定チーム開発しやすい注意点学習コストがある自由度が下がる依存が生まれる

フレームワークには大きな利点がある一方で、知っておきたい注意点もあります。

利点
開発スピードが上がる:共通処理が揃っているので、本来作りたい部分だけに集中できる
品質が安定する:多くの現場で使われ、バグが修正された仕組みを使い回せる
チームで協力しやすい:骨組みが決まっているため、誰がどこに何を書くかが分かりやすい

注意点
最初の学習コストがある:フレームワーク固有のルール・書き方を覚える必要がある
自由度が下がる:枠組みに合わない作り方はしにくい(骨組みの範囲内で動く)
依存(=その仕組みに頼ること)が生まれる:フレームワークが廃れると対応コストがかかる

これらを踏まえ、実際の開発では「プロジェクトの規模・チームの人数・求められる速さ」に合ったフレームワークを選ぶことが大切です。小さなスクリプト1つなら素のコードで十分なこともあります。

📝
練習問題

Q1. フレームワークの説明として最も適切なものはどれか。

Q2. ライブラリとフレームワークの「制御の反転(IoC)」の説明として正しいものはどれか。

Q3. 代表的なフレームワークの組み合わせとして適切なものはどれか。

関連コンテンツ