dev-harness とは何か

1.何を作っているか（30秒でわかる版）

AI に開発作業を頼むと、AI は最後に「できました」と報告してきます。でも、この報告はしばしば当てになりません。頼んだことが抜けていても、本人は気づいていないからです。

だからこれまでは、人間が AI の成果物を毎回レビューして、直しを指示する必要がありました。実は、ここが一番時間を食うところです。

いま作っているのは、この「本当にできたのか？」の確認を人間の代わりにやる仕組みです。

• AI の成果物を、作った本人とは別の AI が採点する
• 合格か不合格かは、最後に計算機が数字で判定する（人の気分も AI の自己申告も入らない）
• 判定の記録は全部ファイルに残り、あとから誰でも確かめられる

これを開発会社に商品として提供するのがゴールです。

2.なぜこれが商売になるのか

開発会社のいまの悩みはこうです。

• AI のおかげでコードを書くのは速くなった
• そのぶん、人間の確認作業（レビュー・検品）が渋滞するようになった

一方で、AI 本体はどんどん賢くなるので、「AI をうまく動かすコツ」だけを売っても、すぐに価値がなくなります。

最後まで残る価値は、「その会社では何を合格とするか」という基準と、それを毎回きっちり検査する仕組みです。これは会社ごと・案件ごとに違うもので、よそから買ってくることができません。

だからこの商品は、道具そのものより「お客さんが自分の合格基準を育てられる仕組み」を中心に据えます。

3.仕組みの核 — 3つの原則

この仕組みの設計は、まさおさん（数百本のスキルを作り込んできた実践者）の考え方を土台にしています。核になる原則は3つです。

原則1: 作った本人に採点させない

自分で書いた答案を自分で採点すると、必ず甘くなります。AI も同じです。だから「作る AI」と「採点する AI」を完全に別にします。採点係は、作業の経緯や言い訳をいっさい知らないまっさらな状態で、成果物だけを見て採点します。テストの実行も自分でやり直し、報告を鵜呑みにしません。

原則2: 合否は計算機が数字で決める

採点係が付けた点数が合格ライン（例: 90点）以上かどうかを、小さなプログラムが数値比較して決めます。「たぶん大丈夫」「もう十分でしょう」という気分が入り込む余地をなくすためです。AI は提案と作業をする係、合否・記録・ルールの番人は機械、という分担です。

原則3: 合格基準はお客さん自身のものにする

道具（エンジン部分）はこちらが保守します。でも「何を合格とするか」の基準・守るべきルール・過去の失敗メモは、お客さん専用のフォルダに置き、お客さんが自分の言葉で育てます。

これには理由があります。人は他人が作ったものに愛着を持てないからです。自分で育てた基準は自分の資産になり、使い続ける動機になります。（お客さんが基準をいじって壊しても大丈夫なように、決まりから外れた書き方は機械が自動で見つけます）

おまけ: AI の「ズル」を防ぐ仕掛け

AI は点数を上げる近道として、基準のほうを緩めることをやりがちです。テスト勉強をせずに、問題のほうを簡単に書き換えるようなものです。だからこの仕組みでは、

• 採点係は基準ファイルを書き換えられない
• 採点項目を勝手に増やしたり減らしたりした採点表は、点数に関係なく無効
• 点数が合格ライン未満なのに「合格」と自己申告したら、それも無効

という検査を機械側に入れてあります。

4.まさおさんの考え方から、ほかに借りているもの

3原則のほかにも、次の作法を取り入れています（それぞれ1行の「なぜ」つき）。

• 部品の名前だけで役割がわかる命名ルール — 名前が約束になっていれば、中を読まなくても安全に使えるから
• 説明書は短く、いちばん大事なことは冒頭に — 長い説明書は肝心なところが埋もれて読まれないから
• AI がもともと知っていることは書かない — 書くほど、この会社固有の大事な指示が薄まるから
• 同じ失敗を繰り返したら、注意書きでなく機械の検査に昇格させる — 注意力で防ぐより、機械で100%防ぐほうが安いから
• 状態はチャットの流れでなくファイルに残す — 途中で止まっても、誰が引き継いでも、続きから再開できるから

5.実際に動いた例（初回の検証・2026年7月10日）

題材: 電卓プログラムに「中央値（真ん中の値）を計算する機能」を足す、という小さな仕事。

1. 依頼書を1枚書く — 「何を作るか」「触っていい場所はどこか」「合格条件6個」（テストが全部通る、元のデータを壊さない、など）を書く
2. 作る AI が実装する — 触っていい場所の中だけでコードとテストを書いた
3. 採点する AI が採点する — 別モデル（Opus）が、依頼書と採点表を照らし、テストを自分で実行し直して、4項目で採点 → 100点
4. 計算機が判定する — 「100点 ≧ 合格ライン90点」を数値比較して 合格
5. 記録が残る — 採点表・点数・判定・根拠が全部ファイルに残った

この間、人間がやったのは依頼書を書くことだけ。成果物のレビューはしていません。

仕組み自体の健全性チェック（自己テスト7項目）も全部通っています。「壊れた採点表を渡したら無効にできるか」「点数不足の自己申告『合格』を弾けるか」まで機械で確認済みです。

6.進め方 — 一気に作らない

前に、一気に作りすぎて全体を把握できなくなったことがありました。今回は1段ずつ、動くことを確認してから次に進みます。

段を上がる条件は毎回同じ: 「自己テストが全部通る」+「実際の仕事を1本流して合格する」。

• 段0（完成✅）: 1回きりの流れ。依頼 → 実装 → 採点 → 機械判定 ← いまここ
• 段1: 不合格だったら、指摘をもとに自動でやり直す（合格するまで回る）
• 段2: 受け入れ試験を本物の環境で行う（実際の画面・実際の端末で確かめる）
• 段3: お客さんが自分で基準や部品を安全に増やせる補助を作る（商品価値の本丸）
• 段4: 配れる形に整え、効果を数字で示す（変更1件あたりの費用、一発合格率）

7.次にやること（あなたの判断待ち）

1. 実際の案件の仕事を1本、この仕組みに流してみる（おすすめ。実戦のズレを早く見つけられる）
2. 段1（自動やり直し）の開発に進む
3. 保存（コミット）の仕方を決める — 「初回検証の分」を分けて保存しておくと、巻き戻せば営業デモとして再利用できます

付録: 物の場所