> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/19-development-flow/first-development.md).

# 初回の開発を始める

## このページの役割

リブログの開発へ初めて入るとき、または新しいプロダクトを立ち上げるときに、最初のIssueへ着手するための入口です。Handbookはリブログの考え方と判断基準を示し、実行コマンドや環境構築の詳細は対象リポジトリのREADMEやdocsで管理します。

初回から全章を読む必要はありません。対象、最初に確認する成果、参照する情報、確認方法を揃え、必要な工程の章へ進みます。

## 最初に読む範囲

| 確認すること             | 参照先                                                                                                                                   |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| プロダクトの目的と位置づけ      | [プロダクト一覧](/engineering-handbook/riburoguno/2-products.md)、該当する技術構成ページ                                                                 |
| リブログでの開発の進め方       | [開発思想](/engineering-handbook/riburoguno/4-development-philosophy.md)、[AIネイティブ開発の基本方針](/engineering-handbook/aineitibu/17-overview.md) |
| 対象の実行方法・現在仕様・作業ルール | 対象リポジトリのREADME、docs、適用されるAGENTS.md、既存のIssueやテスト                                                                                       |
| AIへ渡してよい情報         | [セキュリティとAI利用時の情報管理](/engineering-handbook/riburoguno/5-development-operations/security-and-ai-usage.md)                               |

プロダクトの技術構成ページは概要です。実際のバージョン、構成、コマンドはリポジトリで確認します。既存文書と実装が食い違う場合は、差異を記録して人間が判断します。

## 既存プロダクトに入る場合

1. 対象プロダクト、リポジトリ、作業するIssueを特定する。Issueがなければ、目的を整理して作成する。
2. README、適用されるAGENTS.md、対象機能の現在仕様と既存テストを確認する。文書がなければコードや設定から確認できる範囲を調べる。
3. ローカルでの起動方法、確認コマンド、必要な設定項目を把握する。秘密情報の値は依頼文へ含めない。
4. 変更前の状態を起動または関連テストで確認する。既存の失敗と今回の変更による失敗を区別できるように結果を残す。
5. 最初のIssueの変更範囲、完了条件、確認方法、文書の反映先を整理し、実装へ進む。

初回は、現在仕様を確認でき、動作と差分を判断できる範囲を選びます。環境構築や既存文書の不足が実装を妨げる場合は、その整備を先に扱います。リポジトリ全体の文書一式を作り直す必要はありません。

AIには、[既存プロダクトへの初回参加プロンプト](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/19-development-flow/pages/8knDmoOk5BeW7RRNDlp1#既存プロダクトへの初回参加プロンプト)を使えます。アクセス不足や環境の問題で確認できない項目は、未確認事項として分けます。

## 新しいプロダクトを始める場合

1. 誰のどの問題を解決するか、最初に確認したい利用者価値を決める。
2. 画面表示、データの参照、APIの応答など、結果を確認できる最小の成果と非対象を決める。
3. [技術選定の基準](/engineering-handbook/riburoguno/3-technology-and-architecture/technology-selection.md)を使い、既存資産、データ、公開方法、運用負担に合う構成を選ぶ。
4. リポジトリの管理先と公開範囲を決め、最初のIssueを作成する。土台、利用者価値、公開準備を分けるのは、別々に確認する必要がある場合だけでよい。
5. 起動・確認方法と最初の仕様を、READMEとIssue本文へ残す。必要になった段階で設計や運用の文書を分ける。

既存コードがない場合、調査対象は要件、利用するデータ、外部API、流用する資産、公開環境です。プロダクト全体の完成形を一度に生成せず、最初の成果を実装・確認してから次のIssueを決めます。

AIには、[新規プロダクトの初回整理プロンプト](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/19-development-flow/pages/8knDmoOk5BeW7RRNDlp1#新規プロダクトの初回整理プロンプト)でIssue案と構成案を整理させます。要件や採用技術の判断は人間が行い、初期実装を始める前にIssueへ反映します。

## 開発基盤の成立を先に確認する

新しいクラウド開発環境、ビルドサービス、配布経路、端末機能などを採用する場合、資料上の対応だけで動作するとは判断しません。業務機能を作り込む前に、採用する実際の構成で最小の起動・ビルド・反映経路を確認します。環境構築そのものに必要な最小実装は、この確認の対象です。

1. 人間が、継続利用する実プロジェクトか、独立した検証環境かを決める。新規開発で実プロジェクトを最小構成から育てる場合、AIの都合で別の検証用プロジェクトを追加しない。
2. 実際の生成設定、依存バージョン、対応するビルド環境、利用権限を確認する。既存の手順書や提供資料を読み、適用できる点と差異を整理する。
3. 採用環境で最小ビルドを実行し、対象の端末や実行環境で起動する。ローカルのプレビュー成功と配布物の起動成功を区別する。
4. ローカル編集から同期・ビルド・実行までの一巡を確認する。編集元、ソースの正本、生成物、同期先、同期対象と除外対象を明確にする。
5. 必要な接続先や権限を確認し、結果と未確認事項を残してから、その基盤に依存する機能の実装へ進む。

実プロジェクトを作成することと、既存の本番サービスやDBを変更すること、一般公開することは別です。作成、アップロード、ビルド、配布、既存本番設定の変更は、対象と許可範囲を分けます。秘密情報をソースや同期対象へ含めません。

確認できない場合は「未確認」だけで終わらせず、次に必要な操作、担当者、必要権限、成功条件を示します。AIがアクセスできない操作を人間へ依頼する場合は、操作順と共有してほしい結果を具体化します。接続障害や互換性の問題を、根拠なく技術変更や迂回実装で補いません。

詳細なコマンドや設定は対象リポジトリへ記録します。すべての開発に一律の配布検証を課すのではなく、新規採用・変更する基盤と、その上で実現する機能に必要な確認を選びます。

## 実装へ進める状態

次をIssue本文または既存文書から確認できれば、最初の実装へ進めます。小さな変更では、このために独立した文書一式を作りません。

* 対象リポジトリとIssueが決まっている
* 解決する問題と、今回実現しない範囲が分かる
* 既存の現在仕様、または新規開発で採用する最初の振る舞いが分かる
* 変更する範囲と、結果を左右する未決事項が整理されている
* 起動・テスト・手動確認のうち、何で完了を確認するか決まっている
* 採用した結果を残す文書が決まっている

環境の制約で実行できない確認は成功扱いにしません。結果を左右する仕様や権限などが未決なら、実装前に判断します。DB、認証・権限、公開API、既存データへ影響する場合は、[開発前に準備するファイル](/engineering-handbook/aineitibu/18-preparation-files.md)に沿って設計、確認計画、必要な移行・切り戻しの観点を分けます。

## 小さなIssueの記入例

以下は、既存の一覧にある空状態の文言を変更する汎用例です。実際の画面名、文言、確認方法へ置き換えて使います。

```markdown
## 目的
一覧が0件のとき、利用者が検索条件の見直しを試せるようにする。

## 現在仕様
検索結果が0件のとき「データがありません」と表示する。

## 今回の変更と非対象
文言を「条件に一致するデータがありません。検索条件を変更してください。」へ変える。
検索処理、API、権限、レイアウトは変更しない。

## 完了条件・確認方法
0件の場合に新しい文言が表示され、1件以上の場合は従来どおり表示される。
対象画面を両条件で確認し、既存の関連テストがある場合は実行する。
確認結果と、実行できなかった確認を記録する。

## 文書の反映先
既存の画面仕様に空状態の文言が書かれていれば更新する。
文言を管理する文書がなければ、変更内容と確認結果をIssueへ残す。
```

この程度の変更は、調査、実装、確認、必要な文書更新を[共通依頼ブロック](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/19-development-flow/pages/xTKcTF1wfVIQnKpUIJ5T#共通依頼ブロック)で一つの依頼にまとめられます。調査中にAPIや権限の変更が必要だと分かった場合は、Issueの範囲と設計を見直します。

## 着手後の参照先

| 状況            | 次に使うページ                                                                                                                                          |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| 工程全体を確認したい    | [AIネイティブ開発の全体フロー](/engineering-handbook/aineitibu/19-development-flow.md)                                                                        |
| 完了状態が曖昧       | [Goal First Development](/engineering-handbook/aineitibu/19-development-flow/goal-first-development.md)                                          |
| 実装を依頼したい      | [AI依頼プロンプト集](/engineering-handbook/aineitibu/27-prompt-templates.md)から変更内容に合うものを選ぶ                                                               |
| 動作が期待と違う      | [期待と違う結果を伝えるプロンプト](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/19-development-flow/pages/8knDmoOk5BeW7RRNDlp1#期待と違う結果を伝えるプロンプト) |
| 日を改めて再開する     | [作業再開プロンプト](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/19-development-flow/pages/8knDmoOk5BeW7RRNDlp1#作業再開プロンプト)               |
| 同じ機能を継続して更新する | [機能の継続更新](/engineering-handbook/aineitibu/29-continuous-feature-updates.md)                                                                      |

初回の完了時は、人間が動作と差分を確認し、必要な現在仕様・実行方法を更新します。確認結果、未確認事項、残課題をIssueへ残してから閉じ、次の変更も同じ入口から進めます。