mfsr・mfprobe・rmsmf・txprobe のバージョン 1.1.2 のリリースを開始したことを、ご報告します。
先日の SnowStack.EncodingProbe 1.2.0 のリリース時に予告していた、クラスライブラリの入れ替えを行ったものです。
mfsr・mfprobeについては、wingetにて提供しています。
winget upgradeで更新可能なパッケージを確認し、winget upgrade --allでまとめて、または パッケージ ID を指定して個別に更新できます。
winget upgrade
winget upgrade --all
winget upgrade motoi.tsushima.mfprobe
winget upgrade motoi.tsushima.mfsr
新規にインストールする場合は、パッケージ ID を指定してインストールしてください。
winget install motoi.tsushima.mfprobe
winget install motoi.tsushima.mfsr
詳しいインストール方法の解説は以下のページで行っています。
rmsmf・txprobeは、業務上 .NET Framework 4.8しか使用することが許されない方々のために提供しており、wingetによる提供はしておりません。
インストール方法は、以下のページで解説しております。
使用説明書は、以下の固定ページで以前から解説しております。
rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説
mfsr・mfprobe・rmsmf・txprobe は全て、SnowStack.EncodingProbeクラスライブラリを使用して文字エンコーディング解析を行っています。
先日、このクラスライブラリを1.2.0にアップデートしたので、こちらのコマンド群にも最新版クラスライブラリを導入してリリースしたものが、1.1.2になります。
mfsr・mfprobe・rmsmf・txprobe は全て、クラスライブラリを最新版にアップデートしただけで、基本機能や使い方に変更はありません。
mfsr・mfprobe・rmsmf・txprobe について、クラスライブラリのアップデートにより、変わった部分があります。
クラスライブラリの変更内容は、以下の固定ページで詳しく解説しています。
SnowStack.EncodingProbe 1.2.0 解説 — ファイル出力・変換コマンドと世界の言語への対応
リリースの告知は、SnowStack.EncodingProbe.PowerShell 1.2.0 リリースのお知らせの記事で行っています。
EncodingProbe（略称）では、文字エンコーディング解析にあたって、独自アルゴリズムと、サードパーティ製品（UTF.Unknown）のアルゴリズムの二つのアルゴリズムで、解析を行っています。
サードパーティ製品のアルゴリズムは、欧米など旧シングルバイト文字エンコーディングの解析には優れていますが、CJK圏など漢字文化圏の旧マルチバイト文字エンコーディングの解析では見劣りするため、CJK圏の文字エンコーディングだけを独自アルゴリズムで解析し、解析精度を補完しています。
旧バージョンでは、欧米など旧シングルバイト文字エンコーディングの解析はEncodingProbeの対応が不十分で、独自アルゴリズム側が旧シングルバイト文字エンコーディングを誤判定してしまう確率が高かったのです。
これまで正式に対応していた言語は、英語・日本語・韓国語・繁体字中国語・簡体字中国語だけで、香港にも未対応でした。
旧シングルバイト文字エンコーディングのファイルを、東アジアの言語環境でコマンドを実行して解析すると、状況によって不必要な独自アルゴリズムの方が稼働してしまい、サードパーティ製品（UTF.Unknown）のアルゴリズムに確実に解析処理を渡せない場合がありました。
今回、旧シングルバイト文字エンコーディングのテスト環境も作り、世界の多くの言語のテストを実施することで、東アジアの言語環境でも、旧シングルバイト文字エンコーディングの解析をサードパーティ製品（UTF.Unknown）に確実に渡せるようになりました。
EncodingProbe 1.2.0により、香港の Big5-HKSCS にも対応しております。（ただし、コマンドの表示メッセージなどは、これまでと同じで、香港向けの変更はしていません）
旧シングルバイト文字エンコーディングの解析は、サードパーティ製品（UTF.Unknown）に任せているため、サードパーティ製品が誤判定する部分については、EncodingProbeでの対処はできないのが、現状です。
簡単なテストで明らかになっている問題点は、以下のようになります。
| 言語 | 文字エンコーディング | 問題の内容 |
|---|---|---|
| フランス語 | ISO-8859-15 | €（0xA4）を含む場合、€ が ¤ として読まれ、ISO-8859-1 と誤判定される。 |
| スペイン語 | windows-1252 | €（0x80）や —（0x97）を含む場合、これらが制御文字として読まれ、ISO-8859-1 と誤判定される。 |
| イタリア語 | ISO-8859-1 | 文字の一覧や記号の多いテキストなど、内容によっては判定不能になる。 |
| イタリア語 | windows-1252 | 文字の一覧や記号の多いテキストなど、内容によっては判定不能になる。 |
判定不能になる条件については、前述の固定ページの「シングルバイト系の判定は、長さよりも内容で成否が決まります」で詳しく解説しています。
これらの誤判定は、サードパーティ製品の誤判定なので、私には直接対処ができません。対処するとしたら文字エンコーディング解析方法の根本的な見直しが必要になります。現状では、これらの問題に短期間では対処できません。
正しく判定できない場合は、/c: オプションで文字エンコーディング（例: /c:1252）を明示してください。
mfprobe *.txt /c:1252
ユーザー定義領域（私用領域）を使った簡体字中国語のGBK(CP936)のファイルについては、文字エンコーディング自動判定でGB18030と誤判定する問題があります。
これは、独自アルゴリズムの問題なので、私が対処可能です。
これからゆっくり、総合的な対策を考えたいと思います。
世界の言語に対応するのは、テスト方法が複雑で、どうしても個人の力では限界があります。そもそもある程度の世界言語への対応が可能になったのも、生成AIが活用できるからに他なりません。
現状で、私が対処できるところまでは、完成させたと言わせてもらいます。
上記問題点を含め、これ以上の対処が、私の力でできるかどうかは、正直なところ分かりません。
できる範囲内で、対処していきたいと思います。
通常の利用であれば、現在のバージョンで充分に利用可能だと思います。
以上、リリースの報告でした。
]]>以下のコマンドレットを追加しました。
Out-ProbedFile : オブジェクトを整形して、ファイルに書き出す。
Convert-ProbedContent : 既存のファイルの文字エンコーディング・BOM・改行を変換する。
このほか、既存のコマンドレットの改善や不具合の修正も行っています。
詳細は、以下の固定ページで解説しています。
SnowStack.EncodingProbe 1.2.0 解説 — ファイル出力・変換コマンドと世界の言語への対応
また、NuGet パッケージの SnowStack.EncodingProbe 1.2.0 も同時にリリースしています。
公開 API（クラスやメソッド）の変更はありませんが、これまで英語と東アジアの CJK（日本語・中国語・韓国語）の言語でしか動作を確認していなかったクラスライブラリを、UTF.Unknown が対応している世界の言語でも使用できるように改修しました。
従来は、日本語などの東アジアの言語環境で、欧米などの言語のファイルを判定すると、Shift_JIS などと誤判定することがありました。1.2.0 では、これを正しく判定できるようにしました。ただし、短い文では、まだ誤判定することがあります。
1.1.0 のときとは違い、今回はクラスライブラリの判定処理そのものを改修しているので、NuGet パッケージを直接お使いの方にも、1.2.0 への更新をお勧めします。
NuGet パッケージとPowerShellコマンドレットの機能説明は既に6月のプレリリース時点で、固定ページで公開しております。
インストール方法や使い方については、こちらの固定ページをご覧下さい。
SnowStack.EncodingProbe NuGet Package 解説
SnowStack.EncodingProbe.PowerShell 解説
「コマンドレットを二つ追加しただけで、ずいぶん時間がかかっているじゃないか」と思われる方も多いと思うので、それについて釈明させてください。
まず、今回最も時間を要したのは、二つのコマンドレットの開発ではなく、クラスライブラリの私用領域の扱いと、世界の言語への対応の方です。
先に説明しましたように、コマンドレットも参照しているクラスライブラリの SnowStack.EncodingProbe は、1.1.0 までは英語・日本語・韓国語・繁体字中国語・簡体字中国語でしか厳密な動作確認を行っていませんでした。
今回の 1.2.0 では、UTF.Unknown が対応している旧シングルバイト文字エンコーディングの判定も、東アジアの言語環境で正しく行われるように改修し、厳格な動作確認を行いました。
これにより、クラスライブラリを参照しているコマンドレットも、世界の言語環境で使用できるようになりました。
また、以前から予定していたように、香港の固有文字への対応を行いました。
香港については、Big5-HKSCS への対応をすることになります。Big5-HKSCS は Big5 に香港固有の文字を追加した上位互換の文字エンコーディングですが、.NET には Big5-HKSCS 専用のデコーダーが無く、big5-hkscs を指定しても台湾の Big5（コードページ 950）として扱われます。
香港固有の文字は、主に Big5 のユーザー定義領域（私用領域）に定義されているので、HKSCS に対応するということは、ユーザー定義領域（私用領域）の扱いを決めることと、ほぼ同義になります。
そのため、この Big5-HKSCS への対応をきっかけに、Shift_JIS を含む CJK の旧文字エンコーディング全般について、ユーザー定義領域（私用領域）の扱い方の方針を定めることになりました。
Shift_JIS では、外字の扱い方を定めたことになります。
既に、固定ページの外字（私用領域）の扱い — SnowStack.EncodingProbeで解説していますが、EncodingProbe ではユーザー定義領域（私用領域）の内容には干渉しない方針にしています。
干渉しないとは、例えば Shift_JIS から UTF-8 へ変換する場合は、Shift_JIS のユーザー定義領域の中身を、加工することなく、Unicode の私用領域（PUA）へそのまま写すことを意味します。
ユーザー定義領域の文字が何の字なのかは、ユーザーが決めるものなので、UTF-8 へ移しても PUA の中身の解釈は変更せず、ユーザーの管理下のままにするということです。
香港固有の文字も Big5 のユーザー定義領域に定義されており、Big5-HKSCS を UTF-8 などの Unicode に変換した場合、ユーザー定義領域の香港固有文字を、Unicode の PUA へそのまま写すことになります。
.NET が Big5 と Big5-HKSCS を同一の文字エンコーディングとして扱っている以上、バイナリパターン解析によって両者を区別することはできません。私用領域の文字が、台湾のユーザー定義文字（造字）なのか、香港固有文字なのかも、区別できません。
よって、私用領域の内容は Unicode の PUA へ、そのまま写すことにしました。
この私用領域の扱い方の方針は、そのまま Shift_JIS にも適用されます。外字も Unicode の PUA へ写されます。Unicode からの逆変換では、PUA からユーザー定義領域へ戻されるため、往復も可能です。
EUC-JP の場合は、.NET に 20932 と 51932 の二つのコードページがあり、外字（ユーザー定義領域）の扱いが異なります。外字を往復できるのは 20932 の方だけです。詳細は固定ページの解説をお読みください。
こういった、私用領域の扱い方の方針を定めることに、かなりの時間を要しました。
以前から説明しているように、開発は Claude Code を使用しているので簡単ですが、企画や設計では、私用領域の扱い方などの方針を定めなければならないため、AI に任せることができません。これは「何を、どうしたいのか」の部分なので、人間が考えるしか無いのです。
今のところ、ヘルプなどのメッセージの言語は、まだ世界の言語には対応しておらず、CJK 圏以外は全て英語で表示されますが、これも近い内に対応言語の範囲を広げるつもりでいます。但し、全ての言語のヘルプやメッセージに対応することはできないので、対象とする言語の範囲は絞り込むことになります。詳細は未定です。
クラスライブラリの SnowStack.EncodingProbe 1.2.0 は、まだ mfsr・mfprobe・rmsmf・txprobe には組み込んでいません。これらは 1.1.0 を使用しています。これから入れ替える予定です。入れ替えたら、このブログで告知します。
これを開発している間にも Claude のアップデートが続き、Opus 5.5、Sonnet 5.5 を試すことになりました。
本当に、もう開発は人間の仕事ではないです。人間の仕事は企画立案と大枠の設計になります。
企画立案は問題発見領域の仕事でもあるので、問題発見こそが人間の仕事であるとも言えます。
OSS の開発と公開を始めてから、あれよあれよという間に AI エージェントが発達して、ソフトウェア開発の仕事が根底から覆ってしまいました。
AI エージェントの進歩は、予想を何倍も上回る速度で進んでいます。これはコーディングエージェントだけではなく、他の業務領域でも進むでしょう。
私もコマンドレットを開発しながら、「これからどうしようか？」と悩んでいました。
自動運転車も、来年には登場しそうだという報道が聞こえてきます。
コーディングエージェントの進歩から、これから世の中で起きる激変が垣間見えるようです。
]]>生成AIが社会に与える影響に関しては、営利目的ではない分析を行っている国の報告を読むのが良いでしょう。 経済産業省はAIが産業界と雇用にどのような影響を与え、産業が将来どのような変化を遂げるか予測してレポートを公開しています。 経済産業省の目的は国全体の経済成長にあるので、日本国民全員が受益者と言えます。
今回は、経産省のレポートに描かれる未来の産業界の姿を、レポートからの引用を中心にこの記事に描いてみたいと思います。
特にAIの進歩により、IT産業を中心とした産業界がどのように変わるのかを中心に抽出してみます。
まず、今回参照する経産省のレポートを紹介します。
2025年前半に公開されたレポートです。
2026年前半に公開されたレポートです。
大多数の人が気にするのは、AIにより雇用がどのように変化するのか、という部分だと思います。
「2040年の就業構造推計」では、2040年ごろの職種と学歴と専門性別の雇用需要を2022年と2040年を比較する形で、雇用の変化を予測しています。
分析の結論は、レポートの先頭に記述されています。以下に引用します。
2040年に十分な国内投資や産業構造転換が実現する場合(注)、人口減少により就業者数は約6700万人(2022年)から約6300万人となるが、AI・ロボット等の利活用やリスキリング等により労働需要が効率化され、全体で大きな不足は生じない。
一方で、職種・学歴・地域間では需給ミスマッチが生じるリスクがあり、事務職(約440万人)や文系人材(約80万人)が余剰、AI・ロボット等利活用人材(約340万人)を含む専門職や現場人材(約260万人)、理系人材(約120万人)が不足する可能性。
「人口減少により就業者数は約6700万人(2022年)から約6300万人となるが」と人手不足が加速する不安を想定した上で、「労働需要が効率化され、全体で大きな不足は生じない」と締めています。基本的に人手不足経済が続く前提で、人手不足による経済成長の障害の影響度を予測する内容です。 マクロで人手が余る不景気は、想定されていません。 但し、雇用のミスマッチは、それとは別の懸念事項として報告されています。 マクロとミクロは区別してレポートを読み取りましょう。
なお、この推計は冒頭にあるとおり「十分な国内投資や産業構造転換が実現する場合」という条件付きの数字です。前提が崩れれば、描かれる絵も変わります。
まず、マクロの雇用変化ですが、 「事務職(約440万人)や文系人材(約80万人)が余剰」と 「AI・ロボット等利活用人材(約340万人)を含む専門職や現場人材(約260万人)、理系人材(約120万人)が不足する」の「余剰と不足の対比」が報告されています。
この余剰と不足の説明は、内数が併記されていて非常にわかりにくい表現になっています。
特に「専門職」とその内数の「AI・ロボット等利活用人材」の関係が誤解を招きやすいです。
「専門職」の中に「AI・ロボット等利活用人材」が含まれており、「専門職」全体が181万人の不足になりますが、その中の「AI・ロボット等利活用人材」が339万人の不足になっているので、「AI・ロボット等利活用人材」を除いた「専門職」は、(－181) － (－339) ＝ ＋158 となり、158万人の余剰ということになります。
つまり、専門職の中で不足するのは「AI・ロボット等利活用人材」だけであり、他の専門職は余剰になるということです。
現場人材の場合は、全体で260万人不足で、その内「生産工程従事者」が206万人の不足になると書かれています。こちらは分かりやすいです。「生産工程従事者」以外で不足する現場人材は 260 － 206 ＝ 54 で、54万人の不足です。
全体を整理すると、
余剰の合計は、437万人。 不足の合計は、181万人 ＋ 260万人 ＝ 441万人。 差し引き、441万人 － 437万人 ＝ 4万人の人手不足ということになります。
2040年の就業者数6300万人に対して4万人ですから、全体としてはほぼ均衡です。レポート冒頭の「全体で大きな不足は生じない」という結論とも一致します。
つまり「2040年になっても全体として人手が余ることはない」という報告であり、「AIによる自動化で人手が余る」というレポートでは無いことが理解できると思います。 このレポートは、「AIやロボットの活用により、現在の深刻な人手不足は、緩和される」という報告であり、「AIで失業者が増える」という報告ではありません。
ちなみに、人手不足の推計としてよく引用されるものに、パーソル総合研究所と中央大学による「労働市場の未来推計2035」があります。 こちらは2035年に1日あたり1,775万時間（働き手384万人分）の労働力が不足し、2023年と比べて1.85倍深刻になると推計しています。この1.85倍という比率から逆算すると、2023年時点では200万人分ほどの不足だったことになります。
こちらは「人手不足が深刻化する」という結論なので、経産省の「ほぼ均衡」とは方向が逆に見えます。ただし推計の前提も手法も異なるので、単純比較はできません。この差は、AI・ロボットの利活用や産業構造転換がどこまで進むと置くか、という前提の違いによるところが大きいと思われます。
いずれにせよ、どちらの推計からも「AIによって人手が余る」という結論は出てきません。 現時点(2026年)でもマクロでは深刻な人手不足ですから、経産省の推計は、どちらかと言えば私には「少子化で労働人口が減るわりには、今ほど人手不足は深刻にはならない」という趣旨の報告に見えます。
「2040年の就業構造推計」では、職種や専門性の違いによる雇用のミスマッチが深刻になることに警鐘を鳴らしています。
2026年時点で人手不足経済の現在でも、一般事務職だけは人手が余っており、例外的に新規の就職が難しい職種となっています。 2040年の予想でも、2022年との対比で事務職は437万人も人材余剰になることを予測しています。 これは現在のAIエージェントの進歩を見ると容易に理解できる予想です。 デスクワークを主体とした事務処理業務は現在でもかなりITやAIによる自動化に適した職種です。2040年を待たずに現時点で急速に生産性向上により雇用が縮減する職種であることは誰にでも理解できることでしょう。 また、学歴別で見る文系の大卒・院卒が76万人も余剰になるという予想も、事務職の縮減と関連する現象と容易に予想できます。
ただし、この437万人という数字の読み方には注意が必要です。 これは「2040年に事務職として働ける人の数」と「2040年に事務職として必要とされる人の数」との差を計算したものであり、437万人の失業者が出るという意味ではありません。
思い出してほしいのは、この推計が「就業者数は約6700万人(2022年)から約6300万人となる」という前提で計算されていることです。2040年までに労働人口そのものが400万人も減ります。余剰の437万人は、今の労働市場に上乗せされる失業者ではなく、400万人減った後の6300万人の中での配置の偏りを表した数字です。 そして同じ2040年に、専門職と現場人材で441万人が不足しています。余剰と不足がほぼ同じ規模である以上、事務職から溢れた人材が、そのまま職を失うという話にはなりません。
つまり、この余剰と不足の数字は「職種ごとの人の配置が今のままだったら」という仮定で計算した差分です。 だからこそレポートは、これを失業の予測ではなく「需給ミスマッチのリスク」として警告しています。職種間の移動がうまく進まなければ、一方で職を失う人が出て、他方で人手不足が解消しないという、社会全体にとって最も損な結果になるからです。
土木建設や介護・医療・サービス業や工場などで手足を使った作業をする現場人材が、260万人不足すると言っています。 専門職は全体で181万人の不足ですが、その内訳は先述のとおり「AI・ロボット等利活用人材」の339万人不足と、それ以外の専門職の158万人余剰です。
この339万人という不足数は、情報処理技術者にとって特に重要な意味を持ちます。 この「AI・ロボット等利活用人材」は、2022年時点での就業者数は236万人とされていますが、現在の段階で「AI・ロボット等利活用」職種というものは、まだ多くありません。 2022年時点での「AI・ロボット等利活用人材」は、「機械技術者やその他の情報処理通信技術者等の職種を集計」とレポートの注意書きに書かれていることから、現在の情報処理技術者は「AI・ロボット等利活用人材」に含まれていることが分かります。 2040年時点での「AI・ロボット等利活用人材」は、推定で需要数782万人に対し供給数は443万人と予想しています。
学歴別の需給予測では、理系の大卒・院卒が124万人不足するだけでなく、工業高校卒が91万人不足、高専卒で15万人不足するという、「大卒だけではない広範囲な理系不足」状況を予想しています。
現在でも電気工事士のような人材が不足していて「エアコン設置工事が半年待ち」のような状況が発生しています。 AIとロボットが広く普及するようになれば、ロボットを現場に設置・運用する設備運用系技術者が必要になりますから、現在の電気工事士以上に設備運用系技術者が不足する未来が予想できます。 電脳住宅のようなロボット設備が普及すると、各家庭のメンテに設備運用系技術者が日常的に必要になります。
加えて工場や発電所など社会インフラ設備等のAI化・機械化が進むことを考えれば、工業高校卒が91万人不足というのも理解できます。
「AI・ロボット等利活用人材」が339万人不足するとしていますが、 同レポートの「全国版就業構造推計（改訂版）・職種間ミスマッチ」のページを見ると、これと矛盾するような推計があります。
「主な産業の2040年の需給ミスマッチの内訳」に製造業・建設業・運輸業などの産業別の雇用予測が書かれており、この中に情報通信業があります。
産業別の「AI・ロボット等利活用人材」の需給数予測では、農林水産業で7万人不足、製造業で125万人不足、卸売小売業で77万人不足、建設業で26万人不足、宿泊業・飲食サービス業で21万人不足、運輸郵便業で26万人不足と、ほとんどの産業で不足しているにもかかわらず、情報通信業では102万人も余剰になると予想しています。
情報通信業以外の産業での「AI・ロボット等利活用人材」の不足数の合計は、282万人になりますから、282万人 － 102万人 ＝ 180万人 となり、これら主な産業の合計では180万人の人材不足になります。
9ページの「（参考）将来の産業構造は、①製造業X（エックス）、②情報通信業・専門サービス業、③アドバンスト・エッセンシャルサービス業がカギ」を見ると、情報通信業は2040年には「新需要開拓で新たな付加価値を創出・他産業を上回る賃上げ」と予想していますから、産業が縮小するわけではなく、情報通信業は繁栄することが予想されています。
情報通信業自体は繁栄しても、情報通信業におけるこの職種の労働需要は、供給を大きく下回ることが予想されているのです。
また、この「2040年の就業構造推計」では、「情報処理技術者」という人材が登場せず「AI・ロボット等利活用人材」という枠組みで人材需要を予測しています。 なぜ、このような扱いになっているのかを考えるに「2040年時点では情報処理技術者はこのくくりの中に含めて扱われている」からと思われます。
現在のコーディングエージェントの進歩を見ると、これまでの情報処理技術者の仕事はAIエージェントに置き換わることが、容易に予想できます。 経産省も、2026年から2040年までの間に、現在の情報処理技術者は段階的に「AI・ロボット等利活用人材」にシフトしていく事を予想していることが、「2040年の就業構造推計」の内容から透けて見えます。
これは単純に「情報処理技術者が失業する」という結果には繋がりません。
全産業での「AI・ロボット等利活用人材」の需給は、339万人の不足で、上記「主な産業の2040年の需給ミスマッチの内訳」の中だけで見ても180万人の不足になるので、2040年までに、現在の情報通信業で就労している情報処理技術者がAI・ロボット技術を習得しながら他の産業へ移籍していくことを想定しているのだと思います。
これは、経産省が2018年のDXレポートの頃から啓発している「事業会社でのシステムの内製化」の推奨とも一致する話です。
実際、現在の日本産業界ではシステムの内製化が広がり始めています。
SIer業界から事業会社への情報処理技術者の大移動は、既に始まっている現実です。
9ページの「（参考）将来の産業構造は、①製造業X（エックス）、②情報通信業・専門サービス業、③アドバンスト・エッセンシャルサービス業がカギ」を見ると、ほとんどの産業が2040年時点で「AI・ロボット等利活用人材」を雇用し、実質的にIT企業化して付加価値と賃上げを実現する見通しを、経産省が立てていることが読み取れます。
現在のように、デジタル人材の7割がベンダ企業側に所属する体制は消えていくことを予想しています。（デジタル経済レポート 論点4b・P84）
おそらく、現在の情報処理技術者は、2040年までにはAIやロボットを活用して、今とは全然別の仕事をこなしていることでしょう。
人材需要が高いので失業することは無いと思いますが、今とは全然違う雇用に就いていることでしょう。
もう一つ、重要な点として「AI・ロボット等利活用人材」が339万人不足するということは、その利活用職は誰にでもできる仕事ではなく、「AI・ロボット等利活用人材」として働くために専門知識を持ち専門訓練を受けた人間でなければ務まらない職業だということです。
誰にでもできる仕事ならば339万人も不足しません。
次に、2025年に経産省から公開された「デジタル経済レポート」に描かれた将来像の部分を引用していきたいと思います。
このレポートは、日本におけるIT分野での対外的な競争力の遅れが、将来どのような悪影響を日本の全産業界に与え、それに対して国全体でどのような競争戦略を取るべきなのかを、論じたレポートです。
「将来の国家IT戦略」を立案するレポートなので、そのために「将来のIT産業がどのような姿になるか」を予測しています。
レポートの先頭に要点が書かれています。引用します。
ソフトウェア、そしてデータが、世界を飲み込んでいる。 世界は、存在する文字通りすべての取得可能なデータを起点に、企業や企業の提供するサービスの付加価値がソフトウェアによって規定される「聖域なきデジタル市場」時代に突入している。 サービスの付加価値を規定するソフトウェアが売れないとハードウェアが売れない。 そして、データがなければ価値あるソフトウェアが生み出せず、競争力が維持できない、 という「データに全てを飲み込まれる世界」が、聖域なきデジタル市場という現実の競争環境として着実に迫っている。
将来のIT産業の姿を表す上で要点となるのが、
「サービスの付加価値を規定するソフトウェアが売れないとハードウェアが売れない。」
「そして、データがなければ価値あるソフトウェアが生み出せず、競争力が維持できない」
の部分です。
この文の意味は「1.1 検討の背景と経緯」で解説されます。
2017 年以降の生成 AI の本格的な社会実装により到来した AI 革命により、今まで表形式に構造化されたデータしか扱えなかったソフトウェアは、ついに日常の文書や画像、映像、音声、図面等といった、非構造化データまでも大規模、かつ高速に飲み込むようになった。いま世界は、存在する文字通りすべての取得可能なデータを起点に、企業自体や企業が提供するサービスの付加価値がソフトウェアによって規定される「聖域なきデジタル市場時代」に突入している。 聖域なきデジタル市場において、ソフトウェアとデータはすべての産業・市場を飲み込んでいる。 そして、経済活動の付加価値源泉としてのハードウェアとソフトウェアの主従逆転が起きている。 ハードが売れないとソフトが売れない、というモノの付随物としての組み込みソフトウェアの時代から、ソフトが売れないとハードが売れない、というソフトウェア付随物としてのモノという時代に変容しているのである。
「2017年以降の生成AI」という記述に引っかかった方もいると思いますが、これは原文どおりです。レポートの脚注では、Transformer技術を生んだ「Attention is All You Need」論文の発表（2017年）を起点に、OpenAIのGPT初期モデル（2018年）、ChatGPT（2022年）が挙げられています。
聖域なきデジタル市場では、すべての企業は生存のためにソフトウェアカンパニーに、そしてデータカンパニーにならざるを得ない
デバイスの売り手も、インフラストラクチャの売り手もソフトウェア・データを起点に、モノではなくサービスを売っているということ。 デバイスは、デバイスを媒介したアプリケーションサービスを、またはデータの取得手段としてのサービスを売っている。 一見モノを売っているように見える IaaS も単に計算資源を提供するだけでなく、ユーザが使いやすく管理されたマネージド型の計算サービスとして売っているのである。
まず、IT企業ではない一般の事業会社の市場競争が、ソフトウェアによって勝敗を左右される状況にあることを説明しています。 従来の日本の産業の中心は製造業とされ、ハードウェアの生産能力と品質が日本製品の主な付加価値として機能してきましたが、これからはソフトウェアによって構築されたプラットフォームが付加価値の源泉になり、ソフトウェア・プラットフォームを握れない企業は、プラットフォーム企業の下請けに転落すると、警鐘を鳴らしています。
自動車会社は自社のSDV(Software Defined Vehicle)を開発できなければ、他社の車載OSを搭載しなければなりません。 SDVを提供している企業の下請的存在になり、市場での主導権を失います。 ちょうどパソコンとWindowsの関係がこれに似ています。 昔、独自規格パソコンを開発していた日本のパソコンメーカーはパソコン開発の主導権を自ら握っていましたが、Windowsの登場によりMicrosoftの決めた仕様に従わなければ自社のパソコンを販売できなくなりました。 自動車とSDVの関係もこれと同じです。
この前提で、現在の日本における「事業会社がSIerにソフトウェア開発を外注する」体制に対しては以下の様に批判的評価をしています。
SI 事業 低成長・低利益率事業であり、AI 革命と外資サービス進出による外圧でビジネスモデル転換が迫られる。本事業を主たる収益源とするベンダ企業は、ビジネスモデルをスマイルカーブ上流、下流に移行しなければ、国内ですら生存は難しい。
日本市場の特殊性であるベンダ・ユーザの二項対立という伝統的な枠組みは、ユーザ企業におけるデータ・ソフトウェア戦略を理解できない/したくない経営層、既存のオペレーションフローを変化させたくない現場層と、成長率・利益率が低かろうとSI事業で何とか食い繋ぎたいベンダの利害一致により、この数年間不健全ながらも現状維持されてきた。
しかし、国内市場が SI 事業という薄氷の上で成立していた状況は AI 革命を伴う聖域なきデジタル市場により淘汰され、2-3 聖域なきデジタル市場におけるデジタル赤字推定シナリオで示したとおり、ベンダサイドから市場の破壊が凄まじい速度で進んでいく。外的な環境変化による市場破壊は、内的に変化を実現できなかったベンダ・ユーザ双方に対して、免疫獲得の猶予を与えないまま、剝き出しのソフトウェア・データの市場原理の中に飲み込むことが想定される。
ちなみに「スマイルカーブ」とは、二次元座標のグラフでX軸の左からバリューチェーンの上流・中流・下流を順に配置し、Y軸に収益率を置いた二次元グラフです。収益率の高いものは上流と下流に集中し、中流は収益率が低くなるため、グラフが谷を描きます。これが「スマイルカーブ」です。 このレポートの図では、企画・開発・設計が上流、営業・マーケティング・カスタマーサクセスが下流、そしてSIや運用保守・ローカライゼーションが中流に置かれています。
SI事業については、肯定派も否定派もどちらも多数存在するでしょうから、無駄な諍いを避ける意味で、ここで切り上げます。
大事な話は、次からです。
ここまで引用した話は、「ソフトウェアが産業競争力の鍵を握る」という話で、情報処理技術者には納得感のある話題だと思います。 しかし、情報処理技術者にとって重要なのは次の引用文です。
そして、データがなければ価値あるソフトウェアが生み出せず、競争力が維持できない、 という「データに全てを飲み込まれる世界」が、聖域なきデジタル市場という現実の競争環境として着実に迫っている。
これまでハードウェアが主役だった産業界で、ハードウェアとソフトウェアの主従逆転が起き、ソフトウェアが主役になる、 というのは情報処理技術者には受け入れ易い話ですが、では「データがなければ価値あるソフトウェアが生み出せない」というのはどういうことでしょうか。
これは正にAIの台頭によって起こっている現象で、「ハードウェアとソフトウェアの主従逆転」が起きているのと同時に「データとソフトウェアの主従逆転」も起きているということです。 従来は、データはソフトウェアの付属物でしかなく、価値を持つのはソフトウェアの方でした。 しかし、現代ではソフトウェアはAIエージェントにより安価に生産できる物になりつつあり、代わりにデータの方が重要な価値を持つようになりつつあります。
コーディングエージェントがどうして短期間に人間のプログラマーを凌駕するほどの性能を得たのかと考えれば、LLMが「膨大なOSSのソースコード」をデータとして学習できた事が原因だと言えます。 優れたAI活用ソフトウェアを開発するには、良質なデータを膨大にAIに学習させる必要があるのです。
AIエージェントの中で、なぜ真っ先にコーディングエージェントが実用化したのかと言えば、OSSのソースコードという良質の無料データが豊富にネット上に存在したからです。
もし、OSSのソースコードのような良質なデータが大量に確保できれば、他の職能分野でもコーディングエージェント並に高性能なAIエージェントが開発できるわけです。 現代、そして将来は、このAIエージェント開発用のデータ資源の取り合いとなることを、このレポートは示しています。
エンタープライズデータ 聖域なきデジタル市場において、データはまさにデジタル産業における原油であり、ソフトウェアの従属変数として存在していたデータが、AI 革命の到来によって、データがソフトウェアを従属するという逆転現象が起き始めている。 すべてのデータ利活用が競争優位性につながる聖域なきデジタル市場において、企業はインターネットで自由に取得できるデータの利活用だけではもはや差別化はできず、今まで企業内で死蔵されていたエンタープライズデータや、それに類するデータを利活用できるかが、ハードウェア中心の世界からソフトウェア中心の世界への移行における競争力の決定要因となるであろう。
AIエージェントとは、LLMと従来型アルゴリズムと独自データを組み合わせて構築されたソフトウェアで、LLM(AI)だけで作られているものではなく、従来型IT（アルゴリズムとデータ）もその構成要素に含まれています。
LLMそれ自体の開発は、OpenAI、Anthropic、Google などには対抗できません。対抗できるのは中国だけでしょう。そして中国は日本にとって安全保障上の脅威であり、安心して依存できる相手ではありません。 しかし、LLM自体を開発できなくても、AIエージェントの従来型アルゴリズムと独自データの部分は、日本企業にも開発できます。 つまり、LLMは作れなくても、AIエージェントは作れます。（LLMはエンジンのように部品として使用します）
LLMの学習に使用できる大量データを確保し、且つ自社内で囲い込むことができれば、そのデータを使用したAIエージェントの開発で優位性が確保できます。
独自データさえ他社に取られなければ、独自AIエージェントの開発を独占し優位性を長期間維持することができます。
ここで問題点として、現在の多くの事業会社のように、自社の業務システム開発をSIerに丸投げにしている状況では、自社の重要資産であるエンタープライズデータをSIerを通じて社外に流出させていることになります。 もし、SIerからFDE(Forward Deployed Engineer)などを通じて、社外の外資系プラットフォーマーなどにエンタープライズデータが流れていくと、自社の重要資産データを自ら競合他社へ譲渡しているようなものです。 これでは、敵に塩を送るどころか、原油を送っているようなものです。 データの主導権は自社が握らなければ、AIエージェント活用で優位性は維持できません。 データはソフトウェアを通じて管理するものなので、日本の事業会社はソフトウェアの主導権を取り戻すべきなのでしょう。 経産省がシステム内製化を強く推すのも、理解できます。
これまで、ソフトウェア開発は優秀な情報処理技術者を高給で多数確保することによって、競争力を確保する時代だったのが、AIエージェントの台頭により、ソフトウェア自体の開発単価は下がり、ソフトウェアそれ自体の価値は大幅に低下することになります。
しかし、同じくAIの影響によりソフトウェアの需要はさらに拡大することになります。 従来扱えなかったデータを扱えるようになり、従来できなかったことができるようになるからです。 例えば、音声や視覚情報など、RDBで扱えなかった非構造化データの数々が使用できるようになり、顔認証や音声視覚認識の仕事ができるようになります。 オフィスの中だけだったITシステムが屋外でも活躍するようにもなるでしょう。 既に重機の操作をAIやリモートで行うようになってきています。
ここに「価格が下がると需要が増える」という市場メカニズムの性質も働きます。
AIによる生産性向上で供給が増えるが、AIが原因で需要も増えることになります。 つまり、AIによりマクロな雇用が失われる心配は無いと思います。（ミクロは別の話です）
ソフトウェアは他社と同じ物をコーディングエージェントにより比較的簡単に開発できるようになったが故に、ソフトウェアだけで付加価値を確保することが難しくなり、付加価値の高いソフトウェアを開発するためには、大量のデータが必要になります。 その大量のデータを確保するには、何らかのソフトウェア・プラットフォームが必要になるわけです。
つまり、今後重要になってくるのは、ビジネス的にはデータ確保の為のプラットフォームビジネスであり、技術的にはデータエンジニアリングということになると思います。
そして、確保した膨大なデータを使用して付加価値の高いAIエージェントを開発して、ソフトウェアによりユーザーに自社の製品やサービスを販売して、労務費を掛けず電気代だけで収益を上げる。 これがAI時代の国際競争になるということです。
「労務費を掛けず」と言っても、AIに物理的身体は無く、ロボット開発も時間が掛かるでしょうから、人間にしかできない仕事は簡単には無くならないでしょう。人が不要になることは、少なくとも2040年までは考えなくて良いと思います。
以上、「2040年の就業構造推計」と「デジタル経済レポート」に描かれたITとAIを中心とした産業の将来像の部分だけを、レポートの引用を中心に記述してみました。
AIエージェント時代に予想される将来の変化を、以下にまとめてみます。
ここからは、私の個人的意見ですが、
「コーディングエージェントによりITエンジニアの仕事が無くなる」とネットではよく聞かれる言説ですが、変化の本質からはかけ離れた話にしか聞こえません。
コーディングエージェントにより従来型の開発の仕事は減ることになりますが、同時にAIを使用した仕事が増えているのも現実です。 また、アーキテクチャ設計も、まだしばらくコーディングエージェントには無理なので、人間の仕事でしょう。
また、経産省のレポートにあるように、ITエンジニアに要求されるスキルの重心がAIやデータスキルへ移行していくだけで、人材需要は2040年になっても、依然として大きいことが予想されています。（ロボティクスやフィジカルAIの需要は新規拡大しそうです）
仕事がなくなる心配は、見当違いな心配だと思います。
特に、SIer業界などで DBMS や RDB や NoSQL などを扱っているデータベースエンジニアなどは、AIエージェント時代に必要とされるデータエンジニアリングに一番近い位置に立っているわけですから、新しいデータベース（ベクトルデータベースなど）のスキルを追加していくことになるだけでしょう。他の適任者はいないわけですし。
今後は、多様な構造化・非構造化データをまとめて操作・管理する技術者が必要なので、データベースエンジニアの需要が減ることはないでしょう。（要求される技術範囲は倍増するかもしれませんが）
ネットワークエンジニアはセキュリティ分野で必要ですし、バックエンド系はAIエージェントの構築で需要が伸びると思います。
需要が減りそうなのはGUIアプリなどフロントエンド系ぐらいではないでしょうか。
基本的に開発はコーディングエージェントで自動化されるので、情報処理技術者の仕事は設計と検収を中心としたものに移行しそうではあります。
SIerが安泰とは思いませんが、SIerで働いている情報処理技術者は、他の会社（主に事業会社）の需要が増えると思います。
変な不安に囚われている人々は、SNSや雑な報道に振り回されて混乱しているだけなので、経産省のレポートを熟読して、将来に備えた方が良いと思います。
将来の「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月上旬にはリリースしています。
元々、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駆動開発の研究手段として続けていくことになります。
コマンドツールやコマンドレットの他に、非公開で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エージェントの可能性について、記事に書いてみました。
時々、こういう経験・体験に基づく「雑感」のような記事も書いていくので、よろしくお願いします。
]]>これまで提供していた バージョン 1.0.2 では、Resolve-Encodingによる文字エンコーディングの検出だけしかできませんでした。
今回リリースしたバージョン 1.1.0 では、Windows PowerShell 5.1 と PowerShell 7.x.x の双方において、文字エンコーディングを自動検出した後に、閲覧・編集・追記ができるようになりました。
具体的には以下のコマンドレットを追加しました。
Get-ProbedContent : テキストファイルの文字エンコーディングを検出して表示する。
Set-ProbedContent : 指定テキストファイル（隣接ファイルなど）の文字エンコーディングを検出して出力する。
Add-ProbedContent : 指定テキストファイル（追記対象など）の文字エンコーディングを検出して追記する。
ConvertTo-DotNetEncoding : 文字エンコーディングを指定して、System.Text.Encoding オブジェクトを作成する。
詳細は、以下の固定ページで解説しています。
SnowStack.EncodingProbe.PowerShell 1.1.0 新コマンド解説
また、NuGet パッケージの EncodingProbe 1.1.0 も同時にリリースしています。こちらは機能の変更は無く、参照している UTF.UnknownのUpgradeに対応したことにより、リビルドして再リリースしました。
NuGet パッケージとPowerShellコマンドレットの機能説明は既に6月のプレリリース時点で、固定ページで公開しております。
インストール方法や使い方については、こちらの固定ページをご覧下さい。
]]>当サイトで公開している文字エンコーディング関連のツールおよびクラスライブラリは、UTF.Unknown という海外製の NuGet パッケージを参照しています。
該当する製品は以下のとおりです。
つまり、当サイトから提供しているほとんどの OSS 製品が該当します。
これまで、この UTF.Unknown のライセンスを MIT ライセンス として説明・表記してきましたが、これは私の誤りでした。正しくは以下のライセンス規定になります。
UTF.Unknown
https://github.com/CharsetDetector/UTF-unknown
UTF.Unknown is subject to the Mozilla Public License Version 1.1
(the "License"). Alternatively, it may be used under the terms of
either the GNU General Public License Version 2 or later (the "GPL"),
or the GNU Lesser General Public License Version 2.1 or later
(the "LGPL").
You may obtain a copy of the Mozilla Public License Version 1.1 at
https://www.mozilla.org/MPL/1.1/
日本語で言えば、Mozilla Public License 1.1 / GPL 2 以降 / LGPL 2.1 以降の三重ライセンスです。利用者はこの3つの中から1つを選んで利用できます。
誤った情報を長期間にわたって公開し続けてしまいましたことを、深くお詫び申し上げます。
UTF.Unknown のライセンスについての説明を、正しい内容に修正しました。snow-stack.net の該当箇所の記事は修正済みです。
各ツールのライセンス表示も修正した上で、最新モジュールのバージョン 1.1.1.0 をリリースしました。
機能面は前バージョンの 1.1.0.0 と変わっていません。-v オプションで表示するライセンス表示の内容のみを変更しています。
SnowStack.EncodingProbe および SnowStack.EncodingProbe.PowerShell についても、パッケージに同梱するサードパーティライセンス通知を修正しています。
ライセンス表示を修正した上で、UTF.Unknown のライセンスについて改めて解説したいと思います。ライセンスの誤りをお詫びするだけでなく、正しく理解していただくための情報をお伝えするのが筋だと考えるためです。
UTF.Unknown は、Mozilla Universal Charset Detector の系譜にあるライブラリです。Mozilla のコードを起源としているため、Mozilla が古くから採用してきた三重ライセンスをそのまま引き継いでいます。
このうち中心となるのが Mozilla Public License 1.1（MPL 1.1） です。MPL 1.1 は、1998年に Netscape がブラウザのソースコードを公開する際、「ソースは公開させたいが、企業が商用製品に組み込むことも許したい」という相反する要求を両立させるために設計されました。
その答えが ファイル単位のコピーレフト という考え方です。
MPL 1.1 の義務が及ぶのは「Covered Code」、つまり元々 MPL が付されたソースファイルと、それに対する改変だけです。それらのファイルを改変した場合は MPL のまま公開する義務が生じますが、自分で新しく書いたファイルには義務が及びません。
GPL が派生著作物の全体に伝播するのとは、ここが決定的に違います。
MPL 1.1 の主な義務を整理すると、次のようになります。
| 条項 | 内容 |
|---|---|
| 第3.1条 | 改変した Covered Code は MPL のまま維持する |
| 第3.2条 | ソースコードを入手可能な状態にしておく |
| 第3.3条 | 改変した場合、変更日時と内容を記録する |
| 第3.5条 | 著作権表示・ライセンス表示を除去しない |
| 第3.6条 | 実行形式には別のライセンスを付けてよいが、ソースの入手方法を明示する |
| 第3.7条 | 独自コードと組み合わせた全体は、独自部分について自由なライセンスにできる |
なお、GitHub のリポジトリを見てもライセンスが自動判定されないのは、ルートに LICENSE ファイルが無く license/ ディレクトリに複数のライセンス文書が格納されているためです。私が誤解した一因もここにありました。とはいえ README には明記されており、確認を怠った私の落ち度です。
一方、当サイトが提供する以下の製品は、これまでどおり MIT ライセンス です。ここは変更ありません。
MIT ライセンスは、著作権表示とライセンス文を残すことだけを条件に、使用・複製・改変・再配布・商用利用・プロプライエタリ製品への組み込みまで、ほぼ無制限に認めるライセンスです。コピーレフトはありません。
「MPL 1.1 のライブラリを使っているのに、本体が MIT なのはおかしいのでは」と思われるかもしれません。ここが MPL 1.1 を理解する上で最も重要なポイントです。
当サイトの各ツールは、UTF.Unknown を NuGet パッケージのまま、一切改変せずに参照 しています。ソースコードを取り込んだり、書き換えたりはしていません。
この場合、
という整理になります。
MPL 1.1 が「ファイル単位」であることの実務的な意味が、まさにここに表れています。仮にこれが GPL のライブラリであれば、当方のツール全体が GPL になり、MIT で提供することはできませんでした。
当方に残る義務は、実質的に次の2点だけです。
今回の誤りは、まさにこの1点目に反していた ことになります。
| 本体（EncodingProbe など） | UTF.Unknown | |
|---|---|---|
| ライセンス | MIT | MPL 1.1 / GPL 2+ / LGPL 2.1+ |
| コピーレフト | なし | ファイル単位（弱いコピーレフト） |
| 改変ファイルの公開義務 | なし | あり |
| ソース入手可能性の保証 | 不要 | 必要 |
| 特許の明示的許諾 | なし | あり（MPL 1.1） |
| ライセンス終了条項 | なし | あり |
同じパッケージの中に、条件の異なる2つのライセンスが同居している。それが実態です。
ここが本記事で最もお伝えしたい部分です。
当方のツールやライブラリを組み込んで製品やサービスを配布されている場合、その配布物には UTF.Unknown が含まれています。したがって、MPL 1.1 の義務が皆様にも及びます。
これまで「依存関係はすべて MIT」という前提で管理されていた場合、意図せず MPL 1.1 の表示義務を果たしていない状態になっている可能性があります。誤った情報をお伝えしたことが原因であり、重ねてお詫びいたします。
一方、以下のケースでは実質的な影響はありません。
配布を行っている場合、以下をご確認ください。
1. 最新版へのアップデート
各製品の 1.1.1.0 以降（SnowStack.EncodingProbe は最新版）にアップデートしてください。機能変更はありませんので、動作への影響はありません。修正済みのライセンス通知が同梱されます。
2. 自社製品のライセンス通知の修正
THIRD-PARTY-NOTICES.txt や、それに相当するライセンス一覧に UTF.Unknown を MIT として記載されている場合は、修正をお願いします。記載例は本記事冒頭のとおりです。
3. ソース入手先の明示
UTF.Unknown のソースコード入手先（https://github.com/CharsetDetector/UTF-unknown）を、配布物のどこかに記載してください。バージョン番号も併記しておくと、より確実です。
同じ失敗を繰り返さないために、私自身が今回学んだことを共有します。
今回の誤りの本質は、直接の依存先しか見ていなかった ことです。NuGet は依存パッケージのライセンスを自動的には表示してくれませんし、dotnet list package --include-transitive でパッケージ名は分かってもライセンスまでは出ません。
依存ツリー全体を対象にライセンスを棚卸しする習慣が必要でした。
.NET 環境であれば、nuget-license というツールで依存パッケージのライセンスを機械的に列挙・検証できます。
dotnet tool install --global nuget-license
dotnet restore
nuget-license -i <ソリューションまたはプロジェクト> -t -a "MIT;Apache-2.0;MPL-1.1"
-t オプションが重要です。これを付けないと直接参照しているパッケージしか見ないため、推移的依存に含まれるライブラリを見落とします。今回の私の失敗も、依存ツリー全体を見ていなかったことが原因でした。
-a で許可するライセンスを列挙しておくと、許可リストにないライセンスが混入した時点で検証エラーになります。CI に組み込んでおけば、新しいパッケージを追加した瞬間にビルドが失敗して気づけます。MPL-1.1 を許可リストに明示的に入れておけば、「知らないうちに紛れ込んだ」のではなく「意識して許可した」状態になります。
なお .NET Framework プロジェクトの場合は、dotnet tool 版ではなく GitHub Releases で配布されている NuGetLicenseFramework.exe が必要になることがあります。また、dotnet-project-licenses という旧名のパッケージも NuGet 上に残っていますが、現在メンテナンスが続いているのは nuget-license のほうです。
GitHub の画面右側に表示されるライセンス名は、ルートの LICENSE ファイルを自動判定した結果です。UTF.Unknown のようにディレクトリに格納されている場合、判定されずに空欄になります。
空欄だったときこそ、README とリポジトリ内を丁寧に確認すべきでした。
前述の nuget-license を使っていれば気づけた可能性は高いのですが、このツールも万能ではありません。
ライセンス情報の取得元は NuGet パッケージのメタデータ（.nuspec）です。古いパッケージでは非推奨の licenseUrl しか設定されておらず、SPDX 識別子が入っていないことがあります。その場合、出力には URL だけが並び、ライセンス種別は判定できません。リンク自体が切れている場合もあります。
つまり、出力に「Unknown」や生の URL が現れたら、そこは自分で調べろというサインです。ツールは見落としを検出してくれますが、見落としを自動で正しく解釈してくれるわけではありません。最終的には上流のリポジトリで確認するのが確実です。
MPL / GPL / LGPL のような複数ライセンスの場合、どれを選択したかを明示しておくと、下流の開発者が判断しやすくなります。当方は MPL 1.1 を選択した旨を通知に記載しました。
このたびは、誤ったライセンス情報を長期にわたって公開し、ご利用の皆様にご迷惑をおかけしましたことを、改めて深くお詫び申し上げます。
なお、本記事はライセンスに関する私の理解を述べたものであり、法的助言ではありません。商用配布などで厳密な判断が必要な場合は、専門家にご確認くださいますようお願いいたします。
ご不明な点がありましたら、各リポジトリの Issue よりお問い合わせください。
]]>先日、winget および dotnet tool (NuGet.org) の配布サイトから、mfprobe と mfsr の Version 1.1.0.0 をリリースしました。
dotnet tool からのリリースは、一足早く 2026年8月1日の夕方から公開していたのですが、winget のリリースはMicrosoftの承認を受けなければならないので、リリースに時間がかかってしまいました。
既に、GitHub Release の公開モジュールは、以下から提供済みです。(winget から提供しているモジュールもこのモジュールです)
コマンドの使い方解説は、以下にあります。
rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説
大きな外部仕様の変更や新機能追加はありません。
基本的な変更点は、内部構造の変更です。
ただし、mfprobe の検索オプションには、後述する小さな機能改良を加えています。
従来、mfprobe と mfsr は文字エンコーディング・改行コード・BOMの有無の解析を、独自に実装してコマンドモジュールに内蔵していました。
この内蔵モジュールを少し前にリリースした SnowStack.EncodingProbe に入れ替えました。
SnowStack.EncodingProbe NuGet Package 解説
Version 1.1.0.0 では、mfprobe と mfsr の文字エンコーディング解析モジュールは、SnowStack.EncodingProbe.PowerShell と同じモジュールを使用しています。
Resolve-Encoding コマンドレットと mfprobe の解析結果は、同じになります。
SnowStack.EncodingProbe.PowerShell 解説
微細な機能変更はあります。
まず、韓国語・繁体字中国語・簡体字中国語の解析処理を厳格化しました。以前より解析精度は向上しているはずです。
また、日本語・韓国語・繁体字中国語・簡体字中国語の解析処理において、以下のロジックを適用しました。
バイナリパターン解析の結果、Shift_JIS と EUC-JP のどちらにも該当する結果が出た場合、以下の判定基準を適用します。
IF (テキスト内に改行が存在する) {
IF (改行がWindows型である) {
Shift_JIS と解釈する。
}
ELSE {
EUC-JP と解釈する。
}
}
ELSE {
IF (稼働OSがWindowsである) {
Shift_JIS と解釈する。
}
ELSE {
EUC-JP と解釈する。
}
}
バイナリパターン解析の結果、EUC-KR と CP949 のどちらにも該当する結果が出た場合、CP949と解釈します。
CP949 は EUC-KR を包含します。Windowsユーザーのほとんどは、旧文字エンコーディングを使用する場合、CP949 を使用するはずなので、EUC-KR を返すとかえって利便性を損ないます。
よって、EUC-KR 値を返さない方がユーザーの利益になると判断しました。
EUC-KR に該当する場合は、CP949値を返します。
バイナリパターン解析の結果、EUC-TW と Big5 のどちらにも該当する結果が出た場合、Big5 と解釈します。
文字集合としては、EUC-TW の基になっている CNS 11643 の方が、Big5 より広い範囲をカバーしています。しかし実運用上、Windowsユーザーの旧テキスト資産はほとんどが Big5 (CP950) であり、EUC-TW が使われている例は稀です。
よって、EUC-TW 値を返すよりも Big5 値を返す方が、ユーザーの利益になると判断しました。
EUC-TW に該当する場合は、Big5 値を返します。
台湾で策定された Big5 を元に Windowsで定義された文字エンコーディングが CP950 です。
WindowsとWebの世界では、Big5 と CP950 は同一の文字エンコーディングと解釈されます。
厳密には、両者は規格に少し異なる部分がありますが、Windows環境では CP950 を Big5 と解釈して一般的に運用されています。
SnowStack.EncodingProbe も同様の解釈を適用しています。
現在、Google Chrome や Firefox などのモダンブラウザで charset=big5 と指定した場合、ブラウザ内部では自動的に Windows CP950（またはその拡張版）として解釈されます。
そのため、Webの世界では「Big5 ≒ CP950」として扱われることがほとんどです。
なお、厳密には WHATWG Encoding Standard において、big5 ラベルは HKSCS の拡張分を含むインデックスにマップされます。SnowStack.EncodingProbe の解析処理は、この HKSCS 領域には現時点で未対応です。（後述）
香港の広東語では、その昔 Big5の香港拡張が使用されていました。現在はUTF-8で統一されています。
SnowStack.EncodingProbe は、香港 Big5 には未対応です。
将来的には、対応するつもりでいます。
いつ対応するか、ハッキリとは宣言できません。
申し訳ありません。
中国では、漢字の簡略化が行われ、伝統的な漢字である繁体字とは異なる簡体字を公用文字として使用しています。
中国語の文字エンコーディングは古い順に、GB2312 → GBK (CP936) → GB18030 という種類が存在します。
これらの規格は、新しい方が古い規格を包含する規格になっており、原理的に「GB2312 は GBK にも GB18030 にも該当する」ことになります。
よって、GB2312 と GBK と GB18030 の全てに該当するテキストは存在し、それが三つのどれなのかはテキスト単体では区別できません。
Windows環境では、Unicode時代に入る前には GBK (CP936) を標準文字エンコーディングとして使用していたので、Windowsユーザーの古いテキスト資産は、ほとんど GBK (CP936) で書かれていることになります。
現在、中華人民共和国の民間人は、世界の人々と同様にほとんど UTF-8 を使用しています。
UTF-8 が普及する前は、GBK (CP936) を使用していました。
GB18030 は中華人民共和国の強制性国家標準であり、中国国内で販売される OS やソフトウェアには対応が義務付けられています。ただし、実際に GB18030 固有の領域まで使用するのは行政機関などが中心で、民間ユーザーが保存したテキストが GB18030 でしか解釈できないケースは稀です。
よって、SnowStack.EncodingProbe は、バイナリパターン解析の結果として、GB2312 と GBK (CP936) と GB18030 の何れにも該当する場合、GBK (CP936) と解釈します。
確率的に GBK (CP936) と解釈するのが、一番ユーザーの利益になると思われるためです。
なお、GB18030 としか解釈できないテキストが存在すれば、GB18030 と結果を返します。
GB2312 という解析結果が返ることはありません。
Unicode (UTF-8) がWindows環境の標準になる以前は、日本では Shift_JIS (CP932) が、韓国では CP949 が、台湾では Big5 (CP950) が、中国では GBK (CP936) が、Windowsの標準文字エンコーディングでした。
よく問題になる Excel で CSVファイルを読み込んだときに文字化けする問題も、日本・韓国・台湾・中国で同じような問題を抱えています。
日本では、Windows環境のCSVの標準は Shift_JIS (CP932) であり、UTF-8ならBOMが付いていなければなりません。
韓国では、Windows環境のCSVの標準は CP949 であり、UTF-8ならBOMが付いていなければなりません。
台湾では、Windows環境のCSVの標準は Big5 (CP950) であり、UTF-8ならBOMが付いていなければなりません。
中国では、Windows環境のCSVの標準は GBK (CP936) であり、UTF-8ならBOMが付いていなければなりません。
（Microsoft 365 版の Excel では、BOM の無い UTF-8 の CSV を正しく読み込める場合もありますが、環境やバージョンに依存するため、確実性を求めるなら BOM を付けるのが無難です）
つまり、東アジア漢字文化圏では、文字エンコーディングの実装方法が似通っており、同じような文字化け問題を抱えていることになります。
旧文字エンコーディングでマルチバイト文字エンコーディングを使用していたのも、東アジア漢字文化圏特有の仕様であり、Unicode以前は、他の国々はシングルバイト文字エンコーディングを使用していました。
（ベトナムは漢字を廃してラテン文字表記に移行したため、Unicode 以前の文字エンコーディングも TCVN3 や VISCII などのシングルバイト系が中心でした。IT化の開始が他国より遅く、早い段階から Unicode に移行したこともあり、CJK のような古い文字コード問題はあまり抱えていません）
よって、文字エンコーディングのバイナリ解析処理も、東アジア漢字文化圏で必要になる解析処理と、シングルバイト文字エンコーディングを解析する処理とでは、異なってきます。
東アジア漢字文化圏の旧文字エンコーディング解析処理を、SnowStack.EncodingProbe で独自実装して、シングルバイト文字エンコーディングの解析処理を海外製の UTF.Unknown に任せているのも、このような東アジア漢字文化圏特有の事情に対応するためです。
文字エンコーディングの解析処理以外に、mfprobe の文字列検索処理に少し機能修正を行いました。
mfprobe の /s オプションで検索キーワードを記述した検索文字列リストを指定して、複数文字列の一括検索ができます。
mfprobe /s:slist.txt *.txt
この検索文字列リストの中には、これまで一行ごとに検索文字列一つを記述することしかできませんでした。
一方、mfsr では /r オプションで、置換単語リストCSVを指定して、複数文字列の一括置換を実行できました。
mfsr /r:rlist.txt *.txt
元々、mfprobe コマンドは、mfsr で置換する前に、置換対象となるテキストファイルがどれなのか確認する為に作成したコマンドです。
/r:rlist.txt で指定した置換単語リストCSVの左端カラムで指定した文字列と、同じ文字列を/s:slist.txt で指定することになります。
実作業としては、置換単語リストCSVの左端カラムだけを、別の slist.txt にコピーして検索文字列リストを別途作成しなければなりません。
これは単純に無駄な二度手間なので、/r:rlist.txt で指定する予定の置換単語リストCSVを、そのまま/s:rlist.txt という風に指定できるように、mfprobe を改造しました。
mfprobe /s:rlist.txt *.txt
mfsr /r:rlist.txt *.txt
これで、rlist.txt を、mfprobe の /s オプションと、mfsr の /r オプションの両方で共用できます。
mfprobe 側では、rlist.txt の中にカンマが存在する場合は、左端のカラムだけを読み込み検索するように作っています。
従来と同じ使い方も可能です。
mfprobe 1.0.5.0 には、/s オプションを使用した検索処理に、一部の検索ができない不具合がありました。
この不具合は、1.1.0.0 で解消しました。
気がつかなくて申し訳ないです。
（後述の txprobe 1.0.5.0 には、この不具合は存在しません）
mfprobe・mfsr Version 1.1.0.0 と同様の改造を行った、txprobe・rmsmf の Version 1.1.0.0 も以下のサイトからリリースしています。
こちらは、rmsmf-suite-v1.1.0.0.zip をダウンロードして、ZIPファイルを解凍し、その中のファイル全てを、環境変数 PATH の通ったフォルダーにコピーしてください。
.NET Framework 4.8 のある環境なら、これで起動します。
txprobe・rmsmf は、winget や dotnet tool では、提供していません。
ご了承ください。
これまで、mfprobe・mfsr・txprobe・rmsmf のどれも日本以外の東アジア漢字文化圏の文字エンコーディングの解析処理が不完全な状態で提供していました。
韓国、台湾、中国の旧文字エンコーディングの解析処理のことです。
これらの国の文字エンコーディングの解析処理は、一応可能ではあったのですが、先に解説した「二つの文字エンコーディングの両方に該当する」パターンへの対処方法が定まっておらず、韓国・台湾・中国のテストコードは保留のままスキップして提供していました。
何度も解説していますように、文字エンコーディングの解析処理を、完璧に行うことは不可能です。
日本語でも Shift_JIS と EUC-JP の両方に該当するバイナリパターンは存在するので、この場合はバイナリパターン解析だけで文字エンコーディングを識別することは、できません。
よって、カルチャーやOSの種類など、文字エンコーディング以外の要素も判断材料として活用して、どうしても識別できないバイナリパターンの場合は、使用されている確率の高い文字エンコーディングを選択する仕様にしました。
これ以上の精度で文字エンコーディングの解析処理をするのは、私には難しいと思います。
最初に、mfprobe・mfsr をリリースしてから、約半年も経ちましたが、ここまで来るのに地味に苦労しました。
文字エンコーディングの解析処理と、それらをNuGetパッケージにして共有できるようにすること、PowerShellコマンドレットで提供すること、CJK圏のどこでも使用できるようにすること、どれも結構難しかったです。
開発自体は、GitHub Copilot や Claude Code が使用できるようになったので、後になるほど楽になってきましたが、NuGet パッケージやPowerShellコマンドレットに関しては、仕様策定に苦労しました。テストもAI任せではどうしても抜け漏れが生じてしまい、 自分で確認しなければならない部分も少なくないのが、AIを使用した開発の現実でした。
ようやく、目指していた水準の機能と品質に到達したので、これから提供記事などに、もっと力を入れていきたいと思います。
ちなみに、これらのコマンドは、ヘルプメッセージこそ英語・日本語・韓国語・繁体字中国語・簡体字中国語でしか表示していませんが、文字エンコーディングの解析処理には独自実装だけでなく、UTF.Unknown を使用しているので、UTF.Unknown が対応している全ての国々で使用できます。
日本・韓国・繁体字中国語圏・簡体字中国語圏以外のカルチャーの場合は、全てのメッセージが英語になります。
OSのカルチャーで自動的に表示言語を切り替えているのです。
このブログは日本語でしか書いていませんが、是非他の国々の方々も、ご利用ください。
MITライセンスなので、保証はありませんが、商用・非商用どちらでも無料です。
]]>2026年6月6日から固定ページでプレリリース版の告知は行っていましたが、オープンソース製品として完成水準に到達し正式版として提供開始したので、ブログで改めて告知します。
今回提供開始した SnowStack.EncodingProbe とは、
PowerShell環境や.NETとWindowsアプリの開発において、Shift_JIS, UTF-8, UTF-16LEなどの文字エンコーディングの混在問題の解決のために開発した NuGetパッケージとPowerShellコマンドレットです。
以前から提供している mfprobe, mfsr というコマンドツールに内蔵されていた文字エンコーディング検出処理を、クラスライブラリとして切り出し、NuGet パッケージとして一般提供したものです。
また、その NuGet パッケージを使用して PowerShell コマンドとして文字エンコーディング検出を行う事が可能なコマンドレットも同梱しています。
このコマンドレットを使用するとPowerShellスクリプト（*.ps1）の中でテキストファイルの文字エンコーディング検出が可能になります。
前者のクラスライブラリは、パッケージ名 SnowStack.EncodingProbe として NuGet.org より提供しています。
後者のコマンドレットは、パッケージ名 SnowStack.EncodingProbe.PowerShell として PowerShell Gallery より提供しています。
両者は、同一のソリューションに纏めており、一つの GitHub リポジトリでオープンソース・ソフトウェアとして提供しています。
以下のコマンドでソースのダウンロードが可能です。
git clone https://github.com/motoi-tsushima/SnowStack.EncodingProbe
ライセンスは MITライセンスです。
NuGet パッケージとPowerShellコマンドレットの機能説明は既に6月のプレリリース時点で、固定ページで公開しております。
インストール方法や使い方については、こちらの固定ページをご覧下さい。
SnowStack.EncodingProbe NuGet Package 解説
SnowStack.EncodingProbe.PowerShell 解説
バージョン 1.0.0 の開発をしていく過程で、PowerShellの Get-Content コマンドなどの -Encoding オプションに使用される文字エンコーディング・フレンドリ名が、PowerShellのバージョンによって大きく異なることがわかりました。
また、Resolve-Encoding をユーザーが使いこなすには、フレンドリ名の知識が必要になると思います。
まず、文字エンコーディング・フレンドリ名がどのようなものなのか、解説記事を提供する必要があります。
また、.NETをよく知らないユーザーのために、.NET Framework と .NET(Core) の違いや、Windows PowerShell5.1 と PowerShell6.2以降(最新は7.6.x) の違いを把握してもらう必要があります。
今後は、まずこれらの必須知識の解説記事をブログに書いて公開するつもりです。（これらは単純な公開知識なので、AIを積極活用するつもりです）
また、Windows PowerShell5.1 は旧式PowerShellでありながら、Windows標準搭載のShellでもあるため、多くのユーザーにとって標準の環境でもあります。
この旧型PowerShellは、UTF-16LE を標準文字エンコーディングとしており、BOM無しUnicodeを扱えません。
しかし、現在のWindows環境ではGitやWSLが使用可能で、必然的にBOM無しのUTF-8テキストファイルが混在します。
Windows PowerShell5.1 上でも、BOM無しのUTF-8テキストファイル等、幅広い文字エンコーディングを扱う必要があります。
今後、SnowStack.EncodingProbe.PowerShell では、次のバージョン 1.1.0 で、これらの問題に対処する機能を開発する予定です。
ご報告まで。
SnowStack は、GitHubで公開しているソフトウェアの補助的な解説用のWebサイトです。
このブログは、どちらかと言えば「固定ページ」中心に運営しているので、ブログ部分は補助的な解説記事ぐらいしか書いていません。更新ペースが遅いのもそのような運用方針だからです。
ご了承ください。
]]>.NET 10 の画面有りアーキテクチャの解説とサンプルコード
（2026年4月25日、Avalonia UI の解説とサンプルを追記しました）
（2026年5月9日、Avalonia UI のライセンスの解説記事を公開しました）
この記事とサンプルコードを作成した理由としては、.NET はその内容をよく誤解されることが多く、誤解を解消する上で、分かりやすい解説と具体的なサンプルプログラムを見せる必要があると考えたからです。
「.NET の誤解」の例としては、以下の様な物があります。
「.NET は Windows でしか動かない」
「ASP.NET は一つの技術である」「ASP.NET が使える（開発経験がある）」
「C# は C/C++ 系の開発言語である」
等々は、代表的なものです。 「Java と javascript の違いが分からない」と同じようなものです。
ITシステム開発の現場には、ITエンジニアだけが携わっているわけではなく、業務担当者や営業担当などITエンジニアではない人々も多く関わっていますから、こういう誤解は無くなりません。
ただ、説明しなければ誤解も無くならないので、このネット記事のような媒体で地道に解説していくしかありません。
上記の誤解について簡単に解説すると以下のようになります。
.NET には 旧 .NET Framework と 最新の .NET(Core) の二種類があり、Windows でしか動作しないのは、旧 .NET Framework だけであり、最新の .NET(Core) は Windows だけではなく、macOS,Linux,iOS,Android で動作します。 .NET 10 は、.NET(Core) です。
.NET 系の求人には「ASP.NETの開発経験がある」という条件をよく見かけますし、IT人材系の営業職の人々も「ASP.NET は一つの技術である」「ASP.NETの開発経験があれば、ASP.NETは全て扱える」という認識の人々が圧倒的に多数派です。
この認識は、かなり大雑把すぎて、ほぼ間違っており、様々なトラブルの原因になっています。
この種類の誤解を解消したかったのも、サンプルプログラムと解説記事を公開した理由の一つです。
「.NET 10 の画面有りアーキテクチャの解説とサンプルコード」を読んで頂ければ分かりますが、ASP.NETとはMicrosoft が .NET技術で提供するWeb技術全般に付けているブランド名であり、ASP.NETブランドの中に様々な技術製品やアーキテクチャが提供されています。
つまり、「ASP.NET は一つの技術である」という認識は間違いであり、「ASP.NETの中に様々な技術製品が存在する」のが真実です。
ざっくりと例を挙げると、ASP.NET WebForms , ASP.NET Core MVC , ASP.NET Core Razor Pages , ASP.NET Core Web API , ASP.NET Core gRPC Service , ASP.NET Minimal API といった技術製品が提供されています。
これらの解説は、「.NET 10 の画面有りアーキテクチャの解説とサンプルコード」の中に書いているので、ここでは解説しません。
例えば、ASP.NET WebForms の開発経験のある人材は、ASP.NET Core MVC や ASP.NET Core Razor Pages を扱う事はできません。逆も同様です。 （ASP.NET WebForms は、旧.NET Framework の技術で既に廃止されております。Core と付く物は全て .NET (Core) の技術です）
ASP.NET Core Web API の開発経験のある人も ASP.NET Core gRPC Service は簡単には扱えないでしょう。
IT人材の募集を行う方は、ASP.NET の中のどの技術の開発経験を求めるのか、具体的に記載した方が良いですし、営業や管理職の方々も、そのぐらいの認識は持っておくべきだと思います。
この手の疑問は、生成AIに質問すれば分かる事なので、そろそろ調べておくべきでしょう。
様々なトラブルの原因は、技術を要求する側の雑な認識の方にあるケースが少なくないのです。
これは「Java と javascript の違いが分からない」人々と同様の人々ですね。
C# は、CLR という .NET の仮想環境で動作するマネージドコードを主に開発するために作られた開発言語であり、その位置づけや機能特性は、Java に似た物になります。CLR は JavaVM に相当する VM（仮想マシン）です。
C言語やC++は、ネイティブコードを生成する開発言語なので、C#とは似ても似つかぬ言語です。
現代の開発言語は全て、C言語とC++を祖先として、言語の文法などを作成しているので、C#もC言語とC++を祖先としていますが、それならば Java も PHP も Go も Python もC言語とC++由来の言語と言えます。
「C#がC言語やC++系統の言語である」という認識に、正当性を見いだすのは難しいです。 無駄に誤解とトラブルを招くだけで、有害な認識だと思います。
ここでは .NET の話だけを挙げましたが、他の技術でも同様の誤解が蔓延していると思います。
いちいち例を挙げても切りが無いので挙げませんが、「Swift と SwiftUI を混同している」とか「Git と GitHub を混同している」とか「WSL と Git Bash を混同している」とか、たくさんあるでしょう。
最近広まりつつある Blazor では、Razorコンポーネントがありますが、これを ASP.NET の Razorページと混同する人もこれから増えていくでしょう。
これらの誤解は、誤解する方も悪いですが、説明しない方の責任もあるので、ブログ記事などで地道に解説記事を書いておくのが、誤解を払拭する最低限の努力と言えるでしょう。
解説がない状況では、誤解する者を批判することも、正当性の面で苦しくなります。
サンプルコードの使い方は、「.NET 10 の画面有りアーキテクチャの解説とサンプルコード」の中で必要最小限書いてあります。
GitHub リポジトリのサンプルコードの README.md など、まだぜんぜん書いていませんが、これから少しずつ書いていくつもりです。
最小限、解説記事とサンプルコードだけ完成した時点で公開しています。今後も細部の修正は行いますので、ご了承ください。
リリースや配布の機能は作っていないので、現状では IDE でソリューションを開いて起動するしかありません。
GitHub リポジトリのサンプルコード IssueBoard にはライセンスの記載がありませんが、全て MITライセンス とお考えください。
詳細は、後日 README.md などに書いていくつもりです。
今は、この記事で暫定的に「IssueBoard は MITライセンスである」と宣言しておきます。
MITライセンスは、このプログラムを利用・再配布する場合、著作権表示とライセンス条文を、ソフトウェアの複製または実質的部分に含めることを義務づけるライセンスです。また、本ソフトウェアは無保証であり、利用者の自己責任で使用することに合意することが求められます。
この条件を受け入れることを要求するライセンス規定です。
これは、私だけでは無く、世界の MITライセンス 全てに当てはまる条件なので、覚えておいてください。
商用利用は制限されませんが、利用者の自己責任での利用が求められます。
以上、お知らせでした。
]]>先日、Windows 版は winget によるリリースを開始し、Windows標準の winget install コマンドで、簡単に mfsr と mfprobe をインストールできるようになりました。
rmsmf と txprobe は、これまでと同じで .zip ファイルでのインストールする方式のままです。
私としては、.NET Framework 4.8 でビルドしている rmsmf と txprobe よりも、.NET10 でビルドしている mfsr と mfprobe を極力使用して頂きたいので、このようにしました。
元々、.NET10 で開発していますから、macOS と Linux OS でもリリースすれば動作するように開発しています。
しかし、これまでは Mac と Linux へのリリース手段を提供していませんでした。
リリースに時間がかかった理由として、macOS と Linux OS はCPUの種類やカーネルのバージョンなどの種類が多く、各種の環境に合わせたネイティブコードでのリリースが困難になるため、どのようなリリース方法が良いか判断に迷ったからです。
Windows版は、Native AOT によりネイティブコードでリリースしています。 winget でインストールする mfsr と mfprobe はネイティブコード版です。
今回、macOS と Linux OS に対しては、.NET10 のマネージドコードのアセンブリで提供することにしました。
マネージドコードの実行には .NET10 の Runtime（ランタイム） が必要になります。
しかし、.NET10 Runtime が、CPUの違いやカーネル・glibc などの違いを吸収してくれるので、OS に .NET10 Runtime さえインストールされていれば、どこの環境でも稼働するメリットがあります。
Mac には、インテルCPU版・Apple Silicon版・A18 Pro版と三種類のCPUがあり、macOSのバージョンも新旧でいくつか並行して提供されています。
Linuxはディストリビューションが多数ありカーネルやglibcのバージョンも多数並行して提供されています。
これら全てにネイティブコードを提供することは、難しいと思います。
これらの違いは、 .NET10 Runtime に吸収してもらい、mfsr と mfprobe は Runtime だけに合わせる形式での提供が、一番効率が良く信頼性も高いと考えました。
Windows版のネイティブコードは、winget で提供していますが、macOS と Linux OS へのマネージドコードでの提供は、nuget.org で提供しています。
インストールには dotnet コマンドで dotnet tool install によってインストールします。
マネージドコードでの提供でお気づきの方もいると思いますが、nuget.org でのマネージドコードでの提供は、Windowsでもインストールすることが可能です。 つまり、Windowsでは winget 提供のネイティブコード版と、nuget.org 提供のマネージドコード版の二種類を提供していることになります。
私としては、Windows ではネイティブコード版を利用して欲しいと考えいますが、マネージドコード版もWindowsで同様に動作します。
正直なところ、どちらを使っても違いはほとんど無いです。
違いはマネージドコード版には .NET Runtime が必要なことぐらいです。 好きな方を利用してください。
なお、環境変数 Path の関係で両方使用することはできないと思います。
winget install でも dotnet tool install でも、事前に mfsr と mfprobe の .zip ファイルのダウンロードは必要無いです。
それぞれのコマンドを実行すればインストールできます。
具体的なインストール方法については、以下のページで解説しています。
使い方の解説は、以前から紹介していますように、以下の二つのページで解説しています。
rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説
PowerShellの文字エンコーディング問題に終止符を打つ：BOM・改行コードを自在に扱う方法
以上、「お知らせ」でした。
]]>