30日でエンジニアになるリスキリング講座

この章のゴール

ブラウザに「AIと一緒に作り上げた1ページ目」を表示させる この章では、開発環境の準備・ターミナル操作・AIへの最初の指示を出すところまでを行い、社内FAQのトップページをブラウザに表示させます。

VS Code / Node.js / コーディングAI の3つを自分のPCに準備します。 マウスではなく、文字入力でパソコンに指示を出すターミナル(黒い画面)を使います。 たった1つの指示で、自分の意図したとおりのWebページを表示します。

学習ロードマップ

「30日でエンジニアになるリスキリング講座」の各章の構成です。

カリキュラム全体像

章 講座タイトル 講座で作成するもの この章を通じて身につけるもの 1 事前準備とはじめの一歩 社内FAQトップページ 開発環境の構築とAIへの初回指示 2 AIでWebページを作る チーム紹介ページ AIへのページ依頼プロンプトの型 3 Webサイトをデザインする プロジェクト成果共有ページ レスポンシブ対応と画像生成AIの活用 4 JavaScriptで動くページを作る 経費申請チェッカー JavaScriptで入力→計算→表示 5 Webアプリを作る 問い合わせ対応テンプレ生成アプリ Webアプリの設計とAIでの組み立て 6 APIでデータを取得する 社内営業KPIダッシュボード APIからのデータ取得と自動集計 7 データを保存・共有する 顧客問い合わせ台帳アプリ クラウドDBでのデータ保存・共有 8 アプリを社内に公開する 部署マニュアルサイト Git/GitHub PagesでのWeb公開 9 卒業制作 業務課題を解く1本 企画〜実装の一貫した業務フロー

5つのステップ

この講座で学んだことを活かせば、自分で業務ツールを作れるようになります。一緒に進めていきましょう。

開発環境の準備と最初の1ページを作成します。 見た目を整えたWebページを作成します。 操作に応じて動くデータを扱うアプリを作成します。 作成したWebアプリを公開します。 卒業課題でWebアプリを作成します。

第1章で身につく3つのステップ

この章で身につくのは、これから30日間の講座でずっと使っていく3つのステップです。9章の卒業制作で業務課題を解くときも、明日から別の社内ツールを作るときも、起点はこの3ステップに戻ります。

VS Code・Node.js・コーディングAIを自分のPCに用意する。 3つのツールがすべてPCにインストールできていればOK 文字でPCに指示を出す画面を、怖がらずに開ける状態にする。使うコマンドは最初は3つだけ。 ターミナルを開いて、フォルダの中身を見られればOK 自分で全部書くのではなく、AIに1行プロンプトで依頼して、成果物を受け取る流れを体験する。 AIに頼んだページがブラウザに表示できればOK

必要なもの

本講座で使用するPC・ツール・サービスは以下のとおりです。PC・インターネット環境は事前に、開発ツール・コーディングAIは本章で準備します。

Windows 10/11 または Mac。メモリ 8GB 以上。 コーディングAIを利用する場合、一般的にメモリ16GB以上が推奨されます。 自宅 or オフィスの安定したWi-Fi。社内ネットワークでも可。 会社のネットワーク制限で、ツールのインストールができないことがあります。事前にIT担当者に相談。 VS Code / Node.js（第1章でインストール） どちらも業務で使える定番ツール。PCに入れても問題ありません。 Codex / Claude Code / Gemini CLI から1つ。月額約3,000円。 一部無料プランもありますが、本講座は有料前提。会社経費は社内申請、個人利用は各自で契約してください。

🔎 自分のPCが条件に合うかを確認する方法

Windows：タスクマネージャ「パフォーマンス」でメモリを確認（ショートカットキー：Ctrl+Shift+Esc）。 Mac：左上 Apple メニュー「この Mac について」でメモリを確認。

AIは「超優秀な部下」― あなたは指示を出す側

AIは「専門スキルを持つチームメンバー」が常に横にいる感覚

AI（ChatGPT / Claude / Gemini など）は、膨大な文章を読み込んで "次に来る言葉" を予測するプログラムです。コードを書く・デザインを考える・文章をまとめるといった業務を代行できるレベルまで来ています。

指示の精度が、成果物の精度を決める

結果の質を決めるのは「あなたの指示」です。部下に「いい感じにまとめておいて」と頼んでも欲しい資料が出てこないのと同じ。30日間の講座で身につけるのは、AIに的確な指示を出す「監督力」 そのものです。

❌ 曖昧な指示 「FAQページをいい感じに作って」

→

✅ 具体的な指示 総務部向けFAQトップを水色背景・白文字見出しで

あなた（監督）が AI（部下）に指示を出す

🎬 監督の3つの仕事 — 講座を通じて身につける型

① ゴールを明確にする 「誰の」「どの業務課題を」解くのかを1文で書く

② 的確な指示を出す 何を・どんな見た目で・どこに、を具体化する

③ 成果物を評価する AIの回答がイメージと違えば、もっと具体的に頼み直す

2種類のAIを使い分ける — 相談役と作業役

AIには大きく2種類あります。チャットAI（ブラウザで対話）は企画・相談に、コーディングAI（ターミナルで作業）は実装に強みがあります。本講座の主役はコーディングAIですが、考えの整理や相談には必ずチャットAIを併用します。

ChatGPT / Claude / Gemini 業務課題の言語化／機能アイデアの相談／文章や資料のドラフト作成 総務部で繰り返し聞かれる質問を10個挙げて、FAQページに載せる順で並べて Codex / Claude Code / Gemini CLI コードの生成・編集・実行／ファイル操作／デバッグ／プロジェクト作成 src/App.jsx を編集して、社内FAQトップページを水色背景で作って

🔄 実務での流れ — "相談 → 実装" のバトンを必ず通す

①チャットAIに業務課題を相談して機能案やテキスト素材を受け取る → ②コーディングAIに「この要件でコードを書いて」と渡す。この2ステップが本講座の基本の流れです。いきなり実装AIに頼むと要件が曖昧なまま走り出して手戻りが増えます。

作業台を用意する — VS Code

VS Code（Visual Studio Code）は、プロのエンジニアが使う無料のコードエディタです。Word が文書作成ソフトなら、VS Code はコード作成ソフト。社内でコードレビューや手順書の整備にも使えます。

インストール手順 — Windows

1. ブラウザで `https:
2. 「Download for Windows」をクリック
3. ダウンロードした .exe を実行
4. 使用許諾契約書の同意 → 「同意する」にチェックして次へ
5. 追加タスクの選択 → 項目選択は変更せず、次へ
6. インストール準備完了 → 「インストール」をクリック
7. セットアップウィザードの完了 → 「完了」ボタンをクリック

🎬 動画ガイド VS Code のインストール手順動画 (0:00〜2:30) https://www.youtube.com/watch?v=zK1rKC7QVwk

インストール手順 — Mac

1. 同じURLで「Download for Mac」をクリック
2. ダウンロードした .zip を展開
3. Visual Studio Code.app を「アプリケーション」フォルダにドラッグ
4. 「アプリケーション」から VS Code を起動

起動後の画面 — 主要3エリア

左側。ファイル一覧。社内のフォルダ階層と同じ感覚 中央。実際にコードを書く／AIが書いたコードを読む 下側。AIに指示を出す "窓口"

⌨️ 必須ショートカット ターミナル開閉 — Ctrl + J（Windows） / Cmd + J（Mac）

最初に入れておくと便利なVS Code 3つの拡張機能

メニューを日本語表示に切替。起動後に左サイドバーの拡張機能マークから検索＆インストール。 コードの見た目を自動で整えるツール。保存時にインデントがそろい、手直しの手間が減る。 社内手順書やREADMEを書くときの相棒。プレビュー・目次生成が一発で効く。

ターミナルに慣れる — 文字でPCに指示する黒い画面

マウスの代わりに文字で指示を出す

普段はマウスでフォルダをクリックして開きますが、ターミナルでは 文字（コマンド） で同じ操作をします。"黒い画面に文字を打つ" というだけで、魔法のようなことは何もしていません。

なぜこの章から使うのか

・コーディングAIとの会話はターミナルで行う ・ツール（Node.js・コーディングAI本体）のインストールに必要 ・作ったものをサーバで動かす・共有する操作もターミナル経由

💡 最初に覚えるのは3つだけ この先30日間、毎回使うコマンドはほぼ決まっています。1日目は右の3つから。30日目になる頃には手が勝手に動くようになります。

開き方

・VS Code を起動 → Ctrl + J（Windows）/ Cmd + J（Mac） ・Windows は PowerShell、Mac は zsh が自動で起動

最初に覚える3つのコマンド

今いるフォルダの "住所" を確認 /Users/yamada/Documents 今いるフォルダの中身を一覧表示 Desktop Documents Downloads 指定フォルダに移動する cd Documents

✅ 最初の練習 pwd → ls → cd <表示されたフォルダ名> → ls の順で打ってみる。"場所を確認 → 中を見る → 移動 → また中を見る" が業務フォルダ整理と同じ感覚だと分かります。

JavaScript を動かす土台 — Node.js

Node.js は、JavaScript というプログラミング言語をPC上で動かすツールです。このあとインストールするコーディングAI や、Webアプリを動かすサーバにも必要な "共通の土台" です。

🪟 Windows — インストーラー方式

1. `https:
2. 「Windowsインストーラー（.msi）」をクリック
3. ダウンロードした .msi を実行
4. 「WindowsによってPCが保護されました」→「詳細情報」→「実行」をクリック
5. Welcome to the Node.js Setup Wizard →「Next」
6. End-User License Agreement →「I accept the terms…」にチェック →「Next」
7. Destination Folder →変更せず「Next」
8. Ready to install Node.js →「Install」
9. Completed the Node.js Setup Wizard →「Finish」

🎬 動画ガイド Node.js インストール手順（Windows）YouTube (2:05〜3:45)

🍎 Mac — ターミナル方式（nvm）

ターミナルに以下を1行ずつ貼り付け → Enter（nvm＝Node.js のバージョン管理ツール）:

curl -o- https: . "$HOME/.nvm/nvm.sh" nvm install 24`

💡 ターミナルが不安なら、Windows と同じ要領でインストーラーを使う方法でもOK。nodejs.org/en/download から macOS 版 LTS の .pkg をダウンロードして「Next」で進めてください。

✅ Windows / Mac 共通 — 動作確認

ターミナルに node -v と入力して Enter。v24.x.x のようにバージョンが表示されれば成功。数字が出ない場合はターミナルを一度閉じて開き直してください。

$ node -v v24.8.0

コーディングAIを1つ選ぶ

以下の3つのコーディングAIから1つを選びます。既に契約しているサービスがあればそれを使い、なければ講座で中心的に扱う Claude Code が無難です。本書のプロンプト例・動作画面はすべて Claude Code で動作確認済み。

ChatGPT Plus/Pro npm i -g @openai/codex 既にChatGPT Plus/Pro契約済みなら追加費用不要。日本語の指示にも安定して応答。 すでに ChatGPT を仕事で常用している人 Claude Pro/Max Mac: curl -fsSL https: Win: irm https: Windows は事前に Git（コード履歴管理ツール）のインストールが必要。Mac は標準搭載のため不要。講座のメイン例として本書中で扱う。 迷った人／本書の手順をそのまま追いたい人 Google AI Pro 月額2,900円（初月無料） npm install -g @google/gemini-cli Google アカウントで認証。無料枠もあるが講座では Pro 推奨。 Google Workspace をすでに業務で使っている人

⚠️ Windows で Claude Code を選ぶ場合 事前に Git（コード履歴管理ツール）のインストールが必要。手順は次ページで解説します。

💡 途中で乗り換えOK 使ってみて合わなければ別ツールに切り替え可能。どのツールを選んでも学習内容は変わりません。

コード履歴管理ツール — Git

Git は、コードの変更履歴を記録するツールです。Claude Code は内部で Git を使うため、Windows で Claude Code を選んだ場合のみ 事前インストールが必要です。Mac は標準搭載のため不要、Codex / Gemini を選んだ場合もこのページはスキップしてください。

🪟 Windows — インストーラー方式

1. `https:
2. 「Click here to download」→ ダウンロードした Git-x.xx.x-64-bit.exe を実行
3. 以下4画面（Information / Select Destination Location / Select Components / Select Start Menu Folder）→ 全て変更せず「Next」
4. ⭐ Choosing the default editor → Visual Studio Code を選択 →「Next」（次ページの画像参照）
5. ⭐ Adjusting the name of the initial branch → Override... を選択（main のまま）→「Next」（次ページの画像参照）
6. 以下8画面（PATH environment / SSH executable / HTTPS transport backend / Line ending conversions / Terminal emulator / git pull behavior / Credential helper / Extra options）→ すべてデフォルトのまま「Next」
7. 最後に「Install」→ 完了画面で「Finish」（チェックは外して OK）

✅ このページをスキップしてよい人

1. Mac ユーザー — Git は標準搭載のため作業不要
2. Codex / Gemini を選んだ人 — Git は不要

💡 既にインストール済みかも？ Windows ユーザーでも、過去に Git を入れている可能性があります。ターミナルで git --version を実行し、git version 2.x.x のように表示されれば、すでにインストール済みです（その場合はこのページをスキップしてください）。

⚠️ 重要：次ページの2画面はデフォルトのままにせず、明示的に選択してください（Choosing the default editor と Adjusting the name of the initial branch）

Git インストール — 重要な選択画面と動作確認

前ページのインストール中、ステップ5・6にあたる2画面はデフォルトのまま「Next」せず、明示的に選択する必要があります。それぞれの画面イメージと正しい選択を示します。

⭐ ステップ5：エディタ選択

Choosing the default editor used by Git

ドロップダウンから Use Visual Studio Code as Git's default editor を選択 →「Next」。

💡 デフォルトの Vim のままだと、後で git commit した時にエディタに突入して脱出方法が分からず詰まります。

⭐ ステップ6：初期ブランチ名

Adjusting the name of the initial branch in new repositories

Override the default branch name for new repositories を選択（入力欄は main のまま）→「Next」。

💡 GitHub の新規リポジトリのデフォルトブランチ名と揃えるための設定です。

✅ 動作確認 — git --version

インストール後は、VS Code を完全に終了して開き直してから 確認します（起動中の VS Code には新しい PATH が反映されないため）。新しい VS Code の統合ターミナル（PowerShell）で git --version を実行 → git version 2.xx.x のようにバージョンが表示されれば成功。

$ git --version git version 2.54.0.windows.1

コーディングAIを起動する

コーディングAIのインストールが終わった後は、作業用フォルダを作成して、コーディングAIを起動します。以下の3ステップは、どのコーディングAIも同じ流れです。初回起動時にブラウザでログイン画面が表示されるので、登録済みアカウントでログインしてください。

STEP 1

作業フォルダを作る

$ mkdir my-first-project $ cd my-first-project

mkdir で新規フォルダ作成、cd でその中に移動

STEP 2

起動コマンドを打つ

コーディングAI コマンド Codex codex Claude Code claude Gemini CLI gemini

STEP 3

ブラウザで認証

・初回のみ画面の案内に従ってログイン ・登録済みアカウントで認証 ・ターミナルに戻ると対話画面が起動

起動後の画面イメージ（Claude Code の場合）

💡 動かないときのチェックリスト

① ターミナルを閉じて開き直す ② node -v でバージョン確認 ③ エラー文をコピー → チャットAIに貼り付けて「このエラーの原因と解決策を教えて」と聞く

Claude Code の起動方法（前半：起動と認証）

本書のメインで扱う Claude Code を例に、画面遷移を10ステップで示します。STEP 1〜5 はコマンド起動とブラウザ認証の準備。STEP 6〜10（次ページ）で対話画面まで到達します。初回のみ必要な手順で、2回目以降は STEP 1 のコマンド入力だけで起動します。

ターミナルで claude を実行 矢印キーで好みのテーマを選択 「Claude account」を選んで Enter 表示された URL をブラウザで開く ブラウザで「Authorize」をクリック

🧭 ここまでの流れ

1. ターミナルで起動 → 初期設定（STEP 1〜2）
2. ログイン方式の選択（STEP 3）
3. ブラウザを開いて認証画面へ（STEP 4〜5）

➡ 次ページ：認証コードの貼付〜対話画面の起動

Claude Code の起動方法（後半：認証完了と起動）

ブラウザで取得した認証コードをターミナルに戻して貼り付け、安全確認を経て対話画面が起動します。STEP 6〜10 は1度通過すれば完了で、2回目以降の起動では再度求められません。

コードをコピーしてターミナルに貼付 「Login successful」を確認して Enter 案内画面で Enter を押して進む 1. Yes, I trust this folder を選択 プロンプト入力欄が表示されれば完了

💡 認証は初回だけ

・2回目以降は STEP 1 の claude コマンドだけで対話画面に直行

・別 PC や別アカウントで使うときは再度 STEP 3〜6 が必要

・/logout でログアウト、/login で再ログイン

・対話画面の ? で利用可能なショートカット一覧を表示

作業開始前チェックリスト

これまでの手順で開発環境が揃っているか、以下の4項目を確認します。 すべて完了すると次ページのプロジェクト作成に進めます。

スタートメニュー（Windows）または Launchpad（Mac）から "Visual Studio Code" を起動 VS Code のウィンドウが開く。Japanese Language Pack を入れた場合はメニューが日本語 8ページ「作業台を用意する — VS Code」をチェック 画面上部のメニューから ターミナル → 新しいターミナル（または Ctrl+J / Cmd+J） 画面下部に黒い画面が開き、プロンプト（Windows は >, Mac は % など）が表示される VS Code を再起動。その後にターミナルが表示されない場合は画面上部のメニュー → ターミナル → 新しいターミナル

ターミナルに node -v と入力して Enter v24.x.x のようにバージョン番号が表示される 10ページ「JavaScript を動かす土台 — Node.js」をチェック ターミナルに claude / codex / gemini のどれかを入力して Enter 起動画面と入力欄（>マーク）が表示される（初回はブラウザでログインが必要） 12ページ「コーディングAIを起動する」をチェック

✅ 4項目すべてが完了したら次のステップへ

開発環境が揃いました。次のページから「社内FAQページ」のプロジェクトを作成します。最初はAIがほぼ全部書いてくれるので、安心して進めてください。

💡 1つでも詰まったら

エラー文をそのままコピーして、チャットAIに「このエラーの解決策を教えて」と相談するのが一番早い解決ルートです。

作業フォルダを用意する

これから30日間、章ごとに作るプロジェクトはすべて ai-know-work という1つの親フォルダ配下にまとめます。次回以降の章では、このフォルダの直下に ch02/、ch03/ ... と章別のサブフォルダを追加していきます。

📂 最終的に作るディレクトリ構造

ai-know-work/ ← この章で作る親フォルダ ├─ ch01/ ← この章で後ほど作るプロジェクト ├─ ch02/ ← 次の章で追加 └─ ...

1. エクスプローラを開く（⊞ Win + E）
2. 「PC > Cドライブ > ユーザー > ＜ユーザー名＞ > Documents」と辿って開く
3. 空白で右クリック → 新規作成 → フォルダー
4. 名前を ai-know-work にして Enter

※ PowerShell 派の場合: mkdir $env:USERPROFILE\Documents\ai-know-work

1. Finder を開く（Dock のニコちゃんマーク）
2. メニュー「移動」→「ホーム」（⌘ + ⇧ + H）
3. 空白で右クリック →「新規フォルダ」
4. 名前を ai-know-work にして return

※ ターミナル派の場合: mkdir ~/ai-know-work

📂 VS Code で開く（Win / Mac 共通）

1. VS Code を起動
2. メニュー「File」→「Open Folder...」（Win: Ctrl + K → Ctrl + O / Mac: ⌘ + O）
3. いま作った ai-know-work を選んで開く
4. 「作成者を信頼しますか？」が出たら 「はい、作成者を信頼します」 を選ぶ（次ページ図①）
5. 画面上部「ターミナル」→「新しいターミナル」（Win: Ctrl + Shift + @ / Mac: ⌃ + Shift + @）で統合ターミナルを開く（次ページ図②）

📸 完成イメージ（Win / Mac 共通）

①「作成者を信頼しますか？」ダイアログ — 「はい、作成者を信頼します」をクリック

② ai-know-work を開き、下部に統合ターミナルが表示された VS Code 画面（タイトルバー・エクスプローラ・統合ターミナルのプロンプト末尾を確認）

✅ ここまで出来たら

VS Code のタイトルバーに「ai-know-work」と表示され、統合ターミナルのプロンプト行末尾が ai-know-work になっていれば完了です。

確認コマンド： Win cd / Mac pwd と入力して Enter → 末尾が ai-know-work なら OK。

最初のプロジェクトを作る — Vite

Vite（ヴィート）は、ReactというWeb開発の人気フレームワークを使ってWebアプリを立ち上げるツールです。ここでは 社内FAQページ の土台となるプロジェクトを作ります。前ページで開いた ai-know-work の統合ターミナルでコマンドを1本叩き、対話に y → Yes と2回答えるだけで、雛形作成・依存インストール・開発サーバ起動まで Vite が自動で完走 します。

📘 React・JSX・フレームワークって何？ React＝画面を「ボタン」「見出し」など部品単位で組み立てる仕組み。　JSX＝HTML に似た書き方を JavaScript に書ける記法（App.jsx の拡張子）。　フレームワーク＝"よく使う定番の土台"。

Ok to proceed? → y Enter、Install with npm and start now? → Yes Enter で、雛形作成・npm install・npm run dev まで Vite が自動で完走する Vite + React のデフォルトページが表示される

✅ 成功の目印 — Vite のロゴと "Vite + React" の文字が見えたら完了。ターミナル側は dev server を止めずに残す（停止は Ctrl + C、再起動は cd ch01 && npm run dev）。

⚠️ ありがちなミス — 対話で No を選ぶと自動セットアップが走らない。手動で cd ch01 && npm install && npm run dev を打ち直すか、ch01 フォルダを消して最初からやり直す。

AIに最初の指示を出す — 社内FAQトップページ①

dev server を動かしたまま、VS Code で 別のターミナル を開き（+ ボタン）、同じ ch01 フォルダでコーディングAIを起動します。以下のプロンプトをコピペして、末尾の業務課題部分だけ自分の部署に書き換えれば、すぐに "社内FAQページの1ページ目" が画面に現れます。

あなたはフロントエンドエンジニアです。 現在の src/App.jsx を編集して、 社内FAQページのトップ画面 を作ってください。

・見出しに「よくある質問」と大きく白文字で中央表示 ・背景は水色（``） ・見出しの下に「【部署名】向け」と1行添える ・画面全体に余白をしっかり取る

【業務課題】（↓自分の状況に書き換え） 総務部に毎週10件以上「年末調整の書類どこで出すの？」「住所変更の手続きは？」と個別チャットで質問が来る。

【業務課題】 自分の部署で "同じ質問が繰り返し来ている" 業務を1つ書く。例：情シスの「パスワード再設定どうするの？」、営業の「見積の割引ルールは？」など。

このプロンプトが効く3つの理由

「社内FAQトップ画面」とゴールを1文で明示 背景色・文字色・レイアウトを具体化 src/App.jsx とファイルパスまで指定

💡 次章以降で深掘り 「何を・どんな見た目で・どこに」の3点は プロンプトの基本要素。2章以降で段階的に技を増やします。また「あなたはフロントエンドエンジニアです」は AI に役割を与える "おまじない"。仕組みは 第5章 で学ぶので、今は丸ごとコピペでOK。

AIに最初の指示を出す — 社内FAQトップページ②

プロンプトを送信したあと、Claude Code に貼り付けた画面（INPUT）と、ブラウザに表示される結果（OUTPUT）を見比べておきます。初回はファイルを書き換える前に 「Do you want to overwrite ...?」 の確認ダイアログが出るので、答え方も先に押さえておきましょう。

INPUT — Claude Code に貼り付けた実画面

OUTPUT — ブラウザに表示される localhost:5173

🔐 「Do you want to overwrite ...?」と聞かれたら（コーディングAI）

Claude Code 等はファイル編集のたびに許可を求めます。基本は 1. Yes を選んで進めればOK。毎回の確認が煩わしくなったら 2. Yes, allow all edits during this session でセッション中は自動許可になります。内容を確認しながら進めたい間は 1 推奨。3. No を選ぶと編集が中止され、ファイルは変更されません。

1. Yes（推奨） 今回の編集だけ許可。1ファイルごとに確認したいとき。

2. Yes, allow all edits ... このセッション中は自動許可。慣れてきたら選ぶ。

3. No 編集を中止。ファイルは変わらない。

詰まったときの3つの窓口

受講中に分からないことが出たら、順に使い分けます。一番早いのはAI学習アシスタント、次にチャットAIにエラー文を貼り付け、それでも解けないときだけ講師Q&Aへ。

学習画面左メニューの「Q&A」

学習画面右上の「AIに質問」ボタン

教材の内容を理解しているAIが即答。学習内の質問全般に最適。 学習画面右上の「AIに質問」→ チャット欄に入力 → 即時回答。 ページ番号を添えると的確な回答が返る。 エラー文の解釈や講座外の技術疑問に強い。 ChatGPT / Claude / Gemini にエラー文を貼り付けて質問。 "何をしていたか" を1行添えると診断精度が上がる。 AIで解決しない場合の最終窓口。 学習画面左メニュー「Q&A」→「新しい質問」から投稿。 試したこと・結果をセットで書くと返信が早い。

この章で達成したこと

VS Code + Node.js + コーディングAI を自PCに揃えた pwd / ls / cd で自由にフォルダ移動できる create → install → run dev で新規プロジェクトを立ち上げ

「何を・見た目・場所」を伝える基本プロンプトで画面を変更 自部署の "繰り返し質問" を社内FAQとして解いていく

🏆 次章への橋渡し

次回は "何を・見た目・場所" の3要素をさらに磨いて、自己紹介ページ（＝社内の担当者紹介ページにも転用できる）を作り込みます。

よくあるトラブル Q&A

command not found が出る ターミナルを一度閉じて開き直す → それでもダメならPC再起動。Node.js 関連なら node -v でインストール済みか確認。 npm run dev が起動しない cd ch01 で作業フォルダに入っているか pwd で確認。npm install が完了していない可能性も。 "ポートが使用中" と出る ポート＝アプリがネットワークで使う「窓口番号」。別ターミナルで既に npm run dev が同じ窓口を使っている状態。そちらで Ctrl + C を押して止めてから再起動。 VS Code が英語で表示される 左側の拡張機能アイコン → "Japanese Language Pack" を検索してインストール → VS Code を再起動。 3つのコーディングAIどれが一番良い？ 現時点で大差なし。講座はClaude Codeで例示するので、迷ったらそれ。途中乗り換えも可能。 Windows と Mac で手順は違う？ 基本同じ。異なる箇所は本テキスト内で両方の手順を並記しているので安心して進められる。

この章のゴール

AIと二人三脚で、自部署の「チーム紹介ページ」を1本作り切る この章の終わりには、自部署のメンバー・役割・連絡先をまとめた1ページのWebサイトが、あなたのブラウザに表示されています。外注や総務依頼で止まっていた1ページものを、AIと一緒に自分の手元で完成させる体験です。

第1章の ch01（社内FAQトップページ）とは別に、新しいプロジェクト ch02 を作業フォルダとして立ち上げます。 コピペ可能なプロンプト雛形に自部署のメンバー情報を差し込み、AI に「1ページもののベース版」を作ってもらいます。 AI の出力をブラウザで確認し、「ここだけ直して」の差分指示を1つずつ重ねて、社内共有レベルのデザインに近づけます。

🎯 この章の合格ライン

チームのメンバー3名分と役割が、自分の書いた指示どおりに画面に並んでいれば合格。デザインの完璧さは求めません。1ステップずつ手を動かして、"AIと一緒に作れた" を体で覚えるのが目的です。

💡 なぜ "チーム紹介ページ" なのか

多くの会社で「外注／総務依頼／古い情報のまま放置」のいずれかになりがちな1ページものです。AIと数十分あれば作れる題材で、自部署の業務課題を自分で解く最初の練習台として最適。

🔗 第1章との関係 — 新しい "作業部屋" を作る 第1章で作った ch01（社内FAQトップページ）はそのまま残します。本章では別物の新規プロジェクト ch02 を1から立ち上げる のがポイント。業務で言えば案件ごとに別フォルダを切るのと同じ。作る場所は第1章と同じ ai-know-work 配下で構いません。

全7ステップの見取り図

この章は 7つのSTEP に区切って進めます。1ページ1アクションで、つまずいても戻りやすい構成です。所要時間は全部で1〜1.5時間、1STEPあたり数分〜10分程度。

PART A ― 作業部屋を用意する（約10分）

PART B ― AIに作ってもらう（約20分）

PART C ― 磨き込む（約15分）

💡 各STEPは前のSTEPが完了している前提です。PART A でブラウザに初期画面を表示し、PART B でAIにチーム紹介ページを作ってもらい、PART C で自分好みに磨きます。

本章で使うコマンド早見

初日に打つのは3つだけ。npm install と npm run dev は2日目以降の "再開時" に使う

ターミナル は文字でPCに指示を出す画面、コマンド はそこに打つ指示文です。第1章と同じく、初回セットアップは Vite が npm install と npm run dev を自動完走するので、覚えるコマンドは3つで足ります。

🔰 初回セットアップで打つ3つ 何をする 使うSTEP cd ~/Documents/ai-know-work (Win) cd ~/ai-know-work (Mac) 1章で作った作業フォルダに入る STEP 1 React雛形を作り、npm install と npm run dev まで自動完走 STEP 1 code ch02 VS Codeでフォルダを開く STEP 3 🔁 2日目以降の再開時に使う2つ（初回は不要） cd ch02 作業フォルダに入る 再開時 npm run dev 開発サーバーを起動（停止は Ctrl + C） 再開時

※ npm install は初回が自動で済んでいるため、package.json を変更しない限り再実行不要。

⌨️ 入力のコツ

大文字小文字を区別。長いコマンドは コピペ が確実。打ち終えたら Enter。

🧠 3つのグループで覚える

cd ＝ 移動／ npm 〜 ＝ ライブラリ操作／ code ＝ VS Code起動。

🆘 打ち間違えたら

Enter前なら矢印キーで修正。実行後のエラーはそのままAIへ貼れば解決策が返る。

💡 コマンドの「おまじない」恐怖症から抜ける 初学者のつまずきの多くは 暗記できていないこと が原因ではなく、意味不明な呪文を打っている 感覚が負担になっているだけ。上表の「何をする」を読むだけで、呪文が "依頼書" に変わります。

STEP 1 — プロジェクトを1コマンドで完走させる

ch02 フォルダ作成・部品DL・開発サーバー起動を、Vite が対話プロンプトで自動完走します。

① まず、ai-know-work フォルダにいることを確認する

第1章で作った親フォルダ ai-know-work の直下に ch02 を追加するため、打つ前にそこにいる状態にしてください。1章で開いた VS Code のタイトルバーが ai-know-work なら、ターミナルのプロンプト末尾も ai-know-work のはずです。閉じてしまった人は Win → cd ~/Documents/ai-know-work ／ Mac → cd ~/ai-know-work

② 次のコマンドを1行コピペして Enter

npm create vite@latest ch02 -- --template react

③ 対話に y → Yes と2回答えるだけで完走する

1. Ok to proceed? → y + Enter（パッケージのインストール許可）
2. Install with npm and start now? → Yes + Enter（雛形作成・npm install・npm run dev まで自動完走）

📦 1コマンドで何が起きた？ (a) ch02/ 作成、(b) node_modules/ に部品自動DL（npm install 相当・1〜3分）、(c) 開発サーバー起動（npm run dev 相当）。新案件フォルダ＋資料取り寄せ＋作業環境立ち上げが一括完了した状態。

💡 対話で No を選んでしまったら cd ch02 && npm install && npm run dev を手動で打つか、ch02 フォルダを消してやり直し。node_modules/ は社内共通の部品倉庫扱いで触らない。

ターミナルに VITE v8.x.x ready in XXX ms と `➜ Local: http:

STEP 2 — ブラウザで初期画面を確認＝初めての「動いた」

この章で一番大事なマイルストーン。まだコードは書いていないのに、自分のPCで Web ページが返ってきます。

① ターミナルに表示されているURLを確認する

STEP 1 の最後で Vite が自動起動した開発サーバーが、次のような表示を出しているはずです。

VITE v8.x.x ready in 312 ms

➜ Local: http: ➜ Network: use --host to expose ➜ press h to show help

*② ブラウザで `http:

Chrome / Safari / Edge など、普段使っているブラウザのアドレスバーに上のURLを貼り付けて Enter。React + Vite のロゴ が並んだ初期画面（第1章で見たのと同じ "Get started" 画面）が表示されれば大成功です。

🎉 最初の「動いた」の瞬間 — あなたのPCの中だけで動いている小さなWebサーバー が表示しています。社内ポータルも世のニュースサイトも、同じ仕組みの大規模版。止めるときはターミナルで Ctrl + C、再開は cd ch02 && npm run dev を実行。

✅ できたらOK ― Vite + React のロゴが表示されていればSTEP 2完了。ターミナルは 閉じずに STEP 3 へ。

🗂 node_modules/ は開かなくてOK ／ 起動しないときは Ctrl+C で再実行 — 自動生成された node_modules/ は 絶対に触らない（社内共通の部品倉庫）。表示されないときは Ctrl + C → cd ch02 && npm run dev を打ち直す。社内ネットワーク絡みは末尾Q&A参照。

STEP 3 — VS Code で ch02 を開く

ターミナルは動かしたまま、もう1つの道具 VS Code で中身を見られるようにします。

① 次のどちらかのやり方で ch02 フォルダを開く

A. メニューから開く

VS Code を起動 → ファイル → フォルダーを開く...（英語UIなら File → Open Folder...）→ ch02 を選んで 開く。

B. ターミナルから開く

新しいターミナルで cd ch02 したあと code . とだけ打つ。code コマンドは VS Code をインストールしていれば使えます（Mac で動かない場合は VS Code で Cmd + Shift + P → "Shell Command: Install 'code' command in PATH" を1回実行）。

💾 保存は Ctrl + S（Mac は Cmd + S） 今後数百回使う操作です。指に覚えさせましょう。編集するファイルは数個だけ。初日に全部覚えようとしない のが一番速い学び方。

② 左サイドバーにファイル一覧が表示されるのを確認

数十個のファイルが並びますが、この章で触るのはたった2つ だけ。残りは放置でOKです。

App.jsx ← 主役　App.css ← 見た目 その他 ← 触らない・編集禁止

左サイドバーに src/App.jsx が見えていればSTEP 3は完了。ここからAIに指示を出す段階へ。

STEP 4 — プロンプトの3要素を知る

これから書くプロンプトの設計図です。3点を押さえるだけで戻ってくる成果物の質が一段上がります。

AIへの指示文を プロンプト と呼びます。社内で仕事を外注するときと同じで、"何を・どんな内容で・どう見せたいか" の3点が揃っていると一発で期待通りに近づきます。

ページの種類や主な用途。業務発注でいう "背景と目的"。 「新人歓迎向けに、営業企画部のチーム紹介ページを作りたい」 具体的な文面や項目。固有名詞・数字までそのまま渡す。 「メンバー3名（氏名・役職・担当領域・社内連絡先）と部のミッション1文」 色・レイアウト・雰囲気。参考URLや社内ブランドカラーを添えても良い。 「コーポレートブルー基調、カード3枚横並び、余白多めで落ち着いた印象に」

💡 最初は "1と2" だけで十分 見た目の指定は後から修正指示で磨けます。まず目的と内容だけで1本出し、結果を見てから細部を整えるのが最短ルート。3つ目が空でも、AIが妥当な初期デザインを選んで出してきます。 🗣 業務発注メールと同じ構造 件名＝何を／本文＝内容と見た目／末尾に「不明な点は質問してください」を添えるのと同じ。プロンプトが書けるようになるのは、発注が上手くなるのと同義 です。

STEP 5 — プロンプト雛形を《》だけ書き換える

1から文章を書かなくてOK。雛形の《》部分だけ自分の情報に書き換えれば完成です。

① 以下の雛形を丸ごとコピー

以下の内容で社内向けチーム紹介ページを作ってください。 src/App.jsx にメインコード、src/App.css にスタイルを書いてください。

・用途: 《新人歓迎資料／社内ポータル掲載》 ・部署名: 《営業企画部》 ・チームミッション: 《顧客の声を起点に、全社の打ち手を翌週までに実装する》 ・メンバー（3名）:

1. 《田中 一郎／部長／戦略立案／@tanaka》
2. 《佐藤 次郎／マネージャー／営業推進／@sato》
3. 《鈴木 三郎／メンバー／データ分析／@suzuki》

・デザイン: コーポレートブルー基調、カード3枚横並び、余白多めで読みやすく ・全体的にすっきりした社内ポータル風に仕上げてください ・出力・コメント・説明文はすべて日本語で

② 黄色い《 》の部分だけ、自部署の情報に書き換える

部署名・メンバー名・連絡先などを自分の情報に差し替えます。メンバーは3名でなくても構いません（4〜5名に増やしてもOK）。ダミーデータでも練習になります。

📋 コピー時のコツ／⚠️ 本番公開前は個人情報に注意 黄色い《 》ごとまずコピペし、《 》の中だけ自分の情報に書き換えればOK。雛形は保存すれば別部署にも再利用可。社外公開予定があるなら Slack ID や内線番号は伏字に。エディタに用意できたらSTEP 5完了、次は実際にAIへ。

STEP 6 — AIに送信＆ブラウザで結果を確認

この章で一番ドキドキする瞬間。あなたの指示が実際のWebページに変わります。

① 使っているAIの種類に合わせて送信

🤖 コーディングAI の場合

1. VS Code のターミナルで ch02 フォルダにいることを確認
2. Claude Code / Codex / Gemini CLI を起動
3. 書き換えたプロンプトを貼り付けて Enter

AIがファイルを直接編集・保存。Ctrl+S 不要 で、STEP 1で起動したサーバーが自動でブラウザに反映します。

💬 チャットAI の場合

1. ブラウザ版 ChatGPT / Claude を開く
2. 書き換えたプロンプトを貼り付けて送信
3. AI の出力 App.jsx と App.css を VS Code に貼り付けて上書き保存

貼り付け後に Ctrl+S（Cmd+S） で保存するのを忘れずに。

🔐 「Do you want to overwrite ...?」と聞かれたら（コーディングAI）

Claude Code 等はファイル編集のたびに許可を求めます。基本は 1. Yes でOK。毎回の確認が煩わしくなったら 2. Yes, allow all edits during this session でセッション中は自動許可。内容を確認しながら進めたい間は 1 推奨。3. No を選ぶと編集が中止されます。

AI の応答が終わったら、次のページでブラウザの表示を確認します。

🖥 コーディングAI（Claude Code）にプロンプトを貼り付けた直後の画面例

ターミナル上部に Claude Code のウェルカム画面、下部に貼り付けたプロンプトが表示されています。Enter を押すと AI がファイル編集を開始します。初回は30秒〜1分ほどかかることがありますが、ターミナルに文字が流れている間は処理中なので途中で閉じないでください。完了すると「何を変更したか」の要約が表示されます。

AI が「Done」等の完了メッセージを表示したら、ブラウザで `http:

*② ブラウザで `http:

Vite の初期画面（STEP 2 で見た React ロゴ）が 自部署のチーム紹介ページに変わっている はず。書き換わっていなければ、ブラウザを手動でリロード（Cmd+R / Ctrl+R）。

出力例：営業企画部のチーム紹介ページ。プロンプトに書いた部署名・ミッション・メンバー3名がそのまま反映されている

🎉 AI時代の第一歩 — 自分の部署名・同僚の名前が並んだページがブラウザに表示されたら、その画面をスクリーンショットで保存 してください（Win: Win + Shift + S ／ Mac: Cmd + Shift + 4）。「自分の指示でWebページが動いた」最初の証拠として、今後の学習の励みになります。

💡 英語で返ってきたら プロンプト末尾に「出力・説明文はすべて日本語で」を追記して再送信。色味や配置が微妙でも落ち込まず、PART C で磨きます。「自部署仕様のベース版」ができていれば合格。

HMR（ホットリロード）の正体 — 体験した仕組みを理解する

STEP 6 でファイルが保存された瞬間にブラウザが書き換わったのは、HMR という仕組みのおかげ

npm run dev で起動した dev server は、ファイルの変更を常に見張っていて、保存されると即座にブラウザへ反映します。これを HMR（Hot Module Replacement／ホットリロード） と呼びます。本書ではこの章以降「HMR（ホットリロード）」と略記。

従来の流れ

ファイルを編集 → 保存 → ブラウザで手動リロード → ようやく反映

確認のたびに毎回リロード操作

→

HMR（ホットリロード）のある流れ

ファイルを編集 → 保存 → ブラウザが自動で書き換わる

指示→確認のサイクルが秒単位に

🔁 これから何度も回すサイクル

AIに依頼 → ファイルが更新・保存される（コーディングAIは自動／チャットAIは貼り付け→Ctrl+S）→ HMRでブラウザ反映 → 目で確認 → 修正依頼。この数秒で1周するループが、AI時代の開発速度の正体です。会議でホワイトボードを描きながら議論するのと同じテンポ。

💡 画面が更新されないときは ① ファイルが保存されているか（チャットAIで手貼りした場合は Ctrl+S を確認）／ ② ターミナルに赤文字エラーが出ていないか／ ③ ブラウザのアドレスが http: 🛑 dev server の止め方・再起動 ターミナルで Ctrl + Cを押せば停止。次に使うフォルダにcdしてから再度npm run dev` を実行。複数プロジェクトを同時に立ち上げるとポートが衝突するので注意。

プロジェクトフォルダの地図 — 主役は src/App.jsx

STEP 3 で確認したファイル構成を、拡張子の意味とセットで把握する

拡張子で "役割" を見分ける

拡張子 この章で触る？ 役割 .jsx ◎ メイン 画面の中身（チーム紹介の文面とレイアウト） .css ◯ 補助 見た目の指定（色・余白・フォントサイズ） .html △ ほぼ触らない Webページの土台の箱 .json ✕ 触らない プロジェクト設定ファイル

封筒の表に「請求書在中」と書くのと同じで、拡張子は中身の種類をコンピュータに伝える目印です。

🧭 "触らないファイル" に動じない

node_modules/ や vite.config.js は自動管理。初日に全部覚えようとせず、必要になったら調べる が一番速い学び方です。業務のExcelで言う隠しシートやマクロと同じ扱い。

📁 ch02/ の中身（抜粋）

src/ ├─ App.jsx ← 主役 ├─ App.css ← 見た目 └─ main.jsx ← 触らない index.html ← ほぼ触らない package.json ← 触らない node_modules/ ← 絶対に触らない

🔍 触りたい場所の探し方 VS Code で Cmd + F（Mac）／ Ctrl + F（Win）で検索。変えたい文字列（例：「営業企画部」）を入力すれば、該当箇所へジャンプ。そこが "触るべき場所" です。

💾 保存の習慣 手動でコードを貼り付けた場合は必ず Ctrl + S。コーディングAIを使っている場合は自動保存。

対話サイクル — 磨き込みの基本リズム

「一発で完成」ではなく「4ステップを何周か回す」

STEP 6 までで "自部署仕様のベース版" が完成しました。ここからは 差分指示 で少しずつ磨きます。その基本リズムが以下の4ステップです。

変えたい場所と変更内容を、具体的に1文で伝える src/App.jsx と src/App.css が自動で更新・保存される dev server が変更を検知し、ブラウザ画面が自動で書き換わる 「ここだけ直して」と具体的に指示し、01に戻る

💡 業務との対応

開発サイクル 業務の型 相談 要件のすり合わせ 生成 ドラフト納品 反映 関係者への共有 差分依頼 レビュー・差し戻し

🔁 このリズムは今後全章で再利用 第3章以降の機能追加・API連携も、同じ4ステップ。開発＝対話 へ頭を切り替える。

❌ NG 1周目で完璧を狙いプロンプトを推敲し続ける

💡 代替 60点の下書きを10分で出し、3周で80点を狙う

✅ 合格 1周5分以内。違和感を指示文に翻訳できる

STEP 7 — 差分指示を1回出してみる

1箇所だけ変更する指示を出し、HMRでブラウザに反映される様子を確認します。

① 次のプロンプトをコピー（数値や色は自由に変えてOK）

src/App.css のメンバーカード（カード3枚のやつ）の 背景色だけ を `` に変えてください。 それ以外のデザインは そのまま にしてください。

② AIに送信する

STEP 6 と同じ方法で送信（コーディングAIならターミナルに貼り付け、チャットAIなら出力を App.css に貼り付けて保存）。

③ ブラウザに戻って変化を確認する

`http:

🎉 サイクル1周目完了 これが "磨く" の正体。あとは この粒度の指示を何本も積み重ねる だけで、社内ポータル品質に近づきます。

💡 次は何を変えてみる？ ・メンバー名の文字色を濃紺に／・カード内の役職を太字に／・部署名の上に会社ロゴの絵文字を追加 — 1つずつ指示に変換してみましょう。

✅ できたらOK ― ブラウザで変更が反映され、他のデザインが崩れていなければSTEP 7は完了。全7ステップ達成。同じサイクルを繰り返すだけで仕上がります。

イテレーティブ・リファインメント — 差分指示の書き方

1回で完璧を目指さず、少しずつ磨く技術

"Iterative Refinement（反復的な改善）" はプロの開発者が毎日使うテクニック。下書き → レビュー → 修正 → 完成 の順で仕上げるのと同じで、差分指示にもコツがあります。

差分指示の書き方 — NG → OK

もっとおしゃれにして カードの角を8px丸め、背景をホワイト→ のグラデーションに 形・色・数値を具体化すると差し戻しが1回で済む

全部作り直して メンバーカード内の役職だけ太字に。他はそのままで 変更範囲を1箇所に絞ると、AIが暴走して全体が崩れない

レイアウト変えて カード3枚の横並びを縦並びに変更。スマホで見ることを想定 意図（スマホ対応）を添えると、自動でレスポンシブ調整が入る

🧭 差分指示 3つのコツ

① 範囲を絞る 「名前の色だけ赤に」と言い切る ② 数値で示す 「16px」「#4a7dff」のように単位付きで ③ 不変を明記 「それ以外はそのまま」を添えると保険になる

💡 1周目は "6割" で止める勇気 「気になる差分」を1〜2箇所抽出して2周目へ。議事録を書くときも、下書き→加筆→調整で仕上げるのと同じリズム。3周で80点を目指せばOK。

AIの出力を読むコツ — "触る場所" を見つける

全部理解しなくていい — "どこを触れば何が変わるか" が分かれば十分

AIが生成したコードは最初は記号の海に見えます。でも業務で他人のExcelマクロを読むときと同じで、"自分が変えたい場所" の周辺だけ見ればOKです。

🗺 App.jsx の地図

・冒頭の import 文 → 使う部品の宣言（読み飛ばしてOK） ・関数 App() の中が 画面に表示されるもの ・return( ... ) の中にHTMLのようなタグが並ぶ ・className="..." は App.css 側のデザインと連動

🎨 App.css の地図

・.xxx { ... } のブロック1つが "ある要素のデザイン" ・color: → 文字色、background: → 背景色 ・padding:／margin: → 内側／外側の余白 ・font-size: → 文字サイズ

🔍 修正したい場所の見つけ方

1. VS Code で Cmd+F（Mac）／Ctrl+F（Win）で検索
2. 変えたい文字列（例：「営業企画部」）を入力
3. その周辺のコードが "触るべき場所"

💡 目星をつけてAIに投げる 「App.jsx のメンバーカード付近の余白を詰めて」のように、場所と変更内容をペアで伝える と一発で反映されます。HTMLタグやCSSプロパティの詳細は 補講 にまとめてあります。

よく触る3プロパティだけ覚える

🎨 色を変える

color: 文字色 background: 背景色

例：「メンバー名の color を #4a7dff に」

📏 余白を調整

padding: 内側の余白 margin: 外側の余白

例：「カードの padding を 24px に」

🔠 文字サイズ

font-size: font-weight: 太さ

例：「役職の font-size を 14px に」

ハルシネーション — AIの自信満々な間違い

AIの出力は優秀な部下のドラフト。最終確認は必ず自分の目で

AIは時として、もっともらしく見えて実は間違っている情報を返します。これを ハルシネーション（幻覚） と呼びます。業務でも新人が自信ありげに誤った報告を上げることがあります。確認役は人間側の仕事です。

よくあるハルシネーション3パターン

パターン 概要 存在しないCSSプロパティ "それっぽい名前" を勝手に作る 存在しないReactフック useXxx と "ありそうな名前" を出すが実在しない 実在しないURL・ライブラリ Google Fontsやパッケージ名を架空で生成

😱 AIが自信満々に返す実例（動かない）

import { useFetchData } from 'react'; const data = useFetchData('/api/members');

useFetchData は React の標準機能には存在しません。実行すると即エラー。「AIが言うから」ではなく「ブラウザで動いたから」を判断基準に。

⚠️ 怖いのは "見た目がそれっぽい" こと 構文エラーなら即気づけますが、リンク切れ や レイアウト崩れ は「動いているように見える」ので、目視確認を怠ると社内公開後に指摘されます。

3段階の確認フロー

レイアウトが崩れていないか／文字が切れていないか リンクがある場合はクリックし、404が出ないか確認 "このコードで〇〇が動きません。原因は？" と3点セット（エラー文／発生箇所／該当コード）で再依頼

🔎 裏取りに使える検索 AIが書いた CSS の単語（例：background-color）が本物か確かめたいときは、検索エンジンに background-color MDN のように "単語 + MDN" を入れて検索。MDN は Web標準の公式辞書サイト で、上位ヒットの mdn.mozilla.org が信頼できる答えです。

まとめ — この章で持ち帰る4つの型

30日講座の2歩目として、AIと対話してWebページを1本作り切る 経験をしました。この章で身についたのは単なる React の入口ではなく、今後の業務すべてに効く4つの型です。

・新規案件は npm create vite@latest 1コマンド＋対話で完走 ・主役は src/App.jsx と src/App.css ・HMRで保存即ブラウザ反映

・何を・どんな内容で・どんな見た目に ・雛形をコピペして《 》の中身だけ差し替え ・最初は目的＋内容の2つだけでもOK

・1発完成を狙わず、差分指示を重ねる ・範囲は絞る／数値で示す／不変を明記 ・1指示1変更でAIの暴走を防ぐ

・必ずブラウザで目視とリンク動作確認 ・怪しいコードは3点セットでAIに聞き直す ・MDN等の公式で裏取りする習慣を

🔮 次回予告 — 第3章

この章で作ったチーム紹介ページに 社内ブランドカラー や チーム写真 を取り込み、社内標準に寄せたデザインに磨き込みます。画像生成AIも絡めて、外注していた "見栄え仕事" を自分で回せるところまで進めます。

📚 深掘りは補講へ supplements/ の補講にHTML/CSS用語集、JSXとHTMLの違い、プロンプトのストック習慣、ブラウザの描画プロセスまで。気になった用語だけ引けばOK。

よくあるトラブル Q&A

cd ch02 で作業フォルダに移動できているか／npm install が最後まで走ったかをまずチェック。 「npm run dev 実行時に次のエラーが出ました。原因と対処を教えてください。（エラー文を貼る）」 プロンプト末尾に「日本語で回答し、コードコメントも日本語にしてください」と追加。毎回この1行を雛形に入れておくのが楽です。 「出力・コメント・説明文はすべて日本語で。固有名詞は原文のままで構いません」 ブラウザのコンソールやターミナルのエラー文を、3点セット（エラー文／発生時の操作／該当コード）でAIに伝えれば、ほとんどのケースで原因特定・修正してくれます。 「次のエラーが出ました: (エラー文)／操作: (何をしたか)／コード: (該当箇所を貼る)」 「全部作り直して」ではなく、差分指示（「カードの余白だけ16pxに」）で1箇所ずつ直す。変えたくない部分は「それ以外はそのまま」と明記。 "デザインを変えて" → "メンバーカードの背景色だけ #eef2ff にして、他はそのまま"

🆘 ここに載っていない症状は エラー文や症状をそのままAIに投げるのが最短。解決できなかった症状はプロンプトと一緒にメモ帳へストックしておくと、同じ壁に二度ぶつからずに済みます。

はじめる前に（前提確認）

npm run dev 実行直後のターミナル表示例

📌 この章のスタート地点

第2章で作ったプロジェクト ch02 を VS Code で開き、 ターミナルで npm run dev を起動した状態から始めます。 ブラウザで `http:

※ まだ起動していない方は、ch02 を VS Code で開き、ターミナルで npm run dev を実行してください。

本章での使い方

本章では、この ch02 プロジェクトの src/App.jsx と src/App.css を 「プロジェクト成果共有ページ」に仕立て直していきます。 すべての手順は npm run dev 起動中のブラウザに 即座に反映される 前提です。

よくあるつまずき

・ブラウザに何も出ない → ターミナルに赤字エラーが出ていないか確認 ・表示が崩れた → VS Code で Ctrl + Z（Mac は Cmd + Z）で取り消し。複数手順前なら AI に「直前の状態に戻して」と依頼 ・どの CSS が効いているか分からない → 「ブラウザの開発者ツールで確認する」セクションへ（P.

CSS 用語ミニ辞書 — 1行でざっくり把握

用語 ざっくり理解 レスポンシブ 端末幅ごとに見せ方を変える — A4／スライド版の切替 モバイルファースト スマホ幅から先に組み、PC幅へ広げる設計順 ヘッダー ページ上部の帯 — ロゴやメニューを配置する場所 ナビ 画面上部や横のメニュー — ナビゲーションの略 カラム 縦の段組み — 1カラム＝1列、3カラム＝3列 アイキャッチ 目を引く挿絵・バナー画像 — 記事冒頭やカード上部 メディアクエリ 画面サイズや表示条件に応じてCSSを切り替える機能 Flexbox 横1列・縦1列の並びを整える — 名刺を横一列に Grid 表のようなマス目に配置 — 座席表・カレンダー DevTools Chrome 開発者ツールの略 — ブラウザ標準の検証パネル @media 「◯px のとき」だけ CSS を適用する条件分岐 min-width: 768px 画面が 768px "以上" のとき適用（広い方） max-width: 480px 画面が 480px "以下" のとき適用（狭い方） object-fit 画像をトリミングして枠に合わせる — 写真のリサイズ position: sticky スクロール中も見出しが貼り付く — Excel の行固定

この章のゴール

プロジェクト成果共有ページを "見せられる品質" まで引き上げる

前章で組み上げた社内向けページを、PC／スマホのどちらで開かれても読める品質に磨きます。 本章で作るのは 「プロジェクト成果共有ページ」。 四半期の成果・導入事例・メンバー紹介を1ページにまとめ、 社内ポータルや Slack でリンクが共有されても崩れない状態を目指します。

この章でできるようになる4つのこと

1. 画面幅に応じてレイアウトが自動で組み替わる レスポンシブ対応
2. スクロールに合わせて要素が ふわっと現れる アニメーション／画面上部に 常に表示されるヘッダー
3. 画像生成 AI でヒーロー画像・ロゴ・アイコンを 自分たちで作る
4. Chrome の 開発者ツール で実際の表示を確認しながら微調整

本章で使う2種の AI

デザイン部：画像生成 AI ヒーロー画像・ロゴ・アイコンを短時間で生成する。

技術部：コーディング AI CSS・アニメーション・配置をコードに落とす。

本章では、この2部門のアウトプットを自分1人で回す練習をします。

この章で作るもの：プロジェクト成果共有ページ

章の指示例・プロンプト例はすべてこのページを想定して書かれています。 自分の部署の実際のプロジェクトに差し替えながら読み進めてください。

レスポンシブデザインとは？

画面幅で "見せ方" を切り替える仕組み

プロジェクト成果共有ページは、PC で見ることもあれば、 スマホで開くこともあります。 どの端末でも崩れず読める状態を作るのがレスポンシブデザインです。

端末幅に合わせて見せ方を切り替えるルールを メディアクエリ と呼びます。 「画面幅が◯◯ px 以下のときだけ、このスタイルを適用する」と CSS に書き込みます。 会議室のプロジェクタ解像度に応じて資料のレイアウトを差し替えるのと同じ発想です。

業務シーン別 — 想定される閲覧端末

区分 想定幅 業務シーン スマホ ～480px 営業メンバーが移動中に共有 URL を確認 タブレット ～768px 会議室での投影、役員のサッと閲覧 PC 769px以上 本社デスクでの詳細レビュー

📱 スマホ（～480px）

1カラム縦積み／ナビを縦並び／本文フォント 14〜15px／画像は画面幅いっぱい

📲 タブレット（～768px）

2カラム／ヘッダーはロゴ＋メニュー／画像は 50% 幅／余白を詰める

💻 PC（769px以上）

3カラムや横並びカード／サイドナビ表示／最大幅 1200px で中央寄せ

PC だけで見栄えを整えてスマホ確認を後回しにすると、共有後に「文字がはみ出して読めない」とフィードバックが返ってきます。 プロジェクト成果共有ページの確認は必ず スマホ幅 → PC 幅の順 で行いましょう。

AIにスマホ対応を指示する

プロンプト雛形（コピペして末尾を書き換え）

あなたはフロントエンドエンジニアです。 このプロジェクトの src/App.jsx と src/App.css を、以下の3段階でレスポンシブ対応してください。

・スマホ（～480px）：1カラム、ナビは縦並び、画像は width 100% ・タブレット（481〜768px）：2カラム、ヘッダーはロゴ＋縦3点メニュー ・PC（769px以上）：3カラム、最大幅 1200px で中央寄せ

既存の配色・フォントは変更しないでください。 変更した行だけ、なぜ変更したかを1行コメントで残してください。 App.jsx に該当セクションがなければ追加し、ヒーロー画像は横長バナー型（高さ最大 320px）で表示してください。

【対象ページ】（↓ 自分の職場の状況に書き換え） 四半期のプロジェクト成果共有ページ。ヒーロー画像 ＋ 成果サマリ ＋ メンバー紹介 ＋ 導入事例の4セクション構成。

末尾の【対象ページ】だけを自分の業務資料の構成に書き換えれば、同じ雛形を何度でも使い回せます。

📎 「添付」「このファイル」の扱い方 ・コーディング AI（Claude Code・Codex・Gemini CLI 等）：プロジェクトを開いていればファイルを自動で読む。パスを伝えるだけで OK。 ・チャット AI（ChatGPT・Gemini 等）：src/App.jsx と src/App.css の 中身をコピペして貼り付ける 必要あり。

業務フロー対応

この「幅ごとに分岐して指示する」パターンは、業務マニュアルや社内ダッシュボードを作るときにもそのまま流用できます。 このプロンプトを 自分のメモ帳などにコピペで保存 しておき、次回からは【対象ページ】の部分だけ書き換えれば再利用できます。

プロンプトを実行して結果を確認する

Step 1：AI に貼り付けて実行

Claude Code にプロンプトを貼り付けた状態。 【対象ページ】 だけ自部署の構成に書き換える。

実行手順

1. プロンプトをコピーし、【対象ページ】 を自部署の状況に書き換え
2. AI（Claude Code・ChatGPT 等）に貼り付けて Enter／送信
3. ブラウザで `http:

🔐 「Do you want to ...?」と聞かれたら

実行中に 1. Yes ／ 2. Yes, allow all ／ 3. No が出たら、基本は 1. Yes で OK。確認が煩わしくなったら 2 でセッション中自動許可、3 で編集中止。応答に「ビルド完了」が出れば成功。

Step 2：実行前と実行後を見比べる

Before：第2章終了時（チーム紹介の1セクション）

After：4セクション構成＋PC／タブレット／スマホで表示が自動で切り替わる

主な変化点 — ヒーロー画像／成果サマリ／導入事例が新設され、4セクション構成に整理されました。PC／タブレット／スマホで表示が自動で切り替わる CSS も組み込まれました。ヒーロー画像は仮置きで、本章後半で AI 生成画像に差し替えるため、第2章の結果に応じて細部が異なっていても大丈夫です。

モバイルファーストの考え方

業務資料・社内ページもスマホで開かれる時代。プロは「狭い画面で何を見せるか」から設計する — これが モバイルファースト です。 スマホ幅で 最初に見える3つ に何を置くかが、情報設計そのものになります。

モバイルファーストとは

プロの Web 制作では、スマホ用レイアウトを先に組み、画面が広がるほど要素を追加していく順番で設計します。 PC で詰め込んだ情報をスマホで縮める発想ではなく、狭い画面で本当に必要な要素だけを選び抜く ことから始めるのが特徴です。

この設計順で得られる効果

観点 効果 情報設計 本当に伝えたい3点が研ぎ澄まされる SEO Google はスマホ版を基準に評価 保守性 追加分岐が少なく、CSS が短く保てる

💡 "最初の3つ" の重要性 スマホ画面に置けない要素は、社内資料の "別紙" や "付録" に相当します。 何を3つに絞るかが、ページ全体の評価を決めます。

業務資料との対応

どの業務媒体も「冒頭の3つの要素」で読まれるかどうかが決まります。スマホ画面の制約は、業務文書の優先順位付けと同じ訓練になります。

業務媒体 "最初の3つ" の中身 プロジェクト報告書 タイトル／結論／重要数値 提案書（エグサマ） 課題／提案／ROI Slack・Teams 投稿 結論／根拠／依頼 社内ダッシュボード 主要KPI／前期比／要因 成果共有ページ ヒーロー画像／成果サマリ／メンバー

❌ NG：PCファースト

PC 版で詰め込んだ情報をスマホで縮める発想。 縮めた結果、文字が小さくなり見出しが潰れる。

✅ OK：モバイルファースト

スマホで伝えるべき3点を決めてから PC 版で補足情報を足す。 情報の優先順位がそのまま設計に反映される。

視線を誘導する3つのアニメーション

成果共有ページに "視線の動線" を作る

成果共有ページは、読み手の視線を「ヒーロー画像 → 成果サマリ → メンバー → 導入事例」と順に誘導できるほど伝わりやすくなります。 動きを足すのは装飾のためではなく、読んでほしい順序を伝えるため です。

スクロールに合わせて要素をふわっと表示し、読み手のテンポを整える 「成果サマリ → 導入事例」の順に、下から 0.5 秒で順次登場させる 長いページでも現在地が分かるよう、ナビを画面上部に固定する メンバー・導入事例の長いスクロール中もヘッダーからトップへ戻れるようにする スクロール時に背景画像だけをゆっくり動かして奥行きを演出する ヒーロー画像（プロジェクトのメインビジュアル）にだけ控えめに適用

💡 動きは "主役" にだけ付ける

全部の要素をアニメーションさせると、肝心の数字や結論が埋もれます。 成果共有ページなら 成果サマリと導入事例だけ に動きを付け、 それ以外は静かにしておくと、読み手の注意が自然と主役に向かいます。

制約条件をプロンプトに含める

「やってほしくないこと」を明示する

プロンプトに入れる要素のうち、一番忘れられやすいのが 制約条件 です。 次ページのアニメーション指示でも実際に活用しますが、 業務資料（提案書・報告書・社内ページ等）で最も効くのは「触ってほしくない範囲」を先に宣言することです。

4種の制約 — プロジェクト成果共有ページで実際に効いたもの

種類 用途 プロンプト例 数値制約 サイズ・時間・回数の上限 「アニメーションは 0.3 〜 0.6 秒」「画像の最大幅は 960px」 否定制約 やらせない事項を宣言 「JavaScript ライブラリは追加しない」「配色は変更しない」 品質制約 守るべき非機能要件 「LCP が 2 秒を超えないように」「キーボード操作で全メニューに到達できるように」 範囲制約 変更箇所の限定 「ヘッダーと導入事例だけ修正。メンバー紹介セクションは触らない」

練習：制約を足していく

BEFORE — 制約なし

フェードインを追加してください

AFTER — 制約4点追加

成果サマリと導入事例にフェードインを追加。 ・秒数は 0.3〜0.6 秒 [数値] ・ヘッダーには付けない [否定] ・既存レイアウトは崩さない [品質] ・その他のセクションは触らない [範囲]

制約が効く場面

・既存資料の 一部分だけを直したい とき ・社内で決まった 見た目（色・フォント）を変えたくない とき ・同僚と 別の箇所を分担編集中 のとき ・「派手すぎて報告に使えない」を事前に防ぎたいとき

💡 Tips：制約は「先に」書く

プロンプトの末尾に制約を書くと AI が忘れやすい。 冒頭で「以下の制約を必ず守ってください」と宣言してから本題に入ると、出力が安定します。

AIにアニメーションを指示する

プロンプト雛形（コピペ可）

あなたはフロントエンドエンジニアです。

【制約】以下を必ず守ってください ・アニメーション時間は 0.3〜0.6 秒の範囲 ・ヘッダー自体にはフェードインをかけない ・既存の配色・レイアウトは崩さない ・CSS は src/App.css にまとめ、変更箇所に日本語コメント

【依頼】以下のアニメーションをプロジェクト成果共有ページに追加してください

1. ヘッダーを position: sticky でページ上部に固定
2. 成果サマリと導入事例セクションを IntersectionObserver で検知し、下から 20px ＋ opacity: 0 → 1 で 0.5 秒フェードイン
3. ヒーロー画像のみ、スクロール量に応じた 0.6 倍速のパララックス

💡 数値は「目で確認できる範囲」で書く 倍速 は画像の動く速さの比率（0.6 = スクロールの 60% の速さで動く）。本番のサイトは 0.2〜0.3 で控えめな奥行き感、動作検証は 0.5〜0.7 にすると目視で確認しやすい動きになります。

AIに伝わる4つのコツ（第2章の復習）

・数値で揃える：秒数・px 値は幅で指定 ・感覚語を添える：「ふわっと」「控えめに」 ・対象を限定：どのセクションに付けるか明記 ・NG を書く：やらないでほしいことを先に伝える

崩れたら段階を刻む

雛形のように一度に依頼するのが基本ですが、出力が崩れたら 1つだけ依頼 に戻して切り分けます。 ヘッダー固定 → 動作確認 → フェードイン → 動作確認 … と分割すれば、どの指示で崩れたか特定できます。

🧙 "呪文" で OK の用語 IntersectionObserver は、AIがプロンプトに組み込む JavaScript の仕組みで、画面に入ってきた要素を検知します。第4章以降で詳しく扱う ので、今は AI に渡す呪文として書くだけで十分です。

いい感じに動かして 成果サマリと導入事例を、下から 20px ＋ opacity: 0 → 1 で 0.5秒フェードイン 対象を特定し、距離・透明度・秒数を数値で指定

ヘッダーを目立たせて ヘッダーを position: sticky でページ上部に固定 曖昧な動詞をCSSの具体的な指定に変換する

アニメーションの結果を確認する

動作チェックリスト

□ ヘッダーがスクロール中も上部に張り付くか □ 成果サマリが画面に入ると下からフェードインするか □ 導入事例も同じ動きで現れるか □ ヒーロー画像が他より遅れて動くか □ ヘッダー自体は動かない（最初から表示）か □ 配色・レイアウトが変わっていないか

確認手順

1. ブラウザで `http:
2. ページ上部から ゆっくり下にスクロール
3. 各セクションが画面に入る瞬間を観察
4. 上下にスクロールしてヘッダー追随を確認

💡 「動いた瞬間」を見逃したら

フェードインは 一度きり の動き。再確認するには ページを再読み込み（F5 または Ctrl + R）してからスクロールすると最初からやり直せます。

うまく動かないとき — 症状から原因を特定

症状 確認ポイント 全くフェードインしない ページを再読み込みしても動かなければ AI に「動かない」と伝えて再依頼 全要素が同時に動く 対象セクションの指定を AI に再依頼 ヘッダーが消える 親要素に overflow: hidden がないか ヘッダーがふわっと現れる 雛形の制約を再度伝えて修正依頼 パララックスが分からない 画像とテキストを同じ画面に入れて比較

パララックスが分かりにくい場合

0.6 倍速は スクロールの 60% で画像が動く設定。100px スクロールしたら画像は 60px 動きます。

確認のコツ

1. ヒーロー画像と直下のテキストを 同じ画面 に入れる
2. ゆっくりスクロール → テキストは普通の速度／画像は遅れて動けば OK

完成イメージ — 動作対象の確認

ここまでの指示で、以下の4つのアニメーションがページに組み込まれています。ブラウザでスクロールしながら、それぞれの動きを確認してください。

① ヘッダー → 画面上部に張り付く（固定）

② ヒーロー画像 → 60% の速度で動く（パララックス）

③ 成果サマリ → 下から現れる（フェードイン）

④ 導入事例 → 下から現れる（フェードイン）

✅ 全部動いていれば、アニメーション実装は完了です。

動かない箇所がある場合は、前ページのトラブルシューティング表を参照してください。

マルチモーダルAIとは？

AI が扱える入出力の種類は広がっている

プロンプトはテキストだけではなくなりました。 テキスト・画像・音声・動画 など 複数の種類を組み合わせて 扱える AI を マルチモーダル AI と呼びます。 現場では、文字起こし・画像生成・動画要約が一般業務のツールとして定着しつつあり、本章では 成果共有ページのロゴ・ヒーロー画像・アイコン を AI 画像生成で 自分で作ります。

入出力の種類一覧 — 何を入力できて何が出てくるか

種類 入力できる 出力できる テキスト 指示文・文書 文章／コード／翻訳 画像 写真・スクリーンショット・図 ロゴ／イラスト／写真風 音声 会議録音 文字起こし／ナレーション 動画 録画素材 要約／短編映像

本章で実際に使う入出力

🖼️ 入力

テキスト（プロンプト）＋ 画像（参考デザイン）

🎨 出力

画像（ロゴ・メイン画像・アイコン）

🔀 連携

コーディング AI に「この画像を配置して」と渡す

マルチモーダル AI の便利さは、社内にある資料をそのまま AI に渡せる こと。 例：過去の報告スライドや議事録のスクリーンショットを AI に見せれば、社内の見た目（色・フォント）に揃った 新しい資料を AI が作ってくれます。

使える画像生成AIツール

💬 ChatGPT（DALL-E）

chatgpt.com

普段の会話の流れで画像を生成。 文字指示と参考画像の添付を同じチャット内で混ぜられる。

無料枠：あり（回数制限付き）／ 商用利用：規約範囲内で可

おすすめ：ChatGPT に慣れている人の第一歩

💎 Gemini

gemini.google.com/app

会話しながら画像を生成・修正。 文章指示と画像添付を同じチャット内で混ぜられる。

無料枠：あり（上位は有料プラン）／ 商用利用：プラン・地域により条件あり

おすすめ：参考デザインを渡して雰囲気を合わせたいとき

🎨 Adobe Firefly

firefly.adobe.com

Adobe Stock の学習データで 商用利用に強い。 Photoshop など Adobe ツールとも連携できる。

無料枠：あり（生成クレジット制）／ 商用利用：商用利用可（公式が明示）

おすすめ：法務・著作権リスクを下げたいとき

✨ Midjourney

midjourney.com

アート性・デザイン性に定評。 印象的なヒーロー画像を作るならここ。

無料枠：なし（月額 10 USD〜）／ 商用利用：有料プランで可（条件あり）

おすすめ：対外公開も見据えた高品質素材が要るとき

選び方の目安

・社内資料（議事録の挿絵、社内ページなど）を素早く作る → ChatGPT か Gemini ・著作権の安全性 を最優先（法務確認が必要な場面） → Adobe Firefly ・対外公開する高品質な画像（広報資料・公式サイト） → Midjourney

試す手順：まず1つを選び、言い方を変えて3〜5回 プロンプトを試してみて、求める結果が出にくい場合は、別のツールに切り替える。

AI画像生成のプロンプト術

「電話で絵を発注する」つもりで言葉にする

画像生成 AI は、コーディング AI 以上に 数値（サイズ・カラーコード）と具体的な名前（フォント名・画風名） で結果が大きく変わります。 成果共有ページ用のロゴやヒーロー画像を作るときも、色・画風・背景をできるだけ具体的に指定するほど、イメージ通りの仕上がりに近づきます。

指定するとよい4つの観点

観点 指定の例 色 「ネイビー #1e3a8a とアンバー `` を基調」 背景 「白背景」「透明背景」「淡い青のグラデーション」 雰囲気 「落ち着いた高級感」「テック企業の信頼感」 画風 「フラットデザイン」「アイソメトリック（斜め俯瞰の立体図）」

NG → OK 書き換え

❌ NG

「ロゴを作って」

✅ OK

「社内プロジェクト "NEXTSHIP" のロゴ。 ネイビーとアンバーを基調、フラットデザイン、 白背景、正方形 512×512px」

反復して磨く流れ（リファインメント）

1. 最初の生成 → 3〜4案並べる
2. 方向性の近い1案を選ぶ
3. 「もう少し暗めに」「アンバーを強めに」と修正指示
4. 目線・装飾を整えて完成

一発で完璧は出ません。 "3回試す前提" で予算（時間）を確保しておきましょう。

社内利用時の注意

⚠️ 著作権と利用規約を必ず確認

実在の人物名・ブランド名を入れない／生成物の商用利用可否はツールごとに異なる／社内規定がある場合は広報法務に確認してから公開する。

画像生成 AI を実行する流れ

画像生成 AI は初めてだと操作の流れが分かりにくいもの。Gemini を例に、プロンプト入力 → 生成 → 再試行 → ダウンロード の 5 ステップで紹介します。

前々ページの 画像生成 AI ツール（ChatGPT・Gemini・Adobe Firefly・Midjourney）から 1 つ選び、ブラウザで開きます。本例では Gemini を使用。

前ページのプロンプト雛形をコピーし、Gemini のチャット欄に貼り付けて 送信ボタン（▷） をクリック。

AI が画像を生成。横長サイズ・左右の構図・指定色 が反映されているかチェック。

画像下の ︙（三点メニュー）→ 再試行 で 2-3 案比較し、ベストを選びます。

ダウンロードボタン（↓） をクリック。.png で保存。次ページ以降も同じ流れです。

💡 画像が生成されない場合 Gemini ではチャット欄下の [ツール] → [画像を作成] をクリックしてから実行。

ヒーロー画像を作成しよう

成果共有ページを完成させる 3 つの素材 （ヒーロー画像／ロゴ／アイコン）を順番に作っていきます。最初は ヒーロー画像 — ページ冒頭のメインビジュアルです。

用途

ページ冒頭のメインビジュアル。訪問者の第一印象を決める要素。

作るときのコツ

・横長 1920×720px を必ず指定（既存レイアウトに合わせる） ・左側に 空きスペース を作るとテキストを重ねやすい ・グラフ・データフロー図など 動きのある要素 で印象付け

プロンプト雛形

※ 前々ページの 画像生成 AI ツール（ChatGPT・Gemini・Adobe Firefly・Midjourney）のチャット欄に貼って実行

プロジェクト成果共有ページのヒーロー画像。 ・テーマ：[プロジェクト名 — 解決した業務の課題]（例：「営業企画部 Q1 — 目標達成率 128%」） ・画風：フラットデザイン、ビジネステック調 ・色：ネイビー #1e3a8a とアンバー ``、白背景 ・要素：右側にデータフロー図、左側に空きスペース ・サイズ：横長 1920×720px、PNG

※ *[...]* の部分だけ書き換える

Gemini で生成した例（営業企画部 Q1 のヒーロー画像）

ロゴを作成しよう

ヘッダー左端に置くロゴは、ページの "顔" になります。AI 生成のクセを押さえて、シンプルで使い回せるロゴを作りましょう。

用途

ヘッダー左端に配置。プロジェクトの "顔" としてページ全体の印象を決める。

作るときのコツ

・AI は 文字を崩しやすい → 図形・記号モチーフを推奨 ・小サイズ表示でも視認できる シンプルなデザイン ・正方形（512×512）で作ると様々な場所で使い回せる

プロンプト雛形

※ 画像生成 AI ツール（ChatGPT・Gemini・Adobe Firefly・Midjourney）のチャット欄に貼って実行

プロジェクト成果共有ページのロゴ。 ・テーマ：[プロジェクト名]（例：「営業企画部 Q1 報告」） ・画風：フラットデザイン、シンプル ・モチーフ：[象徴的な要素]（例：「Q1」の文字、矢印） ・色：ネイビー #1e3a8a とアンバー ``、白背景 ・サイズ：正方形 512×512px、PNG

※ *[...]* の部分だけ書き換える

Gemini で生成した例（営業企画部 Q1 報告のロゴ）

アイコンを作成しよう

メンバー紹介セクションのイニシャル文字を、AI 生成のアバターアイコンに差し替えます。役職ごとに 1 案ずつ生成 し、3 つのファイルを揃えます。

用途　メンバー紹介セクション用。イニシャル文字の代替として使う。

作るときのコツ

・1 案ずつ生成 するとファイル単位で差し替えやすい ・シルエット形式 なら人物の特定を避けられて社内利用に安全 ・円形 で作ると現実装（イニシャル円）と差し替えやすい

プロンプト雛形 ※ 画像生成 AI ツールのチャット欄に貼って実行

営業企画部メンバーのシルエットアバター。 ・対象：[役職と特徴]（例：「部長／フォーマルなスーツ姿」） ・スタイル：白シルエット　・色：ネイビーのグラデ背景 ・形：円形　・サイズ：512×512px、PNG

※ *[...]* を変えて3回実行

部長

マネージャー

メンバー

💡 2回目以降が1回目と似ないとき

1回目の画像を添付 して、2・3回目のプロンプトに「この画像と同じスタイル・トーンで」と前置きすると、線の太さ・グラデ・輪郭が揃いやすくなります。

1回目の画像を添付して送信する例

生成した画像をサイトに配置する

3 つの素材（ヒーロー画像／ロゴ／アイコン）が揃ったら、コーディング AI に依頼して成果共有ページに配置します。

用途

生成した 3 つの素材を成果共有ページに反映。コーディング AI が App.jsx と App.css を一括で書き換えます。

配置のコツ

・ファイル名 は logo.png／hero.png／member-bucho.png のように 役割が分かる名前 に ・画像は VS Code の左サイドバーの public/ フォルダ に ドラッグ&ドロップ で配置 → /logo.png のパスで参照できる ・サイズが多少ずれても object-fit: cover（枠からはみ出た部分を自動で切り抜いて表示する CSS 指定）で枠に合わせて表示される

プロンプト雛形

※ コーディング AI（Claude Code・Codex・Gemini CLI 等）のチャット欄に貼って実行

以下3点を、既存の App.jsx と App.css に反映してください。

1. /logo.png をヘッダー左端に配置（高さ 40px、クリックでトップへ）
2. /hero.png をヒーローセクション背景に object-fit: cover で敷く
3. /member-bucho.png／/member-manager.png／/member-member.png をメンバー紹介カードに円形クロップで表示

画像パスは public/ からの相対パスを / 始まりで使用。既存レイアウトは崩さないこと。

Claude Code で配置した完成ページ（営業企画部 Q1 報告）

💡 配置後はブラウザで2点チェック ① 作成した画像がサイトに表示されているか ② サイトの表示が崩れていないか（画像がはみ出る・大きすぎるなど）

AIツールの組み合わせを意識する

3種の AI を "部門間リレー" で回す

本章で実際に使ったのは 画像生成 AI と コーディング AI の2種類でした。ここに チャット AI（企画フェーズの壁打ち）を加えれば、実務の部門間連携（企画 → デザイン → 開発）をそのまま1人で圧縮できる "3種リレー" が完成します。第9章「卒業制作」では、この3種リレーをチャット AI の企画から通して実体験します。

情報設計・文言・構成の壁打ち。企画部の代わり "営業企画部 Q1 報告ページの構成を3案。読み手は経営層、訴求は『売上達成と来期施策』" ロゴ・ヒーロー画像・アイコンを生成。デザイン部の代わり "営業企画部 Q1 のヒーロー画像。ネイビー基調・横長 1920×720。部長／マネージャー／メンバーの円形アイコンも" 実装・配置・レスポンシブ対応。開発部の代わり "/logo.png をヘッダーに、/hero.png をヒーローセクション背景に object-fit: cover で配置。メンバー写真は円形に切り抜き"

✅ リレーの順番とバトン

チャット AI で営業企画部 Q1 報告ページの構成と見出しを決める → その構成を 画像生成 AI に渡してヒーロー画像・ロゴ・メンバーアイコンを生成 → 文言と画像を コーディング AI に依頼して App.jsx／App.css に配置。 "前の AI の成果物を、次の AI の入力にする" と、往復のムダがなくなります。 会社で別部門の担当者に作業を引き継ぐときと同じ段取りです。

画像生成プロンプトのテンプレートを作る

6つの要素に整理して、何度でも同じ雰囲気で作れるようにする

ヒーロー画像・ロゴ・アイコンで使った 画像生成プロンプト を 6つの要素に整理 すると、自分用のテンプレートが完成します。 営業企画部 Q1 で決めた 色や雰囲気 を、次の四半期でも同じテンプレに当てはめて 再現 できます。

画像生成プロンプトの6つの要素

No. 要素 内容 プロジェクト成果共有ページでの例 1 主題 何を描くか 「営業企画部 Q1 報告のヒーロー画像」 2 スタイル 画風・テイスト 「フラットデザイン、ビジネステック調」 3 色 配色の指定 「ネイビー #1e3a8a とアンバー ``」 4 背景 背景の指定 「白背景」「淡いグラデーション」 5 雰囲気 全体のムード 「テック企業の信頼感、落ち着いた高級感」 6 技術指定 サイズ・形式 「横長 1920×720px、PNG」

テンプレート

※ *[...]* の部分を 上の表の例 に差し替えて、画像生成 AI のチャット欄に貼って使います

*[主題]* を作ってください。 *[スタイル]* で、*[色]* を基調に、*[背景]*で。 *[雰囲気]* な印象で、*[技術指定]*。

書き換え済みの実例

営業企画部 Q1 報告のヒーロー画像を作ってください。 フラットデザイン、ビジネステック調で、ネイビー #1e3a8a とアンバー `` を基調に、白背景で。 テック企業の信頼感のある印象で、横長 1920×720px PNG。

最短で始める順番

💡 まずは3つの要素から

主題 ＋ スタイル ＋ 色 の3つだけで出してみて、 結果を見ながら背景・雰囲気・技術指定を足していく。 全要素を最初から書くと、AI が縛られすぎて硬い絵になりがちです。

成果共有ページの四半期ごとの更新では、 主題だけ差し替える 運用で素材を量産できます。

デザイン指示のプロンプトパターン集

よく使う指示を "メモに残しておく"

Web デザインの修正指示には、毎回の業務で使い回せるパターンがあります。 メモ帳や社内のメモツールに 4つのパターンだけ 貼っておけば、今後の業務資料更新で即座に呼び出せます。

「*[ページ名]* をレスポンシブ対応にしてください。 スマホ（480px以下）は1カラム、タブレット（768px以下）は2カラム、 PC は3カラム。最大幅は 1200px で中央寄せ。」 「*[対象セクション]* に、下から 20px ＋ opacity: 0 → 1 の 0.5 秒フェードインを追加してください。 ヘッダーにはアニメーションをつけないでください。」 「*[ページ名]* をダークモードに変更してください。 背景 #0f172a、テキスト 、 アクセント 。配色以外は変更しないでください。」 「*[ページ名]* のヘッダーのロゴとナビを Flexbox で横並びにしてください。 ロゴは左寄せ、ナビは右寄せ、間に margin-left: auto で余白。 既存のフォントサイズは変えないでください。」

メモに残すときは [ページ名] や [対象セクション] を実際の業務資料に合わせて差し替えれば再利用できます。 4 つを一気に使いこなそうとせず、まず 1 つを自分の業務に合わせて繰り返し使ってみる と、実務に定着しやすくなります。

AIに「参考にして」と伝えるテクニック

雰囲気の言語化 — 3つの伝え方

「おしゃれに」では AI は動けません。 「何を参考に」「どの要素を引き継ぐか」を言語化することで、 社内のブランドガイドやコーポレートサイトのデザインの雰囲気（色使い・字体・余白の取り方）を成果共有ページに引き継げます。

雰囲気を色・字体・余白などの要素に分けて言葉で渡す 「自社コーポレートサイトのような、 余白多め・ネイビー基調・細めのゴシック体で」 マルチモーダル対応のチャット AI に画像を添付して指示 ブランドガイドの表紙画像を添付して 「この雰囲気に合わせてヒーローセクションの CSS を書いて」 伝えたい雰囲気を表すキーワードをまとめて渡す 「落ち着いた／信頼感／ネイビー×白／ ゴシック体」をまとめて指定

雰囲気別キーワードセット — 業務資料の見た目を決めるときに

雰囲気 キーワード例 活用シーン ビジネス信頼系 「落ち着いた」「信頼感」「ネイビー×白」 経営報告・対外公開用の成果ページ テック・先進系 「スマート」「グリッド背景」「ダークモード」 DX・AI 系プロジェクトの紹介 チーム親近系 「やわらかい」「丸み」「アクセントにアンバー」 メンバー紹介・採用向けの社内資料 ミニマル系 「余白多め」「モノトーン」「装飾を最小限」 数字で語る KPI ダッシュボード

ブラウザの開発者ツールで確認する <ch03-devtools>

ブラウザ内蔵の "現場確認ツール"

ブラウザの開発者ツール（DevTools）は、ブラウザに初めから入っている無料の確認ツールです。成果共有ページを共有する前の 最終チェック と、「ここの色を変えたい」ときの その場での見た目調整 の両方に使います。本章では Chrome を例に説明しますが、Edge でも確認可能です。

よく使う3つの機能

📱 Device Toolbar 左上の アイコンをクリック（または Cmd ＋ Shift ＋ M）で ON。iPhone / iPad / レスポンシブを切り替えて確認。 🔍 Elements タブ 左上の アイコンをクリック → ボタンや画像などのパーツをクリック → 右側の Styles パネルで CSS が表示。値を直接書き換えると即座にプレビューに反映。 ⚠️ Console タブ 赤字の Error が出ていたら共有前に解消。警告（黄色）も把握しておくと原因特定が速い。

共有前チェックリスト

・iPhone SE相当幅で文字が収まっている　・ヘッダーが固定追従するか ・Console エラーがないか　・画像が壊れた表示になっていないか

起動方法

・ページ上で右クリック → 「検証」（全 OS 共通・迷ったらコレ） ・キーボード派は下の OS 別表を参照

OS キー Windows F12 または Ctrl ＋ Shift ＋ I Mac Cmd ＋ Option ＋ I

Chrome DevTools の画面例

DevToolsで実際に微調整してみよう

ファイルの内容を変えずにDevToolsで試してから本反映

DevTools で CSS をいじってもファイルの内容は書き換わりません。そこで調整してみて、良かった値だけをコーディング AI に伝えて正式反映する、という流れが最速です。ここでは ヘッダーの色を変える 例を6ステップで通します。

Chrome で 営業企画部 Q1 報告ページ を開く F12 または右クリック → 「検証」 DevTools 左上の アイコンをクリック ページ上部の 濃いネイビー帯 をクリック .portal-header の background を #065f46 に書き換え → ヘッダーが緑に変わる

6 AI に反映依頼

「.portal-header の background を #065f46 に変更してください。他の箇所は触らないで。」

コーディング AI に貼り付け、ファイルへ正式反映

他のプロパティでも応用する

ヘッダーの色変更で覚えた 「DevTools で試す → AI に依頼」 の流れは、他のプロパティ・他の要素でも同じパターンが使えます。

よく使う4つのプロパティ

プロパティ 試すこと color 見出しや本文の文字色を変える margin / padding 余白を増減、要素の詰まり具合を調整 font-size スマホ幅での読みやすさを検証 background-color カードの背景を変更して視線誘導を確認

覚えておくと速い — DevTools ショートカット

操作 Mac / Windows 用途 DevTools 開閉 Cmd ＋ Opt ＋ I / F12 編集・検証の入口 Device Toolbar Cmd ＋ Shift ＋ M / Ctrl ＋ Shift ＋ M スマホ／タブレット幅の検証 強制リロード Cmd ＋ Shift ＋ R / Ctrl ＋ Shift ＋ R 前回の表示を無視して最新を取得 要素選択 Cmd ＋ Shift ＋ C / Ctrl ＋ Shift ＋ C 画面上の要素を直接クリックで検査

まとめ

📐 レイアウト編

・レスポンシブ：@media で 480／768px の分岐 ・モバイルファーストで情報を厳選 ・DevTools で実機の見た目を微調整

✨ 動き編

・フェードイン・固定ヘッダー・パララックスで視線を誘導 ・主役にだけ動きを付ける ・数値制約で "やりすぎ" を防ぐ

🎨 画像生成 AI 編

・マルチモーダルでロゴ・ヒーロー画像・アイコンを自分で用意 ・6要素テンプレートで量産 ・3つの要素から始めて必要分だけ足す

🔧 AI 活用編

・3種の AI を部門間リレーで回す ・よく使う指示パターンをメモに残して使い回す ・制約を先に書いて出力を安定させる

🏆 この章の成果

プロジェクト成果共有ページという 1つの業務資料 を通じて、 レスポンシブ設計・アニメーション設計・画像素材内製・AI 連携の4つを同時に練習しました。 同じ手順を別プロジェクトの成果共有や社内マニュアルに転用すれば、 デザイン専門チームを待たずに "見せられる品質" の社内 Web を自分で出せるようになります。

🚀 次回予告 — 第4章：JavaScript で動くページを作る

次は 経費申請チェッカー を題材に、入力に反応するページを JavaScript で組み立てます。 金額を入れると上限超過を判定し、月次合計を返す — 手元の Excel チェックを置き換える小さな業務ツールを、AI と一緒に1本通します。

よくあるトラブルQ&A

デザイン作業でつまずきやすい4つの悩みを、成果共有ページ運用の視点でまとめました。

Chrome DevTools の Cmd ＋ Shift ＋ M（Win は Ctrl ＋ Shift ＋ M）でデバイスモードに切り替え。プリセットと任意幅のレスポンシブ表示を検証できる。 480px（スマホ）→ 768px（タブレット）→ 1200px（PC）の3サイズ巡回で抜け漏れが減る Vite では public/logo.png を /logo.png で参照。./logo.png は NG。Logo.png と logo.png は別扱いで本番エラーに。 全部小文字、単語の区切りはハイフンで統一（例：hero.png member-01.png）。業務資料の命名規則と揃える Cmd ＋ Shift ＋ R（Win は Ctrl ＋ Shift ＋ R）で強制リロード。反映されなければ DevTools Elements で該当要素の CSS が効いているか確認。 ".summary-card に background-color が効いていません。詳細度を上げる修正案を3つ" ブランドガイドや既存ページのスクショを添付し「この色・余白・書体に合わせて再生成」と依頼。言葉だけより一回で合う確率が上がる。 "添付画像と同じネイビーを主色、余白多めで。フォントの印象（細めゴシック）も合わせて"

この章のゴール

「入力 → 計算 → 表示」が動くページを、AI と一緒に作る

本章では、業務でよくある フォーム入力とその結果表示 を題材に、JavaScript でページを動かす感覚を掴みます。 HTML／CSS が「貼り紙」だったのに対して、JavaScript は「受付係」です。ユーザーの入力に反応し、計算し、結果を返します。

この章の走る業務例は 経費申請チェッカー。 金額と区分を入力すると、区分ごとの上限超過を判定し、月次合計を返す社内向け Web ツールです。 手元の Excel チェックや目視確認を置き換える、小さな業務改善の第一歩になります。

この章が終わると、こうなる

・AI に指示して、入力フォーム付きの業務ツールが作れる ・AI が書いた JavaScript を読み、修正してほしい箇所を具体的に伝えられる ・エラーが出ても、3点セットのプロンプトで自力で解決に進める

この章の走る業務例

経費申請チェッカー

・入力：金額3件＋区分（交通費／会議費／雑費） ・計算：区分別上限判定 ＋ 月次合計算出 ・出力：合計金額、超過警告、コピー可能な報告文

今まで Excel で手作業確認していた「上限超過チェック」を、入力即反映の Web ツールに置き換えるイメージです。

はじめに読む — 本章の前提

・第3章のプロジェクト（Vite+React）はそのまま残して OK。本章は新しく別のプロジェクト expense-check（走る業務例：経費申請チェッカー）を作ります ・プロジェクト作成コマンドはターミナルで実行。置き場所は ~/Documents（Mac）／C:\Users\<名前>\Documents（Windows）など自分がすぐ見つけられるフォルダで OK ・本文中の expense-checker は、実コマンドと同じ expense-check で読み替えて進めても構いません（名前は任意）

本章で使う JavaScript 構文早見

この章で使う JavaScript の構文は8つだけ — 一度眺めておけば、AI が書いたコードを読むときの地図になる

経費申請チェッカーを作る過程で、以下の8つの構文が繰り返し登場します。意味を暗記する必要はなく、「あ、この形はあれだ」と思い出せれば十分です。コードは AI に書かせて、自分は 読み解いて指示を出す側 に徹しましょう。

構文 何に使う グループ const 名前 = 値 値を保持（後から変えない） 基本 let 名前 = 値 値を保持（後から書き換える） 基本 if (条件) { ... } 条件分岐（上限超えたら警告など） 基本 useState(初期値) 画面の状態を覚えさせる（Reactフック） React onClick={() => 処理} ボタンが押されたら処理を実行 React 配列.map(x => ...) 配列を別の配列に変換（明細の表示など） 配列操作 配列.filter(x => 条件) 条件に合う要素だけ残す（超過だけ抽出） 配列操作 console.log(値) 値をコンソールに出す（デバッグの合言葉） デバッグ

🧠 3つのグループで覚える

基本 ＝ 値と条件／ React ＝ 画面の状態と操作／ 配列操作 ＝ データを加工 — この3つが揃えば1本組める。

🤖 自分で全部書かなくてOK

構文はAIが書いてくれる。人間の仕事は 何をさせたいか を言葉にして、出力を 読み解いて差分を指示 すること。

🆘 動かないときの合言葉

エラー文／コード／期待動作 の3点セットをAIに貼れば、ほぼ解決。後半の「デバッグプロンプト」で詳しく。

💡 読めれば十分、書けなくてOK — 業務の Excel 関数と同じです。VLOOKUP を暗記していなくても、読めれば直せる のと同じ感覚で大丈夫です。AI が書いた useState や .map が目の前に並んでも、この早見表を横に置いておけば迷わず修正指示が出せます。

完成形と作る手順 — 経費申請チェッカー

完成イメージ

入力フォーム ・金額1：［　4,200　］円　区分：［交通費 ▼］ ・金額2：［　8,500　］円　区分：［会議費 ▼］ ・金額3：［　1,200　］円　区分：［雑費　 ▼］ ［　チェック　］ボタン

結果表示 合計：13,900 円 ⚠ 会議費が上限 5,000 円を超過（+3,500 円） コピー用報告文：「当月経費合計 13,900 円（超過1件）」

※ React（画面を "部品" で組立）+ Vite（開発雛形・第2章ミニ辞書）で作成。AI が雛形を生成するので "コードを覚える" 必要はありません。

作業の4ステップ

npm create vite@latest で雛形を5秒で用意

入力欄3つ・区分セレクト・ボタンを AI に依頼

上限超過チェックと合計計算の関数を追加

超過警告の色分け・報告文のコピーボタン

最初の1手 — ターミナルにそのまま貼る

```bash
npm create vite@latest expense-check -- --template react
cd expense-check && npm install
npm run dev
```

ポイント — "動くもの" を最短で立ち上げる

http:

できあがるフォルダ（触るのは App.jsx と App.css の2つだけ）

expense-check/src/ ├─ App.jsx ← 編集する ／ App.css ← 見た目 └─ main.jsx ← 触らない ／ package.json ほか

はじめの指示 — AI への雛形依頼プロンプト

雛形は "業務要件を具体的に渡して" 一気に作る

AI に雛形を頼むときは、欲しい機能を箇条書きで示し、ファイル名と画面の流れまで明記するのがコツです。 経費申請チェッカーの骨組みを、以下のテンプレートで一度に依頼してみましょう。

AI へ投げるプロンプト（コピペして要件だけ書き換え）

あなたはフロントエンドエンジニアです。React + Vite プロジェクトの src/App.jsx に、 経費申請チェッカー の雛形を実装してください。

要件 ・金額入力欄を3つ、区分セレクトボックスを3つ並べる ・区分の選択肢は「交通費／会議費／雑費」 ・「チェック」ボタンを1つ、下に結果表示エリア1つ ・この段階では、ボタンを押すと「チェックしました」とだけ表示する

出力形式 ・日本語コメント付き、src/App.jsx の完全なコード ・CSS は src/App.css にまとめる

↓ 書き換え箇所はここだけ プロジェクト名：expense-checker／対象業務：経費申請の上限チェック

このプロンプトが満たす3条件

・役割を明示（フロントエンドエンジニア） ・要件を箇条書きで具体化（入力欄の数まで） ・出力形式を指定（ファイルパス・コメント）

あえて "やらないこと" を書く

今回の雛形段階では 計算処理はまだ書かせません。まずフォームの見た目だけを作らせて、動作確認してから次のロジックに進みます。 これが「段階的指示」の基本姿勢です。

確認ポイント

ブラウザに入力欄が並び、ボタンを押すと「チェックしました」と出れば合格。見た目が崩れていても次に進めます。

Tips — コーディング AI は "文脈ごと" 渡すのがコツ

Claude Code や Codex などのターミナル常駐 AI は、プロジェクトのファイルを読めます。 「src/App.jsx に…」と書くだけで、既存コードを踏まえた差分編集が返ってきます。ブラウザのチャット AI に貼り付ける場合は、現在のコード全文を添えてから依頼します。

段階的指示 — 1回1機能で積み上げる

一度に全部頼むと、AI も人間も混乱する

雛形ができたら、機能を 1つずつ 追加していきます。AI への指示は「ブラウザで動作確認できる単位」で区切るのが鉄則です。経費申請チェッカーを4ステップで完成させましょう。

金額3つと区分3つを受け取って、ボタン押下時にコンソールへ JSON で出力する処理を追加 ブラウザの Console（Win: F12／Mac: Cmd+Option+I → 上部タブ「Console」）に {amount:[...], kind:[...]} が出れば OK 金額の合計を計算し、結果欄に「合計：◯◯円」と表示する関数 calcTotal を作る ボタン押下で合計金額がそのまま画面に出れば OK 区分ごと上限（交通費10000／会議費5000／雑費3000）を超えたら赤字で警告メッセージ 会議費に6000入れると赤い警告が出れば OK 結果を1行文字列にし、コピーボタンで clipboard にコピーする機能 ボタン押下後に Slack／Teams／メモ帳などどこでも貼り付けて文字列が出れば OK

NG — 一度に全部頼む

「経費申請チェッカーを作って。合計計算も上限判定もコピーもつけて、デザインもおしゃれに」

→ どこで詰まったか切り分け不能

OK — 1機能ずつ

「まず合計計算だけ追加して。次に動作確認してから、上限判定を別で頼む」

→ 壊れた場所が特定でき修正依頼も鋭くなる

分割の判断基準

"ブラウザで動作確認できる最小単位" に分ける。迷ったら小さすぎるくらいがちょうど良い。

→ 1ステップ＝1動作確認が AI 時代の開発リズム

プロンプト設計の3要素 — 機能追加の型

既存コードへの 機能追加 を指示するときは、常に3つの要素を揃えます。これは業務で他部門に仕事を依頼するときの「背景／依頼内容／納品形式」と同じ構造です。

要素 何を書くか 経費申請チェッカーでの例 ① 現在の状態 今のコードで何ができるか 「3つの金額と区分を入力し、合計を表示する機能まで完成」 ② 追加機能 何を足したいか（1つに絞る） 「区分別に上限超過を判定し、該当項目に赤字で警告を表示」 ③ 期待動作 入力→出力の具体例で書く 「会議費 6,000 入力 → 『⚠ 会議費が上限 5,000 円を超過』を表示」

3要素を埋めたプロンプト完成形（経費申請チェッカー編）

以下の経費申請チェッカーに、上限超過チェック機能を追加してください。

［① 現在の状態］ 3つの金額と区分を入力し、ボタン押下で合計金額を表示するところまで動いています。

［② 追加機能］ 区分ごとに定めた上限（交通費 10,000／会議費 5,000／雑費 3,000）を超えていたら、 該当項目に赤字で「⚠ ◯◯費が上限 N 円を超過（+M 円）」を表示。

［③ 期待動作］ ・交通費 4,200 ＋ 会議費 8,500 ＋ 雑費 1,200 → 「⚠ 会議費が上限 5,000 円を超過（+3,500 円）」1件表示 ・全て上限以内 → 警告なし、合計のみ表示

（現在の App.jsx を貼り付け）

書き換え箇所の目印

プロンプトの ［① 現在の状態］ と ［② 追加機能］ が、毎回書き換わる部分です。 テンプレートとして保存し、次回の業務ツールでは業務要件だけ差し替えて使い回します。

AI 出力精度が上がる4つの習慣

・数字は具体値で書く（「大きな金額」ではなく 10,000） ・境界条件を1例は書く（ちょうど上限の時どうなるか） ・表示文言は完成形そのままを渡す ・既存コードは "省略せず全部" 貼る

AIの出力を検証する — 動作確認→差分言語化→再指示

AI のコードは、受け取った時点ではまだ "仮納品" です。自分の手で動かし、期待とのズレを言葉にして、次のプロンプトに反映する。この 検証サイクル を回すスピードが、そのまま開発スピードになります。

コードを保存しブラウザで実際に操作。 期待通りに動くか、境界値（空欄・ちょうど上限・上限+1）で確かめる。 金額欄を空にして押下したら「NaN 円」と表示された 「なんか違う」ではなく、"入力"と"期待"と"実際"を分けて書く。 入力：空欄 → 期待：『金額を入力してください』 → 実際：『NaN 円』 言語化した差分を、そのまま AI への修正指示に貼る。これで1周完了。 空欄があれば計算せず『金額を入力してください』を表示するように修正して

差分を言語化するコツ — NG → OK

なんか違う 空欄で押すと NaN 円と出る。『金額を入力してください』にしたい 入力・期待・実際の3点を分けると AI が即座に修正できる

いい感じにして 警告文を赤太字（`` 、bold）で表示。合計行の下に配置 色・太さ・位置まで具体化すると出力のブレが消える

デバッグプロンプト — エラー報告の3点セット

エラーは "故障" ではなく "ヒント" です。そのまま AI に渡せば、大半は数秒で原因が特定されます。 鍵は エラーメッセージ／コード／期待動作 の3点を揃えることです。

デバッグプロンプトのテンプレート（コピペ可）

経費申請チェッカーで以下のエラーが出ました。原因と修正方法を教えてください。

［① エラーメッセージ］ Uncaught TypeError: Cannot read properties of null (reading 'value')

［② 該当コード］ const amount = document.getElementById("amount1").value;

［③ 期待動作］ 金額入力欄の値を取得し、合計計算に使いたい。

↓ 書き換え箇所 ① コンソールからそのまま貼る／② 該当行＋前後10行／③ 何をしたかったか

エラー調査の3ステップ

F12（Mac: Cmd+Option+I）→ Console タブ。赤字＝エラー

メッセージ／該当コード／期待動作

テンプレに貼り、修正案をもらう

Tips

React 使用時は、ブラウザ画面にも赤背景のエラー画面が出ます。そのメッセージも全文コピーして AI に渡せば OK です。

確認ポイント — "エラー文だけ貼る" からの卒業

「エラーが出ました、直して」だけだと AI も迷います。3点セットを揃えると、AI は原因仮説 → 修正案 → 動作確認方法まで一度に返してくれます。業務の問い合わせでも「症状だけ報告」より「再現手順＋環境＋期待動作」を添えるほうが解決が早いのと全く同じです。

console.log × AI — 自分で絞って、AIに任せる

エラーが出ていないのに結果がおかしい、というときは 何が、どこまで正しいか を自分で絞り込みます。使う道具は console.log の一行だけです。出力値を AI に渡せば、修正案の精度が段違いに上がります。

経費申請チェッカーでの実例 — 合計が合わない

症状：4200 + 8500 + 1200 を入力したのに、合計が 420085001200 と表示された。

Step 1 — ログを仕込む

```javascript
const total =
  amount1 + amount2 + amount3;
console.log("個別:", amount1, amount2, amount3);
console.log("合計:", total, typeof total);
```

Step 2 — Console で確認

個別: "4200" "8500" "1200" 合計: "420085001200" string

Step 3 — 気づき 値が文字列（string）になっている。+ が足し算ではなく文字の連結になっていた。 ※ 型＝データの種類（string 文字列／number 数値）。NaN は Not a Number（数値に変換できなかった）の合図

Step 4 — AI に渡す

「console.log で typeof total が string でした。入力値を数値に変換してから合計するよう修正してください（該当コード添付）」

console.log の3つの型

値と型 console.log(x, typeof x); 数値か文字列か、有無をまず確認 通過確認 console.log("enter calc"); 関数が呼ばれているかどうかを検査 配列の中身 console.table(arr); 複数金額や明細を表形式で見る

実務のコツ

社内の問い合わせ対応と同じで、"どこまで正常で、どこから異常か" を先に特定するのが最短ルート。AI に渡す情報も鋭くなります。

AIの得意・苦手 — 使い分けマトリクス

AI は万能ではありません。"得意な仕事" と "苦手な仕事" をあらかじめ知っておくと、プロンプトの出し方や任せる範囲を自分で判断できるようになります。

・フォーム雛形、計算関数、バリデーション ・エラーメッセージの解読と修正案 ・既存コードへのコメント追加 ・Excel 的な集計・フィルタ処理の実装

例：経費申請チェッカーの合計計算・上限判定

・コードの意味を日本語で解説 ・API や関数の比較表を出させる ・コードの原因分析（仮説を3つ挙げて） ・表・図・チェックリストへの整形

例：onclick と addEventListener を比較して

・複雑な機能を一度に全部依頼 ・「いい感じに」「なんか」の曖昧な表現 ・画面デザインと機能ロジックの同時実装

対処：段階的指示＋3要素＋具体値で補う

・社内ルールや独自の経費基準 ・関係部署との調整・承認フロー ・個別顧客の事情、機密情報の扱い

対処：人間が判断し、結果だけ AI にコードに落とさせる

次のステップ — AI の弱点は "指示の出し方" で半分は消せる

"苦手"の多くは AI 側ではなく プロンプト側 の不足。段階的指示・3要素・具体値の3点セットを習慣化すると、左下マス（苦手 × 補って任せる）の多くが右上（得意 × 任せる）に移動します。

チャレンジ課題 — 業務課題を自分のツールに

この章で学んだ型（雛形プロンプト → 段階的指示 → 機能追加3要素 → 検証サイクル → デバッグ3点セット）を使って、自分の業務を1つ選び、小さなツールに変えてみましょう。

日々の勤務開始／終了時刻から、月の総勤務時間と残業時間を算出。タイムシート Excel の代替 開始・終了時刻入力 → 日次時間計算 → 月合計＋残業時間表示 商品単価・数量・割引率を入れると、税抜／税込金額と粗利を自動計算。営業電話中の即答に 単価＋数量＋割引 → 税抜／税込計算 → 粗利率表示 件名種別・送り先・日付を入れて、定型の依頼メール文を自動生成。毎日の複数メール送信を圧縮 種別選択 ＋ 変数入力 → テンプレ差し込み → コピー機能

Tips — 5時間で収めるコツ

・「最小構成の3機能」だけ作る ・1機能ごとにブラウザで動作確認 ・詰まったら粒度を1段下げて AI に再依頼 ・デザインは機能が全部動いてから触る

ポイント — 完成後は "同僚1人に見せる"

作ったら必ず同僚に1回見せて、3分だけ使ってもらう。 「ここが分かりにくい」「この欄が要らない」という声が、 次の改善プロンプトになります。業務改善の起点です。

よくあるトラブルQ&A

HTML のフォームから取った値は文字列。+ 演算子が連結になっています。AI に「入力値を Number() で数値化してから合計するよう修正」と伝えれば即修正されます。 console.log で typeof を出力→string なら文字列連結が原因 React の場合、useState で値を保持していないか、onClick にアロー関数が渡っていないケースが多い。エラー全文をそのまま AI に貼り、「ボタン押下時に checkExpense が呼ばれない」と添えてください。 ※ useState ＝ 画面の"状態入れ物"。値を更新すると React が画面を自動で描き直します。 console.log("clicked") を onClick に仕込み、Console に出なければバインド漏れ コーディング AI にファイルパスを指定（「src/App.jsx の該当関数のみ修正」）、ブラウザ AI ならコード全文を添える。"該当箇所以外は変更しないで" と明記するのも有効です。 作業前に git commit して戻せる状態にする／差分だけ見る（Git は第8章で扱うので、今は「いつか学ぶ道具」で OK） 期待値と実際の出力の差分を言語化すれば半分は解けたも同然。入力値・中間値・出力値のどこで崩れるか、3箇所に console.log を仕込んで AI に渡します。 入力 N、期待 M、実際 X。この3語をプロンプトに必ず入れる

この章のまとめ — 明日から使える "型"

30日の旅はまだ途中です。この章で持ち帰るのは AI へ指示する型 です。業務のどんな小さな「入力→計算→表示」でも、同じ型を使って動くツールに変えられます。

テクニック 一言で言うと 経費申請チェッカーでの使い所 ① 雛形プロンプト 役割＋要件＋出力形式を一度に伝える フォームと結果表示の骨組みを5分で立ち上げる ② 段階的指示 ブラウザで動作確認できる単位に分割 合計計算 → 上限判定 → コピー機能 の3段 ③ 機能追加3要素 現状＋追加機能＋期待動作 上限超過の赤字警告を既存コードに足す ④ 検証サイクル 動作確認 → 差分言語化 → 再指示 「空欄で NaN」→ ガード文を追加 ⑤ デバッグ3点セット エラー＋コード＋期待動作 TypeError を秒で修正 ⑥ console.log × AI 自分で絞って AI に任せる 文字列連結の原因を typeof で特定

次回予告 — 第5章 Webアプリを作る

この章の6つの型に 黄金パターン（役割＋文脈＋要件＋出力形式＋制約） と LocalStorage を加えて、より本格的な Web アプリ（ToDo／タスク管理）に挑戦します。この章の型がそのまま土台になります。

この章の宿題 — 1つ選んで試す

・経費申請チェッカーを手順どおりに写経して完走する ・前ページの課題 A〜C のうち1つを選んで作る ・自分の業務から1つ「入力→計算→表示」を選んで雛形まで作る

コードの詳しい仕組み（変数・関数・イベント処理）は補講に掲載。

この章のゴール

この章のゴールは「AI を相棒に、業務の一場面を置き換える Web アプリを5要素プロンプトで組み上げる」こと。 題材は 問い合わせ対応テンプレ生成アプリ。毎回手で書いている返信文をフォーム入力で一発生成し、 Markdown でそのまま社内チャットや顧客メールに貼れるようにします。

📌 本章の前提 — 新規プロジェクトを1本立ち上げます

• 本章は 新規 Vite+React プロジェクト support-board を作って進めます（第4章の expense-check は流用しません）
• 走る例は 問い合わせ対応テンプレ生成アプリ — この1例で全ページを貫きます
• 第4章で触れた useState などの React 用語はまだ馴染みが薄い前提です。次ページの ミニ辞書 で再確認してから本編へ
• 作業の出発点は「空のフォルダに npm create vite@latest support-board を叩く」ところから

📨

問い合わせ対応テンプレ生成アプリ 「問い合わせ区分・顧客名・要旨」を入力 → 返信ドラフトを自動生成 → Markdown でコピー

区分・要旨からテンプレを合成。Markdown 文字列で返す 対応中／済みを切り替え、対応済みは取り消し線で視認性UP クローズ済み・重複問い合わせを1クリックで掃除 LocalStorage で自動保存。翌日の続きから再開可能

💼 これは実務のどの工程？

現場の「問い合わせ対応 → 返信文ドラフト → レビュー → 送付」のうち、 ドラフト作成までを AI と自動化 するツールです。既存の Excel 対応表や Word テンプレから一段進めた、 "業務の型そのものをアプリに閉じ込める" 練習になります。

本章で使う React 用語 — 業務アナロジー辞書

第4章でちらっと出てきた useState や useEffect を、業務のたとえ で1行ずつ再確認します。 厳密な定義は後からで OK。"何に似ているか" を先に掴むと、以降のプロンプトが読めるようになります。

画面の "今の状態" データ ホワイトボードの記入内容。消して書き直すたび画面も描き直される 親から子へ渡す "お題" 上司から部下に渡すメモ。受け取った子は中身を書き換えず参照だけする state を持つための道具 「今の値」と「値を書き換える関数」を2つセットで受け取る申請書 何かが変わった後に自動で走る処理 「会議が終わったら議事録を保存する」のような後片付け担当 use〇〇 で始まる関数の総称 React に機能を "引っ掛ける" レンタル工具。種類ごとに用途が違う useEffect の "監視リスト" 「この変数が変わったら走って」という見張り対象のリスト (後述)

全部暗記しなくて良い — この章を読み進めるとき、横に置いて都度戻ってくる辞書として使ってください。 「画面の状態＝state」「後片付け＝useEffect」の2つさえ掴めば、以降のプロンプト文が読めます。

設計を考える：機能の洗い出し

コードを書く前に 「何を・誰の業務のために・どう動けばよいか」 を1枚に並べます。 実務の要件定義の縮小版。ここを飛ばすと、作りながら迷子になります。

機能一覧 — 問い合わせ対応テンプレ生成アプリ

# 機能 業務視点での意味 1 問い合わせ追加 区分・顧客名・要旨をフォームで入力 2 返信ドラフト生成 テンプレに当て込み Markdown 文字列を返す 3 一覧表示 対応待ち案件を一画面で俯瞰 4 対応済みチェック 終わった案件に取り消し線を付ける 5 案件削除 重複・クローズ済みを掃除 6 自動保存 LocalStorage でブラウザ閉じても残る

業務フロー接続

メール／フォームで届いた問い合わせを登録 区分ごとのテンプレから返信文を合成 人が最終チェックして送る（ここは人の仕事） 対応済みにチェック、不要になれば削除

いきなりコードを書かない — 機能表を1枚書くだけで、後工程の AI への指示が段違いに通りやすくなります。 買い物リストを持たずにスーパーへ行かないのと同じ感覚で、仕様リストを持たずに AI へ頼まない。

プロンプト設計の黄金パターン

「AI に何を書くか」で成果物の質は決まります。 黄金パターンは 5要素をワンセットで渡す こと。全部揃えるほど、業務で使える精度に届きます。

AI に誰として答えさせるか "あなたはフロントエンドエンジニアです" 今の状況・既存コード "問い合わせ対応アプリを Vite+React で作成中" やってほしいこと "区分別に返信ドラフトを生成する関数を追加" どの形で返すか "src/App.jsx に Markdown 文字列を返す形で" 守ってほしいこと "既存の LocalStorage 保存処理は変更しない"

黄金パターン雛形（コピペして 【】 の中だけ書き換え）

［役割］ あなたは【フロントエンドエンジニア】です。 ［文脈］ 【問い合わせ対応テンプレ生成アプリ】を Vite+React で作成中。 ［要件］ 【区分・顧客名・要旨を受け取り、Markdown の返信ドラフトを返す generateReply 関数】を追加してください。 ［出力形式］ 【src/App.jsx に日本語コメント付きで】実装してください。 ［制約］ 【既存の LocalStorage 自動保存は変更しない】こと。

使い分けの目安

場面 揃える要素 小さな確認 要件のみ 関数追加 役割 ＋ 要件 ＋ 出力形式 機能追加 5要素すべて 仕様変更 5要素 ＋ 変更前後を明示

5要素を積み木のように重ねるイメージ

フォーム画面を作る（ステップ1）

まずは 最小の画面 を AI に生成させます。ここで動かしておくと、以降の機能追加が積み上げやすくなります。

コピペ用プロンプト — 問い合わせフォームの骨組み

［役割］ あなたはフロントエンドエンジニアです。 ［文脈］ 問い合わせ対応テンプレ生成アプリを Vite+React で作り始めたところです。 ［要件］ src/App.jsx に以下の UI を含む最小画面を作成してください。

• 画面タイトル「問い合わせ対応ボード」
• 区分の選択（お問い合わせ ／ クレーム ／ 見積依頼）
• 顧客名の入力欄（placeholder: 例）株式会社サンプル）
• 要旨の入力欄（placeholder: 例）請求書の再発行依頼）
• 「追加」ボタン
• 下部に一覧エリア（空でOK） ［出力形式］ src/App.jsx 全文、日本語コメント付き。 ［制約］ 外部ライブラリは入れず、標準の React / CSS だけで。

プロジェクト起動コマンド

```bash
npm create vite@latest support-board \
  -- --template react
cd support-board && npm install
npm run dev
```

動作確認

1. `http:
2. 3つの入力欄と「追加」ボタンが表示されるか確認
3. この時点では「追加」を押しても何も起きなくてよい

💡 Tips dev server はファイル保存と同時に画面更新。Alt+Tab で画面とエディタを往復できるウィンドウ配置が快適です。

AI が返したコードの "読み解き3点セット"

どの関数が何の責務か。import → コンポーネント → export の順に流し読みすれば OK props／state／ボタン押下時の関数名をメモ。次の機能追加で「どこに足すか」の手掛かりになる 保存 → dev server で画面確認。F12 Console にエラー無ければ次へ

✅ まずは「動いた／動かない」で十分 完全理解を最初に求めると進まない。接続点の名前だけ押さえ、動かしながら少しずつ読むのが業務スピードに合う。

状態管理とドラフト生成（ステップ2）

画面が出たら、「追加ボタンで案件が増え、返信ドラフトが自動で差し込まれる」 状態管理を足します。 1回のプロンプトで欲張らず、段階的に指示を重ねるのが鉄則です。

useState([]) で案件配列を持ち、追加ボタンで配列に案件を追加する "案件配列 tickets を useState で管理し、addTicket で区分・顧客名・要旨を追加。空欄はブロック" tickets を map で一覧描画。区分はバッジで色分け "tickets を map で <ul> に描画。区分ごとに背景色を変える（お問い合わせ青／クレーム赤／見積緑）" generateReply(ticket) が Markdown 文字列を返し、各案件にプレビュー表示 "区分別テンプレを用いて Markdown 返信文を組み立てる関数。冒頭・本文・結びの3段構成で日本語"

STEP 2-C のコピペプロンプト（書き換え箇所は【】のみ）

［役割］ あなたはフロントエンドエンジニアです。 ［文脈］ 問い合わせ対応テンプレ生成アプリの App.jsx を作成中（現在のコードは末尾に貼付）。 ［要件］ generateReply(ticket) 関数を追加し、各案件カード下部に返信ドラフトをプレビュー表示。

• 区分が【お問い合わせ】なら感謝＋確認のテンプレ
• 区分が【クレーム】なら謝意＋事実確認のテンプレ
• 区分が【見積依頼】なら受領御礼＋納期目安のテンプレ ［出力形式］ Markdown 文字列を返す関数として実装、日本語コメント付き。 ［制約］ 既存の追加機能・一覧表示は変更しない。

ポイント：1プロンプト1機能

1. 1回のプロンプトでは1つの関数／UI に絞る
2. 動作確認してから次のステップへ
3. 既存コードは必ず文脈として末尾に貼付
4. エラー発生時は エラー文・操作・該当コード の3点セットで戻す

💡 Tips 一度に頼むと、どこが原因で動かないか特定できなくなります。1歩ずつの方が結局最短。

対応済み・削除・Markdown コピー（ステップ3）

返信ドラフトが出るようになったら、運用に必要な 周辺機能 を積みます。ここからは "業務でそのまま使える" ところまで持っていく仕上げフェーズです。

各案件にチェックボックス。done=true で取り消し線＋グレー表示 「削除」ボタンで tickets.filter により該当 ID を除外 各案件の返信ドラフト横に「コピー」。navigator.clipboard.writeText で貼付先へ 最大幅 640px で中央寄せ、区分バッジ色分け、余白と角丸で業務感

ℹ️ navigator.clipboard.writeText — ブラウザのコピー機能を呼び出す命令。引数の文字列がクリップボードに入り、Cmd/Ctrl+V で他アプリに貼り付けできます。「コピー」ボタンの中身は実質この1行だけです。

STEP 3-A 〜 3-D の共通プロンプト骨格（書き換え箇所＝【】のみ）

［役割］ フロントエンドエンジニア ［文脈］ 問い合わせ対応テンプレ生成アプリ（コード末尾貼付） ［要件］ 【Markdown コピー機能】を追加。返信ドラフト横に「コピー」ボタン。押下時に navigator.clipboard.writeText でコピー。 ［出力形式］ 差分のある関数／JSX のみ、日本語コメント付き ［制約］ 既存の追加・一覧・生成処理は変更しない

チェックリスト

• 案件を3件追加 → 一覧に表示されるか
• 対応済みチェック → 取り消し線・グレー化
• 削除 → 当該案件が消える
• コピー → エディタに Markdown が貼れる
• ブラウザ F12 Console にエラーが無い

✅ 完成ライン — 3件の案件に対し、入力 → ドラフト生成 → コピーが通れば業務投入OK。

「業務アプリらしく見せる」4つの即効スタイリング — STEP 3-D の補足

観点 具体的にやること 📐 最大幅＆中央寄せ max-width: 640px; margin: 0 auto; で紙面の呼吸を作る 🏷️ 区分バッジ 区分ごとに薄い背景色＋丸角。一覧が一瞬で読める 🌬️ 十分な余白 padding: 16px／行間 1.6。社内文書に馴染む 🌿 抑えた配色 原色を避け、1色を基調に濃淡で。派手さは疲れる

見た目は機能が全部動いてから触る — デザインを先に整えると、機能追加のたびに崩れて手戻りが発生します。まず動くものを完成させてから、上の4観点で仕上げるのが最短ルートです。

データ保存：useEffect と LocalStorage

ブラウザを閉じると案件が消える状態では業務で使えません。 「tickets が変わるたびに自動保存、起動時に自動復元」 の二段構えを入れます。

🔔 依存配列 [tickets] は "監視リスト"

useEffect(() => {...}, [tickets]) の末尾にある [tickets] が 依存配列。 「この変数が変わったら中の処理を走らせてね」という 監視リスト のイメージ。

• [tickets] → 「tickets が変わったとき」 だけ実行（案件が増減したら保存）
• [] → 「最初の1回だけ」 実行（起動直後に1回だけ走らせたい処理向き）
• 書かない → 画面が更新されるたび毎回 走る（ほぼ使わない。無限ループの原因）

業務メタファーなら「勤怠が更新されたら人事に通知する」の "勤怠" 部分が依存配列。何も書かないと会議中の独り言まで全部通知してしまう、と考えると感覚が掴めます。

🔄 自動保存（書き込み） tickets が変わるたび useEffect で同期。保存の呼び忘れが物理的に起きない 📥 自動復元（読み込み） 起動時に useState の初期値関数で一度だけ読む。毎レンダーで読まない

🎯 業務での意味 昨日の対応中案件が今日そのまま残る。進捗を引き継げるから "業務ツール" と呼べます。

⚠️ ハマりどころ 依存配列を空 [] にすると保存されない。[tickets] を必ず含めること。

コピペ用プロンプト — 自動保存／復元の一括追加

［役割］ フロントエンドエンジニア。 ［文脈］ 問い合わせ対応テンプレ生成アプリ（末尾にコード貼付）。tickets を useState で管理中。 ［要件］ LocalStorage で自動保存／復元を追加。useState 初期値関数で getItem を読む／useEffect で変更都度 setItem。 ［出力形式］ 変更箇所のみ diff 風抜粋＋日本語コメント。 ［制約］ 追加・削除・ドラフト生成の既存挙動は変更しない。

動作確認 — 3ステップ

1. 案件を3件追加 → タブを閉じる
2. もう一度 localhost:5173 を開く
3. 3件がそのまま残っていれば合格

✅ これで業務投入OK 昨日の対応中案件がそのまま今日の画面に出る状態に到達。

⚠️ LocalStorage の実務注意 — "どこでも見られる保存" ではない

• 同じブラウザ・同じ URL でのみ有効（localhost:5173 と本番ドメインは別物）
• 容量は 約 5MB が上限。写真やファイル本体を直接入れる用途には向かない
• シークレットモード／別 PC／別ブラウザ では見えない。機密の原本保管は向かない
• ユーザーが開発者ツールから中身を読める。パスワード・個人情報の保存は避ける

プロンプト改善：NG → OK 書き換え

同じ機能要望でも、言い方で結果は別物になります。 業務で再利用できる "書き換え型" を3本 覚えておけば、ほぼ全場面に応用できます。

問い合わせアプリを全部作って src/App.jsx に区分・顧客名・要旨を受け取る入力フォームと「追加」ボタンを実装。外部ライブラリ禁止 1プロンプト1機能、ファイル・UI・制約を明示すると検証が楽

エラーが出て動かない Cannot read properties of undefined (reading 'map') エラー。追加ボタン押下直後に発生（該当の generateReply 関数コード添付） 3点セット（エラー文／操作／該当コード）で一発特定

見た目を業務用っぽく アプリ全体を最大幅 640px 中央寄せ、区分バッジを青・赤・緑で色分け、角丸 8px、影は控えめに 色・数値・配置を具体化すると期待と実装が揃う

1ターン目：汎用すぎ "問い合わせアプリ作って" → 用途が曖昧で的外れ

2ターン目：役割＋要件 "区分別に返信ドラフト生成" → 出力形式がバラつく

3ターン目：+Few-shot 出力 Markdown 例を1件提示 → 業務でそのまま使える

プロンプト・デバッグ — 症状から原因を特定する対応表

症状 プロンプトの問題 直し方 全然違うものが出た 要件が曖昧 UI／関数名／返り値型を箇条書きで具体化 既存機能を壊された 制約未指定 "〇〇は変更しない" を［制約］に追加 動かない／型不一致 文脈不足 App.jsx 全文を［現在のコード］に貼付 大量コード＋説明過多 1回で頼みすぎ 1プロンプト1機能に分割して再依頼

既存コードへの機能追加プロンプト

アプリが育ってくると「今あるコードに足す」場面が主戦場になります。 仕様 → コード → 追加機能 の3部構成が最強の型です。

🔗 3部構成 ＝ 黄金5要素の "よく使う3つだけ版"

既存コードに機能を足す場面では、役割（＝エンジニア）と 出力形式（＝差分コード）はいつも同じです。だから省略して、残りの 仕様（文脈） ＋ 追加機能（要件） ＋ 制約 の3つだけ書けばOK。 迷ったら黄金5要素に戻る、慣れたら3部構成で手早く — と使い分けると手数が減ります。

3部構成プロンプト — 検索機能の追加例

【現在の仕様】 ・useState で tickets 配列を管理 ・addTicket で区分・顧客名・要旨を追加 ・generateReply で Markdown 返信ドラフトを生成 ・useEffect ＋ LocalStorage で自動保存

【現在のコード】 （ここに src/App.jsx 全文を貼り付け）

【追加したい機能】 ・一覧上部に検索用入力欄を追加 ・顧客名・要旨を対象にリアルタイム絞り込み ・区分バッジ色・削除ボタンの挙動は変えない

なぜ3部構成が効くのか

1. 仕様 を言葉で揃えると AI が前提誤解をしにくい
2. 現コード で実装の地図を渡せば食い違いが減る
3. 追加機能 が独立して書けるので差分が読みやすい

💡 Tips 会話の途中で AI が文脈を失ったと感じたら、毎回3部構成で投げ直す方が結果的に速い。

仕様・現コード・追加機能の3枚セット

役割設定で "AIの立ち位置" を固定する

AI は "誰として答えるか" によって表現も深度も変わります。 業務ツール作りでは 役割 × 読者 を一緒に固定するのがコツです。

❌ 役割なし

"問い合わせアプリを作って"

→ 対象読者も書き方も毎回バラバラ。初学者向け説明／上級者向け最適化／研究者向け議論、どれが来るか運任せ。

✅ 役割＋読者指定

"あなたはフロントエンドエンジニア。社内向け業務ツールを Vite+React で作る想定で、読者は非エンジニアが読んでも意図が分かるレベルの日本語コメントを付けて"

→ コメント粒度・変数名の平易さ・エラーハンドリング方針が揃う。後で引き継ぐときもそのまま共有できる。

業務で使える役割設定パターン

役割 いつ使う 期待される出力の変化 フロントエンドエンジニア 画面・UI・React の実装 JSX／フック／CSS を軸に、保守性を意識した構造を返す コードレビュア 書いたコードの点検依頼 指摘・理由・修正案の3点セットで返してくる テクニカルライター README／社内展開資料作成 見出し階層・箇条書き・用語統一を守った文章になる 情シス担当 セキュリティ・運用の相談 データ保存先・権限・ログなど運用視点が返る プロダクトマネージャ 機能優先度の整理 MoSCoW／インパクト×工数で整理した表が返る

役割は1つに絞る — 「フロントエンドエンジニア兼コードレビュア兼テクニカルライター」のように複数役割を混ぜると、どの観点が優先か曖昧になって出力が薄まります。場面ごとに切り替える方が精度は安定します。

プロンプト品質の自己評価

AI に送る前の 5秒セルフチェック を習慣化すると、やり直しの回数が体感で半分になります。 チェックリストをブラウザのブックマークに貼っておくのがおすすめです。

要件は具体？ "いい感じに直して" "区分バッジを青・赤・緑で色分け、角丸 8px" 文脈を渡した？ "検索機能を追加して" "現在の App.jsx 全文を末尾に貼り、仕様を箇条書きで併記" 出力形式は明示？ "コード書いて" "src/App.jsx に日本語コメント付きで全文を出力" 曖昧表現は削った？ "適当に短く" "返信ドラフトは300字以内、敬語、箇条書き禁止" 1回で頼みすぎない？ "機能を全部追加して" "まず検索機能のみ。動作確認後に次へ"

💡 セルフチェックの習慣化 — 送信前に声に出して1〜5を読むだけで OK。慣れてくると2秒で全部チェックできるようになり、AI との往復回数が体感で半減します。

この章の振り返りと次へ

この章では プロンプトの型で、業務の1場面を Web アプリに閉じ込める 練習をしました。 大事なのは「全部 AI に頼む」でも「全部自分で書く」でもなく 型を持って使い分けること です。

機能一覧を1枚に書き、業務フローに接続 5要素（役割・文脈・要件・出力形式・制約） 1プロンプト1機能で積み上げ動作確認 useEffect ＋ LocalStorage で業務投入可能に 3部構成・役割固定・セルフチェック

🚀

次回：外部データと連携するアプリ API から取得した情報を画面に差し込む実装に進みます。この章で作ったアプリに社内 API の顧客リストを連携させる — "職場データを AI と混ぜる" 本格業務化の入口です。

LocalStorage に保存されない useEffect(() => {...}, [tickets]) で依存配列に tickets を入れる。空だと変更検知が走りません リロードするとデータ消失 useState(() => {...}) の初期値関数で localStorage.getItem を読む形にする 画面が真っ白になった ほぼ JSX 構文エラー。F12 Console の赤文字を読み、閉じタグ漏れ／return ( ... ) の括弧忘れ／className を class と書いたなどを確認。メッセージごと AI に貼ると一発特定 useEffect が無限ループする 依存配列の罠。state を setXxx する副作用なのに依存配列にその state を入れている／依存配列を書き忘れた、が2大原因。更新した state は依存配列から外すか、更新前後を比較してから set する AI が既存機能を壊してくる 制約 欄に「〇〇は変更しない」を明示。加えて追加機能は 1 プロンプト1機能 に分けるとリスクが激減

この章のゴール

この章で身につける「業務データをAIに扱わせる型」

毎月 Excel に CSV を貼って集計している業務を、API から自動取得 → グラフ化まで一本でつなぐ練習をします。 題材は本章を通じて 「社内営業KPIダッシュボード」 1本に統一。 他部署の定例で目にする "手作業レポート" を、AI と組んで置き換える感覚を掴みます。

完了時にできていること

・API（外部データの窓口）が何をするかを、業務の言葉で説明できる ・JSON を "業務データの構造" として読み、必要なキーを取り出せる ・Few-shot／技術選択相談／エラー3点セットのプロンプトを書き分けられる ・fetch → 画面表示 → グラフ化の流れを AI と協働で組める

📊 本章の業務走る例

社内営業KPIダッシュボード

毎月、営業企画が各部署から集める売上 CSV。 これを "API が返す JSON" と見立てて、画面表示とグラフ化を AI 協働で実装します。天気・ToDo は扱いません。

章内で一貫して使うデータ

/api/sales/2026-03 → 部署別の売上・達成率・前月比

⚠️ 写経前に必ず読む ― 本章の API について

本章で登場する `https:

手元で動かしたい場合はこちら（CORS 許可済み・登録不要）

JSONPlaceholder: https:

REST Countries: https:

→ プロンプト中の URL を上記に差し替えれば、同じ型のまま写経できます。

📌 前提確認 ― 本章で想定する環境

・第5章で useState / useEffect を使った Vite+React プロジェクトをひととおり動かした前提です ・本章は 新規プロジェクト sales-dashboard を作って進めます（走る例：社内営業KPIダッシュボード） ・第5章のプロジェクトに上書きせず、別フォルダで新規作成してください

$ npm create vite@latest sales-dashboard $ cd sales-dashboard $ npm install

本章で使う API 用語早見

外部データを取りに行くときに登場する9語 — 一度眺めるだけで、AI の出力や講座中の説明が一気に読めるようになります

API 連携では「HTTP」「JSON」「CORS」など初めて見る用語が一気に押し寄せます。丸暗記は不要です。意味のラベルを貼れるだけで十分 です。本章の KPI ダッシュボード開発中にどれかで詰まったら、このページに戻って該当行を確認してください。

用語・構文 意味・使いどころ グループ API システム間のデータ窓口（社内の問い合わせ窓口のイメージ） 概念 HTTP / HTTPS Web の通信規約（"配達の手順書"） 概念 GET / POST 取得＝GET／送信＝POST の2大メソッド 概念 JSON データの標準フォーマット（"揃った名刺"） 概念 fetch(URL) ブラウザ組み込みの API 呼び出し関数 構文 .then(res => res.json()) レスポンスをJSONに変換して次へ渡す 構文 .catch(err => ...) 失敗したときの受け皿（"ただし書き"） 構文 CORS 別ドメイン間通信の許可確認（最頻出の壁） 壁 .env.local / API キー 秘密の鍵を環境変数で隔離して管理 運用

📡 通信の基本サイクル

リクエスト送る → レスポンス受ける → JSONを読む。この3拍子が理解できれば、あとは応用です。

🧭 CORS は "許可証" のチェック

別ドメインからの呼び出しに サーバ側が許可を出すか の仕組み。エラーが出たら後半の「CORS」セクションへ直行。

🔐 API キーは見せない

.env.local に入れて Git に上げない。社内のパスワードをメールに書かないのと同じ感覚で扱う。

💡 API は「社内の他部署に問い合わせる」と同じ構造 — 「宛先」（URL）・「用件」（GET/POST）・「書式」（JSON）・「権限証明」（API キー）という業務の問い合わせと同じ4点が揃っていれば、返事（レスポンス）が戻ります。AI への指示もこの4点で組み立てれば、一度で通る確率が大幅に上がります。

APIとは「社内のデータ窓口」

業務シーンに置き換える

API とは、他システムのデータを取り出すための「窓口」です。 営業部が毎月経理に「先月の売上 CSV ください」とメール依頼しているのと同じ構図で、 プログラムは API にお願いして JSON を受け取ります。

違いは 「窓口が24時間開いていて、フォーマットが決まっている」 こと。 人が整形していた Excel と違い、必ず同じ形の JSON が返ってくるので、 プログラムで自動処理できます。

覚える3語

・エンドポイント　窓口の URL（例：/api/sales/2026-03） ・リクエスト　　　「3月分の売上ください」と投げる行為 ・レスポンス　　　返ってくる JSON データ

🏢 業務アナロジー

営業部 自分のアプリ メール依頼 fetch() リクエスト 指定した月 URL パラメータ 経理部 API サーバー 返信 CSV JSON レスポンス Excel 加工 画面表示・グラフ化

API を使う3ステップ

① 窓口を知る URL と返るデータを API ドキュメントで確認

② 投げて受け取る fetch() で呼び、JSON を手元に保持

③ 画面に出す 必要なキーを取り出し、表・グラフとして表示

💡 30秒体験 — ブラウザで API を叩く

アドレスバーに以下 URL を貼って Enter。国情報の JSON が返ってきます。

https:

japan を france に変えれば別の国。業務ではクエリ（?month=2026-03）で期間指定するのが典型。

🔷 練習に使える無料API（CORS対応）

・REST Countries — 国情報。登録不要 ・JSONPlaceholder — ダミーデータ。登録不要 ・OpenWeatherMap — 天気情報。無料枠あり（アカウント登録が必要）

JSONを"業務データ"として読む

Excel の「シート・行・列」にあたるものを、JSON では オブジェクト・配列・キー で表現します。 売上ダッシュボードのレスポンスを例に、読みどころを押さえます。

サンプルレスポンス — /api/sales/2026-03

```json
{
  "month": "2026-03",
  "currency": "JPY",
  "departments": [
    {
      "name": "東京営業1課",
      "sales": 12450000,
      "target": 12000000,
      "momRate": 1.08
    },
    {
      "name": "大阪営業2課",
      "sales":  9800000,
      "target": 11000000,
      "momRate": 0.92
    }
  ]
}
```

JSON の読み方 — Excel に置き換える

JSON Excel 意味（業務） { } シート全体 3月の売上レポート1件 month 見出しセル 対象月 departments 行の並び 部署ごとの売上 [ ] 行の集合 複数部署の繰り返し .name 部署列 部署名 .sales 売上列 実績額（円） .target 目標列 月次目標 .momRate 前月比列 1.08 = 前月比+8%

💡 業務で効くコツ

「配列（[ ]）が来たら行の繰り返しだ」と読めれば、 どんな API でも Excel の表として頭の中で描けます。

❌ よくある勘違い data.sales でいきなり売上が取れる → 実際は data.departments[0].sales

✅ 正しい確認順 まず console.log(data) で全体像を把握する → キーの階層を目で確かめてから参照

🔵 AIへの頼み方 JSON を丸ごと貼って「momRate を取り出す関数を」 → 実データ前提で書いてくれる

プロンプトの技術指定レベル ― 3段ピラミッド

同じ「売上ダッシュボードを作って」でも、技術をどこまで指定するかで AI の出力は大きく変わります。 業務で AI を使うときは、自分の理解度とチーム規約に合わせて レベルを使い分ける のがポイントです。

🔷 最小予習 ― fetch / async / await って何？

・fetch(URL) ― Web 上の窓口からデータを取りに行く命令（経理に「3月の売上CSVください」とメール送信する感覚）

・async / await ― 「返事を待ってから次に進む」書き方。返信メールを待ってから集計に進む、と同じ流れ

・await を書く関数の頭には async を付ける、とだけ覚えれば OK。今は 「依頼 → 待つ → 受け取る」 の3ステップが頭に入れば十分

最小の fetch 例（10行以内）

async function load() { const res = await fetch( "https://restcountries.com/ v3.1/name/japan"); const data = await res.json(); console.log(data); } load();

「部署別の売上ダッシュボードを作って」 事前調査。実装技術を絞り込む前の叩き台が欲しいとき 技術選定・UI・構成を AI がすべて提案。後で差し替える前提で受け取る 「売上 API を fetch()＋async/await で叩き、Vite+React で表示」 本講座・現場の大半。既存スタックに寄せたいとき 技術選択が揃うので、別機能追加でも手戻りが起きにくい 「useEffect で初期ロード、try/catch で 401／500 を分岐、Loading状態を useState で管理」 運用アプリの拡張。コードレビュー文化がある現場 チーム規約に沿ったコードが出る。自分でレビュー可能な領域が広がる

本章で採用するレベル2テンプレート（コピペ可）

［役割］ あなたはフロントエンドエンジニアです。 ［API］ https: ［やりたいこと］ 部署別の売上・目標・前月比をカード表示する Web アプリ ［技術］ Vite+React／fetchはasync/await／useEffectで初期ロード ［出力］src/App.jsx` 全体、日本語コメント付き

書き換える箇所と運用Tips

・URL は自部署の API に差し替え ・「部署別の売上」を自分の業務項目に ・技術欄はチームの標準に合わせる ・残り3項目は固定で使い回せる

💡 社内規約があるなら "レベル3＋規約の箇条書き" を保存し、テンプレート化するのが最終形。

Few-shot prompting ― 出力例でブレを消す

プロンプトに 「こう出してほしい」の例 を1つ添えるだけで、AI の出力精度は跳ね上がります。 業務で "報告フォーマットを毎回整える" のと同じで、例を見せるほうが言葉で説明するより速いのです。

❌ Zero-shot（例なし）

「売上データを見やすく表示して」

→ 色・並び順・単位がブレる。往復が増える

✅ Few-shot（例あり）

「この形式で出して：」

■ 東京営業1課 売上: 1,245万円 / 目標 1,200万円 達成率103.8% / 前月比: +8.0%

→ 単位・記号・並びが固定される

Few-shot 実践 ― 売上ダッシュボードを依頼する

本章の業務例「社内営業KPIダッシュボード」で、Few-shot の効果を実地検証します。 AI に渡す 1本のプロンプト をそのまま掲載します。業務では ［業務課題］ 部分を書き換えて再利用できます。

［役割］ あなたはフロントエンドエンジニアです。Vite+React で動く業務ダッシュボードを作るタスクです。

［API］ `https:

［出力例］

┌──────────────── 2026年3月 営業KPI ────────────────┐ │ ■ 東京営業1課 　 売上 1,245万円 / 目標 1,200万円（達成率103.8%）前月比 +8.0% │ │ ■ 大阪営業2課 　 売上 　980万円 / 目標 1,100万円（達成率 89.1%）前月比 △8.0% │ │ ■ 名古屋営業3課 売上 1,110万円 / 目標 1,000万円（達成率111.0%）前月比 +12.0% │ └───────────────────────────────────┘

［技術要件］ ・useEffect で初期ロード／ローディング中は「読み込み中…」を表示 ・達成率100%以上は緑、100%未満は赤で着色 ・src/App.jsx 全体を日本語コメント付きで出力

［業務課題］（↓ ここを自分の業務に書き換え） 毎月、各部署の Excel を営業企画が手動集計している。API 化できれば集計時間を半減できる。

✅ 効く理由① ASCII 図で レイアウト を固定。文章ではなく視覚で伝わる

✅ 効く理由② 「1,245万円」の 単位と桁区切り が例から読み取れる

✅ 効く理由③ 「△8.0%」の マイナス表記 が業務慣習どおりに揃う

AIに技術を選ばせる ― 条件付き比較プロンプト

ダッシュボードに欠かせないのが "グラフライブラリ"。候補が多すぎて迷うときは、 AI に 比較表 を作らせましょう。最終判断は人間、情報整理は AI という役割分担が基本です。

❌ 漠然とした聞き方

グラフを表示するライブラリを教えて

→ 10個ずらっと挙がるだけ。自分の業務に合うかは 結局自分で調べ直すことになる。

✅ 条件付き比較依頼

React で売上ダッシュボードを作る。 棒／折れ線／円に対応／npm 導入／ 日本語情報が多いライブラリを3つ、 メリデメ表で比較して

→ 条件で絞り込んだ3択＋比較表。 5分で意思決定まで辿り着ける。

相談プロンプトの4要素 — ① 用途（具体のシーン）　② 条件（譲れない要件）　③ 形式（表・箇条書きなど）　④ 判断軸（メリデメ・コスト等）

AI が返してくる比較表のイメージ

ライブラリ 強み 弱み ダッシュボード適性 Chart.js シンプル／日本語記事多い／react-chartjs-2 で React と相性良 細かい表現は自前 CSS 寄り ◎ 標準KPI可視化 Recharts React 前提の API／宣言的に書ける 大量データだと描画重め ○ 中小規模ダッシュ ECharts 表現力が最強／大量データもOK API が独特／学習コスト高 △ BI 的な大型案件向け

💡 最終判断は必ず人間 — AI の比較表は "情報整理の下地"。社内規約・既存スタック・運用コストを加味して決めるのは自分の仕事です。本章以降は Chart.js（＋react-chartjs-2） で統一します。

エラー対応のプロンプト戦略 ― 3点セット

API 実装でつまずくポイントはほぼ決まっています。 エラー報告を 「何をした・何が起きた・何を期待した」 の3点セットに揃えるだけで、AI が一発で原因を当ててくれる確率が大幅に上がります。

業務でよく出会う4つの API エラー

エラー 起きる場面 業務上の意味 質問テンプレ CORSエラー fetch 直後 ブラウザが "他社サーバーから持ってくるのダメ" と遮断 「CORS エラーが出ました：（全文）。対処法を教えて」 404 Not Found URL を打ち込んだ直後 窓口の住所が違う（担当部署が変わった等） 「/api/sales/2026-03 に投げて 404。正しい URL の調べ方は？」 401 Unauthorized API キー実装後 社員証を見せずに入ろうとした状態 「401 が返る。キーは Header に入れたつもり：（コード）」 undefined 画面表示段階 キー名の参照先が違う（別ファイル参照に近い） 「data.sales が undefined。実レスポンス：（JSON 全文）」

エラー報告の3点セット — 対比で見る

動かない 売上 API を fetch したら Failed to fetch。devtools Network タブは CORS 表示あり。該当コード添付 「何をしたか」「何が起きたか」を分けて渡す

undefined になる data.sales が undefined。期待は東京営業1課の売上。実レスポンス JSON を貼り付け 期待値と実データを並べれば、キーの階層ズレが一瞬で分かる

グラフが出ない 棒グラフ 0本。chart.js/react-chartjs-2 導入済み、Console に "bar" is not a registered controller ログを添付すれば、AI が不足している登録コードを即座に特定できる

CORSエラー ― 最頻出の壁を先に叩く

CORS（Cross-Origin Resource Sharing）は、「別ドメインのデータをブラウザが勝手に使うのを禁じる」セキュリティ機構です。 業務 API を叩くときに最初にぶつかる壁なので、原因と対処 を先にまとめて押さえます。

業務アナロジー

他部署のデータベースを、「正式な依頼経路を経ずに覗こうとした」状態。 "許可印のある部署からしか引き出せない" ように、API 側でも Access-Control-Allow-Origin ヘッダで呼び出し元を許可する仕組みになっています。

業務で言う "権限申請" の技術版。 自社 API を触るときは、情シス／API 担当に 「このオリジンを許可して」と頼むのが最短です。

豆知識: サーバーは 200 を返していても、ブラウザが 最後に 遮断することがあります。 DevTools の Network タブでステータスとレスポンスヘッダを確認するのが確実です。

エラー文の実物

```
Access to fetch at 'https://…'
from origin 'http://localhost:5173'
has been blocked by CORS policy
```

4つの対処ルート — どれを選ぶ？

① CORS対応 API を使う（最速）

公開 API のほとんどは許可済み。練習・プロトではこれで足りる

② サーバー側で許可してもらう

自社 API の場合。担当者に Allow-Origin 設定を依頼

③ Vite の proxy を使う（開発時）

vite.config.js で API を中継。AI に「proxy 設定を書いて」と頼むのが速い

※ vite.config.js は プロジェクト直下（package.json と同じフォルダ）にあります。VS Code のサイドバーから開いて編集します。

④ AI に丸投げ（現実解）

エラー全文を貼って「この環境で最短の対処を」と依頼。提案のうち ①〜③ のどれに当たるか判断

🔷 実務ワンポイント

練習では「REST Countries API」「JSONPlaceholder」など CORS 許可済みの公開 API を使い、 ルートを①に固定するのが最短。 業務 API を触るタイミングで ②／③ に昇格させていけば、壁で止まらず前に進めます。

複数 APIを束ねる ― 段階開発で迷子にならない

業務ダッシュボードはほぼ必ず 複数 API を使います。 AI に一度に全部依頼すると出力が混乱しがちです。Step 単位で1本ずつ動かす のが鉄則です。

売上ダッシュボードを4段階で組み立てる

/api/sales/:month を fetch → console.log で JSON を目視確認 Few-shot で整形した表示例を AI に渡し、カード UI を生成 Chart.js で部署別売上を棒グラフ化。動作確認後にコミット 別 API で目標値を取得し、達成率バーを併記。前月比矢印も追加

段階開発のプロンプトバトン（Day2 → Day3 の例）

［現状コード］ 下記 App.jsx はカード表示まで完了済み（そのまま貼り付け）。

［追加タスク］ 既存の departments 配列を そのまま使い、Chart.js で 部署別売上の棒グラフ を カードの下に追加してください。

［制約］ ・既存のカード表示は壊さない ・グラフタイトルは「2026年3月 部署別売上」 ・npm install が必要なら手順もコメントで記載

段階化の効能

・動作確認の粒度が細かく なる。どの段階で壊れたか追える ・プロンプトが短く なるので AI が迷わない ・業務レビュー でも「Day 3 までは動く」と即答できる

💡 現場ハック

各ステップ完了時に Git コミット → メッセージに "Day2: カード表示完了" と残すだけで、戻せる／説明できる が両立する。

グラフ化の定石 ― Chart.js で KPI を描く

数字の羅列を 棒グラフ に変えた瞬間、会議での議論の焦点が一変します。 本章の総仕上げとして、売上 API の結果を Chart.js で可視化する型を押さえます。

導入コマンド

```bash
npm install chart.js react-chartjs-2
```

差し替え指示プロンプト（コピペ可）

［役割］ フロントエンドエンジニア。 ［前提］ /api/sales/2026-03 の JSON で departments[].name と .sales を持っています（例を添付）。 ［タスク］ react-chartjs-2 の Bar で 部署別売上を表示するコンポーネント SalesBarChart.jsx を新規作成。 ［出力例］ タイトル「2026年3月 部署別売上」、Y 軸は万円単位、達成率100%以上は緑帯、未達は赤帯。

グラフ種別の選び方

業務の問い 向くグラフ どこが一番売れた？ 棒グラフ（並び替え済み） 月を追ってどう推移？ 折れ線グラフ 構成比は？ 円／ドーナツグラフ 2指標の関係は？ 散布図 KPI 達成率の一覧は？ 棒グラフ＋目標ライン

🔵 迷ったら棒グラフ

KPI 比較の9割は棒グラフで足りる。凝る前にまず棒で出して、チームに見せる。

Before / After — 数字の羅列 → グラフ

📄 Before — 数字の羅列

東京1課 1,245 / 大阪2課 980 / 名古屋3課 1,110 / 福岡4課 720 / 札幌5課 650（万円）

→ どこが不調か即答できない

→

📊 After — 棒グラフ

降順棒グラフ＋目標ライン。不調の札幌5課が一目で分かり、会議の論点が「なぜ札幌？」に揃う。

→ 意思決定スピードが段違い

よくあるトラブル Q&A

API 実装で詰まりがちな4点を、業務でそのまま使える対処フレーズとともに整理します。

fetch で Failed to fetch が出る URL をブラウザに貼って JSON が返るか確認 → devtools Network で CORS 確認 → 社内 VPN 切れも原因に。 AI へ：「Failed to fetch が出ます。URL・Network タブ・エラー全文を添付。対処を順位付きで」

画面に undefined が出る console.log(data) で全体出力 → 期待キーと実キーを並べて確認。階層ズレが典型。 AI へ：「departments[0].sales を画面に出すだけのコードに絞って」

グラフが描画されない chart.js と react-chartjs-2 が両方入っているか確認。v4 以降は Chart.register(...) が必要。 AI へ：「react-chartjs-2 の Bar で "bar is not a registered controller" が出ます。最小動作コード一式を」

社内 API のキーを扱うのが不安 キーは .env に隔離、コミットしない VITE_API_KEY などを .env.local に置き .gitignore で除外。AI に渡すときは YOUR_KEY に伏せ字。 運用ルール：AI と共有するコードからは実キーを必ず除去。漏れたら即ローテーションを情シスに相談

まとめ ― 次章への橋渡し

本章で手に入れた "型" は、業務で他の API を触るときもそのまま再利用 できます。 次章（Ch07）では、API から取ってきたデータを クラウドに保存し、複数人で共有する 仕組みに進みます。

この章で身につけた5つの型

エンドポイント／リクエスト／レスポンスの3語で、他システム連携が説明できる 配列＝行の繰り返し、キー＝列。console.log で構造を先に確認 ASCII 図や整形済み1件を添えるだけで、単位・並び・記号がブレない 用途・条件・形式・判断軸の4要素を揃えて AI に依頼、最終判断は人間 「何をした・何が起きた・何を期待」。CORS は対処ルート4択を頭に置く

🔷 次章へのバトン API で取れたデータを、Firebase など クラウドDB に保存して共有 する仕組みを学びます。チームで使える業務ツールへ昇格させる回です。

🎯 今週の実務アクション — 自部署で毎月コピペしている Excel レポートを1本だけ思い浮かべ、 「もしこれが API で取れたら、この章で学んだ Few-shot で何行のコードで片付くか」を AI に壁打ちしてみてください。 明日の定例の議題が1つ増える ところが、本章の本当のゴールです。

この章のゴール

GOAL

散らばった顧客問い合わせ Excel を、部門横断で共有できるクラウド管理アプリに変える

営業・サポート・開発で別々に管理している「顧客からの問い合わせ」を 1 箇所に集約し、誰のブラウザからでも同じ最新データを参照できる状態にします。今までメールと Excel で属人化していた情報が、AI と連携するための「社内データ基盤」に変わります。

01 理解する

LocalStorage の限界と、クラウド DB が解決する業務課題

02 作る

Firebase をセットアップし、AI と協働して CRUD 画面を実装する

03 守る

API キー管理・AI に渡してはいけない情報を業務ルール化

業務フロー: この章でつくる「顧客問い合わせ台帳アプリ」

① 顧客名・問い合わせ内容・担当者を入力 → ② クラウド DB (Firestore) に保存 → ③ 他部署の PC/スマホでも同じ一覧が見える → ④ 誰でも更新・完了マークを付けられる。Excel 共有の限界「更新衝突・見えない最新版」を同時に解決します。

この章で触れるファイル・ツール

ファイル / ツール 役割 業務での位置づけ https: Firebase の管理画面（GUI） サービス申込み・利用状況の確認 src/firebase.jsFirebase 接続コード（プロンプトの「文脈」） 社内システム接続設定の標準ファイル.env.localAPI キーなど秘密情報の保管場所 社内パスワード管理の最小単位prompts/crud.md` チーム共有のプロンプト雛形 属人化を防ぐ「業務手順書」 Firestore セキュリティルール DB へのアクセス権限を書く設定 社内データのアクセス制御台帳

用語ミニ辞書 ― 先に "言葉の地図" を持っておく

この章ではクラウド DB 関連の専門用語がいくつか出てきます。厳密な定義は本文で順に扱いますので、まずは業務アナロジーで大まかに把握してください。ここで "何となく" 意味が結びついておくと、後半のプロンプト例が読みやすくなります。

認証・DB・ファイル保管を 1 セットで提供するクラウドサービスです。"裏方機能のサブスク" に近いイメージです。 ソースコードが公開されており、誰でも改変・再配布できるソフトウェアです。Supabase や PostgreSQL が代表例です。 OSS の代表的な本格 SQL データベースです。表形式で集計やレポート出しを得意とし、Supabase の心臓部となっています。 各行の項目構成が自由な DB のことです。Excel の行ごとに列数が違ってよいイメージで、Firestore がこの方式です。 「この行は誰が読み書きできるか」を 1 行ごとに制御する仕組みで、Supabase の強みです。 サーバーと一度つながったら切らずに、双方向でメッセージを流し続ける仕組みです。社内チャットの常時接続が近い使われ方です。 誰かが書き換えたら他の画面も即座に反映される動作のことです。内部では WebSocket と差分通知を使っています。 Google 製の NoSQL（スキーマレス）クラウド DB で、本章の主役です。Excel より "カードの束" に近い構造を持ちます。

Tips: 完全に暗記する必要はありません

本文で再登場したときに「辞書で見た用語だ」と戻ってこられれば十分です。業務で新サービスを評価するときも、まず用語を 1 行の業務アナロジーに翻訳するのが近道です。

LocalStorage からクラウド DB へ

前章までの LocalStorage は「自分のブラウザの引き出し」。クラウド DB は「社内 NAS の共有フォルダ」。業務で使えるかどうかは、この差で決まります。 ※ 差分同期 とは、誰かが 1 行書き換えた瞬間、その差分だけを他の画面へ自動で流すしくみ。裏で WebSocket を使い双方向に更新を通知します（本章の onSnapshot で体験します）。

・同じブラウザからしか見えない ・他部署と共有できない ・容量は 5MB まで ・ブラウザ履歴削除で消える

・どの端末からでも同じ最新データ ・部門横断で同時編集・閲覧 ・数 GB 以上、無料枠で十分 ・自動で差分同期 (WebSocket)

業務視点の 5 軸比較

業務で困る場面 LocalStorage Firestore 実務での意味 出張先のスマホから台帳を見たい ✖ 見えない ✓ 同じ一覧 営業の外出先で即対応 同僚と同時に更新したい ✖ 衝突する ✓ 差分同期 問い合わせ対応の属人化を解消 1000 件以上の履歴を貯めたい ✖ 5MB 上限 ✓ 数 GB+ 年単位のナレッジとして残せる ブラウザを変えたら消えた… ✖ 消える ✓ サーバー保持 退職・PC 入替でも資産が残る 他部署に共有したい ✖ 不可 ✓ URL 共有 部門横断の意思決定が速い

選択肢: Firebase か Supabase か

クラウド DB の代表 2 サービスを、業務導入の観点で比較します。本講座では、最も少ない手順で業務アプリを動かせる Firebase を使って進めます。

Firestore・認証・Hosting が一式。無料枠が厚く、5 分で始められる 高度な SQL 集計は不向き。データ量が増えると課金が読みにくい 社内ツールの試作、属人化した Excel の置き換え、数百〜数千レコード規模 本格的な SQL が使える・Row Level Security で業務権限制御が柔軟 学習コストが少し高い・UI 管理画面は Firebase より地味 既存の社内システム (PostgreSQL) と繋ぎたい、SQL 前提の分析用途 管理画面が直感的。Firestore はスキーマレスで仕様変更に強い 学んだ考え方は Supabase でもそのまま応用可能 まず動くものを作り、業務で通じたら Supabase 版に載せ替える進め方

Tips: 「サービス選定」自体が実務スキル

社内で新ツールを選ぶときも、評価軸は同じ。「◎ 得意／△ 苦手／誰に合うか」の 3 点を押さえて稟議書やチャットで共有すれば、技術を知らない上長にも判断材料を渡せます。

CRUD ― データ操作の基本 4 語

どんな業務アプリも、データへの操作は 4 種類しかありません。頭文字を取って CRUD (クラッド) と呼びます。顧客問い合わせ台帳アプリに当てはめて覚えてしまいましょう。

業務フローに重ねると

① 顧客から問い合わせが来る → C で台帳に記録 ② 朝会で担当者が一覧を確認 → R で絞り込み ③ 対応進捗を更新 → U で状態を切替 ④ 誤登録を整理 → D で削除

この 4 つの組み合わせで、社内の受発注システムも、ナレッジベースも動いています。

新しい問い合わせを登録: 顧客名・内容・担当者を入力 一覧表示と検索: 未対応案件や〇〇社の問い合わせを絞り込み ステータス変更: 「対応中 → 完了」や回答内容の追記 重複登録やテスト投入の取り消し、誤入力の整理

Tips: まず R → C の順で作る AI に依頼するときは「一覧表示 (R)」→「追加 (C)」→「更新 (U)」→「削除 (D)」の順で。表示が動けば残りはコピー感覚で増やせます。

HTTP メソッドを 1 語で — GET = 読む ／ POST = 新規追加 ／ PUT = 更新 ／ DELETE = 削除。SQL なら SELECT / INSERT / UPDATE / DELETE に対応します。名前が違うだけで考え方は同じです。

Chain-of-Thought（思考の連鎖）― AI に段階的に考えさせる

複雑な機能を 一度にまとめて 依頼すると、AI は重要な仕様を省略した回答を返します。 ステップで区切って考えさせる と、業務レベルで使える精度になります。これを Chain-of-Thought（思考の連鎖）と呼びます。

「Firebase を使ったリアルタイム同期の顧客問い合わせ管理アプリを作ってください」 重要な仕様が抜けたまま一気にコード生成 → 手戻り多発 「以下のステップで順番に考えて。STEP1 必要な Firebase サービス／STEP2 コレクション設計／STEP3 CRUD 関数設計／STEP4 リアルタイム同期。各 STEP を説明してからコードを出力」 設計が先に言語化されるのでレビューしやすく、どこで詰まったか追跡可能

なぜ効く ①

各 STEP に「考える余地」が生まれ、飛躍した推論が減る

なぜ効く ②

どの STEP で誤ったか特定でき、そこだけやり直せる

なぜ効く ③

コードに論理構造が残り、後から読んでも直しやすい

PROMPT 顧客問い合わせ台帳アプリ ― 段階設計プロンプト（貼り付け用）

あなたはシニア Web エンジニアです。以下のステップで順番に考えてください。 STEP1 Firebase で使うサービスを挙げ、なぜ必要か説明 STEP2 コレクション inquiries のフィールド設計 (名前・型・必須/任意) STEP3 CRUD を行う関数シグネチャを TypeScript 風に列挙 STEP4 onSnapshot でリアルタイム同期を追加する方針 各 STEP を 3 行で説明 → STEP4 末尾で src/App.jsx のコード提示。業務ドメイン: 営業部の顧客問い合わせ管理

Firestore の基礎モデル ― コレクションとドキュメント

セットアップに入る前に、Firestore が どんな形でデータを入れる箱なのか を 1 枚だけ頭に入れておきます。ここを押さえると、後の AI プロンプトで「inquiries コレクションに customer フィールド…」という言い回しがすぐに理解できるようになります。

3 階層だけ覚える

① コレクション (Collection) "箱" や "シート名"。例: inquiries (問い合わせ台帳)

② ドキュメント (Document) "1 行" や "1 枚のカード"。自動で ID が振られる

③ フィールド (Field) "列" や "カードの項目"。名前と値のペアで持つ

Excel で言い換えると

・シート名 = コレクション ・1 行 = ドキュメント ・列 (セル) = フィールド

違いは、行ごとに列の数や種類が違っても OK なこと (= スキーマレス)

構造図 (顧客問い合わせ台帳の例)

📁 inquiries (コレクション) ├─ 📄 abc123 (ドキュメント) │ ├─ customer : "A 社" │ ├─ content : "納期相談" │ ├─ owner : "田中" │ └─ status : "open" ├─ 📄 def456 (ドキュメント) │ ├─ customer : "B 社" │ ├─ content : "見積希望" │ └─ status : "done" └─ 📄 ...

Tips: ドキュメント ID (abc123) は Firebase が自動生成してくれるので、最初は気にする必要はありません。customer など フィールド名 だけを設計すれば動き始めます。

プロンプトで使うときの定番フレーズ

「コレクション inquiries に customer (str) / content (str) / status ("open"|"done") のフィールドを持つドキュメントを保存してください」 ― この 1 文だけで AI は Firestore 用のコードを的確に書いてくれます。

Firebase セットアップ ― 6 ステップ

`https:

npm create vite@latest inquiry-app -- --template react cd inquiry-app && npm install npm install firebase

ブラウザで `https:

左メニューの「構築」→「Firestore Database」→「データベースの作成」→ テストモード を選択 → ロケーションは asia-northeast1 (東京)。

Project Overview 左の ⚙ (歯車) → プロジェクトの設定 → ページ下部 マイアプリ で </> (ウェブ) を選択 → 表示される apiKey / projectId などをコピー。

ルート直下に .env.local を作成。全項目に VITE_ プレフィックス必須 (次ページ詳細)。

initializeApp と getFirestore を import し、db を export。以降のコードはここから取得。

.env.local ― API キー保管場所 bash # .env.local（.gitignore に自動で含まれる） VITE_FIREBASE_API_KEY=AIzaSy... VITE_FIREBASE_AUTH_DOMAIN=inquiry-xxx.firebaseapp.com VITE_FIREBASE_PROJECT_ID=inquiry-xxx

⚠ 「テストモード」は 30 日で期限切れ ― 期限後は Firestore ルールを明示更新。「急に保存されない」事故の定番原因。

src/firebase.js ― 初期化と DB 取得 javascript import { initializeApp } from "firebase/app"; import { getFirestore } from "firebase/firestore"; export const db = getFirestore(initializeApp({ apiKey: import.meta.env.VITE_FIREBASE_API_KEY, authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN, projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID, }));

プロンプトテンプレート ― 再利用できる雛形

同じ種類の依頼は、毎回ゼロから書かず テンプレ化して空欄を埋める のが業務効率化の基本です。品質がブレず、チーム共有にも使えます。

以下の Web アプリに 顧客問い合わせ一覧画面 を追加してください。 【データベース】サービス Firebase Firestore／コレクション inquiries／フィールド customer (str) / content (str) / owner (str) / status ("open"|"done") / createdAt (timestamp) 【追加する機能】status="open" を新しい順に 20 件表示、行クリックで詳細モーダル、"done" に更新するボタンを各行に 【制約】既存機能は変更しない／Firebase SDK モジュラー版 (v9+)／エラーは画面上部に表示 (alert 禁止)／関数に日本語 JSDoc 【現在のコード】（src/App.jsx 全文を貼り付ける）

空欄の埋め方 4 原則

① コレクション名は英小文字の複数形 (inquiries / customers) ② フィールドは「型」まで書く ― 後で集計式を立てやすい ③ 機能説明は動詞で終わる 1 文 (「〜する」「〜できる」) ④ NG 動作（「alert 禁止」など）も明示すると AI の出力精度が上がる

業務で使い回せる派生テンプレ

派生テンプレ 書き換える空欄 画面 UI 調整 色・角丸・余白・フォントサイズ 検索機能追加 フィールド名・完全／部分一致 CSV エクスポート 対象列・ファイル名・区切り文字 権限制御 ロール・読み書き可否・例外

Tips: チームで "プロンプト集" を持つ

prompts/ フォルダに .md 形式で Git 管理すると、AI 活用が "個人技" から "部門の資産" に変わります。

複雑なアプリは 3 フェーズに分解

顧客問い合わせ台帳のように 複数技術が絡む アプリは、1 回の指示で作ろうとすると破綻します。Chain-of-Thought と合わせて、設計 → 実装 → 統合 の 3 フェーズに分けます。

実務メタファー: 要件定義 → 設計レビュー → 実装レビュー

エンジニア現場では「要件定義書 → 設計書 → 実装」と工程を区切り、各段階でレビューします。 フェーズをまたぐ前に「これで合ってる？」と聞く 習慣で、後戻りが激減します。

フェーズ間の橋渡し ― コード全文を貼り付けるのが基本

Phase 1 で生成された src/App.jsx の全文を、Phase 2 のプロンプトにそのまま貼り付けます（Mac: Cmd + A → Cmd + C）。AI に "今の状態" を丸ごと見せることで差分提案がズレません。

コードは書かず、ファイル構成・コレクション・機能一覧だけ言語化する 「まだコードは書かないで」と明示する 顧客問い合わせ管理アプリを設計したいです。ファイル構成／DB 構造／機能一覧を整理してください。コードはまだ不要です。 設計書を渡し、まず 1 機能だけ (追加＋表示) を動かす 前フェーズの出力を丸ごと貼り直して文脈を維持する Phase1 の設計をもとに、まず inquiries の追加と一覧表示だけ実装してください。(設計を貼り付け) 残機能 (更新・削除・リアルタイム同期) を追加し、通しで検証 確認手順も AI に同時に出力させる Phase2 のコードに更新／削除／リアルタイム同期を追加し、CRUD 全機能の動作確認手順も列挙してください。

セキュリティを "AI に守らせる"

「完成してから考える」ではなく コードを書いた直後に AI に自己点検させる のが、業務アプリの基本姿勢です。以下のプロンプトは毎回コピーして使用してかまいません。

以下のコードに公開すべきでない情報 (API キー／パスワード／トークン) が直書きされていないか確認し、該当箇所と修正方針を示してください .env.local 経由か／Git 履歴に残っていないか 以下のコードでユーザー入力を表示・保存する箇所を列挙し、XSS／インジェクション対策が必要な行を指摘してください dangerouslySetInnerHTML／文字列結合 SQL 現在のセキュリティルールをレビューし、「社員だけ読み書き可」「自分のレコードのみ更新可」に変更するルールを示してください テストモード／allow read, write: if true 以下のコードで通信失敗・権限エラー時にユーザーへ伝える仕組みがあるか確認し、欠けていれば追加案を出してください try/catch の有無／無言失敗の箇所

Firestore セキュリティルール ― 最小例

セキュリティルール = DB へのアクセス許可を書くミニ言語。Firebase Console → Firestore → ルール タブで編集。まずは "ログイン済みの人だけ読み書き可" から。

rules_version = '2'; service cloud.firestore
match /databases/ database/documents
match /inquiries/ doc
allow read, write: if request.auth != null;

チェック運用リズム

コード書いた直後

①〜④ を AI に投げる

公開前

.gitignore を AI に読ませて確認

公開後

週 1 で再診断。ルール期限切れも検知

AI に渡してはいけない情報 ― 業務の鉄則

生成 AI は業務で活用できますが、入力した情報がサービスの 学習データや処理ログに記録・利用される可能性 があります（サービスによりオプトアウト可否は異なります）。以下 6 分類は、チャット欄やプロンプトに絶対貼らない。業務で判断に迷ったら "入れない" が正解です。

判断フローチャート

Q1. 流出したら誰かが損害を受ける？ YES → 入れない ／ NO → Q2 へ Q2. 秘密保持規程に触れる？ YES → 入れない ／ NO → Q3 へ Q3. ダミー／抽象化で済む？ YES → ダミー化して入れる ／ NO → 上長相談

Tips: 社内に生成 AI 利用ガイドラインがあるか必ず確認。なければ総務に 1 本メール。

OpenAI/Firebase/社内システムの鍵 不正利用で課金発生・データ抜かれる 氏名・住所・電話・マイナンバー 本人同意なき第三者提供にあたる 病歴・診断結果・処方情報 要配慮個人情報 (個情法) 口座番号・カード番号・暗証番号 不正送金・不正決済の原因に 未公開事業計画・顧客リスト・設計書 秘密保持契約違反／営業秘密漏洩 同僚・顧客の情報を無断で 本人同意が必要。信頼を失う

NG → OK 書き換え

顧客 A 社の問い合わせ全文を貼付 「BtoB SaaS の契約更新問い合わせ」と 抽象化 社員名簿 CSV を丸ごと添付 列構造だけ説明、氏名は ダミー apiKey: "AIzaSy..." を貼付 import.meta.env.VITE_* で 変数参照

API キーを安全に管理する ― .env.local 運用

API キーは 「自宅の鍵」 と同じ。GitHub に上げれば世界中に配るのと同義です。Vite では .env.local に書くだけで自動的に Git 管理外になります。本ページでは "まず安全に隠す" までを体験し、.env.local と import.meta.env.VITE_* の仕組みは 第 8 章で詳しく扱います 。

❌ やってはいけない 4 選

✅ Vite の標準作法

VITE_ プレフィックス変数を .env.local に書き import.meta.env.VITE_* で参照します（ビルド時に実値へ置換、VITE_ 無しは undefined）。npm create vite で生成された .gitignore には .env.local が含まれます。

業務ベストプラクティス ― チームで運用する 3 原則

1Password / Bitwarden 等で共有。Slack・Zoom 送信は不可 開発・検証・本番でキーを分け、事故の影響範囲を局所化 迷ったら無効化 → 新規発行を実施。5 分あれば完了する

AI エージェント ― AI が自分で API を叩く時代

ここまでは 「人が AI にコードを書かせる」 構図でした。いま大きな変化は、 「AI が自律的にサービスを使い分けて仕事を進める」 段階に入ったことです。ここまで習得した API・DB・セキュリティの知識は、そのまま AI エージェントへの指示役 として活用できます。

AI エージェントとは

・複数の API / ツールを 自律的に 呼び出す ・結果を見て次に何をすべきか 自分で判断 する ・1 つの目標から 計画 → 実行 → 検証 を繰り返す

Claude Code や Codex などのコーディング AI も、ファイルを読み・コマンドを実行する "エージェント型"。

業務適用の例

「今週入った顧客問い合わせの一覧を要約し、担当者別に割り振って Slack に通知して」

→ Firestore 照会 → 内容分類 → 担当者 API で振分 → Slack API 通知 AI が 4 サービスをまたいで自走する

Y 字分岐: AI 時代の人材ポジション

❌ 使われる側

・AI の出力を評価できない ・仕組みを知らず判断に時間がかかる ・ブラックボックスとして丸投げ

→ AI が強くなるほど役割が細る

⇄

✅ 使いこなす側 (ここを目指す)

・どの API を使うべきか指示できる ・返ってきたデータの正しさを判断できる ・制約・コスト・セキュリティを設計できる

→ AI が強くなるほど価値が増す

この章で学んだ知識はすべて "AI エージェント時代の必修科目"

CRUD／Chain-of-Thought／プロンプトテンプレ／API キー管理／NG データ判定 ― この 5 点セットが揃っていれば、AI エージェントを業務の実行担当として適切に使いこなせます。逆にこれが欠けると、指示が曖昧になり AI が迷走します。

よくあるトラブル Q&A

Firebase 連携でつまずきやすい 4 つを、原因と解決プロンプトの形でまとめました。エラーメッセージをそのまま AI に貼り付けるのが、解決への最短経路です。

Console →「プロジェクト設定」→「マイアプリ」から再取得。1 文字違うだけで繋がらない。 以下の firebase.js で、apiKey と projectId の末尾を私が読み上げるので合致するか確認してください: (値を貼る) 「テストモード」は 30 日で失効。期限後は全拒否。Console → Firestore → ルール で確認。 以下の Firestore セキュリティルールが今も読み書き可能か解析し、期限切れなら延長ルールを示してください: (ルール貼付) VITE_ で始まらない変数は参照不可。.env.local 編集後は dev サーバ再起動も必須。 以下の .env.local と import.meta.env の参照箇所を見比べて、不整合を指摘してください。(両方貼付) permission-denied ならルール、unavailable ならネットワーク／リージョン設定。 以下のコンソールエラーから原因を切り分けて対処方針を 3 つの可能性として示してください: (エラー文貼付)

鉄則: エラーは "3 点セット" で AI に渡す — エラー文全文 ＋ 直前の操作 ＋ 該当コード。揃えるだけで AI の原因特定精度が体感で 3 倍に高まります。業務で上長に報告する時の型とも同じです。

まとめ ― この章で習得した "データ基盤" の型

Excel 共有の限界を、クラウド DB で突破した

LocalStorage → Firestore への載せ替えは、"個人ツール" を "部門横断の業務基盤" に進化させる分岐点でした。

この章の 5 つの武器

LocalStorage と Firestore を "業務 5 軸" で比較判断できる C/R/U/D と HTTP メソッドの対応を業務言語で説明できる 複雑依頼を STEP で区切り、精度と追跡性を両立 空欄 4 原則で再利用可能な雛形をチームに配れる API キー・渡してはいけない情報・自己点検プロンプト

次章への橋渡し

作った "顧客問い合わせ台帳アプリ" を、次章では Git / GitHub Pages で公開します — コードの履歴管理／チームでのレビュー・マージ／インターネット上での公開 URL。

Tips: この章で済ませておく宿題

① .env.local が .gitignore に入っているか確認 ／ ② Firestore ルールの期限をカレンダーに登録 ／ ③ プロンプトテンプレを prompts/crud.md として保存 ／ ④ "自分の部署でクラウド DB に置きたいデータ" を 3 つメモ

業務へ持ち帰る問い — 「今うちの部署で Excel / メール添付に頼って属人化している情報は？」― 次の課題は、そこにあります。

この章のゴール

この章では、手元で動いているアプリを 社内の仲間が URL でアクセスできる状態 まで持っていきます。 『自分の PC でしか動かない』段階から『部署で共有できる』段階への橋渡しがこの章のテーマです。

📘 本章の前提 — 第7章までに作ったプロジェクトを素材に使います

第1〜7章で準備したプロジェクト（例：Vite + React の部署マニュアルサイト）をそのまま使い、 Git で履歴管理 → GitHub に保管 → GitHub Pages で社内公開 の流れを最初から最後まで通しで練習します。 ゼロから何か新しく作る章ではありません。手元のプロジェクトフォルダが開ける状態から始めてください。

走る業務例：部署マニュアルサイトを社内公開する

本章では「新人オンボーディング用の部署マニュアル」を題材に、 Git で履歴を残し、GitHub に保管し、社内の誰でも開ける URL に公開するまでを通しでやります。

これまで Word を Teams に貼って『最新版どれ？』と聞かれていた運用を、 URL 1 本で常に最新が開く 運用に切り替える練習です。

🎯 この章のゴール（業務フロー対応）

・履歴管理 ← バージョン管理／改訂記録 ・クラウド保管 ← 共有ドライブへの格納 ・社内公開 ← イントラ／Teams での展開 ・公開前レビュー ← 上長チェック・情シス確認 ・著作権・セキュリティ ← 社内規程の遵守

手元で変更履歴を記録 クラウドにバックアップ 配布用ファイルに変換 URL 発行／共有 情報漏洩・著作権チェック

本章で使う Git / GitHub コマンド早見

バージョン管理から公開までで 10 コマンド — 一度眺めたら、あとは STEP に沿って順に打つだけ

Git は『ファイル名＿最新_v3_最終版』のようなバージョン管理を卒業するためのツール。GitHub は、その Git の記録を社内・社外に共有するためのクラウド置き場です。本章で使うコマンドは下の 10 個だけ。意味は 後で少しずつ 理解すれば OK。

コマンド 何をする グループ git init バージョン管理を開始（最初の1回だけ） 初期設定 git config --global user.name "..." 自分の名前をGitに登録（誰がコミットしたか用） 初期設定 git add . 変更を "これから保存する箱" に入れる 日常操作 git commit -m "メッセージ" 変更を確定保存（なぜ変えたかをメモ） 日常操作 git push 手元の変更をGitHubへ送る（クラウド同期） 日常操作 git pull GitHub側の変更を手元に取り込む 日常操作 git remote add origin URL 自分のリポジトリをGitHubに紐付け（最初の1回） 初期設定 npm run build 公開用ファイルを dist/ に生成 公開 npx gh-pages -d dist GitHub Pages で URL を発行 公開 .gitignore に追記 node_modules/ や .env.local を除外（機密保護） 保護

🧠 毎日使うのは 4 つだけ

add → commit → push の 3 連コンボ＋必要なら pull。初期設定は最初の 1 回で済みます。

📦 業務アナロジー

commit ＝ 議事録の確定版保存／ push ＝ 共有フォルダへアップ／ pull ＝ 最新を取りに行く。

🔐 .gitignore を忘れない

.env.local（API キーなど秘密情報を書くファイル）や node_modules/ を最初に除外。API キーが漏れると第三者に悪用され高額請求リスクも。

💡 打ち間違えたら

エラー文をそのまま AI に貼り付けて『直し方を教えて』と投げるのが最短。頻出パターンは後半の「よくあるトラブル Q&A」にも掲載。

Git とは — ファイル名でのバージョン管理を卒業する

職場あるある — ファイル名でのバージョン管理の限界

「部署マニュアル_v3_最終_本当に最終.docx」のような名前を職場で見たことはありませんか。やっていること自体は『バージョン管理』なのですが、ファイル名に書くやり方は 誰が／いつ／何を変えたかが残らず、戻すことも難しい のが難点です。

Git はこれをファイル名ではなく 保存の仕組みそのもの で行うツール。保存のたびにスナップショットと変更理由が記録され、いつでも過去の状態に戻せます。

NG：ファイル名でバージョン管理 OK：Git でバージョン管理

❌ ファイル名方式

manual_v1.docx manual_v3_最終_本当.docx

誰が何を変えたか消える／最新判別不能

✅ Git 方式

manual.md（1ファイル）+ コミット履歴 └ 新人歓迎の節を追加（田中） └ 組織改編を反映（田中）

誰が／いつ／なぜ変えたかすべて残る

実務メリット：Git はコードだけでなく Markdown のマニュアルや手順書にも使えます。『ファイル名でバージョン管理していた業務』を丸ごと置き換えられる、汎用性の高い道具です（20 年以上使われる業界標準）。

🕰 いつでも過去に戻せる

誤って削除・上書きしても、コミット履歴からその時点の内容を復元可能。"先週水曜の版" にもピンポイントで戻せます。

👥 誰が変えたかが残る

1 行ごとに著者と変更日時が記録される（git blame）。後任が "なぜこの仕様？" を追える、属人化解消の基盤になります。

🌳 枝分かれで安全に試す

ブランチ機能で "下書きコピー" を作り、本流を壊さず実験可能。失敗したら捨てるだけ、成功したら本流に合流できます。

はじめての Git — アカウントと初期設定

git のコマンドを実行する 前に 一度だけ済ませる準備があります。ここを飛ばすと git commit や git push のたびにエラーで止まります（所要5分）。

Step 1：GitHub アカウントを作る

① https://github.com にアクセス → 右上 Sign up から登録 ② メール認証を済ませてログインできれば OK ③ ユーザー名は公開 URL に入るので、業務で使っても違和感のない名前に

Step 2：手元の Git に自分の名前とメールを教える

$ git config --global user.name "Your Name" $ git config --global user.email "you@example.com"

この 2 行は PC に 1 回だけ 実行すれば OK。メールは GitHub 登録時と揃えると履歴がきれいに紐付きます。

Git はもうインストール済み

第1章のセットアップで Git は既に入っています（Mac：Xcode Command Line Tools／Windows：Git for Windows）。 ターミナルで git --version を実行してバージョン番号が表示されれば準備 OK。

ターミナル（コマンドを実行する場所）はどこ？

・VS Code の「ターミナル」タブ（おすすめ）— Mac：Ctrl+バッククォート／Windows：Ctrl+Shift+バッククォートで開閉 ・ターミナル.app（Mac）／ PowerShell（Windows）

どちらも プロジェクトフォルダに cd した状態 で実行するのが鉄則（例：cd ~/dept-manual → git status）。

ここで詰まる前に知っておくと早い 3 点

🧭 cd で迷子になったら

pwd（現在地を表示）と ls（中身を一覧）で位置確認。VS Code でフォルダを開き「ターミナル」タブを起こせば、自動で正しい場所に cd 済みになります。

🔠 大文字小文字に注意

GitHub のユーザー名やリポジトリ名は 大文字小文字を区別 します。Dept-manual と dept-manual は別物。URL 入力時は元の表記をそのままコピペするのが安全。

📝 user.email は社用？個人？

業務リポジトリには 会社メール を設定するのが原則。社外公開も視野に入るリポジトリは個人用と分けると後で混乱しません（git config --local で個別設定も可）。

Git の基本コマンド 4 つ

日々の業務で使うのはこの 4 つだけ。『選ぶ → 記録する → 送る → 受け取る』のサイクルで回します。

変更したファイルを選ぶ 改訂した節に付箋を貼る 変更を理由つきで記録する 改訂記録を書いて封をする クラウドに送る 共有ドライブに投函する クラウドから最新を取得 最新版を受け取る

コミットメッセージの書き方（部署マニュアル編）

未来の自分や後任が読んで意味が分かるよう、『何をなぜ変えたか』を簡潔に書きます。

git commit -m "新人歓迎ランチの項目を追加" git commit -m "勤怠システムの URL を最新に差し替え" git commit -m "組織改編で所属部署名を更新"

2回目以降は3コマンドだけ

$ git add . $ git commit -m "改訂理由" $ git push

この 3 コマンドを週 1 回回すだけで、バージョン管理の運用は成立します。

GitHub とは — 社内用クラウドストレージ

GitHub = 変更履歴つきのクラウド保管庫

GitHub は、Git で管理したファイルをインターネット上に保管・共有できるサービス。 OneDrive や Google Drive の『エンジニア版』と考えるのが近く、 違いは ファイルのバージョン履歴がすべて残る ことです。

部署マニュアルの運用に置き換えると、こうなります。

・個人 PC のマニュアル原稿 → ローカルリポジトリ（Git 管理下のフォルダ） ・GitHub 上のバックアップ → リモートリポジトリ ・改訂を共有 → git push でリモートに送る ・後輩が最新を取得 → git pull で受け取る

3 つの用語を業務の言葉に翻訳

Git／GitHub 用語 職場での対応物 リポジトリ プロジェクト専用の共有フォルダ コミット 改訂版を封印した1件の記録 ブランチ 下書き用の作業コピー プッシュ 共有ドライブに送る プル 最新を受け取る プルリクエスト 上長への改訂レビュー依頼

💡 なぜ GitHub を使うのか — 社内でも同じメリットが効く

① 履歴が消えない ファイルを壊しても、過去のどの時点にも戻せる。"先週の版に戻して" に即答できる。

② 複数人の同時編集 後輩が勤怠の節を更新し、あなたが歓迎会の節を更新しても衝突せずマージできる。

③ 公開URLが作れる 本章のゴールである GitHub Pages は、この GitHub 上のファイルをそのまま公開する機能。

✅ 業務で効く Public／Private 使い分け

Public：社外公開ツール・OSS への貢献。GitHub Pages も無料利用可。 Private：社内限定ツール・機密を含む検証。社員間で招待制。どちらも履歴機能はフル活用可能。

⚠️ 先に知っておく注意点

Public リポジトリは 世界中から検索可能。API キー・個人情報・社内機密を一度でも push すると履歴に残り、削除しても跡が残る。公開前チェックを徹底（本章「公開前チェック — NG → OK で直す」）。

リポジトリを作ってコードを送る

部署マニュアル用のリポジトリを作り、手元のファイルを GitHub へ送るまでを、 初回セットアップ と 2回目以降の運用 に分けて整理します。

初回セットアップ — 1度だけ走らせる手順

1. GitHub の「+」→ New repository
2. リポジトリ名：dept-manual（例）
3. 「Public」を選択（GitHub Pages で公開するため）
4. Create repository をクリック
5. 手元で git init → リモートを紐付け → 初回 push

$ git init $ git add . $ git commit -m "初版：部署マニュアル" $ git remote add origin https: $ git branch -M main $ git push -u origin main

2 回目以降の運用 — 3 コマンドで回す

改訂のたびに叩くのはこの 3 つだけ。 週 1 回 / 月 1 回のルーチンとして固定できます。

$ git add . $ git commit -m "勤怠手順を最新化" $ git push

.gitignore を確認：node_modules ／ dist ／ .env.local は既定で除外されます。特に API キーを書いた .env.local がリポジトリに入っていないかは push 前に必ずチェック。

🔑 push の前に：Personal Access Token（PAT）を発行

git push のパスワード欄には GitHub のログインパスワードは使えません。代わりに PAT を発行して貼り付けます。

発行手順：GitHub 右上アイコン → Settings → 左メニュー下部 Developer settings → Personal access tokens → Tokens (classic) → Generate new token (classic) → スコープは repo にチェック → Generate → 表示された ghp_ で始まる文字列をコピー。

⚠️ 一度しか表示されない トークン文字列はこの画面でしか出ません。パスワードマネージャー（1Password / Bitwarden 等）に コピー&保存 してから画面を閉じてください。再発行は可能ですが、過去のトークンは無効化されます。

🤖 AI にセットアップを任せるプロンプト（コピペして末尾だけ書き換え）

あなたは Git/GitHub に詳しいメンターです。以下のプロジェクトを GitHub に上げる手順を、zsh で叩くコマンド列と、各コマンドの成功時の出力例をセットで教えてください。

【前提】（↓ ここを自分の環境に書き換えてください） ・OS：macOS／ターミナルは zsh ・プロジェクトフォルダ名：dept-manual ・リポジトリ名も dept-manual、公開設定は Public ・Vite で作った React アプリ（npm run dev で起動中）

💡 プロンプト使い方のコツ

・Windows の人は「OS：Windows 11／ターミナルは PowerShell」に書き換え ・エラーが出たら、出力をそのまま貼って「このエラーの原因は？」と続ければ会話で解決

push が通った／通らなかったを見極める

✅ 成功時のターミナル出力（抜粋）

To https:

• [new branch]　 main -> main branch 'main' set up to track 'origin/main'.

・new branch または ... -> main の行が出れば push 成功 ・直後に GitHub のリポジトリ画面をリロード → ファイル一覧が反映される

⚠️ よく出る 3 つのエラーと一次対応

① Authentication failed → PAT を貼っていない／古い PAT。新しい PAT を発行して再 push。

② remote: Repository not found → URL タイプミスの可能性大。git remote -v で URL を確認。

③ failed to push some refs → GitHub 側が手元より新しい。git pull --rebase してから再 push。

ビルドと GitHub Pages で社内公開

社内に URL を渡すためには、開発中のコードを 誰のブラウザでも開ける形 に変換する「ビルド」が必要です（HTML / CSS / JavaScript のセットに固める作業）。npm run dev はあくまで開発用の一時サーバーで、他人の PC からは見えません。

📡 localhost って何？ `http:

自分だけ（localhost） npm run dev dist/ に配布物を生成 npm run build リンクを知る社内の人全員 npm i -D gh-pages → npx gh-pages -d dist

Step 1：vite.config.js（プロジェクト直下）に base を追記

export default defineConfig({ base: '/dept-manual/',
plugins: [react()], })

Step 2：gh-pages パッケージを入れてからビルド＆公開

$ npm install -D gh-pages
$ npm run build $ npx gh-pages -d dist

🌐 発行される URL の形

https:

・Teams や社内 Wiki にこの URL を貼れば、部署のみんなが開けます ・改訂時は npm run build → npx gh-pages -d dist で即反映 ・反映されない時はキャッシュを疑う（Cmd + Shift + R）

Step 3：Settings → Pages で公開設定 リポジトリ Settings → Pages で Source: Deploy from a branch ／ Branch: gh-pages ／ Folder: /(root) を選び Save（初回は Step 2 実行後にブランチが現れます）。

⚠️ 落とし穴 base: '/dept-manual/' はリポジトリ名と完全一致させる。ズレると CSS／JS が読めず 真っ白な画面 に。

デプロイ後の運用 — 動作確認と社内告知の型

🧭 デプロイ後 5 分でやる動作確認

① 自分でブラウザから開く 公開 URL を直接入力。404 や真っ白画面が出ないか確認。出た場合は base 設定とリポジトリ名の一致をチェック。

② 別端末・別アカウントで開く スマホ／同僚 PC でも開けるか確認。自分だけ開ける場合は Pages 設定が Public か再確認。

③ 改訂を 1 回回す 1 行直して push → npx gh-pages -d dist。数分以内に反映されれば運用フロー成立の合図。

📢 社内告知 Teams 投稿テンプレート（コピペ可）

皆さま、部署マニュアルサイトを公開しました 🎉 URL：https: 使い方：ブラウザのお気に入りに登録 → 改訂は週 1 で反映 見えない／古い時：Cmd + Shift + R で強制リロード 気付いた誤りは私（@自分）まで Teams DM ください。

最初の投稿が浸透の鍵。URL だけ貼らず "使い方 + 連絡先" を添えると、後追い問い合わせが激減する。

🛠 公開後の運用カレンダー — 部署マニュアル運用の型

毎週 改訂分を 1 回 push + 公開。Teams に「今週の更新点」を 3 行サマリで投稿。

毎月 古い情報の棚卸し（リンク切れ／組織変更／システム更新）を 30 分で。

四半期 アクセス数・問い合わせ件数を集計し、上長と共有。"運用効果" を可視化。

半年〜年 1 情シス／法務に再点検依頼。社内規程の改定に追従して再レビューする。

公開前チェック — NG → OK で直す

公開ボタンを押す前に、"誰でも読める場所にそのまま置いて大丈夫か" を確認します。 特に気をつけるのは 個人情報 と API キー／機密情報。

田中太郎（本名）を サンプルユーザーとしてコードに記載 「サンプル 花子」など架空の名前に差し替える 公開後は誰でも閲覧可能。実在社員の名前は流出扱い

apiKey: "AIzaSy..." をそのままソースに記載 .env.local に書き、.gitignore で除外 Public リポジトリでは丸見え。悪用で高額請求リスク

console.log(社員番号) がデバッグ用で残っている 公開前に全削除。必要ならコメントアウトでなく削除 ブラウザの開発者ツールから誰でも中身を見られる

テスト用に入れた社員データ 20 件がそのまま 架空データに置換、または空状態でデプロイ 社員名・役職・連絡先が社外流出する可能性

AI に公開前レビューを頼む — コピペで使えるプロンプト

あなたはセキュリティレビュアーです。以下のコードを Public リポジトリに公開する前提で、次の 5 観点で 1 件ずつ指摘してください。該当箇所（ファイル名と行番号）と修正方法をセットで。

① 個人情報（氏名・住所・電話・メール・社員番号）のハードコード ／ ② API キー・パスワード・トークンの直書き ／ ③ console.log などのデバッグ出力 ／ ④ テスト用ダミーデータの残存 ／ ⑤ XSS など基本的なセキュリティ脆弱性

【対象コード】（↓ ここに対象ファイルを貼り付け。全ファイル一括は精度が落ちるため、src/App.jsx ＋ 依存 1 ファイル程度に分けるのがおすすめ）

著作権とライセンス — AI 時代の基本

社内公開とはいえ、使った素材の権利処理は実務では避けて通れません。 生成 AI が作ったもの ／ 他人が作ったもの ／ 自分が作ったもの を区別して扱います。

AI 単体は著作権を持てない。人が意図を持って指示・編集していれば その人 に著作権が生じ得る 丸投げ出力は社内規程に沿って扱う。商用利用時は各サービスの利用規約を必ず確認 ネット画像・他社ロゴ・有料フォントは、社内使用でも 許諾が必要 な場合が多い 利用可否を社内法務／情シスに確認。代替はフリー素材サイトか画像生成 AI 自由に使える代わりに ライセンス条項 を守る必要がある（著作権表示・同一ライセンス継承など） package.json の依存ライブラリのライセンスを確認。MIT / Apache 2.0 は比較的使いやすい

主要 OSS ライセンス — 業務で遭遇する3種類

ライセンス 社内利用時の義務 社内向け難度 MIT 著作権表示を残すだけ やさしい Apache 2.0 MIT + 特許に関する条項を守る やさしい GPL GPL のコードを使ったソフトを 社外に配る場合 は、ソースコードも同じ GPL で公開する義務（社内で使うだけなら対象外） 要確認

自分のリポジトリを公開するときは MIT を選ぶのが無難。社内向け用途でも、後から社外公開へ広げやすくなります。

実務の確認フロー

1. マニュアルに使う画像・文章の 出どころ を一覧化する
2. 各素材の 利用条件 を確認（社内規程／利用規約）
3. グレーな素材は 差し替え or 許諾取得
4. 生成 AI 出力には AI 生成である旨 を注記しておく

自分のアカウントを守る — 強いパスワードと 2FA

アプリを公開するエンジニアとは、社内の情報を預かる立場 でもあります。 GitHub / 業務ツールのアカウント乗っ取りは、即座に情報漏洩に直結します。

強いパスワードの3条件

・12文字以上、英大小 + 数字 + 記号を混ぜる ・氏名・誕生日・社員番号など 推測できる情報 は使わない ・サービスごとに 別のパスワード にする

おすすめ：パスワードマネージャー

1Password / Bitwarden などで、 サービスごとのパスワードを自動生成・自動入力。 覚える必要があるのはマスターパスワード1つだけ。

会社で推奨ツールが決まっている場合はそれに従います。

二段階認証（2FA）— もう1段の鍵

パスワードに加えて、スマホのアプリが生成する 6桁コード を入力する仕組み。パスワードが漏れても、スマホがなければ入れません。

2FA を設定すべきアカウント優先順位

順位 アカウント 理由 1 会社メール ここを取られると全部の再発行先に 2 GitHub ソースコード・APIキーの保管庫 3 業務ツール（Slack 等） 機密やりとりの温床 4 銀行・SNS 金銭・レピュテーション被害

💡 社内展開時の小ワザ — 2FA 必須化を "部署ルール" にする

部署のマニュアルサイトに「GitHub は 2FA 必須」と書き添えるだけで、後輩・新人の初期セットアップから安全側に倒せます。あなたが部署に最初に根づかせる 小さな安全文化 になります。

フィッシングの見分け方 — Y字分岐で判断

社内でアプリを公開すると、それになりすました偽メール が届く可能性があります。 「パスワードを確認してください」というメールが来たとき、何を見て判断するか。

📧 シナリオ： 「【緊急】GitHub アカウントが停止されます。24時間以内にログインしてパスワードを確認してください」というメールが届いた

❌ やりがちな NG 対応

・焦ってメール内のリンクを すぐクリック ・似たログイン画面が出たので いつものパスワードを入力 ・2FA コードまで 入力してしまう

結果 認証情報がそのまま攻撃者へ。乗っ取り後にリポジトリや API キーを抜かれ、業務情報が流出。

✅ 正しい対応フロー

・まず深呼吸。「至急」「停止」は疑いのサイン ・送信元アドレスを確認 → support@githuub.com など微妙な綴り違いに注意 ・メール内のリンクは押さず、自分でブラウザに github.com と入力して直接ログイン ・不審ならメールを情シス／上長に転送して相談

原則 『焦らせる・急かす・怖がらせる』表現が揃った時点で、99%フィッシング。

💡 Tips 1

ブラウザのブックマークから公式サイトに入るクセをつける。検索結果の上位にも偽サイトが混じる時代。

💡 Tips 2

社内で似た被害報告が出たら、部署マニュアルに事例を追記。集合知として残すのが再発防止の近道。

💡 Tips 3

誤ってクリック・入力してしまったら、即パスワード変更 + 2FA 再設定 + 情シス報告の3手を即実行。

よくあるトラブル Q&A

GitHub は 2021 年からパスワード認証を廃止。Settings → Developer settings → Personal access tokens で repo 権限のトークンを作り、push 時のパスワード欄にそれを貼る。 トークンは一度しか表示されないので、パスワードマネージャーに保存してから閉じること エラー文に表示されるファイル名・行番号の該当箇所を確認。npm run dev で開いてブラウザコンソールにエラーが出ていないか先に見る。node_modules を消して npm install で直ることも。 エラー文をそのまま貼り付けて「このビルドエラーの原因と修正案を3つ」と聞くと早い vite.config.js の base: '/リポジトリ名/' がリポジトリ名と完全一致しているか／Settings → Pages の Branch が gh-pages になっているかを確認。反映には数分かかることも。 ① base 設定 → ② Public か → ③ gh-pages ブランチの有無 → ④ キャッシュ強制リロード（Cmd+Shift+R） npm run build → npx gh-pages -d dist を再度実行。社内の人には「Cmd + Shift + R（Win は Ctrl + Shift + R）で強制リロードを」と一言添えると混乱が減る。 改訂のたびに部署の Teams に「更新しました／強制リロード推奨」と告知する型を作る

まとめ — 次は卒業制作へ

🚀

自分のアプリを社内で動かせる状態になりました

「部署マニュアルサイト」を例にしましたが、同じ手順はどんな社内ツールにも使えます。 Git で履歴 → GitHub に保管 → Pages で公開 — これが 社内展開の型 です。

この章で身についた 5 つの型

1. Git でファイル名でのバージョン管理
2. GitHub を "履歴つき共有ドライブ" として使う
3. npm run build で配布用ファイルに変換
4. GitHub Pages で社内に URL を渡す
5. 公開前に個人情報・API キー・著作権を確認

次の一歩 — 卒業制作（第9章）

ここまで身につけた 企画 → 実装 → 公開 の型を、自分の職場の業務課題に当てはめて 1 本作り切ります。 この章の "社内公開" は卒業制作の最終ステップそのもの。 胸を張って次の章へ進みましょう。

この章を自分の業務に落とすチェックリスト

① 自分の対象を決める

部署マニュアル／手順書／FAQ／ミニ業務ツール — Git 管理で一番得する業務資産を1つ選ぶ。

② 1週間だけ運用

まず自分 1 人で、週1 push の習慣をつける。改訂理由をコミットメッセージに書く型を固める。

③ 部署に共有

URL を Teams に貼り、改訂フローを1枚紙でまとめる。部署で 最新版が1つに揃う 状態を作る。

この章のゴール

この章では、01〜08章で学んだすべてのスキルを総動員して、 自分だけのオリジナルWebアプリを完成させます。

【この章でやること】

1. テーマを決める — 自分の「あったらいいな」をアプリにする
2. 企画書を作る — ターゲット、機能、スケジュールを整理する
3. AIと一緒に開発する — チャットAI・画像生成AI・コーディングAIを連携させる
4. 発表の準備をする — デモとプレゼンで成果を伝える
5. 振り返りとこれから — 習得スキルの整理、ポートフォリオ化、キャリアパス

いわば、これまでの学びの集大成です。 料理教室でレシピを習い続けた人が、最後にフルコースを仕上げる感覚に近いでしょう。 自信を持って取り組みましょう。

実務の「要件定義フロー」を1人で回す

エンジニアの現場では、コードを書く前に「何を・誰のために・どう作るか」を固める要件定義フェーズがあります。 本章のロードマップは、まさにその業務フローをAIと二人三脚で圧縮したものです。

※ 読み方：左＝本章の学習ステップ ／ 右＝実務での該当フェーズ（例：『テーマ決定』は実務の『課題発見・ユーザーヒアリング』にあたる）

・テーマ決定 ← 課題発見・ユーザーヒアリング ・企画書作成 ← 要件定義書ドラフト ・AI協働開発 ← 設計〜実装 ・発表準備 ← レビュー・リリース説明 ・振り返り ← 保守・次期改善計画

ベテランが数日かけていた要件定義も、AIを相棒にすればその日のうちに形にできます。 卒業制作は、その「AI時代の進め方」を自分の手で体感する機会です。

卒業制作の5日間フロー早見

5日間で "業務課題を1件、最後まで解ききる" の全体像 — 毎朝このページに戻れば自分の立ち位置が分かる

卒業制作は Day 1〜5 の決まった手順 で進めます。各 Day の成果物と、どの AI を主に使うかを下表に整理しました。前章までで使った3種類の AI（チャット／コーディング／画像）を場面で使い分けながら、1本の業務ツールを仕上げるのがゴールです。

フェーズ やること 詰まったら見る章 主に使うAI 成果物 Day 1 テーマ決定・企画書ドラフト 第1章（対話の型）／第5章（プロンプト設計） チャットAI 企画書1枚（7項目） Day 2 機能分解・スケジュール設計 第5章（黄金パターン） チャットAI 機能一覧／Day3〜5工程表 Day 3 MVP 実装（"1本の線" を通す） 第2〜5章（実装の型） コーディングAI 動く最小版（1機能だけOK） Day 4 デザイン・画像・仕上げ 第3章（デザイン）／第6・7章（データ） 画像生成AI＋コーディングAI 提示可能版（色・ロゴ・UI整え済） Day 5 GitHub公開・デモ・事例集化 第8章（公開） チャットAI 公開URL／README／事例集エントリ

💬 チャットAI の出番

企画・文章・振り返り が中心。業務課題を言語化・整理する相棒。Day 1・2・5 で活躍します。

🤖 コーディングAI の出番

実装・修正・デバッグ が中心。Day 3・4 で手を動かすパートナー。第2〜8章の型をそのまま再利用。

🎨 画像生成AI の出番

ロゴ・バナー・アイコン 生成。Day 4 で "見栄え" を整えるときに使う。第3章のテクニックをそのまま適用。

🎯 Day 3 の MVP が最重要マイルストーン

どんなに粗くても Day 3 の終わりに "入力 → 処理 → 出力が一通り動く状態（=1本の線が通った状態）" を作れるかが分かれ道。Day 4・5 は磨きと共有なので、MVP が動いていれば卒業制作は合格圏内に入ります。完璧を目指さず、最小で動く ことを最優先に。

テーマの選び方

「今の会社でできなかったこと」を練習台にする

卒業制作のテーマは、"今の仕事で手をつけられずにいた課題" から選びましょう。 ずっと手作業でやっていたこと、Excel で管理しきれなくなった情報、 毎回同じ説明をくり返している業務——そんな身近なモヤモヤこそ、一番良いテーマです。

業務からテーマを拾う4つの問いかけ

・くり返している手作業で、時間を奪われているものはないか？ ・Excel 管理の情報を、もっと見やすく・使いやすくできないか？ ・毎回同じ説明をしていないか？（＝FAQ 化できる） ・「これ、まだ手作業でやっているな」と薄々気づきながら、放置している業務はないか？

迷ったらここから — 業務課題ベースのテーマ例10選

No. テーマ 解きたい業務課題 1 チームTodo・タスク管理 「誰が何をいつまで」をSlackやExcelに散らさず1画面で共有 2 議事録テンプレート 定型項目の自動入力で、メモから共有までの時間を半減 3 社内FAQ検索 同じ質問への繰り返し回答を削減 4 業務マニュアルサイト 新人オンボーディングを短縮、属人化を解消 5 作業ログ・工数記録 手書きタイムシートを脱却し、工数を可視化 6 日報・週報フォーマッタ 毎日のレポート作成を定型化、管理職も読みやすく 7 備品・在庫チェックリスト Excel 台帳を Web 化し、複数人で同時編集 8 KPIミニダッシュボード CSV を貼り付けるだけで数値をグラフ表示 9 顧客・取引先リスト タグ付けと検索で「あの会社どこだっけ」を解消 10 社内アンケート集計 結果の自動グラフ化で、共有までワンクリック

企画書の書き方

AI と "企画パートナー" として

テーマ選びと同じく、企画書も "ひとりで書き切る" 必要はありません。AI を企画パートナーとして呼び出し、対話しながら7項目を一緒に埋めていきます。

職場のキックオフ資料を、上司や同僚とブレストして作るのと同じ感覚です。

💡 進め方の3ステップ

① 右の "投げるプロンプト" をコピペして AI に送る

② 返ってきた7項目を下表にメモ

③ "自分の職場の言葉" に書き直す

AI と一緒に埋めた企画書

記入例：議事録テンプレートアプリ

項目 AI と決めた内容 ① 名称 「MeetingMemo 〜議事録らくらく〜」（仮でOK） ② 概要 会議の定型項目を自動入力し、共有までワンクリックで済ませる Web アプリ ③ ターゲット 毎週の定例で議事録を手動作成している営業チームのリーダー ④ 主な機能 会議情報の入力／テンプレート自動生成／Markdown コピー ⑤ 使用技術 Vite + React / CSS / LocalStorage / 生成 AI API ⑥ 画面イメージ 入力フォーム → プレビュー → コピーボタンの流れを紙に手書き ⑦ スケジュール 5日間の作業計画（次ページで詳しく説明）

AI の案はそのまま採用せず、"自分の職場の言葉" に書き直してから次ページのスケジュール設計へ進みましょう。

AI へ投げるプロンプト

コピペして末尾の業務課題だけ書き換え

あなたは私の企画ブレスト相手です。下に書いた業務課題を解決する Web アプリについて、5日間で完成できる規模で、次の7項目を提案してください。

① プロジェクト名 ② 概要（1〜2文） ③ ターゲットユーザー ④ 主な機能（3〜5個） ⑤ 使用技術 ⑥ 画面イメージ（UI の大まかな流れ） ⑦ 5日間のスケジュール

【業務課題】 （↓ 自分の職場の状況に書き換える） 毎週の定例会議で議事録を手書きしており、清書と共有に毎回1時間かかっている。

スケジュールの立て方

卒業制作は1日1時間 × 5日間（合計5時間）を想定しています。 要点は Day 3 の終わりに「最低限動く MVP」があること。残り2日で磨き込みと社内共有に回します。

「議事録アプリの機能を5つ提案して」／紙に画面フローを描く npm create vite@latest ／「入力フォーム UI を src/App.jsx に」 「入力情報から議事録テンプレートを生成する関数を src/App.jsx に」 「LocalStorage 保存」「Markdown コピーボタン」を追加 README／GitHub Pages 公開／社内デモ練習

🛠 Day 3 の具体的な指示 — 「関数を書いて」を一段ブレイクダウン

・シグネチャ例：generateMinutes({ meetingName, date, attendees, topics }) → string（Markdown 文字列を返す） ・保存先：src/App.jsx 内（別ファイルに分けず、まず1ファイルで1本通す） ・動作確認：DevTools の Console（console.log(generateMinutes(...))）または画面のプレビュー欄で Markdown を目視

🎯 最重要マイルストーン — Day 3 で「MVP を1本の線で通す」

Day 3 終了時点で「入力 → 生成 → 表示」の線が通っていれば合格ライン。全機能を並行で進めず、最小構成を最短で動かしてから Day 4 以降で肉付けします。Day 3 を越えて実装を積み上げると、Day 5 の社内共有準備に間に合いません。

💡 続けるコツ：毎日同じ時間帯（昼休み・帰宅直後・週末の朝など）に固定して習慣化／詰まったら粒度を一段下げて AI に再依頼（範囲を狭めるほど精度が上がります）。

AIとの協働開発 ― 全体フロー

卒業制作では3種類の AI を場面ごとに使い分けます。 この "使い分け" こそ、本講座で身につける最も実践的な業務スキルです。

企画の壁打ち、要件定義、技術選定の相談相手。業務課題の掘り下げと機能案の洗い出しに使う。 "会議議事録作成を効率化する Web アプリについて、5日間で実装可能な機能を5つ提案して。必要な技術スタックも添えて" ロゴ、アイコン、マニュアル挿絵、プレゼン用イラストを生成。業務資料の見栄えを短時間で整える。 "MeetingMemo という議事録自動生成アプリのロゴを、青系・シンプル・フラットデザインで3案生成して" 設計・実装・デバッグを段階的に依頼。1機能ずつ、既存コードを文脈として渡しながら進める。 "入力フォームから議事録テンプレート（Markdown 文字列）を生成する generateMinutes 関数を src/App.jsx に追加して"

✅ 3種類をまたぐ "成果物バトン" のイメージ

チャット AI で固めた企画書 → 画像生成 AI でロゴ素材を生成 → コーディング AI に企画書とロゴを渡して実装依頼。"前の AI の成果物が、次の AI の入力になる" ように順番に進めるのがコツです。大原則は「AI に一度に全部は頼まない」こと。1回のプロンプトでは1機能に絞り、動作確認してから次へ進みます。

チャットAIの活用テクニック

チャット AI は企画〜要件定義フェーズの "壁打ち相手" として最も威力を発揮します。本講座で身につけたプロンプトエンジニアリングのテクニックは、業務のあらゆる場面でそのまま再利用できます。

プロンプトエンジニアリング テクニック一覧（Ch01〜08の総まとめ）

優先度：★ = 卒業制作で必ず使う ／ ☆ = 余裕があれば取り入れる

優先 テクニック 章 概要 ☆ プロンプトの3要素（何を・見た目・場所） Ch01 具体的な指示の基本 ★ イテレーティブ・リファインメント Ch02 対話で段階的に磨く ☆ 制約条件の指定 Ch03 数値・否定・品質制約を含める ☆ マルチモーダルプロンプト Ch03 画像生成での要素分解 ★ 段階的指示（1回1機能） Ch04 機能を分割して依頼する ★ デバッグプロンプト Ch04 エラー報告の3点セット ☆ 役割設定（ロールプロンプト） Ch05 「あなたは〇〇として」 ★ 黄金パターン（5要素統合） Ch05 役割＋文脈＋要件＋出力形式＋制約 ★ Few-shot prompting Ch06 例示で出力を誘導する ☆ 技術選択の相談プロンプト Ch06 条件付き比較を依頼する ★ Chain-of-Thought Ch07 AI に段階的に考えさせる ☆ プロンプトテンプレート Ch07 再利用可能なひな形を作る ☆ セキュリティチェックプロンプト Ch07 コードの安全性を確認する ☆ AIレビュープロンプト Ch08 公開前の品質チェック

プロンプト設計ワークフロー

1. 企画　　→ Chain-of-Thought で段階的に考えさせる
2. 設計　　→ 黄金パターンで全体像を伝える
3. 実装　　→ 段階的指示 ＋ Few-shot で1機能ずつ
4. デバッグ → デバッグプロンプト（3点セット）で修正
5. 公開前　→ AI レビュープロンプトで品質チェック

効果的な聞き方の3原則

・自分の立場と目的を1文で添える（例：「私は営業企画部で、営業チーム向けの議事録アプリを作っています」←立場＋目的） ・成果物の全体像と想定ユーザーを先に共有し、今日の論点に絞り込む ・1回の質問で1トピック。範囲を広げると出力精度が下がる

プロンプト改善の3ステップ — 同じ依頼を磨き直すと、どこまで精度が上がるか

1ターン目：汎用すぎ 「議事録アプリを作って」 → 用途が曖昧で使えない

2ターン目：役割＋要件 「役割指定で議事録関数を作って」 → 出力形式にバラつき

3ターン目：Few-shot 「出力例 Markdown を提示して」 → 業務でそのまま使える

業務でそのまま使える プロンプト3選 — コピペして【 】内だけ書き換える

あなたは議事録作成の専門家です。【会議名／日時／参加者／議題】を入力すると Markdown 形式で議事録テンプレートを返す関数の仕様を、入出力例付きで提案してください。 あなたは社内 FAQ 整備の担当です。次の質問リストを「カテゴリ／よくある質問／回答／関連リンク」の4列にまとめ、重複を統合してください。【質問リスト】 あなたは管理職向けの週報レビュアーです。次の週報を「成果／課題／来週の打ち手」の3節構造に整理し、冗長な箇所を半分の文字数に圧縮してください。【週報本文】

💡 自分の業務に置き換えて使うコツ

3つとも構造は同じ — 役割（「あなたは〇〇の専門家です」）＋ 入力（【】で明示）＋ 出力形式（節構成・列構成）。この型を覚えれば、明日からの会議メモ・FAQ ・週報をそのまま AI に下処理させられます。

AI に頼んでよい業務／自分で判断すべき業務 — 業務 AI 活用の境界線

✅ AI に頼んで OK な業務

・形式が決まった文書の下書き／整形（議事録・週報・FAQ） ・要約・分類・タグ付けなど機械的な情報処理 ・アイデアの壁打ち（複数案を出させて自分で選ぶ） ・コードの下書き・リファクタ・テストケース提案

⚠️ 自分で最終判断すべき業務

・社外への正式回答／契約・法務関連 の文章 ・個人情報・顧客機密 を含む処理（伏せ字必須） ・金額・期日・人事評価など数値の確定判断 ・セキュリティ／本番環境 に直結するコード変更

📌 合言葉：「AI は下書き、判断は自分」

コーディングAI＋画像生成AIの活用テクニック

実装フェーズでは、コーディング AI に "1機能ずつ" 依頼するのが鉄則。黄金パターン（役割＋要件＋出力形式＋文脈）を毎回揃えるだけで、出力の質が大きく変わります。

良い指示の例（議事録テンプレートアプリ編）

［役割］ あなたはフロントエンドエンジニアです。 ［要件］ 議事録テンプレートアプリに "議事録自動生成" 機能を追加。 ・会議名／日時／参加者／議題の入力欄を受け取り ・Markdown テンプレート文字列を返す関数を作る ・空欄があればエラーを返す ［出力形式］ src/App.jsx の generateMinutes 関数として実装、日本語コメント付き。 ［文脈］ （現在のコードを貼り付ける）

指示の4原則 （Ch04〜06 の総まとめ）

・1機能ずつ指示する（段階的指示）／期待動作を箇条書きで具体化（黄金パターン） ・既存コードは文脈として渡す／欲しい出力形式は例で見せる（Few-shot）

※ 新規作成の1件目だけは "文脈なし" で OK。2回目以降は必ず前回の AI 出力コードを貼り付けてから依頼します

画像生成 AI の業務シーン

・ロゴ・アイコン：「MeetingMemo ロゴを青系3案」 ・マニュアル挿絵：「入力画面で作業する業務シーン」 ・共有スライド：「議事録作成の前後比較イラスト」

NG → OK 書き換えパターン

議事録アプリを全部作って 入力フォームに会議名・日時・参加者・議題の4つのテキスト入力を追加して 範囲を1機能に絞ると検証が楽

エラーが出た Cannot read property 'map' of undefined。App.jsx 起動直後に発生（該当コード添付） 3点セットで原因特定が速い

💡 このエラーの典型原因： state の初期値が undefined のまま map を呼んでいる。useState([]) と初期配列を渡せば直ります。

いい感じにして ボタンを角丸8px・プライマリ色 #4a7dff・ホバー時10%暗く、3案提案 色・形・数値を具体化すると期待が揃う

依頼前のセルフチェック5項目 — AI に投げる前にこの5つを満たしているか確認

3機能まとめて頼まない。動詞1つに絞る 入力（引数）と出力（返り値）の型を明示する src/App.jsx のように相対パスで指定する 2回目以降は前回 AI 出力をそのまま貼る Console / 画面 / テスト — どこで動作を見るか

🛠 詰まったときの粒度ダウン早見

AI の出力が意図と違うときは、依頼の粒度を一段下げるのが最短手。例：「議事録機能を作って」で詰まったら、「会議名・日時・参加者・議題の4つの入力欄を作って」→「入力欄の値を1つの Markdown 文字列に連結する関数だけ書いて」と分解。1機能を1〜3行で書ける単位まで割れば、AI の精度は跳ね上がります。

🎨 画像生成 AI の3要素

被写体／スタイル／色調 を必ず指定。例：「議事録アプリのロゴ（被写体）／フラットでシンプル（スタイル）／青系・3案（色調＋数）」。曖昧な「いい感じ」を排除することが、画像でもコードでも共通の鉄則です。

AI 出力を本採用する前の3チェック — そのままコピペしない

① 動かして確認

必ず 自分の手元で実行 する。コードなら起動・操作、文章なら声に出して読む。AI は "それっぽく見える" 出力を出すので、目視だけでは気づけないバグや言い回しがある。

② 業務語彙に直す

AI の出力には 一般的な言い回し が混じる。社内固有の用語・部署名・略称・敬称ルールに置き換えてから共有する。読み手が違和感を覚えれば信頼を失う。

③ 機密情報を確認

プロンプトに入れた内容 と AI が出した内容 の両方をチェック。顧客名・金額・未公開情報が伏せ字のまま残っていないか、第三者に見られても OK か最終確認する。

📌 所要時間は30秒。惜しむと修正コスト10倍。

成果を社内に共有する

卒業制作の仕上げは、作ったアプリを社内で共有することです。 週報や案件報告と同じく、"何を・誰のために・どんな成果を出したか" を5分で伝える型です。 一度身につければ、報告フォーマットとして今後の業務でも再利用できます。

5分間の成果報告フォーマット — 時間配分

自分の所属／解きたかった業務課題 アプリ名／想定ユーザー／解く業務課題 実際に動かす。メイン機能を通しで操作 AI との協働／壁をどう超えたか 業務にどう組み込むか

報告スクリプトの書き出し例（そのまま使える）

［背景］ 営業企画部の〇〇です。週次定例の議事録を手書きしており、清書と共有に毎回1時間かかっていました。

［作ったもの］ 会議情報を入力すると議事録を自動生成する MeetingMemo を作成。営業チームのリーダー向け。

［デモ］ 会議情報を入力 → テンプレートが自動生成 → Markdown で Slack にコピー、の流れを実演。

［工夫・苦労］ テンプレート生成は Chain-of-Thought でプロンプトを組み、Few-shot で出力形式を固定。

［展開］ 来月から営業チーム全員に展開し、他部署の定例会議にも広げる予定。

実施のコツ

・本番前に最低3回、時間を計って通し練習をする ・デモが落ちたときの "プラン B" を用意する ・スライドは文字を削り、スクショと図を主役にする ・画面ではなく聞き手の方を見て、ゆっくり話す ・5分を超えそうなら話題を増やさず削る

✅ 最後に「次の四半期で〇〇部署へ広げたい」と1文添えると、聞き手が次の一歩につながるフィードバックをくれます。

習得スキルの振り返り

30日間で習得したスキルを4領域に整理しました。 どれも手を動かして培った、業務にそのまま持ち込める武器です。

・HTML / CSS / JavaScript / React で Web アプリを構成できる ・API・データベースと連携した動的アプリを開発できる ・Git・GitHub Pages でコード管理と公開ができる

・黄金パターン（役割＋文脈＋要件＋出力形式＋制約）を使いこなせる ・Few-shot ／ Chain-of-Thought ／反復リファインメントを場面で使い分けられる ・デバッグ・セキュリティ・AI レビューのプロンプトで品質を担保できる

・チャット AI（ChatGPT / Claude / Gemini）で企画・要件定義の壁打ち ・画像生成 AI で業務資料のビジュアル素材を作成 ・コーディング AI（Claude Code / Codex / Gemini CLI）でアプリ開発

・業務課題を企画書に落とす要件定義力 ・段階的に開発を進めるプロジェクト管理の感覚 ・成果を5分の報告にまとめて社内に共有する力

🏆 これらは "修了証書" ではなく、手を動かして得た力

議事録テンプレートアプリを通じて身についた実力です。同じ型で "2作目・3作目" を作れば、社内の AI 人材としてのポジションが定着します。

成果を "業務事例集" にまとめる

作った作品は、自分専用の「業務改善事例集」として残します。 来期に別の課題へ着手するときのお手本になり、社内で AI 活用を広げる提案材料にもなります。

GitHub リポジトリに保存。README に「解いた業務課題」と「使い方」を明記 GitHub Pages などで動くデモを置く。社内 Slack や共有ドキュメントにリンクを貼れる形に 手作業時代の工数・所要時間と、導入後の時間短縮・ミス削減効果を数値で記録 企画・実装・デバッグで AI に投げた代表プロンプトを3本抜粋。次作でそのまま転用 工夫した点、ぶつかった壁、再現するなら変えたい設計。次の一歩のタネになる

📁 事例集フォルダの命名例

2026-04_MeetingMemo/ ├─ README.md（解いた業務課題／Before-After） ├─ app/（ソースコード） ├─ prompts/（使ったプロンプト3本） │　├─ 01_plan.md　　（企画ブレスト） │　├─ 02_implement.md（実装依頼） │　└─ 03_debug.md　　（デバッグ） └─ demo.mp4（30秒の操作動画）

✅ 事例集が2〜3件たまると "社内 AI 人材" として認知される

1作目で "型" を身につけ、2作目で応用を試し、3作目で他部署へ展開する — 同じ型を繰り返すだけで、社内の業務改善リーダーとして動ける土台が整います。事例集は、あなたの成長の履歴書になります。

AIのトレンドとあなたの立ち位置

AI の進化は、あなたに新たな技術習得を強いるのではなく、 "業務課題を AI と解ける人" の価値を押し上げ続けます。

指示を出すだけで AI がリサーチ → 計画 → 実行を連続でこなす。要件定義と検収の精度が、そのまま成果に直結する。 「来週の全社会議の議題を集め、部門別にまとめて要点を5行で」— 情報収集から整理までを一度に依頼できる。 会議の音声文字起こし、Excel スクショからの自動集計など、手作業の "読む／書く" が丸ごと置き換わる。 会議録音を渡すだけで、文字起こし → 議事録 → 決定事項の要約まで自動で生成される。 独自データや社内文書に AI を接続し、自部署の業務に特化したアシスタントを自分で作れるようになる。 自社の商品カタログと過去の営業メモを AI に接続し、顧客別の提案文案を自動生成するアプリを社内運用。

🏆 修了したあなたの3つの強み

① AI で作れる AI に指示を出して Web アプリを自分で完成させられる

② 基礎で見抜ける 基礎を理解しているので AI の出力を評価・修正できる

③ 学び続けられる 学び方の型があるので新技術にも自分でついていける

AI が強くなるほど、「AI に的確に指示し、成果物を評価できる人」の価値は上がります。身につけた型は陳腐化しません。

次のステップ — 社内AI人材としての広げ方

卒業後の成長軸は3方向。今の会社で業務課題を解き続けながら、 🎓 修了時点の自分を起点に、下の3ルートから得意領域を少しずつ深めていきましょう。

TypeScript／Next.js／デザインシステム 『プロを目指す人の TypeScript 入門』『りあクト！』 業務アプリの画面品質と保守性を上げ、長く使われるツールを作れるようになる Node.js／Python／SQL／REST API 『Web を支える技術』『達人に学ぶ SQL 徹底指南書』 業務データを安全に扱うアプリを作り、ダッシュボードや集計ツールに育てられる AI エージェント／社内 LLM／プロンプト運用 『生成 AI 実践ガイド』各社 AI プラットフォーム公式ドキュメント 自部署で解いた型を他部署・他プロセスへ展開し、社内 AI 推進の旗振り役になる

📚 推奨書籍の難易度について 『りあクト！』『達人に学ぶ SQL 徹底指南書』は中級〜上級向けです。修了直後は 公式ドキュメントや入門書（『スッキリわかる SQL 入門』など）から始め、上記は半年後の目標 として位置付けてください。

⏰ 続ける仕組み — "毎週金曜の午後1時間" を業務改善タイムにする

学習時間は業務スケジュールの中に予定として固定しましょう。1年後には3〜4本の業務改善アプリが溜まり、社内での立ち位置が自然と変わります。

よくあるトラブルQ&A

卒業制作でつまずきがちな4つの悩みと、その超え方をまとめました。

「テーマの選び方」の業務課題ベース 10 選から近いものを選び、"自分の部署バージョン" に言い換えるのが最短ルートです。 「私は〇〇部門の〇〇を担当しています。毎日／毎週くり返している作業を5つ挙げて、Web アプリで解けそうなものを教えて」 "入力 → 生成 → 表示" の1本の線が通っていれば、それで立派な成果物です。残りは仕上げとドキュメントに回し、追加機能は "2作目" に送ります。 Day 3 終了時点に MVP が動いていないなら、機能を絞る。Day 4 以降で新機能を追加すると社内共有準備が間に合いません。 段階的指示とデバッグプロンプト（3点セット：エラー文／発生時の操作／該当コード）に戻ります。範囲を広げた一括生成で詰まった場合は、機能を分解するのが最短ルート。 "テンプレート生成機能を実装して" → "generateMinutes 関数の返り値を Markdown 文字列に揃えて" 「解いた業務課題／動くデモ／自分の業務への展開予定」の3つがあれば十分伝わります。完璧なプレゼンは不要です。 「すごい技術だね」ではなく「うちの業務にも使えそう」を引き出せれば、その時点で大成功です

修了メッセージ

🎉　🎓　🎉

30日間、おつかれさまでした。

不安だらけのスタートから、業務課題を解く Web アプリを自分の手で完成させるところまで。 これは、紛れもなくあなた自身の力で成し遂げたことです。

30 日前のあなた

「自分にプログラミングなんてできるのかな」と不安を抱えていた

→

今日のあなた

業務課題を企画書に落とし、AI と協働して Web アプリを作り、社内に成果を共有できる

技術は日々進化しますが、「業務課題を見つけ、AI と一緒に手を動かし、形にして共有する」という 型 さえあれば、どんな変化にも対応していけます。明日から、自分の職場の "次の業務課題" を探してみてください。分からないことは AI に相談し、行き詰まったら社内の仲間にフィードバックを求める。ひとつずつ作って共有するたびに、あなたは "社内で AI を動かせる人" になっていきます。

⚠️ 最後にもう一度（第7章の再確認） AI に相談するときは、社内の機密情報（顧客名・金額の詳細・未公開プロジェクト名）を必ず伏せ字にしてから入力してください。

皆さんのこれからの活躍を、心から応援しています。

株式会社グランドツー