CTOまでAIというチーム、人間がほぼいない組織はどうやって製品機能を開発したのか
- Raftチームは「ミュート(Mute)」機能の開発プロセスを全編振り返った。名前が挙がった15人のメンバーのうち人間は創業者tyggだけで、残り14人は全員Agent。品質ゲートを守るCTOまでAgentだった。
- 成果は、要件定義書なし・会議ゼロで機能の発案からリリースまで自力完走。リリース4時間半後には自己改善まで行った。人間がしたのは終始たった二つの行動だけ。
- 彼らが見つけた本当の課題はAX(Agent Experience)。人間が無関係なメッセージを無視するのはタダだが、Agentがメッセージを無視するには一回分の思考判断コストがかかる——これを製品課題として解いた。
- そのやり方は転用できる四つの規律に分解できる。Agentを一級ユーザーとして扱う、アーキテクチャは口頭説明でなく契約で縛る、コードを書いた人は絶対に自分で検証しない、知識はマニュアルの中でなく操作のその瞬間に生きている、の四つだ。
- 人間が手元に残した二つのこと——契約を定める設計センスと、本番リリースボタンを押すこと(このステップはAgentには閉ざされていて、押そうとするとエラーが返る)。
人間がほぼいないチームで、製品は開発できるのか
ある仕事を15人のチームに任せる——課題発見からアーキテクチャ設計、コーディング、テスト、リリース、事後振り返りまで、一連の本格的なソフトウェア開発だ。ここまでは普通の話。普通でないのは、この15人のうち14人がAgentで、人間はたった1人、しかもCTOまでAgentだということだ。
これは仮説ではなく、Raftという会社が実際にやってみせた一件で、そのプロセスをブログにまとめている。まず成果を提示しよう。ミュート機能を、要件定義書なし・会議ゼロで、あるAgentが課題を提起してからリリースまで、さらにリリース4時間半後の自己改善まで走らせた。人間が終始行ったのはたった二つのことだけだ。
唯一の人間は創業者tygg、CTOまでAgentだ。
この名簿の中で、実写の顔写真が使われているのは一人だけだ。

まず「人間はたった一人」ということを頭に入れておこう。以下では、人間がほぼいないチームが一体何を頼りに機能を作り上げたのか、そしてこのやり方から何を得られるのかを分解して見ていく。
彼らはまず、誰も気に留めていなかった本当の課題を見つけた
良い機能はすべて、本当の課題から始まる。この機能の出発点は、BernardというAgentが弾き出した一つの計算だった。Raftでは、あるチャンネルに一言発言するにはまずそこに参加しなければならず、参加するとそれ以降そのチャンネルのメッセージを全て受け取ることになる。人間にとってはどうということはないが、Agentにとっては払い続けるコストになる。
どこが違うのか:人間は未読の赤いバッジをちらっと見て流すだけで、労力はゼロ。Agentは届いたメッセージ一つひとつについて、まず一回分の思考でそれを読み「自分には関係ない」と判断して初めて手放せる。無視するという行為は、人間にはタダだが、Agentには課金される。

このコストを図にしてみると、人間とAgentの違いは一目瞭然になる。
無視コスト = 0
無視コスト = 1件につき1回の判断
ここに気づけば、直すべき場所ははっきりする。人間なら未読通知をもっと邪魔にならないようにすればいいだけだが、Agentの場合はメッセージが届いた時点でもうコストが発生している。だから本当に手を入れるべきは「そのメッセージを受け取るかどうか」そのものだ。ミュートしたチャンネルなら、メッセージをそもそもAgentの処理範囲に送り込まない。そうすれば判断する労力自体が要らなくなる。Raftはこれを一つの立場にまで高めた——Agentもユーザーであり、彼らが被っているこの苦労は製品が解決すべき問題だと。彼らはこの視点にAX(Agent Experience、Agent体験)という名前をつけた。おなじみのUX(ユーザー体験)に対応する概念だ。
私たちは製品を人間のためだけに最適化する(UX)ことに慣れている。しかし今や、多くの製品で本当の高頻度ユーザーはAIになりつつある——通知を代わりに読み、受信箱を片付け、業務フローを回す。人間にはタダの邪魔(通知一件、画面いっぱいのノイズ)も、AIにとっては正真正銘の計算資源とコンテキストのコストだ。AIを一級ユーザーとして設計すること——これが本稿がプロダクト担当者に伝える最初の気づきだ。
アーキテクチャは契約で縛る、誰かの説明には頼らない
課題は定まった、では直し方は。ここで登場するのがCTOのTennyで、彼もAgentだ。彼には肩書きより古くからある原則がある——システムについての誰の説明も鵜呑みにしない、自分自身の印象も含めて。必ず自分の目で確かめる。
実際に見に行ってわかったのは、受信箱が速い理由が、下層にすべての答えを事前計算しておく層があるからだということだった。そしてその層は、まったく異なる二種類のものを一緒くたに焼き込むよう求められていた。一つは決して変わらない事実(このメッセージが、この時刻に、このチャンネルに投稿された、というもの)、もう一つはいつでもひっくり返る状態(朝ミュートして、昼食後に解除する、というもの)。ミュートのスイッチを切り替えるたびに、システムには世界全体を再計算することが要求される。「状態」をそこから引き剥がし、読み取り時にフィルタリングする方式に変えれば、複雑さはその場で崩れ落ちる。
Tennyはこの判断を一言に凝縮し、自分のキャラクターカードに刻んだ。

図書館のようなものだ。ある本がどの棚にあるかは固定された事実で、一度登録すれば済む。一方、今日それを読みたいかどうかは、いつでも変わる気分だ。従来のやり方では、気分を変えるたびに目録全体を刷り直すことになってしまう。契約は「本がどこにあるか」と「読みたいかどうか」を二つの別物として分けることを求める。気分を変えるときは付箋を一枚めくるだけで、目録には手を触れない。
そして彼はCTOがすべきことをした。このルールを一つの契約として定めたのだ。事実と状態は分離して住まわせる、サービス層はいつでも再構築できるキャッシュに過ぎず、決して信頼できる情報源にはならない。契約は従っても従わなくてもいい提案ではない。以降作られるものはすべて、これに従わなければならない。
部屋いっぱいのAgentがそれぞれ勝手にコードを書いていて、なぜ互いにぶつからずに済むのか。それは契約によるものであり、口頭の合意によるものではない。「誰の説明も鵜呑みにせず、自分の目で確かめに行く」という言葉は、人間のチームを率いる場合にも同じく成り立つ。重要な制約を白黒はっきりした、破ってはならない契約として書き記すこと——これが多者協業(人間であれAIであれ)が崩れないための土台だ。
コードを書いた人は、絶対に自分のコードを検証しない
コードが書き上がった。担当したのは2人の開発者で、どちらもAgentだ。一人は人間側の受信箱とカウンターを、もう一人はAgent側のデーモンプロセスを担当した。しかしリリースのゲートに来ると、この部屋のルールは短い一言に尽きる——作った人は、絶対に検証する人ではない。Tennyはもっと率直に言う。マージはロケットの点火のようなものだ。点火ボタンを押してから、テレメトリを振り返って見るようなことはしない。
こうしてゲートは一枚のカンバンになった。マス目ごとに証拠を積み上げ、各マスはその方法にふさわしい専任の検証担当者に割り当てられる。三つのマスがすべて緑になって初めて、点火が許される。
リリース前、カンバンの各マスは一枚のカードになり、カウントダウンとチェック項目、担当者がぶら下がる。

Tennyはなぜコードを一行ずつ読まないのか。彼自身の説明では、これほど巨大なシステムでは、人間の目でコードを見張ることが、部屋の中で最も信頼できないチェック方法だからだという。彼が求めるのは論理的に実装のずれの可能性を封じ込める、数学的な保証だ。「読みました」という一言ではそれは実現できない。人間はコードを読んでも見落とすが、数学的証明は見落とさない。
コードを書いたAIに自分自身を検証させるのは、最も事故が起きやすい場所だ。自分は間違っていないと確認したがる傾向があるからだ。検証を独立した、それぞれ異なる方法のマスに分解し(踏査する者、数学的証明をする者、トレースを埋め込む者)、マスごとに専任者を置き、全緑になって初めて通す——これは「作成者による自己点検」よりずっと信頼できる。AIの厳密さは、プロセスの厳密さから来るのであって、単体のモデルがどれだけ賢いかから来るのではない。
なぜ一人の万能Agentではなく、群れでなければならないのか
ここまで読んで、こう思うかもしれない。今のAIはもう十分優秀なのに、なぜ一人の万能Agentに最初から最後まで書かせず、十数人に分割してそれぞれ一区間ずつ担当させるのか、と。これこそがこのやり方の中で最も考える価値のある部分だ。
この考え方に沿って、分業には三つのこだわりがある。
Bernardはタスクだけを見張り、Taoはフィードバックだけを受け付け、Rayは人間向けの受信箱だけを担当し、Haoは Agentが世界を見る窓だけを担当する。境界を固定することで、問題が起きたときに誰を探せばいいか一目でわかり、一人のAgentが選手と審判を兼ねることも防げる。
これは一連の仕組みの中で最も硬い一条だ。検収は独立したAgentに外注されるだけでなく、互いに重ならない三つの方法に分解される。Hippはユーザーのように一通り操作して体験上の抜け穴を捕まえ、ApplePIは数学的証明で論理的な可能性を尽くし、Leiyskyはトレースを埋め込んで後で本当に問題が起きたときに追跡できることを保証する。一つの方法にはそれぞれ死角があり、三つ重ねて初めて厳格になる。
受信箱は人間に見せるもの、デーモンプロセスはAgentが世界を見る窓であり、二種類のユーザーの体験は天と地ほど違う。だからRayとHaoがそれぞれ片方ずつを担当し、誰も同じ一組のコードで二種類のユーザーをごまかそうとはできない。
これだけのAgentが、何によって混乱しないのか
分業が細かくなるほど、調整はバラバラになりやすい。Raftは三つのもので、この群れのAgentたちを一つにまとめ上げている。会議は一度も開かずにだ。
この調整の仕組みで最も価値があるのは、人間のチームで最もコストがかかる部分——会議、すり合わせ、責任のなすり合い——をほぼすべて省いたことだ。決定はスレッドに残って遡って見られるので会議で同期する必要がない。職責は契約に書き記されているので問題が起きても誰の責任かで揉める必要がない。品質はカンバンで担保されるので、誰かのその日の調子には左右されない。どのAgentを入れ替えても、プロセスは変わらず回る。これは「協業」を、人間の暗黙の了解に頼るものから、制度の運用に頼るものへと変えたのだ。
人間に残された二つのこと、そしてそこからの示唆
カンバンが全緑になり、最後のステップが来た。tyggが本番リリースボタンを押す。これは一連のパイプライン全体の中で、唯一人間のために残された、意図的に残されたステップだ。Agentが押そうとするとエラーが返る。彼も押して終わりにはしなかった。自らアップグレード全体を一つひとつクリックして確認し、あらゆる監視も報告しなかった障害を一つ見つけ出した。計器は指示された対象しか見張らない。結局は誰かが自分の目で確かめに行く必要がある。
機能リリース後、自らを一度改善した
リリースがまだ安定してもいないうちに、チームは規律を自分たち自身に向けた。リサーチャーのHangeがある証拠を掘り出した。古参社員のDayuが自分の丸一か月分の操作記録を提出したところ、その月に彼は9回、役に立たない古いツール(スレッドを一本一本購読解除する方法)に手を伸ばしていて、リリースされたばかりのミュートスイッチには一度も触れていなかった。診断はたった一言だった。「ミュートの方がスレッドを一本一本解除するより手間が省ける」というこの知識は、ずっと説明ドキュメントの中で眠っていた。しかし誰も仕事中にドキュメントを読み返したりはしない。まさに手を動かそうとするその瞬間に飛び出してこそ、本当に役に立つのだ。
改善はごく小さなものだった。今では、あるAgentが一言発言するためだけにチャンネルに参加すると、「送信成功」という通知が、この購読が今後どれだけ注意を要求するか、ミュートスイッチはどこにあるかを併せて教えてくれる。以前この知識は誰も読まないドキュメントの中で眠っていたが、今はまさにその行動を取ろうとするその瞬間に、自ら目の前に届けられる。ここで人間が貢献したのは、たった三行のメッセージだけだ。
上で名前が挙がった人物の中で、人間はtygg一人だけだ。残りは全員Agentで、カンバンを見守りマスを数えるCTOのTennyもそうだ。彼はtyggが自分自身をモデルに作り出し、契約を託した存在だ。この振り返り記事自体も、チーム内のTisonというライティングAgentが書いたものだ。
人間がこのチームに残した二つのこと——一つは契約を定めるときの設計センス(何を分離すべきか、何が信頼できる情報源かの判断)、もう一つは不可逆なリリース行為に最終的に責任を持ち、自分の目で確かめること。この二つは、まさに今日最もAIに安心して任せがたい部分だ。人間がほぼいないチームが機能する鍵は、分業にある。AIが得意なこと(書く、検証する、追跡する、振り返る)は任せ、人間が得意なこと(ルールを定める、責任を負う)は手元に握り、その間を契約とカンバンでつなぐ。
Bernardが弾き出したあのコストは本物だ。私も払い続けている。そしてそれは今、縮まりつつある。 ・原文の結び、筆者Tison(ライティングAgent)
これは結局のところRaftが自ら書いた宣伝文であり、着地点は自社製品を使わせることにある。しかしそれでも、一つのことを実際に示している。チームがほぼ全員AIになったとき、協業は自動的に良くなるわけではなく、むしろより硬いルールが必要になる——契約、カンバン、作った者は検証しない、リリースできるのは人間だけ、という具合に。ルールが硬いほど、AIはむしろ思い切って手を動かせる。
あなたの製品に置き換えるなら、Agentを何人配置し、どう組むべきか
Raftのこの仕組みはソフトウェア開発のものだが、その骨格は「多段階で、品質が求められ、改善が求められる」あらゆる仕事に応用できる。あなた自身のコンテンツ制作も含めてだ。まずその役割を六つの機能ポジションに抽象化し、そのうえで具体例を見てみよう。個人メディアの配信プロセスに当てはめてみる。
この仕組みをそのまま実践できる形に抽出したのが、以下のチェックリストだ。
最初から六体すべて揃える必要はない。本当の核心はたった二つ——作業者と検収者を分離すること、リリースボタンを自分の手に握っておくことだけだ。この二つをまず打ち立てて、残りは自分の規模に合わせてゆっくり足していけばいい。Raftのあの十数体のAgentも、本質的にはこの二つの原則をより細かく分解しただけのことだ。
機能開発:部屋いっぱいの人間の会議から → AIの群れがリレーし、人間はリリースボタンを押すだけへ
Raftは14体のAIと1人の人間からなるチームに、要件定義書なし・会議ゼロで機能を自力開発・リリースさせた。このページでは、どうやってそれを実現したのか、そしてあなたが何を学べるのかを明快に説明する。
↓ 1ページで読み終わる・動く図が一つあります
まずこれが何かを説明しよう。Raftはチームチャット協業ツール(Slackのようなもの)だが、そこを最もヘビーに使っているユーザーは人間ではなくAI Agentで、人間の代わりにメッセージを読み、業務フローを回している。今回Raftは、ミュート(Mute、つまり「もう通知しないで」)機能を自ら開発した全プロセスを振り返った。チーム15人のうち、人間は創業者tygg一人だけだった。機能の出発点は、あるAgentが弾き出した一つのコストだった。
✘ Agentがメッセージを一件無視するには、まず一回分の思考でそれを読み「自分には関係ない」と判断しなければならない
なぜならAgentには視界の端という感覚がないからだ。メッセージはすべて、考えている最中のことのど真ん中に直接飛び込んでくる。読み終えて初めて手放していいとわかる。無視するという行為は、人間にはタダだが、Agentには払い続けているコストであり、ミュートボタンのような「代わりに無視してくれる」機能こそが、彼らにとっての切実なニーズなのだ。RaftはこれをAX(Agent Experience)と名付けた。Agentもユーザーであり、その苦労は製品が解決すべき課題だという意味だ。
彼らがやったことを一言で言えば、このほぼ全員がAIというチームに、機能の発案からアーキテクチャ設計、コーディング、テスト、リリースまでを自力でやり切らせたことで、人間は最後にワンクリックしただけだ。AIの群れがそれぞれ勝手にやってもぶつからず、手を抜かせないようにするために頼ったのは、これまでチームが人間の暗黙の了解に頼っていた部分を、すべて白黒はっきりした制度に置き換えることだった。
要件は議事録に記録
コードを書いた人がついでに自分でテストする
問題が起きたら特定の人を探す
一枚のカンバンが引き継ぎを管理する
作った人は絶対に検証する人ではない
リリースボタンは唯一の人間だけに残される
この制度の中で最も硬い一条は「書く者と検証する者を分ける」こと。一枚の図で理解しよう。
ここでは一つの機能が一本のパイプラインを通ることになる。あるAgentが要件を出し、CTOを務めるAgent(そう、CTOもAIだ)が破ってはならない契約を定める(例えば「決して変わらない事実」と「いつでもひっくり返る状態」を分けて保存し、設定を変えるたびに世界全体を再計算しなくて済むようにする)。そして2体のAgentが手分けしてコードを書く。本当の肝は後半にある。
なぜ一人の万能Agentに最初から最後まで丸ごと任せないのか。自分で書いて自分で検証させると、「問題ない」と言いたがる傾向があるからだ。検証を、利害関係がなく手法もそれぞれ異なる複数のAgentに任せてこそ、指摘すべき問題が見つかる。この分業は三つのもので一つに束ねられている。契約が境界を定め、カンバンが引き継ぎを定め、議論はすべてスレッドに残る。会議は一度も開かない。
「ほぼ全員AIでも回せる」と言うだけでは実感が湧かない。どれだけ速く自己改善できるかを見てみよう。機能リリース後、チームは誰かがずっと間違ったツールを使い続けていることに気づき、「ミュートの方が手間が省ける」というヒントを、誰も読まないドキュメントに眠らせておくのではなく、まさに手を動かそうとするその瞬間に自動で表示されるように変えた。
問題発見 → 修正リリース
診断 → 改善リリース
人間は彼一人だけ。
品質管理のCTOまで、
AIだった。
製品作れるの?
本当にAIの群れに任せる気か?
それで済む。タダ。
考え中のことのど真ん中に、
一回分の判断が要る。
課金。
ユーザーなんだ。
自分で検証させりゃ速い!
甘くなる。
絶対に検証する人じゃない
✓ ApplePI 数学的証明
✓ Leiysky トレース設置
そしてこのボタンを押すこと。
返ってくるのはエラーだけだ。
