コマンドレット開発から得たAI駆動開発の雑感

これまでシンプルなコマンドツールをオープンソースの形で開発し提供してきました。

このサイトを開設してからまだ八か月しか経っていませんが、この間にAIコーディングエージェントが予想を超える進歩を遂げて、OSS開発を通じてAIの進歩に圧倒されているのが、現在の私の心境です。

元々、2020年にrmsmfを開発して、別のサイトで公開・配布していました。

初期のrmsmfの機能は、「複数の文字列を、複数のテキストファイルに対して、一括置換する」という単純な物で、最初は私も簡単にできると思って開発を始めました。

しかし、取り掛かってみると、「Windows固有の文字エンコーディング問題」が横たわっていることが分かり、この問題を克服する為には、「未知の文字エンコーディングを解析する」機能が必須であることも分かりました。

Windows環境では、文字列置換だけではなく、あらゆるテキスト処理がこの「Windows固有の文字エンコーディング問題」を解消しなければ、実用的なソフトウェアとして使用できないことを自覚しました。

そして、Windows標準機能がこの「Windows固有の文字エンコーディング問題」を解消できていないという、ちょっと信じ難い状況であることを、あらためて思い知らされました。

「Windows固有の文字エンコーディング問題」については、以前いくつか解説記事を書いたので、ここではこれ以上解説しません。

「文字化け」はなぜ終わらない？ 日本のITを縛る文字エンコーディングの深い闇

そのため、rmsmfにも日本語だけの文字エンコーディングの解析処理を独自に開発して実装していました。 その解析精度は今より低かったものの、ほとんどの場合に実用上は問題無く文字エンコーディングを自動推測できていました。

2020年当時は生成AIなど存在しませんでしたから、当然のことながらrmsmfは全部自分でコーディングしていました。

2023年にChatGPTが登場してから、私もAIによるコード生成を試していましたが、2023年から2024年まではハルシネーションによる間違いが多く、実用にはなりませんでした。

しかし、2025年ごろにコーディングエージェントがいくつか登場し始め、その性能には目を見張るものがありました。

エージェントはチャットとは異なり、コンパイラの結果を自分で確認して、何度もコード修正を繰り返して、コンパイルエラーを自力で解消しました。

生成AIが作るコードの品質も、2025年に登場した Claude Sonnet 4.5 あたりから向上して、ほとんどコーディングをエージェントに任せられる水準になりました。

私の場合は.NET開発が主なので、開発環境はWindowsが中心です。

コーディングエージェントはLinuxやmacOSなどUNIX系の開発環境を前提に作られており、登場した当初は、Windows環境で.NET開発に使うことはできませんでした。

しかし、2025年末から2026年初頭にかけて、Windows環境で使用できるコーディングエージェントが登場するようになり、私もこのころからOSS開発に積極的にコーディングエージェントを使用するようになりました。

ちょうど、このサイトsnow-stack.netを開設したタイミングと、Windows環境で使用できるコーディングエージェントが登場したタイミングが一致したわけです。

私が主に使用しているコーディングエージェントは、GitHub Copilot と Claude Code です。

どちらのエージェントもLLMには Claude を主に使用しています。

rmsmf と txprobe は私が自分で書いたコードですが、これらをリファクタリングしたときに、GitHub Copilot のエージェント（Claude Sonnet 4.5）を初めて使用してみました。

機能を変更することなく、コードだけ読みやすく書き換える作業なら、AIはほぼ完璧にこなしました。

その結果に満足した私は、次にrmsmf,txprobeを.NET10用に最適化してmfsr,mfprobeに移植させてみました。

これもAIは二日ぐらいで、ほぼ完璧に実施しました。

細かい不具合はありましたが、手動のテストで問題点を発見してAIに伝えると、AIはすぐにデバッグしました。

その後、国際化対応として、韓国語・繁体字中国語・簡体字中国語の仕様を Claude と Gemini のチャットAI側で詳しく調査しました。 そのうえで文字エンコーディングの解析方式を決めて、それを GitHub Copilot Agent に伝えて、CJK文字エンコーディングの解析処理を追加開発させてみました。

これは、最初は失敗しました。

既に英語と日本語の文字エンコーディング解析処理が実装されているコードに、追加で韓国語・繁体字中国語・簡体字中国語の解析処理を実装するよう「丸投げ」でAIに依頼した結果、何度修正させても正しい文字エンコーディングを返せない事態になりました。（この作業には三日ぐらいかけましたが、完成しませんでした）

原因は、各CJK文字エンコーディングの仕様上、バイナリ解析だけでは完全に文字エンコーディングを識別することが不可能だからです。

これで得た教訓は、「間違った指示や依頼をAIは忠実に実施しようとする」ということです。

実現不可能な指示・依頼であっても、AIは無限に挑戦し続けるのです。

実現不可能な指示ですから、いくら時間を掛けても永久に完成しません。

AIコーディングエージェントに開発を依頼するときは、その依頼内容が実現可能な内容であることを、依頼する人間の側が保証しなければならないのです。

それも開発する前の仕様の段階で実現可能であることを保証しなければなりません。

CJK文字エンコーディングの解析処理については、最終的にはOSのカルチャー情報（国・地域情報）を取得して、国ごとに異なる解析処理を走らせることで対処しました。

これでCJK圏では実用上問題は無いはずです。

また、その後CJK圏以外の旧文字エンコーディング解析処理には、海外製OSSのUTF.Unknownというライブラリが存在することをAIチャットに教えられて知ったので、rmsmf,txprobe,mfsr,mfprobeに組み込みました。

ここまで、二か月もかかっていません。2026年2月上旬にはリリースしています。

コマンドレット開発とNuGetパッケージ化

元々、rmsmfは2020年のターミナル状況に合わせて開発していました。

当時はまだPowerShellがWindowsの主流にはなれておらず、まだまだcmd（コマンドプロンプト）が主流でした。

コマンド上で文字エンコーディングを確認する作業はほとんどcmd上で行われていたので、rmsmfはcmdでもPowerShellでもどこでも動作する仕様にする必要がありました。

cmdとPowerShellでは、パイプラインとコマンドパラメータの仕様が異なるので、どちらでも使えるようにするには、少し工夫が必要でした。

まず、普通のコマンドは積極的にパイプラインを活用する仕様で作られています。パイプラインはUNIX思想で「単純な機能を持つ小さなプログラムを共通の入出力で連携させることで、複雑な処理を柔軟に構成すること」を実現するための機能なので、この目的を満たすために、普通のコマンドはパイプラインを活用します。

しかし、cmdのパイプラインは単純なバイトストリームを渡すのに対し、PowerShellでは.NETオブジェクトを渡す仕様になっています。文字列もSystem.Stringオブジェクトとして渡されます。

よって、PowerShellに合わせてオブジェクトパイプラインを出力すると、cmd側では受け取れないことになります。

そこで、rmsmfではパイプラインを使用しない仕様にしました。データ連携はテキストファイルを受け渡すことで実現しています。

その後に開発したtxprobe,mfsr,mfprobeは全て同様の仕様になっています。

そのため、これらのコマンドツールは、全てPowerShellの機能を生かせないものになってしまいました。

PowerShell上で使用することはできますが、その出力を.ps1スクリプトなどで活用することが難しい仕様です。

私はこの問題を解消したいと考え、同様の機能をPowerShell Cmdlet(コマンドレット)で実装することにしました。

そのためには、まずrmsmf,txprobe,mfsr,mfprobeコマンド群で開発していた文字エンコーディング解析処理を外部モジュールに切り出しNuGetパッケージとして汎用モジュール化する必要があると考えました。

既に文字エンコーディング解析処理は独立したクラスになっていましたから、これだけを切り出すのは簡単ですが、改行コードやBOMの有無の判定処理は別の処理として実装されており、これらを文字エンコーディング解析処理に統合する必要がありました。

文字エンコーディング解析と改行コードとBOMの解析処理を統合し、カルチャー情報とUTF.Unknownの切替機能も組み込み、NuGetパッケージとして扱い易い仕様に変更したのち、NuGet.orgからリリースできるようにしました。

続けて、PowerShell Cmdletとして使い易い仕様の検討に入りましたが、これが一番苦労する要点でした。

Windows PowerShell 5.1とPowerShell 7.xでは文字エンコーディング周りの仕様が異なります。

前者は「デフォルトはShift_JIS、UTF-8で書き出すとBOM付きのみ、エンコーディングの指定は固定のフレンドリー名のみ」ですが、後者は「デフォルトはBOM無しUTF-8、UTF-8はBOMの有無を選択可能、エンコーディングはコードページでもWebNameでも柔軟に指定可能」と、テキストファイル周りの仕様が別のOS並みに異なります。なお、-Encoding UnicodeがUTF-16LEを指す点は、どちらも共通です。

PowerShellコマンドレットの仕様を考えるにあたって、Claude Opus Chat と何度も相談を重ねました。

仕様策定は、私が一人でやるには時間が掛かりすぎるが、「Claudeに丸投げ」もできない作業です。

AIを使用した開発は、「人間にとっての使いやすさ」は人間が責任を持たなければ、適切な設計はできないと言えます。

モジュール分割やUIの設計は、人間にとってのわかりやすさが重要な設計要素になってくるので、身体感覚のある人間にしかわからない側面があります。

最終的にPowerShell Cmdletの開発は、バージョン1.0,1.1,1.2の三回に分けて行うことにしました。

• 1.0ではResolve-Encodingだけを提供して、文字エンコーディング・改行コード・BOMの有無の判別だけの機能を提供する
• 1.1では、ユーザーが文字エンコーディングを気にする事無く、テキストファイルの閲覧・編集を行うことができるコマンドレットを提供する
• 1.2では、対象テキストファイルの文字エンコーディング・改行・BOMの有無の変換機能を提供する

という方針が定まりました。

この仕様策定まで、何日も Claude Opus と相談しながら試行錯誤しました。相談しているうちに Opus は Opus 4.8 に、さらにその後 Opus 5 にアップデートされました。

NuGetパッケージを使用したコマンドレットの実装は、開発規模も小さいので、全て Claude Code に任せてみました。

その結果、私がほとんどコードを書かなくても、不具合のほとんどないコマンドレットが完成しました。

自分でも手動動作確認は行っていますし、いくつか不具合を発見してAIに修正させていますが、コマンドレット程度の規模だと、開発はもう人間の仕事ではないことを実感します。

現在、1.1までリリースしており、これから1.2の開発に着手しますが、これも Claude Code で開発するつもりです。

SnowStack.EncodingProbe.PowerShellのリポジトリの/docs/フォルダーの中には、Claude Code とのやり取りの文書を残しています。

AIで開発していることは、既に公言していることなので、プロンプトも公開しておこうと思います。

私のAI駆動開発は、我流ですし世間のAIガチ勢に比べると、遅れているぐらいだと思いますが、もはやソフトウェア開発においてはAI駆動開発が当たり前になっていると言えるので、AIを使用した開発を行っていると公開して、今後のOSS開発もやっていくことにしました。

今後のOSS開発は、AI駆動開発の研究手段として続けていくことになります。

開発業務はAIの仕事になる

コマンドツールやコマンドレットの他に、非公開でGUIのデスクトップアプリも Claude Code に作らせてみましたが、スタンドアロンアプリ程度なら、GUIも簡単に開発してしまいます。 例えば、SVGファイル専用のドローアプリは二日ぐらい。CSVエディターなら30分ぐらいで完成させることができます。

経済産業省がAI時代のソフトウェア開発について、予測レポートをいくつか公開していますが、それらを読むと「バリューチェーンの中流の市場価値はAIにより急速に失われて行く」と予測しています。

つまり、「物作りは価値を失う」と予測しているのです。

AI時代に価値を維持するのは、「バリューチェーンの最上流と下流のみ」だそうです。

最近のコーディングエージェントの進歩を見ると、ソフトウェア開発に関しては本当に「物作りは価値を失う」という予測は近いうちに実現するだろうと実感します。

現在提供されているAIエージェントで実用水準に達しているのは、Claude Code や OpenAI Codex などコーディングエージェントだけです。

今のところ、AIエージェントによる自動化が本格的に進んでいるのは、ソフトウェア開発の領域だけだと言えます。

しかし、AIエージェントの可能性は、コーディングだけではありません。

建設や製造業の図面設計、電子回路の設計、道路や上下水道といった都市インフラの設計など、AIエージェントによる自動化が可能と思われる領域は他にもたくさんあります。

会計業務や薬剤調合などもAIエージェントが貢献できそうです。

個人的には、マネジメント業務もAIエージェント向きの業務だと思っています。 経営判断すらAIエージェントでできるかも知れません。

これらの領域は、まだAIエージェントが作られていないだけで、エージェント化が進むのは時間の問題だと思います。

既に、音声認識や画像認識などのマルチモーダルAIも実用化されています。それらを束ねて業務そのものを担うエージェント製品が、まだ登場していないだけです。

工場での物作りも、自動化は予想以上に早く進むと思います。 「物作りが価値を失う」将来はそんなに遠い未来ではないかも知れません。

少なくとも、現在の産業構造は、そのままの形では存続しないでしょう。 AIとロボットを中心とした新しい産業構造が構築されると思います。

将来、産業構造がどのように変化するのか、経済産業省は別のレポートでも予想しています。 この辺の経済産業省が描く未来予測の話は、別の記事で書きたいと思います。

今回は、私が文字エンコーディング対策のコマンドツール開発を通じて体感したAIエージェントの可能性について、記事に書いてみました。

時々、こういう経験・体験に基づく「雑感」のような記事も書いていくので、よろしくお願いします。