ARCFORGE

生成コストと保有コスト

2023年までは人がコードを書き、開発人員と期間がプロジェクトを決めていました。2024年からはAIエージェントがコードを書きます。生成速度の問題は解消しました。

代わりに別のものが増えました。成果物の総量です。画面300個をコード300個で作れば、保守・回帰試験・デプロイ・引き継ぎの対象も300件になります。コードの生成コストは下がりましたが、保有コストは減っていません。

ARCFORGEがなくそうとしているのは、生成コストではなく保有コストです。

設定による構成

ARCFORGEは、業務システムをAIが操作できる形に再構成したエンタープライズアプリケーションプラットフォームです。画面300個をコード300個ではなく、設定300件で構成します。

三つの要素から成ります。

行動空間 — 画面・項目・検索・ボタン・権限・コードをすべて機械が読み取れる定型メタとして表現します。自由記述のコードは同じ機能を表現する方法が事実上無限ですが、メタ設定は有限のスキーマを持つため正解空間が狭く、検証が決定的になります。

行動境界 — 照会・保存経路の分離、権限のサーバー再検証、監査記録、テナント分離をエンジンで強制します。作成者が誰であっても結果の形が収束します。プラットフォームに内蔵されたAIエージェントも当該事業場の設定・コード・データのみを対象とし、実行エンジン自体の変更は構造的に遮断されています。

報酬信号 — 結果を確率ではなく判定で確認します。

L1〜L5の判定階層

ARCFORGEは結果の信頼水準を、モデルの確率スコアではなく以下の階層を何段階まで通過したかで判定します。

階層	判定対象	判定方法
L1	生成された設定が標準メタの形式を満たすか	形式検査
L2	設定が指す表・項目・コード・手続きが実在するか	実スキーマ照会
L3	データ定義と保存規則が対象DBで成立するか	適用・コンパイル
L4	定義された画面が実際に描画され、照会・保存が動作するか	ブラウザ自動実行
L5	移行・集計の結果が原本と一致するか	原本との照合

L1・L2は保存時点で即座に、L3からL5は移行・配布の時点で自動化スクリプトにより実行されます。診断結果は結論・根拠・選択肢を備える必要があり、「〜と思われる」のような推測による結びは認めていません。

判定結果と障害事例は指針文書として蓄積され、以後すべての作業の先行入力として投入されます。一度経験した失敗が再発しないようにするための構造です。作業者ではなく指針が改善されるため、どのモデルを使っても結果の水準が保たれます。

コーディングエージェントとの比較

コーディングエージェントは「コードをどれだけ速く生成するか」を、ARCFORGEは「AIが何を操作できるか」を扱います。

	コーディングエージェント	ARCFORGE
成果物	ファイル300個＝保守対象300件	単一エンジン、1件の修正が全画面に反映
反映手順	コード → ビルド → デプロイ	保存後に再読み込み
修正主体	開発者	現場担当者・業務企画者
結果の判定	事後に推定	L1〜L5による決定的判定
多顧客運用	顧客数だけソース・分岐が発生	エンジン1種と設定で管理

コーディングエージェントが適する場合 — 非定型の画面、アルゴリズム開発、画面数が少ない単発のプロジェクト。

ARCFORGEが適する場合 — 定型の業務画面が数十〜数百繰り返されるシステム、顧客が多数の販売ソリューション、継続的な保守が必要なエンタープライズシステム。

ARCFORGEもカスタム開発の区間ではコーディングエージェントを道具として使います。ただし実際の表と保存規則を照会したうえで作成し、許可リストに登録された構成要素のみを使用し、指示・実行の履歴が残るという制約の中でのみ動作します。

主な構成

画面構成 — メニュー・レイアウト定義、表の項目および表示形式、詳細入力フォーム、検索条件および自動照会、ボタン動作、Excelアップロード・ダウンロード。

共通モジュール — セキュリティ・アクセス制御、権限マトリクス、多言語、基準コード、印刷様式、ラベル発行、スケジューラ、状況ウィジェット、変更履歴・添付・通知、バックアップ・復元。プロジェクトごとに作り直しません。

AI運用 — 画面生成ウィザード、画面設定の対話型修正、障害原因の診断、ガードレールに基づくコーディング支援。

構築の手順

1. 要求定義・設計 — 担当者が必要な機能とデータ項目を自然言語で説明すると、その内容をもとにテーブル構造とメニュー種別（照会・登録・ポップアップ）を設計します。
2. AI自動生成 — ArcEditが設計案を解釈し、DDLと画面設定（JSON、グリッド G_・詳細 D_ コンポーネントの組み合わせ）を生成します。コーディングなしで対話的に修正できます。生成された設定は配備なしでレンダリングエンジンがそのまま解釈して動く画面として表示するため、項目配置や照会条件をその場で確認し、追加の指示を出せます。
3. 検収・反映 — 照会・登録・修正を実際の業務シナリオどおりに試し、合わない項目は自然言語で指示し直して即座に再生成します。検証が終われば再配備なしで設定の反映だけで運用画面に適用されます。
4. レガシー移行 — 既存システムの画面とDBを分析し、標準画面に転換できるものと、別途の可視化が必要な特殊画面を切り分けます。標準画面はArcSchemaの設定のみで、特殊画面はArcEditのカスタムページとして再構築したうえで、AI検証ハーネスが既存画面と結果値を自動比較して移行の整合性を確認します。

導入要件

配備とサーバー — SaaSとオンプレミスの両方に対応し、セキュリティ方針に応じて選べます。網分離環境はオンプレミスで対応します。標準的なWAS・DBサーバーの仕様で動作し、GPUは必須ではありません。

ただし自然言語による生成機能（ArcEdit・ArcAssist）はLLMエンジンとの連携が必要です。完全な閉域網の場合は、社内網に配置できるLLM連携方式 — オンプレミスLLM、またはセキュリティ区間内のAPIゲートウェイ — を別途協議する必要があります。

事前準備 — 既存のERP・MES・FEMSの画面一覧とDBスキーマ、業務マニュアル・要求定義書が必要です。移行の場合は画面ごとの機能仕様と利用シナリオまで整理されていて初めて、標準画面と特殊画面を切り分けられます。これがないと設計段階で現行分析をやり直すことになり、移行日程（通常およそ1週間）が延びます。

連携 — ERP・MES・FEMSおよび異種マルチDB（Oracle、MSSQLなど）とREST APIで接続するのが原則です。既存システムのDB接続権限とAPI認証情報が事前に提供されている必要があり、閉域網ではサーバーと連携先の間のネットワーク経路・ファイアウォール方針が確保されている必要があります。APIのないレガシーはDB直接連携を別途協議します。

権限と運用 — 照会・登録・管理者など多段階のRBACに対応し、事業場・部署単位のマルチテナントで運用します。登録・修正・削除の履歴は監査ログとして残ります。AIが生成したDDLと画面設定を運用へ反映するには、IT担当者の査読・承認が必要です。 3か国語の自動翻訳と定期バックアップ・復旧の体制を備え、障害時に即座にロールバックできる運用方針が必要です。

構築日程

別途のインストールプログラムがなく、Webブラウザがあれば足ります。業務データベースはMS SQL Server・MariaDB・PostgreSQLに対応します。

標準日程は現況診断から安定化まで7段階・約12週間です。画面数と移行範囲に応じて調整します。

ISO/IEC 27001とGS認証1等級を取得しています。

適用状況

業種と業務が異なる16か所の事業場が単一エンジン上で運用されています。181件の業務画面が設定として定義され、221件のデータテーブルが連携しており、画面別のプログラムファイルは0件です。

代表的な適用事例はレガシーFEMS（工場エネルギー管理システム）の移行です。照会・管理用の標準画面18種はコードなしで設定のみで、エネルギー系統図やチャートなどの特殊な可視化画面15種はAIバイブコーディングによるカスタムページとして再構築し、全画面を移行しました。移行の所要期間は約1週間で、同じプラットフォーム上に6か所の事業場をテナント単位で拡張する構造を確保しています。

ただしこれは社内の移行リファレンスです。外部顧客の実証サイトはまだなく、2026年中に製造企業を対象とした実証を進める予定です。

製品名の変更

ARCFORGEは**アークマインド（ARCMIND）**という名称で開発されました。商標権の問題によりアークフォージ（ARCFORGE）へ変更しています。2026年10月より前の資料ではアークマインドと表記されている場合がありますが、同じ製品です。