本ドキュメントは、お客様のCIOおよびHead of Operationsの皆様がOKAXIのオペレーション管理ソフトウェアを評価される際にお寄せいただく質問をまとめたものです。回答は、小売および契約管理の本番運用案件における実務経験に基づき記載しています。
はい。OKAXIはコアエンジンをハードコードではなくconfigurableに設計しています。各企業のワークフローはノード (action、condition、approval) およびエッジ (transition) を持つJSONスキーマで定義されます。お客様のadminは管理パネル経由でワークフローを編集でき、OKAXIがコードを再デプロイする必要はありません。一部のお客様は同一インスタンス上で部署ごとに異なる50以上のワークフローを稼働させています。
OKAXIはJSON SchemaとUI Schemaを分離するフォームスキーマを採用します。各フィールドは名前、データ型、バリデーションルール、依存関係、可視性条件を含むメタデータを保持します。adminはドラッグアンドドロップインターフェース経由でフィールド追加、非表示化、ラベル変更が可能です。スキーマ変更時のデータマイグレーションはバージョン管理により自動化され、フォームアップグレード後も既存データは読み取り可能です。
はい。OKAXIはワークフローをバージョン管理します。稼働中のワークフローは既に作成済みのレコードに対して維持されます。新規レコードは新しいワークフローバージョンで実行されます。進行中レコードを新バージョンへ移行する必要がある場合、adminは明示的なマッピングルールを持つマイグレーションスクリプトを実行します。これにより、稼働中の状態機の急激な変更を回避し、ビジネス上の整合性を維持します。
5から7ステップのシンプルなワークフローは、トレーニング済みのお客様adminにより2営業日で構成可能です。20以上のノード、複数階層approval、外部システム統合を含む複雑なワークフローは、OKAXI BAのエンゲージメントで1から2週間かかります。すべてのワークフローには本番昇格前のテスト用サンドボックスが用意されます。OKAXIはハンドオーバー期間中、お客様admin 3から5名を対象に4回のトレーニングセッションを提供します。
OKAXIはクエリパターンごとに専用インデックス手法を適用します。Hotテーブルは (tenant_id、status、created_at) で複合インデックスを持ちます。Coldデータは圧縮付きで別テーブルへアーカイブされます。時間範囲またはテナント別パーティショニングにより、フルテーブルスキャンを回避します。本番稼働中の小売案件では、120万件のレコードを保持するcontractテーブルにおいても、3カラムでフィルタした50行リストビューでp95 200ms未満を達成しています。
OKAXIはcommand-query responsibility separation (CQRS) に基づき契約管理を設計します。command sideはデータ整合性のため正規化テーブルへ書き込みます。query sideはKafkaイベント経由で同期される非正規化リードモデルを使用します。リードモデルにはダッシュボードがrawから再計算しないよう事前集計値 (count by status、sum by amount) が保持されます。
OKAXIはGPSイベント向けに専用time-seriesデータベース (TimescaleDBまたはInfluxDB) を採用します。各フィールド担当者がモバイルアプリから30秒ごとにpingを送信し、MQTTまたはHTTPバッチでバックエンドへ転送されます。バックエンドはtime-seriesストアへ書き込み、30日経過したデータには自動圧縮を適用します。
OKAXIは複雑度に応じて報告書を3層に分割します。Tier 1 (リアルタイムダッシュボード、1秒未満) は5分ごとにリフレッシュされるmaterialized view上で動作します。Tier 2 (詳細レポート、30秒未満) はストリーミングカーソルでアドホッククエリを実行します。Tier 3 (重いクロスドメインレポート、数分) はジョブキュー経由で実行し、結果をメールまたはダウンロードリンクで配信します。ユーザーはUIブロッキングではなく通知を受け取ります。
OKAXIはオリジナルファイルにオブジェクトストレージ (S3またはS3互換) を使用し、メタデータはPostgreSQLに保管します。テキストファイルは規模に応じてElasticsearchまたはPostgreSQL pg_trgmで全文検索インデックス化されます。PDFはtika-server経由で自動的にテキスト抽出され、インデックスへ投入されます。50000件以上のPDFファイル内のコンテンツ検索を、p95レイテンシ500ms未満で実現します。
OKAXIはrole-based access control (RBAC) とattribute-based access control (ABAC) を組み合わせます。RBACは組織ツリーに沿ってロールおよび権限を定義します。ABACは実行時条件を追加します。例えば自身が管理する地域の契約のみ閲覧可能とするなどです。すべての権限チェックはOpen Policy Agent (OPA) またはCasbinで記述された中央ポリシーエンジンを通過し、すべての認可判断が監査可能です。
はい。行レベル: 各レコードはowner_idおよびscope_idを保持し、クエリはユーザーコンテキストに基づき自動でフィルタされます。フィールドレベル: 各フォームフィールドは可視性ルールおよび編集可能性ルールを保持します。給与や契約金額などの機密フィールドは特定ロールのみ閲覧可能です。権限ルールは宣言的に定義され、コードへハードコードされません。お客様adminはOKAXIの再デプロイなしに更新可能です。
監査ログは各イベントについて6次元の情報を記録します。第一に actor (誰が) 。第二に action (何を: create、update、delete、view、export) 。第三に target (どのレコードに) 。第四に timestamp。第五に変更前後のdiff (旧値と新値) 。第六に context (IP、デバイス、session_id) 。ログは改竄検知のためSHA-256チェーンを持つappend-only不変ストレージに保存されます。コンプライアンスレポートはCSV出力またはお客様SIEMへの直接接続をサポートします。
はい。任意の文書タイプに対し、任意の階層数のapprovalフローを付与できます。ルーティングルールは金額レンジ、地域、部署、カスタム条件で構成可能です。各階層にはタイムアウトがあり、次階層へ自動エスカレーションされます。Approverはモバイルプッシュ、メール、アプリ内通知を受信します。Approverは指定期間内に他のユーザーへ委任可能です。Approval履歴は監査ログに完全に記録されます。
OKAXIはOpenAPI 3.0およびGraphQL SDL標準に準拠したREST APIおよびGraphQL APIを公開します。すべてのリソースに標準化CRUDエンドポイントおよびOData形式のフィルタシンタックスを備えます。認証はユースケースに応じてOAuth 2.0またはAPIキーを使用します。Webhookは送信元検証のためHMAC SHA-256署名ヘッダー付きで各イベントを配信します。Rate limitはAPIキーごとに構成されます。ドキュメントは自動生成され、/api/docsにSwagger UIのtry-it-out付きで公開されます。
OKAXIはコアをplugin architectureとして設計しています。各業務モジュールは、subscribeするイベントおよびexposeするAPIを宣言するcontractを持つpluginです。新機能はコアコードを変更せず新規pluginとしてリリースされます。Pluginはfeature flag経由でテナントごとに有効化されます。お客様は独自pluginを開発し、社内マーケットプレース経由で自社インスタンスへデプロイ可能です。セキュリティはOKAXIがレビューおよび承認します。
