メニュー

公開日:
8 min read
技術革新

AI時代の開発における2つのアプローチ(第1部)— ネット観察から見えてきた興味深い現象

AI時代の開発における2つのアプローチ(第1部)— ネット観察から見えてきた興味深い現象のイメージ

よくある質問 (FAQ)

AI全委任による開発手法とはどのようなものですか?

数千行に及ぶプロンプトを1行ずつAIに実行させ、1日かけてウェブサイトを完成させる手法です。「判断は全てAIに任せている」のが特徴で、生成されたコードは見た目は整っており、インデントやフォーマット、命名規則の一貫性など表面的な品質は申し分ありません。

コードレビューの「深度」とは何を指しますか?

表面的なレビューではフォーマットや基本的な構造だけが見えますが、実際の品質評価には、ビジネスロジックの妥当性、エラーハンドリングの適切性、セキュリティホールの有無、パフォーマンスボトルネック、保守性・拡張性といった深いレビューが必要です。

AIが生成するコードの問題点は何ですか?

AIが生成するコードには「見た目の美しさ」がありますが、ビジネス要件との整合性は保証されず、複雑な条件分岐で論理エラーが混入しやすく、セキュリティ考慮が不十分な場合が多く、例外処理が甘い傾向にあります。この問題構造はオフショア開発の課題と非常に似ています。

プロデューサーとエンジニアの視点の違いは何ですか?

プロデューサーは見た目の完成度、開発速度、マーケティング効果を重視します。一方、エンジニアは保守性・拡張性、技術的負債、運用安定性を優先します。プロデューサーの手法は「プロトタイプ製造マシン」としては優秀でも、実運用に耐える品質は期待できません。

AI活用による「仮説検証の民主化」とは何ですか?

ビジネスアイデア→即プロトタイプ→即リリース→即検証のサイクルを個人で回せるようになったことです。従来は外注見積もりから開発期間3ヶ月、コスト数百万円かかっていたものが、AI活用後はアイデアから即日プロトタイプ、翌日リリース、コストほぼゼロで実現できます。

筆者のAI拡張型開発アプローチの特徴は何ですか?

人間が主導権を保持し、AIは「知識豊富だが経験不足の中級エンジニア」として扱います。動作実績のあるコードを最優先し、品質と保守性を重視します。「数撃ちゃ当たる」式ではなく、「じっくりと分析して戦略を立てて、成功の道筋が見えてから本格運用を前提にプロトタイプを作る」アプローチです。

2つのアプローチとは何を指しますか?

1. 高速プロトタイピングアプローチ:仮説検証とアイデアの民主化を目的とする、2. 信頼性重視アプローチ:企業インフラと長期運用の品質保証を目的とする。これは「どちらが正しいか」の問題ではなく、それぞれに価値がある異なるアプローチです。

ネット上で興味深い投稿があり、時間があるときにウォッチしている。

最近、SNSで生成AI開発に関する報告を目にすることが増えた。 特に印象的なのは、AI全委任による開発手法を実践している方々の一連の投稿だ。

「本日よりデバッグとビルドとデプロイは超自動化された」 「あらゆるユーザーシナリオをペルソナ作ってめっちゃテストしてから修正されるようになった」 「Claude Codeで開発してるシステムの自慢」

長年システム開発をしてきた私には、新鮮でありながら、同時に考えさせられる内容だった。

AI全委任による開発手法

その投稿者の手法は非常にユニークだった。 数千行に及ぶプロンプトを1行ずつAIに実行させ、1日かけてウェブサイトを完成させ、「判断は全てAIに任せている」という。

さらに興味深いのは、生成されたコードを20年のプログラマー経験を持つ知人に見せたところ「プログラムはきれいだ」と評価されたと喜んでいる点だ。 確かにAIが生成するコードは、見た目は整っている。 インデントやフォーマット、命名規則の一貫性など、表面的な品質は申し分ない。

エンジニア視点からの疑問

しかし、長年の開発経験を持つ私には、いくつかの疑問が浮かんだ。

コードレビューには「深度」がある。 表面的なレビューで見えるのは、フォーマットや基本的な構造だけだ。 実際の品質評価には、ビジネスロジックの妥当性、エラーハンドリングの適切性、セキュリティホールの有無、パフォーマンスボトルネック、保守性・拡張性といった深いレビューが必要になる。

「きれいだ」という評価は、おそらく10-20分程度の表面的な確認での印象だろう。 知人の方も仕事でない限り、数千行のコードを本気で追うことはしないはずだ。

AIが生成するコードには、確かに「見た目の美しさ」がある。 しかし、ビジネス要件との整合性は保証されず、複雑な条件分岐で論理エラーが混入しやすく、セキュリティ考慮が不十分な場合が多く、例外処理が甘い傾向にある。

興味深いことに、この問題構造はオフショア開発の課題と非常に似ている。 技術的には優秀でも、実務上の判断力や設計思想、保守性への意識が育っていないという点で共通している。

プロデューサーとエンジニアの視点の違い

さらに調べてみると、この投稿者は技術的バックグラウンドを持つ「プロデューサー」だった。 過去に映像ソフトウェアやウェブ制作ツールなどの開発をプロデュースした実績があり、メディア業界での経験も豊富な方だった。

ここで重要な違いが見えてきた。 プロデューサーは見た目の完成度、開発速度、マーケティング効果を重視する。 一方、エンジニアは保守性・拡張性、技術的負債、運用安定性を優先する。

プロデューサーの手法は「プロトタイプ製造マシン」としては優秀でも、実運用に耐える品質は期待できない。 しかし、これは「間違い」ではなく、「目的の違い」なのかもしれない。

新たな可能性の発見

一方で、この投稿者のアプローチには確実に価値がある。

ビジネスアイデア→即プロトタイプ→即リリース→即検証

このサイクルを個人で回せるのは革命的だ:

  • 従来:アイデア→外注見積もり→開発期間3ヶ月→コスト数百万円
  • AI活用後:アイデア→即日プロトタイプ→翌日リリース→コストほぼゼロ

「仮説検証の民主化」が起きている。 資金力のない個人でも、多数のアイデアを低コストで試せる時代になった。

昔だって「デモ版」はあった。 AI時代の高速プロトタイピングは、従来の「デモ版」「PoC(Proof of Concept)」の進化版であり、全く新しい概念ではない。 しかし、そのアクセシビリティと速度は確実に革命的だ。

私自身のAI拡張型開発との違い

私も現在、Claude CodeやGitHub Copilotなど、AI拡張型開発を実践している。 この点は異なるかもしれない。 私のアプローチは:

  • 人間が主導権を保持
  • AIは「知識豊富だが経験不足の中級エンジニア」として扱う
  • 動作実績のあるコードを最優先
  • 品質と保守性を重視

先日、ReactとAnt Designを使用したシステムの修正で、従来方式なら9日かかる作業を0.5日(4時間)で完了した。 速度は18倍だったが、重要なのは:

  • バグゼロでの納品
  • 完全なドキュメント付き
  • 将来の保守が容易な設計
  • 私自身、疲労なく次の仕事へ

これは「数撃ちゃ当たる」式ではなく、「じっくりと分析して戦略を立てて、成功の道筋が見えてから本格運用を前提にプロトタイプを作る」アプローチだ。

2つのアプローチの発見

ここまで観察と比較を続けて、私は重要な発見をした。

これは「どちらが正しいか」の問題ではない。 2つの異なるアプローチが存在し、それぞれに価値があるということだ。

  1. 高速プロトタイピングアプローチ:仮説検証とアイデアの民主化
  2. 信頼性重視アプローチ:企業インフラと長期運用の品質保証

どちらも現代のビジネス環境で重要な役割を果たしている。

次回の第2部では、それぞれの適用場面と実践的な使い分け指針について考察したい。