【ITニュース解説】The Job Pilot Chronicles: 94 Commits, 27 Days, and the Brutal Reality of AI-Assisted Development

システムエンジニアを目指す初心者が、最新のAIツールを活用したソフトウェア開発の現実を知ることは非常に重要である。ある開発者が27日間で94回のコミットを重ねてフルスタックアプリケーション「Job Pilot」を構築した経験は、AI支援開発の光と影を浮き彫りにしている。この開発者の旅は、AIがもたらす生産性向上の期待と、実際に直面する厳しい課題を具体的に示している。

開発は、日付のコミットから始まった。「firts commit」というタイポを含む最初のコミットは、AIがコード全体を生成できる現代においても、人間のミスがなくなるわけではないことを象徴している。AIツールは開発を高速化し、賢くしてくれると期待される一方で、開発者は依然として深夜に自分の間違いをデバッグし、生産性が上がっているのか、それともただ混乱しているだけなのかを問い続ける矛盾を抱えている。

開発者が示した数字、たとえば27日間で94回のコミット、単独開発、特定のキーワードの頻度などは、表面的な活動量を示す。しかし、これらの数字が語らないのは、AIが生成した「完璧に見える」コードがコンパイルできなかったり、巧妙に間違っていたりして、AIと「議論」したり、そのコードを修正したりするのに費やされた時間である。

AIコーディングツールの普及は目覚ましく、最近の調査では84%もの開発者が利用している。しかし、驚くべきことに、経験豊富な開発者がAIツールを使うと、かえってタスク完了に19%長く時間がかかるという結果が出ている。これは、AIツールの利用で24%のスピードアップを期待していた現実とはかけ離れている。その主な原因は、AIが提供する解決策が「ほぼ正しいが、完全ではない」ことが45%もの割合である点だ。中途半端に正しいコードをデバッグすることは、ゼロから自分でコードを書くよりも苦痛だと感じる場合が多い。

開発の初期段階では、AIツールはボイラープレートコード（定型的な繰り返しコード）の生成には非常に有効だった。筆者はアプリケーションの構造を再構築し、適切な責務の分離を行う中で、AIが提供するAPIエンドポイントの生成能力に目を見張った。認証・認可、求人情報、ユーザープロファイルなど、多数のAPIを短期間で構築できたことは、AIの強力な支援を強く感じさせるものだった。しかし、AIツールはプロジェクト全体のアーキテクチャ（構造設計）に関する意見は持たなかった。

開発が進み、各APIコンポーネントを連結しようとしたとき、AI支援開発の最初の厳しい教訓に直面した。AIは個々のコンポーネントを完璧に記述する能力がある一方で、それらを連携させることには非常に不向きなのである。GitHub Copilotが生成する完璧に見えるAPIルートや、Claudeが生成するテストスイートは優れていたが、それらは認証ミドルウェアがデータベースモデルとどのように連携すべきか、あるいは求人の重複排除ロジックがなぜ無限ループを引き起こすのかといった、システム全体の複雑な相互作用を理解できなかった。開発者は、異なるAIの提案間の「翻訳者」となり、AIが生成したコードの統合に関するバグを修正するのに、自分で最初から書くよりも多くの時間を費やすことになった。これは、AIツールが大規模なコードベースのコンテキスト（文脈）や、既存のパターン、アーキテクチャ上の決定、モジュール間の微妙な依存関係を理解できないという90%の開発者の報告と一致する。

フロントエンドの開発では、さらに苦戦した。AIが個別に生成したReactコンポーネントは、いざ組み立てると「フランケンシュタインの怪物」のようになり、期待通りに機能しなかった。何度も最初からやり直すことになり、時にはAIが意図しない大量のコードを生成してしまったり、人間による検証がないままコードが完成したように見えたりした。これは、AIツールが簡単な部分では優れているが、実際のアプリケーションが動作する統合レイヤーで苦戦するという現実を示している。

こうした困難の中で、開発者は「テスト」の重要性を痛感した。AIが生成したコードが本当に機能するかを検証する唯一の方法がテストだった。テストはAIの「現実チェック」の役割を果たした。AIが「本番環境対応」だと自信を持って主張する認証フローにはセキュリティ上の欠陥があり、優雅に見えるデータベースクエリは、テストによって負荷がかかると破損することが明らかになった。AIを使ってコードを生成し、人間がそれを検証し、テストで真実を確認するというパターンこそが、AI支援開発を成功させる鍵となる。

8月中の激しい開発マラソンで燃え尽きた後、開発者はプロジェクトを放棄せず、経験豊富な開発者と初心者を分ける重要な行動に出た。それは「戦略的なリセット」である。現在の方法がうまくいっていないことを認め、より良い知識を持って最初からやり直すことは、失敗ではなく、賢明な進歩の一形態だった。このリセットにより、不要なコードを削除し、より測定されたアプローチでフロントエンドの開発を再開することができた。

これらの経験から、AIを活用した2025年の開発について、いくつかの重要な教訓が得られた。 第一に、AIは強力な「インターン」ではあるが、「シニア開発者」ではない。ボイラープレート生成や独立した機能の作成、テストケースの生成には優れているが、既存のコードベースの文脈理解、アーキテクチャ設計、統合問題のデバッグ、そしてコード生成を止めるべきタイミングの判断は苦手である。 第二に、「ほぼ正しい」問題は非常に深刻だ。AIが生成したコードが45%の割合で「ほぼ正しいが、完全ではない」ことは、壊滅的な影響をもたらす。一見正しく見えるコードが本番環境で失敗すると、ゼロから正しいコードを書くよりも、微妙なAIの誤りをデバッグするのに多くの時間を費やすことになる。 第三に、テストは必須となる。AI支援開発では、包括的なテストは選択肢ではなく、生成されたコードが実際に機能するかを検証する唯一の方法である。 第四に、人間は統合とアーキテクチャの設計に優れている。AIはコンポーネントを生成するが、システムを統合するのは人間である。AI支援開発における真のスキルは、AIに完璧なコードを書かせることではなく、AIが生成した断片を、首尾一貫した、保守可能なシステムに結合する方法を知ることだ。 第五に、リセットは機能であり、バグではない。従来の開発では「書き換えは避けるべき」とされたが、AI支援開発では、より良いプロンプトと明確なアーキテクチャを持って最初からやり直す方が、AIが生成した乱雑なコードをデバッグするよりも早い場合がある。

AIコーディングツールは、複雑で洗練されたコードを瞬時に生成できる点で「最高」だが、同時に、誤った進捗感覚を生み出し、理解不能な問題のデバッグに時間を費やすことになる点で「最悪」な側面も持つ。これは開発者が直面するパラドックスである。

システムエンジニアを目指す初心者がAIツールを利用する上で、この経験から得られる具体的なアドバイスがある。まず、コードを書く前にアーキテクチャを計画し、AIに技術的な決定を任せきりにしないこと。次に、人間（検証）、AI（生成）、テスト（検証）という三位一体のワークフローを受け入れること。これにより、「ほぼ正しい」問題に対する安全策となる。また、AIがコンポーネントを生成するのにかかる時間は短いが、それらを統合するには人間による時間が必要であることを考慮し、予算に含めること。AIが生成したものはすべてテストし、AIコードを修正した場合も再度テストすること。そして、もしAIが生成したコードがひどく絡み合ってしまった場合は、より良いプロンプトで最初からやり直す方が早い場合もあると知ることだ。

現在も開発中の「Job Pilot」は、AI支援開発の現実を示す生きた例である。完璧なアプリケーションではないかもしれないが、人間とAIの協業という、混乱を伴う反復的なプロセスを経て構築された、より良いアプリケーションである。この物語は、AIが開発者を置き換えるのではなく、強力だが根本的に限界のあるツールとの協業を学ぶことの重要性を教えてくれる。私たちはもはやコードを書くだけではなく、強力だが限界のあるツールとの協業という新しい開発プロセスを経験しているのだ。最終的に、すべてのピースが調和し、テストがパスし、ユーザーがバグに遭遇することなくアプリケーションを利用できたとき、ソフトウェアを構築することに最初に情熱を抱いた理由を思い出すだろう。たとえ最初のコミットにタイプミスがあったとしても。