統合ワークスペースOSS「Macro」の仕組みとチーム共有メモリ

Slack でチームの議論をして、Notion に仕様を書き、Linear でタスクを切り、CRM で商談を管理し、メールで顧客とやり取りする。それぞれのツールは単体では優秀なのに、業務のコンテキストがツールの数だけ分断されていく——この感覚は、10人を超えたあたりから多くの開発組織が抱えるものです。

分断を埋めるために、私たちは連携ツールを足します。Zapier で通知を転送し、MCP サーバーを立ててエージェントから各 SaaS を叩けるようにし、Webhook でタスクとチャットをつなぎます。しかし連携は「コピーを増やす」行為であり、参照関係そのものをデータとして持つわけではありません。結果として「なぜこのタスクが存在するのか」を追うには、結局どこかの誰かに聞くしかない状態が残ります。

この問題に対して「連携でつなぐのではなく、最初から単一のシステムとして作り直す」という解き方を取ったのが、GitHub で公開されているオープンソースプロジェクト macro-inc/macro です。メール・チャット・ドキュメント・タスク・Canvas・AI エージェント・通話・ファイル・プルリクエスト・CRM を同一バックエンド上のブロックとして扱い、それらを横断する「チームレベルの共有メモリ」を持つ点が最大の特徴です。

本記事では、Macro のブロック構造、双方向 @リンクとチャンネルベース権限という統合メカニズム、Rust + SolidJS の技術スタック、Huly・AppFlowy・AFFiNE・Twenty といった類似 OSS との違い、そして AGPLv3 とセルフホストの現実的な位置づけまでを整理します。読み終えたときに「自社で検証を進めるか、見送るか」を自分で判断できる状態を目指します。

なお本記事は、公開されている README・公式ドキュメント・GitHub API から取得した情報のみに基づいて構成しています。ローカル環境での実行やインストールによる動作検証は行っていないため、パフォーマンスや使用感に関する評価は含みません。数値は 2026年8月28日時点で GitHub API から取得した値です。

統合ワークスペースOSS「Macro」とは

Macro は、チーム向けの「オールインワンワークスペース」を掲げるオープンソースプロジェクトです。README では、メール・メッセージ・ドキュメント・タスク・エージェント・CRM を単一の高速なインターフェースに統合し、チームレベルの共有メモリを備えたワークスペースだと説明されています。ホスト版のサービスは Macro 公式サイト から利用でき、ソースコード一式が GitHub で公開されています。

リポジトリの基本情報

※ 上記は 2026年8月28日に GitHub API から取得した値です。

採用可否を判断するうえでまず確認したいのが、メンテナンスの健全性です。最終 push が 2026年8月27日と直近であること、リポジトリがアーカイブ状態ではなくフォークでもない一次リポジトリであることは、少なくとも「開発が止まったプロジェクトを掴む」リスクが低いことを示しています。一方でライセンスが AGPL-3.0 である点は、採用判断に直接効いてくる条件です。この点は後半で詳しく整理します。

なぜ「単一のシステム」として作られたのか

README には、このプロジェクトが生まれた背景が具体的に書かれています。開発元自身が Slack・Linear・Notion・HubSpot・Superhuman を併用していたものの、それらが「単一のシステムとして機能しない」状態にあったこと。そして約20人規模へスケールした際に、会社が MCP と Zapier で辛うじてつながっている状況になり、"The company was not computable."（会社が計算可能な状態になかった）と表現される混乱が生じたことが動機として挙げられています。

開発は NYC とトロントで行われ、約15人のチームが2年間にわたって自分たち自身で使い込む形（ドッグフーディング）で作られたとされています。目指す像として「小規模な企業、あるいは大企業内のチームが "operating system" として使えるもの」という表現が使われており、汎用のドキュメントツールやチャットツールの延長ではなく、業務全体の土台を置き換える意図が明確です。

この背景は、後述するチーム共有メモリの設計思想と直結しています。「ツールをつなぐ」のではなく「最初から一つのデータベースの上に業務全体を載せる」という前提があるからこそ、横断的なメモリが成立するという構造になっています。

Macroを構成する10のブロックと役割

Macro の機能は「ブロック」という単位で構成されます。README には10種類のブロックがテーブルで整理されており、それぞれが既存のどのツールを置き換えうるのかを把握することが、採用スコープを見積もる第一歩になります。

ブロック一覧と代替対象

注目したいのは、これらが個別のアプリではなく同一バックエンドを共有している点です。README では、ドキュメントとタスク、チャンネルメッセージとメールといった相互参照が、双方向グラフ（bidirectional graph）としてネイティブに格納されると説明されています。

メールとCRMが同じ画面に載る意味

Email ブロックは Superhuman に着想を得たキーボードファースト UI を採用しており、j k e といったキーで移動・アーカイブができるとされています。複数の Google アカウントを単一のインボックスで triage でき、メール・メッセージ・@メンション・タスクが同じリストに並ぶ統合インボックスが提供されます。詳細は Email ブロックのドキュメント にまとめられています。

さらにネイティブの CRM 機能により、cmd+k からコンタクト（例: tim@acme.com）や会社ドメイン（例: @acme.com）を引いて、関連するメールやファイルを一覧できると記載されています。

この「メールと CRM が同じ画面に載る」設計は、README が挙げる CRM の課題設定と対応しています。標準的な CRM の問題は「最新でないこと」であり、案件の最新状況を知るには結局 AE や SDR に聞く必要がある、という指摘です。Macro の解決策は、CRM をチームチャットとメールに同居させることでした。メッセージ内で会社レコードを @メンションすれば、クリックひとつで最新状態を参照でき、@メンションがメッセージとレコードの双方向リンクを作るため、後からレコード側で関連会話を辿ることもできます。会社の "Notes" はチャンネル／DM と同じ仕組みで動き、ディールごとに自動でチャンネルが付く設計だと説明されています。

タスク管理を「会話の場所」に寄せる設計

Tasks ブロックについて、README は「issue tracking は死んだ」という Linear のレポートに同意しつつ、より強い主張として「issue tracking はそもそも機能していなかった」と述べています。原因として、会話が起きる場所（チームチャット）とタスクが別システムであること、そして追跡以上の便益が乏しいことの2点を挙げています。

その解決策が「チャンネル・DM に密結合した軽量な issue」です。追跡自体を放棄する案については「別種の混乱」だったとして明確に否定されています。タスクの作成経路は多く、メールから、どこでも c t、markdown ドキュメント内の /task、- [ ] を選択して "Task" に変換、チャンネル・DM での @Macro、エージェントチャット内、外部の MCP・API・SDK という7つが挙げられています。詳細は Tasks ブロックのドキュメント を参照してください。

重要なのは、作成されたタスクが作成元のコンテキスト（例: 顧客からのメール）と双方向にリンクされる点です。これにより「なぜやるのか → タスク → エージェント → プルリクエスト」という連鎖を、単一システム内で監査できると説明されています。タスク管理ツールを別に持つ構成では、この連鎖のどこかで必ずリンク切れが起きるため、ここが構造的な差分になります。

双方向@リンクとチャンネルベース権限

「連携ツールでつなげば同じことができるのでは」という疑問に答えるのが、この統合メカニズムの部分です。README の "How it all works together" では4つのメカニズムが挙げられており、そのうち Bidirectional @linking / Channel-based permissions / One inbox の3つがデータモデルと UI の設計に関わります。

双方向グラフとして保存される参照関係

Bidirectional @linking は、メッセージ内でドキュメントを @メンションすると双方が互いを認識し、ワークスペース全体が「どちらの方向にも辿れるコンテキストの網」になるという仕組みです。連携ツールによる通知転送との違いはここにあります。転送はイベントの複製にすぎませんが、双方向リンクは参照関係そのものを永続的なデータとして保持します。

公式ドキュメントの ブロックとメンションの概念 によれば、ファーストパーティのブロック型は md（ドキュメント）/ email / channel / chat / automation / project / contact / company / call / canvas / code / image / video / pdf / unknown の15種類です。@メンションはホバープレビューを生成し、ドキュメント内では読み取り専用の埋め込みに変換できます。また References パネルから、そのブロックへの全メンション・埋め込みを追跡できるとされています。

チャンネル参加＝アクセス権という権限モデル

Channel-based permissions は、チャンネル内で @メンションしたものが自動的にそのチャンネルのメンバーへ共有される仕組みです。チャンネルに参加すればアクセスを獲得し、離脱すれば失う。README はこれを「権限申請のやり取りが不要になる」設計として説明しています。

権限そのものは全ブロック共通で、owner / editor / commenter / viewer の4段階が用意されています。ドキュメントには公開リンクの機能もあります。

そして One inbox は、メール・チャンネルメッセージ・タスク割当・@メンション・エージェント応答が1か所に届き、Signal と Noise に分割されるという設計です。全体を通してキーボードファーストである点も明記されています。

権限が自動付与されないケースに注意する

運用設計を考えるうえで見落とせないのが、権限の自動付与に例外がある点です。公式ドキュメントは「ドキュメント内の埋め込みやメンションでは権限は自動付与されない」と明記しており、チャンネル内のメンションでメンバーが自動的にアクセス権を得るのとは挙動が異なります。

つまり、ドキュメントに機密性の高いブロックを埋め込んでも、それだけで閲覧者にアクセス権が渡るわけではありません。逆に言えば「ドキュメントを共有したのに埋め込みが見えない」という状況が起こりうるため、共有時に別途権限を付与する運用が必要になります。チャンネル中心の運用とドキュメント中心の運用でアクセス制御の挙動が変わることは、導入時のガイドライン整備で押さえておきたいポイントです。

チーム共有メモリとエージェントの扱い

Macro を他の統合ワークスペース系 OSS と最も強く分けているのが、チームレベルの共有メモリです。エージェント機能を「チャット UI を足したもの」として実装するのではなく、業務データの統合を前提とした記憶の仕組みとして設計している点が特徴です。

毎日1パスで合成されるチームメモリ

README によれば、チームのコンテキストが単一のデータベースに存在するからこそ、業務全体の文脈を持つチームレベルのメモリを提供できるとされています。メモリの更新は cron ジョブで毎日実行され、チームの会話・DM・送受信したメール・作成や完了したタスクなどが対象になります。

ここで重要なのは、個々のイベントを逐次処理するのではなく、1パスで統合的に合成し、以前のメモリと結合して新しいメモリ出力を作るという点です。生成されたメモリは markdown の平文として保存され、任意にエクスポートできると記載されています。手動での更新は AI に依頼する形になります。

一般的なチャットボットのメモリが「そのユーザーとの会話履歴」に閉じるのに対し、Macro のメモリは Agents のドキュメント が示すとおり、メール・メッセージ・タスク・ドキュメント・通話・接続ツールを統合して継続的に更新されるビューから動作します。README では "Refreshed nightly."（毎晩リフレッシュされる）と表現されています。

エージェントへのプロンプト内で特定のチャンネル・ドキュメント・タスク・スレッドを @メンションすればコンテキストを固定でき、検索ステップをスキップできるとされています。また、保存したプロンプトをスケジュール実行する Automations にも対応しており、「毎日のインボックスブリーフ」「金曜のチーム週報」「週次の古いタスク整理リマインド」といった例が公式ドキュメントに挙げられています。

MCP でコーディングエージェントから使う

外部のコーディングエージェントからの利用も想定されています。README には、Claude Code や Codex をはじめとする MCP クライアントをワークスペースに向けるためのコマンドが記載されています。

claude mcp add --transport http macro https://mcp-server.macro.com/mcp

出典: https://github.com/macro-inc/macro

セットアップの詳細は MCP セットアップ にまとまっています。公式ドキュメントによれば MCP アクセスは全プランに含まれ、モデルピッカーによってチャットごとにモデルを選択できます（無料アカウントは高速モデルの Haiku に限定され、Macro Pro で追加モデルが解放されると記載されています）。README では OpenAI・Google・Anthropic といった複数プロバイダのモデルを選べる点がポータビリティの観点から強調されています。

エージェントの実行能力についても踏み込んだ記述があります。README は、Macro の UI でできることのほぼ100%をカバーするツール／MCP サーフェスを持ち、MCP にレートリミットを設けていないと明記しています。SaaS ごとの API 制限に阻まれてエージェントの自動化が頭打ちになる、という課題を持つチームにとっては、この設計は評価軸のひとつになります。

権限継承とアトリビューション

エージェントに広い権限を与えることへの懸念は当然あります。この点について公式ドキュメントは、エージェントはユーザーの権限を継承し、そのユーザーがアクセス可能な範囲のみを閲覧すると説明しています。実行結果はユーザーに帰属し、権限によって境界付けられます。

つまり「エージェント専用の強い権限」を別途作るのではなく、既存の人間の権限モデルの上にエージェントを載せる方針です。チャンネル参加がそのままアクセス権になるという権限モデルと組み合わせると、エージェントが読める範囲はチャンネル設計によって制御されることになります。運用ルールを設計する際は、チャンネルの粒度がそのままエージェントの視野になる前提で考える必要があります。

AI エージェントを Bot やプラグインではなく人間ユーザーと同じ一級市民として扱う設計思想は、Rust 製の OSS ワークスペースである Buzz にも共通して見られる方向性です。Macro の場合はその対象範囲がメールや CRM まで広がっている点が違いになります。

Rust + SolidJSの技術スタックとリポジトリ構成

コントリビュートや自前拡張の現実性を判断するには、リポジトリの構造と技術選定を把握しておく必要があります。主要言語は Rust で、フロントエンドは SolidJS という構成です。

モノレポの構成

README には Layout として以下のディレクトリツリーが掲載されています。

macro/
├── apps/
│   ├── web/       SolidJS client — browser, Tauri desktop, mobile
│   └── docs/      docs.macro.com
├── services/      42 deployable services, workers, and Lambda handlers
├── crates/        167 Rust libraries — domain logic, models, db clients
├── packages/      shared TypeScript — collaboration, lexical-core, loro-mirror
├── infra/         Pulumi definitions
├── docker/        local Compose stack
├── nix/           pinned dev shell and build inputs
└── tooling/       repo scripts and code generators

出典: https://github.com/macro-inc/macro

デプロイ可能なサービスが42個、Rust ライブラリが167個という規模感は、統合ワークスペースという射程の広さをそのまま反映しています。共有 TypeScript パッケージには collaboration・lexical-core・loro-mirror が含まれ、インフラ定義は Pulumi、開発シェルは Nix でピン留めされています。

各サービスはヘキサゴナルレイアウト（inbound アダプタ、ポートを持つドメインコア、outbound アダプタ）に従うとされ、コーディング規約は docs/STYLE_GUIDE.md、PR プロセスは CONTRIBUTING.md に整理されていると記載されています。特定のブロックだけを拡張したい場合でも、まずこのレイアウト規約を読むことが前提になります。

Loro CRDT と Cloudflare Durable Objects による協調編集

リアルタイム共同編集の実装は、技術選定の観点で最も特徴が出ている部分です。公式ドキュメントによれば、同期には Loro CRDT を使用し、バックエンドは Cloudflare Durable Objects で構成されています。Rust の sync-service がドキュメント1つにつき Durable Object の "room" を1つ立ち上げ、クライアントは WebSocket で /document/:id に接続します。

この構成により、マルチプレイヤー編集・プレゼンスカーソル・完全なオフライン対応が実現されると説明されています。README 側では、オフライン編集とその後の再調整（reconciliation）、バージョン管理（履歴・フォーク・履歴スクラブ UI）についても触れられていますが、バージョン管理は v1 段階で「git に近づけるにはやることが多い」と自認されています。

なお、エージェントが CRDT 協調システム上のピアとしてドキュメントを編集できる点も記載されています。開いていないドキュメントも編集対象になるため、Automations と組み合わせれば、markdown ドキュメントを毎日自動更新するといった運用が可能になります。

Cloudflare Durable Objects への依存は、セルフホストを検討する際に確認しておきたい点です。協調編集の中核がマネージドなエッジランタイムに乗っている構成であるため、完全にオンプレミスで閉じた運用を想定する場合は、この部分の扱いを事前に調べる必要があります。

開発環境は Nix が前提

ローカルでの実行手順は Running locally にまとまっています。用意されている経路は2つで、フロントエンドだけを変更する場合はホスト済みの *-dev サービスに向けて Vite をローカル実行する方法（Docker 不要）、バックエンドやデータベースを触る場合は Docker で Postgres・Redis・LocalStack・OpenSearch・Kafka・FusionAuth を起動してローカルスタックを動かす方法です。

いずれの経路でも共通の前提は Nix です。公式ドキュメントには、リポジトリの取得と開発シェルの起動が次のように記載されています。

git clone https://github.com/macro-inc/macro.git
cd macro

nix develop

出典: https://github.com/macro-inc/macro/blob/main/docs/RUNNING_L…

Nix シェルが just・Cargo・Rust ツールチェーン・Bun・wasm-pack・sqlx・zig・cargo-zigbuild を提供するため、これらを個別にインストールする必要はないとされています。Linux では Nix dev シェルが Docker CLI・デーモン・Compose・fuse-overlayfs まで供給するため Nix が唯一のホスト依存になりますが、macOS では Docker Desktop・OrbStack・Colima のいずれかを別途導入する必要があります。また Tauri のプラットフォーム依存は容量が大きいため nix develop .#tauri-linux / .#tauri-android という別シェルに分離されています。

Nix が前提という点は、参入コストとして正直に見積もっておくべきところです。チームに Nix の運用経験がない場合、コントリビュートや自前ビルドの初期コストは相応に発生します。

類似OSSとの違い（Huly・AppFlowy・AFFiNE・Twenty）

「他の選択肢と比べてどうか」は採用判断の核心です。統合ワークスペース／Notion 代替の領域には有力な OSS が複数あるため、Macro の位置づけを相対的に把握しておきます。

比較テーブル

※ スター数・ライセンス・言語はいずれも 2026年8月28日時点で GitHub API から取得した値です。NOASSERTION は GitHub 側で SPDX ライセンス識別子を特定できなかったことを示します。

Huly との違い

Huly は統合範囲が最も近い競合です。プロジェクト管理（Tracker）、チャット、ドキュメント、仮想オフィスまでを1つのプラットフォームで提供しており、Linear・Jira・Slack・Notion・Motion の代替を掲げています。

一方で主軸はあくまでプロジェクト管理にあり、Macro が第一級ブロックとして扱うメール（Gmail の統合インボックス）や、チーム横断の共有メモリを毎日1パスで合成する仕組みは範囲外です。実装言語も TypeScript で、ライセンスは EPL-2.0 のため、AGPL-3.0 の Macro とはコピーレフトの強度が異なります。プロプライエタリな製品への組み込みを想定する場合、この差はそのまま採用可否に効いてきます。

AppFlowy・AFFiNE との違い

AppFlowy は Notion 代替として、ドキュメント・wiki・データベースにフォーカスしています。Rust コアと Flutter（Dart）UI の組み合わせでローカルファースト志向が強い一方、メール・CRM・通話は扱いません。「業務コミュニケーションを統合する」という Macro の目的とは、そもそも守備範囲が異なります。

AFFiNE はドキュメントとホワイトボード（Miro 的なキャンバス）の統合が主軸です。Macro の Canvas ブロックとは重なりますが、メール・タスク・CRM・エージェントメモリは扱いません。ライセンス表記が NOASSERTION である点も、AGPL-3.0 が明示されている Macro とは選定時の確認事項が変わります。

ドキュメントとナレッジ管理を主目的とするなら、スター数・エコシステムの成熟度から見て AppFlowy や AFFiNE のほうが選択肢として自然です。Macro が優位に立つのは「コミュニケーションと業務データを一体で扱いたい」という要件がある場合に限られます。

Twenty との違い

Twenty は CRM 単機能の OSS（Salesforce 代替）で、AI を前提とした設計を掲げています。Macro の CRM ブロックと直接比較できる対象です。

決定的な違いは、Macro が CRM を単体プロダクトとしてではなく、チャットとメールに同居させるブロックとして実装している点です。メッセージ内で会社レコードを @メンションすれば双方向リンクが張られ、レコード側から関連会話を辿れます。CRM 単体で高い機能密度が必要なら Twenty、社内コミュニケーションと不可分に運用したいなら Macro、という選定軸になります。

ライセンス・セルフホスト・セキュリティの前提

技術的に魅力があっても、ライセンス条件と運用の現実が合わなければ採用できません。ここが導入判断で最も慎重に確認すべき領域です。

AGPLv3 が意味すること

Macro のライセンスは AGPL-3.0 です。README は "fully open source — not 'open core'" と明記しており、機能の一部を有償版に囲い込むオープンコア型ではないことを強調しています。

公式 FAQ によれば、Macro は 2026年5月31日に BSL（Business Source License）から AGPLv3 へ移行し、完全なオープンソース化を果たしました。ここで重要なのは、AGPL がコピーレフトライセンスであり、派生物もオープンソースである必要があるという点です。FAQ は、Macro の上に何かを構築する場合はコードを AGPLv3 の下に置く必要があり、それが難しい場合は商用ライセンス（licensing@macro.com）を取得する形になると説明しています。

収益モデルも FAQ に整理されており、ホスト版 SaaS のサブスクリプションと、Macro 上にプロプライエタリな製品を構築する事業者向けの商用ライセンスの2本立てとされています。自社サービスに組み込んでクローズドソースのまま提供したい場合は、無償の OSS 利用の範囲を超えることを前提に検討する必要があります。社内利用にとどめるのか、外部向けサービスに組み込むのかで判断が大きく変わるため、法務を交えた確認は早い段階で行っておくのが安全です。

セルフホストの現実的な位置づけ

「OSS なのだからセルフホストすればよい」と考えたくなりますが、FAQ にははっきりとした但し書きがあります。セルフホストは AGPL の下で許可されているものの、2026年6月時点で「主な注力対象ではない（this hasn't been our primary focus）」と明記されています。

さらに、iOS アプリの利用や、Apple・Google Mail・GitHub の PR 連携に必要な承認、LiveKit・FusionAuth といったサードパーティのライセンス取り扱いは、いずれもホスト版が前提になると説明されています。FedRAMP をはじめとするエンタープライズ要件については self-host@macro.com への問い合わせが案内されています。

前述のとおり協調編集の中核が Cloudflare Durable Objects に依存している点も踏まえると、完全にオンプレミスで閉じた運用を必須要件とするチームにとって、現時点の Macro は要件充足を確認するコストが高い選択肢だと言えます。逆に、ホスト版の利用を前提としつつ「ソースコードが公開されており、必要ならフォークできる」という点に価値を見るなら、ライセンス移行済みの現状は十分な安心材料になります。

セキュリティとデータの取り扱い

セキュリティ面では、README に ISO 27001 と SOC 2 Type II のバッジが掲示され、SOC 2 Type II 認証を取得していると記載されています。また、モデルプロバイダとの間でゼロデータ保持契約を結んでおり、顧客のコンテンツでモデルの学習を行わないことが README と FAQ の双方で明記されています。脆弱性報告については、重大度と影響度に応じた報奨金制度が案内されています（security@macro.com）。

AI エージェントに業務データ全体を読ませる設計である以上、この部分の確認は必須です。少なくとも公開情報のレベルでは、データの取り扱い方針は明文化されています。

どんなチームに向くか（導入判断のチェックポイント）

ここまでの情報を、判断軸として整理します。動作検証を行っていない前提のため断定的な推奨はしませんが、確認すべき論点は次のように切り分けられます。

検証を進める価値が高いケース

• 10〜30人規模でツール分散のコストが顕在化しており、SaaS のライセンス費と運用の分断が同時に課題になっています
• AI エージェントを業務データ横断で動かしたいが、SaaS ごとの API 制限やレートリミットが障壁になっています
• 社内利用が中心で、AGPLv3 のコピーレフト条件を許容できます
• Gmail / Google Workspace をメール基盤として使っており、Email ブロックの前提条件と合致します
• ホスト版の利用を軸にしつつ、ベンダーロックインへの保険としてソースコードの公開性を重視しています

慎重に検討すべきケース

• 完全なオンプレミス運用が必須です（セルフホストは公式の主な注力対象ではなく、協調編集は Cloudflare Durable Objects に依存します）
• Gmail / Google Workspace 以外のメール基盤を使っています
• 既存 CRM の高度な機能やインテグレーションに依存しています（CRM 単体の機能密度では Twenty のような専用 OSS のほうが厚いです）
• クローズドソース製品への組み込みを想定しています（商用ライセンスの取得が前提になります）
• チームに Nix の運用経験がなく、自前ビルドやコントリビュートを前提に置いています

最初に確認すべきこと

まずは 公式 FAQ でライセンスとセルフホストの記述を自分の目で確認し、法務・情報システム部門の要件と突き合わせるのが最短です。技術的な実現方式に関心があるなら ブロックとメンションの概念 が権限モデルと CRDT 構成をまとめており、エージェント運用を検討するなら Agents のドキュメント と MCP セットアップ が判断材料になります。開発参加を視野に入れる場合は Running locally で環境要件を確認してください。

統合ワークスペースの導入は、ツールの入れ替えではなく業務プロセスの再設計に近い意思決定です。Macro のように「最初から一つのシステムとして作る」というアプローチは、その分だけ移行コストも高くなります。まずは自社のどの分断が最も痛いのかを言語化したうえで、Macro が解こうとしている問題と一致しているかを確かめることをおすすめします。

関連情報

社内ツールの統合や AI エージェントを前提とした業務基盤の設計について、要件整理の段階からご相談を承っています。ご検討中の方は お問い合わせフォーム からお気軽にお問い合わせください。