Twentyをコードで拡張できるCRMとして導入する
Salesforce の代替を目指すオープンソース CRM。NestJS、PostgreSQL、GraphQL を基盤に、オブジェクト、フィールド、ビューをコードで定義できる。
ひと目でわかる
- これは何?
- 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の保存、権限、バックアップ、クラウドとの責任分界を明確にします。
コミュニティノート