最近、公開ページを何度も読んでいる。
AI制作物のウォッチ。
Codexまわりの調査。
taupeの記事seed。
source-check。
ブラウザで1回読むだけなら、それほど困らない。
でも、そのページを別のAIタスクへ渡し、記事の構成に使い、比較表にも入れるとなると、titleや要点、元URL、確認日を何度も整理することになる。
問題は、読むことではなかった。
同じ公開ページを、再利用できる形に直すところだった。
そこで作ったのが、public-source-extractor です。
公開URLを1件だけ受け取り、AI調査で扱いやすいMarkdownかJSONへ変換する小さなCLIです。
最初は自分用のPython scriptだった。
実際の調査で使える感触があったので、GitHubで公開できる形まで育てました。
先に注意点を書いておくと、指定した公開URLは抽出のためFirecrawl Cloudへ送信される。
API keyやcookieを読むCLIではないが、完全なローカル処理でもない。
ただし、これは万能なWebスクレイパーではない。
抽出した内容をそのまま信じるための道具でもない。
公開ページを調査の下処理へ入れる時に、毎回の手作業を少し減らすためのCLIです。
2026年7月12日時点の実運用を残しておきます。
AI調査で、同じ公開ページを何度も整理していた
AI関連の記事やツールを調べる時、最初に見るのは公式ページです。
そのまま読んで終わるなら問題ない。
ただ、あとから記事のseedにする時や、複数の候補を比べる時には、結局同じ整理が必要になる。
- titleを確認する
- 本文の中心を抜き出す
- 元URLと取得時点を残す
- 要点をMarkdownや表に置く
- 次のAI作業へ渡せる形にする
この作業は地味です。
でも、毎日いくつかの公開ページを扱っていると、意外と積み上がる。
最初は、必要な時だけ自分用scriptを動かしていました。
公開URLをMarkdownかJSONにして、あとから読み直しやすくするだけのものです。
実際に使ってみると、記事を書き始める前の調査が少し整理された。
そこで、個人用のまま置くより、安全に使える範囲を先に決めて、公開CLIにしてみることにしました。
公開URLをMarkdownやJSONへ変える小さなCLIにした
public-source-extractor は、公開HTTP / HTTPSページを1件だけ抽出します。
通常はMarkdown。
決まったfieldが欲しい時だけJSON。
public-source-extractor https://example.com/比較表や記事seedのように、title、summary、main argument、key pointsを一定の形で使いたい時はJSONにします。
public-source-extractor https://example.com/ --mode json --prettyファイルとして残したい時も、出力先を指定するだけです。
public-source-extractor https://example.com/ --output report.md最初の公開版は、PyPIではなくGitHubのtagを固定して入れるsource-only alphaにしています。
pipx install 'git+https://github.com/Ishikawa-Hidekazu/public-source-extractor.git@v0.1.0-alpha.1'Python 3.11以上が必要です。
ここでやりたいのは、調査を自動化しきることではない。
次の作業へ渡せる形に、公開ページを一度そろえることです。
万能scraperではなく、安全境界を先に決めた
公開URLを受け取るCLIは、つい何でも取りに行けるようにしたくなる。
でも、そこを広げると、使う時に何を渡してよいのか分からなくなります。
このCLIでは、最初に境界を決めました。
することは、公開ページ1件の抽出です。
Markdownまたはversioned JSONへ変換し、標準出力か新しいファイルへ出す。
しないことも決めています。
- ログインページ、管理画面、private pageの抽出
- cookie、browser profile、localStorage、credentialsの利用
- サイト全体の巡回
- Chrome操作やComputer Use
- source reliabilityの自動判定
- providerの自動fallback
- telemetry
URLもそのまま受け取らない。
localhost、private IP、loginやadminのpath、tokenやsignatureらしいqueryを含むURLなどを拒否するようにしています。
ただし、これでprivate URLやredirectを完全に防げるわけではありません。
DNS rebindingやproviderが実際にどこを取得するかまで、このCLIだけで保証できるものではない。
だから、公開URLだけを渡す。
署名付きURL、token入りURL、ログイン後のURLは渡さない。
ここは使う側にも残るルールです。
Firecrawl Keylessは便利だけど、experimentalとして扱う
抽出には、firecrawl-keyless providerを使っています。
2026年7月12日時点では、API keyを入れずに動作しました。
ただ、そこで「無料でずっと使える」とは書けない。
FirecrawlのKeyless launch記事では、API keyなしで使えることや、当時のcredit付与が案内されています。
一方で、現行のrate limit docsは、keyless利用をofficial client中心に説明し、IP単位の日次request / credit制限を示しています。
具体的な上限値は公開されていません。
Scrape APIの通常リファレンスには、Authorization headerを使う例も出ている。
公式情報だけ見ても、Keylessの扱いは変わりうる前提で見た方がよさそうです。
なので、CLIのproviderはexperimentalです。
匿名REST access、credit上限、長期の継続を前提にしない。
もう一つ大事なのが、指定したURLはFirecrawl Cloudへ送信されることです。
公開ページを対象にするのはそのためでもあります。
抽出結果も、元ページの正本ではない。
本文には誤りや、prompt injectionのような指示文が混ざる可能性がある。
重要な主張は、元URLと公式・一次情報で確認する。
このCLIは、その確認を省略する道具ではない。
確認前の素材を、扱いやすくする道具です。
実際のAI調査で3ページへ使ってみた
公開後、まず3ページへJSON modeを使ってみました。
| 対象 | 結果 | wall time | provider elapsed | credits |
|---|---|---|---|---|
| OpenAI ChatGPT Work公式ページ | success | 約6秒 | 5,738ms | 5 |
| Firecrawl Keyless公式記事 | success | 約4秒 | 4,354ms | 5 |
| Public Source Extractor GitHub repo | success | 約5秒 | 4,867ms | 5 |
3件だけなので、性能benchmarkとして扱うものではありません。
表のcreditsは、Firecrawlがresponse metadataで返したcreditsUsedです。
料金や日次上限を示す数字ではなく、3件だけで一般的な消費量を判断するものでもありません。
ただ、title、summary、main argument、key points、external sources、resolved URL、provider metadataを同じ形で取れた。
記事seedや比較の前段としては、これで十分使える場面がありました。
OpenAIのChatGPT Work公式ページはMarkdown modeでも試しました。
手元の計測では約1秒で、Markdown出力のbody部分は約5,688文字でした。
日常の調査では、まずMarkdownがよさそうです。
読むための情報量を残しつつ、元ページへ戻る導線も持てる。
JSONは、全URLに一律で使うものではない。
あとで表にする、決まったfieldで比較する、記事seedへ渡す、といった時だけ使う方が自然でした。
使い始めたから、最初の改善Issueが見つかった
ここが面白いところ。
Markdown modeは速くて、普段の調査に使いやすかった。
でも、使っているとfront matterにproviderのcreditsや処理時間が出ていないことに気づきました。
Keylessの具体的な上限値が公開されていないなら、少なくとも返ってきたmetadataは見える方がいい。
Markdown中心で使うなら、なおさらです。
そこで、Issue #7を作り、provider_credits_used と provider_elapsed_ms をMarkdown front matterへ入れる改善を進めました。
PR #8はmainへmerge済みです。
mainのREADMEや現在のコードには、この改善が入っています。
ただし、公開releaseはまだv0.1.0-alpha.1のまま。
Issue #7の改善が、tag release版に入っているわけではありません。
こういう差を雑にしないためにも、alphaは少し使ってから次を出したい。
数日動かして、他にも直すところがまとまったら、次のreleaseを判断します。
自分が毎日使う小さなCLIを積み上げていく
大きなAI調査システムを最初から作る必要はないと思っています。
公開ページを再利用可能なartifactへ変える。
その結果を、元URLと確認日を残したまま次のAI作業へ渡す。
まずはそのくらいでいい。
同じ考え方で、Codexを日々使うためのヘルスチェックCLIも作っています。
Codexを日々使う人へ。ヘルスチェックCLI「codex-healthkit」を公開しました
AIに任せる作業も、毎回長いpromptで説明するより、繰り返す手順をskillへ残した方が確認しやすい。
AIに任せる仕事は、プロンプトではなくskillにした方がいい
Public Source Extractorも、その間に置く小さな道具です。
AIに公開ページを読ませる前に、何をどこまで渡すかを決める。
その境界があるだけで、調査の記録は少し扱いやすくなると思う。
Public Source Extractorを見る
使う前に、まずREADMEとreleaseを読むのがよいです。
今はsource-only alphaです。
公開URLだけを使い、結果を一次情報の代わりにしない前提で試してみてください。