はじめに
AIに実装を依頼したところ、ベータ版ライブラリを使ったコードが生成され、それに気づかずマージしてしまいました。コードは確認していたのに、NuGetパッケージのバージョンまでは見ていなかったという反省と教訓を共有します。
環境
- .NET 10.0
- Azure.AI.OpenAI 2.3.0-beta.1
- Visual Studio 2026
何が起きたか
状況
- C#でAzure OpenAI連携機能を実装
- AIに実装を依頼し、生成されたコードを採用
- コードレビューを通過し、developブランチへマージ
- しばらく経ってから、ベータ版パッケージを使っていることに気づいた
1. AIに「Azure OpenAIでこの機能を実装して」と依頼
↓
2. AIがコードを生成（この時点でベータ版パッケージを使用）
↓
3. コードの動作を確認して採用
↓
4. レビューを受けてマージ
↓
5. （時間経過）
↓
6. 「あれ、これbetaって書いてある...？」と気づく
↓
7. 使いたい機能がベータ版にしかないことが判明
↓
8. レビュアーに相談
↓
9. 試験的リリース目的だったため、レビュアーと相談の結果
ベータ版のまま進めることに
なぜ気づかなかったのか
コードは確認していたが...
AIが生成したコードについて、普段通りのレビューはしていました。ロジックが正しいか、エラーハンドリングは適切か、コーディング規約に沿っているか。でも、NuGetパッケージのバージョンまでは確認していませんでした。
<!-- 実際に追加されていたパッケージ -->
<PackageReference Include="Azure.AI.OpenAI" Version="2.3.0-beta.1" />
↑
完全にノーマーク
コードの中身はちゃんと見ていたつもりでしたが、.csprojに追加されたパッケージの内容まではチェックが甘かったです。
「動いたからOK」の罠
コードが期待通りに動作したので、それ以上深く確認しませんでした。AIが適切なライブラリを選んでくれているだろうという無意識の信頼がありました。
ベータ版の何が問題なのか
気づいた時点では「ベータ版はマズい気がする」という漠然とした感覚しかありませんでした。改めて調べて理解したリスクを整理します。
1. 破壊的変更のリスク
ベータ版は仕様が固まっていないため、次のバージョンで互換性のない変更が入る可能性があります。
// ベータ版で動いていたコード
var options = new ChatCompletionsOptions
{
Messages = { new ChatMessage(ChatRole.User, "Hello") }
};
// 正式版でプロパティ名やクラス名が変わる可能性
// 例：ChatMessage → ChatRequestMessage
// 例：ChatRole.User → ChatRole.UserRole
// → コンパイルエラーや実行時エラーになる
別のバージョンにアップデートした際に、突然コードが動かなくなるリスクがあります。
2. サポート対象外
本番環境でベータ版を使用している場合、問題が発生してもサポートを受けられない可能性があります。
- Microsoftの公式サポートポリシーでは、プレリリース版は通常サポート対象外
- 障害が起きても「ベータ版なので...」で終わる可能性
3. 予期しないバグやセキュリティ問題
- ベータ版には既知・未知のバグが残っている可能性が高い
- セキュリティ脆弱性が後から発見されることもある
- 本番稼働後に緊急対応が必要になるリスク
4. 依存関係の複雑化
他のライブラリとの互換性が保証されていません。別のパッケージをアップデートした際に競合が起きたり、依存関係の解決が困難になったりする可能性があります。
気づいた後の対応
1. まず調査
「安定版に変えなきゃ」と思い、Azure.AI.OpenAIの安定版を調べました。
結果：使いたい機能がベータ版にしか実装されていなかった。
2. レビュアーに相談
状況を説明し、どうすべきか相談しました。
レビュアーの判断
- 今回は試験的なリリースが目的
- 新規プロジェクトで本番環境への影響はない
- 機能がベータ版にしかない以上、選択肢は限られる
- → ベータ版のまま進めることにした
3. 得られた教訓
「結果的に問題なかった」のは運が良かっただけ。本番稼働中のシステムだったらと思うと...。
学んだこと・改善策
AI生成コードで確認すべきポイント
コードだけでなく依存関係も確認
AI生成コードを採用する際は、以下を確認するようにしました。
- どのパッケージが追加されたか
- バージョン番号の確認
- beta/preview/rc/alpha などの表記がないか
- そのバージョンが推奨版（stable）か
.csprojファイルも必ずチェック
AIがコードを生成したら、.csproj（またはpackage.jsonなど）も必ず確認します。
<!-- これを見逃さない -->
<ItemGroup>
<PackageReference Include="Azure.AI.OpenAI" Version="1.0.0-beta.12" />
<PackageReference Include="Azure.Identity" Version="1.10.0" />
</ItemGroup>
AIに「なぜこのバージョンか」を質問する
AIに追加で質問するようにしました。
「このパッケージのバージョンはなぜこれを選んだの？」
「安定版は存在する？」
「ベータ版を使う必要がある理由は？」
ベータ版を使わざるを得ないときの判断基準
今回の経験から、個人的に以下の基準を設けました。
| チェック項目 | 確認内容 |
|---|---|
| 環境 | 本番環境か？検証環境か？ |
| 影響範囲 | 障害時の影響は？ |
| 代替手段 | 安定版で別の実装方法はないか？ |
| 移行計画 | いつ安定版に移行するか決まっているか？ |
| 承認 | チーム/レビュアーの承認を得ているか？ |
ベータ版使用を許容できる条件（推測・個人的見解）
- ✅ PoC・検証環境・開発環境のみ
- ✅ 明確な期限付き（正式版リリース後に移行する計画がある）
- ✅ リスクを理解した上での判断
- ✅ チームの承認を得ている
本番環境では原則NGと考えるようになりました。
チームで取り組めそうなこと
1. レビュー時の確認項目に追加
.csprojや依存関係の変更も明示的にレビュー対象とする
2. CI/CDでの検出
プレリリース版パッケージを自動検出する仕組み（検討中）
# 例：GitHub Actionsで警告を出す
- name: Check for pre-release packages
run: |
if grep -E "beta|preview|rc|alpha" *.csproj; then
echo "::warning::Pre-release package detected"
fi
まとめ
- AIが生成したコードは動作だけでなく、依存関係も確認が必要
- ベータ版ライブラリには具体的なリスクがある（破壊的変更、サポート対象外、バグ・脆弱性）
- ベータ版を使う場合は、リスクを理解した上での明示的な判断と承認が重要
AIは強力なツールですが、生成されたコードを「信頼しすぎない」姿勢が大切だと痛感しました。
参考になったら いいね や ストック をお願いします！
同じような経験をされた方のコメントもお待ちしています。
参考
アウトプットで手当がもらえる会社 ONE WEDGE
株式会社ONE WEDGE では一緒に働く仲間を募集中！
技術記事を書くと手当がもらえる「IT系記事寄稿特別手当」という制度があります。
興味があればぜひカジュアルに話しましょう！
👉 採用サイト