Slackひと声でブログ校正！Claudeレビュー自動化編

Transcript

1. ‹#› Copyright （C ） NRI Netcom, Ltd. All rights reserved. Slack ひと声でブログ校正！ Claude レビュー自動化編 NRI ネットコム TECH AND DESIGN STUDY #66 2025 年05 月28 日 NRI ネットコム株式会社 志水 友輔 ユースケのユースケース Case4
2. ‹#› Copyright（C） NRI Netcom, Ltd. All rights reserved. ブログのレビュー、めんどくさくない？
3. ‹#› Copyright（C） NRI Netcom, Ltd. All rights reserved. 忙しいのに細かい表記やリンク切れまで 毎回チェックするのは大変。。。 レビュー待ちで公開が遅れるのが もどかしい。。。
4. ‹#› Copyright（C） NRI Netcom, Ltd. All rights reserved. 忙しいのに細かい表記やリンク切れまで 毎回チェックするのは大変。。。 レビュー待ちで公開が遅れるのが もどかしい。。。 このあるある、AI×Slackで どこまで解決できるのか？
5. Copyright（C） NRI Netcom, Ltd. All rights reserved. 志水 友輔 (しみず ゆうすけ) NRIネットコム株式会社 / Cloud Architect WebシステムのPoC、アーキテクトがおしごと AWS Ambassadors(2023,24) 　AWS CDK/Bedrock/ChatGPT/カメラ/つけ麺 小学校の娘のお迎えが至福の時間 #nncstudy Blog:
6. Copyright （C ） NRI Netcom, Ltd. All rights reserved. 背景・課題 Tech ブログ公開前の悩み 表記ゆれ、リンク切れ、曖昧表現の見落とし レビュー依頼がSlack で埋もれる レビュアーによって観点や精度がバラバラ 海外カンファレンスレポートなど時事的な記事は特にスピードが重要 " チェック観点は決まってるのに、毎回人がやってるの効率悪いよね" 2024 年はネットコムのブログが266 本公開され、ほぼ毎営業日1 本ペースで投稿 その1 本1 本に対して必ずレビュー工程が発生している レビュー待ち時間が長くなりリアルタイム性が失われる 人手でのチェックは時間がかかりすぎる スピード・標準化・自然な導線が目標 #nncstudy
7. Copyright（C） NRI Netcom, Ltd. All rights reserved. 解決アプローチ 生成AIに 一次レビューを丸投げ（表記・形式・指摘） トリガーは「Slackbotにメンション+URLを渡す」だけ チェック観点をあらかじめ定義して、定型チェックをAIが自動処理 レビュアーは本質的な判断・アドバイス（技術的な正確性や読者目線の調整など） に専念 #nncstudy
8. Copyright（C） NRI Netcom, Ltd. All rights reserved. レビュー自動化の使い方（ユーザー視点） Slackで @メンションして、レビューしたいURLを貼る そのURLの記事内容が自動で取得され、AIによるレビューが実行される 数分後、同じスレッドに分かりやすいレビュー結果が返信される ポイント：Slashコマンドや専用UI不要。自然なSlackの会話の中でレビューが　　 完結 #nncstudy
9. Copyright（C） NRI Netcom, Ltd. All rights reserved. アーキテクチャ構成図 この構成により、Slack上の自然なやりとりから記事レビューの依頼・結果確認ま でが一気通貫で完結 サーバレス（API Gateway+Lambda）と外部AIサービスを組み合わせ、拡張性と 運用のしやすさを両立 #nncstudy
10. Copyright（C） NRI Netcom, Ltd. All rights reserved. Difyの特徴と選定理由 ノーコードでAIアプリを構築できるプラットフォーム ドラッグ＆ドロップやテンプレートで直感的に開発可能 独自ドキュメントを活用したRAG（検索拡張生成） Slack・Google検索など外部ツール連携も容易 オープンソースで拡張性が高く、自社環境への導入やカスタマイズも柔軟 選定理由 PoC段階での試行錯誤やデバッグがしやすく、最速で立ち上げられる #nncstudy
11. Copyright（C） NRI Netcom, Ltd. All rights reserved. Bedrockの特徴と選定理由 AWSが提供する生成AI基盤 テキスト、画像、動画、音声など多様な生成AIモデル（Claude、Nova、 Stable Diffusion等）を用途に応じて選択可能 セキュリティ・運用面での高い信頼性とプライバシー保護（入出力データは 外部提供・学習利用なし） AWS請求へのコスト統合による一元管理（予算管理・FinOps連携の容易さ） 選定理由 多様な生成AIモデルの統合利用と、企業向けの高いセキュリティ・運用性・ コスト管理を両立できる点 #nncstudy
12. Copyright（C） NRI Netcom, Ltd. All rights reserved. WorkflowとAgentの違い Workflow（ワークフロー） 定型性：あらかじめ定義された手順に従って処理を行う 予測可能性：処理結果が安定しており、管理が容易 適用例：請求書処理やデータの定期更新など、繰り返しの業務 Agent（エージェント） 自律性：状況に応じて自ら判断し、行動を選択する 柔軟性：未知の状況や変化に対応可能 適用例：カスタマーサポートでの複雑な問い合わせ対応、動的なデータ分析 など #nncstudy
13. Copyright（C） NRI Netcom, Ltd. All rights reserved. なぜ迷うのか 業務の複雑性と変動性 一見定型的でも、実際には例外処理や判断が必要な場合、Workflowでは対応 が難しくなる 技術的な制約とコスト Agentは高度な技術とリソースを要するため、導入や運用コストが高くなりが ち 信頼性と管理性 Workflowは予測可能で管理しやすい反面、柔軟性に欠ける Agentは柔軟だが、予測不能な動作をするリスクがある ユーザー体験の向上 柔軟に対応してくれるAgentの方が好まれる場合もあるが、誤動作のリスクも 伴う #nncstudy
14. Copyright（C） NRI Netcom, Ltd. All rights reserved. WorkflowとAgentの判断基準と具体例 判断基準 Workflow ：「必ず実行される処理」に向いている Agent ：「必要な時だけ動く柔軟な処理」に向いている 例1 : ブログの内容取得 この処理は絶対に毎回必要なので、Workflowとして組み込んだ 例2 : ブログ内のリンクチェック（リンク切れやURLミスの指摘） リンクの有無によって処理を分岐させたいのでAgentでの実装が向いている このように、処理の性質によってWorkflowとAgentを使い分けている #nncstudy
15. Copyright （C ） NRI Netcom, Ltd. All rights reserved. チェックリストとプロンプトの構成 Claude に渡すチェック観点は明示的に定義 表記ゆれ（クラウド・Cloud ） 曖昧語（ 「◦◦ と思われます」 「◦◦ といえるでしょう」 ） リンクの構造・形式・有効性 Markdown 構文のミス（例：h2→h4 飛びなど） Claude には「観点別の指摘＋修正案」を箇条書きで返すようにプロンプト設計 人間が" 確認" だけで済むよう構造化 #nncstudy
16. Copyright（C） NRI Netcom, Ltd. All rights reserved. Claudeの出力例とUX Claudeの出力は Slack上でそのまま見やすいように整形済み 原文・修正案・理由をセットで提示し、なぜその修正が必要かを明確に伝える構 成 修正案はそのままコピーして利用できるため、修正作業の負荷を大幅に軽減 修正不要な場合も「理由」を明示し、レビュイーの安心感につなげる 表記ゆれや曖昧な表現、Markdownやリンク構文、見出し階層など、幅広い観点 で自動的に指摘・提案 ポイント：原文・修正案・理由がセットで返ってくるため、迷わず・すぐに修正 対応が可能。修正案はコピペで即反映でき、手戻りや作業負荷も最小限。理由も 明確なので納得感が高い #nncstudy
17. Copyright（C） NRI Netcom, Ltd. All rights reserved. 効果と実感値 手動校正: 30分 Claude校正: 1 3分以内 抜け漏れが減り、レビュー指摘が一貫性を持つように レビュアーが「観点に集中」できる 書き手も安心、レビューの質も安定 #nncstudy
18. Copyright（C） NRI Netcom, Ltd. All rights reserved. 実際にやってみて見えてきた課題・気付き PoC運用を通じて直面した主な課題や現場での気付き 指摘内容の粒度や厳しさが記事やプロンプトによってばらつくことがある 修正案が必ずしも文脈に最適とは限らず、最終判断は人間の目が必要 カジュアルな表現やブログらしい砕けた言い回しまで厳しく修正されてしま うケースがあった レビュー結果の履歴管理やナレッジ化の仕組みが今後の課題 これらの課題を踏まえ、プロンプト設計や運用フローの改善、AIと人間の役割分 担の最適化が重要 #nncstudy
19. Copyright（C） NRI Netcom, Ltd. All rights reserved. MCP（Model Context Protocol）とは？ AIモデルと外部データソースやツールを標準化された方法で接続するためのオー プンプロトコル 異なるAIサービスや業務システム間での情報共有・指示連携の容易さ 柔軟な自動化・連携の実現 AIアプリケーションにおける「USB-Cポート」のような役割 #nncstudy モデルA モデルB モデルC データソース ツール1 ツール2 モデルA モデルB モデルC データソース ツール1 ツール2 MCP
20. Copyright（C） NRI Netcom, Ltd. All rights reserved. アーキテクチャの今後（MCP連携の展望） 今後はMCPを活用した機能追加を検討中 AWSドキュメントを参照しながら専門的なレビューを行う BacklogのMCPを使ってチェック項目を管理・自動化 レビューの進捗や指摘事項をチケットで一元管理できるようにしたい これにより、より高度で実践的なレビュー体験や、他ツールとの連携強化を目指 す #nncstudy
21. Copyright（C） NRI Netcom, Ltd. All rights reserved. Dify × MCP 統合チャレンジ 試したこと：AWSドキュメントのMCPをDifyのTool機能で使おうとした MCPのトランスポートには2種類がある stdio（標準入出力）：ローカルやコマンドライン向け SSE（Server-Sent Events）：Webやネットワーク越しの連携向け どちらもJSON-RPC 2.0形式でメッセージをやりとり 課題 MCPはstdioトランスポート用で作られており、DifyのTool（SSE前提）と連 携できなかった mcp-proxyを試したが、エラーが発生して断念 学び Difyは対話＋LLM処理には最適だが、外部ツール統合は限定的 #nncstudy
22. Copyright （C ） NRI Netcom, Ltd. All rights reserved. 外部ツール連携の選択肢 MCP 連携を見据えた外部ツール連携では、Dify ではなくMastra やStrands Agents の利用を検討中 どちらもMCP クライアント（ホスト）として、複数モデルや外部MCP サーバ のツールを柔軟に呼び出せる Mastra はTypeScript/JS 中心、Strands Agents はPython/AWS インフラとの親 和性が高い 公式のMCP ドキュメントサーバや自社ナレッジベースとの連携も容易 今後の方針 MCP ツール呼び出しはMastra またはStrands Agents で実装 Claude は校正・レビュー専任に これにより拡張性・運用性・他ツール連携の幅が広がる #nncstudy
23. Copyright（C） NRI Netcom, Ltd. All rights reserved. まとめ Claude × Slackでレビューが自動化、所要時間は1/6以下に DifyでPoCを素早く実現、試行錯誤に向いていた WorkflowとAgentの違いや使い分けの判断基準も整理でき、今後の設計・運用の 指針が明確に 本格運用・拡張に向けては、MastraやStrands AgentsによるMCP連携を検討中 「レビューは人がやるもの」という常識から脱却できる構成を実現 #nncstudy
24. Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy