AIを用いたソフトウェア開発、いわゆる AI駆動開発 が本格的に広まり始めて、すでに2年ほどが経過した。この間、生成AIは急速に進化し、多数のツールや手法が登場した一方で、「実務としてLLMをどう使いこなすか」という問いに対する体系だった回答は、まだ十分に整理されていない。
AI駆動開発の主要構造を端的に示す動画
まず紹介したいのは、次の動画である。
https://www.youtube.com/watch?v=7JBuA1GHAjQ
スピーカーは Brian Casel。エージェントオーケストレーションツール AgentOS を開発しており、YouTube上でも継続的にAI開発に関する有益な情報を発信している。
この動画は、私が本記事で後述する内容を「最も短く」「最もわかりやすく」まとめていたため取り上げた。
Casel が強調しているポイントは以下の3つである。
- Spec-Driven Development
- Context Engineering
- Workflow Orchestration
これらはすべて「LLMを外側から制御するための技術」であり、実務においてLLMを安定して活用するための基盤となる。
唯一ここに含まれていない重要領域があるとすれば、それは「テスト」である。
LLMの限界を明確に示す：Richard Sutton と Dwarkesh Patel の議論
次に紹介するのは、AI研究の本質的側面を捉えるうえで示唆に富む動画である。
https://www.youtube.com/watch?v=21EYKqUsPfg
この動画には Richard Sutton（強化学習分野の第一人者、「The Bitter Lesson」の筆者）と、AI分野の大物研究者へ鋭い質問を投げ続けるインタビュアー Dwarkesh Patel が登場する。
二人の議論が全く噛み合わないまま1時間進むのが面白いのだが、
Sutton の指摘は、
- LLMは人間が書いたデータを模倣するモデルに過ぎず、環境との相互作用を通じて学習する仕組みを持っていない。
- そのため、行動改善という知能の核心を欠いており、長期的には別のアーキテクチャが必要になる可能性が高い。
LLMは「自律的知能」ではない
Sutton の主張は要するにこうである。
- LLMは「次の単語を予測する巨大モデル」であって、
- 行動→フィードバック→改善という知能の本質的機能を持たず、
- 自己改善を続ける自律エージェントにはなれない。
- つまり、LLMは決して“自動で賢くなっていく存在”ではない。
この事実が、実務におけるLLM活用に直接的な含意を持つ。
「LLMを開発に使う」とはどういうことになるのか？
LLM は単体では破綻する
- 文脈の一貫性を保持できない
- 自分の誤りを学習しない
- 環境の変化に適応できない
- それっぽい嘘を平然と出す
つまり、単体では信頼できる開発者にはなり得ない
しかし、圧倒的な生成能力と解析能力を持つ
- 大量のボイラープレート生成
- コードリーディングの高速化
- 設計・ドキュメント化の補助
- テストケース生成
- 特定の整形・変換タスクの高速処理
ここに実用価値がある。
だから、外側の制御構造が必須となる
LLM は「未完成の作業者」であるため、外部に以下の仕組みを置く必要がある。
- Spec（期待するアウトプットの固定）
- Context（現在地の明示と制限）
- Workflow（手順の固定と強制）
- Testing（生成物が要求を満たしているかを検証）
これらが整って初めて、LLMは一貫した成果物を生成できる。
現在のAI駆動開発の本質
まとめると、不完全なLLMを“外側”で完成させる技術体系とは
「LLMを、外側から構造と制約で補強し、実務で使えるアウトプットを出させるための技術体系」
LLMをどうハーネスし、どう制御し、どう破綻させないかこそが本質である。
本連載の目的
私は会社で唯一のエンジニアであり、特にフロントエンドは未経験の状態からプロダクト開発を進めなければならなかった。
人的リソース、時間、経験の制約を考慮すれば、LLMを使わないという選択肢は事実上存在しなかった。
色々調べる中で学習してきた内容を整理して記録していこうと考えている。