AIにコードを書かせるだけでは足りなかった

生成AIを使えば、以前よりずっと速くコードを書けるようになりました。

私自身もAIを利用しながら、画像や文書を扱うMedia Analysis Engine（MAE）、大量のスクリーンショットを管理するScreenshot Library、学習資料を扱うMultimedia Study Noteなど、複数のローカルシステムを個人で開発しています。

ところが開発規模が大きくなるにつれ、一つの問題が無視できなくなりました。

AIがコードを書けることと、そのコードが自分の実環境で正しく動いていることは別の問題です。

AIはもっともらしい実装を生成できます。しかし、存在しないAPIを前提にしたり、過去と現在の仕様を取り違えたり、実際には検証されていないものを完成したように扱ってしまうことがあります。

そこで現在は、AIの回答そのものではなく、

実際に何が実行され、何が確認され、その判断をどの証拠から再確認できるか

を中心に開発を進めています。

ここでは、この方法を Evidence-Driven Development（証跡駆動開発） と呼びます。

AIを使わない方法ではない

Evidence-Driven Developmentは、AIを信用しないための方法ではありません。

仕様整理、コード生成、PowerShell Wrapper生成、調査、失敗原因の分析など、多くの作業をAIに任せています。

ただし、一つ境界を置きました。

AIには実装候補を作らせる。しかし、AI自身には「実装が成功した」と決めさせない。

成功したかどうかは、実際のPCでコードを動かし、Runtime Resultを取得し、その結果をEvidenceとして確認してから判断します。

基本的な流れは次の通りです。

Specification Freeze
        ↓
Implementation
        ↓
Runtime Verification
        ↓
Evidence
        ↓
Formal Baseline
        ↓
Next Slice

まず今回実装する範囲を固定します。それを実装し、実環境で検証し、証跡を保存し、確認された状態をBaselineとして固定してから次へ進みます。

AIが作るのはコードだけではない

特徴の一つは、AIにPythonなどのImplementationだけを書かせて終わらないことです。

実装Artifactと、それを実環境へ適用・検証するためのPowerShell Wrapperをセットで扱います。

                 AI
                  │
          Specification Freeze
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
 Implementation        PS1 Wrapper
 Python etc.                │
                            ▼
                     Real Environment
                            │
                  ┌─────────┼─────────┐
                  ▼         ▼         ▼
                Install   Verify    Capture
                                      │
                                      ▼
                                   Evidence
                                      │
                                      ▼
                                  Formalize
                                      │
                                      ▼
                               Formal Baseline

PowerShellは単なる起動スクリプトではなく、AIが生成したArtifactと実際のWindows環境をつなぐOrchestration Layerとして使っています。

手作業でファイルをコピーし、部分的に書き換え、目視だけで結果を確認していると、後から「実際に何をしたのか」が分からなくなります。

そこで、可能な範囲で導入・検証・Evidence取得をPS1から再実行できる形にします。

「動いた」ではなく、何が動いたのかを残す

テストがPASSした、という情報だけでは十分ではありません。

実装Artifact、Runtime Result、Evidence、履歴、Baselineを分けて残し、「どの結果を根拠に、どこまで確認済みとしたのか」を追跡できるようにします。

Specification
     ↓
Implementation Artifact
     ↓
Runtime Result
     ↓
Evidence
     ↓
Provenance
     ↓
History / Roadmap
     ↓
Formal Baseline

必要な場合はハッシュも記録し、後から対象Artifactを識別できるようにします。

この方法は、実データを使ったTuningでも利用しています。重要なのは「調整した」という事実だけではなく、どのRuntime Resultを根拠に状態を進めたのかを残すことです。

Evidenceは成功を証明するためだけではない

もう一つ重要なのが、分からないことを、分かったことにしないことです。

AIとの開発では、情報が不足している部分を推測で補うと、その推測を前提として次の実装が積み上がってしまうことがあります。

そこで使っているのが、

GAP = STOP
DoNotGuess = TRUE

という考え方です。

調査してもRuntime上の接続や実装主体を確認できなければ、「おそらくこうだろう」と確定させません。確認できた部分と、まだ確認できない部分を分けて記録します。

Evidenceとは成功を証明するだけのものではありません。

「ここから先はまだ分からない」という境界を残すこともEvidenceの役割です。

失敗したときほど証跡を残す

成功時は、

SUCCESS
   ↓
Evidence
   ↓
Formal Baseline
   ↓
Next Slice

と進みます。

一方、失敗した場合は、

FAIL
  ↓
Failure Evidence
  ↓
Failure Routing
  ↓
GAP = STOP
  ↓
Authority Investigation
  ↓
原因確定
  ↓
次のSpecification

へ戻します。

失敗箇所、参照すべき履歴、再開位置などを残しておけば、AIとのセッションが変わっても調査を再開しやすくなります。

実際、既存モジュールに存在しないAPIを前提にVerifierを作ってしまい、Runtime Verificationで失敗したこともありました。その際は、似たAPIを推測して修正するのではなく、既存Authorityの公開契約をread-onlyで確認する工程へ戻しました。

AIが間違えること自体よりも、その間違いを検出できないまま次へ進むことの方が危険だと考えています。

MAE、Screenshot Library、Multimedia Study Note

この方法を使って育てている中心的なシステムの一つがMedia Analysis Engine（MAE）です。

また、大量のスクリーンショットを検索・分類・参照するScreenshot Library、学習資料を扱うMultimedia Study Noteも開発しています。

現在は、この3システムを一つの巨大なデータベースへまとめるのではなく、それぞれのSource of Truthを維持したまま連携させる方向で統合を進めています。

概念的には次のような構造です。

Screenshot Library ─┐
                     │ read-only
Multimedia Study Note├──→ Evidence / Integration Layer
                     │             │
Existing MAE DB ─────┘             ▼
                         MAE Intelligence Layer
                                   │
                                   ▼
                                Proposal
                                   │
                              Suggest Only
                                   │
                                   ▼
                              Human Review

元画像や文書を統合側へ複製するのではなく、参照、Evidence、提案、判断、監査状態などを扱う設計です。

AIには提案させ、人間が決定する

この考え方は開発工程だけでなく、アプリケーション内部にも現れています。

AIが解析したからといって、すぐにSource of Truthを書き換えるのではありません。

Evidence
   ↓
AI Analysis
   ↓
Proposal
   ↓
Rationale
   ↓
Human Review
   ↓
Decision
   ↓
Commit

「AIが判断した」という事実と、「その判断を採用する」という行為を分離します。

Screenshot Reviewの仕組みでも、Classification、Confidence、Rationaleを人間が確認し、判断をレビューできる形を試しています。

未完成もそのまま残す

長期のAI開発では、

• 以前どこまで完成していたのか
• 実装済みなのか、構想だけだったのか
• Runtimeで確認したのか、AIが提案しただけなのか

が分からなくなりやすいと感じています。

そのため、未完成部分も NOT_YET やGAPとして残します。

完成したように見せることより、確認済みと未確認の境界を維持することを優先します。

Evidence-Driven Developmentを一言で表すなら

現在の考え方を単純化すると、こうなります。

AI Output
   ↓
Unverified Candidate
   ↓
Runtime
   ↓
Evidence
   ↓
Verification
   ↓
Verified State
   ↓
Formal Baseline

Evidenceが不足している場合は、

Unknown
   ↓
GAP
   ↓
STOP

とします。

私にとってEvidence-Driven Developmentとは、

AIによって開発速度を上げながら、AIの不確実性をRuntime Evidenceによって管理するための開発方法

です。

個人開発が少しずつつながってきた

最初から巨大な統合AIシステムを作ろうとしていたわけではありません。

スクリーンショットを探す問題からScreenshot Libraryが生まれ、学習資料を扱うためにMultimedia Study Noteを作り、画像・文書・OCR・検索・AI解析を扱うためにMAEを育ててきました。

AIとの開発が複雑になればEvidenceを残し、継続できるようHistoryやRoadmapを残し、推測を防ぐためGAPで止め、再現しやすくするためPS1をOrchestratorとして使う。

個別の問題への対応が、少しずつ現在の形につながってきました。

このブログでは完成品だけでなく、その途中で起きた失敗、設計変更、検証方法、そして過去の開発記録も少しずつ整理していく予定です。

個人とAIが長期間一緒にシステムを作り続けるには、どのような仕組みが必要になるのか。

その試行錯誤自体も、一つの成果として残していきたいと考えています。