こんにちは！ 新卒5ヶ月目、IT未経験でエンジニアの世界に飛び込んだ、りほです！
普段はClaude Codeを使い、いわゆる「バイブコーディング（指示文でAIにコードを書かせるスタイル）」で開発を進めています。今は、先輩のえりかさんと一緒に社内システムの新規ページ作成や修正などを行っています。
コーディング経験ゼロの私が、Claude Codeだけで社内の基幹システムを作った話
Erika
実務を始めて約3ヶ月。現在の私は、設定していただいた開発環境で、毎日Claude Codeと相談しながら「どう実装していくか」を判断しているレベルです。
「Claude Codeに機能追加を頼んだら、既存のコードまで勝手に書き換えられた……」なんてこともあり、急に出てくるエラーに「なにこれ！？」と驚く毎日でした。ですが、このエラーが出るのにもちゃんとした理由があったんです！
その鍵となるのが「ハーネスエンジニアリング」の考え方でした。
画面上で動くかどうかでしか実装の良し悪しを判断できなかった私を支えてくれたこの考え方を、CTO室のせーさんやClaudeに聞きながら学びました。
今回は、IT未経験の方でも直感的に理解できるよう、わかりやすくまとめてみます！
※本記事の内容は2026年8月時点の情報をもとに執筆しています。紹介しているAIツールの仕様やライセンス条件は変更される可能性があります。最新情報や商用利用に関する詳細は、必ず各サービスの公式サイトおよび利用規約をご確認ください。ハーネスエンジニアリングとは
ハーネスエンジニアリングとは、一言でいうと「AIへのお願い」を、型やテスト、Hooksといった機械的な仕組みに置き換えて、確実に守らせるようにする設計の考え方です。指示するだけで終わらせず、その指示を「後から検知する」「先回りして防ぐ」仕組みとセットで用意する、というのがポイントです。
この記事では、その仕組みを「ハーネス」と呼びます。なぜこのたとえが使われているのか、まずは語源から見てみましょう。
ハーネスの語源
「ハーネス」とは、もともと馬具（手綱・鞍・腹帯など）の総称です。馬は強力で速いですが、手綱も鞍もなしに乗れば振り落とされるか、馬が行きたい方向に勝手に走り出してしまいます。
重要なのは、ハーネスは馬の能力を「制限」するものではなく、騎手と馬が安全に協働するための仕組みだということです。AIエージェントとエンジニアの関係も、まさにこれと同じ構造になっています。
- 馬 ＝ AIエージェント（強力だが、方向付けが必要）
- 騎手 ＝ エンジニア（方向を決め、安全を確認する）
- ハーネス ＝ 設定ファイル、リンター、CI、Hooks（安全に協働するための仕組み）
この考え方の基本になるのが、とてもシンプルな1つの式です。この式は、Terraformなどを作ったMitchell Hashimotoさんが2026年ごろに広めたと言われています。
- エージェント※ ＝ モデル ＋ ハーネス
-
- モデル（LLM） ＝ 「考える」頭脳の部分（ClaudeやGPTなど）
- ハーネス ＝ モデル以外の仕組み全部（ルール・設定・チェックツールなど）
※ここでいうエージェントとは、「モデル（頭脳）が道具を使い→結果を見て→次の行動を自分で決めるというループを自分で回せる」もののことです
最近では「モデルの性能差より、ハーネスの設計差のほうが成果を左右する時代になった」と言われているようなので、一緒に勉強していきましょう！
ハーネスの2つの部品：「ガイド」と「センサー」
ハーネスは、大きく分けて2つの部品でできています。
| 部品 | 役割 | 具体例 |
|---|---|---|
| ガイド（guides） | 間違える「前」に正しい道を伝える | CLAUDE.md、コーディング規約 |
| センサー（sensors） | 書かれたコードが本当に良いか「後から」検知する | テスト、型チェック（TypeScript）、Lint |
私に必要な「見た目以外の判断材料」の正体は、まさにこの「センサー」でした！
画面上で動いて見えても、テストが通らなければ論理が間違っているし、型チェックで弾かれればデータの形がおかしい。人間が付きっきりでコードを見張らなくても、センサーが自動でレビュアーの代わりをしてくれるんです。
ここから先は、私の実務にも近い「予算と実績の差異を計算する機能」を具体例に説明していきます。次の3つが代表的なセンサーです。どれも「書いた”後”から間違いを見つける」ので、すべてセンサーに分類されます。
- テスト（Vitestなど）：「予算100万 － 実績80万 なら、差異は20万になるはず」という答え合わせを実行してくれる道具。計算ロジックが壊れた瞬間に赤くなります。
- 型チェック（tsc）：「金額は数値のはずなのに文字が混ざっている」といった、TypeScriptの型（データの形）の食い違いを検査する仕組み。形が合わないと赤線で教えてくれます。
- リンター（ESLintなど）：差異計算のコードを実行せずに読んで、「使っていない変数がある」などの”書き方の崩れ”を自動で指摘してくれる道具。自動レビュアーのイメージです。
ハーネスエンジニアリングでできること（弱いお願いから強い仕組みへ）
バイブコーディングをしたことがある方、CLAUDE.mdに「箇条書きで記述してください」と書いたとして、AIは常に従ってくれますか？
指示に従ってくれることもありますが、タスクが複雑になるほど無視される頻度は上がってしまいます。これが「お願いベース」の限界です。ハーネスエンジニアリングの核心は、同じルールでも、手軽な「お願い」から「強い仕組み」へ格上げできるという点です。
- お願い：CLAUDE.mdに書くだけ
→守るかどうかはAI次第。 - ルール：リンター（ESLintなど）をCI（自動チェック）に載せる
→CIとは、コードをpushしたり共有したりするたびに、ビルドやチェックを自動で回してくれる仕組み（GitHub Actionsなど）のこと。チェックに失敗したら、その先へ進めないように止められます。 - 物理法則：Hooks（自動実行）で縛る
→Hooksとは、「このタイミングが来たら、必ずこのコマンドを実行する」という仕掛け（例：ファイルを編集したら自動でテストを回す）。AIの気分に関係なく必ず走るのが特徴です。
ここでの「強さ」ってどういう意味？
一つだけ先に整理しておきます。この「お願い ＜ ルール ＜ 物理法則」の「強さ」は、「AIの手元の作業をその場でどれだけキツく縛れるか」という意味です。Hooksは毎回必ず自動で走るので、この意味では一番強い、というわけです。
ただ、「強さ」にはもう一つの見方があります。見方を変えると順番はひっくり返ります。「チームの本番コードに、悪いものが絶対に混ざらない保証」という意味で見ると、実はCI ＋ ブランチ保護ルールのほうが強い関門です。Hooksはあくまで自分のローカル環境の設定なので、設定を切ったり、その設定を持っていない同僚の環境では走りません。一方CIはサーバ側で全員に効いて、マージそのものを止められます。
なので「Hooksが最強」なのは、あくまでAIをその場で縛る力の話、と覚えておくのがおすすめです！
私が一番混乱したポイント
正直、私はここで立ち止まってしまいました。原因を自分なりに突き止めたので、同じところでつまずく人のために残しておきます！
上の「お願い ＜ ルール ＜ 物理法則」は、“強制力の強さ（その場で縛る力）”の順で並んでいます。
私は最初、開発中のどのタイミングで効くのか（時間の順）という視点から読んでいて、「あれ、噛み合わない……」と思っていました。
ですが、この2つは別々のものさしで、並べてみると順番が変わります。
- 強さの順
- お願い ＜ ルール ＜ 物理法則
- 時間の順
- お願い（書く前） → 物理法則（Hooks・保存の瞬間） → ルール（CI・共有するとき）
真ん中のHooksとCIが入れ替わるんです！ 「一番強いはずのHooksが、時間で見ると真ん中に来る」。これが私の引っかかりの正体でした。
時間の流れで並べると、こんなイメージです。
Hooksは一番強い（その場で縛る力）けれど、発動は手元の作業中。CIは強さは中くらいだけど、発動は一番あと。そして、もう一つ違いがあります。お願いと物理法則はローカルで行われるのに対して、ルールはリモートなんです。だから、どちらのものさしで見るかで並びが変わって当然なんですね。
もし私と同じで「時間の流れで理解したい！」というタイプの人は、上の図の順番（書く前 → 保存時 → 共有時）で理解するのがおすすめです。
具体例で見る：ガイドとセンサーでのルールの守らせ方
さきほどの差異計算の例で考えてみましょう。
たとえば、「金額の計算にズレが出ないよう、予算・実績・差異はすべてDecimal型で扱う」というルールを守らせたいとき、これも弱いお願いから、強い仕組みへ格上げしていけます。
- 弱いお願い：文章でお願いする（CLAUDE.md）
→「金額はDecimal型で扱ってね」と書くだけ。タスクが複雑になるとAIに無視されがちです。 - 強い仕組み①：型で先回りして防ぐ（＝ガイド）
→schema.prismaというファイルに「この金額カラムはDecimal型」と書いておくと、型とデータベースの両方から機械的に守らせられます。間違いを”書く前”に防ぐので、これはガイドの役割です。（Prismaは、Float型だと計算の精度が狂うことがあるので、お金は必ずDecimal型にするのが定番です！） - 強い仕組み②：あとから検知する（＝センサー）
→型チェック（tsc）やテスト（Vitest）が、「守られていないコード」を後から見つけて赤くしてくれます。Vitestは「この入力なら、この結果になるはず」を実行してくれる道具で、計算が壊れた瞬間に画面が赤くなってエラーを教えてくれます。これはセンサーの役割です。
💡 解説
ここで出てくるPrismaを少し解説します。Prismaは、TypeScriptのコードからデータベースを操作するためのORM（Object-Relational Mapper/翻訳係）です。ただしファイルを1つ置けば動くものではなく、以下の手順が必要です。
- npmでライブラリを入れる
prisma/schema.prismaにテーブル定義を書く.envに接続先を書くnpx prisma generateで翻訳係のコードを自動生成するnpx prisma migrate devで実際にDBへテーブルを作る
設計図を書くだけでは何も起きず、コマンドで変換する工程が肝になります。
💡 補足
ここでちょっとややこしいのが「型」の扱いです。実は「型」は、見る角度によってガイドにもセンサーにもなります。
- ガイドとしての型：型を定義すること（例：Decimal型を指定する）は、間違いを先回りして防ぐ役割
- センサーとしての型：その型が守られているかを型チェッカーが検知する（tscが赤線を出す）役割
同じ「型」でも、”書いて縛る側”か”あとからチェックする側”かで役割が変わる、と整理すると分かりやすいです。
「AIに言葉で指示しても無視される……」と嘆くのではなく、弱いルールを、機械的に弾ける「型」や「テスト」などの強い仕組みに置き換えていくこと。これこそがハーネスエンジニアリングの実践です。
バイブコーダーの私が今日から始めるステップ
全部一気にやる必要はない、こうした仕組みを1つずつ入れていくのがコツだと思うので、私もできる順に試してみることにしました！ 前提として、まずは開発プロセス全体の流れを掴んでおきます。
開発プロセス全体を表すと、次のようになります。
- 知識：AGENTS.mdや設計ドキュメントを読み、方針を理解してからコードを書き始める
- ルール：リンター・Hooksが自動チェックし、違反があれば修正ループに差し戻す
- フィードバック：テスト実行・動作検証の結果をセルフレビューし、問題があれば再び修正へ
このプロセスを経ることで、受け入れ基準を満たしたコードだけが最終的なアウトプットとして残る仕組みになります。
ステップ①：CLAUDE.mdを書く
プロジェクトのルートにCLAUDE.mdを置きます。
ポイントは長文の取扱説明書にせず、「シンプルな作業メモ」にすることだそうです。Anthropicの公式ガイドでも「とにかく簡潔に」と言われていて、行数の目安としては「だいたい200行以内（短いほど良い）」がよく引き合いに出されます。
よく使うコマンド（npm run dev など）や絶対ルールを書いておくだけで、AIの迷いが激減します！
ステップ②：TypeScriptの型チェックを厳しくする
設定ファイル（tsconfig.json）で "strict"：trueにします。
これをONにするだけで、AIがやりがちな「データが存在しないかもしれないのに、ある前提で進めて本番で落ちるバグ」を、コードを書いた瞬間に赤線で教えてくれるようになります。
ステップ③：大事なロジックだけにテストを書く
全部のコードにテストを書くのは大変なので、「お金の計算」や「差異の計算」など、間違えたら困る核心部分だけにテストを書きます。
なので、例を用いると、「予算100万－実績80万＝差異20万」になることを書きます。コードもテストも両方AIに任せると、AIは「自分の間違ったコードが通る都合のいいテスト」を作ってしまいます。「正解の仕様は人間が握り、毎回のチェックは機械に任せる」。これが正しい役割分担なんですね。
まとめ：目標「1人で開発できるようになりたい」
今回ハーネスエンジニアリングを学んで、「1人で開発できるようになりたい」という目標に一歩近づけた気がします。
私にとっての1人開発の本質は、自分が完璧な天才エンジニアになることではなく、自分の代わりに品質を見張ってくれる「センサー（仕組み）」を味方につけることで解決できそうです。
見た目が動くだけで安心するバイブコーディングから一歩抜け出して、AIと一緒に正しく安全なシステムを作れるように、まずは1行のCLAUDE.mdと型チェックから育てる習慣をつけていきたいと思います！
- 日本・海外（フィリピン）での活躍チャンス
- 最先端技術と多言語環境での成長
- 入社後はメンターがそばで支える安心の成長環境
現在、IT職・営業職ともに積極採用中です。「挑戦できる環境で早く成長したい」「世界を舞台に活躍したい」そんな方は、以下よりぜひご応募ください！
