AIエージェントと共に開発する：Codex・Claude Code・Claude Cowork 実践ガイド
「コードを書くこと」が仕事の中心ではなくなったとき、私たちはエンジニアとして何をすべきなのか — 8つの教訓から学ぶ、安全な委譲のやり方
当記事は以下記事の日本語版です。
ここ数ヶ月の間にAIコーディングエージェントを使って何かをリリースした経験があるなら、この感覚に覚えがあるはずです。3行程度の指示を書いてコーヒーを淹れに席を立ち、戻ってくると差分（diff）とテスト結果、そしてChangelogまで添えられたプルリクエストが出来上がっている——これは、私たちの多くが慣れ親しんできたコードベースとの関わり方とは明らかに異なります。だからこそ、この技術をどう使うかについては意図的であるべきだと思います。
この記事はプレスリリースではなく、現場のフィールドガイドです。個人事業主や小規模チームが今まさに手を伸ばすであろう3つのエージェントツール——OpenAIのCodex、AnthropicのClaude Code、同じくAnthropicのClaude Cowork——をどう使い分けるか、そして何より重要な「エージェントへの委譲が成功するか、ミスを加速させるだけに終わるかを分ける運用規律」について書いています。
始める前に一点だけ断っておきます。このジャンルのモデルバージョン・ベンチマークスコア・料金は、おおむね月単位で変化します。本文中で具体的な数値を挙げている箇所にはすべて出典リンクを付けていますので、永続的な事実ではなく「執筆時点のスナップショット」として読んでください。
AIエージェントで開発する技術 — Codex・Claude_Code・Cowork 実践ガイド - Speaker Deck
なぜ今この変化が起きたのか
ここ数年、「AIによるコーディング支援」と言えばチャットウィンドウを意味していました。関数をペーストして質問し、説明やスニペットを受け取り、あとはコピー・ペースト・実行・デバッグを自分の手で繰り返す——その繰り返しです。
何が変わったかというと、モデルが複数ステップにわたるツール利用を十分にこなせるようになり、開発ループの「外」から指示を出すだけでなく「中」で動作することを任せられるようになった点です。リポジトリをクローンし、実際のファイルを読み、テストスイートを実行し、失敗を解釈し、コードを編集し、再度テストを実行し、プルリクエストを開く——その大部分を、人間が中間ステップをいちいち打ち込むことなく行えるようになりました。OpenAIはCodexのローンチ記事で、エンジニアが「リファクタリング、リネーム、テスト作成といった、集中を妨げる定型的かつスコープの明確なタスク」をオフロードできるツールだとCodexを紹介しています。この「エージェントは質問に答える神託ではなく、限定された作業単位を任せられる同僚である」という捉え方が、本記事で扱う3つのツールすべてに共通する正しいメンタルモデルです。
私たちエンジニアにとっての実務的な帰結は、役割のシフトです。これまでのボトルネックはタイピング速度と構文の暗記量でした。これからはエージェントに与える指示の質と、返ってきた結果をどれだけ厳密にレビューできるかが、エージェントとの1週間がうまくいくかどうかを大きく左右します。「15個のデザインパターンを知っている」より地味なスキルですが、実際の成果を左右するのはこちらです。
チャットツールとコーディングエージェントの違い
ここは正確に理解しておく価値があります。エージェントツールに対する不満の多くは、これを「賢くなったチャットウィンドウ」として扱ってしまうことに起因するからです。
| AIチャット | AIコーディングエージェント | |
|---|---|---|
| スコープ | 質問・説明・コードスニペット | 実際のリポジトリを調査し、実ファイルを編集 |
| 記憶範囲 | その会話の中だけ | 実コードベース、作業ツリー、gitの履歴 |
| 出力 | 自分でペーストするテキストやコードブロック | diff、コミット、プルリクエスト、テスト結果 |
| 実行 | なし——すべて自分で実行する | テスト・lint・ビルド・gitコマンドを自ら実行 |
| 関与の度合い | 毎ステップ必要 | チェックポイントを設けてタスク単位で委譲可能 |
「スニペットを生成する」から「調査し、編集し、テストし、PRを開く」への移行こそ、今世代のツール群を中心に据えてワークフローを再構築する価値がある理由です。同時に、これは失敗モードがまったく異なる——率直に言ってより怖いものになる理由でもあります。スニペットが間違っていれば時間を無駄にするだけですが、エージェントが破壊的なシェルコマンドやスキーマ変更を間違えれば、本番障害につながりかねません。詳しくは後述します。
3つのツール、3つの思想
OpenAI Codex — 非同期クラウドエージェント
Codex（2021年の初代Codexモデルではなく、2025年に再ローンチされたもの）は隔離された非同期実行を中心に設計されています。「authモジュールのテストカバレッジを追加する」「この依存関係をアップグレードする」「このIssueに記載されたバグを修正する」といったタスクは、それぞれ専用のクラウドサンドボックス内でリポジトリをプリロードした状態で実行され、専用のgit worktreeを持つため並行タスク同士が衝突しません。タスクを投げて他の作業に移り、5〜30分後に戻ってくるとコマンドログ・テスト結果・差分（またはPR）がレビュー可能な形で揃っています。
実務上、Codexを特徴づけているのは次の2点です。
-
GitHubネイティブなレビューループ。 プルリクエストに
@codex reviewとコメントするだけで自動レビューが走り、Issue→PRの自動生成によって、よく書かれたGitHub Issueがエディタを一切開かずにドラフトPRへと変換されます。 - 本物の並列実行。 タスクがサンドボックス化・隔離されているため、リファクタリング・テストカバレッジ追加・依存関係アップデートを同時に走らせても作業コピー同士が干渉しません。OpenAIのCodex製品ページや、そのサブエージェント構成を扱った比較記事に詳しい説明があります。
この非同期・バッチ指向の設計は、得意分野の裏返しとして弱点にもなります。30秒ごとに方向修正したくなるような、本当にややこしいデバッグなど、密なインタラクティブなやり取りを必要とするタスクには不向きです。
Claude Code — インタラクティブなターミナルパートナー
Claude Codeはその逆のデフォルトを取ります。ローカルのターミナル（IDEやブラウザからのアクセスも可能）で動作し、影響の大きい操作の前には確認を求めます。設定しない限り、何もマシンの外には出ません。
このローカル・確認優先という姿勢のおかげで、Codexが苦手とする領域——見慣れないコードベースの深い調査、一手ごとに問題理解が更新されるマルチターンのデバッグ、ファイルごとに差分をレビューしながら進めたい段階的なリファクタリング——にうまくフィットします。プロジェクトルートに置く CLAUDE.md は、コーディング規約・禁止事項・テストを実行する正確なコマンドといったリポジトリ固有のコンテキストをセッションをまたいで保持してくれるため、毎回説明し直す必要がありません。これはセッションが長くなるほど効いてきます。最新の機能セットはAnthropicのClaude Codeドキュメントを参照してください。今年に入ってから、異例の速さでアップデートが続いています。
Claude Cowork — 同じ発想をエンジニア以外にも
Coworkは、ある妥当な問いに対するAnthropicの回答です——「調査し、行動し、報告してくれるエージェント」がコードに対してこれほど有用なら、なぜそれをコードを書く人だけに限定する必要があるのか、という問いです。2026年1月にローンチされ、Claudeデスクトップアプリに組み込まれたCoworkは、同じエージェントループ（ファイルを読み、計画を立て、複数ステップの作業を実行し、結果を報告する）を、リサーチ・ドキュメント作成・業務ワークフローに適用します。ターミナルは一切不要です。詳細はAnthropicのCowork製品ページをご覧ください。
エンジニアリング中心のチームにとっても重要なのが、そのプラグインエコシステムです。Anthropicはローンチ時に11個のオープンソースプラグイン（プロダクティビティ、エンタープライズ検索、セールスなど）を提供しており、それぞれがスキル・コネクタ・スラッシュコマンドをひとまとめにしているため、Coworkはゼロからではなくドメイン知識を事前に備えた状態でスタートできます。多くの個人事業主と同じように、クライアントリサーチ・仕様書作成・エンジニアリング作業を一人でこなしているなら、リサーチとドキュメント作成の半分はCoworkに、リポジトリに触れる半分はClaude CodeかCodexに、という分担が現実的です。プラグインローンチの全体像についてはThe New Stackの記事が参考になります。
どう使い分けるか：判断テーブル
すべての軸で勝つツールはありません。私が日常的に使っているおおまかなマッピングは以下の通りです。
| タスク | 使うツール | 理由 |
|---|---|---|
| 未知のコードの調査 | Claude Code | ローカルでの深いインタラクティブ調査 |
| 中小規模の実装修正 | Claude Code または Codex | インタラクティブか投げっぱなしか——好みで選ぶ |
| バグ調査・デバッグ | Claude Code | 仮説を一手ずつ絞り込んでいく |
| テストカバレッジの追加 | Codex | 並列化しやすく、対話の必要性が低い |
| リファクタリング | Claude Code | 進行に合わせて差分を段階的にレビューできる |
| PRレビュー | Codex |
@codex review で一次レビューを自動化 |
| 技術リサーチ・比較資料 | Claude Cowork | リサーチ→整理→文書化を一気通貫で |
| 設計メモ・ADR作成 | Claude Cowork | 構造化されたドキュメント生成に強い |
| README・仕様書のドラフト | Claude Cowork | 既存ファイルを読み込み、一貫した文書を作成 |
簡単な目安はこうです。Codexは投げっぱなしにできる非同期バッチ作業に、Claude Codeはループに留まっていたいインタラクティブな作業に、Coworkはdiffではなくドキュメントで終わる作業に向いています。
本当にうまくいくワークフロー
これらのツールを使っていて悪い結果になる最も多い原因は、「とりあえず実装して」といきなり依頼してしまうことです。一貫して良い結果を生むワークフローは次の通りです。
- 調査する。 何かを触る前に、コードベースと変更による影響範囲を理解させる。
- 計画を提案させる。 コードではなくアプローチを提案させる。
- 計画をレビューする。 ← 人間のチェックポイント。ファイルを触る前にアプローチを承認する。
- 小さなステップで実装する。 一度に複数ファイルをまたぐ大規模な書き換えではなく、機能やファイル単位で。
- テストを実行する。 既存のテストが通ることを確認する。
- 差分をレビューする。 ← 人間のチェックポイント。すべての行を必ず自分の目で読む。
- 必要なら修正する。 具体的な問題点をフィードバックし、再実装させる。
- 最終判断を下す。 ← 人間のチェックポイント。マージとリリースは人間の判断として残す。
8ステップのうち3つが明示的な人間のチェックポイントであることに注目してください。これは単なる摩擦ではなく、「エージェント＝自動操縦ではなくパートナー」という考え方の実際のレバレッジが効いている場所です。1行の依頼からいきなりステップ4へ飛ぶことが、私自身が経験した・読んだ中でほぼすべての悪いエージェント体験の根本原因でした。
AIエージェントを使いこなすための8原則
振り返ってみると常識のように聞こえますが、だからこそタスクの最中に忘れがちなものでもあります。
- いきなり実装に飛びつかない。 まず調査させ、変更計画を提案させる。
- 1タスク・1目的。 関係のない複数の変更を1つの依頼にまとめない——まとめると、それぞれを個別に評価できなくなる。
- 変更の範囲を明示的に絞る。 どのファイル・ディレクトリが対象内/対象外かを明言する。
- 制約を先に伝える。 「APIスペックは変更しない」「新しい依存は追加しない」など、エージェントが動き出す前に伝える。レビュー段階で意外な差分に気づいてからでは遅い。
- テスト実行を必ず指示する。 「テストを実行し、結果を報告すること」と明示的に依頼する——実行されたと勝手に仮定しない。
- 人間は必ず差分をレビューする。 どれだけ要約がきれいに見えても、信頼だけでマージしない。
- 重要な設計判断をAIに委ねない。 アーキテクチャとセキュリティの判断は自分で下す。
- やってはいけないことを明示的に伝える。 禁止事項は平易な言葉で書き出す——エージェントの推測に頼らない。
実践的なプロンプトテンプレート
原則はうなずきながら読むのは簡単ですが、締め切りのプレッシャーの中では忘れがちです。そこで、私が実際に使い回している3つのプロンプトを、使うツールに合わせて少し調整した形で紹介します。
1. コードベース調査の依頼（未知のコードに対する最初の一手として常に使う）：
このリポジトリを調査し、ログイン処理全体の構造を説明してください。
まだファイルは編集しないでください。
特に以下を確認してください：
- 認証のエントリーポイント（エンドポイント）
- 関連するAPIとミドルウェア
- DBのテーブルとスキーマ
- エラーハンドリングの方針
- テストの有無とカバレッジ
最後に、安全に変更を行うための手順を提案してください。
ここで効いている2行は「まだファイルは編集しないでください」と、具体的なチェックリストです。前者がないと、コードの理解に自信を持ったエージェントが、頼んでもいないのに「親切に」あれこれ修正し始めることがあります。後者がないと、調査は最初にそれらしく見える答えで止まりがちです。
2. 実装依頼（最小diffの原則）：
上記の調査結果に基づき、最小限の差分で修正してください。
制約：
- 既存のAPIスペックは変更しない
- 既存のテストはすべて通すこと
- 新しい依存ライブラリは追加しない
- 変更前に対象ファイルの一覧を提示すること
- 実装後に実行すべきテストコマンドを示すこと
- src/auth/ 配下のファイルのみ変更可とする
「最小限の差分」という最初の一文がかなりの仕事をしています。制約なしに任せると、エージェントは——熱心な若手エンジニアと同じように——ついでに近くのコードまで「改善」してしまうことがあります。ファイルスコープ（ここでは src/auth/）を固定することが、このテンプレート全体の中で最もレバレッジの高い一行です。
3. 差分レビューの依頼（自分が見る前にエージェント自身にセルフレビューさせる）：
現在の差分をレビューしてください。
レビュー基準：
- 仕様を満たしているか
- 既存の機能を壊していないか
- セキュリティ上の問題はないか
- 不要な変更が含まれていないか
- テストカバレッジが不十分な箇所はないか
問題があれば重要度（High / Medium / Low）で分類してください。
Highの問題がある場合は、修正案も提示してください。
これは前述の原則6（人間によるレビュー）の代わりにはなりませんが、構造化されたセルフレビューを一段挟むことで、自分の目に届く前に一定の割合の問題を発見でき、重要度分類は実際にレビューする際の優先順位付けにも役立ちます。
いずれ必ず遭遇する失敗パターン
これらのツールを導入したチームの誰に聞いても、あるいはどの記事を読んでも出てくる典型的な失敗と、実際に効く対策をまとめました。
| 失敗パターン | 対策 |
|---|---|
| 関係のないファイルまで変更してしまう | 対象ファイル・ディレクトリを明示的に指定する |
| 仕様を勝手に解釈してしまう | 制約と成功基準を事前に明示する |
| 不完全なテストを「完了」と報告する | 「テストを実行し、結果を報告すること」を必須化する |
| 許可なくDBスキーマやAPIスペックを変更する | 冒頭で変更禁止項目をリスト化する |
| 許可なく依存ライブラリを追加する | 「新規ライブラリ追加禁止」を明示的に伝える |
| 一度に大規模すぎる変更を行う | 1タスク・1目的に分割する |
| セキュリティリスクのあるコマンドを実行する | 確認モードを使用し、権限を最小化する |
これらはすべて同じ根本原因に行き着きます——書いた瞬間には具体的に思えた指示が、実は曖昧だったということです。「ログイン処理を直して」は、フルアクセス権を持つエージェントが解釈し始めるまでは具体的に感じられるものです。
セキュリティリスクを最小化する：権限管理の鉄則
短く、譲れないリストです。
絶対にしないこと：
- プロンプトにAPIキー・トークン・認証情報を貼り付ける
- 本番環境への直接的な操作権限を与える
- 確認なしに破壊的なコマンド（
rm -rf、DROP TABLEなど）を実行させる
やるべきこと：
- 自動実行ではなく、提案・確認モードから始める
- デフォルトは読み取り専用とし、信頼が積み上がってから権限を広げる
- 自動実行を許可するのはステージング環境に限定する
- 機密情報は環境変数で管理し、プロンプトには直接書かない
- 違和感がないときも含め、実行ログのレビューを習慣化する
このセクションから1行だけ持ち帰るとすれば——よく読まずに確認操作を y で承認するコストは、その瞬間においては読んだ上で承認するコストと同じに見えます。しかし、それが間違っていた場合、1週間後にはまったく違う結果になります。
AIに委ねてはいけないこと
これらのツールがどれほど強力になっても、いくつかの判断は人間に残り続けます。
- 要件定義・仕様の決定 — 何を作るかはビジネス上の判断である
- アーキテクチャの決定 — システム全体の設計方針
- セキュリティ判断 — 脆弱性とリスクに対する最終評価
- 品質基準の決定 — どのテストカバレッジ・レビュー基準を許容するか
- 最終レビュー — マージ前に人間がコードを読む
- リリースの決定 — 本番への最終的な出荷判断
理由はシンプルです。エージェントは与えられた指示のスコープ内で最適化を行いますが、ビジネス上の文脈や組織の制約、あるリスクと別のリスクを天秤にかけるような判断は、プロンプトで完全に指定しきれるものではありません。これは次のモデルリリースで解消される一時的な制約ではなく、結果に対して責任を負う人間に判断が残り続ける構造的な理由です。
これらのツールが本当に得意なこと
その境界線の反対側には、積極的に委譲する価値のある作業が数多くあります。
- 既存コードの調査と変更影響範囲の把握
- 小さなバグ修正や型エラーの解消
- テストカバレッジの作成・拡充
- ドキュメント作成（README、APIスペック）のドラフト
- 人間がレビューするためのリファクタリング案の作成
- PRレビューの一次対応支援
- コード重複の解消と定型的なクリーンアップ
- 機械的な変換作業（型注釈の追加、同期処理から非同期処理への移行など）
時間削減効果が実際に現れるのはここであり、その効果は決して些細なものではありません。OpenAIは自社のエンジニアリング組織内において、Codexを「リファクタリング、リネーム、テスト作成といった、集中を妨げる定型的かつスコープの明確なタスク」のデフォルトツールとして位置づけているとCodexのローンチ記事で述べています。また、OpenAI社内での利用状況に関する報道では、一部のワークフローにおいてCodexが自社アプリケーションコードの大部分を生成しているとされています（LeadDevによるOpenAIチームへのインタビュー記事より）。古いスナップショットではなく現在の数値を確認したい場合は、vals.aiのSWE-bench Verifiedリーダーボードをブックマークしておく価値があります。AnthropicもOpenAIも、おおよそ月単位でモデルを更新しており、リーダーボードもそれに合わせて変動します。
業界でよく引用される「自動化30%」のような統計に対する正直な見方は——方向性としては事実だが、組織固有であり、自分のコードベースに対する保証ではない、というものです。言語・テストカバレッジ・チケットがどれだけ明確にスコープされているかによって、実際の効果は本当に変わります。
ツールごとに採用する価値のあるTips
Codex：
- プロジェクトのルールや禁止事項、規約を記載した
AGENTS.mdを整備する——セッション開始時に自動的に読み込まれます。 -
@codex reviewを、たまに手動で頼むものではなく、PRに対する常設チェックとして運用する。 - 難しいバグに対しては
--attemptsオプションを使い、複数の候補解を並列生成して最良のものを選ぶ——逐次的に試行錯誤するより効率的です。
Claude Code：
-
CLAUDE.mdを常に最新に保つ——アーキテクチャ概要、禁止事項、正確なテストコマンドなど。これが長時間のセッションでも一貫した挙動を保つ鍵になります。 - 「このファイルは何をしているのか？」という疑問には、専用のExploreエージェントを実装方針を決める前に使う。
- 長いセッションでコンテキストが肥大化したら
/compactを使う——重要な作業メモリを保持したまま履歴を圧縮できます。 - ヘッドレスモード（
claude -p）はCI/CDパイプラインやGitHub Actionsへの統合に使え、自動化・スクリプト化された実行が可能になります。
Claude Cowork：
- 繰り返し発生するリサーチ・ドキュメント作成系のワークフローには、毎回コンテキストを説明し直すのではなくプラグインに頼る。
- 既存の仕様書があるローカルフォルダを指定し、ドラフトが汎用的な定型文ではなくチーム実際の規約を引き継ぐようにする。
- リサーチ→比較表作成→ADR作成というパイプラインを1つのタスクとして一気通貫で任せる——この一連の引き継ぎこそ、単なるチャットセッションに対するCoworkの優位性が発揮される場面です。
チーム全体への展開
個人での試行段階を過ぎたら：
-
AGENTS.md/CLAUDE.mdをリポジトリで共有する。 新規メンバー（人間にもエージェントにも）のオンボーディング資料を兼ねます。 -
PRレビューを自動化する。
@codex review（またはClaude Code側の同等機能）をCIに組み込み、レビュー基準をチームとして標準化する。個々人がバラバラに基準を作るのを避ける。 - タスクの振り分けを意図的に最適化する。 テスト・型エラー修正・ドキュメント更新といった定型作業はデフォルトでエージェントに委ねる。設計・アーキテクチャの議論は人間が主導する。
- コードレビューの基準を譲らない。 AIが生成したコードも、人間が書いたコードとまったく同じレビュープロセスを通す。差分がツールから出てきたものだからといって、エージェントの出力を批判的に評価するスキルが不要になるわけではありません。チームメンバー全員がこのスキルを持つ必要があります。
今日から始めるために
まだワークフローに組み込んでいないなら、現実的なペースはこのようなものです。
1週目 — まず自分で試す。 個人プロジェクトでClaude CodeかCodexを動かしてみる。最初は調査タスクのみに限定し、実装はさせない——ファイルを触らせる前に、「良い計画」とはどんなものかの感覚を養うためです。
2〜4週目 — 小さなステップで委譲する。 テスト追加や型エラー修正など、本当に小さくスコープの明確なタスクを任せる。信頼できるプロンプトテンプレートを構築する。すべての差分を実際に読む習慣をつける——流し読みではなく。
2ヶ月目以降 — チームに展開する。 AGENTS.md / CLAUDE.md を維持・共有する。自動PRレビューを整備する。成功体験だけでなく、ヒヤリハットもチームで共有する——失敗談は成功談と同じくらい、あるいはそれ以上に学びになります。
ここだけ読むならこれだけ
AIエージェントはエンジニアの代替ではありません。リサーチ・実装・テスト・レビュー支援といった作業単位を委譲できる開発パートナーであり、実際にリスクを伴う判断は人間が握り続けます。
委譲がうまくいくかどうかを左右するのは、次の3点です。
- 作業を小さな単位に分解する。 大きく曖昧な依頼こそ、悪い結果のほとんどの根本原因です。
- 調査→計画→実装→テスト→レビューというループを最後まで踏む。 実装にショートカットしない。
- AIが作業を行い、人間が判断と責任を持つ。 設計・セキュリティ・最終判断はあなたの仕事のまま残ります。
これから重要になる2つのスキルは、実は新しいものではありません——明確な指示を書く力と、返ってきた出力を批判的に評価する力です。どちらも、もともと優れたエンジニアの一部だったスキルです。エージェントはただ、それを「見える化」しただけなのです。
参考リンク：OpenAI Codex ドキュメント、Claude Code ドキュメント、Claude Cowork 製品ページ