はじめに
最近は「AIを使えばどんな開発も効率化できる」と言われています。
私も例に漏れず、自作アプリを**Blazor（.NET MAUI Blazor Hybrid／Blazor WebAssembly）**へ移行してみようと思い立ちました。
AIがコードを提案し、構成を考えてくれるなら、UIもロジックもすぐ組めるはず――そう考えていました。
しかし、現実はまったく違いました。
初期の成功：「Hello World」は簡単だった
最初のチュートリアルやサンプルコードはスムーズに動作しました。
「なるほど、これならC#でWebアプリが書ける。素晴らしい！」
AIも的確にコードを提案してくれて、Counter.razorやFetchData.razorのサンプルもすぐ動作。
この段階では、Blazorの可能性を感じていました。
ところが…応用しようとすると動かない
次のステップでつまずきました。
少し複雑なUIやデータ連携、カスタムコンポーネントを作ろうとすると、AIの提案するコードがことごとく動かないのです。
エラーも分かりづらく、公式ドキュメントを読んでも解決しない。
「動く」と言われているサンプルすら環境差でエラーが出ることがあり、再現性が非常に低いと感じました。
AI駆動開発が通用しなかった理由
AI開発支援を前提にすると、情報量と安定性が重要です。
ReactやWPFのような成熟したフレームワークなら、AIも学習済みの知識が多く、提案の精度が高い。
しかしBlazorはまだ事例が少なく、ライブラリの仕様も頻繁に変わるため、AIの提案が古い・未対応という問題が多発しました。
つまり、「AIを使って楽に作る」には、まだBlazorは早すぎたのです。
開発者人口の少なさも壁に
困ったときに相談できる人がいないのも痛手でした。
フォーラムやQ&Aサイトでも情報が少なく、検索しても答えが見つからない。
結果的に「自力で解決するしかない」状況が増え、開発速度は逆に落ちてしまいました。
結論：Blazor移行は一旦中止
試行錯誤の末、今回はBlazorへの移行を一旦中止することにしました。
理由は以下の通りです：
-
AIによる開発支援がほとんど通用しなかった
-
応用的なコードが安定して動かない
-
技術者・情報の少なさによるメンテナンスリスク
将来的には改善されると思いますが、現時点ではAI時代の開発基盤としては成熟していないというのが正直な印象です。
今後の方針
今後は安定性とサポートのある技術（例：WPF、.NET MAUI単体、または標準Web技術）で進めていく予定です。
AI駆動開発を前提とするなら、やはり「情報が多い」「事例が豊富な」環境を選ぶことが重要だと痛感しました。
まとめ
Blazorは将来性のある技術だと思います。
しかし現時点では、AIと組み合わせて生産性を上げるには環境が整っていないのが現実でした。
これから挑戦しようとしている方は、実験的に試す分には面白いですが、本格的なアプリ移行にはまだ慎重になったほうがいいかもしれません。
.jpg)
0 件のコメント:
コメントを投稿