Codexを数ヶ月使って感じたこと

はじめに

ここ数ヶ月、業務や個人開発の中で Codex を使う機会が増えました。

最初は「コードを書かせるAI」くらいの感覚で使っていましたが、実際に使い続けてみると、単純な実装支援だけではなく、既存コードの読解、改修方針の整理、軽量化対応などにもかなり効果があると感じました。

一方で、便利だからこそ雑に使うと危ない部分もあります。

この記事では、Codexを数ヶ月使って感じた良かった点、悪かった点、そして自分なりに行っている対策についてまとめます。

Codexを使って良かったこと

手をつけられなかった機能改修や軽量化に着手しやすくなった

一番大きかったのは、今まで後回しになっていた機能改修や軽量化に手を入れやすくなったことです。

既存プロジェクトでは、すでに動いている機能に対して改修を入れる場合、まず関連コードを読んで、影響範囲を確認して、実装方針を考える必要があります。

この時点でかなり時間がかかります。

特に、日々の運用や他のタスクがある中では、

• 気にはなっているが優先度が上がらない
• 改修したいが影響範囲の確認が重い
• 軽量化したいが調査に時間がかかる
• 人手が足りず後回しになる

といったことが起きやすいです。

Codexを使うことで、既存コードの把握や改修案の作成がかなり速くなり、今まで手をつけづらかった部分に着手しやすくなりました。

もちろん最終的な判断やレビューは人間が行う必要がありますが、「最初の一歩」が軽くなる効果はかなり大きいです。

担当外の実装を読むコストが下がった

自分が直接担当していない機能や、普段あまり触らない領域のコードを読むときにも役立ちました。

既存コードを読む場合、最初に困るのは「どこから読めばいいのか分からない」ことです。

関係するクラス、呼び出し元、データの流れ、依存関係などを自分で追っていく必要があります。

Codexを使うと、

• この処理の入口はどこか
• このクラスは何を担当しているのか
• どのファイルを見ればよいか
• この変更を入れるとどこに影響しそうか

といった観点で整理しやすくなります。

そのため、担当外だった部分でも、実装の全体像を掴むまでの時間が短くなりました。

後回しにしていた改善に手を出しやすくなった

全体として、Codexを使うことで「時間がかかるから後でやる」「人手が足りないから今は無理」となっていた部分に手を入れやすくなりました。

特に効果を感じたのは、以下のような作業です。

• 既存処理の整理
• 軽量化の調査
• 影響範囲の洗い出し
• 小さなリファクタリング
• テスト用コードや検証コードの作成
• 実装方針のたたき台作成

AIがすべてを解決してくれるわけではありません。

ただ、作業開始までの心理的・技術的なハードルを下げるという意味ではかなり有効でした。

Codexを使って悪かったこと

人間側の意図と違う実装をすることがある

Codexは便利ですが、こちらの意図を完全に理解してくれるわけではありません。

特に新機能の実装や既存機能の改修では、人間側が考えていた設計意図とは違う実装を行うことがありました。

例えば、

• 既存の設計方針と違う書き方をする
• 触ってほしくない箇所まで変更する
• 一見動きそうだが、運用上困る実装になる
• その場しのぎの修正を入れる
• 影響範囲を広げすぎる

といったことがあります。

AIは「それっぽく動くコード」を出すのは得意ですが、「このプロジェクトではどうあるべきか」までは正しく判断できないことがあります。

そのため、実装を任せる場合でも、設計方針や変更範囲は人間側が明確にする必要があると感じました。

エラーで詰まったときに時間とクレジットが溶ける

一番危険だと感じたのは、沼のようなエラーにハマったときです。

原因が明確でないエラーに対して、Codexに修正を任せ続けると、似たような修正や検証実装を繰り返すことがあります。

その結果、

• 同じような修正を何度も試す
• 検証コードが増える
• 原因が分からないまま変更量だけ増える
• 時間が溶ける
• クレジットも溶ける
• それでも修正完了まで行かない

という状態になりがちでした。

これはかなり危険です。

人間が原因を整理できていない状態でAIに投げ続けると、AIもそれっぽい修正を出し続けます。

しかし、それが本質的な解決に向かっているとは限りません。

むしろ、問題の切り分けができていない状態では、AIを使うことで余計に混乱することもあります。

新しいことに取り組むとき、実装者がAIに置いていかれがち

新しい技術や初めて触る領域でCodexを使う場合、AIがどんどん実装を進めてくれることがあります。

これは一見便利ですが、実装者側の理解が追いついていないと危険です。

コードは増えているのに、

• なぜその実装になっているのか分からない
• エラーが出たときに直せない
• 変更したいときに触れない
• どこが重要な処理なのか分からない

という状態になります。

特に学習目的で使う場合、AIに任せすぎると「完成物はあるが、自分の理解がない」という状態になりやすいです。

これはかなり危ないと思いました。

Codexを使う場合でも、少なくとも自分が説明できる範囲に実装を収めることが重要だと感じました。

悪い部分への対策

プロジェクトルールをMarkdownで定義する

対策として、プロジェクト内にMarkdownファイルを追加し、そこにAI向けのルールを書くようにしています。

CodexのようなAIエージェントは、プロジェクト内の色々なファイルを見て、必要に応じて変更を行います。

そのため、何もルールを定義していないと、想定より広い範囲を触ってしまうことがあります。

自分の場合は、以下のような内容を書くようにしています。

• 触ってよいファイル
• 触ってはいけないファイル
• 変更前に確認すべきこと
• コーディング規約
• 命名ルール
• 既存設計の方針
• 禁止している実装
• 勝手に変更してはいけない設定
• 大きなリファクタリングをしないこと
• まず影響範囲を説明すること

特に重要なのは、「やってほしいこと」よりも「やってはいけないこと」を明確にすることです。

AIは良かれと思って広い範囲を修正することがあります。

そのため、禁止事項を多めに定義しておくことで、意図しない変更を減らしやすくなります。

まず調査・方針整理をさせる

いきなり実装させるのではなく、まず調査や方針整理をさせるようにしています。

例えば、

• まず関連ファイルを洗い出す
• 現在の処理の流れを説明させる
• 変更方針を複数案出させる
• 影響範囲を整理させる
• 実装前に変更予定ファイルを提示させる

といった使い方です。

いきなりコードを書かせると、意図と違う方向に進むことがあります。

そのため、最初に「どこを見て、何を変えようとしているのか」を確認するようにしています。

エラー対応では切り分けを優先する

エラー対応では、いきなり修正案を出させるのではなく、原因の切り分けを優先するようにしています。

具体的には、

• まずエラーログを整理する
• 再現条件を確認する
• 変更前後の差分を見る
• 原因候補を複数出す
• それぞれの検証方法を決める
• 一度に複数箇所を変更しない

という流れを意識しています。

AIに任せ続けると、次々と修正案が出てきます。

しかし、原因が分からないまま修正を重ねると、どの変更が効いたのか分からなくなります。

そのため、エラー対応では「修正」よりも「切り分け」を重視した方がよいと感じました。

自分の考えをアウトプットする

もう一つ意識しているのは、自分の考えをアウトプットすることです。

社内外問わず、実装方針や調査結果を文章にまとめることで、自分が本当に理解できているかを確認できます。

AIを使うと、実装スピードは上がります。

しかし、何も考えずに使っていると、自分の理解が追いついていないことに気づきにくくなります。

そのため、

• なぜこの実装にしたのか
• どこで詰まったのか
• 何を検証したのか
• 何が分かったのか
• 次にどう改善するのか

を文章にすることはかなり重要だと思います。

アウトプットすることで、AIに任せた部分と自分で理解している部分の境界が見えやすくなります。

Codexは作業者を楽にするが、責任は人間に残る

Codexを使っていて感じたのは、AIは作業量をかなり減らしてくれる一方で、判断責任までは引き受けてくれないということです。

コードを書く速度は上がります。

調査も速くなります。

既存コードの読解も楽になります。

しかし、

• その設計でよいのか
• その修正で本当に問題が解決しているのか
• 既存仕様を壊していないか
• 運用上問題がないか
• チームの方針に合っているか

といった判断は、結局人間が行う必要があります。

ここをAI任せにすると危険です。

まとめ

Codexを約3ヶ月使ってみて、良い面も悪い面もかなり見えてきました。

良かった点は、今まで時間や人手の問題で後回しにしていた改修や軽量化に着手しやすくなったことです。

また、担当外のコードを読むコストも下がり、既存実装の理解にも役立ちました。

一方で、意図と違う実装をしたり、エラー対応で同じような修正を繰り返したり、新しい領域で実装者側の理解が追いつかなくなる危険もあります。

そのため、Codexを使う上では、

• プロジェクトルールを明文化する
• 禁止事項を定義する
• いきなり実装させず、まず調査・方針整理をさせる
• エラー対応では切り分けを優先する
• 自分の考えをアウトプットする

といった運用が重要だと感じました。

Codexはかなり強力なツールです。

ただし、任せれば何でも解決するものではありません。

「AIに書かせる」のではなく、「AIを使って自分の判断と実装を加速させる」くらいの距離感が、今のところ一番良い使い方だと思っています。