公開したWebサービスを改善する

Webサービスは、公開したら完成ではありません。

実際に使ってもらうことで、初めて「分かりにくい部分」「使われない機能」「エラー」「改善した方がよい導線」が見えてきます。

作る
↓
公開する
↓
使ってもらう
↓
データ・反応を見る
↓
問題を見つける
↓
改善する
↓
再公開

このページでは、公開後のWebサービスをAIと一緒に改善していく基本を学びます。

なぜ公開後の改善が重要？

開発中は「こう使われるはず」と考えていても、実際のユーザーは想定と違う使い方をすることがあります。

• ボタンの場所が分からない
• 入力フォームで迷う
• 説明が足りない
• スマホで使いにくい
• 途中で離脱する
• エラーが起きる

こうした問題は、公開前だけですべて見つけるのは難しいです。

STEP 1：まず正常に動いているか確認する

改善を始める前に、現在のサービスが正常に動いているか確認します。

□ トップページが開く

□ ログインできる

□ ログアウトできる

□ Databaseへ保存できる

□ AI機能が動く

□ エラー表示がおかしくない

□ スマートフォンでも使える

改善より先に、不具合があるなら修正を優先します。

STEP 2：エラーを確認する

本番環境では、開発中に出なかったエラーが発生することがあります。

利用しているサービスのログやエラー情報を確認します。

エラー発生
↓
ログを確認
↓
発生した場所を特定
↓
再現できるか確認
↓
原因調査
↓
修正

AIへエラー調査を依頼する場合も、いきなり修正させず、まず調査から始めます。

本番環境で次のエラーが発生しています。

まず原因を調査してください。

まだコード変更はしないでください。

確認してほしいこと:
・発生箇所
・再現条件
・関係するファイル
・ログ
・Database
・外部API

最後に、
原因候補と修正案を報告してください。

STEP 3：ユーザーの声を集める

改善のヒントは、実際に使った人の反応にもあります。

• 分かりにくかったところ
• 使いにくかったところ
• 欲しい機能
• 途中でやめた理由
• 便利だったところ

最初は大規模なアンケートでなくても構いません。

このサービスを使ってみて、

1. 分かりにくかったところ
2. 使いにくかったところ
3. 欲しい機能
4. 良かったところ

を教えてください。

少人数でも、実際の利用者から具体的な意見をもらうと改善点が見えやすくなります。

STEP 4：感想と事実を分ける

ユーザーの意見は重要ですが、1人の感想だけですべてを変える必要はありません。

ユーザーの感想

「ボタンが分かりにくい」

↓

確認する

他のユーザーも迷っている？
クリックされていない？
配置に問題がある？

↓

改善判断

意見と実際の利用状況を組み合わせて判断します。

STEP 5：アクセス解析を見る

アクセス解析を導入している場合は、ユーザーがどのページを見ているか確認できます。

• どのページが見られているか
• どこからアクセスしているか
• どの導線が使われているか
• どこで離脱しているか

解析ツールによって確認できる内容は異なります。

STEP 6：見る数字を増やしすぎない

最初から大量の指標を追う必要はありません。

サービスの目的に合う数字を少数だけ決めます。

例

訪問
↓
登録
↓
AI機能を使う
↓
再訪する

たとえばAIサービスなら、

• 新規登録数
• AI機能の利用数
• 利用成功率
• 再利用率

などを見ることができます。

STEP 7：ユーザー行動をイベントとして考える

ページ表示だけではなく、重要な操作を計測する考え方もあります。

ページ表示

↓

入力開始

↓

AIで改善ボタン

↓

AI処理成功

↓

結果保存

この流れを見れば、「どこまでは進んでいて、どこで止まっているか」を判断しやすくなります。

STEP 8：改善候補を全部書き出す

ユーザーの声・アクセス解析・自分で使った感想から、改善候補をまとめます。

改善候補

・入力欄が分かりにくい
・AI処理が遅い
・スマホでボタンが小さい
・エラー文が分かりにくい
・保存したIdeaを編集できない
・初回ユーザー向け説明が足りない

この時点では、全部実装する必要はありません。

STEP 9：AIに改善候補を整理させる

改善候補が増えたらAIに分類してもらえます。

次の改善候補を整理してください。

［改善候補一覧］

次のカテゴリーに分類してください。

・重大な不具合
・使いやすさ
・新機能
・パフォーマンス
・セキュリティ
・デザイン
・将来検討

まだ優先順位は決めず、
まず分類だけしてください。

STEP 10：優先順位を決める

改善候補を全部同時に進めると、また大きな変更になります。

そこで優先順位を決めます。

優先度 高

サービスが使えない
データが消える
セキュリティ問題
重大なエラー

↓

優先度 中

使いにくい
離脱につながる
重要機能の改善

↓

優先度 低

細かなデザイン
将来機能
あると便利

見た目の改善より、まずサービスが正しく安全に使えることを優先します。

STEP 11：ImpactとEffortで考える

優先順位を考える簡単な方法として、「効果」と「作業量」で比較する方法があります。

Impact
改善したときの効果

Effort
実装に必要な作業量

たとえば、

効果が大きい
+
作業量が小さい

↓

優先しやすい

という考え方です。

次の改善候補を比較してください。

［候補一覧］

各候補について、

・Impact
・Effort
・リスク
・依存関係

を整理してください。

まだ最終決定はせず、
判断材料を出してください。

STEP 12：1回の改善を小さくする

改善でも、小さな変更単位を意識します。

悪い例

UI改善
+
認証変更
+
Database変更
+
AIモデル変更
+
新機能追加

↓

まとめて公開

問題が起きたときに原因が分かりにくくなります。

改善1

入力フォーム改善
↓
公開
↓
確認

改善2

AIエラー表示改善
↓
公開
↓
確認

小さく変更して結果を確認します。

STEP 13：改善前の状態を残す

改善した結果、本当に良くなったか比較するために、変更前の状態を把握しておきます。

改善前

AI実行成功率
60%

↓

改善

↓

改善後

AI実行成功率
90%

数値がない場合でも、スクリーンショットやユーザーの声を残しておくと比較できます。

STEP 14：改善用Branchを作る

本番コードを直接変更せず、改善用Branchで作業します。

main
│
└─ feature/improve-ai-error-ui

現在の状態を確認します。

git status
git branch --show-current

AIにも作業前確認をさせます。

改善作業を始める前に確認してください。

・現在のディレクトリ
・Git Branch
・git status
・未Commit変更
・対象機能の現在実装

まだ変更しないでください。

STEP 15：改善内容をAIに調査させる

たとえば「AIエラー表示を改善したい」とします。

目的:
AI処理失敗時のユーザー体験を改善する。

現在の問題:
エラー時に何も表示されないことがある。

まず現在の実装を調査してください。

確認:
・AI API呼び出し
・エラー処理
・Loading状態
・ユーザーへの表示
・ログ

まだコード変更はしないでください。

原因と改善案を報告してください。

原因が分かってから実装します。

STEP 16：完了条件を決める

改善の前に、「何ができたら完了か」を決めます。

完成条件

・AI処理中はLoading表示
・連続クリックできない
・成功時は結果表示
・失敗時はエラー表示
・再試行できる
・既存の成功処理を壊さない
・スマホでも使える

条件が明確なら、AI側も作業範囲を理解しやすくなります。

STEP 17：変更を実装する

調査結果をもとに改善してください。

完成条件:
［完了条件］

条件:
・対象機能だけ変更
・不要なリファクタリングをしない
・新しい依存関係を勝手に追加しない
・既存動作を壊さない

実装後に変更ファイルを報告してください。

STEP 18：自分で実際に使う

コード上のチェックだけではなく、実際の操作を確認します。

正常時

入力
↓
AI実行
↓
Loading
↓
成功
↓
結果表示

失敗時

入力
↓
AI実行
↓
Loading
↓
失敗
↓
エラー表示
↓
再試行

ユーザーが実際にたどる流れでテストします。

STEP 19：モバイルでも確認する

PCでは問題なくても、スマートフォンで使いにくい場合があります。

• ボタンサイズ
• 入力欄
• 文字サイズ
• Loading表示
• エラー文
• スクロール

などを確認します。

STEP 20：git diffを確認する

git status
git diff

「小さな改善のつもりが、大量のファイルを変更していないか」を確認します。

現在のgit diffをレビューしてください。

確認:
・改善目的と関係ない変更
・不要なファイル変更
・秘密情報
・既存機能への影響
・不要な依存関係

問題があれば、
修正前に報告してください。

STEP 21：公開前チェックをする

今回の改善に対する公開前チェックをしてください。

確認:
・lint
・型チェック
・build
・利用可能なテスト
・対象機能
・既存機能
・モバイル表示
・秘密情報

失敗項目がある場合は、
成功とは報告しないでください。

STEP 22：Previewで確認する

ローカルで問題がなければ、GitHubへPushしてPreview環境で確認します。

Local
↓
GitHub
↓
Preview
↓
実際の公開環境に近い状態で確認

環境変数・Database・APIなど、localhostとは違う部分もあるためPreview確認は重要です。

STEP 23：Productionへ反映する

Previewで問題がなければ、現在のGit運用に従ってProductionへ反映します。

改善
↓
Local確認
↓
Preview
↓
Production
↓
本番確認

本番反映直後も、対象機能を実際に操作します。

STEP 24：改善後の結果を確認する

公開したら、「実装できたから終了」ではありません。

改善前に見ていた数字やユーザーの反応と比較します。

改善前
↓
問題

改善
↓
公開

改善後
↓
結果確認

結果が良くなっていなければ、さらに原因を考えます。

改善して悪くなることもある

変更したからといって、必ず良くなるとは限りません。

たとえば、

ボタンを目立たせた
↓
クリックは増えた
↓
間違って押す人も増えた

ということもあります。

そのため改善は「仮説」として扱います。

仮説

ここを改善すると良くなるはず

↓

実装

↓

結果確認

↓

本当に良くなった？

STEP 25：改善ログを残す

何を変更し、どうなったかを簡単に残しておくと後で役立ちます。

改善内容:
AIエラー表示

目的:
エラー時の離脱を減らす

変更:
エラー文 + 再試行ボタン

公開日:
XXXX/XX/XX

結果:
再試行率 ○%
成功率 ○%

判断:
継続 / 追加改善 / 元に戻す

AIに記録を整理させることもできます。

STEP 26：ユーザー要望をそのまま全部作らない

サービスを公開すると、さまざまな要望が出てきます。

要望

機能Aが欲しい
機能Bも欲しい
機能Cも欲しい

↓

全部実装

↓

サービスが複雑化

要望が本当に多くのユーザーに必要なのか、サービスの目的に合うか確認します。

STEP 27：機能を追加しない改善もある

改善というと新機能追加を考えがちですが、削ることも改善です。

• 不要な入力項目を減らす
• 説明を短くする
• ボタンを1つにする
• 不要な画面をなくす
• 手順を減らす

10ステップ

↓

不要な3ステップ削除

↓

7ステップ

機能が多いことと、使いやすいことは同じではありません。

STEP 28：AIを改善会議の相手にする

集めたデータやユーザーの声をAIへ渡して、改善案を整理できます。

以下はWebサービス公開後の情報です。

ユーザーの声:
［内容］

現在の問題:
［内容］

利用データ:
［内容］

実装コストの制約:
［内容］

まず状況を整理してください。

次に、
改善候補を出してください。

各案について、
・期待できる効果
・実装難易度
・リスク
・検証方法

を整理してください。

まだ実装はしないでください。

AIは判断材料を整理する相手として使えます。

公開後改善の基本サイクル

公開
↓
計測
↓
ユーザーの声
↓
問題発見
↓
優先順位
↓
小さく改善
↓
Preview
↓
Production
↓
結果確認
↓
次の改善

このサイクルを繰り返すことで、Webサービスを少しずつ良くしていきます。

改善をAIへ依頼する基本テンプレート

目的:
公開中のWebサービスを改善する。

現在の問題:
［問題］

根拠:
［ユーザーの声 / データ / エラー］

改善したい状態:
［ゴール］

制約:
・既存機能を壊さない
・変更範囲を最小限にする
・不要なリファクタリングをしない
・新しい依存関係を勝手に追加しない
・本番Databaseを直接変更しない

まず現在の実装を調査してください。

まだコード変更はしないでください。

報告:
1. 原因候補
2. 関係するファイル
3. 改善案
4. 変更範囲
5. リスク
6. 完了条件
7. テスト方法
8. 改善後に見る指標

Tutorialsで学んだこと

0からWebサービスを作る
↓
GitHub・Vercelで公開
↓
Databaseを追加
↓
ログインを追加
↓
AI機能を追加
↓
公開後に改善する

ここまで進めば、AIを使ってアイデアを形にし、公開し、改善する一連の流れを経験できます。

次に進む

次は、Learn内でまだ整備していないAIツールの使い方を学ぶコンテンツや、より実践的なチュートリアルへ進めます。

Learnトップへ戻る →