はじめに
AI コーディングが普及して、私はときどき「技術スタックなんてもう AI 任せでいいのでは？」と思うようになりました。
実際、AI はかなりのことをやってくれます。言語も、フレームワークも、デプロイ先も、いまの AI は選択肢を広げてくれます。どんな言語でも、どんなインフラでも、動くコードを生成してくれることがあります。私はそれを否定しませんし、むしろありがたいと感じています。
ただ、ここで大事なのは「動くかどうか」と「何が起きても対処できるか」は別だということです。
AI にコードを書かせると、たいていの実装は一通り進みます。動くと思わせるコードを出してくれることも多いです。ところが、問題が起きたときに、私が本当に頼れるのは「よく知っている技術」なのです。
私はその観点で、C# と Azure の組み合わせに強く安心感を感じています。だから、AI コーディングを使うときでも、私はたいていその組み合わせを選びたくなります。
AIが書くコードと、人間が検証するコード
AI は、かなり便利です。
たとえば、API のエンドポイントを作るとき、データベースの接続を作るとき、簡単なバッチ処理を作るとき、AI は一通りのコードを作れます。しかも、言語や環境を切り替えながら、比較的スムーズに対応してくれます。
実務で考えると、こうした利点はとても大きいです。
- 実装の初期速度が上がる
- 仕様を言語化しやすくなる
- 既存の知識を前提にしなくても着手しやすい
- 似たようなコードのパターンをすぐ生成してくれる
一方で、AI が書いたコードには、実務では見落とされやすい「不安」が残りやすいです。
- 例外の扱いが粗い
- ログの粒度が合っていない
- 依存関係の解決が変な方向に行っている
- 非同期やタイムアウトの境界が曖昧
- 本番環境での観測性が弱い
こういう問題は、コードの見た目が動いていても、実運用では立ち上がってくることがあります。
そして、そんなときに本当に頼れるのは、「このコードの挙動がなぜ起きるのかを説明できる」技術です。
AI が書いた設計が、私の既存の知識と合っていれば、かなり安心できます。なぜなら、「何が起きているか」を自分で説明できるからです。逆に、知らない言語や知らないインフラだと、原因の切り分けが遅くなり、対処の選択肢も狭まります。
「動く」と「対処できる」は違う
私は、AI コーディングで一番大事にしているのは「ロールバックできるか」「原因を追えるか」「最小限の修正で戻せるか」という点です。
コードが動くことは、重要です。
でもそれ以上に重要なのは、問題が起きたときに、どこを見ればいいかが分かることです。
たとえば、Web アプリの 500 エラーが発生したとき、
- どの層で失敗しているか
- どのログを持てば原因を絞れるか
- 設定が漏れているのか、依存のバージョンが合っていないのか
- Azure 側でイベントが発生しているのか、アプリ側で落ちているのか
を見分けられるかどうかが、問題解決の本質です。
これは、AI だけがやっているわけではありません。人間が設計を理解し、監視と観測の仕組みを知っていなければなりません。
たとえ AI が 90% の実装を完了してくれても、最後の 10% を本人が担う前提があるとき、私は信頼感が増します。なぜなら、その 10% が本番運用で置き去りにならないからです。
私が安心できるのは C# と Azure
私は、C# と Azure の組み合わせにかなり強い安心感があります。
その理由は、単に「私が慣れているから」ではありません。
C# は、型安全性や構造化された設計、デバッグのしやすさ、ツールチェーンの整合性が揃っているので、問題発生時の見立てがしやすいです。ローカルで再現できることも多く、ログの追跡もやりやすい。
Azure も同じです。
- App Service
- Functions
- Azure SQL
- Application Insights
- Key Vault
- Service Bus
- Container Apps
こうしたサービスの組み合わせは、メトリクスとログを見ながら、どこで何が起こっているかを切り分けやすいです。
私はこの組み合わせが、混乱しにくく、対処しやすく、再現しやすいと感じています。
AI が書いたコードに対しても、私はそれを「自分の知識で検証できる」安心が必要です。
- C# のコードがどこで例外を吐いているのか
- Azure のログに何が残っているのか
- 依存サービスの呼び出しがどうなっているのか
- 監視の指標がどう見えるのか
こうした見え方が分かると、AI が書いたものでも、少しずつ人間の責任範囲で整えられます。
もちろん、C# と Azure 以外の技術にも優れた選択肢はあります。JavaScript でも、Python でも、Go でも、クラウド基盤を変えても、十分に良い開発ができます。
でも、知っている技術であれば、問題が起きたときに本気で対処できるという自信がある種の支えになります。
他の言語やインフラでは、なぜ同じ安心感が持てないのか
私には、他の言語やインフラでも同じ安心感が得られる可能性は十分にあると思います。
ただ、現実には「自分がその技術をどこまで知っているか」で差が出ます。これは一種の経験の蓄積であり、言語やインフラへの習熟度の差でもあります。
同じように AI がコードを書くとしても、知らない言語だと、
- 例外の握り方が知らない
- 依存関係がどう解決されるかが分からない
- 実行環境とローカル環境の差が見えにくい
- どこで落ちるかを予測しにくい
という問題に直面しやすくなります。
逆に、私が長く触ってきた C# と Azure では、コードの構造・例外・ログ・監視・デプロイ先の期待値が見えやすい。それが、AI を使うときの安心材料になるのです。
ただし、ここで一つ重要なのは、この話は本番向けのプロダクト開発を前提にしているということです。
実験、PoC、勉強、教育、趣味開発、あるいは「新しい技術を試す」こと自体が目的のときは、話は違います。
その場合は、むしろ未知の技術を選ぶ価値が高いです。AI と組み合わせれば、短期間で試験的に動かしてみることができますし、技術選定の学習にもなります。
- 触ったことがない言語で小さな実験をやってみる
- 新しいクラウドサービスを試す
- 既存のやり方では得られない設計の仮説を検証する
こうした文脈では、未知の技術を選ぶこと自体が価値になります。
だから、私は「どの技術を選ぶべきか」を一律に決めているわけではありません。
むしろ、次のように分けています。
- 本番プロダクト: 失敗したときに対処できる技術を選ぶ
- 実験 / 勉強 / PoC: 先に試したい技術を選んで、学びを得る
この違いはとても大切です。プロダクトの話では、知っている技術の安心感が強く効きます。一方で、学習や実験の話では、知らない技術に踏み込む価値があるからです。
そして、ここにはもう一つ重要な事実があります。
最後に責任を取るのは人間だということです。
AI が生成したコードを使うのは、技術的には便利ですが、そのコードが本番で安全かどうかを最終的に判断するのは人間です。変更によって発生した障害に対して、説明責任を取るのも人間です。
だからこそ、私が選ぶ技術は「AI に任せやすいもの」ではなく、「問題が起きても自分が責任を持って対処できるもの」なのです。
まとめ
AI コーディングの時代において、技術スタックの選定は以前よりも「自分がどこまでその技術を知っているか」が重要になっています。
AI は、技術を選ぶときの選択肢を広げてくれます。どんな言語でも、どんなインフラでも、たいていはうまくいくでしょう。
でも、そうした時代だからこそ、私たちはより慎重に技術を選ぶ必要があります。
- 何が起きても対処できるか
- 変更の影響範囲を見極められるか
- ログと監視で原因を絞れるか
- 最後に責任を取れるか
この観点で見ると、私がよく知っている C# と Azure の組み合わせには、やはり大きな安心感があります。
AI にコードを書かせるとき、私はその手助けを歓迎します。けれど、どこまでを AI に任せ、どこからを自分が制御するのか。その境界を見極めるためにも、知っている技術を選ぶことの価値は今後も大きいと考えています。
AI コーディングの便利さは大きいですが、責任と対処能力は、やはり人間の知っている技術に支えられるものです。
そして、私はその意味でも、勝手知ったる技術スタックを選ぶことに、ちゃんと価値があると感じています。
おわりに
AI と一緒に開発するとき、私は「自分が信頼できる技術」を選ぶことを大切にしています。
それは、古い技術にこだわるというより、自分が問題を追える技術を選ぶということです。
AI にコードを書かせる時代において、それができる人ほど、安心して実装を進められるし、失敗したときにも立ち直れます。
私にとって、C# と Azure はその代表格です。そこに安心感があるからこそ、AI を使いながらも、最後まで自分の手で責任を持てるのだと思います。