自治体向けの行政ナレッジ検索システムに、OpenAIのGPTモデルとCodex（自然言語からコードを生成するAIモデル）を組み込む取り組みが進んでいます。Polimillという企業が、日本の自治体職員向けに行政知識の検索と活用を支援する基盤を開発し、その開発工程にCodexを使っているという事例です。
この記事は、生成AIをコード生成に使うプロジェクトのQA（品質保証）やCI/CD（継続的インテグレーション・継続的デリバリー、コード変更を自動でテスト・リリースする仕組み）をどう設計すればよいか悩んでいる方に向けた内容です。特に自治体・公共系のシステムのように、誤りが許されにくい領域でAI生成コードをどう検証するかという観点で整理します。
何が起きているのか：AIがコードを書く開発の実態
Codexは、自然言語の指示からプログラムコードを生成するAIモデルです。GitHub Copilotのベースにもなった系譜の技術で、ChatGPTの対話モデルとは別に、コード生成に特化したチューニングがされています。
行政ナレッジ検索という用途では、条例や通達、Q&A集といった非構造化データを検索可能な形にする処理や、検索結果を職員向けにわかりやすく要約する処理が中心になると考えられます。こうした処理のプロトタイプ実装や、繰り返し発生する定型的なコーディング作業をCodexに任せることで、開発速度を上げる狙いがあります。
重要なのは、AIが生成したコードも最終的には人間のレビューとテストを通過する必要がある、という点です。ここが従来の開発と変わらない部分であり、同時に見直しが必要な部分でもあります。
段階的に見る：AI生成コードのテスト戦略はどう変わるか
まず押さえておきたいのは、AIが書いたコードは「動くように見えて実は要件を満たしていない」パターンが人間の書いたコードより出やすい、という傾向です。文法的には正しくコンパイルも通るが、境界条件やエラーハンドリングが抜けているケースが典型例です。
これに対応するには、テストピラミッド（単体テスト・結合テスト・E2Eテストを層状に積む考え方）の下層、つまり単体テストの網羅性を従来以上に意識する必要があります。AIにコードを書かせたら、同じAI、あるいは別のプロンプトでテストケースも生成させ、人間はテストケースの妥当性をレビューする、という役割分担が現実的です。
次に重要なのが、CI（継続的インテグレーション）パイプラインでの自動チェックの厚みです。行政システムのように誤情報のリスクが高い領域では、通常のlintやユニットテストに加えて、生成された要約や検索結果が元の条例・通達の内容と矛盾していないかを確認する仕組みが求められます。これは一般的なソフトウェアテストというより、LLM（大規模言語モデル）出力の正確性を検証する「評価（evaluation）」の領域に近く、従来のQAエンジニアが持つスキルセットとは別の観点が必要になります。
具体的には、入力と期待される出力のペアを大量に用意し、生成結果が期待値からどれだけ逸脱しているかをスコア化する「evalスイート」の整備が一つの手段です。OpenAIは開発者向けにEvalsという評価フレームワークを公開しており、こうした仕組みをCIパイプラインに組み込むことで、モデルやプロンプトを変更するたびに品質の劣化がないかを自動でチェックできます。
既存のCI/CDとの比較：何が同じで何が違うか
従来のCI/CDパイプラインは、コードの変更差分に対してテストを実行し、パスすればデプロイに進む、という決定論的な仕組みが前提でした。GitHub ActionsやJenkinsで組んでいるパイプラインの多くがこの形です。
生成AIが絡む開発では、同じ入力に対して毎回微妙に異なる出力が返る「非決定性」が加わります。このため、テストのアサーション（期待値との一致確認）を単純な文字列一致ではなく、意味的な類似度や、含まれるべきキーワードの有無といった緩やかな基準に変える必要があります。
また、リリースサイクルの最適化という観点では、モデルのバージョンアップ（GPT-4からGPT-4o、あるいは新しいCodexモデルへの切り替えなど）が、自社のコードのリリースとは独立したタイミングで発生する点も見逃せません。モデル提供元のアップデートによって出力の傾向が変わり、既存のevalスイートで検知していた品質基準に抵触するケースもあり得ます。これに備えて、モデルのバージョンを固定するか自動追従するかの方針を、CI/CDの設計段階で決めておくことが望ましいです。
今日から確認できること
すでにAIコード生成ツールをプロジェクトに導入している、あるいは導入を検討している場合、以下の点を確認しておくと具体的な備えになります。
- 使用しているCodex・GPTモデルのバージョンをどこで固定・管理しているか（APIのモデル名指定、環境変数化の有無）
- AI生成コードに対するユニットテストのカバレッジ目標を、人間が書くコードと同じ基準にしているか、別基準を設けているか
- 生成AIの出力を検証するevalスイートやゴールデンデータセット（正解データ）が用意されているか
- CIパイプライン上で、モデル出力の非決定性を許容するテスト設計（緩やかなアサーション）になっているか
- モデルの提供元（OpenAIなど）のバージョンアップ通知をどこで追跡し、リリース判断にどう反映しているか
これらの項目は、既存のCI/CD設定ファイル（.github/workflowsなど）やテストコードを見直すだけで、現状を把握できるものがほとんどです。まずはモデルのバージョン管理から着手すると、他の項目にも波及しやすくなります。
まとめ
行政システムのような公共性の高い分野でAIコード生成を使う事例は、QAやCI/CDの設計にとっても示唆があります。
要点は次の3つです。単体テストの網羅性をAI生成コード向けに見直すこと、モデル出力の正確性を検証するeval的な仕組みをCIに組み込むこと、そしてモデルのバージョン管理をリリースサイクルの一部として明示的に扱うことです。
まずは自分のプロジェクトのCI設定とテストコードを開き、上記の確認ポイントに沿って現状を棚卸ししてみるところから始められます。