この記事は、3-shake Advent Calendar 2025 2日目のエントリ記事です。
はじめに
ブログを書いては直し、また直す。同じ文章を何度も触っていると、客観的な判断ができなくなってくる。「これで本当に伝わるのか？」という疑問だけが残る。
コードにはレビューがあり、デザインには批評がある。しかし、技術ブログには明確な基準がない。その不安を解消するために、最初は自分の文章を評価する「プロンプト」を作って運用していた。防御力、思考整理力、実践応用性など、6つの観点でAIに評価させるのだ。
だが、すぐに問題にぶつかった。「面倒」なのだ。記事を書くたびにプロンプトを開き、貼り付け、結果を待つ。この手動のひと手間があるだけで、次第に「今日はまあいいか」とサボるようになり、せっかくの基準も形骸化していった。
だから、環境ごと変えることにした。
生成AIのエージェント機能を使い、ブログレビューの手順をひとつの動作にまとめたのだ。/blog-quality-review と打てば、必要なチェックが勝手に走る。手間を消し、継続性だけを残す。今回は、そんなブログレビュー環境の構築について紹介する。
ブログ記事評価プロンプト v2.1 https://syu-m-5151.hatenablog.com/entry/2025/05/19/100659 · GitHub
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、はじめていきます。
なぜブログレビューにエージェントを使うのか
自分で書いた記事を自分で評価するのは、想像以上に難しい。「こんなにわかりやすく書いたのに、なぜ伝わらないんだろう」と思うことはないだろうか。
それは私たちが、自分の持つ知識や前提条件を、無意識に読者にも期待してしまうからだ。「これくらい知っているだろう」「説明不要だろう」という思い込みが、読者との間に溝を作る。
ここにエージェントが入ると、話が変わる。
エージェントは私の「暗黙の前提」を共有していない。だから、初学者が感じるであろう「分からない」を冷静に指摘できる。専門用語の壁、論理の飛躍、「なぜ？」という素朴な疑問——これらを容赦なく洗い出してくれる。
さらに、エージェントは疲れないし、基準を忘れない。私が定義した「レビューの観点」を一貫して適用し続ける。これは単なる自動化ではない。私の認知リソースを、「本当に人間にしかできない判断」に集中させるための仕組みだ。
Commandsでレビュー観点を構造化する
Claude Codeには、よく使うプロンプトをコマンド化できる機能がある。.claude/commands/ ディレクトリにMarkdownファイルを置くだけで、ファイル名がコマンド名になり、中身がプロンプトとして機能する。
「毎回『この観点でレビューして』と指示するのは面倒」 「記事ごとにレビューの質がバラつくのが嫌だ」
そんな悩みを抱えていた私にとって、Commandsは最適解だった。
一貫性の担保
手打ちのプロンプトでは、表現の揺らぎによりAIの回答も変わってしまう。Commandsなら常に同一の定義で実行されるため、出力の質が安定する。
# 悪い例（毎回微妙に違う） 「この記事をレビューして」「読みやすさをチェック」「AIっぽくないか見て」 # 良い例（カスタムコマンド） /blog-quality-review blog.md # → 常に定義された6つの観点・同じ基準でレビューが走る
GitでのVersion管理
Commandsの実体はMarkdownファイルだ。つまり、プロンプトの改善履歴をGitで管理できる。
「この観点を追加したら、指摘が鋭くなった」 「この表現を変えたら、より具体的な改善案が出るようになった」
こういった試行錯誤の軌跡が残ることで、プロンプト自体が「育つ資産」になっていく。
私が実際に使っているCommands
ここからは、私がブログ執筆・レビューで実際に使用しているCommandsを全てではないが紹介する。
注意：ここで紹介するのは各Commandの要点のみだ。実際のファイルには、より詳細な指示や評価基準（Few-Shotなど）が含まれている。
Phase 1: 書く前に深く考える
良いブログは「書く」前に「考える」ことから始まる。
/deep-thinking-prompt - 深い思考のための問いかけ
# Deep Thinking Prompt - 深く考えるための問いかけ ブログを書く前に「深く考える」ための問いかけを提供します。 表面的な理解や一般論で終わらず、本質に迫るための思考支援ツールです。 ## 7つの問いかけ 1. **原体験への問いかけ** - なぜこのテーマに興味を持ったのか 2. **前提への問いかけ** - 当たり前だと思っていることは何か 3. **対立への問いかけ** - 矛盾や葛藤はどこにあるか 4. **構造への問いかけ** - システムとしてどう機能しているか 5. **変化への問いかけ** - 過去と現在で何が変わったか 6. **未来への問いかけ** - このまま進むとどうなるか 7. **読者への問いかけ** - 誰に届けたいのか、なぜその人なのか
このCommandを使うと、「何を書くか（What）」だけでなく「なぜ書くのか（Why）」が明確になる。一般論ではなく、自分だけの視点を掘り起こすための工程だ。
/structural-thinking - 構造設計
# Structural Thinking - 構造的思考支援
散らばった思考を整理し、論理的な流れを作ります。
読者の理解プロセスに合わせた「伝わる」構成を設計します。
深く考えたあと、その思考をどう配置するか。このCommandが、散乱したアイデアを読者に届く「ストーリー」へと整えてくれる。
Phase 2: 書いた後にレビューする
/blog-quality-review - 6つの観点でレビュー
以前作成した「ブログ記事評価プロンプト」をCommand化したものだ。
# Blog Quality Review - ブログ品質レビュー 以下の6つの観点（各0.0-5.0スコア）で評価します： 1. **防御力** - 批判や反論への耐性 2. **思考整理力** - 情報の論理的構造化 3. **実践応用性** - 読者が行動に移せる価値 4. **構成と読みやすさ** - 視覚的要素と文体 5. **コミュニケーション力** - 人間味のある伝達 6. **人間らしさ** - 温度感と個性
実行すると記事の強みと弱みが数値化される。「前回は実践応用性が3.2だったが、今回は4.0に上がった」といった具合に、自身の成長や記事の品質を定量的に把握できる。
/beginner-feedback - 初学者の視点
# Beginner Feedback - 初学者の素朴な意見 あなたは**一般読者代表（佐々木ゆい・28歳）**として、素朴な意見を提供します。 - 専門用語や前提知識の壁を発見 - 論理の飛躍を指摘 - 「なぜ？」という素朴な疑問を投げかける - 一般読者が共感できるか確認
エキスパートの目では見逃してしまう、初学者の「分からない」を発見するためのCommandだ。具体的なペルソナを設定することで、フィードバックの解像度を高めている。
/ai-humanity-check - AIっぽさの評価
# ai-humanity-check 文章のAIっぽさを評価し、より人間らしい表現への改善提案を行います。 ## AIっぽさスコア (0.0-5.0) ※低いほど人間らしい **0.0-1.0 (完全に人間的)** - 著者特有の言い回しや癖がある - 具体的な失敗談や苦労話が生々しい - 感情の起伏が自然で共感できる
AIに下書きを支援させると、どうしても文章が「AI臭く」なりがちだ。このCommandで機械的な表現を検出し、体温のある文章へと戻していく。
Phase 3: 仕上げる
/textlint-polish - 文章校正
# Textlint Polish - 文章校正・AIっぽさ除去 機械的・AIっぽい表現を排除し、自然で読みやすい文章にする。 - AIが多用する冗長表現を検出 - 比喩的・詩的すぎる表現を簡潔に - 文体の統一（です・ます調）
textlint的な観点で、表現の誤りや揺らぎを修正する。AI特有の冗長な言い回しもここでカットする。
/redundancy-check - 冗長性チェック
# Redundancy Check - 冗長性チェック 以下の4つの観点（各0.0-5.0スコア）で評価します： 1. **情報密度** - 1文あたりの情報量 2. **簡潔性** - 冗長表現・無駄な修飾の少なさ 3. **論理効率** - 論理的重複・循環論法の少なさ 4. **構造最適性** - 章・節の構成の必要十分性
削れる言葉は徹底的に削る。情報の密度を高め、読み手の時間を奪わない文章にするための最終チェックだ。
全自動レビューの実行
これらを一つずつ実行するのはやはり手間だ。そこで、これらを束ねる /full-review を作成した。
# Full Review - 全自動レビュー実行 すべての必須レビューを自動で順次実行します。 textlint校正から始まり、初学者フィードバック、品質レビューまで一括で実施。 ## 使用方法 /full-review blog.md
このCommandひとつで、以下のフローが流れる。
/textlint-polish（校正）/beginner-feedback（初学者視点）/blog-quality-review（品質スコア）/ai-humanity-check（人間らしさ）
一度設定さえしてしまえば、あとは「コマンド一発」で包括的なレビューが完了する。
上巻のまとめ
ここまで、Commandsを使ったブログレビュー環境の基礎（Phase 1〜3）を解説してきた。
出発点は、「ブログ記事の評価基準がなく、レビューが属人的かつ面倒」という課題だった。これに対し、エージェントを活用して評価観点を構造化し、実行を自動化するというアプローチをとった。
ここで重要なのは、AIとの関係性だ。 体験や感情といった「身体性」は人間が供給し、それを構造化し整える役割をAIが担う。これはAIへの丸投げではなく、互いの強みを活かした協働である。
Commandsによって評価基準を定義し、Gitで管理し、自動化することで、「書くこと」以外のノイズを極限まで減らすことができる。
下巻では、より高度なAgents（サブエージェント）の活用と、複数の視点を持つレビュー体制の構築について解説する。
下巻に続く
