非エンジニアのためのAI時代個人Web制作ノート#1｜調べたことアレコレを簡潔に！

1. 創造の鍛冶屋 Google AI Studio（GAS）

このアプリケーションは、AIaaS / PaaS的な性格を持つサービスです。
特に、Gemini APIを使った生成AIアプリ開発を始めるための環境として理解するとよい。

【役割：生成AIによるコード・ロジックの具現化】
本プロジェクトの「頭脳」。自然言語処理(NLP)での対話から、複雑なプログラムを生成します。

• 中心技術：LLM（大規模言語モデル）
  • Googleの最新モデル「Gemini」を使用。
• G検定重要ワード：プロンプトエンジニアリング
  • 抽象的概念を、AIが理解できる制約（Constraint）として与える技術。
    ※ただし、AIのバージョンが進むと以前のプロンプトでは、同じ出力が得られない可能性もある。あまり固執しすぎるのもよくないと感じた。

【できること】

GASは、Googleの生成AIモデルであるGeminiを使い、プロンプトの試行やAPI連携を始めやすくする開発環境です。公式にも、Gemini APIで構築を始める最速の方法として説明されています。

GASを「作業者」ではなく「設計士」として使うのがポイント。たとえば、「黒と白を基調にした静かな個人サイトにしたい」「記事一覧ページを作りたい」と自然な言葉で伝え、AIに構成やコードを提案してもらう。

AIと対話しながら、Web制作の設計・実装を進める場所と言える。

板書メモ

• プロンプト：AIへの指示文
• API：別サービス同士をつなぐ窓口
• 生成AI：文章・画像・コードなどを生成するAI
• マルチモーダル：テキストだけでなく画像・音声なども扱える性質

🔍 Deep Dive：AIが選んだ最強の武器「Next.js 15」

• 特徴： Reactベースの最新Web制作フレームワーク。
• なぜAIと相性が良い？： 「書き方の型」が厳格に決まっているため、AIは学習した膨大なコーディングデータに基づき、バグの少ない高精度なコードを出力できる。

1. 「静」と「動」を使い分けるハイブリッド・シェフ

Next.js 15は、1枚のWebページの中に、「あらかじめ作っておく部分（静的）」と「その場で作り出す部分（動的）」を混在させることができます。

• 静的（SSG: Static Site Generation）ホテルの「固定メニュー」。誰がいつ見ても同じ。
  • G検定ワード： 推論の高速化。あらかじめ計算（ビルド）を済ませておくことで、ユーザーへの応答速度を極限まで高めます。
• 動的（SSR: Server-Side Rendering）「本日の日替わり」。注文（アクセス）が入ってから作る。
  • 実例（過去のトラブル）： microCMSの記事一覧。これをお店（Firebase）に出した途端、Next.js 15が気を利かせすぎて「固定メニュー」だと勘違いし、更新が止まってしまった事件（バグ）あり。

2. 「キャッシュ」という名の記憶力

Next.js 15の最大の特徴（そして手強い実態）は、「一度調べたことは二度と調べない」という強烈な記憶力です。

• 実態： microCMSにデータを取りに行く際、「さっき見たから、次も同じでしょ？」と勝手に判断します。
• G検定ワード： 効率的なリソース活用。無駄な計算（API通信）を省くための最適化ですが、これが裏目に出ると「情報が古いまま」になります。
• 解決策： GASが提示した「force-dynamic（常に最新を取りに行け）」という指示は、コンシェルジュに「自分の記憶を疑え」と命令したことになります。

3. 「React Server Components」という裏方仕事

Next.js 15では、「サーバー側（裏方）」でほとんどの仕事を済ませて、ユーザーのスマホ（表舞台）には完成品だけを届けるという実態があります。

• 実例： 従来のWebは、スマホの中で重いプログラム（JavaScript）を動かしていましたが、Next.js 15はサーバー側（Firebaseの裏側）で組み立てを完了させます。
• メリット： スマホの電池を食わず、読み込みが「静寂（Quiet）」なほど速い。
• G検定ワード： エッジコンピューティング的発想。ユーザーに近い場所で処理を行い、クライアント（スマホ）側の負荷を最小限に抑える構造です。

2. 無限の知の源泉 microCMS（CMS）

このアプリケーションは、SaaS / Headless CMSに該当するサービスです。
SaaSは、ソフトウェアをインターネット経由で利用する形です。

【役割：コンテンツの構造化保管】 記事データのみを管理し、APIで配信するヘッドレスCMS。

• G検定重要ワード：API（Application Programming Interface）
  • ソフトウェア同士がデータをやり取りする「窓口」。

【できること】

microCMSは、APIベースの日本製Headless CMSです。公式サイトでも、管理画面を自作せず、APIからデータを取得できるCMSとして説明されています。

WordPressは「記事を書く場所」と「サイト表示の仕組み」が一体型です。
一方、microCMSは主に「記事データを管理する場所」です。サイトの見た目は別で作り、記事データだけをmicroCMSから取得します。

これを「Headless CMS」と呼びます。
Headlessとは、頭がないという意味です。ここでいう「頭」は、見た目の画面部分です。つまり、記事管理の裏側だけを持ち、表示画面は別で作るCMSという理解で十分です。

記事を管理し、WebサイトへAPIで届ける本棚と言える。

板書メモ

• CMS：記事や画像を管理する仕組み
• Headless CMS：表示画面を持たず、データ管理に特化したCMS
• APIベース：データをAPI経由で受け渡しする仕組み

🔍 Deep Dive：データの共通言語「JSON（.json）」

• 様態： 半構造化データ（Key-Value形式）。
• 役割： microCMSに保管された記事を、Next.jsという「表示側」に届ける際のパッキング形式。
• Key：
  • "title": "G検定対策" ⬅️ このように意味（Key）と中身（Value）が対になっている。
  • 人間にも読みやすく、機械（AI）も処理しやすいため、現代のWebの標準語。

■ JSONの実態：「国際標準のパッキング・リスト」

JSONの実態を最もよく表す例は、通販の「送り状（納品書）」です。

荷物（データ）を microCMS という倉庫から Next.js という店舗へ運ぶとき、中身が何であるかを誰でも（どのシステムでも）読み取れるように共通の書式で書かれたラベル、それがJSONです。

【JSONの板書メモ】

• 特徴： { } や " 、 , が非常に多い。
• 実態例： ```json { "商品名": "G検定公式テキスト", "価格": 3000, "在庫": true }

3. 鉄腕の総監督 GitHub（GH）

このアプリケーションは、SaaS型の開発プラットフォームに該当するサービスです。
Gitというバージョン管理の考え方を、クラウド上で使いやすくしたサービスです。

【役割：バージョン管理 兼 自動化のハブ】
コードの保管だけでなく、テストから公開までを全自動化する「総監督」。

• G検定重要ワード：CI/CD（継続的インテグレーション／デリバリー）
  • コードを保存した瞬間に、自動でビルド・デプロイを行う仕組み。

【できること】

GitHubは、ソースコードをホスティングし、レビューやプロジェクト管理をしながら開発できるプラットフォームです。公式サイトでも、ソースコードをホスティングし、他の開発者とレビューや管理を行える場として説明されています。

非エンジニアにとってGitHubは難しく見えますが、最初は「コードの保管庫」と考えると理解しやすいです。

重要なのは、変更履歴を残せることです。
たとえば、AIに修正してもらった結果、サイトが壊れた場合でも、前の状態に戻しやすくなります。

開発の保管庫及びコードの変更履歴を管理し、いざとなればBuildとDeployもこなす万能屋と言える。

板書メモ

• Git：変更履歴を管理する仕組み
• GitHub：Gitをクラウドで使いやすくするサービス
• リポジトリ：コードを入れておく箱
• コミット：変更内容の記録

🔍 Deep Dive：自動化の指示書「YAML（.yml）」

• 様態： 半構造化データ
• 役割： GitHub Actions（ロボット）に対する「自動搬送の手順書」。
• key：
  • IaC（Infrastructure as Code）の一端。
  • インデント（字下げ）で構造を表現。
  • 例：「まずNext.jsを立ち上げて、次にFirebaseへ送れ」という手順を記述。

■ JSON vs YAML：使い分けの決定打

💡 結論：使い分けのルール

• 「通信」なら JSON
  • （例：microCMSから記事データを引っ張る時）
  • 理由：プログラムが読み取るための「共通パスポート」だから。
• 「設定」なら YAML
  • （例：GitHub Actionsで自動デプロイの手順を書く時）
  • 理由：人間が読んで理解し、コメントを残すための「レシピ本」だから。

4. ワールド・エッジ Firebase　（FB）

このアプリケーションは、BaaS / PaaSに近いクラウドサービス群です。
Backend as a Service、Platform as a Serviceの考え方に関連します。

【役割：サーバーレス・ホスティング】
世界中の読者にブログを爆速で届ける「お店の建物（インフラ）」。

• G検定重要ワード：サーバーレス（Serverless）
  • OSのアップデートやサーバーの物理的な管理をGoogleが代行。ユーザーは「コードを置くだけ」でOK。
• CDN（Content Delivery Network）
  • 世界中にデータをキャッシュ（一時保存）し、物理的な距離による遅延を解消。

【できること】

Firebaseは、Googleが提供するモバイル・Webアプリ開発プラットフォームです。公式サイトでは、アプリの構築・実行を、速度・安全性・拡張性の面から支援するサービス群として説明されています。

今回の構成では、Firebaseは「公開する場所」として考えるとわかりやすいです。
Google AI Studioで作り、GitHubで保管し、microCMSから記事を取得し、最後にFirebaseで公開する。つまり、読者が実際にアクセスするWebサイトの土台になります。

作ったWebサイトを高速通信網へ公開・運用するGoogleの土台と言える。

板書メモ

• BaaS：バックエンド機能をサービスとして使う形　（Backend as a Service)
• PaaS：アプリを動かす土台をサービスとして使う形 　(Platform as a Service)
• Hosting：Webサイトを公開する仕組み
• スケーラビリティ：アクセス増加に対応しやすい性質

🔍 Deep Dive：配信ルールの定義ファイル「firebase.json」

• 様態： 半構造化データ
• 役割： Firebaseに対し、「どのURLでどのページを出すか」を教える設定。
• G検定視点： 物理サーバーの設定（Apache等）をファイル一個（JSON）で完結させる抽象化技術の好例。

1. firebase.json は「お店の運営マニュアル」

Firebase Hostingという「お店（インフラ）」を動かすとき、Googleのシステムは必ずプロジェクトのルート（一番上の階層）にある firebase.json という名前のファイルを読みに行きます。

• 名前の固有性： setting.json や my-config.json ではダメなのです。「この名前のファイルに、運営ルールが書いてある」という世界共通の約束事になっています。
• 役割： 「どのフォルダを公開するか」「URLの末尾をどう整えるか」といったインフラの挙動を定義します。

2. なぜ YAML ではなく JSON なのか？

「設定ファイルならYAMLの方が人間には読みやすい」と先ほどお話ししましたが、FirebaseはあえてJSONを採用しています。

• 理由： Firebase自体がGoogleの巨大なシステム群の一部であり、システム内部での処理スピードや、他のプログラムとの連携の確実性を優先したためだと考えられます。
• 対比： GitHub Actions： 「人間」が書く手順書なので YAML
  • Firebase： 「システム」が厳格に読み取るルールブックなので JSON (firebase.json)

3. G検定の文脈での重要性：抽象化（Abstraction）

firebase.json を強調した最大の理由は、これが「インフラの抽象化」を象徴しているからです。

昔はサーバーを動かすために、黒い画面（コマンドライン）で複雑な設定を何百行も書く必要がありました。しかし今は、この「たった一つのJSONファイル」を書き換えるだけで、Googleの強力なサーバー群を意のままに操れます。 「複雑なものを、一つのファイル（データ）として扱う」という考え方は、G検定でも重要な「効率化」や「仮想化」の概念に通じます。