レガシーコードベースで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層データ基盤アーキテクチャを紹介している。
個人開発ロボット目撃SNS「ROBOT GO」を10日100コミットで本番化した過程の記録。RLSだけでは権限不足で本番データが表示されない罠、モバイル実機で端末フレームが二重表示になったUIバグ、機能過多で地図が管理画面化した反省、投稿処理をGo+pgxの単一トランザクションへ集約し冪等性・レート制限・advisory lockで整合性を確保した設計、Cloudflare Containers前提が崩れてもHTTP境界を保ったままGo APIの配置先をMiniPC経由の構成へ変更した判断などを紹介している。
AWS Lambda構成をエンドポイントごとに分ける「単一目的Lambda」と、Honoで1つのLambdaにルーティングをまとめる「Lambdalith」を、コールドスタート・認可のタイミング・IAM権限・保守性・ルーティング表現力・CDKの書き方・CloudFormationリソース数の7観点で比較。前者はインフラ層での制御（起動前の認可・最小権限）に強く、後者は開発体験・保守性・リソース数の面で優位。結論は優劣ではなく「インフラ層で効かせたい要件があるか」で選ぶべきというもの。
Netflixのプリンシパルエンジニアが、米国内DVD事業向けに作られたシンプルな決済基盤が、国際展開に伴いどう進化してきたかを解説する講演。ブラジルのデビットカード事情による非同期決済への対応、130カ国同時グローバルローンチ時の課金ゾーン簡略化、地理的例外（サンピエール island）への対処など、アーキテクチャがビジネス変化に合わせて継続的に作り替えられてきた実例を紹介している。
SaaS型アプリケーション開発のためのベストプラクティス集「The Twelve-Factor App」。コードベース管理、依存関係の明示、環境変数による設定、バッキングサービスの疎結合化、ビルド/リリース/実行の分離、ステートレスなプロセス実行、ポートバインディング、並行性によるスケール、高速起動と安全な終了、開発と本番の一致、ログのイベントストリーム化、管理タスクの一回限りプロセス化という12の原則を解説している。
個人開発の店舗向け監視カメラサービスで、カメラ端末を店舗に紐付ける認可設計を解説。オーナー認証はFirebase Authenticationに委ね、カメラ紐付けはQRコード方式（常時稼働の撮影パイプラインと衝突）や個別承認方式（複数台設置に対し過剰）を却下し、曖昧文字を除いた8桁・有効期限24時間・再利用可能なペアリングコードを採用。登録後はカメラ専用トークンに認証を引き継ぐ多層防御でトレードオフを受け入れている。
アソビューがGA(Google Analytics)のpurchaseイベント計測をフロントエンド依存から脱却させた事例。GTM経由の送信ではブラウザ環境やQR決済（PayPay/au PAY）特有のアプリ遷移で計測漏れが発生するため、Measurement Protocol APIを使いバックエンドから直接イベント送信する方式を導入。通常導線ではWorkerアプリが購入完了通知を非同期処理し、QR決済ではclient_idを事前にDBへ保存しておきポーリング自動完了時にも紐付けて送信することで、計測漏れを解消した。
AWSがデータ変換ワークフローの仕様駆動コンポジションパターンを公開。ワークフローの意図（仕様）と処理ロジックを分離し、Lambda・Step Functions・S3・OpenSearchを用いてサーバーレスに実装。仕様がデータセットやフィールドマッピングを宣言的に記述し、コンポーザーが検証してパイプラインを動的に組み立てる。規制対応やマルチソース統合など、トレーサビリティと事前検証が重要なケースに適する一方、単純な変換には過剰な複雑さになりうるとしている。
個人開発の店舗向け監視カメラサービスで、ライブ映像配信プロトコルにWebRTC + SFUを採用した理由を解説。低遅延と1対多視聴という要件のもと、HLS/RTMPはセグメント方式による遅延の大きさで、WebRTC P2PはViewer数に比例する送信負荷とNAT越えの不安定さで却下。SFUを挟むことで低遅延を保ちつつCamera Agent側の送信負荷を一定に抑えられる一方、SFU運用という新たな責務が発生するトレードオフを説明。誰も見ていない間は配信を停止するオンデマンド設計や、pion/webrtcを使ったプロトタイプ検証にも言及している。
Goでレイヤードアーキテクチャを実践する連載の第16回。usecase層とhandler層を分離し、業務判断（入力検証・重複チェック）をusecaseに集約、handlerをHTTP翻訳役に専念させる。DI（依存性の注入）とGoのinterfaceの暗黙的実装を使い、main.goを配線専用にする設計を解説。偽物のrepositoryをinterface経由で注入することで、DBなしで業務ルールの単体テストが0.002秒で実行できることを実演し、テスト容易性をアーキテクチャで作り込む考え方を示す。
LINEヤフーがAIエージェントサービス「Agent i」向けに内製したエージェント開発基盤の紹介記事。ノーコードでワークフローを構築できる「Agent Builder」と、公開されたワークフローを負荷に応じて実行する「Agent Runtime」の2つで構成される。当初はマルチエージェント連携を目指していたが、そもそも一つのエージェントを作ること自体が難しいという課題に気づき、まず誰でも作れる基盤の整備を優先した。Agent BuilderはReact Flowを使ったグラフ編集画面で中間表現（IR）を生成・検証し、Agent RuntimeはKubernetes上でIRをLangGraphの実行グラフに変換して実行する。Namespace分離によるサンドボックス設計、負荷試験で判明したネットワーク帯域のボトルネック対応、Gatewayによる接続方式の吸収など実装上の工夫にも触れ、今後はA2AやMCPでの接続拡張、複数エージェントの自律的な連携を目指す方針を述べている。
組織内に乱立するメタデータリポジトリ（EMS、IR、IAM等）を統合・調整する「メタグリッド」という概念を紹介する書籍。データディスカバリーチームの構築手法や、経営層からアーキテクトまでが押さえるべきメタデータ管理戦略を解説し、データ民主化とセキュリティ強化を支える基盤の全体像を提示する。
個人開発の監視カメラサービスにおいて、設計ER図と実際のDB永続化状況にはギャップがあり、店舗・カメラ関連の4テーブルのみを先に永続化している。優先順位の基準は「プロセス再起動時に失われると困る度合い」で、ログインやカメラ識別に関わるデータを先に永続化し、再取得・再生成可能なイベント・通知はインメモリのまま残すという判断をMVP開発における実装順序の考え方として解説している。
バックエンドエンジニア基礎学習連載の第15回。レイヤードアーキテクチャのうちrepository層の切り出しを扱い、データ出し入れ担当の役割・メソッド命名・エラーの返し方・書いてはいけない処理など設計上の勘所を解説する
建築業向け社内ERPをTanStack Start + Hono + oRPC + Cloudflare Workersで開発した際の設計判断を解説。D1ではなくPostgreSQL（Hyperdrive経由）を選んだ理由、API契約をDB・実装から独立させてCIで依存方向を検査する手法、EVM計算を純粋関数化してサーバ・フロントで共有する設計、キャッシュ用と鮮度重視用でDB接続を分離する方法を紹介。さらにAIエージェント（Flue）を追加した際、UI向けに引いた契約・アーキテクチャ境界がそのままエージェントのデータアクセス境界として再利用できた点を成果として挙げ、契約保守コストの増加やローカル環境でのキャッシュ差異といったトレードオフにも言及している。
AIエージェントがプラットフォームの利用者になる時代に向け、Golden Path（推奨開発ワークフロー）をどう設計し直すかを論じた記事。実行パターン（低遅延の同期型・耐久性のある非同期型・隔離サンドボックス型）をワークロード要件に応じて選ぶこと、確率的なエージェントの判断と決定論的な制御（テスト・承認・デプロイルール）を分離すること、プラットフォーム機能を型付きスキーマ・冪等性・機械可読なエラー分類を備えた構造化インターフェースとして公開すること、サービスカタログを正確な状態に保つこと、そしてシグナルを認可済みの実行に変換する「dispatch」ステップやチェックポイント・リトライ予算・監査可能な記録を通じて自律的な作業を統制することを提案している。
Monzoが構築した独立バックアップ基盤「Monzo Stand-in」の解説記事。主系（AWS上の約3000マイクロサービス）とは別に、GCP上で約18サービスからなる完全に独立したスタンバイ環境を用意し、カード決済や送金、残高確認など重要機能のみを限定的に提供する。強整合性のレプリケーションではなく非同期・結果整合のデータ同期を採用し、主系とは別のコードベースで実装することで同一障害への耐性を高めている。運用コストは主系の約1%に抑えられており、2024年8月の大規模障害時に実際に稼働した実績を紹介している。
Claude Codeのサブエージェントが43本まで増えて破綻したため、agentから「観点(lens/persona)」を切り離し、実行環境(モデル・ツール・権限)だけを持つ「器」として汎用化する設計に移行した記事。観点ファイルのパスを呼び出し側から渡す形にすることで、agent数を8本(+特化3本)まで削減し、起動時のdescription容量を7,318字から1,604字に圧縮。公式ドキュメントとの整合性も検証し、「2つ目の呼び出し元が同じ観点を欲しがるか」を人格を本文に焼き込むか外部ファイル化するかの判断基準として提示している。
社内リリース基盤向け診断Agentの再設計で発生した品質回帰を分析した記事。ヘルスチェック呼び出しを条件付き実行に最適化するはずが、Progressive Disclosure・状態機械・終了条件などの実行制御の仕組みが調査判断そのものへ侵入し、Agentが証拠不足のまま終了する等の劣化を招いた。オープンな調査・中立な情報取得・厳格な安全実行の3層に責務を分離すべきと提案し、性能最適化は情報取得層に限定し、評価はコンポーネント単体でなく最小入力からの完全な行動軌跡を外部ブラックボックスで判定すべきと結論づけている。
マルチテナント環境で1つのテナントの負荷急増が他テナントに影響する「ノイジーネイバー」問題に対し、Google Cloudがハブ・アンド・スポーク型のシャーディングアーキテクチャを提案。統合トピックから読み取りテナント単位でファンアウトするルーターとしての「ハブ」、Pub/Subによる緩衝、優先度別に分離した複数のDataflowインスタンス「スポーク」で構成し、障害の影響範囲を100%から5%未満に抑える。DLQ実装・接続プールの制限・非同期I/Oバッファリングなど実装上のヒントも紹介している。
Web開発ではCRUD/ActiveRecordの成功、画面起点の開発、事業の不確実性、モデリングの難しさという4つの要因からドメインが軽視されがちだが、変更理由の整合・語彙とデータモデルの一貫性・整合性境界の明確化という点でドメイン単位の境界設計には利点がある。初期はCRUDで速度を優先しつつ、リファクタリングへ移行するトリガーをあらかじめ合意しておくことが重要だと論じている。
GitHubで2024年8月17日に発生した大規模障害の公式ポストモーテムを解説する記事。データベースの過負荷が接続プールの枯渇を招き、依存サービスへカスケード的にダウンタイムが拡散した経緯を整理し、サーキットブレーカーパターンのPython実装例と、自社の障害分析にLLMを活用するプロンプト例を紹介している。
『ソフトウェアアーキテクチャの基礎』が示す「知識のピラミッド」（知っていること／知らないことを知っていること／知らないことを知らないこと）を軸に、アーキテクトに求められる技術の幅の広げ方を考察する記事。開発者は頂点の専門性（深さ）を掘り下げがちだが、アーキテクトへの成長には中間層（幅）を広げることが重要で、AI時代は0→1やAIに代替されない設計経験の価値が上がるとし、資格試験や日々の情報収集を幅を広げる手段として位置づけている。
MotherDuckがAIエージェントによるセマンティックレイヤー（Malloy）の自律構築を検証した実験報告。AIは「hands-off」でMalloyモデルを生成できたが、Markdown+SQL方式より2.5倍のトークンを消費し、精度も95%対100%で劣り速度も遅かった。ここから、実装（セマンティックレイヤー自体）は使い捨て可能になり、質問と期待回答のペア（evalセット）こそが組織の意図を保存する耐久的な資産になるという洞察を提示。今後はコードではなく「振る舞いの記述」を蓄積し、必要に応じてAIで再生成する設計への転換を提案している。