設計とレビューで工数を39%削減。Sun Asteriskが語るAI駆動開発の型化とプロセス設計力
「Developers Summit 2026(Dev x PM Day)」レポート 18-C-5セッション
AIツールを導入しても期待ほど開発速度が伸びない、生成コードが増えるほど膨らむレビュー負担、プロセス設計の議論に時間を食われて実装が止まる——こうした壁をプロセスの型化と役割の再定義で乗り越えたのが、クライアントのプロダクト開発に伴走する「デジタル・クリエイティブスタジオ」、株式会社Sun Asterisk(以下、Sun Asterisk)だ。2026年2月18日、「Developers Summit 2026(Dev x PM Day)」において、同社のDivision Manager・岡藤裕太氏が登壇。設計を重視したAI実装と人間によるレビューを軸に工数39%削減を実現した現場の知見から、AI時代のプロダクト開発に必要な方法論や人材像を語った。
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%削減した。
この記事は参考になりましたか?
- この記事の著者
-
森 英信(モリ ヒデノブ)
就職情報誌やMac雑誌の編集業務、モバイルコンテンツ制作会社勤務を経て、2005年に編集プロダクション業務やWebシステム開発事業を展開する会社・アンジーを創業。編集プロダクション業務においては、IT・HR関連の事例取材に加え、英語での海外スタートアップ取材などを手がける。独自開発のAI文字起こし・...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
丸毛 透(マルモ トオル)
インタビュー(人物)、ポートレート、商品撮影、料理写真をWeb雑誌中心に活動。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
ProductZine編集部(プロダクトジンヘンシュウブ)
「プロダクト開発」にフォーカスしたCodeZine内のサブメディアです。プロダクトマネージャーや、プロダクトマネージャーを目指す方をはじめ、チームメンバーや事業責任者、テックリードなど、プロダクト開発を「正しく」進めていきたいすべての人のために、プロダクトマネジメントに関するあらゆる知見をお届けしま...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
提供:株式会社Sun Asterisk
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか?
この記事をシェア
