検索
連載

「Claude Code」は開発の司令塔に　常識を一変させた5つの進化：「AIはただのコード補完」はもう古い　速習・実践「Claude Code」（1）

コード補完を超え、自律的に調査・実行・検証を回せるようになった「Claude Code」。本連載の初回は、この1年でソフトウェア開発の「常識」が一変したClaude Codeの5つの進化を解説。AIを「開発の司令塔」として生かすために押さえておくべきポイントを紹介します。

Share
Tweet
LINE
Hatena

はじめに

　2026年はサッカーのワールドカップ（W杯）イヤー。「サッカーとシステム開発は似ている」と言う人もいます。どちらも、役割を担ったプレイヤーが連携してゴールを目指すからだと。いまやその連携に、大抵はAIが加わっています。AIが参戦しても、当初はそのままの布陣でした。それがこの1年で、AIと私たちのポジションは、がらりと変わった。そう実感しています。

　これまでAIは、コードの断片を教えてくれる、ベンチのコーチ役でした。ピッチに立っていたのは人間です。私たちが選手としてコードを書き、AIは直接ボールを蹴らなかった。ところがいま、AIもピッチに立つ。ファイルを自分で読み書きし、コマンドを走らせ、テストの結果を判定し、次の一手まで実行する。試合を組み立てる司令塔はいまやAI。人間は戦略と最終判断を担う指揮官に変わったのです。

本連載について

　2026年現在、その司令塔として開発者から最も注目を集めているのが、Anthropicの「Claude Code」です。本連載はそのClaude Codeが開発現場をどう変えたか、どう変えつつあるのかを解説します。本連載は「Claude Codeならもう触ったことがあるよ」という読者にも収穫があるはずです。

　なぜならアップデートの速さがすさまじく、2025年末に覚えた使い方では、現在の実力の半分も引き出せていないかもしれないためです。本稿から始めて、第2回はチーム・組織での使いこなし、第3回以降は小さなWebアプリ作りを題材に、手を動かしながら最新のClaude Codeを体験していきます。

　なお、Claude Codeの利用には有料プラン（またはAPIの従量課金）が必要です。第1回で取り上げた仕組みには、リサーチプレビューや実験段階のものも含まれます。対応プランや有効化の要否は機能ごとに異なり、デフォルト（既定）で無効のものもあります。

　状況は頻繁に変わるので、本連載の内容は執筆時点（2026年6月初旬）を基準とし、最新の機能仕様や、ご自身の環境で使えるかどうかは、Anthropicの公式ドキュメントや料金プランのページで確認してください。

AIコーディングで「常識」はどう変わったか

　第1回は、個人の開発体験で起きた5つの変化を共有します。第2回で扱うチーム編の5つと合わせて10個。そのうち幾つかは、この半年内に加わったばかりのものです。「AIコーディング？　まだまだでしょう」と思っているなら、もう危ういかもしれません。

　とりわけWindowsで開発しているなら、「Claude CodeはWSL（Windows Subsystem for Linux）頼み」という印象を持っていないでしょうか。それも、すでに古い認識です。現在はWindowsにネイティブ対応し、WSLもNode.jsも別途用意せず、そのまま動きます。本連載第3回のハンズオンも、全てWindowsだけで進めます。

　まずはその前に、Claude CodeによるAIコーディングで常識はどう変わったのか整理します。

ChatGPT超え？　Claude Codeとは何者か

　一般的なチャット型AIやコード補完ツールは、答えることはできても、実行することはできませんでした。

　Claude Codeは違います。一言でいえば、調査・計画・実行・修正のループを自律的に回す開発環境です。「この機能を追加して」と頼めば、関連ファイルの調査から実装、テスト通過までをひとつながりの作業として最後まで進める。空のフォルダに「こういうアプリを作って」と頼んでも同じで、必要なファイル一式を生成し、途中の作業をあれこれ指示しなくても、対話で方向を調整しながら仕上げていきます。

　この、調査して計画を立て、実行し、結果を見て修正するという一つのつながりの動きを、エージェンティックループ（agentic loop）と呼びます。人間が一つ一つ指示を出すのではなく、AIがこのループを自分で回し続ける。それが「コード補完」と「エージェント」の決定的な違いです。

調査・計画・実行・修正をひとつながりで回すエージェンティックループ
調査・計画・実行・修正をひとつながりで回すエージェンティックループ

　こうした振る舞いを支えているのが、Claudeモデル自体の強み。つまり、大きなコンテキストウィンドウと、高い推論能力です。コンテキストウィンドウとは、一度に読み込んで考慮できる情報の量のこと。大きなコードベースでも関連範囲を読み込み、全体を見渡して段取りできる。断片的なやりとりを重ねる従来のAIとは、動き方そのものが違います。

　モデル自体の進化も続いており、執筆時点では、最上位モデルの「Claude Fable 5」が登場しています。これは「Mythos」モデルの一般向けで、Claude Codeでも利用できます。

Claude Codeをどこで動かすか？　4つの利用形態

　Claude Codeは、一つの製品に固定されたものではありません。利用形態は大きく分けて4つあります。いずれも基盤は同じClaudeモデルですが、得意な場面や設定の共有のされ方は同じではありません。まずは次の表で全体像をつかんでください。

利用形態 動く場所 向いている用途
CLI（コマンドラインインタフェース）版 ターミナル あらゆる操作の基本。スクリプトやCI（継続的インテグレーション）にも組み込める
VS Code（「Visual Studio Code」）拡張機能版 エディタ内 編集中のコードを見ながら対話。差分を確認しやすい
Desktopアプリ 専用アプリ Code／Coworkタブ。Auto VerifyやComputer Useなど新機能の入り口
Web版 ブラウザ（クラウド） 端末を選ばずクラウドで計画・実行。ultraplanなどの土台
Claude Codeの4つの利用形態

　手元で動く3つ（CLI版・VS Code拡張機能版・Desktopアプリ）は、CLAUDE.mdやルールファイルといった設定をそのまま共有できます。一方、クラウドで動くWeb版は別系統です。

　第3回以降のハンズオンは、CLI版とVS Code拡張機能版を中心に進めます。環境を選ばず再現しやすく、本記事で紹介する設定ファイルの効き目を確かめながら手を動かせるからです。Desktopアプリ固有の仕組み（Auto VerifyやComputer Useなど）は、本記事の中で紹介します。

Claude Codeが注目を集める理由

　コードを自分で読んで直すAIは、もちろんClaude Codeだけではありません。ここ1年で、「Cursor」や「GitHub Copilot」のエージェントモード、OpenAIの「Codex」、Googleの「Antigravity」と、ターミナルやエディタで自律的に動くツールが続々と登場しています。ファイルを読み、コマンドを走らせ、テストの失敗を見て直す。このエージェンティックループ自体は、いまや前提条件になりつつあります。

　さらに、先行ユーザーはどれか1つに絞り込んでいるとは限りません。タスクの性質に応じて複数のエージェントを使い分け、ときには同じ作業を別々のツールに投げて、出てきた結果を突き合わせる。そんな運用も珍しくないでしょう。

　では、Claude Codeが選ばれる理由はどこにあるのか。決め手は、一つの突出した機能ではありません。委譲のたびに安全装置を選べる細かな権限設計と、計画から実行・検証、チームへの共有までを同じ環境で進められること。この2つがそろっている点にあります。その中身は、この後の本論で見ていきます。

ソフトウェア開発の「常識」が一変　5つの変化

　ここからは、開発現場での使いこなしを5つの切り口で紹介します。前半は基本機能。後半は、リサーチプレビュー段階のものも含みます。

1．1．「毎回前提を説明するのは面倒」――CLAUDE.md・ルールファイル・Auto Memoryで暗黙知を共有

　「フレームワークはNext.js、命名はキャメルケース、テストはVitest、削除前にチームに確認……」――AIに作業を頼むたび、こうした同じ前提を入力していないでしょうか。会話が変わるたびに、また一から説明し直すことになります。

　そこで役立つのがCLAUDE.mdです。CLAUDE.mdは、プロジェクトの前提や取り決めを書いておくと、Claudeが作業のたびに自動で読み込んでくれるファイルです。これで、毎回の説明の手間を大きく省けます。「CLAUDE.mdならとっくに書いているけど」という読者もいるでしょう。それなら重点は、CLAUDE.mdと同格になったトピック別のルールファイルと、Claude自身が学びを記録するAuto Memoryに移ります。

　この3つは、いずれも「AIに暗黙知を渡す」ための仕組みですが、書く主体も効く範囲も違います。まずは次の図で関係を一望しておきましょう。

CLAUDE.md・ルールファイル・Auto Memoryの関係
CLAUDE.md・ルールファイル・Auto Memoryの関係
  • CLAUDE.md

　プロジェクトの暗黙知を書いたCLAUDE.mdというファイルをリポジトリ直下に置いておけば、Claudeが毎回それを読んでから動きます。CLAUDE.mdに限らず、Claudeに渡すルールや手順は、普通のMarkdown記法のプレーンテキストで書けます。

　しかも、一から手書きする手間もいりません。すでにコードのあるリポジトリなら、初期化コマンドの/initが既存のコードを読み取り、たたき台を作ってくれます。フレームワークやテストコマンドといった、コードから読み取れる事実はこれで拾えます。

　ただし、/initが読み取れるのはあくまで既存のコードです。まだ何もない新規プロジェクトなら自分で書く必要がありますが、これも対話で作成できます。作成後は「削除前にチームへ確認」のような、コードで示されていない取り決めを対話で足していくと、次のような体裁に落ち着きます。

# プロジェクトの決まりごと
- フレームワークはNext.js（App Router）。命名はキャメルケース
- テストはVitest。npm test が緑になるまで完了としない
- APIを変更するときは CHANGELOG.md も必ず更新する
- ファイルを削除する前に、必ずチームへ確認する
〜中略〜
［リスト1］Claudeに生成させ、対話で整えたCLAUDE.mdの例（抜粋）

　箇条書きにある「APIを変更するときはCHANGELOG.mdも必ず更新する」の一行。これを書いておけば、新しいエンドポイントを足すたび、ClaudeはCHANGELOGの更新までケアしてくれます。

　ただし、CLAUDE.mdは強制設定ではなく、毎回読まれる参考情報です。対話が積み重なると、書いてあるのに従われない場面も現実にはあります。絶対に守らせたいルールには、第2回で取り上げる「Hooks」のような強制力のある仕組みが向きます。普段の取り決めなら、CLAUDE.mdに一文書いておけば機能します。

  • トピック別に分けるルールファイル

　取り決めを書く先は、CLAUDE.mdの1ファイルとは限りません。テスト方針、APIの命名規約、フロントエンドのスタイルガイドといったトピック別のルールファイルを、.claude/rules/というフォルダにまとめられます。CLAUDE.mdのつけ足しではなく、同列の置き場です。普通に置けば毎回同じように読み込まれます。CLAUDE.mdにないメリットは2つあります。

　一つは、指示が効く場面を絞れること。ファイル冒頭のフロントマター（メタデータ欄）に対象パスを書けば、Claudeがそのパスのファイルを扱うときだけ、該当ルールが読み込まれます。API実装のルールなら、次のように書きます。

---
description: APIエンドポイント実装のルール
paths: ["src/api/**/*.ts"]
---
# API実装の決まりごと
- 入力は必ずスキーマで検証する
- エラー応答は ProblemDetails 形式に統一する
- 公開APIを変更したら CHANGELOG.md を更新する
〜中略〜
［リスト2］対象パスを絞ったルールファイルの例（.claude/rules/api.md）

　全てをCLAUDE.mdに詰め込むと、毎回読み込まれるコンテキストが増え、肝心の指示が効きにくくなります。常時読ませる必要のないものをルールファイルへ移していけば、肥大化を避けながら取り決めの粒度を保てます。

　もう一つは、使い回せること。1トピック1ファイルなので、よくできたルールを別のプロジェクトにコピーするだけで再利用できます。

　しかも使い回せるのは、コピーするときだけではありません。置き場所そのものでも、効く範囲を変えられます。リポジトリ直下に置けばチームで共有でき、ユーザーフォルダの~/.claude/に置けば自身の全てのプロジェクトで有効になります。これはルールファイルに限らず、CLAUDE.mdでも同じです。プロジェクト固有の取り決めはリポジトリへ、どのプロジェクトにも当てはまる自分用の取り決めはユーザーフォルダへ配置すればよいのです。

  • Claude自身が学ぶAuto Memory

　ここまでは、人間が用意して教える側の話でした。これに加えて、Claude自身が学んだことを記録するAuto Memoryという仕組みがあります。このプロジェクトではどのコマンドでテストを走らせるのか、過去にどんなデバッグでハマったのか。そうした細かな事情を、人間が教えなくてもClaudeが記憶してくれます。CLAUDE.mdやルールファイルに書いた数行と、Auto Memoryがあれば、会話のたびに前提の説明を繰り返す必要がありません。

2．「結局、手戻りが起きる」――Plan Modeで実装前に合意、ムダな時間を低減

　AIに頼んだら見当違いのコードを書かれ、結局全てやり直し。指示が曖昧だったのか、AIの早とちりか。原因はともかく、この手戻りは精神的にもコスト的にも重いものです。

　この典型的なつまずきを、Plan Modeがなくします。Plan Modeを毎日使っている人は、この節の終わりに注目してください。計画はローカルで立てるものという前提が変わり始めています。

　Plan Modeに切り替えると、Claudeはソースコードを書き換えず、調査と計画だけに集中します。出てくるのはコードではなく、これから何をどうするかという段取りです。「どのファイルをどう変えるか」「どんな順で進めるか」が箇条書きで返ってきます。実際の出力は、例として次のようになります。

## 実装計画：ダークモード切り替えの追加
1. theme.ts に表示モードの状態を追加（既存の ThemeProvider を再利用）
2. Header.tsx にトグルボタンを設置（既存の Icon を流用）
3. 選択を localStorage に保存し、初回ロード時に復元
4. 既存のスナップショットテストを更新
変更ファイル：theme.ts / Header.tsx / __tests__/Header.test.tsx
触らない：API層・ビルド設定
［リスト3］Plan Modeが実装前に返す計画の例

　この計画は、こんなやりとりの末に出てきます。

  • 「ダークモードを追加して」とだけ伝えてPlan Modeに入る
  • Claudeが、theme.tsやHeader.tsxを開いて読み、このような段取りを返す
  • その計画を見て「API層は触らないで」「localStorageへの保存より先にトグルを作って」と日本語で注文をつける
  • Claudeが計画を直し、こちらが「これで進めて」と承認するまで、コードには一行も手をつけない
  • 承認した瞬間に、合意した順でようやく実装が始まる

　設計の意図がずれていれば、コードが書かれる前に直せます。手戻りのつらさを、実装前の対話で解消できる。大きな機能追加ほど、この差は大きいでしょう。

  • 計画づくりをクラウドへ預ける「ultraplan」

　計画づくりそのものをWeb版のClaudeに預ける発展形も出てきています。リサーチプレビュー段階の「ultraplan」と呼ばれる仕組みです。ローカルのPlan Modeで作った計画をAnthropic管理のクラウドへ送ってもいいし、最初からクラウド側に立てさせてもいい。あとは気になる箇所にコメントをつけてレビューし、仕上がったらそのまま実行させるか、手元のターミナルに戻して動かすかを選びます。

　ローカルとクラウド、それぞれの位置付けを次の表にまとめます。

観点 ローカル（Plan Mode） クラウド（ultraplan）
動く場所 手元のターミナル Anthropic管理のクラウド（Web版）
計画の起点 その場で対話して立てる クラウドで立てる、またはローカルの計画を送る
レビュー ターミナル上で確認 気になる箇所にコメントをつけてレビュー
実行 そのまま手元で実行 クラウドで実行、または手元に戻して実行
向く場面 すぐ着手したい小〜中の変更 時間のかかる計画、外出先や非同期での検討
ローカルのPlan Modeとクラウドのultraplan　使い分けのポイント

3．「エラーログのコピペばかりで不便」――AI自身が調査・修正・検証まで自動完結

　エラーログをコピーして貼り付け、原因を尋ね、返ってきた修正案を貼り戻してまた実行する。その作業の往復は、ぐっと減りました。「テストの自走はもう見慣れた」という人もいるはずです。それなら本題は後半のAuto Verify。検証の対象が、テストの成否から画面の見た目に広がっています。

  • テストの実行・修正ループはClaudeが回す

　自走の土台になるのはテストそのものです。仕様のたたき台はClaudeに生成させ、境界条件や例外ケースを対話で詰めてからコミットする。そこまでが人間の仕事です。テストの仕様さえ決まっていれば、その後のループはClaudeに任せられます。Claudeが回すのは、次の4ステップです。

  1. テストを実行する
  2. 失敗ログを自分で読み、原因を切り分ける
  3. 原因のファイルを開いて直す
  4. もう一度テストを走らせる（緑になるまで1に戻る）

　実際の動きは、次のようなイメージです。

> npm test … payment.test.ts で3件失敗
失敗を確認します。テストは四捨五入を期待していますが、実装が切り上げになっていました。
→ src/payment/convert.ts の roundUp を roundHalfUp に修正
> npm test を再実行 … 全14件パス
修正点：convert.ts の端数処理を1か所。テストコードには触れていません。
［リスト4］テストの失敗をClaude自身が直していくようす（説明用に簡略化した進行イメージ）

　ポイントは、人間がログを読んでいないことです。「テストが落ちたら直しておいて」と一言だけ伝えて別の作業に移り、戻ってきたら、何を直し、何に触れなかったかを確認すればいいのです。

  • コードの内側から、見た目・操作の外側へ――「Auto Verify」

　検証はコードの内側だけにとどまりません。その一例が、Claude DesktopアプリのCodeタブに加わった自動検証（Auto Verify）です。変更のたびに埋め込みブラウザでアプリを開き、自分の変更を点検します。

Auto Verifyで点検している様子
Auto Verifyで点検している様子

　スクリーンショットを撮るだけでなく、DOM（Document Object Model）を調べ、ボタンをクリックし、フォームに入力し、見つけた不具合はその場で直します。確認の対象も、テストの成否から、レイアウトが崩れていないか、操作は問題なく通るか、といった見た目と操作の面へと広がります。人間は最後に、挙動が本当によいかを確認すれば済みます。

　従来のテスト自動化との違いを整理すると、次の表のようになります。

観点 従来のテスト自動化 Auto Verify
検証の対象 コードの入出力（関数やAPIの結果） 画面の見た目と操作（レイアウト・クリック・入力）
確認の方法 テストコードの成否 埋め込みブラウザでDOM調査・操作・スクリーンショット
事前準備 テストを書いておく必要がある テストがなくても動く
得意なこと 回帰を機械的に防ぐ 見た目崩れや操作不能など、テストで拾いにくい不具合の発見
人間の役割 テスト仕様を決める 最終的に「本当によいか」を判断する
従来のテスト自動化と、Auto Verifyによる見た目・操作の自動検証

4．「コード以外は手作業」――Computer UseでGUI操作まで任せられるように

　Auto Verifyが見ていたのは、ブラウザで動くシステムの画面まででした。一方、「Computer Use」は、デバイス画面そのものへと範囲を広げる仕組みです。まだリサーチプレビュー段階ながら、Claude CodeのDesktopアプリに統合され、ネイティブアプリやGUI（グラフィカルユーザインタフェース）専用ツールの操作までAIに任せられます。

  • 導入時に外せない3つの安全対策

　ただし画面ごと触らせる以上、事前の備えが要ります。次の3つの安全対策は、運用の安全を左右するので外せません。

  • 許可するアプリと操作を絞る
  • 検証環境や、読み取り中心の手順から試す
  • 本番データに触れる手前で、人間のチェックを挟む

　速さへの期待も調整しておく必要があります。公式ドキュメントでは、Computer Useを、適用範囲はいちばん広いが速度はいちばん遅い手段と位置付けています。MCP（Model Context Protocol）やシェルコマンドで済む作業なら、Claudeはそちらを先に選ぶ設計です。

  • 速度と使い分けの現実

　そこまで整えたら、昼休みのあいだに、次の一文をClaudeに渡しておく。「社内の旧資産管理ツールを開き、先月分の貸し出し記録をCSVへエクスポートして、抜けがないかどうか確かめて」　席に戻るころには、APIのない業務ツールの確認が一通り進んでいる、というわけです。

　コードは任せられても周辺は手作業。そう諦めていたレガシーな社内ツールの操作まで、自動化を検討できるようになってきました。もっとも、何をどの順で操作させるかは、まだ人が設計する部分です。

5．「AIに勝手に壊されるのが怖い」――権限モードによる安全制御が可能に

　自律的に動いてほしい。でも、勝手に壊されるのは怖い。この相反する要求に、複数の権限モードが応えます。自律度の低いものから高いものまで、用途に応じて使い分けられます。

  • Plan Mode（計画のみ）：書き換えず、調査と計画だけを立てる
  • 通常モード（要承認）：編集やコマンド実行のたびに確認しながら進める。慎重に進めたいとき向き
  • 編集許可モード：ファイル編集は任せ、コマンド実行などは確認する
  • 「Auto mode」（準自律）：各操作を実行前に安全性チェッカーが審査した上で任せる
  • CI／隔離環境モード（自律）：あらかじめ許可した操作だけを通す、または隔離環境を前提に確認を一切省く

　慎重に確認しながら進めたいときと、思い切って任せたいときを、同じツールの中で行き来できる。最初は手動承認を多めにし、慣れてきた作業から、任せる範囲を少しずつ広げることもできます。

  • 新顔の「Auto mode」　仕組みと運用の原則

　モードの使い分け自体は、経験者には目新しくないかもしれません。新顔は、2026年3月に登場したAuto modeです。といっても、人手を完全に離れて動くわけではありません。バックグラウンドの安全性チェッカーが各操作を実行前に審査し、依頼から逸脱する操作や、想定外の環境へのアクセスなどをブロックします。

　とはいえ、この審査は安全を保証する仕組みにはなっていません。本番データや機密情報に触れる作業では、人間のレビューを前提にして使うのが原則です。その上で、Plan Modeで計画を固めてからAuto modeへ渡し、時間のかかるタスクを任せて、後で結果を確認する。そのような使い方もできるでしょう。

おわりに

　ここまで、AIの進化によるソフトウェア開発で起きた5つの変化を見てきました。「暗黙知の共有」「実装前の合意」「テストとAuto Verifyの自走」「Computer Useによる画面操作」「権限モードによる安全制御」と、どれも人間の仕事を、コーディング作業から、依頼と結果のレビューに移しています。ピッチに立つ司令塔はClaude Codeであり、あなた（人間）はその起用と最終判断を下す“監督”になったのです。

　この1年でClaude Codeには本稿で紹介した以外にもさまざまな新機能が次々と追加されています。まずは手元のプロジェクトで動かして、この進化を自分の手で確かめてみてください。Windows環境だから難しいのではと、身構える必要はもうありません。

　次回は、Claude Codeを利用したチーム開発に焦点を当てます。どの機能を今すぐ使い倒し、どれを試しておくべきなのか、“采配の指針”として示していきます。

筆者紹介

WINGSプロジェクト 高江賢

多様な開発分野の「何でも屋（フルスタックエンジニア）」として働きつつ、WINGSプロジェクトにて、Web記事、書籍の執筆活動をこなしてきたが、2026年夏、勤め人を卒業。フリーランスの技術者兼著述家としてリブート。

WINGSプロジェクト

有限会社WINGSプロジェクトが運営する、テクニカル執筆コミュニティ（代表：山田祥寛）。主にWeb開発分野の書籍／記事執筆、翻訳、講演等を幅広く手掛ける。2026年7月時点での登録メンバーは約50名で、現在も執筆メンバーを募集中。興味のある方は、どしどし応募頂きたい。著書、記事多数。

・サーバーサイド技術の学び舎 - WINGS（https://wings.web-deli.com/）

・RSS（https://wings.web-deli.com/rss）

・X: @WingsPro_info（https://x.com/WingsPro_info）

・Facebook（https://www.facebook.com/WINGSProject）


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る