※この記事は以下記事参照し、自己学習用として書きました。参照記事が素晴らしいので、ぜひご覧ください。わたし自身の知識・理解を深めるため、当記事は「中学生でも理解できるレベル」を目指しました。
参照記事
https://zenn.dev/rio_dev/articles/c0da74ae28bdcd
👩💻 フロントエンド（Webサイトの見た目や動き）
JavaScriptのイベントループってなあに？
JavaScriptは、コンピューターの中で仕事をするとき、基本的に一つのことしか同時にできません（これを「シングルスレッド」って言います）。
でも、Webサイトでは「5秒後にメッセージを出す」とか「ボタンが押されるまで待つ」みたいに、すぐに終わらない仕事（「非同期」な仕事）があります。
イベントループは、学校の先生（JavaScript）と生徒（仕事）のやりくりみたいなものです。
- やるべき仕事（関数） は、「コールスタック」 という机の上に次々積まれます。
- 先生（JavaScript）は、机の上の仕事を一つずつ順番に終わらせます。
- もし、「5秒後に実行」といった時間のかかる仕事（
setTimeoutなどのAPI） が来たら、先生はそれをすぐに机から取り上げて、時計係（ブラウザの機能）に渡します。 - 時計係は指定された時間（5秒など）を測り、時間が来たら、その仕事を**「キュー」** という別の場所に並ばせます。
- 先生は、机の上の仕事が全部終わって手が空いたら、「キュー」に並んでいる仕事がないか確認し、あれば一つずつ取り出して実行します。
このように、先生（JavaScript）が手が空いたときを見計らって、キューの仕事を取り出し実行する仕組みをイベントループと呼び、これにより、一つのことしかできないはずなのに、時間のかかる仕事が裏で進んでいても、他の仕事を止めずに進められるんです。
TypeScript（タイプスクリプト）が役立つことって？
JavaScriptはとても自由で便利なのですが、「間違い（エラー）」を見つけるのが苦手です。例えば、文字を入れるべき場所に間違って数字を入れても、実際に動かしてみるまで気づかないことがあります。
TypeScriptは、この問題を解決するために作られました。これは、JavaScriptに**「型（かた）」というルール**を付け足したものです。
-
バグの早期発見 🔍:
TypeScriptは、プログラムを動かす前に、設定した「型」のルールに違反していないかチェックします。例えるなら、プログラムを書き終わった時点で、先生が赤ペンで間違い（コンパイルエラー）を指摘してくれるようなものです。これにより、実際にWebサイトを動かしてみて「あれ、動かない！」となる前に、バグを未然に防げます。 -
開発がスムーズに 🚀:
VSCodeなどの便利なエディタ（コードを書くソフト）と組み合わせると、この「型」の情報のおかげで、「次にどんな命令が書けるか」 を予測して教えてくれたり（型補完）、書き間違いをすぐに警告してくれたりします。これは、辞書と文法チェック機能付きのノートを使っているようなもので、コードを速く、正確に書く手助けをしてくれます。
☆ブラウザレンダリングの仕組み（Webページが表示されるまで）
Webページが画面に表示されるまでには、だいたい4つの大きなステップがあります。例えるなら、料理（Webページ）を作るプロセスに似ています。
1. リソースの読み込み（材料集め）
- 住所を探す: あなたが入力したURLの「住所（ホスト名）」を**「DNS」** という仕組みが、Webサイトのある場所の「電話番号（IPアドレス）」に変換します。
- 通信の準備とデータの受け取り: 接続のルール（TCPなど）を決めて、Webサイトのデータ（HTML、CSS、JavaScript、画像など）をインターネット経由で受け取ります。
- データの整理: 受け取ったデータのうち、HTMLは「DOMツリー」という家の骨組み図に、CSSは「CSSOMツリー」という骨組みへの色や飾りの指示書に、それぞれ整理されます。
2. JavaScriptの実行（隠し味の調理）
- もしWebページに動きをつけるためのJavaScriptがあれば、このステップでコンピューターが理解できる形に翻訳されて実行されます。
3. レイアウトツリー構築（骨組みに飾り付けの指示を合わせる）
- 「DOMツリー（骨組み）」と「CSSOMツリー（飾り付け指示書）」を組み合わせて、「レイアウトツリー」 という最終的な配置図を作ります。
- この配置図には、各要素が画面のどこに、どれくらいの大きさで表示されるか、といった見た目に関する全ての情報が計算されて含まれます。
4. Painting（絵の具を塗って合成する）
- 最後に、レイアウトツリーの情報をもとに、画面のピクセル（小さな点）に色を塗る（ピクセル化）作業をします。
- それらを合成して、私たちが目にする完成したWebページとして画面に表示します。
🌟豆知識：
最初の表示が終わった後でも、ボタンを押したり、JavaScriptのプログラムが動いたりすると、この③と④の工程が繰り返されて画面が更新されます（これを再レンダリングと言います）。
クリティカルレンダリングパスって何？
Webページが最初に画面に表示されるために、絶対に必要な一連のステップのことを指します。
例えるなら、あなたが学校の教室に初めて入る時、「ドアを開けて、中に入って、席に座る」 までの、最初に完了すべき重要な道のりです。
Googleの専門家は、Webサイトがこの道のりを1秒（1000ミリ秒）以内に終えることが、ユーザーにとって快適だと勧めています。
Webパフォーマンスの指標「RAIL」って？
「RAIL」は、Googleが考えたWebサイトの「速さ」を測るための基準です。これは、「人間が Webサイトを使っているときに、どのくらいの速さを快適と感じるか？」 という考え方をもとに作られています。
| RAILのR・A・I・L | 意味（人間が感じる速さの目安） | 望ましい時間 |
|---|---|---|
| Response（応答） | ボタンを押したり、リンクをタップしたりしたとき、サイトが反応を始めるまでの時間。 | 100ミリ秒（0.1秒）未満 |
| Animation（アニメーション） | ページをスクロールしたり、アニメーションが動いたりするとき、カクカクせず滑らかに動くための速さ。 | 16ミリ秒未満 |
| Idle（アイドル処理） | ユーザーが何も操作していない待機中のときに、裏でこっそり行う準備の仕事の速さ。 | 50ミリ秒未満 |
| Load（読み込み） | Webページの全てのコンテンツが表示され、使えるようになるまでの時間。 | 1000ミリ秒（1秒）未満 |
コアウェブバイタルズって何？
これは、「Webサイトの使いやすさ（UX）」 を測るための、Googleの重要な評価基準です。これが優れているサイトは、検索結果で上位に表示されやすくなります。
主に次の3つの指標で評価されます。
-
LCP (Largest Contentful Paint) - 「読み込みの速さ」
- ページの中で一番大きなコンテンツ（画像や動画など） が表示されるまでにかかる時間。
- ユーザーが「ページが開いた」と感じる速さです。
- 2.5秒未満が理想的です。
-
FID (First Input Delay) - 「反応の速さ」
- ユーザーが最初に何か操作（ボタンクリックなど）をしたときから、サイトが実際に反応を始めるまでの遅延時間。
- ユーザーの操作をサイトがどれだけ早く受け付けられるかを見ています。
- 100ミリ秒未満が理想的です。
-
CLS (Cumulative Layout Shift) - 「表示の安定性」
- ページが表示されている途中で、急にレイアウト（配置）がずれてしまう度合いを測定します。
- 例：「ボタンを押そうとしたら、広告が急に読み込まれてボタンの位置がずれた！」というような、イライラする動きがないかを見ています。
- 0.1未満（ほとんどズレがない）が理想的です。
SPA、SSG、SSRの違いって？
これらは、Webサイトのコンテンツ（HTML）をいつ、どこで作るかの違いです。
| 略称 | 正式名称 | いつ、どこでHTMLを作るか | 例えるなら |
|---|---|---|---|
| SPA | Single Page Application | Webブラウザが、必要なデータだけを受け取って画面の一部を更新する。 | メニューを見て、必要な料理だけを注文し、席で盛り付けを直す。 |
| SSR | Server Side Rendering | ユーザーからのリクエストのたびに、Webサーバーが完全に用意したHTMLをブラウザに送る。 | 注文を受けてから、サーバー（料理人）が毎回最初から完成品を作る。 |
| SSG | Static Site Generation | サイトを作り始める時（ビルド時） に、全てのページのHTMLをあらかじめ用意しておく。 | 人気メニューを大量に作り置きしておき、注文が来たらすぐに提供する。 |
CORSって何？なんで設定しなきゃいけないの？
CORS (オリジン間リソース共有) とは？
CORSは、Webサイトのセキュリティルールの一つです。
あなたのWebサイトのデータ（リソース）を、別のWebサイト（「オリジン」が違う、つまり「住所」が違う）から勝手に使われないように制限する仕組みです。
例えるなら、「自分の家にある大切なモノを、許可していない他人に勝手に持ち出されないようにするルール」 のようなものです。
なぜCORSを設定する必要があるの？
Webブラウザには、セキュリティのために**「同一オリジンポリシー」** というルールがあります。これは、「基本的には、同じWebサイトのデータしかやり取りしちゃダメ」というルールです。
しかし、地図や天気予報など、外部のWebサイトのデータ（API）を使いたい場合もありますよね。
CORSは、このセキュリティの壁を、特定の相手に限り、許可を与えるための仕組みです。
設定が必要な理由は、もしこの設定がないと、悪い人が作ったWebサイトから、あなたがログインしている銀行サイトやSNSなどに対して勝手にデータを取り出すリクエストを送られてしまう（攻撃を防ぐ）ためです。CORSを設定することで、「この外部からのリクエストは、公式に許可されたものですよ」とブラウザに教えることができます。
☆セキュリティの観点からフォーム実装で気をつけること
Webサイトの入力フォーム（ログインや問い合わせ）を作るときに、悪い人に悪用されないように気をつける大切なポイントです。
-
入力値のサニタイジング（エスケープ処理）:
ユーザーが入力した文字の中に、プログラムを動かしてしまうような危険な命令（スクリプト） が含まれていないかチェックし、もしあればそれを無害な普通の文字に変換すること。
例えるなら、郵便物を開ける前に、危険なものが入っていないかチェックして無力化する作業です。 -
reCAPTCHA：
フォームの自動送信をプログラム（ボット）が行っていないか確認するために使う仕組みです。「私はロボットではありません」にチェックを入れるアレです。これで、大量のスパム送信などを防ぎます。 -
type="password"：
パスワードの入力欄には、必ず**type="password"** を設定して、入力した文字が見えないように（*や•で表示） すること。これにより、第三者による盗み見を防ぎます。
☆フロントでのパフォーマンスの測定方法/改善手法
Webサイトがどれだけ速く、スムーズに動くかをチェックし、良くしていくための方法です。
測定方法（どこがボトルネックか探す）
Lighthouse や Chrome DevTools（開発者ツール）といった性能チェックツールを使って、Webサイトのどこに時間がかかっているか（ボトルネック） を特定します。例えるなら、健康診断で体の悪いところを探すようなものです。
改善手法（見つけた問題を直す）
見つけた問題に応じて、次のような改善を行います。
-
不要なレンダリングの除去:
画面の更新（レンダリング）はコンピューターの力をたくさん使うので、本当に必要なときだけ更新するように工夫します。 -
キャッシュ活用:
一度読み込んだ画像やデータをブラウザに一時的に保存（キャッシュ） しておき、次からはWebサーバーに取りに行かなくても済むようにします。 -
APIの最適化:
Webサーバーとのデータのやり取り（API）で、必要なデータだけをやり取りするようにしたり、通信回数を減らしたりします。
改善したら、もう一度ツールで測定して、本当に速くなったかを確認します。
☆Webアクセシビリティって何？高める方法は？
Webアクセシビリティとは？
「視覚や聴覚に障がいがある人、高齢で体の機能が低下している人など、どんな人でも、Webサイトの情報にアクセスし、利用できること」を目指す考え方です。
例えるなら、誰でも利用しやすい「バリアフリー」な建物を作るのと同じです。
アクセシビリティを高める方法の例
- ページタイトル: そのページに何が書いてあるかが、タイトルだけで分かるように書く。
- 画像の代替テキスト: 画像が見えない人（目の不自由な人など）のために、画像の内容を説明するテキスト（「代替テキスト」）を準備する。読み上げ機能がこれを読み上げてくれます。
- エラーメッセージ: フォームなどで入力ミスがあった場合、どこが間違っていて、どう直せばいいかをハッキリと分かりやすく伝える。
- リンクの文言: 「ここをクリック」ではなく、「商品の詳細ページへ」 のように、リンク先がすぐに分かる言葉にする。
div要素にonClickをつけないほうがいい理由
divはただの**「領域」** を分けるためのタグで、「ボタン」 ではないため、次のような問題が起こります。
-
キーボード操作ができない:
キーボードのTabキーを使って、その要素にフォーカス（選択） を合わせることができません。これはキーボードだけで操作する人には不便です。 -
Enter/Spaceキーで動かない:
通常のボタンのように、Enterキーやスペースキーを押してもクリックしたのと同じ動作をしてくれません。 -
読み上げ機能が困る:
スクリーンリーダー（画面の情報を読み上げるソフト） が、それが**「ボタン」として認識してくれない**ため、ユーザーに「これは押せるものだ」と適切に伝えることができません。
これらの理由から、「押して何か動作をさせたい」 ときは、button要素を使うのが正しい方法です。
フロントプロジェクトでエラートラッキングを行う方法
Webサイトでエラー（バグ）が起きたときに、それを見つけて、記録して、直すための方法です。
-
Reactでのエラーの捕まえ方：
-
ErrorBoundary：コンポーネントの中で起こった予期せぬエラーを、アプリ全体が止まる前に捕まえるための仕組みです。 -
Suspense：データ取得など時間のかかる処理（非同期処理） でエラーが起きたときに捕まえることができる機能です。
-
-
エラー解析ツールとの連携：
捕まえたエラーをSentryなどのエラー解析・監視の専門ツールに送ります。これにより、「いつ、どこで、どんなエラーが起きたか」 を詳しく記録・分析でき、バグを素早く直すのに役立てます。
仮想DOM（ヴァーチャル・ディーオーエム）って何？何を解決しているの？
Webサイトの表示内容（DOM）を効率よく更新するための技術です。
仮想DOMとは
Reactなどのライブラリは、Webページの実際の表示内容（DOM） を、そっくりそのままメモリ（コンピューター内の一時的な記憶場所）の中に**「木構造の設計図」** として作っておきます。これが仮想DOMです。
何を解決しているか
以前は、Webサイトの見た目を変えたいとき（例：ボタンのテキストを変える）、プログラマーが**「この要素のこの部分を変えなさい」** と、一つ一つ細かく指示（命令的）する必要がありました。
仮想DOMはこれを変えました。
- プログラマーは**「最終的に画面がどうなっていてほしいか」** だけを記述します（宣言的）。
- どこか変更があった場合、新しい「仮想DOM」 を作ります。
- ライブラリが、古い仮想DOMと新しい仮想DOMを比べて、どこが変わったかを自動で見つけ出します（差分検知）。
- そして、変わった部分だけを、実際のWebページの表示（実DOM）に反映させます。
これにより、プログラマーは**「どうやって変えるか」** を気にせず**「何を表示するか」** に集中でき、さらに、画面の更新が最小限に抑えられるため、速く（パフォーマンスを維持） 画面を更新できるようになりました。
リスト表示でkeyを指定する理由と、indexをkeyにしないほうがいい理由
keyを指定する理由
リスト（項目が並んだもの） を表示するときに、それぞれの項目に**「目印」** としてkeyをつけます。
これは、リストの中身が変わったときに、仮想DOMが**「どの項目が新しく増えたのか？」「どの項目が消えたのか？」「どの項目が順番を入れ替えただけなのか？」** を正確に見分けるために必要です。
もしkeyがないと、新しい項目が一つ増えただけでも、仮想DOMはすべての項目を「更新された！」と勘違いしてしまい、不必要な処理が増えて Webサイトの動きが遅くなります（パフォーマンスが悪化します）。
indexをkeyにしないほうがいい理由
リストの**「順番（index）」** をkeyに使うと、リストの途中で項目が追加されたり、削除されたりしたときに問題が起こります。
例：
[A(key:0), B(key:1), C(key:2)]- リストの先頭にDを追加した →
[D(key:0), A(key:1), B(key:2), C(key:3)]
Reactは、key:0の項目が「A」から「D」に**「入れ替わった」** と認識します。でも実際は「D」が**「新しく追加された」** だけです。
このように、「項目が入れ替わった」のか「項目が新しくなった」のかを正確に追えなくなり、プログラムの動きがおかしくなることがあるため、リストの項目自体が持つ**「ユニークで変わらないID」** などをkeyとして使うべきです。
コンポーネント志向であることの解決ポイント
ReactやVueなどが採用している「コンポーネント志向」とは、Webサイトを**「部品（コンポーネント）」** の集まりとして考える作り方です。
- コンポーネント：Webサイトの「ボタン」「ヘッダー」「記事カード」といった、見た目（HTML）と動き（JavaScript）をセットにした独立した部品のことです。
解決する問題
-
変更・修正がしやすい:
部品（コンポーネント）は、他の部品とほとんど関係なく独立しています（疎結合）。そのため、一つの部品を直したり、新しい部品に交換したりしても、他の部分に影響を与えにくいです。例えるなら、ブロック玩具のように、あるブロックを外しても、他のブロックは崩れないので、素早く安全に開発を進められます。 -
再利用性の向上:
一度作った部品は、Webサイトのどこでも何度でも使い回せます。これにより、コードの量も減り、デザインにも統一感が生まれます。 -
チーム開発のしやすさ:
チームのメンバーがそれぞれ別の部品の開発を分担できるので、開発のスピードが上がり、バグが入り込むのを防ぐことにもつながります。
Fluxって何？何を解決しているの？
Fluxは、Webアプリケーションにおける**「データの流れ方」** のルールのことです。
Fluxの仕組み
Fluxでは、データ（状態） は**「Store（お店の倉庫）」** で集中管理されます。そして、データの変更は必ず一方向に流れるように決められています。
- ユーザーが何か操作をする（Action）。
- 「Dispatcher」という交通整理役が、Storeに向けて更新の指示を出す。
- Storeがデータ（状態）を更新する。
- 更新されたデータが、画面（View）に反映される。
解決した問題
従来のアプリでは、データや画面の部品（コンポーネント）同士が複雑に絡み合っていて、どこでデータが変わったのか、その結果、どこに影響が出たのかが、とても分かりにくくなっていました。
Fluxはこの複雑な絡み合いを解消し、「データは必ず一方向に流れる」 というルールを作ったことで、「データの状態管理」がとてもスムーズになりました。一部の部品を修正しても、他の部品に予期せぬ影響が出にくくなり、バグの発見や修正が簡単になりました。
単方向バインディング/双方向バインディングの違い
バインディングとは、「データ（プログラムが持っている情報）」 と**「画面（Webサイトの見た目）」** を結びつけることです。
| 種類 | 特徴 | 画面（View）からデータ（Model）への反映 | 例えるなら |
|---|---|---|---|
| 単方向バインディング (Reactなど) | データ $\rightarrow$ 画面 の一方向の流れ。 | 画面の入力欄などを変更しても、自動ではデータに反映されない。反映させるには、「イベントハンドラ」 という「ボタンが押されたとき」のような特別な指示が必要です。 | テレビ：データ（電波）は画面に映る（一方向）が、画面を触ってもデータは変えられない。 |
| 双方向バインディング (Vueなど) | データ $\rightleftarrows$ 画面 の双方向の流れ。 | 画面の入力欄などを変更すると、自動で、すぐに、データにも反映されます。 | スマホのメモ帳アプリ：画面に入力すると、それがすぐにデータとして保存される。 |
🎨 デザイン
☆デザインの4原則って何？
良いデザインを作るための、とても大切な4つの基本ルールです。
| 原則 | 意味 | 役立つこと（理由） | 例えるなら |
|---|---|---|---|
| 近接 (Proximity) | 関係のある項目同士は、近くに配置してグループにする。 | 情報が整理され、「仲間であること」 が分かりやすくなります。 | グループごとに席を固めると、誰と誰が仲間かすぐに分かる。 |
| 整列 (Alignment) | ページ上の全ての要素を、ある基準線に沿ってきっちりと並べる。 | ページに統一感が生まれ、スッキリと見やすくなります。 | 本の文字が一直線に並んでいると、読みやすくて気持ちがいい。 |
| 反復 (Repetition) | 色、フォント、形などの視覚的な要素を、デザイン全体で繰り返し使う。 | デザイン全体に一体感（統一感） が生まれ、ブランドとして認識されやすくなります。 | シリーズ物の本の表紙が似ていると、「同じ作者だ」とすぐに分かる。 |
| コントラスト (Contrast) | 異なる要素は、はっきりと差をつける（例：大きな文字と小さな文字、濃い色と薄い色）。 | ページに面白みが出て、重要な情報が目立つようになります**。** | 黒板に白チョークで書くと、文字がはっきりして読みやすい。 |
視線誘導の原理と活用の例
視線誘導とは？
ユーザー（見る人）の目の動きを、デザインの力で意図的にコントロールするテクニックです。
- 私たちは、Webサイトやチラシを見るとき、一般的に**「左上から右下」へ**、そして**「上から下」へ**と視線を動かしやすい傾向があります。
活用の例
-
グーテンベルク・ダイヤグラム:
画面を4つのゾーンに分けたとき、人が最も注目するのは**「左上」** のゾーンだという考え方です。
これを利用して、一番伝えたい、重要な情報やメッセージを画面の左上に配置することで、確実にユーザーの視線をそこに誘導します。
☆アトミックデザインって何？
Webサイトのデザインを考えるときのシステム（ルール）の一つです。
例えるなら、化学の「原子」 から**「分子」「細胞」** を作っていくように、デザインの要素を小さな部品から大きな部品へと組み上げていきます。
- アトム（原子）：一番小さな部品（例：ボタン、入力欄、ラベル）。
- 分子（モレキュール）：アトムを組み合わせた部品（例：検索窓とボタンを組み合わせた検索フォーム）。
- 組織（オーガニズム）：分子を組み合わせた、より大きな部品（例：ヘッダー、フッター）。
- テンプレート：組織を配置した、ページの骨組み。
- ページ：テンプレートに実際のコンテンツ（文字や画像）を入れた最終形。
メリット
- 統一感: 小さな部品からルールを決めて作るので、Webサイト全体でデザインにブレがなく、統一感が出ます。
- 再利用: 一度作った部品は、どこでも何度でも使い回せるので、開発の効率が上がります。
💻 バックエンド & データベース
オブジェクトとカプセル化
オブジェクトとは？
「データ（情報）」 と、そのデータを扱うための**「メソッド（動き、機能）」** を一つにまとめたものです。
例えるなら、「リモコン」 です。
- データ: チャンネル番号、音量の数値
- メソッド: チャンネルを変えるボタン、音量を上げるボタン
カプセル化とは？
オブジェクトの中にあるデータや動きの一部を、オブジェクトの外から見えないように（隠して） することです。
-
カプセル化の目的:
外から勝手にデータを書き換えられたり、予期せぬ操作をされたりするのを防ぎ、オブジェクトの安全を守るためです。例えるなら、リモコンの複雑な内部回路を、外側のケースで覆い隠すことです。ユーザーはボタン（メソッド）だけを操作すればよく、内部の仕組みを知る必要はありません。
継承とポリモーフィズムの違い
どちらも、プログラムの**「再利用性」** を高めるための考え方です。
| 用語 | 意味 | 例えるなら |
|---|---|---|
| 継承 | 「親クラス（スーパークラス）」 の持っているデータや機能を、「子クラス（サブクラス）」 にそっくりそのまま受け継がせること。 | 「人間」 という親の特性（話す、歩く）を、「学生」 や**「社会人」** という子が受け継ぐ。 |
| ポリモーフィズム | 同じ命令（メッセージ） を送っても、それを受け取ったもの（インスタンス）の種類によって、それぞれ違った動きをすること。 | 「歩く」 という同じ命令でも、人間は二足歩行で、犬は四足歩行で動く。 |
☆正規化の手順
データベースの「表（テーブル）」のムダをなくし、効率的で、間違いの少ない（整合性の高い） 形に整える作業です。例えるなら、情報を整理して、同じことを何度も書かなくて済むようにすることです。
| 正規化の段階 | 目的 | 例えるなら |
|---|---|---|
| 第一正規化 | 一つのセルに複数の値が入っているような、繰り返し書かれている項目を別の表に分ける。 | 1つのメモ帳に**「今日の予定：1. 買い物、2. 宿題」** と書くのをやめて、「買い物」 と**「宿題」** を別々の行に分ける。 |
| 第二正規化 | 主キー（表の行を特定する鍵）が複数の項目でできている場合、その主キーの一部だけで決まる項目を別の表に分ける。 | 「注文番号と商品番号」 で決まる表で、「注文番号だけ」 で決まる**「お客様の名前」** を別の表に分ける。 |
| 第三正規化 | 主キーではない項目なのに、他の項目を決定してしまっている項目を別の表に分ける。 | 「商品名」 が分かると**「商品の値段」** が決まる場合、このセットを**「商品マスタ」** として別の表に分ける。 |
トランザクションとACID特性
トランザクションとは？
データベースに対する一連の処理（データの追加、更新など） を、「ひとまとまりの作業」 として扱うことです。
例えるなら、銀行のATMでの「お金の引き出し」 です。
- 「口座からお金を減らす」
- 「ATMからお金を出す」
この2つの処理は、どちらも成功するか、どちらも失敗するかのどちらかでなければ困りますよね。もし「減らす」だけ成功して「出す」が失敗したら、お金が消えてしまいます。トランザクションは、この**「ひとまとまり」** を保証します。
トランザクションが成功して、その結果をデータベースに最終的に書き込むことをコミットと言います。
ACID特性
トランザクションが安全で、正しく実行されるために必要な、4つの大切な性質のことです。
| 特性 | 意味 |
|---|---|
| A (原子性) (Atomicity) | ひとまとまりの処理は、全て実行されるか、全く実行されないかのどちらかになる。途中で止まることはない。 |
| C (一貫性) (Consistency) | 処理の結果、データベースがあらかじめ決められた正しい状態（ルール） を常に保つこと（データの矛盾が起こらない）。 |
| I (独立性) (Isolation) | 複数の処理が同時に行われても、お互いに影響を与えず、一つずつ順番に実行したかのように見えること（途中のデータは見えない）。 |
| D (永続性) (Durability) | 処理が成功（コミット） したら、コンピューターが壊れたり電源が落ちたりしても、その変更が永遠に失われないこと。 |
ロールバックとは？
トランザクション（ひとまとまりの処理）を実行している途中で、何か問題（エラー）が発生したときに、その処理を全て取り消して、処理を始める前の状態にデータベースを**「巻き戻す」** ことです。
例えるなら、ゲームで失敗したときに、セーブした時点まで戻るようなものです。
ロールバックが起こると、そのトランザクションで行われたはずの変更は、一切なかったことになり、データベースは何も変わっていません。
デッドロックとは？どう対策する？
デッドロックとは？
複数のトランザクション（処理）が、お互いに**「相手が使っているデータを待つ」** 状態になってしまい、永遠に次の処理へ進めなくなってしまうことです。
例えるなら、細い道で、向かい合った2台の車がお互いに「道を譲れ」と待っていて、どちらも動けなくなる状態です。
デッドロックが起こると、どちらか一方の処理を強制的に終了（ロールバック） させる必要があります。
対策
-
処理時間を短くする:
一つの処理がデータを占有する時間を短くすることで、他の処理が待つ時間を減らします。 -
アクセスする順番を統一する:
処理の中で複数のデータにアクセスする場合、全ての処理が同じ順番でデータを取り扱うようにルールを決めておくことで、お互いに待ち合う状況が起こりにくくなります。
N+1問題とは？
データベースへのアクセス（SQL）の回数が、必要以上に多くなってしまう問題です。
発生する仕組み
- はじめの1回: ユーザー（例：ブログの投稿者）のリストを1回のSQLで取得します。
- N回: その後、「投稿者1人1人の最新の投稿」を取得するために、投稿者の数（N）だけSQLが何度も実行されてしまう。
結果として、「1回 + N回」 もデータベースにアクセスすることになり、Webサイトの表示がとても遅くなってしまいます（パフォーマンスの低下）。
対策
データベースからデータを取ってくるときに、「関連するデータ（最新の投稿など）」も一緒に、まとめて取ってくるようにプログラムを直すことで、アクセス回数を減らします。
インデックスとは？
データベースの検索を速くするための仕組みで、「本の索引（さくいん）」 のようなものです。
仕組み
インデックスには、「探したいデータの内容」 と**「そのデータがデータベースのどこに保存されているかを示す場所（ポインタ）」** がセットで記録されています。
-
インデックスを使う場合:
探したいデータの内容でインデックスを引けば、データの場所がすぐに分かるので、そこへ直行でき、検索がとても速くなります。 -
インデックスがない場合:
データの場所が分からないので、テーブルの最初から最後まで、一つ一つ順番に調べていくしかなく、時間がかかってしまいます。
注意点：インデックスは便利ですが、データが書き換えられるときに、この索引（インデックス）も更新する必要があるため、データ更新の処理自体は少し遅くなるというデメリットもあります。
フロントとバックエンドの両方でバリデーションを行う理由
バリデーションとは、「入力されたデータが正しいかどうかチェックすること」 です。
理由
-
フロントエンド（Webサイトの画面側）でのバリデーション：
- 目的：ユーザーが入力ミスをしたときにすぐに教えてあげるため（使いやすさのため）。
- 問題：悪い人は、Webサイトの入力フォームを使わずに、特別なツール（
curlなどのHTTPクライアント） を使って、不正なデータを直接バックエンドのサーバーに送ることができます。
-
バックエンド（Webサーバー側）でのバリデーション：
- 目的：不正なデータや危険なデータが、データベースに入ったり、プログラムを悪用したりするのを最終的に防ぐため。
- フロントエンドのチェックは簡単にすり抜けられるので、サーバー側でのチェック（バックエンドでのバリデーション）は絶対必要です。
APIのバージョン管理はなぜ必要か？
APIとは、Webサーバーとプログラムの間でデータのやり取りをするための窓口やルールのことです。
必要な理由
Webサイトやアプリが大きくなると、たくさんの人や他のシステムがそのAPIを使います。
もし、あるAPIのルール（仕様）を突然変えてしまうと、それを使っていた他のシステムが動かなくなってしまい、大混乱になります。
-
バージョン管理のメリット:
- 古いAPI（v1）はそのまま動かし続けて、影響が出ないようにします。
- 新しい機能や改善を加えたAPIを新しいバージョン（v2） として公開します。
- APIを使っている人たちに変更内容を伝えて、徐々に古いAPIから新しいAPIへ切り替えてもらうことができます。
これにより、システム全体を止めずに、安全に改善を進めることができます。
🏗️ インフラ & ネットワーク
☆OS（オペレーティングシステム）が担う機能
OSは、コンピューターの頭脳（CPU） や手足（ハードウェア） を管理し、私たちがパソコンを使えるようにしてくれるための、最も重要な基本ソフトです。
OSの主な役割は、コンピューターの資源（リソース）を効率よく管理・配分することです。
-
ハードウェアの管理:
マウス、キーボード、プリンター、画面などのコンピューターの手足（ハードウェア） を動かす。 -
メモリ管理:
作業用のスペース（メモリ） を、今動いている様々なプログラムに公平に分け与える。 -
ファイル管理:
データ（ファイル）をどこに保存し、どう整理するかを決める。 -
タスク（プロセス）管理:
たくさんのプログラム（タスク）を同時に動かしているように見せるために、CPUの利用時間を細かく分けて配分する。 -
入出力の判別:
キーボードからの入力や、画面への出力など、データの流れをコントロールする。
CPU、メモリ、ストレージ
これらはコンピューターを構成する中心的な部品です。例えるなら、人間が仕事をする時の能力や道具に似ています。
| 部品 | 役割 | 例えるなら | 特徴 |
|---|---|---|---|
| CPU (中央処理装置) | 計算や処理を行い、コンピューターの動作の命令を出す「頭脳」。 | 人間が考える「脳」 そのもの。 | 処理が速ければ速いほど、コンピューターの性能が良い。 |
| メモリ (主記憶装置) | CPUが今すぐ必要とするデータを一時的に置いておく「作業机」。 | 机の広さ。机が広ければ、たくさんの資料（データ）を広げて、速く作業できる。 | 電源を切ると、中のデータは消える（揮発性）。 |
| ストレージ (補助記憶装置) | プログラムやデータをずっと保存しておく「倉庫」。 (HDDやSSDなど) | 本棚や倉庫。 | 電源を切ってもデータは消えない（不揮発性）。 |
システムのレスポンスを下げる主要なボトルネック要素
Webサーバーやパソコンが**「遅い」** と感じるとき、その原因となる主な場所（ボトルネック）は次の4つです。
-
CPU使用率:
頭脳（CPU）が処理でパンクしていて、新しい命令をさばけない。 -
メモリ使用率:
作業机（メモリ）が満杯で、新しい作業を始めるスペースがない。 -
ディスクI/O (I/Oは入出力):
倉庫（ストレージ）へのデータの読み書きが追いついていない。 -
TCPコネクション数:
Webサーバーへのアクセス（接続）の数が多すぎて、新しい接続を受け付けられない。
☆Web上のデータ送信の流れとプロトコル（通信ルール）
Web上のフォームでデータを送信し、サーバーからレスポンスが返ってくるまでには、データは4つの階層（層） を通ります。それぞれの層で**「プロトコル（通信ルール）」** が決まっています。
| 層 | プロトコル名 | 担う役割 | 例えるなら |
|---|---|---|---|
| ① アプリケーション層 | HTTP (やHTTPS) | アプリケーションがどんなデータを、どんな手順でやり取りするかを決める。 | 手紙の「内容」や「書き方」 を決める（日本語、英語、など）。 |
| ② トランスポート層 | TCP/UDP | 通信の信頼性（ちゃんと届くか） を決める。 TCPは信頼性重視、UDPは速さ重視。 | 手紙の「送り方」 を決める（書留で確実に送るか、普通郵便で速く送るか）。 |
| ③ インターネット層 | IP | 「どこからどこへ」 データを届けるか、住所（IPアドレス） をもとに決める。 | 手紙の「あて先」 を決める。 |
| ④ ネットワークインターフェース層 | 無線LAN など | 同じネットワーク内で、データをどうやり取りするかを決める。 | 郵便配達員が、同じ町内をどう回るかを決める。 |
☆DockerとVM（仮想マシン）の違いと、Dockerが解決すること
仮想化技術の違い
| 項目 | VM（仮想マシン） | Docker（コンテナ） |
|---|---|---|
| 仕組み | アプリ、ミドルウェア、ゲストOS全体を持つ。 | アプリ、ミドルウェアのみ。OSの一部機能はホスト（物理マシン）に任せる。 |
| 重さ | 重い。OSから作るため、起動に時間がかかり、多くの資源を使う。 | 軽い。OSの一部を共有するため、起動が速く、資源の消費が少ない。 |
| 例えるなら | 家の中に、別の家を丸ごと作る。 | 家の中に、独立した「部屋」を作る。 |
Dockerが解決すること
-
どこでも同じ環境で動かせる 🌍:
一度コンテナ（アプリケーションの実行環境）を作ってしまえば、どのコンピューターでも（WindowsでもMacでもサーバーでも）、全く同じようにすぐに動かすことができます。「自分のPCでは動いたのに、サーバーでは動かない！」 という問題を解決します。 -
資源の節約 💰:
VMのようにOSを丸ごと動かさないので、メモリやCPUをあまり使いません。これにより、少ない資源で多くのアプリケーションを動かすことができ、コストを節約できます。 -
移動が簡単 ✈️:
コンテナのデータ（イメージ）はVMに比べてとても軽いので、コピーや移動、バックアップが簡単で速いです。
Kubernetes（クーバネティス）とは？何を解決するの？
Dockerでアプリを**「コンテナ」** という箱に分けることができましたが、そのコンテナの数が多くなったときに、それらを効率よく管理・運用するためのシステムです。
例えるなら、Dockerが「独立した部屋（コンテナ）」を作るのに対し、Kubernetesは「マンション全体の管理人」 の役割をします。
解決すること
-
多数のコンテナ管理の手間を減らす:
たくさんのコンテナを、自動でサーバーに配置したり、管理したりする手間を減らします。 -
コンテナの自動化:
- スケジューリング: どのサーバーでコンテナを動かすかを自動で決める。
- オートスケーリング: アクセスが増えたら、自動でコンテナの数を増やし、減ったら減らす（負荷分散）。
- 自己修復: コンテナが壊れたら、自動で新しいコンテナを作り直す。
Docker単体では難しかった、大規模なシステムを安定して運用するための問題を解決してくれます。
☆保存場所に着目した、クッキー、セッション、キャッシュの違い
これらはすべて、Web上でのやり取りで**「情報を一時的に保存しておく」** 仕組みですが、どこに保存され、何に使われるかが違います。
| 項目 | 保存場所 | 目的 | 例えるなら |
|---|---|---|---|
| クッキー (Cookie) | Webブラウザ（ユーザー側） | ユーザーの「状態」 を保存する（ログイン状態、カートの中身、サイトの設定など）。 | あなたの「名刺」。Webサイトから「あなたを識別するための情報」を受け取り、持っている。 |
| セッション (Session) | Webサーバー（サイト側） | 一連の関連するやり取り（ログインからログアウトまでなど）を識別・管理する。「セッションID」 という識別子をクッキーに入れてブラウザに送る。 | ホテルの「ルームキー」。キー（ID）はブラウザに持たせ、鍵を開けた先の部屋（データ） をサーバーが管理する。 |
| キャッシュ (Cache) | Webブラウザ または キャッシュサーバー | 一度見たWebサイトのデータ（画像など）を一時的に保存し、次回以降の表示を速くしたり、通信量を減らしたりする。 | 「一時的なメモ」。毎回図書館に取りに行かず、一度読んだ本を机に置いておく。 |
☆HTTPSとHTTPの違い、安全を確保する仕組み
違い
-
HTTP (HyperText Transfer Protocol)：
Webのデータをやり取りする基本的なルールです。データはそのままの形（平文） で送られるため、盗み見される危険があります。 -
HTTPS (HTTP Secure)：
HTTPにSSL/TLSという暗号化技術を加えて、安全性を高めたものです。
HTTPSが安全を確保する3つの仕組み
-
盗聴防止（暗号化通信） 🔒:
サーバーとブラウザの間の通信を**「暗号化」** します。万が一、途中で通信を傍受されても、暗号を解読できなければ内容を知られることはありません。 -
改ざん防止（メッセージダイジェスト） 🛡️:
送るデータから**「ハッシュ値」** という短い値を計算し、データと一緒に送ります。受け取った側も同じ計算をしてハッシュ値を比較し、値が違っていたら「途中でデータが書き換えられた（改ざんされた）」 と判断できます。 -
なりすまし防止（Webサイト運用元の確認） ✅:
Webサーバーに**「SSLサーバー証明書」** という電子証明書を設置します。- これは**「認証局」** という第三者機関によってWebサイトの運営元が本当に正しいかを証明されたものです。
- これにより、ユーザーはアクセスしているWebサイトが本物であることを確認でき、悪い人によるなりすましを防げます。
DMZ（非武装地帯）とは？
企業や組織の内部のネットワーク（大切な情報がある場所） を、外部のネットワーク（インターネット） から守るための**「緩衝地帯（かんしょうちたい）」** のことです。
- ファイアウォールという「壁」を設定することで、外部からの不正なアクセスを防げます。
- しかし、Webサイトの公開やメールのやり取りなど、外部とアクセスする必要があるサーバーもあります。
そこで、ファイアウォールと外部ネットワークの間にDMZセグメントというゾーンを設けます。
- DMZに置くもの: Webサーバー、メールサーバーなど、外部からのアクセスが必要な公開サーバー。
- 役割: 公開サーバーは外部とアクセスできますが、DMZから内部ネットワークへの接続は厳しく制限されています。これにより、もしDMZ内の公開サーバーが攻撃されても、内部のネットワークへの被害が広がらないように防いでいます。
プロキシ、リバースプロキシ、CDN
これらは、Web上でのデータの流れを「中継」 し、効率を上げたり、セキュリティを守ったりする仕組みです。
| 種類 | 意味 | 役割 | 例えるなら |
|---|---|---|---|
| プロキシ (Proxy) | 内部 $\rightarrow$ 外部 への通信を中継する。 | 会社など内部のユーザーのセキュリティ強化、通信の監視、データキャッシュなど。 | 学校の先生が生徒（内部）のインターネット利用を監視・管理する。 |
| リバースプロキシ (Reverse Proxy) | 外部 $\rightarrow$ 内部 への通信を中継する。 | 外部からのアクセスを複数のWebサーバーに分散（負荷分散） させたり、キャッシュを保持したりする。 | 会社の受付が、外部からの訪問者を空いている担当者（サーバー） へ案内する。 |
| CDN (Content Delivery Network) | 世界中に配置されたキャッシュサーバーのネットワーク。 | ユーザーに最も近い場所にあるサーバーからデータ（画像など）を配信することで、Webサイトの表示を高速化する。 | 世界中のコンビニに商品を置いておき、一番近い店舗からすぐに提供する。 |
ロードバランサーとは？CDNとの比較でのCDNの優位点
ロードバランサー（負荷分散装置）とは？
アクセスが集中したときに、そのアクセスを複数の Webサーバーに「振り分ける（分散する）」 装置です。
-
主な役割:
- 負荷分散: 一つのサーバーに負荷が集中するのを防ぐ。
- ヘルスチェック: サーバーが故障していないかを常にチェックし、故障したサーバーにはアクセスを振り分けないようにする。
負荷分散の観点でのCDNの優れている点
Webサイトの高速化という点で、ロードバランサーもCDNも役立ちますが、CDNには次のようなメリットがあります。
-
回線容量（トラフィック）のボトルネック:
ロードバランサーは、その装置自体がトラフィックの上限になってしまい、回線不足で遅くなる可能性があります。しかし、CDNはたくさんのキャッシュサーバーでできており、それぞれが複数の太い回線につながっているので、回線不足になりにくいです。 -
障害への対応:
ロードバランサー自体が故障すると、その配下の全てのサーバーにアクセスできなくなります（ロードバランサー自体をもう一つ用意する手間がかかる）。一方、CDNは、故障したキャッシュサーバーを自動で切り離す機能を持っています。 -
ファイル配置の手間:
ロードバランサーでサーバーを複数並べる場合、全てのサーバーに同じデータを配置する必要がありますが、CDNは元のサーバー（オリジンサーバー）のファイルを使って、世界中のキャッシュサーバーが負荷分散を実現します。
スケーラビリティとは？
「拡張性（かくちょうせい）」 や**「拡大可能性」** を意味する言葉です。
- システムの利用者が増えたり、扱うデータ量が大きくなったりしたときに、どれだけ柔軟に、手間なく、システムの性能や機能を追加・向上させられるかを示す言葉です。
例えるなら、「急に生徒が増えたとき、どれだけ簡単に教室を増やしたり、学校の施設を大きくしたりできるか」 という能力です。
DNSが名前解決を行う仕組み
DNS (Domain Name System) は、Webサイトの**「名前（URLに含まれるドメイン名）」** を、コンピューターが通信に使う**「住所（IPアドレス）」** に変換する仕組みです。これを**「名前解決」** と呼びます。
-
要求: ユーザーがブラウザに「
example.com」とURLを入力すると、ブラウザはDNSサーバーに**「example.comの住所を教えて！」** と要求します。 -
解決: DNSサーバーは、様々なサーバーと連携して**「
example.comのIPアドレスは192.0.2.1ですよ」** という情報を探して、ブラウザに返します。 - アクセス: ブラウザは受け取ったIPアドレスをもとに、目的のWebサーバーへアクセスして、Webサイトを表示します。
BFF（Backends For Frontends）とは？解決する問題
BFFとは？
クライアント（Webサイトやスマホアプリ） と、バックエンド（Webサーバー） の間に挟んで作る、クライアント専用のサーバーのことです。
解決する問題
-
クライアント側の通信量が増える問題:
Webサービスが複雑になると、一つのWebサイトを表示するために、バックエンドにある複数のサービス（API）にアクセスしなければならないことがあります。- BFFがないと、クライアントが全てのAPIにバラバラにアクセスし、通信量が増えます。
- BFFがあると、クライアントはBFFだけにアクセスすればOK。BFFが裏で複数のサービスからデータを集めて、クライアントが必要な形にまとめて返してくれるので、通信量を減らせます。
-
開発負担の増加:
APIの仕様が変わったとき、BFFがないとWebサイト、スマホアプリなど全てのクライアント側で修正が必要になります。- BFFがあると、BFFがクライアントとバックエンドの間に入ってくれるので、バックエンドのAPIが変わっても、BFFだけを修正すれば済むことが多くなり、クライアント側の開発負担を減らせます。
☆マイクロサービスとは？メリットは？
マイクロサービスとは？
アプリケーションを、それぞれが独立した小さなサービス（部品） の集まりとして作る開発のやり方（アーキテクト）です。
- 従来のモノリシック（一つの大きな塊） な作り方とは反対で、各サービスはお互いにあまり依存せず（疎結合） に、自分だけの役割（例：ユーザー管理サービス、注文処理サービス）を持ちます。
メリット
-
更新が簡単:
小さなサービス（部品）だけを直せばいいので、アプリケーション全体を止めたり、影響を与えたりすることなく、新機能の追加や修正が簡単にできます。 -
技術の自由度:
それぞれのサービスが独立しているので、最適なプログラミング言語やデータベースを、サービスごとに自由に選んで使うことができます。 -
スケーリングの効率化:
特定のサービス（例：注文処理）にだけ負荷が集中した場合、そのサービスだけを増やせばOKです。モノリシックのようにアプリ全体を増やさなくても済むため、コストやリソースの無駄が減ります。
インフラをコード化するメリット
インフラ（サーバーやネットワークなどの土台） の設定や構築を、手作業ではなく「コード（プログラム）」として記述し、自動で実行するようにすることです。
-
工数削減と自動化:
サーバー構築などの作業を自動でやってくれるので、手作業の時間が大幅に減ります。 -
間違いの予防:
手作業での設定ミスや、人による違い（属人化）を防ぎ、常に決まった正しい状態のインフラを作ることができます。 -
効率化と再利用:
一度書いたコードは何度でも再利用できるので、新しい環境を素早く、効率よく作ることができます。 -
履歴の管理:
コードとして管理することで、いつ、誰が、インフラの設定をどう変えたかを、プログラムの変更履歴（Gitなど）で簡単に追うことができます。
☁️ クラウドに関する内容（AWS）
[AWS] ☆IAM（アイアム）とは？最小権限の原則って何？
IAM（Identity and Access Management）とは？
AWS（アマゾン・ウェブ・サービス） というクラウドサービスにおける、「誰が」AWSにアクセスできるか（認証）、そして**「何が」できるか（認可）** を制御・管理するサービスです。
- 認証: AWSにログインするユーザーが「正しい本人かどうか」を確認する。
- 認可: ログインしたユーザーが、AWSのどの機能（サーバーを立てる、データを見るなど）を操作しても良いかを管理する。
最小権限の原則とは？
「AWSを利用する全てのユーザーやプログラムに対して、仕事をするために必要な、最低限の権限だけを与えるべき」というセキュリティ上のとても重要な考え方です。
-
目的:
もし開発者のパソコンや、アプリケーションを動かしているサーバーが悪い人に乗っ取られてしまったとしても、そのアカウントが最小限の権限しか持っていなければ、被害の拡大を最小限に食い止めることができます。「やりたいこと以外は、絶対に許可しない」 という考え方です。
[AWS] S3とCloudFrontの機能、組み合わせて使う利点
| サービス名 | 機能（役割） | 例えるなら |
|---|---|---|
| S3 (Simple Storage Service) | 静的なファイル（HTML、画像、動画など） をウェブサイトとして公開したり、安全に保存したりできるサービス。 | 巨大で丈夫な「倉庫」。 |
| CloudFront | CDN（コンテンツ・デリバリー・ネットワーク）。S3にあるデータを世界中のキャッシュサーバーに置いて、ユーザーに最も近い場所から高速で配信する。 | 世界中に展開する「配送ネットワーク」。 |
組み合わせて使う利点
-
表示速度の高速化:
CloudFrontがユーザーの近くからデータを配信するので、Webサイトの表示がとても速くなります。 -
独自ドメインでのHTTPS（SSL/TLS）対応:
S3単体では、自分の好きなURL（独自ドメイン） で安全な通信（HTTPS） を行うことが難しいです。しかし、CloudFrontを通すことで、安全な証明書を設定でき、独自ドメインでもHTTPSでの公開が可能になります。 -
コスト削減:
CloudFrontがデータをキャッシュして代わりに配信してくれるので、S3へのアクセス回数が減り、通信にかかるコストを削減できます。
[AWS] LambdaとFargateの比較とユースケース
どちらもサーバーの管理（OSの管理など）をしなくてもプログラムを動かせるクラウドサービスです。
| サービス名 | 特徴 | 料金の発生タイミング | ユースケース（使いどころ） |
|---|---|---|---|
| Lambda | プログラムコードだけをアップロードして実行する（サーバーレス）。 | プログラムが実行された「時間」と「回数」 のみ。使っていないときは料金がかからない。 | 短時間で終わる処理、例えば、Webサイトの画像アップロード後のリサイズ、毎日決まった時間に動くバッチ処理など。 |
| Fargate | コンテナ（Docker） を動かすためのサービス。 | コンテナが「起動している時間」 に応じて料金が発生する。 | 長時間動かし続ける必要のあるWebサーバー、たくさんのアクセスに耐える必要があるサービスなど。 |
- コスト重視で短時間処理なら $\rightarrow$ Lambda
- 安定稼働が必要なWebサービスなら $\rightarrow$ Fargate
🔐 セキュリティ
☆情報セキュリティの3要素
情報を守るために、特に重要とされる3つの基本的な柱です。C・I・A と覚えることがあります。
| 要素 | 意味 | 例えるなら |
|---|---|---|
| 1. 機密性 (Confidentiality) | 許可された人だけが情報にアクセスでき、それ以外の人は見られないようにすること。 | 鍵のかかった金庫に大切な書類を入れておく。 |
| 2. 完全性 (Integrity) | 情報が、改ざんされたり、間違って書き換えられたりせず、正確で正しい状態に保たれていること。 | 原本の書類に、改ざん防止の印鑑を押しておく。 |
| 3. 可用性 (Availability) | 許可された人が、必要なときにいつでも情報やシステムを利用できる状態にあること。 | 金庫の鍵をいつでも開けられて、書類を取り出せる状態にしておく。 |
情報セキュリティ3要素の他に、加えられることのある4要素
セキュリティの考え方が広がる中で、上記の3要素に加えて重要視されるようになった要素です。
-
真正性：
情報やアクセスしている相手が、「本物である」 と確認できること（なりすましではない）。 -
信頼性：
システムが意図した通りに正しく動くこと。 -
責任追求性：
「いつ、誰が、何をしたか」 を後から追跡できること。 -
否認防止：
「私がやったことではない」 と、後から行動を否定できないように証拠を残すこと。
アプリの脆弱性を突く攻撃手法と対策（3つ）
Webアプリケーションの**「弱点（脆弱性）」** を突いて、悪いことをする代表的な攻撃とその対策です。
| 攻撃手法 | 内容 | 対策 | 例えるなら |
|---|---|---|---|
| 1. SQLインジェクション | Webサイトの入力欄に、悪意のあるデータベース操作の命令（SQL文） を入れて、情報を盗み出したり、データを改ざんしたりする。 | 特殊文字を無害な文字に変換（エスケープ） する。WAF（Web Application Firewall）を導入する。 | 鍵穴に針金を入れて、鍵を開けようとするのを防ぐ。 |
| 2. XSS (クロスサイトスクリプティング) | 脆弱なWebサイトに悪意のあるプログラム（スクリプト） を埋め込み、そのサイトを見たユーザーのブラウザで実行させて、ユーザーの情報を盗む。 | 特殊文字を無害な文字に変換（エスケープ） する。WAFを使用する。 | 落書きに見せかけて、裏に毒（悪意のプログラム）を仕込むのを防ぐ。 |
| 3. CSRF (クロスサイトリクエストフォージェリ) | ユーザーが悪意のあるサイトを見たときに、そのユーザーが意図しないリクエスト（例：掲示板への勝手な書き込み、パスワード変更など）を、別の本物のサイトに送らせる。 | 入力フォームに「トークン」という秘密の合言葉を埋め込み、正しいリクエストかどうかをチェックする。WAFの導入。 | 知らないうちに、あなたの名前で勝手に宅配便の注文をさせるのを防ぐ。 |
パスワードクラックとその対策
パスワードクラックとは？
「パスワードを割り出して、不正にログインしようとすること」 です。
対策
-
パスワードの試行回数を制限:
ログインを何回か失敗したら、しばらくログインをできなくする。 -
パスワードの使い回しをしない:
もし一つのサイトからパスワードが漏れても、他のサイトでは使われないようにする。 -
長く複雑なパスワード:
文字数が多い、大文字・小文字・数字・記号が混ざったパスワードにして、特定を難しくする。
Dos攻撃（ドスこうげき）とその対策
Dos攻撃とは？
特定のサーバーに対して、大量のアクセスやリクエストを一斉に送りつけることで、サーバーをパンクさせ、サービスを停止させる攻撃です。
例えるなら、小さなお店に大量の人が押し寄せて、お店の営業を邪魔するようなものです。
対策
-
IDS (不正侵入検知システム)：
不正な通信を検知して、管理者に通報するシステムを導入する。 -
IPS (不正侵入防御システム)：
不正な通信を検知するだけでなく、実際にその通信を遮断して防御するシステムを導入する。
セッションハイジャックとその対策
セッションハイジャックとは？
セッションID（Webサーバーとブラウザ間のやり取りを識別するID）を、盗み見たり、推測したりして、他人のセッション（ログイン状態）を乗っ取ってしまう攻撃です。
例えるなら、他人のホテルのルームキー（セッションID）を盗んで、その人の部屋（ログイン中の状態）に入り込むことです。
対策
-
URLにIDを含めない:
URLにセッションIDを含めると、人に見られたり、履歴に残ったりする危険があるので避ける。 -
セッション管理をプラットフォームに任せる:
自分で複雑な管理をするより、安全なセッション管理機能を持つWebフレームワークやクラウドサービスを使う。
IPS/IDS/WAF/ファイアウォールの違い
これらは全て、不正なアクセスからシステムを守る「壁」 ですが、「どこを見て、何を防御するか」 が違います。
| 種類 | 役割 | どこを見て防御するか | 例えるなら |
|---|---|---|---|
| ファイアウォール | 外部からの不正なアクセスを遮断する。 | 通信の**「ヘッダー」** の情報（IPアドレスやポート番号）。 | 家の「門番」。誰が来たか（IP）と、どのドア（ポート）から入ろうとしているかを見る。 |
| IDS (侵入検知) | 不正な通信を検知し、管理者に通報する。 | 通信の**「中身（パケット）」**。 | 「警報機」。泥棒が入ろうとしたのを察知し、ベルを鳴らす。 |
| IPS (侵入防御) | IDSと同じく検知し、さらに不正な通信を自動で遮断する。 | 通信の**「中身（パケット）」**。 | 「警備員」。泥棒を見つけたら、すぐに捕まえて追い出す。 |
| WAF (Web Application Firewall) | Webアプリケーションの弱点（脆弱性） を狙った攻撃から守る。 | HTTPリクエストの「データの内容」。SQLインジェクションやXSSなどを防ぐ。 | 「セキュリティー専門の警備員」。特にWebサイトのフォームに入ってくるデータなどを見て、特定の攻撃パターンを防ぐ。 |
☆エンジニアが使用する開発PCでのセキュリティ対策
開発に使うパソコンは、大切な情報やシステムの鍵（認証情報）が入っているので、特にしっかり守る必要があります。
-
ディスク暗号化の有効化:
パソコンのハードディスク全体を暗号化しておき、万が一パソコンが盗まれても、データが読み出されないようにする（例：BitLocker、FileVault）。 -
エンドポイントセキュリティソフトの導入:
ウイルス対策や不正なプログラムの実行を防ぐためのソフトを入れておく。 -
スクリーンロック設定:
席を離れるときは、すぐに画面にロックがかかるように設定する。 -
二段階認証の設定:
SlackやGitHub、AWSなどの重要なクラウドサービス全てで、IDとパスワードだけでなく、スマホなどを使った二段階認証を設定する。
☆VPN（仮想プライベートネットワーク）とは？仕組みは？
VPNとは？
インターネット（公衆回線）を利用して、仮想的に「自分たちだけの専用回線」を作り、安全な通信を行うための技術です。
例えるなら、大勢が使う公道（インターネット）の上に、自分たちだけの「秘密の地下トンネル」を作るようなものです。
仕組み
-
仮想的な通信経路の構築（トンネリング）:
インターネット回線上に、拠点と拠点をつなぐ「仮想的な通信経路（トンネル）」 を作ります。 -
データのカプセル化と暗号化:
- このトンネルを通るデータは、そのままではなくL2TPなどの通信プロトコルで**「カプセル」** のように包まれます（カプセル化）。
- さらに、IPsecなどの技術を使って、そのデータ全体が**「暗号化」** されます。
-
安全な通信:
データが暗号化されているため、途中で第三者に傍受されても内容を知られることなく、安全にやり取りができます。
BASIC認証とは？その仕組み
Webサイトへのアクセスを簡単に行うための認証方法の一つです。
仕組み
- ユーザーが、BASIC認証で制限されたWebサイトにアクセスしようとします。
- Webサーバーは、「あなたは認証されていませんよ」 というエラー（HTTP 401）を返します。
- ブラウザは、このエラーを受け取ると、ユーザーIDとパスワードの入力画面を自動で表示します。
- ユーザーが入力すると、ブラウザはIDとパスワードを**「エンコード（簡単に元に戻せる変換）」** して、Webサーバーに送ります。
- サーバーは受け取った情報と、あらかじめ保存された正しい情報とを照合し、合っていればアクセスを許可します。
注意点：BASIC認証は、パスワードを暗号化せずに送るため、セキュリティは非常に簡易的です。本格的なセキュリティが必要なサイトには向きません。
🧪 テスト
テスト戦略（工数のベストプラクティス）
アプリケーションのテストにどれだけの時間や労力（工数）をかけるべきか、その配分を決めるための考え方です。
-
テストピラミッド:
テストの工数を**「単体テスト」** に最も多くかけ、次に**「統合テスト」、最後に「総合テスト」** の順に少なくしていくのが理想という考え方です。- 理由: 単体テストは、バグを初期段階で安く見つけられるため、土台を強固にすべきという考え。
-
テスティングトロフィー:
単体テストだけでなく、「統合テスト」 にも力を入れて、アプリケーションの異なる部分が連携する場所のテストを重点的に行うべきという考え方です。- 理由: 実際のバグは、部品が単体で壊れているよりも、部品同士の連携ミスで起こることが多いため。
主要なシステムテストの手法
システムが正しく動くか、使えるかを様々な観点からチェックする方法です。
1. 確認テスト
-
リグレッション（回帰）テスト:
コードを修正したり、新機能を追加したりした後でも、今まで問題なく使えていた「古い機能」が壊れていないかを確認するテスト。壊れている状態を**「デグレ」** と呼びます。
2. 評価テスト
-
セキュリティテスト:
不正アクセスや情報漏えいにつながるシステムの弱点がないかをチェックする。 -
ユーザビリティテスト:
ユーザーの視点に立って、「使いやすいか、分かりやすいか」 を検証する。 -
障害許容性テスト:
システムの一部が故障したり、エラーが起きたりしても、最低限の機能は動き続けられるかを検証する。
3. 負荷テスト
-
性能テスト:
決められた時間内に処理を終わらせる能力（処理能力） があるかを確認する。 -
ロードテスト:
通常時や、少し負荷が高いときを想定して、システムが安定して動くかを検証する。 -
ストレステスト:
想定をはるかに超える大量の負荷をかけて、システムがどこまで耐えられるかを試す（限界を探る）。
🛠️ メソドロジー（開発のやり方）
☆基本設計の流れ
アプリケーションを作る前の、「大枠の設計図」 を決める重要な工程です。
1. プロジェクト全体の設計
プロジェクトの土台となる部分を決めます。
-
プラットフォーム設計:
どのインフラ（AWS、オンプレミスなど）で動かすか、OSやミドルウェアなどを決める。 -
アプリケーション・アーキテクト設計:
アプリ全体の構造（マイクロサービスかモノリシックかなど）や、部品（コンポーネント）の分け方など、アプリの骨格を決める。 -
開発方式・テスト方式設計:
どんな技術（プログラミング言語、フレームワーク） を使うか、テストをどう進めるかを決める。
2. 機能要件の設計
「アプリが何をするべきか」 という、ユーザーから見た機能に関する設計です。
-
ビジネスロジック設計:
データがどのように処理されるかという、アプリの**「頭脳」** となる部分の設計。 -
データベース設計:
どんなデータを、どんな構造（テーブル）で保存するかを決める。 -
画面設計:
WebサイトやアプリのUI（見た目や操作） を設計する。
3. 非機能要件の設計
「アプリがどうあるべきか」 という、機能以外でシステムの品質に関する設計です。
-
性能・拡張性設計:
どれくらいの速さで動くか、将来どれくらい規模を大きくできるかを設計する。 -
セキュリティ設計:
どうやってシステムを守るか（認証、暗号化など）を設計する。 -
運用・保守性設計:
システムが故障したときの対応や、日々の管理をどうするかを設計する。
非機能要件とは？主要な項目
非機能要件とは、アプリケーションが**「持っているべき機能」** ではなく、「システムの使いやすさや品質」 に関わる要件のことです。JUAS（日本情報システム・ユーザ協会） の定義などがよく使われます。
| 非機能要件の項目 | 意味 |
|---|---|
| 可用性 | システムがいつでも使える状態にあること（故障で止まる時間が少ない）。 |
| 性能・拡張性 | 処理速度が速く、大量のアクセスにも耐えられ、将来システムを大きくできること。 |
| 運用・保守性 | システムの管理やメンテナンスがしやすいこと、故障したときに直しやすいこと。 |
| セキュリティ | 情報漏えいや不正アクセスを防ぐための対策が十分に取られていること。 |
| 移行性 | 新しいシステムへスムーズにデータを移せること。 |
| システム環境・エコロジー | システムを動かすための場所や電力に関する要件。 |
ビルドとコンパイルの違い
これらは、人間が書いたプログラムをコンピューターが動かせる形にするための作業です。
-
コンパイル (Compile)：
プログラムのコードを、コンピューターが直接理解できる**「低水準なコード（機械語に近いもの）」** へと翻訳（変換）すること。 -
ビルド (Build)：
コンパイルを含めた、「プログラムを完成させて、実行できるファイルにするための一連の作業全体」 を指します。- コードをチェック（静的解析）。
- コードを翻訳（コンパイル）。
- 必要な部品を全て集めて一つの実行ファイルにまとめる。
例えるなら、コンパイルは「翻訳」 で、ビルドは「翻訳、印刷、製本まで全てをやる」 ことです。
静的型付け言語と動的型付け言語の違い
プログラミング言語が**「変数の型（かた）」** をいつ決めるか、の違いです。
| 種類 | 型を決めるタイミング | メリット | デメリット |
|---|---|---|---|
| 静的型付け言語 (Java、Go、TypeScriptなど) | プログラムを実行する前の「コンパイル時」に型が決まる。 | エラーをすぐに発見でき、バグが少ないプログラムを作りやすい。 | 記述するルールが多く、コード量が少し増える。 |
| 動的型付け言語 (Python、JavaScript、Rubyなど) | プログラムを実行している最中に型が決まる。 | コードを短く、簡単に書け、素早く開発できる。 | 実際に動かしてみるまで、型に関するエラーに気づきにくい。 |
☆同期処理と非同期処理の違い
複数の**「タスク（仕事）」** を、どういう順番で実行するかの違いです。
| 処理方式 | 特徴 | 例えるなら |
|---|---|---|
| 同期処理 (Synchronous) | 複数のタスクを、一つずつ順番に実行していく方式。前のタスクが終わるまで、次のタスクは「待つ」。 | ラーメン屋の行列。前の人が注文を終えて受け取るまで、次の人は待たなければならない。 |
| 非同期処理 (Asynchronous) | 時間のかかるタスク（例：データ取得）を始めたら、そのタスクが終わるのを待たずに、次のタスクを先に実行する方式。 | レストランのウェイター。料理（時間のかかるタスク）の注文を受けたら、待たずに次の客の注文を取りに行く。料理ができたら、後から運んでくる。 |
☆git mergeとgit rebaseはどう違うか？
Git（プログラムの変更履歴を管理するツール）で、異なる開発の線（ブランチ）を一つにまとめる方法の違いです。
| 方法 | 履歴の変化 | メリット | デメリット |
|---|---|---|---|
| git merge | 2つのブランチの履歴をそのまま残し、「マージコミット」 という新しい合体コミットを作る。 | いつ、どこで、何を合体させたかの履歴が明確に残る。 | 合体コミットが増えて、履歴が複雑になりやすい（枝分かれが多くなる）。 |
| git rebase | 自分のブランチの変更を、相手のブランチの最新の状態の上に「付け直す」。マージコミットは作らない。 | 変更履歴が一本の線のようにスッキリと整理され、見やすくなる。 | 履歴が一本になるので、「元々は別のブランチだった」という事実が分かりにくくなる。 |
git-flowでの開発フロー
チームでの開発を整理して進めるための、Gitのブランチ（開発の線）の使い方のルールです。
-
mainブランチ:
常に本番環境で動いている、公開中の、安定したコードを置いておく。 -
developブランチ:
開発の中心となるブランチ。次にリリースしたい機能をまとめる場所。 -
featureブランチ:
新しい機能一つ一つを作るために、developから切り出す（作られる）。機能ができたらdevelopに戻す。 -
releaseブランチ:
developブランチから切り出し、リリース前の最終チェックやバグ修正を行うためのブランチ。チェックが終わったらmainとdevelopに合体（マージ）させる。 -
hotfixブランチ:
本番環境（main）で緊急のバグが見つかったときに、mainから切り出して緊急で修正を行うためのブランチ。修正が終わったらmainとdevelopに合体させる。
このルールにより、それぞれのブランチの役割がハッキリするため、混乱せずに開発を進められます。
☆密結合、疎結合が指すところの意味
システムを構成する**「部品（モジュール）」** や**「システム自体」** の結びつきの強さを表す言葉です。
| 用語 | 結びつきの強さ | 状態 | メリット/デメリット | 例えるなら |
|---|---|---|---|---|
| 密結合 (Tight Coupling) | 結びつきが強い | 部品同士がお互いに強く依存し合っている。 | 一つの部品を直すと、他の部品にも影響が出やすい。技術の自由度が低い。 | 絡み合った糸。一本を引っ張ると、全体が動く。 |
| 疎結合 (Loose Coupling) | 結びつきが弱い | 部品同士が独立していて、お互いにほとんど依存していない。 | 一つの部品を変えても、他の部分に影響が出にくい。変更が簡単で、開発のスピードが上がる。 | ブロック玩具。一つのブロックを外しても、他のブロックは平気。 |
ランダウのO記法で表される計算量 $O(f(N))$ はどう決まるか？
アルゴリズム（計算の手順）の「効率の良さ」 を表す方法です。
- $N$：入力のサイズ（例：処理するデータの数）。
計算量 $O(f(N))$ は、「データサイズ $N$ が大きくなったとき、そのアルゴリズムの実行時間がだいたいどれくらいの速さで増えるか」 を示しています。
- 例えば、データ数 $N$ が2倍になったとき、
- $O(N)$ のアルゴリズムなら、実行時間もだいたい2倍になる。
- $O(N^2)$ のアルゴリズムなら、実行時間はだいたい4倍になる。
最も影響が大きい部分（実行時間が一番増える部分）だけを取り出して、一番シンプルな形で表現します。この記法を使うことで、アルゴリズムを比べるのに役立ちます。
☆DRY、KISS、YAGNIが指すそれぞれの意味
良いプログラムを書くための、開発者の心得や原則です。
| 原則 | 意味 | 役立つこと（理由） | 例えるなら |
|---|---|---|---|
| DRY (Don't Repeat Yourself) | 同じコードを重複して書かない。 | コードが見やすく（可読性） なり、修正が必要な箇所が一つだけで済むようになる。 | 共通のルールは、一箇所にまとめて書いておく。 |
| KISS (Keep It Simple, Stupid) | コードは常に**「単純で、簡潔であること」** を最優先する。 | シンプルなコードは理解しやすく、バグが入る余地が少なく、修正も簡単になる。 | 最も簡単な方法で目的を達成する。 |
| YAGNI (You Aren't Gonna Need It) | 「たぶん将来必要になるかも」 と思っても、今、本当に必要になったときまで、そのためのコードは書かない。 | 使われない機能をあらかじめ作っておくと、コードが無駄に複雑になるのを防ぐ。 | 今使うものだけをカバンに入れる。 |
☆CI/CDとは？
CI（継続的インテグレーション） とCD（継続的デリバリー/デプロイメント） は、プログラムの変更を効率的、かつ自動で行うための開発のやり方です。
| 略称 | 意味 | 目的 |
|---|---|---|
| CI (Continuous Integration) 継続的インテグレーション | プログラムの変更を頻繁にチームの共有リポジトリに合体（マージ） させ、そのたびに自動でビルド・テストを実行する。 | バグを早い段階で発見し、プログラムの品質を保つ。 |
| CD (Continuous Delivery/Deployment) 継続的デリバリー/デプロイメント | CIでテストを通ったコードを、リリースできる状態（デリバリー） にしたり、本番環境に自動で公開（デプロイメント） したりする。 | 手作業を減らし、安全に、素早くWebサイトやアプリを更新できるようにする。 |
☆開発環境、テスト環境、ステージング環境、本番環境
アプリケーションを開発し、公開するまでに使う、それぞれの目的を持った環境のことです。
| 環境名 | 目的 | 例えるなら |
|---|---|---|
| 開発環境 | 開発者が自分のパソコン（ローカル）などで、プログラムを書いたり、動かして試したりする場所。 | 自宅の「作業部屋」。 |
| テスト環境 | 開発が終わったプログラムが、「決められた通りに動くか」 をテスト担当者やチームで検証する場所。 | 「品質管理室」。機能が壊れていないかを厳しくチェックする。 |
| ステージング環境 | 本番環境とほぼ同じ構成（サーバー、ネットワーク、設定など） で作られた、本番直前の最終確認をする場所。 | 「リハーサル会場」。本番と全く同じ条件で、問題がないか最終チェックする。 |
| 本番環境 | 実際にユーザーがアクセスして利用する、公開されているシステムが動く場所。 | 「実際のコンサート会場」。 |
心理的安全性とは？
組織やチームの中で、「自分の意見や質問、間違いを正直に発言しても、非難されたり、バカにされたりしない」 という安心感がある状態のことです。
-
心理的安全性が高いチーム:
- メンバーは**「分からない」** と素直に言え、建設的な議論ができ、新しいアイデアも生まれやすいです。
- ミスを隠さず報告できるため、問題が大きくなる前に解決できます。
WBSとガントチャートの違い
プロジェクトのタスク（作業）を管理するためのツールです。
| ツール名 | 目的 | 内容 | 例えるなら |
|---|---|---|---|
| WBS (Work Breakdown Structure) | プロジェクトの作業を細かく分けて、リスト化する。 | 作業名、担当者、作業時間などが書かれたタスクのリスト。 | 料理の「レシピ」。何を作るか、どんな手順か、誰が担当かを全て書き出す。 |
| ガントチャート | WBSのタスクを元に、いつ、どのタスクをやるかを時間軸で表したスケジュール表。 | 横棒グラフで、タスクの開始日、終了日、進捗状況を示す。 | 料理の「スケジュール表」。いつ、何を、どれくらいの時間をかけてやるか、時系列で示す。 |
ロードマップとは？メリットは？
ロードマップとは？
プロジェクトや製品の**「将来の目標」** と、そこへたどり着くための**「おおまかな計画（工程表）」** を示すものです。
- 特徴: 詳細なスケジュールではなく、大まかな方向性や、達成すべき大きな目標を示します。
メリット
-
ビジョンの共有:
チームメンバー全員が、「自分たちのプロジェクトが最終的にどこへ向かっているのか」 という成功への道筋（ビジョン） を理解し、目標を共有しやすくなります。 -
優先順位の決定:
長期的な目標に照らし合わせて、「今、何をすべきか」 の優先順位を決めるのに役立ちます。
バックログとは？メリットは？
バックログとは？
「プロダクト・バックログ」 のことで、「製品に必要な機能や改善点、直すべきバグ」 などを全てリスト化し、優先順位を付けて記述したものです。
-
特徴:
- 機能だけでなく、技術的な改善や調査なども含みます。
- 優先順位は一番上が**「今すぐやるべきこと」** になります。
メリット
-
状況の把握:
関係者（ステークホルダー）全員がこのリストを見ることで、「今、製品に何が必要とされていて、次に何を作るのか」 というプロダクトの現状と計画を簡単に把握できます。 -
優先順位の透明化:
リストに優先順位が付いているため、チームが次に何をすべきかが明確になり、効率的に開発を進められます。