#アーキテクチャ — Scraps（4ページ目）

@wfukatsu / 15日前

AIに営業プロセスを一周させた（5）提案書23枚を型から組み上げる

提案書は17セクションの型に事実を流し込むことで作成される
課題は3点までに絞り、スコープ外を明記し、比較表に現状維持・内製・既存ベンダー拡張を含める
事例は公表値のみ使用し、出典を明記する。PoC成功基準をスケジュールに反映させる

@Link and Motivation Developers' Blog / 15日前

なぜ「とりあえずref」でいいのか？reactiveとの違いを改めて整理する

refはプリミティブとオブジェクトの両方を扱えるが、reactiveはオブジェクトのみ対応
refは.valueで値をアクセスし、reactiveは通常のオブジェクトのようにアクセス。refはプリミティブも扱えるがreactiveはオブジェクトのみ
reactiveはオブジェクト全体を置き換えるとリアクティブな接続が失われるため、基本的にはrefを使うのが推奨される

@Yoshinari Tanaka (sonicmoov) / 15日前

LLMを業務に入れて分かった「オントロジー」の効き方 — 運に頼らないAI運用の骨組み

LLMを業務に載せる際のオントロジーの設計論が公開された
オントロジーはモノ・コト・視座で構成され、骨子と血肉の区別が重要。viewとツリーの分離、ロールの使い分けが特徴
オントロジーを使うことでAIの提案と人の判断の分担が明確になり、情報資産化が可能になる

@アクシスNWチーム広報部公式note✅ 投稿週3(月水金12:00) / 15日前

#80 後輩に「AIエージェントにもゼロトラストって適用できるんですか？」と聞かれて言葉に詰まった私が、Googleの新しいエージェント設計思想を整理した話

GoogleがAIエージェント向けゼロトラスト設計のリファレンス実装を公開した
3層防御は署名検証・コード隔離・機械的なルールチェックで構成され、プロンプトインジェクション対策にモデル外の強制力を組み合わせた
データベース書き換えやコード実行を伴う処理がある場合、署名検証や隔離実行の仕組みが必要である

@やまだ / 16日前

何をAIに任せ、何を人間に残すか？ - 私たちの開発現場のAIとの役割分担

AIに任せることと人間に残すことをバランスよく検討した開発現場の役割分担が提案された
上流の判断は人間が担い、実作業はAIに任せつつハーネスでコントロールする形が適切と判断
成長機会を確保するためには人間がレビューと要件確認を行う必要がある

@mshimasan / 16日前

品質メトリクスの運用、どうしてる？ ―― データを疑い、リスクを拾う。ログラスQAエンジニアの活動

品質KPIを定義し、その収集・集計・分析を継続的に行っている
インシデントの収束速度と予防の2つの指標を用い、Notion DBのプロパティ定義を見直し、AIと人間の分析を組み合わせる
KPIの定義を見直すきっかけになるような分析結果を出すために、AIの要約と明細の数値を突き合わせる

@Funaba / 16日前

テスト開始を待たない QA ーテスト以外でも価値を発揮するための実践例

QAエンジニアがテスト以外の段階で品質向上に貢献する3つの取り組みを紹介
仕様共有ミーティングを共同レビューの場に、テストレベルごとの担当チームの振り分け、テスト設計技法をチーム全員の仕様理解に活用
実装前に仕様の考慮漏れを発見できるようになった、QAチームが仕様への解像度を高めた状態でテスト設計できるようになった

@hyo-maki / 16日前

【DDD】モノリスを分割するサブドメイン特定法

サブドメインの境界線を特定するための6つの指標を用いてモノリスを分割した
作業成果物の一方向の受け渡し、ドメインエキスパートのグループ、ドメイン用語の定義が指標に含まれる
サブドメインの分割はチーム規模や過去のリリース傾向を考慮して柔軟に変更するべき

@dach / 16日前

Agentに実装を任せる前に、「ズレ」を見つける

AIエージェントに実装を任せる前に、処理順やデータ関係のズレを設計技法で確認する
アクティビティ図で処理順と副作用の境界、ER図でデータ関係と「消える」の意味を確認する
処理順やデータの意味のズレを事前に見つけることで、実装後の修正コストを減らせる

@ShigemoriMasato / 16日前

[初心者] AIコーディングが遅くなった？「読む量」を減らして速さを取り戻すIRV

AIコーディングの遅さは、変更前の読解情報量（IRV）が増えることが原因
IRVはソースコード・テスト・仕様・資料の読解量を含み、ルールの分散や契約の明確さが影響
変更ごとの調査範囲を小さくするにはルールの持ち主を決め、部品間の約束を書くことが効果的

@Kou / 16日前

「【Laravel】Fat Controllerはもう古い？保守性を10倍高めるクリーン設計術」～【laravel】人気記事（09/13）

LaravelでFat Controllerを避けて保守性を高める設計手法が紹介されている
Custom FacadeやMiddleware、Service/Repository層の分離が具体的な実装例とともに説明されている
Controllerの肥大化を防ぐための設計選択が実務に直接影響する

@Ando / 16日前

仕様と実装を同じ言葉で書く ― 責務を機械的に突合し検証し続けるフロントエンド開発（要件定義〜実装・テスト）

フロントエンド開発で仕様と実装を同じ語彙で書くことで、機械的な突合で漏れを防ぐ手法を提案
SOVアーキテクチャの命名規則とymlによる責務宣言、ts-morphでの実装抽出、Playwrightテストとの突合
実装と仕様の突合はCIで自動化可能で、未実装責務や野良コンポーネントを差集合で検出できる

@gonzo-gongon / 16日前

意思決定が、加速するAI開発のボトルネックにならないために

AIによるコード生成の進化に伴う意思決定のボトルネックを解消するための具体的な手法が提示されている
結論の理解に必要な背景を明確化し、自然言語の曖昧さを排除する制約を設ける、AIの追従性を低減する
AIの自己申告を信用せず外部のエビデンスで確認する、プロパティベーステストでさまざまなケースに対応できるコードにする

@クラウドエース株式会社 / 17日前

ソフトウェア DNA とクラウドエージェントのススメ

ソフトウェアDNAとクラウドエージェントを組み合わせてAI駆動開発を実践
ソフトウェアDNAでソフトウェアの「あるべき姿」を定義し、クラウドエージェントに自己完結性を付与
ソフトウェアDNAが明確であればクラウドエージェントに仕事を任せやすくなる

@taki_tech / 17日前

# ゲームエンジンの仕組みとは？

ゲームエンジンはゲームループ、レンダリングエンジン、物理エンジン、アセット管理で構成されている
ゲームループは固定タイムステップでロジックを実行し、可変フレームレートで描画する。物理エンジンは衝突判定を2段階で行う
UnityとGodotはFixedUpdateと_physics_processでロジックを分離し、Unreal Engineは設定で制御する設計になっている

@虎の穴ラボ技術ブログ / 17日前

書評「SQLアンチパターン第2版」

SQLアンチパターン第2版はデータベース設計の失敗パターンを解説し、実務で使える設計手法を提示している
キーレスエントリ、EAV、ポリモーフィック関連の3つのアンチパターンと、クラステーブル継承、STIなどの解決策が紹介されている
外部キーの使い方やEAVの代替案を検討する際には、それぞれのメリット/デメリットを考慮する必要がある

@Seunghyun Cho / 17日前

React Compiler を Babel なしで入れて、useMemo を書くか迷うのをやめた

React Compiler を Babel なしで導入し、手動メモ化を減らす方法を実装した
Oxc による React Compiler 実装と TanStack Table v9 への移行、lint で手動メモ化を禁止するルール
AI 生成コードのメモ化判断を減らすため、手動メモ化を原則禁止し lint で機械的に検出する

@o8n / 17日前

モデルの責務分割と保存形式からの独立を見分ける

モデルの責務分割と保存形式からの独立は別々に判断すべき
Active Recordのモデルに複数の責務が集まり、Data Mapperでモデルとデータベースを分離するケースを比較
変更要求の内容によっては保存形式の制約が責務分割を妨げるため、変換ロジックの保守コストを考慮する必要がある

@カミナシエンジニアブログ / 17日前

フロントエンドなんてバイブコーディングで良いこの時代に、私は

フロントエンドの設計とUX改善がAI時代でも重要
Nani翻訳の非ブロッキング処理、Linearの同期エンジン、楽観的更新のロールバック設計
体験改善にはデータモデルやアーキテクチャの前提を変える設計が必要で、フロントエンドの都合から出発する発想が重要

@tofu_frontend / 18日前

:has()で不要になったJavaScript 10選

:has()で不要になったJavaScriptの10個のケースが紹介されている
:user-invalidで入力状態の判定、:has(img)で画像の有無のレイアウト変更、:has(input:checked)でチェックボックスのスタイル変更
:has()の特異度が高くなるので、意図しない上書きを防ぐために:where()を使うべき