💭

Codex を前提にした Odoo 開発（他のAIエージェントでも適用できます）

に公開
GitHub
Copilot
Odoo
Codex
tech

Codex を前提にした Odoo 開発

― AI を「作業者」ではなく「枠組み強化装置」として使う ―

はじめに

本記事では、Odoo（Odoo 19 Community Edition https://github.com/odoo/odoo ）をベースにした開発において、
Codex をどのような前提で活用しているか、
そして なぜ実装・レビューの両面で破綻せず投入できているのかを共有します。

結論から言うと、本取り組みの本質は次の一点です。

Codex を「コードを書く存在」ではなく、
設計・実装・レビューの枠組みを守らせるための装置として使ったこと

AI を導入したこと自体ではなく、
AI を前提にした開発の型を先に作ったことが成果につながっています。

Codex 活用前にあった課題意識

AI コーディング支援に対して、当初は以下の懸念がありました。

  • 実装ルールが守られなくなるのではないか
  • Odoo コアを誤って改変しないか
  • 設計意図が曖昧なコードが増えないか
  • レビュー品質が人やタイミングによってばらつかないか

これらは AI の性能の問題ではなく、
使い方・指示・レビュー体制を含めた設計不足が原因で起きる問題だと考えました。

方針：Codex を前提に「先に枠組みを作る」

今回の取り組みでは、
実装を始める前に、AI が迷わないための枠組みを先に固定しました。

意識したポイントは以下の3点です。

  1. Codex に判断させない
  2. Codex に迷わせない
  3. Codex に守るべき境界とレビュー観点を明示する

この考え方が、
実装・レビュー・運用すべての設計判断の軸になっています。

Codex を安定して使うための土台（実装＋レビュー）

AGENTS.md を「AI向け仕様書・レビュー基準」として整備

AGENTS.md は、人間向けドキュメントであると同時に、
Codex およびレビュー用 AI に対する制約仕様書・共通基準として位置づけました。

単なるコーディング規約ではなく、
AI が迷わず実装・レビューできるための前提条件と境界を明文化しています。

Codex への指示プロセス（ChatGPT → Codex）

Codex への指示は、いきなりコード生成を依頼しません。

必ず、
一度 ChatGPT に対して指示内容を詳細に言語化させる工程を挟んでいます。

実際の流れ

  1. 人が要件・背景・制約・やらないことを整理
  2. ChatGPT に対して以下を文章化させる
    • 実装の目的
    • 対象モジュール・範囲
    • AGENTS.md に基づく制約
    • 想定する設計方針
  3. その 整理された指示文を Codex に渡して実装を依頼

この工程により、

  • 指示の粒度が安定する
  • 曖昧な表現や解釈揺れが減る
  • Codex が補完や推測で迷走しない

結果として、
迷いのない一貫した実装が行われる状態を作ることができました。

AGENTS.md に明示している主な内容

  • 編集対象は custom_addons/ のみ
  • odoo/addons は改変禁止
  • 拡張は _inherit 前提
  • models / views / security / data の分離
  • manifest の data 読み込み順
  • コメント・docstring の必須化
  • セキュリティ／マルチカンパニー前提
  • 更新 → 確認 → Git 反映までの運用フロー

これらはすべて、

  • Codex が実装時に迷わないため
  • レビュー時の基準を揃えるため
  • 人が最終判断しやすくするため

の 共通土台です。

実装とレビューにおける AI の役割分担

Codex（実装草案）

Codex は主に以下を担当しています。

  • カスタムアドオンの雛形生成
  • models / views / security の初期実装
  • manifest / README / コメントの下書き
  • cron・定期処理のベースロジック
  • テストケース（観点）の叩き台作成

👉 設計意図を含んだ「大枠」を高速に形にする役割

GitHub Copilot（レビュー補助）

レビュー工程では GitHub Copilot を併用しています。

  • PEP8 などのコーディング規約違反の指摘
  • 冗長・不自然な記述の検出
  • import 漏れや細かな書式ミスの補足

特に、
Codex 単体では拾いきれない規約違反を刈り取れるケースが多く、
レビュー精度の底上げに効果がありました。

👉 機械的にチェックしやすい観点を安定して補完する役割

人（判断・最終レビュー）

  • 要件の優先順位決定
  • 「今回はやらないこと」の判断
  • 権限・運用ルールの最終決定
  • 外部連携の境界設計
  • 最終レビューと責任

Codex も GitHub Copilot も、
最終判断を行う主体にはしないという線引きを徹底しています。

得られた効果

初速とレビュー品質の両立

  • 実装草案が即座に出る
  • レビュー対象が早期に具体化される
  • 抽象論のレビューが減少

結果として、
開発初期の停滞がほぼなくなりました。

ルールと品質の安定

  • ディレクトリ構成が崩れない
  • コメント粒度が揃う
  • 規約違反を早期に検出できる

これは、
人が注意し続けるレビューよりも安定しています。

人が「設計」に集中できる

AI が、

  • 書式
  • 規約
  • 初歩的な抜け漏れ

を補助することで、人は

  • 責務分離
  • 拡張性
  • 将来の壊れにくさ

といった 本質的な設計レビューに集中できました。

気づき：Codex は思考もレビューも代替しない

今回の取り組みで最も重要だった気づきは、

Codex は設計やレビューを考えてくれる存在ではない
設計思考とレビュー観点を高速に可視化する存在である

という点です。

AI は思考とレビューの質をそのまま増幅する、
という感触でした。

今後の展開

  • Odoo 開発・レビュー観点の定型化
  • テストケース生成とレビューの自動化拡張
  • 設計判断ログの蓄積

Codex を単なる便利ツールではなく、
開発とレビューの再現性を高める基盤として育てていきます。

まとめ

  • Codex は「考えなくてよくする道具」ではない
  • 考える人とレビューを加速させる道具
  • 枠組みと指示設計を先に作ることで AI は安定戦力になる
  • Odoo のような複雑な開発ほど効果が高い

今回作った枠組みは、
Codex を前提とした開発の再現可能な型として、
今後のプロジェクトにも展開可能です。

Discussion