5つのAIエンジニアリングの違いとは？VS Code＋Codexでの実装方法【Windows】

AIエージェントを使った開発では、プロンプトエンジニアリング（Prompt Engineering）だけでなく、コンテキストエンジニアリング（Context Engineering）やハーネスエンジニアリング（Harness Engineering）といった言葉も見かけるようになった。しかし、それぞれが何を指し、VS CodeとCodexでどう実装すればよいのか分かりにくい人も多いだろう。

この記事では、上記の3つにループエンジニアリング（Loop Engineering）と評価エンジニアリング（Evaluation Engineering）を加えた5つを、「指示・判断材料・作業環境・反復・成功基準」に分けて解説する。WindowsのVS Codeで試せる最小サンプルも紹介するため、プロンプトを工夫するだけでは解決できない問題を切り分け、Codexへ安全かつ再現しやすい形で作業を依頼できるようになる。

なお、この5分類は排他的なものではなく、標準規格や成熟度の順番でもない。たとえばテストは、修正を繰り返すループエンジニアリングと、正しさを判定する評価エンジニアリングの両方に関係する。本記事では、実務で設計対象を整理するための見方として扱う。

5つのAIエンジニアリングの違い
5つのAIエンジニアリングを取り入れるメリット・デメリット
WindowsのVS CodeでCodexを準備する
VS Code＋Codexで最小サンプルを作って実装する
AGENTS.md・SKILL.md・MCP・テスト・config.tomlの役割
VS Code＋Codexで実装するときの注意点
まとめ

5つのAIエンジニアリングの違い

5つの違いは、AIに何をさせるかではなく、AIを使う仕組みのどの部分を設計しているかで考えると分かりやすい。

名称	主な設計対象	確認する問い	Codexでの例
プロンプトエンジニアリング（Prompt Engineering）	指示	何をしてほしいか	チャットへ入力する依頼文
コンテキストエンジニアリング（Context Engineering）	判断材料	何を知っていれば判断できるか	ソースコード、README.md、AGENTS.md、テスト結果
ハーネスエンジニアリング（Harness Engineering）	作業環境とツール	何を使い、どこまで作業できるか	VS Code、ファイル操作、ターミナル、サンドボックス
ループエンジニアリング（Loop Engineering）	反復手順	完了までどう進めるか	調査、修正、テスト、再修正
評価エンジニアリング（Evaluation Engineering）	成功基準	正しく完了したとどう判断するか	テスト、期待値、差分確認

実際の開発では、この5つが互いに重なりながら機能する。プロンプトに完了条件を書けばプロンプト設計と評価の両方に関係し、AGENTS.mdでテスト方法を伝えればコンテキストであると同時にハーネスの一部にもなる。

プロンプトエンジニアリング（Prompt Engineering）はAIへの指示を設計する

プロンプトエンジニアリングは、AIに何をしてほしいかを伝える指示の設計である。

たとえば、次の依頼だけでは、修正範囲や完成条件が分からない。

計算処理のバグを直してください。

次のように、目的、症状、制約、作業後の報告内容まで示すと、Codexが取るべき行動を判断しやすくなる。

加算関数のテストが失敗する原因を調査し、修正してください。

制約:
- 変更範囲は最小限にする
- 関係のないファイルは変更しない
- 外部パッケージは追加しない

作業後:
1. 修正したファイルと内容を説明する
2. テスト結果を報告する
3. 残っている問題があれば報告する

ただし、指示を詳しくするだけでは十分ではない。Codexが対象コードやテストを参照できなければ、適切な修正は難しい。その判断材料を整えるのがコンテキストエンジニアリングである。

コンテキストエンジニアリング（Context Engineering）は判断に必要な情報を設計する

コンテキストエンジニアリングは、AIが判断するために参照する情報を設計する考え方である。

Codexでは、開いているファイルや選択範囲などをコンテキストとして追加できる。プロジェクト内のREADME.md、AGENTS.md、関連コード、テスト結果も判断材料になる。Codexの統合開発環境（Integrated Development Environment：IDE）拡張に関する公式ドキュメントでは、IDE内のコンテキストを利用して作業を依頼できる仕組みが案内されている。

たとえば、同じ「バグを直して」という指示でも、次の情報があるかどうかで結果は変わる。

期待する動作が書かれたREADME.md
プロジェクト固有のルールを記載したAGENTS.md
修正対象のソースコードと失敗しているテスト
直前のテスト結果やエラーメッセージ

大量の情報を無条件に渡せばよいわけではない。古い仕様書や無関係なログが混ざると、Codexが重要な条件を見落とす可能性がある。必要な情報を、必要な範囲に絞って渡すことが重要になる。

ハーネスエンジニアリング（Harness Engineering）は作業環境とツールを設計する

ハーネスエンジニアリングは、AIが実際に作業するための環境、ツール、制約を整えることである。

モデルへの指示だけでは、ファイルの読み書きやテストコマンドの実行はできない。VS Code、作業フォルダー、ターミナル、ファイル操作、サンドボックス、承認ルールなどを組み合わせることで、Codexが開発作業を進められる。

OpenAIはハーネスエンジニアリングの事例として、環境やツールだけでなく、フィードバックループ、静的解析（Lint）、構造テストなどを含む設計を紹介している。また、巨大なAGENTS.mdへすべてを書き込むのではなく、短い案内と詳細ドキュメントを組み合わせる方法も示している。ハーネスエンジニアリングの解説も参考になる。

「テストを実行してください」はプロンプトエンジニアリングだが、Codexがターミナルでテストを実行できる環境や権限を用意することはハーネスエンジニアリングである。

ループエンジニアリング（Loop Engineering）は完了までの反復を設計する

ループエンジニアリングは、調査、実装、テスト、修正をどのように繰り返すか設計する考え方である。

バグ修正なら、次のような流れが基本になる。

原因を調査する
↓
コードを修正する
↓
テストを実行する
↓
失敗したら原因を調査して再修正する
↓
テストが成功したら差分を確認する
↓
完了条件を満たしたら終了する

サブエージェントはループエンジニアリングの必須要素ではないが、複雑な反復処理を分担する手段として活用できる。メインエージェントが調査、テスト、レビューなどの独立した作業をサブエージェントへ依頼し、その結果を集約して次の処理を判断する形である。

メインエージェント
├─ 調査担当のサブエージェント
├─ テスト担当のサブエージェント
└─ レビュー担当のサブエージェント
        ↓
結果を集約して評価する
        ↓
問題あり → 担当へ再依頼する
問題なし → 完了する

OpenAI Docsでは、Codexが専門化したサブエージェントを並列に動かし、メインエージェントが結果を1つにまとめる仕組みとして説明されている。探索、テスト、ログ分析など、互いに独立した作業を分担すると効果的である。Codexのサブエージェントに関する公式ドキュメントも参考になる。

サブエージェントの活用は、5つのエンジニアリングのうち複数に関係する。

利用できるエージェントや権限を整えることは、ハーネスエンジニアリングに当たる
担当ごとに必要な情報を渡すことは、コンテキストエンジニアリングに当たる
起動、待機、結果集約、再依頼、停止を設計することは、ループエンジニアリングに当たる
各担当の結果を合格・不合格に分けることは、評価エンジニアリングに当たる

ただし、サブエージェントはそれぞれモデル処理やツール操作を行うため、単一エージェントよりトークン消費が増える。複数のサブエージェントに同じファイルを同時編集させると競合しやすいため、最初は調査、テスト、レビューなどの読み取り中心の作業へ利用すると安全である。

Codexのエージェントループでは、ツールの実行結果をコンテキストへ加えて再び推論し、最終応答まで処理を繰り返す。Codexのエージェントループに関する公式解説を読むと、コマンド結果やファイル内容が次の判断につながる仕組みを理解しやすい。

ループエンジニアリングは比較的新しい捉え方であり、定義が完全に統一された用語ではない。IBMによるループエンジニアリングの解説でも、新しい実践領域として扱われている。

評価エンジニアリング（Evaluation Engineering）は成功基準を設計する

評価エンジニアリングは、何をもって正しく完了したと判断するかを設計することである。本記事では、評価基準、テスト、評価データを設計する実務の呼称として使用する。

AIが「修正しました」と回答しただけでは、バグが直ったとは判断できない。たとえば加算関数なら、正の数だけでなく、負の数や0を含む入力でも期待値と一致することをテストする必要がある。

評価には、次のような観点が含まれる。

指定したテストがすべて成功したか
変更範囲が依頼内容に収まっているか
既存機能を壊す差分がないか
制約やプロジェクトルールを守っているか

テストは合否を判定する評価であると同時に、失敗結果を次の修正へ渡す反復処理のフィードバックでもある。5分類は完全に分離できるものではなく、役割の違いを理解するための整理方法だと考えるとよい。

5つのAIエンジニアリングを取り入れるメリット・デメリット

5つの観点を取り入れる最大のメリットは、AIの出力品質をプロンプトだけに依存せず、開発プロセス全体で安定させやすくなることである。

メリットは再現性・安全性・完了判定を改善できること

指示、情報、環境、反復、評価を分けて考えると、次の効果が期待できる。

同じルールやテスト方法を再利用し、作業の再現性を高められる
作業フォルダーや権限を制限し、意図しない変更の危険を抑えられる
テストや差分を基準にして、作業が完了したか判断しやすくなる
失敗結果を使って再修正する流れを作り、人間の指示回数を減らせる

問題が起きたときも、「指示が曖昧だったのか」「必要な情報がなかったのか」「テストに抜けがあったのか」を切り分けやすくなる。

デメリットは準備と保守に手間がかかること

仕組みを増やすほど、設定や資料を維持する作業も必要になる。

AGENTS.mdやテストを用意し、変更に合わせて保守する必要がある
古い指示や仕様が残ると、Codexの判断を誤らせる可能性がある
ツールや権限を増やすほど、誤操作の影響範囲が広がる
テストに含まれない条件は、問題があっても見逃す場合がある

最初から複雑なスキル（Skill）やモデルコンテキストプロトコル（Model Context Protocol：MCP）を導入する必要はない。まずは小さな作業フォルダー、短いAGENTS.md、実行可能なテストから始めるほうが管理しやすい。

WindowsのVS CodeでCodexを準備する

Windowsでは、Linux用Windowsサブシステム（Windows Subsystem for Linux：WSL）を必須とせず、Windows上のVS CodeからCodexを利用できる。詳しい動作要件や変更される可能性がある情報は、Windows版Codexの公式ドキュメントで確認できる。

Codex拡張を有効化してサインインする

VS CodeでCodexを使う準備は、次の順番で進める。

CodexのIDE拡張に関する公式ドキュメントを開く。
公式ドキュメント内のインストール導線をクリックし、案内されたCodex拡張をVS Codeへインストールする。
VS CodeでCodex拡張が有効になっていることを確認する。
画面の案内に従ってサインインする。
アクティビティバーに表示されたCodexアイコンをクリックする。

検索結果だけを見て拡張を決めると、名前が似た別の拡張をインストールする可能性がある。公式ドキュメントのインストール導線を利用すると、対象を間違えにくい。

Codexアイコンが見つからない場合は、Ctrl + Shift + Pでコマンドパレットを開き、「Codex: Open Codex Sidebar」をクリックする。表示や初期設定は更新される可能性があるため、迷った場合は公式ドキュメントを確認するとよい。

作業フォルダーを開いて範囲を明確にする

本記事ではC:\workspaceを基準フォルダーとし、後述するC:\workspace\codex-practiceをCodexの作業フォルダーとして使用する。フォルダーを作成した後は、VS Codeの「ファイル」メニューから「フォルダーを開く」をクリックし、C:\workspace\codex-practiceを開く。

Codexは、開いているプロジェクトやファイルを手掛かりに作業する。別のプロジェクトを同じフォルダーへ混在させず、依頼に必要なファイルだけを含むフォルダーを用意すると、対象範囲が分かりやすい。

Windowsのエージェントモードでは、作業フォルダー外への書き込みや、承認なしのネットワークアクセスが制限される。サンドボックスや承認は安全性に関わるため、必要な操作だけを許可し、理由が不明な要求は承認しないことが大切である。

VS Code＋Codexで最小サンプルを作って実装する

ここでは、加算関数に入れた意図的なバグをCodexへ修正させる。Python標準のunittestだけを使うため外部パッケージは不要だが、Windows上でPythonを実行できる環境は必要である。

手順1：Pythonの実行環境を確認する

VS Codeで「ターミナル」メニューから「新しいターミナル」をクリックし、次のコマンドを実行する。

py --version

Pythonのバージョンが表示された場合は、次の手順へ進める。

pyコマンドを実行できない場合は、Python公式のWindows向けダウンロード案内に沿ってPython 3を先にセットアップする。セットアップ後はVS Codeのターミナルを開き直し、もう一度py --versionを実行する。

Pythonのインストール方法や個別の環境設定は、本記事の範囲外とする。py --versionでバージョンを確認できてから、以降のサンプルへ進む。

手順2：C:\workspaceに練習用フォルダーを作る

VS Codeのターミナルで次のコマンドを実行し、C:\workspaceの下にcodex-practiceフォルダーを作成する。

New-Item -ItemType Directory -Path C:\workspace\codex-practice -Force
Set-Location C:\workspace\codex-practice
code .

新しく開いたVS Codeで、次の構成になるようにフォルダーとファイルを作る。

C:\workspace\
└─ codex-practice\
   ├─ AGENTS.md
   ├─ README.md
   ├─ src\
   │  └─ calculator.py
   └─ tests\
      └─ test_calculator.py

エクスプローラー上で作成する場合は、「新しいフォルダー」アイコンと「新しいファイル」アイコンをクリックして追加する。

手順3：AGENTS.mdへ継続的な指示を書く

プロジェクト直下のAGENTS.mdへ、次の内容を記載する。

# プロジェクトの指示

## 目的

このプロジェクトは、Codexの練習に使用する小さなPython電卓である。

## 編集ルール

- 依頼された作業に必要な箇所だけを変更すること。
- 外部パッケージを追加しないこと。
- 誤った実装のままテストを成功させる目的で、テストを変更しないこと。

## 検証

- 編集後に`py -m unittest discover -s tests -v`を実行すること。
- テストが失敗した場合は、再編集する前に原因を調査すること。
- 変更したファイル、テスト結果、残っているリスクを報告すること。

Codexは、プロジェクトルートから現在の作業フォルダーまでのAGENTS.mdを階層的に読み、該当範囲の指示として利用する。AGENTS.mdの公式ガイドにも、テストやLintの実行指示を記載する例がある。

このファイルは、毎回のプロンプトへ書くには長いものの、同じプロジェクトで繰り返し守ってほしいルールに向いている。

手順4：README.mdへ目的を書く

README.mdには、サンプルの目的と実行方法を記載する。

# Codexの練習

このプロジェクトでは、Codexを使った小規模なバグ修正の流れを練習するために、`add`関数を用意している。

プロジェクト直下で次のテストを実行する。

```powershell
py -m unittest discover -s tests -v


README.mdは人間向けの案内であると同時に、Codexがプロジェクトの目的を理解するためのコンテキストにもなる。

### 手順5：意図的なバグを含む処理を作る

`src/calculator.py`へ次のコードを記載する。

```python
def add(a: int, b: int) -> int:
    """Return the sum of two integers."""
    return a - b

関数名と説明では加算すると示しているが、実際には減算している。このreturn a - bが修正対象である。

手順6：正の数・負の数・0をテストする

tests/test_calculator.pyへ次のコードを記載する。

import unittest

from src.calculator import add


class TestCalculator(unittest.TestCase):
    def test_add_positive_numbers(self) -> None:
        self.assertEqual(add(2, 3), 5)

    def test_add_negative_numbers(self) -> None:
        self.assertEqual(add(-2, -3), -5)

    def test_add_zero(self) -> None:
        self.assertEqual(add(0, 4), 4)


if __name__ == "__main__":
    unittest.main()

正の数だけではなく、負の数と0を含む3ケースを用意することで、評価の抜けを減らしている。

プロジェクト直下のターミナルで、修正前のテストを実行する。

py -m unittest discover -s tests -v

この時点では実装が誤っているため、テストは失敗する。失敗内容はCodexが原因を判断するためのコンテキストとなる。

手順7：Codexへ修正を依頼する

Codexのサイドバーを開き、次のプロンプトを貼り付ける。

このプロジェクトの加算処理でテストが失敗する原因を調査し、修正してください。

作業条件:
- 最初にAGENTS.mdとREADME.mdを確認する
- 変更範囲は必要最小限にする
- 外部パッケージを追加しない
- テストを通すためだけに、正しいテストを書き換えない

実装後:
1. `py -m unittest discover -s tests -v`を実行する
2. 失敗した場合は原因を調査し、必要なら再修正する
3. 変更差分とテスト結果を確認する
4. 変更したファイル、修正内容、テスト結果、残っているリスクを報告する

この依頼には、5つのAIエンジニアリングが小さくまとまっている。

プロンプト：原因調査と修正を依頼している
コンテキスト：AGENTS.md、README.md、コード、テストを参照させている
ハーネス：VS Code、ファイル操作、ターミナルを使える
反復処理：修正後にテストし、失敗時は再修正する
評価：3件のテストと差分で完了を判定する

手順8：承認内容を確認してから作業を進める

Codexがファイル変更やコマンド実行の承認を求めた場合は、対象ファイル、コマンド、影響範囲を読んでから承認する。

今回のサンプルで想定される修正は、src/calculator.pyの次の1行である。

return a + b

依頼と関係のないファイル変更、外部パッケージの導入、作業フォルダー外への書き込みなどを求められた場合は、すぐに承認せず理由を確認する。

手順9：修正・テスト・再修正の反復処理を確認する

Codexはコードを修正した後、指定されたテストを実行する。テストが失敗した場合は、その結果を新しい判断材料として原因を調査し、再修正する。

実装を確認
↓
calculator.pyを修正
↓
3件のテストを実行
↓
失敗なら原因を調査して再修正
↓
成功なら差分を確認

同じ失敗が続く場合は、無制限に変更を続けさせず、人間がエラーメッセージと差分を確認する。仕様が曖昧、Pythonを実行できない、必要な操作が権限外といった問題は、コード修正だけで解決できないためである。

手順10：差分と結果から完了を判定する

今回の完了条件は、次の3点である。

src/calculator.pyの加算処理が正しく修正されている
正の数、負の数、0の3テストがすべて成功している
依頼と無関係なファイルやテストが変更されていない

テスト成功だけで完了にせず、差分も確認する。期待どおりなら、プロンプトで依頼した作業を、コンテキスト、ハーネス、反復処理、評価によって完了まで支えられたことになる。

AGENTS.md・SKILL.md・MCP・テスト・config.tomlの役割

これらはすべてCodexの動作に関係するが、同じ目的の機能ではない。役割を混同すると、AGENTS.mdが長くなりすぎたり、不要な外部接続を増やしたりしやすい。

要素	主な役割	向いている内容	5分類との主な関係
AGENTS.md	プロジェクト内の継続指示	コーディング規約、テスト方法、禁止事項	コンテキスト、ハーネス
SKILL.md	必要なときに使う再利用ワークフロー	特定作業の手順、参考資料、補助スクリプト	コンテキスト、ハーネス、反復処理
MCP	外部ツールやデータへの接続	外部サービス、社内データ、専用ツール	ハーネス、コンテキスト
テスト	合否判定と失敗時のフィードバック	期待値、回帰確認、境界条件	評価、反復処理
config.toml	Codex全体の設定	モデル、権限、サンドボックス、MCP	ハーネス

AGENTS.mdはプロジェクトで繰り返し守る指示に使う

AGENTS.mdには、プロジェクト構成、変更時のルール、実行すべきテストなどを記載する。Codexは階層に応じてAGENTS.mdを読み込むため、共通ルールを上位へ、特定フォルダーだけのルールを下位へ分けることもできる。

一度だけの依頼内容まで書き込むのではなく、今後の作業でも繰り返し必要になる情報へ絞ると管理しやすい。

SKILL.mdは特定作業の再利用手順に使う

スキルは、タスク固有の専門知識、指示、参考資料、必要に応じたスクリプトをまとめる仕組みである。Codexはスキルの名前、説明、場所を手掛かりに必要なものを判断し、利用時にSKILL.md全体を読む。

リポジトリ固有のスキルは、$REPO_ROOT/.agents/skills/<name>/SKILL.mdという構成で配置できる。ここで、$REPO_ROOTはリポジトリの最上位フォルダー、<name>は実際のスキル名に置き換える表記である。詳しい仕様はCodexスキルの公式ドキュメントで確認できる。

ただし、今回のような小さなバグ修正ではスキルを用意する必要はない。同じ複雑な作業を何度も行うようになってから検討すればよい。

MCPは外部のツールやデータへ接続する

MCPは、Codexから外部ツールやデータへ接続するために使う。リポジトリ内のファイルとローカルテストだけで完結する作業では不要である。

外部接続を増やすとできることは広がるが、認証情報、アクセス権限、誤操作の影響範囲も確認する必要がある。必要な接続だけを追加することが安全なハーネス設計につながる。

テストは評価と反復の両方を支える

テストは「期待する結果になったか」を判定するため、評価エンジニアリングの中心となる。同時に、失敗結果をCodexへ返して再修正させるため、ループエンジニアリングのフィードバックとしても働く。

テスト件数を増やすだけでは十分ではない。正常系、異常系、境界条件など、実際に保証したい動作を表すテストを設計する必要がある。

config.tomlはモデル・権限・接続などを設定する

CodexのIDE拡張とコマンドラインインターフェース（Command Line Interface：CLI）は、config.tomlの設定を共有する。モデル、権限、サンドボックス、MCPなどを設定するためのファイルであり、ハーネスエンジニアリングに深く関係する。Codex IDE設定の公式ドキュメントで現在の設定項目を確認できる。

今回の最小サンプルでは、config.tomlの編集を必須にする必要はない。まず既定の安全設定で試し、作業上の必要性を理解してから変更するとよい。

VS Code＋Codexで実装するときの注意点

Codexを安定して利用するには、プロンプトの書き方だけでなく、古い情報、過剰な権限、評価の抜けにも注意が必要である。

5つの用語を標準規格として扱わない

プロンプト、コンテキスト、ハーネス、ループ、評価という分類は、実務の設計対象を理解するには便利だが、すべての資料や組織で同じ定義が使われているとは限らない。

特にループエンジニアリングや評価エンジニアリングは、プロンプトエンジニアリングほど定義が定着しているとは限らない。本記事の分類を唯一の正解とせず、チーム内では「何を設計対象と呼んでいるか」を確認する必要がある。

AGENTS.mdへ情報を詰め込みすぎない

AGENTS.mdが長くなりすぎると、重要な指示が埋もれ、古いルールも残りやすくなる。

常に守る短いルールとテストコマンドをAGENTS.mdへ書き、詳細な設計や手順は別のドキュメントへ分けるとよい。AGENTS.mdを案内図として使い、必要な資料へ誘導する構成が管理しやすい。

権限を広げる前にコマンドと差分を確認する

Codexから承認を求められても、内容を読まずに許可してはいけない。特にネットワーク接続、作業フォルダー外への書き込み、依存関係の追加は、今回の依頼に本当に必要か確認する。

作業後は、Codexの説明だけでなく変更差分を確認する。テストが成功していても、無関係なファイルが変更されていれば適切な完了とはいえない。

テストにない不具合は見逃す可能性がある

テストがすべて成功しても、テストしていない動作まで正しいとは限らない。今回の例でも、整数以外を受け取る場合や非常に大きな数を扱う場合は評価していない。

重要な処理では、実際の仕様に応じて正常系、異常系、境界条件、既存機能への影響を確認する。AIの回答ではなく、適切に設計した評価基準を完了判定に使うことが大切である。

Codexを開けない・テストを実行できないときの確認方法

Codexのサイドバーを開けない場合は、拡張が有効になっているか確認し、Ctrl + Shift + Pから「Codex: Open Codex Sidebar」をクリックする。それでも開けない場合は、VS Codeの再起動や拡張の状態、サインイン画面の案内を確認する。

テストを実行できない場合は、次の順番で原因を切り分ける。

VS CodeのターミナルがC:\workspace\codex-practice直下を開いているか確認する。
py --versionを実行し、Pythonを呼び出せるか確認する。
py -m unittest discover -s tests -vを手動で実行する。
表示されたエラーメッセージと、ファイル名やインデントの誤りを確認する。
Codexがコマンド実行を求めた場合は、内容と承認範囲を確認する。

pyコマンド自体を実行できない場合は、コードの問題ではなくPythonの実行環境を先に確認する必要がある。原因が分からないまま権限やサンドボックスを広げないことが重要である。

まとめ

プロンプト、コンテキスト、ハーネス、ループ、評価という5つのエンジニアリングは、それぞれ指示、判断材料、作業環境、反復、成功基準を設計する考え方である。5つは排他的な分類ではなく、テストやAGENTS.mdのように複数の役割を持つ要素もある。

WindowsのVS CodeとCodexでは、まず作業フォルダーを限定し、短いAGENTS.md、明確なプロンプト、実行可能なテストを用意すると始めやすい。修正後はテスト結果だけでなく差分も確認し、失敗が続く場合は仕様、実行環境、権限のどこに問題があるか切り分けることが大切である。

初回からスキル、MCP、複雑なconfig.toml設定まで導入する必要はない。小さなサンプルで「修正、テスト、再修正、差分確認」の流れを作り、繰り返す作業や外部接続が必要になった段階でハーネスを拡張するとよい。