マニュアルReplit
2026年08月04日
既存システムを改修・修正する際の指示の書き方
アプリ開発は、一度作成して終わりではありません。
実際には、
● 機能追加
● バグ修正
● UI調整
● リファクタリング
を繰り返しながら改善していきます。
Replitでも同様で、新規開発よりも「既存コードを安全に変更する」方が難しい場面があります。
ここでは、修正作業を進める際のポイントを紹介します。
修正したい箇所だけでなく、修正したくない箇所を伝える
修正依頼では、「何を変更するか」だけでなく、「何を変えないか」を一緒に書くことが重要です。
例えば、
既存UIや現在の動作は変更せずに、ダークモードを追加してください。
のように制約を明示すると、意図しない変更を防ぎやすくなります。
また、リファクタリングでは、
現在の動作は変更せず、コード整理のみ実施してください。
のように、「構造だけ整理したい」ことを明示しておくと、不要な仕様変更を防ぐことができます。
大きな修正は、ドキュメントを書いてから小さく進める
複雑な修正を一度に依頼すると、Agent が意図しない変更を行ったり、同じ修正を繰り返したりする場合があります。
そのため、大規模な修正では、
● まず修正方針を Markdown に整理する
● 1画面ずつ進める
● 進捗を Markdown に残す
● 確認しながら段階的に進める
といった形で、作業を小さな単位に分けながら進めると、安定した開発につながります。
例えば、最初は実装を行わず、
まずはコード修正を行わず、修正方針を README.md に整理してください。
のように、認識のすり合わせから始めるのも有効です。
また、アプリ全体の修正やリファクタリングをする際は、以下のような進捗管理用 Markdown を作成しておくと、現在の進捗状況を Agent に共有しやすくなります。
# リファクタリング進捗 — controller / view 分離
## 方針
全画面を対象に、表示処理とデータ取得・状態管理の処理を分離します。
- `view`：画面表示・レイアウト・UI部品を担当
- `controller`：データ取得・状態管理・イベント処理を担当
既存の画面表示や動作は変更せず、構成整理のみを行います。
### 注意事項
- 既存UIは変更しない
- 現在の動作は変更しない
- 1画面ずつ修正し、完了後に動作確認する
- マジックストリング・マジックナンバーは `/consts/` 内の各画面用ファイルに定義する
## 修正済み
| 画面 | controller | view | 備考 |
|---|---|---|---|
| 日報入力 | 対応済み | 対応済み | 動作確認済み |
| 日報一覧 | 対応済み | 対応済み | 動作確認済み |
## 未対応
| 画面 | controller | view | 備考 |
|---|---|---|---|
| ホーム | 未対応 | 未対応 | - |
| ユーザー設定 | 未対応 | 未対応 | - |
一度に全体を変更するよりも、1機能・1セクションずつ確認しながら進める方が、安定して開発を進めることができます。