AI駆動開発の全体設計──品質と速度を両立する3本柱
Sun Asteriskは、単なる受託開発にとどまらず、ビジネス・テック・クリエイティブの三位一体でクライアントの事業創造から実装までを支援する「デジタル・クリエイティブスタジオ」だ。岡藤氏は同社のエンジニア部門を統括しながら、テックリードやアドバイザーとして現場にも関わり続ける立場にある。本セッションで共有されたのは、そのクライアントワークの現場に実際にAI駆動開発を取り入れてきた実践知だ。
岡藤氏が示した基本方針は3つ。「設計に基づいたAI実装」「人間によるレビュー」「CI/CDによる品質担保」だ。自動テスト・静的解析・セキュリティチェックをパイプラインに組み込み、品質に対して人間が最終チェックを担うコンセプトは全プロジェクトに共通して貫かれている。
大切にしているポイントについて岡藤氏は、「設計を着実にやること、そして品質を担保するためのレビューや仕組みを取り入れることです」と強調した。
開発プロセスは、「基本設計→クリティカルパス設定→詳細設計→実装」の4ステップで構成される。このフェーズ設計には2つの意図がある。1つは、AIに渡すコンテキスト量の最適化だ。設計ドキュメントを詳細に書きすぎると、AIへのプロンプトが肥大化してしまう。
もう一つの意図は、組織展開のしやすさだ。「AI駆動開発を取り入れます」と告げた瞬間、開発メンバーから「このフェーズではどこまで書くべきか」「何をどこまで書けばいいか」という議論が一斉に起き、実装に入る前に多くの時間が失われた経験があったという。従来の開発フェーズの枠組みに沿わせることで、初めてAI駆動開発に触れるエンジニアでも入りやすい型となった。
このプロセスを支えるのが、Sun Asteriskが自社開発したFigmaプラグイン「MoMorph（モモーフ）」だ。Figmaのデザインにスペックをインプットすると、MoMorphから画面設計書とテストケースが自動で生成される。基本設計フェーズでは、このツールで出力した画面設計書をエンジニアがレビュー・修正し承認するフローをとる。
詳細設計フェーズでは、Claude Codeのカスタムコマンドを用意している。コーディング規約やアプリケーションアーキテクチャ設計のルール、どのディレクトリにどのファイルを置くかといった情報を事前に定義しておくことで、インターフェースレベルの設計が出力される。
要件定義から実装まで──顕在化した3つの課題と解法
要件定義フェーズでは、クライアントワークならではの壁に直面していた。プロジェクトには多様なステークホルダーが関与するため、Webアプリケーション開発に不慣れな担当者が加わるケースも少なくない。そうした環境では、ドキュメントに書く内容の「粒度の不一致」が起きやすい。エンジニアがクライアント側の記述をレビューして差し戻し、また書いてもらう。このやり取りが幾度も繰り返され、コミュニケーションコストが膨らんでいった。
解決策として選んだのが、MoMorphを中間成果物の管理ハブとして活用する手法だ。クライアント側の画面要求書をAIに渡してMoMorphの決まったフォーマットに変換し、出力された画面設計書をエンジニアがレビューするフローを組み込んだ。
岡藤氏は「クライアント側の画面要求書をAIに渡してインターフェースを整えてもらい、出力された画面設計書をエンジニアがレビューします」と説明する。ビジネス側は書きやすい形でインプットでき、エンジニア側は読みやすい形でレビューできる。双方にとって使いやすい共有基盤を構築することで、往復のコストを圧縮した。
開発フェーズでは、3つの課題が顕在化した。1つ目は「タスクサイズの適切な分割」だ。AIへの指示は粒度を小さくするほど精度が上がるが、そのためにはタスクを細かく切れる設計が前提となる。同社では、インターフェースをもとに結合できることを保証する疎結合の設計を採用し、実装タスクを適切な粒度に分割しやすい構造を作った。
2つ目は「要求スキルレベルの上昇」だ。基本設計からクリティカルパス（実装順序）を設定するには、何から着手すべきかを判断できるリードレベルの知識が求められる。結果として、メンバーレベルのエンジニアが活躍しにくい環境になっているという課題は現在も残っており、テンプレートの活用で補いながら引き続き解明を進めている段階だという。
3つ目は「レビューコストの肥大化」だ。AIが生成するコードの量と速度が増えるにつれ、人間によるレビュー負担も比例して増大する。すべてのフェーズで個別にレビューするのではなく、前工程のレビューを後工程でまとめて確認する形でプロセスを絞ることで、リードタイムの圧縮を図った。
こうした取り組みを重ねた結果、実装工数を39%削減した。
