- GLM Legal コンテキストウィンドウ：モデルが 1 回の処理でどれだけの法的テキストを処理できるかを決定するトークン容量です。
- 長文ドキュメント：契約書、証拠一式、法規は単一ウィンドウを超えることが多いため、チャンキングと検索（リトリーバル）が必要です。
- ベストプラクティス：管轄区域を考慮した RAG パイプラインと、構造化されたプロンプトおよび出典引用要件を組み合わせること。
- 重要な制限：GLM Legal の公開ページには正確なコンテキストウィンドウの数値は掲載されておらず、未確認の数値は慎重に扱うべきです。
- レビューの原則：ウィンドウサイズに関係なく、すべての出力に対する人間の専門家による検証は必須です。
GLM Legal コンテキストウィンドウとは何か
GLM Legal コンテキストウィンドウとは、GLM Legal の法的 AI モデルが 1 回の推論処理で読み取り、推論できるテキストの量（トークン単位で測定）のことです。法務業務において、この数値は実現可能なことを直接左右します。80 ページの契約書全体が 1 つのプロンプトに収まるか、証拠の時系列全体を一度に分析できるか、あるいはワークフローが複数回の呼び出しに材料を分割しなければならないかです。
一般的なチャットボットの利用とは異なり、法務ワークフローはドキュメントの分量が膨大です。別添書類を含む単一の M&A 契約は 50,000 トークンを大きく超えることがあり、訴訟の証拠セットはさらに多くなります。だからこそ、コンテキストウィンドウの理解は、法律事務所、コンプライアンスチーム、リーガルテック開発者が GLM Legal 上に構築する前に尋ねるべき最初の技術的質問なのです。
2026 年 10 月時点で、GLM Legal の公開資料およびオープンモデルのページ（Hugging Face 上の law-llm 組織配下にある law-glm-10b および law-glm-10b-v2）では、確定されたコンテキストウィンドウの仕様は公表されていません。サードパーティサイトで見かける具体的なトークン数は、信頼する前に公式の製品またはモデルドキュメントで確認すべきです。
法的タスクにおいてウィンドウが重要な理由
| 法的タスク | 典型的な入力サイズ | ウィンドウの影響 |
|---|---|---|
| 条項レベルの契約レビュー | 5k–40k トークン | 単一の大きなウィンドウに収まることが多い |
| 契約書全文＋別添 | 40k–150k+ トークン | 通常はチャンキングまたは検索が必要 |
| 証拠時系列の構築 | 20k–200k+ トークン | 検索＋反復的要約が必要 |
| 法令・規則の Q&A | 2k–20k トークン | 単一パスで十分なことが多い |
| コンプライアンスチェックリスト生成 | 10k–60k トークン | 規則の長さに依存 |
このパターンは一貫しています。短く焦点を絞ったタスクは直接処理でき、大規模コーパスのタスクにはウィンドウと戦うのではなく、ウィンドウを前提としたアーキテクチャが必要です。
モデルバリアントとコンテキストに関する考慮点
GLM Legal ファミリーには現在 2 つの公開モデルバリアントがあり、どちらも Hugging Face 上で Apache-2.0 ライセンスのもとでホストされています。デプロイを自分で管理するため、実際のコンテキスト挙動はホスト型 API 製品とは異なります。
law-glm-10b
- 100 億パラメータ、GLM アーキテクチャ
- Apache-2.0 ライセンス
- モデルファイルは約 39.5 GB
- セルフホスト：メモリ上限内で最大シーケンス長を自分で管理
law-glm-10b-v2
- ベースモデルの更新版
- 同じ Apache-2.0 ライセンス
- 法的タスクにおける挙動の改善を指向
- デプロイ時の考慮点はベースモデルと同様
セルフホスト vs. ホスト型アクセス
| アクセス方法 | ウィンドウを管理する主体 | 主な考慮点 |
|---|---|---|
| セルフホストの law-glm-10b | あなたのチーム | シーケンス長に応じて GPU メモリが増加、長いウィンドウはより多くの VRAM を消費 |
| 企業向け相談（Z.ai リーガルチャネル） | プロバイダー | オンボーディング時に API 制限、レイテンシ、スループットを確認 |
| GLM cookbook によるプロトタイプ | 使用するモデルによる | 本番の制限が確定する前にプロンプトとスキーマの設計に活用 |
公式のリーガル相談チャネルを通じて GLM Legal を評価する際は、正確なコンテキストウィンドウ、最大リクエストサイズ、トークン単価の料金ティア、入力が上限を超えた場合の挙動（切り捨てか拒否か）を必ず確認してください。これらの詳細がドキュメントパイプラインの設計を決定します。
長文の法的文書への対処：ステップバイステップ
利用可能なウィンドウを超える材料を扱う場合、構造化されたチャンキングと検索のワークフローにより、出力の正確性と追跡可能性を維持できます。
コーパスの棚卸しとクレンジング
重複、無関係な草稿、秘匿特権対象の資料を削除します。後の出典引用が追跡可能になるよう、すべての文書にタイトル、日付、当事者、バージョンをラベル付けします。
法的構造を考慮したチャンキング
任意のトークン数ではなく、条項、セクション、条、文書単位といった自然な法的境界で分割します。見出しと定義用語を各チャンクに付随させます。
管轄区域を考慮した検索の構築
チャンクに管轄区域、文書タイプ、日付、当事者のメタデータを付けてインデックス化します。コーパス全体をプロンプトに詰め込むのではなく、タスクに必要なものだけを検索します。
明示的なスコープと出典引用を伴うプロンプト
タスク、提供されたソース、適用される法、必要な出力スキーマを明記します。すべての所見に条項またはページの引用を必須とし、検索されたテキストにない事実をモデルが持ち込むことを禁止します。
集約と検証
チャンクごとの結果を統合し、矛盾を明示的に解決し、使用前に有資格の専門家がすべての重要な記述、引用、結論を検証します。
契約書を条項の途中で分割することは、義務の誤読の最も一般的な原因です。条項を考慮したチャンキングは法的な意味の単位を保持し、レビュー出力の解釈エラーを大幅に減らします。
コンテキストウィンドウのベンチマークと評価
コンテキスト処理は、法的ベンチマークによって間接的に測定される次元の 1 つです。公開資料で言及されている GLM Legal の評価には Harvey LAB、LegalBench、PLawBench があり、それぞれ入力長との関わり方が異なります。
| ベンチマーク | 範囲 | コンテキスト処理との関連性 |
|---|---|---|
| Harvey LAB | 実務的な法的手法タスク | より長い業務向け入力が持続的推論を試す |
| LegalBench | 幅広い法的推論タスク集 | タスク固有のため、単一スコアではなくカテゴリ別に結果を読む |
| PLawBench | 法的言語と推論の評価 | プロンプト設計と入力構成に敏感 |
| ベンチマーク横断の視点 | 総合比較 | スコアはセットアップ間で互换不可能 |
優れたベンチマーク結果は、モデルが確実に処理できる最大入力を示すものではありません。本番のプロンプトと検索設定の下で、最長のものを含む自分の代表的な文書で必ずテストしてください。
実用的な社内評価には、文書長の変動、エッジケースの条項、反復実行の一貫性、引用の正確性、必要な事実が提供されたコンテキストに欠けている場合の拒否またはエスカレーション挙動を含めるべきです。
ベストプラクティス チェックリスト
コンテキストウィンドウのベストプラクティス：
- デプロイ前に公式ドキュメントまたは相談で正確なコンテキストウィンドウを確認する
- 法的文書は条項またはセクション境界でチャンキングし、文の途中で分割しない
- 検索されたすべてのチャンクにメタデータ（管轄区域、日付、当事者、バージョン）を付与する
- 出力スキーマで重要な所見すべてに出典引用を必須とする
- 本番展開前に最長の現実的な文書でテストする
- すべての法的結論について人間の専門家レビューをプロセスに組み込む
コンテキストウィンドウは設計上の制約であり、法的ケイパビリティの限界ではありません。すべてを 1 つのプロンプトに収めようとするのではなく、ウィンドウを前提に検索パイプラインを構築するチームは、より正確で、レビューしやすく、スケーラブルな結果を得られます。
FAQ
Q: GLM Legal の正確なコンテキストウィンドウサイズは？
2026 年 10 月時点で、GLM Legal の公開モデルページや製品資料には確定されたコンテキストウィンドウの数値は公表されていません。セルフホストの law-glm-10b モデルでは、実効的な最大シーケンス長はデプロイ構成と GPU メモリに依存します。ホスト型アクセスについては、公式のリーガル相談チャネルを通じて上限を確認してください。
Q: GLM Legal は長文契約書全体を 1 回で処理できますか？
契約書の長さとデプロイされたウィンドウサイズによります。短い契約は直接収まることが多い一方、別添を含む大型契約は通常、単一ウィンドウを超えます。そのような場合は、条項を考慮したチャンキングと検索を組み合わせ、矛盾を明示的に処理しながら結果を集約してください。
Q: コンテキストウィンドウが大きいほど法的出力の品質は向上しますか？
いいえ。長いウィンドウはより多くの入力を許容しますが、正確性はプロンプト構造、ソースの品質、引用要件、検索の関連性に大きく依存します。適切に検索された抜粋を用いた焦点を絞ったプロンプトは、詰め込みすぎたコンテキストウィンドウよりも通常優れた結果をもたらします。
Q: エンタープライズデプロイのコンテキスト上限を確認するには？
公式の Z.ai リーガル相談窓口を利用して API アクセスについて相談してください。想定される文書タイプ、コーパスサイズ、リクエスト量、レイテンシ要件、データ取り扱い要件を準備しておくと、プロバイダーが正確な仕様と条件を提示できます。