Sycamore Buildとは？機能・料金・使い方と企業導入時の確認点

Sycamore Buildは、業務で達成したい成果を自然言語で伝え、文書、業務プロセス、データ、会議情報、承認済みのシステムアクセスをもとに、AIエージェントを含む業務ソフトウェアを構築するためのSycamore Labsのプラットフォームです。

公式ページでは、最初に業務を理解してチームがレビューできる仕様・計画を作り、その後に調査、設計、実装、既存システムとの接続、テスト、デプロイ、変更を進める流れとして案内されています。Sycamore Build公式ページ

重要な点：公式の公開説明では、稼働中のアプリケーションに対し、利用者が変更を依頼し、新しい計画をレビューし、版をテストしてから同じリリース経路で昇格させる流れが示されています。本記事では、これを「無条件に本番を自律変更する機能」とは扱いません。企業で試す際は、変更内容、承認者、評価、リリース条件を自社側でも設計してください。

Sycamore Buildでできること

Sycamore Buildは、AIエージェントを含むアプリケーション、エージェントチーム、業務プロセス、それらが出力するレポート、ダッシュボード、Webサイト、プレゼンテーションを構築対象として案内しています。CRM、文書、データ基盤、チケット管理、コミュニケーションツールなど、既存の業務システムにつなぐ構成も想定されています。公式の機能説明

表中の「公式ページで案内される内容」はSycamore Build公式ページに基づきます。「導入側が確認したいこと」はMojiによる実務上の提案です。

「自己改善」は何を意味するのか

Sycamore Buildは、構築後もアプリケーションを変更・改善できることを案内しています。ただし、現行の公開説明で示されている変更の経路は、変更を依頼する、計画をレビューする、版をテストする、リリースするというものです。Buildの変更・リリース説明

そのため導入判断では、「自己改善」を人の関与なしに業務ルールや権限を変更し続けることとして解釈せず、運用結果を受けて変更案・変更版を作り、チームが確認して昇格させる仕組みとして評価する方法が現実的です。

顧客への送信、契約・価格の確定、返金、権限変更、データ削除のように、影響が大きく元に戻しにくい操作は、初期PoCから自動実行の対象にしないことをMojiでは提案します。委任範囲、承認、停止、監査ログの考え方は、AIエージェントのガードレール設計で詳しく解説しています。

Sycamore Governとの違い

Sycamore Buildは、業務意図をアプリケーション、エージェント、プロセスへ落とし込み、構築から本番環境への展開まで扱う側の製品です。

一方のSycamore Governは、組織が構築・購入したAIシステムを把握し、利用目的、データ・ツールへのアクセス、モデル、人による監督、評価、承認、実行時ポリシー、予算、証跡を扱うコントロールプレーンとして案内されています。高い影響を持つ操作には承認ゲートと範囲を絞った制御を置き、必要に応じて実行停止や接続の削除を行えると説明されています。Sycamore Govern公式ページ

Buildで作成したシステムは、所有者、バージョン、環境、モデル、ツール、ポリシー、履歴とともにGovernの統制モデルへ入るとされています。将来の本番運用を見据える場合は、PoCの時点から、所有者、利用データ、許可する操作、ログの保持方針を記録しておくと、後の統制設計を進めやすくなります。BuildとGovernの連携説明

料金・提供状況・日本での利用可否

2026年11月4日に確認したSycamore Buildの公開ページには、アカウント開始とデモ依頼の導線があります。Sycamore Build公式ページ

一方で、同ページでは公開料金表、日本向けの提供地域、国内サポート、データ処理・保管リージョンに関する具体的な条件は確認できませんでした。日本法人が契約・利用できるか、契約主体、サポート言語、処理・保管リージョン、利用できるクラウド展開方式は、導入前にSycamore Labsへ確認してください。

料金も公開ページだけでは確定できません。見積もりを受ける際は、基本料金だけでなく、モデル利用、実行、ホスティング、ログ保管、追加環境、専用環境、BYOC（自社クラウド持ち込み）に関する費用・条件を文書で確認しましょう。

確認すべき料金・契約チェックリスト

• 月額または年額の基本料金と、利用者、ワークスペース、環境ごとの課金単位
• モデル利用、ビルド、テスト、実行、ホスティング、ログ保管のうち、従量課金となる項目
• 本番環境、監査ログ、SSO／SAML、専用環境、BYOCに関する契約条件
• 日本から利用する際の契約主体、請求通貨、サポート時間、データ処理・保管リージョン
• データ保持期間、削除手順、サブプロセッサ、障害時の通知、データのエクスポート可否

このチェックリストはMojiによる提案です。

始め方：最初のPoCを安全に設計する6手順

1. 1業務に絞る：最初は、対象範囲、入力、期待する出力、例外を説明できる業務を選びます。全社横断の自動化を初回の目標にしません。
2. 入力資料の正本を決める：現行手順、規程、データ項目定義、例外一覧、承認者を整理します。古い手順書と口頭ルールを混在させないようにします。
3. Buildに渡す権限を最小化する：初回は読み取り専用の資料、ダミーまたは匿名化済みデータ、開発環境のAPIを優先します。本番システムの更新や外部送信は段階的に検討します。
4. 計画を業務担当者がレビューする：仕様案について、判断主体、入力、出力、例外、禁止操作、不明時のエスカレーション先を確認します。
5. 評価ケースで受入判定する：通常ケースだけでなく、情報欠落、矛盾した入力、権限外の依頼、停止すべきケースを含めます。対象業務の選び方はAIエージェントとは？導入判断・実践手順も参照してください。
6. プレビューから限定本番へ進める：Buildはプレビュー、開発、本番の環境別リリースとロールバックを案内しています。最初は人が成果物を確認して実行する運用にし、合格基準を満たした操作だけを段階的に委任します。環境別リリースとロールバックの公式説明

評価シートのテンプレート

以下は、Sycamore Buildに限らず、業務アプリ構築エージェントを比較するためのMojiによる評価テンプレートです。製品名だけで結論を出さず、同じ入力品質、同じ業務ケース、同じ許容誤差で比較してください。

正答率や自動化率の合格ラインは、モデル、入力資料の品質、外部ツール、失敗時の影響、許容誤差で変わります。顧客への送信や金銭処理では、社内文書の下書きよりも厳しい人の確認と停止条件を設ける必要があります。評価ケースの作り方はLLM評価の進め方、社内文書を参照する場合の評価データ設計はRAG評価データセットの作り方を参照してください。

既存のAIアプリ開発基盤との違い

Sycamore Buildの公開説明で特徴的なのは、業務の記述からアプリケーションを作る工程だけでなく、仕様レビュー、テスト、環境別リリース、変更履歴、Governによる統制をつなげている点です。また、複数モデル、Sycamore管理環境・専用環境・自社クラウドへの展開、MCPを介したツール公開も案内されています。Buildの公式FAQ

ただし、公開仕様上の機能説明だけで、自社の既存SaaS、データ基盤、認証基盤で同じ構成を利用できるとは判断できません。接続できる製品、コネクタごとの権限粒度、MCPの実装範囲、データ境界、利用地域は、デモと技術確認で個別に確認してください。API・MCP・A2Aが担う接続範囲の違いは、API・MCP・A2Aの違いで整理しています。

まとめ

Sycamore Buildは、業務の目的を自然言語で説明し、既存の文書・システム・専門知識を踏まえて、エージェント型の業務ソフトウェアを構築し、テスト、デプロイ、更新まで進めるための企業向けプラットフォームです。

導入時の判断軸は、「どこまで自律的に作れるか」だけではありません。誰が仕様を承認するか、どのデータと操作を許可するか、どの評価で本番昇格を決めるか、異常時に誰が止めるかを、最初のPoCから決めることが重要です。

2026年11月4日時点で確認した公開情報では、料金、日本での提供条件、データ処理リージョン、個別コネクタの対応状況は確定できません。日本での導入を検討する場合は、公式デモ・問い合わせで契約条件と技術要件を確認したうえで、可逆的で影響範囲を限定しやすい業務から評価を始めてください。