Architecture

サーキットブレーカーは、失敗している依存サービスへのリクエストを遮断し、ゴルーチン、ソケット、メモリを消費して最終的にシステム全体が崩壊するというカスケード障害を防ぎます。

2026年にSpec-Driven Development（SDD）のセットアップを比較する開発者は、どのモデルが最も賢いかを問うことは通常ありません。彼らが問うのは、AIエージェントを整合的に保ちつつ、過度な儀式（ceremony）に埋もれさせないワークフローは何かということです。

仕様駆動型開発（SDD）は、仕様がドキュメントとしてキックオフ後に棚卸しされるものではなく、ワークフローそのものであるときに機能します。目的は、大規模な製品要件定義ドキュメントを作成することではありません。

LLMシステムにおけるセキュリティの関心は、プロンプトインジェクションに最も集中していますが、それは確かに注目を集めるべきものです。しかし、エージェントがツールを呼び出し、他のエージェントに作業を委任し始めると、それは問題の一部に過ぎなくなります。

ほとんどのAIエージェントのデモは、追加のステップを伴うチャット補完のように振る舞います。プロンプトを送信し、数秒待ってから、1つのレスポンスとして回答を受け取ります。

2025年、単一エージェントのAIシステムは最盛期を迎えました。一つのLLMにプロンプト、いくつかのツール、そして目標を与えるだけで、限定されたタスクではそれなりの成果を上げることができました。

一度は成功するはずの2つの書き込みが、やがて別々に失敗します。 注文サービスはデータベースに注文を保存し、次にメッセージブローカーにorder.createdイベントをパブリッシュします。

Goの context.Context は使い方が簡単すぎるため、誤用しがちです。これがまさに問題点です。

仕様駆動型開発（Spec-Driven Development）は、ソフトウェアエンジニアが以前から追求してきたものの、努力に見合う成果が得られなくなった際に棚上げされてきたアイデアの一つです。

仕様駆動型開発（SDD）は、2026年において「バイブコーディング（Vibe Coding）の逸脱」に対する真面目な開発者の回答として登場しました。

意思決定記録は、AI支援ソフトウェア開発における欠けていた記憶層です。それらは何が開発されたかだけでなく、なぜ開発されたかを捉えます。そしてその区別は、AIツールがコードを書く際には決定的に重要になります。

Goのエラー処理は、文句を言うのが簡単です。 すべてのGo開発者は、以下のコードを何百回も書いていることでしょう：

Goの並行コードのテストには、これまで少しの規律が必要でした。 ゴルーチンは軽量で、チャネルはシンプル、コンテキストのキャンセルは慣用的です——バックグラウンドワーカーとタイマーは、実世界のGoサービスにどこにでもあります。

GoogleのAgent2Agentプロトコル、一般的にA2Aと略されるこの規格は、最初の1年間で奇妙な展開をみせました。

ポーリングエージェントは、AIアシスタントのアーキテクチャの中で最も華やかではない部分の一つですが、同時に最も有用な部分の一つでもあります。

AIエージェントアーキテクチャは、2つのレイヤーに分割されつつあります。