ai

MADFLOW - AIによるcalcium言語の全自動開発

いつもお世話になっております。わいとんです。

さて、皆さんはAIで全自動開発やっていますでしょうか？今回のエントリでは、私が実務でも導入をし始めている「AIによる全自動開発」について書いていこうと思います。

MAXAMの開発と「将軍」の登場

わたしが前回公開したエントリでは、MADT(Multi Agent Develop Team)という概念を提唱しましたが、これはAgent Orchestrationという用語で語られるものとほぼ同一のものでした。

そして、その実装としてMAXAMというものを作って利用していました（余談：物のついでに萌えキャラを充ててあげたら、なぜかすごくアイマスっぽいキャラが錬成されましたのでそのまま採用した）。

しかし、先月中旬あたりからこのように思うようになりました。

「エージェントの種類が多いと効率が悪い。」

これについて、今となっては当然ともいえる共通認識が醸成されつつあります。とはいえ、当時はまだAgent Orchestration自体がかなり珍しいものでありました。

一方でそのころ、multi-agent-shogun（以下「将軍」）をはじめとしたオーケストレーターも登場しました。

カオスなMAXAM、もう少し整然とした将軍

わたしはMAXAMを、将軍の登場とほぼ同時期にOSSにしており、開発自体も将軍の公開とほぼ同じ日に開始していました。ただ、そのアプローチが驚くほど異なっていまして…

MAXAMはエージェント同士がテキストチャットでわちゃわちゃとやり取りするように作られており、結構カオスになりがちでした。見ている分には正直かなり楽しかったです。一方、将軍はやり取りのフローが構造化されているので、より実践的だと感じました（見た目的にも家老が過労死しそうになってるのが面白かったり…ね）。

将軍はその構成が大変よくできており、エージェント同士による対話が文字通り組織化されているおかげで、エージェント一人ひとりの役割がはっきりさせることに成功しています。

これは、各エージェントの役割ごとにやり取りする相手が限定されていることが有効に働いているということでして、MAXAMとの決定的な違いでした。

MAXAMでの教訓を受けてエージェントフローを再設計

MAXAMでは以下のような問題が発生していました。

  • メンションベースでエージェント間のやり取りを実現していた。
    • エージェントがメンションを忘れる
      • 作業がとまる
      • やりとりが断絶する
      • 他のエージェントがツッコミを入れる
      • ツッコまれたエージェントがツッコミを入れたエージェントとやり取りをし始める
      • 本来やり取りする相手が置いてけぼりを食らう
  • どのエージェントも等しくどのエージェントに対してもコミュニケーションをとることができた。
    • 雑談を始める
      • 本来のタスクをこなさなくなる
      • さぼり方を相談し始める
      • 本来の仕様を無視・改ざんしようとする

使えるかい、こんなもん。

ごもっともです。私も途中で頭に来まして、2月下旬には別のオーケストレーターを設計し始めました。

それがMADFLOWです。

※ごめんなさい、使い方はリンク先見てほしいです。そんな難しくないです。なんとかclawよりはセットアップも楽です。

エージェント同士のやり取りは最小限に。GitHubのissueに対して作業を行う。

MADFLOWはエージェントの構成を最小構成にしました。つまり、エージェントとしては「監督(superintendent)」と「エンジニア(engineer)」だけとし、

監督 : エンジニア = 1 : N

となるようにしました。やり取りもエンジニア同士は行わない。監督とエンジニア1 : 1のやり取りだけです。

また、GitHubのissueをポーリングすることにしました。これにより、issueを立てるだけで監督がissueを検出し、エンジニアに指示を行い、エンジニアがドキュメント整備・テストコード＆実装コードの錬成を行うようになりました。

GitHubのissueで指示を出せるようになると、もはやスマホさえあれば開発がガンガン進むのです。

コードレビューは廃止。テストコードとQAで仕様担保。

もともとMAXAMではコードレビュアー専属のエージェントを用意してましたが、これが異常にコストがかかる割には品質担保として意味がないと気が付きました。どういうことかというと、品質担保は結局動作確認しなければ得られないのと、テストコードで担保できるのは「数学的正しさ」による正当性の範囲である、ということです。

AIによる全自動開発を推し進めることで、以下のことが明確化できたと思っています。

  • 「人間がレビューすれば品質担保できる」というのは幻想。
    • 人間が一番レビュー漏れをやらかす。
      • ただし、AIもレビュー漏れをやらかす。
      • つまり、レビュー自体は品質担保を目的にやるものであってはならない。
      • テスト・CI・型システム等の自動検証の積み重ね。これらが品質担保に対しての施策。
  • なぜレビューするのか？
    • 設計判断の共有
    • 知識移転
    • 属人化の分散
    • メンテナンス性の保持
    • 誤った実装の予防
    • … これらは全部「コードを作ったのが人間」だから意味のあること
    • AIに設計判断を共有する方法はほかにある。markdownに書きましょう。
    • AIに知識移転する方法もほかにある。markdownに書きましょう。
    • AIで全自動開発するなら属人化は起こらない。なぜなら人ではなくAIに依存しているから。
    • AIが作るコードはメンテナンス性が低いか→ダウト。設計意図を同梱させないからメンテナンス性が低下するのである。
    • AIは実装を誤る→ダウト。AIに出された指示が誤っている。
  • ドキュメント（とくに要件定義書）は腐る
    • →その通り。ただしテストコードは要件定義の写像。
    • つまるところ、要件定義からテストコードを起こし、テストコードから実装を写像として起こす。これ。
    • 後からテストコードをいじる → ダウト。要件定義を先に修正する必要がある。

ちょっと文章にすると長くなるので箇条書きにしちゃいましたが、意図は汲み取ってもらえるのではないかと思います。

Calcium言語をMADFLOWで実装中

最近もちまちまとMADFLOWに指示を出すことでCalcium言語を実装しています。が、最近はちょっと小休止中といったところ。言語としては一通り動くところまではできたかと思います。

完全に全自動で開発できており、富士五湖バイクツーリングの休憩中に指示を出して、次の休憩ポイントにつく頃には実装が完了してdevelopブランチにマージされている、という体験が得られました。developブランチへのマージまで自動でやります。CI/CDが通っていればマージ。簡単な事前レビューはしますけど、実装漏れを防止する観点のものであり、品質担保はCI/CDとmainブランチへのマージの前にAIが簡単な動作確認を行うことで担保としています。

調査や検証、レポート作成もMADFLOWで自動化

つまり、MADFLOWをGitHubレポジトリでドキュメント類を管理・編集するものと捉えることもできます。

裏でコマンド類を実行してくれますから（きょうびのAIなら当然やります）、大抵のCLIでできることはできる。それでもってGitHub経由で調査・検証・レポート作成してくれるわけです。

まとめ

疲れたんでこの辺にしておきますが、ざっくりまとめると以下の通りです。

  • 将軍とMAXAMからいろんな示唆を得た。
  • MADFLOWで全自動開発やろうと思えばできるっぽい。
  • AIによる全自動開発では品質担保の意味や方法が変わる。
  • 調査・検証・レポート作成もMADFLOWで全自動化。

ちなみにMADFLOWはGo製のワンバイナリとなります。利用したいプロジェクトでお使いいただければ、比較的簡単にGitHub issueドリブンの全自動開発が始められます。READMEをよく読んでお使いください。あと自分用に作ったものでもあるので、そのあたり自己責任でお願いします。

おまけ：MADFLOWで便利なissue

あと、上手な使い方の一つとして、issueをたくさん立てさせるissueを作ると、非常に便利です。以下のタイトルのissueを私はよく立てます。タイトルだけで大体何とかしてくれます。

  1. 「このプロジェクトの要件定義を確認し、実装計画を立てる」
  2. 「実装計画に基づき、実装完了までのイシューをすべて作成する」

1→2の順番でissueを処理させると、あとは黙ってても実装してくれます。作業が滞ることもありますが、大抵はLLM APIのスロットリングを受けて休憩している状態となります。