セルフホスト型サービス
twentyhq/twenty avatar
twentyhq/twenty

Twentyをコードで拡張できるCRMとして導入する

Salesforce の代替を目指すオープンソース CRM。NestJS、PostgreSQL、GraphQL を基盤に、オブジェクト、フィールド、ビューをコードで定義できる。

スター 56,749フォーク 9,073TypeScriptライセンスはプロジェクトにより異なります

ひと目でわかる

これは何?
TwentyのCRMオブジェクト、ビュー、ワークフロー、AIエージェント、アプリ開発、クラウドとセルフホストの選択肢をREADMEから整理します。
誰に向いている?
自社業務に合わせたCRMをコードで定義し、版管理しながら進化させたい技術チームに向きます。まず`npx create-twenty-app my-app`で検証用アプリを作り、オブジェクト、フィールド、ビュー、publish結果を確認してください。
商用利用できる?
まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
今もメンテナンスされている?
されています。最後のコミットは 1 日前です。
何の言語で書かれている?
主に TypeScript です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月14日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

コードで作るCRMの考え方

TwentyはSalesforceに代わるオープンなCRMとして紹介され、技術チームが業務に合わせたCRMの部品を作り、出荷し、版管理できることを狙っています。READMEが挙げる部品はオブジェクト、フィールド、ビュー、ワークフロー、エージェントです。既製画面の設定だけでなく、アプリケーションの変更をコードとして扱う設計です。

この方式は、営業案件や顧客情報の構造が自社固有で、変更履歴を開発フローへ置きたい組織に合います。短時間で標準CRMだけを使いたい場合は、コード化の運用負担を見積もります。顧客データの移行、権限、監査、削除要件はREADMEの製品紹介からは確定しません。

Cloudとセルフホスト

InstallationにはCloud、Build an app、Self-hostingの3経路があります。Cloudはtwenty.comでワークスペースを作り、インフラ管理なしで始める方法です。自社基盤で動かす場合はDocker Composeが案内され、開発への参加にはlocal setup guideが示されています。

選択の境界は、運用責任とデータ管理です。Cloudでは契約、保存場所、更新、管理権限を確認し、セルフホストではDB、Redis、バックアップ、アップグレードを自分で管理します。READMEだけで両者の機能差やSLAを推測せず、同じテストケースを用いて必要な業務がどちらで成立するかを見ます。

create-twenty-appで雛形を作る

アプリ開発の入口としてREADMEは`npx create-twenty-app my-app`を示しています。サンプルでは`defineObject`と`FieldType`を使い、dealオブジェクトに名前、金額、締め日を定義しています。その後、`npx twenty app:publish --private`でワークスペースへ公開する流れです。

検証ではサンプルをそのまま本番へ出さず、検証用のオブジェクト名とフィールドを定義します。生成されたコード、公開先、private指定の結果、既存データとの関係を記録します。アプリ開発ガイドがobjects、views、agents、logic functionsを扱うと案内しているため、必要な拡張がどの層に属するかを切り分けます。

オブジェクトとビューの運用

TwentyのREADMEは現代的CRMの基本部品としてobjects、views、workflows、agentsを掲げています。オブジェクトは業務上の対象、フィールドは属性、ビューは利用者が見る切り口として設計します。コードで定義するなら、名称変更や必須化が既存レコードと画面へどう影響するかを版ごとに確認します。

最初のテストではdealのような小さな対象を作り、作成、編集、検索、一覧表示、権限の各操作を行います。金額や日付の型、空値、タイムゾーンを確認し、画面で見える値とAPIやエクスポートの値を比較します。ワークフローやAIエージェントを追加する前に、基本データのライフサイクルを固めます。

Stackから見える運用要件

READMEのStackにはTypeScript、Nx、NestJS、BullMQ、PostgreSQL、Redis、React、Jotai、Linaria、Linguiが列挙されています。これはフロントエンド、API、ジョブ処理、データベース、キャッシュを含む構成を示します。セルフホストでは、画面だけを起動すれば済むとは考えず、依存サービスと永続データの管理を含めます。

更新時はDocker Composeの設定、PostgreSQLのバックアップ、Redisの役割、非同期ジョブの再実行を確認します。素材からは必要なリソースやSLA、移行手順の詳細までは確認できません。リリース版を固定し、検証環境でアプリ公開、既存レコード、ワークフローを再現してから更新します。

Twentyのライセンスと採用判断

メタデータではmainブランチ、2026年8月28日の更新、55,790 stars、8,781 forks、177件のopen issuesが確認できます。素材のライセンス欄は空欄なので、利用と改変の条件はリポジトリのLICENSEで確認します。コミュニティ規模やロードマップの存在は参考になりますが、顧客データを扱う安全性を証明するものではありません。

業務モデルをコードで定義し、CRMの変更を開発者が管理したいチームに候補です。非技術ユーザーだけで即日運用したい場合は、Cloudの操作と自社要件の差を先に確認します。検証用ワークスペースでデータモデル、private publish、権限、バックアップ、更新を通し、条件を満たす機能だけ本番へ移します。

Twenty固有の確認では、検証用アプリでdealの作成、金額と日付の編集、ビュー表示、private publish、再デプロイを順に実行します。PostgreSQLのバックアップから戻せるか、非同期処理の失敗を追跡できるか、権限の異なる利用者が同じデータを見られないかを確認します。フィールド変更が既存レコードとエクスポートへ与える差も記録します。Cloudとセルフホストで同じ業務操作を比較し、責任分界と移行手順を文書に残します。ワークスペースを削除したときのデータとアプリの扱いも確認します。アプリの版を戻したときに既存データを安全に読めるかも調べます。顧客データの復旧結果も確認します。

編集部の結論

自社業務に合わせたCRMをコードで定義し、版管理しながら進化させたい技術チームに向きます。まず`npx create-twenty-app my-app`で検証用アプリを作り、オブジェクト、フィールド、ビュー、publish結果を確認してください。顧客データを扱う前にDocker Composeの保存、権限、バックアップ、クラウドとの責任分界を明確にします。

公式情報源

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
コミュニティノート

コミュニティノート