はじめに
この記事は社内LT向けにまとめたものです。想定読者は「Claudeはまだあまり触ったことがない」方。難しい前提は置かず、"こんな仕組みが会話だけで作れる"という雰囲気が伝わればうれしいです。
前回の記事で、Qiitaのトレンド記事を取得する読み取り専用のローカルMCPサーバー「qiita-trend」を作りました。今回はそれをClaude Coworkの定期実行につなぎ、さらに 「良かった記事をログに残す → 好みの傾向を分析 → 次回の記事選定に反映する」 という、使うほど育つ仕組みにした話です。
この仕組みも前回同様、コードや設定を自分で書くことなく、Claudeとのチャットだけで組み上げています。スケジュール作成、ログ設計、連携まですべて対話で完結しました。
▶︎前回の記事はこちら
全体像: 「取得 → 蓄積 → 学習」のループ
ポイントは⑤→②のフィードバックループです。良かった記事のURLをチャットに貼るだけでログが育ち、翌朝以降の選定に効いてきます。
これが成立するのは、Coworkのスケジュールタスクが 各実行を新しいセッションとして起動しつつ、ファイル・MCPサーバー・コネクタ・スキルに手動セッションと同じようにアクセスできる から。「定期タスクからローカルファイル(ログ)も自作MCPも触れる」性質がこの構成の土台です。スケジュールは /schedule とチャットに入力するか、サイドバーの「Scheduled」から作成でき、頻度は毎時・毎日・毎週・平日のみから選べます。
ステップ1: トレンドの定期配信を設定する
まず「Qiita morning digest」というスケジュールタスクを作成しました。設定は特別なことをしておらず、チャットで頼んだだけです。
- 実行タイミング: 平日(月〜金)朝8:00
- 内容: qiita-trend MCPで直近のトレンドを取得し、関心テーマ(生成AI・MCP・デザイン・フロントエンド)に沿って厳選・要約して画面に表示
これだけでも毎朝ダイジェストが届きますが、選定基準が「事前に決めたキーワード」に固定されているのが物足りない点でした。キーワードは自分の好みの近似でしかありません。
ステップ2: 「良かった記事」をログに残す
そこで、読んで良かった記事をチャットでClaudeに共有し、logフォルダに構造化して記録してもらう 運用を始めました。
最初に共有したのはこの5記事です。
- 【AWS】AI-DLCを実際にチームでやってみてわかったことをまとめてみました
- AI Readyな設計書を目指して。人もAIも読みやすい設計書管理
- Claude Codeに人生を管理させて3ヶ月、一番効いたのは自動化じゃなかった
- フロントエンドのテスト戦略「テスティングトロフィー」を理解する
- 【解説】実際の値をもとに、ベクトル化などのRAGの仕組みを根本から理解しましょう
するとClaudeが傾向をこう分析してくれました。
5記事に共通するのは「AIと開発をどう噛み合わせるか」という関心。実装ノウハウより「仕組みの腹落ち」と「チーム/個人での実践知」を重視する選び方
キーワードとして自分で設定していたのは「生成AI・MCP・デザイン・フロントエンド」でしたが、実際の好みはもう一段深いところ(仕組みの腹落ち・実践知)にあった、というのが言語化されたのは面白い体験でした。
ログの設計
ログは、MCPサーバーとは別に、Claude Desktopが読み書きできる作業フォルダの中に置いています。パスのイメージはこうです。
/Users/<あなたのPCユーザー名>/Documents/works/ClaudeDT/ # ← ここは自分の環境に合わせて変える
└── log/
├── 2026-06-15.md
├── 2026-06-16.md
├── 2026-06-17.md
└── 2026-06-23.md # 日付ごとに1ファイル
後から分析しやすいよう、次の方針で構造化しています。
-
日付ごとに1ファイル:
log/2026-06-15.mdのような形式 - frontmatter + テーブル: 件数が増えても機械的に傾向分析できる形
- 著者・テーマ・LGTM数・URL を列に持ち、末尾に その日の傾向メモ を記録(共有時点でLGTM数が不明な場合は空欄)
実際のログはこんな形です(筆者名は伏せています)。
---
date: 2026-06-17
source: Qiita
type: 良かった記事ログ
count: 3
tags: [ローカルLLM, Ollama, RAG, 長期記憶, ClaudeCode, 並列エージェント, ハンズオン, アーキテクチャ, 多言語NLP, 運用基準]
---
# 良かった記事ログ 2026-06-17
筆者が「良かった」と共有した記事の記録。今後の傾向分析に使用する。
| # | タイトル | 著者 | テーマ | LGTM | URL |
|---|---------|------|--------|------|-----|
| 1 | 【完全ローカル】AIに記憶を持たせる5ステップ … | (著者) | ローカルLLM / RAG / 長期記憶 | - | ... |
| 2 | Claude Codeでつくる「並列ループエージェント」… | (著者) | Claude Code / 並列エージェント | - | ... |
| 3 | AIアバターシステムのアーキテクチャ分析 … | (著者) | アーキテクチャ / 多言語NLP / 運用基準 | - | ... |
## メモ
- 1番はローカルLLM×RAGで「記憶」を作るハンズオン。RAG関心の延長。
- 2番はClaude Codeの並列ループエージェント実践。エージェント運用への継続関心。
- 3番はAIアバターの実アーキテクチャ分析。仕組み・設計・運用基準の両立という腹落ち重視傾向と一致。
frontmatter に日付・件数・タグを持たせ、テーブルで1記事1行、末尾のメモで「なぜ響いたか/過去の関心とどうつながるか」を残すのがポイントです。このメモが、後から傾向を読むときに効いてきます。
ステップ3: 定期配信にログを読ませる
仕上げとして、平日朝の配信タスクが logフォルダを読んでから記事を選ぶ ように連携しました。これはClaude側からの「ログが溜まるほど精度が上がるので連携しませんか」という提案に乗った形です。
毎朝の実行はこう動きます。
効果は選定の「軸」に表れました。最初の5記事に対してClaudeが提案してきた類似記事は、AI駆動開発・要件定義 / Claude Codeとエージェント運用 / RAG・テスト戦略 という軸で整理されていて、単なるキーワード一致より一段深い選定になっていました。たとえば「テスティングトロフィー」の記事に対して同じ著者のテストピラミッド解説を、「AI Ready設計書」に対してAIエージェントによるナレッジ運用の記事を、それぞれ「地続きの内容」として拾ってくる、といった具合です。
ログが育っていく: 数日後に共有した記事
数日後(6/17)に共有したのが次の3記事です。いずれも公開記事なのでリンクを付けています。
- 【完全ローカル】AIに記憶を持たせる5ステップ — Ollama×RAGでつくる長期記憶チャットボット — ローカルLLM / RAG / 長期記憶
- Claude Codeでつくる「並列ループエージェント」実践！ハンズオンガイド — Claude Code / 並列エージェント / ハンズオン
- AIアバターシステムのアーキテクチャ分析 - AI・多言語NLPと日本国内の厳格な運用基準を両立する課題への挑戦 — アーキテクチャ / 多言語NLP / 運用基準
興味深いのは、この3記事がすべて 最初の5記事で見えていた関心の延長線上にあった ことです。1番はRAGへの関心が「完全ローカルで記憶を作る」方向に展開したもの、2番はエージェント運用への継続的な関心、3番は「仕組み・設計・運用基準の両立」という腹落ち重視の傾向とそのまま一致していました。ログのメモ欄には、こうした「過去の関心とのつながり」を毎回書き残しています。回を重ねるほど、この繋がりの記述が好みの輪郭をはっきりさせていきます。
実際の配信はこうなった
しばらく運用したあとの、実際の配信結果(2026-07-07)がこちらです。この時点でログは4件(6/15〜6/23、計22記事)まで溜まっており、その傾向を反映して直近2日のトレンドから7本が厳選されました。ログに記録済みの記事とは重複しない ようにも配慮されています。
- AI Agent 時代は「うまく指示する」より「未知を見つける」が大事 — 判断・思考の腹落ち重視の好みにど真ん中(👍4・伸び4.9/日)
- grill-me がバズった Matt Pocock の Claude Code skills リポジトリを一通り眺めてみた — Agent Skills自作への継続関心に直結
- プロンプトを磨くのはもう古い?「コンテキストエンジニアリング」に片足を突っ込む話 — プロンプトからコンテキスト全体設計への視点転換
- Claude Codeの dataviz スキルが凄かった — スキル運用の実力を測る好例(👍25・伸び7.6/日)
- LLMにSQLを生成・実行させる際に注意したこと※AWS編 — 6/15に良かったAI-DLC記事と同じ著者の実践知
- 「日本企業風GitHub」のパロディに学ぶ、なぜJTC業務システムは「警告と文字」で埋め尽くされるのか — 直近2日で最も伸びている記事(👍96・34.1/日)
- 「保守業務って地味…」と思っていた新人の自分へ — 「人・チーム」系の関心に(👍48・26.8/日)
配信の最後には、こんな補足も付いてきました。「RAG・ベクトル化、1on1・マネジメント、フロントエンドテストは直近2日に合致する新着がなかった。人気タグはAIエージェント / ClaudeCode / AWS が上位で、大きな新興トピックは見られない」。足りなかった観点まで正直に報告してくれる のが、単なる記事一覧との大きな違いです。
5番のように「過去に良かった記事と同じ著者の新作」を拾ってきたり、6・7番のように「いま最も伸びている記事」を好みの文脈で意味づけしたりと、ログの蓄積が効いているのが見て取れます。
運用してみて気づいた注意点
アプリが開いている間しか実行されない
スケジュールタスクはPCが起動中でClaude Desktopアプリが開いている間のみ実行されます。閉じていた場合はスキップされ、次回起動時に自動実行されます。完全な無人サーバー運用ではありませんが、毎朝PCを開く運用なら実害はありません。
日付のずれ
ログ記録の際、Coworkで前回のログ記録チャットにそのまま送ってしまうと、記事が前日のログに追記されてしまうことがありました。指摘すると、追記分を正しい日付のファイルへ移し、保存してくれました。
この仕組みをチャットだけで組んだ、ということ
振り返ると、自分がやった操作は次の3つだけです。
- チャットで「定期配信して」と頼む(→ スケジュールタスク作成)
- 良かった記事のURLを貼る(→ 構造化ログとして保存)
- Claudeの「ログと配信を連携しませんか」という提案に乗る
ログのフォーマット設計(frontmatter+テーブル)も、傾向分析も、連携もClaude側の仕事です。「自動化パイプラインを組む」のではなく「運用を会話で育てる」感覚に近く、テーマの追加・除外や配信本数の調整も頼むだけで済みます。
まとめ
- Coworkのスケジュールタスクは新しいセッションでMCP・ローカルファイル両方に触れるので、「取得 → 蓄積 → 学習」のループが組める
- 明示的な好み(キーワード)から始めて、暗黙的な好み(ログからの傾向分析)へ育てていける
- フィードバックは「良かった記事のURLを貼るだけ」。運用コストがほぼゼロなのが続く理由
MCP紹介記事