Claude Code で、
開発効率を仕組みにする。

「2週間で MVP」と聞いて、安かろう悪かろうの突貫工事を想像する経営者は少なくありません。Kmetric でも、Claude Code を本格運用する前は、MVP に8〜12週間かかるのが標準でした。それが2025年から、2週間で安定して届くようになっています。本稿では、この短縮を支えている運用の中身を順に説明します。この速度を生んでいるのは、多くのツールを使い分けることよりも、むしろツールを1つに絞り込んだことです。

1. 数字で見る、開発効率の変化

抽象論より先に、Kmetric の開発組織の実績を Before と After で並べます。どの指標も、個別のツールを足し合わせただけでは出ない差です。

上記の数値は、Kmetric の直近24ヶ月の自社実績です。Before は Claude Code を本格運用する前、After は本格運用を始めた2025年以降のプロジェクトの値です。プロジェクトの性質によって幅があるため、最良条件の値は使わず、平均値を載せています。

2. 効率化を生む7つの用途

Claude Code は「コードを書くツール」と思われがちですが、Kmetric では要件ヒアリング直後の資料作成から保守運用まで、一貫して使っています。各用途で具体的に何をしているかを、順に紹介します。

2.1 資料作成 — 提案書・技術ドキュメント・議事録

顧客提案書は、ヒアリングメモを Claude Code に渡せば30分でたたき台ができます。技術設計書は、アーキテクチャ図も含めて生成しています。議事録は、録音の書き起こしから、やるべきことの抽出、担当者の割り当てまでを一連の流れで処理します。できあがった資料は、Notion・Google Docs・タスク管理ツールの Linear に自動で取り込まれます。

Kmetric では、「人間がゼロから書く」前提をやめ、「人間が編集する」前提に切り替えています。完成度70%のたたき台を1時間で95%に引き上げるほうが、白紙から書き始めるより数段速く仕上がります。

2.2 設計補助 — アーキテクチャ・データ構造・API 設計

1つの要件文書から、データ構造の設計と API 仕様を同時に作ります。同じ文書から作るので、両者に食い違いがないかの確認もその場でできます。

設計判断の記録（ADR）の作成も Claude Code に任せます。「なぜこの技術を選んだか」「ほかにどのような選択肢があったか」「却下した理由は何か」を項目ごとに整理した文書が、設計の議論と並行して自動で作られます。設計レビューでは、Claude Code が「ほかの選択肢」をすぐに挙げるため、実装前の議論が一気に進みます。

2.3 デザイン提案 — 画面ラフ・UI 部品の設計

UI 設計のフェーズでは、デザインツール（Figma）を使わないプロジェクトも増えました。Claude Code に「ホーム画面のラフを作って」と依頼すると、実際に操作できるプロトタイプが返ってきます。デザイナーがいないスタートアップでも、初日から動くプロトタイプを確認できます。

「動くプロトタイプを2時間で」が標準です。デザインレビューは、そのプロトタイプを触りながら進めます。AI 機能を組み込むときの判断基準については、コラム「既存プロダクトに AI 機能を載せる前に決めるべき5つのこと — データ・コスト・UX・セキュリティ・運用」で整理しています。

2.4 コーディング — 機能実装とタスクの切り分け

Kmetric の標準は、1つの機能を1つの PR にまとめ、PR 1つを Claude Code との1回の作業で仕上げることです。タスクは、30〜60分で終わる単位に切り分けてから Claude Code に渡します。「EC サイトを作って」のような大きすぎる依頼は、典型的な失敗パターンです。「ユーザー登録 API を実装、パスワードは暗号化して保存、テスト込み」のように具体的に頼めば、生成されるコードの精度は大きく上がります。

PR の説明文は、Claude Code 自身が書きます。変更履歴（コミットログ）とコード差分を読み、「変更の意図」「テスト方法」「想定リスク」を、レビュアーが理解しやすいかたちに整理して並べます。認証・課金・権限管理のように失敗が許されない部分は、エンジニア2名と Claude Code の3者体制で進めます。設計判断は人間が、コードの生成は AI が担います。

2.5 コードレビュー — AI による一次レビュー

PR が作成されると、開発の自動化基盤に組み込んだ Claude Code が、自動で一次レビューを実施します。検出対象は、バグ・セキュリティ上の弱点・処理速度の低下・コーディング規約違反・データの型の食い違い・テストの不足などです。CLAUDE.md（Claude Code が作業のたびに最初に読む、プロジェクトの前提をまとめたファイル）に書いた「避けるべき書き方」も検出します。

人間のレビュアーは、AI が拾えない領域に集中できるようになります。設計判断と、誤りの影響が大きい領域（権限管理・課金・個人情報の扱い）⁠がその中心です。AI と人間の二段階で確認する体制にすることで、見落としのリスクが大きく下がります。

2.6 開発工程の自動化と連動 — システムが Claude Code を呼ぶ

Claude Code を「人間が呼ぶツール」からシステムが呼ぶツールに切り替えると、開発が24時間365日回り続けます。開発の自動化基盤には、Claude Code を呼び出すきっかけを次のように組み込んでいます。

• 課題（Issue）が登録される → Claude Code が実装案を作り、PR として提出する
• 自動テストが失敗する → Claude Code が失敗の記録を読み、修正案を PR として提出する
• 利用している外部ライブラリ（外部の開発者が公開しているプログラム部品）に脆弱性が見つかる → Claude Code が修正の適用、動作確認のテスト、PR の作成までをまとめて行う
• 毎週末 → CLAUDE.md と設計判断の記録（ADR）の更新案を PR として提出する
• リリース時 → 変更履歴からリリースノートを作って公開する

これらは、自動テストや、AI の出力の品質を採点する仕組み（Eval）と組み合わせて動かしています。基準を満たさない変更は、本番に出しません。本番運用に耐える品質を保つための設計原則は、コラム「PoC で終わらせない — 本番運用に届ける7つの設計原則」でまとめています。

2.7 保守運用 — 障害対応・脆弱性対応・既存コードの改修

リリース後の本番運用は、AI の効果がとくに大きい領域です。Kmetric では、Claude Code が障害対応の当番（オンコール）の一次対応を担っています。

障害が起きたときに監視ツールのエラーログを Claude Code に渡すと、原因の見立てがすぐに返ってきます。データの不整合か、外部サービスの応答の変化か、特定のエラーパターンか。見立てによっては、修正案を PR として自動で作るところまで進みます。外部ライブラリの脆弱性対応は2.6節で挙げた仕組みで自動化しており、人間のレビューを経てから本番に反映します。

古くなった既存コードの段階的な改修や、データ移行用のプログラムの作成も、Claude Code が安定して担える領域です。人間の緊急対応担当の役割は、修正を本番に反映するかどうかの最終判断と、重大な障害を上位者に引き上げる判断（エスカレーション）に絞られつつあります。

3. 「Claude Code 1つ」が効率を生むメカニズム

3.1 複数のツールを使い分ける隠れたコスト

複数の AI コーディングツールを使い分けるやり方は、一見「各ツールのいいとこ取り」に見えます。ただ、商用の受託開発の現場では、3つの問題を生みます。

第一に、ツールを切り替えるコストは見えにくい支出です。30秒の切り替えが1日50回あれば、それだけで25分のロスになります。第二に、CLAUDE.md のほかにツールごとの設定ファイルが並ぶと、内容の重複や食い違いが起きやすくなります。第三に、ツールごとのクセ・ショートカット・設定を覚える学習コストが、新メンバーが入るたびにかかります。

3.2 Claude Code を選んだ3つの理由

Kmetric が Claude Code を選んだ理由は、3つあります。

• コマンドで動かせる — ビルド・テスト・リリースといった開発工程の自動化に、そのまま組み込める
• 長時間の作業を任せられる — 複数の手順・複数のファイルにまたがる作業を、途中で止まらずにやり遂げられる
• 人間と同じファイル単位で作業する — 作業の途中で人と AI が交代しても、続きが自然につながる

その代わり、コードを書く画面（IDE）の中で AI と対話しながら進める手軽さは犠牲になります。それでも、組織として1つのツールに統一して運用するなら、この代償は引き受けられます。1つを深く使い込むほうが、複数を浅く使い分けるよりも、運用の知見がたまりやすいからです。

3.3 前提知識を CLAUDE.md に集約する

Claude Code の効果を最も左右するのは、CLAUDE.md の設計です。これがあるかないかで、出力の品質はまったく別物になります。言い換えると、Claude Code 導入の本当の作業は「Claude Code を入れる」ことではなく、CLAUDE.md を整備することです。CLAUDE.md は、プロジェクト全体の前提、機能のまとまりごとの前提、開発者個人の書き方の好みという3層に分けて置くのが標準です。

書く内容の考え方はシンプルで、「人間の新人が知るべきことは、AI も知るべきこと」⁠です。具体的には、コーディング規約、ライブラリの選定理由、テスト方針、本番反映の手順、業務用語の一覧、避けるべき書き方の例などを書きます。Kmetric では、毎週末に Claude Code 自身に更新案を出させる運用を組み込み、内容が古くならないようにしています。これが、7つの用途すべての精度を支える土台です。

4. AI 駆動開発で陥りやすい5つの落とし穴

Claude Code の運用で繰り返し出会う失敗パターンを、5つ挙げます。

1. 大きすぎるタスクを渡す — 「EC サイトを作って」では失敗します。30〜60分で終わる単位に切り分けてから渡します（2.4節を参照）
2. 前提情報を用意しない — CLAUDE.md がないと、AI は手探りで作業することになります。最初の1〜2週間は、CLAUDE.md の整備に集中して投資します
3. テストなしで AI に任せる — バグが量産されます。自動テストと Eval を必ず組み合わせます
4. AI を信用しすぎる — セキュリティ・課金・権限管理は、人間のレビューが欠かせません。AI はもっともらしい説明を添えて間違えるため、誤りに気付くのが遅れます
5. 量産してから設計する — 設計こそ、Claude Code と一緒に先に決めます。コードを大量に生成した後で整理するのは、きわめて困難です

落とし穴1〜3は、CLAUDE.md と運用ルールで防げます。4と5は組織文化の問題で、ツールの導入だけでは解決しません。

5. 同じ速度を出せる組織と、出せない組織の差

Claude Code は誰でも使えます。にもかかわらず、2週間で MVP に届く会社は多くありません。同じツールを使って速度に差が出るとき、その差は4つの要因に分けられます。改善は、自社がどの要因でつまずいているかを見極めるところから始まります。

• 知識 — Claude Code の使い方を知らない状態です。これは時間が解決します（3〜6ヶ月）
• 投資 — CLAUDE.md・自動化基盤・雛形の整備に、先行投資が必要です。合計1〜3ヶ月分の工数を、顧客プロジェクトの費用に含めず、自社で負担すると決められるかどうかが分かれ目です
• 組織 — 複数人で設計・実装を進める習慣やコードレビューの文化がない組織では、AI 駆動開発は機能しません。個人プレーが残ると、AI が生成したコードの品質を担保できません
• 契約形態 — 4つのうち、とくに大きな障壁です。人月単価で契約していると、速く作るほど売上が減るため、速くする動機が働きません。発注側も人月で見積もりを比べるので、ベンダーが速くなっても、その価値を価格に反映できません

Kmetric は人月ではなく、成果ベースの契約を標準にしています。AI 駆動開発で速くなった分がそのまま利益になるため、Claude Code の運用に全面的に力を注げます。詳しくは AI 開発スタジオのサービス概要をご覧ください。

6. Kmetric の標準セットアップ — 5つの仕組み

自社で取り組む際の参考として、Kmetric が標準で組み込んでいる仕組みを整理します。

1. CLAUDE.md のテンプレート — プロジェクト開始時に自動で配置します。コーディング規約、ADR の雛形、避けるべき書き方の例を含みます
2. プロジェクトの雛形 — 認証・データベース・本番反映の自動化を組み込んであり、初日から動きます
3. 自動テストの雛形 — 単体テストと画面操作テストを、開発工程の自動化に組み込んでいます
4. タスク管理ツール（Linear）と Claude Code の連携 — Linear に登録したタスクを、AI が直接受け取って作業を始めます
5. Claude Code による PR の自動レビュー — PR が作成されると、自動で一次レビューを実施します（2.5節を参照）

これら5つは、Kmetric の AI 開発スタジオの土台です。見積書に項目として並ぶものではありませんが、これがあるからこそ2週間の MVP が成り立ちます。自社で組むには1〜3ヶ月の初期投資がかかりますが、Kmetric では最初から実装済みの状態で提供しています。