メインコンテンツまでスキップ

よくある質問

Merlon が何であるかについての質問と、評価者が意外に感じやすい設計判断について。

プロジェクトについて​

Merlon はオープンソースか？​

いいえ。そしてこの区別は調達において重要である。

Merlon は Business Source License 1.1 による source-available ソフトウェアである。ソースは全面的に公開されており、閲覧・改変・実行（本番利用を含む）が可能だが、OSI 承認のオープンソースではない。Additional Use Grant が1点だけ除外しているためである。すなわち、Merlon を第三者に対してホスティング型・マネージド型・組み込み型のコンプライアンスサービスとして提供することはできない。

2030-09-30（Change Date）に、このバージョンは Apache-2.0 になる。これは約束ではなくライセンスの条項である。

GitHub がライセンスを "Other" と表示するのは、BUSL が OSI のリストに含まれないためであり、これは想定どおりである。理由は ADR-0003 にある。

本番で使ってよいか？​

ライセンス上は可能である。プロジェクトの側が本番に耐えるかは別の問題であり、その答えは宣伝ではなく文書として置いてある。コンテナイメージとリリースチェックリストを参照。

本リポジトリのアクティブなメンテナは1名である。それを読まれないプレリリースタグのサフィックスに符号化するのではなく、全リリースが成果物上で明示する。release-manifest.json とイメージラベルに、当該リリースが独立した承認と職務分離を主張しない旨を記録している。本番適合性は、貴組織の規制上の義務に照らして貴組織が判断すべき事項である。AML/CFT システムにおいては、その判断はベンダーが何を主張していようと当局に対して説明できるものでなければならない。

なぜ latest タグが無いのか？​

同じ docker pull を別々の日に実行した2台のホストが、同じバージョンを名乗りながら異なるソフトウェアを動かしてしまうためである。

規制記録を生成するシステムにおいて、リリースの同一性はイメージダイジェストである。バージョンタグは不変であり、そのダイジェストを指すものにすぎない。コンテナイメージを参照。

Merlon はマルチテナントか？​

いいえ。1デプロイにつき1機関である。

これは未実装の機能ではなく意図的な制約である。マルチテナント化は、ある機関の顧客データ・スクリーニング結果・疑わしい取引の届出草案を、別の機関のものと同一データベースに置き、アプリケーション層のロジックだけを分離手段とすることを意味する。シングルテナント構成は、分離をコードにバグが無いことではなくインフラの性質として担保する。

データとプライバシー​

テレメトリを収集しているか？​

いいえ。利用状況分析も、クラッシュレポートも、ライセンス確認も、いかなる phone-home も存在しない。この質問に答えるために何かを削除したわけではなく、最初から作られていない。

Merlon が行いうる外向き通信の完全な一覧と、その契機はデータ送出にある。一覧は短く、そのすべてが利用者自身が設定したものである。

更新を確認するか？​

いいえ。Merlon は新しいバージョンの存在を通知しない。

これには実際のコストがある。公表済みの脆弱性を含むバージョンを、通知されないまま動かし続けうる。それでもこれは意図的である。Merlon は閉域網で運用されることが多く、そのような環境では公開ホストへの説明のつかない外向き通信自体が指摘事項となり、「このソフトウェアは外部と通信するのか」という問いに一度ではなくデプロイのたびに答えなければならない。

代わりに Releases を購読し、アップグレードを参照すること。稼働中のバージョンは GET /healthz が返す。

顧客データはどこにあるか？​

貴組織の PostgreSQL データベースの中にある。コンテナは状態を持たず、読み取り専用で動作する。

直接的な PII 顧客属性はリポジトリ層で保存時に暗号化されるため、暗号化を迂回する書き込み経路は存在しない。鍵はデータベース外の MERLON_ENCRYPTION_KEY_RING にある。したがって、対応する鍵を伴わないデータベースバックアップは恒久的に読み取れない。バックアップと復元を参照。

設計判断​

なぜ CDD スコアがすべてを駆動するのか？​

取引モニタリングの閾値、ケース優先度、スクリーニング頻度は、いずれも個別に設定するのではなく顧客の CDD リスクスコアから導出される。

代替案であるサブシステムごとの独立した閾値は、ある顧客がスクリーニング上は高リスクでモニタリング上は低リスク、という状態を、その理由を説明する場所がどこにも無いまま許してしまう。ひとつのスコアから導出することで、下流のすべての判断が追跡可能な理由を持つ。これは検査官が求めるものそのものである。

ADR-0004 を参照。

なぜ起動時に自動マイグレーションしないのか？​

スキーマ変更はコンテナ再起動の副作用ではなく、変更管理の対象となる事象だからである。

マイグレーションは、サービング用ロールが持たない専用のデータベースロールを使い、独立した運用手順（make migrate）として実行する。アプリケーションが起動時に自らマイグレーションするなら、サービング用ロールは DDL 権限を必要とする。監査統制がまさに遠ざけようとしている audit_logs に対しても、である。

また、失敗するロールアウトが、たまたま最初に起動したレプリカ上ではなく、意図して実行した手順の中で失敗するという意味もある。

なぜプラグイン機構が無いのか？​

「拡張可能である」ことと「コンプライアンスエンジンの内部で任意コードを実行する」ことは別物であり、監査に耐えるのは一方だけだからである。

Merlon は設定によって拡張する。

  • ルールは content/ 配下の JSON/YAML であり、公開スキーマで検証され、バージョン管理され、有効化には二重統制がかかる。
  • 連携は YAML で設定する REST アダプターである（アダプターガイド）。アダプターはコードではなく設定であり、連携ロジックはバイナリの外に留まる。
  • イベントは webhook で外へ出る。再送と Dead Letter Queue を備える。
  • それ以外は REST API であり、非対話クライアント向けに API キーを発行できる。

第三者のコードをインプロセスで実行するプラグインは、規制記録を生成するトランザクション境界の内側に入り込む。汎用ツールに比べ、この製品にとってその取引条件ははるかに悪い。

なぜ down スクリプトの無い前方向のみのマイグレーションなのか？​

データ変換を逆転させる down マイグレーションは、失われるものがあるか、正しくないかのいずれかであり、どちらであるかはインシデントの最中に判明する。

ロールバックはバックアップからの復元である。そちらのほうが遅く、そして誠実である。バックアップと復元が、文書化された復元ではなくリハーサル済みの復元を要求しているのはそのためである。

なぜコンテナを root で動かさないのか？​

uid 10001 で動作し、書き込み可能なパスを必要としない（--read-only がそのまま動く）。ファイルシステムに何も書かないアプリケーションが書き込み権限を持つ理由は無い。

ドキュメントと貢献​

なぜ ADR がこのサイトに無いのか？​

ADR は公開リポジトリにあり、ここからもリンクしているが、ビルドされるサイトからは除外している。

ADR はシステムを変更する人のための決定記録であり、日本語で書かれ、エンドユーザー向けドキュメントが前提としてはならない文脈を前提としている。ドキュメントとして公開することは、ドキュメントとして保守することを意味する。

ドキュメントに日本語版はあるか？​

ある。本サイトは二言語構成であり、翻訳の同期は CI で強制されている。日本語訳の無い英語ページは、明示的に例外登録されていない限りビルドを失敗させる。オペレーター UI も英語と日本語を提供し、メッセージカタログに同じ強制がかかっている。

貢献者向けファイル（README、CONTRIBUTING、SECURITY）は英語のみである。

貢献できるか？​

できる。CONTRIBUTING.md を参照。

2点は必須であり、満たさない場合 CI が失敗する。すべてのコミットに DCO サインオフ（git commit -s）が必要であること、そしてすべてのプルリクエストが対応する要件または issue と設計上の根拠を明記することである。トレーサビリティの要求は、このコードベースが規制記録を生成しており、「なぜこれを変更したのか」に数年後も答えられる必要があるために存在する。

顧客データ、非公開の仕様、内部のリスク評価を issue やプルリクエストに記載しないこと。

動かない。どこから見ればよいか？​

トラブルシューティングの冒頭に症状の逆引き表がある。ページを通読するのではなく、実際に表示されているメッセージを探すこと。