/note/tech

要件定義の精度を高めるための型と生成AIの活用

• 要件定義の精度を高めるための型と生成AIの活用 / Using Types and Generative AI to Improve the Accuracy of Requirements Definition - Speaker Deck

要約:

■ 1. 概要

• 発表: BPStudy #224（2026年4月30日）
• 発表者: 佐藤治夫（株式会社ビープラウド 代表取締役社長）
• テーマ: 要件定義の精度を高めるための「型」と生成AIの活用
• アジェンダ構成:
  • 01 再浮上する要件定義不要論
  • 02 エージェントによる開発と要件定義
  • 03 コンテキストエンジニアリングとRDRAの親和性
  • 04 モデルベース要件定義手法 RDRA とは
  • 05 RDRA Agent の価値
  • 06 エンジニアリングの重要性の高まり

■ 2. 再浮上する要件定義不要論

• 時代背景:
  • 2025〜2026年にAI Agent時代が到来しつつある
  • コードを書く主体が「人間」から「エージェント」へ移行しつつある
  • 従来のSDLC（要件→設計→実装→テスト→レビュー→デプロイ→監視）が「意図→エージェント→コード+テスト+デプロイ→動作確認→出荷」へ変化しつつある
• 要件定義不要論の背景にある思惑:
  • 作ってから直せばよい（フィードバックを元に直せるという前提）
  • 作ったものを見ないと要件はわからない（動く実物が要件を引き出すという考え方）
  • 動くものがあると進んでいるようで安心する（進捗報告がしやすい）
  • 早く開発したい（設計以降の作業の方が得意・楽しい）
  • 要件定義は不要だとイーロン・マスクも言っている
• 要件定義を省略すると起こること:
  • 不要なものを必要以上に作ってしまう（本来不要な機能や仕様まで実装）
  • 要求の爆発（整理されないまま要求が雪だるま式に膨らむ）
  • 手戻り工数の増大（後工程ほど修正コストが指数的に上昇）
• 後になるほど大変になるため「急がば回れ」の心構えが必要
• アジャイル開発においても各スプリントが「開発対象スコープの要件定義」を内包する

■ 3. エージェントによる開発と要件定義

• エージェント開発での問題の顕在化:
  • 不要なものを必要以上に作る → 工数を吟味せず開発してしまう
  • 要求の爆発 → Why/Whatが無いため優先順位付けが難しい
  • 手戻り工数の増大 → トークンのムダな消費
• 大規模システムをエージェントだけで作るのは手戻りが大きくほぼ不可能
• 「XXXシステムをつくりたい」だけをエージェントに渡しても意図と実装の差分が大きく失敗する
• 対策: システムをユースケース・ストーリー単位に適切に分割する
• ユースケース（ストーリー）がコンテキストとなるコンテキスト設計が有効
• 要件定義の成果物がそのままコンテキストエンジニアリングの入力になる

■ 4. コンテキストエンジニアリングとRDRAの親和性

• コンテキストの腐敗:
  • 入力コンテキストが増えるほど回答精度が低下する現象が存在する
  • 理想的な回答精度に対して実際の回答精度は入力量が増えるほど低下する
• 自然言語ベースのユースケース記述やストーリーはコンテキストとして悪くはないが解像度が粗い:
  • 曖昧さが残りAIへの問い直しが多発する
  • AIとの往復が繰り返し発生しトークン消費・時間コストが嵩む
• RDRAのユースケースは「画面・イベント・タイマー・情報・条件・バリエーション・状態（遷移）」と関係づけて記述する
• RDRAの要素のつながりがコンテキストとして有効である（仮説）

■ 5. モデルベース要件定義手法 RDRA とは

• RDRAの定義（Relationship Driven Requirement Analysis）:
  • システム開発のための要件定義手法（現場で適用できる実装可能な方法論）
  • 要素同士の「関係（Relationship）」を定義する
  • モデルとして可視化する（俯瞰できるモデルを作る）
• システムの定義:
  • 極めて多数の構成要素から成る集合体で各部分が有機的に連携して全体として一つの目的を持った仕事をするもの（新明解国語辞典 第7版）
• 従来の要件定義手法の問題点:
  • 自然言語と断片的な図で記述することが多い
  • システムにとって重要な「要件（構成要素）間のつながり」を読み手が推測して理解する必要がある
  • 抜け漏れ・不整合が発生しやすく要件定義の精度が低下する
• RDRAによる要件定義の優位性:
  • 要素のつながりを明示的に定義する
  • 推測不要（関係性が定義として書かれている）
  • 抜け漏れ・不整合を自動的に検出できる
  • 要件定義の精度・品質が上がる
• RDRAの全体像（4層構造）:
  • システム価値: 要求確認（システム・外部システム・要求）
  • システム外部環境: 業務要件定義（業務・BUC=Business Use Case）
  • システム境界: システム要件定義（UC=Use Case・画面・イベント・情報・条件・タイマー）
  • システム: コンテキスト・情報モデル・状態モデル・条件・バリエーション
• RDRAの進め方:
  • RDRA定義・分析Sheet（Google Sheetsで要件を定義・分析・検証する）
  • RDRA Graph（ブラウザでモデルをビジュアルに確認する）
  • 「関連データ」シートからRDRA Graphを開く
• 要素の定義と関連付けをシートで実施する構成要素:
  • アクター・外部システム（システム価値・外部環境）
  • BUC（システム外部環境・システム境界）
  • 情報・状態・条件・バリエーション（システム内部）
• RDRAによる要件定義の3フェーズ:
  • Phase 1（枠組みを作る）: 議論の土台作り（全体の構成要素を洗い出す）
  • Phase 2（要件を組み立てる）: 要素を関連づけて骨格を組む（トップダウン+ボトムアップ）
  • Phase 3（整合性・網羅性を高める）: 要件定義の仕上げと仕様化の準備（矛盾を解消し整合性を高める）

■ 6. RDRA Agent の価値

• 従来の悩みどころ:
  • 土台を1から作るのが重い（0から構造を組み立てる工数が大きい）
  • 抜け漏れが出やすい（初期に観点を網羅しきれない）
• RDRA ZeroOne / RDRA Agentの価値:
  • LLMを活用してモデルの叩きを0→1で自動生成する
  • テキストデータをクリップボードから読み込みRDRA Graphを開く
  • 「ZeroOne」シートにテキストを貼り付けRDRA定義・分析Sheetを生成する
  • 土台を自動生成することで議論から開始できる
• 制約事項:
  • 整合性・精度向上フェーズ（Phase 2・Phase 3）は人による議論と合意が必須

■ 7. エンジニアリングの重要性の高まり

• AIエージェントの二面性:
  • 業務の生産性や成果を劇的に高める「能力増幅装置」として機能する
  • 適切に管理されない場合はリスクを拡大させる装置にもなり得る
• エンジニアリング原則（手戻りコストの影響を常に意識する）:
  • ソフトウェア開発201の鉄則「鉄則41: 今すぐ要求仕様書の誤りを直せ」
  • 要求仕様書の誤りは発見が後になるほどコストが増大する
  • 設計まで残ったら修正に5倍のコスト
  • コーディングまで残ったら10倍のコスト
  • テスティングまで残ったら20倍のコスト
  • 納入時点まで残ったら200倍のコスト
  • 「後で修正すればいい」という考え方が最終的な納期とコストを破壊する
• エンジニアリング原則（インサイドアウトで品質を高める）:
  • プロセス品質（要件管理・設計基準・レビュー・早期テスト）
  • 内部品質（保守性・再利用性・テスト容易性）
  • 外部品質（機能・性能・セキュリティ）
  • 利用時の品質（目的の達成・価値の創出）
  • これらが連鎖することで品質+開発生産性の向上につながる
• エンジニアリング原則（V字モデルを開発の地図として持つ）:
  • 企画→業務要件定義→システム要件定義→基本設計→詳細設計→プログラミング（左下降）
  • コードレビュー→単体テスト→結合テスト→システムテスト→運用テスト→運用・評価（右上昇）
  • 効果的なエンジニアリングがAIの使用効率も高める
• 弁証法的考察（螺旋階段モデル）:
  • 世の中全ての物事の進歩や発展は右肩上がりに一直線に進歩・発展するのではない
  • あたかも「螺旋階段」を登るようにして進歩・発展していく（田坂広志『使える弁証法』より）
  • 正（テーゼ）→反（アンチテーゼ）→合（ジンテーゼ・アウフヘーベン＝否定の否定）のサイクルで発展する
• エンジニアリングの変遷（弁証法的な螺旋発展）:
  • 2000年代: エンジニアリング重視（プロセス・モデリング・設計、オブジェクト指向設計、RUP・UML・PoEAA・アナリシスパターン）
  • 2010年代: アジャイル開発が台頭（プロセスを重視した開発へのアンチテーゼとして技術・実装重視へ）
  • 2025年以降: 新しいエンジニアリングの在り方（エンジニアリングと技術・実装が融合されたものへ）

■ 8. まとめ

• 再浮上する要件定義不要論: 手を抜くと後ほど大変になる（不要なものを開発・要求の爆発・手戻り工数の増大）
• エージェントによる開発と要件定義: 企画・要件定義の内容がコンテキストエンジニアリングにそのままつながる
• コンテキストエンジニアリングとRDRAの親和性: RDRAの要素のつながりがコンテキストになる
• モデルベース要件定義手法RDRA: システムを構成する要素同士の関係（Relationship）を定義することでモデルとして可視化する
• RDRA Agentの価値: 叩きが生成されることでゼロからのスタートを回避できる
• エンジニアリングの重要性の高まり: AIエージェントは「能力増幅装置」だからこそエンジニアリングが効く

(2026/05/08)

生成AIでスクラムによる開発はどう変わるか

• 生成AIでスクラムによる開発はどう変わるか | Ryuzee.com

要約:

■ 1. 概要

• タイトル: 生成AIでスクラムによる開発はどう変わるか
• 登壇者: 吉羽龍太郎（株式会社アトラクタ CTO・認定スクラムトレーナー）
• 日時: 2025年10月17日

■ 2. 生成AI導入の現状

• 調査回答者の90%が仕事でAIを利用
• 80%以上が生産性向上を実感
• AI導入はもはや検証段階でなく利用しないことがマイナスな状況

■ 3. 従来のスクラムにおける時間配分

• 実装作業が律速要因
• スプリントの時間配分は開発作業の最大化を優先
• スクラムイベント・リファインメント・事務作業を最小化する構造

■ 4. 生成AIによるボトルネックの変化

• 実装時間の激減:
  • 調査・実装・テスト支援が大幅短縮
• ボトルネックの移動:
  • 実装から「事前のドキュメント化」と「事後の検証」へシフト

■ 5. ドキュメント中心化

• AIは「考えを想像」しないためテキスト化されたドキュメントが必須
• 詳細化が重要なドキュメント:
  • プロダクトバックログ
  • スプリントゴール
  • 完成の定義
  • アーキテクチャー
  • コーディング規約
• ドキュメント化のコツ:
  • 前提条件・入力・出力を具体化
  • 例と反例を示す
  • 参照先を紐付ける
  • 用語の一貫性を保つ

■ 6. チーム構成の変化

• モブプログラミングへのシフト:
  • 並列作業の必要性が低下
• 小チーム化:
  • コミュニケーションコスト削減
  • 合意形成の高速化
• ドメイン分割による複数小チーム構成が有効

■ 7. スクラムイベントの変化

• スプリント期間:
  • 従来は1〜2週間が一般的
  • 実装が速くなり1週間以下も可能
• スプリントプランニング:
  • 詳細化のタイミングを遅延可能
  • スプリント中のモブ作業で詳細化
• スプリントゴール:
  • 短期化に伴い重要性が増加
  • 明確なテーマで集中促進
• デイリースクラム:
  • モブ化で常時スクラムの状態
  • 形式的イベントの重要性が低下
• スプリントレビュー:
  • ステークホルダー参加頻度がボトルネック化
  • AIを前提とした期待値調整が必要
• スプリントレトロスペクティブ:
  • AI活用方法の改善が常時テーマ
  • 実験・検証が定常化

■ 8. プロダクトバックログアイテムの変化

• 粒度:
  • 1スプリント単位でなく「AI入力単位＋検査容易性」で設計
• 見積りの意味低下:
  • 実装時間の不確実性低減でベロシティ計測の重要性が減少
• 受け入れ基準の詳細化:
  • テストケースなどを先行検討

■ 9. 現場の課題

• 説明責任:
  • AIに責任を委譲しない
  • 決定と根拠をドキュメント化
  • 完成の定義に説明可能性を含める
• 品質管理:
  • 入力品質とベースコード品質が出力を決定
  • レビュー・ガイドライン・テンプレートの重要性向上
  • 検査と適応の頻度を上げる
• 人材育成:
  • AI活用でコーディング経験機会が激減
  • シニアエンジニアの育成パイプラインが危機的
  • 組織的なスキル投資が必須

■ 10. まとめ

• スプリント短期化とドキュメント優先
• 見積りより内容の合意を重視
• AI活用方法の継続改善
• 品質維持の仕掛けの整備
• 透明性・検査・適応の不変性
• 学習への継続投資

(2026/05/07)

以前、fsnotify がメンテ出来なくなりメンテナを募集　→ 知見があるのでメンテナに参加　→ その時、某氏...

以前、fsnotify がメンテ出来なくなりメンテナを募集

→ 知見があるのでメンテナに参加 → その時、某氏も参加 → 活動しようと思ったら「勝手な事をするな」と叱られる

それからしばらく経って

→ ユーザから「このリポジトリもうメンテしてないん？」と言われる → 見てみるともう 2～3カ月活動がない → 「僕がやるわ」と即答 → 幾らかバグを潰しリリースもした → そして今日突然なんの通告もなく fsnotify の org から強制除名。

某氏、勢い余ってか fsontify の元作者すらも org から削除してしまった様で、ぶっちゃけ怖い。

@mattn_jp

いっぽうで、僕はもう気軽に fsnotify/fsnotify を使う事が出来なくなってしまったので、gofsnotify/fsnotify を作って自分で育てていく事にしました。今のところ僕専用です。

https://github.com/gofsnotify/fsnotify

@mattn_jp

フォークしたリポジトリでの経緯説明

• https://github.com/gofsnotify/fsnotify/issues/1#issuecomment-4386693483

A bit of background on why this project exists. Some time ago the original fsnotify lost its active maintainer and a call went out for help, and since I had prior experience in this area I joined the maintainer team. Another person signed on around the same time, and when I tried to start contributing I was told not to "act on my own."

A while later a user asked me whether the repository was still being maintained. I checked and saw there had been no activity for two or three months, so I stepped in, fixed several bugs, and even cut a release. Then today, with no prior notice, I was suddenly removed from the fsnotify organization.

The upshot is that I can no longer work on fsnotify in my own style, so I'm building my own here under a separate organization. The name happens to match, but the implementation does not reference the original source — though for a feature set like this, the public API will naturally come out looking similar. I don't expect to return to fsnotify/fsnotify either. The API design here may evolve over time, but at minimum, my expertise around Windows will be poured into this codebase.

このプロジェクトが立ち上がった経緯について少し説明します。少し前、オリジナルのfsnotifyはアクティブなメンテナを失い、助けを求める呼びかけがありました。私はこの分野での経験があったため、メンテナチームに加わりました。ほぼ同時期に別のメンバーも加わりましたが、私が貢献を始めようとしたところ、「独断で行動しないように」と言われました。

それからしばらくして、あるユーザーからリポジトリがまだメンテナンスされているか尋ねられました。確認してみると、2、3ヶ月間活動がなかったため、私が介入していくつかのバグを修正し、リリースまで行いました。ところが今日、事前の通知もなく、突然fsnotifyの組織から除外されてしまいました。

結果として、私はもはや自分のスタイルでfsnotifyに取り組むことができなくなったため、別の組織の下で独自のプロジェクトを構築しています。名前は偶然一致していますが、実装は元のソースコードを参照していません。とはいえ、このような機能セットの場合、公開APIは当然似たようなものになるでしょう。fsnotify/fsnotifyに戻るつもりもありません。ここのAPI設計は今後進化していくかもしれませんが、少なくとも、Windowsに関する私の専門知識はこのコードベースに注ぎ込まれることになります。

その後

件の fsnotify に関する投稿を削除しました。必要以上に不安を煽ってしまったり混乱を起こしてしまうのは僕も避けたい為であり、それ以上の意味はありません。

なおエビデンスを消した訳ではなく、投稿は自ら魚拓を取って保存しており必要な場面があれば提出します。

@mattn_jp

MEMO:

• 追放した某氏は↓
• arp242 (Martin Tournoij)
• 幼稚な独占欲によるものか、何かよからぬ事を考えているのか

(2026/05/07)

おい、要件を動くものにしろ

• おい、要件を動くものにしろ - じゃあ、おうちで学べる

要約:

■ 1. 記事の概要

• タイトルは「おい、要件を動くものにしろ」であり AI時代における要件工学シリーズ第2部にあたる
• 要件は文書として残すものではなく 型システム・テスト・CI/CDパイプライン・コードスキーマ・自動レビューに埋め込まれた「動くもの」として存在すべきであると主張する
• ドキュメントは書かれた瞬間から腐敗が始まるが コードに埋め込まれた要件は毎日読まれ検証され続ける

■ 2. 要件・仕様・契約の定義整理とスペック駆動開発の分類

• 三つの概念の定義:
  • 要件:ビジネスが達成したいこと
  • 仕様:システムがその要件をどのように実装するか
  • 契約:コンポーネント間の保証
• スペック駆動開発の3分類:
  • スペックファースト:仕様は実装後に破棄される
  • スペックアンカード:仕様は実装と並走して更新される
  • スペックアズソース:コードは仕様を唯一の真実の源として導出される
• 著者はハイブリッドアプローチを推奨し 仕様が価値を生む箇所にのみ適用することを提唱する

■ 3. AIコードのレビューが困難な理由と信頼構築の方向性

• AI生成コードのレビューには通常の3倍の時間がかかる
• 原因は読む時間の増加ではなく「共有コンテキストの欠如」にある
• 人間のレビュアーが依存する暗黙のチーム知識をAIは持たない
• 解決策はより良いプロンプトではなく より良いコンテキストの提供にある
• 信頼構築のための4方向:
  • ドメイン知識を明示的に構造化する
  • 責任の境界を明確にする
  • 実装前に要件合意を明示的に確保するようプロセスを再設計する
  • AIへの指示をチームの共有資産へ移行する

■ 4. 要件の5層分散

• 原則:1つの要件は1箇所に配置し 検証されるタイミングによって配置先を決定する
• 各層の配置:
  • プロジェクトレベル:CLAUDE.mdに記述する
  • ドメイン固有:ドキュメントとスキルに記述する
  • 機能固有:コミットメッセージ・PRテンプレート・テストコメントに記述する
  • 手続き的:CIワークフローとリンティングルールに記述する
  • 振る舞い:実行可能なテストスイートに記述する

■ 5. 主観的レビューの削減とアーキテクチャの役割

• 著者は「客観的／主観的 × 予防的／回復的」の2×2マトリクスを提示する
• AI時代のボトルネックは「主観的×予防的」の象限であり 自動化できない人間の判断を要する
• アーキテクチャによりこの象限を最小化する手法:
  • 境界付きコンテキスト:意思決定の境界を明確にする
  • 常に有効なドメインモデル:型によって不正な状態を表現不可能にする
  • タイプファースト開発:型を優先して設計する
  • 可変コードと不変コードの分離
  • イベントソーシングによる説明責任の確保

■ 6. 受け入れ基準の実行可能化

• 曖昧な記述（例:「速くなければならない」）を具体的な形式に変換する
• 要件は「いつ・誰が・どこで・何を・どのように・どのくらい」の6要素で記述する
• 具体例:「ユーザーがクリックしたとき APIは200ms以内に応答する」という形式にする
• 「してはならないこと」と「明示的にスコープ外のこと」も記述する

■ 7. 非機能要件とトレードオフの管理

• 非機能要件（性能・セキュリティ・保守性など）は相互に干渉する
• セキュリティ強化は性能を低下させるなど 全てを同時に最大化することはできない
• 「上位3つ」の優先順位を特定し 何がハード目標（二値的合否）で何がソフト目標（程度による）かを認識する
• プロジェクトのフェーズが変化するにつれて優先順位を定期的に見直す

■ 8. 著者のスタンスと実践的原則

• 著者は「仕様書よりも検証を重視する」立場をとる
• 厚い要件ドキュメントよりも 厚いテストとガードレールを重視する
• 実践的原則:
  • 要件は読まれる場所に記述する:別途ドキュメントではなくコードのコンテキストに記述する
  • 測定可能なものは全て自動化し 本物の判断が必要なものにのみ人間のレビューを用いる
  • 要件の進化を認識し「上位3つ」の優先順位をプロジェクト成熟に合わせて見直す
  • 要件はカテゴリではなく検証タイミングによって配置する
  • 書き込み操作と読み込み操作を分離しレビューの強度に差をつける

論評:

■ 1. 総評

• 記事の主張密度と文章量の比率が逆転している
• 核心的な主張は早期に確立されており 以降は同じ主張の繰り返しまたは傍証の積み上げに費やされている
• 記事全体は必要な分量の2倍に相当する

■ 2. 論理的に機能している部分

• 中心テーゼの明確さ:
  • 「ドキュメントに置かれた要件は腐る 動くもの（テスト・型・CI・CLAUDE.md）に分散させた要件だけが毎回検証される」という主張が一貫している
• 撤回条件の明示:
  • この種の実践知系記事では珍しく誠実であり 論述の信頼性を高めている
• 要件/仕様/契約の3区分:
  • 実用的で読者に整理をもたらす
  • 仕様駆動開発の文脈でこれを明示したことに価値がある

■ 3. 論理的に脆弱な部分

• 「動くものは腐らない」という前提の誤り:
  • 著者自身が結論部でテスト・lintルール・CLAUDE.mdも古びると認めている
  • 「腐らない」ではなく「腐ったとき気づきやすいかどうか」という違いを論じるべき
  • 強い主張を採用したまま自己矛盾を抱えている
• 「3倍のレビュー時間」の根拠の脆弱さ:
  • N=1の自己計測にすぎない
  • この数値から「AIで書いたコードは構造的に信頼できない」という一般命題を導いており 観測規模と主張のスケールが不釣り合い
• 「5つの場所に散らす」処方箋の構造的問題:
  • 処方箋を先に提示した後 その問題点として自らの失敗事例が続く
  • 読者を混乱させる順序であり 「1つの要件は1つの場所」を前提として先に述べ 5つは「置き場の種類」として整理し直す必要がある
• 「AIのエラーは新種ではない」という主張の検証不可能性:
  • 撤回条件として「AI固有で以前には観測されなかったエラーを列挙できたら撤回する」と記載している
  • 「AI以前に存在しなかった新種エラー」の同定自体が主観的かつ困難であり 撤回条件が実質的に機能しない
• 4象限モデルの「主観×予防がボトルネック」の論証不足:
  • 「他の象限が自動化・高速化したから相対的に目立つ」という相対論的推論のみで 「最大」と断言するには不十分

■ 4. 主張の冗長パターン

• パターンA（テーゼの繰り返し）:
  • 「動くものに要件を散らす」「ドキュメントは腐る」「機械に判定させる」が複数の節でほぼ同一命題として再登場する
• パターンB（撤回条件の儀式化）:
  • 5〜6回登場することでテンプレート的な免責事項に見えてくる
  • 主要な主張に1〜2回絞った方が誠実さが際立つ
• パターンC（非機能要件節の逸脱）:
  • 「トレードオフ」「Top 3」「時間軸の変化」「AIシステムの新しい品質要件」は中心テーゼとの接続が薄い
  • 結論に辿り着くまでの道のりが長すぎる
• パターンD（個人エピソードの過剰使用）:
  • マイナス在庫の失敗・深夜の差し戻し・空調管理システム・保持期間インシデント等 主張の補強よりページ数の補充として機能している場面が多い

■ 5. 構造的批判

• 記事は実質的に5本の異なる記事を1本に詰め込んでいる:
  • 仕様駆動開発の用語整理と分類
  • AIコードレビューの構造的困難
  • 要件を実行可能な形へ変換する技法
  • 認知負荷を減らすアーキテクチャパターン
  • 非機能要件のトレードオフ管理
• タイトル「おい 要件を動くものにしろ」に対して読者が期待するのは「要件を実行可能な形へ変換する技法」のみ
• 仕様駆動開発の用語整理とAIコードレビューの困難は導入として機能するが アーキテクチャパターンと非機能要件管理は本記事の射程を超えている
• 4象限モデル以降は別稿にすべきであり そうすることで本論が締まる

■ 6. 結論的評価

• 中心テーゼの明確さ: 高い
• 論理の整合性: 中程度（自己矛盾あり）
• 証拠の質: 低め（個人観測が中心）
• 冗長さ: 問題あり（2倍の分量）
• 実務上の有用性: 高い（具体的な処方箋は有用）
• 「ドキュメントより実行可能なもので要件を保つ」という主張は正しく実践的な価値も高い
• 主張の強さに対して論証が追いついていない
• 分量を半分にして核心（要件を動くものへ変換する技法）に絞れば 説得力は現状より増す

(2026/05/06)

ソフトウェア開発の本質的な問題は何だと思いますか？に対する山本 聡 (Satoshi Yamamoto)さんの回答

• ソフトウェア開発の本質的な問題は何だと思いますか？に対する山本 聡 (Satoshi Yamamoto)さんの回答 - Quora

要約:

■ 1. ソフトウェア開発の難しさ：複雑さとの戦い

• ソフトウェアは機能追加により必然的に大規模化し機能間の関係が複雑さを生む
• 複雑さが個人やチームの許容値を超えると不具合増加・工数超過・開発停滞が発生する
• 複雑さを制御しシンプルさを保つことがソフトウェア開発の核心的課題である

■ 2. 複雑さへの対処：継続的リファクタリング

• 機能追加後に複雑化したまま放置せずその場でリファクタリングを行う
• コードへの理解が深い段階で修正することで修正コストが最小化される
• 「新規機能開発前に十分なリファクタリングをしているか」を方針として掲げる
• Joel Testの「バグ修正優先」をさらに発展させリファクタリングを先行させる
• リファクタリングを認めるプロジェクトは複雑さを抑制し順調に進む傾向がある
• 製造業のカイゼン（整理整頓）と同様にソースコードも継続的な整理整頓が有効である

■ 3. ソフトウェア開発の本質的な問題：「見えない」こと

• 良いものと悪いものの判断がすぐにはできないことが本質的問題である
• ホテルや自動車は素人でも品質の良否をある程度観察できる
• ソフトウェアのコードは熟練技術者でも数ヶ月読み込まないと良否の判断が困難である
• 言語が異なれば上級者であっても判断不能になる

■ 4. 「見えない」ことが引き起こす問題

• 上級者には明らかな問題が初心者・中級者には「意見の相違」として処理される
• 良くないコードがマネジメント層には問題に見えずリファクタリングの必要性が無視される
• 初心者・中級者が上級者のコードを誤って低く評価するケースも生じる
• コード断片の善し悪し→プロジェクト全体の善し悪し→プロジェクト運営の善し悪しと段階的に判断が難しくなる
• 顧客と開発者の意思疎通困難・開発者同士の相互理解困難・見積もりの困難もすべて「見えない」問題に帰結する

■ 5. 観察と誤った改善への注意

• うまくいっていないのにカイゼン不要と思い込み現状維持のまま手遅れになるケースがある
• うまくいっていることをカイゼンしようとして逆効果を招くケースもある
• 例：ドキュメント不要で順調だった開発にドキュメント作成を導入し開発速度が低下する
• 何がうまくいっていて何がうまくいっていないかを正確に観察することが重要である

(2026/05/06)

人月の神話

• 人月の神話 - Martin Fowler's Bliki (ja)

要約:

■ 1. 書籍の概要

• フレッド・ブルックスが1960年代初頭にIBM System/360開発プロジェクトを統括した経験をもとに執筆
• 1975年に出版された『人月の神話』はソフトウェア開発において最も影響力のある書籍の一つ
• 2026年時点で一部の内容は時代遅れとなっているが多くの教訓は現在も有効

■ 2. ブルックスの法則

• 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」という法則を提唱
• 要員増加により生じる問題:
  • コミュニケーション経路が指数関数的に増加する
  • コミュニケーション設計が不十分な場合作業が混乱に陥る

■ 3. コンセプトの完全性

• システム設計において最も重要な考慮事項はコンセプトの完全性である
• 設計思想に一貫性のあるシステムは機能が限定されていても優れたアイデアを無秩序に詰め込んだシステムより望ましい
• コンセプトの完全性を構成する要素:
  • 簡潔さ（simplicity）
  • 直截（straightforwardness）：要素を容易に組み立てられるかどうか

■ 4. 推奨事項

• 20周年記念版の入手を推奨
• 1986年の影響力の大きい論文「銀の弾などない」が同版に収録されている

(2026/05/06)

人を増やしても減らしてもアウトプットの品質は向上しない

• 人を増やしても減らしてもアウトプットの品質は向上しない - kosui

要約:

■ 1. 結論

• 人数の増減はアウトプットの品質向上に直結しない
• 問題の本質はコミュニケーションパスの増加と知識のエントロピー拡大が引き起こす中央集権化ループにある
• 解決策は「何を許し何を禁じるか」を自動検出可能な少数の条文として明文化する規範レイヤーの整備である
• 条文はリスクの大きさに応じて詳細度を配分し人間が読まなくても自動で機能する最小集合に絞り込むことが重要

■ 2. 人数増減の限界

• 人を増やした場合の問題:
  • コミュニケーションパスがN(N-1)/2で指数的に増加する（10人で45本・20人で190本・30人で435本）
  • 知識のエントロピー（メンバーが持つ知識分布のばらつき）が拡大し文脈共有コストが増大する
• 人を減らした場合の問題:
  • 解くべき問題の複雑さは変わらず1人あたりの担当範囲が広がる
  • 知識のエントロピーはむしろ増し各人の認知負荷が積み上がる
• 共通の帰結:
  • いずれの場合も意思決定が特定のリードに集中する中央集権化ループに陥る
  • 中央集権体制は意思決定速度を一時的に回復するが分散意思決定と構造的に両立しない
  • リードへの認知負荷累積は判断品質の低下と育成機会の喪失をもたらす

■ 3. 自律的な存在が解決しない問題

• 一貫性の喪失:
  • 局所最適の許容によりUI・データモデル・命名のばらつきが累積する
  • 後続実装者の読解コスト増加がゼロから書く動機を生みばらつきがさらに加速する強化ループに入る
  • 一貫性を収束させようとするレビュワーへの依存が強まり前章と同じ中央集権化ループに帰着する
• ナレッジの劣化:
  • AIによる書き込み頻度の増加に対し剪定役が不在であれば矛盾と陳腐化が加速度的に累積する
  • ナレッジベースへの不信が暗黙知化を進め知識のエントロピーを押し上げる
  • AIエージェントは文脈共有をeasyにするが共有すべき内容そのものをsimpleにはしない
• 自律的な人間の燃え尽き:
  • AI活用度が高い人ほど一人あたりの判断量が増え育成に割ける時間が圧迫される
  • 育成停滞により後進に任せられない状態となり特定人物への判断集中がさらに強まる
  • 判断品質の低下や離脱が残メンバーの負担へ転じ組織全体のパフォーマンスが低下する

■ 4. 規範レイヤーの設計

• 設計の方向性:
  • 「組織として何を許し何を禁じるか」を共有された規範として明文化する
  • ホラクラシー憲章は権力配分の枠組みを定めるが組織横断的な行為規範を含まない
  • 規範なしにリードの暗黙知に依存した運用を続けるとリードへの依存ループが維持される
• 条文の要件:
  • 型検査・CI・Linterとして表現できるものはそこに記述し自動検出を優先する
  • AIエージェントがパターン的に判断できる形での形式化も許容する
  • 規則はADRによってのみ変更可能とする
  • PRD・Design Doc・ADRは人間レビューの前に規範に準じて機械的に評価される
• 条文の例:
  • PIIを永続化する場合はADRやDesign Docで理由を必ず明示する
  • プラットフォームシステムではPHIを永続化してはならない
  • IDや金額などのリテラル値は固有の型を必須とし型検査で取り違えを防ぐ

■ 5. 条文設計の品質基準

• 官僚化リスク:
  • 条文を増やすほど組織は官僚的な方向へ近づきデリバリ性能が低下する
  • Accelerate（DORA調査）はWestnumの3類型（病的・官僚的・生成的）を引用し生成的文化の組織ほどデリバリ性能が高いことを示す
  • 詳細なチェックリストは形骸化し規則を守ることが目的化する文化を育てる
• 絞り込みの原則:
  • 条文数が少なく抽象度が高く自動検出比率が高いほど生成的な文化を維持しやすい
  • 「人間が読まなくても自動で回る最小の集合」に絞り込めないなら未整備のままにしておく方が健全
  • 最重要機能・品質を見極めリスクの大きさに応じてのみ詳細な条文を割り当てる
  • それ以外は原則レベルにとどめ判断の余地を残す
• アーキテクチャとの関係:
  • Accelerateが示す「疎結合なアーキテクチャ」と「分散した意思決定」は少数の高抽象条文なしには成立しない
  • チームが守るべき不変条件が明文化され自動検査されていることが分散意思決定の前提となる
  • あらゆるサブドメインへ詳細条文を網羅して押し付けることはチームが本来払うべき関心を奪う

(2026/05/05)

Product Management Summit 2026　リチェルカ登壇資料『PdMを廃止しました。』

• Product Management Summit 2026　リチェルカ登壇資料『PdMを廃止しました。』 - Speaker Deck

要約:

■ 1. 登壇者・会社概要

• 登壇者は株式会社リチェルカ共同創業者・取締役COOの幸田桃香氏
• 経歴はワークスアプリケーションズ（ERP営業）→FORCAS（SaaS営業）→AI inside（事業開発・代理店営業責任者）→HashPort（Web3.0事業マーケ・PR責任者）→リチェルカ（PM+PdM・コンサル・導入・開発）
• リチェルカは2022年4月設立・資本金約7億9500万円・「AIの社会実装を通じて今までの"できない"を解決する」をミッションとする
• 主要投資家はAngel Bridge・Genesia Ventures・NEW COMMERCE VENTURES
• 借入金融機関はみずほ・SMBC・りそな・商工中金・常陽銀行・北國銀行

■ 2. リチェルカのプロダクト戦略

• 「つくってばらまくSaaS」ではなく、顧客の業務に深く入り込んで課題を解くアプリケーションを開発する「レゴブロック型開発」を採用
• 開発フロー:
  • 顧客Aのペインを深く把握しアプリを開発する
  • 開発したモジュールを汎用化する
  • 汎用化したモジュールを顧客Bの武器として展開する
• 戦略の特徴:
  • エンタープライズの受発注領域に特化する
  • 顧客に深く入り込むほど次プロダクトの土台が積み上がる
  • 1社あたりで展開できるモジュール数（=ARR）が増加する複利構造を持つ

■ 3. PdM廃止の背景と経緯

• 創業当初（2023年〜）の開発体制は「営業→PdM→エンジニア」というリレー型であった
• PdMの役割はERPの業務フロー・ER図の整理、ユースケース作成、PRDの作成
• 従来体制の構造的問題:
  • 顧客の声とプロダクトをつなぐ役割が1職種に集中する
  • エンプラのペインは「深さ」が命であり、伝言ゲームによって希薄化する
  • 役割分担のリレー方式は後発SaaSには遅すぎる
• 2026年にPdMを廃止し、「1人1人が製品責任者」となる体制とFDEの新設へ移行

■ 4. PdM廃止後の新組織体制

• PdMという職種名を廃止し、全員がPdM・製品/機能責任者として機能する体制に移行
• 新設・再定義された役割:
  • クライアントアドバイザー: 既存プロダクトで顧客を立ち上げ、Tier管理しながらペイン抽出→開発連携を担う
  • コンサル: 大型案件で顧客視点を担い、業務理解・折衝・As-Is整理を行う
  • FDE（Forward Deployed Engineer）: エンジニア視点で仮説検証・プロト開発・要件仕様の具体化を担う
  • Application Engineer: 共通基盤の開発と各プロジェクトへの横断アサインを担う

■ 5. FDE（Forward Deployed Engineer）の定義と役割

• 定義: 「誰よりも業務を理解して、As-Is To-Beを描きながら、自分で開発し、顧客の"できない"を解決する役割」
• 必要スキル:
  • ドメイン理解力
  • 仮説構築力
  • 実装力
  • コミュニケーション力
• 他職種との差異:
  • vs PdM: 顧客課題の解決に責任を持ち、1社に深く入り込む
  • vs PM: 自分でコードを書き、モックを開発して語ることができる
  • vs Engineer: 顧客と直接話して仮説を構築できる
• FDEが担う業務範囲: プロジェクトアサイン→顧客との要件定義→プロダクト要件仕様→仮説検証→プロト開発→Application Engineer連携
• 守備範囲が広い理由:
  • 大企業と同じやり方では後発SaaSは勝てない
  • リレー型の役割分担では速度が不足する
  • 勝ち筋は「顧客の深いペインを爆速で形にすること」
  • ペインを聞く人と作る人が同一人物であるべき

■ 6. 現場における変化

• ラストワンマイル問題:
  • AIによって顧客社内でアイデアは広がっているが、組織として運用に乗せるところはほとんど進んでいない
  • 個人レベルでは個人開発・プロトタイプ・PoCが可能になった
  • 組織レベルでは共通AIの導入・業務オペレーションへの組込み・全社再現可能な仕組み・ROIが出るプロダクト化が進んでいない
  • 「個人で作れるものと、組織で回るものは別物」であり、その差を埋めるのがFDEの仕事
• WOW問題:
  • 以前はAIデモを見せるだけで顧客が驚いた
  • ChatGPT・Cursor・Copilotの普及により顧客リテラシーが向上し、WOW演出だけでは価値を出せなくなった
  • 現在の価値源泉は「業務を顧客以上に深く理解し、質の高いアウトプットを速く出せるかどうか」

■ 7. これから求められるスキル

• 求められるのは「営業力×コンサル力×開発力」の掛け算
  • 営業力: 顧客を動かす
  • コンサル力: 課題を構造化する
  • 開発力: 解決策を形にする
• スキルに関する考え方:
  • 全部できる必要はないが、何かが突出して強くなければ深いペインに届かない
  • 営業出身・エンジニア出身・コンサル出身いずれからでも活躍できる
  • 器用貧乏では深いペインに届かない
  • 自分の強みを軸に、他の領域へも「越境する意志」があるかどうかが重要

(2026/05/04)

Go開発者によるDDDの実践：概念理解から具体的な応用まで

• Go開発者によるDDDの実践：概念理解から具体的な応用まで - DMM Developers Blog

要約:

■ 1. プロジェクト概要とリプレース背景

• DMMブックスのバックオフィス向け管理画面サービス（10年以上の運用歴）において技術的負債解消を目的とした大規模リプレースを実施
• 旧構成のPHP（FuelPHP）から新構成へ移行
  • フロントエンド: React（コンポーネントベースによるUI再利用性・保守性向上）
  • バックエンド: Go（静的型付けによる安定性・保守性向上）
  • 設計手法: DDD（ドメイン駆動設計によるビジネスロジック中心の設計）
• 再構築による期待効果
  • システムの持続可能性向上（変化に強く柔軟なシステム）
  • 開発生産性向上（迅速な機能追加・改修）
  • 保守性向上（長期的な運用コスト削減）
  • 開発者体験の向上（最新技術導入によるモチベーション向上と人材確保）

■ 2. DDD導入における課題と対策

• 課題:
  • 概念と実践のギャップ: Entity・Value Object・Aggregateなどの概念をGoコードへ落とし込む具体的なイメージが掴みづらい
  • Go言語特化のノウハウ不足: Go向けDDD実装例が少なく自力での試行錯誤が必要
  • ビジネスロジックの配置判断: ドメイン層・UI層・インフラ層の境界線の引き方が難しい
• 対策:
  • 実践重視のアプローチを採用し概念の疑問をチーム内で徹底議論
  • 実装コードを必ずチームレビューし原則への適合性と改善点を多角的に検討
  • レビューを通じたチーム内知識共有でDDD実装スキルを向上
  • Go言語の特性を活かした実装方法を試行錯誤し独自のベストプラクティスを確立

■ 3. DDDの基本概念

• ドメイン:
  • ビジネスが取り組む問題領域全体（例: 商品販売・顧客管理・在庫管理・決済）
• エンティティ:
  • 一意の識別子を持つオブジェクト（例: ProductID で識別される Product 構造体）
• バリューオブジェクト:
  • 属性の値を表す不変オブジェクト（例: 金額と通貨で構成される Price 構造体）
  • コンストラクタ以外に値を変更する手段を提供しないことで不変性を保証
• アグリゲート:
  • エンティティとバリューオブジェクトの集合で一貫性の境界を形成
  • アグリゲートルートが全体を管理（例: Order がルートで OrderItem をバリューオブジェクトとして保持）
• リポジトリ:
  • アグリゲートの永続化を担うオブジェクトでデータベースアクセスを抽象化
  • インターフェースとして定義し具体的な実装はデータストアに依存
• サービス:
  • 特定のエンティティやバリューオブジェクトに属さないドメインロジックを実行（例: 注文合計金額の計算）

■ 4. DI/DIPの実装

• 依存性逆転の原則（DIP）:
  • 上位モジュールと下位モジュールの両方が抽象（インターフェース）に依存
  • 具体的な実装ではなくインターフェースに対してプログラミングすることが原則
• 依存性注入（DI）:
  • 依存オブジェクトの生成と注入を外部が担当しモジュール間の結合度を低下
• Goでの実装構成:
  • ドメイン層: UserRepository インターフェースと UserService をdomainパッケージに定義し UserService はインターフェースのみに依存
  • インフラストラクチャ層: MySQLUserRepository がインターフェースを実装しDBアクセスを担当
  • main関数: MySQLUserRepository のインスタンスを生成して UserService へ注入
• DI/DIP適用のメリット:
  • テストの容易性: モックリポジトリを注入することでDBアクセスなしにテスト可能
  • 変更への柔軟性: DBを変更する場合はインターフェース実装とmainでの注入箇所を変更するだけでドメイン層は無変更

(2026/05/04)

エラー処理の温故知新

• エラー処理の温故知新 / history of error handling technic - Speaker Deck

要約:

■ 1. 概要

• 発表者: Nakaya Ryota（株式会社ギフティ バックエンドエンジニア）
• 発表日時: 2026年05月01日 giftee TechBash
• テーマ: エラー処理の歴史的変遷と各言語の設計思想の比較

■ 2. エラーの定義と分類

• エラーの定義:
  • エラーとはプログラムの期待と現実のギャップである
  • プログラムが置いた前提や仮定が崩れた瞬間がエラーである
  • 前提は必ずどこかで崩れるためエラー処理は不可避である
• エラーの発生原因:
  • ファイルが存在しない
  • ネットワーク障害
  • 入力値の不正
  • NULLポインター
  • 型の不一致
• エラーの分類:
  • ドメインエラー: 入力値の不正 / 実行前提条件の未充足 / 認証・認可の失敗
  • 非ドメインエラー: メモリ不足（OOM） / ネットワーク障害 / NULLポインター参照

■ 3. C言語の時代 — 値としてのエラー

• C言語とUnix哲学においてエラーは「値」であり プログラムのロジックで処理するものとして扱われた
• 関数やプログラムは成功・失敗を数値で表現する（0なら正常 0以外なら異常）
• 利点:
  • シンプルな記述が可能
• 欠点:
  • 戻り値のチェックを忘れるリスクがある
  • 正常系と異常系のコードが混在する

■ 4. Exceptionの時代

• 概要:
  • C++ / Java / Python / Rubyなど現代主流の言語で採用される方式
  • 例外機構自体は以前から存在していたが 90年代の言語普及が広めた
• 利点:
  • 正常系と異常系のフローを分けて記述できる
  • 大域脱出するためチェック漏れのリスクがない
• 課題:
  • どこでどういう例外が発生するのかを関数シグネチャから把握できない
  • プログラム全体を見ないとハンドリング箇所が把握できず設計難易度が高い
  • スローされたまま誰もキャッチしない事態が生じる
  • 意図せず握りつぶされるリスクがある

■ 5. Javaの検査例外

• 概要:
  • 関数がスローしうる例外をシグネチャで明示する仕組み
  • キャッチして処理するかスローを伝播するかのどちらかを選ばないとコンパイルが通らない
  • 処理漏れをコンパイル時に防止できる
• トレードオフ:
  • 伝播コスト: 全呼び出し層でキャッチ・スローを記述する必要があり ラップしてリスローするコードが量産される
  • API変更への脆弱性: 例外の種類を増やすと呼び出し側全員がキャッチ処理を追加する必要がある
  • 高階関数やラムダ式など関数型記法との相性が悪い
  • 失敗可能性の明示と失敗からの回復可能性は別問題であるという本質的な課題がある

■ 6. Goのエラーハンドリング — 値への回帰

• 概要:
  • 2009年に登場したGoはエラーを値として返す古典的方法を意図的に選択した
  • "Errors are values" — Rob Pike の思想が基盤にある
• 設計思想:
  • 例外は使用しない（panicは回復不能な異常時のみ使用）
  • エラーは日常的な事象であり 特別な制御構造ではなく通常の値として扱う
  • 常にその場で処理するか 呼び出し元に返すかを明示する
  • 「魔法を減らせ」という哲学に基づく
• 値リターンへの回帰の理由:
  • Exceptionはシグネチャに現れず制御フローが追いにくい
  • throw元とcatch先が離れるためデバッグが困難（"Cleaner more elegant and wrong" — Raymond Chen）
  • 暗黙の大域脱出が隠れており制御フローの把握が難しい
  • ドメインエラーはロジックで処理し 非ドメインエラー（OOM / NPE）は大域脱出とする使い分けが可能
  • gotoと同様に例外だけを特別扱いする設計への疑問

■ 7. オフトピック: Clean Codeの見解

• 『Clean Code』の著者は値リターンはコードの可読性を下げるためお勧めしないと記している
• 正常系がストレートに読める方がコードの意図が掴みやすいとされる
• ただしイディオムの違いによる可読性の議論は宗教論争になりがちである

■ 8. 型によるエラー表現

• 概要:
  • Rust / Haskell / Scala / Swift / Kotlinなど近年の言語で採用される方式
  • 失敗する可能性を型システムで表現する（例: Result<String, Error>）
  • 成功値または失敗値のどちらかが返ることが型レベルで保証される
• 値としての扱い（Go）vs 型としての扱い（Rust）の違い:
  • Goの値: errを無視してもコンパイルは通り チェックは開発者の自己責任
  • Rustの型: Resultを開かないと中身を使えず コンパイラが処理を強制する
• Result型のハンドリング（Rust）:
  • matchで全パターンを網羅しないとコンパイルエラーとなる
  • Okケースのみ記述してErrを省略するとコンパイルエラー
  • 「処理し忘れ」がそもそも起こりえない構造になっている
  • 意図的に捨てることは可能（let _ = read_file();）
  • Javaの検査例外と異なり どの階層で処理するかは開発者が自由に選べる
• 型によるエラー表現の特徴:
  • うっかり無視はできないが意図的に捨てることはできる
  • Java検査例外: 各階層に「処理または宣言」を強制
  • RustのResult: 失敗の可能性を示すが どこで処理するかは自由
  • コンパイラが処理漏れを検出できる（例外より明示的）
  • エラーを合成でき関数型との相性が良い
  • 記述量が増える場合がある

■ 9. まとめ

• エラー処理の仕組みと思想は言語ごとに異なる
• 最近の言語トレンドはエラーを型で表現する方向に向かっている
• それぞれの特性を理解して正しく向き合うことが重要
• エラー処理に銀の弾丸はない

(2026/05/04)

AIが週報をつまらなくした。週報のフォーマットを大幅改訂しました

• AIが週報をつまらなくした。週報のフォーマットを大幅改訂しました｜山田裕一朗（CEO at Findy Inc.）

要約:

■ 1. 週報の目的と背景

• FindyではAI活用以前から全スタッフに週報を義務付けている
• 週報の目的は2つある
  • 経営陣が現場の解像度を維持し意思決定の質を高めること
  • メンバー個人の振り返りと成長の機会を創出すること
• 近年AI生成と判別できる週報が増加し読む価値が低下している

■ 2. AIによる週報の問題点

• AI生成週報に共通する問題点は以下の通り
  • カレンダーの予定やNotionのメモ・GitHubイシューをまとめただけの内容になっている
  • 不必要に長く読むのが困難
  • 経営が必要とする個人の考えや気づき・現場の一次情報が欠落している
• AIによる業務整理自体は問題ないが週報そのものになると読む価値がほぼなくなる

■ 3. 良い週報の共通点

• 顧客・ユーザーの生の声が含まれている
• 新技術や施策を試した体験と結果が記述されている
• これらはAIには生成不可能な書き手固有の情報である

■ 4. 新フォーマットの構成

• (1) 今週の印象的な出来事・気づき:
  • 現場でしか捉えられない一次情報として冒頭に配置する
  • ユーザーの声・商談・新技術体験など内容は問わない
• (2) 経営とマネジメントの気づき:
  • 出来事から経営・マネジメント視点での解釈を記述する
  • 「なぜ起きたか」「市場や技術として言えること」「組織・事業として何をすべきか」を問う
  • (1)と(2)についてはAIを使わず自分で書き切ることを推奨する
• (2) 数字・進捗:
  • 営業・プロダクト・エンジニアリングなど自分の仕事に紐づく数字を記載する
  • 全ての仕事に数字が存在するという認識を全員に持たせる意図がある
• (4) 個人の振り返り:
  • 今週の学びと来週の変化を短く記述する

■ 5. 改訂の目的

• 経営への効果:
  • 冒頭から現場の一次情報と思考プロセスを取得できるようにする
  • メンバーの体験と気づきを通じ経営陣の現場解像度を向上させる
• 個人成長への効果:
  • 毎週「数字」「印象的な体験」「経営・マネジメントの気づき」を問い続けることで習慣化する
  • 現場体験から気づきを引き出す能力が積み上がり長期的な成長につながる

■ 6. AIと週報に関する方針

• 業務効率化にAIを活用すること自体は推奨する
• 週報は「自分がどう考えたか」を残す場所として位置づける
• AI時代だからこそ思考の痕跡を残すアウトプットの価値は高まる
• 全員が現場体験から経営・マネジメントの気づきを発見する習慣を醸成し会社全体の意思決定の質向上を目指す

(2026/05/03)

AI時代のエンジニアに必要なパラダイムシフト － 自己否定の先にあるもの

• AI時代のエンジニアに必要なパラダイムシフト － 自己否定の先にあるもの - NRIネットコムBlog

要約:

■ 1. AIによる「知識の価値」の変容

• フレームワークの使い方・設計パターン・言語への精通・ベストプラクティスといった従来の技術知識はAIが即座に再現可能になった
• 「知っている」こと自体の価値が急速に薄れている
• ビッグテックCEOの発言がこの変化を裏付ける:
  • Google CEO Sundar Pichai: 2024年10月にGoogleの新規コードの25%以上がAI生成と発言
  • Meta CEO Mark Zuckerberg: 2025年中にミッドレベルエンジニアの仕事をAIが代替し始めると予測
  • Anthropic CEO Dario Amodei: 3〜6ヶ月以内にAIがコードの90%を書くようになると予測し同年10月にAnthropic社内での実現を述べた

■ 2. 従来のパラダイムと新しいパラダイムの対比

• 従来のパラダイム:
  • 価値の源泉: 技術力（書く・知る・解く）
  • エンジニアの役割: 手を動かす職人
  • 評価の尺度: どれだけ良いコードを書けるか
• 新しいパラダイム:
  • 価値の源泉: 課題設定力・判断力・実行力（定義する・見抜く・届ける）
  • エンジニアの役割: AIを指揮して実現する人
  • 評価の尺度: どれだけ大きな課題を解決できるか

■ 3. AI時代に価値が増す3つの力

• 課題設定力（何を作るべきかを定義する力）:
  • AIの出力品質は入力の品質に完全に依存するため問いの質が成果を決定する
  • 現場を知り人と話し判断できる人間にしかできない
  • ドメイン知識・ユーザーとの接点・技術的実現可能性の感覚・課題の構造化能力が基盤となる
• 判断力（AIの出力の良し悪しを見抜く力）:
  • AIモデルは確率的にもっともらしい出力を返す統計的機械であり正しさを保証する仕組みを内部に持たない
  • 過去の障害対応経験・ユーザー行動の観察・ステークホルダーとの会話の蓄積が判断力の土台となる
  • 判断力はレビューと方向修正に使うものであり自分で書き直す理由にしない
  • 例外として軽微な修正・AI利用コスト制約・AI障害時は自分で実装する場合もある
• 実行力（実現してユーザーに届けきる力）:
  • インフラ構成・ステークホルダーとの合意形成・障害時の判断・フィードバックによる方向転換は人間の仕事
  • 粘り強くやり抜く力・人の感情を汲み取る力・不確実な状況での責任を引き受ける力が含まれる

■ 4. 自己否定（Self-Disruption）の概念と必要性

• 「自己否定」はSelf-Disruptionの意味で使用する:
  • 競合や市場に破壊される前に自らの既存の成功モデルを能動的に壊すビジネス戦略の概念
  • NetflixがDVD事業を捨ててストリーミングに転換しAppleがiPodを潰してiPhoneを生み出した事例が代表例
• 著者が否定した信念:
  • 「自分の手で書いたコードに価値がある」→ コードの価値は誰が書いたかではなく何を解決するかで決まる
  • 「深い技術知識が優秀さの証明」→ 優秀さの尺度はAIを活用して成果を出せるかに移りつつある
  • 「AIより自分の方がうまく書ける」という判断で手を動かす習慣→ 方向修正のフィードバックとしてAIに返すべき
• 否定しなかったもの:
  • 課題設定力・判断力・実行力はむしろ価値が高まっている
  • 技術知識の活かし方を「自分で書く」から「AIの出力を横断的にレビューし方向修正する」へ再定義した
• 自己否定は一回きりのイベントではなくAIの能力進化に合わせて継続的に自分の価値を問い直す姿勢そのもの

■ 5. ローカルAIエージェントと技術進化

• オンラインAIエージェントとローカルAIエージェントの違い:
  • オンラインAI（ChatGPT・Claude Webなど）: ブラウザ・チャット画面越しに使用しハーネス・エンバイロメントは提供側に固定される
  • ローカルAI（Claude Code・Codexなど）: PC内のファイルシステムへ直接アクセスし自律的に動作する
• Claude Codeの自律性が著者の自己否定の触媒になった:
  • 「書く→動かす→失敗を見て直す」ループを人間の介在なしに回す
  • コードベース全体・プロジェクト固有の文脈を取り込んで自己修正できる
• AI活用の技術進化の変遷:
  • ～2024年頃: プロンプトエンジニアリング（どう指示を書くか）
  • 2024〜2025年頃: コンテキストエンジニアリング（RAG等で背景情報をどう教え込むか）
  • 現在以降（並列の対）:
  • ハーネスエンジニアリング: AIエージェントのランタイムをどう構成するか（パーミッション・フック・MCP・CLAUDE.md等のプロセス内設計）
  • エンバイロメントエンジニアリング: AIエージェントが動く世界をどう囲うか（OSユーザー・サンドボックス・ネットワーク制御等のプロセス外設計）

■ 6. 個人としての行動変容

• コードはAIに書かせて自分は「定義」と「判断」に集中する:
  • 課題の定義・要件の構造化・AIへの指示と出力のレビューが業務の中心になった
  • 同じ時間でカバーできる範囲が大きく広がった
• T型スキルセットから「面で動く」スタイルへ:
  • フロントエンド・バックエンド・インフラ・DB・セキュリティ全領域にAIを通じて指示を出せる理解と判断経験が必要
  • 詳細仕様知識ではなく本質を押さえた上でAIを使いこなせる経験値が求められる
• 考え込む前に作って検証するサイクルへ移行:
  • 従来: 2週間で設計を固め2週間で実装し合わなければ手戻り
  • 今後: 1時間で仮説を立ててAIに実装させ動くものを見て検証し方向転換するサイクルを1日に何度も回す
• 「自分にしかできない仕事」を問い続ける:
  • AIにできること（CRUD実装・テスト・ドキュメント・バグ調査の一報）はAIに任せる
  • 自分の時間はユーザーとの課題発見・事業戦略と技術戦略の接続・技術的意思決定のリード・障害時の最終判断に使う

■ 7. チームとマネジメントへの影響

• チーム構造の変化:
  • 従来10人で担っていたプロダクト開発を2〜3人のエンジニアがAIと協働してカバーできる
  • 少数精鋭のチームでは一人ひとりが課題設定力・判断力・実行力を高いレベルで持つ必要がある
• マネジメントの焦点の変化:
  • 工数見積・タスク割り振り・進捗管理→課題の優先順位づけ・「何をAIに任せ何を人間がやるか」の設計・アウトプットの品質レビューへ移行する
• 評価基準の再定義:
  • コード量・コミット数・資格数による評価は不十分になる
  • 新しい評価基準: インパクトある課題の定義・AIの出力の品質担保・仮説検証の速さ・チームのAI活用レベルへの貢献
• ジュニアエンジニア育成の課題:
  • AIがジュニアレベルのタスクをこなすようになると経験を積む機会が減るという構造的課題がある
  • 「AIが書いたコードをレビューすること自体を学習の場にする」アプローチが判断力育成に有効な可能性がある
  • コードそのものよりも判断の根拠を共有するチーム文化が従来以上に重要になる

■ 8. AIには決められない「何を実現すべきか」

• AIはコードの速度・品質で人間を上回る場面が多いが「何を実現すべきか」を自分では決められない
• 課題設定力で良い問いを立て・判断力で出力を正しく見極め・実行力で届けきる人間がAI時代に最も価値を持つ
• AIが実装を担うことでエンジニアは「何を作るべきか」「なぜ作るのか」「本当にユーザーの課題を解決できているか」というより本質的な仕事に集中できる
• 自己否定とは立ち止まることではなく自分が積み上げてきたものを見つめ直し変化すべき部分を見極めて次に進むこと

(2026/05/02)

品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み

• 品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み - LayerX エンジニアブログ

要約:

■ 1. 概要

• LayerX QAエンジニアによるClaude Code Agent Skillsを活用した品質管理の取り組みの紹介
• AIコーディングアシスタントの普及に伴い「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」という課題が発生
• バクラク事業部の品質定義・テスト戦略を言語化しClaude Codeにリスクの高い箇所を保護させテストを同時生成させる試みを実施

■ 2. 早期テストの原則

• JSTQB FLシラバスに定義されるテストの原則の1つ「早期テストで時間とコストを節約する」を基盤とする
• プロセスの早い段階で欠陥を取り除くことで後半に発生する故障が減少し品質コストが削減される
• テスト実行のみならず要件レビューや質問といった活動も含む
• 欠陥の予防が最もコスパが高くアジャイル開発とも親和性が高い
• この原則をClaude Codeの動作に適用することを目指す

■ 3. Skillsに組み込む判断基準

• AIによる予防を実現するため以下の3つの判断基準を言語化:
  • 目指す品質
  • 目指す品質を判断するためのリスクと基準
  • 自動テストのスコープ
• 上記定義によりAIが以下を思考・実行可能になる:
  • 今目指すべき品質のゴールの把握
  • 今守るべきリスクの特定
  • リスクに応じた実装基準の決定
  • 各自動テストで担保すべきスコープの特定

■ 4. 判断基準の言語化

• 目指す品質:
  • バクラクはセンシティブな情報を預かるプロダクト群であり一定以上の品質水準の維持が必要
  • プロダクトのフェーズごとに「バクラク事業部が目指す品質」を定義
  • 市場へのリリースでフィードバックを集めるフェーズと運用中フェーズで優先すべき品質の側面が異なる
• リスクと基準:
  • バクラク事業部ではコンパウンド戦略を採用し複数プロダクトそれぞれに固有のリスクが存在
  • severityの度合いとその影響範囲をまとめたリスク情報をプロダクトごとにskills上で定義
  • 特定期間ごとにチームでリスク定義をアップデートする習慣が社内に確立済み
  • リスク情報に基づきカバレッジの基準を決定
• 自動テストのスコープ:
  • テストピラミッド戦略として自動テストの各レイヤーで検証すべき内容をLayerX社内で定義済み

■ 5. Claude Codeへの統合と動作

• 言語化した情報をClaude Code Agent Skillsとして実装
• フェーズ判断:
  • タスク内容からプロダクトのフェーズを判断
  • 不明な場合はHITL(Human In The Loop)でユーザーに質問
• リスク評価:
  • 機能カテゴリを参照しリスクレベルを評価
  • compaction(コンテキスト肥大化・圧縮による精度低下)防止のため開発対象プロダクトのリスク情報のみを読み込む設計
• 基準の適用:
  • 判断したフェーズとリスクレベルに基づき実装方針・テスト戦略(カバレッジ目標)・コーディング規約を自動適用
• 用途は製品開発のみならずテスト計画・設計・自動テスト整備相談にも対応

■ 6. 実施結果

• skill-creatorのEvalsを使って効果測定を実施し改善効果を確認
• リスクが高い機能開発:
  • Claude Codeが自らリスクの高さを判断しトランザクション管理・ロールバック処理を含む堅牢なコードを生成
  • 定義した基準のユニットテストカバレッジを達成
• テストカバレッジの比較:
  • スキルなし: 65%
  • スキルあり: 95%

■ 7. 結論

• AIがコードを書く時代において人間の役割は「あるべき姿を定義(言語化)すること」へシフト
• 暗黙知になっている品質の姿を言語化しAIに組み込むことでQuality Harnessとして機能させフィードバックループを加速可能
• モデル性能向上に伴いスピードと質が向上する世界において品質のポイントを押さえることの重要性を強調

(2026/05/02)

「Copy Fail」CVE-2026-31431 — 9年間潜んでいた732バイトPythonでLinuxがroot化される脆弱性と対策

• 「Copy Fail」CVE-2026-31431 — 9年間潜んでいた732バイトPythonでLinuxがroot化される脆弱性と対策｜zephel01

要約:

■ 1. 脆弱性の概要

• 名称はCVE-2026-31431（通称「Copy Fail」）
• 2017年以降のほぼすべての主要Linuxディストリビューションに影響するローカル権限昇格の脆弱性
• 732バイトのPythonスクリプト一つでroot権限を取得可能
• 2017年のカーネルコミット導入から9年間発見されずに潜伏していた

■ 2. 技術的詳細

• 原因:
  • Linuxカーネルのcryptoモジュール（algif_aead）に2017年追加された「in-place最適化」のロジックバグ
• 攻撃手法:
  • AF_ALGソケットとsplice()を組み合わせ、任意の読み取り可能ファイルのpage cache（メモリ内キャッシュ）に4バイトを任意に書き換える
  • /usr/bin/suなどのsetuidバイナリをメモリ内で書き換えることでroot権限を即座に取得する
• 特徴:
  • ディスクへの書き込みが一切ないため再起動で自然に元の状態に戻る
  • race conditionやアドレスリークが不要
  • Ubuntu・RHEL・Amazon Linuxなど複数ディストリビューションで同一スクリプトが動作する
  • リモートからの直接攻撃は不可だが他の脆弱性と組み合わせた場合に深刻化する

■ 3. 影響範囲

• 対象環境:
  • 脆弱なコミット（72548b093ee3）導入以降の全主要Linuxカーネル（Ubuntu・Debian・RHEL・Fedora・Amazon Linux・SUSE・Archなど）
  • 4.14以前の旧カーネルは対象外
• 脆弱なバージョン（系列別の上限）:
  • 5.10系列：5.10.254未満
  • 5.15系列：5.15.204未満
  • 6.1系列：6.1.170未満
  • 6.6系列：6.6.137未満
  • 6.12系列：6.12.85未満
  • 6.18系列：6.18.22未満
  • 6.19系列：6.19.12未満
• 特に危険な環境:
  • 共有サーバー
  • Kubernetesコンテナ（page cache共有によるホスト脱出が可能）
  • CI/CDランナー（GitHub Actionsなど）
  • クラウドのサンドボックス環境

■ 4. コミュニティの反応

• X（旧Twitter）での状況:
  • 元投稿が数万ビューを超えvx-undergroundなど著名アカウントが拡散
  • 「732バイトで全ディストリ即root」「9年間潜伏したバグが怖い」「AIが発見したのが衝撃」という声が多数
  • 3000台規模での即時mitigation実施報告やコンテナ環境での危険性を指摘する実務報告が相次ぐ
• Reddit（r/linux・r/sysadmin・r/homelab・r/Proxmoxなど）での状況:
  • Ubuntu 24.04でのPoC実行によりsuが実際に書き換わったという報告が殺到
  • 共有ホスト・K8s・CI/CD環境での深刻性を指摘する声が目立つ
  • CVSS 7.8に対するModerate評価の妥当性に疑問を呈する議論も発生
  • algif_aead無効化コマンドのワークアラウンドが広く共有される

■ 5. 修正状況

• 修正コミット：a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5（crypto: algif_aead - Revert to operating out-of-place）
• mainlineでは7.0-rc7以降に取り込み済み
• 各ディストリビューションで2026年4月29〜30日時点からバックポートが順次提供開始

■ 6. 対策

• 最優先：カーネル更新:
  • パッチコミットa664bf3d603dが含まれるカーネルへ更新する
  • Ubuntu/Debian系：sudo apt update && sudo apt upgrade linux-image-$(uname -r)
  • RHEL/Fedora/Amazon Linux系：sudo dnf update kernel
  • 更新後に再起動しuname -rでバージョンを確認する
• 緊急ワークアラウンド（パッチ未適用時）:
  • algif_aead モジュールを無効化する
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
  • dm-cryptやIPsecなどの通常利用への影響はほぼない
• 追加対策（コンテナ・CI環境推奨）:
  • seccompフィルタでAF_ALGソケット作成をブロックする
  • unprivileged user namespaceを無効化する（sysctl -w user.max_user_namespaces=0）

(2026/05/01)

Before GitHub

• Before GitHub | Armin Ronacher's Thoughts and Writings

要約:

■ 1. GitHub以前のオープンソースの姿

• SourceForge・Trac・Subversionが主要な開発基盤であり 開発者自身がサーバを運用するのが通常であった
• プロジェクトには固有のウェブサイト・メーリングリスト・リリースプロセスがあり 依存関係の追加には相当な調査と理解が伴った
• 評判と実績が信頼の基準として機能し 長期にわたるメンテナンスの継続が重視された
• 小規模プロジェクトは大学サーバや共有インフラ上に置かれ 大規模プロジェクトは自前のインフラを維持するか複数プロジェクトが連合して運用コストを分担した
• MercurialやGitの登場により分散型バージョン管理が普及したが 皮肉にも一極集中型のGitHubが標準プラットフォームとなった

■ 2. GitHubがオープンソースにもたらしたもの

• プロジェクトの作成・発見・コントリビューションの障壁を大幅に引き下げた
• イシュートラッカー・プルリクエスト・CI・Webhook・APIなどの開発インフラを一元提供した
• オープンな開発履歴と可視化されたコラボレーションを業界標準として定着させた
• 放棄されたプロジェクトを含む膨大なコードを検索可能な状態で保存する事実上のアーカイブとして機能した
• 制裁対象国へのアクセス維持に尽力するなど 歴史的には開放的な姿勢を示した

■ 3. 依存関係の爆発的増加とその問題

• GitHubとnpmの組み合わせにより コードの公開・消費・依存が事実上コストゼロになった
• GitHub以前は依存関係の選択において評判・寿命・ベンダリングが自然なフィルタとして機能していた
• マイクロ依存関係の急増により パッケージグラフが人間の把握能力を超えて拡大した
• GitHubはnpmなどのレジストリへの信頼できる公開経路としても機能するようになり サプライチェーン文化の中核を担った
• GitHubへの信頼が低下することはソースホスティングだけでなくサプライチェーン全体に影響を及ぼす

■ 4. GitHubの衰退と分散化の動き

• 現在のGitHubはCopilot AIによるノイズ・製品の迷走・不明確なリーダーシップ・コミュニティ軽視への批判に直面している
• エージェント型コーディングの台頭が組織に大きな圧力をかける一方でリーダーシップが不在の状態にある
• GhosttyのMitchell Hashimotoら影響力のある開発者がGitHubからの移行を表明し始めている
• StrudelやTenacityはCodebergへ移行しており 非GitHubプロパティへの訪問頻度が著者自身にも増加している
• Gitはもともと多数の拠点を想定して設計されており 単一企業への依存はGitの設計思想に反する

■ 5. 分散化のコストとアーカイブの必要性

• 分散化の進展はプロジェクトの自律性を回復し 特定企業の意思決定への依存を減らす
• 一方でコード以外の社会的文脈(イシュー・レビュー・設計議論・リリースノート・セキュリティ情報)は分散環境で失われやすい
• メーリングリストは現代のOSSニーズに対応できておらず代替としての機能を果たしていない
• 公的資金または寄付基金によって維持される中立的なOSSアーカイブ機関の設立が必要である
• アーカイブの目的は開発者生産性市場の獲得ではなく ソース・リリース成果物・メタデータ・プロジェクト文脈の永続的保存に限定すべきである
• Google CodeやBitbucketの前例が示すように 一企業への依存が終わった後にアーカイブ機能が自然発生することは期待できない
• 次世代のプラットフォームはプロジェクトの移行容易性・社会的文脈のミラーリング・リリース保存の堅牢性を設計原則とすべきである

(2026/04/30)

人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話

• 人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話 | Acsim

(2026/04/29)

はてな株に売り殺到、終日値付かず　“11億円流出”ショックで

• はてな株に売り殺到、終日値付かず　“11億円流出”ショックで - ITmedia NEWS

ブログサービスなどを運営するはてな（京都市中京区／東証グロース）の株価が4月27日、値幅制限の下限（ストップ安）水準の881円で売り気配のまま推移し、終日値が付かなかった。同社が前週末に発表した、不正な送金指示による最大約11億円の資金流出事案が嫌気された。

前週末24日の終値は1181円で、27日のストップ安水準は300円安の881円。同日は寄り付きから売り注文が積み上がり、買いが追いつかなかった。

売り材料となったのは、24日に開示した資金流出事案だ。4月20日と21日、悪意ある第三者から虚偽の送金指示に従い、従業員のアカウントから銀行預金を外部の口座に送金していた。

同社の2026年7月期通期業績予想は、売上高38億5900万円、営業利益1億3600万円。最大被害額は、通期営業利益予想の約8倍に相当する規模だ。

同社は手元の運転資金について「十分な流動性を確保しており、事業運営や資金繰りに支障はない」と説明。業績への影響は「精査中」としている。

MEMO:

• はてながこの先生きのこるには

(2026/04/28)

hotchpotch/sqlite-vaporetto: SQLite FTS5 extension for fast Japanese full-text search

• GitHub - hotchpotch/sqlite-vaporetto: SQLite FTS5 extension for fast Japanese full-text search with 🛥Vaporetto / Vaporetto による高速な日本語全文検索を SQLite FTS5 で実現する拡張機能 · GitHub

Vaporetto を利用した、SQLite 向けの高速な日本語全文検索拡張です。

sqlite-vaporetto は FTS5 用の SQLite loadable extension です。 vaporetto という tokenizer を追加し、SQLite が index する前に日本語テキストを検索に適した単語へ分割します。

SQLite の FTS5 は小さくポータブルな全文検索エンジンで、Vaporetto は高速な日本語 tokenizer です。sqlite-vaporetto はこの 2 つを組み合わせ、通常の SQLite database の中で、単語単位の日本語 tokenization、ASCII の大文字小文字を区別しない検索、MATCH query、bm25() ranking、highlight() を使えるようにします。

(2026/04/28)

「FILCO」のダイヤテック閉業、予兆はあった？ ファンアカウントが見たここ半年の「異常な動き」とは

• 「FILCO」のダイヤテック閉業、予兆はあった？ ファンアカウントが見たここ半年の「異常な動き」とは【やじうまWatch】 - INTERNET Watch

FILCOブランドで知られたダイヤテック社の突然の閉業について、この半年間にみられた同社の異常な動きを、ファンアカウントが動画でまとめている。

4月22日にホームページ上で突如発表された同社の事業終了は驚きを持って迎えられたが、詳しい理由やブランドの今後などについては触れられておらず、すべてが謎のまま。そんな同社について、ファンアカウントであるYouTubeの「勝手にFILCOコレクション」が、昨年からの同社の異常な動きについてまとめている。

それによると、同社は昨年後半からこれまでにないほどの破格のセールを連発し、年明けには「単位がおかしい、価格がおかしい」と銘打った在庫一掃セールを実施。それらが一区切りついた2月にはYahooダイレクト店がリニューアルと告知しつつ事実上の閉店。また、ダイレクトショップは3月に入ってから在庫が枯渇し、3月18日にはメンテナンスの告知が掲載されるも以後改善されることなく、4月中頃にはサポートページのお問い合わせフォームが閉鎖され、今回の事業終了の発表に至ったとしている。このほか、ほぼ毎日行われていた公式Xアカウントの投稿も3月6日を最後に中断しており、同社の動きを注意深く観察していれば何かが起きていると分かる予兆はあったようだ。

関連:

• 「FILCO」「Majestouch」のダイヤテックが閉業

(2026/04/27)

COBOL技術者に汎用機の話を聞いて「え、全然汎用じゃないじゃん。どちらかというと専用機...

COBOL技術者に汎用機の話を聞いて

「え、全然汎用じゃないじゃん。どちらかというと専用機に近い（Win、Linuxのオープン系と比較した場合）」

って言ったら

「おまえ全然わかってない。汎用の意味を」

と言われたから

「例えば自分はPerlでCPANモジュール読み込んでサクッとWebサーバ作れますよ？COBOLでできますか？」

と言ったら

「Webサーバ？何だそれは？っていうかCOBOLはPerlではない。Perlの話を持ち出すな」

と否定するばかりで理解しようとせずに自分の中の「汎用」を無意識のうちに守りに入っていた

25年前のIT業界はこういうタイプの人が大量に先輩として存在していた

@ebiebi_pg

MEMO:

• COBOLが動作する汎用機/メインフレームというのは、それ以前のコンピュータが特定用途の計算に特化した専用機であったことへのセールスポイントとしてプログラムを交換するだけであらゆる用途の計算ができる（汎用計算機）ということ
• WindowsやLinuxはその汎用機の更に進化版（かつ廉価版）
• パイセンはその程度はサラッと答えて欲しいところである

(2026/04/26)

ハーネスエンジニアリングとは？

• ハーネスエンジニアリングとは？ - Speaker Deck

要約:

■ 1. 概要

• 本資料はKinopee（きのぴー）による「ハーネスエンジニアリングとは何か」をテーマとした発表スライドである（2026年4月24日）
• ハーネスエンジニアリングという概念には複数の流派が存在し、論者によって定義と重心が異なる
• 資料はハーネスエンジニアリングの5つの流派の整理と、ハーネス・ガードレール・フィードバックループの実践的解説の2部構成をとる

■ 2. ハーネスエンジニアリング 5つの流派

• Chase派（広義・分類論）:
  • 代表者はHarrison Chase（LangChain創業者）
  • 出典は2025年10月のブログ記事「Agent Frameworks, Runtimes, and Harnesses」
  • 原器はDeepAgents（LangChain）
  • framework / runtime / harness の三分類を提示し、モデル以外のすべての構成要素（ツール・メモリ・サブエージェント・ガードレール・オーケストレーション・リトライ・状態管理）をハーネスに包含する
  • ハーネスは「コンテキストを生成する外側の層」であり、コンテキスト設計はその一構成要素として位置づけられる
  • 代表フレーズは「If you're not the model, you're the harness.」（Vivek Trivedy）
• Hashimoto派（運用哲学・失敗駆動）:
  • 代表者はMitchell Hashimoto（HashiCorp創業者）
  • 出典は2026年2月の自身のブログ記事で、OpenAI Codex事例と合わせて急速に普及
  • 原器はAGENTS.md / CLAUDE.md / .cursorrules
  • エージェントが失敗した際に同じミスが物理的に発生しないよう環境を再設計することを基本原則とする
  • AGENTS.mdに失敗防止ルールを一行ずつ追加していく「運用の累積」がハーネスエンジニアリングの実体である
  • ハーネスは設計物ではなく育てていくプロセスとして捉える
  • 日本の.cursorrules運用者と地続きであり、現場感覚に最も近い流派とされる
  • サイクルは「実行→失敗→AGENTS.mdへの追記→再発不能」の繰り返しである
• Fowler派（狭義ハーネス・制御理論）:
  • 代表者はMartin Fowler（Thoughtworks Distinguished Engineer）
  • 出典は2026年のThoughtworks記事「Harness engineering for coding agent users」
  • 原器はClaude Code / Cursor / Devinなどコーディングエージェント全般
  • 5流派の中で唯一、ハーネスをコンテキストの内側（特殊形）に位置づける
  • guides（feedforward制御：事前ルール・制約）とsensors（feedback制御：テスト・lint・事後検証）の両輪でエージェントを信頼に足るものにする
  • 「不要な出力を事前に防ぐ仕組み」と「逸脱を検知して自己修正させる仕組み」の組み合わせとして定義する
  • 制御工学の語彙（フィードバックループ・センサー）に接続する理論志向をとる
  • 代表フレーズは「ハーネス設計はコンテキスト設計の特殊な一形態である」
• Chawla派（同心円モデル・OS比喩）:
  • 代表者はAvi Chawla（Daily Dose of DS）および教育系ライター群
  • 出典は2026年前半「The Anatomy of an Agent Harness」ほか
  • 原器は特定ツールではなく概念モデル
  • プロンプト・コンテキスト・ハーネスを三重の同心円で整理する
  • Beren Millidge（2023）のOS比喩を継承し、LLMをCPU・コンテキストをRAM・ツールをデバイスドライバ・ハーネスをOSに対応させる
  • 定義の厳密さより初学者への説明しやすさを優先する立場をとる
  • Chase派と論理的には整合的だが、より図解寄り・入門記事向きの位置づけである
  • 代表フレーズは「LLMはOSなしの裸のCPUだ。ハーネスがOSに当たる。」（Beren Millidge）
• Codex派（スケール駆動・プロダクション答え）:
  • 代表者はRyan Lopopolo / OpenAI Codexチーム
  • 出典は2026年2月のOpenAI事例公表（エンジニア3名で百万行・95%AI生成）
  • 原器はOpenAI Codexおよびその内部ハーネス
  • プロンプト・コンテキスト設計では解決できない、多段ステップ・自律実行・並列処理に特有の故障モードが存在することを前提とする
  • それらの故障モードを解くものとしてハーネスを定義する（スケール駆動の動機づけ）
  • 他流派と直接対立せず、ハーネス概念が要請された背景と理由を提供する立場をとる
  • Prompt Engineering（2022年〜）→ Context Engineering（2024年〜）→ Harness Engineering（2026年〜）という進化の文脈で位置づける
  • 代表フレーズは「Agents aren't hard; the Harness is hard.」（Ryan Lopopolo）

■ 3. 流派間の対立構造

• 包含関係の逆転が流派間で最も劇的な噛み合わなさを生む
• Chase派・Chawla派の立場:
  • ハーネス ⊃ コンテキスト（ハーネスが外層、コンテキストを包含する）
  • 総合フレームワーク設計の視点
• Fowler派の立場:
  • コンテキスト ⊃ ハーネス（コンテキスト設計が外層、ハーネスはその特殊形）
  • 制御理論（feedforward / feedback）の視点
• 日本に紹介する際は、どちらの意味で語られているかを毎回明示する必要がある

■ 4. ハーネスとガードレールの定義

• ハーネス（馬具）:
  • 役割は走り出す前に「どう走ってほしいか」を伝える事前設計の層
  • 具体的な道具はカスタムインストラクション・プラン・Skills・サブエージェント
  • ハーネスは主観的な設計物であり、現場では名称がつく前から実践されてきた
• ガードレール（道を外れないための柵）:
  • 役割は走った後に「道から外れていないか」を機械で自動検証する事後検証の層
  • 具体的な仕組みは静的解析（lint・型チェック）・ビルド・テスト
  • ガードレールは客観的な機械判定であり、判定の強度がエージェントの自律性を高める鍵となる

■ 5. フィードバックループ

• ハーネス（馬具）とガードレール（柵）だけでは、エージェントは目的地にたどり着けない
• ループの構造:
  • 走らせる（エージェントにタスクをやらせる）
  • 逸脱を観察（期待からのズレを検知する）
  • 軌道を戻す（失敗を受けて修正・再実行する）
  • 上記を繰り返す
• 具体的な適用:
  • テストが落ちたら直させる
  • lintが出たら修正させる
  • 型が通らなければやり直させる

■ 6. 結論

• 言葉の定義の優先順位は低い
• 大切なのは期待した結果を得ることである
• ハーネス・ガードレール・フィードバックループのいずれも、今使える手段を総動員して適切な場所で適切に使い、良い結果を得ることが目的である

(2026/04/26)

再委託先ガバナンスの限界——IPA・ストーンビート指名停止が突きつけた「契約では守れない」時代

• 再委託先ガバナンスの限界——IPA・ストーンビート指名停止が突きつけた「契約では守れない」時代｜Vlightup | デジタルとリアルを繋ぐ、新しい信頼のカタチ -ブライトアップ株式会社

要約:

■ 1. 事件の概要

• 2026年4月10日、内閣官房が独立行政法人情報処理推進機構（IPA）に対し指名停止措置を公表
• 指名停止期間は2026年4月10日から同年9月9日までの5ヶ月間
• 対象契約は「令和7年度 独立行政法人等に対する監査業務の委託」
• 再委託先であるストーンビートセキュリティ株式会社が契約違反行為を行い、業務の一部について履行義務を果たさなかったことが「不誠実な行為」と認定されたことが原因

■ 2. 問題の構造

• 再委託先の管理:
  • IPAは内閣官房から受託した業務をストーンビートセキュリティ株式会社に再委託
  • 再委託先の契約違反が元請であるIPAの指名停止に直結
• 構造的矛盾:
  • IPAはセキュリティ分野の統括・監督機関であるにもかかわらず、自らがガバナンス上の問題に直面
  • 政府機関の監査業務という重要領域で管理体制の不備が露呈

■ 3. 本事件が示す課題

• 再委託先ガバナンスの限界:
  • 契約上の義務を課すだけでは再委託先の不誠実な行為を防止できない
  • 契約管理の複雑性と実際の業務遂行における乖離が顕在化
• 時代的示唆:
  • 「契約では守れない時代」という認識のもと、契約に依存しない新たなガバナンス手法の必要性が浮上
  • 企業グループ・委託チェーン全体での実効的な管理体制の構築が課題

(2026/04/25)

〇〇の人と言われたくて〇〇の人になった

• 〇〇の人と言われたくて〇〇の人になった

エンジニア界隈のイベントで、特定のOSSや手法をもって「〇〇の人」と呼ばれている人に強い憧れを持っていた。

自分もあるプロダクトのエバンジェリストとして小さな周辺の界隈ではあるが活動を続けて少しずつ「〇〇の人ですよね」と話しかけられる事が増えてきた。

憧れの「〇〇の人」が集まるようなカンファレンスにも呼ばれたりして「自分も憧れのネームドの仲間入りかな」と浮かれていた部分も正直かなりあった。

でも実態は違った。

実際会って話せるようになってみると、その「〇〇の人」達は技術に興味がない事がほとんど。

違う飲み会に行けば裏で「まあ、あの人はあぁいう人だから…」「上手く使えばイベントやってくれる」みたいに言われている。

ネームドではないけど技術力や仕事力がある人、ネームドだけど技術力や仕事力がある人、そこに割合の違いは無かったんだと気付いた。

で、自分もこのままじゃヤバいかもと転職エージェントに相談してみたんだけど「〇〇の人なんでその求人ですよね」という前提で話される。

話しても「もったいないですよ」と理解してもらえず、人生詰んでる。

絶対に外では言えないけど、正直プロダクトとして廃れて無かったことになってほしい。

みんなは、俺みたいなやつが二度と生まれないよう、後輩に現実を早く突き付けてあげて欲しい。

MEMO:

• 「〇〇の人」になれたのに転職エージェント使わなきゃいけないの侘しさある
• 〇〇界隈の企業からは声が掛からなかったのか
• みたいな事を思わなくもないが、この増田は高確率で嘘松
• 登壇経験があればGreenみたいな転職サイトに登録しておけばうんざりするほど企業からのスカウトが来る
• それに、あるプロダクトのエバンジェリストが別のプロダクトに乗り換えることは普通のこと
• 他人の過去なんて誰も気にしない
• 転職エージェントは所詮他人なので理解してもらえないなら別のエージェントに乗り換えるだけの話なので詰むという発想自体がおかしい
• ということで、創作増田であろう

(2026/04/25)

内閣官房から指名停止のIPA、再委託先デロイト傘下の不正な行為見つける

• 内閣官房から指名停止のIPA、再委託先デロイト傘下の不正な行為見つける | 日経クロステック（xTECH）

内閣官房が2026年4月に公表した指名停止措置の対象に、情報処理推進機構（IPA）の名があることがSNS（交流サイト）などで話題になっている。IPAが再委託先の契約違反行為を把握し、国家サイバー統括室へ報告したことが発端だった。委託先選定の難しさが浮き彫りになった。

MEMO:

• どういうことなのか？
• 詳細はペイウォールの向こうなので確認できず

(2026/04/25)

はてな、11億円の資金流出　振り込め詐欺か

• はてな、11億円の資金流出　振り込め詐欺か - ITmedia NEWS

インターネット関連事業を手掛けるはてな（京都市中京区）は4月24日、不正な送金指示によって約11億円の資金が銀行口座から流出したと公表した。第三者から虚偽の送金指示があったという。

4月21日に取引先銀行から不審な送金が行われていると連絡があり、確認すると4月20日と21日にある従業員のアカウントから銀行預金を外部の口座へ送金していた。その従業員に確認したところ、悪意ある第三者から虚偽の送金指示があったことが分かった。

はてなは、捜査機関へ全面的に協力するとともに、関係金融機関と被害回復に向けた措置を講じている。社内にも来栖義臣社長を中心とする対策本部を設け、外部の弁護士なども交えて事実関係の調査を進めるという。

なお、この事案に関連して個人情報や顧客情報の流出は24日時点で確認されていない。はてなの運転資金についても十分な流動性を確保しており、事業運営や資金繰りに支障はないとしている。

はてなは関係者や株主に謝罪。「本事案を極めて厳粛に受け止め、捜査へ全面的に協力するとともに、外部専門家を交えた事実関係の詳細な調査および原因の究明、再発防止策の策定を迅速に進める」としている。

MEMO:

• 11億円の振り込みを役員決済もなく従業員の独断で行えるものなのか？
• 従業員の横領がバレただけなのでは？

(2026/04/25)

Metaが、社員の1割である8,000人をクビにすると発表したが、残った社員のパソコンに、新しいソフト...

• Metaが、社員の1割である8,000人をクビにすると発表したが、残った社員のパソコンに、新しいソフトを入れ始め、社員のマウスやキーボードの動きを記録し、画面の中身も、ときどきスクショで取り、AIに学習させていた - posfie

もう少しかみ砕く。

たとえば、社員がメールを書いているとする。

どのキーを、どの順番で叩いているか。

マウスをどこに動かし、どのボタンをクリックしたか。

画面にどんな情報が映っていたか。

これらが、社員のパソコンから吸い上げられる。

そのデータを、会社のAIが受け取る。

じっと見て、学んでいく。

人間はこの仕事を、こう進めているのか、と。

それを毎日、大勢の社員ぶん、同時に繰り返す。

MEMO:

• 社員のアウトプットは企業が正当な権利として利用できるのだからAIの学習の為にキーロガーは必要無いような
• ただの監視では？

(2026/04/25)

「FILCO」「Majestouch」のダイヤテックが閉業

• 「FILCO」「Majestouch」のダイヤテックが閉業 - PC Watch

FILCOブランドのキーボード製品などで知られるダイヤテック株式会社が4月22日をもって事業を終了した。現時点で閉業の理由については明らかにしていない。

ダイヤテックは1982年に設立。自社ブランドのFILCOを展開し、「Majestouch」シリーズをはじめとしたキーボードや周辺機器などの製造/販売を行なっていた。

なお、閉業にともなって、通販やサポートの業務で取得/保有していた個人情報は、4月22日までに個人情報保護法や社内規定などに基づき、適切な方法で安全に破棄/消去したと説明している。

MEMO:

• なんてことだ
• とはいえ、メカニカルキーボード市場はそんな大きくも無いし苦しかったのだろうという事は伺える
• 自分も10年前に購入したFILCOのMajestouch青軸を未だに使っているぐらいなので、買い替え需要も起きにくい商品でもある

(2026/04/25)

なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？

• なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？

要約:

■ 1. UMLの起源と制度的背景

• UMLはラショナルソフトウェアが主導した標準化プロジェクトとして誕生した
• ブーチ法・OOSE・OMTなど複数の方法論を統一するための記法として設計された
• 当初から業務分析・要求管理・設計・実装・テストをまたぐ共通表現として位置付けられた
• 2003年にIBMがラショナルを買収しUMLはプロセス・製品・教育・監査・成熟度まで背負う存在となった
• この経緯により「UML」という語は重厚長大な印象と不可分に結びついた

■ 2. ファウラーによるUMLの再解釈

• ファウラーはUMLの使い方をスケッチ・ブループリント・プログラミング言語の三種に分類した
• 2000年代に「重いUML」として販売されていた本丸はブループリント用途であった:
  • 図を完全な設計書とし実装者がそれを機械的にコードへ写し取る立場
  • 設計者と実装者を分離しモデルから実装まで一気通貫で支配しようとする発想
• ファウラー自身はブループリント的立場を否定しスケッチを重視した:
  • 図は完全な仕様書ではなく重要な点だけを伝える会話道具である
  • 「網羅性は理解しやすさの敵」という立場を明言した
  • 役目を果たした図は捨ててよいと述べた
• ファウラーはコードを主文書と位置付けた:
  • コードのみが十分に詳細かつ正確である
  • 図はコードの理解や対話を助ける補助線にすぎない

■ 3. 2000年代の実務における実態

• 表向きの礼賛と実際の運用の間には当初から温度差があった
• 2007年調査ではUML使用率は52%にとどまり一様ではなかった:
  • モデリングツールは主に初期設計で使用された
  • コード生成は広く使われていなかった
• 問題点として図の品質・非形式的利用・モデリング規約の欠如が挙げられた
• 多くの現場は最初からクラス図やシーケンス図の一部のみを使い残りはフリーハンドの図で済ませていた
• UMLは「看板だけ巨大で実務は最初から部分利用」であったと見るのが実態に近い

■ 4. MDA(モデル駆動アーキテクチャ)の失敗

• MDAはプラットフォーム非依存モデルから実装コードまでを自動生成する構想であった
• UML制度の最大の約束手形は「図を正しく描けばコードは自動的に出てくる」であった
• 2007年調査が示した通り現場ではコード生成はほとんど使われなかった:
  • 生成されるのは骨組みだけで振る舞いは人間が記述する必要があった
  • 生成コードを手で修正するとモデルとの同期が崩れ二重管理が常態化した
• MDAの失敗はCASEツール・RUP・監査向け成果物・モデル中心教育の正当化根拠を根元から失わせた

■ 5. 2010年代の技術環境の変化とアジャイルの定着

• 変更速度を引き上げた三方向からの圧力が同時に加わった:
  • 供給側: AWS S3(2006年)を起点とするクラウドが環境調達の待ち時間を縮め小刻みな試行を可能にした
  • 需要側: iPhone(2007年)がモバイル対応を必須化しアプリストア・OS更新を通じて短い更新周期を市場から要求した
  • 運用基盤側: JenkinsによるCI/CDとGitHubを介したコードレビュー文化がコードの変更と検証を日次レベルで回す基盤を確立した
• アジャイルが能動的に勝ったのではなく市場と技術基盤の側がアジャイルの前提条件を満たした
• 2014年のState of Agile調査では回答者の90%が1年以上のアジャイル経験を持ち採用理由の上位は製品提供の加速・優先順位変更への対応・生産性向上であった
• 同調査でアジャイル案件の管理にMicrosoft Excelが68%使用されIBM Rationalは13%にとどまった

■ 6. UML制度の死の本質

• 死んだのは図そのものではなくUMLという制度である:
  • 図を完全な設計書にし設計者と実装者を分けモデルから実装まで支配しようとする発想が死んだ
• 二重管理は手間の増加ではなく情報の腐敗構造である:
  • コードが変わるたびに図を直す義務が生まれる
  • 直されなかった図は残り続け嘘をつき始める
  • 変更速度が上がるほど図の腐敗速度も上がる
  • 腐った図はないよりも悪い情報源であり新しい図を描く動機まで奪う
• 2010年代にUMLが聞かれなくなったのは図法が間違っていたからではなく維持費が便益を上回ったからである
• 「UML」という語がCASEツール・RUP・MDA・監査文化を連想させる重い語彙になったため現場が軽量化に向かうほど語自体が敬遠された

■ 7. UML制度が死んだ領域と生き残った領域

• UML制度の死は変更速度の高い領域に限定された現象である
• 機能安全・認証が絡む領域ではUMLの系譜は必須の位置を占めている:
  • 自動車組込み: ISO 26262
  • 航空: DO-178C
  • 医療機器: IEC 62304
  • これらの領域ではSysML・MATLAB/Simulink・Stateflowが必須の形式的記述として機能する
• 領域間の非対称性はリリース周期の長さで説明できる:
  • Web領域はリリース周期が日次・週次に短縮され図の維持費が便益を容易に上回る
  • 航空・自動車・医療はリリース周期が年単位で失敗時の損害が人命に直結するため二重管理が安全網として機能する
• 境界線は業界ではなくリリース周期の短さとモデル維持費の損益分岐点にある

■ 8. UML的図法の日常化という逆説

• Web領域でUML制度は死んだがUML的な図はむしろ日常に入り込んでいる
• MermaidはフローチャートからシーケンスÃ図・クラス図・状態図・ER図・C4図まで扱える
• PlantUMLもシーケンス図・ユースケース図・クラス図・状態図などを広くサポートしている
• GitHubではMermaidのレンダリングがIssues・Discussions・プルリクエスト・Wiki・Markdownファイルで利用できる
• Mermaid自身の主目的は「ドキュメントを開発に追いつかせること」であり図を開発速度に追随する軽量文書として扱う
• 死んだのはブランドとしてのUMLであり生き残ったのは図法としてのUMLの断片である:
  • 名称として避けられるようになったのはUMLという語が重い連想を持つ語彙になったからである
  • 実質としてはシーケンス図や状態図の記述機会はむしろ増えている

■ 9. まとめ

• UMLが2000年代に普及したのは単なる図法ではなく標準化・統合・管理可能性の象徴として売られたからである
• ファウラーが整理した軽いUMLと市場が売り続けた重いUMLの間には当初から深いずれがあった
• MDAのコード生成失敗がUML制度の経済的根拠を失わせた
• クラウド・iPhone・CI/CDという三方向からの圧力が変更速度を引き上げアジャイルの前提条件を満たした
• 先に死んだのは図ではなくUMLという名称に付随していた制度と二重管理であった
• UMLは消えたのではなく名前を失って日用品になった

(2026/04/24)

実践ハーネスエンジニアリング：TAKTで実現するAIエージェント制御

• 実践ハーネスエンジニアリング：TAKTで実現するAIエージェント制御 / Practical Harness Engineering: AI Agent Control Enabled by TAKT - Speaker Deck

要約:

■ 1. ハーネスエンジニアリングの定義

• 「ハーネス」の定義は論者によって異なり、コンテキスト設計・出力検査・ガードレール・ドキュメント劣化対策など多義的に使われがちである
• Birgitta Bockeler氏がMartinFowler.comに公開した「Harness Engineering」記事を出発点とする
• 本資料における定義：モデルの外側でエージェントの振る舞いを制御・誘導・検証する仕組みの総称
• メタファー：馬具（手綱・鞍・ハミ）が馬を外から方向づけるように、フィードフォワード（FF）とフィードバック（FB）でAIエージェントを外から方向づける

■ 2. ハーネスの2種類：フィードフォワードとフィードバック

• フィードフォワード（動く前に方向づける）:
  • 誰として何を目的に動くかを明示する
  • 判断に必要な背景知識をあらかじめ渡す
  • 何をもって完了とするかを事前に合意する
  • 使える手段（ツール・権限）を必要な範囲に絞る
  • 現在の局面を示す位置情報を伝える
• フィードバック（動いた後に自己修正を促す）:
  • 出力を検査しやすい形で受け取る
  • 異なる観点から複数回チェックする
  • 不備があれば修正を促して再点検する
  • 改善が停滞したら別の手立てに切り替える
• ステアリングループ：FFとFBを継続的に改善しエージェントを操縦するループであり、結果を見てFF・FB両方を調整し続ける

■ 3. ハーネスが制御する3領域

• 保守性（Maintainability）:
  • コード品質・保守性を守る汎用的なハーネス
  • 重複コード・スタイル違反・力技の修正・過剰な設計を捕捉する
• アーキテクチャフィットネス（Architecture Fitness）:
  • アーキテクチャ特性を定義し測定するプロジェクト固有のハーネス
  • 性能（レイテンシ・スループット・リソース効率）・可観測性（ログの質・トレース可能性）・構造（レイヤー違反・循環依存・結合度）を対象とする
• 振る舞い（Behaviour）:
  • 期待した振る舞いをしているか検査する完全自動化が難しいハーネス
  • 仕様・ユースケース・E2Eテスト・フィクスチャベース検証を対象とする
• ハーネステンプレート：FFとFBをパッケージ化したもの

■ 4. TAKTの概要

• YAMLでマルチエージェントワークフローを記述するオーケストレーター（指揮者「タクト」のメタファー）
• ハーネステンプレートをworkflow.yamlとして定義して動かすOSS
• インストール直後からビルトインテンプレートをそのまま利用可能（npm install -g takt）
• 構成要素:
  • ワークフロー：STEPの有限状態機械
  • ファセット：プロンプトの部品（Persona・Knowledge・Instruction・Output Contract・Policy）

■ 5. フィードフォワードの実装（6つの手法）

• Faceted Prompting（ファセットの組み立て）:
  • プロンプトを5つのファセットに分離（Persona・Knowledge・Instruction・Output Contract・Policy）
  • PersonaはSystem Prompt、その他はUser Messageとして文脈→タスク→制約の順に組み立てる
  • PolicyをUser Messageの末尾に配置しRecency効果で遵守率を最大化する
• Quality Gates（完了条件の事前提示）:
  • STEP完了前にエージェント自身が検証すべき項目を明示する
  • ビルド成功・lint通過・テスト通過などをプロンプトに箇条書きで注入する
• ツール権限の制限:
  • required_permission_modeでreadonly / edit / fullを指定する
  • allowed_toolsで使用可能なツールを明示列挙する
  • レビュアーにはEdit/Writeを渡さず暴走を防止する
• ワークフロー構造の自己認知:
  • プロンプトに現在ステップ位置を自動注入しエージェントが前後関係を理解して動作する
  • 単独STEPで完結させようとする独走を防ぎInstructionBuilderが各STEPで再構築する
• Persona Providers（適材適所のモデル選択）:
  • ペルソナごとに別プロバイダー・モデルを指定する（例：実装はCodex・レビューはClaude）
  • provider_options.claude.effortで推論深度も指定可能
• Team Leader（動的タスク分解）:
  • リーダーエージェントがJSONでタスクを分割し各partを並列実行する
  • 結果を集約して次STEPへ渡すことでFFを動的に広げる

■ 6. フィードバックの実装（7つの手法）

• Output Contract（判定可能な形の強制）:
  • Result: APPROVE / REJECTを強制しfinding_id + family_tagで追跡可能にする
  • new / persists / resolved / reopenedで進捗を分類する
• 判定フェーズの分離:
  • Phase 1（実行エージェント）とPhase 3（conductor・判定専用）を別エージェントに分離する
  • 実行する人と判定する人を分けることで主観を判定から切り離す
• Rulesによる分岐:
  • 文字列conditionはタグ[STEP:N]で照合する
  • ai("……")で自然文条件をAIが判定する
  • nextにCOMPLETE / ABORT / 次STEP名を指定してルーティングする
• 改善ループ:
  • レビュー結果に基づき修正→再レビューを繰り返す（ai_review ⇆ ai_fix・reviewers ⇆ fix）
  • pass_previous_response: falseで前回判断の引きずりを防ぐ
  • session: refreshで会話セッション自体をリセット可能
• Parallel Reviewers（多視点フィードバック）:
  • parallelで複数レビュアー（アーキ・フロント・テスト・セキュリティ等）を並列実行する
  • all() / any()で集約判定し単一視点では見えない問題を補う
• Loop Monitors（収束・発散の判定）:
  • 対象cycleとthresholdを定義し閾値到達でJudge（supervisor）を起動する
  • finding_idの推移から収束・発散を判定し発散なら別ルート（ABORT等）に切り替える
• Worktree Isolation（安全な実行基盤）:
  • 各タスクをworktreeで隔離実行する（git worktreeではなく独自実装）
  • 失敗してもメインブランチを汚さず並列修正を安全に同時実行できる

(2026/04/24)

役割と責任の区別をつける

• 役割と責任の区別をつける

要約:

■ 1. 役割と責任の違い

• スクラムガイド2020での変更:
  • スクラムガイド2017まではプロダクトオーナー・開発者・スクラムマスターを「役割（Role）」と呼んでいた
  • スクラムガイド2020から「責任（Accountability）」という用語に変更された
• Accountability（説明責任）の定義:
  • 「行動・成果・意思決定に対して責任を引き受け、その結果について報告・説明・答弁する義務」
  • 意思決定の根拠・試みた内容・結果・次の行動について担当し説明できることを指す
  • 結果を保証することではなく「結果に対してオーナーシップを持つ」ことを意味する
• ResponsibilityとAccountabilityの区別:
  • Responsibility（実行責任）は実際に手を動かす責任であり誰が何をするかの話
  • 日本語の「責任」にはこの両方の意味が含まれるため混同されやすい
• スクラムガイド2020が用語を変えた意図:
  • 「誰が何をするか」はスクラムチームの自己管理として自分たちで決める
  • どの領域でAccountabilityを持つかは明確にする
• 責任・役割と肩書き・役職・職種は別物である:
  • プロダクトオーナーやスクラムマスターは会社の役職や職種ではなくスクラムチーム内の責任の区分
  • これを理解することで「それはあなたの仕事」「作業が進まない」といった発言がなくなる
• スクラムマスターのAccountability:
  • スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ
  • スクラムチームの有効性に責任を持つ
  • その果たし方はチームの状況やスクラムマスター自身のスタイルによって異なる
  • すべてのイベントの司会やファシリテーターをするResponsibilityは存在しない

■ 2. 「何もしない問題」の正体

• スクラムが適切に機能している場合:
  • スクラムマスターがスクラムチーム内でやることは多くない
  • スクラムチームの外側（組織）での取り組みが増えていくのが通常
  • チーム内の他メンバーから「何もしていないように見えている」だけの可能性がある
• 透明性と説明責任の不足:
  • 自分がどんな目的で何をしているかを公開していない状態が問題
  • スクラムマスターは自分が何に取り組んでいるかを他者からわかるようにする必要がある
• 本当に何もしていない場合の対処:
  • チームメンバーは助けてほしいこと・手伝ってほしいことを積極的に伝える
  • スクラムチーム全体として「毎スプリント価値あるインクリメントを届ける責任」があり一人だけ他人事は許容されない
  • 改善されない場合はマネージャーへエスカレーションしチームから外す

■ 3. 役割のオーバーラップと責任の明確化

• 生成AI時代のチームの変化:
  • チームは小さくなりメンバーのスキルがオーバーラップしている
  • 「これは自分の仕事ではない」という発言が成立しない状況になっている
  • 役割の境界は曖昧であってよい
• 責任の明確化の重要性:
  • 責任が曖昧になると誰も決定しなくなり合議制に陥る
  • 責任が明確であることで意図を持った意思決定が可能になる
• 生成AI時代のプロダクトマネージャー論への適用:
  • 従来プロダクトマネージャーが担っていた業務はチームの様々なメンバーが担うようになる
  • プロダクトマネージャーが持っていたAccountabilityは誰かが持たなければならない
  • 肩書きや職種の名称が変わっても責任そのものは消えない

(2026/04/23)

ドメイン記述ミニ言語の設計論

■ 1. 設計の前提

• ミニ言語が満たすべき三条件:
  • 半形式的であること（機械コンパイル不要だが文法的に曖昧でない）
  • 人間・ドメイン専門家・AIエージェントが共有できること（実装言語の知識を前提としない）
  • 四層（lexicon / syntax / semantics / pragmatics）を持つこと（semantics 層を含む点が用語集との分水嶺）

■ 2. 第一層：Lexicon（語彙）

• 名詞と動詞を対等に扱うことが出発点
• 用語集が失敗する原因は名詞しか定義しないため
• 動詞は必ずどの concept に属するかとセットで記述する規則が必須
  • 動詞が宙に浮くと semantics 層に繋がらない

concept 注文
concept 顧客
concept 注文明細

operation 確定する   (注文に対して)
operation キャンセルする (注文に対して)
operation 追加する   (注文明細を注文に対して)

■ 3. 第二層：Syntax（構成規則）

• ある concept がどんな要素から成り立つかを AND / OR / ? で記述する
• この層を書くことで「ありえない状態の構造的な排除」が始まる
  • OR 型で状態を列挙することで矛盾した状態が文法レベルで存在不可能になる
• 記法の選択方針:
  • Haskell / F# の代数的データ型記法を参考にすることは合理的
  • ドメイン専門家と共有する場合は自然言語寄りの表現も検討に値する
  • 一つのプロジェクト内で記法を混在させないことが肝要

注文 = 顧客 AND List<注文明細> AND 注文状態
注文明細 = 商品 AND 数量 AND 単価
注文状態 = 未確定 | 確定済み | 出荷済み | 完了 | キャンセル済み
数量 = 正の整数   // 型制約も文法の一部

■ 4. 第三層：Semantics（振る舞い）

• 用語集と言語の分かれ目であり設計の核心
• 不変条件（invariant）:
  • concept が存在している間常に真でなければならない規則
  • 構造定義だけでは表現できない意味を持ち込む手段
• 状態遷移:
  • ドメインの時間軸を言語に持ち込む
  • 「いつその操作が意味を持つか」を明確化する
• 事前・事後条件（pre / post）:
  • BDD の Given-When-Then と等価でありテストシナリオに自然に変換できる
  • 厳密な論理でなくともテストに翻訳できる精度があれば十分

注文 {
  invariant: 明細は1件以上存在する
  invariant: 合計金額 = sum(明細.単価 × 明細.数量)
}

注文状態の遷移 {
  未確定    --[確定する]--> 確定済み
  未確定    --[キャンセルする]--> キャンセル済み
  確定済み  --[出荷する]--> 出荷済み
  出荷済み  --[受領する]--> 完了
}

operation 確定する {
  pre:  注文状態 == 未確定
  pre:  明細.count >= 1
  post: 注文状態 == 確定済み
  post: 確定日時 が記録される
}

■ 5. 第四層：Pragmatics（文脈）

• 同じ語が Bounded Context によって意味を変える現象を扱う層
• mapping ブロックを書くことで Context 間の翻訳規則を言語として記録できる
  • 「翻訳の蓄積」という失敗モードへの直接の処方箋

context 受注管理 {
  concept 顧客 = 名前 AND 配送先住所 AND 注文履歴
}

context 与信管理 {
  concept 顧客 = 名前 AND 与信限度額 AND 支払い履歴
}

mapping 受注管理.顧客 <-> 与信管理.顧客 {
  共通キー: 顧客ID
  受注管理側では与信情報は不可視
}

■ 6. 設計原則

• 原則1「書けない状態は存在しない」:
  • 記法が表現できない状態や遷移はモデルに存在しないものとして扱う
  • この制約が言語に思考を強制する力を与える
• 原則2「操作は concept に帰属させる」:
  • 動詞を浮かせず「何が」その操作を持つかを明示する
  • 責務の設計とミニ言語が連動する
• 原則3「不変条件は構造定義の直後に書く」:
  • concept ブロックの中に invariant を置くことで定義と制約を分離しない
  • 後から別ファイルに書かれた不変条件は読まれなくなる
• 原則4「記法の複雑さはドメインの複雑さに合わせる」:
  • シンプルなドメインに複雑な記法を持ち込むとミニ言語自体が保守コストになる
  • 最初は lexicon + syntax + 状態遷移のみで始め段階的に導入するのが現実的
• 原則5「コードと並走する」:
  • ミニ言語のファイルをコードリポジトリと同じ場所に置きコードレビューの対象にする
  • ドキュメントとして別管理した瞬間にコードとの乖離が始まる

■ 7. 残された課題

• ミニ言語の設計完成後もドメイン専門家が実際に読み書きするかという問題は別途残る
• 形式的すぎると専門家が離れ自然言語に近づけすぎると曖昧さが戻るという張力は解消不可能
• ミニ言語はチームごとのキャリブレーションを必要とする一点制作品であり汎用フレームワーク化には本質的限界がある
• 四層の整理はキャリブレーションのための共通語彙として機能する
• 設計目標は「完全な形式言語の作成」ではなく「用語集で止まらないための最低限の文法を持つこと」

(2026/04/22)

ユビキタス言語

• ユビキタス言語 - kawasima

要約:

■ 1. 主張の核心

• ユビキタス言語が "language" と呼ばれる理由はその設計がドメインモデリングそのものだからである
• 言語の設計とは語彙のみならずデータの構造と振る舞いを文法として決めることを指す
• 用語集 (glossary) との本質的な違いは文法の有無にある

■ 2. 言語学的根拠

• 名詞の集まりだけでは言語にならない
  • Saussure: 言語は記号の体系であり個々の記号は差異によって意味を持つため語彙の並びだけでは体系にならない
  • Wittgenstein: 語の意味はその使用によって決まる (哲学探究 §43)
• 言語には語の組み合わせを規定する文法と語が使われる場の両方が要る
• 用語集は名詞の並びであり振る舞い・状態遷移・概念間の関係を記述する文法を持たない

■ 3. 言語の四層とドメインモデルの対応

• 言語学的な四層がドメインモデルの要素に一対一で対応する
  • lexicon (語彙): 概念と操作の名前 → 注文・顧客・検証する等の名詞と動詞
  • syntax (統語): 概念の構成規則 → AND・OR・? による複合・分岐・任意
  • semantics (意味): 語の使われ方 → 不変条件・事前/事後条件・状態遷移 (behavior の入出力仕様)
  • pragmatics (語用): 文脈による意味の変化 → Bounded Context による文脈の切り分け
• 用語集と言語の分かれ目は semantics の層である
  • behavior なしの用語集は語が使われてよい/使われてはいけない規則を書けない
  • behavior を書くことで語が実際にどう使われるかが定義される
• Evans の "a change in the language is a change to the model" はこの対応から導かれる

■ 4. 同方向の先行論

• ユビキタス言語を半形式の記述として扱う先行論が複数存在する
  • BDD (Dan North): Given-When-Then 構文 (Gherkin) による振る舞いの半形式記述
  • Scott Wlaschin "Domain Modeling Made Functional": F# の代数的データ型でドメインを記述しコードがユビキタス言語の記述になるとした
  • Cyrille Martraire "Living Documentation": ユビキタス言語はコードに埋め込まれており BDD シナリオを live specification として扱う
  • Vlad Khononov・Derek Comartin: DDD の core は tactical pattern ではなくユビキタス言語であると明示
• 先行論の共通点は「振る舞いを含む半形式の記述」としてユビキタス言語を扱う視点である
• 先行論が示さなかった点: Evans の定義の曖昧さを正面から問題化し syntax・semantics・pragmatics の三層を具体的に記述する形式の提示

■ 5. 概念が曖昧なまま流通してきた経緯

• Evans 自身がユビキタス言語の定義の曖昧さを認めている
  • 2014年 DDD Exchange: DDD の中核概念が実装レベルで機能せず慣習に頼らざるを得なかったと述べた
  • 2018年 Explore DDD: DDD の説明が "handwavy good advice" "feel good mush" に近いと自己批評した
  • 2019年 DDD Europe: Bounded Context を含む fundamental terms がしばしば誤解されていると認めた
• Evans 2015 DDD Reference の Ubiquitous Language 節は概念の定義ではなく実践の指示を主眼に置いている
• 曖昧さの結果として各地で形骸化が生じた
  • 英語圏: 同義語・一語多義・型/実体の混同・技術用語との衝突といった問題が報告された
  • 日本語圏: プラクティスが精神論として語られる傾向が定着した

■ 6. 実際の成果物は用語集になっている

• 公開されているユビキタス言語の成果物はほぼすべて名詞中心の用語リストである
  • IFRC CBS: 組織・役割・疾病・報告形式の名詞定義が中心で振る舞いや状態遷移の記述は限定的
  • LegalOn Technologies: 用語の日英併記定義が中心で動詞や状態遷移の具体的扱いは示されていない
  • Progate: スプレッドシートによる用語辞書と Figma のドメインモデル図で振る舞い・状態遷移の扱いには及んでいない
  • Matt Pocock の ubiquitous-language skill: 出力例は名詞の表と概念間のカーディナリティが中心
• Qiita の調査でも日本語圏の 6 事例のうち動詞を扱うのは 1 件のみである
• 各チームが自前で形式を発明した結果として最も作りやすい「名詞の辞書」が採用された

■ 7. 日本語訳が用語集理解を助長する問題

• Khononov 邦訳『ドメイン駆動設計をはじめよう』(2024) では ubiquitous language が「同じ言葉」と訳されている
• 「同じ言葉」は四層のうち lexicon の層にのみ対応する訳語である
  • 「同じ」は一意性の要求を「言葉」は語彙の並びを指す
  • syntax・semantics・pragmatics の三層が訳語に含まれない
• カタカナ表記であれば「語ではなく言語」という違和感が残るが「同じ言葉」だとその違和感もなくなる
• 既に名詞中心に偏っている現状で訳語自体がその偏りをさらに強める

■ 8. DSL との関係

• ドメイン記述ミニ言語は実行可能な DSL とは別の位置にある
  • Evans の論じる DSL はコンパイラで処理され実装になる実行可能な言語である
  • ドメイン記述ミニ言語は人間・ドメイン専門家・AI Agent が共有するための半形式的な記述言語である
• ミニ言語の記法は実装との対応が厳密でなくてよい
  • コレクションを示す List は実装構造の指定ではなく複数あるという業務上の意味を表す
• 実行可能な DSL はユビキタス言語の文法の一部を機械に渡す際の固定化であり言語設計そのものではない

■ 9. 用語集として扱うことの失敗モード

• 用語集として運用することは語彙だけを残し文法を捨てることである
• 具体的な失敗モードは以下の通り
  • 翻訳の蓄積: 文法が共通でないためドメイン専門家と開発者の語りの差を文単位で翻訳し続けることになる
  • 瞬間的表現の喪失: 用語集は文を作って使う場を持たないためドメイン理解の核心となる瞬間的な表現が記録されずに失われる
  • 動詞の欠如: 名詞の並びにはドメインの振る舞いが現れず anemic domain model と同じことが言語の側でも起こる
  • ありえない状態の許容: 文法なしではドメインの不変条件が型の段階で守られない
  • コードとの乖離: 言語としてコードと並行して使われないため時間経過とともにコードと食い違っていく

(2026/04/22)

言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺

• 言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺

要約:

■ 1. 記事の概要

• タイトル: 言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺
• 著者: ココナラ DevOpsグループCREチーム y.s.（@inu_no_hou）
• 公開日: 2026年4月20日
• テーマ: communication・mindset・technical writing

■ 2. 概念操作の手法

• 基本テーゼ:
  • 言語化とは「概念操作とその操作結果の伝達」である
  • 概念操作力とその伝達力の二軸を鍛えることが重要
• 主観と客観の整理:
  • 主観は自分のみで有効であり、客観は広く妥当する可能性が高い
  • ビジネスで求められる数値化やファクトとオピニオンの分離はこれに該当
• 抽象化:
  • 個別概念を削り落とす工程
  • 例: 「林檎2つ、バナナ3つ」→「果物5つ」
• 一般化:
  • 抽出した本質を複数の具象に当てはめる操作
  • 例: Tシャツの本質（襟なし・T字型・かぶり式）は生地や色を変えても成立
• 例え話:
  • 概念構造が瑣末な変更を経ても同一であることを利用する手法
  • 具体と抽象を行き来する能力を磨くことに有効
• メタ化:
  • 「本当だろうか？」という問いで自分の概念体系全体を問題化する
  • 問いの次数を上げ下げして視点を調整する
• 結論:
  • 概念操作力とは「具体と抽象を反復横跳びする筋力」であり日々の鍛錬が必要

■ 3. テクニカルライティングの鉄則

• 基本原則:
  • 文章の目的は読者が「わかった・できた」となること
  • 自分の賢さの披露や情報の網羅は目的ではない
• 7つの鉄則:
  • 短く書く: 1文=1アイデアとし文・語・段落を全て短くする
  • 能動態で書く: 「誰が」「何をした」を明確にする
  • 強い動詞を使う: be動詞やoccurではなくgenerate・trigger・deleteなど具体的な動詞を用いる
  • 無駄を削る: 冗長な修飾語や形容詞を排除し数字を活用する
  • 構造で見せる: 見出し・リスト・表で情報を構造化する
  • 読者を意識する: 対象読者の知識レベルを把握して執筆する
  • 一貫性を守る: 同じ概念に同じ用語を使い続ける

■ 4. セルフ編集チェックリスト

• 文の構造:
  • 1文1アイデアを守り複数概念を1文に詰め込まない
  • 受動態を能動態に変換する
  • be・occur・happenなど弱い動詞を回避する
  • 「There is/are」を削除し主語を前面に出す
  • 冗長表現を削除する（「in order to」→「to」・「make use of」→「use」）
• 語彙と用語:
  • 表記ゆれを避け初出時にフル名と略称を定義する
  • 頭字語は初出時に正式名称を説明する
  • It・This・They等の代名詞を具体的な名詞に置き換える
  • 形容詞を数値化する（「very fast」→「225-250%高速」）
• 段落構成:
  • 冒頭文で内容を予告し読者が先頭文のみで内容を判断できるようにする
  • 1段落1トピックを原則とし3〜7行を目安にする
• 見出しとリスト:
  • 見出しは内容を正確に予告する（「Details」×→「Configure the database connection」◎）
  • リストの並列構造を統一する（名詞のみ・命令形のみなど）
• トーンと表現:
  • ユーザーを責めない表現を使う（「Invalid ID」×→「You need an ID that looks like...」◎）
  • pleaseの過剰使用を避ける
  • ジェンダー・文化バイアスを排除する（he→you）
• エラーメッセージ:
  • 「何が問題か」と「どう直すか」の2点セットで構成する
  • 例: 「Error: Invalid input」×→「Can't save because file name contains invalid characters. Remove: / \ : * ? "」◎
• グローバル対応:
  • 文化固有表現を排除する（「a piece of cake」→「simple to set up」）

■ 5. LLMをテクニカルライティングに活用する方法

• 活用場面:
  • 初稿生成: 立場・対象読者・形式を指定して生成する
  • 文書推敲: 受動態検出・文法チェック・スタイル統一に使用する
  • フォーマット変換: Word→Markdownなどの形式変換に使用する
  • 要約: 長文の要点整理に使用する
• 注意点:
  • LLMはハルシネーション（虚偽出力）があるため事実確認が必須
  • 「提供テキストの情報のみ使用」と制約を明示する
  • LLMに書かせすぎるとメタ認知のメリットが消失する

■ 6. テンプレート集

• 技術ドキュメント: 概要・対象読者・前提知識・対象範囲・セクション・関連リソースで構成
• APIリファレンス: メソッド名・構文・パラメータ表・戻り値・例・備考・関連項目で構成
• エラーメッセージ: 何が問題か・なぜか・どう直すかの構成で良悪例を含む
• How-toガイド: タスク名・前提条件・手順・確認方法・トラブルシューティング表・次のステップで構成
• リリースノート: 新機能・改善・バグ修正・破壊的変更・既知の問題・アップグレード手順で構成
• トラブルシューティングガイド: 症状・原因・解決策・未解決時の対応で構成

■ 7. 結論

• 概念操作もテクニカルライティングも単なる筋トレであり継続的な実践が重要
• 日々の鍛錬は裏切らないと著者は強調する

(2026/04/21)

AIの電力限界に挑む——Extropicが狙う「熱力学コンピューティング」とは

• AIの電力限界に挑む——Extropicが狙う「熱力学コンピューティング」とは｜Neo Tech World

要約:

■ 1. 背景——AIの電力・設備コスト問題

• 生成AIは学習・推論において膨大な計算を必要とし中心にあるGPUは高性能だが消費電力も大きい
• AIの課題は「より賢いモデルを作ること」だけでなく現実に動かし続けるための電力と設備コストに移ってきた
• 高性能GPUを積み増すだけでは電力・冷却・設置面積・設備投資の負担が拡大する一方である
• 現在の機械学習はGPUに合わせて進化してきた仕組みであり計算需要は決定論的処理から確率的処理へエネルギー制約へと移行しつつある

■ 2. Extropicの概要と開発ロードマップ

• 2022年創業2023年12月に1410万ドルのシード資金を調達
• GPUの改良ではなく生成AIに必要な計算そのものを作り直す「熱力学コンピューティング」を掲げる
• 開発段階:
  • X0: 2025年Q1のシリコン試作——確率回路を実際に製造できることを実証
  • XTR-0: 2025年Q3の実験・研究プラットフォーム——Extropicのチップと従来型プロセッサを低遅延で接続し超高効率AIアルゴリズムの開発基盤とする
  • Z1: 2026年early access予定の初の量産規模チップ——1チップあたり数十万・1カードあたり数百万の確率回路を標準CMOSプロセスで量産可能とする
• ソフトウェア面ではオープンソース開発基盤THRMLを公開しGPUなど既存環境上で熱力学コンピューティング向けアルゴリズムを試験できる

■ 3. 技術的原理——p-bitと確率回路

• 通常のデジタル計算機が0か1を厳密に固定して計算するのに対しExtropicは回路の揺らぎを計算資源として利用する
• p-bit（確率ビット）:
  • 0と1の間を行き来しながらどちらに寄りやすいかを調整できるスイッチ
  • 従来の半導体がノイズを排除しようとしてきたのに対し揺らぎを計算に取り込む点が根本的に異なる
• 確率回路の種類:
  • PBIT: 0か1を指定した確率で出し分ける基本回路（重み付きコインに相当）
  • PDIT: 複数の離散的な候補から確率に応じて選ぶ回路（重み付きサイコロに相当）
  • PMODE: 連続値をとるガウス分布を表現する回路
  • PMOG: 複数の山を持つ複雑な分布を扱う回路
• TSU（Thermodynamic Sampling Unit）が中核であり複雑な確率分布から直接サンプルを生成することを狙う
• DTM（Diffusion Thermodynamic Model）は拡散モデルに近い発想でTSUの確率的性質を前提に生成処理を組み直したアルゴリズム

■ 4. 技術的ブレークスルーの三点

• TSUによるサンプリング:
  • 従来AIが行列計算で確率表を作りサンプリングするのに対しTSUは確率分布から直接サンプルを出す
  • 生成AIの中核にある確率的選択をハードウェアの中心に置く設計思想
• 量産を見据えた実装可能性:
  • p-bitをトランジスタのみで構成し小型・省エネ・既存回路との統合が容易と主張
  • 研究室デモにとどまらず実際の半導体として大規模化できる可能性を提示
• ハードとアルゴリズムの一体設計:
  • TSU・DTM・THRMLをセットで外部に公開し単なるアイデア企業を超えた段階にある
  • 公式発表では小規模生成AIベンチマークにおいてGPUベース手法より最大約10000倍のエネルギー効率向上の可能性を示す（特定条件下の分析であり商用基盤モデルの実運用置き換えを意味するものではない）

■ 5. 実用化に向けた課題と制約

• スケールの壁:
  • 小規模回路で有望な結果が出ても大規模システムへ拡張した際に同じ効率が維持できるとは限らない
  • 量産では歩留まり・配線・発熱・制御の複雑さが重くなり理論上の優位が崩れうる
• ソフトウェアエコシステムとの接続:
  • 現在のAI開発はCUDAをはじめGPU前提の巨大なエコシステムの上で動いている
  • THRMLの公開は対策の出発点にすぎず「使ってみたい技術」から「導入できる技術」への転換が必要
• 用途の限定性:
  • Extropicの方式はあらゆる計算でCPU・GPUを置き換えるものではない可能性が高い
  • 相性が良いのは確率分布を扱う処理・サンプリングが重い処理・ノイズを前提にした生成や推定の処理
  • 最初の勝ち筋は「全AIを置き換える」ことではなく特定の確率的ワークロードで圧倒的に省エネという狭く深い突破口になる公算が大きい

■ 6. 確定点と未確定点の整理

• 確定している事実:
  • 2025年にTSU・DTM・THRML・XTR-0を含む熱力学コンピューティングの全体像を公表
  • X0シリコン試作・XTR-0開発基盤・Z1量産スケールという三段階ロードマップを明示
  • THRMLをGitHubで公開し外部から触れられる状態にある
  • ハード・アルゴリズム・ソフトウェアを並行して外部に示し始めている
• 未確定の事項:
  • 大規模商用AIの現場でGPUの代替または補完になれるかは未実証
  • 小規模ベンチマークでの10000倍効率向上は特定条件下の分析であり商用スケールでの実証ではない
  • 2026年4月時点では量産出荷の完了や大規模顧客への本格導入を示す一次情報は確認できない
• 現在地の評価:
  • 「机上構想の会社」ではもうないが「GPUに対する勝敗が見えた会社」でもまだない
  • 技術的成立可能性と初期ロードマップを市場に示した段階であり商用スケールで勝ち筋が実証された段階ではない

■ 7. 今後の焦点

• XTR-0やTSUの考え方が試作にとどまらずどこまで大きな規模へ拡張できるか
• THRMLを起点に外部の研究者や開発者がどれだけ参加し技術の土台が広がるか
• 画像生成・気象・科学計算のような確率的処理が重い分野で最初の具体的な実用価値を示せるか
• 三つが揃えばExtropicは「面白い技術」から「業界の現実的な選択肢」へ進む可能性があり揃わなければ高く評価されながらも広くは採用されない技術にとどまる

(2026/04/21)

Why is IPv6 so complicated?

• misc/why6why.md at main · becarpenter/misc · GitHub

要約:

■ 1. IPv6が複雑である理由の概観

• IPv4のアドレスに単純にビットを追加するだけでは不十分であり IPv6の複雑さには正当な理由が存在する
• 主な理由は以下の3点に整理される
  • アドレスのビット数拡張は見た目より複雑である
  • 1994年当時 IPv4以外にも多くのネットワーク層プロトコルが存在しIPv4にない機能が求められた
  • IPv6設計者が過剰設計に陥った可能性がある（いわゆるSecond System Syndrome）
• IPv6開発の意思決定は1991年のIABワークショップを起点とし 1994年7月のIETF会議で正式に採択された

■ 2. アドレスのビット拡張が単純でない理由

• IPv4の実装はすべて32ビットアドレス形式をコードに組み込んでおり アドレス長を変更すると既存の実装はパケットを廃棄する
• アドレスサイズを拡張するには必ずプロトコルを変更する必要があり 以下の対応が不可避となる
  • バージョン番号の変更
  • 新バージョンを処理する新規コードの追加
  • 旧バージョンとの共存技術の実装
• 旧バージョンとの共存方式は数学的に以下の2つしか存在しない
  • デュアルスタック: 新しいマシンがIPv4とIPv6の両方を話す方式
  • トランスレーション: アドレスを旧・新プロトコル間で変換する方式
• IPv4/IPv6共存の複雑さはすべてこの構造的制約から生じており IPv6の設計詳細とは無関係である
• 「IPv8」提案者が主張する「IPv4アドレスの先頭にビットを追加する」方式も試みられたが実用性がなく廃止された（RFC3513 → RFC4291）

■ 3. 1990年代初頭のプロトコル環境

• 1990年代初頭はIPv4がまだ世界を支配しておらず 多数の代替ネットワーク層プロトコルが存在した
  • OSI（開放型システム間相互接続）プロトコル群: 各国政府や大企業が標準として支持
  • DECNET Novell Netware等の独自プロトコル群
• 新世代IPには単なるアドレス拡張ではなく これらの競合プロトコルを上回る機能が求められた
• この背景から IPv4単純拡張では市場・技術的ニーズを満たせなかった

■ 4. IPv6設計の過剰複雑化に関する検討

• IPv6は基本的に保守的な設計であり コネクションレス型パケット交換という基本モデルは維持されている
• 追加された主な機能は以下の通り
  • フローラベル（長年未使用でも無害）
  • フラグメンテーション機構の調整
  • IPv4「オプション」をIPv6「拡張ヘッダ」へ置き換え
  • ステートレスアドレス自動設定（SLAAC）とルータアドバタイズメント（RA）機構
• SLAACはDECNET・Netware・Appletalkに着想を得たものであり 手動アドレス設定を不要とする
• DHCPv6とSLAACが重複するのは SLAAC設計時にDHCPがまだ実績のない新技術だったためであり DHCPv6は後付けで追加された
• IPsecのサポートを必須とする政治的決定は 当時未成熟な技術を強制したことでIPv6普及の妨げとなり 後に撤回された
• IPv6展開の問題の大部分はIPv4/IPv6共存領域から生じており 設計の過剰さによるものではない

■ 5. 代替案（IPv8等）の問題点

• 一部の「IPv8」提案は解決どころか問題を悪化させる要素を含んでいる
  • 地理的アドレッシング: インターネットのドメイン間ルーティングと非互換
  • 自律システム番号に基づくアドレスプレフィックス: ルーティングを破壊する
  • アドレスビットに意味を持たせる設計: サイト再番号付けをさらに困難にする
  • これらは経路制御の破綻 アドレス枯渇の再発 広範囲な監視の容易化等を引き起こすリスクがある

■ 6. 普及に要する時間の必然性

• IPv6が約50%の普及率に達するまで25年以上を要した
• これはIPv6固有の問題ではなく インターネット規模の技術移行には例外なく数十年を要する
  • フレームリレーの廃止
  • ATMの置き換え
  • DNSSECの展開
  • RPKIの展開

■ 7. 結論

• IPv6の存在意義はアドレス空間の拡大にあり それ以外の複雑さは構造的に避けられないものである
• 32ビットを超えるアドレス長を採用した時点で 共存・移行に関するすべての問題は必然的に発生する
• デュアルスタックとトランスレーションの両方式は数学的に不可避であり 代替設計によって回避することは不可能である
• IPv8等の代替提案を検討することはコミュニティにとって時間の無駄である

関連:

• IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服

(2026/04/21)

IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服

• IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服 - PC Watch

要約:

■ 1. IPv8プロトコルの概要

• 次世代ネットワークプロトコル「Internet Protocol Version 8(IPv8)」のドラフト版「draft-thain-ipv8-00」がOne Limited所属のJamie Thain氏によって2025年4月14日にIETFへ提出された
• 本ドラフトはIETFの承認や正式な策定プロセスを経たものではない
• IPv6はアドレス枯渇問題には対処したが管理上の断片化問題を解決できず25年間の展開努力にもかかわらず世界的なインターネットトラフィックのごく一部しか担えなかった
• デュアルスタックによる移行モデルと管理改善の欠如がIPv6の商業的受け入れを妨げた要因とされる

■ 2. アドレス設計と下位互換性

• IPv8のアドレスは64bitで構成され前半32bitのASNルーティングプレフィックス(r.r.r.r)と後半32bitのホストアドレス(n.n.n.n)に分かれる
• アドレス構造:
  • r.r.r.r.n.n.n.n の形式
  • r.r.r.r: 32bit ASNルーティングプレフィックス
  • n.n.n.n: 32bitホストアドレス(IPv4と同一の意味を持つ)
• IPv4との完全な下位互換性:
  • プレフィックスを0.0.0.0とした場合はIPv4アドレスとして機能する
  • IPv4はIPv8の完全なサブセットであり既存デバイス・アプリケーション・ネットワークを変更せずにIPv8ネットワークへ参加できる
  • デュアルスタック運用および強制的な移行期間(フラグデー)は不要
• アドレス空間:
  • 総アドレス数: 2^64 = 18,446,744,073,709,551,616
  • 各ASN保有者に2^32(約42億)のホストアドレスを割り当て
  • CGNATなどを不要とし根本的なアドレス枯渇問題を解決する

■ 3. ネットワーク管理の統合

• 「ゾーンサーバー」と呼ばれるプラットフォームがネットワーク管理の中核を担う
• ゾーンサーバーが提供する統合サービス:
  • DHCP8: アドレス割り当て
  • DNS8: 名前解決
  • NTP8: 時刻同期
  • NetLog8: テレメトリ収集
  • OAuth8: 認証キャッシュ
  • XLATE8: IPv4/IPv8変換
• デバイスは1回のDHCP8 Discover要求を行うだけですべての応答を受信できる

■ 4. セキュリティ機能

• 内部ネットワークの防御:
  • OAuth2 JWTトークンによるローカル認証を基盤とする
  • ACL8ゾーン分離によってデバイス間トラフィックを強制制御する
  • 許可されたルート以外の宛先への通信を排除するアーキテクチャを採用する
  • 3つの独立した強制レイヤーによる多層防御を提供する
• インターネット向けトラフィックの制御:
  • DNS8による名前解決とWHOIS8レジストリの検証を必須とする
  • DNS解決を伴わないハードコードIPアドレスによるマルウェアのC&Cチャネル通信を排除できる

■ 5. ルーティングの強化

• 32bitの累積メトリック「Cost Factor(CF)」を導入:
  • TCPセッションのラウンドトリップ時間・パケット損失・輻輳ウィンドウ状態・セッション安定性・リンク容量から導出される
  • 各ルーターは協調せず送信元から宛先まで累積CFが最低のパスを個別に選択する
• グローバルルーティングテーブルの肥大化問題への対処:
  • 最小プレフィックスを/16に制限する
  • BGP8のグローバルルーティングテーブルをASNごとに1エントリに制限する

(2026/04/20)

Friends Don't Let Friends Use Ollama

• Friends Don't Let Friends Use Ollama | Sleeping Robots

要約:

■ 1. Ollamaの概要と問題の本質

• OllamaはローカルLLM実行ツールとして最も普及しているが普及に値しない
• 普及の理由は先行者優位であり技術的優位性ではない
• llama.cppをラップしたツールでありながらその依存関係を長期間隠蔽してきた
• VC資金を受け取りながらオープンソースコミュニティの信頼を裏切ってきた

■ 2. llama.cppへの帰属問題

• Ollamaの推論機能はすべてGeorgi Gerganov作のllama.cpp(2023年3月)に依存している
• llama.cppはGitHub上で10万以上のスターと450名以上のコントリビューターを持つ
• Ollamaは1年以上にわたってREADMEにllama.cppへの言及を記載しなかった
• MITライセンスの唯一の要件である著作権表示を配布バイナリに含めなかった
• コミュニティからの指摘(Issue #3185)が400日以上放置された
• 最終的に追加されたのはREADME末尾の一行のみであり共同創業者のコメントは距離を置く意図を示唆した

■ 3. llama.cppからのフォークと性能劣化

• 2025年中頃にllama.cppを離れてggmlを直接ベースとしたカスタム実装へ移行した
• 移行理由として安定性を挙げたが実際にはllama.cppが解決済みのバグが再発した
• 主な問題:
  • 構造化出力サポートの破損
  • ビジョンモデルの失敗
  • GGMLアサーションクラッシュ
• ベンチマーク結果:
  • 同一ハードウェア・同一モデルでllama.cppはOllamaの1.8倍高速(161 vs 89 tokens/sec)
  • CPU使用時のギャップは30〜50%
  • Qwen-3 Coder 32Bではllama.cppがOllamaより約70%高スループット
• Georgi Gerganov自身がOllamaのGGMLフォークに問題のある変更があることを指摘した

■ 4. モデル名の誤表示

• DeepSeek R1リリース時に671Bパラメータの本体ではなく小規模蒸留モデルを「DeepSeek-R1」として表示した
• DeepSeek自身は「R1-Distill」プレフィックスで正しく命名しておりHugging Faceも正確に表示していた
• ollama run deepseek-r1は8Bの蒸留モデルを起動する
• Issue #8557と#8698は修正なしにクローズされた
• この誤表示によりDeepSeekの評判に悪影響を与えた

■ 5. クローズドソースアプリのリリース

• 2025年7月にmacOS/Windows向けGUIデスクトップアプリをプライベートリポジトリで開発しライセンスなしで公開した
• コミュニティからAGPL-3.0依存の可能性が指摘された
• WebサイトではGitHubリンクの隣にダウンロードボタンを配置しオープンソースアプリと誤認させる構造だった
• メンテナーは数ヶ月間沈黙し2025年11月にメインリポジトリへのマージが行われた

■ 6. Modelfileの問題

• GGUFはシングルファイルデプロイを原則とし必要な情報がすべてファイル内に含まれているが Ollamaはその上にModelfileという別設定ファイルを追加した
• Ollamaはハードコードされたリストに存在しないチャットテンプレートを自動検出できず{{ .Prompt }}にサイレントフォールバックする
• パラメータ変更のワークフロー:
  • Modelfileのエクスポート→編集→ollama createで新モデルエントリ作成という手順が必要
  • この過程でモデルファイル全体(30〜60GB)がコピーされる場合がある
• Jinja形式ではなくGoテンプレート構文を採用しており独自形式への変換が必要
• llama.cppではtemperatureや system promptはコマンドラインフラグで変更可能

■ 7. レジストリのボトルネック

• 新モデルのGGUFはHugging Face上で数時間以内に公開されるがOllamaレジストリへの追加は遅延する
• Ollamaが提供する量子化形式はQ4_K_SQ4_K_MQ8_0F16F32のみでQ5_K_MQ6_KIQクォントは非対応
• 新モデルリリース時にOllamaでテストした結果としてモデル自体ではなくOllamaのバックエンドに起因する問題がモデルの評判を損なう事例が複数発生している
• Hugging Faceがollama run hf.co/{repo}:{quant}形式をサポートしたが根本的な問題は解決されていない

■ 8. クラウドへの転換

• 2025年後半にクラウドホストモデルをローカルライブラリと並列で提供開始した
• MiniMaxなどのプロプライエタリモデルを選択した場合データが外部に送信されることの明確な開示がない
• Ollamaのドキュメントはプロンプトを保存・ログ記録しないと述べているが第三者プロバイダの扱いは不明
• Alibaba Cloudホストモデルにはゼロデータリテンション保証が存在しない
• CVE-2025-51471:悪意あるレジストリサーバーが通常のモデルpull中に認証トークンを奪取できる脆弱性が存在しPRが作成されるまで数ヶ月を要した

■ 9. VCバックドプロジェクトのパターン

• OllamaはY Combinator(W21)出資のスタートアップでKitematic(Docker GUIをDocker Incに売却)の創業者によって設立された
• 典型的な段階:
  • OSSをラップしてコミュニティの信頼を獲得
  • 帰属表示を最小化してプロダクトを自立しているように見せる
  • プロプライエタリなモデルレジストリ形式でロックインを作る
  • クローズドソースコンポーネントを追加
  • 収益化のためにクラウドサービスを導入
• モデルはハッシュ化されたファイル名でOllama独自形式で保存されており他ツールへの移行が困難

■ 10. 代替ツール

• llama.cpp:
  • OpenAI互換APIサーバー(llama-server)と組み込みWeb UIを提供
  • スループットはOllamaより一貫して高い
  • 2026年2月にggml.aiがHugging Faceと統合し長期持続性を確保
• Mozilla llamafile:
  • モデルとランタイムを1つの実行ファイルにパッケージ化し6つのOSで動作
• llama-swap:
  • 単一APIエンドポイント後ろでのマルチモデルオーケストレーション
• GUIオープンソース選択肢:
  • Jan(AGPLv3):ローカルファーストチャットアプリ
  • koboldcpp(AGPL):組み込みWeb UIを持つllama.cppフォーク
• クローズドソースラッパー:
  • LM Studio:llama.cppへの適切な帰属表示を維持し善意ある姿勢を示すプロプライエタリGUI
  • Msty:マルチモデルサポートと組み込みRAGを持つクローズドソースGUI
• Red Hat ramalama:依存関係を明示的にクレジットするコンテナネイティブなモデルランナー

■ 11. 結論

• llama.cppはGeorgi Gerganovが2023年3月に一夜で作成しローカル推論革命の基盤となった
• Ollamaはそのllama.cppをラップしVC資金を調達したが帰属を拒否しフォークを失敗させクローズドソースアプリを出荷しクラウドサービスへ転換した
• あらゆる判断ポイントでOSSエコシステムへの貢献よりも投資家向けの自立性アピールを優先した
• ローカルLLMエコシステムに必要なのはllama.cppであり Ollamaの代替ツールはすでに十分存在する

(2026/04/20)

Perry

• Perry — TypeScript → Native

MEMO:

• TypeScriptをネイティブバイナリにコンパイルするらしい
• 処理系はRustで記述され、ネイティブコードの生成はLLVMを使用している
• 対応プラットフォームは10種類と結構多いが、これはLLVMの恩恵だろうか
  • macOS, iOS, iPadOS, Android, Linux, Windows, watchOS, tvOS, WASM, Web
• 現時点（v0.5）ではGCが無いので長時間利用されるプロセスには不向きとのこと

(2026/04/20)

システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る

• システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る - Speaker Deck

要約:

■ 1. 概要

• 発表タイトル: 「システムは『動く』だけでは足りない 実装編 ― 非機能要件・分散システム・トレードオフをコードで見る」
• 発表者: @nwiizo（3-shake）
• 基礎編で示した「守るものが違うと設計が変わる」「分けると成功したか不明な場面が増える」「最後は何を守るために何を引き受けるかを決める」という原則を、小さなRustサンプルで具体的に再現する
• 取り上げるテーマ:
  • やり直し（Retry）だけでは危ない理由
  • レプリカ（replica）を読むことがなぜ少し古い値を連れてくるのか
  • その判断をどう残すか（ADR）

■ 2. サンプルの全体像

• サンプルは現実のシステムをかなり単純化したものであり、難しい仕組みを再現することではなく何を守ると何が増えるかを明示することを目的とする
• 注文処理の系:
  • FakePaymentGateway（テスト用決済サービス）
  • CheckoutService（注文を進める役）
  • OrderRequest（注文内容）
• 在庫参照の系:
  • InventoryStore（在庫を見る役）
  • primary（最新の在庫）
  • replica（少し前の在庫）
• 前半は「やり直しで事故が起きる」話、後半は「速く読むと少し古いかもしれない」話

■ 3. Rustを読むための最低限の知識

• struct（構造体）: 関連するデータをまとめる箱
  • 例: OrderRequest（注文番号・金額）、ChargeRecord（課金記録）
• enum（列挙型）: 「この中のどれか1つが起きる」と表すための型
  • 例: GatewayStep::TimeoutAfterCommit、TemporaryFailure、Success
• match（分岐）: 状態ごとにどう振る舞うかを決める書き方
• HashMap（辞書）: 「キー → 値」で覚える辞書
• 今回の目的はRustの文法を覚えることではなく、何を記録して、どこで分岐して、どう安全にしようとしているかを読めるようにすること

■ 4. テーマ1: やり直し（Retry）だけでは危ない

• 問題の核心:
  • タイムアウトが返ってきたとき、呼び出し元からは「返事がない」としか見えない
  • 返事がない原因は3つあり区別できない: (a)リクエストが途中で消えた (b)相手が止まっていた (c)相手は処理したが返事が消えた
  • 今回のコードが再現するのは(c)のケースで、決済サービスは内部的に成功扱いの記録を残しているのに、呼び出し元には失敗に見える状態
• retryのコード動作:
  • CheckoutServiceはタイムアウトを見たら素直にやり直す
  • 最大回数まで繰り返し → gateway.chargeで課金を依頼 → 成功（Ok）なら終了、タイムアウト（Timeout）なら次の回へ、回数を使い切ったら諦める
  • このコードだけ見ると自然だが、実際は成功済みだったら同じ課金をもう一度してしまう
• 実行結果（冪等性なし）:
  • charges: 2 / total_amount: 10000 → 5000円の注文なのに10000円引かれる（二重課金）
• 問題の本質: 失敗したことよりも、成功したのか失敗したのかを決めきれないことが難しい
• 解決策: 冪等性（べきとうせい / Idempotency）
  • retryをやめる工夫ではなく、成功したか失敗したか分からない場面でも事故を増やしにくくする工夫
  • 「このrequest_idはもう処理した」と覚えておけば、同じ依頼が再送されても2回目は捨てられる
• 冪等性のコード実装:
  • 確認: self.processed.contains_key(&request.request_id) → 処理済みなら何もせず「成功」を返す
  • 記録: .entry(...).or_insert(...) → 初めての依頼なら課金してrequest_idを記録する
• 実行結果（冪等性あり）:
  • charges: 1 / total_amount: 5000 → 正しい金額のまま
• 結論:
  • retryは止まりにくくするための道具（一時的な失敗から復帰しやすくなる）
  • 冪等性は「成功したか分からない場面」で事故を増やしにくくする道具（やり直しによる二重実行を抑える）
  • 分散では「止まりにくさ」と「二重実行しない」を組み合わせて守る

■ 5. テーマ2: 速さと最新性は両立しにくい

• リーダーベースレプリケーションの仕組み:
  • 書き込みはLeader（元データ）に行き、変更内容がFollower（複製）に流れる
  • 読み取りはFollowerからもできるので速い
  • ただし流れが追いつくまでは古い値が返る可能性がある
• サンプルのInventoryStore構造:
  • primary（プライマリ）: まず更新される、元の在庫
  • replica（レプリカ）: あとから追いつく、読むためのコピー
  • 書き込みはprimaryのみ、読み取りはprimaryまたはreplica
• 1回の流れ:
  • 最初はprimaryもreplicaも在庫3
  • purchase_on_primary()でprimaryだけ2になる
  • まだreplicaには反映されないので3のまま
  • replicate()を呼ぶとreplicaも2になる
• 実行結果:
  • primary stock right after purchase: 2
  • replica stock before replication: 3（古い）
  • replica stock after replication: 2
• replicaを使うことのトレードオフ:
  • 得られるもの: 読み取りを速くしやすい、混雑を分散しやすい
  • 失うかもしれないもの: 最新の値をすぐには見られない、場面によっては危険
• 場面による使い分け:
  • 商品一覧画面: 多少古くてもよい（速さが大事）→ replicaでよい
  • 購入確定直前: 古い在庫は危険（最新性が大事）→ primaryを見たい
  • どちらが正しいかは技術の好みではなく、その場面で何を守りたいかで決まる
• 同期・非同期レプリケーションのトレードオフ:
  • 同期レプリケーション（複製が終わるまで待つ方式）: 待ちが増える
  • 非同期レプリケーション（待たずに進める方式）: 古い値が見える
  • 速さを取りにいくほど、どこかで待つか、どこかで古さを受け入れるかの判断が必要

■ 6. テーマ3: コードを全部自分で書かない時代になぜ必要なのか

• コーディングエージェントが速くできること:
  • 画面やAPIの雛形を作る
  • テストコードをたたき台から書く
  • リファクタリングを進める
  • 定型的な実装をつなぐ
• 人が決めること（自動では決まらないこと）:
  • どこまでretryをしてよいか
  • timeoutを本当に失敗とみなしてよいか
  • 冪等性が必要な操作はどこか
  • primaryとreplicaをどの場面で使い分けるか
• 難しさはコードを書く量の問題ではなく、どう壊れるかと何を守るかの問題として残る
• 人に残る仕事は「決めること」と「確かめること」:
  • timeoutとsuccessが食い違う場面を想像できる
  • やり直しが二重実行を生む危険を説明できる
  • replicaの古さを許せる場面と許せない場面を分けられる
  • エージェントが書いた実装が、その考えに合っているか確かめられる
• エージェント時代に価値が上がるのは、何を守るかを決めて、大きい事故を小さい不便に変えられているか確かめる力

■ 7. 判断を残すためのADR（Architecture Decision Record）

• ADRとは: 大げさな設計書ではなく、何を決めて、なぜそうしたかを短く残すためのメモ
• ADRが必要な理由: 設計は図だけ見ても理由が分からなくなる
  • 図だけ残る場合: 「なぜそうしたのか」があとで読めない
  • ADRがある場合: 背景、決めたこと、その結果をあとから追える
• ADRの構成要素（4つ）:
  • Title（題名）: 何を決める話なのか
  • Context（前提）: どんな困りごとがあるのか
  • Decision（決めたこと）: 何を選ぶのか
  • Consequence（結果）: 何がよくなり、何が増えるのか
• ADRの記述例:
  • Title: Retry時の二重課金を防ぐためrequest_idを使う
  • Context: timeoutのあとにretryすると同じ課金が重なることがある
  • Decision: request_idで同じ依頼かどうかを見分ける
  • Consequence: 実装は少し増えるが、二重課金の事故を減らしやすくなる
• ADRは問題と判断と結果を短くつなぐメモだと考えると扱いやすい
• コードを自分で全部書かない時代ほど、その理由を短く残しておく価値が上がる

■ 8. まとめ・持ち帰ってほしいこと

• コードは短くても、設計の問題は見える（大規模な本番システムでなくても、本質は小さなサンプルで観察できる）
• 便利な仕組みにも別の困りごとがある（retryもreplicaも、それだけで安心とは限らない）
• 設計は「大きい事故」を「小さい不便」に変える仕事（どう壊れるかを先に考えて、何を守るために何を引き受けるかを決める）
• 基礎編との対応:
  • タイムアウト（Timeout）: 相手が成功しても、こちらからは失敗に見えることがある
  • やり直し（Retry）: 止まりにくくできるが、状態が読めない場面では事故も増える
  • 冪等性（Idempotency）: retryを入れても二重実行しにくくする
  • 一貫性（Consistency）: primaryは最新の値を返しやすい
  • 遅延（Latency）: replicaは速いが、少し古いことがある

(2026/04/19)

deleted_atにインデックスを雑に貼ったら本番DBが死んだ

• deleted_atにインデックスを雑に貼ったら本番DBが死んだ

(2026/04/18)

古典ドメインモデルパターンの解脱

• 古典ドメインモデルパターンの解脱

• Chapter 01 はじめに
• Chapter 02 古典ドメインモデルパターン
• Chapter 03 その構成の何が問題か
• Chapter 04 アウトサイドイン開発とBean Validation
• Chapter 05 パースとバリデーションを同時に行う
• Chapter 06 二つのアプローチの比較
• Chapter 07 Always-Valid Layer という切り口
• Chapter 08 未検証→検証済みという状態遷移
• Chapter 09 ドメインモデルから関心を分離する
• Chapter 10 データ詰め替え戦略の全体像
• Chapter 11 結合強度と距離のバランス
• Chapter 12 デコーダがレイヤーをつなぐ
• Chapter 13 既存コードへの導入
• Chapter 14 設計の重さを測る判断基準
• Chapter 15 付録: Raoh APIリファレンス（本書で使用するもの）
• Chapter 16 付録: 参考文献

本書は13章と付録で構成されています。

• 「問題の正体」（1〜2章）: 古典ドメインモデルパターンがどう見えるか、そこに潜む問題は何かを整理します。
• 「Parse, Don't Validate」（3〜5章）: Bean Validation の限界と、パースしてバリデーションと型変換を同時に行う Raoh デコーダのアプローチを示します。
• 「Always-Valid Layer」（6〜8章）: 「常に正しいデータだけが流れる層」という切り口から、状態遷移の型表現と、関心を分離したドメインモデル（record）を示します。
• 「結合のバランス」（9〜11章）: レイヤー間の詰め替え戦略と結合強度・距離の軸を整理し、デコーダがレイヤー間の接点として機能することを示します。
• 「実践」（12〜13章）: 既存コードへの段階的な導入手順と、どの設計を選ぶかの判断基準を示します。
• 付録: Raoh API リファレンスと参考文献。

初めて読む方は1章から順に読み進めることをお勧めします。既に Parse, Don't Validate や Always-Valid Layer に馴染みがある方は、9章から読み始めても意味が通るように書いています。

(2026/04/18)

DebConf 14: QA with Linus Torvalds

• DebConf 14: QA with Linus Torvalds - YouTube

要約:

■ 1. 概要

• Linus Torvaldsを招いたQ&Aセッションの書き起こし(場所はDebianカンファレンス)
• Linuxカーネル開発・ディストリビューション・ライセンス・セキュリティ等の幅広いテーマについて質疑応答が行われた

■ 2. Linuxディストリビューションと個人的な利用環境

• 2007年のインタビュー以降もDebianをインストールしたことはない
• ディストリビューションは「インストールが容易で作業の妨げにならないこと」が最重要との立場
• Ubuntuは試したがmake installが機能しなかったため断念した
• 個人の作業環境はWebブラウザと3つのターミナルウィンドウのみという極めてシンプルな構成
• 家族のマシンを管理する必要があるため一度使い始めたディストリビューションからの変更が困難

■ 3. Linuxデスクトップの普及問題

• アプリケーションのパッケージングがLinuxデスクトップ普及の最大の障壁
• Windowsや macOS向けにはバイナリを提供できるがLinux向けは困難な状況
• 問題の本質はディストリビューションごと・バージョンごとに異なるバイナリが必要になること
• glibcをはじめとする共有ライブラリが頻繁にABIを破壊することが根本原因
• カーネルにおける「ユーザ空間を壊さない」という唯一の絶対ルールをディストリビューションが守っていないと批判
• ValveがLinuxデスクトップを救う可能性があると期待:
  • 複数バイナリを作成せず静的リンクを使用するため各ディストリビューションも対応せざるを得ない
  • ゲーム自体よりもこのバイナリ配布モデルの実証が重要

■ 4. アプリケーションのバイナリ配布問題

• gitやsparseのような問題と異なり本質的に複雑であり短期間での解決は困難
• 解決策として現状は静的リンクと独自ファイルシステムの同梱が現実的
• Dockerコンテナを用いたアプリケーション配布の可能性に期待
• アプリケーションに求められる要件:
  • グラフィックライブラリやOpenGLなどのUI要素
  • USB・シリアルポート・Bluetooth等のハードウェア直接アクセス
  • Javaのような移植性重視の環境ではハードウェアアクセスが困難

■ 5. ディストリビューションに対する改善要望

• タイムゾーン設定や無線プリンタへの接続など日常操作に管理者権限が不要になること
• 一般ユーザが管理者権限なく作業できる環境を整備してほしい
• ディストリビューションのパッケージ管理者はコアパッケージに集中すべきであり小規模プロジェクトのパッケージ管理は工数の無駄

■ 6. コミュニティにおけるコミュニケーションスタイル

• 自身の攻撃的な言動を認めつつ文化的背景や個性の違いを理由に変える意思がないと表明
• 敬意は与えられるものではなく獲得するものという立場
• オープンソースでは合わない人物を避け自分に合う協力者を選べる利点がある
• 「政治的正しさ」を優先するあまり技術的品質が低下したプロジェクトの存在を懸念

■ 7. systemD

• 予想に反してsystemDを嫌いではないと表明
• 評価する点:
  • Unixのinitシステムの問題を解決した
  • 起動速度の向上は実質的な成果
• 批判する点:
  • バグレポートが無視される事例がある
  • Linuxカーネル固有技術への依存によるポータビリティの欠如

■ 8. GCCのバージョンについて

• 問題となっていたGCCの特定バグはカーネル側で修正済み
• インラインアセンブリを使用しないプロジェクトへの影響は限定的
• GCC 4.2以降のバージョンはおおむね問題なし

■ 9. revokeシステムコールの実装

• 実装に向けた提案パッチを確認中
• CFSと共通のインフラ基盤を使用できる可能性があり設計上の利点
• 実装は確実に行われる見込みだが次バージョンへの搭載は未確定

■ 10. ドライバ開発とioctlの問題

• ioctlはバイナリ互換を破壊しやすい設計上の問題を内包
• 典型的な問題:
  • 32ビットと64ビット環境でデータ型のアライメントが異なる(例: dma_addr_t)
  • ioctl呼び出しのデータ構造変更によるABI破壊
• ドライバ開発者がこれらの問題を認識していないケースが多く理解できるが残念
• GPUレイヤーはかつて同様の問題で被害を受けた後改善された事例がある

■ 11. 後方互換性の維持

• 1991年当時のバイナリが現在も動作するという実績がある
• 真の互換性問題は古いバイナリではなく現代の複雑なバイナリで発生
• UI関連ライブラリのほうが低レベルコードより互換性が壊れやすい
• ライブラリのバグ修正が依存アプリケーションを壊す具体例:
  • glibcがmemcpyの未定義動作への依存を修正したことでAdobe Flash Playerが動作しなくなった
• カーネルでもバグ修正が結果的に互換性を破壊する事例は発生しており完全な保証はできない
• 商用環境では2年遅れでカーネルを使用するケースがあり破壊が遅れて発覚することがある

■ 12. GPL v3とライセンス

• GPL v2の理念: ソースコードを提供する代わりに変更点を還元するという対等な関係
• GPL v3を強く批判する理由:
  • Tivoization条項により「ソースを渡しても自分のデバイスで使えない」状態が生じ得る
  • これはGPL v2の精神に反する
  • FSFがTivoization条項の無効化について不誠実な説明を行ったと批判
• 対応: Linuxカーネルを意図的に「GPL v2のみ」と明示しGPL v3への自動アップグレードを阻止
• GPL v3は別の目的のために選択するライセンスとしては有効であるという立場
• BSD/ISCライセンスは「コードを自由に使ってほしい」という目的に適している

■ 13. FSFへの評価

• FSFの一部の人物を「過激で視野が狭い」と批判
• 寄付先としてはEFFを推奨
• GPL v3をめぐるFSFの説明には不誠実な点があったと明言

■ 14. gitの発展

• gitの現在の成功はJunio Hamano(2006年頃から保守担当)の貢献によるところが大きい
• 良い技術者を見極める基準として「センス(taste)」があるとし、Junioにそれを認めた
• 分散型バージョン管理のモデルが広く受け入れられた
• GitHubがgit普及に大きく貢献した:
  • ホスティングを容易にした
  • オープンソースへの参入障壁を下げた
• かつて批判されたUI上の設計(リネームの扱い等)が後から正当性を認められた

■ 15. セキュリティへのアプローチ

• セキュリティコミットをコミットログに明示的に記載することに反対:
  • 攻撃者が最初に読むのがコミットログであるため情報提供になりかねない
  • あらゆるバグはセキュリティバグになり得るため区別に意味がない
• SELinuxへの評価:
  • かつてはパフォーマンスへの悪影響が深刻だったため無効化していた
  • 現在は改善されており有効化した状態で性能問題を修正した
• セキュリティは単一の層で解決できるものではなくカーネル・ユーザランド双方の多層防御が必要
• セキュリティ研究者(ブラックハット含む)の技術力を高く評価しつつも過度に白黒思考な姿勢を批判

■ 16. 世界観と現状認識

• 公の場での発言が批判的に見えるのは問題発生時にのみ発言するためであり基本的には楽観的
• かつて批判したNvidiaも現在はLinuxカーネルに積極的に貢献するようになった:
  • Android市場の重要性を認識したことが態度変化の主因
• Linux全体として良い方向に進んでいると評価

(2026/04/17)

「1.58ビットに進化したから8GBで十分ですよ。任せてくださいよ」とBonsaiが言うのでMacBook Neoに...

• 「1.58ビットに進化したから8GBで十分ですよ。任せてくださいよ」とBonsaiが言うのでMacBook Neoに組み込んでその性能差を体感。iPhoneでも楽々動くしで、ローカルAIが超進化中（CloseBox） 7枚目の写真・画像 | テクノエッジ TechnoEdge

要約:

■ 1. Ternary Bonsai (1.58ビット) の概要

• PrismMLが1ビットBonsai 8Bの後継として「Ternary Bonsai」を発表
• 1.58ビットとはlog₂(3) ≈ 1.585に由来し、ウェイトが{-1, 0, +1}の三値を取る構成
• 0（何もしない）という選択肢が加わることでスパース性が生まれ、ネットワークの表現力が向上
• マイクロソフトのBitNetと同様のアプローチに基づく

■ 2. 性能比較

• メモリ消費:
  • Bonsai 8B (1-bit): 1.15 GB
  • Ternary Bonsai 8B (1.58-bit): 1.75 GB
  • Qwen3 8B (FP16): 16.38 GB
• ベンチマーク平均スコア:
  • Bonsai 8B (1-bit): 70.5
  • Ternary Bonsai 8B (1.58-bit): 75.5
  • Qwen3 8B (FP16): 78.2
• 600MB増（53%増）でスコアが5ポイント（7%）向上
• FP16モデルの約9.4分の1のメモリでほとんどの実用シナリオを網羅
• MMLU Redux・MuSR・GSM8K・HumanEval+・IFEval・BFCLv3の広範なベンチマークで均等にスコアが向上

■ 3. 動作環境と導入方法

• MLX形式のみ対応（Apple Siliconネイティブ）
• HuggingFaceモデルID: prism-ml/Ternary-Bonsai-8B-mlx-2bit
• 標準のmlx-lmパッケージで動作し、PrismMLのフォーク版ビルドやXcodeは不要
• 起動コマンド一行で初回実行時にモデルが自動ダウンロードされOpenAI互換APIサーバが起動
• 8GB MacBook Neoでの動作結果:
  • 生成速度: 19.3 tok/s
  • ピークメモリ: 2.365 GB

■ 4. mazzaineoへの統合

• mazzaineoのMODEL_REGISTRYに1行追加するのみで統合完了
• 既存のOpenAI互換バックエンドを流用しポート8082を1-bit Bonsaiと共有
• UIのモデルセレクタとサブタイトルが自動切り替えに対応

■ 5. 使用感

• 日本語応答の丁寧さとテキスト接続のスムーズさが1-bit Bonsaiより向上
• 短い質問への回答では差が少なく、複数ステップの推論やTool Calling連鎖で差が顕著
• エージェンティックAIとして使用する場面での文脈保持能力が向上
• 速度は1-bit Bonsai（21.1 tok/s）よりやや劣るが、M4 Proでは82 tok/s出るとPrismMLが発表

■ 6. 8GBマシン向け推奨構成

• 品質最重視: Ternary Bonsai 8B（1.75GBで75.5点、Tool Calling完璧）
• 品質重視: Bonsai 8B (1-bit)（1.15GBで70.5点、最小フットプリント）
• 速度重視: Ollama Qwen3 8B（kv-cache量子化が有効）
• Vision用途: Qwen 3.5 4B / Gemma 4 E2B（カメラ・スクリーンキャプチャ対応）
• 軽量会話: Qwen 2.5 3B（最軽量、エージェント不要時）

■ 7. スマートフォンへの展開と今後の展望

• iOSのメモリ制限により1-bit Bonsai 8Bが実用に至らなかったiPhoneで、1.58-bit版の4B・2Bモデルが選択肢に
• iPhone用LLMクライアント「Locally AI」ではすでにTernary Bonsai 8Bが配信開始
• Qwen 3.6も登場し、1-bit・1.58-bit・量子化等による最適化と基盤モデルの進化が並行して進行
• オープンソースのエージェンティックAI「Agent」が公開
• mazzaineoのMCPエージェント化を実施済み

(2026/04/17)

アンソロピック辞めた研究者｢世界は危機に｣　AI開発競争で理念が無力化

• アンソロピック辞めた研究者｢世界は危機に｣　AI開発競争で理念が無力化 - 日本経済新聞

要約:

■ 1. AI安全性研究者の相次ぐ離脱

• アンソロピックのムリナンク・シャルマ氏が2月に退職
  • 英オックスフォード大で機械学習の博士号を取得しAIの安全性研究に従事
  • 退職時に「価値観を行動の指針とする難しさ」を訴える手紙を公開
  • 「世界は危機に陥っている」と警鐘を鳴らす
  • 「知恵と影響力が釣り合わなければ代償を払うことになる」と警告
• オープンAIのゾーイ・ヒッツィグ氏も同月に退職
  • ChatGPTへの広告導入に反対して離職
  • 利用者のプライベートな悩みに基づく広告は「利用者を操ることになる」と批判
  • 「オープンAIはフェイスブックと同じ過ちを繰り返している」とNYTに寄稿
  • 「AI開発者はAIが引き起こす問題に先手を打てると信じていたが、オープンAIはそれをやめた」と指摘

■ 2. 危険性が高まるAI開発の実態

• アンソロピックが4月7日に「Claude Mythos（クロード・ミトス）」を試験公開
  • システム上の未知の欠陥を特定できるほど高性能
  • 銀行へのサイバー攻撃などへの悪用が懸念される
  • 公開先を一部に限定しベッセント米財務長官が大手銀行トップと緊急会合を開催
• オープンAIは赤字改善のため無料・低価格プラン利用者向け広告の表示を計画

■ 3. 理念と開発競争の乖離

• 各社の売上・企業価値が拡大する一方で安全や倫理への姿勢が揺らぎ始めている
• アンソロピックCEOのダリオ・アモデイ氏が1月公開のエッセーでAIの急速な技術革新が数年以内に深刻なリスクをもたらす可能性を表明
  • 雇用喪失・格差拡大・生物テロなど大量破壊兵器への悪用リスクを列挙
• アンソロピックはAIの軍事利用を禁じる方針を掲げながらもライバルのオープンAIが米国防総省と契約後に政府との協議継続を表明
• 「どれだけ崇高な理念があっても開発競争の前には無意味だ」（米グーグル社員）
  • 米国内のテック企業間競争に加え中国勢との争いも激化
  • 国際的な規制ルールが欠如した状態が続く

■ 4. ブレーキをかける主体の不在

• オープンAIが4月6日にAIが世界を変えるビジョンを政策提言として発表
  • 税制改革・週4日労働・保育強化などAIがもたらす社会変革のビジョンを提示
  • 国家レベルの安全基準策定など規制の必要性も訴える
• アンソロピックが4月2日更新の提言で開発プロセスの透明性と超知能モデルのリスク制御を強調
• トランプ大統領が政府によるAI強制停止のための「キルスイッチ」保有を主張（4月15日放送のインタビュー）
• 米連邦議会下院公聴会（2月24日）で民主党議員らが「AI対人類の問題」「労働者保護」について国務次官に質問
• 米国内の分断と米中対立が深まるなかで最適解は見いだせていない
• AIの急速な進化が人類に残す「考える時間」は長くないとの認識が広がっている

(2026/04/17)

社名こそ出せないが、氷河期新卒時代に常駐したとあるメーカーは下請けをゴミのように扱う...

• 社名こそ出せないが、氷河期新卒時代に常駐したとあるメーカーは下請けをゴミのように扱うところだった→ひどい扱いを受けた会社の製品は買わなくなるという話 - Togetter

要約:

■ 1. 概要

• Togetterまとめ「社名こそ出せないが、氷河期新卒時代に常駐したとあるメーカーは下請けをゴミのように扱うところだった→ひどい扱いを受けた会社の製品は買わなくなるという話」の内容
• 就職氷河期時代に大手メーカーへ常駐した元下請け社員が経験した職場環境の劣悪さと不買運動への発展を主題とする

■ 2. 発端となる投稿

• 投稿者:クワタ (@kuwataku)
• 就職氷河期の新卒時代に常駐したメーカーにおいて下請け社員がゴミのように扱われていたと告発
• 日常的なパワーハラスメントの具体例:
  • 頭を押しのけて「どけよ」と言われることが日常茶飯事であった
  • 精神的に追い詰められメンタルヘルスが悪化した
• 社名は明かさないとしながらも「富士通の製品だけは絶対に買うまいと心に誓っている」と明言
• フォロワーのコメントにより富士通であることが示唆される構造となっている

■ 3. 反応と共感の広がり

• 投稿に対し多数のユーザーが同様の体験を共有:
  • asaji:富士通において女性・若年層への職場いじめを目撃したと証言
  • Yunsaurus:富士通でのパワーハラスメント・セクシャルハラスメント経験を報告
  • HiLack:三菱電機における下請け蔑視の実態を告発
  • tiny_ynz:N社での不当な扱いを言及
• 企業名を明かさない投稿でも文脈から企業が特定される現象がコメント内で指摘される

■ 4. 不買運動の論点

• 不当な扱いを受けた企業の製品を永続的に購入しないという「報復的消費行動」が複数ユーザーにより表明される
• 対象企業は富士通・三菱電機・トヨタグループ系など複数業種にわたる
• 「当時の下請け蔑視を行った当事者が現在も同企業に在籍・出世しているため恨みが持続する」との見解が示される
• 就職氷河期における労働環境の劣悪さが現在進行形の消費行動に影響を与えていることが示される

MEMO:

• 日立系もヤバイ人多かった
• というより、2000年代まではパワハラやセクハラの概念自体が希薄だったのもある
• 現代において当時の振る舞いをやれば即コンプラ問題になるものばかりであった
• それに過剰適応した下請け企業は元請けに平伏低頭みたいな人間も多く醜悪であった
• なのでIT産業においてはSIerが侮蔑と共に語られ、WEB系に人材が流出する流れが起きた

(2026/04/17)

Linux 7.0カーネルにおけるPostgreSQL性能劣化問題、その後の動向

■ 1. 発端

• Linux 7.0開発カーネル上でPostgreSQLのスループットが約半減する性能劣化が報告された
• 報告者はAWSエンジニアのサルヴァトーレ・ディピエトロ（2026年4月3日 LKMLへ投稿）
• テスト環境: AWS EC2 m8g.24xlarge（Graviton4 / 96 vCPU）、PostgreSQL 17
• pgbench（simple-update / 1024クライアント / 96スレッド / 1200秒）の計測結果:
  • Linux 7.0（PREEMPT_LAZY）: 約50,751 TPS
  • 問題コミットをリバート後（PREEMPT_NONE相当）: 約98,565 TPS（約1.94倍）
• perfプロファイリングにより CPU時間の55%がPostgreSQLのユーザースペーススピンロック（s_lock）で消費されていることが判明

■ 2. 当初議論された原因

• Linux 7.0 rc1で導入されたカーネルスケジューラの変更が根本原因
• IntelのカーネルエンジニアPeter Zijlstraによるコミットがプリエンプションモードを制限
• 従来はサーバー向けに「PREEMPT_NONE」（プリエンプションなし・スループット最大化優先）が存在した
• Linux 7.0でx86・ARM64等の主要アーキテクチャからPREEMPT_NONEが廃止され「FULL」と「LAZY」の2モードのみに変更
• 廃止の目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進
• PostgreSQLはプロセスモデルを採用し共有メモリへのアクセスにユーザースペーススピンロックを多用する
• PREEMPT_LAZY環境ではロック保持中にタスクが中断される頻度が上がり他のプロセスが無駄にスピンし続ける

■ 3. 真の原因とAndres Freundの分析

• Andres FreundがLKMLスレッドを調査した結果、真の原因はスピンロック機構そのものではなくスピンロック保持中に発生するTLBミスとマイナーページフォルトであると判明
• 問題の連鎖:
  • Huge Pages未使用時、PostgreSQLの共有メモリは標準4KBページで管理される
  • 100GB超のバッファプールでは各ページへの初回アクセス時にマイナーフォルトが発生する
  • マイナーフォルトがスピンロック保持中に起きるとスレッドが失速し待機中の全スレッドがスピンし続ける
  • PREEMPT_LAZYは失速したロック保持者をスケジュールアウトすることがあり事態をさらに悪化させる
  • 根本問題は最初からページフォルトにあり、プリエンプションモードではない
• Huge Pages有効化により新旧どちらのカーネルでもスループットが同等（約185k TPS）になることが確認された

■ 4. 4KBページとHuge Pagesの比較

• ページサイズ:
  • 通常ページ: 4 KB
  • Huge Pages: 2 MB（x86）/ 1 GB（gigantic）
• 100GBバッファに必要なTLBエントリ数:
  • 通常ページ: 約2,600万
  • Huge Pages: 約5万
• TLBミス頻度:
  • 通常ページ: 高
  • Huge Pages: 大幅に低下
• スピンロック保持中のフォルト:
  • 通常ページ: 発生しやすい
  • Huge Pages: ほぼ発生しない

■ 5. Huge PagesとTHPの区別

• Transparent Huge Pages（THP）と明示的なHuge Pagesは別物
• THPはLinuxカーネルが自動でHuge Pagesを割り当てようとする機能でスワップ対象になり得る
• PostgreSQLには明示的に設定するHuge Pagesが推奨される
• PostgreSQL公式ドキュメントもTHPについて「一部のユーザー・一部のLinuxバージョンで性能劣化が知られており現在は非推奨」と明記している

■ 6. 具体的な設定手順

• OSレベル（明示的なHuge Pages予約）:
  • shared_buffersに必要なHuge Pagesページ数を計算する（例: 32GB ÷ 2MB = 16384ページ + 余裕分）
  • sudo sysctl -w vm.nr_hugepages=16500 で設定し /etc/sysctl.conf に永続化する
  • /proc/meminfo の HugePages_Total / HugePages_Free / Hugepagesize で割り当てを確認する
• PostgreSQL設定（postgresql.conf）:
  • huge_pages = on: 確実に使用（取得失敗時は起動拒否）
  • huge_pages = try: 取得失敗時は通常ページで起動（デフォルト）
  • PostgreSQL 15以降は SHOW huge_pages_status で実際の使用状況を確認可能
• THP無効化（競合防止）:
  • 明示的Huge Pages使用前にTHPを無効化しなければカーネルがTHPで共有メモリをマッピングし性能が不安定になる
  • /sys/kernel/mm/transparent_hugepage/enabled および defrag に never を書き込む

■ 7. 影響が限定的なケースとまとめ

• 影響が出やすい条件:
  • Huge Pages未設定
  • shared_buffersが数十GB以上の大規模構成
  • コールドスタート直後（ウォームアップ期間）
  • 高コアCPU（96vCPUなど）での高並列ワークロード
• Huge PagesまたはTHPを使用していればこのリグレッションはほぼ心配不要という見解がPostgreSQLメーリングリストでまとめられている
• 問題の本質は「PREEMPT_LAZYが悪い」ではなく「Huge Pages未使用環境でのTLBミスがスピンロックと組み合わさった時にPREEMPT_LAZYによって悪化する」という複合的なもの
• Huge Pagesを正しく設定すればLinux 7.0でも従来と同等の性能が得られることが実証されている

関連:

• Linux 7.0におけるPREEMPT_NONE削除問題に関するメモ
• Linux 7.0でPostgreSQL性能半減、修正困難か

(2026/04/17)

【スゴ本】開発現場で使える「良い問い」集

• 【スゴ本】開発現場で使える「良い問い」集 - レバテックLAB

要約:

■ 1. 概要

• ITエンジニアのコミュニケーションにおいて言葉の選択が結果を左右する
• 著者は「正確・論理的に説明すれば伝わる」という思い込みを克服し人への伝え方を変えた
• 人はコンパイラではなく立場・感情・文脈によって解釈が異なる
• 4冊の書籍から「ITエンジニアのピンチを救う言葉」を紹介する

■ 2. 「なぜ」ではなく「いつ」と問う

• 出典: 『「なぜ」と聞かない質問術』中田豊一 著
• 「なぜ」の問題点:
  • 問われる側に圧力・説明責任・問題の責任を押し付ける効果がある
  • 「なぜなぜ分析」は偶然性やプロセスの特殊性を無視し特定個人のミスを根本原因とする傾向がある
  • 繰り返されるとメンバーのモチベーションが萎縮しミスが報告されなくなる
• 「いつ」による事実質問の効果:
  • 「いつ設定を変えたか」「いつGOサインが出たか」と問うことで責任追及なしに事実を収集できる
  • 心理的圧迫を解消しながら責任の所在により速くたどり着ける
• 応用原則:
  • 事実質問は「考えさせるのではなく思い出させる」
  • 過去形・時間・主語を意識して問う

■ 3. 「なぜ」ではなく「うれしいのは」と問う

• 出典: 『伝わるコードレビュー』鳥井雪・久保優子・諸永彩夏 著 島田浩二 監修
• 力関係のある質問の問題点:
  • ベテランから新人への「このメソッドを使ったのはなぜ？」は意図不明で受け手を不安にさせる
  • 質問の背景・理由・求める回答を明示しないと意図が伝わらない
• 「うれしいのは」という問い方の効果:
  • 「このメソッドを使うとうれしいのは何？」とすることで「採用するメリットの主体」が明確になる
  • 「メリット」という言葉より誰にとっての価値かという焦点が鮮明になる
• 実践上の留意点:
  • コードレビューのコメントには質問の背景・意図・求める回答を含める
  • 評価軸の両面を言い換えるだけの問いより価値と結びつく主体を問う問いが有効

■ 4. 解くべき問題を見極める問い

• 出典: 『ライト、ついてますか』D.C.ゴース・G.M.ワインバーグ 著 木村泉 翻訳
• 「問題への飛びつき」の弊害:
  • 学校教育により最初に見つけた問題を素早く解こうとする癖がつく
  • 本当に解くべき問題かどうかを吟味せず固執すると誤った解決策に至る
• 問題再定義の方法:
  • 「問題文をどう変えたら解答を変えられるか」と自問する
  • チケット予約の例: 「予約処理を間に合わせる」ではなく「リクエストを受け付ける」に問題を再定義することで処理分離という発想につながる
• 「ライト、ついてますか」の事例:
  • トンネルでのバッテリー上がりの問題を「バッテリーが上がる」でも「消し忘れ」でもなく「ドライバーに気づいてもらう」と再定義した
  • ヘルプデスクの「コンセントを抜いて挿し直してください」も同様の問題再定義の実践例
• 本質: 問題の定義次第で解答はいくらでも変わる

■ 5. 「問題ない症候群」への対処

• 出典: 『スーパーエンジニアへの道』G.M.ワインバーグ 著 木村泉 翻訳
• 問題ない症候群の特徴:
  • 問題の内容を理解せずに「問題ない」と答える
  • 問題ではなく解決策を説明し始めた場合に症候群と判断できる
• 見分け方の手順:
  • 難しい問題を提示する
  • 「問題ない」と言われたら「その問題とは何か説明してください」と問う
  • 相手が解決策を説明し始めたなら症候群と判断する
• 著者の実体験:
  • データ移行プロジェクトで営業が「問題ない」と遮り代替データを提示
  • 移行ファイルに欠落・フォーマット崩れが多発しスケジュールが大幅遅延
  • 「その問題とは何か」と問うことで問題把握の有無を早期に確認できた
• 対処の原則:
  • 「問題ない」は思考停止ワードとして扱う
  • 「その問題とは何か分かっているか」という問いからリスタートする

■ 6. まとめ

• 良い問いの定義:
  • 事実と判断を明確にする
  • 価値と結びつく主体を明らかにする
  • 本当に解くべき問題に焦点を合わせる
  • 「私たちは何を解決しようとしているのか」というメタ的視点を与える
• 各書籍のエッセンス:
  • 「いつ」: 事実を炙り出し人による判断を一旦保留する
  • 「うれしいのは」: 質問の背景・意図を伝え回答者の価値判断基準を示す
  • 「解くべき問題はこれか」: 誰にとっての問題かによって解答が変わることを意識する
  • 「その問題とは何か」: 問題定義の曖昧さを放置しないための問い

(2026/04/17)

「ブラウザの戻るボタン→広告表示」がスパム扱いに　Google、6月にポリシー変更　違反で検索冷遇も

• 「ブラウザの戻るボタン→広告表示」がスパム扱いに　Google、6月にポリシー変更　違反で検索冷遇も - ITmedia NEWS

米Googleは4月13日（現地時間、以下同）、ブラウザの戻るボタンを押した際、すぐ元のページに戻さず、広告など意図しないページを表示する行為をスパムとして扱うと発表した。6月15日にGoogle検索のスパム対策ポリシーを更新する予定。違反した場合、Webサイトが検索上位に表示されにくくなったり、検索結果から削除されたりする可能性がある。

同様の行為が増加傾向にあるといい、「『Back Button Hijacking』（戻るボタンの乗っ取り）はブラウザの機能を妨害し、ユーザーの期待する操作を阻害し、ユーザーの不満につながる。最終的には見慣れないサイトを訪れる意欲が低下する」（同社）として、対策を強化する。

GoogleはWebサイトの管理者に対し、戻るボタンの挙動を妨げるようなスクリプトなどをポリシー更新までに削除・無効化するよう呼び掛けている。

MEMO:

• よいことだ
• とはいえ、もはやWEBサイトへの流入経路の大半はSNS経由になっているので、検索エンジン対策は切り捨ててバックボタンハイジャックを継続するという判断も成り立つような気がする

(2026/04/17)

The peril of laziness lost

• The peril of laziness lost | The Observation Deck

要約:

■ 1. プログラマの三徳とLaziness(怠惰)の本質

• Larry WallはProgramming Perlにおいてプログラマの三徳として「Laziness(怠惰)」「Impatience(短気)」「Hubris(傲慢)」を提唱した
• 三徳の中でもLazinessは最も深遠な徳であり「システムをできる限りシンプルにする」という美学を内包する
• Lazinessは表面的な怠惰ではなく高度な抽象化を生み出すための知的労働を意味する
• ハンモック・ドリブン開発と呼ばれる一見怠惰な思考作業は実際には問題を繰り返し検討する高度な知的プロセスである
• 優れた抽象化は自分自身だけでなく後継の開発者全員に恩恵をもたらし「より多くの人がより多くのソフトウェアを書けるようにする」ことに繋がる

■ 2. 現代におけるLaziness喪失の背景

• ソフトウェア開発の裾野拡大により自らをプログラマと呼ばない層が増加しLazinessの本来の意味が失われつつある
• 現代の高度な抽象化がもたらす生産性向上は「偽の勤勉さ」を重視する文化を台頭させた
• これはコードを大量生産することを礼賛する「brogrammer」文化として具体化した
• 皮肉なLazinessとハンモック・ドリブン開発は「コードをクラッシュする」ハッスル文化に取って代わられた

■ 3. LLMがもたらすLaziness喪失の加速

• LLMはソフトウェア開発者のあらゆる傾向をより強力に発揮させる増幅器として機能する
• brogrammer文化に対してLLMはアナボリックステロイドとして作用した
• Garry Tanが1日37,000行のコードを生産すると誇示した事例はこの問題を象徴する
• 実際にTanのプロジェクトを分析した結果として複数のテストハーネス・RailsのHello Worldアプリ・テキストエディタ・同一ロゴの8バリアント(うち1つはゼロバイト)が含まれていた
• コードを重量で評価するような指標の誤謬は初学者にも明白である

■ 4. LLMがLazinessを欠く構造的理由

• LLMは作業にコストを感じないため将来の自分や他者の時間を最適化しようとする動機を持たない
• 制約なく放置されたLLMはシステムを改善するのではなく肥大化させる
• LLMはパフォーマンスとは無関係な虚偽の指標に訴求しつつ本質的な品質を損なう
• 人間のLazinessが不可欠な理由は有限な時間という制約が「認知負荷を許容できる限度まで下げよう」という動機を生み出すからである
• 制約こそが最良のエンジニアリングを生む原動力であり時間的制約のないLLMはこれを自発的に行わない

■ 5. LLMを正しく活用するための指針

• LLMは重要なツールではあるがあくまでもツールに過ぎない
• 皮肉でも徳でもない「非生産的な怠惰」の側面(技術的負債への対処など)にLLMを活用することは有効である
• LLMはエンジニアリングの厳密性を高める目的で使用すべきである
• LLMの活用は人間の「徳としてのLaziness」に奉仕する形で行わなければならない
• 最終目標は自分自身だけでなく後続のソフトウェアエンジニア世代に貢献するシンプルかつ強力なシステムを生み出すことである

(2026/04/16)

手戻りを防ぐ、AI駆動プロダクト企画開発プロセス

• 手戻りを防ぐ、AI駆動プロダクト企画開発プロセス - Tabelog Tech Blog

(2026/04/15)

3つの「AI精神症」――投資家のAI妄想、経営者のAI妄想、そしてAI批判者のAI妄想

• 3つの「AI精神症」――投資家のAI妄想、経営者のAI妄想、そしてAI批判者のAI妄想 » p2ptk[.]org

要約:

■ 1. 「AI精神病」という用語の定義と背景

• 「AI精神病（AI psychoses）」はチャットボットによって誘発・増幅された妄想を抱く人々を指す比喩的用語
• 医療問題と隣接するため将来的に廃止が予測されるが現時点では有用な比喩として機能する
• 妄想そのものは新しい現象ではなく歴史的先例が存在する
  • モルゲロンズ病：体内でワイヤーが成長するという妄想であり17世紀に遡る
  • 集団ストーキング妄想：陰謀集団が隠しメッセージを送り込むという信念であり数世紀前から存在する
• インターネットはまばらに分布する同種の妄想を持つ人々の連帯を可能にし妄想を増幅させる
• LLMは昼夜を問わず即座に迎合的な応答を返すことで妄想をさらに深層へと引き込む
• 一過性の認知の誤作動をチャットボットに説明させることで完全に誤った信念体系（妄想）が構築される危険がある

■ 2. 投資家のAI精神病

• AIは史上最大規模の投資バブルを形成しており6000〜7000億ドル以上が投じられている
• AIは劣悪なユニットエコノミクスを持つ
  • ユーザが増えるごとにコストが増加する
  • 利用するたびに損失が拡大する
  • 技術世代が進むほど損失が増加する
• AI企業の全売上を合わせても年間600億ドル程度であり黒字化への道筋が存在しない
• データセンター・GPUの実際の耐用年数（2〜3年）を5年と偽る会計詐欺が横行している
• 「ビザンティン・プレミアム」：投資機会があまりにも複雑で投資家が理解できないために騙されやすくなる構造が成立している
• 損失の大きさを投資の魅力に転換するナラティブが機能している
• 巨大テック企業は自社市場の飽和後にメタバース・Web3・暗号通貨・AIと投機的新規事業を乗り継ぎ成長ナラティブを維持し続けている

■ 3. 経営者のAI精神病

• 経営者は労働者を代替できるものなら何にでも飛びつく傾向がある
• AIは「全ての出力が自分に直接帰属する」という経営者の自己顕示的妄想を強力に刺激する
• チャットボットが労働者の仕事をこなせないという事実よりもボスを説得できるという事実の方が重要な結果をもたらす
• 人間をAIで代替した結果が壊滅的な事例（AWSの障害など）が現実に発生している
• AIセールスマンは経営者の妄想をさらに深化させ企業全体をその妄想に賭けさせる

■ 4. 批判者のAI精神病

• 批判者のAI精神病とは「AIは例外的にひどいテクノロジーだ」という信念
• これはAI企業の誇大宣伝を批判として繰り返す「クリティハイプ（criti-hype）」の一形態
• AIはふつうのテクノロジーであり例外的な性質を持たない
  • 環境コストや雇用への脅威はバブルによるものであり技術自体の性質ではない
  • 問題のある人物や機関がテクノロジーを推進することは歴史上一般的な現象
  • チャールズ・バベッジは奴隷農園管理のために汎用コンピュータを発明した
  • エイダ・ラブレスは競馬の賭けのためにプログラミングを考案した
  • ウィリアム・ショックレーはシリコントランジスタの共同発明者でありながら優生学者だった
  • IBMはアウシュビッツ用タビュレータを製造した
• AIの例外性という主張を増幅することはAI企業のバブル維持を助ける結果になる
• AI企業の罪は株式詐欺と労働者の困窮化にあり人類の知識をスクレイピングすること自体ではない
• サム・アルトマンらはふつうの詐欺師であり例外的な大悪魔として扱うことは彼らの評判を高めるだけ

■ 5. 自動化の二形態とテクノロジーの政治性

• 自動化には二種類が存在する
  • 速く安く作るための自動化：資本が好む形態
  • より良いものを作るための自動化：労働者が好む形態
• ケンタウロス：機械を使って人間の目的を達成する形態（自動はんだ付け機を活用するホビイスト）
• 逆ケンタウロス：機械の周辺機器として人間が酷使される形態（組立ラインの労働者）
• テクノロジーに政治が埋め込まれているのは事実だが単純・明白・不変ではない
• 労働者が自らの判断で自動化ツールをどう使うかを決められる世界の方がよりよい
• 逆ケンタウロスは経営者の決定がもたらす結果であってテクノロジーがもたらす結果ではない

■ 6. AIをふつうのテクノロジーとして扱うことの帰結

• 多くの熟練した実践者がAIをプラグインのような普通のツールとして活用している
• これらの実践者はAIを神やセラピストと取り違えておらず控えめな熱意で受け入れている
• 熟練した労働者の実体験を否定することは正当でない
• AI以前の自動化ツールにもプログラマを誤った方向に導くものは存在しており例外ではない
• AIが例外的だという信念は批判者を誤った方向へと追い込む
  • 熟練の実践者が特定のツールを使うべきかどうかについてツールの道徳的性格に基づいて判断するという誤りを犯す
• 例外的ではないからこそ他のテクノロジーを律するのと同じ力学がAIにも当てはまる
• AI製品の有用性は何をするかによって決まり誰が作ったかや資金の出所には依存しない

(2026/04/14)

ハーネスエンジニアリングはただの環境構築では？

• ハーネスエンジニアリングはただの環境構築では？

要約:

■ 1. ハーネスエンジニアリングの概要

• 「ユーザの想定通り・望み通りに動くような環境」を作る試みとして定義される
• 2026年1月〜2月頃からZennで散見されるようになった概念である
• AIエージェントの挙動制御のための環境構築を指す

■ 2. 著者の問題提起

• 著者はわざわざ用語を作るほど困難な話なのかという懐疑的立場をとる
• SubAgentやAgent Skillなどの概念がすでに存在することから「制御が難しい」という議論に疑問を呈す
• 「ハーネス」という表現に違和感を示し「Boundaries（境界）」や「Permitted（許可・権限）」の方が正確だと主張する

■ 3. ハーネスの語源

• 語源として以下の2つが挙げられる:
  • 犬の安全装置
  • 高所作業の墜落制止用器具
• 両者に共通する解釈として「安全に事を為す装置」が導き出される

■ 4. OpenAI側とarXiv論文側の主張

• OpenAI側（Codex実験）の主張:
  • 「環境の設計と意図の明確化」によるフィードバックループ構築を強調する
  • 制御システムの設計による環境整備を重視する
• arXiv論文側の主張:
  • 制御ロジックを「自然言語の実行可能アーティファクト（NLAH）」として外部化することを提案する
  • モジュール化と体系的な研究対象化を目指す

■ 5. 両者の共通点と相違点

• 共通点:
  • モデル性能よりも「制御構造」が成果を左右するという見解を共有する
  • フィードバックループの重要性を重視する
• 相違点:
  • 構築手法が異なる（制御システム設計 vs 自然言語ベースのモジュール化）

■ 6. 結論

• ハーネスエンジニアリングは「AIエージェント挙動制御のための環境構築」である
• 単なる環境構築にとどまらず終わりのない継続的なプロセスである
• AIの進化への「追随」が必要とされる点が従来の環境構築と異なる

(2026/04/14)

Harnessing Claude's Intelligence | 3 Key Patterns for Building Apps

• Harnessing Claude's Intelligence | 3 Key Patterns for Building Apps | Claude

要約:

■ 1. 概要

• Anthropicが2026年4月2日に公開したブログ記事であり Claudeを用いたアプリケーション構築における3つの中核パターンを示す
• 知性・レイテンシ・コストのバランスを取りながらモデルの進化に対応する設計思想を論じる

■ 2. パターン1: Claudeが既に知っていることを活用する

• bashやテキストエディタなどClaude が熟知しているツールを優先的に活用する
• Claude 3.5 Sonnetはこれらの基本ツールのみを用いてSWE-bench Verifiedで49%のスコアを達成した
• Claudeは汎用ツールをプログラマティックなツール呼び出しやメモリ機能など多様なパターンへと組み合わせる

■ 3. パターン2: 「何をやめられるか」を問い直す

• Claudeの能力向上に伴いエージェント設計の前提を継続的に見直す必要がある
• オーケストレーション:
  • どのツール出力を処理すべきかをClaudeがコンテキストウィンドウを通じて判断できるよう委譲する
  • すべての結果をオーケストレーターに戻すことを必須とする設計を廃止できる
• コンテキスト管理:
  • タスク固有の指示をスキルを通じて段階的に開示するプログレッシブディスクロージャーを採用する
  • 全情報を事前ロードする方式から移行できる
• メモリの永続化:
  • コンパクションやメモリフォルダを通じてClaudeが記憶対象を自律的に選択できるようにする
  • ゲームのプレイログを例として挙げ 旧世代モデルが全履歴を記録していたのに対し 新世代モデルは戦術メモを生成するようになった変化を示す

■ 4. パターン3: ハーネスによる境界設定

• 高いセキュリティや可観測性が求められる箇所では専用ツールを設け静的コンテンツを先頭に配置するなどキャッシュ最適化を行う
• ユーザー確認や監査証跡が必要な高リスクな操作は型付きツールに昇格させセキュリティ上の判断をハーネスで強制する

■ 5. 主要な示唆

• モデルの能力が向上するにつれて旧来の設計上の前提が「不要な重荷」となり蓄積する
• コンテキストリセットによる「コンテキスト不安」の解消など かつて有効だった手法がより高性能なモデルでは不要になる例を示す
• 開発者は能力の進化に応じて設計上の前提を継続的に再評価することが求められる

(2026/04/14)

TechLead Conference 2026

• TechLead Conference 2026 powered by connpass - connpass

MEMO:

• 登壇者の顔ぶれが豪華だ
• 配信はしてくれないのだろうか

(2026/04/13)

GoのAPI開発が変わる！GinやChiに乗せるOpenAPI層「huma」の魅力

• GoのAPI開発が変わる！GinやChiに乗せるOpenAPI層「huma」の魅力

humaの本当の立ち位置は、「GinやChiなどの既存ルーターの上に乗せて、型安全なリクエスト処理とOpenAPIドキュメントの自動生成を提供する層」 なのです。

huma自体はHTTPリクエストのルーティング（URLパスと関数の紐付け）を行いません。ルーティングは Gin、Chi、Echo、あるいは標準の net/http に任せます。humaは、そのルーターの「ハンドラー（コントローラー）」として機能し、以下の役割を担います。

1. リクエストの型安全なパースと自動バリデーション
2. レスポンスの型安全なシリアライズ
3. Goの構造体（コード）からのOpenAPI 3.1仕様書とJSON Schemaの完全自動生成

つまり、humaは 「HTTPパッケージのようなもの」ではなく、「GinやChiをFastAPIのように進化させるための拡張パーツ」 と捉えるのが正解です。

MEMO:

• よさそう

(2026/04/13)

LINEヤフーは“社員の失望”とどう向き合うのか…フルリモートを約束→廃止の企業に求められる「優秀層...

• LINEヤフーは“社員の失望”とどう向き合うのか…フルリモートを約束→廃止の企業に求められる「優秀層の退職を防ぐ制度設計力」（曽和 利光） | マネー現代 | 講談社

要約:

■ 1. LINEヤフーの出社回帰方針とその背景

• 2026年4月に赤坂オフィスを開設し週3回出社を原則とする体制への移行を公表
• 2020年に旧ヤフーが「コロナ収束後もフルリモートを継続する」と発信した過去投稿との整合性を問う声がSNS上で噴出
• 組織人事コンサルタントの曽和利光氏はこの決定を「共創と育成を取りにいく強い経営意思の表明」と位置づけつつ採用ブランドや心理的契約という見えにくい資産への影響を伴う繊細な経営判断と評価

■ 2. 納得なき変更が生じさせる代償

• 心理的契約の問題:
  • 組織行動論における心理的契約とは雇用契約書に書かれない相互期待すなわち「約束だと信じられているもの」を指す
  • DeniseRousseauの整理によれば心理的契約は当事者が「約束がなされた」と信じることで成立しその違反認知は態度と行動をマイナス方向に変える
• SNS投稿の影響:
  • 法的拘束力はないが期待形成としての効果は文書化された規程に劣らないほど強い
  • 一度形成された期待は後日の方針変更を「裏切られた」と受け取られやすくする
• 「事実として違法でないこと」と「心理的に納得されること」は別物であり納得が得られなければエンゲージメントが低下し優秀層から静かに離職していく

■ 3. 人事のプロが提言する7つの対策

• 第一：見直し条件の明示:
  • 「何が起きたら出社を増やす・減らす」をKPIとセットで提示する
  • 意思決定リードタイムやエンゲージメント・離職意向などの指標を社内に開示し定期的にレビューする
  • 出社が「信仰」ではなく「仮説検証」となることで納得性が生まれる
• 第二：例外を制度として扱う:
  • 育児・介護・治療・障害・遠隔居住は多くの企業で常態であり例外ではない
  • 基準・手続・守秘・更新をルール化し現場上長の恣意に任せない
• 第三：代償措置と経過措置の用意:
  • 転居猶予・段階導入・遠距離通勤者への補助・サテライトやコワーキングの活用を講じる
  • 就業規則の不利益変更における合理性判断でも代償措置は重要な考慮要素となる
• 第四：出社日の業務内容の工夫:
  • 出社日にはオンボーディング・コードレビュー・部門横断の意思決定など対面の必然性が高い活動を集約する
  • 集中作業はリモートに寄せることでハイブリッド勤務が機能する
• 第五：評価制度との整合:
  • 出社の多寡が評価に影響するように見えた瞬間に心理的安全性が崩れる
  • 近接性バイアスを避けるためのガードレールを明文化し管理職への教育を実施する
• 第六：データ開示と対話プロセス:
  • Gartnerの調査では出社回帰が離職を増やすことへの懸念はHR側で広く共有されている
  • サーベイ・タウンホール・個別相談窓口などで社員の声を拾う仕組みを先に設置し決定後も改善を継続する
• 第七：採用戦略のアップデート:
  • 職種別にリモート比率の高い役割を残す・地方拠点やサテライトを組み合わせる・転居支援とセットにするなどの再設計が必要
  • 国土交通省の令和7年度調査でテレワーク実施率は増加傾向に転じており候補者のリモートワーク志向は消えていない

■ 4. 問われるのは「決め方」と「直し方」

• 週3回出社・フルリモートいずれが正解かは職種構成・評価制度・管理職の力量・出社日の設計によって異なる
• 経営や人事に求められるのは決定そのものではなく以下の能力:
  • なぜそう決めたかを言語化できること
  • 例外と代償をどう設計するかを示せること
  • データに基づいて修正する勇気を持つこと
  • 社員と候補者に対して誠実に説明し続けられること
• 出社回帰の波の後にも別の最適解が現れる可能性があり「変化を扱える組織」をつくることが経営・人事部門に求められる最大の責務

(2026/04/12)

60年前から存在するメモリの欠陥を克服し、レイテンシーを削減する新たな手法「Tailslayer」が登場

• 60年前から存在するメモリの欠陥を克服し、レイテンシーを削減する新たな手法「Tailslayer」が登場 - GIGAZINE

要約:

■ 1. 背景: DRAMのリフレッシュ問題

• DRAMはキャパシタに蓄えられた電荷の有無で「0」と「1」を判別する仕組み
• キャパシタ内の電荷は時間と共に失われるため「リフレッシュ」作業が定期的に必要
• リフレッシュ中はメモリへのアクセスが不可となる
• CPUがリフレッシュ中にメモリアクセスを試みると数百ナノ秒〜数マイクロ秒の待機時間が発生
• この問題は1966年のDRAM考案時から60年以上にわたり存在
• CPUのクロック数換算で数千クロック分に相当し金融などリアルタイム性重視の分野で問題視

■ 2. Tailslayerの概要と開発者

• Google研究員のローリー・ワイアード氏がDRAMのリフレッシュ問題を克服するライブラリ「Tailslayer」を公開
• 書き込み時に複数の独立したDRAMチャネルへデータを複製する仕組み
• 読み込み時は全複製先アドレスへ同時に読み取り命令を送り最初に応答したデータを採用
• いずれかのチャネルがリフレッシュ中でも他チャネルから応答を得ることで待機時間を回避

■ 3. 技術的実装

• 実装方法:
  • メモリコントローラーが物理アドレスを扱う方式を統計的なタイミング測定によって特定
  • チャネルスクランブリングオフセットを用いてデータが異なるチャネルに配置されるよう書き込みを実施

■ 4. 性能評価

• AMD EPYC 9255での検証結果:
  • 複製数に応じて2〜6段階でレイテンシー分布を測定
  • 6箇所複製の設定では最悪ケースでもレイテンシーを250ナノ秒程度に抑制
• 複数プラットフォームでの検証:
  • AMD・Intel・GravitonなどさまざまなCPUとメモリの組み合わせで効果を確認
  • いずれの環境においても6複製時にレイテンシースパイクを回避
• 99.99パーセンタイル点でのレイテンシーを最大15分の1まで削減

■ 5. 活用用途

• 高頻度取引(HFT)など極めてわずかな遅延が大きな影響を与える分野への活用が見込まれる

(2026/04/12)

アーキテクチャモダナイゼーションとは何か

• アーキテクチャモダナイゼーションとは何か - Speaker Deck

要約:

■ 1. 発表の概要

• 発表タイトル: 「アーキテクチャモダナイゼーションとは何か ― 技術・事業・組織で大事なこと」
• 発表者: nwiizo（株式会社スリーシェイク所属のソフトウェアエンジニア）
• 発表の軸: Nick Tune「アーキテクチャモダナイゼーション」（翔泳社, 2026）およびSusanne Kaiser「Architecture for Flow」（Addison-Wesley, 2025）の2冊
• 目的: 「モダナイゼーション」の実体を掴み、なんとなくではなく構造で判断する軸を持ち帰ること

■ 2. 発表の構成と前提

• 技術・事業・組織の3軸を同時に動かすことが主題
• 技術軸: 何を変えるか（境界・結合・疎結合の本質）
• 事業軸: なぜ変えるか（ドメイン・進化段階・投資判断）
• 組織軸: 誰が変えるか（チーム設計・認知負荷・文化）
• 1つだけ動かせば残り2つが設計図を上書きするという構造的問題を提起
• 本フレームはすべての組織に当てはまるわけではなく、文脈によって3軸のバランスは変わる
• 「3軸同時」は完璧解ではなく自組織の盲点を可視化する装置として活用すべき

■ 3. 設計判断が間違う構造

• 技術・事業・組織それぞれに「よくある語られ方」が存在し、一見正しく聞こえるが構造的に間違っている
• 技術の「よくある語られ方」:
  • 「マイクロサービスにすれば速くなる」「疎結合にしよう」「コンテナ化すれば運用が楽になる」といった語り方が典型
  • 手段の名前が出た瞬間に「なぜそうすべきか」を考えなくなる
  • 成功事例には生存バイアスがあり、失敗した企業の声は聞こえない
• 事業の「よくある語られ方」:
  • 「DXを推進する」「売上20%増」「リリース速度2倍」は目標であって戦略ではない
  • 「うちもAIを入れないと取り残される」という周囲に流される意思決定が起きる
• 組織の「よくある語られ方」:
  • 「Spotifyモデルを導入した」「Team Topologiesに基づいて再編した」は他社のアーキテクチャをコピーするのと同じ問題
  • 「チームを再編しよう」「アジャイルを導入しよう」は仕組みの導入として語られるが、組織図を変えても報告ラインが変わるだけ

■ 4. 各軸で間違う構造の本質

• 技術で間違う構造:
  • 技術の名前には「正解感」があり、名前が判断の代わりを務める
  • 文脈を無視して手段だけを借りることが根本的な誤り
  • 技術の名前が出た瞬間に「なぜ」が消えるなら、それは選定ではなく信仰
• 事業で間違う構造:
  • 分析を省略するほうが簡単なため、標語で済ませてしまう
  • 判断基準がなければ残るのは同調圧力だけとなり、隣の会社がやっているという理由で投資判断が下される
  • 診断を省略した目標設定は速いのではなく雑なだけ
• 組織で間違う構造:
  • 掲げた言葉ではなく実際に起きたことを信じるのに、言葉だけ変えて行動を変えない
  • 仕組みに変化を任せることが誤りであり、見えやすいものを変えて見えにくいものを放置するのは変革ではなく自己満足
  • 組織図を変えるのは簡単だが難しいのは人の行動が本当に変わること

■ 5. 技術への情熱とBVSSHフレームワーク

• 技術への情熱がなければ設計は前に進まない
• 信仰が常に間違うわけではなく、熱量がすべてを凌駕することもある
• アーキテクチャモダナイゼーションにはBVSSHというフレームワークが存在する
• BVSSHの5軸: Better（品質）、Value（価値）、Sooner（速度）、Safer（安全性）、Happier（幸福）
• 開発者の幸せはオマケではなく5軸のひとつ
• 問題は信仰そのものではなく、信仰が「なぜ」を省略する口実になること

■ 6. アーキテクチャモダナイゼーションの定義

• マイクロサービス化でもクラウド移行でもない
• 技術は名前で判断を代替し、事業は周りに合わせて走り出し、組織は仕組みに変化を任せる構造はすべて3つの軸のうち1つだけを語り残りを無視している
• アーキテクチャモダナイゼーションとは技術・事業・組織の現状をそれぞれ正直に見直し、3つを同時に動かすこと
• リプレースでもリライトでもなく、3つの軸を同時に見直す終わらない営み

■ 7. 「同時に」でなければならない理由

• 3つの軸はつながっている
• どこでシステムを切るか（技術）はチームの分け方（組織）を決め、チームの分け方はどこに投資するか（事業）に縛られ、投資の判断はシステムの切り方に戻ってくる
• ぐるっと一周する関係だから1つだけ動かしても残り2つが元に引き戻す
• 「同時に」とは全部を一度に変えるという意味ではなく、何かを変えるとき他の2つにどう影響するかを考えながら小さく動かすこと
• 技術だけの改善計画・事業だけの戦略資料・組織だけの再編提案がバラバラに作られている組織はすでに部分最適の罠にはまっている

■ 8. 3つが同時に語られない理由

• 理由1 ― 専門の壁: 技術の話は技術者が、事業の話は経営者が、組織の話はマネージャーが語り、それぞれの専門が深くなるほど他の軸が見えなくなる
• 理由2 ― 具体性の罠: 3つを同時に動かしている組織は存在するが1人のエンジニアや事業責任者が語ることではなく、現場では複数の人が複数の軸を少しずつ動かしているため個々の具体例は抽象化しにくくカンファレンスで語れる形にならない
• 3つが互いに影響し合う現実をひとつの枠組みで語ることは本質的に難しい
• 3つを同時に語れる言葉はまだ誰も持っていないため、組織は3つを別々に語る分業を生む

(2026/04/11)

制約を設計する - 非決定性との境界線 / Designing constraints

• 制約を設計する - 非決定性との境界線 / Designing constraints - Speaker Deck

要約:

■ 1. 発表概要

• タイトル:「制約を設計する - 非決定性との境界線」(設計ナイト 2026)
• 発表者: 曽根壮大 (Have Fun Tech LLC 代表社員 / 株式会社リンケージ CTO兼COO)
• テーマ: LLMの非決定性という課題に対し、制約を設計することで決定性を確保するアプローチを論じる

■ 2. 非決定性との境界線

• LLMの非決定性の本質:
  • 同一インプットに対して実行ごとに異なるアウトプットが生成される
  • 複数回実行しても出力は不定だが精度は向上する
  • LLMは確率的に、人間は経験的に答えるという違いはあるが、どちらも同一アウトプットを保証しない
• 標準化による解決:
  • 標準化によって単純化・統一化が行われ、アウトプットのばらつきが揃い品質が向上する
  • 手順の標準化は手順書の作成を意味する
  • 入力の標準化としてテンプレート作成や判断分岐の網羅・対応行動の決定を行う
  • チェックリストによって必要な仕様を満たすことを確定させる
  • 暗黙知を明示的・測定可能・更新可能な仕組みに変えること(業務の言語化)
• 境界線の必要性:
  • 非決定性の高い状態から決定性の高い状態へ移行するためには境界線が必要
  • ソフトウェアはハードウェアのために非決定的な現実世界を仕様として決定する役割を担う
  • Webフォームが人間とソフトウェアの境界線として機能し、内部のREST API・バリデーション・ロジック・型・データベースは決定性の世界を構成する
  • 再現性を高めるためには境界線の設計が不可欠

■ 3. 制約が決定性を作る

• 基本原則:
  • ソフトウェアの世界における制約が境界線を作り、品質の担保と安全性を設計する
• 具体例(GeminiによるGoogleカレンダー操作):
  • 直接指示するだけでは品質が安定しない
  • Gemini → GAS → API → Googleカレンダーという経路に制約を設けることで安定化する
  • GASのバリデーションによってハルシネーションを防ぐ
  • APIレイヤーでエラー処理・リトライが実現できる
• ソフトウェアにおける境界線の設計例:
  • REST APIは責任境界線とセットで決定性を作る(CLIインターフェースも同様)
  • 標準入力のバリデーションが制約として境界線を形成する
  • アウトプットの品質が固定される(内部にLLMを含む場合は非決定性が維持される)
  • データ層には決定された事実が保存される(集計・分析の元データは揺らいではならない)
  • 契約プログラミングの概念と類似する
• 制約はガードレールとして機能し、AIが間違った方向に進むことを防ぐ

■ 4. 制約以外のアプローチ

• 制約はガードレールによってAIの方向性を制限するが、ゴールに直接導くわけではない
• ハーネスエンジニアリングも標準化の方向性の一つとして位置づけられる
• ゴールへ導くための手法:
  • テストコード: ソフトウェアに対する期待値を明確化する
  • オブザーバビリティ: ソフトウェアの振る舞いを可視化する
  • 境界線: ソフトウェアのスコープを決める(ドメインモデルと同義)
  • アウトプットの品質指標: コードの方向性を決める(ただし安易な指標はグッドハートの法則を招く。LLMも同様)
• モデルが変わると設計が陳腐化する課題があるため、コミュニティの集合知を活用することが現実的な対策となる

■ 5. おわりに

• ソフトウェアエンジニアの役割の変遷:
  • これまで: 人間のあいまいな要求を仕様として決定してきた
  • 今後: 人間とAIの非決定性をソフトウェアとして決定していく
• AIの発展と人間の学習:
  • AIがどれほど発展しても、仕事の形は変われど抽象度を高める視点は変わらない
  • 知識のある者がAIを活用できることは確かである
  • 理由: 良い質問をするための知識が必要 / AIの出力を評価する能力が必要 / 抽象的なアドバイスを活用する能力が必要
  • AI普及後も人が学ぶことの重要性は変わらない
• 変化への対応:
  • 半年後の状況は予測できないからこそ、変化できる設計が重要
  • 「どうでもよいことは流行りに従い、重大なことは標準に従い、ドメインのことは自分ら設計する」(郡山昭仁)
  • 不易流行(松尾芭蕉): 変わらない本質を大切にしつつ時代の変化に応じた新しいものを取り入れる
  • 温故知新(孔子): 過去の事実を研究し新しい知識や見解をひらく
• 結論: 眼の前の問題を解決できるのは自分自身であり、現実と設計を楽しむことが重要

(2026/04/11)

Rails: 個人開発環境の Docker 化をやめた理由（翻訳）

• Rails: 個人開発環境の Docker 化をやめた理由（翻訳）｜TechRacho by BPS株式会社

MEMO:

• Macが悪いのでは

(2026/04/11)

Ubuntu 26.04（resolute）の開発; 要求スペックの変更とUbuntu Mateの新メンテナ募集

• Ubuntu 26.04（resolute）の開発; 要求スペックの変更とUbuntu Mateの新メンテナ募集 | gihyo.jp

これまでは4GBメモリが要件となっていたため、「⁠Windows 11よりも多くのリソース（特に、6GBメモリ）を要求する」ということでいろいろな技術サイトでさまざまな話題になっています。

なんとなく言葉遊びとして不毛な部分もありつつ、「⁠Windows 11の新規インストール要件はTPM2.0などのより複雑な要件（＝比較的新しいCPUが搭載された環境）を要求する」「⁠そもそもメモリを消費するのはアプリケーションで、特にWebブラウザがどれぐらいのメモリを消費するかが支配的」といった点が議論されており、「⁠古くなったマシンをLinuxデスクトップを用いて再生する」といった捉え方がまだまだ残っていた、ということがわかります（Xubuntu, Lubuntuは2GBメモリが最低要求なので、「⁠メモリが少ないマシン」での利用はこれらを使うことになるでしょう⁠）⁠。

MEMO:

• Firefoxはメモリ消費量がかなり大食いなので6GBだとすぐにメモリ枯渇してしまうと思われ、実用上は16GBかそれ以上欲しいところである

(2026/04/11)

アダムバック、「自分はサトシではない」と調査報道を否定

• アダムバック、「自分はサトシではない」と調査報道を否定（あたらしい経済） - Yahoo!ニュース

ブロックストリーム（Blockstream）のCEOであり暗号学者のアダム・バック（Adam Back）氏が、自身がビットコインの創設者サトシ・ナカモト（Satoshi Nakamoto）であるとの指摘を否定した。同氏は4月8日、自身のXアカウントで「自分はサトシではない」と投稿した。

この発言は、米紙「ニューヨーク・タイムズ（The New York Times）」が同氏をサトシ・ナカモトの有力候補とする調査報道を掲載したことを受けたものとみられる。同報道は、サイファーパンク（Cypherpunk）のメーリングリストにおける過去の投稿データや文体の類似性などをもとに分析したものだが、同氏をサトシと断定するものではない。

バック氏は投稿で、自身が1990年代初頭から暗号技術や電子マネー、プライバシー分野に関心を持ち、サイファーパンクの議論に参加してきた経緯を説明した。そのうえで、自身がサトシと結び付けられる背景について、発言量の多さなどにより関連性が過大に評価される「確証バイアス」の可能性を指摘している。

また同氏は、自身を含む複数の研究者がビットコインに類似するアイデアに取り組んでいたとし、「サトシが誰であるかは分からない」と述べた。さらに、ビットコインにとって創設者の正体が不明であることは望ましい側面もあるとの見解を示している。

なおビットコイン創設者の正体を巡っては、これまでも複数の人物が候補として取り沙汰されてきたが、いずれも決定的な証拠は示されていない。

(2026/04/10)

ここんところのWeb界隈についての主観的記録

• ここんところのWeb界隈についての主観的記録

要約:

■ 1. JSフレームワーク戦争の帰結

• ReactがVue.jsとの競争に勝利した
• 採用企業の増加が正のループを形成しフロントエンドエンジニアの実用的武器となっている
• 学習者には特別な事情がない限りReactを優先して習得することを推奨する

■ 2. Vercelの台頭とNext.jsの優位

• Next.jsがNuxtとの競争に勝利した
• Vercel社はフレームワークから実行環境まで一手に引き受けるプラットフォーム事業を展開している
• NuxtもVercel傘下に収められている状況にある

■ 3. Pax Reactia（パクス・リアクティア）とフレームワーク倦怠感

• 著者の造語「Pax Reactia」はReactを中心とした安定期を表す
• State of JSのデータがフレームワークへの満足度低下を示している
• フレームワークは成熟に伴い高度化し習得難易度が上昇している
• 革新的機能よりも個別最適化型の地味な新機能が主流になると予想される
• 技術変化の速度が過去と比較して鈍化しつつあるという認識を示している

■ 4. JSランタイム・開発環境競争の激化

• Node.jsに代わる候補としてDeno・Bun・Biome・Vite+が競争を繰り広げている
• 将来的にNode.jsが過去の技術として語られる可能性を示唆している

■ 5. Tailwind CSSの功罪

• 功績:
  • CSS設計の煩雑さからの解放に貢献した
• 問題点:
  • 根源的なCSS設計の問題をJavaScriptに肩代わりさせているに過ぎない
  • フレームワークを使わないプロジェクトでは効果が限定的である
  • CSS設計がロストテクノロジー化する懸念がある

■ 6. ネイティブCSSによるJavaScript代替の進展

• ネイティブCSS技術の進歩によりJavaScriptが不要なCSS機能が増加している
• JavaScriptを個別実装するより容易であるため積極的活用を推奨する
• ネイティブ技術であるため支援技術との相性がよくアクセシビリティの向上にも寄与する

■ 7. AIとWeb開発の関係

• AIの影響によりフロントエンド専門エンジニアが不要になる可能性がある
• 一方でフロントエンドの知見なしにはAIを適切に活用できないため引き続き必要とされる可能性もある
• 両方向の可能性が相反する形で共存している状況にある

■ 8. 現状認識のまとめ

• フロントエンドの最先端部分は安定しつつある
• 根本部分はいまだ不安定な状態が継続している

(2026/04/10)

「OpenSSL」なのに……次期バージョン「OpenSSL 4.0」で「SSL 3.0」対応が完全削除

• 「OpenSSL」なのに……次期バージョン「OpenSSL 4.0」で「SSL 3.0」対応が完全削除 - 窓の杜

「OpenSSL」の次期バージョン「OpenSSL 4.0」では、「SSL 3.0」（Secure Sockets Layer version 3.0）サポートが完全に削除される。開発チームが4月7日（米国時間）、公式ブログで発表した。

「OpenSSL」は、インターネット通信で用いられる暗号化実装を提供するオープンソースのライブラリ。SSL/TLSプロトコルの実装をはじめ、暗号化、復号、証明書の管理といった機能を提供する。

「OpenSSL」は1998年12月の誕生当初から「SSL 2.0」（SSLv2）と「SSL 3.0」（SSLv3）の両方をサポートしてきた。つまり、「SSL 3.0」は四半世紀以上前の古い暗号化プロトコルということになる。その設計の古さから、「POODLE」脆弱性をはじめとする多くの問題が指摘されて久しい。

そのため、「SSL 3.0」は「RFC 7568」（2015年6月発行）で廃止が勧告、「OpenSSL 1.0.2h」からはビルド時に既定で無効化されている。これまでは「SSL 3.0」を有効化してビルドすることもできたが、次期バージョン「OpenSSL 4.0」では「SSL 3.0」機能そのものが削除されるため、それも不可能となる。

また、これにあわせて「SSLv2 Client Hello」も廃止されるとのこと。「SSL 3.0」や「SSLv2 Client Hello」を利用しているアプリケーションは、サポートされているTLSプロトコルのバージョン（現時点では「TLS 1.2」または「TLS 1.3」）へ移行する必要がある。

なお、「OpenSSL 4.0」は3月24日の時点でベータ版に達している。このバージョンはもはや「SSL」をサポートしないが、「OpenSSL」の名前に変更はない。

関連:

• OpenSSLプロジェクトの品質問題や組織構造の変遷について
• The State of OpenSSL for pyca/cryptography

(2026/04/09)

Domain Modeling Made Functionalの読書メモ

• Domain Modeling Made Functionalの読書メモ

(2026/04/08)

AIのお世話が辛いのでUsecase Design Docを書く

• AIのお世話が辛いのでUsecase Design Docを書く - CADDi Tech Blog

(2026/04/08)

axios, LiteLLM...不使用だったのでOK、ではない。「次に備える」ソフトウェアサプライチェーン侵害への対策

• axios, LiteLLM...不使用だったのでOK、ではない。「次に備える」ソフトウェアサプライチェーン侵害への対策 - Speaker Deck

(2026/04/07)

Karpathy 氏が言語化した「LLM Knowledge Base」というパターン

• Karpathy 氏が言語化した「LLM Knowledge Base」というパターン | DevelopersIO

要約:

■ 1. 概要

• 2026年4月3日にAI研究者Andrej Karpathy氏がX上で「LLM Knowledge Bases」を投稿し1300万回以上の閲覧を集めた
• 翌日に詳細なアイデアファイルがgistとして公開された
• 多くの人がすでに類似の試みを行っていたことが大きな反響の背景にある
• Karpathy氏の投稿は散発的な試みに名前と構造を与えた

■ 2. LLM Knowledge Baseのコンセプト

• 生のドキュメントをLLMに渡し構造化されたMarkdownのwikiを「コンパイル」させるアイデア
• RAGが「質問のたびにドキュメント断片を検索して回答する」アプローチであるのに対し知識をあらかじめ構造化して永続化する点が異なる
• wikiは使うたびに育つため知識が複利的に蓄積される

■ 3. 3層アーキテクチャ

• Raw sources:
  • 記事・論文・リポジトリ・画像など不変の精選ドキュメント
  • Web記事はObsidian Web ClipperでMarkdownに変換し関連画像もローカルに保存することでLLMが参照しやすくなる
• Schema:
  • wikiの構造や規約を定義する設定ドキュメント
  • カテゴリの整理方法やファイル命名規則などのルールを記述するいわばwikiの「設計図」
• Wiki:
  • LLMが生成したMarkdownファイル群
  • Raw sourcesのサマリー・概念ごとのエンティティページ・バックリンクで構成される
  • 人間が直接書くことはほとんどなくLLMの領域であり人間はキュレーションと方向づけに集中する

■ 4. 3つの操作

• Ingest（取り込み）:
  • 新しいソースを処理してwikiに統合する操作
  • LLMがドキュメントを読みサマリーを書き関連エンティティページを更新しindex.mdを改訂する
  • 既存の知識との矛盾も解消される
• Query（質問）:
  • wikiに対して質問を投げ回答を得る操作
  • 回答を新たなページとしてwikiに「filing back」することで探索や質問がそのまま知識として蓄積される
• Lint（健全性チェック）:
  • wiki全体に対するヘルスチェック
  • 矛盾するデータ・古くなった主張・孤立したページ・欠落したリンクをLLMが検出し修正を提案する

■ 5. 意図的な抽象さ

• Karpathy氏自身がこれを「hacky collection of scripts」と呼んでいる
• 完成されたプロダクトでも確立された方法論でもなく探索段階の共有と位置づけている
• gistに「意図的に少し抽象的/曖昧にしている。方向性がたくさんあるから」と記載されている
• 概念としてはVannevar Bushが1945年に提唱したMemex（ドキュメント間の連想トレイルを辿る装置）に通じる

■ 6. RAGとの違い

• RAGはクエリごとにドキュメント断片を検索してLLMに渡すアプローチで永続的な構造を持たない
• LLM Knowledge Baseは事前に情報を読み込んで構造化し永続的なwikiとして保持する
• Karpathy氏は約100記事・約40万語規模ではRAGなしでもLLMがindex管理とサマリー維持をうまく行えると述べている
• ドキュメントが数千件・数百万語規模になると異なる可能性がある
• 「RAGかwikiか」は二択ではなくアドホックな質問にはRAG的検索が全体像の把握にはwikiが適するという使い分けが実用的

■ 7. Claude Codeでの実装例

• Karpathy氏の投稿以前からMem0によるfact抽出やベクターDBへのドキュメント蓄積・監査コマンドなどのセッション間知識永続化の仕組みを持っていた
• 既存のメモリ基盤の上にwiki層を載せる形で/kb-compileというカスタムコマンドを作成した
• ディレクトリ構成:
  • workspace/knowledge/ がRaw sourcesに相当（日報・リサーチ・セッションログ）
  • 各ディレクトリのCLAUDE.mdがSchemaに相当
  • workspace/wiki/ がCompiled Wikiに相当
  • Memory MCP（Mem0 + pgvector）という検索レイヤーも併用しRAG的検索とwikiの両方を使い分ける
• /kb-compileコマンドの機能:
  • 特定プロジェクトのみのコンパイルや--allオプションによる全体一括更新が可能
  • --lintオプションで矛盾検出・リンク切れチェック・古い記事の検出が可能
• コンパイルされた_index.mdに30プロジェクトの全体地図がまとまり新セッション開始時の状況把握に活用している
• 個々のプロジェクト記事にfrontmatterやバックリンクがありObsidianのグラフビューも利用できる
• 現状の課題:
  • 手動でコマンドを実行しないと更新されない
  • プロジェクト横断のトピック記事は未整備
  • Lintの自動実行が仕組み化できていない

■ 8. まとめ

• Karpathy氏の投稿の核心は「LLMをコンパイラとして使う」という発想の転換
• コードを書かせるだけでなく知識の整理・構造化・保守をLLMに任せる
• 人間は退屈な保守タスクから解放されキュレーションと方向づけに集中できる
• Karpathy氏は「hackyなスクリプトの寄せ集めではなくここには素晴らしいプロダクトが生まれる余地がある」と述べている

(2026/04/06)

実務経験ゼロでもシステムエンジニア　派遣会社が経歴詐称を強要　早期の退職で精神的苦痛

• 実務経験ゼロでもシステムエンジニア　派遣会社が経歴詐称を強要　早期の退職で精神的苦痛 - 産経ニュース

システムエンジニア（SE）の派遣会社に採用され、取引先で勤務した元SEの男性3人が、実務経験がないのに経歴詐称を強要されて精神的苦痛を受けたなどとして派遣会社代表らに賠償を求めた訴訟で、最高裁は、賠償を命じた東京高裁判決を不服とした代表らの上告を棄却した。原告の支援者らは「派遣会社は名前を変えながら従業員の経歴詐称を続けており、問題は終わっていない」と警鐘を鳴らしている。

男性らは、未経験者をSEとして採用するという求人広告などで、被告らが経営するSE派遣企業に入社した。

前後して、SEに必要な技術の習得を名目として、「スクール」の受講を求められ、受講料を支払ったが、SEとしての経歴を偽る「スキルシート」の作成や面接の練習をさせられたという。

男性らは、能力に見合わない多くの業務を担当させられて退職し、精神的苦痛から退職に追い込まれたとして提訴した。

令和6年7月の東京地裁判決は、未経験者を経験者と偽って派遣する代表らの事業は「詐欺行為により利益を得ようとするもの」と指摘。スクールは「詐欺を実現するための手段」で「社会的な相当性を欠く」と非難し、被告側に3人分計約516万円を支払うよう命じた。

東京高裁はおおむね地裁の判断を踏襲した上で賠償額を計約769万円に増額。最高裁も今年2月、代表らの上告を退け、高裁の判断が確定した。

原告の男性らの相談を受け付けた首都圏青年ユニオンの尾林哲矢執行委員長は、「この件は特殊な詐欺事件と思われるかもしれないが、相場賃金より高い相場を示して未経験者を募集するという点で、闇バイトと共通点がある」と指摘。「IT業界には多重下請け構造があり、派遣を受け入れた企業側のチェックにも問題がある」と述べた。

原告代理人の伊久間勇星弁護士は、「被告らはグループを組織して、一つがだめになれば新しい企業を作って活動を続けている。こうした手口は許されないという社会共通の認識を作る必要がある」と訴えている。

MEMO:

• 昔からある話ではあるが、裁判できっちり判決が下ったのはよいことだ

(2026/04/06)

EMにはチームを強くして欲しい

• EMにはチームを強くして欲しい - pospomeのプログラミング日記

要約:

■ 1. EMの責務

• EMの責務は「チームを強くすること」
• チームのボトルネックを特定し自身の作業時間をその解消に充てることが基本的なアプローチ
• 半年・1年後に「チームが強くなった」と言われ続けることがEMとしての価値
• EMの責務は「マイナスをゼロにする」と「ゼロをプラスにする」の2段階に分類される
• マイナスをゼロにする:
  • チームの状態が悪い際に目に見える課題（コミュニケーション問題・開発プロセスの停滞など）を一つずつ解決する行動
  • 課題が可視化されているため何をすべきかは比較的明確
• ゼロをプラスにする:
  • チームの状態が悪くない状況で潜在的なボトルネックを発見し解消する行動
  • 可視化された課題がない状態での発見が求められるため難易度が高い
  • AI活用による開発スピード向上のように「困ってはいないがさらに改善できる領域」への働きかけが例として挙げられる

■ 2. 強いチームの定義

• 「強いチーム」の定義に唯一の正解はなく離職率・開発スピード・人材の質など複数の軸が存在する
• 重要なのはEMのスキルセットとチームメンバーの特性に合致した定義を設定すること
• 現実から乖離した理想像では実現不可能なため自チームが実際に目指せる方向性を選ぶ必要がある
• チーム内で「この方向で強くなろう」という合意が取れている状態が望ましい

■ 3. EMのスキルセット

• EMのスキルセットは以下の4領域に大別される
• プロジェクトマネジメント:
  • スクラム等の開発プロセスを深く理解しスプリントゴール設定や改善サイクルを確立する能力
  • 外部ステークホルダーからの流入をコントロールしエンジニアが開発に集中できる環境を整える
• テクノロジーマネジメント:
  • 技術選定・方針決定における意思決定のガードレール設定やエンジニアの相談相手として機能する能力
  • 技術的負債や将来リスクを見据えた判断のサポートを含む
  • エンジニアリングの最低限の知識がなければ適切な育成・評価が不可能
• プロダクトマネジメント:
  • 仕様・ユーザー価値・事業的価値を理解しエンジニアリング観点での論点整理や仕様検討に貢献する能力
  • プロダクトを理解していないと管理だけして何を作っているか分からない状態になる
• ピープルマネジメント:
  • 採用: 組織に必要な人物像の定義と採用活動への主体的関与・社外アウトプットによる認知拡大
  • 育成: メンバーのWillとチーム課題を踏まえた成長・活躍のための育成計画設計
  • メンタリング: 日常的フィードバックを通じた心理的安全性とエンゲージメントの向上
• 理想は4つのスキル全てを最低限習得した上でいずれかに強みを持つこと
• 実際にはケースバイケースでありPdMが主担当する領域や優秀エンジニアがいる環境では求められる範囲が変わる

■ 4. EMと野球の監督の類比

• EMは野球の監督に類似した役割を担う
• 監督の目的「チームを優勝させる」はEMの「強いチームを作る」に相当する
• 監督のスキルや所属選手の特性によって目指すチームの形が異なる点は「強いチームの定義はEM・メンバーの特性に合わせて決める」という考えと一致する
• コーチ選定・練習メニュー設計・対戦相手分析など幅広い領域の理解が必要な点はEMに求める4つのスキルセットと対応する

■ 5. EMアンチパターン

• なんとなくスクラムイベントに参加しなんとなく1on1を実施してチームにポジティブな変化を与えないまま半年が終わる状態はアンチパターン
• 自分の時間をどう使えばチームにポジティブな変化をもたらし強いチームを作れるかを常に考えることが重要

(2026/04/05)

Bonsai-8Bに関するメモ

■ 1. Bonsai-8Bの概要

• PrismMLが2026年3月31日にステルスから公開した82億パラメータのLLM
• モデルサイズは1.15GBで同サイズの標準16ビットモデルの約14分の1
• エッジハードウェア上で8倍高速かつエネルギー効率は4〜5倍優れる
• Caltechのリサーチから生まれたスタートアップでKhosla VenturesやCerberusおよびGoogleが出資

■ 2. 1ビット量子化の特徴

• 全重みが−1または+1の2値のみで表現される
• 学習後処理ではなくネイティブの1ビット精度でゼロから学習される
• 埋め込み層・アテンション層・言語モデルヘッドを含む全層が1ビットで構成される

■ 3. 性能と動作速度

• ベンチマーク平均スコアは70.5点でフル精度8Bクラスモデルと競争力を持つ
• 知性密度(intelligence density)はQwen3 8B(0.10/GB)を大幅に上回る1.06/GBを達成
• 動作速度:
  • M4 Pro Mac: 毎秒131トークン
  • RTX 4090: 毎秒368〜440トークン(記載箇所により異なる)
  • iPhone 17 Pro Max: 毎秒約44トークン
• 標準的な16ビット8BモデルはiPhoneでは動作しないがBonsai-8BはiPhone上でネイティブ動作が可能

■ 4. 対応プラットフォームとハードウェア要件

• 必要メモリ: 約1.5GB(モデル本体1GB＋オーバーヘッド)
• 標準のllama.cppやLM Studioは1ビット重みに未対応のためPrismML提供の専用推論エンジンが必要
• Appleデバイス(Mac/iPhone/iPad):
  • MLXを通じてネイティブ動作
  • M1以降のMシリーズおよびA18以降のAシリーズチップ対応
  • 統合メモリ8GB以上が最低スペック
  • PrismMLのカスタムMLXフォークが必要
• NVIDIA GPU(Windows/Linux):
  • llama.cppのCUDA経由でネイティブ動作
  • CUDA対応GPUが必須でVRAM 2〜4GB程度で動作可能
  • ただし、標準のllama.cppやLM Studioは1ビット重みに未対応のため、そのままでは動作しない
  • PrismMLが提供するカスタムフォーク版のllama.cppまたはMLXが必要
• CPUのみ:
  • GPUは必須でなくモダンなCPUで推論可能
  • AVX2対応CPUで速度が向上
  • ただし、現時点ではCPUサポートが不完全で公式ベンチマークが存在しない

■ 5. モデルのバリエーションとライセンス

• 8Bのほか4Bと1.7Bのモデルも提供
• GGUF形式とMLX形式で利用可能
• Apache 2.0のオープンソースライセンス

■ 6. 用途と限界

• リアルタイム会話AI・コード補完・シンプルなエージェントタスクをローカルで処理可能
• プライバシー重視のアプリ・オフラインアシスタント・エッジデバイス・ロボティクスへの活用が期待される
• 多言語対応や複雑な推論が必要なワークロードではより大きなモデルに劣る

関連:

• 突如実用化した1ビットLLM Bonai-8B もう推論にGPUはほぼ不要になる。その先に何が起きるか

(2026/04/05)

突如実用化した1ビットLLM Bonai-8B もう推論にGPUはほぼ不要になる。その先に何が起きるか

• 突如実用化した1ビットLLM Bonai-8B もう推論にGPUはほぼ不要になる。その先に何が起きるか – WirelessWire & Schrödinger's

要約:

■ 1. Bonsai-8Bの概要と性能

• カリフォルニア工科大学(カルテック)のババク・ハッシビ教授率いる研究チームPrismMLが開発したLLM
• 独自の非公開日本語要約能力ベンチマークにおいて第3位の精度(ROUGE-L)を記録
• 第2位のQwen3:235b-a22bと比較して1/100のサイズ・10倍の推論速度を実現
• Googleが発表したGemma4と比較して精度1.25倍・速度3倍でありながらサイズは1/8〜1/10
• モデルサイズは1.2GB(80億パラメータ)でスマートフォン上での動作を実証
• Google・カルテック・ベンチャーキャピタルからの資金調達により開発を実現
• モデルは公開済みだが訓練方法は非公開

■ 2. 1-Bit LLM技術の意義

• Bonsai-8Bの極小サイズと高速推論を支える中核技術
• Microsoftが最初に本格開発したが商業的理由(GPU貸出ビジネスへの影響)から積極展開されなかった
• Bonsai-8Bは初の本格的かつ実用的な1-Bit LLMとして従来手法を凌駕
• 10GBサイズへ拡張した場合800億パラメータ相当のモデルが一般的なPCで動作可能となる計算
• その性能規模はDeepSeek-R1に匹敵しゲーミングPCやメモリ24GB搭載のMacで実用的に稼働する見込み

■ 3. ゲーム産業への影響

• AAAタイトル(大予算ゲーム):
  • 開発期間が数年に及ぶためAI活用の計画が困難
  • AI生成素材に対するスタッフやプラットフォームの慎重姿勢も障壁
• ハイパーカジュアルゲーム:
  • 基本無料の収益モデル維持のためオンデバイス計算が必須
  • 生成AIの本格組み込みが現状では困難
• 1-Bit LLMの普及により低予算ゲームへの生成AI統合が現実的になる可能性
• 将来的に画像・動画生成でも同様の小型化が進めば応用範囲がさらに拡大
• 著者は「AIゲームセンター構想」クラウドファンディングを個人プロジェクトとして開始

■ 4. コンテンツ・メディア産業への影響

• スマートフォン上で動作するエージェントAIが個人向けニュース番組を自動生成する時代が到来
• 著者自身がDGX Spark搭載マシン(約60万円)上でAgenticAI「Siki」を運用中:
  • 24時間ソーシャルメディアと最新論文を監視・解析
  • 数時間ごとに約10分のニュース番組動画を自動生成
• 現在は高性能マシンが必要だが1-Bit LLM普及後はスマートフォン単体で同等機能が実現される
• TikTok・InstagramなどのプラットフォームがオンデバイスAI生成コンテンツに移行した場合:
  • ネットワーク維持コストの大幅削減と収益性向上が見込まれる
  • インフルエンサーはAI生成の無限コンテンツとアイデア・根性で競合することを強いられる
• 固定コンテンツを発信するYouTuberや解説配信者も同様の競争圧力にさらされる

■ 5. 人間とAIの共存における価値の転換

• 画面内で完結するコンテンツはAI生成物に品質・体験の両面で対抗困難になる
• 映画DVDと比較してディズニーランドやユニバーサルスタジオが支持される理由の分析:
  • 静的な映像コンテンツと異なり共同体験は毎回異なる
  • 他の観客の存在やライブパフォーマンスが非再現性をもたらす
• 人間が求めるのは快感だけでなく共感であり共有体験の価値は今後も上昇
• アメリカではアーケード回帰の流れが生じ酒場とゲーム機を融合した「バーケード(Barcade)」文化が拡大:
  • Raw Thrills社はトップガン・マーベリック・ゴジラ・マーベル等を題材とした筐体を展開
  • 手軽なテーマパーク体験として機能
• モデル圧縮・小型化の流れはLLMに限らず全AIモデルに適用される不可避な潮流
• 著者がソフトウェアよりもゲームセンターという非効率な体験に注目する理由もこの文脈に基づく
• 1-Bit LLM時代の幕開けはAIと人類の関係における新たな時代の到来を象徴

(2026/04/05)

Linux 7.0におけるPREEMPT_NONE削除問題に関するメモ

■ 1. PREEMPT_NONEとは何か

• Linuxカーネルのプリエンプションモードの一つで、カーネルが原則としてタスクを強制中断しない設計
• プリエンプションモードの種類:
  • PREEMPT_NONE: ユーザー空間復帰時または明示的なschedule()呼び出し時のみ切り替わる
  • PREEMPT_VOLUNTARY: cond_resched()による任意の降伏点を随所に挿入
  • PREEMPT_LAZY: 通常はNONEに近いがスケジューラ判断でプリエンプト可能
  • PREEMPT_FULL: どこでもプリエンプト可能
  • PREEMPT_RT: スピンロックを含むほぼすべてをプリエンプト可能なリアルタイム対応
• スループット優先のサーバー向けとして長年利用されてきた

■ 2. PREEMPT_NONEが削除される理由

• PREEMPT_RTへの統合:
  • Linuxコミュニティは長年PREEMPT_RTのメインライン統合を進めており、カーネルの設計が「どこでもプリエンプト可能」を前提とする方向に移行中
  • PREEMPT_NONEはその前提と根本的に相容れない
• cond_resched()の乱用解消:
  • PREEMPT_NONEおよびPREEMPT_VOLUNTARYでは長時間CPUを占有するコードパスにcond_resched()を手動挿入する必要がある
  • Peter ZijlstraはこれをPREEMPT_LAZYへの移行により解消できると説明
• コードの簡素化:
  • 4〜5種類あるプリエンプションモードをFULLとLAZYの2種類に絞ることでカーネルの複雑性を大幅削減

■ 3. 変更の経緯と「急だった」とされる根拠

• 段階ごとの経緯:
  • 2004〜2024年: PREEMPT_RTプロジェクトが約20年を経てLinux 6.12でメインライン統合
  • 2024年9月: Linus TorvaldsがEurope Open Source SummitでPREEMPT_RTのメインライン受け入れを発表
  • 2024年11月: Linux 6.13にPREEMPT_LAZYが追加。この時点でPREEMPT_NONEは廃止されていない
  • 2026年1月: PREEMPT_NONEをLinux 7.0から廃止するパッチが投入
• 「急だった」とされる根拠:
  • PREEMPT_LAZY追加からPREEMPT_NONE廃止まで約2ヶ月しかない
  • PostgreSQLのような高競合スピンロックワークロードへの影響が事前に検証されていなかった
  • PREEMPT_RTのメインライン化（2024年9月）からPREEMPT_NONE廃止まで1年余りという短期間
  • Linux 7.0がUbuntu 26.04 LTSに採用される予定であり企業・サーバー環境への波及が大きいタイミング

■ 4. 性能劣化の構造とPostgreSQLへの影響

• PREEMPT_NONEの保証とPostgreSQL:
  • PostgreSQLは高競合のスピンロックを多用する設計であり「ロック保持中に中断されない」という保証が性能上クリティカル
  • PREEMPT_LAZYへの移行でAWSエンジニアがLinux 7.0リリース約2週間前に性能半減を報告
• Zijlstraの回答とその問題点:
  • 「PostgreSQL側でRSEQ（Restartable Sequences）のタイムスライス拡張を使え」と回答
  • RSEQタイムスライス拡張自体がLinux 7.0で初めて利用可能になったばかりであり移行コストを下流に一方的に押し付けている

■ 5. カーネルとPostgreSQL開発者間の過去の議論

• 2011年:
  • PostgreSQL開発者Robert Haasが「スピンロック保持中にプロセスがタイムスライスアウトされることが問題」と正確に分析・認識
• 2012年:
  • Linux 3.6でのスケジューラ変更によりpgbenchが3.5比で約20%低下
  • カーネル側の議論は「これはカーネルの問題」という前提で行われPgSQL側への修正要求はなかったとLWNが明記
  • PostgreSQL開発者Josh Berkusが「アプリ修正案は機能しない。旧バージョンのカーネルに留まり続けるユーザーが大量発生するだけ」と論証
• 2026年:
  • PREEMPT_NONEの廃止に際してカーネル開発者とPostgreSQL開発者間の事前正式調整が行われた形跡はない
  • 問題が表面化したのはAWSエンジニアがLinux 7.0リリース約2週間前にメーリングリストへ投稿したタイミング

■ 6. 「性急・強引」という評価の妥当性

• 「性急・強引」と言える根拠:
  • 置き換え先（PREEMPT_LAZY）の実績が不十分なまま廃止が進んだ
  • 解決策として提示されたRSEQがまだ実用可能でないタイミングでPREEMPT_NONEを廃止
  • LTSとの組み合わせが最悪のタイミングとなった
• 一概には言えない側面:
  • PREEMPT_NONEはロック保持中の割り込み排除のためカーネル全体の設計を複雑化させる面があった
  • PREEMPT_RTへの移行は20年越しで段階的に告知されており完全に唐突ではない
  • カーネル開発者の責務はシステム全体の健全化であり特定アプリケーションに合わせて設計を曲げることには限界がある
• 本質的な問題:
  • 技術的な正誤ではなく移行コストの分担の問題
  • 設計の方向性は正当だが移行を支える十分なベンチマーク・検証・猶予期間なしに進めた点は拙速
  • 「調整の仕組みが機能しなかった」と見るのが正確な分析

■ 7. Linus Torvaldsの立場

• 現状（2026年4月時点）:
  • 問題発覚から2日時点でLinusの公式発言はなく未関与
  • Linux 7.0安定版リリースは約1〜2週間後が見込まれるリリース直前のタイミング
• 2012年の先例:
  • 同種の問題に数時間で参加し「アイドルCPUを探すコストを削減する方向」などカーネル側での解決を主導
  • 当時の立場はZijlstraの今回の「PostgreSQL側で直せ」という回答とは対照的
• 今後のシナリオ:
  • 楽観的: 2012年と同様に性能リグレッションを受け入れずPREEMPT_NONEのデフォルト復帰か緩和策を求める
  • 悲観的: Zijlstraの立場を支持しリリースをそのまま進める
  • 中間: 今回のリリースはそのまま出しつつ次のサイクルで緩和措置を指示する

関連:

• Linux 7.0カーネルにおけるPostgreSQL性能劣化問題、その後の動向

(2026/04/05)

Linux 7.0でPostgreSQL性能半減、修正困難か

• Linux 7.0でPostgreSQL性能半減、修正困難か

要約:

■ 1. 問題の概要

• Linux 7.0の開発カーネル上でPostgreSQLのスループットが約半減する性能劣化が報告された
• AWSのエンジニア サルヴァトーレ・ディピエトロが2026年4月3日にLinuxカーネルメーリングリストへ報告
• テスト環境はAWS EC2 m8g.24xlarge（Graviton4 / 96 vCPU）でPostgreSQL 17を使用
• pgbench（simple-update / 1024クライアント / 96スレッド / 1200秒）の結果:
  • Linux 7.0（PREEMPT_LAZY）ベースライン: 約50,751 TPS
  • 問題コミットをリバート後（PREEMPT_NONE相当）: 約98,565 TPS（1.94倍）
• perfプロファイリングにより CPU時間の55%がPostgreSQLのユーザースペーススピンロック（s_lock）で消費されていることが判明

■ 2. 原因

• Linux 7.0 rc1で導入されたカーネルスケジューラの変更が根本原因
• Intelのカーネルエンジニア ペーター・ジルストラによるコミットが利用可能なプリエンプションモードを制限
• 従来はサーバー向けに「PREEMPT_NONE」（プリエンプションなし・スループット最大化優先）が存在していた
• Linux 7.0でx86・ARM64等の主要アーキテクチャからPREEMPT_NONEが廃止され「FULL」と「LAZY」の2モードのみに変更
• 目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進
• PostgreSQLはプロセスモデルを採用し共有メモリへのアクセスにユーザースペーススピンロックを多用する
• PREEMPT_LAZY環境ではロック保持中にタスクが中断される頻度が上がり他のプロセスが無駄にスピンし続ける結果となった

■ 3. カーネル開発者の対応方針

• ディピエトロはPREEMPT_NONEをデフォルトに戻すパッチを提出したが受け入れられなかった
• ジルストラはPostgreSQL側がRSEQ（Restartable Sequences）のタイムスライス拡張を活用すべきと回答
  • タイムスライス拡張はLinux 7.0で利用可能になったカーネル機能
  • アプリケーションがスケジューラに対してタスク切り替えの延期を要求できる仕組み
• リバートの見込みは薄く修正責任はPostgreSQL側に求められている
• PostgreSQLがRSEQのタイムスライス拡張を採用するにはコード変更が必要であり実現時期は不透明
• 少なくともLinux 7.0のリリースには間に合わない状況

■ 4. タイムラインと影響範囲

• Linux 7.0安定版リリースは4月中旬を予定
• Ubuntu 26.04 LTSのリリースは4月23日を予定
• Linux 7.0はUbuntu 26.04 LTSのカーネルとして採用予定
• LTSは企業・サーバー環境で広く使われるためPostgreSQL運用組織への影響が懸念される
• 今回のテスト条件は96 vCPU・1024クライアントという高負荷環境であり全構成で同影響が出るわけではない
• AWSのGraviton4のような大規模インスタンスはPostgreSQLの主要な運用環境であり影響を受ける環境は少なくない

■ 5. 過去の類似事例とパターン

• PostgreSQLとLinuxカーネルの性能摩擦は今回が初めてではない
  • 2010年: Linux 2.6.32のEXT4 fsync変更によりPostgreSQLの性能が大幅低下
  • 2008年: CFSスケジューラ導入後にpgbenchのリグレッションが報告
• カーネル開発者はシステム全体の設計改善を優先し特定アプリケーション向けの最適化を「アプリ側の責任」とする構造的パターンが繰り返されている
• Phoronixが2月に実施したLinux 7.0のAMD EPYCベンチマークではPostgreSQLの読み書き性能が大幅に向上していたとの報告もあり プリエンプションモデルの変更は環境やワークロードによって正反対の影響を与えうる

関連:

• 色々な面でコメントしたくなるな　・カーネル開発者はもう20年ぐらいPostgreSQL開発者にユーザーランド...
• Linux 7.0カーネルにおけるPostgreSQL性能劣化問題、その後の動向

(2026/04/05)

色々な面でコメントしたくなるな　・カーネル開発者はもう20年ぐらいPostgreSQL開発者にユーザーランド...

色々な面でコメントしたくなるな

・カーネル開発者はもう20年ぐらいPostgreSQL開発者にユーザーランドのspinlockは正気じゃないから考え直して欲しいと繰り返し要求していた

・linux kernel summitにPostgreSQL開発者を招待してディスカッションしたがうまくいかなかった。平行線というよりもPostgreSQL側が今こうなっている、実装したときはそれが一番性能よかったという話に終始していて、会話があまり建設的ではなかったと思う

・記事には「PostgreSQLはプロセスモデルを採用しており、共有メモリ上のデータ構造へのアクセスにユーザースペーススピンロックを多用する。」と書かれているが、マルチプロセスというのとスピンロックでないといけないは論理的につながらないと思う。なにか書き忘れてない？

・記事ではUbuntu 26.04 LTSへの影響を気にしているが、最近のUbuntuはPREEMT_DYNAMICかつデフォルトがpreempt voluntaryなので、影響ないのではないか？元々のバグ報告にあるAmaxonLinux2023はPREEMPT_NONEだから影響有るけど。RHELもRHEL9からPREEMPT_DYNAMICなので影響ないっぽい。SUSEも影響ないっぽいな。なら実質困るのはAmazon Linuxユーザーだけ？？

・それはそれとして、PREEMPT_NONEはサーバー用distroで長らく使われてきた決してマイナーではないオプション

・なんだけど、peterはRed Hatにいた時代から -rtチームにいて、PREEMPT_NONEには当たりがキツかった。

どの視点でも面白いディスカッションが出来そうだな、と思ったところで、興味MPが切れたので、ただの感想を投下して逃げる。

おやすみなさい

Linux 7.0でPostgreSQLの性能がほぼ半減。 AWSエンジニアがGraviton4上で実測し、カーネルのプリエンプション変更が原因と特定した。

開発者の回答は「PostgreSQL側で対応しろ」。 リバートの見込みは薄く、Ubuntu 26.04 LTSにはこのまま載る。

カーネルの「改善」がアプリを壊し、修正をアプリ側に求める。

Linux 7.0でPostgreSQL性能半減、修正困難か

@joho_no_todai

@kosaki55tea

(2026/04/05)

ハーネスエンジニアリングを極めたら、IssueからAIエージェントが動き、人間の役割は要件定義だけになった

• ハーネスエンジニアリングを極めたら、IssueからAIエージェントが動き、人間の役割は要件定義だけになった

(2026/04/04)

Claude Codeの「ソースコード流出」をどう見るのか

• Claude Codeの「ソースコード流出」をどう見るのか

(2026/04/04)

Claude Codeでドメインエキスパートを育てる ── 解体新書自動生成Pluginの設計と実践

• Claude Codeでドメインエキスパートを育てる ── 解体新書自動生成Pluginの設計と実践 - 株式会社ヘンリー エンジニアブログ

(2026/04/03)

料金を払えばAIが任意のGPLソフトを合法的に再実装するサービス「malus.sh」が登場：著作権法が...

• 料金を払えばAIが任意のGPLソフトを合法的に再実装するサービス「malus.sh」が登場：著作権法が想定しなかった抜け穴 | XenoSpectrum

MEMO:

• やべーなとは思うけど、再実装という行為そのものは自由だと思われるが
• AIで再実装したところで、その後も安定して機能追加されるとは思えないし早晩メンテされなくなりそう
• 更に言えば、GPLからプロプラに移行したOSSにバックドアが無いと信用する根拠がひとつもないので、そんなもん誰が使うんだという感覚がある
• 元のプロジェクトが粛々と開発していればいつの間にか消えるのではという感じある

(2026/04/02)

ログ設計：基礎から応用まで

• ログ設計：基礎から応用まで

(2026/04/01)

特別調査委員会による調査結果について

• 特別調査委員会による調査結果について[PDF]

(2026/03/31)

「売上99.7％が架空取引」　KDDI、ビッグローブら子会社2社の広告代理事業巡り調査委が公表

• 「売上99.7％が架空取引」　KDDI、ビッグローブら子会社2社の広告代理事業巡り調査委が公表 - ITmedia NEWS

(2026/03/31)

Reactのフラグ地獄を状態遷移テーブルで解消する — Discriminated Union×テーブル駆動設計の実践

• Reactのフラグ地獄を状態遷移テーブルで解消する — Discriminated Union×テーブル駆動設計の実践

(2026/03/31)

クラファン未払いという前代未聞の事態──イシイジロウ氏『シブヤスクランブルストーリーズ』緊急インタビュー

• クラファン未払いという前代未聞の事態──イシイジロウ氏『シブヤスクランブルストーリーズ』緊急インタビュー

MEMO:

• oh...

(2026/03/30)

ユーザーストーリーを書くのがかったるいので「背景・目的・対応内容」に落ち着いた話

• ユーザーストーリーを書くのがかったるいので「背景・目的・対応内容」に落ち着いた話

要約:

■ 1. 概要と経緯

• スクラム開発のPBIにユーザーストーリー形式を使う煩雑さを問題視しAIとの対話を通じて「背景・目的・対応内容」という3点セットに辿り着いた備忘録
• ユーザーストーリーはケント・ベックが1990年代のクライスラーC3プロジェクトで導入した概念
• ユーザーストーリーの本来の目的は完璧な書類の作成ではなく「チームの認識を揃えること（対話への招待状）」であり形式へのこだわりは本末転倒

■ 2. 各要素の役割と不足点

• 背景・目的・ストーリーの位置づけ:
  • 背景: なぜ今これが必要か（広域）
  • 目的: これによって何を実現したいか（中域）
  • ユーザーストーリー: 誰が何をすればその目的が叶うか（詳細）
• ストーリーだけでは不足する点:
  • ストーリーのWhyにはミクロな目的が入るがマクロな背景は抜け落ちやすい
  • 例: 「コストを削減したい」は書けるが「来月までに削減しないとプロジェクトが凍結される」という背景は伝わらない
  • この背景を知っているかどうかでチームの動き方が変わる
• 背景・目的だけでは不足する点:
  • 具体的な対応内容がないとチームが迷走し実装に入れない
• Howだけを書く場合に陥る3つの罠:
  • 対応内容の目的化: 「チケットにこう書いてあるから」と非効率なやり方に固執する
  • レビューの質低下: Whyがないとコードが動くかのスペルチェックしかできない
  • 属人化: 後から「なぜこうしたのか」が分からなくなり先祖返りが起きる

■ 3. 「背景・目的・対応内容」の構造

• 各項目の定義:
  • 背景（Context）: 現状の課題・制約条件（今何が起きているか）
  • 目的（Why + Goal）: 理由と目指す状態（どうなれば成功か）
  • 対応内容（How）: 作業手順・チェックリスト（具体的に何をするか）
• 目的の書き方:
  • WhyとGoalの両方を1文に含める
  • 「[痛み]を解決するために[目指す状態・数値]を実現する」の型を使用
  • Whyだけでは終了条件が不明 / Goalだけでは実施理由が伝わらない
• 日本語の「目的」には理由と目標の両方のニュアンスが含まれ英語のContext/Why/Howより直感的に書ける

■ 4. 階層ごとの使い分け

• エピック:
  • 背景: 厚めに記述
  • 目的: 最重要
  • 対応内容: 記載しない（方針のみ）/ 役割: 北極星
• PBI:
  • 背景: 補足程度
  • 目的: あり
  • 対応内容: あり / 役割: ロードマップ
• タスク:
  • 背景: 不要
  • 目的: 不要
  • 対応内容: 詳細に記述 / 役割: 足元の作業
• エピックに対応内容を書かない理由:
  • 最初にやり方を固定すると改善の余地が失われる
  • 背景と目的があればエンジニアが自律的に考えられる
  • 対応内容まで指示するとチームが作業者になる
• タスクに背景・目的を書かない理由:
  • 親PBIで合意が取れていればタスクは実行レベルで書く方が親切
  • 迷ったら親PBIに戻れれば十分

■ 5. テンプレート

• PBIテンプレート:
  • 背景（Context）: 現状の課題や依頼の経緯を1〜2行
  • 目的（Why + Goal）: 「[痛み]を解決するために[目指す状態・数値]を実現する」
  • 対応内容（How）: 具体的な実装・改修の方針 / 満たすべき受け入れ条件
• エピックテンプレート:
  • 背景（Context）: プロジェクト全体の背景や技術的負債の状況
  • 目的（Why + Goal）: 「[痛み]を解決するために[目指す状態・数値]を実現する」
  • 対応内容はPBIに委ねる
• タスクテンプレート:
  • 対応内容（How）のみ: 設定変更・動作確認・プルリク作成などを列挙
  • 対応内容が10行を超えた場合はPBIが大きすぎるサインであり背景と目的を共通にしたままPBIを分割する

■ 6. dbt-coreのPRテンプレートとの比較

• dbt-coreのPRテンプレートはProblem（何が起きているか）とSolution（どう解決するか）の2項目で構成
• ProblemはContextとWhyに相当 / SolutionはHowに相当
• チケットもPRも「何が問題でどう対処するか」を伝えるという点で構造は同じ
• OSSメンテナが大量のPRを捌くために削ぎ落とした結果の形であり説得力がある

■ 7. 壁打ちで得た気づきと導入のポイント

• ユーザーストーリーの「〈価値〉のためだ」は部分最適になりやすくマクロな背景は別途必要
• 目的はWhyとGoalを1文で書く（「〇〇のために〇〇を実現する」の型）
• エピックの対応内容を書かないことでチームの自律性を維持する
• タスクは対応内容だけで十分であり親PBIへのリンクさえ切れなければよい
• 導入時は引き算が有効:
  • 背景が自明なら1行でよい
  • 目的が前と同じなら「〇〇と同じ」でよい
  • 対応内容がその場で決まらないなら「調査する」から書き始める

(2026/03/30)

なぜステータスが混在するテーブル設計が生まれるのか

• なぜステータスが混在するテーブル設計が生まれるのか

要約:

■ 1. 概要

• 業務システムのDBに複数のステータスカラムが混在するテーブル設計が生まれる原因と防止策を解説する
• 問題の根本はイベントとリソースを区別しないまま設計を始めることにある

■ 2. ステータス混在テーブルが生まれる原因

• イベントとリソースを区別せずに設計している:
  • リソースとは現在の状態を表す「物」であり、イベントとは「何かが起きた」という事実の記録である
  • ステータスはイベントの移り変わりを現在の視点から表したものである
  • この認識がないとステータス変化をUPDATEで上書きする問題として捉え、管理したいカラムを一つのテーブルに追加し続ける結果になる
• カラム定義から設計を始めている:
  • 「何を保存したいか」から設計を始めると保存したいものをすべてカラムとして並べることになる
  • 本来の順番は逆であり「このシステムでどんなイベントが起きるか」を先に列挙してから「イベントの結果として何がリソースとして残るか」を決める
• 外部システムの仕様をそのままDBに持ち込んでいる:
  • 外部コードは数値の飛び番・機関ごとの差異・外部都合の値など自社の業務ステータスとは異質な特徴を持つ
  • 内部ステータスと同テーブルに混在させると自社業務ステータスと外部コードの関係が定義されず、外部仕様変更時の修正箇所の特定が困難になる
• 連携元システムの設計を無批判に踏襲している:
  • 外部システムのDBをクローンして区分値テーブルなしに数値カラムだけを持ち込むと値の意味が自社コードベースのどこにも存在しない状態になる
  • この状態でスキーマを継ぎ足すと同じパターンのカラムが作られ続ける

■ 3. 防止するための設計手順

• イベントを先に列挙する:
  • テーブルやカラムを考える前に「このシステムで何が起きるか」を書き出す
  • イベントを列挙することでテーブルの責務が明確になる
• リソースとイベント記録を分離する:
  • リソーステーブルは現在の状態を表しUPDATEが発生する
  • イベントテーブルは発生した事実を記録しINSERTのみを原則とする
  • 外部コードは外部イベントテーブルに生データとして保持し、自社ビジネス判断を表す内部ステータスは別カラムで管理する
• ステータス遷移を先に定義する:
  • リソーステーブルにステータスカラムを置く前に遷移図を作成する
  • 遷移図により「どの遷移で何のカラムを更新するか」「どの遷移は許可されないか」「どの遷移にイベント記録が必要か」が自然に決まる
• 外部コードと内部ステータスを分ける:
  • 外部コード（生データ）はイベントテーブルにVARCHARまたは元の型で保持し変換しない
  • 内部ステータスはリソーステーブルにTINYINT＋Enum定数で管理し受信時に変換する
  • この設計により外部仕様が変わってもマッピング処理だけを変えればよい状態になる
• 外部の区分値を持ち込む際は意味も一緒に持ち込む:
  • 区分値テーブルもクローンして自社アプリから参照できるようにする
  • またはクローン時点で自社の定数・Enumにマッピングして変換する
  • どちらも取らないまま数値だけを引き継ぐと値の意味が自社システム内のどこにも存在しなくなる

■ 4. まとめ

• ステータス混在テーブルの問題はコードを書き始めてから気づくことが多い
• 根本原因はほぼ常に設計の最初にイベントとリソースを区別できていなかったことにある

(2026/03/30)

40,000行のAPIテスト作成で学んだClaude Code Skillsの育て方

• 40,000行のAPIテスト作成で学んだClaude Code Skillsの育て方 - カミナシ エンジニアブログ

要約:

■ 1. 背景と目的

• APIの動作保証にシナリオテストツール「runn」を使用していたが、サービス成長に伴うAPI増加により運用が困難になった
• 1ファイルあたりのステップ数が膨張し、テストの追加・修正が心理的・技術的に高コストな作業となっていた
• テストを以下の2種類に整理し直し、Claude Code + Skillsで生成する方針を採用した:
  • API単位テスト: 1ファイル = 1API、正常系・異常系を網羅的にカバー
  • ユースケースシナリオ: 複数APIにまたがる業務フローのE2Eテスト

■ 2. テスト生成の仕組み

• API単位テストのフローは5ステップで構成:
  • Step 1 情報収集: API定義やバリデーションロジックなど関連コードを読み込む
  • Step 2 テストケース洗い出し: コードからエラーハンドリングを網羅的に抽出し正常系・バリデーション・権限・存在チェックなどのケース一覧にまとめる
  • Step 3 ユーザー承認: テストケース一覧をMarkdownで提示し過不足を確認する
  • Step 4 サブエージェントへの委譲: API単位で分割して渡し、ファイル生成・実行・エラー修正を自律的に繰り返させる
  • Step 5 セルフレビュー: チェックリスト（ファイル形式・テスト構造・命名規則）で品質を確認する
• サブエージェントへの委譲はAPI単位で分割するルールとし、一度に渡すとコンテキストが膨れてテスト品質が低下するため採用した

■ 3. スキルの段階的な改善

• Phase 1 基本構成の確立: 最初の数APIで基本構造と命名規則を決定し、生成フローの大枠のみを定義したシンプルなスキルを作成
• Phase 2 runnスキルの切り出し: Claudeが繰り返す同一のrunn記法ミスのパターンが可視化されたため、runn記法ナレッジを独立スキルとして切り出した
• Phase 3 サブエージェント導入と構造再設計: 1セッションで情報収集から実装・実行まで担う構成ではコンテキスト超過が頻発したため、スキル本体（情報収集・テストケース設計・ユーザー承認）とサブエージェント（ファイル生成・テスト実行・エラー修正）に役割を分離した
• スキルの見通し改善として、テンプレートやチェックリストを参照ファイルに外出しし、スキル本体（SKILL.md）はフローの記述に集中させた

■ 4. ぶつかった壁と解決策

• runnはYAMLベースの独特な記法を持ち、LLMにとって馴染みが薄く頻繁にミスが発生した
• 主な記法ミスのパターン:
  • bind と include の実行順序: 同ステップ内でbindとincludeを書くと、bindの変数がincludeに渡らない
  • testフィールドのアサーション記法: expr-langの関数を知らず存在しない関数（例: startsWith）を使用してしまう
• 最大の課題はrunnのエラー出力をClaudeが読めないことだった:
  • assertionの条件式が&&や||で組まれると、ツリー構造で深くネストされたエラーが出力される
  • 人間なら失敗箇所を容易に特定できるが、Claudeにはツリーの葉から「=> false」を探す困難な作業になる
  • 結果として、Claudeがツリーを読み解けず同じテストを何度も再実行する悪循環が発生した
• 解決策としてアサーションをステップに分離する設計を採用:
  • 1つのtest:に全条件を詰め込まず、フィールドごとに独立したステップに分離する
  • 効果1: エラー出力がシンプルになり1ステップ=1条件でツリーのネストが発生しない
  • 効果2: ステップ名で失敗箇所が一目瞭然になる
  • 効果3: Claudeが失敗したverifyステップ名から修正箇所を正確に特定し自律的に修正できる
• 人が手動でテストを書く場合は記述量を抑えるためアサーション分割を避けることが多いが、LLMにテストを書かせる場合は自律的な修正・デバッグの実現が大きな価値を持つ

■ 5. 振り返りと学び

• うまくいったこと:
  • 段階的改善: 最初から完璧を目指さず数サービス実装後にパターンを抽出するサイクルが効果的だった
  • 委譲単位の制御: API単位でサブエージェントに渡すことでコンテキスト超過を防ぎテスト品質を維持できた
  • 暗黙知の明文化: Claudeが間違えるたびにNGパターン/OKパターンとしてスキルに蓄積し、LLMが「暗黙知の検出器」として機能した結果、スキルがテスト設計のナレッジベースになった
• 次への学び:
  • 初期設計のコスト: 最初の数サービスは試行錯誤が多いが、実際にやってみないと見えないパターンも多い
  • サブエージェントのモデル選択: Sonnetを使用したがスキルの指示に従わないケースや同じミスを繰り返すケースがあり、チェックリスト強化やプロンプト調整で対処が必要だった

■ 6. まとめ

• 約2週間でYAMLベース40,000行超のAPIシナリオテストをClaude Code + Skillsで生成した（数十API対象・100ファイル以上）
• 取り組みから得た4つのポイント:
  • スキルは最初から完成形を目指さず実装しながら段階的に改善する
  • LLMが間違えるポイントをNGパターン/OKパターンとしてスキルに蓄積する
  • LLMにとって読みにくいエラー出力はテスト設計側の工夫で回避する
  • スキルの改善プロセスは暗黙知を形式知に変換するプロセスそのもの
• テストの量産だけでなくテスト設計のナレッジが明文化されたことがこの取り組みの最大の成果

(2026/03/29)

イベント駆動を軸とした外部システム連携

• イベント駆動を軸とした外部システム連携 | yamarkz.com

要約:

■ 1. 要件と開発方針

• 要件:
  • ニアリアルタイムでのトランザクションデータ処理が必要
  • トランザクション連携が事業の生命線であり可用性と回復性を高水準で実現することが求められる
  • 主体処理と付帯処理の整理および非同期処理のフル活用が前提
  • 複数の連携起点を1つの連携経路に集約し登録・更新・削除のデータライフサイクルを実現する
• 開発方針:
  • 要件漏れが許されないためウォーターフォール型で開発
  • 先行システムの仕様を可能な限り踏襲
  • 開発手法の柔軟性を一定確保した上で進行

■ 2. システム特性

• 獲得を目指す5つの特性:
  • 可用性
  • 回復性
  • 整合性
  • ニアリアルタイム性
  • 独立性
• これらは妥協なく獲得を目指しトレードオフが発生する場合は相談の上で調整する

■ 3. システムデザイン

• 初期構想から大きく外れることなく現在の構成に着地
• 外部結合テストやシナリオテストの段階で構成上の欠陥が顕在化し最適化を実施
  • トラフィック量を意図的に増やした動作検証によって欠陥を発見
  • 取引先との期待値調整と交渉を経て設計変更を実現

■ 4. 工夫

• PubSubのイベント発信基盤の活用:
  • コアシステムのイベント発火をトリガーとして連携フローを構成
  • サテライトシステム側がすべてのイベントを受信した上で連携対象を取捨選択
  • コアシステムは自システムの事実の送信に専念しサテライトが追従する主従原則を採用
  • PubSubによるシステム間の疎結合化により組織スケーラビリティも実現
• 経路選択と連携実行の分離:
  • サテライトシステム内部で経路選択と連携実行を分離して処理
  • ノイジーネイバー問題の解決とAPI連携実行側の責務分離を実現
  • 経路選択で有効イベントを選別しA/B/Cといった経路へのデータルーティングを担う
  • 連携実行側は事前条件チェックと連携処理および付帯処理の実行を担う
• Cloud Tasksのリトライとリクリエイト機構の活用:
  • サテライトシステム内の処理はCloud Tasksを用いて逐次処理する構成を採用
  • Cloud Tasksが呼び出すAPI処理は例外なく冪等性を担保する原則を設ける
  • 冪等性担保によりリトライ処理の恩恵を受け自然回復可能な状態を実現
  • 技術選択がシステム特性の獲得を容易にする代表例
• 冪等性担保と差分チェックによる最小限のリクエスト送信:
  • 外部システムへのリクエストは連携の必要性を都度チェックし必要な場合のみ送信
  • 前回リクエスト時のパラメータをログ保存し差分チェックを行う
  • 不必要なリクエストを排除することでスループット低下とリソース過剰消費を抑制
• サテライトシステムのPull型データ取得:
  • 連携に必要なデータはコアシステムへの参照APIで都度取得するPull型を採用
  • Cloud Tasksパラメータでは参照のキー情報のみを受け渡す
  • 常に最新データ状態で処理が実行される前提で処理を構成

■ 5. 発見

• システム特性はテクニックと戦略で決まる:
  • テクニック: リトライ機構の整備やUpsertによる冪等性担保など即効性のある実装レベルの知識
  • 戦略: システム構成やクラウドサービスの選択など実装以前の設計判断
  • 戦略によってシステム特性の獲得容易性が規定されるためシステムアーキテクトは戦略にこだわる必要がある
• 連携で価値を生む系SaaSはコア/サテライト構成が最適:
  • マルチテナントのコアシステムとシングルテナントのサテライトを分離する構成が有効
  • コアの純度を守りつつサテライトで顧客要望に対応することで事業競合優位性を確保
  • 非同期処理と結果整合性への習熟が技術の最適解選択の幅を広げた
• クラウドサービスをフル活用する時代:
  • 2026年時点でクラウドサービスをフルで活用できる技術と思考が整った
  • 非同期処理系を中心に従来より低コストかつ柔軟性と拡張性を持った開発が可能になった
• AIに代替されにくい領域:
  • プログラマーの職はAIに置き換えられる一方で開発の責任を人が取って推進する領域は残存する
  • 運用容易性や運用安全性の保証はAIには困難であり運用は点ではなく線で考える長い時間軸の世界
  • 少なくとも10年単位ではすべてがAIに置き換えられることはないと考える

(2026/03/28)

AnthropicがAI SREの限界を公式認定。「相関関係を因果関係と誤認し続ける」

• AnthropicがAI SREの限界を公式認定。「相関関係を因果関係と誤認し続ける」

要約:

■ 1. AnthropicによるClaudeのSRE活用実験と限界の報告

• 2026年3月19日のQCon Londonにて Anthropicが ClaudeをSRE（サイト信頼性エンジニア）として活用する試みの限界を公式に報告
• 「相関関係を因果関係と誤認し続ける」という根本的な問題が残存しており SREの完全代替には至らないと自社が認めた
• AnthropicはClaudeを使ってClaudeのインフラ障害を修復する「AIがAIを管理する」構成を試みていた
• ログやメトリクスを読ませ 警告アラートの原因を特定させ 修復アクションを実行させる流れで運用を試みた

■ 2. 判明した問題点

• 警告の表面パターンは認識できるが 障害の根本原因を特定できないことが明らかになった
• 相関関係の誤認例:
  • 「メモリ使用量が急増した後にレスポンスタイムが悪化した」という相関を見て「メモリが原因」と判断する
  • 実際の根本原因はメモリではなく 特定のクエリパターンによるロック競合だった
• 人間のSREは過去のインシデント経験・システム全体の挙動パターン・チームが暗黙的に共有している文脈知識を総動員して根本原因の仮説を立てる
• 現在のLLMにはこの文脈理解が欠けている

■ 3. 相関から因果への誤認が生じる理由

• LLMは本質的にパターンマッチングで動作する
• 学習データ内で「Aが起きた後にBが起きた」という事例が多ければ「A→B」という因果関係として認識する
• システム障害の原因特定では 観測できる相関関係の背後にある「なぜ」を追う必要がある
• これはLLMのアーキテクチャ上の根本的な弱点であり プロンプト改善やコンテキスト長の拡大で多少は改善できるが 現世代のモデルでは完全に解消されていない
• Anthropic自身がこれを認めたことは注目に値し 技術的誠実さとして発信している姿勢が見られる

■ 4. AIが向いている作業と向いていない作業

• AI活用の適性が高い作業:
  • ログのサマリー作成: パターン認識が得意
  • アラートの緊急度分類: 既知パターンの照合で十分
  • 過去インシデントの類似検索: テキスト検索に近い
  • エラーメッセージの意味解説: 定義の説明は得意
• AI活用の適性が低い作業:
  • 障害の根本原因の特定: 相関から因果への誤認が起きやすい
  • 「なぜ今このタイミングで」の特定: 文脈依存の推論が苦手
  • 修復手順の最終判断: 誤った原因に基づく対処になるリスクがある
• 「整理させる」用途はAIが得意で「判断させる」用途は人間のチェックが必要という整理が実態に近い

■ 5. AIによる誤認を確認するための方法

• 原因の絞り込み確認:
  • AIが「Aが原因」と言ったとき「もしAが原因でないとしたら次に考えられる原因は何か」と追加で質問する
  • AIが自信を持って別の候補も挙げてくるなら 最初の断言は過信だった可能性がある
• タイミングの確認:
  • 「このエラーは以前も起きていたか それとも今回初めてか」をAIに確認する前に 自分でログの期間を広げて確認する
  • AIは直近のログに引っ張られて「今回の変更が原因」と判断しやすい傾向がある
• 変更との対応確認:
  • デプロイ直後のエラーに対しAIは自然に「デプロイが原因」と見なしやすい
  • 実際はデプロイと無関係に 外部サービスのタイムアウトや依存ライブラリのバージョン競合が原因だったケースが多い
  • 「デプロイを除いた場合の原因候補」という形で質問するだけで回答の質が変わることがある
• 具体例:
  • Next.jsのビルドエラーをClaudeに貼り付けると 直前に編集したファイルや変更行数の多いファイルを原因として指摘しがち
  • 実際には無関係の依存ライブラリ間のバージョン競合だったりする

■ 6. 残る疑問と今後の展望

• 今回の報告はAnthropicの自社インフラに限った話である
• 異なる規模・構成のシステムや より詳細なシステム文書をコンテキストとして与えた場合に同じ問題が出るかどうかは不明
• 「限界を認めた」というより「現時点の限界を正直に共有した」ととらえる方が正確かもしれない
• 今後のモデル世代での改善状況を見ていく必要がある
• 2026年のSRE領域でのAI活用は「支援ツール止まり」が現実的な見通しとなっている

(2026/03/28)

「COBOL」技術者はもういない、レガシーコードの読み解き方をAnthropicが解説：AIにより数カ月単位での...

• 「COBOL」技術者はもういない、レガシーコードの読み解き方をAnthropicが解説：AIにより数カ月単位でのモダナイゼーションも - ＠IT

要約:

■ 1. 背景と課題

• AnthropicはCOBOLシステムのモダナイゼーションにAIを活用する手法を2026年2月23日に公開
• COBOLシステムは金融・航空・政府系基幹システムで現役稼働を継続
• 開発者の多くが引退し暗黙知はコード内にのみ残存
• COBOLを扱えるエンジニアは希少であり教育機関も極めて少数
• COBOLモダナイゼーションは単純なリファクタリングではなく数十年分の複雑な依存関係の解体が必要
• 従来手法では大量のコンサルタントによる数年単位の工期と高コストが発生し移行に取り組む組織が少ない状況

■ 2. AI支援による自動化（Claude Code）

• Claude Codeが最も工数のかかる探索・分析フェーズを自動化
• 自動化される主要機能:
  • 依存関係のマッピング: エントリーポイント・実行パス・モジュール間データフローを解析し数百〜数千ファイルの関係を可視化
  • ワークフローのドキュメント化: 入力から出力までの処理経路を追跡し処理手順を文章・図として生成
  • リスク特定: 結合度の高いモジュールや隠れた依存関係・重複ロジックを抽出し移行障害要因を事前把握
  • 意思決定支援: 分析結果を基に優先順位や移行戦略の検討材料を提示
• AIの活用により数年単位から数カ月単位へのモダナイゼーション期間短縮が可能

■ 3. 自動探索と依存関係の発見

• AIはコードベース全体を読み取り構造をマッピングしてから分析を開始
• 静的解析では検出不可能なファイル・データベース・グローバル状態を介した隠れた依存関係を自動発見
• 隠れた依存関係の存在がCOBOLモダナイゼーションを高リスク化する主因
• マッピング完了後に各コンポーネントの移行リスクを評価:
  • 結合度の高いモジュール: 高リスクと判定
  • 分離されたコンポーネント: 独立したモダナイゼーションの早期候補として抽出
  • 重複ロジック: リファクタリング機会として提示
  • 技術的負債: 移行前にドキュメント化

■ 4. 人間の判断との組み合わせ

• 規制要件・ビジネス優先事項・運用上の制約・リスク許容度はAIが把握できないため人間の判断が不可欠
• 計画フェーズにおける役割分担:
  • AIの役割: リスク・依存関係・複雑さに基づく優先順位付けの提案
  • チームの役割: ビジネス価値・技術的リスク・組織優先事項に基づく最終決定と目標アーキテクチャ・コード標準・統合要件の定義
• コードテストと検証はコード変更前に定義:
  • AIが予備的な機能テストを設計
  • チームがテストの十分性・手動検証が必要なシナリオ・パフォーマンスベンチマークを決定

■ 5. 段階的実装と継続的検証

• 実装はコンポーネント単位で実施し各ステップで検証
• AIの実装支援内容:
  • COBOLロジックのモダン言語への翻訳
  • レガシーコンポーネントへのAPIラッパー作成
  • 移行中の新旧コード並行稼働用足場の構築
• スコープを小さく保つことで失敗時の修正を早期に実施可能となり大規模なロールバックリスクを排除
• 推奨される開始方法: 明確な境界と中程度の複雑さを持つ単一コンポーネントまたはワークフローから着手
• 反復サイクル: AI分析・ドキュメント化 → 移行計画策定 → 段階的実装 → 各ステップでの検証

(2026/03/27)

ドメインとテーブルが同じなら、そのDDDは過剰かもしれない

• ドメインとテーブルが同じなら、そのDDDは過剰かもしれない

要約:

■ 1. 概要

• シンプルなランキング表示APIにDDDを適用した個人開発の事例を通じ「なぜ詰め替えが多いのか」という疑問から得た気づきを共有する記事

■ 2. 実装内容

• 要件:
  • 入力: ランキングの開始位置（start）
  • 出力: ユーザーID・ユーザー名・スコア・順位
• ロジック: Userテーブルからスコア降順で取得しstartをオフセットとして順位を付ける
• DDDのリッチドメインモデルスタイルを採用しRankingEntry・Ranking・EntryWithPositionのエンティティを定義した

■ 3. 詰め替えへの疑問

• データの流れに対して詰め替えが多すぎると感じた
  • DBモデル → RankingEntry → Ranking → EntryWithPosition → レスポンスDTO
• DDDでは外部から取得した値をprivateにしてゲッターで公開し不正な値がユースケースに流れ込まないようにするという考え方がある
• RankingEntryのフィールドがUserテーブルのカラムとほぼ一致しておりドメインがDBスキーマに依存しているように見えた

■ 4. 結論

• ドメインはDBスキーマを知らないのではなく扱っていたドメインが非常にシンプルだったことが混乱の原因だった
• DDDが活きる条件:
  • 複数のリポジトリから異質なデータを集約し複雑なビジネスロジックで価値を生むケース（例: 決済システムの詐欺判定ドメイン）
• 今回のケースの特徴:
  • 単一テーブルからのデータ取得でロジックはforループによる順位付けのみ
  • ドメインが複数の関心事を統合して価値を生む複雑さを持っていなかった
• アネミックモデルにした場合フィールドがpublicなためコンストラクタを経由せずに不正な値を入れられる問題があり守るべき不変条件がないなら実質的にただの構造体と変わらない
• 複雑なドメインロジックがない場合はエンティティへの詰め替えよりシンプルな構造体（DTO）として扱う方が見通しが良い

■ 5. まとめ

• DDDが活きるケースと今回のケースの比較:
  • データソース: DDDは複数リポジトリの統合 / 今回は単一テーブル
  • ロジック: DDDは複雑なビジネスルール / 今回はforループによる順位付け
  • ドメインとテーブルの関係: DDDは異なる概念 / 今回はほぼ一致
  • 詰め替えのコスト: DDDは払う価値がある / 今回はコストが目的を超える
• パターンを適用する目的を忘れシンプルな問題を複雑にしてしまうことを避けるためには「なぜこれを適用するのか」を考え続けることが重要

(2026/03/26)

DDD×仕様駆動で回す高品質開発のプロセス設計

• DDD×仕様駆動で回す高品質開発のプロセス設計 - Speaker Deck

要約:

■ 1. 概要・ゴール

• 発表者: 松岡幸一郎（株式会社ログラス / AI基盤開発室）
• テーマ: DDD × 仕様駆動でAI駆動開発の品質を上げるプロセス設計
• 持ち帰り項目:
  • sudoモデリング（4つの図のフレームワーク）
  • draw.io × AI（図を使ったAIとの協働）
  • 仕様駆動との接続（AIに「何を作るか」を正確に伝えるプロセス）
  • その他の品質向上のためのプラクティス

■ 2. DDDとは・DDDのアプローチ

• DDDとは:
  • ドメイン駆動設計 = プロダクト開発で大きな価値を生むための手法（2003年〜）
  • 「ドメイン」= ソフトウェアで問題解決しようとする対象（業務領域）
  • 目的: 機能性（役に立つものを作る）× 保守性（長期間作り続けられる）
• DDDの2つのアプローチ（AI時代にも有効）:
  • 機能性向上: ドメインエキスパートと共に行うドメインモデリング → 作るものを検討しAIに渡すために活用
  • 保守性向上: 頻繁なモデルの更新に耐えられる実装パターン → 実装のガードレールとして活用
• モデルと実装の一致の重要性:
  • モデルと実装に乖離があると対応関係が見えにくくなる
  • モデルに変更があった時コードのどこに反映すべきかわからなくなる
  • コードは極力モデルと同じ形での表現を目指す（変更の反映先が一目でわかる）
• ドメイン知識の位置づけ:
  • ドメイン知識があれば役に立つものが作れるわけではない
  • ただしドメイン知識がなければ役に立つものは作れない（必要条件）

■ 3. 仕様駆動開発とは

• 定義: 仕様（完了条件・設計・テスト）を先に決め、AIに実装させる開発アプローチ
• 設計で押さえるべき3要素:
  • 完了条件（受入基準）
  • 技術的な設計
  • テスト
• 本質: 上流で品質を作り込み、手戻りを防ぐこと
• DDD × 仕様駆動の組み合わせ:
  • DDDのモデリングが最上流で「何を作るか」を明確にする
  • 仕様駆動が各フェーズで品質を作り込む
  • 作ったモデルが仕様駆動の各フェーズのインプットになる

■ 4. フェーズ①: モデリング

• モデリングの定義:
  • モデル = 問題解決のために作る抽象化物
  • モデリング = それを議論しながら作る活動
  • 成果物だけでなく、作るプロセスでの議論・認識合わせ・意思決定が重要
• モデリングが役立つ理由:
  • 複雑な構造を整理しやすい（図なら2次元で関係性を一目で把握できる）
  • 「ちょうどいい抽象度」で構造を整理できる（画面の詳細項目だと具体的すぎる）
  • これが仕様駆動の各フェーズの精度向上につながる
• モデリングのタイミング:
  • 新規機能開発・機能改修時: ドメイン理解を深め、わからないことを明確にして意思決定しやすくする
  • 後追いで実施する時: リバースエンジニアリング的に既存コードを理解し、現実と理想のギャップを明確にする
• sudoモデリング（4つの図）:
  • S（システム関連図）: システムに関わるアクターと外部システムを明示する
  • U（ユースケース図）: ユーザーがシステムでどのような操作を行うか明示する
  • D（ドメインモデル図）: 概念と概念の関係を抽象的に描く
  • O（オブジェクト図）: 具体的なデータ例で理解を深め、モデルを検証する
  • 補足として業務フロー図・状態遷移図・シーケンス図も併用可
• モデリング時のポイント:
  • 抽象と具体を行き来し、仮説を回し続ける
  • 具体例が出せない = ドメイン理解が足りていないサイン
  • 意思決定は常に仮説であると考える（モデル図はホワイトボードのように扱う）
• ドメインモデル図のコツ:
  • オブジェクト図（具体例）からドメインモデルに抽象化していく
  • ルール/制約（ドメイン知識）を吹き出しに書き出す
  • 検討メモも積極的に記述する（疑問点も発見を誘発し認識を残す）
  • 多重度を定義する（ルール/制約として重要な意思決定）
  • 集約の範囲（リポジトリの範囲を決める）と英語名（ユビキタス言語のマスタ）を決める
• AIとの協働（draw.io × AI）:
  • AIがdraw.ioファイルを直接操作できるSkillを作成（claude-drawio-skill）
  • draw.ioで描いたモデル図をAIに読み込ませて壁打ちしながらモデルを育てる
  • 「具体例を出して」と聞くだけでオブジェクト図（具体例）を生成できる
  • 「この図の懸念点は？」と聞くと1人では見落としがちな観点をAIが補完してくれる

■ 5. フェーズ②: 受入基準

• 完了条件が曖昧だと意図と違う実装が進む（AIコードドリフト）
  • AIは経験や暗黙知で補完できないため、曖昧な仕様は乖離した実装を生み続ける
• 完了条件を磨き込むことで手戻りを減らせる（AIが自己修正ループを回せ出力品質が上がる）
• モデルで整理した構造が受入基準を書くインプットになる
• 受入基準のアプローチ（4点）:
  • AIで磨き込む: 受入基準を決めたらAIによるレビュー（チェックポイント確認）・リファインメント（不明瞭な点を質問）を入れる
  • Question-First: 大量ドキュメントをレビューさせるより質問させることで論点を洗い出す（CLAUDE.mdに指示しておく）
  • Specification by Example（SBE）: 具体的な実例（Given/When/Then形式）で仕様を定義する
  • sudoモデリングのオブジェクト図がそのままこの「具体例」として活用できる
  • 具体例を書こうとすると自然にコーナーケースが洗い出される
  • AIにとっても具体例 = 入出力が明確 → 意図通りの実装になる
  • 図による可視化: draw.ioでSBEを可視化すると考慮漏れの状態遷移やロジックの分岐が一目で見つかる

■ 6. フェーズ③④⑤: 技術設計・テスト・実装

• 技術設計フェーズ:
  • 意思決定の前倒し: Question-Firstで設計段階でAIに質問させ実装前に意思決定を済ませる
  • 固定観点レビューSkill: プロジェクトで重視する設計観点を言語化してSkillにし、毎回確実に同じ観点でチェックされる状態を作る
• DDDの保守性アプローチ × AIガードレール:
  • ドメインモデルをコードで表現するルールをAIに守らせる
  • CLAUDE.md / .claude/rules/ にルールを定義（エンティティ・値オブジェクト・リポジトリ等のパターン、設計原則・アーキテクチャ制約・コーディング規約を事前定義）
  • AIはルールがあれば従ってくれるため「モデルを守ったコード」が自動的に生成される状態を作る
• ビジュアルで設計を確認:
  • 複雑な仕様はテキストだけだとレビューが辛い
  • draw.ioでクラス図やデータフローにすると一目で把握できる
• テスト分析設計フェーズ:
  • テストを明示的に検討させる: 実装計画と同じタイミングでテスト設計も依頼する（実装前にテストを考えることで仕様の抜け漏れ・矛盾に気づける）
  • テスト設計・レビューSkill: テスト観点をSkillとして言語化し毎回確実に同じ観点でレビューできる状態を作る（チームで育てることでQAの観点・過去の不具合パターンが蓄積される）
• 実装フェーズ:
  • AIが自律的に実装・検証を回せる環境を整える
  • 自動テスト × ブラウザ操作（playwright-mcp等）で画面確認まで任せられると手離れが良くなる
• コンテキストエンジニアリング（AIが必要な情報に確実に辿り着ける設計）:
  • FLOWとSTOCKに分ける: FLOW（開発中に書き留める一時的な情報）・STOCK（AIがまず参照する整理済みドキュメント）
  • 段階的開示: README.mdにインデックスへのパスを書いておきAIが段階的にたどれる構造を作る（大量のドキュメントを一度に読ませるのではなく必要な時に必要な情報だけ渡す）

■ 7. まとめ

• DDDのモデリングは「ちょうどいい抽象度」で複雑なドメインを整理できる
• その「ちょうどいい抽象度」が受入基準・技術設計・テストのインプットになる
• DDD × 仕様駆動は一本のプロセスとして繋がり、開発全体の品質が上がる

(2026/03/25)

Re: ドメインサービスでrepositoryの実行は必要か？

• Re: ドメインサービスでrepositoryの実行は必要か？ - pospomeのプログラミング日記

要約:

■ 1. 結論

• ドメインサービス内でのリポジトリ実行は避けるべきであるが実害の有無によって判断する
• 実害が無視できない場合は避け そうでない場合は許容する

■ 2. ドメインサービスでリポジトリを実行すべきでない理由

• アプリケーションレイヤとドメインサービスの責務が曖昧になるため
• アプリケーションレイヤの責務:
  • 処理の流れを実装する
• ドメインサービスの責務:
  • ビジネスルールを実装する
• リポジトリをドメインサービスで実行すると起こる問題:
  • 処理の流れとビジネスルールが混在する
  • ドメインサービスがファット化する
  • トランザクション境界が不明確になる
  • アプリケーションレイヤが不自然に薄くなる

■ 3. ドメインサービスの適切な使用条件

• 複数の集約にまたがる操作であること
• その操作にぴったりな名前が付けられること
• 上記条件を満たす実装は少ないためドメインサービスを使う機会は意外と少ない

■ 4. 実害の重要性

• ドメインサービスでリポジトリを実行した場合の実害の程度が判断基準となる
• 実害がなければそのまま維持し 困ったらリファクタリングする

■ 5. 回避策

• パターン1: 妥協してドメインサービスでリポジトリを実行する:
  • 実害がない場合に有効（回避策ではなく許容）
• パターン2: 1つの集約にまとめる:
  • 集約の境界を見直し 複数の集約を1つに統合する
  • 新たな集約の発見や入れ子構造の採用によって解決できる場合がある
  • 「xxxされたら」「xxxのあとで」という表現があるケースはドメインイベントの可能性が高くこのパターンに該当しない
• パターン3: ドメインイベントとして扱う:
  • 「Taskが作成されたらActivityReportが作成される」のようなケースに適用
  • ユースケース内でドメインイベントを発行しイベント受信側が処理を担当する
  • イベントソーシングの場合は集約自体がイベントを保持する形になる
  • アウトボックスパターン等の実装が必要になる場合があり実装コストが高い
• パターン4: アプリケーションレイヤでリポジトリを実行する:
  • ドメインサービスを使わずにアプリケーションレイヤで直接リポジトリを実行する
  • トランザクション制御との相性が良く自然に実装できる
  • ドメインサービスを乱用するよりこちらを選ぶ方が良い場合がある

(2026/03/24)

Claude Codeに長期記憶を持たせたら、壁打ちの質が変わった

• Claude Codeに長期記憶を持たせたら、壁打ちの質が変わった

(2026/03/24)

PO・PdMが感じるスクラムの限界

• PO・PdMが感じるスクラムの限界

(2026/03/23)

伊藤淳一が考える「コードレビューの観点とアプローチ」

• 伊藤淳一が考える「コードレビューの観点とアプローチ」 - レバテックLAB

要約:

■ 1. 対象読者と記事の目的

• 対象読者はコードレビューする側に回ったばかりの1〜2年目の新人エンジニア
• リードエンジニアがチーム内でレビュー手順や観点を議論する際の叩き台としても活用可能
• 記事の目的はコードレビューの観点を全網羅することではなく「先輩がレビュー時に何を見ているか」という気づきの提供
• 可読性・保守性・堅牢性・正しさ・セキュリティ・パフォーマンスの6テーマに分けて各3点ずつ観点を紹介

■ 2. 可読性の観点

• シンプルさ:
  • 標準ライブラリで代替できる自前実装は書き換えを検討する
  • 短縮しすぎて可読性を損なうのは不可
• 命名:
  • わかりにくい変数名やメソッド名はNG
  • ほどよく具体的でほどよく抽象的な名前を付ける
  • 動詞と名詞の組み合わせ方で意味が変わる点に注意（例: upload_files vs uploaded_files）
• 1行の長さ:
  • 人間がぱっと理解できない長さの1行記述はNG
  • 一度変数に代入してから使用する方が理解しやすい

■ 3. 保守性の観点

• 責務の分離:
  • ロジックをコントローラに書くとfatコントローラ問題が発生し再利用性が低下する
  • ビジネスロジックはモデルに委譲することでコントローラを薄く保てる
• カプセル化:
  • オブジェクト外部から内部状態を直接参照・変更するのはNG
  • 判断や操作はオブジェクト自身に任せることで再利用性と可読性が向上する
• DRY原則:
  • 同一ロジックの繰り返しを発見した場合はDRY化を検討する
  • 将来的に別々の変更が入る可能性がある場合はあえてDRYにしないケースもある

■ 4. 堅牢性の観点

• 配列とハッシュの使い分け:
  • 無関係なデータを配列に格納してインデックスで指定すると要素の増減時に不具合が起きる
  • ハッシュはキーで指定するため要素が増減しても既存コードの変更が不要
• ハッシュのキーtypo問題:
  • ハッシュはキーをtypoしてもnilが返るだけでエラーにならない
  • 一定の複雑さを超えたら専用クラスを定義しメソッドで参照することでtypoを検出可能
• 文字列結合によるフォーマット生成:
  • URL・HTML・XML・JSON・SQL・CSVなどを文字列結合で生成すると予想外の値でフォーマットが破綻する
  • 各フォーマットには専用のライブラリを使用する

■ 5. 正しさの観点

• ゼロ除算:
  • 除数を動的に変更する場合はゼロ除算でエラーが発生する恐れがあるため考慮が必要
• 丸め誤差:
  • 小数を含む計算ではFloat型特有の丸め誤差が発生する可能性がある
  • 金額計算では致命的な問題になるため RubyではBigDecimalを使用する
• 要件の充足:
  • 実装がPRのdescriptionに記載された要件を満たしているかを確認する
  • 正常系だけでなく異常系（例: 決済処理の途中キャンセル）も考慮できているか確認する

■ 6. セキュリティの観点

• 権限チェック:
  • フロントエンドでボタン表示を制御するだけでは不十分
  • Webアプリケーションではクライアントが自由にリクエストを送れるためバックエンドでも必ず権限チェックが必要
• XSS・SQLインジェクション対策:
  • フレームワークやライブラリを素直に使う限りほとんど発生しない
  • SQLを文字列結合で動的構築するなどイレギュラーな実装を行う際は十分な注意が必要
• クレデンシャル管理:
  • APIキーなどをコードに直書き（平文でgit管理）するのはNG
  • 環境変数やフレームワークが提供する仕組み（Railsの場合 config/credentials.yml.enc など）を使用する

■ 7. パフォーマンスの観点

• 本番データ量の想定:
  • ローカルで一瞬で動く処理も本番のデータ量では異常に時間がかかる場合がある
  • 単純なデータ更新はプログラミング言語側でループするよりDBのSQL一発で処理する方が高速
• 計算量の意識:
  • ループ内で毎回最大長などを求めると計算量がO(n^2)になり要素数増加時に無駄な処理が急増する
  • 最大長などはループの外で事前に求めておくことで計算量をO(n)に抑えられる
• DBアクセス回数:
  • DBへのアクセスは基本的に遅く N+1問題や同一データの繰り返し問い合わせは本番環境の負荷に耐えられなくなる恐れがある
  • シンプルなループ処理に見えてもその裏側でDBへの問い合わせが大量に発生している場合があるため注意が必要

■ 8. その他の観点

• 言語・フレームワークの考え方やベストプラクティスに沿った「○○らしいコード」を書いているか
• プロジェクト固有のお作法に従ったコードを書いているか（お作法は暗黙知にせず明文化することが望ましい）
• 成功・失敗を表すメソッドの戻り値を無視していないか
• 例外処理が適切か（エラーを握りつぶしていないか/不要な例外キャッチをしていないか/条件分岐で実装できるものを例外でスロー・キャッチしていないかなど）
• DBトランザクションを適切に利用しているか
• アプリ側の変更に対応したテストコードが追加されているか
• テスト設計手法（境界値分析など）を意識したテストコードになっているか
• 複雑な条件分岐を持つロジックに対するテストコードのカバレッジが十分か
• false negativeなテストコード（バグが発生していても検知できないテストコード）を書いていないか

■ 9. コラム：「5年後に自分がメンテできるか？」という視点

• 業務コードの寿命は非常に長くPR作成者が退職した後に自分がメンテすることも現実として起こりうる
• レビュー時の自問事項:
  • 5年後にこのコードを見てロジックをすぐに把握できるか
  • テストコードがない状態で既存機能を壊さずに自信を持って変更・追加できるか
  • 当時の仕様の背景を5年後にすぐ振り返られるか
• 答えがNOの場合は「わかりやすいメソッド名への変更」「テストコードの追加」「PRのdescriptionへの詳細記載」などのレビューコメントを入れる

(2026/03/22)

Goで値オブジェクトをどこまで作るべきか〜コスパの良いDDD戦術設計〜

• Goで値オブジェクトをどこまで作るべきか〜コスパの良いDDD戦術設計〜

(2026/03/21)

学ぶのをやめて、つくることにした

• 学ぶのをやめて、つくることにした | ドクセル

(2026/03/20)

Coding Agent時代のドキュメントについて考えていること

• Coding Agent時代のドキュメントについて考えていること - 逆瀬川ちゃんのブログ

要約:

■ 1. ドキュメントの基本的役割

• ソフトウェア開発においてドキュメントは関係者全員が同じ方向を向くためのSingle Source of Truthとして機能する
• 具体的な役割は関係者間のイメージ共有・実装との乖離検出の基準線・正しい挙動の拠り所の3点に集約される
• これらはある時点での正しさを自然言語で記述して共有することに帰結する

■ 2. ドキュメント腐敗の根本原因

• コードには型システムや依存関係グラフといった構造があり変更の影響範囲を機械的に特定できるが自然言語ドキュメントはそれが困難
• 自然言語ドキュメントには機械的なフィードバックループが存在しないことが根本的な問題
• Coding Agent時代では腐敗したドキュメントがAgentの行動を静かに悪化させる危険がある

■ 3. Agentが必要とするドキュメントの分類

• 導出可能なもの（コードやテストから再構成可能なAPI仕様・型定義一覧など）: 書かない
• 検証可能なもの（「レスポンス200ms以内」のように機械的にtrue/false判定可能なもの）: テスト・Linterに移す
• 不変の記録（ADR・ポストモーテムなどある時点の決定と理由）: Append-onlyで保持
• 還元不能な知識（外部制約・Why・組織判断などコードに落とせない知識）: 自然言語ドキュメントとして管理
• ETH ZurichとLogicStar.aiの研究ではディレクトリ構造の概要をCLAUDE.mdに書いてもAgentのファイル発見速度は向上しなかったという結果が出ている

■ 4. 二層構造による提供方式

• Layer 1（CLAUDE.md / AGENTS.md）:
  • セッション開始時に自動的にContextに注入される作業記憶として機能する
  • 禁止事項・ガードレール・アクティブなアーキテクチャ判断の要約・ビルド/テスト/Lintコマンドを置く
  • 約60行を上限としContext効率のためシンプルさを重視する
• Layer 2（docs / docs/adr/）:
  • ADRやドキュメント群はAgentが必要に応じて参照する長期記憶として機能する
  • Context効率の観点からすべてをCLAUDE.mdに詰め込む必要はない

■ 5. ドキュメント管理・運用の実装

• check-doc-freshness.shスクリプト:
  • CLAUDE.md/AGENTS.mdの行数制限（60行以上でエラー）を検査する
  • 壊れたパス参照の検出・last-validated日付チェック・古いADRへの参照確認を実施する
  • phase: currentのドキュメントは3日でWARNING・5日でERROR
  • phase: target（将来目標）は10日でWARNING・15日でERROR
• PreToolUse Hook統合:
  • Claude CodeのHook機能を利用しgit commit前にドキュメント検査を自動実行する
  • exit 2とstderrを使用してブロック時のフィードバックを実装する
• docs-auditorツール:
  • 各ドキュメントが読まれたタイミングを検出する
  • Agentの行動変化（beneficial/neutral/harmful/unnecessary）を分類する
  • ドキュメントごとのROI（impact_score / (content_tokens / 1000)）を計算する
  • 一度も参照されないドキュメントを検出する
• 二段構えの運用:
  • check-doc-freshness.sh（軽量・高頻度）: 毎コミット時の時間ベースチェック
  • docs-auditor（重量・低頻度）: 定期的な実行と実際の行動改善度評価

■ 6. 人間向けドキュメントの扱い

• 人間向けドキュメント（オンボーディング・運用手順・ユーザーマニュアル）はリポジトリの外に出す選択肢を検討する
• Agent向けドキュメントとの混在を回避し各最適化に専念可能にすることが目的
• コード変更に連動した自動更新の仕組みがないことが課題であり現状では試行錯誤中

■ 7. まとめ

• Coding Agent時代でも基本的なドキュメントの役割は変わらないがフィードバックループの構築が必須
• 検証可能性か不変性のいずれかを持つドキュメントを優先する
• 導出可能なものは書かず検証可能なものはテスト化する方針を採る
• 二層構造と二段構えの運用で腐敗対策を実装する
• コード規模やチーム規模によって正解は異なり試行錯誤の余地がある

(2026/03/19)

急成長でぶつかったMySQLの罠とその向き合い方

• 急成長でぶつかったMySQLの罠とその向き合い方 - Speaker Deck

要約:

■ 1. 概要

• 発表者はTimeeのプラットフォームエンジニアリングチームに所属する徳富博
• Aurora MySQLを使用するサービスの急成長で顕在化した7つの罠とその対処法を紹介する
• 急成長の文脈として以下の3点が挙げられる
  • アクセス数の急増によりボトルネックが顕在化
  • データ量の急増によりクエリ処理速度が低下しインデックス設計の重要性が増大
  • 開発者増加によりMigration頻度が増加しALTER TABLEのロック影響が無視できなくなった

■ 2. 罠①: DDL実行時の落とし穴

• メタデータロック（MDL）に関する誤解:
  • 「オンラインDDLならロックはゼロ」という誤解が存在する
  • アルゴリズムに関わらずMDLは必ず発生する
  • ALGORITHM=COPYは開始から完了まで排他MDLを継続保持しDMLが完全にブロックされる
  • ALGORITHM=INPLACEは初期化・実行・最終フェーズの3段階でMDLを取得する
  • ALGORITHM=INSTANTは最終フェーズ（commit table definition phase）でのみ排他MDLを取得する
• MDL待機の発生フロー:
  • DMLが共有MDLを取得した状態でALTER TABLEが排他MDLを要求し待機する
  • 後続のSELECT/UPDATEが共有MDLを取れずキューに詰まる
  • アクセス数が多いプロダクトではこれが大きな問題になる
• Aurora固有の挙動:
  • Vanilla MySQLではMDL待ちがレプリカ側に溜まり待機する
  • Aurora MySQLではDDL反映がクラスターボリューム共有によりほぼ即時反映される
  • Auroraリードレプリカでは実行中のクエリが強制終了（Lost connection）される
  • MDL待ちは溜まらないが単発エラーが発生する
• Aurora lost connectionへの対応:
  • Rails 7.1から導入された自動リトライ機能を活用する
  • lost connectionエラー発生時に一定回数クエリを自動リトライするよう設定する
  • ALTER完了後にリトライが成功しアプリ側にはリカバリされる
• 外部キー制約追加時の注意（COPYアルゴリズム強制）:
  • foreign_key_checks=1（デフォルト）のまま外部キーを追加するとCOPYアルゴリズムが強制される
  • COPYアルゴリズムではテーブル全コピーの間INSERT/UPDATE/DELETEが完全停止する
  • migration実行前にSET SESSION foreign_key_checks=0を実行することでINPLACEになりDMLを止めずにオンライン実行できる
  • ただしforeign_key_checks=0は整合性チェックをスキップするため実行前にデータ整合性を確認する
• 外部キー追加時の参照先テーブルへのSロック:
  • COPYアルゴリズムでは既存データを新テーブルへコピーする際に参照先テーブルの整合性チェックが走る
  • InnoDBはその間参照先テーブルにSロック（共有ロック）をかけ続ける
  • 親テーブルへのUPDATE/INSERT/DELETEはXロックが必要なためSロックと競合しタイムアウトが発生する
  • foreign_key_checks=0でINPLACEにすることで子テーブルのCOPYが走らず参照先テーブルへのSロックも発生しない

■ 3. 罠②: Drop Table中にMDLによるデッドロックが大量発生

• MySQLのレイヤー構造の理解:
  • MySQLサーバーレイヤー（SQL Layer）がメタデータロック（MDL）を管理する
  • InnoDBストレージレイヤーが行ロック・ギャップロック・ネクストキーロックを管理する
  • 一般的にイメージするデッドロックはストレージレイヤーのものだが今回のデッドロックはサーバーレイヤーのもの
• SHOW ENGINE INNODB STATUSに出ないデッドロック:
  • MDL（メタデータロック）はサーバーレイヤーで管理されInnoDBロックモニターの対象外
  • SHOW ENGINE INNODB STATUSやinnodb_print_all_deadlocksには出力されない
  • Datadog/CloudWatchにも何も出ない
  • Performance Schemaのmetadata_locksテーブルで確認可能
• MDLデッドロックの発生メカニズム（DROP TABLE + FK）:
  • セッション①がordersテーブルをSELECTし共有MDLを保持する
  • セッション②がFKを持つ子テーブルcustomers_ordersをDROP TABLEしようとする
  • DROP TABLEはcustomers_orders・customers・ordersの排他MDLを順次要求する
  • ordersの排他MDLはセッション①の共有MDLが邪魔し待機する
  • セッション①がcustomersをSELECTしようとするがセッション②がcustomersの排他MDLを保持中
  • セッション①はcustomers待ち・セッション②はorders待ちとなり相互待機（デッドロック）が発生する
• 再発防止策:
  • DROP TABLE前に外部キー制約を先に削除することで排他MDLの競合対象を最小化する
  • Migration前に本番環境で参照先テーブルへのDMLが走っていないことを確認してから実行する

■ 4. 罠③: Auroraの場合レプリカの重いクエリがWriterに影響する

• 問題の概要:
  • Redashによる数時間の集計クエリがReader上で実行されていた
  • AuroraはWriter/Reader間でクラスターボリューム（Undoログ）を共有する
  • Readerで長時間トランザクションが実行されるとUndoログがパージできなくなる
  • 古い行バージョンが蓄積しRollbackSegmentHistoryListLengthが増大する
  • 共有ボリュームを通じてWriter側のクエリ劣化が発生する
• 対策（トランザクション分離レベルの活用）:
  • 集計クエリには分離レベルをREAD COMMITTEDに設定することでUndoの肥大化を抑制できる
  • SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED を実行してから集計クエリを実行する
  • REPEATABLE READ（デフォルト）はNon-repeatable readとPhantom readを防ぐがUndoログ蓄積が多い
  • READ COMMITTEDはNon-repeatable readとPhantom readが起きうるがUndoログ蓄積が少ない
  • 集計系はリアルタイム整合性より安定稼働が重要でREAD COMMITTEDで十分なケースがほとんど

■ 5. 罠④: 同時リクエストによるデッドロック

• パターン①: ギャップロックデッドロック:
  • ギャップロック（Gap Lock）はインデックス上の「レコードとレコードの間の隙間」に対してかかるロック
  • SELECT FOR UPDATEでレコードが存在しない場合その検索範囲に他トランザクションがINSERTできないよう封鎖する
  • Gap Lock同士は競合しないため複数トランザクションが同じギャップにGap Lockを取れてしまう
  • INSERTはGap Lockと競合するためお互いのGap Lockに阻まれた状態で相互ブロックが生まれやすい
  • 発生シナリオ: TxAとTxBが同時に「email3を検索してなければINSERT」を実行する
  • 両者がGap Lockを取得後INSERTを試みると相手のGap Lockに阻まれ相互待機（デッドロック）が発生する
  • 対策①: INSERT IGNOREまたはINSERT ON DUPLICATE KEY UPDATEを使い1クエリで完結させGap Lockを取らないようにする
  • 対策②: FOR UPDATEをやめ存在確認のみなら共有ロックまたはロックなしにしXロックが本当に必要かを設計から見直す
• パターン②: S→X昇格デッドロック:
  • SロックはSELECT LOCK IN SHARE MODEで取得し他のSロックとは競合しない
  • XロックはSELECT FOR UPDATE/UPDATE/DELETEで取得し全てのロックと競合する
  • SロックをXロックに昇格しようとすると相手のSロックが邪魔になり相互ブロックが発生する
  • 発生シナリオ: TxAとTxBがFKを持つ子テーブルにINSERT後親テーブルをUPDATEする
  • FK INSERTでInnoDBが親テーブルの参照行にSロックを自動取得する（S同士は競合しないので両方成功）
  • その後UPDATEでXロックが必要となるが相手のSロックが邪魔で待機する
  • TxAはTxBのSロック待ち・TxBはTxAのSロック待ちとなりデッドロックが発生する
  • 対策①: UPDATEを先に実行することで先にXロックを取得し後続のFK INSERTのSロック取得を同一TX内のXで成功させる
  • 対策②: INSERT前にSELECT FOR UPDATEで先にXロックを取得し順番待ちにすることで相互ブロックを回避する

■ 6. 罠⑤: 意外に広いロック範囲

• パターン①: UPDATEでテーブル全体がロックされる:
  • インデックスなしのUPDATEではテーブル全体をスキャンし全行に排他ネクストキーロックがかかる
  • 本来1ユーザーだけ更新したいのにテーブル全体がロックされ他トランザクションのINSERT/UPDATE/DELETEがほぼ停止する
  • 対策: 適切なインデックスを追加することでロック範囲を劇的に狭める
• パターン②: 外部キー制約で親テーブルにSロックが伝播する:
  • group_usersにINSERT/DELETEするとInnoDBが参照整合性チェックのため参照先の親行にSロック（共有ロック）を自動取得する
  • バルク処理が大量のSロックを保持し続けると退会・更新系APIのXロック取得がブロックされる
  • 対策: バルク処理を小さいバッチ（例: 100件ごと）に分割して途中でCOMMITしSロックの保持時間を短縮する

■ 7. 罠⑥: 急成長でじわじわ悪化するスロークエリ

• 問題の構造:
  • リリース直後はデータ数が少なくフルスキャンでも数msで問題なし
  • 数ヶ月後にデータが数百万件に増加し同じクエリが数秒に悪化する
  • 急成長期にそのエンドポイントへのアクセスも急増し処理が詰まりはじめる
  • 最終的にタイムアウト多発・接続枯渇・DB負荷急上昇という障害に至る
  • データ量の増加×アクセス数の増加が「無害だったクエリ」を障害の引き金にする
• 気づきにくい理由:
  • リリース時のレビューでは少量データでテストしており問題が見えない
  • データ増加は緩やかなため劣化が少しずつ進み気づくのが遅れる
  • コード変更なしで突然遅くなるため原因特定に時間がかかる
  • AIコードレビューでもクエリの実行計画までチェックできない
• Datadog Database Monitoringによる改善体制:
  • 発見〜改善のフローは「トレースで検知 → 実行計画を確認 → AIが仮説を提示 → チームが修正」
  • スロークエリの検出: 実行時間・頻度でランキングし問題クエリを一目で特定できる
  • 実行計画の可視化: EXPLAINの結果をUIで視覚的に確認しFull Scan/非効率な結合を検知する
  • AIによる改善提案: 実行計画をもとに適切なインデックス構成をAIが自動提案する
  • チームの自律改善: SREを介さず各開発チームが自分たちのクエリを改善できる

■ 8. 罠⑦: データ増加でBuffer Poolが足りなくなる

• InnoDB Buffer Poolとは:
  • テーブルのデータページ・インデックスページをメモリにキャッシュする領域
  • クエリ実行時MySQLはまずBuffer Poolを確認しヒットすればメモリから返す
  • ミスすればストレージから読み込みBuffer Poolに保存する（Read I/O発生）
  • AuroraではBuffer Poolサイズ = DBInstanceClassMemory × 3/4で自動計算される
• 急成長期に起きること:
  • データ量の増加によりワーキングセットがBuffer Poolを超えはじめる
  • 一度読み込んだデータが追い出され次のクエリでまたストレージから読み直す
  • インデックスの増加によりBuffer Poolを消費しインデックス自体もページとしてキャッシュされるため無計画な追加は逆効果になりうる
  • 結果として毎クエリでストレージから読み直しが発生しRead I/Oが急増しクエリが急激に遅くなる
• 監視すべきメトリック:
  • Buffer Pool Hit Ratio: キャッシュヒット率でここが下がるとストレージ読み取りが急増する
  • Read IOPS/Read Latency: Buffer Poolミスが増えると連動して悪化する
  • Buffer Pool使用率: 100%張り付きはワーキングセットがBuffer Poolに収まりきれていないサイン
• チューニングのアプローチ:
  • インスタンスサイズアップ
  • パラメータチューニングでbuffer poolサイズを増やす
  • 不要なインデックスを削除する

■ 9. まとめ: どう向き合うか

• レイヤーを意識する:
  • サーバーレイヤー（MDL）なのかInnoDB（行ロック）なのかで観測方法・対策が全く異なる
  • 「どのレイヤーで起きているか」を最初に問う習慣を持つ
• 仕組みを理解してから運用する:
  • 「InnoDBバッファプール」「MVCC/Undoログ」「メタデータロック」の概念を知っているだけでトラブルシューティングの精度が格段に上がる
• 高トラフィックは「通常では起きない」競合を日常化する:
  • 理論上起きにくい競合もリクエスト数が増えれば確率論的に必ず発生する
  • 設計段階から競合を想定したロック設計・インデックス設計を行う
• 改善を積み重ねる:
  • 単発の対応で終わらせずポストモーテム→再現実験→予防策→モニタリング追加のサイクルを回す
  • Aurora運用知識そのものがプロダクトの継続性に直結する

(2026/03/18)