LinkedIn が大規模コードベースにおける AI エージェントの限界を克服するため、Model Context Protocol（MCP）を基盤に、手順的記憶・コード検索・ランブックを coding agent に直接提供する Contextual Agent Playbooks and Tools を構築した事例。アーキテクチャの詳細と運用上のガードレールを紹介し、信頼性を損なわずに 20% の生産性向上を実現したと述べている。
何年も動き続ける resilient なソフトウェアを作るうえで重要だと筆者が考える指針をまとめた意見記事。開発者としての経験から得た考えを順不同で並べたもので、特定の技術に依存しない設計・実装・保守の姿勢に関する内容。
バイブコーディングで複雑化し制御不能になった GUI アプリに対し、AI へそのまま渡せる対策プロンプトを提示する記事。全コンポーネントを Root 配下に置き、各コンポーネントを MVP パターンの Passive View として描画パラメータのみ操作させ、動作は Chain of Responsibility でイベントをバブリングしてステートマシンとして振る舞う Mediator に裁定させる、という構造を指示する。macOS 常駐型 AI アシスタント「CooSenpAI」の開発経験を踏まえた内容。
フロントエンド開発において、要件定義から実装・テストまで責務を同じ語彙（Subject Object Verb）で記述し、ymlやアノテーションで静的に解析する提案。仕様と実装の突合をCIで継続的に検証し、要件漏れや実装漏れを減らし、AIの品質ゲートにも活用できるとする。
AIがほぼ全て書いたGoの注文処理コードを前に、レビューで何を見ればよいか分からずモヤモヤするジュニアとシニアの対話形式で、動くコードの裏に潜むカプセル化の崩れに着目し、AI生成コードを人間がどう検証すべきかを掘り下げる記事。
Knowledge Graph が agentic システムの基盤として重要になる理由を論じた講演。単純な RAG を超えて、context bundling、decision provenance、code as truth、agent visibility という4つの実践的なアーキテクチャパターンを解説し、Knowledge Graph 上に構築したエンジニアリングハーネスによってフィードバックループの効率化、トークン使用量の最適化、システムの信頼性維持を図る方法を示す。
クロステック・マネジメントが docker-agent を利用し、エージェントハーネスで開発パイプラインを構築している事例。プロダクトオーナーが Markdown で要求仕様を書くと、それを元に Web アプリの Pull Request を生成する。各工程は別々のエージェントが非同期に分担するマルチエージェント構成を取る。
AIを業務に組み込む際、実行前に評価に必要な情報が得られない処理では、最終承認型のHuman-in-the-loopだけでは不十分であり、「事前評価可能性」と「可逆性」に基づく段階的なゲート判断（限定実行→観測→再判断）として設計すべきだと論じる。Kubernetesのローリング更新を具体例として、その部品と人間の承認ワークフローの設計を分けて考える必要性を述べている。
NVIDIAのMemory-Driven Chief of Staffレシピを題材に、AIエージェントの長期メモリ運用における訂正・検査・削除の扱いを検証。人間の訂正が上書きされないこと、構造検査が不整合を検出する一方で内容の正しさは保証しないことなど、メモリを継続利用するための設計論を整理している。
ドメインモデル貧血症は、domain層の純粋性・性能・ロジック配置のトリレンマから構造的に生じると説明。Repository注入か事前取得か呼び出し側分岐のどれも犠牲が生じ、判断に必要なデータを型で返すDecisionパターンが解決策になると主張する。
DDDでドメインモデルが貧血になる原因を、repository呼び出し・先行取得・呼び出し側分岐のトリレンマとして分析し、判断に必要なデータを型で返すDecisionパターンで解決する手法を紹介している。
nginx静的配信のSPAからTanStack Start/Node.js配信への移行について、背景・ADRでの決定事項・実装手順とSSRまわりのつまずきを整理した記事。Cookie認証やCSRF対策、Kubernetes/Helm・distrolessの運用調整など、フロントエンドサーバー導入にまつわる具体的な検討内容が書かれている。
TBSの双方向配信プラットフォーム「Kustamie」で6万人規模の生配信を支えるため、API応答12秒の問題を多段キャッシュやSQSによる非同期化で0.15秒に改善した事例。k6による負荷試験、API Gateway/Lambdaの上限対策、BedrockとNova Microを使ったリアルタイムのチャット自動モデレーションなども紹介している。
SalesforceがAnthropicと提携し、ClaudeからSalesforceのデータやワークフローを操作できる「Salesforce in Claude」を発表。MCPを介したHeadless 360アーキテクチャで、権限管理をSalesforce側に維持する設計。SaaSの死論争に対するSalesforceの立場を示す。
AI開発時代に、アーキテクチャ選択におけるトレードオフの分析と意思決定の重要性を説く。モノリスvsマイクロサービスなどの例を挙げ、要件の定量化・評価軸の設定・比較検討・決定の記録(ADR)という4ステップの「ディシジョン・ドリブン・アーキテクチャ」を紹介。AIには決められない優先順位付けと背景の記録を人間が担うと論じる。
「一つのことは一つの方法」という規約を5言語（Kotlin/C#/Go/Rust/Java）で機械的に強制する実験結果。構造の規則は全言語で守れるが、各リポジトリの「active」自己申告は意味がずれて比較不能で、違反を仕込んでゲートが落ちる実証だけが比較可能。限界は言語のツールがどの粒度（テキスト/import/モジュール/メソッド署名）でコードを名指しできるかで決まると論じている。
Airbnbが認証フローをサーバードリブンアーキテクチャに移行し、認証関連コードを約60%削減した事例。クライアント側の分岐や複雑な認証処理をサーバー側で制御する設計により、コード重複を減らすアプローチを解説している。
エージェント型AIがデータを活用するには、人間向けのデータ設計では不十分で、信頼性・文脈・トレーサビリティ・ガバナンス・運用可能性の5属性をデータ層に組み込む必要がある。データ契約と品質、トレーサビリティとガバナンス、コンテキスト層、検索可能から実行可能への4段階で整備するというアーキテクチャ論。
レガシーコードベースでLLMコーディングの品質が落ちる原因は、用語の意味やコンテキスト境界が定義されていないことにあると指摘し、DDD（ドメイン駆動設計）のユビキタス言語と境界づけられたコンテキストをリポジトリごとの.workflow.jsonマニフェストとCONTEXT.mdグロッサリとして明示することで、エージェントが推測せず正しい判断を下せるようにする実践を紹介する記事。作業を「戦略的（何を変えるか決める）」と「戦術的（実装する）」に分け、後者はskillとsub-agentに委譲し、コンテキスト間のエッジ宣言の不整合は自動検出してissue化する仕組みも解説している。
TOTVSのFabiane Nardon氏が、AIエージェント向けにエンタープライズデータ基盤を設計する手法を解説。決定論的システムと確率的LLMをどう線引きするかを精度・セキュリティ・コストの3軸で説明し、データメッシュとデータプロダクト単位でMCPツールを設計しガバナンスを確保する方法、RDF/OWLによるセマンティックオントロジーでLLMの回答精度を高める事例、Postgres/DuckDBベースの低レイテンシ層をSpark/BigQueryと組み合わせた3層データ基盤アーキテクチャを紹介している。
Claude Codeのサブエージェントが43本まで増えて破綻したため、agentから「観点(lens/persona)」を切り離し、実行環境(モデル・ツール・権限)だけを持つ「器」として汎用化する設計に移行した記事。観点ファイルのパスを呼び出し側から渡す形にすることで、agent数を8本(+特化3本)まで削減し、起動時のdescription容量を7,318字から1,604字に圧縮。公式ドキュメントとの整合性も検証し、「2つ目の呼び出し元が同じ観点を欲しがるか」を人格を本文に焼き込むか外部ファイル化するかの判断基準として提示している。
Web開発ではCRUD/ActiveRecordの成功、画面起点の開発、事業の不確実性、モデリングの難しさという4つの要因からドメインが軽視されがちだが、変更理由の整合・語彙とデータモデルの一貫性・整合性境界の明確化という点でドメイン単位の境界設計には利点がある。初期はCRUDで速度を優先しつつ、リファクタリングへ移行するトリガーをあらかじめ合意しておくことが重要だと論じている。
GitHubで2024年8月17日に発生した大規模障害の公式ポストモーテムを解説する記事。データベースの過負荷が接続プールの枯渇を招き、依存サービスへカスケード的にダウンタイムが拡散した経緯を整理し、サーキットブレーカーパターンのPython実装例と、自社の障害分析にLLMを活用するプロンプト例を紹介している。
『ソフトウェアアーキテクチャの基礎』が示す「知識のピラミッド」（知っていること／知らないことを知っていること／知らないことを知らないこと）を軸に、アーキテクトに求められる技術の幅の広げ方を考察する記事。開発者は頂点の専門性（深さ）を掘り下げがちだが、アーキテクトへの成長には中間層（幅）を広げることが重要で、AI時代は0→1やAIに代替されない設計経験の価値が上がるとし、資格試験や日々の情報収集を幅を広げる手段として位置づけている。