よくある質問

3forgeは、リアルタイムでデータ集約型のアプリケーションを構築・運用するためのアプリケーション・ファブリックである3forge Enterpriseを提供する企業です。アプリケーション・ファブリックは、データアクセス、イベント処理、アプリケーション開発、運用管理を単一のガバナンスされたランタイムに統合します。メッセージング、データベース、ダッシュボード、権限管理、レポーティング、ワークフローロジックのために個別の製品を組み合わせる代わりに、エンジニアリングチームは本番品質の共通基盤の上に構築し、自社の業務課題に固有のロジックだけを記述します。

3forgeは金融機関のために原理原則から設計されました。金融機関のアプリケーションは、継続的なデータストリームを処理し、イベントに決定論的に応答し、きめ細かな権限を適用し、運用面・規制面の監視に対して透明性を保つ必要があります。

アプリケーション・ファブリックは、既存の企業環境全体でデータ、ロジック、アプリケーション、実行を接続するための3forgeのアーキテクチャモデルです。リアルタイムデータと蓄積データへのガバナンスされたアクセスを仮想化し、アプリケーションの構築と運用に必要な共通ランタイムサービスを提供し、ユーザー、ワークフロー、分析ツール、AIエージェントを一貫したインターフェースで接続します。

アプリケーション・ファブリックは企業の技術スタックを置き換えるものではありません。既存のデータベース、レガシーシステム、業務アプリケーション、Excelワークブック、ノートブック、Reactなどのフレームワークはそのまま残り、観測可能で管理された単一の環境の参加者になります。アプリケーションをファブリックの一部にするのは、そのインターフェースがどこで構築されたかではなく、データへのアクセス、ロジックの呼び出し、制御の適用、動作の可視化をどれだけ一貫して行うかです。

アプリケーション・ファブリックは、企業が通常は別々に調達・開発・運用する3つの機能を統合します。

• リアルタイム Data Fabric。データベース、ストリーム、API、ファイル、メッセージングシステムへのガバナンスされたアクセスに加え、運用ワークロードが必要とするキャッシング、永続化、正規化、複合イベント処理、制御された配信を提供します。
• Application Engine。状態管理、イベント処理、権限、フォーム、可視化、レポーティング、テスト、デプロイ、モニタリングなど、アプリケーションが繰り返し必要とするサービスを提供し、開発者が業務固有のロジックに集中できるようにします。
• Operations Hub。デプロイ済みのアプリケーション、コンポーネント、依存関係、バージョン、ライセンス、ワークロードを対象とした、全社規模の可視性と制御を提供します。

これらの柱は互いを強化します。あるプロジェクトのために作成された接続、変換、ポリシー、アプリケーションコンポーネントは再利用可能になるため、新しいユースケースごとに孤立したスタックが増えるのではなく、共通基盤が強化されていきます。

一般的な意味ではありません。3forgeは金融ネイティブのアプリケーションエンジンと表現するのが適切です。ビジュアル開発機能や高速なUI構成を備えていますが、真の価値はランタイム自体が金融機関の繰り返し必要とするデータ、ロジック、ガバナンス、運用機能をすでに内包している点にあります。この点で、汎用のローコードツールや単体のダッシュボード製品とは根本的に異なります。

開発者は明示的な業務ロジックを記述し、独自のワークフローを設計します。共通部分はエンジンが担うため、3forgeはこのモデルをラストマイル開発と呼んでいます。

3forgeはティア1の投資銀行、グローバルヘッジファンド、アセットマネージャー、プライムブローカー、取引所、プライベートエクイティ会社、政府系ファンドで導入されています。数千人のユーザーを抱える大手セルサイド機関から、インフラをゼロから構築せずに迅速に動く必要がある少数精鋭のバイサイド企業まで、幅広く利用されています。世界中で数千人の開発者がこのプラットフォーム上で構築しています。

一般的なユースケースには、トレーディングデスク向けアプリケーション、リアルタイムのリスクとP&L、ポストトレードの照合、コンプライアンス監視、プライベートキャピタルのファンド業務、運用ダッシュボードが含まれます。

BIツールは、静的またはバッチ更新のデータセットを照会するビジネスアナリスト向けに設計されています。3forgeは、リアルタイムストリーミングデータの上にアプリケーションを構築する開発者向けに設計されており、ミリ秒未満の更新レイテンシ、複合イベント処理、システム全体に対する完全なプログラム制御を備えています。

BIツールと異なり、3forgeは完全な開発プラットフォームです。独自のインメモリデータベース、ヒストリカルデータベース、フィードハンドラフレームワーク、スクリプト言語（AmiScript）、そして規制業種の24時間365日の本番環境向けに設計されたデプロイモデルを備えています。TableauやPower BIは3forge ODBCドライバ経由でファブリックのコンシューマーにもなれるため、両者は排他的ではありません。

3forgeは主にクライアントのインフラ内でオンプレミス導入されます。データ所在地、セキュリティ、規制上の制約から、多くの機関投資家がこれを求めるためです。Kubernetes上のコンテナ環境を含め、プライベートクラウドおよびハイブリッド構成も完全にサポートされています。

一部のユースケースではマネージド導入オプションも利用できます。お客様の環境に最適な導入モデルについてはお問い合わせください。

3forgeのライセンスは、各機関の導入規模とユースケースに合わせて設計されます。単一部門での利用か、グローバル複数リージョンでの展開かにかかわらず、営業チームが導入範囲を反映した契約を一緒に組み立てます。

運用面では、ライセンスは手作業でのマシンごとのやり取りではなく、Operations Hubを通じてクライアント自身が管理します。ライセンス発行、猶予期間、オフライン環境の扱いについてはOperations Hubとライセンスのセクションをご覧ください。

近年の主な受賞歴は次のとおりです。

• Prime Broker of the Year, Technology：HedgeWeek 2025
• Best Full-Stack Dev Platform：Trading Tech Insights Europe 2025
• Best Trading Tech Stack Platform：Trading Tech Insights USA Awards 2025
• Best Sell-Side Web-Based Development Environment：Sell-Side Tech Awards 2025
• Best Transaction Cost Analysis System Provider：Waters Rankings 2025

3forgeはニューヨーク（225 Broadway, Floor 40, New York, NY 10007）に本社を置き、オーランド、ロンドン、シンガポール、香港、東京、トロントにオフィスがあります。一般的なお問い合わせはinfo@3forge.comまでお寄せください。

リアルタイム Data Fabricはアプリケーション・ファブリックの第一の柱です。ソースシステムが正本であり続けることを保ちながら、データベース、ストリーム、API、ファイル、メッセージングシステムへのガバナンスされたアクセスを提供し、アプリケーション、ユーザー、エージェントに対して、ファブリック内のデータノードにまたがるリアルタイムおよび履歴のテーブル、ストリーム、プロシージャへの統一された現在状態のアクセスを与えます。

これはデータを置くための新しい場所ではありません。企業がすでに運用しているリポジトリ、ストリーム、システムの上に重なる共通の運用レイヤーであり、ソースとその利用者の間に、運用ワークロードが必要とするキャッシング、永続化、正規化、複合イベント処理、制御された配信を追加します。

リアルタイムデータは動いているデータです。市場のティック、注文と約定のイベント、テレメトリ、フィードやメッセージバス、ストリーミング基盤から連続的に届くメッセージなどです。その価値は到着した瞬間に最も高く、何かが捕捉しない限り、後から照会できる安定した形を持ちません。

蓄積データ（データアットレスト、履歴データとも呼ばれます）は、すでに書き込まれたデータです。ポジション、参照データや顧客データ、過去の取引、日次終了時点の記録、データベース、ウェアハウス、レイク、ファイルに保持される長期履歴などです。安定して照会できますが、過去を記述するものです。

現実の業務上の問いは、たいていその両方を同時に必要とします。「今この瞬間のエクスポージャーはいくらか」は、蓄積されたポジションをライブの価格で再評価したものです。「このアルゴリズムは正常に動いているか」は、ライブの注文フローを履歴のベースラインと比較したものです。どちらか一方だけでは答えられません。だからこそ3forgeは、両者を2つのシステムではなく1つの運用モデルとして扱います。

データ仮想化とは、まず単一の物理ストアへ複製することなく、データを照会し、購読し、組み合わせるための一貫した方法を利用者に提供することです。プラットフォームは分散したソースを安定したインターフェースで提示し、その背後でソースへの接続、正規化、権限、キャッシング、負荷制御を管理します。

実務上の帰結として、成果物の提供を統合プロジェクトの完了まで待つ必要がなくなります。ソースシステムは引き続き正本であり、それぞれのライフサイクルを保ちながら、保持するデータは物理的に集約されるのではなく運用上つながった状態になります。

両者は工学的な性質が根本的に異なり、結合はそのすべてを同時に折り合わせる必要があるためです。

• アクセスモデルが異なる。蓄積データは有限の結果を返すクエリで引き出します。リアルタイムデータは非有界のイベント列として押し出されます。一方はリクエスト・レスポンス、もう一方は購読です。
• 正しさの概念が異なる。履歴クエリは再現可能です。ストリーミング結合は、各瞬間において「現在」が何を意味するかを定義し、遅延したメッセージ、順序が乱れたメッセージ、訂正されたメッセージをどう扱うかを決めなければなりません。
• 性能の許容範囲が異なる。秒単位で測るウェアハウスのクエリを、マイクロ秒単位で測るイベントストリームの経路上に置くことはできません。
• 状態をどこかに保持する必要がある。ストリームを参照データと結合するには、現在の状態をメモリに保持し、双方が変化する中で正しさを保ち、しかも無制限に増大させないようにしなければなりません。
• 権限が両方にまたがる必要がある。あるデスクのポジションを見る権限を持つユーザーは、そのデスクのライブイベントだけを見るべきであり、双方で同一に適用される必要があります。

これをアプリケーションごとに解決すると、重複し、微妙に食い違う実装が生まれます。3forgeはこれをCenterで一度だけ実装します。インメモリのリアルタイムデータベース、ヒストリカルデータベース、複合イベント処理エンジンが同じランタイムに置かれ、単一のデータモデル内でまとめて照会できます。

いいえ。これが「データはあるべき場所に置いたまま」という原則です。新しいアプリケーションがアクセスしたいというだけの理由でデータを複製すべきではありません。ファブリックはアクセスを仮想化し、分散したソースを一貫したインターフェース、ポリシー、運用制御を通じて提示します。ソースシステムは引き続き正本であり続けます。

結果として生まれるのは新たな中央リポジトリではありません。企業がすでに使っているリポジトリ、ストリーム、システムの上に重なる共通の運用レイヤーであり、その中でリアルタイムデータと履歴データは物理的には分散したまま、運用上は接続されます。

3forgeはデータベース、フィード、API、レガシーシステムへのアクセスを仮想化し、チームが単一のガバナンスされたレイヤーを通じてそれらを扱えるようにします。リアルタイムデータと蓄積データは、ワークフローごとに統合ロジックを作り直すことなく、まとめて照会、結合、エンリッチ、業務利用できます。

運用ワークロードには仮想化だけでは不十分なため、ファブリックはソースとコンシューマーの間に機能レイヤーを追加します。基盤システムを保護しレイテンシを下げるキャッシング、後続分析のための永続化、複数ソースにまたがる正規化とエンリッチ、配信前のライブイベントへのフィルタリング、コンフレーション、ビジネスルール適用です。

同じガバナンスされた情報を、アプリケーション、AIエージェント、Pythonプロセス、API、レポート、ダッシュボード、PDF、Excelへ届けられます。利用者ごとに別々の統合経路を作る必要はありません。

これが重要なのは、企業のプラットフォームが今やレポートを読む人よりもはるかに広い利用者層に対応しているからです。サービス、モデル、エージェント、自動化されたワークフローが、それぞれ異なるアクセスパターンと性能要件で継続的にデータを消費します。そのそれぞれが独自の統合を作れば、維持すべき接続、変換、アクセス制御の組がさらに増えていきます。

従来のデータガバナンスは、ユーザー、データベース、レポーティング環境を中心に据えてきました。アイデンティティとロールに基づいてアクセスを付与し、カタログ、リネージツール、監査システムが情報の保管と利用のされ方を記録します。しかし利用者の数と種類が増えるにつれ、このモデルの適用は難しくなります。アプリケーションはユーザーに代わって複数のソースにアクセスします。サービスは人の関与なしに動き続けます。エージェントは動的にツールを選び、クエリを連鎖させ、他のシステムへ流れ込む出力を生み出します。

3forge創業者兼CEOのRobert Cookeはそのリスクを次のように率直に述べています。「there is now suddenly this lack of governance over how things are tested and around how things are being built, how things are connected.」

したがってガバナンスは、各データベースの境界でのアクセス制御に頼ることはできません。データが要求され、変換され、配信され、実行に使われる経路全体に及ぶ必要があり、かつ観測可能でなければなりません。どの利用者がどのソースを使い、データがアプリケーションをどう流れ、ポリシーがどこで適用され、いつ挙動が変化したかをチームが把握できることが求められます。後付けにすれば、新しい利用者が増えるたびに例外管理が増えます。データにアクセスするレイヤーそのものの性質にすれば、その上に築かれるすべてがそれを継承します。

エージェントと自動化されたワークフローは、より高い頻度で情報を消費し、より広い範囲のソースを組み合わせ、ユーザーがアプリケーションを操作するのを待たずに処理を開始することがあります。同時に、AI支援の開発により、企業がガバナンスし運用しなければならないアプリケーション、サービス、インターフェースの数も増えます。

そのためプラットフォームは、誰が、あるいは何が要求を出しているのか、どの情報にアクセスしてよいのか、どの操作を実行してよいのか、ソースにどれだけの負荷をかけてよいのか、その出力をどこへ送ってよいのかを把握する必要があります。これらのポリシーは、利用者が人であれ、アプリケーションであれ、Pythonプロセスであれ、エージェントであれ、一貫して適用されなければなりません。エージェントが、ユーザーやアプリケーションに定められた統制を迂回する並行経路を得るべきではありません。

いいえ。ウェアハウスやレイクは行き先です。そこへデータを移し、そこで照会します。リアルタイム Data Fabricは、企業がすでに運用しているシステム群の上に位置するアクセスと処理のレイヤーであり、ウェアハウスやレイクもその一部として、通常はガバナンスされたソースのひとつになります。

運用上の目的にかなう場合、ファブリックはデータを保持します。Centerは現在の状態をインメモリデータベースに保ち、選択した履歴を自身のヒストリカルデータベースへ永続化でき、頻繁に要求される情報は基盤システムを保護するためにキャッシュできます。しかし目的は唯一の正本になることではありません。大企業は今後もワークロードごとに異なる技術を使い続け、ソースシステムはしばしば正本であり続ける必要があります。

アプリケーションエンジンとは、本格的なアプリケーションが必ず必要とする共通インフラ、すなわち接続性、セキュリティ、状態管理、モニタリング、ライフサイクル管理を標準化する共有ランタイムです。3forgeはその考え方を金融機関に特化して適用します。リスクツール、運用モニター、レポーティングワークフローごとに同じ配管を作り直す代わりに、リアルタイムデータ、決定論的な動作、権限管理、監査可能性をすでに理解している金融ネイティブのランタイムの上に構築します。

アプリケーションエンジンは、ソフトウェアの書き方だけでなく、動き方を定義します。データの移動、処理のスケジューリング、リソースの割り当て、障害の処理、アプリケーションのライフサイクルを管理します。

UnityやUnrealなどのゲームエンジンは、レンダリング、物理演算、アニメーション、入力処理、ネットワーク、アセット管理、デプロイを共有ランタイムとして提供し、開発者がゲームを差別化するメカニクス、コンテンツ、体験に集中できるようにします。企業のアプリケーション開発にも同じ反復構造があります。ほとんどの業務アプリケーションは、接続性、状態管理、並行処理、イベント処理、認証、権限管理、ワークフロー、可視化、レポーティング、モニタリング、デプロイを必要とします。

3forgeはこれらの関心事をエンジンのレベルで一度だけ実装し、その上に構築されるすべてのアプリケーションに一貫して適用します。エンジンを採用するアプリケーションが増えるほど、接続、制御、コンポーネント、運用手法は作り直されるのではなく再利用されます。これがラストマイル開発の原則です。共通部分はエンジンが担い、開発者は違いを生む部分に集中します。

チームがファブリック上で直接構築する場合、Application Engineは必要な技術基盤のおよそ95パーセントを提供します。これには状態管理、イベント処理、権限、フォーム、可視化、レポーティング、テスト、デプロイ、モニタリングが含まれます。開発者は業務固有のロジックとインタラクションに集中します。

ファブリック上に構築されたアプリケーションは、追加の統合レイヤーを作ることなく同じデータ、変換、権限、処理ロジックを利用し、依存関係、アクティビティ、パフォーマンスが設計上observableな、管理された本番ランタイムに入ります。

金融ソフトウェアの構築方法を検討する組織は、一般に3つのアプローチに行き着きます。それぞれ、速度、柔軟性、統制、持続可能性のトレードオフが異なります。

• ベンダー製品を購入する。要件が製品の対応範囲と近い場合、初期機能への最短経路です。ただしカスタマイズは限定的で、統合が複雑になりやすく、ロードマップはベンダーに依存します。ワークフローが差別化要因でない場合に適しています。
• 自社で構築する。柔軟性と所有権は最大ですが、スタックのあらゆる層をチームが設計・構築・保守するため、コスト、納期リスク、運用負荷が増大します。中核の差別化要因に適しています。
• アプリケーションエンジンを活用する。ドメインに合わせた再利用可能なプリミティブを備えた本番品質の共有ランタイムで、自社開発の統制とプラットフォームのレバレッジを兼ね備えます。中核業務を支え、差別化を推進する用途に適しています。

これらは3forge Application Engineの主要な機能領域を表します。Live Dataはリアルタイムデータと蓄積データへのガバナンスされたアクセスとイベント駆動処理を指します。Live User Interfaceはダッシュボード、フォーム、ピボット、ワークフローのフロントエンド層を指します。Live Workbenchはアプリケーションの構築、テスト、診断、運用を行うブラウザベースの環境を指します。Live Scriptingは、計算、変換、コールバック、再利用可能なアプリケーション動作を記述するランタイムネイティブの業務ロジック層を指します。

LivePivots™とLive Promptingは、同じモデルをリアルタイムピボット分析と自然言語による操作へと拡張します。

いいえ。ダッシュボードはプラットフォームの目に見える出力のひとつですが、3forgeはアプリケーションランタイムとして理解するのが適切です。データ統合、イベント処理、ワークフロー、レポーティング、運用ツール、ガバナンスされたデータアクセス、そしてユーザー向けの本格的なアプリケーションをサポートします。3forgeを可視化だけに矮小化すると、アーキテクチャを過小評価し、実際よりずっと狭いプラットフォームに見えてしまいます。

Centerはすでに、ユーザーインターフェースを一切持たないヘッドレスなサーバーサイドアプリケーションをファブリックの中核で動かすことができます。アプリケーション・ファブリックという名称はここに由来します。Web Serverはそのデータフローの上にリアルタイムのインターフェースを生成する機能を追加します。

企業向けプラットフォームは、技術的専門性だけで導入が成功することはまれです。フォワードデプロイドエンジニアリングのモデルでは、3forgeのプラットフォーム専門家が事業部門と技術部門のチームと直接協働し、具体的な業務ユースケースに取り組み、実装から学び、組織の実態に合わせてソリューションを適応させます。

最初のユースケースは2つの役割を果たします。動作するアプリケーションを提供すると同時に、再利用可能な接続、データモデル、統制、コンポーネント、運用手法を確立します。目的は外部エンジニアへの恒久的な依存ではなく、初期の実装を加速し、社内チームへ知識を移転することです。

3forgeは企業のデータとアプリケーションの課題を、4つの別々のプログラムではなく、相互に関連する4つの課題として捉えています。

• リアルタイムデータと履歴データを橋渡しする。単一のリポジトリへの統合を強いることなく、分散したライブデータと蓄積データを一貫した運用モデルで利用可能にします。
• 本番品質のエージェント型アプリケーションを構築する。繰り返し必要となる技術機能をプラットフォーム側で提供し、AI支援で作られた試作をガバナンスされ運用可能なソフトウェアへと引き上げます。
• 全社規模でデータをガバナンスする。権限、リネージ、ポリシー適用、監査を、データが要求され、変換され、配信され、実行に使われる経路全体へ拡張します。人、サービス、エージェントのいずれにも適用されます。
• データ、ロジック、実行を接続する。観測、判断、行動の間の脆い受け渡しを減らし、シグナルの検知、評価、承認、実行を一つの運用フローの中で行えるようにします。

AmiCoreは3forgeアーキテクチャの中心にあるガバナンスされたランタイムコンテナです。3forgeコンポーネントが構成、実行、監視、統制される共通環境を提供し、データアクセス、業務ロジック、ユーザー操作、外部インターフェースにまたがる横断的な制御を適用します。

各AmiCoreインスタンスは3つの領域のサービスを備えています。ランタイム制御（デプロイ、構成、リソース管理、オーケストレーション、ヘルス監視、計測）、セキュリティとガバナンス（ログインと認証、ロールベースアクセス、監査、ファイルシステム管理、ポート管理、プラグイン制御）、アクセスと相互運用性（ネイティブなデータアクセスに加えREST、MCP、JDBCインターフェース）です。

いいえ。AmiCoreはDockerコンテナ、仮想マシン、KubernetesのPodの代替ではありません。AmiCoreはJava仮想マシンの内部で動作し、そのJVM自体はOS上で直接動作することも、Dockerイメージにパッケージ化されKubernetesなどの基盤で管理されることもあります。

この区別は重要です。外側のインフラはプロセスがどこで動き、どの物理リソースを使えるかを制御します。一方AmiCoreは、そのプロセスの内部でアプリケーション・ファブリックがどのように動作するかを制御します。これがガバナンスをデプロイの先、ランタイム自体にまで広げる仕組みです。

AmiCoreコンテナの内部で、目的別のコンポーネントが動作します。

• Relay。外部システムとの境界に位置する統合・転送レイヤー。
• Center。データとイベント処理の中核コンポーネントで、リアルタイムデータベース、ヒストリカルデータベース、複合イベント処理エンジンを保持します。
• Gateway。分散したCenter群を単一の論理インターフェースとして提示するガバナンスされた配信レイヤー。
• Web Server。ユーザー操作、ワークフロー、レポーティング、実行のためのアプリケーションランタイム。
• Web Manager。複数のWeb Serverにまたがるアプリケーションレイアウト、ユーザープロファイル、設定の集中管理。
• Web Balancer。ユーザーセッションをWeb Serverに振り分ける、プラットフォームを理解したエントリーポイント。

Operations Hubはさらに、デプロイされた全インスタンスを対象とした全社規模のビューを提供します。

Relayは3forgeと外部システムの境界に位置します。ライブデータとリクエストをファブリックに取り込み、コマンドや処理済み情報を外部の宛先へ送り返します。フィードハンドラとアダプタを通じて、リアルタイムフィード、メッセージングシステム、データベース、ファイル、ローカルアプリケーションに接続します。

情報が到着すると、Relayはそれを解析、検証、変換してから1つ以上のCenterへルーティングできます。ルーティングルールにより、どのメッセージをどのCenterへ送るか、特定のストリームを複数の宛先へ複製するか、条件を満たさないメッセージを破棄するかを決定できます。Relayはまた、中断時にデータ損失を許容できないワークロードのために、保証メッセージングとストアアンドフォワードを提供します。

Centerはアプリケーション・ファブリックにおけるデータとイベント処理の中核コンポーネントです。Relayなどのコンポーネントから届くライブ情報を取り込み、その現在の状態をインメモリSQLデータベースとして表現するため、アプリケーションは絶えず変化するデータを構造化されたモデルで照会できます。

リアルタイムデータベースと並んで、Centerは非常に大規模なディスク上データセット向けのヒストリカルデータベースを提供し、現在の状態と長期履歴が同じファブリックに参加します。Centerには複合イベント処理エンジンも含まれ、データベースネイティブのトリガーがソーステーブルの変化に応じて情報を集約、フィルタ、結合、エンリッチ、変換します。

Gatewayはガバナンスされた配信レイヤーです。ファブリックが複数のCenterに広がるにつれ、アプリケーション、エージェント、外部連携は単一のGatewayインターフェースに接続し、物理トポロジーを意識せずにデータを照会し、ストリームを購読し、プロシージャを呼び出せます。

Gatewayは複数の実テーブルを1つの仮想テーブルとして、複数のシャード化ストリームを1つのサブスクリプションとして、分散プロシージャを1つの呼び出し可能なサービスとして提示でき、分散ファブリック全体でのクエリのmap/reduceを可能にします。また共通のクエリ結果や状態スナップショットをキャッシュし、重複するサブスクリプションを上流で統合して配信し、再起動なしにCenterを追加・削除できます。セキュアな転送、認証との互換性、ロールベースアクセス、アクセスジャーナルがこのインターフェースに適用されます。

3forge Web Serverは、データとロジックが実際に動くアプリケーションになる場所です。インタラクティブなテーブル、フォーム、ツリー、チャート、マップ、ピボットなどのコンポーネントを通じてユーザーをリアルタイムおよび履歴情報に接続します。これらは入力を受け付け、サーバーサイドロジックを呼び出し、制御された処理を開始できます。

Web Serverはデータ処理層と同じランタイムの一部であるため、インターフェースはアプリケーションの状態と密接に結び付き、ライブ更新はブラウザへ直接届き、権限が各ユーザーの閲覧範囲と操作範囲を決定します。同じアプリケーションモデルは、ライブアプリケーションで使われているレイアウトとロジックをそのまま用いて、スケジュール実行またはイベント駆動のメールおよびPDFレポートも生成します。

Web Managerはアプリケーションレイアウト、ユーザープロファイル、設定を一元管理し、特定のセッションを処理しているWeb Serverに適切な情報を供給します。そのため、セッションが別のサーバーにルーティングされたからといってユーザーのダッシュボード設定が変わることはなく、アプリケーションチームがすべてのWebインスタンスにレイアウトファイルを手作業で同期する必要もありません。

Web Balancerはユーザーを複数のWeb Serverに振り分け、プラットフォームを理解したエントリーポイントを提供するため、各アプリケーションが独自の振り分けロジックを実装せずに済みます。両者により、各Web Serverを個別管理の環境にすることなく、Web層は数千の同時ユーザーを支えられます。

いいえ。AmiCoreは共通ランタイムを提供しますが、単一のデプロイトポロジーを強制しません。小規模なユースケースでは、複数のコンポーネントを1つのJVM内でまとめて動かせます。構成すべきプロセス数が減り、統合から処理、表示までを直線的につなげられます。

ワークロードが増えれば、機能ごとにコンポーネントを分離できます。Relayはデータソースの近くに配置し、Centerは処理能力や耐障害性のために分散し、Web Serverは同時ユーザー数に応じて追加します。事業領域、地域、セキュリティ境界、環境ごとに分けることも可能です。結果は従来型のモノリスでも無関係なマイクロサービスの集合でもなく、アプリケーション資産の要件に応じて構成できるコンポーネント化されたランタイムです。

はい。AmiCoreはプラグインモデルをサポートしており、各機関は制御された拡張ポイントを通じて承認済みの統合や特殊機能を追加できます。これにより、あらゆる拡張をコアプラットフォームの改変にすることなく、ランタイムを現場の要件に適応させられます。

したがってコンテナは2つの役割を果たします。プラットフォームに必要なネイティブサービスを提供することと、プラットフォームを拡張してよい境界を明確に定めることです。プラグイン管理自体も、ガバナンスされたコンテナサービスのひとつです。

3forgeのヒストリカルデータベース（HDB）は、数兆行を保持できる列指向の履歴テーブルを提供します。ディスクに永続化され、パーティショニングをサポートし、リアルタイムテーブルと同じSQL構文で照会できます。公表されている容量は10兆行超、1,000列超です。

HDBは、多数の列とblobフィールドのような重いデータ型、履歴パーティションに影響を与えずに列を追加・削除・変更するスキーマ管理、パーティション最適化を維持したままの行レベルのUPDATEとDELETE、イベント・バッチ・タイマー駆動によるストリーミング更新からのリアルタイムデータのアーカイブをサポートします。履歴テーブルのデータをリアルタイムテーブルに読み込み、結合を含む全範囲のクエリ最適化を利用することもできます。

ストレージタイプは列ごとに設定でき、実際のデータ利用状況に基づき、最適化の際にパーティション単位で動的に調整されます。

• FLAT。INT、FLOAT、DOUBLEなどの固定長型。
• VARSIZE。STRINGやBINARYなどの可変長型で、最大1TBまで。
• BITMAP。カーディナリティの低い文字列に効率的。
• PARTITION。行を独立したパーティションに整理。

パーティション列は変更不可であるため、テーブルスキーマの設計には事前の入念な計画が必要です。HDBは古いパーティションを新しいスキーマにシームレスに対応付け、履歴の整合性を保ちます。

Centerはデータベースネイティブのトリガーを提供し、データ更新に応じて業務ロジックをその場で実行します。コンフレーションと組み合わせることで、必要な分だけの処理に抑えられます。以下のトリガーが標準で利用できます。

• Aggregation。集約テーブルの作成と更新。
• Projection。フィルタ済みテーブルの生成。
• Join。結合テーブルの作成。
• Decorate。別テーブルのデータによるエンリッチ。
• Relay。3forge Relay経由でのメッセージ送信。
• AmiScript。挿入、更新、削除のたびにカスタムスクリプトを実行。

Centerは、転送速度と技術的制約を両立させるためにいくつかの手法を用います。

• デルタベース処理。更新のたびにデータセット全体を再処理・再送信するのではなく、変更分のみを扱います。
• コンフレーション。階層アーキテクチャ間で複製する際、すべての更新を送るか、合意された間隔で最新のものだけを送るかを設定でき、中間値を破棄して下流の負荷を軽減します。
• サマリー化。平均、合計、件数、最小、最大などの定期的およびデルタベースの集計指標がデータ量を圧縮し、時系列分析を支えます。
• デコレーション。イベント駆動トリガーが、テーブルレベルの変更に応じてデータをエンリッチ、検証、伝播します。

3forgeはWindows、Linux、Appleプラットフォーム、Androidにわたる主要な企業環境をサポートします。ブラウザはChrome、Firefox、Edge、Safariに対応します。DockerとKubernetes、各種クラウドプロバイダ、一般的なソース管理システム、金融デスクで使われるデスクトップコンテナ環境にも対応しています。接続面では、幅広いデータベース、API、メッセージングシステム、フィードハンドラをサポートします。

3forge ODBCドライバとExcel RTDサーバーは、現時点では64ビットWindowsクライアント向けに設計されています。

3forgeは35を超えるデータベースアダプタと15のフィードアダプタを標準で備えており、ほぼあらゆるソースからリアルタイムデータと蓄積データを取り込み、データ利用者に対する単一のアクセスポイントとして提示できます。CenterとRelayはいずれもデータベースへ直接接続でき、Relayはさらにリアルタイムフィードへの接続用に設計されています。

3forgeに取り込まれたデータは、REST API、JDBC、ODBC、MCPに加え、.NET、Python、Java、WebSockets、gRPCの双方向ライブラリ経由で照会できます。

CenterとRelayの双方で利用できるデータベースアダプタには次のものが含まれます。

• リレーショナルおよびウェアハウス。Oracle、Microsoft SQL Server、MySQL、PostgreSQL、Sybase、SybaseIQ、IBM DB2、Snowflake、Greenplum、HP Vertica、Netezza、Impala、Hive、SQLite、MemSQL、SingleStore、Phoenix。
• NoSQL、キャッシュ、インメモリ。MongoDB、Couchbase、Redis、Apache Ignite、Hazelcast、HBase、Chronicle Queue。
• 分析および特殊用途。KX、Apache Spark、Hadoop、Deephaven、Symphony、R、Fred、Quandl、Bloomberg。
• ファイルとサービス。AMI DB、フラットファイル、AMI Shell、Excel、REST API。

公開されているJavaプラグインAPIを用いて独自アダプタを実装することもできます。

Relayで利用できるフィードハンドラには、Kafka、Solace、Tibco、RabbitMQ、ActiveMQ、IBM MQ、Amazon SQS、Aeron、60East AMPS、Chronicle Queue、KX Stream、gRPC、FIXが含まれます。市場データフィードにはBloomberg BPIPE、QuantHouse、OneTickが含まれます。

Relayが統合の境界でメッセージを解析、検証、変換するため、ソース固有のロジックを下流で再実装する必要がありません。

Center、Relay、Gatewayは共通のプログラマティックアクセスライブラリを提供します。REST API、JDBC、ODBC、.NET、Python、Java、WebSockets、gRPC、MCPです。

これらをランタイム内で提供することで、インターフェース間の一貫性が生まれます。RESTではなくJDBCで接続したから、あるいはユーザーではなくエージェントが操作を開始したからといって、コンシューマーが受けるガバナンスが根本的に変わるべきではありません。

はい。3forgeはBloomberg専用の統合を標準搭載しています。リアルタイム市場データ購読向けのBPIPE（2024年夏に導入）と、履歴データおよびリファレンスデータへのアクセス向けBloomberg Datasourceアダプタ（2024年秋に導入）です。いずれもライセンスされたBloombergクライアントとして標準でサポートされます。

はい。3forgeは金融アプリケーション間の相互運用のためのFDC3 2.0標準に完全準拠しており、Here（旧OpenFin）やInterop.ioを含む企業向けブラウザおよびデスクトップコンテナで日常的に導入されています。Finsembleのコールバックは2023年夏のリリースで追加されました。

これは、3forgeアプリケーションが単独で動作するのではなく、コンテキスト共有とインテント処理を通じてより広いデスクトップワークフローに参加する必要がある企業にとって重要です。

はい。3forgeはマイクロサービス接続のためのgRPCをサポートし（2025年春に追加）、データベースのデータや監視情報を外部システムから利用できるREST APIサーバーを提供します。イベント駆動の統合のためにAmiScriptから外向きのREST呼び出しを行うこともでき、Relayはローカルプロセスの起動や下流アプリケーションへのコマンド送信も可能です。

最小要件はワークロードによって異なります。開発用インスタンスは16GBのRAMを備えた最近のノートPCで快適に動作します。ティア1銀行の本番環境では、大規模なインメモリデータセットに対応するため、大容量メモリのサーバー（256GBから1TBのRAM）が一般的です。

3forgeはJVMベースのシステムであるため、ヒープのサイジング、GCチューニング、CPUコア数が主要な性能要因になります。導入時にはソリューションエンジニアリングチームがサイジングを助言します。

3つとも可能です。3forgeはオンプレミス、クラウド、ハイブリッド環境での導入をサポートするよう設計されており、既存の運用手法にも適合します。コンポーネントはワークロード、耐障害性、セキュリティ、地理的要件に応じて分散、スケール、構成できます。

そのため企業は初日から全社的なアーキテクチャに踏み切るのではなく、絞り込んだ導入から始め、アプリケーション、データソース、ユーザーが増えるにつれてファブリックを拡張できます。

はい。3forgeはDockerイメージとして配布され、Kubernetesベースのオーケストレーションに完全対応しています。水平ポッドオートスケーリング、リソース制限、3forgeヒストリカルデータベース用の永続ボリューム要求、認証情報のためのクラスタレベルのシークレット管理との統合が含まれます。

Operations HubはKubernetesやデプロイ自動化を置き換えるものではありません。それらのプロセスをガバナンスするために必要な、アプリケーション単位のインベントリと根拠を提供します。

基本的な3forge環境は数時間で立ち上げられます。多くのお客様は、データパイプラインの複雑さに応じて、数日から数週間で社内データソースと統合した実用的なプロトタイプを手にします。セキュリティ統合、SDLCワークフロー、受け入れテストを含む本番展開は、通常数週間で完了します。

3forgeのソリューションエンジニアが全工程を通じて実装を支援します。

最適な出発点は、3forgeソリューションエンジニアとの30分のデモです。お客様のユースケース、データ環境、チーム構成に合わせて内容を調整するため、適合性を素早く評価し、自社インフラ上での概念実証へ進めます。

各ページの「お問い合わせ」ボタンをご利用いただくか、お問い合わせページから直接ご連絡ください。

LivePivots™は、ピボットを表計算上の静的な作業ではなく、生きた運用機能に変える3forgeのアプローチです。ユーザーは数百の列と数百万行にわたる大規模データセットを動的なカテゴリに切り分け、フィルタと権限を適用し、リアルタイムデータと履歴データを単一のガバナンスされたインターフェースで扱えます。

重要なのは、ユーザーがピボットできることそのものではなく、大規模に、権限を伴って、ピボットが動的に更新されるライブなワークフローの中でそれを行える点です。

3forgeの保証メッセージングは、システム負荷や一時的なネットワーク状況にかかわらず、重要な更新が確実に永続化され配信されることを保証します。メッセージはWAL（ライトアヘッドログ）にジャーナリングされるため、一時的にオフラインだったものを含め、下流のCenterは再接続時に取りこぼしたデータを回復し再生できます。

保証メッセージングは重複排除を行わず、exactly-once配信と表現すべきではありません。リアルタイムのトレーディング、リスク、コンプライアンスシステムに必要な永続性と継続性を提供するものです。技術的な購買担当者は過大な主張に気付くため、この正確さは重要です。

3forge Relayは、内容、負荷、カスタムロジックに基づいてメッセージを専用の処理Centerへ振り分ける動的ルーティングルールをサポートし、すべてリアルタイムに構成できます。各Centerは自らの担当分を独立して処理し、その結果はmap-reduce操作でマージされます。

このアーキテクチャは分散システム全体での並列処理と高性能な集約を可能にします。3forgeの導入がアプリケーションを再設計せずに水平方向へ拡張できる仕組みのひとつです。

はい。3forgeはメッセージ変換機能を備えており、宣言的ルールとスクリプトを用いて、カスタムコードを書かずにメッセージを検査、変更、エンリッチ、フィルタできます。

これはFIXなどの金融プロトコルで特に有用です。異なるカウンターパーティへの対応、フォーマットの正規化、機微なフィールドのマスキング、内容に基づくルーティングなど、動的な調整が必要になる場面に対応できます。

3forgeは、簡単な設定でプライマリとウォームスタンバイのCenterデータベース間のデータ複製を提供します。スタンバイはプライマリの健全性を監視し、障害時にはすべてのデータをメモリに保持した状態で引き継げます。

複製はRelayのルーティングルールに基づく複数Center間の負荷分散にも利用でき、冗長性と拡張性の双方を高めます。マルチリージョンやグローバル複製を含む、より高度な構成にも対応します。

はい。3forgeはユーザーインターフェースと同じライブレイアウトモデルとロジックを用いて、自動化されたPDFレポートとメールレポートを生成します。別個のレポーティング製品も、重複した表示ロジックも不要です。

レポートは受信者ごとに調整でき、チャート、テーブル、ヒートマップ、ピボットグリッド、集約テーブルを含められます。内容、書式、署名、配信ルールは役割やワークフローごとに変えられるため、トレーディングのパフォーマンスレビュー、リスク分析、顧客向け資料、規制文書に適しています。

pyami-3forgeパッケージが、Pythonとアプリケーション・ファブリックの間の専用インターフェースを提供します。Pythonプロセスは、個々の基盤ソースへ独立に接続することなく、現在および履歴のデータを照会し、Centerのライブ更新を購読し、ファブリックへ情報を発行し、認可されたAMIサービスとやり取りできます。

アクセスはファブリックを介するため、ノートブックに埋め込まれた個人の認証情報ではなく、ワークロードのアイデンティティに紐付けられます。Pythonの活動は特定でき、認可されたデータに限定され、プラットフォームの運用ビューと監査ビューに含まれます。

• リアルタイムクライアント。クエリ、発行、Centerの購読、増分更新向け。
• Python DB-API 2.0。標準のPEP 249の接続とカーソルモデルに基づくアプリケーション向け。パラメータ化クエリ、バッチ処理、ストアドプロシージャに対応。
• SQLAlchemyダイアレクト。SQLAlchemy CoreおよびORM、スキーマのリフレクション、pandasとの統合向け。
• ピュアPython JDBCクライアント。ネイティブのリアルタイム拡張が不要な、軽量なクエリからDataFrameへのアクセス向け。

どのインターフェースを選んでも、基盤となる運用モデルは変わりません。Pythonは各データベース、フィード、ウェアハウスへ独立に接続するのではなく、常にAMIを通じてデータに到達します。

はい。リアルタイムクライアントは1つ以上のCenterテーブルを購読できます。購読はまず現在のスナップショットを返し、その後は行レベルの追加、更新、削除を増分イベントとして配信するため、Pythonコードはサーバーを繰り返しポーリングしたりクエリ全体を再実行したりせずに変更へ反応できます。

クエリと購読は組み合わせられます。あるプロセスがSQLで初期の履歴データや参照データを読み込み、その後Centerのライブ更新で現在の状態を維持する、といった使い方が可能です。リアルタイムクライアントは非同期SQLもサポートし、長時間のクエリをメインの処理をブロックせずに投入できます。

Pythonのワークフローは、ローカルファイル、個人の認証情報、複製データ、ソースシステムへの直接アクセスに依存したJupyterノートブックから始まることがよくあります。その成果を本番へ移すには、通常、接続性、権限、モニタリング、運用モデルを作り直す必要があります。

3forgeのPythonパッケージは、探索環境と運用環境で同じファブリックインターフェースを提供します。開発者はJupyterで始め、同じアクセスモデルをスケジュール実行スクリプト、分析パイプライン、AIワークフロー、常駐サービスでそのまま使えます。周囲のPythonコードは依然としてテストと堅牢化が必要ですが、企業データへの接続部分を置き換える必要はありません。

3forgeは2つの補完的な経路でExcelをサポートします。ODBCドライバにより、ExcelはPower Query経由で、あたかも一般的なリレーショナルデータベースであるかのようにファブリックを照会し、テーブルを参照してからデータを読み込む、あるいは変換してからブックに取り込めます。3forge RTDサーバーは、Excelネイティブのリアルタイムデータ関数を用いて、Centerが発行するフィールドに個々のセルを購読させ、Centerが増分更新を送るたびに値が自動更新されます。

これによりユーザーは役割に適したアプリケーションと作業方法を保ちながら、データアクセスは管理された単一のAMI環境に接続され続けます。

各数式はAMIクラスタと、AMIテーブル内のオブジェクトの特定フィールドを指定します。

• =RTD("AmiRtd.Server", , "<cluster>", "<table>.<object_id>.<field>")
• =RTD("AmiRtd.Server",,"N1","Trades.AAPL.price")
• =RTD("AmiRtd.Server",,"N1","Trades.AAPL.volume")

最初の該当更新が届くまでセルは#N/Aを表示し、その後は最新値を示してCenterの発行に合わせて更新され続けます。同じテーブルを見ているセルは参照カウント方式のCenter購読を共有し、同じトピックを要求するセルは1つのキャッシュ値を共有するため、多数のライブ数式を含むブックでも上流の購読が重複しません。

ODBCとRTDは異なる利用パターンに対応しており、多くのExcel導入では両方が使われます。

• ODBCはリクエスト・レスポンス型で、結果セットに適しています。テーブルの参照、SQLクエリの実行、履歴または現在のレコードの取得、必要に応じた更新など。例：ポジション、参照データ、履歴。
• RTDは購読型で、継続的に更新される少数のライブ値に適しています。例：価格、ステータス、リミット。

ブックはODBCで大きめの作業テーブルを取得し、RTDで特定の価格や運用指標を継続更新し、Excelの数式で両者を組み合わせる、といった使い方ができます。

3forge ODBCドライバはAMIテーブルを標準のWindows ODBCインターフェースで提示するため、Excel、Tableau、Power BI、LibreOffice Base、pyodbc経由のPython、PowerShell、CまたはC++のODBC APIで書かれたアプリケーションが、一般的なリレーショナルデータベースへ接続するのと同じようにファブリックを照会できます。

これにより、分析・レポーティング製品ごとに個別のコネクタを作る代わりに、管理された単一のクエリ面を公開できます。ドライバは主にクエリと分析のためのインターフェースであり、autocommitで動作し、commitやrollbackによるトランザクション境界はサポートしません。

ODBC接続はSSL/TLSを利用でき、セキュアなAMI JDBCリスナーを用いる場合は相互TLSが必須です。クライアントはサーバーに証明書を提示し、サーバー側も公開鍵でピン留めできます。接続には順序付きのフェイルオーバー先を含められ、プライマリのAMIサーバーが利用できない場合はクライアントライブラリが制御されたバックオフで再試行します。RTDサーバーも同じ相互TLSモデルを使用します。

両インターフェースは現時点で64ビットWindowsクライアント向けです。ODBCドライバはWindowsのマシン単位インストーラで配布され、Windows ODBCドライバマネージャに登録するため管理者権限が必要です。Excel RTDサーバーはユーザー単位のインストーラで配布され、現在のユーザー向けにCOMコンポーネントを登録するため管理者権限は不要です。

AmiScriptはアプリケーション・ファブリックのネイティブなプログラミング言語です。データ、ロジック、ワークフロー、表示を横断して扱う単一のモデルを提供し、Java、Python、SQL、文字列テンプレートの馴染みある概念を組み合わせつつ、金融システム向けの関数とデータ型を追加しています。

言語がファブリック全体で動作するため、レイヤー間を移動してもロジックを書き直す必要がありません。計算はデータモデルで始まり、ワークフローで再利用され、ユーザーインターフェースやレポートに直接現れます。同じロジックを外部アプリケーションやAIエージェントが認可されたインターフェース経由で呼び出すこともできます。

AmiScriptは1,500を超える組み込み関数をドメイン別のライブラリとして備えており、共通のプリミティブを再実装せずに高度なワークフローを組み立てられます。カテゴリには次のものが含まれます。

• 数学、三角関数、丸め、ビット演算、エンコーディング
• 日付と時刻、ナノ秒タイムスタンプを含む時刻管理
• 統計、平均、パーセンタイル、クラスタリング、リサンプリング
• ベータや変化率などの金融指標
• 文字列操作、書式設定、パース（JSONやXLSXを含む）、連結
• 暗号署名、色処理、乱数、URL処理
• ロギングやセッション制御などの運用関数

AmiScriptはマップ、リスト、入れ子構造の定義にPython風の構文を採用しており、市場データのスナップショット、価格ラダー、リスクバケット、構成オブジェクトといった複雑な金融オブジェクトを、冗長なクラス定義や外部スキーマなしにインラインで表現できます。JSONもApplication Engine全体で十分にサポートされています。

これらの構造は言語の第一級市民であるため、変換なしに計算、ビジュアルコンポーネント、永続化レイヤーへ直接渡せます。同じ構造がプライシングロジックを動かし、テーブルを埋め、チャートを駆動できるため、データモデリングと実行の間のグルーコードがなくなります。

はい。AmiScriptは、業務ロジックを決定論的にカプセル化する強い型付けでオーバーロード可能な関数定義をサポートします。関数は一度定義すればスクリプト、クエリ、モデル、ビジュアルで再利用でき、重要な金融計算がシステム全体で一貫します。

想定元本、エクスポージャー、証拠金、PnLがリスク、トレーディング、レポーティング、コンプライアンスの各ワークフローで同一に計算されなければならない金融では、これが重要です。関数はガバナンスされたランタイム内で実行されるため、observableで監査可能であり、システムの他の部分と同じ統制下に置かれます。

AmiScriptはAmiSQLと密に統合されており、開発者は権限、監査、リネージの枠組みの中に留まりながら、馴染みのあるSQL構文で名前付きデータソースに対するパラメータ化クエリを実行できます。${USERACCOUNT}のようなプレースホルダは実行時に解決されるため、識別子をハードコードせずに同じスクリプトが異なるユーザーやセッションへ自動的に適応します。

データアクセスがスクリプト層に直接組み込まれているため、データを照会することと操作することの間に人為的な分断がありません。結果はすぐに後続の計算、可視化、永続化に再利用でき、計算値は組み込みのテンプレート機能でテーブル、チャート、ツールチップ、ダッシュボード、レポートに埋め込めます。

SQLに慣れていると役立ちますが、すべての開発作業に必須ではありません。3forgeはデータモデルにSQLライクなクエリ言語を用いるため、SQLに習熟した開発者はすぐに馴染めます。Data Modelerはクエリ構築の多くを抽象化するビジュアルワークスペースを提供し、クエリ言語の経験が少ないチームの敷居を下げます。

複合イベント処理、結合、ストリーミング集計については、SQLへの理解が深いほど開発速度と成果物の品質が向上します。

はい。3forgeは専用プラグインを通じてVisual Studio Codeなど一般的なIDEに統合できるため、開発者はチームがすでに使っているソースコード、リポジトリ、テストツール、レビュープロセスと並べてファブリックのプロジェクトを扱えます。

IDEとファブリック間の通信はModel Context Protocolに支えられています。このインターフェースを通じて開発環境はランタイムが公開する機能を調べ、スキーマ、プロシージャ、ランタイムオブジェクトなどのコンテキストを取得し、許可された開発機能を呼び出せます。次の変更が手作業で書かれるかAIアシスタントに提案されるかにかかわらず、同じガバナンスされたツールが利用できます。

いいえ。3forgeのレイアウトはブラウザウィンドウ内で構築され実行され、エンジニアはコントロールキー1つでユーザーモードとエディタモードを切り替えます。実行ファイルのコンパイル、バックエンドへの反映、フロントエンドの再読み込み、ソフトウェアのデプロイは不要です。エンジニアは開発しているそのウィンドウで、変更の効果をすぐに確認できます。

探索的な変更は明示的に保存するまで一時的なままにでき、保存済みレイアウトを即座に変えることなく素早い反復が可能です。

• ネストパネル。ナビゲーションコンポーネント、水平・垂直タブ、複数階層のネストに対応。
• スナップ機能付きディバイダによるレイアウトの精密な制御と、コンテキストに応じたビューやポップアップのためのトランジェントパネル。
• ダイナミックHTMLによるカスタム表示と豊かなインタラクティビティ。
• 高度なチャート。バー、散布図、線、面、マップ、トレンド、ヒートマップ、キャンバス、放射状チャート、3Dチャートを組み合わせ、リアルタイムに更新。
• 集約テーブル。列グループ、高度なフィルタ、セル単位の編集に対応。
• リアルタイムピボットテーブル。数百列・数百万行に対応。リアルタイムツリーテーブルは階層と数式をカスタマイズ可能。
• 動的なスタイルとテーマ。ライト、ダーク、高コントラスト、ブランドカラーのパレットをその場で切り替え。

一般的な可視化には、グループ化棒グラフ、複数線グラフ、転置テーブル、ピボットテーブル、CRUDテーブル、ブレッドクラムフィルタ、ヒートマップ、3Dチャート、面グラフ、サンキー図があります。

3forgeは、複雑なダッシュボードのキーボード操作、テーブルやツリーのキーボードによる列フィルタリング、パネル移動とフォーカス制御のスクリプト対応を通じてADAへの準拠を支援します。レイアウトは高コントラストテーマにも対応します。

レイアウトは完全にレスポンシブで、モバイル端末でも動作します。3forgeは転送量を抑えるよう高度に最適化されているため、大規模データセットをモバイルブラウザへリアルタイムに届けられ、経営層はブラウザベースのモバイルUIから主要指標の確認、リスクエクスポージャーの把握、重要なアラートの受信ができます。

はい。開発者はAmiScriptとプラットフォームのフォームフレームワークを用いて完全にカスタムなコンポーネントを作成できます。外部パネルのサポートを通じて、独自のWebベースコンポーネントを埋め込むことも可能です。カスタムチャートや特殊なトレーディングUI要素など固有の可視化要件があるチームのために、サードパーティライブラリや自社コンポーネントを統合するためのフックが用意されています。

はい。3forgeにはソース管理統合が組み込まれており（2020年冬に導入）、レイアウト、データモデル、スクリプトのバージョン管理が可能です。Gitベースのワークフローと統合し、ブランチ、マージ、コードレビューを含む標準的なSDLCの実践をサポートします。

プラットフォームはSDLCフックもサポートしており、3forgeの環境を離れることなく、開発からUAT、本番までの昇格ポリシーを適用できます。

はい。同一レイアウトでの同時開発は2025年春のリリースからサポートされています。組み込みのMerge Toolにより、複数の開発者が独立して変更を加え、昇格前に差分を調整できます。レイアウトを生のXMLや構成テキストとして扱うのではなく、AMIレイアウトの階層構造を理解した上で処理します。

開発は、データモデリング、クエリ分析、AmiScript開発、レイアウト構築、デバッグ、運用状態の確認を統合したブラウザベースの環境で行われます。チームはデータモデルを定義し、ダッシュボードとワークフローを構築し、業務ロジックを記述し、イベント駆動処理を作成し、ソース管理下の変更を1つの環境で管理します。

ランタイムと開発環境が同一のシステムであるため、コンパイル、公開、再デプロイのサイクルなしに、変更を記述し、実行し、実際の条件下で観察できます。目的は単にUIを速く作ることではなく、エンドツーエンドのアプリケーション提供を速めることです。

データモデルは一般に、ユーザーごとのクエリ駆動のデータ整形に適しています。リアルタイムテーブルは一般に、多数のユーザーにまたがる共有のデルタ駆動状態に適しています。この区別はスケールとアーキテクチャの観点で重要です。リアルタイムテーブルが適切な、全体で共有されるホットな状態に対して、ユーザーごとのモデルを使うことは避けるべきです。

WorkbenchはAmiCoreのガバナンスされたランタイムに含まれるブラウザベースのIDEです。ユーザーの権限の範囲内で、現在の環境にあるデータ、コンポーネント、ロジックへ即座にアクセスできるため、開発者は環境を別途再現することなく、データを探索し、クエリを実行し、アプリケーションオブジェクトを調べ、ロジックをテストし、動作をデバッグできます。

Workbenchはランタイムの内部で動作するため、外部エディタだけでは再現しにくい情報を提示できます。ライブな状態、実行の流れ、値、そしてプロシージャが周囲のアプリケーションとどう相互作用するかです。初期開発、運用調査、業務担当者との協働で特に有用です。

いいえ。Workbenchはソース管理も、組織のソフトウェア開発ライフサイクルも置き換えません。プラットフォームへの即時アクセスを提供する一方、外部IDEはリポジトリ、テストツール、レビューワークフローと並んで、より広いエンジニアリングプロセスを支えます。

Workbenchは継続的インテグレーションのワークフロー、最新ブラウザ全体での一貫性、デバイスに依存しないレスポンシブな成果物もサポートします。

はい。Workbenchではヘルプは別の場所ではなく、開発の流れそのものに組み込まれています。開発者がコマンド、関数、式を入力するにつれ、利用可能なパラメータ、期待される型、戻り値、使用パターンがその場に表示されます。

ヘルプ機能はロジックを実行するのと同じ基盤モデルによって駆動されるため、その環境の正確な構文、機能、制約をリアルタイムに反映します。

Data Modelerは、データがどのようにアクセスされ、変換され、組み合わされ、アプリケーションへ届けられるかを定義するビジュアルワークスペースです。開発者はデータベース、ファイル、リアルタイムフィードなどのソースを接続し、SQLとAmiScriptでフィルタ、結合、計算、集約、ブレンドを行い、再利用可能なデータモデルに仕上げます。

データソース、データモデル、アプリケーションパネル、リレーションシップ間の依存関係も表示します。開発者はクエリをテストし、結果とエラーを確認し、アプリケーション変数やユーザー選択でモデルをパラメータ化し、起動時処理、自動更新、コンフレーション、タイムアウト、結果件数上限などの実行挙動を設定できます。従来のER設計ツールと異なり、Data Modelerはアプリケーションの運用上のデータ処理層を表します。

はい。3forgeのインラインデバッガはWorkbench内で動作します。AmiScriptの任意の行にブレークポイントを設定でき、スクリプトを記述しているのと同じ画面からデバッグモードで起動できます。実行がブレークポイントに達すると、Debuggerパネルが現在の変数とコールスタックを表示し、後続のブレークポイントまで実行を継続できます。

デバッガは開発環境に統合されているため、AmiScriptのコールバックを接続中の3forgeインスタンスに対して直接、実データまたはテストデータで実行・検証できます。レイアウトの読み込み時、データモデルの実行時、ユーザーがフィールドやテーブルを操作したとき、あるいは基盤の状態が変化したときにロジックが呼ばれるイベント駆動アプリケーションで特に有用です。

DB ShellはCenterデータベースを照会、構成、管理するための対話型コマンドインターフェースで、MySQLに近い馴染みのある構文でAMI SQLを実行します。データの取得と変更、スキーマの作成と変更、テーブル、インデックス、プロシージャ、トリガー、タイマー、派生ビュー、カスタムオブジェクトなどCenterオブジェクトの管理が可能です。

調査用のツールも備えています。SHOWはCenterで現在動作中のオブジェクトを表示し、DESCRIBEはオブジェクトを再構築するために必要なAMI SQLを返し、DIAGNOSEはテーブルのメモリ消費などの運用情報を報告します。ShellはTelnetやSSH経由でも利用でき、その場合は機能が一部制限されます。

F1コンソールは、稼働中のAMI Webインスタンスのためのコマンドライン管理・診断インターフェースです。専用コンソールポートへの認証済み接続を通じて、管理者はグラフィカルインターフェースを経由せずに、アクティブユーザー、ログイン、Webセッション、読み込まれたレイアウト、セッションの活動を確認できます。

各セッションが使用するリソース、すなわちデータモデルの実行、エラー、処理時間、生成されたテーブル、リアルタイムフィード、プロセッサ、パネル、メモリ消費を可視化します。さらに、セッションやログインの終了、ヘッドレスセッションの作成、選択したセッション内でのAmiScript実行といった運用操作もサポートします。DB ShellがCenterデータベースに焦点を当てるのに対し、F1コンソールはAMI Webランタイムに焦点を当てます。

Merge Toolは、複数の開発者がAMIレイアウトに加えた変更をレビューし、統合し、競合を解決するためのグラフィカルインターフェースです。生のXMLや構成テキストを比較するのではなく、ウィンドウ、パネル、データモデル、スクリプト、設定、可視化といったアプリケーション構造の文脈で変更を解釈します。

差分は、元の共有レイアウト、自分の変更、他者が保存した変更を比較できるナビゲート可能なツリーとして提示されます。個々の変更は採用、却下、統合でき、競合は可能な場合に解決案とともに示され、統合結果は保存前にAMI上でプレビューしテストできます。

3forgeはAIを一般的な期待感ではなく、ガバナンスされた導入という観点で捉えています。プラットフォームはリアルタイムのガバナンスされたデータアクセス、堅牢なランタイム、権限を考慮した制御、observabilityを提供するため、企業は統制を回避したり、既存の複雑さを複製したり、機微なデータへの不透明な経路を作ったりせずにAIを拡大できます。

その根底には、AIが生成したコードであっても、アイデンティティ、権限、状態、並行性、エラー、リトライ、テスト、デプロイ、モニタリング、監査可能性といった本番の責務はなくならないという考えがあります。むしろコードとサービスが増えることで責務は増大しがちです。持続可能な方法は、これら繰り返し必要となる機能をプラットフォーム側で提供し、開発者とエージェントが業務固有のロジックに集中できるようにすることです。

3forgeはModel Context Protocolを通じて、ガバナンスされた開発およびデータアクセスの面を公開します。AIアシスタントを各データベース、API、メッセージストリームへ直接つなぐのではなく、機関はアプリケーション・ファブリックを通じて選択したプラットフォーム機能を公開します。

提供されるツールとユーザーのアイデンティティに応じて、認可されたアシスタントはドキュメントの取得、コンポーネントの確認、スキーマの探索、AMI SQLクエリの作成と実行、ログの参照、認可されたランタイム操作の呼び出しが可能です。MCP接続はプラットフォームの統制を迂回する並行経路を作りません。利用可能なデータ、プロシージャ、コンポーネント、操作は、ガバナンスされたランタイムが適用する認証、権限、デプロイポリシー、監査統制の対象であり続けます。

3forge MCPプラグインはClaude Code、Codex、GitHub Copilotを第一級でサポートし、GeminiとCursor向けには生成された統合を提供します。これにより開発チームは、アシスタントごとに3forge用のプロンプトや指示を個別に設計・保守することなく、慣れたコーディング環境で作業できます。

共通のインターフェースを通じて、複数のアシスタントが同じ制御された面に対して作業します。機関は環境が何を公開するかを定義し、開発者は自分の作業に合ったコーディングツールを使えます。

Claude Code向けに、プラグインは一般的な開発作業のための直接コマンドを提供します。

• 3forge-init：プロジェクトのコンテキストを確立します。
• 3forge-plan：実装計画を作成します。
• 3forge-query：データ探索とAMI SQLクエリを支援します。
• 3forge-runtime：接続中のインスタンスとやり取りします。
• 3forge-review：実装や変更案をレビューします。
• 3forge-debug：ランタイムとアプリケーションの調査を支援します。

これらのコマンドは別個のアクセス経路ではなく、同じ基盤のスキルとMCPツールへの入口です。

基本的なMCP接続は、対応アシスタントにランタイムが公開するツールと情報へのアクセスを与えます。3forge MCPプラグインはその接続の周りに開発モデルを追加し、再利用可能な3forgeスキル、専門開発エージェント、ガイド付きワークフロー、稼働中インスタンスとやり取りするための規約をAIコーディングツールに与えます。

プラグインは2種類の知識を意図的に分けて組み合わせます。安定した開発指示は、アプリケーションの計画、クエリの作成、レイアウトの変更、ランタイム問題の調査といった作業への取り組み方を記述します。環境固有の知識は接続中のインスタンスから取得され、ドキュメント、デプロイ済みコンポーネント、公開ツール、スキーマ、ログ、ランタイム機能を含みます。デプロイが変化しても、あらゆる詳細をプラグインに固定的に埋め込むことなくアシスタントが適応できます。

プラグインには、アプリケーション作成、データアクセス、ランタイム操作、構成、レビュー、デバッグを網羅するスキルのライブラリが含まれます。スキルは特定の作業に対する構造化された手順をアシスタントに与えます。たとえばAMI SQLクエリを組み立てる前にCenterのスキーマを確認する方法、サポートされているパネルパターンを用いてレイアウトを扱う方法、構成情報とログを使ってランタイム問題を調査する方法などです。

大きな要求に対しては、専門開発エージェントが作業を分担します。あるエージェントは稼働環境を調査し、別のエージェントは必要なクエリを作成し、別のエージェントはレイアウトを整理し、別のエージェントは実装案をレビューします。これらのエージェントは独立した権限を持ちません。元のコーディングアシスタントに与えられたツール、ドキュメント、権限を通じて動作します。

認可されている場合は可能です。MCPを通じて、アシスタントは接続された環境で利用可能なコンポーネントを検出し、それぞれに紐付くツールを特定した上で、対象となるデータ、アプリケーション、ランタイム機能を担当するコンポーネントへ要求を送れます。グローバルツールはプラットフォーム全体のドキュメント、ログ、共通機能へのアクセスを提供し、コンポーネント固有のツールは各ランタイムコンポーネントの機能を公開します。

これはAI支援開発の重要な欠落を埋めます。ソースファイルだけから推論するモデルは、構文的にはもっともらしいが実際のデプロイと乖離したコードを生み出しかねません。アシスタントは自らのアイデンティティに公開されたツールと情報だけを受け取り、そのランタイム活動はファブリックを通じてガバナンスされ監査されます。

3forgeはAI開発のための構造化されたナレッジコーパスを維持しています。MCPで公開される関数のリファレンスドキュメントに加え、それらを組み合わせてデータを照会し、アプリケーションを構築し、レイアウトを扱い、ランタイムとやり取りするための再利用可能なパターンを含みます。コーパスは機能ドメインごとに整理され、アシスタントは実行中の作業に関連するガイダンスを受け取れます。

3forgeは実際のMCPツール面を棚卸しし、関連するドキュメントとパターンを実装に照らして監査します。公開されている関数が網羅されているか、文書化された名称、パラメータ、構文、構成キー、挙動が正確なままかを確認します。この監査はプラットフォームのソースを変更せず、自らのドキュメント変更を自動的に採用することもありません。レビュー可能な差分と監査レポートを生成し、人による承認のステップを残します。検証できない主張は推測で処理せず、手動レビューへエスカレーションされます。

3forge MCPプラグインは、ドキュメント参照、検証、適用というモデルに従います。プラットフォームへの変更を提案する前に、アシスタントは関連する3forgeのドキュメントと開発パターンを参照し、検証ツールが利用できる場合は適用を試みる前に提案内容を検証します。

これによってAIが生成したすべての変更が自動的に正しくなるわけではありません。前提を明らかにし、構文を検証し、不正な変更をアプリケーションに入る前に却下できる、明示的な段階を設けるということです。プラットフォームの機能が許す場合、生成された成果物は開発者が明示的に適用またはコミットするまで一時的な状態に留められるため、レイアウトやパネルを試行錯誤しても、途中の操作がすべて恒久的な変更になることはありません。

Ask AIは3forge Web環境に直接組み込まれたチャットボットで、ユーザーは業務画面と別のAIツールを行き来することなく、自然言語でデータとアプリケーションを扱えます。会話インターフェースがアプリケーション内にあるため、ユーザーがすでに持っているコンテキストを利用できます。

その実効的な権限は、ユーザーのアイデンティティと権限、アシスタントに提供されたツール、機関が設定したポリシーによって決まります。基盤のデータベース、コンポーネント、アプリケーションへの無制限のアクセスは与えられません。分析用途では自然言語の要求をAMI SQLに変換でき、読み取り専用として構成することも、適切な認可のもとで選択されたデータ定義・データ変更機能を許可することもできます。

ユーザーの権限と機関の設定に応じて、チャットボットは次のことができます。

• ファブリックで利用可能なデータを使い、自然言語の質問に回答する。
• AMI SQLクエリを作成し実行する。
• 3forgeのアプリケーションやワークフローと対話的にやり取りする。
• 明示的に認可されたランタイム機能を呼び出す。
• 専門のプラットフォームエージェントへタスクを委譲する。
• 機関固有のアプリケーション向けに作成されたエージェントと指示を利用する。
• 設定されたAIモデルとプロバイダを利用する。
• ユーザーの会話を保持し、セッションをまたいで継続する。

はい。利用を許可するAIモデルとプロバイダは機関が選択します。複数のモデルが設定されている場合、ユーザーが会話の中から適切なものを選べるようにすることもできます。

管理者は、アシスタントが呼び出せるツール、会話を保持するかどうか、1つの要求で実行できるアクションや委譲ステップの回数も制御できます。これらの制限は、開かれた会話が制御不能なランタイム操作の連鎖になることを防ぎます。会話履歴はユーザーごとに保持でき、帰属を保ちながらセッションをまたいで調査を継続できます。

両者はアプリケーション・ファブリックへの補完的な経路です。MCPは外部のコーディングアシスタントやAIツールが標準インターフェースを通じてファブリックとやり取りできるようにするもので、コーディングツール、IDE、外部の自動化システムから作業する開発者やエージェントに適しています。

Ask AIは3forgeアプリケーション内で直接作業するユーザー向けの組み込み体験を提供し、データ、ワークフロー、ユーザーコンテキストがすでに存在する同じ業務環境に自然言語アクセスをもたらします。いずれもソースへの直接接続、データの複製、アプリケーションごとのAI統合の必要性を減らし、AIとのやり取りをファブリックのアイデンティティ、権限、計測、監査のモデルの中に留めます。

はい。エージェントはガバナンスされた経路でデータにアクセスし、権限を継承し、集中的にログ記録、監視、制御できます。エージェントがユーザーやアプリケーションに定められた統制を迂回する並行経路を持つべきではありません。定義されたインターフェースからランタイムに入り、権限のあるコンテキストと機能だけを受け取り、活動の帰属可能な記録を残します。

したがってガバナンスは、開発後に各アプリケーションへ付け足すものではありません。アプリケーションが動作する環境から継承されるものです。

公表されている3forge Centerの数値は次のとおりです。

• ヒストリカルデータベース容量：10兆行超
• ヒストリカルデータベースの列数：1,000列超
• リアルタイムデータベースのスループット：毎秒200万オペレーション超
• リアルタイムデータベースのレイテンシ：100マイクロ秒未満

個々の導入における実測値は、ハードウェア、スキーマ設計、同時実行性、ワークロードの性質に依存します。

市場データを基準にした2つの例があります。米国株式の取引と気配の統合フィード（SIP）は、1取引日あたり約25億メッセージを配信します。1行を1件の統合SIPメッセージとすると、10兆行はおよそ4,000取引日、約16年分に相当します。

オプションの市場データははるかに高密度で、活況時のOPRAでは1日あたり約2,000億件の気配更新が発生します。その勢いでも、10兆件の気配更新はおよそ2.5か月分のオプション気配トラフィックに相当します。

はい。金融機関にとって重要なワークロードで新技術のパフォーマンスを評価する技術調査会社STACが、3forge Webが従来型の重量級フロントエンドのリアルタイム性能を上回ることを独立に検証し確認しました。

STACのエグゼクティブディレクターであるPeter Lankford氏は次のように述べています。「We found that on average, the system responded with charts of 2 million data points in roughly 3.7 seconds. We also found that as 25,000 records representing 700 thousand database fields streamed into the system every second, the system made new records available for user queries in less than 150 milliseconds on average.」

3forgeは24時間365日のグローバル運用で数千人の同時ユーザーを抱える機関に導入されています。Web BalancerとWeb Managerがネイティブコンポーネントとしてウェブ層の水平スケーリングを担うため、サードパーティのインフラに依存しません。実際の収容人数は、ダッシュボードの複雑さとセッションあたりのアクティブな購読数によって決まります。

市場データの受信からUI更新までのエンドツーエンドのレイテンシは、標準的な構成では一般に数ミリ秒台です。オプションのプライシングや執行監視のようなレイテンシに敏感なワークフローでは、インメモリアーキテクチャが外部データベースへの往復のオーバーヘッドを排除します。多くの競合ソリューションが遅延を生むのはまさにこの部分です。

3forgeは精緻なレイテンシ測定とブローカー単位の分析のために、ナノ秒およびマイクロ秒精度のタイムスタンプもサポートします。

データ量が増えてもブラウザの応答性を保つために、いくつかの仕組みがあります。

• サーバーサイド処理。計算はCenterへオフロードされ、Web Serverは集計値など関連する結果のみを返すため、帯域とフロントエンドの応答性が保たれます。
• 可視部分のみの転送。チャート、テーブル、ピボットの基となるデータセットはWeb層に保持され、画面上で見えている場合にのみブラウザへ転送されます。
• リアルタイム伝播。UI上のある要素が変化すると、3forgeはその変化を関連するデータセットやビューへ知的に伝播させ、複雑さが増してもUIの整合性を保ちます。

3forgeのヒストリカルデータベースは、非常に大きな時系列データとイベントデータをディスクに保存し、リアルタイムテーブルと同じSQL構文で高速にオンデマンド照会できるよう設計されています。Centerと直接統合されているため、履歴データとリアルタイムデータを単一のデータモデル内でまとめて照会でき、別途データウェアハウス層を設ける必要がありません。

列指向のレイアウト、列ごとのストレージ戦略、パーティショニング、ソートインデックスにより、非常に大きなデータ量でも費用対効果を保てます。スキーマはデータのバックフィルなしに即座に変更できます。

いいえ。ウェブ層のスケーリングはWeb Balancerがネイティブに担うため、外部のロードバランサーやサービスメッシュは不要です。インフラ方針で必要であれば併用も可能です。データ層のスケーリングは複製構成のCenterノードを追加することで実現し、中核機能について外部のキャッシュやメッセージング層に依存しません。

Gatewayが他のGatewayを呼び出す構成も可能で、データセンターやリージョンをまたいで効率的に拡張できます。またGatewayを再起動せずにCenterを追加・削除できます。

アーキテクチャは運用モデルを変えずに複数の方向へ拡張できます。新しいソースの近くにRelayを増やし、処理・保存・地域的な耐障害性のためにCenterを増やし、統合的なアクセスのためにGatewayを追加し、利用者の増加に応じてWeb Serverを追加します。

導入構成は、インスタンスにリソースを増やして垂直に、インスタンスを追加して水平に、あるいは性能と可用性の要件が異なるコンポーネントを分離して機能的にスケールできます。ファブリックは1つの物理構成で定義されるのではなく、構成が変わっても保たれる一貫した役割、プロトコル、統制によって定義されます。

はい。設計に応じて、hot-hotまたはhot-warmのCenter複製、複数のWebコンポーネント、ウェブ負荷分散、分散したユーザープロファイル管理といった耐障害性のパターンを採用できます。メッセージングの継続性については、ジャーナリングと再生をサポートし、下流のコンポーネントが再接続後に取りこぼしたデータを回復できます。

復旧は一律のチェック項目としてではなく、具体的な導入アーキテクチャの文脈で検討すべきです。

高可用性構成では、Centerの状態はウォームスタンバイノードへ継続的に複製されます。スタンバイはプライマリの健全性を監視し、障害時にはすべてのデータをメモリに保持したまま引き継げます。フィードハンドラは再接続して購読を再開するため、インメモリのデータセットは最新の状態を保てます。

障害をまたいだ完全な履歴保持が必要な用途では、3forgeのヒストリカルデータベースがノード再起動後も残る永続的なディスク上ストレージを提供します。

はい。複製アーキテクチャはマルチリージョンおよびグローバルな構成をサポートします。ニューヨーク、ロンドン、香港などの金融拠点をまたいで事業を行い、各リージョンでローカルな性能とリージョン間の整合性の双方が必要な機関で広く利用されています。Center向けの高度な複製機能は2022年夏のリリースで導入されました。

PythonおよびODBCのクライアントも分散環境をサポートし、順序付きのフェイルオーバー先と、アクティブな接続先が利用できなくなった際の自動再接続を備えています。

3forgeはHashiCorp VaultやCyberArkなどの企業向け鍵管理システムと統合し、機微な認証情報をサーバー上に保存せずにリアルタイムで鍵へアクセスできます。パスワードや接続文字列は実行時に動的に取得され、3forgeの環境内でディスクに永続化されることはありません。この機能は2021年冬のリリースで導入されました。

ライセンスモデルは、一時的な接続の問題が本番障害に発展しないよう設計されています。起動時にインスタンスがOperations Hubへ到達できない場合、設定可能な猶予期間のあいだ、直近のライセンスを使い続けられます。

ライセンスサーバーのない環境向けには、ローカルホストに封緘され起動のたびに検証されるスタンドアロンライセンスを3forgeが発行できます。この処理にサーバーもネットワークも必要ありません。

認証は業界標準のシングルサインオンプロトコルで拡張でき、SAML 2.0とOAuth 2.0を完全にサポートするため、Okta、Azure AD、Ping Identityなどのアイデンティティプロバイダと統合できます。

認証はAmiCoreコンテナのレベルで提供されるため、個々のアプリケーションモジュールに限定されず、デプロイ全体に適用されます。RESTリクエスト、JDBCクエリ、ユーザー操作、MCP呼び出しは異なるインターフェースから入ってきますが、同一のアイデンティティ、権限、監査モデルの対象となります。

はい。認可はきめ細かなロールベースアクセス制御の枠組みで実施され、ポリシー定義はネストしたロール、グループ階層、データレベルの権限をサポートします。権限はフィールドやセルの単位まで適用でき、ユーザーやチーム間でのデータ可視性を厳格に分離できます。

権限によるフィルタリングはクエリ実行層で適用されるため、UI側から回避できません。異なるトレーディングデスクやリージョンが共有データに対して分離されたビューを持つ必要があるマルチデスク環境では不可欠です。

はい。保存中か転送中かを問わず、すべてのデータはエンドツーエンドの暗号化で保護されます。転送にはTLS、保存にはAESを使用し、セキュアな複製プロトコルにより分散環境全体で一貫性と完全性を確保します。

3forgeと企業のKMSとの統合により、暗号鍵は外部で管理され、お客様のセキュリティポリシーに従ってローテーションされます。

はい。3forgeはAICPAによるSOC 2 Type 2認証を取得しています。

3forgeはまた、ティア1金融機関のベンダーデューデリジェンスの一環としてセキュリティ評価を受けています。アーキテクチャ図、ペネトレーションテストの要約、データ取り扱いポリシーを含むセキュリティ文書一式は、調達プロセスにおいてNDAのもとでお客様に提供されます。

一部の金融機関や政府機関は、実行可能なコード、データへのアクセス方法、動作の監査可能性について厳格な保証を求めるCISOレベルのポリシーを運用しています。ロックダウンモードはそれらを強制するシステムレベルの構成です。

• ファイルシステム。あらかじめ定義され保護されたパス内でのみ読み取り、作成、変更が可能。
• ポートとソケット。任意のソケットやネットワークアクセスを禁止。
• Javaライブラリ。カスタムJavaパッケージの読み込みを禁止。
• UIレイアウト。JavaScriptの注入を禁止し、エンジンが管理するコードのみを実行。

3forge内で作成されたコードだけが実行されることを保証することで、ロックダウンモードはすべてのファイル、ポート、ライブラリ、外部データとのやり取りに対して完全な監査カバレッジと権限の適用を実現します。

はい。3forgeはユーザー操作、認証イベント、データアクセスを設定可能な粒度で記録し、Gatewayはすべてのやり取りのアクセスジャーナルを保持します。監査ログは自社のSIEM、ログ集約基盤、コンプライアンス用アーカイブへエクスポートできます。

これは社内監査の要件に加え、MiFID II、FINRAなどの枠組みにおける規制上の義務にも対応します。

インフラのガバナンスは通常、外側から内側へ働きます。どのソフトウェアをデプロイしてよいか、どこで実行してよいか、どのリソースを消費してよいか、どのネットワークゾーンに入ってよいかを決めます。AmiCoreはアプリケーションランタイムの内側からもガバナンスを加えます。

ユーザーとサービスを認証し、ロールに紐付け、そのロールをアクセス可能なデータ、プロシージャ、アプリケーション機能に適用します。さらにファイルシステムへのアクセス、ネットワークポート、プラグイン、コンポーネント構成、リソース割り当て、モニタリングといったランタイムの関心事も管理します。AIエージェントが業務ワークフローの参加者になるとき、どのインターフェースから要求が来ても同じ統制が適用されるため、これは一層重要になります。

Operations Hubは3forge導入環境における全社規模の制御レイヤーです。クライアント側でホストされるアプリケーションで、デプロイされた3forgeアプリケーションとそのインスタンスをカタログ化し、健全性と利用状況を監視し、バージョンを特定し、ライセンスを管理し、アラートとレポートを生成します。

AmiCoreが各ランタイム内部の動作をガバナンスするのに対し、Operations Hubはそれらのランタイムがどこにデプロイされ、どのように動作し、どのバージョンを使い、ライセンス範囲内で稼働しているかを記録します。結果として得られるのは、チームがデプロイしたと思っている内容を手作業で維持したリストではなく、運用上の実証に裏付けられた生きたインベントリです。

いいえ。Operations Hubは完全にクライアント環境内で動作し、デプロイされた環境から3forgeのインフラへの直接接続を必要としません。

Operations Hubは、登録されたAmiCoreインスタンスからコンポーネント単位の粒度で健全性と利用状況の情報を収集します。ランタイムレベルでは、CPU、メモリ、スレッド数、ガベージコレクション、ユーザーログイン、アクティブセッションが含まれます。さらにAmiCoreコンテナ内部のテレメトリ、すなわち開いているポート、パーティション、開いているファイル、OSレベルのシグナルまで掘り下げられます。

期間別の移動平均、最高値、最低値は、単発の測定値に反応するのではなく、持続的な容量要件や兆候となる傾向を把握する基礎になります。アラートとスケジュール実行のPDFレポートは、製品領域やリージョンを担当するチームへ振り分けられます。

この監視モデルは、欠落と不整合も探します。想定されるインスタンスからの応答が途絶えた場合、Operations Hubはそのサービスが停止している、切断されている、あるいは記録どおりに稼働していない可能性を示せます。未登録のインスタンスや範囲外の要求が現れた場合、その差異はインベントリ、ライセンス、監査の問題になる前に表面化します。

これはインフラ監視を置き換えるのではなく補完します。従来のツールはホストやJVMがメモリを消費していることを示します。Operations Hubは3forgeの文脈を加えます。どのアプリケーションが動作し、どのコンポーネントを含み、どこにデプロイされ、どのバージョンを使い、そのセッションとライセンスがどう振る舞っているかです。

Operations Hubは、すべてのプロセスを無関係なレコードとして扱うのではなく、アプリケーションを中心とした構造化されたインベントリを構築します。アプリケーションは事業領域、説明、許可リージョンとともに一度登録され、稼働中のインスタンスは環境、リージョン、ホスト、ステータス、JVM、インストール済みコンポーネントの情報とともにそのレコードに集約されます。

これにより環境全体でバージョンの差異が可視化され、技術チームはどのインスタンスがサポート対象リリースへ移行し、どれが旧バージョンに留まっているかを特定できます。アップグレード計画は、リリースのたびに調査をやり直す作業ではなく、影響を受けるアプリケーションとインスタンスの明確なリストになります。

Operations Hubはライセンスの発行とインベントリを一元化します。3forgeが提供する親キーにより、機関は子ライセンスを社内で生成・管理できます。ライセンスは個々のホストに恒久的に固定されるのではなく、登録されたアプリケーション、製品領域、リージョンに紐付けられます。

承認済みのインスタンスが起動すると、ライセンスサーバーへ自身を申告し、マシン単位のライセンスを自動的に受け取ります。各付与は記録されます。ライセンスサーバーが呼び出されるのはこのときだけで、以降の起動では鍵ペアがローカルで検証され、インスタンスは完全にオフラインで単独起動します。利用状況はアプリケーション単位で日次、週次、月次に確認できます。

はい。3forgeはローカルホストに封緘され、アプリケーション、許可ホスト、有効期限を明示したスタンドアロンライセンスを発行でき、起動のたびにローカルで検証されます。サーバーもネットワークも必要ありません。

ライセンスサーバーを使う場合、ローカルの信頼された管理者が3forgeクライアントポータル上でシークレットキーを作成し、特定のホスト名、アプリケーション、有効期限に限定して、ローカルマシンライセンスを発行する権限を委譲します。付与そのものには意味がなく、元の3forge文書と紐付いている場合にのみ有効です。

Operations Hubがファブリック全体の上位レベルのテレメトリを提供する一方、各コンポーネントはコード実行、データアクセス、レイテンシ、スループットにわたる詳細な調査のために十分に計測されています。

• フレームスレッド分析。実行時間が関数間でどう配分されているかを可視化するパフォーマンスプロファイリングで、遅いコードパスを正確に特定します。
• 高度なログビューア。専用の可視化がアプリケーションログを解析し、キューで処理されたメッセージに基づいてJVMのメモリ割り当て、消費、余裕を示し、分析を導く所見を自動生成します。
• エンドツーエンドのレイテンシ分析。イベントのタイムスタンプから処理段階、個々のパッケージまでレイテンシを測定・相関付けし、傾向、外れ値、性能劣化を示すライブレイアウトとして提示します。
• セッション単位・アプリケーション単位のリソース帰属。Workbenchは単一JVM内のリソース使用を個々のユーザーとアプリケーションに帰属させ、偏りの検出、重要ユーザーの実行時間の保護、負荷を生んでいるアプリケーションの特定を可能にします。

3forgeは季節ごとのサイクルに沿って、年に約3回から4回、名前付きのメジャーリリースを公開します。各リリースには新機能、性能改善、不具合修正が含まれます。重大な問題に対応するパッチリリースは、メジャーリリースの合間に必要に応じて提供されます。

3forge Enterpriseのリリースノートは、3forgeポータル（portal.3forge.com/release-notes.htm）で公開されています。各リリースの概要はリリースノートのページでもご覧いただけます。

アップグレードは既存のレイアウトや構成との後方互換性を保つよう設計されています。標準的な手順は、ステージング環境に新しい3forgeバイナリを配置し、既存のアプリケーション群を受け入れテストに通し、その後本番へ昇格させるというものです。複雑な環境については、3forgeのサポートチームがアップグレード計画を支援できます。

Operations Hubはアプリケーション単位のインベントリを提供し、どのインスタンスがどのバージョンで動作しているかを示すことで、アップグレードの対象範囲を明確にします。

はい。後方互換性の維持は3forgeの中核的なコミットメントです。既存のAmiScript、レイアウト、データモデルはバージョンアップ後も動作し続けます。動作の変更が導入される場合は、移行のガイダンスとともにリリースノートに明記されます。非推奨となった機能は通常、削除までに複数のリリースサイクルにわたってサポートされます。

3forgeのプロジェクトは、通常のソフトウェアエンジニアリングの規律で管理すべきです。レイアウトと関連する構成はソース管理に置き、デプロイは少なくとも開発から本番へ、できればその間にQAまたはUATの段階を挟んで昇格させます。

レイアウトのエクスポートだけを本番相当とみなすのではなく、構築済みのダッシュボード全体と関連構成を下位環境で検証してから昇格すべきです。

はい。Workbenchでは、AmiScriptのコールバックを接続中の3forgeインスタンスに対して直接、実データまたはテストデータで編集、実行、検証できます。変更をレイアウト定義に確定したり上位環境へ昇格させたりする前に確認できます。

トランジェントオブジェクトのサポートにより、探索的なコード変更は明示的に保存するまで保存済みレイアウトに影響しません。

Centerには、実行時間を含めてどのコードが呼び出されたかを分析するテストおよびコードカバレッジのツールに加え、カスタムロジックをステップ実行するためのブレークポイントと分かりやすいエラーコードを備えたデバッガが含まれています。

クエリプランナが実行を事前コンパイルし計画することで性能を最適化します。これは本番に近い形状のデータでデータモデルが意図どおりに動作するかを検証する際に有用です。

はい。多くのお客様は開発、UAT、本番の少なくとも3つの環境を運用しています。3forgeのソース管理統合とSDLCフックは、これらの環境間の昇格ワークフローを支えるよう設計されています。レイアウトと構成はファイルとして保存されるため、標準的なCI/CDパイプラインでバージョン管理と昇格が可能です。

テストは、コードの正しさ、データの可用性、権限、負荷時の性能、デプロイ時の挙動を対象とすべきです。データモデルとアプリケーションロジックについては、コードがコンパイルされるかだけでなく、データソースの前提、スキーマの前提、更新の挙動が正しいかも検証すべきです。

優れた3forgeのテストには、中間結果の確認、ユーザーごとの権限の検証、リリース前の下位環境での昇格テストが含まれます。

専任の3forgeエンジニアが取引週を通じて24/5のサポートを提供するため、チームは問題を迅速に解決し、開発を継続できます。標準のサポート窓口に加え、3forgeは製品ドキュメント、リリースノート、認定資格、プロジェクトのリスク低減サービスを提供します。

3forgeは技術評価、実装のガイダンス、アーキテクチャに関する相談、逼迫したプロジェクトや難航しているプロジェクトへの体系的な介入も支援できます。3forgeはソフトウェアプラットフォームであると同時に、必要に応じてデリバリーのパートナーでもあります。

AmiScriptリファレンス、コンポーネントAPI、構成ガイド、アーキテクチャ図を含む完全な技術ドキュメントはdoc.3forge.comで提供されています。ドキュメントは各リリースで更新され、検索可能なAPIリファレンス、チュートリアル、実例が含まれます。

25時間を超える体系的なチュートリアルが、基礎から高度な本番運用パターンまでチームを導きます。Mallon Associatesとの提携による正式な認定プログラムも用意されています。

3forgeはソリューションエンジニアによる体系的なオンボーディングも提供しており、AmiScript開発、データモデル設計、フィードハンドラの構成、本番デプロイのベストプラクティスを、オンサイトまたはリモートで扱います。

3forgeにはランタイム指標を可視化する監視コンソールが組み込まれています。テーブルごとのメモリ使用量、購読スループット、クエリ実行時間、JVMヒープ統計などです。列単位のメモリ分析ツールは非効率なスキーマの特定に役立ち、REST APIによりGrafanaやDatadogなどの外部observabilityプラットフォームから監視データを利用できます。

Operations Hubが全社規模のビューを加え、フレームスレッド分析、LogViewer、エンドツーエンドのレイテンシ分析といったコンポーネント単位のツールがより深い調査を支えます。複雑な本番障害については、3forgeのエンジニアリングチームがサポート窓口を通じて直接対応します。

はい。契約中のお客様は3forgeの開発者ポータルとナレッジベースを利用でき、検索可能なQ&A、よくあるパターンとレシピ、移行ガイド、コミュニティ提供の実例が含まれます。お客様のエンジニアリングチームは、3forgeのエンジニアが参加し技術的な議論に応じる共有Slackコミュニティにも参加できます。

3forgeは3つの導入モデルを提供しており、いずれにも同じ本番品質のランタイム、ツール、ガバナンスの枠組みが適用されます。

• 3forgeが構築する（ターンキー提供）。定義された要件とスケジュールに基づき、3forgeがアプリケーションの設計と提供に全面的な責任を負います。
• お客様のチームが構築する（自律構築）。公開ドキュメント、チュートリアル、サポートを活用し、社内チームが独自に設計・展開します。
• 双方が構築する（ハイブリッドモデル）。3forgeのForward Deployed Engineersがお客様のチームに参画し、社内の主体性と専門的な加速を組み合わせます。

プラットフォームがブラックボックス製品ではなくアプリケーションエンジンであるため、企業はアーキテクチャの一貫性を損なうことなく、時間の経過とともにモデルを移行できます。

ターンキーモデルでは、3forgeは範囲、マイルストーン、成果物を明確に定義した管理されたプロジェクト体制で進め、定期的なチェックポイントによりライフサイクル全体を通じて透明性と経営層による監督を確保します。

提供にはアプリケーションエンジンの全機能が活用され、データ統合、権限管理、リアルタイム処理、UI構成、運用ツールのための既製プリミティブが含まれます。最終的なシステムは、お客様のインフラ、ブランド、アイデンティティ管理、権限の枠組みに合わせて完全に構成された状態で納品されます。プロトタイプではなく、本番運用可能な導入物です。このモデルは、スピード、責任の所在の明確さ、確実な実行が最優先される場合に適しています。

ハイブリッドモデルでは、3forgeの専門家がお客様の開発ワークフローの内側で活動し、アーキテクチャの助言、本番パターン、性能最適化の知見を提供します。お客様の機関はアーキテクチャの主導権と業務ドメインの所有権を保持しながら、多様な本番環境でプラットフォームを導入してきたエンジニアの経験を活用できます。

実践的な協働により、知識は組織内に残ります。開発者は抽象的な演習ではなく実際のシステムを構築しながら、実務的な指導とベストプラクティスを得られます。このモデルは、社内の知識と長期的な自律性を保ちながら速度を最大化します。

はい。3forgeは十分に文書化されているため、社内チームが独自に設計・展開できます。プラットフォームは技術実務者向けに作られており、doc.3forge.comの包括的な公開ドキュメント、25時間を超える体系的チュートリアル、Mallon Associatesとの提携による認定プログラム、取引週を通じた24/5のエンジニアリングサポートが利用できます。

このモデルは、社内に強い開発力があり、その専門性を組織に定着させたい企業に適しています。

3forge Enterpriseは通常、既存のデータ環境の中に導入され、導入戦略は対処すべき課題から決まります。よくある起点は次のとおりです。

• 新しいアプリケーションを加速する。必要なソースをその場所のまま接続し、ガバナンスされたインターフェースで公開することで、アプリケーションチームはコネクタ、キャッシュ、権限、監視ではなく業務ロジックに集中できます。
• 分析やAIを製品化する。Excel、Python、Jupyterでの分析作業を活かしつつ、それが企業データと本番プロセスに到達する方法を変えます。
• 分断されたアプリケーションをつなぐ。個々には機能しているものの、データ、状態、判断が一貫して受け渡されていないツール群の間にファブリックを提供します。
• AI駆動のアプリケーションを安全に導入する。短期間で作られたアプリケーションと企業システムの間にガバナンスされたアクセス層を置き、一時的なAPIやデータベースへの直接接続を置き換えます。
• 逼迫したプロジェクトを立て直す。すでに機能している部分を残しつつ、提供を妨げている部分の責任を3forgeが選択的に引き受けます。

はい。プロジェクトがすでに遅延または不安定な状態にあるとき、新しいアーキテクチャ基盤からやり直すことは通常さらなるリスクを生みます。3forgeは、提供を妨げている部分、たとえば信頼性の低いデータ移動、リアルタイムな状態の欠如、重複した業務ロジック、遅いインターフェース、不十分な監視、多数のシステムをまたぐワークフローなどの責任を、選択的に引き受けられます。

この安定化レイヤー自体が本番運用可能であるため、当面の介入は後で取り除くべき一時しのぎではなく、長期的なファブリックの一部になり得ます。

• 技術評価フレームワーク。戦略の複雑さ、取り扱う資産クラス、取引量、想定される成長に基づいて要件を定量化します。
• 実装チェックリスト。データ統合、リスクシステムの構成、規制報告の設定、トレーディング接続を網羅します。
• ROI算定ツール。生産性向上、運用リスクの低減、総保有コストの比較を定量化します。
• ソリューションアーキテクチャのテンプレート。マルチマネージャー、システマティック、クレジット特化など、一般的なファンド構成向けの参照アーキテクチャ。
• 顧客向けワークショップ資料、ベンダー評価スコアカード、導入ロードマップ、およびガバナンスとベストプラクティスのガイド。

3forgeは幅広い担い手に対応しますが、すべての作業に同じスキルレベルが必要なわけではありません。ダッシュボードの構築やデータ照会に集中するユーザーもいれば、スクリプト、イベント処理、データモデリング、プラグイン開発を担う上級ユーザーもいます。プラットフォームは複数の技術プロファイルに開かれている一方、一部の機能はエンジニアや技術力の高いプラットフォームチーム向けです。

3forgeはトレーディングとフロントオフィス、リスク管理、規制対応、ポートフォリオ管理、プライベートエクイティ、データ統合、データオーケストレーションで利用されています。具体的なワークフローには、統合オーダーブック、リアルタイム照合、FX取引コスト分析、トレジャリーのレポと配当ラダー、リアルタイム与信限度額モニタリング、取引異常検知、アルゴリズム監視とキルスイッチ、CAT報告、イントラデイのファクター寄与度分析、キャリードインタレストとウォーターフォールの計算、ゴールデンレコードの構築、データウェアハウスのキャッシングなどがあります。

お客様はアプリケーション・ファブリック上で500を超える金融ユースケースを構築してきました。各ワークフローを個別に購入・構築するのではなく、1つのエンジンを複数のワークフローに使うことで価値が積み上がります。詳細はユースケースをご覧ください。

はい。3forgeのソリューションエンジニアリングチームは、初期のアーキテクチャレビューとデータモデル設計から本番稼働まで、実践的な支援を提供します。明確な納期があるお客様には、開発を加速するためにエンジニアをお客様のチーム内に配置することも可能です。エンタープライズサービスでは、初期導入後も継続的な戦略面・技術面の支援を提供します。

AIはすでに将来のロードマップ項目ではなく、提供済みの機能の一部です。現在の機能には、ガバナンスされたMCPインターフェース、AIコーディングツール向けの3forge MCPプラグイン、専門開発エージェント、組み込みのAsk AIチャットボット、モデル向けドキュメントのための監査されたナレッジコーパスが含まれます。

3forgeは、本番環境で求められるアイデンティティ、権限、ワークロード統制、observability、監査可能性を維持しながら、ユーザー、開発者、サービス、エージェントが企業データとやり取りする方法を拡張し続けています。具体的なロードマップの詳細は、製品ブリーフィングプログラムを通じてお客様に共有されます。