CodeWF ツールボックス：Avalonia + Prism で作られた開発者向けツールキット

本日の記事では、私自身が開発している CodeWF Toolbox（CodeWF 工具箱） についてご紹介します。

私のことをご存知の方からは「站长（サイトマスター）」と呼ばれることが多いですが、それは私が運営するウェブサイト「CodeWF」があるからです。このツールボックスも、コードを書いたり、サイトを保守したり、資料を整理したり、問題を調査する際に繰り返し直面したニーズをもとに作成しました。単なるボタンがいくつか置かれた Avalonia デモではなく、すでに 100 以上のツールエントリを備えたローカルデスクトップツールボックスです。

プロジェクトは C# + Avalonia + Prism + Semi.Avalonia + Ursa で構成されており、目的はシンプルです。開発者が日常的に繰り返し使う変換、エンコード/デコード、フォーマット、検証、生成、検索といったツールを、一つのローカルデスクトップアプリケーションに集約することです。

今回は漠然とした「クロスプラットフォーム UI 能力」ではなく、CodeWF Toolbox が実際に何ができるのかを軸に説明します。スクリーンショットも新しく撮り直し、メインウィンドウのサイズを少し縮小し、ホームページにはよく使われるツールとおすすめツールのエントリを追加しました。全体は私の好みである デザートテーマ で表示しています。

まずは機能紹介の GIF をご覧ください。

ホームページ：もはや空白の歓迎ページではない

新しいホームページは、今回重点的に調整したポイントの一つです。以前は単なる歓迎ページのようなものでしたが、現在はツールボックスのエントリとしてより適したものになっています。

ホームページ上部には 3 つのコア情報が表示されます：

現在利用可能なツール数：117
現在の機能モジュール数：12
現在の実行プラットフォーム：Windows x64

下部には「よく使うツールとおすすめツール」が追加されました。ユーザーがすでにツールを使用したことがある場合は、よく使うツールが優先表示され、8 個に満たない場合はおすすめツールで補完されます。初回起動時にも空っぽに見えず、タイムスタンプ、Base64、GUID、QR コード、ハッシュ、ログビューアといった高頻度なエントリがすぐに目に入ります。

この調整は小さなものですが、ツールボックスの体験にとっては重要です。デスクトップツールボックスを作る際に、私が明確に考えていたのは、「ホームページは宣伝ページであるべきではなく、ユーザーが開いたらすぐに作業を始められるようにすべき」ということです。

変換ツール：開発者が毎日使う小さな機能

変換ツールは、CodeWF Toolbox の中で最も基本的で、最もよく使われる機能の一つです。

現在の変換モジュールには、以下の独立したページとデータ駆動型ツールが含まれています：

タイムスタンプ変換：Unix タイムスタンプとローカル時刻の相互変換、秒とミリ秒に対応。
Base64 エンコード/デコード：UTF-8 テキストのエンコード、デコード、入れ替え、コピー。
GUID ジェネレーター：GUID を一括生成し、大文字小文字や形式を制御。
YAML to JSON、JSON to YAML。
画像を ICO アイコンに変換。
車移動用 QR コードジェネレーター。
Base64 ファイル変換。
Base64 文字列エンコード/デコード。
大文字小文字変換。
カラーピッカー。
日時変換。
整数進数変換。
JSON/TOML/XML/YAML 相互変換。
リスト変換、Markdown to HTML、ローマ数字変換など。

例えば Base64 エンコード/デコードページでは、テキストを入力するとすぐにエンコード結果が得られます。

こうした機能は非常に小さなものですが、開発者が一日の中で最も繰り返しウェブ検索してしまうものです。ローカルツールボックスにすることで、応答が速く、オフラインで使用でき、広告がなく、一時的なテキストを外部サイトに貼り付ける必要がなくなるという明確な利点があります。

開発ツール：フォーマット、解析、差分、コマンド補助

開発モジュールは、「コード記述中の補助ツール」に重点を置いています。これらのツールの多くは私自身が日常的に使用するものであり、ツールボックスに入れる際の優先度も高くなっています。

現在の開発系ツールは幅広い範囲をカバーしています：

JSON フォーマット、JSON 圧縮、JSON パス抽出、JSON to CSV。
YAML フォーマット。
XML フォーマット、XML XPath テスト。
SQL 美化とフォーマット。
CSV to JSON、CSV to Markdown 表。
INI to JSON、.env to JSON。
HTTP ヘッダー解析。
Data URL 解析。
Docker イメージタグ解析。
Docker Run to docker-compose。
Chmod 計算機。
Crontab 式生成。
Regex Tester、Regex cheatsheet、正規表現置換。
Git チートシート。
Hex dump ビューア。
SemVer チェックと比較。
Markdown 表ジェネレーター。
NanoID、UUID v5、ランダムポートなどの生成系ツール。

上の図にある JSON フォーマットページは典型的な例です。左側に元の JSON を入力すると、右側にフォーマット結果が出力され、キー名のソートやインデントのスペース数も制御できます。

こうしたツールはデータ駆動型フォームに抽象化するのに適しています。入力フィールド、出力フィールド、実行関数、自動実行設定をすべて ToolSpec で記述でき、ツールごとに重複した XAML を書く必要がありません。私にとってこれは非常に重要です。ツールの数が増えれば増えるほど、後々のメンテナンスコストが実際の問題になるからです。

セキュリティツール：ハッシュ、HMAC、鍵、パスワード関連

セキュリティモジュールには、開発中に一時的な計算や生成が必要になるセキュリティ関連の機能がまとめられています。

現在含まれている機能は以下のとおりです：

Bcrypt ハッシュと比較。
BIP39 ニーモニックフレーズ/シード生成。
AES、TripleDES テキスト暗号化/復号。
ハッシュ（テキスト）：MD5、SHA1、SHA2、SHA3、RIPEMD160。
HMAC ジェネレーター。
パスワード強度分析。
PDF 署名確認。
RSA 鍵ペア生成。
トークンジェネレーター。
ULID ジェネレーター。
UUID v4 ジェネレーター。

スクリーンショットはハッシュツールです。CodeWF Toolbox と入力すると、ツールが直接ハッシュ値を生成します。同様の機能はコマンドラインでも実行できますが、デスクトップツールの方が一時的な検証、コピー、比較に適しています。

Web ツール：HTTP、JWT、URL、MIME、UA をすべて処理

Web モジュールは主にフロントエンド/バックエンドの連携、API 調査、Web メタデータ処理を対象としています。サイト管理や API 作成時に、こうした小さなツールを頻繁に開くことになります。

現在のツールは以下のとおりです：

Basic Auth ヘッダー生成。
現在のデバイス情報表示。
HTML エンティティのエスケープ/アンエスケープ。
HTML WYSIWYG コンテンツ生成。
HTTP ステータスコード照会。
JWT 解析。
Keycode 情報表示。
Open Graph / Twitter Meta タグ生成。
MIME タイプ照会。
OTP ワンタイムパスワード生成と検証。
Outlook SafeLink デコード。
Slugify 文字列。
URL エンコード/デコード。
URL 解析。
User-Agent 解析。
JSON Diff。

これらのツールに共通するのは、入出力構造が比較的標準的であり、統一された ToolFramework で保守するのに非常に適している点です。

メディアツール：QR コード、WiFi QR コード、SVG プレースホルダー

メディアモジュールは現在のところ、動画編集のような「大規模メディアツール」ではなく、開発者が日常的に必要とする小さな生成ツールに重点を置いています。

現在含まれている機能：

QR コードジェネレーター。
WiFi QR コードジェネレーター。
SVG プレースホルダージェネレーター。

QR コードジェネレーターは URL やテキストを入力して QR コードを生成します。この機能がローカルツールボックスにあると、特にローカルアドレスやドキュメントのアドレス、リポジトリのアドレスをスマートフォンで読み取りたい時に便利です。

ネットワークツール：IP、CIDR、MAC アドレス

ネットワークモジュールは現在、IP アドレスや MAC アドレスなどの基本的なツールをカバーしています：

IPv4 アドレス変換：10 進数、2 進数、16 進数、IPv6 mapped などの形式。
IPv4 範囲展開：開始/終了 IP から CIDR 範囲へ。
IPv4 サブネット計算機。
IPv6 ULA ジェネレーター。
MAC アドレスジェネレーター。
MAC アドレスベンダー照会。

これらのツールは、バックエンド、運用、ネットワーク調査、ローカル開発環境の設定などに実用的です。私は散発的でありながらよく使われる照会や変換を、一時的な検索に頼らなくて済むようにするために、CodeWF Toolbox に組み込みました。

数学、計量、テキスト、データツール

CodeWF Toolbox はエンコード変換だけではなく、小さな計算やテキスト処理ツールも含んでいます。

数学系：

ETA 計算機。
数式計算機。
パーセンテージ計算機。

計量系：

Benchmark builder。
Chronometer タイマー。
温度変換器。

テキスト系：

ASCII Art テキストジェネレーター。
Emoji ピッカー。
Lorem ipsum ジェネレーター。
Numeronym ジェネレーター。
文字列難読化器。
テキスト差分。
テキスト統計。

データ系：

IBAN チェックと解析。
電話番号解析とフォーマット。

これらの機能は毎日使うわけではありませんが、「使いたいときにツールを探す」という場面に該当します。せっかくツールボックスを作るなら、こうした低頻度ながら実用的な小さな機能も取り込みたいと考えました。

ログビューア：大きなファイルを一度にメモリに読み込まない

ログビューアは私が特に気に入っているモジュールの一つです。

単にログファイルを ReadAllText() で読み込んでテキストボックスに入れるのではなく、可視ウィンドウに基づいてレンダリングし、大きなログファイルやリアルタイムの tail シナリオ向けに設計されています。画面上では以下が確認できます：

ログを開く。
再読み込み。
末尾にジャンプ。
末尾を追跡。
現在のファイルパス。
可視コンテンツ領域。

このような機能はデスクトップツールにとって非常に価値があります。数百 MB のログをざっと確認したいだけで、IDE を起動したり、普通のテキストエディタがフリーズするのを待ったりしたくないという場面は多いからです。

国際化リソース管理：XML 翻訳ファイルのマージと管理

プロジェクトには CodeWF.Modules.XmlTranslatorManager モジュールもあり、XML 言語リソースの管理を担当しています。

含まれる機能：

XML ファイルのマージ。
XML ファイルの管理。
多言語属性と言語クラスモデル。

このモジュールは、CodeWF Toolbox 自身が自分自身にサービスを提供する好例です。ツールが増えるにつれて、多言語リソース、モジュールメニュー、リソースのマージなどをツール化する必要が生じ、手動で維持していると時間が経つにつれてエラーが発生しやすくなります。

注：現在のバージョンでは多言語ファイルに JSON を使用しています。XML 形式はブランチ i18n-xml で確認できます。

テーマと言語：デザートテーマは確かに見やすい

今回のスクリーンショットでは主にデザートテーマを使用しています。全体的な印象は、明るいテーマよりも個性的でありながら、ダークテーマのように内容を暗くしません。

テーマ切り替えの効果はこの GIF で確認できます：

現在のテーマ一覧：

システムに従う。
ライトモード。
ダークモード。
アクア。
デザート。
トワイライト。
ナイトスカイ。

言語リソース：

簡体字中国語。
繁体字中国語。
English。
日本語。

ここで注目すべき点は、テーマと言語は単に文字列を切り替えるだけではないということです。デスクトップアプリケーションを長期間使い続けるためには、テーマ、コントロールライブラリ、フォント、ウィンドウサイズ、リスト幅、ドロップダウン幅などを総合的に検討する必要があります。例えば、今回はメインウィンドウの起動サイズを大きめから、日常のデスクトップに適した比率に調整し、ホームページのカードもよりコンパクトな 4 列レイアウトに変更しました。

多数のツールをどのように整理しているか

すべての小さなツールに完全なページを書くと、後々のメンテナンスが大変になります。CodeWF Toolbox では現在、大きく分けて 2 つのツール編成方法を採用しています。

1 つ目は、独立したページを持つツールです。

例：

タイムスタンプ変換。
Base64 エンコード/デコード。
GUID ジェネレーター。
画像を ICO に変換。
ログビューア。
XML 翻訳リソース管理。

これらのツールはより具体的なインタラクションや状態を持つため、View と ViewModel を個別に作成する方が適切です。

2 つ目は、データ駆動型のツールです。

例：

JSON フォーマット。
JWT 解析。
ハッシュ（テキスト）。
URL エンコード。
MIME 照会。
MAC アドレス照会。
QR コード生成。
数学計算。
テキスト統計。

これらのツールは入出力パターンがより標準的であり、ToolSpec で記述できます：

public class ToolSpec
{
    public string Id { get; set; }
    public string Category { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public List<ToolField> Fields { get; } = [];
    public List<ToolOutput> Outputs { get; } = [];
    public Func<ToolRunContext, CancellationToken, Task> RunAsync { get; set; }
    public bool AutoRun { get; set; }
}

これにより、新しいツールを追加する際には、多くの場合、次のものだけを追加すれば済みます：

ツール ID。
カテゴリ。
入力フィールド。
出力フィールド。
アルゴリズム関数。
多言語リソース。
アイコン。

UI フォームは再利用でき、ツールのロジックがメインウィンドウを汚染することもありません。これが、CodeWF Toolbox を今後も拡張し続けられる基盤です。

Prism のモジュール化により機能を継続的に追加

プロジェクトのエントリでは、Prism を使用してモジュールを登録しています：

moduleCatalog.AddModule<MainModule>();
moduleCatalog.AddModule<ToolFrameworkModule>();
moduleCatalog.AddModule<ConverterModule>();
moduleCatalog.AddModule<DevelopmentModule>();
moduleCatalog.AddModule<SecurityModule>();
moduleCatalog.AddModule<WebModule>();
moduleCatalog.AddModule<MediaModule>();
moduleCatalog.AddModule<NetworkModule>();
moduleCatalog.AddModule<MathModule>();
moduleCatalog.AddModule<MeasurementModule>();
moduleCatalog.AddModule<TextModule>();
moduleCatalog.AddModule<DataModule>();
moduleCatalog.AddModule<LogViewerModule>();
moduleCatalog.AddModule<XmlTranslatorManagerModule>();

各モジュールは、自身のメニュー項目と View を登録する責任を持ちます。メインプログラムは各ツールページの内部実装を知る必要はなく、以下のことだけを担当します：

アプリケーションの起動。
ログインウィンドウ。
メインウィンドウ。
テーマと言語。
共通サービス。
Prism Region。
モジュールカタログ。
システムトレイと終了動作。

この境界線は重要です。ツールボックスのようなプロジェクトは、書き散らかしやすく、最終的にメインウィンドウに機能の詳細が詰まりがちです。Prism のモジュール化は、少なくとも明確な拡張の方向性を提供し、後でツールを追加してもメインプログラムが乱れないようにしてくれます。

Q：なぜメインプロジェクトでツールモジュールを強参照するのですか？

A： Windows AOT で公開すると、マネージドモジュールの動的ライブラリを正常に動的ロードできなくなります（.NET ランタイムに依存するため）。アンマネージド DLL として公開しても、モジュールの動的ロードをサポートしません（未調査）。AOT 以外の公開では、Windows 7 との互換性が失われます。

学習に適したポイント

Avalonia を学んでいる方にとって、CodeWF Toolbox は単一ウィンドウのデモよりも価値があると思います。なぜなら、実際のデスクトップアプリケーションで直面する多くの問題を扱っているからです：

メインウィンドウとログインウィンドウ。
システムトレイ。
テーマ切り替え。
多言語リソース。
モジュール化ナビゲーション。
ToolFramework によるデータ駆動型ツール。
ファイル選択。
クリップボードへのコピー。
大きなログファイルの表示。
ユーザー設定と使用履歴。
Windows/Linux/macOS のプラットフォーム差異への対応（準備）。
公開設定。

こうした工学的なポイントは、多くの場合「ボタンが描画できるかどうか」ではなく、「ツールが増えても保守できるかどうか」という問題です。このプロジェクトは、私自身が実際に手を動かしながらこれらの工学的な問題を整理しているものです。

現在も改善の余地がある点

CodeWF Toolbox はすでにかなり完成度の高い方向性を持っていますが、私自身もまだまだ磨き上げる余地があることを認識しています：

一部のツールページのコントロールスタイルをさらに統一できる（例：入力ボックスの枠線、ボタンの階層、間隔）。
一部の中華語リソースに機械翻訳の痕跡が見られるため、徐々にブラッシュアップできる。
ツール数がすでに多いため、ホームページのおすすめツールにさらに明確なカテゴリ戦略を追加できる。
検索結果でツールカテゴリや最近の使用状況をさらに強調できる。
ログビューアにサンプルファイルやドラッグ＆ドロップのエントリを追加できる。
ビルド時にプレビュー SDK の警告、非推奨 API、Avalonia XAML の到達可能性警告がまだあるため、徐々にクリーンアップできる。

今回は既にメインウィンドウのデフォルトサイズを小さくし、ホームページに 8 つのショートカットエントリを追加しました。デザートテーマの下では、全体的に普段使いできるツールボックスという印象になり、過度に拡大されたデスクトップシェルには見えません。

最後に

CodeWF Toolbox は私自身が開発し保守しているツールボックスです。その価値は、個々のツールがどれだけ複雑かということではなく、開発者が頻繁に使う多くの小さなツールを拡張可能なデスクトップアプリケーションにまとめている点にあります。

現在、以下の分野をカバーしています：

変換ツール。
開発ツール。
セキュリティツール。
Web ツール。
メディアツール。
ネットワークツール。
数学ツール。
計量ツール。
テキストツール。
データツール。
ログビューア。
国際化 XML リソース管理。

C# でデスクトップツールを書くことは時代遅れではありません。ファイル、ローカルクリップボード、ログ、オフライン変換、一時的な生成、フォーマット、システム統合といったシナリオにおいて、ローカルデスクトップアプリケーションは依然として大きな価値を持っています。

そして、Avalonia + Prism はこの方向に対して、クロスプラットフォームでありながらモジュール化された方法で多数の機能を保守できる、比較的モダンな道筋を提供しています。

今後も CodeWF Toolbox を「本当に日常的に使える」ものへと磨き上げていきます。単なるデモウィンドウを作るよりも、私が鍛えたいのは次の能力です：増え続ける小さなツールを、長期間保守可能な製品として組織化する方法。