From 02c1f9329ce51b057d716dd6b679bcea944d53a8 Mon Sep 17 00:00:00 2001 From: mako-surprise Date: Thu, 5 Mar 2026 17:11:54 +0900 Subject: [PATCH] =?UTF-8?q?feat:=20=E5=9B=B3=E8=A7=A3=E3=83=84=E3=83=BC?= =?UTF-8?q?=E3=83=AB=E3=81=AE=E5=88=9D=E6=9C=9F=E3=82=B3=E3=83=B3=E3=83=86?= =?UTF-8?q?=E3=83=B3=E3=83=84=E3=82=92=E8=BF=BD=E5=8A=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Made-with: Cursor --- .../creating-visual-explainers/SKILL.md | 241 ++++ .../references/base.html | 83 ++ .../references/library-template.html | 66 + .../references/model-answer.html | 968 ++++++++++++++ .../references/node-install-guide.md | 68 + .../scripts/deploy-diagram.sh | 56 + .gitignore | 6 + README.md | 230 ++++ output/.gitkeep | 0 output/cursor.html | 1010 +++++++++++++++ output/git.html | 1050 +++++++++++++++ output/index.html | 77 ++ output/llm.html | 1142 +++++++++++++++++ 13 files changed, 4997 insertions(+) create mode 100644 .claude/skills/creating-visual-explainers/SKILL.md create mode 100644 .claude/skills/creating-visual-explainers/references/base.html create mode 100644 .claude/skills/creating-visual-explainers/references/library-template.html create mode 100644 .claude/skills/creating-visual-explainers/references/model-answer.html create mode 100644 .claude/skills/creating-visual-explainers/references/node-install-guide.md create mode 100644 .claude/skills/creating-visual-explainers/scripts/deploy-diagram.sh create mode 100644 .gitignore create mode 100644 README.md create mode 100644 output/.gitkeep create mode 100644 output/cursor.html create mode 100644 output/git.html create mode 100644 output/index.html create mode 100644 output/llm.html diff --git a/.claude/skills/creating-visual-explainers/SKILL.md b/.claude/skills/creating-visual-explainers/SKILL.md new file mode 100644 index 0000000..c556883 --- /dev/null +++ b/.claude/skills/creating-visual-explainers/SKILL.md @@ -0,0 +1,241 @@ +--- +name: creating-visual-explainers +description: Generates an illustrated HTML page about any topic and deploys it to surge.sh. Triggered by requests like "図解を作って", "図解を生成して", "このトピックを図解して", or "図解してデプロイして". +--- + +# Creating Visual Explainers + +任意のトピックについて、前提知識がなくても理解できる図解HTMLを生成し、surge.shに公開する。品質基準は「入社したての新卒社会人が読んでも腹落ちする明快さ」だが、この基準は出力には表示しない。 + +## 依存 + +- `references/base.html` — 図解テンプレート（Tailwind CSS CDN・Lucide Icons CDN・ADS配色を含む「額縁」） +- `references/model-answer.html` — 模範回答（品質基準・デザインパターンの実例）。base.htmlと同一の額縁を含む完全なHTMLファイル + +## ワークフロー + +### Step 0: 前提確認 + +`references/base.html` が存在するか確認する。 + +存在しない場合、以下を伝えて終了: + +> テンプレートファイルが見つかりません。スキルのフォルダ構成が壊れている可能性があります。運営に連絡してください。 + +### Step 1: 模範回答の読み込み + +`references/model-answer.html` を読み、以下を把握する: + +- 完成品の品質水準 +- デザインパターン（色使い・余白・カード・フロー図などの視覚表現） +- Tailwind CSSクラスの使い方 +- Lucide Iconsの使い方 +- コンテンツの構成・情報量・説明の深さ + +模範回答がデザインガイドラインの代わりになる。パーツ一覧やルールではなく、実物から読み取る。 + +### Step 2: テンプレートの読み込み + +`references/base.html` を読み、額縁の構造を把握する: + +- `` 〜 `` のプレースホルダー位置 +- ``, `` のプレースホルダー +- ADS配色のTailwind設定 +- 読み込み済みのCDN（Tailwind CSS・Lucide Icons） + +### Step 3: ウェブで情報収集 + +トピックについてウェブ検索を行い、正確かつ最新の情報を収集する。 + +検索は **2〜3回** に絞る。以下の観点でクエリを組み立てる: + +1. **正確な定義**: トピックの公式な定義、公式ドキュメントの説明 +2. **最新動向**: 直近の変更点、アップデート、現在のベストプラクティス +3. **具体例**: 実際の使われ方、初心者に伝わるたとえに使える事例 + +検索結果から以下を整理し、Step 4 の参考情報とする: + +- トピックの正確な定義（検索結果を優先。AIの学習データだけに頼らない） +- 最近変わった点があれば、それを明記する +- たとえ話に使えそうな事例や数字 +- **出典URL**: 図解に採用した情報のソースURLを控えておく（Step 4 でインライン出典に使う） + +### Step 4: コンテンツ生成 + +Step 3 で収集した情報をもとに、図解HTMLを生成する。検索結果で得た定義・事実・具体例を優先的に採用する。 + +模範回答のデザインを参考にしつつ、Tailwindの語彙で自由にレイアウトを組む。模範回答のパターンに合うものはそのまま使い、合わないものはTailwindクラスでその場で作る。テンプレートの定義済みパーツに縛られない。 + +### Step 5: ファイル作成 + +1. `output/` ディレクトリがなければ作成する +2. トピックに関連する短い英単語のスラッグを決める（例: `api-basics`, `git-rebase`） +3. `references/base.html` を `output/{スラッグ}.html` にコピーする +4. コピーしたファイル内のプレースホルダーをすべて置換する: + - `` → 図解のタイトル + - `` → 内容を要約した1文 + - `` 〜 `` → Step 4で生成したコンテンツ +5. ファイル保存後、ブラウザで自動的に開く: + - macOS: `open output/{スラッグ}.html` + - Windows: `start output/{スラッグ}.html` + +### Step 5.5: 図解ライブラリの更新 + +`output/` 内の全HTMLファイル（`index.html` 以外）をスキャンし、一覧ページ `output/index.html` を生成・更新する。 + +1. `output/` 内の `.html` ファイル一覧を取得する（`index.html` は除外） +2. 各ファイルの `` タグからタイトルを、`<meta property="og:description">` から説明文を読み取る +3. `references/library-template.html` を読み込む +4. テンプレート内の `<!-- LIBRARY_ITEMS -->` を、以下の形式のカードリストで置換する: + +```html +<a href="{ファイル名}" class="block bg-ads-surface border border-ads-border rounded-xl p-5 hover:border-ads-accent/40 transition-colors"> + <h2 class="font-bold text-slate-900 mb-1">{タイトル}</h2> + <p class="text-sm text-ads-muted">{説明文}</p> +</a> +``` + +5. 結果を `output/index.html` として保存する + +### Step 6: 公開 + +ファイル保存後、公開する前にまず Node.js の有無を確認する。 + +```bash +node --version +``` + +バージョン番号が表示された → そのまま「公開の実行」に進む。 + +`command not found` と表示された → `references/node-install-guide.md` の手順に従ってNode.jsのインストールを案内する。 + +#### 公開の実行 + +以下のスクリプトを**実行する**（中身を読む必要はない）。 + +**重要: 第1引数には図解本体のファイル（`output/{スラッグ}.html`）を指定する。`output/index.html`（ライブラリ一覧）ではない。** + +**macOS / Git Bash（Windows）の場合:** + +```bash +bash .claude/skills/creating-visual-explainers/scripts/deploy-diagram.sh output/{スラッグ}.html [スラッグ] +``` + +**Windows（PowerShell）で bash が使えない場合:** + +```powershell +npx --yes surge output/{スラッグ}.html --domain diagram-[スラッグ].surge.sh +``` + +スラッグにはトピックに関連する短い英単語を指定する（例: `git-rebase`, `api-basics`）。 + +#### 初回の場合（Surge未登録） + +ターミナルにメールアドレスとパスワードの入力を求められる。以下を伝える: + +> 初回のみアカウント登録が必要です。 +> メールアドレスを入力して Enter → パスワードを決めて入力して Enter。 +> 確認メールが届いたらリンクをクリックすれば登録完了です。 +> 次回以降はこの手順は不要です。 + +#### エラーが出た場合 + +エラーメッセージをそのまま見せず、**何が起きていて何をすれば解決するか**を、専門用語を避けて平易に説明する。 + +よくあるエラーと対応: + +- **`npx: command not found`** — Node.js がまだ入っていない。`references/node-install-guide.md` の手順を案内する +- **`surge: not found` / surge関連エラー** — `npm install -g surge` を実行してから再度試す +- **認証エラー / `Login required`** — `npx surge login` を実行してメールアドレスとパスワードを入力する +- **その他** — エラーの内容を読み、「何が問題で」「次に何をすればいいか」を平易に説明する + +### 図解の削除 + +ユーザーが「この図解を削除して」と依頼した場合: + +1. `deploy-history.log` を読み、直近のデプロイURLを特定する + - ログが存在しない場合 → ユーザーに削除したいURLを聞く +2. `npx surge teardown [ドメイン]` を実行する +3. 削除完了をユーザーに伝える + +### Step 7: 完了報告 + +#### 公開に成功した場合 + +``` +完成・公開完了: 【図解のタイトル】 + +（図解の内容を1〜2文で要約） + +公開URL: +https://diagram-スラッグ.surge.sh + +図解の主なポイント: +- （主要トピックを3〜5個） + +この図解を削除したいとき: +チャット欄で「この図解を削除して」と伝えてください。 +``` + +#### 公開できなかった場合 + +``` +完成: 【図解のタイトル】 + +（図解の内容を1〜2文で要約） + +ファイルの保存先: +output/{スラッグ}.html（ブラウザにドラッグ＆ドロップすると表示できます） +図解ライブラリ: output/index.html + +図解の主なポイント: +- （主要トピックを3〜5個） + +URLで共有したいとき: +チャット欄で「この図解を公開して」と伝えてください。 +``` + +## 守ること（禁止事項） + +- **React・shadcn/ui を使わない** — 静的な図解にJSフレームワークは不要。AIの出力を制限し、モデルによる品質差も限定的にしてしまう +- **絵文字を使わない** — OS依存で表示が変わる。アイコンはLucide Iconsを使う +- **インタラクティブ要素を入れない** — トグル、フェードイン、アニメーション、フォーム、クリックで開閉する要素は一切禁止 +- **`<style>` タグを追加しない** — スタイリングはTailwind CSSクラスで行う。インラインの `style` 属性も避ける +- **`<script>` を追加しない** — テンプレートに含まれるもの以外のJavaScriptは禁止 +- **外部リソースを追加しない** — テンプレートに含まれるCDN以外の外部読み込み（画像URL・フォント・追加CDN）は禁止 +- **テンプレートの額縁構造を変更しない** — `<head>`・CDN読み込み・meta タグはそのまま維持する +- **PDF印刷で消える表現を使わない** — `bg-clip-text text-transparent` によるグラデーション文字はPDF出力時に透明のまま消える。テンプレートの print CSS でフォールバックを入れているが、グラデーション文字を使った場合はPDF出力で色が単色（`#2563EB`）に変わる点を意識すること + +## コンテンツ生成の指針 + +- **概論 → 各論** — いきなり詳細に入らない。全体像を見せてから個別の話に入る +- **専門用語は初出で必ず解説** — 「API（Application Programming Interface＝ソフトウェア同士がやり取りするための窓口）」のように、括弧書きで平易に説明する +- **たとえ話で身近な体験に結びつける** — レストランの注文、郵便配達、信号機など、技術を知らない人でもイメージできる例を使う +- **簡潔にまとめすぎない** — 理解に必要な情報量は削らない。腹落ちするまで丁寧に説明する +- **図を早く見せる** — 見出しから最初のビジュアルまでに、テキストは最大2段落（各2〜3行）。それ以上の説明が必要な場合は、図を先に見せてから図の後にテキストで補足する（図→説明の順）。「説明してから図を見せる」より「図を見せてから説明する」方が、同じ文量でも「読まされている感」がなくなる。テキストで述べたたとえ話（ゲーム、レストラン等）も、テキストだけで済まさずミニビジュアル化を検討する +- **「見たことがあるもの」は説明するのではなく見せる** — 図解の中で読者がすでに体験しているもの（アプリの画面、ツールのUI、Webサイト）に言及するとき、テキストで「〜という画面が表示されます」と書く代わりに、その画面自体をTailwind CSSで再現して配置する。「天気アプリの画面」なら天気アプリのモックアップを、「チャット画面」ならチャットUIを、「ターミナル」ならターミナルウィンドウを見せる。読者の「見たことある！」という記憶が発火する瞬間が、テキスト説明より圧倒的に理解を深める +- **ビジュアルには2つの役割がある** — 図解に使うビジュアルは「構造を示す図」と「体験を再現する図」の2種類。どちらか一方ではなく、両方を組み合わせて使う: + - **構造パターン（仕組みを頭で理解する図）** — 知識の種類に応じて選ぶ: + - **「Xとは何か」(定義)** → アナロジー図: 身近なたとえの登場人物を配置し、矢印で関係を示す。主役を中央に大きく + - **「Xはどう動くか」(プロセス)** → ステップフロー: 番号つき横並び（モバイルは縦）。各ステップにアイコン＋一言。色はステップごとに変える + - **「XとYの違い」(比較)** → 左右対比: 2カラムで並べ、同じ観点を同じ行に揃える。✗/✓ や赤/緑で差を一目で伝える + - **「Xの具体例」(事例)** → カードグリッド: 2列のカードにアイコン＋タイトル＋説明。カード内で「表の顔」と「裏の仕組み」を分けると深みが出る + - **「Xのすごさ」(数値)** → 数字カード: 3カラムに大きな数字。text-3xl font-black で存在感を出し、色を各数字で変える + - **「Xの構造・中身」(階層)** → 入れ子ブロック: 外側の大きなブロック内に構成要素を配置。ボーダーや背景色の濃淡で階層を表現 + - **「Xの誤解」(訂正)** → 誤解→正解カード: 赤ヘッダーに誤解、本文に緑で正解。✗と✓の対比 + - **「Xの変遷」(時系列)** → タイムライン: 左にボーダーライン、各時点に年号・ラベル・要約。色のグラデーションで時代の変化を表現 + - **体験再現パターン（読者の「見たことある」記憶と結びつける図）** — 読者が実際に触れたことのある画面をTailwind CSSで再現する。「あなたが見ているもの」「〜の画面では」「実際に使うとき」のような文脈が出てきたら、テキスト説明ではなくこちらを使う: + - **チャットUI** — 吹き出し形式の対話画面。暗い背景＋ユーザー吹き出し（右寄せ）＋AI吹き出し（左寄せ）＋入力欄モック + - **エディタUI** — タイトルバー（赤黄緑ボタン）＋サイドバー（ファイルツリー）＋コードペイン。AIチャットパネルを加えた3ペインも可 + - **ターミナルUI** — タイトルバー（赤黄緑ボタン）＋プロンプト（$）＋コマンド＋出力。コードブロックとの違いはウィンドウ枠がある点 + - **ブラウザUI** — タイトルバー（赤黄緑ボタン）＋アドレスバー＋ページ内容 + - **アプリ画面** — 上記に当てはまらないアプリ（天気予報、地図、決済画面など）。角丸カード内にアイコン＋数値＋ラベルでミニ画面を再現 + - 共通ルール: 中身はリアルすぎず要点が伝わるミニマルな内容にする。特定ブランドのロゴや名称は使わず汎用的な表現にする。Tailwind CSSクラスのみで構成する +- **冒頭にヒーロー＋一枚絵サマリー** — タイトルで「何の図解か」を伝えたあと、そのままトピックの核心を1枚の図で見せる。ヒーローの説明文を図への導入（「ひとことで言えば──」のような引き）にし、図の直後に各論への橋渡し（「ここからひとつずつ解説していきます」）を置く。ヒーロー → 一言の答え → 図 → 各論が一本の流れになること。一枚絵サマリーの構成: + - **一言の答え**: トピックの核心を1文で太字表示（カード冒頭）。読者が「なるほど」と思える定義を先に読ませ、そのあとの図で視覚的に裏付ける + - **コア図解**: 一言の答えを図にしたもの。アイコン＋矢印＋ラベルで表現 + - **身近な接点**: 読者がすでに体験している具体例を、アイコン＋一言のピルで2〜4個並べる +- **読者のレベルに言及しない** — 「初心者向け」「入門」「未経験者でもわかる」のように読者を特定のレベルにラベリングする表現をタイトル・見出し・本文に入れない。「わかりやすく説明する」のは図解の品質であって、読者のレベルではない。たとえ話や専門用語の解説で自然に噛み砕けば、ラベルなしで誰にでも伝わる +- **ヒーローバッジはトピックカテゴリ** — タイトル上のバッジには、トピックのカテゴリを入れる（テクノロジー、ビジネス、開発ツール、デザイン、マーケティングなど）。「初心者向け」「入門」など読者のレベルを示すラベルは入れない +- **インライン出典** — 検索結果から採用した事実・定義・数字のすぐ近くに、出典リンクをさりげなく添える。本文の読みやすさを損なわないよう `text-xs text-ads-dim` で小さく薄く表示し、リンクテキストはURLそのままではなく「出典: ○○公式ドキュメント」のようにページ内容がわかる名前にする。段落末やカード下部など、視線の流れを邪魔しない位置に置く +- **日本語で** — 英語メインのトピックでも、図解は日本語で書く diff --git a/.claude/skills/creating-visual-explainers/references/base.html b/.claude/skills/creating-visual-explainers/references/base.html new file mode 100644 index 0000000..4988d15 --- /dev/null +++ b/.claude/skills/creating-visual-explainers/references/base.html @@ -0,0 +1,83 @@ +<!DOCTYPE html> +<html lang="ja"> +<head> + <meta charset="UTF-8"> + <meta name="viewport" content="width=device-width, initial-scale=1.0"> + <meta name="robots" content="noindex, nofollow, noarchive, nosnippet, noimageindex"> + <meta name="googlebot" content="noindex, nofollow"> + <meta property="og:title" content="<!-- TITLE -->"> + <meta property="og:description" content="<!-- DESCRIPTION -->"> + <meta property="og:type" content="article"> + <title><!-- TITLE --> + + + + + + + + + +
+ +
+
+ + + +
+ + + + + diff --git a/.claude/skills/creating-visual-explainers/references/library-template.html b/.claude/skills/creating-visual-explainers/references/library-template.html new file mode 100644 index 0000000..0259946 --- /dev/null +++ b/.claude/skills/creating-visual-explainers/references/library-template.html @@ -0,0 +1,66 @@ + + + + + + + + 図解ライブラリ + + + + + + + + +
+
+

図解ライブラリ

+

チャット欄で「○○を図解して」と依頼すると、ここに追加されます

+
+ +
+ +
+ +
+

こんなことを聞いてみよう

+
+
「API とは何か、図解して」
+
「Git の rebase と merge の違いを図解して」
+
「クラウドとは何か、図解して」
+
「KPI と KGI の違いを図解して」
+
「HTML と CSS の関係を図解して」
+
「UI と UX の違いを図解して」
+
+
+
+ + + diff --git a/.claude/skills/creating-visual-explainers/references/model-answer.html b/.claude/skills/creating-visual-explainers/references/model-answer.html new file mode 100644 index 0000000..ce24d75 --- /dev/null +++ b/.claude/skills/creating-visual-explainers/references/model-answer.html @@ -0,0 +1,968 @@ + + + + + + + + + + + + APIの仕組み + + + + + + + + + +
+ +
+
+ + + + + +
+
+ + テクノロジー +
+

+ APIの仕組み +

+

+ 「APIって何？」と聞かれて、うまく答えられない。
+ ひとことで言うと ── +

+
+ + + + + +
+
+

+ API = ソフトウェアの「注文窓口」 +

+

+ 中身を知らなくても、決まった形で頼めば結果が届く +

+
+ + +
+ +
+
+ +
+
あなたのアプリ
+
「天気を教えて」
+
+ + +
+
+ リクエスト + + +
+
+ + +
+
+ +
+
API
+
注文を届け、結果を返す
+
レストランのウェイター役
+
+ + +
+
+ 依頼 + + +
+
+ + +
+
+ +
+
サービス
+
処理して結果を返す
+
+
+ + +
+
+ + 結果（レスポンス）があなたのアプリに届く +
+
+ + +
+
+
あなたも毎日使っている
+
+
+ + +
+
+ + 天気予報 +
+
+ + Googleログイン +
+
+ + オンライン決済 +
+
+ + 地図・ナビ +
+
+ +
+ +

+ ここから先で、この仕組みをひとつずつ丁寧に解説していきます。 +

+ + + + + +
+
+
+ +
+

そもそもAPIって何？

+
+ +

+ API（エーピーアイ）は Application Programming Interface（アプリケーション・プログラミング・インターフェース）の略称です。正式名称を聞いても「何のこと？」と思いますよね。 +

+ +

+ まずは日常のたとえで考えてみましょう。レストランに行った場面を想像してください。 +

+ +

+ あなた（お客さん）は、厨房に直接入って料理を作ることはできません。厨房のルールも、調理器具の使い方も知りません。でも、ウェイターに「パスタをください」と注文すれば、厨房で作られた料理があなたのテーブルに届きます。厨房の中で何が起きているかを知る必要はありません。 +

+ + +
+

レストランで考えるAPIの役割

+ +
+ +
+
+ +
+
あなた
+
お客さん
+
「パスタください」
+
+ + +
+
+ 注文 + + +
+
+ + +
+
+ +
+
API
+
ウェイター
+
注文を伝え、料理を届ける
+
+ + +
+
+ 依頼 + + +
+
+ + +
+
+ +
+
サーバー
+
厨房
+
パスタを作って渡す
+
+
+ +
+
+ + 料理（レスポンス）があなたのテーブルに届く +
+
+
+ +

+ この比喩がAPIの本質をほぼ言い当てています。あなた（アプリ）は、厨房（サーバー）の中で何が起きているかを知る必要がありません。ウェイター（API）に決まった形式で注文を伝えれば、結果が返ってくる。これがAPIです。 +

+ + +
+
+
+ +
+
+

ここがポイント

+

+ APIは「仲介役」です。相手の内部構造を知らなくても、決まったルールで話しかければ結果が返ってくる。これがAPIの本質です。この「決まったルール」のことを、エンジニアは「インターフェース（Interface）」と呼びます。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

もう少し正確に言うと

+
+ +

+ レストランのたとえで、ざっくりとしたイメージはつかめましたか？ ここからもう少しだけ正確に説明します。 +

+ +

+ APIとは、ひとことで言えば「ソフトウェア同士が会話するための窓口」です。あなたが使っているアプリの裏側で、別のサービスのデータや機能を借りてくるための「取り決め」と考えてください。 +

+ +
+
技術的な定義
+

+ API = あるソフトウェアの機能を、 + 別のソフトウェアから使えるようにする仕組み +

+

出典: MDN Web Docs — Web API の紹介

+
+ +

+ これだけだとまだ抽象的に感じるかもしれません。では、APIがある世界とない世界を比べてみましょう。 +

+ + +
+ +
+
+ + BEFORE — APIがない世界 +
+
    +
  • + + 天気情報が欲しければ、自分で気象観測の仕組みを構築する +
    • +
  • + + 決済機能が欲しければ、クレジットカード処理を自前で開発する +
    • +
  • + + 地図を表示したければ、地図データを自分で作成・更新する +
    • +
  • + + ユーザー認証はパスワード管理からセキュリティ対策まで全部自前 +
    • +
+
+ + 膨大な開発コストと時間。バグのリスクも高い。 +
+
+ + +
+
+ + AFTER — APIがある世界 +
+
    +
  • + + 天気情報は天気予報APIに問い合わせるだけで取得できる +
    • +
  • + + 決済はStripe APIに任せれば数行のコードで完成 +
    • +
  • + + 地図はGoogle Maps APIで高品質な地図を即表示できる +
    • +
  • + + ログインはGoogleやAppleのAPIで安全に認証できる +
    • +
+
+ + 「自分が本当に作るべきもの」に集中できる。 +
+
+
+
+ + + + + +
+
+
+ +
+

APIの仕組み — リクエストとレスポンス

+
+ +

+ APIでのやり取りは、実はとてもシンプルです。基本は「聞く（リクエスト）」と「答える（レスポンス）」の2つだけ。 +

+ +

+ リクエスト（Request）とは、「こういう情報をください」「この処理をしてください」とAPIに送るメッセージのことです。レスポンス（Response）は、APIがその要求に対して返す結果です。この2つのやり取りを分解すると、4つのステップになります。 +

+ + +
+

APIリクエスト〜レスポンスの流れ

+ +
+
+
1
+ +
リクエスト送信
+
あなたのアプリが
「こういう情報ください」
とAPIに送る
+
+ +
+ + +
+ +
+
2
+ +
APIが受け取る
+
リクエストの内容を
チェック・認証する
（門番の役割）
+
+ +
+ + +
+ +
+
3
+ +
サーバーが処理
+
データベース検索や
計算など、実際の
処理を実行する
+
+ +
+ + +
+ +
+
4
+ +
レスポンス返却
+
処理結果をあなたの
アプリに返す
（料理が届く瞬間）
+
+
+
+ +

+ 言葉だけだとまだピンとこないかもしれません。では、実際のコードで見てみましょう。たとえば、天気予報APIから東京の天気を取得するコードは、たったこれだけです。 +

+ + +
+
+ + JavaScript — 天気予報APIの呼び出し例 +
+ 
// 1. APIにリクエストを送る（「東京の天気を教えて」と聞く）
+const response = await fetch("https://api.weather.example.com/current?city=tokyo");
+
+// 2. レスポンスをJSON形式（データの構造）に変換する
+const data = await response.json();
+
+// 3. 必要なデータを取り出して使う
+console.log(data.temperature); // → "22°C"
+console.log(data.condition);   // → "晴れ"
+console.log(data.humidity);    // → "65%"
+
+ + +
+

+ + コードの解説（1行ずつ読み解く） +

+
+
+ 1 + fetch() は「指定したURLに問い合わせる」命令。URLの末尾にある ?city=tokyo が「東京の情報が欲しい」というリクエストの中身です。レストランのたとえで言えば「パスタください」にあたる部分。 +
+
+ 2 + 返ってきたデータは機械向けの生データなので、.json() で人間が読みやすい形（JSON = JavaScript Object Notation）に変換します。JSONは「名前: 値」の組み合わせでデータを表現する書式で、Web業界で最も広く使われています。 +
+
+ 3 + 変換したデータから data.temperature のように、ドット（.）で区切って欲しい情報を名前で取り出します。辞書で単語を引くのに似ています。 +
+
+
+ +

+ ターミナル（コマンドを入力する黒い画面）からもAPIを試せます。curl（カール）というコマンドを使うと、たった1行でAPIにリクエストを送れます。 +

+ + +
+
+
+
+
+
+
+
+ + ターミナル — curlコマンドでAPIを叩く +
+
+ 
$ curl https://api.weather.example.com/current?city=tokyo
+
+# 返ってくるレスポンス（JSON形式）
+{
+  "city": "東京",
+  "temperature": "22°C",
+  "condition": "晴れ",
+  "humidity": "65%"
+}
+
+ +
+
+
+ +
+
+

ちょっと補足: URLの構造

+

+ https://api.weather.example.com/current?city=tokyo のURLは、大きく3つの部分に分かれます。api.weather.example.com がAPIの住所（ベースURL）、/current が「何を」（現在の天気）、?city=tokyo が「どこの」（東京）というパラメータです。レストランで例えると「〇〇レストランの（住所）、メインメニューから（何を）、パスタを（詳細）」に対応します。 +

+
+
+
+ +

+ では、このAPIのレスポンスが実際のアプリではどう表示されるのでしょうか？ あなたが見ている天気アプリの画面を覗いてみましょう。 +

+ + +
+
+
+
+
+
+
+
+ + weather-app.example.com +
+
+
+
+
現在地: 東京
+
+ + 22°C +
+
晴れ
+
+
65%
+
3m/s
+
+
+
+
+ +
+
+
+ +
+
+

APIの結果 → アプリの画面

+

+ 上の天気アプリは、裏側で temperature: "22°C" や condition: "晴れ" というAPIレスポンスを受け取り、見やすいデザインに変換して表示しています。あなたが普段見ているきれいな画面の裏側では、こうしたAPIのやり取りが行われているのです。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

身近なAPIの例 — 実はあなたも毎日使っている

+
+ +

+ 「API」と聞くとプログラマーの専門用語に聞こえるかもしれません。しかし、あなたがスマホで何気なくやっている日常の操作の裏側では、たくさんのAPIが動いています。「あなたが見ている画面」の裏側で、APIが何をしているのかを図解します。 +

+ +
+ +
+
+
+
東京
+
+ + 22°C +
+
晴れ
+
+
65%
+
3m/s
+
+
+
+
+

+ 天気予報アプリ +

+
裏側でAPIがやっていること
+

気象庁のサーバーに「東京の最新天気データをください」とリクエストを送り、気温・天候・湿度・風速などのデータをJSON形式で受け取っている

+
+
+ + +
+
+
アカウントにログイン
+
+
+ G +
+ Google でログイン +
+
+
+ または +
+
+
メールアドレスで登録
+
+
+

+ 「Googleでログイン」ボタン +

+
裏側でAPIがやっていること
+

GoogleのOAuth API（オーオース = 認可の仕組み）に「このユーザーの身元を確認してください」と問い合わせ、認証トークン（本人確認済みの証）を受け取っている

+
+
+ + +
+
+
+ +
+
お支払い完了
+
¥1,980
+
VISA **** 4242
+
+
+

+ オンライン決済 +

+
裏側でAPIがやっていること
+

Stripe等の決済APIが、クレジットカード会社のサーバーと暗号化通信を行い、与信確認（この人は支払える？）→ 決済処理 → 結果通知を実行している

+

出典: Stripe API 公式ドキュメント

+
+
+ + +
+
+
+
+
+
+
+ 現在地 +
+
+
+
+ + 東京駅 +
+
12分
+
+
+
+
+

+ 地図・ナビアプリ +

+
裏側でAPIがやっていること
+

Google Maps APIが地図画像の取得、現在の交通情報の取得、経路計算をそれぞれ別のAPIに問い合わせ、統合して表示している

+
+
+
+ +
+
+
+ +
+
+

気づきましたか？

+

+ 上の4つの例に共通しているのは、あなたがAPIの存在を意識していないということです。天気を確認するとき「今からAPIを呼ぶぞ」とは思いませんよね。優れたAPIは、ユーザーにその存在を感じさせません。まるで空気のように、裏側で静かに仕事をしているのです。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

APIを使うとどう嬉しいか

+
+ +

+ ここまで読んで「APIは便利そうだ」と感じてもらえたと思います。では、開発者の視点から見たとき、APIを使うことで具体的にどのくらいの効果があるのか。数字と一緒に見てみましょう。 +

+ +
+
+
50回+
+
あなたが1日に
APIを使っている回数
+
+
+
24,000+
+
世界で公開されている
APIの数
+

出典: ProgrammableWeb

+
+
+
0.2秒
+
多くのAPIの
平均応答時間
+
+
+ +
+
+
+ +
+
+

開発スピードが上がる

+

決済、認証、地図、翻訳...。これらをゼロから作ると何ヶ月もかかりますが、APIを使えば数日〜数時間で実装できます。車を作りたいとき、エンジンから設計する必要はないのです。

+
+
+ +
+
+ +
+
+

品質が担保される

+

Google Maps、Stripe、AWSなど、各分野の専門企業が何千人体制で開発・運用しているAPIの品質は、個人や小さなチームで再現できるレベルではありません。その品質を「借りる」ことができます。

+
+
+ +
+
+ +
+
+

保守の手間が減る

+

API提供元がバグ修正・機能改善・セキュリティ更新を継続的に行ってくれます。あなたはAPIを「使うだけ」。自分でゼロから作った機能は、自分でずっと面倒を見続ける必要があります。

+
+
+ +
+
+ +
+
+

レゴのように拡張できる

+

APIはレゴブロックのように組み合わせられます。たとえば「翻訳API + 音声合成API」を組み合わせれば、多言語音声読み上げ機能が作れます。1つのAPIだけでは実現できない価値が、組み合わせで生まれるのです。

+
+
+
+
+ + + + + +
+
+
+ +
+

よくある誤解

+
+ +

+ APIについて学び始めると、多くの人が同じところでつまずきます。ここでは、初学者が陥りがちな3つの誤解を取り上げて、正しい理解に修正します。 +

+ +
+
+
+
+ +
+

誤解: 「APIはプログラマーだけが使うもの」

+
+
+
+
+ +
+
+

実際は:

+

+ あなたも毎日APIを使っています。朝、天気アプリを開く。SNSにログインする。電子マネーで買い物する。これらの操作はすべて、裏側でAPIが動いています。プログラマーが「APIを使う」のは、この仕組みのコードを書いている側にいるだけの話。気づかないうちにAPIの恩恵を毎日受けているのです。 +

+
+
+
+
+ +
+
+
+ +
+

誤解: 「APIって難しい技術でしょ？」

+
+
+
+
+ +
+
+

実際は:

+

+ APIの概念自体は「注文して結果を受け取る」というシンプルな仕組みです。レストランで注文できるなら、APIの概念は理解できます。先ほどのコード例のように、実際のプログラムも数行で書けることがほとんどです。難しいのはAPIそのものではなく、「APIで何を作るか」を考える部分。道具はシンプル、使いこなすセンスが問われるということです。 +

+
+
+
+
+ +
+
+
+ +
+

誤解: 「APIを使うと個人情報が漏れそうで怖い」

+
+
+
+
+ +
+
+

実際は:

+

+ 適切に設計されたAPIは、必要最小限の情報だけをやり取りします。たとえば銀行のAPIが口座残高を返す際、パスワードや暗証番号は一切含まれません。APIはデータの「窓口」であり、「何の情報を公開し、何を隠すか」を厳密に制御できます。むしろ、データベースに直接触るよりもAPIを介した方が安全なのです。レストランのたとえで言えば、お客さんが直接厨房に入るより、ウェイターを通した方が厨房の秩序が保たれるのと同じです。 +

+
+
+
+
+
+
+ + + + + +
+
+
+ +
+

まとめ — 覚えておきたい3つのこと

+
+ +

+ 長い図解を読んでいただきありがとうございます。最後に、この記事で伝えたかったことを3つに絞ってまとめます。 +

+ +
+
+
+
01
+
+

APIは「ソフトウェアの窓口」

+

+ レストランのウェイターのように、あなた（アプリ）とサーバーの間を取り持つ仲介役。相手の内部構造を知らなくても、決まったルール（インターフェース）で話しかければ結果が返ってきます。 +

+
+
+
+ +
+
+
02
+
+

あなたはすでにAPIユーザー

+

+ 天気予報、SNSログイン、地図検索、オンライン決済。気づかないうちに、あなたの日常はAPIに支えられています。APIは特別な人だけのものではなく、全員の生活を支える仕組みです。 +

+
+
+
+ +
+
+
03
+
+

APIで「車輪の再発明」がなくなる

+

+ すでにある優れた機能をAPIで借りることで、自分は「自分にしか作れない部分」に集中できます。開発スピードが上がり、品質も上がり、保守の手間も減る。これがAPIの最大の恩恵です。 +

+
+
+
+
+ +
+ +

APIは「知っている」だけで世界が広がる概念です。

+

+ 次にアプリを使うとき、「この裏側でどんなAPIが動いているんだろう？」と想像してみてください。天気予報の数字も、ログインボタンも、決済完了の画面も、すべてAPIが繋いでいます。テクノロジーの見え方が、少しだけ変わるはずです。 +

+
+
+ + +
+ + + + + diff --git a/.claude/skills/creating-visual-explainers/references/node-install-guide.md b/.claude/skills/creating-visual-explainers/references/node-install-guide.md new file mode 100644 index 0000000..857b8d9 --- /dev/null +++ b/.claude/skills/creating-visual-explainers/references/node-install-guide.md @@ -0,0 +1,68 @@ +# Node.js インストールガイド + +SKILL.md の Step 5 で Node.js が未インストールだった場合に参照する。 + +## 説明と許可 + +以下をユーザーに伝え、インストールの許可を求める: + +> 図解の作成は完了しました。`output/index.html` をブラウザにドラッグ＆ドロップすれば、今すぐ確認できます。 +> +> URLで公開するには「Node.js」のインストールが必要です。 +> Node.js は、パソコン上でプログラムを動かすための土台で、世界中で使われている安全な道具です。 +> **README にも記載の通り、AI-Driven School 運営が確認済みですので安心してください。** +> +> 今からインストールしてもよいですか？ + +ユーザーが許可しなかった場合 → ファイルの確認方法（`output/index.html` をブラウザで開く）を伝えて終了。 + +## macOS の場合 + +インストーラーをダウンロードする: + +```bash +PKG_NAME=$(curl -sL https://nodejs.org/dist/latest-lts/ | grep -o 'node-v[0-9.]*\.pkg' | head -1) && curl -fsSL "https://nodejs.org/dist/latest-lts/${PKG_NAME}" -o /tmp/node-install.pkg && echo "ダウンロード完了: ${PKG_NAME}" +``` + +ダウンロード完了後、インストールを実行する**前に**以下を伝える: + +> インストールのために、パソコンのパスワードの入力が必要です。 +> これはパソコンにログインするときに使っているパスワードです。 +> 画面下のターミナル欄にパスワードを入力して Enter を押してください。 +> 入力中の文字は画面に表示されませんが、正常な動作です。 + +```bash +sudo installer -pkg /tmp/node-install.pkg -target / && rm /tmp/node-install.pkg +``` + +## Windows の場合 + +インストールを実行する**前に**以下を伝える: + +> インストール中に「このアプリがデバイスに変更を加えることを許可しますか？」という確認画面が表示されることがあります。 +> 「はい」を押してください。 + +```powershell +winget install OpenJS.NodeJS.LTS --accept-package-agreements --accept-source-agreements +``` + +インストール完了後、現在のターミナルで Node.js を使えるようにする: + +```powershell +$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User") +``` + +winget が使えない場合（「winget は認識されていません」と表示された場合）: + +```powershell +$msi = (Invoke-WebRequest -Uri "https://nodejs.org/dist/latest-lts/" -UseBasicParsing).Links.href | Where-Object { $_ -match "x64\.msi$" } | Select-Object -First 1; Invoke-WebRequest -Uri "https://nodejs.org/dist/latest-lts/$msi" -OutFile "$env:TEMP\node-install.msi" -UseBasicParsing; Start-Process msiexec.exe -ArgumentList "/i `"$env:TEMP\node-install.msi`"" -Verb RunAs -Wait; Remove-Item "$env:TEMP\node-install.msi" +``` + +## インストール完了の確認 + +```bash +node --version +``` + +バージョン番号が表示された → インストール成功。 +エラーが出た → Cursor を再起動してからもう一度試すよう案内する。 diff --git a/.claude/skills/creating-visual-explainers/scripts/deploy-diagram.sh b/.claude/skills/creating-visual-explainers/scripts/deploy-diagram.sh new file mode 100644 index 0000000..4554a75 --- /dev/null +++ b/.claude/skills/creating-visual-explainers/scripts/deploy-diagram.sh @@ -0,0 +1,56 @@ +#!/bin/bash +set -e + +HTML_FILE="${1:-output/index.html}" +SLUG="${2:-}" + +GREEN='\033[0;32m' +YELLOW='\033[1;33m' +RED='\033[0;31m' +NC='\033[0m' + +if ! command -v node &>/dev/null; then + echo -e "${RED}エラー: Node.js がインストールされていません${NC}" >&2 + echo "Node.js をインストールしてから、もう一度試してください。" >&2 + exit 1 +fi + +if [ ! -f "$HTML_FILE" ]; then + echo -e "${RED}エラー: $HTML_FILE が見つかりません${NC}" >&2 + echo "先に図解を生成してください。" >&2 + exit 1 +fi + +if [ -n "$SLUG" ]; then + DOMAIN="diagram-${SLUG}.surge.sh" +else + DOMAIN="diagram-$(date +%y%m%d%H%M).surge.sh" +fi + +TEMP_DIR=$(mktemp -d) +trap 'rm -rf "$TEMP_DIR"' EXIT + +cp "$HTML_FILE" "$TEMP_DIR/index.html" +printf "User-agent: *\nDisallow: /\n" > "$TEMP_DIR/robots.txt" + +echo -e "${YELLOW}公開中...${NC}" +npx --yes surge "$TEMP_DIR" --domain "$DOMAIN" + +touch deploy-history.log +echo "$(date '+%Y-%m-%d %H:%M:%S') | https://${DOMAIN}" >> deploy-history.log + +echo "" +echo -e "${GREEN}完了！${NC}" +echo "URL: https://${DOMAIN}" + +if [[ "$OSTYPE" == "darwin"* ]]; then + echo "https://${DOMAIN}" | pbcopy + echo -e "${GREEN}URLをクリップボードにコピーしました${NC}" +fi + +if command -v clip.exe &>/dev/null; then + echo -n "https://${DOMAIN}" | clip.exe + echo -e "${GREEN}URLをクリップボードにコピーしました${NC}" +fi + +echo -e "${YELLOW}削除するとき: npx surge teardown ${DOMAIN}${NC}" diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..ecbc70c --- /dev/null +++ b/.gitignore @@ -0,0 +1,6 @@ +output/*.html +!output/index.html +!output/git.html +!output/llm.html +!output/cursor.html +deploy-history.log diff --git a/README.md b/README.md new file mode 100644 index 0000000..c0a4913 --- /dev/null +++ b/README.md @@ -0,0 +1,230 @@ +# 図解ツール + +わからない言葉やしくみを AI に伝えるだけで、初めて聞く人にもわかるように噛み砕いた図解ページを自動で作ってくれるツールです。 + +検索してもよくわからなかったことが「なるほど」に変わります。 + +- **前提知識がなくても読める** — 専門用語は出てきた場所で必ずわかりやすく解説されます +- **いきなり難しくならない** — まず全体像を見せてから、細かい話に入ります +- **文字の壁にならない** — カード・ステップ図・比較表など、目で見てわかる構成です +- **毎回きれいな図解ができる** — テンプレートと模範回答をもとに、安定した品質で生成されます +- **スマホでも見やすい** — 画面サイズに合わせてレイアウトが自動で調整されます + +## まず見てみる + +`output/index.html` が図解ライブラリ（一覧ページ）です。 +ブラウザ（Chrome、Safari など）にドラッグ＆ドロップして開いてみてください。 +サンプルの図解が 3 つ入っているので、完成品のイメージがわかります。 + +- **Gitの仕組み** — 開発の土台になるバージョン管理ツール +- **LLM（大規模言語モデル）の仕組み** — AI 時代の中核技術 +- **Cursorの仕組み** — まさにこの図解ツールを動かしているエディタ + +気に入ったら、次のステップで自分だけの図解を作ってみましょう。 + +## 使い方 + +3 ステップで図解が完成します。 + +``` + ① このフォルダを Cursor で開く + ↓ + ② チャット欄で「○○を図解して」と依頼 + ↓ + ③ ブラウザで確認（自動で開きます） +``` + +### ステップ 1: このフォルダを Cursor で開く + +Cursor のメニューから「File → Open Folder」を選び、この「図解ツール」フォルダを開きます。 + +コードを書いたり、ファイルを編集したりする必要はありません。 +フォルダを開くだけで準備完了です。 + +### ステップ 2: チャット欄で図解を依頼する + +Cursor のチャット欄に、知りたいことを書いて送信します。 + +``` +APIについて図解して +``` + +これだけで OK です。AI が内容を読み取り、図解を自動で作ってくれます。 + +### ステップ 3: 図解を確認する + +AI が図解を作り、`output/` フォルダに保存します。 +完成すると自動でブラウザが開きます。 + +作った図解は上書きされず、どんどん溜まっていきます。 +`output/index.html`（図解ライブラリ）を開けば、過去の図解を一覧で確認できます。 + +## 使い方の例 + +こんなときに使えます。 + +- **「API とは何か、図解して」** + レストランの注文に例えて説明してくれるので、仕組みが腹落ちします + +- **「Git の rebase と merge の違いを図解して」** + Before / After の比較図で、2 つの違いが一目でわかるようになります + +- **「クラウドとは何か、図解して」** + 専門用語をひとつずつ噛み砕きながら、全体像が頭に入ります + +- **「HTML と CSS の関係を図解して」** + 役割の違いと連携の仕組みが、具体例つきで理解できます + +技術用語に限らず、どんなテーマでも図解にできます。 +特に指定しなくても、初めて聞く人にわかるレベルで説明してくれます。 + +## 図解を共有するには + +### PDF で共有する（おすすめ・準備不要） + +図解ページの下部にある「PDF でダウンロード」ボタンを押すと、印刷画面が開きます。 +保存先を「PDF」にすれば、そのままファイルとして保存できます。 + +保存した PDF は、メール・Slack・LINE などで誰にでも送れます。 +相手は特別なアプリもアカウントも不要で、すぐに読めます。 + +### URL で共有する（上級者向け） + +URL を発行して他の人にも共有したい場合は、以下の 2 つが必要です。 + +- **Node.js** — パソコン上でプログラムを動かすための土台 +- **Surge** — URL を発行してくれる無料の公開サービス + +どちらも、AI がチャット上でインストールと登録の手順を案内してくれます。 + +``` + 手元で見るだけ → 準備不要 + output/index.html をブラウザで開くだけ + + URL で共有する → Node.js + Surge が必要 + 初回だけセットアップが必要（AI が案内します） +``` + +公開した URL は `deploy-history.log` に自動で記録されます。 +過去の URL を忘れた場合は、AIチャット欄で「公開した URL を教えて」と聞いてください。 + +### 共有するときの注意 + +発行された URL は **Google などの検索結果には表示されません**。 +検索しても見つからないので、知らない人の目に偶然触れることはありません。 + +ただし、**URL を知っている人は誰でもページを見ることができます**。 +これは Google ドライブや Notion の「リンクを知っている人に共有」と同じ仕組みです。 + +``` + 検索エンジン → 見つからない ✅ + URL を知らない人 → 見られない ✅ + URL を知っている人 → 見られる ⚠️ +``` + +そのため、以下の点に気をつけてください。 + +- **社外秘や個人情報など、絶対に外に出てはいけない情報は図解の内容に含めない** +- URL の共有先は、見せたい相手だけに限定する（SNS の公開投稿に貼らない、など） + +社内の情報をどこまで図解に含めてよいかは、お勤め先のルールに従ってください。 +迷ったときは、上長やチームに確認するのが確実です。 + +### 初めて URL を発行するとき + +AI がチャット上で順番に案内してくれます。画面の指示に従うだけで完了します。 + +1. **Node.js のインストール** + AI が「インストールしてよいですか？」と確認してから進めます。 + Mac でも Windows でも対応しています。 + +2. **Surge の登録** + 初回だけメールアドレスとパスワードの入力が必要です。 + こちらも AI がその場で手順を教えてくれます。 + +Node.js は世界中の開発現場で使われている安全な道具です。 +AI-Driven School 運営が動作確認済みですので、安心してください。 + +## フォルダの中身 + +``` +図解ツール/ +├── .claude/skills/creating-visual-explainers/ ← AI への指示書（通常は非表示） +├── README.md ← この説明書 +└── output/ ← 図解の保存先 + ├── index.html ← 一覧ページ（自動生成） + └── ○○.html ← 個別の図解（どんどん増える） +``` + +「.claude」で始まるフォルダは通常は非表示です。表示されなくても問題ありません。 +あなたが触る必要があるファイルはありません。 +AI がすべて自動で処理します。 + +| ファイル / フォルダ | 説明 | 触る必要 | +|---|---|---| +| `output/` | 図解ライブラリ。`index.html` で一覧、各図解は個別ファイル | 見るだけ | +| `README.md` | この説明書 | 読むだけ | +| `.claude/skills/` | AI への指示書とテンプレート。AI が自動で読み込みます（通常は非表示） | なし | + +## Git で管理する場合 + +このフォルダを Git で管理する場合、`output/` 内の図解 HTML は `.gitignore` に追加することをおすすめします。 +図解は手元で読むためのもので、リポジトリに含める必要はありません。 + +同梱の `.gitignore` で、自分が作成した図解と `deploy-history.log` はあらかじめ除外されています。 + +## 困ったとき + +### 「base.html が見つかりません」と言われた + +「図解ツール」フォルダそのものを Cursor で開いているか確認してください。 +フォルダの中の個別ファイルではなく、フォルダごと開く必要があります。 + +### 図解がうまく生成されない + +チャット欄に「エラーが出ました」と伝えてください。 +AI が原因を調べて、対処法を案内してくれます。 + +### Node.js のインストールでつまずいた + +チャット欄で「Node.js のインストールがうまくいきません」と伝えてください。 +Mac / Windows それぞれに合わせた手順を案内してくれます。 + +解決しない場合は、Cursor を一度終了してから開き直すと直ることがあります。 + +### その他のトラブル + +何が起きても、まずはチャット欄で AI に状況を伝えてください。 +AI がエラーの内容を読み取り、次にやるべきことを教えてくれます。 + +## 利用量の目安 + +> 以下は 2026 年 3 月時点の Cursor 料金をもとにした参考値です。 +> 料金体系は変わることがあるため、最新の情報は [Cursor の料金ページ](https://cursor.com/pricing) で確認してください。 + +Cursor の Teams プラン（$40/ユーザー/月）には、月 **$20 ぶんの AI 利用枠** が含まれています。 +Claude Sonnet 4.6 で図解を作った場合、1 回あたりの消費は図解のボリュームによって変わります。 + +``` + 1 回あたりのコスト目安（Sonnet 4.6 の場合） + + 小さめの図解（用語の簡潔な解説） → 約 $0.18（約 27 円） + 標準的な図解（仕組みを丁寧に説明） → 約 $0.25（約 38 円） + 大きめの図解（全体像を網羅的に） → 約 $0.35（約 53 円） +``` + +$20 の利用枠で作れる図解の数は、ボリュームにもよりますがおおむね以下の通りです。 + +``` + 図解だけに使った場合 → 約 60〜110 回 + 半分を他の作業に使った場合 → 約 30〜55 回 +``` + +図解以外の作業（コードの質問、ファイル編集など）にも同じ利用枠を使います。 +1 日 1〜2 回のペースなら、月の利用枠に十分収まります。 + +利用枠を超えた場合は、同じ料金で自動的に追加課金されます（チーム管理者が上限を設定可能）。 + +--- + +Mac / Windows どちらでも使えます。AI-Driven School 運営が動作確認済みです。 diff --git a/output/.gitkeep b/output/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/output/cursor.html b/output/cursor.html new file mode 100644 index 0000000..bd35abc --- /dev/null +++ b/output/cursor.html @@ -0,0 +1,1010 @@ + + + + + + + + + + + Cursorの仕組み + + + + + + + + + +
+ +
+
+ + + + + +
+
+ + 開発ツール +
+

+ Cursorの仕組み +

+

+ 「AIでコードを書くって、どういうこと？」
+ ひとことで言うと ── +

+
+ + + + + +
+
+

+ Cursor = コードエディタに「AIの頭脳」を融合させた開発環境 +

+

+ あなたがコードを書くそばで、AIが文脈を読み、補完し、修正し、新しいコードまで生成する +

+
+ + +
+ +
+
+ +
+
あなた
+
コードを書く・指示する
+
+ + +
+
+ 操作・質問 + + +
+
+ + +
+
+ +
+
Cursor
+
VS Code + AIの頭脳
+
エディタとAIが一体化
+
+ + +
+
+ 問い合わせ + + +
+
+ + +
+
+ +
+
AIモデル群
+
Claude, GPT, Gemini...
+
+
+ + +
+
+ + AIの提案・修正がエディタにそのまま反映される +
+
+ + +
+
+
Cursorでできること
+
+
+ + +
+
+ + コード自動補完 +
+
+ + チャットで質問 +
+
+ + ファイル横断で修正 +
+
+ + 自律的にタスク実行 +
+
+ +
+ +

+ ここから先で、Cursorの仕組みをひとつずつ丁寧に解説していきます。 +

+ + + + + +
+
+
+ +
+

そもそもCursorって何？

+
+ +

+ ひとことで言えば、CursorはAIが組み込まれたコードエディタです。世界標準のエディタ「VS Code」に、AIの力を融合させたものです。 +

+ + +
+

CursorとVS Codeの関係

+ +
+ +
+
+ +
+
VS Code
+
世界標準のエディタ
+
高性能な「作業机」
+
+ + +
+
+ + +
+
+ + +
+
+ +
+
AI
+
大規模言語モデル
+
専属の「ベテラン助手」
+
+ + +
+
+ = +
+
+ + +
+
+ +
+
Cursor
+
AI搭載エディタ
+
助手が常駐する作業環境
+
+
+
+ +

+ コードエディタとは、プログラマーがプログラムを書くための専用ソフトです。Wordで文章を書くように、プログラマーはコードエディタで色分け表示・自動インデント・入力ミス検出などの機能を使いながらコードを書きます。 +

+ +

+ VS Code（Visual Studio Code）は、Microsoftが開発した無料のコードエディタで、世界中の開発者の約70%が使用しています。拡張機能で自分好みにカスタマイズできるのが魅力です。 +

+ +

+ フォークとは、オープンソースのコードをコピーし、それを土台に独自に発展させること。CursorはVS Codeをフォークして作られており、見た目も操作感もほぼ同じですが、AIがエディタの中核に組み込まれている点が根本的に違います。 +

+ +

+ 実際のCursorの画面を模して見てみましょう。 +

+ +
+ +
+
+
+
+
+
+
+ + Cursor — my-project +
+
+ +
+ + + +
+
+ app.py +
+ 
1  def greet(name):
+2      return f"Hello, {name}!"
+3
+4  # ここにユーザー一覧を返す関数を追加したい
+5  def get_users():
+6      return db.query("SELECT * FROM users")
+
+ + +
+
+ +

+ 左がファイル一覧、中央がコード、右がAIとのチャット。AIにやりたいことを伝えるだけで、コードが提案されます（緑の部分）。 +

+ +

+ ここで重要な区別があります。VS Codeに後からAIプラグイン（GitHub Copilotなど）を追加するのと、Cursorを使うのは本質的に異なります。たとえで言えば、普通の車にカーナビを後付けするのと、最初から自動運転システムが組み込まれた車を買うくらいの違い。Cursorでは、AIがファイル編集、ターミナル操作（コマンド実行）、ブラウザでのテスト、ウェブ検索までを一体的に操作できます。 +

+ + +
+
+
+ +
+
+

ここがポイント

+

+ CursorはVS Codeの「拡張版」ではなく「進化版」です。AIがエディタの操作系統そのものに組み込まれているから、プラグインの後付けでは実現できない深い統合が成り立っています。VS Codeでできることはすべてそのまま使えて、さらにAIの力が加わります。 +

+

出典: Cursor公式サイト

+
+
+
+
+ + + + + +
+
+
+ +
+

AIはどうやってコードを理解するのか

+
+ +

+ Cursorの最大の強みは、「あなたのプロジェクト全体を理解している」ことです。 +

+ +

+ たとえばChatGPTにコードの質問をする場合、関連するコードを自分でコピペして渡す必要がありますよね。Cursorは違います。プロジェクトの全ファイルを自動的に解析し、ファイル間の関係や構造を把握した上で回答します。1万行のコードがあっても、AIはその全体像を「地図」のように掴んでいるのです。 +

+ + +
+

CursorのAIが動く4ステップ

+ +
+
+
1
+ +
インデックス化
+
プロジェクト全体を読み取り
意味的な「地図」を作成
（ファイル間の関係も把握）
+
+ +
+ + +
+ +
+
2
+ +
文脈の構築
+
今開いているファイル、
カーソル位置、編集履歴から
「何をしたいか」を推測
+
+ +
+ + +
+ +
+
3
+ +
AIモデルに問い合わせ
+
構築した文脈を
Claude・GPT等に送信
（最適なモデルを選択）
+
+ +
+ + +
+ +
+
4
+ +
結果をエディタに反映
+
AIの回答をコードとして
エディタに表示・適用
（差分の確認も可能）
+
+
+
+ +

+ ここで重要なのが「文脈」（コンテキスト）の精度です。同じ「ボタンを追加して」という指示でも、ECサイトなら「カートに入れるボタン」、ブログなら「いいねボタン」が適切ですよね。Cursorはプロジェクト全体を読んでいるから、あなたのプロジェクトにフィットした提案を返すことができます。一般的なAIチャットとの決定的な違いがここにあります。 +

+ +
+
+
+ +
+
+

ちょっと補足: 対応AIモデル

+

+ Cursorは Claude（Anthropic社）、GPT（OpenAI社）、Gemini（Google社）など複数のAIモデルに対応しています。さらに独自の「Composer」というモデルも開発しており、通常のモデルの4倍の速度でコーディングタスクを処理できます。用途に応じてモデルを切り替えられるのも、Cursorの大きな特徴です。 +

+

出典: Cursor公式ブログ — Introducing Cursor 2.0 and Composer

+
+
+
+
+ + + + + +
+
+
+ +
+

5つの主要機能を図解する

+
+ +

+ Cursorには数多くの機能がありますが、大きく5つの柱に分けられます。それぞれを「何ができるのか」「何がうれしいのか」という視点で図解します。 +

+ + +
+ + +
+
+
+ +
+
+

Tab補完

+
「次に書きたいこと」を先読み
+
+
+

+ コードを数文字打ち始めると、AIが続きを予測して薄い文字で提案します。 +

+
+
+
+
+
+
+
+ app.py +
+
+
+ def calc_total(items): +
+
+ return sum(item.price for item in items) +
+
+ Tab ↹ で採用 +
+
+
+

+ 関数まるごとの予測もでき、入力量が劇的に減るため「考えること」に集中できます。 +

+
+ + +
+
+
+ +
+
+

エージェントモード

+
AIに「丸投げ」する
+
+
+

+ 「このボタンのデザインを変えて」「テストを書いて」と日本語で指示するだけで、AIが必要なファイルを特定し、コードを編集し、ターミナルでコマンドを実行します。 +

+

+ 2025年2月からCursorのメインインターフェースになりました。複数ファイルにまたがる修正も、エージェントが一気に片付けてくれます。 +

+

出典: Cursor Docs — Agent Overview

+
+
+ + +
+ + +
+
+
+ +
+
+

チャット

+
コードについて「会話」する
+
+
+

+ エディタの中でAIに直接質問できます。「この関数は何をしている？」「なぜこのエラーが出る？」と聞けば、あなたのプロジェクトの文脈を踏まえて回答が返ってきます。 +

+

+ コードを範囲選択して「これをもっとシンプルにして」と依頼することもできます。検索エンジンで調べるのとは違い、「あなたのコード」に即した回答が得られるのが強みです。 +

+
+ + +
+
+
+ +
+
+

MCP

+
外部ツールとの「橋渡し」
+
+
+

+ MCP（Model Context Protocol = AIが外部サービスを操作するための共通規格）を使うと、AIの「手」がエディタの外まで伸びます。 +

+

+ たとえば、Figma（デザインツール）からデザインデータを取得したり、Slack（チャットツール）にメッセージを送ったり、データベースを直接操作したり。AIが外部の道具を自在に使えるようになる仕組みです。 +

+
+
+ + +
+
+
+ +
+
+

バックグラウンドエージェント

+
クラウドで並列作業
+
+
+
+
+

+ 2026年2月に発表された最新機能です。AIがクラウド上の仮想マシン（インターネット上にある遠隔のコンピュータ）で作業するため、あなたのPCには負荷がかかりません。 +

+

+ これまでは1〜3つの作業を順番にこなしていましたが、バックグラウンドエージェントでは10〜20のタスクを同時並行で進められます。あなたが別の仕事をしている間に、AIが裏で黙々とコードを書き、テストを実行し、結果を報告してくれます。 +

+
+
+
指示を出せる場所
+
+
+ + デスクトップアプリ +
+
+ + Webブラウザ +
+
+ + モバイルアプリ +
+
+ + Slack / GitHub +
+
+

出典: CNBC (2026/2/24)

+
+
+
+ + +
+
+
+ +
+
+

5つの機能はバラバラではない

+

+ これらの機能は独立しているように見えて、裏側ではすべて同じ「文脈理解エンジン」を共有しています。Tab補完もチャットもエージェントも、あなたのプロジェクト全体を理解した上で動いている。だからどの機能を使っても、的外れな提案が出にくいのです。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

コーディングがどう変わるのか

+
+ +

+ 機能の説明だけでは実感が湧きにくいかもしれません。ここでは、具体的に「何がどう変わるのか」を数字と対比で見てみましょう。 +

+ + +
+
+
50%+
+
Fortune 500企業の
半数以上が導入
+

出典: Cursor公式

+
+
+
$29.3B
+
企業評価額
（約4.4兆円）
+

出典: CNBC (2026/2)

+
+
+
30秒
+
独自モデルComposerの
平均タスク完了時間
+

出典: Cursor公式ブログ

+
+
+ + +
+ +
+
+ + BEFORE — AIエディタがない世界 +
+
    +
  • + + エラーメッセージをコピーしてGoogle検索→Stack Overflowで解決策を探す +
    • +
  • + + 新しいライブラリの使い方を公式ドキュメントで何十ページも読む +
    • +
  • + + 変数名を変更するとき関連ファイルを1つずつ手作業で修正 +
    • +
  • + + コードレビューは人間同士のスケジュール調整が必要 +
    • +
+
+ + 「調べる時間」がコーディングの大半を占める +
+
+ + +
+
+ + AFTER — Cursorがある世界 +
+
    +
  • + + エラー箇所でAIに聞くと原因と修正コードが数秒で返る +
    • +
  • + + 「使い方を教えて」とチャットすれば自分のプロジェクトに合った実例を生成 +
    • +
  • + + 「全ファイルでリネームして」でAIが依存関係を把握して一括修正 +
    • +
  • + + AIが24時間いつでもコードレビューの相手になる +
    • +
+
+ + 「考える時間」にコーディングの大半を使える +
+
+
+
+ + + + + +
+
+
+ +
+

他のAIコーディングツールとの違い

+
+ +

+ AIを使ったコーディングツールはCursorだけではありません。代表的なGitHub Copilot（ギットハブ・コパイロット）やWindsurf（ウインドサーフ）との違いを整理します。 +

+ + +
+

AIコーディングツール 3つのアプローチ

+ +
+ +
+
+
+ +
+
Cursor
+
+
アプローチ
+

エディタ自体をAIで再設計

+
強み
+
    +
  • + + 複数ファイル横断の大規模修正 +
    • +
  • + + エージェントの自律的タスク実行 +
    • +
  • + + 深いコードベース理解 +
    • +
+
+ + +
+
+
+ +
+
GitHub Copilot
+
+
アプローチ
+

既存エディタにAIを追加

+
強み
+
    +
  • + + あらゆるエディタ・言語に対応 +
    • +
  • + + GitHubとの深い連携 +
    • +
  • + + 無料プランあり（月2,000回補完） +
    • +
+
+ + +
+
+
+ +
+
Windsurf
+
+
アプローチ
+

推論エンジンで文脈を深く追跡

+
強み
+
    +
  • + + 企業向けセキュリティ認証 +
    • +
  • + + 低コスト（月$10〜） +
    • +
  • + + 文脈を持続する推論エンジン +
    • +
+
+
+
+ +

+ GitHub Copilotは「既存のエディタにAIを追加する」アプローチ。VS CodeでもJetBrainsでもVimでも使えるのが利点ですが、エディタとの統合度はCursorに劣ります。Windsurfは独自の推論エンジンを持ち、企業向けの厳しいセキュリティ要件に対応しているのが特徴です。 +

+ +

+ Cursorが選ばれる最大の理由は、「エディタとAIの一体感」です。プラグインを追加するのではなく、エディタそのものがAIを前提に設計されているから、操作の流れが自然で、AIとの共同作業がスムーズに進みます。 +

+
+ + + + + +
+
+
+ +
+

よくある誤解

+
+ +

+ AIコーディングツールには、まだ多くの誤解があります。ここでは特に多い3つの誤解を取り上げて、正しい理解に修正します。 +

+ +
+ +
+
+
+ +
+

誤解: 「AIがコードを書くなら、プログラマーは不要になる」

+
+
+
+
+ +
+
+

実際は:

+

+ AIは「優秀なアシスタント」であって、意思決定者ではありません。建築家がCAD（設計ソフト）を使っても建築家が不要にならないのと同じです。何を作るか、なぜ作るかを決めるのは人間。AIはその実現速度を劇的に上げる道具です。むしろ、AIが定型的な実装を引き受けてくれるおかげで、人間はより創造的で価値の高い判断に集中できるようになります。 +

+
+
+
+
+ + +
+
+
+ +
+

誤解: 「AIが書いたコードはバグだらけで信用できない」

+
+
+
+
+ +
+
+

実際は:

+

+ AIの提案は必ず人間がレビューする前提の設計になっています。Cursorにはdiff表示（変更前後を並べて比較する機能）があり、AIの変更を1行ずつ確認してから承認できます。また、AIは人間が見落としがちなタイポ（打ち間違い）やパターンの不一致を検出してくれる面もあります。道具の出力を鵜呑みにせず、人間が最終判断するという姿勢が大切です。 +

+
+
+
+
+ + +
+
+
+ +
+

誤解: 「Cursorを使うにはAIの専門知識が必要」

+
+
+
+
+ +
+
+

実際は:

+

+ VS Codeが使える人なら、ほぼそのままCursorに移行できます。インターフェースはVS Codeと同じですし、日本語で指示を書くだけでAIが動きます。「プロンプトエンジニアリング」（AIへの指示を最適化する技術）の専門知識は不要です。「このエラーを直して」「テストを書いて」——日常の言葉で話しかけるだけで十分機能します。 +

+
+
+
+
+
+
+ + + + + +
+
+
+ +
+

まとめ — 覚えておきたい3つのこと

+
+ +

+ 最後に、この図解で伝えたかったことを3つに絞ってまとめます。 +

+ +
+
+
+
01
+
+

CursorはVS Codeに「AIの頭脳」を融合させたエディタ

+

+ 見た目はVS Codeと同じ。しかし中身は、AIがエディタの操作系統に深く統合された「AI-first」の設計。プラグインの後付けでは実現できない、AIとの自然な共同作業が可能になっています。 +

+
+
+
+ +
+
+
02
+
+

「プロジェクト全体を理解している」のが真の強み

+

+ ファイルを1つずつ見るのではなく、プロジェクト全体の文脈を把握した上で提案する。だからTab補完もチャットもエージェントも、あなたのコードベースに合った回答が返ってきます。一般的なAIチャットとの決定的な違いがここにあります。 +

+
+
+
+ +
+
+
03
+
+

AIは道具。使いこなすのは、あなた自身

+

+ Cursorは「何を作るか」を考える仕事を奪いません。「どう実装するか」の速度と精度を劇的に上げる道具です。AIにできることを正しく理解し、人間の判断と組み合わせる。そのスキルが、これからの開発者の新しい武器になります。 +

+
+
+
+
+ +
+ +

Cursorは「AIとどう働くか」の最前線にある道具です。

+

+ 次にコードを書くとき、エラーに詰まったとき、大量のファイルを修正しなければならないとき。AIが隣にいる環境を一度体験すると、もう元には戻れなくなります。コーディングの体験そのものが変わる。それがCursorの本質です。 +

+
+
+ + +
+ + + + + diff --git a/output/git.html b/output/git.html new file mode 100644 index 0000000..0a96687 --- /dev/null +++ b/output/git.html @@ -0,0 +1,1050 @@ + + + + + + + + + + + Gitの仕組み + + + + + + + + + +
+ +
+
+ + + + + +
+
+ + 開発ツール +
+

+ Gitの仕組み +

+

+ 「Git？バージョン管理？」と聞いてもピンとこない。
+ ひとことで言うと ── +

+
+ + + + + +
+
+

+ Git = コードの「タイムマシン」 +

+

+ いつでも過去の状態に戻れて、複数人で同時に安全に作業できる仕組み +

+
+ + +
+ +
+
+ +
+
作業ディレクトリ
+
ファイルを編集
+
+ + +
+
+ git add + + +
+
+ + +
+
+ +
+
ステージング
+
記録する変更を選ぶ
+
「次のセーブに含める」
+
+ + +
+
+ commit + + +
+
+ + +
+
+ +
+
リポジトリ
+
変更履歴を保管
+
+
+ + +
+
+ + push でクラウドへ送信 / pull でクラウドから取得 +
+
+ + +
+
+
似た体験、ありますよね
+
+
+ + +
+
+ + ゲームのセーブ&ロード +
+
+ + Googleドキュメントの変更履歴 +
+
+ + Ctrl+Z で「元に戻す」 +
+
+ + Dropboxの過去バージョン復元 +
+
+
+ +

+ ここから先で、この仕組みをひとつずつ丁寧に解説していきます。 +

+ + + + + +
+
+
+ +
+

そもそもGitって何？

+
+ +

+ Gitはコードの「セーブ＆ロード」ができるツールです。 +

+ + +
+

ゲームで考えるGitの役割

+
+
+
+
+
+
+
+
RPG — ボス戦前
+
+
+
+
セーブデータ
+
+
+ セーブ +
+
+ ロード +
+
+
+
+
+
+ Slot 1 + 5分前 — ボス戦前 +
+
+
+ Slot 2 + 3時間前 — 街の探索中 +
+
+
+ Slot 3 + 昨日 — 前の街 +
+
+
+
+

Gitはこの「セーブ＆ロード」を、コードに対してやってくれるツール

+
+ +

+ もしGitがなかったら、コードの管理はこうなります。 +

+ + +
+ +
+
+ + BEFORE — Gitがない世界 +
+
    +
  • + + ファイル名が「企画書_最終版_v2_本当の最終版.docx」だらけになる +
    • +
  • + + 同僚の変更で自分が書いたコードが上書きされて消える +
    • +
  • + + 「昨日まで動いてたのに...」と途方に暮れる +
    • +
  • + + なぜこの変更をしたのか、理由を誰も覚えていない +
    • +
+
+ + 元に戻したくても戻せない。原因の特定に何時間もかかる。 +
+
+ + +
+
+ + AFTER — Gitがある世界 +
+
    +
  • + + すべての変更に日時・作者・説明メッセージが自動で付く +
    • +
  • + + 複数人が同時に編集しても安全に統合（マージ）できる +
    • +
  • + + 任意の過去の状態にいつでも一瞬で戻せる +
    • +
  • + + 「誰が、いつ、なぜ変えたか」が全部記録されている +
    • +
+
+ + 怖がらずに変更でき、問題があってもすぐ原因を特定できる。 +
+
+
+ + +
+
技術的な定義
+

+ Git = ファイルの変更履歴を記録・追跡し、 + いつでも過去の状態に復元できる分散型バージョン管理システム +

+

出典: git-scm.com — About Git

+
+ +

+ Gitは2005年に、Linux（リナックス）というOSを開発したリーナス・トーバルズが作りました。Linuxは世界中の何百人もの開発者が同時にコードを変更するプロジェクトです。その膨大な変更を安全に管理するために生まれたのがGitでした。つまりGitは最初から、大規模なチーム開発のために設計されたツールなのです。 +

+ + +
+
+
+ +
+
+

ここがポイント

+

+ Gitは「コードのタイムマシン」であり、同時に「チームの交通整理係」でもあります。過去に戻る力と、複数人の作業を安全にまとめる力。この2つがGitの本質です。現在、プロの開発者の96%がGitを使っています。 +

+

出典: Stack Overflow Developer Survey 2022

+
+
+
+
+ + + + + +
+
+
+ +
+

Gitの「3つの場所」を理解する

+
+ +

+ Gitを使うとき、ファイルは3つの場所を行き来します。この3つの関係がわかれば、Gitの仕組みの大半は理解できたと言っても過言ではありません。 +

+ +

+ わかりやすいように、「手紙を書いて送る」プロセスにたとえてみましょう。 +

+ + +
+

Gitの3つの場所 — 手紙で考える

+ +
+ +
+
+ +
+
作業ディレクトリ
+
Working Directory
+
手紙を書いている机
+
+ + +
+
+ git add + + +
+
+ + +
+
+ +
+
ステージング
+
Staging Area
+
封筒に入れた手紙
+
+ + +
+
+ commit + + +
+
+ + +
+
+ +
+
リポジトリ
+
Repository
+
郵便局の配達記録
+
+
+ +
+
+ + 過去のどの記録にも、いつでも戻れる +
+
+
+ + +
+
+
+ +
+
+

作業ディレクトリ（Working Directory）

+

+ あなたが実際にファイルを編集している場所です。手紙のたとえで言えば、机の上で手紙を書いたり、消しゴムで書き直したりしている段階です。この段階の変更はまだGitに記録されていません。ただの「書きかけ」の状態です。自由に書き直し、試行錯誤できます。 +

+
+
+ +
+
+ +
+
+

ステージングエリア（Staging Area）

+

+ 「次のコミットに含める変更」を選んで置いておく場所です。手紙のたとえで言えば、書き終わった手紙を封筒に入れた状態です。まだポストに投函していないので、「やっぱりこの手紙は出さない」と封筒から出すこともできます。「10ファイル変更したけど、今回は3ファイルだけ記録したい」ということが可能になるのが、この場所の存在意義です。 +

+
+
+ +
+
+ +
+
+

リポジトリ（Repository）

+

+ 変更履歴が永久に保管される場所です。手紙のたとえで言えば、郵便局が「いつ、誰が、どんな手紙を送ったか」をすべて記録しているのと同じです。リポジトリに記録された変更（これをコミット（Commit）と呼びます）は消えることがなく、いつでも確認でき、いつでもその時点の状態に戻れます。 +

+
+
+
+ + +
+
+
+ +
+
+

なぜ「ステージング」が必要なの？

+

+ 「編集したら即座に記録すればいいのでは？」と思うかもしれません。しかし実際の開発では、バグ修正と新機能の追加を同時進行していることがよくあります。ステージングがあることで、「バグ修正だけ先に記録して、新機能の開発は後から記録する」という意味のある単位で履歴を残すことができるのです。これにより、後から「どの変更が原因でバグが起きたか」を特定しやすくなります。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

基本操作の流れ — edit, add, commit, push

+
+ +

+ Gitの日常的な作業は、たった4つのステップの繰り返しです。開発者が毎日何十回と繰り返すこの流れを、順番に見ていきましょう。 +

+ + +
+

Gitの基本サイクル

+ +
+
+
1
+ +
ファイルを編集
+
コードを書く・修正する
（ここはGit関係なし）
+
+ +
+ + +
+ +
+
2
+ +
git add
+
記録したいファイルを
ステージングに追加する
+
+ +
+ + +
+ +
+
3
+ +
git commit
+
ステージングの内容を
メッセージ付きで記録
+
+ +
+ + +
+ +
+
4
+ +
git push
+
ローカルの記録を
クラウドに送信する
+
+
+
+ +

+ では実際に、ターミナル（コマンドを入力する黒い画面）で打つコマンドを見てみましょう。たったこれだけのコマンドで、変更が記録されてクラウドに送信されます。 +

+ + +
+
+
+
+
+
+
+
+
+ + ターミナル — Gitの基本操作 +
+
+ 
# 1. ファイルを編集する（普通にコードを書く。Gitの操作は不要）
+
+# 2. 変更したファイルをステージングに追加する
+$ git add index.html
+
+# 3. メッセージ付きで変更を記録する
+$ git commit -m "ログインページのデザインを変更"
+
+# 4. 記録をリモート（クラウド）に送信する
+$ git push origin main
+
+
+ + +
+

+ + コマンドの解説（1つずつ読み解く） +

+
+
+ add + git add index.html は「index.htmlの変更を、次のコミットに含める」という宣言です。複数ファイルをスペース区切りで指定したり、git add . で全ファイルを一括追加することもできます。手紙のたとえで言えば「この手紙を封筒に入れる」にあたります。 +
+
+ commit + git commit -m "メッセージ" は「ステージングの内容を、説明メッセージ付きで永久に記録する」コマンドです。-m はmessage（メッセージ）の頭文字。ゲームで言えば「セーブする」瞬間です。メッセージには「何を、なぜ変えたか」を簡潔に書きます。 +
+
+ push + git push origin main は「自分のパソコンに記録した履歴を、GitHubなどのクラウドに送信する」コマンドです。origin はリモートリポジトリのデフォルト名、main はブランチ名（次のセクションで説明します）です。 +
+
+
+ +

+ 逆に、チームメンバーがクラウドに送った変更を自分のパソコンに取り込むときは、git pull を使います。 +

+ + +
+
+
+
+
+
+
+
+
+ + ターミナル — 履歴の取得と確認 +
+
+ 
# リモートの最新状態を自分のパソコンに取り込む
+$ git pull origin main
+
+# 変更履歴を確認する（誰が何をしたか一覧で見える）
+$ git log --oneline
+a1b2c3d ログインページのデザインを変更
+e4f5g6h ユーザー登録機能を追加
+i7j8k9l データベース接続設定を修正
+
+
+ +
+
+
+ +
+
+

覚えるのは4つだけ

+

+ 日常的に使うGitコマンドは、add（選ぶ） → commit（記録する） → push（送る） → pull（もらう）の4つです。この4つさえ覚えれば、基本的なバージョン管理はすぐに始められます。実際の開発で使うコマンドの大半は、この4つの組み合わせです。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

ブランチ — 平行世界で安全に実験する

+
+ +

+ Gitの最も強力な機能のひとつがブランチ（Branch = 枝）です。ブランチとは、開発のメインラインから「枝分かれ」して、独立した作業空間を作る仕組みのことです。 +

+ +

+ たとえ話で考えてみましょう。あなたは小説を書いています。本筋はほぼ完成していますが、「この登場人物を追加したらどうなるだろう？」と実験したい。でも本筋を直接書き換えて失敗したら大変です。そこで原稿をまるごとコピーして、コピーの方で思い切り実験する。うまくいったら本筋に反映する。ダメだったらコピーを捨てるだけ。これがブランチの考え方です。 +

+ + +
+

ブランチの流れ — 3ステップ

+ +
+ +
+
1
+ +
枝分かれ（branch）
+
mainブランチから
新しいブランチを作成
（コピーのようなもの）
+
+ +
+ + +
+ + +
+
2
+ +
自由に開発
+
ブランチ上で自由に
コードを変更する
（mainには一切影響なし）
+
+ +
+ + +
+ + +
+
3
+ +
統合（merge）
+
完成したらmainに
マージして合流
（失敗なら捨てるだけ）
+
+
+
+ +

+ ここでのポイントは、featureブランチでの作業中も、mainブランチには一切影響がないということです。小説のたとえで言えば、コピー原稿をどんなに書き換えても、金庫にしまった本筋の原稿は無傷のまま。だからこそ安心して大胆な実験ができるのです。 +

+ + +
+
+
+
+
+
+
+
+
+ + ターミナル — ブランチの基本操作 +
+
+ 
# 新しいブランチを作って、そこに切り替える
+$ git switch -c feature-login
+
+# ブランチ上で自由にコードを書く（mainには影響しない）
+$ git add login.html
+$ git commit -m "ログイン機能を実装"
+
+# mainブランチに戻る
+$ git switch main
+
+# featureブランチの変更をmainに統合する
+$ git merge feature-login
+
+
+ + +
+
+
+ +
+
+

mainを壊さない安全性

+

実験的な変更はブランチ上で行い、完成してからmainに統合する。本番環境が壊れるリスクを大幅に減らせます。

+
+
+
+
+ +
+
+

同時並行で作業できる

+

Aさんはログイン機能、Bさんは検索機能と、それぞれ別のブランチで独立して開発を進められます。お互いの作業が衝突しません。

+
+
+
+
+ + + + + +
+
+
+ +
+

GitとGitHubは別物

+
+ +

+ 「Git」と「GitHub（ギットハブ）」は名前が似ていますが、まったく別のものです。混同している人がとても多いので、ここで明確に区別しておきましょう。ひとことで言えば、GitはWordのような「ツール」、GitHubはGoogle Driveのような「サービス」です。 +

+ + +
+
+
+
+ +
+
+

Git

+
ツール（ソフトウェア）
+
+
+
    +
  • + + 自分のパソコンにインストールして使う +
    • +
  • + + ファイルのバージョン管理機能を提供 +
    • +
  • + + コマンドライン（ターミナル）で操作 +
    • +
  • + + 完全無料のオープンソースソフトウェア +
    • +
+
+ + インターネットなしでも使える +
+
+ +
+
+
+ +
+
+

GitHub

+
Webサービス（プラットフォーム）
+
+
+
    +
  • + + インターネット上で動くクラウドサービス +
    • +
  • + + Gitリポジトリのホスティング（保管場所）を提供 +
    • +
  • + + ブラウザ上でコードレビューや議論ができる +
    • +
  • + + 無料プランと有料プランがある +
    • +
+
+ + 世界で1億人以上の開発者が利用 +
+
+
+ +
+

身近なたとえで整理すると

+
+
+
Git
+
Wordのような
「文書作成ツール」
+
+
:
+
+
GitHub
+
Google Driveのような
「クラウド保管&共有サービス」
+
+
+

Wordがなくてもファイルは作れるし、Google Driveがなくてもファイルは保存できる。でも両方使うと圧倒的に便利。

+
+ +
+
+
+ +
+
+

GitHub以外の選択肢もある

+

+ GitHubは最も有名ですが、同じ「Gitリポジトリのホスティングサービス」にはGitLabやBitbucketもあります。どれも中身で使っている技術はGitです。Gmail、Outlook、Yahoo!メールのように、「サービスは違うけど、やっていることは同じ（メールの送受信）」というイメージに近いです。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

よくある誤解

+
+ +

+ Gitについて学び始めると、多くの人が同じところでつまずきます。ここでは、よくある3つの誤解を取り上げて、正しい理解に修正します。 +

+ +
+ +
+
+
+ +
+

誤解: 「Gitはプログラマーだけが使うもの」

+
+
+
+
+ +
+
+

実際は:

+

+ Gitはテキストファイルならなんでもバージョン管理できます。デザイナーがデザインデータを管理したり、ライターが原稿の変更履歴を追ったり、研究者が論文の共同執筆に使ったり。「ファイルの変更を追いたい」すべての人にとって有益なツールです。 +

+
+
+
+
+ + +
+
+
+ +
+

誤解: 「一度削除したファイルは戻せない」

+
+
+
+
+ +
+
+

実際は:

+

+ Gitで一度コミットした変更は、事実上消えません。ファイルを削除しても、過去のコミットにそのファイルが存在していた記録が残っています。git checkout や git restore コマンドで、過去の状態からいつでも復元できます。まさに「タイムマシン」の真骨頂です。 +

+
+
+
+
+ + +
+
+
+ +
+

誤解: 「Gitを使うにはインターネットが必要」

+
+
+
+
+ +
+
+

実際は:

+

+ Gitは「分散型」のバージョン管理システムです。「分散型」とは、リポジトリの完全なコピーが自分のパソコンにあるという意味です。だからインターネットに接続していなくても、コミット（記録）も履歴の確認もブランチの作成もすべてできます。インターネットが必要になるのは、pushやpullでクラウド上のリモートリポジトリとやり取りするときだけです。飛行機の中でもコーディングとコミットは問題なくできます。 +

+
+
+
+
+
+
+ + + + + +
+
+
+ +
+

まとめ — 覚えておきたい3つのこと

+
+ +

+ 最後に、この図解で伝えたかったことを3つに絞ってまとめます。 +

+ +
+
+
+
01
+
+

Gitは「コードのタイムマシン」

+

+ ファイルの変更を「いつ、誰が、何を、なぜ」変えたかという情報とともに記録し、いつでも過去の状態に戻れます。ゲームのセーブ&ロードを、コードの世界で実現する仕組みです。 +

+
+
+
+ +
+
+
02
+
+

基本は「add → commit → push → pull」の4つ

+

+ 作業ディレクトリ・ステージング・リポジトリの3つの場所を、4つのコマンドでファイルが行き来する。この流れさえ理解すれば、Gitの基本操作は身につきます。 +

+
+
+
+ +
+
+
03
+
+

ブランチで「安全な実験場」を作れる

+

+ メインの開発ラインを壊さずに新しい機能を試せるブランチの仕組みが、Gitの最大の武器です。チーム全員が安心して同時に開発を進められます。 +

+
+
+
+
+ +
+ +

Gitは、現代のソフトウェア開発を支える「共通言語」です。

+

+ 世界中の開発者の96%が使うGit。最初はコマンドに戸惑うかもしれませんが、基本の4つのコマンドを覚えれば、もう「最終版_v2_本当の最終版」に悩まされることはありません。まずは小さなプロジェクトで git init と打つところから始めてみてください。 +

+

出典: git-scm.com / Stack Overflow Developer Survey 2022

+
+
+ + +
+ + + + + diff --git a/output/index.html b/output/index.html new file mode 100644 index 0000000..ad50a95 --- /dev/null +++ b/output/index.html @@ -0,0 +1,77 @@ + + + + + + + + 図解ライブラリ + + + + + + + + +
+
+

図解ライブラリ

+

チャット欄で「○○を図解して」と依頼すると、ここに追加されます

+
+ +
+ +

Gitの仕組み

+

Gitの仕組みを、身近なたとえとビジュアルでわかりやすく図解します。

+ + +

LLM（大規模言語モデル）の仕組み

+

LLMの仕組みを、身近な例とビジュアルでわかりやすく図解します。

+ + +

Cursorの仕組み

+

AIが組み込まれたコードエディタ「Cursor」の仕組みを、身近な例とビジュアルでわかりやすく図解します。

+ +
+ +
+

こんなことを聞いてみよう

+
+
「API とは何か、図解して」
+
「Git の rebase と merge の違いを図解して」
+
「クラウドとは何か、図解して」
+
「KPI と KGI の違いを図解して」
+
「HTML と CSS の関係を図解して」
+
「UI と UX の違いを図解して」
+
+
+
+ + + diff --git a/output/llm.html b/output/llm.html new file mode 100644 index 0000000..6e3792c --- /dev/null +++ b/output/llm.html @@ -0,0 +1,1142 @@ + + + + + + + + + + + LLM（大規模言語モデル）の仕組み + + + + + + + + + +
+ +
+
+ + + + + +
+
+ + AI・機械学習 +
+

+ LLMの仕組み +

+

+ 「ChatGPTってどういう仕組みなの？」と聞かれて、うまく答えられない。
+ ひとことで言うと ── +

+
+ + + + + +
+
+

+ LLM = 膨大な文章を読んで「次の言葉」を予測するAI +

+

+ 大量のテキストから言葉の使い方を学び、人間のような文章を生み出す +

+
+ + +
+ +
+
+ +
+
あなたの質問
+
「明日の会議の議事録を書いて」
+
+ + +
+
+ 入力 + + +
+
+ + +
+
+ +
+
LLM
+
文脈を理解し、次の言葉を予測
+
超高速の「穴埋めの天才」
+
+ + +
+
+ 出力 + + +
+
+ + +
+
+ +
+
生成された文章
+
自然で的確な回答が届く
+
+
+ + +
+
+
あなたも毎日触れている
+
+
+ + +
+
+ + ChatGPT +
+
+ + 翻訳アプリ +
+
+ + コード補完 +
+
+ + AI検索 +
+
+ + 文章要約・校正 +
+
+ +
+ +

+ ここから先で、この仕組みをひとつずつ丁寧に解説していきます。 +

+ + + + + +
+
+
+ +
+

そもそもLLMって何？

+
+ +

+ LLMは Large Language Model（ラージ・ランゲージ・モデル）の略で、日本語では「大規模言語モデル」と訳します。名前に含まれる3つの単語がそのまま特徴を表しています。 +

+ + +
+

名前に秘密がある ── 3つの単語を分解

+
+
+
+ +
+
Large（大規模）
+
数千億〜数兆個の「パラメータ」（調整つまみ）を持つ。人間の脳の神経接続のように、膨大な情報の繋がりを記憶している
+
+
+
+ +
+
Language（言語）
+
扱うのは「言葉」。人間が書いた文章を大量に読み込んで、言葉の使い方・つながり・ニュアンスを学習している
+
+
+
+ +
+
Model（モデル）
+
数学的な計算の仕組み。入力されたテキストを受け取り、規則に従って処理し、結果を出力する「装置」のようなもの
+
+
+
+ +

+ つまりLLMとは、膨大な量の文章データを読み込んで、「言葉の使い方」を身につけたAIです。では、「言葉の使い方を身につける」とは、具体的にどういうことでしょうか？ +

+ +

+ 実は、LLMの基本動作は驚くほどシンプルです。やっていることはたった一つ ── 「次に来る言葉を予測する」。これだけです。 +

+ + +
+

「穴埋めテストの天才」で考えるLLM

+

LLMは文の続きを予測し続ける。たった一つの動作を超高速で繰り返している。

+ + +
+
問題文
+

+ 「今日は天気が ??? ので、公園に ???」 +

+
+ + +
+
+
+ +
LLMの頭の中（1つめの空欄）
+
+
+
+
+
+ 良い ── 72% +
+
+
+
+
+ 悪い ── 15% +
+
+
+
+
+ 穏やかな ── 8% +
+
+
+
+
+ その他 ── 5% +
+
+
+
+ + 最も確率が高い「良い」を選択 +
+
+ +
+
+ +
LLMの頭の中（2つめの空欄）
+
+
+
+
+
+ 行きましょう ── 68% +
+
+
+
+
+ 出かけたい ── 18% +
+
+
+
+
+ 散歩しよう ── 10% +
+
+
+
+
+ その他 ── 4% +
+
+
+
+ + 「天気が良い＋公園」の文脈で「行きましょう」を選択 +
+
+
+ + +
+
完成
+

+ 「今日は天気が 良い ので、公園に 行きましょう」 +

+

この「予測 → 選択」を1秒間に数百回繰り返すことで、長い文章が生まれる

+
+
+ +

+ では、LLMが実際に使われている画面を見てみましょう。あなたもすでに見たことがあるはずです。 +

+ +
+
+
+
+
+
+
+
+ + AIチャット +
+
+
+ +
+
+

東京の明日の天気を教えて

+
+
+ +
+
+ +
+
+

東京の明日の天気は晴れ時々くもり、最高気温は24°Cの予報です。午後から雲が増える見込みですが、傘は必要なさそうです。

+
+
+ +
+ メッセージを入力... + +
+
+
+ +

+ このチャット画面の裏側で、LLMが「次に来る単語」を猛烈な速度で予測し続けています。 +

+ +

+ 「なんだ、穴埋めをしているだけなのか」と拍子抜けするかもしれません。しかし、ここがポイントです。この単純な予測を、数兆語分の知識を使って、文脈を深く理解しながら行うからこそ、まるで人間が書いたかのような自然な文章が生まれるのです。 +

+ +

+ ここで言う「パラメータ」とは、LLMが学習を通じて調整する数値のことです。たとえるなら、巨大なミキサー卓（音楽のミキシングコンソール）についた無数のつまみ。1つ1つのつまみが「この単語の後にはこの単語が来やすい」といった知識を少しずつ記憶しています。つまみの数が多いほど、より繊細で正確な言語理解ができるようになります。 +

+ + +
+
+
1,750億
+
GPT-3のパラメータ数
+

出典: Brown et al., 2020

+
+
+
数兆語
+
学習に使われた
テキストデータの量
+
+
+
100万+
+
最新LLMが一度に
処理できる文字数
+

GPT-5, Claude, Geminiの最大コンテキスト長（2026年時点）

+
+
+ + +
+
+
+ +
+
+

ここがポイント

+

+ LLMの本質は「次の単語の予測」です。この単純な原理を、桁違いの規模（パラメータ数・データ量・計算量）で実行することで、要約・翻訳・プログラミング・質問応答まで、驚くほど幅広い言語タスクをこなせるようになりました。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

LLMの中で何が起きているのか

+
+ +

+ 「次の言葉を予測している」ということはわかりました。では、LLMの内部では、具体的にどんな処理が行われているのでしょうか。テキストが入力されてから出力されるまでを、4つのステップに分解して見てみましょう。 +

+ + +
+

入力から出力までの4ステップ

+ +
+
+
1
+ +
トークン化
+
文章を「トークン」
という小さな単位に
分割する
+
+ +
+ + +
+ +
+
2
+ +
ベクトル化
+
各トークンを
数値の列（ベクトル）
に変換する
+
+ +
+ + +
+ +
+
3
+ +
Transformer処理
+
Attention機構で
単語同士の関係を
深く理解する
+
+ +
+ + +
+ +
+
4
+ +
次の言葉を出力
+
最も自然な「次の
トークン」を選んで
文章を組み立てる
+
+
+
+ +

+ それぞれのステップをもう少し詳しく見てみましょう。 +

+ + +
+

+ 1 + トークン化 ── 文章をパーツに分解する +

+

+ コンピュータは「文章」をそのまま理解できません。まず、文章を「トークン」と呼ばれる小さな単位に分割します。トークンは単語そのものではなく、単語より少し小さいパーツです。英語の場合、だいたい1トークン = 4文字程度。日本語では1文字が1トークンになることもあります。 +

+
+
例: 「私はAIについて学んでいます」
+
+ 私 + は + AI + について + 学 + んで + います +
+

実際のトークン分割はモデルによって異なります。上記は概念的な例です。

+
+
+ + +
+

+ 2 + ベクトル化 ── 言葉を数値に変換する +

+

+ コンピュータが処理できるのは数値だけです。そこで、各トークンを「ベクトル」（数値の列）に変換します。この操作を「埋め込み（Embedding）」と呼びます。たとえるなら、言葉を「座標」に変換するようなものです。意味が近い言葉は座標上でも近い位置に配置されます。 +

+
+
言葉の座標イメージ
+
+
+ 「犬」 +
+ 0.82 + -0.15 + 0.63 + ... +
+
+
+ 「猫」 +
+ 0.79 + -0.12 + 0.58 + ... +
+
+
+

「犬」と「猫」は意味が近いので、数値（座標）も似た値になる。実際のベクトルは数千〜数万次元。

+
+
+ + +
+

+ 3 + Transformer処理 ── 文脈を理解する頭脳 +

+

+ ここがLLMの心臓部です。Transformer（トランスフォーマー）は2017年にGoogleの研究者が発表したAIの設計図（アーキテクチャ）で、現在のほぼすべてのLLMがこの設計を採用しています。その中核にあるのが「Attention（アテンション = 注意機構）」と呼ばれる仕組みです。 +

+

+ Attentionが何をするかを、日常のたとえで説明します。あなたが「お金を銀行に預けた」という文を読むとき、「銀行」が「金融機関」のことだと瞬時にわかりますよね。しかし「川の土手に座った」と書いてあれば、「川岸」を想像するはずです。あなたは無意識に周囲の単語を見て、言葉の意味を判断しています。Attentionはまさにこれをやっています。 +

+

出典: Vaswani et al., "Attention Is All You Need", 2017

+ + +
+
Attention の動き ── 各単語が他の単語をどれだけ「注目」するか
+
+
+ お金 + を + 銀行 + に + 預けた +
+
+ + 「銀行」は「お金」と「預けた」に強く注目 +
+
+ お金 ── 注目度: 高 + を ── 注目度: 低 + 預けた ── 注目度: 高 +
+
+ + 結論: この「銀行」は「金融機関」だと判断できる +
+
+
+
+ + +
+

+ 4 + 次の言葉を出力 ── 最も自然な続きを選ぶ +

+

+ Transformer層を何十回も通過して文脈を深く理解したら、最後に「次に来る最も自然なトークン（言葉のパーツ）は何か？」を計算します。語彙全体（数万〜数十万語）の中から確率を計算し、最も適切なトークンを1つ選びます。そして、その選んだトークンを文末に追加して、再びステップ1から繰り返す。この超高速なループ（毎秒数百トークン）によって、長い文章が生まれます。 +

+
+ +
+
+
+ +
+
+

ちょっと補足: マルチヘッドAttention

+

+ 実際のLLMでは、1回の処理で複数のAttention（注意の視点）を同時に走らせます。これを「マルチヘッドAttention」と呼びます。たとえるなら、1人で本を読むのではなく、96人のチームが同じ文章を同時に読んで「文法の観点」「意味の観点」「トピックの観点」など、それぞれ異なる角度から分析している状態です。GPT-3では96個のAttentionヘッドが並列で動いています。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

LLMはどうやって賢くなるのか

+
+ +

+ LLMは生まれたときから賢いわけではありません。最初はランダムな数値の塊にすぎず、「あいうえお」すらまともに出力できません。そこから3つの段階を経て、私たちが使えるレベルまで成長します。 +

+ +

+ この3段階を、人間の成長にたとえると理解しやすくなります。 +

+ + +
+

LLMの成長 ── 3つのフェーズ

+ +
+ +
+
+
1
+
+
+
+
+ 事前学習（Pre-training） +
+

たとえ: 図書館の本をすべて読む子ども

+

+ インターネット上の膨大なテキスト（Wikipedia、書籍、ニュース記事、Webサイト、コードなど）を読み込み、「言語のルール」を学びます。このとき学んでいるのは特定の質問への答えではなく、「日本語とはこういう風に使う」「プログラミング言語はこういう構文」という言語の根本的なパターンです。 +

+
+ Wikipedia + 書籍・論文 + Webページ + ソースコード + ニュース記事 +
+
+
+ + +
+
+
2
+
+
+
+
+ ファインチューニング（Fine-tuning） +
+

たとえ: 家庭教師について「対話の仕方」を練習する

+

+ 事前学習だけだと、LLMは「文章の続きを書く」ことはできますが、「質問に的確に答える」「指示に従って行動する」ことは苦手です。そこで、人間が作った高品質な「質問と回答のペア」を使って追加学習を行います。これにより「ユーザーが何を求めているか」を理解し、適切な形式で応答できるようになります。 +

+
+
+ + +
+
+
3
+
+
+
+ RLHF（人間のフィードバックによる強化学習） +
+

たとえ: 先輩に「どっちの回答がいい？」と何千回も評価してもらう

+

+ RLHF = Reinforcement Learning from Human Feedback（人間のフィードバックに基づく強化学習）。同じ質問に対してLLMが複数の回答を生成し、人間の評価者が「こっちの方がわかりやすい」「こっちは正確」と評価します。その評価結果を使って「良い回答とは何か」の基準を学習します。安全性やマナーもこの段階で身につきます。 +

+

出典: Ouyang et al., "Training language models to follow instructions with human feedback", 2022

+
+
+
+
+ + +
+
+
+ + 事前学習のみのLLM +
+
+
+
質問: 「東京タワーの高さは？」
+
+

東京タワーの高さは333メートルで、1958年に完成した。東京タワーは日本電波塔とも呼ばれ、観光名所としても知られている。東京タワーの周辺には芝公園があり...

+
+

+ + 答えは合っているが、聞いていないことまで延々と続く +

+
+
+
+ +
+
+ + RLHF後のLLM +
+
+
+
質問: 「東京タワーの高さは？」
+
+

東京タワーの高さは333メートルです。

+
+

+ + 質問に対して的確に、簡潔に答えている +

+
+
+
+
+ +
+
+
+ +
+
+

気づきましたか？

+

+ LLMが「賢く見える」のは、事前学習で言語能力を身につけた上に、ファインチューニングとRLHFで「人間にとって役立つ回答の仕方」を学んでいるからです。知識だけでなく、「コミュニケーション能力」も後から訓練されているのです。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

代表的なLLM ── 今、誰が作っているのか

+
+ +

+ 2026年現在、LLMの開発競争は激しさを増しています。特に大きな存在感を示しているのが、以下の3社です。それぞれのモデルには異なる強みがあり、用途に応じて使い分けるのが一般的になっています。 +

+ + +
+ +
+
+
+ +
+
+

GPT-5シリーズ

+

OpenAI

+
+
+
+

ChatGPTの頭脳。世界で最も多くのユーザーに使われているLLMシリーズ。数学や論理的推論に特に強みを持ちます。

+
+ 数学が得意 + 高速処理 + 幅広い用途 +
+
+
+ + +
+
+
+ +
+
+

Claude

+

Anthropic

+
+
+
+

安全性と正確性を重視して設計されたLLM。特にプログラミングと長文の処理に強く、開発者から高い支持を得ています。

+
+ コーディング最強 + 安全性重視 + 長文に強い +
+
+
+ + +
+
+
+ +
+
+

Gemini

+

Google

+
+
+
+

テキストだけでなく、画像・動画・音声も同時に理解できる「マルチモーダル」が最大の強み。Google検索やYouTubeとの連携も特徴です。

+
+ マルチモーダル + 推論が得意 + コスト効率 +
+
+
+ + +
+
+
+ +
+
+

オープンソースLLM

+

Meta（Llama）、Mistral 他

+
+
+
+

ソースコードや学習済みモデルが公開されており、誰でも無料で利用・改良できます。企業が自社サーバーで動かし、データを外部に出さずに使えるのが大きなメリットです。

+
+ 無料で利用可能 + カスタマイズ自在 + データが手元に残る +
+
+
+
+ +

+ 2026年のトレンドとして注目すべきは、「1つのモデルですべてを賄う」のではなく、用途に応じて複数のモデルを使い分ける「マルチモデル戦略」が主流になりつつあることです。長い文書の分析にはGemini、コードの生成にはClaude、計算問題にはGPT-5、というように適材適所で使い分けます。 +

+ +
+
+
+ +
+
+

ちょっと補足: LLMの学習コスト

+

+ GPT-4クラスのLLMを1から学習させるには、数千〜数万台のGPU（画像処理用の高性能チップ）を数ヶ月間フル稼働させる必要があり、学習コストだけで数千万〜数億ドルと推定されています。「AIは誰でも作れる」と言われますが、基盤モデル（Foundation Model）の学習には莫大な資金と設備が必要です。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

LLMの「できること」と「苦手なこと」

+
+ +

+ LLMは非常に強力ですが、万能ではありません。何が得意で、何が苦手なのかを正しく理解しておくことが、LLMを上手に活用するための第一歩です。 +

+ +
+ +
+
+ + 得意なこと +
+
    +
  • + + 文章の生成・要約 ── 長い報告書を3行にまとめる、メールの下書きを作るなど +
    • +
  • + + 翻訳 ── 多言語間の翻訳を、文脈を踏まえて自然に行う +
    • +
  • + + プログラミング支援 ── コードの生成、バグの発見、リファクタリング +
    • +
  • + + 質問応答 ── 学習済みの知識の範囲内で質問に回答する +
    • +
  • + + アイデア出し ── ブレインストーミングの壁打ち相手になる +
    • +
+
+ + +
+
+ + 苦手なこと +
+
    +
  • + + 最新情報の取得 ── 学習データ以降の出来事は知らない（リアルタイム検索は別機能） +
    • +
  • + + 正確な計算 ── 複雑な数式の計算はミスする。電卓の方が確実 +
    • +
  • + + 事実の正確性 ── もっともらしいが間違った情報を生成することがある（ハルシネーション） +
    • +
  • + + 物理世界の体験 ── 味、匂い、痛みなど、身体的な感覚は持っていない +
    • +
  • + + 「わからない」と認める ── 知らないことでも何か答えようとする傾向がある +
    • +
+
+
+ +
+
+
+ +
+
+

ハルシネーションとは？

+

+ LLMが事実と異なる内容を、あたかも正しいかのように自信を持って出力する現象を「ハルシネーション（幻覚）」と呼びます。LLMは「次に自然な言葉を予測する」仕組みなので、事実確認を行っているわけではありません。「もっともらしい文章 = 正しい文章」とは限らない、ということを常に意識しておく必要があります。 +

+
+
+
+
+ + + + + +
+
+
+ +
+

よくある誤解

+
+ +

+ LLMについて学び始めると、多くの人が同じところで引っかかります。ここでは、よくある3つの誤解を取り上げて、正しい理解に修正します。 +

+ +
+ +
+
+
+ +
+

誤解: 「LLMは人間のように"考えて"いる」

+
+
+
+
+ +
+
+

実際は:

+

+ LLMは「思考」しているのではなく、膨大なテキストから学んだ統計的パターンに基づいて、最も確率の高い次の単語を選んでいるだけです。人間のような意識や理解は持っていません。「考えているように見える」のは、学習データの規模が桁違いに大きいことと、Transformerの文脈理解能力が高いためです。出力の質が高いことと、「思考」していることは別物です。 +

+
+
+
+
+ + +
+
+
+ +
+

誤解: 「LLMはインターネットをリアルタイムで検索している」

+
+
+
+
+ +
+
+

実際は:

+

+ LLMの知識は学習時に読み込んだデータに基づいています。会話のたびにインターネットを検索しているわけではありません。学習データに含まれていない最新のニュースや出来事については答えられません。ただし、ChatGPTの「ブラウジング機能」やGeminiの「Google検索連携」のように、別途検索機能を組み合わせることで最新情報を取得できるようになっている製品もあります。LLMそのものの機能と、製品としての追加機能は区別して理解することが大切です。 +

+
+
+
+
+ + +
+
+
+ +
+

誤解: 「LLMは質問の文章をそのままコピーして返している」

+
+
+
+
+ +
+
+

実際は:

+

+ LLMは学習データをそのまま丸暗記しているわけではなく、言語のパターンや構造を「圧縮」して記憶しています。たとえるなら、料理のレシピを何千冊も読んだシェフが、レシピ本を見ずに新しい料理を作れるようなものです。LLMの出力はその場で新しく「生成」された文章であり、データベースから検索・コピーしたものではありません。だからこそ、同じ質問でも毎回少し違う回答が返ってくるのです。 +

+
+
+
+
+
+
+ + + + + +
+
+
+ +
+

まとめ ── 覚えておきたい3つのこと

+
+ +

+ 長い図解を読んでいただきありがとうございます。最後に、この記事で伝えたかったことを3つに絞ってまとめます。 +

+ +
+
+
+
01
+
+

LLMの正体は「次の単語予測マシン」

+

+ 膨大なテキストから「言葉の使い方」を学び、「次に来る最も自然な言葉」を予測し続ける。この単純な原理を、桁違いの規模で実行することで、翻訳・要約・プログラミング・対話まで、驚くほど多様な言語タスクをこなしています。 +

+
+
+
+ +
+
+
02
+
+

Transformerとattentionが鍵

+

+ LLMが「文脈を理解できる」のは、Transformer内部のAttention機構のおかげです。文中のすべての単語の関係性を同時に見渡し、「この言葉は前後のどの言葉と関係が深いか」を瞬時に判断します。これにより、同じ単語でも文脈に応じて異なる意味を正しく解釈できます。 +

+
+
+
+ +
+
+
03
+
+

強力だが万能ではない

+

+ LLMは「考えている」のではなく「予測している」。そのため、もっともらしいが間違った回答（ハルシネーション）を出すこともあります。LLMを上手に使うとは、その得意・不得意を理解した上で、得意な部分をフルに活用し、苦手な部分は人間が補うことです。 +

+
+
+
+
+ +
+ +

LLMは「道具」です。使いこなすのは、あなたです。

+

+ 次にChatGPTやClaudeを使うとき、「この裏側で、数千億のパラメータが文脈を読み取って、次の単語を選んでいるんだな」と想像してみてください。LLMの仕組みを知っているだけで、より的確な質問ができるようになり、より良い回答を引き出せるようになります。 +

+
+
+ + +
+ + + + +