OpenAI Codex 導入支援
開発チームの手が、設計と判断に戻る

利用形態と対象リポジトリ、権限、認証情報の扱いを決め、会社として把握できる形に集約します。

• 利用形態の確認（クラウド上で動かす形、ターミナルで動かす形、エディタ拡張として使う形のどれを使うか。提供形態と利用条件は変更されることがあるため、契約時点の公式情報を一緒に確認します）
• 対象リポジトリの選定（先に使うリポジトリと、当面は対象にしないリポジトリを分けます）
• アカウントと利用者の管理（個人アカウントでの利用が混ざっていないかの確認と、会社契約への集約）
• リポジトリに対する権限（読み取りのみか、ブランチの作成まで許すか、本番ブランチには触れさせないか）
• 認証情報の扱い（環境変数、鍵、接続先情報をコードやプロンプトに含めないための確認）
• 顧客から預かっているコードを扱う場合の、契約上の確認事項の整理

処理の流れ、外部接続点、影響範囲を読み解いて文書に残し、改修に着手できる状態まで持っていきます。

• 対象システムの処理の流れの整理（どの画面・どのバッチから、どのデータがどう動くか）
• 外部との接続点の洗い出し（連携している他システム、API、データベース、ファイル連携）
• 変更したときに影響が出る範囲の特定（改修前の確認に使います）
• 設定ファイルや起動手順の整理（開発環境を立ち上げ直せる状態にします）
• 読み解いた内容をドキュメントとして残す手順（AIの出力をそのまま残さず、担当者が確認してから確定します）
• 残っている仕様書との差分の確認（資料と実物が食い違っている箇所を先に見つけます）

人が見る前の一次通しをAIに任せ、レビュー担当者が設計と業務要件の確認に時間を使える形にします。

• 一次通しで見る観点の決定（例外処理の漏れ、入力値の確認、エラー時の挙動、命名と書き方の統一）
• 社内のコーディング規約を読ませて、規約に沿っているかを確認させる形の整備
• 指摘の扱い方の取り決め（そのまま直す指摘、担当者が判断する指摘、無視してよい指摘の分け方）
• レビュー依頼を出す前に開発者自身が通す形にするか、依頼後に自動で通す形にするかの決定
• レビュー担当者が本来見る観点の明示（設計の妥当性、業務要件との整合、性能、セキュリティ）
• 一次通しでは判断しない範囲の明示（本番マージの可否は人が決めます）

改修予定のある機能から既存挙動のテストを用意し、開発の流れの中で実行される形に組み込みます。

• 対象範囲の選定（改修予定がある機能、障害が起きたことのある機能から先に着手します）
• 既存の挙動を確認するテストの作成（いまの動きを壊していないかを見るためのテスト）
• 境界値と例外パターンの洗い出し（入力の上限、空の値、想定外の形式）
• テストデータの用意（本番データをそのまま使わない形での準備）
• テストの実行を開発の流れに組み込む手順の整理
• テストが通らなかったときの扱い（直すのか、既知の仕様として記録するのかの判断基準）

定型処理のたたき台づくりを任せ、リファクタリングはテストを用意した範囲から順に進める形にします。

• 仕様書や要件メモから、実装の骨組みを出させる進め方（そのまま使わず、設計者が判断して確定します）
• 定型的な処理の作成（一覧画面、入出力の変換、帳票の出力、バッチ処理の雛形）
• 重複しているコードの洗い出しと、まとめ方の案の作成
• 古い書き方や使われなくなった処理の特定
• リファクタリングの順番づけ（一度に変えず、テストを用意した範囲から進めます）
• 変更の粒度の取り決め（レビューできる大きさに分けて出す形にします）

工程ごとの線引きと承認者を決め、研修と手順書でチーム全体の進め方を揃えたうえで、月次で使われ方を確認します。

• 工程ごとの線引き（AIが下書きする工程、開発者が判断する工程、本番マージを承認する工程）
• 承認者の明示（本番への反映、データベースの変更、外部公開に関わる変更は誰が決めるか）
• 開発チーム向けの研修（自分が担当しているコードを題材に、その場で使える状態まで進めます）
• 使い方の手順書（渡す情報、任せてよい作業、そのまま採用してはいけない出力）
• 月次の確認（使っているエンジニアの数、任せている工程、レビューの往復回数や着手までの時間の変化）
• 内製したAIツールや自動化を本番で使う場合の審査への引き渡し（AI開発セキュリティ顧問で対応します）