AIがコードを書く時代になって、「では人間のエンジニアは何をするのか」と不安に感じる人は多いです。
ですが、実際に変わっているのは、仕事がなくなることではありません。人間の役割が「コードを書く人」から、「目的とルールを設計する人」へ移っているのです。
OpenAIのCodex関連情報を見ると、AIにただお願いするよりも、必要な文脈を渡し、完了条件を明確にするほうが成果につながりやすいことがわかります。`AGENTS.md` のような指示ファイルを読み込ませたり、レビューや検証の流れを組み込んだりすることで、AIは単なる補助ではなく、自走しやすい開発パートナーになります。
この記事では、OpenAI DevDay 2025で紹介されたCodex活用の話も参考にしながら、個人開発でも再現しやすいAI駆動開発の型をやさしく解説します。
AIがコードを書く時代に、人間の役割はどう変わるか
結論からいうと、人間の仕事は「コードを1行ずつ書くこと」から、「何を正解とするか決めること」へ移っています。
AIは、仕様がはっきりしていて、確認方法も決まっている仕事が得意です。
たとえば、フォームの入力チェックを追加する、一覧画面の表示を直す、既存ルールに沿ってテストを通す、といった作業はかなり自動化しやすいです。
一方で、次のような仕事はまだ人間が強いです。
- 何を作るべきか決める
- どの案を採用するか判断する
- ユーザーにとって本当に必要かを考える
- AIが出した結果を信頼してよいか見極める
つまり、人間は「実装者」だけでなく、設計者、編集者、審査役の役割を持つようになります。
結論は「方針・制約・検証」を人間が持つこと
AI時代の開発で重要なのは、AIに丸投げすることではありません。
大事なのは、AIが迷わないように枠を作ることです。
その枠が、次の3つです。
- 方針
何を作るのか、どこまで作るのか、どの順番で進めるのかを言葉にします。
- 制約
このライブラリを使う、この画面は変えない、テストが通るまで終わりにしない、といったルールです。
- 検証
本当に動くかを、感覚ではなく仕組みで確かめます。ここで大事になるのがテストです。
OpenAIのCodexワークフロー資料でも、Codexは明確な文脈と完了条件があるときに特に力を発揮すると説明されています。つまり、人間の仕事は減るのではなく、より上流に寄るのです。
AI駆動開発を支える3つの土台
1. テスト
テストは、コードが正しいかを機械的に確認する仕組みです。
人間が毎回目で見て確かめなくても、AIが自分でチェックできます。
たとえば、Todoアプリなら「タスクを追加したら一覧に入るか」をテストで決めておけば、AIはその条件を満たすまで修正を続けやすくなります。
def test_add_task():
t = Task()
t.add("買い物")
assert "買い物" in t.list()
“`
この1本があるだけでも、AIにとっては「何が正解か」がかなりはっきりします。
2. 設計ドキュメント
設計ドキュメントは、AIに背景を伝えるためのメモです。
ここでいう設計ドキュメントとは、難しい設計書ではありません。
たとえば、次のような内容が書いてあれば十分です。
- 何を作るのか
- なぜ作るのか
- まず何から作るのか
- どんな制約があるのか
- 今回あえてやらないことは何か
OpenAI Cookbookには `PLANS.md` を使った長時間タスクの実践例があります。
ただし、ここで大事なのはファイル名ではありません。`PLANS.md` はあくまで一例で、本質は「AIが読んで進められる設計メモを置くこと」です。
3. AGENTS.md
たとえば、こんな内容です。
Repository expectations
- コードを変更したら `pytest` を実行する
- Lintエラーを残したまま終了しない
- 仕様変更があれば docs/ を更新する
- 大きい変更の前に計画を書き、意図を明確にする
これは、人間でいう「作業ルール集」に近いです。
AIにとっては、ただのメモではなく、行動の基準になります。
個人開発でもできる導入手順
ここからは、実際に小さく始める方法を紹介します。
Step1 プロジェクトを作る
まずはふつうにGit管理できる状態にします。
Gitを使うのは、変更点を見やすくするためです。レビューもしやすくなります。
Step2 設計メモを書く
ここでは `plans.md` でも `plan.md` でも、好きな名前でかまいません。
大事なのは、AIが読んで迷わない内容にすることです。
Goal
作るもの: Todoアプリ
目的: ローカルで動く簡単なタスク管理アプリ
Features
- タスク追加
- タスク削除
- 完了チェック
- JSON保存
To-Do
- [ ] main.py を作る
- [ ] taskモデルを作る
- [ ] UIを作る
- [ ] テストを書く
Decision Log
- 最初はCLIで作る
- 保存はDBではなくJSON
- 学習コストを下げるため構成はシンプルにする
Step3 AGENTS.mdを書く
次に、AI向けのルールを書きます。
Working rules
- コード変更後は必ず `pytest` を実行する
- テスト失敗時は原因を特定し、自分で修正して再実行する
- 仕様を変えたら設計メモも更新する
- 大きい変更は小さな単位に分けて進める
この1枚があるだけで、AIの動きはかなり安定します。
Step4 先にテストを書く
ここがいちばん大事です。
テストがないと、AIは「動いたっぽいコード」を出しやすくなります。
テストがあれば、AIは「通るまで直すべきコード」として扱いやすくなります。
つまり、テストはAIへの注文書であり、採点表でもあります。
Step5 AIに実装と検証を任せる
たとえば、次のように伝えます。
このとき重要なのは、「コードを書いて」で終わらないことです。
何を読んで、何を満たしたら完了なのかまで入れると、AIはかなり安定します。
人間が最後まで手放してはいけない仕事
AIに多くを任せられるようになっても、人間が持つべき仕事は残ります。
まず、目的の判断です。
その機能は本当に必要なのか、誰のためなのかは、人間が決めるべきです。
次に、優先順位の判断です。
バグ修正を先にやるのか、新機能を作るのかは、事業やユーザーの状況で変わります。
そして、品質の最終判断です。
テストが通っても、使いにくいUIやわかりにくい画面はありえます。
要するに、人間は不要になるのではなく、より上流に寄るのです。
コードを全部書く人から、開発全体を設計し、AIを動かす人へ変わっていきます。
よくある失敗と対策
よくある失敗は、AIに最初から大きすぎる仕事を渡すことです。
「SNSアプリを全部作って」では、判断が広すぎてブレやすくなります。
対策は、小さく区切ることです。
ログインだけ、投稿機能だけ、一覧表示だけ、というふうに1つずつ終わらせます。
次の失敗は、テストなしで進めることです。
この場合、AIは見た目だけそれらしいコードを出しても、壊れている部分に気づきにくくなります。
もう1つは、ルールを書かないことです。
`AGENTS.md` のような指示がないと、AIは毎回前提があいまいなまま動きます。
なお、Codex CLIには `/review` によるローカルコードレビュー機能があります。
差分を読んで、優先度つきで指摘を返す仕組みです。実装スレッドとレビューを分ける運用は、個人開発でもかなり実践的です。
まとめ
AIがコードを書く時代に、人間がやるべきことは、以前よりむしろはっきりしています。
人間が担うのは、
- 何を作るか決めること
- AIが迷わないルールを作ること
- 正しさを確かめる仕組みを用意すること
です。
そのための最初の一歩は難しくありません。
まずは次の3つで十分です。
- 小さな設計メモを書く
- `AGENTS.md` でルールを書く
- 先にテストを書く
この3つがあるだけで、AIはただのコード補完ではなく、自走しやすい開発パートナーになります。
OpenAIの公式情報でも、CodexはDevDay 2025の準備で実際に活用され、`AGENTS.md` やレビュー、明確な完了条件を前提にしたワークフローが案内されています。
だからこそ、これからの開発では「AIに書かせること」そのものより、AIが正しく進める環境を作れるかが差になります。
FAQ
Q1. AIがコードを書けるなら、エンジニアは不要になりますか？
いいえ。不要になるというより、役割が変わります。
人間は、目的決め、優先順位づけ、品質判断、リスク管理を担うようになります。
Q2. テストがなくてもAI開発はできますか？
できますが、精度は下がりやすいです。
テストがあると、AIが自分で確認しながら直せるので、安定しやすくなります。
Q3. AGENTS.mdは必須ですか？
必須ではありません。
ただし、同じルールを何度も伝えるなら、かなり効果的です。
Q4. plans.md は公式の決まりですか？
断定は避けたほうが安全です。
`PLANS.md` の実践例はありますが、本質は「AIが読める計画書を用意すること」です。
Q5. 個人開発でも意味はありますか？
あります。
むしろ個人開発では、1人で設計・実装・確認を回す必要があるため、AIに反復作業を任せる効果が出やすいです。
Codexを使った開発や記事制作の運用を整えるうえで、先に読んでおきたい資料をまとめました。
