docs: stage-1 i18n coverage + news
This commit is contained in:
sanbuphy
@@ -0,0 +1,82 @@
|
||||
# プロジェクト紹介
|
||||
|
||||
2025年は、多くの人にとってAIプログラミングの元年と呼ばれています。AIを使ってコードを書く人が増えていますが、その多くはまだおもちゃレベルにとどまっています。Vibe Codingで開発プロセスをどう組むか、どのツールを選ぶべきか、プロトタイプから本番運用までに何が足りないのか、わからないことが多いでしょう。
|
||||
|
||||
私たちは段階的な**三段階の実践パス**を採用しています。初心者向けステージではミニゲームでAIプログラミングに素早く慣れ、第一段階ではVibe Codingのワークフローを身につけWebアプリケーションのプロトタイプを完成させ、第二段階ではフルスタック開発とデプロイを学び、第三段階ではクロスプラットフォームの複雑なアプリケーションを構築します。
|
||||
|
||||
各ステージには完全なプロジェクト実践が含まれており、実際の課題の中でおもちゃから製品へと進化し、最終的に**どんなアイデアも実用アプリとして具現化する能力**を身につけます。
|
||||
|
||||
私たちは、Vibe Codingをマスターし、体系的なトレーニングを積めば、一人で**フロントエンド・バックエンド開発、AI能力の統合、プロダクトデザインを兼ね備えたオールラウンド開発者**になれると信じています。
|
||||
|
||||
本プロジェクトは主に3種類の学習者を対象としています：
|
||||
|
||||
- **初心者（一般の方 / プロダクト・運営側）**：非技術背景の方や入門学習者が重要な概念を理解し、最初のAI小ツールやプロダクトプロトタイプを完成させるのを支援します。
|
||||
- **初中級開発者（基礎のある学生や開発者）**：vibe codingとネイティブAIアプリケーション開発を体系的に習得します。
|
||||
- **上級開発者（企業・スタートアップ、オープンソース・独立開発者）**：チームや個人がネイティブAIアプリケーションを迅速に構築・検証・反復できるよう支援します。
|
||||
|
||||
## 📖 コンテンツナビゲーション
|
||||
|
||||
### 総付録
|
||||
|
||||
[AI能力辞典：一般的なAIコア概念と用語、シナリオの解説](/ja-jp/appendix/8-artificial-intelligence/ai-capability-dictionary)
|
||||
|
||||
### ゼロ、ようちえん
|
||||
|
||||
| 章节 | キーコンテンツ | 状態 |
|
||||
| :--- | :--- | :--- |
|
||||
| [初心者向け：学習マップ](/ja-jp/stage-1/learning-map/) | 全体学習パスガイド | ✅ |
|
||||
| [初心者向け：AI時代、話せばプログラミング](/ja-jp/stage-1/ai-capabilities-through-games/) | 貪食蛇などのケースでAIプログラミングの能力を初体験 | ✅ |
|
||||
|
||||
### 一、AIプロダクトマネージャー
|
||||
|
||||
| 章节 | キーコンテンツ | 状態 |
|
||||
| :--- | :--- | :--- |
|
||||
| [初級二：AI IDEツールを知る](/ja-jp/stage-1/introduction-to-ai-ide/) | IDEの使い方を学び、インターフェース構造と効率的なプロンプト方法を習得 | ✅ |
|
||||
| [初級三：プロトタイプを作る](/ja-jp/stage-1/building-prototype/) | プロダクト分析の分解から、マルチページプロダクトプロトタイプ実装までの完全ループ | ✅ |
|
||||
| [初級四：プロトタイプにAI能力を追加](/ja-jp/stage-1/integrating-ai-capabilities/) | 一般的なAI能力（テキスト・画像・動画）のAPI導入を理解し完了 | ✅ |
|
||||
| [初級五：完全プロジェクト実践](/ja-jp/stage-1/complete-project-practice/) | 実シナリオのシミュレーション、ユーザーフィードバックの反復とプロジェクト発表（課題あり） | ✅ |
|
||||
|
||||
#### 付録
|
||||
|
||||
| 章节 | キーコンテンツ | 状態 |
|
||||
| :--- | :--- | :--- |
|
||||
| [付録A：プロダクト思考補足](/ja-jp/stage-1/appendix-a-product-thinking/) | アイデア評価からニーズ分解、MVPまでのプロダクト思考フレームワーク | ✅ |
|
||||
| [付録B：よくあるエラーと解決策](/ja-jp/stage-1/appendix-b-common-errors/) | vibe codingでのよくあるエラーとトラブルシューティング方法 | ✅ |
|
||||
| [付録：アイデアの探し方](/ja-jp/stage-1/appendix-idea-sources/) | 参考アプリ、トレンド、VCリストから細分化方向を見つける | ✅ |
|
||||
| [付録：ダブルダイヤモンドモデル](/ja-jp/stage-1/appendix-double-diamond/) | まず問題を定義し、それからソリューション設計を展開する完全リズムを理解 | ✅ |
|
||||
| [付録：Jobs to Be Done](/ja-jp/stage-1/appendix-jobs-to-be-done/) | JTBD手法でユーザーが本当に達成したいことを見極める | ✅ |
|
||||
| [付録：The Mom Testユーザーインタビュー法](/ja-jp/stage-1/appendix-mom-test/) | ユーザーインタビューを通じてニーズを検証する調査方法 | ✅ |
|
||||
|
||||
### 二、初中級開発エンジニア
|
||||
|
||||
#### フロントエンド部分
|
||||
|
||||
| 章节 | キーコンテンツ | 状態 |
|
||||
| :--- | :--- | :--- |
|
||||
| lovartで素材制作 | lovartを使って人物、シーンなどのビジュアル素材を一括生成し、UIデザインとフロントエンド開発に素材基盤を提供 | 🚧 |
|
||||
| FigmaとMasterGo入門 | デザインツールで情報アーキテクチャとページ構造を整理し、フロントエンド実装の基盤を作る | 🚧 |
|
||||
| 最初のモダンアプリケーション構築 - UIデザイン | デザインカンプに基づいてコンポーネント化インターフェースを完成し、デザインからコードへの最初のリンクを実現 | 🚧 |
|
||||
| UIデザイン仕様を参考にページとボタンを設計 | 主要なデザイン仕様を使ってページ構造、ボタン階層を整理し、AIでデザイン案を生成する方法を学ぶ | 🚧 |
|
||||
| [ホグワーツの肖像画を一緒に作ろう](/ja-jp/stage-2/frontend/hogwarts-portraits/) | ゼロからAI能力を組み込んだフロントエンドアプリを作り、デザインと開発を連携させる | 🚧 |
|
||||
|
||||
#### バックエンド開発部分
|
||||
|
||||
| 章节 | キーコンテンツ | 状態 |
|
||||
| :--- | :--- | :--- |
|
||||
| APIとは何か | HTTPインターフェースとリクエスト・レスポンスモデルを理解し、バックエンド統合と連携の準備 | 🚧 |
|
||||
| [データベースからSupabaseまで](/ja-jp/stage-2/backend/database-supabase/) | SupabaseでデータベースとAPIを構築し、データモデルとフロントエンドページを接続 | 🚧 |
|
||||
| 大規模モデルでインターフェースコードとドキュメントを支援 | 大規模モデルでインターフェースとデータベースのドキュメントおよびコードを生成し、読みやすくテスト可能なバックエンドを実現 | 🚧 |
|
||||
| GitワークフローとZeaburデプロイ | Gitワークフローでコードを管理し、アプリケーションをZeaburにデプロイして公開 | 🚧 |
|
||||
| モダンCLI開発ツール | CLI系AIプログラミングツールで開発とデバッグを加速し、個人のエンジニアリングワークフローを形成 | 🚧 |
|
||||
| stripeなどの決済システムの統合方法 | 決済システムを導入し、課金フローと基本決済プロセスを完了 | 🚧 |
|
||||
| 最初のモダンアプリケーション構築 - フルスタックアプリ | フロントエンド、バックエンド、決済モジュールを統合し、デプロイ可能なフルスタックWebアプリを完成 | 🚧 |
|
||||
| モダンフロントエンドコンポーネントライブラリ + Trae実戦 | モダンフロントエンドコンポーネントライブラリとTraeを使い、ログイン登録と課金対応のプロダクトを独立して完成 | 🚧 |
|
||||
|
||||
#### AI能力付録
|
||||
|
||||
| 章节 | キーコンテンツ | 状態 |
|
||||
| :--- | :--- | :--- |
|
||||
| [Dify入門とナレッジベース統合](/ja-jp/stage-2/ai-capabilities/dify-knowledge-base/) | Dify Workflowと基本RAGでツール系プロダクトを構築し、今後のアプリアップグレードのサンプルを作成 | 🚧 |
|
||||
| AI辞典の調べ方とマルチモーダルAPIの統合を学ぶ | 適切なモデルとAPIの調べ方を学び、テキスト、画像などのマルチモーダル能力をプロダクトに組み込む | 🚧 |
|
||||
|
||||
### 三、上級開発エンジニア
|
||||
@@ -0,0 +1 @@
|
||||
../../../zh-cn/stage-1/ai-capabilities-through-games/images
|
||||
@@ -0,0 +1,765 @@
|
||||
# 初級一：AI 時代、話せるならプログラミングできる
|
||||
|
||||
これは**プロジェクトベースの学習**チュートリアルです。ステップに沿って操作し、結果を再現してみましょう。
|
||||
間違えても気にしないでください。私たちはあなたができると信じています。常に覚えておいてください：
|
||||
|
||||
<div style="text-align: center;">
|
||||
<div style="display: inline-block; padding: 8px 20px; border-radius: 8px; border: 1px dashed #FFB6C1; background: linear-gradient(135deg, #FFF0F5 0%, #FFE4EC 100%); margin: 12px 0;">
|
||||
<span style="font-size: 15px; font-weight: 500; color: #666;">完成は完璧より重要 🐣</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>4 時間</strong>、複数回に分けて完了可能'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['zh-cn/stage-1/ai-capabilities-through-games'] ?? []
|
||||
</script>
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['対話型 AI プログラミング', 'AI ネイティブミニゲーム', 'スネークゲーム実践']" coreOutput="AI ネイティブスネークゲーム + 自作ミニゲーム" expectedOutput="1つの動作する AI ネイティブスネークゲーム +（オプション）1つの自作 AI ネイティブミニゲームまたはデモ">
|
||||
|
||||
<strong>完全にプログラミングができない</strong>、あるいは少ししか知らない場合、この章はあなたのために用意されています。最も基礎的なところから始めます：<strong>対話方式で</strong>AI にコードを書かせます。構文を覚える必要はなく、環境設定も不要で、Web ページ上で直接実行できます。
|
||||
|
||||
最初の<strong>動作するプログラム</strong>——「単語を食べ、詩を書き、絵を描く」スネークゲームを自分で作ります。この実践を通じて、AI プログラミングが実際にどのようなものかを体験します。AI があなたの思考を代わりにするのではなく、あなたがアイデアを言葉にし、AI がそれを実現してくれます。
|
||||
|
||||
すべての創造は 0 から 1 へのスタートです。あなたに自信と専門性を伝えられたら嬉しいです。あなたにとっては、<strong>実行力 is all you need</strong>。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '課題と機会', description: '一般人のプログラミングの新たな可能性' },
|
||||
{ title: '能力の初探', description: '60秒の高速開発体験' },
|
||||
{ title: 'ネイティブ実践', description: 'AI ネイティブスネークゲームを作る' },
|
||||
{ title: '創造の拡張', description: '応用してゲームを作る' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 一般人の課題と機会
|
||||
|
||||
多くの人は頭の中にたくさんのプロダクトアイデアを持っています：家計簿ツール、子供の成長を記録するウェブページ、あるいは小さなゲームなど。しかし、コードを書いたりプログラマーを探したりすることを考えると、すぐに諦めてしまいます。
|
||||
|
||||
AI の登場により、初めて一般人に全く新しい可能性がもたらされました。コードを書く必要はなく、AI に自分が欲しいものを明確に伝えるだけでいいのです。GitHub Copilot からの[データ](https://www.wearetenet.com/blog/github-copilot-usage-data-statistics)によると、1500万人以上の開発者が AI 補助プログラミングを使用しており、平均46%のコードが AI によって生成されています。Java プロジェクトではこの割合は61%に達します。
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="display: flex; align-items: center; gap: 8px;">
|
||||
<span style="font-size: 20px;">🚀</span>
|
||||
<span style="font-weight: bold; font-size: 16px;">効率と採用率の飛躍</span>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<el-row :gutter="20" style="margin-bottom: 24px;">
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #409EFF; font-size: 24px; font-weight: bold;">55%</div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">速度の向上</div>
|
||||
</div>
|
||||
</el-col>
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #67C23A; font-size: 24px; font-weight: bold;">2.4 <span style="font-size: 14px;">日</span></div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">タスク所要時間（元9.6日）</div>
|
||||
</div>
|
||||
</el-col>
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #E6A23C; font-size: 24px; font-weight: bold;">81%</div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">初日のインストール率</div>
|
||||
</div>
|
||||
</el-col>
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #F56C6C; font-size: 24px; font-weight: bold;">96%</div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">提案採用率</div>
|
||||
</div>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
<div style="line-height: 1.8; color: #606266;">
|
||||
本当に興奮するのは効率の飛躍です：開発者がタスクを完了する速度が <b>55%</b> 向上しました。元々 9.6 日かかっていたコードの提出が、今では <b>2.4 日</b>で完了します。この目に見える効率の向上は、AI がもはや「オプションツール」ではなく、開発プロセスに不可欠なプログラミングアシスタントになりつつあることを示しています。採用率のデータもこれを裏付けています：アクセス権を取得した当日、<b>81%</b> の開発者が最初のうちにインストールを完了し、使用を開始しました。そのうち <b>96%</b> が当日に AI が提供するコード提案を採用しました。つまり、開発者はほぼ即座に AI を日常のコーディング作業に統合しているのです。
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
一般人にとって、このトレンドはさらに意義があります：プロのプログラマーでさえ大量に AI に依存してコードを書いているなら、**プログラミングのできない私たちが、なぜ AI と対話して自分のアイデアを実現できないのでしょうか？**
|
||||
|
||||
このコースの目標は、あなたに新しいスキルを習得させることです：自然言語の対話でアプリケーションを作れるようになります。コンピュータの言葉で AI とコミュニケーションする方法、AI に頭の中のアイデアを実用的なプロダクトにする方法を教えます。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: '課題と機会', description: '一般人のプログラミングの新たな可能性' },
|
||||
{ title: '能力の初探', description: '60秒の高速開発体験' },
|
||||
{ title: 'ネイティブ実践', description: 'AI ネイティブスネークゲームを作る' },
|
||||
{ title: '創造の拡張', description: '応用してゲームを作る' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. AI はどこまでできるか
|
||||
|
||||
このセクションでは、一つの問題だけを議論します：プログラミングが全くできない場合、現在の AI はどこまでできるのでしょうか？
|
||||
|
||||
大まかに言えば、現在の大規模モデルの能力は次のように理解できます：**シンプルな社内ツール**、**データ可視化ダッシュボード**、および一部の**軽量ミニゲーム**の開発に対応できます。これらの能力は、**個人用ツール**の作成や、**プロダクトマネージャーの視点からのニーズ検証**には基本的に十分です。ただし、ワンクリックで**商用レベルの完成品**を生成したい場合、通常は**プロセス設計**や**ディテールの仕上げ**において人手による継続的な最適化が必要です。
|
||||
|
||||
次に、スネークゲームを例に、AI プログラミングが現在どこまでできるかを具体的に見てみましょう。
|
||||
|
||||
### 2.1 60秒でスネークゲームを作る
|
||||
|
||||
まず、コースで使用する実験用ウェブページ [z.ai](https://chat.z.ai/) を開いてください。`z.ai` は智譜 AI（中国を代表する大規模言語モデル企業の一つ）が開発した AI プラットフォームで、その中核能力は智譜が自社開発した GLM シリーズの大規模モデルによって支えられています。このプラットフォームはスライド生成、ポスターデザイン、フルスタック開発など、複数の AI 機能を統合しています。このチュートリアルでは、そのフルスタック開発モジュールの使用に焦点を当てます。
|
||||
|
||||
::: details 💡 「Web ページでプログラミングできる」とは？
|
||||
|
||||
過去、Web アプリケーションを開発するには：
|
||||
- プログラミング環境のインストール（Python、Node.js など）
|
||||
- コードエディタの設定
|
||||
- HTML/CSS/JavaScript などの言語の学習
|
||||
- 各種依存関係やエラーの処理
|
||||
|
||||
しかし今は、AI プログラミングプラットフォームを使えば、次のことだけが必要です：
|
||||
- ブラウザを開き、Web ページにアクセスする
|
||||
- 自然言語で欲しい機能を説明する
|
||||
- AI が自動的にコードを生成し、リアルタイムでプレビューする
|
||||
|
||||
この「対話即プログラミング」のモードにより、プログラミングは「コードを書く」ことから「要件を説明する」ことになりました。あなたは技術的な詳細を気にする必要がなく、AI に欲しいものを明確に伝えるだけで、アイデアを実行可能なプログラムに変えてくれます。これが AI 時代のプログラミングの新しいパラダイム——**Vibe Coding（バイブコーディング）**です。
|
||||
:::
|
||||
|
||||
|
||||
|
||||
シンプルな要件を入力して**フルスタック開発**ボタンをクリックすると、Web ページの完全な作成プロセスをリアルタイムで見ることができます。通常、コーヒーを淹れる時間で Web ページが自動的に生成されます！
|
||||
|
||||
```
|
||||
スネークゲームを作ってください：
|
||||
1. 方向キーで蛇の移動を制御
|
||||
2. 食べ物を食べると蛇が長くなり、スコアが増加
|
||||
3. 壁や自分の体にぶつかるとゲームオーバー
|
||||
4. スタートとリスタートボタンを付ける
|
||||
5. シンプルで美しいインターフェース
|
||||
```
|
||||
|
||||
|
||||
|
||||
生成が完了すると、右側にブラウズ可能な Web ページのインターフェースが表示されます。ページのコンテンツを上下にスクロールしたり、ページ上部の 🧭 ボタンをクリックしてフルスクリーンモードに切り替えて効果を確認したりできます。
|
||||
|
||||
> 上部の左から右へのボタンの役割はそれぞれ：矢印ボタンはサイドバーの対話履歴を展開、鉛筆ボタンは新しい対話を作成、ループ矢印ボタンはページをリロード、コンパスボタンはフルスクリーンモードに切り替え、Download ボタンはプロジェクトをダウンロード、<> ボタンはコードビューに切り替え、Publish ボタンはプロジェクトを公開。
|
||||
|
||||
|
||||
|
||||
この Web ページのソースコードを表示したい場合は、右上隅のコードアイコンをクリックして完全なコードを確認できます。
|
||||
|
||||
|
||||
|
||||
::: tip 🌐 他の AI プログラミングツールを探索
|
||||
|
||||
z.ai のほかに、以下の優れた AI プログラミングプラットフォームもおすすめです：
|
||||
|
||||
| ツール | URL | 特徴 |
|
||||
|------|------|------|
|
||||
| **Google AI Studio**（おすすめ） | [aistudio.google.com/apps](https://aistudio.google.com/apps) | Google 公式、Gemini モデル対応、高速プロトタイプ開発に最適 |
|
||||
| **Figma Make** | [figma.com/make](https://www.figma.com/make) | デザインツールとの深い統合、デザイナー向けのインタラクティブプロトタイプに最適 |
|
||||
| **Coze** | [coze.com](https://www.coze.cn) | ByteDance の AI Bot 開発プラットフォーム、ノーコードのビジュアル構築機能。豆包、Kimi などの中国産大規模モデルと深く統合、プラグインマーケットプレイス、スケジュールタスク、マルチチャネル配信（Feishu、WeChat など）をサポート |
|
||||
| **v0.dev** | [v0.dev](https://v0.dev) | Vercel の AI UI 生成ツール、説明を入力するだけで実行可能な React コンポーネントを生成 |
|
||||
| **Bolt.new** | [bolt.new](https://bolt.new) | StackBlitz の AI フルスタック開発プラットフォーム、完全な Web アプリケーションを直接生成・デプロイ可能 |
|
||||
| **Lovable** | [lovable.dev](https://lovable.dev) | 高品質な React アプリの生成に特化、GitHub 統合とワンクリックデプロイをサポート |
|
||||
| **Replit Agent** | [replit.com](https://replit.com) | AI プログラミングアシスタントを統合したオンライン IDE、複数言語とリアルタイムコラボレーションをサポート |
|
||||
|
||||
他の Web プログラミングツールの詳細な比較と使用チュートリアルについては、拡張読み物を参照してください：[7 つの主流 Vibe Coding オンラインプラットフォーム実測比較](../../stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md)
|
||||
:::
|
||||
|
||||
### 2.2 対話型プログラミングでできること・できないこと
|
||||
|
||||
このセクションでは、一つの具体的な問題に焦点を当てます：対話型 AI のみに依存し、コードを一切書かない場合、一体どこまで進めることができるのか。
|
||||
経験則として、比較的安定した結論は次のとおりです：「小さくて完成度の高い」ものを作ることはできますが、「どこまでやれば十分か」は、あなたが各ステップの詳細を自分で判断する必要があります。
|
||||
|
||||
#### 「小さくて明確な」アプリに適している
|
||||
|
||||
前のスネークゲームの例からわかるように、典型的なパターンがあります：
|
||||
インターフェースとインタラクションを明確に説明できれば、AI は通常、数回の対話で、開ける、クリックできる、遊べる完全な Web ページを組み立てることができます。
|
||||
|
||||
この種のタスクにはいくつかの共通特徴があります：
|
||||
|
||||
- 範囲が明確：1ページの Web ページ、シンプルな社内ツール、小さなゲーム
|
||||
- 結果が見える：ブラウザで期待通りに動作するかすぐに確認できる
|
||||
- 修正が直接的：問題を見つけた後、後続の対話で具体的な現象を指摘し修正を求めることができる（エラーをコピーして貼り付けたり、スクリーンショットを貼り付けたりして AI に修正させる）
|
||||
|
||||
この範囲内では、対話型 AI を実行力のある「アシスタント開発者」と見なすことができます。各ラウンドで自然言語を使って要件を細分化・修正するだけで、素早く使えるプロトタイプを得ることができます。
|
||||
|
||||
**AI が単独で小規模プロジェクトを完了する成功率：**
|
||||
<el-progress :percentage="90" :stroke-width="15" status="success" striped striped-flow />
|
||||
|
||||
#### 大規模プロジェクトには「プロセスの視点」が必要
|
||||
|
||||
小さくて明確な範囲を超えると、数回の対話だけで AI に複雑なシステムをエンドツーエンドで完成させることは、すぐに限界に達します。大規模プロジェクトは多くの場合、バックエンド、データベース、サードパーティサービスの統合が必要で、権限、セキュリティ、同時実行、大量のビジネスルールも関係し、1ページの Web ページではなく、既存のビジネスと深く統合されたシステム全体の構築が目標です。
|
||||
|
||||
この場合、より合理的なアプローチは、すべての要件を一度に AI に投げるのではなく、まず明確な全体プロセスを整理することです：重要なステップは何か、各ステップの入力・出力と状態変化は何か、どのノードがパフォーマンスとセキュリティに最も敏感か。このフローチャートに基づいて、比較的独立した部分を分割し、対話型 AI にインターフェース、モジュール、スクリプト、テストの生成を任せます。
|
||||
|
||||
現在の能力では、AI は一つ一つの小さなステップを加速するのに適しており、あなた（またはチーム）がステップの分割方法、連携方法を決定し、最終的なアーキテクチャ設計、システム統合、運用保守を担当します。
|
||||
|
||||
#### 「書ける」ことと「使える」ことの違い
|
||||
|
||||
一見すると、AI は何でも書けるように見えますが、これらが本当に使えるのか、どこまで使えるのか、どのように区分すべきでしょうか？
|
||||
|
||||
一つの参考となる経験則は次のとおりです：
|
||||
|
||||
::: warning ⚠️ 適用シナリオガイド
|
||||
|
||||
- **プロトタイプ / デモ / 社内ツール**：まず AI に初版を作らせ、その後あなたがディテールを反復するのに非常に適しています。
|
||||
- **実際のユーザー向けの大規模プロダクト**：通常、エンジニアがアーキテクチャ、抽象化、パフォーマンス、保守に長期的に取り組む必要があります。
|
||||
- **高セキュリティ / 高コンプライアンスシステム（決済、リスク管理、医療など）**：現段階では「生成してそのまま本番稼働」は推奨されず、厳格なレビューとテストプロセスを導入する必要があります。
|
||||
:::
|
||||
|
||||
現在、AI を効率的なデモと個人用ツールのパートナーとして比較的安心して見なすことができます：
|
||||
十分にテストし、反復し、「ここが違う、修正して理由を説明して」と何度も聞けば、プロトタイプと社内ツールのレベルでは、全体的な品質は通常十分であり、実践的な価値があります。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: '課題と機会', description: '一般人のプログラミングの新たな可能性' },
|
||||
{ title: '能力の初探', description: '60秒の高速開発体験' },
|
||||
{ title: 'ネイティブ実践', description: 'AI ネイティブスネークゲームを作る' },
|
||||
{ title: '創造の拡張', description: '応用してゲームを作る' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 3. 実践：あなた初の AI ネイティブアプリケーション
|
||||
|
||||
実践パートに戻りましょう。前半では、AI を使って遊べるスネークゲームのプロトタイプを素早く作成し、AI が何ができて何ができないかを大まかに理解しました。次に、最も基本的な **vibe coding** のテクニックを使って、**現代版**の AI スネークゲームを作成する方法を学びます。蛇が豆ではなく文字を食べるようにします。最後に、ゲームが食べた文字に基づいて詩を生成し、絵を描かせます。
|
||||
この実際のケースを通じて、新しいプログラミング方法の核心理念を理解できます：自然言語で要件を明確に表現する方法を学びます。
|
||||
|
||||
### 3.1 AI ネイティブスネークゲーム
|
||||
|
||||
最初は、最もシンプルな方法で大規模モデルと対話します。これにより、迅速にプロダクトプロトタイプを得ることができます。チャットボックスに直接入力できます：
|
||||
|
||||
> **💡 プロンプト例：** スネークゲームを作ってください
|
||||
>
|
||||
> 
|
||||
|
||||
> **💡 プロンプト例：** スネークゲームを作ってください。以下の機能をサポートしてください
|
||||
>
|
||||
> 1. さまざまな単語を食べることができ、それらがボックスに収集されます
|
||||
> 
|
||||
|
||||
> **💡 プロンプト例：** スネークゲームを作ってください。以下の機能をサポートしてください：
|
||||
>
|
||||
> 1. さまざまな単語を食べることができ、それらがボックスに収集されます
|
||||
> 2. 蛇が8つの単語を食べると、LLM がそれらの単語に基づいて詩を作成し、必要に応じて詩を再ミックスできます
|
||||
> 3. 詩が完成したら、次のステップでその詩に基づいて画像が自動的に作成されます
|
||||
>
|
||||
> 
|
||||
|
||||
注意：開発中に期待通りにいかない問題に遭遇する場合があります。ボタンをクリックしても反応がない、機能使用時にエラーが発生する、機能が期待通りに動作しない、またはフロントエンドページが期待したデザインと一致しないなどです。
|
||||
|
||||
この場合、モデルにさらに質問して、これらの予期せぬ問題を修正するよう助けてもらう必要があります。
|
||||
|
||||
|
||||
|
||||
### 3.2 ゲームに新機能を追加する
|
||||
|
||||
基本機能が完成したら、プログラムに新しい工夫を追加してみましょう。蛇が単語や文字を食べるプロセスが少し退屈だと思うなら、蛇に異なる色の単語を食べさせ、それに応じて蛇の色を変えることができます。
|
||||
|
||||
また、「食べる」プロセスにエフェクトを追加したり、エフェクトをトリガーするマジックワードを導入したりすることもできます。たとえば、蛇の速度やサイズを増やすなど。別のアイデアとして、蛇が単語を食べるたびにモデルに詩と画像を生成させることもできます。8つの単語を食べるまで待つ必要はありません。
|
||||
|
||||
これが難しいと思うなら、言語モデルに直接助けを求めることができます。創造的な提案を出して、ゲームをより面白くしてくれます。試してみてください！
|
||||
|
||||
```
|
||||
1. "単語が世界をアンロック" メカニズム
|
||||
蛇が単語を食べるたびに、LLM がその単語に対して詩的な連想を行い（例：「木」→「森」「緑陰」）、画像モデルがその単語の小さなアートワークを即座に生成します。これらの画像は徐々にユニークなパノラマを構成し、プレイヤーは毎回プレイするたびに「絵を描き、詩を書いている」ことになります。
|
||||
|
||||
2. "詩のパズル" プレイ
|
||||
蛇が食べた各単語が LLM に短い詩の行を生成させ、画像モデルが挿絵を生成します。これらの詩と画像はパズルのように組み合わされ、ラウンド終了時に AI コラボレーションの詩と絵になります。
|
||||
|
||||
3. "マジックワード" & "ストーリー分岐"
|
||||
特別な「マジックワード」（例：「風」「夜」「夢」）は、LLM に詩を生成させるだけでなく、シーンの雰囲気やテーマを変えます——画像生成のスタイルを夜、嵐、夢の雰囲気に切り替えます。
|
||||
分岐ストーリー：LLM は開始時にテーマやなぞなぞ（例：「秋の思い出」）を提示します。プレイヤーの単語選択がストーリーと詩の進化に直接影響し、画像モデルはリアルタイムで背景とビジュアル効果を更新します。
|
||||
|
||||
4. "リアルタイムインタラクティブ生成"
|
||||
各単語の後、LLM が一行の対話や説明を生成し、ゲーム内の NPC がプレイヤーに「話しかけ」たり、環境に応じて変化したりします。
|
||||
蛇の外観やゲーム内の障害物は、食べた単語に基づいて視覚的に変化します。これは画像モデルのおかげです。
|
||||
|
||||
5. "創作 & シェア"
|
||||
プレイヤーはセッション終了時に AI 創作の詩と画像を保存・シェアでき、ユニークな「AI コラボレーション」を自慢できます。
|
||||
「最も美しい詩+アート」「最も創造的な単語の組み合わせ」などのランキングは、リプレイと創造性を促します。
|
||||
|
||||
6. "フレーズスネーク" チャレンジ
|
||||
リバースモード：LLM が詩の一行またはなぞなぞを提示し、プレイヤーは蛇を操作して単語を順番に食べ、文を再構成する必要があります。間違った単語を食べると、画像生成モデルによって面白いまたは芸術的な結果がトリガーされます。
|
||||
|
||||
7. "テーマレベル" & "スタイル選択"
|
||||
ゲーム開始時に、プレイヤーがテーマ（例：「童話」「SF」「唐詩」）を選択し、LLM と画像モデルの両方が単語選択、詩のスタイル、ビジュアル効果を調整し、毎回のプレイが新鮮に感じられるようにします。
|
||||
|
||||
8. "リアルタイムコラボレーション"
|
||||
特別な単語を食べると、LLM はプレイヤーにフレーズやスタイルの入力を促し、AI が対応する詩と挿絵を生成し、真の人間-AI コラボレーションを実現します。
|
||||
|
||||
9. "AI イースターエッグ & 実績"
|
||||
特定の単語の組み合わせが LLM によって特別なテーマや内部ジョーク（例：「月」「桂花」「川岸」）として認識され、レアな詩と挿絵がトリガーされ、探索を報酬します。
|
||||
|
||||
10. "成長の物語"
|
||||
蛇が成長するにつれて、LLM が連続する物語詩を生成し、画像モデルがシームレスな長巻物またはパノラマを作成し、プレイヤーは「書き、描き、遊ぶ」ことを同時に楽しめます。
|
||||
```
|
||||
|
||||
また、LLM にプロジェクトレベルのプロンプトを直接生成させるよう依頼することもできます。前のセクションでは、スネークゲームのプロンプトを自分で書きました。今回は、大規模モデルに全体フレームワークと実装パスを含むプロンプトを生成させましょう（z.ai で直接生成できます）。
|
||||
|
||||
より良いプロンプトの書き方を学びたい場合は、[プロンプトエンジニアリング付録](/zh-cn/appendix/8-artificial-intelligence/prompt-engineering)を参照してください。
|
||||
|
||||
> AI にウェブスネークゲームを生成させたいのですが、より完全なプロンプトが必要で、結果をより印象的で面白くしたいです。詩を生成する機能を実装するスネークゲームを生成してください。また、画像生成モジュールを含める必要があります。
|
||||
|
||||
z.ai の回答は次のようになります：
|
||||
|
||||
|
||||
|
||||
このプロンプトを使ってフルスタック開発モードでプロジェクトを再生成できます：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: '課題と機会', description: '一般人のプログラミングの新たな可能性' },
|
||||
{ title: '能力の初探', description: '60秒の高速開発体験' },
|
||||
{ title: 'ネイティブ実践', description: 'AI ネイティブスネークゲームを作る' },
|
||||
{ title: '創造の拡張', description: '応用してゲームを作る' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
### 3.3 他のミニゲームを作ってみる
|
||||
|
||||
スネークゲーム以外にも、想像力を存分に発揮させましょう。
|
||||
|
||||
何でも創造できます。失敗しても最初からやり直すだけです！
|
||||
|
||||
```
|
||||
1. AI アートギャラリープラットフォーム
|
||||
説明：AI 生成アート作品を展示するオンラインギャラリー。ユーザーはアップロード、共有、コメントができます。
|
||||
機能：ユーザーアカウントシステム、アート作品のアップロードと展示、評価システム、カテゴリブラウジング、AI 生成ツール統合。
|
||||
技術的ハイライト：React/Vue フロントエンド、Node.js バックエンド、MongoDB データベース、AI API 統合。
|
||||
|
||||
2. レトロゲームアーカイブ
|
||||
説明：クラシックゲームを称えるウェブサイト。ゲームの歴史、プレイガイド、オンラインで遊べるレトロゲームを含みます。
|
||||
機能：ゲームデータベース、タイムライン展示、オンラインエミュレータ、ユーザーレビュー、ゲームコレクション機能。
|
||||
技術的ハイライト：レスポンシブデザイン、WebGL/Canvas ゲーム実装、RESTful API、ユーザー認証システム。
|
||||
|
||||
3. サステナブルライフトラッカー
|
||||
説明：エコフレンドリーなヒントとコミュニティチャレンジを通じて、ユーザーがカーボンフットプリントを追跡・削減するウェブサイト。
|
||||
機能：個人カーボンフットプリント計算機、目標設定、進捗追跡、コミュニティチャレンジ、環境知識ベース。
|
||||
技術的ハイライト：データ可視化、モバイル最適化、ソーシャル機能、プッシュ通知。
|
||||
|
||||
4. バーチャルキッチンアシスタント
|
||||
説明：AI ベースの料理指導プラットフォーム。パーソナライズされたレシピ提案とステップバイステップの料理手順を提供します。
|
||||
機能：レシピデータベース、食材認識、パーソナライズされた推薦、料理タイマー、栄養分析。
|
||||
技術的ハイライト：画像認識 API、機械学習推薦システム、音声制御、リアルタイムビデオガイダンス。
|
||||
|
||||
5. インディーミュージック発見プラットフォーム
|
||||
説明：インディーズアーティストや新進アーティストに特化した音楽ストリーミングプラットフォーム。
|
||||
機能：音楽ストリーミング、アーティストプロフィール、パーソナライズされた推薦、プレイリスト作成、コミュニティレビュー。
|
||||
技術的ハイライト：オーディオストリーミング処理、推薦アルゴリズム、ソーシャル機能、音楽可視化。
|
||||
|
||||
6. ミニマリストタスク管理システム
|
||||
説明：禅の美学を持つタスク管理ツール。シンプルさと効率的なタスク整理に焦点を当てています。
|
||||
機能：タスクの作成と分類、優先度設定、進捗追跡、チームコラボレーション、データ分析。
|
||||
技術的ハイライト：ミニマリスト UI デザイン、ドラッグ＆ドロップ機能、リアルタイム同期、クロスプラットフォーム互換性。
|
||||
|
||||
7. SF ライティングワークショップ
|
||||
説明：SF 作家のためのクリエイティブツールとインスピレーションプラットフォーム。ワールドビルディング補助とキャラクター開発ツールを含みます。
|
||||
機能：ストーリー構造ツール、キャラクタープロフィール、ワールドビルディングテンプレート、ライティング統計、コミュニティフィードバック。
|
||||
技術的ハイライト：リッチテキストエディタ、データ可視化、コラボレーティブ編集、AI 補助創作。
|
||||
|
||||
8. パーソナルナレッジグラフ
|
||||
説明：ユーザーがパーソナルナレッジネットワークを構築し、さまざまなアイデアと情報を可視化・接続するツール。
|
||||
機能：ノードの作成と接続、タグシステム、検索機能、インポート/エクスポートツール、可視化グラフ。
|
||||
技術的ハイライト：グラフデータベース、データ可視化アルゴリズム、Markdown サポート、クロスデバイス同期。
|
||||
|
||||
9. バーチャル植物園
|
||||
説明：インタラクティブな植物図鑑。ユーザーは植物の世界を探索し、バーチャルガーデンを作成できます。
|
||||
機能：植物データベース、3D 植物モデル、成長シミュレーション、ガーデニングガイド、コミュニティ展示。
|
||||
技術的ハイライト：3D レンダリング、季節変化シミュレーション、AR 統合、植物認識 API。
|
||||
|
||||
10. プログラミングチャレンジアリーナ
|
||||
説明：プログラマー向けのオンラインコンペティションプラットフォーム。さまざまな難易度レベルのプログラミングチャレンジを提供します。
|
||||
機能：チャレンジ問題、コードエディタ、自動評価、リーダーボード、学習パス。
|
||||
技術的ハイライト：コードサンドボックス環境、リアルタイム評価システム、アルゴリズム可視化、ソーシャル学習機能。
|
||||
```
|
||||
|
||||
また...ゲームが好きなら、一緒にゲームを作ってみましょう！
|
||||
|
||||
```
|
||||
1. 3D オープンワールド RPG
|
||||
説明：広大なオープンワールド、クエスト、キャラクター成長を持つファンタジー RPG。
|
||||
機能：昼夜サイクル、ダイナミック天気、スキルツリー、マルチプレイヤーコープ、クラフトシステム。
|
||||
技術的ハイライト：Three.js または Babylon.js による 3D レンダリング、サーバーサイドゲームロジック、キャラクターカスタマイズ、セーブシステム。
|
||||
|
||||
2. FPS アリーナ
|
||||
説明：高速ペースのマルチプレイヤー FPS。さまざまなゲームモードとマップを備えています。
|
||||
機能：チームデスマッチ、キャプチャーザフラグ、武器カスタマイズ、ランクマッチ。
|
||||
技術的ハイライト：WebGL/Three.js による 3D グラフィックス、マルチプレイヤーネットワークコード、ヒット検出、ボイスチャット。
|
||||
|
||||
3. AI チェス & マルチプレイヤー
|
||||
説明：AI 対戦とオンライン対戦機能を備えた本格的なチェスプラットフォーム。
|
||||
機能：AI 難易度レベル、エンドゲームチャレンジ、トーナメントモード、リプレイ分析。
|
||||
技術的ハイライト：チェスロジックライブラリ、WebSocket によるリアルタイム対戦、ELO ランキングシステム、アンチチート。
|
||||
|
||||
4. マージャンオンラインマルチプレイヤー
|
||||
説明：オンラインマルチプレイヤーとスコアリング機能を備えた伝統的な麻雀ゲーム。
|
||||
機能：複数のルールセット、プライベートルーム、ランキングシステム、リプレイ機能。
|
||||
技術的ハイライト：牌マッチングロジック、リアルタイムマルチプレイヤー、ロビーシステム、スコア追跡。
|
||||
|
||||
5. ターン制ストラテジーゲーム
|
||||
説明：グリッドベースの戦闘とユニット管理を備えたタクティカルストラテジーゲーム。
|
||||
機能：キャンペーンモード、スカーミッシュ、ユニットアップグレード、フォグオブウォー、マルチプレイヤー対戦。
|
||||
技術的ハイライト：グリッド移動システム、AI 意思決定、ターン同期、セーブ/ロードシステム。
|
||||
|
||||
6. タイムアタックレーシングゲーム
|
||||
説明：タイムアタックとコースレコードに焦点を当てた 3D レーシングゲーム。
|
||||
機能：複数のコース、車のカスタマイズ、ゴーストリプレイ、リーダーボード。
|
||||
技術的ハイライト：3D カーの物理、コースエディタ、リプレイシステム、オンラインリーダーボード。
|
||||
|
||||
7. カードバトルゲーム（デッキ構築）
|
||||
説明：プレイヤーがデッキを構築し、対戦相手と戦うストラテジーカードゲーム。
|
||||
機能：カード収集、デッキ構築、ランクマッチ、シーズンイベント。
|
||||
技術的ハイライト：カードゲームロジック、マッチメイキングシステム、AI 対戦相手、カードアニメーション。
|
||||
|
||||
8. バトルロイヤル（俯瞰 2D）
|
||||
説明：縮小するゲームエリアとルート機能を備えた俯瞰 2D バトルロイヤル。
|
||||
機能：ソロおよびスクワッドモード、武器の多様性、インゲームイベント、リーダーボード。
|
||||
技術的ハイライト：リアルタイムマルチプレイヤー、ゾーン縮小ロジック、ルート生成システム、マッチメイキング。
|
||||
|
||||
9. ホラーサバイバルゲーム（一人称）
|
||||
説明：リソース管理と脱出メカニズムを備えた一人称ホラーゲーム。
|
||||
機能：不気味な雰囲気、パズル、敵 AI、マルチエンディング。
|
||||
技術的ハイライト：ダイナミックライティング、サウンドデザイン、敵の経路探索、セーブシステム。
|
||||
|
||||
10. リズムゲーム（3D）
|
||||
説明：音楽のビートに合わせてノートを叩く 3D リズムゲーム。
|
||||
機能：複数の難易度レベル、コースエディタ、カスタム楽曲サポート、リーダーボード。
|
||||
技術的ハイライト：オーディオ分析、ビート同期、3D ノートトラック、入力タイミング検出。
|
||||
```
|
||||
|
||||
## 📚 Assignment
|
||||
|
||||
<el-card id="assignment-card" shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🎯 本章の課題：最初の AI ネイティブミニゲームを完成させる</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
このセクションでは、「対話でスネークゲームを生成」から「AI ネイティブミニゲームの設計思考の理解」までの完全なプロセスを体験しました。以下の課題は、この理解を自分の能力にするのに役立ちます。
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
<strong>AI ネイティブスネークゲームを完全に再現する</strong>
|
||||
<ul>
|
||||
<li>最低限の実装：蛇が移動できる、「食べ物」を食べると長さとスコアが変化する、壁や自分の体にぶつかるとゲームオーバー。</li>
|
||||
<li>再現中、エラー現象 + エラーメッセージ + 重要なコードスニペットを一度に AI に投げ、「初心者モード」で修正してもらう練習をする。</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>（オプション）自作の AI ネイティブミニゲームまたはデモを 1 つ作る</strong>
|
||||
<ul>
|
||||
<li>文字、画像、音楽、リズムなどを中心とした任意の軽量ゲームプレイで構いません。例：「単語を食べて詩を書く」「リズムタップ」「生成的ランニング」など。</li>
|
||||
<li>重要なのはビジュアルの豪華さではなく、AI がここで具体的に何を助けたのか、人間には困難または面倒な部分を何を解決したのかを明確に説明できることです。</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
これが完全なチュートリアルです！すべての内容を完了し、自分のスネークゲームを構築するには <strong>4 時間</strong>かかるかもしれません。急ぐ必要はありません——探索、実験、そしてプロセスを楽しんでください。途中で理解できない概念に遭遇した場合は、以下の付録の関連部分を参照してください。
|
||||
</p>
|
||||
</el-card>
|
||||
|
||||
## 付録
|
||||
|
||||
<el-card id="appendix-nav" shadow="hover" style="margin-top: 24px; margin-bottom: 24px; border-left: 5px solid #67C23A;">
|
||||
<div style="font-weight: bold; margin-bottom: 8px;">付録ナビゲーション</div>
|
||||
<div style="color: #606266; font-size: 14px; line-height: 1.6; margin-bottom: 12px;">
|
||||
本章に関連する基本概念を整理しました：学習中に「フロントエンドとは何か」「Vibe Coding とは何か」などの疑問に遭遇したら、いつでもここに戻って参照できます。
|
||||
</div>
|
||||
<el-row :gutter="16">
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-1" style="text-decoration: none; color: inherit;"><b>付録 1：フロントエンド開発の知識は必要？</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">アプリケーション全体におけるフロントエンドの位置を理解し、「見える」部分を知る。</span>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-2" style="text-decoration: none; color: inherit;"><b>付録 2：Vibe Coding とは何か</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">「対話型開発」の核心理念を理解し、AI とどう連携するかを知る。</span>
|
||||
</el-col>
|
||||
</el-row>
|
||||
<el-row :gutter="16" style="margin-top: 10px;">
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-3" style="text-decoration: none; color: inherit;"><b>付録 3：モデルコンテキスト</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">「コンテキスト長」などよく聞くが混同しやすい概念を整理する。</span>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-4" style="text-decoration: none; color: inherit;"><b>付録 4：命令追従能力</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">モデルがなぜ「話を理解しない」ことがあるのか、より明確に書く方法を学ぶ。</span>
|
||||
</el-col>
|
||||
</el-row>
|
||||
<div style="margin-top: 12px; font-size: 12px; color: #909399;">
|
||||
ヒント：Ctrl/⌘+F でキーワードを検索できます。または、わからない段落を AI にコピーして、「完全に初心者にもわかるように」説明してもらうこともできます。
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
## <span id="appendix-1">[付録 1：フロントエンド開発の知識は必要？](#appendix-nav)</span>
|
||||
|
||||
::: tip 💡 一言でまとめると
|
||||
コードを書く必要はありませんが、基本概念を理解すると AI に要件をより良く説明できるようになります。
|
||||
:::
|
||||
|
||||
<el-row :gutter="16" style="margin: 20px 0;">
|
||||
<el-col :span="12" :xs="24" style="margin-bottom: 16px;">
|
||||
<el-card shadow="hover" style="border-radius: 12px; height: 100%;">
|
||||
<template #header>
|
||||
<div style="display: flex; align-items: center; gap: 8px;">
|
||||
<span style="font-size: 20px;">👁️</span>
|
||||
<span style="font-weight: bold;">フロントエンド</span>
|
||||
<el-tag type="success" size="small">可視</el-tag>
|
||||
</div>
|
||||
</template>
|
||||
<div style="color: #606266; line-height: 1.8;">
|
||||
ユーザーが<strong>見て、触れる</strong>すべてのコンテンツ
|
||||
<ul style="margin: 12px 0; padding-left: 20px;">
|
||||
<li>ウェブページのタイトル、テキスト、画像</li>
|
||||
<li>ボタン、入力フィールド、ドロップダウンメニュー</li>
|
||||
<li>ゲームインターフェース、アニメーション効果</li>
|
||||
</ul>
|
||||
</div>
|
||||
</el-card>
|
||||
</el-col>
|
||||
<el-col :span="12" :xs="24" style="margin-bottom: 16px;">
|
||||
<el-card shadow="hover" style="border-radius: 12px; height: 100%;">
|
||||
<template #header>
|
||||
<div style="display: flex; align-items: center; gap: 8px;">
|
||||
<span style="font-size: 20px;">⚙️</span>
|
||||
<span style="font-weight: bold;">バックエンド</span>
|
||||
<el-tag type="info" size="small">不可視</el-tag>
|
||||
</div>
|
||||
</template>
|
||||
<div style="color: #606266; line-height: 1.8;">
|
||||
サーバー上で動作するデータ処理
|
||||
<ul style="margin: 12px 0; padding-left: 20px;">
|
||||
<li>ユーザースコアの保存</li>
|
||||
<li>ログイン認証</li>
|
||||
<li>レベルコンテンツの配信</li>
|
||||
</ul>
|
||||
</div>
|
||||
</el-card>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
### フロントエンドの三種の神器
|
||||
|
||||
ブラウザは三つの「コード」を使ってページを構築します：
|
||||
|
||||
<el-tabs type="border-card" style="margin: 20px 0;">
|
||||
<el-tab-pane label="🏗️ HTML - 骨格">
|
||||
<div style="padding: 10px;">
|
||||
<p><strong>役割：</strong>ページ上に<strong>何があるか</strong>を定義する</p>
|
||||
<p><strong>例え：</strong>家の構造スケッチ（壁、ドア、窓の場所）</p>
|
||||
<el-card style="background: #f5f7fa; margin-top: 12px;">
|
||||
<pre style="margin: 0;"><code><button>クリック</button>
|
||||
<h1>タイトル</h1>
|
||||
<img src="photo.png"></code></pre>
|
||||
</el-card>
|
||||
</div>
|
||||
</el-tab-pane>
|
||||
<el-tab-pane label="🎨 CSS - スタイル">
|
||||
<div style="padding: 10px;">
|
||||
<p><strong>役割：</strong>要素の<strong>見た目</strong>を制御する</p>
|
||||
<p><strong>例え：</strong>家の内装（色、素材、レイアウト）</p>
|
||||
<el-card style="background: #f5f7fa; margin-top: 12px;">
|
||||
<pre style="margin: 0;"><code>button {
|
||||
background: blue;
|
||||
color: white;
|
||||
border-radius: 8px;
|
||||
}</code></pre>
|
||||
</el-card>
|
||||
</div>
|
||||
</el-tab-pane>
|
||||
<el-tab-pane label="⚡ JavaScript - 挙動">
|
||||
<div style="padding: 10px;">
|
||||
<p><strong>役割：</strong>ページを<strong>動かす</strong></p>
|
||||
<p><strong>例え：</strong>家の電気回路スイッチ（クリック後の応答）</p>
|
||||
<el-card style="background: #f5f7fa; margin-top: 12px;">
|
||||
<pre style="margin: 0;"><code>button.onclick = () => {
|
||||
alert('クリックされました！')
|
||||
}</code></pre>
|
||||
</el-card>
|
||||
</div>
|
||||
</el-tab-pane>
|
||||
</el-tabs>
|
||||
|
||||
### コードがページになる仕組み
|
||||
|
||||
Web ページを開くと、ブラウザは三つのコードを順番に処理します：
|
||||
|
||||
**1. HTML —— ページ構造の定義**
|
||||
ブラウザはまず HTML を解析し、ページ上にどの要素（タイトル、段落、画像、ボタンなど）があるか、そしてそれらの階層関係を理解します。
|
||||
|
||||
**2. CSS —— スタイルの適用**
|
||||
次にブラウザは CSS ルールに従って、これらの要素にスタイルを追加します：色、サイズ、位置、間隔など、ページを見やすくします。
|
||||
|
||||
**3. JavaScript —— インタラクションの追加**
|
||||
最後に JavaScript コードを実行し、ページを「動かします」：クリックへの応答、フォームの送信、アニメーションの再生など。
|
||||
|
||||
**4. ページの表示**
|
||||
三つの連携結果が、あなたが最終的に見る Web ページです。
|
||||
|
||||
### モダンフロントエンドフレームワーク：HTML から React/Vue へ
|
||||
|
||||
前述の HTML、CSS、JavaScript はフロントエンド開発の「三種の神器」であり、すべての Web ページの基礎です。ただし、ページが複雑になると、これらだけでは課題に直面します：コードの保守が困難、反復作業が多い、データ同期が面倒など。
|
||||
|
||||
**モダンフロントエンドフレームワーク**（React、Vue、Angular など）は HTML/CSS/JS の上に構築され、開発をより効率的にします：
|
||||
|
||||
**1. HTML/CSS/JS（基礎段階）**
|
||||
ページ要素を直接操作し、シンプルなページに適しています。しかし、コード量が増えると、すべてのロジックが混ざり合い、保守が困難になります。
|
||||
|
||||
**2. jQuery（過渡期）**
|
||||
DOM 操作を簡素化し、コードをより簡潔にします。ただし、ページの状態を手動で管理する必要があり、データ変更時に対応する要素を自分で見つけて更新する必要があります。
|
||||
|
||||
**3. React/Vue（モダン期）**
|
||||
コンポーネント化と状態駆動の設計を採用：
|
||||
- **コンポーネント化**：ページを独立した再利用可能なモジュール（ボタン、カード、ナビゲーションバーなど）に分割
|
||||
- **状態駆動**：データが変更されると、フレームワークが対応する UI を自動的に更新し、手動操作が不要
|
||||
|
||||
::: tip 💡 簡単に理解すると
|
||||
- **HTML/CSS/JS** = 基礎材料（レンガ、セメント、鉄筋）
|
||||
- **React/Vue** = 建築フレームワーク（家を建てるための規範とツールを提供）
|
||||
|
||||
AI 補助プログラミング時代では、フレームワークのすべての詳細を深く理解する必要はありません。基本概念を理解するだけで、自然言語の説明で AI にコード生成を依頼できます。
|
||||
:::
|
||||
|
||||
### Vibe Coding において
|
||||
|
||||
**核となるポイント：コードを書く必要はなく、説明できれば十分です。**
|
||||
|
||||
フロントエンドの概念を理解した後、次のように AI に要件を説明できます：
|
||||
|
||||
> "React でリーダーボードページを作って。右側にスコアリストを表示し、行をクリックすると下にプレイヤー詳細を表示する。シンプルでモダンなスタイルに。"
|
||||
|
||||
HTML、CSS、JavaScript などのフロントエンド基礎知識をさらに深く理解したい場合は、[Web 基礎付録](/zh-cn/appendix/3-browser-and-frontend/javascript-deep-dive)を参照してください。フロントエンド技術の発展の歴史を知りたい場合は、[フロントエンド進化史付録](/zh-cn/appendix/3-browser-and-frontend/frontend-frameworks)を参照してください。
|
||||
|
||||
## <span id="appendix-2">[付録 2：Vibe Coding とは何か](#appendix-nav)</span>
|
||||
|
||||
> 💡 Vibe Coding とは？コンピュータ科学者 [Andrej Karpathy](https://karpathy.ai/)（OpenAI の共同創業者の一人、テスラ元 AI 責任者）が 2025 年 2 月に **vibe coding** という言葉を提案しました。この概念は、LLM に依存するコーディング方法を指し、**プログラマーが自然言語の説明を提供することで、手動でコードを書くことなく動作するコードを生成できるようにします。**
|
||||
|
||||
|
||||
|
||||
文字通り、Vibe Coding は「話すことで開発する」方法として理解できます。その核となる変化は：もう自分で一行一行コードを書いたり、構文を調べたり、バグを修正したりする必要はなく、自然言語で欲しいものを直接説明するだけです。例えば：
|
||||
|
||||
「ログインページが必要です。携帯番号の入力フィールドと認証コードの入力フィールドを付けてください。」
|
||||
「ログイン成功後、トップページにリダイレクトし、右上隅にユーザー名を表示してください。」
|
||||
「シンプルなスネークゲームを作ってください。キーボードの方向キーで操作できるように。」
|
||||
|
||||
大規模言語モデル（LLM）がこのような説明を自動的に実際に動作するコードに翻訳し、対応するページ、ロジック、データ構造を生成します。結果を見た後、自然言語で修正意見を伝えます。例えば「ボタンをもう少し大きく」「背景をダークカラーに」「スコアを記録してリーダーボードを表示」など。AI は引き続きあなたの要件に応じて実装を調整します。
|
||||
|
||||
このモードでは、プログラミング言語を先に学んでからコードを書く必要はありません。主な精力を次のことに注ぎます：何を作るかを明確にする、結果を見て「どこが違うか」を判断する、新しい修正を提案する。AI はこれらの上位のアイデアを具体的な実装に落とし込み、機械的で反復的なコーディング作業を大幅に削減します。
|
||||
|
||||
Vibe Coding の詳細についてはこちらを参照してください：[https://www.ibm.com/think/topics/vibe-coding](https://www.ibm.com/think/topics/vibe-coding)
|
||||
|
||||
Karpathy の共有内容の詳細についてはこちらを参照してください：[https://karpathy.bearblog.dev/blog/](https://karpathy.bearblog.dev/blog/)
|
||||
|
||||
### Vibe Coding の達人を装う方法
|
||||
|
||||
実際、本格的な vibe coding の過程では、複雑なプロンプトをあまり使いません。開始時にプログラム全体に対して具体的で適度に複雑なプロンプトを提供する必要があるかもしれませんが、その後の各ステップでは、次のような種類のプロンプトだけが必要です：
|
||||
|
||||
```
|
||||
"コードにバグがあります、修正してください。"
|
||||
"部分コードは不要です。修正後の完全なコードをください。"
|
||||
"あなたのコードにはまだ問題があります。"
|
||||
"もう一度修正して、修正後の完全なコードをください。"
|
||||
"さっきまで動いていたのに、なぜ今動かないのですか？"
|
||||
"私の意図を理解していないのですか？元のコードを変更しないでください。"
|
||||
"デバッグ機能を追加しないでください。"
|
||||
"私が依頼していないことはしないでください。"
|
||||
"私が実装を依頼した機能はどこですか？"
|
||||
"私の言葉がわからないのですか？"
|
||||
"関数を一つだけください。"
|
||||
"以前のコードを参照するように言ったはずです。"
|
||||
"不要なコメントを追加しないでください。"
|
||||
"元のコードの基本ロジックを変更しないでください。"
|
||||
"コードを修正してください。"
|
||||
"私のコードをベースに修正..."
|
||||
"変数名を変更しないでください！！！"
|
||||
"元の関数名を変更しないでください！"
|
||||
"私の変数を勝手に変更しないでください。"
|
||||
"追加機能を追加しないでください。"
|
||||
"フレームワークだけを生成するのではなく、完全なコードを生成してください。"
|
||||
```
|
||||
|
||||
これは少し誇張されているように聞こえるかもしれませんが、実際には、これらが日常の作業で使用するプロンプトです。大規模言語モデルの**コンテキスト長の制限**のため、または**命令追従能力**があまり強くないため、モデルは対話の早い段階で議論された内容を忘れることがあります。vibe coding では、長いコンテキストのモデルを使用する傾向があり、命令追従能力の強いモデルを使用します。これら二つのランキングや指標で判断できます。
|
||||
|
||||
または、トレーニングデータセットのスタイルにより、大規模モデルはそのトレーニングデータのスタイルで回答する傾向があります。例えば、一部の人は真面目に話し、一部の人は多くの修飾を加え、一部の大規模モデルはコードに多くのコメントや不要なモジュールを追加するのが好きです。
|
||||
|
||||
## <span id="appendix-3">[付録 3：モデルコンテキスト](#appendix-nav)</span>
|
||||
|
||||
モデルコンテキストは、AI の短期記憶として理解できます。これは、現在の一回の対話またはタスクにおいて、モデルが「見て」および「覚えて」いるすべてのテキストコンテンツを指し、以前に入力した質問、システムが提供した説明、関連資料などを含みます。
|
||||
|
||||
コンテキストがあるからこそ、AI はあなたが前の内容に続いて質問していることを理解し、一ラウンド一ラウンド、途切れのない自然な対話を行うことができます。コンテキストがなければ、あなたの各文はモデルにとって全く新しい質問のように見え、以前に何を言ったかを知ることができず、対話を続けることはできません。
|
||||
|
||||
各モデルには独自の有効コンテキスト長（context window）があります。この長さは通常 token（大まかに「単語の断片」の単位と理解できます）で測定され、現在の主流モデルはほぼ 32k～128k token です。コンテキストが長いほど、モデルが一度に「読める」内容が増えます。例えば：
|
||||
|
||||
- 長めの論文やレポートを一度に読む
|
||||
- 同じ対話ラウンドで複数の資料やケースを参照する
|
||||
- モデルに以前の数ラウンドの複雑な議論の結論を覚えさせる
|
||||
|
||||
入力内容がモデルのコンテキスト制限に近づくまたは超えると、次のような一般的な現象がよく発生します：
|
||||
|
||||
- モデルが長いテキストの細部や重要情報を忘れ始める
|
||||
- 対話が進むにつれて、話題が当初の目標から徐々に逸れる
|
||||
- 同じ資料に対する異なる質問間で、参照内容に不一致が生じる
|
||||
|
||||
これらの現象は、モデルが突然「バカになった」わけではなく、コンテキスト容量が使い切られたり使い切れに近づいた後に生じる自然な結果です。
|
||||
|
||||
実際の使用では、コンテキストを可能な限り長くしたいと同時に、次の点も意識する必要があります：
|
||||
|
||||
- コンテキストが長いほど、消費する計算リソースが増える
|
||||
- 対応する呼び出しコスト（費用）も増加する
|
||||
|
||||
したがって、AI アプリケーションを設計する際には、モデルに十分な量を読ませることと、コストの制御・効率の向上との間でバランスを取る必要があります。例えば：
|
||||
|
||||
- 本当に長期保存が必要な情報を要約してからモデルに渡す
|
||||
- 不要な詳細情報を、一度にコンテキストにそのまま入れ続けない
|
||||
- 外部ナレッジベースなどの方法を使い、「長期記憶」をシステムに任せ、モデルのコンテキストに無理に入れない
|
||||
|
||||
## <span id="appendix-4">[付録 4：命令追従能力](#appendix-nav)</span>
|
||||
|
||||
命令追従能力とは、モデルがあなたの命令を理解した後、正確かつ完全にあなたの要求通りに実行できるかどうかを指します。質問に答えるだけでなく、指定されたフォーマット、スタイル、手順でタスクを完了することも含みます。
|
||||
|
||||
例えば、以下はすべてモデルに明確な要求がある命令です：
|
||||
|
||||
- この記事を3つのポイントに要約する
|
||||
- 正式で礼儀正しい口調で返信メールを書く
|
||||
- この単語を英語に翻訳し、それぞれ例文を作る
|
||||
- 記事から著者、日時、主要イベントを抽出する
|
||||
|
||||
命令追従能力の強いモデルは、通常次の特徴を備えています：
|
||||
|
||||
- 要求された数量通りに出力する
|
||||
例えば3つのポイントに要約するよう依頼すれば、5つを出力することはありません。
|
||||
- 指定されたすべての要素をカバーする
|
||||
例えば著者、日時、イベントの抽出を依頼すれば、そのいずれも漏らしません。
|
||||
- 指定されたフォーマットとトーンを遵守する
|
||||
例えば正式なトーンを依頼すれば、あまり口語的な返信を出力しません。
|
||||
- 不要な追加拡張を行わない
|
||||
例えば翻訳と例文の作成だけを依頼すれば、無関係な説明を大量に出力しません。
|
||||
|
||||
実際の応用では、強い命令追従能力は非常に重要です。理由は次のとおりです：
|
||||
|
||||
- 安定性の向上：同じ命令を異なる時刻で複数回実行した場合、出力構造と動作パターンがより一貫し、ランダムな逸脱が起こりにくい
|
||||
- 再現性の向上：プロンプトを製品やプロセスに設定する場合、モデルがおおよそどのように応答するかを予測でき、テストと反復が容易
|
||||
- システム統合の容易さ：モデルの出力が期待されるフォーマットに合致すれば、バックエンドプログラム、ワークフロー、その他のツールとの自動接続が容易
|
||||
|
||||
したがって、大規模言語モデルを選択・評価する際には、賢いか、知識カバレッジが広いかだけでなく、命令追従能力にも特に注意する必要があります。産業級アプリケーションにとって、安定して正確に命令を実行できることは、たまに驚くような回答を出すことよりもはるかに重要です。
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="学びを続ける"
|
||||
description="「ゲーム化体験」から出発し、ローカル開発とプロダクト実践への継続を推奨します。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1 @@
|
||||
../../../zh-cn/stage-1/appendix-a-product-thinking/images
|
||||
@@ -0,0 +1,899 @@
|
||||
---
|
||||
title: 'プロダクト思考とソリューション設計'
|
||||
description: 'AIツールの構築から、アイデアの発想・判断・磨き上げができるAIアプリへの移行を学び、プロダクト思考の核心理念と実践方法を習得する。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>6 時間</strong>'
|
||||
</script>
|
||||
|
||||
# プロダクト思考とソリューション設計
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['プロダクト思考', 'ニーズ分析', 'ソリューション設計', 'ユーザーインサイト']" coreOutput="1つの完成したプロダクト企画" expectedOutput="実現可能なプロダクト設計のアプローチ">
|
||||
|
||||
前の章では、z.aiとローカルAI IDEで様々な小ツールを構築する方法を学びました。また、Traeを使って環境設定や依存関係のインストールなどのエンジニアリング問題を処理する方法も試し、ブラウザからローカルプロジェクトへアイデアを移す能力を身につけました。
|
||||
|
||||
次に、私たちの関心を<strong>「作れるかどうか」</strong>から<strong>「何を作るべきか、作る価値があるか」</strong>へと進めます。
|
||||
|
||||
この章では、以下の内容を体系的に扱います：
|
||||
- 「アイデア」とは何か、「良いアイデア」とはどういうものか
|
||||
- プロダクトの方向性が投資に値するかどうかを判断する方法
|
||||
- 反復可能なプロセスを使って、曖昧なインスピレーションを明確なアプリ企画に変える方法
|
||||
|
||||
<strong>コア目標：</strong>ツールを構築できることから、本当に人が使って実際の価値を生み出すAIアプリを作れることにアップグレードする。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'アイデアの出所', description: '信頼できるプロダクトアイデアを見つける' },
|
||||
{ title: 'ソリューション分解', description: 'アイデアを実現可能なアプリにする' },
|
||||
{ title: '磨き上げと判断', description: '使えるものから使いやすいものへ' },
|
||||
{ title: 'AIによる拡張', description: 'AIを合理的に活用して価値を創造' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 学習内容
|
||||
|
||||
全体的に、アプリを作るための基本知識を学びます：アイデアの出所 → アイデアをアプリにする方法 → 使えるアプリから使いやすいアプリへ → AIの活用 → ユーザーの獲得。
|
||||
|
||||
1. アプリを作るにあたって、どこから来たアイデアが信頼できるか？
|
||||
2. アイデアがあれば、どうやって実現可能なアプリに分解するか？
|
||||
3. 作った後、どうやって「良いアプリ」に判断し磨き上げるか？
|
||||
4. どの段階で、どのように合理的にAIを活用して価値を拡大するか？
|
||||
5. アプリがあれば、0から最初のリアルユーザーをどう見つけるか？
|
||||
|
||||
# 1. アプリを作るにあたって、どこから来たアイデアが信頼できるか
|
||||
|
||||
多くの人がアプリを作るといえば、まず十分に印象的なクリエイティブなアイデアを思いつくことだと反応します。だから毎日ランキングをチェックし、レポートを読み、様々な人気プロダクトを研究し、他人の成功ストーリーに注目して、いつか自分も特別に違うアイデアに出会えることを願っています。
|
||||
|
||||
しかし実際のところ、多くの人は本当のアイデアを持っておらず、単にアイデアがないことに焦っているだけです。また、最初から高いハードルを設定する人もいます：面白くなければ始めない、普通は失敗と同義だと思う。でも実際に少し進んでみると、長く安定して続くアプリの多くは、深夜に思いついたものではなく、具体的な生活シーンの中で、リアルな問題の周りに少しずつ育ったものだということに気づくでしょう。
|
||||
|
||||
だから、この章が解決したいのはスタート地点の問題です：**どうすればアイデアを持てるのか？そのアイデアは本当に信頼できるのか？あなたが時間とエネルギーを投じて、それをリアルなアプリにする価値があるのか？**
|
||||
|
||||
## 1.1 アイデアとは何か
|
||||
|
||||
まず、最も基本的でありながらもよく見過ごされる問題から始めましょう：アイデアとは一体何か。
|
||||
|
||||
日常会話で人々がよく言うアイデアは、多くの場合、非常に主観的な興奮です。道を歩いていて動画を見かけ、瞬間的にこの方向がすごくクールだと思い、「私も似たようなものを作れる」と心の中で思うかもしれません。あるいはパーティーで誰かが製品の使い勝手の悪さに文句を言い、あなたが「こういうのが自動的に全部やってくれるものがあればいいのに」と口を挟むかもしれません。この時、確かに曖昧な考えはありますが、実際に作れるものとはまだほど遠いです。
|
||||
|
||||
ここでは、少し厳密な基準を設けましょう。あるアイデアが以下の条件の少なくともいくつかを満たす場合にのみ、それを「アイデア」と呼びます：
|
||||
|
||||
第一に、**明確なユーザー層に向けている必要があります**。漠然と「全員」と言うのではなく、主に誰に使われるのかを明確に説明できる必要があります。大学生、新入社員、子育て中の親、それとも独立開発者、EC事業者、小規模企業のオーナー。異なる人は同じことに対して全く異なる関心を持っており、ターゲット層さえ決まっていなければ、その後のすべての判断が宙に浮いてしまいます。
|
||||
|
||||
第二に、**具体的なシーンに根ざしている必要があります**。このアプリはユーザーがいつ使うのか、朝の通勤電車の中、仕事の合間、寝る前、週末の資料整理の時。ノートやタスク管理のような一見抽象的なツールであっても、よく観察すれば、高頻度で使われる部分は必ず特定のシーンと密接に結びついています。
|
||||
|
||||
第三に、**ユーザーが明確なタスクを完了するのを助ける必要があります**。タスクは大きくなくても構いませんが、説明できる必要があります。一日のToDoリストを整理する、長い記事をいくつかの要点にまとめる、会議のための構造の明確な議事録を生成する、あるいは週末の都市散策のための実行可能なルートを生成するなど。タスクを具体的に説明できれば、後の機能設計と価値評価が容易になります。
|
||||
|
||||
第四に、**現状よりも良い方法やツールを提供する必要があります**。ユーザーが元々どのようにこのことを完了していたのか、頭で覚える、紙に書く、Excel、スクリーンショットで保存、それとも異なるアプリ間を行き来するのか。あなたが提供できるのが、明らかに手間が省けて、安定して、快適な方法であれば、そのアイデアは真に価値を持ち始めます。
|
||||
|
||||
|
||||
|
||||
上記の思考について、うまく整理できなくても大丈夫です。今はAIの時代です。上記の内容を完全なプロンプトに整理し、あなたのアイデア、ターゲットユーザー、使用シーンをまとめて書き込み、LLMに補完と洗練を任せることができます。モデルを常にオンラインのプロダクトパートナーとして扱い、繰り返し対話、質問、修正することで、曖昧な概念を具体的にすることができます。
|
||||
|
||||
## 1.2 アイデアとユーザーニーズ：自己満足を避ける第一の防衛線
|
||||
|
||||
多くの人が初めてアプリを作る時に最も陥りやすい罠は、自己満足です。自己満足とは、自分のアイデアに夢中になり、世界を変革する方向だと感じているのに、一般ユーザーに話すと反応が冷静で、礼儀正しく頷きながらも「いいですね」としか言わず、製品がリリースされてもダウンロードも長期利用もされないことです。
|
||||
|
||||
この状況を避けるには、アイデアとユーザーニーズを分けて考える必要があります。
|
||||
|
||||
まず**ユーザーニーズ**とは何かを話しましょう。比較的簡単な言葉で要約できます：具体的なシーンにおいて、**ユーザーが目標を達成するために、下げたい様々なコスト、または増やしたい様々な価値。** ここでのコストは、お金だけでなく、時間、労力、精神的負担、ミスのリスク、さらには社交的なプレッシャーも含まれます。
|
||||
|
||||
このことを理解すると、**単なるかっこよさだけではニーズを構成できない**ことがわかります。多くのアイデアは確かに十分に斬新ですが、ユーザーが特定の目標においてより省力的に、より安心して、より自信を持てるようにしない限り、真に持続可能なアプリを支えることは困難です。
|
||||
|
||||
アイデアとニーズの間には、よく見過ごされる溝があります。**アイデアはあなたの主観的判断を表し、データによる裏付けではありません。** ニーズは、ユーザーが実際に何を経験し、何に悩んでいるかを表します。
|
||||
|
||||
アイデアを判断する際、簡単な区別方法があります。**真のニーズか偽のニーズか**を見ることです。真のニーズの明確な特徴は、あなたのアプリがなくても、ユーザーが積極的にこの問題を解決しようとしていることです。
|
||||
|
||||
偽のニーズの典型的な状況はまさに逆です。あなたが積極的に提起しなければ、大多数の人はそれが問題であることに気づきません。
|
||||
|
||||
だから、**自己満足を避ける第一の防衛線はユーザーニーズを理解することです。** 最初に、「自分以外に、このことで真剣に悩んでいる人は誰か」という一見簡単だが非常に重要な質問に答える必要があります。
|
||||
|
||||
|
||||
|
||||
## 1.3 良いアイデアが良い理由
|
||||
|
||||
すべてのアイデアが同じ運命を辿るわけではありません。良いアイデアは、数日で粗いがプロセスが通るバージョンを作っても、自然に少数のリアルユーザーを引き付けます。悪いアイデアは、機能を詰め込み、広告にお金をかけ、様々なプラットフォームで宣伝しても、最終的に外力で一時的にデータを積み上げるだけで、すぐに静寂に帰します。
|
||||
|
||||
この背後にある最も本質的な違いは、アイデア自体が重要な問題点に触れているかどうかです。
|
||||
|
||||
**良いアイデアは、自然に成長を迎えます**：非常に質素な形態で登場しても、ユーザーの手元の具体的な小さな問題を解決できれば、ある程度の自然な成長を得ることができます。例えば、音声を素早くテキストに変換する小ツールは、最初はウェブページに数個のシンプルなボタンがあるだけかもしれませんが、認識品質が良ければ、多くの人がリンクを友人に転送するでしょう。
|
||||
|
||||
**悪いアイデアは、最初から外力駆動に依存することになります**。外見が良くても、継続的にプッシュしなければならず、ユーザー獲得の努力を緩めると、使用データは急降下します。
|
||||
|
||||
もちろん、上記の状況は絶対ではありません。例えば初期市場ではユーザーが価値に気づくまで一定の遅延がある場合や、競合がある場合は外観、操作の難易度、ブランド特性などを考慮する必要がありますが、これらはより深い内容であり、当面は考慮しません。
|
||||
|
||||
選択は努力より重要です。
|
||||
|
||||
## 1.4 良いアイデアの出所：4つの主要な出所と具体的な例
|
||||
|
||||
多く人がアイデアを思いつくとき、机の前に座って天井を見つめ、いつかインスピレーションが突然降ってくるのを待つ姿を想像します。しかし現実の良いアイデアは、生活の中の小さな観察、コミュニティでの繰り返しの質問、インターネット上の山のような不満、そして既存のプロダクトから少しずつ選別されるものです。
|
||||
|
||||
以下の4つの出所から、真剣に取り組めば、スタートできる方向を容易に見つけることができます。
|
||||
|
||||
|
||||
|
||||
### 自分の生活を愛する
|
||||
|
||||
非常に素朴ですが効果的な原則があります：**生活に参加すればするほど、問題を発見しやすくなり、何が解決する価値があるかを判断する能力も高まります。** 参加感とは、画面越しに他人の生活を見るのではなく、自分で体験し、試し、失敗することです。
|
||||
|
||||
例えば、猫を飼うのが好きなら、猫と一緒に過ごす一日は、100件の「猫の飼い方のコツ」を見るよりも情報量が多いです。**毎回の少し不快な体験は、潜在的なプロダクトの手がかりです。**
|
||||
|
||||
猫を写真に撮ることについて考えてみましょう。多くの人が経験したことがあるでしょう：スマホをかざしても猫は絶対にカメラを見てくれない。下を向いて爪を舐めるか、別の隅を見つめている。だったら、スマホやタブレットの画面に自動で動く赤い点、羽、小さな虫のアニメーションを表示して、猫の視線を引きつける小ツールがあってもいいのでは。シャッターボタンを押すと、フロントカメラの近くで自動的に一周動いて、猫の視線をカメラの方向に「騙し」、ついでに連写して、その中からはっきりして見栄えの良いものを選ぶ。さらに一歩進めば、このアプリは各猫がどの色、どの移動軌跡に最も興味を持つかを記録し、次回は自動的にその猫の「専用」遊びモードを使って成功率を高めることができる。
|
||||
|
||||
|
||||
|
||||
メイクやスキンケアを楽しむなら、家のキャビネットに並ぶ製品一つひとつの背後には、大量の試行錯誤と意思決定があります。スマートフォンのアルバムで毎回のメイクの写真を撮る習慣があるかもしれませんが、振り返る時に、その日どの口紅、どのアイシャドウを使ったかを少しずつ思い出す必要があります。これらの情報を体系的に記録して、自分だけのメイク図鑑にできるかどうか。さらにアプリに統計を取らせて、特定のメイクがどんな場面で最も使われているか、どの組み合わせが写真で最も良い表現になるかを把握できれば、次にメイクを選ぶ時にゼロから考える必要がなくなります。
|
||||
|
||||
もう少し具体的に、多くの人が経験するシーンを考えてみましょう。朝の時間がとても急で、アルバムを開いて「前回の成功した通勤メイク」を探そうとしても、長い時間探した末にその時どの製品を使ったか思い出せない。だったら、メイクの写真を撮った後、スマートフォンに向かって「今日は面接メイク、01番のオレンジブラウンアイシャドウとローズベージュのリップを使った」とだけ言えば、アプリが自動的に認識して「メイクレシピ」を生成し、写真と結びつける機能があってもいい。次回は「面接」「オレンジブラウンアイシャドウ」「ローズベージュ」で検索するだけで、関連するすべてのメイクがワンタップで表示され、「今日は通勤に適した、5分で完成するメイクだけ見る」というレコメンドリストも自動生成される。毎朝節約できる数分は、非常に具体的な「解決された問題」です。
|
||||
|
||||
City walkや各種のスロートラベルが好きなら、すでに様々なツールを使って体験を組み立てているかもしれません：地図アプリでルートを記録し、メモ帳に行きたいカフェをリストアップし、アルバムに沿道の写真と感想が散在している。では、ルート、チェックインスポット、写真、テキストを一つにして、タイムラインとストーリー性のあるウォーキングログにできるアプリは作れないか。さらに、そのルートをワンタップで友人にシェアし、同じ都市で違うバージョンを歩けるようにする。
|
||||
|
||||
さらに日常的な小さなディテールを掘り下げてみましょう。多くの人がcity walkの時に、「その角がとても美しいと思ったのに、家に帰って地図で全く見つけられない」という挫折感を経験しています。超軽量な機能を作れないか。歩いていて感覚のある角に来たら、イヤホンのボタンを長押しして、「ここにマーク、デート散歩に適した道」と言えば、アプリが瞬時に現在地に音声付きのマークポイントを落とし、時間、天気、騒音レベルを自動記録する。後で自分や友人がこの都市の地図を開くと、「通行者実測の雰囲気スポット」が見える。一人でぼーっとするのに適した場所、夜景を見るのに適した場所、友達と歩きながら話すのに適した場所。本来「歩き過ぎて忘れる」小さな角が、このように徐々に質感のある都市体験データベースに育っていく。
|
||||
|
||||
これらの例が説明したいのは一つのことだけです：**自分の生活を愛する必要がある。生活が最高のアイデア出所です。** 毎日遭遇する困惑、その場で思いついた応急処置、少し面倒だけど我慢してきた場所。これらに少し多く目を向け、小さなツールで改善できるかどうかを考えてみれば、すべて未来のプロダクトの原型になり得ます。
|
||||
|
||||
### 自分が持つユーザー資産から発掘する
|
||||
|
||||
ユーザー資産とは、簡単に言えば、あなたがすでにリーチできる人々のことです。読者、運営するコミュニティ、会社の同僚グループ、長期参加している趣味コミュニティなどです。**一部の人々が日常何を話し、何に悩み、何を期待しているかを安定して聞けるチャネルがあれば**、ゼロから始める人よりも大きなアドバンテージがあります。
|
||||
|
||||
よくある例を挙げます。あなたがデザイナーコミュニティの主催者であれば、毎日グループで見えるコンテンツは、実は非常に貴重なニーズプールです。誰かがクライアントが常に修正を繰り返すと文句を言い、誰かが特定の素材サイトの課金方式に不満を持ち、誰かが異なるサイズ間の調整が時間の無駄だと感じている。各不満の背後には、潜在的なプロダクトの手がかりが隠されています。
|
||||
|
||||
あなたが試験対策コミュニティにいる場合、グループには長期的に似たような話題が溢れているかもしれません。今日の調子が悪い、計画がまた延期された、どの資料を見るのがより効率的か、どうすれば継続的にチェックインできるか。想像で考える必要はなく、しばらく観察して、皆が繰り返し言及する共通の難題を整理すれば、学習系アプリの初期機能の方向性を大まかに描くことができます。
|
||||
|
||||
### 公開の場からニーズを発掘する
|
||||
|
||||
自分のコミュニティや読者層がなくても心配する必要はありません。インターネット上では毎日、無数の人が様々なプラットフォームで自分の困難と不満を語っています。公開の場でのこれらの声は、それ自体が巨大な宝庫です。
|
||||
|
||||
あなたの興味のある業界に関連するいくつかのプラットフォームを選び、定期的に感情の色のある重要ワードを検索できます。例えば、**「面倒」「おすすめある？」「どう解決する」「本当に不便」「もっといい方法ない？」** など。そして忍耐強く投稿とコメントを見て、二種類の情報に注目してください。
|
||||
|
||||
一つ目は、ある問題が長期的に、繰り返し言及されていること。就職関連のセクションでは、定期的に履歴書の書き方、自己紹介の準備、面接結果のフォローアップについて質問がある。育児グループでは、離乳食の組み合わせ、生活リズムの調整、親子コミュニケーションの困惑が繰り返し現れる。小規模EC事業者のコミュニティでは、在庫管理、キャッシュフロー、スタッフのシフトが常に心配されている。これらの長期に存在する繰り返しの問題は、業界が繰り返し露呈しているシステム的なペインポイントです。
|
||||
|
||||
もう一つは、特定のシーンでユーザーが非常に不器用な方法で無理やりやっていること。例えば、すべてのToDoを紙に書いてから写真を撮ってクラウドにアップロードする人。異なるアプリ間でコピーペーストを繰り返して、あるフォーマットから別のフォーマットに変換する人。異なるチャネルのデータを手動で一つの表にまとめる人。これらの場所は、少し注意深く観察すれば、プロセス化・ツール化できる多くの小さな切り口が見つかります。
|
||||
|
||||
### 巨人の肩の上に立つ
|
||||
|
||||
よく見過ごされるもう一つのアイデアの出所は、既存のプロダクトとプロジェクトです。世界にはすでに多くの素晴らしい人々が、私たちのために多くの探索の道を歩んでくれました。あなたは毎回白紙から始める必要はなく、他人が半分まで進めたところに立って、もう一歩進むことができます。
|
||||
|
||||
**ハッカソン、プロダクトイノベーションコンテスト、スタートアップ Demo Day**のような場では、多くの面白い小さな作品が現れます。それらの多くは二つの特徴を持っています：時間が厳しく、リソースが限られている。これはあなたが今作ろうとしている小アプリと非常によく似ています。だから、これらの受賞作品を見るとき、二つの問いを多くしてみると良いでしょう。もしこのものがより狭いセグメントだけにサービスしたら、もっと実現しやすくなるか。機能を半分、さらには三分の二削って、最もコアな部分だけ残したら、むしろもっと明確になるか。
|
||||
|
||||
同様に、**プロダクトランキング、オープンソースプロジェクト、ツールコレクションサイト**にリストされているツールも、思考の出発点になります。興味のあるものをいくつか選び、一つ一つ分解してみてください。それは誰のどんな問題を解決しているのか、現在の形態にはどのような明らかな不足があるのか、別のシーンや別の国に移行したらどう変わるか。コピーするのではなく、この分解練習を通じて、問題とソリューションの間の関係への理解を訓練するのです。
|
||||
|
||||
長期間これらの4つの道から素材を掘り起こし続けると、アイデアは突然頭の中に現れる奇跡ではなく、生活、他人、情報世界との長期的な相互作用から自然に育つ副産物であることがわかります。
|
||||
|
||||
## 1.5 良いアイデアを一言で要約する方法：少ないほど多いという芸術
|
||||
|
||||
アイデアがどこから来るかを大まかに知った後、次の重要な練習は、**一言で明確に説明すること**です。この練習は簡単そうに聞こえますが、実際にはかなり残酷です。なぜなら、**あなたのアイデアが本当に明確なコアをつかんでいるかという事実に直面することになるから**です。
|
||||
|
||||
人を記憶に留められるのは、相手が全面的に完璧だからということは少なく、多くの場合、ある明確な特徴があるからです。プロダクトも同じです。**十数個の機能を無理に覚えさせるより、素朴だが明確な印象を与える方が良い**です。
|
||||
|
||||
一言を書く際のよくある間違いは、過度に広範囲であることです。例えば：「ユーザーの英語力を向上させるアプリ」。一見間違っていませんが、深く掘り下げると、この文はほとんど何も言っていないことがわかります。
|
||||
|
||||
相対的に良い表現はもっと具体的です。例えば：「毎日10分の通勤時間を利用して、1ヶ月で100のコア単語を覚える暗記アプリ」。ここでは少なくとも3つのことが説明されています：使用コストは管理可能で、毎日10分だけ；予想結果は可視的で、1ヶ月で100の新単語；シーンは明確で、主に通勤中。
|
||||
|
||||
この練習は、**誰を助けるのか、どのようなシーンであなたを思い出してほしいのか、どの程度の期間でどのような結果を達成したいのか**という3つの質問に繰り返し答えることです。
|
||||
|
||||
## 1.6 AIを使って思考を発散させ、差別化を見つける
|
||||
|
||||
過去にアイデアを思いつくのは、ほとんど自分でゆっくり考えるしかありませんでした。今はAIがあり、いつでも召喚できるブレーンストーミングパートナーが増えました。
|
||||
|
||||
ある方向に行き詰まったとき、現在のアイデアをできるだけ明確にAIに説明し、いくつかのことをお願いしてみましょう。例えば、**同じコアタスクに基づいて、20種類の異なるユーザーグループをリストアップ**したり、学生、フリーランサー、子育て中の親、小規模事業者などの異なる角度から、このアイデアの可能な使用方法を再記述したりします。
|
||||
|
||||
**一般的なアイデアは必ずしも無効なアイデアではありません。** 単語暗記、ToDoリスト、家計簿、習慣トラッキングのような一見一般的な方向は、背後にある問題が実際に普遍的に存在するからこそ、継続的に作られます。この場合、**誰が特定の小グループをよりよく理解し、細部でより彼らの生活に寄り添えるか**が競争になります。
|
||||
|
||||
AIの価値は、あなたに代わって決定を下すことではなく、本来非常に狭い道を、より完全な地図に変えることにあります。
|
||||
|
||||
## まとめ
|
||||
|
||||
いくつかの簡単な次元を使って、アイデアがすでに十分明確かどうかを検査する方法を学びました。自分がかっこいいと思うことと、ユーザーが本当に必要としていることの違いを区別する必要があります。良いアイデアが良い理由は、最初からあるペインポイントに立っているからです。自分の生活、ユーザー資産、公開情報、既存プロダクトから継続的に手がかりを掘り起こすことを学びました。一言でアイデアを説明する練習も必要です。AIを思考を拡張するパートナーとして使い、判断を代替するツールとして使わないことも学びました。
|
||||
|
||||
手元に1〜3個のそのようなアイデアがあり、**一言で説明できる**（誰に使われるのか、どのシーンで、おおよそどんな結果をもたらすのか）時、新アイデアを考え続ける衝動を止めて、次のステップに注意を向けることができます：その中の一つを、実際に作れて、実際のユーザーに使えるアプリに分解する方法。
|
||||
|
||||
アイデアが少し微妙でも大丈夫。最初は微妙なのが正解です。**完成は常に完璧より重要です。** 始めなければ終わりはありません。
|
||||
|
||||
## 📚 課題
|
||||
|
||||
上記の内容に基づいて、以下の課題を完了してください：
|
||||
|
||||
1. 自分の興味に合わせて、AIを使っていくつかのアプリの「アイデア」を生成する
|
||||
2. AIに自分のアイデアに基づいて、それが真のニーズか偽のニーズかを評価させ、ユーザーニーズインサイトと提案を得る
|
||||
3. 4つの主要な出所から1〜2つの出所を選んで「アイデア」を得るか、AIにいくつかのアプリの「アイデア」を生成させる
|
||||
4. 上記のすべての Idea から、最も好きな3つのアイデアを選び、情報量の豊富な一言でそのアイデアを要約してみる
|
||||
|
||||
# 2. アイデアがあれば、どうやって実現可能なアプリに分解するか
|
||||
|
||||
前の章で解決したのはスタート地点の問題でした：一体どのようなアイデアが真剣に扱う価値があるのか。
|
||||
|
||||
本当の挑戦はここから始まります。多くの人がこのステップでつまずきます：頭の中には一見完全な青写真があるのに、いざ手を動かすと複雑すぎて手がつけられません。
|
||||
|
||||
|
||||
|
||||
考えないで！今がその時です！この章では、アイデアから実現可能なバージョンへの分解方法を学びます。ゼロからあるものを作るのは天才に依存するのではなく、**発散、収束、分解、詳細化、参考、質問**という一連の反復練習可能な具体的なアクションに依存します。
|
||||
|
||||
## 2.1 アイデアからソリューションへ：ダブルダイヤモンドモデルの発散と収束
|
||||
|
||||
ページを描いてアイデアを出すことを学んだ後、すぐにもう一つの一般的な問題に直面するでしょう：アイデアがどんどん増えてくること。ホワイトボードに様々なシーンと機能を書き連ね、紙には異なるページバージョンが描かれ、一見達成感がありますが、実際にやろうとすると逆に手がつけられなくなる。なぜなら、すべてが重要に見え、どれも試す価値があるように思えるから。
|
||||
|
||||
この時、非常に古典的で分かりやすい思考フレームワークを使う必要があります：**ダブルダイヤモンドモデル**。このモデルの意味は実はとても素朴で、人生の多くの段階で、最初に発散してから収束する必要があり、最初からすべてを一度にやり切ろうとしてはいけないということです。
|
||||
|
||||
### ダブルダイヤモンドモデルとは
|
||||
|
||||
ダブルダイヤモンドモデルは、英国デザイン評議会が提案したイノベーションとデザインプロセスフレームワークです。プロセス全体を連続する二つの菱形（「ダブルダイヤ」）に例えます。最初のダイヤは「問題の発見」から「明確な問題の定義」へ、まず広く発散し、十分に調査・理解してから、真に解決すべきコア問題を収束・整理することを強調します。2番目のダイヤは「解決策の発展」から「最終的なソリューションの納品」へ、可能な解決アプローチを大胆に発散・探索・反復し、その後収束・選別・磨き上げて最適で実行可能な案を出すことを強調します。ダブルダイヤモンドモデルは、問題とソリューションの両方の段階で「発散—収束」のプロセスを経ることを強調し、最初から解決策に飛びつくことを避け、イノベーションの品質と成功率を向上させます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 第一ダイヤ：問題を理解し、単点から全体像への発散と収束
|
||||
|
||||
**ダブルダイヤモンドモデルでは、第一ダイヤは問題そのものに関するものです。** まず曖昧な認識から始め、徐々により多くの関連状況と可能性を発散させ、その後一度収束して、真に解決する価値のある問題点を見つけます。
|
||||
|
||||
アプリに対応させると、次のようなことがあります。
|
||||
|
||||
**発散段階では、ユーザーが直面する可能性のある使用シーン、遭遇する可能性のある障害、期待する結果をできるだけ多く列挙します。** 急いで判断せず、頭の中の関連するものをすべてまず並べます。
|
||||
|
||||
**収束段階では、最も一般的で最も痛い1〜2つの状況だけを選ぶよう自分に強います。** 例えば、多数のシーンから、最も多く言及されたのは、非常に長い作業ドキュメントを受け取った時に、このドキュメントが何を言いたいのか、主な結論は何かをまず把握したいということだと発見したとします。それなら、第一版のアプリの目標をこう定めることができます：ユーザーが5分以内に長文のコア意味を理解できるようにする。
|
||||
|
||||
第一ダイヤの終了時には、開始時よりも明確になっているべきです：**あなたが真に解決する必要のある問題は何か、他の周辺問題と比べて、なぜ優先度が高いのか。**
|
||||
|
||||
### 第二ダイヤ：ソリューションを設計する、粗いアイデアから実行可能な案へ
|
||||
|
||||
**ダブルダイヤモンドの第二部分は、ソリューションの誕生に関するものです。** どの問題を解決するかを大体把握した後、次にするのは、その問題に対してできるだけ多くの解決方法を考え、その中から第一版に最も適したものを選び出すことです。
|
||||
|
||||
発散段階では、絶えずアイデアを追加し続けることを意味します。様々な機能、より細かいシーン、様々な可能なプレイ方法をブレインストーミングできます。
|
||||
|
||||
収束段階では、シンプルだが非常に実用的な評価ツールを取り出します：ユーザー価値 × 実現可能性 × 時間コスト。各アイデアにこの3つの次元で大まかなスコアをつけ、例えば1〜5点とし、総合スコアが高く、時間コストが管理可能なアイデアをMVP、つまり最小実行可能バージョンの構成要素として優先的に選びます。
|
||||
|
||||
このプロセスで絶えず自分に思い出させるべきことが一つあります：**第一版の目標は完璧なアプリを作ることではなく、実際に存在し、誰かが本当に使えるバージョンを作ることです。** すべてを網羅する必要はなく、一つの具体的なタスクで十分にまともに機能すればいいのです。
|
||||
|
||||
ダブルダイヤモンドモデルを使って思考を整理することに慣れると、多くの元々絡み合っていた状況がずっとスッキリします。どの段階で可能な限り多く考え、どの段階で断固として一部の可能性を削るべきかが分かります。
|
||||
|
||||
## 2.2 実行可能なステップを得る：抽象から具体へ
|
||||
|
||||
発散した後、アイデアを得ることは簡単ですが、実行可能なステップを得ることは非常に困難です。「効率を向上させるツールを作りたい」と言っても、抽象的すぎて手がつけられません。ここに必要な能力は**分解と詳細化**です。大きな抽象的な目標を、すぐに手を動かせる最小の実行可能項目に分解して詳細化することです。
|
||||
|
||||
|
||||
|
||||
### 生活の例から始める：「ハンバーガーが食べたい」とは一体何か
|
||||
|
||||
「ハンバーガーが食べたい」という文は一見複雑ではありませんが、真剣に分解すると、多くの具体的な分岐が隠されています。
|
||||
|
||||
まずは**動機と内面のコアニーズ**。本当にハンバーガーが食べたいのか、味が恋しいのか、素早く食事を済ませたいのか、友達と集まりたいのか、それともいい写真を見て食いつきたのか。一見無関係に見えますが、後の選択に直接影響します。
|
||||
|
||||
次に**行動の範囲**。どんなハンバーガーを食べたいか、何時に食べたいか、ハンバーガーだけか、セット全体が欲しいか。
|
||||
|
||||
さらに**どうやって実現するか**。店に行くのか、デリバリーか、自分で作るか。それぞれの選択に対応する行動ルートは全く異なります。
|
||||
|
||||
分解をすべて明確にした後、曖昧な「ハンバーガーが食べたい」という言葉は、具体的なアクションステップの列になります。
|
||||
|
||||
**分解と詳細化の意義はここにあります：聞こえは大きくて抽象的な願いを、具体的に実行可能なリストへと導くことです。**
|
||||
|
||||
### アプリの例：ドキュメント処理効率の向上をどこから始めるか
|
||||
|
||||
もう少し複雑で段階的な例を見てみましょう。ある正当な願いがあると仮定します：「ドキュメント処理効率を向上させるアプリを作りたい」。この方向は正しいですが、この半分の文で止まってしまうと、どこから手をつけていいかわかりません。
|
||||
|
||||
ここでは分解と詳細化の方法を使って、一歩ずつ具体的にしていきます。時間の都合上、ここでは2層の分解方法のみを示します。
|
||||
|
||||
#### 第一層の分解と詳細化
|
||||
|
||||
**まず、「ドキュメント」とは何かを定義する必要があります。** ドキュメント自体は非常に広い概念で、表、Wordレポート、PDFファイル、Markdownテキスト、TXTメモ、スキャンされた画像ドキュメント、数式を埋め込んだ学術論文などが含まれます。
|
||||
|
||||
**次に、「処理」とは何かを定義する必要があります。** 50ページのレポートを5ページの読みやすい要約にするのか、様々な形式のWord、PDF、Markdownを統一テンプレートにするのか、翻訳、書き換え、推敲なのか。
|
||||
|
||||
**「アプリ」についても定義する必要があります。** 自分専用の小ツールなのか、将来ユーザーがいるものなのか、Webアプリなのか、モバイルアプリなのか、既存システムに埋め込まれる小機能なのか。
|
||||
|
||||
**「効率」も具体的に分解する必要があります。** 速度だけか、速度と品質とエラー率と理解の難易度を含むのか。
|
||||
|
||||
|
||||
|
||||
#### 第二層の分解と詳細化
|
||||
|
||||
第一層の分解結果が「AIを使ってPDFドキュメントをテキストに変換する速度と品質を向上させるWebアプリを作りたい」という文になったとします。
|
||||
|
||||
しかし、この記述でも多くの重要な情報がまだ曖昧です。「どのAIを使うか」「どの程度まで向上させるか」「どの使用シーンに対応するか」「どのようなユーザーを対象とするか」などです。
|
||||
|
||||
さらに分解を続け、この文をより細かい粒度の設計決定と技術案に変える必要があります。
|
||||
|
||||
最終的に、以下のような明確な記述になります：
|
||||
|
||||
> ユーザーにブラウザベースの小ツールを提供し、構造が比較的明確でテキスト主体のPDFレポートを優先サポートし、適応した解析プロセスと軽量AIクレンジングを通じて、約10秒以内に段落構造が明確でタイトル階層が基本的に保持される編集可能なテキストを出力し、ログインなしで使用可能にする。
|
||||
|
||||
|
||||
|
||||
抽象から具体への移行は、「ドキュメント処理効率を向上させるアプリを作りたい」という大きな願望を、誰でも（あるいはAIでも）すぐに理解して実行を開始できるタスクリストに分解することです。
|
||||
|
||||
## 2.3 ホワイトボードでアプリを構想する：最初のアプリを描く
|
||||
|
||||
多くの人がアプリを作り始めるとき、最初に思い浮かぶのはコード、バックエンド、データベース、API、フレームワークです。しかし、最初にすべての注意を技術に向けると、最も重要なものを見落とす危険があります：**ユーザーがここで一体何をするのか。**
|
||||
|
||||
最も簡単でよく見過ごされる方法は、まず描くことです。ホワイトボード、白紙、メモ帳で構いません。ユーザーが入ってから出るまでの全経路を、数枚の簡単なページスケッチで描き出し、エディタを開いてコードを書くのではなく先に構想します。
|
||||
|
||||
アプリ全体をまず3種類のページに分けることができます：入口ページ、操作ページ、結果ページ。
|
||||
|
||||
|
||||
|
||||
### 入口ページ：ユーザーがどこから入り、最初に何を見るか
|
||||
|
||||
入口ページは、ユーザーとアプリが初めて出会う場所です。多くの人が入口を設計する時、まず汎用的なトップページを思い浮かべ、機能ボタン、モジュール入口、広告枠を詰め込み、これで十分な量と素晴らしさがあるように見えます。しかし、このページを紙に描いて壁に貼り、初めて来た人のふりをすると、突然非常に現実的な問題に気づくでしょう：**「結局どこを押せばいいんだ？」**
|
||||
|
||||
入口ページを描く時、まず自分をガイドとして見なすことができます。いくつかの非常に具体的な質問をします：ユーザーはどのような方法で入ってくるのか、シェアリンクのクリックか、アプリストアでの検索か、ウェブページでのQRコードスキャンか。異なるソースはユーザーの予想を全く異なるものにします。
|
||||
|
||||
### 操作ページ：ユーザーが何を入力、クリック、選択するか
|
||||
|
||||
ユーザーが前に進むことを決めた後、次は操作ページに落ちます。つまりアプリの作業領域です。ここがユーザーと本当にインタラクションする場所であり、最も過剰に複雑に設計されやすい場所でもあります。
|
||||
|
||||
操作ページを描く時、**ユーザーに一つのことだけさせる**という非常に効果的な練習があります。
|
||||
|
||||
紙の上で操作ページを構想する利点は、非常に低コストで異なるバージョンを試せることです。
|
||||
|
||||
### 結果ページ：ユーザーが何を得て、どう表示するか
|
||||
|
||||
結果ページでは、**ユーザーが最も関心するコア情報を最も目立つ位置に配置**する必要があります。
|
||||
|
||||
入口ページ、操作ページ、結果ページをすべて描いた後、矢印で繋ぎ、**ユーザーが初めて入ってから終了までの一歩一歩を**描きます。
|
||||
|
||||
この章のコアは一言です：まずユーザーの操作プロセスを描き、その後技術実装を考える。コードが書けなくても、**数枚の簡単なスケッチでアイデアを目に見えるアプリの原型に変える**ことができます。
|
||||
|
||||
## 2.4 他人のアプリを参考にする：賢く「宿題を写す」
|
||||
|
||||
多くの人が最初のアプリを作る時、一種の心理的負担があります：ゼロから始めなければならず、ページ構造、インタラクション方法、ビジュアルレイアウトはすべて完全にオリジナルでなければならず、そうして初めてプロダクトを作っていると言えると。現実は、この原則を守ると、無関係な場所で大量のエネルギーを無駄にすることになります。
|
||||
|
||||
アプリデザインにおいて、より効率的で成熟した態度があります：**賢く宿題を写す**です。単なる模倣ではなく、他人がすでに検証した良い解決策を選択的に借用し、あなたのユニークな価値にエネルギーを残すことです。
|
||||
|
||||
インターネット上にはアプリのインターフェースのスクリーンショットを収集するウェブサイトがたくさんあり、アプリストアの詳細ページも大量にあります。これらは巨大な参考図鑑です。自分の方向に近いアプリをいくつか選び、サンプルのように一ページ一ページ見てください。
|
||||
|
||||
重点的に観察するのは配色の美しさではなく、いくつかの重要なエリアでどのように処理しているかです：
|
||||
|
||||
- ナビゲーションバーの設計、下部か上部か、固定のコア入口か一つのメインボタンだけか
|
||||
- フォームの構成、一度に同じページで全て入力するか、複数の小ステップに分けるか
|
||||
- 結果表示時に、最も重要な情報が最も目立つ位置に置かれているか、次要情報はどのように整理されているか
|
||||
- 新ユーザーが初めて来た時、使用方法を説明する短いガイドフローがあるか
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
具体的には以下のウェブサイトを参考にできます：
|
||||
|
||||
- [https://www.uisources.com/](https://www.uisources.com/)
|
||||
- [https://screenlane.com/](https://screenlane.com/)
|
||||
- [https://pagecollective.com/](https://pagecollective.com/)
|
||||
- [https://patttterns.net/](https://patttterns.net/)
|
||||
- [https://mobbin.com/](https://mobbin.com/)
|
||||
- [https://refero.design/](https://refero.design/)
|
||||
- [https://scrnshts.club/](https://scrnshts.club/)
|
||||
- [https://godly.website](https://godly.website)
|
||||
|
||||
## 2.5 すべてが準備できてからユーザーニーズを調査するのを待たない
|
||||
|
||||
多くの人がユーザー主導のプロダクトを作ると言いながら、実際には最初に自分の心の中の完全なバージョンを作ってから他人に見せる習慣があります。**これは一見体面が良いですが、プロダクトの観点からは非常に危険な習慣です。**
|
||||
|
||||
解決策：**描きながら聞く、作りながら聞く、作ってから聞くのではない。**
|
||||
|
||||
### 描きながら聞く：紙の段階からフィードバックを収集する
|
||||
|
||||
ホワイトボードや紙に入口ページ、操作ページ、結果ページを描いた時点で、すでにユーザーと対話する基盤があります。
|
||||
|
||||
### 作りながら聞く：半完成品の段階で人を招いて試用する
|
||||
|
||||
基本プロセスが通る半完成品バージョンがあれば、一人で黙って使う理由はありません。**定義した最小タスクを完了できれば、すでにリアルユーザーの試用を招待する条件を備えています。**
|
||||
|
||||
**このプロセスであなたがすべきは弁解ではなく、観察です。**
|
||||
|
||||
### 粗雑さを恐れない
|
||||
|
||||
早い段階で問題を露呈させることは、コストが最も低いです。
|
||||
|
||||
## 📚 課題
|
||||
|
||||
上記の内容に基づいて、以下の課題を完了してください：
|
||||
|
||||
1. 任意のLLMを使用して、前のアイデアについてAIにダブルダイヤモンドモデルを参考に発散結果を出させ、あなたがその発散結果から実行可能なソリューションセットを選ぶ必要があります。
|
||||
2. 以前に思いついたアイデアについて、分解と詳細化の方法を使用して、より具体的な実行可能な内容を得てください。例：「ユーザーにウェブツールを提供し、20ページ以下のテキスト主体PDFをアップロードすると、10秒以内に段落構造が明確でタイトル階層が保持された編集可能テキストを得られ、ワンタップコピーと.txtダウンロードをサポートする。」
|
||||
3. 詳細化したアイデアに基づいて、ホワイトボードでアプリを描いてみてください。アプリは2つの部分に注目する必要があります：UIはどのように設計すべきか、どのような機能があるべきか、各機能はどこにあるか。
|
||||
|
||||
# 3. 作った後、どうやって「良いアプリ」に判断し磨き上げるか
|
||||
|
||||
アプリが作られて実際の世界で人に使われるようになると、全く別の段階に入ります。これまでの議論はすべてアイデアとデザインの段階に留まっていましたが、今、プロダクトは初めて実際の使用シーンで検証されます。ユーザーが間違えた場所、躊躇した場所、立ち止まった場所が見えると同時に、どのステップが驚くほどスムーズか、あるいはあるコーナーで予想外に長く留まったかも見えるでしょう。これらのディテールは、頭の中のプロダクトへの様々な想像よりもはるかに正直です。
|
||||
|
||||
この章で解決するコア問題は：アプリがすでに作られ、初期ユーザーが使用している時、良いアプリからどれくらい離れているか、そしてどのように実際の使用情報を利用して少しずつ磨き上げるか。
|
||||
|
||||
## 3.1 良いアプリとは：4つのコア特徴
|
||||
|
||||
アプリが良いかどうかを判断するには、自分がどれだけ好きか、ダウンロード数や一両日の使用回数だけを見るのではなく、より基礎的で安定した特徴があるかどうかを見る必要があります。簡単に言えば、以下の特徴を参考にできます：
|
||||
|
||||
### 良いアプリは具体的な価値をもたらす
|
||||
|
||||
良いアプリの最も直接的な特徴は、あるシーンでユーザーに実用的なメリットをもたらすことです。このメリットは大きくなくても、高度な言葉でパッケージングする必要もありませんが、具体的に説明できる必要があります：**ユーザーに何を少なくさせたか、どれだけの時間を節約したか、あるいは何をミスしにくくしたか。**
|
||||
|
||||
|
||||
|
||||
例えば、簡単な会議議事録ツールが、録音をアップロードするか会議中に直接録音するだけで、終了後に自動的に構造化された会議議事録を生成し、ToDo、責任者、締め切りをリストで明確にするなら、それはタイピングの時間だけでなく、記録、整理、選別、フォーマット出力の全プロセスの精神的労力を節約します。
|
||||
|
||||
### ユーザーが直感的に使える、マニュアルなしでわかる
|
||||
|
||||
もう一つの過小評価されがちですが極めて重要な特徴は、**良いアプリは通常あまり説明を必要としない**ことです。ユーザーが初めて開いた時、直感で大体どこから始めればいいか分かり、何をクリックすると何が起きるかが分かります。
|
||||
|
||||
|
||||
|
||||
**良い使い勝手は、本質的にユーザーコストに対するプロダクトの尊重です。** あなたは一つのことを認めているのです：誰にもあなたのアプリを研究する義務はない。
|
||||
|
||||
### 高頻度または重要なシーンで自然にあなたを思い出す
|
||||
|
||||
良いアプリはしばしば安定した使用リズムを持っています。高頻度であるか、重要であるか。**高頻度とはユーザーの日常に溶け込んでいること**。重要とは毎日使わなくても、特定のシーンに遭遇するとユーザーが真っ先にあなたを思い出すこと。
|
||||
|
||||
**本当に警戒すべきは、ユーザーが高頻度にも使わず、重要シーンでも積極的に思い出さない**ことです。
|
||||
|
||||
### 利他心
|
||||
|
||||
本当に良いアプリは、比較的素朴な利他心を持っています。確かにどう生き残るかを考え、合理的な課金方法も設定しますが、デザインのパスと体験において、優先順位は常に：**ユーザーがこのことをよりスムーズに完了できるようにするか、追加の障害を作るために余計なステップを加えるか。**
|
||||
|
||||
もう一つ重要なことがあります：**良いアプリは必ずしも大きなアプリである必要はありません。** 小さくても、ある人々、あるシーン、あるタスクに特化していれば、その小さな部分で十分に優れています。
|
||||
|
||||
## 3.2 ニーズインサイト：マズローの欲求階層理論
|
||||
|
||||
|
||||
|
||||
アプリを作る前に、多くの人は機能レベルの思考に直接飛びつきます。しかし、アプリが生き残れるかどうかを決定するのは、あなたが人間のどのレベルの欲求に触れているか、そしてどれくらい正確に触れているかです。
|
||||
|
||||
マズローの欲求階層理論は、5つの層に分けられます：生理的欲求、安全の欲求、所属と愛の欲求、尊重の欲求、自己実現の欲求。
|
||||
|
||||
### 生理的・生存に関連するニーズ
|
||||
|
||||
この層は最も基礎的で、食べる、寝る、生存状態そのものに直接関係します。フードデリバリー、食材購入、ランナーサービス、予約、配車などの典型的な配送・移動サービスは、本質的にユーザーがより低い時間コストで最も基本的な問題を解決するのを助けています。
|
||||
|
||||
あなたのアプリがこの層で頑張る場合、一つの特徴があります：**ユーザーは安定、信頼性、予測可能性に特に敏感**です。
|
||||
|
||||
### 安全感と確実性のニーズ
|
||||
|
||||
安全のニーズには、物理的な安全だけでなく、経済的、情報的、心理的な安全感も含まれます。
|
||||
|
||||
多くのツール型アプリは、実際には主にこの安全の層で機能しています。家計簿、資産管理、保険アシスタント、契約テンプレートツール、パスワードマネージャー、バックアップツール、プライバシー保護ツールなど。
|
||||
|
||||
この種のプロダクトをデザインする時、もう一つ聞いてみてください：**あなたは一体ユーザーのどの種類のリスクを下げているのか、お金の、時間の、関係の、それともコンプライアンスと法務の。**
|
||||
|
||||
### 帰属感、つながり、認められること
|
||||
|
||||
さらに上の層は、所属と愛のニーズです。簡単に言えば、一人になりたくない、ある人たちとつながりたいということです。この層は、ソーシャル、コミュニティ、趣味グループアプリの本拠地です。
|
||||
|
||||
もしあなたのアプリがこの層に立とうとするなら、コンテンツだけでは不十分です。考えるべきは：**ユーザーはなぜここを「仲間がいる場所」だと思うのか、ここに痕跡を残し、他人と軽くてもリアルなインタラクションを起こしたいと思うか。** そうでなければ、あなたが作っているのは単方向の放送ツールです。
|
||||
|
||||
### 尊重、自己価値、達成感
|
||||
|
||||
さらに上の層は、尊重と自尊のニーズです。人は受け入れられるだけでなく、ある段階で意識し始めます：私はここでまともな人間なのか、見られ、認められているのか、やったことが誰かに知られているのか。
|
||||
|
||||
大量のチェックイン、バッジ、ランキング、称号、達成システムが、実はこの層で機能しています。
|
||||
|
||||
この層では、重要はインセンティブシステムを作ったかどうかではなく：**あなたのアプリがユーザーに蓄積できるステージを提供しているか、初心者から熟練者への変化を明確に見えるようにしているか**です。
|
||||
|
||||
### 自己実現と自己超越
|
||||
|
||||
ピラミッドの最上層は、どのような人間になりたいか、そして自分の一部を貢献したいかを指します。これは非常に抽象的に聞こえますが、具体的なシーンに落とすと、非常に実践的な表現があります。
|
||||
|
||||
例えばクリエイティブツール：執筆、絵画、音楽制作、ビデオ編集、プログラミングプロジェクト管理。表面上は技術的能力を提供していますが、背後にあるのはユーザーの何か自分のものを創造したいという渇望です。
|
||||
|
||||
アプリが真にこの層に触れた時、非常に強い粘性を持つことが多いです：**インターフェースが最も美しくなくても、機能が最も完全でなくても、ユーザーはここに留まります。なぜならそれは、私はどんな人間か、どんなことをしているかというより深いつながりを確立しているからです。**
|
||||
|
||||
実際のデザインでは、このように自己チェックできます：
|
||||
|
||||
- まず自分に聞く：私のアプリが最も主要に、最もコアで満たしているのはどの層のニーズか、一つだけ選ぶ
|
||||
- 次に聞く：このコア層の上で、自然に一つ上の層に拡張する機会があるか、無理に概念を貼り付けるのではないか
|
||||
- 最後に、自分のターゲット層より下の層で、明らかな欠点がないか、ユーザーの足を引っ張っていないか
|
||||
|
||||
## 3.3 ユーザータイプ別：CエンドアプリとBエンドアプリの違い
|
||||
|
||||
アプリを作った後、もう一つ重要なことに気づくでしょう：一般個人ユーザーと企業・機関ユーザーに向き合うのは、全く異なるゲームルールです。どちらもユーザーと呼ばれますが、関心事は全く異なります。
|
||||
|
||||
- **Cエンド（Consumer End）**：消費者側。一般個人ユーザーが対象。WeChat、Douyin、Meituan など。
|
||||
- **Bエンド（Business End）**：企業側。企業、機関、組織ユーザーが対象。DingTalk、財務ソフトウェア、POSシステムなど。
|
||||
|
||||
### Cエンドアプリ：一般個人の生活、感情、習慣に向け
|
||||
|
||||
Cエンドアプリは個人ユーザーに向けており、各人の日常生活に組み込まれています。
|
||||
|
||||
|
||||
|
||||
これらのアプリは種類が異なりますが、いくつかの共通の関心事があります。
|
||||
|
||||
**第一に、ユーザー成長。** つまり、より多くの人に初めてアプリを試させる方法。
|
||||
|
||||
**第二に、リテンションと再訪。** 人が来ただけではなく、留まりたいか、戻りたいか。
|
||||
|
||||
**第三に、コンバージョンと課金。** ユーザーが課金する理由は、無料版をひどくしたからではなく、あなたから一部の価値を得た後、有料機能がより高いレベルの利便性をもたらすと見たから。
|
||||
|
||||
**第四に、シェアと伝播性。** 多くのCエンドプロダクトが急速に広がるのは、使用プロセスに自然なシェア性があるからです。
|
||||
|
||||
### Bエンドアプリ：組織の効率、コスト、リスク管理に向け
|
||||
|
||||
Bエンドアプリは企業、チーム、機関、または特定の部門に向けています。
|
||||
|
||||
|
||||
|
||||
これらのアプリとCエンドの最大の違いは、複数のロールのニーズを同時に満たす必要があることです。
|
||||
|
||||
Bエンドアプリにはいくつか特にコアな関心事があります。
|
||||
|
||||
**第一に、効率の向上。** ある一人の時間が短縮されただけでなく、プロセス全体の時間が減少し、コラボレーションコストが下がり、コミュニケーションリンクが減る。
|
||||
|
||||
**第二に、コスト削減。** 人件費、研修費、システム保守費など。
|
||||
|
||||
**第三に、リスクコントロールとコンプライアンス保証。** 多くのBエンドシーンでは、コンプライアンスとトレーサビリティに高い要求があります。
|
||||
|
||||
**第四に、権限管理と責任の境界。** 誰が何を見れるか、誰が何を変更できるか、誰がどの結果に責任を持つか。
|
||||
|
||||
業界からアプリへの思考方法：**あなたがある程度理解している業界を選び**、その業界の日常的な運営の中で、どのプロセスが人工に大きく依存しているか、どの情報が複数のシステムやプライベートチャットに散在しているか、どのプロセスのエラー率が特に高いがすぐには発見されにくいかを分析します。これらの場所の周りに、非常にフォーカスされた小ツールを設計できます。
|
||||
|
||||
## 3.4 ユーザーデータに基づく磨き上げ：自分が良いと思うものからユーザーが良いと思うものへ
|
||||
|
||||
アプリを作った後に最も起こりやすい錯覚は、自分では使えば使うほどスムーズに感じ、どこもかなり合理的だと思い込んで、そのままユーザーも同じように感じるはずだと考えてしまうことです。実際には、自分で作ったプロダクトほど、他人がつまずいている点に気づきにくくなります。アプリを「自分ではよくできていると思う作品」から、本当に良いアプリへ育てていくには、実際のユーザーフィードバックを設計の中に取り込む必要があります。
|
||||
|
||||
### ユーザーが話せる出口として、シンプルなフィードバックの仕組みを設計する
|
||||
|
||||
最初から複雑なカスタマーサポートシステムやデータ分析基盤を作る必要はありません。ごくシンプルな方法から始められます。
|
||||
|
||||
**グループチャットは最も直接的な方法です。** すでに小さなユーザーグループを持っているなら、普段の利用中に出てきた問題やアイデアを、そのグループに投稿してもらうよう促せます。あなたがやるべきことは、丁寧に返信し、記録し、定期的に整理することです。グループ内で言い訳したり、防御的に反論したりすることではありません。この小さな集団の中で、率直に話せる雰囲気を作れるほど、後から集まるフィードバックの価値は高くなります。
|
||||
|
||||
アンケートは、**一度に比較的多くの構造化された情報を集めたいとき**に向いています。たとえば、あるバージョンをリリースした後、いくつかの具体的な機能についてユーザーがどう感じたかを知りたい場合です。回答率を高めたいなら、アンケートは長くしすぎず、質問もできるだけ具体的にします。たとえば「この期間で最もよく使った機能はどれですか」「どのステップで一番詰まりましたか」と聞く方が、「このアプリ全体をどう感じますか」と漠然と聞くより有効です。
|
||||
|
||||
使用後のポップアップもよく使われる方法です。たとえば、ユーザーが一つのタスクを完了した後に、非常に短い評価と自由記入欄を出し、「今回の体験はスムーズでしたか」と尋ねます。場合によっては、単純な数値評価だけでも、あるフローに明らかな問題があるかどうかを判断する助けになります。
|
||||
|
||||
1対1のインタビューはコストが高めですが、得られるリターンも大きいことがよくあります。**異なるタイプのユーザーを数人選び、20分から40分ほど時間を取ってもらい**、普段の使い方を詳しく聞いてみましょう。実際に操作してもらいながら、何を見ているのか、何を感じているのかを話してもらうと、画面を眺めているだけでは見えない問題が出てきます。以前、ある創業者がユーザーから提案をもらうために、毎日十数件のミーティングを組んで対話していた例を見たことがあります。ユーザーニーズを理解するために時間を使うことは、決して悪いことではありません。
|
||||
|
||||
### 雑然としたフィードバックから3種類の情報を抽出する
|
||||
|
||||
ユーザーフィードバックはたいてい混ざり合っていて、一目で整理するのは難しいものです。そこで、まずはそれらを **bug、体験上の問題、新しいニーズ** の3種類に分けてみましょう。
|
||||
|
||||
**bug とは、本来起きるはずだと言っていた動作が、ある状況ではまったく起きなかったり、間違った動作になったりすることです。** たとえば、アップロードに失敗する、クラッシュする、ボタンが反応しない、結果が明らかにおかしい、といった問題です。この種の問題に対しては、できるだけ早く再現し、修正し、修正後には影響を受けたユーザーへ自分から知らせるべきです。そうすることで、あなたがこれらの問題を本気で扱っていることが伝わります。
|
||||
|
||||
**体験上の問題とは、フローの長さ、操作位置、文言の表現などで、最もスムーズな経路を選べていないことです。** たとえば、ユーザーがあるボタンの前でいつも迷い、クリックすると取り返しのつかない結果になるのではないかと不安になる。重要な機能なのに目立たない隅に置かれている。デフォルト設定が多くの人の習慣と逆で、毎回余計な調整が必要になる。この種のフィードバックは、データと観察を組み合わせて判断し、変えるべきか、どの程度変えるべきかを決める必要があります。
|
||||
|
||||
**新しいニーズとは、ユーザーがあなたの想定していなかった機能や利用シーンを提案し始めることです。** 複数のエクスポート形式、チーム共同作業、ほかのよく使うツールとの連携など、本当に検討する価値があるものもあります。ただし、ユーザーが言ったことをすべてそのまま作る必要はありません。本当に見るべきなのは、その新しいニーズの背後に共通した問題があるか、それがもともとサービスしたかった人たちや中核タスクと一致しているかです。そうでなければ、分散したニーズにあちこち引っ張られ、最後には何でもやりたいが、どれも深く作れないプロダクトになってしまいます。
|
||||
|
||||
一つの習慣として、すべてのフィードバックにラベルを付けるとよいでしょう。それが bug なのか、体験上の問題なのか、新しいニーズなのかを記録します。定期的にこれらのラベルを集計し、どの種類の問題がどの機能やフローに集中しているかを見ます。そうすれば、ただ受け身で修正するだけでなく、高頻度の問題を意識的に中心へ置いて改善を進められます。
|
||||
|
||||
### 3つのシンプルな指標で継続投資すべきか判断する
|
||||
|
||||
リソースが限られている中、このアプリが継続的な長期投資に値するかを判断するためのシンプルで効果的な指標が必要です。
|
||||
|
||||
**一つ目はリテンションです。** リテンションは、ある1日に何人がアプリを開いたかを見るものではありません。**一定期間の中で、どれだけのユーザーが継続して使っているか**を見るものです。かなり粗く数えても構いません。たとえば、ダウンロード後1週間以内に少なくとも1回使った人が何人いるか、1か月以内に戻ってきた人が何人いるかを見ます。大多数のユーザーが1、2回使っただけで戻ってこないなら、初期段階で十分な価値を感じてもらえていないか、利用のハードルが高すぎる可能性があります。
|
||||
|
||||
**二つ目は再訪頻度です。** アプリをアンインストールしなかった人たちが、どのくらいの頻度で戻ってくるのかを見ます。毎日使えるツールと、四半期に一度だけ思い出されるアプリでは、プロダクトの位置づけが違います。だから同じ物差しでは測れません。それでも、あなたは合理的な利用リズムの想定を持ち、実際のデータと照らし合わせて、大きなズレがないかを見るべきです。頻度が期待より高いなら、価値が想定以上かもしれません。頻度が期待よりはるかに低いなら、シーンの捉え方がずれているのか、どこかの体験がユーザーを疲れさせているのかを考え直す必要があります。
|
||||
|
||||
**三つ目は推薦意欲です。** あなたのアプリを誰かが自分から他人に勧めたいと思うかどうかです。これはいくつかの方法で観察できます。たとえば、ユーザーが特にスムーズにタスクを完了した後に自然な共有入口を用意し、実際に何人が使うかを見る。グループ内で誰かが自発的にあなたのプロダクトを薦めているかを見る。小規模なユーザーインタビューで、「身近な人が似た問題に遭遇したら、このツールを勧めますか」と聞いてみる。推薦意欲は、単純な満足度スコアよりも問題をよく表すことが多いです。なぜなら、推薦は個人の信用を伴う行為であり、ユーザーは本当に大きく助けられたと感じたときにだけ、友人へ紹介しようとするからです。
|
||||
|
||||
この三つの指標を、前に述べたユーザーフィードバックと組み合わせて見ると、アプリが今どの状態にあるのかがだいたい判断できます。機能はまだ不完全でも、すでに一部の人が残り、特定のシーンで繰り返し使っているなら、そのアプリは投資と磨き込みを続ける価値があります。逆に、たくさんの bug を直し、新機能も積み上げたのに、リテンションと再訪がずっと上がらず、ほとんど誰も自発的に薦めないなら、一度冷静に考えるべきです。範囲を縮め、最初の中核シーンへ戻るべきなのか、場合によっては別の方向を検討すべきなのかを見直すタイミングです。
|
||||
|
||||
# 4. どの段階で、どのように合理的にAIを活用して価値を拡大するか
|
||||
|
||||
ひとたび本気でアプリを作り始めると、すぐに非常によくある誘惑に出会います。「ここにもう少し AI を入れられないだろうか」という誘惑です。この誘惑が強いのは、毎日のように「AI が某業界をエンパワーする」「AI が某プロセスを根本的に作り直す」「AI がすべてをワンクリックで片づける」といった宣伝を目にするからです。時間がたつにつれ、本来は素朴だった問題を、いかにも派手なスローガンに変えてしまい、技術スタックの中にいくつものモデル呼び出しを積み上げ、気づけばアカウント残高だけが減っていく、ということが起こりやすくなります。
|
||||
|
||||
このチュートリアルは AI ネイティブアプリの開発を扱っているので、この話題を語るのは少し自分の商売道具に水を差すようにも見えます。しかし、小さなアプリや立ち上げたばかりのプロダクトにとって、**最も危険なのは AI を使わないことではなく、AI のために AI を使うことです**。本当は、まずシンプルで信頼できるツールを作ればよいのに、新しい能力に惹かれて、賢そうに見える機能を次々に足してしまう。その結果、もともと着地できたはずの方向が、高く、複雑で、しかも価値の伸びがはっきりしないものになります。この章で解決したい核心は、どの段階で、どの部分に、どのような形で AI を使えば、本当にアプリの価値を大きくできるのかを明確にすることです。
|
||||
|
||||
## 4.1 AIのためにAIをしない
|
||||
|
||||
自分が気づかないうちにAIのためにAIをしていないかを判断するための非常に実用的な方法は、AI機能を追加する前に、まず真剣に2つの質問に答えることを強制することです。
|
||||
|
||||
**第一に：AIなしでも、このアプリは成立するか。** つまり、すべてのAI能力を一時的に取り除いても、あなたがやっていることはそれ自体価値のあることであり、ユーザーに現実のニーズがあり、毎日、毎週、毎月このことに真の時間を投じる意欲があるかどうか。
|
||||
|
||||
この言い方は少し時代に逆行しているように聞こえるかもしれません。今ではほとんどのプロダクト紹介で AI が非常に目立つ位置に置かれ、AI がなければ現代的なツールではないかのように見えるからです。しかし、もしあなたのアプリが AI を外した途端に完全に成り立たなくなるなら、多くの場合、それは技術が十分に先進的ではないという問題ではありません。もっと深い問題として、あなたが捉えているニーズ自体が痛くもかゆくもない、あるいは実際には存在していない可能性があります。
|
||||
|
||||
たとえば、ToDo を整理するツールを作るとします。主な差別化が、ToDo リストにモデルが生成したヒントを足すこと、たとえば自動タイトル付け、自動分類、自動説明補完だったとします。しかしユーザーはそもそも ToDo を書くときに、タイトルを付けることを苦痛だとは感じておらず、ただ早く用件を書き留めたいだけかもしれません。そうであれば、どれだけ賢そうな機能を足しても、継続的な価値にはなりにくいでしょう。逆に、一歩引いて、AI を使わないときにこのアプリの最も素朴な価値は何かを問い直すと、もっと堅実な方向が見えてくるかもしれません。たとえば、複数のチャネルに散らばったタスクを一か所に集めること、1日に実際に終えられる量を見える化すること、予定が破綻する前にリスクを示して、削るべきことと選ぶべきことを判断しやすくすることです。こうした基礎能力を堅く作る方が、最初から ToDo にさまざまなスマートタグを付けるより重要なことが多いのです。
|
||||
|
||||
**第二に：AIを使った後、具体的に何が向上したか。** ここでは「効率向上」「体験再構築」「スマートアップグレード」のような非常に一般的な要約は受け付けません。ユーザー自身が明確に感知できる1〜2つの次元に落とす必要があります。
|
||||
|
||||
自分に次のように問いかけてみてください。
|
||||
|
||||
- タスク完了の速度が明らかに上がったか。たとえば、もともとゼロから1ページのコピーを書く必要があったものが、5分の確認と修正で済むようになったか。
|
||||
- 結果の品質が明らかに上がったか。たとえば、同じ時間で、より整理され、より専門的で、対象読者に合った内容を出せるようになったか。
|
||||
- 利用プロセスがよりスムーズ、あるいはより楽になったか。たとえば、退屈なフォーム入力を、会話に近い質疑応答に変えられたか。
|
||||
- 実際のコストが下がったか。たとえば、外注回数、人工サポート時間、研修期間、意思決定時間を減らせたか。
|
||||
|
||||
頭の中の答えがまだ、**なんとなく**便利になりそう、少し格好よく見えそう、という程度にとどまっているなら、その AI 機能はまだ最も重要な力点を見つけられていない可能性が高いです。
|
||||
|
||||
この二つの問いには、はっきりした順序があります。まず AI がなくてもアプリとして筋が通ることを確認し、その上で、AI を加えると具体的にどこが良くなるのかを問うのです。
|
||||
|
||||
## 4.2 AIがどのような役割を果たすかを考える
|
||||
|
||||
このアプリがAIを使わなくても成立し、明確な改善点を見つけた後、次に考える必要があるのは：**あなたのアプリで、AIは一体何をしているのか。** 多くのプロダクトがここで間違えるのは、AIを非常に抽象的なエネルギーとして扱い、具体的な役割を持ったパーツとして扱わないからです。
|
||||
|
||||
より明確なアプローチは、AIをいくつかの異なるコンポーネントとして考えることです：**それは脳であり、目であり、手です。** プロダクトの目標に基づいて、どの部分を担当させるかを決める必要があります。可能であれば、最初は一つか二つの役割だけを選んでしっかりやり、全部詰め込むべきではありません。
|
||||
|
||||
|
||||
|
||||
**脳として機能する時**、AI は主にテキスト内容を理解して生成したり、複雑な情報の間で推論したりします。たとえば、会議議事録アシスタントを作るなら、長い録音から本当に重要な論点を取り出せる必要があり、単に時系列で並べるだけでは足りません。学習アプリを作るなら、ユーザーの回答を見て、概念を理解していないのか、それとも単に手順を書き間違えただけなのかを判断し、それぞれ違うフィードバックを返す必要があります。この種のシーンでの AI の価値は、ユーザーの言葉を読み取り、与えられた材料を理解し、構造と論理を持つ出力を生成できることにあります。あなたがやるべきことは、ユーザーが問題を明確に出せるようにし、十分に正確なコンテキストを渡し、この「脳」が判断するための情報をそろえることです。
|
||||
|
||||
**目として機能する時**、重点は画像や動画など、テキストではない内容を処理することにあります。これらを機械が理解できる記述へ変換し、その記述をもとにさらに行動します。たとえば、紙の書類を整理するツールなら、写真を撮って、請求書、契約書、包装説明書などを検索可能な文字に変えられます。絵の練習アプリなら、ユーザーが描いたラフを見て、構図や線の問題を指摘できます。部屋の整理提案ツールなら、ユーザーがアップロードした写真から部屋のレイアウトや物の分布を認識し、簡単に実行できる改善案を出せます。ここでの AI の要点は、分析できる目のように働き、アプリがキーボード入力の文字だけでなく、ユーザーの生活にある実物世界へ触れ始められることです。
|
||||
|
||||
**手として機能する時**、AI は単に提案やテキスト結果を返すだけでなく、一連の具体的な動作を実行し始めます。たとえば一部の自動化プラットフォームでは、複数のステップを一つのワークフローとしてつなげられます。メールから添付ファイルを読み取り、内容を要点にまとめ、グループへ送信し、原文をクラウドドライブに保存し、最後にタスク管理ツールへフォローアップ項目を自動作成する、といった流れです。ここでの AI の役割は、複雑なプロセスの中で、文脈に応じて次に何をすべきかを動的に判断することです。たとえば、あるメールがクレームかどうかを見分ける、フォームがきちんと埋まっているかを判断する、そしてそれに応じて異なる後続処理を起動する、といったことです。
|
||||
|
||||
これらに加えて、実際のアプリケーションでは、AIの役割はさらに具体的で多様になります：
|
||||
|
||||
テキスト処理では、翻訳、要約、Q&A、続きを書くこと、感情分析などを担うことがあります。たとえば、カスタマーサポートシステムで問い合わせを自動分類する、法律文書アシスタントで契約条項を抽出する、教育アプリで作文を添削する、といった使い方です。
|
||||
|
||||
- 技術的な基盤は主に深層学習における **大規模言語モデル（** **LLM** **）** です。大量のテキストから言語規則と世界知識を学び、長文や多ターン対話の文脈を「読める」だけでなく、一貫した文体で自然な内容を「書ける」ようになります。
|
||||
- 「理解」の側では、LLM はユーザー意図の識別、重要情報の抽出、感情傾向の判断に使えます。「生成」の側では、要約の自動作成、質問への回答、続きを書くこと、書き換え、多言語翻訳などに使われ、人が読む、整理する、書く必要のある大量の作業を自動化または半自動化できます。
|
||||
- **オンラインカスタマーサポートボット**の例では、システムがまずユーザーの一言から、問い合わせ、クレーム、アフターサポートのどれに近いかを大まかに判断し、発話の中から注文番号、時間、商品名などの重要情報を抽出します。その後、LLM が文脈と企業ナレッジベースを組み合わせて、自然で完全な回答を生成します。これにより、人手の負荷を減らし、ピーク時にも安定したサービス品質を保てます。
|
||||
|
||||
画像処理では、認識、分類、生成、修復、強化を担うことがあります。たとえば、医療画像で病変位置を標注する、EC プラットフォームで商品を自動切り抜きして背景を差し替える、デザインツールでテキスト記述から挿絵を生成する、といった使い方です。
|
||||
|
||||
- 画像理解は通常、**畳み込みニューラルネットワーク** **（** **CNN** **）** などの視覚深層モデルに依拠します。大量の画像からエッジ、テクスチャ、構造などの特徴を学び、物体検出、画像分割、細粒度分類、たとえば異なる病変や商品カテゴリの区別に使われます。
|
||||
- 画像生成と修復は、**拡散モデル、** **GAN** ** などの生成モデル**に依拠します。テキスト記述や参考画像から新しい画像を生成したり、ぼやけた画像、欠けた画像、低解像度画像を修復・超解像したりできます。
|
||||
- 多くのシステムでは LLM も組み合わせます。まず自然言語でユーザーの説明を理解し、その後、視覚モデルに適した「プロンプト」、スタイルタグ、構図制約を自動生成し、「何が欲しいかを聞き取る」ことから「欲しいものを描く」ことまでつなげます。
|
||||
- EC プラットフォームの**「スマート主画像生成」**を例にすると、システムはまず検出・分割モデルで商品を元画像から精密に切り抜きます。次に LLM が事業者の入力した文言、たとえば「シンプルな北欧風リビング、柔らかい自然光」を解析し、具体的なシーン、色調、スタイルパラメータへ変換します。最後に拡散モデルがそれに合う背景と光と影を生成し、構図が悪いものやスタイルが合わないものを自動で除外し、そのまま出品に使える商品主画像を出力します。
|
||||
|
||||
音声・動画処理では、音声や動画の生成、文字起こし、ノイズ除去、編集、字幕作成を担うことがあります。たとえば、ポッドキャストツールで冒頭と締めのナレーションを自動生成する、動画プラットフォームで台本から解説動画を自動合成する、会議ソフトで会話をリアルタイム文字起こし・翻訳し、多言語字幕と録画再生を生成する、といった使い方です。
|
||||
|
||||
- 「理解」の側では、システムは**音声認識モデル**で音声を文字へ変換し、同時に話者、言語、話速、おおよその感情を分析します。また、視覚モデルで動画画面内のシーン、人物、重要な物体を理解します。
|
||||
- 「生成」の側では、LLM を中核として、台本、会議内容、ユーザー指示を理解・分解・書き換えます。その後、**音声合成** **（** **TTS** **）で自然な音声解説を生成し、動画生成・編集モデル**によって画面を自動合成または編集し、背景を差し替え、ショットや字幕を挿入します。音声側の生成モデルは背景音楽や環境音も自動生成でき、深度ノイズ除去や音質強化と組み合わせて全体の聞き心地を高めます。
|
||||
- **「テキストから短動画を生成する」**タイプのプロダクトでは、ユーザーは文章を入力するだけで済みます。システムはまず LLM で文章をいくつかの自然な段落と画面に分け、ナレーションに適した原稿と簡単な絵コンテ記述を生成します。次に TTS モデルが音声を合成し、動画テンプレートや生成モデルが絵コンテに基づいて画面を選ぶ、または生成します。タイムライン上で字幕と音声を自動同期し、最後にそのまま公開できる短動画として書き出します。
|
||||
|
||||
音声インタラクションでは、認識、合成、感情検出、対話管理を担うことがあります。たとえば、スマートスピーカーでユーザー指示を理解する、音声ナビでルートを読み上げる、語学学習アプリで発音を修正する、といった使い方です。
|
||||
|
||||
- フロント側では、深層学習の**音声認識モデル**がユーザー音声をテキストに変換し、さらにイントネーション、音量、話速などの特徴を抽出して、感情や状態を判断する手がかりにします。
|
||||
- バックエンド側では、**音声合成（TTS）**が文字の返答を自然で流暢な音声出力に変えます。感情認識モデルはユーザーの現在の話し方に応じて返答の口調や速度を調整し、やり取りをより本物の会話に近づけます。
|
||||
- **スマートスピーカー**を例にすると、ユーザーが「今日は少し疲れたから、リラックスできる音楽をかけて」と言った場合、システムはまず音声認識で文字に変換します。次に LLM が過去の再生履歴を組み合わせて、ユーザーにとっての「リラックス」の好みを理解し、より穏やかなプレイリストを自動選択します。感情認識がユーザーの疲労状態を判断した後、TTS は返答を合成するときに話速を落とし、声の調子を柔らかくして、全体の交流を「聞き取れる」だけでなく「聞いて心地よい」ものにします。
|
||||
|
||||
上の内容は、AI のいくつかの主要方向における応用と技術を簡単に紹介したものにすぎません。実際のビジネスシーンでは、多くの場合、複数の最新 AI API を導入し、異なるタスクでより全面的にテストする必要があります。現在の AI の能力がどこまで強いのか、どんな問題を解けるのか、どのような状況で間違えやすいのか、その境界がどこにあるのかを、少しずつ把握していかなければなりません。これを理解して初めて、能力を誤って見積もることでリスクを埋め込むことなく、機能とフローを合理的に設計できます。
|
||||
|
||||
次に、この点をめぐって、AI の能力と境界をどう理解するか、実際にプロダクトを作るときに何を考えるべきかを、もう少し体系的に見ていきます。
|
||||
|
||||
## 4.3 AIの能力と限界に習熟する
|
||||
|
||||
実際に AI をアプリへ組み込み始めると、すぐに一つの現実に気づきます。宣伝で語られる万能感と、具体的な一機能に落としたときの制約には、かなり大きな差があることがあります。過度に約束して結果が外れるのを避けるには、**現在の AI 能力の主な方向について基本的な認識を持ち、それぞれの境界がどこにあるのかを明確にする必要があります。大量のテストを通じて Bad Case を集めて振り返り、利用時には AI が高い確率で間違える状況を避けるか、少なくともエラーに対する警告を加える必要があります。**
|
||||
|
||||
現在のモデルは多くのシーンで、依然としてもっともらしい作り話をする問題を抱えています。特に、自由に発揮させたり、十分に信頼できる参考資料を与えなかったりすると、見た目には自信に満ちているが完全に間違った答えを出すことがあります。存在しないファイル、データ、経験を作り出すことさえあります。したがって、結果が重大な影響につながるシーン、たとえば財務報告書、法律文書、医療アドバイスなどでは、設計上、必ず人間による校正や多重チェックの層を明確に加え、モデル出力をそのまま自動実行できる指示として扱ってはいけません。
|
||||
|
||||
同時に、プライバシーとデータセキュリティも正面から向き合う必要がある問題です。どのデータならそのままモデルに送れるのか、どのデータは匿名化処理が必要なのか、どのデータはそもそも第三者システムに出してはいけないのかを、非常にはっきり理解しておく必要があります。ユーザーがアップロードする契約書、病歴、個人識別情報などの敏感な内容については、画面と規約の中で処理方法を明確に説明し、可能であれば、こうしたシーンにはより安全で制御しやすいモデルデプロイ方式を個別に選ぶべきです。
|
||||
|
||||
もう少し具体的に、ここではエージェント Agent に関係する例を借りて、AI 能力の境界を本当に理解するとはどういうことかを説明します。注意してほしいのは、ここで Agent をゼロから実装する方法を教えるわけでも、今すぐ特定のアーキテクチャを追うべきだと言っているわけでもないことです。この例を通じて見てほしいのは、一つの考え方です。同じ Agent という話題でも、ある人は単なる新しい用語として扱うだけですが、別の人はこの話題を使って、タスクを明確に分解し、境界をはっきり描くことができます。
|
||||
|
||||
AI アプリの現場に長くいる著者 Barret 李靖氏が、Agent をどう作るべきか、AI を使うべきかを説明するために、私が非常に納得している整理を示していました。それは成熟した理解の仕方をよく表しています。まず問題を分解し、それから AI の使いどころを語る、という方法です。
|
||||
|
||||
> Agent には二つの変数があります。一つはタスクの進み方を制御する workflow、もう一つは内容生成を制御する context です。
|
||||
>
|
||||
> 1）workflow と context の確定性がどちらも高い場合、この種のタスクは自動化しやすく、従来の RPA に近いものになります。たとえば請求書処理やフォーム入力タスクでは、AI は主に接着剤のような役割で、発揮できる余地は比較的限られます。
|
||||
>
|
||||
> 2）workflow は確定しているが context が不確定な場合、つまりプロセスは固定されているが入力が多様な場合、Agent は意味理解の面で補完する必要があります。たとえばカスタマーサポート Q&A や契約解析では、外部検索、知識グラフなどのツールで情報の不足を補い、推論結果を期待に近づける必要があります。
|
||||
>
|
||||
> 3）workflow は不確定だが context が確定している場合、つまり入力は明確だが進み方が多様な場合、Agent は自律的に経路を計画する必要があります。市場分析レポート生成、パーソナライズ推薦などがこれに当たります。多くの End-to-End RL Agent はこの種のタスクを得意とします。訓練段階で大量の経路計画や問題解決の考え方を学習しているからです。
|
||||
>
|
||||
> 4）workflow と context がどちらも不確定な場合は、最も複雑なシーンです。推論も探索も必要になります。革新的なソリューション設計、部門横断の情報収集などは、より汎用型 Agent に近いものです。その実行効果は、与えられたツールの豊富さに左右され、特にプログラミング能力を最大限開放することが重要です。たとえば Github でリポジトリを探して clone し、コードを修正して問題を解決することを学ばせ、人間のように働かせることです。
|
||||
>
|
||||
> したがって、Agent をうまく作るには、まずシーンを明確にする必要があります。本質的に、自動化が解くのは「確定性」の問題であり、知能化が解くのは「不確定性」の問題です。
|
||||
|
||||
この分解方法の価値は、「Agent を作る」という曖昧な概念を、具体的に判断できる問いへ変えることにあります。あなたが向き合うタスクでは、どこが確定していて、どこが不確定なのか。プロセスも情報も確定しているなら、従来のプログラムで十分です。不確定性が現れたときに初めて、AI の意味理解、パターン認識、推論計画の能力が活きます。ただし同時に、不確定性が高いほど、AI が持ち込む新しいリスクも大きくなります。両方が不確定なシーンでは、AI の一歩一歩がずれる可能性があり、どの選択をするかを事前に知るのは難しくなります。多くのチームが第二象限、つまり workflow は確定しているが context が不確定なシーンから始めるのはこのためです。AI の理解能力を活かしながら、固定されたフローでリスクを制御範囲に閉じ込められるからです。
|
||||
|
||||
この小節の最初の問いに戻りましょう。本当に AI の能力境界を理解するとは、どういうことでしょうか。
|
||||
|
||||
まず、シーンごとに AI への要求が違うことを理解することです。前の workflow と context の例が示しているように、プロセスも情報も確定しているとき、AI に活躍の余地はあまりなく、従来の自動化で十分です。プロセスは確定しているが情報が不確定なとき、AI の価値は理解と補完にあります。プロセスが不確定なとき、AI には計画と探索が必要になります。この分解方法の本質は、不確定性の出どころと程度を識別することです。AI の中核能力は、不確定性の中でパターンと関連を見つけることです。この考え方は Agent だけでなく、画像認識、コンテンツ生成、推薦システムなど、あらゆる領域に同じように重要です。たとえば AI 切り抜きツールを作る場合、入力は確定しています。一枚の画像です。しかし、エッジ認識の正確さや複雑背景の処理能力こそが、不確定性のある部分です。
|
||||
|
||||
|
||||
|
||||
しかし、AIは不確実性を解決すると同時に、新しい不確実性も導入します。その出力は確率的であり、誤解、誤推論、ハルシネーションを起こす可能性があります。異なるシーンと異なるユーザーは、この不確実性に対する許容度が全く異なります。だからさらに聞く必要があります：
|
||||
|
||||
**AI が導入する新しい不確定性を、ユーザーとシステムは受け止められるか？** たとえばカスタマーサポートのシーンでは、AI がユーザー意図を誤解しても、ユーザーはすぐに訂正できます。この不確定性は制御可能です。しかし、財務承認を自動実行する場合、AI の一度の誤判断が深刻な結果をもたらす可能性があり、この不確定性は受け入れられません。画像生成でも同じです。ユーザーのアバターを美化するだけなら、結果が気に入らなければ再生成すればよく、試行錯誤のコストは低いです。しかし、建築設計者に施工図を生成する場合、たった一つの細部の誤りでも工事事故につながる可能性があります。
|
||||
|
||||
**AI の正確率は、このシーンの合格ラインに達しているか？ そしてその合格ラインは、ユーザーがそれを何に使うかで決まります。** 同じ画像認識でも、ユーザーのアルバム整理や顔写真分類を助けるだけなら、識別精度が80%でも受け入れられるかもしれません。せいぜい数枚を手動で調整すればよいからです。しかし、セキュリティ監視に使う場合、20%の不審者を見逃すことは深刻な安全リスクになります。同じテキスト生成でも、ソーシャルメディア投稿を書くなら60点のアイデアで十分かもしれません。ユーザーが自分で整えられるからです。しかし、法律契約条項を生成するなら95点でも足りません。たった一つの言葉の不適切さが法的紛争を引き起こす可能性があるからです。ユーザーや用途によって、エラー率への感度は完全に違います。自分がサービスするシーンの許容範囲がどこまであるのかを、はっきり理解しておく必要があります。
|
||||
|
||||
**AI が間違えたとき、補正する方法はあるか？** workflow が確定しているシーンでは、重要な節点に人間のレビューを置き、AI の不確定性を局所的に制御できます。しかし workflow も不確定なシーンでは、AI の一歩一歩がずれる可能性があり、いつ介入すべきかを判断するのが難しくなります。このとき、コストとリスクは急速に上がります。たとえば画像修復シーンで、AI が古い写真を十分にリアルに修復できなかったとしても、ユーザーは一目で気づき、採用しないことを選べます。しかし医学画像の補助診断シーンで、AI が異常位置を間違ってマークした場合、医師が気づきにくい可能性があり、結果ははるかに深刻です。
|
||||
|
||||
**AI のパフォーマンスを測定し、最適化する方法はあるか？** そのタスク自体に明確な正誤基準がない場合、AI がうまくできているかどうかをどう判断するのでしょうか。ユーザーのフィードバックが遅れて返ってくる場合、どう素早く反復するのでしょうか。測定すらできないとき、AI の不確定性はブラックボックスになります。たとえば推薦システムなら、クリック率や滞在時間などの指標で効果を素早く評価できます。しかし、クリエイティブな広告コピーを生成する場合、「良い」とは何か自体が主観的で、配信後のコンバージョン率を待たなければ分からないことがあり、反復周期は長くなります。
|
||||
|
||||
本当に成熟した判断は、「ここに不確定性があるから AI を使える」ではありません。「ここでの不確定性は AI が処理でき、AI がもたらす新しい不確定性も自分たちで管理できる」という判断です。「この機能点で、AI はどの程度助けになるのか、投資する価値があるのか、どのように投資すれば最も費用対効果が高いのか」。こうした判断力を形成できれば、今後機能を設計し、案を評価するたびに、多くの遠回りを避けられます。
|
||||
|
||||
# 5. アプリがあれば、0から最初のリアルユーザーをどう見つけるか
|
||||
|
||||
苦労してアプリを作った後、次の難題は、最初のリアルユーザーをどう見つけるかです。
|
||||
|
||||
多くのチームはこの段階で、ものができたのだから、あとは広めればよい、と考えがちです。宣伝する、広告を買う、露出を増やす。より多くの人に見てもらえば自然に回り始めるように見えます。しかし最初から大規模露出を追うと、典型的な罠にはまりやすくなります。貴重な時間と予算を使い、データ上は人が来たように見えても、そのアプリを本当に継続利用したい人がいるのかは検証できないままです。
|
||||
|
||||
この段階で最も重要なのは一つだけです。**できるだけ小さなコストで、本当に人がこのアプリを使いたいと思い、使い終わったあとも戻ってきたいと思っていることを証明することです。** 成長とプロダクトの文脈では、このステップは通常「コールドスタート」と呼ばれます。
|
||||
|
||||
コールドスタートとは、ほとんどすべてがゼロの状態から、新しいプロダクトを本当に動き始めるところまで持っていくことです。このときは、ユーザー基盤も、口コミも、検索流入も、ブランド認知もありません。各種指標はほぼ 0 にとどまっています。そんな冷え切った環境の中で、最初に本当に使ってくれる人たちを見つけ、その人たちを中心に最初の利用ループを組み立てる必要があります。
|
||||
|
||||
これは、その後の既にユーザーやデータのあるプロダクトを最適化する仕事とはまったく別の種類です。ざっくり言えば、次の4つのステップで進められます。
|
||||
|
||||
1. まず、成長は 0–1 と 1–N に分けられると理解し、今の自分が何を把握すべきかを知る
|
||||
2. 本当に探すべき相手が誰なのかを明確にし、終端ユーザーだけを見ない
|
||||
3. 対象をはっきりさせたうえで、自分に合った 1〜2 本のコールドスタート経路を選ぶ
|
||||
4. リソースが限られる現実の中で、取捨選択を学び、力を最も重要な小さな部分に絞る
|
||||
|
||||
## 5.1 まず2つの段階を区別する：0–1と1–N
|
||||
|
||||
正式にユーザーを探し始める前に、まず一つ明確にしておく必要があります。それは、**成長には段階がある** ということです。成長に関する仕事を全部まとめて考えると、今どこに力を入れるべきか分からなくなります。最も単純で実用的な分け方は、成長を 0–1 と 1–N に分けることです。
|
||||
|
||||
### 0–1：誰も使っていない状態で、どうコールドスタートするか
|
||||
|
||||
0–1 とは、完全にユーザーがいない状態から、本当に使いたいと思う少数のユーザーが現れるまでのプロセスです。冷スタートの「冷」は、最初の時点でほぼすべての指標がゼロであることにあります。ダウンロードも、検索量も、口コミもありません。あなたのアプリは、この世界にまだ存在していないのと同じです。
|
||||
|
||||
この段階でやるべきことは、自然流入や運を当てにすることではありません。自分から動いて、最初の土台を作ることです。具体的には、次のことが必要です。
|
||||
|
||||
**本当に使ってくれる少数のシードユーザーを見つけること。** ただ知り合いから数を集めるのではなく、あなたが解きたい問題に本当のニーズを持っている人を探します。人情や好奇心で一度だけ開いて去る人ではなく、その問題に現実に困っている人です。
|
||||
|
||||
**最初の利用体験と供給を用意すること。** ユーザーが来たとき、真っ白な画面しか見えないのではだめです。機能がまだ不完全でも、少なくとも一度はコア操作を完了でき、価値を感じられるようにします。
|
||||
|
||||
**このプロダクトが何をするのか、何を解決するのかを簡単な言葉で説明できるようにすること。** ブランドの後ろ盾がない初期段階では、ユーザーがあなたに与える注意は数秒しかありません。「これは自分に何の役に立つのか」を最短で伝える必要があります。
|
||||
|
||||
**最初の接触経路を確保すること。** 小さなコミュニティでも、フォーラムでも、友人関係でも構いません。大事なのは規模ではなく、本当に必要としている人へ正確に届くかどうかです。
|
||||
|
||||
0–1 段階で本当にやるべきことは、最初のリアルニーズを持つ人を引き込み、流入から利用、そしてフィードバックまでの完全なループを回すことです。そのループが回れば、このアプリが空中楼閣ではなく、本当に必要とされ、使われるものだと証明できます。
|
||||
|
||||
### 1–N：すでに使いたい人がいる基盤で、どうスケールするか
|
||||
|
||||
繰り返し使いたいユーザーが少しずつ増えてきたら、ようやく問題は、数十人、数百人から、数千人、数万人、さらにその先へどう拡大するかに移ります。これが、一般に言う成長、拡張、スケールの段階です。
|
||||
|
||||
1–N の段階では、メカニズム、組織、収益化、ブランド、チームといった、より複雑な論点を考え始めます。たとえば:
|
||||
|
||||
**比較的安定した獲得チャネルを見つけているか。** どれだけの予算や時間を入れれば、どのくらい新規ユーザーが増えるのか。ここでは運ではなく、再現可能で予測可能な成長経路が必要です。
|
||||
|
||||
**サービスの仕組みを整え始めているか。** たとえばサポート、運営施策、ユーザー教育です。ユーザーが増えると、初期のように一人ひとりへ手取り足取り教えることはできません。標準化されたサービス体制が必要になります。
|
||||
|
||||
**このプロダクトでどうやって収益を得るか。** サブスク、単発課金、追加価値サービス、その他の方法か。ビジネスモデルは最初から完全に固める必要はありませんが、1–N に入ったら持続可能な形を真剣に考えるべきです。
|
||||
|
||||
**ユーザーにどんなブランド印象を残したいか。** 早期は小さな輪の中で広がるだけでも、規模が大きくなると「覚えてもらうこと」「信頼してもらうこと」「自発的に薦めてもらうこと」を考えなければなりません。
|
||||
|
||||
**チームにどんな能力がまだ足りないか。どの工程は長期的に見張る必要があるか。** 0–1 は一人や小さなチームでも支えられますが、1–N には複数の役割が必要になりがちです。
|
||||
|
||||
これらはどれも重要です。しかし 0–1 の段階でそれらを先に考え始めると、空転するだけになりやすいです。まだ本当に使われるのか、残ってくれるのかが分かっていない段階で、収益モデルやブランド戦略を語っても、肝心なところから目を逸らしてしまうだけです。
|
||||
|
||||
### なぜまず0–1に集中すべきか
|
||||
|
||||
個人開発者や小チームにとって、1–N よりも**本当に最も重視すべきなのは 0–1**です。理由は単純です。最初のリアルユーザーすら見つけられないなら、その後のスケール、商業化、ブランド構築について語るのはすべて机上の空論だからです。
|
||||
|
||||
0–1 段階は、プロダクトのライフサイクルの中で最も脆く、同時に最も重要な瞬間です。この段階は、そのプロダクトの価値を証明できるか、最初の信頼を作れるか、そして次の成長の土台を築けるかを決めます。0–1 を本当に回せて初めて、1–N の議論に進む資格ができます。
|
||||
|
||||
次に、0–1 段階にさらに焦点を絞り、「いったい誰を探すべきか」という問いを明確にしてから、具体的なコールドスタートの経路を話します。
|
||||
|
||||
## 5.2 コールドスタートの対象：シードユーザー、供給側、トラフィック側、チャネル側
|
||||
|
||||
さまざまな種類のアプリは、たいてい次の四つの対象を避けて通れません。シードユーザー、供給側、トラフィック側、チャネル側です。
|
||||
|
||||
### 第一類：シードユーザー
|
||||
|
||||
**シードユーザーは、あなたが最初に接触するユーザーです。** 彼らの典型的な特徴は人数が少ないことですが、ターゲットのペルソナと非常に高く一致していることです。彼らから得たいのは、登録数や利用データだけではありません。方向性そのものと体験のフィードバックです。
|
||||
|
||||
たとえば、個人向けツールなら、シードユーザーは、ある問題で長く困ってきた人たちかもしれません。長文を書くことが多いコンテンツクリエイター、報告資料を頻繁に作る職場の人、毎日大量の資料と向き合う学生などです。教育系アプリなら、同じ試験を準備している少人数の受験者や、特定学年の保護者がシードユーザーになりえます。
|
||||
|
||||
コールドスタート時には、まず 20〜50 人ほどの協力してくれるユーザーを見つけ、1〜2 週間かけて使いながら対話する、といった明確な目標を立てられます。重要なのは人数ではなく、高密度なやり取りを通してプロダクトのロジックを磨き込むことです。
|
||||
|
||||
### 第二類：供給側
|
||||
|
||||
**一部の二面市場や多面市場のプラットフォーム型プロダクトでは、ユーザー側だけでは不十分です。** 十分な供給側がなければ、ユーザーを連れてきても、使えるものがなくてすぐに離れてしまいます。
|
||||
|
||||
供給側は、コンテンツクリエイター、講師、サービス提供者、店舗、ドライバー、大家などであることがあります。彼らが、プラットフォームの豊かさと魅力を決めます。
|
||||
|
||||
たとえば、デザイナー向けの素材プラットフォームを作るなら、まず一部のデザイナーに作品をアップロードしてもらう必要があります。たとえ小規模でも、無料素材の一部を開放してもらえないと、ユーザーが来てもサンプル画像しか見えず、定着しにくいでしょう。オンライン予約ツールなら、あらかじめ使ってくれそうな店舗や機関と連携していないと、普通のユーザーが来ても実際に予約できる相手がいません。
|
||||
|
||||
冷スタートのときは、まずユーザー側を先に解くのか、供給側を先に解くのか、あるいは両方を同時に進めるのかを、はっきり理解しておく必要があります。多くのプラットフォームは、初期にこの取捨選択を経験しています。これを構造的な問題として正面から認識しているだけでも、終端ユーザーばかり集めようとする人たちより一歩先に進んでいます。
|
||||
|
||||
### 第三類：トラフィック側
|
||||
|
||||
トラフィック側とは、**短時間である程度のユーザーの注意をあなたへ向けられる人や組織**です。インフルエンサー、縦型メディア、コミュニティ運営者、あるいは多くのユーザーを持つツールプラットフォームがこれに当たります。
|
||||
|
||||
たとえば、職場向けツールなら、何人かのキャリア系ブロガーに自然な形でアプリを紹介してもらえれば、仕事効率ツールに敏感な人たちを短期間で集められる可能性があります。小紅書のクリエイター向け選題アシスタントなら、数人の中堅ブロガーと協力して、実際のケースで使い方を見せてもらうと、そのクリエイターたち自体が潜在的なシードユーザーになります。
|
||||
|
||||
冷スタートの段階で、いきなり最大級のトラフィック側を探す必要はありません。むしろ、規模は中程度でもターゲット層と強く重なる小さなトラフィック側のほうが、カスタマイズされた試みに一緒に取り組みやすいことが多いです。大事なのは、そのような人や組織を見つけ、あなたが何をするのか、相手にどんな利点があるのかを分かりやすく伝える提案を持ち込むことです。
|
||||
|
||||
### 第四類：チャネル側
|
||||
|
||||
チャネル側とは、**特定のシーンでターゲットユーザーに安定して届く組織や入口**を指します。トラフィック側との違いは、トラフィック側が一時的な注意の導入に寄りがちなのに対し、チャネル側はより長期的で構造化された接続方法であることです。
|
||||
|
||||
学校、研修機関、企業、業界団体、ソフトウェアサービス事業者は、典型的なチャネル側です。あなたのアプリが、ある種の機関の効率向上、コスト削減、サービス品質向上に本当に役立つなら、相手にはそのアプリを自分たちの体制内の多くのユーザーに紹介する動機があります。
|
||||
|
||||
冷スタート時に、大きなチャネルを一気に取りにいくのは現実的ではありません。まずは小さな範囲の試験導入から始めることができます。たとえば、1〜2 クラス、小さな会社、地域コミュニティと協力し、しばらく内部で使ってもらい、そのフィードバックを見てから規模を広げるかどうか決める、という進め方です。
|
||||
|
||||
このように対象を分けて考える利点は、すべての力を終端ユーザーの新規獲得だけに投入し、プロダクト構造のほかの重要な部分を見落とすのを防げることです。自分のプロダクト形態に応じて、簡単な役割図を描き、それぞれの対象が誰なのか、今どれだけいるのか、短期の目標が何なのかを書き出してください。この対象図が整理できたら、具体的なコールドスタート経路を話し始められます。
|
||||
|
||||
## 5.3 コールドスタート方法：異なる対象に対する3つの主要ルート
|
||||
|
||||
### ルート1：シードユーザーで突破口を開く、私域を優先活用
|
||||
|
||||
このルートは、主にシードユーザーと一部の供給側に向けたものです。
|
||||
|
||||
多くの個人開発者、小さなチーム、さらにはスタートアップにとって、最も現実的で、コストが低く、しかもリズムをつかみやすい方法は、通常、自分がすでに持っている私域から始めることです。
|
||||
|
||||
このルートでは、おおよそ三つの重要な行動があります。
|
||||
|
||||
1. **少数の的確なユーザーを積極的に体験へ招くこと** - 重要なのは数ではなく、ターゲットペルソナとの一致度です。
|
||||
2. **意識的にフィードバックを集め、すばやく改善すること**
|
||||
3. **シードユーザーに最初のコンテンツや事例を生み出してもらうこと**
|
||||
|
||||
### ルート2：コンテンツまたは特典で駆動する、明確な第一の理由を提示
|
||||
|
||||
このルートは、主にシードユーザーとトラフィック側に向けたもので、競争の激しい領域では特に一般的です。
|
||||
|
||||
ユーザーに多くの代替選択肢があるとき、「新しく出たから試してみて」という一言だけでは動いてもらえません。もっと明確で、もっと魅力的な理由を用意する必要があります。
|
||||
|
||||
よくあるアプローチは二つあります。
|
||||
|
||||
1. **実利のある特典で引き込むこと** - たとえば新しいコースプラットフォームなら、初期に高品質な無料コースをいくつか公開したり、期間限定の割引枠を出したりします。
|
||||
2. **縦深のあるコンテンツで継続的に惹きつけること** - TikTok、小紅書、公式アカウント、ポッドキャストなどで、ターゲットユーザーが関心を持つ垂直テーマを継続的に扱い、価値ある内容を出し続けます。
|
||||
|
||||
### ルート3：ビッグプラットフォームを活用し、既存のエコシステムで突破口を見つける
|
||||
|
||||
このルートは、主に供給側、トラフィック側、チャネル側に向けたものです。
|
||||
|
||||
多くの分野で、新しいアプリがゼロから独自のエコシステムを作るのは、非常にコストが高いです。しかし、自分を大きなプラットフォーム上の新しい店舗、新しいアカウント、新しいプラグインとして捉えれば、コールドスタートの難易度は大きく下がります。
|
||||
|
||||
## 5.4 リソースが限られた時の取捨選択：0–1段階で最も重要な小部分だけをする
|
||||
|
||||
0–1 段階にいることを確認し、サービス対象を明確にし、コールドスタート経路も大まかに選んだのに、リソースがまったく足りないことに気づく。
|
||||
|
||||
この段階では、意識的に縮小する必要があります。目標は「たくさんやること」ではなく、「最も重要な小さな部分をしっかりやること」です。ここでは、三つの角度から自分の行動の組み立て直しができます。
|
||||
|
||||
### 目標から具体的なタスクへ
|
||||
|
||||
コールドスタートのとき、多くの人が設定しがちな目標は、「市場の反応を見てみる」「まずユーザーを増やす」「まず試用してもらう」といった曖昧なものです。こうした表現は広すぎて、毎日やっていることが本当に目標に近づいているのか判断しづらいです。
|
||||
|
||||
より実務的な方法は、目標を一つの具体的な小さなことへ絞ることです。たとえば、今後 4 週間で、ターゲットペルソナに合う 20 人のリアルユーザーに、彼ら自身のリアルな場面で、何度も完全にアプリを使ってもらい、そこから具体的なフィードバックを十分に集める、といった形です。
|
||||
|
||||
**「細分化された人々」とは、単に「この種のツールを使いそうな人」ではなく、具体的なラベルを指さして説明できる一群のことです。** たとえば、レポート生成ツールなら、ターゲットは漠然とした「職場の人」ではなく、「インターネット業界の運営職で 1〜3 年目の人」に絞るべきです。この層には共通点があります。毎月本当にレポートを書く必要があり、時間が限られていて、それでも内容をある程度専門的に見せたいのです。問題は具体的で、しかも継続的です。
|
||||
|
||||
**「完全な使用タスク」も曖昧にしてはいけません。** このレポートツールを例にすると、一回の完全なタスクは、ユーザーが最近一週間の運営データと素材を整理してツールに取り込み、初稿を生成し、その後おすすめの構成と要点に従って 2〜3 回修正し、最後に PPT または文書として出力し、実際に部門会議で使うところまで含みます。ユーザーが少し触って終わりで、なんとなく眺めただけなら、それは完全な使用とは言えません。
|
||||
|
||||
フィードバックは、十分に細かく聞く必要があります。たとえば:
|
||||
|
||||
- データを取り込むとき、どこか分かりにくい、入口が見つからない、あるいは毎回違う場所を押してしまうところはあるか
|
||||
- 生成された構成は、その会社のレポートの習慣に合っているか。たとえば「背景–目標–プロセス–結果」の形になっているか
|
||||
- 本当に使う画面はどれで、毎回削除される画面はどれか
|
||||
- 使ったあと、レポート準備時間が 3 時間から 1 時間に縮まったと明確に感じるか、それとも「少し便利になった気はするが、はっきりは言えない」程度なのか
|
||||
|
||||
### 何でも試そうとしない
|
||||
|
||||
小目標を決めたら、次の問題は、その 20 人のユーザーをどう見つけ、どうやって実際のシーンを一緒に回すかです。
|
||||
|
||||
冷スタートの方法はたくさんあります。コンテンツを書く、コミュニティを作る、広告を打つ、インフルエンサーに頼む、機関と組む、プラットフォームに載せる。ですが、リソースが限られているなら必要なのは、方法の数ではなく、**今の自分にとって最も自然で、続けやすいものはどれか**です。
|
||||
|
||||
もし普段から長文を書くのが得意で、最後まで読んでくれる人たちがいるなら、まずはコンテンツから始めるのがよいでしょう。たとえば、このツールを使って実際の月次レポートを準備する過程を、非常に具体的な実践記録として書きます。元データの受け取りから、構成の検討、初稿の生成、細部の修正、実際の会議室での使用までを順に示します。途中で比較スクリーンショットを挟み、使う前と後で時間、見た目、構成がどう変わったかを見せます。最後は、冷たいダウンロードリンクだけを置くのではなく、「運営レポートを作る人なら、私と一緒にこのツールを磨きたいなら連絡してください。20 人を選んで一対一でフォローします」と明確に書きます。
|
||||
|
||||
もし、安定したコミュニティをいくつか持っているなら、たとえば運営者のグループや同窓会の仕事グループがあるなら、私域から始める方が向いています。そこで、率直にこう話せます。「レポート生成ツールを作っています。まだ使える段階ですが、かなり粗いです。本当にレポートが必要な人を集めて、一緒に使い方を磨きたいです」。自分から手を挙げてくれた人の中から、職種や仕事内容を見て最も合う人を選び、小さなグループを作って試用してもらい、スクリーンショットや不満、改善案を送ってもらい、自分は毎日そのフォローをします。
|
||||
|
||||
もし、特定の業界で人脈があるなら、たとえば研修機関の講師を何人か知っている、あるいは中小企業の事業責任者を知っているなら、試験導入を 1 つのクラスや小さなチームに落とし込めます。具体的には、明確な試用プランを提案します。たとえば、次の 1 か月はそのチームの週報をすべてあなたのツールで作成してもらい、あなたはリアルタイムでサポートと調整を行う。その代わり、相手には毎週 10 分だけ小さな会議に付き合ってもらい、どこが一番使いやすいか、どこが一番しんどいかを教えてもらいます。
|
||||
|
||||
### 最も重要な部分だけを磨く
|
||||
|
||||
小目標を持ち、主経路も決めたら、次にやるべきことは、自分に「この小さな部分だけをやる」という制限をかけることです。
|
||||
|
||||
冷スタート段階のチームに共通する特徴は、不安です。不安になると、すぐ外に新しい動きを探したくなります。短動画アカウントを作るべきか、使い方動画をいくつか撮るべきか、少し予算を入れて広告を試すべきか、何人かのメディアに連絡して記事を書いてもらうべきか。**どれも単体では悪くありませんが、合わさると、毎日あちこち向かっていて、どの経路も深くならないという結果になります。**
|
||||
|
||||
**たとえば、今後 4 週間は二つのことだけに集中すると自分に決めます。** 一つは、20 人のユーザーを対象に、彼らの実際の場面での体験を何度も改善し、「なんとか使える」から「かなり自然に使える」状態へ持っていくこと。もう一つは、選んだ主経路に沿って少数の新規ユーザーを継続的に見つけ、その行動とフィードバックを記録し、前のグループとの共通点と違いを見ることです。
|
||||
|
||||
この 4 週間のあいだに、新しいアイデアや新しい機会が出てきても、まず自分にこう問い直します。「それは、この期間内に 20 人のユーザーの体験を明らかに良くするか、あるいは次の似たユーザーを見つけるのに本当に役立つか。」
|
||||
|
||||
このやり方の背景には、コールドスタートの本質を認める姿勢があります。手元にある情報は非常に限られており、同時に多くの方向で良い判断は下せません。10 か所で少しずつやるよりも、一つの具体的なシーン、一つの具体的なグループで、繰り返し検証できる改善をした方がよいのです。たとえば、ある運営新人の集団に対して、このツールがレポート準備時間を本当に短縮し、本当に重点を伝えやすくしていると、明確に見えることがあります。
|
||||
|
||||
あなたが通るべきなのは、**ユーザーを見つける → 使ってもらうよう導く → フィードバックを集める → 体験を改善する → 継続利用してもらう** という閉ループです。このループが滑らかに回るようになって初めて、次に別のチャネルを増やしたり、新しい連携を試したりする意味が出てきます。
|
||||
|
||||
# まとめ
|
||||
|
||||
最初の問題に戻ります：アプリを作ること、一体どこから始めるのが信頼できるスタートか。
|
||||
|
||||
この記事の全内容は、実は一つのメインラインを中心に展開しています：**まずアイデアが何かを明確にし、それとユーザーニーズの関係を見て、それを一歩一歩作れて、使えて、磨き上げられて、AIで拡大でき、ユーザーを見つけられる完全な使用パスに分解すること。**
|
||||
|
||||
まず第一章では、アイデアそのものから出発しました。アイデアはもう頭の中の「なんかかっこいい」ではなく、明確なユーザー層に向け、**具体的なシーンに根ざし、具体的なタスクを完了させ、現状より良い方法を提供する**必要があります。
|
||||
|
||||
次に第二章では、**行動を開始する**ことを学びました。**発散と収束の間を行き来**し、ダブルダイヤモンド方式でまずアイデアを広げ、その後ユーザー価値、実現可能性、時間コストに基づいて**真に実行可能なルートに収束**させること。**抽象から具体へ**の練習、ホワイトボードや紙で先に描いてから作ること、**他人のナビゲーション、フォーム、結果表示、ガイドフローを分析し、既存の経験を借りる**こと。そして、プロダクトが完全に完成してからユーザーに聞くのではなく、プロトタイプや半完成品の段階から、**描きながら聞き、作りながら聞き**、リアルユーザーに可能な限り早くデザインに関与させること。
|
||||
|
||||
第三章では、何が「使える」で、何が「使いやすい」かを区別する自分なりの判断基準を徐々に構築しました。
|
||||
|
||||
第四章では、視点を純粋なプロダクトからAI能力へと拡張しました。**AIのためにAIをする衝動を抑え**、真剣に2つのことを問う：AIなしでもこのアプリは成立するか、AIを使った後具体的に何が向上したか。
|
||||
|
||||
最後の第五章では、これらすべてを一つの現実的な問題に引き戻しました：たとえすでに悪くなく、AIも使えるアプリがあっても、ユーザーがいなければ価値はゼロです。
|
||||
|
||||
これらの内容を合わせると、一連の方法は神秘的なものではありません：**信頼できるアイデアから出発し、それがリアルなニーズに根ざしていることを確認する。描く、書く、分解する方法で、最小実行可能アプリに収束する。リアルユーザーと明確な指標を使って、少しずつ良いアプリに磨き上げる。重要ポイントで合理的にAIを導入して価値を拡大する。最後に、限られたリソースの下で、適切なコールドスタート方法で最初の対価を支払う意思のある人を見つける。**
|
||||
|
||||
次のステップは、過度な幻想を捨て、その中から一つを選んで作り出し、推し出し、実際の世界で検証を受けることだけです。**アイデア、方法論、AI、成長に関するすべての議論は、最終的に具体的な一人の人、一つの具体的なシーン、一つの具体的なタスクに落ちなければなりません。**
|
||||
|
||||
だから、最初は粗くても問題ありません。機能が欠けていても、プロセスが硬くても、インターフェースが簡素でも構いません。公開しても誰も反応してくれなくても、登録や課金する人がいなくても、それでも問題ありません。これらはすべてプロセスの状態であり、最終的な結論ではありません。次にどう修正すればいいかを教えてくれているだけで、真に重要なのは進歩することです。
|
||||
|
||||
この段階で、筆者はプロセスを楽しむだけでいいと思っています。有名なインタラクティブストーリーゲーム『To the Moon』が言ったように：
|
||||
|
||||
**_"The ending isn't any more important than any of the moments leading to it."_**
|
||||
|
||||
**_結末は、そこに至るまでのどの瞬間よりも重要ではない。_**
|
||||
|
||||
|
||||
+355
@@ -0,0 +1,355 @@
|
||||
# 7つのAIプログラミングツールの比較
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
数多くあるAIプログラミングツールの中で、どれが自分に一番合っているのでしょうか？本章では、統一された実践タスク——「スネークゲーム + AIで詩を作る」ゲームの開発——を通じて、Lovable、Replit、Z.aiなど7つの主要なWeb Vibe Codingプラットフォームを深く横断的に評価します。初心者へのやさしさ、コードの制御性、デプロイの便利さなど、複数の観点から比較し、あなたに最適な開発支援ツールの選び方をご案内します。
|
||||
|
||||
---
|
||||
|
||||
# 1. Vibe Codingでスネークゲームを作る：完全実践チュートリアル
|
||||
|
||||
本記事では、「Vibe Coding（雰囲気コーディング）」と呼ばれる新興のソフトウェア開発手法についてご紹介します。これは人工知能を活用してアプリケーション構築プロセスを加速させる手法です。
|
||||
|
||||
続いて、Vibe Codingの核心的な概念、AI Agentとは何かを説明し、実用的なプロンプトの書き方をご紹介します。最後に、ゼロから「スネーク（Snake）」ゲームを構築する完全な実践を通じて、複数の主要なVibe Codingプラットフォームを詳しく比較評価し、自分に最も適したツールの組み合わせを選べるようにします。
|
||||
|
||||
## ここで学べる内容：
|
||||
|
||||
- **Vibe Codingとは何か：** 定義、ワークフロー、そして主な利点について理解します。
|
||||
- **AI Agentの役割：** AI Agentの動作方式、および従来のプログラムとの違いを理解します。
|
||||
- **プロンプトの上手な書き方：** 明確で具体的なプロンプトの書き方を身につけ、より良い結果を得られるようになります。
|
||||
- **Vibe Codingツール：** 主要なAIプログラミング・デザインプラットフォームを知ります。
|
||||
- **プラットフォームの比較：** 初心者の視点から、7つの異なるAI Agentプラットフォームの長所と短所を評価・比較します。
|
||||
- **UI / UXツール：** Figma、MastergoなどのUI/UXツールを全体のワークフローに組み込む方法を学びます。
|
||||
|
||||
## 1. はじめに
|
||||
|
||||
これまでのレッスンでは、z.aiのフルスタック開発モデルを使ってプログラミングタスクを進めてきました。
|
||||
|
||||
しかし、その核心が「AI Agent」であることはご存知でしょうか？（一般的なチャット式AIとは異なり、ずっとスマートです。）なぜなら、単に会話するだけでなく、思考（タスクを与えると、まず計画を立てます）し、自発的に行動（例えば、Web検索、PCコマンドの実行、Webページを開くなどのツールを呼び出す）できるからです。詳しくは後ほど説明します。
|
||||
|
||||
## 1. Vibe Codingとは何か？
|
||||
|
||||
Vibe Codingとは、AIを活用してアプリケーション開発プロセスを加速させる新しいソフトウェア開発手法です。従来のプログラミングの代替ではなく、より「対話型」のプログラミングモードと言えます。この概念はAI研究者のAndrej Karpathy氏によって提唱されました。このワークフローでは、開発者はコードを一行ずつ手書きするのではなく、主にAI Agentを誘導してアプリケーションの生成、最適化、デバッグを行います。
|
||||
|
||||
Vibe Codingの核心的な考え方は、**「コード中心（code-first）」**から**「意図中心（intent-first）」**への転換です。もう最初の一行からコードを考える必要はなく、自然言語で期待する結果を記述するだけで済みます。
|
||||
|
||||
典型的なVibe Codingのワークフローは、継続的なイテレーションのサイクルです：
|
||||
|
||||
- **目標を記述する：** まず一文または一段落で実現したい機能を記述します。例：「Pythonバックエンド付きで、詩を生成できるシンプルなスネークゲームを作って。」
|
||||
- **AIがコードを生成：** AI Agentがあなたのニーズを解析し、基本構造、フロントエンドページ、バックエンドロジックを含む初版コードを生成します。
|
||||
- **実行して確認：** 生成されたコードを実行し、期待通りに動作するか確認します。同時にバグや不十分な点を見つけます。
|
||||
- **フィードバックして反復：** エラーや期待通りの結果でない場合は、チャットで引き続き指示を出します。例：「蛇の移動が遅すぎるので、速度を上げてください」や「`.env`ファイルのAPI Keyが正しく読み込まれていません。バックエンドコードを修正してください。」
|
||||
- **上記の手順を繰り返す：** 「記述 → 生成 → 実行 → フィードバック」のサイクルで継続的にイテレーションし、アプリケーションが満足できる状態になるまで続けます。
|
||||
|
||||
### Vibe Codingの主な利点：
|
||||
|
||||
- **敷居を下げる：** プログラミング経験のないデザイナー、起業家、学生なども、自然言語でアプリケーション開発に参加できるようになります。
|
||||
- **迅速なプロトタイピング：** アイデアから最小viable製品（MVP）までの時間が大幅に短縮されます。
|
||||
- **効率の向上：** テンプレートコードなど、大量の反復的・機械的なコーディング作業を自動処理し、開発者がアーキテクチャ設計や問題の抽象化に注力できるようにします。
|
||||
- **実験に有利：** まず迅速に成果物を作り、その後継続的に改良していくアプローチを奨励し、新しいアイデアや機能の試行がしやすくなります。
|
||||
|
||||
## 2. Vibe Codingオンラインプラットフォーム（Web-based）とは何か？
|
||||
|
||||
今回の実測では、評価するツールが**Web-based（オンラインプラットフォーム）**と**IDE（ローカル開発環境）**の2つのカテゴリーに分かれていることがわかります。
|
||||
|
||||
どちらも基本的にはAIにコードを書かせる仕組みですが、使用感と適用シーンには大きな違いがあります：
|
||||
|
||||
### Vibe Codingオンラインプラットフォーム (Web-based)
|
||||
|
||||
**代表的なツール：** Lovable, Replit, Z.ai, v0
|
||||
|
||||
「荷物を持ってすぐ入居できる」サービス付きマンションのようなものです。
|
||||
|
||||
- **環境設定不要：** Python環境やNode.jsのバージョン、依存パッケージのインストールなどを気にする必要はありません。ブラウザを開いてURLを入力するだけで、すぐにコーディングを始められます。
|
||||
- **ワンクリックプレビューとデプロイ：** コードが生成されると、プラットフォームは通常、右側のウィンドウに自動的に実行結果を表示します。完成したら、ボタン一つでリンクを生成して友人に共有できます。
|
||||
- **適したシーン：**
|
||||
- **アイデアの迅速な検証（MVP）：** 頭の中にアイデアがあり、30分程度で試してみたい場合。
|
||||
- **初心者の入門：** 複雑な環境エラーで挫折したくなく、AIプログラミングの楽しさを体験したい場合。
|
||||
- **軽量アプリケーション：** シンプルなツールWebページ、ミニゲーム、個人ポートフォリオページなど。
|
||||
|
||||
### AI IDE (ローカル開発環境)
|
||||
|
||||
**代表的なツール：** Cursor, Trae, VS Code + AIプラグイン
|
||||
|
||||
「内装付き」の持ち家のようなものです。
|
||||
|
||||
- **強力なローカル能力：** お使いのコンピュータ上で動作し、すべてのローカルファイルに直接アクセスでき、コンピュータの計算リソースを活用できます。
|
||||
- **プロのワークフローとシームレスに連携：** 大規模プロジェクトに適しており、各種プラグインを自由にインストールし、ローカルデータベースに接続し、複雑なデバッグが可能です。
|
||||
- **適したシーン：**
|
||||
- **プロジェクト開発：** 長期メンテナンスが必要で、構造が複雑な商業プロジェクト。
|
||||
- **深いカスタマイズ：** コードの細部を極限まで制御したい場合や、既存のローカルワークフロー（Git、Dockerなど）と深く統合する必要がある場合。
|
||||
- **データプライバシー：** コードが完全にローカルにあり、企業のセキュリティ規範により適合します。
|
||||
|
||||
**まとめると：** AIプログラミングに触れ始めたばかりの方や、手軽に小さなものを作ってみたい場合は、**オンラインプラットフォーム**が素晴らしい出発点です。プロの開発者の方や、プロジェクトが徐々に複雑になってきた場合は、**ローカルIDE**の方がより高い上限を提供してくれます。
|
||||
|
||||
---
|
||||
|
||||
## 3. AI Agentとは何か？
|
||||
|
||||
### AI Agentとは何か？
|
||||
|
||||
AI Agentとは、環境を認識し、意思決定を行い、特定の目標を達成するために自発的に行動できるソフトウェアシステムです。固定された指示に従い、単一のフローしか持たない従来のソフトウェアと比較して、AI Agentはより柔軟で適応性に優れています。
|
||||
|
||||
AI Agentを従来のプログラムと区別する主な特徴は以下の通りです：
|
||||
|
||||
- **自律性（Autonomy）：** AI Agentは高い独立性を持っています。従来のプログラムは通常、人間が一歩一歩トリガーする必要がありますが、Agentは目標に基づいて次に何をすべきかを自ら判断できます。
|
||||
- **知覚と記憶（Perception & Memory）：** Agentは環境からデータを収集し（例：APIレスポンス、センサーデータ、ユーザー入力など）、「記憶」を通じてコンテキストを保持し、その後の行動で経験を再利用し、効果を継続的に改善します。
|
||||
- **合理性と目標志向（Rationality & Goal-Orientation）：** Agentは与えられた目標に基づいて分析と計画を行い、より高い「パフォーマンス指標」を追求するために最適な行動シーケンスを選択します。
|
||||
- **ツールの使用（Tool Use）：** 近年のAI Agentの大きな特徴は、外部ツールを呼び出すことができ、「テキストの生成」にとどまらないことです。例えば、Webページの閲覧、コードの実行、データベースのクエリ、メールの送信などが可能で、「ツールを調整する」頭脳と言えます。
|
||||
|
||||
このように例えて理解できます：
|
||||
|
||||
- **従来のプログラム**は計算機のようなものです。数字と演算子を入力すると、ボタンを押した時にだけ計算を実行します。
|
||||
- **AIアシスタント**は人間のアシスタントのようなものです。「近くのレストランを探して」と頼むと、検索結果を表示し選択肢を提示しますが、最終的な決定はあなたが行います。
|
||||
- **AI Agent**は自動化された研究チームのようなものです。あなたは上位の目標（例：「日本旅行の計画を立てて」）を与えるだけで、Agentがタスクを分解し、インターネットで情報を調べ、航空券やホテルを予約し（API経由）、スケジュールを整理し、最終的に結果を届けてくれます。プロセスの細部にほとんど介入する必要はありません。
|
||||
|
||||
---
|
||||
|
||||
# 2. プロンプトの書き方について
|
||||
|
||||
## 1. プロンプトは一度に書き上げる方が良いか、それとも複数ステップに分ける方が良いか？
|
||||
|
||||
多くの人は、「完全なフルスタックアプリケーションを作る」ことを一つのプロンプトで一度にまとめたくなるでしょう。事実、現在のツールは十分に強力であり、一見それなりの結果を一度に出すことも可能です。しかし、全体的な体験と成功率から見ると、作業を小さなステップに分け、段階的にイテレーションする方が、結果的に良い成果が得られやすく、「どうしても変えられない」という行き詰まりに陥りにくくなります。
|
||||
|
||||
> **ヒント：** 「一発で完璧」を期待するより、大きな目標を一つずつ実行可能な小さなTo-doに分割しましょう。
|
||||
> 例えば、「build me a Snake game」と直接言うのではなく、以下のように分けます：
|
||||
> 「1. まずスネークゲームのフロントエンドを作る」、
|
||||
> 「2. 次にスコアを記録するバックエンドを実装する」、
|
||||
> 「3. 最後にフロントエンドとバックエンドを繋ぐ」。
|
||||
> こうすることで、AIがあなたのニーズをより正確に理解し、より信頼性の高い出力を提供してくれます。
|
||||
|
||||
## 2. 明確であればあるほど良い
|
||||
|
||||
- Vibe Codingでは、あなたが書くプロンプトはコードと同じくらい重要です。プロンプトが明確で具体的であればあるほど、結果はあなたのイメージに近づきます。
|
||||
- 最初に目標と制約条件を明確にしておけば、後の修正の回数を減らすことができます。これは時間の節約になるだけでなく、使用量とコストの節約にもなります。
|
||||
|
||||
---
|
||||
|
||||
# 3. ツールの概要（Vibe Coding / UIUXツール）
|
||||
|
||||
## 1. AI Agentプラットフォーム
|
||||
|
||||
| **Name** | **Platform** |
|
||||
| ------------------------------------------ | ------------ |
|
||||
| **[Lovable](https://lovable.dev/)** | Web-based |
|
||||
| **[Cursor](https://cursor.com/cn/agents)** | PC |
|
||||
| **[Z.ai](https://chat.z.ai/)** | Web-based |
|
||||
| **[Replit](https://replit.com/~)** | Web-based |
|
||||
| **[Minimax](https://agent.minimaxi.com/)** | Web-based |
|
||||
| **[Trae](https://www.trae.ai/)** | PC |
|
||||
| **[V0](https://v0.app/)** | Web-based |
|
||||
|
||||
## 2. AI UIUXプラットフォーム
|
||||
|
||||
| **Name** | **Platform** |
|
||||
| ------------------------------------- | -------------------- |
|
||||
| **[Mastergo](https://mastergo.com/)** | Web-based |
|
||||
| **[FIgma](https://www.figma.com/)** | Web-based, PC Plugin |
|
||||
|
||||
---
|
||||
|
||||
# 4. 実践チュートリアル（Vibe Coding + UIの組み合わせ）
|
||||
|
||||
1. Vibe Codingを行うプラットフォームのチャットウィンドウで、作りたいプログラムの説明を入力します。
|
||||
例：
|
||||
|
||||
> フロントエンドとバックエンドを備えたシンプルなスネーク（Snake）Webアプリケーションを構築してください。
|
||||
>
|
||||
> 1. フロントエンド
|
||||
>
|
||||
> - ページ1：ゲームページ
|
||||
> - キーボードで蛇の移動を操作します。
|
||||
> - 蛇が食べるのは食べ物ではなく、英単語です。
|
||||
> - ページのサイドバーに収集済みの単語とその数を表示します。
|
||||
> - ゲームオーバー後も、収集済みの単語は保持され、新しいゲームにも引き継がれます。
|
||||
> - ページ2：詩を作るページ（Make Poem）
|
||||
> - ゲームページと同じ単語リストを表示します（データは同一）。
|
||||
> - ボタンを提供し、現在収集している単語をバックエンドに送信して詩を生成します。
|
||||
> - 詩の生成後、使用された単語をリストから削除またはカウントを減らします。
|
||||
>
|
||||
> * GameとMake Poemの2つのページ間を切り替えるためのシンプルなナビゲーションを追加してください。
|
||||
> * 収集した単語が両方のページで確認できるようにしてください。
|
||||
>
|
||||
> 2. バックエンド
|
||||
>
|
||||
> - 収集した単語を受け取り、詩を返すバックエンドAPIを提供してください。
|
||||
> - DeepSeek APIを使用して詩を生成します。
|
||||
> - API Keyを`.env`ファイルに保存し、`.gitignore`でこのファイルを除外してください。
|
||||
|
||||
2. DeepSeek API Keyを入力します。（[https://platform.deepseek.com/](https://platform.deepseek.com/)で取得できます）
|
||||
1. LLMのAPI Keyは、あなた自身のプロジェクトで大規模言語モデルを呼び出すために使用します。これは機密情報であるため公開できず、設定ファイルに別途記載する必要があります。
|
||||
**なぜ`.env`ファイルを使い、GitHubにアップロードしてはいけないのか？**
|
||||
- `.env`ファイルは**鍵やパスワード**（例：DeepSeek API Key）を保存するために特化しています。
|
||||
- このファイルがGitHubにアップロードされると、世界中の人があなたの鍵を見て不正使用する可能性があります。
|
||||
- 安全のため、`.gitignore`ファイルで`.env`を除外するよう宣言し、Gitが追跡しないようにする必要があります。
|
||||
- これにより、プロジェクトはローカルでこれらの鍵を正常に使用しながら、リポジトリで鍵が漏洩することはありません。
|
||||
|
||||
3. 生成結果を確認した後、エラーや修正が必要な箇所があれば、チャットウィンドウで直接修正のリクエストを入力できます。
|
||||
4. ページデザインに満足できない場合は、FigmaやMastergoでインターフェースを再設計し、そのデザインコンセプトをAgentにフィードバックすることもできます。
|
||||
|
||||
- **例**
|
||||
|
||||
> _Word-Snake_ という名前の**2ページWebアプリケーション**を設計してください。
|
||||
>
|
||||
> - **Gameページ：**
|
||||
> - 蛇はキーボードで操作して移動します。
|
||||
> - 蛇が食べるのは通常の食べ物ではなく、英単語です。
|
||||
> - 右側のパネルに収集済みの単語と数を表示します。
|
||||
> - ゲームオーバー後も、単語の在庫はリセットされず、次のラウンドに引き継がれます。
|
||||
> - **Make Poemページ：**
|
||||
> - 同じ共有単語在庫を表示します。
|
||||
> - ユーザーが一部の単語を選択し、**Generate Poem**ボタンをクリックします。
|
||||
> - 選択した単語をバックエンドに送信し、DeepSeek APIで詩を生成します。
|
||||
> - 詩の生成後、使用された単語を在庫から削除または減らします。
|
||||
> - **ナビゲーション：** シンプルなTabまたはトップメニューで2つのページ間を切り替えます。
|
||||
> - **共有状態：** 収集した単語が両方のページで常に同期され、確認できるようにします。
|
||||
|
||||
- **効果の例**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 5. AI Agentプラットフォームの比較（シンプルなプロジェクトに最適な組み合わせの選び方）
|
||||
|
||||
それぞれのVibe Codingプラットフォームには独自の特徴とワークフローがあります。私たちは同一の「DeepSeek APIを組み込んだスネークゲーム」という要件を使って、複数のプラットフォームで実測を行い、初心者の視点から長所と短所を評価しました。以下はそのまとめです。
|
||||
|
||||
## 1. 比較基準
|
||||
|
||||
1. **目標（Goal）**
|
||||
DeepSeek APIに接続されたスネーク（Snake）Webアプリケーションを構築する。
|
||||
2. **ゲームの詳細（Game Details）**
|
||||
1. ゲームはDeepSeek LLM APIを使用して詩を生成します。
|
||||
2. 蛇が食べるのは英単語で、収集された単語はゲーム終了後も保持され、新しいゲームでも引き続き使用されます。同じ単語は複数回収集でき、それぞれカウントされます。
|
||||
3. 詩が生成された後、使用された単語は在庫から削除されます。
|
||||
|
||||
3. **必須機能（Must-Haves）**
|
||||
1. スネークゲームを含む実行可能なフロントエンドページ（キーボード操作、Canvasレンダリング）。
|
||||
2. 単語収集の仕組み（単語がボード上に表示され、蛇が単語を食べるとサイドバーのリストが更新される）。
|
||||
3. 複数ラウンドのゲーム間で単語在庫を永続化する機能。
|
||||
4. DeepSeek APIを使用するバックエンド（API Keyがない場合は、まずモックの詩を返すようにする）。
|
||||
5. 「詩を生成する」ボタン：クリック後にバックエンドを呼び出し、詩を表示し、使用状況に応じて単語在庫を更新する。
|
||||
6. API Keyに対する`.env`サポート、および`.gitignore`による鍵の漏洩防止。
|
||||
|
||||
4. **加点要素（Nice-to-Haves）**
|
||||
1. ユーザーがどの単語を使って詩を生成するかを選択できる。
|
||||
2. ユーザーエクスペリエンスが良い（例：サイドバーに単語リストが明確に表示される、詩の表示エリアのレイアウトが適切）。
|
||||
3. 初心者向けにコードにコメントを追加し、主要なロジックを説明している。
|
||||
|
||||
## 2. コーディング出力の比較
|
||||
|
||||
### 1. Lovable（Web-based）
|
||||
|
||||
- **プラットフォームタイプ：** Web
|
||||
- **主な特徴とワークフロー：** Lovableは統合とコラボレーションの面で優れています。Supabaseデータベースの接続などの初期化作業を自動的に完了し、プロジェクトのセットアッププロセスを非常にスムーズにします。プロジェクトの要件を記述するだけで、Agentが各種サービスを連携させ、基本構造を構築してくれます。
|
||||
- **対象ユーザー：** 初めてVibe Codingに挑戦する初心者にとって、Lovableは非常に使いやすい選択肢です。複数サービス連携の複雑さを簡略化し、環境設定ではなくプロンプトとイテレーションに集中できます。高度な自動化のおかげで、すぐに実行可能なプロトタイプを得られます。
|
||||
- **プロンプトのプロセス：**
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
|
||||
|
||||
- **価格：** 比較的高めですが、学校のメールアドレスがあれば、学生認証により半額で利用できます。
|
||||
|
||||
|
||||
### 2. Cursor（IDE）
|
||||
|
||||
- **プラットフォームタイプ：** デスクトップアプリケーション（PC）
|
||||
- **主な特徴とワークフロー：** CursorはAI機能を統合した専用IDEで、Windows、macOS、Linuxに対応しています。コード生成、スマートリライト、コードベース検索などの機能を開発環境に直接組み込んでいます。Webツールと比較すると、より従来のローカル開発体験に近いです。ローカル環境であるため、コンピュータごとの設定が異なり、環境関連の問題に遭遇することがあります。メリットは、プロジェクトがローカルにあるため、追加で実行環境をダウンロード・設定する必要がなく、Cursorが多くの煩雑な手順を処理してくれることです。
|
||||
- **対象ユーザー：** ある程度プログラミングの基礎があるユーザーにとって、Cursorは非常に強力で馴染みのある環境です。しかし、完全なゼロベースの初心者にとっては、プロジェクト構造、依存関係管理、ファイル編成などの概念を自分で理解する必要があり、学習曲線はやや急になります。従来のコーディングプロセスにAIアシスタントを加えたい開発者により適しています。
|
||||
- **プロンプトのプロセス：**
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
|
||||
|
||||
- **価格：**
|
||||
|
||||
|
||||
### 3. Z.ai（Web-based）
|
||||
|
||||
- **プラットフォームタイプ：** Web
|
||||
- **主な特徴とワークフロー：** Z.aiの使い方は比較的シンプルですが、明らかな課題が一つあります：**生成されたコードを手動でコピー＆ペーストする**必要があります。プラットフォーム自体にリアルタイムプレビューウィンドウがないため、コードの実行結果をすぐに確認するのが難しいです。
|
||||
- **対象ユーザー：** このプラットフォームは比較的「手動」の使用方式を求めます。自動化が少ないため、コードと直接向き合う必要があり、AIの出力内容を深く理解したい人にとっては逆に良い訓練になります。しかし、頻繁なコピー＆ペーストは効率の問題とミスのリスクをもたらします。ワンクリック体験を追求する人ではなく、「生のAI出力コード」を見たい方に向いています。
|
||||
- **プロンプトのプロセス：**
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
|
||||
|
||||
- **価格：**
|
||||
|
||||
|
||||
### 4. Replit（Web-based）
|
||||
|
||||
- **プラットフォームタイプ：** Web
|
||||
- **主な特徴とワークフロー：** Replitはオールインワンのオンライン開発・デプロイ環境で、ブラウザ上でコーディング、プログラムの実行、オンラインアクセスURLの生成が可能です。コーディングを始める前に、明確なアクションプランを提示します。またビジュアルエディタも提供しており、プレビューウィンドウで直接UIを変更でき、ソースコードが自動的に同期更新されます。これにより、AIの出力が期待通りかどうかを随時確認でき、修正の往復を大幅に減らすことができます。
|
||||
|
||||
|
||||
|
||||
- **対象ユーザー：** Replitは初心者に非常に使いやすいです。コーディングからデプロイまでの完全なサイクルを簡略化し、自前でサーバーやホスティングサービスを設定する必要がありません。コラボレーション機能も強力で、同級生と一緒にプロジェクトを作ったり、他の人にリモートでコードを見てもらうのに適しています。
|
||||
- **プロンプトのプロセス：** 構築中、AIは最初から要件を完全に理解しているわけではなく、約3ラウンドのイテレーションを経て、最終的に理想的な結果に到達しました。
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
|
||||
|
||||
- **価格：**
|
||||
|
||||
|
||||
### 5. Minimax（Web-based）
|
||||
|
||||
- **プラットフォームタイプ：** Web
|
||||
- **主な特徴とワークフロー：** Minimaxはタスクの実行に通常かなり時間がかかります。そのプロセスには、AIが自動的にエラーを発見して修正することが多く含まれるため、全体として遅く、やや手間がかかる印象です。本プロジェクトを例にすると、Agentは通常まず詳細な計画を作成し、その後ステップバイステップでバックエンド、データベース、フロントエンドのロジックを構築していきます。
|
||||
- **対象ユーザー：** 自動的にテストを実行しエラーを修正するため、時間とTokenの消費が大きいですが、AIがどのように問題を特定し解決するかを明確に観察でき、学習の観点からは非常に価値があります。
|
||||
- **プロンプトのプロセス：**
|
||||
|
||||
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
|
||||
|
||||
- **価格：** 無料版では複雑なプロジェクトを最初から最後までスムーズに完了するのが難しい場合があるため、プロジェクトを完全に構築できるよう、有料プランへのアップグレードをお勧めします。
|
||||
|
||||
|
||||
### 6. Trae（IDE）
|
||||
|
||||
- **プラットフォームタイプ：** デスクトップアプリケーション（PC）
|
||||
- **主な特徴とワークフロー：** デスクトップアプリケーションとして、TraeはWebツールと比較してパフォーマンスとレスポンス速度で通常優位性があります。ただし、ダウンロードとインストールが必要で、一部のユーザーにとっては導入の敷居が少し高くなります。同様に、ローカル環境であるため、コンピュータの設定や依存環境の違いにより、ある程度の不確実性が生じます。メリットは、Traeがローカルでのプロジェクト作成と実行設定を支援し、直接ローカルで開発とデバッグができることです。
|
||||
- **対象ユーザー：** 長期的にVibe Codingプロジェクトを行い、専用のデスクトップツールを使用したいと考えているユーザーにより適しています。「たまに遊んでみたい」だけの方には、最も軽量な選択肢ではないかもしれません。
|
||||
- **プロンプトのプロセス：**
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
|
||||
|
||||
- **価格：** 価格は比較的手頃で、無料版でも品質の良い小規模プロジェクトを十分に完了できます。
|
||||
|
||||
|
||||
### 7. V0（Web-based）
|
||||
|
||||
- **プラットフォームタイプ：** Web
|
||||
- **主な特徴とワークフロー：** V0はVercelが提供する、React UIコンポーネントの生成に特化したツールです。高品質で本番環境に使用可能なインターフェースの生成において優れたパフォーマンスを発揮します。ただし実際の使用では、「コードビューが見つけにくい」「API Keyをどこに設定すべきかの明確な説明がない」といった問題に直面することがあります。
|
||||
- **対象ユーザー：** V0はフロントエンドとUI/UXデザインに注力する学生やデザイナーに非常に適しています。しかし完全なフルスタックソリューションではなく、バックエンドロジックとAPI統合を実装するには他のプラットフォームを使用する必要があるため、「ワンストップで完全なアプリケーションを構築する」ことが目標であれば、最適な第一選択ではないかもしれません。
|
||||
- **プロンプトのプロセス：**
|
||||
|
||||
|
||||
|
||||
|
||||
- **スネークゲームの効果：**
|
||||
|
||||
- **価格：** 無料ユーザーは約4〜5個のシンプルなプロジェクトを構築できます。
|
||||
|
||||
|
||||
## 3. プラットフォームの総合比較
|
||||
|
||||
| **プラットフォーム** | **レビュー** | **Platform** | **備考** |
|
||||
| ------------------------------------------ | ------------------------------------------------------------------------------------------ | ------------ | ------------------------------------------------------------------------------------------ |
|
||||
| **[Lovable](https://lovable.dev/)** | AIプログラミング初心者に非常にやさしく、操作がシンプルで体験がスムーズ。理想的な入門選択。 | Web-based | Supabaseなどのサービス接続を自動的に完了し、設定コストを削減。 |
|
||||
| **[Cursor](https://cursor.com/cn/agents)** | 開発経験のあるユーザーに適しており、生産性とコード品質を大幅に向上。 | PC | ある程度のプログラミング基礎が必要。ローカル環境ではプロジェクト構造や依存関係を自分で理解する必要がある。 |
|
||||
| **[Z.ai](https://chat.z.ai/)** | プログラミングの基礎があり、AI出力コードの細部を直接研究したいユーザーにより適している。 | Web-based | プレビューウィンドウがなく、結果の確認が面倒。コードの手動貼り付け、フォルダやファイルの手動作成、サービスの手動実行が必要。 |
|
||||
| **[Replit](https://replit.com/~)** | アイデアを素早くアクセス可能なオンラインサービスにしたいユーザーにお勧め。 | Web-based | オールインワンのオンライン開発・デプロイ。コラボレーション対応、ビジュアルエディタ付き。 |
|
||||
| **[Minimax](https://agent.minimaxi.com/)** | AIの自動的なエラー検出と修正の全プロセスを見て学びたい人に適しているが、全体として遅くToken消費が大きい。 | Web-based | 全プロセスが長く、AIが複数回自動テストを実行してエラーを修正する。 |
|
||||
| **[Trae](https://www.trae.ai/)** | プログラミング経験があり、デスクトップIDE + AI Agentの組み合わせを使いたいユーザー向けの効率向上ツール。 | PC | ローカルインストールと環境設定が必要だが、パフォーマンスが良く、長期的なVibe Codingプロジェクトに適している。 |
|
||||
| **[V0](https://v0.app/)** | React UIの視覚効果を素早く作りたい非開発者向けに最適化。フロントエンド/デザイン志向の学生に適している。 | Web-based | React UI生成に特化。バックエンドや完全なアプリケーション構築には他のプラットフォームとの連携が必要。 |
|
||||
+344
@@ -0,0 +1,344 @@
|
||||
# デザインとプログラミングAgentでウェブサイトを設計する
|
||||
|
||||
## 本章の概要
|
||||
|
||||
本章では、デザインと開発がAIを通じてどのように完璧に連携できるかを紹介します。あなたはプロダクトマネージャーの役割を担い、「デザインAgent」にロゴデザイン、カラースキーム、ページレイアウトを指示し、その後「プログラミングAgent」と協力してビジュアル稿を実行可能なコードに変換します。アイデアの構想からウェブサイトの公開まで、フルパイプラインのAI活用開発フローを体験し、一人でチームを務められるようになります。
|
||||
|
||||
---
|
||||
|
||||
# 1. 入門ガイド
|
||||
|
||||
## 1. チュートリアルの紹介
|
||||
|
||||
AIデザインAgentとコーディングAgentを使って、ゼロから完全なウェブサイトを構築しましょう。
|
||||
|
||||
- **デザインAgent**：ロゴ、ウェブページレイアウト、カラースキームなどのビジュアル要素の作成を担当
|
||||
- **コーディングAgent**：あなたがプロンプトで指定した要件とレイアウトに基づいて、HTML/CSS/JSなどの実際のコードを記述し、実行可能なウェブサイトを構築
|
||||
|
||||
## 2. デザインAgentとコーディングAgent
|
||||
|
||||
- **デザインAgent**：あなたが提供するプロンプトに基づいて、画像、ページモックアップ、デザインスタイルを生成するAI。
|
||||
- Mastergo
|
||||
- Lovart
|
||||
- Figma MCP
|
||||
- **コーディングAgent**：あなたがプロンプトで要求した機能とレイアウトに基づいて、実際のコード（HTML/CSS/JSなど）を記述するAI。
|
||||
- Z.AI
|
||||
- Trae
|
||||
- Cursor
|
||||
- Lovable
|
||||
|
||||
---
|
||||
|
||||
# 2. デザインAgentを使ってロゴを作成
|
||||
|
||||
## 1. ロゴデザイン時に考慮すべき重要要素
|
||||
|
||||
ロゴは、ウェブサイトの第一印象を決定づける重要な要素の一つです。AIデザインAgentから満足のいく結果を得るには、プロンプトで希望するロゴのタイプを明確に説明する必要があります。
|
||||
|
||||
1. **ブランド名 / テキスト**
|
||||
|
||||
- ロゴに含める必要のあるテキスト（例：ウェブサイトタイトル、ブランド名など）。
|
||||
|
||||
2. **スタイル（ムード / 雰囲気）**
|
||||
|
||||
- ロゴが伝えたい全体的な感覚や雰囲気。
|
||||
- _例：ミニマル、キュート、シンプル、モダン、レトロ、未来感など。_
|
||||
|
||||
3. **カラースキーム**（任意）
|
||||
|
||||
- ロゴの配色は、ウェブサイト全体の基調と一致させることが望ましい。
|
||||
- 具体的な16進数カラーコードや、大まかな色調（寒色、暖色など）を指定可能。
|
||||
- _例：**`#171721`**（黒）、**`#FF7130`**（オレンジ）。_
|
||||
|
||||
4. **形状（シェイプ / 構造）**
|
||||
|
||||
- ロゴに特定の形状や構図が必要かどうかを明確にする。
|
||||
- _例：円の中にテキスト、アイコン＋テキストの組み合わせ、アイコン中心のロゴなど。_
|
||||
|
||||
5. **アイコン / シンボル要素**（任意）
|
||||
|
||||
- ロゴに含めたい図形や記号。
|
||||
- _例：本のアイコン、稲妻のシンボル、AI関連の図形、抽象的なジオメトリックパターンなど。_
|
||||
|
||||
## 2. ロゴデザインのプロンプト作成
|
||||
|
||||
**プロンプト例**
|
||||
|
||||
```
|
||||
「ミニマルスタイルのロゴをデザインしてください。ブランド名は 'My First Website'。
|
||||
黒 (#171721) とオレンジ (#FF7130) を使用し、テキストを円の中に配置してください。」
|
||||
```
|
||||
|
||||
```
|
||||
「ブランド名 'AIID' のロゴをデザインしてください。
|
||||
全体的に未来感があり、クリーンでシンプルなスタイルに。メインカラーは青と白。
|
||||
AIを象徴する抽象的な図形とテキストを組み合わせ、透明背景のPNGで書き出してください。」
|
||||
```
|
||||
|
||||
## 3. Agentにデザインを依頼
|
||||
|
||||
- 上記のプロンプトを入力 → Agentが生成した複数のデザイン案を比較。
|
||||
|
||||
|
||||
|
||||
## 4. 最終ロゴを決定
|
||||
|
||||
- 草案の中から一番好きなバージョンを選択してダウンロード。
|
||||
|
||||
---
|
||||
|
||||
# 3. ウェブサイトの構造を計画
|
||||
|
||||
## 1. 基本セクションを理解する
|
||||
|
||||
ウェブサイトの制作を始める前に、どのメニュー（セクション）を含めるかを計画することが重要です。メニューの設計は、訪問者に何を見せたいか、そしてどのような行動をとってほしいかによって決まります。
|
||||
一般的に、ウェブサイトは **Home / About / Contact** などの基本セクションで構成されます。
|
||||
|
||||
## 2. 構造スケッチを自分で描く（任意）
|
||||
|
||||
ウェブサイトの目的に基づいて、簡単なメニュー構造を書き出すことができます。
|
||||
|
||||
### 基本メニュー
|
||||
|
||||
1. **Home**
|
||||
1. 訪問者がウェブサイトに入って最初に見るメインページ
|
||||
2. 通常、ロゴ、ヒーローエリア、短いキャッチフレーズや紹介文が含まれる
|
||||
2. **About**
|
||||
1. あなたが誰か、またはプロジェクト/サービスの目的を紹介
|
||||
2. 個人ポートフォリオ：自己紹介＋略歴
|
||||
3. サービス系ウェブサイト：ビジョン、目標、コア機能
|
||||
3. **Contact**
|
||||
1. 連絡先情報（メールアドレス、電話番号、ソーシャルメディアリンクなど）
|
||||
2. シンプルなお問い合わせフォームを追加することも可能
|
||||
|
||||
### オプションメニュー
|
||||
|
||||
4. **Services / Projects**
|
||||
1. 提供するサービスや、プロジェクト/ポートフォリオの紹介
|
||||
2. 通常、リストやカード形式で表示
|
||||
|
||||
5. **Gallery**
|
||||
1. 画像、写真、デザイン作品の展示用
|
||||
|
||||
6. **Blog / News**
|
||||
1. 記事、ニュース、ログの公開用
|
||||
|
||||
7. **FAQ**
|
||||
1. 訪問者からよくある質問と回答のまとめ
|
||||
|
||||
## 3. カラースキームの選択（任意）
|
||||
|
||||
すでにロゴがある場合や、特定のカラーリングでウェブサイトをデザインしたい場合は、プロンプトにカラーコードを直接指定することもできます。
|
||||
|
||||
**例：** `#171721, #872B97, #FF7130, #FF3C68`
|
||||
|
||||
カラースキームが思い浮かばない場合は、配色ウェブサイトやキーワード検索でインスピレーションを見つけることもできます。
|
||||
|
||||
- **配色参考ウェブサイト**
|
||||
- https://colorhunt.co/
|
||||
- https://coolors.co/
|
||||
|
||||
|
||||
|
||||
- **Googleでキーワード検索して配色を探す**
|
||||
|
||||
|
||||
|
||||
## 4. ウェブサイトデザインのプロンプト作成
|
||||
|
||||
**プロンプト例**
|
||||
|
||||
```
|
||||
「Home、About、Contactの3つのセクションで構成されるシングルページウェブサイトをデザインしてください。
|
||||
配色は #171721、#FF7130、#FF3C68 を使用。
|
||||
全体的にモダンでシンプルなスタイルに。」
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4. デザインAgentを使ってウェブサイトを設計
|
||||
|
||||
## 1. プロンプトを入力 → デザイン稿を生成
|
||||
|
||||
- プロンプトに計画した構造と選択した配色を記載。
|
||||
|
||||
**Mastergoプロンプト例**
|
||||
|
||||
|
||||
|
||||
## 2. デザイン稿を確認し修正意見を提示
|
||||
|
||||
自分のニーズに合わせて、Agentにフィードバックを提出できます。例えば：
|
||||
|
||||
- 「派手すぎるので、全体的にもっとシンプルなスタイルに変更して。」
|
||||
- 「フォントを変えて。」
|
||||
- 「カラーリングを調整して。」
|
||||
- 「この部分を削除して。」
|
||||
|
||||
|
||||
|
||||
## 3. 最終デザインを確定
|
||||
|
||||
デザイン稿を複数回修正して満足したら、このデザインをコードに変換し、コーディングAgentが理解して作業を続けられるようにします。
|
||||
|
||||
デザインをコードに変換する方法はプラットフォームによって異なりますが、通常はデザインプラットフォーム内で特定のプラグインをインストールして使用します。
|
||||
|
||||
**Mastergoの例**
|
||||
|
||||
1. [Mastergoプラグインサイト](https://mastergo.com/community/plugin)を開き、**seal** を検索。
|
||||
|
||||
|
||||
|
||||
2. デザインページに戻り、**四角アイコン（プラグイン）** をクリック。
|
||||
|
||||
|
||||
|
||||
3. コードに変換したいデザイン領域を選択し、**Generate** ボタンをクリックしてコードを生成。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 5. コーディングAgentを使ってウェブサイトを構築
|
||||
|
||||
## 1. HTML/CSS/JSの基本概念を理解する
|
||||
|
||||
ウェブサイトは本質的に3つの言語で構成されています：
|
||||
|
||||
- **HTML（HyperText Markup Language）** → 構造（骨組み）
|
||||
- **CSS（Cascading Style Sheets）** → スタイル（外観）
|
||||
- **JavaScript（JS）** → 機能（インタラクション）
|
||||
|
||||
この3つが連携して、私たちが見る完全なウェブページを構成します。
|
||||
|
||||
1. **🏗️ HTML（構造）**
|
||||
|
||||
- ページに「何を表示するか」を定義
|
||||
- テキスト、画像、ボタン、リンクなどの要素を配置
|
||||
- 建物の **壁と骨組み** に相当
|
||||
|
||||
**例**
|
||||
|
||||
```html
|
||||
<h1>こんにちは！</h1>
|
||||
<p>これが私の最初のウェブサイトです。</p>
|
||||
<a href="contact.html">お問い合わせ</a>
|
||||
```
|
||||
|
||||
2. **🎨 CSS（スタイル）**
|
||||
|
||||
- 「コンテンツをどのように表示するか」を決定
|
||||
- 文字サイズ、色、余白、背景、ボタンの形状などを制御
|
||||
- HTMLに「服」とビジュアルスタイルを与える
|
||||
|
||||
**例**
|
||||
|
||||
```css
|
||||
h1 {
|
||||
color: #FF7130; /* テキストカラー */
|
||||
font-size: 36px; /* フォントサイズ */
|
||||
text-align: center; /* 中央揃え */
|
||||
}
|
||||
|
||||
body {
|
||||
background-color: #171721; /* 背景色 */
|
||||
color: white; /* デフォルトテキストカラー */
|
||||
}
|
||||
```
|
||||
|
||||
3. **⚙️ JavaScript（JS）（機能）**
|
||||
|
||||
- ウェブページをユーザーとインタラクティブにする
|
||||
- ボタンクリック、メニュー展開、画像スライダー、フォーム送信などの動的効果を実現
|
||||
- HTML/CSSが静的な骨組みと外観だとすれば、JSはウェブページを「活かす」 **脳** に相当
|
||||
|
||||
**例**
|
||||
|
||||
```javascript
|
||||
function showAlert() {
|
||||
alert("ボタンがクリックされました！");
|
||||
}
|
||||
```
|
||||
|
||||
```html
|
||||
<button onclick="showAlert()">クリックして</button>
|
||||
```
|
||||
|
||||
## 2. コーディングAgentにコードを生成させる
|
||||
|
||||
**プロンプト例**
|
||||
|
||||
```
|
||||
「Home、About、Contactセクションを含むシングルページウェブサイトのHTMLとCSSを書いてください。
|
||||
配色は #171721、#FF7130、#FF3C68 を使用。
|
||||
背景は黒、テキストは白にしてください。」
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 3. ウェブサイトを実行
|
||||
|
||||
ラフコードが生成されると、Agentは通常プロジェクトを自動的に起動し、生成されたウェブページを表示します。
|
||||
|
||||
Agentを再起動した場合や、ウェブページが表示されない場合は、次のようなプロンプトを入力してください：
|
||||
|
||||
```
|
||||
"Please activate the project"
|
||||
```
|
||||
|
||||
Agentがプロジェクトを再起動しプレビューページを開くので、現在の効果を確認しやすくなります。
|
||||
|
||||
## 4. 簡単な修正を行う
|
||||
|
||||
引き続き自然言語でラフデザインを微調整できます。例えば：
|
||||
|
||||
- 「ボタンをもっと大きくして。」
|
||||
- 「フォントを太くして。」
|
||||
|
||||
|
||||
|
||||
## 5. ウェブサイトのテキスト内容を修正
|
||||
|
||||
Agentが生成した初期版のウェブサイトには、通常、自動生成されたプレースホルダーテキストが含まれています。実際のシナリオに近づけるために、事前に実際の内容を用意し、Agentに置き換えてもらうことができます。
|
||||
|
||||
**応用例**：AIIDウェブサイトのAboutページを更新
|
||||
|
||||
1. Aboutページに表示したい内容を事前に書く。Agentが理解しやすいように、Markdown形式で保存すると便利。
|
||||
|
||||
|
||||
|
||||
2. ダイアログでAgentに、そのファイルの内容を指定ページに適用するよう指示。
|
||||
|
||||
|
||||
|
||||
3. 内容適用後の更新版を確認。
|
||||
|
||||
|
||||
|
||||
## 6. 画像を挿入
|
||||
|
||||
特定の画像（ロゴや背景画像など）を追加したい場合は、まず画像をプロジェクトフォルダにアップロードし、プロンプトでページのどの位置にこれらの画像を使用するかを指定します。
|
||||
|
||||
- **例：**
|
||||
|
||||
|
||||
|
||||
- **結果：**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 6. デザインとコードの統合
|
||||
|
||||
## 1. デザインファイルとウェブサイトコードを統合（任意）
|
||||
|
||||
デザインAgentからコードファイルをダウンロードした後、それらを現在のプロジェクトディレクトリに移動し、コーディングAgentにこれらのデザインコードと既存プロジェクトの統合を依頼できます。
|
||||
|
||||
- **例：**
|
||||
|
||||
|
||||
|
||||
- **結果：**
|
||||
|
||||
|
||||
@@ -0,0 +1,325 @@
|
||||
---
|
||||
title: 'コードを書くときにエラーが出たらどうするか - スクリーンショットでAIに聞く実践ガイド'
|
||||
description: 'AIに効率的に質問して開発中の様々なエラー問題を解決する方法を学び、スクリーンショット、説明、問題箇所の特定の標準フローを習得し、AIをデバッグアシスタントにする。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>30 分</strong>'
|
||||
</script>
|
||||
|
||||
# コードを書くときにエラーが出たらどうするか
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['デバッグのコツ', 'AI協働', '問題トラブルシューティング', '開発者ツール']" coreOutput="標準化されたエラートラブルシューティングフロー" expectedOutput="よくあるエラーの90%を自力で解決できる">
|
||||
|
||||
AI時代において、エラーのトラブルシューティング方法はすでに変わりました。
|
||||
|
||||
すべてのエラータイプを暗記する必要も、デバッグの専門家になる必要も、エラーの意味を理解する必要すらありません。
|
||||
|
||||
<strong>覚えるべきことは一つだけ：AIへの聞き方。</strong>
|
||||
|
||||
本章では、<strong>基礎から応用まで</strong>のトラブルシューティングフローを教えます：
|
||||
|
||||
1. <strong>ステップ1：直接聞く</strong>：現象を説明 + スクリーンショット、一言で質問
|
||||
2. <strong>ステップ2：情報を追加</strong>：解決できない場合、F12を開いて重要情報を追加
|
||||
|
||||
このフローをマスターすれば、<strong>エラーの90%は自分で解決できます</strong>。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 説明
|
||||
本章のすべての方法は、Cursor/Trae/Claude等のAI IDEの実際の使用経験に基づいており、日常開発に直接応用できます。
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '直接質問', description: '現象を説明 + スクリーンショット' },
|
||||
{ title: '情報を追加', description: 'F12を開いて問題を特定' },
|
||||
{ title: '反復解決', description: '問題が解決するまで' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 核心のコツ：スクリーンショットでAIに聞く
|
||||
|
||||
::: warning なぜこの章が重要なのか？
|
||||
|
||||
多くの初心者がエラーに遭遇したときの最初の反応は：
|
||||
- 慌ててコードを適当にいじる
|
||||
- 「xxx エラーの解決方法」を30分かけて検索する
|
||||
- エラーの意味を理解しようとする
|
||||
- 一人で深夜までデバッグする
|
||||
|
||||
<strong>これらはすべて時間の無駄です。</strong>
|
||||
|
||||
AI時代において、デバッグはとてもシンプルなことになりました：
|
||||
|
||||
```
|
||||
エラーを発見 → スクリーンショット → AIに聞く → AIの指示に従う
|
||||
```
|
||||
|
||||
エラーを理解する必要も、デバッグができる必要も、問題がどこにあるかを知る必要すらありません。
|
||||
|
||||
<strong>必要なのは「聞き方」を学ぶことだけです。</strong>
|
||||
|
||||
:::
|
||||
|
||||
### 1.1 最もシンプルな質問方法
|
||||
|
||||
複雑なテンプレートは不要で、以下の2つの方法から選べます：
|
||||
|
||||
**方法1：現象を説明する**
|
||||
|
||||
フォーマット：さっき何をしたか、今どうなったか
|
||||
|
||||
```
|
||||
さっきログインページのコードを修正したら、ページが白くなってしまいました。どうすればいいですか？
|
||||
```
|
||||
|
||||
**方法2：スクリーンショット**
|
||||
|
||||
現在のページやエラー情報を直接スクリーンショットで撮る
|
||||
|
||||
```
|
||||
[スクリーンショット]
|
||||
|
||||
このエラーはどうやって解決しますか？
|
||||
```
|
||||
|
||||
**最良の方法：説明 + スクリーンショット**
|
||||
|
||||
```
|
||||
さっきログインページのコードを修正したら、ページが白くなってしまいました。
|
||||
|
||||
[スクリーンショット]
|
||||
|
||||
どうすればいいですか？
|
||||
```
|
||||
|
||||
**覚えておいてください：コンテキストを明確に説明し、スクリーンショットを添えれば、AIがより早く問題を解決してくれます。**
|
||||
|
||||
### 1.2 問題をうまく伝える方法
|
||||
|
||||
多くの初心者は質問したいことは分かっていても、どう言えばいいか分かりません。実際には、次の3つを明確にするだけで十分です：
|
||||
|
||||
**1. さっき何をしたか**
|
||||
|
||||
```
|
||||
さっき保存ボタンをクリックしました
|
||||
さっきログインページのコードを修正しました
|
||||
さっきページをリロードしました
|
||||
```
|
||||
|
||||
**2. 今どうなっているか**
|
||||
|
||||
```
|
||||
ページが空白になっています
|
||||
ボタンを押しても反応しません
|
||||
エラーメッセージが表示されています
|
||||
```
|
||||
|
||||
**3. どうしたいか**
|
||||
|
||||
```
|
||||
データを保存させたい
|
||||
ページを正常に表示させたい
|
||||
ボタンを押した後にプロンプトを表示させたい
|
||||
```
|
||||
|
||||
**完全な例：**
|
||||
|
||||
```
|
||||
さっき保存ボタンをクリックしたら、「保存に失敗しました」というエラーが表示されました。
|
||||
|
||||
[スクリーンショット]
|
||||
|
||||
フォームデータをデータベースに正常に保存したいのですが、どうすればいいですか？
|
||||
```
|
||||
|
||||
**重要な原則：**
|
||||
- 専門用語を使わず、平易な言葉で説明する
|
||||
- 時系列で説明する：先に何をして、それからどうなったか
|
||||
- 自分の期待を伝え、AIに何をしてほしいかを伝える
|
||||
|
||||
## 2. ステップ1：直接現象を説明して質問する
|
||||
|
||||
問題に遭遇したら、<strong>急いでF12を開く必要はありません</strong>。まず現象を直接説明し、現在のページのスクリーンショットを撮ってAIに見せましょう。
|
||||
|
||||
多くの場合、AIはスクリーンショットを見るだけで直接解決策を提示できます。
|
||||
|
||||
### 2.1 よくある現象の説明方法
|
||||
|
||||
::: tip 直接説明すればOK
|
||||
|
||||
**ページが白い**
|
||||
```
|
||||
ページを開いたら空白になっています。どうすればいいですか？
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
**ボタンを押しても反応しない**
|
||||
```
|
||||
このボタンを押しても反応しません。見てください。
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
**データが保存できない**
|
||||
```
|
||||
保存を押してもデータが保存されません。どうすればいいですか？
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
**スタイルの表示がおかしい**
|
||||
```
|
||||
このボタンの位置がずれています。どうやって調整しますか？
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
**APIエラー**
|
||||
```
|
||||
APIを呼び出したらエラーが出ました。見てください。
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 2.2 AIが直接解決してくれたら
|
||||
|
||||
おめでとうございます、問題は解決しました！AIの指示通りに修正すればOKです。
|
||||
|
||||
### 2.3 AIが「もっと情報が必要」と言ってきたら
|
||||
|
||||
このとき初めてF12を開いて、重要情報を追加する必要があります。次をご覧ください。
|
||||
|
||||
## 3. ステップ2：重要情報を追加する
|
||||
|
||||
AIが「もっと情報が必要」と言ってきたら、問題のタイプに応じてF12を開いて対応する内容のスクリーンショットを撮ります。
|
||||
|
||||
### 3.1 いつ情報を追加する必要があるか
|
||||
|
||||
AIから以下のような回答が来るかもしれません：
|
||||
- 「Consoleを開いてエラーがないか確認してください」
|
||||
- 「Networkパネルのスクリーンショットを見せてください」
|
||||
- 「具体的なエラー情報を見る必要があります」
|
||||
|
||||
このような場合は、以下のガイドに従ってスクリーンショットを追加してください。
|
||||
|
||||
### 3.2 Console情報の追加（ページが白い/エラーが出る場合）
|
||||
|
||||
::: tip 操作手順
|
||||
|
||||
**ステップ1：F12で開発者ツールを開く**
|
||||
|
||||
Macは `Cmd+Option+I`、またはページを右クリックして「検証」を選択。
|
||||
|
||||
**ステップ2：Consoleタブに切り替える**
|
||||
|
||||
**ステップ3：赤いエラー情報をスクリーンショット**
|
||||
|
||||
**ステップ4：AIに送る**
|
||||
|
||||
```
|
||||
Consoleエラーは以下の通りです：
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 3.3 Network情報の追加（データの問題/APIエラー）
|
||||
|
||||
::: tip 操作手順
|
||||
|
||||
**ステップ1：F12で開発者ツールを開く**
|
||||
|
||||
**ステップ2：Networkタブに切り替える**
|
||||
|
||||
**ステップ3：もう一度操作する**（保存をクリック/ページをリロード）
|
||||
|
||||
**ステップ4：対応するリクエストを見つけてスクリーンショットを撮る**
|
||||
|
||||
- URLとステータスコードを確認
|
||||
- Payload（送信パラメータ）を確認
|
||||
- Response（返却結果）を確認
|
||||
|
||||
**ステップ5：AIに送る**
|
||||
|
||||
```
|
||||
Network情報は以下の通りです：
|
||||
|
||||
リクエスト：[スクリーンショット1]
|
||||
パラメータ：[スクリーンショット2]
|
||||
レスポンス：[スクリーンショット3]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 3.4 Elements情報の追加（スタイルの問題）
|
||||
|
||||
::: tip 操作手順
|
||||
|
||||
**ステップ1：要素を右クリック → 「検証」**
|
||||
|
||||
開発者ツールが自動的にその要素にフォーカスします。
|
||||
|
||||
**ステップ2：Stylesパネルのスクリーンショット**
|
||||
|
||||
**ステップ3：AIに送る**
|
||||
|
||||
```
|
||||
要素のスタイルは以下の通りです：
|
||||
|
||||
[スクリーンショット]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
## 4. ステップ3：解決するまで反復する
|
||||
|
||||
### 4.1 非効率なやり方
|
||||
|
||||
以下のやり方は時間の無駄です：
|
||||
|
||||
エラーを見て慌てて、コードを適当にいじる
|
||||
30分かけてエラーの解決方法を検索する
|
||||
各エラーの意味を理解しようとする
|
||||
一人で深夜までデバッグする
|
||||
|
||||
### 4.2 効率的なやり方
|
||||
|
||||
以下のフローに従いましょう：
|
||||
|
||||
まず現象を説明してスクリーンショットで質問する
|
||||
AIが「もっと情報が必要」と言ってきたら、F12を開いて追加情報を提供する
|
||||
アドバイスに従ってコードを修正する
|
||||
修正後にテストし、問題が残っていればスクリーンショットを撮って再度質問する
|
||||
|
||||
## 5. まとめ：完全なフロー
|
||||
|
||||
```
|
||||
問題に遭遇
|
||||
↓
|
||||
現象を直接説明 + スクリーンショット
|
||||
↓
|
||||
AIに投げる：「どうすればいいですか？」
|
||||
↓
|
||||
AIが直接解決したか？
|
||||
↓ はい
|
||||
AIの指示に従う
|
||||
↓
|
||||
解決したかテストする
|
||||
↓
|
||||
↓ いいえ / AIがもっと情報を必要としている
|
||||
F12を開いて、重要情報を追加する
|
||||
↓
|
||||
再度AIに送る
|
||||
↓
|
||||
解決するまで繰り返す
|
||||
```
|
||||
@@ -0,0 +1,633 @@
|
||||
---
|
||||
title: 'C 誌消費シーンインスピレーションリファレンス'
|
||||
description: '本文書は LLM 大規模モデルの C 誌消費シーンにおけるクリエイティブな応用方向をまとめ、ライフスタイル、感情コンパニオン、エンターテインメント、自己成長、ソーシャルインタラクションなどの分野のインスピレーションシーンを網羅し、一般消費者向けの AI アプリケーション開発者に参考を提供します。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { computed, ref } from 'vue'
|
||||
|
||||
const duration = '約 <strong>4 時間</strong>'
|
||||
|
||||
const vibePoint = ref('')
|
||||
const feeling = ref('')
|
||||
|
||||
// 各シーンのトピックプール - 雰囲気、感覚、心理的暗示を強調
|
||||
const topicPool = {
|
||||
'lifestyle': [
|
||||
{ title: '朝の儀式感アラームアシスタント', desc: '天気、スケジュール、気分に基づいて専用の朝の儀式を生成し、毎日を素晴らしいスタートから始める' },
|
||||
{ title: '一人暮らしの雰囲気クリエイター', desc: '一人暮らしの方に居家の雰囲気プランを設計、照明、音楽、アロマのスマートな組み合わせアドバイス' },
|
||||
{ title: '週末のおうちデート回復プランジェネレーター', desc: '今の気分に基づいて完璧なおうちコンボを推奨：映画＋おやつ＋雰囲気コーディネート' },
|
||||
{ title: '就寝前の心の癒しラジオ', desc: '優しい物語、瞑想ガイドを生成し、眠りをサポートするプライベートラジオ' },
|
||||
{ title: '暮らしの美学インスピレーションキャッチャー', desc: '日常の小さなことから美を発見し、暮らしの美学提案と儀式感ガイドを生成' }
|
||||
],
|
||||
'emotion': [
|
||||
{ title: '深夜のツリーくり聞き手', desc: '24 時間オンラインの感情のゴミ箱、判断せずにすべての悩みを受け止める' },
|
||||
{ title: '失恋回復コンパニオン', desc: '失恋のどん底期に優しい寄り添い、回復アドバイスと感情の出口を提供' },
|
||||
{ title: '不安緩和呼吸コーチ', desc: '不安感情を感知し、呼吸練習とマインドフルネス瞑想をガイド' },
|
||||
{ title: '自信再構築メンター', desc: 'ポジティブな対話と心理的暗示を通じて、自己肯定感と価値観の再構築をサポート' },
|
||||
{ title: '感情日記スマート分析', desc: '感情日記を分析し、感情パターンを発見、温かいインサイトとアドバイスを提供' }
|
||||
],
|
||||
'entertainment': [
|
||||
{ title: '没入型マーダーミステリー DM', desc: 'マーダーミステリーのゲームマスターを演じ、サスペンスの雰囲気を作り出し、ストーリーを進行' },
|
||||
{ title: 'オープンワールドゲームの魂の NPC', desc: '血の通った NPC がプレイヤーのストーリーを記憶し、リアルな感情的絆を生み出す' },
|
||||
{ title: 'パーソナライズドポッドキャスト生成', desc: '興味に基づいて専用ポッドキャストを生成、友達とのおしゃべりのように自然' },
|
||||
{ title: 'バーチャルコンサートの盛り上げ役', desc: 'オンラインコンサートにライブ感を演出、リアルタイムインタラクション、応援、雰囲気レンダリング' },
|
||||
{ title: 'インタラクティブ小説共創パートナー', desc: '読者と一緒にストーリーを共創、すべての選択が世界の行方に影響' }
|
||||
],
|
||||
'growth': [
|
||||
{ title: '個人の成長の証人', desc: '成長の軌跡を記録し、重要な節目で励ましと振り返りを提供' },
|
||||
{ title: '習慣形成ゲーム化コーチ', desc: '退屈な習慣形成を面白い冒険ゲームに変える' },
|
||||
{ title: 'スキル学習パートナーマッチング', desc: '志を同じくする学習仲間を見つけ、お互いに励まし合い、進歩を共有' },
|
||||
{ title: '毎日の小さな幸せ発見者', desc: '生活の中の小さな美しい瞬間を見つける手助け、感謝とポジティブなマインドを育む' },
|
||||
{ title: '人生シミュレーション体験器', desc: '異なる人生の選択肢をシミュレートし、パラレルワールドのもう一つの可能性を体験' }
|
||||
],
|
||||
'social': [
|
||||
{ title: 'アイスブレイクトピックジェネレーター', desc: 'ソーシャルシーンで面白いトピックを提供し、気まずさを解消、距離を縮める' },
|
||||
{ title: 'SNS投稿文雰囲気クリエイター', desc: '写真と気分に基づいて、おしゃれな SNS 投稿文を生成' },
|
||||
{ title: 'デート雰囲気プランナー', desc: 'デートに完全な雰囲気プランを設計、場所からトピック、サプライズまで' },
|
||||
{ title: 'オンライン飲み会の盛り上げ役', desc: 'オンラインパーティーで盛り上げ、ゲームの企画、インタラクションをガイド' },
|
||||
{ title: 'ソーシャルエネルギー管理アシスタント', desc: '内向的な方のソーシャルエネルギー管理をサポート、快適なソーシャルペースを見つける' }
|
||||
],
|
||||
'creative': [
|
||||
{ title: 'インスピレーション枯渇応急キット', desc: 'クリエイティブの行き詰まり時に予想外のインスピレーションスパークを提供' },
|
||||
{ title: '個人スタイル探索ガイド', desc: 'ユニークな個人スタイルの発見をサポート、ファッションから表現まで' },
|
||||
{ title: '手帳＆日記美学アドバイザー', desc: '手帳のレイアウト、配色、コンテンツアイデアの美学アドバイスを提供' },
|
||||
{ title: '写真構図雰囲気ガイド', desc: 'シーンと表現したい感覚に基づいて、写真とレタッチのアドバイスを提供' },
|
||||
{ title: '音楽気分マッチング', desc: '今の気分とシーンに基づいて、完璧な音楽コンボを推奨' }
|
||||
],
|
||||
'travel': [
|
||||
{ title: '街歩き探索ガイド', desc: '地元の人のように街を探索し、隠れた宝スポットを発見' },
|
||||
{ title: '旅行気分日記生成', desc: '旅行の写真と気分を美しい旅行記と思い出に変換' },
|
||||
{ title: '一人旅コンパニオンアシスタント', desc: '一人旅の方に寄り添い、アドバイスと安心感を提供' },
|
||||
{ title: '目的地雰囲気プレビュー', desc: '出発前に目的地の雰囲気を没入的に体験、事前に入り込める' },
|
||||
{ title: '旅行写真雰囲気ガイド', desc: 'シーンと光に基づいて、ストーリー性のある旅行写真の撮り方をガイド' }
|
||||
],
|
||||
'health': [
|
||||
{ title: '運動モチベーション覚醒師', desc: '動きたくない時にちょうどいい励ましとモチベーションを与える' },
|
||||
{ title: 'ヘルシー食インスピレーションキッチン', desc: '気分と食材に基づいて、癒されるヘルシーレシピを生成' },
|
||||
{ title: '睡眠の質向上雰囲気クリエイター', desc: '環境から心理まで、全方位に質の高い睡眠雰囲気を作り出す' },
|
||||
{ title: 'ボディセンシングガイド', desc: '体のシグナルに注意を向け、心身のつながりを構築' },
|
||||
{ title: 'セルフケアリマインダー', desc: '忙しい中で立ち止まり、自分を大切にするようリマインド' }
|
||||
],
|
||||
'learning': [
|
||||
{ title: '知識探索ゲーム化ガイド', desc: '退屈な知識学習を面白い探検アドベンチャーに変える' },
|
||||
{ title: '語学学習シーンパートナー', desc: '異なる役を演じ、シチュエーション会話の中で自然に言語を習得' },
|
||||
{ title: '好奇心満足アシスタント', desc: 'あらゆる奇想天外な疑問に答え、世界への好奇心を満たす' },
|
||||
{ title: '読書ノートインスピレーション', desc: '読書感想の整理をサポート、新しい思考の角度を発見' },
|
||||
{ title: '知識共有雰囲気クリエイター', desc: '学んだ知識を面白い共有コンテンツに変換' }
|
||||
],
|
||||
'relationship': [
|
||||
{ title: '親密な関係コミュニケーションコーチ', desc: '言いにくい感情の表現をサポートし、親密な関係を改善' },
|
||||
{ title: '家族ケアリマインダー', desc: '家族を気遣うことをリマインド、温かいインタラクションのアイデアを提供' },
|
||||
{ title: '友情維持雰囲気クリエイター', desc: '遠距離の友情の維持をサポート、共通の話題を創造' },
|
||||
{ title: '告白＆サプライズプランナー', desc: '大切な人に忘れられないサプライズとロマンチックな瞬間を企画' },
|
||||
{ title: '対立緩和雰囲気ガイド', desc: '関係が緊張した時に雰囲気を和らげるアドバイスと話術を提供' }
|
||||
],
|
||||
'pet': [
|
||||
{ title: 'ペット擬人化日記', desc: 'ペットの視点で日記を生成、飼い主との温かい日常を記録' },
|
||||
{ title: 'ペット行動分析師', desc: 'ペットの行動言語を読み解き、ペットとの絆を深める' },
|
||||
{ title: 'ペットとの時間企画', desc: 'ペットとインタラクションするクリエイティブな活動をデザイン、絆を深める' },
|
||||
{ title: 'ペット記念ストーリー生成', desc: 'ペットの写真と思い出を温かいストーリーに変換' },
|
||||
{ title: '初心者ペット飼い主安心ガイド', desc: '初心者のペットオーナーに温かい寄り添いと指導を提供' }
|
||||
],
|
||||
'finance': [
|
||||
{ title: '消費感情覺察アシスタント', desc: '衝動買いの背後にある感情に気づき、健全な消費観を確立' },
|
||||
{ title: '貯蓄目標ビジュアルモチベーション', desc: '貯蓄目標をビジュアル化された夢の進捗に変換' },
|
||||
{ title: '資産管理知識カジュアル学習', desc: '気軽で面白い方法で資産管理の知識を学ぶ' },
|
||||
{ title: '財務不安緩和師', desc: '財務ストレスに直面した時に感情サポートと実用的アドバイスを提供' },
|
||||
{ title: '少額投資体験ゲーム', desc: 'ゲーム化された方法で投資を体験し、参入のハードルを下げる' }
|
||||
],
|
||||
'career': [
|
||||
{ title: 'キャリア迷いコンパニオン', desc: 'キャリアの迷い期に傾聴、探索、方向性のアドバイスを提供' },
|
||||
{ title: '仕事の達成感覚醒師', desc: '仕事の中の価値と意義を見つけ、情熱を再燃させる' },
|
||||
{ title: '職場ソーシャル雰囲気アシスタント', desc: '職場ソーシャルの気軽なトピックとインタラクションアイデアを提供' },
|
||||
{ title: '副業インスピレーション発掘器', desc: '個人の興味とスキルに基づいて、副業のアイデアを刺激' },
|
||||
{ title: '面接前の自信加油站', desc: '面接前に心理的な準備と自信の励ましを提供' }
|
||||
],
|
||||
'home': [
|
||||
{ title: '居家空間雰囲気デザイナー', desc: '気分と季節に基づいて居家の雰囲気プランを設計' },
|
||||
{ title: '四季インテリアチェンジガイド', desc: '季節に合わせてインテリアを変え、新鮮さを保つ' },
|
||||
{ title: '小スペース空間マジック', desc: '小さなスペースでも快適で温かい雰囲気を作り出す' },
|
||||
{ title: '居家儀式感クリエイター', desc: '日常の居家活動に儀式感を創造' },
|
||||
{ title: '断捨離心理コンパニオン', desc: '片付け時に心理的サポートと意思決定アドバイスを提供' }
|
||||
],
|
||||
'food': [
|
||||
{ title: '一人飯癒しレシピ', desc: '一人暮らしの方にシンプルで癒される料理プランを設計' },
|
||||
{ title: 'イベント食卓雰囲気デザイン', desc: '特別な日に儀式感のある食卓コーディネートを設計' },
|
||||
{ title: '料理気分マッチング', desc: '今の気分に基づいて適した食べ物と作り方を推奨' },
|
||||
{ title: '料理初心者自信ビルダー', desc: 'ゼロベースの料理初心者に温かい励ましとシンプルなレシピを提供' },
|
||||
{ title: 'フードフォトグラフィー雰囲気ガイド', desc: '家庭料理でも魅力的な雰囲気写真に撮る方法をガイド' }
|
||||
],
|
||||
'fashion': [
|
||||
{ title: '今日のコーデ気分ボード', desc: '天気、シーン、気分に基づいてコーデインスピレーションを生成' },
|
||||
{ title: 'カプセルワードローブコーディネーター', desc: '限られたアイテムで無限のコーデの可能性を創造' },
|
||||
{ title: '個人スタイル探索の旅', desc: 'ユニークな個人スタイルの発見と確立をサポート' },
|
||||
{ title: '古着の新しい着こなしクリエイター', desc: '古い服に新しいコーデインスピレーションを提供' },
|
||||
{ title: '特別シーンスタイリングアドバイザー', desc: '重要なシーンに自信を持てるスタイリングをデザイン' }
|
||||
]
|
||||
}
|
||||
|
||||
// 事前定義の推薦ルートマッピングテーブル - 雰囲気と感覚に基づく
|
||||
const recommendationMap = {
|
||||
// 雰囲気: 癒し系
|
||||
'healing': {
|
||||
'relax': ['emotion', 'lifestyle', 'health', 'home'],
|
||||
'inspire': ['creative', 'growth', 'learning', 'entertainment'],
|
||||
'connect': ['relationship', 'social', 'pet', 'emotion'],
|
||||
'escape': ['travel', 'entertainment', 'creative', 'lifestyle']
|
||||
},
|
||||
// 雰囲気: 成長系
|
||||
'growth': {
|
||||
'relax': ['growth', 'learning', 'creative', 'health'],
|
||||
'inspire': ['career', 'learning', 'creative', 'growth'],
|
||||
'connect': ['social', 'relationship', 'career', 'learning'],
|
||||
'escape': ['travel', 'entertainment', 'creative', 'lifestyle']
|
||||
},
|
||||
// 雰囲気: ソーシャル系
|
||||
'social': {
|
||||
'relax': ['social', 'pet', 'food', 'home'],
|
||||
'inspire': ['social', 'creative', 'entertainment', 'travel'],
|
||||
'connect': ['relationship', 'social', 'pet', 'travel'],
|
||||
'escape': ['social', 'travel', 'entertainment', 'creative']
|
||||
},
|
||||
// 雰囲気: 探索系
|
||||
'explore': {
|
||||
'relax': ['travel', 'creative', 'lifestyle', 'food'],
|
||||
'inspire': ['travel', 'creative', 'learning', 'entertainment'],
|
||||
'connect': ['travel', 'social', 'relationship', 'pet'],
|
||||
'escape': ['travel', 'entertainment', 'creative', 'lifestyle']
|
||||
},
|
||||
// 雰囲気: 日常系
|
||||
'daily': {
|
||||
'relax': ['lifestyle', 'home', 'health', 'emotion'],
|
||||
'inspire': ['creative', 'food', 'fashion', 'home'],
|
||||
'connect': ['relationship', 'social', 'pet', 'lifestyle'],
|
||||
'escape': ['entertainment', 'creative', 'travel', 'lifestyle']
|
||||
}
|
||||
}
|
||||
|
||||
const vibeOptions = [
|
||||
{ label: '癒し系', value: 'healing', desc: '温かい、安らぎ、癒し' },
|
||||
{ label: '成長系', value: 'growth', desc: '進歩、ブレイクスルー、変容' },
|
||||
{ label: 'ソーシャル系', value: 'social', desc: 'つながり、シェア、インタラクション' },
|
||||
{ label: '探索系', value: 'explore', desc: '好奇心、冒険、発見' },
|
||||
{ label: '日常系', value: 'daily', desc: '日常、リアル、今この瞬間' }
|
||||
]
|
||||
|
||||
const feelingOptions = [
|
||||
{ label: 'リラックスしたい', value: 'relax', desc: 'ストレス解消、頭を空っぽに' },
|
||||
{ label: 'インスピレーションを得たい', value: 'inspire', desc: 'クリエイティブの刺激、気づき' },
|
||||
{ label: 'つながりが欲しい', value: 'connect', desc: '人とのつながり、感情の共鳴' },
|
||||
{ label: '現実から逃れたい', value: 'escape', desc: '現実逃避、没入体験' }
|
||||
]
|
||||
|
||||
const scenarios = [
|
||||
{ key: 'lifestyle', name: 'ライフスタイル', anchor: '#_1-ライフスタイル' },
|
||||
{ key: 'emotion', name: '感情コンパニオン', anchor: '#_2-感情コンパニオン' },
|
||||
{ key: 'entertainment', name: 'エンターテインメント', anchor: '#_3-エンターテインメント' },
|
||||
{ key: 'growth', name: '自己成長', anchor: '#_4-自己成長' },
|
||||
{ key: 'social', name: 'ソーシャルインタラクション', anchor: '#_5-ソーシャルインタラクション' },
|
||||
{ key: 'creative', name: 'クリエイティブ表現', anchor: '#_6-クリエイティブ表現' },
|
||||
{ key: 'travel', name: '旅行探索', anchor: '#_7-旅行探索' },
|
||||
{ key: 'health', name: '心身の健康', anchor: '#_8-心身の健康' },
|
||||
{ key: 'learning', name: '知識探索', anchor: '#_9-知識探索' },
|
||||
{ key: 'relationship', name: '関係マネジメント', anchor: '#_10-関係マネジメント' },
|
||||
{ key: 'pet', name: 'ペットコンパニオン', anchor: '#_11-ペットコンパニオン' },
|
||||
{ key: 'finance', name: '財務の健康', anchor: '#_12-財務の健康' },
|
||||
{ key: 'career', name: 'キャリア開発', anchor: '#_13-キャリア開発' },
|
||||
{ key: 'home', name: '居家空間', anchor: '#_14-居家空間' },
|
||||
{ key: 'food', name: 'グルメ料理', anchor: '#_15-グルメ料理' },
|
||||
{ key: 'fashion', name: 'ファッションスタイル', anchor: '#_16-ファッションスタイル' }
|
||||
]
|
||||
|
||||
// 推薦結果の計算 - トピックプールからランダムに抽出
|
||||
const recommendationTopics = computed(() => {
|
||||
if (!vibePoint.value || !feeling.value) return []
|
||||
|
||||
const keys = recommendationMap[vibePoint.value]?.[feeling.value] || []
|
||||
const topics = []
|
||||
|
||||
// 各推薦シーンから 1〜2 トピックをランダムに抽出
|
||||
keys.forEach(key => {
|
||||
const scenario = scenarios.find(item => item.key === key)
|
||||
const scenarioTopics = topicPool[key] || []
|
||||
|
||||
if (scenario && scenarioTopics.length > 0) {
|
||||
const count = Math.floor(Math.random() * 2) + 1
|
||||
const shuffled = [...scenarioTopics].sort(() => Math.random() - 0.5)
|
||||
const selected = shuffled.slice(0, Math.min(count, shuffled.length))
|
||||
|
||||
selected.forEach(topic => {
|
||||
topics.push({
|
||||
...topic,
|
||||
scenarioKey: key,
|
||||
scenarioName: scenario.name,
|
||||
scenarioAnchor: scenario.anchor
|
||||
})
|
||||
})
|
||||
}
|
||||
})
|
||||
|
||||
// ランダムソートして総数を制限
|
||||
return topics.sort(() => Math.random() - 0.5).slice(0, 8)
|
||||
})
|
||||
|
||||
// 現在の選択の説明を取得
|
||||
const currentSelection = computed(() => {
|
||||
const vibe = vibeOptions.find(i => i.value === vibePoint.value)
|
||||
const feel = feelingOptions.find(p => p.value === feeling.value)
|
||||
return {
|
||||
vibe: vibe?.label || '',
|
||||
feeling: feel?.label || ''
|
||||
}
|
||||
})
|
||||
|
||||
const scrollToAnchor = (anchor) => {
|
||||
setTimeout(() => {
|
||||
let element = document.querySelector(anchor)
|
||||
|
||||
if (!element) {
|
||||
const altAnchor = anchor.replace('#_', '#')
|
||||
element = document.querySelector(altAnchor)
|
||||
}
|
||||
|
||||
if (!element) {
|
||||
const anchorText = decodeURIComponent(anchor.replace('#', '').replace(/^_/, ''))
|
||||
const headings = document.querySelectorAll('h2, h3')
|
||||
|
||||
for (let heading of headings) {
|
||||
const headingText = heading.textContent.trim()
|
||||
const cleanHeading = headingText.replace(/^\d+\.\s*/, '')
|
||||
if (cleanHeading === anchorText || headingText.includes(anchorText)) {
|
||||
element = heading
|
||||
break
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (element) {
|
||||
element.scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
block: 'start'
|
||||
})
|
||||
element.style.backgroundColor = '#fdf2f8'
|
||||
element.style.transition = 'background-color 0.3s'
|
||||
element.style.padding = '8px'
|
||||
element.style.borderRadius = '4px'
|
||||
setTimeout(() => {
|
||||
element.style.backgroundColor = ''
|
||||
element.style.padding = ''
|
||||
}, 2000)
|
||||
}
|
||||
}, 100)
|
||||
}
|
||||
|
||||
const resetSelection = () => {
|
||||
vibePoint.value = ''
|
||||
feeling.value = ''
|
||||
}
|
||||
</script>
|
||||
|
||||
# C 誌消費シーンインスピレーションリファレンス
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['C 誌アプリ', 'ライフスタイル', '感情体験', '雰囲気演出']" coreOutput="15+ の生活シーンインスピレーションの発見" expectedOutput="ユーザーの心を打つプロダクト方向を見つける">
|
||||
|
||||
本文書は <strong>LLM 大規模モデルの C 誌消費シーンにおけるクリエイティブな応用方向</strong>をまとめています。B 誌が効率やペインポイントに関心を持つのとは異なり、C 誌プロダクトは<strong>感覚の演出、心理的暗示、雰囲気</strong>を重視し、ユーザーが使用プロセスで感情の共鳴と素晴らしい体験を得るようにします。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
## シーン雰囲気クイック選択
|
||||
|
||||
<el-card shadow="hover" style="margin-top: 16px; margin-bottom: 24px; border-left: 5px solid #ec4899;">
|
||||
<div style="font-weight: 600; margin-bottom: 8px;">あなたの心を打つシーンインスピレーションを見つける</div>
|
||||
<div style="color: #606266; font-size: 14px; line-height: 1.6; margin-bottom: 12px;">
|
||||
求める雰囲気と今の感覚を選択すると、システムが関連するシーン方向を推奨します。タグをクリックすると該当セクションにジャンプします。
|
||||
</div>
|
||||
<el-row :gutter="16">
|
||||
<el-col :span="12">
|
||||
<el-select v-model="vibePoint" placeholder="雰囲気タイプを選択" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in vibeOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value"
|
||||
>
|
||||
<div style="font-weight: 500;">{{ item.label }}</div>
|
||||
<div style="font-size: 12px; color: #909399;">{{ item.desc }}</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<el-select v-model="feeling" placeholder="今の感覚を選択" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in feelingOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value"
|
||||
>
|
||||
<div style="font-weight: 500;">{{ item.label }}</div>
|
||||
<div style="font-size: 12px; color: #909399;">{{ item.desc }}</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
<div v-if="recommendationTopics.length > 0" style="margin-top: 16px;">
|
||||
<div style="font-weight: 600; margin-bottom: 12px; color: #ec4899;">
|
||||
おすすめの {{ currentSelection.vibe }} × {{ currentSelection.feeling }} シーン：
|
||||
</div>
|
||||
<div style="display: flex; flex-wrap: wrap; gap: 8px;">
|
||||
<el-tag
|
||||
v-for="topic in recommendationTopics"
|
||||
:key="topic.title"
|
||||
type="danger"
|
||||
effect="light"
|
||||
style="cursor: pointer; margin-bottom: 4px;"
|
||||
@click="scrollToAnchor(topic.scenarioAnchor)"
|
||||
>
|
||||
{{ topic.title }}
|
||||
</el-tag>
|
||||
</div>
|
||||
<el-button type="text" size="small" @click="resetSelection" style="margin-top: 8px;">
|
||||
選び直す
|
||||
</el-button>
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
---
|
||||
|
||||
## 1. ライフスタイル
|
||||
|
||||
> 💡 **コアコンセプト**：平凡な日常に儀式感を与え、ディテールの中に美しさを創造
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 朝の儀式感アラームアシスタント | 天気 API、カレンダーデータを統合し、LLM がパーソナライズされた朝のプランを生成；スマートスピーカーでカスタム音楽を再生、スマート照明の段階的点灯 |
|
||||
| 2 | 一人暮らしの雰囲気クリエイター | スマートホームデバイス（照明、スピーカー、アロマディフューザー）に接続し、LLM が時間/気分に応じて自動的にパラメータ調整；ユーザーの好みを学習し継続的に最適化 |
|
||||
| 3 | 週末のおうちデート回復プランジェネレーター | 動画配信プラットフォーム API と連携して作品リストを取得し、ユーザーの視聴履歴の好みに基づいて映画＋グルメ＋コーディネートのコンボプランを生成 |
|
||||
| 4 | 就寝前の心の癒しラジオ | TTS 音声合成で優しい物語を生成、ホワイトノイズミックスアルゴリズム、スマート音量フェードアウト；睡眠データに基づいてコンテンツを調整 |
|
||||
| 5 | 暮らしの美学インスピレーションキャッチャー | 画像認識でユーザーの環境写真を分析し、LLM が美学提案を生成；Pinterest/Instagram スタイルのコンテンツ推奨 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 感情コンパニオン
|
||||
|
||||
> 💡 **コアコンセプト**：無条件の受容と寄り添い、感情の優しい器になる
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 深夜のツリー聞き手 | エンドツーエンド暗号化でプライバシーを確保、LLM 感情分析で感情を理解、長期記憶でユーザーのストーリーを保存、複数ターンの対話で継続的なサポート |
|
||||
| 2 | 失恋回復コンパニオン | 感情段階認識アルゴリズム、段階ごとに異なるサポート（吐露期→発散期→再構築期）；心理学ナレッジベース RAG 検索 |
|
||||
| 3 | 不安緩和呼吸コーチ | 生体センサーデータ入力（心拍数/呼吸）、リアルタイムで不安レベルをモニタリング；音声ガイドで呼吸リズム、漸進的筋弛緩法の指導 |
|
||||
| 4 | 自信再構築メンター | ポジティブ心理学対話フレームワーク、ユーザーの小さな達成を記録してフィードバック；認知再構築技術でネガティブな自己対話の変革をサポート |
|
||||
| 5 | 感情日記スマート分析 | 感情認識 NLP モデル、時系列分析で感情パターンを発見；感情グラフの可視化、予測的アラート |
|
||||
|
||||
---
|
||||
|
||||
## 3. エンターテインメント
|
||||
|
||||
> 💡 **コアコンセプト**：没入型体験の創造、エンターテインメントを心の居場所に
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 没入型マーダーミステリー DM | LLM がリアルタイムでストーリー分岐を生成、音声合成で NPC を演じ、プレイヤーの反応に応じて難易度とテンポを動的に調整；AR/VR シーンレンダリング |
|
||||
| 2 | オープンワールドゲームの魂の NPC | 長期記憶データベースがプレイヤーとのインタラクション履歴を保存、LLM がパーソナライズされた対話を生成；感情コンピューティングで NPC にリアルな感情反応を持たせる |
|
||||
| 3 | パーソナライズドポッドキャスト生成 | ユーザーの興味グラフに基づいて専用コンテンツを生成、TTS でユーザーの好きな声をクローン；リアルタイムインタラクションでリスナーの質問に回答 |
|
||||
| 4 | バーチャルコンサート盛り上げ役 | バーチャルアバターレンダリング、リアルタイムコメントインタラクション、バーチャルペンライト/応援アイテム；空間オーディオ技術でライブ感を演出 |
|
||||
| 5 | インタラクティブ小説共創パートナー | LLM がリアルタイムでストーリーを生成、ユーザーの選択が物語の行方に影響；マルチエンディング設計、キャラクター関係の動的発展 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 自己成長
|
||||
|
||||
> 💡 **コアコンセプト**：成長は苦行ではなく、楽しい自己発見の旅
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 個人の成長の証人 | タイムライン可視化で成長軌跡を表示、マイルストーンの自動マーク；「過去の私」vs「今の私」の比較表示 |
|
||||
| 2 | 習慣形成ゲーム化コーチ | ゲーム化メカニズム（経験値、レベル、バッジ）、ソーシャルランキング、AI コーチのキャラクター演じ（例：「冒険メンター」） |
|
||||
| 3 | スキル学習パートナーマッチング | 興味と学習目標に基づくマッチングアルゴリズム、学習グループコミュニティ、お互いのチェックインメカニズム |
|
||||
| 4 | 毎日の小さな幸せ発見者 | 画像認識で生活の中の素敵な瞬間を発見、感謝ジャーナルのガイド、毎週の素敵な瞬間の振り返り |
|
||||
| 5 | 人生シミュレーション体験器 | マルチブランチストーリーで異なる選択の結果をシミュレート、パラレル人生の比較；意思決定の結果の可視化表示 |
|
||||
|
||||
---
|
||||
|
||||
## 5. ソーシャルインタラクション
|
||||
|
||||
> 💡 **コアコンセプト**：ソーシャルを気軽で自然に、快適なつながりを見つける
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | アイスブレイクトピックジェネレーター | 場面と参加者に基づくスマートトピック推奨、リアルタイム会話分析で話題継続の提案；気まずい瞬間のフォローアップヒント |
|
||||
| 2 | SNS投稿文雰囲気クリエイター | 画像コンテンツ分析、LLM が複数スタイルの文案を生成（文芸/ユーモア/シリアス）；emoji とレイアウトのスマート推奨 |
|
||||
| 3 | デート雰囲気プランナー | 双方の興味に基づくデートプラン生成、レストラン/アクティビティ推奨、会話トピック提案；リアルタイム天気と交通情報 |
|
||||
| 4 | オンライン飲み会盛り上げ役 | オンラインゲームライブラリ、アイスブレイクアクティビティジェネレーター、トピックルーレット；バーチャル背景とフィルターで雰囲気を強化 |
|
||||
| 5 | ソーシャルエネルギー管理アシスタント | ソーシャル活動後のエネルギー消費評価、回復アドバイス（一人の時間のアクティビティ推奨）；ソーシャルカレンダーのスマートプランニング |
|
||||
|
||||
---
|
||||
|
||||
## 6. クリエイティブ表現
|
||||
|
||||
> 💡 **コアコンセプト**：誰にでも创造力がある、ただ目覚める必要があるだけ
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | インスピレーション枯渇応急キット | クロスドメイン連想アルゴリズム、ランダム刺激語生成、クリエイティブプロンプトライブラリ；マインドマップ式インスピレーション発散ツール |
|
||||
| 2 | 個人スタイル探索ガイド | 画像分析でユーザーの既存スタイルを識別、スタイルトレンド推奨、バーチャル試着/メイク；スタイル進化タイムライン |
|
||||
| 3 | 手帳＆日記美学アドバイザー | レイアウトテンプレート推奨、カラースキーム生成、装飾エレメント提案；手書き文字認識とコンテンツ美化 |
|
||||
| 4 | 写真構図雰囲気ガイド | シーン認識と構図アドバイス、フィルタースタイル推奨、レタッチパラメータのスマート調整；写真技法の学習パス |
|
||||
| 5 | 音楽気分マッチング | 音楽感情分析アルゴリズム、ユーザーの気分認識、パーソナライズドプレイリスト生成；音楽ストーリーと背景紹介 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 旅行探索
|
||||
|
||||
> 💡 **コアコンセプト**：旅行は景色を見るだけでなく、異なるライフスタイルを感じること
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 街歩き探索ガイド | 地元通コンテンツの集約、穴場スポット推奨、AR ナビゲーション；リアルタイム翻訳と音声ガイド |
|
||||
| 2 | 旅行気分日記生成 | 写真の自動分類と厳選、LLM が美しい旅行記を生成、位置情報マーク付きタイムライン；ワンクリックで旅行動画生成 |
|
||||
| 3 | 一人旅コンパニオンアシスタント | リアルタイム位置共有と安全リマインド、現地の緊急連絡先、AI ガイドの音声コンパニオン；一人旅コミュニティ交流 |
|
||||
| 4 | 目的地雰囲気プレビュー | VR/360° パノラマプレビュー、現地の音と香りのシミュレーション、文化背景紹介；バーチャル「試住」体験 |
|
||||
| 5 | 旅行写真雰囲気ガイド | ゴールデンアワー通知、構図補助線、現地名所撮影スポット推奨；後処理カラースタイル提案 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 心身の健康
|
||||
|
||||
> 💡 **コアコンセプト**：健康は目標ではなく、優しいセルフケア
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 運動モチベーション覚醒師 | ユーザーの状態に応じて運動タイプをスマート推奨、マイクロエクササイズ（5分）オプション、ゲーム化運動チャレンジ；ソーシャル運動チェックイン |
|
||||
| 2 | ヘルシー食インスピレーションキッチン | 冷蔵庫の食材認識、パーソナライズドレシピ推奨、栄養バランス分析；ステップバイステップの料理ガイド |
|
||||
| 3 | 睡眠の質向上雰囲気クリエイター | 睡眠モニタリングデータ分析、就寝前儀式生成、環境最適化提案（温度/湿度/照明）；スマートウェイクアップ |
|
||||
| 4 | ボディセンシングガイド | ボディスキャン瞑想ガイド、身体部位と感情の関連付け、心身接続エクササイズ；バイオフィードバック可視化 |
|
||||
| 5 | セルフケアリマインダー | 仕事の強度モニタリング、定期的な休憩リマインド、マイクロケアアクティビティ提案（水分補給/ストレッチ/深呼吸）；セルフケア記録 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 知識探索
|
||||
|
||||
> 💡 **コアコンセプト**：学習は終わりのない冒険、好奇心が最良の教師
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 知識探索ゲーム化ガイド | 知識ポイントマップ可視化、クリア形式の学習パス、アチーブメントバッジシステム；AI メンターのキャラクター演じ |
|
||||
| 2 | 語学学習シーンパートナー | LLM が異なるキャラクターを演じて会話、発音矯正、文化背景紹介；没入型シチュエーションシミュレーション |
|
||||
| 3 | 好奇心満足アシスタント | Wikipedia/ナレッジグラフ接続、複雑な概念のわかりやすい説明、関連知識推奨；好奇心記録 |
|
||||
| 4 | 読書ノートインスピレーション | 書籍内容分析、観点の抽出と関連付け、思考の角度の推奨；読書ノートテンプレートと美化 |
|
||||
| 5 | 知識共有雰囲気クリエイター | 知識カード自動生成、共有文案の最適化、ビジュアル美化；ソーシャル共有データフィードバック |
|
||||
|
||||
---
|
||||
|
||||
## 10. 関係マネジメント
|
||||
|
||||
> 💡 **コアコンセプト**：良い関係には心を込めたお手入れが必要、でも心を込めるのは複雑じゃなくていい
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 親密な関係コミュニケーションコーチ | 感情表現テンプレート生成、非暴力コミュニケーション技法指導、対立解決話術；関係健康度評価 |
|
||||
| 2 | 家族ケアリマインダー | 重要日付のリマインド（誕生日/記念日）、ケアの話術提案、家族アクティビティ推奨；家族アルバム生成 |
|
||||
| 3 | 友情維持雰囲気クリエイター | 友人とのインタラクション記録、共通話題推奨、遠隔集会企画；友情タイムラインと思い出生成 |
|
||||
| 4 | 告白＆サプライズプランナー | パーソナライズドサプライズプラン生成、ギフト推奨、ロマンチック話術提案；実行スケジュールとリマインド |
|
||||
| 5 | 対立緩和雰囲気ガイド | 感情冷却話術、相手の立場に立つ思考のガイド、和解ステップ提案；関係修復トラッキング |
|
||||
|
||||
---
|
||||
|
||||
## 11. ペットコンパニオン
|
||||
|
||||
> 💡 **コアコンセプト**：ペットは家族、彼らの寄り添いは記録し大切にする価値がある
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | ペット擬人化日記 | ペット行動分析、一人称日記生成、写真自動添付；ペットの「SNS」 |
|
||||
| 2 | ペット行動分析師 | ペット行動動画分析、健康アラート、トレーニング提案；品種特性ナレッジベース |
|
||||
| 3 | ペットとの時間企画 | ペットアクティビティ推奨、DIY おもちゃチュートリアル、ペットフレンドリースポット推奨；ペットソーシャルマッチング |
|
||||
| 4 | ペット記念ストーリー生成 | 写真と動画の厳選、タイムラインストーリー生成、音楽コーディネート；記念アルバム/動画の自動生成 |
|
||||
| 5 | 初心者ペット飼い主安心ガイド | 段階別ケアガイド、よくある質問への回答、緊急時の対応；初心者コミュニティサポート |
|
||||
|
||||
---
|
||||
|
||||
## 12. 財務の健康
|
||||
|
||||
> 💡 **コアコンセプト**：財務的自由は目標ではない、財務の健康こそが目標
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 消費感情覺察アシスタント | 消費記録分析、感情-消費関連分析、衝動買いアラート；代替的満足感の提案 |
|
||||
| 2 | 貯蓄目標ビジュアルモチベーション | 目標進捗の可視化、夢シーンレンダリング、マイルストーンのお祝い；貯蓄習慣形成ゲーム |
|
||||
| 3 | 資産管理知識カジュアル学習 | 断片的な知識プッシュ、シチュエーション型ケーススタディ、インタラクティブクイズ；知識テストと証明書 |
|
||||
| 4 | 財務不安緩和師 | 財務状況の健康評価、ストレスマネジメントスキル、小さなステップのアクションプラン；財務心理カウンセリング |
|
||||
| 5 | 少額投資体験ゲーム | バーチャル投資シミュレーション、リスク教育、投資ポートフォリオゲーム；リアル少額投資のガイド |
|
||||
|
||||
---
|
||||
|
||||
## 13. キャリア開発
|
||||
|
||||
> 💡 **コアコンセプト**：キャリアはレールではなく、探索できる荒野
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | キャリア迷いコンパニオン | キャリア興味診断、スキル棚卸し、業界情報推奨；キャリアメンターとの対話 |
|
||||
| 2 | 仕事の達成感覚醒師 | 業績記録、価値の抽出、達成の可視化；同僚/顧客からのポジティブフィードバック収集 |
|
||||
| 3 | 職場ソーシャル雰囲気アシスタント | 職場トピック推奨、ネットワーキングスキル、業界イベント推奨；LinkedIn コンテンツ最適化 |
|
||||
| 4 | 副業インスピレーション発掘器 | スキル-興味-市場ニーズのマッチング、副業事例集、スタートアップガイド；副業コミュニティ交流 |
|
||||
| 5 | 面接前自信加油站 | 模擬面接、よくある質問の準備、自信向上テクニック；身だしなみアドバイス |
|
||||
|
||||
---
|
||||
|
||||
## 14. 居家空間
|
||||
|
||||
> 💡 **コアコンセプト**：家は住む場所ではなく、心の居場所
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 居家空間雰囲気デザイナー | 空間写真分析、スタイル推奨、家具/インテリア推奨；AR プレビュー効果 |
|
||||
| 2 | 四季インテリアチェンジガイド | 季節テーマ推奨、収納とディスプレイの提案、イベントデコレーションプラン；買い物リスト生成 |
|
||||
| 3 | 小スペース空間マジック | 空間最適化アルゴリズム、多機能家具推奨、収納テクニック；視覚的広がりのテクニック |
|
||||
| 4 | 居家儀式感クリエイター | 日常儀式のデザイン（朝/夜/週末）、儀式実行リマインド；儀式効果フィードバック |
|
||||
| 5 | 断捨離心理コンパニオン | アイテムの感情価値評価、断捨離ステップガイド、心理的サポート；寄付/リサイクルルート推奨 |
|
||||
|
||||
---
|
||||
|
||||
## 15. グルメ料理
|
||||
|
||||
> 💡 **コアコンセプト**：食べ物は愛の言語、料理は愛を表現する方法
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 一人飯癒しレシピ | 冷蔵庫の食材認識、シンプルレシピ推奨、ステップバイステップガイド；一人飯の盛り付け美学 |
|
||||
| 2 | イベント食卓雰囲気デザイン | イベントテーマメニュー、食卓コーディネートプラン、雰囲気演出テクニック；ゲスト体験最適化 |
|
||||
| 3 | 料理気分マッチング | 気分-食べ物関連アルゴリズム、感情調整レシピ、コンフォートフード推奨；料理セラピーガイド |
|
||||
| 4 | 料理初心者自信ビルダー | 超シンプルレシピ、失敗挽回テクニック、自信構築の声かけ；段階的難易度アップ |
|
||||
| 5 | フードフォトグラフィー雰囲気ガイド | 料理の盛り付け提案、自然光の活用、撮影アングルのガイド；フィルターと後処理の提案 |
|
||||
|
||||
---
|
||||
|
||||
## 16. ファッションスタイル
|
||||
|
||||
> 💡 **コアコンセプト**：ファッションは自己表現、スタイルは内面の外在表現
|
||||
|
||||
| 番号 | アプリケーションシーン名 | アプリケーションシーン機能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 今日のコーデ気分ボード | 天気/シーン/気分の総合推奨、バーチャル試着、コーデインスピレーション；ワードローブ管理 |
|
||||
| 2 | カプセルワードローブコーディネーター | ワードローブ棚卸し、アイテム別コーデ組み合わせ、1着多コーデプラン；買い物アドバイス（空欄を補完） |
|
||||
| 3 | 個人スタイル探索の旅 | スタイルテスト、参考アイコン推奨、スタイル進化パス；自信構築 |
|
||||
| 4 | 古着の新しい着こなしクリエイター | 古着リメイクインスピレーション、新しいコーデ方法、アクセサリーのポイントテクニック；サステナブルファッションの理念 |
|
||||
| 5 | 特別シーンスタイリングアドバイザー | シーンのドレスコード読み解き、スタイリングプラン生成、メイク・ヘアアドバイス；全体スタイリングの調和 |
|
||||
|
||||
---
|
||||
|
||||
## C 誌プロダクトを設計するコアの心得
|
||||
|
||||
### 1. 「機能」から「感覚」へ
|
||||
|
||||
B 誌プロダクトは「この機能がどんな問題を解決できるか」に関心を持ち、C 誌プロダクトは「この機能がどんな感覚をもたらせるか」に関心を持ちます。
|
||||
|
||||
| B 誌の考え方 | C 誌の考え方 |
|
||||
|---------|---------|
|
||||
| 効率向上 | 好きなことにもっと時間を使える |
|
||||
| コスト削減 | 使うお金の価値を最大化 |
|
||||
| ペインポイント解決 | 素晴らしい体験の創造 |
|
||||
| 機能の充実 | 感覚が届いているか |
|
||||
|
||||
### 2. 雰囲気を演出する 3 つのレイヤー
|
||||
|
||||
**感覚レイヤー**：視覚、聴覚、触覚のデザイン
|
||||
- 温かい色調
|
||||
- リラックスできる音
|
||||
- スムーズなアニメーション
|
||||
|
||||
**感情レイヤー**：感情の共鳴とガイド
|
||||
- ユーザーの気持ちを理解する
|
||||
- 感情的サポートを提供する
|
||||
- ポジティブな感情を創造する
|
||||
|
||||
**意味レイヤー**：価値の共感と帰属感
|
||||
- ユーザーが理解されていると感じる
|
||||
- 帰属感を創造する
|
||||
- 行動に意味を与える
|
||||
|
||||
### 3. 心理的暗示の力
|
||||
|
||||
C 誌プロダクトの文案とデザインはすべて心理的暗示を伝えています：
|
||||
|
||||
- **ポジティブ暗示**：「あなたはもう十分頑張っています」「ゆっくりでいいんです」
|
||||
- **帰属暗示**：「あなたと同じ人がたくさんいます」「一人じゃないんです」
|
||||
- **成長暗示**：「毎回の試みは進歩です」「あなたはもっと良くなっています」
|
||||
|
||||
### 4. ユーザーをより良い自分にする
|
||||
|
||||
最高の C 誌プロダクトはユーザーを変えるものではなく、ユーザーがなりたい自分をサポートするものです。
|
||||
|
||||
- 「〜すべき」ではなく、「〜できます」
|
||||
- 「〜しなければ」ではなく、「〜したいなら」
|
||||
- 「まだ足りない」ではなく、「あなたはもう〜」
|
||||
|
||||
---
|
||||
|
||||
> 🌟 **覚えておいてください**：C 誌ユーザーが買っているのは機能ではなく、感覚です。ツールではなく、寄り添いです。サービスではなく、理解です。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,544 @@
|
||||
---
|
||||
title: 'ダブルダイヤモンドモデル：正しいことをして、正しくやる'
|
||||
description: 'ゼロベースの読者向け Double Diamond 入門記事。Discover、Define、Develop、Deliver の4つの段階を理解し、問題が明確になる前にプロトタイプを作り始めるのを防ぐ。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 時間</strong>'
|
||||
</script>
|
||||
|
||||
# ダブルダイヤモンドモデル：正しいことをして、正しくやる
|
||||
|
||||
<a id="top-dd"></a>
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['Double Diamond', 'デザイン思考', '要件分析', 'ソリューション設計']"
|
||||
coreOutput="より明確な問題定義と、より合理的な検証の切り口"
|
||||
expectedOutput="いきなりプロトタイプを作り始めるのではなく、まず問題を明確にしてからソリューションを比較できるようになる"
|
||||
>
|
||||
|
||||
多くの人が初めてプロダクトを作るとき、最も陥りやすい罠は「不够努力」ではなく、ソリューションに早く入りすぎることです。
|
||||
|
||||
頭の中に方向性が浮かんだ途端、ページのレイアウト、ボタンの配置、AIの統合の有無、ログイン登録の要否、プロトタイプのツール選びなどを考え始めます。色々と作業した後で、根本的な問題が全く考えられていなかったことに気づくのです：ユーザーに本当にそのペインポイントがあるのか？この問題に今取り組む価値があるのか？プロジェクトを前に進めているつもりで、実は間違った方向で一所懸命加速しているだけなのです。
|
||||
|
||||
ダブルダイヤモンドモデル（Double Diamond）は、まさにこの状況を防ぐためにあります。
|
||||
|
||||
このモデルが最も価値ある点は：**「正しいことをする」と「正しくやる」は、全く異なる2つの段階である**という提醒です。問題がまだ明確になっていないのに、急いでプロトタイプを作り始めると、通常は間違った方向をより完全に仕上げるだけです。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小SOP
|
||||
**目的**：読み終えた後、プロダクトを作るときにいつまず問題を考え、いつからソリューションやプロトタイプを考え始めればよいかがより明確になり、いきなり間違った方向で一所懸命作業するのを防げるようになります。
|
||||
|
||||
**アクションアイテム**：`Discover → Define → Develop → Deliver`の4つのステップに沿って進み、各ステップでその段階がやるべきことだけを行う。
|
||||
|
||||
**結果**：より明確な問題定義、複数の比較可能なソリューション、そして検証可能な最小バージョンを得られます。
|
||||
|
||||
**キーワードジャンプ**：[ダブルダイヤモンドモデルとは](#dd-what) · [最初のダイヤモンド](#dd-first) · [AIがどう役立つか](#dd-ai)
|
||||
:::
|
||||
|
||||
## 以下の内容を学びます
|
||||
|
||||
1. ダブルダイヤモンドモデルとは何か、なぜゼロベースのプロダクト作りに適しているのか
|
||||
2. Discover、Define、Develop、Deliver の4つの段階がそれぞれ何をしているのか
|
||||
3. 「今はまだ発散を続けるべき」か「今から収束を始めるべき」かをどう見分けるか
|
||||
4. ダブルダイヤモンドモデルをAIプロダクト、プロトタイプ設計、要件検証にどう活用するか
|
||||
|
||||
<a id="dd-what"></a>
|
||||
## [1. ダブルダイヤモンドモデルとは](#top-dd)
|
||||
|
||||
ダブルダイヤモンドモデルは、英国の**Design Council**が提唱した古典的なデザインプロセスフレームワークです。完全なデザイン・イノベーションプロセスを、2つの連続したダイヤモンド形で表します。
|
||||
|
||||
「ダイヤモンド」の形になっているのは、各ダイヤモンドが相反するがどちらも重要な2つのアクションを含んでいるからです：
|
||||
|
||||
- **発散**：まず視野を広げ、より多くの可能性を見る
|
||||
- **収束**：次に範囲を絞り、判断と取捨選択を行う
|
||||
|
||||
全プロセスは4つのステップからなります：
|
||||
|
||||
1. **Discover**：ユーザー、問題、環境、市場を広く理解する
|
||||
2. **Define**：大量の情報から、本当に解決すべき核心問題を抽出する
|
||||
3. **Develop**：核心問題を中心に複数のソリューションを発散させる
|
||||
4. **Deliver**：スクリーニング、プロトタイプ、テスト、そしてより適切なソリューションを納品する
|
||||
|
||||
この4つのステップを最も覚えやすい一言に圧縮すると：
|
||||
|
||||
- **最初のダイヤモンド**：まず何を解決すべきかを明確にする
|
||||
- **2つ目のダイヤモンド**：その問題をどう解決するかを決める
|
||||
|
||||
これはあなたが正確に表現した次の言葉と同じです：
|
||||
|
||||
- **最初のダイヤモンド：正しいことをする**
|
||||
- **2つ目のダイヤモンド：正しくやる**
|
||||
|
||||
## 2. なぜダブルダイヤモンドモデルは初心者に特に適しているのか
|
||||
|
||||
初心者がプロダクトを作るとき、最もよくあるリズムは次のようになります：
|
||||
|
||||
- アイデアを思いつく
|
||||
- この方向性がかっこいいと思う
|
||||
- すぐにプロトタイプを作り始める
|
||||
- 作っているうちに機能が増えていく
|
||||
- 最終的に自分が何を解決しているのか分からなくなる
|
||||
|
||||
ダブルダイヤモンドモデルの価値は、プロセスを複雑にすることではなく、**「問題を理解する」と「ソリューションを設計する」を切り離す**ことにあります。
|
||||
|
||||
これはシンプルに聞こえますが、実は非常に重要です。なぜなら、多くの失敗したプロダクトは、実行が不真面目だったのではなく：
|
||||
|
||||
- 間違った問題を選んだ
|
||||
- ユーザーを誤解した
|
||||
- ソリューションを早すぎるとロックした
|
||||
- 大量の時間を細部の磨き上げに費やし、方向性を検証しなかった
|
||||
|
||||
ダブルダイヤモンドモデルは常に次のように提醒します：
|
||||
|
||||
- 思いつきやすいからといって、問題が成立していると早とちりしない
|
||||
- ソリューションを作れるからといって、それが作る価値があるとは限らない
|
||||
- プロトタイプが完全に見えるからといって、ユーザーが本当に必要とするとは限らない
|
||||
|
||||
<a id="dd-first"></a>
|
||||
## [3. 最初のダイヤモンド：正しいことをする](#top-dd)
|
||||
|
||||
最初のダイヤモンドが焦点を当てるのは**問題そのもの**であり、ソリューションではありません。
|
||||
|
||||
一言で理解するなら：**まず急いで作るのではなく、本当にやる価値があるかどうかを明確にする。**
|
||||
|
||||
### 3.1 Discover：まず問題空間を広げる
|
||||
|
||||
Discover段階の核心的なタスクは、**広く調査することであり、早急に結論を出すことではありません。**
|
||||
|
||||
このステップで通常行うことには以下が含まれます：
|
||||
|
||||
- ユーザーが実際のシナリオでどう行動しているかを見る
|
||||
- 潜在ユーザーにインタビューし、最後に問題に遭遇したのがいつかを理解する
|
||||
- 現在どうやって代替手段で対処しているかを見る
|
||||
- 競合や代替ソリューションの対応方法を確認する
|
||||
- 市场、プロセス、制約、サプライチェーンの情報を収集する
|
||||
|
||||
多くの人はDiscoverを「資料をたくさん見ること」と誤解しがちです。実はもっと重要なのは：**情報とデータではなく、人とシナリオを理解することです。**
|
||||
|
||||
例えば「AIで議事録を整理するツール」を作りたい場合、Discover段階では以下に注目すべきです：
|
||||
|
||||
- ユーザーが会議後に最も苦痛に感じるのはどこか
|
||||
- 議事録か、整理か、それとも共有か
|
||||
- 現在は自分で書いているのか、インターンに頼んでいるのか、録音を聞き直しているのか、それとも整理していないのか
|
||||
- どの会議シナリオで議事録が最も必要で、どのシナリオでは不要なのか
|
||||
|
||||
このステップの最も重要な目標は答えを出すことではなく、**早すぎる段階で答えが分かったと思い込まないことです。**
|
||||
|
||||
### 3.2 Define：大量の情報から核心問題を抽出する
|
||||
|
||||
Discoverが視野を広げることだとすれば、Defineは収束を始めることです。
|
||||
|
||||
Define段階でやるべきことは、すべての観察を残すことではなく、次の問いに答えることです：
|
||||
|
||||
- 本当に最優先で解決すべき問題はどれか
|
||||
- どの問題が最も頻繁に発生し、最も痛みが強く、最も価値があるか
|
||||
- 第1版ではどのシナリオに絞るべきか
|
||||
|
||||
このステップの核心は、幅広いトピックを明確な問題定義に収束させることです。
|
||||
|
||||
例えば最初はこう言っていたかもしれません：
|
||||
|
||||
> 会議の効率を高めるAIツールを作りたい。
|
||||
|
||||
Define段階に到達すると、より良い表現は次のようになるかもしれません：
|
||||
|
||||
> プロジェクト型チームが30〜60分の協働会議を終えた後、10分以内にToDo、担当者、期限付きの議事録を出力できない問題を、まず解決する。
|
||||
|
||||
ここで問題が明確になり始めます：
|
||||
|
||||
- ユーザーは誰か
|
||||
- シナリオは何か
|
||||
- ボトルネックは何か
|
||||
- 成功基準は何か
|
||||
|
||||
Defineの本質は、**「問題がたくさんある」状態から「今回はどの問題を先に解決するか」への収束です。**
|
||||
|
||||
## 4. 2つ目のダイヤモンド：正しくやる
|
||||
|
||||
最初のダイヤモンドを完了して初めて、2つ目のダイヤモンドに進むのが適切です。なぜなら、この時点で解決しているのは曖昧な方向ではなく、収束された具体的な問題だからです。
|
||||
|
||||
### 4.1 Develop：核心問題を中心にソリューションを発散させる
|
||||
|
||||
Develop段階の重点は、**同じ問題に対して、複数の可能なソリューションを探索することです。**
|
||||
|
||||
なお、ここの発散はDiscover段階のものとは異なります：
|
||||
|
||||
- Discoverの発散は、問題空間を探索すること
|
||||
- Developの発散は、ソリューション空間を探索すること
|
||||
|
||||
議事録の例で言えば、Develop段階では以下のことを考え始めることができます：
|
||||
|
||||
- Webツールにするのか、会議プラグインにするのか
|
||||
- 録音をアップロードしてから処理するのか、リアルタイムで記録するのか
|
||||
- 要約だけにするのか、ToDo抽出をメインにするのか
|
||||
- 個人効率を強調するのか、チーム共有を強調するのか
|
||||
- ユーザーに自由に編集させるのか、構造化テンプレートとして直接出力するのか
|
||||
|
||||
このステップはブレインストーミングに適しており、チームと一緒にソリューションを広げるのにも適しています。
|
||||
|
||||
ただし、ここには一つの前提があります：**すべてのソリューションは、定義済みの同じ問題にサービスする必要があります。**
|
||||
問題が明確に定義されていないと、Developは再び機能の乱れに戻ってしまいます。
|
||||
|
||||
### 4.2 Deliver：ソリューションの選択、プロトタイプ、テスト、納品
|
||||
|
||||
Deliver段階は2つ目のダイヤモンドの収束段階です。
|
||||
|
||||
このときやるべきことは、さらに多くのアイデアを考えることではなく、判断を始めることです：
|
||||
|
||||
- 現在の段階に最も適したソリューションはどれか
|
||||
- 最小で最も有用なバージョンはどれか
|
||||
- どの機能を先に作る必要があり、どれは後回しでいいか
|
||||
- プロトタイプ、テスト、小規模検証をどう進めるか
|
||||
|
||||
多くの人はDeliver＝「公開」と誤解しがちです。実際のより正確な意味は：**ソリューションをテスト可能、検証可能、反復可能なものに変えることです。**
|
||||
|
||||
それは次のようなものかもしれません：
|
||||
|
||||
- 低 fidelity のフロー図
|
||||
- Figma プロトタイプ
|
||||
- 動作するMVP
|
||||
- 小規模なユーザーテスト
|
||||
- 実際のフィードバック後の反復バージョン
|
||||
|
||||
Deliverのポイントは「完璧な納品」ではなく、**できるだけ早くソリューションを実際の環境で検証することです。**
|
||||
|
||||
## 5. 最も覚えやすい比較表
|
||||
|
||||
4つの段階がいつも混同されるなら、以下のバージョンを直接覚えてください：
|
||||
|
||||
| 段階 | 何をしているか | キーワード | 一般的な成果物 |
|
||||
| --- | --- | --- | --- |
|
||||
| Discover | 問題を理解する | 調査、観察、インタビュー、情報収集 | ユーザーインサイト、シナリオノート、問題リスト |
|
||||
| Define | 問題を定義する | 抽出、焦点、取捨選択、問題の書き直し | 問題定義、優先順位、MVPの切り口 |
|
||||
| Develop | ソリューションを探索する | ブレインストーミング、比較、共創、プロトタイプの構想 | ソリューションリスト、フローのラフスケッチ、プロトタイプの方向性 |
|
||||
| Deliver | ソリューションを検証する | プロトタイプ、テスト、反復、納品 | プロトタイプ、テストフィードバック、最適化バージョン |
|
||||
|
||||
さらに圧縮すると：
|
||||
|
||||
- **Discover / Define**：「正しいことをする」を解決する
|
||||
- **Develop / Deliver**：「正しくやる」を解決する
|
||||
|
||||
## 6. ダブルダイヤモンドモデルの最もよくある誤解
|
||||
|
||||
### 6.1 Discover前にいきなりDeliver
|
||||
|
||||
これが最もよくあるパターンです。アイデアを思いついた瞬間にプロトタイプを書き始め、PRDを書き、モデルを統合し、ページを作る。
|
||||
|
||||
問題は真面目にやっていないのではなく、問題が解決する価値があるかどうかをまだ確認していない可能性があることです。
|
||||
|
||||
### 6.2 Discoverを長くやりすぎて、Defineに入らない
|
||||
|
||||
もう一つの極端な例は、ずっと調査し、ずっと資料を見続け、ずっとインタビューしているのに、収束するのを恐れることです。
|
||||
|
||||
ダブルダイヤモンドは無限の発散を促すものではなく、発散の後には必ず判断と取捨選択に入る必要があることを提醒します。
|
||||
|
||||
### 6.3 Defineの後、こっそり問題を変える
|
||||
|
||||
多くのチームはDevelop段階で、あるソリューションが作りやすいからといって、逆に問題定義を変更して既存のソリューションに適合させようとします。
|
||||
|
||||
これは非常に危険です。なぜなら、問題を解決しているのではなく、自分の好きなソリューションに理由を見つけているだけかもしれないからです。
|
||||
|
||||
### 6.4 Deliverを「すべて盛りで公開」と誤解する
|
||||
|
||||
Deliverは完全なプロダクトをすべて作り終えて初めて終わりという意味ではありません。多くの場合、テスト可能なプロトタイプ、1回の実際のユーザートライアルが、すでに良いdeliverです。
|
||||
|
||||
## 7. AIプロダクトで、ダブルダイヤモンドモデルをどう使うか
|
||||
|
||||
AIプロダクトは特に「能力先行」の罠に陥りやすいです。なぜならモデルの能力があまりにも魅力的に見えるからです。以下のことを考え始めたくなります：
|
||||
|
||||
- マルチモーダルを統合するかどうか
|
||||
- Agentにするかどうか
|
||||
- ワークフローを追加するかどうか
|
||||
- 音声、画像、インターネット検索を統合するかどうか
|
||||
|
||||
しかし、ダブルダイヤモンドモデルはまず以下の問いを強制します：
|
||||
|
||||
- ユーザーはどのステップで本当に詰まっているのか
|
||||
- このボトルネックは本当にAIでなければ解決できないのか
|
||||
- AIを使わない場合、既存の方法はどこが最も悪いのか
|
||||
- AIを加えた後、最も核心的な進展は何か
|
||||
|
||||
これはよくある状況を回避するのに役立ちます：**能力は強いが、価値は弱い。**
|
||||
|
||||
実用的な順序は次の通りです：
|
||||
|
||||
1. Discover段階でユーザーが現在タスクをどう処理しているかを観察する
|
||||
2. Define段階で最も痛みの強いシナリオを一文の明確な問題定義にする
|
||||
3. Develop段階でどのAI能力がこの問題に最も適しているかを比較する
|
||||
4. Deliver段階で最小バージョンを作り、実際のユーザーにテストしてもらう
|
||||
|
||||
## 8. そのまま使えるダブルダイヤモンドテンプレート
|
||||
|
||||
自分のプロダクトを作っている場合は、まずこの順序に従って書いてみてください：
|
||||
|
||||
### Discover
|
||||
|
||||
- 観察したユーザーは誰ですか？
|
||||
- そのユーザーが最後にこの問題に遭遇したのはいつですか？
|
||||
- 現在どうやって解決していますか？
|
||||
- 最も煩わしい、最も遅い、最も不安な部分はどこですか？
|
||||
|
||||
### Define
|
||||
|
||||
- この山積みの問題の中で、最も優先して解決すべきものはどれですか？
|
||||
- どのシナリオが最も頻度が高い、または最も重要ですか？
|
||||
- 第1版ではまず誰にサービスし、何だけを解決しますか？
|
||||
- 問題が解決された後、ユーザーの状態はどう変わりますか？
|
||||
|
||||
### Develop
|
||||
|
||||
- この問題に対して、どのような可能なソリューションがありますか？
|
||||
- どのソリューションが最も軽く、最も速く、最も検証しやすいですか？
|
||||
- 何を必ずやる必要があり、何は後回しにできますか？
|
||||
|
||||
### Deliver
|
||||
|
||||
- この方向を検証するために、最小で何を納品できますか？
|
||||
- フロー図、プロトタイプ、それともMVPですか？
|
||||
- 誰にテストを依頼しますか？
|
||||
- テスト後、継続、修正、中止をどう判断しますか？
|
||||
|
||||
## 9. ゼロベースでも理解できる例
|
||||
|
||||
「大学生の就職活動用レジュメ作成を支援する」AIツールを作りたいと仮定します。
|
||||
|
||||
多くの人は最初から2つ目のダイヤモンドに入り、次のことを考え始めます：
|
||||
|
||||
- ワンクリックで美しくするかどうか
|
||||
- AIで書き直すかどうか
|
||||
- JDと自動マッチングするかどうか
|
||||
- 自己紹介を生成するかどうか
|
||||
|
||||
しかし、ダブルダイヤモンドモデルに従えば、より良いプロセスは次のようになります：
|
||||
|
||||
### 最初のダイヤモンド
|
||||
|
||||
**Discover**
|
||||
|
||||
- 新卒学生が最後にレジュメを修正したのがいつかを聞きに行く
|
||||
- 古いレジュメをどうやって新しいバージョンに変えたかを見る
|
||||
- 最も苦痛なのが「書き方が分からない」「修正の仕方が分からない」なのか、「良し悪しの判断ができない」なのかを理解する
|
||||
|
||||
**Define**
|
||||
|
||||
- 最終的により具体的な問題に収束する：
|
||||
- 「大学生がレジュメを作れない」ではなく
|
||||
- 「初めてインターンに応募する学生が、既存の経験をポジションに合った表現に書き直せず、応募を先延ばしにしている」
|
||||
|
||||
### 2つ目のダイヤモンド
|
||||
|
||||
**Develop**
|
||||
|
||||
- いくつかのソリューションを考える：テンプレートライブラリ、AI書き直し、ポジション比較、レジュメスコアリング、ケース参考
|
||||
|
||||
**Deliver**
|
||||
|
||||
- 第1版は「ポジション記述に基づいて経験のbullet pointsを書き直す」機能のみ
|
||||
- 5人の学生に試用してもらい、最初の版のレジュメをより早く提出できるかどうかを確認する
|
||||
|
||||
最初のダイヤモンドをしっかりやれば、2つ目のダイヤモンドはずっと明確になることが分かるでしょう。
|
||||
|
||||
## 10. まとめ
|
||||
|
||||
ダブルダイヤモンドモデルが最も力を発揮するのは、全体のごちゃ混ぜ状態を4つのより明確なアクションに分解することです：
|
||||
|
||||
- まず発散して問題を理解する
|
||||
- その後収束して問題を定義する
|
||||
- 再び発散してソリューションを探索する
|
||||
- 最後に収束してソリューションを納品する
|
||||
|
||||
これはあなたを遅くするのではなく、**忙しく見えて実は方向が間違っている遠回りを大幅に減らしてくれます。**
|
||||
|
||||
特にAI時代において、ものを作るスピードがますます速くなる中、ダブルダイヤモンドモデルは逆に重要になります。なぜなら「作る」ことがますます簡単になると、本当に希少な能力は次のようになるからです：**あなたが解決する価値のある問題を解決しているか、そして適切な方法でそれを解決しているかどうか。**
|
||||
|
||||
この一言を覚えておけば十分です：
|
||||
|
||||
**まず正しいことをして、その後正しくやる。**
|
||||
|
||||
<a id="dd-ai"></a>
|
||||
## [11. AIを使ってダブルダイヤモンドプロセスを進める方法](#top-dd)
|
||||
|
||||
ダブルダイヤモンドモデル自体はAIツールではありませんが、AIは4つの段階で「アクセラレーター」として非常に適しています。重要なのは、AIに意思決定を任せるのではなく、視野の拡大、情報の整理、ソリューションの比較、検証資料の生成を支援させることです。
|
||||
|
||||
### 11.1 Discover段階で、AIを使ってまず情報の基盤を作る
|
||||
|
||||
正式なインタビューや調査の前に、AIに軽量な問題スキャンをさせると良いでしょう：
|
||||
|
||||
- 市場にある一般的な代替ソリューションは何か
|
||||
- ユーザーが公開コミュニティで最もよく不満を言っているのは何か
|
||||
- この問題はどのようなシナリオとユーザー層に多いか
|
||||
- 既存のプロダクトが通常見落としているのは何か
|
||||
|
||||
このステップは実際の調査に代わるものではありませんが、問題マップを素早く構築するのに非常に適しています。
|
||||
|
||||
シンプルな初心者入力は次のようなものです：
|
||||
|
||||
```text
|
||||
大学生のレジュメ添削を支援するツールを作りたい。
|
||||
まず機能を考える前に、この問題で皆が最もよく遭遇するトラブルを見てほしい。
|
||||
```
|
||||
|
||||
AIは次のような出力をするかもしれません：
|
||||
|
||||
```text
|
||||
初期問題マップ：
|
||||
|
||||
1. どんな経験を書けばいいか分からない
|
||||
2. ポジションに合わせてどう修正すればいいか分からない
|
||||
3. 何度修正しても十分良いかどうか確信が持てない
|
||||
4. 誰かに見てもらいたいが、毎回頼むのは気が引ける
|
||||
5. 確信がないため、提出を先延ばしにしてしまう
|
||||
```
|
||||
|
||||
この出力の目的は、あなたに代わって結論を出すことではなく、Discoverにより早く入るためのものです。
|
||||
|
||||
### 11.2 Define段階で、AIに問題定義の収束を支援させる
|
||||
|
||||
多くの人は資料をたくさん集めた後、問題を本当に明確な一文に圧縮するのが最も難しいと感じます。調査ノートをAIに渡して、複数の候補問題定義に圧縮してもらうことができます：
|
||||
|
||||
```text
|
||||
以下はDiscover段階で収集したユーザーフィードバックと調査ノートです：
|
||||
[内容を貼り付ける]
|
||||
|
||||
次の3つのことをしてください：
|
||||
1. 最も頻繁に出現する問題パターンを分類・整理する
|
||||
2. 問題の頻度、痛みの強さ、検証可能性に基づいて、優先的に解決すべき3つの問題を整理する
|
||||
3. 各問題を具体的な問題定義の一文に書く
|
||||
```
|
||||
|
||||
これにより、Defineによりスムーズに入れるようになります。「問題がたくさんある」状態に留まり続けることがなくなります。
|
||||
|
||||
入力を非常にシンプルに書くこともできます：
|
||||
|
||||
```text
|
||||
現在収集した問題は以下の通りです：
|
||||
1. 皆はレジュメに何を書けばいいか分からない
|
||||
2. 皆はどう修正すればいいか分からない
|
||||
3. 皆はいつもまだ十分に修正できていないと感じ、提出をためらう
|
||||
|
||||
第1版ではどの問題を先に解決するのが最も適切か見てほしい。
|
||||
```
|
||||
|
||||
AIは次のような出力をするかもしれません：
|
||||
|
||||
```text
|
||||
優先的に解決すべき問題：
|
||||
|
||||
「初めてインターンに応募する学生が、レジュメが提出可能なレベルに達しているか確信が持てず、何度も修正を繰り返して提出を先延ばしにしている。」
|
||||
|
||||
理由：
|
||||
1. この問題はより具体的である
|
||||
2. 先延ばし行動を説明できる
|
||||
3. 小さなバージョンで検証しやすい
|
||||
```
|
||||
|
||||
このような出力は非常に有用です。なぜなら、曖昧な問題の山からMVPの出発点により近い定義へと収束させてくれるからです。
|
||||
|
||||
### 11.3 Develop段階で、AIに複数のソリューションを発散させる
|
||||
|
||||
問題を定義した直後、頭に浮かんだ最初のソリューションだけに固執しがちです。AIはこのステップで強制的に発散させるのに非常に適しています：
|
||||
|
||||
```text
|
||||
私はすでに核心問題を定義しました：[あなたの問題定義]
|
||||
最終的な回答を直接出すのではなく、以下の角度からそれぞれ2〜3種類の解決方向を提案してください：
|
||||
1. 最も軽量なMVP
|
||||
2. ニーズ検証に最も適したソリューション
|
||||
3. 体験向上に最も適したソリューション
|
||||
4. AIに依存しないソリューション
|
||||
5. AIに依存するソリューション
|
||||
最後に各ソリューションのメリット、リスク、検証コストを比較してください。
|
||||
```
|
||||
|
||||
これにより、一つのソリューションに早すぎる段階で縛られなくなります。
|
||||
|
||||
シンプルな入力は次のように書けます：
|
||||
|
||||
```text
|
||||
私の現在の問題定義は：
|
||||
「大学生はレジュメが提出可能かどうか確信が持てず、ずっと先延ばしにしている。」
|
||||
|
||||
4つの異なるソリューションを考えてほしい、1つだけでいいのにしないでほしい。
|
||||
```
|
||||
|
||||
AIは次のような出力をするかもしれません：
|
||||
|
||||
```text
|
||||
ソリューション1：レジュメ提出チェックリスト
|
||||
ソリューション2：ポジション記述に基づく针对性のある書き直し
|
||||
ソリューション3：ユーザーがレジュメをアップロードした後にリスク警告を提示
|
||||
ソリューション4：優秀なケースとの照合を提供し、ユーザーがギャップを判断できるようにする
|
||||
```
|
||||
|
||||
これにより、「ソリューションの比較」に入りやすくなり、最初からAI書き直しという一つの方向だけに固執しなくなります。
|
||||
|
||||
### 11.4 Deliver段階で、AIにプロトタイプのテキストとテスト資料の生成を支援させる
|
||||
|
||||
Deliver段階に入ると、AIは次の作業を加速するのに非常に適しています：
|
||||
|
||||
- 低 fidelity プロトタイプのページテキストの生成
|
||||
- ユーザーテストスクリプトの整理
|
||||
- 比較可能な複数バージョンのタイトル、ボタン、説明文の生成
|
||||
- テスト後のフィードバックと問題リストの整理
|
||||
|
||||
例えば、AIに20分間のユーザーテストスクリプトを生成させたり、5人のユーザーフィードバックを「継続／方向修正／一時停止」の判断基準に整理させたりすることができます。
|
||||
|
||||
例えば、最もシンプルな入力は次のように書けます：
|
||||
|
||||
```text
|
||||
非常にシンプルなプロトタイプを作った：
|
||||
ユーザーがレジュメをアップロードすると、システムがどこがまだ提出に適していないかを教える。
|
||||
|
||||
15分間のユーザーテストスクリプトを生成してほしい。
|
||||
```
|
||||
|
||||
AIは次のような出力をするかもしれません：
|
||||
|
||||
```text
|
||||
15分間テストスクリプト：
|
||||
|
||||
1. まずユーザーに最近のレジュメ提出経験を説明してもらう
|
||||
2. ユーザーに自力でレジュメのアップロードを完了してもらう
|
||||
3. フィードバック結果を理解できるか観察する
|
||||
4. 質問する：これらのヒントのうち、どれが最も役立ち、どれが混乱を招いたか
|
||||
5. 質問する：次回提出前に、もう一度使いたいと思うか
|
||||
```
|
||||
|
||||
このような出力は非常に実用的です。なぜなら、「プロトタイプが完成した」から「次にどうテストするか」まで導いてくれるからです。
|
||||
|
||||
### 11.5 AIに「段階ゲートキーパー」を演じさせる
|
||||
|
||||
ダブルダイヤモンドモデルで最もよくある問題は、ステップを飛ばすことです。AIに直接ゲートキーパーを務めさせ、今がどのステップにいるのかをリマインドさせることができます：
|
||||
|
||||
```text
|
||||
あなたはプロダクトプロセスコーチとして行動してください。
|
||||
以下は私の現在のプロジェクトの状態です：[あなたの説明]
|
||||
私が現在Discover、Define、Develop、Deliverのどれにいるかを判断してください。
|
||||
そして以下を教えてください：
|
||||
1. 早すぎる次の段階へのジャンプをしていないか
|
||||
2. 現在の段階で最も補うべきアクションは何か
|
||||
3. 今はまだやるべきでないことは何か
|
||||
```
|
||||
|
||||
これは初心者にとって特に役立ちます。なぜなら、「問題がまだ明確になっていないのにプロトタイプを作り始める」ことが非常に起こりやすいからです。
|
||||
|
||||
## 📚 課題
|
||||
|
||||
上記の内容に基づいて、次の課題を完了してください：
|
||||
|
||||
1. 最近作りたいプロダクトのアイデアを1つ選び、Discover、Define、Develop、Deliverの4ステップのドラフトを書く
|
||||
2. Define段階で、問題を強制的に一文に圧縮する
|
||||
3. Develop段階で、少なくとも3種類の異なるソリューションをリストアップし、最初に思いついた方法だけに固執しない
|
||||
4. Deliver段階で、1週間以内に納品可能な最小検証バージョンを書き出す
|
||||
|
||||
## 参考文献
|
||||
|
||||
この記事は主にDesign CouncilのDouble Diamondに関する公式資料を参照しており、さらに深く読むのに適しています：
|
||||
|
||||
- [Design Council: The Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)
|
||||
- [Design Council: Framework for Innovation](https://www.designcouncil.org.uk/our-work/skills-learning/tools-frameworks/framework-for-innovation-design-councils-evolved-double-diamond/)
|
||||
- [Design Council: History of the Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/history-of-the-double-diamond/)
|
||||
@@ -0,0 +1,301 @@
|
||||
---
|
||||
title: 'アイデアの見つけ方：初心者に最も適した3つの参考ソース'
|
||||
description: 'ゼロベースの読者向けのプロダクトアイデア入門記事。アイデアを直接閲覧できるサイト、トレンドソース、実際のビジネスソース、VCリストを重点的に整理し、リンクからより具体的な方向性を素早く見つけられるようにする。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 時間</strong>'
|
||||
</script>
|
||||
|
||||
# アイデアの見つけ方：初心者に最も適した3つの参考ソース
|
||||
|
||||
<a id="top-idea-sources"></a>
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['アイデアの発見', 'プロダクトの方向性', 'ニーズの発見', '業界観察']"
|
||||
coreOutput="より具体的で、引き続き調査する価値のあるプロダクト方向性を1つ"
|
||||
expectedOutput="どこを見ればいいか、どう見ればいいか、何を先に見るべきかが分かり、「AI + 某業界」のような空虚なアイデアで終わらなくなる"
|
||||
>
|
||||
|
||||
多くの人が最初のステップで行き詰まります。それはインスピレーションが全くないからではなく、たくさんのコンテンツを見た後でも、頭の中に残るのが抽象的なキーワードだけだからです：
|
||||
|
||||
- AI for education
|
||||
- AI for healthcare
|
||||
- AI for finance
|
||||
- AI agent for business
|
||||
|
||||
これらはまだアイデアではありません。それらは「方向性が大きい」ことを伝えているだけで、以下を伝えていません：
|
||||
|
||||
- 誰が使うのか
|
||||
- どんなシナリオで使うのか
|
||||
- 現在どうやって間に合わせているのか
|
||||
- どのステップを最初に切り込むのが最も価値があるのか
|
||||
|
||||
この記事は空虚な方法論を語らず、より使いやすいソースを直接整理して提供します。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小SOP
|
||||
**目的**：読み終えた後、アイデアがないときにどこをまず見ればいいか、どのリンクが「具体的なニーズ」を見るのに適しているか、どれが「トレンド」を見るのに適しているか、どれが「実際のビジネス」を見るのに適しているかが分かるようになります。
|
||||
|
||||
**アクションアイテム**：まずアイデアリストを一巡し、次に稼ぐ小さなプロダクトを一巡し、次にトレンドとよりビジネス的なソースを見て、最後に引き続き調査したい方向性を1つ残す。
|
||||
|
||||
**結果**：抽象的なキーワードで止まらず、より具体的で検証する価値のある方向性を1つ得られます。
|
||||
|
||||
**キーワードジャンプ**：[参考アプリリスト](#idea-apps) · [トレンドソース](#idea-trends) · [よりビジネス的なソース](#idea-business) · [VC / アクセラレーター ソース](#idea-vc) · [最短パス](#idea-path) · [AIがどう役立つか](#idea-ai)
|
||||
:::
|
||||
|
||||
## 以下の内容を学びます
|
||||
|
||||
1. どのサイトがアイデアを直接閲覧するのに適しているか
|
||||
2. どのサイトがすでに稼いでいる小さなプロダクトを見るのに適しているか
|
||||
3. どのソースがトレンドと業界の変化を見るのに適しているか
|
||||
4. どのソースが実際のビジネスと実際の支払いに近いか
|
||||
5. ゼロベースに最も適した最短使用パス
|
||||
|
||||
<a id="idea-apps"></a>
|
||||
## [1. 参考アプリリスト：まず他の人がすでに何をしているかを見る](#top-idea-sources)
|
||||
|
||||
これは初心者に最も適したスタート地点です。最も具体的だからです。
|
||||
|
||||
### 第一グループ：開けばアイデアリスト、直接選べる
|
||||
|
||||
- [Reddit — r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
このsubredditの核心的な用途は：実際のユーザーが直接「誰かXXを作ってくれないか」と投稿することです。各投稿は通常、具体的なプロダクトニーズであり、少しのシナリオ説明も付いています。`Top -> Past Month`または`Top -> Past Year`で並べ替えて、20分で実際のニーズを多数スキャンできます。
|
||||
- [Reddit — r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
|
||||
上記と似ていますが、よりソフトウェア/Appに焦点を当てています。投稿の一般的なフォーマットは「XXができるアプリが必要」で、粒度が小さく、小さくて美しいニッチなものが多いです。
|
||||
- [Reddit — r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
|
||||
最初の2つより完全です。多くの投稿は単なる一文のニーズではなく、市場分析、ビジネスモデル、なぜ今やる価値があるのかも含まれています。
|
||||
- [Unvalidated Ideas](https://unvalidatedideas.com/)
|
||||
毎週未検証のスタートアップアイデアを公開し、一般的なフィールドにはターゲットユーザー、マネタイズ方法、初期検証のアイデアが含まれます。フォーマットが統一されており、クイックスキャンに適しています。
|
||||
- [IdeasAI](https://ideasai.com/)
|
||||
AIでスタートアップアイデアを生成し、ずっとスクロールできます。品質は安定していませんが、「全くインスピレーションがない」ときに刺激を得るのに適しており、自分で細分化シナリオに掘り下げられます。
|
||||
|
||||
### 第二グループ：他の人がすでに稼いでいる小さなプロダクトを見て、アイデアを逆推する
|
||||
|
||||
これらのプラットフォームの論理は：他の人がすでにニーズを検証し、収益を上げていることです。それらを見るのは、コピーするためではなく、「どのような小さな問題に支払う人がいるか」を見るためです。
|
||||
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
多くの実際の小さなビジネスケースを掲載しており、通常は創業者インタビュー、収益データ、スタートプロセスが含まれます。月収1万〜10万ドルの小さなプロダクトに注目すると、よりニッチで、一般の人が理解できるプロダクト規模に近いです。
|
||||
- [Indie Hackers — Products](https://www.indiehackers.com/products)
|
||||
インディー開発者がプロダクトを展示する場所で、多くは収益と成長を公開しています。収益順に並べ替えて、月数千〜数万ドルのプロダクトがどのような具体的な問題を解決しているかを見てください。
|
||||
- [MicroConf Blog](https://microconf.com/blog)
|
||||
Micro SaaSに焦点を当てています。「十分に小さいが、支払う人がいる」プロダクトの切り口を見るのに適しています。
|
||||
- [1000 Tools](https://1000.tools/)
|
||||
AIツールアグリゲーションサイト。どのカテゴリーにすでに参入者がいるが、品質が一般的なもの、または国内/ある垂直業界でまだ十分にカバーされていない方向性を見るのに適しています。
|
||||
- [Product Hunt](https://www.producthunt.com/)
|
||||
最近繰り返し現れるプロダクトタイプを見て、一位だけを見るのではなく、どのカテゴリーに継続的に参入しているが、まだ明確な勝者がいないかに注目してください。
|
||||
- [BetaList](https://betalist.com/)
|
||||
初期プロダクトや、まだ方向性を試しているチームを見るのに適しています。
|
||||
|
||||
### プロダクトを見るときは、プロダクト自体だけでなく、低評価や「代行サービス」も見る
|
||||
|
||||
- [G2](https://www.g2.com/)
|
||||
使い方：1つ星、2つ星の評価を見る。低評価には通常「既存のプロダクトのどの部分がうまくいっていないか」が隠されています。
|
||||
- [Capterra](https://www.capterra.com/)
|
||||
使い方：G2と同様に、SaaS系プロダクトの実際の不満を見るのに適しています。
|
||||
- タオバオ / 閑魚 / [Fiverr](https://www.fiverr.com/) / [Upwork](https://www.upwork.com/) / 猪八戒
|
||||
使い方：「代行」「代整理」「代入力」「代転記」「代書き起こし」で検索。ある人工サービスがよく売れているなら、その背後には通常、再現可能でプロダクト化できるプロセスがあります。
|
||||
|
||||
シグナルの判断は非常にシンプルです：
|
||||
|
||||
- ユーザーがすでに既存のツールに不満を持っている
|
||||
- ユーザーがすでにお金を払って人にやらせている
|
||||
- ユーザーがすでにこのプロセスに多くの人力と時間を投入している
|
||||
|
||||
### 第四グループ：動画を見る、誰かが直接アイデアを解説してくれる
|
||||
|
||||
フォーラムやランキングをスクロールするのが好きではなく、「誰かが思考を整理してくれる」方が好きなら、動画やポッドキャストも非常に適しています。
|
||||
|
||||
- `Greg Isenberg startup ideas`を検索
|
||||
具体的なアイデアを2〜3個直接解説し、市場規模、競合分析、切り口も説明してくれるので適しています。
|
||||
- `My First Million podcast`を検索
|
||||
2人の司会者がよく1回のエピソードでビジネスアイデアをブレインストーミングし、密度が高く、具体的なニッチがよく出てきます。
|
||||
- `YC startup ideas`または`Michael Seibel startup ideas`を検索
|
||||
初心者に適しており、内容が率直で、方向性の選び方を直接話すことが多いです。
|
||||
|
||||
<a id="idea-trends"></a>
|
||||
## [2. トレンドソース：どの方向が台頭しているかを見る](#top-idea-sources)
|
||||
|
||||
トレンドサイトの役割は、直接アイデアを提供することではなく、ある方向が上昇しているかどうか、引き続き見る価値があるかどうかを判断するのを助けることです。
|
||||
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
データで成長が速いが、まだ主流に入っていないトピックやプロダクトカテゴリーを追跡。まだあまり混雑していない方向を見るのに適しています。
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
キーワードを検索して過去1年のトレンドラインを見て、「関連クエリ」の「急上昇」ワードを確認。
|
||||
- [Glimpse](https://meetglimpse.com/)
|
||||
Google Trendsと同様
|
||||
- 業界研究レポートの要約ページ
|
||||
すでに方向性がある場合、その方向が業界内でどの位置にあるかを素早く見るのに適しています。
|
||||
- McKinsey / BCG / Gartnerのトレンドコンテンツ
|
||||
より企業や大規模業界の視点に偏っており、BtoB、工業、伝統的業界に適しています。
|
||||
- [State of AI Report](https://www.stateof.ai/)
|
||||
あなたの方向性がAI技術自体に関連している場合、このような年次レポートは大局観を構築するのに非常に適しています。
|
||||
|
||||
トレンドを見るときは、次の3点にのみ注目してください：
|
||||
|
||||
- この言葉は継続的に上昇しているか
|
||||
- それはどの具体的なシナリオに位置しているか
|
||||
- 誰が最初にそれに時間、切り替えコスト、または予算を払うのか
|
||||
|
||||
<a id="idea-business"></a>
|
||||
## [3. よりビジネス的なソース：誰がお金を使っているか、誰が不満を言っているか、誰が人工サービスを売っているかを見る](#top-idea-sources)
|
||||
|
||||
「かっこいい」方向性ではなく、「実際のビジネスに近い」方向性を見つけたいなら、ワークフローにより近いソースを見る必要があります。
|
||||
|
||||
### 誰が実際に何にお金を使っているかを見る
|
||||
|
||||
- [中国政府調達網](https://www.ccgp.gov.cn/)
|
||||
使い方：「スマート建設現場」「実験室管理システム」「データ収集」「診療所管理」「見積システム」等の言葉で検索し、予算、技術要件、使用シナリオを見る。
|
||||
- 各省市公共資源取引センター
|
||||
使い方：地方政府と国有企業が実際にどのシステムを調達しているかを見る。
|
||||
- 比標網 / 千里馬招標網 / 標事通
|
||||
使い方：企業側の調達ニーズと高頻度システムタイプを見る。
|
||||
|
||||
これらのソースの強いシグナルは、未来を議論しているのではなく、「今日すでにこのために支払う人がいる」ことを示していることです。
|
||||
|
||||
### 誰が実際に何に不満を言っているかを見る
|
||||
|
||||
- 製造業：機械コミュニティ、工控フォーラム
|
||||
- 医療：丁香園、医脈通
|
||||
- 建築 / エンジニアリング：土木オンライン、広聯達コミュニティ
|
||||
- 財務 / 会計：中国会計視野フォーラム
|
||||
- 貿易：福歩外贸フォーラム、米課圏
|
||||
- 飲食 / 小売：職業餐飲網、聯商網フォーラム
|
||||
- [Reddit](https://www.reddit.com/)の垂直セクション：`r/smallbusiness`、`r/Entrepreneur`、`r/SaaS`、`r/healthcare`、`r/manufacturing`
|
||||
- [V2EX](https://www.v2ex.com/)
|
||||
- 即刻
|
||||
- 小紅書
|
||||
|
||||
検索時には「AI」「イノベーション」だけでなく、以下の言葉で検索する方が効果的です：
|
||||
|
||||
- とても面倒
|
||||
- もっといい方法はないのか
|
||||
- おすすめツール求む
|
||||
- Excel では管理しきれない
|
||||
- I wish there was
|
||||
- is there a tool for
|
||||
- I hate
|
||||
|
||||
### 誰が反復的な人工サービスを売っているかを見る
|
||||
|
||||
- [Fiverr](https://www.fiverr.com/)
|
||||
- [Upwork](https://www.upwork.com/)
|
||||
- 猪八戒網
|
||||
- タオバオ
|
||||
- 閑魚
|
||||
|
||||
これらのサービスがよく売れているなら、引き続き調べる価値があります：
|
||||
|
||||
- PDFの見積書をExcelに整理してほしい
|
||||
- 顧客データを一括整理してほしい
|
||||
- 履歴書 / コピーの修正 / 書き起こし / アーカイブをしてほしい
|
||||
|
||||
このようなサービスの背後には通常、一回きりのニーズではなく、繰り返し発生するワークフローがあります。
|
||||
|
||||
### 完全なワークフローを見る、アイデアリストだけを見るのではなく
|
||||
|
||||
時には最も直接的な方法は、一つの業界を選び、そのプロセス全体を見て、WeChat、Excel、紙とペン、電話で行われているステップを見つけることです。
|
||||
|
||||
- 外貿：サプライヤー探し、見積もり依頼、比較、見積書作成、顧客への送付、返信フォロー、検品手配、船腹予約、通関。
|
||||
見るべき切り口：サプライヤーの見積もりを顧客見積もりに整理する。
|
||||
- 歯科診療所：受診、レントゲン撮影、画像診断、プラン説明、フォロー、治療、再診。
|
||||
見るべき切り口：患者にプランを説明し継続的にフォローする。
|
||||
- 建設現場：巡視、撮影、グループ送信、報告書整理、発注者に提出。
|
||||
見るべき切り口：現場写真からコンプライアンス報告書へ。
|
||||
|
||||
<a id="idea-vc"></a>
|
||||
## [4. VC / アクセラレーターソース：「波がどちらに打っているか」を見る](#top-idea-sources)
|
||||
|
||||
このカテゴリーのソースは大きな方向性を見つけるのに適していますが、直接検証に代わるものではありません。
|
||||
|
||||
- [Y Combinator — Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
使い方：切り口を見つけるのに適しています。よく「私たちがこういうものを作る人を見たい」と直接言ってくれます。
|
||||
- [a16z — Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
使い方：より大きなトレンドとトラックの判断に偏っており、業界感覚を構築するのに適しています。
|
||||
- [NFX](https://www.nfx.com/)
|
||||
使い方：スタートアップの課題を素早くスキャンするのに適しています。
|
||||
- [Sequoia Capital](https://www.sequoiacap.com/article/)
|
||||
使い方：必ずしもアイデアを直接リストアップするわけではありませんが、ある種のプラットフォーム変遷と機会についてよく語ります。
|
||||
- [First Round Review](https://review.firstround.com/)
|
||||
使い方：ある方向を深く掘り下げるのに適しており、アイデアリストとは限りませんが、記事の品質は通常非常に高いです。
|
||||
|
||||
これらのソースのメリット：
|
||||
|
||||
- 未来にどの方向を見る価値があるかを教えてくれる
|
||||
- どのトラックが継続的に推進される可能性があるかを教えてくれる
|
||||
- あるトラックのコンテキストに素早く入れる
|
||||
|
||||
これらのソースの制限：
|
||||
|
||||
- 通常、投資家の視点
|
||||
- 具体的にどの役割が最も苦痛かは必ずしも教えてくれない
|
||||
- どのプロセスのステップが最もボトルネックかは必ずしも教えてくれない
|
||||
- 今日誰がすでにそのために支払っているかは必ずしも教えてくれない
|
||||
|
||||
したがって、より良い使い方は：まずこれらで方向性を見つけ、それから参考プロダクト、業界フォーラム、調達情報、実際のワークフローに戻ってより具体的な切り口を見つけることです。
|
||||
|
||||
<a id="idea-path"></a>
|
||||
## [5. 「アイデアがなくてアシスタントを作ることしか思いつかない人」に最も適した最短使用パス](#top-idea-sources)
|
||||
|
||||
もし最短のパスを1つだけ歩くなら、次のようにできます：
|
||||
|
||||
1. 最初のステップ、30分。
|
||||
[r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)を開き、`Top -> Past Year`で並べ替えて、50の投稿を素早くスキャンし、「これなら私にもできそう」と感じる方向をすべて保存する。
|
||||
2. 2番目のステップ、30分。
|
||||
[Starter Story](https://www.starterstory.com/)または[Indie Hackers Products](https://www.indiehackers.com/products)を開き、収益順に並べ替え、中程度の収益のプロダクトを見て、最も成功しているものだけを見ない。最初のステップに関連する方向を見つけ、それらが具体的に誰に売っているか、どのステップを解決しているかを見る。
|
||||
3. 3番目のステップ、20分。
|
||||
[Google Trends](https://trends.google.com/)で関連キーワードを検索し、トレンドが成長しているかどうかを確認し、「関連クエリ」の急上昇ワードを見る。
|
||||
4. 4番目のステップ、20分。
|
||||
G2 / Capterra / 業界フォーラム / 入札プラットフォーム / Fiverr等のサイトで、この方向が今日どこが最も煩わしく、どこがまだ人力に頼っているかを見る。
|
||||
|
||||
見終わった後、次の一文をはっきりと言えれば十分です：
|
||||
|
||||
- ある種の人々が、あるシナリオで、あるプロセスのステップでつまずき、現在は主にある愚かな方法でやりくりしている。
|
||||
|
||||
<a id="idea-ai"></a>
|
||||
## [6. AIがどう役立つか](#top-idea-sources)
|
||||
|
||||
この記事の焦点はAIではありませんが、AIは整理に非常に適しています。
|
||||
|
||||
最も実用的な使い方は2つだけです：
|
||||
|
||||
- 閲覧したリンク、投稿タイトル、ユーザーの生の言葉をAIに貼り付け、「ユーザー層 / シナリオ / ペインポイント / 代替ソリューション」に分類してもらう。
|
||||
- AIに散在する情報を3つの候補方向に整理してもらい、50の機能に発散し続けるのではなく。
|
||||
|
||||
次のように直接聞けます：
|
||||
|
||||
```text
|
||||
最近見たソースは以下の通りです：
|
||||
1. [タイトルまたは生の言葉を貼り付ける]
|
||||
2. [タイトルまたは生の言葉を貼り付ける]
|
||||
3. [タイトルまたは生の言葉を貼り付ける]
|
||||
|
||||
機能リストは出さないでください。
|
||||
次の3つだけを行ってください：
|
||||
1. ユーザー層とシナリオで分類する
|
||||
2. 繰り返し現れる煩わしいステップを見つける
|
||||
3. より具体的な3つの候補方向に整理する
|
||||
```
|
||||
|
||||
## 関連読書
|
||||
|
||||
- [Y Combinator - Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
- [a16z - Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
- [NFX](https://www.nfx.com/)
|
||||
- [Reddit - r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
- [Reddit - r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
|
||||
- [Reddit - r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
- [Indie Hackers - Products](https://www.indiehackers.com/products)
|
||||
- [Product Hunt](https://www.producthunt.com/)
|
||||
- [BetaList](https://betalist.com/)
|
||||
- [IdeasAI](https://ideasai.com/)
|
||||
- [Unvalidated Ideas](https://unvalidatedideas.com/)
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
- [G2](https://www.g2.com/)
|
||||
- [Capterra](https://www.capterra.com/)
|
||||
@@ -0,0 +1,696 @@
|
||||
---
|
||||
title: 'Bエンド産業アプリケーションシーン方向参考'
|
||||
description: '本ドキュメントは、LLM大規模言語モデルのBエンド企業シーンにおける実装アプリケーションをまとめたものです。工業製造業、スマートカスタマーサポート、教育業界、スマートプログラミング、医療、ネットワークセキュリティ、金融管理、企業サービスなどの分野の具体的なアプリケーション方向をカバーし、企業顧客向けのAIアプリ開発者に参考を提供します。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { computed, ref } from 'vue'
|
||||
|
||||
const duration = '約 <strong>6 時間</strong>'
|
||||
|
||||
const interestPoint = ref('')
|
||||
const purpose = ref('')
|
||||
|
||||
// 各業界のトピックプール
|
||||
const topicPool = {
|
||||
'manufacturing': [
|
||||
{ title: '新エネルギーバス外観AI補助設計プラットフォーム', desc: '画像生成モデルによる外観コンセプト設計' },
|
||||
{ title: 'スマート図面設計・審査アシスタント', desc: 'RAG技術で企業設計規範ナレッジベースを構築' },
|
||||
{ title: '技術文書自動生成・管理', desc: 'LLMに基づく製品仕様書と操作マニュアルの自動生成' },
|
||||
{ title: '生産設備巡回点検レポート自動生成アシスタント', desc: '音声による設備状態記述、構造化巡回点検レポートの自動生成' },
|
||||
{ title: '工業設備故障診断ナレッジQAアシスタント', desc: '過去の故障ケースに基づくベクトルナレッジベースの構築' }
|
||||
],
|
||||
'customer-service': [
|
||||
{ title: 'マルチチャネルスマートカスタマーサポート自動応答・チケット生成システム', desc: 'マルチチャネルメッセージ受信、LLMによる意図理解後の応答生成' },
|
||||
{ title: '見込み客発掘・フォローアップ提案アシスタント', desc: '過去の対話記録を分析し、高意向顧客を識別' },
|
||||
{ title: '企業内部ナレッジスマート検索・QAマネージャー', desc: '内部文書に基づくベクトルナレッジベースの構築' },
|
||||
{ title: 'カスタマーサポート対話スマートサマリー・チケット生成ツール', desc: '会話終了後の自動サマリー生成とキー情報抽出' },
|
||||
{ title: 'カスタマーサポート金牌トーク推薦ナレッジシステム', desc: '優秀な事例を分析し、金牌トークテンプレートを抽出' }
|
||||
],
|
||||
'education': [
|
||||
{ title: 'パーソナライズ言語学習パス計画・スマート導学システム', desc: '学習者レベルを評価し、毎日の学習タスクを計画' },
|
||||
{ title: '授業案自動作成・教育リソース配信プラットフォーム', desc: 'カリキュラムに基づく授業案フレームワークの自動生成' },
|
||||
{ title: '宿題自動採点・学習状況診断分析システム', desc: '記述式問題の自動採点と添削アドバイスの自動生成' },
|
||||
{ title: '人材ポジションコンピテンシーモデル構築・学習マップ', desc: '求人JDを分析して能力要件を抽出' },
|
||||
{ title: '外国語スピーキング1対1シチュエーション実践演習', desc: 'LLMが異なる役割を演じ、スピーキング会話を実施' }
|
||||
],
|
||||
'programming': [
|
||||
{ title: 'スマートコード補完・Bug自動修正アシスタント', desc: 'IDEプラグインによるリアルタイムコード補完提案' },
|
||||
{ title: 'ローコードアプリ構築・プロセス自動化プラットフォーム', desc: '自然言語による要件記述をローコード設定に変換' },
|
||||
{ title: 'ユニットテストケース生成システム', desc: 'AST解析によるソースコード解析、境界条件テストケースの生成' },
|
||||
{ title: 'コードスマート分析・言語移行ツール', desc: 'コード品質の分析と最適化提案' },
|
||||
{ title: 'フロントエンドUIコード自動生成ツール', desc: 'デザイン画像認識によるレスポンシブCSSの生成' }
|
||||
],
|
||||
'healthcare': [
|
||||
{ title: '医学検査レポートスマート解読アシスタント', desc: 'OCRによる主要指標の認識、異常値の解読' },
|
||||
{ title: 'ナレッジ検索技術ベースの健康相談エキスパート', desc: '医学ナレッジグラフの構築、RAG検索による回答生成' },
|
||||
{ title: '臨床研究データ意思決定分析プラットフォーム', desc: 'EMRデータの統合、統計分析コードの補助生成' },
|
||||
{ title: '医学画像レポート自動生成ツール', desc: '画像特徴の記述による構造化レポートの自動生成' },
|
||||
{ title: '慢性疾患管理服薬リマインダースマートアシスタント', desc: 'パーソナライズ服薬リマインダの生成、服薬禁忌チェック対応' }
|
||||
],
|
||||
'security': [
|
||||
{ title: 'コードセキュリティ脆弱性検出・修正エンジン', desc: 'SASTによるコードスキャン、脆弱性原理の分析' },
|
||||
{ title: 'AI生成フィッシングメールスマート識別・ブロックシステム', desc: 'メール内容の分析によるAI生成フィッシングメールの識別' },
|
||||
{ title: 'セキュリティ運用日報自動生成アシスタント', desc: 'ログ集約、キーイベントの自動抽出' },
|
||||
{ title: 'ペネトレーションテストレポートスマート生成アシスタント', desc: '脆弱性記述に基づくレポートの自動生成' },
|
||||
{ title: '脅威インテリジェンススマート検索・分析アシスタント', desc: 'マルチソース脅威インテリジェンスの照会、コンテンツの解読' }
|
||||
],
|
||||
'finance': [
|
||||
{ title: '与信審査レポートスマート生成アシスタント', desc: '財務データ入力による与信審査レポートの自動生成' },
|
||||
{ title: 'プライベートバンクウェルスマートコンサルタント', desc: '顧客リスク許容度の分析による資産配分提案の生成' },
|
||||
{ title: 'IPO目論見書スマート生成・コンプライアンス検証アシスタント', desc: 'モジュール化テンプレートによる事業記述の自動入力' },
|
||||
{ title: '企業財務レポート自動生成・経営異常早期警戒システム', desc: '財務分析と経営層討論の自動生成' },
|
||||
{ title: '保険代理店スマートトーク練習', desc: 'シミュレーション対話によるトークのコンプライアンス性と説得力の評価' }
|
||||
],
|
||||
'enterprise': [
|
||||
{ title: '企業契約ライフサイクルコンプライアンス審査・修正提案プラットフォーム', desc: '条項の法規データベースとの照合、コンプライアンス審査レポートの生成' },
|
||||
{ title: '営業通話音声書き起こし・トーク推薦', desc: 'ASR書き起こし、会話分析と金牌トークの推薦' },
|
||||
{ title: 'マーケティングコンテンツスマート生成・デザインシステム', desc: 'マーケティングコピーとセールスポイントの抽出' },
|
||||
{ title: '競合広告出稿分析プラットフォーム', desc: '競合広告の収集、出稿戦略の分析' },
|
||||
{ title: '全网トレンドトピックスマート分析・コンテンツ推薦システム', desc: 'トレンド分析とトピック提案の推薦' }
|
||||
],
|
||||
'content': [
|
||||
{ title: '映像・小説コンテンツ制作補助プラットフォーム', desc: 'ストーリー概要、キャラクター設定、セリフ生成の提供' },
|
||||
{ title: '企業ブランドストーリー・PR記事スマート執筆アシスタント', desc: 'ブランドキーワード入力による複数スタイルコピーの生成' },
|
||||
{ title: 'バーチャルデジタルヒューマンライブ配信・配信管理システム', desc: 'デジタルヒューマン像 + TTS音声 + LLM対話' },
|
||||
{ title: 'ショートビデオスクリプト生成・スマート編集', desc: 'ショートビデオスクリプトと絵コンテの生成' },
|
||||
{ title: 'マーケティングコンテンツスマート生成・デザインシステム', desc: 'マーケティングコピーとセールスポイントの抽出' }
|
||||
],
|
||||
'government': [
|
||||
{ title: '12345行政窓口スマート音声ナビ・自動振り分けシステム', desc: '音声認識による要望の理解とスマート振り分け' },
|
||||
{ title: '行政サービスホールスマート案内・政策QAロボット', desc: '行政ナレッジベースのRAG検索' },
|
||||
{ title: '企業支援政策スマートマッチング・精密配信プラットフォーム', desc: '企業プロファイルによる適用政策の自動マッチング' },
|
||||
{ title: '行政審査書類スマート事前審査・コンプライアンス検証アシスタント', desc: 'OCR認識とキー情報抽出' },
|
||||
{ title: '都市グリッドイベントスマート識別・配車管理プラットフォーム', desc: 'イベントタイプの識別と振り分け' }
|
||||
],
|
||||
'legal': [
|
||||
{ title: '契約リスク脆弱性ワンクリック「間違い探し」Agent', desc: 'リスクチェックリストとの照合による潜在的問題の識別' },
|
||||
{ title: '類似案件勝訴率AIスマート評価コンサルタント', desc: '案件特徴抽出、類似案件の検索マッチング' },
|
||||
{ title: '法規変更リアルタイム監視・業務影響分析レーダー', desc: '変更内容の解析と業務影響の評価' },
|
||||
{ title: '弁護士レターAIGC自動起案ツール', desc: '事実陳述入力による規範的な弁護士レターの生成' },
|
||||
{ title: '複雑な法律条項「翻訳」を平易な言葉にする解説プラグイン', desc: '分かりやすい解説の生成' }
|
||||
],
|
||||
'travel': [
|
||||
{ title: 'AIGCベースのラク旅ガイドジェネレーター', desc: '毎日の旅程スケジュールの自動生成' },
|
||||
{ title: '全网航空券・ホテル価格トレンド予測・低価格自動ロックボット', desc: 'MLモデルによる価格トレンド予測' },
|
||||
{ title: 'ビザ書類スマート事前審査・自動フォーム記入補助システム', desc: 'OCR認識による情報完全性チェック' },
|
||||
{ title: '海外旅行リアルタイム音声翻訳・メニュー視覚中国語化マネージャー', desc: 'オフライン音声翻訳、メニュー画像OCR' },
|
||||
{ title: '旅行足迹自動生成精美旅行記・SNS投稿アシスタント', desc: '写真情報抽出による旅行記文案の生成' }
|
||||
],
|
||||
'emotion': [
|
||||
{ title: 'LLMベースの24時間深層コンパニオン仮想パートナー', desc: '記憶システムによる対話履歴の保存' },
|
||||
{ title: 'マルチモーダル感情認識・心理カウンセリングAIコンサルタント', desc: '音声トーン分析 + テキスト感情認識' },
|
||||
{ title: 'アルツハイマー老人AI認知訓練・記憶想起デジタルヒューマン', desc: '認知ゲーム訓練、古い写真による記憶トリガー' },
|
||||
{ title: '社交不安のAIGCシミュレーション社交練習コーチ', desc: 'バーチャル社交シーンのシミュレーション' },
|
||||
{ title: '全天候気分監視・AIポジティブ感情モチベーションアシスタント', desc: '気分トレンドの分析とモチベーションコンテンツの生成' }
|
||||
],
|
||||
'entertainment': [
|
||||
{ title: 'LLM駆動のオープンワールドゲームNPC自律意思決定エンジン', desc: 'NPC行動木とLLM意思決定の融合' },
|
||||
{ title: '没入型マーダーミステリーAIGCストーリー推演・DMコントロール補助ツール', desc: 'プレイヤーの選択によるストーリー分岐のトリガー' },
|
||||
{ title: 'インタラクティブ小説エンディング生成式修飾器', desc: '読者の選択がストーリーの方向性に影響' },
|
||||
{ title: 'eスポーツ戦局CVビジュアル分析・AIスマート実況アナウンサー', desc: 'ゲーム画面のリアルタイム分析' },
|
||||
{ title: 'マルチキャラTTS音声合成オーディオブック自動生成システム', desc: 'テキストのキャラクター割り当て、パーソナライズ音色の生成' }
|
||||
],
|
||||
'ecommerce': [
|
||||
{ title: '高コンバージョンAIGC商品詳細ページ一括生産ツール', desc: 'セールスポイントコピーとシーン記述の生成' },
|
||||
{ title: 'アパレルバーチャルモデルAIスマート試着・展示動画生成ファクトリー', desc: 'バーチャルモデル試着効果の生成' },
|
||||
{ title: '越境EC多言語LLMローカライズ翻訳・ブラッシュアップアシスタント', desc: '商品説明の多言語翻訳' },
|
||||
{ title: '24時間全天候AIGCデジタルヒューマンライブ配信システム', desc: 'デジタルヒューマン像 + リアルタイムトーク生成' },
|
||||
{ title: '市場トレンドAIインサイト・爆売り予測エンジン', desc: 'トレンドホットスポットの洞察、品揃え提案' }
|
||||
],
|
||||
'energy': [
|
||||
{ title: '家庭電力使用行動AI分析・省エネ戦略コンサルタント', desc: '電力使用パターンの分析、省エネ提案の生成' },
|
||||
{ title: '太陽光パネル欠陥ドローンCVビジュアル識別システム', desc: 'ドローン巡回撮影、熱赤外画像分析' },
|
||||
{ title: '電力スポット取引価格AIトレンド予測・自動利益戦略Agent', desc: '価格予測モデル、戦略生成' },
|
||||
{ title: '企業全チェーンカーボン排出AI自動算定・ESGレポート生成アシスタント', desc: 'カーボン排出因子の計算、ESGレポートの自動生成' },
|
||||
{ title: '電網異常気象負荷AI予測・緊急配車指揮システム', desc: '気象データ連携、負荷予測モデル、配車戦略生成' }
|
||||
],
|
||||
'av-media': [
|
||||
{ title: '長編動画ハイライトAI識別・ショートビデオ自動編集ツール', desc: 'ビデオコンテンツ分析、キーフレーム識別' },
|
||||
{ title: 'ビデオ背景ノイズAIスマート分離・音声強調アシスタント', desc: 'オーディオ分離モデル、背景ノイズ除去' },
|
||||
{ title: '古い映像4Kアップスケーリング修復・AIスマート着色ワークベンチ', desc: 'ビデオ超解像度モデル、AI自動着色' },
|
||||
{ title: 'テキストからリアルレベルTTS吹き替え・感情制御システム', desc: 'マルチ音色TTSモデル、感情制御生成' },
|
||||
{ title: '会議録音AIスマート書き起こし・コアToDo抽出アシスタント', desc: '複数人会議の音声分離書き起こし' }
|
||||
],
|
||||
'ai-marketing': [
|
||||
{ title: 'RED爆売りコピーAIGC自動執筆エンジン', desc: '種草コピーの生成、emoji最適化' },
|
||||
{ title: 'マーケティングポスターAIスマートレイアウト・マルチサイズ適応ツール', desc: 'ポスターテンプレートのスマートマッチング' },
|
||||
{ title: 'ブランドLOGOクリエイティブAIGC生成・VI体系構築プラットフォーム', desc: 'LOGOクリエイティブ生成、VI規範生成' },
|
||||
{ title: '全网ホットAI追跡・トレンドマーケティングクリエイティブ生成アシスタント', desc: 'マーケティング角度の分析、クリエイティブプランの生成' },
|
||||
{ title: 'ショートビデオスクリプトクリエイティブAIGC生成・絵コンテガイダンスアシスタント', desc: 'スクリプトと絵コンテの生成、撮影アドバイス' }
|
||||
],
|
||||
'data-intelligence': [
|
||||
{ title: '自然言語からSQL文への自動生成ツール', desc: '自然言語クエリのSQLへの変換' },
|
||||
{ title: '企業データアセットカタログスマート棚卸・分類システム', desc: 'メタデータ収集、自動分類' },
|
||||
{ title: 'データ品質異常自動検出・修正提案エンジン', desc: 'ルールエンジン + MLモデルによる異常検出' },
|
||||
{ title: 'スマートレポート生成・ビジュアル設定アシスタント', desc: '対話式レポート設定の生成' },
|
||||
{ title: 'データ指標定義スマートQAアシスタント', desc: '指標定義ドキュメントに基づくナレッジベースの構築' }
|
||||
]
|
||||
}
|
||||
|
||||
// 推薦リンクマッピングテーブル
|
||||
const recommendationMap = {
|
||||
'creative-content': {
|
||||
'increase-efficiency': ['content', 'av-media', 'ai-marketing', 'entertainment'],
|
||||
'reduce-cost': ['content', 'ecommerce', 'ai-marketing'],
|
||||
'improve-experience': ['entertainment', 'emotion', 'travel', 'content'],
|
||||
'innovate-business': ['ai-marketing', 'content', 'av-media', 'entertainment']
|
||||
},
|
||||
'tech-service': {
|
||||
'increase-efficiency': ['programming', 'enterprise', 'data-intelligence', 'customer-service'],
|
||||
'reduce-cost': ['programming', 'enterprise', 'manufacturing'],
|
||||
'improve-experience': ['customer-service', 'enterprise', 'programming'],
|
||||
'innovate-business': ['data-intelligence', 'programming', 'security', 'enterprise']
|
||||
},
|
||||
'data-intel': {
|
||||
'increase-efficiency': ['data-intelligence', 'finance', 'enterprise', 'manufacturing'],
|
||||
'reduce-cost': ['data-intelligence', 'manufacturing', 'energy'],
|
||||
'improve-experience': ['data-intelligence', 'customer-service', 'ecommerce'],
|
||||
'innovate-business': ['data-intelligence', 'finance', 'security', 'ai-marketing']
|
||||
},
|
||||
'user-service': {
|
||||
'increase-efficiency': ['customer-service', 'ecommerce', 'travel', 'enterprise'],
|
||||
'reduce-cost': ['customer-service', 'ecommerce', 'enterprise'],
|
||||
'improve-experience': ['customer-service', 'emotion', 'travel', 'ecommerce', 'entertainment'],
|
||||
'innovate-business': ['ecommerce', 'travel', 'emotion', 'entertainment']
|
||||
},
|
||||
'industry-solution': {
|
||||
'increase-efficiency': ['manufacturing', 'healthcare', 'finance', 'government'],
|
||||
'reduce-cost': ['manufacturing', 'energy', 'enterprise', 'finance'],
|
||||
'improve-experience': ['healthcare', 'education', 'government', 'travel'],
|
||||
'innovate-business': ['finance', 'security', 'legal', 'healthcare', 'government']
|
||||
}
|
||||
}
|
||||
|
||||
const interestOptions = [
|
||||
{ label: 'クリエイティブコンテンツ生成', value: 'creative-content', desc: 'コピー、画像、動画などのクリエイティブコンテンツ' },
|
||||
{ label: 'テクニカルサービスツール', value: 'tech-service', desc: '開発ツール、自動化、コード補助' },
|
||||
{ label: 'データインテリジェンス分析', value: 'data-intel', desc: 'データ分析、予測、スマート意思決定' },
|
||||
{ label: 'ユーザーサービス体験', value: 'user-service', desc: 'カスタマーサポート、マーケティング、ユーザー体験' },
|
||||
{ label: '業界ソリューション', value: 'industry-solution', desc: '特定業界のディープアプリケーション' }
|
||||
]
|
||||
|
||||
const purposeOptions = [
|
||||
{ label: '効率向上', value: 'increase-efficiency', desc: '自動化、プロセス高速化' },
|
||||
{ label: 'コスト削減', value: 'reduce-cost', desc: '人件費削減、リソース最適化' },
|
||||
{ label: '体験改善', value: 'improve-experience', desc: 'ユーザー満足度、サービス品質' },
|
||||
{ label: 'ビジネスイノベーション', value: 'innovate-business', desc: '新製品、新モデル' }
|
||||
]
|
||||
|
||||
const industries = [
|
||||
{ key: 'manufacturing', name: '工業製造業', anchor: '#_1-工業製造業' },
|
||||
{ key: 'customer-service', name: 'スマートカスタマーサポート', anchor: '#_2-スマートカスタマーサポート' },
|
||||
{ key: 'education', name: '教育業界', anchor: '#_3-教育業界' },
|
||||
{ key: 'programming', name: 'スマートプログラミング', anchor: '#_4-スマートプログラミング' },
|
||||
{ key: 'healthcare', name: '医療方向', anchor: '#_5-医療方向' },
|
||||
{ key: 'security', name: 'ネットワークセキュリティ', anchor: '#_6-ネットワークセキュリティ' },
|
||||
{ key: 'finance', name: '金融管理・保険銀行業', anchor: '#_7-金融管理・保険銀行業' },
|
||||
{ key: 'enterprise', name: '企業サービス', anchor: '#_8-企業サービス' },
|
||||
{ key: 'content', name: 'コンテンツ制作・運営', anchor: '#_9-コンテンツ制作・運営' },
|
||||
{ key: 'government', name: 'スマート行政', anchor: '#_10-スマート行政' },
|
||||
{ key: 'legal', name: '法律事務・契約管理', anchor: '#_11-法律事務・契約管理' },
|
||||
{ key: 'travel', name: '旅行・外出サービス', anchor: '#_12-旅行・外出サービス' },
|
||||
{ key: 'emotion', name: 'エモーショナルコンパニオン', anchor: '#_13-エモーショナルコンパニオン' },
|
||||
{ key: 'entertainment', name: 'レジャー・エンターテインメント', anchor: '#_14-レジャー・エンターテインメント' },
|
||||
{ key: 'ecommerce', name: 'ECサービス', anchor: '#_15-ECサービス' },
|
||||
{ key: 'energy', name: 'エネルギー', anchor: '#_16-エネルギー' },
|
||||
{ key: 'av-media', name: '音声・動画', anchor: '#_17-音声・動画' },
|
||||
{ key: 'ai-marketing', name: 'AIマーケティング', anchor: '#_18-AIマーケティング' },
|
||||
{ key: 'data-intelligence', name: 'データインテリジェンス', anchor: '#_19-データインテリジェンス' }
|
||||
]
|
||||
|
||||
// 推薦結果を計算
|
||||
const recommendationTopics = computed(() => {
|
||||
if (!interestPoint.value || !purpose.value) return []
|
||||
|
||||
const keys = recommendationMap[interestPoint.value]?.[purpose.value] || []
|
||||
const topics = []
|
||||
|
||||
keys.forEach(key => {
|
||||
const industry = industries.find(item => item.key === key)
|
||||
const industryTopics = topicPool[key] || []
|
||||
|
||||
if (industry && industryTopics.length > 0) {
|
||||
const count = Math.floor(Math.random() * 2) + 1
|
||||
const shuffled = [...industryTopics].sort(() => Math.random() - 0.5)
|
||||
const selected = shuffled.slice(0, Math.min(count, shuffled.length))
|
||||
|
||||
selected.forEach(topic => {
|
||||
topics.push({
|
||||
...topic,
|
||||
industryKey: key,
|
||||
industryName: industry.name,
|
||||
industryAnchor: industry.anchor
|
||||
})
|
||||
})
|
||||
}
|
||||
})
|
||||
|
||||
return topics.sort(() => Math.random() - 0.5).slice(0, 8)
|
||||
})
|
||||
|
||||
const currentSelection = computed(() => {
|
||||
const interest = interestOptions.find(i => i.value === interestPoint.value)
|
||||
const pur = purposeOptions.find(p => p.value === purpose.value)
|
||||
return {
|
||||
interest: interest?.label || '',
|
||||
purpose: pur?.label || ''
|
||||
}
|
||||
})
|
||||
|
||||
const scrollToAnchor = (anchor) => {
|
||||
setTimeout(() => {
|
||||
let element = document.querySelector(anchor)
|
||||
|
||||
if (!element) {
|
||||
const altAnchor = anchor.replace('#_', '#')
|
||||
element = document.querySelector(altAnchor)
|
||||
}
|
||||
|
||||
if (!element) {
|
||||
const anchorText = decodeURIComponent(anchor.replace('#', '').replace(/^_/, ''))
|
||||
const headings = document.querySelectorAll('h2, h3')
|
||||
|
||||
for (let heading of headings) {
|
||||
const headingText = heading.textContent.trim()
|
||||
const cleanHeading = headingText.replace(/^\d+\.\s*/, '')
|
||||
if (cleanHeading === anchorText || headingText.includes(anchorText)) {
|
||||
element = heading
|
||||
break
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (element) {
|
||||
element.scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
block: 'start'
|
||||
})
|
||||
element.style.backgroundColor = '#f0f9ff'
|
||||
element.style.transition = 'background-color 0.3s'
|
||||
element.style.padding = '8px'
|
||||
element.style.borderRadius = '4px'
|
||||
setTimeout(() => {
|
||||
element.style.backgroundColor = ''
|
||||
element.style.padding = ''
|
||||
}, 2000)
|
||||
}
|
||||
}, 100)
|
||||
}
|
||||
|
||||
const resetSelection = () => {
|
||||
interestPoint.value = ''
|
||||
purpose.value = ''
|
||||
}
|
||||
</script>
|
||||
|
||||
# Bエンド産業アプリケーションシーン方向参考
|
||||
|
||||
## 章節のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['Bエンドアプリ', '産業アプリケーション', 'AIシーン', '実装参考', '業界ソリューション']" coreOutput="15以上のBエンド業界アプリケーションシーンを理解" expectedOutput="企業顧客に適したプロジェクト方向を見つける">
|
||||
|
||||
本ドキュメントは <strong>LLM大規模言語モデルのBエンド企業シーンにおける実装アプリケーション</strong>をまとめたものです。Cエンドがユーザー体験と感情に注目するのとは異なり、Bエンドプロダクトは<strong>実際のビジネスニーズの解決、効率向上、コスト削減</strong>を重視します。各シーンは<strong>実際の実装の可能性</strong>を持ち、<strong>ニーズ分析から技術実装</strong>までの完全なアプローチをカバーしています。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
## 業界方向クイック選択
|
||||
|
||||
<el-card shadow="hover" style="margin-top: 16px; margin-bottom: 24px; border-left: 5px solid #409EFF;">
|
||||
<div style="font-weight: 600; margin-bottom: 8px;">あなたに合ったアプリケーションシーンを見つける</div>
|
||||
<div style="color: #606266; font-size: 14px; line-height: 1.6; margin-bottom: 12px;">
|
||||
興味の方向と実現したい目的を選択すると、システムが関連する業界シーンを推薦します。タグをクリックすると対応する章にジャンプします。
|
||||
</div>
|
||||
<el-row :gutter="16">
|
||||
<el-col :span="12">
|
||||
<el-select v-model="interestPoint" placeholder="興味方向を選択" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in interestOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value">
|
||||
<div style="display: flex; flex-direction: column;">
|
||||
<span>{{ item.label }}</span>
|
||||
<span style="font-size: 12px; color: #909399;">{{ item.desc }}</span>
|
||||
</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<el-select v-model="purpose" placeholder="実現目的を選択" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in purposeOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value">
|
||||
<div style="display: flex; flex-direction: column;">
|
||||
<span>{{ item.label }}</span>
|
||||
<span style="font-size: 12px; color: #909399;">{{ item.desc }}</span>
|
||||
</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
<div v-if="recommendationTopics.length > 0" style="margin-top: 16px;">
|
||||
<div style="font-weight: 600; margin-bottom: 10px; color: #409EFF;">
|
||||
おすすめ {{ recommendationTopics.length }} 個のアプリケーションシーン
|
||||
<span style="font-weight: normal; color: #909399; font-size: 13px; margin-left: 8px;">
|
||||
({{ currentSelection.interest }} + {{ currentSelection.purpose }})
|
||||
</span>
|
||||
</div>
|
||||
<el-table
|
||||
:data="recommendationTopics"
|
||||
style="width: 100%; cursor: pointer;"
|
||||
@row-click="(row) => scrollToAnchor(row.industryAnchor)"
|
||||
highlight-current-row>
|
||||
<el-table-column prop="title" label="アプリケーションシーン" min-width="300">
|
||||
<template #default="scope">
|
||||
<div style="font-weight: 500; color: #303133;">{{ scope.row.title }}</div>
|
||||
<div style="font-size: 12px; color: #909399; margin-top: 4px;">{{ scope.row.desc }}</div>
|
||||
</template>
|
||||
</el-table-column>
|
||||
<el-table-column prop="industryName" label="所属業界" width="180" align="center">
|
||||
<template #default="scope">
|
||||
<el-tag type="info" effect="light" size="small">{{ scope.row.industryName }}</el-tag>
|
||||
</template>
|
||||
</el-table-column>
|
||||
</el-table>
|
||||
<div style="margin-top: 10px; font-size: 12px; color: #909399;">
|
||||
テーブルの任意の行をクリックすると対応する業界の章にジャンプします
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div v-else-if="!interestPoint || !purpose" style="margin-top: 14px; color: #909399; font-size: 13px;">
|
||||
<span v-if="!interestPoint && !purpose">興味方向と実現目的を選択してください</span>
|
||||
<span v-else-if="!interestPoint">興味方向を選択してください</span>
|
||||
<span v-else>実現目的を選択してください</span>
|
||||
</div>
|
||||
|
||||
<div v-if="interestPoint || purpose" style="margin-top: 12px;">
|
||||
<el-button size="small" @click="resetSelection">再選択</el-button>
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
## 業界クイック紹介
|
||||
|
||||
### 主要技術選択
|
||||
|
||||
AIアプリ開発では、一般的な技術方向として以下があります：
|
||||
|
||||
1. **LLM（大規模言語モデル）**：自然言語タスクの処理に得意。対話、テキスト生成、要約、翻訳などに適用。
|
||||
2. **VLM（視覚言語モデル）**：視覚理解と言語能力を組み合わせ、画像記述、視覚QA、マルチモーダルコンテンツ生成を実現。
|
||||
3. **GenAI（生成式AI）**：テキスト生成、画像生成、動画生成などを含む。
|
||||
|
||||
### 選択戦略
|
||||
|
||||
1. **興味志向**：自分が興味のある業界や技術方向を優先選択。
|
||||
2. **業界適合**：自身の業界背景やリソースの優位性に合わせてシーンを選択。
|
||||
3. **技術難易度**：自身の技術基盤に合わせて適切な複雑さを選択。
|
||||
|
||||
## 1. 工業製造業
|
||||
|
||||
工業製造業シーンは主に設計補助、生産最適化、スマートメンテナンスの3つの方向に展開します。
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 新エネルギーバス外観AI補助設計プラットフォーム | 画像生成モデルによる外観コンセプト設計、LLMによる設計規範チェック |
|
||||
| 2 | スマート図面設計・審査アシスタント | RAG技術による企業設計規範ナレッジベース構築 |
|
||||
| 3 | 技術文書自動生成・管理 | LLMによる製品仕様書と操作マニュアルの自動生成 |
|
||||
| 4 | 生産設備巡回点検レポート自動生成アシスタント | 音声による設備状態記述、構造化巡回点検レポートの自動生成 |
|
||||
| 5 | 工場フォークリフトスマート配車・経路計画システム | LLMによる注文タスクと倉庫位置の解析、地図APIによる最適配車方案 |
|
||||
| 6 | LLM情報検索ベースのデータウェアハウス | Text-to-SQL技術による自然言語からデータベースクエリへの変換 |
|
||||
| 7 | 工業設備故障診断ナレッジQAアシスタント | 過去の故障ケースに基づくベクトルナレッジベース構築 |
|
||||
| 8 | 生産品質検査レポートスマート生成・欠陥分類 | OCRによる検査写真の欠陥認識、LLMによる構造化品質検査レポートの生成 |
|
||||
| 9 | 在庫棚卸スマートアシスタント・棚卸レポート生成 | 棚卸データ入力、LLMによるシステム在庫との自動照合・差異レポート生成 |
|
||||
| 10 | 工芸プロセス最適化提案スマートQAシステム | 生産工芸ドキュメントに基づくRAGナレッジベースの構築 |
|
||||
|
||||
## 2. スマートカスタマーサポート
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | マルチチャネルスマートカスタマーサポート自動応答・チケット生成システム | マルチチャネルメッセージ受信、LLMによる意図理解後の応答生成とチケット自動作成 |
|
||||
| 2 | 見込み客発掘・フォローアップ提案アシスタント | LLMによる過去のカスタマーサポート対話記録の分析、高意向顧客の識別 |
|
||||
| 3 | 企業内部ナレッジスマート検索・QAマネージャー | Confluenceと内部文書に基づくベクトルナレッジベース構築 |
|
||||
| 4 | カスタマー満足度調査・サービス改善管理システム | LLMによるカスタマーサポート対話の自動感情分類と満足度スコアリング |
|
||||
| 5 | カスタマーサポート対話スマートサマリー・チケット生成ツール | 会話終了後の自動サマリー生成とキー情報抽出 |
|
||||
| 6 | カスタマーサポートトークコンプライアンス自動検出アシスタント | カスタマーサポートの返信内容のリアルタイムコンプライアンス性検出 |
|
||||
| 7 | カスタマーサポートチケット自動要約・分類生成ツール | 長い対話記録の要約生成と自動分類タグ付け |
|
||||
| 8 | カスタマー感情監視・異常早期警告ツール | リアルタイムでの音声トーン特徴とテキスト感情の分析 |
|
||||
| 9 | カスタマーサポート金牌トーク推薦ナレッジシステム | 優秀なカスタマーサポート対話事例の分析、金牌トークテンプレートの抽出 |
|
||||
| 10 | スマート外線通話対話内容分析・品質検査アシスタント | 外線通話録音の書き起こし、LLMによる対話内容の分析 |
|
||||
|
||||
## 3. 教育業界
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | パーソナライズ言語学習パス計画・スマート導学システム | LLMによる学習者レベル評価、毎日の学習タスクの計画 |
|
||||
| 2 | 授業案自動作成・教育リソース配信プラットフォーム | LLMによるカリキュラムに基づく授業案フレームワークの生成 |
|
||||
| 3 | 宿題自動採点・学習状況診断分析システム | LLMによる記述式問題の自動採点と学習弱点の特定 |
|
||||
| 4 | 人材ポジションコンピテンシーモデル構築・学習マップ | LLMによる求人JDの分析、ポジション能力プロファイリングの構築 |
|
||||
| 5 | 校本カリキュラム体系構築・スライド制作ツール | LLMによる学校特色と学生ニーズの分析、校本カリキュラムフレームワークの生成 |
|
||||
| 6 | 外国語スピーキング1対1シチュエーション実践演習 | LLMが異なる役割を演じるスピーキング会話、ASRによる発音の認識と採点 |
|
||||
| 7 | 大学受験大数据推薦・キャリアプランニング指導プラットフォーム | LLMによる受験生のスコア・順位・興味情報の分析 |
|
||||
| 8 | 児童プログラミングコードアシスタント | LLMによるコードロジックの解説とプログラミング指導 |
|
||||
| 9 | 知識ポイントマインドマップ自動生成・学習パス推薦ツール | コーストピック入力によるLLMの知識ポイントマインドマップの自動生成 |
|
||||
| 10 | 中英作文自動採点・添削エンジン | LLMによる立意、構造、言語、多様性などの多次元採点 |
|
||||
|
||||
## 4. スマートプログラミング
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | スマートコード補完・Bug自動修正アシスタント | CodeLlama微調整コードモデル、IDEプラグインによるリアルタイムコード補完提案 |
|
||||
| 2 | ローコードアプリ構築・プロセス自動化プラットフォーム | 自然言語による要件記述のLLMによるローコード設定への変換 |
|
||||
| 3 | ユニットテストケース生成システム | AST解析による関数ロジックの抽出、LLMによる境界条件テストケースの生成 |
|
||||
| 4 | コードスマート分析・言語移行ツール | Tree-sitterによるコード構造の解析、LLMによるコード品質分析と最適化提案 |
|
||||
| 5 | 自然言語からSQL文への自動生成ツール | LLMによる自然言語クエリのSQLへの変換 |
|
||||
| 6 | APIインターフェース自動テスト・ドキュメント生成プラットフォーム | LLMによるコードコメントとインターフェース定義の分析 |
|
||||
| 7 | UIテストスクリプトスマート録画・保守ツール | ブラウザプラグインによるユーザー操作軌跡の録画 |
|
||||
| 8 | システムログ分析・故障特定 | ELK Stackによるログデータの収集、LLMによる異常ログの分析 |
|
||||
| 9 | フロントエンドUIコード自動生成ツール | デザイン画像OCR認識によるレスポンシブCSSとコンポーネントコードの生成 |
|
||||
| 10 | データベース構造スマート設計・モデリングアシスタント | 業務要件ドキュメント入力によるER図とデータテーブル構造の自動生成 |
|
||||
|
||||
## 5. 医療方向
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 医学検査レポートスマート解読アシスタント | 検査レポート画像のアップロード、OCRによる主要指標の認識、LLMによる異常値の解読 |
|
||||
| 2 | ナレッジ検索技術ベースの健康相談エキスパート | 医学ナレッジグラフ（ICD-10、薬品説明書、診療ガイドライン）の構築 |
|
||||
| 3 | 臨床研究データ意思決定分析プラットフォーム | EMRデータと検査結果の統合、LLMによる統計分析コードの補助生成 |
|
||||
| 4 | 医学試験問題スマート生成・間違い解析システム | 教材の章と知識ポイントの入力による練習問題と解説の生成 |
|
||||
| 5 | 薬物研究全プロセスナレッジグラフスマートQAエキスパート | 薬物-ターゲット-疾患ナレッジグラフの構築 |
|
||||
| 6 | 薬品説明書スマートQAアシスタント | 薬品説明書画像のアップロードまたは薬名入力による用法用量等のQA |
|
||||
| 7 | 疾病知識科普記事生成アシスタント | 疾病名と受診者の入力による分かりやすい科普記事の生成 |
|
||||
| 8 | 医学画像レポート自動生成ツール | 放射線科医師の画像特徴記述による構造化レポートの自動生成 |
|
||||
| 9 | 手術記録スマート生成・アーカイブアシスタント | 手術中の音声入力による構造化手術記録の生成 |
|
||||
| 10 | 慢性疾患管理服薬リマインダースマートアシスタント | 患者の服薬リスト入力によるパーソナライズ服薬リマインダの生成 |
|
||||
|
||||
## 6. ネットワークセキュリティ
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | コードセキュリティ脆弱性検出・修正エンジン | SASTツールによるコードスキャン、LLMによる脆弱性原理の分析 |
|
||||
| 2 | AI生成フィッシングメールスマート識別・ブロックシステム | LLMによるメール内容・送信者特徴・リンク安全性の分析 |
|
||||
| 3 | セキュリティ運用日報自動生成アシスタント | セキュリティデバイスログの集約、キーイベントの自動抽出 |
|
||||
| 4 | セキュリティナレッジベーススマートQAアシスタント | セキュリティドキュメント、CVEライブラリに基づくベクトルナレッジベースの構築 |
|
||||
| 5 | ペネトレーションテストレポートスマート生成アシスタント | ペネトレーションテスト完了後の脆弱性記述に基づくレポートの自動生成 |
|
||||
| 6 | 悪意コード防护・プライバシーコンプライアンス監視 | サンドボックスによる不審査ファイルの動作分析、LLMによる悪意特徴の識別 |
|
||||
| 7 | セキュリティ設定コンプライアンスチェックリスト生成ツール | 対象システムタイプの入力によるセキュリティ設定チェックリストの生成 |
|
||||
| 8 | 脅威インテリジェンススマート検索・分析アシスタント | マルチソース脅威インテリジェンスの照会、LLMによるインテリジェンスの解読 |
|
||||
| 9 | セキュリティインシデント振り返りレポート生成アシスタント | セキュリティインシデント発生後のタイムラインに基づく振り返りレポートの自動生成 |
|
||||
| 10 | グローバル脅威インテリジェンス監視・早期警戒センター | グローバルセキュリティニュースと脆弱性開示のクローリング |
|
||||
|
||||
## 7. 金融管理・保険銀行業
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 与信審査レポートスマート生成アシスタント | 企業基本情報と財務データの入力による与信審査レポートの自動生成 |
|
||||
| 2 | プライベートバンクウェルスマートコンサルタント | 顧客リスク許容度と財務目標の分析による資産配分提案の生成 |
|
||||
| 3 | IPO目論見書スマート生成・コンプライアンス検証アシスタント | 目論見書のモジュール化テンプレート、LLMによる事業記述の自動入力 |
|
||||
| 4 | 企業財務レポート自動生成・経営異常早期警戒システム | 財務システムデータの自動収集、LLMによる財務分析の生成 |
|
||||
| 5 | 財務票券情報抽出・QAアシスタント | 請求書画像のアップロード、OCR認識、LLMによる関連QA |
|
||||
| 6 | コンプライアンスケーススマート検索・QAアシスタント | 規制処罰ケースに基づくナレッジベースの構築 |
|
||||
| 7 | 保険代理店スマートトーク練習 | LLMが異なるタイプの顧客を演じるシミュレーション対話 |
|
||||
| 8 | 保険商品条項分析・競合比較プラットフォーム | 条項の構造化解析、LLMによるハイライトサマリーと注意事項の生成 |
|
||||
| 9 | 顧客トーク感情識別サービス | 音声感情認識とトークコンプライアンス検出のリアルタイムフィードバック |
|
||||
| 10 | 保険理赔進捗スマート照会・対話アシスタント | ユーザーの保険証番号または案件番号の入力による理赔進捗の照会 |
|
||||
|
||||
## 8. 企業サービス
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 顧客維持分析・解約早期警戒プラットフォーム | 行動データのトラッキング収集、MLモデルによる解約確率の予測 |
|
||||
| 2 | B2B見込み客アプローチ・マーケティングメールプラットフォーム | 企業工商データによるターゲット顧客のフィルタリング、LLMによるパーソナライズマーケティングコンテンツの生成 |
|
||||
| 3 | 営業パイプライン監視・業績予測プラットフォーム | CRMデータの自動収集、LLMによる営業ファネルの分析と業績達成の予測 |
|
||||
| 4 | ブランドレピュテーション監視・危機早期警戒レーダー | 全网レピュテーションデータの収集（ソーシャルメディア、ニュース、フォーラム）、LLMによる感情と伝播トレンドの分析 |
|
||||
| 5 | 職場メールスマート執筆・コミュニケーション感情管理アシスタント | メールコンテキストの理解、LLMによるプロフェッショナルメール草案の生成 |
|
||||
| 6 | 履歴書スマート解析・ポジションマッチングシステム | 履歴書PDFの解析によるキー情報の抽出、LLMによる適合ポジションのマッチング |
|
||||
| 7 | 企業従業員入社ガイド・QAアシスタント | 入社ドキュメントナレッジベースのRAG検索、新入社員のよくある質問への回答 |
|
||||
| 8 | 従業員パフォーマンスフィードバック・OKR目標管理プラットフォーム | OKRシステムデータの収集、LLMによる目標達成状況の分析 |
|
||||
| 9 | スマート会議記録・ToDo管理 | 会議録音の書き起こし、LLMによる主要議論点とToDo項目の抽出 |
|
||||
| 10 | 請求書識別・経費精算自動処理 | OCRによる請求書情報の認識、請求書の真贋検証と精算コンプライアンスの自動確認 |
|
||||
|
||||
## 9. コンテンツ制作・運営
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 映像・小説コンテンツ制作補助プラットフォーム | LLMによるストーリー概要、キャラクター設定、セリフ生成 |
|
||||
| 2 | 企業ブランドストーリー・PR記事スマート執筆アシスタント | ブランドキーワードと製品情報の入力による複数スタイルコピーの生成 |
|
||||
| 3 | バーチャルデジタルヒューマンライブ配信・配信管理システム | デジタルヒューマン像モデリング + TTS音声 + LLM対話 |
|
||||
| 4 | ショートビデオスクリプト生成・スマート編集 | LLMによるショートビデオスクリプトと絵コンテの生成 |
|
||||
| 5 | 営業会話音声書き起こし・トーク推薦 | 通話ASR書き起こし、LLMによる会話分析と金牌トークの推薦 |
|
||||
| 6 | マーケティングコンテンツスマート生成・デザインシステム | 製品情報入力によるマーケティングコピーとセールスポイントの抽出 |
|
||||
| 7 | マルチプラットフォーム広告出稿ROIリアルタイム監視・戦略最適化システム | 広告プラットフォームAPI連携によるデータ収集、LLMによる出稿効果の分析 |
|
||||
| 8 | 検索エンジンキーワード・トラフィック分析 | Baidu指数、5118データ収集、LLMによるキーワードトレンドと競合度の分析 |
|
||||
| 9 | 競合広告出稿分析プラットフォーム | サードパーティデータプラットフォームAPIによる競合広告の収集 |
|
||||
| 10 | 全网ホットトピックスマート分析・コンテンツ推薦システム | Weiboホット検索、抖音トレンドデータ収集、LLMによるトレンド分析 |
|
||||
|
||||
## 10. スマート行政
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 12345行政窓口スマート音声ナビ・自動振り分けシステム | 市民からの通話音声認識、LLMによる要望の理解と対応部門へのスマート振り分け |
|
||||
| 2 | 行政サービスホールスマート案内・政策QAロボット | 行政ナレッジベースのRAG検索、LLMによる手続きと政策問題への回答 |
|
||||
| 3 | 企業支援政策スマートマッチング・精密配信プラットフォーム | 政策の構造化解析、企業プロファイルによる適用政策の自動マッチング |
|
||||
| 4 | 行政審査書類スマート事前審査・コンプライアンス検証アシスタント | 書類OCR認識とキー情報抽出、LLMによる完全性とコンプライアンスの検証 |
|
||||
| 5 | 公共安全ビデオ監視異常行動検出システム | ビデオストリームのリアルタイム分析、CVモデルによる異常行動（喧嘩、転倒など）の検出 |
|
||||
| 6 | 都市グリッドイベントスマート識別・配車管理プラットフォーム | 都市センシングデータ（IoT、カメラ）の収集、LLMによるイベントタイプの識別と配車 |
|
||||
| 7 | 世論民意大数据分析・リスク早期警戒システム | 行政窓口、ネットレピュテーション、世論訪問等多ソースデータの融合分析 |
|
||||
| 8 | 行政アーカイブデジタル化識別・スマート分類管理プラットフォーム | OCRによるアーカイブ文字内容の認識、LLMによるキー情報の抽出と自動分類 |
|
||||
| 9 | 突発公共イベント緊急指揮・救援資源スマート配車プラットフォーム | イベント情報の収集、LLMによる緊急対応策の生成 |
|
||||
| 10 | 大気環境汚染グリッド化監視・精密発生源特定システム | 空気質量センサーデーデータの収集、CVモデルによる汚染源の識別 |
|
||||
|
||||
## 11. 法律事務・契約管理
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 契約リスク脆弱性ワンクリック「間違い探し」Agent | 契約テキストの構造化解析、リスクチェックリストとの照合による潜在的問題の識別 |
|
||||
| 2 | 企業契約ライフサイクルコンプライアンス審査・修正提案プラットフォーム | 契約条項と法規データベースの照合、コンプライアンス審査レポートの生成 |
|
||||
| 3 | 類似案件勝訴率AIスマート評価コンサルタント | 案件特徴抽出、類似案件の検索マッチング |
|
||||
| 4 | 法規変更リアルタイム監視・業務影響分析レーダー | 法規データベースのリアルタイム更新、変更内容の解析と業務影響の評価 |
|
||||
| 5 | 弁護士レターAIGC自動起案ツール | 事実陳述入力による規範的な弁護士レターの生成 |
|
||||
| 6 | 法廷録音リアルタイム書き起こし・争点焦点自動抽出記録儀 | 法廷録音ASR書き起こし、LLMによる争点焦点とキー論点の抽出 |
|
||||
| 7 | 全网知的財産権侵害手がかり自動監視・ブロックチェーン証拠システム | ECプラットフォーム、ソーシャルメディアの侵害監視 |
|
||||
| 8 | LLMベースのIPO目論見書キーデータ一貫性チェック・リスク早期警戒Agent | 目論見書複数章節のデータ照合、不一致とデータ異常の識別 |
|
||||
| 9 | 複雑な法律条項「翻訳」を平易な言葉にする解説プラグイン | 選択した法律条文に対する分かりやすい解説の生成 |
|
||||
| 10 | 案件証拠チェーンスマート整理・ビジュアル表示システム | 証拠資料のアップロード、LLMによる証拠関係とタイムラインの分析 |
|
||||
|
||||
## 12. 旅行・外出サービス
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | AIGCベースのラク旅ガイドジェネレーター | ユーザー設定（日数、予算、興味）の入力、毎日の旅程スケジュールの生成 |
|
||||
| 2 | 全网航空券・ホテル価格トレンド予測・低価格自動ロックボット | OTA価格データの収集、MLモデルによる価格トレンド予測 |
|
||||
| 3 | 航班欠航後のクロス航空会社旅程再構成・緊急方案推薦コンサルタント | 航班ステータス監視、LLMによる代替旅程方案の分析 |
|
||||
| 4 | ビザ書類スマート事前審査・自動フォーム記入補助システム | 書類写真のアップロード、OCR認識による情報完全性チェック |
|
||||
| 5 | 海外旅行リアルタイム音声翻訳・メニュー視覚中国語化マネージャー | オフライン音声翻訳モデル、メニュー画像OCR認識と翻訳 |
|
||||
| 6 | 大データ実評価に基づくホテル「避雷」ガイド分析儀 | ホテルレビューデータの収集、LLMによるポジネガティブ評価キーワードの抽出 |
|
||||
| 7 | 目的地没入型VRプレビュー・バーチャル部屋選択インタラクティブプラットフォーム | 360度パノラマ写真の収集、VR技術による没入型プレビュー |
|
||||
| 8 | 旅行足迹自動生成精美旅行記・SNS投稿アシスタント | 写真の時間・場所情報の抽出、LLMによる旅行記文案の生成 |
|
||||
| 9 | 企業出張請求書自動集約・コンプライアンス精算管理プラットフォーム | 出張プラットフォームAPI連携、請求書情報の自動収集 |
|
||||
| 10 | 景区混雑リアルタイム予測・時間差観光ルート計画ナビ | 景区混雑データの収集、MLモデルによる混雑時間帯の予測 |
|
||||
|
||||
## 13. エモーショナルコンパニオン
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | LLMベースの24時間深層コンパニオン仮想パートナー | 記憶システムによる対話履歴の保存、LLMによるパーソナライズ返信の生成 |
|
||||
| 2 | マルチモーダル感情認識・心理カウンセリングAIコンサルタント | 音声トーン分析 + テキスト感情認識、LLMによるカウンセリング提案の生成 |
|
||||
| 3 | アルツハイマー老人AI認知訓練・記憶想起デジタルヒューマン | 認知ゲーム（記憶、計算、言語）訓練；古い写真/古い曲による記憶想起 |
|
||||
| 4 | 社交不安のAIGCシミュレーション社交練習コーチ | バーチャル社交シーンのシミュレーション、LLMが異なる役割を演じる |
|
||||
| 5 | 生成式AI児童就寝前物語カスタマイズ機 | 親のテーマと好みの入力によるカスタマイズ物語の生成 |
|
||||
| 6 | 逝者デジタルライフ復元・LLM時空間対話システム | 生前の資料（音声、テキスト）によるパーソナライズモデルの訓練 |
|
||||
| 7 | MBTIデータベースのAI性格ミラー・共感チャットボット | MBTIテスト結果入力、LLMによる性格分析と共感返信の生成 |
|
||||
| 8 | 全天候気分監視・AIポジティブ感情モチベーションアシスタント | 日常の気分状態の記録、LLMによるトレンドの分析とモチベーションコンテンツの生成 |
|
||||
| 9 | プライバシー保護級青少年AI悩みポスト | 匿名で悩みを吐き出す入口、LLMによる傾聴とアドバイス |
|
||||
| 10 | 自律進化能力を持つAI仮想ペット育成システム | ペット性格モデルの訓練、対話インタラクションによる成長進化 |
|
||||
|
||||
## 14. レジャー・エンターテインメント
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | LLM駆動のオープンワールドゲームNPC自律意思決定エンジン | NPC行動木とLLM意思決定の融合、対話システムによるパーソナライズインタラクション |
|
||||
| 2 | 没入型マーダーミステリーAIGCストーリー推演・DMコントロール補助ツール | プレイヤーの選択によるストーリー分岐のトリガー、LLMによる推理ロジックの生成 |
|
||||
| 3 | インタラクティブ小説エンディング生成式修飾器 | 読者の選択がストーリーの方向性に影響 |
|
||||
| 4 | 二次元キャラクター3DモデリングAIGC自動生成ワークベンチ | テキスト記述によるキャラクターのスケッチ生成、3Dモデリングツールによる自動モデリング |
|
||||
| 5 | eスポーツ戦局CVビジュアル分析・AIスマート実況アナウンサー | ゲーム画面のリアルタイム分析、キーモメントの識別 |
|
||||
| 6 | パーソナライズユーモアコンテンツ推薦アルゴリズムエンジン | ユーザー興味プロファイリング、ユーモアコンテンツのマッチング推薦 |
|
||||
| 7 | AIスマート音調・KTV人声美化ソフトウェア | オーディオノイズ除去と人声強調処理 |
|
||||
| 8 | 映画ドラマキャラクター専用ストーリーAI抽出・編集ツール | ビデオコンテンツ分析、キャラクター関連シーンの抽出 |
|
||||
| 9 | マルチキャラTTS音声合成オーディオブック自動生成システム | テキストのキャラクター割り当て、パーソナライズ音色の生成 |
|
||||
| 10 | ボードゲーム強化学習対局リプレイコーチ | 棋局分析、AI対手によるシミレーション対局 |
|
||||
|
||||
## 15. ECサービス
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 高コンバージョンAIGC商品詳細ページ一括生産ツール | 商品情報入力によるセールスポイントコピーとシーン記述の生成 |
|
||||
| 2 | アパレルバーチャルモデルAIスマート試着・展示動画生成ファクトリー | アパレル平置き画像処理、バーチャルモデル試着効果の生成 |
|
||||
| 3 | 越境EC多言語LLMローカライズ翻訳・ブラッシュアップアシスタント | 商品説明の多言語翻訳、文化的適応ブラッシュアップ |
|
||||
| 4 | NLPベースの顧客感情分析・スマート返信ロボット | コンサルティング対話の感情分析、自動返信の生成 |
|
||||
| 5 | 24時間全天候AIGCデジタルヒューマンライブ配信システム | デジタルヒューマン像 + リアルタイムトーク生成 |
|
||||
| 6 | 全网同種商品AI比価・トレンド予測プラグイン | ECプラットフォーム価格クローリング、比価チャート表示 |
|
||||
| 7 | 買い者レビュー画像AIスマート選別・ショートビデオ合成プラットフォーム | 買い者レビュー画像の品質スコアリング |
|
||||
| 8 | LLMベースのリアルタイム販売対話音声分析・金牌トーク推薦 | 通話ASR書き起こし、リアルタイムトークコンプライアンス検出 |
|
||||
| 9 | 市場トレンドAIインサイト・爆売り予測エンジン | ソーシャルメディアとECデータの収集分析、LLMによるトレンドホットの洞察 |
|
||||
| 10 | 私域トラフィックユーザープロファイルAIクラスタリング・精密運営システム | ユーザー行動データクラスタリング分析、プロファイルタグの生成 |
|
||||
|
||||
## 16. エネルギー
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 家庭電力使用行動AI分析・省エネ戦略コンサルタント | スマート電力メーターデータの収集、電力使用パターンの分析 |
|
||||
| 2 | 太陽光パネル欠陥ドローンCVビジュアル識別システム | ドローン巡回撮影、熱赤外画像分析 |
|
||||
| 3 | 電力スポット取引価格AIトレンド予測・自動利益戦略Agent | 電力市場データ収集、価格予測モデル |
|
||||
| 4 | 蓄電池健康度AI非破壊検出・熱暴走リスク早期警戒システム | バッテリー運行データの監視、健康度評価モデル |
|
||||
| 5 | 企業全チェーンカーボン排出AI自動算定・ESGレポート生成アシスタント | エネルギー消費データの収集、カーボン排出因子の計算 |
|
||||
| 6 | 電網異常気象負荷AI予測・緊急配車指揮システム | 気象データ連携、負荷予測モデル |
|
||||
| 7 | ガソリンスタンド違反行為AIビデオ識別・アラームガードマン | ビデオ監視分析、違反行為（電話、喫煙など）の検出 |
|
||||
| 8 | 長距離石油ガスパイプライン漏洩音波AI監視・精密位置特定システム | 音波センサーデーデータの収集、漏洩検出モデル |
|
||||
| 9 | バーチャル発電所リソース統合・AI電力取引意思決定システム | 分散型リソースの接続、統合最適化配車 |
|
||||
| 10 | 鉱山人员位置AI追跡・危険エリア侵入アラーム | UWB/Bluetooth位置測定、人员軌跡の追跡 |
|
||||
|
||||
## 17. 音声・動画
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | 長編動画ハイライトAI識別・ショートビデオ自動編集ツール | ビデオコンテンツ分析、キーフレーム識別 |
|
||||
| 2 | ビデオ背景ノイズAIスマート分離・音声強調アシスタント | オーディオ分離モデル、背景ノイズ除去 |
|
||||
| 3 | 古い映像4Kアップスケーリング修復・AIスマート着色ワークベンチ | ビデオ超解像度モデル、古い画質の修復 |
|
||||
| 4 | テキストからリアルレベルTTS吹き替え・感情制御システム | マルチ音色TTSモデル、感情制御生成 |
|
||||
| 5 | ビデオ音声ASR自動認識・バイリンガル字幕生成ツール | 音声認識による字幕生成、多言語翻訳 |
|
||||
| 6 | ビデオ画面余分物体AIスマート消去エンジン | ビデオターゲット追跡、物体除去修復 |
|
||||
| 7 | 著作権フリーバックグラウンドAIGC自動作曲機 | 音楽生成モデル、感情スタイル制御可能 |
|
||||
| 8 | 特定人物音色AIクローン・変声変換ソフトウェア | 少量音声サンプルによる音色モデルの訓練 |
|
||||
| 9 | 脚本ワンクリック絵コンテスクリプト・AI動的プレビデオ生成プラットフォーム | 脚本解析による絵コンテ生成、AIプレビデオの生成 |
|
||||
| 10 | 会議録音AIスマート書き起こし・コアToDo抽出アシスタント | 複数人会議の音声分離書き起こし |
|
||||
|
||||
## 18. AIマーケティング
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | RED爆売りコピーAIGC自動執筆エンジン | トピック入力、LLMによる種草コピーの生成 |
|
||||
| 2 | マーケティングポスターAIスマートレイアウト・マルチサイズ適応ツール | コピー入力、ポスターテンプレートのスマートマッチング |
|
||||
| 3 | ブランドLOGOクリエイティブAIGC生成・VI体系構築プラットフォーム | ブランドキーワード入力、LOGOクリエイティブ生成 |
|
||||
| 4 | 全网ホットAI追跡・トレンドマーケティングクリエイティブ生成アシスタント | ホットデータ収集、LLMによるマーケティング角度の分析 |
|
||||
| 5 | 広告出稿ROIリアルタイム監視・AI予算入札マネージャー | 広告プラットフォームデータ連携、効果分析モデル |
|
||||
| 6 | 競合マーケティング戦略深層解析・AI週報生成器 | 競合コンテンツ収集分析、戦略の抽出 |
|
||||
| 7 | 検索エンジンキーワードAI配置・集客記事一括執筆 | キーワード分析、記事の一括生成 |
|
||||
| 8 | 千人千面パーソナライズマーケティングメールAI執筆エキスパート | ユーザープロファイルデータ、パーソナライズコンテンツ生成 |
|
||||
| 9 | ブランド評判全网監視・レピュテーション危機AI早期警戒レーダー | 全网レピュテーションデータ収集、感情分析 |
|
||||
| 10 | ショートビデオスクリプトクリエイティブAIGC生成・絵コンテガイダンスアシスタント | テーマ入力、スクリプトと絵コンテの生成 |
|
||||
|
||||
## 19. データインテリジェンス
|
||||
|
||||
| 番号 | アプリケーションシーン名 | 実装参考 |
|
||||
| :--: | --- | --- |
|
||||
| 1 | Text-to-SQLベースの自然言語データ検索エンジン | 自然言語のSQLクエリへの変換、結果のビジュアル表示 |
|
||||
| 2 | 対話式BI：一言でビジュアルチャートを生成 | データ要件の記述、チャートの自動生成 |
|
||||
| 3 | スクリーンショットワンクリックExcelテーブル識別ツール | スクリーンショットのアップロード後、VLMによるテーブル構造とデータの認識 |
|
||||
| 4 | 画像・スクリーンショットからExcelテーブルAI識別ツール | 画像OCRによるテーブル構造の認識、データのExcel出力 |
|
||||
| 5 | マルチソース異種構造データナレッジグラフ自動構築 | マルチデータソースの接続、エンティティと関係の抽出 |
|
||||
| 6 | データレポートスマート解読・トレンド分析アシスタント | データレポート画像またはデータ入力、VLMによるチャート内容の解読とトレンド分析 |
|
||||
| 7 | データベーステーブル構造スマート解読・クエリ例生成アシスタント | テーブル名またはフィールド記述の入力、建テーブル説明とサンプルクエリSQLの生成 |
|
||||
| 8 | 企業マスターデータスマート対合・AI重複排除ガバナンス | マルチソースマスターデータのマッチング、重複レコードの識別 |
|
||||
| 9 | データ要件ドキュメントスマートテストケース変換ツール | データ要件記述の入力、LLMによるテストシナリオと検証ケースの生成 |
|
||||
| 10 | データ指標定義スマートQAアシスタント | 指標定義ドキュメントに基づくナレッジベース構築 |
|
||||
@@ -0,0 +1,496 @@
|
||||
---
|
||||
title: 'Jobs to Be Done でユーザーが本当に達成したいことを見極める'
|
||||
description: 'ゼロベースの読者向けの Jobs to Be Done 入門記事。ユーザーは機能を買っているのではなく、特定のシーンでプロダクトを「雇用」して進捗を達成していることを理解し、JTBD でプロダクト方向、インタビュー質問、AI プロンプトを分解する方法を学びます。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 時間</strong>'
|
||||
</script>
|
||||
|
||||
# Jobs to Be Done でユーザーが本当に達成したいことを見極める
|
||||
|
||||
<a id="top-jtbd"></a>
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['JTBD', 'ユーザーニーズ', 'プロダクト思考', 'ニーズインサイト']"
|
||||
coreOutput="1 つのよりリアルなニーズに近い JTBD 文"
|
||||
expectedOutput="曖昧なアイデアをより具体的なユーザーシーンと MVP 方向に絞り込める"
|
||||
>
|
||||
|
||||
多くの人が初めてプロダクトを作る時、最も陥りやすい間違いは「自分がどんな機能を作るか」に注意を全部向けてしまうことです。他のプロダクトにスマート分類があれば自分も追加したくなり、自動サマリーがあれば自分も接続したくなり、Agent、マルチモーダル、ワークフローがあれば自分も欠かせないと感じてしまいます。
|
||||
|
||||
しかし現実には、ユーザーが「この機能名がかっこいいから」という理由でプロダクトを使うことはめったにありません。彼らはむしろ特定の場面で、あることを前に進めたいと思い、一時的にツールやサービス、さらには人を「雇用」して、この一歩を完了させようとします。
|
||||
|
||||
これこそが **Jobs to Be Done（JTBD）** という手法が私たちに気づかせようとしていることです：**ユーザーは機能そのものを買っているのではなく、あるソリューションを雇用して、自分の進捗を達成しようとしているのです。**
|
||||
|
||||
本記事はできるだけ分かりやすい言葉で、ゼロから JTBD を理解し、AI アプリケーションを作る際に直接使える分析ツールにするまでを案内します。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：読み終わった後、曖昧なアイデアを本当にユーザーシーンのあるニーズの一文に絞り込む方法がより明確になり、頭の中に機能名の羅列だけが残ることはありません。
|
||||
|
||||
**アクション項目**：曖昧なアイデアを 1 文書き、潜在ユーザー 3 人に「前回どう対処したか」を聞き、それを JTBD 文に整理する。
|
||||
|
||||
**結果**：より明確なニーズ仮説が得られ、初版で何を優先すべきかがわかる。
|
||||
|
||||
**キーワードジャンプ**：[JTBDとは](#jtbd-what) · [一文公式](#jtbd-formula) · [AIの活用法](#jtbd-ai)
|
||||
:::
|
||||
|
||||
## この章で学ぶ内容
|
||||
|
||||
1. Jobs to Be Done とは何か、なぜ「機能ブレスト」よりもリアルなニーズに近いのか
|
||||
2. 「ユーザーが欲しいと言う機能」と「ユーザーが本当に達成したいこと」の区別方法
|
||||
3. 簡単なテンプレートを使って、曖昧なアイデアをシーン、トリガー、障害、成功基準に分解する方法
|
||||
4. JTBD を AI プロダクト、インタビュー質問、プロンプト整理にどう活用するか
|
||||
|
||||
<a id="jtbd-what"></a>
|
||||
## [1. Jobs to Be Done とは何か](#top-jtbd)
|
||||
|
||||
Jobs to Be Done は **JTBD** と略されることが多いです。その背後にある核心的なアイデアは、Clayton Christensen のチームが広めた次の古典的な表現に関連しています：**ユーザーはあるプロダクトを「雇用」して一つのことを完了させる。**
|
||||
|
||||
ここで言う「こと」とは、ToDoリストにあるような表面的な動作ではなく、ユーザーが自分の状態を変えたいと思う一種の **進捗** です。例えば：
|
||||
|
||||
- 「AI 議事録ツールが欲しい」ではなく、「会議後 10 分以内に要点、ToDo、責任者を整理し、もう思い出しながらメモを補完したくない」
|
||||
- 「家計簿 App が欲しい」ではなく、「お金がどこに消えているのかを知りたい、月末に不安を感じたくない」
|
||||
- 「履歴書最適化ツールが欲しい」ではなく、「安心してまともな履歴書を提出したい、毎回提出するたびに自分の書いたものが不十分だと疑いたくない」
|
||||
|
||||
だから、**JTBD が注目するのはプロダクトがどう見えるかではなく、ユーザーがなぜこの瞬間にそれを必要としているのかです。**
|
||||
|
||||
これこそが、一見異なるプロダクトが実際には同じ Job を争っている理由でもあります。ユーザーが「通勤途中で退屈したくない」と思えば、雇用の対象はショート動画、ポッドキャスト、ゲーム、チャット、さらには居眠りかもしれません。ユーザーが「とても長い PDF を素早く理解したい」と思えば、雇用の対象は AI 要約ツール、インターン、同僚、自分で頑張って読む、あるいはとりあえず読まないことかもしれません。
|
||||
|
||||
この視点で問題を見ると、本当の競合相手は「自分と似たような App」だけではなく、**ユーザーの現在受け入れ可能なすべての代替ソリューション** であることに気づくでしょう。
|
||||
|
||||
## 2. JTBD とユーザーペルソナ、機能リストの違い
|
||||
|
||||
多くの初心者が初めてニーズ分析をする時、まずユーザーペルソナを書きます：25 歳、女性、一線都市、ホワイトカラー、効率ツールが好き、新しいプロダクトを試す意欲がある。この情報は全く役に立たないわけではありませんが、通常 **一人がなぜこの瞬間に行動を起こすのかを説明するのには不十分です。**
|
||||
|
||||
JTBD がより関心を持つのは次のような問題です：
|
||||
|
||||
- どんなシーンでソリューションを探すことを決めたのか
|
||||
- その時、何につまずいたのか
|
||||
- 何を次のステップに進めたいのか
|
||||
- 今どんな不器用な方法でやりくりしているのか
|
||||
- もし上手く解決できたら、どんな結果なら「価値があった」と思うのか
|
||||
|
||||
つまり、**ユーザーペルソナは「この人が大体誰か」に近く、JTBD は「この人が今本当に何を達成したいか」に近い** ということです。
|
||||
|
||||
同様に、機能リストも人を誤導しがちです。ユーザーが「Word エクスポートが欲しい」「AI リライトが欲しい」「音声入力が欲しい」と言っても、これらは表面的な表現にすぎません。JTBD はさらに掘り下げます：
|
||||
|
||||
- なぜ今 PDF ではなく Word でエクスポートする必要があるのか？
|
||||
- リライトしたいのは、文章のスタイルが良くないからか、それとも異なる対象に合わせる必要があるからか？
|
||||
- 音声入力が欲しいのは、タイプするのが面倒だからか、それとも歩いている時、運転している時、会議直後にすぐ記録するからか？
|
||||
|
||||
多くの場合、**機能は Job の一時的な翻訳にすぎません**。機能だけを集めると、プロダクトは「ユーザーが言うままに積み上げる」ものになりがちですが、背後にある Job が見えれば、本当に使いやすく、本当に競争力のあるソリューションを作れる可能性がずっと高くなります。
|
||||
|
||||
## 3. ゼロベースでも理解できる例
|
||||
|
||||
まず複雑な AI プロダクトを考えるのは後回しにして、生活の例から始めましょう。
|
||||
|
||||
ある人が朝出かける前にいつも朝食を食べる時間がなく、よく地下鉄の入り口でサンドイッチとコーヒーを買うと仮定します。表面的には彼は「朝食」を「購入」していますが、JTBD で見れば、彼が本当に達成したいことは：
|
||||
|
||||
- 急いでいる朝に、最も頭を使わない方法で一食を済ませる
|
||||
- 会社に着く前に空腹でフラフラにならない
|
||||
- 朝食のために通勤のペースを崩さない
|
||||
|
||||
この時、ユーザーが雇用しているのは「ある特定ブランドのサンドイッチ」ではなく、朝をスムーズに進められるソリューションです。隣のコンビニがより速く、より近く、より安定していれば、彼はすぐに元の選択を変えるかもしれません。
|
||||
|
||||
このロジックを AI プロダクトに持ち込むと、より明白になります。
|
||||
|
||||
例えば「AI 議事録ツール」を作りたいとします。機能のレベルに留まると、すぐに考え始めがちです：
|
||||
|
||||
- 音声アップロードに対応すべきか
|
||||
- 話者分離に対応すべきか
|
||||
- Markdown エクスポートに対応すべきか
|
||||
- 自動 ToDo 生成に対応すべきか
|
||||
|
||||
これらは間違いではありませんが、まだ不十分です。JTBD でもう一段階問い直すと、ユーザーが本当に達成したいのは：
|
||||
|
||||
- 会議後 10 分以内に、議論結果を不参加者に同期したい
|
||||
- ToDo、責任者、締切をきれいに抽出し、チームが記憶に頼ったコラボレーションをしなくて済むようにしたい
|
||||
- 議事録の整理にかかる繰り返しの時間を減らし、意思決定と実行にエネルギーを注ぎたい
|
||||
|
||||
Job が明確になると、多くの機能の優先順位が自動的に見えてきます。初版で最も重要なのは「12 種類のエクスポート形式に対応すること」ではなく、次のようなことかもしれません：
|
||||
|
||||
- 議事録の構造が十分に明確であること
|
||||
- ToDo 抽出が安定していること
|
||||
- 共有リンクが便利であること
|
||||
- 出力結果がチームに直接転送できる信頼性があること
|
||||
|
||||
これこそが JTBD の価値です：**「どの能力を積み上げるか」から「ユーザーのどんな進捗を支援するか」に注意を戻すことができます。**
|
||||
|
||||
## 4. 使いやすい JTBD テンプレート
|
||||
|
||||
ゼロベースなら、JTBD を学術的に考えすぎる必要はありません。まず最も実用的な 5 つの要素を掴めば十分です。
|
||||
|
||||
### 4.1 シーン
|
||||
|
||||
ユーザーはどんな瞬間、どんな環境でこのプロダクトを思い出すのか？
|
||||
|
||||
- 会議が終わった後
|
||||
- 上司が急に資料を求めてきた時
|
||||
- 夜履歴書を提出する準備をしている時
|
||||
- 月末にお金がまた足りないことに気づいた時
|
||||
|
||||
**シーンのないニーズは、通常まだリアルではありません。**
|
||||
|
||||
### 4.2 トリガー
|
||||
|
||||
何が彼にすぐソリューションを探す決意をさせたのか？
|
||||
|
||||
- 長い文書に圧倒され、どこから読めばいいかわからない
|
||||
- 明日提出の資料が、今日になってフォーマットがめちゃくちゃだと気づく
|
||||
- 上司に進捗を追及され、自分が整理しきれていないことに気づく
|
||||
- 記録を続けたいが、手書き、コピー、整理が面倒すぎる
|
||||
|
||||
トリガーには往々にして感情が伴います。この感情は重要です。なぜなら、ユーザーがなぜこの瞬間に行動を起こすのかを決めるからです。
|
||||
|
||||
### 4.3 達成したい進捗
|
||||
|
||||
彼は「一つの動作をする」だけでなく、自分をどんな新しい状態に進めたいのか？
|
||||
|
||||
- 混乱から明確へ
|
||||
- 不安から安心へ
|
||||
- 先延ばしからスタートへ
|
||||
- 非効率からスムーズへ
|
||||
- うまく説明できないから直接届けられるものへ
|
||||
|
||||
このステップで「進捗」という言葉が非常に重要です。なぜなら、多くの人が本当に買っているのはツールではなく、**状態の変化** だからです。
|
||||
|
||||
### 4.4 現在の代替ソリューション
|
||||
|
||||
あなたのプロダクトがない今、彼はどうしているのか？
|
||||
|
||||
- 手作業でコピペ
|
||||
- Excel やメモアプリでやりくり
|
||||
- 同僚に頼る
|
||||
- 先延ばしにする
|
||||
- 複数のツールの間で行き来する
|
||||
|
||||
誰が代替ソリューションか、誰があなたの本当の競争環境か。
|
||||
|
||||
### 4.5 成功基準
|
||||
|
||||
どうなったら本当に解決したと言えるのか？
|
||||
|
||||
- 10 分以内に共有可能な結果が得られる
|
||||
- 大きな修正なしで他人に送れる
|
||||
- 抜け漏れ、ミス、忘れが起こりにくい
|
||||
- 初めて使っても次のステップがわかる
|
||||
|
||||
「ユーザーがどうやって価値を判断するか」すら言えないなら、その方向性はおそらくまだ十分に絞り込まれていません。
|
||||
|
||||
<a id="jtbd-formula"></a>
|
||||
## [5. そのまま使える一文公式](#top-jtbd)
|
||||
|
||||
プロダクトの方向性を整理したい時、まずこの実用的なテンプレートに当てはめてみてください：
|
||||
|
||||
> \_\_\_\_\_\_\_\_\_\_ の時、\_\_\_\_\_\_\_\_\_\_ がしたい、それは \_\_\_\_\_\_\_\_\_\_ のためだ。
|
||||
> 今は \_\_\_\_\_\_\_\_\_\_ でなんとかこのことをやり遂げている。
|
||||
|
||||
例えば：
|
||||
|
||||
> 情報量が多いプロジェクト会議が終わった時、ToDo、責任者、締切を含む議事録を素早く得て、すぐにチームに同期し実行を推進したい。
|
||||
> 今は自分の記憶、チャット履歴の確認、手作業での整理でなんとかやり遂げている。
|
||||
|
||||
もう一つの例：
|
||||
|
||||
> 新しい職種に応募する準備をする時、既存の経歴を職種に合ったバージョンに素早く書き換えて、安心してまともな履歴書を提出したい。
|
||||
> 今は古い履歴書を繰り返しコピペし、言葉を手作業で修正し、最後にはどんどん自信がなくなっている。
|
||||
|
||||
一文をこの明確さまで書ければ、その後の画面設計、プロンプト設計、機能優先度の判断がずっと楽になります。
|
||||
|
||||
## 6. AI プロダクトを作る時、特に注目すべき 3 つのレイヤーの Job
|
||||
|
||||
多くの AI プロダクトは機能デモでは強そうに見えますが、実際にリリースされてもユーザーが定着しないことがよくあります。その一般的な理由は、表面的な動作を解決しただけで、より深い Job を解決していないからです。
|
||||
|
||||
Job は大まかに 3 つのレイヤーに分けて見ることができます：
|
||||
|
||||
### 6.1 機能レイヤー
|
||||
|
||||
最も表面的なタスクは何か？
|
||||
|
||||
- 文書の要約
|
||||
- コピーのリライト
|
||||
- ToDo の抽出
|
||||
- 画像の生成
|
||||
|
||||
これはユーザーが口に出しやすいレイヤーです。
|
||||
|
||||
### 6.2 感情レイヤー
|
||||
|
||||
ユーザーはどんな不快感を減らしたいのか、またはどんな感情を得たいのか？
|
||||
|
||||
- 慌てたくない
|
||||
- プロフェッショナルに見えたい
|
||||
- 毎回ゼロから始めたくない
|
||||
- コントロール感が欲しい
|
||||
|
||||
多くの有料意欲は、実際に感情レイヤーと深く関係しています。
|
||||
|
||||
### 6.3 社会レイヤー
|
||||
|
||||
ユーザーは他人の目にどうなりたいのか？
|
||||
|
||||
- より頼りに見られたい
|
||||
- チームでより組織力があると思われたい
|
||||
- 顧客の前でよりプロフェッショナルに見られたい
|
||||
- SNS でより表現力があると思われたい
|
||||
|
||||
機能レイヤーだけをやっていれば、プロダクトは代替されやすいです。感情レイヤーと社会レイヤーも同時に理解すれば、より粘着性のある価値を見つけやすくなります。
|
||||
|
||||
## 7. JTBD を逆に使ってプロダクト方向を絞り込む
|
||||
|
||||
時にはすでにプロダクトがあるのではなく、3〜5 のアイデアがあって、どれを作るべきかわからないことがあります。この時、JTBD は選別に非常に適しています。
|
||||
|
||||
各アイデアを取り上げて、それぞれに 5 つの質問をすることができます：
|
||||
|
||||
1. このアイデアに対応するシーンは十分に具体的か？
|
||||
2. ユーザーはすでに何らかの不器用な方法で解決しているか？
|
||||
3. この Job の痛みは十分に強いか、または十分に高頻度か？
|
||||
4. もし上手くできたら、ユーザーは明らかに「状態が良くなった」と感じるか？
|
||||
5. 初版はこの Job の重要な一歩だけを囲んで、小さいが有用なバージョンを作れるか？
|
||||
|
||||
ある方向性が最後まで説明しても「面白そう」としか言えず、トリガー、代替ソリューション、成功基準をはっきりと言えないなら、それはおそらくまだ曖昧なインスピレーションであって、成熟した方向性ではありません。
|
||||
|
||||
## 8. そのままユーザーインタビューに使える質問
|
||||
|
||||
多くの人は調査をする時、「どんな機能が欲しいですか？」と聞いてしまいます。この聞き方は表面的な回答を得やすいです。
|
||||
|
||||
JTBD は次のような質問により適しています：
|
||||
|
||||
- 前回この問題に直面したのはいつですか？
|
||||
- その時何をしていて、なぜつまずいたのですか？
|
||||
- 最終的にどう解決しましたか？
|
||||
- このプロセスで一番面倒で、一番遅くて、一番不安なのはどこですか？
|
||||
- もしツールがあれば、どんな結果なら本当に役に立つと思いますか？
|
||||
- どんな代替方法を試しましたか？なぜ十分ではなかったのですか？
|
||||
|
||||
この聞き方には利点があります：会話をリアルな体験に引き戻し、想像上の好みに留まらせないことです。
|
||||
|
||||
## 9. AI に JTBD 分析を手伝ってもらう
|
||||
|
||||
JTBD 自体は AI が発明したものではありませんが、AI は JTBD の整理と洗練に非常に適しています。
|
||||
|
||||
例えば、5〜10 件のユーザーフィードバックを収集したら、それらをモデルに渡して次の構造でまとめてもらうことができます：
|
||||
|
||||
```text
|
||||
プロダクト研究アシスタントを演じてください。
|
||||
ユーザーの生の言葉を渡します。まず機能提案をせず、
|
||||
Jobs to Be Done のフレームワークで整理してください：
|
||||
|
||||
1. ユーザーはどんなシーンにいるか
|
||||
2. 行動を起こすトリガーは何か
|
||||
3. 本当に達成したい進捗は何か
|
||||
4. 現在の代替ソリューションは何か
|
||||
5. 最も重視する成功基準は何か
|
||||
6. これらのフィードバックで繰り返し出現する感情ワードは何か
|
||||
|
||||
最後に、これらを最も優先的に検証すべき 3 つの JTBD 仮説に整理してください。
|
||||
```
|
||||
|
||||
もしすでにアイデアがあるなら、AI に第一段階の絞り込みをしてもらうこともできます：
|
||||
|
||||
```text
|
||||
[あなたのプロダクトアイデア] を作りたい。
|
||||
機能リストを直接出すのではなく、Jobs to Be Done の方法で分析してください：
|
||||
|
||||
1. このプロダクトがサービスする可能性のある具体的なシーンは何か
|
||||
2. 各シーンでユーザーが達成したいコア Job は何か
|
||||
3. 既存の代替ソリューションには何があるか
|
||||
4. どの Job が MVP の出発点として最も適しているか、なぜか
|
||||
5. 最終的に推奨する Job を明確な JTBD 文に書いてください
|
||||
```
|
||||
|
||||
このようにすることで、最初から AI に「50 の機能をブレスト」させるのではなく、方向性をまず明確にできます。
|
||||
|
||||
## 10. 初心者が最も陥りやすい 4 つの誤解
|
||||
|
||||
### 10.1 Job を機能名にしてしまう
|
||||
|
||||
「AI 要約」「スマート分類」「自動生成」は Job ではなく、それらは実現方法の可能性にすぎません。
|
||||
|
||||
### 10.2 ターゲット層を広く書きすぎる
|
||||
|
||||
「すべてのビジネスパーソン」「すべての学生」「すべての起業家」は通常広すぎます。広ければ広いほど、リアルなシーンを見えなくなります。
|
||||
|
||||
### 10.3 ユーザーの言葉だけを聞き、行動を見ない
|
||||
|
||||
ユーザーは自分が何を欲しがっているかを説明できますが、彼らの本当の優先順位は、今どのように問題をやりくりしているかに隠されていることが多いです。
|
||||
|
||||
### 10.4 最初から完全なプラットフォームを作ろうとする
|
||||
|
||||
JTBD の正しい使い方は、通常「何でもできる大きなプラットフォームを作る」ことではなく、まず一つのシーンで最も重要な一歩に注目し、それを非常に使いやすくすることです。
|
||||
|
||||
## 11. まとめ
|
||||
|
||||
Jobs to Be Done の最も価値のある点は、新しい用語を与えることではなく、観察の角度を変えてくれることです：**プロダクトの機能だけを見るのではなく、ユーザーが何を次のステップに進めたいのかを見る。**
|
||||
|
||||
あなたが次のようなことを繰り返し自分に問い始めると：
|
||||
|
||||
- ユーザーはどんなシーンでこのプロダクトを雇用しているのか
|
||||
- 彼は一体どこでつまずいているのか
|
||||
- 今どんな方法でやりくりしているのか
|
||||
- 問題が解決した後、状態はどう変わるのか
|
||||
|
||||
元々曖昧だったアイデアが急にはっきりとし、元々派手だった機能も急に重要ではなくなっていくことに気づくでしょう。
|
||||
|
||||
プロダクトを作る時、特に AI プロダクトを作る時、最も怖しいのは最初から能力展示に夢中になることです。JTBD はあなたの注意を本当に重要なところに引き戻してくれます：**ユーザーはなぜあなたを必要としているのか、そしてあなたは一体ユーザーのどんな進捗を支援しているのか。**
|
||||
|
||||
<a id="jtbd-ai"></a>
|
||||
## [12. AI を活用して JTBD を実践する方法](#top-jtbd)
|
||||
|
||||
JTBD は AI が発明したものではありませんが、AI はこの手法で研究アシスタント、整理アシスタント、対照アシスタントとして非常に適しています。重要なのは：**AI に整理と拡張をさせ、ユーザーの推測をAIに代行させないこと。**
|
||||
|
||||
次のように活用できます：
|
||||
|
||||
### 12.1 AI に曖昧なアイデアを JTBD 仮説に書き直させる
|
||||
|
||||
頭の中に「大学生のインターン探しを支援するツールを作りたい」という曖昧な説明しかない時、まず AI にそれをいくつかの可能性のある Job に分解させることができます：
|
||||
|
||||
```text
|
||||
今、曖昧なプロダクトアイデアがあります：[あなたのアイデア]
|
||||
機能リストを直接出すのではなく、Jobs to Be Done の方法で分析してください：
|
||||
1. どのような具体的なシーンに対応する可能性があるか
|
||||
2. 各シーンでユーザーが本当に達成したい進捗は何か
|
||||
3. 現在の代替ソリューションは何か
|
||||
4. どの Job を最初に MVP にするのが最も適切か
|
||||
最後に各 Job を明確な JTBD 文に書いてください。
|
||||
```
|
||||
|
||||
非常に初心者っぽい入力でも全く問題ありません：
|
||||
|
||||
```text
|
||||
大学生のインターン探しを支援するものを作りたい。
|
||||
具体的に何を作るかまだはっきり言えない。ユーザーが本当に何を達成したいかを考えてみて。
|
||||
```
|
||||
|
||||
AI が返す有用な出力は次のようになります：
|
||||
|
||||
```text
|
||||
可能性のある JTBD 方向：
|
||||
|
||||
1. 初めてインターンに応募する準備をする時、まず何を準備すべきかを素早く知りたい、
|
||||
情報が乱雑で応募を先延ばしにしたくない。
|
||||
|
||||
2. インターンの求人を見た時、自分が応募する価値があるかどうかを素早く判断したい、
|
||||
不適切な求人に時間を無駄にしたくない。
|
||||
|
||||
3. 応募を始める時、既存の履歴書を求人に合ったバージョンに素早く書き換えたい、
|
||||
より早く応募を完了し、通過率を高めたい。
|
||||
```
|
||||
|
||||
このような出力の価値は、元々非常に漠然としていたアイデアを、よりリアルなシーンに近い方向に分解してくれることです。
|
||||
|
||||
### 12.2 AI にインタビューの生の言葉を整理させる
|
||||
|
||||
すでに何度かユーザーインタビューを終えたなら、インタビュー記録を AI に渡して、繰り返し出現するシーン、トリガー、代替ソリューション、成功基準を抽出させることができます。
|
||||
|
||||
```text
|
||||
以下は 5 人のユーザーのインタビュー生の言葉です。
|
||||
まずソリューションを出さず、JTBD フレームワークで整理してください：
|
||||
1. ユーザーはどんなシーンにいるか
|
||||
2. 行動を起こすトリガーは何か
|
||||
3. 本当に達成したい進捗は何か
|
||||
4. 現在の代替ソリューションは何か
|
||||
5. 最も重視する成功基準は何か
|
||||
6. どの情報が複数のユーザーで繰り返し出現しているか
|
||||
最後に、最も優先的に検証すべき 3 つの JTBD 仮説に整理してください。
|
||||
```
|
||||
|
||||
非常にシンプルな初心者入力も次のように書けます：
|
||||
|
||||
```text
|
||||
3 人に聞きました。大体こんな風に言っていました：
|
||||
|
||||
1. 毎回インターンに応募するたびに履歴書を書き直すのが本当に面倒。
|
||||
2. 一番怖いのは、自分が書いたものが正しいかどうかわからないこと。
|
||||
3. 今は先輩に見てもらうようにしているけど、毎回頼むのは申し訳ない。
|
||||
|
||||
彼らが本当に達成したいことを整理して。
|
||||
```
|
||||
|
||||
AI は次のように出力するかもしれません：
|
||||
|
||||
```text
|
||||
整理結果：
|
||||
|
||||
- 共通シーン：インターン応募前の履歴書処理
|
||||
- 共通の困難：「十分良い」までどう修正すればいいかわからない
|
||||
- 現在の代替ソリューション：先輩に見てもらう、自分で繰り返し修正
|
||||
- 可能な JTBD：
|
||||
インターンに応募する準備をする時、履歴書が応募可能なレベルに達しているかをより早く判断したい、
|
||||
「もう少し修正」でずっと応募できずにいる状況から抜け出したい。
|
||||
```
|
||||
|
||||
このような出力は、散らばった生の言葉から「ニーズ」により近いものを抽出してくれるので、非常に有用です。
|
||||
|
||||
### 12.3 AI に軽量なウェブ調査を先に行わせる
|
||||
|
||||
大規模なインタビューを始める前に、AI に少し軽い外部情報スキャンをさせることができます。例えば：
|
||||
|
||||
- 公開フォーラムやコミュニティで、皆がこの問題にどう不満を漏らしているか
|
||||
- 市場の既存プロダクトが主にどのレベルの問題を解決しているか
|
||||
- ユーザーの最も一般的な代替ソリューションは何か
|
||||
- 一般的な評価で、最も満足されている点と最も不満な点は何か
|
||||
|
||||
この調査はリアルなユーザーインタビューに代わるものではありませんが、Discover 段階のウォームアップとして、問題の地図を先に構築するのに非常に適しています。
|
||||
|
||||
シンプルな入力は次のようなものです：
|
||||
|
||||
```text
|
||||
調べてほしいことがあります：
|
||||
「大学生が履歴書を修正してインターンに応募する時、最もよくあるペインポイントは何？」
|
||||
公開フォーラム、経験談、就職コミュニティで皆が自分で言っていることを優先的に見てください。
|
||||
最も一般的な問題を 5 つに整理して。
|
||||
```
|
||||
|
||||
AI は次のように出力するかもしれません：
|
||||
|
||||
```text
|
||||
よくあるペインポイントの整理：
|
||||
|
||||
1. 履歴書に何を書けばいいかわからない、経歴が少なすぎる
|
||||
2. 異なる職種に合わせてどう修正すればいいかわからない
|
||||
3. 何度も修正したが、まだ十分かどうかわからない
|
||||
4. 信頼できる人に見てもらえない
|
||||
5. 応募プロセスが複雑で、先延ばしにしがち
|
||||
```
|
||||
|
||||
この種の出力は最終結論として扱うべきではありませんが、どの問題を優先してインタビューするかを決めるのに非常に適しています。
|
||||
|
||||
### 12.4 AI に「反論者」を演じさせる
|
||||
|
||||
多くの場合、私たちは自分のアイデアに感情を入れすぎてしまいます。意図的に AI に批判者を演じさせ、問題をより明確に説明するよう促すことができます：
|
||||
|
||||
```text
|
||||
非常に厳しいプロダクト研究コンサルタントを演じてください。
|
||||
以下は私の JTBD 仮説です：[あなたの仮説]
|
||||
次の観点から批判してください：
|
||||
1. このシーンは広すぎないか
|
||||
2. この Job は機能であり、本当に進捗であるかどうか
|
||||
3. 代替ソリューションが弱すぎないか
|
||||
4. 成功基準が不明確ではないか
|
||||
5. この仮説で最も検証が必要なリスクは何か
|
||||
```
|
||||
|
||||
このようにすることで、自分がニーズを見ているのか、それともただ自分が好きなソリューションを見ているのかをより早く発見できます。
|
||||
|
||||
## 📚 課題
|
||||
|
||||
上記の内容に基づいて、次の課題を完了してください：
|
||||
|
||||
1. 最近やりたいプロダクトアイデアを一つ選び、JTBD 公式の一文で明確に書く
|
||||
2. このアイデアに 5 つの要素を補完する：シーン、トリガー、進捗、代替ソリューション、成功基準
|
||||
3. 潜在ユーザー 3 人に聞き、「前回この問題に直面したのはいつですか」を少なくとも 1 回は聞き出す
|
||||
4. インタビューの生の言葉を AI に渡し、最も優先的に検証すべき 3 つの JTBD 仮説に整理する
|
||||
|
||||
## さらに学ぶために
|
||||
|
||||
- [Christensen Institute: Jobs to Be Done](https://www.christenseninstitute.org/theory/jobs-to-be-done/)
|
||||
- [Harvard Business School Online: What Is Jobs to Be Done?](https://online.hbs.edu/blog/post/jobs-to-be-done)
|
||||
- [Intercom: Jobs-to-be-Done: A framework for customer needs](https://www.intercom.com/blog/jobs-to-be-done-framework/)
|
||||
- [Mural: Jobs to Be Done framework guide](https://www.mural.co/blog/jobs-to-be-done-framework)
|
||||
@@ -0,0 +1,589 @@
|
||||
---
|
||||
title: 'The Mom Test：ユーザーインタビューでニーズを検証する方法'
|
||||
description: 'ゼロベースの読者向けの The Mom Test 入門記事。礼儀正しいフィードバックを避け、実際の行動、具体的な事実、既存の問題を中心にユーザーインタビューを行い、「良さそう」をより確実なニーズ判断に変える方法を学びます。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 時間</strong>'
|
||||
</script>
|
||||
|
||||
# The Mom Test：ユーザーインタビューでニーズを検証する方法
|
||||
|
||||
<a id="top-mom"></a>
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['ユーザーインタビュー', 'ニーズ検証', 'ユーザーリサーチ', 'プロダクト調査']"
|
||||
coreOutput="1 組のよりリアルな情報を引き出せるインタビュー質問"
|
||||
expectedOutput="ユーザーの礼儀正しい励ましを検証とみなさず、実際の行動で方向性を判断できる"
|
||||
>
|
||||
|
||||
多くの人が初めてプロダクト調査をする時、最も重要なのは「人に話を聞くこと」だと思いがちです。そこで友達や同僚、さらには家族に聞いてみます：
|
||||
|
||||
- このアイデア、どう思う？
|
||||
- こんなプロダクトがあったら、使う？
|
||||
- この機能、悪くないよね？
|
||||
|
||||
相手もとても励みになるフィードバックをくれるでしょう：
|
||||
|
||||
- いいね
|
||||
- 役に立ちそう
|
||||
- 試してみたらいいと思う
|
||||
|
||||
問題は、これらの回答は通常、判断に役立たないということです。それはむしろ礼儀、サポート、あるいはその場で盛り上げようとする自然な反応に近いものです。自分が「市場検証」を得たと思っても、実際には判断に使いづらい慰めを集めただけなのです。
|
||||
|
||||
The Mom Test という手法は、まさにこの問題を解決するためのものです。それは私たちに注意喚起します：**ユーザーがわざと嘘をついているのではなく、あなたの質問の仕方が、自然と相手を聞こえの良いが無難な回答に導いているのです。**
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：読み終わった後、ユーザーとどう話せば「良さそう」しか聞けない会話から、方向性を判断できる情報を引き出せるかがより明確になります。
|
||||
|
||||
**アクション項目**：本来聞こうとしていた 5 つの質問を書き直し、「最近いつありましたか」「その時どうしましたか」を優先して聞くようにします。
|
||||
|
||||
**結果**：どれが意見で、どれが本当に判断を支える証拠なのかを見分けやすくなります。
|
||||
|
||||
**キーワードジャンプ**：[The Mom Testとは](#mom-what) · [3つの核心原則](#mom-principles) · [AIの活用法](#mom-ai)
|
||||
:::
|
||||
|
||||
## この章で学ぶ内容
|
||||
|
||||
1. The Mom Test が一体何を解決しようとしているのか、なぜ多くの「ユーザー調査」が実際にはリアルな情報を調査できていないのか
|
||||
2. この手法の最も核心的ないくつかの原則：意見を聞くのを減らし、行動を聞くのを増やす；仮定を聞くのを減らし、事実を聞くのを増やす
|
||||
3. 偽陽性フィードバックを得やすい質問を、より価値のあるインタビュー質問に書き直す方法
|
||||
4. The Mom Test と JTBD、ニーズ検証、MVP 判断をどう組み合わせて使うか
|
||||
|
||||
<a id="mom-what"></a>
|
||||
## [1. The Mom Test とは一体何か](#top-mom)
|
||||
|
||||
The Mom Test は Rob Fitzpatrick の同名の著書に由来します。その名前は冗談のように聞こえますが、非常に的確に指摘しています：
|
||||
|
||||
**あなたのお母さんでさえ、「それはダメなアイデアだ」とは直接言えないのです。**
|
||||
|
||||
その理由は彼女が不誠実だからではなく：
|
||||
|
||||
- あなたを傷つけたくない
|
||||
- 無意識にあなたを励ましたくなる
|
||||
- あなたの表現に沿って答えやすくなる
|
||||
|
||||
実はお母さんだけではなく、友達、同僚、昔の同級生、さらには多くの見知らぬ人も、あなたのプロダクトアイデアに直面すると、似たような「ポジティブなフィードバック」をよくくれます。これはニーズが本当に存在するという意味ではなく、あなたが質問を誰もが賛同しやすい形にしてしまっているだけです。
|
||||
|
||||
だから The Mom Test のポイントは決して「お母さんに聞くな」ではなく：
|
||||
|
||||
**質問を誰もがあなたに同調して答えるような形にしないことです。**
|
||||
|
||||
この手法が本当に教えたいのは、対話を通じて、よりリアルなニーズに近い情報を手に入れる方法であり、自分を気分よくさせるコメントを集めることではありません。
|
||||
|
||||
## 2. この手法が解決する核心的な問題
|
||||
|
||||
The Mom Test が主に解決するのは、非常に一般的な認知の錯覚です：
|
||||
|
||||
**礼儀正しいポジティブなフィードバックを、リアルなニーズと混同してしまう。**
|
||||
|
||||
例えばあなたが聞くと：
|
||||
|
||||
- この App のアイデア、どう思う？
|
||||
- AI で履歴書を書くツールがあったら、使う？
|
||||
- この機能、価値あるでしょ？
|
||||
|
||||
これらの質問に共通する特徴は：
|
||||
|
||||
- すべて「意見」を聞いている
|
||||
- すべて少し暗示を含んでいる
|
||||
- すべてまだ起きていない未来について話している
|
||||
|
||||
そして「意見」と「未来の仮定」に対する回答は、通常不安定です。多くの人は自分の興味、実行力、将来の購入意欲を過大評価しがちです。
|
||||
|
||||
だから The Mom Test は注意を促します：
|
||||
|
||||
- 他人のあなたのアイデアに対する評価をあまり信用しない
|
||||
- 他人の未来の行動予測をあまり信用しない
|
||||
- できるだけユーザーのすでに起こった実際の行動に戻る
|
||||
|
||||
「使うかどうか」よりも「前回どう対処したか」のほうが、真実に近いことが多いからです。
|
||||
|
||||
<a id="mom-principles"></a>
|
||||
## [3. 3つの最も核心的な原則](#top-mom)
|
||||
|
||||
最も重要な部分だけを先に覚えたいなら、次の 3 つの原則を先に覚えてください。
|
||||
|
||||
### 3.1 自分のアイデアについて話すのを減らし、ユーザーの過去のリアルな体験について話す
|
||||
|
||||
多くの無効なインタビューは冒頭で自分のソリューションを語り、自分がどれだけ興奮しているか、どんなプロダクトを作ろうとしているかを話します。問題は、あなたが話しすぎると、相手が「あなたに合わせる」「あなたを励ます」モードに入りやすくなることです。
|
||||
|
||||
それに対して、より良い方法は相手の体験に焦点を当てることです：
|
||||
|
||||
- 前回この問題に直面したのはいつですか？
|
||||
- その時何をしていましたか？
|
||||
- 最終的にどう対処しましたか？
|
||||
- どの手順が一番面倒でしたか？
|
||||
|
||||
この種の質問は、想像上の好みに留まることなく、より自然に会話を現実に引き戻せることに気づくでしょう。
|
||||
|
||||
### 3.2 抽象的な意見を聞くのを減らし、具体的な事実を聞く
|
||||
|
||||
「この機能は良さそう」「悪くないね」「ちょっと役立ちそうかも」、これらの表現はあまりに抽象的で、プロダクトの判断に役立ちません。
|
||||
|
||||
より価値のある情報は通常、次のようなものです：
|
||||
|
||||
- 先週この件に 2 時間悩まされました
|
||||
- 今は Excel と WeChat でなんとかやりくりしています
|
||||
- 先月似たようなツールにお金を払いました
|
||||
- 一番怖いのは間違えることではなく、遅くなることです
|
||||
|
||||
これらこそが、問題の強度、頻度、有料化の可能性を判断するのに本当に役立つ情報です。
|
||||
|
||||
### 3.3 ユーザーがどんなソリューションを欲しがっているか聞くのを減らし、今どう問題を解決しているか見る
|
||||
|
||||
ユーザーは自分の悩みを説明するのは得意ですが、ソリューションを設計するのは必ずしも得意ではありません。
|
||||
|
||||
もし聞くと：
|
||||
|
||||
- AI がこれを自動でやってくれる機能、欲しくない？
|
||||
- スマート機能を追加するのって役立つ？
|
||||
|
||||
得られるのは通常、あるソリューションに対する曖昧な態度だけであり、ニーズそのものではありません。
|
||||
|
||||
より良い質問は：
|
||||
|
||||
- 今、この問題にどう対処していますか？
|
||||
- なぜこの方法を選んだのですか？
|
||||
- どこが良くないですか？
|
||||
|
||||
既存の代替ソリューションを見極めることは、「何を欲しがっているか」を直接聞くよりも重要なことが多いのです。
|
||||
|
||||
## 4. なぜ人々はいつも聞こえは良いが役に立たない回答をするのか
|
||||
|
||||
これが理解できれば、インタビューでの誤判断が大幅に減ります。
|
||||
|
||||
### 4.1 人は無意識に礼儀正しさを保つ
|
||||
|
||||
特に会話の相手と関係がある場合、相手は直接言いにくいものです：
|
||||
|
||||
- この方向、ちょっと無理そう
|
||||
- 全然使わない
|
||||
- この問題はそこまで重要じゃない
|
||||
|
||||
むしろ「いいね」「機会があればやってみてもいいかも」と言いがちです。
|
||||
|
||||
### 4.2 人は未来の自分を過大評価する
|
||||
|
||||
多くの人が心から未来の自分を信じています：
|
||||
|
||||
- もっと自律的になる
|
||||
- もっと学ぶ意欲がある
|
||||
- もっとお金を払う
|
||||
- もっと新しいツールを試す
|
||||
|
||||
だから「あればたぶん使う」という言葉は、未来に本当に使うこととイコールではないことが多いのです。
|
||||
|
||||
### 4.3 質問の仕方自体が答えを誘導している
|
||||
|
||||
あなたが聞くとき：
|
||||
|
||||
- このアイデア、いいよね？
|
||||
- この機能、役に立つでしょ？
|
||||
|
||||
あなたは実はこっそり「正解」を質問に忍ばせているのです。
|
||||
|
||||
これこそが The Mom Test が特に強調している理由です：**インタビューを自分への承認探しにしないこと。**
|
||||
|
||||
## 5. 直接比較：どんな質問が無駄になりやすく、どんな質問がより価値があるか
|
||||
|
||||
以下の対照表は、ほぼすべての初心者が使うものです。
|
||||
|
||||
| 無駄になりやすい質問 | より価値のある質問 |
|
||||
| --- | --- |
|
||||
| このアイデア、どう思う？ | 前回この問題に直面したのはいつ？ |
|
||||
| このプロダクトがあったら使う？ | 今、この件をどう処理している？ |
|
||||
| この機能にお金を払う？ | 前回この問題にお金を使った？何に？ |
|
||||
| この機能は重要だと思う？ | このプロセスで一番面倒で、一番遅くて、一番不安なのはどの手順？ |
|
||||
| AI が自動でやってくれる機能、欲しくない？ | なぜまだもっと使いやすい解決策を見つけられていないの？ |
|
||||
|
||||
この表で最も重要なのは具体的な文ではなく、背後にある方向性です：
|
||||
|
||||
- 意見から事実へ
|
||||
- 未来から過去へ
|
||||
- あなたのソリューションからユーザーの問題へ
|
||||
|
||||
## 6. ゼロベースでもすぐに使えるインタビューの流れ
|
||||
|
||||
今すぐ誰かに話を聞きに行きたいなら、次の順序で進められます。
|
||||
|
||||
### 6.1 オープニング：学習しているのであって、売り込んでいるのではないと伝える
|
||||
|
||||
例えば：
|
||||
|
||||
> 最近、皆さんがこの種の問題にどう対処しているかを調べていて、まずリアルな状況を知りたいと思っています。売り込みではありません。
|
||||
|
||||
このような表現は、相手が「ポジティブなフィードバックをあげなきゃ」という心理的負担を減らすのに役立ちます。
|
||||
|
||||
### 6.2 最近のリアルな体験から聞き始める
|
||||
|
||||
まず次のような質問から始められます：
|
||||
|
||||
- 前回この問題に直面したのはいつですか？
|
||||
- その時何が起きましたか？
|
||||
- 最初の反応はどう対処しましたか？
|
||||
|
||||
会話が具体的な出来事に入ると、情報の質は通常明らかに向上します。
|
||||
|
||||
### 6.3 行動、コスト、代替ソリューションについて掘り下げる
|
||||
|
||||
引き続き聞きます：
|
||||
|
||||
- 今、どうやって解決していますか？
|
||||
- この方法で一番不満なのは何ですか？
|
||||
- このためにどれくらいの時間、お金、または労力を費やしましたか？
|
||||
- 他の方法を試したことはありますか？なぜ続けなかったのですか？
|
||||
|
||||
### 6.4 最後に痛みの強さと優先度を判断する
|
||||
|
||||
「痛いですか」と直接聞く必要はなく、詳細から判断できます：
|
||||
|
||||
- よく直面しているか
|
||||
- すでに自発的に対処しようとしているか
|
||||
- すでにコストを払う意欲があるか
|
||||
- この話をしている時に明らかな感情が表れているか
|
||||
|
||||
これらはすべて「これがあなたのペインポイントですか」という一言よりも役立ちます。
|
||||
|
||||
## 7. より完全な例
|
||||
|
||||
「AI で大学生の履歴書を添削する」プロダクトを作りたいと仮定しましょう。
|
||||
|
||||
### 誤った聞き方
|
||||
|
||||
同僚に聞きます：
|
||||
|
||||
> AI 履歴書最適化ツールを作ろうと思うんだけど、どう思う？
|
||||
> もし職種に合わせて自動で履歴書を修正できたら、使う？
|
||||
|
||||
この時、相手はこう言う可能性が高いです：
|
||||
|
||||
- 良さそう
|
||||
- 役に立ちそう
|
||||
- 無料なら試すかも
|
||||
|
||||
これらの回答はニーズがどれほど強いかを判断するのにほとんど役立ちません。
|
||||
|
||||
### より良い聞き方
|
||||
|
||||
次のように変えられます：
|
||||
|
||||
> 前回履歴書を修正したのはいつ？
|
||||
> その時なぜ修正したの？
|
||||
> どうやって修正したの？
|
||||
> どの手順が一番詰まった？
|
||||
> 誰かに見てもらったことはある？
|
||||
> 履歴書のためににお金や時間をかけたことはある？
|
||||
|
||||
これらの質問を通じて、得られる情報は次のようなものかもしれません：
|
||||
|
||||
- 多くの人は書けないのではなく、異なる職種に合わせて書き換える方法がわからない
|
||||
- 一番痛いのはレイアウトではなく、「どの経歴を書く価値があるか」がわからないこと
|
||||
- 怠けているのではなく、毎回履歴書を修正するのが精神的に消耗するから先延ばしにする
|
||||
- 先輩のアドバイス、テンプレートサイト、AI ツール、友達に見てもらうことでなんとか解決している
|
||||
|
||||
この時点で、本当の問題にずっと近づいています。
|
||||
|
||||
## 8. The Mom Test と JTBD をどう組み合わせて使うか
|
||||
|
||||
もし JTBD が「ユーザーがどんな進捗を達成したいか」を見極めるのを助けるなら、The Mom Test はむしろこう教えていると言えます：
|
||||
|
||||
**インタビューを通じて、この Job が本当に存在するかどうかを確認する方法。**
|
||||
|
||||
この二つを繋げて使うことができます：
|
||||
|
||||
1. まず JTBD で一つの Job を仮定する
|
||||
2. 次に The Mom Test の方法で、ユーザーの最近のリアルな体験について聞く
|
||||
3. この Job が本当に高頻度で、リアルで、優先してやる価値があるかを見る
|
||||
|
||||
例えば、JTBD の仮定が次のようだとします：
|
||||
|
||||
> インターンに応募する準備をする時、古い履歴書を職種に合ったバージョンに素早く書き換えて、できるだけ早く応募を完了したい。
|
||||
|
||||
それなら The Mom Test スタイルの質問で検証できます：
|
||||
|
||||
- 前回応募したのはいつ？
|
||||
- その時、どうやって履歴書を修正した？
|
||||
- どの部分が一番書きにくかった？
|
||||
- 修正後、どうやって十分かどうかを判断した？
|
||||
|
||||
このように手法が繋がります：
|
||||
|
||||
- JTBD はニーズ仮説の定義に役立つ
|
||||
- The Mom Test はインタビューによる仮説検証に役立つ
|
||||
|
||||
## 9. 初心者がユーザーインタビューをする時に最も陥りやすい誤解
|
||||
|
||||
### 9.1 インタビューをプロダクト紹介会にしてしまう
|
||||
|
||||
自分のアイデアを話しすぎると、相手はリアルな状況を教えるのではなく、あなたに合わせ始めやすくなります。
|
||||
|
||||
### 9.2 インタビュー相手が全部知り合い
|
||||
|
||||
知り合いに聞くのも悪くありませんが、知り合いは励ましてくれやすいです。少なくともリアルなユーザーに近い人も混ぜる必要があり、自分を支持してくれる人だけに聞くべきではありません。
|
||||
|
||||
### 9.3 早すぎる機能の追及
|
||||
|
||||
問題をはっきりさせる前に、ボタン、画面、機能の詳細について聞き始めると、通常ソリューションに入るのが早すぎます。
|
||||
|
||||
### 9.4 「使います」の一言を検証結果とみなす
|
||||
|
||||
インタビューはせいぜい方向性の判断に役立ち、検証が完了したこととイコールではありません。本当の検証は、最終的にユーザーが実際のコスト（時間、切り替えコスト、トライアル行動、さらには有料）を払う意欲があるかどうかにかかっています。
|
||||
|
||||
### 9.5 インタビュー終了後に整理しない
|
||||
|
||||
聞き終わってそのままにしておくと、情報はすぐに曖昧な印象になってしまいます。できるだけ早く整理しましょう：
|
||||
|
||||
- 高頻度で出現した問題
|
||||
- ユーザーの生の言葉の中の感情ワード
|
||||
- 現在の代替ソリューション
|
||||
- すでに払ったコスト
|
||||
- 自分の新しい判断
|
||||
|
||||
## 10. そのままコピーして使える質問リスト
|
||||
|
||||
すぐに始めたいなら、ここに汎用性の高い質問セットがあります。
|
||||
|
||||
### オープニングの質問
|
||||
|
||||
- 前回この問題に直面したのはいつですか？
|
||||
- その時具体的に何が起きましたか？
|
||||
|
||||
### 行動の質問
|
||||
|
||||
- その時どう対処しましたか？
|
||||
- なぜこの方法を選んだのですか？
|
||||
|
||||
### コストの質問
|
||||
|
||||
- この件には通常どれくらいの時間や労力がかかりますか？
|
||||
- この解決のためににお金を使ったことはありますか？
|
||||
|
||||
### 代替ソリューションの質問
|
||||
|
||||
- 他のツールや方法を試したことはありますか？
|
||||
- なぜ結局続けなかったのですか？
|
||||
|
||||
### 締めくくりの質問
|
||||
|
||||
- 将来同じ問題に直面したら、最も理想的な解決方法はどんなものだと思いますか？
|
||||
|
||||
この締めくくりの質問は聞いてもいいですが、最後に置くのが良いでしょう。なぜなら、前半では事実をより多く手に入れる必要があり、願望ではないからです。
|
||||
|
||||
## 11. まとめ
|
||||
|
||||
The Mom Test の最も重要な貢献は、「よりうまく話す」スキルを与えることではなく、より冷静な判断方法を構築することです：
|
||||
|
||||
- 他人のあなたのアイデアに対する褒め言葉を急いで信用しない
|
||||
- 「あれば使う」をリアルなニーズとみなさない
|
||||
- インタビューを自分への承認探しにしない
|
||||
|
||||
本当に価値のあるインタビューは、これらのものにできるだけ戻るべきです：
|
||||
|
||||
- ユーザーの最近のリアルな体験
|
||||
- 今どう対処しているか
|
||||
- すでにどんなコストを払っているか
|
||||
- どこで明らかに不快感を感じているか
|
||||
|
||||
このように聞き始めると、得られる情報は時に聞こえは良くないかもしれませんが、通常はより役立ちます。
|
||||
プロダクトを作る時、**役に立つ真実は、聞こえの良い励ましよりも常に重要です。**
|
||||
|
||||
<a id="mom-ai"></a>
|
||||
## [12. AI を活用してユーザーインタビューに役立てる方法](#top-mom)
|
||||
|
||||
The Mom Test は本質的に「リアルな人と話す」手法なので、AI が実際のインタビューに代わることはありません。しかし、AI はインタビューの前、中、後でサポートするのに非常に適しており、特に初心者のハードルを下げるのに役立ちます。
|
||||
|
||||
### 12.1 AI に「聞きづらい質問」を書き直させる
|
||||
|
||||
「このアイデア、どう思う？」と聞くべきではないとわかっていても、口を開くとついこの言葉に戻ってしまう人は多いです。まず自分で準備した質問を AI に渡して、書き直してもらうことができます：
|
||||
|
||||
```text
|
||||
以下はユーザーインタビューで聞こうとしている質問です：
|
||||
[質問を貼り付け]
|
||||
|
||||
The Mom Test の原則に従って書き直してください：
|
||||
1. 意見型の質問を削除する
|
||||
2. 未来を仮定する質問を削除する
|
||||
3. 過去のリアルな行動、既存の代替ソリューション、すでに払ったコストを中心に質問を書き直す
|
||||
4. 最後にインタビューで直接使える 8〜10 の質問リストに整理する
|
||||
```
|
||||
|
||||
初心者っぽい入力でも全く問題ありません：
|
||||
|
||||
```text
|
||||
ユーザーに聞きたいことがあります：
|
||||
1. AI で履歴書を添削するツールを作ろうと思うんだけど、どう思う？
|
||||
2. 使う？
|
||||
3. お金払う？
|
||||
|
||||
もっと良い聞き方に書き直して。
|
||||
```
|
||||
|
||||
AI が出力する有用な回答は次のようになります：
|
||||
|
||||
```text
|
||||
書き直した質問：
|
||||
|
||||
1. 前回履歴書を修正したのはいつ？
|
||||
2. その時なぜ修正したの？
|
||||
3. どうやって修正したの？
|
||||
4. どの手順に一番時間がかかった？
|
||||
5. 誰かに見てもらったことはある？
|
||||
6. 履歴書の修正のためににお金や時間をかけたことはある？
|
||||
```
|
||||
|
||||
このような出力は、元々「意見を聞く」質問を「リアルな行動を聞く」質問に直接変えてくれるので、非常に役立ちます。
|
||||
|
||||
### 12.2 AI に異なる対象に合わせたインタビューのガイドラインを作成させる
|
||||
|
||||
同じ方向性でも、異なるターゲット層に対してはインタビューの焦点が異なります。例えば学生、人事、フリーランサーでは関心事が全く違います。AI に異なる対象向けにそれぞれのガイドラインを作成させることができます：
|
||||
|
||||
- 初心者ユーザーには、最近のリアルな体験を重点的に聞く
|
||||
- ヘビーユーザーには、代替ソリューションと痛みの強さを重点的に聞く
|
||||
- 有料ユーザーには、すでにコストを払ったかどうかを重点的に聞く
|
||||
|
||||
こうすることで、実際に話す時にリズムができ、誰にでも同じ質問を繰り返すことがなくなります。
|
||||
|
||||
例えば次のように入力できます：
|
||||
|
||||
```text
|
||||
2種類の人に聞きます：
|
||||
1. 初めてインターンを探す大学生
|
||||
2. たくさんの人の履歴書を見てきた先輩
|
||||
|
||||
それぞれインタビューガイドラインを 6 つずつの質問で作って。
|
||||
```
|
||||
|
||||
AI は次のように出力するかもしれません：
|
||||
|
||||
```text
|
||||
大学生向け：
|
||||
1. 前回インターンに応募したのはいつ？
|
||||
2. その時一番詰まったのはどの手順？
|
||||
3. 自分の履歴書が応募できるレベルかどうか、どうやって判断する？
|
||||
...
|
||||
|
||||
先輩向け：
|
||||
1. 前回誰かの履歴書を見たのはいつ？
|
||||
2. よく見かける明らかな問題は何？
|
||||
3. 後輩が一番詰まるのはどの手順？
|
||||
...
|
||||
```
|
||||
|
||||
このようにすれば、ゼロから質問を考える必要がなく、インタビューの準備がずっと楽になります。
|
||||
|
||||
### 12.3 AI にインタビュー記録を整理させる
|
||||
|
||||
インタビューが終わった後、最も起こりやすい問題は「情報がない」ことではなく、「情報が散らばっている」ことです。AI は断片的な会話を構造化されたメモに整理するのに非常に適しています：
|
||||
|
||||
```text
|
||||
以下は 3 人のユーザーとのインタビュー記録です。
|
||||
The Mom Test の観点から整理してください：
|
||||
1. どの内容が事実で、どれがただの意見か
|
||||
2. ユーザーの最近のリアルな行動は何か
|
||||
3. 現在の代替ソリューションは何か
|
||||
4. ユーザーがすでに払った時間、お金、または労力コストは何か
|
||||
5. どの問題が繰り返し言及されたか
|
||||
6. どの発言がポジティブに聞こえるが、証拠が不十分か
|
||||
```
|
||||
|
||||
このステップは特に価値があります。なぜなら、「良さそう」な内容と「本当に判断を支えられる」内容を分けるのに役立つからです。
|
||||
|
||||
簡単な入力は次のようなものです：
|
||||
|
||||
```text
|
||||
あるユーザーとのインタビュー記録です：
|
||||
|
||||
- ツールがあれば試してみると言っていた
|
||||
- 先週履歴書の修正に一晩かかった
|
||||
- 今は主に友達に見てもらっている
|
||||
- 一番難しいのは、どこまで直せば「応募できる」と言えるかわからないこと
|
||||
|
||||
意見と事実に分けてください。
|
||||
```
|
||||
|
||||
AI は次のように出力するかもしれません：
|
||||
|
||||
```text
|
||||
意見：
|
||||
- ツールがあれば試してみる
|
||||
|
||||
事実：
|
||||
- 先週履歴書の修正に一晩かかった
|
||||
- 現在の代替ソリューションは友達に見てもらうこと
|
||||
- 一番の難点は「いつ応募できるレベルになるかわからない」
|
||||
|
||||
ニーズ判断に使えるポイント：
|
||||
- この問題は最近実際に発生した
|
||||
- ユーザーはすでに明らかな時間コストを投入している
|
||||
- 現在のソリューションは他人に依存し、不安定
|
||||
```
|
||||
|
||||
この出力は初心者に直感的に教えてくれます：どの言葉が判断に使えて、どの言葉は参考程度に聞いておけばいいか。
|
||||
|
||||
### 12.4 AI に軽量なウェブ検索を先に行わせる
|
||||
|
||||
インタビューを始める前に、AI に少し軽い外部調査をさせることができます。例えば：
|
||||
|
||||
- 公開コミュニティで、皆が最近この問題にどう不満を漏らしているか
|
||||
- 既存ツールで最も批判されているのは何か
|
||||
- ユーザーがすでに似たような問題にお金を払っているかどうか
|
||||
- 市場にどんな代替ソリューションがすでに存在するか
|
||||
|
||||
この種の情報はリアルなインタビューに代わるものではありませんが、どこから質問を始めればいいかをより早く見つけるのに役立ちます。
|
||||
|
||||
例えば、簡単な入力は次のようなものです：
|
||||
|
||||
```text
|
||||
調べてほしいことがあります：
|
||||
「大学生が履歴書を修正する時に最もよく不満を漏らすこと」
|
||||
最も一般的な不満を 5 つ、わかりやすい言葉でまとめて。
|
||||
```
|
||||
|
||||
AI は次のように出力するかもしれません：
|
||||
|
||||
```text
|
||||
よくある不満：
|
||||
|
||||
1. 履歴書に何を書けばいいかわからない
|
||||
2. 職種ごとに書き換えるのが面倒
|
||||
3. いくら修正しても十分かどうかわからない
|
||||
4. 頼れる人に見てもらえない
|
||||
5. いつまでも準備が終わらないと感じて先延ばしにする
|
||||
```
|
||||
|
||||
このような結果の価値は、インタビューの切り込み点を見つけやすくしてくれることにあります。
|
||||
|
||||
### 12.5 AI に「インタビュー振り返りコーチ」をさせる
|
||||
|
||||
インタビューが終わったばかりの記録を AI に渡して、改善点を指摘させることもできます：
|
||||
|
||||
```text
|
||||
以下は私のユーザーインタビュー記録の一部です。
|
||||
The Mom Test の観点から振り返りを行ってください：
|
||||
1. どの質問が承認を求めるような聞き方だったか
|
||||
2. どの質問に明らかな誘導があったか
|
||||
3. どこでさらに事実について掘り下げられたか
|
||||
4. もう一度やるとしたら、この会話はどう聞けばよかったか
|
||||
```
|
||||
|
||||
これは初心者に特に役立ちます。なぜなら、「私は証拠を集めているのか、それとも励ましを集めているのか」という感度をより早く構築できるからです。
|
||||
|
||||
## 📚 課題
|
||||
|
||||
上記の内容に基づいて、次の課題を完了してください：
|
||||
|
||||
1. 最近やりたいプロダクトの方向性を一つ選び、本来聞こうとしていた「聞きづらい」質問を 5 つ書く
|
||||
2. この 5 つの質問を The Mom Test スタイルに合わせて書き直す
|
||||
3. 潜在ユーザー 3 人に聞き、「前回この問題に直面したのはいつですか」を少なくとも 1 回は聞き出す
|
||||
4. インタビュー終了後、4 種類の情報を整理する：リアルな行動、代替ソリューション、すでに払ったコスト、繰り返し出現した困難
|
||||
|
||||
## さらに学ぶために
|
||||
|
||||
- [The Mom Test 公式サイト](https://momtestbook.com/)
|
||||
- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
|
||||
@@ -0,0 +1 @@
|
||||
../../../zh-cn/stage-1/building-prototype/images
|
||||
@@ -0,0 +1,605 @@
|
||||
---
|
||||
title: 'プロトタイプを动手作る - 業務分析からマルチページプロダクトプロトタイプの実装まで'
|
||||
description: '業務分析からマルチページプロダクトプロトタイプの実装までの完全なループを体験。AI IDE を使って単一ページおよびマルチページアプリケーションを生成し、プロトタイプを美化・テストする方法を学びます。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>8 時間</strong>'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['ja-jp/stage-1/building-prototype'] ?? []
|
||||
</script>
|
||||
|
||||
# 初級三：プロトタイプを动手作る
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['業務分析', 'プロトタイプ設計', 'AI 支援プログラミング', 'マルチページアプリ']" coreOutput="1 つの EC素材ワークベンチプロトタイプ" expectedOutput="インタラクティブな Web プロトタイプ">
|
||||
|
||||
前の章では、<strong>良いアイデアの見つけ方</strong>を学びました——ユーザーニーズから出発し、誰かがお金を払ってくれる方向を見つけること。しかし方向を見つけるのは第一歩にすぎず、<strong>本当にプロダクトマネージャーを試すのは：曖昧なニーズをどう使えるプロダクトにするかです。</strong>
|
||||
|
||||
この章では、<strong>現実的な問題</strong>を解決します：上司から「AI で商品の出品から EC プラットフォームへの掲載までの効率を上げて」と一言投げかけられた時——どうやってそれを<strong>使えるプロダクトプロトタイプ</strong>にするか？
|
||||
|
||||
前のヘビゲームや計算機とは異なり、<strong>リアルな業務では機能を勝手に考えることはできません</strong>：
|
||||
|
||||
1. <strong>ペインポイントを明確にする</strong>：運営チームに話を聞き、曖昧な「効率アップ」から<strong>本当のペインポイント</strong>を掘り出す
|
||||
2. <strong>重点的に作る</strong>：多くの問題の中から<strong>一番痛いところ</strong>を先に解決し、一度に全部やろうとしない
|
||||
3. <strong>素早く検証する</strong>：AI IDE で先に<strong>単一ページプロトタイプ</strong>を作り、動いたらマルチページに拡張する
|
||||
4. <strong>使えるものを作る</strong>：最後に<strong>デモでき、操作できる EC素材ワークベンチ</strong>を納品する
|
||||
|
||||
私たちは<strong>おもちゃからアプリへの転換</strong>を学び、<strong>共感と顧客のリアルなニーズを考える</strong>ことを学びます。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info ℹ️ 説明
|
||||
本記事には業務用語が含まれる場合があります。わからない場合は AI に説明を求めることができます。
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'ニーズ分析', description: '曖昧から具体へ' },
|
||||
{ title: '単一ページ検証', description: 'コア機能の実装' },
|
||||
{ title: 'マルチページ拡張', description: 'アプリ構造の完善' },
|
||||
{ title: '美化改善', description: 'ユーザー体験の向上' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. コードを書く前にニーズを確定する
|
||||
|
||||
前のチュートリアルでは、AI IDE を使ってヘビゲームや各種ミニゲームを簡単に生成しましたが、これらはおもちゃプロジェクトにすぎず、仕事や生活には応用できません。もし AI 能力を本当に皆さんに役立てたいなら、生活や仕事のシーンと組み合わせた Vibe Coding プログラミングを行うべきです。
|
||||
|
||||
前の章では<strong>誰かがお金を払ってくれる良いアイデアの見つけ方</strong>を学びましたが、方向を見つけるのは始まりにすぎません。本当にプロダクトを作る時、次のことに気づくでしょう：<strong>「何を作るか」を知っていることと、「どう作るか」を知っていることの間には、大きな溝があります。</strong>
|
||||
|
||||
この溝こそが<strong>ニーズの具体化</strong>です。
|
||||
|
||||
例えば、授業や個人のプロジェクトでは、最も簡単で実行可能な機能からプロダクトやアプリを作ることがよくあります：
|
||||
|
||||
- 「カンバンを作って、タスクを一覧にして。」
|
||||
- 「絵を描くツールを作って。」
|
||||
- 「アンケートを収集できるソフトを作って。」
|
||||
|
||||
これらは往々にして単なるツール、単一の機能モジュールであり、明確な業務問題とすら言えません。さらに重要なのは、<strong>これらのアイデアは往々にして「あなたが役に立つと思う」だけであり、「ユーザーが本当に必要としている」わけではない</strong>ことです。
|
||||
|
||||
企業プロジェクトやスタートアッププロジェクトでは、プロダクトマネージャーやエンジニアは往々にしてより大きな業務の課題から出発します。例えば、次のようなシーンを想定できます：
|
||||
|
||||
<el-card shadow="hover" style="border-left: 5px solid #409EFF; background-color: #ecf5ff; margin: 20px 0;">
|
||||
<div style="font-weight: bold; color: #303133; margin-bottom: 10px;">🛍️ 業務シーン：</div>
|
||||
<div style="color: #606266; line-height: 1.6;">
|
||||
<p>あなたはある店舗の EC 運営プロダクトマネージャーです。上司から曖昧だがプレッシャーの大きい課題を与えられました：</p>
|
||||
<p style="font-style: italic; margin-top: 10px;">「今、公式アカウントはみんな AI で画像やコピーを作っているし、簡単そうに見える。うちでもやってくれ、TikTok EC で新商品を出品する時の効率を上げたい。」</p>
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
この時、あなたは「上司、また夢を見てますね！」と思うかもしれません。しかし実際の仕事では、このような曖昧な一言での決定は非常に一般的であり、週にタピオカミルクティーを頼む回数よりも多いことすらあります。したがって、立派な職場の働き手として（むしろ新興スタートアップの CEO になってほしいですが）、私たちは自作のツールから本当のプロダクトプロトタイプへの転換方法を学ばなければなりません。
|
||||
|
||||
AI IDE を学んだので、このニーズは実はとてもシンプルだと考えるかもしれません。AI にこれに基づいてプロンプトを与え、Agent に投げれば万事解決じゃないかと：
|
||||
|
||||
```
|
||||
私の要件 xxxx を参考に、
|
||||
EC素材ワークベンチを設計してください、
|
||||
商品説明、画像、動画などの素材の生成・管理機能を含む。
|
||||
```
|
||||
|
||||
もし興奮してこのニーズをそのままプロトタイプに変換し、上司に送ったら——おめでとう、今四半期のボーナスはキャンセルです！
|
||||
|
||||
**なぜこうなるのか？これこそが私たちが解決すべき核心的なペインポイントです：**
|
||||
|
||||
以前、AI IDE を学んだ時は、ヘビゲーム、計算機のような**自分用のおもちゃプロジェクト**を作っていました——機能はシンプル、自分が何を欲しいか明確、作ったものは自分が使えばいい。しかし**リアルな業務シーンは全く異なります**：
|
||||
|
||||
- **あなたはユーザーではない**：上司が求めているのは「効率アップ」だが、運営チームが毎日具体的にどう働き、どこでつまずいているかを知らない
|
||||
- **AI も業務を理解していない**：曖昧なニーズを AI に投げても、一般的な知識に基づいて推測するしかなく、できたものはそれっぽく見えて実際には全く使えない
|
||||
- **良いアイデア ≠ 良いプロダクト**：「AI 生成機能を追加する」のはかっこいいと思うかもしれないが、ユーザーは必要としていないかもしれないし、元の方法より面倒かもしれない
|
||||
|
||||
**だからこそ、私たちは「アイデアからユーザー理解」を学ぶ必要があるのです。** あなたのアイデアが本当に他人の問題を解決して初めて、積極的に聞き、業務を深く理解して、本当に価値のあることができます。（良いアイデアは良い技術よりも重要なことすらあります）
|
||||
|
||||
### 1.1 想像から現実へ：業務への質問を学ぶ
|
||||
|
||||
::: info 💡 まず明確に：ニーズとは？業務とは？
|
||||
|
||||
**ニーズ**とはユーザーが本当に求めているもので、彼らが直面している悩み、解決したい問題です。例えば「上司が商品の出品を早くしたいと言った」、これは一つのニーズです。
|
||||
|
||||
**業務**とはユーザーが毎日実際にやっていること、彼らの働き方です。例えば EC 運営が毎日やること：商品出品、価格変更、画像作成、データ確認...これらはすべて業務です。
|
||||
|
||||
**なぜ業務に関心を持つべきか？**
|
||||
業務を理解しなければ、作ったツールは「良さそうに見えるが誰も使わない」ものになりかねないからです。ユーザーが毎日どう働き、どこでつまずいているかを本当に理解して初めて、本当に役立つものが作れます。
|
||||
|
||||
:::
|
||||
|
||||
最もシンプルな視点から出発して、まず自分にいくつか質問できます：
|
||||
|
||||
- 上司が言う「**効率を上げる**」は、具体的にどういう意味？**速く作る**こと？**コストを減らす**こと？**もっと売る**こと？
|
||||
- 今、商品はどうやって出品している？**どこがうまくいかない**？
|
||||
- 毎日何個の**新商品**を作る？各商品に何枚の**画像**、何文字の**テキスト**が必要？
|
||||
- 今の仕事の中で、**何が一番面倒**で、**一番やりたくない**？
|
||||
|
||||
しかしこれらは推測の質問です。私たちは最前線の TikTok EC 担当者に直接「あなたたちの困難と関心事はどこにありますか？」と聞き、コミュニケーションを通じてより正確な答えを得る必要があります：
|
||||
|
||||
::: info 📋 リアルな業務ヒアリング結果
|
||||
|
||||
EC 運営をしている人に聞いたところ、次のような悩みがありました：
|
||||
|
||||
**1. やることが多すぎて雑然としている**
|
||||
- 一人で複数の店舗を管理し、各店舗に多くの商品がある
|
||||
- 毎日忙しく行き来する：**新商品の出品**、**価格変更**、**画像作成**、**データ確認**、一つ終わらないうちに次の作業
|
||||
|
||||
**2. コンテンツ作りは一回で完成するのではなく、試しながら作る**
|
||||
- まず**メーカー提供の画像**、**以前使った素材**や**ネットで見つけた参考画像**を使って、素早く商品を**出品**して試す
|
||||
- 少しのお金をかけてプロモーションをし、**誰かが買うか見る**
|
||||
- **売れている商品**だけ、真面目に画像を作り、詳細を書き、動画を撮る
|
||||
|
||||
:::
|
||||
|
||||
業務ヒアリングが終わると、私たちは情熱に駆られます。この時なら本当に業務に合った完璧なプロダクトプロトタイプが作れる！——また間違っています。「すべての要望を一度に満たそう」とすると、プロダクトは非常に大きくなり、コースの時間内に実装するのも難しくなります。したがって、さらに整理・絞り込みを行い、本当の核心的なペインポイントを見つける必要があります。
|
||||
|
||||
### 1.2 発散から収束へ：業務の核心的なペインポイントと機能を特定する
|
||||
|
||||
::: info 💡 なぜ「収束」が必要？「ペインポイント」とは？
|
||||
|
||||
**問題は多いが、まずどれをやるか？**
|
||||
|
||||
ユーザーはたくさんの問題を教えてくれるかもしれません：A も面倒、B も面倒、C も面倒...しかし、すべての問題を一度に解決しようとすると、最後は何も上手くできなくなる可能性があります。だから**収束**する必要——多くの問題の中から、**一番痛くて、一番急いでいて、一番解決できる**ものを先に選ぶのです。
|
||||
|
||||
**ペインポイントとは？**
|
||||
ユーザーが**一番嫌で、一番時間がかかり、一番解決したい**という具体的な問題のこと。「役に立つと思う」ではなく、ユーザーが**毎日愚痴をこぼし、毎回やるのが苦痛**なことです。
|
||||
|
||||
:::
|
||||
|
||||
上記のヒアリングを通じて、運営が直面する問題がたくさんあることがわかりました：イベントのペースに邪魔される、複数店舗を管理する、出品/価格変更/画像作成/データ確認の間で忙しく行き来する...
|
||||
|
||||
「これらすべての問題を全部解決する」としようとすると、最後は**大きくて包括的だが使いにくい**ツールになります。
|
||||
|
||||
これらの問題を分類（AI に手伝ってもらうこともできます）すると、大まかに 3 種類あります：
|
||||
|
||||
1. **ペースの問題**：いつ出品し、いつ価格を調整するか
|
||||
2. **効率の問題**：どうやって複数の店舗、複数の商品を同時に管理するか
|
||||
3. **コンテンツの問題**：どうやって商品画像とコピーを素早く作るか
|
||||
|
||||
このコースにとって、最も適して先に解決するのは**第 3 種：コンテンツ作成の問題**です。しかし「素早くコンテンツを作る」はまだ少し抽象的なので、業務担当者に具体的にどこがつまずいているかをもう一度聞きます：
|
||||
|
||||
::: info 📋 業務担当者の話：コンテンツ作りで最も苦痛な 2 つの場所
|
||||
|
||||
**苦痛 1：バッチで画像とコピーを作るのが大変**
|
||||
- 素材はあちこちに散らばっている：クラウドストレージ、WeChat の履歴、プラットフォームの管理画面...**探すのが大変**
|
||||
- 一度にたくさん商品を出品する必要があり、**一つずつ丁寧に作る時間がなく**、適当に組み合わせるしかない
|
||||
- 要求は高くなく、**見られて、出品できればいい**、それほど精美でなくていい
|
||||
|
||||
**苦痛 2：使い勝手の良いソリューションを保存して再利用できない**
|
||||
- 以前上手くいったタイトル、レイアウトを**次に使おうとしても見つからない**
|
||||
- ソリューションがチャット履歴、以前の商品リンクに散らばっている
|
||||
- 使いたい時に**ずっと探して、コピペして、長く修正する**必要がある
|
||||
- **お気に入り、管理、直接適用**できるツールがない
|
||||
|
||||
:::
|
||||
|
||||
上記の 2 つのペインポイントに基づいて、簡単なツールを作ります：**運営がバッチで画像とコピーを作るのを助け、良いソリューションを保存して次に直接使えるようにする**もの。
|
||||
|
||||
それは 2 つのことだけを行います（AI に手伝ってもらって詳細化できます。業務フィードバックに基づいて常に機能を削減することを忘れないでください）：
|
||||
|
||||
::: info 機能 1：EC 商品画像とコピーのバッチ生成
|
||||
|
||||
**これは何をするものか？**
|
||||
システムに商品情報を入れると、自動的に EC プラットフォーム（TikTok、タオバオなど）で出品用の商品画像とテキストを生成します。
|
||||
|
||||
**入力**
|
||||
| タイプ | 内容 |
|
||||
|------|------|
|
||||
| 商品情報 | 名前、カテゴリ、ブランド、素材、サイズ、カラーなど |
|
||||
| 商品画像 | 白背景画像またはシンプルなシーン画像 |
|
||||
| 参考画像 | 以前よく売れた商品のスクリーンショットや参考リンク |
|
||||
| インポート方法 | Excel バッチインポート、またはページ上で直接入力 |
|
||||
|
||||
**出力（生成される EC 素材）**
|
||||
- **商品メイン画像**：テキスト付きのセールスポイント商品展示画像（ユーザーがスクロール時に最初に目にする画像）
|
||||
- **商品タイトル**：検索で見つかるキーワード組み合わせ
|
||||
- **セールスポイントコピー**：1〜2 文の買い手を引きつける言葉
|
||||
- すべて**少し修正すれば出品できる**完成品
|
||||
|
||||
**効果**
|
||||
- 以前：各商品をゼロから画像とコピーを作成
|
||||
- 現在：商品のバッチをシステムに入れ、ドラフトを生成してから選んで少し修正するだけ
|
||||
|
||||
:::
|
||||
|
||||
::: info 機能 2：使い勝手の良いソリューションをテンプレートとして保存
|
||||
|
||||
**入力**
|
||||
| タイプ | 内容 |
|
||||
|------|------|
|
||||
| セット | メイン画像 + タイトル + コピー |
|
||||
|
||||
**出力**
|
||||
| 機能 | 説明 |
|
||||
|------|------|
|
||||
| 適用 | 次回新商品を作る時、テンプレートで自動生成 |
|
||||
| 修正 | タイトル、コピーを直接修正 |
|
||||
| 管理 | 名前を付け、タグ付け（例：「メンズバッグテンプレート」「プロモーションタイトル」）、探しやすくする |
|
||||
|
||||
**効果**
|
||||
1. 新商品をインポート
|
||||
2. 選択：システムのデフォルト生成、または**保存済みテンプレートを使う**
|
||||
3. システムが自動的にテンプレートのスタイルを適用し、新しい画像とコピーを出力
|
||||
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
**振り返り：私たちは何をしたか：**
|
||||
|
||||
1. **まず質問した**：すぐに作り始めるのではなく、まず運営に「何が一番嫌ですか」と聞いた
|
||||
2. **ペインポイントを見つけた**：彼らが最も苦痛なのは「画像とコピーを作るのが大変」と「良いソリューションを保存できない」
|
||||
3. **範囲を絞り込んだ**：大きくて包括的なプラットフォームを作らず、「バッチ生成 + テンプレート保存」の 2 つの機能だけを作る
|
||||
|
||||
**なぜこれが重要か？**
|
||||
|
||||
多くの初心者のプロダクト作りの誤解は：機能が多ければ多いほど良い。しかしユーザーが本当に必要としているのは**最も痛い問題を解決すること**。たくさんの機能がどれも使いにくいより、1〜2 の機能が本当にユーザーに役立つ方が良い。
|
||||
|
||||
**プロダクトと業務思考の核心：**
|
||||
- 自分で「ユーザーが何を必要としていると思うか」を考えない
|
||||
- ユーザーに「毎日何をしていますか？どこが一番苦痛ですか？」と聞く
|
||||
- 多くの問題から**一番痛くて、一番解決できるもの**に絞り込む
|
||||
- まず**最小限の使えるバージョン**を作り、ゆっくり反復する
|
||||
|
||||
これがコードを書く前に明確にしておくべきこと。コードはただのツールであり、**ユーザーを理解し、問題を見つける**ことこそが第一歩です。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: 'ニーズ分析', description: '曖昧から具体へ' },
|
||||
{ title: '単一ページ検証', description: 'コア機能の実装' },
|
||||
{ title: 'マルチページ拡張', description: 'アプリ構造の完善' },
|
||||
{ title: '美化改善', description: 'ユーザー体験の向上' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. 10 分でプロトタイプを作る：AI IDE で「コア機能」を落とし込む
|
||||
|
||||
::: info 💡 プログラミング Plan についての提案
|
||||
現在の IDE が十分賢くないと感じる、またはすぐに枠を使い切ってしまう場合は、**プログラミング Plan** を購入することができます。事前学習として[この記事](../../stage-2/backend/modern-cli/)を参照して Claude を使ってプログラミングを行ってください。
|
||||
:::
|
||||
|
||||
考え過ぎるのも良くありません。過度な反省を抑えて、単一ページからプロトタイプの作成を始めましょう。
|
||||
|
||||
### 2.1 第一歩：AI に普通の言葉でやりたいことを伝える
|
||||
|
||||
最初から完璧なプロンプトを目指す必要はありません。最も自然な表現から始めましょう。同僚にニーズを説明するように、普通の言葉で AI に何を作りたいかを伝え、AI に手伝ってもらってより専門的な表現にブラッシュアップしてもらいましょう。
|
||||
|
||||
#### 2.1.1 口頭から始める（初心者にお勧め）
|
||||
|
||||
まず自分の言葉でアイデアを説明します。たとえ荒くても構いません：
|
||||
|
||||
```
|
||||
EC 運営が自動的に商品のメイン画像とコピーを生成するツールを作りたい。
|
||||
運営は普段一つずつ手作業で画像とコピーを作っていて、とても面倒。
|
||||
私のアイデアは：商品情報をアップロードすると、システムが自動的にドラフトのバッチを生成し、
|
||||
運営は使いやすいものを選んで少し修正すれば使える。
|
||||
|
||||
まず最もシンプルなバージョンを作る：1 つのページで、左側に商品情報を入力、
|
||||
右側に生成結果を表示。画像のアップロード、テキストの入力ができ、
|
||||
生成後にメイン画像のプレビューとコピーが表示される。
|
||||
```
|
||||
|
||||
次に、このテキストを AI（ChatGPT、Claude など）に送り、拡張してもらいましょう。AI は通常、あなたが考慮していなかった詳細を補充し、アイデアをより明確に整理し、最後に AI IDE に適したプロンプトを生成してくれます。
|
||||
|
||||
次のように AI に伝えられます：
|
||||
```
|
||||
上のアイデアを拡張して、明確な業務ロジックドキュメントに整理して、
|
||||
それから AI IDE（Cursor、Trae など）に送るのに適したプロンプトを生成して、
|
||||
単一ページアプリケーションのプロトタイプコードを生成するのに使う。
|
||||
```
|
||||
|
||||
AI は構造化されたニーズと対応するプロンプトを返してくれます。自分でチェックして不要な機能を削除し、問題がなければコード生成に使いましょう。
|
||||
|
||||
#### 2.1.2 拡張ステップをスキップ：整理済みの業務ドキュメントを直接 AI に渡す
|
||||
|
||||
もし前の章で業務ロジックドキュメントをすでに整理しているなら、次の形式を使って直接 AI IDE に送り、AI に拡張してもらう中間ステップを省けます。ニーズがすでに明確で、すぐにコードを書き始めたい場合に適しています：
|
||||
|
||||
```
|
||||
業務ロジックを参考に単一ページアプリケーションを実装して、コア機能の検証に使います。
|
||||
|
||||
業務ロジックの参考：
|
||||
1. 運営の第一版の画像・テキストドラフトのバッチ生成：
|
||||
- **入力（直接アップロードとバッチインポート素材をサポート）：**
|
||||
- 商品基本情報：名前、カテゴリ、ブランド、素材、サイズ、カラー、対象層など
|
||||
- 商品画像：白背景画像 / シンプルなシーン画像
|
||||
- 毎回の生成時に追加のヒット商品スクリーンショットや参考リンクのアップロードをサポート、参考物を許可
|
||||
- Excel バッチインポート、またはページ上でオンライン入力 / アップロードをサポート
|
||||
- ページ上で商品素材を素材ライブラリに保存するかどうかを指定でき、次回の利用に便利
|
||||
- **出力（直接出品または軽微な修正で出品可能な内容）：**
|
||||
- 各商品につき「まともで、基本セールスポイントを含む」メイン画像ドラフト
|
||||
- 「構造が合理的で、コアキーワードを含む」タイトル + 1〜2 文のセールスポイントコピー
|
||||
- **期待される使い方の変化：**
|
||||
各バッチの商品をゼロから作成するのではなく、商品のバッチをシステムに入れて、システムが生成したドラフトから選別・微調整する。
|
||||
|
||||
まず第一の機能を作り、第二の機能（テンプレートライブラリ）は後で追加する。
|
||||
```
|
||||
|
||||
#### 2.1.3 プログラマーのやり方（応用）：AI に「プロンプトのプロンプト」を書いてもらう
|
||||
|
||||
コード生成プロセスをより細かく制御したい場合、まず AI（ChatGPT など）にニーズに基づいて、AI IDE 専用のプロンプトを生成させることができます：
|
||||
|
||||
```
|
||||
以下のアイデアに基づいて、coding Agent に送るコード記述用のプロンプトを作ってください。
|
||||
このプロンプトを使ってコードを生成する必要があります。
|
||||
|
||||
[業務ロジックの説明をここに貼り付け]
|
||||
|
||||
要件：
|
||||
1. プロンプトには明確なページレイアウトの説明を含める
|
||||
2. データ構造とインタラクションロジックを明確にする
|
||||
3. 技術スタックを指定する（例：React + Tailwind）
|
||||
4. 実装する必要のあるコア機能を列挙する
|
||||
```
|
||||
|
||||
通常、AI は次のような構造化されたプロンプトを生成します：
|
||||
|
||||
|
||||
このプロンプトを少し修正してから、AI IDE に送ってコードを生成させることができます。
|
||||
|
||||
### 2.2 第二歩：AI IDE に直接コードを生成させる
|
||||
|
||||
#### 2.2.1 準備：AI IDE の基本操作を理解する
|
||||
|
||||
もし AI IDE（Cursor、Trae、Windsurf など）の基本使い方にまだ慣れていない場合、まず付録の[IDE 基礎チュートリアル](/ja-jp/appendix/2-development-tools/ide-basics/)を参照して、以下を理解することをお勧めします：
|
||||
- 新規プロジェクトの作成
|
||||
- AI Agent との対話
|
||||
- AI のコード生成プロセスの理解
|
||||
|
||||
#### 2.2.2 コード生成を開始
|
||||
|
||||
この時点で初期プロンプトが得られています。最初のプロンプトスタイルを例にして、AI にコードの生成を手伝ってもらいましょう。まずウィンドウと対応するフォルダーを作成し、フォルダーを開きます（お気に入りのフォルダーの場所で新規プロジェクトを初期化）：
|
||||
|
||||
|
||||
|
||||
サイドバーで好きなモデル（gemini、gpt、glm、kimi、minimax などを推奨）を選択し、第一歩で得たプロンプトを入力：
|
||||
|
||||
|
||||
生成をクリックすると、おなじみのプロセスが始まります。AI はプロンプトに基づいてプロジェクトのディレクトリ構造、必要なファイルを計画し、各ファイルの初期内容を与えます。
|
||||
|
||||
::: warning ⚠️ 特別な注意：AI が確認を待って止まる可能性がある
|
||||
生成プロセス中、AI Agent は**あなたの入力や確認を待って止まる**ことがよくあります。例えば：
|
||||
- 次のステップに進むかどうかを聞く
|
||||
- 何かの操作を確認するためにエンターキーを押すよう促す
|
||||
- 何かの技術的な選択について聞く
|
||||
|
||||
**AI が止まったら、まず対話画面をチェックして、あなたの返事を待っているかどうかを確認してください。** 多くの初心者は AI が思考中だと思っていますが、実際にはずっと前からあなたを待っています。積極的に返事をするかエンターキーを押せば、AI は作業を続けます。
|
||||
:::
|
||||
|
||||
この時、エンターキーを押して情報を確認することを忘れないでください（さもないと待機状態に陥ります。一部の AI IDE ではこの問題は起こりません）：
|
||||
|
||||
|
||||
次のようなシーンに遭遇した場合、これはローカルでサービスがすでに起動していることを意味し、クリックしてスキップする必要があります。さもないとこの画面に留まり続けます（コード生成が完了しても何も表示されない場合、「このプロジェクトを起動して」と自発的に言う必要があります）：
|
||||
|
||||
|
||||
::: info 💡 シーンの説明
|
||||
**シーンの説明**：`npm create vite@latest` で React + TypeScript プロジェクト（easy-vibe-web）を作成した後、コンピュータが自動的にこの Web ページを「起動」し、すぐに効果を確認できるようにします。
|
||||
|
||||
**ローカルサービス**：あなたのコンピュータが一時的に Web ページの展示ウィンドウを開いたものと理解でき、あなたのコンピュータ上でのみ実行され、他人はアクセスできません。
|
||||
|
||||
**localhost（ローカルアドレス）**：`localhost` は「このコンピュータ自身」を意味し、ブラウザでアクセスすると、実際にはあなたのコンピュータで実行中の Web ページにアクセスしています。
|
||||
|
||||
**ポート**：ポートは番号と理解でき、同じコンピュータ上で実行される異なる Web サービスを区別するために使われます。このプロジェクトが使用するのは 5174 です。
|
||||
|
||||
**アクセスリンク `http://localhost:5174/`**：このアドレスは「このコンピュータのポート番号 5174 の Web ページにアクセスする」ことを意味し、ブラウザで開けば効果が確認できます。
|
||||
|
||||
**今回のシーンの説明**：システムは元々 5173 を使おうとしましたが、この番号がすでに使用されていたため、自動的に 5174 に切り替えました。これは正常な動作です。
|
||||
|
||||
**操作ガイド**：ブラウザを開き、アドレスバーに `http://localhost:5174/` と入力してエンターキーを押せば、現在のプロジェクトページが確認できます。
|
||||
:::
|
||||
|
||||
すべて確認が完了したら、エージェントがしばらく実行されるのを待つと、次のような結果が得られます：
|
||||
|
||||
|
||||
初步的な機能画面がすでにありますが、フロントエンドページがあまりにもシンプルです。この時、AI と直接対話して画面表示を最適化できます：
|
||||
|
||||
|
||||
最適化後、より美しい画面が得られます：
|
||||
|
||||
|
||||
自分のニーズに合わせて Web ページの機能を変更できます。スクリーンショットを添えて自由に質問できます。例えば：「バッチインポート機能はまだ不要だから、削除して」「左側の入力項目が多すぎるから、xxxxx だけ残して」。さらに、他の成熟した Web サイトを参考にすることもできます。例えば、Google のあるデザインプロダクトを直接「参考」にできます（好きな成熟した Web サイトのスクリーンショットを貼り付けることもできます）：
|
||||
|
||||
|
||||
最終的に得られる結果：
|
||||
|
||||
|
||||
### 2.3 エラーが出たらどうする
|
||||
|
||||
実際の操作では、エラーに遭遇するのは必然です。これは正常な現象であり、あなたが何か間違ったことをしたという意味ではありません。あなたはエラーを理解する必要はなく、「見た状況」を完全に AI に渡すだけでいいです。
|
||||
|
||||
一般的な対処方法は 3 つだけです：
|
||||
|
||||
- **方法 1：ページやターミナルのエラー**
|
||||
ページが赤くなる、真っ白になる、またはターミナルに赤い文字がたくさん出る時は、スクリーンショットを撮るか、すべてのエラー情報をコピーして AI に送り、修正してもらう。
|
||||
|
||||
- **方法 2：機能がおかしいがエラーは出ない**
|
||||
例えばボタンが反応しない、データが表示されない、スタイルが崩れている場合、「今何が起きている + 本当はどうしたいか」を普通の言葉で説明し、必要に応じてスクリーンショットを添える。
|
||||
|
||||
- **方法 3：問題があるかどうかわからない**
|
||||
直接 AI に聞ける：「この機能に明らかな問題がないか、調整が必要かチェックして。」
|
||||
|
||||
#### 2.3.1 初心者によくある質問
|
||||
|
||||
- **Q：エラー情報がどこにあるかわからない**
|
||||
- A：一般的に、「赤い文字」をすべて見てください。ターミナル、コンソール、またはページ上で赤いプロンプトを見つけ、全選択コピーして AI に渡せばいいです。
|
||||
|
||||
- **Q：AI が修正しても同じエラーが出る場合は？**
|
||||
- A：これはよくあることです。最新のエラー情報をスクリーンショットまたはコピーして AI に送り、前回の修正を基にさらに修正してもらう。
|
||||
|
||||
- **Q：AI の修正案を完全に理解する必要がある？**
|
||||
- A：一度に全部理解する必要はありません。毎回 1〜2 のポイントに注目すれば、時間をかけて徐々にコードが理解できるようになります。英単語を蓄積するのと同じです。
|
||||
|
||||
- **Q：何度も修正しても問題が解決しない場合は？**
|
||||
- A：次を試すことができます：
|
||||
- IDE の「バージョンロールバック」機能を使い、エージェントの対話で巻き戻しボタンを見つけて、実行可能なバージョンに戻ってやり直す
|
||||
- モデルを変えるか、プロンプトを調整し、現象やエラー情報をより具体的に説明する
|
||||
- 「現在のコード + エラーログ + 期待される動作」をパッケージにして、一度に AI に送り、問題部分を全体としてリファクタリングしてもらう
|
||||
|
||||
## 3. 単一ページからマルチページアプリケーションへの拡張
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: 'ニーズ分析', description: '曖昧から具体へ' },
|
||||
{ title: '単一ページ検証', description: 'コア機能の実装' },
|
||||
{ title: 'マルチページ拡張', description: 'アプリ構造の完善' },
|
||||
{ title: '美化改善', description: 'ユーザー体験の向上' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
コア機能のロジックが基本的に生成されたら、残りの部分のコンテンツを生成できます。例えば、この時点で設定や一部のボタンをクリックしても全く反応しません。
|
||||
|
||||
AI に業務プロンプトのニーズに基づいてチェックさせ、未生成の部分を生成させたり、AI に未実装のページを直接補完させたりできます。特定のページを指定して AI に実装を補完させることもできます。ページがクリックでき、機能が正常にインタラクションできるまで続けます：
|
||||
|
||||
|
||||
しばらく待つと、プログラムが以前の基礎の上に複数のページとインタラクティブ機能を補完しているのが見えます：
|
||||
|
||||
|
||||
|
||||
|
||||
この時、あなたは各気になる機能とボタンを手動でクリックし、インタラクションが正常であることを確認するだけでいいです。インタラクションできない機能があれば、AI とコミュニケーションして修正してもらえます。
|
||||
|
||||
## 4. プロトタイプを「それっぽく」する
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: 'ニーズ分析', description: '曖昧から具体へ' },
|
||||
{ title: '単一ページ検証', description: 'コア機能の実装' },
|
||||
{ title: 'マルチページ拡張', description: 'アプリ構造の完善' },
|
||||
{ title: '美化改善', description: 'ユーザー体験の向上' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
マルチページ構造ができたら、最後のステップはプロトタイプを「動く」状態から「使いやすくて、プロフェッショナルに見える」ものにすることです。これには、全プロセス（ユーザーフロー）を自分で体験し、実行できない部分を AI に修正してもらい、毎回リフレッシュ後にゼロから新規ユーザーとして全プロセスを歩いて期待通りの結果を得られるようにする必要があります。
|
||||
|
||||
最初のニーズを振り返ってみましょう：
|
||||
|
||||
```
|
||||
1. 運営の第一版の画像・テキストドラフトのバッチ生成：
|
||||
- **入力（直接アップロードとバッチインポート素材をサポート）：**
|
||||
- 商品基本情報：名前、カテゴリ、ブランド、素材、サイズ、カラー、対象層など
|
||||
- 商品画像：白背景画像 / シンプルなシーン画像
|
||||
- 毎回の生成時に追加のヒット商品スクリーンショットや参考リンクのアップロードをサポート
|
||||
- Excel バッチインポート、またはページ上でオンライン入力 / アップロードをサポート
|
||||
- ページ上で商品素材を素材ライブラリに保存するかどうかを指定可能
|
||||
- **出力（直接出品または軽微な修正で出品可能な内容）：**
|
||||
- 各商品につき「まともで、基本セールスポイントを含む」メイン画像ドラフト
|
||||
- 「構造が合理的で、コアキーワードを含む」タイトル + 1〜2 文のセールスポイントコピー
|
||||
- **期待される使い方の変化：**
|
||||
各バッチの商品をゼロから作成するのではなく、商品のバッチをシステムに入れて、システムが生成したドラフトから選別・微調整する。
|
||||
|
||||
2. 使い勝手の良い出力を再利用可能なテンプレートライブラリとして保存：
|
||||
- **何が保存できるか？**
|
||||
- 運営が「使いやすい」と感じた任意の出力をワンクリックでお気に入りに追加：
|
||||
- 「メイン画像 + タイトル + セールスポイント」の完全な組み合わせ
|
||||
- またはその一部だけ、例えばあるタイトル構造、あるセールスポイントコピー
|
||||
- **保存した後、何ができるか？**
|
||||
- **再利用：**
|
||||
- このお気に入りを使い、新商品パラメータのバッチを適用して、新しい画像・テキストドラフトを再生成
|
||||
- または同じ商品で、このテンプレートに基づいて複数のバリエーションを生成し A/B テストを行う
|
||||
- **編集：**
|
||||
- タイトルコピー / セールスポイントコピーを直接修正
|
||||
- 画像編集をサポートする場合、メイン画像のテキストやステッカー等の要素を微調整
|
||||
- **管理：**
|
||||
- お気に入りに名前を付け、タグ付け（例：「メンズバッグメイン画像テンプレート」「プロモーションタイトル構造」）、店舗別分類をサポートし、後の検索に便利に
|
||||
- **次回新商品出品時にどう使うか？**
|
||||
- 新商品をインポート後、運営は選択できる：
|
||||
- システムのデフォルトロジックで生成、または
|
||||
- 「保存したテンプレートを使って生成」を指定
|
||||
- システムは新商品データに基づき、テンプレートの構造とスタイルを自動的に適用し、新しいメイン画像 + タイトル + セールスポイントドラフトを出力
|
||||
```
|
||||
|
||||
もし毎回テストする時に自分でデータを作成しなければならないなら、膨大な時間がかかります。この時、通常「テストデータ」という方法を使って処理します。次のように AI とコミュニケーションして、テスト用のクイックデータエントリを画面に生成させ、全機能が正常に実行できるか素早くテストできます：
|
||||
|
||||
```
|
||||
このユーザー使用プロセスをテストする必要があり、完全に実行できることを確認したい。
|
||||
次のニーズに基づいてテストデータエントリを生成し、クリック後すぐに全プロセスが正常かどうかをテストできるようにしてください：
|
||||
1. 運営の第一版の画像・テキストドラフトのバッチ生成：
|
||||
- **入力（直接アップロードとバッチインポート素材をサポート）：**
|
||||
- 商品基本情報：名前、カテゴリ、ブランド、素材、サイズ、カラー、対象層など
|
||||
- 商品画像：白背景画像 / シンプルなシーン画像
|
||||
- 毎回の生成時に追加のヒット商品スクリーンショットや参考リンクのアップロードをサポート
|
||||
- Excel バッチインポート、またはページ上でオンライン入力 / アップロードをサポート
|
||||
- ページ上で商品素材を素材ライブラリに保存するかどうかを指定可能
|
||||
- **出力（直接出品または軽微な修正で出品可能な内容）：**
|
||||
- 各商品につき「まともで、基本セールスポイントを含む」メイン画像ドラフト
|
||||
- 「構造が合理的で、コアキーワードを含む」タイトル + 1〜2 文のセールスポイントコピー
|
||||
- **期待される使い方の変化：**
|
||||
各バッチの商品をゼロから作成するのではなく、商品のバッチをシステムに入れて、システムが生成したドラフトから選別・微調整する。
|
||||
```
|
||||
|
||||
簡単に結果が得られます（データが少なすぎる場合は、AI に複数のテスト用ケースを生成させることができます）：
|
||||
|
||||
|
||||
クリックして結果を得ます：
|
||||
|
||||
|
||||
この時、直接結果が得られますが、「仮の生成プロセス」があるわけではありません。リアルな生成プロセスを模擬したい場合、AI と直接対話できます：「クリックした後、しばらく経ってから結果を返すリアルな生成プロセスを模擬してください。」
|
||||
|
||||
|
||||
生成機能が実行できることを確認したら、テンプレートライブラリの機能が正常であることも確認する必要があります。ページの生成カードから、テンプレートライブラリの保存機能が実装されていないことがわかります。この時、AI とさらに深く対話する必要があります：「要件 [ここに上記の 2. の内容を貼り付け] が正常であることを確認してください。ある結果をクリックして対応するテンプレートを保存でき、開いたら生成パラメータが見えるように」
|
||||
|
||||
生成は往々にして一回では完成せず、時にはスクリーンショットで修正が必要です：
|
||||
|
||||
|
||||
最終的に期待通りの結果が得られます：
|
||||
|
||||
|
||||
手動でのニーズフロー体験に加えて、AI に直接ニーズチェックをさせることもできます。例えば：
|
||||
|
||||
- 「最初のニーズと照合して、現在のアプリケーションがすべてのコア機能をカバーしているかチェックして。」
|
||||
- 「機能リストを作って、どれが完成、どれが未実装または体験不足かをマークして。」
|
||||
|
||||
AI は通常チェックリストを出力してくれます。結果に基づいて改善を続けるかどうかを検討できます。繰り返し修正を経て、比較的完璧なプロトタイプ結果が得られます。
|
||||
|
||||
## 5. 📚 課題：あなた独自の TikTok EC ワークベンチを複製する
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🚀 チャレンジタスク：EC素材ワークベンチを複製</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
この章のプロンプトと内容を参考に、完全なループを一回完了してください：
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>完全ループの実践</strong>
|
||||
<ul>
|
||||
<li>業務整理プロンプト生成 → 単一ページプロトタイプ生成 → マルチページプロトタイプ生成</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>成果の共有</strong>
|
||||
<ul>
|
||||
<li>プログラムのスクリーンショットを撮って皆に見せる</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>思考問題</strong>
|
||||
<ul>
|
||||
<li>次の「大規模言語モデル（LLM）とテキストから画像生成能力の統合」に向けて、前もって考えておく：あなたのワークベンチに、「AI コピー生成 / 画像生成 / スクリプト生成」などの能力をどう組み込めるか？</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 次のステップ
|
||||
|
||||
次のセクションでは、このコンテンツ制作ワークベンチを基礎として、具体的な AI 能力（テキストからテキスト、画像からテキスト、テキストから画像）を統合します。例えば：
|
||||
|
||||
- あるコンテンツタスクに対して、自動的にコピードラフトと複数のタイトル候補を生成
|
||||
- タスクの説明に基づいて自動的に画像ドラフトを生成（テキストから画像）
|
||||
- 過去のコンテンツタスクを自動分類・要約し、次のキャンペーンの企画に役立てる
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="学習を続ける"
|
||||
description="「AI 能力の統合 → 完全プロジェクトループ → デザインエンジニアリング」の順序で続けることをお勧めします。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,301 @@
|
||||
---
|
||||
title: '完全プロジェクト実践 - Demo からプロダクト級プロトタイプへ'
|
||||
description: 'Demo 段階から脱却し、プロダクトチェーンの完善、リアルな模擬データの構築、フィードバックによる迅速な反復を学び、最終的に展示・操作可能な完全な AI プロダクトプロトタイプを完成させます。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>3 日</strong>'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['ja-jp/stage-1/complete-project-practice'] ?? []
|
||||
</script>
|
||||
|
||||
# 初級五：完全プロジェクト実践
|
||||
|
||||
## 本章のガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['プロダクト思考', '模擬データ', 'インタラクション改善', 'LocalStorage']" coreOutput="1 つの機能完備な AI プロダクトプロトタイプ" expectedOutput="完全なチェーンとリアルなデータを含む Web アプリ">
|
||||
|
||||
前の章で AI 能力を組み込み、Demo は動くようになりましたが、本当の「プロダクト」からは<strong>まだ遠い</strong>です：ページをリロードすると<strong>データが消える</strong>、エラーが出ると<strong>真っ白</strong>、リストには「テストデータ 1、テストデータ 2」しかなく、ユーザーが間違って操作しても<strong>元に戻せない</strong>...
|
||||
|
||||
この章では、これらの<strong>穴をすべて埋めます</strong>。<strong>プロダクトの完全なチェーンを補完</strong>し、AI で<strong>リアルな業務データ</strong>を生成してダミーデータを置き換え、<strong>エラー処理とユーザーフィードバック</strong>を追加し、最後に<strong>人に見せられる、デモンストレーションできる</strong>完全なプロトタイプに仕上げます。
|
||||
|
||||
これは初級段階の<strong>最後の章</strong>です。この一歩を終えれば、「全くプログラミングできない」から「<strong>AI プロダクトプロトタイプを独力で作れる</strong>」への脱皮が完了します。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'チェーン完善', description: '単一機能から完全なループへ' },
|
||||
{ title: '魂を注入', description: 'リアルな業務データの模擬' },
|
||||
{ title: 'フィードバック反復', description: 'リアルなフィードバックに基づく改善' },
|
||||
{ title: '最終課題', description: 'あなたの卒業制作' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. "Happy Path" を拒否：コアチェーンの完善
|
||||
|
||||
多くの初心者がプロトタイプを作る時、往々にして「Happy Path」（最も理想的なルート）しか作りません：ユーザーがクリック → API が正常に応答 → 結果を表示。
|
||||
しかし現実世界では、物事はそう順調にはいきません。プロトタイプを本当のプロダクトのように見せるために、次のいくつかの「見えない」部分を考慮する必要があります。
|
||||
|
||||
### 1.1 「待ち状態」と「フィードバック」の追加
|
||||
|
||||
ユーザーが「コピー生成」をクリックした時、AI が応答するまでに数秒かかることがあります。画面に何の反応もなければ、ユーザーはプログラムが壊れたと思います。
|
||||
**AI IDE に Loading 状態を追加してもらいましょう：**
|
||||
|
||||
> プロンプト例：
|
||||
> 「生成ボタンをクリックした時、ボタンを『生成中...』に変更してクリック不可にし、同時に右側の領域にローディングアニメーションを表示してください。API が結果を返した後にのみ、元の状態に戻してください。」
|
||||
|
||||
### 1.2 「失敗」と「異常」の処理
|
||||
|
||||
API Key が期限切れになる可能性もあり、ネットワークが切断される可能性もあります。
|
||||
**AI IDE にエラー処理を追加してもらいましょう：**
|
||||
|
||||
> プロンプト例：
|
||||
> 「API リクエストが失敗した場合、コンソールに直接エラーを出すのではなく、ページ上部に赤いプロンプトボックス（Toast）を表示し、ユーザーに『生成に失敗しました。後でもう一度お試しください』と伝え、ユーザーが再度生成をクリックできるようにしてください。」
|
||||
|
||||
### 1.3 会話履歴の永続化
|
||||
|
||||
AI とのやり取りの中で、会話内容を保存し、ユーザーが履歴を振り返り、以前の交流を続けられるようにする必要があります。現段階ではデータベースを導入せず、次のような軽量ソリューションを選択できます：
|
||||
|
||||
**ストレージソリューションの選択：**
|
||||
|
||||
| ソリューション | 適用シーン | 特徴 |
|
||||
| --- | --- | --- |
|
||||
| **LocalStorage** | 純フロントエンドプロジェクト、ユーザーデータをブラウザに保存 | 実装がシンプル、リロードしても消失しない、デバイス間の同期不可 |
|
||||
| **JSON ファイル** | ローカルプロトタイプ、データをファイル形式で保存 | 構造が明確、デバッグしやすい、手動編集可能 |
|
||||
| **TXT ファイル** | 最もシンプルなソリューション、テキスト内容を素早く記録 | フォーマットが自由、互換性が高い |
|
||||
|
||||
**会話内容の例：**
|
||||
保存された会話履歴には通常、次の内容が含まれます：
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"role": "user",
|
||||
"content": "BluetoothイヤホンのTikTok販売コピーを生成して",
|
||||
"timestamp": "2026-01-20 10:30:00"
|
||||
},
|
||||
{
|
||||
"role": "assistant",
|
||||
"content": "【Bluetoothイヤホンおすすめコピー】\n\n🎧 レイテンシフリー、没入型リスニング体験\n\nみんな！このBluetoothイヤホン本当に最高👇\n\n✅ 40dBアクティブノイズキャンセリング、一瞬で音楽の世界へ\n✅ 30時間の超長バッテリー、1週間の通勤で充電不要\n✅ 通話クリアさは対面と同じ、地下鉄の騒音でも会話可能\n✅ 半インイヤー設計、長時間着用でも痛くない、圧迫感なし\n\n💰 期間限定キャンペーン、下のリンクをクリックしてゲット！",
|
||||
"timestamp": "2026-01-20 10:30:05"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
**実装プロンプト：**
|
||||
|
||||
> 「会話履歴の保存機能を実装してください。ユーザーと AI の会話記録を JSON ファイルとして保存（または LocalStorage を使用）することをサポートしてください。ページに入るたびに自動的に履歴会話を読み込み、個別の会話記録の表示と削除をサポートしてください。」
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: 'チェーン完善', description: '単一機能から完全なループへ' },
|
||||
{ title: '魂を注入', description: 'リアルな業務データの模擬' },
|
||||
{ title: 'フィードバック反復', description: 'リアルなフィードバックに基づく改善' },
|
||||
{ title: '最終課題', description: 'あなたの卒業制作' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. 魂を注入：リアルデータの模擬（Mock Data）
|
||||
|
||||
空っぽのページは人を感動させられません。想像してみてください、「EC素材ワークベンチ」を他人に見せようとして、履歴記録が空っぽ、あるいは「test / test / test」の一行しかない場合。
|
||||
デモンストレーション効果を最高にするために、リアルなデータを「偽造」して、プロトタイプが半年間運営された本当のプロダクトのように見せる必要があります。
|
||||
|
||||
### 2.1 AI にデータ構造を設計させる
|
||||
|
||||
各フィールドが何と呼ばれるべきか（例えば `name` か `title` か）を自分で考える必要はありません。これは完全に AI に任せられます。
|
||||
|
||||
あなたは **業務シーン** を AI に伝えるだけでいいです：
|
||||
|
||||
> **プロンプト例：**
|
||||
> 「**TikTok EC素材ワークベンチ**のプロトタイプを作っています。
|
||||
> 『商品タスク』を記述するための JSON データ構造を設計してください。
|
||||
> このタスクには：商品の基本情報（名前、カテゴリ）、入力素材（画像リンク）、および AI が生成した結果（タイトル、コピー、ポスター画像）が含まれるべきです。
|
||||
> JSON の例を直接ください。」
|
||||
|
||||
AI はあなたの説明に基づいて、`productName`、`generatedContent` のようなフィールドを自動的に考えてくれます。
|
||||
|
||||
### 2.2 AI に「リアルな」データを批量生成させる
|
||||
|
||||
データ構造ができたら、次は AI に「穴埋め」をさせ、リアルに見えるデータを批量生成させます。
|
||||
|
||||
**プロンプトのコツ：**
|
||||
AI に「データを生成して」とだけ伝えるのではなく、インターンにタスクを割り当てるように、**業務背景**と**内容要件**を伝える必要があります：
|
||||
|
||||
- **業務背景**：AI に私たちが「TikTok EC」をやっていることを伝え、商品タイトルは目を引くものに（例えば「スタイルアップ神器」「学生必須」）、コピーは口語体にする
|
||||
- **画像要件**：プロトタイプを美しく見せるため、画像はモノクロのプレースホルダーではなく、ランダムなカラフルな風景画や実物写真が望ましい
|
||||
|
||||
> **プロンプト例：**
|
||||
> 「先ほど設計した構造に基づいて、10 件のリアルな模擬データを生成してください。
|
||||
> （注意：必ずしも JSON 形式である必要はありません。フロントエンドを書いているなら JavaScript 配列として生成させてもいいし、Python を使っているなら List として生成させても構いません。）
|
||||
>
|
||||
> **業務シーンの要件**：
|
||||
>
|
||||
> 1. ここは総合百貨店で、商品は「レディース」「デジタル」「コスメ」の 3 カテゴリにまたがると仮定する。
|
||||
> 2. **生成されたタイトルとコピーは非常に「TikTok風」にする**：例えばタイトルには Emoji (🔥, ✨) を含め、コピーは「最高」「実測おすすめ」といった口調にする。
|
||||
> 3. **画像フィールド**：`https://picsum.photos/seed/{random_id}/300/400` という形式を統一して使用し、各画像が異なるようにする。」
|
||||
|
||||
**生成された Mock Data の例：**
|
||||
|
||||
```javascript
|
||||
export const mockProductTasks = [
|
||||
{
|
||||
id: 'task_001',
|
||||
name: '夏用フレンチレトロ花柄ワンピース',
|
||||
status: 'completed',
|
||||
input: {
|
||||
category: 'レディース',
|
||||
features: ['ウエストマーク', 'スタイルアップ', 'エレガント'],
|
||||
originalImage: 'https://picsum.photos/seed/dress_input/300/400'
|
||||
},
|
||||
output: {
|
||||
generatedTitle: '✨誰が着ても可愛い！このフレンチ花柄ワンピース本当に最高🔥',
|
||||
generatedCopy:
|
||||
'みんな！このワンピース本当にスタイルアップ効果抜群！ウエストマークが最高で、着るとすぐウエストが見えます。生地も通気性があって、夏に着ても全く蒸れません。デートやお買い物にピッタリ！👗',
|
||||
generatedPosterImage: 'https://picsum.photos/seed/dress_output/300/400'
|
||||
},
|
||||
createdAt: '2026-01-20T10:00:00Z'
|
||||
},
|
||||
{
|
||||
id: 'task_002',
|
||||
name: '超強ノイズキャンセリング Bluetooth イヤホン Pro',
|
||||
status: 'completed',
|
||||
input: {
|
||||
category: 'デジタル',
|
||||
features: ['ノイズキャンセリング', '超長バッテリー', '低レイテンシ'],
|
||||
originalImage: 'https://picsum.photos/seed/tech_input/300/400'
|
||||
},
|
||||
output: {
|
||||
generatedTitle: '🎧 ついに見つけた！このイヤホンのノイズキャンセリングすごすぎ！🔇',
|
||||
generatedCopy:
|
||||
'これを着けると、世界が一瞬で静かになります。音質も最高で、音楽を聴くとまるで現場にいるみたい。バッテリーも申し分なく、1回の充電で1週間使えます！学生必須アイテム！',
|
||||
generatedPosterImage: 'https://picsum.photos/seed/tech_output/300/400'
|
||||
},
|
||||
createdAt: '2026-01-21T14:30:00Z'
|
||||
}
|
||||
// ... その他のデータ
|
||||
]
|
||||
```
|
||||
|
||||
### 2.3 （応用）LocalStorage を使って「擬似的な追加・削除・更新」を実装
|
||||
|
||||
先ほど生成した「模擬データ」をただ見るだけでなく、削除も修正もでき、さらに新しく生成したタスクがページをリロードしても残るようにしたい場合は、`LocalStorage` と組み合わせることができます。
|
||||
|
||||
> **プロンプト例：**
|
||||
> 「データストレージ機能を実装してください。
|
||||
>
|
||||
> 1. `localStorage` から優先的にデータを読み込む。
|
||||
> 2. `localStorage` が空の場合、先ほど生成した Mock データで初期化し、それらを `localStorage` に保存する。
|
||||
> 3. 同時に `addProductTask` と `deleteProductTask` 関数を書き、毎回の操作後に `localStorage` を同期して更新する。」
|
||||
|
||||
このステップにより、プロトタイプは「記憶」を持ち、ユーザー体験はほぼ本物のプロダクトと変わりません。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: 'チェーン完善', description: '単一機能から完全なループへ' },
|
||||
{ title: '魂を注入', description: 'リアルな業務データの模擬' },
|
||||
{ title: 'フィードバック反復', description: 'リアルなフィードバックに基づく改善' },
|
||||
{ title: '最終課題', description: 'あなたの卒業制作' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 3. フィードバックの収集と迅速な反復
|
||||
|
||||
部屋に閉じこもっていては良いプロダクトは作れません。今、あなたのプロトタイプは「コア機能」+「完全なチェーン」+「デモデータ」を備えています。いよいよ他人に見せましょう。
|
||||
|
||||
### 3.1 誰にテストしてもらう？どうテストする？
|
||||
|
||||
- **友達や同僚に頼む**：技術を理解している必要はなく、ちょっと使ってみてもらうだけでOK
|
||||
- **誘導せずに観察する**：「ここをクリックして」と言うのではなく、彼らがどこをクリックするかを見る。ボタンが見つからなければ、デザインに問題があるということ
|
||||
- **「オズの魔法使い」法**：AI がまだ接続できていなければ、裏側（またはデータベース）で手動でデータを修正して AI の戻り値を模擬し、ユーザーがこの機能を必要としているかを先に検証する
|
||||
|
||||
### 3.2 バグと不満への対応
|
||||
|
||||
- **レイアウト崩れ**：異なる画面サイズで崩れる可能性がある
|
||||
- **アクション**：スクリーンショットを撮って AI IDE に送る → 「この画面幅で崩れています。修正してください。」
|
||||
- **操作が煩わしい**：「このプロセスは複雑すぎる」
|
||||
- **アクション**：提案を AI IDE に伝える → 「ユーザーがアップロードしてから生成するまで遅すぎると感じています。ワンクリック生成に変更できませんか？」
|
||||
- **新機能の要望**：「この機能があればいいのに」
|
||||
- **アクション**：コアかどうかを評価し、コアなら AI に簡易版を迅速に実装させる
|
||||
|
||||
**覚えておいてください：この段階では、AI はあなたの最良の修正アシスタントです。問題を見つけるのはあなたの役割で、コードの修正は AI に任せましょう。**
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: 'チェーン完善', description: '単一機能から完全なループへ' },
|
||||
{ title: '魂を注入', description: 'リアルな業務データの模擬' },
|
||||
{ title: 'フィードバック反復', description: 'リアルなフィードバックに基づく改善' },
|
||||
{ title: '最終課題', description: 'あなたの卒業制作' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 4. 🎓 ステージ最終課題：あなたの「卒業制作」を完成させよう
|
||||
|
||||
おめでとう！あなたは「ニーズ」から「プロトタイプ」、そして「AI 統合」までの全プロセスを歩み終えました。いよいよ最終成果を披露する時です。
|
||||
|
||||
**今回の最終課題は「EC素材ワークベンチ」に限定されません。** 自分の興味や業界のバックグラウンドと組み合わせて、唯一無二の AI プロダクトプロトタイプを作り上げる必要があります。
|
||||
|
||||
### テーマ選びと要件
|
||||
|
||||
**[産業多分類シーン方向リファレンス](../appendix-industry-scenarios/index.md)** から最も近いシーンを一つ選ぶか、自分のアイデアに基づいて全く新しいシーンを構想してください。
|
||||
|
||||
**プロジェクトは前の章で学んだすべての内容を総合的に活用する必要があります：**
|
||||
|
||||
1. **プロトタイプの構築**：フロントエンド技術を使って美しく使いやすいインターフェースを構築する
|
||||
2. **ニーズの制御**：大いに全てを求めるのではなく、コア機能の論理的なループを完成させる
|
||||
3. **API の統合**：リアルな AI モデル（LLM/VLM など）を統合し、アプリケーションに真のインテリジェンスを付与する
|
||||
4. **遊べるアプリケーションを実装する**：静的ページではなく、データフローとインタラクションフィードバックのある動的アプリケーション
|
||||
|
||||
### 課題の成果物
|
||||
|
||||
最終的に以下の 2 つを提出する必要があります：
|
||||
|
||||
1. **完全なプロトタイプアプリケーション**：デプロイされてオンラインで動作、またはローカルで実行可能で、完全な使用チェーンを備える
|
||||
2. **30 秒のデモ動画**：アプリケーションのシーンを簡単に紹介し、コア機能の実際の操作をデモンストレーションする動画
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🚀 最終チャレンジリスト</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
これは Stage 1 の最後の戦いです。以下のリストに従って作品をチェックしてください：
|
||||
</p>
|
||||
|
||||
<div style="font-weight: bold; margin-bottom: 10px;">コア機能セルフチェック</div>
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> <strong>シーンが明確</strong>：特定の業界またはアプリケーションシーンを選択している</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>論理的ループ</strong>：コアプロセスが通っており、Happy Path だけではない</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>AI 駆動</strong>：大規模モデル API をリアルに呼び出しており、事前設定された返答ではない</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>体験が完全</strong>：Loading、エラー処理、模擬データを含む</label></li>
|
||||
</ul>
|
||||
|
||||
<div style="font-weight: bold; margin: 20px 0 10px;">成果物の準備</div>
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> <strong>プロトタイプアプリケーション</strong>：コードが完成し実行可能</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>デモ動画</strong>：30 秒程度でコアのハイライトを明確に展示</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 次のステップ
|
||||
|
||||
最終課題が完了したら、あなたは「AI アプリケーションプロトタイプを独力で開発する」能力を備えています。
|
||||
次の Stage 2 では、より複雑なフルスタック開発に深く入り込み、このプロトタイプを、データベースがあり、ユーザーシステムがある、本当にオンラインできる商業レベルのアプリケーションにする方法を学びます。
|
||||
|
||||
次のステージでお会いしましょう！
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="さらにステップアップ"
|
||||
description="Stage 1 完了おめでとう、以下の章がエンジニアリング開発に進むのに役立ちます。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1 @@
|
||||
../../../zh-cn/stage-1/integrating-ai-capabilities/images
|
||||
@@ -0,0 +1,808 @@
|
||||
---
|
||||
title: 'プロトタイプに AI 能力を追加 - テキストと画像 API の統合'
|
||||
description: '既存の Web プロトタイプに本物の AI 能力を統合する：API の核心概念を理解し、API Key と公式サンプルの見つけ方を習得。DeepSeek テキストモデルと各種画像生成サービス（SiliconFlow Qwen-Image、Recraft、Seedream）の実践的統合、およびモデル選定の一般的な方法を習得します。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>1 日</strong>'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['zh-cn/stage-1/integrating-ai-capabilities'] ?? []
|
||||
</script>
|
||||
|
||||
# 初級四：プロトタイプに AI 能力を注入する
|
||||
|
||||
## 章節ガイド
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['API', 'テキストモデル', 'テキストから画像', 'プロトタイプ統合']" coreOutput="プロトタイプに1つのテキストモデル＋1つの画像モデルを統合（画像はオプション）" expectedOutput="実際の API を呼び出せる AI プロトタイプ">
|
||||
|
||||
前の章では、<strong>良いアイデアを見つける</strong>ことから<strong>プロダクトプロトタイプを作る</strong>ことまでの完全なフローを完了しました。しかし、現在のプロトタイプはまだ「空っぽの殻」です——ボタンをクリックしてもコンテンツは本当に生成されず、ページ上のデータはすべて固定値です。
|
||||
|
||||
第1章で強調したことを覚えていますか？<strong>私たちは「人が支払うプロダクト」を作りたいのであって、「見た目がまともなプロトタイプ」を作りたいのではない。</strong> 本当の価値はプロダクトが<strong>本当の問題を解決</strong>することから生まれ、そのためにはプロトタイプが<strong>本当に動く</strong>必要があります。
|
||||
|
||||
この章では、プロトタイプを<strong>「生きたもの」</strong>にします：<strong>実際の AI 能力</strong>を統合し、API Key の取得から、公式ドキュメントの読解、AI IDE にインターフェースの統合を任せるまでをカバーします。<strong>DeepSeek テキストモデル</strong>を例に、アプリケーションが<strong>実際に大規模モデルを呼び出してコンテンツを生成</strong>する方法を学びます。興味があれば、<strong>画像生成の統合（オプション）</strong>にも挑戦できます。
|
||||
|
||||
この章を学び終えると、プロトタイプは<strong>静的なデモではなくなります</strong>。それは<strong>実際の AI 能力を呼び出し、本当の問題を解決できるアプリケーション</strong>になります。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'API 基礎', description: '核心概念とセキュリティ規範を理解' },
|
||||
{ title: 'テキスト統合', description: 'DeepSeek テキスト生成実践' },
|
||||
{ title: '画像統合', description: 'VLM 画像理解と生成' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
# 1. API の基礎概念
|
||||
|
||||
前述の通り、私たちの目標は「AI 能力を組み込む」ことで、プロトタイプを静的なデモではなく、実際の AI サービスを呼び出せるツールにすることです。これを実現する鍵は、API（Application Programming Interface）を理解し、使用することです。
|
||||
|
||||
API はコンピュータサイエンスにおける重要な抽象概念で、簡単に理解できます：**相手が指定した形式で「質問」を送ると、相手も同じ形式で「結果」を返す**。
|
||||
|
||||
- **あなたが送る内容**：通常は「API Key」と「何を生成したいか」
|
||||
- **相手が返す内容**：成功すれば結果を返す。失敗すれば理由を伝える（「Key が間違っている」「残高不足」「パラメータエラー」など）
|
||||
|
||||
具体的には、以下の核心的な要素を把握する必要があります：
|
||||
|
||||
1. **API Key**：あなたの「通行証」であり「財布の鍵」。他人に渡されると、あなたの代わりに API を呼び出して費用が発生します。
|
||||
2. **Endpoint（エンドポイント）**：API リクエストの具体的なパスで、どの機能にアクセスするかをサーバーに伝えます。完全なリクエスト URL は通常「ベース URL ＋ Endpoint パス」で構成されます。例：
|
||||
- テキスト生成：ベースURL (`https://api.service.com`) ＋ Endpoint (`/v1/chat/completions`) ＝ 完全URL `https://api.service.com/v1/chat/completions`
|
||||
- 画像生成：ベースURL (`https://api.service.com`) ＋ Endpoint (`/v1/images/generations`) ＝ 完全URL `https://api.service.com/v1/images/generations`
|
||||
3. **呼び出し/リクエスト**：AI サービスにタスクを送信し、結果を取得するプロセス
|
||||
4. **リクエスト内容**：AI に送信する具体的な内容。AI に書かせたい記事のテーマ、生成したい画像の説明など。
|
||||
5. **レスポンス結果**：AI が処理完了後に返す内容。生成された記事、画像など。
|
||||
6. **エラーハンドリング**：問題が発生した時（API Key エラー、リクエスト過多など）、どのようにトラブルシューティングするか。
|
||||
|
||||
::: info ℹ️ API とは
|
||||
API についてのより深い解説は、付録の [API 入門](/zh-cn/appendix/4-server-and-backend/api-intro) をご覧ください。
|
||||
|
||||
::: warning 🔐 **API セキュリティに関する注意事項**
|
||||
API Key は AI サービスにリクエストするための「通行証」であり、認証と課金に使用されるパスワード文字列です。
|
||||
|
||||
API Key はアカウントと課金に直接関連しているため、以下の点に注意してください：
|
||||
|
||||
- 絶対に<strong>グループチャット、スクリーンショットのネット投稿</strong>、公開フォーラムへの投稿はしない
|
||||
- <strong>コードにハードコードして Git リポジトリにコミットしない</strong>（特に公開リポジトリ）
|
||||
- Key の漏洩が疑われる場合は、<strong>直ちに新しい Key に変更する</strong>
|
||||
|
||||
以下の内容では、<strong>API KEY を AI IDE に直接貼り付けて操作</strong>します。<strong>正式なプロジェクトでは絶対にこの方法を使わないでください！！</strong>練習なのでこの方法を使います。（より熟练になったら、AI に設定ファイルを生成させ、API KEY を設定ファイルに配置するだけで済みます）
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: 'API 基礎', description: '核心概念とセキュリティ規範を理解' },
|
||||
{ title: 'テキスト統合', description: 'DeepSeek テキスト生成実践' },
|
||||
{ title: '画像統合', description: 'VLM 画像理解と生成' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
# 2. テキスト生成 API の統合：DeepSeek
|
||||
|
||||
API にはこれらの技術概念が含まれますが、プロトタイプ開発段階では、実際の操作は非常にシンプルで効率的です。核心的なアプローチは：
|
||||
|
||||
> **公式サンプルを見つけ、API Key を取得し、AI IDE にボタンに統合させる。**
|
||||
|
||||
これらの概念を習得すると、テキストモデルでも画像モデルでも、本質的なフローは同じことがわかります：ユーザーがボタンをクリックすると、フロントエンドが入力を整理してリクエストを送信し、インターフェースが結果を返したら、ページに結果を表示する。次に、実際の操作でこれを確認します。
|
||||
|
||||
`1.2 プロトタイプを作る` で、あなたはすでにインタラクティブなプロトタイプを作りました。次にやることは、プロトタイプの中の「AI のように見える機能」を本当に使える能力に変えることです：**ユーザーがボタンをクリックすると、プロトタイプが外部の AI サービスにリクエストを送信し、返されたテキストを表示する。**
|
||||
|
||||
::: info ℹ️ 原理の詳細
|
||||
原理に関する詳細を知りたい場合は、付録の [大規模言語モデル（LLM）入門](/zh-cn/appendix/8-artificial-intelligence/llm-principles) をご覧ください。
|
||||
::: details 詳細：DeepSeek とは？
|
||||
|
||||
**杭州深度求索人工知能基礎技術研究有限公司**（Hangzhou DeepSeek Artificial Intelligence Basic Technology Research Co., Ltd.）、DeepSeek を商号とする、<strong>大規模言語モデル（LLMs）を開発する中国の人工知能（AI）企業</strong>です。DeepSeek は本社を浙江省杭州に置き、中国のヘッジファンド幻方量化（High-Flyer）に所有・資金提供されています。DeepSeek は幻方量化の共同創業者である梁文鋒氏によって2023年7月に設立され、彼は両社の CEO も務めています。同社は2025年1月に同名のチャットボットと DeepSeek-R1 モデルをリリースしました。
|
||||
|
||||
DeepSeek の GPQA ベンチマークランキングにおける他のトップモデルとのパフォーマンス比較を見てみましょう。注目すべきは、DeepSeek はオープンソース（誰でもインターネットからモデルをダウンロード可能）モデルですが、Grok、Google Gemini、ChatGPT などの一般的なモデルはクローズドソースです。ご覧の通り、DeepSeek はすでに第一陣のモデルに大きく迫っています。
|
||||
|
||||
|
||||
|
||||
GPQA は「大学院レベル Google-Proof Q&A ベンチマーク」の略で、科学 Q&A タスクのための大学院レベルのベンチマークです。詳細は以下の通りです。
|
||||
|
||||
GPQA は448の多肢選択問題を含み、生物学、物理学、化学のサブ分野（量子力学、有機化学、分子生物学など）をカバーしています。これらの問題は61人の博士号取得者または博士課程在籍中の専門家によって作成され、厳格な検証プロセスを経ています。
|
||||
:::
|
||||
|
||||
この3ステップに従えば、大規模モデル生成 API の迅速な統合が可能です：
|
||||
|
||||
1. **DeepSeek プラットフォームで API Key を作成する**
|
||||
2. **DeepSeek ドキュメントでテキスト生成サンプルを見つける**（通常はコピペで使えるサンプルコードがある）
|
||||
3. **AI IDE を開き、API Key ＋公式サンプルを貼り付け**、AI に実現したい機能を伝える：
|
||||
> この大規模モデルの API を統合して、このアプリのコピーライティング生成タスクをサポートしてください
|
||||
|
||||
次にデモを行います。以下の全フローに沿って操作できます。まず [DeepSeek](https://platform.deepseek.com/usage) にアカウントを登録し、API Key を作成して、少額をチャージして検証します。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
「API KEYS」をクリックし、画面下部の「create new API key」を見つけます。最終的に `sk-8573341c39fc44315aadc071c53rh7d2` のような API key が得られます。
|
||||
|
||||
|
||||
|
||||
Key を取得すると、モデルを呼び出す権限を持てます。
|
||||
|
||||
ここで、[API](https://api-docs.deepseek.com/) ドキュメントを直接読むことができます。通常、curl または Python の呼び出しサンプルが提供されています。
|
||||
|
||||
|
||||
|
||||
サンプルを見つけたら、ドキュメントの内容と Key をすべて AI IDE のチャットボックスにコピーし、大規模言語モデルを既存のプロトタイプに統合するよう依頼できます。
|
||||
|
||||
|
||||
|
||||
プロンプトの参考：
|
||||
|
||||
```
|
||||
この呼び出し方法を参考に、コピーライティング生成機能をサポートしてください。商品情報に基づいてクリックすると対応する Douyin EC 用のキャッチコピーを生成し、複数のスタイルをサポートするようにしてください。
|
||||
|
||||
以下の参考資料：
|
||||
api key：sk-8573341c39aefa1efe
|
||||
api リクエスト参考：
|
||||
curl \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
|
||||
-d '{
|
||||
"model": "deepseek-chat",
|
||||
"messages": [
|
||||
{"role": "system", "content": "You are a helpful assistant."},
|
||||
{"role": "user", "content": "Hello!"}
|
||||
],
|
||||
"stream": false
|
||||
}'
|
||||
```
|
||||
|
||||
AI のコード生成をしばらく待つと、対応するコピーライティング生成ボタンを簡単にテストできます。入口が見つからない場合は、AI IDE にどのページからそのページにアクセスできるか聞いてください。どうしても見つからない場合は、AI IDE に直接アイデアに基づいてリファクタリングと改良を依頼して、最終的なコピーライティング生成結果を得てください。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
もちろん、ここで「本当に大規模モデルを呼び出しているのか、固定のレスポンスを内蔵しているだけなのか、どうやって確認するの？」と思うかもしれません。カスタムのテキストを入力して、大規模モデルがあなたが即座に指定したカスタム分析に基づいて対応するコピーライティングを生成させることで確認できます。
|
||||
|
||||
毎回結果が異なり、論理的であれば、API が正常に呼び出されていると安心できます。[API 使用管理プラットフォーム](https://platform.deepseek.com/usage)で呼び出しが成功したかどうかも確認できます（数分待つ必要がある場合があります）。
|
||||
|
||||
## さらに多くのテキスト生成モデルの選択
|
||||
|
||||
DeepSeek 以外にも、他の大規模言語モデルも試せます。ほとんどのモデルは **OpenAI 互換インターフェース** を提供しているため、切り替えは非常に簡単です——API Key、ベース URL、モデル名を変更するだけです。
|
||||
|
||||
### MiniMax 統合
|
||||
|
||||
::: details 詳細：MiniMax とは？
|
||||
|
||||
**MiniMax** は中国の人工知能企業で、汎用人工知能技術の研究開発に取り組んでいます。MiniMax は自社開発の MiniMax-M2.7 大規模言語モデルシリーズをリリースしており、多くのベンチマークテストで優れたパフォーマンスを示し、非常に高いコストパフォーマンスを誇ります。
|
||||
|
||||
**MiniMax-M2.7 シリーズの主な特徴：**
|
||||
|
||||
- **超長いコンテキスト**：204,800 トークンのコンテキストウィンドウをサポート。長文書、多ラウンド対話に適している
|
||||
- **高コストパフォーマンス**：非常に競争力のある価格
|
||||
- **OpenAI 互換インターフェース**：OpenAI SDK を直接使用して呼び出し可能。新しい API 形式を学ぶ必要がない
|
||||
- **2つの利用可能なモデル**：
|
||||
- `MiniMax-M2.7`：フラグシップモデル、複雑なタスクに適している
|
||||
- `MiniMax-M2.7-highspeed`：高速版、同じパフォーマンスを維持しながらより高速
|
||||
:::
|
||||
|
||||
統合方法は DeepSeek と同じで、3ステップだけです：
|
||||
|
||||
1. [MiniMax オープンプラットフォーム](https://platform.minimax.io/) にアクセスしてアカウントを登録し、API Key を作成
|
||||
2. MiniMax ドキュメントで呼び出しサンプルを見つける
|
||||
3. API Key ＋サンプルを AI IDE に貼り付ける
|
||||
|
||||
MiniMax は OpenAI 互換インターフェースを提供しているため、以下の curl サンプルとあなたの API Key をコピーして、AI IDE に統合を依頼できます：
|
||||
|
||||
```bash
|
||||
curl https://api.minimax.io/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer ${MINIMAX_API_KEY}" \
|
||||
-d '{
|
||||
"model": "MiniMax-M2.7",
|
||||
"messages": [
|
||||
{"role": "system", "content": "You are a helpful assistant."},
|
||||
{"role": "user", "content": "Hello!"}
|
||||
],
|
||||
"stream": false
|
||||
}'
|
||||
```
|
||||
|
||||
::: tip ✅ ヒント
|
||||
MiniMax の API 形式は DeepSeek とほぼ完全に同じです（どちらも OpenAI 互換形式）。したがって、DeepSeek の統合がすでに成功していれば、MiniMax に切り替えるには3つの箇所を変更するだけです：
|
||||
1. **ベース URL**：`https://api.minimax.io/v1` に変更
|
||||
2. **API Key**：MiniMax の API Key を使用
|
||||
3. **モデル名**：`MiniMax-M2.7` または `MiniMax-M2.7-highspeed` に変更
|
||||
|
||||
詳細は [MiniMax OpenAI 互換インターフェースドキュメント](https://platform.minimax.io/docs/api-reference/text-openai-api) を参照してください。
|
||||
:::
|
||||
|
||||
# 3. 画像からテキスト API の統合：Qwen3 VL
|
||||
|
||||
::: info ℹ️ 原理の詳細
|
||||
原理に関する詳細を知りたい場合は、付録の [視覚言語モデル（VLM）入門](/zh-cn/appendix/8-artificial-intelligence/multimodal-models) をご覧ください。
|
||||
|
||||
::: details 詳細：Qwen3 VL とは？
|
||||
|
||||
**Qwen3 VL** はアリババクラウドの通義千問チームがリリースしたマルチモーダル視覚言語モデルシリーズの最新版です。VL は「Vision-Language」、つまり視覚言語モデルを表します。画像内容を理解し、画像に基づいてテキストの説明を生成、画像に関する質問に回答、画像情報の抽出などができます。
|
||||
|
||||
|
||||
|
||||
|
||||
**Qwen3 VL の主な機能：**
|
||||
|
||||
- **画像理解**：画像中の物体、シーン、人物、テキストなどを認識
|
||||
- **視覚 QA**：ユーザーの質問に基づき、画像に関する質問に正確に回答
|
||||
- **画像説明**：詳細または簡潔な画像のテキスト説明を生成
|
||||
- **複数画像理解**：複数の画像を同時に処理し、比較分析をサポート
|
||||
- **テキスト抽出**：画像からテキスト内容を抽出（OCR 機能）
|
||||
|
||||
**なぜ Qwen3 VL を選ぶのか？**
|
||||
|
||||
前世代モデルと比較して、Qwen3 VL は画像理解の正確さが大幅に向上し、より長く複雑な画像分析タスクをサポートしています。中国語理解で優れたパフォーマンスを示し、API 呼び出しコストが比較的低く、コストパフォーマンスが高いです。また、コンテキストウィンドウが大きく、より複雑な視覚推論タスクを処理できます。
|
||||
|
||||
**典型的な応用シーン：**
|
||||
|
||||
- EC：商品画像から自動的にタイトル、説明、セールスポイントを生成
|
||||
- コンテンツ制作：素材画像に基づいて自動的にコピーや画像提案を生成
|
||||
- オフィス：画像内容の抽出、帳票の自動認識
|
||||
- 教育：画像問題の自動解析、知識ポイントの抽出
|
||||
|
||||
:::
|
||||
|
||||
前のパートではテキスト生成 API の統合方法について説明しましたが、前のアプリケーションシーンでは一つの問題に気づきます。アップロードするのは画像ですが、大規模言語モデルだけでは画像の内容をうまく理解できず、生成結果に差が出る可能性があります。
|
||||
|
||||
画像をテキストの説明に変換してくれるモデルが欲しい。これには視覚言語モデル（VLM）が必要です。このケースでは、視覚言語モデルを使って商品のセールスポイント説明を生成し、ユーザー体験を向上させます。
|
||||
|
||||
利便性のため、[クラウドプラットフォーム SiliconFlow](https://cloud.siliconflow.cn/me) が提供する API インターフェースを使用して、画像からテキストへの API を統合します。
|
||||
|
||||
::: details 詳細：SiliconFlow とは？
|
||||
**硅基流動（SiliconFlow）** は中国国内で有名な AI モデル集約プラットフォームで、各種主流の大規模言語モデルと視覚言語モデルの API インターフェースサービスを提供しています。
|
||||
|
||||
**プラットフォームの特徴：**
|
||||
|
||||
- **多モデルサポート**：DeepSeek、Qwen、Llama シリーズなどのオープンソースモデルを含む各種主流 AI モデルを統合
|
||||
- **技術最適化**：オープンソースモデルの推論を最適化し、低遅延・高並行の API サービスを提供
|
||||
- **インターフェース互換**：OpenAI 形式と互換性のある API インターフェースを提供。既存のアプリケーション統合に便利
|
||||
- **従量課金**：呼び出し量に応じた課金に対応
|
||||
|
||||
SiliconFlow はオープンソース大規模モデルの推論サービスで比較的成熟しており、中国産オープンソース AI モデルを使用する際の一般的な選択肢の一つです。
|
||||
:::
|
||||
|
||||
SiliconFlow プラットフォームのホームページに入ると、多くのモデルが選択できることがわかります。左上のフィルターを見つけて展開し、視覚タグを選択すると、智譜 GLM-4.6V や Qwen3-VL など、多くの画像からテキストへのモデルが表示されます。
|
||||
|
||||
|
||||
|
||||
どれでも選んでテストできます。ここでは `Qwen/Qwen3-VL-8B-Instruct` を例にします。
|
||||
|
||||
|
||||
|
||||
[SiliconFlow プラットフォーム](https://cloud.siliconflow.cn/me/account/ak) に入り、API キーで「新建 API 密钥」をクリックして、新しい API Key を作成します。
|
||||
|
||||
以下のコードを参考コードとして、生成した API Key と一緒に AI IDE に送信し、機能統合を行えます。
|
||||
|
||||
::: details 画像からテキストへの参考コード
|
||||
|
||||
```python
|
||||
from openai import OpenAI
|
||||
from typing import Dict, Any, List
|
||||
import base64
|
||||
import os
|
||||
SILICONFLOW_API_KEY: str = ""
|
||||
SILICONFLOW_BASE_URL: str = "https://api.siliconflow.cn/v1/"
|
||||
MODEL_NAME: str = "Qwen/Qwen3-VL-8B-Instruct"
|
||||
|
||||
def encode_image(image_path: str) -> str:
|
||||
with open(image_path, "rb") as image_file:
|
||||
return base64.b64encode(image_file.read()).decode('utf-8')
|
||||
|
||||
def get_vlm_completion(client: OpenAI, messages: List[Dict[str, Any]]) -> str:
|
||||
response = client.chat.completions.create(
|
||||
model=MODEL_NAME,
|
||||
messages=messages,
|
||||
max_tokens=512,
|
||||
temperature=0.7,
|
||||
top_p=0.7,
|
||||
frequency_penalty=0.5,
|
||||
stream=False,
|
||||
n=1
|
||||
)
|
||||
return response.choices[0].message.content
|
||||
|
||||
def caption_image(image_path: str) -> str:
|
||||
base64_image = encode_image(image_path)
|
||||
messages = [
|
||||
{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{
|
||||
"type": "text",
|
||||
"text": "Please describe this image in detail."
|
||||
},
|
||||
{
|
||||
"type": "image_url",
|
||||
"image_url": {
|
||||
"url": f"data:image/jpeg;base64,{base64_image}"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
client = OpenAI(
|
||||
api_key=SILICONFLOW_API_KEY,
|
||||
base_url=SILICONFLOW_BASE_URL
|
||||
)
|
||||
|
||||
return get_vlm_completion(client, messages)
|
||||
|
||||
image_path = "images.jpg"
|
||||
caption = caption_image(image_path)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
このシーンでは、AI IDE にアップロードされた画像から EC のセールスポイントテキストやキーワードを自動生成する機能を実装させます。以下のように指示します：
|
||||
|
||||
```
|
||||
以下の画像からテキストへの API を基に、アップロードされた画像から EC のセールスポイントテキストとキーワードを自動生成する機能を実装してください。
|
||||
|
||||
<ここにコードを省略、キーと参考コードを自分で貼り付ける必要があります>
|
||||
```
|
||||
|
||||
最終的に生成結果が得られます：
|
||||
|
||||
|
||||
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: 'API 基礎', description: '核心概念とセキュリティ規範を理解' },
|
||||
{ title: 'テキスト統合', description: 'DeepSeek テキスト生成実践' },
|
||||
{ title: '画像統合', description: 'VLM 画像理解と生成' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
# 4. 画像生成 API の統合：Seedream 即梦
|
||||
|
||||
前のパートでは主にテキスト関連のタスクを扱いました。次は画像生成機能の統合に挑戦し、テキストの説明から画像を生成したり、画像を編集したりできるようにします。
|
||||
|
||||
::: info ℹ️ 原理の詳細
|
||||
原理に関する詳細を知りたい場合は、付録の [画像生成入門](/zh-cn/appendix/8-artificial-intelligence/image-generation) をご覧ください。
|
||||
|
||||
::: details 詳細：[Seedream 即梦](https://seed.bytedance.com/en/seedream4_5) とは？
|
||||
|
||||
|
||||
|
||||
> Google が開発した Nano Banana は知っているかもしれませんが、Seedream も見逃せません。Seedream 4.5 は ByteDance が開発した次世代画像クリエイティブモデルです。画像生成と画像編集の機能を統一アーキテクチャに統合しています。これにより、知識に基づく生成、複雑な推論、参照の一貫性などの複雑なマルチモーダルタスクを柔軟に処理できます。さらに、推論速度は前世代より大幅に高速で、最大4K解像度の驚くべき高画質画像を生成できます。
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
**主な機能：**
|
||||
|
||||
- **テキストから画像（文生图）**：テキストの説明から画像を生成。複数のスタイル（リアル、カートゥーン、水墨、サイバーパンクなど）をサポート
|
||||
- **スタイル変換**：画像を指定したアートスタイルに変換
|
||||
- **画像バリエーション**：参照画像に基づいて類似スタイルの新しい画像を生成
|
||||
- **解像度向上**：画像の鮮明さとディテールを向上
|
||||
- **画像編集**：自然言語の指示で既存の画像を編集・修正
|
||||
|
||||
**なぜ Seedream を選ぶのか？**
|
||||
|
||||
- **国内ネットワークが安定**：国内からのアクセスが速く、遅延が低い
|
||||
- **効果が優秀**：EC、素材シーンで安定した信頼性
|
||||
- **中国語最適化**：中国語プロンプトの理解がより正確。国内ユーザーに適している
|
||||
- **速度が速い**：生成効率が高く、レスポンスタイムが短い
|
||||
- **品質が安定**：最大4K解像度の高画質画像を生成
|
||||
|
||||
**典型的な応用シーン：**
|
||||
|
||||
- EC：メイン画像、詳細ページ画像、プロモーションポスターの生成
|
||||
- SNS：アバター、スタンプ、画像の生成
|
||||
- デザイン：コンセプトアート、素材画像、背景画像の迅速な制作
|
||||
- マーケティング：広告画像、イベントバナー、祝日ポスターの制作
|
||||
|
||||
**Qwen3 VL との連携：**
|
||||
|
||||
これら2つの API は直列で使用できます：まず Qwen3 VL で参照画像を分析し、画面内容を理解。次に Seedream で分析結果を基にプロンプトを生成し、新しい画像を作成します。
|
||||
:::
|
||||
|
||||
Douyin、Bilibili、YouTube で見かける「AI ポスター / AI メイン画像 / AI キャラクター画像」は、本質的にここで紹介する技術を使っています。あなたがやるべきことは非常にシンプルです：ユーザーの入力を一文に整理し、画像 API にリクエストを送り、返された画像を表示する。ここで使うモデルを画像生成 / 画像編集モデルと呼びます。
|
||||
|
||||
Seedream API をプロジェクトに統合する手順を順番にデモします（AI IDE のサポートを活用）。
|
||||
|
||||
[ホームページ](https://www.volcengine.com/experience/ark?launch=seedream)にアクセスし、ログインをクリックします。
|
||||
|
||||
|
||||
|
||||
ログイン後、右上のチャージオプションを見つけます。
|
||||
|
||||
|
||||
|
||||
チャージには本人確認が必要です。
|
||||
|
||||
|
||||
|
||||
認証成功後、[1元をチャージしてテスト](https://console.volcengine.com/finance/fund/recharge)できます。
|
||||
|
||||
[初期画面](https://www.volcengine.com/experience/ark?launch=seedream)に戻り、API アクセスをクリックします。
|
||||
|
||||
|
||||
|
||||
まず、API key を作成し、オプション選択をクリックします。
|
||||
|
||||
|
||||
|
||||
これでステップ2に進みます。ここで、呼び出すサービスが Seedream 4.5 であることを確認し、提供された呼び出しサンプルをコピーします。（スクリーンショットが比較的早い時期のものなので、モデルバージョンはまだ4.0です）
|
||||
|
||||
|
||||
|
||||
API Key と呼び出しサンプルの準備ができたら、AI IDE に直接貼り付けて、フロントエンドのインタラクティブデモを生成させるか、既存のプロトタイプに機能を統合させます。画像でテキストから画像か複数画像から単一画像かを選択できることに注意してください。現在のニーズに応じて参考コードを選択してください。
|
||||
|
||||
::: warning ⚠️ 重要なヒント
|
||||
ここでのデフォルトのサンプルは比較的複雑です。**「ウォーターマーク追加」** と **「ストリーミングレスポンス」** を無効にすることを忘れないでください。ウォーターマークが生成されず、リクエスト失敗が発生しないようにするためです。
|
||||
:::
|
||||
|
||||
後で参照画像生成モードを使用するため、まずは複数画像から単一画像への機能に行きます。参考コードは以下の通り：
|
||||
|
||||
```
|
||||
curl -X POST https://ark.cn-beijing.volces.com/api/v3/images/generations \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer xxxxxxx" \
|
||||
-d '{
|
||||
"model": "doubao-seedream-4-5-251128",
|
||||
"prompt": "将图1的服装换为图2的服装",
|
||||
"image": ["https://ark-project.tos-cn-beijing.volces.com/doc_image/seedream4_imagesToimage_1.png", "https://ark-project.tos-cn-beijing.volces.com/doc_image/seedream4_imagesToimage_2.png"],
|
||||
"sequential_image_generation": "disabled",
|
||||
"response_format": "url",
|
||||
"size": "2K",
|
||||
"stream": false,
|
||||
"watermark": true
|
||||
}'
|
||||
```
|
||||
|
||||
画像参照コードが得られたら、AI IDE に EC で一般的に使われる画像タスク機能をサポートさせます：
|
||||
|
||||
```
|
||||
以下の API を基に、このプロジェクトの EC ビジネスの一般的な機能（ポスター生成、Douyin EC メイン画像生成など）を実装してください。
|
||||
|
||||
<ここに API KEY と画像編集コードを貼り付けてください>
|
||||
```
|
||||
|
||||
実装効果は以下の通り：
|
||||
|
||||
|
||||
|
||||
注目すべき点として、画像生成では奇妙な問題に頻繁に遭遇する可能性があるため、AI IDE に完全なエラーメッセージを表示させることをお勧めします。コピー＆ペーストで修正しやすくするためです（そうしないと、「生成に失敗しました」と何度も表示されるが、理由が分からないという状況になる可能性があります）。例えば、次のように言えます：
|
||||
|
||||
```
|
||||
画像生成失敗とだけ表示せず、毎回完全な失敗理由（画像不一致、リクエストエラー、タイムアウトなど）を表示してください！
|
||||
```
|
||||
|
||||
修正後に更新がウェブページに反映されないことがあります。修正後もウェブページでエラーが出続ける場合（何度も）、AI IDE に直接「このプロジェクトを再起動してください」と言ってみてください。
|
||||
|
||||
EC ビジネスでは、ユーザーがアップロードした服を自動的にキャラクターに着せたり、商品の魅力的な販売画像やポスターを自動生成したりしたい場合があります。ここでは、EC ポスターを生成させるプロンプトを試します：
|
||||
|
||||
|
||||
|
||||
自分の想像するビジネスシーンに応じて、テキストから画像または画像から画像 API を使って異なる機能を実装できます。
|
||||
|
||||
## さらに多くの画像サービスの選択
|
||||
|
||||
以下に他の選択肢を示します。まず Qwen 画像生成の結果を動かし、効果とコストに応じて以下のサービスで差し替えることをお勧めします（実際の使用感に基づいて選択）。
|
||||
|
||||
### Recraft 統合
|
||||
|
||||
プロトタイプが「デザイン制作」寄りの場合（ブランドスタイルのイラスト、マーケティングポスター、ベクタースタイル素材の生成など）、Recraft の方が使いやすいことが多いです。統合方法は前のセクションと完全に同じです：<strong>Key を取得 ＋ 公式サンプルを見つける ＋ AI IDE にサンプルをボタン/ページに落とし込ませる</strong>。
|
||||
|
||||
::: details 詳細：Recraft とは？
|
||||
|
||||
> Recraft はデザイナー、イラストレーター、マーケター向けの AI ツールで、2022年に米国で設立され、本社はロンドンにあります。ビジュアル効果（画像、ベクターアート、3D グラフィックス）の生成・イテレーションを支援し、高品質な出力（任意のテキストサイズ/長さ）、正確な要素の配置、ブランドの一貫性のあるデザインなどの利点があります。200カ国/地域の300万人以上のユーザー（Ogilvy、Netflix など含む）に信頼され、3.5億枚以上の画像が作成されています。チームはこれをデザイナーの必須ツールにすることを目指し、クリエイターが AI 補助ワークフローをコントロールできるようにしています。
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
まず、[API エントリ](https://www.recraft.ai/profile/api) を見つけて API Key を取得する必要があります。
|
||||
|
||||
ここでは無料枠が提供されていないため、1,000 クレジットを自分でチャージする必要があります。このサイトは Alipay と WeChat Pay に対応しているため、1,000 クレジットは簡単に取得できます（注意：必要以上にチャージしないでください）。
|
||||
|
||||
|
||||
|
||||
その後も同じ方法に従います：公式ドキュメントで対応するリクエストサンプルを見つけます：
|
||||
|
||||
- <https://www.recraft.ai/docs/api-reference/getting-started>
|
||||
- <https://www.recraft.ai/docs/api-reference/usage>
|
||||
- <https://www.recraft.ai/docs/api-reference/guides>
|
||||
|
||||
:::
|
||||
|
||||
### Qwen Image / Qwen Image Edit 統合
|
||||
|
||||
画像生成サービスをよりシンプルな方法で統合したい場合は、Qwen Image（通義万相）を検討できます。アプローチは同じです：「画像生成 API」として扱い、プロトタイプのボタンに接続するだけです。
|
||||
|
||||
::: details 詳細：Qwen Image / Qwen Image Edit とは？
|
||||
|
||||
**Qwen Image**（通義万相とも呼ばれる）は、アリババクラウドの通義チームがリリースした画像生成モデルシリーズで、主に2つのモデルを含みます：
|
||||
|
||||
**1. Qwen Image——テキストから画像（Text-to-Image）モデル**
|
||||
|
||||
テキストの説明から全く新しい画像を生成します。プロンプトを入力すると、モデルがあなたの意図を理解し、説明に合った画像を生成します。
|
||||
|
||||
|
||||
|
||||
**主な機能：**
|
||||
|
||||
- **テキストから画像（文生图）**：テキストの説明から画像を生成。複数のスタイル（リアル、カートゥーン、水墨、サイバーパンクなど）をサポート
|
||||
- **スタイル変換**：画像を指定したアートスタイルに変換
|
||||
- **画像バリエーション**：参照画像に基づいて類似スタイルの新しい画像を生成
|
||||
- **解像度向上**：画像の鮮明さとディテールを向上
|
||||
|
||||
**2. Qwen Image Edit——画像から画像（Image-to-Image）モデル**
|
||||
|
||||
既存の画像を編集・修正します。自然言語の指示で、モデルに修正の意図を理解させ、結果を生成させます。
|
||||
|
||||
**主な機能：**
|
||||
|
||||
- **部分置換**：画像中の特定の物体や人物を置換（「背景を海辺に変えて」など）
|
||||
- **要素削除**：画像から不要な要素を削除
|
||||
- **スタイル変換**：画像にフィルターやアート効果を追加
|
||||
- **画像拡張**：画像の境界を拡張し、新しいコンテンツを生成
|
||||
- **スマートレタッチ**：自動美化、光影調整、欠陥修正
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**なぜ Qwen Image シリーズを選ぶのか？**
|
||||
|
||||
- **中国語最適化**：中国語プロンプトの理解がより正確。国内ユーザーに適している
|
||||
- **低コスト**：海外競合と比較して価格が手頃
|
||||
- **高速**：生成効率が高く、レスポンスタイムが短い
|
||||
- **安定した品質**：EC、素材シーンで安定した信頼性
|
||||
- **多様なスタイル**：様々なアートスタイルとクリエイティブ効果をサポート
|
||||
|
||||
**典型的な応用シーン：**
|
||||
|
||||
- EC：メイン画像、詳細ページ画像、プロモーションポスターの生成
|
||||
- SNS：アバター、スタンプ、画像の生成
|
||||
- デザイン：コンセプトアート、素材画像、背景画像の迅速な制作
|
||||
- マーケティング：広告画像、イベントバナー、祝日ポスターの制作
|
||||
:::
|
||||
|
||||
[SiliconFlow](https://siliconflow.cn/) の公式サイトを確認してください。左側に「Playground」セクションがあり、API 呼び出しなしで様々なモデルを試せます。ページ上部に「Filters」ボタンがあります。クリックすると右側のモデルリストをフィルタリングできます。
|
||||
|
||||
「Image」を選択すると、現在サポートされているすべてのテキストから画像へのモデルだけが表示されます。ここでは Qwen/Qwen-Image を使用します。
|
||||
|
||||
|
||||
|
||||
すべての設定が完了したら、対応する画像生成 API ドキュメントを参照する必要があります。公式ドキュメントページで「API Reference」とマークされたセクションを見つけてください。クリックして [画像生成の API セクション](https://docs.siliconflow.cn/cn/api-reference/images/images-generations) にナビゲートし、関連するリクエストサンプルを見つけます。
|
||||
|
||||
以下のリクエストサンプルと API KEY を AI IDE に送信するだけで、画像生成機能を実装できます。
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url https://api.siliconflow.cn/v1/images/generations \
|
||||
--header 'Authorization: Bearer <token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '
|
||||
{
|
||||
"model": "Qwen/Qwen-Image-Edit-2509",
|
||||
"prompt": "an island near sea, with seagulls, moon shining over the sea, light house, boats int he background, fish flying over the sea"
|
||||
}
|
||||
'
|
||||
```
|
||||
|
||||
ここでのモデルは Qwen/Qwen-Image または Qwen/Qwen-Image-Edit-2509 を使用できます。
|
||||
|
||||
::: details 画像編集参考コード
|
||||
|
||||
以下のコードと Key をコピーして、AI IDE に送信します：
|
||||
|
||||
```python
|
||||
import requests
|
||||
import os
|
||||
from typing import Dict, Any, Optional
|
||||
|
||||
SILICONFLOW_API_KEY: str = ""
|
||||
SILICONFLOW_BASE_URL: str = "https://api.siliconflow.cn/v1/images/generations"
|
||||
QWEN_IMAGE_EDIT_MODEL: str = "Qwen/Qwen-Image-Edit-2509"
|
||||
|
||||
def generate_image_edit(
|
||||
prompt: str,
|
||||
image: Optional[str] = None,
|
||||
image2: Optional[str] = None,
|
||||
image3: Optional[str] = None,
|
||||
negative_prompt: Optional[str] = None,
|
||||
cfg: Optional[float] = 4.0,
|
||||
seed: Optional[int] = None
|
||||
) -> Optional[Dict[str, Any]]:
|
||||
payload: Dict[str, Any] = {
|
||||
"model": QWEN_IMAGE_EDIT_MODEL,
|
||||
"prompt": prompt,
|
||||
}
|
||||
if image:
|
||||
payload["image"] = image
|
||||
if image2:
|
||||
payload["image2"] = image2
|
||||
if image3:
|
||||
payload["image3"] = image3
|
||||
if negative_prompt:
|
||||
payload["negative_prompt"] = negative_prompt
|
||||
if cfg is not None:
|
||||
payload["cfg"] = cfg
|
||||
if seed is not None:
|
||||
payload["seed"] = seed
|
||||
|
||||
headers: Dict[str, str] = {
|
||||
"Authorization": f"Bearer {SILICONFLOW_API_KEY}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
try:
|
||||
response = requests.post(SILICONFLOW_BASE_URL, json=payload, headers=headers)
|
||||
response.raise_for_status()
|
||||
return response.json()
|
||||
except requests.exceptions.RequestException as e:
|
||||
print(f"Error generating image: {e}")
|
||||
return None
|
||||
|
||||
def save_image_from_url(image_url: str, output_path: str = "image.png") -> bool:
|
||||
try:
|
||||
response = requests.get(image_url)
|
||||
response.raise_for_status()
|
||||
os.makedirs(os.path.dirname(output_path) if os.path.dirname(output_path) else ".", exist_ok=True)
|
||||
with open(output_path, "wb") as f:
|
||||
f.write(response.content)
|
||||
print(f"Image saved successfully to: {output_path}")
|
||||
return True
|
||||
except requests.exceptions.RequestException as e:
|
||||
print(f"Error downloading image: {e}")
|
||||
return False
|
||||
except Exception as e:
|
||||
print(f"Error saving image: {e}")
|
||||
return False
|
||||
|
||||
prompt: str = "让天空变成傍晚，有月亮和星星，梦幻风格"
|
||||
negative_prompt: str = "模糊, 低质量, 扭曲"
|
||||
image_url: str = "https://inews.gtimg.com/om_bt/Os3eJ8u3SgB3Kd-zrRRhgfR5hUvdwcVPKUTNO6O7sZfUwAA/641"
|
||||
image2_url: Optional[str] = None
|
||||
image3_url: Optional[str] = None
|
||||
|
||||
cfg: float = 4.0
|
||||
seed: int = 12345
|
||||
output_path: str = "edited_image.png"
|
||||
|
||||
print(f"Generating edited image with prompt: {prompt}")
|
||||
print(f"Input image: {image_url}")
|
||||
print(f"CFG: {cfg}, Seed: {seed}")
|
||||
print("-" * 50)
|
||||
|
||||
result = generate_image_edit(
|
||||
prompt=prompt,
|
||||
image=image_url,
|
||||
image2=image2_url,
|
||||
image3=image3_url,
|
||||
negative_prompt=negative_prompt,
|
||||
cfg=cfg,
|
||||
seed=seed
|
||||
)
|
||||
|
||||
if result and "images" in result:
|
||||
images = result["images"]
|
||||
if images and len(images) > 0:
|
||||
image_url_result = images[0]["url"]
|
||||
print(f"Image edit generated successfully. URL: {image_url_result}")
|
||||
success = save_image_from_url(image_url_result, output_path)
|
||||
if success:
|
||||
print(f"Image saved to: {output_path}")
|
||||
else:
|
||||
print("Failed to save image to local file")
|
||||
else:
|
||||
print("No images found in response")
|
||||
else:
|
||||
print("Image generation failed")
|
||||
if result:
|
||||
print(f"Response: {result}")
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
# 付録：「現在より強力な」AI モデルを見つける方法
|
||||
|
||||
テキストモデル（大規模言語モデルとも呼ばれる）の発展は非常に速く、常により良いパフォーマンスを示すモデルを使用していることを確認する必要があります。以下の2つのウェブサイトで、「現在よく使われ、評価も高いモデル」を簡単に確認できます。
|
||||
|
||||
一般的に、この種のウェブサイトは **「モデルアリーナ」** と理解できます：2つのモデルの出力を並べて表示し、より好きな方に投票します。票が多いモデルは、より多くの人が「使いやすい」と思っていることを意味します。
|
||||
|
||||
また、これらの大規模モデルアリーナで謎の匿名モデル（「Unknown Model」）が表示されることがあります。これは通常、「内部テストモデル」がこっそりブラインドテストに参加していることを意味し、より強力な能力に先取りして体験できるチャンスがあるかもしれません。
|
||||
|
||||
## LMArena
|
||||
|
||||
ウェブサイト：<https://lmarena.ai/>
|
||||
|
||||
LMArena は「より多くの人がどのモデルの回答を好むか」を判断するのに適しています。投票数が多く、スコアが高いほど、実際の使用シーンでより安定していることを意味します。
|
||||
|
||||
簡単な使い方：
|
||||
|
||||
1. リーダーボード（Leaderboard）を直接見る
|
||||
2. 目的の方向（一般対話 / プログラミング / ビジョンなど）を選ぶ
|
||||
3. トップ3の中で使えるもの（アクセス可能、価格が受け入れられる、遅延が受け入れられる）を選ぶ
|
||||
|
||||
|
||||
|
||||
## Artificial Analysis
|
||||
|
||||
ウェブサイト：<https://artificialanalysis.ai/>
|
||||
|
||||
Artificial Analysis は「効果 / 価格 / 速度」を同じ表で比較するのに適しています。モデル選定のパラメータシートとして使えます。
|
||||
|
||||
一般的な使い方：
|
||||
|
||||
1. 関心のあるモデルカテゴリ（テキスト / 画像生成など）を見つける
|
||||
2. 品質指標（Quality）＋価格（Price）＋遅延/スループット（Latency/Throughput）を見る
|
||||
3. 「総合的なコストパフォーマンス」がプロダクトに最も合うものを選ぶ
|
||||
|
||||
::: tip ✅ 推奨
|
||||
「どちらが強いか」を感覚で議論しないでください。より信頼性のある方法は：同じ入力で2〜3つのモデルを同時にテストし、ランキングと価格を組み合わせて決定することです。
|
||||
:::
|
||||
|
||||
## まとめ
|
||||
|
||||
各種 AI サービスを統合する際、API を複雑に想像する必要はありません。以下の核心的な概念を把握すれば、ほとんどのシーンに対応できます：
|
||||
|
||||
**API の本質は通信の橋渡し**です。やっていることはシンプル：あなたのリクエストを送信し、モデルのレスポンスを持ち帰る。背後で何が起きているかを気にする必要はなく、リクエスト形式を正しく組織するだけで済みます。
|
||||
|
||||
**SDK は API のラッパー**です。API が raw インターフェースだとすれば、SDK は既成のツールキットです——リクエスト署名、エラーハンドリング、パラメータ検証などの面倒な詳細をすべて処理してくれます。日常の開発では、直接 API を呼び出すより SDK を優先して使うと、多くの手間が省けます。
|
||||
|
||||
**ドキュメントを読むときは、3つのことに注目するだけで十分**です：サービスアドレス（endpoint）、認証情報（API key）、呼び出しパラメータの書き方。この3点を明確にすれば、統合は時間の問題です。
|
||||
|
||||
残りの作業は、IDE とモダンな開発ツールがやってくれます。ビジネスロジックに集中し、低レベルの呼び出しはこれらの成熟した SDK とツールチェーンに任せましょう。
|
||||
|
||||
# 5. 📚 課題：最初の AI 能力を統合する
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🚀 チャレンジタスク：AI 能力をあなたのワークスペースに統合する</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
この授業のプロンプトと内容を参考に、完全なクローズドループを完了してください：
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>完全なクローズドループの実践</strong>
|
||||
<ul>
|
||||
<li>一つの AI サービス（LLM / テキストから画像 / 画像から画像）を選択し統合 → フロントエンドとバックエンドのインタラクションを実装 → プロトタイプに統合</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>成果の共有</strong>
|
||||
<ul>
|
||||
<li>機能ページのスクリーンショットをみんなにシェアする</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>思考問題</strong>
|
||||
<ul>
|
||||
<li>次の「完全なプロジェクト実践」のために空間を確保し、事前に考える：これらの AI 能力をどのように組み合わせて、面白い機能を作るか？</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 次のステップ
|
||||
|
||||
次のセクションでは、これらの分散した AI 能力を繋ぎ合わせ、実際のビジネスシーンに基づいた完全なプロダクトを作ります：
|
||||
|
||||
- コンテンツ企画、商品出品、データ分析などのプロセスを一つの完全なビジネスフローに繋げる
|
||||
- この授業で学んだ AI 能力（LLM コピーライティング生成、テキストから画像、画像編集など）を実際のビジネスノードに組み込む
|
||||
- 孤立したデモではなく、本当に使える「EC AI ワークスペース」を実装する
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="関連記事"
|
||||
description="「単一の AI 能力」から「完全なプロダクトフロー」への推奨学習パス。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1 @@
|
||||
../../../zh-cn/stage-1/introduction-to-ai-ide/images
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,275 @@
|
||||
---
|
||||
title: 'アイデアからAIプロダクトへ - Easy-Vibe 学習ロードマップ'
|
||||
description: 'AIプログラミングの完全な学習ロードマップ：ゼロからフルスタック開発まで。Vibe Coding、Claude Code、CursorなどのAI IDEツールをマスターし、プロダクト思考、フルスタック開発、AI能力統合を学びます。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['ja-jp/stage-1/learning-map'] ?? []
|
||||
</script>
|
||||
|
||||
# アイデアからAIプロダクトへ
|
||||
|
||||
::: info 特別感謝
|
||||
**清華大学深セン国際大学院**の学生の皆様に、本コースのテスト・フィードバック・サポートにご協力いただきましたこと、心より感謝申し上げます！皆様のご意見とご貢献により、このコースはさらに良くなりました。[👉 完全な貢献者リストを見る](https://github.com/datawhalechina/easy-vibe#-contributing--contributors)
|
||||
:::
|
||||
|
||||
昔はソフトウェアを作るハードルが非常に高くて、プログラミングもアルゴリズムも理解し、数年のプロジェクト経験も必要でした。
|
||||
今は違います。アイデアさえあれば、AIがコードを書いてくれます。
|
||||
|
||||
これは大きな変化です：**プログラミング言語が自然言語になろうとしています。**
|
||||
|
||||
大規模言語モデル（LLM）の登場により、開発はもはや「技術エリートの専有物」ではなく、誰もが使えるツールになりました。かつて最も難しかったのは「コードの書き方」でしたが、今最も難しいのは「**何を作るか**」です。
|
||||
|
||||
> **Vibe Codingとは？**
|
||||
> 簡単に言うと、「話してプログラミングする」ことです。雰囲気プログラミングとは、直接コードを書くのではなく、AIとだけ対話することでプログラミングプロジェクトを完成させるアプローチを指します。
|
||||
|
||||
もちろん、AIにコードを書かせるのは最初の一歩にすぎません。本当に使えるプロダクトを作るには、以下のような問題に直面します：
|
||||
- AIにクリーンで保守性の高いコードを書かせるにはどうすればよいか？
|
||||
- 断片的なコードを動くアプリケーションに組み立てるには？
|
||||
- アプリを実際に公開し、ユーザーに使ってもらうには？
|
||||
- テキスト生成や画像認識などのAI能力をプロダクトに組み込むには？
|
||||
|
||||
これらの問題の答えは、このコースで見つけることができます。
|
||||
|
||||
学生、先生、医師、労働者、技術に全く疎い一般の方でも——何年もプログラミングを学ぶ必要はありません。2週間で動くデモンストレーション可能なプロダクトプロトタイプを作ることができます。
|
||||
|
||||
| あなたの立場 | このコースでできること |
|
||||
|---------|-------------|
|
||||
| 学生 | 課題、コンテスト、起業、自分でプロジェクトを作り、人に頼らない |
|
||||
| 社会人 | 繰り返し作業を自動化し、効率を上げ、副業を開発する |
|
||||
| プロダクトマネージャー / デザイナー | アイデアを紙に留めず、素早くデモを作成して上司やクライアントに見せる |
|
||||
| 起業家 / 中小企業のオーナー | 低コストでアイデアを検証し、数万円の外注費なしでMVPを作成する |
|
||||
| 先生 / 教育関係者 | 教育ツール、教材、自動出題システムを作成し、教育効率を向上する |
|
||||
| 医師 / 弁護士 / 専門職 | 専門プロセスを自動化し、自分の効率ツールを作る |
|
||||
| すべての人 | AIで生活・仕事の具体的な問題を解決し、不可能を可能にする |
|
||||
|
||||
AI時代において、実行力とアイデアは常に技術よりも重要です。
|
||||
|
||||
## 成長パス：「AIを使える」から「AIプロダクトを作れる」へ
|
||||
|
||||
<div class="stage-intro">
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🎮</div>
|
||||
<h3>初心者入門</h3>
|
||||
<p class="stage-role">AIプログラミングを体験</p>
|
||||
<div class="stage-tags">
|
||||
<span>ヘビミニゲーム</span>
|
||||
<span>ゼロから始める</span>
|
||||
<span>Vibecoding 初体験</span>
|
||||
<span>数分で生成</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="stage-grid">
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🛠️</div>
|
||||
<h3>第一段階</h3>
|
||||
<p class="stage-role">プロダクトマネージャー / 運営</p>
|
||||
<div class="stage-tags">
|
||||
<span>AI IDE (Cursor/Claude)</span>
|
||||
<span>要件分解 & プロトタイプ</span>
|
||||
<span>AI能力の統合</span>
|
||||
<span>完全なDemo開発</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">💻</div>
|
||||
<h3>第二段階</h3>
|
||||
<p class="stage-role">初中級開発者 / インディー開発者</p>
|
||||
<div class="stage-tags">
|
||||
<span>Figmaからコードへ</span>
|
||||
<span>Supabase データベース</span>
|
||||
<span>Stripe 決済統合</span>
|
||||
<span>Dify ナレッジベース</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🚀</div>
|
||||
<h3>第三段階</h3>
|
||||
<p class="stage-role">上級開発者 / アーキテクト</p>
|
||||
<div class="stage-tags">
|
||||
<span>Web/ミニプログラム/マルチプラットフォーム</span>
|
||||
<span>MCP 高度ツール</span>
|
||||
<span>RAG & LangGraph</span>
|
||||
<span>上級エンジニア思考</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<style>
|
||||
.stage-intro {
|
||||
margin: 20px auto;
|
||||
max-width: 400px;
|
||||
}
|
||||
|
||||
.stage-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
|
||||
gap: 12px;
|
||||
margin: 16px 0;
|
||||
}
|
||||
|
||||
.stage-card {
|
||||
border: 1px solid var(--vp-c-divider);
|
||||
border-radius: 10px;
|
||||
padding: 12px;
|
||||
background-color: var(--vp-c-bg-soft);
|
||||
transition: all 0.3s ease;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
text-align: center;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.stage-card:hover {
|
||||
transform: translateY(-2px);
|
||||
background-color: var(--vp-c-bg-mute);
|
||||
box-shadow: 0 4px 16px rgba(0, 0, 0, 0.05);
|
||||
border-color: var(--vp-c-brand);
|
||||
}
|
||||
|
||||
.stage-icon {
|
||||
font-size: 2rem;
|
||||
margin-bottom: 8px;
|
||||
line-height: 1;
|
||||
}
|
||||
|
||||
.stage-card h3 {
|
||||
margin: 0 0 4px 0 !important;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
line-height: 1.2;
|
||||
}
|
||||
|
||||
.stage-role {
|
||||
margin: 0 0 8px 0 !important;
|
||||
font-size: 0.8rem;
|
||||
color: var(--vp-c-text-2);
|
||||
font-weight: 500;
|
||||
}
|
||||
|
||||
.stage-tags {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
justify-content: center;
|
||||
gap: 4px;
|
||||
}
|
||||
|
||||
.stage-tags span {
|
||||
font-size: 0.7rem;
|
||||
padding: 1px 6px;
|
||||
border-radius: 3px;
|
||||
background-color: var(--vp-c-bg-alt);
|
||||
color: var(--vp-c-text-2);
|
||||
border: 1px solid var(--vp-c-divider);
|
||||
}
|
||||
|
||||
.stage-card:hover .stage-tags span {
|
||||
background-color: var(--vp-c-bg);
|
||||
border-color: var(--vp-c-brand-dimm);
|
||||
color: var(--vp-c-brand-dark);
|
||||
}
|
||||
</style>
|
||||
|
||||
この完全な学習パスを通じて、以下を獲得します：
|
||||
|
||||
- **Vibe Coding開発能力：** vibecodingの思考法とAIコーディングツールに熟練し、開発効率を数倍に引き上げます。構文を暗記するのではなく、AIに高品質なコードを生成させる方法を学びます。
|
||||
- **フルスタック開発スキル：** UI設計からフロントエンド実装、データベース設計からAPI開発、ローカル開発からクラウドデプロイまで、モダンWebアプリケーションの完全な技術スタックを習得します。
|
||||
- **AI能力統合：** 各種マルチモーダルAI APIを呼び出し、テキスト、画像、音声などのAI能力をアプリにシームレスに統合し、RAG等の技術でインテリジェントなプロダクトを構築する方法を学びます。
|
||||
- **プロダクト思考と運営能力：** ユーザーリサーチから要件分解、MVP設計からプロダクト反復、決済統合からユーザー管理まで、完全なプロダクト開発・運営ループを形成します。
|
||||
|
||||
# 学習後、何ができるようになる？
|
||||
|
||||
## 第一段階：最初のプロダクトプロトタイプを作る
|
||||
|
||||
この段階は、プログラミングの基礎が全くない方、または少しだけ知っているが自信がない方に適しています。まず理論をたくさん学ぶのではなく、実際に手を動かしながらAIツールを使ってコードを書く方法を学びます。
|
||||
|
||||
**学習後できること**：
|
||||
- AIプログラミングツールで独立してWebアプリケーションを完成させる
|
||||
- プロダクトアイデアをクリック・操作可能なプロトタイプに変える
|
||||
- プロトタイプにAI機能（テキストから画像生成、インテリジェント対話など）を追加する
|
||||
- エラーが発生したときにトラブルシューティング・解決方法を知っている
|
||||
|
||||
簡単に言うと、「動いて、他人にデモンストレーションできるもの」を作れるようになります。
|
||||
|
||||
まずはミニゲームでAIプログラミングを体験し、その後AIプログラミングツールを使ってコードを書いたりエラーを修正する方法を学びます。次にシンプルなページから始め、徐々に操作可能なマルチページアプリケーションを作り、テキストから画像生成やインテリジェント対話といったAI機能を追加していきます。最後に完全なプロジェクトを独立して完成させ、アイデアを実際に実現する可能性を持てるようになります。
|
||||
|
||||
# なぜプロジェクト制でトレーニングするのか？
|
||||
|
||||
> **現実世界の課題**
|
||||
>
|
||||
> 理由は実は単純です：今の状態のまま職場に入ると、実際のプロジェクトと上司やクライアントからの「社会の洗礼」で立ち行かなくなる可能性が高いです。現実世界でより一般的なシナリオは：
|
||||
|
||||
> メンターや上司：「xxxを作ってほしい、目標はyyyの効果を出すこと」
|
||||
>
|
||||
> ドキュメント？既存のフレームワーク？詳細な要件仕様書？多くの場合、存在しません。
|
||||
|
||||
実際の仕事の多くのタスクは、本質的に不確実性の高い環境で見たことのない問題を解決することです：要件は曖昧で、境界線は変化し、正解を教えてくれる人はいません。自分で資料を調べ、実験し、プロトタイプを組み、反復しながら、最終的に「動いて、使えて、公開できる」ソリューションを提案する必要があります。
|
||||
|
||||
このコースが目指しているのは、比較的安全な環境で、事前に一度「社会シミュレーション」を体験してもらうことです：
|
||||
|
||||
- 一見難しそうなプロジェクト課題を通じて、問題の分解、設計案の作成、自力での資料探索を練習する
|
||||
- あまり「お手軽」ではないスキャフォールディングとコードを通じて、中〜大規模なコードベースの読解・理解・改造を学ぶ
|
||||
- アイデアから公開までの完全ループを通じて、実際のプロダクトをゼロからイチにする全過程を体験する
|
||||
|
||||
短期的には、このトレーニングは確かに大変ですが、長期的には、就職やキャリアアップにおける競争力を大幅に高めます：挫折に強くなり、不確実な環境で突破口を見つける力がつき、AIを本当のプロダクトに落とし込む能力も高まります。「デモで遊ぶ」段階にとどまらなくなります。
|
||||
|
||||
# 質問の技法：AI時代に必須のスキル
|
||||
|
||||
AI時代において、質問することも「基本スキル」の一つです。同じコード、同じエラーに対して、**質問の仕方が、AIがどんな回答を出すかをほぼ決定します**：大ざっぱな回答か、段階的に実行可能な修正案か。
|
||||
|
||||
**良い習慣を身につけましょう**：「AIへの質問」を日常の開発フローの一部とし、分からないことや行き詰まった問題があればすぐに質問しましょう。
|
||||
|
||||
## なぜこれが必須スキルなのか？
|
||||
|
||||
- **現実には完全なドキュメントがほとんどない**：多くの場合、不明確な要件、半完成品のコード、散在するエラー情報に直面する
|
||||
- **AIはあなたの常にそばにあるメンター兼同僚**：質問上手になれば、「高品質なペアプログラミング」に変わる
|
||||
- **能力の上限はコミュニケーションで決まる**：重要な情報を提供し、出力フォーマットを制約するほど、回答はより使いやすくなる
|
||||
|
||||
**よくある誤解**：「なぜエラーが出るの？」とだけ聞いても、推測の羅列しか得られません。コンテキストを補完して初めて、実行可能なソリューションが得られます。
|
||||
|
||||
## 情報をAIに「伝える」方法：スクリーンショット vs コピー＆ペースト
|
||||
|
||||
どちらの方法でも構いませんが、用途が異なります：
|
||||
|
||||
| 方法 | 適用シナリオ | 重要なポイント |
|
||||
| ------------ | ----------------------------------------- | ----------------------------------------- |
|
||||
| **コピー＆ペースト** | エラースタック、ログ、コード、設定、API レスポンス | できるだけ完全に、キーワードの1行だけを切り取らないように |
|
||||
| **スクリーンショット** | UI レイアウトの問題、操作の異常、ツール画面でボタンが見つからない | 全画面 + 重点エリアに注釈、できればテキストの説明を一言添える |
|
||||
|
||||
::: danger ⚠️ 重要な前提
|
||||
**すべてのAIが画像入力をサポートしているわけではありません。** スクリーンショットでのコミュニケーションには、AIにマルチモーダル能力（画像を理解・分析できる能力）が必要です。現在画像入力をサポートするAIには、Claude (Anthropic)、GPT-4V/GPT-4o (OpenAI)、Gemini (Google)、および一部の国内大規模モデル（通義千問、文心一言など）が含まれます。
|
||||
|
||||
**使用しているAIが画像入力をサポートしていない場合**、スクリーンショットは認識されませんので、テキストをコピー＆ペーストする方式に切り替えてください。
|
||||
:::
|
||||
|
||||
## AIに「上手に説明してもらう」ためのプロンプトのコツ
|
||||
|
||||
答えだけではなく、「答えを学びたい」場合は、以下のような指示を使うと、説明の質が大幅に向上します：
|
||||
|
||||
> **学習型質問の例**
|
||||
>
|
||||
> - 「まず5文でこの概念を説明してから、理解が正しいかを確認するための質問をいくつか出してください。」
|
||||
> - 「このエラーメッセージについて詳しく説明してください。なぜエラーが出るのか理解できません。」
|
||||
|
||||
# いくら頑張っても解決できない、諦めたい
|
||||
|
||||
もしかすると、頑張り方が間違っているのかもしれません。暗闇の中で一人で苦しむのではなく、作者やティーチングアシスタントと話してみましょう：これまでに試した方法、直面している具体的な壁、そして現在の心理状態を正直に打ち明けてください。多くの場合、方向を少し変えたり、重要な知識ポイントを一つ補うだけで、前に進めるようになります。
|
||||
|
||||
# チュートリアルの設計に不合理なところがある
|
||||
|
||||
いつでも著者に連絡し、issueを提出するか、グループや授業で直接フィードバックしてください。このチュートリアルをより良くしていきたいと強く願っています：どこが不明確か、どこが使いにくいか、どこで無駄な努力をしたか、率直に指摘してください。リアルで具体的なフィードバックほど、後の学習者の役立ちます。
|
||||
|
||||
# Reference
|
||||
|
||||
- [南京大学 計算機科学技術学科 計算機システム基礎 コース実験](https://nju-projectn.github.io/ics-pa-gitbook/ics2025/)
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="次に何を学べるか"
|
||||
description="「AIを使える」から「プロダクトを作れる」へのルートに沿って、さらに先に進みましょう。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
Reference in New Issue
Block a user