  |
コーディングエージェント(というかLLM)が生成したMarkdownに `**` などの強調表示がのこりがちであるのはよく知られていると思う。
背景事情としてはこちらのスライド: https://speakerdeck.com/kwahiro/nazeqiang-diao-biao-shi-dekizu-star-star-gabiao-shi-sarerunoka-perldeshi-matutamarkdownnoli-shi-tori-ben-yu-wen-shu-niokeruke-ti が大変に参考になる。
また、LLMにMermaidを含んだMarkdownを書かせることはよく行なわれていると思うが、これも結構invalidなMermaidを吐いてくることがある。モデル側の進歩でかなり失敗は減っているところではあるが、GPT-5.4とかOpus 4.6とかの最新モデルでも約物と強調の問題だとか、Mermaidだとかで失敗することはある。
ということで、ハーネスつけて制御すればいいのではないかと思っていくつかのツールをつくった。
これをどう使うかというと、たとえばClaude Codeをつかっているならば、 CLAUDE.md に以下のようにでも書く
# Markdown について ## 全般的な注意事項 - 日本語を含むMarkdownを書いた場合 `cmark-cjk-lint pathtomarkdown.md` コマンドを実行して、Markdownの構文エラーがないか確認してください。エラーがあれば修正してください。 ## Mermaid を含む場合 - `mdmermaidchecker pathtomarkdown.md` コマンドを実行することで、Markdown 内の Mermaid 図を検証することができます。エラーがあれば修正してください。
こんなふうにしておけば、Claude Codeが勝手にvalidなMarkdownになるまで修正してくれる。
ただし、「Markdownに壊れている箇所がないか」を人間が目で読みながら確認して手で修正する作業は絶対に文書の質を上げると思うので、こういうものを使うのは結構トレードオフにはなる。でもあんま手間はかけられないけど壊れたMarkdownが出来ると困るとか、完全に自動化されたフローのなかに組み込みたいとかだと、こういうターゲットを絞ったLinterのようなものを作っておくのは一つの手だと思う。
既存のテキストLinterみたいなものにこういう機能を入れてもらうように頑張るみたいな方向性もありえるかもしれないが、車輪の再開発を一切恐れず自分の必要なものを最小限だけ用意するというのも現代ではありえる考え方だと思う。
6
