先に、私の結論
基本は、1つの機能をUI/UX、処理、保存、再読み込みまでつなぐ「縦切り」で進める。
ただし最初に、認証、画面枠、デザインの基本、データの決まりなど共通土台だけを薄く作る。
結論は、1機能ずつUI/UXまでつなぐ
私なら、基本は2番を選びます。
1つの機能を、画面だけでも内部処理だけでもなく、利用者が実際に使えるところまでつなげます。
入口 → 入力 → 処理 → API → 保存 → 表示 → 再読み込みたとえば「プロフィール編集」なら、入力フォームを置いて終わりではありません。
保存ボタンを押し、入力内容が保存され、成功やエラーが表示され、ページを開き直しても変更が残るところまでを1組にします。
開発では、このように利用者が使える機能を縦方向に通す考え方を「縦切り」「Vertical Slice」と呼ぶことがあります。
ただし、最初から1画面ずつバラバラに作るわけではありません。
認証、画面の枠、文字や色の基本、データの持ち方、エラー表示など、共通土台だけは最初に薄く決めます。
1番は、機能を先に横並びで作る流れ
1番は、先に認証、検索、通知、決済などの内部機能を作り、あとから画面とつなぐ進め方です。
データベース、API、フロントエンドのように、技術の層ごとに作るため「横切り」と考えると分かりやすくなります。
1番のメリット
- データ構造やAPIの共通ルールをまとめて考えやすい
- UIがないバッチ処理、CLI、API中心の製品では進めやすい
- 仕様が完全に固まり、入出力の契約も変わらないなら分担しやすい
- 画面担当が決まる前でも、内部処理の試作を始められる
1番のデメリット
- 最後につなぐまで、利用者が本当に操作できるか分からない
- APIの形と画面で必要な情報がずれたとき、複数機能をまとめて直すことになる
- 読み込み中、データなし、入力エラーなど、画面で初めて気づく状態が後回しになる
- 「機能はできた」と「アプリとして使える」の間に、大きな統合作業が残りやすい
- AIエージェントごとに前提が少しずつ違うと、最後に型、名前、保存方法を合わせる作業が増える
最初は速く見えても、完成度を画面で確かめる時期が遅くなるのが弱点です。
2番は、1つの利用者行動を完成させる流れ
2番は、「新規登録」「記事を保存」「商品を検索」のように、1つの利用者行動ごとにUI/UXと内部機能をつなぎます。
2番のメリット
- 早い段階で、実際に触れる画面ができる
- UIを通して、足りないデータや不要な処理に気づきやすい
- 1機能ごとにテストできるため、不具合の範囲を絞りやすい
- 最初の完成例を、次の機能の部品やAIエージェントへの見本にできる
- 途中で優先順位が変わっても、完成済みの機能は使える状態で残る
2番のデメリット
- 最初の1機能は、共通部品も作るため遅く見えやすい
- 各機能で別々の見た目を作ると、UIがばらつく
- 将来の共通化を考えなさすぎると、似た処理が重複する
- 逆に共通化を先回りしすぎると、縦切りの小ささが失われる
大事なのは、毎回デザインを完成品の細かさまで磨くことではありません。
利用者が迷わず操作でき、必要な状態がそろい、次の機能へ再利用できる程度まで整えます。細かな色や余白は、2〜3機能を作って共通パターンが見えてからそろえても間に合います。
また、UXは1機能だけでは完結しません。「登録して、検索して、保存する」のように複数機能をまたぐ流れは、数機能ごとに最初から最後まで通して確認します。
なぜAIエージェント開発では2番が合いやすいのか
ここは公式仕様ではなく、今回の比較からの私の判断です。
AIエージェントは、依頼された範囲が明確なほど、変更する場所と完了条件を絞りやすくなります。
「検索、通知、決済を全部作って」と広く頼むより、「今回は商品検索だけ。検索欄への入力から、結果表示、0件、通信エラー、再読み込みまで確認」と頼むほうが、何をもって完成とするかが具体的です。
1機能ごとに現在の画面、コード、テストを確認できるため、間違った前提を次の機能へ広げる前に止めやすくなります。
一方、機能を全部作ってから接続すると、各エージェントが別々に想定したデータ名、エラー形式、画面の状態が、最後の統合で一度に表面化することがあります。
AIエージェントを使うメリット
AIエージェントのよさは、コードを書いてもらう速さだけではありません。
調査、実装、確認、記録を同じ流れで頼めることにあります。
| 任せられること | 期待できる助け |
|---|---|
| 現状調査 | 関係するファイルや処理のつながりを探し、変更前の状態を整理する |
| たたき台作成 | 文章で伝えた目的から、画面や処理の最初の案を作る |
| 実装 | 複数ファイルにまたがる変更を、対象範囲に沿って進める |
| 確認 | テスト、型チェック、ビルド、画面表示などを実行する |
| 記録 | 変更した理由、実行した確認、残る課題を文章に残す |
人が毎回、すべてのファイルを探して、修正して、確認結果をまとめるより、最初の調査や繰り返し作業を任せやすくなります。
また、1つ目の機能で作った入力欄、エラー表示、テストの形を読み取り、2つ目の機能へ同じルールを使ってもらうこともできます。
ただし、AIエージェントが出したコードが正しいことを保証するものではありません。
商品として何を作るか、利用者にとって分かりやすいか、個人情報や決済を安全に扱えているか、公開してよいかは、人が確認する必要があります。
AIエージェントを有効活用する7つの方法
1. 作業手順より、目的と成功条件を先に伝える
「このファイルへこのコードを書いて」だけでなく、「誰が何をできれば成功か」を伝えます。
目的：初めての利用者がメールアドレスで登録できる
成功条件：登録、入力エラー、通信エラー、再読み込み後のログイン状態を確認できる
対象：新規登録画面と関連するAPI
対象外：SNSログイン、管理画面、料金プラン細かな手順をすべて決めるより、目的、現在の情報、変えてはいけない条件、完了の証拠を示すほうが、AIエージェントは調査と実装の道筋を選びやすくなります。
2. 1回の依頼を、使える1機能に絞る
「アプリを完成させて」では広すぎます。
「新規登録だけ」「記事保存だけ」のように、利用者が1つの目的を達成できる単位へ絞ります。
小さすぎてボタンの部品だけにならず、大きすぎて複数の利用者行動が混ざらない範囲が目安です。
3. 現在のコードと資料を先に確認してもらう
AIエージェントへ、いきなり実装を始めてもらいません。
現在のコード、未保存の変更、仕様書、デザイン、関連テストを先に確認してもらいます。
過去の説明と現在のコードが違う場合は、推測で進めず、食い違いとして報告してもらいます。
4. 画面から再読み込みまで一本道で追ってもらう
1ファイルの修正だけでは、保存後や別画面で反映されないことがあります。
入口 → 入力 → 処理 → API → 保存 → 表示 → 再読み込みこの順番で関係する場所を調べ、実装後も同じ順番で確認してもらいます。
5. 正常時だけでなく、途中の状態も完成条件へ入れる
AIエージェントは、書かれていない状態を自動ですべて補うとは限りません。
- 読み込み中
- データがない
- 入力内容が間違っている
- 通信に失敗した
- 保存に成功した
- スマートフォンで表示した
- キーボードで操作した
必要な状態を完了条件へ含めます。
6. 実装した本人にも、証拠を出してもらう
「できました」という返事だけで終わらせません。
変更したファイル、実行したテスト、画面で確認した幅、確認できなかったことを分けて報告してもらいます。
重要な機能では、実装とは別の確認として、差分レビューや本番での動作確認も行います。
7. 並行作業は、変更場所が重ならないときだけ使う
複数のAIエージェントを使うと、調査や独立した機能を同時に進められます。
一方で、同じ認証処理、データ型、共通UIを別々に変更させると、速さより衝突の修正が増えることがあります。
並行化する前に、担当する機能、変更してよいファイル、共有するAPIやデータ形式、最後に統合する担当を決めます。
公式資料から確認できる考え方
アジャイルソフトウェア開発宣言の背後にある原則では、価値あるソフトウェアを早く継続的に届けること、動くソフトウェアを短い間隔で届けることが示されています。
Scrum Guideの公式版でも、Incrementはそれまでの成果へ追加され、相互に動くことを十分に確認し、価値を提供するには利用可能でなければならないと説明されています。
これは「必ず縦切りにしなければならない」という規則ではありません。ただ、内部機能だけを長く積み上げるより、使える小さな完成単位で確認する考え方と相性がよい資料です。
テストについても、MDNのWeb開発カリキュラムは、画面操作などの機能テストに加え、部品同士が連携して動く統合テストを扱っています。
UI/UXは、コードが全部できてから初めて考えるものでもありません。GOV.UK Design Systemは、用意された部品やパターンであっても、自分たちのサービスで機能するか利用者調査で確かめることが重要だと案内しています。
AIエージェントへの指示について、OpenAI公式のモデルガイダンスでは、目的、関連する情報、制約、承認が必要な境界、成功条件を伝えることが勧められています。コード変更後は、対象機能のテスト、型チェック、ビルド、必要な画面確認など、具体的な検証を依頼する考え方も示されています。
また、OpenAI公式のCodex活用例には、大きなコードベースの処理経路調査、細かなUI変更、テスト、デプロイ、ドキュメント更新などが挙げられています。使える範囲はAIエージェントに与えたツールや権限で変わるため、どこまで操作を任せるかも先に決めます。
おすすめは、薄い共通土台を作ってから縦切り
私が選ぶなら、次の順番です。
- アプリで最初に成立させたい利用者行動を1つ決める
- その機能に必要な共通土台だけを作る
- UI、処理、保存、再読み込みまで一本道でつなぐ
- 成功、エラー、データなし、読み込み中、スマートフォンを確認する
- できた部品とルールを使い、次の機能へ進む
- 2〜3機能ごとに、UIのばらつきと重複処理をまとめて整える
最初に作る共通土台は、次の程度です。
| 共通土台 | 最初に決める範囲 |
|---|---|
| 画面 | ヘッダー、本文幅、基本の文字、色、ボタン |
| データ | ID、日時、必須項目、保存方法 |
| API | 成功とエラーの基本形式 |
| 認証 | ログインが必要か、誰が何を見られるか |
| 品質確認 | テスト、スマホ表示、キーボード操作の最低条件 |
まだ使わない通知基盤や、将来必要になるかもしれない複雑な権限まで、先に完成させる必要はありません。
1番を選んでもよい場面
1番がいつも悪いわけではありません。
- 画面がないAPI、CLI、定期実行の処理を作る
- 既存UIがあり、接続先のAPIだけをまとめて置き換える
- 入出力仕様が固定され、契約テストも用意できている
- 捨てる前提の技術検証で、まず処理が可能かだけ確かめたい
- 共通基盤の移行そのものが今回の目的になっている
この場合も、最後まで接続を待たず、1本だけ先に実際の利用先へつなぐと安心です。
まとめ：完成の単位を「使える1機能」にする
2つを比べると、一般的な画面付きアプリでは、1機能ずつUI/UXまでつなぐ2番が進めやすいと考えます。
ただし、正確には次の組み合わせです。
薄い共通土台
↓
機能AをUIから再読み込みまで完成
↓
機能Bを同じ形で完成
↓
数機能ごとにUIと共通処理を整理機能を作ることと、UI/UXを作ることを別々の最終工程にしません。
「内部では動く」ではなく、「利用者が操作し、結果を確認し、やり直しても正しく動く」を完成の単位にします。
AIエージェントへ頼むときも、機能名だけでなく、入口、保存、表示、エラー、再読み込みまでを完了条件に含めると、途中の抜けを確認しやすくなります。
コピーして使えます
1機能ずつUIから再読み込みまで完成させる指示
ついでに気になったこと
最初からUIをきれいに仕上げたほうがいい？
最初の1機能では、使い方を判断できる程度に整えれば十分です。色や余白を細部まで磨くより、操作の流れと状態表示を確認し、共通パターンが見えてから全体をそろえるほうが手戻りを抑えやすくなります。
バックエンド担当とフロント担当が別でも縦切りがいい？
担当は分かれていても、完成の単位は1つの利用者行動にそろえられます。APIの入出力例と完了条件を共有し、画面と処理を同じ短い期間でつなぐ形です。
複数のAIエージェントへ並行で頼んでもいい？
依存しない機能や、変更するファイルが重ならない作業なら並行化できます。共通の認証、型、画面部品、データ構造を同時に別々の判断で変更させると衝突しやすいため、担当範囲と共通契約を先に固定します。
どこまでできたら1機能の完成と言える？
ボタンが表示された段階ではなく、入力、処理、保存、結果表示、エラー表示、再読み込み後の状態まで期待どおり確認できた段階です。公開対象なら、本番環境でも同じ流れを確認します。
小さなアプリでも共通土台は必要？
必要ですが、最小限で構いません。画面枠、基本の文字と色、データ保存方法、エラーの扱い、テストの実行方法など、最初の機能を通すために必要なものだけ決めます。