タベリエのAI開発、体制と作業フローを図解する

はじめに

前回の記事で、AIエージェントで"体制"を作りながら開発を進めてきた話を書きました。ただ、フェーズを追う形式だったので、「結局、今どういう体制で、どういう流れで作業が進んでいるのか」が一枚の絵として伝わりにくかったかもしれません。
今回は現時点のスナップショットとして、誰が何をやっているか(体制)と、1つの作業がどう流れるか(作業フロー)を、図を使って説明します。

体制: 誰が何をやっているか

前回記載の通り、私が直接会話するのは、統括役のPMだけです。実装やレビューなど、実際の作業(production work)はすべてPM経由でサブエージェントに渡ります。

ポイントは2つです。

• PMは実作業を持たない。 コードを書く、不具合を調査する、レビューする、pushする——これらは全部サブエージェントに投げます。PMの仕事は「誰に何を投げるか判断すること」と「私との会話」だけです。これは、PMはマネジメントに作業に徹する、各種タスクの並列処理を可能とする、モノ作りは役割とプロセスを最適化して行う、ことを目的としています。
• 役割ごとに見る情報を絞っている。 例えばimpleはそのタスクのスペックとコードだけを見て、これまでの経緯は見ません。QAは差分だけを見て、実装の意図に引きずられずにレビューします。会話が長くなるほどAIは精度が落ちる(long-context疲れ)ので、コンテキストを役割ごとに小さく保つのが狙いです。

作業フロー: 1つの作業がどう流れるか

私が何かを決めてから、実際にコードが本番に出るまでの流れです。

ここでの工夫は主に2つです。

1つ目は、②「まず計画書に反映してから作業を渡す」という順序です。 私が何かを決めた直後にいきなり作業を渡すと、その決定が会話の中にしか存在しない状態でサブエージェントが動き出してしまいます。すると、後になって「なぜこの実装になったのか」を誰も辿れなくなりますし、実行中に作業の抜け漏れ・不整合が生じえます。正確な計画書を起こすことができれば、あとはPMの指示のもと、それに沿ってAIチームだけで実行することが可能となります。
特に最初のころは、計画書に書いた？実績記録した？と聞くと、すみません忘れてましたと返されることも多かったので、ここは徹底してもらえるよう改善してきています。

2つ目は、⑧のpushが「1コマンド」ではなく「1サイクルの締め」として設計されている点です。 push作業(release)は、単に本番に反映するだけでなく、完了した項目の後片付け、前提が変わった箇所の更新、その回で見つかった欠陥の真因を開発標準へ書き戻すこと、知見の振り分けまでを含みます。この「締めの工程」は、push直後に私が本番の動作確認を始めるのと並行して進み、最後にQAが独立して確認して初めて1サイクルが完了したことになります。これも当初は抜け漏れが多かった点ですが、人間の世界と同じで、失敗の再発防止を忘れることは非常にもったいないので、なぜなぜ分析とプロセスへの反映を徹底してもらっています。作業クローズに入ったAIエージェントが、他のAIエージェントのためのSkillや開発標準を自発的に更新する状態、これによりチームの品質は確実に向上してきています。

おわりに

体制と作業フローは、最初からこの形だったわけではありません。今後は、この体制が実際に事故を起こし、どう改善されてきたかも書いていきたいと思います。

前回の記事はこちらです。
→ AI支援旅行アプリ「タベリエ」を、構造化ループエンジニアリングで作り上げた話

Xアカウントです。もし良かったらフォローお願いします。
→ タベリエ: https://x.com/torukonauk

アプリも育ってきました。紹介ページだけでも見ていただけると嬉しいです。
→ タベリエ: https://tabelier.torukona.uk/?ch=zenn003#/about