はじめに
こんにちは、アジャイル開発チーム兼Insight Edge Techblog編集チーム担当のニャットです。
以前、Vertex AI Geminiを使った社内議事録生成アプリ の記事で生成AI案件への挑戦について書きましたが、その後、生成AI案件にも少しずつ慣れてきました。とはいえ、生成AIの進化があまりにも速すぎて、キャッチアップの日々が続いています。笑
最近は、Claude Codeのコマンド、サブエージェント、スキルといった新しくリリースされた機能をいじってみることを楽しんでいます。そしてClaude Code Actionを使ってGitHub上でこれらの機能を活用できるように仕組み構築も色々試行錯誤しています。
その中の1つとして、テックブログレビューエージェントをマルチエージェント構成で構築したので、今回はその取り組みについて紹介します。
今回のレビューエージェントの構成はテックブログレビューにとどまらず、他のドキュメントレビューやコードレビューにも応用できると思いますので、ぜひ参考にしていただけると嬉しいです！
なお、弊社では以前LangGraphベースでTechblogレビューエージェントを開発し紹介していましたが、最近はClaude Code Actionベースに置き換えていますので、その変遷についても説明します。
本記事について
この記事は、Insight Edge Advent Calendar 2025 1日目の記事です。
弊社には「やってみる・みんなでやる・やりぬく」というValueがあり、私たちテックブログ編集チームもこのValueを大切にしています。編集チームメンバーは年初にそれぞれ「やってみる」チャレンジを選ぶようにしており、今回紹介するレビューエージェントの進化は、まさにこのValueを体現した取り組みです。
1人のメンバーの「やってみる」から始まり、チーム全体で「みんなでやる」で改善を重ね、アドベントカレンダーという目標に向けて「やりぬく」——本記事では、そんなストーリーをお伝えします。
LangGraphからClaude Code Actionへ – Techblogレビューエージェントをみんなで進化させてみた1年間
このセクションでは、TechblogレビューエージェントをLangGraphベースからClaude Code Actionベースのマルチエージェント構成にシフトさせた過程を紹介します。現在のエージェント構成を先に知りたい方は、 次のセクション からご覧ください。
1. LangGraphでのエージェント作成からスタート（やってみる）
弊社のテックブログレビューエージェントは、以前も本テックブログで公開していた通り、Matsuzakiさんが LangGraphベースのレビューエージェント を作ってくださっていたことから始まりました。Techblogレビュー作業をエージェントを使って自動化する仕組みはここがスタートでした。
私も実際に活用させていただきましたが、人間が指摘しづらい細かいポイント（文言の統一性など）をずばっと指摘してくれて、とても助かりました。
当時のレビュー結果イメージも記事内にありますので、詳しくは Matsuzakiさんの記事 をご覧ください。
記事の中では、「今後やりたいこと」として以下のようなアイデアが挙げられていました。
- 記事内容に基づいて対象読者（ペルソナ）を作成し、ペルソナの視点からレビューする
- 内容チェックでWeb検索を取り入れ、類似記事の参照や比較ができるようにする
- レビューにSEO観点を取り入れ、検索流入を意識したキーワードやタイトルを提案する
2. Claude Code Actionも併用して活用してみる（みんなでやる）
LangGraphベースのレビューエージェントを運用する中で執筆者や編集チームから多くのフィードバックが集まり、当時挙げられていた「やりたいこと」を実現したい思いも強くなっていきました。しかし、テックブログ編集チームは組織改善活動の一環であり、メンバーは日々の案件対応で忙しく、エージェントの改善やLangGraph実装を継続的に更新する時間を十分に確保するのは難しい状況でした。
ちょうどその頃、Claude CodeとClaude Code Action(詳細はこちら)への関心が世の中に広まりました。編集チームのKさんが「Techblogの活動を自動化する」チャレンジを掲げており、すぐにもClaude Code Actionを導入していただき、Github上でClaude Codeによるレビューを試せる環境を整えてくれました。
この時は、レビュー観点を1つのプロンプトにまとめ、プルリクエスト上で @claude を呼び出すとClaude Codeが自律的にレビューしてくれる方針を採用していました。プロンプトは編集チーム全員で整理しました。誤字・脱字、読みやすさ、技術的正確性、記事の深さ、読者の引き込み、拡散性（SEO）などの観点でレビューするように指示しました。
プロンプトの詳細を見る
## タスク あなたはInsight Edge TechBlogの編集者です。Pull Requestの内容をもとにレビューを実施し、具体的な課題と修正方針を示す提案を作成します。 ## 手順 1. メンバーのTechblogをしっかり読み、内容を理解します。 2. 誤字、脱字がないかをチェックします。 3. 読みやすさに焦点を置き、チェックします。 - 言葉遣いや表現が明確で分かりやすいか？ - 段落や見出しなどのフォーマットは整理されているか？ - 図などで表現した方が分かりやすい項目がなかったか？ 4. 技術的正確性に焦点を置き、チェックします。必要に応じてウェブ検索も行い、内容が正確かどうかを確認してください。 - 技術的な内容に誤りや誤解を招く表現はないか？ - ソースデータが信頼できるか？ 5. 記事の深さに焦点を置き、考えます。 - トピックに対する背景知識や文脈が十分に提供されているか？ - 初心者から中級者・上級者までにとって有益な情報量か？ 6. 読者の引き込みに焦点を置き、考えます。 - 冒頭から興味を惹かれる構成になっているか？ - 読み進めたくなる工夫やストーリーテリングがあるか？ 7. 拡散性に焦点を置き、考えます。 - タイトルなど検索でヒットしやすいワードが含まれているか？SEO向上のため、もっといい書き方がないか？ - 記事の内容は読者から拡散したくなるような内容になっているか？ 8. 何度か読み返し、同僚として親切な態度でレビューコメントを作成します。 ## 出力 - 形式: markdown形式で出力します。 - 構成: 以下の内容を含むレビューコメントを作成してください。絵文字なども使って分かりやすくしてください。 - 総評：記事を読んだ時の全体的な印象 - 良かった点 - 改善点 - 提案: 具体な箇所に対して具体的な対応方針か修正後の文章を提案してください。
このようなプロンプトでも、最初からいい感じのレビュー結果が返ってきました。例えば、先日公開された AIエージェントはなぜ複雑なタスクを完遂できないのか？ の初稿でのレビュー結果は以下の通りです。
約半年間LangGraphとClaude Code Actionを併用してレビューを運用した結果、観点のアップデートのしやすさやClaude Codeの進化への期待から、編集チームでは最終的にClaude Code Actionベースへ一本化することを決めました。
継続運用で見えてきた課題と改善ポイント
この仕組みを約半年間を運用してきましたが、執筆者や編集チームから以下のようなフィードバックがありました。
良かった点： 細かい誤字や文言の統一性、構成改善の提案、視覚化の提案、技術的な正確性、読みやすさの改善、SEO観点の提案など、人間が指摘しづらい点を遠慮なく指摘してくれました。
実際執筆していただいたメンバーからも以下のようなポジティブなフィードバックがありました。
一方で、レビュー記事数が増えてくるとだんだん以下のような課題も見えてきました。
課題と改善ポイント:
- レビューコメントの質にばらつきがある：コメントは長いものの、参考になる内容は7割ほどで、編集チームの最終レビューでは追加で指摘する箇所も残っていました。
- ファクトチェックができていない：時事ネタ（セミナーの開催期間）、論文の内容、技術的な内容のファクトチェックができていなかった。プロンプトには「検索して確認するように」と書いていたのに、検索できている様子がなく、誤った指摘を作ってくることもあった
- 各観点のレビューが浅い：それぞれの観点である程度指摘はくるが、深くレビューできないため、深い指摘がこなかった
- 執筆フローに合わせたレビューができない：固定プロンプトのため、目次段階、初稿、修正後、どのタイミングでも毎回同じレビューをしていた
さらに、課題とまではいかないものの、以下のような追加でやりたいことも見えてきました。
- Matsuzakiさんが挙げていたペルソナを作成してレビューも取り入れるとレビューの質が上がるのでは？
- 執筆フローに合わせたレビュー：目次段階、初稿、修正後で異なるレビューをしてもらえるとさらに効率的では？
- 過去記事との内部リンク最適化：関連記事があれば自動で提案してくれると今年のチャレンジである「PV数向上」にもつながりそう
3. マルチエージェント構成への進化させてレビュー質を高める（やり抜く）
それらの課題を解決したいという思いに加えて、Insight Edge初のアドベントカレンダーの開催もやってくる！月に25本の投稿をレビューしなければならないのは編集チームに対してかなりの負担になってしまうため、アドベントカレンダー企画者としてTechblogレビューエージェントの改善をやり抜く決意をしました。
そこで、以下の方針でエージェントを進化させることにしました。
1. 執筆フローに合わせた段階的レビュー
執筆者が必要なタイミングで必要なレビューを受けられるよう、3つのカスタムスラッシュコマンドを作りました。
/outline-review：目次段階で構成を簡潔にチェック/initial-review：初稿を徹底的にレビュー/update-review：修正後の差分をレビュー
スラッシュコマンドの詳細は以下のClaude Codeの公式ドキュメントをご参照ください。
Claude Code公式ドキュメント: カスタムスラッシュコマンド
2. レビューの質を高める仕組み
- マルチエージェント化：サブエージェント機能を使って各観点ごとに専門エージェントが深くレビューすることで、抽象的ではなく具体的なコメントを実現
- ペルソナ駆動レビュー：読者体験評価エージェントには記事内容に応じてターゲット読者のペルソナを生成し、適用
- MCPサーバーの設定：外部ツールと連携し、最新の技術仕様の取得
- Web検索、Web取得機能を有効化：WebFetch、WebSearch機能を使えるようにすることで時事ネタや最新情報を検証
サブエージェント、MCPツール設定、Web検索・取得機能の設定詳細は以下のClaude Codeの公式ドキュメントをご参照ください。
3. レビューの効率化
- GitHub Suggestion機能：Claude Code Actionのインラインコメント作成MCPツールを活用し、該当箇所に直接修正案を提示してワンクリックで修正を適用可能にする
現在のTechblogレビューエージェント詳細
では現在のTechblogレビューエージェントがどうなっているのか、説明します。
レビューエージェント構成
全体のアーキテクチャは以下の通りです。
ちょっと複雑に見えるかもしれませんが、流れはシンプルです。
- スラッシュコマンド実行:
/outline-review、/initial-review、/update-reviewのいずれかのコマンドをGitHub上で実行 - メインエージェント（Claude Code）による処理: 記事を分析し、必要なサブエージェントを選択して順次か並列で起動
- サブエージェントによる専門レビュー: 各エージェントが独立したコンテキストで並列処理
- 結果統合・出力: 環境に応じてMarkdownファイルまたはPRコメントとして出力
今回は、以下のサブエージェントを用意しています。
| サブエージェント名 | 主な役割 | 起動条件 | ペルソナ適用 | 使用MCPツール |
|---|---|---|---|---|
| persona-generator | ペルソナ生成 | 常時 | – | – |
| structure-evaluator | 構成・深さ・引き込み評価 | 常時 | ✓ | – |
| japanese-quality-checker | 日本語品質チェック | 常時 | ✓ | textlint MCP |
| quality-checker | フォーマット・視覚化チェック | 常時 | × | – |
| seo-analyzer | SEO最適化 | 常時 | ✓ | – |
| internal-link-optimizer | 内部リンク提案 | 常時 | ✓ | – |
| tech-validator | 技術的正確性の検証 | 条件付き* | × | Context7 MCP, WebSearch |
| fact-checker | 時事ネタ・統計データ検証 | 条件付き** | × | WebSearch |
| compliance-checker | コンプライアンス・法的リスク | 常時 | × | – |
*技術内容が深い場合（論文引用、技術用語10個以上、コードブロック3つ以上など）のみ起動
**外部リンクや時事的事実（「最近」「先日」「発表」「リリース」など）が含まれる場合に起動
各サブエージェントは独立したコンテキストで動作するため、それぞれの専門分野に集中した深いレビューが可能になっています。
記事レビュー例
では実際の私のこのブログでレビューしてみます。執筆者が目次・ドラフトか原稿をプルリクエストに挙げた際、編集チームメンバーがプルリクエストのコメント上で @claude /outline-review や @claude /initial-review を実行してレビューを依頼します。
/outline-review の実行結果
まずは目次段階で /outline-review を実行してレビューをお願いしていました。
SEO対策のため、タイトルを短くするようにと提案されたり、流入を増やすため関連記事のリンクを追加するように提案されたりしていますね。
この後、全部指摘を採用させていただき、改善しました！
ちなみにレビュー過程では、以下のようなペルソナを作成してくれたようです。
/initial-review の実行結果
次に、初稿を完成し、 /initial-review を実行してレビューをお願いしました。
総合コメントから分かる通り、とても詳細にレビューできていると思います。
また、インラインコメントで改善提案も色々もらえました。
アドベントカレンダーをどうしても最初から宣伝したかったのに・・・エージェント的にはあまり良くないようですね。笑
工夫点
次に、このレビュー仕組みを構築した時の工夫ポイントを紹介させていただきます。もし同じような仕組みを作りたい方がいれば、参考になれば嬉しいです。
カスタムスラッシュコマンドのワークフロー制御でレビューフローの最適化
カスタムスラッシュコマンドは簡単にいうと事前に定義されたプロンプトで、コマンド呼び出し時にこのプロンプトがClaude Codeのメインセクションに渡され、指示された処理が実行されます。
例えば初稿をレビューするための /initial-review コマンドでは、環境判定 → レビュー対象特定 → ペルソナ生成 → 記事分析 → サブエージェント選択・並列起動（ペルソナ情報も渡す）→ 結果統合 → 環境別出力という流れで動けるように、カスタムスラッシュコマンドの定義に工夫しました。
具体的な工夫ポイントを以下に紹介します。
- 環境判定と出力先の切り替え: GitHub Actions環境かローカル環境かで出力先を切り替えるようにしました。
if [ "$GITHUB_ACTIONS" = "true" ]; then
echo "レビュー結果はPRコメントとして投稿されます"
else
echo "レビュー結果は.reviewsフォルダーに保存されます"
fi
この目的は、執筆者が執筆中でもローカル環境で自身の記事をレビューできるようにするためです。これによって編集チームのレビュー負担も軽減できます。
- ペルソナ駆動レビュー: ワークフロー開始時に記事の内容を理解し、対象読者と想定するペルソナを作成。これらのペルソナを読者体験評価エージェント（構成、日本語品質、SEO、内部リンク）に適用し、多角なレビューをさせるように工夫しました。一方で、技術的正確性や法的リスクなど客観的に判断すべき観点はペルソナに依存せず、専門家視点で評価させるようにしました。
**ペルソナの適用:** 生成されたペルソナは、以下の**読者体験評価エージェント**に適用してください。 - `structure-evaluator`: 読者にとって理解しやすい構成か？ - `japanese-quality-checker`: 読者にとって読みやすい日本語か？ - `seo-analyzer`: 読者の興味を引くタイトルか？ - `internal-link-optimizer`: 読者が次に読みたい記事へ誘導できているか？ **重要:** これらのエージェントは、**生成された各ペルソナごとに個別に起動**してください。 - 例: 3つのペルソナが生成された場合、`structure-evaluator`を3回（各ペルソナで1回ずつ）起動 - 各起動時には、該当するペルソナ情報を渡してください 以下のエージェントは、プロの専門家視点で客観的に評価します（**ペルソナ不要、1回のみ起動**）。 - `tech-validator`: 技術的正確性 - `fact-checker`: 事実確認 - `compliance-checker`: 法的リスク - `quality-checker`: 視覚的品質
- 条件付きサブエージェント起動: 記事内容によってチェック観点は変わるため、条件付きでサブエージェントを起動するようにしました。
**条件付きエージェント:** - `tech-validator`: 技術内容が深い場合のみ起動 - 論文の引用、arXiv/DOIリンク、技術用語10個以上、コードブロック3つ以上などがある場合 - `fact-checker`: 以下のいずれかに該当する場合に起動 - 外部リンク（http/https）が含まれている - 時事的事実がある（「最近」「先日」「発表」「リリース」などのキーワード）
これによって全ての記事に対して無駄に全ての観点でチェックする必要がなくなり、効率的かつコスト抑えてレビューできるようになります。
- 並列実行の明示的な指示: 各サブエージェントは独立とした観点でチェックし、順序関係がないため、並列で起動するように指示しました。
### 3. サブエージェント並列実行
選定したサブエージェントを並列で起動してください。
これによりGitHub Actionの実行時間も短縮でき、コスト削減にもつながります。
サブエージェント分離によるコンテキスト節約とレビューの深さ向上
上でも書いた通り、Claude Code Actionを導入した当初は1つの大きなプロンプトで全観点をレビューしていました。しかし、各観点でのレビューが浅く、具体的な指摘が少ないという課題がありました。そこで、Claude Codeのサブエージェント機能を活用し、観点ごとに独立したエージェントへ分離してみました。サブエージェントは独立したコンテキストウィンドウで動作するため、それぞれが専門分野へ特化したシステムプロンプトと十分なコンテキストを持つことができます。
これにより、例えば japanese-quality-checker は日本語品質チェックのベストプラクティスやtextlintの使い方に集中でき、tech-validator は技術検証に必要な詳細な指示を持つことができるようになりました。結果として、各観点でのレビューの深さが向上したと思います。
※ 階層型マルチエージェントは AIエージェントが複雑タスクを完遂できない理由と、「マルチエージェント×コンテキストエンジニアリング」の最新手法 でも説明されていますので、ぜひ合わせてご覧ください。
サブエージェントからメインスレッドへの結果受け渡し：JSON設計の工夫
複数のサブエージェントを並列実行する際、各エージェントからの結果をどう受け取り、どう統合するかが課題でした。
最後の総合コメントおよびサジェッション投稿を統合して整理しやすいように、現在では各サブエージェントには以下のような統一されたJSON形式で結果を返すよう指示しています。
{ "category": "日本語品質", "issues": [ { "type": "誤字", "severity": "high", "location": "第3章", "problem": "「てにをは」の誤り", "suggestion": "具体的な修正案", "original_text": "元のテキスト", "suggested_text": "修正後のテキスト", "line_range": "105-106" } ], "inline_comments": [ { "comment_type": "suggestion", "line_range": "120", "comment": "コメント内容" } ], "positives": ["良かった点"], "summary": "総評" }
この設計により、メインスレッドでは各エージェントのJSON結果を受け取り、以下の処理が可能になりました。
- 重要度（
severity）別に指摘事項を整理 original_text、suggested_text、line_rangeが揃っている指摘を自動的にGitHub Suggestionとして投稿- カテゴリ別に整理された最終レポートの生成
GitHub Suggestion機能を確実に動かすための指示の工夫
Claude Code ActionにはGitHub PR上でインラインコメントを投稿する mcp__github_inline_comment__create_inline_comment というMCPツールが用意されています。
しかし、コマンドやサブエージェントのプロンプトで明示的に「このツールを使え」と指示しないと、使われないことも多いです。そのため、明示的に使うよう指示しました。
**IMPORTANT - GitHub PR Inline Comment形式での出力:** この実行はGitHub Actions環境で行われています。 具体的な修正案がある場合は、必ず以下のフィールドを含めてください。 - `original_text`: 修正対象の元のテキスト - `suggested_text`: 修正後のテキスト - `line_range`: 該当箇所の行範囲 これらの情報を `mcp__github_inline_comment__create_inline_comment` ツールを使って GitHub PR上でSuggestion形式のインラインコメントとして投稿してください。
なお、Claude Code Actionがデフォルトで mcp__github_inline_comment__create_inline_comment を許可していない可能性もありますので、許可するように設定を追加しました。
MCPツールの積極的な活用
レビューの質を高めるため、以下のMCPツールを活用しています。
- textlint MCP (
mcp__textlint__lintFile)：日本語の自動チェックに使用。japanese-quality-checkerが呼び出し - Context7 MCP (
mcp__context7__get-library-docs)：最新の技術ドキュメント取得に使用。tech-validatorが呼び出し - github_inline_comment MCP (
mcp__github_inline_comment__create_inline_comment)：GitHub PR Suggestionの投稿に使用
Web検索・取得機能の有効化
とても簡単なことですが、以前の仕組みではプロンプトで必要に応じてウェブ検索するように指示していたにもかかわらず、事実確認が必要な指摘事項はほとんどハルシネーションが発生して、プロンプトが悪いのか？とずっと思い込んでいました。しかし、実はClaude Code Actionはデフォルトでこの機能を許可していないため、検索や取得ができていなかったことが最近判明しました。笑
そのため、今回からは WebSearch と WebFetch 機能を有効化することで、tech-validator や fact-checker が最新の公式情報を検証できるようにしています。
残っている課題と今後の改善点
上記の仕組みを導入してから、現在のところメンバーからかなりポジティブなフィードバックをもらっていますが、まだいくつかの課題が残っています。
- サブエージェントによってはまだ過剰や不足な指摘がある。
- → 今後は編集チーム全員で継続的にプロンプトを改善していこうと思います。
- サブエージェントはなるべく並列実行をするようにしているが、それでも実行時間は前より長くなっているため、Github Actionのコストがかかる。
- → 必要なエージェントのみ起動する判定ロジックをさらに洗練させたいですね。
- 現在はWeb検索・取得機能を特に制限なく有効化してしまっていますが、むやみに外部情報を参照しすぎると、コンテキストも増大し、コスト増加やハルシネーションのリスクもある。
- → 今後適切な制限を設けたいと考えています。
また他の課題もあると思いますが、これから皆さんのフィードバックを求め続け、改善を続けていきたいと思います。
まとめ
テックブログレビューエージェントは、Matsuzakiさんの「やってみる」から始まり、Kさんや編集チームメンバーの「みんなでやる」で改善、そしてアドベントカレンダーに向けた「やり抜く」で改善を続けてきたInsight Edgeらしい事例だと思います。
私個人もこの活動を通じてClaude Code Actionの機能、Claude Codeのスラッシュコマンド、サブエージェントに関してより詳しくなりました。このレビューの仕組みはTechblogに限らず、案件のコードレビューやドキュメントレビューなどにも活用できると思いますので、この知見を活かして社内のコードレビュー課題を解決することにも挑戦してみたいと思います。そこでもう1つの「やってみる・みんなでやる・やりぬく」のValue事例が作れたら嬉しいですね。
Insight Edge Advent Calendar 2025が始まりました！
最後に、改めてお知らせです！
この記事は Insight Edge Advent Calendar 2025 の1日目として公開しています。
12月25日まで毎日、弊社メンバーがそれぞれの挑戦や学びを発信していきますので、ぜひ Insight Edge Advent Calendar 2025 をフォローして、お楽しみください！
