Claude CodeでLLM開発が変わる理由。プロンプトより重要な環境設計とハーネスエンジニアリングとは

LLMエージェント開発において、プロンプトを磨き続ける手法は変化している。現場では「指示」から「環境設計」へのシフトが起きている。

精巧なプロンプトを書いても、LLMの推論能力だけに頼る開発には限界がある。ファイル構成やワークフローを構造化し、LLMが動くための「ハーネス（枠組み）」を構築する手法がとられている。

この記事では、SaaS開発における「プロンプトより重要な環境設計」の正体と、Claude Codeを「状態を持つエージェント」へと進化させる手法を解説する。コードを書く前に「ディレクトリ構造」を設計する理由を、事実で紐解く。

LLMエージェント開発を支える「ハーネスエンジニアリング」の台頭

2026年、AIエージェント開発の現場で「ハーネスエンジニアリング」という概念が注目されている。これは、LLMへの指示文を最適化する従来のプロンプトエンジニアリングとは異なるアプローチである。

LLMの推論能力にすべてを委ねるのではなく、ファイル構成や構造化データを用いて、モデルが動くための「制約」や「枠組み」をシステム的に設計する。この動きは、セキュリティ分析AIエージェントの分野から広がった。

特定のセキュリティツールでは、プロンプトで指示するだけでなく、エージェントが参照するディレクトリ構造やJSON形式のワークフローを設計し、モデルの不安定さを補完している。この設計手法を取り入れた開発者からは、「プロンプトの修正回数が減り、エージェントの回答精度が安定した」という報告がある。

Claude Codeを活用した開発環境でも同様の変化がある。チャットで逐次指示を出す代わりに、`.claude/` フォルダ配下にルールやワークフローを記述したMarkdownファイルを置くことで、エージェントの挙動を固定する手法が一般的である。

複数日や複数フェーズにわたる開発では、セッションを超えて「要件定義レポート」や「アーキテクチャ履歴」をファイルとして保持する。それをエージェントに読み込ませることで、翌日以降の作業再開がスムーズになることが示されている。

これらの動きは、人間がLLMとの間で「文脈」をコピー＆ペーストして運搬する非効率なプロセスからの脱却である。

しんたろー：
LLMに毎回同じ説明をするのは無駄が多い。ThreadPostの開発で、最初は都度プロンプトを投げていたが、今は `.claude/` にルールを書き込むだけで済む。エージェントとの対話が「指示」から「確認」に変わる。開発効率が上がり、ストレスが減る。

現在のLLMエージェント開発は、以下の3つの要素を構造化する方向にシフトしている。

* エージェント定義: 各役割に応じた専用の指示書をMarkdownで管理する

* ワークフロー管理: 繰り返される業務をヒアリングベースで生成し、自動化する

* 状態の外部化: セッションの記録やレポートをタイムスタンプ付きでファイル出力し、文脈を永続化させる

これらの手法は、公開されているOSSのエージェント構成や、Claude Code向けのフレームワークに反映されている。グローバル環境を汚さず、プロジェクト単位で完結する設計思想は、個人開発者にとって親和性が高い。

LLMが迷わず動ける「道」を設計することが、現在の開発者にとって高いレバレッジを生む投資先である。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、AI最新情報を開発者目線で解説する「AI活用Tips」である。

あわせて読みたいClaude Codeの使い方完全ガイド｜インストールから実践まで2年運用の開発者が解説 →

プロンプトの限界を突破する「ハーネス」という考え方

LLMに対して気の利いたプロンプトを書くことに腐心する開発者は多い。しかし、Claude Codeで1人SaaSを開発する過程では、プロンプトだけで複雑なエージェントを制御することに限界がある。プロンプトは「指示」であり、LLMの解釈や処理の深さは、モデルの機嫌やコンテキストの量に左右されるためである。

そこで注目されているのが、LLMをシステム的に拘束し、安定した挙動を強制する「ハーネスエンジニアリング」である。LLMという不安定なエンジンに、堅牢な「外骨格（ハーネス）」を装着する。具体的には、プロンプトの中にすべての手順を書き込むのではなく、プロジェクト内に「.claude/」のようなディレクトリを設け、そこに要件定義書やコーディング規約、実行可能なワークフローを構造化して格納する。

しんたろー：
毎日Claude Codeを叩いていると、同じ説明を繰り返す瞬間がある。チャットの履歴を遡るのではなく、ディレクトリ構成でルールを固めると、LLMの動きが安定する。開発時間を削るための有効な手段である。

この手法において「自由度」と「規約」を両立させる点は議論の対象となる。手段を細かく指定すると環境依存で失敗するため、目的のみを定義し、プロセスはLLMに任せるべきだという意見がある。一方で、専用のワークフローや厳格な規約を定義して、LLMの動き方をシステム的に制御することを推奨する意見もある。

開発者が「何を自動化し、何を人間が判断すべきか」という境界線をどこに引くかという戦略の違いである。コードの品質を担保するテスターエージェントには厳格な規約が必要だが、新しい機能を模索するアーキテクトエージェントには、ある程度の自由度が必要となる。

これらの制御が「人間にとって読みやすいMarkdown」で行われている点は特筆すべきである。PythonやJavaScriptで複雑なフレームワークを組むことも可能だが、Markdownでエージェントのルールを記述すれば、開発者自身がいつでも中身を確認し、修正できる。ブラックボックス化しがちなLLM開発において、人間が主導権を握り続けるための防衛策である。

また、LLM同士が直接文脈をやり取りするプロトコルを確立する動きも加速している。人間がチャットの内容をコピー＆ペーストして、別のLLMに貼り直す「運搬作業」は、開発における無駄である。LLMが解釈可能な形式で文脈を直接渡す仕組みを構築できれば、開発の再現性は高まる。

Claude Codeは、こうした「環境設計」を完結させるためのプラットフォームになりつつある。セッションの記録を自動でファイル化し、それを翌日のLLMが読み込んで作業を再開する。このループを回すことで、1人開発の生産性はチーム開発のレベルに近づく。

LLM開発における「エンジニアリング」とは、モデルの推論能力を信じてプロンプトを磨くことではない。LLMが迷い込んだり、勝手に深掘りしすぎたりしないよう、システム的な制約を設計し、LLMが動くための「道」を整備することである。

今すぐ取り組むべき「環境設計」の具体策

変化を開発に落とし込むには、プロンプトをいじる時間を削り、「LLMが読み込むドキュメントの構造化」に時間を割く必要がある。

明日から実践できるアクションは以下の3点である。

まずは、プロジェクトのルートディレクトリに「CLAUDE.md」を配置し、そこにワークフローを記述すること。毎回「テストを書いてから実装して」と指示する手間が消える。指示を忘れてモデルの挙動がブレるストレスから解放されることで、開発の集中力は維持される。

次に、「REQUEST.md」のような依頼用ファイルを活用すること。タスクを依頼する際、背景や前提条件をチャットで打ち込むことは避ける。必要な情報をMarkdownファイルにまとめ、それを読み込ませて「このファイルに従って実装して」と投げる。翻訳の手数を減らすことで、情報の劣化を防ぎ、LLMの推論精度を最大化する。

最後に、「セッションの記録」をファイルとして残す習慣を付けること。Claude Codeを使用する場合、セッション終了時に「何が成功し、何が残タスクか」をレポートとして保存する。翌日、そのファイルを読み込ませるだけで、前日の文脈を引き継いだ状態で開発を再開できる。1人SaaS開発における「疑似チーム開発」の仕組みである。

しんたろー：
LLMは「指示待ち」させると精度が落ちる。構造化された「道」を用意すれば、正確に走る。最近は実装コードを書く時間より、`.claude/` フォルダの中身を整える時間の方が長い。結果的にバグも減り、精神的に楽になる。

これらの作業を「面倒なドキュメント作成」と捉えず、将来の自分に向けた「プログラミング」と考える。コードを書くことだけがエンジニアリングではない。LLMというエンジンを、脱線させずにゴールまで走らせるための「ハーネス（制約）」を設計することこそが、現代の開発者のスキルである。

まずは「自分が毎日繰り返している指示」を、Markdownファイルに書き出すことから始める。その効率を体験すれば、チャット画面でプロンプトを打ち続ける日々には戻らない。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

よくある質問

プロンプトエンジニアリングとハーネスエンジニアリングはどう違うのですか？

プロンプトエンジニアリングは「LLMの出力内容」を言葉で制御しようとする試みである。ハーネスエンジニアリングは「LLMが動く枠組み（アーキテクチャ）」を設計することで、モデルの不安定さをシステム的に補完する手法である。例えば、プロンプトで「事実と仮説を分けて」と頼むのが前者であり、エージェントの処理フローやツール利用の制約をコードや構造化ファイルで固めるのが後者である。実用的なエージェント開発では、両者の組み合わせが用いられる。

Claude Codeを使いこなすために、まずは何から始めるべきですか？

まずは「CLAUDE.md」を作成し、プロジェクトのルールやワークフローを記述することから始める。次に、依頼内容をファイル単位で構造化する「REQUEST.md」の考え方を取り入れ、LLMに渡すコンテキストを整理する。さらに、複数日の開発を行う場合は、セッションの記録やレポート出力を自動化する仕組みを導入すると、翌日以降の作業再開がスムーズになる。小さなタスクから、環境を定義する意識を持つことが重要である。

構造化ファイルを使うと、かえって自由度が下がりませんか？

構造化によって「思考の自由度」は高まる。曖昧な指示に悩む時間が減り、LLMが自律的に動ける範囲が明確になるためである。制約を書くことは自由を奪うことではなく、LLMが「どこまで踏み込んでいいか」の安全地帯を広げる作業である。何も制約がない状態では、モデルは無難で浅い回答に逃げがちになる。意図的に制約を設けることで、LLMの持つポテンシャルを引き出すことが可能になる。

まとめ

LLMに「指示」を投げ続ける時代は変化している。今、開発者に求められているのは、モデルの推論能力を最大限に引き出すための「環境設計」である。

コードや設計書、そして日々のワークフローを構造化し、LLMが迷わず動ける「ハーネス」を構築する。このエンジニアリングこそが、個人開発の生産性を変える鍵である。

「指示」から「環境」へ。開発ワークフローを構造化し、AIと共に次のステージへ進む。