Pandocベースの Hancom Hangul 変換ツール - md、html、docx を hwpx に変換するオープンソースツールの紹介
(github.com/msjang)政府系研究機関で働いて9年目、HWP 文書作業の不便さを解消したくて開発しました。
開発の背景
- 2018年: Python 初心者だった頃、正規表現ベースの HML/HWPML 変換器を試作 - https://github.com/msjang/md2hml
- 2025年1月: hwpfy を開発
- リアルタイム共同編集ウィキをベースに、20人余りの週間業務報告を取りまとめ
- ウィキ → DOCX エクスポート → 公務員書式を適用した DOCX に変換(hwpfy) → Hangul アプリで開いて HWPX として保存 → 所内の上位部署に HWPX で共有
- 2025年12月: pypandoc-hwpx
- もう十分に実力が身についたと思い、腰を据えて時間を投資して開発しました。
開発方法
- DOCX を希望する書式で作成し、HWPX として保存しました。
- 生成された DOCX と HWPX を unzip して XML を見ながら不要な属性を削り、整えました。そして Word と Hangul アプリで問題なく開けるかも確認しました。
- md、html、docx、hwpx フォーマットを比較する文書を作成しました。 - https://github.com/msjang/pypandoc-hwpx/…
- もともとは上記の
format_comparison.mdを見せて LLM にコーディングさせようと思っていましたが、すでに正解となる HWPX がある状況だと気づきました。 - Antigravity(Gemini Pro 3) と何度もフィードバックを重ねながら作りました。望む形式になかなかならなかったため、XML を細かく確認しながらフィードバックを与えました。フォーマット比較文書を直接言及はしませんでしたが、内容を把握していたことがレビューに大いに役立ちました。
今後やりたいこと
Pypandoc から Python を取り除き、Haskell で実装して Pandoc に HWPX writer をコントリビュートしたいです.
7件のコメント
https://velog.io/@wjsdj2009/…
こういう記事があるのですが、一度政治家の方々に連絡してみては…？
ハンコムが先に開発しておくべきだったと思えるアイテムですね……ハンコムに海外進出する意思があるならですが。
Haskell への貢献を応援します！
もともとは1〜2か月かけてゆっくり作るつもりでしたが、昨日 https://youtu.be/8cSqPRsM_Yg のニュースが出てしまったので、急いで作りました。
すばらしいですね。
ただ、差し出がましいようですが、大統領が望んでいる変換の方向は
hwp* -> .md, docs, pdf plain text ...ではないでしょうか？ このプロジェクトは逆方向の変換もサポートしているのでしょうか？HWP や HWPX をパースするライブラリは、昔から数多くありました。Java ベースではこれが有名です。
https://github.com/neolord0/hwplib
https://github.com/neolord0/hwpxlib
Python でハンコム win32 API をラップしたものもあります。初期の HWP 自動化講座に登場するやつですね。バックエンドで Windows 用 HWP アプリを制御するものです。
https://pypi.org/project/pyhwpx/
Python で別途プログラムなしに HWPX を standalone で扱うものとしては、これがあります。読み込みや置換もでき、段落や表を追加することもできます。 https://github.com/airmang/python-hwpx
でも考えてみると、私たちの多くは LLM アプリとやり取りしています。ChatGPT、Claude、Gemini に Web ブラウザでアクセスしてチャットしながらやり取りします。OpenWebUI でローカルモデルを動かす場合でも、Web ブラウザからアクセスして利用します。スマートフォンの ChatGPT アプリの音声モードでやり取りした結果も、Web ブラウザでチャットログを確認できます。そして LLM の output は、コピー ボタンを押してメモ帳に貼り付けてみると markdown であることが分かります。
LLM の markdown や html は出てくるのに、これをそのまま hwpx に変換して保存するライブラリはあるのか？ ありません。
GEMINI Pro で特許アイデアを考えていると、「文書にしましょうか」と聞かれます。そしてボタンを押すと、Google Docs の文書として特許明細書のドラフトができあがっています。単に Markdown を変換して文書にしただけなのに、かなり見栄えがします。
韓国は、好むと好まざるとにかかわらず、HWP を業務推進とコミュニケーションの標準としてきました。そして私たちの業務フロー(workflow)の中で、HWP 生成はある意味当然のことです。
ChatGPT の音声モードで会議内容を一通り聞いたあと、「要約して議事録にして参加者にメールで送って」「ブレインストーミングした内容を特許明細書のドラフトにして」などを頼むとき、その出力物は HWP であるべきだという話です。
これまでは、LLM の結果を人が Web ブラウザから Hancom アプリへコピーし、書式を整え、文字幅や字間などを丹念に調整して組版する工程を経てきました。
GEMINI が Google Docs を作ってくれる時代に、韓国の税金を投入した LLM モデルやサービスは、HWPX も人の介入なしに作ってくれるべきではないでしょうか。
私は業務自動化のためにこうしたニーズを持っており、そのためにこれを作りました.
余談。
HWP自体は、パースしてテキストに変換するだけなら簡単です。Googleが韓国語の文書をインデックス化するために2000年代からすでに作成して独自に適用していましたし、上で言及したオープンソース群でも十分に可能です。
HTMLのh1〜h6に対応するアウトラインレベル1〜6のスタイルを適用すれば、文書の階層構造（hierarchy）も保持したまま文書を作成できます。
ただしHWPはエディタの機能が多すぎるうえ、利用者が紙の出力物を見栄えよくすることに注力して書式を適用するため、アウトラインレベルを適用しようという努力がされてきませんでした。
それを端的に示しているのが、研究所で300ページのHWP文書をPDFとして保存すると、しおり情報が1つも生成されないという点です。だから電子文書なのに、スクロールしながら探さなければなりません。ものすごく不便です。しかも容量の大きいPDFは、どれだけ高性能なコンピューターでも、ざっと目を通すために高速スクロールすると非常にもたつきます。
機関評価のときにこんなことはできないので、審査員の人数分だけ数百ページの報告書を山のように印刷して積み上げ、機関評価を行います。そして評価が終わるとすぐに捨てます。
海外の報告書では、400ページのPDF報告書を受け取ると目次だけで16ページあり、目次にはリンクが付いていて、クリックすると該当ページへ移動します。アウトライン表示をすると、しおりが非常に細かく分かれていてよく整備されています。これは、ツール上で人が意識しなくても簡単に入力され、自動生成されたものだということを意味します。
ともかく話を戻すと、現在大多数が「アレアハングル」を使う慣習によって作られたHWPからはテキストは取得できますが、文書の階層情報を得るのは難しいです。
しかし、LLMで人の介入なしにHWPを生成すれば、こうした点を考慮して自動的に作成できます。