あなたのAIはまだ、「ものの調べ方」を知らない。──調査スキル「imozuru」を作ってバズった話

株式会社パレットリンクの@BaspisKawaEです。
今回は、AIに調べものをさせるスキルを公開したら反応を多くいただいたので、なぜわざわざ調べものをスキルにしたのかを解説します。
よろしくお願いします!

対象読者：AIに調べものを任せていて、答えが物足りないと感じたことがある方
前提知識：なし（情報探索や検索技術の専門知識は必要ありません）
必要な環境：Claude Code、Node.js、Python 3.10以上（入れ方は7章にまとめています）
この記事で学べること：AIの成果が物足りないときに手順を見直す考え方と、情報探索の研究をもとに組んだClaude Codeのスキル「imozuru」の仕組み

すぐに試したい方は、Claude CodeとNode.js、Python 3.10以上が入っている環境のターミナルで次のコマンドを流すと、Claude Codeにimozuruが入ります。

npx skills add MaryCache/imozuru

そのあとはClaude Codeに「芋づる式に調べて: 〇〇」と頼むだけで使えます。
詳細な使い方は7章とREADME¹にまとめています。

リポジトリのリンクはこちら

目次

• 1. 背景：調べもののスキルを公開したら、GitHubで伸びた
• 2. 調べものはAIにもともとできるのでは
• 3. 与えられた手段を作り直す
• 4. AIの答えになぜなぜ分析をかける
  • 4-1. 物足りない答え
  • 4-2. 「AIだから」で思考を止めない
  • 4-3. 実際にやってみた
• 5. 手がかりは情報探索の研究にあった
• 6. imozuruに入れたもの
  • 6-1. 要約させない
  • 6-2. 引用をたどる
  • 6-3. 止めどきを証拠で決める
  • 6-4. 抜き書きを機械で照合する
  • 6-5. 無いときは探した範囲つきで「無い」と言う
• 7. 使い方
• 8. このスキルの限界
• まとめ

1. 背景：調べもののスキルを公開したら、GitHubで伸びた

2026年10月13日に、Claude Codeのスキル「imozuru」をGitHubで公開しました¹。

公開を知らせたXのポストは約85.6万回表示され、リポジトリへのリンクは24,882回クリックされました。

10月25日の時点で、スターは1,225、フォークは55になっています。

IssueとPull Requestも届き、多くの方に支えられながら改善を続けています。

これはもう初めてのことだったので、かなりうれしかったです！
個人開発、OSSの真に面白い部分を知ることができました。

この記事では、なぜわざわざ調べものをスキルとして作り直したのかと、そのスキルに何を入れたのかを書いていきます。

2. 調べものはAIにもともとできるのでは

「調べものくらい、AIは最初からできるのでは？」と思う方も多いはずです。

実際、そのとおりです。
「〇〇について調べて」と頼めば、AIは検索してWebページを読み、まとめた文章を返してくれます。

ただ、どの言葉で検索し、どのページを開き、どこで調べるのをやめるかという手順は、最初からツールに付いてきたものです。
私たちはその仕組みをよく知らないまま、決まった手段として使っています。

3. 与えられた手段を作り直す

生成AIの台頭によって、ツールを作る手間は大きく下がりました。
今なら、毎日使っている手段や、当たり前とされている手順そのものも作り直せます。

当たり前の手段を、決まったものとして受け入れない！

その中でもAIの調べものは、誰もが毎日使い、答えの良し悪しも比べやすい作業です。
与えられた手段を疑って作り直す手始めに、ちょうどよい題材でした。

4. AIの答えになぜなぜ分析をかける

4-1. 物足りない答え

私はフロントエンドのデザイン、色彩理論、映像表現、音の編集といった様々な専門分野の知見を、よくAIに集めさせています。

ところが、どうも物足りないときがあり……。

仕方なく自分で理屈を考えて並べて、「こういう仕組みなのでは？　こういう考え方とか良いんじゃない？」とAIに話すと、今度は求めていた答えにたどり着きます。
一回で求めていたものが返ってくることもあるのですけどね。
感覚として、どうにも安定しません。

……ということは、私の発想はネットに転がっている知見よりすごいのでしょうか？

流石に人類の集合知を舐めるなという話で、そんなはずはないでしょう。
偉大なる「車輪の再発明」という言葉があるように……。
私が思いつくようなことは、たいてい誰かがもう考えて、どこかに書いています。

それなのに、なぜAIはその「どこか」にたどり着けないのでしょうか。
情報処理は得意分野のはずなのですが。

それさえ安定して特定できれば、人類の集合知、形式知を誰でも借りて利用することができるのですが……。

世の中で才能やセンスとして片付けられているものの多くには、決まった答えが導き出されていて理論として確立されている、と私は考えています。
たとえ理論が確立するほどに成熟していない分野だとしても、先人の成功体験、失敗体験の記録だけでも十分な価値があります。

AIで一人ひとりが扱える情報の量が大きく広がった今、これをやらなくてどうする！　……と思ったのが、imozuruの始まりです。

4-2. 「AIだから」で思考を止めない

さてこんなとき、「まあAIだからこんなものだろう、やっぱりまだまだだね」と片付けるのは、現場のトラブルを「担当者の不注意」で片付けるのと同じです。

製造業で知られるなぜなぜ分析²では、問題が起きたとき、人のミスで止めずに、そのミスが起きる手順や環境まで掘り下げます。

この考え方を、そのままAIにも当ててみました。
「なぜ」を3回たどります。

1. なぜ答えが物足りないのか → 原文を開かないまま、検索結果の要約をつなぎ合わせて答えているから
2. なぜ原文を開かないのか → 「調べて」と頼むと、数回検索して出てきた要約をまとめたら終わる手順で動いているから
3. なぜその手順なのか → 最初からツールに付いてきた調べ方を、そのまま使っていたから

見直すべきは、AIが使っているデフォルトの調べ方だと考えました。

4-3. 実際にやってみた

時系列が前後してしまいますが、この見立てが合っていたかどうかは、imozuruを作ったあとで確かめました。
デフォルト調査とimozuruの対照実験です。

プロンプトは「イラストで、明るい面と暗い面の色をどうずらすといいか調べて」です。
「調べて」の一言だけでClaude Sonnet（Web検索あり）に3回頼んだ結果と、imozuruの手順を渡して同じモデルに1回頼んだ結果を比べました。

比べたこと	「調べて」の一言（3回）	imozuruの手順（1回）
開いて確かめた原文	0本（検索結果の要約だけから答えた）	11本（原文から切り出した文32件を、原文の行と照合した）
研究	3回とも「規則は無い」「理論ではない」と結論した	影の中の色の見え方を測った論文に届いた3
意見の食い違い	ほとんど出ない	影の彩度を上げる派と下げる派などを並べた
届かなかったもの	書かない回が多い	有料の本や取れなかったページを一覧にした

少なくともこの比較の範囲では、効果は劇的ですね！！

では、デフォルトの手順の穴をどうやって改善したのか。
次の章からはimozuruを作る前の話に戻ります。

5. 手がかりは情報探索の研究にあった

調べ方を良くする方法としてはじめに思いついたのが、ループエンジニアリングです。
（意味の広い言葉なので補足すると、ここでは「AIに同じ手順を、前の結果を見ながら何度も回させる考え方」という意味で、この言葉を使っています）

まず思いつく一般的な言葉で検索。
その後、ヒットした専門用語や名前の挙がる人でさらに検索し、そこでヒットした用語や人でまた検索する……これを繰り返せばいいのではないかと構想しました。
これは私自身が、キャッチアップの際によく無意識に取っている手法です。

簡単な例を挙げますね。

「夕焼けはなぜ赤いのか」を調べるとします。

1. まず「夕焼け　なぜ赤い」で検索すると、「レイリー散乱」という専門用語が出てきます。
2. 次に「レイリー散乱」で検索すると、空の青さも同じ仕組みで説明できることと、名前の元になったイギリスの物理学者レイリー卿が出てきます。あわせて、雲が白く見える理由として「ミー散乱」という別の用語も出てきます。
3. さらに「ミー散乱」やレイリー卿の名前で検索すると、空の色を扱った元の論文や、大気の光を研究する分野へとつながっていきます。

最初は「夕焼け」という身近な言葉しか知らなくても、出てきた言葉を手がかりに、専門の資料までたどり着けるわけです。

勿論、この程度の例であれば、既存のAI要約調査でも夕焼けの知識を得ることは出来ます。
ただし、この手法であれば「その知識どこで得たの？」と聞かれた際に、「AIに教えてもらった」ではなく、「こうこうこういう論文があって～」と言えるようになります。
なんだか、とてもかっこいいですね。

芋づる式にたどっていくので、このスキルをimozuruと名付けました。

そして、この手順を試作して私が最初に掘った題材は、「調べ方」そのものです。
私は検索や情報探索の専門家ではないので、思いつきだけで設計を組んでも意味がありません。
imozuruをより良いものにするために、人が長年かけて確かめてきた「調べ方の集合知、形式知」を集めることにしました。

これによって、図書館情報学の情報探索の研究を手に入れました。
代表的なものを3つ挙げます。

• Bates（1989）のberrypicking⁴：人は調べる途中で問いそのものを変えながら、木の実を摘むように情報を少しずつ拾い集める。拾い方として、参考文献をさかのぼる、その論文を引用している新しい論文へ進む、同じ著者の他の仕事を見る、といった動きを挙げている
• Ellis（1987）の探索行動のモデル⁵：情報を探す人の動きを、始める・引用をつたってたどる・ざっと眺める・良し悪しを見分ける・新着を見張る・要るところを抜き書きする、の6つに分けた
• Kuhlthau（1991）の探索過程⁶：調べ始めは誰でも混乱する。その段階で無理にまとめると、早く結論を出しすぎて、あとで要る細部を見落とす。これを早すぎる閉じ（premature closure）と呼ぶ

ところが、AIに深い調査（deep research）をさせる研究の論文3本⁷の参考文献をたどったところ、Bates・Kuhlthau・Ellisの論文は1本もありませんでした。

なんてもったいないのでしょうか……！！

6. imozuruに入れたもの

というわけで、前章で並べた研究を手順に入れて、imozuruが完成しました。
全体の流れは次のとおりです。

地図は、見つけた専門用語・人・情報が出てくる場（学会、雑誌、ブログなど）を書き留めておく一覧です。
ここからは、前の章の研究とつながる5つの決まりを紹介します。

6-1. 要約させない

一番大事な決まりはAIに要約させないことです。
Kuhlthauの言う早すぎる閉じを避けるため、途中経過を文章でまとめさせません。
Webページや論文の原文をファイルに保存し、「どのファイルの何行目にあるか」を指すだけにしています。

6-2. 引用をたどる

Batesの挙げた動きのとおり、参考文献をさかのぼり、引用している論文へ進み、著者で追います。

知らない分野ではそもそも何という言葉で検索すればいいかが分かりません。
引用をたどれば、主題を言葉で言い表さなくても先へ進めます。

6-3. 止めどきを証拠で決める

AIの検索には、情報が足りているのに探し続ける失敗と、足りていないのに早くやめてしまう失敗の2種類があります⁸。

そこでimozuruは最初に、原文の裏付けが要る主張を3〜6個書き出します。
たとえば「この分野ではそれを何と呼ぶか」「定番の手法は何か」「どこで失敗するか」です。
その全部に原文の場所が付いたら止めます⁹。
探しても新しい資料がほとんど出なくなる飽和に達したときも止めます¹⁰。

6-4. 抜き書きを機械で照合する

最後にできる抜き書きのページには、主張ごとに、原文から切り出した文がそのまま並びます。

ページを作るPythonスクリプトは、切り出した文が、保存した原文の指定の行にそのままあるかを照合します。
1語でも言い換えが混ざっていると、ページを作らずに止まります。

原文に見つからない抜き書きがある（言い換えか、行番号のずれ）:
  sample-blog.md:5  「わたしは影を塗るとき、まず一番暗い色を先に置く。 明るい影から置くと、あとで暗い…」

「言い換えず、原文のまま抜き出して」とプロンプトに書いても、AIにとってはお願いにしかなりません。
そのためここはスクリプトによる検査にしました。
人（モデル）の意識、注意に頼らず手順で防ぐという、4章のなぜなぜ分析と同じ考え方です。

6-5. 無いときは探した範囲つきで「無い」と言う

デザインのトーン＆マナーを、言葉から書体や色に落とす方法を掘ったときは、その流れの途中までしか原文が見つかりませんでした。
JAGATの記事¹¹は、その先をこう書いています。

ブランド・アイデンティティからデザイン・クリエイティブ表現に落とし込むには「クリエイティブジャンプ」と言われる発想の転換が必要で、経験や感覚によるところが大きい。

日本のアートディレクター本人が「この言葉からこの書体を選んだ」と書いた記録は、探した範囲では0件でした。
センスや才能は理論で後付けできるという私の考えを、真っ向から否定する材料が見つかってしまいましたね。

imozuruはこういうときに、探した範囲つきで「理論が見つからなかったよ～」と返します。
4-3で「規則は無い」と言い切られたのとは、ここが違います。
抜き書きは原文のままなので、脚色の入りようもありません。

間違った構想を与えてそれをデータで補強しようとすれば、がっつりべっつり否定してくれるのです。
頼もしい限りですね。

7. 使い方

imozuruを使うには、次の3つが入っている必要があります。
まだ入れていないものがあれば、それぞれの公式の手順を見て先に入れてください。

必要なもの	使う場面	入れ方
Claude Code	imozuruを動かす本体です	Claude Codeのセットアップ
Node.js	下のnpxコマンドでスキルを入れるときに使います	Node.jsのダウンロード
Python 3.10以上	原文の取得や抜き書きの照合をするスクリプトが使います	Pythonのダウンロード

3つがそろったら、ターミナルで次のコマンドを流します。

npx skills add MaryCache/imozuru

スクリプトはPythonの標準ライブラリだけで動くので、追加のパッケージは要りません。
pdftotextなどがあると、取れる原文が増えます。

繰り返しになりますが、Claude Codeには次のように頼みます。

芋づる式に調べて: 歌ってみたの MIX で、上手い人がどういう順番で処理しているか

結果は~/research/<話題>/に、地図（map.md）、探索の記録（log.md）、落とした原文、照合を通った抜き書きのページとして置かれます。

新着を追う見張りのモードや、手動で入れる方法についてはREADMEをご覧ください。

8. このスキルの限界

• ログインの壁（Xやpixivなど）と有料の論文の向こうには届きません。届かなかったものとして、URLを一覧にして返します
• 出て1年ほどの論文は、引用をたどるAPI（OpenAlex）への登録が追いついておらず、たどれないことがあります
• Webを検索するので、問いの中身が検索語として外に出ます。機密が絡む調べものには使いにくいかもしれません
• 4-3の比較は色の問いを「調べて」の一言で3回、imozuruで1回頼んだだけなので、一般化はできません。声の話題では、imozuruがボット対策で取れなかった論文の写しを、「調べて」の一言のほうが別の場所で見つけた回もありました
• 試行は日本語の依頼だけです

まとめ

• AIの成果物が物足りないときは、なぜなぜ分析に沿ってまず環境（ハーネス）と手順（スキル）を見直すべき
• 研究、論文、先人の知恵は、AIの手順を組む手がかりになる
• 作る手間が下がった今は、与えられた手段をそのまま受け入れず、自分で作り直せる

「AIだからこの程度しか答えられない」と諦めることはいつだってできます。
やれることを全てやってからでも、遅くはありません。

普段何気なく使っている当たり前の手順を、ぜひ一度疑って、作り直してみてください！

パレットリンクでは、日々のつながりや学びを大切にしながら、さまざまなお役立ち記事をお届けしています。よろしければ、ぜひ「Organization」のページもご覧ください。
また、私たちと一緒に未来をつくっていく仲間も募集中です。ご興味をお持ちの方は、ぜひお気軽にお問い合わせください。一緒に新しいご縁が生まれることを楽しみにしています。

1. imozuru（MIT）。https://github.com/MaryCache/imozuru ↩ ↩²

2. 大野耐一『トヨタ生産方式』ダイヤモンド社、1978年（本文は未読）。中小機構のJ-Net21も「『なぜを5回繰り返す』ということは、トヨタの経営を語る時によく出てきます」と書いています。https://j-net21.smrj.go.jp/solution/qa/efficiency/Q0891.html ↩

3. Morimoto ら「Human color constancy in cast shadows」2025。https://doi.org/10.1177/20416695251349737 ↩

4. Marcia J. Bates「The design of browsing and berrypicking techniques for the online search interface」1989。https://www.pages.gseis.ucla.edu/faculty/bates/articles/berrypicking.pdf ↩

5. David Ellis の博士論文（1987）。1989年の論文の元になったもの。https://etheses.whiterose.ac.uk/id/eprint/2975/1/DX093006.pdf ↩

6. Carol C. Kuhlthau「Inside the Search Process」1991。https://tefkos.rutgers-sci.domains/Courses/612/Articles/Kuhlthau_Inside_91.pdf ↩

7. arXiv 2508.05668・2506.18959・2609.01294。https://arxiv.org/abs/2508.05668 https://arxiv.org/abs/2506.18959 https://arxiv.org/abs/2609.01294 ↩

8. Zhang ら「To Search or Not to Search」2026。https://arxiv.org/abs/2602.03304 ↩

9. Roh & Han「HALT」2026。https://arxiv.org/abs/2608.02009 ↩

10. Kastner ら「Estimating the Horizon of Articles to Decide When to Stop Searching in Systematic Reviews」2007。https://pmc.ncbi.nlm.nih.gov/articles/PMC2655834/ ↩

11. 小澤歩「トーン＆マナーのつくり方」JAGAT、2014。https://www.jagat.or.jp/past_archives/content/view/5711.html ↩