統合ERPなしでAIエージェントが失敗する理由

プロジェクト型企業においてAIエージェントが失敗するのは、分断されたデータ上で、ビジネスコンテキストを持たず、統制されたシステム内で行動する権限もないまま動作する場合です。統合ERPは、エージェントに単一のデータセット、推論の基盤となる原価構造、そして実行できる内容を管理するロールと承認を提供します。DANAOS ProjectVIEW AIはこの原則に基づいて構築されています。そのエージェントは、BoQ ↔ WBS ↔ コストコードのフレームワーク上に構築された統合ERPであるProjectVIEW ERP上で動作します。

このページは、建設、造船・修繕、海洋・オフショア、鉱業・採石、プロジェクト型製造の各業界で、自社のシステム環境のどこにAIエージェントを配置すべきかを検討している役員および経営層の方々を対象としています。

エージェントのパイロットが失敗する原因の多くは、モデルの性能不足ではありません。モデルが何に接続されているかが原因です。繰り返し見られる原因は次の4つです。

1. 分断されたデータ。見積はスプレッドシートに、発注は購買ツールに、進捗は工程管理ソフトに、請求書は会計システムにあります。各システムは真実の一部しか保持していません。そのうちの一つだけを読み取るエージェントは、部分的な回答を自信満々に返してしまいます。
2. ビジネスコンテキストの欠如。発注書の明細は、それがどのBoQ項目、どのWBS要素、どのコストコードに属するかをエージェントが知らなければ、単なる数字にすぎません。この紐付けがなければ、エージェントは見積が予算単価を上回っているか、原価が正しいアクティビティに対して計上されているかを判断できません。
3. トランザクション権限の欠如。基幹システムの外にあるエージェントは提案はできますが、管理された方法で何かを作成、承認、計上することはできません。助言にとどまるか、権限を迂回し監査証跡を残さない回避策を通じて行動するかのいずれかになります。
4. 壊れたプロセスを増幅する。AIは壊れたプロセスを直してはくれません。むしろ増幅させます。承認が非公式で、コストコードに一貫性がなく、システム間でデータが再入力されている場合、エージェントはその不整合をより速いスピードで自動化してしまいます。

プロセス面については、インサイト記事AIエージェントは壊れたERPを直さないで詳しく解説しています。

統合ERPは、エージェントがたまたま読み取るデータソースではありません。エージェントの作業を信頼性が高く管理可能なものにする枠組みです。

• 共通の原価構造。ProjectVIEW ERPでは、すべての見積、予算、発注、出来高請求、原価がBoQ、WBS、コストコードに紐付けられています。エージェントは、各要素がどうつながるかを推測することなく、入札から最終精算まで数値を追跡できます。
• 単一のデータセット。積算、調達、下請業者、資材、機械、人事、会計が同じ記録を使って業務を行います。ERPは何が起きたかを記録し、AIはなぜそれが起きたのか、そして次に何が起きるのかを説明します。
• ロールと権限。エージェントは「ID → ロール → 権限 → データ → AI → アクション」というガバナンスの連鎖を通じて動作します。ユーザーのロールが許可する範囲のみを参照し、実行します。
• 承認と監査。重要なアクションは人によるアクションと同じ承認ワークフローを経て、すべてのステップが記録されます。

この組み合わせは、決定論的なERP＋確率論的なAIです。ERPがルールを徹底し、AIがパターンを見つけ、説明し、提案します。

ProjectVIEW AIのエージェントは、「検知 → 調査 → 説明 → 提案 → 承認依頼 → 実行 → 監査」という決まったサイクルに従います。

例：調達エージェントが、あるBoQ項目について予算単価を上回る仕入先の見積を検知します。その項目の原価構成、過去の購買、現在の発注状況を調査し、差異を説明したうえで、再見積の依頼や差異メモ付きでの承認などの対応を提案します。購買担当者またはプロジェクトマネージャーが承認または却下します。その後に初めてERP内でアクションが実行され、一連の流れはすべて監査のために記録されます。

エージェントは継続的に監視・分析を行いますが、重要なアクションには必ず人による承認が必要です。これは制約ではなく、意図的な設計です。

すべてのAI活用に統合ERPが必要なわけではありません。ユースケースについて率直に判断してください。

• 文章作成と要約。書簡の作成、契約書の要約、施工要領書の翻訳などは、汎用アシスタントと文書があれば十分に機能します。
• 単発の分析。一度だけエクスポートしたデータを一度分析し、結果を人が確認する場合、リスクは限定的です。
• 試行。システムに関する意思決定の前に、AIで何ができるかを試すことは妥当な第一歩です。

一線を越えるのは、エージェントの出力が、経営陣が依拠する発注、支払、出来高査定、予測に反映される場合です。その時点で、エージェントには基幹システムのコンテキストと統制が必要になります。

ProjectVIEW AIは既存システムの上で動作させることもできます。SAPやOracleなどのサードパーティERP、Primavera P6、MS Project、BIMモデル、文書管理システムと接続し、データをBoQ、WBS、コストコードの構造にマッピングします。購入方法は3つあります。ProjectVIEW ERPのみ、既存システムの上にProjectVIEW AIを導入、または両方をProjectVIEW OSとしてまとめて導入する方法です。

トレードオフは明確です。基盤となるシステム環境が分断されているほど、エージェントを信頼できるようになるまでに、データのマッピングと照合により多くの労力がかかります。サードパーティERP連携およびProjectVIEWと汎用ERPシステムの比較をご覧ください。

1. 一つの原価構造（BoQ、WBS、コストコード）について合意し、すべてのモジュールで使用します。
2. 承認を正式化します。誰が、どの金額で、どのプロジェクトについて何を承認するのかを定めます。
3. 可能な限り、システム間の再入力をなくします。
4. 明確なルールのある一つのプロセス、例えば予算単価に対する見積チェックからエージェントを開始します。
5. すべての重要なアクションに人の承認者を置き、監査ログを確認します。

AIの側面については、ProjectVIEW AIエージェントおよびセキュリティとガバナンスをご覧ください。原価構造については、プロジェクト原価管理とはをご覧ください。

BoQ ↔ WBS ↔ コストコードの上に構築された、ガバナンスの効いた単一のERPデータセット上で、ProjectVIEW AIのエージェントがどのように動作するかをご覧ください。