AI時代のオープンソース貢献：HwpLibSharpポーティングプロジェクトから学んだこと

Microsoft MVPとして活動して17年になります。その間、.NETコミュニティで最も多く受けた質問の一つが「C#でHWPファイルをどう扱えばいいですか？」でした。韓国のハンコム社の公式ライブラリはWindowsとCOMベースであり、クロスプラットフォーム.NET環境では事実上、解決策がありませんでした。

そんな中、@neolord0さんのhwplibを見つけました。Javaで書かれた、純粋にHWPファイルフォーマットをパースするオープンソースライブラリです。「これを.NETに移植すればコミュニティに貢献できる」とすぐに思いましたが、簡単なことではありませんでした。コードベースが膨大な上に、今も継続的にアップデートされていたからです。

2026年、AIコーディングアシスタントと共にこの作業を始めました。

一回限りのポーティングではなく「同期化」

一見、HWPは頻繁に変わるフォーマットではないため、一度ポーティングすれば手を加える必要はないと思いがちです。しかし、あらゆる技術は変化し続けます。元のプロジェクトが今も活発にメンテナンスされているのはもちろん、.NET技術自体も進化しているため、一回限りの作業では不十分です。

従来のフォーク（fork）は、時間が経つほど原本との距離が開きます。最終的に「自分たちのバージョン」と「オリジナル」がそれぞれ別の道を歩むことになります。当然の流れですが、それでも別のアプローチを選びました。単なるフォークではなく、原本と共に生き続ける「移植された実装（Ported Implementation）」 というアイデンティティを明確にしたのです。

元プロジェクト: hwplib (Java)
       ↓ 定期的な同期
ポーティングプロジェクト: HwpLibSharp (C#)
       ↓ .NET特化の改善
エコシステム拡張

そのため、READMEにもこう記載しました。

「本プロジェクトの意思決定および判断の優先権は、オリジナルプロジェクトの作者である @neolord0 氏の意思を優先します。」

これは礼儀のために書いた文章ではありません。2つのプロジェクトが長期的に共存するためには、誰が方向性を決めるのかを最初から明確にする必要があると判断したからです。

AIと共に行ったポーティング作業

正直に言えば、AIコーディングアシスタントなしでこのプロジェクトを進めていたら、初期ポーティングだけで6ヶ月以上かかっていたでしょう。アップストリーム同期は到底手が出せず、結局放置された「もう一つのレガシー」になっていたはずです。

しかし、AIと一緒に作業することで、まったく異なるアプローチが可能になりました。

AIがうまくできたこと

構文変換はほぼ完璧でした。Javaのgetter/setterをC#プロパティに変換し、命名規則をC#コンベンションに合わせ、nullチェックをNullable参照型に変換する作業は、ほとんど自動化できました。

ライブラリのマッピングでもAIの助けは大きかったです。Apache POIをOpenMcdfに置き換える際、「Javaでこのライブラリが果たす役割を.NETでは何で代替できるか」を素早く見つけてくれました。元プロジェクトがアップデートされるたびに変更点を追跡してC#バージョンに反映する反復作業でも、ヒューマンエラーを大幅に削減してくれました。

Upstream変更の自動追跡

この過程で特に効果的だったのは、AIエージェントを活用したupstream変更の自動追跡方式でした。元のhwplibプロジェクトに新しいコミットが入るたびに、AIエージェントが変更されたJavaソースファイルと対応するC#ソースファイルを比較分析し、実装上の差異を検出します。

この同期を体系的に管理するために、ポーティングされたすべてのC#ソースファイルの先頭に、元のJavaファイルとの対応関係を明示するヒントヘッダーを残しました。

// =====================================================================
// Java Original: kr/dogfoot/hwplib/util/compressors/Compressor.java
// Repository: https://github.com/neolord0/hwplib
// =====================================================================

このヘッダーがあれば、AIエージェントは「このC#ファイルの元はJava側のどのファイルか」を即座に把握できます。upstreamでCompressor.javaが変更されると、AIが対応するC#ファイルを見つけてdiffを分析し、不足している変更点や実装上の差異をレポートしてくれます。人間が数百のファイルを一つずつ照合する必要なく、AIが「この部分が原本と異なっているので確認が必要です」と教えてくれる方式です。

実際にこの方式を導入した後、upstream同期にかかる時間が従来比80%以上短縮されました。以前は変更ログを読んで関連ファイルを一つずつ探しながら手動で反映していたのが、今ではAIが変更リストと影響範囲を自動的に整理してくれるようになりました。

AIができなかったこと

一方、HWPファイルのSection-Paragraph-Control構造、各コントロールの意味、韓国語ワープロ文書ならではの特性といったドメイン知識は、完全に自分の役割でした。AIがもっともらしく提案したコードが実際に正しいかどうかの検証は、やはり人間がやるべき仕事です。

戦略的な意思決定も同様でした。Native AOTをサポートするか、Blazor WebAssemblyでどう動作させるか、どの.NETバージョンまでサポートするか。こうした判断には.NETエコシステム全般への理解と、実際のユーザー環境に対する感覚が必要です。ライセンス文言、原作者との関係設定、韓国の開発者コミュニティの文脈を反映する作業も、AIが下書きを作り、自分が仕上げるという方法で進めました。

.NETエコシステムに合わせた再設計

単にコードを移すだけで終わりではありませんでした。.NET開発者が自然に使えるよう、原本プロジェクトの哲学と意図を損なわない範囲でAPIを整える作業も必要でした。

// Blazor WebAssemblyサポート（ファイルシステムなしでストリームから）
var hwpFile = HWPReader.FromStream(memoryStream);

// Native AOT互換、URLからの非同期ロード
var hwpFile = await HWPReader.FromUrlAsync(url);

これらの機能はオリジナルのJavaバージョンには存在しません。しかし.NET開発者なら当然期待するものです。おかげで、Azure FunctionsでHWPを処理したり、Blazorでブラウザ上にHWPをレンダリングすることも可能になりました。

面白いこともありました。Java開発者がHwpLibSharpのREADMEを見てアイデアを持ち帰り、オリジナルプロジェクトのドキュメント化に貢献したのです。.NETバージョンの使用例がJavaユーザーにも役立ったということです。

特にRAG（Retrieval-Augmented Generation）用途でHWPからテキストを抽出する例は、両コミュニティで活発に議論されました。AIがHWP文書を理解するにはどのような形式のテキストを抽出すべきか——この問いはプログラミング言語の境界を超えるものです。

コードを移す人からキュレーターへ

このプロジェクトを進める中で、自分の役割そのものが変化したことを感じました。最初はコードを翻訳する人でしたが、今は2つのエコシステムを繋ぐキュレーターに近い存在です。元プロジェクトの変更を監視し、.NETコミュニティの要望を収集し、2つの世界の慣行と哲学を調整し、持続可能な同期プロセスを設計する仕事です。

現在、HwpLibSharpは.NET Framework 4.7.2から.NET 8までをサポートし、実際に政府・公共機関のプロジェクトでも使用されています。しかし、サポート範囲よりも意味があるのは、以前は不可能だったシナリオが実現したことです。

• Azure Functionsでサーバーレス方式のHWP処理
• Blazor WASMによるブラウザ内HWPレンダリング
• .NET MAUIモバイルアプリでのHWP読み取り
• AI/LLMのRAGパイプラインへのHWP文書統合

このプロジェクトから学んだこと

AIは経験の増幅器である。 17年間積み重ねた.NETの経験が、AIを通じて何倍もの生産性として現れました。その経験がなければ、AIに正しい方向を示すこともできなかったでしょう。AIは経験を代替するのではなく、増幅させるものです。

自動化の境界を知るべきである。 構文変換、パターン適用、反復テストは自動化する。しかし、戦略的な意思決定やドメイン検証、コミュニティとの関係は人間が直接担うべきです。この境界を混同すると、素早く間違った方向に進む可能性があります。

フォーク（Fork）ではなく「Living Port」という概念。 原本と競争せず、共生しながらそれぞれのエコシステムに価値を加える構造です。オープンソース貢献の新しい形になり得ると考えています。

貢献はコード以上のものである。 READMEの一行、サンプルの一つが、誰かの3日分の無駄な作業を節約します。韓国のように独自の文書フォーマットを扱う環境では、その効果はさらに大きいです。

おわりに

.NETが好きでコミュニティを作り、17年間維持してきました。その過程で築いた経験とネットワークが、AIというツールと出会い、新しい形の価値を生み出しています。

HwpLibSharpプロジェクトは、技術的専門性、コミュニティへの貢献、AI時代の開発方法論の実験が融合した作業でした。AIが時間を稼いでくれ、その時間でより多くの人に貢献できました。おそらくこれが、現在のオープンソース貢献の在り方なのかもしれません。

プロジェクトリンク：

• GitHub: rkttu/HwpLibSharp
• NuGet: HwpLibSharp
• 元プロジェクト: neolord0/hwplib

プロジェクトへのフィードバックや貢献はいつでも歓迎します。GitHub Issueからお気軽にどうぞ。