作成日：2026-10-19。状態：計画作成済み。AI による単独の内部レビュー（裁定者・指摘者・レビュアーが同一、独立性なし）を実施済み（記録・追補・完了記録）。独立レビューは未実施で、外部の確認者が得られた時点で G0 から再開する。以下は作成時（独立レビュー前）の計画で、本文は変更していない。作成者側の 証明義務の整理 と 事前監査 を参考資料にし、独立した判断を別途記録します。この計画の作成や追加監査の通過を、独立レビューの完了とはしません。
2026-10-20 運用方針の更新：利用者の指定により、現在のリポジトリは独立の確認者を置かずに進めます。以下の計画は将来、英語で記述する別リポジトリで、確認が必要な時点から再開するための資料として保持します。現在の進行条件にはしません。決定記録 を参照してください。
1. 目的と対象
最終目標は、将来の変化に原理的に耐える医療コード体系の確立です。今回は、その基礎として採用した限定した保存条件について、前提を満たす入力を誤認定しないか、前提の欠落を検出できるか、保証の説明が実装と一致するかを確認します。
| 対象 | レビューする範囲 | 今回の合格に含めないこと |
|---|---|---|
| 理論 | S1/S2、C1の充足対応・モデル被覆・割当、R1の採用、有限合成、射影の喪失 | 任意言語の完全判定、無限更新の極限、体系の普遍性全体の証明 |
| 実装 | 認定器、依存・所有者・型検査、参考意味、履歴、同一事象の結合、資源停止 | 外部処理系の保証、性能優位性、実運用可用性の実証 |
| 期待結果 | P0の22条件/37 JSON/221必須パス、P1の20条件/80 JSON/417必須パス | 医学的正解ラベル、未見性能、R4の架空40件への合格 |
| 表現と説明 | 予測/臨床肯定、支持/非含意、原保存/再実行、新側保証、認定範囲の区別 | 臨床ライブラリの操作性、AIモデルの精度、実体系への対応完了 |
今回の架空例に患者情報や外部マスターを追加しません。実資料・医学的正解のレビューへ進む場合は、D03とR4の条件を別途適用します。
2. 固定する基準とレビュー資料
開始基準はコミット e73d4bab30cbb40b9354724c361610d5c22033c1（P1-d）。共通manifestのSHA-256は 1f01ed6593f555b42e370661c225fac1012bdf89b115bc29fd91513474d35efb、168ファイルの束は 561ef3924483c4f36c0ec3edec571979dd2418a880ac84320c70bfe7f36ef864 です。固定結果 と一致することを開始時に確認します。
資料は、AGENTS/vision、R5の原理、P0契約、P1設計契約と20条件、P1-a/b/c実行契約、P1-d評価契約・manifest・実例、runtime・テスト・評価スクリプトです。これに本計画、PO01〜PO12、追加監査script/test/resultsを添えます。追加資料はP1-d後の別成果物なので、レビュー開始時にそのコミットと生バイトhashも記録します。基準の168ファイルと追加監査の束を混同しません。
Git管理外の過去ログが手元になくても、固定コミットから再実行して記録を作れます。過去ログを受領した場合も、HEAD・実体hash・結果・実行コマンドを確認します。作成者の説明や「通過した」という要約だけを判定根拠にしません。
3. 役割と独立性
| 役割 | 必要な観点 | 担当状況 |
|---|---|---|
| 意味・証明の確認者 | 一階のモデル意味、定義拡張、量化と変数割当、反例、前提と結論の区別 | 未割当 |
| 実装・評価の確認者 | Python、JSONの型、依存閉包、履歴・問い合わせ、再現性・資源停止 | 未割当 |
| 作成者 | 設計意図と実体の提示、指摘への回答、修正案・反例・再実行記録の作成 | 現在の開発側。自分の作業を独立確認済みにしない |
| 裁定者 | 根拠と反例を確認し、解消しない意味判断を裁定 | 不一致が出て当事者間で解消できない場合に割当 |
一人の独立レビュアーが最初の二役を兼ねる場合は、両方の能力と確認範囲を記録します。作成者との設計・実装・期待結果作成への関与を申告し、自分が作成した対象の唯一の承認者にはしません。別のAIによる確認を用いる場合も、利用者が認めた担当と範囲、共有した作成者情報、確認方法を記録します。別実行や別スレッドという理由だけで独立性を認定しません。現時点で人・AIとも割当や承認を受けたという記録はありません。
4. 実施順と開始・終了条件
| 段階 | 実施内容 | 残すもの・次へ進む条件 |
|---|---|---|
| G0 資料固定 | 担当・独立性・対象・コミット/hashを確認。隔離した作業場所を用意 | 記録様式 の開始欄。対象実体が固定できない間は開始しない |
| G1 意味のレビュー | POごとに前提・結論・導出を再構成。実装結果を見る前に反例と期待条件を記す | 全12 POの判断、反例候補、未解決点。作成者の期待値に合わせる前の記録を保持 |
| G2 実装のレビュー | 下記の重点経路を読む。G1の期待と実装を比較し、新たな負例を作る | コード位置・再現入力・期待・実際・根拠を持つ指摘台帳 |
| G3 再現・追加検証 | 固定20/22条件、全必須パス、API/CLI、開発テスト、必要な追加例を実行 | 環境・コマンド・終了コード・hash・分母・全文ログ。失敗を除外して再集計しない |
| G4 裁定と修正 | 指摘ごとに合意/不一致/保留を判定し、修正理由と再確認範囲を決める | 修正前後の版・入力・結果、不一致の根拠。未解消の重大指摘は合格にしない |
| G5 正解凍結 | 独立確認を終えた期待結果と適用範囲を別版として固定 | 確認者・承認日・裁定・新manifest。旧作成者snapshotと独立確認済み版を併存 |
カレンダー日程と所要時間は担当割当後に決めます。まずG0、次にG1/G2、G3、G4/G5の順で進め、仕様変更や重大な反例が出た場合は該当段階へ戻ります。作成者側の追加監査はG1〜G3の代替ではありません。
5. 必ず確認する経路と反例
| 優先 | 対象 | 必須の問い・反例 |
|---|---|---|
| 最優先 | PO01/02、validation.py・definitions.py | 旧側だけで依存を解決できるか。新記号の共有・上書き・循環・隠れた追加包含・新所属データで認定の前提が崩れないか |
| 最優先 | PO04〜07、ledger.py・events.py・handover.py | 同一zの四役割か。完全履歴と採用が可換か。原/中間/最終の実体、依存、方針、翻訳後Qを検査しているか。再hashした改変でも拒否できるか |
| 最優先 | PO03/09、query.py・各上限処理 | 未決/否定/衝突/未知能力/打切りを混同しないか。未確認や訂正済みの未知能力も落ちないか。部分結果を完全回答にしないか |
| 高 | 参考意味、reference.py | 充足対応だけで被覆を認定しないか。匿名の存在から名前付き事実を捏造しないか。有限一致・反例なしを一般証明にしないか |
| 高 | PO08、projection.py | 同じ射影値で異なる旧回答を返す二記録を扱えるか。二段目の無損失や別添えを全体の復元と混同しないか |
| 高 | PO10/11、forecast.py・archive | 1/1予測を臨床肯定にしないか。確認は報告の確認か。旧runtimeのバイト保存だけで解釈・実行可能にしないか |
| 高 | PO12、評価器・説明文書 | 型付き比較・全件数・P22相互関係・入力保持を確認できるか。全部棄権でも通る評価になっていないか。証拠の強さと認定範囲が合うか |
この表はコードの一部を読むだけの許可ではありません。認定・入力検査・停止の各分岐と、その分岐が依存する実装を全て確認します。少なくとも上記の主要関数は全文を確認し、各受入条件の全入力・期待パスを照合します。各分岐に確認例がない場合は、追加例または範囲を限定する理由を記録します。
事前監査の PR01 も確認します。逆向きの関係を使う存在規則から存在を導けても、現行handlerはunassessedに留めます。まず仕様通りの限定と、説明上の不足を判別し、推論範囲を広げる変更の要否を別に判断します。限定を明示した未対応を、直ちに誤った非含意や誤認定と同じ欠陥として数えません。
6. 再現手順
既存作業を保持したうえで、リポジトリから別のworktreeを作ります。
git worktree add --detach ../med-dsl-review-e73d4ba e73d4bab30cbb40b9354724c361610d5c22033c1
cd ../med-dsl-review-e73d4ba
python3 -m unittest discover -s tests -v
python3 scripts/research/evaluate-p1-d.py --cli --output data/research/p1-d/review-baseline
git diff --check
P1-dの231開発テスト、P1 20/20・80/80・417/417、P0 22/22・37/37・221/221とP22相互関係を別々に記録します。Python 3.14.4での既存結果を基準にし、対応下限の3.11での実行は追加確認事項です。環境を用意できなければ「未確認」とし、対応済みへ読み替えません。
今回の追加監査は、追加資料を固定した別の作業場所で実行します。P1-dだけをcheckoutした場所には存在しません。
python3 -m unittest discover -s tests/audits -v
python3 scripts/research/audit-preservation.py --output data/research/preservation-audit/review
追加監査8テストと有限モデルの件数は、既存231テストや20条件の分母へ混ぜません。新しい意味を含む例は、既存の期待結果を書き換えて押し込まず、対象PO・前提・独立した期待・版とともに追加します。
7. 判定基準と指摘の扱い
| 重大度 | 例 | 扱い |
|---|---|---|
| S0 | 無根拠なcertified、誤った含意、未知や未完成を確定、原情報の不可逆な消失 | 該当認定・機能は不合格。範囲の停止/修正と独立再確認が済むまで凍結しない |
| S1 | 必須の前提や証拠の欠落、仕様と実装の意味不一致、再現不能・評価の見逃し | 重要な不一致として解消。根拠が未確定なら保留し合格にしない |
| S2 | 認定範囲に影響しない説明・参照・可読性の不備 | 修正または理由付き保留。保証の解釈に影響するならS1以上へ変更 |
各POは「適合」「修正後適合」「不適合」「未判定」「今回対象外（理由と保証範囲への影響）」を記録します。対象POを後から対象外へ変えて通過数を整えません。全POの判断と証拠が揃い、未解消S0/S1がなく、必要な再現・正例/負例を通り、認定範囲の説明が一致した場合に限り、この限定範囲のレビュー合格とします。
指摘には最小再現入力、期待、実際、PO、コード/仕様位置、根拠、重大度、提案、担当、状態を付けます。不一致は双方の説明と反例を残し、意味の問いは独立した裁定に回します。裁定者も決まらず解消しなければ未判定で止め、その対象を独立確認済みと表示しません。
修正する場合は、レビュー対象の旧コミット・snapshot・実行記録を保持して別版で行い、影響するPOと回帰を再確認します。期待値を変えるなら、実装に合うからという理由ではなく、修正した意味と独立確認者の判断を記録します。--create-snapshot だけでは独立した正解凍結になりません。
8. 完了成果物と、その後
完了時は、担当・独立性、固定実体、全PO判定、指摘/裁定/修正台帳、実行ログ、対象範囲付きの結論、独立確認済み期待結果の版を残します。詳細な外部データは持ち込まず、非公開の方針を維持します。
その後は、未対応意味の形式化、R4の比較実証、臨床ライブラリ・AIの要求検証を別に進めます。今回の合格で、体系の永続性全体や将来の全コード体系への対応を完了したとはしません。