7月24日、Ihor Riazantsevが「AI-Assisted Development Under Deadline: What It Takes to Ship Production Code on an Unfamiliar Stack」と題した記事を公開した。未経験のスタックで2週間という納期制約の中、Claude Codeを活用してプロダクション品質のコードを届けた実践経験について詳しく報告している。

App Store削除から2週間でWeb移植——現場で何が起きたか

Photify AIがApp Storeから削除された。残された時間は約2週間。AIによる写真・動画生成機能を、別プロダクトのBotify AI（Web版）に移植しなければならない。

問題は期間だけではなかった。Botify AIのスタックはReact、TypeScript、Next.js——筆者のIhor Riazantsevが一度も触ったことのない技術だった。スタックを一から学ぶ余裕はなく、それでもプロダクション品質で届ける必要がある。このリアルな制約の中で、Claude Codeがどう機能し、どこで限界を見せたか——それがこの記事の核心だ。

AIが本当に効いた場面：コード理解の加速

Riazantsevが最初に直面したのは「書く」問題ではなく「読む」問題だった。新機能を実装する前に、既存コードベースの構造を把握しなければならない。コンポーネント間の依存関係を手動でトレースしていれば、それだけで2週間が溶けていた。

ここでClaude Codeが最も価値を発揮した。未知のコードセクションの説明、機能の実装箇所の特定、依存関係のコンテキスト提供——これらを人間が行う何倍ものスピードでこなした。「探索から実装への移行」を大幅に前倒しにできたと筆者は述べている。

実装フェーズでも同様で、初期実装の生成、既存パターンに沿ったコードの提案、デバッグ時のエラー分析と修正候補の生成、といった作業を加速した。ゼロから書き始める代わりに、動く土台から洗練・調整へ入れる——この差は2週間という制約下では大きかった。

AIが生み出したリスク：「動くコード」≠「プロダクションコード」

この記事で最も読む価値があるのはここだ。

一貫性の崩壊（Consistency Drift）

AIは「目の前の問題を解く」ことに最適化されており、コードベース全体の整合性は考慮しない。結果として起きたのが一貫性ドリフトだ——既存の共有定数やヘルパー関数が存在するにもかかわらず、AIはそれを無視して値をハードコードしたり、重複するユーティリティを新たに生成したりした。

筆者は、AIが生成したコードで共有ヘルパーを使わず重複ロジックが書かれているケースを複数確認し、レビュー後に既存ヘルパーを再利用する形へ修正したと報告している。個々の差分は小さく見えるが、積み重なると「真実の情報源が複数存在する」状態になり、メンテナンスコストが上昇する。

影響範囲の拡大（Blast Radius）

コードベース全体にアクセスできるAIは、1機能だけの変更が必要な場面で共有コンポーネントを「改善」しようとすることがある。これが意図せず無関係な箇所に影響を与えるリスクがある。

対策として筆者はフィーチャー専用ディレクトリを作り、新機能のロジックをそこに閉じ込めた。共有サービスへの変更は最小限に抑え、1行ずつレビューした。

CIもテストスイートもない状態での品質担保

このプロジェクトにはCI/CDパイプラインも自動テストスイートも本番モニタリングも存在しなかった。品質担保は徹底した手動テストとレビューに依存した。

その過程で最も深刻な問題が発覚した。大量のメディアギャラリーを高速スクロールすると、デバイスが熱を持ちアプリがラグし始めた。調査の結果、ビューポート外に出たメディアアイテムがメモリから解放されておらず、スクロール中に何百ものオブジェクトが蓄積していることが判明した。

この問題はAIの静的解析やコードレビューでは一切検出されなかった。リアルな使用条件下での手動テストによってのみ可視化された。

問題の根本原因を特定した後、Claude Codeに正確な問題説明を与えると数秒で修正コードを生成した。しかし解決には続きがあった。オフスクリーンアイテムを正しく解放すると、スクロールバックのたびに再読み込みが発生し、不要な遅延が生じた。最終的な実装は「メモリ解放」「プリロード」「バックエンドのキャッシュヘッダー適切化」を組み合わせたものになった。

問題を発見したのも、解決策を判断したのも、リリース可否を決めたのも人間だった。AIは「何を直すか」が特定されてから動いた。

まとめ：ボトルネックはコード生成ではなくなった

筆者がこの経験から引き出した結論はシンプルだ。AIはコード生成を加速したが、エンジニアリング判断を代替しなかった。 アーキテクチャ上の意思決定、本番環境での検証、リスク評価、リリース判断——これらはすべてエンジニアの責務のままだった。実際、2週間という期間内で移植を完遂できたのは、AIによるコード生成の加速だけでなく、一貫性ドリフトやBlast Radiusといったリスクをエンジニア自身が早期に認識し、対処できたことが大きいと筆者は強調している。

AIが日常的な開発ツールになるにつれ、エンジニアの役割は「コードを書く」から「AIの生成物を評価し、統合し、方向づける」へとシフトしていく。そのシフトにおいて最大の課題は「コードを書けるか」ではなく、「生成されたコードが既存アーキテクチャに適切か、本番環境で信頼できるか」を判断できるかだ。

詳細はAI-Assisted Development Under Deadline: What It Takes to Ship Production Code on an Unfamiliar Stackを参照していただきたい。