パイロットがPRを承認する時代、『仕様駆動・ループ・サンドボックス』――エンジニアに残る仕事、増える仕事（2）ループとコンテキスト
1. はじめに――新人に、毎回すべてを口頭で説明しますか？
前回は、開発者の役割が「実装者」から「指揮者」へ移りつつある、という話をしました。
今回は、その指揮者が具体的に何を設計するのか、に踏み込みます。
新人に仕事を頼むとき、毎回すべての手順を口頭で説明するでしょうか。
普通はしません。
ゴールを伝え、マニュアルの場所を教え、困ったら誰に聞けばいいかを決めておく。
あとは本人に試行錯誤してもらいます。
AIエージェントとの付き合い方も、同じ方向に進んでいます。
指揮者が書くのは、一回の指示ではなく「仕組み」だ。
2. ループエンジニアリング――回り続ける仕組みを設計する
人間が毎回プロンプトを打ち込み、一問一答を繰り返す――。
このスタイルは過去のものになりつつあります。
代わりに設計するのが「ループ」です。
ゴールと完了条件をシステムに組み込み、エージェントが「やってみる → 検証する → 直す」を自分で回し続ける。
人間が設計するのは、一回の指示ではなく、この回り続ける仕組みそのものです。
ここで効いてくるのが、前回の仕様駆動開発です。
「何ができたら完成か」が仕様に書かれていなければ、ループは止まりどころを失います。
ループの質は、完了条件の質で決まる。
3. コンテキストエンジニアリング――エージェントの「職場環境」をつくる
もう一つの柱が、エージェントに渡す「文脈」の設計です。
モデルが一度に扱えるコンテキストウィンドウには限りがあります。
その制約の中で、必要な情報を、必要なときに、必要なだけ渡す。
コードベースの外にあるデータやツールにつなぐ標準としては、**MCP（Model Context Protocol）**が広く使われています。
MCPはAnthropicが2024年に公開したプロトコルで、2025年12月にはLinux Foundation傘下に新設されたAgentic AI Foundation（AAIF）へ寄贈されました。いまは特定ベンダーのものではない、中立な標準という位置づけです。
これに加えて、3つを組み合わせることを勧めます。
|
仕組み |
中身 |
人間の職場でいうと |
|---|---|---|
|
スキル（Skills） |
再利用できる手順や知識をまとめたMarkdownファイル。必要なときだけ読み込まれる |
業務マニュアル |
|
自動化（Automations） |
フォーム送信などのイベントやCronの定期実行で、エージェントを起動する仕組み |
定例業務のカレンダー |
|
サブエージェント（Sub-agents） |
ライブラリの仕様確認や障害調査など、個別タスクのために一時的に派遣される専用エージェント |
調査を頼む応援メンバー |
ちなみにスキルも、Anthropicが2025年10月に発表し、同年12月に「Agent Skills」としてオープン標準化したものです。SKILL.mdというファイルを中心にした形式で、いまでは多くのエージェント製品が対応しています。
以前の記事「AIに『手順書』を持たせる魔法のファイル、『AI Agent Skills』」で紹介したものが、まさにこれです。
うまい一言を考える時代から、エージェントが働く「職場環境」を設計する時代へ。
4. AIは「時間」の感覚を持たない
面白い実験があります。
LLMに「三人称視点のRPGを作るには、どのくらいかかりますか？」と聞いてみる。
返ってくる答えは、たいてい「数週間から数か月」です。
ところが、同じモデルを積んだコーディングエージェントに「作って」と頼むと......。
5分ほどで、動くサンプルができあがってしまうことがあるのです。
LLMは、人間の開発工数について書かれた大量の文章から学んでいます。
だから「どのくらいかかるか」と聞かれれば、人間の感覚で答える。
でもモデル自身には、時間も、実行速度も、メモリも、実感として存在しません。
自分の手の速さを知らない職人のようなものです。
ハードウェアの下で何が起きているか
エージェントを本気で使いこなすなら、推論のときにハードウェアで何が起きているかまで押さえておくべきだ、と強調します。
最低限、次の2つは知っておきたいところです。
- モデル重み（Model weights）：LLMのパラメータそのもの。GPUメモリに載せられ、推論のたびに計算資源を使う
- KVキャッシュ（KV cache）：プロンプトを処理し応答を生成する過程で、過去の計算結果を使い回すためにGPU上に作られるキャッシュ
たとえばエージェントループでは、同じシステムプロンプトやコードベースの説明を何度もモデルに渡します。
KVキャッシュがうまく再利用できれば、そのぶん速く、安くなる。
コンテキストを膨らませすぎれば、遅く、高くなる。
つまり、第2章のループも第3章のコンテキストも、最後はこの「中身」の話に行き着くのです。
以前「高いモデルに全部投げていませんか？『LLMルーター』という節約術」で書いたコストの話とも、地続きのテーマです。
モデルの「中身」を知っている人ほど、エージェントを速く、安く、賢く回せる。
5. 明日からできること
- チームの「暗黙のルール」を1つ、スキル化する：コーディング規約やレビュー観点をMarkdownにまとめ、エージェントに読ませる
- 完了条件を「テストが通ること」で定義する：エージェントが自分でループを回せるように、検証の手段を先に用意する
どちらも、30分あれば試せます。
マニュアルと合格基準を渡せば、エージェントは自分で走り出す。
6. 結論：プロの差は「仕組み」と「中身」に出る
前回、指揮者の役割はエンジニアだけのものではなくなりつつある、と書きました。
では、プロのエンジニアの差はどこにつくのか。
今回の答えは、この2つです。
- エージェントが自分で回り続けるためのループとコンテキストを設計できること
- その裏でGPUやKVキャッシュに何が起きているかを理解したうえで、速さとコストを設計できること
ただし、エージェントに多くを任せるほど、新しい危険も生まれます。
次回は、エージェント時代のSQLインジェクションともいえるプロンプトインジェクションと、その守り方を取り上げます。
あなたのチームのエージェントは、どんな「マニュアル」を持たされていますか？