付録
本付録は、本文で語った事件を再説明する場ではありません。再利用可能な設計パターン、章とADR・コミットの対応関係、用語の定義、参考文献を、検索して参照するための資料としてまとめます。
全体像: 最終的なレイヤー構成と、そこへ至る流れ
事件ごとの詳細に入る前に、最終的にawaseがどんな形に落ち着いたかを俯瞰します。主経路 (入力から出力まで)は4段階を経て、以下の図が示す最終形に至りました。
| 段階 | 時期(章) | 追加されたもの | 主経路の形 |
|---|---|---|---|
| 第1段階 | 第1章 | なし(engine一つで完結) | 入力から出力までの素朴な一本道 |
| 第2段階 | 第1〜2章 | n-gramによる統計的タイブレーク、Decision/Effectモデル、アプリ種別ごとの出力切り替え | 一本の経路の中だけで完結 |
| 第3段階 | 第3〜8章 | 観測・信念層(観測は信念を直接上書きしない)、アプリ適応層(物理キーを渡すか制御) | 主経路の外側に別の層が新設される |
| 第4段階(最終形) | 第9章〜 | 観測・信念層と適応層を4層reducerへ統合、世代照合という型 | 「作用してよいか」を最後に一箇所で判断する経路が完成 |
出力の先には、メモ帳・Word(Win32/UWP)、Chrome・Edge、Windows Terminal・VS Codeという 具体的なアプリ名を置き、その先で実際にかな漢字変換を行うGJI(Google 日本語入力)・ MS-IMEという2つの競合IMEへつながります。フックからIME確定文字までの間、 WH_KEYBOARD_LL・IMM32/TSF・GetProcessIoCountersといったWindows APIのどこに 触れているかも矢印に添えました。
この経路は、送った命令が事実どおりに届いたか(柱A)、同じ分岐に押し込んでいた変化が 本当に一つの軸だったか(柱B)という2つの問いにまだ答えていません。第10〜11章は柱Aを、 第12章は柱Bを、第13〜15章は同じ照合の発想を開発プロセスへ向けます。
パターンカタログ
本文全体から抽出した12個の設計パターンです。各パターンは「パターン名・文脈・問題・働く力・解決・結果・限界・関連する章とADR」の8項目で統一しています。
1. Observer never overrides desired(観測は信念を上書きしない)
- 文脈: 非同期のprobe・pollがbeliefを更新しようとする場面です。
- 問題: 観測をそのまま反映すると、後から届いた古い観測がintentを消してしまいます。
- 働く力: 観測の遅延・順序入れ替えは避けられませんが、intentは観測より優先して守るべき情報です。
- 解決: Intent・Observation・Transition・Barrierの4層に分離し、Observationはbeliefを直接書き換えず、常にIntentとの照合を経由してから反映します。
- 結果: observationがintentを上書きして起きていた症状が解消しました。
- 限界: 4層分離自体は「いつ照合するか」を決めません。照合のタイミングそのものが、別の急所(パターン2)になり得ます。IME belief・GJI warmth・observation admissionの3領域が独立に同型の設計へ収束したのも、「集約すれば直る」という初期仮説が誤りだったことの傍証です。
- 関連する章・ADR: 第9章、ADR-032
2. Generation/epoch fencing(世代照合による足止め)
- 文脈: 非同期API呼び出し(IME apply等)の結果が発行順と異なる順序で返る場面です。
- 問題: 古い呼び出しの結果が新しい状態を上書きします(stale write)。
- 働く力: 完了順序は制御できませんが、「どの世代への呼び出しか」は発行時に分かります。
- 解決:
on_focus_process_changed(フォーカス先プロセスの変更)のたびにwrapping_add(1)でラップしながら増える世代カウンタ(FocusEpoch)を発行時に刻み、適用時に現在の世代と照合してから適用します。 - 結果: observation起因のstale writeを構造的に防止しました。
- 限界: admit()通過後から実際の適用までの間に世代が変わるケース(TOCTOU、確認した瞬間と使う瞬間のずれ)は、世代照合だけでは防げません。
- 他の実装での確認例: Unitree Go2 Runtimeにも
TickIdというFocusEpochに似た値がありますが、execute直前のガードはウォッチドッグの生存確認だけで、送信直前の再照合はまだありません(終章で触れます)。 - 関連する章・ADR: 第9章、第16章、ADR-077
3. Own the channel, don't filter the noise(チャネルを断つ、ノイズは濾さない)
- 文脈: 合成イベントと物理イベントが区別できない入力経路です。
- 問題: フィルタを重ねても新しいエッジケースが次々見つかり収束しません。
- 働く力: 判別は不可能な場合がありますが、経路そのものへのアクセスは制御できます。
- 解決: 判別を諦め、対象アプリに物理キーそのものを見せません(チャネルレベルでConsumeします)。
- 結果: 誤検知の再発が止まりました。
- 限界: チャネルを断てない構成(相手プロセスの内部ウィジェット構造など)では、別の観測手段が必要です。
- 関連する章・ADR: 第7章、ADR未確認(要補完)
4. Side-channel observability(副次観測)
- 文脈: 競合プロセスの内部状態を知る公式APIが存在しない場面です。
- 問題: DLLフック・COM傍受・IPC盗聴がいずれも失敗します。
- 働く力: OS標準のプロセスメトリクス(I/Oカウンタ等)は公式APIとして公開されています。
- 解決: 必要な操作自体をプローブとして転用し、
GetProcessIoCounters()の差分から相手の処理内容を推測します。 - 結果: 競合IMEの活性化状態を検出できるようになりました。
- 限界: この技法自体の一般的な限界は、2013年のアンチデバッグ手法の文脈でのみ間接的に確認されています。
- 関連する章・ADR: 第6章、ADR-048、ADR-062
5. Confidence-tiered sensor fusion(確信度による観測の融合)
- 文脈: 複数のprobeが矛盾する情報を返す場面です。
- 問題: 「最後に届いた値を正とする」と、信頼度の低い観測が高い観測を覆します。
- 働く力: observationの由来(evidence)によって信頼度は異なります。
- 解決: 観測源ごとに信頼度を重み付けし、投票的に1つのbeliefへ統合します。
- 結果: 確信度型の導入により、矛盾する観測がそのまま反映される事態を防ぎました。
- 限界: 重み付けの基準自体は経験則であり、新しい観測源が増えるたびに見直しが必要です。
- 関連する章・ADR: 第4章、ADR-044
6. Shadow-mode migration(並走移行)
- 文脈: 新しい実装(shadow_model等)を既存実装と置き換える場面です。
- 問題: いきなり切り替えると新実装の未知の欠陥が本番へ影響します。
- 働く力: 新旧を同時に動かして差分だけを見れば、切り替え前に欠陥を発見できます。
- 解決: 新旧実装を並走させ、差分ログで検証してから段階的に昇格させます(ADR-040)。
- 結果: shadow_modelをSSOT(Single Source of Truth、単一の真実源)へ安全に昇格できました。
- 限界: 並走期間中は、二重のメンテナンスコストがかかります。
- 関連する章・ADR: 第5章、ADR-040
7. FeedbackPolicy: 読み戻せるかどうかで補正ループを分岐させる
- 文脈: 自動是正ループを、観測能力の異なる対象(読み戻せる/読み戻せない)へ一律適用する場面です。
- 問題: 読み戻せない対象に確認前提のループを当てはめると、無限に再送するか収束を偽装します。
- 働く力: 読み戻せるかは実装者の好みでなく、対象システムの観測可能性で決まります。
- 解決:
Read { source, deadline }/Blind { max_attempts, backoff }という型を導入し、指定を省略できないようにします。Blindの諦め(GaveUp)は観測ストアへ書き込みません。count guardと組み合わせれば追加漏れも検知できます。 - 結果: 675ミリ秒に16回の無限再送と、観測を書き戻すことによる補正の永久停止という、正反対の2つの壊れ方を、同じ型設計で防止しました。
- 限界: この型は有限回で終端すること(liveness)は保証しますが、観測を書き込む側の偽装(safety)までは防げません。Windows実機でのソークテストも未実施です。
- 関連する章・ADR: 第10章、ADR-078、ADR-080、ADR-081
8. Blast radius(破壊範囲)で取り消し操作を選ぶ
- 文脈: 取り消し操作(backspace等)の対象を、遅れて届く証拠だけから正確に狙い撃てない場面です。
- 問題: 精度を上げる対策を重ねても取り違えリスクは消えず、誤って発火すると無関係な確定済みの文字まで消えます。
- 働く力: 取り消し操作には、破壊できる範囲が構造的に限定されているものとされていないものがあります。
- 解決: 精度でなく破壊範囲で操作を選びます。カーソル直前を無条件に消すbackspaceではなく、現在のcompositionスコープの外に届かないESCキーへ置き換えます。
- 結果: 誤って発火しても、確定済みの無関係な文字を巻き込まなくなりました。
- 限界: 範囲が構造的に限定された代替操作が存在する場合にしか使えません。代替が見つからなければ、精度側の対策に頼らざるを得ません。
- 関連する章・ADR: 第11章、ADR-079
9. 静的な軸は型へ、動的な軸は共有機構へ
- 文脈: 複数の実行文脈(アプリ×IME等)にまたがるロジックを一つの汎用ループへ共通化してきた場面です。
- 問題: 「共有か重複か」を直感で選ぶと、共有側はcross-profile spilloverを、重複側は実装同士の乖離というリグレッションを生みます。
- 働く力: ロジックが実は2つの独立した軸(静的な軸、動的な軸)を1つの分岐に押し込んでいたことが原因でした。
- 解決: 静的な軸(プロファイル)は型で分離し重複を許容します。動的な軸(アクティブなIME種別)は共有機構にまとめ、capability tokenで到達可能性を閉じます。count guardとcontract testが、単一窓口化までの中間解として機能します。
- 結果: 既存バグ43件を分類した実測データに基づき、限定的な分離(Limited Go)を選択しました。契約テスト5件が、実データから拾い出した失敗モードに一対一で対応する形で実装されています。
- 限界: 変化の軸が二つに分解でき、かつ直交している場合にしか使えません。軸を見誤れば、分離そのものが新しいバグの温床になります。単一窓口化・完全分離そのものの代替にはなりません。
- 関連する章・ADR: 第10章、第12章、ADR-081、ADR-082
10. 大局的な疑いを、修正ループの外へ独立させる
- 文脈: 個々の変更が局所的に正しくテストも通るのに、積み重なった結果全体を疑う機会が存在しない場面です。
- 問題: 「次の不具合を直す」を繰り返すだけでは、「今もこれ全部が必要か」という前提を疑う問いは生まれません。
- 働く力: 疑う機会は修正ループの延長では生まれず、独立したタスクとして切り出さなければ生まれません。
- 解決: 「もう要らないのではないか」という仮説を立て、安全策を一時的に外すリスクを引き受けるか、前提を疑わせることだけを目的にした対話(壁打ち)を設けます。
- 結果: 待機行列・捨て打ち機能という二重の予防的防御層の全廃(第13章)、プロファイル別ドライバへの分離という設計転換(第12章)という、2つの独立した大局的な飛躍が生まれました。
- 限界: 疑う機会を構造的に用意することは保証しますが、何を疑うべきかという矛先そのものは原則の外にあります。
- 関連する章・ADR: 第13章、ADR-080、ADR-081
11. 診断フラグ→実機ソーク→恒久化→物理削除の4段階
- 文脈: 「もう要らないのではないか」という仮説を、実害のリスクを冒さずに検証したい場面です。
- 問題: 予防策をいきなり削除すると仮説が外れた場合に実害が出ますが、放置すれば二重の保守コストが残ります。
- 働く力: 削除の可否を判断する証拠は、実機で長期間動かしてみなければ得られません。
- 解決: 安全策を診断フラグで無効化し、実機で日をまたいでソークし、問題が出なければ恒久化、最後に物理削除します。削除時の副産物(到達不能コード等)も調査します。
- 結果: 待機行列・捨て打ち機能という二重の予防的防御層を、安全に全廃できました。
- 限界: この型は、疑う対象がいったん仮説として明示されていることを前提とします。仮説を立てる最初の一歩そのものは、この型に含まれません。
- 関連する章・ADR: 第13章
12. 同じ場所を書き換える権利を、空間と時間の両軸で区切る
- 文脈: 複数の書き手(人間・複数のAIセッション)が同じ対象に同時、あるいは時間を隔てて触れる場面です。
- 問題: 所有と経緯の情報が暗黙のままだと、空間的な衝突と時間的な衝突の両方が起こり得ます。
- 働く力: 空間的に同時に触れられる対象と、時間的に隔たって検討される対象とでは、必要な区切りの形が違います。
- 解決: 空間側には、作業単位ごとに専用の作業ディレクトリとブランチ(
git worktree)を割り当て、構造的に交わらないようにします。時間側には、判断を退けた理由までを消さずに記録する仕組み(試行ログ・revertルール)を用意します。 - 結果: worktree分離により、複数セッションの作業ツリー共有事故を防止しました。試行ログとrevert規約により、5日間で6回反転したキー選択の経緯を追跡可能にしました。
- 限界: どちらの仕組みも、区切りの手段を用意するだけであり、書き手がそれに従うかどうかまでは保証しません。規律が続く保証は、記録の仕組み自体からは出てきません。
- 関連する章・ADR: 第14章
ADR・コミット対応表
章・事件・ADR番号・主要コミットの対応です。本文の再説明はせず、参照先として使う表です。
| 章 | 事件名 | 症状 | ADR番号 | 主要コミット | 現在の限界 |
|---|---|---|---|---|---|
| 第9章 | IME belief/SSOTモデルの変遷 | observationがintentを上書き | ADR-032, 077 | d2e183f, f8dd8d4, 6baabf9, a4db93e, 604cf99 | admit後・適用前のepoch遷移(TOCTOU) |
| 第9章(補) | 凝集性リファクタ第2幕(21タスク一括) | 循環依存・God Object・ImeBelief.input_modeのpub公開 | ADR-069 | d79c25e | 未確認(残タスクは個別コミットの追跡が必要) |
| 第9章(補) | GJI前置キー待機キューの所有権移管 | probe切り替え時にdeferred VKが破棄される(「にゅうりょく」→「にうりょく」) | ADR-071 | 15ac8d8 | StepCoroのself-priming漏れは別途対応 |
| 第10章 | conv-mode増幅ループ(ConvModeMgrの自己参照) | cold warmupのたびに誤ったbeliefがreal IMEへ再書き込み | ADR-078 | e7cc6d7, d495649 | 最小対策は第13章で撤去され、型設計は未実装 |
| 第10章 | drift correctionのActuation型化 | 675ミリ秒の間にVK_IME_OFFを16回無限再送 | ADR-080 | 68d73d5 | 実機ソーク未実施、暫定値のまま |
| 第11章 | per-VK confirmのstale confirm誤帰属 | 世代の異なる確定証拠をbackspaceが取り違え無関係な文字を消す | ADR-079 | 7b54a96, 1817925, a3be20d | ESC+限定replayによる回収(Stage 2)は未実装 |
| 第12章 | プロファイル別capabilityドライバへの分離 | 共有ループのプロファイル分岐がcross-profile spilloverを生む(既知バグ43件中11件) | ADR-081 | 123801b, 4af265f, bc3d13e | 実機配線と旧経路撤去は未着手 |
| 第12章(補) | journal配線によるActuation出所・世代の記録 | 分離移行中どちらの経路が真実か分からなくなる期間が生じうる | ADR-082 | 4503223, b1ea94c | 本体は提案段階、journal配線のみ実施済み |
| 第3章 | Windows Terminal/TSFコールドスタートliteral化 | ローマ字キーストロークのリテラル漏れ | ADR-049 | 26373e2, 84e6942, c089757, 97c922e, 6ecb8e9 | F2後の再初期化に344ms必要(idle時間に比例) |
| 第7章 | ImmCross/LINE偽VK_F3/F4 echo | 物理KANJIキー押下が偽トグル生成 | 要確認(未特定) | d99e3f1, 77ccf34, e890a26, f84c74b, 08b8661, 0e364ea | ImmCrossProbeの信頼性問題(Qt子ウィジェット) |
| 第7章(補) | GJIキーバインド3世代交代 | F13/F14衝突 | ADR-034/057/067 | 7f8291f, 81df62c, cfbbd20, b271aee, 098c663 | MS-IMEはVK_KANJIが必要(ADR-063) |
| 第9章(補) | VK/ScanCode混同検知dylint | newtype導入後も取り違え継続 | ADR-012 | 2dd43f4 | 未確認(現状lintで防御) |
| 第6章 | 捨て打ち機能(旧サクリファイシャル・ウォームアップ) | Chrome cold-start中のリテラル化 | ADR-048, 062 | 26bc0fe, d02ec44, 6c1732d, 22c3905 | vim等とのVK_A衝突(他アプリは離脱済み) |
| 第8章 | StepCoro統一 | 増殖したFSM群(5種類)の複雑化 | ADR-053 | e548e63, ccd4711, f01d401, b077c3d, 2c756dd, d1d6d17 | LiteralDetectFsmはコルーチン化されず残存(意図的) |
注記です。第7章のコミットハッシュ(11件)は実在・内容一致を確認済みですが、対応するADR番号は未特定です。
拡張用語集
src/toc.mdの用語集に、Unitree Go2 Runtime実地検証で見つかった対応語を追記しています。
| 用語 | 定義 | Unitree Go2 Runtime対応語 |
|---|---|---|
| shadow state | OSが正直に教えてくれないIME状態を、自前で推測・保持する仕組み | WorldState(immutableな世界モデル) |
| belief(信念) | 観測から導出した「いまのIME状態はこうだろう」という推定値 | BeliefView<T>(旧称BeliefSnapshot<S,B>) |
| Observation(観測) | probe・pollから届く生の情報。beliefを直接上書きしない | StateUpdate(S層が受け取る生観測) |
| FocusEpoch | フォーカス先プロセスの変更のたびに増えるカウンタ。観測の鮮度を判定する基準 | TickId(tick単調カウンタ。ただしepoch照合には未使用) |
| AcceptedObservation | 世代(epoch)照合(admit)を通らないと構築できない、型で保証された「新鮮な観測」 | 現状Unitree Go2に相当機構なし |
| 捨て打ち機能 | I/Oカウンタ差分で副次観測する技法(第6章、第13章で撤去) | 直接対応なし |
| Observed<T> | Unitree Go2 Runtimeの観測品質型。Fresh・Stale・Unknown・Brokenの4値を持つ | awaseのshadow state・beliefに相当 |
| 用語 | 定義 |
|---|---|
| awase (合わせ) | 本書で描くWindows用日本語入力エンジン(NICOLA親指シフト方式) |
| NICOLA / 親指シフト | 親指キーとの同時打鍵タイミングで仮名を確定する日本語入力方式 |
| TOCTOU急所 | admitした時点では新鮮でも、実際に適用する時点では陳腐化している間隙 |
| FeedbackPolicy(Read/Blind) | actuateの結果を読み戻せるかを型で必須指定させる設計(第10章) |
| liveness / safety | 補正が有限回で収束する性質(liveness)と、状態が嘘をつかない性質(safety)(第10章、第13章) |
| 静的な軸 / 動的な軸 | 実行中に変わらない軸と、実行時に変わる軸の区別(第12章) |
| 世代フェンシング(epoch fencing) | 遅れて届いた証拠がどの試行に属するかを照合する仕組み(第11章、第16章) |
| blast radius(破壊範囲) | undo操作が届きうる範囲の小ささで操作を選ぶ考え方(第11章) |
| count guard / contract test | 呼び出し箇所数の凍結と契約テストによる現実的な中間解(第10章、第12章) |
| Unitree Go2 Runtime | 著者が別に設計しているロボット(Unitree Go2)向けアプリケーションランタイム |
参考文献リスト
| 文献 | 書誌情報 | 備考 |
|---|---|---|
| Kleppmann, フェンシングトークン論 | Martin Kleppmann, "How to do distributed locking", 2016-02-08, https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html | — |
| Chubby (Burrows, OSDI 2006) | Mike Burrows, "The Chubby lock service for loosely-coupled distributed systems", 7th USENIX OSDI '06, 2006-11. https://www.usenix.org/conference/osdi-06/presentation/chubby-lock-service-loosely-coupled-distributed-systems | PDF直リンクは要検索です。 |
| Firefox OS/Gaia bug 1110030 | Bugzilla@Mozilla, Bug 1110030, "Routing hardware key events to keyboard app when an input field is focusing", https://bugzilla.mozilla.org/show_bug.cgi?id=1110030 | IsSynthesizedByTIP言及箇所は要検索です。 |
| NIOSH Hierarchy of Controls | CDC/NIOSH, "Hierarchy of Controls", https://www.cdc.gov/niosh/hierarchy-of-controls/about/ | — |
| Yaron Minsky, "Make illegal states unrepresentable" | 原典記事URLは要検索です(OCamlコミュニティで広まった言い回し)。 | 要検索 |
| "Typestate via Revocable Capabilities" (arXiv 2510.08889) | arXiv番号のみ確認済みで、URLは要検索です。 | 要検索 |
Kubernetes resourceVersion | Kubernetes公式ドキュメント, "API Concepts: Efficient detection of changes", https://kubernetes.io/docs/reference/using-api/api-concepts/ | — |
| Raftコンセンサスアルゴリズムのterm番号 | Diego Ongaro, John Ousterhout, "In Search of an Understandable Consensus Algorithm", USENIX ATC 2014 | (第9章) |
| Gaffer On Games | Glenn Fiedler, "Gaffer On Games"(ネットコード分野で広く参照される個人技術ブログ), https://gafferongames.com/ | 個別記事の直リンクは要検索です。 |
| GGPO | GGPO開発チーム, "GGPO Rollback Networking SDK", https://github.com/pond3r/ggpo | — |
Bevy Tick | Bevy公式ドキュメント, bevy_ecs::component::Tick, https://docs.rs/bevy_ecs/latest/bevy_ecs/component/struct.Tick.html | — |
crossbeam-epoch | crossbeam-rsプロジェクト, https://docs.rs/crossbeam-epoch/ | epochという語は共通ですが別問題です(false friend)。 |
slotmap / generational-arena | それぞれのcrates.ioページ、https://docs.rs/slotmap/ 、https://docs.rs/generational-arena/ | 値の構築自体は型で制限していません。 |
GhostCell / generativity | Joshua Yanovski et al., "GhostCell: Separating Permissions from Data in Rust"(ICFP 2021)、generativity crateドキュメント | 世代カウンタとの組み合わせ例は未確認です。 |
| Peter Ferrie, アンチデバッグ手法集 | Peter Ferrie, "The Ultimate Anti-Debugging Reference", 2011年初出・以降改訂 | 原典URLは要検索です。 |
| F5/NGINXの受動的ヘルスチェック | F5公式ドキュメント「Passive Health Monitoring」、NGINX公式ドキュメント「passive health checks」 | — |
| チョード式キーボードの特許(US4,680,572) | United States Patent 4,680,572 (1987年登録) | — |
| QMKファームウェアのtap-hold機能 | QMK公式ドキュメント, "Tap-Hold Configuration Options", https://docs.qmk.fm/tap_hold | — |
| Rodney Brooks, Subsumption Architecture | Rodney A. Brooks, "A Robust Layered Control System for a Mobile Robot", IEEE Journal of Robotics and Automation, 1986 | — |
| Joint Detection and Estimation理論 | 信号処理分野における、検出(detection)と推定(estimation)を同時に扱う理論の総称。個別の代表論文は要検索です。 | — |
| Gary Bernhardt, "Functional Core, Imperative Shell" | Gary Bernhardt, "Boundaries"(講演、2012年、Destroy All Software) | 講演URLは要検索です。 |
| Android ANR(Application Not Responding) | Android公式ドキュメント, "Keep your app responsive", https://developer.android.com/topic/performance/vitals/anr | URLは要検索です。 |
| Kubernetes readiness/livenessプローブ | Kubernetes公式ドキュメント, "Configure Liveness, Readiness and Startup Probes", https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ | — |
| TCP再送タイマーとKarnのアルゴリズム | Phil Karn, Craig Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM 1987 | — |
| Redux | Redux公式ドキュメント, https://redux.js.org/ | — |
| JavaScript/Python/Rustのasync/await | 各言語公式ドキュメント(ECMAScript async functions、PEP 492、Rust async book) | 個別URLは要検索です。 |
| フライバイワイヤとフライトエンベロープ保護 | 例: Airbus公式資料「Fly-by-wire」解説等 | 個別の一次資料URLは要検索です。 |
| CWE-367 (Time-of-check Time-of-use Race Condition) | MITRE, "CWE-367", https://cwe.mitre.org/data/definitions/367.html | — |
未確認・要確認事項
- 第7章(ImmCross/LINE偽イベント)に対応するADR番号は未特定です。
- 参考文献のうち「要検索」と記した項目は、出版前に原典を直接確認してください。
- 第1・2・3・6・7・8・9・16章に追加した関連研究(フェンシングトークン、ゲームnetcode、 Rustの世代付き型、アンチデバッグ手法、受動的ヘルスチェック、労働安全の階層モデル、 チョードキーボード特許、Subsumption Architecture、ブラウザのイベントループ/Android ANR、 RAIIの他言語比較、Kubernetes readiness/livenessプローブ、TCP再送のKarnのアルゴリズム、 Redux、async/await、フライバイワイヤのフライトエンベロープ保護、CWE-367/TOCTOU等)の 書誌情報は、本セッションでWeb検索を伴わず記憶とmaster-research-logの記述から 記載したものです。URL・年号・巻号等は出版前に一つずつ裏取りしてください。