📖 はじめに — 一度直した負債が、別のプロジェクトでもう一度生まれた
前回は、共通ハーネス cts-harness v0.15.2 の現在地を、こう結んだ。
足せることではなく、測って捨てられること。分からないことを、分からないまま正しく残せること。
それから約1か月。本稿では、ハーネスが v0.15.2からv0.31.0 へ進んだ期間を観測範囲とする。本稿の基準日である2026年8月30日時点の最新リリースは v0.31.1 である。
ここでいうハーネスとは、AI モデルそのものではなく、その周囲に置く規範、テスト、品質ゲート、証跡、権限制御、作業手順の総体を指す。AI が「何を作り、何をもって完成とするか」を、会話の記憶だけに依存させないための装具である。
この版数の増加は、機能開発の速さを誇る数字ではない。むしろ、当時のハーネスに何が入っていなかったかを示す記録である。
CTS-EC では、AI 駆動開発の過程で積み上がった技術的負債を、約1か月かけてリファクタリングした。しかし、その知見を共通ハーネスへ十分に戻せていなかったため、同じ型の負債が CTS-POS で再発した。
さらに深刻だったのは、オブザーバビリティ、エラー処理、アラート発報がハーネスの要求に入っていなかったことだ。未実装なのに、技術的負債の台帳にすら上がっていなかった。要求されていないものは、AI もテストも「欠落」とは判定できない。その穴を埋めるため、CTS-EC / POS のアプリケーションと、GCP / AWS の監視・通知経路を横断し、さらに1か月近くを要した。
二度の「1か月」から得た結論は単純である。
プロジェクトで得た教訓を、そのプロジェクトの文書に残すだけでは、組織は同じ授業料をもう一度払う。
では、次の SaaS である CTS-LOGI / AD では、どうすれば再発を止められるのか。さらに、この仕組みを他社の AI 駆動開発へ持ち出せるのか。本稿は、そのサービス化への現在地を記録する。
🚨 技術的負債より怖い「台帳に存在しない欠落」
技術的負債は、認識できていれば返済計画を立てられる。優先度、影響範囲、期限、再評価条件を台帳に置けるからだ。
本当に危険なのは、必要な品質特性そのものが要件に無く、負債としても認識されていない状態である。
たとえば、API が正常系のレスポンスを返し、単体テストも CI も緑なら、「完成」に見える。しかし本番運用には、その外側がある。
| 「動く」の外側にある問い | 欠けると起きること |
|---|---|
| 外部 API の失敗を分類できるか | 再試行すべき障害と、業務エラーと、恒久障害が混ざる |
| エラーを安定した契約で返せるか | FE・運用・顧客ごとに解釈が分岐する |
| 重要事象を構造化ログで観測できるか | 障害が起きても検索・集計できない |
| Alert の条件式が実ログと一致するか | policy は存在するのに、発火しない |
| 通知先まで到達するか | Alert は発火しても、人に届かない |
| 実際に試験発火したか | 「設定した」を「動く」と取り違える |
この層は、アプリケーション、クラウド基盤、通知経路の境界をまたぐ。どれか1リポジトリのテストだけでは完結しない。そのため、要件に最初から入っていなければ「後で監視を足す」という別プロジェクトになりやすい。
CTS で実際に必要になったのは、GCP の構造化ログと log-based alert、AWS の CloudWatch Alarm、SNS の購読、通知先の確認、そして試験発火による実受信までを1本の完成条件として扱うことだった。
コードが完成したかではなく、異常が起きたときに、正しく分類され、観測され、担当者へ届くかまでが完成である。
🧭 v0.15.2からv0.31.0 — 再発を共通資産へ変えた履歴
この反省を、注意書きの追加だけでは終わらせなかった。実案件で見つかった欠落を、規範、機械可読な契約、決定論ゲート、採用検査へ順に変換した。
| 版 | 実案件が暴いた穴 | ハーネスへ戻したもの |
|---|---|---|
| v0.16.0 | observability の横断規範が無い | 09-observability O-1〜O-6と CI ゲート |
| v0.18.0〜v0.20.0 | 検査未実行が緑に見える、ログ出力自体が業務を止める、監視部品が自己増殖する | O-7〜O-9。検査は fail-closed、実行時ログは fallback つき fail-open、通知層は「ログは厚く・Alertは薄く」 |
| v0.25.0 | EC / POS が同じ依存を別々に分類する | 外部 API エラー契約114行と症状 Alert 契約8行を TSV の単一正本として配布 |
| v0.26.0 | 配布したが利用側で起動されない「第三状態」 | adoption.tsv と doctor。required / conditional / optional を機械判定 |
| v0.27.0〜v0.29.1 | 契約があっても未実装を検出できない。既存負債を一度に赤くすると導入自体が止まる | 未参照コードを赤にする coverage ラチェットと、減る一方の baseline / 期限つき waiver |
| v0.30.0 | 契約 TSV を production が直接読む実装が、ビルドと設計を壊した | D-8。契約は test-time の突合に使い、production はコンパイル時型で表現 |
| v0.31.0 | 散文の申し送りが解釈途中で drift する | ID つき構造化申し送りと doctor D-n の default-deny 追跡 |
v0.25.0 の外部 API エラー契約は、その後の実測で122行まで成長した。増えただけではない。GCP Secret Manager の DEADLINE_EXCEEDED に対する retry 前提が実 SDK と違うことも見つかり、v0.28.1 で訂正した。契約を作った側も無条件には信じず、利用側の実装と SDK の双方から反証を受け付ける。
v0.26.0 のきっかけも象徴的だった。機械にした適用項目は EC / POS で 8/8 実行されていた一方、散文の申し送りで依頼した項目は両プロジェクトとも0件だった。人が怠けたのではない。配布、採用、実行を別状態として機械が見ていなかった設計が悪かった。
v0.27.0 では、契約を配っただけでは Cognito の32コード中、EC は10種、POS は17種しか実装から参照していないことが判明した。文書を置くことと、製品が契約を満たすことは別である。そこで「未分類 = 赤」を coverage ラチェットへ変えた。
そして v0.30.0 では、その契約を真面目に使おうとした POS が、production から TSV を直接読む実行時分類器を作り、ビルドを壊した。原因の一部は、以前のハーネスの申し送りが曖昧だったことにある。POS の誤読として片づけず、ハーネス側の欠陥として D-8 とゲートへ戻した。
POS からの報告、オーナー裁定、規範 D-8、ゲート、EC / POS の実リポジトリ受け入れ、v0.30.0 の出荷までは実質1日だった。さらに POS 側の再作業では、構造的に見えなかった24件を解消し、coverage baseline を 24件から0件へ戻し、同じ月のうちに STG / PROD への反映まで閉じた。
約1か月の手戻りを、次の同型では1日の共通規範化へ変える。この差が、ハーネスを作る理由である。
🔁 商品の本体は「規範集」ではなく、学習を閉じるループ
DDD、SOLID、TDD、セキュリティ、オブザーバビリティのチェックリストだけなら、コピーできる。CLAUDE.md や hook の雛形だけを配ることも難しくない。
しかし、それだけでは CTS-EC から CTS-POS への再発を止められなかった。
必要だったのは、次のループ全体である。
ここで Owner は事業・要件・アーキテクチャの最終裁定者、Lead は調査、実装、独立検証の証拠を集約して裁定点だけを Owner へ上げる AI エージェントを指す。
CTS が他社開発へ持ち出そうとしている商品の本体は、次の2つである。
- 出戻りを機械で止める開発運営システム — 規範、契約、ゲート、証跡、期限つき waiver、構造化申し送りを一体で運用する。
- 実測された欠陥 family の台帳 — v0.31.0時点で backlog 番号は #55 に到達しており、「検証が静かに失われる」「配線済みなのに起動しない」「散文が別解釈を生む」など、個別バグの背後にある再発可能な型を蓄積する。
ゲートは、書かれていることではなく発火したことで評価する。契約も、行数ではなく実装との不一致を止めたことで評価する。改善案も、効果が見えなければ追加せず、害があれば撤去する。
これは 前回 の「測って捨てる設計」を、個々の AI エージェントから組織の学習ループへ広げた形である。
🧑✈️ AIは代替ではなく増幅 — OwnerとLeadの判断を消さない
この構想は、「AI に全部任せれば、経験の浅いチームでも同じ品質になる」という話ではない。むしろ逆である。
AI は増幅器だ。境界づけられたコンテキストを理解し、失敗の分類を裁定し、どの品質特性へコストを払うか決められる Owner がいれば、その判断を高速に実装へ広げられる。判断が無ければ、局所最適なコードと見えない負債を高速に増幅する。
したがって、Owner と Lead の壁打ちループは商品の外へ追い出さない。ハーネスの役割は属人性をゼロにすることではなく、人にしかできない裁定だけが Owner へ届くよう、裁定帯域を圧縮することである。
- テスト、形式、値域、証跡、配線は機械へ渡す
- 既知の欠陥 family はゲートで止める
- 複数の正解があり得る設計判断だけを Owner と Lead へ上げる
- 裁定結果は D-* とゲートへ戻し、同じ判断を次案件で繰り返さない
「AI が書いたから速い」ではない。判断の再利用率が上がるから速いのである。
🧩 LOGI / ADで作る「要件プロファイル」
すべてのシステムへ同じ規範を適用すればよいわけではない。大規模 SaaS、1社専用 SaaS、社内システム、無人バッチでは、必要な DDD 境界、UI、アクセシビリティ、性能計測、tenancy の水準が異なる。
一方で、案件ごとにゼロから選ばせると、再び人の記憶へ戻る。
現在のハーネスは既に、「どこまでやるか」を4軸で表せる。
- 規範の格付け: MUST / SHOULD
- 採用レベル: required / conditional / optional
- 数値閾値: coverage、性能、許容差
- 期限規律: baseline、理由つき waiver、再評価条件
CTS-LOGI / AD では、この4軸に名前つき要件プロファイルを重ねる。プロジェクトが分類を宣言すれば、適用する規範、閾値、ゲートが決まり、見積りと検収の基準線にもなる。
ただし、プロファイルを机上で完成させることはしない。LOGI / AD の実装で必要になった要件を D-* として導出し、ゲートが実際に発火するところまで測ってから共通化する。マイクロサービス、Java、React への対応も同じである。
未経験の構成へ「完全対応」と先に書くのではなく、1件目の実案件で導出し、2件目から再利用できる資産にする。 新しいスタックの1件目は、その導出コストも見積りに明示する。
プロファイルの水準を下げるときも、default-deny、期限つき waiver、理由必須、セキュリティの中核は落とさない。
tierを下げる = 免除を増やす、ではない。対象となる規範自体を減らす。
この違いを守らないと、免除台帳が「本当は必要だが未実装」の置き場になり、再び嘘をつく。
📐 請負開発と相性がよい理由 — 完成の定義を機械で共有できる
時間精算・工数販売を前提とする準委任契約では、出戻りの削減が受託側の売上増加に直結しにくい。発注側と受託側の改善インセンティブが、構造的に揃いにくい。
固定価格の請負では逆になる。受託側が出戻りリスクを引き受けるため、同じ品質をより少ない周回で完成させられることが、そのまま競争力になる。
ただし、請負には「何をもって完成とするか」という難所がある。ここでハーネスが検収基準になる。
要件・受入条件
+ 適用プロファイル
+ AT（受入テスト）
+ DoD（完成の定義）
+ 決定論ゲート全緑
+ 未消化の申し送り・期限超過 waiver なし
= 機械可検証な検収これは「バグが絶対に無い」という品質保証ではない。宣言した検査を実行せずに PASS と扱わないこと、既知の欠陥 family を無言で再発させないこと、未検証領域を未検証のまま明示することを、契約と証跡にできるという意味である。
納品物にも、ソースコードだけでなく次を含められる。
- 適用した品質プロファイルと規範
- ゲートの実行・発火実績
- 欠陥 family の検出・是正記録
- 技術的負債台帳と期限つき残余
- 構造化された版申し送り
「完成しました」という受託側の自己申告を、発注側が信じる契約から、双方が同じゲートを読める契約へ変えられる。
📏 LOGI / ADから測る4つの数字
この構想も、まだ他社案件で実証済みではない。だから、最初から「圧倒的に安い」と結論づけるのではなく、LOGI / AD の初日から次を計測する。
| 指標 | 何を判断するか |
|---|---|
| 出戻り round 数 / 案件 / Phase | 請負価格に織り込むリスクと、再利用による削減効果 |
| ゲート発火数 / 経路 / family | ゲートが飾りでなく、どの再発を止めたか |
| 欠陥 family の新規 / 既知件数 | ハーネス資産の成長率と、既知問題の再発率 |
| Owner 裁定回数 / 週 / 案件 | 1人の Owner が扱える案件数と、裁定帯域のボトルネック |
EC と POS では、同じハーネス・同じ版の比較で 10 round 対 1 run という差が一度観測されている。ただし、これは一般化できるベンチマークではない。案件条件を揃えて LOGI / AD でも継続測定し、初めて値付けと営業の根拠になる。
🔭 現在提供できるもの、これから実証するもの
2026年8月30日時点の境界を、先に明示しておく。
| 領域 | 現在地 |
|---|---|
| .NET / Angular / GCP / AWS の SaaS | CTS-EC / POS で規範、ゲート、契約、通知経路を実測済み |
| LOGI / AD | 要件プロファイルと計装の最初の実験台。これから実測 |
| マイクロサービス / Java / React | 必要になった実案件から D-* とゲートを導出する。現時点で完全対応とは言わない |
| 社内システム / バッチ | 自社案件で1回実証してからプロファイル化する |
| 他社向け | まず1社、自社の opinionated なスタック、請負、品質 SLA つきでパイロットする構想 |
スタック自由の「何でも開発」は目指さない。実測していない品質を、カタログ上の対応可否だけで売らないためである。
一方、実案件から新しい規範を導出し、複数プロジェクトへ戻す仕組みは既に動いている。CTS-EC で見つけ、POS で差分を暴き、ハーネスへ戻し、LOGI / AD は最初から受け取る。その循環を、次は顧客案件まで広げる。
🧾 まとめ — 売るのはAIの速さではなく、同じ失敗を二度しない能力
CTS-EC で約1か月かけて返した負債が、CTS-POS で再発した。オブザーバビリティ、エラー処理、アラート発報は、負債として認識される前の要件から抜け、さらに1か月近い横断対応になった。
この経験から、次の原則が定まった。
- 実案件の欠陥は、個別修正で終わらせず D-*、契約、ゲートへ戻す
- 配布と採用と実行を別状態として追跡する
- observability と Alert を「後付け運用」ではなく完成条件に含める
- AI に判断を代替させず、Owner / Lead の判断を再利用可能にする
- 案件分類を品質プロファイルと見積り・検収の基準線にする
- 出戻り削減が利益になる請負契約で、機械可検証な完成を約束する
AI 駆動開発の競争力は、1回目の実装速度だけでは測れない。
一度払った失敗の授業料を、次の案件では払わない。しかも、払わずに済んだことを証拠で示せる。
これが、CTS-LOGI / AD で実測し、AIエージェント事業として他社開発へ展開しようとしている、CTS のハーネス駆動型 AI 開発である。
📚 シリーズ記事（ステアリング駆動開発・応用編）
第I部: クロスファミリー検証（全6回）
- 総論 — マルチ LLM の2系統と見取り図
- 裏取り編 — +18.1pt 論文の検証
- 設計編 — finder / verifier 分業と逆順禁止
- TDD×ハーネス編 — テスト保護と三層ゲート
- 実装編 — Claude Code の中から Codex を動かす
- モデル戦略編 — ティア割当と「買うか組むか」
本編終章
運用実録
- CI テスト29分 → 5.6分 — 検証エンジンの平時運用
- GPT-5.6 sol 切替 — もう一つのデフォルト追従
- 遊休90%の枠に仕事を振る — Codex上流調査と verifier バッチ化
- ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布
- 69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角
現在地と事業展開
- 「最高品質ですか？」に Yes と答えないハーネス
- 二度の「1か月」を繰り返さない — 技術的負債から育てる AI 駆動開発ハーネス【サービス化への現在地】（本記事）
- ステアリング駆動開発を、ループエンジニアリングで包む — 人の注意力で止めるから、機械の停止条件で止めるへ【v0.32.0】
関連記事
- AI 駆動開発が積み上げる技術的負債 — なぜ AI が短期最適化を増幅するのか
- ハーネスが単一プロジェクトを卒業する — 共通資産として配布できる形へ切り出した過程
- 「最高品質ですか？」に Yes と答えないハーネス — v0.15.2 時点の検証境界
- AIエージェント事業 — Challenge株式会社の開発・導入支援