建設業向けプライベート・エンタープライズAI：ProjectVIEW AIがERPデータを統制されたインテリジェンスに変える方法

エンタープライズAIは、データ主権と高度な人工知能へのアクセスのどちらかを選ぶよう、企業に強いるべきではありません。

 

• 建設会社、
• EPCコントラクター、
• 造船所、
• オフショア・コントラクター、
• 鉱業会社、そして
• その他のプロジェクト主導型企業

 

は、見積、BoQ、WBS構造、生産性指標、サプライヤーの見積書、調達履歴、契約、クレーム、プロジェクト原価、エンジニアリング記録、商業データなど、最も価値ある知的財産の一部をERPシステム内に保有しています。

 

 

DANAOS ProjectsにおけるProjectVIEW AIの戦略は、これとは異なります。

 

データの管理権を保持する。ビジネスコンテキストを自社で持つ。アクセスを統制する。タスクに適したAI推論エンジンを使う。

 

ProjectVIEW ERP は引き続き業務上の記録システム（System of Record）であり、ビジネスコンテキストの源泉です。AIは、そのコンテキストに基づいて機能する、統制されたインテリジェンス・レイヤーとなります。

 

この区別は根本的なものです。

 

ProjectVIEW AIとは何か？

 

ProjectVIEW AIは、ProjectVIEW ERPのインテリジェンスおよびエージェント型自動化のレイヤーであり、構造化されたプロジェクト固有の企業データとワークフローにAIの推論を適用するよう設計されています。

 

ProjectVIEW ERPは、業務の基盤を提供します。

 

BoQ ↔ WBS ↔ コストコード

 

これらの次元は、商業上のスコープ、工期、リソース、原価、そしてプロジェクトの実際の実行をつなぎます。

 

ProjectVIEW ERPは、すでに次のようなプロセスをサポートしています。

 

• 積算・入札
• 予算策定・原価管理
• 調達
• サブコントラクター管理
• 契約・商務管理
• 資材・生産
• 機械設備・車両
• 人事・給与
• 現場業務
• プロジェクト管理
• 文書管理
• 財務管理

 

ProjectVIEWの公開製品ドキュメントでは、この統合環境とBoQ、WBS、コストコードの関連付けに加え、実績対予算の原価モニタリングや、Oracle Primavera P6、Microsoft Projectなどのシステムとの連携について説明しています。

 

ProjectVIEW AIは、その業務基盤の上にインテリジェンスを構築します。

 

 

なぜAIの前にERPが必要なのか？

 

エンタープライズAIの品質は、AIが利用できる情報の品質、構造、コンテキストに大きく左右されます。

 

汎用的なAIモデルは、発注書が何であるかを理解できるかもしれません。

 

しかし、次のことは本来的には理解していません。

 

• どのプロジェクトがその資材を必要としているのか
• どのBoQ項目がその要求を生み出したのか
• どのWBSアクティビティがそれを必要としているのか
• どのコストコードがその支出を負担すべきか
• どれだけの数量が予算化されていたのか
• すでに何がコミットされているのか
• 実際に何が消費されたのか
• どのサプライヤーが以前に評価されたのか
• その購買が承認基準額を超えているかどうか
• その支出が原価の乖離を生むかどうか
• そして、誰がその取引を承認する権限を持っているのか

 

そのコンテキストは、適切に構造化された建設ERPの中にすでに存在しています。

 

だからこそDANAOSは一貫して主張してきました。企業は、大規模なAI自動化に取り組む前に、ERPとプロセスの基盤を確立すべきだということです。ProjectVIEW ERPは、財務、調達、契約、プロジェクト、業務を共通の業務環境へと構造化します。

 

AIにとって、この構造化された環境は非常に価値があります。

 

AIモデルに、互いにつながっていないスプレッドシート、メール、データベース、文書の非構造的な寄せ集めを理解させる代わりに、ProjectVIEWは特定のタスクに必要な、関連する業務コンテキストへの管理されたアクセスを提供できます。

 

DANAOSのエンタープライズAI戦略とは何か？

 

DANAOSの戦略は、短い言葉で要約できます。

 

データは手元に。インテリジェンスはオーケストレーションで。

 

私たちは、企業が自社固有の業務知識を一般消費者向けの公開AIシステムに明け渡すべきだとは考えていません。

 

また、すべてのコントラクター、造船所、エンジニアリング会社が、大規模なGPUクラスターを購入・維持してAIインフラ企業になる必要があるとも考えていません。

 

その代わりに、ProjectVIEWはモデルに柔軟で、企業が統制するAIアーキテクチャを中心に開発が進められています。

 

このアーキテクチャは、五つの重要なレイヤーを分離します。

 

1. 記録システム — ProjectVIEW ERP

 

ERPは、取引、ワークフロー、予算、契約、調達記録、プロジェクト構造、業務履歴を保持します。

 

2. ビジネスコンテキスト — ProjectVIEWのビジネスロジック

 

BoQ、WBS、コストコード、リソース、契約、承認、そしてプロジェクトの実際の実行が、企業データに意味を与えます。

 

3. ガバナンス — ID、権限、セキュリティ

 

AIのアクセスは、基盤となる企業情報を統制しているのと同じ組織上の境界を尊重しなければなりません。

 

4. インテリジェンス — エンタープライズAIモデル

 

ユースケース、セキュリティ・アーキテクチャ、デプロイ要件、商業上の考慮事項に応じて、適切なAI推論モデルを選択できます。

 

5. アクション — ProjectVIEW AIエージェント

 

目的特化型のエージェントは、質問への回答から、状況の調査、アクションの推奨、そして承認された場合には管理されたワークフローの開始へと、段階的に役割を広げていくことができます。

 

その結果は、単にチャットボットにつながったERPではありません。

 

それは統制されたエージェント型ERP（Governed Agentic ERP）の基盤です。

 

エンタープライズAIでは、ERPデータを公開AIサービスに送る必要があるのか？

 

いいえ。

 

エンタープライズ向けのデプロイでは、企業顧客のデータを一般消費者向けの公開AIサービスから分離するよう特別に設計されたアーキテクチャを使用できます。

 

例えば、MicrosoftのAzure AI / Microsoft Foundryに関するドキュメントでは、Azureが販売するモデルについて、顧客のプロンプト、生成結果（completions）、エンベディング、トレーニングデータは、他の顧客や基盤モデルのプロバイダーには提供されず、顧客の許可なく生成系基盤モデルのトレーニングに使用されることはないとしています。

 

Microsoftはまた、これらのモデルが、基盤モデルのプロバイダーが運営するサービスとやり取りするのではなく、MicrosoftのAzure環境内でホストされているとしています。

 

この区別は重要です。

 

最先端のAIモデルを使うことは、自動的に一般消費者向けの公開チャットボットを使うことを意味するわけではありません。

 

AIが企業情報とどのようにやり取りするかは、エンタープライズ・アーキテクチャ、ID管理、データレジデンシー、保持設定、モデルのデプロイ、契約上の管理によって決まります。

 

データレジデンシーについてはどうか？

 

データレジデンシーについては、単に情報が「ファイアウォールの内側にとどまる」と言うよりも、正確な表現が求められます。

 

Microsoftは、いくつかのデプロイモデルを文書化しています。

 

標準またはリージョナルのデプロイでは、デプロイ構成に応じて、推論処理を選択したデプロイ先の地域（ジオグラフィ）またはリージョン内にとどめることができます。Data Zoneデプロイは定義された地理的ゾーン内で動作し、Globalデプロイは対象となるAzureリージョン全体でリクエストを処理できます。

 

Microsoftはまた、保存データは指定されたAzureの地域内にとどまるとしています。

 

したがって、エンタープライズAIのアーキテクチャでは、次の点を意図的に検討する必要があります。

 

データの所在 → モデルのデプロイ → 保持 → ID → 権限 → ネットワーク・アーキテクチャ → 監査可能性

 

データ主権は、マーケティング上のチェック項目として扱えるものではありません。

 

それはアーキテクチャ上の判断です。

 

ProjectVIEWは、顧客のERPデータベースでAIモデルをトレーニングする必要があるのか？

 

必ずしもその必要はありません。

 

これも、DANAOSのAI戦略における重要な区別の一つです。

 

エンタープライズAIは、企業のERPデータベース全体を取り出して基盤モデルを再トレーニングすることを、常に必要とするわけではありません。

 

その代わりに、システムは特定のリクエストに関連する情報を取得し、推論時にそのコンテキストをモデルに提供することができます。

 

Microsoftは、この種のアーキテクチャを企業データを用いたAI応答のグラウンディングと説明しています。同社の「On Your Data」アーキテクチャでは、関連情報が指定されたソースから取得されてプロンプトの補強に使用され、元のデータは顧客が選択したデータの所在地にとどまります。

 

ProjectVIEWにとって、この考え方は特に強力です。なぜなら、基盤となる情報がすでにプロジェクトのビジネスロジックを中心に構造化されているからです。

 

AIモデルにすべてへの無差別なアクセスを与えるのではなく、システムは適切な権限を持つユーザーに、適切なタスクのための適切なコンテキストを提供できます。

 

建設AIにとって、なぜBoQ、WBS、コストコードが重要なのか？

 

AIにはコンテキストが必要だからです。

 

建設プロジェクトは、単なる会計取引の集まりではありません。

 

原価が業務上の意味を持つのは、企業が次の点を理解したときです。

 

何を販売したか → 何を計画したか → 何を予算化したか → 何をコミットしたか → 何を実行したか → 何を消費したか → 何を支払ったか → 何が残っているか

 

ProjectVIEW ERPは、これらの次元を次の仕組みでつなぎます。

 

BoQ ↔ WBS ↔ コストコード

 

DANAOSは、この構造を、商業上のスコープ、工程計画、原価情報をつなぐプロジェクト・カーネルと位置付けています。

 

これにより、AIには孤立した文書よりもはるかに価値のあるものが提供されます。

 

それが構造化されたプロジェクト・コンテキストです。

 

シンプルな経営上の質問を考えてみましょう。

 

「なぜこのプロジェクトは利益率を失っているのか？」

 

汎用的なチャットボットは、孤立した総勘定元帳からこの質問に確実に答えることはできません。

 

プロジェクトを理解するAI環境であれば、次の要素間の関係を調査できる可能性があります。

 

• 見積原価
• 予算の改訂
• 調達のコミットメント
• サプライヤー価格
• サブコントラクターの出来高認証
• 労働生産性
• 機械設備の稼働率
• 資材消費
• プロジェクトの進捗
• 変更（バリエーション）
• クレーム
• 収益
• 工程の乖離
• 実際原価

 

それが、企業向けソフトウェアに付け加えられたAIと、プロジェクトのビジネスロジックに組み込まれたAIとの違いです。

 

AIアシスタントからAIエージェントへ

 

第一世代のエンタープライズAIは、主に質問に答えるものでした。

 

次の世代は、ますますワークフローに参加するようになります。

 

この移行は重要です。

 

ProjectVIEW AIアシスタントは、次のような質問に答えるかもしれません。

 

 

ProjectVIEW AIエージェントは、さらに先へ進むことができます。

 

 

例えば、調達エージェントは、最新のサプライヤー見積が予算単価を大きく上回っていることを検知できます。

 

そのうえで、次のことができます。

 

1. 関連するBoQと予算を取得する
2. 過去の調達情報を確認する
3. 見積を比較する
4. 原価の乖離を特定する
5. プロジェクトへの潜在的な影響を評価する
6. 適切なアクションを推奨する
7. その推奨をProjectVIEWの承認ワークフローに回す
8. 承認された取引をERPを通じて実行する
9. 意思決定と取引の履歴を保存する

 

重要な言葉は「承認された」です。

 

エンタープライズAIは、単に自律的であるべきではありません。

 

それは統制された自律型インテリジェンスであるべきです。

 

なぜ人による承認が依然として重要なのか

 

ERPシステムが存在する理由の一つは、企業に説明責任が求められるからです。

 

発注書は、単なるテキストではありません。

 

サブコントラクターの出来高証明書も、単なるテキストではありません。

 

変更（バリエーション）も、単なるテキストではありません。

 

これらは商業上のコミットメントです。

 

キャッシュフロー、契約上の責任、プロジェクトの利益率、財務報告に影響を及ぼす可能性があります。

 

つまり、エンタープライズAIは、確立された権限規則の範囲内で機能しなければなりません。

 

NISTのAI Risk Management Frameworkは、AIシステムの設計、デプロイ、利用、評価の全体を通じて、信頼性とリスク管理を組み込むことを重視しています。NISTはまた、生成AI特有のリスクに対応する専用の「Generative AI Profile」も公開しています。

 

ProjectVIEWにとって、その実務上の解釈は明快です。

 

AIは企業のガバナンスを迂回するのではなく、その内側で機能すべきです。

 

ProjectVIEWのAIガバナンス原則

 

このアーキテクチャを理解するのに役立つ考え方は、次のとおりです。

 

 

1. IDがユーザーを特定します。
2. 役割が組織上の責任を定めます。
3. 権限が、どの情報とプロセスにアクセスできるかを決定します。
4. ProjectVIEWが関連する業務データを提供します。
5. AIが、承認されたコンテキストに基づいて推論します。

 

ProjectVIEWが、その後にどのようなアクションを実行できるかを管理します。

 

これが重要なのは、同じAIへの質問でも、まったく異なるアクセス権が必要になる場合があるからです。

 

プロジェクトマネージャー、調達マネージャー、CFO、クオンティティサーベイヤー、サブコントラクターは、同じ質問をしたからといって、必ずしも同じ情報を受け取るべきではありません。

 

ProjectVIEWは、ERP基盤の一部として、ユーザー、役割、グループ単位のアクセス制御と、ワークフロー／ビジネスプロセス管理をすでに提供しています。

 

したがって、AIはエンタープライズ・アーキテクチャにおける、もう一つの統制された参加者となります。

 

ProjectVIEW AIエージェントとは何か？

 

ProjectVIEWの長期的なアーキテクチャは、単一の汎用的な社内チャットボットではなく、目的特化型のAIエージェントに基づいています。

 

想定される領域には次のものがあります。

 

AI入札エージェント

 

過去データの分析、原価見積、入札書類の作成、リスクの特定、シナリオ評価を支援します。

 

AI調達エージェント

 

サプライヤー情報の分析、見積分析、過去価格との比較、調達計画、乖離の検知を支援します。

 

AI原価管理エージェント

 

実績対予算のパフォーマンスを調査し、新たに生じつつある原価の異常を特定します。

 

AI契約エージェント

 

契約記録、変更、クレーム、出来高認証、義務、商務文書の分析を支援します。

 

AIプロジェクト管理エージェント

 

原価、進捗、工程の情報をつなぎ、新たに生じつつあるパフォーマンスの乖離の特定を支援します。

 

AI機械設備エージェント

 

稼働率、保守、ダウンタイム、機器コストの分析を支援します。

 

AI経営エージェント

 

複雑なプロジェクト・ポートフォリオを運営する経営幹部に、プロジェクト横断的なインテリジェンスを提供します。

 

目的は、孤立したアプリケーションをさらに増やすことではありません。

 

目的は、専門化されたAIエージェントがProjectVIEW ERPによって統制された共通のエンタープライズ・データ・ファブリック上で機能できるようにすることです。

 

なぜモデルの柔軟性が重要なのか？

 

AIモデルは極めて速いペースで進化しています。

 

エンタープライズ・ソフトウェア企業にとって、AI戦略全体を一つのモデルに密結合させることは、不要な技術的依存を生むことになります。

 

 

それは、次の要素の組み合わせです。

 

ProjectVIEWのビジネスロジック + 構造化された企業データ + ワークフロー + ガバナンス + 統合 + AIオーケストレーション。

 

推論モデルは進化し得ます。

 

顧客の業務知識は、エンタープライズ・アーキテクチャの中にとどまります。

 

ここから、重要な区別が導かれます。

 

• AIモデルはインテリジェンスを提供します。
• ProjectVIEWはコンテキストを提供します。
• ビジネスロジックは意味を提供します。
• ガバナンスは統制を提供します。

 

これは、その時々で市場をリードしている基盤モデルに会社のAI戦略全体を賭けるよりも、持続性の高いエンタープライズ・アーキテクチャです。

 

なぜ単純にローカルLLMを導入しないのか？

 

ローカルAIモデルには、妥当なユースケースがあります。

 

オフラインでの運用、厳しく制限されたデータ環境、レイテンシー要件、特殊なワークロードなどがそれを正当化する場合には、適切な選択となり得ます。

 

 

したがって、DANAOSはこの選択を次のようには捉えていません。

 

公開AIか、ローカルAIか。

 

より適切な問いは、次のとおりです。

 

企業の各ワークロードに求められるインテリジェンス、セキュリティ、ガバナンス、経済性、データレジデンシーの特性を備えているのは、どのモデルとデプロイ・アーキテクチャか？

 

だからこそ、モデルの柔軟性がProjectVIEW AI戦略の中心にあるのです。

セキュリティはアーキテクチャの一部である

 

AIのセキュリティは、ERPのセキュリティと切り離すことはできません。

 

ProjectVIEW ERPは、アクセス制御、ワークフロー、セキュリティ機構を備えたエンタープライズ環境の中で稼働します。DANAOSが公開しているSaaSフレームワークでは専用のプライベート環境というアプローチが説明されており、またDANAOSはISO 27001やISO 27018を含むISO認証を公表しています。

 

AIインフラのレベルでは、MicrosoftはFoundryの保存データが暗号化されていること、そして対応するサービスと構成では顧客管理キーを使用できることを示しています。

 

したがって、重要な原則は単に次のようなものではありません。

 

「当社のAIは安全です。」

 

そうではなく、次のとおりです。

 

AIは、企業のセキュリティ、ID、データ、ガバナンスのアーキテクチャを継承し、その中で機能します。

 

ProjectVIEWの「リアリティチェック」

 

AIに価値があるのは、AIが推論の対象とする現実が正確である場合に限られます。

 

これは、ProjectVIEW ERPの中核となるビジネスロジックに直接つながっています。

 

あらゆるプロジェクト・プロセスは、最終的に二つの基本的な次元に照らして評価できます。

 

時間（TIME）— 作業分解構成（WBS）によって表されるもの

 

そして

 

原価（COST）— 数量明細書（BoQ）を含む、商業および予算の構造から導かれるもの。

 

そのうえで、実際の実行を計画と継続的に比較することができます。

 

 

• 調達を予算と比較できます。
• サブコントラクターの進捗を、認証済みの出来高と比較できます。
• 資材消費を計画数量と比較できます。
• 労務と機械設備を、想定生産性と比較できます。
• プロジェクトの実際原価を、予算および進捗と比較できます。

 

ProjectVIEW ERPは、すでに実績対予算の原価モニタリングと、労務、プラント・機械、資材、サブコントラクターにわたる現場データの収集を提供しています。

 

AIは、そのリアリティチェックを大幅に強力なものにします。乖離が、もはやダッシュボード上の受動的な数値にとどまる必要がなくなるからです。

 

乖離は、調査を開始させるイベントになり得ます。

 

ビジネスインテリジェンスから機械による推論へ

 

従来のERPレポートが答えるのは、次の問いです。

 

何が起きたのか？

 

ビジネスインテリジェンスは、次の問いに答えるのに役立ちます。

 

それはどこで起きたのか？

 

予測分析は、次のように問います。

 

次に何が起こり得るのか？

 

エージェント型AIは、さらに別の問いをもたらします。

 

それに対して、私たちは何をすべきか？

 

ここで、ERPとAIが融合します。

 

AIモデルは推論することができます。

 

しかし、組織を理解しているのはERPです。

 

ERPは次のことを把握しています。

 

• プロジェクト
• 予算
• 契約
• サプライヤー
• サブコントラクター
• リソース
• 承認
• 責任
• 取引
• そして、プロジェクトの実際の実行

 

この業務基盤のないAIは、商業上の現実から切り離された、見栄えのよいインターフェースになってしまうおそれがあります。

 

ProjectVIEWはその基盤を提供します。

 

DANAOSは何を構築しているのか？

 

DANAOSは、新たな汎用チャットボットを作ろうとしているのではありません。

 

また、私たちの戦略目標は、基盤モデルの開発企業になることでもありません。

 

私たちが構築しているのは、プロジェクト主導型企業のためのAIオーケストレーション・レイヤーです。

 

 

両者が一体となって、DANAOSがProjectVIEW OSと呼ぶアーキテクチャを形成します。これは、建設、海洋・オフショアエンジニアリング、造船、鉱業、その他の複雑なプロジェクト型産業のための統合された業務環境です。

 

方向性は明確です。

 

企業ファーストのアーキテクチャ。プロジェクト中心のビジネスロジック。目的特化型のAIエージェント。

 

建設ERPにおけるAIの未来とは？

 

未来の姿が、ERPの横に置かれたAIチャットボットである可能性は低いでしょう。

 

より大きな影響をもたらす進化は、AIがERPによって管理されたビジネスプロセスの内側で機能することです。

 

つまり、次の段階から、

 

検索 → 回答

 

次の段階へと移行することを意味します。

 

観察 → 理解 → 推論 → 推奨 → 承認 → 実行 → 監査

 

建設をはじめとするプロジェクト型産業にとって、これは特に重要です。プロジェクトの収益性は、原価、工期、リソース、契約、業務の実行に関わる、互いに結び付いた何千もの意思決定に左右されるからです。

 

AIは、そうした意思決定を加速させることができます。

 

しかし、それらの意思決定を検証するためのビジネス上の現実を提供するのはProjectVIEWです。

 

DANAOSのProjectVIEW AI戦略

 

この戦略は、最終的に七つの原則に要約できます。

 

• 企業データを統制された状態に保つ。
• ProjectVIEW ERPを記録システムとして維持する。
• BoQ、WBS、コストコードによってプロジェクトの現実を構造化する。
• AIには、承認されたタスクに必要なビジネスコンテキストのみを与える。
• 基盤となる推論モデルについて柔軟性を保つ。
• 互いにつながらない汎用AIツールではなく、目的特化型のAIエージェントを使う。
• 重大な影響を伴うアクションは、企業のワークフロー、権限、承認、監査証跡の中にとどめる。

 

それがProjectVIEW AIの方向性です。

 

• AIがERPを置き換えるのではありません。
• AIがERPの外側で機能するのではありません。
• ERPデータをAIに明け渡すのではありません。

 

AIが、企業の業務モデルの内側で、インテリジェントかつ統制された参加者となるのです。

 

ProjectVIEWが現実を提供し、AIが推論を提供します。両者が一体となって、インテリジェントなプロジェクト企業を生み出します。

 

---