AIコーディングエージェントの使い分けメモ：ChatGPT・Codex・Claude Code・Gemini
AIを1つだけ契約して全部を任せる、というやり方は、自分の作業には合いませんでした。調査に向いた道具と、コードを触らせる道具と、文章を磨く道具は、それぞれ求めるものが違います。今は複数のAIを「担当」として使い分けていて、この形に落ち着いています。
大まかな分担はこうなっています。
| 作業 | 主に使うAI | 理由 |
|---|---|---|
| 調査・要件整理 | ChatGPT | 対話しながら論点を広げたり絞ったりしやすい |
| コード編集 | Codex | ローカルのリポジトリを直接触れる |
| 文章の推敲・別視点チェック | Claude など他のAI | 自分と実装担当の両方から距離を置ける |
| 大量ドキュメントの要約 | Gemini | Googleのサービス連携が効く場面がある |
以下、それぞれ「得意な頼み方」と「事故る頼み方」を分けて書きます。ここが本題です。
調査と要件整理は ChatGPT
新しい作業に入るとき、まず ChatGPT で壁打ちをします。仕様が固まっていない段階では、正解を出すことより「論点を洗い出す」ことの方が価値があります。要件の抜け、想定すべき例外、代替案の候補。こういう散らかった相談はチャット形式が向いています。
得意な頼み方は、背景と制約を先に渡すこと。「誰が使う機能か」「変えてはいけない既存仕様は何か」を最初に書いておくと、的外れな提案が減ります。逆に事故るのは、いきなり「この機能のコードを書いて」と投げる頼み方。コードを書くのは次の担当の仕事と決めて、ここでは整理に徹する方が結果的に速いです。
注意： 設計判断が固まっていないコードは、動いても後で作り直しになります。
コード編集は Codex 中心
実装は Codex に任せることが多いです。Codex は OpenAI のコーディングエージェントで、ChatGPT・エディタ・ターミナルから使えます。ローカルのファイルを読み、編集し、テストなどのコマンドも実行できるので、「この範囲を、こう直して」という具体的な作業を渡すのに向いています。
得意な頼み方は、変更範囲と守るべき既存仕様を明示することです。「この関数の外側は触らない」「既存のテストは全部通すこと」と線を引いておく。事故る頼み方は、範囲を指定せず「全体をきれいにして」と丸投げするパターンで、意図しない差分が大量に混ざります。もう1つ、自分の中で決めている線引きがあります。コミットのレビューと push は自分でやる。差分を自分の目で読んでからでないと取り込まない、という運用です。
注意： エージェントが書いたコードを無検品で本流に入れるのは、結局あとで自分の首を絞めます。
なお、Claude Code（Anthropic のエージェント型コーディングツールで、ターミナルや IDE で動きます）も性質としてはこの「実装担当」に近い道具です。どちらを主担当にするかは好みと手元の環境次第で、自分の場合は Codex を中心に据えています。大事なのは道具の優劣より、「実装させる道具は1つに寄せて、他は別役に回す」という分担の固定でした。
推敲と別視点チェックには、実装者と別のAIを
文章の推敲や、設計・記事のチェックには、実装を担当していないAIを使います。理由は単純で、書いた本人（人でもAIでも）は自分の前提に引っ張られるからです。この記事を含むブログ記事の品質チェックも、実装担当とは別のAIに見てもらっています。
得意な頼み方は、「良いと言わず、問題点を先に挙げて」と頼むこと。忖度のない指摘が欲しい場面なので、評価ではなく検証を依頼する形にします。事故るのは「これでいいか確認して」と聞く頼み方です。
注意： 「これでいいか確認して」と聞くと、だいたい肯定が返ってきて何も得られません。
チェックの観点そのものは、AIに書かせた記事の品質チェック：出典・捏造・定型文を見抜くに整理しました。
Gemini は Google 連携と大量ドキュメントで
Gemini の出番は、Google のサービスと絡む作業です。Google ドライブに置いた長文ドキュメントやフォルダ単位の要約など、Workspace 側に最初から組み込まれている機能が効く場面では、わざわざファイルを別サービスへ持ち出すより速い。道具ごとに「ここだけはこれ」という居場所を作っておくと、毎回どれを使うか迷う時間が消えます。
注意： 逆に、日常の調査やコード作業の主担当にはしていません。出番は Google のサービスと絡む作業に絞ります。
ここまでの使い分けを、頼み方つきの早見表にするとこうなります。
| ツール | 担当 | 得意な頼み方 | 事故る頼み方 |
|---|---|---|---|
| ChatGPT | 調査・要件整理 | 背景と制約を先に渡して、論点を洗い出す | 設計が固まっていない段階で、いきなり「コードを書いて」と投げる |
| Codex | コード編集（実装担当） | 変更範囲と守るべき既存仕様を明示して渡す | 範囲を指定せず「全体をきれいにして」と丸投げする |
| Claude など他のAI | 文章の推敲・別視点チェック | 「良いと言わず、問題点を先に挙げて」と検証を頼む | 「これでいいか確認して」と聞く（肯定が返ってくる） |
| Gemini | 大量ドキュメントの要約・Google連携 | ドライブの長文やフォルダ単位の要約など、Workspace 連携が効く場面で使う | 日常の調査やコード作業の主担当に据える |
使い分けで迷ったときの判断基準
最後に、自分が迷ったときに立ち返る基準を3つだけ。
- 「考える」作業か「触る」作業か（→「調査と要件整理は ChatGPT」「コード編集は Codex 中心」） 作業が「考える」なのか「触る」のか。考える作業はチャット型、リポジトリを触る作業はエージェント型、と分けると大抵うまくいきます。
- 取り消しが効くかどうか push や公開のように戻しにくい操作は、AIに実行させず人間の確認を必ず挟む。任せる作業と任せない作業の線引き全般は、AIに任せる作業・任せない作業の線引きにまとめています。
- チェック役を別に確保できているか（→「推敲と別視点チェックには、実装者と別のAIを」） 何かを作らせるAIと、それを検証するAI（または自分）が別人格になっているかは、品質に直結します。
このサイトのリニューアル自体もこの分担で進めていて、実装は Codex、記事の品質管理は別のAI、最終確認は自分、という形になっています。AIを1つの万能選手として使うより、小さい役割分担のチームとして扱う方が、少なくとも自分の作業には合っていました。