Claude Code のハーネスとは何か。素のままで使わない、という発想
Claude Code を1ヶ月触ると、機能はだいたい一巡します。なのに、人の作業環境を覗くと別物に見える——その違和感の正体は、素のまま使うか、自分用に仕立てているかの違いです。公式では「Customize」とまとめられ、開発者コミュニティでは「ハーネス」と呼ばれるこの領域を、Step 5 シリーズの1本目として整理します。
はじめに
Claude Code を1ヶ月ほど触ると、機能はだいたい一巡します。Hooks も Skills も SubAgent も、何ができるかはわかった。なのに、人の作業環境を覗くと別物に見える——あの違和感の正体は、Claude Code を 素のまま使うか、自分用に仕立てているか の違いです。
ひとつ最初にお断りしておきます。本記事のテーマである「ハーネス」は、公式ドキュメントには出てこない言葉 です。公式は同じ領域を「Customize with instructions, skills, and hooks」と呼んでいます。ただ、開発者コミュニティでは「ハーネス（harness）」という呼び方の方が広く使われていて、響きも内容に合っています。本記事もこの呼び方で進めますが、「公式では Customize、コミュニティではハーネス」という対応関係は頭に置いておいてください。
ここから始まる Step 5 シリーズ「ハーネス設計」 は、Step 1〜4 で学んだ Claude Code の機能を どう束ねて自分の作業環境にするか を扱う4本シリーズです。1本目の本記事では、まず「ハーネスとは何か」という視点そのものを入れます。
ハーネスとは何か
ハーネス（harness）はもともと馬具の言葉です。鞍・手綱・あぶみ・引き綱——馬を止める・進める・曲げるための道具一式をまとめてハーネスと呼びます。バラバラに持っていても意味がなく、ひとセットで初めて馬を制御する道具になる のが特徴です。
Claude Code に話を戻します。素の Claude Code は、それ単体でも便利な道具です。が、それだけだと毎回「日本語で返してほしい」「強い操作の前は確認してほしい」「このプロジェクトの方針はこうだ」を伝え直すことになります。これを毎回口頭でやるのは消耗します。
そこで、Claude の周りに 設定ファイル・ルール書き・自動化のしくみ を束ねて配置します。settings.json で許可の範囲を決め、hooks で保存後の自動チェックを仕込み、CLAUDE.md でプロジェクトの空気を伝え、Skills で専門知識を渡す。これらを ひとセットの設計 として持っておく状態が、本記事でいう「ハーネス」です。
Web 制作の例で言えば、デザインシステム に近い感覚です。CSS リセット・タイポグラフィのスケール・カラートークン・コンポーネント規約。1個ずつでも動くけれど、束ねて初めて「自分のサイトの空気」になる——あの感覚を Claude Code 側で再現する道具立て、と思ってください。
なお、既存記事「Claude Hooks とは何か」の中でも harness という言葉が出てきます。あちらは「Claude Code 本体（実行主体）」を指す狭い用法でした。本記事では同じ言葉を 設定一式という広い意味 で使い直します。同じ単語が文脈で2つの意味を持つ点だけ、最初に押さえておいてください。
素のままの Claude Code と何が違うか
ハーネスを着けるとどう変わるかを、Before / After で並べてみます。
Before：素の Claude Code
インストールしただけの状態だと、毎回こんな会話が繰り返されます。
- 会話を始めるたびに「日本語で返して」とお願いする
- ファイルを編集してもらうたびに「
npm run lintも走らせて」と頼む - 強い操作の前に「念のため対象を一覧で見せて」と挟む
- このプロジェクトの方針（例：Astro を使っている、テストフレームワークは Vitest）を毎回最初に説明する
便利は便利なのですが、毎回同じ依頼を口頭で出している自分 に気づきます。生産性の頭打ちはここから来ます。
After：ハーネスを着けた Claude Code
ハーネスを設計して着せると、同じ作業がこう変わります。
- CLAUDE.md がプロジェクトの方針を語る → 毎回の説明がいらない
- settings.json の permissions が許可の境界を決める → 安全な操作はノーチェックで進む
- hooks がファイル保存後に自動で lint をかける → 「lint も走らせて」が要らない
- Skill が「このプロジェクトのコーディング規約」を覚えている → 規約違反を Claude 自身が避ける
- SubAgent が長い調査を別働で済ませる → メイン会話のコンテキストが汚れない
ここで大事なのは、Claude そのものを改造したわけではない という点です。Claude は同じ Claude のまま。改造したのは 周辺のハーネス（馬具）側 だけです。ハーネスを外せば、また素の Claude Code に戻ります。周辺を整える という発想に立つと、できることがぐっと広がります。
ハーネスを構成する7つの部品
ハーネスを構成する主な部品を、ひと目で見えるように並べます。
それぞれの役割と置き場所を表にすると、こうなります。
| 部品 | 役割（一行） | 主な置き場所 |
|---|---|---|
| settings.json | ハーネスの設定本体 | ~/.claude/settings.json |
| permissions | やっていい操作の境界を決める | settings.json の中 |
| hooks | タイミングで自動的に動かす | settings.json の中 |
| CLAUDE.md | プロジェクトの取扱説明書 | プロジェクト直下 |
| skills | 専門知識のパッケージ | ~/.claude/skills/ ほか |
| subagents | 別働の Claude を呼び出す枠 | ~/.claude/agents/ ほか |
| MCP | 外の世界（Drive・Gmail 等）への接続口 | settings.json の中 |
各部品の詳しい話は、それぞれ単独の記事にまとめてあります。hooks は「Claude Hooks とは何か」、CLAUDE.md は「CLAUDE.md の書き方」、skills は「Claude Skills とは何か」、subagents は「Claude SubAgent とは何か」、MCP は「MCP とは何か」をそれぞれ参照してください。本記事では 個別機能には深入りしません。ここで扱いたいのは、これら7つを 束ねて1つのハーネスとして見る 視点の方です。
「機能」として見るのと「ハーネス」として見るのの違い
同じ7つを「機能カタログ」として見るのと、「ハーネス」として見るのとでは、頭の使い方が変わります。
機能カタログとして見ると、7個の独立した話になります。「hooks の書き方を覚えよう」「skills を作ってみよう」と1個ずつ深掘りする方向です。これはこれで悪くはないのですが、全体としてどう動かしたいか の絵を描くのは難しいままです。
ハーネスとして見ると、7個は 1つの作業環境を構成する7つの面 に変わります。「自分はどんな作業環境にしたいのか」を先に決めて、そこから「だったら hooks で何を自動化するか、CLAUDE.md には何を書くか、permissions はどう絞るか」を逆算する流れになります。設計が先、機能が後 の順番です。
ハーネス視点を持つと、機能の選び方そのものが変わります。これが本記事で一番伝えたい話です。
なぜハーネスという視点が必要か
「個別機能を1つずつ覚えていけば、いずれ全部わかるのでは？」と思うかもしれません。それでも、ハーネスという視点をわざわざ立てる理由が3つあります。
ひとつめは、個別最適の落とし穴 を避けるためです。hooks だけ凝って設定すると、「permissions で許した操作なのに hooks が止める」ような矛盾が起きます。CLAUDE.md と Skill が違う指示を出していて、Claude が混乱することもあります。全体を1つの設計として見ていれば防げる事故 が、機能ごとに別々に触っていると起きやすくなります。
ふたつめは、「自分専用の作業環境」を持つ感覚 が手に入るからです。エディタを使い込むと、誰しも自分用の設定（VS Code の settings.json、.vimrc、Neovim の init.lua）を持ちます。Claude Code も同じ温度感で、毎日触る道具なら自分用に仕立てるのが自然 です。ハーネスはその仕立てそのものを指す言葉です。Web 制作で言えば、ESLint と Prettier と EditorConfig をひとセットで揃えて、新しいプロジェクトでも同じ書き味を再現する——あの感覚に近いものです。
みっつめは、ハーネスごと持ち運べる からです。一度 ~/.claude/ をひとまとめに整えて Git で管理しておけば、新しいマシンでも、新しいプロジェクトでも、すぐに同じ作業環境が立ち上がります。Step 4 で扱った Claude Code スタイルガイド と組み合わせれば、自分の流儀をそのまま外に持ち出せる状態になります。
Step 5 シリーズの読み方
本シリーズ「Step 5: ハーネス設計」は、本記事を含めて全4本の構成です。
- 本記事：ハーネスとは何か（視点を入れる）
- 2本目：permissions と settings.json の設計（境界の引き方）
- 3本目：hooks による自動化設計（タイミング駆動の使い分け）
- 4本目：subagents と skills の組み合わせ（役割分担の設計）
繰り返しになりますが、本シリーズは 個別機能の使い方そのものは扱いません。それぞれの「使い方」は既存記事に任せて、ここでは どう組み合わせるか だけに絞ります。「機能はだいたい知っているのに、自分の作業環境がしっくり来ない」という段階の方に、ちょうど効く内容になっているはずです。
まとめ
要点を振り返ります。
- ハーネスは公式用語ではない（公式では Customize）。ただし開発者コミュニティでは広く使われており、設計の視点としては優れた呼び方
- 素の Claude Code は便利だが、毎日触るならハーネスを着せたほうが消耗が減る
- ハーネスを構成する主な部品は7つ：settings.json / permissions / hooks / CLAUDE.md / skills / subagents / MCP
- 7つは別物ではなく、1つの作業環境を構成する7つの面
- ハーネスを持つと、設計が先・機能が後の順番で物事を考えられるようになる
- 一度整えたハーネスは、Git で管理すれば新しいマシン・新しいプロジェクトでも同じ環境がすぐ立ち上がる
次回（2本目）は、ハーネスの中でも 境界を決める部分——permissions と settings.json の設計を扱います。「何をどこまで Claude に許すか」を考える、ハーネス設計の入り口です。続けて読むと、本記事の「視点」が 具体的な設定ファイル に着地する感覚がつかめるはずです。
WordPressを実際に動かしてきたサーバー：ロリポップ
Claude Code でWordPressサイトを組み立てるとき、最初に置く先として無理のないレンタルサーバー。月数百円から始められ、WordPressの自動インストールにも対応しています。設定で詰まりがちな初期段階の時間をかなり減らせます。