N&S Logo

Claude Codeで研究・記事・分析を自動化する7ステップ

更新: 7/10
読了: 約32
字数: 12,492文字
Claude Codeで研究・記事・分析を自動化する7ステップ

Claude Codeに触るたび、何が動いているか分からず作業が止まる。

多くのリサーチャーやライターが抱えるこのフラストレーションの正体は、スキルの重複と巨大化したシステムプロンプトにあります。役割が混ざるとモデルは“何でも屋”になり、無駄な処理や不透明な中間生成物が作業効率を奪います。本記事はその曖昧さを排し、研究・記事・分析を自動化するための7つの実践ステップを示します。各ステップは「何を」「誰が」「どう検証するか」を明確に分離する設計になっており、テンプレートとチェックリストで動作を可視化。論文検索から構成作成、定量分析までの実例を交え、今日から試せる改善策を丁寧に解説します。

そもそもどう動くのか

家のPCの前にいないと作業が進まない──そんな「人間がハブ」になってしまう運用を変えたい人向け。

仕組みを噛み砕くと、Claude Codeは「スキル群(自動化モジュール)+セッション内プロンプト」で動く、生成AIとは運用目的が違う“エージェント寄り”の仕組みである。実務的にはスキルを整理してプロジェクト単位で構成し、外部知識をベクトル検索で組み込んで(RAG)回し、テストと監視で劣化を検出するループを回すと安定する。Claude Code 2.1.206 では /cd にディレクトリ候補表示が追加され、/doctor がチェックイン済みの CLAUDE.md を短縮提案する挙動が検証されている。

  1. スキルの棚卸しと削減
  • 実行: プロジェクトルートで /doctor を走らせる。
  • 例:
/cd path/to/project
/doctor
  • 出力を見て、使われていない CLAUDE.md やスキルを git で切る(git rm)か内容を切り詰める。
  1. ディレクトリとドキュメントの紐付け
  • /add-dir で参照するドキュメントを登録する。
/add-dir docs/
/cd docs/
  • こうするとスキルが参照するデータの範囲が明確になる。
  1. セッションプロンプト(初期指示)を固定化
  • 最初に渡すプロンプトをテンプレ化してセッションにセットする。例:
Goal: 「要点抽出して3つのアクションを提案する」
Constraints: 最新のdocs/のみ参照
  • これでスキルがぶれにくくなる。
  1. 外部知識(RAG)を作る
  • ドキュメントを埋め込み→ベクトルDBにインデックス。ローカルスクリプトでバッチ化するのが現場向け。
  • 例(概念):python embed_docs.py docs/ --index my_index→ セッションはクエリで近傍を取得して参照。
  1. プロキシで通信を可視化
  • ローカルプロキシ(例: mitmproxy)を立て、どのプロンプト/スキルが呼ばれているか確認。
mitmproxy -p 8080
# クライアントをプロキシ経由にして通信ログを観察
  • 不要な呼び出しはスキルの無効化で切る。
  1. テストを自動化する
  • 固定入力(smoke test)で期待出力を比較する。CI に組み込み、差分が出たらアラート。
  • 例:curl -X POST http://localhost:8080/session -d @tests/smoke_input.jsonでレスポンスをスナップショット比較。
  1. 監視と運用ルール
  • 定期的に /doctor を回してドキュメント肥大化を検出。RAG のインデックス更新頻度を決める(例: 週次)し、ログでレイテンシ・失敗率を監視する。

まとめ:手順は「スキル整理→プロジェクト化→RAG→プロキシ観察→テスト/監視」のループ。まずはプロジェクトルートで /doctor を実行して不要なCLAUDE.mdを見つけるところから始めてみてください。

① スキルとシステムプロンプトの監査(まずはクリーン)

家のプロンプトが肥大化して、何を返してくるか予測できない——そんな状態で自動化は始められない。

そもそもどう動くのか:Claude Codeのセッションには「チェックインされたスキルやCLAUDE.mdの内容」が入り、実際に送信されるプロンプトはクライアント→サーバ間のリクエスト本文に含まれる。/doctor はローカルにチェックインされたCLAUDE.mdの冗長箇所を見つけて「ここを切れ」と提案するツールで(検証済み事実: Claude Code 2.1.206に追加)。mitmproxy等でプロキシを立てれば、ブラウザやCLIが送る「実際のプロンプト」を検査できる。

  1. セッションで /doctor を実行する
    • セッション入力欄に /doctor と打つ。出力をテキストで保存しておく(コピー&ファイル保存)。
  2. CLAUDE.md をバックアップして差分確認
    • gitを使っているならgit checkout -b audit/claude-md-backupを作る。/doctorの提案と現ファイルを比較。
  3. ローカルプロキシを起動(mitmproxy例)
    • ターミナルで:mitmproxy -p 8080を実行。
  4. 環境変数でアプリをプロキシ経由にする
    • macOS/Linux:
      export HTTP_PROXY=http://localhost:8080
      export HTTPS_PROXY=http://localhost:8080
      
    • PowerShell:
      $env:HTTP_PROXY='http://localhost:8080'
      $env:HTTPS_PROXY='http://localhost:8080'
      
  5. セッション操作を再現してリクエストをキャプチャ
    • プロキシ経由で通常通り操作し、mitmproxyの画面で流れるリクエストを観察。
  6. 送信されるプロンプト本文を抽出して確認
    • 保存した流れをファイルに書き出す:mitmdump -w flows.mitm。mitmproxyのFlow詳細で system / user / assistant の順に送られる内容をチェック。CLAUDE.mdの全文や機密情報(APIキーやトークン)が混入していないかgrep -nE '(API_|APIKEY|token|secret)' CLAUDE.mdで確認。
  7. 最小化して再検証、コミット
    • /doctor の提案に従い不要な説明や冗長な例を削る。再度プロキシで送信確認したらコミット。コミットメッセージは「audit: trim CLAUDE.md per /doctor suggestions」。

まとめ まずは /doctor を実行して出力をファイルに保存し、mitmproxyで実際に送られるプロンプトをキャプチャしてください。次の一歩は、その出力とキャプチャ結果を突き合わせてCLAUDE.mdを最小化することです。

② プロジェクト構成とディレクトリ管理をルール化

作業が止まる最大の原因は「どのフォルダに何があるか分からず、探すたびに中断する」ことだ。

そもそもどう動くのか:Claude Code はセッション内で作業パスを切り替える /cd と、永続的にパス候補を登録する /add-dir を使える。最近の変更(Claude Code 2.1.206)で、/cd が /add-dir と一致するパス候補を提案するようになったため、ローカル構成を固めておくとClaude側で迷わず移動できる。さらに /doctor でチェックして不要に長い CLAUDE.md を短くする提案も出る。

7ステップ

  1. プロジェクトルールを決める
    コピペで使える標準構成を決める。例:docs/(ドキュメント)/skills/(スニペット)/data/(生データ)/templates/(テンプレ)
mkdir -p myproj/{docs,skills,data,templates} && cd myproj && git init
  1. 最低限の説明ファイルを置く
    プロジェクト概要は短く CLAUDE.md にまとめる(長くなり過ぎない)。
echo "短い概要: 目的、主要データ、作業ディレクトリ" > CLAUDE.md
git add CLAUDE.md && git commit -m "Add CLAUDE.md"
  1. ローカルパスをClaude用に登録する(/add-dir)
    Claude セッションにて、プロジェクトルートと主要サブディレクトリを登録する。例:
/add-dir /home/you/projects/myproj "myproj root"
/add-dir /home/you/projects/myproj/data "myproj data"
/add-dir /home/you/projects/myproj/docs "myproj docs"
  1. 作業時は /cd でコンテキスト切替
    作業を始めるたびに /cd で作業パスへ移動。2.1.206 以降は /cd が /add-dir 登録を候補として提示するので候補から選ぶだけで速い。例:
/cd myproj/docs
  1. 名前付けと相対パス規約を決める
    チームで「data/raw」「data/processed」など細分化のルールを決め、必ず /add-dir に登録する。相対パスで参照するルールをREADMEに明記する。

  2. 定期チェックと整理(/doctor を活用)
    コミット済みの CLAUDE.md が肥大化していたら、Claude の /doctor にチェックさせ、不要部分の削除案を受ける。実行は人間が確認して反映する。

  3. 設定のテンプレ化と自動化準備
    新規プロジェクト作成をワンライナー化しておく。例: setup.sh を作り、ローカル作成→git init→CLAUDE.md 作成まで自動化。Claude 登録用の /add-dir 行はファイルに出力しておき、セッションでコピペ登録する。

まとめ:ローカルでディレクトリ構成を固定し、/add-dir でClaude側にも登録、作業前に /cd でコンテキストを切り替えれば中断が減る。まずは次の一手:ターミナルで

mkdir -p myproj/{docs,skills,data,templates} && cd myproj && git init

を実行して、Claude に /add-dir で登録してみてください。

③ プロンプトテンプレを作ってCLAUDE.mdを最小化

家のPCの前でテンプレを探してコピペしている時間が一番ムダだ。

そもそもどう動くのか:テンプレをリポジトリの templates/ に置いておけば、セッション開始時は「テンプレを読み込む」だけで済む。テンプレはプレーンテキスト(あるいはマスターファイル)なので、catで表示してそのままセッションに貼るか、UIのファイルアップロード機能に放り込めば再利用できる。さらに Claude Code の /doctor がリポジトリにある CLAUDE.md の削減案を出すので、チェックインされた冗長な指示はそちらで整理しておくと管理が楽になる(Claude Code 2.1.206 に /doctor の提案機能が追加されたことを確認済み)。

  1. templates/ フォルダを作る(最初のファイル登録)
mkdir -p templates
echo "# article template\n{{instructions}}" > templates/article.md && git add templates/article.md

上のコマンドは即座にファイルを作り、git に追加する最短例。

  1. 記事テンプレを具体化する(プレースホルダを決める)
cat > templates/article.md <<'T'
# タイトル: {{title}}
## 概要
{{summary}}

## 指示
{{instructions}}

## 参考(出典)
{{sources}}
T
git add templates/article.md

必ず「タイトル・要約・指示・出典」を分けておくと、セッションでの差し替えが簡単。

  1. 分析テンプレを作る(再現手順を含める)
cat > templates/analysis.md <<'T'
# 分析: {{name}}
- データ: {{data_path}}
- 前処理: {{preprocess_steps}}
- 手法: {{method}}
- 出力: {{expected_outputs}}
- 再現コマンド:

python run_analysis.py --data {{data_path}} --out results/

T
git add templates/analysis.md

実行コマンドを明記しておけば、Claudeに「この行を含めて説明して」と指示できる。

  1. テンプレをコミットして保護する
git commit -m "Add templates for article and analysis" templates/

テンプレは履歴に残しておくと誰でも同じ定型を使える。

  1. セッションでテンプレを読み込む具体手順 ローカルでテンプレの中身を表示して、そのままセッションに貼るのが最も確実。
cat templates/article.md

UIでファイルをアップロードできる場合は templates/ をアップロードして「ファイルから読み込む」を使う。いずれにせよ手動で貼るのが一番互換性が高い。

  1. CLAUDE.md は /doctor に従ってトリミングする セッションで/doctorを実行して提案を受け、その指示に合わせて CLAUDE.md を編集する。 ローカルで編集してコミットする例:
vim CLAUDE.md   # /doctor の提案に従って不要部分を削る
git add CLAUDE.md && git commit -m "Trim CLAUDE.md per /doctor suggestions"

(注)Claude Code 2.1.206 に /doctor がチェックイン済み CLAUDE.md のトリミング提案を行う機能が追加されている点は検証済み。

  1. 起動を少し自動化する(ワンライナーでテンプレを表示) セッション開始時にテンプレをすぐ取り出せるよう小さなスクリプトを置くと楽。
mkdir -p scripts
cat > scripts/show_article_template.sh <<'S'
#!/bin/sh
cat templates/article.md
S
chmod +x scripts/show_article_template.sh

セッション開始時に./scripts/show_article_template.shを実行して表示→貼り付け、がワークフロー化しやすい。

まとめ:templates/ にテンプレを置き、セッションでは cat して貼るだけにすれば作業が劇的に速くなる。まずは今回示した echo コマンドで templates/article.md を作って git 管理に入れることから始めてください。次の一歩:templates/article.md を1つ作って、実際に Claude セッションで貼って試してみる。

④ ベクトルDBでRAGを組み込み(外部知識を効率化)

家のフォルダに必要な情報が眠ったままで、Claudeに聞いても「それは知らない」と返される――そんなイライラを解消する。

そもそもどう動くのか:文書をベクトル化(埋め込み)してベクトルDBに入れておく。質問が来たら類似検索で関連文を取り出し、その抜粋をClaudeへコンテキストとして渡す。仕組みが分かれば、あとは「埋める→索引化→検索→注入」の繰り返しだ。

  1. 文書を集めて正規化する
  • PDFならpdftotextでテキスト化、Markdown/HTMLはプレーン化。例:
find docs/ -name '*.pdf' -exec pdftotext {} {}.txt \;
  1. テキストをチャンクに分割する(検索精度のため)
  • 1チャンクあたり約1500–3000文字を目安に。簡単なPythonで実行:
# chunker.py
text = open('doc.txt','r',encoding='utf-8').read()
for i in range(0, len(text), 2000):
    open(f'chunks/doc.{i//2000}.txt','w',encoding='utf-8').write(text[i:i+2000])
  1. 埋め込みライブラリを入れて実行する
  • まず必要パッケージを入れる(ローカル実行例):
pip install faiss-cpu sentence-transformers
python embed.py --src docs/ --out faiss.index
  • embed.pyは「テキストを埋め込み、FAISSフォーマットで保存する」スクリプトである想定。出力はベクトルとメタ(ファイル名/オフセット)。
  1. FAISSにインデックスを作る(スクリプト例)
import faiss, numpy as np
embs = np.load('embeddings.npy')  # shape=(n,d)
index = faiss.IndexFlatIP(embs.shape[1])
index.add(embs)
faiss.write_index(index, 'faiss.index')
  1. 検索API(ローカル)を用意する
  • シンプルにsearch.pyでクエリを受けて上位kを返す:
python search.py --index faiss.index --q "研究の要点は何か" --k 5
  • 結果は[スニペット, ソース]のリスト形式で返す設計にする。
  1. Claudeへ渡すプロンプトを組み立てる
  • 検索結果をそのまま渡すと冗長になるので、上位3件をコンテキスト化してプロンプトに埋める。例:
System: 以下はあなたが参照可能なドキュメント抜粋です。出典を示して要点を回答してください。
Context:
1) <抜粋A> (source: fileA.md)
2) <抜粋B> (source: fileB.pdf#page3)
Question: <ユーザーの質問>
  1. Claudeに送信してRAGを回す(例:HTTP/requests)
  • 環境変数でAPIキー管理し、POSTする。雛形:
import os, requests, json
resp = requests.post(os.environ['CLAUDE_API_URL'],
    headers={'Authorization':f"Bearer {os.environ['CLAUDE_API_KEY']}"},
    json={'prompt': full_prompt})
print(resp.json())
  • 返答は元の抜粋と照らし合わせて妥当性を検証する(必ず出典を付ける)。

まとめ:手元ドキュメントを埋め込み→FAISSで索引→検索結果をClaudeへ注入する流れがRAGの核だ。まずは示したコマンドでembed.pyを動かし、faiss.indexを作ることを次の一歩にしよう。

⑤ スキル(automation)の作成と設定反映

家のPCの前でしか動かない自動化、もう嫌じゃないですか?

そもそもどう動くのか:Claude Codeでは、skills/配下に置いたモジュールがsettings.jsonのskills配列で指されているとランタイムが読み込む。つまり「モジュールを作る」→「settings.jsonで有効化」→「ランタイムに再読込」をすれば機能する。仕組みが分かれば後は手順の繰り返しで運用できる。

  1. スキルのディレクトリと最小コードを作る
    例として要約スキルを作る。init.py を置くとimportしやすい。
mkdir -p skills/summarize
echo "def handle(text):\n    return text[:200]  # 簡易サマリ" > skills/summarize/main.py
touch skills/summarize/__init__.py
  1. ローカルでモジュールを検証する
    Pythonから直接インポートして動作確認。
python -c "from skills.summarize import main; print(main.handle('長い本文...'))"
  1. settings.jsonにスキルを追加する(安全に編集)
    jqを使って追記する例(tmpを経由して原子的に上書き):
jq '.skills += ["skills/summarize"]' settings.json > tmp && mv tmp settings.json
  1. 不要なスキルを外す(例)
    古いパスを取り除くにはmap/selectでフィルタする:
jq '.skills |= map(select(. != "skills/old_skill"))' settings.json > tmp && mv tmp settings.json
  1. 配置順や優先度を整理する
    配列を書き換えて順序を固定する例:
jq '.skills = ["skills/summarize","skills/qa"]' settings.json > tmp && mv tmp settings.json
  1. 変更を反映(ランタイム再読込)
    多くの開発環境はsettings.jsonの変更を監視するが、監視がない場合はランタイムを再起動する。開発サーバなら一旦停止して再起動(例: Ctrl+C → npm run dev など)。確実に反映されているかログで確認する。

  2. 実運用での動作確認(エンドツーエンド)
    スキルを経由する簡易ラッパーで入出力テスト:

echo '{"text":"要約してほしい本文"}' > sample.json
python - <<'PY'
import json
from skills.summarize import main
print(main.handle(json.load(open('sample.json'))['text']))
PY

まとめ:skills/にモジュールを置き、settings.jsonで有効化・整理し、ランタイムを再読込すれば自動化が動く。まずは今回の手順で1つスキルを作ってsettings.jsonに追加し、ローカルで動作確認してみてください。

⑥ テストとCIで回帰を防ぐ(自動化の信頼性確保)

家のPCでしか動く仕組みを確認していては、本番で壊れたときに血反吐を吐く。

そもそもどう動くのか:Claude Codeを使った自動化は「スキル」(小さな機能単位)を組み合わせて動く。各スキルごとにユニットテストを書き、ローカルで通す→CIで毎回実行して落ちないことを担保する。仕組みが分かれば、あとでモックやカバレッジの閾値を足すだけで信頼性が上がる。

  1. スキル単位でテスト骨格を作る
  • ディレクトリとテンプレートを作る:
    mkdir -p tests && echo "def test_skill_example(): assert True" > tests/test_skill_example.py
    
  1. ローカルでまず通す(確認ワンライナー)
  • pytestを入れて素通り確認:
    pip install pytest && echo "def test_dummy(): assert True" > tests/test_dummy.py && pytest -q
    
  1. 外部APIはモックする
  • requestsなど外部呼び出しがある場合はrequests-mockを使う例:
    pip install requests-mock
    echo "import requests, requests_mock
    def test_api(mock):
        with requests_mock.Mocker() as m:
            m.get('https://api.example/ok', text='ok')
            assert requests.get('https://api.example/ok').text == 'ok'" > tests/test_api.py
    pytest -q
    
  1. 仮想環境で依存を固定して実行
  • reproducibleにする:
    python -m venv .venv && source .venv/bin/activate
    pip install -r requirements.txt
    pytest -q
    
  1. CI設定を用意してGit pushで起動させる(GitHub Actions例)
  • .github/workflows/ci.yml(最小構成):
    on: [push, pull_request]
    jobs:
      test:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - uses: actions/setup-python@v4
            with: {python-version: '3.x'}
          - run: pip install -r requirements.txt
          - run: pytest -q
    
  1. キャッシュと成果物で早く安定化させる
  • pipキャッシュやカバレッジを残す: actions/cacheやupload-artifactを利用。CI内でのコマンド例:
    pip install coverage
    coverage run -m pytest
    coverage report --fail-under=80
    
  1. ローカルガードとマージ条件を作る
  • pre-commitで基本ルールを自動化し、PRマージにCI必須ルールを設定:
    pip install pre-commit
    pre-commit install
    pre-commit run --all-files
    

まとめ:スキルごとのテスト+ローカル確認→CIで毎回実行、という流れを作れば回帰は激減する。まずは今のリポジトリにtestsディレクトリを置き、上記のローカル確認ワンライナーを実行してからGitにpushしてCIを回してみてください。

⑦ 監視・ログ・改善ループ(運用で磨く)

家のPCの前にいないと運用の不具合に気づかない、という状況をなくしたい人向け。

そもそもどう動くのか:運用では「実際の入出力(ログ/プロキシで見える通信)」を定期的に拾って傾向を掴み、問題のパターンが出たら設定を絞り込み/ドキュメントを切り詰めてモデルの負担を減らす。Claude Code 2.1.206 では /doctor チェックが追加され、手動での診断→提案(CLAUDE.md の切り詰めなど)が可能になっている。ここでは手を動かせる7ステップを示す。

  1. ログの常時監視を始める

    • サーバ上でリアルタイム確認:
      tail -f logs/claude.log
      
    • 直近のエラーだけ拾う:
      grep -i "error" logs/claude.log | tail -n 50
      
  2. 通信をプロキシで可視化する

    • mitmproxy を起動して記録/可視化:
      mitmproxy -w mitm.log
      mitmweb -p 8081
      
    • クライアントのプロキシ設定を mitmproxy に向け、mitmweb の画面で失敗パスを確認する。
  3. /doctor を定期的に実行する(手動→自動のフロー)

    • まず手動で Claude Code のセッションに "/doctor" を送り診断を確認。提案内容(CLAUDE.md の切り詰め等)を受け取る。
    • 自動化は「実行を忘れない」ためのリマインドを入れる(例:cronで通知)。
      # /etc/cron.d/claude_doctor_reminder
      0 9 * * Mon ubuntu DISPLAY=:0 notify-send "Run /doctor in Claude Code"
      
  4. /doctor の提案を適用する(CLAUDE.md の切り詰め)

    • 提案に基づきファイルを短くする例(先頭200行だけ残す):
      head -n 200 CLAUDE.md > CLAUDE.md.trimmed && mv CLAUDE.md.trimmed CLAUDE.md
      
  5. settings.json で冗長ログや高頻度オプションを削る

    • 編集例(バックアップを作ってから編集):
      cp settings.json settings.json.bak
      jq '.logging.level="warn"' settings.json > settings.tmp && mv settings.tmp settings.json
      
    • 変更後はサービス再起動を忘れずに。
  6. アラートの自動化(簡易)

    • ログ内の致命的エラーをメール送信する簡易スクリプト例:
      grep -i "fatal\|panic" logs/claude.log | tail -n 20 | mail -s "Claude alert" [email protected]
      
    • 上のスクリプトを cron に入れて即時検知を補助する。
  7. 改善ループを回す(週次レビュー)

    • 週1回、mitm.log、claude.log、/doctor の出力を並べて差分を出す。差分の多いパラメータ(大きなCLAUDE.mdや冗長なログ設定)を次回で削る決定をする。

まとめ:まず今日1回、tail でログを見て mitmproxy を立て、手動で /doctor を実行して提案内容を確認してください。次はその提案を反映する(CLAUDE.md の切り詰め or settings.json の調整)ことを一つのタスクにしてください。

まとめ

この記事では、目標設定・データ準備・プロンプトテンプレ化・反復改善・パイプライン自動化・評価と監視・ドキュメント化、の7つのステップで研究や記事作成、分析をClaude Codeで再現性高く自動化する方法をまとめました。まずはお使いのClaude Codeセッションで /doctor を実行し、CLAUDE.mdの肥大箇所を洗い出すことを次の一歩にしてください。

📱 関連ショート動画

この記事の内容をショート動画で解説

横にスクロールできます

著者について

原田賢治

原田賢治

代表取締役・AI技術責任者

Mike King理論に基づくレリバンスエンジニアリング専門家。生成AI検索最適化、ChatGPT・Perplexity対応のGEO実装、企業向けAI研修を手がける。 15年以上のAI・システム開発経験を持ち、全国で企業のDX・AI活用、退職代行サービスを支援。