実験計画と測定方法
本ページは研究001の事前計画と事後追加計画です。測定結果は研究報告PDFを参照してください。
事前実験計画
策定日：2026-10-31。Two Brain / AINTERNET Genesis 0.1。 本計画はこの研究の測定前に記録する。探索的な技術報告であり、査読論文・公開登録ではない。
固定条件
- 既存のLinux実行ファイルを使用し、本体のGoコードは変更しない。
- SHA-256:
872cbb9fa7698e0cefa94cb70f9d7ba6d66457392a14dae179a345477c194a36 - 1台のLinux、127.0.0.1、独立プロセス・保存領域・乱数生成した鍵。
- 接続先は手動登録。外部公開、サイト作成、DNS変更、AIモデル接続は行わない。
- 試験用秘密鍵は一時領域だけに保存し、終了時に削除する。
- seed=20261031。入力・実装・環境・各試行を記録。失敗・未成立試行も残す。
問いと方法
| ID | 問い | 事前に決める試行 |
|---|---|---|
| R1 | サイズによって取得完了時間・資源使用量はどう変わるか | 文章1KiB/64KiB/1MiB、PNG 512²/1024²/2048²。各初回1回、準備2回、測定20回。反復ごとに順序を乱数化 |
| R2 | 同時要求を増やすとどうなるか | 1MiB文章と1024² PNG。1/2/4/8並列、各6バッチ。自動再試行なし。全要求の成功・失敗を記録 |
| R3 | 手動コピーは発行元停止後も引き継げるか | 3/5/8ノード、各3回。隣接登録、取得後の明示再公開、前のノード停止。全段で署名Recordの一致を確認 |
| R4 | 強制停止から復帰できるか | 保存完了後SIGKILL 5回、受信中の一時ファイル観測後SIGKILL 5回。後者はタイミングが成立しなければ未成立として残す |
| R5 | 公開範囲・改ざん検出は維持されるか | 非公開/不存在、明示公開、再配布非自動、公開停止の20反復。本文/署名の各20改ざんをローカル保存領域に注入 |
| R6 | 別言語が同じObjectを検証できるか | Go作成6種類をPythonで検証。公開試験鍵によるPython作成20件をGoで検証。本文/署名各64変異と不正CBORを拒否 |
| R7 | Webのような目録・リンク・更新・データ処理を構築できるか | 公開目録、4件の合成温度データ、画像、非信頼文章。目録検索→取得→単位確認→平均→出典付き回答。ローカルHTTPで同じデータを読み同じ値になるか確認 |
指標と解釈
取得時間はCLIプロセス起動、ローカルIPC、認証済み接続上のHELLO、提供側検証、転送、受信側検証・保存を含む。 初回は「受信側にObjectがない最初の取得」であり、OSキャッシュを消去したcold disk測定ではない。 反復は同じObjectの再取得。既存接続・OSキャッシュ・メモリ再利用が影響する。 中央値、四分位範囲、観測p95（補間値）を報告し、母集団の保証値にはしない。 CPUは2ノードのプロセスCPU時間、RSSは約10ms間隔の観測最大値。CLI・測定器は含まない。 測定器の負荷、共有ホストの揺らぎを排除できない。p値による優劣の断定はしない。
R2は同じ受信ノードへの同時要求であり、独立クライアント数の試験ではない。 R3は自動経路切替・自動複製ではない。単一ホストでの最大8プロセスであり世界規模を示さない。 R4のSIGKILLはOS/電源故障ではない。送信ACKの永続化耐性も電源断までは示さない。 R5の同じエラーは時間差による漏洩がない証明ではない。署名は事実性を証明しない。 R6はObject形式だけの相互運用でありPython版P2Pノードではない。 R7の目録・検索は研究用アプリケーションであり未実装DISCOVER/QUERYの代わりに実装済みと主張しない。 JSONは文章Objectの本文。P2P制御形式はCBORのまま。処理は固定ルールでAIモデルではない。 HTTP対照は機能比較。実装言語、TLS、署名、保存条件が同じでない速度比較は行わない。
成果物
日本語PDF、編集用HTML/Markdown、図、試行CSV/JSONL、環境情報、再実行スクリプト、 独立検証器、公開可能な合成データ例、限界と0.1.x/0.2への提案。 研究の結果はローカルに置き、公開・ドメイン設定・企業への連絡は別途扱う。
R8 — 同時要求の上限を踏まえた事後追加実験
追加理由：study-01のR2で、8並列96要求のうち48要求が失敗した。 事前計画の結果を受けた探索的追加であり、事前仮説の検証と混同しない。 本体の処理枠数やエラー処理は変更せず、研究用クライアント側だけで順番を待たせる。
- データ：R1と同じseedによる1024² RGB PNG（約3MiB）。
- 1バッチ32件を一度にキューへ投入する。ワーカー数2/4/8、各3バッチ。
- 計288要求。条件順序はseed=20261031で乱数化。自動再試行なし。
- 完了時間はキュー投入から計測する。取得処理だけの時間と区別して記録する。
- 観測：成功率、バッチ完了時間、キュー待ち込みの中央値/p95。
- これは同じ受信ノードのアプリ側制御であり、世界規模の公平性・負荷制御ではない。
- R1〜R7の結果を書き換えず、別ディレクトリに保存する。