会話駆動開発

背景

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

会話駆動開発

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

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

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

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

会話駆動開発とは

会話駆動開発とは、シンプルにAIとの会話はすべてmsgとしてmdで保持しつつ、人間はあまり介在しない開発手法。

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

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

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

Convos

会話の作り方

まず、AIとのすべての会話のメッセージをMarkdown化して記録する
1ファイル1まとまりの会話として、convos/のようなディレクトリに蓄積していく
ファイル名は{pin|msg}_{3桁連番}_slug.mdという形式
連番はpin・msgの種別を問わず1本を共有する（新しいファイルは常に既存最大番号+1）
これを徹底して、複数のAIの会話をこのMDに落とし続ける

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

1
2
3
4
5
6
convos/
├── pin_001_spec.md                       # 現時点の正本仕様
├── msg_002_dictionary_analysis.md        # レビュー依頼
├── msg_003_root_cause_review.md          # レビュー依頼
├── msg_004_review_response.md            # msg_003への回答
└── msg_005_naming_convention_update.md   # pin/msgの命名規則自体の変更記録

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

pinとmsgの意味

pin（Stack）
- 常に最新の1件が「今の正本」になる、継続的に更新される生きた仕様書
- 重要な仕様改訂が入ったら、新しいpin_NNN_...mdを追加する
- 古いpinは置き換えられるのではなく、その時点のスナップショットとして残る
- Git HEADに近いイメージ
msg（Flow）
- やり取りの時系列ログで、追記のみ、過去は書き換えない
- レビュー依頼・レビュー結果・レビュー対応など、一区切りごとに1ファイルを必ず作成する
- 時間とともに流れていく、Flow（フロー）の情報
- Git Logに近いイメージ

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

開発フロー

開発フローは、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に渡す
その繰り返し

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

まとめ

ConvosはAIとの会話を、pin（Stack）とmsg（Flow）に分けてMarkdown化する記録方法
pinは常に最新の1件が正本になる仕様書、msgは追記のみの時系列ログで、連番はpin・msgで1本を共有する
人間の役割は自分で考えることではなく、何をpinに据え何をmsgとして残すかを判断して中継するメッセンジャーになる

会話駆動開発

目次

背景

会話駆動開発

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

会話駆動開発とは

Convos

会話の作り方

pinとmsgの意味

開発フロー

init: 管理AIと仕様を作る

loop: 作業AIと開発する

まとめ

参考文献