受入系列を commit c60fa71 に固定し、ローカル Ollama agentteam-qwen35-9b-16k で、実際のリポジトリ資料を使う系列を再確認しました。v18の第1・2回は旧配信契約では機械検証とReviewer提出を通過しましたが、「パイン」「ロカル」「アデュータ」「actual-source」などの翻訳崩れを確認したため停止しました。v18証跡を保存し、現行コードで検出語と領域別根拠語を拒否する修正を入れています。修復例を追加したv20も1回実行しましたが、「パイン」「ステール」「演算主体」などが残り現行契約でfailとなり、Reviewer前に停止しました。v20証跡。現行の決定論的テストは 107 passed / 1 skipped です。10回と意味品質の独立評価が完了するまで同一業務の反復条件を満たしたとは扱わず、L2/L3も未達のままです。
L1の紹介資料は揃っていますが、指定された「同じデモを10回」の条件は未達です。L2・L3は未到達です。 他の5製品の実装をこの評価で監査したわけではありません。達成率の推測値は使いません。
実資料を使ったローカルQwenのv3系列は3実行分を保存しました。旧ランタイムの機械判定とReviewer判定が合格でも、現行の依頼者Schemaで再監査すると3実行とも日本語の語崩れ・英語コピーが残り、L1の反復受入には数えていません。失敗証跡はここにあります。強化契約のv6〜v10も実モデルで実行し、英語コピー、長時間model call、必須語不足、計画誤りを検出して停止しました（v6、v7、v8、v10）。v11はrun 1・2が修正版と独立Reviewerをpassし、run 3はSchema不合格後にpartial停止しました。受入済みは2/10で、10回条件は未達です（v11）。v12 run 1も旧契約では実Ollamaで修正版と独立Reviewerをpassしましたが、後から「キーcloak」「パインされた」「バックス」を検出したため、最新契約で再監査すると不合格となり、次系列で拒否する契約回帰テストを追加しました。run 2はremaining英語コピーと必須語不足のまま1200秒でinterrupted、run 3も系列停止時にinterruptedとなりました（v12）。旧契約でのv11/v12合計は3/20ですが、現行契約での受入済みは2/20です。10回条件は未達です。現行mainには、この再発を自動終了でも拒否するSchemaと、Reviewerが保存済みSchemaを直接使う経路を反映済みです。
代表用途は「公開された3ページを比較し、出典付きメモをレビューして、修正履歴と未確認事項を引き渡す」です。
| 条件 | 現状・根拠 |
|---|---|
| 30〜90秒の実動作デモ | 32秒の実モデル記録再生。合成ナレーション付き。ライブ処理の所要時間は約24分 |
| 代表ユースケース | 公開資料の比較メモ。上記動画と操作できる記録で確認可能 |
| 同一デモ10回 | 未達。現在のバージョンと設定を固定した10回連続の実行記録が必要 |
| 制約説明 | 出典照合未検証・予算によるpartialをデモで明示。一般的な品質優位は未証明 |
| コスト | デモは約$6.07定価換算。用途別の記録はSTATUS。顧客価格・請求額とは異なる |
| データ送信先 | ローカル保存。クラウドモデル利用時は入力が接続先へ送信される。SECURITY |
| 失敗時の表示 | partialと未検証を確認できる実記録あり。あらゆる誤完了を防ぐ保証はない |
| 原因調査のログ | デモの171イベント、成果物revision、レビュー結果を公開 |
| README / Site | 起動方法・実画面・制約を掲載。3分で理解できるかの外部ユーザ評価は未実施 |
| Business CTA | 導入相談あり。今回、架空の問い合わせ送信は行っていない |
| License | MIT |
| テスト証拠 | 実モデル比較・Reviewer監査と実行結果からの修正。認証・SSO・永続実行・削除/暗号化復元・監査収集・実行境界を追加。実資料の初回試験では誤完了と翻訳誤りを発見し、元の失敗記録と修正後の101件passを保存。既存の50課題には架空製品や合成データが含まれるため、新たな受入試験は実際のリポジトリ資料を使用する。自動テスト数や旧ベンチマークを実企業データでの業務成功率に置き換えない |
企業への説明文:
ローカルで動くAIチームが、調査・成果物作成・レビュー・修正を進め、その版を何で確認したかを記録します。公開資料を使った実行例を、未完了になったケースも含めてお見せできます。業務に適用する際は、対象作業と合格条件を絞って検証します。
本番導入に向けた実装状況はProduction acceptance planと導入・復旧手順で管理します。認証・権限・保存領域の制御、更新/復旧手順を追加しましたが、実資料の反復試験はまだ失敗・停止中であり、これだけでL2/L3達成とは判定しません。
既存の予算制御・承認・サンドボックスだけでL2とは判定しません。以下を顧客ごとの環境で検証してから受入条件を満たしたと判断します。
| 領域 | 次に必要なもの |
|---|---|
| 認証・分離 | 企業認証、ユーザ別workspace、組織とテナント間のアクセス拒否検証 |
| 秘密・送信先 | 鍵の保管と更新、モデル固定、許可接続先、送信データの説明 |
| 保存・削除 | 保存先・保持期間・削除とバックアップの扱い |
| 業務接続 | 対象業務で必要なconnectorを1つ選び、権限と失敗時挙動を検証 |
| 承認・費用 | 誰が何を承認するか、ユーザ/組織別予算、停止と復旧の運用 |
| 契約する範囲 | 限定ユースケース、合格条件、運用責任、未対応機能 |
キュー・workerの拡張、HA、障害復旧、中央監査、RBAC、組織ポリシー、監視、SLO/SLA、インシデント対応は別の到達条件です。現在の単一プロセスの実行基盤に、本番可用性を約束する説明は付けません。
- ローカルOllamaの結果からの修正と別比較試験を実施。Claudeの79ペアは履歴として残し、ローカル結果で埋めない。残るレビュー修正上限も別途原因を確認する。
- 公開資料の代表業務を現行版で10回。依頼・設定・commitを固定し、成功/partial/失敗、成果物の正確性、費用、時間、介入を記録する。
- Reviewerの採点を、単語への一致から根拠付きの指摘判定へ移行。正しい文書の対照群も含め、検出と誤検出を分ける。
- その結果でL1判定を更新する。顧客データのPoCは上記L2の不足を対象業務に合わせて埋めてから進める。