01
ENGINEERING NOTE
- AI駆動開発
- AI-DLC
- ハーネスエンジニアリング
AIを使うから実装を任せるへ：FooQoo流 AI駆動開発ベストプラクティス
この記事が参考になったら
はてなブックマークに追加してもらえるとうれしいです。
現在の章01AIを「使う」から実装を「任せる」へ
01
ENGINEERING NOTE
この記事が参考になったら
はてなブックマークに追加してもらえるとうれしいです。
現在の章01AIを「使う」から実装を「任せる」へ
AIを使っているのに、気づけば実装やバグ修正のことばかり考えていませんか。作りたいもののイメージがあっても、コードを動かすことに意識を取られると、そのイメージを具体化する時間が後回しになります。
この問題を防ぐために、AIに個々の作業を頼むだけでなく、実装工程を任せる進め方を考えました。そうすることで、作り手は「何を作るか」「どこまで作るか」「できあがったものはイメージ通りか」という判断に集中できます。
実際にこのテックブログを作るときも、実装やバグ修正に追われて、作りたいものを考える時間がなくなることは避けたいと考えていました。私が時間を使いたかったのは、機能の優先度や画面の雰囲気を決め、このブログをどんなものにするかを詰めることです。
この記事では、本テックブログの開発を例に、作るものを具体化して実装を任せ、結果を確かめるまでの進め方を紹介します。目指したのは、作り手が「何を作るか」に集中でき、任せた実装もイメージからぶれにくい状態です。
本テックブログの開発ではAI駆動開発の考え方の一つでありAWSが提唱するAI-DLC（AI-Driven Development Life Cycle）を採用しています。
AI-DLCは、AIを開発の各工程に参加させ、人間が重要な判断を担う開発の考え方です。AWSが提唱する枠組みでは、開発をInception（構想を要件にする）、Construction（設計・実装する）、Operations（運用する）の3つのフェーズで捉えます。AIが計画を提案し、不明点を尋ね、実行する。その節目で人間が内容を確かめます。
私はこの考え方を個人開発に取り入れ、特にInceptionとConstructionの分担を意識しました。Inceptionでは、AIの質問や提案を使いながら、何を作るかを具体化します。機能やデザイン、実現する仕組みについて、採用するものと見送るものを自分で決めます。Constructionでは、その判断をもとに実装をAIへ任せ、仕様に沿っているかを確かめる仕組みも動かします。
私が自分で握っておきたいのは、プロダクトとして何を目指すかという判断です。候補を考えるところはAIと協業し、決めたものを形にする工程は任せたいと考えました。
図1は、開発の全体像を表したものです。Inceptionで決めたPenのデザイン、設計文書・実装範囲、受け入れ条件を守るべき仕様として渡し、AIが実装します。その結果について静的解析、UT、結合試験・E2Eテスト、Penと実画面の照合で確かめ、失敗したらAIが修正します。仕様やデザインを大きく変える必要が出たときは、人が判断してInceptionに戻ります。
図1：検証結果をAIの次の実装に返します。仕様やデザインの大きな変更は人が判断します。
この記事では、このテックブログを作る際のInceptionとConstructionを順にたどります。まずは、曖昧なイメージをどう実装に渡せる形にしたかから書きます。
開発を始める時点で、作りたいものの完成像がはっきりしているとは限りません。私にとってInceptionの中心は、決まった仕様をAIに伝えることよりも、対話を通じて自分のイメージを具体化することです。AIには足りない観点を質問してもらい、機能、画面、文言、実現方法の候補を出してもらいます。その中から何を採用するかは、自分で決めます。
このテックブログの開発で最初にAIと議論した問いは、「今回の作業のゴールは何か」でした。ゴールを考えると、ブログにありそうな機能を並べる前に、読者にまず何ができてほしいかを決められます。今回は、読者が記事を選んで読み、書き手についても知れることを中心に置きました。
その目的に照らして、MVPに何を含めるかを判断しました。
MVP：最初にユーザに届ける価値を必要最低限の範囲まで絞ったプロダクト
ホームは記事一覧を兼ね、記事の詳細ページでは本文と目次を読めるようにします。一方、最初に用意できる記事の数は少ないため、サイト内検索やタグによる絞り込み、人気記事などの機能は見送りました。AIから機能を提案されても、「あれば便利か」だけでなく「今の目的に必要か」で優先度をつけます。
このとき決めるのは、実装する機能だけではありません。今回作らない機能も明らかにすると、AIが実装中に機能を広げずに済みます。また、どこまで具体的に決めてから実装へ渡すかが見え、外せない体験に集中できます。
実際にAIはブログシステムでよく実装されている検索機能を提案してきましたが、記事が少ない段階では一覧から選ぶ体験を整えるほうが先だと考え、見送りました。
次に必要だったのは、「読みやすいブログ」のような言葉を、画面として判断できる形にすることでした。画像生成AIに複数のデザイン案を出してもらい、トーンや配置を見比べました。一つの案を丸ごと選ぶのではなく、明るい技術誌のような雰囲気、左に記事・右にプロフィールを置く構成、文字の余白感など、気に入った要素を選んでいきました。候補を見ることで、最初は言葉にできなかった好みも具体的になりました。
選んだ方向性はPenでホーム、記事詳細、目次、404画面などの具体的なデザインにしました。
Pen：AIエージェントと一緒に画面の配置や文言を編集できるデザインツール。作った画面は
.penファイルとしてリポジトリに保存できます。テックブログの開発では、画像案から選んだ方向性をPenで具体化し、実装が守る見た目の基準にしました。
Penの画面と文言は、Constructionで実装が守る仕様として扱います。画像案は雰囲気を探る助けになりますが、文字の大きさや行間まで判断しきれませんでした。そこは、実際に使う書体と文量を置いた画面で詰める必要がありました。
デザインが定まると、何を実装すればよいかも見えてきます。私の場合は、漠然と「ブログを作る」と考えていた状態から、記事を選ぶ画面、読み進める画面、現在地を示す目次など、実装対象を具体的に考えられるようになりました。
図2：Penで具体化したホーム画面。記事一覧とプロフィールの配置、文字の余白感を実装時の基準にしました。
画面のイメージが見えた後は、それを成立させる仕組みの設計に集中しました。例えば、記事をどんなデータとして持つかです。このテックブログでは、記事をMDXファイルで管理し、タイトル、URLに使うslug、公開日、下書きかどうかなどを記事ごとに持たせます。画面に表示する情報と公開の条件が決まると、AIに任せる実装の範囲も明確になります。
配信方法については、公開記事のページをビルド時に事前生成する方針にしました。一方、執筆中の記事は pnpm dev で確認できるようにし、本番の成果物には下書きを含めないと決めました。公開ページを事前生成しつつ、存在しないURLにはサーバーから404を返す構成です。こうした画面の外側の条件も、実装前に決めておきます。
Inceptionの成果物は、Penのデザインだけではありません。記事データや配信方法を記した設計文書、今回作る範囲、完成を判断するための受け入れ条件も揃えます。自分のイメージをこれらの形にして渡すことで、ConstructionではAIが実装に取り組みやすくなり、できあがったものを確かめる基準も持てると考えています。
Inceptionで作るものを決めたら、Constructionでは実装をAIに任せます。ここで重視したのがハーネスエンジニアリングです。AIが参照する仕様や作業範囲を揃え、実装結果を確かめる手段と、失敗したときのフィードバックを用意する考え方です。OpenAIの実践でも、エージェントが作業できる環境、意図の明文化、検証の仕組みが重視されています。
このテックブログでは、Penのデザイン、設計文書、受け入れ条件を実装の参照元にしました。受け入れ条件には、例えば「公開記事を選ぶと詳細へ進める」「開発中は下書きを確認できるが、本番の成果物には含めない」といった、完成時に確かめる内容を書いています。AIが実装方法を考える余地は残しながら、守るべき画面や動作を明確にしました。
実装方法を細かく指示するより、目指す画面と完成の判定基準を用意することがポイントです。AIが途中で迷ったときにも、そこへ戻れる状態が重要だと考えています。
実装にはTDD（Test-Driven Development）を採用しました。期待する動作をテストで先に表し、失敗を確認してから実装し、テストが通るところまで進める方法です。さらにE2Eテストも導入し、実際のブラウザでホームから記事を開き、目次で章へ移動する、といった読者の操作を通して確かめます。下書きが開発環境だけで見えることや、存在しない記事が404になることも確認対象にしました。
チェックはテストだけではありません。作業は依存関係に沿ってWaveに分け、各Waveの統合時には、機能同士が実際につながるかを専用スクリプトで一度に確認しました。例えば、記事データがホームに表示されることや、ホームから詳細へ進めることを確かめています。最終段階ではE2EとPenとの画面照合も行いました。
図3：Constructionの実装の流れ。並列で作業できるUoWはWaveで統合し、フロー型で進める。
こうして、AIが「できました」と報告するだけで終わらず、実行結果を見て修正できる流れにします。ただし、テストが通ることだけで完成を決めるわけではなく、最終的には作り手による最後の判断が必要になります。
実装中の小さな不足や、仕様を変えずに直せる問題は、AIが補って結果を報告します。一方、機能の範囲、Penのデザイン、受け入れ条件を大きく変える必要が出たら、作業を止めて人が判断します。AIに実装を任せるために、どこまで自分で進めてよいかという境界も渡しておくのです。
テストやビルドは、決めた動作や公開条件を確かめる助けになります。ConstructionではPenと実画面の照合も行いました。その上で最後に確かめたいのは、Inceptionで具体化したイメージと、読者が触れる画面が合っているかです。記事を選び、読み進め、書き手を知る流れを自分で操作し、文字の読みやすさや余白の印象も見ます。
私が目指すのは、何を作るかを自分で決め、実装をAIに任せ、できあがったものを自分で判断する進め方です。イメージを仕様にし、結果を確かめる仕組みを整えるほど、実装を任せやすくなり、成果物もぶれにくくなると考えています。
今回はAIを使うだけでなく、実装ステップを任せるFooQoo流のAI駆動開発の進め方を紹介しました。 実際にこの開発手法を使っていると、よりプロダクト開発により集中できるようになるので参考になれば嬉しいです。