技術ブログのファクトチェックをAI Agentに任せる

レバレジーズ株式会社テクノロジー戦略室の苑田です。

苑田が技術ブログのファクトチェックをするときによく使うツールを紹介します。

⚠️この記事では、記事の内容をゼロから生成AIに作らせるのではなく、自分で書いた内容の検証や校正を効率化する方法を紹介します｡

ファクトチェック

記事を書いていると、その情報が正しいのか最新なのかを確認したくなることがあります。そのときは、以下のツールを使うと便利です。

Deepwiki MCP(OSSに関する情報)
DeepResearch系(実際に使用されている記事に関する情報)
ドキュメント系MCP(公式ドキュメントに関する情報)

それぞれ説明していきます。

Deepwiki MCP

Deepwiki MCPはOSSに関する情報を確認するときに便利です。例えば、Strands AgentsのSwarm機能について詳しく調べたいときに、Deepwiki MCPに以下のように質問します。

strands agentsのSwarmが何をしているのかをdeepwiki mcp（strands-agents/sdk-python）で調査し、まとめてください。

そうすると、以下のような回答が返ってきます。

  概要

  Strands Agents SDKのSwarmは、自己組織化するエージェントチームによる自律的な協調を実現するマルチエージェントパターンです。共有メモリとツールベースのハンドオフを使用して、動的なタスク分配と集合知を実現します。

  アーキテクチャ

  主要コンポーネント

  - Swarmクラス: MultiAgentBaseを継承し、エージェントの協調を管理
  - SwarmNode: 各エージェントをラップし、初期状態を保持
  - SharedContext: 全エージェント間で共有される作業メモリ（JSON形式）
  - SwarmState: 実行状態を管理（現在のノード、タスク、完了状態、履歴、メトリクス）

  主要機能

  1. 自己組織化エージェントチーム
    - 中央制御なしでエージェントが自律的に協調
    - 動的なタスク分配
  2. ツールベースのハンドオフ
    - handoff_to_agentツールを各エージェントに自動注入
    - エージェント間の制御移譲を実現
  3. 共有作業メモリ
    - SharedContextによる情報共有
    - 集合知の構築
  4. 動的コンテキスト伝播
    - ハンドオフ時に豊富なコンテキストを伝達
    - 実行履歴、共有知識、利用可能エージェントリスト
  5. 実行制御とループ防止
    - max_handoffs: 最大ハンドオフ回数
    - max_iterations: 最大反復回数
    - execution_timeout: 実行タイムアウト
    - repetitive_handoff_detection_window: 繰り返し検出

  動作フロー

  1. 初期化: エージェントリストでSwarmインスタンスを作成
  2. ツール注入: 各エージェントにhandoff_to_agentツールを自動注入
  3. 実行ループ: 現在のエージェントがタスクを実行
  4. ハンドオフ: エージェントが判断して他のエージェントに制御を移譲
  5. コンテキスト構築: 次のエージェントに包括的な情報を提供
  6. 完了: ハンドオフがなくなるか、制限に達したら終了

  他のマルチエージェントパターンとの比較

  | パターン  | 用途         | 協調方式        | 実行方式          | 状態管理                       |
  |-------|------------|-------------|---------------|----------------------------|
  | Graph | 決定論的ワークフロー | エッジベース条件付き  | 依存関係に基づく順次/並列 | GraphState                 |
  | Swarm | 自己組織化チーム   | ツールベースハンドオフ | 動的ハンドオフ駆動     | SharedContext + SwarmState |
  | A2A   | システム間相互運用性 | HTTPプロトコル   | リクエスト/レスポンス   | 外部管理                       |

  Swarmの利点

  1. 非決定論的フローに適している
    - 事前に正確な手順が不明な問題に対応
    - 動的に変化する状況への適応
  2. 柔軟な問題解決
    - エージェントが自律的に最適な次のエージェントを選択
    - 状況に応じた動的なタスク分配
  3. 共有知識による集合知
    - SharedContextによる情報蓄積
    - 各エージェントの貢献が全体に反映
  4. シンプルなセットアップ
    - Graphパターンのような複雑なノード・エッジ定義が不要
    - エージェントリストを渡すだけで協調システムが構築

  実用例

  データ分析→コードレビュー→セキュリティチェックのような、専門性の異なるエージェントが順次または協調して問題を解決するシナリオに最適。各エージェントは自身の判断で次のエージェントにタスクを引き継ぎ、コンテキストと共有知識を活用して効率的に問題を解決します。

このように、いちいちgithubのソースコードを確認せずとも、OSSの情報を調べることができます。

DeepResearch系

OSSの使用方法だけではなく、実例を調べたくなることもあると思います。例えば、Strands Agentsは2025/07/16にリリースされたばかりなので、日本ではあまり情報がありません。全世界でどのように使われているのかを調べるときに、DeepResearchを使うと便利です。 DeepResearchはそれっぽいことを書くので、正直読むのが疲れますが、この際に欲しい情報は引用です。

AWS関連なので、Builder Center読んどけ感はありますが、実際に使われている記事を調べるときに便利です。

ドキュメント系MCP

ある程度事例が集まってきて記事をまとめていると、本当にこれが正しいのか、最新の情報なのかを確認したくなることがあります。 DeepResearchは便利ではありますが、さまざまな情報を集めてきてまとめているので、内容が正しくない部分があります。そういう詳細を調べたいときは、ドキュメント系MCPを使うと便利です。

例えば、以下のようなまとめ方をしたとします。

API Gatewayのタイムアウト制限は29秒で変更不可能です。

生成AIアプリケーションを作成している人は、API Gatewayのタイムアウト制限が29秒ではなく、延長リクエストを使用して延長可能であることを知っています。なぜなら、LLMのレスポンス時間が29秒を超えることがよくあり、Lambdaの関数URLを使用して回避していたからです。しかし、API Gatewayを使用していない人は、あまりよく知らないと思います。実際、Claude Codeに聞いてみても、延長不可能と回答してきます。

⏺ API Gatewayのタイムアウト制限は 29秒 です。

  これはAWS API Gatewayのハードリミットで、リクエスト処理が29秒を超えると自動的にタイムアウトエラー（504 Gateway Timeout）が返されます。

  主なAPI Gatewayのタイムアウト関連の制限：
  - REST API: 29秒
  - HTTP API: 30秒
  - WebSocket API: アイドルタイムアウト10分、接続時間最大2時間

> 延長リクエストとかある？

⏺ API Gatewayのタイムアウト29秒は延長できません。これはAWSのハードリミットです。

  ただし、以下の回避策があります：

  1. 非同期処理パターン
    - Lambda + SQS/SNSで非同期実行
    - Step Functionsで長時間処理を管理
    - 処理開始時にジョブIDを返し、別エンドポイントでステータス確認
  2. WebSocket API
    - 最大2時間の接続維持が可能
    - リアルタイムで処理状況を通知
  3. Lambda関数URLs
    - 最大15分のタイムアウト設定が可能
    - API Gateway経由ではなく直接Lambda実行
  4. ECS/Fargateへの直接接続
    - Application Load Balancer経由で最大4000秒まで設定可能

ここで、ドキュメント系MCPを使って以下のように質問します。

以下の文章が正しいかどうかをaws document mcpを使用して、調査してください。
情報は最新でお願いします。
「API Gatewayのタイムアウト制限は 29秒で変更不可能です。」

すると以下のように返ってきます。

⏺ 調査結果

  文章「API Gatewayのタイムアウト制限は 29秒で変更不可能です。」について

  部分的に正しくないです。

  実際の仕様：

  REST API の場合:
  - Regional APIs: 50ms～29秒（変更可能）
  - Edge-optimized APIs: 50ms～29秒（変更不可能）
  - Private APIs: 50ms～29秒（変更可能）

  HTTP API の場合:
  - 最大統合タイムアウト: 30秒（変更不可能）

  訂正ポイント：

  1. 29秒は上限値だが、変更可能なケースがある
  2. Regional APIとPrivate APIでは29秒を超えて設定可能（ただしアカウントレベルのスロットルクォータ削減が必要）
  3. HTTP APIは30秒が上限

  結論: 「変更不可能」という部分が不正確。APIタイプによって変更可能性が異なります。

  参考URL: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-execution-service-limits-table.html

先ほどは、延長不可能と回答してきましたが、実際は変更可能なケースがあることがわかりました。このように、ドキュメント系MCPを使うことで、最新の正しい情報を調査することができます。もし、何度も同じことを質問するなぁと思ってきたら、カスタムプロンプトに登録しておくと便利です。

エディタ

基本的に記事を書く場合は、VSCodeなどのエディタを使うといいです。理由は、記事の内容をこまめにcommitでき、差分が確認しやすいからです。

例えば、とある文章を作成し、表記揺れや誤字脱字を修正するときに、AIにレビューさせるとします。毎回Geminiとかでこれをコピペして確認すると、どこが修正されたのかがわかりにくく、毎回同じことを質問するのが面倒です。しかし、VSCodeであれば、一旦作成してcommitしておき、AIにレビューさせると、差分がわかりやすいです。