# fxir.jp 全ページ監査報告書 **対象**:https://fxir.jp/ 全公開ページ(HTML 55、sitemap収載URL 97、公開JSON/正本.md/コード含む) **基準**:為替介入研究所 会則 v1.0 **前回報告**:AUDIT-2026-08-08-R1(CRITICAL 3・HIGH 3 是正確認済) **監査日**:2026年8月12日(JST) **版**:AUDIT-2026-08-12 / v1.0 --- ## 0. 結論 | 区分 | 件数 | 内容 | |---|---|---| | CRITICAL | 4 | 検証手順が実際に破れているもの(ハッシュ不一致・台帳リンク誤り・OTS未確定の断定・AI回答のFACT表示) | | HIGH | 8 | 表示崩れ(全ページ)・数値の同日矛盾・存在しない研究の告知・APIドキュメントの誤り 等 | | MEDIUM | 15 | 証拠区分の脱落・二次資料の断定利用・条番号誤引用・更新漏れ 等 | | LOW | 9 | 表記ゆれ・索引漏れ・軽微な鮮度 | 前回監査(8/8)以降の4日間でサイトは 26ページ → 55ページへ拡張された。前回指摘の N-1(159.483/159.481 不一致)は**是正済み**を実測確認した。一方、**拡張のスピードに検証系(HASHES.txt・registry.json・provenance.json・status.json・sitemap)の更新が追いついていない**のが今回の指摘の中心である。 特に **C-1 は「curl して sha256sum せよ」という当研究所自身の検証手順が、実際に実行すると失敗する状態**であり、会則第24条・第66条の核心に触れる。 レスポンシブについては、**日本語全41ページがスマートフォン幅で横スクロールを生じ、英語・中国語14ページは幅375pxの端末で561px(+49%)に広がる**という、サイト全体に及ぶ構造的な不具合を検出した。 --- ## 1. 監査方法 | 検査 | 方法 | |---|---| | ページ棚卸し | sitemap.xml の97URLを全取得(全て200)。HTML内の全 href/src を抽出し内部1,945参照・外部383参照を解決 | | リンク切れ | 内部URL 120件・外部10ドメインへHTTPステータス実測 | | レスポンシブ | Chromium(Playwright)で **320 / 375 / 768 / 1440px** × 55ページ = 220通りを実測。DOM上の要素境界・`innerWidth`・`scrollWidth`・コンソールエラー・失敗リクエストを取得 | | ハッシュ検証 | 掲示値と `curl \| sha256sum` の実測値を突合 | | 存在時刻証明 | 公開リポジトリ `github.com/fxirjp/fxir.jp` をクローンし、`git log` と `ots info` / `ots verify` を実行 | | 会則適合 | 会則 v1.0 全68条に照らして全ページ本文・公開JSON・正本Markdownを検査 | > レスポンシブ計測について:当サンドボックスのブラウザから fxir.jp へ直接到達できなかったため、**公開HTMLをそのまま取得したローカル複製(live取得のHTML+live取得のJSON)** に対して計測した。HTML・CSS・JSは配信物と同一バイトである。この制約は結果に影響しないと判断するが、事実として記録する(会則第58条)。 --- ## 2. CRITICAL ### 🔴 C-1 `docs/HASHES.txt` の2件が配信ファイルと不一致 — 検証手順が実際に失敗する **関係条文**:第24条(再現可能性)、第27条(改ざん検知)、第28条(データ来歴)、第66条 N-006 の一次CSV 2本について、掲示ハッシュと配信ファイルの実測が一致しない。 | 対象 | 掲示値(HASHES.txt) | 実測値(curl + sha256sum) | |---|---|---| | `data/swap_hirose_usdjpy_daily.csv` | `e4b3e75a80539df3…52a55` | `29d1d8a3c35adb74…7fa71` | | `data/swap_ig_usdjpy_daily.csv` | `0bb48db24a0d6406…3440d` | `13c4ddd279914805…5cf93` | **原因**:掲示値はリポジトリ側の **CRLF版**(32,457B / 49,708B)に対する値。配信されているのは **LF版**(30,998B / 47,683B)。`tr -d '\r'` を掛けると両者はバイト一致する。FTPSデプロイのASCIIモード変換が有力(推定)。 **なぜCRITICALか**:読者が指示どおり検証すると**必ず不一致になる**。サイト全体で唯一、「DON'T TRUST, VERIFY.」が実行不能になっている箇所である。他の27件中25件は実測一致しており、この2件だけが例外。 **是正案**:リポジトリ側CSVをLFに正規化 → `HASHES.txt` を**配信バイトから**再生成。デプロイをバイナリ転送に固定し、CIに「配信物 vs HASHES.txt」の突合を必須ステップとして追加する。訂正記録(corrections.json)にも登録する。 --- ### 🔴 C-2 `registry.json` の N-006 が N-004 を指している **関係条文**:第28条、第32条、第24条 ```json "id":"N-006", "sha256":"a9feda58ac2b6680…", ← docs/n-006_v1.0.md のハッシュ(実測一致) "links":{ "html":"n-004.html", "md":"docs/n-004.md", ← 実測 ce06ff38… で掲示SHAと別物 "claims":"data/verify/N-004-claims.json" } ``` 研究台帳(registry.html)と英中版 research.html は registry.json をそのまま描画するため、**N-006 の行をクリックすると N-004 が開く**。かつ台帳上でハッシュとファイルが食い違う。`data/verify/N-006-claims.json` は 404(N-006 に claims は存在しない)。 **是正案**:`links` を `{html:"n-006.html", md:"docs/n-006_v1.0.md"}` に修正、`claims` を削除、未使用キー `link` を除去。`version` を `"v1.0"` → `"1.0"`(他エントリと表記統一)。 --- ### 🔴 C-3 OpenTimestamps は Bitcoin 未確定なのに「固定されています」と断定 **関係条文**:第10条、第11条第3項(UNVERIFIEDをCONFIRMEDへ変更する禁止)、第35条 verify.html の記述: > 「初回コミット(`05a9fa1f…6582`・2026-08-12)の存在時刻は PROOF.md への OpenTimestamps 刻印(PROOF.md.ots)で**ビットコインのブロックチェーンに固定されています**。」 **実測(`ots verify` / `ots info` を実行)**: - `PROOF.md.ots` の対象ハッシュ `0dd8f11ec2924661…` は現行 `PROOF.md` と一致(対象の取り違えはない) - attestation は **すべて `PendingAttestation`**(bob / alice / catallaxy / eternitywall の各カレンダー) - `ots verify` 出力:`Pending confirmation in Bitcoin blockchain` - **Bitcoin ブロックへの attestation は1件も収録されていない** すなわち現時点で「ビットコインに固定」は成立していない。カレンダーサーバへの提出は完了しているため、確定は時間の問題だが、**未確定を確定と表示している**点は第11条に抵触する。前回監査でこの項目は「未実施と明示」により第58条を満たしていたものが、今回は逆方向に振れた。 **同一ページ内の自己矛盾も併存**:verify.html が読み込む `data/verify/WP-001.json` の `external_anchor` は今も「**未実施(現状は自己掲示のみ)**…実施予定」のままで、静的HTML部分は「刻印済み」と表示する。**同じ画面に「未実施」と「実施済み」が同時に出ている**。 **是正案(文案)**: > 「初回コミット(`05a9fa1f…6582`・2026-08-12)の存在時刻について、PROOF.md への OpenTimestamps 刻印を**申請済み(`PROOF.md.ots`)**。現在の状態は**カレンダー受理・Bitcoin確定待ち(PENDING)**であり、確定後に `ots upgrade` した .ots とブロック高を掲示する。現時点で第三者が検証できるのは『カレンダーサーバが当該時刻に受理した事実』までである(会則第11条)。」 あわせて `data/verify/WP-001.json` の `external_anchor` を実状に更新する。 --- ### 🔴 C-4 AIチャットの回答自体に `FACT` バッジが付き、コピー時に証拠状態が脱落する **関係条文**:第14条(AI出力の事実認定禁止)、第11条、第15条 `assets/fxir-chat-page.js` は各AI回答バブルに `{state}` を描画し、`state` は API 応答(=AI自身の出力)由来。CSSに `.cv-chip.FACT` が定義されており、**AIの回答に FACT 表示が到達しうる**。 さらにコピーボタンの生成文字列は `answer + sources + location.href` のみで、**証拠状態バッジも「AI生成である」旨の注記も含まれない**。ai.html が「証拠状態を落として引用しないでください」と求めているのと自己矛盾する。 **是正案**: 1. サーバ側で AI 回答の `state` を `ESTIMATE / HYPOTHESIS / UNVERIFIED` に制限し、`FACT` は**参照した正本の証拠状態として出典行にのみ**表示する 2. チップ直下に恒常表示:「このバッジは参照した正本の証拠状態であり、AIの回答そのものの正しさを示さない(会則第14条)」 3. コピー文字列の先頭に固定文言を挿入:`【AI生成・未検証】…証拠状態: ` 4. `SPEC-CHAT v0.1`(システムプロンプト・参照コーパス範囲・state決定ロジック)を公開し、「AIは数値を補完しない」(第15条)の**検証手段**を第三者に与える --- ## 3. HIGH ### 🟠 H-1 日本語 全41ページがスマートフォン幅で横スクロールする **実測**:`viewport 375px` に対し `document.scrollWidth = 409px`(+34px)。`viewport 320px` では `408px`(+88px)。**JA全ページで同一**。 **原因(特定済み)**:グローバルナビ `