AI

始まりは単純な好奇心から 「HWPファイルを.NETで直接扱えたらいいのに…」 こんな考えをした.NET開発者は私だけではないでしょう。HWPファイルは韓国で公共機関を中心に今でも広く使われている文書形式ですが、.NETエコシステムではこれを適切に扱えるオープンソースライブラリがありませんでした。 これまで.NETでHWPファイルを扱うには、Windows OS限定でアレアハングルをインストールすると付属するHWP ActiveXコントロールのCOMタイプライブラリを呼び出して制御する程度しかありませんでしたが、残念ながらこれさえもサポートが終了し、今は道が閉ざされた状態です。 そんな中、Javaで書かれたhwplibを発見しました。neolord0さんが継続的にメンテナンスしてきたこのライブラリは、HWPファイルの読み書きを完成度高くサポートしていました。 以前なら、このようなライブラリを移植することは、強い使命感と目的意識がなければなかなか手を出せる作業ではありませんでした。しかし、高性能なAIモデルが多く登場し、今なら新しい挑戦ができるのではないかという好奇心がありました。 こうして始まった3週間の旅を共有します。 数字で見るプロジェクト 本格的な話の前に、Javaバージョンのプロジェクトの規模を数字でまとめてみましょう。 項目 内容 元プロジェクト neolord0/hwplib (Java) 移植プロジェクト rkttu/libhwpsharp (C#) ターゲットフレームワーク .NET Standard 2.0, .NET Framework 4.7.2, .NET 8 総コミット数 54個 開発期間 2025-12-16 ~ 2026-01-08（約3週間） 初期移植コード 641ファイル、50,010行 641ファイル、5万行。正直、最初にこの数字を見たときは「これは可能なのか？」という疑問が湧きました。 初日：AIと共に行った大規模コード変換 5万行を1日で？ 2025年12月16日、プロジェクトを開始しました。通常の状況であれば、5万行のJavaコードをC#に変換するには数ヶ月かかったでしょう。しかし、AIコーディングアシスタントがゲームチェンジャーでした。 AIにJavaファイルを渡し、C#に変換してもらいました。もちろん、機械的な変換だけでは不十分でした。JavaとC#は似ているように見えますが、微妙な違いが多いからです。 // Java public byte getValue() { return value; } public void setValue(byte value) { this.value = value; } // C# public byte Value { get; set; } このようなパターン変換はAIがうまく処理してくれました。しかし、本当の問題は別にありました。 最大の難関：Apache POIからOpenMcdfへ OLE2複合ドキュメントの沼 HWPファイルはMicrosoftのOLE2複合ドキュメント形式（Compound File Binary Format）に基づいています。簡単に言えば、1つのファイルの中に複数の「ストリーム」がフォルダ構造のように格納されている形式です。 JavaではApache POIライブラリがこの形式を扱いますが、.NETには直接対応するものがありません。代わりにOpenMcdfというライブラリを使う必要がありましたが、残念ながらApache POIとはAPIが完全に異なります。 ...

サービス開発をしている同僚たちと話をしていると、AI導入について漠然とした負担感を感じているケースをよく見かけます。その負担感の根源を掘り下げると、大抵は**「学習（Training）」**という用語が生む誤解に起因しています。 「モデルをサービスに組み込むと、ユーザーデータを取り込んでリアルタイムで学習して賢くなるんですか？」 「じゃあ、その学習プロセスを私たちがコントロールできますか？変なことを学んだらどうしますか？」 もしこのような悩みをお持ちでしたら、少し心配を置いても大丈夫です。今日はその誤解を開発者の言葉で解説します。 「学習」はビルドタイム、「推論」はランタイム 最初に正すべきことは、私たちがサービスにデプロイするAIモデルは、ほとんどの場合「凍結された（Frozen）」状態であるという点です。 開発用語で例えると次のようになります。 概念 AI用語 開発用語の比喩 説明 モデルを作る 学習（Training） ビルドタイム（Build Time） 膨大なリソースと時間が必要 モデルを使う 推論（Inference） ランタイム（Runtime） リクエストを受けて結果を返す 私たちがサービスを運用するとき、実行中のバイナリコードが自らコードを修正して進化することはありません。AIも同様です。 モデルはデプロイされた瞬間、もはや「学ぶ学生」ではなく、**「指示通りに働く労働者」**になります。私たちが心配すべき領域は学習ではなく、この労働者がうまく仕事ができるよう環境を整えることです。 図書館の比喩でAI構造を理解する では、最新情報はどのように反映され、AIはどのような役割を果たすのでしょうか？私はこの構造を**「図書館」**に例えることがよくあります。 構成要素 図書館の比喩 説明 AIモデル（LLM） 司書 言語能力と推論能力を持つ存在 RAG / DB 書庫 サービスデータと最新情報が保存される空間 プロンプト 業務指示書 司書に仕事を任せるときに渡すガイドライン サービス開発者である私たちが毎日やっていることは、**「図書館に新刊を補充すること（DBアップデート）」**です。司書（AI）は私たちが補充した本を必要なときに取り出し（Retrieve）、内容を読んで組み合わせてユーザーに提供する（Inference）だけです。 多くの方が恐れている**「学習（Fine-tuning）」は、「司書を大学院に送って再教育すること」**に相当します。司書が基本的な読解力が不足している場合や、一般的な常識では理解できない特殊なドメインを扱う必要がある場合にのみ必要なエッジケースです。 ほとんどのビジネス問題は、司書を再教育（学習）させることではなく、以下の3つで解決できます： 優秀な司書を採用する - 良いベースモデルを選択 良い業務マニュアル - よく設計されたプロンプト 整理された書庫 - 構造化されたRAG/DB AIは「意味処理アクセラレータ」である このように構造を把握すると、AIはもはや恐ろしい未知の存在ではありません。単に私たちのシステムアーキテクチャに組み込むべき一つの**「部品」**に過ぎません。 コンピュータの歴史は「処理の高速化」でした。 ハードウェア 高速化対象 CPU 計算とロジック（if-else）処理 GPU グラフィックスとピクセル処理 AI（LLM） 意味（Semantics）と文脈（Context）処理 私たちはこれまでif (text.contains("りんご"))のようなコードで人間の言語を機械的に処理するのに苦労してきました。今では、その「意味処理」を専門に担当する高性能アクセラレータ（AI）が登場したのです。 おわりに AI時代だからといって、開発者がAIモデルを直接作ったり数式を理解したりしなければならないという強迫観念を持つ必要はありません。 MySQLの内部エンジンのソースコードを知らなくても優れたバックエンドサーバーを構築できるように、AIという**「優秀な司書」を私たちのサービスのどのデスクに座らせ、どのような権限を与えるかを設計するアーキテクチャリング能力**は今でも有効であり、さらに重要になっています。 AIに過度な意味を付与しないでください。それは自ら考えて反乱を起こす人工知能ではなく、私たちが入力したデータを確率的に最もそれらしく処理して返す**「関数（Function）」であり「ツール（Tool）」**です。 ツールは恐れるべき対象ではなく、手に馴染ませてうまく活用すべき対象です。