確実 vs オプション：Zunaviはどう「信頼できるもの」を線引きするか

「約束」をするフィーチャーフラグのレジストリ

多くのフィーチャーフラグの仕組みが答える問いは1つだけです。「この顧客に対してこの機能はONかOFFか」。Zunaviのフラグレジストリは、もう1つの、より重要な問いに答えます。この機能が言っていることを信頼していいのか、です。

レジストリ内のすべての機能には「確実（certain）」か「オプション（optional）」かのtierが付与されており、これは見た目だけの区分ではありません。既定のON/OFF状態を決め、さらにその機能がUI上で自分自身についてどう語ることを許されるかを決めます。

確実：既定でON、そうでなければならないから

5つの機能が「確実」に分類され、既定で有効になっています。図面台帳のコア（drawing.core）、メタデータ検索（search.metadata）、仕様書と図面のひも付け（spec.link）、版管理・来歴（revision.management）、承認フロー（approval.flow）です。これらは、図面管理システムが間違っていてはならない機能です。台帳が「この図面はC版だ」と言えば、本当にC版でなければなりません。承認フローが「この変更は承認された」と言えば、それは真実であり、追跡可能でなければなりません。台帳（システム・オブ・レコード）に「だいたい正しい」バージョンは存在しません。

オプション：既定でOFF、精度がまだそこまで達していないから

7つの機能が「オプション」に分類され、既定で無効になっています。表題欄OCR（scan.titleblock）、2D類似検索（similar.2d）、3D類似検索（similar.3d）、クロスモーダル類似検索（similar.crossmodal）、図面比較・差分（viewer.compare）、3Dビューア（viewer.3d）、AIエージェント（ai.agent）です。これらは劣った機能というわけではなく、むしろプラットフォームの中でも技術的に最も興味深い部分の一部です。しかし「確実」tierにはない性質を共有しています。補助的であり、まだ発展途上であり、その出力は事実として扱われる前に人間による確認が必要だという点です。

スキャンした図面から表題欄OCRで部品番号を読み取るのは本当に便利です — 1文字誤読して、その値がBOMに伝播する前に誰も気づかない、ということが起きるまでは。ベクトルベースの類似検索が既存の図面に「似ている」図面を表示してくれるのは、部品番号の重複を避けるのにとても役立ちます — その一致を確認すべき「手がかり」ではなく確定した同一性として扱う人がいない限りは。オプション機能の失敗モードは「動かない」ことではありません。「十分な頻度で正しいために、人々がダブルチェックをやめてしまい、それが本当に重要な1回に限って外れる」ことです。

そもそもなぜこの線を引くのか

マーケティング的には、すべてを「AI搭載」と呼んで全部ONで出荷するほうが単純です。しかし、エンジニアリング向けソフトウェアに関しては、それは特に間違った判断だと私たちは考えています。スプレッドシート上の誤ったデータは煩わしい程度で済みます。しかし、加工現場、購買部門、品質部門が全員参照する図面台帳に誤ったデータがあれば、間違った材質が発注されたり、間違った版が加工されたり、重複した部品番号が2つの異なる部品を静かに統合してしまったりする可能性があります。誤りのコストは、そのデータに依存する下流の意思決定の数に比例して増大します。そして製造業では、その数は非常に多いのです。

そのため、このtier分けは設計による正直さの一形態です。確実とは「これは事実として保証する」という意味であり、オプションとは「これは人がより速く進むための道具であり、最終的な確認はまだ人間が担う」という意味です。オプション機能が有効化されている場合でも、UIはその出力を補助的であり確認が必要なものとして明示することが求められます。フラグを有効化しても、その機能の「認識論的な地位」が格上げされるわけではありません。

業界全体が同じ問題と格闘している

エンジニアリング向けソフトウェアにおけるAI支援機能に明示的な信頼境界が必要だと結論づけたのは、私たちだけではありません。PLMにおけるAI導入に関する論評は、ベンダー側の視点から同じ点を指摘しています。目標はエンジニアの判断を取り除くことではなく、事務作業を減らし、関連情報を表面化させ、潜在的な問題にフラグを立てることであり、AIは「規律あるガバナンスと人間による検証なしに問題を解決できると期待されるべきではない」とされています（Supply & Demand Chain Executive誌、ArasのPLMにおけるAIエージェントへの取り組みについて）。AI支援によるデータラベリングに関する研究も、別の角度から似た結論に達しています。システムが単なる答えではなく確信度を示すとき信頼性が向上し、ユーザーは、何のデータで訓練・検証されたかが見えないブラックボックスのように振る舞うモデルの出力を信頼することに（正しく）慎重になる、というものです（arXiv、AI支援データラベリングインターフェースに関する研究）。Zunaviの確実/オプションという区分と、「補助的であり要確認」というUI上の表現は、これらの文献が描く同じ問題に対する私たちなりの答えです。マッチング結果、OCRの読み取り、類似度スコアをそのまま信じさせるのではなく、確信度と根拠を示すという方向性です。

フラグの実際の解決の仕組み

フラグは機能ごとの単純なbooleanではありません。解決は複数の層で行われます。レジストリに組み込まれた既定値（defaultEnabled）がベースとなり、グローバルなデータベース上書きがすべてのテナントに対してそれを反転させることができ、テナント別の上書きが1つの顧客に対してさらに反転させることができます。FeatureFlagsService.resolveAll(tenantKey)がこの3層をテナントごとの単一の解決済みマップに合成し、30秒キャッシュすることで、チェックを安価に保ちつつも古くなりすぎないようにしています。デプロイ形態もここに関わります。Tenant.deploymentはONPREMかCLOUDのいずれかで、オンプレのテナントはクラウド依存のフラグが既定でOFFになります。これはしばしばデータが社外へ出ることを意味するからです（詳しくはオンプレ第一のアーキテクチャに関する記事をご覧ください）。

UIだけの慣習ではなく、二重に強制される

この仕組みが単なるUI上の慣習で終わらないのは、独立して2回チェックされているからです。フロントエンドでは、GET /api/v1/feature-flagsが現在のテナント向けに完全に解決されたマップを返し、UIはそれを使って何を表示し、どのルートを公開するかを決めます。しかし、隠されたボタンはセキュリティ境界ではなく、単なる提案に過ぎません。だからこそ同じルールがバックエンド側でも改めて強制されます。制限された機能に依存するすべてのルートには@RequireFeature(KEY)が付与されており、APP_GUARDとして登録されたグローバルなFeatureFlagGuardによってチェックされます。もしリクエストが無効化された機能のエンドポイントに直接到達した場合 — テナントレベルでフラグがOFF、機能がライセンスされていない、理由が何であれ — APIはフロントエンドが何を表示していたかに関わらず403を返します。

この二重の強制こそが、フィーチャーフラグが単なるUIの気配りなのか、それとも実際の保証なのかを分ける違いです。類似検索がOFFになっているテナントは、古いキャッシュ結果を見ることも、「一応まだ動く」エンドポイントに到達することもありません。本当に重要な層でドアが閉じられています。

全体像の中での位置づけ

このtier分けは、リリース日に紐づいたローンチ用の仕掛けではありません。Zunaviにはまだリリース日がなく、この記事でも日付を示すつもりはありません。これはプラットフォームの作り方に組み込まれた構造的な判断であり、あるオプション機能が来四半期に「確実」へ昇格するにせよ、さらに1年チューニングが必要になるにせよ、成り立ち続けるように設計されています。目標は機能を少なく出すことではなく、UIが実際の機能が獲得した以上の確信をユーザーに主張しないようにすることです。

---

関連記事：なぜZunaviの図面台帳をゼロから作り直しているのか、なぜZunaviはオンプレ第一なのか、そしてZunaviの紹介記事。ご自身のワークフローで「確実/オプション」の線をどこに引くべきか、ご意見があればぜひお聞かせください。[email protected]までご連絡ください。