要求管理から詳細設計・実装・結合テスト・品質分析までを1つの基盤でつなぐ、企業専用AI開発OS「AI-DevContinuum」を、SHIKOU × AIが自社のシステム開発現場で開発しました。実際の案件でも継続して検証しています。
一言でいえば、AI駆動開発×ALM（Application Lifecycle Management：開発ライフサイクル管理）です。AIで開発を進め、そこで生まれた品質やナレッジを次の開発へつなぐ。
その根底にあるのは、AIに任せるところと、人間が責任を持つところを分けるという考え方です。AIが各工程の下書きや分析を支援し、人が確認・承認する。数値の計算や最終判断は人に残し、AIには下書きと分析だけを任せています。
開発するほど、企業の開発力が高まる。
それがAI-DevContinuumの目指す姿です。
AI-DevContinuumは何をするツールか
AI-DevContinuumでは、担当者が聞き取った要求をもとに、AIが要件定義書の下書きを生成します。承認された要件定義書の内容は、そのまま設計書やテストケースの下書きにも引き継がれます。
要求ヒアリングから要件定義書・設計書までをAIが下書きする
ヒアリングで聞き取った要求は、要求ごとにIDを振って登録します。このIDを設計書やテストケースに通しで使うことで、後から「この要求はどの設計に反映され、どのテストで確認したか」をツールをまたがずに追えるようにしています。
要件定義書はClaude(Anthropic社のAIモデル)のOpusというモデルで下書きを生成し、担当者が内容を確認して承認する流れです。要求の抽出にはSonnetを使い、用途に応じてモデルを使い分けています。
実装・結合テスト・品質分析までを同じ基盤でつなぐ
承認された要件定義書と設計書をもとに、実装計画と結合テスト計画をAIが起案します。現状の実装計画は新規実装が前提です。今後は、既存コードとの整合性をAIが分析し、新規作成・既存改修・既存機能の流用のいずれで進めるかを判断したうえで実装計画を起案する機能へ発展させる予定です（人の承認を経てAIが実装に着手する流れ自体は変わりません）。テスト結果や不具合の件数は品質分析の画面に集計され、進捗やリスクをPMがまとめて確認できるようにしています。
機能ごとの実装状況、テストの通過状況、不具合の件数が別々のツールに分かれていると、品質管理責任者が全体像をつかむまでに時間がかかります。そのためAI-DevContinuumでは、これらの情報を同じ基盤の中で、要求に振ったIDにひもづけて管理しています。
品質をどう担保しているか
AI-DevContinuumが目指しているのは「AIに全部やらせる」ことではありません。AIに任せるところと、人間が責任を持つところを分けることで、品質の再現性を確保しています。これはAI-DevContinuumの設計全体を貫く、企業向けAI開発の考え方です。
不具合の知見を、レビュー観点として次の開発へつなぐ
見つかった不具合は、原因を分析したうえでレビュー観点として蓄積し、次のAIレビューへ自動で反映します。「AIに新しいコードを書かせるだけ」ではなく、開発で得た知見を組織の資産として次に活かす仕組みです。詳しくは別記事レビュー品質をAIのナレッジループでどう変えたかにまとめています。
品質スコア・リスクスコアはAIに計算させない
不具合件数やテスト進捗から算出する品質スコアやリスクスコアは、SQLとPythonによる決定論的な計算式で出しています。AIが担当するのは、その数値が何を意味するかという所見文の生成だけです。
数値の計算をAIに任せると、モデルや実行条件によって結果が変わる可能性があります。そこで、監査や振り返りに使う数値は再現性を前提とし、この線引きを設けました。
名寄せ・分類の最終確定は人が行う
不具合の名寄せや機能分類は、AIが候補を提示し、確定するかどうかは人が判断する運用にしています。誤って統合してしまうと、それ以降の分析データ全体に影響するため、取り消しできる形にしています。
また、特定の規格への対応を謳う場合の表現にも注意しています。「対応済み」ではなく「対応を支援する機能」にとどめているのは、規格ごとの要求事項の整理や運用の証跡づくりが、機能の実装だけでは完結しないためです。
なぜ作ったか
AI-DevContinuumを作った理由は、レビュー・要求管理・品質管理がツールごとに分かれていることそのものが、品質のばらつきや仕様漏れを生んでいると考えたためです。
レビュー品質の属人化と仕様漏れ
レビューはベテラン担当者の経験や勘に頼ることが多く、担当者によって指摘の質にばらつきが出ます。過去の指摘内容も個人の記憶やメモにとどまり、次の案件に活かされにくいという課題がありました。
また、要求と設計・テストの対応関係をExcel等で個別に管理していると、実装漏れやテスト漏れが起きやすくなります。要求が変更されたときに、どの設計やテストへ影響するのかを追いきれないことも課題でした。
レビュー指摘の観点をどう蓄積し、精度をどう検証したかは、別記事レビュー品質をAIのナレッジループでどう変えたかにまとめています。
専用ツールを組み合わせる案も検討したが、統合を選んだ理由
要求管理・品質管理・コードレビューをそれぞれ専門のツールに任せる案も検討しました。個別のツールは機能が深く、乗り換えのコストも一つひとつは小さく済みます。
それでも、要求・設計・テストの情報がツールごとに分かれていると、対応関係を保つ紐付け作業がツールをまたぐたびに発生します。案件を重ねるほどこの維持コストの方が効いてくると判断し、要求から品質分析までを1つの基盤でつなぐ設計を選びました。
導入すると何が変わるか
AI-DevContinuumは自社で開発しながら実際に運用しているため、開発を続けてきた過程そのものが実測値として残っています。
開発の進捗と回帰テストの積み上げ
機能を追加するたびに全件の回帰テストを実行しており、テストの件数は約40件から約140件、約200件、約260件、約310件と積み上がってきました。
回帰テストの件数が増えるほど、1回の機能追加にかかる確認の手間も増えます。それでも全件を通した上でリリースする運用を続けているのは、品質分析の数値そのものに再現性を持たせるためです。
名寄せ精度の検証は、詳しくは別記事で
不具合の名寄せ(表記ゆれのある同じ不具合をまとめる処理)では、AIによる分類と単純な文字列の類似度を比較する検証も行いました。この検証は合成データによるもので、実データでの精度はまだ検証していません。
検証の詳細な条件と結果は、レビュー・品質管理機能を掘り下げた別記事レビュー品質をAIのナレッジループでどう変えたかにまとめています。
他人が運用できる形にするまでにやったこと
自社の開発フローの中だけで動けばよいわけではなく、他社のPM・品質管理責任者が実際の案件で使える状態にするまでには、いくつかの設計判断がありました。
実行系の操作(コード生成やAIへの指示送信など)を安全に扱うため、権限のないメンバーには操作をさせない設計にしています。計画では管理者権限に限定していたはずの操作が、一般メンバーでも実行できる状態になっていたことが第三者レビューで見つかりました。
この経験から、権限に関わる機能を拡張するときは、実装後に別の視点でレビューする工程を標準の運用にしています。AIへの指示や外部への送信も、内容をマスキングして記録に残す1つの経路に統一しました。
どんな場合に向いているか
AI-DevContinuumは、決まった仕様に合わせてもらうパッケージ製品ではなく、発注企業の開発フローや体制に合わせてカスタマイズする開発OSという立ち位置です。
想定する導入規模
現在は自社開発や中小のシステム開発会社(10名から50名程度のチーム)での運用を続けています。今後は大手のシステム開発会社や規制の厳しい業界での利用を想定しています。
こんな課題感なら当てはまる
次のような状況では、要求から品質分析までを1つの基盤でつなぐ効果が出やすいと考えています。
- 開発ドキュメント作成に時間がかかる：
要件定義書・設計書・テスト仕様書を毎回ゼロから作成しており、ドキュメント作成が開発者の大きな負担になっている
→ AIが下書きを生成し、人が承認する形で負担を減らせます - レビュー品質が属人化している：
ベテランの経験や勘に頼ったレビューになっていて、担当者によって品質にばらつきが出ている。過去の指摘が次の案件に活かされない
→ AIレビューと品質フィードバックで観点を蓄積し、自動反映します - 要求・設計・テストの漏れを防ぎきれない：
要求と設計、テストケースの紐付けをExcel等で管理していて、実装漏れ・テスト漏れ・対応関係の確認に手間がかかる
→ トレーサビリティとテストマトリクス、カバレッジで補います - プロジェクトの品質・進捗を横断的に把握できない：
不具合、リスク、テスト進捗、カバレッジなどの情報が各所に分散し、PMが今どこに問題があるのかをリアルタイムに把握しにくい
→ 品質ダッシュボードで一元把握できます(WBS・進捗管理は専用画面で提供しており、ダッシュボードへの統合は今後の予定です)
一方で、すでに社内の運用フローが固まっていて、部分的な機能だけを補いたいという場合は、専用ツールを個別に導入する方が早いこともあります。どの部分をどこまでカスタマイズするかは、実際の開発フローを伺いながら決めていく形になります。
よくある質問
AI-DevContinuumの導入を検討する中で、次のような質問をよくいただきます。
Q：ALMとは何ですか
A：ALMは、Application Lifecycle Managementの略で、要求定義から設計・実装・テスト・保守までのシステム開発の一連の流れを管理する考え方です。AI-DevContinuumは、このALMの各工程をAIの下書き生成と人の承認判断でつなぐ開発OSとして設計しています。
Q：既存の開発管理ツールを使っている場合、乗り換える必要がありますか
A：既存のツールをすべて置き換える前提ではなく、貴社の開発フローや体制に合わせてカスタマイズする形で導入します。どの工程から置き換えるか、どの工程は既存のまま残すかは、実際の開発フローを伺いながら決めていきます。また、場合によっては既存のツールと連携させることも可能ですので、その点もあわせてご相談ください。
Q：レビュー機能について詳しく知りたいです
A：レビュー指摘の観点をどう蓄積し、精度をどう検証したかは、別記事レビュー品質をAIのナレッジループでどう変えたかで扱っています。
Q：AIが生成した内容がそのまま採用されることはありますか
A：要件定義書や設計書、テストケースはAIが下書きを作りますが、内容を確定するのは常に人です。品質スコアやリスクスコアの計算式もAIには触らせず、SQLとPythonによる決まった式で算出しています。
まとめ
AI-DevContinuumは、要求管理から詳細設計・実装・結合テスト・品質分析までを1つの基盤でつなぐ開発OSです。要求ごとのIDを設計書やテストケースにも通しで使うことで、対応関係をツールをまたがずに追える仕組みにしています。
現時点で予定していた標準機能の実装を完了し、機能追加のたびに実行する回帰テストは約310件まで積み上がっています。数値の計算をAIに任せず決定論的な式で出しているのも、この開発を続けてきた過程に再現性を持たせるためです。
導入を検討する際は、貴社の開発フローのうち、どの工程から要求管理と品質分析をつなぎたいかを伺うところから始めます。まずは現状の課題を1つ挙げていただければ、AI-DevContinuumをどの工程から段階的に導入できそうかをお伝えします。
AI-DevContinuumの導入を検討している方へ
次のような課題を抱えているPM・品質管理責任者の方向けの内容になっています。
- 開発ドキュメント作成に時間がかかる
- レビュー品質が属人化している
- 要求・設計・テストの漏れを防ぎきれない
- プロジェクトの品質・進捗を横断的に把握できない
要求管理・レビュー・品質分析のどこに一番課題を感じているかを伺い、貴社の開発フローに合わせてどこからカスタマイズしていくかを相談しながら決めていきます。製品の詳細はAI-DevContinuum製品ページにまとめています。実際の画面に触れていただけるデモ版もご用意していますので、ご希望の方はお問い合わせの際にお申し付けください。
まずはお問い合わせから、現状の課題を聞かせてください。