拒絶理由コメントはHTMLでいいかもしれない

TL;DR
LLMに考えさせる媒体としては、ノイズが少なく軽いMarkdownが有用。
人間が拒絶理由コメントやOA対応方針を判断する場面では、HTMLの可視性・構造化の強みが大きい。
実務では、Markdown/JSONを原本にして、HTMLを人間向けビューとして生成する二層構造がよさそう。

MarkdownとHTMLの使い分けを、特許業務の視点で考える

Obsidianを使い始めて、いつの間にか一年が経ちました。

生成AIへの入力は、基本的にいったんObsidianで書いてからコピペしています。そうすると、あとから「あのときのプロンプト、なんだっけ？」となることがかなり減ります。

また、私はObsidianのSync機能は使わず、ローカルのみで運用しています。そのため、情報漏洩のリスクを抑えられますし、バックアップも定期的に取っています。中身は基本的にMarkdownの束なので、一年使っても容量は10MBにも届いていません。

このように、私の業務はかなりMarkdown中心で回っています。特許公報などの情報も、いったんMarkdown化してから処理することが多く、ObsidianとMarkdownはもはや手放せない存在です。

先日も、審査基準をMarkdown化する記事を書いたばかりでした。

ところが最近、「MarkdownよりHTMLでは？」という議論を目にしました。

最初は「えー、そんなことある？」と思いました。
ただ、よく考えると、先月くらいにコーディングエージェントを使って拒絶理由コメントを試作したとき、私自身もこう思っていたのです。

「これ、docxである必要ある？ HTMLでよくない？」

MarkdownはLLMにやさしい。でも人間に最適とは限らない

先日の記事では、HTMLにはソースコード中に装飾や構造などの余分な情報が含まれるため、エージェントが扱う情報媒体としては非効率ではないか、という結論を書きました。

この考え自体は、今でも大きくは間違っていないと思っています。

LLMに処理させるための情報媒体としては、Markdownはかなり優秀です。
意味情報に対するノイズが少なく、文章構造もそこそこ表現でき、しかも軽い。私が日々の業務でMarkdownを使っている理由もそこにあります。

人間の可読性でいえば、Markdown、YAML、JSONの順に読みやすい、という理解でいました。もちろん人によるとは思いますが、少なくともプレーンテキストよりは読みやすい。だから、Markdownで十分ではないかと思っていました。

しかし、最近の生成AIの出力を見ると、もう少し上の可読性が求められているようにも感じます。

たとえば、Geminiが出力するインタラクティブな可視表示や、ClaudeのArtifactsはとても見やすいです。情報を「読む」というより、「見て判断する」ための形になっています。

特許文書でも同じことが言えます。
図面なしで読むのがしんどい明細書は多いです。化学系では図面が少ないこともありますが、表は重要です。機械系の明細書では、図面が本体といってもよい場合すらあります。

つまり、LLMが処理しやすい形式と、人間が理解しやすい形式は、必ずしも一致しないのではないかと思ったのです。

拒絶理由コメントをHTMLで構造化してみる

そこで、最近話題になっていた「レスポンスをHTMLとして構造化する」という考え方を使い、ChatGPTに特許業務で使えそうなアイデアを出してもらいました。

プロンプトとしては、たとえば次のようなものです。

すると、いろいろなアイデアが出てきました。
正直、悪くありません。
出願系の業務はセンシティブなので、すぐに実行するには慎重になる必要があります。ただ、中間処理については生成AIの活用が少しずつ容認されてきている印象もあります。公開情報を整理する用途であれば、比較的取り入れやすいのではないかと思います。

そこで、出てきたアイデア自体はMarkdownとして保存しつつ、さらに次のように頼んでみました。

実際には、私の癖で少し丁寧に、

のようにお願いしてしまいます。

そして出てきたHTMLを見て、少し驚きました。

これは、人間が読むための媒体としてはかなり強いのではないか、と。

カード、表、色分け、セクション分けなどをうまく使えば、単なる文章よりもずっと判断しやすくなります。拒絶理由コメントのように、複数の引例、請求項、相違点、対応方針を並べて確認する場面では、HTMLの見やすさがかなり効いてきます。

「人間が判断する資料」としてのHTML

ここで重要なのは、HTMLを「LLMに考えさせるための形式」として見るのではなく、「人間が判断するための表示形式」として見ることです。

拒絶理由通知に対する対応方針を検討する場合、必要な情報は多岐にわたります。

本願発明の要点、拒絶理由の概要、引用文献の記載、請求項ごとの対応関係、相違点、補正案、反論案、リスク、次のアクション。

これらをMarkdownで並べても、もちろん読めます。
ただ、長くなると視線の移動が増えますし、どこが重要なのかも埋もれやすくなります。

一方でHTMLなら、見出し、カード、表、色、余白、折りたたみ表示などを使って、情報を判断しやすい形に整理できます。

Word、Excel、PowerPoint、PDFの代わりに、案件確認用のHTMLビューを作る。
これはかなり現実的な使い方ではないかと思います。

しかもHTMLは軽いです。
ブラウザで開けますし、共有もしやすい。事務所内でデザインを統一するなら、CSSを事務所カラーに合わせることもできます。

対外的に出す資料ではなく、まずは内部検討用の「見やすい画面」として使うだけでも、かなり効果がありそうです。

MarkdownとHTMLは競合しない

とはいえ、だからといってMarkdownが不要になるわけではありません。

むしろ、LLMに考えさせるならMarkdownの方が向いている場面は多いと思います。

Markdownは軽く、意味情報に対するノイズが少なく、再編集もしやすい。Obsidianで蓄積するにも向いています。LLMに再分析させる場合も、HTMLより扱いやすい場面が多いでしょう。

一方で、HTMLには弱点もあります。

タグや装飾情報が増えるため、トークン数は増えます。意味情報と装飾情報が混ざります。再編集もMarkdownより重くなりがちです。また、LLMにとっては視覚的な見やすさがそのまま意味を持つわけではありません。

そのため、HTMLをすべての原本にするのは少し違う気がします。

私の現時点での感覚は、こうです。

LLMに考えさせるならMarkdown。
人間に判断させるならHTML。
両方に使うなら、Markdownをデータ本体、HTMLを表示レイヤーにする。

理想は「二層構造」かもしれない

もう少し整理すると、理想形は二層構造です。

第1層は、LLM用の軽量データ。
Markdown、YAML、JSONなどで、意味情報をきれいに持たせます。

第2層は、人間用のHTMLビュー。
第1層のデータをもとに、カード、表、色分け、フィルタなどを備えたHTMLを生成します。

この形にすると、次のような利点があります。

LLMは軽量な構造データを扱える。
人間はHTMLで見やすく判断できる。
HTMLが壊れても元データが残る。
別案件にも再利用しやすい。
後からLLMに再分析させやすい。

かなり強い構成です。

ただし、すべての業務でここまでやる必要があるかというと、それは別問題です。
ちょっとした検討ならMarkdownだけで十分ですし、毎回二層構造を作るのは重すぎるかもしれません。

それでも、拒絶理由対応のように情報量が多く、判断も必要で、あとから見返す価値があるものについては、この構成を試す価値がありそうです。

OA対応方針HTMLは自動化できるか

HTML出力の最後に「OA対応方針HTMLを作るプロンプト」のようなものがありました。

これを使うとさらに面白いことができそうです。

たとえば、エージェントのsandboxのInboxに、本願、OA、引例などを適切な形式で入れる。
エージェントがそれらを処理する。
必要なフォルダ構造、プロンプト、コンテキスト、ハーネスを整える。
最後にHTMLとしてまとめる。

これだけで、かなり実務的な検討資料が作れるかもしれません。

もちろん、実際に運用するには注意点があります。
出願情報や未公開情報の扱い、クライアント情報、生成AIの利用ルール、出力内容の検証など、考えるべきことは多いです。

ただ、公開情報の整理や、研修用のサンプル案件であれば試しやすいはずです。
少なくとも、今度の研修のネタにはなりそうです。

まとめ：思考はMarkdown、判断はHTML

現時点での結論は、かなりシンプルです。

LLMの思考にはMarkdown。
人間の理解と判断にはHTML。
実務運用では、MarkdownやJSONを原本にして、HTMLをビューとして生成するのが強い。

Markdownは、これからも私の業務の中心にあり続けると思います。
Obsidianで情報を蓄積し、プロンプトを管理し、LLMに処理させるための媒体としては、やはりMarkdownが便利です。

一方で、人間が判断するための資料としては、HTMLをもっと使ってもいいのではないかと思い始めています。

拒絶理由コメント、OA対応方針、引例比較、請求項チャート、研修資料。
こうしたものは、HTML化することでかなり見やすくなる可能性があります。

MarkdownとHTMLは、どちらか一方を選ぶものではありません。

考えるためのMarkdown。
見るためのHTML。

この使い分けを意識すると、生成AIを使った特許業務の設計は、もう一段階進められるのではないかと思います。

前川知的財産事務所
弁理士
砥綿洋佑