コーディングエージェントを利用する際に、人間は何を考え、何をする必要があるか。
このテーマについて、多くの情報を総合すると、二点に集約されると考えています。
現時点での私の見解は「環境整備」と「評価」の2つです。AIが作業に入る前に働きやすい状態を作ることと、出てきたものを判定することです。
AIを社員だと考えてみる
環境整備という言葉だけだと抽象的なので、AIを社員だと考えると分かりやすいです。
非常に優秀だが、自社の事情は何も知らず、社内の暗黙のルールも分からず、最終的な責任は取れない社員。この人に成果を出してもらうために上司がやることは、細かく指示を出すこと以上に、動きやすい職場を作ることだと思います。前提を共有し、手順を渡し、やってはいけないことを先に伝えておく。そして成果物を誰がどこで確認するかを決めておく。というイメージです。
環境整備と評価はループしている
環境整備はAIが作業に入る前の工程、評価は終わった後の工程です。この2つはループになります。
[人間] 環境整備 ──→ [AI] 作業 ──→ [人間] 評価
↑ │
└────── 失敗パターンの還元 ←────────┘評価で見つかった失敗を環境整備に還元すると、次回以降の失敗率が下がります。AIに任せる作業量が増えても、このループ自体は人間が回すことになります。
以降、環境整備を「何を渡すか」「手順をどう残すか」「どこまで任せるか」の順に見たあと、評価の話に移ります。
環境整備：AIが動き出す前に決めること
何を渡すか
いわゆるコンテキストエンジニアリングの領域です。Anthropicはこれを「プロンプトエンジニアリングの自然な発展形」と位置づけています。指示文の書き方を工夫するのがプロンプトエンジニアリングなら、こちらはモデルに渡す情報全体（システム指示、ツール定義、外部データ、会話履歴など）をどう取捨選択するかを扱います。
コンテキストウィンドウが大きくなったから関係しそうな情報を全部入れる、という戦略は機能しません。同記事によると、渡す情報が増えるほど、モデルがその中から正確に情報を拾う精度は落ちます。程度の差はあれ、すべてのモデルに現れる性質だそうです。
なので、事前に渡すものと参照させるものを分けることになります。アーキテクチャ方針、命名規約、禁止事項、ビルドとテストのコマンドは変動しないのでルールファイルに書いて常時読み込ませる。個別の設計書やAPI仕様、過去の経緯は量が多く変わりやすいので、どこを見ればいいかだけ教えて必要になったら読ませる等です。
ただ、最近はそもそもモデルや環境（CursorやClaudeのデフォルト設定等）の変化によってベースの精度がかなり高く、過度に気にする必要はないと個人的には考えています。
参考：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
手順をどう残すか
試行錯誤して見つけた良い指示が個人のチャット履歴に埋もれる、というのは組織として損です。かと言って、プロンプト集を共有するのも探しにくかったり、プロジェクトの固有文脈に弱くなります。
対処はシンプルで、プロンプトをファイルにしてリポジトリに入れます。差分が見えるし、Pull Requestでレビューできるし、チーム全員が同じ指示を使えます。主要なAI開発ツールはいずれも、Markdownファイルを置くと/コマンド名で呼び出せる仕組みを持っています（スラッシュコマンド）。
手順をすべてルールに書いて常時読み込ませるとコンテキストを圧迫します。短い指針や制約はルール、複数ステップの手順は呼び出し式のコマンド、という切り分けになります。
参考：https://code.claude.com/docs/en/slash-commands
どこまで任せるか
3つの中で一番判断が要るところです。
ルールもコマンドも、結局はLLMへのお願いです。読んでもらえる確率は高いですが100%ではありません。「編集したらフォーマットして」と書いても、飛ばされることはあります。
ではスクリプトを置いておけば足りるかというと、それだけでは足りません。スクリプトは「何をするか」を決める側で、誰かが呼ばないと動きません。AIに「このスクリプトを実行して」と頼むだけでは、またお願いの世界に戻ってしまいます。
そこで出てくるのがフック（Hooks）です。Claude Codeの公式ドキュメントでは、フックを「Claude Codeのライフサイクル上の特定の時点で実行される、ユーザー定義のシェルコマンド」と説明しています。ポイントは、LLMが選んで実行するのではなく、ツール側が決まったタイミングで必ず走らせることです。たとえば「ファイルを編集したあと」「シェルコマンドを実行する前」に、フォーマッタや危険操作のチェックを自動でかけられます。スクリプトは中身、フックはその起動スイッチ、という関係です。
同じ「自動でやらせる」でも、分かれ目は文脈を読む必要があるかどうかです。
・文脈次第で答えが変わるもの（設計判断、レビューコメントの中身、ドキュメントの書き方）はAIに任せる
・答えが決まっていて例外を許したくないもの（フォーマッタ、Lint、本番への破壊的操作のブロック）は、スクリプトをフックで必ず走らせる
この線引きを先に決めておくと、後からルールを増やし続ける展開になりにくいです。
参考：https://code.claude.com/docs/ja/hooks-guide
評価：出てきたものを判定する
ここで言う評価（Evals）は、出力が期待する要件や品質を満たしているかを判定する仕組みのことです。先述したコンテキストについては頻繁に言及されるイメージがありますが、評価については今年に入ってからちらほら見かけるようになった印象です。
誰が評価するか
Anthropicは、エージェントの評価はコードベース／モデルベース／人間の3種類を組み合わせるのが一般的だと整理しています。
推奨は、機械的に判定できるところはコードベースに任せ、柔軟性が要るところにLLMを使い、人間は追加の検証、というものです。
何を評価ケースにするか
同記事は「実際の失敗から集めた20〜50件のシンプルなタスクで十分に良いスタートになる」としています。大事なのは、出どころが実際に起きた失敗であることです。規約に反したコードを書いた、必要なエラーハンドリングを飛ばした。そうした失敗をそのまま評価ケースに変えていくのが現実的だと思います。
参考：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
失敗をどこに還元するか
評価で見つけた失敗を環境整備のどこに戻すかを判断できて、初めてループが回り始めます。
・前提知識が足りていなかった → 渡すコンテキストに追記する
・手順の一部を飛ばしていた → コマンドとして手順を明文化する
・何度言っても守られない → スクリプトで機械的に強制する
・そもそも良し悪しの基準が曖昧だった → 評価基準を定義し直す
一番下が特に大事だと思っています。AIの出力が微妙だと感じるとき、自分たちが基準を言語化できていないことにある場合は少なくありません。言語化できて初めて、ルールにもスクリプトにも落とせます。（もちろん、言語化の補助にAIを使うのもよくあるケースです）
ただ、これを人手でルールファイルを開きながらゴリゴリ直す必要はありません。失敗に気づいたその場で、「このミスをルールに追記して」「次から飛ばさないよう手順をコマンドにして」とAIに頼めば足ります。人間がやるのは、どこに還元するかを決めることと、出てきた変更が妥当かを見ることです。
補足1：マルチタスク前提でどこまでやるか
ここまで書いておいてなんですが、受託開発で1人が複数案件を持っている状況だと、フィードバックループをフルセットでやるのは現実的ではないと考えています。
自社プロダクト等で1つのリポジトリを長く触り続けるならルールを育てフックを組む投資が回収できますが、受託開発の場合はそもそも「プロジェクトの環境を育てる」という感覚を持つのが難しいと感じている人が多いと思います。
ただ、このループの一部はAI側がやってくれるようになってきました。Cursorの公式ドキュメントは、ルールについて「まずシンプルに始める。エージェントが同じミスを繰り返していると気づいたときだけルールを足す」と書いています。OpenAIのCodexのドキュメントはもっと直接的で、「エージェントがコードベースについて誤った前提を置いたら、修正が残るようにエージェント自身にAGENTS.mdを更新させること。これをフィードバックループとして扱うこと」。Claude Codeのauto memoryはデフォルトで有効になっていて、ビルドコマンドやデバッグで分かったことを、Claude自身が「将来の会話で役に立つか」を判断して書き溜めます。
つまり、フィードバックループのために仕組みを自作する必要は薄れてきています（長期の保守や自社プロダクトであれば依然やりたいですが）。時間が取れないなら、AIが同じミスをしたときにその場で「これをルールに追記して」と頼む（標準スラッシュコマンドにルール追加があるのでそれを使う）、自動でメモを溜める仕組みだけ置いておく。だけで十分に効果を発揮できます。
まとめると
・フィードバックループの本格的な仕組み作りは受託開発の性質上現実的ではない
・作業のついでにフィードバックをして育てる意識だけ持てば、最低限のミス対策になる
ということになります。
参考：https://cursor.com/ja/docs/rules
参考：https://developers.openai.com/codex/guides/agents-md
参考：https://code.claude.com/docs/en/claude-md
補足2：用語の多さについての見解
この分野はツールも用語も次々に増えていて、追いかけるだけでも大変です。たとえば前述の評価まわりだと、最近は「ハーネスエンジニアリング」や「ループエンジニアリング」といった言葉も見かけるようになりました。重要な用語でいえばある程度絞れますが、それでも従来の開発では聞き馴染みがない言葉が次々と登場する印象はあると思います。
参考：https://lilianweng.github.io/posts/2026-07-04-harness/
ただ、実際に必要なのは概念のほうで、周辺知識がなくても十分に使えると思っています。この記事の文脈で言えば、「AIに考えさせる部分と、スクリプトで固める部分を決める」「人間が評価して、その結果をAIに教えていく」という基本戦略を押さえていれば足ります。
細かい仕様はそれこそAIに聞けば分かることが多いです。概念だけ押さえて、あとは触りながら慣れていくのがいいと思います。
そして評価については、AIが主流になる前から積み上げてきた知識や経験がそのまま活きます。テストの観点を立てる、レビューで何を見るか決める、受け入れ条件を先に握る等。これまでの積み重ねが効く分野だと考えています（個人的にはここにビハインドがあるので、工夫して追い付いていきたいところです）
おわりに
あれこれ書きましたが、正直なところ、私もここに書いたことをやりきれてはいないので、自分自身も意識していきたいと思います。
フィードバック（ループ）関連は組織的な仕組み作りも絡むため、チームを挙げて取り組んでいきたいと考えています。
