評価の訂正（2026年10月27日）
以前の「本家imozuruの再現に成功」という評価は撤回しています。 Codexが検索役に本家・利用者の指定にない「最大2〜3クエリ」「候補4資料程度」の上限を設定し、深掘りを縮小しました。原文19件と引用照合は旧試験の事実ですが、本家の調査品質・手順忠実性の証明にはなりません。
比較環境に再発防止の指示と証跡検査を追加しました。是正の記録を参照してください。修正後の実調査は未検証です。
IMPLEMENTATION REVIEW
本家imozuruと
自作「芋づるラボ」の差
コードが動くことと、調査が成立することは違う。実装・本番D1の成果物・Codex Cloudでの本家直接実行を突き合わせ、何ができて何ができていないかを整理した。
まず結論
芋づるラボは本家imozuruの同等実装ではない。 本家の取得・追跡・引用確認スクリプトを使いながら、独自の状態管理とローカルLLMの制御を上から重ねている。その接続部分に、本家の「問いを更新し、証拠で止まる」という核心を損なう問題がある。
一方、本家スクリプトをCodex Cloudで呼び出した旧調査は、原著までたどりレポートを完成させている。モデル・環境・実行方法が違うため、これだけでQwenやローカルPCの性能が劣ると断定はできない。
本家・ローカル版・Cloud版の違い
| 比較対象 | 本家imozuruの設計 | 自作ローカル「芋づるラボ」 | Codex Cloud旧調査（指示逸脱あり） |
|---|---|---|---|
| 出発点 | 分野を異なる2方針で探り地図を作成 | 新規地図作成が長時間化。8検索・62ヒットで中断、原文0本 | 2本の検索役で地図を作成し原文19件へ進行 |
| 問いと論点 | 原文を読み直して変更可 | 最初の論点は変更できず、継続指示全文が新しい論点になる | 6論点を設定して原著で満たす。独立した変更操作の有無は不明 |
| 原文の追跡 | 著者・参考文献・被引用・記事リンクを追う | 道具はあるが重い新規調査での一巡は未確認 | 原著・著者・日本語記事リンクの追跡を記録 |
| 終了条件 | 充足・証拠ある飽和・4周・取得不能・利用者が指定した上限 | 独自の2時間／検索48回／取得80回。検索失敗で飽和誤認の再現あり | 原文の引用で6/6論点を充足して終了。独自時間上限なし |
| 原文の品質 | 取得した本文をチェックし不完全なら失敗と記録 | 独自PDF救済は200文字で成功とし得る | 本家fetch.pyを使い、保存資料19件。完全な内容検査は別問題 |
| 解説と引用 | 原文を保全して引用付きの読者別解説 | 実出力に?NNNの説明逆転。自己意味監査も支持ありと判定 | 引用文字列25件・説明60文をチェック。内容監査はCodex本人による |
| 運用機能 | 調査フォルダ、閲覧、watch | Cloudflare、Slack、永続保存などを追加（強み） | Cloudで結果をGitHub保存。ただし直接読めるURLの案内が欠けていた |
ローカル版は2026年10月27日の固定コードと本番D1結果を使用。Cloud版は2026年10月27日の専用タスク成果物を使用。
本当に修正すべき6つの点
01 終了条件を勝手に変えた
本家は「依頼に時間・回数上限がある場合」のみ約束による打ち切りを認める。ローカル実装はelapsed ≥ 7200秒をハードコード。最新D1継続調査はこの上限で停止した。ユーザーの明示した上限ではない。
確認根拠・実装箇所を開く02 継続時に作業指示が論点へ混入
ローカル実装では継続依頼の全文を新しい論点として追加する。最新のD1結果では、原文調査とは別の「通知まで」等を含む指示文が第4論点となった。3/4充足という分母自体に問題がある。
確認根拠・実装箇所を開く03 検索失敗を調べ尽くしたと誤認できる
1方針で既知1件、もう1方針はタイムアウト0件、新語が増えて未充足でも、局所再現では飽和100%で終了した。失敗・新語・探索した仮説の違いを終了判定が十分に扱っていない。
確認根拠・実装箇所を開く04 新規の地図作りが未完走
細分化した実行制御は原文追跡段階から。初期地図の重い生成はその対象外で、実際のTransformer調査は原文0本のままレビュー待ちで停止中。継続版SQLiteの成功は、新規調査開始の成功を示さない。
確認根拠・実装箇所を開く05 誤訳を「根拠あり」とした
SQLiteの?NNNを「数字NNNの後に疑問符」と逆に説明していた。引用したSQLite原文は正しい順序なのに同一モデルの意味監査が支持ありと判定。文字列一致と意味の正確性は別物。
確認根拠・実装箇所を開く06 原文取得の救済基準が緩い
本家がPDF取得失敗とした場合、独自のpypdfルートで200文字以上抽出できれば成功扱いにできる。長文PDFの一部だけが取れた場合にも完了と判断する危険がある。
確認根拠・実装箇所を開く旧Cloud調査で確認した事実と不合格理由
本家スキルの29ファイルは固定版と一致する一方、検索役に独自の探索件数上限を課したため、本家に忠実な比較試験とは認められない。標準Web検索と本家のfetch.py、chain.py、report.py、digest.pyを使い、原文19資料、11検索語、9検索記録、追跡を含む15記録を保存した。終了理由は「全6論点に原文位置と引用を付けたため充足」であり、独自の2時間上限ではない。
原文照合の例として、FlashAttentionの原著Theorem 1には、演算量がO(N²d)のまま、入力・出力以外の追加メモリをO(N)とする記述がある。この区別はレポートでも維持されている。一方で、実行を独立した第三者が全文査読したわけではない。意味監査は実施したCodex自身の点検で、19本の収集だけで「調査品質が保証された」とは言えない。
「調査ができた」ことと「利用者が読める形で渡した」ことも別。これまでHTMLを非公開GitHubへ保存しただけで閲覧URLを用意せず、利用者の受け取りまで完了できていなかった。本ページと読者別レポートは、閲覧経路を修正するための別の公開物である。
完成判定をどうやり直すか
第一に独自の2時間・48検索・80取得を「約束の上限」と扱うことをやめ、明示された利用者条件とシステムの安全制限を別に記録する。第二に継続依頼を作業指示と研究上の問いに分離し、論点の更新を可能にする。第三に検索失敗と新語が増えたときの飽和終了を防ぎ、初見テーマの0周から原文取得・追跡へ進める。第四に意味監査の誤判定、PDF不完全取得、旧版参照、Slack障害の巻き込みを回帰テストで防ぐ。
現段階の評価：便利な調査基盤の試作としては成立。ただし本家imozuru互換の自律調査エンジンとしては未完成。
今回の旧版を合格例にせず、同じ問いを同じ終了基準で両方に与え、原著到達、手がかりの展開、未確認点の記録、引用の意味、終了理由、停止・再開を比較して初めて「改善した」と判断できる。検索ヒット数やレポートの文量だけで順位を付けない。
元の資料へ戻る
読者別レポート（Lv1／Lv2／Lv3、ブラウザ閲覧） ／ Cloud調査ログ ／ 詳細なコード監査記録 ／ 本家imozuruの仕様