非エンジニア向け完全ガイド+即使えるテンプレート3点付き
はじめに ― このtipを読むと、こうなれる
このtipの内容を最後まで実装すると、次の状態になります。
- Claudeに毎回同じ前提説明をしなくて済む(CLAUDE.mdを階層化して、必要な情報だけが自動でロードされる状態)
- モデルを変えなくても、レスポンスの精度が上がる(同じSonnetでも、整えた現場と整えていない現場では別物の挙動になる)
- 月額APIコストを抑えたまま、複雑なタスクをこなせる(無駄なコンテキスト消費が減るため、Opus多用を避けられる)
- 「見当違いのファイルを開きにいく」事故が消える(コードベースの地図をClaudeに渡せている状態)
- 足回りを「数年使い続ける」ための、月1のメンテナンスサイクルが回り始める(放置すると確実に錆びる仕組みを、回す仕組みに変える)
これらは、コードを書く能力ではなく、「自分の現場をClaudeに渡せる形に整える能力」で実現できます。
つまり、非エンジニアでも全部できます。
むしろ、非エンジニアこそ、ここから始めるべき内容です。その理由も含めて、本文で書きます。
このtipの対象読者
対象:
- Claude Code を実務で使い始めている(あるいは使い始めたい)非エンジニア
- 自前の自動化システムを VPS や個人マシンで動かしている個人運用者
- Claude のレスポンスが「なんか遅い」「無関係なファイルを開く」と感じたことがある人
- モデルを Opus に上げるとコストが膨らむので、別の方法で精度を上げたい人
- skill / hook / MCP / CLAUDE.md の使い分けを、自分の言葉で説明できるようになりたい人
対象外:
- Claude Code をまだインストールしていない人(まずは公式ドキュメントから)
- 大企業のモノレポ(数百万行規模)を運用しているエンジニア(公式記事の方が向いています)
- 「即儲かる方法」を探している人(このtipには書いてありません)
前提知識・必要な環境
必須:
- Claude Code をインストール済み
- ターミナル(macOS / Linux / Windows + WSL)を最低限触れる
- Git を最低限触れる(コミット、プッシュ程度)
あると望ましい:
- VPS や個人マシンで cron や systemd を動かした経験
- Python など、何らかのスクリプト言語を読める
不要:
- 高度なプログラミングスキル(本記事は非エンジニア向け)
- 特定のフレームワークの知識
- 業務での開発経験
このtipの構成
全体は4部構成です。
- 第1部:理論編(なぜ足回りなのか、Anthropic公式が整理した7要素)
- 第2部:実装ガイド編(ステップ1〜5の作業手順)
- 第3部:実践事例編(二つの現場の具体例、よくある失敗6つ、非エンジニアの罠3つ)
- 第4部:テンプレート編(即使えるテンプレート3つ)
「忙しいから結論だけ知りたい」なら、第2部の冒頭と、第4部のテンプレート3つを先に読んでも実装はできます。ただし、第1部の理論を理解したうえで第2部に入る方が、応用が効きます。
このtipの位置づけ
このtipは、単体で実装まで完結する設計にしています。他のtipsを買わなくても、ここに書いてある内容だけで、Claude Codeの足回り構築は一通り終わります。
ただし、同じ「非エンジニアの自動化現場×Claude Code」というテーマで、関連tipを今後も出していく予定です。気になる方は、Xで筆者をフォローしておくと、新作のお知らせが届きます。
第1部 ― 理論編
1. なぜ「モデル選び」ではなく「足回り」なのか
Claude Code を使い始めた頃、私はずっと、レスポンス品質の問題を 「モデルを切り替えるしかない問題」 だと思っていました。
Sonnetがいいのか、Opusで殴るのか、Haikuで足りるのか。ベンチマークと料金表を行ったり来たりしていた時期もあります。
でも、違った。
Claude Codeの性能は、モデルそのものよりも、それを取り囲む「ハーネス(=足回り)」で決まる。
これは、Anthropicが2026年5月14日に公開した公式ブログ 「How Claude Code works in large codebases」 で、数百万行のモノレポや数千人の開発者を抱えた組織向けに整理された運用パターンの、中心メッセージです。
最初は「大企業の話だろう」と思いました。
私のリポジトリは、せいぜい数万行。一人で運用している。非エンジニア。
でも、読み進めて、姿勢を正しました。そこに書かれていた原則は、規模に依存しなかったからです。
そして、私の現場(VPS上の自動売買エンジン、複数テーマのブログ自動投稿パイプライン、SNS自動投稿)に当てはめると、ほぼそのまま機能した。
「ハーネス」という言葉の意味
ハーネス(harness)は、馬具・装具という意味の英単語です。
馬の能力をどれだけ引き出せるかは、馬そのものの能力だけでなく、「どんな鞍を載せ、どんな手綱で繋ぎ、どんな鞭を使うか」で決まります。
Claude も同じです。モデルそのもの(=馬の能力)は、Anthropic が進化させてくれます。でも、それを使う側のハーネス(=馬具)が貧弱だと、せっかくのモデル性能を引き出せない。
逆に、ハーネスを丁寧に整えると、同じモデルでも別物のように働きます。
2. Anthropic公式が整理した7つの拡張ポイント
公式記事では、Claude Codeの性能を決める拡張ポイントとして、7つの要素が整理されています。
まず3つの中核から見ていきます。
中核1: CLAUDE.md ― 毎回読まれる「現場の取扱説明書」
セッションが始まるたびに、Claudeが自動で読むファイルです。
- ルートに置けば全体像が伝わる
- サブディレクトリに置けば、その場所のローカルルールが伝わる
Claudeは作業対象のディレクトリに移動した瞬間、上位のCLAUDE.mdを全部辿って読みます。だから階層的に置くと、必要な情報だけがコンテキストに乗る仕組みになります。
中核2: Hooks ― 「自動でやってもらう仕草」
毎回Claudeに口で言わなくても、特定のタイミングで自動的に走るスクリプト。
- lint や format の自動実行
- セッション終了時に CLAUDE.md の更新候補を書き出させる(自己改善の使い方)
- 危険なファイルへの書き込みをブロック(事故防止の使い方)
中核3: Skills ― 「必要なときだけ呼ばれる専門家」
CLAUDE.mdに何でも詰め込むと、毎回Claudeのコンテキストを圧迫します。
Skillsは、関連するタスクのときだけ自動で展開される仕組みです。再利用可能な専門知識を切り出すのに向いています。
ここまでが基礎。
周辺4要素
残る4つは、上の3つを補強したり、外と繋いだりするための周辺装置です。
Plugins は、skill、hook、MCP設定をまとめて配布できる仕組み。組織向けの話に見えますが、一人でも、複数マシン間で同じ設定を運ぶときに役立ちます。
LSP(言語サーバー) は、grepではなくシンボル単位で歩けるようにする仕組み。grepで文字列を探すと関数名が被っているだけのファイルも全部ヒットしますが、LSPは定義そのもの・参照そのものに正確に飛びます。多言語コードベースで効果が大きい。
MCPサーバー は、Claudeが外部のドキュメント、APIインフラ、社内ツールに直接アクセスできるようにする経路。
Subagents は、メインのClaudeとは別に、独立したコンテキストでサブタスクを走らせる仕組み。「コードベース全体をマップしてレポートにまとめる」のような読み取り専門の役割を、別の分身に任せる使い方です。
7要素の優先順位
非エンジニアの個人プロジェクトで導入する優先順位は、次の通りです。
- CLAUDE.md(階層化) ― ここから始める。投資対効果が最大
- Hooks(事故防止系3つ) ― 二番目に効く。事故予防として
- Skills(再利用可能な専門知識のみ) ― ある程度プロジェクトが育ってから
- MCPサーバー(必要なもののみ) ― 用途が見えてから接続
- Plugins ― 複数マシンや、他人と設定を共有するときに
- LSP ― 多言語コードベースを扱うときに
- Subagents ― 大規模な現状把握タスクが必要になったときに
「全部を一気に入れる」のではなく、1番から順番に、ひとつずつ整えていきます。
3. 非エンジニアこそ、ハーネスを最初に磨くべき理由
エンジニア出身の方は、たぶん、無意識のうちに「コードベースを他人に渡すときの作法」を身につけています。
READMEを書く、ディレクトリを切る、命名規則を揃える、共通の設定ファイルを置く。
これらは、いずれも「他人が読んだときに迷子にならない設計」です。
ところが、非エンジニアが思いつきで自動化を作り始めると、こうなりがちです。
- スクリプトを一つのフォルダにベタッと並べる
- 設定値はソースコードに直書き
- README は最初の日に1行だけ書いて、その後放置
- 動いているシステムと、過去に試した残骸が、同じディレクトリに同居
これ、自分一人でいじっているうちは、なんとなく動きます。
でも、Claude Codeにそれを渡した瞬間に、問題が露呈する。
Claudeは、人間の同僚が「あれはあのフォルダね、はいはい」と暗黙にやっているような補完を、できません。
非エンジニアがClaude Codeを使うとき:
- コードを書く部分は Claude が補ってくれる
- でも、コードベースを「Claudeにとって読みやすくする」部分は、誰も補ってくれない
ここに、非エンジニア特有のボトルネックがあります。
逆に言えば、ここさえ整えれば、非エンジニアの個人プロジェクトでも、Claude Codeは大企業の現場と同じレベルの再現性を出してくれます。
これが、本記事を書いた一番の動機です。
この記事のライター
