ManusでManusを再構築する: 何が変わり、何が壊れ、私たちは今どのように働いているのか
Tao Zhang 著、Manus 共同創業者 兼 最高製品責任者
9月下旬、Manus 2.0 のラストスパートの最中、私は Slack でエンジニアの一人にいくつかの機能要望とバグ報告を送った。その後、進捗を確認しに行くと、彼の画面には agent セッションが横一列に並んで開かれていて、Manus のものもあれば Codex のものもあった。私はその一つをクリックしてみた。プロンプトは私の Slack メッセージが一字一句そのまま貼り付けられたものだった。
1年前なら、彼は私のメッセージを読み、意図を汲み取り、それからコードを書いていただろう。今では agent がリクエストを読み、該当するコードを見つけ、変更を提案する。エンジニアの仕事は作業を指示し、確認し、結果に責任を持つことだ。リクエストが走っている間のほとんどは、彼を待たせない。今では、1人のエンジニアが10から20のリクエストを同時に動かしていることが、ここでは当たり前になっている。
私はチームがこれほど早く適応してきたことを誇りに思う。同時に、不安でもある。このペースは正しいのか?まだ気づいていないことは何だろう?
私たちは Manus で agent を作っているので、自らに2つのルールを課している。自社製品を実務で使うこと。そして、AI が機能しなくなる場所を探し続けること。
人と agent が初期設定として並んで働く会社の内側で何が起きるのかを記録しておきたい。この記事では、エンジニアリング、プロダクト、マーケティングの3つのチームを取り上げ、うまくいかなかったことも含めている。これは進行中の実験の報告であって、「AI ネイティブ組織」の定義ではない。
これまでに学んだこと:
•中間地点は存在しない。古いやり方に AI を追加しても、ノイズが増えるだけのこともあった。物事が変わったのは、ループが閉じたときだけだった。
•agent には全体像が必要だ。より良いプロンプトよりも、より良いコンテキストの方が効果があった。
•信頼はテストとコンテキストから生まれるのであって、モデルの品質だけから生まれるのではない。
•自律性にはゴールラインが必要だ。agent が自走できるのは、成功が確認できる場合のみ。それ以外の場所では、人が判断する。
•ボトルネックは移動する。エンジニアリングが速くなると、何を作るかを決めることが制約になった。
•人の役割は縮小していない。より影響力の大きい事柄に集中するようになった。
1. 中間地点は存在しない
2026年以前、私たちは多くの企業と同じことをしていた。既存の働き方に AI を追加していたのだ。つまり、サポートは AI 要約で問題を指摘し、エンジニアはコーディング支援を使い、ボットはチャンネルに分析を投稿する。それぞれは単体で有用だったが、相互に接続されているものは多くなかった。ループが実際に閉じるまで、私たちは単に昔と同じやり方で働いていて、ただ大量の AI が互いに喋り合っているだけだった。
私たちがよく立ち返る一文がある。ソフトウェアエンジニアリングとは、時間で積分されたプログラミングである。コードを書くことは測りやすいが、複雑な製品を何年も健全に保つことはそうではない。AI が書いたコードの比率が高いことは、本当の進歩を意味することもあれば、後で誰かが片付けなければならないガラクタの山を意味することもある。
私たちが気にかけているテストはより厳しい。Manus は1年以上稼働している複雑な製品だ。新しい働き方のもとで、崩壊することなく改善し続け、かつ各人の生産性を高めることができるか?これまでのところ、答えはイエスだ。
2. agent に全体像を渡す
ほとんどのテック企業と同じく、私たちが最も時間を失うのは引き継ぎだった。フロントエンドエンジニアとバックエンドエンジニアがそれぞれリクエストを解釈し、インターフェイスで合意し、そしてすれ違いを修正するのに何日も費やす。2人が同じように要件を理解することは、めったにない。
AI がスタック横断でコードを書けるなら、1人がリクエストを端から端まで担当できるのではないか?障害はコンテキストだった。私たちのコードは別々のリポジトリに存在していたため、どの agent もシステム全体を一度に見ることができなかった。
それに対する私たちの答えは、社内実験から始まりました。人間の入力を最小限にし、手書きのコードをほとんど使わずに、AIがどこまで製品を構築できるかを確かめたかったのです。その過程で開発した手法が、現在私たちが Manus-mono、略して Mono と呼ぶ社内ツールになりました。
Mono はリポジトリを統合しません。単一のエントリーポイントと、Agent 向けに書かれたマニュアル、つまり各リポジトリの役割、それらがどう組み合わさるか、そして私たちの働き方を記したものです。Agent は必要なものを自分で取り込みます。また、アーキテクチャ決定記録のライブラリも維持しているため、すべての Agent セッションは、コードだけでなく過去の決定の背景にある理由から始まります。誰かが Agent と作業するとき、その Agent は先に関わった全員のコンテキストを持っているのです。
Mono は段階的に成長し、各段階が前の段階で明らかになったボトルネックを解消してきました:
1.システム全体を見る。単一のリポジトリには含まれないビジネスコンテキストを追加し、並行作業のために Git worktrees を使用しました。
2.ローカルで検証する。テスト環境へのプッシュには以前は5〜10分かかっていました。今では Manus スタック全体がラップトップ上で動作し、チェックは数秒で完了します。
3.本番環境の問題をデバッグする。スコープ付き権限により、Mono は本番環境のバグ診断に必要なログ、設定、エラーレポートを読み取ることができます。
4.リリースをエンドツーエンドで実行する。以前は作業が止まりがちだったリリース工程を、Mono が処理するようになりました。承認の判断は依然として人が行います。
5.エンドツーエンドでテストする。検証が遅い部分になったとき、Mono はテストアカウントを使って実際のユーザーフローをブラウザとモバイルシミュレーター上で実行し始めました。
(Mono の仕組みと進化の過程。Manus を使ってチームメンバーが作成しました。)
Mono はコードの Wiki ですか、と聞かれることがあります。ドキュメントはその一部ですが、残りはコードを取り巻くすべて、つまりテスト方法、リリース方法、何を決定しなぜそうしたか、そして Agent が触れてよいもの・触れてはいけないものです。
時を経て、Mono は人々が追加していくことで良くなっていく共有ナレッジベースになりました。例えば、私たちの運用エンジニアはリリースの手伝いを頼まれるのに飽き飽きして、リリースプロセスを Mono に書き込みました。今では誰でもリリースを実行でき、Agent も実行できますが、承認は依然としてリリース権限を持つ人の手にあります。チームの働き方が大好きです。一人が自分の不満を解消したことで、会社全体が少し速くなったのです。
チームは今、一人の人間がすべてのプラットフォームでリクエストを出荷できることを前提としています。モバイルチームはこの間ずっと7人体制です。彼らは2つの製品にまたがる4つのアプリをメンテナンスしながら、Web と同じペースを維持しています。
Mono はトップダウンの命令なしに社内に広がりました。それはツールと同じくらい文化が説明していると思います。AI の限界を試すことは私たちが存在する理由の一つであり、組織もフラットです。ツールは組織が許す範囲までしか広がりません。
3. ループを閉じる: ユーザーのバグ報告から検証済みの修正まで
Mono により、誰もが製品のどの部分でも作業できるようになりました。それが半分です。もう半分は、Agent 自身が問題を見つけられるようにすることでした。
ほとんどのインターネット企業では、ユーザーのバグ報告は、修正できるエンジニアに届くまでにサポート、プロダクト、トリアージを経由します。
私たちの場合、社内 Agent がまず報告を調査し、原因となった変更まで問題を追跡します。それから Slack に投稿し、その変更を担当するエンジニアをタグ付けします。エンジニアはそれが自分が修正すべきものかどうかを判断し、自分の Agent に引き渡します。別の Agent が重要なテストとフローを実行して修正を確認します。
3つの Agent、3つの役割: 一つはトリアージ、一つは作業、一つはチェック。間にいる人が判断を下します。私たちのエンジニアリング作業のうち、Agent が問題を人に持ち込むこのような形で始まるものが増えています。
このループには明確な制限があります。ユーザー報告を読む Agent はコードを変更できません。調査して私たちに報告することしかできません。変更はエンジニアが判断した後、そのエンジニア自身の Agent から行われます。リリース権限を持つ人の承認なしには何もリリースされません。
4. Agent が書いたコードを信頼できるようになるまで
長い間、main ブランチに入るすべての変更には、2 人のシニアエンジニアのいずれかの承認が必要でした。そのステップを省略できるほど AI を信頼していなかったのです。Agent がより多くのコードを生成するようになると、このレビューステップがボトルネックになりました。
純粋なコーディング能力では、モデルはすでに強力でした。違いは 2 つの点にあると認識しました。第一に、人は自分の作業をどうテストすればよいか知っています。第二に、人は上流と下流の議論に参加してきたため、ビジネスにとって「正しい」とは何かを理解しています。正しいコードは、正しいプロダクトと同じではありません。
私たちは両方に取り組みました：
•Agent を議論に参加させる。各エンジニアの Agent は、追加された Slack スレッドに常駐し、文脈を追跡するようになりました。最終的に誰かが「Go」と言ったとき、Agent はチームが何をどう決めたのか、そしてその理由をすでに把握しています。
•Agent にエンドツーエンドでテストさせる。バックエンドチームと協力し、Agent が各変更後に Manus 内で実際のフローと回帰テストを実行できるようにしました。テストカバレッジが拡大するにつれ、私たちの信頼も深まりました。
現在、すべての変更はこの検証と、利用可能な最も強力なモデルを動かすコードレビューボットを通過します。支払いなどのセンシティブな領域には追加のルールが設けられています。ボットは順番待ちの列を置き換えたのであって、人間の判断を置き換えたわけではありません。Agent はプルリクエストを作成できますが、人間からの明示的な承認なしに main ブランチにマージすることはできません。何を作るか、誰がリリースできるかは、依然として人が決定します。
5. 自律性にはゴールが必要
信頼には限界があり、私たちはそれを痛い目を見て学びました。
ある時期、誰もが完全自律型の Agent ループに熱狂していたので、試してみました。Agent は社内のフィードバックチャネルから意見を収集し、各項目についてプロジェクトを立ち上げました。あるチームメイトが週末の間ずっと実行させておきました。月曜日の朝、200 件以上の項目が彼の判断を待っていたのです。
それらの決定も Agent に任せればよいのではないか？自律ループは、目標が達成されたかどうかをシステムがチェックできる場合にうまく機能します。テストは合格か不合格か、ページは読み込まれるか読み込まれないか。実際の仕事のほとんどには、そのようなチェックがありません。完了したかどうか、そしてそもそもやる価値があったかどうかは、人が判断しなければなりません。
その週末から 2 つの教訓を得ました。第一に、人はチェックなしのループが生み出すスピードで決定を下すことはできません。第二に、何かを行うべきかどうかを誰も決めないなら、その結果は誰のものにもなりません。セクション 3 のバグ修正ループが機能するのは、テストが成功を定義するからです。プロダクトの決定にはテストがないので、Manus におけるすべてのプロダクト変更は、依然として人がやる価値があるかどうかを判断することから始まります。
6. エンジニアリングが速くなると、プロダクトがボトルネックに
従来のプロダクトプロセスには多くの引き継ぎがあり、それぞれで優先順位が少しずつずれていきます。コーディング Agent によってエンジニアが速くなるにつれ、新たな問題が現れました。良い要件を書けるプロダクトマネージャーが足りなかったのです。初めて、エンジニアリングが制約ではなくなりました。
Manus では、最初の解決策として、何人かのエンジニアに発見からローンチまで問題を担当する「ビルダー」になってもらいました。しかし、技術とプロダクトの両方の判断力を持つ人はほとんどいませんでした。次に、PM にコードを変更できるようにしました。これも行き詰まりました。引き継ぎは依然として存在し、エンジニアの直感がなければ、PM はコピーやインタラクションは変更できても、根底にあるロジックは変更できませんでした。
Mono は、ルールを一緒に運ぶため、両方の問題を解決しました：
•モデル呼び出しやコストに関わる変更は、コードが書かれる前にオーナーの承認が必要です。
•すべての変更は、エンジニアの変更と同じレビューとテストを通過します。
•Mono はテストアカウントでサインアップと支払いを実行し、各ステップを記録できるので、PM は何かが壊れた正確な瞬間を指し示すことができます。
実際にはこのような感じです。音声からテキストへの変換に取り組む PM は、Manus に 10 以上のモデルをベンチマークさせ、1 つを選びました。彼女は Mono を通じてフロントエンドコードを取り込み、デザインシステム内でデモを構築し、Manus に各ユーザーシナリオを画像としてレンダリングさせてレビューしました。彼女はそのデモを動画にしました。計画は十分明確だったので、彼女は Web とデスクトップの UI を含め、自分で機能を作り上げました。
途中で人が3つの判断を下しました。彼女はモデルを選びました。プロダクトとデザインがデモをレビューしました。リリース権限を持つエンジニアがコードをレビューしました。1年前であれば、こうしたことはどれも不可能だったでしょう。
私たちはこれを、ヒューマン・イン・ザ・ループからヒューマン・オン・ザ・ループへの移行と表現しています。かつてAIはタスクの70〜80%を担い、残りを人が埋めていました。今では人がルールを設定し、複数のAgentを監督し、重要なポイントで方法と結果を確認し、必要に応じて介入し、成果に責任を持ちます。
現在、一部のPMは書面の仕様書やモックアップの代わりに短い動画を引き継ぎます。数分で、ユースケース、各画面、各クリックの動作、エッジケースの挙動、そして裏側での仕組みがすべて示されます。私たちにとっては、デザイン、エンジニアリング、QAが「完了」の意味についてより早く合意でき、PMは一度説明するだけで済みます。
(音声入力のプロダクト要件動画)
現在、PMの約半数が自分で機能をリリースしており、すべてのPMがコードをコミットしています。デザイナーも始めました。あるPMはManus 2.0でManus Studioのインターフェースの大部分を書きました。別のPMはVideo Editorを書きました。これらそれぞれの背後には、自分の役割がかつてカバーしていた範囲を超えて何ヶ月も努力した人がいます。それが私が最も誇りに思うことです。
これは誰もがビルダーになる必要があるという意味ではありません。会社の誰もが構築できるようになると、存在すべきでないものがリリースされる可能性があります。私たちのプロダクトチームはよくこう問いかけます：「もし1秒でコストもゼロなら、これをリリースしますか？」答えがノーの場合もあります。何を構築し、何を構築せず、ユーザーが最終的に何を目にするかを決めるモジュールオーナーは依然として必要です。Monoのようなインフラを維持する人も必要です。構築が容易になるほど、何を構築するかを決めることがより重要になります。
7. マーケティングワークフロー内のAIチームメイト
マーケティング提携は、スクリプトレビュー、価格設定、契約、承認、支払い、ローンチ、結果レビューを経て進みます。これらのステップはメール、契約ツール、承認システム、スプレッドシート、広告プラットフォームに存在します。この仕事の多くは、かつてそれらの間で情報を移動させることであり、判断を要する創造的な作業に充てる時間がほとんど残りませんでした。
私たちは1つの小さな問題から始めました：パートナーコンテンツや広告が公開されたとき、しばしばその情報を遅れて知ることになっていたのです。そこでAIに、コンテンツがいつ公開されたかを検知するスクリプトを書かせました。次にパフォーマンスデータが欲しくなりました。それから過去の提携のレビューも。そして社内ワークフロー全体がつながりました：契約が結ばれたり承認が通ったりすると、Agentがステータスを更新し、次のステップを担当する人に通知します。
Manusはこれらすべてを社内サイトに構築しました。人にとっては、ダッシュボードとカレンダーです。Agentにとっては、ツールのセットです。私たちのワークフロー内でそれらのツールを使うAgentを、私たちはAIチームメイトと呼んでいます。それはチームが接続したチャネルとシステム内でのみ機能し、このワークフローに限定したアクセス権を持ちます。
その働きは次のとおりです：
•自分のキューを管理します。多くの人が同時にメッセージを送るため、1つの「フロントデスク」セッションで全員と話し、並列セッションにタスクを引き渡します。メッセージが自分に関連するかどうかを判断し、次に現在の作業を中断するか待つかを決めます。これらのルールは開発中に自ら提案し、私たちがレビューしてから採用しました。
•転送されたコンテキストから学びます。戦略変更はかつて会議と書面のブリーフを意味していました。今では私たちのマーケティングリードが議論を転送して、「これを学んで」と言うだけです。
•長期的な目標を視野に入れ続けます。あるとき、追加されていたSlackスレッドのチームメイトたちが、プロジェクトがどの段階にあるか思い出せませんでした。タグ付けされていないのに、こう返信しました：「Bはまだテスト中です。Bを検討する前にAの結果を待ちますか？」
•他のチームと事実確認を行います。3Dモデルのリギングをローンチした後、プロダクトチームに何がサポートされているか尋ねました。リギングが魚、ヘビ、四足動物を含む7カテゴリをカバーしていると学び、私たちの説明が正確に保たれました。
チームメイトは今、スクリプトと価格設定のレビューにそれを参加させています。なぜなら、過去の提携記録を読んでいるからです。最終判断は依然として人が下します。
社内サイトは、Agentを含むユーザー自身からも改善されることができます。Agentが摩擦に遭遇すると、フィードバックエンドポイントを通じてリクエストを提出します。これによりManus 2.0のAutomationsを通じてManusに開発タスクが開かれ、エンジニアがリリース前に変更をレビューします。これは約1週間稼働しています。これに頼れるようになるには、さらに多くの事例が必要です。
では、チームの人々は何をするのでしょうか？3つのことが彼らに残ります。重要な決定はすべて下し、責任を持ちます。Agentが見たことのない事例に対処し、何をすべきか、誰に尋ねるべきかを教えます。そして、分析が新しい視点を示したときはいつでも、方向を修正します。
8. お互いの中断を減らす
これらすべてのチームにおいて、多くの質問はもはや誰かを中断させる必要がなくなりました。
まずエージェントに尋ねましょう。あるチームメイトが Mono 上で Slack ボットを構築し、クラウドコンピュータ上で動作してスレッド内で返信します。エンジニア以外のメンバーが最も多く使っています。この機能はどう動くの？この文字列はどこ？これはもうリリースされた？もうオーナーを先に探す必要はありません。
ステータス更新を求める代わりに、セッションを開きましょう。エンジニアの進捗はかつて個人の AI チャットの中にあり、ログオフしたら見えなくなっていました。そこで私たちは、プロジェクトのメンバーが互いのセッションを見て参加をリクエストできる内部機能を構築しました。エンジニアがエージェントと一緒に機能の大部分を構築し、その後 PM が同じセッションに参加して間隔、スタイル、コピーを調整することができます。他人のセッションに投稿するには承認が必要で、権限についてはまだ調整中です。
（例示：エンジニア、PM、デザイナーが 1 つのセッションで作業する様子。実際の価格変更ではありません。）
ポイントはお互いに話す回数を減らすことではありません。お互いを中断させる回数を減らすことです。
決める必要があることだけを決めましょう。私たちの最もヘビーな AI ユーザーは、1 つのメインセッションを維持しており、その唯一の仕事は、彼の決定が必要な事項をそれぞれの推奨事項とともにリストアップすることです。Slack が忙しくなると、彼はそれには関わらず、「今、何を決めなければならないか？」と尋ねます。
私も同じようなことをしています。1 日に 20 以上のタスクがあり、公に共有しているように、私は ADHD です。始めることが私にとって最も難しい部分です。今では、すべてのタスクが専用の Manus プロジェクトに入り、それぞれが独立したタスクになります。できることは始めます。わからない場合は、背景とどの PM が担当すべきかを私に尋ねます。そして、私が与えた自分の Slack、Gmail、Notion へのアクセス権を使って、コンテキストを収集し、1 行のメモではなく完全なリクエストを PM に渡します。私にとって、この変化は効率だけではありません。今では、どこから始めるべきか不安に感じる時間が大幅に減り、これは個人的にも大きなことです。
9. コストに見合う価値はあるか？
私たちは AI に多くを支出しており、その支出を綿密に追跡しています。誰かのパフォーマンスを判断するためではありません。支出自体を判断するためです：それは今成果を上げているのか、それとも将来のための準備なのか？
これが何を買ってくれると考えているか、そしてコストがどこに向かうと予想しているかをお伝えします：
•時間と注意を買っています。チームが成長するにつれて、調整が全員の注意を奪います。AI は各人の注意を守り、仕事に対するより完全なオーナーシップを与えます。そして私たちはまだ採用を続けています。
•最高のモデルを使うことが、AI の限界を学ぶ方法です。セクション 4 で説明した検証とコードレビューのセットアップは、入手可能な最も強力なモデル上で動作しています。開発者生産性をリードする同僚は、これを私たちの最もコストパフォーマンスの良い支出だと呼んでいます。
•コストは製品を通じて下がるはずです。私たちの開発の多くが、自社製品である Manus Studio で行われるようになったため、使用データから tokens がどこで無駄になっているかがわかります。修正は製品に反映されるので、ユーザーにとっても Manus をより効率的にするはずです。モデルがより安くなり、無駄を取り除くにつれて、今日のコストは大幅に下がると予想しています。これは信念であり、約束ではありません！
10. まだうまくいっていないこと
中断は減りましたが、注意はより断片化しています。かつて 1 日に 4、5 つのことを処理していた人が、今では一度に 20 や 30 のことを進めているかもしれません。切り替えごとにコンテキストの再読み込みが必要です。AI は人ができることを拡張しますが、同時により多くをするよう人を押しやります。ある PM は、タスクが実行されていると、別のエージェントを起動したくなるのを我慢できないと私に言いました。より多くのことをするのが目標ではありません。私たちはこれを祝うべきペースではなく、解決すべき問題として扱っています。
情報はより散在しています。私たちのプロダクト責任者は、以前はすべての変更とその理由を把握していました。今では、問題のスクリーンショットを撮って Mono に「誰がこれを変更したの？」と尋ねることがあります。おかしな話ですが、質問は本物です。全員が製品を変更する権限を持つとき、全体に対して責任を持つのは誰でしょうか？
共有権限の再設計が必要です。仕事が共有・引き継ぎでき、エージェントが私たちの会話のより多くに参加するようになると、何を開放し、何に承認が必要かを決めなければなりません。
私たちの修正はまだ基本的なものです。今のところ、1 つのエージェントが他のエージェントを監督し、行き詰まっていることと人間の判断が必要なことのみを報告しています。これはもっと改善できることを私たちは知っています。
11. 次に何を構築するか
これらの問題は、他のチームもおそらく必要とするプロダクト作業を示唆しています。これらの機能は事前に計画していたものではありません。私たち自身が繰り返しぶつかっていた問題から生まれたものです。
•共有ワークスペースとしてのセッション。誰かが問題を提起し、デザイナーが解決策を提案し、エンジニアがそれを構築し、PMが運用する。すべてが同じ場所で行われます。
•デバイスや人をまたいで進む作業。ローカルマシンとクラウドマシンが接続されたままなので、人が離れても作業を継続できます。
•人が考えつかなかった選択肢を見つけるAgent。適切な権限を持ち、会社のシステム内で動作するAgentは、指示を実行するだけでなく、解決策を提案できるべきです。
まず私たち自身で試してから、ユーザーに提供します。
12. 人が今していること
一列に並んだAgentセッションを開いているエンジニアは、単に効率性の話ではありません。これは組織が何に基づいて動いているかの変化です。かつて企業は役割と階層を通して情報を動かしていました。一人ができることは、どれだけの人とリソースを活用できるかに依存していました。今では、AIにコンテキストとツールを与えるのに少し時間を使い、判断や決定により多くの時間を使います。ますます頻繁に、問題を私たちに持ちかけてくるのはAgentです。それについて何をするかを決めるのは、依然として私たちの仕事です。
こんな冗談を言ったことがあります。Manusがこれだけできるなら、なぜオフィスに来るのか?Agentに任せればいい、と。しかし、重要な問いは依然として人が提起し、議論し、決定する必要があります。たとえば、良いプロダクトとは何か?あるいは、少し誇張して言えば、AIの限界を押し広げ続ける実収益を伴う素晴らしいプロダクトを作るのか、それとも利益率を狙うのか?AIは私たちがどちらを望んでいるか知りません。私たちは知っています。文化と信頼は、日々、そして重要な瞬間に、一緒に物事を解決していくことから生まれます。それがすべてのセッションの作業の土台となる基盤です。
ですから、今のところ、私たちの答えはこれです。AIネイティブな組織としての実験において、人の役割は減っていません。むしろ、最も大きなインパクトを与えられる領域、つまり問題を定義し、品質を判断し、何に取り組む価値があるかを決め、結果に責任を持つことに、より集中するようになりました。
だからこそ、私たちは今も採用を続けています。人のスキルと判断力は、この働き方の中心にあり、それは当分変わりません。
これを書いている今、1年後にこの投稿が何を語っているのか興味があります。会社ごとに目標、構造、文化は異なるため、標準的な答えや最終形はないかもしれません。しかし、Agentを構築する会社にとって、人とAIがどう連携して働くかを突き詰めることは、選択肢ではありません。それは仕事の一部です。私たちは取り組み続け、学んだことを共有し続けます。
数字についての注記。この投稿の数値は社内記録に基づいています。チームサイズとPMのシッピング数は10月下旬時点のものです。一部は推定値、または測定ではなく個人の経験に基づくものです。
