#architecture

InfoQがオンライン認定プログラムを拡充し、新たに AI Engineering と Organizational Architecture のコホートを追加した 対象は初心者ではなく、senior / staff / principal など、すでに責任の重い意思決定を担う人たち 5週間の少人数コホート形式で、事前学習 → 4時間のライブワークショップ → 自分の実案件に当てはめる流れ AIは「作る」だけでなく、RAG、agents、evals、AI infrastructure、production reliability まで扱う Organizational Architecture は、技術そのものよりも 組織設計、価値の流れ、platform strategy、認知負荷 などに焦点を当てる 個人的には、これは「資格」というより上級者同士の実戦会議に近い設計で、かなり実用寄りだと思う InfoQがオンライン認定プログラムを拡張し、新たに2つのコホートを追加しました。 追加されたのは、**InfoQ Certified

古いシステムにAIを足すとき、いちばん壊れやすいのは「AIそのもの」ではなく、その前後にある既存の仕組みだ――この記事は、そんな現実をかなり生々しく教えてくれます。 DEV Communityの元記事では、2014年から動いているローン申請プラットフォームにLLMを組み込んだチームが、どこでつまずいたのかを順番に振り返っています。読んでいて「そりゃそうなるよね…」と何度も思いました。デモではうまくいくのに、本番では別世界。AI導入あるあるの、かなり本質的な話です。 LLMを通常の関数みたいに扱うと危ない - 遅延や障害が起きたとき、画面全体や決済処理まで止まる AI導入は実質「データ整備プロジェクト」になりがち - 古いDBには、意味の曖昧な項目や表記ゆれが山ほどある コスト監視は最初から必要 - AIは静かにお金を食うので、あとから気づくと請求額が怖い 解決策はLLMをアプリ本体から切り離すこと - gateway を挟み、timeout・fallback・監査ログ・コスト計測を持たせる AIはモデルより「つなぎ目」で失敗する - 既存システム

Joynのバックエンドは、最初は単一ノード中心で壊れやすい構成だった 問題の本丸はコードだけでなく、データ整合性・可用性・デプロイ時間だった 解決策としてserverlessに移行し、AWSのmanaged servicesを積極活用した データの一貫性にはHub and Spoke patternを採用 障害の広がりを抑えるためにcell-based isolationを使った さらに、multi-region active-activeを現実的なコストで実現する工夫が重要だった InfoQの「Evolution of a Backend for a Streaming Application」は、ドイツのストリーミングサービス Joyn のバックエンドが、どうやって“火の車”状態から立て直されたのかを語るプレゼンだ。 話しているのは Daniele Frasca さん。ざっくり言うと、「最初はかなり苦しい構成だったけど、AWSベースのserverlessへ段階的に移行して、可用性・スケーラビリティ・デプロイ速度を改善していった

コードには 2つの役割 がある。 1つは機械を動かす命令、もう1つは人間が理解するための概念モデル。 良いコードは、単なる手順書ではなく、ドメインの語彙 を映し出す。 ソフトウェア開発は、業務ドメイン（例: retail, banking）と技術ドメイン（例: web, data, AI）の 翻訳作業 に近い。 bounded context（境界づけられた文脈）は、同じ言葉でも意味が変わる現実を受け止めるための考え方。 言語や framework は、表現手段であると同時に 思考の道具 でもある。 LLMはコード生成を安くしたが、だからこそ「コードの価値はどこにあるのか？」が問われている。 これからは、コードを量産する力よりも、正しい概念を見つけ、形にする力 が重要になる。 Martin Fowler の記事「What Is Code?」は、タイトルこそシンプルですが、かなり本質的な問いを投げかけています。 一見すると「コードとは、プログラマーが書く命令文でしょ？」で終わりそうです。でもこの記事は、そこから一段深く掘ります。特に生成AI