コーディングエージェントを活用して生産性を高めるための主要な実践手法をまとめた『Taming Vibe Coding: エンジニアのためのガイド』を公開してから、半年以上が経過しました。
当時の記事で触れた内容の多くは現在でも十分に通用するものですが、この半年間でエージェントを取り巻く環境は目覚ましく進展しました。そこで、私の考え方がそれ以降どのように進化してきたのか、現状のアップデートを共有したいと思います。
プロンプティングとコンテキストエンジニアリング#
プロンプティングは依然として重要であり、適切に構造化されたプロンプトは作業時間を大幅に節約してくれます。しかし、プランニングシステムの登場により、プロンプティングは以前ほど「成否を分ける唯一の決定打」ではなくなりました。現在の多くのコーディングエージェントにはプラン（またはプランニング）モードが標準搭載されており、コーディングに飛びつく前に数ターンかけてタスクを「ブレインストーミング」し、詳細な実装プランを練り上げます。
これにより、実際にコードが書かれる前にプランをレビューし、エージェントを正しい方向へと誘導できるため、時間とトークンの大幅な節約につながります。一方で変わらないのは、一貫した結果を担保するための明確な受入基準（Acceptance Criteria）の必要性です。これは、私がプランをレビューする際にも最も注意深く見ているポイントです。
コンテキストエンジニアリングは、Agent Skills（エージェントスキル）の普及によって劇的な進化を遂げました。そのおかげで、最近では AGENTS.md（あるいは GEMINI.md や CLAUDE.md など）を細かく書くことをほとんど意識しなくなりました。Antigravity には Rules（ルール）という概念があり、これも本質的にはコンテキスト最適化の仕組みですが、私はスキルを優先して Rules をほとんど使っていません。AGENTS.md や Rules でしか実現できず、他のテクニックで代替できないような要件には、今のところ出会っていません。
なお、セマンティック検索などを活用した検索拡張生成（RAG）に関連するコンテキストエンジニアリングは、専門知識を扱う上で今なお不可欠です。これはメモリシステムの動作原理そのものでもあり、外部ライブラリや依存関係を扱う際には、パッケージドキュメントをコンテキストに動的注入する手法を現在でも多用しています。
Model Context Protocol の台頭と衰退（？）#
Model Context Protocol（MCP）サーバーを立ち上げる代わりに、Agent Skills と CLI ツールを組み合わせて使うアプローチを好む開発者が増えています。そのアプローチも尊重しますが、私自身はエージェントにシェルの直接実行権限を与えることにセキュリティや信頼性の面で不安があるため、ローカルで動かす MCP サーバー（godoctor や speedgrapher など）にツールをパッケージングする手法を好んでいます。以前と変わった点といえば、MCP サーバーの導入に対してかなり慎重になり、大半の場合は自作のカスタムサーバーのみを設定するようになったことです。
また、MCP サーバーを単独で使うことはほとんどなく、「スキル ＋ MCP」を組み合わせて運用しています。スキルが作業プロセスを記述し、MCP がツール群を公開します。これは、MCP のシステム指示（instructions）そのものをチューニングしようとするよりも効果的であることが多いです。かつて私は MCP の指示調整に何百時間も費やしましたが、結局コーディングエージェントにことごとく無視されるという苦い経験をしました。
普段は「MCP ＋ スキル」の組み合わせで十分ですが、極めて重要なタスクには「MCP ＋ スキル ＋ フック（Hooks）」という “スーパーコンボ” を投入します。フックの役割は、エージェントを私が進めたい方向へ強制的に向かわせることです。私はこれを「エージェントをレールに乗せる」、あるいは「エージェントの自律性（agency）をあえて下げる」と呼んでいます。フックシステムを利用することで、望ましくないアクションをブロックし、使わせたいツールを使うようエージェントの「背中をそっと押し（gentle nudge）」、ツールが呼ばれるかどうかの確率的なブレを排除できます。言い換えれば、エージェントに決定論的な振る舞いを強制できるのです。
あらゆるプロセスにスキルを#
私は、再現性を持たせたいプロセスに対してスキルを作成しています。例えば、私が最も頻繁に使っているスキルのいくつかは、テクニカルライティングやレビューに関するものです。私は（このブログを含め）常にコンテンツを執筆しているからです。また、エージェントが自力で扱うのに苦労しそうな技術についてもスキルを記述します。これには通常、登場したばかりの最新技術、ニッチなプロジェクト、あるいは自作ツールなどが含まれます。
一例を挙げると、少し前に A2UI ワークショップの準備をしていたとき、非常に苦労したことがありました。A2UI は、エージェント指向のユーザーインターフェース（Agentic User Interfaces）を開発するための比較的新しいプロトコルです。あまりに新しい概念であり、さらに私独自の指導上の要件があったため、エージェントは手厚い支援と試行錯誤なしには仕様を理解できませんでした。しかし、最初のハードルを一度乗り越えてその知識をスキルとしてパッケージングしたことで、次回以降に同様の作業を行う際、極めてスムーズに進められるようになりました。
一方で課題となるのは、作成したスキルを常に最新の状態に保ち、綺麗に整理し続けるのが難しい点です。この問題を解決することこそが、MCP にとっての「復権の契機（名誉挽回のチャンス）」になるのではないかと考えています。現在、プロトコル仕様にスキルを追加する提案が進められています。残念ながら、それがいつ（あるいは本当に）実現するかについての見通しは立っていませんが、今のところは自分たちでスキルを管理していくしかありません。理論上は、プロンプトを活用した段階的開示（progressive disclosure）とスクリプト実行用のツールを組み合わせることで、MCP 上に「スキル風」の体験を構築することも可能ですが、目下のバックログの多さを考えると、まだ試すには至っていません。
サブエージェントの台頭（そして衰退知らずの躍進）#
サブエージェントは、界隈の誰もがこぞって話題にしている「次のトレンド」です。その中核にあるアイデアは、分離された独立したコンテキストウィンドウを持つエージェントを個別に立ち上げ、タスクを並列化することにあります。これにはコンテキストの最適利用、タスク間の情報汚染の防止、そしてコンテキストの早期劣化・腐敗（context rot）の抑制という大きなメリットがあります。また、各タスクが自己完結するため、コンテキスト圧縮の必要性が減り、メインのコンテキストウィンドウを汚染することもありません。コーディングハーネス側のサポートとしては、スキルと同様に独自のシステムプロンプト、モデル、設定を持つエージェントを事前定義できるものもあれば、Antigravity のようにメインセッションの「クローン」としてアドホックにエージェントを生成し、それぞれに独立したコンテキストウィンドウを割り当てる方式を好むものもあります。
アドホックなエージェント生成では、1つのプロンプトから3つの異なるエージェントを立ち上げて並列処理させるといった自由度の高い操作が可能です。しかし個人的には、Antigravity でもエージェントを事前定義できるようになってほしいと感じています。事前定義ができれば、自分好みに「厳選・調整（curate）した」エージェントをポータブルな形で管理できるからです。また、エージェント間でタスクを並列化することは決して簡単なスキルではありません。この1年でエージェントにタスクを投げることにはすっかり慣れましたが、それらをいかに効率よくオーケストレーションするかについては、まだ深く考えられていませんでした。
多くの意味で、これはプロダクトオーナー（PO）やチームリードがタスクを細分化し、チーム全体でどう取り組むかを検討するときに使う「筋力」と同じです。ただしサブエージェントの場合、固定メンバーのチームではなく、必要なだけ何人でも「チームメンバー」を生み出せます。結局のところ、私が重視しているのは「クールだから」という理由でエージェントを並列化することではなく、「それによって本当により良い成果が出せるのか？」という本質的な問いです。
もしその問いへの答えが No（いいえ） であるなら、1度に1つのエージェントを順次動かしていく方が賢明です。綿密なプランニングに費やす労力や、タスクを慎重に切り分ける認知的負荷（mental toil）に見合わないからです。だからこそ私は、エージェントを事前に定義できるアプローチを好みます。必要なときに特化型として呼び出せれば十分であり、それらが並列で動くかどうかは本質的な問題ではないからです。
フック（Hooks）は最高の相棒#
最後にとっておきのお気に入りを残しておきました。フック（Hooks）です。フックとは、エージェントのライフサイクルにおける特定のイベント発生時にトリガーされるコールバックのことです。先週、フックについて丸ごと1本解説した記事『コーディングエージェントにおけるフックのマスター』を公開しましたので、この記事を読み終えたらぜひ続けてチェックしてみてください。要するに、モデルは本質的に予測不可能であり、いとも簡単に脱線（off the rails）してしまいます。フックはモデルにガードレールを設け、偶然や運任せにすることなく望む方向へと誘導するための優れた手段です。それだけでなく、エージェントハーネスにモニターを接続してデータを収集し、永続的なメモリシステムを追加するなど、応答の品質を一段と引き上げることも可能にしてくれます。
おわりに#
この業界の進化スピードは凄まじく、第一線でエンジニアリングを続けていくためには、新しいプロセスや技術が登場するたびに柔軟に取り入れ、足かせとなる古い慣習を手放していく適応力が欠かせません。それでも、（この記事を含め）世にあるいかなるガイドも「唯一の絶対的な真実」だとは思わないでください。この技術はまだ黎明期にあり、誰もが手探りの学習プロセスの真っ只中にいます。何より重要なのは、自分自身の開発環境においてどんな技術やワークフローが最も効果を発揮するのか、自ら実験を重ねて確かめることです。
この記事では、私にとってうまくいっているアプローチと、考え方の変遷について共有しました。しかし私自身、すべてを知っているわけではなく、日々学びの連続です。私たちは「AI のトレーニング」について多くの議論を交わしますが、何よりも大切なのは「自分自身の脳をトレーニングすること」です。AI を思考停止の言い訳にせず、実験、学習、そして改善のサイクルを回し続けましょう。そして、何か面白い発見があれば、ぜひ周りにもシェアしてください！
