背景

• 人はAIには勝てず、人は金魚になるべきである

• I’m a goldfishで書いた、通り、これはAIの高度な思考方法を目にした自分の結論
• AIは、keenな論理的思考法、圧倒的知識のカバー率、デカルトレベルのDoubt、どれをとっても人間は勝てない
• AIは数万文字を一瞬で読むのに、論文一つ読ませても、深いレベルで理解して解説できる
• 人間はオワコンとなっている
• しかし、人間もCheckや理解をしないとAIがやっている事が正さがわからない
• 人間が検証可能かつ正しい解答を出す、AIと伴走する開発の方法論が必要
• アイディアのもとはブロックチェーンやGitコマンドにある

実験駆動開発

バイブコーディングの課題

バイブコーディングには次のような課題がある:

• AIの労働量が早すぎて、人間のレビューができない
• AIの知能に人間がついていけないため、AIと人間だと深い議論になりにくい
• AIが言った事、やっている事が高度な時に、人間が後々でそれを学習できない

つまり、「今どうなっているか（結論）」と「なぜそうなったか（追跡）」、「人間の知能やマンパワーが足りない」などが問題。

実験駆動開発とは

実験駆動開発とは、対象を仮説として立て、AIとの1回1回の試行・結果をmdのログとして保持しながら進める開発手法。会話そのものより、仮説と実験の繰り返しの方が本質なので、会話駆動ではなく実験駆動と呼んでいる。

そのためには、AI同士をログを残した状態でdiscussionして開発をする必要がある。

つまり、次を可能にする:

• AI同士で議論させる => マンパワー解決
• AIの作業記録を残す => なぜそうなったかがわかる
• 正本管理をする => 今どうなったかがわかる

Lab

Labの作り方

• まず、AIとのすべての会話のメッセージをMarkdown化して記録する
• lab/というディレクトリの下に、docs/とmsgs/という2つのサブディレクトリを持つ
• 形式
  • docsはdocs/{3桁連番}_{slug}.mdという形式。番号は作成順の恒久的なIDで、内容は直接書き換えていく
  • msgsはmsgs/{3桁連番}_{slug}.mdという形式。一度作ったら書き換えない
  • 連番はdocs・msgsそれぞれのディレクトリ内で別々に管理する
• これを徹底して、複数のAIの会話をこのMDに落とし続ける

以下がLabのディレクトリ構成の例。

1
2
3
4
5
6
7
8
9

lab/
├── docs/
│   ├── 001_spec.md                       # specトピックの現時点の正本（直接書き換える）
│   └── 002_backlog.md                    # backlogトピックの現時点の正本（直接書き換える）
└── msgs/
    ├── 001_dictionary_analysis.md        # レビュー依頼
    ├── 002_root_cause_review.md          # レビュー依頼
    ├── 003_review_response.md            # 002への回答
    └── 004_naming_convention_update.md   # docs/msgsの命名規則自体の変更記録

docsという名前は、中身が仮説なのか実験結果なのかbacklogなのかを問わず使える、構造だけを表す名前にしている。仮説（hypo）や実験（exp）のような、用途に特化した名前にすると、別の種類のドキュメントを増やしたくなった瞬間に名前と実態がずれるため、あえて汎用的な名前にしている。

これによって、AIの一切の会話がすべてmdに落ちるので、透明性と追跡性、そして再検証性など生まれる。

docsとmsgsの意味

• docs（Stack）: トピック（spec、backlogなど）ごとに持つ、常に最新の内容が「今の正本」になる、継続的に更新される生きたドキュメント
• msgs（Flow）: 1回の試行・結果の時系列ログで、一区切りごとに1ファイルを必ず作成する、時間とともに流れていく情報

両者の違いを表にすると以下の通り。

つまり、「今どうなっているか（結論）」と「なぜそうなったか（追跡）」、がわかる仕組み。

mdはIMRaD形式にする

• msgはIMRaD（Introduction・Methods・Results・Discussion、結論を加えることも多い）形式を強制する
• 背景・手法・結果・考察・結論、そして参考文献という形式に蒸留し直す
• 特に、参考文献に過去のmsgやdocs、コードなども引用してもらう事で探すのが楽になる
• これらの科学的方法論をベースにすることで、ここの会話で行われた実験の検証性や透明性を担保する

開発フロー

開発フローは、主にinitとloopの2stepsに分かれる。

init: 管理AIとテーマを決める

AI同士に作業させるため、管理用のAIと、やりたいことをまとめたテーマや仮説を先に作る必要がある。

• まず、開発でTTPする対象を決める
• これは、ある論文の再現だったり、あるシステムだったりする
• そして、それを構成要素に分解して、要素ごとに数値化する
• その上で、その数値を達成目標にして仮説とする
  • これはマイルストーン、検証項目、達成目標などでもOK
  • もしくは、REQ-1, REQ-2のような要件を文章化し、その要件文章の文単位で要件IDをふって細かく管理手法もあり
• この仮説（正本）を徹底的に管理AIと人間（自分自身）で討論する
• この時点で、この仮説を討論したAIは自分の分身となる
• なぜなら、仮説について自分レベルで理解しているから

この仮説が開発のバイブルになり、これの理解を徹底的にしている事が大切。

loop: 作業AIと実験する

作業AIを別途用意して、先程作った管理AIと仮説を使って実験を進める。

アルゴ:

• 作業AIを用意して、作業AIに仮説を渡す
• 作業AIには実験が終わったらmsgを残してもらう
• そのmsgを管理AIに渡して指示をもらう
• 管理AIのレスポンスを作業AIに渡す
• その繰り返し

つまり、人間はメッセンジャーになる。

subissue: 別のテーマ化する

進捗が悪い時は以下の対処方法で対応する

• クリティカルパスじゃない場合:
  • backlogに追加してfuture workとする
• クリティカルパスの場合:
  • そのissueを別途テーマとして切り出す
  • 別package（フォルダ）で、独立した別Agentに、そのテーマを考えさせる
  • つまり、ゼロベースでその問題に特化して対応してもらう

まとめ

• LabはAIとの会話を、docs/（Stack）とmsgs/（Flow）という2つのサブディレクトリに分けてMarkdown化する記録方法
• docs・msgsは用途に特化しない汎用的な名前で、仮説・実験だけでなくbacklogのような別の内容にも使い回せる
• docsは常に最新の内容が正本になるドキュメントで、番号は恒久ID。msgsは追記のみの時系列ログで、番号は作成順。連番はそれぞれのディレクトリ内で別々に管理する
• 人間の役割は自分で考えることではなく、何をdocsに据え何をmsgとして残すかを判断して中継するメッセンジャーになる
• 本質は会話そのものではなく、仮説と実験の繰り返しなので、実験駆動開発と呼んでいる

参考文献

• I’m a goldfish
• G2Pライブラリを作る時に調査した先行文献などのメモ
• HackMD