ツーワンデジタル、「AIエンジニアリングモデル」を策定

公開：2026年9月18日

CodeCampが提供するDX人材育成が可能なプログラミングやITが学べる公開講座

この記事はプレスリリースです

本記事は、PR TIMESに掲載された企業・団体等のプレスリリースを原文のまま転載しています。記事内容は発表時点の情報です。

発表元: 合同会社ツーワンデジタル
原文: PR TIMESで元のプレスリリースを読む
配信日時: 2026年9月18日 11時00分
転載日: 2026年9月24日

発表内容については発表元へ、当サイト上の訂正・削除については、当サイトのお問い合わせフォームにご連絡ください。

転載

プレスリリース本文

蓄積した開発知見を体系化、継続的な品質向上へ

ソフトウェア、AI・データ領域を軸とした受託開発を展開する合同会社ツーワンデジタル（本社：東京都渋谷区、代表：岸田楓馬）は、およそ1年間の実務を通じて培った開発知見を体系化し、AIを前提にソフトウェア開発プロセスを設計、改善する「AIエンジニアリングモデル」を策定しました。

今後、本モデルを共通の開発基盤として継続的に活用し、お客様に提供するサービスのさらなる品質向上につなげてまいります。

策定の背景

生成AIの普及に伴い、ソフトウェアの初期構築は、以前より容易に行えるようになりました。しかし、「ソフトウェアを形にする」ことと、セキュリティ、保守性など、企業の実業務で求められる品質特性（注1）を備えたサービスを迅速に提供し続けることとの間には、依然として大きな隔たりがあります。

開発の現場においてAIの活用が広がる中、単に試作の手間を減らすだけでなく、お客様の課題解決を見据え、人とAIそれぞれの強みを活かした開発プロセスをどのように再設計し、継続的に改善していくかが重要なテーマとなっています（注2）。

注1：品質特性とは、ソフトウェアやシステムの品質を評価する観点を指します。国際規格ISO/IEC 25010でも、セキュリティや保守性などを含む品質特性が体系的に整理されています。

注2：Addy Osmani氏は「Loop Engineering」において、AIへ個別に指示するだけでなく、AIが自律的に動く開発ループそのものを設計し、その上で人が検証、理解、判断を担う考え方を発信しています。

AIエンジニアリングモデル

本モデルは、製品の実装状況と要件定義書等に定めた状態を照合し、プロダクトバックログアイテム（PBI、注3）候補を生成するとともに、各PBIに基づく実装、品質検証、プルリクエスト（PR、注4）の作成を自動化します。

また、開発をスプリント（注5）単位で区切り、スプリント初日の所定時刻に処理を自動で開始します。エンジニアが個別に操作、指示することなく、当該スプリントで予定する成果物から、次スプリントのPBI候補までを一通り作成します（注6）。

設計上の主なポイントは、次の4点です。

責務分担 ― AIは「作成」、人は「判断、改善、対話」
人とAIの責務を明確に分け、AIは「作成」に、人は「判断、改善、対話」に集中します。AIは、製品の実装や次の開発項目の整理などを担います。一方、人はそれらの成果物の理解と品質担保、開発プロセスの改善、お客様との対話を担います。AIに何を任せるかだけでなく、人が何に集中するかを含めて設計します。
時間配分 ― スプリント初日に「生成し切る」
従来は、スプリントの多くの時間を実装が占めていました。これに対し、本モデルは、スプリントの成果物を初日に一通り作成します。これにより、以降の時間を、品質担保、開発プロセスの改善、お客様との対話といった、人が担うべき活動に振り向けます。
実行方法 ― AIを「自律 × 並列」で動かす
人が逐次介入することなく、AIが実装、テスト、レビュー等を自律的、並列的に進めます。その後、次の開発項目の整理、報告を行います。これにより、品質検証を経た成果物の作成から次に予定するタスクの整理まで、一連の工程を高速化します。
ループ設計 ― 「生成」と「検収・フィードバック」の二重ループ
AIが人の逐次介入なく進める「生成」のループと、人が成果物の評価、判断（以下「検収」）やお客様との対話を担う「検収・フィードバック」のループを分けて設計します。前者ではAIが自律的に成果物を作成し、後者では人による検収やお客様からのフィードバックを次の開発へ反映します。この2つを接続し、継続的な開発サイクルを形成します。

これらの特長は、品質、コスト、提供速度（QCD）の最適化を目指すものであり、一度決めた形に固定されるものではありません。製品やシステムに求められる品質特性について、実務や学習を通じて社内に蓄積した判断基準を、AIが参照するドキュメントや開発プロセスに継続的に反映し、各設計を見直しながら、より良いソフトウェアの提供につなげています。

注3：PBI（プロダクトバックログアイテム）とは、機能追加や改善、修正など、プロダクトの開発で今後取り組む項目を一つひとつ整理したものを指します。

注4：PR（プルリクエスト）とは、開発した変更内容を確認、レビューした上で、製品のコードに反映するための依頼を指します。

注5：スプリントとは、開発を一定の期間ごとに区切り、その期間に取り組む開発項目を決めて進める方法を指します。

注6：図中のスプリント初日の「AI実行」に相当するプロセスを含む、本モデルと類似した開発フローを実際の受託開発案件で運用しています。一部の工程は本モデルと異なりますが、導入後はスプリント初日の早い段階でPRが一通り自動生成される状態から開発を始められるようになり、成果物の検収や改善など、品質向上に関わる業務へより多くの時間を充てられるようになりました。