AIエージェントは、指示を受けてパソコン内のファイルを読み、画面やプログラムを作り、エラーを調べるところまで手伝えるようになりました。以前の「方法を教えてもらい、自分で作業する」流れから、「目的を伝え、出来上がったものを確認する」流れへ変わりつつあります。
ただし、Webシステム全体を一度の指示で作り、確認せずに使い始めるのは危険です。AIを活用する開発ほど、計画する・小さく作る・実際に確かめるという基本が重要になります。
Webシステムは一度に完成させない
Webシステム開発は、新しい店舗を作ることに似ています。
図面を決めずに、受付、倉庫、会計、看板を同時に工事すると、通路がつながらなかったり、必要な場所に設備がなかったりします。まず一つの受付業務を動かし、利用者が迷わず使えるかを確認してから、次の場所へ広げます。
前のChapterで決めた「利用者・仕事の流れ・画面・機能・データ・権限」が、開発の図面になります。この図面をAIへ渡し、最初の試作範囲を一つに絞ります。
一つの仕事を最初から最後まで通す
予約管理なら、最初からすべての機能を作る必要はありません。
- 架空の予約申込みを入力する
- 受付担当者が一覧で確認する
- 詳細を開く
- 予約の状態を「確認済み」へ変更する
- 変更後の状態が保存・表示される
このように、一つの仕事を最初から最後まで通せる小さな仕組みを作ります。画面だけを並べた見本でも、データベースだけを作った状態でもなく、利用者が一つの成果へ到達できることが大切です。
開発で使う四つの場所を知る
AIとWebシステムを作るときは、主に四つの場所を使います。
| 場所 | 簡単な説明 | 確認すること |
|---|---|---|
| プロジェクトフォルダ | システムの設計図や部品をまとめた保管場所 | 関係のないファイルを触っていないか |
| IDE | ファイル、コード、AI、変更内容をまとめて見る作業台 | どのファイルが変わったか |
| ターミナル | 開発用サーバーやテストを動かす操作窓口 | 実行する命令と結果 |
| ブラウザ | 利用者と同じように画面を試す場所 | 表示、入力、エラー、操作の流れ |
専門的な命令をすべて暗記する必要はありません。AIへ実行を任せる場合でも、「今は何を動かしているのか」「結果をどこで確認するのか」は理解しておきましょう。
ローカル環境は公開前の試運転場所
開発中によく見るlocalhostは、自分のパソコン自身を表す名前です。開発用サーバーを起動すると、ブラウザから試作中の画面を確認できます。
これは店舗でいえば、開店前に店内だけで行う試運転です。インターネットへ一般公開された状態ではありません。
ローカルで動いたからといって、そのまま安全に公開できるわけではありません。公開環境、秘密情報、監視、バックアップなどは、別の公開準備が必要です。
画面を部品に分けると育てやすくなる
Webシステムの画面は、ボタン、入力欄、見出し、予約カード、一覧表、確認メッセージなどの小さな部品に分けられます。この再利用できる画面部品をコンポーネントと呼びます。
コンポーネントは、店舗で共通して使う棚や案内札のようなものです。同じ役割のボタンを画面ごとに別々に作るのではなく、一つの共通部品として管理します。
- 表示や操作をそろえやすい
- 一か所の修正を複数画面へ反映しやすい
- AIへ変更範囲を伝えやすい
- 後から画面や機能を増やしやすい
小規模なシステムでも部品を整理しておくと、事業の成長に合わせて機能を追加しやすくなります。ただし、最初から細かく分けすぎる必要はありません。同じ形や動作が繰り返し現れたところから共通化します。
AIには「計画・実装・確認」を分けて任せる
AIへ「予約システムを作って」とだけ伝えると、必要以上の機能を作ったり、会社の運用と異なる判断をしたりする可能性があります。
仕事を三つに分けます。
1．計画する
最初に、要件を読んで変更計画を出してもらいます。
- 今回作る利用の流れ
- 新しく作る画面と部品
- 変更するファイル
- 使用する仮データ
- 今回は作らない機能
- 完成を判断する条件
- 分からない点と確認が必要な点
この段階では、すぐにファイルを変更させず、方向が合っているかを人が確認します。
2．小さく実装する
計画を承認したら、一つの流れだけを実装します。
最初は架空データを使い、画面表示、入力、状態変更などの中心機能を作ります。本物の顧客情報、決済、外部への自動送信などは接続しません。
大きな依頼を一度に渡すより、「予約一覧を表示する」「詳細を開く」「状態を変更する」のように、確認できる単位で進めます。
3．人が確認する
完成の判断は、AIの「できました」という報告ではなく、実際の結果で行います。
- ブラウザで画面が表示されるか
- スマートフォン幅でも操作できるか
- 必須情報がない場合に止まるか
- 入力内容が正しく保存・表示されるか
- 権限のない利用者が操作できないか
- 関係のない画面が壊れていないか
- 変更したファイルと理由を説明できるか
見た目だけでなく、正常な場合と失敗する場合の両方を試します。
入力フォームは「間違いを直せること」まで設計する
入力フォームは、項目を並べるだけでは完成ではありません。
たとえば、予約希望日が空欄、メールアドレスの形式が違う、利用できない日付が選ばれた場合に、どこを直せばよいか分かる表示が必要です。
ブラウザ側の確認は、利用者がその場で間違いを直すために役立ちます。しかし、ブラウザ側の確認は回避される可能性があるため、サーバー側でも入力を確認します。
初回の試作では、次の四つを確かめます。
- 正しい入力を受け付ける
- 必須項目がない場合は保存しない
- 間違った場所と直し方を表示する
- 不正な入力をサーバー側でも拒否する
データベースやAPIは、必要になった順に接続する
画面ができた直後に、本物の顧客データや外部サービスへ接続する必要はありません。
まず架空データで利用の流れを確認し、次にどの情報を保存するかを確定します。その後で、データベースやAPIとの接続を一つずつ追加します。
APIは、外部サービスや別の機能と情報を受け渡す窓口です。予約カレンダー、メール通知、決済、AIなどと連携できますが、接続先が増えるほど、失敗時の対応や権限管理も増えます。
初回試作では、次の原則を守ります。
- 実在する顧客・従業員の情報を使わない
- APIキーやパスワードを本文や指示文へ書かない
- 読み取りだけで試せるなら、書き込み権限を与えない
- 接続に失敗しても、画面全体が操作不能にならないようにする
- 外部送信や決済は、人が確認する段階を残す
エラーはAIへ「状況ごと」伝える
開発中にエラーが出るのは珍しいことではありません。大切なのは、「動かない」とだけ伝えないことです。
AIへ次の情報をまとめて渡します。
- 何をしようとしたか
- どの画面・操作で起きたか
- 本来どうなるはずだったか
- 実際に何が起きたか
- 表示されたエラー文
- 直前に変更した内容
- 再現できる手順
画面の画像やエラー記録を渡す場合は、顧客情報、メールアドレス、APIキーなどが映っていないか確認します。
修正後は、そのエラーが消えたことだけでなく、以前動いていた機能が壊れていないかも試します。
Claude CodeとCodexは、共通の完成条件で使う
Claude CodeとCodexは、どちらもプロジェクトのファイルを調べ、変更し、開発用の命令やテストを実行する支援に利用できます。
ただし、画面、権限の選択肢、確認の仕組み、実行環境は同じではありません。操作名を無理にそろえるのではなく、共通する仕事の流れを決めます。
- 要件と対象フォルダを渡す
- 変更前に計画を確認する
- 一つの機能だけを実装する
- 変更内容を確認する
- 開発用サーバーで動かす
- 正常・不足・誤入力・権限外を試す
- 結果と残る課題を記録する
どちらを使っても、最終的に見るのは「人の仕事が正しく完了するか」です。
ローカルで動くことは、公開準備の始まり
Chapter 2の完成は、ローカル環境で小さなWebシステムが動き、試した結果と残る課題を説明できることです。
インターネットへ公開する前には、さらに次の準備があります。
- 変更履歴と戻し方
- 公開先とドメイン
- APIキーなど秘密情報の管理
- 個人情報と権限の保護
- 公開前テスト
- エラーの記録と通知
- バックアップと復旧
- 継続的な更新と費用管理
これらは、次のChapterで扱う公開・セキュリティ・保守運用の仕事です。
YMWorksのWebシステム開発でできる支援
AIを使えばコード作成は速くなりますが、事業に合う要件、画面の使いやすさ、データの扱い、安全な公開、継続的な改善まで自動で決まるわけではありません。
YMWorksでは、事業者の言葉をそのまま機能一覧へ変えるのではなく、現在の仕事を整理し、必要な仕組みへ落とし込み、小さな試作から確認する進め方を重視します。
- 現在の業務と課題の整理
- ホームページ、既存サービス、独自システムの比較
- 要件定義と画面・データ設計
- AIを活用した試作と実装
- 利用者目線での確認と改善
- 公開後の運用を考えた構成
「何を作ればよいか、まだ言葉にできていない」という段階でも、業務の整理から始められます。
まとめ
AIとWebシステムを作るときも、開発の基本は変わりません。
- 要件を図面として、最初の仕事を一つに絞る
- ローカル環境で公開前の試運転を行う
- 画面を再利用できる部品として整理する
- 計画・実装・確認を分ける
- フォームは間違いを直せるところまで設計する
- 架空データから始め、外部接続は一つずつ増やす
- AIの完了報告ではなく、実際の動作で判断する
AIは開発を速くする優秀な作業者です。一方、何を作るか、どこまで任せるか、何をもって完成とするかを決めるのは人です。この役割分担が、速さと安心を両立させます。