Taming Vibe Coding という記事を公開してから6ヶ月以上が経過しました。この記事では、コーディング・エージェントを使用して生産性を向上させるために私が実践してきた主要な手法をまとめました。
その記事の内容の多くは現在でも有効ですが、この半年間でこの分野では多くのことが起こりました。そこで、それ以来私の考えがどのように進化したかについて、簡単にアップデートすることにしました。
プロンプティングとコンテキスト・エンジニアリング#
プロンプティングは依然として重要であり、適切に構造化されたプロンプトは多くの時間を節約してくれます。しかし、プランニング・システムの登場により、以前ほど決定的な要素ではなくなりました。現在の多くのコーディング・エージェントには、プラン（またはプランニング）モードが搭載されており、タスクを数ターンかけて「ブレインストーミング」し、コーディングに移る前に実装プランを練り上げます。
これにより、コードが書かれる前にプランを確認し、エージェントを誘導することが可能になり、多くの時間とトークンを節約できます。変わっていないのは、一貫した結果を保証するための強力な受け入れ条件（Acceptance Criteria）の必要性です。これは、私がプランをレビューする際に最も注意を払う部分です。
コンテキスト・エンジニアリングは、エージェント・スキル（Skills）の普及により劇的に改善されました。そのため、最近では AGENTS.md（または GEMINI.md, CLAUDE.md など）を書くことをほとんど気にしなくなりました。Antigravity には Rules という概念があり、これも本質的にはコンテキストの最適化ですが、私はスキルのほうを好んで使っています。AGENTS.md やルールでしかできないことで、他の手法では代替できないものにはまだ出会っていません。
セマンティック検索などによる検索拡張生成（RAG）に関連するコンテキスト・エンジニアリングの側面は、専門的な知識においては依然として重要です。これはメモリ・システムの仕組みでもあり、外部依存関係を扱う際には、パッケージのドキュメントをコンテキストに注入する手法を今でも使っています。
Model Context Protocol の台頭と衰退（？）#
MCP サーバーを立ち上げる代わりに、エージェント・スキルと CLI ツールの組み合わせを好む人が増えています。それも一つの考え方ですが、私はエージェントに直接シェル・アクセスを与えることに不安を感じるため、依然としてツールをローカルで実行する MCP サーバー（godoctor や speedgrapher など）にパッケージ化することを好みます。変わった点といえば、MCP サーバーのインストールに対して非常に慎重になり、ほとんどの場合、自作のカスタム・サーバーのみを構成していることです。
また、MCP サーバーを単独で使うことはほとんどなく、スキルと MCP を組み合わせて使用します。スキルがプロセスを記述し、MCP がツールを公開します。これは、MCP の指示自体を最適化しようとするよりも効果的であることが多いです。私は MCP の指示に何百時間も費やしてきましたが、コーディング・エージェントに完全に無視されることもありました。
ほとんどの場合は MCP + スキルを使用しますが、本当に重要なタスクには、MCP + スキル + hooks の「スーパーコンボ」を使用します。hooks の部分は、エージェントを私が望む方向に強制的に向かわせる役割を担います。私はこれを「エージェントをレールに乗せる」や「エージェントの主体性（Agency）を制限する」と呼ぶことがあります。hook システムにより、望ましくないアクションをブロックし、エージェントが使ってほしいツールを使うように「優しく促す」ことができます。これにより、ツールが呼び出されるかどうかの確率的要素を排除し、決定論的な動作を強制することができます。
あらゆるものにスキルを#
私は、繰り返したいプロセスに対してスキルを作成します。例えば、私が最もよく使うスキルは、テクニカルライティングやレビューに関するものです。なぜなら、私は常に（このブログのような）コンテンツを制作しているからです。また、エージェントが苦手とするテクノロジーについてもスキルを書きます。これには通常、新しいテクノロジー、ニッチなプロジェクト、または自作のプロジェクトが含まれます。
例えば、最近 A2UI のワークショップの準備で非常に苦労しました。A2UI は、エージェント・ユーザーインターフェースを開発するための比較的新しいプロトコルです。非常に斬新なコンセプトであり、私には非常に具体的な教育上のニーズがあったため、エージェントは多くの助けと試行錯誤なしには理解できませんでした。最初のハードルを越えた後は、この知識をスキルにパッケージ化することで、次に同様のことを行う際にスムーズに進めることができました。
マイナス面としては、自分のスキルを最新の状態に保ち、整理しておくことが苦手であることです。この問題を解決することが MCP にとっての「救済の瞬間」になるかもしれません。現在、プロトコルの仕様にスキルを追加する提案がなされています。残念ながら、それがいつ実現するか（あるいは実現するかどうか）の見通しは立っていません。そのため、当面は自分たちでスキルを管理し続けるしかありません。理論的には、プロンプトを使った段階的な開示とスクリプトが必要な部分のためのツールを使用して、MCP で「スキル風」の体験を作り出すことも可能ですが、現在のバックログを考えると、まだ試せていません。
サブエージェントの台頭（と衰退の兆しなし）#
サブエージェントは、今誰もが話題にしている「次のクールなもの」です。そのアイデアは、タスクを分離されたコンテキスト・ウィンドウを持つ独自のエージェントとして起動し、並列化することです。これには、コンテキストの最適な使用、タスク間の汚染の回避、コンテキストの早期劣化（Context Rot）の防止というメリットがあります。また、各タスクが自己完結しているため圧縮の必要性が減り、メインのコンテキスト・ウィンドウを汚染することもありません。コーディング・ハーネスのサポートという点では、スキルと同じように、独自のシステム・プロンプト、モデル、構成を持つエージェントを事前に宣言できるものもあれば、Antigravity のように、メイン・セッションの「クローン」としてアドホックにエージェントを作成する方式を好むものもあります。
アドホックなエージェント作成では、プロンプトを使用して3つの異なるエージェントを立ち上げ、並列に実行するといったクリエイティブなことが可能ですが、Antigravity に事前に宣言されたエージェントがないのは少し寂しい気もします。事前宣言があれば、自分の「厳選された」エージェントをポータブルな形でパックできるからです。また、エージェント間でタスクを並列化することは、習得が容易なスキルではありません。この1年、エージェントにタスクを与えることには慣れましたが、それらを効率的にオーケストレートする方法についてはまだあまり考えていません。
多くの点で、これはプロダクト・オーナーやチーム・リーダーがタスクを分解し、チームがどのように取り組むかを考える際に使うのと同じ筋肉を使います。しかし、サブエージェントの場合、固定されたチームではなく、好きなだけ「チーム・メンバー」を作成できます。結局のところ、私が並列化にこだわるのは「クール」だからではなく、「それによってより良い結果が得られるか？」という問いのためです。
もし答えが「いいえ」であれば、一度に1つのエージェントを実行するほうが賢明です。プランニングに費やす労力や、慎重にタスクを分割する精神的な負担が報われないからです。だからこそ、私は自分のエージェントを事前に定義できることを好みます。必要なときに専門化させるだけで済み、並列に実行されるかどうかはそれほど重要ではないからです。
Hooks は最高の友#
最後にお気に入りのものを紹介します。hooks です。hooks は、エージェントのライフサイクルにおける特定のイベントでトリガーされるコールバックです。先週、これについて記事一冊分（hooksをマスターする）を書きました。この記事を読み終えたら、ぜひチェックしてみてください。結論として、モデルは予測不可能であり、簡単にレールから外れてしまうことがあります。hooks は、モデルにガードレールを追加し、運に頼ることなく望む方向に誘導するための優れた方法です。さらに、エージェント・ハーネスにモニターを接続してデータを収集し、永続的なメモリ・システムを追加するなど、応答の品質を向上させることも可能にします。
結論#
業界の動きは速く、存在感を示し続けるためには、新しいプロセスやテクニックが登場するたびにそれらを受け入れ、足かせとなっている古い荷物を手放す適応力が必要です。それでも、（この記事を含め）世にあるガイドを真実の源だと思わないでください。このテクノロジーはまだ初期段階にあり、誰もが学習の過程にあります。重要なのは、自分の環境に最適なテクノロジーとワークフローを見極めるために実験することです。
この記事では、私にとってうまくいっていること、そして私の考えがどのように進化してきたかを共有しましたが、私がすべてを知っているわけではなく、常に学び続けています。AI のトレーニングについてはよく語られますが、自分の脳をトレーニングすることのほうがはるかに重要であることを忘れないでください。AI を自分の脳を停止させる言い訳にせず、実験、学習、反復を続けてください。そして、何か面白い発見があれば、ぜひ共有してください！
