「URLを貼るだけでOSSを精査させる」仕組みを作ってみた

Last updated at 2026-06-22Posted at 2026-06-22

株式会社パレットリンクの@BaspisKawaEです。
今回は、ClaudeでOSSを精査する仕組みを作ることが出来たので、それについて解説します。
よろしくお願いします!

対象読者: OSSを安全に調べたい個人開発者・エンジニア
前提知識: GitHubとgitの基本操作、Claudeを利用した経験
この記事で学べること: Claudeのコンテナ機能とSkill機能を組み合わせ、GitHubのURLを渡すだけでOSSをcloneして精査するワークフローを構築する方法

1. 背景：SNSで流れてくるOSSと、AIに渡したときの挙動

XをはじめとしたSNSには、毎日新しいツールが紹介されます。
これらを毎回人間が査読していると、個人開発の速度優位が失われます。

一方、これらをAIに渡して機能追加を依頼すると、AIは中身を確認せず実装に着手することが報告されています¹。
「読まないと危険。しかし全て読むのは現実的ではなく、速度も落ちる」というジレンマがあります。

Claude Codeを使えば実機でcloneと実行によるOSS精査ができますが、精査したい対象は「未確認のリポジトリ」そのものですから、自分のマシンに展開するのは非常に危険です。

このジレンマを安全に、かつ簡単に解消する方法を二章にて紹介します。

2. Claude.aiのコンテナ実行環境

Claude.aiは内部にLinuxサンドボックスを持っており、一章で述べた隔離された環境に該当します。
さらにチャットでAIに命じることで、bash git pip npm などのコマンドを実行できます²。
git clone も可能という事です。

動作確認

実際に、bashコマンドを実行させて確認してみました。

cat /etc/os-release を実行してください

Claude Haiku 4.5で上記のチャットを打つと、次の出力が返りました。

PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.4 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

Claudeの最終応答テキストは「あなたが実行しているシステムはUbuntu 24.04.4 LTSです」のような形になることがあります。
プロセス（ツール呼び出し）を展開すると、内部の bash で実際に cat /etc/os-release が実行された記録を確認できました。
それがClaudeのコンテナ内の実行結果です³。

コンテナの特徴

項目	内容
OS	Ubuntu 24.04 LTS
利用可能なコマンド	`bash`, `git`, `pip`, `npm`, `curl` ほか標準的なツール群
ファイル操作	生成・編集・実行が可能
永続性	セッション終了時にリセット

つまり、ClaudeはURLから内容を読むだけでなく、リポジトリをcloneして実コードを検査できます。
web_fetch によるREADME読み込みよりも、遥かに優れた品質でOSSを精査できます。

3. 再現方法

配布しないという選択

「これを使えば安全」と書いてある配布スキル……これはかえって怪しい。少し身構えてしまいますね。
しかしそれでは、このスキルを解説する意味が半減してしまいます。

ということで、このスキルについては実物を配布せず、設計だけを共有することにしました。

ぜひこの記事をお手元のClaudeに渡して、自分用に組み立ててみてください。
己の目の届く範囲で作られたものが、一番安心して使えます。

再現用プロンプト

本記事と以下の単一プロンプトをClaudeに渡すことで、スキルを再現できるよう構成しました。

この記事の内容を参考に、自分用の精査スキルを設計してください。
出力先パス、依存数の閾値、動作確認の線引きについて、
私の使い方を質問しながら決めてください。

第四章では、スキルの実際の設計を解説していきます。

4. 設計解説

4-1. 精査スキルの設計

Claudeのスキルは、SKILL.mdというMarkdownファイルに「特定の状況での手順」を記述し、自動呼び出しさせる仕組みです⁴。
このスキル機能を利用して、「GithubのURLが貼られた場合に対象リポジトリをcloneし、精査してレポートを返す仕組み」を作成します。

【本記事の精査スキルの仕様】

入力: GitHubのリポジトリURL（https:// 省略可、/tree/{branch} や /commit/{sha} 指定にも対応）
出力: {owner}_{repo}/{YYYYMMDD}.md 形式のMarkdownレポート

発動条件

URL単独では動かないようにしました。
「精査して」「中身確かめて」「使えそう?」のような意図を示すキーワードが同時にあるときのみ発動します。
誤動作を防ぐためのガードです。

スキルの中身については、次節で解説します。

4-2. ワークフローの10ステップ

Step	内容
1	URL受領と検証
2	shallow clone（`git clone --depth=1`⁵）
3	構造把握（ファイル数、サイズ、最終コミット日）
4	一次ドキュメント精読（README, LICENSE, CONTRIBUTING, SECURITY）
5	依存ファイル確認（`package.json`, `requirements.txt`, `Cargo.toml`, `go.mod` ほか）
6	安全性チェック（grepによる危険パターン検出）
7	コード本体の代表サンプリング
8	動かすか読むだけかの判断
9	Markdownレポート出力
10	後片付け

以下、各Stepについて解説します。

Step 1: URL受領と検証

受け取った文字列がGitHubのリポジトリURLとして妥当か検証します。
対応形式は3つに限定しました。

github.com/{owner}/{repo} のリポジトリトップ
github.com/{owner}/{repo}/tree/{branch} のブランチ指定
github.com/{owner}/{repo}/commit/{sha} のコミット指定

Issues / Pull Requests / Wiki などのサブパスURLは受け付けません。
リポジトリ全体ではなく、その一部分の話になってしまうためです。

Step 2: shallow clone

git clone --depth=1 で履歴を直近1コミット分に切り詰めて取得します。
大型リポジトリでは数百MBの差が出るため、サイズと時間の節約になります。

git clone --depth=1 https://github.com/{owner}/{repo}.git
# ブランチやコミット指定があれば --branch を併用
git clone --depth=1 --branch={branch} https://github.com/{owner}/{repo}.git

Step 3: 構造把握

リポジトリの全体像を俯瞰します。
取得する指標は次のとおり。

ファイル数（1,000を超えるなら「忙しい」シグナル）
ディスクサイズ
最終コミット日（メンテナンスの活発度）
トップレベルのディレクトリ構造

ここで「メンテナンス停止リポジトリ」「巨大モノレポ」「単一ファイルツール」などの大まかな性格が見えます。

Step 4: 一次ドキュメント精読

次のファイルを順に読みます。

README.md — 主目的・使い方
LICENSE — 商用利用可否、コピーレフトの強さ
CONTRIBUTING.md — 開発体制
SECURITY.md — セキュリティポリシー（存在するだけで良いシグナル）
CHANGELOG.md — メンテナンス頻度
.github/workflows/ — CIの稼働状態

ライセンスが不明なリポジトリは商用利用を勧めない、というポリシーをスキルに書き込んでおきます。

Step 5: 依存ファイル確認

言語に応じて読むファイルを切り替えます。

Node: package.json, package-lock.json
Python: requirements*.txt, pyproject.toml, setup.py
Rust: Cargo.toml, Cargo.lock
Go: go.mod, go.sum
Ruby: Gemfile, Gemfile.lock
Java/Kotlin: pom.xml, build.gradle*

依存数、メジャー依存の素性、ロックファイルの一貫性を確認します。
直接依存と間接依存の数を別々に記録しておくと、後のレポートで「依存が広いか狭いか」の判定に使えます。

Step 6: 安全性チェックの具体パターン

【危険シグナルとして検出するgrepパターン】

# postinstall系スクリプトの有無
grep -rE '"(pre|post)install"' . --include='*.json'

# curl | sh パターン
grep -rE '(curl|wget).*\|\s*(sh|bash)' . --include='*.sh' --include='*.md'

# 難読化（base64エンコード+eval）
grep -rE 'eval\s*\(\s*(atob|Buffer\.from|base64)' .

# 認証情報の読み取り
grep -rE '~/\.(ssh|aws|gnupg)' .

検出された場合は危険シグナルとしてレポート最上部に記載されます。

Step 7: コード本体の代表サンプリング

全コードを読む必要はありません。
読むべきは「エントリーポイントとREADMEで言及されている主要モジュール」のみです。

main.*, index.*, cli.*, __init__.py, mod.rs などのエントリ
READMEで具体的に紹介されている関数・クラス

「このツールが何をやっているか」が分かるところまで読めば十分とします。
このスキルの目的は、「危険の検知」と「ツールの採用価値の可視化」にあります。
そのため、より詳細な処理の解説を行わせる必要はありません。
学習目的で、より詳細な内容を参照させたい場合は、スキル使用時に単一のプロンプトで宣言しましょう。

Step 8: 動かすかどうかの判断ロジック

スキル内で次の基準により分岐させます。

条件	動作
危険シグナルが1つ以上検出	動かさない
安全性確認が主目的	動かさない（静的解析のみ）
依存が軽く、機能挙動を確認したい	動かす
root権限・システム改変を要求するセットアップ	動かさない

判断軸をスキル側に固定することで、対話のたびに判断がブレることを防げます。

Step 9: Markdownレポート出力

ここまでで集めた情報を構造化し、Markdownレポートとして出力します。
ファイル名は {owner}_{repo}/{YYYYMMDD}.md 形式で、同じリポジトリを再精査したときに日付別に並ぶ構造にしました。

具体的なレポートのフォーマットは次節 4-3 で詳しく見ていきます。

Step 10: 後片付け

cloneしたディレクトリを削除します。
セッション終了時にコンテナごとリセットされるため必須ではありませんが、複数のリポジトリを連続して精査する場合は、前のディレクトリを消してから次のcloneを始めると見通しが良くなります。

4-3. 出力レポートのフォーマット

【スキル実行時に生成されるMarkdownレポートの構造】

# 精査レポート: {owner}/{repo}

> 調査日: 2026-06-01
> ライセンス: MIT

## 総合判断
- 使えそうか: ✅ / ⚠️ / ❌
- 安全性: ✅ / ⚠️ / ❌
- 推奨される使い方: ...

## 安全性チェック

### 危険シグナル
（検出された危険パターン）

### 注意シグナル
- README冒頭に `curl | bash` ワンライナーあり
- ただし `clone してから精査するルート` も併記

### 良いシグナル
- ライセンス明確
- CI（build/coverage/lint）が稼働中
- 最新コミットが調査日の前日

## 技術構成
- 主要言語と比率
- 主要依存
- テスト・CI状況

## 動作確認
- 判断：動かした / 動かさなかった
- 理由：Step 8の判断結果に基づく
- 結果：実際の挙動（動かした場合のみ）

設計上のポイント

総合判断を ✅ / ⚠️ / ❌ 表示し、「使えそうか」と「安全性」を分離する

両軸を独立させることで、次のようなケースを正確に表現できます。

ケース	使えそうか	安全性
健全で活発に開発されている	✅	✅
メンテナンス7年停止、新規採用は非推奨	⚠️	✅
危険シグナル検出、採用すべきでない	❌	❌

動作確認セクションを独立させる

判断理由を明示することで、なぜ動かしたか/動かさなかったかを後から追跡可能にします。

設計は以上です。

まとめ

ClaudeはLinuxコンテナを内包し、bash や git などのコマンドを実行できる
スキルとして精査ワークフローを記述すると、URLを貼るだけでcloneと検査が可能になる
コードは配布せず設計のみを共有する
この記事をClaudeに渡せば、同等のスキルを再現できる

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

NF0000「Claude Codeにバックドア入りOSSを渡したら、何の疑いもなく実装した」Qiita, 2026-03-10. https://qiita.com/NF0000/items/66510f959b1c22f011a7 ↩
Anthropic「Code execution tool」Claude Docs. https://docs.claude.com/en/docs/agents-and-tools/tool-use/code-execution-tool — 「The code execution tool allows Claude to run Bash commands and manipulate files, including writing code, in a secure, sandboxed environment」と明記されている。 ↩
Claude.aiでこの機能を扱うのは「Upgraded file creation and analysis」と呼ばれる機能で、Pro / Max / Team / Enterprise プランで claude.ai/settings/features から有効化できる。なお Code execution tool は API 経由でも利用可能で、ベータヘッダー code-execution-2025-08-25 を付けて呼び出す。 ↩
Anthropic「The Complete Guide to Building Skills for Claude」claude.com/blog, 2026-01-29. https://claude.com/blog/complete-guide-to-building-skills-for-claude — 公式のスキル実例集は https://github.com/anthropics/skills で公開されており、docx pptx pdf skill-creator など17種類の実装例を読める。 ↩
--depth=1 は履歴を直近1コミット分のみに切り詰めて取得するオプション。大型リポジトリのcloneにかかる時間とディスク使用量を抑えられる。https://git-scm.com/docs/git-clone ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up