AI Coding Loop Engineering入門：Plan・Implement・Test・ReviewをAgent任せにしすぎない設計

3行まとめ

設計する

Plan、Implement、Test、Reviewの流れを先に決めます。

止める

危険な操作は人間承認やCIで止めます。

残す

テスト結果、未実行理由、リスクをPRに残します。

Agentの性能差だけでなく、失敗時に戻れる運用を作ることが重要です。

• AIコーディングをチームで使うなら、Agentの賢さだけでなく、Plan、Implement、Test、Reviewをどう回すかを先に設計した方が安定します。
• この記事では、どこをAgentに任せるか、どこで人間承認やCIを入れるか、どの証跡をPRやartifactに残すかを、実務の運用ルールとして整理します。
• 2026年6月13日時点では、X/Twitter上の周辺AI開発アカウントでagent比較やloop engineeringへの関心が見えましたが、本文の根拠はOpenAI、Anthropic、GitHub、Playwright、Vitestなどの一次情報に限定しています。

この記事は「どのAIコーディングツールが一番強いか」を決める記事ではありません。すでにCodex、Claude Code、GitHub Copilot、Cursor系のAgentを試しているチームが、日々の開発ループにどう組み込むかを考えるための記事です。

この記事でわかること

Plan

Goal、Scope、Done、Not Doneを固定します。

Implement

sandbox、permissions、MCP、外部APIの扱いを分けます。

Test

実行コマンド、CI、reporter、artifactで証跡を残します。

Review

AIレビュー、人間レビュー、CODEOWNERS、セキュリティ確認を分担します。

どのツールを使うかより、どこで止まり何を残すかを先に決めます。

• AI Coding Loop Engineeringを、Plan、Implement、Test、Reviewの4工程で考える理由
• PlanでAgentに渡す前に固定するGoal、Scope、Done、Not Doneの書き方
• Implementでsandbox、permissions、MCP、外部APIをどう扱うか
• Testで「実行した」と言える証跡を、CI、reporter、artifactに残す方法
• ReviewでAIレビュー、人間レビュー、CODEOWNERS、セキュリティ確認を混ぜない考え方
• 小さなbugfix、依存更新、feature追加、DB migrationなどで委任範囲を変える基準

AIコーディングの話は、つい「どのAgentが速いか」「どのモデルが賢いか」に寄りがちです。もちろん性能差はあります。ただ、チーム導入で問題になるのは、賢いAgentが一度うまく直せたことよりも、失敗したときに誰が止め、何を見て、どう戻すかです。

このブログでは以前、AIコーディングツールを同一条件で測る<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-benchmark-kit-bugfix-feature-test-repair/">AI Coding Benchmark Kit</a>を扱いました。今回は測定キットではなく、日々の開発作業を回すための運用ループに絞ります。

前提知識

項目	内容	見方
Plan		影響範囲や候補案はAgentに出させ、Goalや危険領域は人間が承認します。
Implement		小さな修正は任せやすく、secrets、外部API、DB、課金、認証は止めます。
Test		失敗ログ要約は任せつつ、CI statusとartifact保存を確認します。
Review		差分整理はAIが助け、仕様判断やrelease判断は人間が担います。

Loop Engineeringは、作業を任せる範囲と止める範囲を工程ごとに分ける考え方です。

ここでいうLoop Engineeringは、特定ベンダーの正式機能名ではなく、AIコーディング作業を反復可能な運用単位へ分ける考え方として使います。中心に置くのは、次の4工程です。

工程	Agentに任せやすいこと	人間やCIで止めたいこと
Plan	影響範囲の洗い出し、候補案、テスト候補	Goal、Scope、Done、危険領域の承認
Implement	小さな修正、限定された差分、既存パターンへの追従	secrets、外部API、DB、課金、認証の変更
Test	ローカルテスト実行、失敗ログ要約、再実行	CI status、artifact保存、未実行項目の明記
Review	差分整理、見落とし候補、PR本文の補助	仕様判断、リリース判断、セキュリティ例外

OpenAI Codexはsandboxとapproval policyで、ファイルアクセス、ネットワーク、承認を分けて扱う設計を説明しています。Claude Codeはpermissionsでallow、ask、denyのルールを扱い、hooksではコマンド実行に関する注意も明記しています。GitHub Copilotもrepository instructionsやAGENTS.mdに対応するため、リポジトリ内の指示ファイルを運用ルールとして扱う流れが強くなっています。

つまり、AIコーディングAgentを使う側にも「どこまで動かしてよいか」を設計する責任があります。プロンプトを丁寧に書くだけでは足りません。

AI Coding Loop Engineeringとは何を設計する考え方か

1. 1任せる

   Agentが自走してよいタスク、ファイル範囲、コマンドを決めます。

2. 2止める

   人間承認、CI必須、denyする操作を明確にします。

3. 3残す

   差分、テスト結果、未実行理由、リスクを見返せる形にします。

4. 4見直す

   失敗した作業を、次のPlanや権限設計へ戻します。

うまくいった記憶ではなく、再現できる判断材料を残すことが導入判断につながります。

AI Coding Loop Engineeringは、Agentの作業を「依頼して終わり」にしないための設計です。Agentが動ける範囲、止まる条件、残す証跡を、Plan、Implement、Test、Reviewの流れに沿って決めます。

ツール比較ではなく、作業の流れを設計する

Codex、Claude Code、Copilot、Cursorのどれを使うかは重要です。ただし、チーム運用ではツール差より先に決めることがあります。

• どのタスクならAgentが自走してよいか
• どの操作は必ず人間承認に戻すか
• どのテストを通したら「完了」と言えるか
• 失敗したとき、ログと差分をどこで見られるか
• PR本文に何を残すか

ここが曖昧なままAgentを増やすと、うまくいった作業だけが記憶に残り、失敗した作業は「AIが悪い」「指示が悪い」で終わります。導入判断に使える材料が残りません。

「任せる」「止める」「残す」で見る

各工程は、次の3つに分けると設計しやすくなります。

観点	例
任せる	既存コードの読み取り、限定された修正、テスト候補の提案、失敗ログ要約
止める	workspace外編集、ネットワーク利用、DB migration、secrets参照、課金や認証まわりの変更
残す	Plan、実行コマンド、テスト結果、未実行理由、承認ログ、PRのリスク欄

速さだけを見ると、承認やログ保存は遠回りに見えます。けれども、AIが入る開発では「あとで追えること」が速度になります。失敗ログ、artifact、PR本文が残っていれば、次の再依頼や人間レビューが短くなります。

PlanでAgentに渡す前に固定するもの

Goal

何を達成したいのかを短く書きます。

Scope

触る範囲と触らない範囲を分けます。

Done

完了と判断する条件を先に置きます。

Not Done

今回やらないことを明記して広がりを止めます。

Plan承認を残すと、実装レビューで仕様の手戻りを吸収しすぎずに済みます。

PlanはAgentに「考えさせる」工程ですが、すべてをAgentに決めさせる工程ではありません。人間が先にGoal、Scope、Done、Not Doneを固定し、Agentにはその中で調査や候補出しをさせます。

GoalとDoneを短く固定する

悪いPlan依頼は、だいたい広すぎます。

この画面をいい感じに直して。

この依頼では、UIの見た目、アクセシビリティ、テスト、文言、コンポーネント分割、既存仕様のどれを優先するのかが分かりません。Reviewで差し戻すときも「いい感じではない」以上の説明が難しくなります。

確認項目

最初の依頼は、次の程度まで絞ります。

Goal:
Checkout画面の配送先フォームで、郵便番号のバリデーションエラーを表示する。

Scope:
src/features/checkout 以下のフォームとテストだけを変更する。

Done:
- 空の郵便番号で送信するとエラーが表示される
- 既存の注文送信テストは通る
- 追加したテスト名と実行コマンドをPR本文に残す

Not Done:
- 決済API、DB schema、配送先保存処理は変更しない

この形なら、AgentがPlanを作ったあと、人間は「やってよい範囲に収まっているか」を見られます。

Plan承認を人間の仕事として残す

小さなbugfixでは、Plan承認は軽くてよい場合があります。たとえば、再現テストがあり、変更対象が1ファイルに限られ、rollbackも簡単な修正です。

承認を厚くする条件

一方で、次の領域はPlan承認を厚くします。

• DB migration
• 認証、認可、セッション管理
• 課金、請求、契約状態
• secrets、API key、token
• 外部APIの書き込み
• 本番データに影響するバッチ
• 依存関係の大きな更新

Agentが出したPlanに、変更対象、想定リスク、テスト方法、戻し方が入っていなければ、Implementへ進めない方がよいです。これはAIへの不信ではなく、普通の開発プロセスです。

リポジトリ指示を作業ごとのプロンプトで上書きしない

チーム運用では、毎回のプロンプトより、リポジトリ内の指示ファイルが大事になります。

• AGENTS.md
• .github/copilot-instructions.md
• .github/instructions/*.instructions.md
• CLAUDE.md
• ツール固有のsettingsやpermissions

GitHub Copilotのrepository instructionsは、リポジトリ全体、path-specific、agent instructionsなどの分け方を公式Docsで説明しています。CodexにもAGENTS.mdのガイドがあります。

注意点

ここが矛盾すると、Agentの性能比較ではなく、運用の不整合になります。たとえば、AGENTS.mdでは「外部通信は禁止」と書き、個別プロンプトで「必要ならAPIを叩いて」と書いてしまう状態です。Planの前に、指示ファイルの優先順位と禁止事項をそろえておきます。

Implementでsandbox、permissions、MCPを柵にする

項目	内容	見方
workspace内の読み取り		許可しやすい操作として扱います。
workspace内の小さな編集		タスク種別と差分範囲に応じて許可します。
package install		承認または専用ブランチで扱います。
network access		allowlistまたは承認を前提にします。
secrets参照		原則禁止として、必要性とログの残り方を確認します。
destructive command		denyまたは明示承認に寄せます。

広い権限を使う場合は、理由と影響範囲を作業ログやPRに残します。

ImplementはAgentが一番力を出しやすい工程です。同時に、事故も起きやすい工程です。ファイル編集、コマンド実行、ネットワーク、MCP、外部API、secret参照を同じ扱いにしないことが出発点になります。

ファイル編集とコマンド実行を同じ扱いにしない

OpenAI Codexの公式Docsでは、sandbox modeとapproval policyが別の層として説明されています。sandboxは技術的に何ができるか、approval policyはどの行為で承認を求めるかに関わります。

初期方針

チーム運用では、次のように分けます。

操作	初期方針
workspace内の読み取り	許可しやすい
workspace内の小さな編集	タスク種別に応じて許可
workspace外の編集	原則承認
package install	承認または専用ブランチ
network access	allowlistまたは承認
secrets参照	原則禁止
destructive command	denyまたは明示承認

注意点

danger-full-accessのような広い権限は、検証や一時的な作業では必要になることがあります。ただ、チーム標準として常用するものではありません。強い権限を使った場合は、その理由をPRや作業ログに残します。

MCPと外部APIはallowlistから始める

MCPは便利です。GitHub、ドキュメント検索、ブラウザ検証、社内ツールなどにつなげると、Agentの作業範囲は広がります。

ただし、作業範囲が広がるほど、Reviewで見るべきものも増えます。導入の順番は、read-onlyから始めるのが現実的です。

段階導入の条件

段階	例	注意点
1	ローカルworkspaceだけ	まず差分とテストを安定させる
2	GitHub read-only	issue、PR、diffの読み取りに限定する
3	公式Docs検索	参照元URLを残す
4	ブラウザ検証	操作対象と証跡を残す
5	外部API書き込み	人間承認、監査ログ、rollbackを必須にする

MCPのTools、Resources、Promptsの基本は、公開済みの<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か</a>でも整理しています。Loop Engineeringでは、MCPを「何でもできる拡張」ではなく、工程ごとの権限境界として扱います。

hooksやpermissionsは最後の安全装置ではない

Claude Codeのpermissionsはallow、ask、denyを使ってツール実行を制御できます。hooksは強力ですが、公式Docsではコマンドhookがユーザー権限で動くことも注意されています。

hooksやpermissionsは、入れれば安全になる魔法ではありません。むしろ、チームの作業ルールを実行時にも反映するための仕組みです。

下振れ条件

たとえば、PreToolUseで危険なコマンドを止める、PostToolUseでテスト実行を促す、StopでPRサマリーの不足を検出する、といった使い方が考えられます。ただし、hookが壊れている、ログを誰も見ていない、失敗してもPRが進む、という状態では安全装置として機能しません。

Testで「実行した」を判断できる証跡にする

1. 1コマンド

   lint、typecheck、unit、E2Eなど実行したコマンドを書きます。

2. 2結果

   通過、失敗、スキップを分けて残します。

3. 3未実行

   実行できなかった理由と残るリスクを書きます。

4. 4artifact

   junit.xml、Playwright report、job summaryなどを保存します。

Reviewで必要なのは「テストしました」という言葉ではなく、再確認できる証跡です。

AIコーディングで一番もめやすい言葉が「テストしました」です。何を、どの環境で、どのコマンドで、どこまで実行したのかが分からなければ、Reviewの材料になりません。

Agentの自己申告ではなく、再実行できるコマンドで見る

最低限残す項目

最終報告には、最低限これを残します。

Tests run:
- npm run lint
- npm run typecheck
- npm test -- --run

Not run:
- Playwright E2E: ローカルにブラウザ依存が未導入のため未実行

Artifacts:
- CI job summary
- test-results/junit.xml
- playwright-report/

未実行の項目があること自体は悪ではありません。問題は、未実行なのに実行したように読めることです。Agentにも、人間にも、Not runを書かせる運用にします。

PlaywrightやVitestのreporterをCIで読める形にする

PlaywrightはJSONやJUnit reporterを公式Docsで案内しています。VitestもreporterとoutputFileの指定を扱っています。

レポートの分け方

人間が読むものと、CIや集計が読むものは分けます。

用途	例
人間が読む	HTML report、PR summary、スクリーンショット
CIが読む	JUnit XML、JSON report、exit code
後から調査する	trace、coverage、console log、artifact

UI変更ならPlaywrightのtraceやスクリーンショットが役立ちます。ユニットテスト中心ならVitestのJSONやJUnit出力が扱いやすいです。どれを採用するかより、PRから追える場所に残すことが大事です。

GitHub Actions artifactで失敗時の材料を残す

GitHub Actionsでは、actions/upload-artifactを使ってbuildやtestの出力を保存できます。公式Docsでは、artifact名、path、retention-daysなどの指定例が案内されています。

AIコーディング作業では、成功時より失敗時のartifactが効きます。

保存すべき材料

• 失敗したテストのログ
• Playwright report
• trace
• screenshot
• coverage
• lint結果
• 生成されたPR summary

これらが残っていれば、人間レビューは「どこで落ちたか」から始められます。残っていなければ、Agentへの再依頼も人間の調査も最初からやり直しです。

ReviewでAIレビューと人間レビューを混ぜない

項目	内容	見方
AIレビュー		差分要約、変更範囲、テスト漏れ、エラーハンドリング漏れを確認します。
PR本文		Summary、Tests run、Not run、Risksをそろえます。
人間レビュー		仕様の正しさ、ユーザー影響、release判断、rollback可能性を見ます。
CODEOWNERS		危険領域や専門領域の確認先を自動で呼びます。

AIの指摘を承認印にせず、人間が見るべき判断を残します。

Review工程では、AIレビューを入れること自体より、AIレビューに何を任せないかが重要です。

AIレビューは差分整理と見落とし検知に寄せる

AIレビューが得意な場面はあります。

AIに寄せる項目

• 差分の要約
• 変更範囲の棚卸し
• テスト漏れ候補
• エラーハンドリング漏れ候補
• 命名や重複の指摘
• PR本文の不足検出

人間が見る項目

一方で、次の判断は人間に残します。

• 仕様として正しいか
• ユーザー影響を許容できるか
• セキュリティ例外を認めるか
• releaseしてよいか
• rollback可能か
• 料金や利用規約に影響しないか

AIレビューのコメント数を品質指標にしない方がよいです。コメントが多くても重要でない場合がありますし、コメントが少なくても危険な差分を見逃している場合があります。

PR本文にSummary、Tests run、Not run、Risksを残す

AIが作ったPRほど、本文を薄くしない方がよいです。差分だけでは、Agentが何を確認し、何を確認していないかが分かりません。

確認項目

PR本文は、最低限この形にします。

Summary:
- Checkoutフォームの郵便番号バリデーションを追加
- 既存の注文送信処理には触れていない

Tests run:
- npm run typecheck
- npm test -- checkout

Not run:
- Playwright E2Eは未実行。UI文言のみの変更ではなく、次PRで追加予定。

Risks:
- 既存ユーザーの保存済み住所に空文字がある場合、送信前にエラーが出る可能性

この考え方は、公開済みの<a href="https://ai-dev.blog.mo-gmo.com/ai-agent-pr-template-summary-tests-risks-not-run/">AIエージェントPRテンプレート</a>の記事でも扱っています。

人間レビューは最後の承認印ではない

人間レビューを最後の押印にすると、Planが薄いPRほど揉めます。差分が大きい、テストが足りない、なぜその実装にしたか分からない。こうなると、Reviewで設計からやり直すことになります。

Loop Engineeringでは、ReviewからPlanへ戻れるようにします。

• Planが曖昧ならImplementに戻さず、Planを直す
• Testが薄いなら追加実装ではなく証跡を足す
• Riskが大きいならrelease判断へ進めない
• 権限が広すぎたら次回のpermissionsやAGENTS.mdへ反映する

Reviewは「このPRを通すか」だけでなく、「次のLoopをどう短くするか」を決める工程です。

どこまで任せるかをタスク種別で変える

項目	内容	見方
小さなbugfix		再現テスト、限定差分、既存パターン修正は任せやすい領域です。
UI調整		CSSや文言修正は進めやすく、仕様変更や画面崩れで止めます。
依存更新		changelog確認やlockfile更新は任せつつ、major updateで承認を厚くします。
Feature追加		受け入れ条件内に絞り、Scope外のリファクタで止めます。
DB・認証・課金		自動完了にせず、設計、migration、rollback、監査を人間が見ます。

任せやすい作業ほど自走範囲を広げ、影響が大きい作業ほどPlan承認を厚くします。

すべてのタスクを同じ権限でAgentに渡すと、うまくいく作業と危ない作業が混ざります。タスク種別ごとに委任範囲を変えます。

委任範囲の目安

タスク種別	任せやすい範囲	止める条件
小さなbugfix	再現テスト、限定差分、既存パターン修正	影響範囲が広がる、外部APIに触る
UI調整	CSS、文言、アクセシビリティ修正	意味のある仕様変更、未確認の画面崩れ
依存更新	changelog確認、lockfile更新、テスト	major update、build設定変更
Feature追加	受け入れ条件内の実装	Scope外のリファクタ、DB変更
DB migration	migration案、rollback案の作成	自動適用、本番データ変更
認証、課金、secret	調査、影響範囲整理	自動修正、自動デプロイ

小さなbugfixとUI調整は自走範囲を広げやすい

再現手順があり、失敗テストがあり、変更範囲が狭い作業はAgentに向いています。UI調整も、スクリーンショットやPlaywrightの確認を残せるなら進めやすい領域です。

ただし「見た目だけ」の作業でも、フォーム文言、accessible name、validation、analytics eventが変わることがあります。UI変更を軽く見すぎないようにします。

依存更新とfeature追加はPlan承認を厚くする

依存更新は、package.jsonとlockfileだけを見て終わりにしない方がよいです。changelog、breaking change、transitive dependency、build設定、型定義、CI差分を見ます。

Feature追加も同じです。受け入れ条件が薄いままAgentに渡すと、実装は速く進みますが、Reviewで仕様の話に戻ります。Plan承認で、やることとやらないことを分けます。

DB、認証、課金、secretは自動完了にしない

DB migration、認証、課金、secret、外部API書き込みは、Agentに調査やPlanを頼む価値があります。ただし、自動完了には向きません。

自動完了にしない条件

最低限、次の条件を満たしてから進めます。

• 人間がPlanを承認している
• stagingで確認できる
• rollback手順がある
• 監査ログが残る
• secretsをログに出していない
• CIと手動確認の両方が分かる

Agentが賢いほど、危険な作業も自然に進められてしまいます。だから、止める線を先に決めます。

小さく始める導入手順

1. 1週目

   PlanテンプレートとPRテンプレートを用意します。

2. 次の段階

   permissions、hooks、artifact保存を足します。

3. 安定後

   GitHub read-only、Docs検索、ブラウザ検証、外部APIを順に広げます。

4. 測定段階

   Benchmark Kitでタスク別の成功率や手戻りを比べます。

最初から全部を自動化せず、失敗時の原因が見える順番で広げます。

Loop Engineeringは、大きな基盤を作ってから始めるものではありません。最初はPlanテンプレートとPRテンプレートだけで十分です。

最初の1週間はPlanテンプレートとPRテンプレートだけで始める

1週目に見るのは、次の5つです。

確認項目

• 既存のAGENTS.mdやリポジトリ指示はあるか
• PRテンプレートにTests run、Not run、Risks欄があるか
• CI status checkは必須になっているか
• Agentに許可するコマンドと禁止するコマンドが決まっているか
• 危険領域のタスクを自動完了にしていないか

既存のリポジトリ指示を整えるなら、<a href="https://ai-dev.blog.mo-gmo.com/team-agents-md-template-permissions-tests-review/">チーム向けAGENTS.mdテンプレート</a>が近いです。

次にpermissions、hooks、artifact保存を足す

2週目以降は、実際に差し戻したPRを見ながら、止める条件を増やします。

追加する順番

• workspace外編集で承認を求める
• package installで承認を求める
• secretsに触れそうな操作をdenyにする
• Playwright reportをartifactに保存する
• CI失敗時にjob summaryへログ位置を出す
• PR本文のNot run欄が空なら差し戻す

GitHub Actionsでログやartifactを残す設計は、公開済みの<a href="https://ai-dev.blog.mo-gmo.com/github-actions-ai-agent-logs-job-summary-artifacts-retention/">GitHub ActionsでAIエージェント作業ログを残す記事</a>も参考になります。

測定したくなったらBenchmark Kitへつなぐ

運用ループが整うと、次に「どのAgentがこのタスクに向いているか」を測りたくなります。その段階でBenchmark Kitに進めばよいです。

順番としては、まず運用ループ、次に測定です。逆にすると、権限やログ保存がばらばらのままAgent比較をしてしまい、結果の解釈が難しくなります。

結果

任せる線

Agentが自走してよいタスク種別、ファイル範囲、コマンドを決めます。

止める線

人間承認、CI必須、denyする操作を置きます。

残す線

テスト結果、未実行理由、artifact、リスクを残します。

線を決めておくほど、Agentは動きやすくなり、失敗時にも戻りやすくなります。

この記事での結論は、AIコーディングAgentを導入するなら、ツール選定と同じくらい運用ループを先に決めるべきだ、というものです。

特に効くのは、次の3本線です。

最終チェック

線	決めること	置く場所
任せる線	Agentが自走してよいタスク種別、ファイル範囲、コマンド	Plan、AGENTS.md、repository instructions
止める線	人間承認、CI必須、denyする操作	permissions、hooks、CI status check
残す線	テスト結果、未実行理由、artifact、リスク	PR本文、job summary、artifact

この3本線がないままAgentを強くすると、速く進む作業もありますが、失敗時に戻れなくなります。逆に、線を決めておけば、Agentはより動きやすくなります。毎回人間が細かく監視するのではなく、止まる場所と残す場所を仕組みに置けるからです。

失敗点とハマりどころ

Planが薄い

実装は進んでも、Reviewで仕様判断に戻ります。

指示が矛盾する

AGENTS.md、個別プロンプト、settings、hooksの前提がずれます。

証跡がない

テストした範囲、未実行理由、失敗ログが確認できません。

hooksを過信する

安全保証ではなく、Plan、permissions、Reviewと合わせて使います。

失敗したら、Goal、Scope、Done、権限、証跡のどこが薄かったかに戻します。

Planが薄いままImplementだけ進む

一番よくある失敗は、Planが薄いまま実装だけ速く進むことです。差分は出ます。テストも一部通ります。ただ、Reviewで「そもそもこの仕様でよいのか」に戻ります。

Planが薄いPRは、実装レビューで吸収しようとしない方がよいです。Goal、Scope、Done、Not Doneを足してから、もう一度Loopを回します。

permissionsと指示ファイルが矛盾する

AGENTS.mdでは「外部通信禁止」と書いているのに、個別プロンプトでは「必要ならweb検索して」と書く。Claude Code settingsではaskにしているのに、hook側では別の前提で動く。こうした矛盾は、Agentの失敗に見えますが、実際はチーム運用の問題です。

指示ファイルを変更したら、変更レビューの対象にします。公開済みの<a href="https://ai-dev.blog.mo-gmo.com/agents-md-change-review-instruction-drift-permission-conflict-tests/">AGENTS.md変更レビューの記事</a>でも、この観点を扱っています。

「テストしました」が証跡になっていない

Agentが最終報告で「テストしました」と書いても、コマンド、終了コード、対象範囲、失敗ログ、未実行理由がなければ、Review材料として弱いです。

PR本文には、実行したものと実行していないものを分けます。CI artifactには、あとで人間が見たいものを残します。

hooksを安全保証として扱う

hooksは便利ですが、最後の安全保証ではありません。hook自体が誤設定されることもありますし、ログを見ない運用なら止めても気づけません。

確認項目

hookを入れたら、壊れたときにどう検知するか、誰が直すか、どのPRで設定変更をレビューするかまで決めます。

実務で使うなら

1. 1Planテンプレート

   Goal、Scope、Done、Not Doneを固定します。

2. 2PRテンプレート

   Summary、Tests run、Not run、Risksを残します。

3. 3禁止操作

   secrets参照、destructive command、承認なし外部APIを止めます。

4. 4artifact保存

   test-results、playwright-report、coverage、job summaryを残します。

新しい基盤より先に、作業の入口と出口をそろえると定着しやすくなります。

最初に作るのは、大げさなAgent基盤ではなく、次の4つです。

1. Planテンプレート

Goal:

Scope:

Done:

Not Done:

Allowed commands:

Approval required:

Artifacts to keep:

このテンプレートをIssue、PR、Agent依頼文のどこかに置きます。

2. PRテンプレート

Summary:

Tests run:

Not run:

Risks:

Rollback:

Agentが作ったPRでも、人間が作ったPRでも同じ形にします。形式が同じなら、Reviewの観点もそろいます。

3. permissionsと禁止操作の初期ルール

最初から完璧なdeny listを作ろうとしない方がよいです。まずは、危険領域を明示します。

最初にdenyへ寄せる操作

• workspace外編集
• secrets参照
• 本番DB
• 課金、認証、権限まわり
• 外部API書き込み
• destructive command
• npm audit fix --forceのような広範囲変更

4. artifact保存の最小セット

CIで保存するものを決めます。

保存対象

• test report
• lint/typecheck log
• Playwright traceやscreenshot
• coverage
• run summary
• PR本文

保存しないものも決めます。.env、secret、個人情報、本番データ、社内固有の非公開ログは、artifactに入れない方針を明記します。

セキュリティ・コスト注意

権限

read-only、限定write、承認付きwriteの順に広げます。

コスト

モデル料金だけでなく、CI時間、artifact保存量、Review時間も見ます。

ログ

社内コード、秘密情報、認証情報を不用意に残さないようにします。

切り戻し

失敗時に戻せる範囲で権限と自動化を広げます。

セキュリティとコストは単純な勝敗ではなく、扱う情報と影響範囲で条件が変わります。

Agentの権限は便利さと同時に広がる

AgentにMCP、ブラウザ、GitHub、外部API、package installを許可すると、できることは増えます。同時に、漏れる情報、壊せる範囲、レビューすべきログも増えます。

まずread-only、次に限定write、最後に承認付きwriteの順に広げます。最初から広い権限を渡して、あとから制限する運用は難しいです。

コストはモデル料金だけではない

AIコーディングのコストは、サブスクリプションやAPI料金だけではありません。

• 再試行回数
• CI実行時間
• artifact保存量
• Review時間
• hooksやpermissionsの保守
• 失敗時の切り戻し

Loop Engineeringの目的は、Agentを遅くすることではありません。無駄な再試行とレビュー迷子を減らすことです。

社内コードや秘密情報をログに残さない

Agent作業では、ログ保存が重要です。ただし、何でも保存すればよいわけではありません。

保存対象外を先に決めます。

• API key
• access token
• .env
• 顧客情報
• 本番DB dump
• 非公開の取引情報
• 社内だけのURLやcredential

ログを残す設計と、ログに残さない設計は同時に必要です。

FAQ

項目	内容	見方
新しいツールか		特定ベンダーの正式機能名ではなく、運用ループとして設計する考え方です。
ツール間で共通化できるか		任せる線、止める線、残す線は共通化し、設定や承認挙動は個別に確認します。
MCPを最初から入れるか		まずローカルworkspaceで安定させ、read-onlyから順に広げます。
Benchmark Kitとの違い		Benchmark Kitは測定、Loop Engineeringは日々の運用設計に寄せます。

共通化するのは判断軸であり、各ツールの具体的な設定は公式情報で確認します。

Loop Engineeringは新しいツールですか？

いいえ。この記事では、AIコーディング作業をPlan、Implement、Test、Reviewの運用ループとして設計する考え方として使っています。特定ベンダーの正式機能名ではありません。

CodexとClaude Codeで同じルールを使えますか？

運用上の判断軸は共通化できます。ただし、sandbox、permissions、hooks、approvalの実装はツールごとに違います。共通化するのは、任せる線、止める線、残す線です。設定ファイルや承認の挙動は、それぞれの公式Docsで確認します。

MCPは最初から入れるべきですか？

最初から入れなくてもよいです。まずローカルworkspaceだけでPlan、差分、Test、Reviewを安定させます。その後、GitHub read-only、Docs検索、ブラウザ検証、外部APIの順に足す方が、失敗時の原因を切り分けやすいです。

Benchmark Kitとは何が違いますか？

Benchmark Kitは、複数Agentを同一条件で測るためのタスク、ログ、採点表の話です。この記事は、日々の開発作業でAgentをどう動かし、止め、証跡を残すかの話です。運用ループが決まったあとにBenchmark Kitへ進むと、比較結果を読みやすくなります。

次に読むなら

このブログの更新通知やAIコーディング運用の検証記事を追いたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>でも新着を案内しています。チーム向けにAGENTS.md、permissions、MCP allowlist、CI artifact、PRテンプレートをまとめて棚卸ししたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/contact/">お問い合わせ</a>から相談できます。

参照した主な情報源

• OpenAI Codex Agent approvals & security: https://developers.openai.com/codex/agent-approvals-security
• OpenAI Codex Sandboxing: https://developers.openai.com/codex/concepts/sandboxing
• OpenAI Codex AGENTS.md guide: https://developers.openai.com/codex/guides/agents-md
• Claude Code permissions: https://code.claude.com/docs/en/permissions
• Claude Code hooks: https://code.claude.com/docs/en/hooks
• GitHub Actions artifacts: https://docs.github.com/en/actions/tutorials/store-and-share-data
• GitHub Copilot repository instructions: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
• Playwright test reporters: https://playwright.dev/docs/test-reporters
• Vitest reporters: https://vitest.dev/guide/reporters
• Terminal-Bench GitHub: https://github.com/harbor-framework/terminal-bench
• OpenAI Evals GitHub: https://github.com/openai/evals

更新履歴

1. 2026-06-13

   初版。需要シグナルは市場関心として扱い、仕様や機能は一次情報で確認しました。

運用ルールはツール仕様の変化に合わせて見直します。

• 2026-06-13: 初版。X/Twitter上の需要シグナルは市場関心としてのみ扱い、仕様や機能の説明は一次情報で確認。Codex、Claude Code、GitHub Copilot、GitHub Actions、Playwright、Vitestの公式情報を参照した。