TL;DR
GitHub のトレンド一覧に載っていた Agent Skill「last30days」を、Linux コンテナ上で実際にインストールして動かしました（2026-07-31 時点でインストールされた版は SKILL.md の frontmatter で version: "3.18.4"・MIT ライセンス）。実測でわかったことは次の3点です。
-
SKILL.mdは 221,743 文字 / 54,935 トークン（o200k_base で計測）。筆者リポジトリで最大のスキルの 3.4 倍、中央値の 16.5 倍という重量級です - API キーは一切なくても動きます。ただし「動く」の中身が経路ごとに違い、同一トピックでの取得件数は 3 件 → 10 件（3.3 倍） まで開きました
-
--searchで指定したソースは、そのまま使われるとは限りません。プランナーが途中でソース一覧を書き換えるため、指定した Reddit が 1 件も叩かれない経路がありました
はじめに
対象読者は、Claude Code や Codex などのエージェントに外部スキルを入れて運用していて、「入れる前にコストと実挙動を確かめておきたい」と考えている開発者です。
last30days は、Reddit・X・YouTube・TikTok・Hacker News・Polymarket・GitHub などを横断して直近 30 日の話題を集め、エンゲージメント順に並べ直してブリーフを作るスキルです。公式 README では Reddit・Hacker News・Polymarket・GitHub は設定なしで動くと説明されています。
本記事は、その「設定なしで動く」がどこまで本当かを、実際に叩いたログで確かめた記録です。検証環境は Linux コンテナ（Node v22.22.2 / システム既定 python3 は 3.11.15、python3.12 と python3.13 も同居）です。
1つ目の壁: Python 3.12+ が必須
npx skills add mvanhorn/last30days-skill でのインストール自体は数十秒で終わり、./.agents/skills/last30days に配置されました。Claude Code 向けにはシンボリックリンクが張られます。
インストール直後、既定の python3 で叩くとこうなります。
$ python3 scripts/last30days.py --help
last30days v3 requires Python 3.12+.
Detected Python 3.11.15.
Install with:
Mac: brew install python@3.12
Windows: winget install Python.Python.3.12
Linux: sudo apt install python3.12 (or pyenv install 3.12)
引数のパースにすら入らず、バージョンチェックだけで終了します。Debian bookworm 系（3.11）や Ubuntu 22.04（3.10）をそのまま使っている環境では、ここで確実に止まります。python3.12 を明示すれば通りました。
エラーメッセージが具体的な導入コマンド付きで返ってくる点は親切ですが、スキルの起動をエージェントに任せている場合、エージェント側が python3 を素直に呼ぶと毎回ここで転びます。ホスト側で python3.12 を既定にしておくか、スキル呼び出し時の Python パスを固定しておくのが安全です。
2つ目の壁: SKILL.md が 54,935 トークン
インストール後のフットプリントを測りました。
| 項目 | 実測値 |
|---|---|
| 総容量 | 18MB |
| ファイル数 | 198（うち Python 94） |
assets/ |
14MB（デモ用の jpeg / png / mp3） |
scripts/ |
4.0MB |
SKILL.md |
2,255 行 / 221,743 文字 |
18MB のうち 14MB が assets/ で、中身は README 用のデモ画像や音声ファイルです。動作には不要ですが、インストール時には一緒に降ってきます。
そして本題は SKILL.md です。tiktoken の o200k_base でトークン化したところ 54,935 トークン でした。
$ python3 -c "
import tiktoken
enc = tiktoken.get_encoding('o200k_base')
t = open('SKILL.md', encoding='utf-8').read()
print('o200k_base tokens:', len(enc.encode(t)))
"
o200k_base tokens: 54935
比較のため、筆者が運用しているリポジトリの 29 スキルを同じ方法で測りました。
| スキル | トークン |
|---|---|
| last30days | 54,935 |
| hourly-dispatch（自リポ最大） | 16,286 |
| write-article | 8,509 |
| research-runner | 7,008 |
| 自リポ 29 スキルの中央値 | 3,327 |
自リポジトリで最も肥大化しているスキル（記事公開パイプライン全体のディスパッチャ）の 3.4 倍、中央値の 16.5 倍です。スキルの本文はエージェントが起動したときにコンテキストへ載るため、この重さは 1 回の呼び出しごとに効いてきます。
SKILL.md の中身を読むと、大半は「LAW 1〜7」と名付けられた ホストモデルへの行動規範 です。たとえば LAW 7 は「あなた（ホストの推論モデル）がプランナーである」と宣言し、過去の失敗事例（2026-04-19 の誤読）まで日付入りで書き込まれています。プロンプトインジェクション対策というより、ホストモデルの手抜きを防ぐための防御コードが積み上がった結果に見えます。
なお npx skills add の実行時には、Gen / Socket / Snyk の 3 社によるリスク評価が「High Risk / 1 alert」と表示されました。ネットワークアクセスとブラウザ Cookie 読み取りを持つスキルなので、この表示自体は妥当です。導入前に一次情報として確認する価値があります。
キーなしで実際に使えるソースはどれか
このスキルには健康診断コマンドがあります。環境変数を一切足さない状態で --diagnose を叩いた結果が次です（JSON 全体は長いため、該当部分だけを抜粋しています）。
"network": {
"available_sources": [
"reddit",
"hackernews",
"polymarket",
"github",
"grounding"
],
"native_search": false
},
"safe": true,
"status": "ready"
README の記述どおり、Reddit / Hacker News / Polymarket / GitHub は無設定で候補に入ります。ただし GitHub は本環境では実際には使えませんでした。
[GitHub] No GitHub token; using the unauthenticated REST tier (low rate limit)
[GitHub] 403 rate limited or forbidden: https://api.github.com/search/issues?q=...
未認証の GitHub Search API は上限が厳しく、共有 IP のコンテナからだと 403 になります。--diagnose は「候補として存在するか」を返すだけで、実際に応答が返るかまでは確認していない 点は注意が必要です。
Reddit は逆に、キーなしでもしっかり動きました。ログを見ると RSS 検索 → サブレディットの人気投稿 → arctic-shift によるスコア補完、という 3 段構えでした。
[RedditKeyless] Tier 1 (RSS) 10 posts; score-only; 121 scored cards
[RedditKeyless] arctic-shift backfilled 9 post scores
[RedditKeyless] Relevance floor dropped 1 off-topic posts
--search は「候補プール」であって指定ではない
ここが今回いちばん引っかかった挙動です。--search hackernews,reddit,github を渡したのに、Reddit が 1 件も取れませんでした。
[Planner] Plan: intent=how_to, freshness=evergreen_ok, cluster_mode=workflow, subqueries=1, source=llm
[Planner] sq1 label=implementation search=""Model Context Protocol" implementation OR integration" sources=[hackernews,github]
✓ Research complete (5.1s) - Reddit: 0 threads, HN: 3 stories, Github: 0 results
プランナーが生成したサブクエリの sources が [hackernews, github] になっており、Reddit がそもそも呼ばれていません。Reddit が壊れているのではなく、プランナーの判断で落とされていた わけです。
このスキルのプランナーには 3 つの経路があります。
同一トピック「Model Context Protocol」で 3 経路を比べた結果が次の表です（--quick --max-results 10 前後で統一、件数は Reddit と Hacker News の合計）。
| 経路 | ログの source
|
実際に叩かれたソース | 取得件数 | 所要 |
|---|---|---|---|---|
キーあり・--search 3 種指定 |
llm |
hackernews, github | 3 | 5.1s |
キーなし・--search 2 種指定 |
deterministic |
reddit, hackernews | 7 | 4.0s |
キーなし・--plan 自前生成 |
external |
hackernews, reddit, grounding, jobs | 10 | 16.6s |
最少 3 件と最多 10 件で 3.3 倍 の差が出ました。3 行は「キーの有無」と「--plan の有無」の両方が変わっているため、差の要因を片方だけに帰することはできません。それでも実務的な含意ははっきりしていて、最多だったのは API キーを 1 つも設定していない --plan 経路 です。キーを足すことより、ホスト側でプランを書くことのほうが効きました。
--plan を使うときは、こういう JSON をファイルに書いて渡します。
{
"intent": "concept",
"freshness_mode": "evergreen_ok",
"cluster_mode": "none",
"subqueries": [
{
"label": "primary",
"search_query": "model context protocol mcp server",
"ranking_query": "What are developers saying about Model Context Protocol servers?",
"sources": ["reddit", "hackernews", "polymarket"],
"weight": 1.0
}
]
}
$ python3.12 scripts/last30days.py "Model Context Protocol" \
--plan /tmp/plan.json --quick --emit compact --max-results 10
[Planner] Plan: intent=concept, ..., subqueries=1, source=external
[Planner] sq1 label=primary search="model context protocol mcp server" \
sources=[hackernews,reddit,grounding,jobs]
✓ Research complete (16.6s) - Reddit: 6 threads, HN: 4 stories, ...
面白いのは、--plan で ["reddit", "hackernews", "polymarket"] と書いたのに、実行時のソースが [hackernews, reddit, grounding, jobs] に書き換わっている点です。Polymarket が落ち、grounding と jobs が足されています。つまり --plan でもソース指定は最終決定ではなく、エンジン側の調整が入ります。
著者視点の一次所見
3 経路を往復して感じたのは、このスキルが「キーがなくても動く」というより 「ホストのエージェントが仕事をすれば、キーなしで一番よく動く」 設計になっている、ということです。
SKILL.md の LAW 7 は、キーがないときに出る警告文を「能力の制約」と読み違えたホストモデルの実例まで載せて、--plan を必須だと繰り返しています。実際に測ると、その主張は正しかったわけです。キーを持たせた llm 経路が最も取得件数が少なく、キーなしの external 経路が最も多く拾いました。
一方で、54,935 トークンという SKILL.md の重さは、その設計思想の請求書でもあります。ホストモデルに正しく振る舞わせるための規範をすべて本文に書き込んだ結果、呼び出すたびに 5 万トークン超がコンテキストを占めます。1M コンテキストの世代なら許容範囲ですが、複数スキルを併用する構成では効いてきます。実運用では、必要なフェーズでだけ起動する運用に寄せるのが現実的だと感じました。
Python 3.12 要件と GitHub の 403 は、いずれも「事前に測っておかないとエージェントが黙って劣化する」タイプの落とし穴でした。導入直後に --diagnose を一度通し、さらに実際に 1 クエリ流して各ソースの取得件数を確認しておくと、こうした劣化に気づけます。
おわりに
実測でわかったことを整理します。
- Python は 3.12 以上を明示的に指すこと（3.11 では起動前に落ちる）
- インストール 18MB のうち 14MB はデモ用アセット。動作には不要
-
SKILL.mdは 54,935 トークン。呼び出しごとのコンテキスト消費として見積もること - キーなしで Reddit と Hacker News は十分に動く。GitHub は未認証だと環境によって 403
-
--searchも--planのsourcesも最終決定ではない。ログの[Planner]行で実際のソースを必ず確認すること - 取得件数を最大化したいなら、ホスト側で
--planを書く経路を選ぶこと
「キーレスで動くか」だけでなく「どの経路で動かすか」で結果が 3 倍変わるスキルでした。導入するときは、--debug を付けた 1 回の試走を必ず挟むことをおすすめします。