このページの内容は、サードパーティサービスによって自動翻訳されています。

エンジニアリングチームが要件に苦労する理由は、必要な情報が不足しているからではありません。多くの場合、情報は人が読むために作成された文書として提供されており、PLMシステムが管理できる形式ではないことが原因です。

製品仕様書には、エンジニアリングに必要なあらゆる情報が含まれています。要件記述、セクション番号、見出し、表、図、注記、リスト、そしてそれらを補完するコンテキストです。しかし、その情報を Aras Innovator® で活用できるようにするには、誰かが内容を解釈し、要件と補足情報を切り分け、適切なコンテキストを保持しながら、その構造を手作業で再現しなければなりません。

まさにここで非効率が生まれます。

エンジニアは文書を読み込み、それぞれの要件を特定し、どこで一つの要件が終わり次の要件が始まるのかを判断し、内容を分類するとともに、図表などの重要な補足情報が失われないよう確認する必要があります。この作業は繰り返しが多く、時間がかかるうえ、ミスも起こりやすいものです。さらに重要なのは、本来であれば技術的な判断に集中すべき熟練エンジニアの時間が、文書の転記作業に費やされてしまうことです。

これは単なる事務作業上の不便さではありません。要件はトレーサビリティの出発点です。要件が遅れて、不完全な形で、あるいは適切な構造を持たないままシステムに取り込まれると、その後のすべてのプロセスが不安定な土台の上で進むことになります。

Requirements Ingestion Agent は、まさにこの課題を解決するために設計されています。

このエージェントは、Aras InnovatorEdge AI を活用して仕様書を取り込み、要件を抽出・正規化し、補足情報を保持したまま、Aras Innovator 内のガバナンスされた要件オブジェクトへとマッピングします。目的は単に PDF をより速く読み取ることではありません。人が読むための仕様書を、デジタルスレッド内で利用できる構造化されたトレーサブルな要件データへと変換することです。

デモをご覧いただく前に

デモを見る前に、注目すべきポイントを理解しておくと役立ちます。

これからご覧いただくのは、単なる文書のアップロードではありません。重要なのは、Requirements Ingestion Agent が複雑な技術仕様書を、Aras Innovator が理解・管理し、他の情報と関連付けられるガバナンスされた要件へと変換する点です。

この例では、入力となる文書は石油・ガス業界の仕様書です。文書には本文、セクション番号、要件記述、表、図、リスト、そして文書構造に関する情報が含まれています。課題は単にテキストを抽出することではありません。文脈の中でその意味を理解することです。

特に注目していただきたいポイントは3つあります。

まず、文書が Edge App にアップロードされる様子をご覧ください。ここが取り込みワークフローの開始点になります。

次に、カスタム解析指示に注目してください。ここでは、文書固有のルールに合わせてエージェントを調整できます。例えば、セクション番号の扱い方、どの記述を要件として認識するか、どの補足情報を保持するか、どの情報を除外するかなどを指定できます。

最後に、レビューのステップをご覧ください。ここでエージェントの処理結果が確認できます。要件は個別に整理され、タイトルが付与され、図表などの補足情報も保持されます。また、Aras Innovator に公開する前に、ユーザーが内容を確認・修正できます。

ここで重要なのは、文書の内容がガバナンスされた要件オブジェクトへと変換されることです。

より本質的な問いは、「このエージェントは、複雑な仕様書をエンジニアが信頼できるトレーサブルな要件へと変換することで、企業を支援できるか」という点です。

それでは、今ご覧いただいた内容について詳しく見ていきましょう

ここまでご覧いただいた内容を振り返りましょう

このデモをご覧になった多くの方が最初に感じるのは、その処理速度でしょう。通常であれば手作業によるレビューとデータ入力が必要となる仕様書が、ガイド付きワークフローによって解析・構造化され、インポートできる状態まで準備されます。

しかし、本当に重要なのは、その裏側で行われている処理です。

プロセスは元となる PDF から始まります。まずエージェントは文書構造を解析し、セクション、見出し、テキストブロック、要件候補、表、図、およびその他の補足要素を識別します。これは重要な処理です。要件は単独で存在するものではなく、文書全体の階層構造の中に位置付けられており、その階層構造が要件の意味や解釈を左右することが少なくないからです。

続いて、エージェントは要件となる内容を検出し、それ以外の情報と切り分けます。このデモでは、カスタム指示によって仕様書固有の記述ルールをエージェントに理解させています。その結果、要件の境界、タイトル、除外対象、補足情報などをより正確に認識できるようになります。

その後、抽出された情報は Aras Innovator の要件スキーマへマッピングされます。生成されるのは単なるテキスト抽出ファイルではありません。Aras Innovator 内で要件文書として利用できる構造化データです。

これこそが、このデモが伝えたい本質です。構造化されていない仕様書の内容が、PLMで管理可能な要件へと変換されるのです。

カスタム指示が重要である理由

このデモの中でも特に重要でありながら見落とされがちな機能が、カスタム指示フィールドです。

これが、一般的な PDF パーサーとの大きな違いです。

仕様書にはそれぞれ独自のルールがあります。セクション番号を要件の識別情報として扱うものもあれば、要件として扱うべきではない注記を含むものもあります。また、表や図を対応する要件と関連付けたまま保持する必要がある場合もあります。

Requirements Ingestion Agent は、こうした文書固有のルールに基づいて動作を調整できます。

つまり、ドメイン知識をプロセスに取り込めるということです。単一の固定されたパーサーにロジックを組み込むわけではありません。これは非常に重要です。要件の品質は単に言葉を抽出することではなく、その意図を正しく保持することによって決まるからです。

人によるレビューが不可欠である理由

デモで確認できるもう一つの重要な点は、プロセス全体がレビュー可能であることです。

Requirements Ingestion Agent の価値は、エンジニアをプロセスから排除することではありません。繰り返し発生する手作業を自動化しながらも、最終的な判断はエンジニアが行えるようにすることです。

レビューの段階では、ユーザーは公開前に抽出された要件を確認できます。タイトルや要件本文を確認し、図などの補足情報が正しく取り込まれているかを検証し、不要な内容を削除することも可能です。修正が必要な場合は、Aras Innovator に要件文書を作成する前に変更できます。

この Human-in-the-Loop のステップは非常に重要です。

要件はエンジニアリング全体の基盤となるオブジェクトです。ここで発生した誤りは、設計判断、検証、コンプライアンス、変更影響分析、そしてその後のトレーサビリティにまで影響を及ぼす可能性があります。そのため、単に処理速度が速いだけでは十分ではありません。企業には、抽出された内容を確認し、必要に応じて修正・承認した上で、ガバナンスされたデータとして登録できる仕組みが必要です。

AI は抽出、構造化、正規化を担当します。

エンジニアは意図の確認、妥当性の検証、そして最終的な責任を担います。

これこそが、人と AI の適切な役割分担です。

Aras Innovator で行われる処理

最後のステップは公開です。

レビューが完了すると、アプリケーションは Aras Innovator 内に要件文書を作成します。このデモでは、元の仕様書から 155 件の要件が取り込まれ、Innovator 環境に登録されます。

ここに、このソリューションの本当の価値があります。

元の情報はもはや PDF の中に閉じ込められたままではありません。構造化され、ガバナンスされた要件データへと変換されます。要件文書、個々の要件オブジェクト、補足テキスト、画像、そしてそれらの関連情報はすべて Aras Innovator 内で利用できるようになり、ライフサイクル全体のガバナンスやトレーサビリティの一部として活用できます。

ここで、ビジネス上の価値が明確になります。

このエージェントは単に情報を抽出するだけではありません。デジタルスレッドを構成する情報を充実させる役割を果たします。

エンジニアリング組織にとって重要な理由

このソリューションがもたらす価値は非常に明確です。

要件を手作業で取り込むプロセスは、専門知識を持つ人材の時間を奪い、一貫性の欠如を招き、トレーサビリティの確立を遅らせます。Requirements Ingestion Agent は、レビューとガバナンスを維持しながら、取り込み作業の中でも特に繰り返し発生する部分を自動化することで、この課題を解決します。

エンジニアリング組織にとっては、要件の取り込みをより迅速に行えるだけでなく、要件構造の一貫性向上、転記ミスの削減、そしてより早い段階でのトレーサビリティ確立につながります。

さらに、その後に続くあらゆるプロセスにとって、より優れた出発点を提供します。要件は設計、検証、変更影響分析、コンプライアンス対応、そしてその後のエンジニアリングにおける意思決定へと活用されます。これらの要件が早い段階でガバナンスされたデータとなるほど、デジタルスレッドはより強固なものになります。

だからこそ、要件の取り込みは重要なのです。

これは単に文書をアップロードするための仕組みではありません。外部の仕様書を、実際に活用できる製品知識へと変換することを支援する仕組みなのです。

このデモから得られる最も重要なポイント

このデモを初めて見た人は、何を持ち帰るべきでしょうか。

答えは、「AI は PDF から要件を抽出できる」ということではありません。

PLM において AI が真価を発揮するのは、複雑で外部に存在する製品情報を、企業が実際に活用できるガバナンスされた構造へと変換するときです。

Requirements Ingestion Agent は、エンジニアリングチームが日常的に受け取る仕様書から作業を開始し、文書ごとのルールを適用しながら要件を抽出・正規化し、補足情報を保持し、エンジニアによるレビューを経て、承認された結果を Aras Innovator に直接登録します。

これは、単なる自動化のための自動化ではありません。

仕様書を、デジタルスレッドの中で活用できるトレーサブルな要件へと変換する、実践的なアプローチです。