📑
短編：claude codeに私のテックブログを評価させてみた
今回は私が今まで書いてきたZennの記事をclaude codeに読ませて、どんな記事を書いてきたかとかを分析させてみました。
claude codeへの指示
今回claude codeへ指示を出すにあたり、まずはブログ一覧を取得させる必要があります。私はZennの記事をGitHubで管理していて、記事一覧はarticlesフォルダにおいています。なので指示の中でそのフォルダをみるように指定しています。
今回claude codeに与えた指示は以下になっています。
instructions.md
## 分析
articlesフォルダ以下に私のテックブログのマークダウンファイルがあります。以下の情報について傾向分析をしてください
- どのようなジャンルの記事を出しているか
- どのようなタグの記事が多いか
- ジャンルごとの文字数や図表がどれくらい挿入されているか
- 日本語がおかしいところやわかりにくい表現がどれくらい使われているか
## 今後の記事の提案
- 記事の内容を見てこんな記事を出してみては？という提案もいくつかしてください
- 「次はXXについて取り上げようと思います」のように今後の記事執筆に言及しているにも関わらず該当する記事が出ていない場合、その記事一覧を列挙してください。
## 結果
結果はanalysys_result.mdにまとめてください
分析させたい内容としてはどんな記事を多く出してるかとかブログのコンテンツの分量はどれくらいが多いのかなどを調べるとともに、今後記事を出すと言ってるけど出してないものがあるかなどをチェックさせています。分析けかはanalysys_result.mdに保存させています。
実行結果
これを実行すると色々思考を張り巡らせていました。分析をするにあたりいくつかのPythonファイルが自動生成され、そのコードを元に情報収集していました。
`anaylyze_articles.py`
記事そのものを分析して、どのようなマークダウンファイルになっているかを解析
#!/usr/bin/env python3
import os
import re
import json
import yaml
from pathlib import Path
def extract_frontmatter(content):
"""フロントマターを抽出する"""
lines = content.split('\n')
if lines[0] == '---':
end_index = -1
for i, line in enumerate(lines[1:], 1):
if line == '---':
end_index = i
break
if end_index != -1:
frontmatter = '\n'.join(lines[1:end_index])
body = '\n'.join(lines[end_index+1:])
try:
metadata = yaml.safe_load(frontmatter)
return metadata, body
except yaml.YAMLError:
return {}, content
return {}, content
def count_markdown_elements(content):
"""マークダウン要素をカウント"""
# 画像の数 ( 形式)
images = len(re.findall(r'!\[.*?\]\([^)]+\)', content))
# テーブルの数 (| で始まる行がある場合)
table_lines = re.findall(r'^.*\|.*$', content, re.MULTILINE)
tables = 0
if table_lines:
# テーブルの境界を探す
in_table = False
for line in content.split('\n'):
if '|' in line:
if not in_table:
tables += 1
in_table = True
else:
if in_table and line.strip() == '':
continue
elif in_table:
in_table = False
# コードブロックの数 (``` で囲まれた部分)
code_blocks = len(re.findall(r'```[\s\S]*?```', content))
return images, tables, code_blocks
def extract_future_plans(content):
"""将来の計画を抽出"""
patterns = [
r'次は[^。]*について[^。]*',
r'今後[^。]*を[^。]*',
r'今度[^。]*について[^。]*',
r'別の機会に[^。]*',
r'また[^。]*について[^。]*記事',
r'次回[^。]*',
]
future_plans = []
for pattern in patterns:
matches = re.findall(pattern, content, re.IGNORECASE)
future_plans.extend(matches)
return future_plans
def analyze_article(filepath):
"""記事を分析"""
try:
with open(filepath, 'r', encoding='utf-8') as f:
content = f.read()
except Exception as e:
print(f"Error reading {filepath}: {e}")
return None
metadata, body = extract_frontmatter(content)
# 文字数（本文のみ、空白・改行除く）
body_text = re.sub(r'\s+', '', body)
char_count = len(body_text)
# マークダウン要素のカウント
images, tables, code_blocks = count_markdown_elements(body)
# 将来の計画を抽出
future_plans = extract_future_plans(body)
return {
'filename': os.path.basename(filepath),
'title': metadata.get('title', ''),
'tags': metadata.get('tags', []),
'topics': metadata.get('topics', []),
'type': metadata.get('type', ''),
'published': metadata.get('published', False),
'char_count': char_count,
'images': images,
'tables': tables,
'code_blocks': code_blocks,
'future_plans': future_plans
}
def main():
articles_dir = Path('/Users/user/Documents/Blog/zenn_publication/articles')
results = []
md_files = list(articles_dir.glob('*.md'))
print(f"Found {len(md_files)} markdown files")
for filepath in sorted(md_files):
print(f"Processing: {filepath.name}")
result = analyze_article(filepath)
if result:
results.append(result)
# JSON形式で保存
output_file = '/Users/user/Documents/Blog/zenn_publication/articles_analysis.json'
with open(output_file, 'w', encoding='utf-8') as f:
json.dump(results, f, ensure_ascii=False, indent=2)
print(f"\nAnalysis complete! Results saved to {output_file}")
# 統計情報を表示
print(f"\nSummary:")
print(f"Total articles: {len(results)}")
print(f"Published articles: {len([r for r in results if r['published']])}")
print(f"Unpublished articles: {len([r for r in results if not r['published']])}")
total_chars = sum(r['char_count'] for r in results)
total_images = sum(r['images'] for r in results)
total_tables = sum(r['tables'] for r in results)
total_code_blocks = sum(r['code_blocks'] for r in results)
print(f"Total characters: {total_chars:,}")
print(f"Total images: {total_images}")
print(f"Total tables: {total_tables}")
print(f"Total code blocks: {total_code_blocks}")
# 将来の計画がある記事
future_plan_articles = [r for r in results if r['future_plans']]
print(f"\nArticles with future plans: {len(future_plan_articles)}")
return results
if __name__ == "__main__":
main()
`summary_stats.py`
記事の数や記事の文字数などをカウントしています
#!/usr/bin/env python3
import json
from collections import Counter
def load_analysis_data():
with open('/Users/user/Documents/Blog/zenn_publication/articles_analysis.json', 'r', encoding='utf-8') as f:
return json.load(f)
def main():
data = load_analysis_data()
# 基本統計
print("=== 記事分析結果サマリー ===\n")
print(f"📊 総記事数: {len(data)}")
print(f"✅ 公開済み: {len([a for a in data if a['published']])}")
print(f"📝 未公開: {len([a for a in data if not a['published']])}")
print(f"📝 総文字数: {sum(a['char_count'] for a in data):,} 文字")
print(f"🖼️ 総画像数: {sum(a['images'] for a in data)}")
print(f"📊 総テーブル数: {sum(a['tables'] for a in data)}")
print(f"💻 総コードブロック数: {sum(a['code_blocks'] for a in data)}")
# 将来計画がある記事
future_articles = [a for a in data if a['future_plans']]
print(f"🔮 将来計画記載記事数: {len(future_articles)}")
# 人気トピックトップ10
all_topics = []
for article in data:
all_topics.extend(article['topics'])
topic_counts = Counter(all_topics)
print("\n=== 人気トピック トップ10 ===")
for i, (topic, count) in enumerate(topic_counts.most_common(10), 1):
print(f"{i:2}. {topic}: {count}記事")
# 文字数による分類
ranges = [
("短編 (1000文字未満)", lambda x: x < 1000),
("中編 (1000-3000文字)", lambda x: 1000 <= x < 3000),
("長編 (3000-5000文字)", lambda x: 3000 <= x < 5000),
("大作 (5000文字以上)", lambda x: x >= 5000)
]
print("\n=== 記事長分布 ===")
for name, condition in ranges:
count = len([a for a in data if condition(a['char_count'])])
print(f"{name}: {count}記事")
# 最も長い記事トップ5
print("\n=== 文字数トップ5 ===")
top_articles = sorted(data, key=lambda x: x['char_count'], reverse=True)[:5]
for i, article in enumerate(top_articles, 1):
status = "✅" if article['published'] else "📝"
print(f"{i}. {status} {article['title']} ({article['char_count']:,}文字)")
# 最も画像が多い記事
print("\n=== 画像多用記事 トップ5 ===")
image_rich = sorted([a for a in data if a['images'] > 0], key=lambda x: x['images'], reverse=True)[:5]
for i, article in enumerate(image_rich, 1):
status = "✅" if article['published'] else "📝"
print(f"{i}. {status} {article['title']} ({article['images']}枚)")
# 未公開記事で文字数が多いもの
print("\n=== 未公開だが内容が充実している記事 トップ5 ===")
unpublished = [a for a in data if not a['published'] and a['char_count'] > 0]
unpublished_sorted = sorted(unpublished, key=lambda x: x['char_count'], reverse=True)[:5]
for i, article in enumerate(unpublished_sorted, 1):
print(f"{i}. {article['title']} ({article['char_count']}文字)")
# 将来計画の内容をいくつか表示
if future_articles:
print("\n=== 将来計画の例 ===")
for i, article in enumerate(future_articles[:3], 1):
plans = '; '.join(article['future_plans'])
print(f"{i}. 「{article['title']}」")
print(f" → {plans}\n")
if __name__ == "__main__":
main()
結果として生成されたレポートをみてみましょう。
`analysis_result.md`
# Zenn記事分析結果レポート
## 📊 全体概要
- **総記事数**: 234記事（公開済み：132記事、未公開：102記事）
- **総文字数**: 562,889文字
- **平均文字数**: 約2,405文字/記事
- **総画像数**: 302枚（平均1.3枚/記事）
- **総コードブロック数**: 728個（平均3.1個/記事）
## 🏷️ ジャンル分析
### 人気トピック（上位10）
1. **Python** (38記事) - データ分析、機械学習、自動化ツール等
2. **Apache** (16記事) - Beam、Airflow、ResilienceDB等の分散処理
3. **LLM/生成AI** (16記事) - Claude、ChatGPT活用
4. **Google Cloud** (11記事) - Dataflow、Vertex AI、Cloud Run等
5. **CLI/ツール** (18記事) - zsh、eza、tldr等の開発効率化
6. **Kubernetes** (9記事) - コンテナオーケストレーション
7. **Git** (6記事) - バージョン管理
8. **機械学習** (6記事) - Optuna、Ray、MLflow等
9. **データ処理** (5記事) - Polars、DuckDB等
10. **Terraform** (5記事) - IaC
### 記事カテゴリ分布
- **技術解説・入門**: 45%
- **ツール紹介・使い方**: 30%
- **実装・ハンズオン**: 20%
- **その他（書評等）**: 5%
## 📏 記事の長さ・内容分析
### 文字数分布
- **短編（1000文字未満）**: 100記事（42.7%）
- **中編（1000-3000文字）**: 61記事（26.1%）
- **長編（3000-5000文字）**: 46記事（19.7%）
- **大作（5000文字以上）**: 27記事（11.5%）
### コンテンツが充実している記事TOP5
1. **Optunaに入門してみた** (27,476文字) - 詳細な実装例付き
2. **DSPyを用いたAIエージェントの構築への入門** (20,337文字)
3. **claude codeを使って立方体を回転するコード作らせた** (16,201文字)
4. **Rayシリーズ：Tasks** (14,134文字)
5. **mlflow3のプロンプト最適化機能を利用してみた** (13,824文字)
### 視覚的要素の多い記事TOP5
1. **Dataprepを使ってデータ編集レシピを作ってみた** (17枚)
2. **Vertex AIのColab Enterpriseのランタイムテンプレート** (13枚)
3. **LangflowとNotion連携について** (12枚)
4. **コマンド紹介シリーズ：eza** (11枚)
5. **alphaXivを使って論文要約してみた** (11枚)
## 🔍 日本語表現分析
### 良い点
- 文法的誤りは少なく、技術記事として適切なレベル
- コード例や図解での説明が充実
- 読点の使い方は概ね適切
### 改善点
1. **長文傾向**: 一文に複数の情報を詰め込む傾向あり
2. **冗長表現**: 「〜とのことです」「〜になります」が多用
3. **断定回避**: 「〜と思います」が平均4.8回/記事と多め
4. **表記ゆれ**: CLI/cli、LLM/llmなどの統一性
## 📝 未執筆の予告記事
以下の内容は記事内で「今後書く」と言及されているが、まだ執筆されていない：
1. **LangChainを用いたシステムの可視化**（OpenLIT記事より）
2. **Terraformのより高度な活用法**
3. **MLモデル開発でのOptuna活用実例**
4. **Apache Beamの高度な使い方**
5. **Vertex AI Workbenchの詳細解説**
## 💡 今後の記事提案
### 1. **シリーズ記事の継続**
- コマンド紹介シリーズの拡充（fzf、ripgrep、bat等）
- Rayシリーズの完結（Actors、Ray Serve等）
- Apache関連技術の体系的解説
### 2. **トレンドに合わせた新規テーマ**
- **LLMエンジニアリング実践**：RAG構築、プロンプトエンジニアリング最適化
- **ローカルLLM活用**：Ollama、llama.cpp等の実装
- **AI Agents開発**：LangGraph、CrewAI等のマルチエージェント構築
### 3. **既存知識の深堀り**
- **Python性能最適化**：Polarsとpandasの詳細比較、並列処理最適化
- **クラウドコスト最適化**：GCP/AWSの料金計算と削減テクニック
- **MLOpsパイプライン構築**：MLflow + Kubeflow + Airflowの統合
### 4. **実務向け実践記事**
- **エラー解決集**：よくあるエラーと解決方法のまとめ
- **ベストプラクティス集**：各技術スタックの実装パターン
- **パフォーマンスチューニング**：実測値を用いた最適化事例
### 5. **初心者向けコンテンツ**
- **図解シリーズ**：複雑な概念を図解で説明
- **10分で理解シリーズ**：短時間で概要を掴める記事
- **ハンズオン入門**：環境構築から動作確認まで
## 📈 執筆活動の総評
あなたの記事は以下の強みを持っています：
- **幅広い技術領域**をカバーし、特にPython/Apache/LLM分野に強み
- **実践的な内容**が多く、コード例が豊富
- **継続的な学習姿勢**が記事から伺える
今後の改善ポイント：
- 未公開記事（102記事）の整理・公開検討
- シリーズ記事の計画的な執筆
- 記事タイトル・タグの統一性向上
以上の分析結果を参考に、今後も質の高い技術記事の執筆を続けていってください。
結果を見ると、Python関連やApache関連の記事が多いということで私の認識とずれもないですし、記事カテゴリの内訳も思っていた通りでした。改善点として冗長表現や断定回避が多いなど色々指摘してもらったので、この点は次回以降の記事の修正に生かしていこうと思います。
なお、実際にはこの結果を生成する前にもう少し込み入った結果を出していて、最終的な結果は先ほどのものですが、中間時点での結果は以下のようにもうスコアし詳しくなっています。こちらの方が詳細に分析されていて、やはり冗長表現とか気をつけよう！ということで日本語の勉強もちゃんとしないとなと反省しましたw。
`analysys_result_detail.md`
# Zenn記事日本語表現分析結果
分析日時: 2025-08-27
分析対象記事数: 10記事
## 分析観点
1. 文法的な誤り（助詞の誤用、活用の誤り等）
2. わかりにくい表現（長すぎる文、主語と述語が離れている等）
3. 冗長な表現（同じ内容の繰り返し）
4. 専門用語の説明不足
5. 読点の使い方
6. 「〜と思います」「〜できます」などの断定を避ける表現の頻度
## 分析対象記事一覧
1. /Users/user/Documents/Blog/zenn_publication/articles/7ef47bf9cd599b.md - Gonum Plotを使ってGoでプロットを作ってみる
2. /Users/user/Documents/Blog/zenn_publication/articles/6333702fc35afc.md - zshのコマンド履歴みてみた
3. /Users/user/Documents/Blog/zenn_publication/articles/b50109458ca532.md - Teradataとは？
4. /Users/user/Documents/Blog/zenn_publication/articles/dd94771d828ec7.md - コマンド紹介シリーズ：tldr
5. /Users/user/Documents/Blog/zenn_publication/articles/9b2e5528548353.md - 2025年4月版読んでいて良かった本紹介
6. /Users/user/Documents/Blog/zenn_publication/articles/2b240c4b343765.md - Apache ResilientDBとはなんなのか？
7. /Users/user/Documents/Blog/zenn_publication/articles/e3d25446d34776.md - Pythonを使ったチュートリアルを通してDataflow試してみた
8. /Users/user/Documents/Blog/zenn_publication/articles/a57b277ee7af27.md - コマンド紹介シリーズ：imgcat
9. /Users/user/Documents/Blog/zenn_publication/articles/3b90ad19a4e8a6.md - スラッシュコマンドでアキネイター風なことをclaudeにさせてみた
10. /Users/user/Documents/Blog/zenn_publication/articles/ca5a602c2482f5.md - Eventarcを用いてCloud Storageへのファイルアップロードイベントを検知してみた
---
# 各記事の詳細分析
## 1. Gonum Plotを使ってGoでプロットを作ってみる
### 文法的な誤り
- **助詞の誤用**: 「フォークとのことです」（文脈的に「というものです」が適切）
- **表記ゆれ**: 「Gonum Plot」「GoNum Plot」の混在は見られないが一貫性は保たれている
### わかりにくい表現
- **長い文**: 「Gonum Plotはcode.google.com/p/plotinumの新しい公式フォークとのことです。Goを利用してプロットのビルド・描画ができるAPIを提供しており、現時点ではまだ変動しており仕様が変更される可能性があるとのことです。」
- **改善案**: 「Gonum Plotは、code.google.com/p/plotinumの新しい公式フォークです。Goを利用してプロットのビルド・描画ができるAPIを提供しています。ただし、現時点ではまだ仕様が変動しており、変更される可能性があります。」
### 冗長な表現
- 「とのことです」の多用（3回）
- **改善案**: 情報の直接表現に変更する
### 専門用語の説明不足
- **良い点**: 「plotter.XYs」「vg.Inch」など専門用語に対してコード例で説明
- 「mise」については過去記事への参照で補完
### 読点の使い方
- 概ね適切だが、「pts := make(plotter.XYs, 10)」の説明で読点がやや不自然
### 断定を避ける表現
- 頻出: 「〜と思います」（3回）、「〜できます」（5回）
- **改善案**: 技術記事では断定表現を増やすことで信頼性向上
---
## 2. zshのコマンド履歴みてみた
### 文法的な誤り
- **活用の誤り**: 「pip instalal scikit-learn」（typoだが記事内では意図的）
- **文法**: 特に大きな問題なし
### わかりにくい表現
- **主語の省略**: 「かくいう自分も今回はじめてみました」
- **改善案**: 「私も今回初めて見てみました」
### 冗長な表現
- 「今回作ったのは以下になります」「以下のようになっています」の重複表現
### 専門用語の説明不足
- **良い点**: `.zsh_history`フォーマットを実際の例で説明
- virtualenvの説明は省略されているが、一般的なツールなので問題なし
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（7回）、「〜だと思います」（2回）
- **改善案**: データ分析結果なので、事実として断定できる部分は断定表現に変更
---
## 3. Teradataとは？
### 分析不可能
- 内容が極めて短く（URLのみ）、分析に十分な文章量なし
- **改善案**: 記事を完成させる必要がある
---
## 4. コマンド紹介シリーズ：tldr
### 文法的な誤り
- 特に大きな問題なし
### わかりにくい表現
- **長い文**: 「そのような場合に、簡単な利用例を示してくれるのが`tldr`になります。」
- **改善案**: 「そのような場合に、簡単な利用例を示してくれるのが`tldr`です。」
### 冗長な表現
- 「以下のようになります」「以下のように表示されました」の類似表現の多用
### 専門用語の説明不足
- **良い点**: man pagesについて丁寧に説明
- コマンドライン操作について前提知識があることを想定
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（6回）、「〜できます」（3回）
- **改善案**: コマンドの機能説明では断定表現が適切
---
## 5. 2025年4月版読んでいて良かった本紹介
### 文法的な誤り
- **活用の誤り**: 「Professional Data Engineerを撮って」→「取って」
### わかりにくい表現
- **文の構造**: 「私としてはAIは使えるのはもちろんのこと、その基盤を作ることもできるエンジニアになりたいのでこういう本を読みたいと思っています。」
- **改善案**: 「私は、AIを使えるだけでなく、その基盤を作ることもできるエンジニアになりたいと考えています。そのため、このような本を読んでいます。」
### 冗長な表現
- 「〜と思っています」「〜と思います」の多用
### 専門用語の説明不足
- **良い点**: 各書籍の内容と学習目的を明確に説明
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思っています」（8回）、「〜と思います」（5回）
- **改善案**: 読書体験は個人的事実なので、断定表現で問題なし
---
## 6. Apache ResilientDBとはなんなのか？
### 文法的な誤り
- 特に問題なし
### わかりにくい表現
- **引用の処理**: 長い英語引用文の直後の説明が理解しにくい
### 冗長な表現
- 「〜ということです」「〜とのことです」の多用（5回）
### 専門用語の説明不足
- **良い点**: ブロックチェーン関連の専門用語に対して適切な説明
- PBFT、UTXOなど専門性の高い用語も文脈で理解可能
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（6回）、「〜だと思います」（2回）
- **改善案**: 技術解説では断定表現が適切な場面が多い
---
## 7. Pythonを使ったチュートリアルを通してDataflow試してみた
### 文法的な誤り
- 特に大きな問題なし
### わかりにくい表現
- **長い文**: チュートリアル手順の説明で一文が長くなる傾向
### 冗長な表現
- 「以下のようになります」類の表現が多用
- 手順説明での重複表現
### 専門用語の説明不足
- **良い点**: Cloud Storage、Dataflow、Apache Beamの関係性を適切に説明
- 技術用語に対する説明が充実
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（11回）、「〜だと思います」（3回）
- **改善案**: チュートリアル手順は断定表現で記載すべき
---
## 8. コマンド紹介シリーズ：imgcat
### 文法的な誤り
- **語彙選択**: 「霊の如く」→「例によって」（一般的な表現に変更推奨）
### わかりにくい表現
- 表現は概ね明瞭
### 冗長な表現
- 「〜になります」の多用
### 専門用語の説明不足
- **良い点**: コマンドオプションの説明が適切
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（2回）、「〜できます」（4回）
- 使用頻度は適切な範囲内
---
## 9. スラッシュコマンドでアキネイター風なことをclaudeにさせてみた
### 文法的な誤り
- **表記**: 「slachcommand」→「slashcommand」（topics内のtypo）
### わかりにくい表現
- 「私の歴史知識が終わっていることが明らかになっているのは抜きにして」
- **改善案**: より客観的な表現に変更
### 冗長な表現
- 会話記録の重複記載
### 専門用語の説明不足
- **良い点**: スラッシュコマンドの仕組みを適切に説明
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（4回）
- 使用頻度は適切
---
## 10. Eventarcを用いてCloud Storageへのファイルアップロードイベントを検知してみた
### 文法的な誤り
- 特に大きな問題なし
### わかりにくい表現
- 技術的手順の説明が明瞭
### 冗長な表現
- 手順説明での定型表現の多用
### 専門用語の説明不足
- **良い点**: Eventarc、Cloud Run、Cloud Storageの関係性を図解で説明
- アーキテクチャ図が理解を助けている
### 読点の使い方
- 概ね適切
### 断定を避ける表現
- 「〜と思います」（3回）
- 使用頻度は適切
---
# 全体的な傾向
## 1. 文法的な誤り
- **頻出問題**: 活用の誤り（「撮って」→「取って」）
- **typo**: コード内や専門用語でのスペルミス
- **総合評価**: 大きな文法的問題は少ない
## 2. わかりにくい表現
- **共通課題**: 一文が長すぎる傾向
- **改善点**: 複文を単文に分割することで読みやすさ向上
- **総合評価**: 技術記事として概ね適切な水準
## 3. 冗長な表現
- **最頻出**: 「〜とのことです」「〜になります」「以下のようになります」
- **改善案**: より直接的な表現への変更
- **総合評価**: 冗長表現の削減で文章の簡潔性向上が可能
## 4. 専門用語の説明不足
- **良い点**: コード例や図解での説明が充実
- **改善点**: 前提知識レベルの明示
- **総合評価**: 技術記事として適切なレベル
## 5. 読点の使い方
- **総合評価**: 概ね適切、大きな問題なし
## 6. 断定を避ける表現の頻度
- **頻出**: 「〜と思います」（平均 4.8回/記事）
- **頻出**: 「〜できます」（平均 3.2回/記事）
- **改善案**: 事実や手順説明では断定表現を使用
- **総合評価**: 技術記事にしては断定を避ける表現がやや多い
## 推奨改善アクション
1. **文章構造**: 長文の分割
2. **表現の簡潔化**: 冗長な接続表現の削減
3. **断定表現の活用**: 技術的事実に対する自信ある表現
4. **専門用語の統一**: 表記ゆれの防止
まとめ
今回はclaude codeに自分のブログの傾向を分析させてみました。分析結果はおおむね自分が考えていたものと同じでしたが、色々と反省点も見つかりました。今回はZennのAPIとかは使ってないので実際にどれくらい記事が閲覧されたかを見せていないのであくまで記事のマークダウンしか情報がなかったですが、いつかZennのAPIと組み合わせて統計情報を利用しながらより深い洞察を得れるような仕組みを作っみたいと思います。
Discussion