Scraps 最終更新 2026/10/02 00:40

#アーキテクチャ

@さにんぐ /

Claudeの口癖は「落ち着いてください。」 — 開発未経験の私が、初めて「機能」を作った話

  • 開発未経験者が初めてソート機能を実装し、顧客視点と設計判断の重要性を学んだ
  • 自然順と辞書順の比較、ICU collation方式とソートキー列方式の選択、UIの設計
  • 設計判断にはリリース後の影響も考慮し、曖昧なまま判断せず確認する

@小川幹雄 /

「AIの民主化」を日本で言い出した身として、そろそろ本当に「民主化」をやめたい話

  • AIエージェント時代には「AIの民主化」が成立しなくなった
  • AutoML時代の1対5の生産性差がエージェント時代には1対100〜1000に拡大し、30点のプロトタイプと80点以上の運用システムのギャップが生じている
  • 30点のエージェントは自己責任で使うべきで、80点以上の品質を確保するには専門家によるガバナンスが必要

@早々(WW)のフリーランス /

Python: str.join() は文字列のメソッド(配列が主語にならない理由)

  • Pythonのstr.join()は文字列が主語でリストやイテラブルを引数に受け取る
  • リストやタプル、ジェネレータなどイテラブルを結合できる仕組みと、型ごとのメソッド重複を避ける設計
  • リストにjoinメソッドを実装するとイテラブルごとに同じ処理を繰り返す必要があるため、文字列側に集約されている

@ないとー /

減らない分岐は、指示ではなく型のせいだった

  • 型が不正な状態を許すと、コーディングエージェントがその分岐を書く。指示を直しても減らない。
  • 判別共用体で状態を直和にし、境界でparseして型で検証する。型エラーで修正箇所を自動検出する。
  • 型が許す状態は分岐として書かれるため、レビューで確認する項目が増える。判別共用体で状態を網羅的に表現する。

@ihiratch /

状態空間モデルにおけるFilteringとSmoothingの違いを理解する

  • Filteringは過去の観測から現在の状態を推定し、Smoothingは未来の観測も使って過去の状態を推定し直す
  • Filteringはp(x_t|y_{1:t})を計算し、Smoothingはp(x_t|y_{1:T})を計算する。予測ステップとベイズ更新、後ろ向きの尤度計算が主な手順
  • SmoothingはFilteringより19%高い推定精度を示し、信用区間も狭くなるが、両者のアンサンブルでさらに精度向上が可能である。

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

SaaSの技術的難しさはホリゾンタルとバーティカルで異なる

  • SaaSの技術的難しさはホリゾンタルとバーティカルで戦い方が異なる
  • ホリゾンタルは95点の答えを高速に実装し、バーティカルは30点の解を70点に高める
  • テーマごとに90点か70点かを判断し、品質水準や検証プロセスを変える必要がある

@bik /

Claude Codeが必須手順を無言で飛ばした。実案件でわかった3つのこと

  • Claude Codeを使った実案件で、必須手順が無視される、指示に忠実に従う、再開位置がずれるなどの問題が起きた
  • 必須手順は停止ポイントとして設計する必要があり、AIスキルは実行される仕様として扱う、状態保存場所の整合性が重要
  • AIスキルのレビューとテストを必須とし、状態保存場所を統一する対応が必要

@Tomonori Hayashi / @pHaya72 /

お前のループエンジニアリングは間違っている

  • ループエンジニアリングの実践で人間の確認を必要最小限にし、自動化の仕組みを構築する
  • 評価観点と評価基準の区別、状態遷移に人間確認ステータスを追加、仕事の発見を自動化する
  • 人間の確認は可逆性と影響範囲で濃淡をつけることで減らすことが可能

@wfukatsu /

【チームによるAI駆動開発の勘所:第6回】指摘事項で書いたものを、止める側へ

  • 指摘事項を4分類に分けてHooksやSkillsに還元する方法が説明されている
  • 規約違反はHooksで、実装パターンはSkillsで、知識不足はCLAUDE.mdで、設計判断は判断チェックリストで対応
  • 機械的に判定できる指摘はCLAUDE.mdに流すと検出できなくなるためHooksに配置すべき

@keison /

NOCCA×NOCCAの完全解析を独立再現してみた

  • NOCCA×NOCCAの強解決を別実装で独立再現し、論文の予想通り到達不可能な配置が60個で尽きることを確認した
  • 左右反転を畳む設計と組合せ数系のrank/unrank、全空間2bit版のメモリ戦略、ゴール勝ちを1手として数えるルール
  • 到達不可能な配置の数が60個で尽きることをBFS未到達候補全件のZDD照会で確認し、論文の予想を裏付けた

@石坂忠広 /

ほぼ週間Go言語 2026/08/23: Go 1.27関連記事まとめ

  • Go 1.27でジェネリックメソッドやencoding/json/v2、goroutineリーク検出が正式リリースされた
  • ジェネリックメソッドは構造体メソッドに型パラメータを追加、encoding/json/v2は従来のエンジンに置き換えられ、goroutineリークプロファイルはruntime/pprofから利用可能に
  • encoding/json/v2はエラー判定にerrors.Isを使うこと、UUIDv7の時刻は業務日時として使えないこと、goroutineリークプロファイルはステージング環境でテストすることを確認する

@autotaker1984 /

コーディングエージェントを増やすとコードはどう変わるのか――5つの分業パターンで品質と開発コストを比べた

  • エージェントの分業パターンによってコード品質や開発コストが大きく変わる
  • Singleは全体を一つの文脈で扱い、Plan-Dev-QAは計画・開発・品質保証を分業し、テストと共有契約を増やす
  • 品質保証を厚くするとテストコードが7割増え、変更時の入力トークンも2倍になるためコストが増える

@Hatachi /

「なぜ画面とロジックを分けるの?」実務1ヶ月目のエンジニアが理解したMVVMのメリットと役割分担

  • MVVMパターンで画面とロジックを分離することでメンテナンス性が向上する
  • データバインディングで画面更新を自動化、ロジックをViewModelに集約
  • Viewにロジックを書くと仕様変更時の修正範囲が広がるため、ViewModelに処理を移すことが推奨される