AI をチームで機能させるには：ステートレスなエージェントと共有コンテキスト

ひとりで使う AI エージェントは、驚くほど頼りになります。あなたの書き方を覚え、プロジェクトを記憶し、週ごとに賢くなっていく。ところがチームに持ち込んだとたん、おかしなことが起こります。エージェントを増やしても成果は伸びず、気づけば人を減らすどころか増やしている。

気のせいではありません。MIT の NANDA イニシアチブは 2025 年のレポート『The GenAI Divide』で、企業の生成 AI パイロットのうち急速な売上増につながったのは約 5% にとどまると報告しました。著者が原因に挙げたのはモデルの性能ではなく、学習のギャップです。汎用の AI ツールは、その会社ならではの仕事の進め方を学ばず、合わせてもくれない、という指摘です。

私たちはこの 2 年間、実際のチームでエージェントを動かし、やり方を 5 回作り直してきました。ツールをつないだチャットボット、ターミナルで動くコーディングエージェント、個人の PC を長期記憶にするエージェント、職種を割り振ったエージェントだけの「AI 会社」、そして今のやり方です。この記事は、失敗を重ねた末に残ったものをまとめたものです。結論を先に言うと、エージェントを増やすのはやめて、ステートレスにし、記憶はチームに持たせることです。

ひとりで使えば強い AI が、チームでは失速する理由

エージェントの記憶は、それぞれが孤島になる

教えたことを覚えてくれるエージェントは、ひとりで 1 台の PC を使う分には大きな進歩です。しかしチームでは、その記憶こそが問題になります。

営業の A さんと B さんが、それぞれ「顧客メールに返信する」エージェントを作ったとします。B さんのエージェントは使うほど良くなり、A さんのエージェントは追いつけない。B さんのエージェントが学んだことは、A さんのエージェントには一切届きません。記憶が、それを作った人のところにしかないからです。理想ははっきりしています。A さんと B さんが同じエージェントを使えばいい。二人を隔てているのは、エージェント自身が持つ記憶なのです。

エージェントが増えるほど、人がつなぐ場所も増える

以前の会社で、8 桁規模の ERP を導入したことがあります。業務の整理だけで 20 人以上が丸 1 年かかり、稼働後は各部署がシステムを使いこなせる人を新たに採用しなければなりませんでした。システム以外に、ほぼ同額がかかった計算です。会社の成長には役立ちましたが、コスト削減にはなりませんでした。ソフトウェアを使うのは結局人で、人がボトルネックであることは変わりません。システムが完璧になるほど、使う側にはより高い力が求められます。

エージェントも同じことを繰り返します。エージェントが 1 つ増えるたびに、人が入力し、確認し、ほかの仕事とつながなければならない接点が 1 つ増える。『人月の神話』の古い教訓どおりです。2 人なら連絡経路は 1 本、10 人なら 45 本、50 人なら 1,225 本。企業が「人材密度」を語るのはこのためで、エージェントにも同じ考え方が必要です。私たちはこれを知能密度と呼んでいます。エージェントは少ないほどよく、1 つ 1 つが強いほどよい。

速くなった気がすることと、実際に速いことは別物

METR は 2025 年にランダム化比較試験を行いました。経験豊富なオープンソース開発者 16 人が、長年メンテナンスしてきた自分のプロジェクトで、実際のタスク 246 件に取り組みました。AI の使用を認めたタスクは、かえって 19% 時間がかかりました。開始前、開発者は AI で 24% 速くなると予想し、終わった後も 20% 速くなったと感じていました。2025 年初頭のツールでの結果で、METR 自身もすでに古い結果だと明記しています。それでも教訓は変わりません。ひとりが速くなったと感じても、チームの成果が増えたとは限らないのです。

1. エージェントはステートレスに、記憶はチームに

エージェントが持ち込むのは知能だけで十分です。チームが知っていることは、チーム自身が持つ 1 か所に置く。私たちはそれをコンテキストデータベースと呼んでいます。中身は 4 つです。

資料：ドキュメントとデータ。
ルール：仕事の進め方を定めたマニュアルとスキル。
権限：誰が何を見られ、誰が何を変えられるか。
履歴：誰が、いつ、何を変えたか。

このコンテキストはチームに 1 つだけで、すべてのエージェントがそれを読みます。管理するのはその 1 つであって、エージェントそれぞれが何を覚えているかを追いかける必要はありません。

効果は 3 つあります。まず、エージェントを替えても何も失いません。今日 Claude Code と Codex を行き来しても、来年まったく新しいものに替えても大丈夫です。次に、同僚同士が孤島でなくなります。B さんが教えたことを、A さんがその日の午後から使えます。そして、人が辞めても、教えたことはチームに残ります。

エンジニアなら見覚えのある形でしょう。Web のアーキテクチャはずっと前にこれを学びました。サービスはステートレスにし、状態はデータベースに置く。だからサービスはいつでも入れ替え、スケールできる。チームで AI を使うときも同じ分け方が要ります。ステートレスなエージェントと、コンテキストデータベース。

その「状態」をどこに置くべきか迷っているなら、エージェントのメモリ・ナレッジベース・システムオブレコードの違いで比較しています。

2. エージェントは職種ではなく、権限で分ける

エージェントを導入するとき、ほとんどの人は無意識に組織図をなぞります。営業エージェント、SEO エージェント、プロジェクト管理エージェント。私たちもまさにそうして、職種のある「AI 会社」を作り、そして自分たちで壊しました。

人間に組織図が必要なのは、ひとりの能力には限りがあり、何でもはできないから分業するためです。AI は違います。ほぼ何でもでき、いくらでも複製できる。それを組織図どおりに分けるのは、1 億人の天才を 10 人の平凡な作業者に変えるようなものです。実際、エージェントを細かく分けるほど結果は悪くなり、必要な人はむしろ増えました。エージェント間で受け渡すたびに、仕事が少しずつ薄まっていくのです。

うまくいく分け方は 1 つだけ、権限、つまりそのエージェントがどのデータに触れられるかです。多くのチームでは 2 つで足ります。

社内向けのエージェント 1 つ：広い権限を持ち、チーム全員が使う。
社外向けのエージェント 1 つ：顧客やパートナーに対応し、必要最小限の権限だけを持つ。サポート用のエージェントが給与表を読めてはいけません。

いま見かけるマルチエージェントの多くは、職種が違うからではなく、権限が違うから分かれているにすぎません。

3. スキルは少なく、全員が同じものを使う

全員がエージェントを持つと、全員が自分のスキルを書き始めます。やがて同じ仕事に 10 種類のスキルができ、どれもチームの知恵を集めたものにはなっていません。

スキルとは何か。私たちの定義は、SOP に、その背後にある知識と基準を加えたものです。それが独立して存在する理由は、スキルがボタンだからです。人が「このやり方でやってほしい」と AI に明示的に頼む起点です。ボタンが増えるほど、使われないボタンも増えます。100 個のスキルを書いた同僚が辞めたら、誰がそれを引き継ぐのでしょうか。

だから、導入が深まるほどスキルは減っていきます。チームの知識は共有のコンテキストに戻し、スキルは次の 2 つを満たすものだけ残します。

毎週、誰かが使っている。 今週誰も触っていないなら、存在する必要はありません。
人の判断が必要である。 判断のいらない純粋な実行なら、完全に自動化して終わりにします。

ふるいにかけて残るものは多くありません。そして、それがチームの仕事の進め方の中核です。残った数個には担当者を決め、更新し続けます。10 個のうちどれを残すかを決めるのは、マネジメントであり、センスの問題です。

4. 判断は人に残す

業務を完全に自動化しようとしないでください。チームが生み出すものは最終的に顧客の前に出ますが、顧客の期待は上がり続けます。期待が上がったことに気づくのは判断であり、判断とはセンスです。誰も基準を示さず、誰も結果を見ない AI は、どんどん無難で凡庸になっていきます。完全に自動化できる業務は、誰にでも真似できる業務です。

よく知られた例が Klarna です。2025 年 5 月、同社の CEO は Bloomberg に対して、AI ファーストのカスタマーサービスは安かったが品質は下がったと語り、顧客がいつでも人と話せるよう、再び人の採用を始めました。

とはいえ、すべてのステップを見張ることもできません。人を正しい位置に置く習慣は 3 つです。

毎日 1 つの入口。 肝心なステップに、チームが毎日実際に開いて応答するスキルの入口を置きます。高い基準を持つ人に任せ、少なくとも週に 1 回は改善します。
毎週 1 本のレポート。 自動化は、成果物を納めた時点では終わりません。推奨アクション付きの日報や週報を出し、やるべきことを人が承認し、やるべきでないことを止めた時点で完成します。たとえば SEO エージェントなら、昨日のトラフィックを報告し、今日狙うキーワードを提案し、先月増えた流入が自社の商品とは無関係な検索だったことも指摘してくれます。
定期的な「何が良いか」を話し合う場。 難しいのは AI を業務につなぐことではなく、何が良くて何が良くないかを合意することです。人が集まって話し合い、外部の視点も取り入れます。社内の人は立場上、本音を言いにくいこともあるからです。

人が操作すればボトルネックになり、人が判断すれば堀になる。

このやり方を取り入れたチームで起きたこと

一緒に取り組んでいる 3 つのチームの例です（社名は伏せます）。

あるゲームテクノロジー企業は、1 か月で、予定していたエンジニア 50〜100 人の採用を止め、約 20% の人員を新しい役割に移す計画を立てました。
2 社目は、3 か月で人員を配置転換し、事業ラインを増やしました。
あるオンライン小売企業は、毎月の SEO エージェンシー費用をなくし、1 人が担当する形に切り替えました。その人の毎日の仕事は、エージェントの日報を読んで判断を下すことです。

どのケースでも、人は操作する側から判断する側に移りました。

今週できる 3 つのこと

チームで作ったエージェントを書き出し、「明日 Claude Code や Codex に替えても仕事は続くか」と問う。 続かないなら、チームの知識がチームではなくエージェントの中に閉じ込められています。
スキルの数を数える。 スキルに直接書き込まれた知識を共有のコンテキストに戻し、2 つのルールでふるいにかけます。どちらも満たさないものは削除するか、完全に自動化します。
すべてのワークフローで、人が承認する瞬間を指し示す。 指し示せないなら、まだ本番に出す段階ではありません。

Busabase の役割

私たちが Busabase を作ったのは、このコンテキストデータベースになるためです。テーブル、ドキュメント、スキル、アプリを 1 か所にまとめ、チームのすべてのエージェントとすべての人が同じものを使います。MIT ライセンスのオープンソースで、自分の PC で動かすことも、チームでは Busabase Cloud を使うこともでき、いま使っているエージェントをそのままつなげます。

ここまでの考え方は、Busabase では具体的な形になっています。

記憶はチームのもの：すべてのエージェントが同じワークスペースを読み書きします。
権限で分ける：API キーには読み取り、変更リクエスト、書き込み、管理の 4 段階があります。変更リクエスト権限のキーを持つエージェントは変更を提案できますが、自分の提案をマージすることはできません。
スキルは少なく：スキルは共有のワークスペースに置かれるので、全員が同じバージョンを使い、作った人が辞めても残ります。
判断は人が：提案された変更は、誰かがレビューするまで受信箱で待ちます。日報や週報はテーブルとドキュメントに書き込まれ、1 か所で読んで承認できます。

単なる AI テーブルではない理由をもっと詳しく知りたい方は、Busabase が解決する問題からどうぞ。試すなら、まず 1 つのプロジェクトから。最新の進捗とチームのやり方をワークスペースに入れ、いま使っているエージェントをつなぎ、「今週何が変わった？」と聞いてみてください。

Busabase Cloud を無料で始める、またはテンプレートセンターから既製のワークスペースを選べます。

人が操作するためのシステムを作るのも、エージェントを増やすのも、もうやめましょう。コンテキストは AI に、センスは人に。