Challenge株式会社

CTS Development Harness v0.39.1

AIシステム開発 開発ハーネス

TDD・レビュー・品質ゲート・停止条件を一つの開発ループへ統合し、AIの速度と受入条件に基づく再現可能な品質を両立します。企業ごとの要件に合わせて調整し、社内チームへの定着まで支援します。

CTS Development Harness v0.39.1

Anthropicのループ設計12観点で、11観点を充足

Anthropicの公開ガイドに示された長時間稼働エージェントの設計要件を12観点へ分解し、CTSのハーネスを自社採点。11項目を充足し、配線済みで未起動の項目は無くなりました。残る1項目は実装ではなく裁定で、v1.0.0を目前にしています。

停止条件は、止める条件より先に「止まった後の経路」から設計します。大きいrunは起動前に理由つきの承認を求め、合格後の是正は差分だけを再レビュー。v0.39.1では、runの重さを起動前に測る検査と、費用の外枠としての定額上限を加えました。

技術が変わっても、開発ループは変えない。

ハーネス設計を切り替え、Java、React、Vue、iPhone(iOS)、Androidにも迅速に対応できます。

JavaReactVueiPhone / iOSAndroid

11

充足

0

部分充足

1

未充足

※ Anthropicによる認定・監査ではなく、同社の公開ガイドから抽出した評価観点に基づく当社の自己評価です。未充足項目も含め、根拠を技術記事で公開しています。

01

要件と受入条件を先に固定

「何を作るか」と「何をもって完成とするか」を、実装前にテスト可能な条件へ落とし込みます。

02

TDDと決定論的な品質ゲート

AIの自己申告ではなく、テスト、静的解析、ビルド、契約検査、依存脆弱性スキャンの実行結果で品質を確認します。

03

運用まで含めた完成条件

セキュリティ、エラー処理、ログ、監視、アラートまでを後付けにせず、開発時の要件に含めます。

04

実案件の教訓を次へ再利用

見つかった欠陥を個別修正で終わらせず、共通ルールとゲートへ戻し、別案件での再発を防ぎます。

05

企業ごとの要件・基準へ調整

機能要件に加え、セキュリティ、性能、可用性、運用などの非機能要件を、企業の技術構成と品質基準へ合わせます。

06

内製チームへ導入・定着

テンプレート、開発ルール、レビュー方法、品質ゲートの運用を社内チームへ移し、継続改善できる体制づくりを支援します。

07

周回上限と進捗なし検出

同じ状態での再実行や上限を超えた周回を機械的に止め、止まった理由を定型コードで記録。人の注意力に依存しない運転層を持たせます。

08

承認はクレジットを使う前に

変更規模が目安を超えるrunは起動前に止め、理由つきの承認で進めます。途中で止めて最初からやり直す停止は採らず、トークン使用量は計測と警告で記録します。

09

合格後の是正は差分だけ再レビュー

前回合格したレビュー証跡以降の差分だけを再レビューし、軽微な是正のたびにrunを丸ごと回し直すトークン消費を抑えます。

10

レビュー済みのコードだけを出荷

証跡に記録したレビュー対象のハッシュをCIとpush時に再計算し、レビューしていない修正が出荷に紛れ込む経路を塞ぎます。

11

runの重さを起動前に測る

編集するファイルの宣言を必須にし、多すぎるrunは起動前に止めます。1回のrunを小さく切り、時間で打ち切るときも変更と申し送りを残して終えます。

12

費用にも停止条件を置く

定額プランの上限を最も外側の停止条件にし、追加購入はしません。使いすぎの結果は請求ではなく待ち時間になり、runごとの消費は台帳に残します。

LOOP RECORD

1本の開発セッションが、49時間続いた

自社サービスの開発で、Claude CodeとCodexを使った1本のセッションが49時間続きました。続いたのはモデルが賢かったからではなく、会話が何度途切れても文書から再開でき、止まるべき所では起動前に止まり、人が戻るまで待てる構造があったからです。人の発言は40回で、その半分はCIの失敗対応と訂正に使われています。ループは人の判断を置き換えず、判断する場面をまとめます。

AIの費用は、開発者1席あたり月約5万円の定額です。同じ量をAPIの定価で払うと約35倍になる計算で、定額の上限を最も外側の停止条件として使っています。

49時間

1本の開発セッション

実際に動いていたのは約37時間

93本

Codexの実装run

調査runは別に17本

4本

検証ワークフローPASS

全量レビュー3本・差分1本

2本

マージしたMR(PR)

pushは9回

8回

コンテキスト圧縮を越えて継続

状態は会話ではなく文書に持つ

月約5万円

AI費用(開発者1席)

定額2契約・追加購入なし

※ 2026年10月2日14:30〜10月4日15:34、自社サービスのセッション記録から集計。30分以上の空白が合計約12時間あり、実際に動いていた時間は約37時間です。費用は2026年10月時点の契約額です。定額の上限に達し、13時間止まった週もあります。

CODE REVIEW

人間ゲートから、決定論ゲートへ。

AIにコードを書かせるところまでは、多くの現場で動き始めています。それでも効率が思ったほど上がらない。理由の多くは、マージリクエスト(GitHubではプルリクエスト)の手前にあります。AIが数分で書いた差分を、人が読んで合否を決める。この「人間ゲート」に、差分が並びます。

当社は、合否を人の目視で決めません。テスト、カバレッジ、静的解析、契約検査、依存脆弱性スキャンの実行結果で決めます。レビューはAIが全量で行い、人は差分を読まず、ゲートの結果と方針を判断します。ウォーターフォールからアジャイルへ移ったときと同じ、開発スタイルの転換です。

WHY

人のレビューは、AIの速度に追いつかない

  • 01AIは差分を数分で出します。人が読んで判断する時間は、差分の量に比例して増えます。書く速さだけが上がると、待ち行列ができます。
  • 02読む量が増えるほど、レビューの精度は下がります。「見たことにする」レビューは、ゲートとして機能していません。
  • 03人の注意力に依存した合否は、再現できません。同じ差分でも、日によって通ったり止まったりします。

WHAT

決定論ゲートが判定するもの

  • ✓テストとカバレッジ — 受入条件から先に書いたテストが通り、カバレッジが閾値を超えているか
  • ✓静的解析・ビルド・契約検査 — 型、規約、API契約の整合を、実行結果で確認する
  • ✓依存脆弱性スキャン — 推移依存を含む依存木を、マージ前のCIで既知の脆弱性データベースと突き合わせ、検出すればマージに乗らない。人が差分を読んでも見つからない。例外は期限と理由を台帳に残す
  • ✓AIによる全量レビューと証跡 — 実装とは別のAIが差分をレビューし、証跡を残す。合格後の是正は差分だけを再レビュー
  • ✓CIでの証跡ハッシュの再計算 — レビュー対象のハッシュをCIとpush時に再計算し、レビューしていない差分はマージに乗らない
  • ✓停止条件 — 周回上限、進捗なし検出、runの規模を機械が止め、止まった理由を定型コードで記録する

CASE — 2026年10月

ライブラリの脆弱性は、ゲートで監視して初めて、すぐ動ける

脆弱性の勧告は、こちらの都合に関係なく公開されます。使っているライブラリを人が覚えていて、勧告を読み、影響を調べる運用では、気づくのが遅れ、対処はさらに遅れます。当社は、推移依存を含む依存木をマージ前のCIでスキャンし、検出すればマージを止めます。勧告が公開された後、最初のパイプラインが赤になります。

2026年10月7日、自社サービスが使う画像ライブラリに脆弱性勧告5件(High 3)が公開されました。ゲートがビルドで検出して止め、翌8日には修正版へ更新してマージしています。警告を抑止して旧版に留まる案は、ゲートが抑止設定を見ないため採れません。勧告から対処までが1日で閉じたのは、ゲートが依存木を見ていたからです。

合否は、機械が

テスト、カバレッジ、静的解析、契約検査、依存脆弱性スキャンの実行結果だけで決めます。AIの自己申告は信じません。同じ差分なら、同じ結果になります。

レビューは、AIが全量で

人が読める量に合わせて差分を間引きません。全量を読み、証跡のハッシュをCIが再計算。レビューしていない差分はマージに乗りません。

判断は、人が

受入条件の合意、方針と優先順位、起動とpushの承認、例外の裁定。差分を読む工程は、人の仕事から外します。

FOUNDATION

決定論ゲートは、土台があって初めて動く

機械が合否を決めるには、機械が読める判定材料が要ります。TDDと受入条件、カバレッジ、エラー処理、アラート、ログとメトリクスによるオブザーバビリティ。これが無い環境では、結局人が読むしかありません。

この土台を先に作るのが、内製化支援の最初の仕事です。開発環境レビューで現在の土台を確かめ、PoCで1機能にゲートを通してから、開発チームへ広げます。

MINDSET

チームで変わること

  • →受入条件を、実装の前にテストとして書く
  • →レビュー会で差分を読むのをやめ、ゲートの結果を見る
  • →見つかった欠陥は、個別修正で終わらせず、ゲートへ戻す
  • →止める判断をAIに任せず、停止条件をコードで持つ

レビューを減らすのではなく、人が読む工程をなくす。合否は機械が、判断は人が。

ご相談から検収・運用まで

内製化支援

お客様の開発環境に合わせた、Development Harnessをお作りします。秘密保持契約を結んだうえで現在の環境を見て、小さく試し、効果を確かめてから開発チームへ広げます。

  1. 01

    開発環境レビュー

    20万円〜(税抜)

    秘密保持契約を結んだうえで会社を訪問し、開発環境(リポジトリ、CI、テスト、レビューの流れ)と開発メンバーの体制・スキルを調査。ハーネスで何を機械に任せられるかを整理し、内製化計画の立案までを行います。

  2. 02

    PoC(テストハーネス作成)

    対象を1機能に絞り、テスト、品質ゲート、停止条件を組み込んだハーネスを試作。お客様の環境で実際に回し、効果と課題を確認してから次へ進みます。

  3. 03

    見積・スケジュール・契約

    PoCの結果をもとに、調整範囲、成果物、マイルストーンを固定価格で提示します。人数や作業時間ではなく、合意した成果物と品質ゲートの通過で検収します。

  4. 04

    開発チーム用ハーネス、開発スタート

    開発チームの技術構成と開発ルールに合わせてハーネスを仕上げ、テンプレート、レビュー方法、ゲートの運用を移管。社内で開発を続け、改善できる体制まで支援します。

開発環境レビューは、20万円(税抜)から承ります。

会社訪問、開発環境・メンバーの調査、内製化計画の立案までを含みます。調査の前に秘密保持契約を締結し、お預かりした情報は計画の立案以外に使いません。PoC以降は、計画をもとに範囲と成果物を決めて個別にお見積りします。ハーネスの調整と社内チームへの定着は、請負開発とは別にご契約いただけます。

開発では外部の生成AIサービス(Anthropic、OpenAI)を利用します。送信する情報の範囲、学習への利用の有無、除外する情報(個人情報・認証情報等)は、秘密保持契約と合わせて契約書に定めます。

内製化支援について相談する

AIを使うシステムを、AIでつくる。

請負開発だけでなく、社内チームでAI駆動開発を続けるためのハーネス調整・定着支援もご相談いただけます。まずは、現在の開発体制と技術構成をお聞かせください。