AIさん、コードは任せた!……あれ、仕事も?
Image created by ChatGPT
50万件のソート
実際にあった話。
Bukken というデータクラスがあり、その List をソートする要件があったのですが、データは50万件。
ソートだけで10秒かかってしまうので、高速化する必要がありました。
public class Bukken
{
public string CodeTown { get; set; }
public int Page { get; set; }
public int Floor { get; set; }
public int TotalCost { get; set; }
public decimal RoomSize { get; set; }
}
List<Bukken> bukkens;
// 50万件のデータ
bukkens.Sort(
(a, b) =>
{
if (a == null && b == null) return 0;
if (a == null) return 1; // null を最後にしたい場合(逆にするなら -1)
if (b == null) return -1;
if (a.CodeTown != b.CodeTown)
{
return string.Compare(a.CodeTown, b.CodeTown);
}
if (a.TotalCost != b.TotalCost)
{
return a.TotalCost - b.TotalCost;
}
if (a.Floor != b.Floor)
{
return a.Floor - b.Floor;
}
if (a.RoomSize != b.RoomSize)
{
return (int)(a.RoomSize - b.RoomSize);
}
if (a.Page != b.Page)
{
return a.Page - b.Page;
}
return 0;
});
GPT以前
便宜的に、対話型AIをGPTと呼称しています。
高速化とは言ってもどういう手段あるかなー……if 文多すぎるのを整理したり、ソートの高速化でググって有用そうなコードを真似てみたり、色々と手を尽くすことでしょう。
所要時間は数時間から1日。どのくらい高速にするかで所要時間は変わりますが、1日かければ半分の速度にはなるかな?、と推測します。
GPT以後(現在)
最近めっきりググらなくなりました。即GPTに尋ねます。
私:
ソートコードの処理が遅いのですが、高速化することができますか?
- 先ほどのソースコードをつける
ChatGPT:
はい、現在のソート処理はわかりやすいですが、比較回数が多く、かつ値型と参照型が混在しているため、データ数が多いとパフォーマンスが低下しやすいです。
以下に高速化のための改善案をいくつか提示します。
✅ 高速化のための改善ポイント
-
ラムダ式より Comparer クラスのキャッシュが高速
匿名関数(ラムダ)を毎回生成するとパフォーマンスに影響します。比較用の IComparer<T> を 1つだけ作ってキャッシュしておきましょう。 -
CompareTo を使う
a.TotalCost - b.TotalCost のような引き算は オーバーフローの可能性があり、CompareTo のほうが安全で速いです(特に double や long 型)。
✅ 改善版コード(IComparer<Bukken> 実装)
public class BukkenComparer : IComparer<Bukken>
{
public int Compare(Bukken a, Bukken b)
{
if (a == null && b == null) return 0;
if (a == null) return 1;
if (b == null) return -1;
int cmp;
cmp = string.Compare(a.CodeTown, b.CodeTown, StringComparison.Ordinal);
if (cmp != 0) return cmp;
cmp = a.TotalCost.CompareTo(b.TotalCost);
if (cmp != 0) return cmp;
cmp = a.Floor.CompareTo(b.Floor);
if (cmp != 0) return cmp;
cmp = a.RoomSize.CompareTo(b.RoomSize);
if (cmp != 0) return cmp;
return a.Page.CompareTo(b.Page);
}
}
// 使用例:
bukkens.Sort(new BukkenComparer());
🔄 その他の高速化アプローチ(必要なら)
事前に null を除外 or 別処理
ソート時の null チェックを省略可能(性能改善)
LINQ で OrderBy + ThenBy(読みやすいがやや遅い)
ソート条件が明確だが、大量データでは遅くなる傾向あり
並列化(Parallel Sort)
非常に大量のデータ(数万件以上)なら意味があるが、通常は不要
🔍 パフォーマンス差(体感)
現在のラムダ式
相対速度(小規模): 100%
相対速度(数万件): 約50〜70%(比較的遅い)
Comparer + CompareTo
相対速度(小規模): 120〜140%
相対速度(数万件): 約150%(高速)
わずか1分ほどで解決策、必要なコード、パフォーマンス差まで教えてくれる。
そして、この通りコードを改善したところ、50万件では処理速度がわずか9分の1。
違いをまざまざと見せつけられる
私がやると1日でせいぜい2分の1(推測ベースですが)。GPTは1分で9分の1。
差が明らかすぎて、言い訳する気もおきません。
もちろん「GPTじゃなくても、そのくらい俺にだって出来る」と鼻息荒くする人もいるでしょう。
回答を1分で出せるかはわかりませんが、全C#プログラマーの0.5%くらいは、もしかしたら出来るのかも。
それは素直に凄いですし、誇っていいことだと思います。
問題は、残り99.5%にとってGPTは「今まで出来なかったことをあっさりと可能にしてしまう」ということです。
また、Comparer クラスのキャッシュとか CompareTo とか、教えてもらったことは今後にも活かせます。
プログラム中級者であれば、GPTを使えば、その実力を上級者まで簡単に引き上げることができるでしょう。
At CoderやPaizaの試験問題もAIにやらせちゃえばいいんです。
近い将来、At Coderの上位者は「人間の中では凄い」、実務ではGPTに任せるのだから、その成績に価値なし、となっていくでしょう。
現在の100m走のようなポジションに落ち着いていく。実務は車で。
✅ プログラム知識のない人にも、プログラムは出来るのか
これは2025年現在、もう少し懐疑的です。仕様書からアプリケーションをまるっと作り出すほど優秀ではありませんし、人間が作り出す仕様書の多くは、論理矛盾や例外処理まで考えられていないからです。
UI など、イノベーションを起こすことで更に生産性や快適さをあげられる要素をAIがゼロから作るのも難しそう。安全性を99.9%になるまで安心しない、といった日本的発想(完璧主義)も馴染まないかもしれません。
でも、妥協を受け入れることができれば、いずれなんとかなるような気がします。論理矛盾や例外処理を見つけ出すのはAIの方が得意そうですし、いい感じに修正までしてくれるのではないでしょうか。
人並に丁寧な言葉で、具体性のある指示ができるような人材であれば、プログラムの知識が一切なくともアプリを作ることが可能になると思います。
✅ 仕事を奪われるのは、プログラムだけじゃないんだけどね。
AIのせいでプログラマーは不要になる! と声高に不安を煽る記事をちょくちょく見かけますが、そういう提灯記事を書くライターの仕事は、真っ先にAIに奪われると思います。
絵も、曲も、AIが人と同じように、インプットにインスピレーションを受け、自分のアウトプットに変えていき、一貫性をもって修正されるようになれば、学習速度が異常なAIに人が勝つことはまず不可能ですし、人よりも人らしい感動作品が作られるのも時間の問題のような気がします。
あらゆる創作が人間の特権でなくなった先に、人間には何が残されるのか……それはまだ、わかりません。
でも、人は人。AIが作り出す洗練されたものではなく、人が創った質の悪い、「人間臭い」ものに惹かれるようになるのかもしれません。
まるで音質の悪いレコードの音に、どこか温かみを感じるように。
Discussion