Sierraは、会社全体をどうAI-pilledしたのか

2026年1月、SierraのエンジニアはClaude Code、Codex、Git worktreeを使い、複数のエージェントを並列で走らせ始めました。

Sierraの公式記事によれば、一部のエンジニアリングタスクでは、5倍の仕事量を進められたとしています。

そこで同社は、より大きな問いを立てます。

エンジニアが一カ月でここまで変わるなら、会社にいる全員を同じ状態へ近づけるには何が必要か。

6人のAI acceleration teamがつくられました。ここから始まったのは、成功事例の横展開ではありません。いくつかの設計を試し、失敗し、捨て、会社の仕事に合う形へ組み直す過程でした。

最初の設計は、直感的で、間違っていた

Sierraは、職種ごとのエージェントを用意しました。

サポート向けのPINE、データ分析のPinewood、エンジニアリングのPinecone、営業のReggie Jr。それぞれの役割に、専用AIを割り当てる考え方です。

一見すると合理的です。営業には営業AI、サポートにはサポートAIがいればよい。

実際には、社員が「どのエージェントに何を頼むのか」を覚える負担が生まれました。もっと深い問題もありました。会社にとって重要な仕事は、一つの部署の中だけでは終わりません。

製品を届ける仕事には、開発、営業、マーケティング、法務、オペレーションが関わります。顧客課題の調査も、Slack、GitHub、データ基盤、CRM、インシデント管理をまたぎます。

役割別エージェントは、組織図には沿っていました。仕事の終わり方には沿っていませんでした。

一つのAgentにしたのは、入口を減らすためではない

Sierraは職種別エージェントを、Pineconeという一つのエージェントへ統合しました。

一つのSlack handle、一つのURL、質問から完成まで切れない一つのthread。Pineconeが必要なシステムと手順を選ぶため、社員は内部の複雑さを引き受けません。

重要なのは、チャット窓口の統合ではありません。

仕事を「営業の依頼」「法務の依頼」「開発の依頼」と分割せず、終わらせるべきJobとして扱うことです。技術が複雑さを吸収し、人は目的と判断を渡す。

この思想は、AIの数を増やす発想とは逆です。

部署の数だけAgentを作ると、組織の境界がAIにも複製されます。一つのAgentが仕事全体を受け取ると、改善された能力は会社全体で再利用されます。

Magic Momentの論で読むと、一つにする理由はAI体験をきれいにするためではありません。部門をまたぐたびに、顧客との時間をリセットしないためです。同じ顧客の会話が、営業、法務、開発で別々の事実になっている限り、Agentは引き継ぎを速くするだけで、会社の判断は一つになりません。

セッションではなく、仕事が終わるまで持続する

多くの仕事は、一度の会話で完了しません。

数日、数週間、ときには数カ月かけて、情報が増え、優先順位が変わり、人の判断を待ちます。呼ばれたときだけ現れ、セッション終了とともに文脈を失うAIでは、途中までしか担えません。

Pineconeは、Jobが終わるまで状態を持ち続けます。

成果物にwebhookが発火する。Linearへタスクが入る。レビューが戻る。その時点で必要な情報を集めて初稿をつくり、人の判断が必要な場所で人を呼ぶ。

会議前には準備メモが置かれ、面接後には評価のたたき台があり、レビューには要約、主要リスク、コメント案が添えられる。

目的は通知を増やすことではありません。未完成の仕事が人へ届く量を減らすことです。

ただしSierraは、ここも完成済みとは書いていません。現在も多くのセッションは人のプロンプトから始まります。Agentが必要なときに人へ判断を求める関係へ反転することが、次の方向です。

ボトルネックは知能から、会社固有の文脈へ移った

Sierraは、現在のフロンティアモデルは多くのビジネス業務に十分な能力を持つと捉えています。

そのとき不足するのは、会社固有の情報です。

自社のワークフロー、過去の経緯、顧客との関係、明文化されていない判断。モデルの学習データには存在しない文脈が、仕事を最後まで進めるときのボトルネックになります。

この「会社固有の文脈」は、社内文書の量ではありません。顧客の沈黙をどう読むか。何を良い提案と考え、何を断るか。どの未来を選ぶか。正解がコモディティ化するほど、こうした主観と美意識が会社の判断資本になります。AI化の役割は、それを平均的な正解で塗りつぶすことではなく、仕事の中で失わずに運ぶことです。

Sierraでは2人のメンバーが、Claude CodeとOpus 4.6を使ったデータ分析Agentを試作しました。MCPとコマンドライン経由でSlack、GitHub、ClickHouse、Salesforce、PagerDutyへつなぎ、以前は午後を費やしていた顧客課題の調査を数分で進められたとしています。

しかし、完全な文脈への接続は、そのまま大きなリスクになります。

無制限のAgentに、会社の全データを渡してはいけません。SierraのMCP Gatewayは、社員本人のアクセス権を引き継ぎ、ツール呼び出しごとにポリシーを適用し、顧客データを分離し、監査証跡を残します。

Sierraの図では、MCP Gatewayは37のシステムへAgentを接続しています。

ここで守るべき原則は、「全部読めるAgent」ではなく、「その社員ができる範囲で、必要な仕事をできるAgent」です。

AgentがUIになっても、記録の置き場所は残す

Pineconeへ依頼した仕事は、具体的な成果物になります。

開発ならPull Request、営業なら提案資料、法務なら契約書、採用なら評価、カスタマーサクセスなら顧客ストーリー。

Sierraは、Agentを新しいSystem of Recordにしようとしていません。

GitHubにはPull Requestを残し、Salesforceには顧客を残し、LinearにはIssueを残す。Agentはそれらをまたぐ操作面になります。

既存システムを置き換えると、成熟した機能を再構築する負担が生まれます。Agent経由の人と既存画面を使う人で、事実が二つに分かれる危険もあります。

AgentはUI、既存System of Recordはbackend。この分担が、一つの入口と一つの事実を両立させます。

7万5千セッションは、成果ではない

Pineconeは2026年3月の最初のcommitから、600人以上に対して7万5千回を超えるセッションを実行しました。現在、SierraのPull Requestの70%はPinecone経由で開かれ、明示的なプロンプトなしで動く数百の自動化もあるとされています。

利用されていることを示す数字として、これは重要です。

一方で、セッション数やツール呼び出し数は活動量です。顧客課題が一度で解決したか、商談が速く進んだか、レビューに使う夜の時間が減ったかまでは示しません。

Magic Momentは、Engagementを単なる反応量ではなく、顧客との関係性に宿る、移ろう時間価値として見ます。不安が確信へ変わったのか。止まっていた合意が次の行動へ進んだのか。7万5千セッションという活動量だけでは、その変化はわかりません。

日本企業が持ち帰るべきなのは、Agentの数ではない

Sierraの過程から持ち帰るべきものは、「全社員へAIを配る」という号令ではありません。

最初に選ぶべきなのは、一つの部署ではなく、複数部門をまたいで完了させたいJobです。

次に、そのJobで必要な文脈と成果物を特定する。既存システムをbackendとして残し、社員本人の権限を継承する。途中の状態を持続させ、人が判断すべき場所を明示する。最後に、利用量から成果へ測定を進める。

Magic Momentが顧客接点を起点に考えるのも、Jobが部門で終わらず、経営判断がダッシュボードから始まるわけでもないからです。会話の中で関係性が動いたMomentを捉え、提案、承認、実行、Outcomeまでつなぐ。そこまで一本で通らなければ、営業AI、CS AI、分析AIを増やしても、会社の時間は分断されたままです。

Sierraの目標は、ただ仕事量を増やすことではありません。

判断、趣味、創造性、関係構築。人にしかできない仕事へ、時間を戻すことです。そして、その時間から育った主観と美意識を、顧客との関係性に根ざした会社の判断として残すことです。

出典

• Sierra — AI-pilling our company: lessons learned