大量かつ高難度の契約プログラムを運用する法務チームのためのエンタープライズ CLM スタックです。サイクルタイム、レッドラインの正確性、締結後の義務追跡が、いずれも数字に表れる領域を対象とします。4 つのツール、4 つのライフサイクル段階、そしてその間を結ぶ明示的なハンドオフで構成されます。この 4 つはすべて 2026 年に動きました。Ironclad は調達向けエージェントと MCP サーバーを出荷し、Litera は単一エージェントを軸に再ローンチしてメタデータ製品群を改称し、Docusign はこのスタックが依存するリポジトリ API を改称し、Spellbook は公開価格を撤回しました。最後の 1 点が、このスタックの予算の立て方に対する最大の変更です。
各パーツの噛み合い方
Ironclad は CLM のバックボーンであり、ワークフローエンジンです。 すべての契約は Ironclad のインテークから入ります。条項を起案する前に、相手方、契約種別、リスク階層、必要な承認を捕捉する構造化フォームです。Ironclad は依頼を適切なプレイブックへルーティングし、案件を割り当て、承認チェーンを統制します。締結後は締結済み契約を保管し、更新期日と義務を追跡し、期限アラートを発火させます。年間 2,000 件から 10,000 件超を処理するプログラムでは、運用規律が宿る場所がここです。
ここでは 2026-08-05 に 2 つの変更がありました。Ironclad は AI Obligation Extraction を出荷しました。更新ウィンドウ、値引き、クレジット、リベート、解除権、支払条件を、誰かが読み直す散文ではなく追跡可能なフィールドに変換します。あわせて、手動タグ付けなしにサプライヤー契約の階層を組み立てる Contract Family Agent、AI Redlining from Precedent、そして SAP Data Foundation と SAP Procurement Automation という 2 パッケージとして販売され Ariba と S/4HANA を接続する SAP 連携が加わりました。これとは別に、Ironclad は現在 OAuth に対応した公式のリモート MCP サーバーを運用しており、create_obligation、get_obligation、list_obligations、list_obligation_types、update_obligation を含むおよそ 10 個のツールを Claude、ChatGPT、Cursor その他の MCP クライアントに公開しています。実務上の効果は、誰かが先に REST API に対して開発しなくても、エージェントが義務レイヤーを照会できるという点です。
Spellbook は AI 支援による起案と一次レビューを担います。 Ironclad からのハンドオフはインテークのトリガーです。Ironclad が依頼を起案担当弁護士へルーティングすると、その担当者は該当するプレイブックの立場をコンテキストとして作業します。Spellbook はプレイブックからの逸脱を指摘し、事前承認済みのフォールバック文言を提示し、リスクのある条項を平易な言葉で注記します。仕上がった草案は承認ルーティングのために Ironclad へ戻ります。要となる性質は、汎用の法律コーパスではなくチーム自身のプレイブックを読む点にあり、その結果、提案は市場標準に対するモデルの推測ではなく自社の立場を反映します。
捨てるべき捉え方は「Word アドイン」です。Word のサイドバーは今も日常的な作業面ですが、Spellbook は名前の付いた部品群からなるプラットフォームとして販売されています。Review、Draft、Compare、Ask、Playbooks、そして複数文書にまたがる起案とレビューのためのエージェント Associate です。さらにメール、Slack、Salesforce にも届きます。コネクタは iManage、OneDrive、SharePoint、Google Drive、Dropbox をカバーします。欠けているものに注意してください。公開 API も MCP サーバーもありません。つまり Spellbook は、このスタックの中で自動化の対象にもエージェントからの操作対象にもできない唯一のレイヤーです。その境界を越えるものはすべて、文書の中の人間として越えます。
Litera は送信時点での文書品質管理とメタデータ除去を提供します。 Spellbook から Litera へのハンドオフは送信前ステップです。Litera Compare は最後に承認されたバージョンに対して条項レベルの最終差分を実行し、レッドラインのやり取りの中で入り込んだ変更を捕まえます。メタデータレイヤーは、ファイルが相手方に届く前に、隠れた変更履歴、コメントスレッド、文書履歴を除去します。交渉を伴う契約では過去の交渉上の立場が変更履歴の中に残るため、これは現実の露出リスクです。
このメタデータレイヤーは 2026 年に改称されました。Metadact 製品群は現在 Clean です。Clean Desktop が Metadact Desktop を、Clean Server がオンプレミスサーバーを、Clean Cloud が Litera One 内の Metadact を置き換え、自前の除去サーバーを構築しパッチを当てる必要をなくす Litera ホスティング型サービス Clean+ が 2026 年 6 月末に一般提供へ到達しました。Clean は Word、PDF、Excel、ZIP の添付ファイルにわたり 300 種類を超えるメタデータを、従来版と新版いずれの Outlook でも検出して除去します。手順書がまだ Metadact を指しているなら、その名称ではもう存在しない製品を指していることになります。
Litera は 2026-07-15 に企業としても「1 つのエージェント、1 つのデータセット」を軸に再ローンチし、個別製品ではなくプラットフォームを売る形へ移りました。エージェント Lito が、起案、比較、契約レビュー、ナレッジマネジメント、事業開発を貫く軸となります。Lito の次期バージョンは、2026 年 8 月 23 日から 27 日にナッシュビルで開催される ILTACON で、Foundation と GrowthTech のポートフォリオ全体にわたって披露されています。これはポジショニングとデモとして扱ってください。すでに保有している機能としてではありません。自社テナント内で Lito が何をするかは、Litera との契約に対する問いです。このスタックが送信境界で依存しているのは、エージェントではなく決定論的な Compare と Clean のエンジンです。
Docusign IAM は署名レイヤーであり、契約インテリジェンスのプラットフォームです。 Ironclad からのハンドオフは締結のトリガーです。承認が完了すると、IAM が締結パッケージを送付し、署名状況を追跡し、締結済み契約を webhook 経由で Ironclad のリポジトリへ返します。
リポジトリ API は名称が変わり、成熟しました。かつての Navigator API は現在 Agreement Manager API であり、対象となる Agreement Manager 顧客に対して 2026 年 5 月から一般提供されています。その Iris 抽出は、解析すべきテキストではなく構造化フィールドとして条項を返します。expiration_date、renewal_type（たとえば AUTO_RENEW）、renewal_notice_date、total_agreement_value、effective_date、jurisdiction、termination_period_for_cause などです。一括取り込みは POST /v1/accounts/{accountId}/upload/jobs を通じて実行され、1 ジョブあたり 10,000 文書、1 文書あたり 100MB、事前署名 URL の有効期間は 8 時間、ジョブの TTL は 3 日です。単体取得は GET /v1/accounts/{accountId}/agreements/{agreementId} です。認証は OAuth 2.0 です。過去分の文書をスタックへ移行する作業を、サービス案件ではなくスクリプト化可能な作業に変えるのが、この部分です。
ツール同士が重なり始めた領域
この組み合わせを支えてきた従来の論拠は、各ツールが重複なく 1 つの段階の専門家である、というものでした。それは以前ほど正しくありません。そうでないふりをすると、二重に支払うことになります。
Ironclad の AI Redlining from Precedent は Spellbook の領域に着地し、Ironclad の AI Obligation Extraction は Docusign の Iris が Agreement Manager API から返すものと重なります。どちらの重複も、それ単独ではツールを外す理由にはなりません。しかし両方とも、展開前にどのシステムが各機能の正となるかを文書で決めておく理由にはなります。2 つのシステムが更新日を 2 つのリポジトリへ抽出する状態は、チームが「これはいつ自動更新されるのか」に対して 2 つの答えを持つに至る経路そのものです。
今も成り立つ分担はこうです。弁護士は読む場所で起案し、レッドラインを承認するためにブラウザのワークフローへ引き出されることに抵抗します。したがって Spellbook は機能だけでなく定着によって席を得ています。Litera が席を得ているのは、決定論的な Compare と Clean のステップに他の 3 つでは代替がなく、しかもオールインワン導入で最も省略されやすいステップだからです。Ironclad のレッドライン機能は、そもそも誰も Word で交渉していない調達インテーク経由のサプライヤー文書に使い、Spellbook は交渉を伴う商用契約に充ててください。
コストの実態
公開されているものと公開されていないものに分けてください。予算サイクルの中で、この 2 つの半分はまったく異なる振る舞いをします。
公開済み、または観測済み:
- Ironclad: Vendr が追跡した購買では、年間契約額の中央値は $40,000、観測されたレンジは $15,000 から $104,272、交渉による平均削減率は 20.6% です。Ironclad について流布している高位 6 桁のバンドは、Vendr が実際に記録したほぼすべてを上回っています。50 人から 150 人規模のプログラムでは、中央値ではなく観測レンジの上限に対して計画し、~$105,000 を明確に超える見積もりは、比較可能な事例を持ち出して押し返すべきものとして扱ってください。
- Docusign IAM: 現在は公開された価格ラダーがあります。Starter は年払いで $45/ユーザー/月、ユーザーあたり年間 100 通のエンベロープ送信と 1 つのワークフローが付きます。Standard は $50/ユーザー/月で最低 3 ユーザー、Web アプリ経由のエンベロープは無制限、ワークフローは 3 つです。Professional は $80/ユーザー/月で最低 3 ユーザー、ワークフローは 10 個です。IAM のすべての階層は 50 ユーザーが上限です。 このスタックをカスタム見積もりへ押しやるのは、席単価ではなくこの上限です。最上位の公開階層で 50 ユーザーのプログラムはおよそ $48,000/年となり、50 ユーザーを超えるものはラダーから完全に外れます。
見積もり制、うち 1 つは金額化そのものが不能:
- Spellbook: 公開価格はありません。Spellbook はかつて Solo を $99、Team を $179 のユーザー月額で掲示していましたが、これらの階層は消えました。価格ページは現在 Law Firms と In-House Teams のみを示し、ドル金額はどこにもなく、価格はライセンス人数によって決まると記載されています。第三者のトラッカーは、エントリー席をおよそ $20 から $99、エンタープライズをおよそ $199 から $350 の範囲に置き、10 席かつ 6 か月の最低条件が報告されています。エントリー階層で 5 倍の開きがあるものは価格帯ではありません。Spellbook の営業チーム以外の誰も知らないという証拠です。責任を問われる予算に Spellbook の席単価を入れないでください。先に、そして早く見積もりを取ってください。このスタックで最も分散の大きい費目です。
- Litera: 見積もりのみで、バンドルされたエンタープライズ契約として販売され、実効的なユーザー単価はバンドルに含まれるモジュール次第です。このスタックが必要とする最小構成は Compare と Clean です。Foundation と Kira は別の判断になります。
導入と継続コスト。 Ironclad の設定、Spellbook のプレイブック構築、Litera の展開は、あわせて初年度のプロジェクトであって購買ではありません。Compare は数日で展開できますが、Ironclad のワークフロー設定とプレイブック開発は数か月かかります。忘れられがちな継続コストはプレイブックの保守です。立場を最新に保つために、年あたり弁護士 1 名の 1 四半期分をおよその目安として計上してください。Spellbook も Ironclad の先例ベースのレッドラインも、陳腐化した部分を含めてプレイブックにあるものを増幅するからです。
適合ルール
このスタックが正しい選択となる条件:
- 契約量が年間 2,000 件を超え、実質的な法的複雑性を伴う場合。クリックラップではなく、交渉を伴う商用契約であること
- 社内チームに 20 名以上の弁護士がおり、1 人あたりの生産性向上が席単価を賄えること
- CLM のワークフロー設定、SSO/SCIM のプロビジョニング、Ironclad と Docusign 間の webhook 連携を担う IT 体制があること
- 外部法律事務所への支出が十分に大きく、起案サイクルの短縮が法務支出を測定可能な形で動かすこと
- GC または CLO が、スタックが本来の効率で回り始めるまでの 6 か月から 12 か月のプレイブック開発に予算を付けること
このスタックが誤った選択となる条件:
- 契約量が年間 1,000 件未満の場合。これを下回ると Ironclad は正当化しにくく、Juro や Concord がより安価にユースケースをカバーします
- チームが 10 名未満の場合。席あたりの AI コストが便益を上回ります
- プレイブックがまだ存在しない場合。AI レイヤーはプレイブックを増幅するものであり、増幅する対象がありません
- 契約が圧倒的に定型で交渉が最小限の場合。署名して保管するだけで足ります
- 失敗した、あるいは先送りされた導入の後で意図的に CLM プラットフォームを避けている場合。代わりにプラットフォームを使わない道筋を見てください。これは設計が異なるものであり、本スタックの安価版ではありません
よくあるバリエーション
Docusign IAM を Ironclad ネイティブの署名に置き換える。 Ironclad は eSignature レイヤーを内蔵しています。Agreement Manager API の構造化された条項抽出が不要な場合、つまり Ironclad 自身の義務フィールドですでに足りている場合、Ironclad 内で署名を完結させればベンダーと連携を 1 つずつ減らせます。置き換えのルール: 年間エンベロープ量が 5,000 件未満で、更新に関する唯一の正が Ironclad のリポジトリフィールドである場合に採用してください。過去分文書のスクリプト化可能な移行が必要なら採用しないでください。それは Agreement Manager API の最も強い論拠です。
Litera Compare を Spellbook Compare で代替する。ただし Clean は代替できない。 Spellbook は Compare 機能を備えているため、送信前ステップの比較側は移せます。メタデータ側は移せません。Outlook 内の Word、PDF、Excel、ZIP にわたる Clean の 300 種類超のメタデータに相当するものが Spellbook にはないからです。置き換えのルール: 差分のみであれば許容でき、それも契約構成が Word ネイティブで、チームに既存の Litera ライセンスがない場合に限ります。AmLaw 系事務所出身者で構成されたチームでは、Litera はすでに支払い済みであることが多いのです。ライセンス費用を節約するためにメタデータのステップを落とすのは誤ったトレードです。最も安い費目でありながら、単独で最大の開示リスクを守っている費目だからです。
M&A デューデリジェンスのために Harvey を追加する。 この 4 つのツールは商用契約と業務契約を扱います。加えて M&A デューデリジェンス、つまり資産取得、資本取引、表明保証レビューを回すチームは、複数文書分析のために Spellbook と並べて Harvey を追加すると得るものが大きくなります。Harvey は LexisNexis との提携により一次法源にも到達するようになり、専用のリサーチ席との差が縮まりました。置き換えのルール: デューデリジェンスを外部法律事務所へ全面委託していない前提で、年間 3 件から 4 件の社内取引を超える場合に正当化されます。
スタックを買い手側へ向ける。 Ironclad の調達向けエージェントと SAP パッケージにより、このスタックのサプライヤー契約向け構成は 1 年前には成り立たなかった形で実用的になりました。推進要因が売り手側のサイクルタイムではなく調達コストの削減であるなら、買い手側コントラクトオペレーションのスタックから始めてください。
このスタックが置き換えないもの
- 会社の存続を左右する訴訟、証券関連業務、専門的な規制案件のための外部弁護士。このスタックが改善するのは商用契約のスループットであって、法的判断ではありません
- 外部法律事務所への支出を統制するための電子請求と案件管理（Brightflag、現在は Wolters Kluwer の一部、または Onit）。Ironclad が管理するのは契約であって請求書ではありません
- GDPR、CCPA、EU AI Act の義務に対応するプライバシーコンプライアンス機能。Ironclad 内の契約データはプライバシープログラムへの入力にはなりますが、プログラムそのものではありません
- 法令リサーチ（Lexis+ with Protégé、Westlaw、CoCounsel）。Spellbook が起案の拠りどころとするのは自社のプレイブックであって判例ではなく、前例のない論点には依然としてリサーチのレイヤーが必要です
- 係属中の訴訟のための裁判所提出システム