AmiCore
ガバナンスされたコンテナ
AmiCoreは、3forgeのコンポーネントを構成、実行、監視、ガバナンスするランタイムコンテナです。各ユースケースは独自の仕組みを実装するのではなく、共通の運用モデルを継承します。
なぜコンテナなのか
ガバナンスを第一級の要素に
オペレーティングシステムやインフラプラットフォームでは、複雑なアプリケーション内部のガバナンスに対応できません。
- アプリケーションが特定のユーザーにどのデータを公開してよいか
- AIエージェントが業務プロシージャをどう呼び出せるか
- どのコンポーネントがストリームを消費しているか
- アクションが監査のためにどう記録されるか
- ファイル、ポート、プラグイン、リソースが、アプリケーション内のすべてのコンポーネントでどう管理されるか
こうした判断をアプリケーションごとに実装すると、同じインフラ上の2つのシステムが、異なるセキュリティ、監視、運用のモデルに従うことになります。
AmiCoreは、プロセスそのものの内部に制御レイヤーを加えます。横断的な関心事を一度で解決し、その中のすべてのコンポーネント、インターフェース、アプリケーションに一貫して適用する共有ランタイムです。
AmiCore
AmiCoreは共通のランタイムを提供し、シンプルな構成から大規模なデプロイメントまで、ユースケースごとにコンポーネントを設計できます。AmiCoreは、次の要素を管理するソフトウェアコンテナです。
プラットフォームとインターフェース
- デプロイメント
- データアクセス
- プラグイン
- REST
- MCP
- JDBC
情報セキュリティ
- ロールベースのアクセス
- ログインと認証
- ファイルシステムとポートへのアクセス
- モデルのアクティビティ監視
- 監査
開発
- ユニットテストによるコードカバレッジ100%
- IDE統合
- インラインデバッガー
- 統一スクリプト言語
AmiCoreコンテナの中で、アーキテクトは次のコンポーネントを使ってデプロイメントを設計できます。
プラグインモデル
- AmiCoreはI/Oにプラグイン方式を採用し、各インターフェースを同一のポリシーでガバナンスされる共通実装として提供
- エージェントは定義されたインターフェースから入り、権限のあるコンテキストだけを受け取り、帰属可能な記録を残す
- ガバナンスはランタイムから継承され、後から各アプリケーションに追加するものではない
利用可能なプラグインの例
リレーショナルDBとデータウェアハウス
Oracle · PostgreSQL · SQL Server · DB2 · MySQL · Sybase · Snowflake · Vertica · Impala · Hive · SQLite
NoSQL、キャッシュ、インメモリ
MongoDB · Couchbase · Redis · Ignite · Hazelcast · HBase · Chronicle Queue
メッセージングとストリーミング
Kafka · Solace · TIBCO EMS / StreamBase · IBM MQ · AMPS · gRPC
マーケットデータフィード
Bloomberg / B-PIPE · OneTick · QuantHouse · LSEG Data & Analytics(旧Refinitiv)
クラウド、ID、セキュリティ
AWS KMS / SQS · Azure Vault · Okta · SAML · LDAP · Web Entitlements · SSH
ファイル、フォーマット、ツール
Parquet · Avro · Excel · PDF · Python · Git · Perforce · Email
ガバナンス
AmiCoreは、金融機関がアプリケーションランタイムに求める要件を満たすよう設計されています。柔軟なコーポレートセキュリティモデルにより、AIが生成したものを含むアプリケーションを封じ込め、監査し、ガバナンスします。主な機能は次のとおりです。
AmiCoreが金融機関に適する3つの理由
自社環境で稼働
- コンピューター
- オンプレミス
- クラウド
- モバイル
データが自社環境の
外に出ない
ランタイムの完全な透明性
- パフォーマンス
- リソース
- 監査
コンテナの内部
目的別に設計されたコンポーネントで、自社に最適なインフラを構築
Relay、Center、Gateway、Web Server、Web Manager、Web Balancer。いずれも同じランタイムで構成、実行、ガバナンスされます。
選択肢の比較
3forge Enterpriseと代替アーキテクチャの比較
3forge Enterpriseは、初期導入からプロジェクトの加速、積み重なるメリットに至るまで、スケーラブルでガバナンスされたアーキテクチャのための有力なパラダイムを提供します。アーキテクトは多くの場合、オープンソースや社内コンポーネントによる構築からクラウド型データプラットフォームまで、他の選択肢と比較する必要があります。各スコアをクリックすると、その根拠をご覧いただけます。
評価は、既存の環境やご経験によって異なる場合があります。意見交換のための初回相談をご希望の方は、お問い合わせください。
| 評価軸 | 3forge Enterprise | クラウド型データプラットフォーム | 組み合わせ型ストリーミングスタック | 社内での独自開発 |
|---|---|---|---|---|
| リアルタイムの状態とサブ秒の応答 |
3forge Enterprise · 5/5 最高評価。現在の状態はアプリケーションロジックと同じプロセス内のメモリに保持されるため、クエリとデータの間にネットワークホップがありません。 |
クラウド型データプラットフォーム · 2/5 データの鮮度は取り込みとマイクロバッチのスケジューリングに左右され、すべてのクエリがリモートサービスへの往復になります。キャッシュで差は縮まりますが、なくなりはしません。 |
組み合わせ型ストリーミングスタック · 4/5 これ以上の評価にならないのは、現在の状態を別のサービングストアに実体化する必要があるためです。レイテンシは、そのストアと、ストリームとの整合性の維持に左右されます。 |
社内での独自開発 · 4/5 これ以上の評価にならないのは、結果が完全にチームの設計力と継続的な専門性に依存するためです。スタック自体は何も保証しません。 |
| ペタバイト規模の履歴分析 |
3forge Enterprise · 4/5 これ以上の評価にならないのは、ヒストリカルデータベース周辺の分析ツールがデータウェアハウスより限られ、コンピュートがオンデマンドで弾力的にスケールしないためです。 |
クラウド型データプラットフォーム · 5/5 最高評価。弾力的なコンピュート、成熟したクエリオプティマイザー、そして4つの中で最も充実した分析・機械学習エコシステムを備えています。 |
組み合わせ型ストリーミングスタック · 2/5 これ以上の評価にならないのは、ストリームはアーカイブではないためです。履歴には別のストアと第2のクエリ経路が必要ですが、スタックはどちらも提供しません。 |
社内での独自開発 · 3/5 これ以上の評価にならないのは、スケールは基盤に選んだデータベース次第であり、パーティショニング、チューニング、ライフサイクル管理の作業がチームに残るためです。 |
| ランタイム内部で強制されるガバナンス |
3forge Enterprise · 5/5 最高評価。ID、エンタイトルメント、監査はコンテナレベルのサービスであるため、アプリケーションごとに独自実装するのではなく、すべてのインターフェースが同じモデルに従います。 |
クラウド型データプラットフォーム · 3/5 これ以上の評価にならないのは、制御がデータの境界で止まるためです。データがアプリケーションに渡った後は、プラットフォームはその扱いを把握することも制約することもできません。 |
組み合わせ型ストリーミングスタック · 2/5 これ以上の評価にならないのは、各コンポーネントが独自のセキュリティモデルを持つためです。組織として1つのポリシーをそれらの上に再構築する必要があり、各コンポーネントが個別にバージョンアップするにつれてずれが生じます。 |
社内での独自開発 · 2/5 これ以上の評価にならないのは、ガバナンスがアプリケーションごとに実装されるためです。同じインフラ上の2つのシステムが、異なるエンタイトルメントと監査のモデルを持つことになります。 |
| ガバナンスされた本番アプリケーションまでの期間 |
3forge Enterprise · 5/5 最高評価。状態管理、エンタイトルメント、インターフェース、レポーティング、監視、デプロイメントがランタイムに備わっているため、残る作業はビジネスロジックだけです。 |
クラウド型データプラットフォーム · 2/5 これ以上の評価にならないのは、すぐに使えるのはデータ層だけだからです。アプリケーション、そのインターフェース、統制は別の取り組みとして残ります。 |
組み合わせ型ストリーミングスタック · 2/5 これ以上の評価にならないのは、最初のアプリケーションより先に統合作業が必要なためです。何かをリリースする前に、スタックを組み上げ、保護し、運用可能にしなければなりません。 |
社内での独自開発 · 1/5 これ以上の評価にならないのは、業務固有の最初の機能より前に、共通機能をすべて自前で構築する必要があるためです。ガバナンスされたリリースまでの最も長い道のりです。 |
| 運用と整合維持が必要な構成要素 |
3forge Enterprise · 4/5 これ以上の評価にならないのは、分散デプロイメントでは複数のコンポーネントがリージョンや環境をまたいで稼働し、それぞれにキャパシティとフェイルオーバーの計画が必要なためです。 |
クラウド型データプラットフォーム · 3/5 これ以上の評価にならないのは、マネージドプラットフォームが1つの層にすぎないためです。BI、ノートブック、オーケストレーション、アプリケーション層は、それぞれ個別に運用・アップグレードされます。 |
組み合わせ型ストリーミングスタック · 1/5 これ以上の評価にならないのは、コンポーネント、ベンダー、アップグレードサイクルが最も多く、その間のすべてのインターフェースを自社で維持しなければならないためです。 |
社内での独自開発 · 2/5 これ以上の評価にならないのは、スタック全体とそのライフサイクルが、開発したチームに委ねられるためです。3年後に誰も引き受けたがらない部分も含めてです。 |