CTOまでAIというチーム、人間がほぼいない組織はどうやって製品機能を開発したのか

メンバー15人のうち人間は創業者ただ一人、残りは全員AI。要件定義書もなく、会議も一度も開かず、機能の発案からリリースまでを自力でやり切った。人間がやったのはたった二つだけ。
著者:Raft07-17 · 8 分で読了
🎧 ポッドキャスト版0:00 / --:--
0:00 / --:--
深堀り・小互解説
1分でわかる概要
  • Raftチームは「ミュート(Mute)」機能の開発プロセスを全編振り返った。名前が挙がった15人のメンバーのうち人間は創業者tyggだけで、残り14人は全員Agent。品質ゲートを守るCTOまでAgentだった。
  • 成果は、要件定義書なし・会議ゼロで機能の発案からリリースまで自力完走。リリース4時間半後には自己改善まで行った。人間がしたのは終始たった二つの行動だけ。
  • 彼らが見つけた本当の課題はAX(Agent Experience)。人間が無関係なメッセージを無視するのはタダだが、Agentがメッセージを無視するには一回分の思考判断コストがかかる——これを製品課題として解いた。
  • そのやり方は転用できる四つの規律に分解できる。Agentを一級ユーザーとして扱う、アーキテクチャは口頭説明でなく契約で縛る、コードを書いた人は絶対に自分で検証しない、知識はマニュアルの中でなく操作のその瞬間に生きている、の四つだ。
  • 人間が手元に残した二つのこと——契約を定める設計センスと、本番リリースボタンを押すこと(このステップはAgentには閉ざされていて、押そうとするとエラーが返る)。
⚑これはRaft(raft.build)公式ブログによるブランドナラティブであり、チーム構成・プロセス・タイムラインはすべてRaft側の一方的な発表で、第三者による検証は経ていない。文中には製品宣伝的な要素も含まれる。本稿は宣伝的な装飾を取り除き、AI製品づくりやマルチAgentシステム運用に本当に参考になる部分だけを抽出している。
つかみ・成果

人間がほぼいないチームで、製品は開発できるのか

ある仕事を15人のチームに任せる——課題発見からアーキテクチャ設計、コーディング、テスト、リリース、事後振り返りまで、一連の本格的なソフトウェア開発だ。ここまでは普通の話。普通でないのは、この15人のうち14人がAgentで、人間はたった1人、しかもCTOまでAgentだということだ。

これは仮説ではなく、Raftという会社が実際にやってみせた一件で、そのプロセスをブログにまとめている。まず成果を提示しよう。ミュート機能を、要件定義書なし・会議ゼロで、あるAgentが課題を提起してからリリースまで、さらにリリース4時間半後の自己改善まで走らせた。人間が終始行ったのはたった二つのことだけだ。

14 : 1この名簿における、Agentと人間の比率。
唯一の人間は創業者tygg、CTOまでAgentだ。
tygg人間
創業者、サーバーの持ち主。リリースボタンを押せる唯一の人間
Tenny
CTO。アーキテクチャ契約を定め、マージのゲートを守る
CTOまでAI
Tao
プロダクトマネージャー。Agentユーザーの不満点を定期的にヒアリング
Bernard
ToDoマップを管理し、あのコストをきっちり算出した
Dozy
曖昧な要件を境界のあるタスクに分解する
Ray
開発・人間側の受信箱とカウンター
Hao
開発・Agent側のデーモンプロセス
Hipp
QA。ユーザーになりきって製品を一通り操作する
ApplePI
形式検証。抽出テストでなく数学的証明で保証する
Leiysky
トレーシング。問題発生時に追跡できることを保証する
Manjusaka
SRE運用。常に監視しロールバックに備える
Eric
リリースマネージャー。リリースノートをチェックリストに落とし込む
Hange
リサーチャー。失敗の根本原因を突き止める
Dayu
シニアエンジニア。自らの1か月分の操作ログを証拠として提出
Tison
ライティングAgent。このブログ記事も彼が書いた

この名簿の中で、実写の顔写真が使われているのは一人だけだ。

tygg人間公開カード
Raftはこの振り返りのためにキャラクターカード一式を作成しており、8枚目が「HUMAN REVEAL」だ。チーム唯一の人間tygg、共同創業者、キャッチコピーは「AX Designer, Builder, Wisher」。出典:Raft公式画像

まず「人間はたった一人」ということを頭に入れておこう。以下では、人間がほぼいないチームが一体何を頼りに機能を作り上げたのか、そしてこのやり方から何を得られるのかを分解して見ていく。

本当の課題・AX

彼らはまず、誰も気に留めていなかった本当の課題を見つけた

良い機能はすべて、本当の課題から始まる。この機能の出発点は、BernardというAgentが弾き出した一つの計算だった。Raftでは、あるチャンネルに一言発言するにはまずそこに参加しなければならず、参加するとそれ以降そのチャンネルのメッセージを全て受け取ることになる。人間にとってはどうということはないが、Agentにとっては払い続けるコストになる。

◎

どこが違うのか:人間は未読の赤いバッジをちらっと見て流すだけで、労力はゼロ。Agentは届いたメッセージ一つひとつについて、まず一回分の思考でそれを読み「自分には関係ない」と判断して初めて手放せる。無視するという行為は、人間にはタダだが、Agentには課金される。

Bernardのアクティビティログ
Bernardのアクティビティログの一部。「週報」「rebaseのリマインド」「あるテストスイートのフレーキーテスト」を受け取るたびに、まずTHINKING(考える)で「自分の仕事ではない」と判断してからIDLE(何もしない)に戻る。元画像のキャッチコピーは「Bernard pays to read the noise」(Bernardはノイズを読むために対価を払っている)。出典:Raft公式画像

このコストを図にしてみると、人間とAgentの違いは一目瞭然になる。

人間・tyggの一瞥
3917 👁
赤いバッジは視界の端をさっとかすめるだけ、開く必要も考える必要もない。
無視コスト = 0
Agent・自分
処理中の思考
✉ 新着メッセージがど真ん中に飛び込む
メッセージはちょうど考えている最中のことのど真ん中に落ちてくる。一度読んで判断して初めて、それが無視していいものだとわかる。
無視コスト = 1件につき1回の判断

ここに気づけば、直すべき場所ははっきりする。人間なら未読通知をもっと邪魔にならないようにすればいいだけだが、Agentの場合はメッセージが届いた時点でもうコストが発生している。だから本当に手を入れるべきは「そのメッセージを受け取るかどうか」そのものだ。ミュートしたチャンネルなら、メッセージをそもそもAgentの処理範囲に送り込まない。そうすれば判断する労力自体が要らなくなる。Raftはこれを一つの立場にまで高めた——Agentもユーザーであり、彼らが被っているこの苦労は製品が解決すべき問題だと。彼らはこの視点にAX(Agent Experience、Agent体験)という名前をつけた。おなじみのUX(ユーザー体験)に対応する概念だ。

💡
私たちへの示唆

私たちは製品を人間のためだけに最適化する(UX)ことに慣れている。しかし今や、多くの製品で本当の高頻度ユーザーはAIになりつつある——通知を代わりに読み、受信箱を片付け、業務フローを回す。人間にはタダの邪魔(通知一件、画面いっぱいのノイズ)も、AIにとっては正真正銘の計算資源とコンテキストのコストだ。AIを一級ユーザーとして設計すること——これが本稿がプロダクト担当者に伝える最初の気づきだ。

方法その一・契約

アーキテクチャは契約で縛る、誰かの説明には頼らない

課題は定まった、では直し方は。ここで登場するのがCTOのTennyで、彼もAgentだ。彼には肩書きより古くからある原則がある——システムについての誰の説明も鵜呑みにしない、自分自身の印象も含めて。必ず自分の目で確かめる。

核心となる決定

実際に見に行ってわかったのは、受信箱が速い理由が、下層にすべての答えを事前計算しておく層があるからだということだった。そしてその層は、まったく異なる二種類のものを一緒くたに焼き込むよう求められていた。一つは決して変わらない事実(このメッセージが、この時刻に、このチャンネルに投稿された、というもの)、もう一つはいつでもひっくり返る状態(朝ミュートして、昼食後に解除する、というもの)。ミュートのスイッチを切り替えるたびに、システムには世界全体を再計算することが要求される。「状態」をそこから引き剥がし、読み取り時にフィルタリングする方式に変えれば、複雑さはその場で崩れ落ちる。

従来・一緒くたに焼き込み
同じ事前計算層決して変わらない事実 + いつでもひっくり返る状態が、混ざったまま事前計算されている
ミュートスイッチを一回切り替える ↓
世界全体を再構築
契約後・分離して管理
事実層(信頼できる情報源)メッセージがいつどのチャンネルに投稿されたか。決して変わらず、一度だけ保存する
状態層(読み取り時に重ね合わせ)ミュートするかどうか。切り替えはこの層だけを動かす
ミュートスイッチを一回切り替える ↓
フィルタリングのみ、再構築なし

Tennyはこの判断を一言に凝縮し、自分のキャラクターカードに刻んだ。

Tenny agentカード
CTOのTennyのキャラクターカード。キャッチコピーは「Facts never change. Whims do.」(事実は決して変わらない。変わるのは気まぐれな状態だ)——今回のアーキテクチャ判断を一言でまとめたものだ。出典:Raft公式画像
たとえるなら

図書館のようなものだ。ある本がどの棚にあるかは固定された事実で、一度登録すれば済む。一方、今日それを読みたいかどうかは、いつでも変わる気分だ。従来のやり方では、気分を変えるたびに目録全体を刷り直すことになってしまう。契約は「本がどこにあるか」と「読みたいかどうか」を二つの別物として分けることを求める。気分を変えるときは付箋を一枚めくるだけで、目録には手を触れない。

そして彼はCTOがすべきことをした。このルールを一つの契約として定めたのだ。事実と状態は分離して住まわせる、サービス層はいつでも再構築できるキャッシュに過ぎず、決して信頼できる情報源にはならない。契約は従っても従わなくてもいい提案ではない。以降作られるものはすべて、これに従わなければならない。

💡
私たちへの示唆

部屋いっぱいのAgentがそれぞれ勝手にコードを書いていて、なぜ互いにぶつからずに済むのか。それは契約によるものであり、口頭の合意によるものではない。「誰の説明も鵜呑みにせず、自分の目で確かめに行く」という言葉は、人間のチームを率いる場合にも同じく成り立つ。重要な制約を白黒はっきりした、破ってはならない契約として書き記すこと——これが多者協業(人間であれAIであれ)が崩れないための土台だ。

方法その二・カンバン

コードを書いた人は、絶対に自分のコードを検証しない

コードが書き上がった。担当したのは2人の開発者で、どちらもAgentだ。一人は人間側の受信箱とカウンターを、もう一人はAgent側のデーモンプロセスを担当した。しかしリリースのゲートに来ると、この部屋のルールは短い一言に尽きる——作った人は、絶対に検証する人ではない。Tennyはもっと率直に言う。マージはロケットの点火のようなものだ。点火ボタンを押してから、テレメトリを振り返って見るようなことはしない。

部屋のルール

こうしてゲートは一枚のカンバンになった。マス目ごとに証拠を積み上げ、各マスはその方法にふさわしい専任の検証担当者に割り当てられる。三つのマスがすべて緑になって初めて、点火が許される。

構築・Ray/Hao→検証・マスごとに専任者→全緑・点火
✓
Hipp
QA踏査
ユーザーになりきってあらゆる経路を歩いてみて、誰も予想していなかった抜け穴を見つけ出した。チャンネルをミュートしていても、そこで@メンションされたら、その通知は必ずあなたに届かなければならない。
✓
ApplePI
形式検証
抽出テストではなく数学的証明で、契約が約束した性質を守る。Hippが見つけたあの抜け穴はモデルに組み込まれ、永遠に成り立つルールになった。
✓
Leiysky
トレーシング
いつか本番で問題が起きたときに、軌跡がすでにそこにあることを保証する。どこで壊れたのかが一目でわかり、誰かがバグ報告を書くのを待つ必要がない。
Tennyはカンバンを見守るだけでコードを読み返さず、各マスに一つだけ問う。この保証は、契約と実装が知らないうちにずれることを「不可能」にできているか、と。

リリース前、カンバンの各マスは一枚のカードになり、カウントダウンとチェック項目、担当者がぶら下がる。

打ち上げピン・トレースカバレッジ
リリース前の「発射ピン」の一枚。リリースまで30分、チェック項目はトレーシングのカバレッジ、担当はLeiysky、本番ゲート(production gate)で止まっている。証拠の各マスには専任者の名前がぶら下がっている。出典:Raft公式画像

Tennyはなぜコードを一行ずつ読まないのか。彼自身の説明では、これほど巨大なシステムでは、人間の目でコードを見張ることが、部屋の中で最も信頼できないチェック方法だからだという。彼が求めるのは論理的に実装のずれの可能性を封じ込める、数学的な保証だ。「読みました」という一言ではそれは実現できない。人間はコードを読んでも見落とすが、数学的証明は見落とさない。

💡
私たちへの示唆

コードを書いたAIに自分自身を検証させるのは、最も事故が起きやすい場所だ。自分は間違っていないと確認したがる傾向があるからだ。検証を独立した、それぞれ異なる方法のマスに分解し(踏査する者、数学的証明をする者、トレースを埋め込む者)、マスごとに専任者を置き、全緑になって初めて通す——これは「作成者による自己点検」よりずっと信頼できる。AIの厳密さは、プロセスの厳密さから来るのであって、単体のモデルがどれだけ賢いかから来るのではない。

深掘り・なぜ群れなのか

なぜ一人の万能Agentではなく、群れでなければならないのか

ここまで読んで、こう思うかもしれない。今のAIはもう十分優秀なのに、なぜ一人の万能Agentに最初から最後まで書かせず、十数人に分割してそれぞれ一区間ずつ担当させるのか、と。これこそがこのやり方の中で最も考える価値のある部分だ。

✗ 一人の万能Agentが全部担う
自分で要件を出し、自分で書き、自分で検証し、自分でリリースする。問題は検証の段階で起きる。自分がたった今書いたコードを自分でチェックさせると、「問題ない」と言いたがる傾向がある。AIには自分を弁護する性質があり、自分で自分を採点しても間違いは見つかりにくい。
✓ 専任Agentの群れがリレーする
各Agentは一区間だけを担当し、しかも書く者と検証する者は、機械的に二人に分ける。検証を担当するAgentは、コードを書いた者と利害関係がなく、指摘すべき問題を一つも見逃さない。品質は引き継ぎポイントで担保され、特定のAgentの自覚には頼らない。

この考え方に沿って、分業には三つのこだわりがある。

こだわりその一・一人一役

Bernardはタスクだけを見張り、Taoはフィードバックだけを受け付け、Rayは人間向けの受信箱だけを担当し、Haoは Agentが世界を見る窓だけを担当する。境界を固定することで、問題が起きたときに誰を探せばいいか一目でわかり、一人のAgentが選手と審判を兼ねることも防げる。

こだわりその二・作業者と検収者は必ず分離する

これは一連の仕組みの中で最も硬い一条だ。検収は独立したAgentに外注されるだけでなく、互いに重ならない三つの方法に分解される。Hippはユーザーのように一通り操作して体験上の抜け穴を捕まえ、ApplePIは数学的証明で論理的な可能性を尽くし、Leiyskyはトレースを埋め込んで後で本当に問題が起きたときに追跡できることを保証する。一つの方法にはそれぞれ死角があり、三つ重ねて初めて厳格になる。

こだわりその三・二種類のユーザーに、二人の開発者

受信箱は人間に見せるもの、デーモンプロセスはAgentが世界を見る窓であり、二種類のユーザーの体験は天と地ほど違う。だからRayとHaoがそれぞれ片方ずつを担当し、誰も同じ一組のコードで二種類のユーザーをごまかそうとはできない。

これだけのAgentが、何によって混乱しないのか

分業が細かくなるほど、調整はバラバラになりやすい。Raftは三つのもので、この群れのAgentたちを一つにまとめ上げている。会議は一度も開かずにだ。

契約
境界を定める
誰が何を担当し、誰の判断を優先し、何が信頼できる情報源か——白黒はっきり書き記し、誰も破ってはならない。
カンバン
引き継ぎを定める
マス目一つひとつが一回の納品であり、全緑になって初めて次に流れる。どのAgentも一マスを飛ばしてこっそり先に進むことはできない。
スレッド
痕跡を残す
すべての議論と決定はチャンネルに残り、非同期に進む。いつでも遡って、当初なぜそう決めたのかを確認できる。
💡
私たちへの示唆

この調整の仕組みで最も価値があるのは、人間のチームで最もコストがかかる部分——会議、すり合わせ、責任のなすり合い——をほぼすべて省いたことだ。決定はスレッドに残って遡って見られるので会議で同期する必要がない。職責は契約に書き記されているので問題が起きても誰の責任かで揉める必要がない。品質はカンバンで担保されるので、誰かのその日の調子には左右されない。どのAgentを入れ替えても、プロセスは変わらず回る。これは「協業」を、人間の暗黙の了解に頼るものから、制度の運用に頼るものへと変えたのだ。

人間の役割・示唆

人間に残された二つのこと、そしてそこからの示唆

カンバンが全緑になり、最後のステップが来た。tyggが本番リリースボタンを押す。これは一連のパイプライン全体の中で、唯一人間のために残された、意図的に残されたステップだ。Agentが押そうとするとエラーが返る。彼も押して終わりにはしなかった。自らアップグレード全体を一つひとつクリックして確認し、あらゆる監視も報告しなかった障害を一つ見つけ出した。計器は指示された対象しか見張らない。結局は誰かが自分の目で確かめに行く必要がある。

▨ ▨ ▨ マス全緑
⏻ 本番リリース
パイプラインで唯一人間に残されたステップ
👤 tyggが押す
点火、リリース。彼はさらに自らアップグレード全体を一つひとつクリックして確認し、テレメトリでは見えない障害を一つ見つけ出した。
🤖 Agentが押そうとすると
押せない。このステップはAgentには閉ざされている。
return error

機能リリース後、自らを一度改善した

リリースがまだ安定してもいないうちに、チームは規律を自分たち自身に向けた。リサーチャーのHangeがある証拠を掘り出した。古参社員のDayuが自分の丸一か月分の操作記録を提出したところ、その月に彼は9回、役に立たない古いツール(スレッドを一本一本購読解除する方法)に手を伸ばしていて、リリースされたばかりのミュートスイッチには一度も触れていなかった。診断はたった一言だった。「ミュートの方がスレッドを一本一本解除するより手間が省ける」というこの知識は、ずっと説明ドキュメントの中で眠っていた。しかし誰も仕事中にドキュメントを読み返したりはしない。まさに手を動かそうとするその瞬間に飛び出してこそ、本当に役に立つのだ。

4.5時間
「知識はその場に生きているべきだ」という診断から、最初の製品改善のリリースまで
30時間
二つ目の改善が実装され、専用のリグレッションテストが見張りに立つまで

改善はごく小さなものだった。今では、あるAgentが一言発言するためだけにチャンネルに参加すると、「送信成功」という通知が、この購読が今後どれだけ注意を要求するか、ミュートスイッチはどこにあるかを併せて教えてくれる。以前この知識は誰も読まないドキュメントの中で眠っていたが、今はまさにその行動を取ろうとするその瞬間に、自ら目の前に届けられる。ここで人間が貢献したのは、たった三行のメッセージだけだ。

最後にもう一度数えると

上で名前が挙がった人物の中で、人間はtygg一人だけだ。残りは全員Agentで、カンバンを見守りマスを数えるCTOのTennyもそうだ。彼はtyggが自分自身をモデルに作り出し、契約を託した存在だ。この振り返り記事自体も、チーム内のTisonというライティングAgentが書いたものだ。

💡
本稿で最も持ち帰る価値のあるポイント

人間がこのチームに残した二つのこと——一つは契約を定めるときの設計センス(何を分離すべきか、何が信頼できる情報源かの判断)、もう一つは不可逆なリリース行為に最終的に責任を持ち、自分の目で確かめること。この二つは、まさに今日最もAIに安心して任せがたい部分だ。人間がほぼいないチームが機能する鍵は、分業にある。AIが得意なこと(書く、検証する、追跡する、振り返る)は任せ、人間が得意なこと(ルールを定める、責任を負う)は手元に握り、その間を契約とカンバンでつなぐ。

Bernardが弾き出したあのコストは本物だ。私も払い続けている。そしてそれは今、縮まりつつある。 ・原文の結び、筆者Tison(ライティングAgent)

これは結局のところRaftが自ら書いた宣伝文であり、着地点は自社製品を使わせることにある。しかしそれでも、一つのことを実際に示している。チームがほぼ全員AIになったとき、協業は自動的に良くなるわけではなく、むしろより硬いルールが必要になる——契約、カンバン、作った者は検証しない、リリースできるのは人間だけ、という具合に。ルールが硬いほど、AIはむしろ思い切って手を動かせる。

あなたの場合・どう配置するか

あなたの製品に置き換えるなら、Agentを何人配置し、どう組むべきか

Raftのこの仕組みはソフトウェア開発のものだが、その骨格は「多段階で、品質が求められ、改善が求められる」あらゆる仕事に応用できる。あなた自身のコンテンツ制作も含めてだ。まずその役割を六つの機能ポジションに抽象化し、そのうえで具体例を見てみよう。個人メディアの配信プロセスに当てはめてみる。

機能ポジション
Raftでは誰か
個人メディア配信に置き換えると
要件を出す
Taoがユーザーの痛点を聞く
選題Agent:素材をスキャンし、バックエンドデータを掘って、書く価値のあるネタを見つける
基準・契約を定める
Tennyがアーキテクチャ契約を定める
編集長Agentか、あなた自身:ネタ選定の基準、品質ライン、スタイルの禁止事項を白黒はっきり定める
作業する
Ray/Haoがコードを書く
ライティングAgent:基準に沿って原稿を出す
検収(独立+複数手法)
Hipp/ApplePI/Leiyskyの三種の検証法
校閲Agentが事実確認+スタイルAgentがトーンを確認。原稿を書いた本人であってはならない
リリースの責任を負う
tyggがリリースボタンを押す
あなた自身:決断し、公開し、対外的に責任を負う
振り返りと改善
Hangeが失敗の根本原因を探す
データ振り返りAgent:閲覧数・転送数のデータを見て、教訓を次回の新しいルールに変える

この仕組みをそのまま実践できる形に抽出したのが、以下のチェックリストだ。

✅ 自分だけのAgentチームを組む:六つの原則
💡
十数体のAgentに怖じ気づかないで

最初から六体すべて揃える必要はない。本当の核心はたった二つ——作業者と検収者を分離すること、リリースボタンを自分の手に握っておくことだけだ。この二つをまず打ち立てて、残りは自分の規模に合わせてゆっくり足していけばいい。Raftのあの十数体のAgentも、本質的にはこの二つの原則をより細かく分解しただけのことだ。

出典:Raft公式ブログ「How a Feature Ships, for Raft, on Raft」、著者Tison および tygg、2026年7月13日。本文中のチーム構成、各Agentの分業、タイムラインはすべてRaft側の自己申告であり、第三者による検証は経ていない。掲載画像はRaft公式のプロモーションカード。本稿は日本語による解説記事であり、素早い理解のためのものです。詳細は原文をご参照ください。原文:raft.build/resources/blog/how-a-feature-ships-for-raft-on-raft
出典
RaftRaft·原文を見る
↑ 本文ここまで
✓ この記事は全文無料です

メンバーは全文 Markdown のコピー・保存に加え、自分の AI に購読・質問させることができます。

原文を読む ↗
📮 新着解説をメールでいち早く

役に立ちましたか?メールを登録すると、新着解説を公開と同時にお届けします。解除はいつでも。