Wordコメント返信を自動化する｜Claude Fableで1時間を10分に

この記事の結論（30秒で読める要約）

• Wordの吹き出しコメントで往復する「弁護士と事業部の押し戻しラリー」は、.docx の中身が ZIPとXMLの塊 だと分かれば、そこにAIを差し込む余地が一気に広がります。
• 標準的なAI（Opus 4.6やSonnet）ではコメントの流れを全部読み切れず、ちぐはぐな返信になりがちでした。1M（100万トークン）文脈対応の Claude Opus 4.7、社内呼称「Fable」 で、その壁を超える手応えが出はじめています。
• 大手SaaS（LegalOn／LegalForce／Microsoft Word Legal Agent）は一般論のレビューが強い一方、自社独自の押し戻し慣習まで含めた返信自動化 は、Claude Code Skill＋docx-comments などの自作ラインが現実解です。
• 過去の交渉ログや押し戻しパターンを、Snorbe（deskrex.aiのAIリサーチエージェント。社内ナレッジをグラフ構造で関連づけて記憶するAI）に貯めて次案件で呼び出す「反復ループ」を組めば、来週の月曜からレビュー時間の圧縮が体感できます。

契約書のWordファイルに、弁護士から吹き出しコメントがずらっと並んでいる。それを事業部が1件ずつ読み、意図をくみ取って修正案を書く。相手方から返ってきたコメントに、また弁護士がコメントを重ねる。……気づけば1件の契約に1時間、数往復すれば1日が溶けていく。

法務・総務・コンサルの現場では、この「Wordコメント押し戻しラリー」がかなり深刻な時間泥棒になっています。しかも、多くの人は「そういうものだ」と半ばあきらめているのではないでしょうか。

この記事では、その1時間を10分にたたむための現実的な道筋を、なるべく中学生が読んでも意味が取れる粒度で解説します。ただし、専門性は落としません。.docx の内部XMLの話、Claude Fable（Opus 4.7 1M）ならではの強み、契約書レビュー系SaaSとの棲み分け、Before/After のサンプル会話、そして月曜日から始められる反復ループまで、順番に降りていきます。

1. 弁護士コメント押し戻しラリーの正体｜なぜ1件で1時間溶けるのか

まず「なんとなく重い」の中身を分解します。

契約書レビューは、事業部 → 法務・弁護士 → 事業部 → 相手方、と情報が三角形で行ったり来たりします。BUSINESS LAWYERS の解説によれば、レビュー完了後の修正交渉から合意形成までは、順調で数日、拗れると数ヶ月かかることも珍しくありません（BUSINESS LAWYERS「契約書レビューとは？」）。マネーフォワードの解説でも、リーガルチェック後の修正交渉フェーズが総所要期間の大半を占めると整理されています（マネーフォワード「リーガルチェックにかかる期間は？」）。

現場を眺めると、Wordコメントの中身は大きく4パターンに分かれます。

1. 「承諾」、このままでよい、というシンプルな返し
2. 「条件付き受諾」、ここを直せば飲めます、という部分同意
3. 「代替案の提示」、別の書き方に差し替えたい、という具体提案
4. 「削除要請」、この条項自体を落としたい、という強い押し戻し

事業部から見て一番しんどいのが、3と4です。弁護士は「この条項は当社基準に照らして受け入れ困難」とだけ書きがちで、事業部は「じゃあ具体的にどう書けば通るの？」と迷います。ここで質問メールを飛ばし、往復1〜2日、というのがよくあるロス構造です。

LegalAgent の分析では、この遅延を減らす順序として「AIが一次的に論点を拾い、弁護士が社内判断基準とリスク許容度に照らして確認し、事業部が次に動ける形にして返す」流れが挙げられています（LegalAgent「契約レビューはなぜ遅くなるのか」）。この「AIが一次的に論点を拾い、事業部が次に動ける形で返す」という部分を、Word上のコメントスレッドで直接やってしまおうというのが、この記事の主題です。

では、なぜAIをここに差し込む余地があるのでしょうか。それを理解するために、まず .docx ファイルの正体を見に行きます。

2. .docx の中身は「ZIP＋XML」｜中学生にもわかるOOXMLコメントの仕組み

Wordの .docx ファイル、ダブルクリックで開くとWordが立ち上がるだけの、あの拡張子。実はあれ、中身は ZIP圧縮ファイル です。試しに .docx のコピーを作って、拡張子を .zip に書き換えて解凍してみると、フォルダとXMLファイルの束が出てきます。

この形式は「Office Open XML（OOXML）」と呼ばれ、ISO 29500 と ECMA-376 という国際規格になっています（Library of Congress「DOCX Transitional」）。要するに、Wordの独自バイナリではなく、世界共通のルールに沿ったXMLだ、ということです。

.docx を解凍すると、こんなファイルが並んでいます。

word/
  document.xml        ← 本文（段落、表、画像の位置など）
  comments.xml        ← コメント本体
  commentsExtended.xml← コメント返信スレッドの親子関係
  commentsIds.xml     ← コメントのグローバル一意ID
  styles.xml          ← 見出しや太字などのスタイル定義

コメント1件は word/comments.xml に格納される <w:comment> という要素です。ECMA-376仕様サンプル（c-rex.net）に沿って、実際の中身をのぞくと、こんな感じになっています。

<w:comments xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
  <w:comment w:id="0"
             w:author="法務・田中"
             w:date="2026-07-08T10:14:00Z"
             w:initials="TN">
    <w:p><w:r><w:t>本条は当社基準に照らして受け入れ困難。要協議。</w:t></w:r></w:p>
  </w:comment>
</w:comments>

見慣れないタグが並んでいますが、意味はシンプルです。

• w:id="0" はコメントの通し番号
• w:author はコメント主
• w:date は日付（世界標準の書き方）
• 中の <w:p><w:r><w:t> は「段落 → 文字のかたまり → 実テキスト」の入れ子

そして、本文側の word/document.xml には、「ここからここまでの本文にコメントが付いていますよ」というマーカーが埋め込まれます。

<w:commentRangeStart w:id="0"/>
<w:r><w:t>秘密保持義務違反に基づく損害賠償</w:t></w:r>
<w:commentRangeEnd w:id="0"/>
<w:r><w:commentReference w:id="0"/></w:r>

w:id="0" という同じ番号で、コメント本文と本文の該当箇所がひも付いています。このひも付けをプログラムで読み解くことで、「どの条項に、どんなコメントが、誰から、いつ付いたか」を機械的に取り出せます。

さらに Word 2019以降のコメント 返信スレッド は、word/commentsExtended.xml に格納されます。

<w:commentsEx xmlns:w="...">
  <w:commentEx w:paraId="0000A1B2" w:done="0"/>
  <w:commentEx w:paraId="0000A1C3" w:parentPaeaId="0000A1B2" w:done="0"/>
</w:commentsEx>

w:parentPaeaId で「このコメントは、あのコメントへの返信ですよ」と親子関係を表現しています。Wordのコメント欄で「↵ 返信」を押したときに作られるアレの正体です。

Microsoft公式のOpenXml SDKドキュメント（Comment Class、コメント取得の手順）でも、この構造でコメントを読み書きする流儀が説明されています。

要するに、Wordのコメントを自動処理したいなら、.docx を解凍して comments.xml と commentsExtended.xml を読めばよい。理屈はこれだけです。あとは「読んだあと、どうAIに返信ドラフトを作らせるか」というモデル選びの話になります。ここからが、Claude Fable の出番なんじゃないかな、と思っています。

3. Claude FableがOpus 4.6を引き離した「1M文脈」の使い所

Anthropic は2026年、Claude Opus 4.7 を発表しました（Introducing Claude Opus 4.7、Claude Migration Guide）。特徴を実務者目線でまとめると、こうなります。

• 長時間走行するエージェント用途に強くなっています
• トークナイザが更新され、同じテキストでもトークン消費の勘所が変わります
• 高解像度画像入力（最大2576ピクセル）に対応しています

そして、契約書の押し戻しラリー自動化にとって特に大きいのが、「1M（100万トークン）」バリアント の存在です。当媒体では、この長文脈対応のOpus 4.7を社内で Fable と呼んでいます。

なぜ1M文脈がここで効くのか。契約書レビューの返信ドラフトを作るとき、AIが読むべき素材は次のように積み上がります。

• 今レビュー中の契約書本文（数千〜1万トークン）
• そこに付いている全コメントスレッド（数百〜数千トークン）
• 自社の秘密保持プレイブック、下請法プレイブック、業法プレイブックなど（合計 3万〜10万トークン）
• 同種契約の過去12件、そこでの弁護士押し戻しログ（10万〜20万トークン）
• 相手方との過去交渉メール／議事録（さらに10万〜20万トークン）

「1件の契約書」だけならOpus 4.6でも十分ですが、「自社の慣習にそって、取引先の癖まで踏まえて返信案を作る」となると、素材が一気に膨らみます。Opus 4.6の200k文脈だと、途中で「話の頭が抜けた」ような回答が返ってきがちでした。特に、コメント20件超・過去契約10件超を一度に渡すシチュエーションで、返信の一貫性が崩れました。

Fable（Opus 4.7の1Mバリアント）に切り替えると、この崩れ方が目に見えて減ります。契約書全文＋全コメント＋自社プレイブック＋過去12件を一気に読ませても、「秘密保持義務違反時の損害賠償上限を、当社基準では直接損害に限定する慣行があります」といった、社内の癖に沿った返信ドラフトが素直に出るようになりました。トークナイザの更新でカウントは変わるので、コスト側のリグレッションは事前に確認が必要です（Claude Opus 4.7 Deep Dive（Caylent））が、少なくとも「文脈落ちで返信品質が崩れる」問題は、Fableに切り替えたときが分岐点でした。

ここで大事なのは、モデルを1M文脈にした瞬間、記事の冒頭で触れた4つの押し戻しパターンのうち、3の代替案提示と4の削除要請にも、Fableが具体案を返せるようになる点です。「受け入れ困難」で終わらせず、「過去の同種契約12件では、こう書き換えて相手方に飲ませました」まで一気に返信できます。事業部が次に動ける形で情報が返ってくる、というのはこういう状態です。

Anthropicは公式アドインの Claude for Word も提供しており、そのヘルプページでも 「Comment-driven editing（コメント駆動編集）」 として、コメントスレッドを読み、対象本文を編集し、スレッドに返信する、というワークフローが紹介されています（Use Claude for Word（Anthropic公式サポート）、Claude for Word ガイド）。Fableをこの流儀で使うと、「1つずつコメントを潰していく事業部担当者」の役割を、下書きレベルで置き換えられます。

技術寄りの方は、コミュニティ発の Claude Code Skill も見ておく価値があります。tim-hua-01 さんが2026年2月に公開した comment-on-docx は、read_document_runs.py というスクリプトで .docx を 「run」単位（書式が一貫する最小の文字列単位）まで分解して読み込み、Claudeにコメントを追記させる仕組みです。LessWrong にも公開時の解説記事があります（A Claude Skill To Comment On Docs）。

Python側の下ごしらえエコシステムは、意外なほど整っています。

• python-docx 1.2.0は、コメントの読み込みと追加ができます。ただし「返信（reply）」と「解決（resolve）」は現時点で未実装、と公式ドキュメントに明記されています
• sunt05/docx-commentsは、python-docxの手が届かない返信・解決に対応しています。Word Onlineとの互換もキープしています
• Spire.Doc for Pythonは、コメントスレッドの返信から担当弁護士名の差し替えまで、一通り対応しています

「Fable が思考、Python が手先」と割り切ると、実装のかたちが見えてきます。次の章で、その組み合わせが1件どう回るかを、具体ケースで追いかけます。

4. Before/After｜秘密保持契約の第4条を10分で戻すサンプル

ここまでの話を、1つの契約案件に落とし込みます。想定は、日常でよくある 秘密保持契約（NDA）第4条：損害賠償条項 の押し戻しラリーです。数字と会話は当媒体で観察した典型パターンから合成した架空例ですが、業界の人ならすぐに「ああ、これはあの局面」と分かるはずです。

Before：Word往復に1時間かかっていた頃

弁護士から返ってきた 契約書_v2.docx を開くと、第4条の横に赤い吹き出し。

法務・田中（10:14） 本条は当社基準に照らして受け入れ困難。要協議。

事業部の担当者は、この一文だけで動けません。「当社基準」って何？「受け入れ困難」ってどこまで押し戻すの？

やりがちなムーブは、この3つです。

1. まず法務にSlackで「これって具体的にどう直せばいいですか？」と聞いてみます
2. 次に過去のNDA案件のフォルダを漁って、似た条項の書き換え例を探します
3. 最後に相手方の営業担当者に「一旦社内で検討します」と保留メールを打ちます

このステップに、体感1時間。運が悪ければ弁護士の返信が翌日、というのもザラでした。

After：Fable＋Snorbeループで10分に

同じ第4条を、Fable（Opus 4.7 1M）＋Claude Code Skill＋Snorbeナレッジグラフに通します。

1. Claude Code Skill（comment-on-docx 系）が 契約書_v2.docx を解凍し、comments.xml と本文XMLを取り出します
2. Snorbeのナレッジグラフから、過去のNDA12件と、そこでの弁護士押し戻しログ、相手方との交渉メールを引きます
3. Fableに、契約書全文と全コメント、NDAプレイブック、過去12件を一度に渡します
4. Fableが返信ドラフトをJSON形式で返します
5. Python側で、返信ドラフトを w:comment として comments.xml に書き戻し、commentsExtended.xml の親子関係も一緒に追記します
6. 事業部担当者がWordでファイルを開き、Fableの返信ドラフトを確認します。そのまま送信するか、1〜2箇所だけ書き換えて送信します

Fable の出す返信ドラフトは、たとえばこんな内容になります。

Claude Fable（Draft, 10:22） 直近12件のNDA案件で、当社は損害賠償上限を「本契約に起因して現実に発生した直接損害に限る」と定義し、いずれも合意に至っています（案件2025-04〜2026-06、Snorbe参照: nda-directdamage-precedent-2026Q1）。第4条の該当箇所を以下の通り修正するご提案でいかがでしょうか。

• 修正前：「秘密情報の開示によって相手方に生じた一切の損害を賠償する」
• 修正後：「秘密情報の開示によって相手方に現実に発生した直接損害を賠償する（間接損害・逸失利益・特別損害は含まない）」

相手方は昨年の共同開発契約時にも同旨で妥協実績あり（案件2025-11、担当・弁護士 山田）。事業部で問題なければ、このまま先方に返送で問題ない見込みです。

これが吹き出しコメントとしてWord上に自動追記されるので、事業部担当者は返信案を読んで、「OK、このまま送ります」と返すだけ。手作業でやっていた3ステップが、Wordを開いて中身を確認する所要時間になります。実測で10分前後。

内部的には、書き戻される comments.xml はこう変化します。

<w:comment w:id="0" w:author="法務・田中"
           w:date="2026-07-08T10:14:00Z" w:initials="TN">
  <w:p><w:r><w:t>本条は当社基準に照らして受け入れ困難。要協議。</w:t></w:r></w:p>
</w:comment>
<w:comment w:id="1" w:author="Claude Fable (Draft)"
           w:date="2026-07-08T10:22:00Z" w:initials="CF">
  <w:p><w:r><w:t>過去12件のNDAで採用した「直接損害限定」表現に差し替え提案します。</w:t></w:r></w:p>
</w:comment>

そして commentsExtended.xml に、Fableの返信が田中さんのコメントに紐づいた 返信スレッド として登録される、という寸法です。

小規模なコードイメージも、雰囲気だけ添えておきます。実務では例外処理や差分検出をもっと足しますが、骨格はこれだけです。

# Spire.Doc for Python の例（返信スレッド追加）
from spire.doc import Document, Comment

doc = Document()
doc.LoadFromFile("契約書_v2.docx")

original = doc.Comments.get_Item(0)          # 田中さんの元コメント
reply = Comment(doc)
reply.Format.Author = "Claude Fable (Draft)"
reply.Format.Initial = "CF"
reply.Body.AddParagraph().Text = fable_draft  # Fable が返した返信ドラフト
original.ReplyToComment(reply)               # 返信スレッドとして紐付け

doc.SaveToFile("契約書_v3.docx")

fable_draft に何を突っ込むか、が本命の設計ポイントです。ここに「今の契約全文＋全コメント＋過去12件＋自社プレイブック」を1M文脈に流し込めるモデル、つまりFableが刺さります。Sonnetでも短いレビューなら回りますが、「押し戻し2周目・3周目」の履歴が積み上がった重い局面では、Fableの1M文脈が体感で最も安定します。

「AIっぽい返信」で先方をイラッとさせないコツ

もう1点、Before/Afterで見落とされがちなのが 語気の統一 です。「Fable が返信をJSON生成 → Python で w:comment に書き戻す」だけでは、返信文が急に丁寧になったり、翻訳調になったりして、相手方の弁護士に「AIぽくてやりづらい」と感じさせることがあります。

これを避けるには、Fableに渡すプロンプトの中に 社内の過去コメント履歴サンプル（田中さんの実際のコメント10件など）を貼り、「この人格・語気に寄せて返信を書いてください」と指示するのが手っ取り早いです。Snorbeに担当者ごとの過去コメントを貯めておくと、これが自然に自動化できます。

5. SaaSと自作Fable運用の使い分け＋月曜から始めるSnorbeループ

「じゃあ、既存の契約書レビューSaaSはもう要らないんですか？」と聞かれると、答えはNoです。むしろ 併用が現実解 です。

2026年前半、Word内エージェントは競合が一気に激化しました。

• Microsoft Word Legal Agent、2026年4月30日発表。GPT-4系＋「deterministic resolution layer」で、Wordの書式・変更履歴を保持したまま編集する仕組み（Law.com、BigGo解説）
• LegalOn Contract AI（LegalOn Technologies）、Word上で契約直接編集、弁護士監修レビュー基準、リスクアラート、修正案提案
• LegalForce（LegalOn Technologies）、契約類型×立場でリスク指摘、条文検索、類似文書比較、Wordアドイン
• マネーフォワード クラウドAI契約書レビュー（PR TIMES）、弁護士監修、Word/PDF差分比較
• LeCHECK（株式会社リセ、ITトレンド比較）、3人に1人が契約レビュー時間を約半分以下に短縮したと発表。ライトプランは和文10,000円/月から
• Spellbook（Legal AI Reviews）、Toronto発のWordアドイン

強みは共通していて、「一般論としての契約レビュー」が速いことです。専門弁護士が監修した基準と雛形が最初から入っていて、下請法や個人情報保護法など、日本の法改正にも継続追随してくれます。中小の法務チームで、月に数十件の契約を回すなら、SaaSは生産性を押し上げます。

一方、SaaSが弱いのは、「自社の押し戻し慣習」「取引先ごとの過去交渉ログ」まで踏まえた返信案の生成です。SaaS側は多くの企業に売る前提で標準化されているので、「うちは損害賠償上限を必ず直接損害に限定する」「あの取引先の田中さんは3回押せば必ず飲む」といった、自社固有・関係性固有の情報は溜まりません。

このギャップを、Fable＋Claude Code Skill＋Snorbeで埋めるのが、この記事の本命の絵です。使い分けの目安は、ざっくりこう捉えると分かりやすいです。

月曜から始めるSnorbe反復ループ

「明日からいきなり全部やるのは重い」という方に向けて、Snorbeを軸にした反復ループの立ち上げ手順を、なるべく小さくたたんで紹介します。1週間目は情報を貯めるだけ、2週間目から返信ドラフト生成に踏み込むイメージです。

1. 今週：過去のNDAや業務委託契約を10件、Snorbeにアップロードします。契約本文だけでなく、弁護士がつけた過去のWordコメント、事業部からの返信メール、最終締結版までを1セットにして投入します
2. 今週：自社プレイブックを1〜2本、Snorbeに登録します。秘密保持義務、損害賠償、解除、準拠法など、社内で「これは必ずこう返す」というルールを、テキストで箇条書きにして投入します
3. 来週：新規案件が来たら、Claude Code Skill＋Fableで返信ドラフトを試作します。comment-on-docx 系のスキルを使い、Snorbeから過去10件とプレイブックを引きながら、Fableに全コメント一括で返信ドラフトを書かせます
4. 来週：事業部担当者は「AIドラフトを読んで送るだけ」の役に徹します。最初の週は3〜4件、Before/Afterのレビュー時間を実測してログを取ります
5. 翌々週以降：反復ループを回します。実測して短縮効果が出た案件のパターンをSnorbeに追加し、Fableのプロンプトも社内の語気に合わせて微調整します

Snorbeが得意なのは、契約書・コメント・交渉メール・判断ログを同じナレッジグラフ上でつなげて記憶するところです。SaaS側にはノウハウが貯まりませんが、Snorbeなら「あの取引先の押し戻し傾向」や「あの弁護士がよく使う言い回し」まで、社内資産として貯まっていきます。月曜からのループは、まずは lp.deskrex.ai からSnorbeに触れてみるのが最短ルートです。

今後の展望（短く）

2026年は契約書レビューが「Word内エージェント×自社プレイブック」の年になりました。SaaS陣はプレイブックを共通化し、Anthropic陣はComment-driven editingとOOXML直操作を重層化しています。中小法務・地方の弁護士事務所は、月額数十万円のSaaSに手が届かないケースがまだ多く、Claude Code＋docx-comments＋Snorbeの自作ラインは、SaaSに置き換わる新しい選択肢として広がる余地があります。

予測を1つだけ置いておくと、2027年までに「押し戻し交渉ログをナレッジ化して次案件に転用する会社」と「毎回ゼロから弁護士に投げる会社」の間で、月間の契約締結件数に3〜5倍の開きが出る可能性があります。押し戻しは知的財産です。溜めるか、溜めないか。それだけで、法務担当の1日の使い方が変わります。

Wordの吹き出しの向こう側には、まだたっぷり自動化の余地が残っています。月曜、契約書_v2.docx を開いたら、まずは中身を .zip に展開して、comments.xml をのぞいてみてください。押し戻しラリーの入り口にFableを一体差し込むだけで、あなたの1時間が10分になります。

FAQ｜Wordコメント返信自動化とClaude Fableへのよくある質問

Q1. .docx の中を解凍していじって大丈夫ですか？Wordが壊れませんか？

バックアップを取ってから触るのが大前提ですが、OOXMLはISO 29500として国際規格化された公開仕様なので、python-docx や Spire.Doc など専用ライブラリを介せば、Word上で開けなくなるリスクはほぼありません。ヒヤリとしやすいのは、comments.xml に手作業で w:id を書き足すときの整合性ミスなので、原則ライブラリ経由で書き込みしてください。

Q2. Claude Fableを使う場合、契約書を外部に送っても大丈夫ですか？機密情報が心配です

Anthropicの契約プランや自社のNDAポリシー次第です。Enterprise契約であれば入力データが学習に使われない設定にできます。厳密な機密案件は、まず社内のクラウド利用ポリシーを法務と情シスに確認し、必要に応じてClaude for Enterpriseや、Bedrock（Amazon Web Services上でClaudeを動かすホスティング）／Vertex（Google Cloud上でClaudeを動かすホスティング）経由の運用を検討する流れが安全です。

Q3. LegalForce や LegalOn を使っているのですが、Fable運用と併用するメリットはありますか？

あります。SaaS側は「一般論として合っているか」を早くチェックしてくれますが、「自社の押し戻し慣習に沿って、取引先固有の交渉履歴まで踏まえた返信ドラフトを作る」用途では、Fable＋Snorbeで自社データを持ち込んだ方が刺さります。SaaSで一次スクリーニング、Fable＋Snorbeで返信ドラフト、と役割分担する併用パターンが現実解です。

Q4. Claude Sonnet や Opus 4.6 ではダメですか？

コメント数件・契約書1本の短い場面ならSonnetでも十分回ります。ただ、コメント20件超・過去契約10件超・自社プレイブックまで一度に読ませる「押し戻し2周目・3周目」の重い局面では、Fable（Opus 4.7 1M）の1M文脈がもっとも安定します。用途で使い分けるのがコスト・品質の両立に向いています。

Q5. 事業部担当者は、Fableの返信ドラフトをそのまま送っていいですか？

初期の1〜2ヶ月は、必ず担当者と弁護士が目視レビューしてから送るのが安全です。Fableが提示する「過去12件で採用された表現」の中に、案件の性質に合わない条項が紛れることがあります。慣れてきたら、リスクの高い条項（損害賠償、解除、準拠法など）だけは人間レビュー必須、それ以外はFableドラフトほぼそのまま、といったポリシーに段階的に切り替えていくのが自然です。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/