「Claude Code 効果ない」は本当か ── 導入企業のリアル

「Claude Codeを入れたけれど、使っているのは一部のエンジニアだけ」「Cursorを全員に配布したのに、業務効率が体感できない」──こうした声が、AI開発ツールを先行導入した開発組織から相次いで聞こえてくる。
日経BPの2025年7月調査によると、日本企業における生成AIツールの導入率はすでに64.4%に達している。にもかかわらず、「全社的に定着している」と胸を張れる企業は少数派だ。多くの組織が「PoC止まり」や「一部担当者のみ活用」という状態に陥っている。

では、Claude Codeは本当に効果がないのか。Cursorは使いこなせないツールなのか。答えはNoだ。問題はツールの限界ではなく、ツールを導入した後に必要な「設計」が抜け落ちていることにある。その設計こそが、本記事のテーマである「ハーネス設計」だ。

AI駆動開発の定着に向けてどこから手をつければよいか体系的に学びたい方は、AI駆動開発伴走セミナーでハーネス設計を含むAI活用の実践手法を学べる機会を設けている。まずは概念から確認していこう。

成果が出ない会社に共通する「3つの設計不足」

AI駆動開発が定着しない組織には、共通する3つのパターンがある。Claude Code自社導入の失敗事例を分析した調査でも、問題の本質は「AIの性能が足りない」のではなく「組織への統合設計の不備」であることが繰り返し指摘されている。

設計不足①：セキュリティ・情報管理ポリシーの未整備

最も多いのが「社内コードを外部のAIに渡していいのか」という判断基準が曖昧なまま導入してしまうケースだ。明確なルールがないと、現場は「念のため外部情報は何も投げないでください」という自衛的なルールを作り、Claude Codeが本来持つコードベース理解の力を全く活かせない状態になる。
情報分類ポリシー（どのデータをAIに渡してよいか）とアクセス制御の設計が、AI開発ツール導入の大前提だ。

設計不足②：既存の開発フローへの未統合

「ブラウザの別タブにClaude Codeを開き、コードをコピペしている」という運用では、生産性が下がることすらある。AIツールがIDE・Git・CI/CDと連携していなければ、エンジニアの日常フローに組み込まれない。SB Creative の分析でも、AIに「アプリを作って」と曖昧に頼むだけでは整合性が崩れると指摘されている。AIが文脈を正確につかめる環境を整えることが先決だ。

設計不足③：プロンプト設計の属人化

AIに詳しい一部エンジニアだけが高い成果を出し、チーム全体には広がらない。これが「使いこなせない」状態の正体だ。再現性のある活用法が「その人の頭の中にしかない」状態では、組織としてのスケールは不可能だ。COLOPLのCursor導入事例でも「ベストプラクティスをチーム間で共有する仕組みづくりに継続して取り組んでいる」と、ナレッジ共有の難しさが正直に語られている。

ハーネス設計とは何か ── ツール導入との根本的な違い

「ハーネス」とは馬に取り付ける馬具のことだ。馬の脚力を制御・誘導し、目的に向けて最大限に引き出す仕組みを指す。AIにおけるハーネス設計も同じ発想だ。AIエージェントの能力を活かすための「周囲の仕組み全体」を意図的に設計することを指す。

ハーネスエンジニアリング入門2026によると、AIとの協働方法は3段階で進化してきた。

• 第1段階：プロンプトエンジニアリング（2022〜2024年）「どう聞くか」を工夫する。ゼロショット、フューショット、Chain-of-Thoughtなどの技法。単発の質問には有効だが、複数ステップの継続作業には力不足だった。
• 第2段階：コンテキストエンジニアリング（2025年〜）「何を見せるか」を設計する。AIのコンテキストウィンドウに最適な情報を事前に詰め込む環境設計。プロジェクト構造、コーディング規約、ドメイン知識をAIに渡す。
• 第3段階：ハーネスエンジニアリング（2026年〜）「どんな環境で働かせるか」を設計する。ルール、自動チェック、フィードバックループなど、AIエージェントが正しく動ける仕組みの全体を構築する。

この3段階で最も重要な知見は「制約を増やすほど、エージェントの生産性は向上する」という逆説だ。自由に動かせるほどAIは混乱し、品質が下がる。明確な制約とルールの中でこそ、AIは高品質な成果物を出し続ける。

AI駆動開発を組織に定着させたい場合、Captain.AIはハーネス設計の思想を土台に構築されたAIエージェント実行基盤だ。スキル定義・ルール管理・実行環境が一体化されており、チームでAIを標準化・共有化するうえで有力な選択肢となる。

成果を出す会社が実践する「3層ハーネス設計」の全貌

Qiitaのハーネスエンジニアリング入門では、実効性の高いハーネスは5つの要素（ルール・スキル・フック・メモリ・フィードバックループ）で構成されると整理されている。実際の導入では、この5要素を3つの層として段階的に構築するのが現実的だ。

Layer 1：ルール層（AIに「何をしてはいけないか」を教える）

最初に整備すべきは「CLAUDE.md」（Claude Code用）または「AGENTS.md」（汎用エージェント用）と呼ばれるプロジェクト指示ファイルだ。ここに記載するのはルール・コーディング規約・プロジェクト構造・禁止事項だ。
AIは「わからないから都度聞く」から「ルールに従って自律的に動く」存在へと変わる。例えば「ドメイン層は外部ライブラリをimportしない」「型の不明な変数を any にしてはいけない」といった宣言的な制約を書くだけで、コードの品質が劇的に安定する。

Layer 2：スキル層（繰り返し作業を「型」に変える）

同じ指示を3回以上したら、それはスキル化のサインだ。「テストを書いて」「APIエンドポイントを追加して」「コードレビューして」といった繰り返し作業を、`.claude/skills/<名前>/SKILL.md` という標準化された手順ファイルとして保存する。
スキルファイルは「チームのノウハウをAIに教えるドキュメント」だ。一度作ったスキルは全メンバーが共有できるため、「AIの使い方が上手い人」と「そうでない人」の格差が縮まる。プロンプトの属人化を解消する最も直接的な手段がこのスキル層だ。

Layer 3：フィードバック層（品質ゲートで「逸脱を自動検知」する）

最後のレイヤーが、lint・型チェック・テストの自動実行による品質ゲートだ。AIがルール層の制約を破ろうとしても、フィードバック層が即時に検知して修正を求める。「事後のコードレビュー」から「即時の自動検知」への転換だ。
この3層が機能した事例として注目されるのが、Airclosetが公開したハーネス整備の実践報告だ。月別マージPR数が23件から518件へ、約22倍に増加した。これは「書く量が増えた」のではなく「AIがルールに従って自律的に動き、人間のレビュー工数が削減された」ことの結果だ。さらに非エンジニア（事業マネージャー）も本番リポジトリに直接PRを出せるようになったという。

このような結果が生まれる背景には、「品質ゲートがあるから安心して任せられる」という信頼の構造がある。テストカバレッジ90%強制やlint禁止回避の検知など、制約が厳しいほどAIへの委任可能な範囲は広がる。

こうしたAIエージェントの実行環境を整備する基盤として、AI内製化セミナーでは、ルール・スキル・フィードバックの3層設計を事業部門のマネージャーでも実践できるレベルで習得できる内容を提供している。

今日から始めるハーネス設計の最初の一歩

ハーネス設計は特別な技術ではない。「どんな環境でAIに働いてもらうか」を言語化する習慣だ。完璧な設計を目指す必要はなく、20%の設計で80%の効果を得られるのが現実だ。以下の3ステップで段階的に始めよう。

Day 1：CLAUDE.mdを書く

まずプロジェクトのルートに `.claude/` ディレクトリを作り、`CLAUDE.md` を置く。書く内容は以下の最低限でよい。

• プロジェクトの概要（何を作っているか、技術スタック）
• コーディング規約（命名規則、ディレクトリ構造）
• 禁止事項（any型禁止、特定ライブラリの使用禁止 など）
• テスト方針（カバレッジ目標、テストの書き方のルール）

このファイルを置くだけで、Claude Codeの出力品質は明らかに変わる。「AIへの指示は毎回丁寧に」という消耗戦から解放される第一歩だ。

Week 1：3回繰り返した指示をスキルファイルに変換する

1週間使ってみると、同じような指示を何度も打っていることに気づく。その瞬間がスキル化のタイミングだ。`.claude/skills/<作業名>/SKILL.md` を作り、その作業の手順・注意事項・出力フォーマットを記述する。
スキルファイルは「チームの暗黙知を形式知に変える」ドキュメントでもある。Gitで管理すれば、新しいメンバーがチームに入った初日からAIを同じ品質で使えるようになる。プロンプト設計の属人化は、この一手で大きく緩和される。

Month 1：フックで品質チェックを自動化する

1ヶ月後には「ルール違反が繰り返される作業」が見えてくる。その作業をフック（イベント駆動の自動実行）で自動化しよう。Claude Codeであれば、ファイル保存時に自動フォーマット、タスク完了時に自動テスト実行、といった設定が可能だ。
フィードバックが即時になることで、AIへの「後からの修正依頼」という非効率なサイクルが消える。COLOPLをはじめ多くの先行企業が「AIの使い方は最初から完璧にはならない、継続的な改善が鍵」と強調している。ハーネス設計も同様に、使いながら育てていくものだ。

AIが自律的に動ける環境を支えるインフラ基盤として、Kubo（マネージドKubernetes）は月額8,800円〜でAIワークロードに最適化されたインフラを提供している。Claude Codeやエージェントを本番環境で安定的に動かすための基盤として、スケールアウトが容易な点が多くの開発チームに選ばれている。

まとめ：「ツールを入れる」から「環境を設計する」へ

「Claude Code 効果ない」「Cursor 使いこなせない」という悩みの正体は、ツールの問題ではなかった。ハーネス設計──すなわち「AIが正しく動ける環境の設計」──が抜け落ちていたことが根本原因だ。

まとめると、AI駆動開発を定着させるには以下の3層が必要だ。

• ルール層：CLAUDE.mdでAIに守るべき制約を宣言する
• スキル層：繰り返し作業をスキルファイルに変換し、チームで共有する
• フィードバック層：品質ゲートで逸脱を自動検知し、即時修正を促す

AIは「使う」フェーズをとうに超え、「協働できる環境を設計する」フェーズに入った。AIを同僚として迎え入れるなら、そのための「職場環境」を整える必要がある。AI Co-workの時代において、競争優位を生む差は「どのツールを使うか」ではなく「どんなハーネスを設計するか」で決まる。
ツールの導入は出発点にすぎない。環境設計こそが、AI駆動開発を「一部の人のスキル」から「組織全体の生産性」に変える唯一の道だ。

まずはハーネス設計の考え方を整理したい方は、Hexabase資料ダウンロードでAI駆動開発・ハーネス設計に関する資料を無料で入手できる。チームへの展開方法や具体的な設計支援が必要な場合は無料相談へ、実践スキルを体系的に習得したい方にはAI駆動開発伴走セミナー（入門2日〜アーキテクト養成コースまで）も用意している。