SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

デブサミ2026の初日をProductZineとコラボで開催。

Developers Summit 2026 「Dev x PM Day」

Developers Summit 2026 「Dev x PM Day」

ProductZineイベントレポート(AD)

設計とレビューで工数を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駆動開発を取り入れてきた実践知だ。

株式会社Sun Asterisk Division Manager 岡藤裕太氏
株式会社Sun Asterisk Division Manager 岡藤裕太氏

 岡藤氏が示した基本方針は3つ。「設計に基づいたAI実装」「人間によるレビュー」「CI/CDによる品質担保」だ。自動テスト・静的解析・セキュリティチェックをパイプラインに組み込み、品質に対して人間が最終チェックを担うコンセプトは全プロジェクトに共通して貫かれている。

 大切にしているポイントについて岡藤氏は、「設計を着実にやること、そして品質を担保するためのレビューや仕組みを取り入れることです」と強調した。

 開発プロセスは、「基本設計→クリティカルパス設定→詳細設計→実装」の4ステップで構成される。このフェーズ設計には2つの意図がある。1つは、AIに渡すコンテキスト量の最適化だ。設計ドキュメントを詳細に書きすぎると、AIへのプロンプトが肥大化してしまう。

AI駆動開発の4ステップと各フェーズで作成するドキュメント
AI駆動開発の4ステップと各フェーズで作成するドキュメント

 もう一つの意図は、組織展開のしやすさだ。「AI駆動開発を取り入れます」と告げた瞬間、開発メンバーから「このフェーズではどこまで書くべきか」「何をどこまで書けばいいか」という議論が一斉に起き、実装に入る前に多くの時間が失われた経験があったという。従来の開発フェーズの枠組みに沿わせることで、初めてAI駆動開発に触れるエンジニアでも入りやすい型となった。

 このプロセスを支えるのが、Sun Asteriskが自社開発したFigmaプラグイン「MoMorph(モモーフ)」だ。Figmaのデザインにスペックをインプットすると、MoMorphから画面設計書とテストケースが自動で生成される。基本設計フェーズでは、このツールで出力した画面設計書をエンジニアがレビュー・修正し承認するフローをとる。

MoMorphを利用したドキュメント作成フロー
MoMorphを利用したドキュメント作成フロー

 詳細設計フェーズでは、Claude Codeのカスタムコマンドを用意している。コーディング規約やアプリケーションアーキテクチャ設計のルール、どのディレクトリにどのファイルを置くかといった情報を事前に定義しておくことで、インターフェースレベルの設計が出力される。

要件定義から実装まで──顕在化した3つの課題と解法

 要件定義フェーズでは、クライアントワークならではの壁に直面していた。プロジェクトには多様なステークホルダーが関与するため、Webアプリケーション開発に不慣れな担当者が加わるケースも少なくない。そうした環境では、ドキュメントに書く内容の「粒度の不一致」が起きやすい。エンジニアがクライアント側の記述をレビューして差し戻し、また書いてもらう。このやり取りが幾度も繰り返され、コミュニケーションコストが膨らんでいった。

 解決策として選んだのが、MoMorphを中間成果物の管理ハブとして活用する手法だ。クライアント側の画面要求書をAIに渡してMoMorphの決まったフォーマットに変換し、出力された画面設計書をエンジニアがレビューするフローを組み込んだ。

 岡藤氏は「クライアント側の画面要求書をAIに渡してインターフェースを整えてもらい、出力された画面設計書をエンジニアがレビューします」と説明する。ビジネス側は書きやすい形でインプットでき、エンジニア側は読みやすい形でレビューできる。双方にとって使いやすい共有基盤を構築することで、往復のコストを圧縮した。

 開発フェーズでは、3つの課題が顕在化した。1つ目は「タスクサイズの適切な分割」だ。AIへの指示は粒度を小さくするほど精度が上がるが、そのためにはタスクを細かく切れる設計が前提となる。同社では、インターフェースをもとに結合できることを保証する疎結合の設計を採用し、実装タスクを適切な粒度に分割しやすい構造を作った。

 2つ目は「要求スキルレベルの上昇」だ。基本設計からクリティカルパス(実装順序)を設定するには、何から着手すべきかを判断できるリードレベルの知識が求められる。結果として、メンバーレベルのエンジニアが活躍しにくい環境になっているという課題は現在も残っており、テンプレートの活用で補いながら引き続き解明を進めている段階だという。

 3つ目は「レビューコストの肥大化」だ。AIが生成するコードの量と速度が増えるにつれ、人間によるレビュー負担も比例して増大する。すべてのフェーズで個別にレビューするのではなく、前工程のレビューを後工程でまとめて確認する形でプロセスを絞ることで、リードタイムの圧縮を図った。

 こうした取り組みを重ねた結果、実装工数を39%削減した。

AI駆動開発の課題と対策の全体整理
AI駆動開発の課題と対策の全体整理

スピードと品質を両立する方法論──レビュー戦略の分岐点

 実装工数の削減を39%から、さらに60%、70%へと引き上げるために何が必要か。岡藤氏はさらに踏み込んだ方法論を紹介した。

 AI駆動開発における効率化の最大のボトルネックは、レビューコストだ。人が最終チェックを担う方針をとる以上、AIが生成するコードの量が増えるほど、レビューに要する時間も比例して伸びる。一方、レビューを削減してAIに完全委任する方向に進めば、品質の不確実性が増大する。

 AIに委ねる範囲が広がるほど、出力が全部正しいとは言い切れない部分も増える。これが人によるレビューを削ることのトレードオフだと岡藤氏は指摘する。

 効率化の選択肢は大きく2つに整理される。1つ目は「レビュープロセスを減らし、他の手段で品質を担保する」方向で、削る箇所によっては開発スピードが大きく変わる。2つ目は「レビュープロセス自体を効率化し、1件あたりの時間を短縮する」方向だ。今回紹介された方法は2つ目を採用しており、それが39%という数字の背景にある。「速さを重視するか品質を重視するかは、お客さまと期待値調整をした上でプロセスを再設計していきます」と岡藤氏は語る。

レビュー効率化の2つの選択肢──プロセス削減か、レビュー自体の改善か
レビュー効率化の2つの選択肢──プロセス削減か、レビュー自体の改善か

 レビュー効率を左右する要素として岡藤氏が挙げたのは「タスク分解」と「コンテキスト理解度」の2点だ。タスクを小さな単位に分解するほどAIの出力精度が上がり、レビュー対象の品質自体が改善される。コンテキスト理解度については、「何ができていればレビューをパスできるかの解像度が高いほど、見るポイントがはっきりして、レビューの速度が上がります」と説明する。

 AIが自動生成したテストケースをレビューする場面では、仕様をどれだけ把握しているかがそのままレビュー速度に直結する。仕様の網羅性を判断できるコンテキストがあるエンジニアほど、短時間で精度の高いレビューが可能だ。AI駆動開発において、個人のスキルと知識が速度と品質に直接影響する構造になっていると岡藤氏は指摘した。

AI時代の開発を担う人材像──求められる5つのケイパビリティ

 AI駆動開発のプロセスを現場で機能させるには、それを担う人材の能力も再定義が必要だ。岡藤氏は実践を通じていくつかのケイパビリティが重要になると定義した。

 なかでも重要視するのが、プロセスの設計とアップデート能力だ。「プロセス設計に銀の弾丸はありません。プロジェクトやチームごとに最適な形が異なるので、常にアップデートを続ける意識が必要です」と岡藤氏は語る。現場の一次情報をもとに仮説を立て、絶えず改善し続けられる姿勢が、AI駆動開発の成否を分ける。

 クリティカルパスを引く能力も欠かせない。タスクの依存関係を整理し、どの実装からどの順序で着手するかを事前に設定する力だ。同社のAI駆動開発では1スプリント(2週間)で50タスク近くを同時に進めるスピード感になる。クリティカルパスが崩れた瞬間、実装は止まる。「その時間が非常にもったいないです」と岡藤氏は語った。依存関係を見越してタスクの順序を設定する力が求められる。

 優先度付けと開発推進能力については、リアルな失敗談を交えて語られた。「AI駆動開発のプロセスのアップデートが楽しくなってしまい、そちらに時間をかけすぎて、プロダクト開発の本来の目的をおろそかにしてしまったことがありました」。改善活動と本来の開発目的のバランスを意識的に保つことが、この能力の核心だ。

 これらのケイパビリティの適用は、「管理者」と「作業者」で役割が分かれる。管理者はクリティカルパスの設定やタスクの優先度付け・開発推進に責任を持ち、作業者は完了条件を高解像度でイメージする役割やアーキテクチャ設計を担う。プロセスの設計とアップデート能力、クリティカルパスの設定は両者に共通して求められる。俯瞰した管理者目線と、AIと並走するエンジニア目線では見えてくる課題が異なるため、双方の視点からのアプローチが組織全体の改善につながるからだ。

管理者と作業者それぞれに求められるケイパビリティ
管理者と作業者それぞれに求められるケイパビリティ

 こうした能力を実践的に機能させるうえで、プロダクトマネージャー観点とエンジニア観点を横断する広い知見も重要になると岡藤氏は付け加えた。

 「エンジニアはこう動くだろうからプロダクトマネージャー観点でここのプロセスを変えよう、という発想が生まれるには、両方の視点を持っていることが前提になります」

 広いスコープでQCDを俯瞰しながら仮説を立ててプロセスをアップデートしていくうえで、複眼的な知見は選択肢の幅を広げる。一方、個人の専門性もAI時代においてむしろ価値を増している。クライアントや自社プロダクトのドメインに精通した「ドメインスペシャリスト」と、ソースコードやアーキテクチャへの深い理解を持つエンジニアが、それぞれプロセス設計力を備えることで、高い解像度のレビューと継続的な改善の両立が実現できるという考えだ。

 最後に岡藤氏は、「現場の一次情報を受け取りながらAI駆動開発のプロセスを適用し、運用しながらアップデートをかけていく。その伴走こそがわれわれの価値です。AI Readyなプロセスの適用・運用を担いながら、クライアントの皆さんと素晴らしいプロダクトを作っていくことがわれわれの使命です」と締めくくった。

この記事は参考になりましたか?

提供:株式会社Sun Asterisk

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

ProductZine(プロダクトジン)
https://productzine.jp/article/detail/4129 2026/03/25 12:00

イベント

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング