2025年も最後の月になりました。ほんとに時間の経過が早いなと年々感じています。

1年が早かったと思いつつも、生成AI周りの変化は依然目まぐるしく今年1年だけでも新たなワードが出てきたと思っています。

印象に残っていた出来事に関して、記載していきたいと思います。
印象ベースで書いていくので、事実と微妙に異なるかもしれませんが、その点は寛容的にみていただけると嬉しいです。

MCP (Model Context Protocol) による外部サービス連携の容易化

2024年11月末に、Claude から MCP (Model Context Protocol) がリリースされ、2024年の暮れから2025年の上半期にかけて、さまざまなAIエージェントサービスや、SaaS がこぞって MCPサーバーを公開する流れがきました。
MCPサーバーの登場で、AIエージェントが外部サービスと容易に連携できるようになります。
MCPサーバーと連携することによって、AIエージェントのモデルが持っていない知識や能力を増強し、AIを使ってできることの質や量も上がっていきました。

個人的に当時感動していたのは、Playwright MCP です。Playwright は、フロントエンドのE2Eテストや、コンポーネントテストなどが行えるテストフレームワークですが、Playwright MCP を使ってAIエージェントに簡単なユーザビリティテストをやってもらったり、ユーザーガイドの作成をしてもらったり、テストの枠を超えて幅広く利用できる点が好評価でした。

（一方で、MCPの利便性と並んでセキュリティ観点の問題は出てきてはいますね。）

◼︎ ↓ MCPについて

Vibe Coding でだれでもアプリが作れる世界観へ

2025年2月、Open AI共同創業者のアンドレイ・カルパシー氏が、Xにて感覚的にコーディングをする営みを「Vibe Coding」と名付けました。このころ利用できた Vibe Coding にあたるサービスとしては、Claude Artifacts, V0, Bolt.new あたりだったかと思います。
AコーディングをAIエージェントに任せて、人間はAIのアウトプットを（たとえばWebページ）を実際に見て、フィードバックを行い、タスクを完遂する方法です。

◼︎ アンドレイ・カルパシー氏のX投稿

◼︎ Claude Artifacts GA

◼︎ V0

◼︎ Bolt.new

AIエージェントが自力である程度まともなアウトプットを出すようになったので、AIエージェントにそろそろタスクを任せようかなと思った人間が、感覚的にコーディングをして楽をしようと企んでいるといった構図かなと個人的には捉えています。

Vibe Coding は、動くものが簡単に作れるといった利点があり、プロトタイプの作成が簡単になったり、コーディングをやらないような方がアプリを作ったり、今までの 0 → 1 のハードルを大幅に下げたと思います。

一方 Vibe Coding の副作用として、AIが好き勝手にコードを書いてしまうため人間が読みづらかったり、後から変更を加えようとするとリグレッションが発生してアプリの動作が壊れやすくなったり、と技術的負債が積み重なっていることが往々にしてあったと思います。
また、人間が思った通りにAIがコーディングをしてくれないというストレスも同時にあったかと思います。

Context Engineering による生成AIのガードレール導入

「人間が思った通りにAIがコーディングをしてくれない」をさらに細かくいうと、人間の言語化が不十分なところに起因していることが考えられます。
人間が出す指示の背景や、言語化できていない部分をAIは汲み取ることができません。
文脈（Context）をAIに渡しておくことで、Vibe Coding で不足していたバックグラウンドを共有する必要性があります。
では、何でもかんでもAIに文脈 (Context) を与えればいいかというと、そうではありません。
AIエージェントが保持できる文脈には限りがあります。

Context Window と呼ばれるAIエージェントが記憶できる情報量の限界を意識しながら、できるだけコンパクトにしつつ、必要な文脈 (Context) をAIエージェントに提供することが考えられました。
そこで登場しているのが、Context Engineering です。

Context Engineering とは、AIエージェントが意思決定を行うために必要な情報を文脈（Context）として提供する方法で、Prompt Engineering を拡張し、再定義されたワードです。

広範囲をカバーするような包括的な考え方で、AIエージェントが全体像を理解しながら、個別最適なアウトプットができるように、人間は必要な文脈 (Context) を言語化する部分に注力したらいいのかなと漠然と思っていました。
2025年の夏、AIエージェントのために人間が働く、そんな未来がやって来るのかなと思ったりしていましたねー

◼︎ Everything is Context Engineering

Spec-Driven Development の登場

2025年7月に AWS から KIRO がリリースされ、2025年9月には Github から spec-kit がリリースされました。
従来の人間の開発フェイズを尊重したような形になっており、まずは言語化して認識をすり合わせてから実装するような流れを取ります。
先ほど紹介した Context Engineering 同様、認識合わせを綿密にやっておくことによって、アウトプットの質を担保しようとする方法です。
Spec-Driven Development は、Specify → Plan → Tasks → Implement の4フェーズで構成されていて、順番に内容を明確にしていく感じで、個人的には考慮漏れが減っているように感じています。
また spec-kit には Contitution というコマンドがあり、こちらではプロジェクトのルールや原則などを記載しておくことで、AIエージェントがそれらを守ってくれやすくなります。

◼︎ KIRO

◼︎ spec-kit

Contiuous AI という考え方

CI/CD に並ぶ概念で、GithubNext のほうで提唱されています。
開発の中で、特定のタイミングや条件で繰り返し利用される生成AIエージェントによるタスクを総称して、Continuous AI （継続的AI）と呼んでいるようです。

継続的AIとは、あらゆるプラットフォームにおけるソフトウェアコラボレーションをサポートする自動化AIのあらゆる用途を指す名称です。あらゆるプラットフォームにおけるあらゆるソフトウェアコラボレーションをサポートする自動化AIのあらゆる用途が、継続的AIです。

該当するものが結構多いなという印象ですが、人間がチェックしていて、仕組み化が難しかった部分にもAIエージェントを使って自動化が適用されていくかもしれませんね。

GithubNext が、Continuous AI に該当するサービス、ライブラリの一覧を公開しているので、該当するものがなにかは awsome-continuous-ai のページで確認するといいかなと思います。

◼︎ Continuous AI

◼︎ Awsome List of Continuous AI

TOON というトークン効率を考えたフォーマット

TOON (Token-Oriented Object Nation) とは、トークン効率がいいと言われるデータのフォーマットです。
最近耳にして気になっていますが、使ったりは特にできていません。
YAMLをベースに、CSVのフォーマットを取り入れた形式のようで、JSONと比較してトークン効率がかなりいいと言われています。
難点としては、新しいフォーマットなので、モデルが学習しているかどうかというところですね。
古いモデルだとTOONに関する知識がないので、トークン効率がよくても精度面でどうなのかは気になりますね。

マルチターンでAIエージェントとやり取りをすることが増えてきているので、コンテキストを小さくすることを考えると、使うシーンは出てきそうな気がしています。あとは、トークン消費を抑えて生成AIの従量課金コストを下げるといった観点でも、貢献できそうです。

◼︎ TOON

◼︎ TOON Playground

まとめ

2025年をふりかえってみましたが、生成AI開発まわりの変化はやっぱり早いなと思いました。
今後も最新情報をウォッチしつつ、新しいプラクティスや考え方を取り入れて、開発体験、ひいては顧客体験の向上に繋げるため、生成AIをフル活用できればと思っています！

ここまで読んでいただきありがとうございました！