業務でAIエージェントと開発するときの「基本のキ」：Explore / Plan / Code / Commit

はじめに

うぐいすソリューションズ Advent Calendar 2025の 6 日目担当の zen です。

2025 年は「AI エージェント元年」と言ってよいほど、コーディングを支援する AI ツールが一気に増えた 1 年でした。
Claude Code や Cursor、Codex、Gemini CLI、最近だと antigravity のようなサービスやツールまで、選択肢はどんどん増えています。

一方で、こんな悩みもよく見かけます。

• 新機能や開発ハックの情報量が多すぎて、キャッチアップに疲弊する
• 0→1 の個人開発では便利でも、業務のコードベース（独自のドメイン知識やリポジトリ秩序がある）ではうまくハマらない
• チームで「とりあえず AI エージェントを導入した」ものの、メンバーごとに使い方がバラバラで効果が見えづらい

そこで本記事では、

• どんな AI ツールや新機能が出てきても揺らがない「基本のキ」

として、Anthropic 公式ブログの
Claude Code Best Practices – Try common workflows
に登場する

Explore → Plan → Code → Commit

という 4 ステップを、業務開発に寄せて具体的にどう運用するかを掘り下げていきます。

ここで紹介する考え方は Claude Code 専用テクニックではなく、いずれのコーディング系 AI エージェントでもほぼ共通で使えるワークフローです。

なぜ「基本のキ」が重要なのか

まず強調しておきたいのは、次の 2 点です。

• AI エージェントの新機能やハックはこれからも次々と出てくる
• それらの流行り廃りに振り回されないためには、共通する基本動作を身体で覚えておくのが一番ラク

私自身も、新しい機能のキャッチアップに追われ続けて「これ、いつまで続くんだろう……」となった時期がありました。
そこから一度立ち止まり、

「ツールは違っても、結局やってほしいことの骨格は同じでは？」

と整理した結果、行き着いたのが Explore / Plan / Code / Commit の 4 ステップでした。

この 4 つさえ押さえておけば、

• ツールが変わっても、やることはほぼ同じ
• チームメンバーにも説明しやすい
• ドメイン知識が濃いプロダクトでも、AI 側に正しいコンテキストを渡しやすい

といったメリットが得られます。

以降では、それぞれのステップを「業務コーディング目線」で具体的に見ていきます。

Explore：まずは「ちゃんと理解してる？」を確認する

多くの人がやりがちなのが、いきなり実装指示を投げてしまうことです。

しかし、業務のコードベースには

• 過去の経緯で生まれた暗黙のルール
• チームごとの命名規約や責務の分割方針
• 特有のドメイン知識

がたっぷり詰まっています。
これらを AI がどれくらい理解できているかを確認せずに実装させる と、だいたい後からツッコミどころ満載のコードが出てきます。

そこで最初のステップとして、

「お前、ちゃんと理解してくれてるの？」を確認するフェーズ

を必ず挟みます。

具体的な指示例

まずは、関係しそうなファイルを AI に読ませたうえで、次のように聞いてみます。

{@必要なファイル群} について実装内容を深く解釈し、その理解を私に提示してください。
もし曖昧な理解の箇所があるならば私に質問をしてください。

ここで返ってきた内容を読むと、日頃からそのコードを書いている人ほど、

• 「いや、そこはそういう設計じゃないんだよな」
• 「このサービスの責務、全然違うところにフォーカスしてるな」

と感じる瞬間が出てくるはずです。

ここでやるべきこと

ポイントは、AI の理解のズレを「AI のせい」にしないことです。

実際には、

• 必要なコンテキストをまだ渡し切れていない
• 曖昧な仕様や例外パターンを伝えていない
• チーム内でしか通じない前提を共有していない

といったケースがほとんどです。

したがって、このフェーズでは：

• AI が示した理解の中で 曖昧 or 間違っている箇所を特定 する
• それをもとに 追加の説明やファイル参照を、小さめの粒度で渡し直す
• 「そうそう、うちの実装はそんな感じなんだよ」と思えるレベルまで 会話を往復 する

ことを意識してみてください。

会話が長くなってきたら、最後にもう一度こう頼むのもおすすめです。

ここまでの理解を一度まとめ直してください。
特に、（◯◯サービス／△△ドメイン）まわりの責務と、今回変更対象になりそうな箇所を整理してほしいです。

この「Explore」の質が高いほど、後続の Plan/Code/Commit がスムーズになります。

Plan：実装させる前に「設計レビュー」まで済ませておく

Explore で AI 側の理解を整えたとしても、まだ実装はさせません。

次にやるのは、

「その理解のもとで、どう実装しようとしているのか？」を事前に確認すること

です。ここをすっ飛ばして「じゃあ書いて」とやると、

• 責務の分割がしっくりこない
• テーブル設計や型設計が甘い
• テスト戦略が考えられていない

といった状態のまま Code フェーズに突入し、最終的に「書き直しになってトータル遅い」ということになりがちです。

指示例：要件定義書（実装計画書）を書かせる

私がよく使っているプロンプトはこんな形です。

理解した内容を元にして{実際に実装したいこと}を行いたいと思っています。
それを実現するための要件定義書（実装計画書）をTODOリスト付きでmdファイルで作成してください。
最高のアウトプットを得るために不明な点があれば私に質問してください。

これにより、AI は

• どのファイルをどう変更するか
• どんな関数・クラス・コンポーネントを新設／改修するか
• どの順番で進めるのが良さそうか
• どこが曖昧で、どんな追加情報が必要そうか

を 1 つの Markdown（例：plan.md）にまとめてくれます。

ここでの人間の仕事

この Plan フェーズが、人間側の仕事の山場 だと思っています。

• AI が書いてきた計画を「設計レビューする」つもりで読み込む
• ツッコミどころがあれば、Markdown を直接修正する or 追加指示で差分を反映させる
• 抜け漏れがないか（例外パターン・非機能要件・パフォーマンス・セキュリティなど）をチェックする

このときのコツは：

• 「雑にダメ出しをする」のではなく、計画そのものを一緒に育てる感覚で修正していくこと
• 一度確定させたら、そのplan.mdをこの後の会話の“単一の真実”として扱うこと

です。

作成された計画ファイルは、個人なら一時ファイルとして削除しても良いですし、チーム開発ならあえて専用の/docsフォルダに残しておくのもおすすめです。
「このタスク、どういう設計で進めたんだっけ？」を後から辿りやすくなります。

Code：TODO に沿って「機械的に」実装してもらう

Explore と Plan がしっかりできていれば、実装フェーズの仕事の 9 割は終わっています。

ここでは、AI には「考えさせる」のではなく、

合意済みの TODO リストに沿って、機械的に手を動かしてもらう

ことに集中してもらいます。

指示例：plan.md駆動で実装させる

Plan フェーズで作った Markdown に TODO リストがある前提で、次のように指示します。

{@作成したmdファイル} のTODOリストに沿って、実装を開始してください。

1つのTODOが完了するごとに、実際に変更したファイルと要約を箇条書きで報告してください。
大きめの変更を行う場合は、事前に私に確認を取ってください。

このとき、人間側は

• TODO の順番や粒度が適切か
• 途中で仕様の見落としに気づいたら Plan に立ち戻るべきか

を見極める「監督」のような立ち位置になります。

変な実装が出てきたときのリカバリ手段

もしここで明らかに変な実装が出てきたら、取れる手段はだいたい次のいずれかです。

1. コンテキストリセット
   • 長いやりとりでコンテキストが破綻している可能性があります
   • チャットを新規にする or /clear でコンテキストをクリアし、plan.mdだけを渡し直す
2. 計画ファイルのアップデート
   • 実装しながら見えてきた知見を、plan.md側にも反映させる
   • 「実装が計画からズレた」のではなく、「計画が現実に追いついていない」と捉えるイメージ
3. モデルやツールの切り替え
   • どうしても相性が悪そうなら、別のモデルやツール（例：Claude Code → Cursor）に Plan を渡して続きからやってもらう

重要なのは、「変になったら一度立ち止まり、Explore or Plan まで戻る」 という発想を持っておくことです。

Commit：Git 運用も AI に手伝ってもらう

最後のステップは Commit です。
ここまで来たら、Git まわりの単調作業も AI にやらせてしまいましょう。

指示例：コミット単位の設計まで任せる

私がよく使っている指示は、だいたいこんな形です。

git statusやgit diffを実行し、適切なファイル単位で区切りながらcommitしてください。

- commitメッセージは日本語で書いてください
- サマリ行のあとに、ディスクリプションも1〜3行程度で記載してください
- テストが必要な変更については、commit前に `yarn test` を実行し、結果も簡単に報告してください

こうすることで：

• 変更のかたまりごとに、意味のあるコミット が自動で作られる
• コミットメッセージとgit logが整い、人間も AI も後から辿りやすくなる
• 将来的にgit logを丸ごと AI に渡して「この機能の歴史を教えて」といった使い方もできる

といったメリットがあります。

とはいえ push / pull は人間が握る

個人的には、

• git add
• git commit

までは AI に任せても良いと思っていますが、

• git push
• git pull

といったリモート操作は、基本的に人間が握っておく のをおすすめします。

もし GitHub MCP などを使っている場合は、

• push したあとの Pull Request 作成
• PR ディスクリプションの執筆

といった「テキスト生成部分」だけ AI に任せる、という分担もありです。

Explore / Plan / Code / Commit を業務に馴染ませるコツ

最後に、この 4 ステップを 実際のチーム開発で運用するうえでのコツ をいくつか挙げておきます。

1. 用語をチームで共有する

まずはチーム内で、

• 「いきなり Code に行かず、必ず Explore と Plan を挟もう」
• 「Plan はplan.mdに落としてから実装に入ろう」

といった 共通言語 を作っておくとスムーズです。

Slack や Notion などで、Explore/Plan/Code/Commit の簡単な説明と、よく使うプロンプト例を共有しておくのもおすすめです。

2. plan.mdをちゃんと資産として扱う

Plan フェーズで作った Markdown は、雑に捨ててしまうにはもったいない情報が詰まっています。

• docs/ai-plans/ のようなディレクトリを切って保管する
• 大きめの機能開発では、docs/feature-◯◯/plan.mdのようにまとめる
• レビュー時に「この Plan どおりに実装されているか？」を確認するチェックリストとして使う

といった形で、コードと同じくらい「生きたドキュメント」として扱うと、後から効いてきます。

3. 新機能やハックは「この 4 ステップのどこに効くのか？」で評価する

今後も AI エージェントの新機能や「○○ すると爆速で開発できるハック」は出続けるはずです。

そうした情報を見かけたときは、

• これは Explore の質を上げてくれるのか？
• Plan を自動で作るのに役立つのか？
• Code フェーズを高速化してくれるのか？
• Commit やテストまわりを楽にしてくれるのか？

といった観点で、「自分のワークフローのどこを強化してくれるのか」を評価してみてください。すると大体 AGENT.md や rules に対してチームでどう向き合うか、というところからスタートすることが多くなると思います。

そうすると、

• 「なんとなくすごそうだから全部試す」状態から卒業できる
• 自分やチームにとって本当に効くものだけを選びやすくなる

はずです。

まとめ

本記事では、Anthropic のベストプラクティスとして紹介されている

Explore → Plan → Code → Commit

という 4 ステップを、**業務で AI エージェントと開発するときの「基本のキ」**として整理し直してみました。

• Explore：AI が本当に文脈を理解しているかを、一度立ち止まって確認する
• Plan：実装前に、要件定義書／実装計画書を一緒に作り、設計レビューまで済ませる
• Code：合意済みの TODO リストに沿って、実装作業を AI に任せる
• Commit：Git の単調作業やコミットメッセージ作成も AI に手伝ってもらう

という骨格さえ身につけておけば、新しいツールが出てきても慌てる必要はありません。
まずは、いま使っている AI エージェントで 「次のタスクだけでも、この 4 ステップで進めてみる」 ところから試してみてください。

そのうえで、新機能や開発ハックは「このワークフローのどこを強化してくれるのか？」の視点で、ゆっくり取り入れていけば十分だと思っています。

2023 年末に Cursor を使い始めたところから早 2 年経ちましたが、今年は特にエンジニアとしての仕事が大きく変わった 1 年でした。来年はどんな開発体験の変化があるか、楽しみにしながら年を過ごそうと思います。