この記事は Quickエンジニア Advent Calendar 2025 21日目の記事です！
クイックのエンジニアリングマネージャー桃原（@gozaing）です。
ぶっちゃけ、2025年のAI情報、多すぎやしませんか……！？
どの部署からもひっきりなしに相談がよせられて、
EMのみなさんは毎日パンク寸前だと思うんです。
「まずはデータ整備も必要です！！」と思いつつ、事業やサービスは待ってくれない。
そんな状況で本質を見失うと、判断を間違えてしまいます。
2025年に盛り上がったAI AgentやMCP、AI-DLC。
これらがテストを通した開発サイクルと組み合わさることで、エンジニアリングがどう変わるのか。
バラバラに理解していても見えてこないので、理解のために整理してみました。
この記事は誰のためのものか
この文章は、次のような人に向けて書いています。
- AI Agent / MCP / AI-DLC について単体では理解したつもり
- だが、それらの違いを設計として説明できない
- AI Agent / TDD / 開発サイクルの変化を予測できていない
- AIツール導入について 意思決定・予算・責任を持つ立場
- 正直、全部を腰を据えて調べる時間はない
つまり、 2025年12月の私（EM） です。
私自身がその立場で、
- これらが単体で動くのではなく、合わさった動きになると何が変わるのか？
- そして、それは管理可能なのか？
- 何を判断すべきか？
を理解する必要がありました。
この記事は、私が知りたかったことを、FizzBuzzの実装を通して整理したものです。
「時間がない」という方は、ブクマして年末年始にお楽しみください！
おまけパートにFizzBuzzのリポジトリツリーを載せています（続編込み）。
結論を先に：AI Agentは「制御された試行錯誤ループを担う」のみ
※本記事では、AI Agentの構造を直感的に理解するため、 「FizzBuzzの自動修正」 という最小のタスクを例に説明します。実際の業務ではこれが「バグ修正」や「リファクタリング」に置き換わりますが、本質的な構造は同じです。
- テストを実行する
- 失敗を観測する
- 修正案（diff）を生成する
- 適用して再実行する
最小構成はシンプル。
制御された試行錯誤ループ
それ以上でも、それ以下でもない。
この理解ができるかどうかで、
AI Agent を 買うべきか／作るべきか／使うべきでないか
の判断が変わります。
全体像（まずここだけ掴んでください）
開発者（人間 / CI）
│
▼
Agent（司令塔）
├─ テストを実行する
├─ 失敗ログを見る
├─ LLMに「修正案」を考えさせる
└─ diffを適用する
│
▼
MCP Server（手足）
├─ ファイルを読む
├─ ファイルを書く
└─ テストを実行する
- 考える： LLM
- 動かす： MCP
- 回す： Agent
- 判定する： テスト
これだけです。
AI Agentとは何か
AI Agent = LLM + ループ制御 + 実行制限
人格ではありません、自律的存在でもありません。
（2025/12だからそう言ってますが、、、、明日にも変わりますし、たぶん変わってます）
「失敗を前提に、閉じた範囲で試行錯誤させる設計」
それが AI Agent です。
FizzBuzzの実装で言えば、「テストが落ちた」という失敗をトリガーに、
合格するまでコードを書き直させる 「自律的なリトライの仕組み」 を指します。
TDDは何が変わったのか
2025年の文脈では、
- AIがテストを生成し、動作を保証する（ガードレール）
- 人間は「何を解決すべきか」という仕様と意図に集中する
- 不安が解消され、開発スピードと品質が両立する
TDDは、AIを制御するための契約 です。
AIは失敗しても責任を取りません。
だからこそ、テストが最終判断者になります。
開発者がデータやドメインを理解しないといけない本質がここにあります。
MCPとは何か（APIサーバとの違い）
APIサーバは、
- 信頼されたクライアント
- 認証・認可
- 想定外は例外
という前提で作られています。
LLMは違います。
- 指示を誤解する
- フォーマットを壊す
- 想定外の操作を提案する
つまり、LLMは「信用できないクライアント」。
MCPの役割
AI Agentができることを、実行環境側で物理的に制限する。
- 書けるディレクトリは限定
- 実行できるコマンドは限定
- LLMが何を言っても、できないことはできない
MCPは 手足 であり、判断は一切しません。
Agentが司令塔で、LLMが脳とした場合の比喩です。
「どのファイルを直すか」は誰が決めるのか？
ここが一番誤解されやすく、説明が曖昧になりやすいポイントです。
- MCPが決める → ❌
- MCPは言われたことしかやらない
決めるのは AI Agent です。
AI Agentの実際の流れはこうです。
- テスト失敗ログを見る
- 関係ありそうなファイルを読む
- その内容をLLMに渡す
- diffを生成させる
MCPは一切、推論しない
MCPにLLMを入れない理由
理由は明確で、
- 推論と実行を混ぜると責任境界が壊れる
- セキュリティ監査ができなくなる
- モデル差し替えが困難になる
判断（LLM）と実行（MCP）は分離する
これは技術選択ではなく、AIを用いた設計や開発サイクルの話です。
開発サイクルの話が出てくると、じゃあ「AI-DLCとの違いは？」となりますね。
AI-DLCとの違い
AI-DLC（AI Development Life Cycle）1は、
- データ
- モデル
- 精度
- 再学習
- MLOps
を扱います。
一方、この記事で扱っているのは、
「AI Agentをどう働かせ、どう管理するか」
比較すると
| 観点 | AI-DLC | MCP × TDD × AI Agent |
|---|---|---|
| 主対象 | モデル | 振る舞い |
| 中心課題 | 精度 | 権限・責任 |
| フェーズ | 開発〜運用 | 実行時 |
| 判断主体 | 指標 | テスト |
AI-DLCでは語られないこと
- 実行権限の制御
- 失敗前提の設計
- 責任境界の明示
これらは モデルの性能が良くなっても解決しません。
設計でしか解決できない問題 です。
EM が考えるべき問い
AI Agent 導入検討や推進する際に、以下を考える必要があります。
- AIに どこまでの権限を与えるか？
- 失敗は どこで止まるか？
- 正しさは 何で判定するか？
- 人は どこで介入するか？
これに答えられないAIツールやAI Agentは、
導入・推進目的を見極める必要がある となります。
導入前に考え、判断するのは難しすぎますね。
だからこそ、本質を理解しておかなければいけないジレンマがあります。
まとめ
- AI Agentは「制御された試行錯誤ループを担う」のみ
- MCPはAIの手足を縛る仕組み
- TDDはAI制御の契約
- AI-DLCは上位だが、実行設計は扱わない
AI Agentを、 「LLMを使って“責任を持って自動化する”ためのソフトウェア設計パターン」 として理解すること。
AI Agentが「なんとなくいい感じにやってくれる」という曖昧な期待を捨て、
ドメインを熟知した人間がTDD（テスト）を用いてAI Agentを縛る。
精度の向上をモデルベンダー任せにするのではなく、
- どう権限を絞り
- どこで失敗をリトライさせ
- どこで人がレビューするのか
という「エンジニアリング組織全体での設計力」で品質を担保し、事業成長を加速させる。
これこそが、これからのエンジニアリングマネージャーの意思決定範囲となっていくと考えます。
これが、2025年中に理解しておくべき結論です。
最後に
大前提として、 AI Agentを身近なものにして試してみること が重要です。
使っているからこそ、課題への解像度が高まることは言うまでもありません。
EMには、組織に対して「その学習や試行の時間へ投資するための説明責任」があります。
そのためには、やはり時間を取って本質を理解するしかありません。
本記事が、皆さんの理解の一助となれば幸いです。
おまけ
コード全文は長くなるため、次回の記事でコピペ実行できる形で公開します。
まずは今回の話を責務に落とすと以下になります。
リポジトリツリーも記載したので、次回の記事をお楽しみに！！
- MCP Server（Python）：read/write/run だけを提供する“手足”。推論しない。
- Agent（PHP）：テスト→失敗観測→diff生成依頼→適用→再実行のループ制御
- TDD：正しさの契約。成功/失敗の唯一の基準
- LLM：本来はdiffを生成する“脳”。
- サンプルでは理解優先でダミーdiffを返す
- 他モデルに差し替え可能（OpenAIなど）
ここまで整理できれば、AI Agent / MCP / TDD が
責任分離されたソフトウェア設計として扱えるようになると思います。
リポジトリツリー（完成形）
続編で公開するサンプルコードは、最終的に次のような構成になります。
GitHub Codespacesを利用するので、1クリックで環境構築できます。
FizzBuzzで説明するのは、「誰が、どこで、何を判断しているか」がシンプルに説明できるため。
repo-fizzbuzz-agent/
├─ .devcontainer/
│ ├─ devcontainer.json
│ ├─ Dockerfile
│ └─ postCreateCommand.sh
├─ repo/ # “直される側”の最小PHPプロジェクト（FizzBuzz + PHPUnit）
│ ├─ composer.json
│ ├─ src/FizzBuzz.php
│ └─ tests/FizzBuzzTest.php
├─ mcp-server/ # MCP Server（Python）：read/write/run のみ提供
│ └─ server.py
├─ agent-php/ # Agent（PHP）：ループ制御 + diff適用
│ ├─ composer.json
│ ├─ phpunit.xml
│ ├─ bin/agent # 実行エントリポイント
│ ├─ src/
│ │ ├─ Agent.php
│ │ ├─ PatchApply.php
│ │ ├─ Util.php
│ │ └─ Mcp/
│ │ ├─ McpTransport.php
│ │ ├─ RepoTools.php
│ │ ├─ RepoToolsViaMcp.php
│ │ └─ StdioMcpClient.php
│ └─ tests/
│ └─ PatchApplyTest.php
└─ README.md