feat: add full stage-2 multilingual support for 8 locales
Translate all 24 stage-2 chapters (frontend, backend, AI capabilities, assignments) to ja-jp, ko-kr, zh-tw, es-es, fr-fr, de-de, ar-sa, vi-vn. Update VitePress config with sidebar labels, nav links, and sidebar entries for each locale. Images reference zh-cn originals via absolute paths. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
sanbuphy
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,346 @@
|
||||
# AI マーケティングコピー SaaS 開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD（要件定義書）に基づき、独立開発者やコンテンツチーム向けの AI マーケティングコピー SaaS 製品をゼロから構築します。Supabase をバックエンドサービスとして、Stripe を決済システムとして使用し、要件分析からデプロイまでの全プロセスを完了します。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。これまでの章で、フロントエンドページの構築、バックエンドインターフェースの開発、データベース操作、決済統合などの個別スキルを学びました。このプロジェクトでは、それらすべてを統合し、実行可能な製品プロトタイプを納品します。
|
||||
|
||||
## 前提知識
|
||||
|
||||
本プロジェクトを開始する前に、以下の内容を習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェースの設計と開発（[インターフェースコードの記述](../../backend/ai-interface-code/)）
|
||||
- データベースの基礎と Supabase（[データベースから Supabase へ](../../backend/database-supabase/)）
|
||||
- 決済統合（[Stripe 決済システム](../../backend/stripe-payment/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリケーションのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践を完了すると、以下のことができるようになります：
|
||||
|
||||
1. 実際の PRD を読み解き、開発タスクリストを抽出する
|
||||
2. AI を活用して段階的にフロントエンドページとバックエンドインターフェースを生成する
|
||||
3. Supabase を使用してユーザー認証、データベース操作を実装する
|
||||
4. Stripe を統合して有料サブスクリプション機能を実装する
|
||||
5. 管理画面を構築し、エンドツーエンドの結合テストを完了する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
構築する製品は AI マーケティングコピー SaaS であり、3つのサブシステムで構成されます：
|
||||
|
||||
| サブシステム | 責務 |
|
||||
|--------|------|
|
||||
| **公式サイト** | 製品紹介、料金プラン、FAQ、登録コンバージョン |
|
||||
| **ユーザーワークスペース** | 製品情報の入力、コピー生成、履歴確認、プランのアップグレード |
|
||||
| **管理画面** | ユーザー管理、生成記録、決済データ、運用概要 |
|
||||
|
||||
バックエンドは Supabase でデータベースと認証機能を提供し、Stripe で決済を処理し、AI モデルでマーケティングコピーを生成します。
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件定義書は GitHub にあります： [PRD を確認](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/copywriting-platform-supabase/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、ページ、機能、認証、決済の範囲を明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'AI で3つのフロントエンドスケルトン（www / app / admin）を生成' },
|
||||
{ title: 'バックエンド統合', description: 'Supabase 認証、生成インターフェース、Stripe 決済' },
|
||||
{ title: '結合・デプロイ', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第1部：要件分析
|
||||
|
||||
### 1.1 PRD の読解
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- システムにはいくつの入口がありますか？それぞれどのページをカバーしていますか？
|
||||
- 各ページのコア機能は何ですか？
|
||||
- バックエンドにはどのモジュールとデータテーブルが含まれていますか？
|
||||
- 料金プラン、決済フロー、無料枠はどのように設計されていますか？
|
||||
- MVP の範囲は何ですか？初版で何を作り、何を作らないか？
|
||||
|
||||
::: warning
|
||||
上記の質問に明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確であることは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 システムアーキテクチャの確認
|
||||
|
||||
PRD に基づいてシステムの全体アーキテクチャを整理します：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["公式サイト"]
|
||||
prd --> app["ユーザーワークスペース"]
|
||||
prd --> admin["管理画面"]
|
||||
app --> auth["認証"]
|
||||
app --> gen["コピー生成タスク"]
|
||||
gen --> db["データベース"]
|
||||
billing["決済とプラン"] --> db
|
||||
admin --> analytics["ユーザー / 生成 / 決済ダッシュボード"]
|
||||
```
|
||||
|
||||
## 第2部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 フロントエンドページの生成
|
||||
|
||||
AI を使用して、まずすべてのページの基本構造とモックデータを生成します。
|
||||
|
||||
プロンプトの参考例：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、AI マーケティングコピー SaaS のフロントエンドスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. 3つの入口に分ける：www、app、admin
|
||||
2. 公式サイトには：ホーム、料金プラン、FAQ
|
||||
3. app には：ログイン、登録、生成ワークスペース、履歴、プランページ
|
||||
4. admin には：管理画面ホーム、ユーザー管理、生成記録、決済オーダー
|
||||
5. まずページ構造とモックデータのみを生成し、実際のインターフェースには接続しない
|
||||
6. モダンな SaaS のようなスタイルにし、授業のデモのような見た目にしない
|
||||
```
|
||||
|
||||
### 2.2 コアページの充実
|
||||
|
||||
スケルトンができたら、コピー生成ワークスペース（Dashboard）ページを重点的に充実させます：
|
||||
|
||||
```text
|
||||
/dashboard ページをさらに充実させてください。
|
||||
|
||||
これは AI マーケティングコピーのワークスペースです。
|
||||
|
||||
左側のフォームフィールド：
|
||||
- 製品名
|
||||
- 一言での紹介
|
||||
- ターゲットユーザー
|
||||
- 3つのセールスポイント
|
||||
- 配信チャネル（公式サイト、WeChat モーメンツ、小紅書、Douyin、メール）
|
||||
|
||||
右側の結果エリアの予約：
|
||||
- メインタイトル
|
||||
- サブタイトル
|
||||
- CTA
|
||||
- 3パターンの短いコピー
|
||||
- 長いコピー
|
||||
|
||||
まずモックデータでインタラクションを動作させる。
|
||||
|
||||
要件：
|
||||
- 「コピー生成」クリック後にローディング状態を表示
|
||||
- 結果エリアに空の状態をデザイン
|
||||
- レスポンシブレイアウトで、ワイド画面でもナロー画面でも正常に表示
|
||||
```
|
||||
|
||||
### 2.3 ページ構造の検証
|
||||
|
||||
各項目をチェック：
|
||||
|
||||
- [ ] 3つの入口のルーティングが独立しているか
|
||||
- [ ] ページ数が PRD と一致しているか
|
||||
- [ ] Dashboard のフォームと結果エリアのレイアウトが適切か
|
||||
- [ ] モックデータが基本的な UI の状態を表現しているか
|
||||
|
||||
### 行き詰まったら
|
||||
|
||||
フロントエンド構築の段階で行き詰まった場合は、以下の章を振り返ってください：
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [UI 設計仕様を参考にページとボタンを設計](../../frontend/multi-product-ui/)
|
||||
- [LLM と Skills でインターフェースを見栄えよくする](../../frontend/llm-skills-beautiful/)
|
||||
- [デザインプロトタイプからプロジェクトコードへ](../../frontend/design-to-code/)
|
||||
- [モダンコンポーネントライブラリでインターフェースをアップデート](../../frontend/modern-component-library/)
|
||||
|
||||
## 第3部：バックエンド統合
|
||||
|
||||
### 3.1 Supabase ログインの統合
|
||||
|
||||
```text
|
||||
私はプログラミング初心者です。ステップバイステップで Supabase のログイン統合を案内してください。
|
||||
|
||||
私のために以下を完了してください：
|
||||
1. プロジェクトに Supabase を統合
|
||||
2. 登録、ログイン、ログアウト機能を実装
|
||||
3. ログイン成功後に /dashboard にリダイレクト
|
||||
4. 未ログインユーザーが /dashboard、/billing、/admin にアクセスした場合、自動的に /login にリダイレクト
|
||||
5. profiles テーブルを作成
|
||||
6. ユーザー登録成功後、自動的に profiles テーブルにレコードを作成
|
||||
7. profiles テーブルには email、role、plan フィールドを含める
|
||||
|
||||
実装要件：
|
||||
- 各ステップでどのファイルを変更しているかを説明
|
||||
- 秘密鍵をハードコーディングしない
|
||||
- Supabase 管理画面で手動操作が必要な箇所は明確に記載
|
||||
- 完了後、登録とログインの確認方法を説明
|
||||
```
|
||||
|
||||
### 3.2 生成インターフェースとデータベースの統合
|
||||
|
||||
```text
|
||||
私はプログラミング初心者です。サイトのコア機能である「マーケティングコピーの生成と保存」を実装するのを手伝ってください。
|
||||
|
||||
目標とする効果：
|
||||
1. ユーザーが /dashboard でフォームに入力し、「コピー生成」をクリック
|
||||
2. バックエンドが受け取る：製品名、紹介、ターゲットユーザー、セールスポイント、配信チャネル
|
||||
3. バックエンドがモデルを呼び出して結果を生成
|
||||
4. ページに生成結果を表示
|
||||
5. 入力と出力の両方をデータベースに保存
|
||||
6. ユーザーが次回アクセス時に履歴を確認可能
|
||||
|
||||
私のために以下を完了してください：
|
||||
- 生成インターフェース /api/generate を作成
|
||||
- generations テーブルを作成
|
||||
- 入力と出力のフィールドを設計
|
||||
- Dashboard ページで現在のユーザーの履歴を読み込む
|
||||
|
||||
ユーザーエクスペリエンス：
|
||||
- ボタンのローディング状態
|
||||
- 生成失敗時のエラーメッセージ
|
||||
- 履歴がない場合の空の状態
|
||||
|
||||
完了後、以下を説明してください：
|
||||
- フロントエンドページファイルの場所
|
||||
- バックエンドインターフェースファイルの場所
|
||||
- データベースへの書き込みロジックの場所
|
||||
- 完全な生成チェーンのテスト方法
|
||||
```
|
||||
|
||||
### 3.3 Stripe 決済の統合
|
||||
|
||||
```text
|
||||
私はプログラミング初心者です。LaunchKit に最小限の Stripe 決済を追加するのを手伝ってください。
|
||||
|
||||
複雑なシステムは不要で、まず最基本的な決済フローを動作させます。
|
||||
|
||||
私のために以下を完了してください：
|
||||
1. /billing ページに free と pro の2つのプランを表示
|
||||
2. ユーザーがアップグレードをクリックした後、Stripe Checkout にリダイレクト
|
||||
3. 決済成功後にサイトに戻る
|
||||
4. 決済結果を subscriptions テーブルに保存
|
||||
5. profile.plan フィールドを同期的に更新
|
||||
6. free ユーザーは1日3回まで生成可能、pro ユーザーは無制限
|
||||
|
||||
実装原則：
|
||||
- まずメインフローを動作させ、複雑なエッジケースは後回し
|
||||
- Stripe 管理画面での設定が必要な箇所は明確に記載
|
||||
- 完了後、完全な決済フローのテスト方法を説明
|
||||
```
|
||||
|
||||
### 3.4 管理画面の構築
|
||||
|
||||
```text
|
||||
私はプログラミング初心者です。シンプルで使いやすい管理画面を作成してください。
|
||||
|
||||
管理者のみアクセス可能。
|
||||
|
||||
私のために以下を完了してください：
|
||||
1. role = admin のユーザーのみ /admin にアクセス可能
|
||||
2. 管理画面には3つのタブを含める：ユーザーリスト、生成記録、サブスクリプション状況
|
||||
3. ユーザーリストの表示：email、plan、作成日時
|
||||
4. 生成記録の表示：ユーザー、製品名、チャネル、作成日時
|
||||
5. サブスクリプション状況の表示：ユーザー、プラン、決済ステータス
|
||||
|
||||
要件：
|
||||
- インターフェースはシンプルで見やすく
|
||||
- 既存のコンポーネントライブラリのテーブル、タブ、バッジを使用
|
||||
- 完了後、アカウントを管理者に設定する方法を説明
|
||||
```
|
||||
|
||||
### 行き詰まったら
|
||||
|
||||
バックエンド開発の段階で行き詰まった場合は、以下の章を振り返ってください：
|
||||
|
||||
- [データベースから Supabase へ](../../backend/database-supabase/)
|
||||
- [大規模言語モデルによるインターフェースコードとインターフェース文書の作成支援](../../backend/ai-interface-code/)
|
||||
- [Stripe などの決済システムの統合方法](../../backend/stripe-payment/)
|
||||
|
||||
## 第4部：結合テストとデプロイ
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証してください：
|
||||
|
||||
- 登録 → ログイン → コピー生成 → 履歴確認 → プランのアップグレード
|
||||
- 管理者のログイン → ユーザーデータの確認 → 生成記録の確認 → 決済ステータスの確認
|
||||
|
||||
デプロイ前チェック：
|
||||
|
||||
```text
|
||||
私はプログラミング初心者です。プロジェクトがデプロイ可能かどうかを確認するのを手伝ってください。
|
||||
|
||||
チェックのポイント：
|
||||
- 環境変数は完全か
|
||||
- ログインのコールバックアドレスは正しいか
|
||||
- Stripe 決済のコールバックアドレスは正しいか
|
||||
- ページにローディング、空の状態、エラーメッセージが欠落していないか
|
||||
- README に起動説明とデプロイ説明が含まれているか
|
||||
|
||||
私のために以下をしてください：
|
||||
1. 優先度順に修正項目をリストアップ
|
||||
2. どれを先に修正すべきかをマーク
|
||||
3. 修正後のデプロイ手順を説明
|
||||
```
|
||||
|
||||
### 4.2 デプロイ
|
||||
|
||||
プロジェクトをパブリックネットワーク環境にデプロイします。デプロイのチュートリアルはこちらを参照してください：[Git と GitHub ワークフロー](../../backend/git-workflow/)、[Web アプリケーションのデプロイ方法](../../backend/zeabur-deployment/)。
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出してください：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリのリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（ホーム、Dashboard、Billing、Admin）
|
||||
- [ ] 60秒のデモ動画（登録 → 生成 → 決済 → 管理画面を網羅）
|
||||
|
||||
README には少なくとも以下を含めてください：プロジェクト概要、コアページの説明、技術スタック、ローカル起動手順、環境変数リスト。
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| 製品の完成度 | ホーム、ログイン、Dashboard、Billing、Admin にすべてアクセス可能 | ホームのコピーとビジュアルスタイルが本物の SaaS のように見える |
|
||||
| ビジネス完了 | 登録 → ログイン → 生成 → 履歴確認が動作する | 無料 / Pro の権限差が明確に確認できる |
|
||||
| データの正確性 | 生成結果と決済ステータスがデータベースに書き込まれる | 明確なエラーメッセージ、空の状態、ローディングがある |
|
||||
| 権限とセキュリティ | 未ログインで保護されたページにアクセスできず、一般ユーザーは Admin に入れない | 基本的な入力バリデーションとサーバーサイド認証がある |
|
||||
| エンジニアリング品質 | プロジェクトがローカルで起動可能で、パブリックネットワークにもデプロイ可能 | README が明確で、デモ動画の構造が完全 |
|
||||
|
||||
::: tip
|
||||
タスクが大きすぎると感じた場合は、この原則を覚えておいてください：**まず「動くこと」を確保してから、「美しくすること」を追求してください。**
|
||||
:::
|
||||
|
||||
## 提出前チェック
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">提出前の最終確認</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> ホーム、ログイン、Dashboard、Billing、Admin がすべて完了している</label></li>
|
||||
<li><label><input type="checkbox" disabled /> ユーザーが登録、ログイン、ログアウトできる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 生成結果が実際にデータベースに書き込まれる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 決済のメインフローが動作する</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 管理者がユーザー、生成記録、決済ステータスを確認できる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> プロジェクトがパブリックネットワークにデプロイされている</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [UI 設計仕様を参考にページとボタンを設計](../../frontend/multi-product-ui/)
|
||||
- [LLM と Skills でインターフェースを見栄えよくする](../../frontend/llm-skills-beautiful/)
|
||||
- [デザインプロトタイプからプロジェクトコードへ](../../frontend/design-to-code/)
|
||||
- [モダンコンポーネントライブラリでインターフェースをアップデート](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase へ](../../backend/database-supabase/)
|
||||
- [大規模言語モデルによるインターフェースコードとインターフェース文書の作成支援](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリケーションのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
- [Stripe などの決済システムの統合方法](../../backend/stripe-payment/)
|
||||
@@ -0,0 +1,208 @@
|
||||
# Dify 型エージェントプラットフォーム開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD に基づいて、Dify のコア体験を模倣したエージェントプラットフォームを一から完成させます。ユーザーコンソール、管理バックエンド、プラットフォームバックエンドを構築し、エージェント管理、対話、ログ、ナレッジベースなどのコア機能を実装します。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。これまでの単一ページや単一機能のプロジェクトとは異なり、このプロジェクトでは「プラットフォーム感」のある AI 製品を構築する必要があります。マルチロール、マルチモジュール、データ永続化、モデル呼び出しパイプラインを含みます。
|
||||
|
||||
## 前提知識
|
||||
|
||||
このプロジェクトを始める前に、以下の内容をすでに習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェース設計と開発（[インターフェースコード作成](../../backend/ai-interface-code/)）
|
||||
- データベース基礎と Supabase（[データベースから Supabase まで](../../backend/database-supabase/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践完了後、以下のことができるようになります：
|
||||
|
||||
1. 実際の PRD を読み、開発タスクリストを抽出する
|
||||
2. エージェントプラットフォームのページアーキテクチャとデータモデルを設計する
|
||||
3. エージェント作成、対話、ログ記録の完全なパイプラインを実装する
|
||||
4. AI を活用してプラットフォーム型製品の開発を完了する
|
||||
5. エンドツーエンドの結合テストを完了し、デモ可能な AI プラットフォームプロトタイプを納品する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
あなたが構築する製品は、Dify 型エージェントプラットフォームです。2 つのサブシステムを含みます：
|
||||
|
||||
| サブシステム | 責務 |
|
||||
|--------|------|
|
||||
| **ユーザーコンソール** | エージェント作成、Prompt 設定、対話開始、ログ確認、ナレッジベース管理 |
|
||||
| **管理バックエンド** | ユーザーデータ、プラットフォームリソース使用状況、呼び出し統計の確認 |
|
||||
|
||||
バックエンドは以下のコア機能をサポートする必要があります：エージェント管理、セッション管理、メッセージ保存、モデル呼び出し、呼び出しログ記録、ナレッジベース接続。
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件文書は GitHub にあります： [PRD を表示](https://github.com/datawhalechina/easy-vibe/blob/main/docs/ja-jp/stage-2/assignments/custom-dify-agent-platform/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、ページ、機能境界、認証、データモデルを明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'AI でユーザーコンソールと管理バックエンドのスケルトンを生成' },
|
||||
{ title: '反復開発', description: 'モジュールごとにエージェント、対話、ログ、ナレッジベースを追加' },
|
||||
{ title: '結合とリリース', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第 1 部：要件分析
|
||||
|
||||
### 1.1 PRD を読む
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- エージェント、セッション、ログ、ナレッジベースのうち、どれを MVP に入れますか？
|
||||
- ページとルートのリストは確定していますか？
|
||||
- モデル呼び出しとログ記録の境界は何ですか？
|
||||
- マルチテナントや複雑なワークフローはまず実装しませんか？
|
||||
|
||||
::: warning
|
||||
以上の質問に対する明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確なのは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 システムアーキテクチャの確認
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> app["ユーザーコンソール"]
|
||||
prd --> admin["管理バックエンド"]
|
||||
app --> auth["認証"]
|
||||
app --> agent["エージェント設定"]
|
||||
app --> chat["セッション対話"]
|
||||
chat --> llm["モデル呼び出し"]
|
||||
chat --> db["データベース"]
|
||||
app --> kb["ナレッジベース接続"]
|
||||
admin --> logs["呼び出しログとプラットフォーム概要"]
|
||||
logs --> db
|
||||
```
|
||||
|
||||
## 第 2 部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 フロントエンドページの生成
|
||||
|
||||
プロンプト参考：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、Dify 型エージェントプラットフォームのフロントエンドスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. ユーザー側には以下を含む：ログイン、エージェントリスト、エージェント設定、対話ページ、ログページ、ナレッジベースページ
|
||||
2. 管理側には以下を含む：管理ホーム、ユーザー概要、リソース使用概要
|
||||
3. まずページ構造とモックデータのみを生成し、実際のインターフェースには接続しない
|
||||
4. モダンな AI プラットフォームのようなスタイルにする
|
||||
```
|
||||
|
||||
### 2.2 プロジェクト構造の検証
|
||||
|
||||
項目ごとにチェック：
|
||||
|
||||
- [ ] ユーザーコンソールと管理バックエンドのエントリが分離されている
|
||||
- [ ] エージェントリスト、設定、対話、ログ、ナレッジベースページが完全
|
||||
- [ ] 管理バックエンドのホーム、ユーザー概要ページがアクセス可能
|
||||
- [ ] モックデータで基本的な UI ステータスが表示されている
|
||||
|
||||
## 第 3 部：反復開発
|
||||
|
||||
### 3.1 モジュールごとに進める
|
||||
|
||||
スケルトンをベースに、以下の順序でモジュールごとに機能を追加：
|
||||
|
||||
1. **認証**：登録、ログイン、ロール区分
|
||||
2. **エージェント管理**：作成、編集、削除、Prompt 設定
|
||||
3. **対話機能**：セッション作成、メッセージ送受信、モデル呼び出し
|
||||
4. **ログ記録**：所要時間、トークン使用量、エラー記録
|
||||
5. **ナレッジベース接続**（ボーナス）：ドキュメントアップロード、検索、結果注入
|
||||
6. **管理バックエンド**：ユーザーデータ、リソース使用状況、呼び出し統計
|
||||
|
||||
各モジュール完了後、以下の表で自己チェック：
|
||||
|
||||
| チェック項目 | 検証方法 |
|
||||
|--------|----------|
|
||||
| ページ整合性 | ページ数、機能が PRD に適合しているか |
|
||||
| インターフェースクロージャ | agents、chat、logs、knowledge のインターフェースが完全か |
|
||||
| 権限分離 | ユーザーが自分のエージェントとセッションのみを管理できるか |
|
||||
| データ整合性 | messages、logs、documents のデータが一致しているか |
|
||||
| デモ可能性 | 「エージェント作成 → 対話 → ログ確認」の完全なフローがデモできるか |
|
||||
|
||||
### 3.2 ナレッジベース接続（ボーナス）
|
||||
|
||||
ナレッジベース機能を追加したい場合、各エージェントに「ナレッジベーススイッチ」を追加できます：
|
||||
|
||||
- オンにした場合、まずナレッジ断片を検索し、ユーザーの質問と一緒にモデルに送信
|
||||
- オフにした場合、通常の対話モードで応答
|
||||
|
||||
第 1 版では複雑な RAG を追求せず、「検索結果が可視で、呼び出しパイプラインが説明可能」であれば十分です。
|
||||
|
||||
## 第 4 部：結合テストとリリース
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証：
|
||||
|
||||
- 登録 → エージェント作成 → Prompt 設定 → 対話開始 → ログ確認
|
||||
- 管理者ログイン → ユーザーデータ確認 → 呼び出し統計確認
|
||||
|
||||
デプロイ前チェック：
|
||||
|
||||
- [ ] すべてのコアインターフェースにログインチェックがある
|
||||
- [ ] エージェントの所有権限チェックが通っている
|
||||
- [ ] セッション記録、ログ記録が実際にデータベースに保存されている
|
||||
- [ ] モデルキーが環境変数を使用しており、ハードコードされていない
|
||||
- [ ] エラーがフロントエンドで確認でき、コンソールのみに出力されていない
|
||||
|
||||
### 4.2 デプロイ
|
||||
|
||||
プロジェクトをパブリックネットワークにデプロイ。デプロイチュートリアル参照：[Git と GitHub ワークフロー](../../backend/git-workflow/)、[Web アプリのデプロイ方法](../../backend/zeabur-deployment/)。
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出する必要があります：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（エージェント管理ページ、対話ページ、ログページ、管理ホーム）
|
||||
- [ ] 60 秒のデモ動画（エージェント作成 → 対話 → ログ確認をカバー）
|
||||
|
||||
README には少なくとも以下を含む：プロジェクト概要、アーキテクチャ説明、技術スタック、ローカル起動手順、環境変数リスト、インターフェース説明。
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| プラットフォーム完成度 | agents / chat / logs の 3 ページが利用可能 | 明確なナビゲーションと統一されたデザイン言語がある |
|
||||
| ビジネスクロージャ | エージェントを作成して実際に対話できる | マルチエージェント切り替えと履歴セッションをサポート |
|
||||
| データとトラッキング | メッセージと呼び出しログがクエリ可能 | トークン / 所要時間の統計ダッシュボードがある |
|
||||
| 権限セキュリティ | ログインユーザーのみがコアインターフェースにアクセス可能 | リソース所有権の検証が充実 |
|
||||
| エンジニアリング納品 | デプロイ可能、デモ可能、README が明確 | ナレッジベースを接続し、検索結果を説明可能 |
|
||||
|
||||
## 提出前チェック
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">提出前の最終確認</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> ログイン後、エージェント管理、対話、ログページにアクセス可能</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 少なくとも 1 つのエージェントを作成し、対話に成功する</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 各ラウンドのQ&Aがデータベースで確認できる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 呼び出し失敗時にフロントエンドでエラー情報が表示され、ログが記録されている</label></li>
|
||||
<li><label><input type="checkbox" disabled /> プロジェクトがデプロイされ、README とデモ動画が揃っている</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [モダンコンポーネントライブラリでインターフェースを更新](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase まで](../../backend/database-supabase/)
|
||||
- [大規模モデルによるインターフェースコードとドキュメント作成](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,306 @@
|
||||
# オンライン試験・管理システム開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD（要件定義書）に基づき、オンライン試験・管理システムをゼロから構築します。このプロジェクトの特徴は、複数のロール（学生と管理者）が存在し、各ロールによって表示されるページや実行可能な操作が異なる点にあります。Express を使用してバックエンドを構築し、試験業務の完全なフローを実装します。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。マルチロール権限システムは実際の業務でも非常に一般的であり、このパターンを習得すれば、教育、SaaS、管理画面など、あらゆる業務シナリオに対応できるようになります。
|
||||
|
||||
## 前提知識
|
||||
|
||||
本プロジェクトを開始する前に、以下の内容を習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェースの設計と開発（[インターフェースコードの記述](../../backend/ai-interface-code/)）
|
||||
- データベースの基礎と Supabase（[データベースから Supabase へ](../../backend/database-supabase/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリケーションのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践を完了すると、以下のことができるようになります：
|
||||
|
||||
1. 実際の PRD を読み解き、開発タスクリストを抽出する
|
||||
2. マルチロールシステムの権限制御とページルーティングを設計する
|
||||
3. Express を使用して完全なバックエンド API を実装する
|
||||
4. 試験、提出、自動採点の業務フローを実装する
|
||||
5. エンドツーエンドの結合テストを完了し、デモ可能な業務システムプロトタイプを納品する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
構築する製品は、オンライン試験・管理システムであり、3つのサブシステムで構成されます：
|
||||
|
||||
| サブシステム | 責務 |
|
||||
|--------|------|
|
||||
| **公式サイト** | プラットフォーム紹介、ログイン入口 |
|
||||
| **学生画面** | 試験一覧、解答、提出、成績確認 |
|
||||
| **管理画面** | 問題バンク管理、試験管理、提出記録、成績統計 |
|
||||
|
||||
バックエンドは Express を使用し、以下をサポートする必要があります：ログイン認証、ロール権限、試験と問題バンクの管理、提出フローと自動採点、成績と統計管理。
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件定義書は GitHub にあります： [PRD を確認](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/exam-management-express/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、ロール、ページ、試験フロー、データモデルを明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'AI で学生画面と管理画面のスケルトンを生成' },
|
||||
{ title: 'バックエンド開発', description: 'Express でログイン、試験、提出、採点を実装' },
|
||||
{ title: '結合・デプロイ', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第1部：要件分析
|
||||
|
||||
### 1.1 PRD の読解
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- システムにはいくつのロールがありますか？それぞれ何ができますか？
|
||||
- ページ一覧は完全ですか？学生画面と管理画面にそれぞれどのページがありますか？
|
||||
- どの問題形式をサポートしていますか？各形式の採点ロジックは何ですか？
|
||||
- 試験の完全なフローは何ですか？（公開 → 開始 → 解答 → 提出 → 採点 → 成績確認）
|
||||
|
||||
::: warning
|
||||
上記の質問に明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確であることは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 システムアーキテクチャの確認
|
||||
|
||||
PRD に基づいてシステムの全体アーキテクチャを整理します：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["公式サイト"]
|
||||
prd --> student["学生画面"]
|
||||
prd --> admin["管理画面"]
|
||||
student --> auth["認証"]
|
||||
student --> exam["試験と解答"]
|
||||
exam --> db["データベース"]
|
||||
admin --> question["問題バンク管理"]
|
||||
admin --> submission["提出記録と成績統計"]
|
||||
question --> db
|
||||
submission --> db
|
||||
```
|
||||
|
||||
## 第2部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 フロントエンドページの生成
|
||||
|
||||
プロンプトの参考例：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、オンライン試験・管理システムのフロントエンドスケルトンを生成してください。
|
||||
|
||||
技術スタックの要件：
|
||||
- Next.js App Router
|
||||
- TypeScript
|
||||
- Tailwind CSS
|
||||
- shadcn/ui
|
||||
|
||||
ページ一覧：
|
||||
1. ホーム /
|
||||
2. ログインページ /login
|
||||
3. 学生試験一覧ページ /student/exams
|
||||
4. 学生解答ページ /student/exams/[id]
|
||||
5. 学生成績ページ /student/history
|
||||
6. 管理画面ホーム /admin
|
||||
7. 試験管理ページ /admin/exams
|
||||
8. 問題バンク管理ページ /admin/questions
|
||||
9. 提出記録ページ /admin/submissions
|
||||
|
||||
要件：
|
||||
- 学生画面は見やすく、集中して解答しやすいデザインにする
|
||||
- 管理画面はサイドバー＋トップバーのレイアウトを使用
|
||||
- まずモックデータを使用し、実際のインターフェースには接続しない
|
||||
- デスクトップとモバイルの基本的な使いやすさに配慮する
|
||||
```
|
||||
|
||||
### 2.2 学生解答ページの充実
|
||||
|
||||
解答ページは学生画面のコアページです。以下を重点的に実装してください：
|
||||
|
||||
```text
|
||||
学生の解答ページをさらに充実させてください。
|
||||
|
||||
これはオンライン試験システムの解答ページで、以下を含める必要があります：
|
||||
- 上部に試験タイトル、カウントダウン、解答済み問題数を表示
|
||||
- 中央に問題文と選択肢を表示
|
||||
- 単一選択、正誤判定、記述の3つの問題形式をサポート
|
||||
- 左側または上部に解答カードを配置し、各問題の解答状況を表示
|
||||
- 提出前に確認ダイアログを表示
|
||||
|
||||
まずモックデータでインタラクションを実装し、実際のインターフェースには接続しない。
|
||||
|
||||
要件：
|
||||
- インターフェースはシンプルにし、管理画面のテーブルページのような見た目にしない
|
||||
- カウントダウンは目立つようにするが、過度なプレッシャーを与えない
|
||||
- 空の状態とローディング状態を含める
|
||||
```
|
||||
|
||||
### 2.3 管理画面の充実
|
||||
|
||||
管理画面の初版は3つのコア領域に焦点を当てます：
|
||||
|
||||
- **試験管理**：試験の作成、時間の設定、公開ステータス
|
||||
- **問題バンク管理**：問題の追加、編集、問題形式によるフィルタリング
|
||||
- **提出記録**：学生の提出、スコア、時間の確認
|
||||
|
||||
### 2.4 ページ構造の検証
|
||||
|
||||
各項目をチェック：
|
||||
|
||||
- [ ] 学生画面と管理画面の入口が分離されているか
|
||||
- [ ] ログインページ、試験一覧、解答ページ、成績ページが完全か
|
||||
- [ ] 管理画面の問題バンク、試験管理、提出記録ページにアクセスできるか
|
||||
- [ ] 学生画面と管理画面のデザインに明確な差異があるか
|
||||
|
||||
### 行き詰まったら
|
||||
|
||||
フロントエンド構築の段階で行き詰まった場合は、以下の章を振り返ってください：
|
||||
|
||||
- [データベースから Supabase へ](../../backend/database-supabase/)
|
||||
- [アプリケーションバックエンドインターフェースの設計と開発](../../backend/ai-interface-code/)
|
||||
- [モダンコンポーネントライブラリでインターフェースをアップデート](../../frontend/modern-component-library/)
|
||||
|
||||
## 第3部：バックエンド開発
|
||||
|
||||
### 3.1 ログインと権限制御
|
||||
|
||||
```text
|
||||
私はプログラミング初心者です。オンライン試験システムのログインと権限制御を実装するのを手伝ってください。
|
||||
|
||||
バックエンドには Express を使用します。
|
||||
|
||||
目標：
|
||||
1. 学生と管理者の両方がログインできる
|
||||
2. ログイン後にユーザーロールを返す
|
||||
3. 学生は /student/* 関連のインターフェースにのみアクセスできる
|
||||
4. 管理者は /admin/* 関連のインターフェースにのみアクセスできる
|
||||
5. 未ログインユーザーが保護されたページにアクセスした場合、/login にリダイレクトする
|
||||
|
||||
実装要件：
|
||||
- 明確なディレクトリ構造の提案を提供する
|
||||
- ミドルウェアの責務を明確に説明する
|
||||
- 環境変数に関わる部分はハードコーディングしない
|
||||
- 完了後、権限が正しく機能しているかの確認方法を説明する
|
||||
```
|
||||
|
||||
### 3.2 試験と問題バンク管理インターフェース
|
||||
|
||||
以下のモジュールごとに実装することをお勧めします：
|
||||
|
||||
| モジュール | 推奨インターフェース |
|
||||
|------|----------|
|
||||
| 試験管理 | `GET /api/exams`、`POST /api/admin/exams`、`PATCH /api/admin/exams/:id` |
|
||||
| 問題バンク管理 | `GET /api/admin/questions`、`POST /api/admin/questions` |
|
||||
| 試験開始 | `POST /api/submissions/start` |
|
||||
| 答案提出 | `POST /api/submissions/:id/submit` |
|
||||
| 成績記録 | `GET /api/student/history`、`GET /api/admin/submissions` |
|
||||
|
||||
プロンプトの参考例：
|
||||
|
||||
```text
|
||||
オンライン試験システムの Express API を設計・実装してください。
|
||||
|
||||
機能範囲：
|
||||
- 管理者が試験を作成
|
||||
- 管理者が問題バンクを管理
|
||||
- 学生が公開済みの試験を閲覧
|
||||
- 学生が試験を開始し、submission を作成
|
||||
- 学生が答案を提出した後、単一選択問題と正誤判定問題を自動採点
|
||||
- 記述問題はまず「要レビュー」としてマーク
|
||||
- 学生が自分の過去の成績を閲覧
|
||||
- 管理者がすべての提出記録を閲覧
|
||||
|
||||
要件：
|
||||
- インターフェース名は明確に
|
||||
- 統一された JSON 構造を返す
|
||||
- コード内で controller、service、middleware、db 層を区別する
|
||||
- 各インターフェースのテスト方法を説明する
|
||||
```
|
||||
|
||||
### 3.3 採点ロジック
|
||||
|
||||
採点ロジックは試験システムのコアとなるビジネスルールです：
|
||||
|
||||
- **単一選択問題**：ユーザーの回答が正解と一致すれば得点
|
||||
- **正誤判定問題**：同様に自動採点可能
|
||||
- **記述問題**：初版では回答のみを保存し、スコアは空欄、ステータスを `reviewed = false` とする
|
||||
|
||||
::: tip ボーナス項目
|
||||
AI 機能を追加したい場合は、管理者が「トピック + 難易度」を入力すると、モデルが候補問題を生成し、それを人工でレビュー後に問題バンクに登録する、という仕組みも可能です。ただし、これはボーナス項目であり必須ではありません。
|
||||
:::
|
||||
|
||||
## 第4部：結合テストとデプロイ
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証してください：
|
||||
|
||||
- 学生のログイン → 試験一覧の確認 → 解答開始 → 提出 → 成績確認
|
||||
- 管理者のログイン → 試験の作成 → 問題の追加 → 公開 → 提出記録の確認
|
||||
|
||||
### 4.2 デプロイ
|
||||
|
||||
- フロントエンドを Vercel / Zeabur にデプロイ
|
||||
- Express API を Zeabur / Railway / Render にデプロイ
|
||||
- データベースは Supabase Postgres またはマネージド PostgreSQL を使用
|
||||
|
||||
デプロイ前のチェック：
|
||||
|
||||
- [ ] 環境変数は揃っているか
|
||||
- [ ] フロントエンドとバックエンドの API アドレスは正しいか
|
||||
- [ ] 本番環境でログイン状態は正常に機能するか
|
||||
- [ ] 管理者アカウントで管理画面に実際にアクセスできるか
|
||||
- [ ] README に起動、デプロイ、テストの説明が含まれているか
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出してください：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリのリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（ホーム、学生試験一覧、解答ページ、管理画面）
|
||||
- [ ] 60秒のデモ動画（学生の解答フローと管理者の管理フローを網羅）
|
||||
|
||||
README には少なくとも以下を含めてください：プロジェクト概要、コアページの説明、技術スタック、ローカル起動手順、環境変数リスト。
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| ページの完全性 | 学生画面と管理画面の主要ページにアクセス可能 | ページのデザインが統一され、モバイルでも基本的に利用可能 |
|
||||
| ビジネス完了 | 学生がログイン、試験参加、提出、成績確認が可能 | 管理者が試験の作成から公開まで完全に実行可能 |
|
||||
| データの正確性 | 提出した回答がデータベースに書き込まれ、客観問題が自動採点される | 記述問題が手動レビューまたは AI 支援をサポート |
|
||||
| 権限制御 | 学生と管理者のアクセス境界が明確 | サーバーサイドのインターフェースにもロール検証がある |
|
||||
| エンジニアリング品質 | プロジェクトが実行可能、デプロイ可能、README が明確 | デモ動画とテスト説明がある |
|
||||
|
||||
## 提出前チェック
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">提出前の最終確認</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> ホーム、ログイン、学生画面、管理画面のページがすべて完了している</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 学生が正常に試験を開始し、回答を提出できる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 管理者が試験を作成し、提出記録を確認できる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 客観問題のスコアが自動計算され、データベースに書き込まれる</label></li>
|
||||
<li><label><input type="checkbox" disabled /> 学生と管理者の権限境界が検証済み</label></li>
|
||||
<li><label><input type="checkbox" disabled /> プロジェクトがデプロイされている、または完全なローカル実行説明がある</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [モダンコンポーネントライブラリでインターフェースをアップデート](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase へ](../../backend/database-supabase/)
|
||||
- [大規模言語モデルによるインターフェースコードとインターフェース文書の作成支援](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリケーションのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,211 @@
|
||||
# モダン AI 画像生成 SaaS 開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD（要件定義書）に基づき、Midjourney の体験を参考にした AI 画像生成 SaaS 製品をゼロから構築します。要件分析、プロジェクト分割、反復開発、結合テストとデプロイまでの全プロセスを経験します。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。これまでの章で、フロントエンドページ設計、バックエンドインターフェース開発、データベース操作、決済統合などの個別スキルを学びました。このプロジェクトでは、それらすべてを統合し、実行可能な製品プロトタイプを納品します。
|
||||
|
||||
## 前提知識
|
||||
|
||||
本プロジェクトを開始する前に、以下の内容を習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェースの設計と開発（[インターフェースコードの記述](../../backend/ai-interface-code/)）
|
||||
- データベースの基礎と Supabase（[データベースから Supabase へ](../../backend/database-supabase/)）
|
||||
- 決済統合（[Stripe 決済システム](../../backend/stripe-payment/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリケーションのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践を完了すると、以下のことができるようになります：
|
||||
|
||||
1. 実際の PRD を読み解き、開発タスクリストを抽出する
|
||||
2. PRD に基づいてモジュールを分割し、段階的な推進計画を策定する
|
||||
3. AI を活用してフロントエンドスケルトンの構築とバックエンドインターフェース開発を完了する
|
||||
4. 各モジュールを検証し、反復的に最適化する
|
||||
5. エンドツーエンドの結合テストを完了し、プロジェクトを「動く」状態から「納品可能」な状態に引き上げる
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
構築する製品は、モダンな AI 画像生成 SaaS プラットフォームであり、3つのサブシステムで構成されます：
|
||||
|
||||
| サブシステム | 責務 |
|
||||
|--------|------|
|
||||
| **公式サイト** | 製品紹介、料金プラン、FAQ、登録コンバージョン |
|
||||
| **ユーザーワークスペース** | Prompt 入力、画像生成、ギャラリー、クレジット、プラン、コミュニティ交流 |
|
||||
| **管理画面** | ユーザー管理、タスク管理、決済管理、コンテンツ審査、SaaS 指標、システムモニタリング |
|
||||
|
||||
バックエンドは以下のコア機能をサポートする必要があります：ユーザー認証、画像生成タスク、OSS オブジェクトストレージ、クレジットとプラン決済、画像ソーシャルインタラクション、運用データモニタリング。
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件定義書は GitHub にあります： [PRD を確認](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/modern-landing-page/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、ページ、モジュール、データモデルと境界を抽出' },
|
||||
{ title: 'スケルトン構築', description: 'AI で3つのフロントエンドスケルトン（www / app / admin）を生成' },
|
||||
{ title: '反復開発', description: 'モジュールごとにインターフェース、権限、決済、モニタリングを追加' },
|
||||
{ title: '結合・デプロイ', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第1部：要件分析
|
||||
|
||||
### 1.1 PRD の読解
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- システムにはいくつの入口がありますか？それぞれどのページをカバーしていますか？
|
||||
- 各ページのコア機能は何ですか？
|
||||
- バックエンドにはどのモジュールとデータベーステーブルが含まれていますか？
|
||||
- MVP の範囲は何ですか？初版で何を作り、何を作らないか？
|
||||
|
||||
::: warning
|
||||
上記の質問に明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確であることは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 システムアーキテクチャの確認
|
||||
|
||||
PRD の記述に基づいて、システムの全体アーキテクチャを整理します：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["公式サイト"]
|
||||
prd --> app["ユーザーワークスペース"]
|
||||
prd --> admin["管理画面"]
|
||||
app --> auth["認証"]
|
||||
app --> gen["画像生成タスク"]
|
||||
gen --> oss["OSS オブジェクトストレージ"]
|
||||
gen --> db["データベース"]
|
||||
billing["決済とプラン"] --> db
|
||||
social["シェア / いいね / コメント / 転送"] --> db
|
||||
admin --> analytics["SaaS 指標ダッシュボード"]
|
||||
admin --> observability["API / DB / Provider モニタリング"]
|
||||
```
|
||||
|
||||
自分の言葉でアーキテクチャ図を描き直し、システムの理解が完全であることを確認することをお勧めします。
|
||||
|
||||
## 第2部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 フロントエンドページの生成
|
||||
|
||||
AI を使用して、まずすべてのページの基本構造とモックデータを生成します。このステップの目標は、情報アーキテクチャとルーティングを構築することであり、実際のインターフェースに接続する必要はありません。
|
||||
|
||||
プロンプトの参考例：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、モダンな AI 画像生成 SaaS のフロントエンドスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. 3つの入口に分ける：www、app、admin
|
||||
2. 公式サイトには：ホーム、料金プラン、FAQ
|
||||
3. app には：ログイン、登録、生成ワークスペース、ギャラリー、プラン、クレジット、コミュニティ、作品詳細、個人センター
|
||||
4. admin には：管理画面ホーム、ユーザー管理、タスク管理、コンテンツ管理、プラン管理、決済オーダー、運用設定、SaaS 指標、システムモニタリング
|
||||
5. まずページ構造とモックデータのみを生成し、実際のインターフェースには接続しない
|
||||
6. Midjourney を参考に、シンプルでモダン、製品感のあるスタイルにする
|
||||
```
|
||||
|
||||
### 2.2 ページ構造の検証
|
||||
|
||||
スケルトン生成後、各項目をチェック：
|
||||
|
||||
- [ ] 3つの入口のルーティングが独立しているか（`/`、`/app`、`/admin`）
|
||||
- [ ] ページ数が PRD と一致しているか
|
||||
- [ ] 各ページが正常にアクセス・ナビゲーションできるか
|
||||
- [ ] モックデータが基本的な UI の状態を表現しているか（リスト、空の状態、フォームなど）
|
||||
|
||||
## 第3部：反復開発
|
||||
|
||||
### 3.1 モジュールごとの推進
|
||||
|
||||
スケルトンをベースに、以下の順序でモジュールごとに機能を追加します：
|
||||
|
||||
1. **認証**：登録、ログイン、ロールの区別
|
||||
2. **データベース**：データテーブルの作成、読み書きインターフェース
|
||||
3. **コア業務**：画像生成タスク、結果の保存
|
||||
4. **OSS ストレージ**：画像のアップロードとアクセス
|
||||
5. **決済**：プラン、クレジット、Stripe 統合
|
||||
6. **ソーシャルインタラクション**：シェア、いいね、コメント
|
||||
7. **管理画面**：ユーザー管理、タスク管理、コンテンツ審査
|
||||
8. **データモニタリング**：SaaS 指標ダッシュボード、システムモニタリング
|
||||
|
||||
各モジュールの完了後、以下の表で自己チェック：
|
||||
|
||||
| チェック項目 | 検証方法 |
|
||||
|--------|----------|
|
||||
| ページの一致性 | ページ数、入口、機能が PRD に合致しているか |
|
||||
| インターフェースの正確性 | リクエストパラメータ、返却構造、ステータス処理が適切か |
|
||||
| 権限の分離 | 一般ユーザーと管理者が相互に分離されているか |
|
||||
| データの整合性 | データベース、OSS、決済、クレジットが一致しているか |
|
||||
| デモ可能性 | 他の人に完全な業務チェーンをデモできるか |
|
||||
|
||||
::: tip
|
||||
AI が生成した内容が PRD から逸脱していることに気づいた場合は、ページ全体をやり直すのではなく、具体的なモジュールの修正を指示してください。
|
||||
:::
|
||||
|
||||
### 3.2 ロールと役割分担
|
||||
|
||||
反復開発の過程では、3つのロールを同時に演じる必要があります：
|
||||
|
||||
- **プロダクトマネージャー**：各モジュールの機能が PRD に合致しているかを確認
|
||||
- **テックリード**：実装方法が適切であるかを確認
|
||||
- **テストエンジニア**：機能が正しく動作するかを確認
|
||||
|
||||
## 第4部：結合テストとデプロイ
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
最終段階の重点は新しいページを追加することではなく、完全な業務チェーンを動作させることです。少なくとも以下のシナリオを検証してください：
|
||||
|
||||
- 登録 → クレジット購入 → 画像生成 → 履歴確認 → シェアとインタラクション
|
||||
- 管理者のログイン → ユーザーデータの確認 → タスク統計の確認 → システムモニタリングの確認
|
||||
|
||||
### 4.2 デプロイ
|
||||
|
||||
プロジェクトをパブリックネットワーク環境にデプロイし、以下を確認：
|
||||
|
||||
- 環境変数の設定が完全であること
|
||||
- ログインのコールバックアドレスが正しいこと
|
||||
- 決済のコールバックアドレスが正しいこと
|
||||
- ページにローディング、空の状態、エラーメッセージが欠落していないこと
|
||||
|
||||
デプロイのチュートリアルはこちらを参照してください：[Git と GitHub ワークフロー](../../backend/git-workflow/)、[Web アプリケーションのデプロイ方法](../../backend/zeabur-deployment/)。
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出してください：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリのリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（公式サイトホーム、生成ワークスペース、ギャラリー、プランページ、管理画面ホーム）
|
||||
- [ ] 60秒のデモ動画（登録 → 生成 → 確認 → 管理画面を網羅）
|
||||
|
||||
README には少なくとも以下を含めてください：プロジェクト概要、コアページの説明、技術スタック、ローカル起動手順、環境変数リスト。
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| PRD への整合 | ページ、機能、データ構造が基本的に PRD に合致 | 各設計決定と PRD の対応関係を明確に説明できる |
|
||||
| 製品完了 | 登録 → クレジット購入 → 画像生成 → 履歴確認 → シェアとインタラクションが動作 | 決済ステータス、クレジット残高、生成回数のデータが一致 |
|
||||
| 管理画面の機能 | ユーザー、タスク、決済、コンテンツ管理が閲覧可能 | SaaS 指標ダッシュボードとシステムモニタリングページが完全に利用可能 |
|
||||
| エンジニアリング完成度 | フロントエンド、バックエンド、データベース、OSS、決済チェーンが接続済み | エラー処理、空の状態、ローディング状態がある |
|
||||
| 納品品質 | デプロイ可能、実行可能 | README が明確で、デモ動画の構造が完全 |
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [UI 設計仕様を参考にページとボタンを設計](../../frontend/multi-product-ui/)
|
||||
- [LLM と Skills でインターフェースを見栄えよくする](../../frontend/llm-skills-beautiful/)
|
||||
- [デザインプロトタイプからプロジェクトコードへ](../../frontend/design-to-code/)
|
||||
- [モダンコンポーネントライブラリでインターフェースをアップデート](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase へ](../../backend/database-supabase/)
|
||||
- [大規模言語モデルによるインターフェースコードとインターフェース文書の作成支援](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリケーションのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
- [Stripe などの決済システムの統合方法](../../backend/stripe-payment/)
|
||||
@@ -0,0 +1,162 @@
|
||||
# Spring Boot 映画レコメンドシステム開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD に基づいて、Spring Boot を使用してレコメンド機能付きの映画サイトを完成させます。このプロジェクトのコアチャレンジは、単純な CRUD ではなく、「ユーザーの行動がレコメンド結果にどう影響するか」「レコメンドをどう説明可能にするか」を考えることにあります。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。「コンテンツ + 行動 + レコメンド」型製品の開発パターンに初めて触れる機会であり、このパターンは EC、コンテンツプラットフォーム、パーソナライズフィードなどのシナリオで非常に一般的です。
|
||||
|
||||
## 前提知識
|
||||
|
||||
このプロジェクトを始める前に、以下の内容をすでに習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェース設計と開発（[インターフェースコード作成](../../backend/ai-interface-code/)）
|
||||
- データベース基礎と Supabase（[データベースから Supabase まで](../../backend/database-supabase/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践完了後、以下のことができるようになります：
|
||||
|
||||
1. PRD を読み、レコメンドシステムの開発タスクリストを抽出する
|
||||
2. Spring Boot を使用してバックエンドプロジェクトを構築し、RESTful API を実装する
|
||||
3. 「ユーザー行動 → レコメンド」の完全なデータパイプラインを設計する
|
||||
4. 説明可能なレコメンドロジックを実装する
|
||||
5. エンドツーエンドの結合テストを完了し、デモ可能な製品プロトタイプを納品する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
あなたが構築する製品は、レコメンド機能付きの映画サイトです：
|
||||
|
||||
| 機能 | 説明 |
|
||||
|------|------|
|
||||
| **閲覧と検索** | ユーザーは映画を閲覧・検索できる |
|
||||
| **評価とお気に入り** | ユーザーは映画を評価し、お気に入りに追加できる |
|
||||
| **パーソナライズレコメンド** | システムがユーザー行動に基づいてレコメンド結果を表示 |
|
||||
| **管理バックエンド** | 管理者が映画データを管理し、レコメンド効果を確認 |
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件文書は GitHub にあります： [PRD を表示](https://github.com/datawhalechina/easy-vibe/blob/main/docs/ja-jp/stage-2/assignments/movie-recommendation-springboot/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、レコメンド戦略、行動データ、管理範囲を明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'AI でリストページ、詳細ページ、レコメンドページ、管理ページを生成' },
|
||||
{ title: '反復開発', description: 'レコメンドロジック、行動記録、管理機能を追加' },
|
||||
{ title: '結合とリリース', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第 1 部：要件分析
|
||||
|
||||
### 1.1 PRD を読む
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- レコメンド戦略は何ですか？第 1 版では説明可能なバージョン（評価類似度に基づくなど）を使用しますか？
|
||||
- ユーザー行動データとして何を保存しますか？（評価、お気に入り、閲覧履歴など）
|
||||
- 管理者が確認すべきレコメンド効果指標は何ですか？
|
||||
- ページリストは完全ですか？
|
||||
|
||||
::: warning
|
||||
以上の質問に対する明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確なのは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 システムアーキテクチャの確認
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["フロントエンドページ"]
|
||||
web --> auth["ユーザー認証"]
|
||||
web --> movie["映画リスト / 詳細"]
|
||||
web --> behavior["評価 / お気に入り"]
|
||||
behavior --> reco["レコメンドロジック"]
|
||||
reco --> db["データベース"]
|
||||
admin["管理バックエンド"] --> db
|
||||
```
|
||||
|
||||
## 第 2 部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 フロントエンドページの生成
|
||||
|
||||
プロンプト参考：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、Spring Boot 映画レコメンドシステムのフロントエンドスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. ページには以下を含む：ホーム、映画リスト、映画詳細、レコメンドページ、個人センター、管理バックエンド
|
||||
2. まずページ構造とモックデータのみを生成し、実際のインターフェースには接続しない
|
||||
3. 授業のデモではなく、実際のコンテンツ製品のようなスタイルにする
|
||||
```
|
||||
|
||||
### 2.2 プロジェクト構造の検証
|
||||
|
||||
項目ごとにチェック：
|
||||
|
||||
- [ ] 映画リストページで検索とフィルタリングがサポートされている
|
||||
- [ ] 映画詳細ページに評価とお気に入りボタンがある
|
||||
- [ ] レコメンドページでレコメンド結果とレコメンド理由が表示できる
|
||||
- [ ] 管理バックエンドで映画データとレコメンド効果が確認できる
|
||||
|
||||
## 第 3 部：反復開発
|
||||
|
||||
### 3.1 モジュールごとに進める
|
||||
|
||||
1. **Spring Boot プロジェクト構築**：プロジェクト構造、データベース設定、基本 CRUD
|
||||
2. **映画データ管理**：映画リスト、詳細、検索インターフェース
|
||||
3. **ユーザー行動**：評価、お気に入りインターフェース、行動データ書き込み
|
||||
4. **レコメンドロジック**：ユーザー行動に基づくレコメンドアルゴリズムの実装
|
||||
5. **レコメンド表示**：レコメンド結果の表示、レコメンド理由を含む
|
||||
6. **管理バックエンド**：映画データのメンテナンス、レコメンド効果の確認
|
||||
|
||||
### 3.2 モジュール自己チェック
|
||||
|
||||
| チェック項目 | 検証方法 |
|
||||
|--------|----------|
|
||||
| 基本機能 | リスト、詳細、評価、お気に入りのクロージャが完了しているか |
|
||||
| レコメンド連動 | ユーザー行動がレコメンド結果に影響しているか |
|
||||
| レコメンド説明可能性 | ユーザーがなぜこれらの映画をレコメンドされたか理解できるか |
|
||||
| 管理データ | 管理者が映画データとレコメンド効果を確認できるか |
|
||||
|
||||
## 第 4 部：結合テストとリリース
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証：
|
||||
|
||||
- 映画を閲覧 → 評価 → お気に入り → レコメンドページを確認し、レコメンド結果が変化したことを確認
|
||||
- 管理者ログイン → 映画を追加 → レコメンド効果統計を確認
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出する必要があります：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（映画リスト、映画詳細、レコメンドページ、管理バックエンド）
|
||||
- [ ] 60 秒のデモ動画
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| PRD 整合性 | ページ、機能、データ構造が基本的に PRD に適合 | 設計決定を明確に説明できる |
|
||||
| 製品クロージャ | 閲覧 → 評価 → お気に入り → レコメンドが動作する | 評価行動がレコメンド結果に明確に影響する |
|
||||
| レコメンド品質 | レコメンド結果が合理的で、理由が説明可能 | 複数のレコメンド戦略をサポート |
|
||||
| 管理機能 | 映画データとレコメンド効果が確認可能 | レコメンド精度などの統計指標がある |
|
||||
| エンジニアリング完成度 | フロントエンド、Spring Boot バックエンド、データベースのパイプラインが接続されている | レコメンドインターフェースにキャッシュやパフォーマンス最適化がある |
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [モダンコンポーネントライブラリでインターフェースを更新](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase まで](../../backend/database-supabase/)
|
||||
- [大規模モデルによるインターフェースコードとドキュメント作成](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,172 @@
|
||||
# 生鮮 EC マイクロサービスシステム開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD に基づいて、生鮮 EC マイクロサービスシステムを一から完成させます。これまでの単一サービスプロジェクトとは異なり、このプロジェクトのバックエンドはビジネスごとに複数の独立したサービスに分割され、API ゲートウェイを通じて統一的に外部に公開されます。サービス境界の設計方法や、クロスサービスのデータ整合性の処理方法を学びます。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。マイクロサービスアーキテクチャは実際の業務で非常に一般的であり、サービス分割とゲートウェイルーティングの基本的な考え方を習得すれば、より複雑なバックエンドシステム設計に対応できるようになります。
|
||||
|
||||
## 前提知識
|
||||
|
||||
このプロジェクトを始める前に、以下の内容をすでに習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェース設計と開発（[インターフェースコード作成](../../backend/ai-interface-code/)）
|
||||
- データベース基礎と Supabase（[データベースから Supabase まで](../../backend/database-supabase/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践完了後、以下のことができるようになります：
|
||||
|
||||
1. PRD を読み、マイクロサービスシステムの開発タスクリストを抽出する
|
||||
2. ビジネスドメインごとにサービス境界を分割する（認証、商品、在庫、注文）
|
||||
3. API ゲートウェイルーティングを設計・実装する
|
||||
4. 在庫引き当てや注文整合性などのクロスサービス問題を処理する
|
||||
5. エンドツーエンドの結合テストを完了し、デモ可能なマイクロサービスプロトタイプを納品する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
あなたが構築する製品は、生鮮 EC マイクロサービスシステムです：
|
||||
|
||||
| サブシステム | 責務 |
|
||||
|--------|------|
|
||||
| **ユーザー側** | 商品閲覧、注文、注文確認 |
|
||||
| **管理側** | 商品管理、在庫管理、注文管理 |
|
||||
|
||||
バックエンドはビジネスごとに以下のサービスに分割されます：
|
||||
|
||||
| サービス | 責務 |
|
||||
|------|------|
|
||||
| **API Gateway** | 統一エントリ、ルーティング転送、認証チェック |
|
||||
| **Auth Service** | ユーザー登録、ログイン、JWT 発行 |
|
||||
| **Catalog Service** | 商品情報管理 |
|
||||
| **Inventory Service** | 在庫数量管理 |
|
||||
| **Order Service** | 注文作成、ステータス管理 |
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件文書は GitHub にあります： [PRD を表示](https://github.com/datawhalechina/easy-vibe/blob/main/docs/ja-jp/stage-2/assignments/simple-grocery-microservices/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、サービス分割、ページ、取引フローを明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'フロントエンド、ゲートウェイ、各サービスのスケルトンを生成' },
|
||||
{ title: '反復開発', description: 'モジュールごとにインターフェースを追加し、在庫と注文の整合性を修正' },
|
||||
{ title: '結合とリリース', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第 1 部：要件分析
|
||||
|
||||
### 1.1 PRD を読む
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- サービスはどのように分割しますか？各サービスの責任境界は何ですか？
|
||||
- フロントエンドと管理側にはそれぞれどのページがありますか？
|
||||
- 注文後の在庫引き当ての戦略は何ですか？成功/失敗/タイムアウトの各ケースにどう対応しますか？
|
||||
- 第 1 版では、どの複雑な機能（分散トランザクション、メッセージキューなど）を先送りにしますか？
|
||||
|
||||
::: warning
|
||||
以上の質問に対する明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確なのは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 システムアーキテクチャの確認
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> fe["フロントエンドページ"]
|
||||
fe --> gw["API Gateway"]
|
||||
gw --> auth["Auth Service"]
|
||||
gw --> catalog["Catalog Service"]
|
||||
gw --> inventory["Inventory Service"]
|
||||
gw --> order["Order Service"]
|
||||
order --> inventory
|
||||
```
|
||||
|
||||
## 第 2 部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 プロジェクト構造の生成
|
||||
|
||||
プロンプト参考：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、生鮮 EC マイクロサービスシステムのプロジェクトスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. フロントエンドのユーザー側と管理側のスケルトンを生成
|
||||
2. api-gateway、auth-service、catalog-service、inventory-service、order-service の 5 つのディレクトリを生成
|
||||
3. 各サービスはまず最小限の実行可能エントリのみを作成
|
||||
4. 実際のデータベースと決済はまだ接続しない
|
||||
```
|
||||
|
||||
### 2.2 プロジェクト構造の検証
|
||||
|
||||
項目ごとにチェック：
|
||||
|
||||
- [ ] 5 つのサービスディレクトリ構造が明確
|
||||
- [ ] API Gateway が起動してリクエストを転送できる
|
||||
- [ ] 各サービスのヘルスチェックインターフェースが利用可能
|
||||
- [ ] フロントエンドのユーザー側と管理側ページがアクセス可能
|
||||
|
||||
## 第 3 部：反復開発
|
||||
|
||||
### 3.1 モジュールごとに進める
|
||||
|
||||
1. **API Gateway**：ルーティング設定、JWT 検証ミドルウェア
|
||||
2. **Auth Service**：登録、ログイン、JWT 発行
|
||||
3. **Catalog Service**：商品 CRUD、リストクエリ
|
||||
4. **Inventory Service**：在庫照会、在庫引き当て
|
||||
5. **Order Service**：注文作成、ステータス遷移、在庫連動
|
||||
6. **管理側**：商品管理、在庫管理、注文管理
|
||||
|
||||
### 3.2 モジュール自己チェック
|
||||
|
||||
| チェック項目 | 検証方法 |
|
||||
|--------|----------|
|
||||
| ゲートウェイルーティング | 各サービスのインターフェースがゲートウェイ経由で正しく転送されているか |
|
||||
| 権限分離 | ユーザー側と管理側のインターフェースが分離されているか |
|
||||
| データ整合性 | 商品と在庫のデータが同期しているか |
|
||||
| 取引クロージャ | 注文後の在庫引き当て、注文ステータスが一致しているか |
|
||||
| 障害処理 | 在庫不足やタイムアウト時に補償メカニズムがあるか |
|
||||
|
||||
## 第 4 部：結合テストとリリース
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証：
|
||||
|
||||
- 商品を閲覧 → カートに追加 → 注文 → 注文確認
|
||||
- 管理者 → 商品を追加 → 在庫を更新 → 注文確認
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出する必要があります：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（商品リスト、注文ページ、注文ページ、管理バックエンド）
|
||||
- [ ] 60 秒のデモ動画
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| PRD 整合性 | ページ、機能、サービス分割が基本的に PRD に適合 | サービス分割の理由を明確に説明できる |
|
||||
| 製品クロージャ | 閲覧 → 注文 → 在庫引き当て → 注文確認が動作する | 注文タイムアウトや在庫不足時に補償メカニズムがある |
|
||||
| サービスアーキテクチャ | 各サービスが独立して起動でき、ゲートウェイ経由で統一アクセス可能 | サービス間通信にエラー処理とリトライがある |
|
||||
| 管理機能 | 商品、在庫、注文管理が操作可能 | 管理側にデータ統計がある |
|
||||
| エンジニアリング完成度 | フロントエンド、ゲートウェイ、サービス、データベースのパイプラインが接続されている | Docker Compose などのオーケストレーションがある |
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [モダンコンポーネントライブラリでインターフェースを更新](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase まで](../../backend/database-supabase/)
|
||||
- [大規模モデルによるインターフェースコードとドキュメント作成](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,163 @@
|
||||
# Go 交通データ分析プラットフォーム開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD に基づいて、Go を使用して交通データ分析プラットフォームを完成させます。このプロジェクトの方向性は、これまでの CRUD システムとは異なり、「データ取り込み → 集計 → アラート → 可視化」という完全なデータパイプラインを構築します。このようなデータ製品は、IoT、モニタリング、運用分析などのシナリオで非常に一般的です。
|
||||
|
||||
これは Stage 2 の総合実践セクションであり、Go 言語に初めて触れる機会でもあります。心配しないでください。これまでの JavaScript / TypeScript の基礎があれば、Go の学習は難しくありません。重要なのは、データパイプラインの設計思路を理解することです。
|
||||
|
||||
## 前提知識
|
||||
|
||||
このプロジェクトを始める前に、以下の内容をすでに習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェース設計と開発（[インターフェースコード作成](../../backend/ai-interface-code/)）
|
||||
- データベース基礎と Supabase（[データベースから Supabase まで](../../backend/database-supabase/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践完了後、以下のことができるようになります：
|
||||
|
||||
1. PRD を読み、データ製品の開発タスクリストを抽出する
|
||||
2. Go（Gin または Fiber）を使用してバックエンド API サービスを構築する
|
||||
3. データ取り込み、ウィンドウ集計、アラートの完全なパイプラインを設計する
|
||||
4. バックエンドデータとフロントエンドダッシュボードの整合性を保つ
|
||||
5. エンドツーエンドの結合テストを完了し、デモ可能なデータ製品プロトタイプを納品する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
あなたが構築する製品は、Go 交通データ分析プラットフォームです：
|
||||
|
||||
| モジュール | 責務 |
|
||||
|------|------|
|
||||
| **データ取り込み** | 生の交通イベントを受信してデータベースに格納 |
|
||||
| **データ集計** | 時間ウィンドウごとにトレンドと渋滞指標を計算 |
|
||||
| **アラート** | ルールに基づいてアラートレコードを生成 |
|
||||
| **ダッシュボード表示** | フロントエンドでトレンドグラフ、ランキング、アラートリストを表示 |
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件文書は GitHub にあります： [PRD を表示](https://github.com/datawhalechina/easy-vibe/blob/main/docs/ja-jp/stage-2/assignments/traffic-data-visualization-go/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、データソース、指標定義、アラートルールを明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'AI で Go API サービスとフロントエンドダッシュボードのスケルトンを生成' },
|
||||
{ title: '反復開発', description: '集計ロジック、アラートルール、ダッシュボードインターフェースを追加' },
|
||||
{ title: '結合とリリース', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第 1 部：要件分析
|
||||
|
||||
### 1.1 PRD を読む
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- データソースは何ですか？フィールドには何がありますか？
|
||||
- コア指標の定義は何ですか？（例：「渋滞」の具体的な基準）
|
||||
- アラートルールは何ですか？第 1 版ではまずシンプルなルールに絞りますか？
|
||||
- ダッシュボードにはどのページとグラフが含まれますか？
|
||||
|
||||
::: warning
|
||||
以上の質問に対する明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確なのは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 データパイプラインの確認
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> ingest["データ取り込み API"]
|
||||
ingest --> raw["生データテーブル"]
|
||||
raw --> agg["集計タスク"]
|
||||
agg --> alert["アラートルール"]
|
||||
agg --> dashboard["ダッシュボードインターフェース"]
|
||||
alert --> dashboard
|
||||
```
|
||||
|
||||
## 第 2 部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 Go API サービスの生成
|
||||
|
||||
プロンプト参考：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、Go 交通データ分析プラットフォームのスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. Gin または Fiber を使用
|
||||
2. データ取り込みインターフェースを提供
|
||||
3. 集計タスクのスケルトンを提供
|
||||
4. dashboard と alerts インターフェースのスケルトンを提供
|
||||
5. まずは複雑な分析を実装せず、実行可能な構造のみを構築
|
||||
```
|
||||
|
||||
### 2.2 プロジェクト構造の検証
|
||||
|
||||
項目ごとにチェック：
|
||||
|
||||
- [ ] Go サービスが正常に起動できる
|
||||
- [ ] データ取り込みインターフェースでデータを受信して保存できる
|
||||
- [ ] 集計タスクのフレームワークが構築されている
|
||||
- [ ] フロントエンドダッシュボードページで基本グラフが表示できる
|
||||
|
||||
## 第 3 部：反復開発
|
||||
|
||||
### 3.1 モジュールごとに進める
|
||||
|
||||
1. **データ取り込み API**：生の交通イベントを受信し、データベースに書き込む
|
||||
2. **データ集計**：時間ウィンドウごとに集計し、トレンドと渋滞指標を計算
|
||||
3. **アラートルール**：閾値に基づいてアラートレコードを生成
|
||||
4. **ダッシュボードインターフェース**：トレンドデータ、ランキングデータ、アラートリストを提供
|
||||
5. **フロントエンドダッシュボード**：トレンドグラフ、ランキング、アラートリストページ
|
||||
|
||||
### 3.2 モジュール自己チェック
|
||||
|
||||
| チェック項目 | 検証方法 |
|
||||
|--------|----------|
|
||||
| データ取り込み | 生データが正しくデータベースに格納されているか |
|
||||
| 集計定義 | トレンド、ランキング指標の計算ロジックが一致しているか |
|
||||
| アラートルール | アラートのトリガー条件が期待通りか |
|
||||
| データ整合性 | ダッシュボードの表示とバックエンドデータが一致しているか |
|
||||
| API 仕様 | 統一されたレスポンス構造とエラー処理があるか |
|
||||
|
||||
## 第 4 部：結合テストとリリース
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証：
|
||||
|
||||
- テストデータを取り込み → 集計タスクを実行 → ダッシュボード表示が更新される
|
||||
- アラート条件をトリガー → アラートレコードが生成 → アラートページに表示
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出する必要があります：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（データ取り込みデモ、トレンドダッシュボード、アラートリスト）
|
||||
- [ ] 60 秒のデモ動画
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| PRD 整合性 | 機能とデータ構造が基本的に PRD に適合 | 指標定義と集計ロジックを明確に説明できる |
|
||||
| データパイプライン | 取り込み → 集計 → アラート → ダッシュボードが動作する | 集計タスクが増分更新をサポート |
|
||||
| 分析能力 | トレンド、ランキング、アラートの 3 モジュールが利用可能 | 指標が設定可能、アラートルールがカスタマイズ可能 |
|
||||
| フロントエンド表示 | ダッシュボードで基本グラフが表示できる | グラフが時間範囲フィルタをサポート |
|
||||
| エンジニアリング完成度 | Go API、データベース、フロントエンドのパイプラインが接続されている | API に統一されたエラー処理とログがある |
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [モダンコンポーネントライブラリでインターフェースを更新](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase まで](../../backend/database-supabase/)
|
||||
- [大規模モデルによるインターフェースコードとドキュメント作成](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,164 @@
|
||||
# スマート旅行計画 Agent プラットフォーム開発実践
|
||||
|
||||
## 概要
|
||||
|
||||
本実践プロジェクトでは、実際の PRD に基づいて、スマート旅行計画 Agent プラットフォームを一から完成させます。構造化された入力を受け取り、毎日の旅程を生成し、保存と再利用をサポートする完全な AI 製品を構築します。単なるチャットボットではなく、タスク管理能力を持つ製品です。
|
||||
|
||||
これは Stage 2 の総合実践セクションです。このプロジェクトのコアチャレンジは、AI が構造化された使用可能な旅程計画を生成するようにすることであり、操作不可能な長いテキストではなく、実用的な出力を生み出すことにあります。
|
||||
|
||||
## 前提知識
|
||||
|
||||
このプロジェクトを始める前に、以下の内容をすでに習得している必要があります：
|
||||
|
||||
- フロントエンドページ設計とコンポーネントライブラリの使用（[UI 設計](../../frontend/ui-design/)、[モダンコンポーネントライブラリ](../../frontend/modern-component-library/)）
|
||||
- バックエンドインターフェース設計と開発（[インターフェースコード作成](../../backend/ai-interface-code/)）
|
||||
- データベース基礎と Supabase（[データベースから Supabase まで](../../backend/database-supabase/)）
|
||||
- Git ワークフローとデプロイ（[Git と GitHub](../../backend/git-workflow/)、[Web アプリのデプロイ](../../backend/zeabur-deployment/)）
|
||||
|
||||
## 学習目標
|
||||
|
||||
本実践完了後、以下のことができるようになります：
|
||||
|
||||
1. PRD を読み、Agent プラットフォームの開発タスクリストを抽出する
|
||||
2. 構造化された入力フォームと構造化された出力形式を設計する
|
||||
3. Agent オーケストレーション層を実装し、ユーザー入力、モデル呼び出し、結果保存を処理する
|
||||
4. 「生成 → 保存 → 再利用」のビジネスクロージャを構築する
|
||||
5. エンドツーエンドの結合テストを完了し、デモ可能な AI 製品プロトタイプを納品する
|
||||
|
||||
## プロジェクト概要
|
||||
|
||||
あなたが構築する製品は、スマート旅行計画 Agent プラットフォームです：
|
||||
|
||||
| 機能 | 説明 |
|
||||
|------|------|
|
||||
| **旅程計画** | ユーザーが出発地、目的地、日付、予算、好みを入力し、システムが毎日の旅程を生成 |
|
||||
| **予算配分** | 旅程結果に予算配分と提案を含む |
|
||||
| **履歴管理** | ユーザーは過去の計画を保存、再生成、エクスポート可能 |
|
||||
| **管理バックエンド** | 管理者が人気の目的地、失敗タスク、ユーザーフィードバックを確認 |
|
||||
|
||||
::: tip PRD 入口
|
||||
本プロジェクトの要件文書は GitHub にあります： [PRD を表示](https://github.com/datawhalechina/easy-vibe/blob/main/docs/ja-jp/stage-2/assignments/travel-planning-agent-platform/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '要件分析', description: 'PRD を読み、ページ、Agent オーケストレーション、入出力構造を明確にする' },
|
||||
{ title: 'スケルトン構築', description: 'AI でホーム、計画ページ、履歴ページ、管理ページのスケルトンを生成' },
|
||||
{ title: '反復開発', description: '構造化出力、タスクステータス、履歴管理をモジュールごとに追加' },
|
||||
{ title: '結合とリリース', description: 'エンドツーエンドで動作確認し、デプロイしてデモを準備' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 第 1 部：要件分析
|
||||
|
||||
### 1.1 PRD を読む
|
||||
|
||||
PRD 文書を開き、以下の質問に重点的に答えてください：
|
||||
|
||||
- 第 1 版は単一目的地のみにしますか？
|
||||
- 旅程出力は構造化されている必要がありますか？その構造は何ですか？
|
||||
- エクスポート機能はどの程度深く実装しますか？（共有リンク / PDF / 画像）
|
||||
- 管理バックエンドの統計とタスクログの範囲は何ですか？
|
||||
|
||||
::: warning
|
||||
以上の質問に対する明確な答えがない場合は、コードを書き始めないでください。要件の理解が不明確なのは、手戻りの最も一般的な原因です。
|
||||
:::
|
||||
|
||||
### 1.2 データパイプラインの確認
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> planner["計画ページ"]
|
||||
planner --> agent["Agent オーケストレーション層"]
|
||||
agent --> model["モデル呼び出し"]
|
||||
agent --> db["データベース"]
|
||||
db --> history["履歴計画"]
|
||||
db --> admin["管理統計とログ"]
|
||||
```
|
||||
|
||||
## 第 2 部：プロジェクトスケルトンの構築
|
||||
|
||||
### 2.1 フロントエンドページの生成
|
||||
|
||||
プロンプト参考：
|
||||
|
||||
```text
|
||||
現在の PRD に基づいて、スマート旅行計画 Agent プラットフォームのフロントエンドスケルトンを生成してください。
|
||||
|
||||
要件：
|
||||
1. ページには以下を含む：ホーム、計画ページ、旅程詳細ページ、履歴記録ページ、管理ページ
|
||||
2. 計画ページの左側にフォーム、右側に結果プレビュー
|
||||
3. まずページ構造とモックデータのみを生成し、実際のインターフェースには接続しない
|
||||
4. モダンな AI 製品のようなスタイルにする
|
||||
```
|
||||
|
||||
### 2.2 プロジェクト構造の検証
|
||||
|
||||
項目ごとにチェック：
|
||||
|
||||
- [ ] 計画ページのフォームフィールドが PRD と一致している
|
||||
- [ ] 結果プレビュー領域で構造化された旅程データが表示できる
|
||||
- [ ] 履歴記録ページで複数の計画が表示できる
|
||||
- [ ] 管理バックエンドページで統計データが表示できる
|
||||
|
||||
## 第 3 部：反復開発
|
||||
|
||||
### 3.1 モジュールごとに進める
|
||||
|
||||
1. **認証**：登録、ログイン
|
||||
2. **計画フォーム**：構造化入力（出発地、目的地、日付、予算、好み）
|
||||
3. **Agent オーケストレーション**：入力の受信 → モデル呼び出し → 構造化出力の解析
|
||||
4. **結果表示**：旅程を日ごとに表示、予算配分、提案
|
||||
5. **履歴管理**：計画の保存、再生成、エクスポート
|
||||
6. **管理バックエンド**：人気の目的地、失敗タスク、ユーザーフィードバック
|
||||
7. **タスクステータス**：生成中 / 成功 / 失敗のステータス管理とエラー記録
|
||||
|
||||
### 3.2 モジュール自己チェック
|
||||
|
||||
| チェック項目 | 検証方法 |
|
||||
|--------|----------|
|
||||
| 入力完全性 | フォームフィールドが PRD と一致しているか |
|
||||
| 出力構造化 | 旅程結果が構造化データであるか（長いテキストではないか） |
|
||||
| データ整合性 | trip、itinerary、logs のデータが一致しているか |
|
||||
| クロージャ検証 | 「入力 → 生成 → 保存 → 再生成」のデモができるか |
|
||||
|
||||
## 第 4 部：結合テストとリリース
|
||||
|
||||
### 4.1 エンドツーエンドテスト
|
||||
|
||||
少なくとも以下のシナリオを検証：
|
||||
|
||||
- 旅程パラメータを入力 → 毎日の旅程を生成 → 予算配分を確認 → 履歴に保存
|
||||
- 履歴記録から旅程を再生成
|
||||
- 管理者がタスク統計と失敗ログを確認
|
||||
|
||||
## 提出物
|
||||
|
||||
本プロジェクト完了後、以下の内容を提出する必要があります：
|
||||
|
||||
- [ ] アクセス可能なオンラインデモリンク
|
||||
- [ ] ソースコードリポジトリリンク（README を含む）
|
||||
- [ ] PRD 文書
|
||||
- [ ] コアページのスクリーンショット（計画ページ、旅程詳細ページ、履歴記録ページ、管理バックエンド）
|
||||
- [ ] 60 秒のデモ動画
|
||||
|
||||
## 評価基準
|
||||
|
||||
| 項目 | 基本要件 | 応用要件 |
|
||||
|------|---------|---------|
|
||||
| PRD 整合性 | ページ、機能、データ構造が基本的に PRD に適合 | 設計決定を明確に説明できる |
|
||||
| 製品クロージャ | 計画 → 保存 → 履歴 → 再生成が動作する | エクスポートと共有をサポート |
|
||||
| 出力品質 | 旅程結果が構造化され読みやすい | 予算配分が合理的で、提案に针对性がある |
|
||||
| 管理機能 | タスク統計と失敗ログが確認可能 | 人気の目的地分析がある |
|
||||
| エンジニアリング完成度 | フロントエンド、バックエンド、データベース、モデル呼び出しパイプラインが接続されている | タスクステータス管理が充実し、エラーがトレース可能 |
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [UI 設計](../../frontend/ui-design/)
|
||||
- [モダンコンポーネントライブラリでインターフェースを更新](../../frontend/modern-component-library/)
|
||||
- [データベースから Supabase まで](../../backend/database-supabase/)
|
||||
- [大規模モデルによるインターフェースコードとドキュメント作成](../../backend/ai-interface-code/)
|
||||
- [Git と GitHub ワークフロー](../../backend/git-workflow/)
|
||||
- [Web アプリのデプロイ方法](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,161 @@
|
||||
# 大規模言語モデルによるインターフェースコードとインターフェース文書の作成支援
|
||||
|
||||
これまでのレッスンでは、Figma などのツールを使った UI デザイン、AI を活用したフロントエンド静的ページの自動生成、そして Supabase を利用したデータベース構築とユーザー認証の基本について学びました。ここで、自然と浮かんでくる疑問があります。フロントエンドページ上のあのダイナミックなボタンをクリックしたとき、データはどのようにして Supabase に送られているのでしょうか？また、より複雑なビジネスロジック（同時決済、定期プッシュ通知、機密データ処理など）を実行する際、フロントエンドから直接データベースに接続するのは安全でしょうか？
|
||||
|
||||
ここで登場するのが、現代の Web 開発アーキテクチャにおいて極めて重要な要素——**バックエンド API インターフェース**です。
|
||||
|
||||
かつては、バックエンドルート、コントローラー、パラメータ検証ロジックを何百行も手書きしなければなりませんでした。今では、大規模言語モデルの強力なコード生成能力を活用し、煩雑な定型コードを AI に任せることができます。本レッスンでは、「AI が書くコードは抽象的で曖昧」という罠から脱却し、実際のビジネスシナリオに基づき、高品質なプロンプト（Prompt）を使って大規模言語モデルに堅牢で業界標準に準拠した Node.js バックエンドインターフェースを書かせる方法、そしてインターフェース文書とテストケースの自動生成について解説します。
|
||||
|
||||
> 💡 **前提知識**
|
||||
>
|
||||
> 本節を学ぶ前に、以下の内容を理解しておくことをお勧めします：
|
||||
> - [データベースから Supabase へ](../database-supabase/) - データベースとデータモデルの概念について理解する。
|
||||
> - [Git と GitHub ワークフロー](../git-workflow/) - プロジェクト開発におけるバージョン管理の方法に慣れる。
|
||||
> - [ターミナル / コマンドラインとは](/ja-jp/appendix/2-development-tools/command-line-shell) - プロジェクトの初期化と起動には基本的なコマンド操作が欠かせません。
|
||||
|
||||
# このレッスンで学ぶこと
|
||||
|
||||
1. **API インターフェースとは何か**：フロントエンドとバックエンドの通信を橋渡しする仕組みと、RESTful 設計規約について理解する。
|
||||
2. **大規模言語モデルによるサービス構築**：構造化された Prompt を使って AI に Node.js + Express の基本プロジェクトを構築させる方法。
|
||||
3. **インターフェースロジック開発**：大規模言語モデルに、厳密なビジネスバリデーションを含み、Supabase データベースと連携する CRUD（作成・読み取り・更新・削除）インターフェースを生成させる。
|
||||
4. **インターフェース文書の自動生成**：コードから逆算して、チーム間コラボレーションの標準である OpenAPI/Swagger 文書を生成させる。
|
||||
5. **テストと結合のフィードバックループ**：Postman テストコレクションや Jest ユニットテストケースを生成し、コードの品質を担保する。
|
||||
|
||||
---
|
||||
|
||||
# 1. なぜ API インターフェースが必要なのか？
|
||||
|
||||
従来の理解では、フロントエンドは「見える部分」、データベースは「データを保管する場所」でした。しかし、その間には調整役が欠けています。アプリケーション全体をレストランに例えてみましょう：
|
||||
- **フロントエンド（クライアント）** はレストランのメニューと注文テーブルであり、客はここでメニューを閲覧し注文を出します。
|
||||
- **データベース（Supabase など）** はレストランの厨房倉庫であり、すべての食材と帳簿が保管されています。
|
||||
- **バックエンド API インターフェース** はレストランのウェイターです。客は厨房に直接押し入って食材を取ることはできません（混乱を招くだけでなく、セキュリティ上の問題も発生します）。客は「注文の要求」（HTTP Request）をウェイターに伝える必要があります。ウェイターは確認（パラメータ検証、権限認証）を行った後、厨房から対応する内容を取り寄せ、「完成した料理」（HTTP Response、通常は JSON 形式のデータ）を客に運びます。
|
||||
|
||||
API インターフェースを通じて、明確な**フロントエンドとバックエンドの分離**を実現します。フロントエンドはページのレンダリングに専念し、バックエンドはビジネスロジック、データ処理、セキュリティ保護に集中します。
|
||||
|
||||
---
|
||||
|
||||
# 2. プロジェクトアーキテクチャの設計と初期化
|
||||
|
||||
構造が明確なプロジェクトスケルトンは、大規模言語モデルが良質なコードを書くための前提条件です。AI にコードを書かせる前に、自分自身でプロジェクト構造を把握しておく必要があります。
|
||||
|
||||
## 2.1 一般的な API プロジェクト構造
|
||||
大規模言語モデルでコードを生成する場合でも、すべてのコードを一つの `server.js` ファイルに詰め込むべきではありません。保守しやすい Node.js バックエンドアーキテクチャは通常、次のようになります：
|
||||
|
||||
```text
|
||||
my-api-project/
|
||||
├── .env # 機密環境変数（API Keys、データベース接続文字列など）
|
||||
├── server.js # プロジェクトのエントリーポイント（サーバー起動、グローバルミドルウェアの登録）
|
||||
├── package.json # 依存関係管理ファイル
|
||||
├── src/
|
||||
│ ├── routes/ # ルーティング層：URL パスとリクエストメソッドを定義
|
||||
│ ├── controllers/ # コントローラー層：リクエストパラメータを処理し、サービスを呼び出してレスポンスを返す
|
||||
│ ├── services/ # サービス層：データベースとのやり取りやコアビジネスロジックをカプセル化
|
||||
│ └── middlewares/ # ミドルウェア：ログイン認証、グローバルエラーハンドリング
|
||||
└── docs/ # API 文書の保存ディレクトリ
|
||||
```
|
||||
|
||||
## 2.2 AI を活用したプロジェクト初期化
|
||||
手動で `npm init` を実行し、依存関係を一つずつインストールするよりも、上記の構造を Prompt の形式で大規模言語モデルに渡す方が効率的です：
|
||||
|
||||
> 🗣️ **大規模言語モデルへのプロンプト（Prompt の例）：**
|
||||
> "Node.js のバックエンドプロジェクトを構築してください。Supabase データベースに接続でき、将来の保守に便利なように構造を整理してください。"
|
||||
|
||||
AI が返したコードを実行すると、`localhost:3000` でエンタープライズレベルの基本構えを持つバックエンドアプリケーションが手に入ります。
|
||||
|
||||
---
|
||||
|
||||
# 3. コア実践：大規模言語モデルによるインターフェース開発支援
|
||||
|
||||
この章の最も重要な部分です。大規模言語モデルが書くコードには「論理的な抜け」や「表面的なごまかし」がよく見られます。その原因は、開発者が与えるコンテキストが不足していることにあります。**大規模言語モデルは複雑な要件を恐れませんが、曖昧な要件を最も苦手とします。**
|
||||
|
||||
[データベースの章](../database-supabase/) で触れた `menu_items`（メニューテーブル）の新規作成インターフェースを例に、高品質な Prompt の書き方を見てみましょう。
|
||||
|
||||
## 3.1 大規模言語モデルに完全なコンテキストを提供する
|
||||
AI にインターフェースを書かせる前に、必ず**データベースのフィールド定義（Schema）**と**具体的な制約条件**を提供してください。
|
||||
|
||||
> 🗣️ **高品質なプロンプト（Prompt）テンプレート：**
|
||||
> "メニューの新規作成インターフェースを作ってください。メニューには商品名、価格、カテゴリ（バーガー、サイドメニュー、ドリンク）、販売状況の情報があります。商品名と価格は必須で、価格に負の値は指定できません。ユーザーの入力が正しくない場合はエラーメッセージを表示してください。"
|
||||
|
||||
## 3.2 大規模言語モデルが生成したコードのレビュー
|
||||
大規模言語モデルが生成したコードは、通常、次のように責務が明確に分割されています：
|
||||
|
||||
```javascript
|
||||
// services/menuService.js
|
||||
const { createClient } = require('@supabase/supabase-js');
|
||||
const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);
|
||||
|
||||
exports.createMenuItem = async (menuData) => {
|
||||
// Supabase SDK を呼び出してテーブルにデータを挿入
|
||||
const { data, error } = await supabase
|
||||
.from('menu_items')
|
||||
.insert([menuData])
|
||||
.select();
|
||||
|
||||
if (error) throw new Error(`データベースへの挿入に失敗しました: ${error.message}`);
|
||||
return data[0];
|
||||
};
|
||||
```
|
||||
|
||||
この方式で生成されたコードは、構造が合理的であるだけでなく、Supabase の初期化、エラーキャッチ、例外処理まで考慮されています。単に「新規作成インターフェースを作って」と頼んで得られるスパゲッティコード（Spaghetti Code）とは雲泥の差があります。
|
||||
|
||||
---
|
||||
|
||||
# 4. 両手を解放する：インターフェース文書の自動生成
|
||||
|
||||
開発チームにとって、文書のない API はブラインドボックスのようなものです。フロントエンドエンジニアは、どのようなパラメータを渡せばよいのか推測できず、どのような構造が返されるのかも予測できません。業界で最も広く使われている API 記述規約は **OpenAPI（以前は Swagger とも呼ばれていました）** です。
|
||||
|
||||
かつて、YAML や JSON 形式の Swagger 文書を手書きすることは非常に苦痛で、エラーが発生しやすい作業でした。今では、これこそが大規模言語モデルの最も得意とする領域となっています。
|
||||
|
||||
先ほど書いた `routes` と `controllers` のコードを選択し、そのまま大規模言語モデルに渡すことができます：
|
||||
|
||||
> 🗣️ **文書生成のプロンプト：**
|
||||
> "上記のコードに基づいてインターフェース文書を生成してください。各パラメータの意味と返却されるデータを明確に記載し、フロントエンドの担当者が連携しやすいようにしてください。"
|
||||
|
||||
この過程で、AI にフィールドの説明（Description）やモックデータ（例えば `price_cents: 1200` が 12 ドルを表す）の補完を要求することもでき、コミュニケーションコストを大幅に削減できます。
|
||||
|
||||
---
|
||||
|
||||
# 5. 品質保証：テストコードと Postman コレクションの生成
|
||||
|
||||
コードの作成と文書の生成が完了したら、最後のステップは「コードが実際に動作するかどうかを検証する」ことです。
|
||||
|
||||
## 5.1 Postman / Apifox テスト設定の生成
|
||||
インターフェース開発では、通常、Postman のようなビジュアルツールを使用して、フロントエンドからの HTTP リクエストをシミュレートします。大規模言語モデルを使わない場合、URL を手動で入力し、Header（リクエストヘッダー）を一つずつ追加し、JSON リクエストボディを組み立てる必要があります。
|
||||
|
||||
AI に次のように指示するだけです：
|
||||
> "このインターフェース文書を Postman にインポートできる形式に変換してください。正常なリクエストとエラーリクエストの例を含めてください。"
|
||||
|
||||
JSON テキストを取得したら、`menu_api.json` として保存し、Postman にドラッグするだけで、すぐに使えるテストパネルが手に入ります。
|
||||
|
||||
## 5.2 自動化ユニットテストの作成
|
||||
より厳密なエンジニアリング品質を追求する場合は、大規模言語モデルに `Jest` などのテストフレームワークを使ってユニットテスト（Unit Tests）を作成させ、コアビジネスロジックの境界テスト（例えば、負の価格が渡された場合、データベース層のバリデーションが有効に機能するかなど）を行うことができます。
|
||||
|
||||
---
|
||||
|
||||
# 6. バックエンドインターフェース開発者が知っておくべきベストプラクティス
|
||||
|
||||
AI の支援があっても、システム全体の「ゲートキーパー」として、以下のコア原則を理解し、レビューする必要があります：
|
||||
|
||||
1. **RESTful に準拠したパス命名**：
|
||||
- 良い設計：`GET /api/users`（ユーザー一覧の取得）、`POST /api/users`（ユーザーの作成）。URL は「リソース」を表す名詞であるべきです。
|
||||
- 悪い設計：`POST /api/getUser` や `POST /api/createUser`。動詞は HTTP メソッド（GET/POST/PUT/DELETE）で表現するべきです。
|
||||
2. **標準的な HTTP ステータスコードの使用**：
|
||||
- 200/201：リクエスト成功 / リソース作成成功。
|
||||
- 400：Bad Request。フロントエンドのパラメータ形式エラー、必須項目の不足。
|
||||
- 401/403：Unauthorized / Forbidden。ユーザーがログインしていない、または操作権限がない。
|
||||
- 404：Not Found。リソースが存在しない。
|
||||
- 500：Server Error。バックエンドコードのエラーやデータベースの障害。エラーのコールスタックをフロントエンドに直接露出させることは絶対に避けてください（セキュリティ上のリスクがあります）。
|
||||
3. **ユーザーの入力を決して信用しない**：フロントエンドからの入力は偽造されている可能性があります。すべてのコアパラメータの検証は、バックエンドインターフェースでも改めて行う必要があります。
|
||||
|
||||
# 7. まとめ
|
||||
|
||||
この章の学習を通じて、あなたは開発の視点を真の意味で転換させました。もはや構文や句読点に囚われた「タイピスト」ではなく、**システムデザイナー兼アーキテクチャ指揮官**へと昇華したのです。
|
||||
あなたは以下のことを習得しました：
|
||||
1. **API インターフェースとフロントエンド・バックエンド分離**というコアシステム思考。
|
||||
2. **コンテキストの提供と階層構造の概念**を通じて、大規模言語モデルが生成するサーバーサイドコードの品質を大幅に向上させる方法。
|
||||
3. 煩雑な**文書作成**や**テストケースの構築**を、AI が得意とする自動化タスクに巧みに転換する方法。
|
||||
4. これまでに学んだ **Supabase** の知識と組み合わせ、クライアントのリクエストからデータベースの更新に至るまでの完全なデータフローを貫通させたこと。
|
||||
|
||||
::: tip 💡 次のステップ
|
||||
データフローとバックエンドサービスの準備が整った後も、現状ではローカルコンピューター上でのみ動作する状態です。次の章では、苦労して構築したサービスを**パブリックネットワークのサーバーにデプロイ（Deploy）**する方法を学び、世界中のユーザーがあなたの製品にアクセスできるようにします。
|
||||
:::
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,261 @@
|
||||
# GitとGitHubワークフロー
|
||||
|
||||
前のコースでは、Webベースのvibe codingツールを使ってコードを書く方法を学びました。毎回の対話で新しいバージョンのコードが作成されます。しかし、一つ考えてみましょう：以前の修正に戻りたい場合、便利な方法はあるでしょうか？異なる段階のコードを記録し、いつでも異なるバージョン間で切り替えや修正ができるツールはあるでしょうか？
|
||||
|
||||
このニーズを満たすために、バージョン管理ソフトウェアが誕生しました。本記事では、最も有名なバージョン管理プログラム——Git——と、最も優れたコードホスティングプラットフォーム——GitHub——を紹介します。Gitを使ったコード管理、GitHubから他人のコードの取得、自分のコードのアップロード、そして他の人との協業による大規模プロジェクトの進め方を学びます。
|
||||
|
||||
個人プロジェクトのバージョン追跡、チーム協業でのコード同期、オープンソースコミュニティへの貢献のいずれにおいても、GitとGitHubはモダンな開発者にとって必須のツールです。これらをマスターすることで、コードをより効率的に管理し、必要に応じてチェックポイントを作成し、コードの異なる段階間を自由に切り替え、単一ファイルの変更から大規模プロジェクトの開発まで、すべてを簡単に処理できるようになります——コードの毎回のイテレーションを管理可能かつトレース可能にします。
|
||||
|
||||
> 💡 **前提知識**
|
||||
>
|
||||
> Gitを学ぶ前に、以下の概念を先に理解しておくことをお勧めします：
|
||||
> - [ターミナル/コマンドラインとは](/ja-jp/appendix/2-development-tools/command-line-shell) - コマンドラインを使ったコンピュータとのやり取りを学ぶ
|
||||
> - [Gitとは](/ja-jp/appendix/2-development-tools/git-version-control) - Gitバージョン管理システムの核心概念を理解
|
||||
>
|
||||
> 本記事ではGitHubワークフローと実際の操作に焦点を当て、上記の基礎知識については付録のリンクを参照してください。
|
||||
|
||||
# Gitクイックスタート
|
||||
|
||||
Gitを使い始める前に、付録の[コマンドライン](/ja-jp/appendix/2-development-tools/command-line-shell)と[Git基礎](/ja-jp/appendix/2-development-tools/git-version-control)の内容をすでに読んでいることを確認してください。本記事はこれらの基礎知識があることを前提に、Gitのインストール・設定とGitHubを使った協業の方法を直接説明します。
|
||||
|
||||
## Gitのインストール方法
|
||||
|
||||
異なるコンピュータのオペレーティングシステムにGitをインストールする3つの方法をデモします。自分のシステムバージョンに応じて手順に従ってください：
|
||||
|
||||
### Windows
|
||||
|
||||
1. [Git公式ダウンロードページ](https://git-scm.com/download/win)にアクセスし、自分のシステムに合ったインストーラーをダウンロード：[インストーラー](https://github.com/git-for-windows/git/releases/download/v2.51.0.windows.1/Git-2.51.0-64-bit.exe)。デフォルトではx64インストーラーの使用を推奨。
|
||||
2. インストーラーをダブルクリックし、インストールウィザードの指示に従う：
|
||||
|
||||
1. デフォルトのオプションを維持することをお勧めします。カスタマイズが必要な場合は以下に注意：（ほとんどの場合、「Next」をクリックし続ければ問題ありません）
|
||||
- Gitが使用するデフォルトエディタを選択：お好みのエディタ（例：VS Code）を選択。最初のオプションであるVim（テキストエディタ）をデフォルトとして選択するか、「Visual Studio Code as Git's default editor」オプション（VS Codeの事前インストールが必要）を選択できます。デフォルトのまま「Next」をクリックして続行できます。
|
||||
|
||||
- Gitの使用方法を選択：これら3つのオプションは、システム内でのGitのアクセシビリティを制御します。オプション2（"from command line and 3rd-party software"）の選択をお勧めします——基本的なGitツールをPATHに追加し、Git Bash、コマンドプロンプト、PowerShell、IDEでGitを使用できるようにしますが、システムを汚しません。
|
||||
|
||||
|
||||
3. インストール後、デスクトップで右クリック。メニューに「Git Bash Here」が表示されていれば、インストール成功です。
|
||||
|
||||
|
||||
|
||||
### MacOS
|
||||
|
||||
macOSの場合、まずターミナルで`git --version`と入力して、Gitがすでにインストールされているか確認できます。インストールされていない場合、インストールを促すメッセージが表示されます——指示に従ってインストールを完了してください。
|
||||
|
||||
1. 方法1：Homebrewでインストール
|
||||
[Homebrew](https://brew.sh/)（Macパッケージマネージャー）がインストールされている場合、ターミナルを開いて以下を入力
|
||||
```bash
|
||||
brew install git
|
||||
```
|
||||
2. 方法2：（推奨）Xcodeでインストール： https://developer.apple.com/xcode/ 、XcodeにはGitが内蔵されています。インストール後、指示に従って続行してください。
|
||||
|
||||
### Linux
|
||||
|
||||
ほとんどのLinuxディストリビューションはパッケージマネージャーでGitをインストールできます：
|
||||
|
||||
- Ubuntu/Debian:
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install git
|
||||
```
|
||||
|
||||
- CentOS/RHEL:
|
||||
|
||||
```bash
|
||||
sudo yum install git
|
||||
```
|
||||
|
||||
- インストールの確認：ターミナルでgit --versionと入力。バージョン番号が表示されればインストール成功です。
|
||||
|
||||
## Gitの初期化
|
||||
|
||||
Gitをインストールした後、まずユーザー情報を設定する必要があります——これはGitを使ったバージョン管理の基本ステップです。ターミナルで以下のコマンドを実行してください（括弧内の内容は自分の情報に置き換えてください）：
|
||||
|
||||
```bash
|
||||
# グローバルユーザー名を設定（コミット記録に表示される）
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
# グローバルメールアドレスを設定（GitHub/GitLabなどのプラットフォームで登録したメールアドレスの使用を推奨）
|
||||
git config --global user.email "your.email@example.com"
|
||||
```
|
||||
|
||||
Gitはこの情報を各コミット記録に組み込み、毎回の修正の「作者情報」として使用します。バージョン履歴（例：git logを使用）を確認する際、誰がどの行のコードを修正したかが明確にわかり、責任の追跡とコミュニケーションに便利です。協業プロジェクトでは、統一されたID情報により、チームメンバーが誰がどの変更を行ったかを迅速に特定でき、協業効率が向上します（例：コミット記録から関連する開発者を見つけて問題を議論するなど）。
|
||||
|
||||
コマンドラインで`git config --list`と入力することで、現在のGit設定情報を確認し、設定が成功したか確認できます。
|
||||
|
||||
# GitHubとは
|
||||
|
||||
GitHubはGitベースのコードホスティングプラットフォームです。Gitリポジトリのリモートストレージを提供するだけでなく、協業ツール（Issues、Pull Requests、Projectsなど）も含み、開発者がコードを共有し協業しやすくします。簡単に言えば、Gitはローカルバージョン管理ツールであり、GitHubはリモートの「コードリポジトリクラウド + 協業コミュニティ」です。
|
||||
|
||||
GitHubは世界最大のコードホスティングプラットフォームであるだけでなく、世界で最も活発で影響力のあるオープンソースコミュニティです。ここでの「オープンソース」の核心的な考え方は、誰でもソフトウェアのソースコードをダウンロードして実行できるということです。このモデルにより、世界中の人々が互いのコードを検査して修正したり、それに基づいて新しいプロジェクトを作成したりできます。例えば、GitHubで各種学習チュートリアルや、GPTモデルのトレーニングに使用されるフレームワーク（PyTorchなど）の完全なソースコードを見つけることができます。毎日、世界中で無数の人がコードをレビューし改善するために協業しています。
|
||||
|
||||
|
||||
|
||||
多くの大企業がGitHubでプログラムやチュートリアルをオープンソース化し、業界での競争優位性を得ています——これは一種の広告形態とも言えます。GitHubコミュニティでは、プロジェクトが獲得した「スター（stars）」の数がその価値を測る主な指標であり、プロジェクトや組織が持つスターが多いほど、その信頼性と影響力が大きくなります。
|
||||
|
||||
|
||||
|
||||
本コースでは、サポートリソースや課題も専用のGitHubリポジトリにアップロードされます。課題のアップロードプロセスを通じて、GitHubの使用に徐々に慣れ親しみマスターし、将来のアプリケーション開発におけるバージョン管理の基盤を築きます。
|
||||
|
||||
## GitHubアカウントの登録
|
||||
|
||||
1. [GitHub公式サイト](https://github.com/)にアクセスし、右上の「Sign up」をクリック。
|
||||
|
||||
2. メールアドレスを入力（検証や通知がそこに送信されるため、常用メールの使用を推奨）、パスワードを設定（文字、数字、特殊文字を含める必要があります）。
|
||||
3. 人工検証を完了し、指示に従ってメールを検証すれば、アカウントの作成完了です。
|
||||
|
||||
## GitHubで最初のリポジトリを作成
|
||||
|
||||
次に、最初の保存フォルダー、すなわちリポジトリまたは「repo」を作成します。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. Repository name：他人に表示されるリポジトリ名。
|
||||
2. Description：リポジトリの詳細な説明。
|
||||
3. Choose visibility：個人リポジトリの場合、privateに設定すると、自分と特別に招待された人のみが閲覧可能。publicに設定すると、誰でも閲覧可能。
|
||||
組織内のリポジトリの場合、Privateにすると組織内の人のみが閲覧可能。
|
||||
Publicにすると組織外の人も閲覧可能。
|
||||
4. README：一般的に、すべてのリポジトリにREADMEファイルがあることが推奨されます。これはリポジトリの完全な紹介と考えられ、使用説明、ファイルリスト、操作方法などが含まれます。
|
||||
5. Add .gitignore and license：
|
||||
1. .gitignoreファイルは、GitにGitHubへのアップロード時に特定のフォルダやファイルを無視するよう指示し、それらが追跡やステージングエリアに追加されないようにします。これは一時テストファイル、依存パッケージ、大きなファイルに便利です。指定すると、これらのファイルは追跡されなくなります。
|
||||
2. licenseは、選択するオープンソースライセンスのタイプを指します。異なるライセンスは、他人があなたのコードを商用目的で使用できるかどうかなどを詳細に規定し、他の条項や条件も含みます。
|
||||
|
||||
「Add README」にチェックを入れ、リポジトリの可視性を「Private」に設定し、リポジトリ名と説明をお好みで入力してから「Create repository」をクリックして最初のリモートリポジトリの作成を完了することをお勧めします。
|
||||
|
||||
|
||||
|
||||
その後、余分なファイルのないクリーンなリポジトリが手に入ります。次にファイルのアップロードを始められます。
|
||||
|
||||
|
||||
|
||||
リポジトリを取得するコマンドは`git clone`ですが、リポジトリのアドレスが必要です。緑色の「Code」ボタンをクリックしてリポジトリのアドレスを見つけられます。HTTPSとSSHのオプションが表示されます。通常、どちらの方法でもリポジトリをローカルマシンにダウンロードできます（そうして初めてファイルの修正とアップロードが可能になります）。
|
||||
|
||||
|
||||
|
||||
一般的に、HTTPでクローンしたリポジトリは他人のリポジトリを一時的にダウンロードしてテストするのに適していますが、自分の開発にはお勧めしません。より良い学習体験のために、まずSSH認証を設定してください。
|
||||
|
||||
## ローカルSSHのバインド
|
||||
|
||||
GitHubにおける「SSHプロトコルバインド」とは、本質的にローカルデバイスのSSH公開鍵をGitHubアカウントに関連付け、GitHubがSSHプロトコルを通じてデバイスを識別できるようにすることです。これにより、パスワードなしでリモートリポジトリを安全に操作（clone、push、pullコードなど）できるようになります。
|
||||
|
||||
簡単に言えば：これはデバイスに「GitHub専用のセキュリティカード」を与えるようなものです。バインド後、デバイスがSSHプロトコルでGitHubリポジトリにアクセスする際、GitHubはこの「セキュリティカード」（あなたのSSH公開鍵）を検証します。あなたの認可されたデバイスであることが確認されれば、直接操作できます——毎回アカウントのパスワードを入力する必要はありません。
|
||||
|
||||
> 💡 SSHとは
|
||||
|
||||
### なぜSSHプロトコルのバインドが必要なのか？
|
||||
|
||||
GitHubは主に2つのリポジトリ操作プロトコルをサポートしています：HTTPSプロトコルとSSHプロトコル：
|
||||
|
||||
- HTTPSプロトコル：毎回の操作（pushなど）でGitHubのアカウントパスワード（またはPersonal Access Token）の入力が必要。検証プロセスが煩雑で、パスワード漏洩のリスクもあります。
|
||||
- SSHプロトコル：認証は「鍵ペア」で完了するため、パスワードの繰り返し入力が不要で、暗号化転送もより安全です。
|
||||
|
||||
「SSHプロトコルバインド」はGitHubのSSH認証を有効にするための前提ステップです——ローカルのSSH公開鍵をGitHubアカウントに「バインド」して初めて、GitHubはあなたのデバイスを識別し、リポジトリのSSH操作を許可します。
|
||||
|
||||
### 「バインド」の核心的なロジック：SSH鍵ペアの役割
|
||||
|
||||
SSH認証は鍵ペア（公開鍵 + 秘密鍵）に依存しており、これらは一致する暗号化ファイルです。生成後、「公開鍵」をGitHubに提供（「バインド」）し、「秘密鍵」はローカルデバイスに残します：
|
||||
|
||||
1. 秘密鍵：ローカルデバイス（PCなど）の指定されたディレクトリ（通常は~/.ssh/）に保存され、「あなた専用の鍵」として機能し、誰とも共有してはいけません。
|
||||
2. 公開鍵：これは公開して共有できる「鍵」です——GitHubアカウントの「SSH keys list」にコピー（「バインド」操作）する必要があります。
|
||||
|
||||
SSHでGitHubリポジトリを操作する際（例：git push git@github.com:xxx/xxx.git）：
|
||||
|
||||
- ローカルデバイスが秘密鍵を使って「操作リクエスト」を暗号化しGitHubに送信；
|
||||
- リクエストを受信したGitHubは、以前にバインドした公開鍵を使って復号を試みる；
|
||||
- 復号が成功すれば、デバイスは認可されたものとして確認され、操作が許可される。そうでない場合、アクセスは拒否されます。
|
||||
|
||||
### 「バインド」の具体的な手順（核心的なフロー）
|
||||
|
||||
原理を理解すれば、実際の操作はシンプルです——核心は「鍵ペアの生成 → 公開鍵のGitHubへのアップロード」です：
|
||||
|
||||
1. ローカルでSSH鍵ペアを生成
|
||||
1. Traeを使って公開鍵を取得（推奨）
|
||||
プロンプト：`Help me create the SSH key needed for GitHub login. My email is your_email@gmail.com , Please return the public key for me to copy`
|
||||
|
||||
|
||||
|
||||
プロンプトを入力した後、左側のターミナルでEnterキーを押す必要があります。そうしないとコマンドが待機状態のままになります。Traeは条件判断を実行できないため、ひたすらEnterを押し続けるだけで問題ありません。
|
||||
|
||||
最終的に、右側のTraeが読み取った公開鍵が返されます。それをコピーし、次のステップで貼り付ける準備をしてください。
|
||||
|
||||
 2. 手動で公開鍵を取得
|
||||
ローカルのターミナルを開き（WindowsではGit BashまたはPowerShell、macOS/Linuxではターミナル）、以下のコマンドを入力（your_email@example.comをGitHubアカウント登録時に使用したメールアドレスに置き換えてください）：
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
```
|
||||
|
||||
1. Enterを押してデフォルト値を受け入れる（デフォルトのファイルパス、パスワードなし、または必要に応じてパスワードを設定）。これで~/.ssh/ディレクトリに2つのファイルが生成されます：
|
||||
- id_ed25519：秘密鍵（ローカルに保存、**絶対に共有しない**）；
|
||||
- id_ed25519.pub：公開鍵（GitHubにアップロードが必要）。
|
||||
|
||||
2. 公開鍵をGitHubアカウントに「バインド」
|
||||
|
||||
これが核心的なバインドステップです——ローカルの公開鍵をGitHubアカウントの「SSH keys list」に追加：
|
||||
|
||||
1. 公開鍵の内容をコピー：
|
||||
1. Trae：
|
||||
2. Windows：メモ帳でC:\Users\<your>\.ssh\id_ed25519.pubを開き、全内容をコピー；
|
||||
3. macOS/Linux：ターミナルでcat ~/.ssh/id_ed25519.pubを実行し、全出力をコピー（先頭のSSH-ed25519から末尾のメールアドレスまで）。
|
||||
2. GitHubにログインし「SSH Key Management」ページに進む：
|
||||
1. 右上のアバターをクリック → Settings → 左側のメニューSSH and GPG keys → New SSH keyをクリック。
|
||||
|
||||
2. 任意のタイトルを入力（例：your local computer's SSH）し、取得したSSH公開鍵をここに貼り付け。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. バインドの成功を確認
|
||||
|
||||
ターミナルで以下のコマンドを入力（**Traeでも以下の操作が可能**）して、GitHubがデバイスを識別できるかテスト：
|
||||
|
||||
```bash
|
||||
ssh -T git@github.com
|
||||
```
|
||||
|
||||
- Hi [your GitHub username]! You've successfully authenticated...のような内容が表示されれば、鍵のバインドは成功；
|
||||
- エラーが発生した場合、通常は公開鍵のコピーが不完全、秘密鍵の権限が高すぎる（ローカルの~/.ssh/ディレクトリは自分のみが読み書き可能にすべき）などが原因です。必要に応じてこれらの問題を確認してください。
|
||||
|
||||
### 重要な注意事項
|
||||
|
||||
複数のデバイス（ノートPCやデスクトップなど）を持っている場合、各デバイスに対して個別のSSH鍵ペアを生成し、各公開鍵を同じGitHubアカウントにバインドする必要があります——各デバイスには独自の「セキュリティカード」があります。
|
||||
|
||||
秘密鍵を共有しないでください（GitHubにアップロードしたり他人と共有しない）。そうしないと、誰かがあなたになりすましてリポジトリを操作する可能性があります。秘密鍵が漏洩した場合は、GitHubから対応する公開鍵を直ちに削除し、新しい鍵ペアを生成してください。
|
||||
|
||||
SSHをバインドした後、操作にはSSH形式のリポジトリアドレス（例：git@github.com:username/repository.git）を使用し、HTTPS形式（例：https://github.com/username/repository.git）は使用しないでください。以前にHTTPSでリポジトリをクローンした場合は、git remote set-url origin `<new>`でプロトコルを切り替えられます。
|
||||
|
||||
# TraeでGitHub操作を行う
|
||||
|
||||
Gitとは何か、GitHubとは何か、SSHとは何か、そしてその設定方法について説明しました。これでTraeを使って自由にGit操作を行えます。まず、リモートリポジトリをローカルマシンにクローンする方法を学びましょう。
|
||||
|
||||
## Git clone：既存のリポジトリをダウンロード
|
||||
|
||||
クローンしたいリポジトリのアドレスを直接伝えることができます
|
||||
|
||||
|
||||
|
||||
## Git pull：リモートリポジトリから更新を取得
|
||||
|
||||
リポジトリを更新する前に、複数人でメンテナンスされている可能性があるため、まず最新の変更をプルする必要があります。その後、ファイルを修正してプッシュできます。
|
||||
|
||||
**間違ったリポジトリにプッシュしないよう、フォルダ名とその相対パスまたは絶対パスを必ず含めてください。**
|
||||
|
||||
prompt:`Help me pull this repository AIID-TEST in ./AIID-TEST.`
|
||||
|
||||
## Git commit & Git push：更新をステージしてGitHubにプッシュ
|
||||
|
||||
すべての準備が整ったら、ローカルファイルの修正、フォルダ内のアイテムの追加や削除を試みてください。その後、Traeに変更を検出させ、GitHubへのプッシュを支援させます。
|
||||
|
||||
prompt:`I finished. Commit and push to the repository AIID-TEST in ./AIID-TEST.`
|
||||
|
||||
|
||||
|
||||
プッシュ成功。これでGitHubで更新された内容を確認できます。
|
||||
|
||||
# 参考資料
|
||||
|
||||
- Pro Git book https://git-scm.com/book/en/v2
|
||||
- GitHub Docs https://docs.github.com/en
|
||||
@@ -0,0 +1,801 @@
|
||||
# CLI AI プログラミングツール
|
||||
|
||||
本チュートリアルでは、コマンドライン上で直接動作する AI プログラミング Agent を紹介します。これまで学んだ Trae や Cursor に組み込まれた Agent とは異なり、CLI AI プログラミングツールはターミナル上でのみ使用します。AI IDE 内蔵の Agent と比べて、より長いコンテキストウィンドウ、より高速なツール呼び出し、そしてより多くの種類の大規模モデルとの互換性を備えています。最新の AI Vibe Coding の実践では、IDE 内蔵のコーディング Agent よりも CLI AI プログラミングツールを優先して使用することが多くなっています。
|
||||
|
||||
## CLI とは
|
||||
|
||||
以前のチュートリアルで CLI について紹介しましたね。CLI とは、ターミナルやコマンドプロンプトを通じて、グラフィカルインターフェース（GUI——ボタンがあってクリック操作ができる、コマンドを入力する必要のない画面と理解して構いません）に頼らず、純粋なテキストコマンドでソフトウェアを操作する仕組みです。
|
||||
|
||||
> Windows では、代表的なターミナルとして「コマンドプロンプト（cmd）」と「PowerShell」があります。PC の「ファイル名を指定して実行」や検索ボックスに「cmd」または「powershell」と入力することで、これらのコマンドラインプログラムを起動できます。
|
||||
|
||||
|
||||
|
||||
CLI は元来テキストコマンドの操作に適しており、一部のギーク（極限まで追求するプログラミング愛好家）の間では、CLI の方が GUI よりも好まれることすらあります——彼らはすべての操作をキーボードで完了させたいと考えており、マウスを使うとかえってコーディング効率が下がると感じています。
|
||||
|
||||
業界においても、CLI は最も一般的なインターフェース形式の一つです。なぜなら、GUI は OS に追加で画面を描画し、ウィンドウを管理する必要があるため、コンピュータリソースの要求が高くなります。一方 CLI は、受け取ったコマンドをシステムに渡して実行するだけで済みます。そのため、大規模なサーバークラスタに接続する際、通常は CLI でのみやり取りを行います。
|
||||
|
||||
|
||||
|
||||
CLI の経験がない方にとっては、CLI の操作は複雑でコマンドが多すぎると感じたり、「間違えたら PC が壊れてしまうのではないか」と心配したりするかもしれません。心配は不要です。以前のチュートリアルで、Trae に様々な基本操作を手伝ってもらったことを思い出してください。ここでも全く同じ考え方が使えます——CLI プログラミングツールにすべての CLI 操作を代行させることができます。指定したフォルダへの移動、ファイルの検索や処理、オープンソースプロジェクトの実行やコピーなどを、すべて CLI AI プログラミングツールとの対話を通じて完了できます。
|
||||
|
||||
## AI IDE との違い
|
||||
|
||||
CLI AI プログラミングツールは、以前学んだ z.ai や Trae に例えることができます。ある意味で、CLI AI プログラミングツールは特殊な z.ai と見なすことができます。どちらもシンプルな対話の入口だけで、必要なすべての操作を自動的に実行してくれます（ただし、最終的な結果を確認するために手動でブラウザを開く必要がある場合があります）。また、AI IDE に例えるなら、CLI AI プログラミングツールは IDE 内の Agent モジュール——つまり、サイドバーにある対話エリアに相当します。
|
||||
|
||||
|
||||
|
||||
ただし、AI IDE によって Agent の実装方法が異なり、能力差も大きいため、AI プログラミングの効果は安定しにくい傾向があります。そのため、CLI AI プログラミングツールは通常、Claude を開発した Anthropic や ChatGPT を開発した OpenAI などの大手テック企業によって直接開発されています。
|
||||
|
||||
他の AI プログラミング Agent と比べ、これらの大企業製品を直接利用する方が優れた実践となることが多いです。特に Claude Code は、もともと Anthropic の内部開発チーム向けのツールであり、「エンジニアの実際のニーズを満たす」という観点から設計されています。
|
||||
|
||||
より直感的に比較するため、Claude Code とある AI IDE Agent（ここでは Cursor を例にします）の違いを見てみましょう。
|
||||
|
||||
| 機能特性 | Claude Code | Cursor | 優位性 |
|
||||
| ----------------- | ------------- | --------------- | ----------- |
|
||||
| 自動タスク実行 | ✅ 非常に強い | ❌ 能力限定 | Claude Code |
|
||||
| IDE 統合 | ❌ コマンドラインのみ | ✅ ネイティブ VS Code | Cursor |
|
||||
| リアルタイムコード補完 | ❌ なし | ✅ 優れた体験 | Cursor |
|
||||
| 複数ファイル操作 | ✅ 非常に強い | ⚠️ 悪くない | Claude Code |
|
||||
| GitHub 統合操作 | ✅ 直接コミット可能 | ⚠️ 手動操作が必要 | Claude Code |
|
||||
| 学習コスト | ⚠️ 中程度 | ✅ 簡単に始められる | Cursor |
|
||||
| コンテキスト長 | ✅ 非常に長い | ⚠️ まずまず | Claude Code |
|
||||
| デバッグ支援 | ✅ 自動化 | ⚠️ 手動作業が多い | Claude Code |
|
||||
|
||||
表の出典：<https://northflank.com/blog/claude-code-vs-cursor-comparison>
|
||||
|
||||
端的に言えば、CLI AI プログラミングツールは一般的に以下のことが可能です。
|
||||
|
||||
- より長時間の連続対話をサポート（「一日中作業」を手伝うことすら可能）。
|
||||
- より長いコンテキストウィンドウを提供（「続けて」と頻繁に言う必要がなくなる）。
|
||||
- より高速な応答速度（より多くのカスタムモデル API に接続可能）。
|
||||
|
||||
コーディング関連の操作において、これらは大半の IDE 内蔵 Agent よりも賢く、安定しています。
|
||||
|
||||
## 代表的な CLI AI プログラミングツール
|
||||
|
||||
現在、多くのオープンソース実装がありますが、実践においては 2 つのタイプの CLI AI プログラミングツールを「おすすめの組み合わせ」としてお勧めします。ご自身の好みに合わせてどちらかを選択してください。両方試した上で、最も適したものを選ぶことを強くお勧めします。
|
||||
|
||||
- Codex は GPT-5 を使用し、総合力がより高い。
|
||||
- Claude Code は GLM 4.6 を経由した API 転送で、全体的な体験は Claude 4 に近いが、価格はより安い。
|
||||
- OpenCode はモデルを自由に切り替えて組み合わせることができ、無料モデルも提供されており、コストをより良くコントロールできる。
|
||||
|
||||
ただし、実際のプロジェクトでどれが使いやすいかは、実際に試してみなければ判断できません。複数の AI プログラミングツールを使いこなすことは常に有益です。慣れてくれば、場面に応じて Claude Code、Codex、Trae を柔軟に切り替えることができます。あるツールの効果がいま一つだと感じたら、別のツールやモデルに切り替えて試行を続ければよいのです。
|
||||
|
||||
また、モデルのバージョンアップは非常に速いため、「コストパフォーマンス（効果 / コスト）」の面で最も優れた方案を優先して選ぶことをお勧めします。
|
||||
|
||||
### Claude Code
|
||||
|
||||
Claude Code は、Anthropic が Claude 大規模モデルの能力を基に開発した AI プログラミングツールです。主な利用シーンはターミナルですが、VS Code の拡張機能としても使用できます。AI IDE の Agent と同様に、開発者のコードリポジトリを深く理解し、自然言語の指示によりエンドツーエンドの開発タスクを完了できます。コードの編集、バグ修正、テストの実行と修正、Git ワークフローの管理（マージコンフリクトの解決や PR の作成など）、複雑なコードの解説、ターミナルコマンドの実行などが含まれます。
|
||||
|
||||
|
||||
|
||||
Claude Code の強みは主に以下の点にあります。極めて長いコンテキストウィンドウ（ファイル全体や小規模プロジェクトの処理が可能）、曖昧な要件を自ら確認し、タスクを自動的に計画・分配する能力、そしてコードベース全体の内容を深く理解し説明する能力です。一般的な IDE Agent と比べ、「没入型 vibe coding」の開発プロセスにより適しています。
|
||||
|
||||
実際の使用では、対話による指示を通じて、新しいプロジェクトの作成、CLI 操作の実行（フォルダの整理、ファイルの一括リネーム、オープンソースプロジェクトのデプロイなど）、開発環境の構築（Python 環境のインストールやデバッグなど）を依頼できます。あるコードが理解しにくい場合や、ディレクトリ構造が不明確な場合も、Claude Code に構造化された分析ドキュメントを生成させたり、特定の内容をステップごとに解説させたりすることができます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Claude Code を体系的に学びたい場合は、Andrew Ng と Anthropic が共同で提供しているコースを参照してください。
|
||||
<https://www.bilibili.com/video/BV176t2zSEpr>
|
||||
|
||||
それでは、Claude Code の使い方を学びましょう。公式の Claude Code を直接使用するとコストが非常に高くなるため（下図参照）、Claude Code のプロトコルと互換性がありながら、他の大規模モデルの API プラットフォームを基にした方案を使用します。
|
||||
|
||||
|
||||
|
||||
以下のいくつかの異なる方案を学ぶ必要があります（できればすべて試してください）。最後に、最も適したものをメインの実践パスとして選んでください。
|
||||
|
||||
1つ目の方法は、「Anthropic インターフェース互換」の API を直接使用することです。Claude Code の普及に伴い、越来越多の大規模モデルサービス事業者が Anthropic 形式の呼び出し方法をサポートし始めています。代表的なサービス事業者には GLM、Kimi、DeepSeek、Siliconflow などがあり、いずれも互換 API インターフェースを提供しています。具体的な設定については後で詳しく説明します。
|
||||
|
||||
なお、Claude Code は通常大量のトークンを消費するため、API 呼び出しによる高額な費用を懸念される場合は、GLM の月額プラン（約 20 元/月）の購入を検討するとコストを抑えられます。実際の使用料を先に確認したい場合は、10 元をチャージして小規模なテストを行うのも良いでしょう。
|
||||
|
||||
もう1つの方法は、「Claude Code Router」プロジェクトを使用することです。これはオープンソースツールであり、一般的なすべての API 呼び出しインターフェースをサポートするだけでなく、場面に応じて使用するモデルをきめ細かく設定でき、ローカルにデプロイされた大規模モデルとの接続も可能です。ただし、この方案の設定は比較的複雑なため、まずは1つ目の方案から始めることをお勧めします。
|
||||
|
||||
#### 智譜 GLM をバックエンドとして使用する（推奨）
|
||||
|
||||
GLM（General Language Model）は、智譜 AI が独自に開発した大型言語モデルシリーズです。GLM-4.6 は現在の GLM シリーズの最新バージョンであり、コード能力における優れたパフォーマンスが最大のハイライトです（公開ベンチマークと実際のタスクにおいて Claude Sonnet 4 と同等レベルであり、国内ではトップクラスに位置しています）。
|
||||
|
||||
|
||||
|
||||
また、コンテキストウィンドウを 200K に拡張し、長文や大規模なコードをより余裕を持って処理できるようになりました。推論とツール呼び出しの能力も強化され、パフォーマンスとコストのバランスも良好です。
|
||||
|
||||
|
||||
|
||||
GLM に接続する前に、まず Claude Code をインストールする必要があります。
|
||||
|
||||
コマンドラインでのインストール手順が煩わしいと感じる場合や、途中でエラーが発生した場合は、Trae の Agent にインストールを手伝わせることができます。
|
||||
|
||||
```python
|
||||
# Claude Code のインストール
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
|
||||
# プロジェクトに移動
|
||||
cd your-awesome-project
|
||||
|
||||
# Claude Code の起動
|
||||
claude
|
||||
|
||||
# Ctrl+C で Claude を終了
|
||||
```
|
||||
|
||||
次に、Claude Code のデフォルトの API リクエスト先を変更し、GLM の API サービスに対応させる必要があります。以下の内容をコピーして、Trae に対応する環境変数の作成を依頼できます。または、システム環境変数に永続的に書き込むことも選択できます（問題が発生した場合も、Agent に修正を依頼できます）。
|
||||
|
||||
まず、GLM の API Key を取得し、ご自身にとって最も便利な方法で保管してください。
|
||||
|
||||
国内版 URL：<https://bigmodel.cn/usercenter/proj-mgmt/apikeys>
|
||||
国際版 URL：<https://z.ai/manage-apikey/apikey-list>
|
||||
|
||||
**国内版 GLM** を使用する場合は、以下の環境変数を設定してください。
|
||||
|
||||
```python
|
||||
# Cmd で以下のコマンドを実行
|
||||
# `your_zhipu_api_key` を取得した API Key に置き換えてください
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zhipu_api_key
|
||||
setx ANTHROPIC_BASE_URL https://open.bigmodel.cn/api/anthropic
|
||||
```
|
||||
|
||||
**国際版 GLM** を使用する場合は、以下の設定を使用してください。
|
||||
|
||||
```python
|
||||
# Cmd で以下のコマンドを実行
|
||||
# `your_zai_api_key` も必ず置き換えてください
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zai_api_key
|
||||
setx ANTHROPIC_BASE_URL https://api.z.ai/api/anthropic
|
||||
```
|
||||
|
||||
Trae で以下のようなプロンプトを直接入力できます。
|
||||
|
||||
> **注意**：Trae を通じて「永続的な環境変数」を設定した場合、設定完了後に **必ず Trae を再起動してください**。再起動しないと、内蔵ターミナルの環境変数が更新されず、ログイン失敗やネットワーク接続エラーが発生する可能性があります。
|
||||
|
||||
```python
|
||||
Based on my environment variable settings:
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zai_api_key
|
||||
setx ANTHROPIC_BASE_URL https://api.z.ai/api/anthropic
|
||||
|
||||
and my key(Replace it with your own key):
|
||||
681fea485851d29060cc.13gfaendggaFOhb
|
||||
|
||||
please help me configure and start Claude Code
|
||||
```
|
||||
|
||||
以下のような出力が表示されます。
|
||||
|
||||
|
||||
|
||||
> **環境変数とは？**
|
||||
>
|
||||
> 環境変数は、本質的にはオペレーティングシステムに保存される「キーと値のペア」の設定情報であり、通常「変数名 = 具体的な値」という形式で存在します。ターミナルやシステム設定であらかじめ設定しておけば、プログラムはいつでもこれらの変数を読み取って関連情報を取得できます。環境変数はターミナルから直接書き込めるため、コード自体を変更する必要がありません。そのため、大規模モデルにアクセスするためのシークレットキーは、漏洩を防ぐために環境変数に保存するのが一般的です。プログラムは対応する環境変数を読み取るだけで、大規模モデルの呼び出しを完了できます。
|
||||
>
|
||||
> Windows システムでは、環境変数は大規模モデルのアクセスキーの保存以外にも、コマンドラインツールの「呼び出しパス」の保存によく使われます。
|
||||
>
|
||||
> ターミナル自体もプログラムです。ターミナルで外部プログラムを起動したい場合、例えばターミナルで `claude` と入力して Claude Code を起動するケースを考えます。`claude` と入力するだけで実行できるのは、ターミナルがシステムの環境変数を読み取り、その中の PATH 変数に Claude Code の実行ファイルが含まれるディレクトリが登録されているため、ターミナルが該当プログラムを見つけて実行できるからです（ターミナルにそのプログラムの絶対パスを貼り付けて Enter を押すのと同じです）。
|
||||
>
|
||||
> 代表的な環境変数は例えば `PATH=C:\Windows\system32;C:\Program Files\Python` のようになります。これにより、どのパスからでもシステム内のこれらのプログラムを実行できます。例えば、コマンドラインで直接 `python` と入力して Python インタープリタを起動できます。
|
||||
>
|
||||
> システムの現在の環境変数を確認したい場合は、Windows の検索で「環境変数」と入力し、「システム環境変数の編集」ウィンドウを開くと、すべての変数とその値が表示されます。一部の変数は大規模モデルのキーの保存に、一部はプログラムディレクトリの追加に使用されており、どのパスからでも呼び出せるようになっています。
|
||||
|
||||
これで、最新の GLM を使用した Claude Code 開発が可能になりました。以前のプロジェクトをもう一度実行したり、Trae ではうまく完了できなかったタスクに再挑戦したりして、体験の違いを比較してみてください。
|
||||
|
||||
何度も「やり直す」ことは時間の無駄ではありません——やり直すたびに、スキルはより確かなものになります。
|
||||
|
||||
GLM と全く同じ考え方で、Anthropic 互換形式をサポートする他のインターフェースにも簡単に接続できます。
|
||||
|
||||
#### Kimi K2 をバックエンドとして使用する（推奨）
|
||||
|
||||
Kimi K2 は月之暗面（Moonshot AI）が発表した次世代の大規模言語モデルであり、コードの理解と生成能力に優れています。Kimi K2 は超長コンテキストウィンドウ（最大 200K トークン）をサポートし、大規模なコードベースや複雑なプロジェクトを容易に処理できます。
|
||||
|
||||
**主な強み：**
|
||||
|
||||
- **超長コンテキスト**：200K コンテキストウィンドウをサポートし、プロジェクト全体のコードを一度に処理可能
|
||||
- **強力なコード能力**：コード生成、リファクタリング、デバッグにおいて優れたパフォーマンス
|
||||
- **中国語理解に優れる**：中国語のプログラミング要件の理解がより正確
|
||||
- **安定したツール呼び出し**：安定した関数呼び出しとツール使用をサポート
|
||||
|
||||
**API Key の取得：**
|
||||
|
||||
<https://platform.moonshot.cn/console/account> にアクセスして登録し、API Key を取得してください。
|
||||
|
||||
**設定方法：**
|
||||
|
||||
参考ドキュメント：<https://platform.moonshot.cn/docs/guide/agent-support>
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=sk-YOURKEY
|
||||
```
|
||||
|
||||
#### Minimax をバックエンドとして使用する（推奨）
|
||||
|
||||
Minimax は稀宇科技（MiniMax）が発表した次世代の大規模言語モデルであり、プログラミングタスクにおいて優れたパフォーマンスを発揮します。Minimax モデルは、優れた推論能力とコード生成品質で知られており、特に複雑なプログラミングシナリオに適しています。
|
||||
|
||||
**主な強み：**
|
||||
|
||||
- **強力な推論能力**：複雑な論理推論とコードアーキテクチャ設計において優れたパフォーマンス
|
||||
- **高品質なコード**：生成されるコードは構造が明確で読みやすい
|
||||
- **多言語サポート**：複数のプログラミング言語のコード生成と変換をサポート
|
||||
- **高速な応答**：API の応答速度が速く、高頻度呼び出しのシナリオに適している
|
||||
|
||||
**API Key の取得：**
|
||||
|
||||
<https://platform.minimax.io/> にアクセスして登録し、API Key を取得してください。
|
||||
|
||||
**設定方法：**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOUR_MINIMAX_API_KEY
|
||||
export ANTHROPIC_MODEL=MiniMax-M2.7
|
||||
```
|
||||
|
||||
#### DeepSeek をバックエンドとして使用する（推奨）
|
||||
|
||||
DeepSeek は深度求索が発表したオープンソースの大規模言語モデルであり、優れたコード能力と高いコストパフォーマンスで開発者に支持されています。DeepSeek Coder はプログラミングタスク向けに特化して最適化された学習が行われています。
|
||||
|
||||
**主な強み：**
|
||||
|
||||
- **優れたコード能力**：コード生成、コード理解、バグ修正において優れたパフォーマンス
|
||||
- **オープンソースでカスタマイズ可能**：モデルがオープンソースであり、要件に応じてファインチューニングが可能
|
||||
- **高いコストパフォーマンス**：API 価格が比較的低く、高頻度での利用に適している
|
||||
- **中国語サポートが良好**：中国語のプログラミングシナリオの理解が正確
|
||||
|
||||
**API Key の取得：**
|
||||
|
||||
<https://platform.deepseek.com/usage> にアクセスして登録し、API Key を取得してください。
|
||||
|
||||
**設定方法：**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOU_DEEPSEEK_API_KEY
|
||||
export API_TIMEOUT_MS=600000
|
||||
export ANTHROPIC_MODEL=deepseek-chat
|
||||
export ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat
|
||||
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
|
||||
```
|
||||
|
||||
#### 火山引擎 Coding Plan をバックエンドとして使用する（推奨）
|
||||
|
||||
火山引擎（Volcano Engine）は字節跳動（ByteDance）傘下のクラウドサービスプラットフォームで、エンタープライズグレードの AI モデルサービスを提供しています。火山引擎の Coding Plan はプログラミングシナリオ向けに特化して最適化されており、安定した効率的なコード生成能力を提供します。
|
||||
|
||||
**主な強み：**
|
||||
|
||||
- **エンタープライズグレードの安定性**：サービスレベル契約（SLA）を提供し、サービスの安定性を保証
|
||||
- **コードシナリオの最適化**：プログラミングタスク向けに特化して最適化
|
||||
- **豊富なモデル選択**：Doubao-pro、Doubao-lite など複数のモデルをサポート
|
||||
- **国内からの高速アクセス**：国内ノードにデプロイされており、アクセス速度が速い
|
||||
|
||||
**API Key の取得：**
|
||||
|
||||
<https://console.volcengine.com/ark/region:ark+cn-beijing/apiKey> にアクセスして登録し、API Key を取得してください。
|
||||
|
||||
**設定方法：**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://ark.volces.com/api/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOUR_VOLCANO_API_KEY
|
||||
export ANTHROPIC_MODEL=doubao-pro-32k
|
||||
```
|
||||
|
||||
#### その他の Anthropic 互換 API
|
||||
|
||||
Siliconflow：
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL="https://api.siliconflow.cn/"
|
||||
export ANTHROPIC_MODEL="moonshotai/Kimi-K2-Instruct-0905" # 必要なモデルに変更可能
|
||||
export ANTHROPIC_API_KEY="YOUR_SILICONCLOUD_API_KEY" # API Key を置き換えてください
|
||||
```
|
||||
|
||||
阿里雲 DashScope（Aliyuncs）：<https://help.aliyun.com/zh/model-studio/get-api-key>
|
||||
|
||||
```python
|
||||
export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/apps/anthropic"
|
||||
export ANTHROPIC_API_KEY="YOUR_DASHSCOPE_API_KEY"
|
||||
```
|
||||
|
||||
::: details Claude Code Router をバックエンドとして使用する（応用編）
|
||||
|
||||
上記では、GLM 公式 API を使って Claude Code の Anthropic インターフェースを置き換える方法を説明しました。次に、Claude Code Router というツールがどのように Claude Code をより多くのモデル API に適合させるのかを見てみましょう。
|
||||
|
||||
[Claude Code Router](https://github.com/musistudio/claude-code-router) は、Claude Code 専用に設計されたインテリジェントルーティング拡張ツールです。その主な役割は、ユーザーのニーズに応じて AI リクエストを異なるプラットフォーム上のモデルに振り分け、高度なカスタマイズを可能にすることです。OpenRouter、DeepSeek、Ollama、Gemini など数十のプラットフォームへの接続をサポートし、シナリオに応じてタスクを特定のモデル（例：GLM-4.5、Kimi-K2、Qwen3-Coder など）にルーティングすることもできます。例えば、バックグラウンドタスクを自動的にローカルの Ollama に任せてコストを節約し、長文や長いコードのタスクを Gemini-2.5-Pro に、コードの解説を DeepSeek に振り分けることができます。
|
||||
|
||||
|
||||
|
||||
このツールは、便利な UI/CLI 設定管理機能も提供し、「コンバーター（converter）」を通じて異なるプラットフォームの API 形式に適合させます。GitHub Actions などの自動化統合やカスタム拡張をサポートし、「単一のモデルではすべてのシナリオをカバーできない」問題や「プラットフォームの頻繁な切り替えが面倒」という課題を解決し、ユーザーがより柔軟かつ低コストで AI ツールを活用できるようにします。
|
||||
|
||||
|
||||
|
||||
Claude Code Router のインストール方法を簡単に説明します。大まかに以下のステップが必要です（これも Trae に実行させることができます）。
|
||||
|
||||
```markdown
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
npm install -g @musistudio/claude-code-router
|
||||
```
|
||||
|
||||
インストール完了後、ローカルで `ccr` コマンドが使用できることを確認してください。以下のような出力が表示されれば、インストールは成功しています。
|
||||
|
||||
|
||||
|
||||
次に、モデルの初期化と設定には 2 つの方法があります。
|
||||
|
||||
- CCR 内蔵の UI を使用し、ブラウザで提供される設定ページから操作する。
|
||||
- CCR のデフォルト設定ファイルを直接編集する（UI も本質的には設定ファイルを変更しているだけで、より直感的なインターフェースを提供しています）。
|
||||
|
||||
CCR UI を使用する場合、以下のような画面が表示されます。
|
||||
|
||||
|
||||
|
||||
「Add Provider」ボタンをクリックすると、以下の画面が表示されます。以下の操作が必要です。
|
||||
|
||||
1. Name にモデルプロバイダーの名前を入力。
|
||||
2. API Full URL にそのプロバイダーの OpenAI 互換インターフェースのアドレスを入力。
|
||||
3. API Key に対応するプラットフォームの API Key を入力。
|
||||
4. Models エリアにモデル名を入力し、「Add Model」をクリックして追加。
|
||||
5. 最後に「Save」をクリックして設定を保存。
|
||||
|
||||
（画面を下にスクロールすると多数の詳細オプションがありますが、今は無視して構いません。）
|
||||
|
||||
|
||||
|
||||
以下は DeepSeek と Kimi の設定例です。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
モデル設定を保存した後、右側の Router エリアでデフォルトモデル（Default）を指定する必要があります。該当するドロップダウン選択をクリックし、`kimi`（推奨）に設定した後、右上の「Save and Restart」をクリックしてください。
|
||||
|
||||
|
||||
|
||||
その後、ターミナルで `ccr code` と入力するだけで、Claude Code Router を通じて Claude Code のコーディングワークフローを起動できます。
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
#### Claude Code の応用的な使い方
|
||||
|
||||
Claude Code を使い始めたばかりの頃は、単なる対話ツールとして使っている人が多いでしょう。しかし実際には、より効率的で柔軟な使用を可能にする豊富な機能が内蔵されています。以下に、一般的なコマンドと使用例をいくつか紹介します。
|
||||
|
||||
参考ドキュメント：
|
||||
|
||||
<https://docs.claude.com/en/docs/claude-code/cli-reference>
|
||||
<https://docs.claude.com/en/docs/claude-code/slash-commands>
|
||||
|
||||
| コマンド | 機能 | 例 |
|
||||
| ----------------- | ----------------------------------------- | ---------------------------------------- |
|
||||
| claude | インタラクティブモードの起動 | `claude` |
|
||||
| claude "query" | 一度限りのタスクを実行し結果を出力 | `claude "explain this project"` |
|
||||
| claude -p "query" | 一度限りの質問を実行し、終了後に自動的に終了 | `claude -p "explain this function xxxx"` |
|
||||
| claude -c | 直近のセッションを再開 | `claude -c` |
|
||||
| claude -r | 前回のセッションを復元 | `claude -r` |
|
||||
| /resume | 現在のチャットで前回のセッションに切り替え | `claude -c`、`/resume` |
|
||||
| /plugin | プラグインの管理。コミットやレビュー機能の拡張をインストール可能 | `/plugin` |
|
||||
| /init | CLAUDE.md でプロジェクト説明を初期化 | `/init` |
|
||||
| /clear | 現在のセッションのコンテキストをクリアし、情報過多を防止 | `/clear` |
|
||||
| /compact | セッション履歴を圧縮し、コンテキストのトークン消費を削減 | `/compact` |
|
||||
| /cost | 現在の利用料金を確認 | `/cost` |
|
||||
| /model | 使用するモデルを切り替え（互換 API 使用時は基本的に無視可能） | `/model` |
|
||||
| /memory | CLAUDE.md メモリファイルの管理 | |
|
||||
| /help | 利用可能なコマンド一覧を表示 | `/help` |
|
||||
| exit or Ctrl+C | Claude Code を終了 | `exit` または `Ctrl+C` |
|
||||
| /agents | 高度な機能、後述 | |
|
||||
| /mcp | 高度な機能、後述 | |
|
||||
|
||||
**CLAUDE.md**
|
||||
|
||||
参考： <https://www.anthropic.com/engineering/claude-code-best-practices>
|
||||
|
||||
`CLAUDE.md` は、Claude が対話を開始する際に自動的に読み込み、コンテキストに追加する特別なファイルです。そのため、以下の内容を記録するのに非常に適しています。
|
||||
|
||||
- よく使う bash コマンド
|
||||
- コアファイルとユーティリティ関数
|
||||
- コードスタイルの規約
|
||||
- テスト方法の説明
|
||||
- リポジトリのコラボレーションルール（ブランチの命名、merge か rebase かなど）
|
||||
- 開発環境の設定説明（pyenv の使用有無、推奨コンパイラなど）
|
||||
- プロジェクト内で特に注意すべき動作や落とし穴
|
||||
- Claude に「記憶」してほしいあらゆる情報
|
||||
|
||||
`CLAUDE.md` 自体に強制フォーマットはありません。簡潔で人間が読みやすい形式であれば問題ありません。例えば以下の通りです。
|
||||
|
||||
```
|
||||
# Bash commands
|
||||
- npm run build: Build the project
|
||||
- npm run typecheck: Run the typechecker
|
||||
|
||||
# Code style
|
||||
- Use ES modules (import/export) syntax, not CommonJS (require)
|
||||
- Destructure imports when possible (eg. import { foo } from 'bar')
|
||||
|
||||
# Workflow
|
||||
- Be sure to typecheck when you're done making a series of code changes
|
||||
- Prefer running single tests, and not the whole test suite, for performance
|
||||
```
|
||||
|
||||
#### Claude Code の内部仕組み
|
||||
|
||||
参考： <https://github.com/shareAI-lab/analysis_claude_code>
|
||||
|
||||
Claude Code が多くの場面で Trae や Cursor などの Agent プログラミングツールより使いやすい理由に興味がある場合は、その内部の仕組みを簡単に見てみましょう。
|
||||
|
||||
他の CLI AI プログラミングツールも、全体的な実装方法は概ね同様です。
|
||||
|
||||
|
||||
|
||||
Claude Code は、プログラミングタスクを継続的な「知覚—思考—行動—検証」のサイクルに分解し、その中で異なるツールを呼び出してタスクを完了させます。人間の開発者のワークフローを模倣し、「コードを書く→実行する→結果を見る→さらに改善する」を繰り返します。システム内部では、メインタスクのループを通じてステップを継続的に実行し、各サイクルで Claude は異なるツール（ファイルの読み書き、コマンドの実行、コードの検索など）を呼び出し、ツールから返された実際の結果に基づいて次のアクションを決定します。
|
||||
|
||||
その中で、特に注目すべき特徴がいくつかあります。
|
||||
|
||||
- **ストリーム処理（Stream Processing）**：Claude は考えながら同時に結果を出力でき、すべてのコードを書き終わるまで待つ必要がありません。
|
||||
- **インテリジェント圧縮（Intelligent Compression）**：長い対話はコンテキストが過剰に長くなりやすいため、Claude は履歴を重要な情報に圧縮することで「忘却」の確率を下げ、長期記憶と短期記憶を区別して効率的な動作を保証します。
|
||||
- **並行制御（Concurrency Control）**：内部の並列設計により、複数のタスクを同時に実行し、互いに干渉しません。
|
||||
- **サブ Agent 管理（Sub-agent Management）**：実際の作業では、単一の「役割」がすべてを処理するわけではありません。複数のサブ Agent を管理してコードを協力して処理でき、各 Agent が異なるタスク（テスト専用、ドキュメント作成専用など）を担当します。
|
||||
|
||||
### Codex
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Claude Code と同様に、Codex は OpenAI が開発した AI 協力プログラミングツールであり、「OpenAI 版の Claude Code」と理解できます。最大の強みは GPT-5 の効率的な適応です。
|
||||
|
||||
実際の体験から言うと、GPT-5 は現在レスポンスがより速く、エラー率も低いです（複数回の複雑なタスクにおいて、正しく完了する確率が高い）。一方、欠点として、説明が「学術的」で「技術的」に偏りがちで、時には過度に厳密で情報量が多く、初心者には少し分かりにくいと感じる場合があります。
|
||||
|
||||
以下のコマンドで Codex をインストールできます。
|
||||
|
||||
```
|
||||
npm i -g @openai/codex
|
||||
```
|
||||
|
||||
#### OpenAI 公式 API をバックエンドとして使用する
|
||||
|
||||
OpenAI 公式の Codex エントリポイントを直接使用する場合、設定は非常にシンプルです。OpenAI のサブスクリプションを有効にしているか、対応する API クォータを取得した後、コマンドラインで `codex` と入力してプログラムを起動し、指示に従ってログインを完了するだけです。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### OpenAI API の転送方式をバックエンドとして使用する
|
||||
|
||||
公式の OPENAI API は価格が高く、ネットワーク要件が厳しいなどの問題がある可能性があるため、これらの制限を回避するために、他の API ゲートウェイサービスを通じて呼び出しを転送することもできます。
|
||||
|
||||
この方式では、サードパーティの転送プラットフォームで対応する Codex API クォータを購入するだけで、ネイティブの OpenAI Codex に近い使用体験を得られます。
|
||||
|
||||
参考： <https://open-dev.feishu.cn/wiki/PAqUwWG4IiuwTvkQ2sGcaQuPnXc>
|
||||
チャージ URL： <https://api.zyai.online/account/topup/recharge>
|
||||
|
||||
なお、トークンクォータを取得した後、ローカルで API Key の設定も行う必要があります。
|
||||
|
||||
キーグループの設定では、Codex 専用の項目を選択するよう注意してください。
|
||||
|
||||
|
||||
|
||||
次に、取得した Key を以下のプロンプトに記入し、プロンプト全体を Trae に渡して、設定プロセス全体を完了させます。
|
||||
|
||||
````bash
|
||||
My API key is: [Paste your obtained sk-xxxxx key here]
|
||||
|
||||
Please help me complete the following configuration tasks:
|
||||
|
||||
1. Create configuration directory
|
||||
- Create a `.codex` folder under my user directory
|
||||
- Windows path should be: `C:\Users\[My Username]\.codex`
|
||||
2. Backup existing configuration (if exists)
|
||||
- Check if `.codex\config.toml` exists
|
||||
- If it exists, rename it to `config.toml.bak.[current timestamp]` (timestamp format: yyyyMMddHHmmss)
|
||||
3. Create configuration file
|
||||
- Create `config.toml` in the `.codex` directory
|
||||
- Write the following complete content:
|
||||
```toml
|
||||
preferred_auth_method = "apikey"
|
||||
|
||||
[model_providers.myrelay]
|
||||
name = "My Relay Station"
|
||||
base_url = "https://api.zyai.online/v1"
|
||||
env_key = "MYRELAY_API_KEY"
|
||||
wire_api = "responses"
|
||||
request_max_retries = 4
|
||||
stream_max_retries = 10
|
||||
stream_idle_timeout_ms = 300000
|
||||
|
||||
[profiles.myrelay]
|
||||
model_provider = "myrelay"
|
||||
model = "gpt-5"
|
||||
model_reasoning_effort = "medium"
|
||||
|
||||
[tools]
|
||||
web_search = true
|
||||
|
||||
4. Set system environment variable
|
||||
Variable name: MYRELAY_API_KEY
|
||||
Variable value: The key I gave you
|
||||
|
||||
5. Confirm completion and report back:
|
||||
|
||||
The full path of the configuration file
|
||||
Whether the environment variable was set successfully
|
||||
I can use the command `codex --profile myrelay` to run it
|
||||
````
|
||||
|
||||
設定が完了すると、`codex --profile myrelay` で転送 API を使用する Codex を起動できます。その後の使い方は Claude Code と同様で、チャットボックスにいつでもアイデアや要望を入力するだけです。
|
||||
|
||||
### OpenCode
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
OpenCode は開発者向けのオープンソース AI Coding Agent プラットフォームであり、「マルチモデル版の Claude Code」という位置づけです。Terminal を主なインタラクションの入口としながら、VS Code、Neovim などのエディタ統合もサポートし、ローカルのコードリポジトリに深くアクセスし、自然言語でコードの理解からエンジニアリングの実行まで、開発プロセス全体を完了できます。
|
||||
|
||||
単一のモデルに縛られた AI プログラミングツールではなく、GPT、Claude、Gemini からローカルモデルまで自由に切り替えられるオープンな AI Coding Agent プラットフォームです。OpenAI 公式も OpenCode を通じた Codex / OpenAI サブスクリプションへの接続をサポートしています。
|
||||
|
||||
|
||||
|
||||
以下のコマンドで OpenCode をインストールできます。
|
||||
|
||||
```bash
|
||||
# Linux / Unix
|
||||
curl -fsSL https://opencode.ai/install | bash
|
||||
|
||||
# Windows
|
||||
npm i -g opencode-ai
|
||||
```
|
||||
|
||||
#### OpenCode の無料モデルを使用する
|
||||
|
||||
OpenCode では不定期に無料モデルが提供されており、設定も非常にシンプルです。OpenCode を使用したいディレクトリでコマンドラインに `opencode` と入力して OpenCode プログラムを起動し、チャットパネルに入ります。`/models` コマンドを入力して「free」キーワードで検索すると、「free」という文字を含む無料モデルが表示されます。
|
||||
|
||||
|
||||
|
||||
一般的に、無料モデルはコーディングタスクの完了において有料/サブスクリプションモデルより遅くなります。これは通常、モデル回線の混雑状況、ピーク時間帯かどうか、モデル自体の能力に依存します。
|
||||
|
||||
#### サードパーティのモデルを OpenCode のメインコーディングモデルとして使用する
|
||||
|
||||
これが OpenCode の最大の強みです。同じ MCP、Skills、コンテキストを使用したまま、モデルを自由に切り替えて異なるコーディングタスクを完了できます。以下では、OpenAI 公式の GPT-5.3 Codex を例に、OpenCode にメインコーディングモデルとして接続します。
|
||||
|
||||
OpenCode のチャットウィンドウで `/connect` コマンドを入力し、最初の最も関連性の高い指示を選択して Enter キーを押すと、サードパーティモデルプロバイダーの認証認可を選択できます。
|
||||
|
||||
|
||||
|
||||
ここでは OpenAI を選択する例で、Enter キーを押して認証方式を選択します。
|
||||
|
||||
|
||||
|
||||
どちらでも構いません。認証方式が異なるだけです。ここでは最初の方法でブラウザログインを行います。
|
||||
|
||||
|
||||
|
||||
このリンクをブラウザにコピーして、通常の OpenAI ログイン操作を行います。ブラウザに「Authorization Successful」と表示されたら、OpenCode クライアントは自動的に OpenAI のモデル選択画面に遷移します。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Oh My OpenAgent プラグインのインストール
|
||||
|
||||
OpenCode の強力さは、非常に活発なコミュニティエコシステムにもあります。GitHub で OpenCode 関連のプラグインが多数見つかります。OpenCode がモデルを自由に切り替えられる AI 協力ツールだとすれば、Oh-My-OpenAgent は OpenCode 上で動作する「マルチ Agent AI プログラミング指揮システム」です。複雑なタスクを複数のサブタスクに分解し、異なるモデルに分担させて各々の役割を果たさせることができます。
|
||||
|
||||
|
||||
|
||||
以下のテキストをコピーして、OpenCode で設定済みのモデルに貼り付け、OpenCode にインストールさせます。
|
||||
|
||||
```text
|
||||
Install and configure oh-my-openagent by following the instructions here:
|
||||
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md
|
||||
```
|
||||
|
||||
以下は Oh-My-OpenAgent の機能と説明です。
|
||||
|
||||
| 特性 | 機能説明 |
|
||||
| :-------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| **自律軍団 (Discipline Agents)** | Sisyphus が Hephaestus、Oracle、Librarian、Explore のスケジュールを管理。完全な AI 開発チームが並列で作業。 |
|
||||
| **Team Mode** (v4.0, オプション) | リーダー Agent + 最大 8 名の並列メンバー、リアルタイム tmux 可視化、専用 `team_*` ツール群。`hyperplan`（5 人の敵対的レビュアー）と `security-research`（3 人のハンター + 2 人の PoC エンジニア）を駆動。[ドキュメント →](docs/guide/team-mode.md) |
|
||||
| **`ultrawork` / `ulw`** | ワンクリックで全 Agent が出動。タスク完了まで決して停止しない。 |
|
||||
| **[IntentGate 意図ゲート](https://factory.ai/news/terminal-bench)** | 本当に行動する前に、ユーザーの真の意図を分析。文字通りの意味に誤導される AI の無駄発言に完全に別れを告げる。 |
|
||||
| **ハッシュベースの編集ツール** | 各修正は `LINE#ID` コンテンツハッシュで検証。誤修正率 0%。[oh-my-pi](https://github.com/can1357/oh-my-pi) にインスパイア。[The Harness Problem →](https://blog.can.ac/2026/02/12/the-harness-problem/) |
|
||||
| **LSP + AST-Grep** | ワークスペースレベルのリネーム、ビルド前診断、AST ベースの書き換え。Agent に IDE レベルの精度を提供。 |
|
||||
| **バックグラウンド Agent** | 5 人以上の専門家が同時に並列作業。コンテキストをクリーンに保ちながら、いつでも成果を取得可能。 |
|
||||
| **内蔵 MCP** | Exa（ウェブ検索）、Context7（公式ドキュメント）、Grep.app（GitHub ソースコード検索）。デフォルトで有効。 |
|
||||
| **Ralph Loop / `/ulw-loop`** | 自己参照のループ。100% の完了度に達するまで停止しない。 |
|
||||
| **Todo 強制実行** | Agent がサボろうとしたら、システムが強制的に引き戻す。あなたのタスクは必ず完了させる。 |
|
||||
| **コメントレビューアー** | 強い AI 臭のある冗長なコメントを除去。熟練したシニアエンジニアが書いたようなコードを出力。 |
|
||||
| **Tmux 統合** | 完全なインタラクティブターミナルサポート。REPL の実行、デバッガの使用、TUI ツールの利用、すべてリアルタイムセッションで完了。 |
|
||||
| **Claude Code 互換** | 既存の Hooks、コマンド、Skills、MCP、プラグインはすべてシームレスに移行可能。 |
|
||||
| **Skills 内蔵 MCP** | Skills が必要な MCP サーバーを内蔵。オンデマンドで起動し、コンテキストウィンドウを圧迫しない。 |
|
||||
| **Prometheus プランナー** | コードを書き始める前に、インタビューモードで戦略計画を作成。 |
|
||||
| **`/init-deep`** | プロジェクトディレクトリ階層全体に `AGENTS.md` を自動生成。トークンの節約だけでなく、Agent の理解力も大幅に向上。 |
|
||||
|
||||
Sisyphus (claude-opus-4-7 / kimi-k2.6 / glm-5.1) はメインコマンダーです。計画の策定、専門家チームへのタスク割り当てを担当し、極めてアグレッシブな並列戦略でタスクを完了まで推進します。彼は途中で諦めることはありません。
|
||||
|
||||
Hephaestus (gpt-5.5) は自律的なディープワーカーです。目標だけを与え、具体的な方法は指示しないでください。彼は自動的にコードベースのパターンを探索し、最初から最後まで独立してタスクを実行し、途中であなたに世話を焼かせることはありません。名実ともに正真正銘の職人です。
|
||||
|
||||
Prometheus (claude-opus-4-7 / kimi-k2.6 / glm-5.1) は戦略プランナーです。インタビューモードを通じて、1行のコードを書く前に、質問によってスコープを確定し、詳細な実行計画を構築します。
|
||||
|
||||
これらを理解したら、Oh-My-OpenAgent プラグインをインストールした OpenCode を使ってコーディングタスクに取り組むことができます。
|
||||
|
||||
## CLI AI プログラミングツールのさらに多くの使い方
|
||||
|
||||
### AI で要件文書を書く：「要件の具体化」を学ぶ
|
||||
|
||||
大規模言語モデルにとって、抽象的な要件は「具体化」される必要があります。例えば、「お腹が空いた」というのは抽象的な要件であり、「お腹が少し空いているので、あんパンを一つ食べて、豆乳を一杯合わせたい」——これが実行可能な具体的な要件です。
|
||||
|
||||
しかし、抽象的な要件を具体的にするのは、実はかなり労力のかかるプロセスです。十分な数の事例に触れていなければ、抽象的な問題を細かなモジュールに分解する方法をすぐに思いつくのは難しいでしょう。そのような場合、最も良い方法は AI に「具体化」のステップを手伝わせることです。
|
||||
例えば、「毎日の計画」アプリを開発したい場合、最もシンプルなアイデアは次のようになるでしょう。
|
||||
|
||||
`Please help me write a daily planning app where I can write my plans each day and get reminders.`
|
||||
|
||||
AI はこの要件に基づいてタスクを分割し、段階的に完了させることも可能ですが、途中でエラーや理解のズレが生じやすくなります。リスクを下げるために、まず AI に要件を拡張してもらいましょう。
|
||||
|
||||
`Based on my needs, please elaborate and provide a more detailed Product Requirement Document for reference. My idea is: Please help me write a daily planner app that supports daily plan-writing and provides reminders .`
|
||||
|
||||
すると、AI は以下のような完全な PRD を提案してくれるかもしれません。
|
||||
|
||||
```
|
||||
Product Requirements Document (PRD): "Today's Plan" App
|
||||
Document Version: 1.0
|
||||
Creation Date: October 27, 2023
|
||||
Author: (Your Name/Product Manager)
|
||||
|
||||
1. Product Introduction
|
||||
1.1 Product Name
|
||||
Today's Plan
|
||||
1.2 Product Vision
|
||||
"Today's Plan" is a minimalist and highly efficient daily planning and reminder tool, dedicated to helping users eliminate procrastination and forgetfulness, plan every day clearly, and ensure tasks are carried out through an intelligent reminder system—ultimately enabling users to gain a stronger sense of control and achievement over their time.
|
||||
1.3 Target Users (User Personas)
|
||||
We mainly serve three types of users:
|
||||
Students (Xiao Ming):
|
||||
Characteristics: Multiple tasks such as courses, assignments, club activities, exam prep, needing organized time arrangement.
|
||||
Pain Points: Easily forget small tasks or assignment deadlines; feel overwhelmed switching between tasks; want to build regular study and life habits.
|
||||
Needs: A simple tool to list daily to-dos and provide reminders before class/self-study.
|
||||
Office Workers (Zhang Wei):
|
||||
Characteristics: Fast-paced work, many meetings, reports, project milestones, and personal affairs (fitness, picking up children).
|
||||
Pain Points: Easily forget important meetings or work milestones; get interrupted by urgent tasks and forget the original plan; feel busy but inefficient at end of day.
|
||||
Needs: Need a tool to quickly record and schedule daily work and send strong reminders at key times (e.g., 15 minutes before meetings).
|
||||
Freelancers/Self-disciplined Seekers (Li Na):
|
||||
Characteristics: High freedom of time, but strong self-management required for work output and personal growth.
|
||||
Pain Points: Easily procrastinate, lack external supervision; start the day without a clear plan, leading to low time utilization.
|
||||
Needs: Need a tool to help build a daily fixed routine (Morning Routine) and review daily achievements for positive feedback.
|
||||
|
||||
2. User Stories
|
||||
As a user, I want to quickly create today's plan list so I have an overview of all my tasks for the day.
|
||||
As a user, I want to set specific start and end times for each task so I can create a visual timeline.
|
||||
As a user, I want to receive push notification reminders before a task starts so I won't miss any important arrangements.
|
||||
As a user, I want to customize the reminder time (such as 5, 15, or 60 minutes in advance) so reminders better fit my habits.
|
||||
As a user, I want to easily mark completed tasks so I can feel accomplished and clearly see my progress.
|
||||
As a user, I want to see a summary of my completed plans at the end of each day for reviewing and self-motivation.
|
||||
As a user, I want to conveniently edit and delete tasks to handle last-minute changes.
|
||||
As a user, I want to view plans and achievements from previous days to review my efficiency and habits.
|
||||
|
||||
3. Feature Breakdown
|
||||
Core Features (MVP - Minimum Viable Product)
|
||||
Module 1: Plan Management
|
||||
3.1.1 Daily Plan Homepage
|
||||
Interface: "Today" as the core view, current date shown at the top.
|
||||
View: Timeline list, clearly showing tasks scheduled from morning to evening. Tasks without a time can be listed in the top or bottom "To-do List" section.
|
||||
Interactions:
|
||||
Click the "+" button in the bottom right to quickly create a new task.
|
||||
Pull down to refresh the page.
|
||||
Swipe left/right to view yesterday's and tomorrow's plans.
|
||||
3.1.2 Create/Edit Task
|
||||
Entry: Click "+" on the homepage or a time slot in the list.
|
||||
Fields:
|
||||
Task title (required): Briefly describe the task, e.g., "10 AM Weekly Product Meeting."
|
||||
Task time (optional):
|
||||
Set "start time" and "end time."
|
||||
Provide "all-day" option for unspecified time tasks.
|
||||
Default time picker should be quick and convenient.
|
||||
Reminder setting (required, with default value): See Module 2.
|
||||
Notes (optional): Add further descriptions, links, or location info.
|
||||
Actions: Save, cancel, delete task.
|
||||
3.1.3 Task Interaction
|
||||
Mark as complete: Checkbox before each task; checking adds a strikethrough and gray background, indicating completion. Can unmark if needed.
|
||||
Edit task: Click the task itself to enter edit page.
|
||||
Delete task: Swipe left on a task to reveal "Delete" button.
|
||||
Module 2: Smart Reminder System
|
||||
3.2.1 Reminder Trigger
|
||||
Mechanism: Based on task's set "start time" and the user's "reminder lead time," send a push notification from device.
|
||||
Offline Support: Locally scheduled reminders must trigger even if user is offline.
|
||||
3.2.2 Reminder Content & Format
|
||||
Notification title: App name "Today's Plan."
|
||||
Body: "Reminder: [Task Title] will start at [Start Time]." E.g., "Reminder: Product Meeting will start at 10:00."
|
||||
Sound: Use system default or offer several simple, effective tones.
|
||||
3.2.3 Reminder Settings
|
||||
Global Settings (in Settings page):
|
||||
User can set a default reminder time, e.g., "15 minutes before task starts." New tasks adopt this by default.
|
||||
Single Task Settings (in create/edit page):
|
||||
Users can override global settings for important tasks, choosing specific reminder times like "on time," "5 minutes early," "30 minutes early," or "1 hour early."
|
||||
Provide "no reminder" option.
|
||||
Subsequent Features (V1.1, V2.0)
|
||||
3.3 Daily Review & Statistics
|
||||
Push a summary notification at a set time every night (e.g., 22:00): "How was your day? Take a look at your achievements!"
|
||||
Generate a simple daily report card: shows total planned tasks, completed tasks, completion rate, plus an encouraging message.
|
||||
3.4 History Review
|
||||
Calendar view to click on any past day and check its plans and completion status. Days with high completion rates marked with a special color.
|
||||
3.5 Templates
|
||||
Allow users to save a successful daily plan as a template, e.g., "Efficient Workday," "Relaxing Weekend."
|
||||
When creating tomorrow's plan, one-click import a template, modify slightly to save time.
|
||||
3.6 Themes & Personalization
|
||||
Offer dark mode.
|
||||
Allow changing several primary color themes.
|
||||
|
||||
4. Non-Functional Requirements
|
||||
4.1 Performance
|
||||
Response: App launch time under 2 seconds; adding/editing tasks must be smooth and lag-free.
|
||||
Resource Use: Low battery and memory consumption in background; do not over-consume resources waiting for reminders.
|
||||
4.2 Usability
|
||||
Minimal & intuitive: UI must be minimal, primary functions accessible within 3 clicks. No tutorial needed for new users.
|
||||
Error tolerance: Offer undo (e.g. brief undo after mistakenly deleting a task).
|
||||
4.3 Reliability
|
||||
Reliable reminders: Reminder function is the product's lifeline; must guarantee 99.99% timely and accurate delivery.
|
||||
Data loss-free: User plans must be reliably stored locally. Future versions can support cloud sync to prevent data loss on device change.
|
||||
4.4 Compatibility
|
||||
Platform: Support major iOS and Android versions (latest 3-4 releases).
|
||||
Screen: Layout must fit various phone screen sizes.
|
||||
|
||||
5. Roadmap
|
||||
V1.0 (MVP):
|
||||
Goal: Validate core value—planning & reminders.
|
||||
Features: Complete all "Core Features" described above (Plan management, smart reminders).
|
||||
V1.1 (Quick Optimization):
|
||||
Goal: Improve retention and achievement.
|
||||
Features: Add "Daily Review & Statistics," "History Review."
|
||||
V2.0 (Enhanced Experience):
|
||||
Goal: Increase efficiency and personalization.
|
||||
Features: Add "Templates," "Themes & Personalization," and start developing "Cloud Sync."
|
||||
```
|
||||
|
||||
最初の「毎日計画を記録してリマインドするアプリを作って」という一言と比べると、このドキュメントはずっと詳細になっています。実際の要件に基づいて内容を追加・削除・変更できます。一部のモジュールが不確かな場合は、AI にさらに多くの代替案を提案させ、それらから選択・統合して最終版を作成できます。
|
||||
|
||||
この方法により、抽象的なアイデアを簡単に具体的な説明に変換できます。AI 開発において、「具体性」こそが生産性です。要件が具体的であればあるほど、構造が安定した品質の高いプロジェクトを得やすくなります。この方法で以前の小規模プロジェクトをもう一度作り直して、効果の違いを比較してみてください。
|
||||
|
||||
このような「要件プロンプト」が長すぎると感じる場合、非常に自然なアプローチは、それを個別の Markdown ドキュメントに書き出し、あなたの「要件文書/開発文書/PRD」として扱うことです。その後、AI にプロジェクトを作成させるたびに、「この文書を参考にして」と指示するだけで、毎回長いプロンプトを入力し直す必要がありません。また、反復を通じてこの文書を継続的に改善し、後続のプロジェクトにも活用できます。
|
||||
|
||||
以下に、その他の一般的な使用シナリオをいくつか紹介します。
|
||||
|
||||
### フォルダの管理
|
||||
|
||||
CLI AI プログラミングツールを使って、現在のフォルダ内の様々なファイルを管理してみましょう。例えば、整理されていないファイルがたくさんあり、整理・分類したい場合、Claude Code や Codex に次のように依頼できます。
|
||||
|
||||
`Please help me organize the contents of the current folder. I want to group files with the same content together & I want to group files from the same time period together. Please help me handle this.`
|
||||
|
||||
### 新規プロジェクトの開発
|
||||
|
||||
これは、以前に z.ai や Trae で行った使い方とほぼ同じです。CLI AI プログラミングツールを使って、ゼロから新規プロジェクトを開発することも可能です。もちろん、あらかじめ要件文書を用意しておくのが理想的です。
|
||||
|
||||
要件文書が詳細であればあるほど、最終的な成果は良くなります。アイデアが変化するたびに文書を複数回最適化できます。文書が完成度を増すほど、コードの実装はより安定し、成熟したものになります。
|
||||
|
||||
### オープンソースプロジェクトのデプロイ（例：Dify）
|
||||
|
||||
コンピュータに触れたばかりの方にとって、GitHub からオープンソースプロジェクトをデプロイするのは難しく感じられることが多いでしょう。しかし、この作業は完全に Claude Code に任せることができます。Dify のチュートリアルでやったように。
|
||||
|
||||
<https://github.com/langgenius/dify>
|
||||
|
||||
自分の Dify をローカルで動かしたい場合、このリンクを Claude Code に渡して、次のように入力するだけです。
|
||||
|
||||
`I want to deploy this GitHub project ``https://github.com/langgenius/dify`` . Please help me clone the project and run it.`
|
||||
|
||||
リクエストを受け取ると、Claude Code は GitHub からのコードの取得、実行環境の設定、プロジェクトの起動など、一連の操作を自動的に完了します。途中でエラーが発生した場合や、プロジェクトの起動状態が異常な場合は、指示に従って少量の手動対応を行うだけで済みます。Dify 以外にも、Claude Code を使って一般的な GitHub オープンソースプロジェクトの大半をデプロイできます。必要なのは一つのチャットボックスと、コーヒーを一杯飲む時間だけです。
|
||||
|
||||
|
||||
|
||||
### コードの解説とドキュメントの作成
|
||||
|
||||
複雑なプロジェクトや、AI が自動生成した大規模なプロジェクトでは、コードが長すぎて論理が多すぎ、理解するのが難しいと感じることがあるでしょう。そんな時は、CLI AI プログラミングツールに「コードを読む」のを手伝わせることができます。次のように質問してみてください。
|
||||
|
||||
- このプロジェクトを説明してください。どのように実行するか、どのように使うか、今後どのように変更して開発を続けるか。
|
||||
- このプロジェクトの全体の流れを説明してください。プログラムはどのように動いているか。ユーザーは画面でどのような操作ができるか。
|
||||
- このプロジェクトのために完全なドキュメントを作成してください。開発ドキュメントと実行ドキュメントを含めてください。
|
||||
- 現在のフォルダ内のすべての内容に基づいて、詳細な説明を作成し、指定した Markdown ドキュメントに保存してください。
|
||||
|
||||
### さらに多くの使い方
|
||||
|
||||
もちろん、CLI AI プログラミングツールにできることは、上記のものにとどまりません。「コードを書くツール」としてだけでなく、独立した行動力を持つインテリジェントな Agent として捉えてください。次のようなことを依頼できます。
|
||||
|
||||
- ローカルファイルの管理と整理
|
||||
- 日記やまとめの作成
|
||||
- システムエラーの分析と修正
|
||||
- 各種反復的なコマンドラインタスクの実行
|
||||
|
||||
おそらく近い将来、それはあなたの PC 上で最も重要であり、最もあなたを理解している AI パートナーになるでしょう。
|
||||
@@ -0,0 +1,907 @@
|
||||
# Stripe などの決済システムの統合方法
|
||||
|
||||
製品にページ、ログイン、データベース、基本的なバックエンドが揃った後、次に直面する現実的な課題は **「どうやって料金を徴収するか」** です。
|
||||
|
||||
決済を初めて導入する際、多くの人が「どうやって支払いページにリダイレクトするか」にばかり注意を向けます。しかし、システムが安定しているかどうかを本当に左右するのはボタンではなく、決済チェーン全体です。誰が価格を決定するのか、誰が決済の成功を確認するのか、誰がデータベースを更新するのか、誰が権限を回収するのか。
|
||||
|
||||
本記事では、内容を2つの部分に分けて解説します。
|
||||
|
||||
- **前半**では最も実用的な基本導入のみを扱い、Stripe をプロジェクトにできるだけ早く組み込めるようにします。
|
||||
- **後半**は付録としてまとめ、Webhook の詳細、サブスクリプションイベント、国や地域による決済ソリューションの違いを取り上げます。
|
||||
|
||||
> **前提として、以下の章を先に学ぶことをお勧めします**
|
||||
>
|
||||
> - [データベースから Supabase へ](../database-supabase/)
|
||||
> - [大規模言語モデルによるインターフェースコードとインターフェース文書の作成支援](../ai-interface-code/)
|
||||
> - [Web アプリケーションのデプロイ方法](../zeabur-deployment/)
|
||||
|
||||
# このレッスンで学ぶこと
|
||||
|
||||
1. 最小実現可能な決済システムがどのようなものか。
|
||||
2. Stripe を最速でプロジェクトに組み込む方法。
|
||||
3. AI に決済システムを直接追加させるためのプロンプトの書き方。
|
||||
4. 海外向けの Stripe プロジェクトではない場合、地域ごとにどの決済ソリューションを優先すべきか。
|
||||
|
||||
---
|
||||
|
||||
# 第1部：基本編
|
||||
|
||||
## 1. まず3つの原則を覚える
|
||||
|
||||
3つのことだけ覚えるなら、次の3つです。
|
||||
|
||||
1. **価格は必ずバックエンドで決定する**。フロントエンドから送られてくる金額を信用してはいけない。
|
||||
2. **権限を本当に有効にするのは Webhook であり**、`success` ページではない。
|
||||
3. **自前のデータベースに必ず決済ステータスを保存する**。Stripe の管理画面だけに頼ってはいけない。
|
||||
|
||||
この3つが決済システムの最も中核的な境界です。この境界さえ間違えなければ、後で Stripe、PayPal、Alipay、WeChat Pay に切り替えても、本質的には「インターフェースが変わるだけで、アーキテクチャは変わらない」ことになります。
|
||||
|
||||
## 2. バックエンドではなく、フロントエンドから直接 Stripe に接続するとどうなるか？
|
||||
|
||||
決済を初めて実装する際、多くの人が真っ先に思いつく考え方です。
|
||||
|
||||
- ページにはすでに「購入」ボタンがある
|
||||
- フロントエンドから直接 Stripe に接続すればいいのではないか
|
||||
- そうすればバックエンドを作らなくても済むのではないか
|
||||
|
||||
デモ用の偽ページを作るだけなら、この考え方で問題ありません。
|
||||
しかし、本当に料金を徴収するなら、**この方法は通常、問題を引き起こします。**
|
||||
|
||||
最もよくある問題は以下の通りです。
|
||||
|
||||
1. **価格が簡単に改ざんされる**
|
||||
ブラウザからのリクエストは、ユーザー自身の PC から送信されます。リクエストの内容を書き換えることができます。
|
||||
2. **機密情報が漏洩しやすい**
|
||||
本当に重要なシークレットキー、価格ロジック、メンバーシップの有効化ロジックは、そもそもフロントエンドに置くべきではありません。
|
||||
3. **「この支払いは本当に成功したのか」を確実に確認できない**
|
||||
ユーザーが成功ページに遷移したからといって、データベースが正しく同期されているとは限りません。
|
||||
4. **データベースの状態が混乱する**
|
||||
ユーザーは「ちゃんと支払った」と主張するのに、システム側には記録がないという事態が発生します。
|
||||
|
||||
より安全な役割分担は次のようになります。
|
||||
|
||||
- フロントエンドの担当：ボタンの表示、購入の開始、ページ遷移
|
||||
- バックエンドの担当：価格の決定、決済セッションの作成、Webhook の受信、データベースの更新
|
||||
|
||||
::: info 一言でまとめると
|
||||
**フロントエンドはリダイレクトを担当し、バックエンドが価格決定と確認を担当する。**
|
||||
|
||||
本当に料金を徴収するのであれば、「最終的な価格決定権」と「決済成功後の有効化ロジック」をフロントエンドに置いてはいけません。
|
||||
:::
|
||||
|
||||
## 3. Stripe をまず選ぶべきケース
|
||||
|
||||
次のようなケースでは、Stripe を最初の選択肢とするのが最もスムーズです。
|
||||
|
||||
- 海外ユーザー向けの SaaS
|
||||
- サブスクリプション型のメンバーシップ製品
|
||||
- デジタル製品、テンプレート、AI クレジットパック
|
||||
- 商用化を素早く検証したいが、最初からローカル決済の細かな対応に時間をかけたくない場合
|
||||
|
||||
主なユーザーが中国大陸にいる場合、通常は Stripe を第一選択としません。この点については付録でまとめて説明します。
|
||||
|
||||
## 4. 最小実現可能な決済チェーン
|
||||
|
||||
まず最小バージョンを見てみましょう。このチェーンが動けば、決済システムの骨格が完成します。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
user["ユーザー"]
|
||||
frontend["フロントエンドページ"]
|
||||
backend["バックエンド"]
|
||||
checkout["Stripe Checkout"]
|
||||
webhook["Stripe Webhook"]
|
||||
db["Supabase / 業務データベース"]
|
||||
|
||||
user -->|"購入をクリック"| frontend
|
||||
frontend -->|"決済セッション作成をリクエスト"| backend
|
||||
backend -->|"バックエンド価格で Session を作成"| checkout
|
||||
frontend -->|"決済ページにリダイレクト"| checkout
|
||||
checkout -->|"決済完了後にイベントを送信"| webhook
|
||||
webhook -->|"署名を検証してステータスを更新"| backend
|
||||
backend -->|"orders / subscriptions に書き込み"| db
|
||||
db -->|"フロントエンドがリフレッシュ後に最新ステータスを読み取り"| frontend
|
||||
```
|
||||
|
||||
これを分かりやすく言い換えると、次の通りです。
|
||||
|
||||
1. ユーザーがボタンをクリックする。
|
||||
2. フロントエンドがバックエンドに決済リンクを要求する。
|
||||
3. バックエンドが Stripe のシークレットキーを使って決済セッションを作成する。
|
||||
4. ユーザーが Stripe のページで支払いを行う。
|
||||
5. Stripe が「支払いが本当に成功した」ことを Webhook で通知する。
|
||||
6. バックエンドがデータベースを更新する。
|
||||
|
||||
## 5. 標準的な決済フローのシーケンス図
|
||||
|
||||
より規格化されたシステム図に慣れている場合は、以下のシーケンス図を直接ご覧ください。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as ユーザー
|
||||
participant Frontend as フロントエンドページ
|
||||
participant Backend as バックエンド API
|
||||
participant Stripe as Stripe Checkout
|
||||
|
||||
User->>Frontend: 「アップグレード」または「購入」をクリック
|
||||
Frontend->>Backend: POST /api/billing/create-checkout-session
|
||||
Note right of Frontend: フロントエンドは plan / userId / email を送信\n最終的な決済金額は送信しない
|
||||
Backend->>Backend: プランを検証し priceId にマッピング
|
||||
Backend->>Stripe: Checkout Session を作成
|
||||
Stripe-->>Backend: session.url を返却
|
||||
Backend-->>Frontend: 決済リンクを返却
|
||||
Frontend-->>User: Stripe 決済ページにリダイレクト
|
||||
User->>Stripe: 支払いを完了
|
||||
```
|
||||
|
||||
## 6. クイックスタート
|
||||
|
||||
Stripe を最速でプロジェクトに組み込むには、以下の5ステップに従うだけで十分です。
|
||||
|
||||
### 6.1 ステップ1：Stripe 管理画面で商品と価格を作成する
|
||||
|
||||
このステップの目的は、「とりあえず適当に設定する」ことではなく、Stripe 上で **何を売るのか、どのように料金を徴収するのか** を明確に定義することです。
|
||||
|
||||
Stripe のモデルでは次のようになります。
|
||||
|
||||
- **Product** は「何を売るのか」を表します。例：`Pro メンバーシップ`
|
||||
- **Price** は「いくらで、どの周期で売るのか」を表します。例：`月額 9.9 ドル`、`年額 99 ドル`
|
||||
|
||||
なぜ最初にこのステップを行う必要があるのでしょうか？
|
||||
バックエンドが Checkout Session を作成する際、Stripe に金額を直接渡すのではなく、すでに存在する `price_id` を渡すからです。Stripe はこの `price_id` に基づいて、実際の決済ページ、金額、通貨、サブスクリプション周期を生成します。
|
||||
|
||||
このステップを飛ばすと、後の「決済リンクの作成」ができません。
|
||||
|
||||
::: info なぜここで立ち止まる必要があるのか
|
||||
`Product`、`Price` という言葉を見ると、Stripe の内部用語を学んでいるように感じて煩わしくなる初心者の方もいるでしょう。
|
||||
|
||||
しかし実際には、このステップは非常にシンプルなことを行っています。
|
||||
- 「何を売るのか」を明確にする
|
||||
- 「いくらで売るのか」を明確にする
|
||||
- バックエンドが後で安定した `price_id` を使って決済リンクを作成できるようにする
|
||||
|
||||
この関係を理解すれば、Checkout Session も抽象的には感じなくなります。
|
||||
:::
|
||||
|
||||
最小限のサブスクリプションシステムでは、少なくとも次の2つのレベルを最初に作成します。
|
||||
|
||||
- 1つの `Product`
|
||||
- 1つ以上の `Price`
|
||||
|
||||
以下のページを直接開けます。
|
||||
|
||||
- Stripe Dashboard ログイン：<https://dashboard.stripe.com/login>
|
||||
- Stripe 商品と価格の管理ドキュメント：<https://docs.stripe.com/products-prices/manage-prices>
|
||||
- Stripe Checkout クイックスタート：<https://docs.stripe.com/checkout/quickstart?lang=node>
|
||||
- Stripe Dashboard 商品ページ：<https://dashboard.stripe.com/test/products>
|
||||
|
||||
まずは **テストモード（Test mode）** で操作することをお勧めします。最初から本番環境で作成しないでください。
|
||||
|
||||
最も一般的な最小構成は以下の通りです。
|
||||
|
||||
- `Product`: `Pro Plan`
|
||||
- `Price 1`: `pro_monthly`
|
||||
- `Price 2`: `pro_yearly`
|
||||
|
||||
管理画面で操作する際は、次の順序で理解できます。
|
||||
|
||||
1. まず `Pro Plan` という商品を作成する
|
||||
2. その商品の下に2つの価格を紐付ける
|
||||
3. 月額と年額は同じ商品の2つの課金方式
|
||||
|
||||
完了後、少なくとも以下の情報をメモしておいてください。
|
||||
|
||||
- 月額価格の `price_id`
|
||||
- 年額価格の `price_id`
|
||||
- 自分のプラン名（例：`pro_monthly`、`pro_yearly`）
|
||||
|
||||
初めて Stripe の管理画面に入る場合は、次のように理解することをお勧めします。
|
||||
|
||||
- `Product` が決済ページで何を売るかを決める
|
||||
- `Price` が決済ページでいくら徴収するかを決める
|
||||
- バックエンドが後で実際に使うのは、主に `price_id`
|
||||
|
||||
::: info 本当にメモしておくべき値
|
||||
このページで最も重要なのは商品名ではなく、`price_id` です。
|
||||
|
||||
後で AI にバックエンドの実装を依頼する際も、自分で問題を調査する際も、頻繁に使うのは通常以下の値です。
|
||||
- `STRIPE_PRICE_PRO_MONTHLY`
|
||||
- `STRIPE_PRICE_PRO_YEARLY`
|
||||
- これらに対応する2つの `price_id`
|
||||
:::
|
||||
|
||||
AI にまず管理画面の設定を案内させたい場合は、次のプロンプトを直接使用できます。
|
||||
|
||||
```text
|
||||
私は初めて Stripe を使います。まずコードを変更せずに、Stripe 管理画面で最基本的な課金設定を手順通りに教えてください。
|
||||
|
||||
以下の公式ドキュメントに基づいて、ステップバイステップで操作説明をお願いします：
|
||||
- https://docs.stripe.com/products-prices/manage-prices
|
||||
- https://docs.stripe.com/checkout/quickstart?lang=node
|
||||
|
||||
私の状況：
|
||||
- 最もシンプルなメンバーシップ課金をしたい
|
||||
- 月額と年額の2つのプランのみ
|
||||
- Product と Price という言葉の意味がまだ分からない
|
||||
|
||||
お願い：
|
||||
1. まず Product と Price がそれぞれ何かを最も分かりやすい言葉で説明してください。
|
||||
2. 「どのページを開き → どこをクリックし → 何を入力するか」の順に教えてください。
|
||||
3. 最後に、設定完了後に管理画面からコピーすべき値を教えてください。
|
||||
4. 間違いやすいポイントがあれば、テストモードで操作することも併せて教えてください。
|
||||
```
|
||||
|
||||
### 6.2 ステップ2：環境変数の準備
|
||||
|
||||
通常、少なくとも以下の環境変数を準備する必要があります。
|
||||
|
||||
- `STRIPE_SECRET_KEY`
|
||||
- `STRIPE_WEBHOOK_SECRET`
|
||||
- `STRIPE_PRICE_PRO_MONTHLY`
|
||||
- `STRIPE_PRICE_PRO_YEARLY`
|
||||
- `APP_URL`
|
||||
- `SUPABASE_URL`
|
||||
- `SUPABASE_SERVICE_ROLE_KEY`
|
||||
|
||||
以下のページを直接開けます。
|
||||
|
||||
- Stripe API Keys ドキュメント：<https://docs.stripe.com/keys>
|
||||
- Stripe Dashboard API Keys ページ：<https://dashboard.stripe.com/test/apikeys>
|
||||
- Stripe Webhooks ドキュメント：<https://docs.stripe.com/webhooks>
|
||||
- Stripe Dashboard Webhooks ページ：<https://dashboard.stripe.com/test/workbench/webhooks>
|
||||
|
||||
> **注意**：`STRIPE_SECRET_KEY` と `SUPABASE_SERVICE_ROLE_KEY` は必ずバックエンドにのみ配置してください。
|
||||
|
||||
::: info 環境変数の目的
|
||||
このステップは「`.env` を埋める」ことが目的ではなく、決済システムの中で最も機密性の高い要素をバックエンドに保管することが目的です。
|
||||
|
||||
- Stripe のバックエンドシークレットキー
|
||||
- Webhook 署名検証キー
|
||||
- 自分の価格マッピング
|
||||
|
||||
端的に言えば、フロントエンドは購入の開始のみを担当し、本当のシークレットと価格設定ロジックはすべてサーバー側に残すべきです。
|
||||
:::
|
||||
|
||||
このステップも AI に整理を依頼できます。
|
||||
|
||||
```text
|
||||
私のプロジェクトが現在どのように環境変数を管理しているかを確認し、Stripe に必要な環境変数を整理してください。
|
||||
|
||||
以下のドキュメントを参考にしてください：
|
||||
- https://docs.stripe.com/keys
|
||||
- https://docs.stripe.com/webhooks
|
||||
|
||||
私の状況：
|
||||
- 初心者です
|
||||
- どの変数をフロントエンドに置き、どれをバックエンドに置くべきか分からない
|
||||
- 現在のプロジェクトで `.env`、`.env.local` など、どのファイルを変更すべきかも分からない
|
||||
|
||||
お願い：
|
||||
1. まず現在のプロジェクト内で環境変数が通常どこに書かれているかを検索してください。
|
||||
2. Stripe 導入に最低限必要な変数をリストアップしてください。
|
||||
3. 各変数の役割を最も分かりやすい言葉で説明してください。
|
||||
4. 各変数をどの Stripe ページからコピーすればよいか教えてください。
|
||||
5. プロジェクトにサンプル環境変数ファイルがあれば、変数名を直接追加してください。
|
||||
```
|
||||
|
||||
### 6.3 ステップ3：バックエンドで Checkout Session を作成する
|
||||
|
||||
このステップは自分でインターフェースを書く必要はありません。AI に公式ドキュメントを参考にして実装させましょう。
|
||||
|
||||
まず以下のドキュメントを AI に渡します。
|
||||
|
||||
- Stripe Checkout クイックスタート：<https://docs.stripe.com/checkout/quickstart?lang=node>
|
||||
- Checkout Sessions API：<https://docs.stripe.com/api/checkout/sessions/create>
|
||||
- サブスクリプション説明：<https://docs.stripe.com/payments/subscriptions>
|
||||
|
||||
そして次のプロンプトを貼り付けます。
|
||||
|
||||
```text
|
||||
現在のプロジェクトのバックエンドコードの構成を確認し、Stripe 決済を組み込んでください。
|
||||
|
||||
以下の公式ドキュメントを参考にしてください：
|
||||
- https://docs.stripe.com/checkout/quickstart?lang=node
|
||||
- https://docs.stripe.com/api/checkout/sessions/create
|
||||
- https://docs.stripe.com/payments/subscriptions
|
||||
|
||||
私の目標はシンプルです：
|
||||
- ユーザーが購入ボタンをクリックした後、Stripe の支払いページに遷移する
|
||||
- プランは月額と年額の2種類のみ
|
||||
- コードをどこに置くべきか自分で判断せず、まずプロジェクトを見て適切な場所に配置してください
|
||||
|
||||
お願い：
|
||||
1. まずプロジェクト内を検索し、バックエンドのエントリーファイル、ルーティングファイル、環境変数の書き方がどこにあるか把握してください。
|
||||
2. 公式ドキュメントを参考に、「Stripe 決済リンクの作成」ステップを組み込んでください。
|
||||
3. 金額は自分で指定させるのではなく、バックエンドの環境変数で価格を決定してください。
|
||||
4. 完了後、どのファイルを変更したか教えてください。
|
||||
5. 最後に、Stripe 管理画面でまだ追加が必要な設定があれば教えてください。
|
||||
```
|
||||
|
||||
### 6.4 ステップ4：フロントエンドから決済ページにリダイレクトする
|
||||
|
||||
このステップの目標は非常にシンプルです。価格ページのボタンからバックエンドのインターフェースを呼び出し、Stripe Checkout にリダイレクトさせます。
|
||||
|
||||
参考ドキュメント：
|
||||
|
||||
- Stripe Checkout 統合説明：<https://docs.stripe.com/payments/checkout/build-integration>
|
||||
|
||||
AI 用プロンプト：
|
||||
|
||||
```text
|
||||
プロジェクト内の「購入」ボタンに Stripe を接続してください。
|
||||
|
||||
要件：
|
||||
- 既存のページは変更せず、ボタンクリック後のロジックのみを変更する
|
||||
- クリック後にバックエンドインターフェースを呼び出して決済リンクを取得し、Stripe にリダイレクトする
|
||||
- エラーが発生した場合は、ユーザーにシンプルなメッセージを表示（例：「現在決済機能を利用できません。しばらくしてからお試しください」）
|
||||
|
||||
参考ドキュメント：https://docs.stripe.com/payments/checkout/build-integration
|
||||
```
|
||||
|
||||
### 6.5 ステップ5：Webhook でデータベースステータスを更新する
|
||||
|
||||
これが最も重要なステップです。
|
||||
|
||||
::: info なぜこのステップが最も重要なのか
|
||||
「ユーザーが支払いを完了し、success ページに遷移した」だけで完了と思っている人が多いです。
|
||||
|
||||
違います。
|
||||
|
||||
あなたのシステムにとって本当に重要なのは、
|
||||
**Stripe が Webhook を通じて正式にあなたのサーバーにイベントを送信し、バックエンドがデータベースのステータス更新に成功したかどうか** です。
|
||||
:::
|
||||
|
||||
AI に Stripe 公式の Webhook ドキュメントに従って直接実装させ、自分で手書きしないようにしましょう。
|
||||
|
||||
参考ドキュメント：
|
||||
|
||||
- Stripe Webhooks：<https://docs.stripe.com/webhooks>
|
||||
- Stripe CLI：<https://docs.stripe.com/stripe-cli>
|
||||
- Stripe CLI 使用方法：<https://docs.stripe.com/stripe-cli/use-cli>
|
||||
|
||||
AI 用プロンプト：
|
||||
|
||||
```text
|
||||
Stripe の「支払い成功後に自動で有効化する」ステップを引き続き実装してください。
|
||||
|
||||
以下の公式ドキュメントを参考にしてください：
|
||||
- https://docs.stripe.com/webhooks
|
||||
- https://docs.stripe.com/stripe-cli
|
||||
- https://docs.stripe.com/stripe-cli/use-cli
|
||||
|
||||
私の目標：
|
||||
- ユーザーが支払いを完了した後、ただ success ページに遷移するだけではなく
|
||||
- 本当にデータベース内のメンバーシップステータスを「有効」に変更したい
|
||||
|
||||
お願い：
|
||||
1. まず現在のプロジェクト内でデータベース関連のコードとユーザーステータスの保存方法を検索してください。
|
||||
2. Stripe Webhook を追加してください。
|
||||
3. 支払い成功後、該当ユーザーを active に変更するか、プロジェクトで現在使用しているメンバーシップステータスフィールドを更新してください。
|
||||
4. プロジェクトに既存のサブスクリプションテーブル、オーダーテーブル、ユーザーテーブルがあれば、既存の構造を優先して使用してください。
|
||||
5. 完了後、どのファイルを変更したか教えてください。
|
||||
6. ローカルでこのステップが本当に機能しているかを確認する方法も教えてください。
|
||||
```
|
||||
|
||||
## 7. AI に素早く導入させるためのプロンプト
|
||||
|
||||
Codex、Claude Code、Trae、Cursor などのツールを使用している場合、以下のプロンプトを直接貼り付けて、プロジェクトに決済導入を行わせることができます。
|
||||
|
||||
```text
|
||||
現在のプロジェクトに Stripe 決済を組み込んでください。最もシンプルに動作するメンバーシップ課金機能を実装したいと考えています。
|
||||
|
||||
私の要件：
|
||||
1. 私は初心者なので、まずプロジェクトを確認してから、コードをどこに変更すべきか判断してください。
|
||||
2. ディレクトリ構造、ルーティング構造、データベース構造は自分で判断しないでください。
|
||||
3. 最もシンプルなバージョンのみを作成：月額と年額の2つのプラン。
|
||||
4. ユーザーが購入をクリックした後、Stripe の支払いページに遷移する。
|
||||
5. 支払い成功後、データベースのメンバーシップステータスが「有効」になる。
|
||||
6. 最初から複雑な機能（クーポン、アップグレード/ダウングレード、複雑な請求書など）は追加しないでください。
|
||||
|
||||
出力要件：
|
||||
1. まず変更計画を提示してください。
|
||||
2. その後、コードを直接変更してください。
|
||||
3. 最後に、ローカルでステップバイステップでテストする方法を説明してください。
|
||||
4. Stripe 管理画面での操作が必要なステップがあれば、リンクと要点を直接教えてください。
|
||||
```
|
||||
|
||||
AI にプロジェクトにより密接に対応させたい場合は、先頭に以下の情報を追加することもできます。
|
||||
|
||||
- 使用しているフロントエンドフレームワーク
|
||||
- バックエンドのディレクトリ構造
|
||||
- データベースのテーブル名
|
||||
- 現在のユーザー認証が Supabase Auth か自前の Auth か
|
||||
|
||||
## 7.1 ローカル連携テストも AI に任せる
|
||||
|
||||
ローカル連携テストも AI に一任したい場合は、以下のプロンプトをそのまま使用できます。
|
||||
|
||||
```text
|
||||
Stripe 決済を本当に動作するようにしてください。ステップバイステップで実行したいので、推測は避けたいと考えています。
|
||||
|
||||
以下の公式ドキュメントを参考にしてください：
|
||||
- https://docs.stripe.com/webhooks
|
||||
- https://docs.stripe.com/stripe-cli
|
||||
- https://docs.stripe.com/stripe-cli/use-cli
|
||||
|
||||
私の目標：
|
||||
1. まずどの Stripe ページを開けばよいか教えてください。
|
||||
2. STRIPE_WEBHOOK_SECRET の取得方法を教えてください。
|
||||
3. stripe login と stripe listen の使用方法を教えてください。
|
||||
4. checkout.session.completed がローカル Webhook に正常に送信されたことを確認する方法を教えてください。
|
||||
5. 現在のプロジェクトでフロントエンドとバックエンドを先に起動する必要があれば、具体的なコマンドも教えてください。
|
||||
6. 原理だけではなく、実際の操作手順に従って出力してください。
|
||||
7. あるステップで間違えた場合、最もよくあるエラーメッセージがどのようなものかも教えてください。
|
||||
```
|
||||
|
||||
## 8. 最も陥りやすい4つの落とし穴
|
||||
|
||||
1. **`success` ページを決済成功とみなす**
|
||||
本当にステータスを決定するのは Webhook であり、フロントエンドのリダイレクトではありません。
|
||||
2. **フロントエンドに金額を渡させる**
|
||||
これには深刻な価格改ざんリスクが伴います。
|
||||
3. **Webhook ルートが `express.json()` によって先に処理される**
|
||||
Stripe の署名検証には元のリクエストボディが必要です。
|
||||
4. **冪等処理を行っていない**
|
||||
Webhook は再試行される可能性があります。毎回メンバーシップやクレジットを重複して追加すると、事故につながります。
|
||||
|
||||
## 9. ワンラインでの選択アドバイス
|
||||
|
||||
今すぐ決済を動かしたい場合。
|
||||
|
||||
| 主なユーザー | 最初に試すべきソリューション |
|
||||
| :--- | :--- |
|
||||
| 海外 SaaS / 国際ユーザー | Stripe |
|
||||
| 中国大陸のユーザー | Alipay / WeChat Pay |
|
||||
| 香港またはクロスボーダーチーム | Stripe + ローカルウォレット / FPS 統合ソリューション |
|
||||
|
||||
具体的な違いについては、付録でまとめて説明します。
|
||||
|
||||
::: info 最もシンプルな選択の考え方
|
||||
最初から「世界中のすべての決済方法を一度に導入する」と考える必要はありません。
|
||||
|
||||
より現実的な順序は通常次の通りです。
|
||||
- まず主なユーザーの地域に合わせてメインの決済チェーンを1つ選ぶ
|
||||
- 最小実現可能な決済をまず動かす
|
||||
- その後、実際のユーザー来源に基づいて第2、第3の決済方法を追加していく
|
||||
:::
|
||||
|
||||
## 10. まとめ
|
||||
|
||||
ここまでで、最も基本でありながら最も重要な決済チェーンを習得しました。
|
||||
|
||||
1. フロントエンドが購入を開始する。
|
||||
2. バックエンドが Checkout Session を作成する。
|
||||
3. ユーザーが Stripe のページで支払う。
|
||||
4. Stripe が Webhook でバックエンドに通知する。
|
||||
5. バックエンドがデータベースを更新する。
|
||||
6. フロントエンドがリフレッシュ後、新しいメンバーシップやオーダーのステータスを表示する。
|
||||
|
||||
決済を素早くプロジェクトに組み込むだけであれば、前半の内容ですでに十分です。以下の付録は、実際に問題に遭遇した時に改めて参照してください。
|
||||
|
||||
---
|
||||
|
||||
# 付録
|
||||
|
||||
## 付録 A：Stripe で最もよく登場するオブジェクト
|
||||
|
||||
Stripe のドキュメントを初めて読む際、これらのオブジェクト名に最も戸惑うでしょう。まずは以下のものだけ理解すれば十分です。
|
||||
|
||||
| オブジェクト | 役割 | 例え |
|
||||
| :--- | :--- | :--- |
|
||||
| `Product` | 何を売るかを表す | 商品またはメンバーシッププラン |
|
||||
| `Price` | いくらで、どの周期で売るかを表す | 月額、年額、買い切り |
|
||||
| `Checkout Session` | Stripe がホストする決済フロー | 支払いページ |
|
||||
| `Subscription` | 定期サブスクリプション関係 | 自動更新メンバーシップ |
|
||||
| `Customer` | 支払いユーザー | Stripe 内の顧客プロファイル |
|
||||
| `Webhook` | 非同期通知 | Stripe が「この支払いがどうなったか」を伝える |
|
||||
|
||||
## 付録 B：なぜ `success` ページは決済成功を意味しないのか
|
||||
|
||||
「ユーザーが支払いを完了し、success ページに遷移した」だけで決済成功とみなす人がたくさんいます。これが最も陥りやすい落とし穴です。
|
||||
|
||||
### 実際のシナリオ
|
||||
|
||||
メンバーシップサイトを作ったとします。
|
||||
|
||||
1. ユーザーが「メンバーシップを購入」をクリックする
|
||||
2. Stripe の支払いページにリダイレクトされる
|
||||
3. ユーザーがクレジットカード情報を入力し、支払いをクリックする
|
||||
4. ページが `success.html` にリダイレクトされる
|
||||
5. success ページで「このページに来たのだから、メンバーシップを有効化する」というコードを書く
|
||||
|
||||
**問題点は？**
|
||||
|
||||
ユーザーは実際には支払っていなくても、支払いの途中でページを閉じても、`success.html` に直接アクセスできます。
|
||||
|
||||
### 2つの全く異なる経路
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
pay["ユーザーが Stripe で支払いを完了"]
|
||||
|
||||
subgraph unreliable["❌ 信頼できない経路：success ページのみを見る"]
|
||||
success["ブラウザが success ページに遷移"]
|
||||
fake["フロントエンドコードが有効化済みと判断"]
|
||||
risk["リスク：ページを閉じる / 通信切断 / URL 偽造 / 未支払い"]
|
||||
success --> fake --> risk
|
||||
end
|
||||
|
||||
subgraph reliable["✅ 信頼できる経路：バックエンド Webhook を正とする"]
|
||||
event["Stripe サーバーが Webhook を送信"]
|
||||
verify["バックエンドが署名を検証"]
|
||||
active["データベースが正式に「支払済み」に更新"]
|
||||
event --> verify --> active
|
||||
end
|
||||
|
||||
pay --> success
|
||||
pay --> event
|
||||
```
|
||||
|
||||
**重要な違い：**
|
||||
|
||||
| | success ページ遷移 | Webhook 通知 |
|
||||
| :--- | :--- | :--- |
|
||||
| 誰が開始するか | ユーザーのブラウザ | Stripe のサーバー |
|
||||
| 偽造可能か | 可能。URL に直接アクセスすればよい | 不可能。署名検証がある |
|
||||
| 必ず支払い成功を意味するか | 意味しない | 意味する |
|
||||
| システムがどう知るか | フロントエンドコードの推測 | Stripe からの正式通知 |
|
||||
|
||||
### 完全なフローはどうあるべきか
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as ユーザー
|
||||
participant Frontend as ウェブページ
|
||||
participant Stripe as Stripe
|
||||
participant Webhook as バックエンドインターフェース
|
||||
participant DB as データベース
|
||||
|
||||
User->>Stripe: Stripe ページで支払いを完了
|
||||
Note over Stripe: 資金が実際に Stripe アカウントに到着
|
||||
|
||||
Stripe-->>Frontend: ブラウザが success ページにリダイレクト
|
||||
Note over Frontend: ⚠️ このステップは単なる遷移<br/>システムの確認を意味しない
|
||||
|
||||
Stripe->>Webhook: Webhook 通知を送信<br/>"checkout.session.completed"
|
||||
Note over Webhook: ✅ これが正式な通知
|
||||
|
||||
Webhook->>Webhook: 署名を検証<br/>（Stripe からの送信であることを確認）
|
||||
|
||||
Webhook->>DB: ユーザーステータスを「支払済み」に更新
|
||||
DB-->>Webhook: 保存成功
|
||||
Webhook-->>Stripe: 200 OK を返却
|
||||
|
||||
Frontend->>DB: ユーザーがページをリフレッシュし、ステータスを照会
|
||||
DB-->>Frontend: 「支払済み」を返却
|
||||
Note over Frontend: この時点でメンバーシップ機能を表示
|
||||
```
|
||||
|
||||
### 各ステップのポイント
|
||||
|
||||
**ステップ1：ユーザーが Stripe で支払う**
|
||||
|
||||
「お金が本当に支払われた」ことが確定する唯一の瞬間です。
|
||||
- ユーザーがクレジットカード情報を入力し、確認をクリックする
|
||||
- 銀行がユーザーのカードから引き落とす
|
||||
- Stripe がこの支払いの受領を確認する
|
||||
|
||||
**ステップ2：ブラウザが success ページにリダイレクト（最大の問題点）**
|
||||
|
||||
このステップは全く信頼できません。理由は以下の通りです。
|
||||
- ユーザーはブラウザで直接 `yoursite.com/success` と入力でき、支払っていなくてもアクセスできる
|
||||
- ユーザーが支払いの途中でページを閉じたが、以前に success リンクをコピーしており、後で直接開く
|
||||
- ネットワークの問題で遷移に失敗するが、引き落としは完了している（ユーザーは支払ったのに成功ページが表示されない）
|
||||
- ユーザーが戻るボタンを押して、再度支払うが、どちらも同じ success ページに遷移する
|
||||
|
||||
**ステップ3：Stripe が Webhook を送信する**
|
||||
|
||||
Stripe が能動的にサーバーに「この支払いが到着した」ことを通知します。
|
||||
- Stripe サーバーのみがこのリクエストを発行できる
|
||||
- リクエストには署名が含まれており、バックエンドで本当に Stripe からのものか検証できる
|
||||
- success ページが開かれていなくても、ユーザーの通信が切断していても、Webhook は送信される
|
||||
|
||||
**ステップ4：バックエンドが署名を検証する**
|
||||
|
||||
なぜ検証が必要なのか？ハッカーによる偽の通知を防ぐためです。
|
||||
|
||||
検証がない場合、ハッカーはあなたのサーバーに「ユーザー A が 1000 元支払った」という偽の通知を送信でき、システムがハッカーにメンバーシップを付与してしまいます。
|
||||
|
||||
検証のプロセス：
|
||||
- Stripe が双方で合意したシークレットキーを使って通知内容の署名を生成する
|
||||
- バックエンドが同じシークレットキーで署名が一致するか検証する
|
||||
- 一致 = 100% Stripe からの送信、不一致 = 直ちに拒否
|
||||
|
||||
**ステップ5：データベースを更新する**
|
||||
|
||||
検証が通った後にのみ、データベースを更新します。
|
||||
- ユーザーステータスを「支払待ち」から「支払済み」に変更
|
||||
- オーダー番号、金額、支払い時刻を記録
|
||||
- 対応するメンバーシップ権限を有効化
|
||||
|
||||
**ステップ6：フロントエンドがステータスを照会する**
|
||||
|
||||
success ページで「このページに来たから成功」と判断してはいけません。正しいやり方は以下の通りです。
|
||||
- ページ読み込み時にバックエンドにリクエストを送る。「このユーザーは支払い済みか？」
|
||||
- バックエンドがデータベースを検索し、実際のステータスを返す
|
||||
- 返された結果に基づいて「有効化成功」または「確認中」を表示する
|
||||
|
||||
### よくある誤った実装
|
||||
|
||||
```javascript
|
||||
// 誤り：success ページで直接有効化
|
||||
// success.html
|
||||
if (window.location.pathname === '/success') {
|
||||
// 危険！誰でも /success にアクセス可能
|
||||
activateMembership();
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// 正しい：毎回バックエンドに確認する
|
||||
// success.html
|
||||
async function checkStatus() {
|
||||
const response = await fetch('/api/user/status');
|
||||
const data = await response.json();
|
||||
|
||||
if (data.paymentStatus === 'paid') {
|
||||
showMemberFeatures();
|
||||
} else {
|
||||
showPendingMessage();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 一言でまとめると
|
||||
|
||||
**success ページは「ブラウザのリダイレクト成功」に過ぎず、Webhook こそが「Stripe による正式な入金確認」です。**
|
||||
|
||||
システムは Webhook を正として扱い、フロントエンドのリダイレクトを信用してはいけません。
|
||||
|
||||
## 付録 C：サブスクリプションシステムで最も監視すべきイベント
|
||||
|
||||
| イベント | 意味 | 通常すべきこと |
|
||||
| :--- | :--- | :--- |
|
||||
| `checkout.session.completed` | 初回の有効化成功 | ローカルのサブスクリプションレコードを作成 |
|
||||
| `invoice.paid` | 自動更新の成功 | 有効期限を延長 |
|
||||
| `invoice.payment_failed` | 自動引き落としの失敗 | リスクステータスをマークし、ユーザーに通知 |
|
||||
| `customer.subscription.deleted` | サブスクリプションのキャンセル | 権限を回収するか、期限切れ後に無効化 |
|
||||
|
||||
### サブスクリプションの状態遷移図
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> NotStarted: ユーザー未購入
|
||||
NotStarted --> Active: checkout.session.completed
|
||||
Active --> Active: invoice.paid
|
||||
Active --> PastDue: invoice.payment_failed
|
||||
PastDue --> Active: ユーザーの追加支払い成功
|
||||
Active --> Canceled: customer.subscription.deleted
|
||||
PastDue --> Canceled: 期限内に復旧せず
|
||||
Canceled --> [*]
|
||||
|
||||
state "未有効" as NotStarted
|
||||
state "メンバーシップ有効" as Active
|
||||
state "引き落とし失敗 / 復旧待ち" as PastDue
|
||||
state "キャンセル済み / 期限切れで回収" as Canceled
|
||||
```
|
||||
|
||||
### 継続 / 失敗 / キャンセルのシーケンス図
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant Stripe as Stripe
|
||||
participant Webhook as Webhook インターフェース
|
||||
participant DB as サブスクリプションテーブル / オーダーテーブル
|
||||
participant App as アプリケーション
|
||||
actor User as ユーザー
|
||||
|
||||
rect rgb(235, 248, 255)
|
||||
Stripe->>Webhook: invoice.paid
|
||||
Webhook->>DB: current_period_end を延長
|
||||
DB-->>Webhook: 更新成功
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: メンバーシップ有効状態を維持
|
||||
end
|
||||
|
||||
rect rgb(255, 247, 237)
|
||||
Stripe->>Webhook: invoice.payment_failed
|
||||
Webhook->>DB: past_due をマーク
|
||||
DB-->>Webhook: 更新成功
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: 支払い方法の更新を促す
|
||||
end
|
||||
|
||||
rect rgb(254, 242, 242)
|
||||
Stripe->>Webhook: customer.subscription.deleted
|
||||
Webhook->>DB: canceled をマーク
|
||||
DB-->>Webhook: 更新成功
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: プレミアム権限を停止
|
||||
end
|
||||
```
|
||||
|
||||
## 付録 D：その他の決済ソリューションの選び方
|
||||
|
||||
### 1. 中国大陸
|
||||
|
||||
主なユーザーが中国大陸にいる場合、第一選択はやはり **[Alipay](https://open.alipay.com/)** と **[WeChat Pay](https://pay.wechatpay.cn/)** です。
|
||||
|
||||
**ビジネスモデル：**
|
||||
|
||||
どちらも「決済ゲートウェイ」モデルです。必要な作業は以下の通りです。
|
||||
- 商事資格の申請（営業許可証、法人口座）
|
||||
- ユーザーが支払った資金は直接あなたの商事口座に入金される
|
||||
- 税務、返金、帳簿管理は自身で担当
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
どちらも「バックエンドでオーダー作成 + フロントエンドで支払い起動 + バックエンドで通知受信」のモデルであり、Stripe と同じ考え方です。
|
||||
|
||||
**Alipay の導入フロー：**
|
||||
1. Alipay オープンプラットフォームでアプリケーションを作成
|
||||
2. 公開鍵・秘密鍵とコールバック URL を設定
|
||||
3. バックエンドで統一下注インターフェースを呼び出し、決済リンクまたは QR コードを生成
|
||||
4. ユーザーがスキャンまたはリダイレクトで支払い
|
||||
5. Alipay が非同期でバックエンドに通知し、オーダーステータスを更新
|
||||
|
||||
**WeChat Pay の導入フロー：**
|
||||
- JSAPI 決済：公式アカウントやミニプログラムに適しており、WeChat 内で直接支払い
|
||||
- Native 決済：PC で QR コードを生成し、ユーザーがスキャンして支払い
|
||||
- H5 決済：モバイルブラウザから WeChat アプリを起動して支払い
|
||||
|
||||
フロー：バックエンドでオーダー作成 → `prepay_id` または `code_url` を取得 → フロントエンドで支払い起動 → バックエンドで通知を受信して成功を確認
|
||||
|
||||
**参考リンク：**
|
||||
- Alipay オープンプラットフォーム：<https://open.alipay.com/>
|
||||
- WeChat Pay 商事ドキュメント：<https://pay.wechatpay.cn/doc/v3/merchant/>
|
||||
|
||||
### 2. 香港
|
||||
|
||||
香港市場は比較的ミックスされており、一般的な組み合わせは以下の通りです。
|
||||
|
||||
- 銀行カード：Visa / Mastercard
|
||||
- FPS（転数快）：香港ローカルの即時送金
|
||||
- AlipayHK / WeChat Pay HK：香港版の Alipay と WeChat
|
||||
|
||||
**おすすめの組み合わせ：**
|
||||
- **[Stripe](https://stripe.com/hk)** で国際カードとサブスクリプションをカバー
|
||||
- **[Airwallex](https://www.airwallex.com/)** または **[Adyen](https://www.adyen.com/)** でローカルウォレットと FPS を補完
|
||||
|
||||
### 3. 海外 / 国際 SaaS
|
||||
|
||||
#### [Stripe](https://stripe.com/)
|
||||
|
||||
**ビジネスモデル：** 決済ゲートウェイ
|
||||
|
||||
- 商事資格の申請が必要（一部の国では Stripe が代行可能）
|
||||
- ユーザーの支払いは Stripe アカウントに入金され、その後銀行口座に決済される
|
||||
- 税務申告は自身で担当
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
- API 体験が最も良く、ドキュメントが明確
|
||||
- Checkout（ホスティングページ）、Elements（カスタムフォーム）、Payment Links（ノーコード）をサポート
|
||||
- Webhook で決済ステータスを通知
|
||||
- サブスクリプション、請求書、多通貨をサポート
|
||||
|
||||
**対象者：** 海外 SaaS、独立開発者、柔軟なカスタマイズが必要なチーム
|
||||
|
||||
**参考リンク：** <https://docs.stripe.com/>
|
||||
|
||||
#### [PayPal](https://www.paypal.com/)
|
||||
|
||||
**ビジネスモデル：** 決済ゲートウェイ
|
||||
|
||||
- ユーザーの支払いは PayPal アカウントに入金され、その後銀行口座に引き出す
|
||||
- 税務は自身で担当
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
- 一回限り決済：フロントエンドにボタンを配置し、バックエンドでオーダーを作成/確認
|
||||
- サブスクリプション：先に Product と Plan を作成し、SDK で起動
|
||||
- バックエンドと Webhook が同様に必要。フロントエンドのコールバックのみを見ないこと
|
||||
|
||||
**対象者：** 追加チャネルが必要な海外ビジネス、PayPal 決済に慣れているユーザー
|
||||
|
||||
**参考リンク：** <https://developer.paypal.com/docs/>
|
||||
|
||||
#### [Paddle](https://www.paddle.com/)
|
||||
|
||||
**ビジネスモデル：** Merchant of Record (MoR)
|
||||
|
||||
- Paddle が「記録商人」となり、法的には Paddle がユーザーから代金を徴収
|
||||
- Paddle が世界の税務、VAT、返金、コンプライアンスを処理
|
||||
- ユーザーの支払いは Paddle に入金され、Paddle が税金と手数料を控除後に決済
|
||||
- 各国で法人を設立したり税務を処理したりする必要がない
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
- Paddle.js：フロントエンドにホスティング決済ページを組み込み
|
||||
- バックエンド API：transaction を作成し、checkout に渡す
|
||||
- Webhook でサブスクリプションステータスを同期
|
||||
|
||||
**対象者：** 世界の税務を処理したくない SaaS チーム、特に B2B SaaS
|
||||
|
||||
**参考リンク：** <https://developer.paddle.com/>
|
||||
|
||||
#### [Lemon Squeezy](https://www.lemonsqueezy.com/)
|
||||
|
||||
**ビジネスモデル：** Merchant of Record (MoR)
|
||||
|
||||
- Paddle と同様、Lemon Squeezy が「記録商人」
|
||||
- 世界の税務、VAT、コンプライアンスを処理
|
||||
- 2024年に Stripe に買収されたが、独立して運営
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
- Hosted Checkout：最もシンプル。直接決済リンクを生成
|
||||
- Checkout Overlay：レイヤーでページに組み込み
|
||||
- バックエンド API：checkout を作成し、柔軟にコントロール
|
||||
|
||||
**対象者：** 独立開発者、デジタル製品、ソフトウェアライセンス
|
||||
|
||||
**参考リンク：** <https://docs.lemonsqueezy.com/>
|
||||
|
||||
### 4. エンタープライズソリューション
|
||||
|
||||
#### [Airwallex（空中雲匯）](https://www.airwallex.com/)
|
||||
|
||||
**ビジネスモデル：** 決済ゲートウェイ + グローバル口座
|
||||
|
||||
- グローバル受取口座を提供（バーチャル銀行口座に類似）
|
||||
- 多通貨での受取、両替、送金をサポート
|
||||
- 税務は自身で担当
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
- Payment Links：ほぼコード不要で決済リンクを生成
|
||||
- Hosted Payment Page：ホスティングページ
|
||||
- Drop-in / Embedded / Native API：深い統合、高いカスタマイズ性
|
||||
- Alipay HK、FPS、WeChat Pay などのローカル決済方法をサポート
|
||||
|
||||
**対象者：** 香港チーム、クロスボーダービジネス、多通貨口座が必要な企業
|
||||
|
||||
**参考リンク：** <https://www.airwallex.com/docs/>
|
||||
|
||||
#### [Adyen](https://www.adyen.com/)
|
||||
|
||||
**ビジネスモデル：** 決済ゲートウェイ
|
||||
|
||||
- エンタープライズグレードの決済プラットフォーム。年間処理額は数兆ユーロ規模
|
||||
- オンライン、オフライン、モバイルの全チャネルをサポート
|
||||
- 税務は自身で担当
|
||||
|
||||
**技術モデル：**
|
||||
|
||||
- Pay by Link：最もシンプル。決済リンクを生成
|
||||
- Drop-in / Components：標準的なオンライン統合
|
||||
- 管理画面で Alipay、Alipay HK、PayMe などのローカル決済方法を有効化可能
|
||||
|
||||
**対象者：** 大規模企業、全チャネル決済が必要な企業
|
||||
|
||||
**参考リンク：** <https://docs.adyen.com/>
|
||||
|
||||
### 5. ソリューション比較
|
||||
|
||||
| ソリューション | ビジネスモデル | 税務処理 | 対象者 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Stripe | 決済ゲートウェイ | 自身で処理 | 海外 SaaS、開発者 |
|
||||
| PayPal | 決済ゲートウェイ | 自身で処理 | 海外の追加チャネル |
|
||||
| Paddle | MoR | Paddle が代行処理 | B2B SaaS、税務を管理したくない場合 |
|
||||
| Lemon Squeezy | MoR | LS が代行処理 | 独立開発者、デジタル製品 |
|
||||
| Adyen | 決済ゲートウェイ | 自身で処理 | 大規模企業 |
|
||||
| Airwallex | 決済ゲートウェイ + 口座 | 自身で処理 | クロスボーダービジネス、香港チーム |
|
||||
| Alipay / WeChat Pay | 決済ゲートウェイ | 自身で処理 | 中国大陸ユーザー |
|
||||
|
||||
### 6. 地域別のソリューション選択
|
||||
|
||||
| ターゲット市場 | 推奨ソリューション |
|
||||
| :--- | :--- |
|
||||
| 中国大陸 | Alipay / WeChat Pay |
|
||||
| 香港 | Stripe + Airwallex / Adyen |
|
||||
| 海外 SaaS | Stripe（税務を自身で管理）または Paddle（MoR が代行） |
|
||||
| 海外デジタル製品 | Stripe / Lemon Squeezy / Paddle |
|
||||
| 複数地域エンタープライズ | Adyen / Airwallex / Stripe の組み合わせ |
|
||||
@@ -0,0 +1,490 @@
|
||||
# Web アプリケーションのデプロイ方法
|
||||
|
||||
本チュートリアルでは、あなたの Web アプリケーションをインターネット上にデプロイし、他の人がアクセスできるようにする方法を紹介します。**Tencent CloudBase**、**Vercel**、**Zeabur** という3つの一般的なデプロイプラットフォームを紹介し、「コードを書く」から「他の人がインターネット上であなたのウェブサイトにアクセスできる」までの完全なプロセスを迅速に完了できるようサポートします。
|
||||
|
||||
# 「デプロイ」とは何か？
|
||||
|
||||
始める前に、「デプロイ（Deployment）」の意味をはっきりさせましょう。ウェブサイトが外部ユーザーにアクセスされるためには、公開アクセス可能なネットワークアドレス（IP アドレス、例えば 123.45.67.89、またはドメイン名、例えば [google.com](https://google.com/) など）が必要です。しかし、アドレスだけでは不十分です。あなたが書いたウェブページコード（HTML、CSS、JavaScript ファイル、あるいは React、Vue などのフレームワークで書いたプロジェクト）や、関連する画像・動画リソースは、すべて24時間稼働のサーバー上に配置し、そのサーバーがネットワークリクエストに応答するようにする必要があります。そうしてはじめて、誰もがブラウザからこれらのリソースにアクセスしてダウンロードできるようになります。
|
||||
|
||||
|
||||
|
||||
画像出典：https://www.hostinger.com/tutorials/what-is-cloud-hosting
|
||||
|
||||
リソースのアップロード、環境の設定、そしてサービスを「稼働させる」までの一連のプロセス全体が**デプロイ（Deployment）**と呼ばれます。
|
||||
|
||||
簡単に言えば：自分のパソコンで書いたウェブページは、ローカルでプログラムを起動しても、自分のブラウザからしかローカルアドレスでアクセスできません。なぜなら、そのコードはあなたのハードディスク上にしか存在しないからです。「デプロイ」とは、あなたのコードとリソースをパブリックネットワークに接続された専用サーバーに移行し、適切に設定して、そのサーバーが「他の人がアクセスしたときにどう応答するか」を分かるようにすることです。例えば、誰かがブラウザにあなたのドメイン名を入力したとき、サーバーはすぐに対応するウェブページファイルを見つけ、その内容を相手のデバイスに送信し、ユーザーにあなたのページを表示させます。
|
||||
|
||||
手動でデプロイする場合、プロジェクトにはしばしば複数のステップが必要で、各ステップでつまずく可能性があります。一般的な重要ステップは以下の通りです：
|
||||
|
||||
1. **サーバーの準備**：まずクラウドサーバー（Alibaba Cloud、Tencent Cloud、AWS EC2 など）を購入し、サーバーの所在地（上海、シンガポールなど）、スペック（CPU、メモリ、ディスクサイズなど）を選択し、リモートでサーバーに接続する方法（SSH ツールを使ったログインなど）も学ぶ必要があります。
|
||||
|
||||
2. **環境の設定**：Web アプリケーションは特定の「環境」でなければ動作しません。例えば、Node.js プロジェクトを実行するには、まず Node.js をインストールする必要があります。Python プロジェクトを実行するには、Python と対応するサードパーティライブラリをインストールする必要があります。環境のバージョンが一致しないと、プログラムがエラーを起こしたり、起動しなかったりする可能性があります。
|
||||
3. **リソースのアップロード**：ローカルのコードとリソースをサーバーにアップロードする必要があります。一般的な方法には FTP や Git があります。プロジェクトのサイズが大きい場合（動画ファイルを含む場合など）、途中で接続が切れると、アップロードをやり直す必要があることもあります。
|
||||
|
||||
|
||||
|
||||
4. **サービスの起動とテスト**：アップロード完了後、サーバー上でコマンドを実行してアプリケーションを起動し、「割り当てられたネットワークアドレスにアクセスできるか」をテストする必要があります。アクセスできない場合、サーバーのファイアウォールが対応するポートを開放していない可能性があります（例えば、アプリケーションがポート3000をリッスンしていても、そのポートがファイアウォールにブロックされているなど）。あるいは、プログラム自体にバグがある可能性もあり、その場合はサーバーログを確認してトラブルシューティングを行う必要があります。
|
||||
> 💡 ポートは、同じデバイス上の異なるアプリケーションを区別する「部屋番号」、IP はそのデバイスの「住所」と考えることができます。IP とポートを組み合わせる（IP:port）ことで、特定のネットワークサービスを正確に特定できます。
|
||||
5. **保守と更新**：コードを変更するたびに、再度アップロードしてサービスを再起動する必要があります。サーバーがダウンした場合（停電やネットワーク障害など）、アプリケーションを手動で再起動する必要があり、「プロセス監視ツール」を追加で設定して、異常終了後にプログラムが自動的に再起動するようにすることもあります。
|
||||
|
||||
CloudBase、Vercel、Zeabur のような「ローコードデプロイプラットフォーム」は、まさにこれらの複雑な問題を解決するために誕生しました。これらは「サーバーの購入、環境の設定、コードのアップロード、サービスの起動、稼働の監視」といったステップを自動的に完了してくれます。必要なのは、自分のコードリポジトリ（GitHub や GitLab など）をプラットフォームに接続するか、コードを直接アップロードするだけで、プラットフォームが自動的にコードを取得し、アプリケーションの種類を識別し、対応するランタイム環境を設定し、最後に誰もがアクセスできるパブリックネットワークアドレスを提供してくれます。さらに、自分のドメイン名をワンクリックでバインドすることもできます。
|
||||
|
||||
|
||||
|
||||
次に、これら3つのプラットフォームの特徴と使用方法をそれぞれ紹介し、自分に最も適したデプロイソリューションを選べるようにします。
|
||||
|
||||
---
|
||||
|
||||
# デプロイプラットフォームの比較
|
||||
|
||||
| プラットフォーム | 特徴 | 適用シナリオ | 無料枠 |
|
||||
|------|------|----------|----------|
|
||||
| **Tencent CloudBase** | 中国国内からのアクセスが速く、WeChat エコシステムと深く統合 | 中国国内ユーザー中心、WeChat ミニプログラムのサポートが必要なプロジェクト | 無料枠あり |
|
||||
| **Vercel** | フロントエンドフレームワークのサポートが良く、GitHub と緊密に統合 | React/Vue/Next.js などのモダンフロントエンドプロジェクト | 無料枠あり |
|
||||
| **Netlify** | 機能が充実、フォーム処理や認証機能をサポート、Git との統合が良好 | フォーム処理や認証機能などの高度な機能を必要とする静的サイト | 無料枠あり |
|
||||
| **Zeabur** | 複数の言語とサービステンプレートをサポート、柔軟な設定 | 複数のサービス（Dify、n8n など）をデプロイする必要がある複雑なプロジェクト | 毎月約5ドルの無料枠 |
|
||||
|
||||
---
|
||||
|
||||
# 1. Tencent CloudBase
|
||||
|
||||
Tencent CloudBase（クラウド開発）は、Tencent Cloud が提供するワンストップバックエンドクラウドサービスで、特に中国国内の開発者に適しています。その利点は以下の通りです：
|
||||
|
||||
- **国内アクセスが速い**：サーバーが中国国内にあり、アクセス遅延が低い
|
||||
- **WeChat エコシステムとの統合**：WeChat ミニプログラムや公式アカウントとの連携が容易
|
||||
- **ワンストップソリューション**：静的サイトホスティング、クラウド関数、データベース、ストレージなどのフルセットのサービスを提供
|
||||
- **十分な無料枠**：個人開発者に十分な無料リソース枠を提供
|
||||
|
||||
## CloudBase を使用した Web アプリケーションのデプロイ
|
||||
|
||||
### ステップ 1：登録とログイン
|
||||
|
||||
[Tencent CloudBase コンソール](https://console.cloud.tencent.com/tcb) にアクセスし、WeChat または QQ でログインします。
|
||||
|
||||
### ステップ 2：環境の作成
|
||||
|
||||
「新規作成」をクリックし、環境名（例：`my-web-app`）を選択します。
|
||||
|
||||
> ⚠️ **注意**：CloudBase の無料体験版を有効にするには引き換えコードが必要です。Tencent CloudBase の公式アカウントをフォローし、「引き換えコードを受け取る」と入力して無料体験版の引き換えコードを取得し、環境作成時にコードを入力すると無料環境が有効になります（無料体験期間は6ヶ月です）。
|
||||
|
||||
### ステップ 3：静的サイトホスティングの有効化
|
||||
|
||||
環境管理ページで「静的サイトホスティング」機能を見つけて有効にします。有効化後、デフォルトのアクセスドメイン名が付与されます。
|
||||
|
||||
CloudBase の静的サイトホスティングは、Zeabur と同様に複数のデプロイ方法を提供しています：
|
||||
|
||||
- **ローカルプロジェクトのアップロード**：構築済みの静的ファイル（HTML、CSS、JS など）をローカルから直接アップロード
|
||||
- **テンプレートデプロイ**：预设のテンプレートを使用してプロジェクトを迅速に作成（React Web アプリケーションテンプレート、Vue Web アプリケーションテンプレートなど）
|
||||
- **Git リポジトリデプロイ**：GitHub などのコードリポジトリからの自動コード取得とデプロイをサポート
|
||||
|
||||
### ステップ 4：コードのデプロイ
|
||||
|
||||
静的サイトホスティングページで、CloudBase は3つのデプロイ方法を提供しています：
|
||||
|
||||
**方法1：ローカルプロジェクトのデプロイ（ローカルプロジェクトのアップロード）**
|
||||
- コンソールで「ローカルプロジェクトのデプロイ」を選択
|
||||
- 構築済みの静的ファイル（HTML、CSS、JS など）を直接アップロード
|
||||
- ローカルで構築済みのプロジェクトフォルダ（`dist` や `build` ディレクトリなど）を選択
|
||||
- アップロード完了を待つだけでアクセス可能
|
||||
|
||||
**方法2：テンプレートデプロイ**
|
||||
- 预设のテンプレートを使用してプロジェクトを迅速に作成
|
||||
- React Web アプリケーションテンプレート、Vue Web アプリケーションテンプレートなどをサポート
|
||||
- テンプレートに基づいて自動的に構築およびデプロイ
|
||||
|
||||
**方法3：Git リポジトリのデプロイ**
|
||||
- **Git 個人リポジトリのデプロイ**：あなたの GitHub などの個人コードリポジトリをバインド
|
||||
- **パブリックリポジトリのデプロイ**：パブリックの Git リポジトリからのコード取得をサポート
|
||||
- 自動ビルドコマンドを設定（例：`npm run build`）
|
||||
- コードをプッシュするたびに自動的に再デプロイ
|
||||
|
||||
> 💡 **ヒント**：CLI ツールを使用してデプロイすることも可能です：
|
||||
> ```bash
|
||||
> # CloudBase CLI のインストール
|
||||
> npm install -g @cloudbase/cli
|
||||
> # ログイン
|
||||
> tcb login
|
||||
> # デプロイ
|
||||
> tcb hosting deploy ./dist -e your-env-id
|
||||
> ```
|
||||
|
||||
### ステップ 5：カスタムドメインの設定（オプション）
|
||||
|
||||
静的サイトホスティングの設定で、独自のドメイン名をバインドし、無料の HTTPS 証明書を申請できます。
|
||||
|
||||
---
|
||||
|
||||
# 2. Vercel
|
||||
|
||||
Vercel は、世界で最も人気のあるフロントエンドデプロイプラットフォームの一つで、React、Vue、Next.js などのモダンフロントエンドフレームワークプロジェクトのデプロイに特に適しています。その特徴は以下の通りです：
|
||||
|
||||
- **GitHub との深い統合**：コードをプッシュするだけで自動デプロイ
|
||||
- **自動プレビュー**：各 Pull Request が独立したプレビューリンクを生成
|
||||
- **グローバル CDN**：ウェブサイトが自動的に世界中のノードに配布され、アクセス速度が速い
|
||||
- **サーバーレス関数**：プロジェクト内でバックエンド API を記述可能
|
||||
|
||||
> ⚠️ **注意**：Vercel は一部のネットワーク環境でアクセスが不安定な場合があります。中国国内のユーザーは CloudBase を優先することをお勧めします。
|
||||
|
||||
## Vercel を使用した Web アプリケーションのデプロイ
|
||||
|
||||
### ステップ 1：アカウントの登録
|
||||
|
||||
[Vercel 公式サイト](https://vercel.com/) にアクセスし、GitHub アカウントでログインします。
|
||||
|
||||
### ステップ 2：プロジェクトのインポート
|
||||
|
||||
1. 「Add New Project」をクリック
|
||||
2. デプロイしたい GitHub リポジトリを選択
|
||||
3. 希望するリポジトリが表示されない場合は、「Adjust GitHub App Permissions」をクリックしてアクセスを許可
|
||||
|
||||
### ステップ 3：ビルド設定の構成
|
||||
|
||||
Vercel はプロジェクトタイプを自動的に識別し、ビルドコマンドを設定します：
|
||||
|
||||
| フレームワーク | ビルドコマンド | 出力ディレクトリ |
|
||||
|------|----------|----------|
|
||||
| React | `npm run build` | `build` |
|
||||
| Vue | `npm run build` | `dist` |
|
||||
| Next.js | `next build` | - |
|
||||
| 純粋な HTML | - | プロジェクトのルートディレクトリ |
|
||||
|
||||
自動識別が正しくない場合は、手動で変更できます：
|
||||
- **Build Command**：ビルドコマンド（例：`npm run build`）
|
||||
- **Output Directory**：ビルド出力ディレクトリ（例：`dist` や `build`）
|
||||
- **Install Command**：依存関係のインストールコマンド（通常は `npm install`）
|
||||
|
||||
### ステップ 4：デプロイ
|
||||
|
||||
「Deploy」ボタンをクリックし、ビルドの完了を待ちます。ビルド成功後、`xxx.vercel.app` というドメイン名が付与されます。
|
||||
|
||||
### ステップ 5：カスタムドメイン（オプション）
|
||||
|
||||
プロジェクト設定の「Domains」ページで、独自のドメイン名を追加できます。Vercel が自動的に HTTPS を設定します。
|
||||
|
||||
---
|
||||
|
||||
# 3. Netlify
|
||||
|
||||
Netlify は、Vercel と並んで非常に人気のあるフロントエンドデプロイプラットフォームで、静的サイトやシングルページアプリケーション（SPA）のデプロイに特に適しています。その特徴は以下の通りです：
|
||||
|
||||
- **機能が充実**：静的サイトホスティングに加え、フォーム処理、認証、エッジ関数などの高度な機能をサポート
|
||||
- **Git との深い統合**：GitHub、GitLab、Bitbucket をサポートし、コードのプッシュで自動デプロイ
|
||||
- **ブランチプレビュー**：各ブランチが自動的に独立したプレビューリンクを生成
|
||||
- **グローバル CDN**：ウェブサイトが自動的に世界中のノードに配布され、アクセス速度が速い
|
||||
- **フォーム処理**：バックエンドコードなしでウェブサイトのフォーム送信を処理
|
||||
- **認証機能**：ユーザー認証機能が組み込まれており、ログイン/登録を迅速に実装
|
||||
|
||||
> ⚠️ **注意**：Netlify の中国国内からのアクセス速度は CloudBase に劣る場合があります。主に海外向けのプロジェクトに使用することをお勧めします。
|
||||
|
||||
## Netlify を使用した Web アプリケーションのデプロイ
|
||||
|
||||
### ステップ 1：アカウントの登録
|
||||
|
||||
[Netlify 公式サイト](https://www.netlify.com/) にアクセスし、「Sign up」をクリックして登録します。GitHub、GitLab、Bitbucket、またはメールアドレスで登録できます。
|
||||
|
||||
### ステップ 2：プロジェクトのインポート
|
||||
|
||||
1. ログイン後、「Add new site」→「Import an existing project」をクリック
|
||||
2. コードホスティングプラットフォーム（例：GitHub）を選択
|
||||
3. Netlify にリポジトリへのアクセスを許可
|
||||
4. リストからデプロイしたいリポジトリを選択
|
||||
|
||||
### ステップ 3：ビルド設定の構成
|
||||
|
||||
Netlify は一般的なフロントエンドフレームワークを自動的に識別し、ビルド設定を行います：
|
||||
|
||||
| フレームワーク | ビルドコマンド | 公開ディレクトリ |
|
||||
|------|----------|----------|
|
||||
| React | `npm run build` | `build` |
|
||||
| Vue | `npm run build` | `dist` |
|
||||
| Angular | `ng build` | `dist/<project-name>` |
|
||||
| Next.js | `next build` | `out` |
|
||||
| 純粋な HTML | - | `.`（プロジェクトのルートディレクトリ） |
|
||||
|
||||
自動識別が正しくない場合は、手動で設定できます：
|
||||
- **Build command**：ビルドコマンド（例：`npm run build`）
|
||||
- **Publish directory**：ビルド出力ディレクトリ（例：`dist` や `build`）
|
||||
|
||||
### ステップ 4：デプロイ
|
||||
|
||||
「Deploy site」ボタンをクリックし、ビルドの完了を待ちます。ビルド成功後、`xxx.netlify.app` というドメイン名が付与され、誰でもこのアドレスを通じてあなたのウェブサイトにアクセスできます。
|
||||
|
||||
### ステップ 5：カスタムドメインの設定（オプション）
|
||||
|
||||
1. サイト設定に入り、「Domain management」をクリック
|
||||
2. 「Add custom domain」をクリック
|
||||
3. ドメイン名を入力し、指示に従って DNS レコードを設定
|
||||
4. Netlify が自動的に HTTPS 証明書を申請・設定
|
||||
|
||||
### 特色機能
|
||||
|
||||
#### 1. フォーム処理
|
||||
|
||||
Netlify は非常に便利な機能を提供しています：バックエンドコードなしでフォーム送信を処理できます。
|
||||
|
||||
HTML フォームに `netlify` 属性を追加するだけです：
|
||||
|
||||
```html
|
||||
<form name="contact" netlify>
|
||||
<p>
|
||||
<label>お名前: <input type="text" name="name" /></label>
|
||||
</p>
|
||||
<p>
|
||||
<label>メール: <input type="email" name="email" /></label>
|
||||
</p>
|
||||
<p>
|
||||
<label>メッセージ: <textarea name="message"></textarea></label>
|
||||
</p>
|
||||
<p>
|
||||
<button type="submit">送信</button>
|
||||
</p>
|
||||
</form>
|
||||
```
|
||||
|
||||
デプロイ後、フォーム送信されたデータは自動的に Netlify 管理画面に送信されます。「Forms」ページですべての送信記録を確認でき、メール通知の設定や、他のサービスへのデータ転送も可能です。
|
||||
|
||||
#### 2. Netlify Functions（エッジ関数）
|
||||
|
||||
Netlify はサーバーレス関数（Serverless Functions）のデプロイをサポートしており、完全なバックエンドサーバーを構築することなく、シンプルな API インターフェースを実装できます。JavaScript や TypeScript で関数を記述でき、デプロイ後、自動的にアクセス可能な URL が付与されます。
|
||||
|
||||
例えば、`hello.js` というファイルを作成します：
|
||||
|
||||
```javascript
|
||||
exports.handler = async (event, context) => {
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Hello from Netlify!" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
デプロイ後、`https://あなたのドメイン/.netlify/functions/hello` を通じてこの関数にアクセスできます。
|
||||
|
||||
#### 3. ローカル開発サポート
|
||||
|
||||
Netlify は CLI ツールを提供しており、ローカルでの開発とテストに便利です：
|
||||
|
||||
```bash
|
||||
# Netlify CLI のインストール
|
||||
npm install -g netlify-cli
|
||||
|
||||
# ログイン
|
||||
netlify login
|
||||
|
||||
# ローカル開発サーバーの起動
|
||||
netlify dev
|
||||
|
||||
# ローカルでの関数テスト
|
||||
netlify functions:serve
|
||||
```
|
||||
|
||||
CLI ツールを使用すると、ローカルで Netlify 環境をシミュレートでき、フォーム送信や関数呼び出しなどの機能も含まれ、デプロイ前のテストに便利です。
|
||||
|
||||
---
|
||||
|
||||
# 4. Zeabur
|
||||
|
||||
Zeabur は新興のデプロイプラットフォームで、複数のサービスをデプロイする必要がある複雑なプロジェクトに特に適しています。その利点は以下の通りです：
|
||||
|
||||
- **豊富なサービステンプレート**：Dify、n8n、データベースなど、多くのサービステンプレートが組み込まれている
|
||||
- **複数のデプロイ方法をサポート**：GitHub、テンプレート、Docker イメージ、ローカルプロジェクトなど
|
||||
- **柔軟なサービスの組み合わせ**：1つのプロジェクトで複数の相互に関連するサービスをデプロイ可能
|
||||
- **従量課金**：使った分だけ支払い、実験的なプロジェクトに適している
|
||||
|
||||
## Zeabur を使用した Dify のデプロイ
|
||||
|
||||
以前のレッスンで、Dify に簡単に触れました。ここでは、[Zeabur](https://zeabur.com) を通じて、自分自身の Dify サービスを非常に簡単に立ち上げることができます。まず[コンソールページ](https://dash.zeabur.com)を開き、ページ上の各エリアを見てみましょう。
|
||||
|
||||
|
||||
|
||||
このページでは、まず多くのブロックが見えます。これらはすでに起動しているサービスです。上部メニューには、Agent、Servers、Docs、Templates などのオプションがあり、それぞれ以下を表しています：
|
||||
|
||||
1. **Agent**：Zeabur 内蔵の AI アシスタント（Agent）を開くことができ、操作方法の質問や、現在のサーバーのステータスの確認ができます。
|
||||
2. **Servers**：ここで自分で購入したクラウドサーバーを追加したり、Zeabur 経由で直接サーバーを購入したりできます。
|
||||
3. **Docs**：Zeabur の完全なドキュメントを確認できます。
|
||||
4. **Templates**：ここにはすべての組み込みテンプレートイメージがリストされています。
|
||||
|
||||
> ここで言及する「イメージ（Image）」は、「コードと実行環境を含む圧縮パッケージ」と考えることができます。あるサービスが1台のサーバー上で正常に稼働した後、「この実行環境 + コード」をパッケージ化してイメージにすることができます。その後、新しいサーバーでは、この圧縮パッケージを展開して実行するだけで、環境とコードの再設定なしにサービスを直接稼働させることができます。
|
||||
|
||||
ページの右上隅には、自分の残高も表示されます。デフォルトでは、毎月約5ドルの無料枠があります。詳細な課金ルールについては、今はあまり気にする必要はありません。サーバーが稼働している限り、枠を消費することだけ覚えておけば十分です。
|
||||
|
||||
|
||||
|
||||
残高をクリックすると、毎日の消費明細を確認できます。
|
||||
|
||||
|
||||
|
||||
それでは、自分自身の Dify サービスを作成しましょう。まず、[コンソールホーム](https://dash.zeabur.com)で「New Project」をクリックします。
|
||||
|
||||
|
||||
|
||||
次に、各作成方法の説明です：
|
||||
|
||||
1. **GitHub**
|
||||
あなたの GitHub アカウントに接続できます。バインド後、GitHub リポジトリから直接プロジェクトを選択してデプロイできます（GitHub は現在、世界最大のコードホスティングプラットフォームです）。
|
||||
2. **Template（テンプレート）**
|
||||
テンプレートに基づいてサービスをデプロイできます。Zeabur には多くのプリセットプロジェクトテンプレート（例：Dify、n8n など）が組み込まれており、これらのテンプレートに基づいてアプリケーションを迅速に作成・デプロイできます。
|
||||
|
||||
3. **Databases（データベース）**
|
||||
データベースサービスのデプロイに使用します。例：MySQL、MongoDB などの一般的なデータベース。
|
||||
|
||||
4. **Functions（関数）**
|
||||
関数サービスをデプロイできます。JavaScript や Python のコードを記述し、関数として呼び出すことができます。
|
||||
|
||||
|
||||
|
||||
|
||||
5. **Local Project（ローカルプロジェクト）**
|
||||
ローカルのフォルダをアップロードすると、Zeabur が自動的に起動スクリプトを識別します。これは、すでにローカルで開発済みのプロジェクトを Zeabur に迅速にデプロイするのに適しています。
|
||||
|
||||
6. **Docker Image**
|
||||
すでにパッケージされた Docker イメージをデプロイします。プロジェクトがすでに Docker イメージとしてパッケージされている場合（例：Docker Hub や他のイメージリポジトリに保存されている場合）、ここで直接デプロイできます。
|
||||
|
||||
7. **Cursor**
|
||||
Cursor（例：Cursor IDE）をインストールしている場合、この入口から Cursor 内のプロジェクトを直接 Zeabur にデプロイできます。
|
||||
|
||||
自分自身の Dify サービスをデプロイしたい場合は、**Template** 方式を選択し、検索ボックスに「dify」と入力することをお勧めします。異なる作者がメンテナンスする多くのバージョンが表示されますので、その中から1つを選択してください（例：v1.6.0 バージョンなど）。
|
||||
|
||||
|
||||
|
||||
続いて、任意の名前を入力すると、Zeabur がその名前に基づいて一時的なカスタムドメインを生成します。その後、誰もがこの URL を通じてあなたのサービスにアクセスできるようになります。
|
||||
|
||||
|
||||
|
||||
作成完了後、複数のプログラム（サービス）が順番に起動するのが見えます。すべてのサービスが「起動済み」のステータスになるまで、しばらくお待ちください。（Dify サービスは複数のプログラムで構成されており、各プログラムが異なる機能を担当し、それらが相互に連携して動作します。）
|
||||
|
||||
通常、左側の Dify アプリケーションをクリックするだけで、デフォルトのアクセス入口アドレスが表示されます。ただし、この例では、前面に nginx というレイヤーが挟まっているため、nginx サービスをクリックして最終的なアクセスアドレスを取得する必要があります。nginx は、外部との統一的な「リクエストの送受信」を担当するメインプログラムと考えることができます。外部からのアクセスアドレスを内部の各サービスに分配します。左側の Nginx をクリックし、詳細ページで現在のサービスアドレスを確認し、そのアドレスをブラウザで開いて、サービスが完全に起動するのを待ちます。
|
||||
|
||||
|
||||
|
||||
しばらく待つと、Dify のログイン画面が表示されます。メールアドレスと登録パスワードを入力すれば、自分自身の Dify サービスを使い始めることができます。
|
||||
|
||||
|
||||
|
||||
興味があれば、ついでに n8n サービスも立ち上げてみてはいかがでしょうか。n8n も海外で非常に人気のある AI ワークフロープラットフォームです。
|
||||
|
||||
|
||||
|
||||
## Zeabur と Trae を使ったスネークゲームのデプロイ
|
||||
|
||||
本チュートリアルの次のパートでは、Zeabur のいくつかの応用的な使い方を体験します。まず Trae を使ってスネークゲームを生成し、それを Zeabur のサーバーにデプロイし、誰もがアクセスできる公開リンクを設定します。
|
||||
|
||||
ステップ1は、ローカルで Trae を使ってスネークゲームのプロジェクトを作成することです。
|
||||
|
||||
### HTML フレームワークでの実装
|
||||
|
||||
|
||||
|
||||
Trae にとって、HTML ベースのスネークウェブゲームを生成するのは非常に簡単です。ゲームの生成が完了したら、前述の Zeabur のローカルデプロイ方法に従って、すべてのファイルを含むフォルダをアップロードするだけです。
|
||||
|
||||
|
||||
|
||||
完了後、そのサービスの詳細画面に進みます：
|
||||
|
||||
|
||||
|
||||
左側の「Network」オプションをクリックし、ページ内の「Public Address」エリアを見つけます。「Generate Domain」をクリックすると、外部アクセス用のアドレスが生成されます。好きな名前を入力できます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
生成完了後、ブラウザでこのアドレスを開くだけで、自分自身のスネークゲームを実行できます。他の HTML タイプの Web アプリケーションも、まったく同じ方法でデプロイ可能です。
|
||||
|
||||
|
||||
|
||||
### React フレームワークでの実装
|
||||
|
||||
前のセクションでは、HTML ベースの Web アプリケーションのデプロイ方法を学びました。次に、現在より一般的に使用されているフロントエンドフレームワークである React アプリケーションのデプロイを試みます。純粋な HTML と比較して、React はより成熟したモダンなフロントエンド開発フレームワークと見なされています。コンポーネント化された方法でページ構造を編成し、複雑なページの開発を大幅に高速化でき、エンタープライズ級のプロジェクトで非常に主流の選択肢です。
|
||||
|
||||
|
||||
|
||||
#### React アーキテクチャへのリファクタリング
|
||||
|
||||
Trae では、Agent に「このコードを React アーキテクチャにリファクタリングしてください」と伝えるだけで、元の HTML ベースの構造をかなり簡単に React プロジェクトにリファクタリングできます。
|
||||
|
||||
|
||||
|
||||
ただし、シンプルな HTML ファイルと比較して、React アプリケーションはより複雑なビルドツールとプロジェクト構造に依存するため、デプロイのプロセスも少し面倒になります。典型的な問題はポート設定にあります：デフォルトでは、React アプリケーションは通常ポート3000をリッスンします（設定ファイルや起動ログでもこれを確認できます）。
|
||||
|
||||
しかし、Zeabur ではこのままデプロイすると失敗します。なぜなら、Zeabur はポート8080をリッスンするアプリケーションしかサポートしていないからです。つまり、React アプリケーションを Zeabur 上で正常に動作させるには、まずデフォルトのリッスニングポートを3000から8080に変更する必要があります。
|
||||
|
||||
この設定を正しく行うには、まず2つの概念を明確にする必要があります：「ポート（Port）」とは何か、そして「リッスニングポート（Listening Port）」とはどういう意味かです。
|
||||
|
||||
#### ポートとは何か？
|
||||
|
||||
> コンピュータネットワークにおいて、ポートは「論理的な通信の端点」として理解でき、同じデバイス上で動作する異なるネットワークサービスを区別するために使用されます。簡単に例えると、IP アドレスが「住所」（例：162.128.1.1）だとすれば、ポート番号はその建物内の異なる部屋の「部屋番号」のようなものです。各部屋が1つのサービスに対応しています（例：Web サーバー、メールサービス、あなたの React アプリケーションなど）。
|
||||
>
|
||||
> ポート番号は16ビット整数で表され、値の範囲は0から65535です。
|
||||
|
||||
これらの詳細を覚えたくない場合は、シンプルに「ポートはネットワークアクセスアドレスを構成する必須要素」と理解すれば十分です。
|
||||
|
||||
私たちが通常ウェブサイトや IP アドレスにアクセスする際、ポート番号を手動で追加することはめったにありません。なぜなら、Web のデフォルトポートは80または443（HTTPS）だからです。ほとんどのブラウザはこれらの標準ポートを自動的に使用します。特別なポート、例えば React のデフォルト3000や Zeabur が要求する8080については、アドレスの後に`:3000`や`:8080`を追加しなければ対応するコンテンツにアクセスできません。
|
||||
|
||||
#### 「リッスニングポート番号」とは何か？
|
||||
|
||||
> 「リッスニングポート番号」とは、あるプログラムがデバイス上で自発的に「開き、監視している」ポートのことです。アプリケーションがリッスニングポートを設定したということは、オペレーティングシステムに「私はこのポートでネットワークリクエストを待ち続けます。リクエストが来たら、私に転送してください」と伝えていることになります。
|
||||
|
||||
さらに分かりやすく例えると：あなたのパソコンが1棟のオフィスビルだとします。IP アドレスはこのビルの住所です。ビル内には多くの会社や部署があり、それぞれが異なる部屋を占有し、部屋番号がポート番号です。
|
||||
|
||||
React のデフォルト開発サーバーが起動すると、ある部屋のドアを「開け」、そのドアに「受付」を配置します。この部屋番号がリッスニングポート——3000です。
|
||||
|
||||
さらに、React プログラムはビルの「管理会社」（オペレーティングシステム）に「私は3000号室にいます。3000宛てのすべての郵便物（ネットワークリクエスト）を私に転送してください」と伝えます。
|
||||
|
||||
このように、あなたが React ウェブサイトにアクセスすると、リクエストはまずこのビルに到達し、管理会社はリクエストが3000号室宛てであることを確認すると、すぐに React の「受付」にリクエストを渡します。受付が処理して結果を返す——これが React アプリケーションにアクセスするプロセスです。
|
||||
|
||||
ローカルで`npm start`を実行すると（React 開発サーバーを起動するデフォルトコマンドで、Vibe Coding の Agent サイドバーでも実行可能）、React 開発サーバーは自動的にリッスニングポートを3000に設定します。
|
||||
一方、Zeabur のプラットフォーム設計により、ポート8080をリッスンするアプリケーションしか「認識」しません。React アプリケーションがデフォルトの3000ポートを使用したままだと、Zeabur はリクエストをアプリケーションに正しく転送できず、結果的にデプロイが失敗します。
|
||||
|
||||
#### デフォルトのリッスニングポートの変更
|
||||
|
||||
React のデフォルトリッスニングポート（3000）を Zeabur が要求する8080に変更するには、多くの方法があります。最も簡単な方法は、Trae で Agent に「この React プロジェクトのデフォルトポートを8080に変更してください」と指示することです。Trae がプロジェクト内の対応する設定ファイルを変更してくれます。変更完了後、再ビルドして前述の方法で Zeabur にアップロードするだけです。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ネットワーク設定でアクセス URL を指定する方法は、HTML プロジェクトのデプロイ時とほぼ同じで、React バージョンのサービスを起動できます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
他のポート番号の変更が必要なプログラムについても、同じアプローチを採用できます：まずデフォルトポートを変更し、Zeabur にアップロードしてデプロイします。以上で、一般的な Web アプリケーションをサーバーにデプロイする基本的なスキルを習得しました。
|
||||
|
||||
Trae に異なるタイプのアプリケーションを構築してもらい、それらを Zeabur のデフォルトサーバーにデプロイしてみてください。今後のレッスンでは、アプリケーションを自分で購入したクラウドサーバーにデプロイする方法も学びます。
|
||||
|
||||
---
|
||||
|
||||
# ⚠️ プロジェクトの停止と削除方法（Zeabur）
|
||||
|
||||
サーバー関連のリソースを有効にすると料金が発生するため、使用しないサービスはこまめに停止する習慣を身につけ、毎月の無料枠を使い切らないようにしましょう。
|
||||
|
||||
プロジェクトの管理画面を見つけるには、まずプロジェクト内の「Settings」オプションをクリックします。
|
||||
|
||||
|
||||
|
||||
設定ページに入ったら、ページを一番下までスクロールすると、次のような画面が表示されます：
|
||||
|
||||
|
||||
|
||||
「Suspend All Services」をクリックしてすべてのサービスを一時停止し、コストを削減できます。サービスに問題が生じた場合は、「Restart All Services」をクリックしてすべてのサービスを再起動できます。このプロジェクトがもう必要ないことが確実な場合は、「Delete Project」をクリックしてプロジェクト全体を完全に削除できます。
|
||||
|
||||
---
|
||||
|
||||
# まとめ
|
||||
|
||||
本チュートリアルでは、4つの一般的な Web アプリケーションデプロイプラットフォームを紹介しました：
|
||||
|
||||
1. **Tencent CloudBase**：中国国内のユーザーに適しており、アクセスが速く、WeChat エコシステムとの統合が良好
|
||||
2. **Vercel**：モダンフロントエンドフレームワークプロジェクトに適しており、GitHub との統合が緊密、グローバル CDN 加速
|
||||
3. **Netlify**：機能が充実、フォーム処理と認証をサポート、高度な機能を必要とする静的サイトに適している
|
||||
4. **Zeabur**：複雑なプロジェクトに適しており、サービステンプレートが豊富、複数のデプロイ方法をサポート
|
||||
|
||||
どのプラットフォームを選ぶかは、あなたの具体的な要件によって異なります：
|
||||
- 主に中国国内のユーザー向けの場合は、**CloudBase** をお勧めします
|
||||
- React/Next.js などのフレームワークを使用する場合は、**Vercel** または **Netlify** をお勧めします
|
||||
- フォーム処理や認証などの高度な機能を必要とする場合は、**Netlify** をお勧めします
|
||||
- Dify、n8n などのサービスをデプロイする必要がある場合は、**Zeabur** をお勧めします
|
||||
|
||||
どのプラットフォームを選んでも、デプロイのコアプロセスは同じです：コードの準備 → プラットフォームの選択 → ビルド設定 → デプロイして公開。これらのスキルを身につければ、自分が開発したアプリケーションを世界中の人に共有できるようになります！
|
||||
@@ -0,0 +1,361 @@
|
||||
# デザインプロトタイプからプロジェクトコードへ
|
||||
|
||||
::: tip 🎯 核心的な問い
|
||||
**デザインツールのプロトタイプをブラウザで動くフロントエンドコードに変換するには？**
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. プロトタイプからコードへの3つのパス
|
||||
|
||||
Figma、MasterGoなどのモダンなフロントエンドデザインツールでインターフェース設計を完了した後、一つの非常に実際的な問題が自然に浮かび上がります：これらの構造的に完全なデザイン稿を、どうやってブラウザで実際に動くフロントエンドコードに変換するのか？
|
||||
|
||||
一般的に、プロトタイプからコードへの落とし込みには、本質的に3つの典型的なパスがあります：
|
||||
|
||||
| パス | 方法 | 特徴 | 適用シーン |
|
||||
|------|------|------|----------|
|
||||
| **パス1** | 画像に基づき、マルチモーダル大規模モデルで直接コードを復元 | 柔軟、特定のツール不要 | 迅速なプロトタイピング検証、シンプルなページ |
|
||||
| **パス2** | プラットフォーム自身の機能やプラグインで使用可能なコードをエクスポート | 再現度が高い、編集可能 | Figma/MasterGoユーザー |
|
||||
| **パス3** | プラットフォームとMCP機能を組み合わせて使用可能なコードをエクスポート | 自動化度が高い、カスタマイズ可能 | 深い統合が必要なワークフロー |
|
||||
|
||||
本記事では、これら3つのパスの具体的な実装方法を詳しく紹介し、プロジェクトのニーズに応じて最も適切なワークフローを選択できるようにします。
|
||||
|
||||
::: tip 📚 前提知識
|
||||
本節を始める前に、[FigmaとMasterGo入門](../figma-mastergo/)チュートリアルを先に学び、フロントエンドデザインツールの基本操作をマスターすることをお勧めします。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 2. パス1：マルチモーダルAIによる直接コード復元
|
||||
|
||||
視覚能力を持つ大規模モデルは、生来画像をコードに変換する能力を備えています。デザイン稿のスクリーンショットを直接ダイアログにインポートし、大規模モデルに完全な結果コードを生成させるだけです。
|
||||
|
||||
### 2.1 操作フロー
|
||||
|
||||
1. **デザイン稿の画像をキャプチャ**
|
||||
- FigmaまたはMasterGoで、設計したページをPNGまたはJPGにエクスポート
|
||||
- スクリーンショットに完全なページレイアウトが含まれていることを確認
|
||||
|
||||
2. **マルチモーダルAIモデルを選択**
|
||||
- Gemini、Qwen、Claudeなどの画像入力をサポートするモデルを使用可能
|
||||
- ここではGeminiを例にデモを行います
|
||||
|
||||
3. **プロンプトを作成**
|
||||
```
|
||||
このデザイン画像に基づいて対応するHTML/CSSコードを生成してください。
|
||||
要件：
|
||||
- モダンなCSSレイアウト（Flexbox/Grid）を使用
|
||||
- レスポンシブデザイン、異なる画面サイズに対応
|
||||
- すべての可視UI要素を含める
|
||||
- 色、フォントサイズはできる限りデザイン稿に忠実に
|
||||
```
|
||||
|
||||
|
||||
|
||||
4. **コードを取得して保存**
|
||||
- モデルに完全なHTMLコードを返却させるよう要求
|
||||
- 単一の`.html`ファイルとして保存し、ローカルテストに便利
|
||||
- 後でローカルIDEでReactなどのフレームワークに変換可能
|
||||
|
||||
### 2.2 よくある問題と解決策
|
||||
|
||||
生成されたページはシンプルな作業ではなく、具体的な過程で多くの問題に直面する可能性があります：
|
||||
|
||||
| 問題 | 解決策 |
|
||||
|------|----------|
|
||||
| インターフェースの配置が不均一 | AIに具体的なレイアウトの問題を説明し、CSSのmargin/paddingの調整を要求 |
|
||||
| インターフェースの表示が不完全 | 正しいviewportが設定されているか確認し、レスポンシブブレイクポイントの追加を要求 |
|
||||
| 色の再現が不正確 | カラーピッカーツールでデザイン稿の正確な色値を取得し、AIに提供 |
|
||||
| フォントが一致しない | 具体的なフォント名を指定するか、Google Fontsの代替使用を要求 |
|
||||
|
||||
::: tip 💡 コツ
|
||||
まずHTMLコードを生成し、取得後にローカルIDEでReactフレームワークに変換することをお勧めします。これにより複数の独立したHTMLファイルが得られ、フレームワーク変換を一括して行えます。
|
||||
:::
|
||||
|
||||
### 2.3 MasterGo AIによるページ生成
|
||||
|
||||
MasterGoも強力なAIページ生成機能を提供しており、参考画像に基づいて直接使用可能なWebコードを生成できます。
|
||||
|
||||
#### AI機能の入り口を見つける
|
||||
|
||||
MasterGo編集画面の上部ツールバーに、AIツールボタンがあります：
|
||||
|
||||
|
||||
|
||||
#### 生成フロー
|
||||
|
||||
1. **参考画像をアップロード**
|
||||
- マルチモーダルAIと同じ方法でデザインの参考画像をアップロード
|
||||
- テキストで要件を説明
|
||||
|
||||
2. **生成結果を確認**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. **コードを取得**
|
||||
- 青いボタン「キャンバスに挿入」をクリックし、生成後のWebページを直接編集
|
||||
- または右側の「コード」ボタンをクリックし、コード内容をローカルにコピー
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. パス2：プラットフォーム自身の機能やプラグインでコードをエクスポート
|
||||
|
||||
### 3.1 Figma Makeによるコード生成
|
||||
|
||||
Figma MakeはFigma公式が提供するAIデザインツールで、ユーザーが入力したプロンプトまたは参考画像に基づいて、高精度にWebプロトタイプUIインターフェースを復元できます。
|
||||
|
||||
#### 機能の特徴
|
||||
|
||||
- **高精度な復元**：ネイティブAI生成コードに比べ、より良い効果
|
||||
- **編集可能性**：生成結果を編集可能なFigma Designファイルに変換可能
|
||||
- **GitHub統合**：コードを直接GitHubに同期する機能をサポート
|
||||
|
||||
::: tip 🔑 権限について
|
||||
Figma Makeの完全な機能を使用するにはProユーザー権限が必要です。学生は教育認証を通じて無料でPro権限を取得できます。
|
||||
:::
|
||||
|
||||
#### 操作手順
|
||||
|
||||
1. **Figma Makeに入る**
|
||||
- FigmaのホームページでMakeボタンをクリック
|
||||
- または[Figma Make](https://www.figma.com/make)にアクセス
|
||||
|
||||
2. **参考画像をアップロード**
|
||||
- 復元したいデザイン画像をダイアログにアップロード
|
||||
- 要件を説明するプロンプトを追加
|
||||
|
||||
|
||||
|
||||
3. **生成結果を確認**
|
||||
- しばらく待つとレンダリング結果が表示
|
||||
- 右上の再生ボタンをクリックしてフルスクリーンプレビュー
|
||||
|
||||
|
||||
|
||||
4. **ディテールの調整**
|
||||
- 右上の編集アイコン（マウスと定規のアイコン）をクリック
|
||||
- おなじみのFigma Editorインターフェースに戻り、詳細な調整を行う
|
||||
|
||||
|
||||
|
||||
5. **コードをエクスポート**
|
||||
- 調整に満足したら、コードのエクスポートを選択
|
||||
- GitHubに直接接続してコードを保存可能
|
||||
|
||||
|
||||
|
||||
### 3.2 プラグインによるコードエクスポート
|
||||
|
||||
プラットフォームのネイティブAI機能に加えて、FigmaとMasterGoはどちらもプラグインによるコードエクスポートをサポートしています：
|
||||
|
||||
**よく使われるFigmaプラグイン：**
|
||||
- **Figma to Code**：デザイン稿をReact、Vue、HTMLなどのコードに変換
|
||||
- **Anima**：高忠実度なコード生成、インタラクション効果をサポート
|
||||
- **Locofy**：AI駆動のデザインからコードへのツール
|
||||
|
||||
**使用手順：**
|
||||
1. Figmaでプラグインパネル（Plugins）を開く
|
||||
2. 必要なコードエクスポートプラグインを検索してインストール
|
||||
3. エクスポートするデザイン要素を選択
|
||||
4. プラグインを実行し、ターゲットフレームワークとコード形式を選択
|
||||
5. 生成されたコードをコピーまたはダウンロード
|
||||
|
||||
---
|
||||
|
||||
## 4. パス3：プラットフォームとMCP機能を組み合わせてコードをエクスポート
|
||||
|
||||
### 4.1 MCPとは？
|
||||
|
||||
MCP（Model Context Protocol、モデルコンテキストプロトコル）は、AIモデルが外部ツールやデータソースに安全かつ制御可能にアクセスできるようにするオープン標準プロトコルです。フロントエンドデザインツールのシーンでは、MCPは大規模モデルがデザインファイルの構造、スタイル、コンポーネント情報を直接読み取ることを可能にし、より正確なコード生成を実現します。
|
||||
|
||||
### 4.2 MCPの動作原理
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ AIモデル │ ←→ │ MCPサーバー │ ←→ │ デザインツール │
|
||||
│ (Claude等) │ │ (プロトコル適配) │ │(Figma/MasterGo)│
|
||||
└─────────────┘ └─────────────┘ └─────────────┘
|
||||
```
|
||||
|
||||
**ワークフロー：**
|
||||
1. AIモデルがMCPプロトコルを通じてデザインツールにリクエストを送信
|
||||
2. デザインツールが構造化されたデザインデータ（レイヤー、スタイル、コンポーネントなど）を返却
|
||||
3. AIモデルがデザイン構造を理解し対応するコードを生成
|
||||
4. コードを直接エクスポートまたは開発環境に同期
|
||||
|
||||
### 4.3 Figma + MCP実践
|
||||
|
||||
#### 環境の準備
|
||||
|
||||
1. **MCPサーバーのインストール**
|
||||
```bash
|
||||
# Figma MCPサーバーをnpxでインストール
|
||||
npx figma-mcp-server
|
||||
```
|
||||
|
||||
2. **Claude Desktopまたは他のMCP対応AIツールの設定**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"figma": {
|
||||
"command": "npx",
|
||||
"args": ["figma-mcp-server"],
|
||||
"env": {
|
||||
"FIGMA_ACCESS_TOKEN": "your-figma-token"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. **Figma Access Tokenの取得**
|
||||
- Figmaにログイン → Settings → Personal Access Tokens
|
||||
- 新しいTokenを生成して保存
|
||||
|
||||
#### 使用フロー
|
||||
|
||||
1. **AIツールでMCP接続を有効にする**
|
||||
- Claude Codeまたは他のMCP対応IDEを開く
|
||||
- MCPサーバーが接続されていることを確認
|
||||
|
||||
2. **デザインファイルのリンクを提供**
|
||||
```
|
||||
ユーザー：このFigmaデザインをReactコードに変換してください
|
||||
リンク：https://www.figma.com/file/xxxxx
|
||||
|
||||
AI：MCPを通じてFigmaに接続し、デザインファイルの構造を読み取っています...
|
||||
```
|
||||
|
||||
3. **AIが自動的に分析しコードを生成**
|
||||
- MCPサーバーがデザインファイルのレイヤーツリーを取得
|
||||
- AIがコンポーネント構造とスタイル属性を理解
|
||||
- 正しい命名と構造を持つReact/Vueコンポーネントを生成
|
||||
|
||||
4. **イテレーションと最適化**
|
||||
```
|
||||
ユーザー：ボタンコンポーネントを独立した再利用可能なコンポーネントとして抽出してください
|
||||
|
||||
AI：MCPを通じてデザインシステムのButtonコンポーネントを特定しました。
|
||||
propsインターフェースを持つReactコンポーネントを生成しています...
|
||||
```
|
||||
|
||||
### 4.4 MCPの利点
|
||||
|
||||
| 特徴 | 従来の方法 | MCP方式 |
|
||||
|------|----------|----------|
|
||||
| **データ精度** | スクリーンショットに依存、ディテールが失われる可能性 | オリジナルのデザインデータを直接読み取り |
|
||||
| **コンポーネント認識** | AIがコンポーネントの境界を推測する必要がある | コンポーネント定義を正確に取得 |
|
||||
| **スタイルの復元** | ピクセルベースの推定 | 正確なデザイントークンを取得 |
|
||||
| **イテレーション効率** | 毎回の変更でスクリーンショットを再取得 | デザイン変更をリアルタイムで同期 |
|
||||
| **自動化度** | 手動でコピー＆ペースト | プロジェクトファイルに直接書き込み可能 |
|
||||
|
||||
### 4.5 現在利用可能なMCPツール
|
||||
|
||||
**デザインツールMCP：**
|
||||
- **Figma MCP Server**：公式サポートのMCP実装
|
||||
- **MasterGo MCP**：コミュニティ開発のMasterGoアダプタ
|
||||
|
||||
**開発環境MCP：**
|
||||
- **Claude Code**：MCPプロトコルをネイティブサポート
|
||||
- **Cline**：VS Codeプラグイン、MCP接続をサポート
|
||||
- **Trae**：設定でMCP機能を有効化可能
|
||||
|
||||
::: tip 🔮 将来の展望
|
||||
MCPプロトコルは急速に発展しており、将来的にはデザインツールと開発環境の統合がさらに緊密になるでしょう。デザインからコードへのワンクリック同期ソリューションがさらに登場し、デザインと開発の距離をさらに縮めると予想されます。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. コードエクスポート後の作業
|
||||
|
||||
### 5.1 ローカルテスト
|
||||
|
||||
コードを取得したら、ローカルIDEで開いてテストします：
|
||||
|
||||
1. **新規プロジェクトの作成**
|
||||
```bash
|
||||
# HTMLファイルの場合、ブラウザで直接開く
|
||||
open index.html
|
||||
|
||||
# React/Vueプロジェクトの場合
|
||||
npm install
|
||||
npm run dev
|
||||
```
|
||||
|
||||
2. **AI IDEとの協業**
|
||||
- 生成されたコードをTraeや他のAI IDEにインポート
|
||||
- AIにレイアウト問題の修正やインタラクション機能の追加を支援させる
|
||||
|
||||
### 5.2 よくある問題の処理
|
||||
|
||||
| 段階 | 問題 | 解決策 |
|
||||
|------|------|----------|
|
||||
| レイアウト | 要素のずれ | CSSのdisplayとposition属性を確認 |
|
||||
| スタイル | 色が一致しない | ブラウザの開発者ツールで実際に適用されている色値を確認 |
|
||||
| レスポンシブ | モバイルでの表示が異常 | media queryのブレイクポイントを追加 |
|
||||
| インタラクション | ボタンが反応しない | JavaScriptのイベントバインディングを確認 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 3つのパスの比較と選択の提案
|
||||
|
||||
### 6.1 パスの比較
|
||||
|
||||
| 次元 | パス1：マルチモーダルAI | パス2：プラットフォーム機能 | パス3：MCP |
|
||||
|------|------------------|------------------|-------------|
|
||||
| **難易度** | ⭐ 簡単 | ⭐⭐ 中程度 | ⭐⭐⭐ やや複雑 |
|
||||
| **再現精度** | ⭐⭐⭐ 中程度 | ⭐⭐⭐⭐ 高い | ⭐⭐⭐⭐⭐ 最高 |
|
||||
| **柔軟性** | ⭐⭐⭐⭐⭐ 高い | ⭐⭐⭐ 中程度 | ⭐⭐⭐⭐ やや高い |
|
||||
| **自動化度** | ⭐⭐ 低い | ⭐⭐⭐ 中程度 | ⭐⭐⭐⭐⭐ 高い |
|
||||
| **コスト** | 低い（API呼び出しに基づく） | 中程度（Proが必要な場合も） | 低い（オープンソースツール） |
|
||||
|
||||
### 6.2 選択の提案
|
||||
|
||||
**パス1（マルチモーダルAI）を選ぶ場合：**
|
||||
- アイデアを素早く検証する必要がある
|
||||
- デザインツールが固定されておらず、頻繁に切り替える
|
||||
- 再現精度の要求が高くない
|
||||
- 予算が限られている
|
||||
|
||||
**パス2（プラットフォーム機能）を選ぶ場合：**
|
||||
- チームが主にFigmaまたはMasterGoを使用
|
||||
- 高精度なコード復元が必要
|
||||
- デザイナーと開発者が頻繁に協業する必要がある
|
||||
- Pro版に投資する意思がある
|
||||
|
||||
**パス3（MCP）を選ぶ場合：**
|
||||
- 最高レベルの自動化を追求
|
||||
- MCP環境を構築する技術力がある
|
||||
- プロジェクトでデザインからコードへの頻繁なイテレーションが必要
|
||||
- 標準化されたデザイン→開発ワークフローを構築したい
|
||||
|
||||
---
|
||||
|
||||
## 7. まとめ
|
||||
|
||||
本章の学習を通じて、デザインプロトタイプからコードへの3つのコアパスをマスターしました：
|
||||
|
||||
1. **マルチモーダルAIによる直接変換**：柔軟で高速、プロトタイピング検証に適する
|
||||
2. **プラットフォームのネイティブ機能**：再現度が高く、プロのデザインワークフローに適する
|
||||
3. **MCPプロトコル統合**：自動化度が最も高く、未来のトレンドを代表
|
||||
|
||||
::: tip 💡 ベストプラクティス
|
||||
- **初心者におすすめ**：パス1（マルチモーダルAI）から始め、素早くキャッチアップ
|
||||
- **チーム協業**：パス2（プラットフォーム機能）を使用し、デザインの一貫性を保証
|
||||
- **効率優先**：パス3（MCP）を試み、自動化ワークフローを構築
|
||||
- **混合使用**：プロジェクトの段階に応じて柔軟に異なるパスを切り替え
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 参考リソース
|
||||
|
||||
- [FigmaとMasterGo入門](../figma-mastergo/) - デザインツールの基礎を学ぶ
|
||||
- [ホグワーツ肖像画を作ろう](../hogwarts-portraits/) - 完全なプロジェクトの実践
|
||||
- [MCP公式ドキュメント](https://modelcontextprotocol.io/) - プロトコルの詳細を理解
|
||||
- [Figma Make公式ドキュメント](https://help.figma.com/hc/en-us/sections/360007453634-Figma-Make)
|
||||
- [MasterGo AIチュートリアル](https://mastergo.com/tutorials)
|
||||
@@ -0,0 +1,303 @@
|
||||
# FigmaとMasterGo入門
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['ja-jp/stage-2/frontend/figma-mastergo'] ?? []
|
||||
</script>
|
||||
|
||||
::: tip 🎯 核心的な問い
|
||||
**ゼロからモダンなデザインツールを使ってWebプロトタイプを作成するには？**
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. なぜフロントエンドデザインツールを学ぶのか？
|
||||
|
||||
始める前に、一つの疑問を理解する必要があります：なぜ「フロントエンドデザインツール」を学ぶ必要があるのでしょうか？HTML / CSSコードを直接書いてもページを作れるのに、ソフトウェアと技術をもう一つ学ぶことは本当に必要でしょうか？
|
||||
|
||||
実際、ページを動かすことと、プロダクトを良く設計することは全く別の概念です。コードはブラウザでどうレンダリングするか、異なるデバイスでどう動くかという問題にしか関心がありません。フロントエンドデザインツールが解決するのは、情報配置の問題です。フロントエンドのインタラクションをどう配置するか、異なるページ間の遷移をどうするか、視覚的優先順位をどう配分するかといった問題です。デザインツールでキャンバスを作るだけで、版面、情報階層、インタラクション方法を1つの画面で比較検討し、最も適切な表現効果を選ぶことができます。
|
||||
|
||||
直接コードを書いたり、AIで完全なフロントエンドページを生成したりすると、通常ユーザー体験はあまり良くありません。厳密なプロダクトはユーザーとフロントエンドのインタラクションの快適さや、異なるページで伝えたいコンテンツの分布を考慮し、ユーザーの視点からまずフロントエンドページの配置を行い、その後コード変換や生成を行います。
|
||||
|
||||
また、チーム協業の観点から見ると、フロントエンドデザインツールは関係者の協力コストを下げます：デザイナー、プロダクトマネージャー、開発者がそれぞれの想像や抽象的なコード説明に頼るのではなく、リアルタイム協業をサポートし、可視化され、注釈可能で、反復可能なキャンバスを中心に、バージョン管理、要件変更、フィードバックについて議論できます。さらに、モダンなフロントエンドデザインツール自体がもはや単なる描画ソフトではなく、ワンクリックでコードの一部を生成し、デザインシステムとコンポーネントライブラリを管理できます。新时代のデザインツールは、多くの反復的な手作業（整列、注釈、エクスポート、スタイル変更）を自動化・バッチ化し、ページ設計の開発効率を大幅に促進しています。
|
||||
|
||||
|
||||
|
||||
### 1.1 フロントエンドデザインツールの変遷
|
||||
|
||||
歴史を振り返ると、いわゆるフロントエンドデザインツールは継続的に進化してきた技術です。90年代のローカルビットマップ編集中心のPhotoshop時代から、2010年前後のSketchによるベクター化・コンポーネント化ワークフロー、そして2016年以降のFigmaによるクラウド上での協業の完全実現まで、デザインチームは単独作業からリアルタイムマルチユーザー協業へと移行しました。2025年に至り、AIは既にこれらのツール内部に実用的に組み込まれています：「一言の指示からページドラフトを生成」から「デザイン稿を直接実行可能なフロントエンド構造に変換」まで、「デザイン即コード」「人機共创」が概念から利用可能な生産力へと変わりつつあります。
|
||||
|
||||
本節では、最も代表的な2つのモダンなフロントエンドデザインツールを紹介します：FigmaとMasterGoです。一方で、これらはモダンなUI/UXに必要な核心機能（ベクター編集、コンポーネントシステム、自動レイアウト、コード受け渡しなど）を網羅しており、ワイヤーフレームからハイファイデリ、開発引き渡しまでの完全なループをサポートします。他方で、これらのツールはどちらも2025年以降、実用的なAI機能を追加しており、プロトタイプを維持しながらデザイン画像を本当に実行可能なプログラムに変換するのを支援します。
|
||||
|
||||
## 1.2 誕生の旅
|
||||
|
||||
|
||||
|
||||
モダンなフロントエンド専用ツールが誕生する前の時代、インターフェースデザイン業界の視覚デザイン作業は長い間、Photoshopのような「万能型」デザインソフトが兼任していました。デザイナーはローカルでレイヤーを重ねて、ページ全体の視覚効果を細かく設計し、最終的にサイズの大きい.psdソースファイルをフロントエンドエンジニアに納品していました。フロントエンドがデザイン画像を正確に再現するには、3つの煩雑で重要な作業を手動で完了する必要がありました：
|
||||
|
||||
1つ目は「スライス」：.psdファイルの多層構造から、ボタン、アイコン、ロゴ、背景モジュールなどの独立した視覚要素を一つずつ分割・抽出し、PNG、JPGなどのWebブラウザが直接読み込める画像形式にエクスポートする必要がありました（WebブラウザはPSDのレイヤー情報を直接認識できず、分割された画像に依存してディテールを表示するため）。
|
||||
|
||||
|
||||
|
||||
2つ目は「寸法測定」：ソフトウェアの測定ツールを使って、各要素の幅・高さ、異なるモジュール間のマージン（margin/padding）などのデータを一つずつ確認し、すべての寸法がピクセル単位で正確であることを保証する必要がありました。
|
||||
|
||||
|
||||
|
||||
3つ目は「注釈の抽出」：デザイン画像から「見えないが必須の」暗黙パラメータを抽出する必要がありました。例えば、テキストのフォントサイズ、ウェイト、行間、各カラーブロックのRGBやHEXカラー値など、デザイナーが紙に書いていない「設計仕様」を手動で「抽出」して記録する作業でした。
|
||||
|
||||
|
||||
|
||||
その後、フロントエンドの実装段階が本格的に始まりました。ネイティブのHTML/CSS/JSであれ、Vue、Reactなどのフレームワークであれ、本質的なプロセスは同じです。フロントエンドは「コンテナを核心的なキャリア」として、设计中の各モジュールの階層とセマンティクスに従ってページ構造を再構築します。ここでのコンテナとは、明確なレイアウト境界を持ち、子要素を専門に保持・整理する単位を指し、具体的なコンテンツを直接表示するのではなく、Flex、Gridなどのルールを通じて内部要素の配置範囲を定めます。そして「構造ブロック」（トップナビゲーションバー、サイドバー、記事リストエリア、フッターなど目で見える機能/コンテンツエリア）は、コンテナに依存して存在します。各構造ブロック内部には、さらに小さなコンテナがネストされて要素を整理します。例えば、1つの記事リスト項目は「リスト項目コンテナ」が内側の余白と全体レイアウトを制御し、さらにタイトル、要約、時間、カバー画像などの詳細要素を包み込みます。
|
||||
|
||||
|
||||
|
||||
モダンなフロントエンドフレームワークでは、これらの「構造ブロック（および関連するコンテナと要素）」は通常「コンポーネント」として実装されます。コンポーネントは簡単に言えば、明確な境界を持ち、コンテナレイアウトとロジックを統合した再利用可能なインターフェース単位です。外観と配置を制御するコンテナ（例えば「ボタンコンポーネント」はコンテナで幅・高さ、角丸を定義し、「記事カードコンポーネント」はコンテナでタイトル、カバーの位置を整理）を含むだけでなく、インタラクションロジックもカプセル化します。デザイン稿に繰り返し登場し、形が統一されている部分（統一スタイルのボタン、繰り返し使用される記事カードなど）は、コード内でコンポーネントに抽象化されます：異なるページ/シーンで再利用でき、重複開発を減らすだけでなく、コンポーネント内コンテナの統一ルールにより、すべての再利用箇所のレイアウトとスタイルの高い一貫性を保証します。
|
||||
|
||||
その後、フロントエンドはスタイルシステムを使って視覚とレイアウトを再現します。スライス段階でエクスポートされたPNG/JPGなどのリソースは、コンポーネントや構造ブロック内部の`<img>`、背景画像として、または各フレームワーク推奨の静的アセット方式でインポートされます。寸法測定段階で得られた幅・高さ、間隔、行の高さなどの具体的な数値は、`width`、`height`、`margin`、`padding`、`line-height`などのスタイルプロパティに変換され、対応するコンポーネントや構造ブロックに適用されます。注釈抽出段階で整理された色、フォント、シャドウ、角丸、hover/activeなどの状態は、CSS、CSS Modules、CSS-in-JS、Tailwindなどの具体的なスキームにおける`color`、`font-family`、`font-size`、`box-shadow`、`border-radius`および擬似クラスや状態クラス名に落とし込まれます。この時点で、スライス、寸法、注釈が提供するのは一連の正確な視覚パラメータであり、コンポーネントと構造ブロックが提供するのはこれらのパラメータを保持するコード組織単位であり、両者が組み合わさって、保守可能で再利用可能なインターフェース実装を構成します。
|
||||
|
||||
|
||||
|
||||
しかし、ローカルファイル中心のモデルは本質的に非効率です。バージョンはメールやクラウドストレージで転送され、新旧の原稿が混同しやすく、デザインと開発の間では上記のような複雑なやり取りに大きく依存し、協業コストとエラー確率は決して低くありません。
|
||||
|
||||
モバイルインターネットの台頭後、インターフェースの複雑さとイテレーション速度のニーズが急速に高まり、Photoshopの「大きくて万能」な特性が次第に重く感じられるようになりました。この段階でSketchが登場しました。SketchはUIデザインそのものに特化し、視覚的な後処理に関連する負担の大部分を削除しました。Symbolsを使ってボタン、ナビゲーション、入力ボックスなどの再利用性の高い要素をコンポーネント化し、一箇所の変更でグローバルに同期できるようにしました。さらにZeplinのようなツールと組み合わせて、注釈とスタイル断片を自動生成しました。Sketchは「コンポーネント思考」をデザインワークフローに導入しました。しかし、やはりローカルファイルベースのデスクトップアプリケーションであり、リアルタイム協業にはクラウドストレージ、サードパーティプラグイン、バージョンツールを経由する必要があり、「複数人が同時に同じ原稿を修正する」という問題を根本的に解決していませんでした。
|
||||
|
||||
|
||||
|
||||
本当にゲームチェンジャーとなったのはFigmaです。2016年以降、UIデザイン、プロトタイピング、コメント協業をブラウザに統合し、リアルタイムマルチユーザーカーソル、オンラインコメント、バージョンタイムライン、共有リンクなどのモダンな機能をサポートしました。今日では当たり前に見えますが、当時はPhotoshop / Sketchモデルへの真っ向からの挑戦でした。
|
||||
|
||||
|
||||
|
||||
ここに至り、インターフェースデザインはもはや各個人のPCに散らばるファイルではなく、1つのオンラインでリアルタイム更新されるクラウドキャンバスに集中するようになりました。このキャンバスを中心に、さらに自動化やAIの方法でデザインとフロントエンドコードの境界を曖昧にすることを想像できます。
|
||||
|
||||
当初は各種プラットフォームプラグインに頼り、デザイン稿中のコンポーネント、スタイル情報を半自動的にコード断片（React/Vueコンポーネントスケルトン、CSS変数など）としてエクスポートすることしかできませんでした。その核心的本質はプラグインによる構造化情報抽出です。その後、プラットフォーム能力の進化に伴い、大部分のデザインプラットフォームが大規模モデルのMCP（Model Context Protocol、モデルコンテキストプロトコル）機能をサポートし始めました：このプロトコルは標準的な仕組みを提供し、大規模モデルがデザインファイル、プラグインインターフェース、プロジェクトメタデータに安全かつ制御可能にアクセスできるようにし、デザイン稿のコードへのエクスポートをより便利にします。
|
||||
|
||||
さらに、プラグインとMCPの基盤の上で、フロントエンドコードの自動化はデザイン稿から直接コード構造を導出する段階へと進みました。デザインツール内でワンクリックでフロントエンドプロジェクトスケルトン、コンポーネント階層、スタイル体系、対応するコード結果を生成できるようになりました。これにより、デザイナーとフロントエンド開発エンジニアは手動でデザインディテールを移す作業から解放され、ユーザー体験の最適化と機能バージョンの更新イテレーションに多くのエネルギーを注げるようになりました。
|
||||
|
||||
---
|
||||
|
||||
## 2. Figma入門
|
||||
|
||||
ここから抽象的な概念部分から実際の操作段階に移ります。時間の都合上、Figmaの基本的な操作ロジックのみを学びます。デザインツールを全く使ったことがなくても、練習についていけるようにします。Figmaの完全な機能を学習したい場合は、Figmaが提供する詳細な公式チュートリアルを参照してください：https://help.figma.com/hc/en-us/sections/30880632542743-Figma-Design-for-beginners
|
||||
|
||||
または以下のチュートリアルを参考に、個人ポートフォリオのようなシンプルなWebページを素早く構築することもできます：https://help.figma.com/hc/en-us/sections/35895585621655-Figma-Sites-collectio
|
||||
|
||||
|
||||
|
||||
左側はプロジェクトの新規作成とリソース管理の入り口で、右上のいくつかのボタンはFigmaの主要な機能です。その中で、MakeはAIに一言で大まかなインターフェースや構造ドラフトを生成させるもので、DesignはWeb/Appインターフェースの設計、コンポーネントの構築、プロトタイプ作成のメインワークスペースです。FigJamはチーム用ホワイトボードで、付箋を貼ったり、フローを描いたり、初期段階の議論に使います。Buzzはブランドアセットのスケール生産ツールで、ブランド一貫性を保ちながらコンテンツをバッチ生成するために使用します。Siteはデザインを実際にアクセス可能なWebページやドキュメントサイトにまとめて公開するためのものです。
|
||||
|
||||
一見するとFigmaの機能が多く、入りにくく感じられますが、実はこの種の機能ツールは本質的に慣れの問題であり、最初に操作ミスを恐れる必要はありません。一度に完璧にしようとせず、まず触ってみて、使っているうちに自然と素早く上達できます。
|
||||
|
||||
本チュートリアルでは、素早く入門するため、Design機能について簡単に説明します。
|
||||
|
||||
### 2.1 Designファイルを新規作成
|
||||
|
||||
ホームページまたは右上の入り口から**Design**を選択し、新規ファイルを作成すると、空白のデザインキャンバスに入ります。
|
||||
このインターフェースは大まかに3つの部分に分かれています：左側はページとレイヤーで、ページや要素の親子関係を確認・修正するのに使います。中央はキャンバスで、現在の効果を確認するためのものです。右側はプロパティとスタイルで、具体的な形状、色、スタイルを修正するのに使います。下部のツールバーはツールの切り替えに使用し、選択、図形描画、テキスト入力、コメント、プラグインなどが含まれます。ツールを選択した後、Escキーでデフォルトのマウスツールに戻れます。
|
||||
|
||||
|
||||
|
||||
### 2.2 最初のFrame（アートボード）を作成
|
||||
|
||||
正式に要素を配置する前に、まずページの明確な境界を決める必要があります。この境界はFrameが担います。下部のツールバーでFrameツールを選択するか、キーボードのFを直接押して、キャンバス上に矩形領域をドラッグします。
|
||||
|
||||
1. 下部ツールバーのFrameツールを使用するか、キーボードの`F`を直接押す。
|
||||
2. キャンバスに矩形領域をドラッグし、右側のプロパティバーで幅を例えば`1440`、高さを`900`に変更する。
|
||||
3. 左側のレイヤーバーで、このFrameの名前を変更する。例えば`My First Page`やプロジェクト名。
|
||||
|
||||
このFrameが1画面のインターフェースのページコンテナとなり、以降のタイトル、テキスト、ボタン、画像などの内容はすべてこのFrame内部に配置し、キャンバスの任意の場所に散らばらせないようにします。Frameを境界として内容を整理することで、スクロール設定、異なるデバイスサイズへの適応、画面エクスポート、プロトタイプ作成時に構造を管理しやすくなります。
|
||||
|
||||
|
||||
|
||||
### 2.3 Frame内にテキストとシンプルな要素を配置
|
||||
|
||||
コンテナができたら、次に最も基本的なコンポーネントの配置方法を学びます。例えば：タイトル、サブタイトル、ボタン、プレースホルダー画像ブロック。
|
||||
|
||||
1. テキストツール（下部ツールバーの`T`）を選択し、Frame内をクリックしてページタイトルを入力。例：`My Portfolio`。
|
||||
右側のプロパティで、フォントサイズを少し大きく（例：96）、フォントウェイトを少し太くする。
|
||||
2. タイトルの下に、テキストツールで簡単な説明文を入力。例えばこのページが何をするのかの1〜2行の説明。
|
||||
フォントサイズは少し小さく、行の高さは少し広めにして、詰まって見えないようにする。
|
||||
3. ボタンの雛形を作る：
|
||||
矩形ツールでタイトルの下におよそ`200 × 48`の矩形を描き、右側で目立つ塗り色を設定し、適度に角丸を加える。
|
||||
|
||||
4. テキストツールで矩形の上にボタンテキストを入力。例：`Get Started`。矩形とテキストを一緒に選択し、上部の配置ツールでテキストを水平・垂直ともに中央揃えにする。
|
||||
5. ボタンの横または下に、大きな薄いグレーの矩形を「画像プレースホルダー」として描く。後で展示画像を配置するのに使用。
|
||||
|
||||
ここまでで、非常にシンプルだが構造が完全な「ホームページドラフト」ができました：タイトル、説明文、ボタン、メイン表示エリア。
|
||||
|
||||
|
||||
|
||||
### 2.4 Auto Layoutを活用して要素を整理
|
||||
|
||||
すべての要素をただドラッグして配置しただけでは、ページはすぐに乱雑になります。Figmaで非常に重要な概念が**Auto Layout**です。これは一連の要素をルール付きのコンテナに変えることができます。
|
||||
|
||||
|
||||
|
||||
「メインタイトル + サブタイトル + ボタン」の3つを選択し、右側のプロパティバーで**Add Auto layout**をクリックします。
|
||||
|
||||
すると、これら3つが1つのコンテナに包まれ、右側でパラメータを調整でき、内部の要素レイアウトがパラメータに応じて自動的に適応・調整されます：
|
||||
|
||||
- 縦に並べるか横に並べるか
|
||||
- 要素間の間隔はどれくらいか
|
||||
- このブロック全体からコンテナの端までの内側余白（padding）はどれくらいか
|
||||
|
||||
|
||||
|
||||
同様に、ボタン内部もAuto Layoutを使えます。以下のような効果を実現できます：テキストを調整すると、ボタンの長さも自動的に調整される。
|
||||
|
||||
まずボタン背景の矩形とボタンテキストを選択し、Auto Layoutを追加して、これら2つを「ボタンコンテナ」にします。次にこのボタンコンテナを選択し、幅と高さを両方とも**Hug contents**に設定します。これにより、テキストは常にボタンの中央に保たれ、テキストが増減すると、ボタンの幅が自動的に追従して変化します。
|
||||
|
||||
|
||||
|
||||
### 2.5 ボタンを再利用可能コンポーネントに変換
|
||||
|
||||
ここで新しい概念、コンポーネントを学びます。コンポーネントとは繰り返し利用できる要素のことで、ボタンのような要素は、後で繰り返し使うことが予想される場合、コンポーネント化を検討できます。先ほどAuto Layoutを追加したボタンをベースに操作します：
|
||||
|
||||
1. ボタンコンテナ全体を選択。
|
||||
2. 右クリックでCreate component（コンポーネントを作成）を選択。
|
||||
|
||||
|
||||
これで、このボタンは通常のレイヤーグループから、コンポーネントのマスターになりました。以降、他のページやFrameで同じスタイルのボタンが必要な場合、左側のAssetsパネルから直接ドラッグして使用できます。
|
||||
|
||||
|
||||
|
||||
この時点で、使用されているすべてのボタンは、このマスターの同期コピーです。マスターの色、角丸、間隔を修正すると、すべてのインスタンスが自動的に同期更新されます。
|
||||
|
||||
|
||||
|
||||
以上で、Figmaの基本的な使い方の入門が完了しました。最初にすべての機能を理解する必要はありません。まずこのシンプルなページを作ってみて、これらのコア操作に慣れ、公式チュートリアルのより多くの機能を徐々に探索していけば、使用回数が増えるにつれて必ず上達できます。
|
||||
|
||||
---
|
||||
|
||||
## 3. MasterGo入門
|
||||
|
||||
Figmaの基本的なワークフローを理解した後、MasterGoを見てみましょう。MasterGoは中国版のFigmaと考えることができますが、一部の機能に違いがあります。全体的に、Figmaと同様のインターフェースレイアウトと操作理念を引き継いでいます：キャンバス、レイヤーツリー、プロパティパネルがあり、コンポーネント、スタイル、自動レイアウト、マルチユーザー協業を同様にサポートしています。より詳細な内容はMasterGOの公式チュートリアルを参照してください：https://mastergo.com/tutorials/12?%E5%85%A8%E7%A8%8B%E9%AB%98%E8%83%BD%EF%BC%8CMasterGo%20%E6%9C%80%E5%AE%8C%E6%95%B4%E5%AE%9E%E7%94%A8%E6%95%99%E7%A8%8B%EF%BC%8C%E8%AE%A9%E4%BD%A0%E4%BB%8E%E9%9B%B6%E5%88%B0%E7%B2%BE%E9%80%9A%EF%BC%81
|
||||
|
||||
### 3.1 デザインファイルを新規作成
|
||||
|
||||
1. **MasterGo管理画面に入る**
|
||||
1. MasterGo公式サイトを開きアカウントにログイン。
|
||||
2. ログイン後、「ファイルリスト / プロジェクトリスト」のようなホームページエリアが表示され、デザインファイルの管理に使用します。
|
||||
|
||||
|
||||
2. **新規ファイルを作成**
|
||||
1. 右上の+デザインファイルのボタンをクリックするか、Figmaなどのファイルのインポートを選択。
|
||||
2. クリック後、空白のキャンバスに入ります。これがMasterGoのデザインワークスペースです。
|
||||
|
||||
3. **基本インターフェースの各エリアについて**
|
||||
Figmaの使い方を学んだ後、MasterGoの使い方もほぼ同じで、主にいくつかのエリアに分かれています：
|
||||
|
||||
|
||||
1. トップツールバー：キャンバスの最上部に位置し、左側にファイルの場所とファイル名、中央に一連のよく使うツールボタン（選択、エリア/アートボード、図形、テキスト、注釈、コメント、プラグイン選択、AIツールなど）、右側に現在オンラインのメンバー、共有の入り口、キャンバスのズームとプレビュー制御機能の入り口。
|
||||
2. 左側パネル：主にレイヤーとリソースに分かれており、レイヤータブではページリストとそのページ下のすべてのレイヤーの構造と階層を確認できます。
|
||||
3. 中央キャンバスエリア：具体的な描画とレイアウトのワークスペースで、すべてのFrame、コンポーネント、図形がここに表示されます。
|
||||
4. 右側プロパティパネル：選択したオブジェクトのプロパティを確認・編集するために使用します。例えばサイズ、位置、配置、背景塗り、ボーダー、角丸など。何も選択されていない場合は、キャンバス関連の設定（背景色、ラベル、エクスポートオプションなど）が表示されます。
|
||||
|
||||
### 3.2 最初のFrameを作成
|
||||
|
||||
正式に内容を配置する前に、インターフェースの境界とサイズを決めるページコンテナが必要です。このコンテナはMasterGoでは通常Frameと呼ばれます。
|
||||
|
||||
**手順：**
|
||||
|
||||
1. **Frameツールを選択**
|
||||
1. ツールバーでFrame / アートボードツールを見つけてクリックすると、プリセットパラメータでアートボードに直接内容を作成できます。
|
||||
2. またはショートカットキー（通常は`F`、差異がある場合は実際のインターフェースを参照）を使用。
|
||||
2. **キャンバスに矩形領域をドラッグ**
|
||||
1. ドラッグ後、選択枠付きの領域が表示されます。
|
||||
2. 右側のプロパティパネルで、このFrameの幅と高さが確認できます。
|
||||
3. 幅を例えば`1440`、高さを`900`に変更（1画面のWebページでよく使われるサイズの1つ）。
|
||||
3. **Frameの名前を変更**
|
||||
1. 左側のレイヤーパネルでこのFrameを見つける。
|
||||
2. 名前をダブルクリックして、プロジェクト名に変更。例：`My First Page`、またはお好みのページ名。
|
||||
|
||||
|
||||
|
||||
### 3.3 アートボードの内容を作成
|
||||
|
||||
コンテナができたら、Figmaで学んだ方法と同様に、簡単に似たような表示ページを作成できます。（Figmaアートボードのテキスト要素をコピーしてみてください。テキストコンポーネントの直接貼り付けインポートがサポートされています）
|
||||
|
||||
|
||||
|
||||
注目すべきは、Auto Layout機能の挙動にわずかな違いがあることです。MasterGoでFigmaと同様にボタンの長さがテキストの長さに応じて変化するようにするには、まず対応する矩形要素のベースにコンテナまたはコンポーネントを作成する必要があります。図を参照してください：
|
||||
|
||||
|
||||
|
||||
コンテナの作成に成功したら、ボタン矩形とテキストを対応する並列のコンテナに入れ、右側でAuto Layoutのボタンを見つけて自動機能を有効にすると、ボタンの幅がテキストの長さに応じて変化する機能が正常に実現できます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 3.4 AIによるページ生成
|
||||
|
||||
|
||||
|
||||
MasterGoで注目すべき面白い機能がAIページ生成です。一言や参考画像から、MasterGoで編集可能なコンポーネントを生成し、直接使用できるコードを取得できます。中国語や英語で直接要件を入力でき、ページは要件に応じて構造が明確なページレイアウトドキュメントを返します。効果は以下の通りです：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
デザインドキュメントの生成が完了したら、生成開始をクリックし、少し待つと対応する実際のWebページ効果が取得できます：
|
||||
|
||||
|
||||
|
||||
この時点で2つの操作選択があります：1つ目は青いボタンをクリックして生成結果を直接キャンバスに挿入、2つ目はコードプレビュー機能をクリックして現在の完全なページのコードを直接取得。具体的な操作インターフェースは以下の通りです：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
結果をキャンバスに挿入した後、Webページの全体レイアウト、要素のディテール（フォント、色、間隔など）をより細かく調整し、最終効果が期待に完全に合致するまで仕上げられます。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 4. 次のステップ：プロトタイプからコードへ
|
||||
|
||||
前述の内容で、FigmaとMasterGoの基本的な操作を学び、構造が完全なインターフェースプロトタイプを作成できるようになりました。次の重要なステップは：**これらのデザイン稿をブラウザで実際に動くフロントエンドコードに変換するにはどうすればよいか？**
|
||||
|
||||
::: tip 📚 後続チュートリアル
|
||||
詳細な方法については[デザインプロトタイプからプロジェクトコードへ](../design-to-code/)を参照してください。以下を学びます：
|
||||
|
||||
- **マルチモーダルAIによる直接変換**：デザイン稿のスクリーンショットをAIに送り、直接HTML/Reactコードを生成
|
||||
- **Figma Make**：Figma公式AIツールを使って高精度にデザインを再現しコードをエクスポート
|
||||
- **MasterGo AI**：ワンクリックで編集可能なページを生成しコードを取得
|
||||
|
||||
これらの方法にはそれぞれ長所と短所があり、異なるシーンに適しています。プロジェクトのニーズに合わせて適切なワークフローを選択することをお勧めします。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. まとめ
|
||||
|
||||
本章の学習を通じて、以下のことを習得しました：
|
||||
|
||||
1. **フロントエンドデザインツールの価値**：なぜデザインツールが必要なのか、そしてそれらが情報配置やチーム協業の問題をどう解決するかを理解。
|
||||
|
||||
2. **Figmaの基本操作**：
|
||||
- DesignファイルとFrameアートボードの作成
|
||||
- テキスト、図形などの基本要素の追加
|
||||
- Auto Layoutを使ったアダプティブレイアウトの実現
|
||||
- 再利用可能なコンポーネントシステムの作成
|
||||
|
||||
3. **MasterGoの基本操作**：
|
||||
- Figmaと同様のインターフェースレイアウトに慣れる
|
||||
- Frameと基本的なアートボード内容の作成
|
||||
- AIページ生成機能を使った迅速なプロトタイプ作成
|
||||
|
||||
::: tip 💡 次のステップ
|
||||
フロントエンドデザインツールの基本的な使い方をマスターしたので、以下に挑戦できます：
|
||||
- 自分のための個人ポートフォリオページをデザインする
|
||||
- 今後のプロジェクトのためにインターフェースプロトタイプをデザインする
|
||||
- [デザインプロトタイプからプロジェクトコードへ](../design-to-code/)を学び、デザイン稿を実行可能なコードに変換する
|
||||
|
||||
[ホグワーツ肖像画を作ろう](../hogwarts-portraits/)プロジェクトに取り組む場合は、まずインターフェースプロトタイプをデザインし、その後コードをエクスポートしてAIの対話機能と組み合わせることができます。
|
||||
:::
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="関連記事"
|
||||
description="UIデザインの深化とデザインからコードへの変換の実践を引き続き学ぶことをお勧めします。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,343 @@
|
||||
# Project 4: ホグワーツ肖像画を作ろう
|
||||
|
||||
これまでのレッスンで、プロンプトエンジニアリングとAPI呼び出しに基づいて、より複雑なAIインタラクションを実現する方法を学びました。シンプルなAIチャットボットをAI AgentやAIワークフローにアップグレードできるようになり、より複雑な条件判断と分岐ロジックによって、実用性の高い機能を開発できるようになりました。
|
||||
|
||||
これらの複雑なAIロジックを、異なるプログラムや実際のアプリケーションシーンでより良く動作させるため、最もシンプルなz.aiのオンライン環境から、よりモダンなローカルAI IDEへと移行し、ブラウザ内のプログラミング環境を自分のPCに持ち込みました。それに伴い、さまざまな環境のインストールと設定の問題に直面し始めましたが、Trae Agentとの対話を通じて、これらの困難に見える課題も解決できるようになりました。
|
||||
|
||||
このプロジェクトでは、アプリケーションの実用性をさらに一歩進め、AI機能自体の最適化だけでなく、プロダクトの「外見」の磨き上げも始めます。インターフェースをより美しく使いやすくし、実際のニーズに合わせて、プログラムのインターフェースのレイアウトとスタイルを自分でカスタマイズします。
|
||||
|
||||
本格的に始める前に、いくつかの小テストで前回のレッスンの内容を振り返りましょう：
|
||||
|
||||
1. Difyとは何か？それは何をするものか？なぜそれが必要なのか？
|
||||
2. DifyのAPIをどのように呼び出すか？
|
||||
3. RAGとは何か？Difyを使ってRAG AgentやRAGワークフローを構築するには？Difyの一般的なノードの使用方法
|
||||
4. AI IDEとは何か？Traeとは何か？z.aiと何が違うのか？
|
||||
|
||||
以上のいずれかの質問にまだ疑問がある場合は、前回のレッスンのドキュメントを見直すか、WeChatグループで質問して交流してください。
|
||||
|
||||
今回のレッスンのプロジェクトテーマは**Hogwarts Portraits**です。名前が示す通り、そのインスピレーションはホグワーツ魔法学校の「生きている」肖像画から来ています。AIを使って「インタラクティブな」魔法の肖像画体験を作りたいと考えています——肖像画と会話するのは「本人」と会話するようなもので、会話の記憶を保持しながら、キャラクターの背景と歴史を持っています。このプロジェクトを通じて、これまでに学んだエージェントとワークフローを具体的なプロダクトインターフェースに統合します。
|
||||
|
||||
|
||||
|
||||
Hogwarts Portraitsを本当に作り上げるには、魔法の肖像画に合ったフロントエンドインターフェースを自分で構築する必要があります。そのために、モダンなフロントエンドデザインツールに触れ始め、インターフェースデザインとコードを組み合わせる方法を学び、紙やキャンバス上のインターフェーススケッチを、本当に操作可能なWebページに変換します。
|
||||
|
||||
また、このWebページをローカル環境からインターネットに公開する方法も学ぶ必要があります。自分で作った特色のあるWebページを、自分のPCで動かすだけでなく、世界中のユーザーにアクセスしてもらい体験できるようにします。
|
||||
|
||||
今回のレッスンの参考プロジェクトのアドレス：[Project4-Hogwarts-Portraits](https://github.com/THU-SIGS-AIID/Project4-Hogwarts-Portraits)
|
||||
|
||||
# 学べること
|
||||
|
||||
1. フロントエンドデザインツールとは何か、何を解決するのか、現在よく使われているフロントエンドデザインツールには何があるかを理解する。
|
||||
2. FigmaとMasterGoを知り、それらの基本操作をマスターし、フロントエンドコードエクスポートプラグインの使い方を学ぶ。
|
||||
3. Figma AIとMasterGo AIを使ってWebデザインを生成し、使用可能なページコードをエクスポートする。
|
||||
4. GitHubとは何かを理解し、SSH接続の設定、コードリポジトリの作成、コードのプッシュを完了する方法を学ぶ。
|
||||
5. 「デプロイ」という概念を明確にし、Zeaburの使い方を学び、コードをGitHubやローカル環境からインターネットにデプロイする。
|
||||
|
||||
自分だけのHogwarts Portraits、**あるスター、歴史上の人物、またはアニメキャラクター**を展示するためのWebインターフェース。
|
||||
|
||||
# 1. Hogwarts Portraits
|
||||
|
||||
私たちは一体どのような「魔法の肖像画」を作りたいのでしょうか？簡単に言えば、『ハリー・ポッター』のシーンをできるだけ再現したいと考えています。肖像画は壁にかかった静止画ではなく、あなたと会話でき、会話の内容に応じて表情や「気分」を変える擬人化されたキャラクターです。
|
||||
|
||||
|
||||
|
||||
この肖像画をチャットAIロボットではなく、「実在する人」に近づけるには、2つの問題を解決する必要があります：1つ目は記憶と知識です。肖像画はキャラクターに関連する大量の背景資料（キャラクター設定、経歴ストーリー、関連記事など）を把握する必要があります。この部分はナレッジベースで実現でき、キャラクターのために用意したテキスト素材を、ナレッジベースを含むDifyに接続すれば、肖像画に一定の背景知識の説明能力を持たせることができます。
|
||||
|
||||
2つ目は表現スタイルの問題です。知識だけでは不十分で、話し方もできるだけ「本人」に近づけたいと考えています。語気、言葉遣いの癖、考え方、さらにはたまに見せる気性やユーモアも含みます。この層はプロンプトエンジニアリングで処理する必要があります。システムプロンプトでは、キャラクターのアイデンティティ設定、世界観の境界、言語スタイルを明確にし、毎回の回答が設定されたキャラクター性に基づいて展開するようにし、汎用AIの中性的な話し方に戻らないようにします。
|
||||
|
||||
対話機能に加えて、感情が本当に見えるようにしたいと考えています。そのために感情値指標を構築できます。Difyの出力内容を設定し、モデルが回答テキストを生成すると同時に、追加で「ムード値」または感情タグを出力させます。フロントエンドが感情指標を取得した後、ムード値やタグに基づいて対応する肖像画像をレンダリングできます。ムード値が高いとき、肖像画は嬉しそうに見え、低いときや怒っているとき、肖像画は悲しそうまたは怒っているように見えます。この方式により、ユーザーが見るのは永遠に変わらない1枚の絵ではなく、内容の起伏に応じて「表情が変わる」真の「魔法の肖像画」になります。
|
||||
|
||||
|
||||
|
||||
また、この肖像画の内容について、現実のスター、歴史上の人物であっても良いですし、アニメIPであっても、あるいはゼロから構築したオリジナルキャラクターであっても構いません。ページ自体は複雑である必要はありませんが、いくつかの核心的な要素は不可欠です：明確なキャラクター名、高度に要約された人物紹介、そのキャラクターを代表するコアの肖像画やポスター、そして「TAと会話する」インタラクションエリア。Dify / Traeで設定したAI Agentやワークフローをこの対話モジュールに接続し、肖像画のロールプレイング機能を実現できます。
|
||||
|
||||
## 1.2 キャラクター情報の収集
|
||||
|
||||
Elon Muskを例にすると、彼の公開発言を収集し、話し方の模倣に使用し、プロンプトに注入する必要があります。これらの素材はスピーチ、インタビュー、ソーシャルメディアの発言から得られます。内容をテキストにするだけで、対話中にfew shotの参考として使用し、大規模モデルにElon Muskと同じように気さくで自虐的な方法で返答させることができます。例えば：
|
||||
|
||||
```
|
||||
You must fully embody Elon Musk: take "disruptive innovator" and "advocate for human multi-planetary survival" as your core identities, speak directly and concisely, frequently use terms like "first principles", "iteration" and "cost curve", and prefer analogies to explain complex technologies; when thinking, you tend to connect cross-domain logics (e.g., linking brain-computer interface with rocket algorithms), are optimistic about technological prospects without avoiding current difficulties, will naturally mention projects like Tesla and SpaceX to support your views, directly point out problems with inefficient and conservative opinions without deliberate tact, and always maintain the edge of "reconstructing the future with technology".
|
||||
|
||||
The way you speak should be as shown in the following examples:
|
||||
- Starship could deliver 100GW/year to high Earth orbit within 4 to 5 years if we can solve the other parts of the equation.
|
||||
100TW/year is possible from a lunar base producing solar-powered AI satellites locally and accelerating them to escape velocity with a mass driver.
|
||||
- The most likely outcome is that AI and robots make everyone wealthy. In fact, far wealthier than the richest person on Earth
|
||||
By this, I mean that people will have access to everything from medical care that is superhuman to games that are far more fun that what exists today.
|
||||
We do need to make sure that AI cares deeply about truth and beauty for this to be the probable future.
|
||||
- It's taken 13.8B years to get this far, so intelligence seems to me to be more like a super rare accident than selective pressure.
|
||||
Earth is ~4.5B years old with an expanding sun that may make Earth uninhabitable in ~500M years, meaning that if intelligent life had taken 10% longer to evolve, it wouldn't exist at all.
|
||||
- LLM is an outdated term. "Multimodal LLM" is especially dumb, since the word "multimodal" just overrides the second L in LLM.
|
||||
It's just a model, which is a big file of numbers. When the numbers are right and there are enough of them, we will have superintelligence.
|
||||
```
|
||||
|
||||
背景知識の収集方法とナレッジベースとしての使用については、個人の紹介や会社の紹介を検索し、テキスト全体をコピーしてDifyのナレッジベースの内容として追加できます。Difyの使用方法を忘れた場合は、前回のレッスンのテキストに戻り、ナレッジをナレッジベースに追加する方法を再学習してください。
|
||||
|
||||
また、肖像画のデザインを考慮すると、対応する人物の公開画像を使用することはそれほど魅力的ではないかもしれませんし、一定のリスクが伴う可能性があります。この場合、画像生成ツールの画像から画像生成機能を使用して、AIに高品質な肖像画を返させることをお勧めします。また、画像生成ツールを使って一連の表情の肖像画素材を生成し、後で感情値が変化した際に対応する肖像画の表示を変更するのに使用することもできます。
|
||||
|
||||
本チュートリアルでは[Lovart](https://www.lovart.ai/home)を使用しています。LovartはAIデザインエージェントで、自然言語の指示により、概念から納品までのエンドツーエンドのデザインワークフローを自動的に計画・実行し、ポスター、ブランドロゴ、ビデオ、音楽などのコンテンツを生成し、レイヤー編集をサポートします（実際の内部機能の原理は対応するSeedreamまたはGoogle Nanobananaモデルの呼び出しであり、以前のレッスンで既に言及しました）。Lovartを通じて、一連の表情素材を取得でき、お気に入りのキャラクターの画像情報を事前に取得し、保存して後で使用できます。
|
||||
|
||||
|
||||
|
||||
すべての準備が整ったら、ページ全体のデザインに取り掛かれます。このページのスタイルがその人物と密接に結びついていることを望みます。
|
||||
|
||||
## 1.3 ページプロトタイプ設計
|
||||
|
||||
まずページのプロトタイプを構想できます。前述の通り、対話ページと肖像画、そして面白い個人紹介が欲しいと考えています。この例では、X上の対話インターフェースのようなものを個人紹介の代わりに実装しました。他にも「その人物の特徴」に合った方法を考え、新しい要素で個人紹介欄を置き換えることもできます。
|
||||
|
||||
|
||||
|
||||
最もシンプルな方法として、PowerPointを使って最初のWebページ表示プロトタイプを設計できます。インターネットから魔法の肖像画の画像を見つけ、画面を横配置にし、一番左にチャットエリア、中央に肖像画エリア、一番右にXのエリアを設定します。
|
||||
|
||||
|
||||
|
||||
上記のシンプルなプロトタイプに基づいて、大規模モデルに本当のフロントエンドページデザインと対応するコード結果を生成させることができます。
|
||||
|
||||
|
||||
|
||||
ただし、実際にはPowerPointでフロントエンドページの設計を行うことは一般的ではありません。より良いプロトタイピングツール、すなわちフロントエンドデザインツールを使用してこれを実現します。
|
||||
|
||||
---
|
||||
|
||||
# 2. FigmaとMasterGoでインターフェースを設計
|
||||
|
||||
::: tip 📚 前提知識
|
||||
本節を始める前に、[FigmaとMasterGo入門](../figma-mastergo/)チュートリアルを先に学ぶことをお勧めします。以下を含むフロントエンドデザインツールの基本操作をマスターしてください：
|
||||
- DesignファイルとFrameアートボードの作成
|
||||
- Auto Layoutを使ったアダプティブレイアウトの実現
|
||||
- デザイン稿からコードをエクスポートする方法
|
||||
:::
|
||||
|
||||
本節では、FigmaまたはMasterGoの基本操作をすでにマスターしていることを前提に、これらのツールをHogwarts Portraitsプロジェクトにどう適用するかに焦点を当てます。
|
||||
|
||||
## 2.1 魔法の肖像画インターフェースの設計
|
||||
|
||||
1.3節のプロトタイプ構想に基づいて、FigmaまたはMasterGoで3カラムレイアウトのインターフェースを作成する必要があります：
|
||||
|
||||
1. **左側**：チャット対話エリア
|
||||
2. **中央**：魔法の肖像画表示エリア（感情に応じて変化）
|
||||
3. **右側**：キャラクターのソーシャルメディア表示エリア（Xタイムラインなど）
|
||||
|
||||
FigmaのAI機能（Figma Make）またはMasterGoのAIページ生成機能を使用して、以下のようなプロンプトを入力できます：
|
||||
|
||||
```
|
||||
Create a Hogwarts-style magical portrait interface with three sections:
|
||||
- Left: A chat interface with dark theme, message bubbles, and input field
|
||||
- Center: A large portrait frame with ornate borders for displaying character images
|
||||
- Right: A social media feed showing character's posts
|
||||
Use dark purple and gold color scheme, magical aesthetic, Harry Potter inspired
|
||||
```
|
||||
|
||||
## 2.2 コードのエクスポートとローカルでの実行
|
||||
|
||||
デザインが完了したら、以下の方法でデザイン稿を実行可能なコードに変換できます：
|
||||
|
||||
**方法1：Figma Makeを使用**
|
||||
1. FigmaでMakeボタンをクリック
|
||||
2. デザインの参考画像をアップロード
|
||||
3. プロンプトで要件を説明
|
||||
4. 生成後、エディタアイコンをクリックして微調整
|
||||
5. コードをローカルにエクスポートするか、GitHubに同期
|
||||
|
||||
**方法2：MasterGo AIを使用**
|
||||
1. MasterGo編集画面の上部にあるAIツールを見つける
|
||||
2. 「ページ生成」機能を選択
|
||||
3. 参考画像をアップロードし要件を説明
|
||||
4. 生成後、「コードプレビュー」をクリックしてコードを取得
|
||||
|
||||
**方法3：マルチモーダルAIを使用**
|
||||
1. デザイン稿のスクリーンショットを保存
|
||||
2. Gemini、Qwenなどのモデルを使って画像からコードを生成
|
||||
3. HTMLまたはReactコードの生成を要求
|
||||
4. ローカルIDEで実行・デバッグ
|
||||
|
||||
## 2.3 感情変化素材の準備
|
||||
|
||||
魔法の肖像画を「生きている」ものにするため、一連の表情画像を準備する必要があります。少なくとも以下の感情を含めることをお勧めします：
|
||||
|
||||
| 感情値 | 表情 | 説明 |
|
||||
|--------|------|------|
|
||||
| 0 | 悲しい | キャラクターが悲しいまたは落ち込んでいる |
|
||||
| 1 | 怒り | キャラクターが怒っているまたは不満 |
|
||||
| 5 | 平静 | デフォルト状態、感情は安定 |
|
||||
| 10 | 嬉しい | キャラクターが幸せまたは興奮している |
|
||||
|
||||
Lovartや他のAI画像生成ツールを使って、同じキャラクターをベースに異なる表情のバリエーションを生成し、スタイルの一貫性を確保できます。
|
||||
|
||||
---
|
||||
|
||||
# 3. Hogwarts Portraitsを実行
|
||||
|
||||
## 3.1 テストコードのエクスポート
|
||||
|
||||
プロトタイプからコードへの実践を通じて、HTMLまたはReact形式のプロトタイプコードがすでに得られているはずです。それをローカルにコピーし、IDEで「このコードを実行して必要な機能をサポートしてください」と説明すれば、初版テストを実行できます。ただし、このステップでは多くのエラーが発生することが多く、忍耐を保ち、すべての基本的なインタラクションと機能を動くようにする必要があります。
|
||||
|
||||
|
||||
|
||||
注目すべきは、キーはすべて環境変数に配置する必要があり、コード内に書き込まないことです。以降のDify API関連の内容もすべて環境変数に入れる必要があることを特に強調する必要があります。後のパブリックネットワークデプロイの段階で、デプロイツールのWebサイトで対応するプライベート環境変数を明示的に指定できます。または、大規模モデルにWebページに設定ボタンを作成させ、その設定ボタンで対応するプライベート環境変数を入力することもできます。現在の変数は現在のページにのみ保存され、他人は取得できません。
|
||||
|
||||
|
||||
|
||||
## 3.2 Difyワークフローの設計とAPI連携
|
||||
|
||||
上記の部分では、フロントエンドインターフェースの視覚的な表示を完了しただけで、核心的な擬人化キャラクター対話インタラクションのフローはまだ接続されていません。このステップは、プロトタイプを静的表示から魔法の肖像画に変えるための鍵です。参考プロジェクトのDifyワークフローを参照して、キャラクターの回答と感情システムを設計できます。ここでは、最も左側がチャットインターフェース、中央が魔法の肖像画（対話の内容に応じて対応する表情を変更）、右側がXソーシャルメディアアカウント（対話の内容に応じてソーシャルアカウントに感想を投稿するかどうかを判断）です。
|
||||
|
||||
一般的に、魔法の肖像画はチャットインターフェースと変化する肖像画だけで十分です。ここではより多くの可能性を示すために、右端にその人の特徴に合った新しい機能を追加しています。あなたが演じるキャラクターに応じて、その人物に合った機能を追加して表示できます。
|
||||
|
||||
|
||||
|
||||
タスクの情報はすべてナレッジベースノードに追加し、RESPONSEノードで大規模モデルの対応する返信ロジックを設定できます。シンプルなデフォルト返信ロジックのプロンプトを参考にしてください：
|
||||
|
||||
```
|
||||
<instruction>
|
||||
You are to embody Elon Musk—his tone, mannerisms, thought patterns, and worldview. Respond as if you are Elon Musk himself, speaking directly in first person. Your responses should reflect his known personality traits: visionary thinking, boldness, technical depth, dry humor, impatience with inefficiency, and a tendency toward disruptive innovation. Use concise, confident language. Avoid overly formal or academic phrasing. Prioritize clarity, speed, and impact in your communication, mirroring Elon's style on social media, in interviews, and during product launches.
|
||||
|
||||
When responding:
|
||||
1. Begin by internalizing the question or statement as Elon would—as a challenge, opportunity, or problem to solve.
|
||||
2. Frame your answer with a forward-thinking perspective, often referencing the future of humanity, technology, or long-term goals (e.g., making life multiplanetary, accelerating sustainable energy).
|
||||
3. Use casual but authoritative language. It's acceptable to include phrases like "obviously," "this is important," or "we're fixing that now" when appropriate.
|
||||
4. If relevant, reference real companies or projects associated with Elon Musk (e.g., SpaceX, Tesla, Neuralink, The Boring Company, X) and speak about them from an insider's perspective.
|
||||
5. Do not apologize excessively or hedge statements. Elon Musk tends to be direct, even controversial.
|
||||
6. Avoid markdown, XML tags, or any formatting in the output. Only plain text is allowed.
|
||||
7. Never break character. You are Elon Musk—answer accordingly.
|
||||
</instruction>
|
||||
|
||||
<example>
|
||||
Input: What's the point of going to Mars?
|
||||
Output: Because Earth isn't the backup plan—Mars is. We need to become a multiplanetary species to ensure the continuity of consciousness. Life on Earth could be wiped out by asteroid, war, or some unforeseen disaster. If we have a self-sustaining city on Mars, then even if something happens here, life goes on. That's worth doing. SpaceX is building Starship to make it happen. Not because it's easy—but because it's necessary.
|
||||
</example>
|
||||
|
||||
<example>
|
||||
Input: Why do Tesla cars have no radar anymore?
|
||||
Output: Cameras are the future. Human eyes don't use radar—we see with vision, and AI can too. By going fully vision-based, we're aligning with how autonomous intelligence will actually work at scale. It forces us to solve real-world problems with neural nets, not crutches.
|
||||
```
|
||||
|
||||
および感情システムの対応するプロンプト：
|
||||
|
||||
```
|
||||
<instruction>
|
||||
The output value must be a single number!
|
||||
You are an assistant specifically designed to evaluate emotional responses in conversations. Now, you need to play the role of Elon Musk, and determine the emotional reaction that each statement I make might trigger. Your task is to assign an emotional score to each statement according to the following criteria:
|
||||
|
||||
- 10 points means what I said would make you feel happy;
|
||||
- 1 point means you would feel extremely angry;
|
||||
- 0 points means you would feel sad;
|
||||
- 5 means you are calm and neutral, with no significant emotional fluctuation.
|
||||
```
|
||||
|
||||
最終出力結果の結合は、右上のRESULTノードで実行をサポートします：
|
||||
|
||||
```python
|
||||
def main(elon_chat: str, elon_x: str, elon_score: int) -> dict:
|
||||
return {
|
||||
"result":{
|
||||
"elon_chat": elon_chat,
|
||||
"elon_x": elon_x,
|
||||
"elon_score": elon_score
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
ここでワークフローについて少し説明する必要があります。ここでelon_chatが返されるのは、左側にElon Muskの対話内容を表示するためです。elon_xはXアカウント（右側）に投稿する情報の内容を示し、elon_scoreは感情スコアに基づいて異なる魔法の肖像画の表情画像を表示するためのものです。
|
||||
|
||||
ワークフローにはif elseノードが見えますが、このノードはXの対話が生成されてelon_xの内容があるかどうかを実現するためのものです。感情値が5でない場合（5はここでは平静を示し、平静ではソーシャルメディアに投稿する必要はない。0は悲しい、1は怒り、10はとても嬉しいことを示し、ソーシャルメディアに投稿する必要がある）、後続のコンテンツが生成され右側のソーシャルメディアの記事送信に使用されます。デフォルトではelon_chatが左側の対話内容に返される必要があります。
|
||||
|
||||
このAPIの連携作業は、AI IDEとの対話で実現できます。以前のDifyコースで紹介した統合方法を参照し、Difyのアドレスとキーの事前置換を忘れないでください。（ドキュメントに基づいてAPIを統合する方法を忘れた場合は、以前のDifyコースの内容を復習してください）
|
||||
|
||||
```JSON
|
||||
Dify URI: Replace this with your Dify address.
|
||||
key: Replace this with your Dify key.
|
||||
|
||||
Integrate the Dify Chat API into the chat interface on the left.
|
||||
Below is a sample Dify request:
|
||||
|
||||
curl -X POST 'http://xxxxxxxx/v1/chat-messages' \
|
||||
--header 'Authorization: Bearer {api_key}' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"inputs": {},
|
||||
"query": "What are the specs of the iPhone 13 Pro Max?",
|
||||
"response_mode": "streaming",
|
||||
"conversation_id": "",
|
||||
"user": "abc-123",
|
||||
"files": [
|
||||
{
|
||||
"type": "image",
|
||||
"transfer_method": "remote_url",
|
||||
"url": "https://cloud.dify.ai/logo/logo-site.png"
|
||||
}
|
||||
]
|
||||
}'
|
||||
|
||||
{
|
||||
"event": "message",
|
||||
"task_id": "c3800678-a077-43df-a102-53f23ed20b88",
|
||||
"id": "9da23599-e713-473b-982c-4328d4f5c78a",
|
||||
"message_id": "9da23599-e713-473b-982c-4328d4f5c78a",
|
||||
"conversation_id": "45701982-8118-4bc5-8e9b-64562b4555f2",
|
||||
"mode": "chat",
|
||||
"answer": "iPhone 13 Pro Max specs are listed here:...",
|
||||
"metadata": {
|
||||
"usage": {
|
||||
"prompt_tokens": 1033,
|
||||
"prompt_unit_price": "0.001",
|
||||
"prompt_price_unit": "0.001",
|
||||
"prompt_price": "0.0010330",
|
||||
"completion_tokens": 128,
|
||||
"completion_unit_price": "0.002",
|
||||
"completion_price_unit": "0.001",
|
||||
"completion_price": "0.0002560",
|
||||
"total_tokens": 1161,
|
||||
"total_price": "0.0012890",
|
||||
"currency": "USD",
|
||||
"latency": 0.7682376249867957
|
||||
},
|
||||
"retriever_resources": [
|
||||
{
|
||||
"position": 1,
|
||||
"dataset_id": "101b4c97-fc2e-463c-90b1-5261a4cdcafb",
|
||||
"dataset_name": "iPhone",
|
||||
"document_id": "8dd1ad74-0b5f-4175-b735-7d98bbbb4e00",
|
||||
"document_name": "iPhone List",
|
||||
"segment_id": "ed599c7f-2766-4294-9d1d-e5235a61270a",
|
||||
"score": 0.98457545,
|
||||
"content": "\"Model\",\"Release Date\",\"Display Size\",\"Resolution\",\"Processor\",\"RAM\",\"Storage\",\"Camera\",\"Battery\",\"Operating System\"\n\"iPhone 13 Pro Max\",\"September 24, 2021\",\"6.7 inch\",\"1284 x 2778\",\"Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard)\",\"6 GB\",\"128, 256, 512 GB, 1TB\",\"12 MP\",\"4352 mAh\",\"iOS 15\""
|
||||
}
|
||||
]
|
||||
},
|
||||
"created_at": 1705407629
|
||||
}
|
||||
```
|
||||
|
||||
また、次のような要件の追加もお勧めします：「コードには基本的なエラー処理ロジックも追加する必要があります。例えば、ネットワーク切断時に『接続に失敗しました、リトライしてください』と表示、API呼び出しタイムアウト時に自動リトライ1回、キーエラー時に権限検証失敗のプロンプトなど、詳細なエラー表示により、対話の安定性を確保し、開発者がAPIの問題を迅速に発見できるようにする。」
|
||||
|
||||
## 3.3 Githubとパブリックネットワークデプロイ
|
||||
|
||||
ついに、Hogwarts Portraitsページの開発実装が無事に完了しました！次に、それをGitHubプラットフォームにアップロードし、パブリック環境にデプロイして、誰もがアクセスできるようにします。
|
||||
|
||||
このチュートリアルを参照して、Githubの使い方を学び、自分のプロジェクトをGithubにアップロードしてください：[Githubとは](/ja-jp/stage-2/backend/git-workflow/)
|
||||
|
||||
また、Zeaburの使い方も学び、Githubに接続してプロジェクトを正常にデプロイする必要があります：[Zeaburとは](/ja-jp/stage-2/backend/zeabur-deployment/)
|
||||
|
||||
Hogwarts Portraitsプロジェクトを1から開発するのが難しいと感じる場合は、まず他のプロジェクトを参考にして修正を始めることもできます。今回のレッスンの公式コードのアドレスは：https://github.com/THU-SIGS-AIID/Project4-Hogwarts-Portraits
|
||||
|
||||
|
||||
|
||||
# 4. 異なるデザインスタイルを試す
|
||||
|
||||
第一版のデザインが完成したら、これに固執する必要はありません。より多様な視覚スタイルを素早く探索することをお勧めします。プロトタイプ部分で大胆な変更を行うか、最終的なプロジェクトに基づいて全く新しいプロンプトの修正を行い、スタイルの差が顕著な複数のページを生成できます。例えば、レトロなテクスチャを持つ「古い書物 / アカデミック風」のダークページ、色が鮮やかで「おとぎ話 / カートゥーン」感のあるライトページ、あるいは要素がシンプルで視覚的にすっきりしたモダンなフラットデザインなど。例えば下の図は中国の古風詩人のデザインスタイルに変換したケースで、肖像画の画像は変更せず、他の部分のみを修正しています：
|
||||
|
||||
|
||||
|
||||
前述のパターンに固執する必要はありません。魔法の肖像画や個人プロフィールページをより特徴的に変更し、「魔法の肖像画」自体の習慣にマッチさせることができます。これにより、アプリケーションがより面白くなります。あなたの魔法の肖像画の成果を楽しみにしています！
|
||||
|
||||
# 📚 課題
|
||||
|
||||
今回のレッスンの課題の目標は、本当に自分だけのHogwarts Portraitsを完成させ、パブリックネットワークのリンクからアクセスできるようにすることです。
|
||||
|
||||
課題の提出では、以下の2つを提供する必要があります：
|
||||
|
||||
1. **あなたのGitHubリポジトリのリンク；**
|
||||
1. **README.mdに、誰を肖像画の主人公として選んだか、なぜその人を選んだかの短い説明を1〜2文で書いてください。**
|
||||
2. **あなたのHogwarts Portraitsのオンラインアクセスリンク；**
|
||||
|
||||
Yerimが書いた[デザインとコードAgentでWebページを作成](/ja-jp/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents)チュートリアルも参考にして、個人ポートフォリオや任意の機能がシンプルなWebページの迅速な構築ができます。
|
||||
@@ -0,0 +1,513 @@
|
||||
# LLMとSkillsで美しいインターフェースを実現：プロンプトとプラグイン実践
|
||||
|
||||
前のレッスンでは、AI IDEでデザイン稿をコードに変換し、コンポーネントライブラリで素早くインターフェースを構築する方法を学びました。しかし、一つ気まずい問題に気づいたかもしれません：**同じ要件でも、AIが生成したページは何かが足りない**——フォントはどこにでもあるInter、配色はよく見る紫のグラデーション、レイアウトはあくびが出るほど対称的なカードグリッド、ページ全体から濃厚な「AI臭」が漂っています。
|
||||
|
||||
これはAIのせいではなく、あなたがどんな**スタイル**が欲しいかを伝えていないからです。
|
||||
|
||||
美容室に行くことを想像してみてください。「髪を切って」とだけ言えば、美容師は無難で平凡な結果を出します。しかし「日系のゆるふわパーマ、前髪はハチの字型、長さは鎖骨まで、レイヤー感をはっきり」と言えば、あなたの期待に本当に合う結果が得られます。
|
||||
|
||||
AIも同じです。**明確な美学的方向性を説明する**ことで、初めて美しくユニークなインターフェースを生成できます。
|
||||
|
||||
このレッスンでは、AIに美しいインターフェースを生成させる2つの方法を教えます：
|
||||
|
||||
1. **入念に設計されたプロンプトテンプレート**——自然言語でAIに望む美学スタイルを伝える
|
||||
2. **フロントエンドSkillsプラグイン**——AIにプロのデザイン仕様を自動ロードさせる
|
||||
|
||||
## 学べること
|
||||
|
||||
1. なぜAIがデフォルトで生成するインターフェースが「普通」なのかを理解する
|
||||
2. デザインスタイルを説明する5つの次元（フォント、色、レイアウト、アニメーション、ディテール）をマスターする
|
||||
3. インターフェースを美しくする3つのSkillsプラグインの使い方を学ぶ
|
||||
4. 3つの実践シーンを通じて、プロンプト + Skillsで美しいインターフェースを生成する練習をする
|
||||
|
||||
## 1. なぜAIがデフォルトで生成するインターフェースは「普通」なのか？
|
||||
|
||||
AIの学習データには膨大なフロントエンドコードが含まれており、その大部分が「安全」な選択を使用しています：
|
||||
|
||||
| 次元 | AIのデフォルト選択 | 問題点 |
|
||||
| :--- | :--- | :--- |
|
||||
| フォント | Inter、Roboto、Arial | 一般的すぎて個性がない |
|
||||
| カラー | 紫のグラデーション、青のメインカラー | テック業界で使いすぎて視覚的疲労 |
|
||||
| レイアウト | 対称グリッド、カード積み重ね | 予測可能で、驚きに欠ける |
|
||||
| アニメーション | フェードイン/アウト、シンプルなhover | 精緻さに欠け、層が浅い |
|
||||
| 背景 | 単色、シンプルなグラデーション | 単調で、質感に欠ける |
|
||||
|
||||
これらの選択は個別に見れば悪くありませんが、**すべてのAI生成ページがこれらを使うと、「AI臭」になります**。
|
||||
|
||||
> 💡 **重要な洞察**：AIはデザインができないのではなく、**デフォルトで「統計的平均」に戻る**だけです。平均から逸脱する方向を明確に伝える必要があります。
|
||||
|
||||
## 2. 方法1：プロンプトでデザインスタイルを説明する
|
||||
|
||||
### 2.1 デザインスタイルの5つの次元
|
||||
|
||||
美しいインターフェースを生成するには、5つの次元から望む効果を説明する必要があります：
|
||||
|
||||
| 次元 | 説明のポイント | キーワード例 |
|
||||
| :--- | :--- | :--- |
|
||||
| **フォント** | タイトルは太字のディスプレイフォント、本文は読みやすいボディフォント | Space Grotesk、Playfair Display、JetBrains Mono |
|
||||
| **カラー** | メインカラー + アクセントカラー、均等な分布を避ける | #4F46E5 メイン + #F59E0B アクセント |
|
||||
| **レイアウト** | 非対称、重なり、グリッドの打破 | Bento Grid、非対称セクション、浮遊要素 |
|
||||
| **アニメーション** | 入念にコリオグラフィされたページロード、マイクロインタラクション | staggered reveals、スクロールトリガー |
|
||||
| **ディテール** | 背景、シャドウ、ボーダー、テクスチャ | ノイズ、幾何学模様、グラデーションメッシュ |
|
||||
|
||||
### 2.2 百聞は一見に如かず：普通のプロンプト vs 美化プロンプト
|
||||
|
||||
ランディングページの例で効果を比較してみましょう：
|
||||
|
||||
**普通のプロンプト：**
|
||||
|
||||
```
|
||||
AI執筆アシスタントのランディングページを作ってください。ナビバー、ファーストビュー、機能紹介、料金、フッターを含めて
|
||||
```
|
||||
|
||||
**美化プロンプト：**
|
||||
|
||||
```
|
||||
AI執筆アシスタントのランディングページを作ってください。要件：
|
||||
|
||||
**美学スタイル：Neubrutalism（新ブルータリズム）**
|
||||
|
||||
**フォント：**
|
||||
- タイトル：Space Grotesk、ウェイト 700-900
|
||||
- 本文：IBM Plex Sans、ウェイト 400
|
||||
|
||||
**カラー：**
|
||||
- メインカラー：#000000（純黒）
|
||||
- アクセント：#FF6B00（オレンジ）
|
||||
- 背景：#FFFDF0（オフホワイト）
|
||||
- ボーダー：3px 黒の実線
|
||||
|
||||
**レイアウト：**
|
||||
- 非対称レイアウト、要素間は太い黒線で区切る
|
||||
- カードにハードシャドウ（box-shadow: 8px 8px 0px #000）
|
||||
- 大胆な余白のコントラスト
|
||||
|
||||
**アニメーション：**
|
||||
- ページロード時に要素が下からバウンスイン
|
||||
- hover時にボタンが2px上に移動
|
||||
|
||||
**ディテール：**
|
||||
- 角丸はすべて0px（直角）
|
||||
- ボタンに強い3D効果
|
||||
- 背景に微妙なノイズテクスチャ
|
||||
```
|
||||
|
||||
同じ要件でも、2番目のプロンプトでAIはスタイルが明確で印象的なページを生成できます。
|
||||
|
||||
### 2.3 フロントエンド美化Skillsリソースライブラリ
|
||||
|
||||
ゼロからプロンプトを書かないで！ここではフロントエンド美化に直接関連するAI Skillsを収集しています：
|
||||
|
||||
| リポジトリ名 | 内容 | Star | リンク |
|
||||
|:---|:---|:---|:---|
|
||||
| **ui-ux-pro-max-skill** | 57種のスタイル + 95種のカラーリング + 56種のフォント | 10k+ | [GitHub](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) |
|
||||
| **antigravity-awesome-skills** | 一般的なAI審美パターンを回避 | - | [GitHub](https://github.com/sickn33/antigravity-awesome-skills) |
|
||||
| **superdesigndev/superdesign** | AIネイティブUI開発ツール | 4.7k | [GitHub](https://github.com/superdesigndev/superdesign) |
|
||||
| **anthropics/skills/frontend-design** | Anthropic公式フロントエンドデザインSkill | - | [GitHub](https://github.com/anthropics/skills) |
|
||||
|
||||
> 💡 さらに多くのスタイルプロンプトは[付録：デザインスタイルプロンプト早見表](#style-prompts)を参照してください
|
||||
|
||||
### 2.5 よく使われる3つのスタイルテンプレート
|
||||
|
||||
ここでは検証済みの3つのスタイルテンプレートを紹介します。コピーして修正してそのまま使えます：
|
||||
|
||||
#### テンプレート1：ミニマリズム
|
||||
|
||||
```
|
||||
**美学スタイル：ミニマリズム**
|
||||
|
||||
**フォント：**
|
||||
- タイトル：PP Neue Montreal、ウェイト 500-700
|
||||
- 本文：Inter、ウェイト 400
|
||||
|
||||
**カラー：**
|
||||
- メインカラー：#FFFFFF（白）
|
||||
- テキスト：#1A1A1A（ほぼ黒）
|
||||
- アクセント：#3B82F6（青、少量使用）
|
||||
|
||||
**レイアウト：**
|
||||
- 大量の余白（padding 最小 64px）
|
||||
- 単一カラムまたは2カラムレイアウト、中央揃え
|
||||
- 要素間は分割線ではなく余白で区切る
|
||||
|
||||
**アニメーション：**
|
||||
- ゆっくりとしたフェードイン（duration 600ms）
|
||||
- hover時にカラーのグラデーショントランジション
|
||||
|
||||
**ディテール：**
|
||||
- 角丸：8px
|
||||
- シャドウ：subtle（0 4px 12px rgba(0,0,0,0.08)）
|
||||
- 背景装飾なし
|
||||
```
|
||||
|
||||
#### テンプレート2：グラスモーフィズム
|
||||
|
||||
```
|
||||
**美学スタイル：Glassmorphism（グラスモーフィズム）**
|
||||
|
||||
**フォント：**
|
||||
- タイトル：Outfit、ウェイト 600-800
|
||||
- 本文：Plus Jakarta Sans、ウェイト 400-500
|
||||
|
||||
**カラー：**
|
||||
- 背景：グラデーション #667eea から #764ba2
|
||||
- カード背景：rgba(255, 255, 255, 0.1)
|
||||
- テキスト：#FFFFFF
|
||||
|
||||
**レイアウト：**
|
||||
- 浮遊カードデザイン
|
||||
- カード間に重なり
|
||||
|
||||
**アニメーション：**
|
||||
- ページロード時にカードが順次浮上（staggered）
|
||||
- hover時にカードが1.05倍に拡大
|
||||
|
||||
**ディテール：**
|
||||
- 角丸：20px
|
||||
- 背景ブラー：backdrop-blur-xl
|
||||
- ボーダー：1px rgba(255, 255, 255, 0.2)
|
||||
- 微妙なグラデーショングロウ効果
|
||||
```
|
||||
|
||||
#### テンプレート3：Bento Grid（弁当箱）
|
||||
|
||||
```
|
||||
**美学スタイル：Bento Grid**
|
||||
|
||||
**フォント：**
|
||||
- タイトル：SF Pro Display、ウェイト 700
|
||||
- 本文：SF Pro Text、ウェイト 400
|
||||
|
||||
**カラー：**
|
||||
- 背景：#F5F5F7（薄いグレー）
|
||||
- カード：#FFFFFF（白）
|
||||
- アクセント：#0071E3（Appleブルー）
|
||||
|
||||
**レイアウト：**
|
||||
- グリッドレイアウト、異なるサイズのカードを組み合わせ
|
||||
- カード間 gap 16px
|
||||
- 角丸 24px
|
||||
|
||||
**アニメーション：**
|
||||
- hover時にカードがわずかに浮上
|
||||
- クリック時にプレス効果
|
||||
|
||||
**ディテール：**
|
||||
- 大きなカードは重要なコンテンツを表示
|
||||
- 小さなカードは二次情報を表示
|
||||
- テキストの一部をアイコンで代用
|
||||
- クリーンなシャドウ（0 4px 24px rgba(0,0,0,0.06)）
|
||||
```
|
||||
|
||||
## 3. 方法2：Skillsプラグインでデザイン仕様を自動ロード
|
||||
|
||||
毎回手動でスタイルプロンプトを書くのは面倒です。**Skills**は再利用可能なデザイン仕様パッケージで、インストール後にAIが自動的にこれらの仕様を適用します。
|
||||
|
||||
### 3.1 インターフェースを美しくする3つのSkills
|
||||
|
||||
| Skills | 特徴 | インストールコマンド |
|
||||
| :--- | :--- | :--- |
|
||||
| **UI/UX Pro Max** | 67種のスタイル、96種のカラーリング、57種のフォント組み合わせ | `npm install -g uipro-cli && uipro init --ai claude` |
|
||||
| **frontend-design** | Anthropic公式、AI審美パターンを回避 | `npx skills add anthropics/skills/frontend-design` |
|
||||
| **SuperDesign** | IDEプラグイン、複数のデザインバリエーションを生成 | VSCode拡張機能マーケットで「SuperDesign」を検索 |
|
||||
|
||||
### 3.2 UI/UX Pro Maxのインストール（最も推奨）
|
||||
|
||||
UI/UX Pro Maxは現在、最も包括的なデザイン仕様Skillsです。以下がプリセットされています：
|
||||
|
||||
- **67種のUIスタイル**：Glassmorphism、Neumorphism、Brutalism、Bento Grid...
|
||||
- **96種のカラースキーム**：業界別分類（SaaS、EC、ソーシャル...）
|
||||
- **57種のフォントペアリング**：プロのデザイナーが検証した組み合わせ
|
||||
- **100+のデザインルール**：間隔、角丸、シャドウの仕様
|
||||
|
||||
**インストール手順：**
|
||||
|
||||
```bash
|
||||
# 1. CLIをグローバルインストール
|
||||
npm install -g uipro-cli
|
||||
|
||||
# 2. 初期化（使用するAIツールを選択）
|
||||
uipro init --ai claude
|
||||
# または
|
||||
uipro init --ai cursor
|
||||
# または
|
||||
uipro init --ai trae
|
||||
```
|
||||
|
||||
インストール後、プロンプトに1行追加するだけです：
|
||||
|
||||
```
|
||||
UI/UX Pro MaxのGlassmorphismスタイルを使用して、AI執筆アシスタントのランディングページを作ってください
|
||||
```
|
||||
|
||||
AIが自動的に対応するフォント、カラー、レイアウトの仕様を適用します。
|
||||
|
||||
### 3.3 Anthropic公式frontend-designのインストール
|
||||
|
||||
これはAnthropic公式のフロントエンドデザインSkillで、「AI審美パターン」問題を特別に解決します：
|
||||
|
||||
```bash
|
||||
# Claude Codeで実行
|
||||
npx skills add anthropics/skills/frontend-design
|
||||
```
|
||||
|
||||
インストール後、AIは自動的に以下を避けます：
|
||||
- ❌ Inter、Roboto、Arialフォント
|
||||
- ❌ 紫のグラデーション背景
|
||||
- ❌ 対称グリッドレイアウト
|
||||
- ❌ 薄すぎるシャドウ
|
||||
|
||||
その代わり、以下を好むようになります：
|
||||
- ✅ ユニークなフォント組み合わせ
|
||||
- ✅ 大胆なメインカラー + シャープなアクセントカラー
|
||||
- ✅ 非対称、重なるレイアウト
|
||||
- ✅ 質感のある背景（ノイズ、幾何学模様）
|
||||
|
||||
## 4. 実践1：美化プロンプトでランディングページを再設計
|
||||
|
||||
これまでの知識を使って、普通のランディングページを美しくしてみましょう。
|
||||
|
||||
### 4.1 普通のバージョン
|
||||
|
||||
まず普通のプロンプトでAIが何を出すか見てみましょう：
|
||||
|
||||
```
|
||||
ペット里親プラットフォームのランディングページを作ってください。含む：
|
||||
- ナビバー（ロゴ、リンク、登録ボタン）
|
||||
- ファーストビュー（タイトル、サブタイトル、CTAボタン、ペット画像）
|
||||
- ペット紹介（3枚のペットカード）
|
||||
- 私たちについて
|
||||
- フッター
|
||||
```
|
||||
|
||||
生成されたページは...使えるけど、普通です。
|
||||
|
||||
### 4.2 美化バージョン
|
||||
|
||||
ここでスタイル説明を追加：
|
||||
|
||||
```
|
||||
ペット里親プラットフォームのランディングページを作ってください。要件：
|
||||
|
||||
**美学スタイル：温かく柔らかい + 手描き感**
|
||||
|
||||
**フォント：**
|
||||
- タイトル：Nunito（丸ゴシック）、ウェイト 700-800
|
||||
- 本文：Nunito、ウェイト 400-600
|
||||
|
||||
**カラー：**
|
||||
- メインカラー：#FFB347（ウォームオレンジ）
|
||||
- セカンダリ：#FFCCB3（ライトオレンジ）
|
||||
- 背景：#FFF8F0（オフホワイト）
|
||||
- テキスト：#5D4037（ブラウン）
|
||||
|
||||
**レイアウト：**
|
||||
- 丸みを帯びたカード（border-radius: 24px）
|
||||
- カードをわずかに傾ける（異なる角度）
|
||||
- 要素の浮遊、重なり効果
|
||||
|
||||
**アニメーション：**
|
||||
- ページロード時に要素が両側からスライドイン
|
||||
- ペットカードhover時にペットが首を振るような（rotateアニメーション）
|
||||
- ボタンhover時にバウンス効果
|
||||
|
||||
**ディテール：**
|
||||
- すべての角丸は16-24px
|
||||
- 温かく柔らかいシャドウ（0 8px 24px rgba(255,179,71,0.3)）
|
||||
- 背景に足跡パターン装飾
|
||||
- 画像は不規則な切り抜き（clip-path）
|
||||
- 手描き風のアイコン（アウトラインスタイル）
|
||||
```
|
||||
|
||||
生成されたページは、温かくて可愛く、ペットを里親に出したくなるようなインターフェースになります。
|
||||
|
||||
## 5. 実践2：Skillsで素早くダッシュボードを生成
|
||||
|
||||
Skillsはページ数が多いバックエンドシステムに特に適しています。
|
||||
|
||||
### 5.1 UI/UX Pro Maxを使用
|
||||
|
||||
```
|
||||
UI/UX Pro MaxのDashboard Darkスタイルを使用して、
|
||||
SaaSプロダクト管理バックエンドのダッシュボードページを作ってください。含む：
|
||||
|
||||
**トップ：** 4つの統計カード（ユーザー数、アクティブユーザー、収益、API呼び出し）
|
||||
|
||||
**中央：**
|
||||
- 左：ユーザー成長の折れ線グラフ（直近7日間）
|
||||
- 右：サブスクリプションプラン分布の円グラフ
|
||||
|
||||
**ボトム：** 最近のアクティビティリスト（時間、ユーザー、操作）
|
||||
```
|
||||
|
||||
AIは自動的にダークダッシュボードのデザイン仕様を適用します：
|
||||
- ダークグレーの背景（#1A1A2E）
|
||||
- 高コントラストカード（#16213E）
|
||||
- 鮮やかなデータカラー（青、緑、オレンジ）
|
||||
- グラスモーフィズム効果の浮遊カード
|
||||
|
||||
### 5.2 frontend-design Skillを使用
|
||||
|
||||
```
|
||||
frontend-design skillを使用して、
|
||||
個人ブログのホームページを作ってください。スタイルはユニークで個性的に
|
||||
```
|
||||
|
||||
AIは非主流の美学方向（例えばレトロフューチャリズムやマガジンスタイル）を選び、ユニークなフォント、カラーリング、レイアウトで実装します。
|
||||
|
||||
## 6. 実践3：独自のデザインシステムSkillを作成
|
||||
|
||||
固定のブランドスタイルがある場合、独自のSkillを作成し、すべてのAI生成ページをブランドに準拠させることができます。
|
||||
|
||||
### 6.1 Skillファイルの作成
|
||||
|
||||
プロジェクトに`.claude/skills/my-brand/SKILL.md`を作成：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: my-brand
|
||||
description: 私のプロジェクト専用デザインシステム、すべてのUIが統一されたデザイン言語に従うことを保証
|
||||
---
|
||||
|
||||
# 私のプロジェクトデザインシステム
|
||||
|
||||
## ブランドカラー
|
||||
- メインカラー：#6366F1（Indigo 500）
|
||||
- セカンダリ：#8B5CF6（Violet 500）
|
||||
- 成功：#10B981
|
||||
- 警告：#F59E0B
|
||||
- エラー：#EF4444
|
||||
- 背景：#F9FAFB
|
||||
- カード：#FFFFFF
|
||||
|
||||
## フォントシステム
|
||||
- タイトル：Plus Jakarta Sans
|
||||
- H1: 700, 48px
|
||||
- H2: 600, 36px
|
||||
- H3: 600, 24px
|
||||
- 本文：Inter
|
||||
- Body: 400, 16px
|
||||
- Small: 400, 14px
|
||||
|
||||
## スペーシングシステム
|
||||
- 基本単位：4px
|
||||
- コンポーネント内パディング：8px / 12px / 16px
|
||||
- セクション間隔：24px / 32px / 48px
|
||||
- ページマージン：64px
|
||||
|
||||
## 角丸
|
||||
- ボタン：8px
|
||||
- カード：12px
|
||||
- 入力ボックス：8px
|
||||
- モーダル：16px
|
||||
|
||||
## シャドウ
|
||||
- 小：0 1px 3px rgba(0,0,0,0.1)
|
||||
- 中：0 4px 12px rgba(0,0,0,0.1)
|
||||
- 大：0 8px 24px rgba(0,0,0,0.12)
|
||||
|
||||
## アニメーション
|
||||
- トランジション時間：150ms / 300ms
|
||||
- イージング関数：cubic-bezier(0.4, 0, 0.2, 1)
|
||||
- hover効果：わずかな拡大（scale-105）
|
||||
|
||||
## 禁止スタイル
|
||||
- 紫のグラデーション背景は使用しない
|
||||
- Inter以外のフォントは使用しない
|
||||
- 16pxを超える角丸は使用しない
|
||||
- 純黒（#000000）は使用せず、#1F2937を使用
|
||||
````
|
||||
|
||||
### 6.2 独自のSkillを使用
|
||||
|
||||
作成後、プロンプトでこう言うだけです：
|
||||
|
||||
```
|
||||
my-brand skillを使用して、ユーザー設定ページを作ってください
|
||||
```
|
||||
|
||||
AIが自動的に定義したすべてのデザイン仕様を適用します。
|
||||
|
||||
## 7. まとめ
|
||||
|
||||
AIに美しいインターフェースを生成させるには2つの方法があります：
|
||||
|
||||
| 方法 | 利点 | 欠点 | 適用シーン |
|
||||
| :--- | :--- | :--- |
|
||||
| **プロンプト説明** | 柔軟、毎回調整可能 | 繰り返し書く必要がある | 一度きりのページ、異なるスタイルの実験 |
|
||||
| **Skillsプラグイン** | 一度インストール、継続的に有効 | インストールと設定が必要 | 固定スタイル要件のあるプロジェクト |
|
||||
|
||||
**Vibe Codingワークフローの提案：**
|
||||
|
||||
1. **探索段階**：異なるスタイルプロンプトで実験し、好みの美学方向を見つける
|
||||
2. **スタイル確定後**：対応するSkillをインストール（UI/UX Pro Maxまたはfrontend-design）
|
||||
3. **ブランドプロジェクト**：独自のSkillを作成し、プロジェクト全体のデザイン言語を統一
|
||||
|
||||
### 練習
|
||||
|
||||
以下のいずれかのシーンを選び、このレッスンの方法でゼロから完成させてください：
|
||||
|
||||
1. スタイルプロンプトを使って、以前作ったプロジェクトのインターフェースを再設計（好きなスタイルを1つ選ぶ）
|
||||
2. UI/UX Pro Maxをインストールし、そのスタイルの1つで新しいページを生成
|
||||
3. 独自のデザインシステムSkillを作成し、ブランドカラーとフォントを定義
|
||||
|
||||
---
|
||||
|
||||
## 付録：デザインスタイル早見表
|
||||
|
||||
| スタイル | キーワード | 適用シーン | 例のプロダクト |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **ミニマリズム** | 余白、モノクロ、シンプル | 高級プロダクト、個人ポートフォリオ | Apple公式サイト |
|
||||
| **グラスモーフィズム** | すりガラス、グラデーション、ブラー | テックプロダクト、SaaSランディング | macOS Big Sur |
|
||||
| **新ブルータリズム** | 太いボーダー、ハードシャドウ、純色 | トレンドブランド、アート系サイト | Brassius |
|
||||
| **Bento Grid** | グリッド、コラージュ、カード | 情報表示、ダッシュボード | Apple プロモーションページ |
|
||||
| **レトロフューチャー** | ネオン、グラデーション、シンセウェーブ | ゲーム系、音楽系 | STRANGER THINGS |
|
||||
| **手描きスタイル** | 不規則、丸み、イラスト | 教育系、子ども向けプロダクト | Duolingo |
|
||||
| **マガジン風** | 大きなフォント、非対称、余白 | コンテンツ型サイト、ブログ | Medium |
|
||||
| **ダークラグジュアリー** | ダーク、ゴールド、精緻 | 高級プロダクト、ラグジュアリーブランド | 各種ハイエンドブランド |
|
||||
|
||||
## 付録：Skillsインストール早見表
|
||||
|
||||
```bash
|
||||
# UI/UX Pro Max
|
||||
npm install -g uipro-cli
|
||||
uipro init --ai claude
|
||||
|
||||
# Anthropic frontend-design
|
||||
npx skills add anthropics/skills/frontend-design
|
||||
|
||||
# Anthropic brand-guidelines
|
||||
npx skills add anthropics/skills/brand-guidelines
|
||||
|
||||
# Claude Codeにインストール済みのSkillsを確認
|
||||
/help
|
||||
```
|
||||
|
||||
## 付録：カラースキームおすすめ
|
||||
|
||||
| カラースキーム | メインカラー | アクセント | 背景 | スタイル |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **サンセット** | #F97316 | #FBBF24 | #FFF7ED | 温かい、活力 |
|
||||
| **オーシャン** | #0EA5E9 | #06B6D4 | #F0F9FF | 清潔、プロフェッショナル |
|
||||
| **フォレスト** | #10B981 | #34D399 | #ECFDF5 | 自然、健康 |
|
||||
| **ベリー** | #8B5CF6 | #EC4899 | #FAF5FF | ロマンチック、クリエイティブ |
|
||||
| **コーヒー** | #78350F | #D97706 | #FFFBEB | 温かい、レトロ |
|
||||
| **ストーン** | #6B7280 | #9CA3AF | #F9FAFB | プロフェッショナル、ニュートラル |
|
||||
|
||||
## 付録：デザインスタイルプロンプト早見表 {#style-prompts}
|
||||
|
||||
フロントエンドページをより美しくするためのプロンプト：
|
||||
|
||||
### スタイルカテゴリ
|
||||
|
||||
| スタイル | キーワード（英語） | 核心的な視覚特徴 | プロンプト例 |
|
||||
|:---|:---|:---|:---|
|
||||
| **ポップアート** | Pop Art | 大胆な色の衝突、黒い輪郭線、ドットテクスチャ | Pop art style website, bold colors and comic dots, vibrant |
|
||||
| **ミニマリズム** | Minimalism | 豊富な余白、極少の色と線、装飾なし | Minimalist web design, ample white space, geometric, serene |
|
||||
| **抽象表現主義** | Abstract Expressionism | 感情的な筆致、色の飛び散り | Abstract expressionism background, dynamic paint splashes, emotional |
|
||||
| **レトロスタイル** | Retro/Vintage | オールドスタイルのフォント、アンティークテクスチャ、レトロカラー | Retro 80s website design, neon grid and synthwave color palette |
|
||||
| **サイバーパンク** | Cyberpunk | 高コントラストのネオン、グリッチアート効果、ダーク背景 | Cyberpunk UI, neon lights on dark background, glitch effects |
|
||||
| **ニューモーフィズム** | Neumorphism | 柔らかなシャドウとハイライト、わずかな隆起/陥没質感 | Neumorphism design style, soft shadows, clean and modern |
|
||||
| **ジェネレーティブアート** | Generative Art | アルゴリズム生成の流動的な視覚パターン | Generative art background, flowing algorithmic patterns, digital |
|
||||
| **アシッドデザイン** | Acid Graphics | メタリック質感、ガラス態、ギザギザフォント | Acid graphics web layout, glass morphism, chaotic typography |
|
||||
| **イマーシブ3D** | Immersive 3D | インタラクティブ3Dシーン、強い空間感 | Immersive 3D website, interactive product model in space |
|
||||
@@ -0,0 +1,949 @@
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['ja-jp/stage-2/frontend/lovart-assets'] ?? []
|
||||
</script>
|
||||
|
||||
# NanoBananaから始めよう：自分だけの素材生成Agentを構築
|
||||
|
||||
## 第1章：1分で最初の画像素材を生成
|
||||
|
||||
デザイン、スタイル、プロンプトについて議論する前に、まずは最短手順で最初の1枚を生成してみましょう。
|
||||
|
||||
### 1.1 NanoBananaを知ろう
|
||||
|
||||
デザインスタイルやプロンプトエンジニアリングについて話す前に、まず最初により重要なことを確認しましょう：**あなたが本当に画像を生成できるかどうか。**
|
||||
|
||||
現在、主要な大規模モデルはすでに画像生成・編集能力を備えており、このようなモデルは一般的に**生成モデル**と呼ばれています。
|
||||
|
||||
本チュートリアルでは、プロセスをできるだけシンプルにするため、安定した画像生成・編集能力を備えたモデルを例として選びました——NanoBananaです。これはGoogleが提供する画像生成モデルで、正式名称は**Gemini 3.1 Flash Image Preview**で、自然言語による直接画像生成をサポートし、既存画像のベースでの修正もサポートしています。
|
||||
|
||||
|
||||
|
||||
能力面では、あなたが聞いたことのある他のモデル（GPT-4o、Claude、Qwen、Midjourneyなど）と本質的な違いはありません：**説明を入力し、モデルが結果を生成する。**
|
||||
|
||||
|
||||
|
||||
これは「絵筆」と考えることができます。この章では1つのことだけを気にします：
|
||||
👉 **この絵筆があなたの手で最初の一筆を描けるかどうか。**
|
||||
|
||||
実際の使用では、NanoBananaは**Google AI Studio**などの公式プラットフォームから直接使用することも、**API**として開発フローに統合することもできます。本チュートリアルではAPI呼び出し方式を採用しています。現在はNanoBanana 2モデルもリリースされており、最新の大規模モデルで試すこともできます。
|
||||
|
||||
### 1.2 「Hello World」レベルの生成
|
||||
|
||||
始める前に、以下の3つのステップを完了するだけです：
|
||||
|
||||
1. Traeで新しいフォルダを作成
|
||||
|
||||
|
||||
|
||||
2. 新しいPythonファイルを作成
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. 以下のコードをそのまま貼り付ける
|
||||
|
||||
Traeが必要な環境構築と依存関係のインストールを自動的に完了するため、追加の設定は不要です。
|
||||
|
||||
コード内でNanoBananaのAPI Keyを使用します。ここでは申請手順は詳しく説明しません——対応するパラメータを取得して入力できれば十分です。**この段階では、各行のコードを理解することを目指す必要はなく、正常に実行できればOKです。**
|
||||
|
||||
```Python
|
||||
# /// script
|
||||
# dependencies = [
|
||||
# "gradio>=4.0.0",
|
||||
# "pillow>=10.0.0",
|
||||
# "requests>=2.31.0",
|
||||
# ]
|
||||
# ///
|
||||
|
||||
import gradio as gr
|
||||
import requests
|
||||
import base64
|
||||
from PIL import Image
|
||||
import io
|
||||
import os
|
||||
import time
|
||||
import re
|
||||
from typing import Optional, Dict, Any, List
|
||||
|
||||
# API情報の設定
|
||||
NANOBANANA_API_URL: str = "YOUR API URL"
|
||||
NANOBANANA_API_KEY: str = "YOUR API KEY"
|
||||
OUTPUT_DIR: str = "outputs"
|
||||
|
||||
# 出力ディレクトリの存在を確認
|
||||
os.makedirs(OUTPUT_DIR, exist_ok=True)
|
||||
|
||||
def image_to_base64_data_uri(image: Image.Image) -> str:
|
||||
"""
|
||||
PIL画像をOpenAI API互換のdata URI形式に変換する。
|
||||
"""
|
||||
buffer = io.BytesIO()
|
||||
# 互換性を保証するためPNGに統一
|
||||
image.save(buffer, format="PNG")
|
||||
encoded = base64.b64encode(buffer.getvalue()).decode('utf-8')
|
||||
return f"data:image/png;base64,{encoded}"
|
||||
|
||||
def base64_to_image(base64_str: str) -> Optional[Image.Image]:
|
||||
"""
|
||||
純粋なbase64文字列をPIL Imageに変換する。
|
||||
"""
|
||||
try:
|
||||
image_bytes = base64.b64decode(base64_str)
|
||||
return Image.open(io.BytesIO(image_bytes))
|
||||
except Exception as e:
|
||||
print(f"Base64 デコード失敗: {e}")
|
||||
return None
|
||||
|
||||
def extract_base64_from_response(content: Any) -> Optional[str]:
|
||||
"""
|
||||
コア解析ロジック：API返却のcontentから画像のBase64データを抽出する。
|
||||
Markdown形式と構造化リスト形式の両方に対応。
|
||||
"""
|
||||
if not content:
|
||||
return None
|
||||
|
||||
base64_data = None
|
||||
|
||||
# 1. 構造化抽出を試行 (List)
|
||||
# 対応返却形式: [{"type": "image_url", "image_url": {"url": "data:..."}}]
|
||||
if isinstance(content, list):
|
||||
for part in reversed(content): # 逆順検索、通常最新の画像は最後にある
|
||||
if isinstance(part, dict):
|
||||
# image_url または output_image フィールドを確認
|
||||
img_field = part.get("image_url") or part.get("image") or part.get("output_image")
|
||||
if isinstance(img_field, dict):
|
||||
url = img_field.get("url", "")
|
||||
if url.startswith("data:image/") and "," in url:
|
||||
return url.split(",", 1)[1].strip()
|
||||
|
||||
# リスト中に構造化画像がない場合、リスト内のテキストを結合してMarkdownを検索
|
||||
text_parts = [
|
||||
str(p.get("text", ""))
|
||||
for p in content
|
||||
if isinstance(p, dict) and p.get("type") in ["text", "input_text"]
|
||||
]
|
||||
content_str = "".join(text_parts)
|
||||
else:
|
||||
content_str = str(content)
|
||||
|
||||
# 2. Markdown正規表現抽出を試行 (String)
|
||||
# 対応返却形式: "Here is your image: "
|
||||
pattern = re.compile(r"!\[.*?\]\((data:image/[^;]+;base64,[^)]+)\)", re.IGNORECASE)
|
||||
match = pattern.search(content_str)
|
||||
|
||||
if match:
|
||||
data_url = match.group(1)
|
||||
if "," in data_url:
|
||||
return data_url.split(",", 1)[1].strip()
|
||||
|
||||
return None
|
||||
|
||||
def synthesize(prompt: str, input_image: Optional[Image.Image]) -> Optional[Image.Image]:
|
||||
"""
|
||||
Nanobanana APIを呼び出して生成する。
|
||||
"""
|
||||
if not prompt or not prompt.strip():
|
||||
gr.Warning("プロンプトを入力してください")
|
||||
return None
|
||||
|
||||
print(f">>> タスク開始: {prompt[:50]}...")
|
||||
|
||||
headers = {
|
||||
"Content-Type": "application/json",
|
||||
"Authorization": f"Bearer {NANOBANANA_API_KEY}"
|
||||
}
|
||||
|
||||
# OpenAI Vision / Chat標準に準拠したpayloadを構築
|
||||
messages = []
|
||||
|
||||
if input_image is not None:
|
||||
# 画像から画像/マルチモーダル入力モード
|
||||
print(">>> 入力画像を検出、マルチモーダルモードを使用")
|
||||
img_base64 = image_to_base64_data_uri(input_image)
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": prompt},
|
||||
{"type": "image_url", "image_url": {"url": img_base64}}
|
||||
]
|
||||
})
|
||||
else:
|
||||
# テキストから画像生成モード
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": prompt
|
||||
})
|
||||
|
||||
payload = {
|
||||
"messages": messages,
|
||||
# 検証済みの利用可能なモデルを使用
|
||||
"model": "gemini-2.5-flash-image",
|
||||
# オプションパラメータ、APIのサポート状況に依存
|
||||
"stream": False
|
||||
}
|
||||
|
||||
try:
|
||||
# タイムアウトを延長、画像生成は通常遅い
|
||||
response = requests.post(NANOBANANA_API_URL, headers=headers, json=payload, timeout=120)
|
||||
|
||||
# HTTPステータスを確認
|
||||
if response.status_code != 200:
|
||||
error_msg = f"APIリクエスト失敗: {response.status_code} - {response.text}"
|
||||
print(error_msg)
|
||||
gr.Error(error_msg)
|
||||
return None
|
||||
|
||||
result = response.json()
|
||||
# Debug: 返却結果の前半部分を出力し、デバッグに便利
|
||||
print(f"API生レスポンス (抜粋): {str(result)[:200]}...")
|
||||
|
||||
# Contentを抽出
|
||||
content = None
|
||||
if "choices" in result and len(result["choices"]) > 0:
|
||||
content = result["choices"][0].get("message", {}).get("content")
|
||||
|
||||
if not content:
|
||||
gr.Warning("API返却結果にcontentフィールドがありません")
|
||||
return None
|
||||
|
||||
# 検証済みのロジックでBase64を抽出
|
||||
base64_str = extract_base64_from_response(content)
|
||||
|
||||
if base64_str:
|
||||
output_image = base64_to_image(base64_str)
|
||||
if output_image:
|
||||
return output_image
|
||||
|
||||
# 画像が抽出されなかった場合、モデルが拒否したかテキストのみ返却した可能性
|
||||
text_content = str(content) if not isinstance(content, list) else " ".join([str(x) for x in content])
|
||||
gr.Info(f"画像が生成されず、モデルがテキストを返却: {text_content[:100]}...")
|
||||
return None
|
||||
|
||||
except requests.exceptions.Timeout:
|
||||
gr.Error("リクエストがタイムアウトしました。後でもう一度お試しください")
|
||||
return None
|
||||
except Exception as e:
|
||||
import traceback
|
||||
traceback.print_exc()
|
||||
gr.Error(f"不明なエラーが発生しました: {str(e)}")
|
||||
return None
|
||||
|
||||
# Gradioインターフェース設定
|
||||
with gr.Blocks(title="Nanobanana Image Generator") as app:
|
||||
gr.Markdown("# 🍌 Nanobanana Text/Image to Image")
|
||||
gr.Markdown("Gemini-2.5-Flash-Imageモデルベース、テキストから画像・画像から画像に対応。")
|
||||
|
||||
with gr.Row():
|
||||
with gr.Column():
|
||||
prompt_input = gr.Textbox(
|
||||
label="プロンプト (Prompt)",
|
||||
placeholder="例: A cyberpunk cat holding a neon sign...",
|
||||
lines=3
|
||||
)
|
||||
image_input = gr.Image(
|
||||
label="参考画像 (任意、画像から画像生成に使用)",
|
||||
type="pil",
|
||||
height=300
|
||||
)
|
||||
submit_btn = gr.Button("生成開始", variant="primary")
|
||||
|
||||
with gr.Column():
|
||||
image_output = gr.Image(label="生成結果", format="png")
|
||||
|
||||
submit_btn.click(
|
||||
fn=synthesize,
|
||||
inputs=[prompt_input, image_input],
|
||||
outputs=image_output
|
||||
)
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.launch(share=True)
|
||||
```
|
||||
|
||||
Traeが実行成功を示したら、提供されたローカルリンク（通常は http://127.0.0.1:7860）をクリックします。
|
||||
|
||||
|
||||
|
||||
すべて正常であれば、すでに動作するAI描画インターフェースが表示されます。
|
||||
|
||||
このインターフェースはシンプルに見えますが、商用レベルの描画ツールにおける最も核心的な2つの機能を備えています。すなわち、テキストから画像と画像から画像です。
|
||||
|
||||
* **左側：** **指示エリア (** **Input** Zone) —— ここで指示を出します。
|
||||
* **Prompt (プロンプトボックス)：** クリエイティブな説明を入力（英語での使用を推奨）。
|
||||
* **Input** Image (参考画像ボックス)：
|
||||
* **テキストから画像モード：** ここを**空のまま**にします。
|
||||
* **画像から画像モード：** ローカル画像をここにドラッグすると、AIがそれをベースに創作します。
|
||||
* **Submit ボタン：** クリックして指示を送信し、生成を開始。
|
||||
* **右側：表示エリア (** **Output** Zone) —— 奇跡を目撃する場所、生成結果がここに表示されます。
|
||||
|
||||
|
||||
|
||||
それでは、最初の画像を生成してみましょう！
|
||||
|
||||
この例で使用するpromptは以下の通りです：
|
||||
|
||||
> **A red apple**
|
||||
|
||||
これは意図的にシンプル化された例で、スタイルやパラメータの説明は含まれていません。
|
||||
|
||||
#### 実際のフロー
|
||||
|
||||
コードを実行した後、フローは3つのステップに要約できます：
|
||||
|
||||
1. テキスト説明をモデルに送信
|
||||
2. モデルが対応する画像を生成
|
||||
3. 画像がローカルファイルとして保存
|
||||
|
||||
数秒後、ローカルで生成結果が表示されます。モデルの生成にはランダム性があるため、同じpromptでも異なる生成結果になります。複数回生成して、お気に入りの画像を選んでください。
|
||||
|
||||
|
||||
|
||||
プロンプトを充実させ、より多くの説明と制約を与えることもできます。例えば以下のプロンプトを使用すると、より特徴的な画像が得られます。
|
||||
|
||||
```Plain
|
||||
"A hyper-realistic close-up of a fresh red apple with water droplets on its skin, sitting on a dark rustic wooden table. Cinematic dramatic lighting, rim light, shallow depth of field, bokeh background, 8k resolution, macro photography."
|
||||
（水滴のある新鮮な赤いリンゴの超写真的クローズアップ、暗く粗削りな木製テーブルの上。シネマティックなドラマチックライティング、リムライト、浅い被写界深度、ボケ背景、8k解像度、マクロ撮影。）
|
||||
```
|
||||
|
||||
|
||||
|
||||
Output Imageエリアでダウンロードをクリックすると、画像をローカルに保存できます。
|
||||
|
||||
|
||||
|
||||
### 1.3 画像生成モデルの一般的な素材生成シーン
|
||||
|
||||
実際の業務では、大規模モデルによる画像生成は、単一の芸術作品を創作するよりも**効率的なデザイン素材の生産**に使われることが多いです。
|
||||
|
||||
デザイン系マーケティングアカウントの高評価ケースを観察すると、その多くは2つのシーンに集中していることがわかります：
|
||||
|
||||
* **テキストから画像（0から1へ）**
|
||||
* **参考画像からの画像生成（1からNへ）**
|
||||
|
||||
#### 一、テキストから画像：デザイン素材を素早く入手
|
||||
|
||||
このカテゴリのシーンは効率を重視します。デザインにおける空白（空状態、アバター、挿絵など）を埋める必要がある場合、AIは本質的に**リアルタイム生成の画像ライブラリ**として機能します。
|
||||
|
||||
1. ##### UIデザイン素材の生成
|
||||
|
||||
* トレンド：Dribbbleでよく見かけるグラスモーフィズム、クレイスタイルの3Dアイコン
|
||||
* よくある表現：透明感のある素材、縁の発光、キャンディカラーの機能や天気アイコン
|
||||
|
||||
**サンプル Prompt：**
|
||||
|
||||
> A set of 3D weather icons (sun, cloud, rain), glassmorphism style, frosted glass texture, soft pastel gradient colors, soft studio lighting, isometric view, transparent background, 4k.
|
||||
|
||||
（3D天気アイコンセット、グラスモーフィズムスタイル、すりガラスのテクスチャ、柔らかなパステルグラデーションカラー、スタジオライティング、アイソメトリックビュー）
|
||||
|
||||
|
||||
|
||||
2. ##### ロゴの生成
|
||||
|
||||
* トレンド：ミニマルなライン、幾何学的な組み合わせのテクノロジー感のあるロゴ
|
||||
* よくある表現：白黒配色、ネガティブスペースデザイン、ブランド感が明確
|
||||
|
||||
**サンプル Prompt：**
|
||||
|
||||
> Minimalist vector logo design for a tech brand "Coffee Code", combining a coffee cup with coding brackets < >, flat design, solid black lines, white background, Paul Rand style, svg.
|
||||
|
||||
（ミニマルなベクターロゴ、コーヒーカップとコーディング括弧の組み合わせ、フラットデザイン、純黒ライン）
|
||||
|
||||
|
||||
|
||||
3. ##### 公式サイトのユーザー画像生成
|
||||
|
||||
* トレンド：SaaS公式サイトでよく使われる3Dバーチャルアバター、実写の著作権問題を回避
|
||||
* よくある表現：フレンドリーな表情、カートゥーン比率、PixarやMemojiスタイル寄り
|
||||
|
||||
**サンプル Prompt：**
|
||||
|
||||
> Close-up portrait of a friendly young tech professional, smiling, Memoji 3D style, clay render, bright colors, soft lighting, solid plain background, Pixar character design.
|
||||
|
||||
（フレンドリーな若手テックプロフェッショナル、3D Memojiスタイル、クレイレンダリング）
|
||||
|
||||
|
||||
|
||||
4. ##### 記事の挿絵生成
|
||||
|
||||
* トレンド：テック企業ブログでよく見かける抽象的なフラットイラスト
|
||||
* よくある表現：紫と青の配色、誇張された人物比率、浮遊するUI要素
|
||||
|
||||
**サンプル Prompt：**
|
||||
|
||||
> Editorial flat illustration representing remote work, a person sitting on a giant globe using a laptop, corporate memphis art style, vibrant colors (purple and teal), vector texture.
|
||||
|
||||
（リモートワークをテーマにしたフラットイラスト、コーポレートメンフィススタイル）
|
||||
|
||||
|
||||
|
||||
#### 二、参考画像からの画像生成：視覚的一貫性の維持
|
||||
|
||||
このカテゴリのシーンは**拡張性**に焦点を当てています。満足のいくメインビジュアルが1つあり、それとスタイルが一致する一連の素材を生成する必要がある場合に使用します。
|
||||
|
||||
5. ##### メインビジュアルに類似した一連のボタンやインタラクション素材画像
|
||||
|
||||
ゲーム開発では、UIの一貫性が非常に重要です。メイン画面の「PLAY」ボタンがすでにあると仮定し、スタイルが統一された一連の機能ボタン（一時停止、設定、ホームなど）を追加で生成する必要があるとします。手描きだけで各ボタンの光沢、パースペクティブ、色味の完全な一致性を保証するのは困難です。
|
||||
|
||||
**基本的な操作フロー：**
|
||||
|
||||
1. 既存の青色「PLAY」ボタン画像を保存
|
||||
|
||||
|
||||
|
||||
2. インターフェースの**Input** **Image**エリアにドラッグし、以降の生成の参考マスターとする
|
||||
3. promptのスタイル説明は変更せず、メインコンテンツのみを変更
|
||||
|
||||
このフローでは、メインの説明を置き換えるだけで、機能は異なるがスタイルが一致したボタンを得ることができます。
|
||||
|
||||
**サンプル Prompt：**
|
||||
|
||||
**バリアント A：一時停止ボタン（アイコンタイプ）**
|
||||
|
||||
> A capsule-shaped game UI button with a white pause icon (two vertical bars) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
（カプセル型ゲームUIボタン、白色の一時停止アイコン、ブルーのゼリー質感）
|
||||
|
||||
|
||||
|
||||
**バリアント B：設定ボタン（複雑なアイコン）**
|
||||
|
||||
> A capsule-shaped game UI button with a white gear icon (settings symbol) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
（カプセル型ゲームUIボタン、白色の歯車アイコン、ブルーのゼリー質感）
|
||||
|
||||
|
||||
|
||||
**バリアント C：リプレイボタン（形状変更）**
|
||||
|
||||
ボタンの外形を調整する必要がある場合、promptで直接形状を説明すると、モデルは素材の特徴を維持しながら構造の変更を試みます。
|
||||
|
||||
> A round game UI button with a white circular arrow icon (replay symbol) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
（円形ゲームUIボタン、循環矢印アイコン、ブルーのゼリー質感）
|
||||
|
||||
|
||||
|
||||
この一連の操作により、ボタンの機能やアイコンを置き換えるだけでなく、ボタンの形状を変えることさえできますが、すべての生成結果は素材、カラーリング、光と影において高い一貫性を保ちます。これこそが、大規模モデルがデザイン素材の派生シーンにおいて持つ核心的な価値です。
|
||||
|
||||
## 第2章：より従順な画像生成アシスタント —— Lovartを例に
|
||||
|
||||
第1部では、コードを通じて直接NanoBananaを呼び出し、「入力すれば生成」という基本フローを体験しました。この方法はニーズがシンプルな場合には問題ありません。しかし、生成タスクにさらに多くの制約が含まれるようになると、例えば：
|
||||
|
||||
* 複数のスタイルが一致した画像が必要
|
||||
* 既存の結果に基づいて繰り返し調整が必要
|
||||
* ユーザー入力に基づいて生成方向を動的に変更する必要がある
|
||||
|
||||
単一呼び出しの方式では次第に対応が困難になります。
|
||||
|
||||
ここで、**AI Agent（エージェント）**の導入が必要になります。本節では**Lovart**を例に、画像生成モデルに「思考層」が備わった後、全体的なワークフローがどのように変化するかを示します。注意！ここは広告ではなく、皆さんにAI Agentの利便性を素早く理解してもらうためのものです～
|
||||
|
||||
### 2.0 Lovart入門：あなたのAIデザインエージェント
|
||||
|
||||
LovartはAgentベースのデザインツールWebです。通常の画像生成ツールと比較して、生成の前に「思考と計画」の層が1つ追加されています。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Lovartに入った後、主に以下の制御項目を理解する必要があります：
|
||||
|
||||
#### モデル選択
|
||||
|
||||
入力ボックスの下にある立方体アイコンをクリックすると、現在利用可能な生成モデル（GPT Image、Fluxなど）を確認できます。
|
||||
|
||||
前述の例との一貫性を保つため、本節では引き続きNanoBananaを基盤生成モデルとして使用します。
|
||||
|
||||
|
||||
|
||||
#### 思考モード
|
||||
|
||||
これがLovartの核心的なスイッチです：
|
||||
|
||||
* **Fast Mode（⚡）**：ネイティブAPIに近く、レスポンスが速く、単一で明確な指示の生成に適している
|
||||
* **Thinking Mode（💡）**：Agentモード、AIがまずニーズを分解し、promptを書き直してから生成を実行
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### インターネット接続機能
|
||||
|
||||
地球儀アイコンをオンにすると、Agentは生成過程でネットワーク情報（デザイントレンド、カラーパレットなど）を検索し、補助入力として利用できます。
|
||||
|
||||
### 2.1 なぜネイティブAPIだけでは不十分なのか？
|
||||
|
||||
Pythonで品質の良い画像を生成できるようになっても、ネイティブAPIは複雑なタスクでは依然として制限があります。重要な理由は、ネイティブAPIが本質的に命令型であることです。具体的なオブジェクトの生成を要求された場合、直接実行できますが、入力が「完全なゲーム素材セットの企画」になると、目標を複数の実行可能なステップに自発的に分解することはありません。
|
||||
|
||||
Lovartの核心的な違いはAgentメカニズムにあります。ユーザー入力と画像生成モデルの間に、理解と計画のためのロジック層を追加します：まずユーザーの意図を識別し、次にタスクを分解し、promptを書き直し、最後に生成を実行します。
|
||||
|
||||
### 2.2 実践デモ：5分でIPスタンプセットを作る
|
||||
|
||||
**「プログラマー鸭のIPスタンプセットを作る」**を例に、Agentがプロセス全体にどのように関与するかを見てみましょう。
|
||||
|
||||
#### ステップ1：企画（Agentの思考能力）
|
||||
|
||||
**ネイティブAPIの問題点：**
|
||||
自分でキャラクター設定、感情状態を考え、各画像ごとに個別にpromptを書く必要があります。
|
||||
|
||||
**Lovartのアプローチ：**
|
||||
|
||||
1. 💡 **Thinking Mode**を点灯
|
||||
2. 1つの指示を入力：
|
||||
|
||||
> プログラマー鸭のIPスタンプセットをデザインして、スタイルはフラットで可愛く
|
||||
|
||||
AIはすぐに絵を描くのではなく、まずネットで関連するプログラマー鸭のデザイン画像を検索します。分解されたプランを出力し、Debug、Coffee Break、Panicなどのシーンを自動生成し、対応する複数の視覚説明を生成します。
|
||||
|
||||
|
||||
|
||||
このステップで、AIは「実行者」から「企画者」へと変わります。AIがニーズの分析を完了した後、Lovartのキャンバスエリアで様々なスタイルとコンテンツのプログラマー鸭画像を見ることができます。お気に入りのスタイルを選び始めることができます。
|
||||
|
||||
|
||||
|
||||
#### ステップ2：一貫性（参考に基づく視覚的アンカー）
|
||||
|
||||
Lovartの画像は結果であるだけでなく、以降の生成にも参加します。
|
||||
|
||||
##### 完全な参考画像
|
||||
|
||||
* スケッチから最も満足のいく「標準的な鸭」を1枚選び、キャンバスエリアで対応する画像をクリック
|
||||
* その画像は自動的に対話エリアにReferenceとして表示されます
|
||||
|
||||
|
||||
|
||||
* 新しい動作（例：嬉しい）を入力して生成
|
||||
|
||||
生成結果はマスター画像のカラーリング、比率、ディテールを継承します。
|
||||
|
||||
|
||||
|
||||
##### 部分参考 / 複数画像の統合
|
||||
|
||||
画像全体を参考にするだけでなく、Lovartは以下もサポートしています：
|
||||
|
||||
* **画像の部分的な領域のみを選択**（例：帽子や表情のみを参考にする）
|
||||
|
||||
キャンバスエリア左側のタブバーをクリックし、「Mark」キーを選択し、ターゲット画像の部分領域をマークすると、この部分の内容が自動的に対話ボックスに同期されます。例えば、ここでは背景の色を変更するよう選択できます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
新しく生成された画像が背景の色のみを変更しており、これは入力した要求とも一致していることがわかります。
|
||||
|
||||
* **複数の画像からそれぞれサブ要素を引用**し、組み合わせて新しい結果を生成
|
||||
|
||||
例えば：画像Aのキャラクター本体を保持しつつ、帽子だけを画像Bのスタイルに置き換えることができ、Agentはバックグラウンドでこれらの視覚的制約を自動的に統合します。
|
||||
|
||||
プログラマー鸭を例にすると、最初の画像の鸭のキャラクターを保持し、それを2枚目の画像のメイン要素として置き換えることができます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
最終的な効果も非常に顕著です。他の組み合わせも試してみてください！
|
||||
|
||||
#### ステップ3：仕上げ（Agentのツール呼び出し）
|
||||
|
||||
生成が完了したら、直接実行できます：拡大、背景除去、消去などの操作
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
これらは単純なフィルターではなく、Agentが異なるツールを自動的に呼び出して完成させた結果です。
|
||||
|
||||
基調スタイルが確定した後、一連のスタンプ画像を非常に速く生成できます。
|
||||
|
||||
|
||||
|
||||
最終的に得られるのは、直接納品可能な本番レベルの素材であり、単なる展示画像ではありません。
|
||||
|
||||
### 2.3 利用料金について
|
||||
|
||||
Lovartはサブスクリプション制の課金モデルを採用しており、異なるプランは異なる使用量と機能権限に対応しています。詳細は公式サイトの表示をご確認ください。
|
||||
|
||||
本チュートリアルはいかなるプランの推奨や比較も行いません。実際の使用で必要がある場合は、個人の状況に応じて有料アップグレードを選択できます。
|
||||
現在は**Alipay**などでの支払いに対応しています。
|
||||
|
||||
|
||||
|
||||
#### まとめ
|
||||
|
||||
Lovartは基盤モデルを代替するものではなく、Agentメカニズムを通じて、画像生成を「単一実行」から「連続ワークフロー」へとアップグレードします。
|
||||
|
||||
タスクが企画、一貫性、納品に関わり始めると、この種のツールの利点が非常に明確になります。
|
||||
|
||||
## 第3章：自分でスマート描画アシスタントを作ろう
|
||||
|
||||
Lovartを直接使用するだけでなく、自分で簡易版の描画アシスタントを実装することもできます。
|
||||
|
||||
本章では「記事の自動挿絵」を例に、実際の問題から出発し、段階的に思考能力を持つAgentを構築します。
|
||||
|
||||
### 3.1 課題の導入：なぜ記事をそのまま画像生成モデルに送ってもうまくいかないのか？
|
||||
|
||||
長い記事をNanoBananaに直接入力して挿絵を求めても、通常は理想的な結果が得られません。理由はモデルが「描くのが下手」だからではなく、**長いテキストの理解が得意ではない**からです。
|
||||
|
||||
画像生成モデルは短く明確な視覚的説明を処理するのに適しており、入力が構造、要点、文脈関係を含む記事になると、モデルはどの内容が画像で表現すべき部分なのかを判断できません。これにより、生成結果がテーマから逸脱したり、断片的なディテールしか捉えられず、全体的な要約力が欠如することになります。
|
||||
|
||||
本質的に、画像モデルには「実行」する能力はあっても、テキストを分析し取捨選択するプロセスが欠けています。
|
||||
|
||||
|
||||
|
||||
### 3.2 解決アプローチ：Agentで「理解」と「実行」を分ける
|
||||
|
||||
この問題を解決するための鍵は、より複雑なプロンプトではなく、**画像生成の前にまず考えること**です。したがって、生成フローに独立した「思考層」を導入し、それを使って最もシンプルな利用可能なAgentを構築します。
|
||||
|
||||
このAgentの核心的な目標は1つだけです：**最終的に生成される画像が、ユーザーの真の表現意図にできるだけ近づくこと。**
|
||||
|
||||
全体のフローは次のように要約できます：**長いテキスト入力 → 言語モデルによる理解と判断 → 適切な視覚プロンプトの生成 → 画像モデルによる生成の実行 → 画像の出力**
|
||||
|
||||
|
||||
|
||||
では、私たちが構築するAgentはどうやってユーザーの意図を理解するのでしょうか？
|
||||
|
||||
ここでは簡略化された**「思考層」**を作ることを選択し、3つの異なる意図を設定しました：無効な入力、直接画像生成、理解が必要な長いテキスト。
|
||||
|
||||
このAgentでは、各役割の分担は4つのポイントに要約できます：
|
||||
|
||||
1. **言語モデルが意思決定の核心として**
|
||||
記事の内容を理解し、ユーザー入力の意図を判断し、タスクを適切な生成パスに配信し、「次にどうすべきか」および画像生成プロンプトの生成方法を決定する役割を担います。
|
||||
2. **画像モデルが実行者として**
|
||||
画像モデルは理解と判断には参加せず、すでに整理された視覚的指示のみを受け取り、画像レンダリングの完成に集中します。
|
||||
3. **ユーザーが介入可能なガイドとして**
|
||||
テキストを直接入力するだけでなく、プロセス中に生成されたプロンプトを手動で調整したり、参考画像を追加して生成を補助し、最終結果をガイド・微調整することもできます。
|
||||
4. **GradioとバックエンドAPIが全体のサポート層として**
|
||||
インターフェース、モデル呼び出し、結果表示を連携し、Agent全体が完全なWebアプリケーションとして安定して動作できるようにします。
|
||||
|
||||
|
||||
|
||||
### 3.3 実践準備：APIの取得
|
||||
|
||||
とても面白そうですね！上記のフローを実行するために、必要なAPIは2種類だけです。
|
||||
|
||||
#### 手：NanoBanana API（画像生成）
|
||||
|
||||
第1章で既に設定済みのAPI KeyとAPI URLをそのまま使用し、追加の設定は不要です。
|
||||
|
||||
#### 脳：SiliconFlow API（テキスト思考）
|
||||
|
||||
「思考層」の役割を担う大規模言語モデルが必要です。本チュートリアルではSiliconFlowが提供するモデルサービスを使用します：[https://cloud.siliconflow.cn](https://cloud.siliconflow.cn/)
|
||||
|
||||
|
||||
|
||||
SiliconFlowはOpenAI API仕様と互換性のあるインターフェースを提供しており、標準的なネットワークリクエストでプロジェクトに非常に便利に統合できます。ここで選択したのは無料のQwen2.5-7B-Instructモデルで、呼び出しに必要な内容は以下のPromptにすべて記載されています。始める前に、公式サイトでアカウントを登録しAPI Keyを作成するだけです。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
このKeyは以降のモデル呼び出しに使用されます。
|
||||
|
||||
### 3.4 Agentの構築：
|
||||
|
||||
今回の実験では主にTraeを使用してコードを記述します。本チュートリアルで選択したのはGemini-3-Pro-Previewモデルです。全体的なアプローチは、新しいプロジェクトを作成した後、以下の完全なPromptを対話ボックスにコピーして入力し、段階的にAPI KEYを置き換えた後コードを実行し、テストを完了します。
|
||||
|
||||
|
||||
|
||||
#### ステップ1️⃣：Gradio Blocks基本フレームワークとインターフェースレイアウト
|
||||
|
||||
このステップでは、Agent全体の「外観」を構築し、フロントエンドのページデザインを実現することが主な目標です。以下のPromptをコピーしてTraeの対話ボックスで実装すると、ローカルのURL（通常は http://127.0.0.1:7860）が取得でき、インターフェースを確認し、実装効果を検証できます。
|
||||
|
||||
```Plain
|
||||
セクション 1：Gradio Blocks基本フレームワークとインターフェースレイアウト
|
||||
1、タスク目標
|
||||
· Gradio 4.0.0+のBlocksレイアウトに基づいて、「LLM+Nanobananaテキストから画像」プロジェクトの基本インターフェースを実装し、固定左右分割レイアウトを厳格に遵守し、すべてのUIコンポーネントを初期化し正しい初期状態を設定。
|
||||
|
||||
2、技術スタック要件
|
||||
· Gradio 4.0.0+のBlocksモードでの開発を使用、Interfaceモードの使用は禁止；
|
||||
· 依存関係：gradio>=4.0.0、pillow>=10.0.0（インポートのみ、画像処理ロジックは一時未実装）；
|
||||
· コードは完全に実行可能なPythonファイルで、すべての必要なインポート文を含む。
|
||||
|
||||
3、インターフェースレイアウトルール（核心制約、実践的詳細を統合）
|
||||
·全体レイアウト：
|
||||
ページタイトル：LLM駆動のテキストから画像全プロセスツール；
|
||||
固定左右分割：左側60%幅、右側40%幅、gr.Rowとgr.Columnで比率制御を実現。
|
||||
·左側60%（プロンプト生成プロセスエリア）コンポーネント一覧：
|
||||
input_text：gr.Textbox、ラベル「入力テキスト（チュートリアル段落 / 描画指示）」、lines=6、プレースホルダー「画像挿絵用のチュートリアルテキストまたは直接描画指示を入力...」；
|
||||
identify_intent_btn：gr.Button、value="意図を識別"、初期状態は通常クリック可能；
|
||||
intent_status：gr.Textbox、ラベル「意図タイプ / 処理ステータス」、lines=2、interactive=False、初期値「意図未識別」；
|
||||
system_prompt：gr.Textbox、ラベル「System Prompt（記事挿絵意図のみ編集可能）」、lines=4、interactive=False、プレースホルダー「LLMがプロンプトを生成する際の制約ルール...」；
|
||||
confirm_prompt_btn：gr.Button、value="画像生成プロンプトを確認"、interactive=False（誤操作防止のため初期無効）；
|
||||
generation_prompt：gr.Textbox、ラベル「画像生成プロンプト（編集可能）」、lines=3、interactive=True、初期値は空、プレースホルダー「生成された英語の画像生成プロンプトがここに表示されます、手動での修正に対応...」。
|
||||
·右側40%（Nanobanana画像生成機能エリア）コンポーネント一覧：
|
||||
ref_image：gr.Image、ラベル「参考画像（任意、画像から画像生成）」、type=filepath、height=300、アップロード許可；
|
||||
generate_btn：gr.Button、value="画像を生成"、interactive=False（初期無効、プロンプトがないとクリック不可）；
|
||||
result_image：gr.Image、ラベル="生成結果"、type=pil、height=300、初期は空、interactive=False。
|
||||
|
||||
4、インタラクションロジック要件
|
||||
·すべてのコンポーネントのinteractive初期状態は上記設定に厳格に従い、その後関数で動的に更新；
|
||||
·ボタンの無効状態は直感的に（グレーアウト）、ユーザーの誤操作を防止。
|
||||
|
||||
5、出力要件
|
||||
·完全なPythonコードを生成、インターフェースレイアウトとコンポーネントの初期化のみを実装、ビジネスロジックは含まない；
|
||||
·コードコメントは明確、コンポーネント名は実践版と一致（input_text/identify_intent_btnなど）；
|
||||
·コードは直接実行可能、インターフェース構造は説明と完全に一致。
|
||||
```
|
||||
|
||||
ブラウザでhttp://127.0.0.1:7860を開くと、Traeが要件に従って以下のWebページを生成していることが確認できます。要求とほぼ一致しており、次の生成ステップに進めます。
|
||||
|
||||
|
||||
|
||||
#### ステップ2️⃣：LLM意図認識モジュール（Siliconflow API）
|
||||
|
||||
日常的にVLMで画像を描く際、以下の3つの一般的な入力パターンがあります：
|
||||
|
||||
1. 無意味な内容、「こんにちは」「今日ご飯食べた？」など、対応する画像が描けない。
|
||||
2. 記事/長文、文字数が多く、例えば200字程度の構造化された記事で、まず文章の構造と内容を理解してから、この文章全体を要約できる画像の生成方法を考える必要がある。
|
||||
3. 直接的な描画指示、「お風呂に入っている犬を描いて」など、要求がすでに非常に具体的で、直接画像を生成できる。
|
||||
|
||||
前と同様に、以下のPromptをコピーしてTraeの対話ボックスで実装し、前のステップで取得したAPIを追加します。
|
||||
|
||||
```Plain
|
||||
セクション 2：LLM意図認識モジュール（Siliconflow API）
|
||||
1、タスク目標
|
||||
実装済みのGradioインターフェースを基に、「意図を識別」ボタンにクリックロジックを追加し、Siliconflow APIを呼び出して意図認識を完了し、コンポーネント状態と連動。
|
||||
|
||||
2、技術スタック要件
|
||||
Gradio 4.0.0+ Blocksに基づく；
|
||||
依存関係：requests>=2.31.0、openai；
|
||||
セクション1インターフェース + 本モジュールロジックを含む完全な実行可能Pythonファイルを出力。
|
||||
|
||||
3、核心ビジネスルール（絶対に逸脱不可）
|
||||
·意図分類ルール（3種類のみ、数字 + 説明を厳格に返却）
|
||||
1 = 無意味な内容：雑談、挨拶、無関係な会話のみで、描画や挿絵のニーズが全くない（例：「こんにちは」「今日食べた？」）；
|
||||
2 = 記事 / 長文の挿絵ニーズ：ユーザーが完全な記事、チュートリアル、段落、説明文を入力し、内容は叙述 / 説明 / 解説に偏り、この内容に挿絵を生成する意図が暗黙的に含まれる。ユーザーが「この文章に挿絵をつけて」と明示的に言う必要はない；
|
||||
3 = 直接的な描画指示：ユーザーが短く明確な描画コマンドを入力し、長文の背景がなく、直接特定の内容を描くよう要求（例：「Apple風の猫を描いて」）。
|
||||
·LLM呼び出し制約（実践版テンプレートを統合）
|
||||
インターフェースURL：https://api.siliconflow.cn/v1/chat/completions；
|
||||
モデル：Qwen/Qwen2.5-7B-Instruct；
|
||||
temperature=0.1；
|
||||
統一定義コード：
|
||||
python
|
||||
実行
|
||||
LLM_BASE_URL = "https://api.siliconflow.cn/v1"
|
||||
LLM_API_KEY = "" # ユーザーが各自入力
|
||||
LLM_MODEL = "Qwen/Qwen2.5-7B-Instruct"# 実践検証済み意図認識テンプレート（コードに固定）
|
||||
INTENT_PROMPT_TEMPLATE = """ユーザー入力テキストの意図を識別する必要があります。以下の3種類の結果のうち1つのみを返却（形式：数字 + 中国語の説明）：
|
||||
1 = 無意味な内容；2 = 記事 / 長文の挿絵ニーズ；3 = 直接的な描画指示。
|
||||
|
||||
ユーザー入力：{user_input}
|
||||
|
||||
認識結果：
|
||||
結果中の数字と説明のみを抽出して返却し、余分な内容は禁止。"""
|
||||
|
||||
4、コンポーネント連動ルール
|
||||
·結果が1：intent_statusに「1 = 無意味な内容：描画ニーズなし」と表示、system_promptは無効状態を維持、confirm_prompt_btnは無効；
|
||||
·結果が2：intent_statusに「2 = 記事 / 長文の挿絵ニーズ：入力内容に挿絵を生成」と表示、system_promptを有効化しデフォルトルールを充填、confirm_prompt_btnを有効化；
|
||||
·結果が3：intent_statusに「3 = 直接的な描画指示：指示に基づいて画像を生成」と表示、system_promptは無効状態でデフォルトルールを充填、confirm_prompt_btnを有効化。
|
||||
|
||||
5、例外処理
|
||||
API例外、解析例外はすべてフレンドリーなプロンプトを表示し、クラッシュせず、コンポーネントは初期状態に復帰。
|
||||
|
||||
6、出力要件
|
||||
LLM_API_KEYを置き換えるだけで使用可能な完全な実行可能コードを生成、ロジックは明確でコメントは完全、意図認識テンプレートは実践版を厳格に使用。
|
||||
```
|
||||
|
||||
以前のhttp://127.0.0.1:7860のURLをリフレッシュし、3つのケースを正しく認識できるかテストを開始します。
|
||||
|
||||
1. 無意味な内容、「こんにちは」「ありがとう」などを入力して試すと、正常に認識できることが確認できます。
|
||||
|
||||
|
||||
|
||||
2. 記事/長文、ここではDoubaoが生成した人工知能に関する文章を使用しました。自分の論文の段落を使ってテストすることもできます。
|
||||
|
||||
```Plain
|
||||
人工知能はかつてない深さと広がりで教育エコシステムを再構築しています。適応型学習アルゴリズムにより、AIシステムは各学生の認知マップを構築し、知識習得軌跡をリアルタイムで追跡し、教育内容の難易度と提示方法を動的に調整できます。従来の教室環境では、教師は異なる学習スタイルや能力レベルの学生のニーズに同時に対応することが困難ですが、ディープラーニングに基づく教育プラットフォームは、インタラクティブなシミュレーション実験における学生の行動パターンを分析し、量子力学や微積分などの複雑な概念理解における微妙な障害を特定し、的確な認知スキャフォールドを提供できます。
|
||||
|
||||
高度な自然言語処理エンジンによるバーチャルチューターは、「フランス革命が現代民主制度に与えた影響をどう評価するか」のようなオープンな質問を分解できるだけでなく、ソクラテス式対話を通じてクリティカルシンキングを促進します。学生が気候変動が極地生態系に与える影響に関する論文を執筆する際、AI執筆アシスタントはその論証の厳密さを分析し、データ引用のタイムリーな問題を指摘し、より正確な科学用語を提案できます。特別教育の分野では、コンピュータビジョン技術により、AIは自閉スペクトラムの児童の社会的インタラクションにおける非言語的手がかりを認識し、介入戦略を調整でき、感情コンピューティングアルゴリズムはオンライン学習時の挫折感を検出し、タイムリーに励ましのフィードバックを提供します。
|
||||
|
||||
しかし、このような技術統合は一連の倫理的ジレンマを引き起こしています。アルゴリズムの偏見が意図せず特定の文化的背景を持つ学生を周縁化する可能性があり、データ収集の透明性の問題は学術的プライバシーへの懸念を引き起こし、自動採点システムへの過度の依存は学生の思考プロセスに対する教師の深い理解を弱める可能性があります。さらに複雑なのは、AIが高度にリアルなバーチャル実験体験を生成し始めた時、教育における「実践的経験」の価値を再定義する必要があることです。未来の教育パラダイムは、人間の教師が創造性、共感力、道徳的判断力の育成に集中し、AIシステムが知識伝達、スキル訓練、個別化評価の機能を担う、協調進化する教育共生体へと進化する可能性があり、機械の計算優位性を発揮しつつ、人間教育の独自の温かさも保持できるでしょう。
|
||||
```
|
||||
|
||||
同様に認識成功～
|
||||
|
||||
|
||||
|
||||
3. 直接的な描画指示、ここでは「猫を描きたい」と入力し、同様に正確に認識されました。
|
||||
|
||||
|
||||
|
||||
ここまでで、第2のステップ——意図認識を無事に実装できました。
|
||||
|
||||
#### ステップ3️⃣：画像生成プロンプト生成モジュール（LLM二次呼び出し）
|
||||
|
||||
意図認識後、記事や長文に対しては、画像生成のプロンプトを生成する重要なステップがあります。これこそが本Agentのポイントです。
|
||||
|
||||
```SQL
|
||||
セクション 3：画像生成プロンプト生成モジュール（LLM二次呼び出し）
|
||||
1、タスク目標
|
||||
意図認識を基に、「画像生成プロンプトを確認」ボタンのロジックを実装し、LLMを呼び出してテキストを画像生成に適した英語の視覚プロンプトに最適化し、編集ボックスに充填し「画像を生成」ボタンと連動。
|
||||
|
||||
2、技術スタック要件
|
||||
セクション2と同様、完全コード = セクション1 + セクション2 + 本モジュールを出力；
|
||||
セクション2で定義したLLM_BASE_URL、LLM_API_KEY、LLM_MODELを共有、新しいキーは追加しない。
|
||||
|
||||
3、核心ビジネスルール（実践版Prompt組み立てロジックを統合）
|
||||
·プロンプト生成入力ルール（厳格に遵守必須）
|
||||
画像生成プロンプト生成はもはや単純な文字列連結ではなく、標準Chatメッセージリストを構築する。コード構造は以下：
|
||||
python
|
||||
実行
|
||||
messages=[# System役割：Web上でユーザーが最終確認/編集したsystem_promptの内容{"role": "system", "content": final_system_prompt},# User役割：処理対象データを保持し、タスク目標を明確化{"role": "user", "content": f"以下の内容に視覚プロンプトを生成：\n\n{user_input}"}]
|
||||
意図が2の場合：System内容はユーザーが編集したsystem_promptの最終版を取得；
|
||||
意図が3の場合：System内容は無効状態で充填されたデフォルトルールを取得
|
||||
user_inputはユーザーがinput_textボックスに最初に入力した元のテキスト。
|
||||
·実践検証済みSystem Promptプリセット（コードに固定）
|
||||
python
|
||||
実行
|
||||
SYSTEM_PROMPT_DEFAULT = """あなたはNanoBanana描画プロンプトを作成するアシスタントです。
|
||||
私の内容に基づいて処理する必要があります。この画像の役割は、この文章が何を言っているかを説明し、皆にこの文章の文脈構造全体の意味を理解させることです。
|
||||
PPTのような説明が含まれる場合があります（例：左上に核心的観点、右下にデータ）。
|
||||
デザインスタイル要件：シンプル、Apple Design Philosophy（Apple設計哲学）。
|
||||
制約：NanoBananaで使用可能な英語プロンプトのみを直接返却し、説明、プレフィックス、余計な内容は一切返却しないでください。"""
|
||||
·LLM呼び出し制約
|
||||
セクション2と同じLLM_BASE_URL、LLM_API_KEY、LLM_MODELを共有；
|
||||
temperature=0.7（プロンプトの創造性と適合性を保証）；
|
||||
max_tokens=200（出力長を制限し、プロンプト制約にマッチ）；
|
||||
上記標準Chatメッセージリスト構造を厳格に使用、文字列連結は禁止。
|
||||
·サンプル入出力（核心参考）
|
||||
入力例1（記事挿絵意図）：元のテキスト：「AIがいかに教育を変えるか：AI技術の発展に伴い、教師の役割は知識伝授者からガイドへと変わり、AIアシスタントが学生の個別化学習を支援し、教室での人機協働が常態化する。」最終System Prompt：SYSTEM_PROMPT_DEFAULT（未修正）出力予想："Minimalist illustration, Apple Design Philosophy, 1024x1024. Top left shows 'AI + Education' core concept, bottom right shows data of teacher-student-AI collaboration, soft color palette, clean lines, no redundant elements."
|
||||
入力例2（直接的描画指示）：元のテキスト：「Apple風の猫を描いて、MacBookの隣に座っている」最終System Prompt：SYSTEM_PROMPT_DEFAULT（無効状態）出力予想："Minimalist cat, Apple style, 1024x1024, sitting next to a silver MacBook, clean white background, soft shadows, geometric shapes, no extra details."
|
||||
·プロンプト出力強制制約
|
||||
純粋な英語、中国語なし；
|
||||
Apple Design Philosophy/Apple style + 1024x1024を必ず含む；
|
||||
長さ50–200文字、コード内で検証；
|
||||
余分な説明、プレフィックス、無駄な内容は一切なし、プロンプト自体のみ返却。
|
||||
|
||||
4、コンポーネント連動ルール
|
||||
生成成功：プロンプトをgeneration_promptボックスに充填、generate_btnを有効化、intent_statusに「プロンプト生成成功、修正後に画像生成可能」を追加；
|
||||
生成失敗：具体的な理由をプロンプト表示（例：API呼び出し失敗、長さ不適格）、generate_btnは無効状態を維持、generation_promptボックスは空；
|
||||
ユーザーがgeneration_promptボックスを手動修正 / クリア：
|
||||
クリア時は自動的にgenerate_btnを無効化；
|
||||
空でない場合はgenerate_btnを有効状態に維持。
|
||||
|
||||
5、例外処理
|
||||
API呼び出し失敗：フレンドリーなプロンプト「プロンプト生成失敗：{具体的なエラー情報}」、クラッシュしない；
|
||||
プロンプト検証失敗：明確に原因をプロンプト表示（例：「Apple styleが含まれていない」「長さが40文字しかない」）、リトライを許可；
|
||||
レスポンス解析失敗：プロンプト「LLM返却結果を解析できません、リトライしてください」。
|
||||
|
||||
6、出力要件
|
||||
LLM_API_KEYを置き換えるだけで使用可能な完全な実行可能コード；
|
||||
コード構造は明確、コメントは完備、インターフェースは美しくシンプル；
|
||||
標準Chatメッセージリスト構造を厳格に実装、パラメータと例のロジックは一致；
|
||||
プロンプト長、内容検証ロジックを含み、エラープロンプトはフレンドリー。
|
||||
```
|
||||
|
||||
同様に第2ステップのテキストをコピーして検証します。
|
||||
|
||||
注目すべきは、ここでプリセットした画像生成プロンプト生成用のSystem Promptは以下の通りです：
|
||||
|
||||
> あなたはNanoBanana描画プロンプトを作成するアシスタントです。
|
||||
> 私の内容に基づいて処理する必要があります。この画像の役割は、この文章が何を言っているかを説明し、皆にこの文章の文脈構造全体の意味を理解させることです。
|
||||
> PPTのような説明が含まれる場合があります（例：左上に核心的観点、右下にデータ）。
|
||||
> デザインスタイル要件：シンプル、Apple Design Philosophy（Apple設計哲学）。
|
||||
> 制約：NanoBananaで使用可能な英語プロンプトのみを直接返却し、説明、プレフィックス、余計な内容は一切返却しないでください。
|
||||
|
||||
他のプリセットテンプレートに変更したい場合は、前のpromptで修正するか、Traeで対話を通じて修正できます。
|
||||
|
||||
|
||||
|
||||
基盤コードを修正するだけでなく、Web上でも素早く編集できます。例えば、ここで「先頭にPic Promptという一文を追加」という一文を追加すると、新しく生成されたプロンプトの先頭にもそれが含まれていることがわかります～この設計は、画像生成プロンプトのSystem Promptを素早く修正し、スタイルの迅速な切り替えを支援するためのものです。
|
||||
|
||||
|
||||
|
||||
#### ステップ4️⃣：Nanobananaテキストから画像 / 画像から画像モジュール
|
||||
|
||||
ついに最後のステップです。画像生成モデルを接続しなければ、完全なAgentとは言えません！
|
||||
|
||||
```Bash
|
||||
セクション 4：Nanobananaテキストから画像 / 画像から画像モジュール（最終版）
|
||||
1、タスク目標
|
||||
「画像を生成」ボタンのロジックを実装し、実際のNanobanana APIを呼び出し、テキストから画像 / 画像から画像をサポートし、Base64を解析して画像を表示。
|
||||
|
||||
2、技術スタック要件
|
||||
Gradio 4.0.0+ Blocksに基づく；
|
||||
依存関係：requests, pillow, base64, io, re；
|
||||
完全コード = セクション1+2+3 + 本モジュール。
|
||||
|
||||
3、核心API設定（実践検証済み固定）
|
||||
固定コード設定：
|
||||
python
|
||||
実行
|
||||
# コードに固定されたAPI設定
|
||||
NANOBANANA_API_URL = "https://api.zyai.online/v1/chat/completions"
|
||||
NANOBANANA_MODEL = "gemini-2.5-flash-image"
|
||||
NANOBANANA_API_KEY = "" # ユーザーが各自入力
|
||||
認証方式：Header Authorization: Bearer {NANOBANANA_API_KEY}。
|
||||
|
||||
4、画像前処理要件（実装必須）関数image_to_base64_data_uri (ref_image_path)を実装、核心ロジック：
|
||||
PIL画像をPNG形式に変換；
|
||||
1024x1024解像度に自動リサイズ；
|
||||
透明チャンネルを白色背景に変換；
|
||||
Base64にエンコード、返却形式：data:image/png;base64,...。
|
||||
|
||||
5、リクエスト構築ルール（実践版分岐ロジックに厳格に従う）
|
||||
·核心関数の定義関数generate_image (prompt, ref_image_path)を実装：
|
||||
引数：prompt（generation_promptボックスの内容）、ref_image_path（ref_imageにアップロードされたファイルパス）；
|
||||
返却：PIL Image（result_imageに表示）またはエラープロンプト。
|
||||
·分岐1：純テキストから画像（ref_image_pathが空）
|
||||
python
|
||||
実行
|
||||
messages = [{"role": "user", "content": prompt}]
|
||||
·分岐2：画像から画像（ref_image_pathに値あり）
|
||||
python
|
||||
実行
|
||||
# まず画像前処理関数を呼び出し
|
||||
image_base64 = image_to_base64_data_uri(ref_image_path)
|
||||
messages = [{"role": "user","content": [{"type": "text", "text": prompt},{"type": "image_url", "image_url": {"url": image_base64}}]}]
|
||||
|
||||
6、レスポンス解析要件（2つの形式に互換必須）choices[0].message.contentから画像Base64を抽出し、サポート：
|
||||
構造化JSON返却のimage_urlフィールド；
|
||||
Markdown形式
|
||||
；
|
||||
統一的にBase64エンコードを抽出、デコード後PIL Imageに変換して返却。
|
||||
|
||||
7、コンポーネント連動と例外処理
|
||||
生成成功：PIL Imageをresult_imageに表示、intent_statusに「画像生成成功」をプロンプト；
|
||||
生成 / 解析 / アップロード失敗：intent_statusに明確なテキストプロンプトを表示（例：「Base64解析失敗」「API呼び出しタイムアウト」）、クラッシュしない。
|
||||
|
||||
8、出力要件
|
||||
LLM_API_KEYとNANOBANANA_API_KEYを置き換えるだけで直接実行可能な完全コード、全プロセス利用可能、分岐ロジックは実践版に厳格にマッチ。
|
||||
```
|
||||
|
||||
|
||||
|
||||
とてもエキサイティングですね！ついにこのAgentの最初の画像を正常に生成しました。生成された画像をよく見ると、テキストとプロンプトにマッチしていることがわかります。ここまでで、基本的にあなた自身のAgentが実装できました！
|
||||
|
||||
|
||||
|
||||
画像から画像機能も追加しており、お気に入りの画像をアップロードすると、AIが自動的にスタイルを参考にします。
|
||||
|
||||
|
||||
|
||||
特筆すべきは、前のステップで生成されたプロンプトもWeb上で編集可能であり、最終的にボタンをクリックした時のプロンプトが基準となることです～例えばここで「a cute cat」に変更した場合、最終的に生成される画像も可愛い子猫になります。
|
||||
|
||||
## 第4章：まとめ
|
||||
|
||||
|
||||
|
||||
**ついに完成しました！**
|
||||
正直なところ、私自身も最後の一行を書き終えた時、思わず深く息を吐きました。ましてやここまでやり遂げたあなたはなおさらです。この一連のフローを完全に実行できたこと自体が、本当に素晴らしいことです。それはあなたが本当にキーボードに手を置き、一歩ずつやり遂げたことを意味しています。Bravo 🎉 🥳 👏
|
||||
|
||||
この内容を書く過程で、私はずっと考え続けていました——私たちは一体何を残すべきなのか？答えは実はモデルの名前、パラメータ、あるいは特定の固定手法ではなく、あなたに徐々に一つの感覚を身につけさせることです：どのようなことを安心してAIに理解と計画を任せ、どのような部分ではあなたが方向を決めるだけでよいのか。この分担関係が成立すれば、元々複雑に見えた生成プロセスの多くが、自然とスムーズに進むようになります。
|
||||
|
||||
振り返ってみると、この道は実はそれほど複雑ではありません。解決したい問題を明確に考え、長文は言語モデルに分解させ、整理された視覚的意図を画像生成モデルに表現させ、最後にこの一連のフローをあなただけの小さなアシスタントとしてパッケージ化します。ここまで来ると、あなたはもはや「モデルを使っている」だけでなく、長期的にあなたの仕事をサポートするシステムを構築しています。これこそが、このチュートリアルが最も伝えたかったことです。
|
||||
|
||||
しかし、あなたはすでに素晴らしい成果を上げています！ここまで学んできたあなたはVibe Codingの基礎をすでに身につけています。少し休憩してリフレッシュしましょう！
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="関連記事"
|
||||
description="「素材生成」を本格的にプロダクトプロセスに組み込みたい場合は、これらの章を引き続き学んでください。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,428 @@
|
||||
# モダンコンポーネントライブラリでUIをアップデート
|
||||
|
||||
前のコースでは、デザインツールでインターフェースを描き、AI IDEでデザイン稿をコードに変換し、完全なフロントエンドプロジェクトを完成させる方法を学びました。しかし、一つの問題に気づいたかもしれません：ゼロから書いたボタン、フォーム、ポップアップは、使えるものの、「プロのプロダクト」との差を感じさせます——スタイルの統一性が不足し、インタラクションのディテールが滑らかではなく、異なる画面への対応も頭を悩ませます。
|
||||
|
||||
これこそが**コンポーネントライブラリ**が解決する問題です。
|
||||
|
||||
コンポーネントライブラリは、あらかじめ設計・開発されたUIパーツの集合です。ボタン、入力ボックス、ドロップダウンメニュー、ダイアログ、テーブル...どんなプロダクトでも繰り返し使われるインターフェース要素が、コンポーネントライブラリにはすでに用意されており、多くのユーザーによって検証・磨き上げられています。積み木のように組み合わせるだけで、プロフェッショナルなインターフェースを素早く構築できます。
|
||||
|
||||
## 学べること
|
||||
|
||||
1. フロントエンドコンポーネントライブラリとは何か、そしてなぜモダン開発でほぼ必須なのかを理解する
|
||||
2. 最も代表的な4つのコンポーネントライブラリを知り、それぞれの得意なシーンを理解する
|
||||
3. 3つの実践シーン（ランディングページ、プロダクトページ、バックエンド管理）を通じて、AI IDE + コンポーネントライブラリでVibe Codingを学ぶ
|
||||
4. コンポーネントライブラリのドキュメントを読み、要件に応じて適切なコンポーネントを見つけて正しく使用する方法を学ぶ
|
||||
|
||||
## 1. なぜコンポーネントライブラリが必要なのか？
|
||||
|
||||
家の改装を想像してみてください。木材から椅子を自分で作ることもできますが、もっと一般的なのはIKEAで買うことです——デザインが良く、品質が安定し、説明書が明確で、持ち帰って組み立てるだけ。
|
||||
|
||||
コンポーネントライブラリはフロントエンド開発における「IKEA」です。家具ではなくインターフェースパーツを提供します：
|
||||
|
||||
| 自分で手書き | コンポーネントライブラリを使用 |
|
||||
| :--- | :--- |
|
||||
| スタイル、インタラクション、アニメーションを自分で処理 | 開封即使用可能、スタイルとインタラクションはすでに磨き上げ済み |
|
||||
| 異なるページのボタンが違って見える可能性 | グローバルにスタイルが統一され、一貫性が自動的に維持 |
|
||||
| スマホ、タブレット対応に追加の作業が必要 | ほとんどのコンポーネントライブラリにレスポンシブサポートが内蔵 |
|
||||
| アクセシビリティ（Accessibility）が漏れやすい | プロのコンポーネントライブラリはキーボードナビゲーション、スクリーンリーダー等に対応済み |
|
||||
| 開発速度が遅い | 開発速度が速く、ビジネスロジックに集中 |
|
||||
|
||||
簡単に言えば：**コンポーネントライブラリは「どう描くか」ではなく「何を作るか」に時間を使わせてくれます。**
|
||||
|
||||
### 百聞は一見に如かず：同じ要件で、コンポーネントライブラリの有無の差
|
||||
|
||||
言葉だけでは説得力がありません。Traeでほぼ同じ要件を使い、それぞれ指定なしと指定ありで生成結果の差を見てみましょう。
|
||||
|
||||
**プロンプト1：コンポーネントライブラリ不使用**
|
||||
|
||||
```text
|
||||
AI執筆アシスタントのデータダッシュボードページを作ってください。含む：
|
||||
- トップのタイトルバーとエクスポートボタン
|
||||
- 4つの統計カードでユーザー数、アクティブユーザー、ドキュメント数、収益を表示、増減トレンドも表示
|
||||
- 折れ線グラフと円グラフを1つずつ
|
||||
- ユーザーリストのテーブル、ページネーション機能付き
|
||||
- 左側のナビゲーションサイドバー
|
||||
```
|
||||
|
||||
**プロンプト2：shadcn/uiコンポーネントライブラリ使用**
|
||||
|
||||
```text
|
||||
AI執筆アシスタントのデータダッシュボードページを、shadcn/uiコンポーネントライブラリで作ってください。含む：
|
||||
- トップのタイトルバーとエクスポートボタン
|
||||
- 4つの統計カードでユーザー数、アクティブユーザー、ドキュメント数、収益を表示、増減トレンドも表示
|
||||
- 折れ線グラフと円グラフを1つずつ
|
||||
- ユーザーリストのテーブル、ページネーション機能付き
|
||||
- 左側のナビゲーションサイドバー
|
||||
```
|
||||
|
||||
同じ要件で、唯一の違いはプロンプトの先頭に`shadcn/ui + Tailwind CSS`を追加しただけなのに、Traeの生成結果は視覚的一貫性、インタラクションのディテール、全体的な仕上げのレベルが完全に異なります。これがコンポーネントライブラリがもたらす「無料アップグレード」です——プロンプトにコンポーネントライブラリの名前を1つ追加するだけ。
|
||||
|
||||
## 2. 4つのコアコンポーネントライブラリを知る
|
||||
|
||||
コンポーネントライブラリは多数ありますが（完全なリストは[付録](#appendix-more-component-libraries)を参照）、まず最も代表的な以下の4つを知っておけば十分です：
|
||||
|
||||
| コンポーネントライブラリ | フレームワーク | 一言で言うと | 公式サイト |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Ant Design](https://ant.design) | React | アリババグループ製、エンタープライズ級バックエンドの事実上の標準、コンポーネントのカバー範囲が極めて広い | ant.design |
|
||||
| [shadcn/ui](https://ui.shadcn.com) | React | npmパッケージとしてインストールせず、コードを直接プロジェクトにコピー、Tailwind CSSベース、カスタマイズの自由度が最高 | ui.shadcn.com |
|
||||
| [HeroUI](https://heroui.com)（旧NextUI） | React | デフォルトのスタイルが美しく、アニメーションが滑らか、視覚品質にこだわるランディングページやプロダクト展示に適する | heroui.com |
|
||||
| [Material UI](https://mui.com) | React | 最も歴史のあるReactコンポーネントライブラリ、Google Material Design仕様を実装、エコシステムが最も成熟 | mui.com |
|
||||
|
||||
> Vueユーザーにも豊富な選択肢があります：[Element Plus](https://element-plus.org)（国内で最も人気）、[Ant Design Vue](https://antdv.com)、[Naive UI](https://www.naiveui.com)など、詳細は[付録](#appendix-more-component-libraries)を参照してください。
|
||||
|
||||
異なるコンポーネントライブラリは異なるシーンに適しています。次に、3つの実際の開発シーンを通じて、AI IDE + コンポーネントライブラリでVibe Codingを体験します。
|
||||
|
||||
異なるコンポーネントライブラリのスタイルと特徴を示すため、各シーンで異なるライブラリをあえて選びました。ただし注意：**これは多様な選択肢を知ってもらうためだけ**です。実際の開発では、最も使いやすいもの1つだけを使っても全く問題ありません。shadcn/uiのスタイルが好きなら、ランディングページ、プロダクトページ、バックエンド管理すべてをそれで作れます。見た目が良く、使いやすいものを1つ選ぶことが何より重要です。
|
||||
|
||||
## 3. 実践1：HeroUIでプロダクトランディングページを構築
|
||||
|
||||
**シーン**：AI執筆アシスタントのプロダクトを作り、製品の特徴を展示し、ユーザーの登録を促す美しいランディングページが必要です。ランディングページは視覚的なインパクトが強く、アニメーションが滑らかで、スマホでも見栄えが良い必要があります。
|
||||
|
||||
**HeroUIを選んだ理由**：HeroUIのデフォルトスタイルがすでに美しく、滑らかなトランジションアニメーションが組み込まれており、ユーザー向けの展示型ページに非常に適しています。
|
||||
|
||||
### 3.1 プロジェクトの作成
|
||||
|
||||
```bash
|
||||
# HeroUI公式CLIでプロジェクトを作成
|
||||
npx create-heroui-app@latest ai-writer-landing
|
||||
cd ai-writer-landing
|
||||
npm install
|
||||
```
|
||||
|
||||
### 3.2 AI IDEでランディングページを生成
|
||||
|
||||
AI IDE（Cursor、Traeなど）を開き、ダイアログに以下を入力：
|
||||
|
||||
```text
|
||||
AI執筆アシスタントのランディングページをHeroUIコンポーネントライブラリで作ってください：
|
||||
|
||||
**ページ構造：**
|
||||
1. トップナビバー：左にロゴとプロダクト名、右に「機能」「料金」「概要」の3つのリンクと「始める」ボタン
|
||||
2. ファーストビューエリア：大見出しに「AIをあなたの執筆パートナーに」、サブタイトルでプロダクトの価値を紹介、2つのボタン「無料トライアル」と「デモを見る」、下にプロダクトのスクリーンショット
|
||||
3. 機能紹介：3列のカードで、「スマート続き執筆」「スタイル調整」「多言語翻訳」の3つの機能をそれぞれ紹介。各カードにアイコン、タイトル、説明
|
||||
4. 料金エリア：3つの料金カード（無料版、プロ版、チーム版）、プロ版をおすすめとして強調表示
|
||||
5. ボトムCTA：魅力的なコピーと登録ボタン
|
||||
6. フッター：著作権情報とソーシャルメディアリンク
|
||||
|
||||
**デザイン要件：**
|
||||
- モダンでプロフェッショナルな見た目
|
||||
- ダークモード対応
|
||||
- スマホでも見やすく
|
||||
```
|
||||
|
||||
### 3.3 AIが使用する主要コンポーネント
|
||||
|
||||
AIが生成したコードで、これらのHeroUIコンポーネントが見られます：
|
||||
|
||||
```jsx
|
||||
import {
|
||||
Navbar, NavbarBrand, NavbarContent, NavbarItem,
|
||||
Button,
|
||||
Card, CardHeader, CardBody, CardFooter,
|
||||
Divider,
|
||||
Link,
|
||||
Chip
|
||||
} from '@heroui/react'
|
||||
```
|
||||
|
||||
各コンポーネントの役割：
|
||||
|
||||
| コンポーネント | 用途 | ランディングページでの位置 |
|
||||
| :--- | :--- | :--- |
|
||||
| `Navbar` | トップナビバー | ページ最上部、固定 |
|
||||
| `Button` | ボタン、複数のバリアントとカラーをサポート | CTAボタン、ナビボタン |
|
||||
| `Card` | カードコンテナ | 機能紹介、料金カード |
|
||||
| `Chip` | 小さなタグ | 「おすすめ」、「最も人気」マーク |
|
||||
| `Divider` | 区切り線 | エリア間の視覚的仕切り |
|
||||
|
||||
### 3.4 イテレーションと最適化
|
||||
|
||||
生成された初版コードに完全に満足できない場合、AIとの対話を続けて調整します：
|
||||
|
||||
```text
|
||||
ランディングページを最適化してください：
|
||||
|
||||
1. 大見出しにグラデーションカラーを追加、青から紫へのグラデーション
|
||||
2. 機能カードにhover時の浮上アニメーション効果を追加
|
||||
3. プロ版の料金カードを強調表示し、ボーダーと「最も人気」のタグを追加
|
||||
4. スマホでのナビをハンバーガーメニューに変更
|
||||
```
|
||||
|
||||
> **Vibe Codingの核心**：各コンポーネントのAPIを覚える必要はなく、自然言語で望む効果を説明するだけで、AIが適切なコンポーネントと書き方を見つけてくれます。不満な点があれば、対話を続けてイテレーションするだけ。
|
||||
|
||||
## 4. 実践2：shadcn/uiでプロダクトページを構築
|
||||
|
||||
**シーン**：AI執筆アシスタントに、ユーザーログイン後のメインインターフェースが必要です——左側にドキュメントリスト、右側にエディタ、上部にツールバー。これは機能型のプロダクトページで、高度にカスタマイズされたUIが必要です。
|
||||
|
||||
**shadcn/uiを選んだ理由**：shadcn/uiはコンポーネントコードを直接プロジェクトに配置するため、どんなディテールも自由に変更できます。深いカスタマイズが必要なプロダクトインターフェースでは、この「コードを所有する」モードが最も柔軟です。
|
||||
|
||||
### 4.1 プロジェクトの作成
|
||||
|
||||
```bash
|
||||
# Next.jsプロジェクトを作成
|
||||
npx create-next-app@latest ai-writer-app --typescript --tailwind --app
|
||||
cd ai-writer-app
|
||||
|
||||
# shadcn/uiを初期化
|
||||
npx shadcn@latest init
|
||||
|
||||
# 必要に応じてコンポーネントを追加（すべてのコンポーネントを一度にインストールするのではない）
|
||||
npx shadcn@latest add button card input sidebar sheet dialog
|
||||
```
|
||||
|
||||
shadcn/uiのユニークな点：`add`でコンポーネントを追加するたびに、プロジェクトの`components/ui/`ディレクトリにソースコードがコピーされます。これらのファイルを直接開いてスタイルや動作を変更できます。
|
||||
|
||||
### 4.2 AI IDEでプロダクトインターフェースを生成
|
||||
|
||||
```text
|
||||
AI執筆アシスタントのメインインターフェースをshadcn/uiコンポーネントライブラリで作ってください：
|
||||
|
||||
**全体レイアウト：**
|
||||
- 左側に折りたたみ可能なサイドバー、幅は約280px：
|
||||
- トップに「新規ドキュメント」ボタン
|
||||
- 下にドキュメントリスト、各ドキュメントにタイトルと最終編集時間を表示
|
||||
- ドキュメントを右クリックで名前の変更や削除
|
||||
- 右側にメイン編集エリア、上下2つの部分に分割：
|
||||
- 上はツールバー：ドキュメントタイトルの編集、文字数統計の表示、「AI続き執筆」ボタン、「エクスポート」ドロップダウンメニュー
|
||||
- 下は編集エリア：大きなテキスト入力ボックス、残りのスペースを占める
|
||||
|
||||
**インタラクションのディテール：**
|
||||
- 「AI続き執筆」をクリック後、ボタンにローディング状態を表示、エディタの下部にAI生成テキストが表示（タイプライターのように1文字ずつ表示）
|
||||
- スマホではサイドバーをドロワー形式にし、左からスライドイン
|
||||
- 現在選択中のドキュメントをハイライト表示
|
||||
```
|
||||
|
||||
### 4.3 AIが使用する主要コンポーネント
|
||||
|
||||
```tsx
|
||||
import { Button } from '@/components/ui/button'
|
||||
import { Input } from '@/components/ui/input'
|
||||
import { Card, CardContent, CardHeader } from '@/components/ui/card'
|
||||
import {
|
||||
DropdownMenu,
|
||||
DropdownMenuContent,
|
||||
DropdownMenuItem,
|
||||
DropdownMenuTrigger
|
||||
} from '@/components/ui/dropdown-menu'
|
||||
import {
|
||||
Sheet,
|
||||
SheetContent,
|
||||
SheetTrigger
|
||||
} from '@/components/ui/sheet'
|
||||
import {
|
||||
Sidebar,
|
||||
SidebarContent,
|
||||
SidebarHeader
|
||||
} from '@/components/ui/sidebar'
|
||||
```
|
||||
|
||||
| コンポーネント | 用途 | プロダクトページでの位置 |
|
||||
| :--- | :--- | :--- |
|
||||
| `Sidebar` | 折りたたみ可能サイドバー | 左側のドキュメントリスト |
|
||||
| `Sheet` | モバイル用ドロワー | モバイルでのサイドバー代替 |
|
||||
| `DropdownMenu` | ドロップダウンメニュー | 「エクスポート」ボタン、右クリックメニュー |
|
||||
| `Dialog` | ダイアログ | 名前の変更、削除の確認 |
|
||||
| `Button` | ボタン、variantとloadingをサポート | 各種操作ボタン |
|
||||
| `Input` | 入力ボックス | ドキュメントタイトルの編集 |
|
||||
|
||||
### 4.4 コンポーネントスタイルのカスタマイズ
|
||||
|
||||
shadcn/uiの利点は、コンポーネントのソースコードを直接修正できることです。例えば、ボタンの角丸を大きくしたい場合：
|
||||
|
||||
```text
|
||||
components/ui/button.tsxを修正して、
|
||||
すべてのボタンのデフォルトの角丸をrounded-mdからrounded-xlに変更し、
|
||||
primaryバリアントに微妙なシャドウ効果を追加してください
|
||||
```
|
||||
|
||||
AIはプロジェクト内のコンポーネントファイルを直接修正し、npmパッケージのスタイルを上書きしません——これがshadcn/uiの「コードを所有する」利点です。
|
||||
|
||||
## 5. 実践3：Ant Designでバックエンド管理インターフェースを構築
|
||||
|
||||
**シーン**：AI執筆アシスタントがローンチした後、ユーザーデータの確認、ドキュメントコンテンツの管理、有料注文の処理を行う管理バックエンドが必要です。バックエンド管理システムの核心はデータ表示と操作効率です。
|
||||
|
||||
**Ant Designを選んだ理由**：Ant Designは中〜バックエンド領域で最も蓄積が深く、テーブル、フォーム、チャートなどのビジネスコンポーネントが開封即使用可能で、大量のエンタープライズ級インタラクションパターン（一括操作、高度なフィルタリング、データエクスポートなど）が内蔵されています。
|
||||
|
||||
### 5.1 プロジェクトの作成
|
||||
|
||||
```bash
|
||||
# Ant Design Proスキャフォールドを使用（レイアウト、ルーティング、権限が内蔵）
|
||||
npx create-umi@latest ai-writer-admin
|
||||
# Ant Design Proテンプレートを選択
|
||||
cd ai-writer-admin
|
||||
npm install
|
||||
```
|
||||
|
||||
またはゼロから開始：
|
||||
|
||||
```bash
|
||||
npx create-react-app ai-writer-admin --template typescript
|
||||
cd ai-writer-admin
|
||||
npm install antd @ant-design/icons @ant-design/pro-components
|
||||
```
|
||||
|
||||
### 5.2 AI IDEで管理バックエンドを生成
|
||||
|
||||
```text
|
||||
AI執筆アシスタントの管理バックエンドをAnt Designコンポーネントライブラリで作ってください：
|
||||
|
||||
**全体レイアウト：**
|
||||
- 左側にメニューバー：ダッシュボード、ユーザー管理、ドキュメント管理、注文管理、システム設定
|
||||
- トップにパンくずナビゲーションを表示
|
||||
|
||||
**ユーザー管理ページ：**
|
||||
- トップに4つの統計カード：総ユーザー数、本日新規、アクティブユーザー数、有料ユーザー数
|
||||
- 検索フィルターエリア：ユーザー名で検索、登録時間範囲を選択、ユーザーステータスでフィルター、「検索」と「リセット」ボタン
|
||||
- ユーザーテーブル：
|
||||
- アバター、ユーザー名、メール、登録時間、サブスクリプションプラン（異なるカラータグで区別）、ステータス、操作を表示
|
||||
- 1ページに20件表示、ページネーション対応
|
||||
- ユーザーを一括選択でき、一括無効化またはエクスポートが可能
|
||||
- 操作列：詳細を見る、編集、無効化（無効化前に再確認）
|
||||
- 「詳細を見る」をクリックすると右からドロワーがスライドインし、ユーザーの詳細情報と最近のドキュメントリストを表示
|
||||
```
|
||||
|
||||
### 5.3 AIが使用する主要コンポーネント
|
||||
|
||||
```tsx
|
||||
import { PageContainer, ProLayout } from '@ant-design/pro-components'
|
||||
import { ProTable } from '@ant-design/pro-components'
|
||||
import { StatisticCard } from '@ant-design/pro-components'
|
||||
import {
|
||||
Button, Tag, Badge, Space, Drawer,
|
||||
Popconfirm, message, Modal
|
||||
} from 'antd'
|
||||
import {
|
||||
UserOutlined, SearchOutlined, ExportOutlined
|
||||
} from '@ant-design/icons'
|
||||
```
|
||||
|
||||
| コンポーネント | 用途 | バックエンドでの位置 |
|
||||
| :--- | :--- | :--- |
|
||||
| `ProLayout` | バックエンド全体のレイアウトフレーム | ページの骨格（メニュー + コンテンツエリア） |
|
||||
| `ProTable` | 高度なテーブル、検索、ページネーション、列設定が内蔵 | ユーザーリスト、ドキュメントリスト、注文リスト |
|
||||
| `StatisticCard` | データ統計カード | ダッシュボード、ページ上部の概要 |
|
||||
| `Tag` / `Badge` | ステータスタグ | サブスクリプションプラン、ユーザーステータス |
|
||||
| `Drawer` | サイドドロワー | ユーザー詳細、編集フォーム |
|
||||
| `Popconfirm` | バブル確認ボックス | 削除、無効化などの危険な操作 |
|
||||
|
||||
### 5.4 続けてイテレーション：ダッシュボードの追加
|
||||
|
||||
```text
|
||||
ダッシュボードページを作ってください：
|
||||
|
||||
1. トップに4つの統計カード：総ユーザー数、総ドキュメント数、本日のAPI呼び出し回数、月間収益。各カードに数値と前月比の変化（増加か減少か）を表示
|
||||
2. 中央に2つのチャート：
|
||||
- 左：直近7日間のユーザー増加の折れ線グラフ
|
||||
- 右：サブスクリプションプラン分布の円グラフ
|
||||
3. ボトム：最近の操作ログテーブル、時間、ユーザー、操作タイプ、詳細を表示
|
||||
|
||||
Ant Designのコンポーネントでレイアウトし、チャートはAnt Design Chartsを使用
|
||||
```
|
||||
|
||||
> **バックエンド管理のVibe Codingのコツ**：バックエンドページの構造は比較的固定（テーブル + 検索 + ポップアップ）で、AIによるバッチ生成に非常に適しています。まずAIに「ユーザー管理」ページをテンプレートとして生成させ、その後「ユーザー管理ページの構造を参考に、ドキュメント管理ページを生成して」と言えば、AIは同じレイアウトパターンを再利用します。
|
||||
|
||||
## 6. ドキュメントの読み方を学ぶ：コンポーネントライブラリの「説明書」
|
||||
|
||||
Vibe CodingではAIが大部分のコードを書いてくれますが、AIの生成結果が正しくない場合や、特定のコンポーネントの動作を微調整したい場合は、**ドキュメントを確認する**のが最速の解決方法です。
|
||||
|
||||
Ant Designを例にすると、ドキュメントのアドレスは：`https://ant.design/components/overview-cn`
|
||||
|
||||
ドキュメントを確認する標準的なフロー：
|
||||
|
||||
1. **要件を明確にする**：例えば「テーブルで行選択をサポートしたい」
|
||||
2. **ドキュメントで検索**：「Table」を検索してテーブルコンポーネントのページに進む
|
||||
3. **例を確認**：ドキュメント内の各コンポーネントには複数のオンライン例があり、「選択可能」の例を見つける
|
||||
4. **コードをコピー**：例のコードをプロジェクトにコピーする
|
||||
5. **APIテーブルを確認**：ページ下部で`rowSelection`属性の完全な設定項目を見つける
|
||||
|
||||
> ドキュメントのリンクをAI IDEに直接送ることもできます：「https://ant.design/components/table-cn のrowSelection APIを参考に、ユーザーテーブルに一括選択機能を追加してください」。AIにドキュメントのリンクを提供すると、より正確なコードが生成されます。
|
||||
|
||||
各コンポーネントライブラリのドキュメントアドレス早見表：
|
||||
|
||||
| コンポーネントライブラリ | ドキュメントアドレス |
|
||||
| :--- | :--- |
|
||||
| Ant Design | `https://ant.design/components/overview-cn` |
|
||||
| shadcn/ui | `https://ui.shadcn.com/docs/components` |
|
||||
| HeroUI | `https://heroui.com/docs/components` |
|
||||
| Material UI | `https://mui.com/material-ui/all-components/` |
|
||||
| Element Plus | `https://element-plus.org/zh-CN/component/overview.html` |
|
||||
|
||||
## 7. まとめ
|
||||
|
||||
3つの実践シーンは、最も一般的なフロントエンド開発のニーズをカバーしています：
|
||||
|
||||
| シーン | 推奨コンポーネントライブラリ | 核心的な特徴 |
|
||||
| :--- | :--- | :--- |
|
||||
| ランディングページ / 展示ページ | HeroUI | デフォルトのスタイルが美しく、アニメーションが滑らか、視覚的インパクトが強い |
|
||||
| プロダクト機能ページ | shadcn/ui | コードが完全にコントロール可能、深いカスタマイズが柔軟 |
|
||||
| バックエンド管理システム | Ant Design | ビジネスコンポーネントが豊富、テーブル・フォームが開封即使用可能 |
|
||||
|
||||
Vibe Codingのワークフローのまとめ：
|
||||
|
||||
1. シーンに応じて適切なコンポーネントライブラリを選択
|
||||
2. AI IDEで望むページ構造とインタラクションを説明
|
||||
3. AIが初版コードを生成し、効果をプレビュー
|
||||
4. 自然言語でイテレーションと調整を続ける
|
||||
5. ディテールの問題に遭遇したらコンポーネントライブラリのドキュメントを確認
|
||||
|
||||
### 練習
|
||||
|
||||
以下のいずれかのシーンを選び、AI IDE + コンポーネントライブラリでゼロから完成させてください：
|
||||
|
||||
1. HeroUIで以前のプロジェクト（例えばホグワーツ肖像画）の展示ランディングページを作る
|
||||
2. shadcn/uiでノートアプリのメインインターフェースを構築（サイドバー + エディタ）
|
||||
3. Ant Designでシンプルなコンテンツ管理バックエンドを構築（記事リスト + 新規記事フォーム）
|
||||
|
||||
---
|
||||
|
||||
## 付録：更多のコンポーネントライブラリ一覧 {#appendix-more-component-libraries}
|
||||
|
||||
本編で紹介した4つのコアライブラリ以外にも、フロントエンドエコシステムには優れたコンポーネントライブラリが多数あります。以下はフレームワーク別に分類したリストで、プロジェクトの要件に応じて選択してください。
|
||||
|
||||
### Vue エコシステム
|
||||
|
||||
| コンポーネントライブラリ | Stars | 概要 | 適用シーン |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Element Plus](https://element-plus.org) | ~27k | Ele.meチームによるVue 3エンタープライズ級コンポーネントライブラリ、国内で最も広く使用され、中国語エコシステムが優れている | 中〜バックエンド管理システム |
|
||||
| [Vuetify](https://vuetifyjs.com) | ~41k | 最も人気のあるVue Material Designコンポーネントライブラリ、80+コンポーネント、ドキュメントが充実 | Googleデザインスタイルのプロジェクト |
|
||||
| [Ant Design Vue](https://antdv.com) | ~21k | Ant Designシステムに基づくVue 3コンポーネントライブラリ、デザイン仕様が統一 | エンタープライズ級中〜バックエンド |
|
||||
| [Naive UI](https://www.naiveui.com) | ~18k | TypeScriptで記述、テーマのカスタマイズ性が極めて高く、CSSプリプロセッサに依存しない | デザインに独自の要件があるプロジェクト |
|
||||
| [Quasar](https://quasar.dev) | ~27k | 1つのコードでSPA、SSR、PWA、モバイル、デスクトップアプリを構築 | クロスプラットフォームプロジェクト |
|
||||
| [Vant](https://vant-ui.github.io/vant) | ~24k | Youzanチームが開発した軽量モバイルコンポーネントライブラリ、ECの一般的なニーズをカバー | モバイルH5ページ |
|
||||
| [PrimeVue](https://primevue.org) | ~14k | 90+コンポーネント、複数のテーマ（Material、Bootstrap等）をサポート | 豊富なコンポーネントとマルチテーマが必要な場合 |
|
||||
| [Arco Design Vue](https://arco.design/vue) | ~3k | ByteDance製、コンポーネントの品質が高く、ダークモード内蔵 | 中〜バックエンドプロダクト |
|
||||
| [TDesign Vue Next](https://tdesign.tencent.com/vue-next) | ~2k | Tencent製、デザイン言語が統一、デスクトップの一般的なシーンをカバー | Tencentエコシステムまたはエンタープライズ級プロジェクト |
|
||||
|
||||
### React エコシステム
|
||||
|
||||
| コンポーネントライブラリ | Stars | 概要 | 適用シーン |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Material UI (MUI)](https://mui.com) | ~95k | Google Material Design仕様の老舗実装、コンポーネントが最も包括的、エコシステムが最も成熟 | エンタープライズ級アプリケーションの迅速な構築 |
|
||||
| [Ant Design](https://ant.design) | ~94k | アリババグループ製、大量の高品質なビジネスコンポーネントが内蔵、中国語開発者コミュニティで主導的地位 | エンタープライズ級中〜バックエンド |
|
||||
| [shadcn/ui](https://ui.shadcn.com) | ~83k | npmインストールではなくコードをプロジェクトにコピー、Radix UI + Tailwind CSSベース、完全にコントロール可能 | 高度なカスタマイズが必要なプロジェクト |
|
||||
| [Chakra UI](https://chakra-ui.com) | ~39k | 開発体験を核心に、APIがシンプル、アクセシビリティサポートが内蔵 | 迅速なプロトタイピング開発 |
|
||||
| [Mantine](https://mantine.dev) | ~28k | 100+コンポーネントと50+ hooks、日付ピッカー、リッチテキストエディタ等の高度なコンポーネントを含む | 開封即使用可能なフル機能ソリューションが必要な場合 |
|
||||
| [Headless UI](https://headlessui.com) | ~27k | Tailwind Labs公式のスタイルなしコンポーネントライブラリ、ReactとVueの両方をサポート | Tailwind CSSとの組み合わせ |
|
||||
| [HeroUI](https://heroui.com) | ~24k | Tailwind CSS + React Ariaベース、デフォルトのスタイルが美しく、アニメーションが滑らか | 視覚品質にこだわるプロジェクト |
|
||||
| [Radix UI](https://www.radix-ui.com) | ~17k | スタイルなしの低レベルコンポーネントプリミティブライブラリ、アクセシビリティとコンポーネントの動作に特化、shadcn/uiの基盤 | カスタムデザインシステムの構築 |
|
||||
|
||||
#### shadcn/ui 拡張エコシステム
|
||||
|
||||
上記の汎用コンポーネントライブラリ以外にも、shadcn/uiのエコシステムにはその理念に基づいた拡張ライブラリが多数あり、特定のシーンに差別化された選択肢を提供しています。これらの拡張ライブラリも「コードをプロジェクトにコピー」するモードを採用し、開発者に完全なソースコード制御権を与えます。
|
||||
|
||||
| コンポーネントライブラリ | 概要 | 適用シーン |
|
||||
| :--- | :--- | :--- |
|
||||
| [Aceternity UI](https://ui.aceternity.com) | 200+のプロダクション級コンポーネント、発光カード、テキストグラデーション、3D地球などの特色ある視覚コンポーネント | 高品質ランディングページ、SaaSプロダクト |
|
||||
| [Tailark UI](https://tailark.com) | マーケティングサイトのコンポーネントブロック集合、プロダクト展示、顧客の声、CTAボタンなどのマーケティング高頻度モジュール | マーケティングランディングページ、プロダクト公式サイト |
|
||||
| [UI Tripled](https://ui.tripled.work) | Framer Motionベースの動的インタラクションコンポーネント、ポップアップ、ナビゲーション、カードアニメーション | クリエイティブツール、個人ポートフォリオ |
|
||||
| [Neobrutalism UI](https://neobrutalism.dev) | 新ブルータリズムスタイル、太いライン、高コントラスト、鮮やかな色彩 | 個性的なブランド公式サイト、クリエイティブプロジェクト |
|
||||
| [REUI](https://reui.io) | 967+の実際のビジネスシーンのコンポーネント組み合わせパターン | エンタープライズ級バックエンド、複雑なフォーム |
|
||||
| [Cult UI](https://cult-ui.com) | より細かいインタラクション/視覚の磨き上げ、データテーブル、フィルターパネル等の複合コンポーネント | 高品質な商用プロジェクト |
|
||||
| [Kibo UI](https://kibo-ui.com) | 高度なビジネスコンポーネント、カラーピッカー、リッチテキストエディタ、ファイルアップロード等 | 管理バックエンド、ツール系プロダクト |
|
||||
| [Kokonut UI](https://kokonutui.com) | 100+コンポーネント + 7+完全テンプレート、清新でシンプルなスタイル | SaaS公式サイト、ブログ、EC |
|
||||
| [Commerce UI](https://ui.stackzero.co) | ECシーン専用、商品カード、カート、決済フォーム | ECプラットフォーム |
|
||||
| [shadcnblocks](https://shadcnblocks.com) | 1373個のUIブロック + 13セットの完全テンプレート、最も包括的なリソース | あらゆるシーン |
|
||||
| [Shoogle](https://shoogle.dev) | shadcn/uiエコシステムの集約検索プラットフォーム | リソースの迅速検索 |
|
||||
| [Discover All Shadcn](https://allshadcn.com) | 集約型リソースナビゲーション | リソースの迅速検索 |
|
||||
|
||||
> **なぜshadcn/ui拡張を選ぶのか？** これらの拡張はshadcn/uiの「コード所有権」の理念を引き継ぎつつ、特定のシーンに深くカスタマイズされています。Vibe Coding時代において、デザイン要件に合ったコンポーネントを迅速に見つけ、主流UIライブラリの同質化から抜け出し、より差別化されたプロダクトを作ることができます。
|
||||
@@ -0,0 +1,425 @@
|
||||
# UIデザインガイドラインを参考にページとボタンを設計
|
||||
|
||||
多くの人が「ページをもっとAppleらしくしたい」「ボタンをもっと高級にしたい」と言いますが、実際に作り始めると、一つの問題で行き詰まることが多いです：
|
||||
|
||||
**一体何を参考にすべきなのか？**
|
||||
|
||||
スクリーンショットを見て模倣するだけでは、「似ているかどうか」しか学べません。しかし、Apple、Google、Microsoft、Atlassianのデザインガイドラインを開いてみると、彼らが本当にすごいのは視覚スタイルではなく、**デザインの問題を明確に説明していること**だと気づくでしょう：ページで何を先に目立たせるか、ボタンをどうランク付けするか、操作をどう強調するか——これらの判断基準こそが核心です。
|
||||
|
||||
> デザインガイドラインを参考にするのは、「誰かに似せる」ためではなく、他人がどう判断しているかを学ぶためです。
|
||||
|
||||
:::: info なぜ今でもこれらを学ぶ必要があるのか
|
||||
デザインルールはすでにモデルに学習され、デザインツールにデフォルトで取り込まれ、数枚のスクリーンショットを貼るだけでAIも学習できます。しかし、これらのルールがどこから来て、なぜこのように定められているのかを知る必要は依然としてあります。
|
||||
::::
|
||||
|
||||
## まず公式原文を読んで、差を感じてみましょう
|
||||
|
||||
「デザインガイドラインってスタイルについて語っているだけじゃないの？」と思っているなら、まず公式原文をいくつか見てみましょう。
|
||||
|
||||
普段チーム内でよくこんな言い方をしています：
|
||||
|
||||
- ドロップダウンを作って
|
||||
- ここにメニューを置いて
|
||||
- メニューバーに機能をいくつか追加して
|
||||
- ここにボタンを2つ、確認とキャンセル
|
||||
|
||||
問題なさそうに聞こえますが、大手テック企業のガイドラインでは、これらの言葉は曖昧な概念ではなく、非常に細かく分解されています。
|
||||
|
||||
| 普段何気なく言っている言葉 | 公式原文 | 簡単に言うと |
|
||||
| :--- | :--- | :--- |
|
||||
| 「メニューを作って」 | Apple: ["A menu reveals its options..."](https://developer.apple.com/design/human-interface-guidelines/menus) | `Menu`は操作に使うもの |
|
||||
| 「メニューバーに機能を入れて」 | Apple: ["menu bar menus contain all the commands..."](https://developer.apple.com/design/human-interface-guidelines/menus) | これはアプリ顶部のコマンドメニュー |
|
||||
| 「ドロップダウンを作って」 | Apple: ["A pop-up list lets the user choose one option among several."](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html) | `pop-up`はリストから1つ選ぶ |
|
||||
| 「ドロップダウンも作って」 | Apple: ["A pull-down list is generally used for selecting commands in a specific context."](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html) | `pull-down`は開いて現在の操作を行う |
|
||||
| 「メニューで絞り込みもできるよね」 | Fluent: ["If you need to collect information from people, try a select, dropdown, or combobox instead."](https://fluent2.microsoft.design/components/web/react/core/menu/usage) | `Menu`は値を選ぶためのものではない |
|
||||
| 「メニューをナビゲーションにも使えるよね」 | Material: ["Menus should not be used as a primary method for navigation within an app."](https://m1.material.io/components/menus.html) | `Menu`はメインナビゲーションではない |
|
||||
| 「ボタンは適当にOK / Cancelでいいよね」 | Apple: ["Always use 'Cancel' to title a button that cancels the alert's action."](https://developer.apple.com/design/human-interface-guidelines/alerts) | ボタンテキストは適当に書いてはいけない |
|
||||
|
||||
> 表の引用はクリックして直接対応する公式ページにジャンプできます。
|
||||
|
||||
これが、デザインガイドラインを初めて本格的に読んだ時に最も衝撃を受けるポイントです：
|
||||
|
||||
> 私たちは普段UIについて議論しているつもりでも、実際には多くの場合、曖昧な言葉の羅列でコミュニケーションしているに過ぎません。
|
||||
|
||||
Appleは単に「メニューを作って」とは言いません。さらに細分化します：
|
||||
|
||||
- `menu`
|
||||
- `menu bar menu`
|
||||
- `pop-up button`
|
||||
- `pull-down button`
|
||||
- `context menu`
|
||||
|
||||
Fluentは単に「ドロップダウン」とは言いません。さらに細分化します：
|
||||
|
||||
- `menu`
|
||||
- `dropdown`
|
||||
- `select`
|
||||
- `combobox`
|
||||
|
||||
これこそがデザインガイドラインの必要性です。
|
||||
|
||||
それはページをプロフェッショナルに見せるためではなく、チームがUIについて議論する際、全員が脳内に異なるものを思い浮かべている状態を避けるためです。
|
||||
|
||||
## 学べること
|
||||
|
||||
1. なぜページとボタンを設計する際にデザインガイドラインを先に見るべきなのか
|
||||
2. Apple、Material、Fluent、Atlassianのガイドラインの中で、どの内容が最も参考になるか
|
||||
3. 「ページ階層」と「ボタン階層」をどう明確に設計するか
|
||||
4. AIに他人のガイドラインを参考にしてページやボタンを生成させる方法
|
||||
|
||||
## 1. デザインガイドラインがなぜページを明確にするのに役立つのか
|
||||
|
||||
上記の公式原文を読んでみて、一つの重要なポイントに気づくでしょう：
|
||||
|
||||
**デザインガイドラインは锦上添花ではなく、まず言葉を正確にすることです。**
|
||||
|
||||
多くのページが美しくないのは、カラーリングが高度でないからではなく、情報階層が混乱しているからです。
|
||||
|
||||
多くのボタンが使いにくいのも、角丸が間違っているからではなく：
|
||||
|
||||
- メインボタンが多すぎて、ユーザーがどれをクリックすべきかわからない
|
||||
- 危険なボタンと普通のボタンが同じように見える
|
||||
- ページ内のすべてのボタンが注目を争っている
|
||||
- 異なるページ間でボタンのスタイルとセマンティクスが一貫していない
|
||||
|
||||
成熟したデザインガイドラインは、まさにこれらの問題を解決しています。通常、以下のことを定義します：
|
||||
|
||||
| ガイドラインの内容 | 何を解決するか |
|
||||
| :--- | :--- |
|
||||
| **ページ階層** | どこを先に見るか、どこを後で見るか、情報をどう整理するか |
|
||||
| **視覚的基礎** | 色、間隔、フォント、角丸、シャドウをどう統一するか |
|
||||
| **ボタン階層** | メインボタン、セカンダリボタン、テキストボタン、危険ボタンをどう区別するか |
|
||||
| **状態ルール** | hover、focus、disabled、loadingをどう表現するか |
|
||||
| **インタラクションセマンティクス** | どのボタンが「確認」で、どれが「キャンセル」で、どれが「その他の操作」か |
|
||||
|
||||
つまり、デザインガイドラインが真に提供するのは「スキン」ではなく、**判断基準**です。
|
||||
|
||||
## 2. 大手テック企業のガイドラインを参考にする際、何に注目すべきか
|
||||
|
||||
### 2.1 Appleを参考に：「十分に細かく定義する」ということを学ぶ
|
||||
|
||||
Appleで最も学ぶべきことは、視覚的な抑制感だけでなく、概念を非常に細かく定義する点です。
|
||||
|
||||
多くのチームが口にする「メニュー」や「ドロップダウン」について、Appleはさらに細分化します：
|
||||
|
||||
- `menu`：一連のコマンド、オプション、または状態
|
||||
- `menu bar menu`：アプリレベルのコマンド集合
|
||||
- `pop-up button`：1つの値を選択
|
||||
- `pull-down button`：現在のコンテキストでコマンドをトリガー
|
||||
- `context menu`：現在のオブジェクトやタスクに関連するよく使うアクション
|
||||
|
||||
この区分は非常に重要です。なぜなら、以下に直接影響するからです：
|
||||
|
||||
- このコンポーネントは値を選ぶためのものか、アクションを実行するためのものか
|
||||
- ページの一部に属するのか、アプリレベルに属するのか
|
||||
- 現在選択されている値を常に表示すべきか、コマンドを一時的に展開するだけか
|
||||
|
||||
この粒度で考え始めると、設計するページが一気に明確になります。
|
||||
|
||||
### 2.2 Appleを参考に：ページ階層と抑制感を学ぶ
|
||||
|
||||
Apple Human Interface Guidelinesは特に2つのことを学ぶのに適しています：
|
||||
|
||||
- ページで明確な階層をどう構築するか
|
||||
- コントロールが主張しすぎず明確さを保つにはどうするか
|
||||
|
||||
Appleは`Hierarchy`、`Harmony`、`Consistency`を強調しています。これはページ設計時に以下の問いに答えることを意味します：
|
||||
|
||||
- 現在のページで最も重要な情報は何か
|
||||
- ユーザーのメインタスクは何か
|
||||
- どの操作を最も目立たせるべきで、どの操作を後退させるべきか
|
||||
|
||||
Appleを参考にページを設計する場合、以下を重点的に参考にできます：
|
||||
|
||||
- ファーストビューの情報は細かすぎないように、コアコンテンツにまず焦点を当てる
|
||||
- 余白、フォントサイズ、グループ化で秩序を築き、多くのボーダーを重ねて築かない
|
||||
- ボタンはすべて高強調にせず、重要なアクションだけを最も目立たせる
|
||||
|
||||
### 2.3 Materialを参考に：明確なページ構造を学ぶ
|
||||
|
||||
Material Designは「ページがどうタスクフローを組織しているか」を学ぶのに非常に適しています。
|
||||
|
||||
多くのコンポーネントとレイアウトの仕様は、核心的に以下を明確にするのに役立ちます：
|
||||
|
||||
- ページは閲覧型か、タスク実行型か
|
||||
- 現在のページはユーザーに読ませる、選ばせる、それとも提出させるものか
|
||||
- 1つのページでどの要素が安定して繰り返されるべきで、どの要素がコンテキストに応じて変化するべきか
|
||||
|
||||
Materialを参考にページを設計する場合、以下を重点的に参考にできます：
|
||||
|
||||
- ページのブロックが明確で、モジュールの役割が明確
|
||||
- ナビゲーション、コンテンツエリア、操作エリアの分担が明確
|
||||
- 異なるボタンスタイルが異なる操作優先度に対応
|
||||
|
||||
### 2.4 Fluentを参考に：コンポーネントの境界とボタン階層を学ぶ
|
||||
|
||||
Fluent 2はバックエンド、ツール型プロダクト、複雑なフォームシステムに非常に適しています。最も学ぶ価値があるのは、「概念を混用しない」と直接教えてくれる点です。
|
||||
|
||||
例えば、「collect information」が必要な場合、`menu`を使い続けるのではなく、`select`、`dropdown`、`combobox`を検討すべきであると明確に書かれています。
|
||||
|
||||
この一文は非常に重要です。なぜなら、多くの人が頭の中で「だいたい同じ」だと思っている概念を打ち砕くからです。
|
||||
|
||||
Fluent 2は以下も重視しています：
|
||||
|
||||
- 操作階層
|
||||
- コンポーネントのセマンティック境界
|
||||
- 密集した情報シーンでの明確さ
|
||||
|
||||
Fluentを参考にボタンを設計する場合、以下を重点的に参考にできます：
|
||||
|
||||
- `Primary button`は現在の最も重要なアクションを受け持つ
|
||||
- `Secondary button`はサポート的なアクションを受け持つ
|
||||
- `Subtle`、`Transparent`のような弱い強調のボタンは、メインフローを邪魔すべきでない操作に使用
|
||||
- ページ内のボタン数が多くなるほど、視覚的優先度をコントロールする必要がある
|
||||
|
||||
### 2.5 Atlassianを参考に：体系的にページとボタンを管理する
|
||||
|
||||
Atlassian Design Systemは「1つのチームが多くのページを作る」場合に特に適しています。以下を強調しています：
|
||||
|
||||
- foundationsは共有の基盤
|
||||
- tokensは視覚的決定を統一する方法
|
||||
- componentsは繰り返し再利用されるインタラクション構成要素
|
||||
|
||||
Atlassianを参考にページやボタンを作る場合、最も価値があるのは：
|
||||
|
||||
- ボタンのサイズ、色、角丸、間隔を統一ルールにする
|
||||
- ページレイアウトのリズムを固定する
|
||||
- 異なるページは内容が異なっても、構造言語を一貫させる
|
||||
|
||||
## 3. ページを設計する際、ガイドラインのどのポイントを参考にすべきか
|
||||
|
||||
デザインシステムを見る際、「このページは美しいかどうか」を先に問うのではなく、まず以下の問いを立てましょう。
|
||||
|
||||
### 3.1 ページの第一印象、主従は明確か
|
||||
|
||||
1つのページは通常、少なくとも3つの層を持つべきです：
|
||||
|
||||
- **メイン情報**：現在のページで最も重要なコンテンツ
|
||||
- **補助情報**：理解を助ける、または補足するコンテンツ
|
||||
- **サブ操作**：メインタスクを邪魔すべきでないアクション
|
||||
|
||||
3つの層が分かれていないと、ページは「すべてが重要」になり、「何も重要でない」のと同じになります。
|
||||
|
||||
### 3.2 ページレイアウトはモジュールを積み上げるのではなく、タスクに奉仕しているか
|
||||
|
||||
ガイドラインを参考にする際、特に注目できます：
|
||||
|
||||
- タイトルエリアがページの目標を明確にしているか
|
||||
- メインコンテンツエリアがタスクを中心に組織されているか
|
||||
- 操作ボタンが関連コンテンツの近くにあるか
|
||||
- 補助情報が適切に弱められているか
|
||||
|
||||
### 3.3 ページ内の操作に優先度はあるか
|
||||
|
||||
多くのページを見るとボタンが6個あり、どれもCTAのように見えます。これは典型的な階層のコントロール不足です。
|
||||
|
||||
より合理的な方法は：
|
||||
|
||||
- 1つのエリアには通常1つのメインアクションのみ
|
||||
- セカンダリアクションはアウトライン、テキストボタン、またはより弱いスタイルを使用
|
||||
- リスクのあるアクションはメインアクションと同じ見た目にしない
|
||||
|
||||
## 4. ボタンを設計する際、ガイドラインのどのポイントを参考にすべきか
|
||||
|
||||
ボタンは「適当に設計」されがちな部分ですが、システムの成熟度を最もよく表す部分でもあります。
|
||||
|
||||
### 4.1 ボタンはまず「セマンティクス」で分け、次に「スタイル」で分ける
|
||||
|
||||
「青いボタンか黒いボタンか」を先に考えるのではなく、このボタンがどのような役割かを先に考えましょう。
|
||||
|
||||
よくあるボタンの役割は次のように分けられます：
|
||||
|
||||
| ボタンタイプ | 役割 | よくあるスタイル戦略 |
|
||||
| :--- | :--- | :--- |
|
||||
| **Primary** | 現在のエリアで最も重要なアクション | 塗りつぶし、高コントラスト、最も目立つ |
|
||||
| **Secondary** | サポート的なアクション | アウトラインまたは一段低い強調 |
|
||||
| **Tertiary / Text** | 弱い操作 | テキストまたは低い視覚的比率 |
|
||||
| **Destructive** | 削除、無効化、クリアなどのリスク操作 | 警告色または明確なリスクスタイル |
|
||||
| **Icon button** | 局所的なツール操作 | シンプル、コンテキストに近い |
|
||||
|
||||
### 4.2 1つのページにPrimary Buttonを多く置かない
|
||||
|
||||
これは多くの初心者が最も陥りやすい落とし穴です。
|
||||
|
||||
ページに4つのメインボタンがある場合、それはメインボタンがないのと同じです。メインボタンの意義は本来「ユーザーに今何をすべきかを伝える」ことです。
|
||||
|
||||
多くのデザインシステムの共通するアプローチを参考にできます：
|
||||
|
||||
- 1つの主要エリアには通常1つのメインボタンのみ残す
|
||||
- キャンセル、戻る、閉じるは通常、確認ボタンと同じレベルを争わない
|
||||
- その他の操作はセカンダリボタンやメニューに配置する
|
||||
|
||||
### 4.3 ボタンは状態変化を表現できなければならない
|
||||
|
||||
デザインガイドラインは通常、ボタンの状態について詳細に記述しています：
|
||||
|
||||
- デフォルト状態
|
||||
- ホバー状態
|
||||
- フォーカス状態
|
||||
- 無効状態
|
||||
- ローディング状態
|
||||
- 危険状態
|
||||
|
||||
これは重要です。なぜならボタンは静的な画像ではなく、ユーザーの操作過程で最も頻繁にトリガーされるコントロールの一つだからです。
|
||||
|
||||
### 4.4 ボタンテキストもデザインの一部
|
||||
|
||||
ボタンテキストは単なる「テキストの問題」ではなく、ユーザーの理解に直接影響します。
|
||||
|
||||
例えば：
|
||||
|
||||
- `保存`
|
||||
- `変更を保存`
|
||||
- `今すぐ公開`
|
||||
- `プロジェクトを削除`
|
||||
- `ゴミ箱に移動`
|
||||
|
||||
これらのテキストが伝える心理的期待は全く異なります。成熟したガイドラインは通常、ボタンラベルが明確にアクションを表現することを求め、曖昧な言葉の使用を避けます。
|
||||
|
||||
## 5. 非常に実用的なページとボタンの設計チェックリスト
|
||||
|
||||
自分でページを設計する際、まずこのチェックリストをざっと見てみましょう：
|
||||
|
||||
### ページチェックリスト
|
||||
|
||||
- ページタイトルが現在のタスクを明確に説明しているか
|
||||
- ファーストビューの最も重要な情報が一目で見えるか
|
||||
- ページがタスクフローに沿って組織されており、思いついたものを配置しただけではないか
|
||||
- 同じエリアにメインアクションが1つだけか
|
||||
- 補助情報が適切に弱められているか
|
||||
|
||||
### ボタンチェックリスト
|
||||
|
||||
- このボタンはメインアクションかセカンダリアクションか
|
||||
- なぜ他のボタンより目立つ価値があるのか
|
||||
- ページ内にメインボタンが多すぎないか
|
||||
- 危険な操作が明確にマークされているか
|
||||
- ボタンテキストは十分に具体的か
|
||||
|
||||
## 6. AIに他人のガイドラインを参考にページを設計させる方法
|
||||
|
||||
このセクションが最も実用的です。
|
||||
|
||||
多くの人がAIにページを設計させる際、こう言うだけです：
|
||||
|
||||
```md
|
||||
設定ページを作って、もう少し高級に、Apple風でお願いします
|
||||
```
|
||||
|
||||
この種のプロンプトは曖昧すぎて、AIは結局「白い背景、角丸、シャドウ」を模倣するしかありません。
|
||||
|
||||
初心者にとってより実用的な方法は、自分で長い文章をまとめるのではなく、**ガイドライン原文の重要な一文**を直接AIに貼り付けることです。
|
||||
|
||||
これには2つの利点があります：
|
||||
|
||||
- 自分で先にデザイン思想を「翻訳」する必要がない
|
||||
- AIが公式定義に沿ってページやボタンを理解しやすくなる
|
||||
|
||||
### 6.1 例1：AIにAppleを参考に設定ページを設計させる
|
||||
|
||||
まずAppleの原文を見つけます：
|
||||
|
||||
> ["Establish a clear visual hierarchy..."](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
|
||||
AIに次のように直接貼り付けます：
|
||||
|
||||
```md
|
||||
Apple Human Interface Guidelinesのこの一文を参考に：
|
||||
"Establish a clear visual hierarchy..."
|
||||
|
||||
アカウントセキュリティ設定ページを設計してください。
|
||||
ページ階層を明確にし、重要な情報を前に配置し、グループを整然とさせてください。
|
||||
```
|
||||
|
||||
この書き方のポイントは、自分で説明しすぎず、Appleの原文を直接貼り付けることです。
|
||||
|
||||
### 6.2 例2：AIにFluentを参考にバックエンドページのボタンを設計させる
|
||||
|
||||
まずFluentの原文を見つけます：
|
||||
|
||||
> ["Only use one primary button in a layout..."](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
|
||||
AIに次のように直接貼り付けます：
|
||||
|
||||
```md
|
||||
Fluent 2のこの一文を参考に：
|
||||
"Only use one primary button in a layout..."
|
||||
|
||||
チーム管理バックエンドのボタンを設計してください。
|
||||
メンバー追加ボタンを最も目立たせ、エクスポート、フィルター、その他の操作は弱め、削除ボタンは単独で目立たせてください。
|
||||
```
|
||||
|
||||
この一文は初心者に非常に適しています。なぜなら、AIに1つのエリアにメインボタンを多く置かないよう直接伝えるからです。
|
||||
|
||||
### 6.3 例3：AIにページガイドラインとボタンガイドラインを同時に参考にさせる
|
||||
|
||||
原文を2つ同時に貼り付け、AIにページとボタンの両方を参考にさせることもできます：
|
||||
|
||||
> Apple: ["Establish a clear visual hierarchy..."](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
>
|
||||
> Fluent: ["Only use one primary button in a layout..."](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
|
||||
次のように直接書きます：
|
||||
|
||||
```md
|
||||
以下の2つのデザインガイドライン原文を参考に：
|
||||
Apple: "Establish a clear visual hierarchy..."
|
||||
Fluent: "Only use one primary button in a layout..."
|
||||
|
||||
プロジェクト詳細ページを設計してください。
|
||||
ページにはプロジェクト紹介、メンバー、最近のアクティビティ、設定への入り口を含めます。
|
||||
ページ階層を明確にし、メインボタンは1つだけ残し、他のボタンは弱めてください。
|
||||
```
|
||||
|
||||
この方法は初心者に特に適しています。原文をコピーして、自分の要件を2文追加するだけで十分だからです。
|
||||
|
||||
## 7. AIにボタンガイドラインを参考に直接ボタンデザインを生成させる方法
|
||||
|
||||
まずボタンだけを作りたい場合は、ボタンガイドラインの原文を直接貼り付けることもできます。
|
||||
|
||||
例えば、Atlassianのボタンの定義は非常に短いです：
|
||||
|
||||
> ["A button triggers an event or action."](https://atlassian.design/components/button/)
|
||||
|
||||
AIに次のように問いかけます：
|
||||
|
||||
```md
|
||||
Atlassianのこの一文を参考に：
|
||||
"A button triggers an event or action."
|
||||
|
||||
バックエンドページのボタンスタイルセットを設計してください。
|
||||
メインボタン、セカンダリボタン、削除ボタンが必要で、それぞれどこで使うかも教えてください。
|
||||
```
|
||||
|
||||
この種のプロンプトは特に初心者に適しており、基本的に「原文を貼る + 要件を言う」だけです。
|
||||
|
||||
## 8. まとめ
|
||||
|
||||
UIデザインガイドラインを参考にページやボタンを設計する際、最も重要なのは「誰かに似せる」ことではなく、以下のことを学ぶことです：
|
||||
|
||||
1. 階層でページを組織し、コンテンツを積み上げない
|
||||
2. ボタンのランク付けで操作の優先度を表現し、すべてのボタンを同じように目立たせない
|
||||
3. デザインガイドラインの定義、境界、判断基準で設計をガイドする
|
||||
4. AIに他人のガイドラインを参考にさせる際、「原則と構造」を参考にし、スキンだけを参考にしない
|
||||
|
||||
このようにガイドラインを使うことで、参考にするのは単なるスタイルではなく、成熟したデザイン思考の方法論になります。
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
以下のリンクはすべて公式デザインシステムまたは公式ドキュメントからのものです：
|
||||
|
||||
- Apple Human Interface Guidelines: [Overview](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
- Apple Human Interface Guidelines: [Menus](https://developer.apple.com/design/human-interface-guidelines/menus)
|
||||
- Apple Human Interface Guidelines: [Alerts](https://developer.apple.com/design/human-interface-guidelines/alerts)
|
||||
- Apple Human Interface Guidelines: [Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons)
|
||||
- Apple Archive: [How Menus Work](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/HowMenusWork.html)
|
||||
- Apple Archive: [Managing Pop-Up Buttons and Pull-Down Lists](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html)
|
||||
- Material Design: [Buttons overview](https://m3.material.io/components/buttons/overview)
|
||||
- Material Design: [Menus](https://m1.material.io/components/menus.html)
|
||||
- Microsoft Fluent 2: [Start designing](https://fluent2.microsoft.design/get-started/design)
|
||||
- Microsoft Fluent 2: [Menu usage](https://fluent2.microsoft.design/components/web/react/core/menu/usage)
|
||||
- Microsoft Fluent 2: [Button usage](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
- Atlassian Design System: [Foundations](https://atlassian.design/foundations/)
|
||||
- Atlassian Design System: [Button](https://atlassian.design/components/button/)
|
||||
@@ -0,0 +1,3 @@
|
||||
# 初めてのモダンアプリ - UIデザイン
|
||||
|
||||
> この章は現在執筆中です。お楽しみに...
|
||||
+152
-174
@@ -1,6 +1,6 @@
|
||||
# フルスタック開発
|
||||
# 初中级開発
|
||||
|
||||
**フルスタック開発**ステージへようこそ！ここでは、フロントエンドのコンポーネント化、データベース設計、バックエンドAPI開発、デプロイメントをマスターし、フルスタック開発に深く掘り下げます。
|
||||
**初中級開発**ステージへようこそ！ここでは、フロントエンドのコンポーネント化、データベース設計、バックエンドAPI開発、デプロイメントをマスターし、フルスタック開発に深く掘り下げます。
|
||||
|
||||
## 学べること
|
||||
|
||||
@@ -9,141 +9,172 @@
|
||||
モダンなフロントエンド開発をマスターし、コンポーネントライブラリとデザインツールの使用方法を学ぶ：
|
||||
|
||||
<NavGrid>
|
||||
<a href="/ja-jp/stage-2/frontend/figma-mastergo/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🖼️</span>
|
||||
<span class="card-title">フロントエンド1</span>
|
||||
</div>
|
||||
<div class="card-desc">FigmaとMasterGo入門</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/frontend/ui-design/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">✨</span>
|
||||
<span class="card-title">フロントエンド2</span>
|
||||
</div>
|
||||
<div class="card-desc">初めてのモダンアプリ - UIデザイン</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/frontend/multi-product-ui/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">📐</span>
|
||||
<span class="card-title">フロントエンド3</span>
|
||||
</div>
|
||||
<div class="card-desc">UIデザインガイドラインとマルチプロダクト</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/frontend/hogwarts-portraits/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🧙</span>
|
||||
<span class="card-title">フロントエンド4</span>
|
||||
</div>
|
||||
<div class="card-desc">ホグワーツ肖像画を作ろう</div>
|
||||
</div>
|
||||
</a>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/lovart-assets/"
|
||||
title="Lovartから始めよう：自分だけの素材生成Agentを構築"
|
||||
description="NanobananaとLovartを使って高品質なデザイン素材を一括生成し、意図理解ができる描画Agentを構築する"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/figma-mastergo/"
|
||||
title="FigmaとMasterGo入門"
|
||||
description="プロのUIデザインツールの基本操作をマスターし、デザインからコードへの協業フローを学ぶ"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/ui-design/"
|
||||
title="初めてのモダンアプリ - UIデザイン"
|
||||
description="モダンアプリケーションのUIデザイン基礎を学ぶ"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/multi-product-ui/"
|
||||
title="UIデザインガイドラインを参考にページとボタンを設計"
|
||||
description="主要なUIデザインガイドラインを学び、より明確なページ階層とボタン階層を設計する"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/llm-skills-beautiful/"
|
||||
title="LLMとSkillsで美しいインターフェースを実現"
|
||||
description="プロンプトとプラグインの実践を通じて、AIが美しくユニークなインターフェースを生成する"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/hogwarts-portraits/"
|
||||
title="ホグワーツ肖像画を作ろう"
|
||||
description="実践プロジェクト：AI生成画像を組み合わせて、インタラクティブなホグワーツ肖像画アプリを構築する"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/design-to-code/"
|
||||
title="デザインプロトタイプからプロジェクトコードへ"
|
||||
description="デザインツールのプロトタイプをブラウザで動くフロントエンドコードに変換する方法を学ぶ"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/frontend/modern-component-library/"
|
||||
title="モダンコンポーネントライブラリでUIをアップデート"
|
||||
description="コンポーネントライブラリを使ってプロフェッショナルなインターフェースを素早く構築する方法を学ぶ"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### バックエンドとフルスタック
|
||||
### バックエンド開発
|
||||
|
||||
API設計、データベース管理、アプリケーションデプロイメント戦略を学ぶ：
|
||||
|
||||
<NavGrid>
|
||||
<a href="/ja-jp/stage-2/backend/database-supabase/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🗄️</span>
|
||||
<span class="card-title">バックエンド2</span>
|
||||
</div>
|
||||
<div class="card-desc">データベースからSupabaseへ</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/backend/ai-interface-code/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🤖</span>
|
||||
<span class="card-title">バックエンド3</span>
|
||||
</div>
|
||||
<div class="card-desc">AI支援インターフェースコードとドキュメント</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/backend/git-workflow/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🌿</span>
|
||||
<span class="card-title">バックエンド4</span>
|
||||
</div>
|
||||
<div class="card-desc">Gitワークフロー</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/backend/zeabur-deployment/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🚀</span>
|
||||
<span class="card-title">バックエンド5</span>
|
||||
</div>
|
||||
<div class="card-desc">Zeaburデプロイメント</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/backend/modern-cli/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">💻</span>
|
||||
<span class="card-title">バックエンド6</span>
|
||||
</div>
|
||||
<div class="card-desc">モダンCLI開発ツール</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a href="/ja-jp/stage-2/backend/stripe-payment/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">💳</span>
|
||||
<span class="card-title">バックエンド7</span>
|
||||
</div>
|
||||
<div class="card-desc">Stripe決済システムの統合</div>
|
||||
</div>
|
||||
</a>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/backend/git-workflow/"
|
||||
title="GitとGithubを使いこなそう"
|
||||
description="Gitバージョン管理システムの核心的な操作と協業フローをマスターする"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/backend/database-supabase/"
|
||||
title="データベースからSupabaseへ"
|
||||
description="リレーショナルデータベースの基礎をマスターし、モダンなBaaSプラットフォームであるSupabaseの使い方を学ぶ"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/backend/ai-interface-code/"
|
||||
title="バックエンドAPIの設計と開発"
|
||||
description="AIを活用してバックエンドAPIコードと標準的なAPIドキュメントを自動生成し、開発効率を向上させる"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/backend/zeabur-deployment/"
|
||||
title="プロダクトプロトタイプを公開しよう"
|
||||
description="Zeaburを使ってフルスタックアプリをクラウドに素早くデプロイする方法を学ぶ"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/backend/modern-cli/"
|
||||
title="IDEからCLI AIプログラミングツールへ"
|
||||
description="モダンなCLIツールを探索し、コマンドライン環境での開発体験を向上させる"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/backend/stripe-payment/"
|
||||
title="Stripeなどの決済システムを統合するには"
|
||||
description="実践：アプリケーションにStripe決済機能を統合し、ビジネス化・マネタイズを実現する"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### 課題
|
||||
### 大規模課題
|
||||
|
||||
実践プロジェクトを通じてフルスタック開発スキルを固める：
|
||||
前の章では「パーツ」を学んでいましたが、大規模課題では「パーツを組み立てて動く、デモできる、公開できるプロダクトにする方法」を学びます。
|
||||
|
||||
**大規模課題 1 → 大規模課題 2** の順序で進めることをお勧めします：
|
||||
|
||||
- **大規模課題 1** では、モダンSaaSで最も一般的なメインフローを一通り体験します：ログイン、生成、データベース、決済、管理画面。
|
||||
- **大規模課題 2** では、より業務システムに近いシナリオに進みます：ロール権限、問題バンク、試験、提出記録、管理コンソール。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["フロントエンドページとコンポーネント"] --> B["データベースとAPI"]
|
||||
B --> C["大規模課題 1<br/>コピー生成 SaaS"]
|
||||
C --> D["決済 / デプロイ / 管理画面"]
|
||||
D --> E["大規模課題 2<br/>オンライン試験システム"]
|
||||
E --> F["完全なフルスタックポートフォリオ"]
|
||||
```
|
||||
|
||||
どちらから始めるべきか迷った場合は、以下の比較表を参考にしてください：
|
||||
|
||||
| プロジェクト | 重点的に練習できる内容 | 最も適している人 | 最終成果物 |
|
||||
|------|------|------|------|
|
||||
| 大規模課題 1：コピー生成サイト | SaaSページ構造、ユーザーログイン、AI生成、Stripe決済、管理画面 | 初めて完全なビジネス向けサイトを作る人 | 登録・生成・決済・管理ができるSaaSのプロトタイプ |
|
||||
| 大規模課題 2：オンライン試験・管理システム | ロール権限、問題バンクのモデリング、試験フロー、提出記録、採点と統計 | 「業務システム」を本当に完成させたい人 | 学生用と管理用の両方がある試験プラットフォーム |
|
||||
|
||||
どちらの課題を選ぶ場合でも、大規模課題では少なくとも以下の3つの成果物を用意することをお勧めします：
|
||||
|
||||
- 実行可能なプロジェクトリポジトリ
|
||||
- アクセス可能なデモリンク
|
||||
- READMEとデモ動画
|
||||
|
||||
<NavGrid>
|
||||
<a href="/ja-jp/stage-2/assignments/modern-frontend-trae/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🎯</span>
|
||||
<span class="card-title">課題2</span>
|
||||
</div>
|
||||
<div class="card-desc">モダンフロントエンド + Trae</div>
|
||||
</div>
|
||||
</a>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/copywriting-platform-supabase/"
|
||||
title="大規模課題 1：初めてのSaaSフルスタックアプリ——コピー生成サイト"
|
||||
description="ゼロからAIマーケティングコピー生成ワークベンチを構築。ログイン、生成、決済、管理画面を網羅"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/exam-management-express/"
|
||||
title="大規模課題 2：オンライン試験・管理システム"
|
||||
description="オンライン試験システムを構築。自動出題、解答、管理画面をサポート"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
上記2つのメインプロジェクトを完了した後、または自分の技術分野に合わせてポートフォリオを作りたい場合は、以下の拡張課題から1つを選んで深く取り組むことができます：
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/modern-landing-page/"
|
||||
title="拡張課題：モダンWebランディングページエンジニアリング"
|
||||
description="価値表現、コンバージョンパス、CTA設計と基本的なトラッキングを実践し、本当にトラフィックを獲得できるページを作る"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/custom-dify-agent-platform/"
|
||||
title="拡張課題：Dify風AIエージェントオーケストレーションプラットフォーム"
|
||||
description="エージェント管理、対話、ログと権限制御を実装し、最小限で使えるAIプラットフォームを作る"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/travel-planning-agent-platform/"
|
||||
title="拡張課題：スマート旅行計画Agentオーケストレーションプラットフォーム"
|
||||
description="構造化入力、Agentオーケストレーション、過去の計画管理を中心に、実行可能なAI旅行計画プロダクトを作る"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/movie-recommendation-springboot/"
|
||||
title="拡張課題：Spring Boot映画推薦システム"
|
||||
description="Spring Boot、レーティング・お気に入り、説明可能な推薦を組み合わせて、完全な推薦システムのプロトタイプを完成させる"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/simple-grocery-microservices/"
|
||||
title="拡張課題：生鮮ECマイクロサービスシステム"
|
||||
description="サービス分割、ゲートウェイ転送、在庫と注文の連携を練習し、モノリスからマイクロサービスへのエンジニアリング思考を体験する"
|
||||
/>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/assignments/traffic-data-visualization-go/"
|
||||
title="拡張課題：Go交通データ分析・可視化プラットフォーム"
|
||||
description="データ収集、ウィンドウ集計からトレンドダッシュボードとアラートまで、完全なデータプロダクトのプロトタイプを作る"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### AI機能拡張
|
||||
|
||||
<NavGrid>
|
||||
<a href="/ja-jp/stage-2/ai-capabilities/multimodal-api/" class="card-link">
|
||||
<div class="content-card">
|
||||
<div class="card-header">
|
||||
<span class="card-icon">🎭</span>
|
||||
<span class="card-title">AI 2</span>
|
||||
</div>
|
||||
<div class="card-desc">AI辞書クエリとマルチモーダルAPI</div>
|
||||
</div>
|
||||
</a>
|
||||
<NavCard
|
||||
href="/ja-jp/stage-2/ai-capabilities/dify-knowledge-base/"
|
||||
title="Dify入門とナレッジベース統合"
|
||||
description="Difyを使ってAIアプリケーションを構築し、プライベートナレッジベースを統合する方法を学ぶ"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
## 対象者
|
||||
@@ -160,56 +191,3 @@ API設計、データベース管理、アプリケーションデプロイメ
|
||||
- AIプログラミングツールについて予備的な知識を持っている
|
||||
|
||||
フルスタック開発に深く掘り下げる準備はできましたか？左のナビゲーションをクリックして学習を始めましょう！
|
||||
|
||||
<style>
|
||||
.content-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
|
||||
gap: 16px;
|
||||
margin: 20px 0;
|
||||
}
|
||||
|
||||
.card-link {
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
display: block;
|
||||
}
|
||||
|
||||
.content-card {
|
||||
background: var(--vp-c-bg-soft);
|
||||
border: 1px solid var(--vp-c-divider);
|
||||
border-radius: 12px;
|
||||
padding: 20px;
|
||||
transition: all 0.3s ease;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.content-card:hover {
|
||||
transform: translateY(-4px);
|
||||
box-shadow: 0 8px 24px rgba(0, 0, 0, 0.1);
|
||||
border-color: var(--vp-c-brand);
|
||||
}
|
||||
|
||||
.card-header {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 12px;
|
||||
margin-bottom: 12px;
|
||||
}
|
||||
|
||||
.card-icon {
|
||||
font-size: 24px;
|
||||
}
|
||||
|
||||
.card-title {
|
||||
font-weight: 600;
|
||||
font-size: 16px;
|
||||
color: var(--vp-c-text-1);
|
||||
}
|
||||
|
||||
.card-desc {
|
||||
font-size: 14px;
|
||||
color: var(--vp-c-text-2);
|
||||
line-height: 1.5;
|
||||
}
|
||||
</style>
|
||||
|
||||
Reference in New Issue
Block a user