3
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI 開発の『爆速神話』に騙されるな

Last updated at Posted at 2025-10-14

はじめに

「AI を使えば数時間で Web アプリが作れる」
そんな謳い文句を目にして、AI 駆動開発に挑戦してみました。
結果として 2 つの Web アプリケーションを開発し、GitHub で公開することができました。

しかし、開発には 80 時間以上かかっています。
当初の予想よりも 10 倍近くの時間がかかっています。現実は甘くありません。(T_T)

80 時間の開発を通じて得た学びと、AI 開発との向き合い方をお話しします。
AI 開発の「爆速神話」の現実をお伝えします。

知識の無さから効率の悪い開発を進めていたことも自負しています。
温かい目で見てください。

利用したツール

  • Kiro
  • Amazon Q Developer CLI

開発した OSS

Marp Web Editor

Markdown でプレゼンテーション作成する Web エディタです。
(Next.js + React + TypeScript + Tailwind CSS、AI 支援機能搭載)

リアルタイムプレビュー、テンプレート機能、カスタムテーマ対応を実装。
AI 支援機能や共有機能も搭載しています。
HTML/PDF/PPTX でのエクスポートにも対応。

Q Dev Config

Amazon Q Developer CLI 設定ファイルを GUI で作成する Web アプリです。 ( Live Demo )

3 つの設定ファイル(General/Agent/MCP)に対応し、リアルタイムプレビューで確認しながら設定できます。

実際にかかった開発時間

前提

私はエンジニア経験があり、生成 AI 普及前に他言語での社内アプリ開発の経験もあります。
Next.js/React/TypeScript は未経験です。
「フロントエンド知識不足」であって「プログラミング初心者」ではありません。

Marp Web Editor:70 時間

「Markdown でプレゼンテーションを作る Web エディタ」という比較的シンプルなアプリケーションを想定していました。
AI エージェントに任せれば、数時間で完成するだろうと思って。

時間配分(体感)

  • 要件定義・設計:40%
  • 実装・修正:残り 20%
  • デバッグ:40%

実装よりも要件定義・設計・デバッグに時間がかかっています。
AI エージェントとの対話、調査依頼、仕様の検討と修正を繰り返すうちに、気がつけば膨大な時間が経過していました。
テストコードは利用していないため、デバッグも実際に動作してみてフィードバックを出しての繰り返しです。

使用ツール

  • 初期:Kiro
  • 後期:Amazon Q Developer CLI

Q Dev Config:12 時間

2 つ目のプロジェクトでは、開発時間が大幅に改善されました。
コード行数やファイル数が大きく異なるため、純粋な比較はできないですが、明らかに効率は向上しています。

使用ツール

  • Amazon Q Developer CLI

改善できた要因

  • 技術選定コストの削減(Zod, Zustand, TailwindCSS, shadcn/ui 等の知識蓄積)
  • コンパイルチェック・ESLint を初期から組み込み
  • ドキュメントの適宜更新
  • 短期サイクル開発

なぜこんなに時間がかかったのか?

なぜ予想よりも大幅に時間がかかったのか、振り返ってみると 3 つの理由が見えてきました。

理由 1:知らない技術で判断できない

一番困ったところです。
知らない技術領域での AI 提案を適切に判断できていませんでした。

具体例:Next.js/React での判断困難

  • use clientの使い方・必要性
  • useMemoの適用場面
  • コンポーネント分割の方針
  • Anyで実装されたものの対処方法

他にもまだまだありましたが、全く分からないところは、AI からの提案を受け入れるしかない状況が頻発。
実装された内容も正しいのか判断が付かず。
後から「思った通りに動かないな」となり大きな修正が必要に、結果として開発時間が膨れ上がることに。

  • ちょっと知ってる領域:ある程度読んで妥当性を評価する
  • 全く知らない領域:文章がもっともらしいだけで承認する

AI の提案は良さそうに見えるので、油断すると受け入れちゃいます。
知らない領域は都度の学習も面倒になり、「その提案で進めましょう。」と。
技術的に正しいかどうかと、説明が上手かどうかは全然別の話なのに。

理由 2:設計がコロコロ変わる

Kiro を使った開発では、以下の流れで進めていました。

  1. steering 作成
  2. 各実装ごとの specs 作成
  3. タスク実行
  4. 問題発生時「新規 specs の作成 → 実装物の修正 → steering の更新」

技術的な制約で設計変更が必要になった箇所が多く、事前調査の甘さが浮き彫りに。
二度、全体的に作り直しました。

問題に気づくのは、すべての実装が完了して動作確認時となってしまっていたことが特に問題。
設計時点では良さそうだが、実際に動かしてみると「なんか違う...」となり、そのたびに要件や設計を見直す羽目に。

ドキュメント管理を初期の作りっぱなしのままで、問題発生時に更新の流れです。
実装内容や仕組みをこまめに更新しないと、AI が効率的に動いてくれないんですね。

理由 3:AI との対話に時間がかかる

ここは私の知識不足が大きな要因ですが、無駄な対話が多く発生していました。

思い通りに動作しない場合や、不具合が発生した場合に噛み合わない対話が続きます。
伝え方が悪いのもありますが、AI は目の前のエラー解決を優先して、全体のバランスは考えてくれません。
修正を繰り返すうちにコードがぐちゃぐちゃになり、無理やりエラーを回避する実装も発生。
テストコードを書かせても、テストを通すためだけの修正を繰り返し徒労に終わりました。

コンパイルチェック(npx tsc --noEmit)と ESLint(npm run lint)の重要性を後から知ることに。
こまめにチェックすればそこまで的はずれな修正は行われなかったです。

得られるものは多い

この経験を踏まえて、さらに AI 駆動開発を続けています。

学習曲線の効果が高い

2 つ目のプロジェクトでは、作業時間が劇的に改善できていました。
大きな要因としては以下の通りです。

コンパイルチェックと ESLint の組み込み

実際に動作テストするまで問題に気づかないことがロスの大きな要因だったので、都度チェックを行うように。
本当の不具合は実行前に検知できるようになり、問題の蓄積も最小限で済みました。

技術選定コストの削減

Zod、Zustand、TailwindCSS、shadcn/ui といった必須ライブラリの知識が蓄積。
選定時の効率化が進みました。

短期サイクルでエージェントを回す

指示 → 設計 → 実装 → 確認を 10 分未満で回して、ロングランは極力避けるようにしました。
実稼働時間は多いですが、品質が向上して完成までの期間は大幅に短縮できました。(本当はロングランさせたい)

ドキュメントの適宜更新

重要情報を常時更新して、AI エージェントが効率的に情報を得られる状態を維持する。
誤った方向性の作業をされるとロスが大きすぎます。

従来開発では得られない速さ

時間がかかったとはいえ、未経験のフレームワークや言語で 70 時間は爆速です。
未経験の技術スタックでも実用アプリが作れる。
これは学習コストを大幅に削減できているとは思います。

これから始める方へ

私の経験から、これから始める方に伝えたいことをまとめました。

長期的な投資として実践する

AI 開発スキルは、長期的な投資として非常に価値があると思っています。

2 つ目、3 つ目...と開発を進めることでさらなる効率化が期待できます。
実践することで AI 開発手法の継続的な最適化を進められます。

AI が発達しても、技術的な判断力の重要性は変わりません。
むしろ、AI の提案を適切に評価するために、より深い理解が必要になる場面もあります。

AI 開発は一度覚えれば終わりではありません。
ツールの進化、手法の改善、新しいやり方への適応など、継続的な学習が必要です。

現実的な開発計画

最初のプロジェクトは予想時間の 3-5 倍を見込んでおいた方がいいです。
私の場合は 10 倍でしたが、これは極端な例かもしれません。
それでも、少なくとも 3-5 倍は見込んでおくのがいいと思います。

長時間実装は避けて、短期サイクルで進めることをお勧めします。
問題の早期発見と修正コストの削減につながります。

成功するための心構え

爆速開発は、2 つ目以降のプロジェクトからでした。
最初のプロジェクトで爆速を期待するのは現実的ではありません。
学習投資として捉えて、2 つ目以降での効率化を目指すのがいいと思います。

陥りがちな罠とその回避法

AI の提案を鵜呑みにしてしまい、後から大きな修正が必要になりました。
特に知らない技術領域では、安易に承認せず、調査や学習に時間を投資することが重要です。

また、デバッグも大変です。
効率的な確認方法を事前に学習しておくべきです。

AI が効率的に動作するためには、整理された情報が必要です。
実装内容や重要な決定事項は、こまめにドキュメント化が必要です。

まとめ

AI 開発の「爆速神話」は、誇張されているような実感です。
私の経験では、予想の 10 倍の時間がかかりました。
それでも、従来の手法よりは圧倒的に早いですが。

また、過度な期待は禁物ですが、学習効果は確実にあります。
長期的な視点での投資価値は高いと考えています。
最初は時間がかかっても、継続することで確実にスキルは向上します。

どんどん挑んでいきましょう。
価値ある体験が得られるはずです!

3
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?