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