各部門にAIを配ったら、逆に使いにくくなった

チームが最初に取った方法は、役割ごとに4つの専属agentを分けることだった。カスタマーサポートagent（PINE）、データ分析agent（Pinewood）、エンジニアリングagent（Pinecone）、セールスagent（Reggie Jr）。この発想は直感的に見えたが、実際に使ってみると問題が出てきた。

表面的な問題は、社員がどのagentが何を担当しているかを覚えなければならないことだった。しかもチームは松（パイン）にちなんだ命名を好んだため、PINE、Pinewood、Pineconeが並ぶと見分けがつきにくい。より根深い問題は、会社にとって本当に重要な仕事の大半は部門をまたいで進み、一つの部門内だけで完結することはほとんどないという点だった。

会社とは本質的に、片づけるべき仕事の集合体だ。プロダクトのリリースを例にとれば、それは技術チームだけでなく、セールス、マーケティング、法務、オペレーションにもまたがる。部門が存在するのは、一つのチームや一人の人間では、ある仕事のすべての部分をこなしきれないからだ。AIはこの前提を変えつつある。一つの仕事を最初から最後まで通しでこなせる範囲がどんどん広がっているのだ。

この原理は、Sierra自身のプロダクトですでに一度実証されている。Sierraで組み上げたagentは全工程型で、一つのagentが商品に関する問い合わせから口座開設、トラブルシューティング、請求まで、すべての工程をこなせる。カスタマーサポートは1を、セールスは2を押してくださいという昔ながらのIVR式の振り分けとは違う。

すべてを一つのagentに集約することで、会社は本当の価値、つまり片づけるべき仕事そのものに近づく。改善を一つ加えるたびに全社がその恩恵を受け、全員のスピードが同時に上がっていく。

優れたagentは自分でいつ動くべきかを知っている

たいていの仕事は一回の会話で片づくものではない。数日、数週間、時には数ヶ月にまたがり、その間チームは学び続け、優先順位は変わり続け、新しい情報が絶えず入ってくる。質問されたときにだけ現れ、セッションが終われば消えてしまうagentでは、役に立てる範囲は限られる。

コンテキストを持ち続けることで、Pinecone は自発的にもなった。質問されるのを待つのではなく、次のステップの準備が整った時点で自ら動き出す。たとえば何らかの成果物がwebhookを発火させたとき、タスクがLinearに登録されたとき、レビューが到着したときなどだ。まずコンテキストを集めて一稿目を仕上げ、判断が必要な部分だけを人に渡す。ミーティングの前には、すでにメモが用意されている。面接が終わる頃には、インタビューの記録がすでに下書きされている。レビューが届いたときには、要約と主要なリスク、提案がすでに添えられている。狙いは通知を増やすことではなく、手元に届いてもまだ片づいていない仕事を減らすことだ。

この段階をチームはまだ完全には実現できていない。大半のセッションは依然として人間側が先に口を開く形だ。だが、この順序を逆転させ、必要なときにagentの側から人を探しに来るようにすることこそ、持続性がチームを導きつつある方向である。

AIを阻んでいるのは、あなたの会社を理解していないことだ

以前AIを阻んでいたのは、モデル自体が十分に賢いかどうかだった。今日の最先端モデルは、知能の面ではすでに十分間に合っている。本当のボトルネックは別の場所に移った。会社に固有のコンテキスト、具体的な業務フロー、履歴、そしてどんな学習データにも出てこない判断基準だ。

今年1月、チームの2人がClaude CodeとOpus 4.6を使い、MCP（Model Context Protocol）とコマンドラインツール経由で社内システムに接続し、データ分析agentを組み上げた。それほど多くの追加指示を与えなくても、Slack、GitHub、ClickHouse、Salesforce、PagerDutyを横断して数分で一つの顧客問題を調査できた。以前は半日かかっていた作業が、トラブルシューティングとインシデント対応の第一歩になった。

同じパターンはデバッグの枠を超えて広がっていった。完全なコンテキストを与えられたagentは、顧客との打ち合わせの準備をし、アカウントを調査し、契約書やRFPを確認し、あるプロダクトの意思決定を遡って調べ、あちこちに散らばった作業を一つのまとまった成果物にまとめられる。しかし、agentにこれほど多くのコンテキストを持たせること自体が、新たなセキュリティとプライバシーのリスクになる。

Sierra はこの問題を解決するために MCP Gateway という一層を自社開発した。Pinecone は各社員本人の権限を継承し、ツール呼び出しのたびにポリシーチェックを受け、顧客データは互いに分離され、呼び出しのたびに監査ログが残される。

Sierra MCP Gateway は統一ゲートウェイを通じて37の社内システムに接続しており、すべての呼び出しがここで権限チェックを受ける。画像出典：Sierra公式ブログ

Pinecone は Claude Code と Codex の上に構築されている。この二つの基盤ツールのアップデートは追い風になるが、技術の最先端は絶えず変化していて、あるモデルは計画立案が最も得意で、別のモデルはコーディングが最も得意、さらに別のモデルは文章が最も得意といった具合だ。モデルより上のこの層を自分たちの手に握っておくことで、チームは各タスクを最適なモデルにルーティングでき、あるモデルに障害が起きたときには切り替えられ、コストをコントロールでき、単一のベンダーに縛られずに済む。本当に持続する強みとは、どのモデルもより使いやすくするコンテキスト、ワークフロー、ルーティングというこの層を自分たちで持っていることなのだ。

agentは新しいインターフェース、既存システムはそのまま既存システム

どの仕事も具体的な何か、成果物を生み出す。コードを書くagentは真っ先に自分の成果物を見つけた。プルリクエスト（PR）だ。他の部門にもそれぞれ対応する成果物がある。顧客事例、契約書、RFPの回答、ロードショー資料、人事評価などだ。

これらの成果物は、agentが作業する際の入力であると同時に、agentが差し出す出力でもある。Pinecone にロードショー資料の修正を頼めば、返ってくるのは修正済みの資料そのものであって、「こう直すといいですよ」という一言のチャットメッセージではない。

チームは、これら既存の記録システム（system of record）を置き換えるのではなく、それらと連携する方がうまくいくことに気づいた。GitHub は引き続きPRを保管し、Salesforce は引き続き顧客アカウントを保管し、Linear は引き続きissueを保管する。agentはこれらのシステムの上に架かり、それらをつなぎ合わせる層なのだ。

これらのシステムを置き換えることは、数十年かけて積み上げられてきた成熟したソフトウェアをもう一度作り直すことを意味する。さらに厄介なのは、それによって会社が真っ二つに分かれてしまうことだ。一部の人はagent経由で働き、もう一部の人は従来通りツールを直接使って働き、それぞれ違う記録が残ってしまう。チームが賭けている方向性は、これらのプロダクトが徐々にバックエンドのような存在になり、agentが主要な操作インターフェースになっていくというものだ。

7.5万回動いたことは、本当に良くなったことを意味しない

Pinecone は3月に最初のコードをコミットしてから、すでに7.5万回を超えるセッションをこなし、600人超の社員にサービスを提供してきた。いまや社内PRの70%はPineconeが発行しており、さらに数百件の自動化タスクが、誰にも明示的に指示されていない仕事を静かに処理し続けている。

この手の数字は成果として語られがちで、初期段階ではそれ自体は間違っていない。ツールが実際に使われていて、ロードマップのスライドの上でほこりをかぶっているわけではないことを証明するからだ。しかし、何回セッションが動いたか、ツールが何回呼び出されたかは活動量であって、結果ではない。あるチームは、トークン使用量の数字を見栄えよく積み上げることは十分に可能でも、下流では何も良くなっていない、というケースがありうる。同じエラー率、同じサイクルタイムのまま、ただAIが関わる部分が増えただけということだ。

だからトークン使用量は悪くない出発点だ。チームはまずこのツールを使う習慣を身につけて初めて、それが本当に役に立っているかどうかを測る話ができる。しかし価値はそこにあるわけではなく、チームも話をそこで終わらせたくはない。彼らが問い続けたいのは、agentが実際に何を変えたのかということだ。ある取引の成約が早まったのか、ある顧客の問題が一度で解決したのか、誰かがそのおかげで定時に帰れて、また深夜までかかってレビューを仕上げる羽目にならずに済んだのか。現時点でチームはこれらを測る良い方法をまだ見つけていない。セッション数や呼び出し回数は単に数えやすいというだけであり、このギャップこそが次に埋めるべきものだ。

実験中：AIに今日の出来を自ら振り返らせる

チームは Pinecone に新しいことを試させている。毎日その日にこなした仕事を振り返り、自分自身のスキルセットに対して改善案を出すというものだ。

長期的に見て、チームが欲しいのは、Sierraから絶えず学び自らを改善し続けるagentであって、毎日Sierraの代わりに仕事をこなして終わりというだけのagentではない。

この先、チームはこのシステムをさらに深く掘り下げる、より技術寄りの記事をいくつか公開する予定だ。Allen Chen は Pinecone が経てきた幾度もの反復とその背後の技術アーキテクチャについて、Mihai Parparita は MCP Gateway がどのように完全なコンテキストを安全に収集しているかについて、Rohith Ravi はこのすべてを支える基盤インフラ Agency について語る。

天才を探す時代から、誰もが一人ずつ持てる時代へ

冒頭で触れた1968年のあの研究に話を戻すと、最高のエンジニアと平均的なエンジニアの間には生産性で10倍の差があることがわかっていた。過去50年間、唯一の解決策はそのひと握りの人材を何とかして引き抜くことだった。

今、もう一つの答えが出てきた。誰もが一人一台agentを持ち、あの一握りの人材の優位性を手にするというものだ。今回の変化の意味は、単により多くの仕事を片づけられるようになったことにとどまらない。それは時間を空け、人間にしかできない部分、つまり判断、審美眼、創造力、そして人間関係の維持のために残してくれる。

Sierra は4つの専属AIを全部解体し、Pinecone という統一アシスタント一つに合体させた。社員はもう「誰に聞けばいいか」を考える必要がなくなり、一つの窓口で最初から最後まで済む。同時に彼らは、それを「一問一答」型から脱却させ、自らタスクを見張り、出番が来たら先に一稿を仕上げてから人に判断を委ねるようにした。

しかし、これほど多くの社内システムの鍵を一つのAIに渡してしまうと、新たな悩みが出てくる。このAIは何を根拠に、これらのデータに安全に触れられるのか。

AIを阻んでいるのは実は賢さが足りないことではなく、あなたの会社を理解していないこと、具体的な業務フロー、履歴、社内の人間にしかわからない判断基準を理解していないことだ。Sierra の解決策は、MCP Gateway という名の「権限の関所」を一層挟むことだった。Pinecone がどこかの社内システムに触れるたびに、必ずこの関所を通らなければならない。

小互が一言尋ねると、Pinecone はどのシステムを調べるべきか自分で判断する。ただし呼び出しのたびに必ず MCP Gateway を通り、小互本人の権限だけを使い、顧客データは互いに分離され、一件ごとに記録が残る。GitHub、Salesforce といった既存システムは相変わらずそれぞれの記録を管理し続け、Pinecone はその上に被さる統一窓口にすぎない。もとは半日かけて調べ物をしていたのが、数分で一稿目が出るようになった。

リリースから4ヶ月、数字は華やかだ。まず具体的な体感を一つ見てみよう。同じ顧客のエラー調査でも、