こんにちは 業務改善エンジニアのこめまるです
最近、ローカル環境で動く画像編集アプリの開発を進めています。
内容としては、画像の取り込み、編集条件の指定、プレビュー、処理結果の確認、再実行、作業履歴の保存などを行うアプリです。
たとえば、商品画像や資料用画像のように、同じような編集作業を何度も行う場面では、手作業だけだとどうしても時間がかかります。
そこで、画像編集の流れをアプリ化しつつ、処理条件や確認観点を整理して、再現性のある形にできないかを試しています。
今回の記事で書きたいのは、画像編集そのものではありません。
テーマは、AI駆動開発を実際に回してみて、開発プロセスの考え方がどう変わったかです。
AIを使うと、たしかに実装は速くなります。
でも、複雑なアプリを作るほど、単にAIにコードを書かせるだけではうまくいきません。
むしろ大事だったのは、要件、設計、実装、テスト、保守運用までを見据えて、AIが安全に動ける開発の型を作ることでした。
AI駆動開発は「AIにコードを書かせること」ではなかった
最初は、AI駆動開発というと、
「こういう機能を作って」
「このバグを直して」
「このコードをリファクタして」
と依頼して、AIにコードを書いてもらうものだと思っていました。
もちろん、それ自体は間違っていません。
ただ、実際にアプリを作っていると、それだけでは全然足りませんでした。
特に、画像編集のように結果を目視で確認する要素があるアプリでは、エラーが分かりやすく落ちてくれるとは限りません。
ビルドは通る。
処理も最後まで走る。
でも出力結果を見ると、一部だけ不自然。
特定の条件だけ編集結果が崩れる。
前の修正で直ったはずの箇所が、別の条件でまた壊れる。
こういうことが普通に起きます。
このときに、ただAIに
まだ変です。直してください。
と伝えても、かなりの確率で修正が迷子になります。
開発効率を上げるには、まず品質を観測できる状態にする
AI駆動開発というと、どうしても「どれだけ速く実装できるか」に目が行きます。
ただ、今回の開発で痛感したのは、スピードより先に品質を観測できる状態を作る必要があるということです。
たとえば、以下のような問題がありました。
- ある編集条件だけ、意図した結果にならない
- プレビューでは問題ないのに、保存後の結果が微妙に違う
- 手動操作では再現できるが、自動処理にすると結果が安定しない
- エラーにはならないが、期待した処理が実行されていない
- 安全側に戻したつもりの処理が、実際には一部だけ反映されている
このあたりは、コードだけ見てもなかなか原因が分かりません。
見た目の違和感はある。
でも、その違和感がどの処理で発生したのかが分からない。
ここで必要だったのは、いきなり修正することではなく、
どこで壊れたのかを観測できる状態にすること
でした。
これは業務アプリケーション開発でも同じだと思っています。
画面上は一見動いている。
でも、業務ルールの境界条件でおかしい。
例外時の戻し処理が足りない。
後続処理との整合性が崩れる。
運用に入ってから調査しづらい。
こういう問題は、AIに実装させる前に、何をもって正常と判断するのかを設計しておかないと見落としやすくなります。
AIに任せるためには、ログ設計がかなり重要
AI駆動開発で大事なのは、AIに「修正して」と投げることではなく、AIが判断できる材料を渡すことだと感じました。
人間が画面を見ていると、
「プレビューと保存結果が違う」
「この条件だけ処理結果が不自然」
「元の状態に戻したいのに、一部だけ前の処理が残っている」
という表現になります。
ただ、これだけだとAI側はコード上のどの条件が悪いのか判断しづらいです。
そこで、処理の途中に診断ログを増やしていきました。
input_file_loaded
edit_condition_selected
preview_generated
save_process_started
save_process_completed
restore_original_applied
validation_result
output_diff_score
こういうログがあると、AIへの依頼がかなり具体的になります。
悪い例です。
保存結果が変です。直してください。
良い例です。
プレビュー生成までは期待通りですが、保存処理後の結果だけ差分が出ています。
ログを見るとpreview_generated=true、save_process_completed=trueですが、validation_result=warningになっています。
保存処理側で編集条件の一部が再適用されていない可能性があります。
保存処理の分岐を確認し、プレビュー時と保存時で同じ編集条件が使われるようにしてください。
ただし、既存の手動編集フローは壊さないでください。
ここまで条件を渡すと、AIの修正精度がかなり変わります。
AIは「それっぽい修正」を作るのは得意です。
でも、「どの条件では修正してはいけないか」まで明示しないと、別の正常ケースを壊すことがあります。
「修正して」より「仮説を検証して」のほうが強い
AIにバグ修正を依頼するとき、最近はなるべく以下の形にしています。
【現象】
〇〇の条件で△△が起きています。
【仮説】
原因は□□の処理が保存時に再利用されていないことだと考えています。
【確認してほしいこと】
1.この仮説がコード上正しいか確認する
2.正しければ最小修正する
3.正しくなければ別の原因候補を挙げる
【制約】
-対象ファイルを絞って確認する
-既存の正常ケースを壊さない
-手動編集フローは変更しない
-診断ログを追加する
ポイントは、いきなり「全部直して」と言わないことです。
特に複雑な処理では、AIに一気に大きな修正をさせると、後から何が効いたのか分からなくなります。
今回の画像編集アプリ開発でも、何度かこの罠にハマりました。
たしかに出力は少し良くなる。
でも、別の条件では悪化する。
さらに、修正範囲が広すぎて戻しづらい。
これを避けるには、AIにも人間にも分かる単位で、仮説を小さく切る必要があります。
要件定義から保守運用まで、AI前提で考える
AI駆動開発を本格的に使うなら、実装工程だけに閉じないほうがいいと感じています。
今回の開発でも、AIを使ったのはコード生成だけではありません。
| 工程 | AIを使ったこと | 人間が握ったこと |
|---|---|---|
| 要件整理 | 機能分解、実現方式の候補出し | 何を作るべきか、何を作らないか |
| 設計 | 画面構成案、処理フロー案、ログ設計案 | 安全側の仕様、境界条件、優先順位 |
| 実装 | 小さな修正、関数分割、ログ追加 | 変更範囲、禁止事項、レビュー観点 |
| テスト | 確認観点、異常系ケース、再現手順の整理 | 最終的な品質判断、業務上の妥当性 |
| 保守運用 | 調査用ログ、再実行手順、原因切り分け案 | 運用で困らない設計になっているか |
AIは実装だけでなく、要件定義や設計の壁打ちにも使えます。
ただし、AIに任せるほど、人間側が「何を成果とするか」を明確に持っておく必要があります。
業務アプリケーション開発であれば、単に画面が動けばよいわけではありません。
- 実際の業務フローに合っているか
- 例外時に現場が困らないか
- 後から調査できるか
- 権限やデータの扱いが安全か
- 保守担当が追える構造か
このあたりまで見ないと、AIで速く作ったものが、後から速く壊れる可能性があります。
AIエディタは魔法の道具ではなく、開発プロセスを変える道具
ChatGPT/Codex/ClaudeCode/Cursor/GitHubCopilotのようなツールは、本当に強力です。
ただ、使ってみて感じるのは、AIエディタは「便利な補助ツール」というより、開発プロセス自体を変える道具だということです。
今までは、人間が調査して、人間が設計して、人間が実装して、人間がレビューする流れでした。
AI駆動開発では、そこにAIが入ってきます。
でも、AIが入ることで人間の役割が減るというより、変わります。
人間の役割は、コードを全部手で書くことから、次のような方向に寄っていきます。
- 課題を分解する
- 成功条件を定義する
- 禁止事項を明確にする
- AIに渡す情報を整える
- 出力をレビューする
- 再現性のある開発手順にする
- チームに共有できる形にする
特にチームでAI駆動開発を導入するなら、「使っている人だけが速い」状態では足りません。
誰が使っても一定の品質が出るように、プロンプトの型、レビュー観点、ログ設計、テスト観点を共有していく必要があります。
AI駆動開発で重要だった進め方
今回かなり効果があった進め方は、以下です。
1.現象を具体的に書く
2.原因の仮説を立てる
3.関係しそうなログを出す
4.AIにコードを読ませる
5.最小修正させる
6.出力結果とログを比較する
7.良ければ次の問題に進む
8.ダメなら仮説を捨てる
地味ですが、これが一番安定しました。
逆に失敗しやすかったのは、以下のような進め方です。
1.出力結果を見て違和感を伝える
2.AIに広めに修正させる
3.なんとなく改善した気がする
4.でも別条件で壊れる
5.追加修正する
6.さらに条件が複雑になる
この流れになると、どんどんコードが重くなります。
そして最後には、
「今どの処理が最終結果に効いているのか分からない」
という状態になります。
AI駆動開発では、ここがかなり危険です。
AIに渡すプロンプトも、設計書の一部になる
AIに投げるプロンプトは、一時的な指示ではなく、開発の設計書に近いものだと感じています。
特に良かったのは、プロンプトに以下を入れることです。
1.現在の症状
プレビューでは期待通りですが、保存後の画像だけ一部の編集条件が反映されていません。
2.やってほしくないこと
保存処理だけを場当たり的に修正しないでください。
プレビュー処理と保存処理で編集条件の扱いが二重管理にならないようにしてください。
3.修正対象
まずは編集条件を受け渡している箇所に絞って確認してください。
関係のないUI変更は行わないでください。
4.成功条件
同じ編集条件でプレビュー生成と保存処理を実行した場合、検証ログ上で同じ条件IDが記録されること。
5.ログ追加
修正後に、どの編集条件で処理されたか分かる診断ログを追加してください。
このように書くと、AIの作業がかなり安定します。
単に「実装してください」ではなく、
何を守りながら、どこを、どの条件で直すのか
まで書くイメージです。
AIに任せる部分と、人間が握る部分を分ける
今回の開発で感じたのは、AIは実装スピードを大きく上げてくれる一方で、全部を任せると危ないということです。
自分の感覚では、役割分担はこんな感じです。
| 役割 | AIに任せやすい | 人間が握ったほうがいい |
|---|---|---|
| コード調査 | 得意 | 最終判断は人間 |
| 小さな修正 | 得意 | 修正範囲の制約は人間 |
| ログ追加 | 得意 | 何を観測すべきかは人間 |
| 原因候補の洗い出し | 得意 | 優先順位付けは人間 |
| アーキテクチャ判断 | 補助はできる | 基本は人間 |
| 品質判断 | 苦手 | 人間が見るべき |
| 知見共有 | たたき台作成は得意 | 現場に合わせた型化は人間 |
画像編集アプリでは、最終的に「利用者にとって自然に使えるか」が重要になります。
これは、ログだけでも、コードだけでも判断しきれません。
業務アプリケーションでも同じで、最終的に「現場で使えるか」「運用で困らないか」は人間が判断する必要があります。
AIにコードを直してもらいながらも、最終的な品質判断は人間が持つべきだと感じました。
「AIで速く作る」より「AIで迷子にならない」ほうが大事
AI駆動開発というと、どうしてもスピードに目が行きます。
たしかに、AIを使うと実装は速いです。
自分ひとりでは時間がかかる調査や修正も、かなり短時間で進みます。
ただ、今回のように複雑なアプリを作っていると、単純なスピードよりも大事なことがありました。
それは、
迷子にならないこと
です。
AIは速く進めてくれます。
でも、進む方向を間違えると、速く迷子になります。
だからこそ、
- 仕様を残す
- ログを残す
- 修正範囲を絞る
- 禁止事項を書く
- 成功条件を決める
- 1回の修正を小さくする
- 変更理由を残す
- レビュー観点を残す
- チームに共有できる形にする
このあたりがかなり重要でした。
AI駆動開発で大事なのは、AIに自由に走らせることではなく、AIが安全に走れるレールを作ることだと思います。
個人開発でも、開発標準はあったほうがいい
今回の開発を通して、個人開発でも最低限の開発標準は必要だと感じました。
たとえば、以下のようなものです。
-変更対象ファイルを明示する
-1回の修正で目的を1つに絞る
-修正前に原因仮説を書く
-修正後に何を確認するか決める
-ログを増やしたら、何のためのログか分かる名前にする
-安全側の処理は最後の保険として扱う
-見た目改善のために、安全側の処理を壊さない
-プロンプトと修正結果をナレッジとして残す
これはチーム開発だけの話ではありません。
むしろ個人開発こそ、AIによって修正量が増えるので、ルールがないと一気に破綻します。
AIが書いたコードを、あとから自分が読めない。
前に直した理由を忘れる。
同じ問題を何度も直す。
修正が積み重なって、消していい処理が分からなくなる。
この状態を避けるためにも、個人開発でも簡単なルールは作っておいたほうがいいです。
そして、このルールはそのままチームのAI駆動開発標準にもつながると思っています。
実際に使いやすかったプロンプトの型
最後に、今回の開発で使いやすかったプロンプトの型を載せておきます。
以下の問題を調査してください。
【現象】
〇〇の条件で△△が発生しています。
【期待する状態】
□□の場合は必ず××になること。
【現在の仮説】
原因はAの処理後にBの処理が上書きしていることだと考えています。
【確認してほしいこと】
1.仮説がコード上正しいか確認する
2.正しければ最小修正する
3.正しくなければ別の原因候補を示す
4.修正後に判断できる診断ログを追加する
【制約】
-対象ファイルは〇〇のみ
-既存の正常ケースを壊さない
-関係ないUI変更は行わない
-安全側の処理を弱めない
【出力してほしいこと】
-変更ファイル
-根本原因
-修正内容
-確認ポイント
-残リスク
この型にしてから、AIとのやり取りがかなり安定しました。
AIに丸投げするのではなく、調査、修正、検証の流れを固定するイメージです。
まとめ
画像編集アプリの開発を通して、AI駆動開発に対する考え方が少し変わりました。
以前は、
AIにコードを書かせること
が中心だと思っていました。
でも今は、
AIが正しく判断できる材料を用意すること
のほうが大事だと感じています。
特に複雑なアプリでは、AIに任せる前に、
- 何が起きているのか
- どこまで直すのか
- 何を壊してはいけないのか
- どうなったら成功なのか
- どのログで判断するのか
- 運用時にどう調査するのか
- チームにどう共有するのか
を整理する必要があります。
AIはかなり強力です。
ただし、観測できないものは直せません。
条件が曖昧なものは、別の形で壊します。
制約がない修正は、あとから負債になります。
だからこそ、AI駆動開発では、
コードを書く力より、観測する力と指示を分解する力が重要
だと思いました。
AIに任せるために、人間が設計する。
AIに速く進んでもらうために、人間がレールを敷く。
AIで開発文化を変えるために、実践した知見を型にして共有する。
この感覚を持てるようになったのが、今回の開発で一番大きな学びでした。