ここまでのチュートリアルでは、Webサービスを作り、Databaseを追加し、ログイン機能まで実装する流れを学びました。
次はいよいよ、Webアプリの中からAIを呼び出して、AI機能を持つサービスへ進みます。
ユーザー
↓
Webアプリへ入力
↓
サーバー
↓
AI API
↓
AIが処理
↓
回答
↓
Webアプリに表示
これが理解できると、文章生成、要約、分類、アイデア生成、チャット、文章修正など、さまざまなAI機能を自分のWebサービスへ組み込めるようになります。
このチュートリアルでは、ユーザーの入力をAI APIへ送り、生成された回答をWebアプリへ表示する基本的な流れを理解します。
今回追加するAI機能
これまで作ってきたアイデア整理アプリへ、AIによるアイデア改善機能を追加する想定で進めます。
たとえばユーザーが、
AI初心者向けの学習サービスを作りたい
と入力して「AIで改善」ボタンを押すと、AIが内容を整理します。
元のアイデア
↓
AI API
↓
改善案
・対象ユーザー
・解決する課題
・具体的な機能
・最初に作るMVP
・検証方法
まずは1つのシンプルなAI機能から始めます。
AI APIとは?
APIは、別のサービスの機能を自分のアプリから利用するための仕組みです。
AI APIを使うと、自分で巨大なAIモデルを作らなくても、AIサービスが提供するモデルをWebアプリから利用できます。
自分のWebアプリ
「この文章を要約して」
↓
AI API
↓
AIモデル
↓
「要約結果」
↓
自分のWebアプリ
OpenAI、Anthropic、Googleなど、複数の企業が開発者向けAI APIを提供しています。
ChatGPTやClaudeのWeb画面を使うのではなく、自分のサービスの中からAIモデルへ処理を依頼するのがAI APIの基本イメージです。
STEP 1:AIに何をさせるか決める
最初から「何でもできるAI」を作ろうとすると、仕様が複雑になります。
まず1つの処理に絞ります。
- 文章を要約する
- 文章を修正する
- アイデアを整理する
- 内容を分類する
- タイトルを作る
- 質問に答える
今回の目的は、
入力されたアイデアを
AIが整理・改善する
だけにします。
STEP 2:入出力を決める
AI機能を作るときは、「何を渡して」「何を返してほしいか」を先に決めます。
INPUT
ユーザーのアイデア
↓
AI
↓
OUTPUT
・対象ユーザー
・課題
・改善案
・MVP
・次にやること
この形が決まっていると、プロンプトや画面も設計しやすくなります。
STEP 3:AIに実装設計を相談する
いきなりAPIを接続させる前に、現在のアプリにどこへAI処理を追加するか確認します。
現在のWebアプリへAI機能を追加したいです。
機能:
ユーザーが入力したアイデアをAIへ送り、
次の形式で改善案を返す。
・対象ユーザー
・解決する課題
・改善案
・最初のMVP
・次にやること
まず現在のプロジェクトを調査してください。
確認:
・使用Framework
・サーバー側処理の場所
・API Route / Server Actionなど現在の構成
・環境変数の扱い
・既存のAI関連ライブラリ
まだコード変更やパッケージ追加はしないでください。
変更予定ファイルと実装方針だけ報告してください。
AI APIは秘密情報も扱うため、実装場所の確認が重要です。
STEP 4:APIキーとは?
AI APIを利用するときは、サービスからAPIキーなどの認証情報が発行されることがあります。
Webアプリ
↓
APIキーで認証
↓
AIサービス
↓
利用を許可
APIキーは、そのサービスを利用するための重要な秘密情報です。
APIキーをGitHub、SNS、記事、ブラウザ側のJavaScriptなどへ公開しないでください。第三者に利用されると、料金発生や不正利用につながる可能性があります。
STEP 5:APIキーを環境変数へ入れる
APIキーはコードへ直接書かず、環境変数として管理します。
AI_API_KEY=[REDACTED]
実際の環境変数名は、利用するAIサービスやSDKの公式ドキュメントに従います。
ローカルでは .env.local などを利用する構成があります。
.env.local
AI_API_KEY=...
STEP 6:.gitignoreを確認する
APIキーを設定したら、環境変数ファイルがGitへ追加されていないか確認します。
git status
.env.local などがGit管理対象になっていないことを確認します。
必要に応じて .gitignore を確認してください。
STEP 7:AI APIはサーバー側から呼び出す
APIキーを守るため、AI APIは基本的にサーバー側から呼び出します。
安全なイメージ
ブラウザ
↓
自分のサーバー
↓
AI API
↓
自分のサーバー
↓
ブラウザ
ブラウザへAPIキーを渡して直接AIサービスへ接続する構成は、キーが利用者から見えてしまう可能性があります。
APIキーをクライアント側コードへ直接埋め込まないでください。秘密情報を必要とするAI API呼び出しは、サーバー側で処理する構成を基本にします。
STEP 8:AIサービスの公式SDKを確認する
AIサービスによっては、開発者向けの公式SDKが提供されています。
現在のプロジェクトに合う公式の方法を確認しましょう。
このプロジェクトからAI APIを利用したいです。
現在利用するAIプロバイダーの
公式ドキュメントを前提に、
現在推奨されているSDK・実装方法を確認してください。
条件:
・古いAPI形式を使わない
・公式SDKを優先
・現在のFrameworkに合わせる
・追加するパッケージと理由を説明する
まだインストールしないでください。
AIサービスは更新が速いため、古いブログ記事だけで実装しないことも重要です。
STEP 9:プロンプトを設計する
AI機能の品質は、モデルだけではなくプロンプトによっても変わります。
今回なら、次のような指示をAIへ渡します。
あなたは新規サービスの企画支援AIです。
ユーザーのアイデアを整理してください。
次の形式で回答してください。
1. 対象ユーザー
2. 解決する課題
3. アイデアの改善案
4. 最初に作るMVP
5. 次に検証すること
条件:
・初心者にも分かる文章
・必要以上に断定しない
・元のアイデアを無視しない
・具体的にする
ユーザーのアイデア:
[入力内容]
ユーザー入力部分だけを毎回変えて利用します。
STEP 10:ユーザー入力と指示を分けて考える
AIへ送る内容には、アプリ側で決める指示と、ユーザーが入力する内容があります。
アプリ側の指示
あなたは企画支援AIです。
この形式で回答してください。
+
ユーザー入力
AI初心者向けの学習サービスを作りたい
この2つを混同しないように設計します。
サービスとしてAIを使う場合は、ユーザーが毎回プロンプト全体を書くのではなく、アプリ側で基本ルールを持ち、必要な情報だけユーザーから受け取る設計もできます。
STEP 11:入力値を検証する
ユーザーが送る内容をそのままAIへ渡す前に、最低限の入力チェックを行います。
- 空欄ではないか
- 長すぎないか
- 想定した形式か
ユーザー入力
↓
Validation
↓
問題なし
↓
AI API
問題あり
↓
APIを呼ばない
↓
エラー表示
無駄なAPI利用を防ぐ意味でも重要です。
STEP 12:AI APIを呼び出す処理を実装する
設計が確認できたら、AI API呼び出しを実装します。
AI改善機能を実装してください。
入力:
idea
処理:
・入力値をValidation
・サーバー側からAI APIを呼ぶ
・APIキーは環境変数から取得
・アイデア改善用プロンプトを使用
・回答をフロントエンドへ返す
条件:
・APIキーをクライアントへ送らない
・不要なライブラリを追加しない
・既存機能を壊さない
・関係ないファイルを変更しない
・エラー処理を入れる
実装前に変更予定ファイルを報告してください。
STEP 13:Loading状態を作る
AIの回答には少し時間がかかることがあります。
ボタンを押して何も変わらないと、ユーザーは動いているか分かりません。
AIで改善
↓
処理中...
↓
結果表示
処理中はボタンを無効にするなど、二重送信を防ぐ方法もあります。
STEP 14:AIの回答を表示する
AI APIから回答を受け取ったら、画面へ表示します。
AIの回答
対象ユーザー:
AI初心者
課題:
何から学べばよいか分からない
改善案:
実践型の学習導線を作る
MVP:
AI入門 + プロンプト + Tutorial
次に検証:
初心者が最後まで進めるか
長い生テキストをそのまま出すより、見出しやカードへ整理するとユーザーが読みやすくなります。
STEP 15:構造化された回答を考える
アプリ側でAI回答を加工したい場合は、一定の構造で返してもらうと扱いやすくなります。
{
"targetUser": "...",
"problem": "...",
"improvements": ["...", "..."],
"mvp": "...",
"nextStep": "..."
}
JSONのような形式を利用すれば、文章の中から必要な部分を探すのではなく、項目ごとに画面へ表示できます。
ただし、AIの出力が必ず期待した形式になるとは限らないため、アプリ側で検証することも重要です。
STEP 16:AIの出力もValidationする
ユーザー入力だけでなく、AIから返ってきた回答も信用しすぎないようにします。
AI API
↓
回答
↓
形式を確認
↓
問題なし
↓
表示
形式がおかしい
↓
エラー処理
または
再試行
特にAIの出力をDatabaseへ保存したり、別の処理へ自動で渡したりする場合は重要です。
AIが生成した内容も「外部から受け取ったデータ」と考え、必要な形式になっているか確認してから利用する習慣をつけましょう。
STEP 17:AIが失敗した場合を考える
AI APIは常に成功するとは限りません。
- ネットワークエラー
- API側の一時的な問題
- 認証エラー
- 利用上限
- タイムアウト
- 不正な入力
などが発生する可能性があります。
AI処理に失敗しました。
時間をおいてもう一度お試しください。
のように、ユーザー側にも状態が分かるようにします。
STEP 18:エラー詳細をそのままユーザーへ出さない
開発中のエラーには内部情報が含まれることがあります。
Database URL
API Key
内部パス
技術構成
認証情報
などをユーザー画面へそのまま表示しないようにします。
内部ログ
詳細なエラー
↓
ユーザー
「AI処理に失敗しました」
STEP 19:利用料金を理解する
AI APIは、利用量に応じて料金が発生するサービスがあります。
そのため、AI機能を追加するときは「動くか」だけでなく「どれくらい使われるか」も考えます。
1回のAI処理コスト
×
1ユーザーの利用回数
×
ユーザー数
↓
サービス全体のAIコスト
モデルごとの価格や仕様は変更される可能性があるため、利用するAIサービスの現在の公式料金ページを確認してください。
STEP 20:無制限にAPIを呼ばせない
公開サービスで誰でも何回でもAIを実行できると、想定以上のAPI利用が発生する可能性があります。
そこで、用途によって利用制限を考えます。
- ログインユーザーだけ利用可能
- 1日あたりの回数制限
- 一定時間内のリクエスト制限
- 入力文字数制限
- プランごとの利用上限
AI APIのキーを隠していても、公開されたAI機能が無制限に使えるとコスト増加につながる場合があります。公開前に利用制限を検討しましょう。
STEP 21:入力文字数を制限する
非常に長い文章を毎回AIへ送ると、処理時間や利用料金が増える場合があります。
入力
最大2,000文字
↓
超えた場合
「2,000文字以内で入力してください」
用途に合わせて適切な上限を設計します。
STEP 22:ログインユーザーごとに利用回数を管理する
前回作った認証とDatabaseを使えば、ユーザーごとのAI利用回数を管理することもできます。
User
↓
AI実行
↓
利用回数を記録
↓
上限を確認
↓
AI API
将来的なSaaSでは、無料プランと有料プランでAI利用量を変える設計にもつながります。
STEP 23:AIへの入力に個人情報を含めないか確認する
ユーザーがAIへ入力する内容には、個人情報や会社の機密情報が含まれる可能性があります。
- 氏名
- メールアドレス
- 電話番号
- 顧客情報
- 社外秘資料
- 契約情報
自分のサービスで何をAIプロバイダーへ送信するのか把握し、利用規約やプライバシーポリシーも確認する必要があります。
STEP 24:AIの回答を事実として扱わない
AI機能をサービスに組み込んでも、AIの回答が必ず正しいわけではありません。
特に、
- 法律
- 医療
- 金融
- 最新ニュース
- 料金
- 統計
など重要な情報を扱う場合は、AI出力をそのまま確定情報として表示しない設計も重要です。
STEP 25:AI回答をDatabaseへ保存する
今回のアプリでは、生成された改善案をIdeaと一緒に保存することもできます。
Idea
title
content
userId
+
AI Result
targetUser
problem
improvements
mvp
nextStep
保存する前に、どのデータが必要なのか考えます。
AIの生の回答をすべて保存する必要がない場合もあります。
STEP 26:AI処理の履歴を考える
サービスが大きくなると、AI処理の状態や失敗を追跡したくなる場合があります。
AI Request
userId
createdAt
status
model
result
error
などを必要に応じて管理すれば、「誰がいつAIを使ったか」「どの処理が失敗したか」を調査しやすくなります。
STEP 27:ローカルでテストする
実装後は、正常な入力だけではなく複数のケースを試します。
□ 普通の文章
□ 短い文章
□ 空欄
□ 長すぎる文章
□ 日本語
□ 英語
□ AI APIエラー時
□ 連続クリック
AI機能は入力によって結果が変わるため、複数パターンで試すことが重要です。
STEP 28:git diffを確認する
git status
git diff
特に次を確認します。
- APIキーが含まれていないか
- 不要なライブラリを追加していないか
- サーバー側とクライアント側の役割
- エラー処理
- 入力Validation
- 既存機能への影響
現在のAI機能実装をレビューしてください。
確認:
・APIキーの漏えい
・クライアントへの秘密情報露出
・Validation
・AI出力の検証
・エラー処理
・無制限利用のリスク
・不要な依存関係
・既存機能への影響
まだ修正せず、
問題点だけ報告してください。
STEP 29:公開前チェック
AI機能の公開前チェックをしてください。
確認:
・lint
・型チェック
・build
・利用可能なテスト
・API Keyの管理
・入力Validation
・AI出力Validation
・エラー処理
・利用制限
・認証
・Database
・秘密情報
失敗項目がある場合は、
成功とは報告しないでください。
STEP 30:VercelへAPIキーを設定する
ローカルの環境変数はGitHubへPushしないため、Vercel側にもAI API用の環境変数を設定します。
Local
.env.local
↓
AI_API_KEY
Vercel
Environment Variables
↓
AI_API_KEY
PreviewとProductionで設定対象が分かれている場合は、必要な環境へ正しく設定します。
STEP 31:Previewで実際にAIを動かす
Vercel Preview URLでAI機能を実行します。
Preview
入力
↓
AIで改善
↓
Loading
↓
AI API
↓
結果表示
localhostで動いていても、Vercelの環境変数設定などが原因で公開環境では失敗することがあります。
STEP 32:Productionへ公開する
Previewで問題がなければ、現在のGit運用に従って本番へ反映します。
Local
↓
Feature Branch
↓
GitHub
↓
Preview
↓
AI機能テスト
↓
Main
↓
Production
本番でも最低限1回は実際のAI処理を確認します。
AI API追加の基本フロー
AI機能を決める
↓
INPUT / OUTPUT設計
↓
AIプロバイダーを決める
↓
API Key
↓
環境変数
↓
サーバー側処理
↓
プロンプト
↓
Validation
↓
AI API
↓
出力検証
↓
UI表示
↓
エラー処理
↓
利用制限
↓
コスト確認
↓
Preview
↓
Production
AI API実装の基本テンプレート
目的:
WebアプリへAI機能を追加する。
AI機能:
[AIにさせたい処理]
INPUT:
[AIへ渡す情報]
OUTPUT:
[返してほしい形式]
条件:
・APIキーをクライアントへ公開しない
・サーバー側からAI APIを呼ぶ
・入力Validationを行う
・AI出力も検証する
・エラー処理を入れる
・入力サイズを制限する
・不要な依存関係を追加しない
・既存機能を壊さない
・秘密情報をログへ出さない
最初に現在のプロジェクトを調査してください。
まだコード変更・インストールはしないでください。
報告:
1. 現在の構成
2. 推奨するAI API接続方法
3. 必要な環境変数
4. 変更予定ファイル
5. プロンプト設計
6. 出力形式
7. セキュリティ上の注意
8. コスト上の注意
9. テスト方法
自分のWebアプリに追加したいAI機能を1つだけ考え、「INPUTは何でOUTPUTは何か」をAIと整理してみましょう。まだAPI接続はせず、最初は機能設計だけでOKです。
ここまででできるようになったこと
Webサービス
↓
Database
↓
ログイン
↓
ユーザーごとのデータ
↓
AI API
↓
AI機能を持つWebアプリ
ここまで進めば、AIを単に使うだけではなく、AIを機能として組み込んだサービスを自分で作るところまで到達しています。
Tutorialsの次へ
次は、ここまで作ったWebアプリを題材に、公開後に改善していく方法を学びます。
作る
↓
公開する
↓
使ってもらう
↓
問題を見つける
↓
改善する
↓
再公開する