ブログClaude Codeを活用した開発の進め方|現役CTOが教える実践5ステップ

Claude Codeを活用した開発の進め方|現役CTOが教える実践5ステップ

Claude Code開発の進め方(実践5ステップとチーム定着)を示すアイキャッチ画像

Claude Codeは、やりたいことを言葉で伝えるだけで、コードベース全体を読み取り、実装からテスト、コミットまでを自律的に進めるコーディングエージェントです。個人で試すだけなら、その日のうちに手応えを得られます。

一方で、実際の開発に組み込もうとすると壁にぶつかります。開発の進め方に型がなく、成果がその日の指示の仕方次第でばらついてしまう。チームに広げようとした途端、書き方も品質もメンバーごとにばらばらになってしまう。AI駆動開発に取り組む現場から、こうした相談を受けることが増えました。

筆者はDX/AX SaaSの実務に10年携わり、現役CTOとして5.5年、今もClaude Codeを軸に実際のプロダクトを開発・提供し続けています。前職のSaaSベンチャーではCTOとしてChatGPT・Cursor・Devinといったツールを開発組織へ導入してきました。その過程でうまくいったことも、個人の実験止まりで終わった失敗も両方経験しています。

本記事では、その実体験をもとに、Claude Codeを活用した開発の進め方を体系的に解説します。Claude Codeで何ができるのか、対応環境と料金、最初に整える環境構築という前提を押さえたうえで、日々の開発を回す実践5ステップ、開発を加速する4つの機能、そして多くの記事が触れない「チームの開発プロセスへの組み込み方」と注意点までを順に解説します。

目次

Claude Codeとは?開発スタイルを変えるコーディングエージェント

Claude Codeは、Anthropic社が提供する、コードを書く作業そのものをAIに任せられるツールです。「コーディングエージェント」と呼ばれる種類のAIで、人間から指示を受けると、プロジェクトの中身を自分で読み、必要な変更を考え、実際にファイルを書き換え、動作確認まで行います。

例えるなら、「この機能を追加して」と一言伝えるだけで、関連するファイルを自分で探し出し、進め方を考え、実装し、テストまでしてくれる新人エンジニアのような存在です。開発者がやることは、コードを1行ずつ自分で書くことではなく、「何を作りたいか」を明確に伝え、出来上がったものが正しいかを確認することに変わります。

従来のコード補完型AIツールとの違い

これまでの開発向けAIの主流は、GitHub Copilotに代表される「コード補完型」でした。これはエディタでコードを書いていると、続きの候補をAIが提案してくれるものです。あくまで「書く速度」を上げる道具であり、どこに何を書くか決め、提案を採用するか判断し、動作を確かめるのは常に人間でした。

両者の違いを整理すると、次のようになります。

観点コード補完型(Copilotなど)Claude Code(エージェント型)
作業の単位1行〜数行の続きを提案「機能を作る」などのタスクをまるごと完遂
作業の主体人間が書き、AIは補助するAIが実装し、人間は指示と確認をする
動く範囲エディタのカーソル位置だけ複数ファイルの編集・コマンド実行・テストまで横断
人間の役割コードを書く・提案を取捨選択する要件を伝える・出来上がりを検証する

※Copilot自体も現在はエージェント機能を拡充していますが、ここでは補完型の代表例として対比しています。

Claude Codeでは、「この機能を追加して」と伝えるだけで、関連するファイルを探す、直す場所を決める、実際に書き換える、動作を確認する——という一連の作業をAI自身が最後まで進めます。人間がやるのは、最初に何を作りたいかを伝えることと、出来上がったものが合っているかを確かめることの2つだけです。

この違いは、日々の働き方にも表れます。コード補完型は、自分がキーボードを打っている間だけ役立つ道具です。一方でClaude Codeに任せている間、人間は別の作業を進められます。「AIに手伝ってもらう」から「AIに任せて、人間は確認する」へ。この感覚の変化こそが、開発の進め方を一から見直す価値を生んでいます。

Claude Codeで開発を始める前に整えるべき環境構築

Claude Codeでの開発は、最初の30分の設定で成果が大きく変わります。ここでは、使う環境を決めるところから開発の土台になる初期設定まで、着手前に整えておきたい4つを順に紹介します。

Claude Codeで開発を始める前に整えるべき環境構築の4ステップを示すインフォグラフィック

自分に合った利用環境を選ぶ

1つ目は、どの環境でClaude Codeを動かすかを決めることです。Claude Codeは1つの環境に縛られず、公式に提供されている主な利用環境は次のとおりです。

利用環境特徴
ターミナル(CLI)最も基本の形。コマンドラインからプロジェクト全体を操作できる
VS Code / Cursor拡張エディタ内で差分確認や会話履歴を扱える
JetBrains系IDEIntelliJ IDEAやPyCharmなどにプラグインとして導入できる
デスクトップアプリターミナル不要。複数セッションの並行実行やタスクのスケジュール実行に対応
Web(claude.ai/code)ローカル環境の構築なしにブラウザで実行できる

どれを選んでも中身は同じClaude Codeなので、自分の慣れに合わせて構いません。日常的にコードを書くならターミナルやIDE拡張、まず触って感触を掴みたい段階ならデスクトップアプリが扱いやすいでしょう。

なお、利用には基本的にClaudeのサブスクリプション、またはAnthropicのAPIアカウントが必要です。料金プランは改定されることがあるため、最新の条件は公式ドキュメントで確認してください。

インストールして初回セッションを始める

2つ目は、選んだ環境にインストールして、最初のセッションを開くことです。

初めてClaude Codeに触れるなら、ターミナル操作に慣れていなくても始められるデスクトップアプリからのスタートが安心です。公式サイトからアプリをダウンロードしてインストールし、起動したらAnthropicアカウントでログインするだけで準備が整います。あとは開発したいプロジェクトのフォルダを選んで話しかければ、その場でClaude Codeが動き出します。

ターミナルやIDEから使う場合は、公式ドキュメントの手順に従います。macOS/Linuxはコマンド1つで導入でき、プロジェクトのディレクトリへ移動して claude と入力すれば起動し、初回はログインを求められます。WindowsはPowerShell経由やWSL、VS Code拡張から入る方法がありますが、いずれもターミナルやエディタの操作にある程度慣れていることが前提です。

つまずきやすいのはツールの操作よりも、この後の「何をどう指示するか」です。例えば筆者は初回セッションでいきなり実装を頼まず、「このリポジトリの構成と主要な処理の流れを説明して」と質問することから始めます。AIにコードベースを読ませつつ、こちらも回答でAIの理解度を確かめられるので、最初の一歩として手堅いといえます。

CLAUDE.mdで開発の前提を共有する

3つ目は、CLAUDE.mdで開発の前提を共有することです。

CLAUDE.mdは、プロジェクトのルートに置くMarkdownファイルで、Claude Codeがセッション開始時に毎回読み込みます。技術スタック、コーディング規約、テストの実行コマンド、やってはいけないことなどを書いておくと、毎回説明し直す手間がなくなります。人間のメンバーに渡すオンボーディング資料のAI版と考えると分かりやすいでしょう。

正直に言うと、筆者も導入当初は「何を書けばいいのか」が分かりませんでした。現在は /init コマンドでClaude Code自身にプロジェクトを分析させて下書きを作らせ、実際に開発を進めながら「同じ指摘を2回したらCLAUDE.mdに追記する」という運用に落ち着いています。最初から完璧を目指すより、育てる前提で小さく始めるのが近道です。

権限設定とPlan Modeを既定にする

4つ目は、権限設定とPlan Modeを既定にすることです。

エージェントに実行権限を渡す以上、どこまで自動で進めてよいかの線引きが必要です。Claude Codeはファイル編集やコマンド実行の前に承認を求める仕組みを持ち、許可する操作を設定で制御できます。まずは承認を挟む設定から始め、信頼できる操作から徐々に自動化の範囲を広げていくと安全です。

あわせて既定にしたいのがPlan Mode(実装前に計画を立て、人間の承認を得てから実行するモード)です。いきなりコードを書かせると、意図と違う方向に大量のコードが生成されることがあります。計画の段階で認識のずれを直すほうが、生成後に修正させるよりはるかに安上がりです。

Claude Codeを使った開発の実践5ステップ

環境が整ったら、日々の開発をどう回すかです。筆者が実際のプロダクト開発で回している進め方を、5つのステップで紹介します。

Claude Codeを使った開発の実践5ステップを示すインフォグラフィック

ステップ1|要件を仕様として言語化する

1つ目のステップは、作りたいものを仕様として書き出すことです。

「ユーザー管理機能を作って」のような曖昧な指示では、AIは曖昧さを推測で埋めてしまいます。対象画面、データの流れ、エラー時の挙動、やらないことの4点を短くても文章にしてから渡すと、成果物の精度が目に見えて変わります。

このとき、仕様書づくり自体をClaude Codeに手伝わせるのが実務的です。要件を口語で伝えて「仕様として整理して。不明点は質問して」と指示すると、抜けている観点を質問の形で返してくれます。AIとの開発は、コードを書く前の言語化に時間を使うほど後工程が速くなります。

ステップ2|Plan Modeで実装計画を確認する

2つ目は、実装前の計画確認です。

Plan Modeで仕様を渡すと、どのファイルをどう変更するか、どんな順序で進めるかの計画が提示されます。ここで見るべきは「触ってほしくないファイルに手を出していないか」「影響範囲の見積もりが自分の認識と合っているか」の2点です。

計画がずれていたら、コードを1行も生成させる前に指摘して修正させます。例えば「認証まわりは既存の実装を使い回してほしいのに、新しく作り直す計画になっている」といったずれは、この段階なら『既存のAuthモジュールを再利用して』と一言添えるだけで直ります。

生成後に気づけば、作られたコードを読み解いて捨てる作業からやり直しです。レビューの負担が最も軽いのはこの段階で、経験上、計画レビューを省略して手戻りした時間のほうが、計画確認にかかる時間より確実に長くなります。

ステップ3|小さい単位で実装させる

3つ目は、実装をタスク単位で小さく区切ることです。

機能を丸ごと一度に作らせると、生成量が多すぎてレビューが追いつかず、問題の切り分けも難しくなります。計画をステップに分割し、1ステップ実装させてはビルドとテストが通ることを確認する。この繰り返しが結局最速です。

小さく区切る習慣は、AIの間違いを早く検出するためでもあります。方向性の誤りは生成量が少ないうちに見つかれば数分で直せますが、大量のコードに埋まってからでは発見自体が難しくなります。

目安として、筆者は1ステップを「ビルドが通り、テストで動作を確認できる最小のまとまり」で区切っています。例えばAPIを1本追加するなら、エンドポイントの追加とそのテストで一区切り。画面まで一気に作らせないことで、どこで壊れたかを常に直前のステップに絞り込めます。

ステップ4|テストとレビューで検証する

4つ目は検証です。

Claude Codeはテストの作成と実行、失敗時の修正まで自律的に行えるため、「実装したらテストを書いて通るまで直す」までをセットで指示します。検証の仕組みを与えるほど、エージェントは自走できるようになります。

ただし、AIが書いたコードをAI自身の報告だけで信じるのは危険です。筆者は別セッションのClaude Codeにレビュー専用の役割を与え、実装とは独立した目でコードを確認させています。それでも最終判断は人間の仕事です。特に認証・決済・データ削除に関わる変更は、必ず自分の目で差分を読みます。作業はAIに任せても、責任は移せません。

ステップ5|コミットからプルリクエストまで任せる

5つ目は、バージョン管理への反映です。

Claude CodeはGitと直接連携し、変更のステージング、コミットメッセージの作成、ブランチ作成、プルリクエストの発行までを一括で任せられます。変更内容を踏まえた説明文を自動で書いてくれるため、レビュアーへの引き継ぎコストも下がります。

さらにGitHub ActionsやGitLab CI/CDと連携すれば、プルリクエストへの自動コードレビューや、CI失敗をトリガーにした修正ワークフローまで組み込めます。ここまで到達すると、開発フローの中で人間が担うのは仕様の言語化とレビュー・承認に絞られてきます。

開発を加速する4つの拡張機能

5ステップが回り始めたら、次は開発速度を底上げする機能を取り入れます。実務での効果が大きい順に4つ紹介します。

開発を加速する4つの拡張機能(Skills・サブエージェント・MCP・Hooks)を示すインフォグラフィック

Skills|繰り返す作業を型にする

Skillsは、繰り返し行うワークフローを手順書としてパッケージ化し、Claude Codeに実行させる機能です。リリース作業、レビューのチェックリスト、定型レポートの生成など、「毎回同じ説明をしている作業」はすべてスキル化の候補になります。

効果的なのは、普段の業務のやり方をClaude Code自身に分析させてスキル化することです。自分では手順を意識していなかった作業ほど、型にしたときの再現性の効果が大きくなります。仕組みの詳細はClaude Skillsとはの記事で、呼び出し方や運用のコツはClaude Skillsの使い方の記事で詳しく解説しています。

サブエージェント|開発を並列で進める

サブエージェントは、1つのタスクを複数のエージェントに分担させる機能です。リードのエージェントが作業を調整し、調査・実装・テストなどのサブタスクを並行して進めます。それぞれが独立した作業スペースを持つため、メインの会話に余計な情報を持ち込まずに専門作業だけを任せられます。筆者がClaude Codeの使い方で最初に世界が変わったと感じたのは、この並列実行を知ったときでした。

例えば新機能の実装中に、別のエージェントへ既存コードの調査やドキュメント更新を並行で走らせる。人間が1人でも、開発の同時進行数を増やせるという感覚は、従来のツールにはなかったものです。

調査や単純作業のように、メインの実装と文脈を共有しなくても進む作業ほど切り出しやすく、待ち時間がそのまま別の成果に変わります。ただし依存関係のある作業を無理に並列化すると、あとで結果を突き合わせる手間が増えるので、切り出すのは独立して完結するタスクに絞るのがコツです。仕組みや作り方はClaudeサブエージェントとはの記事で詳しく解説しています。

MCP|外部ツールと接続する

MCP(AIツールを外部データソースへつなぐオープン標準)を使うと、Claude CodeからJiraのチケット、Slackのやり取り、データベースなどへ直接アクセスできます。チケットを開いて仕様を読み取り、実装し、完了報告をSlackへ流すところまでを、Claude Codeから離れずに進められます。

MCPの効果が表れるのは、コードを書く作業そのものより、その前後にあります。仕様を確認するために別のツールを開き、実装の前後で関係者へ共有し、進捗を報告する。こうしたやり取りに費やす時間は、実際にコードを書いている時間より長いことも珍しくありません。

MCPはこの見えないコストを削る機能だと捉えると、導入の優先順位を判断しやすくなります。まずは自分が1日に何度も開いているツールから接続すると、効果を実感しやすいはずです。

Hooks|品質チェックを自動で挟む

Hooksは、Claude Codeの動作の前後にシェルコマンドを自動実行する仕組みです。ファイル編集のたびにフォーマッタをかける、コミット前にリンターを走らせるといった品質チェックを、AIの作業フローに強制的に組み込めます。

人間に「毎回リンターを実行してください」と言い続けるのが難しいように、AIへの口頭指示も忘れられることがあります。

例えば「編集後は必ずフォーマッタをかける」「特定のディレクトリは書き換えを禁止する」といったルールは、CLAUDE.mdに書くよりHooksで強制したほうが確実です。CLAUDE.mdの指示が“お願い”なのに対し、Hooksは条件を満たさなければ処理を止める“関所”として働きます。ルールは指示ではなく仕組みにする。Hooksはその考え方をエージェント開発に持ち込む機能です。

個人利用で終わらせずチームに定着させる3つのポイント

Claude Codeを活用した開発に関する情報の多くは個人の生産性向上で止まっていますが、組織として成果を出す本番はここからです。

筆者はCTOとして開発組織にAIツールを導入する中で、個人には定着してもチームの標準にならないという壁を何度も見てきました。熱心な1人だけが使いこなし、その人が異動するとノウハウごと消える。この失敗を避けるための要点を3つ紹介します。

Claude Codeをチームに定着させる3つのポイントを示すインフォグラフィック

CLAUDE.mdとスキルをリポジトリで共有する

1つ目は、設定を個人の環境からリポジトリへ移すことです。

CLAUDE.mdやスキル、権限設定をリポジトリにコミットして共有すれば、誰がClaude Codeを起動しても同じ前提・同じ手順で動きます。新メンバーのオンボーディングも「リポジトリをcloneすれば開発環境の知見ごと手に入る」状態になります。

属人化したAI活用は、その人の退職とともに消える一時的な効率化にすぎません。例えば、熱心なメンバーが育てたCLAUDE.mdやスキルも、個人のローカルに置いたままではその人が抜けた瞬間にゼロに戻ります。プロンプトの工夫を個人のメモに溜めるのではなく、チームの資産としてバージョン管理する。この一手間が個人利用とチーム活用の分かれ目になります。

レビューとCIをAI前提に再設計する

2つ目は、開発プロセス側の見直しです。

AIがコードを量産できるようになると、ボトルネックは実装からレビューへ移ります。人間のレビューをどこに残すか、AIによる一次レビューをどこに挟むか、CIでどこまで自動検証するかを決め直す必要があります。

筆者のチームでは、AIレビューで機械的な指摘を先に潰し、人間のレビューは設計判断と仕様の妥当性に集中させる形に再設計しました。具体的には、命名やフォーマット、明らかなバグの指摘はAIの一次レビューに任せ、人間は「この設計で将来の変更に耐えるか」「仕様の解釈が合っているか」だけを見ます。

レビュー観点を、機械に渡せるものと人間が持つべきものに仕分けするのが再設計の第一歩です。ツールを導入しただけでプロセスが従来のままだと、レビュー待ちの行列が伸びるだけで、開発全体のスピードは上がりません。

効果を数字で計測する

3つ目は計測です。

導入効果を「なんとなく速くなった」で済ませると、経営層への説明も投資判断もできず、取り組みが続きません。プルリクエストのリードタイム、レビュー時間、手戻り率など、導入前後で比べられる指標を先に決めておきます。

筆者も前職のSaaS事業で生成AIのワークフローを整備した際、削減効果を経営層へ説明できたのは、対象業務の作業時間を導入前から計測していたからでした。

逆に、導入してから「効果を測ろう」と思っても、比較する導入前の数字が残っていなければ証明のしようがありません。だからこそ計測は最初に仕込みます。まずはプルリクエストのリードタイムなど、既存ツールから自動で取れる1〜2指標に絞って始めるのが現実的です。効果を語れるかどうかは、ツールの性能ではなく計測の設計で決まります。

Claude Codeを活用した開発における注意点

最後に、筆者自身がつまずいたポイントを中心に、Claude Code開発の注意点を5つ紹介します。いずれも後から直すより、最初に知っておくほうが圧倒的に安く済みます。

Claude Codeを活用した開発における5つの注意点を示すインフォグラフィック

ディレクトリ戦略を最初に決める

筆者の1つ目の後悔は、Gitリポジトリ単位でClaude Codeを使い始めたことです。エンジニアリング用途では自然な選択でしたが、ドキュメント作成や調査など開発周辺の業務にも使えると気づいたときには、成果物とノウハウが複数の場所に散らばっていました。

Claude Codeをどの範囲の作業に使うのかを先に決め、それに合わせてディレクトリ構成を設計しておくことをおすすめします。例えば「開発リポジトリ」「調査・ドキュメント」「定型業務」で親フォルダを分け、それぞれにCLAUDE.mdを置くだけでも、用途ごとの前提が混ざらず見通しがよくなります。

最初にこの器を用意しておけば、使う範囲が広がっても成果物が散らばりません。後からの整理は、想像以上に骨が折れます。

学習の仕組みを最初から入れる

2つ目の後悔は、導入から1ヶ月ほど、気づきをCLAUDE.mdへ書き戻す運用をしていなかったことです。その結果、同じ指摘を何度も繰り返す羽目になりました。AIの出力精度は、教えた量に比例して上がります。

「同じ指摘を2回したら必ず記録する」というルールを最初の1日から動かすだけで、1ヶ月後の使い勝手はまったく変わります。記録先はCLAUDE.mdが基本ですが、手順としてまとまった作業ならスキルに、毎回強制したいルールならHooksに、と蓄積先を使い分けると効きます。

大切なのは書く場所そのものより、「気づきをその場で残す」を習慣として仕組み化しておくことです。ツールの学習ではなく、環境への蓄積が精度を作るという感覚は、使い込むほど強くなりました。

他人の公開スキルをそのままコピーしない

インターネット上には有用なスキルやCLAUDE.mdの実例が多数公開されていますが、中身を理解せずコピーして使うのは危険です。スキルはClaude Codeへの指示そのものなので、悪意ある記述が紛れていれば、意図しない動作やプロンプトインジェクション(外部から仕込まれた指示でAIを操る攻撃)の入口になり得ます。

例えば一見便利なスキルの中に「特定のファイルを外部へ送信する」といった一文が隠れていても、丸ごとコピーして使えば気づかないまま実行してしまいます。

安全なやり方は、構造だけを参考にして中身は自分の業務に合わせて書き直すことです。チームで使う場合は、社内のガイドラインとして「外部スキルはレビューを通してから導入する」と決めておくと事故を防げます。

機密情報の扱いと学習データの範囲を最初に確認する

企業でClaude Codeを導入するとき、最初に整理しておきたいのが「何を読ませ、そのデータがどこまで使われるか」です。Claude Codeはコードベースを自律的に読み進めるため、.envやAPIキーを含む設定ファイルをうっかり参照範囲に入れると、認証情報までAIに渡ってしまいます。読ませたくないファイルは、権限設定や対象ディレクトリの指定であらかじめ除外しておきましょう。

学習利用の範囲も押さえておく必要があります。公式のデータ使用ポリシーでは、Team・Enterprise・APIといった商用利用の場合、送信したコードやプロンプトがモデルの学習に使われることはありません(開発パートナープログラム等に明示的にオプトインした場合を除く)。

一方、個人向けのFree・Pro・Maxプランはモデル改善への利用を許可するかを自分で選ぶ形で、オンにするとClaude Code経由のデータも対象になります。会社のコードを扱うなら、自社の契約区分とこの設定を導入前に確認しておくのが安全です。

丸投げせず、検証の責任は人間が持つ

Claude Codeは強力ですが、生成されたコードの正しさを保証するものではありません。もっともらしく見えて要件とずれた実装、既存機能を壊す変更は起こり得ます。

実際、テストが通っていても「テスト自体がAIの誤った理解のまま書かれていた」ということも起こります。だからこそ、テストという検証の仕組みを与えること、そして認証・決済・データ削除のように失敗が取り返しのつかない箇所はテストの緑ランプだけを信じず人間が差分を読むこと——この2つは、どれだけ自動化が進んでも省略しないでください。

作業はAIに任せ、判断と責任は人間が持つ。この線引きさえ守れば、Claude Codeは開発の進め方を根本から変える武器になります。

Claude Code開発をチームに定着させるならOpsfieldにご相談ください

本記事では、Claude Codeでの開発の進め方を、環境構築、実践5ステップ、開発を加速する4つの機能、チームへの組み込み、注意点の順に解説しました。個人で速くなるだけなら、今日から始められます。一方で、組織の開発プロセスとして定着させるには、CLAUDE.mdやスキルの共有設計、レビュー・CIの再設計、効果計測の仕組みづくりが欠かせません。

Opsfieldでは、今もClaude Codeで実プロダクトを開発・出荷し続ける現役エンジニアが、開発組織向けのAI駆動開発研修を提供しています。教材ベースではなく、実際の開発ログとライブデモをもとに、ツールの使い方からチームの開発プロセスへの組み込みまでを伴走します。自社の開発組織でどこから手を付けるべきか迷っている方は、まずは30分の無料相談で現在地を一緒に整理しましょう。

無料お役立ち資料

生成AI社内ガイドラインのつくり方。

生成AI社内ガイドラインのつくり方。 資料の表紙イメージ

情報漏えいを防ぎながら生成AIを安全に活用するための社内ルール策定の実務資料です。

フォームに入力いただくと、ご記入のメールアドレス宛に資料をお送りします。

← ブログ一覧に戻る