売るのは「AIの速さ」ではなく、「同じ失敗を二度しない能力」です ― CTSのAI駆動開発（請負・内製化支援）

このシリーズで、CTSが自社SaaS「CTS-EC」の技術的負債をどう返済し、その仕組みを共通ハーネスとして育て、複数プロジェクトへ配ってきたかを記録してきました。今回、その到達点として、この開発の進め方を他社向けのサービスとして提供する構想を公開します。

■ きっかけは、うまくいった話ではなく、二度繰り返した失敗です。

CTS-ECで約1か月かけて返した技術的負債が、CTS-POSでもう一度生まれた。さらに深刻だったのは、オブザーバビリティ・エラー処理・アラート発報が、そもそも要件に入っておらず、技術的負債の台帳にすら上がっていなかったことです。要求されていないものは、AIもテストも「欠落」と判定できません。その穴を埋めるのに、また1か月近くかかりました。

ここから得た結論は単純です。プロジェクトで得た教訓を、そのプロジェクトの文書に残すだけでは、組織は同じ授業料をもう一度払う。

■ AIがコードを書いたことは、品質の根拠にならない

CTSのAI駆動開発では「AIが書いたから速い・正しい」とは考えません。品質の根拠にするのは、AIの自己申告ではなく、実行結果です。

・要件と受入条件を、実装前にテスト可能な形へ固定する
・TDDと決定論的な品質ゲート（テスト・静的解析・ビルド・契約検査）で確認する
・セキュリティ・エラー処理・ログ・監視・アラートまでを「完成条件」に含める（後付けにしない）
・実案件で見つかった欠陥を個別修正で終わらせず、共通ルールとゲートへ戻し、別案件での再発を止める

コードが完成したか、ではありません。異常が起きたときに、正しく分類され、観測され、担当者へ届くか。そこまでを完成の定義にしています。

■ 請負開発と相性がよい理由

時間精算の準委任では、出戻りの削減が受託側の利益に直結しにくく、発注側と受託側のインセンティブが揃いにくい。固定価格の請負では逆で、少ない周回で同じ品質に到達できることが、そのまま競争力になります。

請負の難所は「何をもって完成とするか」です。CTSはここにハーネスを検収基準として置きます。要件・受入テスト・完成の定義・品質ゲート全緑・未消化の申し送りゼロを、双方が同じ証跡で読める。「完成しました」という自己申告を信じる契約から、双方が同じゲートを読める契約へ変えられます。

■ 誠実に、現在地を線引きします

前回の「『最高品質ですか？』にYesと答えないハーネス」の続きです。売る段になっても、姿勢は変えません。

・実測済み：.NET / Angular / GCP / AWS のSaaS（CTS-EC / POSで規範・ゲート・契約・通知経路を運用）
・これから実証：CTS-LOGI / AD を最初の実験台に、出戻り周回・ゲート発火・欠陥family・裁定回数の4指標を計測
・現時点で「完全対応」とは言わない：マイクロサービス / Java / React は、必要になった実案件から導出する

スタック自由の「何でも開発します」は目指しません。実測していない品質を、カタログの対応可否だけで売らないためです。

■ 4つのアプローチ

・AI駆動システム開発（請負）：要件整理から検収まで、品質と完成条件を見える形に
・AI組み込み・システム連携：分類・照合・確認・文章生成など、人が判断する工程へLLMを業務機能として組み込む
・クラウド基盤・モダナイゼーション：Terraformでの基盤構築、SaaS連携、AS/400等を活かす段階移行
・AI駆動開発の内製化支援：当社のハーネスを企業ごとに調整し、社内で継続できる仕組みへ

売るのは、AIの速さではありません。一度払った失敗の授業料を、次の案件では払わない。しかも、払わずに済んだことを証拠で示せる ― その能力です。

技術的な全記録はこちら、サービスのご相談はコーポレートサイトからどうぞ。

▼技術的負債から育てたAI駆動開発ハーネス【サービス化への現在地】― CTS-KB
https://kb.cts-g.ai/articles/ai-driven-development-harness-service-introduction

▼AIシステム開発（請負・内製化支援）― サービス案内・ご相談
https://www.cts-g.com/services/ai-agent/