NHK放送技術研究所（以下、NHK技研）は、技術展示イベント「技研公開2026」（5月28日～31日）で、ニュース映像などのコンテンツがいつ・どこで・誰によって撮影・編集されたかを記録し、検証できるようにする「来歴情報技術」の研究成果を展示している。
映像に「いつ・誰が・どう編集したか」を刻む技術、NHK技研が開発 来歴情報で“AIフェイク”も判別可能 - ITmedia NEWS
なりすまし動画や生成AIによる偽情報が拡散しやすい状況の中で、コンテンツの信頼性をユーザー自身が判断できるようにすることを目指す。
映像に「いつ・誰が・どう編集したか」を刻む技術、NHK技研が開発 来歴情報で“AIフェイク”も判別可能 - ITmedia NEWS
⇧ とりあえず、「検証」の結果が正しいかどうかはどう担保しているのかが気になりますな...
例えば「編集」に利用された「媒体」が乗っ取られていて、悪意ある第三者に利用されていないとも限らないので、そのあたりの「検証」の結果について、どのようなケースまで担保するのかは明らかにして欲しいお気持ち...
まぁ、完全なる「ファクトチェック」は不可能と言うことで「妥協点」を設けるにしろ、
- 検証可能なケース
- 検証不可能なケース
が分かる「情報」は明らかにして欲しいお気持ち...
兎にも角にも、「ユーザーフレンドリー（User Friendly）」、且つ、「ユーザーエクスペリエンス（UX：User eXperience）」な「情報」を公開して欲しいところではありますな...
不変条件は前提となる文脈によって定義が異なるのでややこしい...
毎年恒例の
⇧「JJUG CCC（Japan Java User Group Cross Community Conference）」の春の開催に参加して来ました。
今回は「AI」に絡む話が多かったのが印象的。
各「セッション」の「資料」の公開場所について、
⇧ 上記サイト様が整理してくださっておりました。
で、『不変条件と整合性境界—ビジネスが決める設計判断と実現パターン』という「セッション」について、
⇧ 上記の「スライド」によりますと、「ドメイン駆動設計（DDD：DomainDriven Design）」における「不変条件」の話になって来るらしく、「ドメイン駆動設計（DDD：DomainDriven Design）」の要素が密接に絡んできますと。
ちなみに、「不変条件」とは、
不変条件（英: invariant）とは、コンピュータプログラムの理論における用語で、ある処理の間、その真理値が真のまま変化しない述語 (predicate) であり、その処理シーケンスに対して不変であるという。
コンピュータプログラムは一般にそれを実行したときの変化で表されるが、プログラムの不変条件が何であるかを知ることも同様に重要である。これは特にプログラムについて推論するときに便利である。コンパイラ最適化の理論、契約プログラミングの方法論、プログラムの正しさを判定する形式手法など、いずれもプログラムの不変条件を重視している。
⇧ 上記にありますように、元々は、
『不変条件（英: invariant）とは、コンピュータプログラムの理論における用語で、ある処理の間、その真理値が真のまま変化しない述語 (predicate) であり、その処理シーケンスに対して不変であるという。』
とあるように、特に「業務知識」とかの接点は無いものであった模様。
また、
⇧ 上記の「Amazon」の公開している「セキュリティ」関連に関する「ドキュメント」における「不変条件」は「業務知識」が関わって来るが、「ドメイン駆動設計（DDD：DomainDriven Design）」には言及されていない。
ネットの情報を漁っていたところ、
本稿は、DDDの集約モデリング手順や、境界の見つけ方そのものを解説する記事ではない。扱うのは、集約境界と単一DBトランザクション境界を混同したときの波及である。RDBのロックや運用上の負担、読み取り側の公開範囲、プロセスマネージャー設計へ、どのような影響が出るのかを見る。つまり、ドメインモデリングの本質論ではなく、不変条件を実装へ落とす過程で表面化する技術的な論点に焦点を当てる。
⇧ 上記サイト様によりますと、
- 業務システム、且つ、データベースへのデータの永続化が必要となる
- 業務のコンテキストが複数あり、処理とデータが複雑に関係し合っている
のような「課題」を解決するために「ドメイン駆動設計（DDD：DomainDriven Design）」を活用するのだと思われるが、
⇧ 上記によりますと、「データ」の状態について、
- 強整合（即時整合性）
- リアルタイムの整合性が求めらる。同期。
- 処理を確定する時点で、ルールを満たした状態にFixする。
- 弱整合（結果整合性）
- タイムラグが許容される。非同期。
- 一時的な不整合を許し、後続処理でルールを満たす状態にFixする。
の2種類の「整合性」に大別されますと。
で、上記の2種類の「整合性」は、2種類の「境界」で対応する形になりますと。
■整合性と境界の対応関係
| No | 整合性 | 境界 |
|---|---|---|
| 1 | 強整合（即時整合性） | 集約の境界 |
| 2 | 弱整合（結果整合性） | ユースケースの境界 |
ここで、「業務システム」における「不変条件」については、
⇧ 上記にあるように、「区分け」が必要であると。
⇧ 上記にありますように、満たすことができないと「不可逆的」な「業務」上の「被害」を与えてしまうものについては、
- 真の不変条件
に分類されるそうな。
ちなみに、「真の不変条件」という「用語」は、
⇧ 上記によりますと、「Vaughn Vernon」氏の主張で出て来ている模様。
で、「集約」が複数になって来ると、1つの「集約」で完結しない処理が出てくるわけで、
⇧ 上記サイト様によりますと、「単一DBトランザクション」による「同期」処理では解決できない話になって来るので、「時間軸を持ったプロセス」による「非同期」な処理としての「設計」が必要になって来ますと。
ちなみに、「ACD」は、
■ 日本語版
ACIDとは、信頼性のあるトランザクションシステムの持つべき性質として1970年代後半にジム・グレイが定義した概念で、これ以上分解してはならないという意味の不可分性（英: atomicity）、一貫性（英: consistency）、独立性（英: isolation）、および永続性（英: durability）は、トランザクション処理の信頼性を保証するために求められる性質であるとする考え方である。
■ 英語版
In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps. For example, a transfer of funds from one bank account to another, involving multiple changes such as debiting one account and crediting another, is a single transaction.
⇧ 上記の「ACID（atomicity, consistency, isolation, durability）」の内、「独立性(Isolation)」を除外したものになる模様。
「ACD（atomicity, consistency, durability）」ということになるようだが、
Long-running transactions (also known as the saga interaction pattern) are computer database transactions that avoid locks on non-local resources, use compensation to handle failures, potentially aggregate smaller ACID transactions (also referred to as atomic transactions), and typically use a coordinator to complete or abort the transaction.
In contrast to rollback in ACID transactions, compensation restores the original state, or an equivalent, and is business-specific. For example, the compensating action for making a hotel reservation is canceling that reservation.
⇧ 上記の「Long-running transactions (also known as the saga interaction pattern)」の「弱整合（結果整合性）」を実現するための「方式」に関わりがある模様。
ややこしいのは、
⇧ 上記によりますと、
『「同一のトランザクション」だが「集約」を跨ぐ』
というケースも出てくるらしいというね...
まぁ、「集約」が分割できたとて、「データ」の「整合性」を管理する際に関わる「要因」を極力減らしておきたい気持ち的には「同一のトランザクション」で済ませておきたいと思うのが人情...
例えば、「障害」が発生した際に、「影響範囲」の調査をする際に、確認しなければならない「要因」が多いと辛いので...
特に、「非同期」な「状態」管理が絡んでくると、どのタイミングで、どの処理が関わったことに因るのか、特定が困難になること、あるあるですからな...
ちなみに、
⇧ 上記によりますと、「プロセス」の「設計」が、「システム」を「複雑」にしがちな気もする...
ただ、「パフォーマンス」的な問題については、
⇧ 上記によりますと、
- 集約の粒度
- ACIDの粒度
は別の問題という気がする。
「集約」を分割できたとしても、「同一のトランザクション」で複数の「集約」を処理するのであれば、分割されず巨大な状態の「集約」の時と変わらない気がしますしな...
ただ、「集約」が分割されていないと、「プロセス」的なアプローチの障壁となるのは、確かな気がするので、結局のところ、「業務要件」がハッキリしないことには、「ドメイン駆動設計（DDD：DomainDriven Design）」における「不変条件」もFixできない気はする...
とりあえず、
⇧ 上記によりますと、「不変条件」の「ルールを抽出」をするとなると、
- 要求定義
- 要件定義
などの「工程（フェーズ）」を経て、
- 業務フロー
- 業務の内、システムに落とし込める部分
の洗い出し、整理ができている必要がありますと。
まぁ、
- 不変条件
の「情報」の整理を「ソフトウェア開発」のどの「工程（フェーズ）」で実施するのかが「ファジー」なのが良くないとは思うのだが、仮に「設計」で考慮するというのであれば、昨今の「アジャイル開発」の「スクラム」的な取り組みで考えると、
- 要求定義
- 要件定義
- 設計
を行ったり来たりして決めていくのでしょうかね...
まぁ、
⇧ 上記にありますように、「ソフトウェア開発」については、
- 工程（フェーズ）
- タスク
が非常に「ファジー」であるからして、「情報」が「錯綜」していることもあり、「混沌（カオス）」と化しているので、「現場」は混乱しているのだけども...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
