これはなに
こんにちは、レバテック開発部のもりたです。
今回はわたしが普段web記事を読む際に使っているClaude Skillsについてご紹介します。ITのエンジニアって技術の流行り廃りが早かったりして、日々の情報収集を求められますよね。けど実際に記事が読めるかと言われると、あんまり読めないのではないでしょうか。今回はそのつらみを整理してClaudeの助力で解決できつつあるので、ご共有します。
構成
構成
- 元々のインプット環境と課題
- 解決策
- よかったこと
課題、解決方法、感想！ シンプル構成でいきます。
元々のインプット環境と課題
まずはわたしがどんな環境でなにを読み、どんな課題を持っていたのかを共有します。
もともとのインプット習慣
初めに私が普段どのようなものを読むのかですが、仕事や家事育児の合間にWeb記事を読むのが中心でした。Xで流れてきたものや、気になって検索したWeb記事を読むことが多かったです。
また、記事を読む際にObsidianを利用することもあります。例えば海外の記事などはObsidianのWebClipperを使って文章データをObsidianに落としてきたのち、要約・翻訳するスキルを使って読みやすくしていました。そして読んだ後は得た知識を短くまとめるということを目指しています。
そんな感じでやっていたため、私が文章を読むときのワークフローは以下のような感じでした。
Xで見かける→WebClipする→スキルで翻訳・要約→本文を読む→理解をまとめる
今回の課題
そのようにインプットを行なっていた私ですが、課題がいくつかありました。
まず、Clipしたままになっている記事がたくさんありました。とりあえずあとで読もうと思ってClipしたのち、忘れ去られて読まれないことが多かったです。仮に読みかかったとしても、難しい単語や理解できない文脈にあたると面倒になり、読むのをやめていました。
次に、読めたものもそのまま放置されており、自分の中で身についた気がしていませんでした。本当は理解したことをまとめておきたいのですが、理解を言語化するのもまあコストですし、ぼんやりしたまま放置することも多かったです。
以上のようなワークフロー・課題を持っていたのですが、次の解決策にある通りClaudeを利用して一定解決しています。
解決策
というわけで解決策です。
やったことは真っ当で「Claudeと一緒に読むようにして、問題のあった箇所を助けてもらってる」という感じです。具体的なところを見てみましょう。
まず、ClaudeのSkillsを作成し、次のようなワークフローを定義しました。
以下にワークフローの概要と、実際のSkillsを並べます。
ワークフロー
- 前提：翻訳済みファイルは作成ずみ
- １：印刷して読む。わからない箇所があれば赤ペンで印をつける
- ２：わからなかった単語をClaudeに質問
- ３：記事の内容についてClaudeと一緒に議論
- ４：Claudeから記事内容についてのクイズ
- ５：感想をまとめる
- ６：Permanentノート[1]にできるものはする
実際のスキルなど
なげ〜〜のでアコーディオンにします。
前提となっているフォルダ構成など
前提となっているフォルダ構成
一応フォルダ構成も書きますが、大したことはしていません。
ChromeのObsidian向け拡張機能であるWebClipperを使ってWeb記事のデータを取得していて、そこから後述の要約・翻訳スキルにかけたものを資料置き場に移しているだけです。
- リポジトリルート
- 資料置き場
- Webclip置き場
- まとめノート置き場
また、この分類はZettelkastenと呼ばれる手法を参考にしています。以前そこらへんも薄〜く概要を書いたので、気になる方は読んでみてください。
要約・翻訳スキル
要約・翻訳スキル
スキルです。コピペします。
- SKILL.md
---
name: webclip-processor
description: ObsidianのWebClip記事を処理し、要約ノートを作成するスキル（英語記事は日本語翻訳も行う）
allowed-tools: Read, Glob, Bash, Write, AskUserQuestion
---
作業ガイドライン：[guidelines.md](guidelines.md)を参照してください。
## タスク
1. **処理対象ファイルを確認する**
- `{「Webclip置き場」フォルダ}` 内のファイル一覧をGlobで取得する
- すでに処理済みのファイル（`本文`・`翻訳`・`要約` で終わるもの）は除外する
- 候補一覧をユーザーに提示し、どのファイルを処理するか確認する
2. **ファイルを読み込んでタイトルを確定する**
- 対象ファイルを読み込む
- frontmatterの `title` フィールドを取得する
- `title` がない場合はファイル名から推測してユーザーに確認する
- タイトルにファイル名不可文字が含まれる場合は以下のルールで自動置換する（確認不要）：
- `/` → `-`
- `?` → 削除
- タイトルに使う表記を確定する（例：`A brief history of Object Relational Mapping`）
2.5. **記事の言語を判定する**
- 本文の大部分がひらがな・カタカナを含む → 日本語記事
- 本文が主に英語（日本語用語が散在する程度） → 英語記事
- 判定が難しい場合はユーザーに確認する
- 以降のステップで「英語記事のみ」と書かれたステップは日本語記事の場合スキップする
3. **元記事をリネームする**
- Bashで `mv` を使い、元ファイルを `『タイトル』本文.md` にリネームする
- リネーム先ファイル：`{「Webclip置き場」フォルダ}/『{タイトル}』本文.md`
- リネーム前にユーザーに確認は不要（タイトル確定済みのため）
4. **日本語翻訳ノートを作成する（英語記事のみ）**
- 日本語記事の場合はこのステップをスキップする
- ファイル：`{「Webclip置き場」フォルダ}/『{タイトル}』翻訳.md`
- 元記事の本文全体を日本語に翻訳する
- frontmatterは不要。翻訳内容だけを書く
- 元記事の見出し構造・段落構成を保持する
- 固有名詞・技術用語は原語を括弧内に残す（例：「オブジェクト関係マッピング（ORM）」）
5. **要約ノートを作成する**
- ファイル：`{「Webclip置き場」フォルダ}/『{タイトル}』要約.md`
- 英語記事の場合は以下のフォーマットで作成する：
```
---
status: unread
---
# これはなに
（この記事が何であるかを1〜2行で説明）
## 関連ファイル
[[『{タイトル}』本文]]
[[『{タイトル}』翻訳]]
# 要約
（記事の内容を日本語で要約。重要な論点・事実・主張を網羅する）
```
- 日本語記事の場合は以下のフォーマットで作成する（翻訳リンクなし）：
```
---
status: unread
---
# これはなに
（この記事が何であるかを1〜2行で説明）
## 関連ファイル
[[『{タイトル}』本文]]
# 要約
（記事の内容を日本語で要約。重要な論点・事実・主張を網羅する）
```
6. **ファイルを移動する**
- Bashで `mv` を使い、`{「Webclip置き場」フォルダ}/` から `{「資料置き場」フォルダ}/` に移動する
- 英語記事：本文・翻訳・要約 の3ファイルを移動
- 日本語記事：本文・要約 の2ファイルを移動
7. **完了を報告する**
- 作成・移動したファイルのパスを列挙して報告する
guidelines.md
# webclip-processor ガイドライン
## 対象フォルダ
`{「Webclip置き場」フォルダ}/`
## 処理済みファイルの判定
ファイル名が以下で終わるものは処理済みとして除外する：
- `本文.md`
- `翻訳.md`
- `要約.md`
## タイトルの扱い
- frontmatterの `title` を優先使用する
- `title` が空・未設定の場合はファイル名（拡張子・タイムスタンプ部分を除く）から推測し、ユーザーに確認する
- 確定したタイトルをそのまま `『』` で囲んでファイル名に使う
- ファイル名に使えない文字（`/`, `\`, `:`, `*`, `?`, `"`, `<`, `>`, `|`）が含まれる場合は、ユーザーに代替タイトルを提案する
## 言語判定の基準
- 本文にひらがな・カタカナが連続して含まれる → 日本語記事
- 本文が主に英語で、日本語用語が散在する程度 → 英語記事
- 判定が曖昧な場合はユーザーに確認する
## 翻訳の品質指針（英語記事のみ）
- 逐語訳ではなく、意味を優先した自然な日本語にする
- 固有名詞・技術用語は初出時に原語を括弧で補足する
- コードサンプルは翻訳せずそのまま保持する
- 著者名・組織名・製品名は原語のまま
- 元記事の見出し（`#` `##` 等）の階層構造はそのまま維持する
## 要約の品質指針
- 「これはなに」は1〜2行の簡潔な説明にする
- 要約本文は記事の主要な論点・事実・主張をすべてカバーする
- ユーザーが元記事を読まなくても内容を把握できる密度で書く
- 時系列・因果関係が重要な記事ではその流れを保持する
- 箇条書きよりも流れのある文章を優先する（必要に応じて箇条書きも可）
- 日本語記事は原文をそのまま読めるため、要約は内容の構造化・論点の抽出に集中する
- 難解な専門用語には必要に応じて簡潔な補足を入れる
## 処理後のファイル移動
処理完了後、`{「Webclip置き場」フォルダ}/` から `{「資料置き場」フォルダ}/` に移動する。
- 英語記事：本文・翻訳・要約 の3ファイル
- 日本語記事：本文・要約 の2ファイル
- 移動にはBashで `mv` を使う
## リネーム後の参照更新
リネーム後、vault全体を対象に元のファイル名への参照（Obsidianリンク）を検索し、見つかった場合はリネーム後のファイル名に書き換える。
- 検索パターン：`[[元のファイル名]]`（`[[元のファイル名|表示テキスト]]` 形式も対象）
- 更新先：`[[『タイトル』要約]]`（要約ファイルへのリンク）
- 検索にはGrepを使う（Glob + Bashのlsは日本語括弧にマッチしないことがあるため）
## ファイルパスの注意
- すべてのパスは `{リポジトリルート}/` を起点とする相対パスで管理する
- Obsidianのリンクは `[[ファイル名]]` 形式（拡張子なし）で記述する
Claudeと一緒に読むスキル
Claudeと一緒に読むスキル
SKILL.md
---
name: claude-read
description: 資料を一緒に読むスキル。webclip-processor で作成した翻訳・要約ノートや {「資料置き場」フォルダ} 内の資料ファイルを対象に「選択 → 読書 → 理解 → 確認テスト → 感想ノート → 読了」の学習セッションを Claude と一緒に実施する。「一緒に読もう」「この資料を読む」「claude-read」「資料を読みたい」「クリップを読む」など、資料を読む作業を始めるときは必ずこのスキルを使う。
allowed-tools: Read, Glob, Bash, Write, Edit, AskUserQuestion
---
## ステータス定義
資料ファイルの frontmatter `status` フィールドで読書進捗を管理する：
| 値 | 意味 |
|---|---|
| `unread` | 未着手（または status 未設定） |
| `reading` | 読書中（Phase 1〜2） |
| `processing` | 全体理解中（Phase 3） |
| `reviewing` | 確認テスト中（Phase 4） |
| `reflecting` | 感想ノート作成中（Phase 5） |
| `harvesting` | permanentノート化待ち（Phase 6） |
| `done` | 完全読了（Phase 7） |
---
## Phase 1: 資料の指定
1. `{「資料置き場」フォルダ}/` 以下の `.md` ファイルを Glob で取得する
- 除外: `*本文.md`, `*翻訳.md`（これらは生素材であり読書の対象ではない）
2. 各ファイルの frontmatter から `status` を読み取る
3. 優先順位をつけてユーザーに一覧を提示する
- 優先: `status: unread` または status 未設定
- 次点: `status: reading` / `processing` / `reviewing` / `reflecting`（途中再開）
- 末尾: `status: done`
4. ユーザーが資料を選択したら：
- ファイルを Read で読み込んでおく（要約.md の場合は関連する翻訳.md も）
- frontmatter に `status: reading` を設定する
- frontmatter がある場合: Edit で `status:` 行を追記または更新
- frontmatter がない場合: ファイル先頭に以下を挿入する
```
---
status: reading
---
```
5. webclip-processor 済みの要約.md を選択した場合は、翻訳ファイルへの案内を表示する：
「翻訳ファイルを Obsidian で開いて読んでください：`[[『タイトル』翻訳]]`」
---
## Phase 2: 読書
ユーザーに伝える：「資料を読んでください。読みながら気になった点があれば聞いてください。読み終わったら教えてください。」
質問が来たら**聞かれたことだけ**に答える。1〜3文で簡潔に。
- 文脈から先読みして関連情報を補足しない
- 資料全体のまとめや意味づけは「それは次のフェーズで話しましょう」と Phase 3 に持ち越す
- 「なぜこの設計になっているのか」「全体としてどういう意味か」など、理解の議論になってきたら Phase 3 へ
ユーザーから「読み終わった」「読んだ」などの合図が来たら：「次は一緒に内容を整理しますか？」と確認してから Phase 3 へ。
---
## Phase 3: 全体の理解
1. `status: processing` に更新する
2. Claude は読み込んでいる資料（要約.md や本文）をもとに**主要論点を整理して提示**する
- 「この資料で一番重要なポイントは〜」「著者の主張は〜」のように構造化して示す
3. ユーザーの理解を引き出す：「この点はどう理解しましたか？」「気になった部分はありましたか？」
4. ユーザーとディスカッションする。理解のズレや深掘りたい点があればここで扱う
5. ユーザーが「OK」「理解できた」などの合図を出したら：「理解確認の質問をしてもいいですか？」と確認してから Phase 4 へ。
---
## Phase 4: 確認テスト
1. `status: reviewing` に更新する
2. 資料の内容に基づいた**理解確認の質問を 3 問**出す
- 1問ずつ出す（3問一気に出さない）
- 事実確認だけでなく、理解の深さを問う問いにする（例：「なぜ〜なのか」「〜と〜の違いは何か」）
3. 各回答に対してフィードバックする（正解・補足・深掘り）
4. 3問終了後、「感想をまとめましょうか？」と確認してから Phase 5 へ。
---
## Phase 5: 感想ノート作成
1. `status: reflecting` に更新する
2. 会話を遡り、ユーザーが「感想に書きたい」「あとで感想に入れたい」などと言っていた箇所を拾い、あれば一覧として提示する。そのうえでユーザーに感想を聞く：「この資料を読んでどう思いましたか？気づきや印象に残ったことを教えてください。」
3. ユーザーの感想をもとに感想ノートを作成する
- **ユーザーの言葉をそのまま使う**。意味や表現を Claude が書き換えない
- Claude が観点を補足したい場合は `## Claude先生より` セクションに分けて書く（任意）
- `## Claude先生より` の書き味は「赤ペン先生」スタイルで：ユーザーの感想の良い点を◎などで褒め、補足・訂正は励ます口調で添える
**感想ノートのフォーマット**（`{「資料置き場」フォルダ}/YYYY.M.D_『タイトル』感想.md`）：
```markdown
---
title: 『タイトル』感想
date: YYYY.M.D
links:
- [[『タイトル』要約]]
---
# 感想
（ユーザーの言葉をそのまま記録）
## Claude先生より
（Claude が補足・コメントを加える場合のみ。なければ省略。赤ペン先生スタイルで書く）
```
4. **要約ノートへの逆リンクを追記する**（双方向リンクのため）：
- 要約.md を選択した場合: `## 関連ファイル` セクションに `[[YYYY.M.D_『タイトル』感想]]` を追加
- セクションがない場合はファイル末尾に `\n## 関連ファイル\n[[感想ノート名]]` を追加
- standalone ファイルの場合: ファイル末尾に `\n[[感想ノート名]]` を追加
5. 感想ノートと逆リンクの作成が完了したら：「permanent化に進みますか？」と確認してから Phase 6 へ。
---
## Phase 6: permanent化待ち
1. `status: harvesting` に更新する
2. 完了を報告する：作成・更新したファイルのパスを列挙して伝える
3. ユーザーに案内する：「感想ノートをもとに、permanentノートを `{まとめノート置き場}/` に作成してください。」
4. permanentノートを作成したらユーザーに知らせてもらう：「作成できたら教えてください。」と伝える。合図が来たら `status: done` に更新して Phase 7 へ。
---
## Phase 7: 完全読了
「お疲れ様でした！」と伝えて作業を完了する。
---
## 注意事項
- **各フェーズの移行前に必ず確認する**：「次に進みますか？」と一言添えてからフェーズを進める
- **status 更新は各フェーズの開始時**に行う：途中離脱しても resume できるよう状態を保持する
- **感想はユーザーの言葉で**：Claude が感想を代筆するのではなく、ユーザーから聞いた言葉をまとめる
やってよかったこと
とりあえずで読める
以前まではとにかく読み通して理解の言語化まで一気に行うスタイルだったため、なかなか手を出せず読み始められないということも多くありました。ただ今回のワークフローではフェーズごとに進めることができ、進捗をAIが追跡してくれるので、気軽に読み始め、途中で止めることも簡単です。そのため、着手が早くなりました。
中途半端な状態で放置することが極端に減った
そして一旦着手してしまうと、案外最後までちゃんと進められることも多かったです。これは知らない単語をちゃんと調べるフェーズを入れていることも意味があったと思っていて、全て理解した上で全体の構造理解に進めるため、それ以降のフェーズもあまり苦労することなく進められました。また、途中で止めやすい反面、再開するのも簡単だったため、お手洗いに行っている隙にちょっと読むとか、そういうことができたのも最後まで読める理由だったかなと思います。
Claudeからのコメントがついて嬉しい
感想をまとめた時にClaudeがコメントをつけてくれます。地味にやる気出ます。
おわりに
自分の興味を満たすために物を読むというのは本来とても楽しいことだと思っています。ただ、それが自己研鑽になり有意義さを求められてくると、背伸びした読書をすることにもつながり、ストレスの多いものになりがちですよね。
このスキルでは読書の中にある課題を細かく対処することで、インプットの負荷を下げてみました。このスキルを使ってインプット習慣を作ることで、好きなものにもっとのめり込める人が増えたら嬉しいなと思っています。
-
Zettelkastenにおけるまとめのノート ↩︎
Discussion