AIコーディングツールで開発したアプリが、ある日突然クラッシュした。
ログもない。
再現手順もわからない。
原因の特定に3日かかった。
こんな経験をしたことはありませんか？
Redditのあるスレッドで、AIを使ったiOSアプリ開発のベストプラクティスが投稿されました。
そして、大きな反響を呼んだのです。
投稿には400以上の賛同が集まりました。
コメント欄にも、ベテラン開発者たちの知見が次々と寄せられています。
本記事では、そのスレッドの内容を参考にしながら、AI支援開発で品質を守るためのポイントを整理していきます。
「コンパイル通ったからOK」の罠
AIコーディングツールの速さは驚異的です。
機能の実装からデバッグまで、人間の何倍ものスピードでこなしてくれます。
でも、そこに落とし穴がある。
コードが動く。
テストも通る。
じゃあリリースしよう。
この流れが自然に加速してしまうのです。
元の投稿者は、サイバーセキュリティのバックグラウンドを持つ開発者です。
そして、この点を強く警告していました。
AIはあなたが頼んだものを返してくれる。
でも、頼まなかったことには手をつけない。
エラーハンドリングを指示しなければ、ハッピーパスだけの実装が返ってきます。
環境分離を意識しなければ、開発用と本番用のトークンが同じまま放置される。
つまり、速さの恩恵を受ける裏側で、技術的負債が静かに積み上がっていくわけです。
シニアエンジニアはあなた自身
このスレッドで最も支持された考え方があります。
AIは、今まで見た中で最速のジュニア開発者だ。 でもジュニアはジュニア。 アーキテクチャの判断やセキュリティの設計は、シニアエンジニアであるあなたが担う。
この比喩は多くの開発者の共感を集めました。
AIは各言語やフレームワークの範囲内では優秀なコードを書ける。
ところが、異なる言語の境界をまたぐバグが起きた瞬間、途端に文脈を失います。
あるコメント投稿者は、Swift・Rust・Flutterを1つのリポジトリで扱うmacOSアプリを開発しているそうです。
各言語のコードは問題なく書ける。
しかし、SwiftとRustのFFI境界でクラッシュが起きると、AIにはまったく手が出せなかったと報告していました。
こうした境界を超えた問題は、全体像を把握している人間にしか解決できません。
可観測性は初日から入れる
「可観測性（Observability）を後回しにするな」という主張も、スレッド全体で繰り返し強調されていました。
あるコメント投稿者の体験が印象的です。
サイドプロジェクトをリリースした後、App Storeに「起動時にクラッシュする」という1つ星レビューがついた。
しかし、ログがなかったため原因の特定に3日かかったそうです。
この体験が示していることは明快でしょう。
クラッシュレポートの導入は、最初のユーザーが怒りのレビューを書いた後では遅い。
開発の初日に済ませておくべきです。
加えて、ターミナルに流れるだけのログでは不十分です。
永続化された実用的なログを用意する必要があります。
ヘルスチェック用のエンドポイントも地味に役立ちます。
サービスが生きているかどうかを、トップページにアクセスして祈る代わりに、明確に確認できるからです。
過剰設計という見えない敵
20年以上の開発経験を持つベテランエンジニアが、スレッドに重要な視点を加えていました。
AIに「完璧な設計」を求めると、どうなるか。
ToDoアプリなのにマイクロサービスアーキテクチャを提案してくるような事態が起きる、というのです。
複雑さはプロジェクトを静かに殺す、とその人は言います。
次のリファクタリングは10倍難しくなる。
テストの量も爆発的に膨れ上がる。
そして、バグの温床が広がっていく。
アバター用にminioストレージは要らない。
重要でないメッセージのために非同期キューを導入する必要もない。
すべてのエッジケースに「対応」しなくても、「適切に処理」できれば十分です。
この開発者が紹介していた比喩が印象的でした。
ソフトウェア開発は旅客機ではなく、戦闘機を作るようなものだ、と。
旅客機のような快適さや冗長性は必要ない。
ミッションを完遂して、無事に帰還できればいいのです。
セキュリティとデプロイの基本を怠らない
AI支援開発だからといって、ソフトウェアの基本原則が変わるわけではありません。
元の投稿者は、以下のような実践を習慣にしていると述べていました。
まず、シークレット管理について。
ハードコードやgitへのコミットは避ける。
そして、開発・ステージング・本番で別々のトークンを使い分ける。
サーバーサイドのバリデーションも必須です。
AIが生成したコードはハッピーパスに偏りがちで、悪意のある入力に対して無防備になりやすい。
だからこそ、入力検証を意識的に組み込む必要があります。
外部APIを呼ぶ場合はサービスレイヤーでラップする。
こうしておくと、将来プロバイダーを切り替えたり、キャッシュを追加したりするときに効いてきます。
認証やデータ書き込みへのレート制限も、攻撃を受けてからでは遅い。
ステージング環境は「本番っぽいもの」ではなく、本番のミラーとして構築すべきです。
CORSをワイルドカードに設定するのは、エラーが消えた瞬間は気持ちいいかもしれません。
でも、やめたほうがいい。
CI/CDは後回しにしない
「ローカルで動いたから大丈夫」は、デプロイ戦略ではありません。
CI/CD（継続的インテグレーション・継続的デリバリー）の仕組みは、早い段階で導入すべきです。
大げさなパイプラインは不要でしょう。
テストの自動実行と、パイプラインからのデプロイが最低限整っていれば十分です。
自分のノートPCから直接デプロイする運用は、事故のもとになります。
プロジェクトの構築・実行・デプロイ手順もドキュメント化しておきましょう。
複数プロジェクトを切り替えていると、1週間前の自分のセットアップ手順すら驚くほど簡単に忘れてしまうものです。
CLAUDE.mdをプロジェクトの「契約書」にする
スレッドで特に注目された実践テクニックが、CLAUDE.mdファイルの活用です。
Claude Codeには、プロジェクトルートに置いたCLAUDE.mdを自動的に読み込む機能があります。
このファイルに開発規約やアーキテクチャパターン、セキュリティルールを記述しておく。
すると、セッションをまたいでもAIが一貫した基準でコードを提案してくれるようになります。
あるコメント投稿者は、このファイルを「READMEではなく、契約書として扱うべきだ」と表現していました。
READMEは参考資料にすぎない。
しかし、契約書は遵守すべき規範だからです。
一方で、ファイルの肥大化を懸念する声もありました。
150行を超えるとコンテキストに悪影響が出るという報告もあります。
そのため、古い内容は履歴ファイルに移すなど、簡潔に保つ工夫が必要です。
なお、AIにCLAUDE.md自体の改善を依頼するのも有効なアプローチでしょう。
自分が弱いルール領域をAIに補強してもらえるため、ベストプラクティスの網羅性が高まります。
タイムゾーンと「後でやる」の危険性
地味だが重要なポイントとして、時刻の扱いも挙げられていました。
保存はUTC、表示時にローカルタイムへ変換する。
これが鉄則です。
UTCとローカルタイムとJavaScriptのデフォルトが混在したデバッグ地獄は、経験した人なら二度と繰り返したくないでしょう。
もう一つ。
「後で直す」という自分への約束は、ほぼ間違いなく守られません。
ハック的なコードを見つけたら、その場で修正するか、期限付きのチケットを切る。
コメントアウトで機能のON/OFFを切り替えている状態を「フィーチャーフラグ」と呼んでいるなら、それはシステムではなく願望です。
まとめ
AI支援開発のスピードは魅力的です。
これまで何日もかかっていた実装が、数時間で形になる。
その体験は衝撃的でしょう。
しかし、速さが技術的負債を見えにくくしているのも事実です。
コードが動くことと、コードが正しいことは違います。
このスレッドから浮かび上がるメッセージは明快でした。
AIに任せる部分と、人間が判断すべき部分を意識的に線引きすること。
可観測性やセキュリティ、テストといった基本を、速さを理由に省かないこと。
そして、CLAUDE.mdのようなツールを使って、AIとの協業ルールをプロジェクトの最初から定義しておくこと。
基本を守る開発者が、最終的には速く進める。
この原則はAI時代になっても変わりません。
