IR資料や有価証券報告書といった開示資料の作成では、金融商品取引法や証券取引所の規則に沿った記載が求められます。しかし多くの企業では、資料がほぼ完成した最終段階になってから法務部門や外部の弁護士・監査法人に法令準拠のチェックを依頼しています。この事後チェック型の進め方では、指摘が入るたびに大幅な書き直しと再レビューが発生し、開示期限ギリギリまで作業が続く状況が常態化しています。
この記事は、従業員100〜1,000名規模の上場企業で、IR・経理・総務などの管理部門を担当している方を想定しています。開示資料の作成プロセスに関わり、法務部門との調整に時間を取られている実務担当者やマネージャーが対象です。読み終えると、資料作成の途中段階で法令上の問題点を自動的に洗い出し、最終レビューでの大幅修正を減らすワークフローを自社に導入できるようになります。なお、大規模エンタープライズ向けの全社的な文書管理基盤の構築や、個別ツールの網羅的なレビューは扱いません。
本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。
読み終えた時点で、開示資料の作成から最終レビューまでの各段階にコンプライアンスチェックを埋め込んだ3ステップのワークフローと、それを実現するツール構成が手に入ります。
Workflow at a glance: 開示資料の法令準拠チェックを作成段階に組み込み修正の手戻りと開示遅延を防ぐ方法
開示資料の作成は、数値データの集計、文章の起草、図表の作成、法令に基づく記載要件の確認など、複数の工程にまたがります。多くの企業では、これらの工程がExcelやWordなどのファイルベースで進み、法令準拠の確認は完成間際に法務部門へファイルを送付する形で行われています。
この進め方の根本的な問題は、作成者が法令要件を意識しないまま資料を書き進めてしまうことです。たとえば、有価証券報告書の記述についてガバナンス報告の記載要件が変更されていた場合、作成者がその変更を知らなければ、最終チェックまで誤りが発見されません。発見された時点で修正すると、関連する他の箇所にも影響が波及し、修正範囲が雪だるま式に広がります。
もう一つの問題は、過去の開示で受けた指摘事項や修正履歴が体系的に管理されていないことです。前回の有価証券報告書で東京証券取引所から受けた指摘や、監査法人からのコメントが個人のメールやファイルに埋もれていると、同じ種類の誤りが繰り返されます。担当者が異動や退職で変わると、過去の知見がそのまま失われます。
開示資料の提出が遅れると、証券取引所から改善報告を求められるだけでなく、投資家からの信頼が低下し、株価に直接的な影響を及ぼします。さらに、法令違反の記載が見過ごされたまま開示された場合、金融庁からの行政処分や訴訟リスクにもつながります。事後チェック型の体制は、こうしたリスクを最終段階の担当者に集中させており、組織として持続可能な仕組みとは言えません。
開示資料の品質を上げながら作業時間を短縮するには、法令準拠の確認を最終段階に一括で行うのではなく、資料作成の各段階に小さなチェックポイントとして埋め込むことが重要です。
資料を書いている最中に、法令上の必須記載事項の漏れや、使ってはいけない表現、過去に指摘を受けたパターンと類似する記述を自動的に検出できれば、作成者自身がその場で修正できます。最終レビューに回る前に大半の問題が解消されるため、法務部門の負担も大幅に減ります。
法令要件や社内ルール、過去の指摘事項をチェックリストやルールとして一元管理し、それをツールに反映させることで、担当者が変わっても同じ品質基準でチェックが行われます。属人的な知識に頼らない体制が実現します。
作成段階のチェック結果を承認フローに組み込むことで、未解決の指摘がある状態では次の工程に進めないようにできます。これにより、問題の先送りを仕組みとして防ぎます。
以下の3ステップは、四半期ごとの決算短信や年次の有価証券報告書の作成サイクルを想定しています。IR担当者が資料を起草し、法務部門が最終確認を行う一般的な体制を前提としています。
IR担当者は、開示資料のドラフトをSharePoint上の専用ライブラリに作成します。SharePointのバージョン管理機能を有効にし、誰がいつどの部分を変更したかを自動的に記録します。
具体的な運用として、開示資料の種類ごとにフォルダを分け、決算短信、有価証券報告書、コーポレートガバナンス報告書などのテンプレートをあらかじめ格納しておきます。テンプレートには、前回の開示で使用した構成と、法令上の必須記載項目をコメントとして埋め込んでおくと、作成者が記載要件を意識しながら起草できます。
過去の指摘事項は、SharePoint上のリスト機能を使って管理します。指摘の内容、該当箇所、対応状況、対応した担当者を記録し、新しい資料を作成する際に参照できるようにします。この指摘事項リストは次のステップ2で自動チェックのルールに反映させます。
担当者の引き継ぎとしては、IR担当者がドラフトを作成し、チームリーダーが内容を確認した上で、ステップ2のチェック工程に進みます。
ドラフトがある程度まとまった段階で、LegalForceを使って法令準拠のチェックを実行します。LegalForceは契約書や法務文書のレビューをAIで支援するツールですが、開示資料に含まれる法的な記載についても、表現の適切性や必須条項の漏れを検出する用途で活用できます。
具体的には、ドラフトのうち法令に関わる記述部分(リスク情報、ガバナンス体制、役員報酬の開示方針など)をLegalForceに取り込み、チェックを実行します。チェック対象としては、金融商品取引法で求められる記載事項との照合、過去に指摘を受けた表現パターンとの類似性検出、曖昧な表現や誤解を招く記述の検出などがあります。
チェック結果はレポートとして出力されるため、IR担当者はその場で修正を行います。1回のチェックで全ての問題を解消する必要はなく、起草の節目ごとに繰り返し実行することで、段階的に品質を高めていきます。FitGapでは、最低でもドラフト完成時と法務部門への提出前の2回はチェックを実行することをおすすめします。
チェック結果のうち、IR担当者の判断では対応が難しい指摘については、次のステップ3で法務部門にエスカレーションします。
LegalForceでのセルフチェックが完了した資料を、ジョブカンワークフローを使って法務部門や経営層の承認フローに乗せます。
ジョブカンワークフローで開示資料レビュー用の申請フォームを作成し、以下の情報を添付して申請します。SharePoint上の資料リンク、LegalForceのチェック結果レポート、未解決の指摘事項とその対応方針です。
承認ルートは、IR担当者からチームリーダー、法務部門、CFOまたは開示責任者という流れで設定します。法務部門は、LegalForceで既にチェック済みの項目については確認を省略し、未解決の指摘事項や機械的なチェックでは判断できない論点に集中してレビューできます。
差し戻しが発生した場合は、ジョブカンワークフロー上にコメントとして修正指示が記録されるため、IR担当者はSharePoint上の資料を修正し、必要に応じてLegalForceで再チェックした上で、再申請します。この履歴が全てジョブカンワークフロー上に残るため、次回の開示サイクルで過去の経緯を確認できます。
開示期限の管理もジョブカンワークフローの期限設定機能を使い、提出期限の5営業日前までに法務レビューが完了するようにリマインダーを設定します。
SharePointを文書管理の中心に据える最大の利点は、多くの企業で既にMicrosoft 365を導入しているため、追加コストなしで利用を開始できることです。バージョン管理、アクセス権限の設定、リスト機能による指摘事項の管理など、開示資料の管理に必要な機能が一通り揃っています。
一方で、SharePointは文書の内容を自動的にチェックする機能は持っていません。あくまでファイルの保管と版管理の基盤であり、法令準拠の確認は別のツールで補う必要があります。また、SharePointのフォルダ構成やメタデータの設計を最初にしっかり行わないと、ファイルが散乱して管理が破綻するリスクがあります。開示資料の種類、年度、ステータスで整理するルールを初期段階で決めておくことが重要です。
LegalForceの強みは、日本の法令や契約実務に特化したAIチェック機能を持っている点です。海外製の汎用的な文書チェックツールと異なり、日本語の法律文書に対する精度が高く、金融商品取引法に関連する記載のチェックにも活用できます。
ただし、LegalForceは万能ではありません。開示資料に特化した専用のチェックルールがあらかじめ用意されているわけではないため、自社の開示資料に合わせたチェック観点の設定や、過去の指摘事項を踏まえた運用上の工夫が必要です。また、AIによるチェックはあくまで補助であり、最終的な法令準拠の判断は法務部門や外部専門家が行う必要があります。FitGapでは、LegalForceを法務部門の作業を代替するものではなく、法務部門に回す前の品質を底上げするツールとして位置づけることをおすすめします。
ジョブカンワークフローは、日本企業の承認フローに合わせた設計がされており、複数段階の承認ルート設定、差し戻し、条件分岐などを直感的に設定できます。開示資料のレビューフローでは、誰がいつ承認したか、どのような修正指示があったかが全て記録として残るため、監査対応や次回の開示準備にも活用できます。
注意点として、ジョブカンワークフローとSharePoint、LegalForceの間にはネイティブな連携機能がないため、資料のリンクやチェック結果の添付は手動で行う必要があります。この手動作業は1回の申請あたり数分程度ですが、完全な自動化を求める場合はAPI連携の開発が必要になります。現実的には、まず手動運用で始めて効果を確認してから、自動化の投資判断をするのが合理的です。
| Tool | Role | Pricing | Implementation time | Notes |
|---|---|---|---|---|
| SharePoint | 開示資料の文書管理・版管理・過去指摘事項の蓄積基盤 | Microsoft 365に含まれる(既存契約で利用可能な場合が多い) | 1〜2週間(フォルダ構成とテンプレート整備) | 開示資料の種類・年度・ステータスでフォルダとメタデータを設計する。バージョン管理を有効化し、指摘事項リストを作成する。Microsoft 365を未導入の場合は別途契約が必要。 |
| LegalForce | 起草段階での法令準拠セルフチェック | 月額課金 | 2〜3週間(チェック観点の設定と運用ルール策定) | 開示資料に関連するチェック観点を整理し、過去の指摘事項をルールとして反映する。AIチェックは補助的な位置づけとし、最終判断は法務部門が行う運用とする。 |
| ジョブカンワークフロー | 開示資料の承認フロー管理と履歴記録 | 月額課金 | 1〜2週間(申請フォームと承認ルートの設定) | 開示資料レビュー用の申請フォームを作成し、IR担当→チームリーダー→法務→CFOの承認ルートを設定する。期限リマインダーを開示提出日の5営業日前に設定する。SharePointやLegalForceとの連携は手動で行い、必要に応じてAPI連携を検討する。 |
開示資料の法令準拠チェックを最終段階に集中させる体制は、手戻りの増大と開示遅延のリスクを構造的に抱えています。SharePointで資料と過去の指摘事項を一元管理し、LegalForceで起草段階からセルフチェックを実行し、ジョブカンワークフローで承認フローと履歴を管理する。この3つを組み合わせることで、法務部門に回る前に大半の問題が解消され、最終レビューは本当に判断が必要な論点に集中できるようになります。
まずは次回の開示サイクルで、ドラフト完成時にLegalForceでチェックを1回実行するところから始めてみてください。それだけでも、最終レビューでの指摘件数がどの程度減るかを実感できるはずです。
Mentioned apps: LegalForce, ジョブカンワークフロー
Related categories: ワークフローシステム, 電子契約システム
Related stack guides: 輸出管理教育の受講完了と実務権限を自動連動させ未受講者による誤申請を防ぐ方法, 該非判定の根拠資料が散逸して再現できない問題を解消し監査対応を万全にする方法, 電子化した契約書・請求書の法的要件を一気通貫で満たし税務調査や監査に備える方法, 補助金の変更申請と実績報告の整合性を保ち事後監査での指摘と返還リスクを防ぐ方法, パートナーへの変更依頼が社内承認後に正しく伝わらない問題を解消し手戻りとプロジェクト遅延を防ぐ方法
サービスカテゴリ
AI・エージェント
ソフトウェア(Saas)