昨今、AIの加速化が続き、多くの話題であふれていますよね。
AIエージェント、copilot、claudecode、codex…などなど、開発体験が明らかに変わってきているのを日々感じます。
ただ、AIの話が多い中でくどいですが、最近開発を通してひしひしと感じていることがあって、今日はそれをまとめます。
ショート動画を流し見する感覚で、ゆるく見ていただければ嬉しいです！
まず自己紹介
2022年にWebエンジニアになる道を決心して、2024年に独学未経験からWebエンジニアとして転職しました。約3年目の26歳です。
普段はLaravelをメインに開発していて、WordPressやMovableType、PowerCMSなどの案件もちょくちょく触っています。
本題：「動く」と「運用できる」は別物だと痛感した
結論から言うと、
AIを駆使すれば“動くもの”は作れる。
でも“運用できるもの”を作るには、結局、人間側の理解と設計が必要になる。
…これが今の自分の実感です。
「AIで誰でもサービスが作れる」みたいな話をよく見かけますし、実際、プロトタイプなら爆速で作れます。
ただ、現場って最終的に「作って終わり」じゃなくて、運用して改善していくのが前提なんですよね。
未経験で炎上した話（自分の黒歴史）
自分は未経験で入社してすぐアサインした案件で、盛大に炎上しました。
当時は（今もですが）「知らないことを知らない」状態の母数が圧倒的に多かったです。
その結果、何が起きたかというと…
- ほとんどがChatGPT頼り（当時は3系が中心）
- その場しのぎのつぎはぎ実装
- 仕上がりは“動くけど品質は最悪”
- 自分で実装したソースなのに理解できてない
という地獄みたいな状況になりました。
最終的にはPLが一から作り直してくださって、問題を収束させてもらいました。
（もしこの記事を見られていたら、この場を借りて改めてお礼を申し上げます。本当にありがとうございました…）
ここで痛感したのは「AIで作る」より「運用できる形にする」難しさ
当時の自分は、
「こういう処理をしたい」→AIに投げる
「返ってきたコードを貼る」→動いたらOK
「次の要件が来る」→またAIに投げる
「返ってきたコードを貼る」→動いたらOK
みたいな感じで、クラス内に処理をどんどん足していってました。
設計も責務も共通化も、ほぼ考えられていない状態です。
一方でPLの実装は、
- 共通化できる箇所の整理
- 責務の分離（どこが何をするべきかが明確）
- “今だけ動けばOK”じゃなくて、運用・保守まで見ている
という、別物でした。
そしてそのシステムは、今も大きな問題が起きていない（起きてもすぐ解決できる）状態で運用されています。
この差って結局、動かすことじゃなくて、
「変更に耐えて、直せて、引き継げる形」になっているかどうかだと思っています。
「運用できるもの」って具体的に何が違うのか
現場で本当に困るのって、だいたいこういうタイミングです。
- 追加機能が入る
- 仕様変更が入る
- 想定外の入力や例外ケースが出る
- 不具合が起きる
- 担当が変わる（引き継ぎが発生する）
このときに、
- どこを直せばいいか分かる
- 修正の影響範囲を読める
- テストや確認観点が立つ
- ログや例外設計がされていて原因追跡できる
こういう状態だと、運用コストが一気に下がります。
逆に、AIで作った“動くけど理解できてないコード”が混ざっていると、
改修のたびに地雷踏みになりがちで、結局、開発速度どころか運用が詰みます。
AIに「品質を意識した実装」をさせても限界がある理由
自分の中で大きいのはここで、
AIに品質を意識して実装させたとしても、その実装内容を理解できないなら、運用面では品質がないのと同じ
という感覚です。
たとえばAIが、設計的には良いコードを返したとしても、
- なぜこの構造なのか
- どこが壊れやすいのか
- どうテストすべきか
- どの変更が危険なのか
- どの責務がどこにあるのか
これが分からないと、結局その後の改修で破綻します。
“良いコード”を貼っても、運用で死ぬ。炎上した時の自分がまさにこれでした。
バイブコーディングへのスタンス（否定したいわけじゃない）
ここ、誤解されたくないので明確に書くと、
自分はバイブコーディング自体を否定したいわけじゃないです。
むしろ、
- 小さな検証
- 初速のプロトタイプ
- アイデア出し
- UI叩き台
- 一回動くものを作って方向性を掴む
こういう場面では、バイブコーディングは超強いと思ってます。
ただ、記事タイトルの通りで、「動く」と「運用できる」は別の話です。
運用できるものにするには、設計や責務、テスト観点、変更耐性など、結局は人間側の理解が必要になります。
自分が炎上後に変えたこと（成長に効いたやつ）
自分は炎上を経験してから、次の案件では使い方を変えました。
- 要所要所はAIを使う（レビュー用途、設計の壁打ち、比較案出し）
- 実装フローや責務の切り方はまず自分で考える
- コアロジックは基本自分で書く
- AIの提案は「採用する／捨てる」を明確にする
この運用に変えてから、「自分の頭で設計する時間」が増えた分、
結果的に運用・保守の目線が育って、成長速度が上がった実感があります。
AIは“答え”というより、思考の補助輪として使う方が、自分には合っていました。
まとめ：AI時代でも「運用できる形にする力」は消えない
言いたいのはシンプルで、
AIで動くものは作れる。
でも“運用できるもの”にするには、設計と理解が必要。
この一点です。
そしてそれを握れるのは、
経験を積んできた人、スキルや技術を追い続けてきた人だと思っています。
だからこそ、AIが進化しても「作って終わり」じゃない現場では、
品質や運用の目線を持っている人の価値は当分変わらないはずです。
（10年後、20年後はそれすら変わってる可能性はありますが…）
おわりに
もし未経験の頃の自分みたいに、AIに寄りかかって「動くもの」を量産して疲弊している人がいたら、
一回立ち止まって、
- “このコードはなぜこうなってる？”
- “この責務はどこに置くべき？”
- “後から直す時、自分は追える？”
- “運用や改修の時に詰まない？”
みたいな視点を持つだけでも、かなり変わると思います。
自分もまだまだ修行中なので、引き続き頑張ります。