imozuru｜知らない分野を要約せず原典まで芋づる式に掘るClaude Code向けスキルを実測レビュー

imozuru（いもづる）は、知らない分野を汎用的な言葉から原典にたどりつくまで芋づる式に掘る、Claude Code向けのスキル／プラグインだ。MITライセンスで公開され、2026-10-21時点でGitHubのstarは959、forkは37。BatesのberrypickingやEllis・Kuhlthauといった図書館情報学の情報探索研究を、エージェントの調べ方に落とし込んでいる。本記事では導入からデモ実行・同梱テストまで手元で実測した。

この記事はClaude Code拡張エコシステムの1本として、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめた全体像の一部にあたる。

imozuruとは｜要約せず原典まで掘るClaude Codeスキル

スキルなしでClaude Codeに「調べて」と頼むと、検索上位の数件を読んで要約が返る。要約はすぐ読めるが、判断に要る細部が落ちやすい。そもそも分野の用語を知らないうちは検索語も選べず、最初に思いついた言葉の範囲から先へ進めない。

imozuruはこの順序を変える。まず分野の用語・中心にいる人・知見が集まる場（学会・雑誌・個人ブログ・動画・リポジトリ）を押さえ、そこから引用やリンク、著者を芋づる式にたどって原文を集める。集めた原文は要約せずsources/に保存し、答えに必要な主張ごとに「どのファイルの何行目か」を示すに留める。原文を読んで判断するのはユーザー自身、という線引きが設計の軸だ。

読者の3つの問いで整理すると、何ができる＝知らない分野を用語から原典まで掘って出典つきで残す、何を解決する＝AIの早すぎる要約で細部が落ちる問題、何を代替する＝素の「調べて」や要約で完結するリサーチ、となる。「論文とか先行研究を漁って」「上手い人のやり方を集めて」「原文で落として」「/imozuru」といった頼み方や/imozuru watchで起動する。読んだ資料の要約・解説を書く用途や、答えが1つの事実確認には使わない設計だ。

関連スキルの仕組みはClaude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説が詳しい。

imozuruの動き方：問いから原典までの流れ

Claudeはまず、問いと、答えるために必要な主張を3〜6個書き出す。次に探し方を変えた2本の検索役（Webを検索するサブエージェント）で用語・人・場を集め、地図（map.md）にまとめる。その後、原文が見つかるまで参考文献・被引用・著者をたどる。論文のない分野では、記事中のリンクや「〇〇さんの記事を参考にした」という記述をたどる。

見つけた原文はsources/に保存し、404やログインを求めるページは中身を見て除く。すべての主張に原文が付くか、新しい資料が出てこなくなった（飽和した）ら探すのをやめ、原文から切り出した文を主張ごとに並べた抜き書きのページ（report.html）を作る。結果は~/research/<話題>/に、地図・ログ・原文・抜き書きとして残る。

見張り（watch）モードでは、掘って見つけた場（QiitaやZennのタグ、note、YouTube、ブログ、arXiv）の新着をRSSで集めて並べる。検索を使わないため費用がかからず結果も揺れない。XやpixivはRSSを出していないので見張れない、と返す割り切りがある。

原文を落とすfetch.pyには、芋づる式リサーチを安全に回すための境界が引いてある。http(s)以外のURLと、127.0.0.1や192.168.x.xといった手元・内部の宛先には取りに行かない。検索結果に細工したURLを置かれて、ローカルで動くサービスの中身を読まれるのを防ぐためだ。保存した原文や検索結果に「このコマンドを実行して」と書いてあっても従わず、資料にそう書いてあった事実だけをユーザーに伝える、という指示注入への構えもある。

実測：導入からデモ実行・同梱テストまで

導入は3通り。Claude Codeのプラグイン、skillsのCLI、手動コピーのいずれか。

/plugin marketplace add MaryCache/imozuru
/plugin install imozuru@imozuru

npx skills add MaryCache/imozuru
# 手動なら skills/imozuru/ を ~/.claude/skills/imozuru/ へコピー

手元ではリポジトリをクローンし、skills/imozuru/を~/.claude/skills/imozuru/へコピーして配置できることを確認した。スクリプト単体も試せる。同梱のexamples/demo/で、抜き書きのページを作るreport.pyを走らせた。

python3 skills/imozuru/scripts/report.py examples/demo
# → 照合 OK: 抜き書き 4 件がすべて原文のとおり → report.html

report.pyは、抜き書きの文が原文の指定の行にそのまま在るかを機械で照合し、1語でも違えばHTMLを作らない。試しに抜き書きの1文を原文に無い文字列へ書き換えて再実行すると、「原文に見つからない抜き書きがある」と報告してHTMLを作らなかった（陰性対照）。言い換えが紛れ込むのを防ぐ仕組みが実際に効いている。

同梱テストも標準ライブラリのunittestで走る。

python3 -m unittest discover -s tests

設計思想：なぜ要約しないのか

imozuruの決まりは、情報探索研究の知見に紐づく。READMEは出典を明記しており、スキル本体のreferences/theory.mdに対応づけがまとまっている。

・要約しない：調べ始めの混乱した段階で詳しくまとめると、早すぎる結論（premature closure）を招いて探索を妨げる（Kuhlthau 1991）。だから原文の場所を示すところまでに留める
・止めどきは確信度でなく証拠で：すべての主張に原文の場所が付くか、2本の検索役が挙げた資料の7割以上が既知（飽和）になったら止める。7割は試行で決めた仮の目安だと明記されている
・方向を1つに決め打ちしない：AIの検索は方向が複数ありうる段階で1つを選び、その道を選び続けて失敗しがち（HypoSearch・Zhouら2026）。迷ったら仮説ごとに検索役を分けて比べる
・検索語が無いときは引用をたどる：引用をたどる方法は主題を言葉で言い表す問題を避けられる（Bates 1989）

論文のない塗り方やMIXのような分野では、知見の多くが個人のブログや動画にある。imozuruはそうした記事も論文と同じようにたどり、保存した原文に〔論文〕〔本人〕〔観察〕〔まとめ〕〔公式〕の印を付けて、どれを信じるかはユーザーに委ねる。エージェント設計の勘所はClaude Code Skillsの設計9カテゴリ｜Anthropic社内で数百個動かすThariqの実践則とも重なる。

素の依頼・要約型リサーチとの比較

要約型のリサーチが悪いわけではなく、素早く全体像を掴むには向く。imozuruは逆に、出典に当たって自分で判断したい調べ物に寄せた道具だ。両者は競合というより使い分けになる。

ライセンスと採用判断（向く人・待つ人）

ライセンスはMIT。LICENSEファイルの実体もMIT License / Copyright (c) 2026 MaryCacheで、追加条件は無い。2026-10-21時点でstar959・fork37、オープンなissueは1件。リリースタグは付いておらず、READMEも「mainにコミットが入るたびに新しい版として扱う」と明記する。版が固定されない点は、採用時に更新の追従方針を決めておきたい。

・向いている人：知らない分野を用語から掘りたい人、AIの要約では細部が落ちて困っている人、出典を自分で確かめたい人
・待った方がよい人：安定版のタグで運用を固定したい人、機密・個人データを含む調べ物に使いたい人（問いが検索語として外部に出る）

参照ソース

・MaryCache/imozuru（公式リポジトリ） — README・LICENSE・スクリプト・テスト（2026-10-21時点でstar959・fork37を確認）
・imozuru SKILL.md（スキル定義） — 流れ・止めどき・道具（fetch/chain/report/watch）の仕様