Macro深掘り：AIワークスペースでメール・タスク・CRMを一体化できるか

Macroは何を一つにまとめるのか

Macroは、メール、メッセージ、文書、タスク、AIエージェント、通話、ファイル、プルリクエスト、CRMを一つのワークスペースで扱うプロジェクトです。READMEでは、各要素を単に同じ画面へ並べるのではなく、メール、タスク、文書、会社、連絡先などを「@リンク」で相互参照できる構成として説明しています。

中心となる考え方は、仕事に関する会話と成果物の文脈を分離しないことです。たとえば、顧客メールからタスクを作り、そのタスクを文書やメッセージから参照する流れが示されています。CRMについても、会社や連絡先に関連するメールやファイルを同じワークスペースで扱う設計です。

リポジトリの主言語はRustです。READMEではSolidJSとRustで構築していると説明されており、Cargo.tomlとpackage.jsonの存在もbundleに記録されています。

• メール：複数アカウント、共有受信箱、メールからのタスク作成を扱う構成。
• メッセージ：チャンネルとダイレクトメッセージを提供し、他のオブジェクトと相互参照。
• 文書：Markdownを基本とし、CRDTによる共同編集、履歴、オフライン編集と再同期を説明。
• タスク：メール、文書、メッセージ、エージェントなど複数の文脈から作成可能。
• CRM：会社と連絡先のオブジェクト、カスタムプロパティ、メール同期などを記載。
• AIエージェント：チーム単位の共有メモリを利用し、文書編集やメール関連の操作に関与。

Web制作・マーケティング業務で注目したい導線

Web制作会社や少人数のマーケティングチームにとって注目点になるのは、問い合わせ対応、制作タスク、顧客情報、関連資料を同じ文脈でたどれることです。READMEに記載された機能を組み合わせると、顧客メールから担当タスクを作成し、その背景となるメールを参照したまま制作や確認を進める導線を検証できます。

顧客や会社ごとにメールとファイルを集約するCRM機能は、案件の経緯を担当者の記憶だけに依存させないための候補になります。Markdown文書からタスクを作成したり、文書内でメールや会社を参照したりできるため、要件整理、議事メモ、修正指示を別々のツールへ転記する回数を減らせる可能性があります。

ただし、工数削減率、対応速度、商談成果などを示す検証済みの数値はresearch bundleにありません。導入効果は、現在の業務フローを一つ選び、情報の転記、検索、確認にかかる負担が実際に変化するかを自社で確かめる必要があります。

• 問い合わせメールから制作・確認タスクを作り、元のやり取りまで追跡できるか。
• 会社・連絡先単位で、担当者が必要とするメールやファイルへ到達できるか。
• 要件書や議事メモのチェック項目を、二重入力せずタスクへ移せるか。
• 社内メッセージ、顧客メール、文書のアクセス範囲を適切に分けられるか。
• 既存のメール、CRM、タスク管理を置き換える場合に、移行負担が統合効果を上回らないか。

AIエージェントと自動化の位置づけ

MacroのAIエージェントは、独立したチャット機能ではなく、メール、文書、タスクなどと同じワークスペースに置かれています。READMEでは、共有されたチーム単位のメモリを使い、文書を編集したり、AIチャットからメールの下書き、編集、送信を行ったりできると説明しています。タスクは内部エージェントに加え、外部MCP、API、SDKからも作成できるとされています。

文書機能ではCRDTを採用し、エージェントが人間と同じ共同編集の仕組みに参加する設計が説明されています。自動化の例として、チャンネルを確認してMarkdown文書を更新し、他者が先に編集していれば更新を見送る処理がREADMEに掲載されています。

この設計は、情報を探すだけのAIから、文書更新やメール操作を伴うAIへ進む余地を示します。一方、操作権限を持つエージェントには、参照できるデータ、実行できる操作、承認が必要な処理、停止と復旧の手順を先に定義する必要があります。特にメール送信のような対外操作は、PoC段階では下書きまでに限定するなど、影響範囲を管理しながら検証するのが現実的です。

• 最初に、検索・要約・下書き・更新・送信を別々の権限として整理する。
• トークンや環境変数を、文書やエージェントの会話へ直接記録しない運用を設計する。
• 自動更新した内容について、変更箇所と実行主体を確認できる状態を検証する。
• 誤った更新や操作が起きた場合の停止、差し戻し、手動復旧をPoCの評価対象に含める。
• 共有メモリへ保存してよい顧客情報と、対象外にする情報を事前に分類する。

v2026.8.14.0で確認できる更新内容

research bundleが最新リリースとして収録しているのは、2026年8月14日公開のv2026.8.14.0です。リリースノートには、Outlookアカウント連携、カレンダー操作、通知更新、ユーザー表示名、メール件名、モバイル表示など、日常業務に接する機能の追加と修正が並んでいます。

カレンダーでは、予定をドラッグして移動したり、開始・終了時刻を変更したりする機能が追加されています。Google Calendarについては、Macroが使用するスコープだけを要求する修正と、接続済み受信箱を更新する際にカレンダーアクセスだけを求める認証修正が記載されています。

通知ではGraphQLの通知更新を購読する機能が追加され、DOCXアップロードでは大文字と小文字が混在する拡張子の通知修正が含まれます。メールでは返信件名の接頭辞認識、カレンダーでは複数日イベントの表示、iOSではiPad対応に関する修正も記録されています。

機能追加と複数領域の修正が継続していることは確認できますが、このリリースノートだけで本番環境における安定性や後方互換性を評価することはできません。導入時は利用予定のメール、カレンダー、モバイル環境に絞って回帰確認を行う必要があります。

• Outlookアカウント連携のサポート。
• カレンダー予定のドラッグ移動と時刻変更。
• Google Calendarで要求するスコープの限定。
• GraphQL通知更新の購読。
• 大文字・小文字が混在するDOCX拡張子の処理修正。
• 返信件名の接頭辞認識、複数日イベント表示、iPad対応などの修正。

AGPL-3.0を導入前に確認する

licenseEvidenceでは、LICENSE.txtのSPDX識別子がAGPL-3.0であり、本文がGNU Affero General Public License Version 3であることを確認できます。したがって、MacroのライセンスはAGPL-3.0と明示できます。

LICENSE.txtの前文では、ネットワークサーバー上で動く改変版を公衆が利用する場合に、その利用者が改変版のソースコードを入手できるようにする目的が説明されています。また、「free」は価格ではなく自由を意味すると明記されているため、OSSであることだけから利用・運用費用が発生しないとは判断できません。

社内検証、改変、外部提供を同じ扱いにせず、どのコードを変更するのか、誰がネットワーク経由で利用するのか、ソースコードをどのように管理するのかを導入計画に記録する必要があります。個別構成への具体的な適用判断は本記事では行わず、組織のライセンス確認プロセスに沿って判断してください。

• リポジトリ直下のLICENSE.txtとSPDX識別子AGPL-3.0を記録する。
• 利用するバージョンと、自社が変更したファイルの範囲を追跡する。
• 社内だけの利用か、顧客や外部利用者へネットワーク経由で提供するかを区別する。
• 派生物や連携部分を含む個別の扱いを、導入前の確認事項として残す。
• OSSライセンスと、ホスティングや保守などの費用判断を分けて評価する。

現時点で見落とせない限界

公式READMEは幅広い機能と統合方針を説明していますが、research bundleには比較ベンチマーク、稼働率、処理容量、必要インフラ、標準的な運用費用の検証資料が含まれていません。既存のメール、チャット、CRM、文書管理をまとめて置き換えられるかどうかは、機能一覧だけでは判断できません。

文書のバージョン管理について、README自身がまだv1であり、gitに近づける余地や将来のgit互換性の可能性に触れています。モバイルについてもiOSアプリとWeb利用を案内する一方、Androidアプリは今後の予定として記載されています。これらは利用端末や文書管理要件によって導入判断へ直接影響します。

また、メール、通話、CRM、共有メモリを同じワークスペースで扱うほど、アクセス制御やデータ管理の確認範囲は広がります。今回確認した一次情報だけでは、暗号化、データ保管地域、監査ログ、バックアップ、復旧目標などへの適合を判定できません。機密性の高い案件を扱う前に、自社要件との照合が必要です。

• READMEの製品説明と、実環境で再現できた結果を分けて記録する。
• Androidアプリを必須とする現場では、Web利用で要件を満たせるか確認する。
• 文書履歴や復元を重視する場合は、現行のバージョン管理機能を実データで試す。
• 認証、権限、監査、バックアップ、データ保管に関する必要条件を別途確認する。
• 全機能を一度に評価せず、メールとタスクなど境界の明確な組み合わせから試す。

導入判断は一つの業務フローを使ったPoCから

Macroは、情報がメール、チャット、文書、タスク、CRMへ分散し、同じ背景説明を何度も転記しているチームほど検証しやすい構成です。特に、顧客メールからタスクを作り、会社情報や関連文書まで追跡する流れは、READMEに記載された複数機能をまとめて確かめられます。

一方で、全面移行から始めると、製品自体の評価とデータ移行、権限変更、業務ルール変更の影響を切り分けにくくなります。最初は一つの案件種別や社内チームへ対象を限定し、既存ツールを残したまま、文脈の追跡性、手作業の転記、エージェントの操作範囲、復旧手順を確認する方法が適しています。

採用の判断基準は、機能数ではなく、必要な担当者が元のメールや会話まで迷わずたどれるか、自動化を安全に止められるか、運用担当者が権限と変更を管理できるかです。これらを満たし、セキュリティ要件とAGPL-3.0への対応を整理できた段階で、対象業務を広げる判断へ進むのが妥当です。

• 対象業務を「顧客メールから制作タスクを起票する」など一つに絞る。
• 利用者、扱うデータ、必要なアクセス権、AIに許可する操作を事前に定義する。
• 元のメール、タスク、文書、顧客情報を相互に追跡できるか確認する。
• AIによる送信や更新は段階的に解放し、停止と差し戻しを試す。
• v2026.8.14.0の変更点から、自社のメール、カレンダー、端末に関係する項目を再現確認する。
• 改変範囲と提供形態を記録し、AGPL-3.0の確認を完了してから本番範囲を決める。