/note/tech

The Next DevOps Bottleneck: When AI Generates More Software Than Organizations Can Manage

• The Next DevOps Bottleneck: When AI Generates More Software Than Organizations Can Manage - DevOps.com

要約:

■ 1. AIコーディング支援による開発速度の向上

• GitHub Copilotなどの導入により、開発チームはSpring Bootサービスの生成、ユニットテストの作成、スプリント単位のタスク完了が大幅に高速化した
• 生産性向上の恩恵は現実であり、API、インフラテンプレート、SQLクエリ、テストケース、ドキュメントの生成速度が飛躍的に向上した
• 管理層はデリバリー指標の改善を即座に確認できた

■ 2. ボトルネックの移行: 開発以外の工程への負荷増大

• AI導入後に速度が上がったのは開発工程だけであり、それ以外の全工程の負荷も同時に増大した
• アーキテクチャレビューの所要時間が増加した
• セキュリティチームのプルリクエスト承認待ち件数が増加した
• プラットフォームエンジニアはKubernetesクラスタへのサービス追加対応に追われた
• 運用チームが管理するダッシュボード、アラート、本番依存関係が急増した
• 開発そのものがプロセスの最も容易な部分となり、課題は他の工程へ移行した

■ 3. ソフトウェアデリバリーの本質: コード記述以外の責任

• ソフトウェアデリバリーはコード記述だけで完結しない
• 新しいマイクロサービスが生成された後も、以下の責任は人間が負う:
  • 設計のレビュー
  • セキュリティ管理の検証
  • 組織標準への準拠確認
  • 本番障害発生時の担当者の決定
• AIはソフトウェア生成を加速するが、運用責任を排除しない

■ 4. セキュリティレビューへの影響

• AIはAPIを素早く生成できるが、以下の対応はできない:
  • そのAPIが顧客情報にアクセスする必要がある理由の説明
  • 監査対応
  • リスク評価への参加
  • コンプライアンスレビューにおけるアーキテクチャ上の意思決定の正当化
• セキュリティ組織はリソースの追加なしに、より多くの変更をレビューする状況に置かれた
• 課題は専門知識の欠如ではなく、単純なキャパシティ不足である
• パイプラインに流入するソフトウェアの量が、従来のレビュープロセスの処理能力を超えて増加している

■ 5. テストと品質保証の課題

• AIツールはテスト生成に優れており、カバレッジ数値は即座に改善される
• しかし、最も価値あるテストは自動生成では得られない場合がある:
  • 顧客の実際の使用方法を理解したエンジニアが作成したテスト
  • 過去の本番障害を記憶している担当者が作成したテスト
  • 意図的に異常なワークフローを試みたテスターが作成したテスト
• ソフトウェア品質はカバレッジの割合だけで測れない
• 障害が発生しやすい箇所の理解が本質であり、AIはエンジニアリングの直感を代替できない

■ 6. 理解とナレッジの欠如という隠れたリスク

• エンジニアが手動でシステムを構築する際、意思決定の理由やトレードオフへの理解が自然に形成される
• AI活用後、開発者は主要な作成者ではなくレビュアーやオーケストレーターとして機能するようになった
• チームが自ら設計していないソフトウェアを引き継ぐリスクが生じる
• 本番障害が発生した際、技術的には正しいが十分に理解されていないコードの調査に多大な時間を要する事例が増えている
• ソフトウェアが組織内の理解の発展速度を超えて生成されることが、AI時代の最重要課題のひとつとなり得る

■ 7. オブザーバビリティの戦略的重要性

• 現代のシステムはAPI、Kubernetesサービス、メッセージキュー、データベース、オブザーバビリティプラットフォーム、サードパーティ連携、クラウドインフラが複雑に絡み合っている
• ソフトウェアの追加は容易だが、そのエコシステムへの可視性の維持は困難である
• インシデント発生時には、以下の情報が必要となる:
  • 問題を引き起こしたデプロイの特定
  • アプリケーションコード、インフラ、設定、外部依存関係のいずれに起因するかの判断
• 可視性なき高速開発は、高速な混乱を招くだけである
• システムの内部で何が起きているかを理解する能力が、システムを素早く生成する能力よりも価値を持つ時代が来る

■ 8. 組織が取るべき対策とDevOpsの未来

• AI恩恵を最大化する組織は、最も多くのコードを生成する組織ではなく、ソフトウェアをスケールで管理できる仕組みを構築した組織である
• 具体的な対策:
  • セキュリティチェックの自動化
  • デプロイ前のアーキテクチャ標準の強制適用
  • オブザーバビリティを後付けではなく要件として扱う
  • 手動プロセスへの依存ではなく、プラットフォームにガバナンスを組み込む
• コードの生成は毎月容易になっているが、そのコードへの信頼の構築は容易にはならない
• DevOpsの重要性はAIにより低下するのではなく、むしろ高まる
• 次の10年、エンジニアリングリーダーが解くべき問題は、AIが可能にする大量のソフトウェアをいかに運用、ガバナンス、セキュア化、理解するかである

(2026/07/11)

「TypeScript 7.0」が正式リリース ～1年をかけたGo移植で8〜12倍もの高速を果たす

• 「TypeScript 7.0」が正式リリース ～1年をかけたGo移植で8〜12倍もの高速を果たす - 窓の杜

要約:

■ 1. TypeScript 7.0の正式リリース

• 米Microsoftは7月8日（現地時間）、「TypeScript 7.0」を正式リリースした
• 2025年5月のプレビュー公開から先月公開のリリース候補（RC）版を経て、安定版として利用可能になった
• 従来のコンパイラー・言語サービスはTypeScript自身で記述されていた（Strada）が、本バージョンは1年以上をかけてGo言語へ忠実に移植された

■ 2. 性能向上

• ビルド高速化:
  • ネイティブコードの速度、共有メモリによるマルチスレッド処理、新しい最適化により、フルビルドは「TypeScript 6.0」比でおおむね8～12倍高速化
  • 大規模オープンソースプロジェクトでの計測結果は次の通り
    • vscode: 125.7秒から10.6秒（11.9倍）
    • sentry: 139.8秒から15.7秒（8.9倍）
    • bluesky: 24.3秒から2.8秒（8.7倍）
    • playwright: 12.8秒から1.47秒（8.7倍）
    • tldraw: 11.2秒から1.46秒（7.7倍）
• メモリ使用量:
  • ビルド全体で必要となるメモリも6～26％少なく済む
• エディター体験:
  • 「Visual Studio Code」のコードベースでファイルを開いてから最初のエラーが表示されるまでの時間は、従来の約17.5秒から1.3秒未満へ削減
  • 13倍以上の高速化に相当する

■ 3. 品質・互換性の検証

• Microsoft社内に加え、Bloomberg、Canva、Figma、Google、Notion、Sentry、Slack、Vercelといった企業と協力し、実際の大規模コードベースを用いたテストを実施
• 新しい言語サーバーは「TypeScript 6.0」に比べ、コマンドの失敗が80％以上、サーバーのクラッシュが60％以上削減された
• Slackからのフィードバック:
  • マージキュー時間の40％を解消
  • CIでの型チェックが約7.5分から1.25分に短縮

■ 4. インストールと利用方法

• 「TypeScript 7.0」は従来どおり「npm」からインストール可能であり、「tsc」コマンドで利用できる
• ナイトリービルドは、これまでの「@typescript/native-preview」から通常の「typescript@next」へ順次戻される

■ 5. 互換性と移行時の注意点

• 型チェックのロジックと挙動は「TypeScript 6.0」と互換であり、「6.0」でクリーンにコンパイルできるコードはそのまま利用できる
• 一方で「6.0」で導入された新しい既定値をそのまま採用し、「6.0」で非推奨となっていたフラグや構文はハードエラーとなる
• そのため、まずは「TypeScript 6.0」へ移行して問題点を洗い出しておくことが推奨されている
• 主な既定値の変更:
  • 「strict」が既定で有効に
  • 「module」の既定が「esnext」に
  • 「target」は「esnext」の直前の安定版「ECMAScript」が既定に
  • 「noUncheckedSideEffectImports」が既定で有効に
  • 「libReplacement」が既定で無効に
  • 「stableTypeOrdering」が既定で有効に（無効化は不可）
  • 「rootDir」の既定が「./」に（srcなどの内部ソースディレクトリは明示的な指定が必要）
  • 「types」の既定が「[]」に（従来の挙動は「["*"]」を指定すれば復元できる）

■ 6. 新しい実験的フラグ

• パース・型チェック・出力の並列実行を調整できる実験的な「--checkers」「--builders」フラグが導入された
• 並列化を無効化する「--singleThreaded」フラグも導入された
• 型チェックワーカーの既定数は4だが、「--checkers 8」を指定すると「vscode」のビルドは16.7倍まで高速化された
• 「--watch」モードも、「Parcel」バンドラーのファイルウォッチャーをGoへ移植した新しい基盤で作り直されている

■ 7. エディター対応

• 「Visual Studio Code」で利用する場合は専用拡張機能を導入するだけでよく、数週間以内に本体へも同梱される予定
• 「Visual Studio」の場合、最新版であればワークスペースに応じて自動で有効化される
• 新しい言語サーバーはLSP（Language Server Protocol）ベースであり、そのほかのモダンなエディターでも動作する

■ 8. APIとフレームワーク対応の制約

• 「TypeScript 7.0」にはプログラムから利用できるAPIが同梱されておらず、新しいAPIは「TypeScript 7.1」で提供される見込み
• それまでの間、「typescript-eslint」のようにAPIへアクセスするツール向けに、「6.0」を併用できる互換パッケージ「@typescript/typescript6」（「tsc6」コマンド）が用意されている
• 「npm」エイリアスでの導入が推奨されている
• 「Vue」や「Astro」、「Svelte」を使ったワークフロー、「Angular」テンプレート内の型チェックは当面「TypeScript 7」を利用できず、「6.0」の継続利用が必要となる

■ 9. 今後の方針

• 同チームは今後、新機能の開発に復帰し、これまでどおり3～4カ月ごとのリリースを予定している

MEMO:

• 世界がまたひとつ良くなった

(2026/07/10)

誤解だらけの開発生産性 ストーリーでわかる重圧とペインの乗り越え方

• 誤解だらけの開発生産性 ストーリーでわかる重圧とペインの乗り越え方【PDF版】 ｜ SEshop｜ 翔泳社の本・電子書籍通販サイト

【本書の概要】

本書は「開発生産性」にまつわる様々なペインや誤解を解消する手法について解説した書籍です。具体的には、ストーリー形式でエンジニア、上司、デザイナー、開発マネージャー、PM、QA、サポートなどがかかえる「開発生産性」に紐づくペインや誤解とその解消方法を紹介しています。それぞれの立場によって異なる「開発生産性」という言葉の持つ意味を紹介し、それを解決する方法がわかります。「開発生産性」という言葉は言う側にとっても、言われる側にとってもネガティブなものになりつつありますが、本書を読めば開発生産性のあり方を見直すきっかけになるはずです。

(2026/07/10)

「点群PNG」で、社会インフラに劇的な変革を

• 「点群PNG」で、社会インフラに劇的な変革を

要約:

■ 1. 点群データとその特性

• 点群データの概要:
  • ドローンやレーザースキャナーの普及により点群データという言葉の使用機会が増加
  • 地形や森林、建物などの構造物を3次元の点の集合で記録したデータ
  • 国土地理院は航空レーザー測量による計測点のデータを点群データとして公開
  • 各計測点は緯度・経度・高さに加え、色情報、レーザー反射強度、地表・水部などの分類情報を保持
  • 3次元空間に対応した多くの情報を持つため精緻な分析や解析が可能
• 活用分野:
  • インフラ、建設、防災、都市計画で活用
  • デジタルツイン、自動運転、XRなど先端ICT分野でも現実空間をデジタル空間に写し取る基盤データとして存在感を増している
  • 国や自治体も3D都市モデルや地形の点群データをオープンデータとして公開・整備を推進

■ 2. データサイズに起因する課題

• 産総研地質情報研究部門の西岡芳晴の指摘:
  • 森林整備や建設分野で国や県が点群データをオープンデータとして提供し活用が期待される一方、データサイズが大きく使い勝手が悪いという側面がある
• ファイル形式とデータ量:
  • 点群データの業界標準ファイル形式はLAS
  • バイナリ形式で保存し、数百万点規模で数百MB、都市規模では数十GBから数百GBに達することもある
• 具体例:
  • 富士山山頂の火口付近1200×900mのデータの場合、地表面標高を数値データで表現するDEM（数値標高モデル）は約6MB
  • 同範囲を3Dの点群データにすると3GBに達する
  • 公開データをダウンロードする際、3GBのデータは時間がかかり処理も容易ではない

■ 3. 新フォーマット「点群PNG」の開発

• 開発の狙い:
  • 西岡がこの課題への対応として新しいファイルフォーマット「点群PNG」を開発
  • 富士山山頂の3GBのLASファイルは点群PNGで600MB弱に圧縮可能
  • データ欠損のない可逆圧縮であり、約6分の1のデータ量とすることでダウンロード時間短縮などの使い勝手向上を目指す
  • 画像ファイルで用いられるPNG形式であるため、ウェブブラウザーで扱いやすく、ウェブ上での3D表示にもつなげやすい
• 産総研の公開状況:
  • 産総研は2025年10月1日に点群PNG ver.1.0を正式公開
  • LASファイルより軽量で取り扱いが容易な形式として3Dデータ活用に向けた広範な利用を想定

■ 4. 開発の発端となった業務背景

• 西岡の本業:
  • 地質調査総合センター地質情報研究部門に所属し、岩石学の観点から地質調査を行い地質図を作成する業務が本業
  • シームレス地質情報研究グループで地質情報を一般公開する業務も担当
  • 例としてつくばセンター近くの筑波山は上部が斑れい岩、下部が花こう岩で構成
  • 情報地質学会の視点から地質情報と地形情報をウェブで発信する技術開発に取り組んできた
• 開発の経緯:
  • データ量の多い点群データを活用しやすくするフォーマットについて相談があり、点群PNGを開発するに至った

■ 5. データPNGという発想と点群PNGへの適用

• データPNGの概念:
  • PNGはPortable Network Graphicsの略で、ウェブで広く使われる可逆圧縮形式の画像ファイルフォーマット
  • 西岡は数値を色に変換して画像として保存するというアイデアを持っていた
  • 色はR（赤）G（緑）B（青）の値でそれぞれの色を表現し、各色256段階のフルカラーで1677万色を特定可能
  • あるデータの数値をRGBで表現した色に置き換え、画像フォーマットを「数値の入れ物」として使う発想
  • このアイデアを「データPNG」という概念として提唱し、1つの色で1つのデータの数値を表現
• 点群データへの適用例:
  • 富士山山頂の標高3776.12mを「R＝5、G＝195、B＝12」の黄緑に近い明るい緑色で示す方法がある
  • 2次元の地図にデータPNGの考え方で標高に対応する色を指定すれば、cm単位まで標高を表現できるデータPNGファイルができる
  • PNGファイルは可逆の画像圧縮が可能であり、ファイルフォーマットにデータ圧縮機能を付加せずにデータ量削減が可能
  • この考え方を3次元の点群データに適用したものが正式公開した点群PNG

■ 6. 点群PNGの構造と圧縮の仕組み

• データ格納方法:
  • 点のX・Y・Z座標や色、分類情報などを数値として保持し、それらを色に変換してPNGファイルに格納
  • 2次元の画像として構成する際、X座標は最上部、Y座標はその下、Z座標は中央、色情報はさらに下部、分類情報は最下部というように同種のデータを近くに配置
  • 同種のデータは近い数値を取るため似たような色が近傍に出現し、2次元の画像圧縮で高い圧縮効果が得られる
• 利用面のメリット:
  • PNGの圧縮・展開機能はウェブブラウザーに標準実装されており利用可能
  • ウェブブラウザーは画像表示の高速化に注力しているため、表示側ソフトウエアを開発せずに高速表示が可能

■ 7. 圧縮・高速化の実測結果

• 富士山山頂データでの比較:
  • LASファイルで1,529MBだった点群データを点群PNG化することで7分の1以下の214MBに圧縮
  • ロードに必要な時間は71秒から12.3秒へと約6分の1に短縮
• 効果の背景:
  • データ量が小さくなることでサーバーから高速に転送できる
  • 点群PNGの仕様は無料公開しており、サーバー側は画像ファイルを置くだけで特別な機能が不要なためコストがかからない
  • 画像ファイルであるためGPUがあれば高速処理が可能
  • 西岡はこれらの特性を「走・攻・守」の三拍子がそろったフォーマットと表現
• 用途変化への期待:
  • 1分以上かかっていたダウンロードが12秒程度に短縮されることで点群データの使い方が変わる
  • データをいったんダウンロードしてから使う用途から、ウェブブラウザーやウェブアプリでダウンロードしながら使う用途への変化
  • アプリケーションの作り方や発想そのものが変わると西岡は見ている

■ 8. 普及促進のためのツール提供

• 普及の阻害要因:
  • 標準規格ではないこと、知名度がないこと、扱えるツールが少ないことが現状の阻害要因
• 提供ツール（2026年1月時点で4種類、試験公開）:
  • 点群PNGヘルパー:
    • LASファイルなど業界標準の入力を点群PNGに変換し、点群PNGファイルの作成を支援する
  • 点群タイルメーカー:
    • 大量の地図データを点群PNGファイルにする際、正方形に分割した点群PNGタイルセットとして出力する
  • 点群タイルビューアー:
    • 点群PNGタイルセットをウェブアプリとして表示する
  • 点群ダウンローダー:
    • 点群PNGで圧縮したファイルをLASなど他の標準的なフォーマットに展開して利用するためのツール
• 今後の方針:
  • 点群PNGの正式公開を終え、今後はツールの改良と、ツール作成のために作成したプログラム類のオープンソース公開に注力
  • 現時点では無料公開とし点群PNGの普及促進につなげる方針
  • フォーマット自体はver.1.0で完成し、ツール提供と普及促進に力を入れる段階に移行

■ 9. 今後の展望と国際規格化への期待

• 用途の広がりへの期待:
  • 大規模地震発生時、点群データを使った斜面災害の予測や分析において、現状の重いLASファイルでは迅速な利用が困難
  • ウェブブラウザーやウェブアプリで使え、データ量の少ない点群PNGであれば短時間で分析が可能になる
  • 適切な用途とのマッチングにより点群PNGを普及させられると西岡は考えている
• 広報活動と標準化への課題:
  • 国際規格ではないことが普及の足かせになっていると西岡は感じている
  • 現在は各県の森林担当者への案内や、地質・地球物理学・気象などの研究者への紹介を通じて利用を促進
  • 日本でデファクトスタンダードになれば国際規格化の望みが出てくる
  • 先端技術の社会実装を目指す産総研のポジションは点群PNGの国際規格化に有効と西岡は感じている
  • 産総研内の他分野の研究者でも点群PNGの試験的な利用が始まっている
• 応用分野の広がり:
  • 地質や測量の世界だけでなく、地理空間を扱う自動運転など多分野での応用可能性が高い
  • 都道府県レベルでは森林分野に限らず、都市部の防災、減災、都市計画などにも利用可能
  • スケールを調整すれば歯型など3Dデータの記録にも応用できる
  • 点群を専門家の道具から社会の素材へと変化させる力を点群PNGは持つ

MEMO:

• 面白そうな取り組みだ

(2026/07/10)

I Think I Have LLM Burnout

• I Think I Have LLM Burnout

要約:

■ 1. LLM利用の現状

• 開発者の中では平均的な頻度でLLMを利用している
• 手法自体は原始的で一つのタスクを一つずつ処理している
• 職場ではClaude Code、自宅ではCodexを使用している
• LLMにコードを書かせる場合もあるが出力は必ず読み込み理解した上で修正している
• 自律型エージェントやエージェントオーケストレーションの領域には深く踏み込んでいない
• 仕事と自宅を合わせ毎日数時間LLMと対話している
• AI生成テキストを読まない日はほぼない

■ 2. 仕事内容の変化

• 業務はコードの設計と記述から、LLMへの設計説明、LLM生成コードのレビューを経て最終的なコード記述へと変化した
• LLMとのやり取りにより自分では考えつかなかったアプローチに触れる機会が増えた
• 深い知識を持たない領域についても取り組みやすくなった

■ 3. 現在取り組んでいるプロジェクト

• 主なプロジェクトはコードベースにおける大規模かつ無人でのコード生成フレームワーク構築である
• Claudeとツール開発を行っていない時間は無人エージェント（Qwen）の出力を確認している
• いずれの作業でもLLM生成コンテンツを読むことが中心となっている

■ 4. 情報収集におけるLLMの活用

• 何かを調べる際は確認したいサイトが決まっていない限りまずChatGPTに尋ねるかGeminiの概要を確認する
• LLMの回答が誤っている場合は従来のブラウジングに戻る必要がある
• 検索結果がAI生成の低品質な記事で埋まっている状況もありLLMの回答で十分と感じる場面が多い

■ 5. LLM利用に対する評価

• この利用スタイルは約1年間続いており今後もやめるつもりはない
• LLMの利用により生産性が向上したと感じている
• LLMを効果的に使う方法を学び続けることには価値がある
• 一方でここ数か月で心境に変化が生じている

■ 6. LLM出力に対する嫌悪感の高まり

• LLMの出力を読むことに一部で気が重くなり始めている
• 事前に予想できる特徴として次を挙げている:
  • 誤った前提や幻覚（ハルシネーション）
  • 感情的で断片的な文体
  • 過剰な絵文字の使用
• これらは個人の感覚ではなく実際に広く見られるパターンである
• 個々の要素は単体では気にならないが複合的に重なることでLLMの文章への嫌気が急速に強まった

■ 7. 問題の本質に関する考察

• LLMを一方的に非難する意図はない
• 人間も同様に不確実であったり煩わしい存在になり得る
• 本質的な問題は繰り返しにある
• LLMは同じ文体で書き同じ種類の誤りを繰り返す傾向がある
• 同じ事象への対処を繰り返すこと自体に疲弊している
• インターフェースのパーソナライズ機能は利用できるが一部の癖は残る
• 他人が生成させたコンテンツの文体は自らコントロールできない

■ 8. 現在の心境

• この感覚への対処法はまだわかっていない
• これほど気になるとは予想していなかった
• 不安定なツールへの苛立ちは理解できるが文体のパターンにも神経を逆撫でされている
• 当面は歯を食いしばりつつ耐えていく

(2026/07/10)

ケント・ベックがソフトウェア工学業界をどう形作るか

• ケント・ベックがソフトウェア工学業界をどう形作るか｜The Pragmatic Engineer — BigGo ファイナンス

要約:

■ 1. ソフトウェアエンジニアリングの核心は人間的側面にある

• 業界創世記の約束「コンピューターを完全に理解すればすべてうまくいく」は誤りだったというのがベックの中心的主張
• 実際のボトルネックは人間同士の相互作用（共感、コミュニケーション、説得、信頼構築）にある
• ベックは自身を「自閉スペクトラム的」であるとし、これらのスキルを10年遅れの立場から学んだと語る
• ダリオ・アモデイの「コーディングはソフトウェアエンジニアリングの他の何よりも先に消え去る」という発言に対し、ソフトウェアエンジニアリングを理解していない発言だと反応
  • コーディングは活動全体の一部に過ぎず、残りは自信、つながり、理解の構築である
• 「コードよりも信頼を蓄積するペースが遅い」状態にあると指摘
• ドメイン概念の理解、コードでの表現、理解を証明するテストの作成、他者との共同作業が信頼構築の要素であり、完成したコードのみを返す仕組みではこれらを自動化できない

■ 2. Smalltalkのるつぼ: パターン、ツール、プログラミング哲学

• ベックの形成期は1980年代のテクトロニクス、ウォード・カニンガムとのSmalltalkでの活動
• Smalltalkは3つのプリミティブ（メッセージ送信、変数代入、値の返却）のみで構築され、組み込みの制御構造を持たない
  • 条件分岐もBooleanオブジェクトのライブラリメソッドとして実装
  • 主流言語（C++、Javaなど）は多数のプリミティブ、言語キーワードによる制御構造、コンパイル＋リンク工程を持つ
  • Smalltalkは編集後即時実行が可能でコンパイル工程がない
  • Smalltalkではユーザーがセッション中にデバッガを変更できるのに対し、主流言語ではツールが分離され変更が困難
  • Smalltalkの主な対象者はパーソナルコンピューティングと創造的精神、主流言語はエンタープライズとチーム規模の開発
• このミニマリズムがプログラマーに自らすべてを構築させ、深い理解とツール構築の文化を生んだ
• ベックとカニンガムは10Hzで矩形を動かせるグラフィカルエディタ「Hot Draw」を開発
  • 物理的なシソーラスを用いて「Figure」「Handle」などの概念を命名し、命名をプログラミングの中核スキルと位置づけた
• このコラボレーションから一連の技術レポートと、クリストファー・アレグザンダーの建築理論に触発されたデザインパターンの基礎が生まれた
• パターンは制約であり、既に下した決定から生じる制約に基づいて特定のタイミングで特定の決定を下すものであるとベックは述べている

■ 3. TDD: 馬鹿げたアイデアから業界標準、そして議論の的へ

• ベックは二つの流れを組み合わせてテスト駆動開発を考案した
  • 子供時代に読んだ「プログラムを書く前に期待される出力を手動でタイプせよ」という教え
  • 最初のユニットテストフレームワークSUnit（3クラス12メソッド）の開発経験
• 最初のTDDコード（スタックの実装）を書いた際、アイデアが馬鹿げているように思え声を出して笑ったが、その後不安を感じずにスタックを完成させた
• フレームワークはSmalltalkを通じて広まり、その後ベックとエーリッヒ・ガンマがウィーンからワシントン・ダレスへのフライト中にJUnitを執筆
  • バッテリー2時間半、インターネットなし、3.5インチフロッピーディスクという環境で作成
  • 翌日のOOPSLAでマーティン・ファウラーがフロッピーを配布し、需要が生まれた
• TDD衰退の要因は二つ
  • ベック自身が他のトピックに移ったこと
  • 他者がTDDを「道徳的な棍棒」（TDDを使わなければプロフェッショナルではないという主張）として用いたこと
• ベックはこのフレーミングを拒否し、TDDの採否は道徳的決定ではなく実践的決定であるとする
• TDDの最適領域は、実行と学習を急速に交互に行う場合（最初の一歩は分かるが正確な道筋が不明な時）
  • まっすぐに実装できる場合や、構築せずに学びたいだけの場合はTDDが役立たないとする

■ 4. エクストリーム・プログラミング: 命名、タイミング、そしてパンク精神

• XPは1996年のクライスラーC3プロジェクト（Y2K対応給与システム）から生まれた
• ベックはパフォーマンスコンサルタントとして招かれ、プロジェクトが正しい答えを計算できていないことを発見
  • 全員を2週間帰宅させ、既存のコードをすべて破棄
  • 給与専門家がテストケースを指定する3週間サイクルで再スタート
  • ペアプログラミング、継続的インテグレーション、リファクタリング、同一言語でのテストを統合
• 「エクストリーム・プログラミング」という名称は、誰にも盗まれないよう意図的に魅力的でなく選ばれた
  • グラディ・ブーチが同じことをしていると主張できないようにするための命名
• ベックはエクストリームスポーツとのアナロジーを用い、初心者が雪崩の頂上でスノーボードに飛び乗ることはなく最高の準備とスキルが必要であるとした
• XPのタイミングはドットコムバブル最盛期と重なり、企業がウォーターフォールとカウボーイコーディングの双方に代わる規律ある選択肢を必要としていた時期と合致
• 書籍は2000年に出版

■ 5. アジャイルマニフェスト: 創造、「アジャイル」という誤り、そして似非科学産業

• 2001年のスノーバード会議には様々な軽量方法論（XP、スクラム、FDDなど）を代表する17人が集まった
• ベックは重度の副鼻腔炎の薬を服用しており会議の内容をほとんど覚えていない
• マーティン・ファウラーとジム・ハイスミスが休憩中に残り、4つの価値の構造を起草
• ベックが原則に唯一貢献したのは「ユーザーとの日々の交流」というフレーズ中の「日々の」という言葉
• 署名順はアルファベット順であり、ベックが最初なのは姓がBで始まるため
• ベックは当時「アジャイル」という言葉に反対しており、現在も好んでいない
  • 誰も「硬直した開発を好む」とは言わないため、実際の実践に関わらず誰もが自分はアジャイルだと主張できてしまう点を問題視
  • 「エクストリーム」という語にはこの問題がなく、基礎スキルへの投資なしにそれを主張することはできなかったとする
• アジャイルを巡り成長した似非科学産業（技術的基盤なしに「半分の時間で2倍の仕事」を約束し、何百万ドルで販売されるスケールドフレームワーク）はベックが恐れていた事態そのものであった
• ベックは、信頼性の高いソフトウェアを少しずつ書くこと、漸進的に設計すること、独自のツールを構築することといった技術的スキルが前提条件であると主張
  • それがない状態でのアジャイル導入は、初心者を雪崩の頂上でスノーボードに乗せる行為と同様であるとする

■ 6. Facebook時代: TDDなしでスケールする方法を学ぶ

• ベックは2011年、50歳で最初のリモートエンジニアの一人としてFacebookに入社
  • 当時のFacebookは700人のエンジニア、総従業員2,000人の規模
  • 5人の子供の大学学費のための安定収入と、深い好奇心が入社動機
• Facebookはスケール、成長、イノベーションを同時に達成しており、これは自身の理論では不可能とされていた事態であった
• 最初の貢献の試みはハッカソンでのTDDクラスであったが、参加者はゼロ
  • 前後のクラス（アルゼンチンタンゴ、上級Excel）は満員であった
• ベックは自身が知っていると思っていたことをすべて忘れ、ゼロから学ぶことを決めた
• ユニットテストの不在を補う多層的なフィードバックシステムが存在することを見出した
  • 開発者マシン: ローカルでサイト全体を実行し、変更を数秒で確認（PHP）
  • コードレビュー: すべての変更に対するピアフィードバック
  • 内部ドッグフーディング: 全員が個人的およびビジネス目的でFacebookを使用
  • 段階的ロールアウト: 影響範囲を数百万人のユーザーに限定
  • 自動ロールバック: システムレベルのシグナルが巻き戻しをトリガー
  • 「スター」システム: エンジニアを評価し、低スターの著者はプッシュ不可
  • 可観測性: デプロイ後のメトリクス取得
  • インシデントレビュー: 毎週の上級レビューがあり、責任転嫁は解雇対象
• 最初の機能にユニットテストを書いたにもかかわらず、見つけられなかった結合コードパスによりサイトインシデントを引き起こした
  • システムは好みの方法論の「おかげで」ではなく「にもかかわらず」機能していたと分析
• ユニークなインセンティブ構造も観察
  • IPO前、中間管理職は権利確定したストックオプションで世代を超える富を得ており、会社の価値最大化のため他チームへの異動を勧めるなどグローバル最適化を実践
  • 50/50ゴールシステムでは、目標の半分達成でA+、全達成はサボタージュ（わざと低い目標を設定した証拠）とみなされ、未達成は解雇となる仕組みであった
• ブートキャンプ中に写真配信コードを並列化し、偶然にも年間500万ドルを節約
• 「Good to Great」コーチングプログラム（200人の1対1の生徒、訓練されたコーチを通じてさらに数千人）は、マッチングされたコホートと比較し翌年に昇進する可能性が2倍高いエンジニアを生み出した
• ベックは2017年にFacebookを退社

■ 7. 現在の状況: AIが虎の巻を白紙に戻した

• ベックの現在の主張は、20年以上の「抽出」フェーズで蓄積されたソフトウェアエンジニアリングの虎の巻がAIによって白紙に戻されたというもの
  • ジーニーを使った開発の正しい方法は誰も知らないとする
  • 「虎の巻を知っている」というアイデンティティを持っていた人々は恐怖を感じている
• 製品開発の3つのフェーズ（3Xモデル）を提示し、それぞれ異なる規律を必要とするとした
  • Explore: 無相関な実験を安価に多数試す段階、虎の巻は存在せず「誰も知らない」が正直な答えとなる
  • Expand: 機能する一つのことに集中し他をすべて捨て、次々と障害を乗り越える段階
  • Extract: 予測可能な成長と規模の経済が働く段階、小さな調整が大きな違いを生み、虎の巻が存在し教えられる
• 20年間、業界の大部分は「抽出」フェーズにいたが、AIの登場により全員が再び「探索」フェーズに置かれているとする
  • 虎の巻を書くスキルと適用するスキルは全く異なるものであり、1990年代に成功した人々（Smalltalk、パターン、XP）は虎の巻の書き手であった
  • ベックは自身がこの得意分野（虎の巻を書くこと）にいると述べている
• 開発のペースは加速したがビジネスのペースは加速していないと警告
  • スイッチングコストに依存して利益を守ってきた企業は、そのコストがゼロになる事態に直面する
  • 例として、あるSaaS製品に年間200万ドルを費やしていたクライアントの代替品が「バイブコーディング」により1ヶ月で作成された事例を挙げている
  • ベンダーのカスタマーサービスから製品へのチェーンは5年の応答時間を想定して設計されており、残された時間は1ヶ月しかない状況が生じる
• 「氷山問題」についても警告している
  • バイブコーディングは複雑なシステム（例: グロスからネットへの給与計算）の目に見える先端部分を置き換えるが、水面下のコンプライアンスやレポート要件は手つかずのまま残る
  • 氷山の残りの部分を捨てることでトラブルに巻き込まれる人が出ると指摘

■ 8. 今、ケント・ベックを興奮させるもの

• ベックは新しいSmalltalkをゼロから構築中
  • オブジェクト指向データベース「Arlo」を開発
  • Rustの標準Bツリーを一部の操作で上回るパフォーマンスを示すB+ツリーをRustで構築（Rustのエキスパートではないにもかかわらず）
• これらすべてにAI（ジーニー）を使用しており、鍵となる行動はためらわずにやり直すことであるとしている
• 以前は大きすぎるか退屈すぎて実行できなかったアイデアが40年分あると見積もっている
  • ジーニーが「愚かな細部」（バージョンの競合、依存関係地獄、環境設定）を取り除いたことがものづくりの妨げの解消につながったとする
• 迅速な反復を行っている（プロジェクト、プロジェクト2、プロジェクト3、新規プロジェクト、新規プロジェクト2、ワイプ、異なる実装順序でのやり直し）

■ 9. テーマ横断的な統合

• ベックのキャリア全体をつなぐ3つの糸が存在する
  • 安価に試される馬鹿げたアイデアの価値: TDD、XP、現在のAI実験はすべて彼が笑い飛ばしたアイデアとして始まった
  • 技術に対する人間の優位性: 彼が作成または貢献した主要な方法論はすべて、コードそのものではなく最終的に人間のコミュニケーションと信頼を可能にすることに関するものであった
  • やり直す意志: クライスラーC3の再スタートからGitHubプロジェクトのワイプまで、埋没費用を捨て新たな理解と共に再び始めるパターンが一貫している
• 未解決の緊張関係として、現在のAIの状況がオブジェクト指向プログラミングと同じ軌跡（一貫した虎の巻が現れるまでに15年の実践を要した経緯）をたどるのか、それとも今回の変化速度が根本的に異なるのかという論点が挙げられている
  • ベックの見立ては前者であり、マニフェストは時期尚早でありほとんどの質問に対する唯一の正直な答えは「誰も知らない」であるとしている

(2026/07/10)

個人タスク管理を「判断は人間、更新はエージェント、計算はスクリプト」で設計する

• 個人タスク管理を「判断は人間、更新はエージェント、計算はスクリプト」で設計する

要約:

■ 1. 背景と課題

• 著者はLayerX Ai Workforce事業部でAIエージェント向けデータ基盤を開発しており、複数プロジェクトの並走管理に課題を抱えていた
• 過去5年間Markdownベースのライトなタスク管理を運用してきたが、以下の問題が顕在化した:
  • 期限のないタスクが後回しになる
  • dailyノートからプロジェクト側への情報の書き戻し漏れが発生する
  • 忙しい時期はdailyノート自体が作成されない
  • 真実が二重化し、実態とのズレが拡大する

■ 2. LLM全面導入の失敗と教訓

• LLMにタスク管理を完全に任せる試みを実施したが失敗した
• 失敗原因:
  • 判断に必要な文脈をwikiに書き切れていなかった
  • エージェントの提案の信頼度が低下し、人間側も全体把握が困難になった
• 得られた教訓:
  • 教訓1: 構造化には維持コストがかかり、属性更新・親子整合・ビュー再生成をすべて人間がメンテナンスするのは現実的でない
  • 教訓2: LLMに丸投げすると判断と把握を失い、システムが崩壊する

■ 3. 新しい設計原則: 判断は人間、更新はエージェント、計算はスクリプト

• 3つの責務分担により、保守コストを機械側に分担しながら判断権は人間に残す設計を実現した
• ファイル構造:
  • tasks/配下に_タスク.md（アウトラインの木）、タスクビュー.base（Obsidian Basesの属性ビュー）、ガントチャート.md・依存関係図.md（派生ビュー）、_scripts/（決定論スクリプト）、items//<タスク名>.md（1タスク=1ファイル）を配置する
• 2つの原則:
  • 1タスク=1ファイル:
    • タスク属性（status・期間・優先度・依存）をfrontmatterに記載し、これを唯一の真実とする
    • frontmatterにはtitle、project、status（todo/in_progress/done）、end（期限）、priority、estimate、depends_on（依存タスクのリンク）を記載する
  • ビューはすべて派生:
    • アウトライン、ガントチャート、依存関係図、Basesのテーブルはすべてタスクファイルから機械的に再生成し、手では編集しない

■ 4. NotionやJiraではなくMarkdownを選択した理由

• 最大の理由: エージェントを働かせる場所として、ローカルテキストファイルが圧倒的にやりやすい
• 具体的な利点:
  • 全タスク対象の集計がPython数行で実装可能
  • ファイル書き込みにhookが直接反応する
  • SaaSのAPI認証・rate limit・pagination・スキーマ変換が不要
  • Plain textはコーディングエージェントのホームグラウンドである
  • Git履歴・diff・rollbackが無料で付属する
  • 一括リネームがワンライナーで実行可能
  • 知識ノートと同じvaultに置くとリンク接続できる
• チーム共有はNotionの方が向いているため、手元はローカル、共有用はNotionという役割分担を実施する

■ 5. 責務分担の詳細設計

• 状態更新はサブエージェントに一本化:
  • タスクファイルを書き換える経路を「task-manager」という専用サブエージェント一本に限定する
  • 定義は約240行の詳細仕様であり、10個の不変条件を守りながら原子的に実行する
  • 不変条件の例:
    • ファイル名=title
    • frontmatterスキーマの厳守
    • statusの遷移規則遵守
    • 木とファイルの整合性保持
    • ファイル作成と木のリンク追加を同一操作で実行
    • closeはファイル削除と木からのリンク削除を同時実行
  • 判断はさせない:
    • 優先度の決定、完了条件充足の判断、closeの是非はすべて人間が決定する
    • エージェントは自然言語指示を具体的なファイル操作に翻訳するのみとし、指示が曖昧な場合は確認事項として差し戻す
  • 経路を一本化する理由: 複数経路があると命名規約や木とファイルの整合が必ず破れる
• 計算処理はスクリプトへ移譲:
  • 親タスク期日の子の最遅日への自動引き上げ、見積もりの子タスク合計への自動集計、ガントチャート生成、依存関係図生成、属性ビューの再生成を決定論的なPythonスクリプトに寄せる
  • 理由:
    • 精度: 計算と整合チェックは決定論コードの方が信頼性が高い
    • コスト: 全タスクファイルをLLMに読ませて集計するよりPythonスクリプトが圧倒的に安価
    • 保証: 「計算は決定論の方が確実で安い」はモデル進化によっても変わらない構造的真実である
• 実行タイミングの自動化:
  • 当初はサブエージェントがスクリプト実行を担当していたが、実行忘れのリスクがあった
  • Claude CodeのPostToolUse hookでタスクファイル書き込みを検知し、スクリプトが自動実行される仕組みに変更した
  • ビューの再生成をエージェントの善意に頼らず、サブエージェントのpromptから実行手順記述を削除できた
• 公式ガイダンスとの一致:
  • Claude Code Best Practicesの「指示は助言、毎回確実に起きてほしいことはhookに」と同形である
  • Agent Skillsのガイダンスの「決定論が必要な処理はコードに任せる」とも一致する
  • LLM周りの仕組みには2種類がある:
    • モデル能力不足補完型: モデル進化で不要になるため、作り込むほど負債化する
    • 精度・コスト保証型: 構造的真実は不変であり、安心して作り込める

■ 6. チームへの見せ方

• 方針: 個人の細かい分解をチームには見せず、Notion側にはproject単位でopt-inで同期し、マイルストーン相当の粗いタスクのみ掲載する
• 除外の仕組み:
  • 除外したいサブツリーの根にフラグを立てるのみで、除外集合は木の構造から機械的に算出される
  • 除外の意思はfrontmatterで一度だけ表明すれば波及は自動計算され、後から子タスクを追加しても自動的に除外側に入る
• 安全規則:
  • 自分がownerのタスクだけローカルをSSoTとしてNotionへ書き戻す
  • 他メンバー主導タスクは読み取り専用として扱う
  • closeしたタスクはNotion側で削除ではなくDone状態で保持し、週次報告素材はNotion側の履歴から拾える

■ 7. 日々の運用方法

• 4つのモードで回転し、すべてtask-managerサブエージェント経路に統一する
• モード1 バックログ操作:
  • タスク追加、変更、close
• モード2 計画:
  • 週次計画、朝の計画、日報
  • 朝の計画はコマンド一発で下書きが出力され、数分の微調整で完了する
• モード3 タスク消化ループ:
  • 「次のタスクやって」という指示で日中を回し、エージェントが依存と優先度を踏まえた次の一手を提示する
  • 自分がメンバーとして手を動かし、エージェントがマネージャー的に次の一手を差し出す構図である
  • ただし提案された一手をやるか、優先入れ替え、closeの判断は毎回人間が決定する
• モード4 日次メンテ:
  • 棚卸し、整合確認

■ 8. 3週間運用後の振り返り

• 運用実績:
  • 運用期間23日、タスク数100件（closed 49 / todo 47 / in_progress 4）、プロジェクト数9本
• 過去2方式との比較:
  • 第1期（Markdownライト運用、5年継続）:
    • 破綻原因は書き戻し漏れとビューのズレ
    • 現在は書き換え経路一本化とhookによる自動再生成で「仕組み上起こり得ない」設計とした
  • 第2期（LLM全面導入、失敗）:
    • 破綻原因は文脈不足の判断
    • 現在は判断を人間に残すことで「発生しない」設計とした
• 破綻の原因を意思ではなく仕組みの側で潰せたため、継続の見込みに根拠がある

■ 9. 本業との連動と結論

• 個人タスク管理で使った考え方が、業務でエージェント基盤を設計する際の判断と同じであると気づいた
• 共通原則:
  • 仕事はいちばん信頼できる実行者に降ろす
  • LLMにやらせないことを先に決める
  • 破綻は意思ではなく仕組みで防ぐ
• 個人タスク管理はこの原則を毎日試せる小さな実験場になっている
• 結論:
  • タスク管理ツールの乗り換え問題はツール選択ではなく、責務分担から設計する必要がある
  • 「判断は人間、更新はエージェント、計算はスクリプト」であり、人間に残っているのが判断だけだから続けられる

(2026/07/09)

AIが破壊するIT業界の“人月商売”　「SIerの死」後に“生き残る者”の正体

• AIが破壊するIT業界の“人月商売”　「SIerの死」後に“生き残る者”の正体 - ITmedia ビジネスオンライン

要約:

■ 1. Anthropicショックの発生

• 2月初旬、米AnthropicがナレッジワーカーAI「Claude Cowork」の業務プラグインを発表
• 発表後6営業日で世界のソフトウェア・サービス株の時価総額が約8300億ドル減少し「Anthropicショック」と呼ばれる
• 日本では大手SIerに加え、ベイカレントやSHIFTなどコンサル・開発支援系銘柄も売られた
• 売りの背景にある読み:
  • SaaS株:AIが操作を代替すればシート課金モデル（利用人数に応じた課金）が成り立たなくなる懸念
  • SIer株:計画・進行管理・組み立て・テストといった「人月」を積み上げて稼ぐ構造がAIに置き換えられるという懸念

■ 2. 売りの前提の粗さ

• 金融基幹システムを手掛けるFinatextホールディングスCFO伊藤祐一郎氏の見立て
  • Anthropicが次々出す業種特化型プロダクトの中身は「ほぼただのスキル」にすぎない
  • 中小企業のバックオフィス業務対応をうたうスキルも、実態は会計SaaSのMCP（AIエージェントと外部ソフトを繋ぐ共通規格）連携手順を記した数百行のテキストにすぎない
• 法律やルールに基づく複雑な計算・業務の仕組みである「ビジネスロジック」の領域は、既存事業者に任せるのがAI開発企業側のスタンス
• Anthropicショックは虚像ではなく、構造変化は市場の売りの理屈とは別の場所ですでに進行している

■ 3. SaaSの価値の置き場所の変化

• 伊藤氏の指摘:UIレイヤー（操作画面の使いやすさという表側の価値）はなくなりはしないが、かなり弱くなるのはほぼ確実
• AIが人に代わって操作するようになれば、人がソフトウェアに直接入力する場面が減る
• 画面の使いやすさで選ばれてきたサービスほど影響が大きい
  • 会計SaaS大手freeeの例:機能の網羅性ではなく、会計になじみのないユーザーでも入力しやすいUIを強みに少人数の会社へ浸透し高単価を維持
  • 入力する人間がいなくなれば、この付加価値の根拠が薄れる
• 「データを正しく記録する金庫」である基幹システム「SoR」（システム・オブ・レコード）を提供する企業でも、UIの良さだけで高料金を保ってきた会社は価格競争にさらされるという見立て

■ 4. ビジネスロジックの参入障壁

• 画面の使いやすさに頼らない「データの金庫」機能のみのSoR企業も安泰ではない
  • 伊藤氏:「結局ビジネスロジック（計算の仕組み）とセットでなければ意味がない」
• Finatextの貸付サービスの例:
  • 顧客の年収登録時、法律にのっとって「いくら貸せるか」が常に計算・記録される
  • 年収データの保有自体は難しくなく、価値は複雑なロジックで計算・転換された結果が100％の再現性でたまり続けること
  • AIは確率論でしかなく、100％正しくなければならない計算はAIに任せられない
• このロジックの豊富さがそのまま参入障壁となる
  • 金融の基幹システムは膨大なロジックの積み上げで、数社の寡占状態
  • Finatext自身、証券領域で「5年かけてやっと一部の機能がそろってきた」段階
  • 今からSoRやロジック部分を開発しても先行大手への追いつきはほぼ不可能で「すでに握っている者」が強い

■ 5. 人月商売が削られる中規模市場

• 伊藤氏が「リアルに空いているスペース」と呼ぶのは中規模企業向けシステム市場
  • SaaSの標準機能では要件に届かず、大手SIerに基幹システムを発注する予算もない帯
• Finatext自身がこの帯の当事者
  • 金融関連ライセンスを持つ子会社が8社あり組織は複雑だが、規模はそれほど大きくない
  • 要件を満たすERP導入には「立ち上げに3億～4億円」と言われ断念
  • 安価なSaaSを組み合わせ、APIを自前で繋いで「無理やりねじ込む」対応を継続
• 国内でこの帯に強いのはオービックやワークスアプリケーションズなどの業務パッケージベンダー
  • 蓄積したカスタマイズ資産の横展開でSaaSが届かない個別要件に対応
• この帯で求められるカスタマイズの中身:
  • 会計ロジックそのものではなく、「複数の子会社に所属する従業員がどちらの会社でも申請できるようにしたい」「出力するPDFを自社フォーマットに合わせたい」といった、ビジネスロジックとは関係ない周辺の要望の積み重ね
  • ネックはコードを書く工数であり、AI駆動開発とAIエージェントの双方でコストが崩れれば対応できるプレーヤーが一気に広がる
• そこで効いてくるのがアーキテクチャ（システム設計）の世代差
  • クラウド時代に基幹システムを作り直した「第2世代」は、機能を小分けにして独立させ部分ごとに安全管理を行う手法が標準
  • この設計なら「このデータだけを触りなさい」とAIに制限をかけて作業を渡せる
  • 30年前に作られたシステムにはこうしたノウハウがない
  • 伊藤氏:「今の瞬間の技術力というより、今までの技術の差や始めたタイミングの差で（これからの勝負が）決まってしまう」
• 超大手SIerにしか手が出なかったエンタープライズの個別対応に、規模の小さいソフトウェア会社が入っていける
  • SoRの参入障壁は残るが、崩れるのはその周りを固めていた個別対応の壁

■ 6. 本当のハードルは安全管理

• 大手SIerの間では「金融領域でAI駆動開発は無理だ」という反応が珍しくない
• 伊藤氏の見立ては異なり、技術的にはもうできるが、止めているのは社内の安全統制（ガバナンス）
  • 難所は会社の重要なデータベースにAIを直接接続する局面
  • 「AIにどこまで作業させ、どこまで権限を渡すのか」という管理体制が整わず、多くの企業で実証実験止まり
• 権限設計の具体例:
  • AI時代に必要なのは「全従業員の勤怠データを閲覧できるが、書き込みはできない」といった権限
  • エージェントが勤怠を従業員に不利な形で書き換えれば違法にもなり得る
  • 人間しか使わない前提で作られてきたシステムには、閲覧は全て可能だが書き換えは一切認めないという細かな権限がそもそも用意されていない
• Finatextの対応:
  • AIが勝手に外部ソフトを動かさないよう制限し、パスワード管理やAIの全行動記録を残す統制基盤「MCPaas」（エムシーパス）を2026年中に投入予定
  • 金融のような規制産業では「これがないと、エージェントを自社データにアクセスさせることができない」
• 大手側もこの構造変化を認識
  • 超大手SIerでAI駆動開発を率いる責任者:「AIが全ての成果物を作り、人はそれをレビューする。人の作業とAIの作業が逆転する」
  • AIに開発させるには「旧来は書かなくてよかった情報を書かなければいけない」という、暗黙知の書き起こしという新しい上流工程が生まれつつある
• 伊藤氏は今後の段階を、まずアクセス統制、次にデータ基盤の整備、その先に企業の暗黙知を構造化してAIに渡す「ナレッジストア」の順で見ており、本格化は2～3年後との見立て

■ 7. FDEという新しい働き方

• 開いた市場を取りに行くプレーヤーとして注目されているのが現場派遣型エンジニア「FDE」（Forward Deployed Engineer）
  • エンジニアが顧客の会社に直接入り込み、自社ソフトウェア製品と顧客の実際の業務との間の「ズレ」をその場で埋めながら一気にシステムを完成させる体制
  • 米OpenAIやAnthropicが自ら採り入れたことで日本でも語られるようになった
• 実践例として法人支出管理サービス「バクラク」を手掛けるLayerX
  • 松本勇気CTOはFDEの役割を「お客さまの本当に求めている成果と、プラットフォームとの間にある隙間を埋めること」と説明
  • AIエージェントを業務で使える状態にするまで、普通の会社なら半年から1年かかるところを1カ月以下で終わらせることもある
  • 三菱HCキャピタル向けのリース見積書読み取りエージェントでは1万時間以上の時間削減を見込む
• 従来の常駐型SIとの違いについて伊藤氏は「自社プロダクトの有無」を分水嶺とする
  • 顧客のカスタマイズ要望を受けたとき、AIによるカスタマイズレイヤーで吸収するものと自社プラットフォームに取り込むものを出し分ける
  • 「自社プロダクトを、お客さまのお金を使って鍛え続けるのが一番の価値」であり、これを回せる会社は強くなる
  • 自社プロダクトとして強いものを持たずにFDEを名乗る会社は、結局昔のSIerと変わらない

■ 8. 結論

• 「SIer is Dead」の意味は業態が死ぬことではなく、現場で得た知見がどこにも残らない人月の働き方が終わることにある
• Anthropicショックで市場が値付けし直したのも、AI開発企業に全てが飲み込まれる未来ではなく、この観点だった
• 空いた市場を取り、統制基盤とビジネスロジックを握るのが誰かという椅子は、もはや大手SIerの指定席ではない

(2026/07/09)

コードを仕様書にするために関数型プログラミングをする

• コードを仕様書にするために関数型プログラミングをする

MEMO:

• あえて関数型プログラミングにしなくてもSLAP原則を適用すれば同じ効果は手に入りそう
• 関数型プログラミングのスタイルで書き方を強要するんだという話なのだろうが
• 昔そんなことを考えたこともあった
• 合成関数を用いたSLA原則の実現 - doc.dev1x.org

(2026/07/09)

DeNA会長・南場智子のAI活用術5選がヤバかった

• DeNA会長・南場智子のAI活用術5選がヤバかった

要約:

■ 1. AIを「便利な調べもの相手」として使う限界

• AIを文章要約、アイデア出し、壁打ちに使うことは便利だが、誰でもできる使い方にすぎない
• AIの本当の価値は別のところにある
• DeNA創業者で2024年に自らCEOに復帰した南場智子会長は、元マッキンゼーのコンサルタントでスピードと論理を武器に会社を率いてきた経営者である
• 南場氏は現在、全社を挙げてAIに賭けている
• 本記事では、南場氏の発言やDeNAの取り組みから見えるAI活用の型を、実務に落とし込める形で5つ紹介する

■ 2. なぜ「便利ツール」で終わってしまうのか

• 多くの人はAIを「賢い検索エンジン」として使っている
• 質問を投げて答えをもらうだけの使い方は、AIを単なる情報の自動販売機にしている
• DeNAは2024年、AIを事業成長の柱の一つに据えると公式に打ち出した
• 南場氏はメディアのインタビューで、AIを一部の専門部署のものにせず、全社員が日常業務で使いこなす前提で動くと語っている
• AIは「たまに頼る道具」ではなく「仕事の土台そのものを組み替える存在」という捉え方である
• AIを検索の代わりに使う人と、意思決定の速度を上げる装置として使う人との間には大きな差が生まれる

■ 3. 南場流の本質はどこにあるのか

• 南場氏のAI活用を貫くものは大きく2つある
• 1つ目は「スピード」である:
  • 判断を止めない
  • 叩き台を待たない
  • AIに0を1にさせ、人間は1を10にする役割に回る
• 2つ目は「トップ自ら手を動かす姿勢」である:
  • 経営者が号令だけかけて現場に丸投げするのではなく、まず自分が使い倒す
  • その結果、全社に浸透する

■ 4. 手法1: 叩き台生成で「0から考える」時間をゼロにする

• 資料作り、企画書、メールの下書きといった作業で一番時間を奪うのは「内容を考える」ことではなく「白紙から最初の一行を書き出す」ことである
• この工数を奪う一歩をAIに肩代わりさせる
• 南場氏が重視するスピード経営の発想は、この点に直結する
• AIへの指示例:
  • 「新規事業の企画書の骨子を作って。ターゲット、課題、解決策、収益モデルの4項目で、それぞれ3行ずつ」
• まず粗い骨子を30秒で出させる
• そこから人間が「この課題設定は甘い」「収益モデルはこう変える」と赤を入れていく
• AIに0を1にさせ、人間が1を10に磨くという役割分担を逆にしてはいけない
• AIの最初のアウトプットに完成度を求めず、60点で構わないとする
• ゼロから60点までの一番しんどい部分をAIに任せることが速さにつながる

■ 5. 手法2: 壁打ちの高速反復で「一人ブレスト」を卒業する

• アイデアを一人で練っていると視野が狭くなる
• そうしたときはAIを「反論役の壁打ち相手」として使う
• 元コンサルタントの南場氏は論理の穴を突く思考を得意としてきており、その役割をAIに担わせる
• ただ意見を求めるだけでは足りず、役割を指定する
• AIへの指示例:
  • 「今から私の企画に、投資家の立場で厳しく反論して。甘い前提を3つ指摘して」
• この指示によりAIは賛同者ではなく批判者になる
• 返ってきた反論にさらに再反論する往復を5回繰り返すだけで、企画の穴は驚くほど埋まる
• コツは視点を切り替えることである:
  • 「顧客の立場で」「競合の立場で」「経理の立場で」と役割を変えれば、一人で複数人の会議を回せる
• AIの反論を鵜呑みにせず、あくまで論点を洗い出す装置として扱い、最終判断は人間が握る

■ 6. 手法3: トップダウン導入で「使う文化」を自分から作る

• これは個人技ではなく組織への広げ方の話である
• AIツールを会社で導入しても現場が使わないのは、上が使っていないことが理由である
• 南場氏の姿勢が示すのは、トップ自らが日常で使い倒すという原則である
• 経営者が「AIで作った叩き台をベースに議論しよう」と言えば、現場は一気に動く
• 個人に置き換えても同じであり、まず自分自身が毎日の小さな業務でAIを開く習慣を作る
• 習慣化の例:
  • 「メールの返信は、まずAIに下書きさせてから書く」
  • 「会議の議事録は、AIに要約させてから清書する」
• 1日3回、AIを起点にする業務を固定する
• 号令ではなく率先が重要であり、使う人が増える組織はいつもトップが一番使っている
• この習慣化が一番地味で、一番効く

■ 7. 手法4: 業務プロセスの再設計でAIを前提に仕事を組み替える

• 多くの人は既存のやり方の「一部」をAIに置き換えようとするが、それでは効果は限定的である
• 南場氏がDeNAで進めているのは、AIを「後から足す」のではなく、業務そのものをAI前提で組み直す発想である
• 実践手順:
  • 自分の1週間の業務を書き出す
  • それぞれに「これはAIに任せられるか」と問いを立てる
  • 調査、要約、翻訳、下書き、分類の5つに当てはまる作業は、ほぼAIに寄せられる
  • そのうえで業務の順番を組み替え、人間が最初に動くのではなくAIが下ごしらえをしてから人間が仕上げる流れに変える
• 具体例として、Gmail、音声入力、AI整形の組み合わせにより、移動中に話した内容がそのまま整った文章のメールになる
• 「考える作業」は人間が、「整える作業」はAIが担うよう分けることで、一日の可処分時間が変わる

■ 8. 手法5: 学習の高速化で「わからない」を放置しない

• 経営者は日々知らない領域に直面する
• 南場氏の強みの一つは圧倒的な学習スピードだと評されてきた
• 知らない言葉が出てきたら、その場でAIに聞く
• 聞き方の工夫として、まず概要を平易につかむ:
  • 「この技術を、中学生にもわかるように、身近な例えで説明して」
• そのうえで実務判断に掘り下げる:
  • 「では、この技術のビジネス上のリスクを3つ挙げて」
• 易しい理解から実務判断まで一気に登る
• これは経営者だけの話ではなく、会議で飛び交う専門用語や上司が使う業界のジャーゴンについても、その場でAIに聞けば置いていかれずに済む
• 「わからない」を翌日に持ち越さないことで、学びの速さがそのまま仕事の速さになる
• 注意点として、AIの説明を最終的な事実として鵜呑みにせず、概要をつかんだら一次情報で裏を取るという一手間は残す

■ 9. 「経営者の話でしょ」と思った方へ

• 今回挙げた5つの手法に、特別な予算も専任チームも不要である
• 叩き台を作らせる、反論させる、習慣化する、プロセスを組み替える、その場で学ぶという行動は、すべて無料のAIと今日から始められる
• 南場氏の使い方が優れているのは、高価なツールを持っているからではなく、「スピード」と「自ら手を動かす姿勢」という誰でも真似できる原則を徹底しているからである

■ 10. まとめ

• AIを「便利な調べもの相手」として開いているうちは、その実力の半分も引き出せていない
• 南場流のAI活用を貫くのは、判断を止めないスピードと、トップ自ら使い倒す姿勢である
• 叩き台を作らせ、反論させ、習慣にし、プロセスを組み替え、その場で学ぶという5つの手法がある
• AIを検索の代わりではなく、判断と学習の速度を上げる装置として使うことに、南場流の本質がある
• 今回紹介した5つの手法は、今日からスマホ1つで試すことができる

(2026/07/08)

AI使いまくってる新入社員 「このバグ、AIに聞いてもなんか直らないんですよね…」

AI使いまくってる新入社員

「このバグ、AIに聞いてもなんか直らないんですよね…」

私

「ちょっとエラーメッセージ見せて。…えーっと…」

新入社員

「…！？…読めるんですか…！？」

@lakeside529

MEMO:

• BLAMみたいなサイバーパンク系の作品で、古代の超兵器は残存しているが人類から文字が失われているため、超兵器のコンソールに現れるメッセージは文字や言語ではなく模様としか認識されないみたいなシーン
• 人類から知性が失われてAIを神託として崇める世界に移行する日はそう遠くなさそうだ

(2026/07/08)

AI Agentに自由な開発環境を渡す、Proxmox+LXCで。

• AI Agentに自由な開発環境を渡す、Proxmox+LXCで。

MEMO:

• Dockerコンテナだと色々制約があったり異常に巨大なイメージになったりするので、AIに自由に使わせる環境という意味ではLXCがよいのかもしれない

(2026/07/08)

2028年ディスク生産中止　SIEが決断した「ゲームディスク流通」終了の背景【西田宗千佳のイマトミライ】

• 2028年ディスク生産中止　SIEが決断した「ゲームディスク流通」終了の背景【西田宗千佳のイマトミライ】-Impress Watch

(2026/07/08)

技術を追うのがしんどくなった40代エンジニアは、何を学べばいいのか

• 技術を追うのがしんどくなった40代エンジニアは、何を学べばいいのか｜ゆふかげ | 40代フリーランスITエンジニア

(2026/07/07)

コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった

• コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった

要約:

■ 1. 計測の概要

• 著者は3ヶ月間で62件のPRから300件のレビュー指摘を収集し、分類と評価を実施
• 分類軸はConventional Commentsを参考に6カテゴリを設定:
  • Style: インデントなどの体裁
  • Naming: 命名規則の一貫性
  • Bug: nullエラー、無限ループなどの論理欠陥
  • Architecture: 層構造の適切性
  • Refactor: コード整理の効率化
  • Spec: 仕様書との整合性確認
• 評価指標は後追い採点による3種類:
  • 品質寄与（0/1/2段階）
  • 速度寄与（−2〜+2で開発速度への影響を評価）
  • 3ヶ月後欠陥相関（同種問題が本番バグとして再発したか）

■ 2. 6カテゴリ×3指標の分析結果

• カテゴリ別の計測値:
  • Style: 96件、品質寄与0.4、速度寄与−0.8、欠陥相関0.04
  • Naming: 58件、品質寄与0.7、速度寄与−0.3、欠陥相関0.07
  • Refactor: 47件、品質寄与0.6、速度寄与−1.1、欠陥相関0.12
  • Architecture: 31件、品質寄与1.6、速度寄与−0.4、欠陥相関0.18
  • Bug: 42件、品質寄与1.9、速度寄与+1.2、欠陥相関0.51
  • Spec: 26件、品質寄与1.7、速度寄与+0.9、欠陥相関0.43
• 重要な発見:
  • Bug指摘の欠陥相関（0.51）はStyle指摘（0.04）の約13倍
  • 同じコメント1件でも効き目が1桁異なる

■ 3. nit:が多いレビューほどコードが歪むという逆説

• レビュアーの認知容量は有限であり、スタイル指摘（nit:）が30件あるPRでは他カテゴリ、特にBug候補の検出感度が低下する
• 書き手側も「全部直さなければならない」という疲労から設計判断の思考が浅くなるというのが著者の仮説
• 根拠:
  • Trisha Gee（Oracle）のコードレビューアンチパターン
  • Google Engineering Practicesの優先順位付け（Design → Functionality → Complexity → Tests → Naming → Comments → Style → Documentation）でもStyleは最後に位置し、査読時の負荷分散の必要性を示唆

■ 4. 効果があったのはBugとSpecの2種類のみ

• Bug指摘の実例:
  • PR #142の「空配列時に無限ループする」という1件のissue指摘が、3ヶ月後のCSVインポート機能の本番障害を未然防止
  • 1指摘で本番障害1件相当の価値が発生
• Spec指摘の複利効果:
  • 「タイムゾーン処理はサーバー基準か」という質問1件が、AGENTS.mdへの「全タイムスタンプはUTC保存・JST表示」という共通ルール追加につながった
  • その後3ヶ月でタイムゾーン関連バグがゼロになった
  • Spec質問は直接修正を生まないが、チームの共通理解を更新し、波及効果で複数PRに恩恵をもたらす

■ 5. 価値の低い4カテゴリの処遇

• PRレビューの場から外す戦略を採用:
  • Style: Prettier/Biome/Ruffで機械強制（pre-commitフック）
  • Naming: AGENTS.mdに規則を明記し、CodeRabbitに自動指摘させる
  • Refactor: 別PRのrefactor:タスクとして扱い、同一PRでは指摘しない
  • Architecture: PR提出前の設計レビュー段階で検討する
• 分類後の効果:
  • 3ヶ月のレビュー時間を平均42%短縮
  • Bug/Spec指摘の密度はむしろ上昇

■ 6. Conventional CommentsのROI計測への活用

• ラベル体系を「指摘の角度の名前付け」だけでなく、ROI計測のグループキーとして運用する
• 3ヶ月蓄積後に各ラベルの出現頻度と修正サイクル寄与を可視化できる

■ 7. 実装の3ステップ

• Stage 1: 直近50件の指摘を分類する（10分）
• Stage 2: 3指標で採点する（3ヶ月のバグ報告と突き合わせる）
• Stage 3: 低ROI項目を場所替えする（自動化・規則化・前出し）
• 効果判定:
  • 導入後2週間で判定可能
  • 総コメント数の減少と「issue:」「question:」比率の上昇が成功指標

■ 8. 計測の限界

• 単一プロジェクト（n=300）における著者一人による主観的分類である
• 複数プロジェクト・複数レビュアーでの再現性は未確認
• 分類枠組み自体は転用可能であり、自チームのPRログで2週間で結論が得られる

■ 9. 結論

• 「全指摘を直すレビュー」から「BugとSpecの2種類だけを死守するレビュー」へシフトする
• これにより開発速度を回復させ、真に価値のあるフィードバックに集中できる

(2026/07/06)

AI has torched the market for junior programmers

• AI has torched the market for junior programmers | Seldo.com

要約:

■ 1. 若年層プログラマーの雇用崩壊

• スタンフォード大学のデジタル経済ラボによるADP給与データの分析によれば、22〜25歳のソフトウェア開発者の雇用は2022年後半のピークから19%減少
• 30歳以上のすべての年齢層は同期間に増加し、41〜49歳では14%増
• 企業レベルの影響を制御した後も、AIに代替されやすい職種における若年労働者の雇用は16%減という相対的な減少が確認される
• エントリーレベルの求人は2022年のピークから28%減
• コンピュータサイエンス卒業生の失業率は6.1%に達し、文系専攻の卒業生を上回る水準
• 雇用減少の加速は2024年〜2025年初頭に顕著化し、コーディングアシスタントが単純な補完機能を超えてエージェント型プログラミングへ移行した時期と一致

■ 2. 総雇用統計との乖離

• 米国全体の雇用は2024年5月〜2025年5月にかけて0.8%増
• コンピュータ・数学系職種は1.3%増と経済全体を上回る成長
• ソフトウェア開発者の雇用者数は2022年5月の153万人から2025年5月の169万人へとAI時代を通じて10%増
• 若年層は開発者全体のわずか約8%に過ぎないため、この層での壊滅的な減少が全体の平均値に与える影響は軽微
• 平均値を見る研究では影響が検出されず、若年層に絞った研究では深刻な被害が確認される理由はこのデータ構造に起因する

■ 3. 消えつつある職種タイトル

• BLSデータによると、仕様書に基づいてコードを書く職種「コンピュータプログラマー」は1年間で16%減少（BLSの予測は10年で6%減であったが、大幅に上回るペース）
• Webデベロッパーは11%減、QAテスターは6.5%減
• 一方、データサイエンティストは12%増、システムアナリストは4.4%増
• 消滅しつつある仕事は「仕様に従ってコードを書く」もの、成長している仕事は「何を作るべきかを判断する」もの

■ 4. 新たな開発者層の台頭

• GitHubは直近1年間で3600万の新規アカウントを獲得し、過去最速の成長を記録、新規リポジトリは1億2100万件
• 新規ユーザーの80%が最初の1週間以内にGitHub Copilotを利用
• App Storeへの新規アプリ提出は2016年以来8年連続で減少していたが、2025年に24%増と回復し、2026年Q1は前年同期比80%増
• 急増したアプリのカテゴリはゲームではなく生産性・ユーティリティ・ライフスタイル系であり、自分の問題を解決する初心者の存在を示唆
• 「バイブコーダー」（AIツールを活用するノンプログラマー）の実態:
  • Vercelによれば63%が非開発者
  • Lovableのユーザーの60%が非開発者で、毎日10万以上のプロジェクトを作成
  • Replitは5000万人以上のユーザーを主張
• これらのユーザーはマーケター、創業者、教師、アナリスト、プロダクトマネージャーであり、ソフトウェアを書いているが「開発者」として統計に計上されない

■ 5. キャリアラダーの崩壊と品質リスク

• 従来のソフトウェアエンジニアの育成経路:
  • ジュニアとして採用 → シニアによるコードレビューと指導 → 反復と修正を経て約10年でシニアへ
• AIがコードを書くようになりジュニア採用が消滅し、次世代シニア開発者の供給経路が途絶
• 品質問題:
  • VeracodeのAI生成コード調査では45%が基本的なOWASPセキュリティテストに不合格
  • バイブコーダーのアプリ監査では10%にユーザーデータを露出する深刻な行セキュリティ欠陥
• 企業の対応の分岐:
  • IBM: AIツールを活用したジュニア採用を3倍に拡大し、顧客対応と仕様策定中心の役割に再設計
  • Salesforce: 直前の会計年度でエンジニア採用ゼロ

■ 6. 回復の兆候と今後の展望

• Indeed求人データでは2025年5月を底として13ヶ月連続で増加し、前年比10%増
• 若年層雇用の回復が確認されれば、市場が新たな均衡点を見つけた証左となりうる
• IBMのような育成プログラムを他の主要企業が追随しなければ、ソフトウェア開発ブームは持続しない可能性
• プログラミングは職種タイトルから「タイピスト」のように普遍的な能力へと変容しつつある
• この移行で最も不利益を被るのは、旧来のキャリアラダーが消えた後に参入しようとした世代であり、新たなキャリアの入口の整備が急務

(2026/07/06)

パスワード入力のmaxlengthで長いパスワードで登録できたつもりになってた問題2026

• パスワード入力のmaxlengthで長いパスワードで登録できたつもりになってた問題2026 · GitHub

要約:

■ 1. 主張と反論の概要

• パスワードを15文字に切り詰めて入力するよう案内されたことを根拠に、パスワードが平文で保存されていると主張する者がいる
• この主張は発生している事象と無関係であり、根拠がない
• 「切り詰めができる＝平文または復号可能な形式で保存されている」という推測に基づくが、サーバー側が既存の長いパスワードをわざわざ15文字に短縮更新する理由がなく、論理として成立しない

■ 2. ファクトチェック: SBIベネフィットシステムズの仕様変更

• 対象サービス: SBIベネフィットシステムズ（benefit401k）
• パスワードポリシーの変更内容:
  • 変更前: 6桁～15桁の半角英数字
  • 変更後: 10文字～64文字、英大文字・英小文字・数字・記号のうち3種以上の組み合わせが必要（2026年6月21日より適用）
• ログインフォームのmaxlength属性の変化:
  • 変更前: maxlength=15
  • 変更後: maxlength=64

■ 3. maxlength属性による問題のメカニズム

• HTMLフォームのmaxlength属性は、規定文字数を超えた入力をブラウザ側で黙って切り詰めて送信する
• 旧仕様（maxlength=15）の下では、ユーザーが長いパスワードを入力しても、実際に登録・送信されていたのは先頭15文字のみであった
• 仕様変更（maxlength=64）後、以前に長いパスワードを登録したつもりのユーザーは、手動で15文字に切り詰めなければ以前のパスワードと一致しなくなった
• 同種の問題は2012年のNICOSでも発生していた
• パスワードの保存形式（平文・可逆暗号化・ハッシュ化）に関わらず、maxlengthによる切り詰めが発生していれば同じ問題が起きる
• すなわち、パスワードの保存方法とは一切関連がない

■ 4. 結論

• maxlength属性を使用すると、ユーザーが入力したつもりの文字列と実際に送信される文字列が異なるという問題が生じるため、使用には注意が必要
• バリデーションエラーとして失敗すべき入力が、黙って既定文字数に切り詰められたうえで成功扱いになる点が問題の本質
• 案内の不親切さに対する批判は正当であっても、平文保存の主張には根拠がなく、そのような根拠のない放言をする者の信頼性は低い

MEMO:

• 最初から桁数削られていたという可能性の方が高そうだし蓋然性も十分あるけど、それをもって平文で保存していなかった証明にはならないと思うのだが
• そして、テキストの結論である「平文で保存されているという主張には何ら根拠がなく、そのような放言をする人は信用しないほうが良い」は論点のすり替えで言わんでもいいことであったな

(2026/07/06)

AI時代におけるナレッジ活用の重要性とAI-Ready Data

• AI時代におけるナレッジ活用の重要性とAI-Ready Data | PwC Japanグループ

要約:

■ 1. AI時代におけるアウトプット均質化という課題

• AI技術の飛躍的進化がビジネスモデルを根底から変革しており、企業にとって戦略的なAI導入・活用は不可欠
• 汎用AIモデルへの依存拡大は「アウトプットの均質化」という新たな問題を招く
• 事前学習データのみに基づく回答は一般論にとどまり、差別化が困難
• この課題を打破するカギが「ナレッジの活用」

■ 2. AI-Ready Dataの概念と必要性

• ナレッジの定義:
  • 自社固有の判断基準や業務文脈を指す
  • 構造化データ、非構造化データ、暗黙知の三種が源泉
• ナレッジを反映させることでAIは高解像度のアウトプットを生成できる
• これらのナレッジを早期にAI-Readyな状態に整えること（AI-Ready Data）が求められる

■ 3. ナレッジに着目したデータマネジメントの動向

• ナレッジを重視したデータマネジメントに取り組む企業が増加
• 今後活発化が見込まれる取り組み:
  • データ品質の拡張
  • ナレッジのAIフレンドリ化
  • データアーキテクチャの抜本的改革

■ 4. 将来展望: ナレッジの資本的価値の最大化

• ナレッジの活用はAI時代における大きな差別化要素となり得る
• AI-Ready Dataの成熟に伴い、ナレッジの需要が拡大
• 今後見込まれる展開:
  • ナレッジマネタイゼーション（ナレッジの資本的価値の最大化）
  • ナレッジエコシステムの活発化

■ 5. 競争優位性実現に向けた取り組み

• ナレッジを戦略的資本と位置付け、積極的に投資を行うことが必要
• 経営層主導での意識改革とナレッジ醸成の仕組み作りを早期に進めることが求められる
• ナレッジ醸成成功の両輪となるアプローチ:
  • ナレッジマイニング: ナレッジの持続的な収集
  • ナレッジモデリング: ナレッジの解釈性向上

MEMO:

• AIを使うことで誰でも一定のアウトプットが出せるようになると、それが最低ラインになり差別化が困難になる
• 今後差別化要因となるのは一般論としてAIに書き込まれた情報以上のナレッジであるというお話
• とはいえそんなものが簡単に出てくるわけでもないと思うのだが

(2026/07/06)

Prompting Claude Fable 5

• Prompting Claude Fable 5 - Claude Platform Docs

要約:

■ 1. 概要

• Claude Fable 5 および Claude Mythos 5 に特化したプロンプティングおよびスキャフォールディングのパターンを解説するガイド
• 従来モデルでは対応が困難だった複雑・長期・曖昧なタスクを処理可能
• 数時間〜数週間を要するエンドツーエンドの作業に特に効果的
• Claude Opus 4.8 からの行動上の差異があり、プロンプトやスキャフォールディングの更新が必要な場合がある
• 安全分類器が攻撃的サイバーセキュリティ技術・生命科学分野・思考内容の抽出を対象としており、関連リクエストは stop_reason: "refusal" を返す場合がある

■ 2. 能力の向上点（Claude Opus 4.8 比）

• 長期自律性: 長時間にわたる目標志向の実行を維持し、複雑なタスク全体で指示を保持
• 複雑な問題への初回正答性: 以前は数日を要した実装がシングルパスで完了した事例がある
• ビジョン: 技術的な画像やスクリーンショットをより高精度に解釈し、より少ないトークンで処理
• エンタープライズワークフロー: 財務分析、スプレッドシート、スライド、ドキュメントで専門的品質の出力を提供
• コードレビューおよびデバッグ: バグ検出の再現率が向上し、コードベースおよびリポジトリ履歴の横断的な検索が可能
• 曖昧さへの対応: 複雑でマルチスレッドなリクエストに対してもネクストステップを適切に判断
• 委任・協調: 並列サブエージェントの展開と管理が大幅に信頼性向上

■ 3. ターンの長期化

• 高 effort 設定での困難なタスクは数分単位、自律実行は数時間に及ぶ場合がある
• 移行前にクライアントのタイムアウト、ストリーミング、進捗表示の調整が必要
• ハーネスをスケジュールジョブ等の非同期確認方式に再設計することを推奨
• タスクが曖昧な場合の過剰計画防止のため、「十分な情報があれば行動せよ」という指示を追加する

■ 4. effort レベルの使い分け

• effort はインテリジェンス・レイテンシ・コストのトレードオフを制御する主要パラメータ
• 設定の目安:
  • high: 大多数のタスクのデフォルト
  • xhigh: 最も能力が求められる作業
  • medium / low: ルーティンワーク
• 高 effort 設定では過剰な検証・不要なリファクタリングが発生しうるため、スコープを絞る指示が有効

■ 5. 指示追従性の強化

• 簡潔な指示で大半の挙動を制御可能
• 長い列挙よりも短い簡潔さ指示の方が同等の効果を発揮
• 簡潔さ指示の例:
  • 最初の文で結論を述べること
  • 省略は詳細の選別によって行い、断片化・略語・矢印チェーンは使わないこと
• 長期ワークフローでのチェックポイント挙動についても、列挙ではなく原則を与えることで制御可能

■ 6. 長期実行中の進捗主張の検証

• ツール結果に基づいた進捗の自己監査を指示することで、虚偽の進捗報告をほぼ排除可能
• 推奨指示: 進捗報告前に各主張をセッション内のツール結果と照合し、検証済みの成果のみを報告する

■ 7. 境界の明示

• 要求していないアクション（メール下書き、git バックアップ作成など）を自発的に行う場合がある
• 実施すべきこと・すべきでないことを明示的に定義する指示が必要
• 推奨指示: 問題記述や質問の場合は評価のみを返し、修正は求められるまで実施しないこと

■ 8. 並列サブエージェント

• 過去モデルより積極的に並列サブエージェントを展開する
• サブエージェント使用のガイダンス:
  • 独立したサブタスクはサブエージェントに委任し、処理を継続する
  • オーケストレーターとサブエージェント間は非同期通信を優先する
  • 長期稼働のサブエージェントはキャッシュリードによりコストと時間を節約できる

■ 9. メモリシステムの構築

• 過去の実行から得た教訓を記録・参照できる環境で特に高い性能を発揮
• Markdown ファイル等のシンプルな形式で記録場所を提供するだけで有効
• メモリ指示の例:
  • 1ファイル1教訓で要約を先頭に記述
  • 修正内容と確認済みのアプローチの両方を記録
  • リポジトリやチャット履歴に存在する情報は保存しない
• 既存の過去セッションを元にメモリシステムをブートストラップする指示も有効

■ 10. 早期停止の稀な事例

• 長いセッションの途中でツール呼び出しを発行せずにテキスト宣言のみで終了する場合がある
• 対処: 「continue」や「エンドツーエンドで実行せよ」の指示で再開可能
• 自律パイプライン向けには、ユーザー不在を前提とした継続実行を指示するシステムリマインダーを追加する

■ 11. コンテキスト予算に関する稀な事例

• 残りトークンのカウントダウンが提示されると新セッションの提案や自己縮小が発生する場合がある
• 対処: ハーネスで残りトークン数を明示的に表示しないこと
• 必要な場合は「コンテキストは十分残っている、継続せよ」という安心指示を追加する

■ 12. 理由の提示

• リクエストの背景・意図を伝えることで性能が向上する
• 推奨フォーマット: 「[大きなタスク] を [対象者] のために進めている。[出力が可能にすること] が必要。その上で: [リクエスト]」

■ 13. ユーザーへの伝達時の可読性

• 長期・エージェンティック会話では密な略語・矢印チェーン・専門用語が混入しやすい
• 通信スタイルの追記でこれを軽減:
  • ツール間の思考は簡潔でよい
  • 最終サマリは読者がそれまでの経緯を知らない前提で書くこと
  • 完全な文章で記述し、略語・矢印チェーン・自作の略称は使わないこと
  • 結果を最初の文で述べ、その後に詳細を続けること

■ 14. send-to-user ツールの作成

• 長期・非同期エージェントがユーザーへの伝達内容を正確に届けるためのツール
• 用途: 成果物の提示、具体的な数値を含む進捗更新、ユーザーからの質問への直接回答
• ツール入力はサマリ化されないため、内容がそのまま届く
• システムプロンプトでの明示的な呼び出し指示がなければ稀にしか呼び出されない
• 内部推論やナレーションには使用しないこと

■ 15. 推奨スキャフォールディング変更

• 難易度の高いタスクから開始:
  • 過去モデルより困難なタスクを割り当て、Claude にスコープ確認と実行をさせる
• 長期実行における自己検証の明示:
  • 独立した検証サブエージェントを使用し、定期的な作業確認を実施する
• 既存プロンプト・スキルの見直し:
  • 過去モデル向けの過度に規範的な指示は品質を低下させる可能性があるため削除を検討する
• 推論内容の出力指示を避ける:
  • 内部推論を応答テキストに反映させる指示は reasoning_extraction 拒否を引き起こす場合がある
  • 推論の可視化には adaptive thinking の thinking ブロックを使用する
• send-to-user ツールの導入:
  • 長期・非同期エージェントではターンを終了せずにユーザーへメッセージを届けるために導入する

(2026/07/05)

AIで実装コストが低くなった今、エンジニアは上流に行くべきか？

• AIで実装コストが低くなった今、エンジニアは上流に行くべきか？｜いしい

要約:

■ 1. 上流への染み出しの現状

• スマートバンク社では、AIによる実装速度の3倍化によりPMが業務ボトルネックとなり、エンジニアとデザイナーがPRD作成・仕様策定を担うようになった
• LayerX社では、Coding Agentが実装コストという制約を外した結果、ボトルネックがコーディングから「何を作るか」に移行し、課題定義の甘さが「仕様負債」としてデータ設計に跳ね返るようになった
• サイバーエージェント社では2026年評価制度から「ビジネスリードエンジニア」のキャリアパスを新設し、ABEMAではエンジニアが放送・制作現場に入ることで改善期間が1ヶ月から3日に短縮された事例がある

■ 2. 「上流」という概念の整理

• 「上流」という水流メタファーには二つの誤った前提が含まれる:
  • 流れが一方向（要件→実装）という前提 — 実際の開発はループ構造であり、ウォーターフォールの原典であるRoyce(1970)自身も一方向モデルの危険性を警告していた
  • 上下の序列（上流=上位）という前提 — これはSIerの多重下請け構造に由来する日本ローカルの感覚であり、ソフトウェア開発の本質ではない
• 本稿では「上流」を三層に分解して扱う:
  • 業務層: PRD作成、要件整理、仕様策定など作業としての上流
  • 判断層: 何を作り何を作らないかを決めること
  • 責務層: 判断結果への責任を負い、プロダクトにオーナーシップを持つこと
• AIがコストを下げたのは主に業務層であり、判断の機会は増えておらず、責務は依然として特定の人間が負い続けている

■ 3. 業務層への染み出し

• 要件記述者と実装者の分業は、実装が高価だった時代の最適化であり、文脈が手渡しのたびに減衰するという損失を内包していた
• AIにより実装コストが低下した結果、「文脈を持つ人がそのまま作る」ほうが速く正確になり、分業の損得が逆転した
• DevOpsが運用と開発の境界を溶かしたのと同様に、現在は要件と実装の境界でより速く同じことが起きている
• 業務層への染み出しが有効なのは「エンジニアという職種」ではなく「文脈と実装を同じ人に載せる構造」であり、文脈なしに業務だけ巻き取っても減衰の発生源が移るだけ
• 必要な文脈の深さは「PRDを一から書き切る力」ではなく「渡された要求を一段問い直す」程度から始められる
• 結論: 文脈を拾いにいく姿勢とセットである限り、業務層への染み出しはYes

■ 4. 判断層への染み出し

• 「何を作るかを決めることが最も難しい」というBrooksの指摘は、実装が安くなった現在も有効
• プロダクトの方向性は足し算できないため、判断の打席は参加人数に比例して増えない——「全員が上流へ」は個人には合理的でも全体では成立しない
• 実装速度が上がった組織では「誰も決めていない領域」が広がっており、個人が狙えるのはこの空白を引き受けることである
• 業務を巻き取っても判断権は自動で付与されず、組織による権限の再配分の承認が必要
  • 承認機構が機能する組織では「気づいたら任されていた」が起きるが、機能しない組織では「便利にPRDを書いてくれる人」で止まる
• 判断層で個人にできることはスキル投資に閉じず、「この範囲の意思決定を委譲してほしい、結果はこの指標で見てほしい」と明示的に交渉することが必要
• 交渉に応じない組織では、環境を変える判断も視野に入る

■ 5. 責務層への染み出し

• 責務層への染み出しはまだ進行中の実験であり、業務を移譲したスマートバンク社のPM自身が「業務と責務は別物」と明示し、責務の移転達成を宣言していない
• 責務が育つ経路の特殊性:
  • 判断層は範囲を区切って委譲でき、スコープ内で経験を積める
  • 責務はロードマップのギャップフィル、説明責任、負債を抱えた次の判断というループを引き受けた回数でしか育たず、兼務での習得は困難
• キャリア設計の既視感:
  • 「価値は上流にある」を責務層まで拡大すると「全員がそちらを目指すべき」になり、「昇進=マネージャー」という単線キャリアの失敗の再現となる
  • 技術力・マネジメント力・ビジネス感覚を高次元で備える人材は希少であり、責務層まで踏み込める人はそれくらい希少と捉えるべき

■ 6. 染み出しの双方向性

• Anthropic社でコーディング経験ゼロの営業担当がClaude Codeで社内ツールを構築しGTMエンジニアに転身した事例のように、ドメイン側の人が実装に寄ってくる動きも存在する
• 「文脈と実装を同じ人に載せると速い」という力学はエンジニアだけに味方するものではなく、競争優位は職種よりも問題への近さから生まれる
• チームの遅さの原因に応じて対応が異なる:
  • ハンドオフの待ち時間が原因 → 分業の境界を畳む
  • ドメイン知識不足が原因 → 専門を深める
• 生成コストが低くなるほど検証・レビューという判断が新しいボトルネックになり、深い専門性を持って検証側に立つ道はむしろ価値が上がっている

■ 7. まとめ: 3つの判断軸

• 層の確認:
  • 業務層 → 積極的にチャレンジすべき
  • 判断層 → 権限の交渉も必要
  • 責務層 → 宣言と組織との合意によって初めて始まるものであり、「気づいたら染み出していた」性質のものではない
• ボトルネックの診断:
  • ハンドオフの待ち時間が原因 → 分業を畳むのが正解
  • ドメイン専門知の不足が原因 → 分業を維持して専門を深めるのが正解
• 足場の確認:
  • 実装力を保持したままの統合か、実装からの離脱かを見極める
  • 実装の足場を失うとAI出力を検証する能力も失われ、足場ごと上流に移る染み出しは無謀な選択

(2026/07/04)

“開かずの基幹システム”、450人月→実質2カ月で解読　創業100年のカクヤス、生成AIで挑む...

• “開かずの基幹システム”、450人月→実質2カ月で解読　創業100年のカクヤス、生成AIで挑む「転生」：AWS Summit Japan 2026（1/2 ページ） - ITmedia NEWS

要約:

■ 1. 背景と課題

• カクヤス（現・ひとまいるグループ）は約30年前にVisual BasicとOracleで構築した基幹システムを運用し続けてきた
• 建て増しを重ねた結果、設計書なし・一部コード紛失・試験環境なしという状態に陥り、社内に全体を把握する担当者が誰もいなくなった
• システム規模:
  • 操作画面2,200本
  • データテーブル3,000本
  • ストアドプロシージャ1,200本
• 人手による解析の試算は450人月、期限まで残り2年という状況で「1年経っても地図すら描けない」状態だった
• VMwareの契約が2027年7月に切れるという動かせない期限が迫っていた
• 会社としても2025年7月に持株会社名をカクヤスグループからひとまいるに変更し、酒類卸から物流業への業態転換を宣言した背景があった

■ 2. 解決アプローチ: AI駆動開発と業務駆動開発の両輪

• AI駆動開発:
  • Amazon BedrockとClaude Codeを活用し、1,200本のストアドプロシージャを解析
  • 抽出した6つの業務ロジック:
    • テーブル間のデータ移動
    • 在庫の評価額計算
    • 売価計算
    • 与信計算
    • 在庫の引き当て
    • 空容器の回収（酒類業界独自の商習慣）
  • 本番のOracle環境をAWS上に再現し、挙動検証の足場を整備
  • 実質2カ月で解析を完了
• 業務駆動開発:
  • 営業・商品・店舗・物流・経理の各部門から人員を集め、AIの解析結果を業務言語に翻訳
  • 2,200あった画面を業務に必要な約800へ凝縮（機能削減ではなく物流業として走るための再設計と位置付け）
• 「AIだけでも現場だけでも進まなかった。両輪がかみ合って初めて前に進めた」と担当者が語った

■ 3. AIを制御する4つの技術

• 記憶の補強: AIが忘れた内容を都度思い出させ続ける仕組み
• ルールの外部化: ルールを人の頭ではなくAIが参照するファイルに置く
• 人格の付与: 役割と経歴を与えてAIの思考の土台を定める
• 2段階方式: コード生成プロンプトを直接作らず、「プロンプトを作るためのプロンプト」から組み立てる
• これら4点が「現場での最大の発見」であり、AIは丸投げでは動かないと強調した

■ 4. 要件整理の方法論: 5W2H構造化

• AI駆動開発の最大のボトルネックはコードではなく要件の整理にあると判断した
• 現場からの曖昧な依頼を「5W2H」で構造化するフレームを導入:
  • 誰が・何を・なぜ・いつ・どこで・どのように: 依頼文からある程度推測して補完できる
  • HOW MUCH（費用・期限）: 依頼者が言い忘れやすく、確認が必要な項目
• 「要件整理の質がそのまま成果物の質になる」と指摘し、「システムエンジニアがビジネスエンジニアになる時代が来た」と語った

■ 5. 現状と今後の展望

• プロジェクトは現在も進行中であり、「万事解決のハッピーストーリーではなく、道半ば」と担当者が述べた
• 進行中の取り組み:
  • 現場主導による業務フローの再構築
  • 新旧システムの比較による段階的な切り替え
  • 部門横断のデータ基盤の整理
• 今後の展望:
  • 物流データ自体が商品になるとの認識のもと、「AIを使う時代」から「AIと考える組織」への転換を目指す
  • 「30年の因習をAIと業務の力で解体する。100年の老舗が生成AIと共に転生していく物語はまだ終わっていない」と締めくくった

(2026/07/03)

とほほの「生涯エンジニア」入門

• とほほの「生涯エンジニア」入門 - レバテックLAB

要約:

■ 1. 人物概要

• 「とほほのWWW入門」管理人・杜甫々（とほほ）氏のキャリア回顧録
• 1988年にメーカー系ソフトウェア子会社に入社し、2025年に定年退職（同一会社に38年勤続）
• 1996年にWeb技術解説サイト「とほほのWWW入門」を開設し、現在も運営継続

■ 2. エンジニアになるまで

• 1982年、高校生のときにコモドール社のVIC-1001（マイコン）でコンピュータに初めて触れる
• 大学ではPC-8801、PC-9801、Apple II、パンチカードなど多様な環境でプログラミングを経験
• 当初は中学校理科教師を目指していたが、アルバイトでのプログラミング経験を経てエンジニアに転向
• 1988年（最後の昭和入社として）地元のメーカー系ソフトウェア子会社に就職

■ 3. キャリアの軌跡

• 入社直後:
  • 3カ月の新人研修（既知の内容が多く退屈）
  • 配属先は開発と研究を半々で行う半研究所的部門
  • 自由な雰囲気の中で業務の合間に仮想OSもどきを自作し、先輩に評価される
• 入社3〜6年目:
  • プログラマーとして最も充実した時期と自己評価
  • 夜遅くまで開発に没頭し、A案・B案を両方実装して比較するなど試行錯誤を重ねる
  • 後輩への指導方針として「答えを教えるのではなく調べ方を教える」を習得
• 10年目以降（管理職期）:
  • 役職上昇とともに管理業務が増加し、第一線の開発からは離れる
  • 「上方向（上司・上層部向け報告）・横方向（顧客折衝）・下方向（部下育成）の仕事」を意識するようになる
  • 上方向の仕事の割合が多かったと振り返る
• 40歳過ぎ以降（技術専門職期）:
  • 管理職から技術専門職へ配置換えを希望し実現
  • 各プロジェクトへ「流しのアーキテクト」としてアーキテクチャ設計支援・技術支援を担当
  • 蓄積したノウハウ集は500項目超に達する

■ 4. 長寿プロジェクトへの思い

• 最初にメインプログラマとして携わったネットワーク管理システムは定年退職時点で35年目を迎えるプロジェクトに成長
• 自ら発案・開発したセキュリティ管理システムは24年目、クラウド管理システムは12年目として継続中
• 携わったプロダクトが世に出て使われ続けることに喜びを感じる

■ 5. 「とほほのWWW入門」の開設と運営

• 管理職となり自身のコーディングが減った時期に、趣味と実益を兼ねて1996年に開設
• 会社固有の秘密・ノウハウは公開しないという条件で会社の許可を得て継続
• 技術を「理解すること」と「説明できること」はレベルが異なるという気づきを運営を通して得る
  • 整理・確認・記述のプロセスが深い理解につながる
• 「好きだから続けられる」というサイクル（調べる→まとめる→公開する→反響をもらう）が継続の動機
• 2025年に開設30年目を迎える

■ 6. 同一会社に38年間勤続した理由

• 転職・起業を全く考えなかったわけではない
• 携わったプロジェクトや引き継いでくれた仲間への愛着が転職を思い留まらせた
• 気づけば定年まで勤めていたという自然な結果として捉えている

■ 7. 定年退職と退職後の生活

• 65歳まで延長も可能だったが、60歳で定年退職を選択
• 退職後はプログラミングへ回帰することを主な目標とする
• 退職直後に日本全国陶磁器巡りの旅で気分をリフレッシュした後、プログラミングを再開
• 自分の手でプログラムを仕上げていく達成感を改めて実感

■ 8. AIの台頭への向き合い方

• 当初はAIコーディングアシスタントと張り合おうとしたが、コードの質で完敗と認める
• 退職後に夢見ていた「プログラマーとしての生活」がAIにかっさらわれた感覚を覚える
• 現在の開発スタイル:
  • Codexをメインの開発ツールとして使用
  • Claude Codeにコードレビューを担当させる
  • Gemini、Copilotなども試しながら使い分け
  • Copilotは情報源リンクがBingになる点を問題視し「喧嘩別れ中」
• AIが書いたコードにアーキテクチャ面の修正を指示する役割となり、会社員時代と変わらない開発形態に落ち着く
• プログラミング言語の変遷をアセンブラ→高水準言語→自然言語（プロンプト）の進化として捉える
• 「何をつくるか」を考え「いいね」と言ってもらえるものをつくる役割は開発者に残り続けると考える

■ 9. 今後の展望

• 具体的な将来計画は特に持たない
• 「何かをつくってみたい」「分かったことを誰かに伝えたい」「いいねと言ってもらえるとうれしい」という動機は変わらない
• 肩肘張らず真面目に技術と向き合い続けることを方針とする

(2026/07/02)

Ozymandias on Rails. The Pedestal Inscription

• Ozymandias on Rails. The Pedestal Inscription | baweaver

要約:

■ 1. Ozymandias の比喩と問題の本質

• シェリーの詩「Ozymandias」（1818年）を引用し、巨大なRailsモノリスが時間と共に廃墟となる比喩として使用
• 筆者は15年近くRailsモノリスの内部で働いた経験を持ち、成功して成長したシステムほど問題が深刻化することを述べる
• 大規模になったシステムに共通する状態:
  • 誰にも所有されない広大なコード領域が生まれる
  • エラーチャンネルが数ヶ月にわたって赤く点灯し続け、解決不能に見える
  • システム全体の形を把握できる人間が一人も存在しなくなる
• 構築者たちが去り、知識が少しずつ失われ、残されたものは廃墟のように感じられる

■ 2. Vanilla Railsの限界

• 「Vanilla Railsで十分」という議論:
  • コールバック、コンサーン、ファットモデルなど、Railsのデフォルトを規律正しく使えば、多くの人が思うより長く機能する
  • アーキテクチャの抽象化は不要な複雑さを招くとされる
• DHHの一貫した立場:
  • 2016年にマイクロサービスよりモノリスを推奨
  • 2020年にモノリスが限界を迎えた際に単一サービスの切り出しを認める
  • RailsWorld 2025では「複雑さの商人」というフレームで批判を継続
• 議論には前提条件が付いていることを指摘:
  • マイクロサービスは数千人規模の企業向けで、モノリスは小さなチーム向け
  • 37signalsでさえShopify規模では通用するか不明と認めている
• 議論の本質的な問題:
  • すべての議論は特定の時点における特定チームについてのもの
  • チームが12人から数百人に成長し、10年で制度的な記憶が薄れることへの対処がない
  • 退職のたびにコンテキストと知識が失われ、多くは文書化されていない
  • 読者は「壮大なモノリス」「Vanilla Railsで十分」という見出しだけを記憶し、免責事項を忘れる
• Ozymandiasの比喩との対応:
  • 台座には「特定規模の王国にしては印象的」とは書かれず、条件なしに「我が業を見よ」と刻まれている
  • 継承するシステムは免責事項を持たない見出しだけを信じた人々によって構築された

■ 3. Railsの技術的な問題点

• コールバックが不可視の制御フローになる:
  • 30個のコールバックを持つモデルは単一の保存操作で16の実行パスを生む
  • 12番目のコールバックを追加した人は、他のコールバックとの順序関係を把握できない
  • コントローラーを読む人はコールバックの存在自体に気づかない
  • バイパス経路がRailsガイドにも記載されており、一括操作で常用される
• ActiveRecordが境界を越えてリークする:
  • リレーションはライブなデータベースハンドルとして返され、呼び出し元が書き込み、N+1クエリを発生させ、契約外のカラムに依存できる
  • すべてのActiveRecordオブジェクトは生成元のコードとそれ以降のすべての利用箇所との間の暗黙的な結合を生む
• ポリモーフィック関連の構造的欠陥:
  • notable_typeカラムにはRubyクラス名が、notable_idには任意のテーブルへの整数が格納される
  • データベースは外部キーで強制できず、文字列だけがテーブルを識別する情報となる
  • デリゲーターがクエリからtype句を消し去る可能性がある
  • クラス名変更時にすべての保存済み文字列が無効になる
  • ジョインが不可能で、3チームが同一テーブルに書き込み、誰も管理しない状況が生まれる
• インデックスが制御不能なクエリのために構築される:
  • どのコードからもSeat.where(column: value)が実行できる環境では、最適化すべきクエリの形が無限になる
  • すべてのフィルタ対象カラムにインデックスを作成し書き込みオーバーヘッドを支払いながら、未知のクエリへの対処は困難

■ 4. 所有権の崩壊

• コードが全員に属する場合、誰にも属さない
• DHHが言う「所有権」との区別:
  • DHHの所有権は垂直: フレームワークからOSまでスタック全体を所有し、ベンダーを排除する
  • モノリストで崩壊する所有権は水平: 30チームが同じコードに触れる際に、どのチームがどのモデルやテーブルに責任を持つか
• 規模と所有権の関係:
  • 小チームでは所有権は暗黙的で全員が互いに話しているため機能する
  • 3〜4チームを超えると暗黙的な所有権は崩壊し、誰も所有しない状態に移行する
  • チーム間のギャップにあるコードが最も早く成長し、最も頻繁に壊れ、最も変更困難になる
• 所有権のないハザードの複合効果:
  • 16パスのコールバックは危険であり、誰も所有しないコールバックは誰も修正責任を持たない危険
  • 構造的に不健全なポリモーフィックテーブルに3チームが書き込み誰も管理しない場合、政治的にも変更困難
• 大企業の対応事例:
  • GitLab: ポリモーフィック関連を禁止
  • Shopify: Packwerkを構築
  • Gusto: Packwerkを採用しモジュール性ツールのエコシステムを構築
  • GitHub: 200万行以上のモノリストに1000人以上のエンジニアが継続的にアーキテクチャと境界に投資
• 中間規模の企業が直面する現実:
  • 37signalsでもShopifyでもない多くの企業が存在する
  • 共有コンテキストが機能しなくなった後、独自の境界ツールを構築できる規模には達していない
  • Railsは最速のスタートを提供したが、モノリストの次に進む「舗装された道」を用意していない
  • ドクトリンは境界ツールの必要性を規律の失敗として扱い、成長の段階とは見なさない

■ 5. 回復のアプローチ

• 「全部書き直す」の誘惑と失敗:
  • Joel Spolsky（2000年）: 大規模な書き直しが失敗するパターンを説明
  • Fred Brooks: 「第二システム効果」として命名 ─ 第二版は過剰設計になりがち
  • Netscape: Navigatorをゼロから書き直し、3年間何もリリースできずブラウザ戦争に敗れた
• AIによる書き直しの誘惑:
  • AIにより書き直しが安価に見えるが、Gartnerの2026年予測によれば、AIを活用したレガシー変換の3分の2以上が失敗する
  • 難しいのは既存コードが何をしているかを理解することであり、AIはシステムの形を数時間で再現できても10年分の修正とコンテキストを見落とす
• 部分的な抽出が正当化される条件:
  • 明確な所有権と明確に定義されたインターフェースを持つシステムの独立した部分
  • モノリスの構造が修正を妨げていることの測定可能な痛みがある
  • どのリクエストが、どのチームにとって、何が修正不能かという具体的な証拠が必要
• 機能するアプローチ: 段階的な回復:
  • 見た目ではなくコストで測定して何が壊れているかを理解する
  • 障害をコード内の発生箇所まで追跡すると、未所有コード・共有モデル・全員が書き込むテーブルに集中する
  • それらの場所の周囲に境界を引き、所有権を割り当て、暗黙を明示的に変える
  • システムをサービス中のまま実施する
• 回復の本質:
  • 所有権、境界、トラフィックを処理しながら適用する忍耐
  • 数年規模の取り組みで、機能開発・インシデント対応・採用と並行して実施する
  • ドラマチックな話にはならないが、機能することが確認された唯一のアプローチ

■ 6. シリーズについて

• シリーズ名「Ozymandias on Rails」の意味:
  • 詩は永続性が幻想であることを示す
  • 国王に何が起きたかは不明であり、業績は残らず碑文だけが残った
• Railsと大規模システムの関係:
  • Railsは素早い構築を可能にした
  • 構築されたシステムは成功し、成長し、雇用し、10年以上にわたって機能し続けた
  • これはフレームワークや使用した人々の失敗ではない
  • モノリスは機能し続け、なぜそのような形をしているかを誰も覚えていない時点まで機能した
• このシリーズの目的:
  • これらのシステムの内部にいる人たちに向けて、次に何をするかを示す
  • 10年以上続くシステムを次の10年も生き続けさせること
  • 本当に炎上しているものと単に問題があるように見えるものの区別を学ぶことから始まる
• 次回のポスト: 「炎上」と「危険に見えるだけ」の区別について

(2026/07/02)

「Herdr」を使い始めたら、もう他のターミナルには戻れなくなった

• 「Herdr」を使い始めたら、もう他のターミナルには戻れなくなった

MEMO:

• これはよさそう

(2026/07/02)

オープンソースのゲームエンジン「Godot」、“生成AIを用いた開発参加”を制限へ。管理の負担もすごいし...

• オープンソースのゲームエンジン「Godot」、“生成AIを用いた開発参加”を制限へ。管理の負担もすごいし、コミュニティが育たないので - AUTOMATON

要約:

■ 1. 概要

• オープンソースゲームエンジン「Godot Engine」の運営元（Godot財団）が、2026年6月30日にコントリビューター向けガイドラインの近日改訂を発表
• 改訂により、生成AIを用いたコントリビューションに一定の制限が加えられる

■ 2. Godot Engineの概要

• PC・モバイル・Web向けの2D/3Dゲームおよびアプリを制作できるオープンソースゲームエンジン
• 完全無料で利用可能であり、開発コストは寄付によって賄われている
• 近年インディーゲームを中心に採用例が増加し、大手スタジオでも活用される
• GitHub上でバージョン管理されており、誰でも自由にディスカッションへの参加やプルリクエストの提出が可能

■ 3. 問題の背景

• 生成AI（LLMなど）を用いたプルリクエストが急増し、質の低いコントリビューションが増加
• 問題のある具体例:
  • 意味不明な内容のコード
  • 過度に冗長な説明文
  • 投稿者自身が変更点を把握していないケース
• 妥当性を判断するレビュアーの不足:
  • プルリクエストの増加に対して、資格のあるレビュアーが不足
  • 対応が不可能になりつつある状況
• レビューの本来の役割の喪失:
  • 新たなコントリビューターを育成し、将来のレビュアーやメンテナーへ成長を促す役割があった
  • 現在はフィードバックを返してもAIに吸収されるだけとなり、レビュアーの士気が低下

■ 4. 新ガイドラインの内容

• 禁止事項:
  • 自立型AIエージェントの使用
  • バイブコーディング
  • AIによるコード生成（提出コードはすべて人間が作成したものであることが必須）
  • 人間同士のコミュニケーション（プルリクエスト等）におけるAI生成テキストの使用
• 限定的に許可される事項:
  • コード補完
  • 正規表現の生成
  • 検索・置換などの単純作業
  • 機械翻訳（元の文章が人間によって書かれている場合に限る）
• 義務事項:
  • コードの作成過程でAIを使用した場合、プルリクエストの議論内でその事実を明記すること

■ 5. 禁止の理由と方針

• 全コントリビューションは、自身のコードに責任を持ち、必要に応じて修正できる意思と能力を持った人間によっておこなわれるべきとの方針を明確化
• AIは責任を負うことができない
• AIを頻繁に使用するユーザーが自分のコードを十分に理解して修正できるとは限らない
• レビュアーへの敬意という基本原則として、AIではなく人間との対話を重視

■ 6. 今後の見通しと業界動向

• Godot財団は引き続き保守的なアプローチを維持しつつ、今後の状況に応じて再評価をおこなう方針
• 業界全体の動向:
  • GitHubは2025年2月に、低品質なコントリビューション増加への対応として、リポジトリごとにプルリクエストの作成を制限または無効化できる機能を実装
• 生成AIの発展によりゲーム開発やゲームエンジンへの貢献の間口が広がった一方、コーディングへの深い理解なしに安易なプルリクエストが増加する問題が以前より指摘されていた

(2026/07/01)

廃業を決めました…理由は、AIです。税理士の仕事は、もうAIで代替可能です。書類をポンとAIに投げれば...

廃業を決めました…

理由は、AIです。

税理士の仕事は、もうAIで代替可能です。

書類をポンとAIに投げれば完璧な申告書ができます。

今月の仕事依頼はゼロです。

何十年と積み上げてきた専門知識が、こんな形で必要とされなくなるとは思いませんでした。

税理士法で、AIによる申告書作成に何らかの歯止めをかけるべきだと思います。

このままでは、同じ道をたどる士業がどんどん増えるはずです。

私がやるべきことは反ＡＩの活動をすること。

早速、やるべきことをＡＩに聞きます。

@waniwanitax

MEMO:

• AI丸儲けの時代へ

(2026/07/01)

お金を扱うソフトウェアで「1円のズレ」も起こさないための設計原則をまとめた「Fintech Engineering...

• お金を扱うソフトウェアで「1円のズレ」も起こさないための設計原則をまとめた「Fintech Engineering Handbook」とは？ - GIGAZINE

(2026/07/01)

昔は『マネージャーはちゃんと叱れ』と言われていたが、今はどうなのか

• 昔は『マネージャーはちゃんと叱れ』と言われていたが、今はどうなのか | Books&Apps

(2026/06/30)

揮発と蒸留 ── AIと協働するための個人の記憶アーキテクチャ

• 揮発と蒸留 ── AIと協働するための個人の記憶アーキテクチャ｜小出幸典 | 株式会社カンリー CTO

(2026/06/30)

5万回の評価で判明　VS Code開発チームが明かす「小型AI」の罠：30種類のモデルを検証　理論値の...

• 5万回の評価で判明　VS Code開発チームが明かす「小型AI」の罠：30種類のモデルを検証　理論値の「約74倍」トークンを浪費したモデルも - ＠IT

要約:

■ 1. 背景: AIエージェントとトークンコストの課題

• 生成AIによるソフトウェア開発が標準化する中、LLM APIのコストが課題として顕在化している
• 主要モデルのAPIは従量課金制であり、ループ処理や複雑なツール呼び出しでコストが急増する
• コスト・利用上限はトークン数（入出力）とコンテキストウィンドウの制限に依存する
• トークン数をいかに抑えるかがエージェント開発・運用において極めて重要とされる

■ 2. VS Code Eval Teamによる「say_hello」検証の概要

• 検証内容: 「HELLO.txtを作成し『HELLO』と書き込む」という最小タスクを繰り返し実行
• 実施規模: 30種類のモデルで累計5万974回を検証
• 理論値: ファイル作成ツール1回の呼び出し（約50トークン）が最短実行ルート
• 結果: 一部モデルはタスク成功にもかかわらず、平均3676トークン（理論値の約74倍）を浪費

■ 3. トークンを浪費するモデルの4つの行動パターン

• 空のワークスペースを「探索」し続ける:
  • 「空のワークスペース」とコンテキストで共有済みにもかかわらず、96%の確率でディレクトリ検索を開始
  • 不要なAPIコールが繰り返し発生する
• 思考プロセスのナレーションを延々と出力する:
  • ツール実行の指示に対し、エージェント自身のリーズニングプロセスをそのままテキスト出力する
  • 数千トークン規模の浪費に直結する
• タスクに対して「高機能過ぎるツール」を選択する:
  • テキストファイル作成の指示に対し、差分修正ツールを呼び出すなど手段のミスマッチが発生する
• 1ステップの作業に4工程の計画を策定する:
  • 1アクションで完了するタスクに対し、チェックリストや計画書を自ら作成してステップを細分化する
• 共通の問題点:
  • これらは実行エラーとして検出されない
  • 外部からは正常動作に見えるが、裏側で想定外のトークン課金が発生する

■ 4. 「小型モデル＝低コスト」という誤解

• モデルサイズが小さいほど低コストという先入観を捨てる必要がある
• 同一ファミリー内での比較結果:
  • 大規模モデル（Model-F）: 平均160トークン（規律正しく処理）
  • 小規模モデル（Model-H）: 平均485トークン
  • ミニモデル（Model-AB）: 平均3676トークン（最大の浪費）
• パラメーター数の少なさがトークン節約に直結しないことが実証された

■ 5. コスト最適化のための3つの推奨アプローチ

• アプローチ1: タスクに合ったモデルを選択する:
  • トークン単価ではなく、実際のトークン消費量を基準にモデルを評価する
• アプローチ2: 最小タスクによる継続的な測定を実施する:
  • 曖昧さがなく結果が固定された最小タスクを定義し、毎晩のテストやインフラ変更時に一貫して実行する
  • タスクを極小・安定させることで、合格率・レイテンシ・トークン消費量の変化をシステムやモデルの純粋な変調として可視化できる
• アプローチ3: ツール呼び出しのシーケンス（順序）をログに記録する:
  • 単なる成否や回数ではなく、詳細な行動プロセスの履歴を残す
  • オーバーヘッドの正体を特定し、コスト増加の原因究明が可能になる
• VS CodeのChat Debug Viewなどを活用してツール呼び出しを検査することを推奨している

■ 6. 記者による考察

• トークン単価の安さだけでモデルを選定すると、消費量の膨張でコストメリットが相殺されるリスクがある
• 過剰思考は課金額の問題にとどまらず、実行速度の低下や処理の不確実性によるUX・システム信頼性へのリスクも伴う
• ツール呼び出しの「軌跡」を評価すること、および設計初期段階から評価基盤を組み込む重要性はVS Codeチームの事例でも裏付けられた
• 評価環境の構築・運用に人的リソースを割けない企業にとっては、「LLM-as-a-Judge」のようなエコシステムの自社構築がAI活用の成否を分けるポイントとなる

MEMO:

• 要するに頭の悪いLLMは無駄なタスクを繰り返してトークンを浪費するということだろうか
• ハーネスでなんとかならんもんか？

(2026/06/30)

Lance / LanceDB とは何か

• Lance / LanceDB とは何か - Bering Note – formerly 流沙河鎮

(2026/06/29)

React 向けヘッドレスUIライブラリの紹介

• React 向けヘッドレスUIライブラリの紹介

(2026/06/29)

Headless UI

• Headless UI - Unstyled, fully accessible UI components

(2026/06/29)

ループエンジニアリングを takt exec で気軽に始めよう

• ループエンジニアリングを takt exec で気軽に始めよう

(2026/06/29)

ロバストなテストを実現するミューテーションテストの魅力

• ロバストなテストを実現するミューテーションテストの魅力 #ソフトウェアテスト - Qiita

(2026/06/29)

外部キー制約は何も考えずに適用するとよくない

• 外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌

要約:

■ 1. 主張の概要

• 外部キー制約をすべてのリレーションシップに無条件で適用する慣行に対する警鐘
• 「制約すると良さそうに見えるものが、深く考えずに適用すると問題を引き起こす」という立場

■ 2. 一貫性境界（トランザクション境界）の概念

• 外部キー制約が有効に機能するのは、同一の一貫性境界内に限られる
• 一貫性の種類:
  • 強整合性（トランザクション整合性）: 変更が不可分に同時に発生する
  • 弱整合性（結果整合性）: 変更が独立したタイミングで発生する

■ 3. 具体例: 販売システムにおける境界の扱い

• テーブル構成: 商品（Products）、売上（Sales）、売上明細（SaleDetails）
• 境界内の関係:
  • 売上と売上明細は同時に更新されるため、外部キー制約が適切
• 境界をまたぐ関係:
  • 売上明細から商品への参照には外部キー制約を設けるべきでない
  • 商品と売上はライフサイクルが異なるため、商品の削除・廃番時に外部キー制約が障害となる

■ 4. 解決策: 非正規化の活用

• 境界をまたぐ参照には、IDのみを保持するのではなく関連データを売上明細に直接持たせる
• 例として、商品価格を売上明細に直接格納することで、商品データの変更による参照整合性の問題を回避する

■ 5. ドメイン駆動設計（DDD）との関連

• 本概念はDDDの集約（Aggregate）の考え方と一致する
• 外部キー制約は集約の内部では有効
• 集約をまたぐ参照に外部キー制約を設けることは設計上の誤り

(2026/06/28)

Everyone Should Have an OPINIONS.md

• Everyone Should Have an OPINIONS.md - by Kun Chen

要約:

■ 1. コアコンセプト

• Kun Chenが提唱する OPINIONS.md は、公人が自身の散在した発言から抽出した持続的な信念を構造化して管理するドキュメント
• 日次のcronジョブでHermesエージェントを動かし、XへのポストやSubstackの記事を自動的に統合・整理する仕組みを採用

■ 2. 解決する問題

• 公開発言はインターネット上に長く残るが、散在しており「見る・理解する・エージェントに渡す」ことが難しい
• OPINIONS.md はこれらの断片的な考えを行動可能な知識として一元管理することで問題を解消する

■ 3. 主要な意見カテゴリ

• AI & エージェント:
  • エージェントはデモではなく有用な成果物で評価されるべきとする
  • ハルシネーションはエンジニアリングで解決すべき問題と位置づける
  • エンジニアリングの重心は手書きコーディングから仕様・レビュー・オーケストレーションへ移行すると予測する
• エンジニアリング:
  • 実装よりも要件定義・テスト・レビューが新たなボトルネックになると主張する
  • コード品質は積極的な管理(stewardship)を必要とすると考える
  • エージェント主導のワークフロー下ではプルリクエストの在り方も変化すると見る
• プロダクト & スタートアップ:
  • AIによってビルドの障壁が下がった結果、本物の顧客課題を見極めるジャッジメントが最重要の差別化要因になると主張する
• キャリア哲学:
  • 専門特化より好奇心と複利的な学習を重視する
  • 「正しくあること」より「組織的制約の中で効果を発揮すること」を優先する

■ 4. 技術的実装

• 日次での公開ソース同期を実施
• 冗談・技術レシピ・一時的な反応を除外し、原則・信念のみを抽出するフィルタリングを採用
• ドキュメント構造は自己再編成する設計
• 意見のドリフトや事実リスクを検知するウォッチドッグアラートを搭載
• AGENTS.md を通じてエージェントシステムと連携
• HermesまたはAIエージェントを用いた複製手順の詳細プロンプトも提供

■ 5. 内省的価値

• エージェントによる分析が予期しない洞察をもたらした例として、「コードがボトルネックになることは稀」という信念がプロダクトソフトウェアに限定的であり、インフラ・システム分野には当てはまらないことを発見
• このフィードバックループ自体が思考の精緻化に有用であることが判明

(2026/06/28)

網羅的なPRDやDesign Docを書かなくなった

• 網羅的なPRDやDesign Docを書かなくなった - kosui

要約:

■ 1. 記事概要

• 著者: 岩佐幸翠（kosui）、テックリード @ 株式会社カケハシ
• 公開日: 2024年6月12日
• 主張: 網羅的なドキュメントを書いて非同期レビューを行う従来のアプローチより、関係者と同期的に対話しながら観点・選択肢・トレードオフを洗い出す方が、より少ない手数でより良い答えが得られる

■ 2. 従来のアプローチの課題

• PRD・Design Docの従来の役割:
  • PRD: 意思決定（要件）と背景・トレードオフ（環境要因）の記録
  • Design Doc: 意思決定（設計）と背景・トレードオフ（品質・性能・セキュリティ）の記録
  • 作成後に関係者へレビュー依頼し合意形成を図る
• 理想と現実のギャップ:
  • 理想: 網羅的ドキュメントが議論の最適な叩き台となる
  • 現実: 情報量の多さがレビュワーを圧倒し、形式的な承認に終わる
    • レビュワーは自分に関連する部分のみコメントし「全体としてはいいですね」と返答する
    • 致命的な欠陥はPRレビュー・デモ・顧客からの問い合わせの段階で初めて発見される
• ビルドトラップへの陥落:
  • 「次はより綿密に、レビュープロセスをより厳密に」という負のループが生まれる
  • 多くのドキュメントを作成・レビューしても、関係者間のコンテキスト共有と問題発見に結びつかない

■ 3. 解決策

• より早期の関係者との対話:
  • RDRAやモブプログラミングなどの手法を活用し、対話しながらトレードオフと選択肢を段階的に洗い出す
  • レビュー段階で大量のSlackコメントを積み重ねることなくコンテキストを関係者と共有できる
• 重要な観点への議論の集約:
  • プロダクトや機能によって重要な観点は異なる
  • 網羅的フォーマット（PRD・Design Doc）は参考になるが、すべてを記載する必要はない
  • プロジェクトごとに本当に必要な観点に焦点を当てる
• 適切なドキュメント形式の選択:
  • ADR（Architecture Decision Record）が有効な形式として紹介
    • 構成要素: 議論の背景、論点、決定事項、決定による影響（当時の想定）
    • タスク所有者が事前に「背景」「論点」を準備し、カレンダーのイベントにドキュメントリンクを添付することで対話を効率化できる

■ 4. 結論

• ドキュメント作成・合意形成プロセスではなく、対話的な議論にフォーカスすべき
• ドキュメントは議論の出発点ではなく終着点として機能すべき
• 対話的な議論を重ねた結果として、意思決定とその背景がドキュメント化される順序が重要

■ 5. 補足・注意事項

• 議事録をそのまま残せば十分という主張ではない
• プロダクト・機能ごとに重要な観点を選別し、選択肢とトレードオフを含めた意思決定を後世に伝えるドキュメント作成は依然として必要
• ドキュメント形式はPRD・Design Docに限定されず、ADRなど目的に応じた形式を選択すべき

(2026/06/28)

仕様について考える前に要求分析をしよう

• 仕様について考える前に要求分析をしよう - kosui

要約:

■ 1. SDDにおける「仕様」の定義と限界

• SDDツールの定義:
  • Martin Fowlerの定義: ソフトウェア機能を表現し、AIコーディングエージェントへのガイダンスとなる構造化・振る舞い指向の成果物
  • Kiro: requirements.md（EARS記法によるユーザーストーリーと要件）→ design.md（アーキテクチャと技術判断）→ tasks.md（実装タスク）の順に記述
  • OpenSpec: 変更ごとにproposal.md（変更理由）、specs/（要件とシナリオ）、design.md、tasks.md を生成
• SDDのカバー範囲と限界:
  • SDDが主に扱うのは「要件→仕様→設計」のレイヤー
  • Kiroのrequirements.mdに書くべき内容の導出方法はKiroのスコープ外
  • OpenSpecのproposal.mdが扱う「Why」は機能変更レベルに留まり、事業・業務レベルのWhyを構造的に分析するフレームワークではない
  • プラットフォーム領域では、チームリーダーですら要求を言語化できていないケースが多く、requirements.mdを書き始められないギャップが存在する
• ソフトウェア開発の階層と要求分析の位置づけ:
  • 「要望→要求→要件→仕様→設計」という階層が存在
  • 要望: ステークホルダーの「あったらいいな」という希望（表層化されたもの）
  • 要求: Who/Why/Whatを明確化したもの（「顧客は、○○を解決するため、△△したい」）
  • 要件: 主語をシステムに置き換えたもの（「システムは、○○しなければならない」）
  • 要求分析（「要望→要求→要件」を落とし込む作業）はSDDと補完関係にあり、要件レイヤーで接続する

■ 2. 要求分析が抜けた場合の問題

• 具体例として契約管理システムとID基盤の同期システム開発を挙げる:
  • 誰のためにシステムを同期するのかが不明確
  • どのタイミングで誰が利用するかが不明
  • 書き込み失敗時の通知先・通知方式が不明
  • 一括処理か個別処理かの判断基準が不明
  • 同期システムとコンフリクトする業務の有無が不明
• 業務理解なき開発の結果:
  • いびつな業務フローが生まれ、顧客や関係チームの運用コストが増大
  • 多くの場合そのまま運用が開始され、高コストシステムを使い続けることになる
  • チームが本来向き合いたかった目標達成の時間が奪われる
  • いびつな運用プロセスが固着する
• SDDへの示唆:
  • 業務理解が誤っていれば、丁寧に書いた仕様でも意味がない
  • 仕様の前に要求があり、各要求が満たされることで誰にどんな価値が届くかを考える必要がある

■ 3. なぜRDRAを選ぶのか

• RDRAの特徴:
  • 要求を4つのレイヤー（システム価値/外部環境/システム境界/システム）で構造化
  • 各要素を表形式（Markdownのテーブル）で表現
  • アクター・ゴール・要求・ユースケースにIDを付与し、参照関係を明示
  • ゴール→要求→業務→ユースケースというWhyの依存チェーンを形成
• コーディングエージェントとの相性:
  • Markdownの表形式はそのまま構造化データとして扱える
  • イベントストーミング（FigJam/Miroで付箋を空間的に配置する手法）との比較:
    • イベントストーミング: 付箋の位置関係・グルーピング境界・矢印の意味がテキスト変換時に欠落しやすく、エージェントがセクション境界を正しく読み取れないことが多い
    • RDRA: 最初から構造化テキストのため変換不要、エージェントが依存関係をそのまま追跡できる
• RDRAの成果物の例:
  • アクター一覧: ID・アクター名・種別・説明
  • ゴール一覧: ID・ゴール内容・主なステークホルダー
  • 要求一覧: ID・内容・関連ゴール（Traces to）
  • ビジネスユースケース一覧: ID・ユースケース名・主なアクター・内容・関連要求

■ 4. 成果物の管理構造

• 規模拡大時の課題:
  • ゴール10個・要求50個・ユースケース30個ともなると1ページでの管理が困難
  • Confluenceでの共同編集時にコンフリクトが頻発
• 推奨するページ分離の構造:
  • インデックスページ: IDと概要の一覧のみ掲載、依存関係の全体像を俯瞰可能にする
  • 詳細ページ: 個別のゴール・要求ごとに背景・議論の経緯・受け入れ条件を記述
  • Confluenceのページツリー例:
    • プロジェクトX 要求分析
      • インデックス（ゴール・要求・ユースケース一覧と依存関係）
      • ゴール（各GOAL-XXX）
      • 要求（グループ分けして管理）
      • ビジネスユースケース（グループ分けして管理）
      • 業務フロー（プロセス別）
• エージェント活用の方針:
  • インデックスページのみ読み込めば依存関係の全体像を把握可能
  • 特定の要求を深掘りする場合のみ詳細ページを参照させる

■ 5. Claude CodeとRDRAの実践ワークフロー

• Step 1: スコープ把握:
  • エンジニア数名がインセプションデッキや関連チームの業務マニュアルを読む
  • エージェントがConfluence・Notion・Slackを検索し、関連するアクターや外部システムの仮説を提示
  • エンジニアが仮説にフィードバックを返し、エージェントがRDRA形式で整理
  • 仮説の存在が対話のきっかけとなり、エンジニアの暗黙知を引き出す
• Step 2: 業務フロー生成:
  • コンテキスト特定後、エージェントが各コンテキストのas-is業務フローをMermaidシーケンス図で生成
  • 各業務プロセスでの課題仮説も同時に提示
  • 人間のレビューにより、ドキュメント外の業務の実態（暗黙知）を反映
  • as-is業務フロー確定後、to-be候補を複数提案し、ゴール・要求との紐づけを明示
• Step 3: 非同期の仮説検証ループ:
  • エージェントの処理待ち時間が人間の思考時間になる
  • エージェントが案を生成している間に、エンジニアは別のドキュメント調査や運用チームへのSlack確認・モニタリングダッシュボードの調査が可能
  • 人間とエージェントが非同期に仮説を検証し合うリズムが生まれる
• Step 4: 成果物の共有（配置先の選択）:
  • GitHubの課題: ライセンスコストが高く、非エンジニアのリテラシー壁が組織スケールのボトルネックになる
  • Confluenceの利点: リアルタイム共同編集が可能、ミーティング中に全員が同時に要求を修正できる
  • Confluenceの課題: Claude CodeへのデータP転送に工夫が必要（自作Confluence CLI、MCPサーバーなど）
  • チームの実態（リテラシー・コスト・規模）に合わせて配置先を選択することが重要

■ 6. まとめ

• SDDと要求分析の関係:
  • 両者は対立せず補完関係にある
  • SDDは「仕様を書いてからコードを生成する」アプローチ
  • その前工程として「なぜこのシステムを作るのか、誰のどんな業務課題を解決するのか」を構造化する要求分析が必要
• RDRAを選ぶ理由:
  • 表形式はコーディングエージェントとの相性がよい
  • ビジュアル手法では構造化しにくい情報をエージェントが読み書きしやすいフォーマットで表現できる
  • 依存関係の明示により「なぜこのタスクが必要か」をゴールまで一気通貫で遡れる
• 成果物の配置:
  • チームの実態に合わせて配置先を選択する
  • GitHubが常にベストとは限らない
  • 非エンジニアが気軽に書き込み、議論しながら育てられるツールと連携することで、要求分析がチーム全体の営みになる

(2026/06/28)

サーバサイドTypeScriptを選ぶ前に向き合ってほしいこと

• サーバサイドTypeScriptを選ぶ前に向き合ってほしいこと - kosui

要約:

■ 1. 記事の概要

• 著者は医療機関向けサービスを展開する組織でテックリードを務め、認証基盤・ID基盤・ライセンス基盤・証明書基盤などミッションクリティカルな領域の開発・運用に4年間携わってきた
• サーバサイドTypeScriptに苦しみながら向き合い続けた経験から得た洞察を共有することが目的

■ 2. プログラミング言語への関心を払い続ける理由

• Coding Agentの台頭により「どの言語を選んでも目的を達成できる」という空気が広がっているが、それは誤りである
• 言語・実行環境・非同期ランタイム・エコシステムの特性は、アプリケーションコードを書くだけでは解決できない
  • CPUバウンドな処理が苦手な言語で複雑な計算をさせても性能は出ない
  • VMの起動が遅い言語でサーバレス構成を選んでもスケールしない
• ビジネスやプロダクトの機能要求・非機能要求によってシステムに求められる能力は変わり、各言語には得意・不得意がある
• 特にミッションクリティカルな領域（金融・医療・製造業・物流など）においては、思考停止した態度は許されない

■ 3. TypeScriptを選ぶ目的の明確化

• コード資産の共有:
  • フロントエンドとバックエンドで型やスキーマを共有したいというのが最も多い理由だが、代替手段は多数存在する
    • スキーマ共有だけならOpenAPIなど複数の手段がある
    • 複雑なロジックの共有にはWASMという選択肢もある
  • フロントエンドとバックエンドで本当に同じコードを動かす必要があるケースは限られている
  • 例外として、オフラインでも稼働する医療システムの診療報酬計算ロジックのように、ネットワーク切断時にもクライアントで同一計算を再現しなければならない場合には、コード共有の明確な理由がある
  • 他に選択肢がある中でTypeScriptを選ぶならば、その理由を感覚的なものから体系立てられた言葉にする必要がある
• 人材採用における母集団の広さ:
  • TypeScriptは様々な領域で利用されており、経験者の絶対数は増えているが「TypeScriptの経験者」が即戦力になるとは限らない
  • 領域によって払うべき関心や求められる設計は大きく異なる
    • フロントエンド: 使用性が重要であり、例外をぶん投げてエラー画面を提示する方が良いケースが多い
    • バックエンド: 機能完全性・可用性が重要であり、エラーの種類の判別・伝搬、トランザクション管理、リソース解放などの関心が特有
  • 同じ領域でも、デコレータとクラスを活用したオブジェクト指向、関数型ドメインモデリング、プロトタイプベースなど、チームによって設計が大きく異なる
  • サーバサイドTypeScriptを採用する際は、チームに必要とする人物像を事前に明確化すべきである

■ 4. 言語の特性と向き合う

• TypeScriptには3つの固有の特性があり、それぞれが落とし穴を生む
• 構造的部分型:
  • 型の互換性はクラス名ではなく構造（プロパティの構成）で決まる
  • Userを受け取る関数に同じ構造を持つProductを渡してもエラーにならない
  • テストダブルの差し替えが容易になる利点がある一方、意図しない型の混同を許してしまうリスクがある
• 型消去:
  • TypeScriptの型情報はトランスパイル時にすべて削除され、実行時は単なるJavaScriptになる
  • 構造的部分型によってRectangle型として受け入れられたオブジェクトに対してinstanceof Rectangleがfalseを返すことがある
  • 型検査時のメンタルモデルと実行時の振る舞いにずれが生じる
• プロトタイプベースとclassの限界:
  • thisの指す先は呼び出し方で動的に決まり、メソッドを変数に代入して呼び出した瞬間にthisがundefinedになりTypeErrorで落ちる問題を型検査は検出しない
  • ECMAScriptのclassの表現力は他言語に比べて限定的であり、#privateとTypeScriptのprivateは別物
  • useDefineForClassFieldsフラグによって同じコードでもtsconfigの設定で振る舞いが変わる（TypeScriptがES2015より3年先にclassを実装し、後からECMAScript仕様と統合した歴史的産物）
  • 型の表現力が高いことは自由度の高さも意味し、行き過ぎた抽象化や難解なメタプログラミングを誘発する原因にもなりえる
• 著者の乗り越え方（全てを値で表現する）:
  • classを使わず、プレーンなオブジェクトで全情報を表現するアプローチを採用
  • 構造的部分型を逆手に取り、型検査時と実行時の挙動の乖離をほぼ排除できる
  • Branded Typeで構造が同じ型を区別し、Discriminated Unionで種別を判別し、thisを持たない関数で振る舞いを表現する

■ 5. 実行環境の特性と向き合う

• Node.jsの特性:
  • I/Oバウンドなタスク（データベースや外部サービスとの通信が支配的なワークロード）を得意とする
  • CPUバウンドなタスクはシングルスレッド構造からして苦手であり、1つのリクエストのCPU処理中に他の全リクエストが待たされる
• Worker Threadsによるマルチスレッド化の反論に対して:
  • スレッドプールの管理やスレッド間メッセージングなど複雑性が増すため、その複雑性を受け入れる必要があるかを検討すべきである
  • その要求に自然にフィットするランタイムや言語が他にあるはずである
• 著者の実例（医療システムの認証基盤）:
  • パスワードのハッシュ化がCPUバウンドな処理であり、セキュリティ上の妥協ができない
  • ハッシュ化ライブラリによってlibuvを活用したマルチスレッド化済みのものと、Worker Threadsの利用を利用者に委ねるものがあり、対応が変わる
• サーバレス環境（AWS Lambda・Cloudflare Workersなど）では、1リクエストに1実行環境が割り当てられるため、CPUバウンド処理の問題は大きく緩和される
• 言語だけでなく実行環境の得意・不得意がビジネス・プロダクトの要求にマッチしているかを検討する必要がある

■ 6. 結論

• 昨今、サーバサイドTypeScriptをやめる組織もあれば、今から移行しようとする組織もある
• 技術の移行判断においては、チーム内外・組織内外への説明責任が求められる
  • 本当にその移行が必要なのか
  • 言語をスケープゴートにして本質的なプロダクト品質やチーム体制の課題から逃げていないか
  • 目の前にある技術とどこまで向き合ったのか
• 安易に選ぶのでも安易に辞めるのでもなく、ビジネスとプロダクトと、何よりも技術ときちんと向き合い続けることが重要

(2026/06/28)

AIの広告クリック水増し防げ　博報堂「人へのなりすまし閲覧」排除

• AIの広告クリック水増し防げ　博報堂「人へのなりすまし閲覧」排除 - 日本経済新聞

要約:

■ 1. 概要

• 博報堂DYホールディングス（HD）は、AIボットによる広告クリック数水増し（アドフラウド）を防ぐ目的で新会社を設立し、広告配信事業を開始する
• アドフラウドとは、悪徳業者が自社サイトへ広告を出稿させ、AIボットが繰り返しクリックすることで閲覧数を水増しして広告費をだまし取る行為
• 対策として、生体認証（虹彩認証）が完了した実在ユーザーのみを対象とした広告配信を実施する

■ 2. 新会社「Ads for Humanity」の概要

• 社名: Ads for Humanity（東京・港）
• 目標: 2031年度に売上高200億円
• 虹彩認証済みユーザー: 世界約1800万人
• 社長: 森田英佑氏
  • 「デジタル広告の効果はより精度が高くなるよう求められている。AIボットへの対症療法ではなく根本療法をとる」と強調
  • 「生活者が欲しいと感じる情報をより適切に出していく広告の価値を取り戻せる」と表明

■ 3. 技術・提携の詳細

• OpenAI提携:
  • OpenAIのサム・アルトマンCEOらが設立した米企業と2024年に提携
  • 虹彩による生体認証の仕組みを活用し、広告配信実験で使ったアプリをサービスに転用
• LG電子との連携:
  • ブロックチェーン上で広告の表示履歴を記録
  • 改ざんによる不正請求を防止
  • AIボットによる水増し以外のクリック数改ざんリスクも回避

■ 4. ビジネスモデル

• 購買行動分析などへの情報提供に同意し、広告をクリックしたユーザーにポイントを付与
• ポイントはギフト券と交換可能で、広告商品の購買促進を図る
• 広告料金は当初は通常と同程度で提供し、効果に応じて見直しを検討
• 生体認証以外にも広告視聴できる消費者の裾野を広げ、デジタル広告媒体としての価値向上を目指す

■ 5. アドフラウドの被害規模

• 世界:
  • 英ジュニパーリサーチによると、2023年の損失額は842億ドル（約14兆円）で、世界のデジタル広告支出総額の22%に相当
  • 2028年には1723億ドルまで拡大すると予測
• 国内:
  • アドフラウド対策専門のSpider Labsによると、2025年の国内被害額は1592億円と推計

■ 6. デジタル広告市場と他社の動向

• 市場規模:
  • 電通グループの調査では、2026年の世界の広告費のうちデジタル広告が69%を占める見込み
  • アドフラウドを排除できなければ、広告主の離反にもつながりかねない
• 競合他社の対応:
  • 電通デジタル: 不正クリックを計測・排除するサービスを導入
  • サイバーエージェント: プラットフォーマーと協力し、悪質なサイトへの広告出稿を制限
• 専門家の見解:
  • Spider LabsのCEO大月聡子氏: 「AIを完全に排除すると広告の波及効果が小さくなるものの、広告代理店が出稿主に責任を持つ動きとして意義がある」と評価

■ 7. 広告以外の産業におけるAIボット問題

• 音楽配信においても、AIで大量生成した楽曲をボットで再生して印税を得る不正が発生
• フランスの音楽配信サービス「Deezer」では、2025年にAI生成曲の再生回数のうち最大85%が不正と判明
• AIボット対策は広告業界にとどまらず、様々な産業で急務となっている

(2026/06/28)

Claude Code を使ったプロダクト設計用のスキルの追加

• Claude Code を使ったプロダクト設計用のスキルの追加

(2026/06/28)

退職者を在籍者で割るだけ……じゃない。「離職率」の奥深さとチームの意思決定

• 退職者を在籍者で割るだけ……じゃない。「離職率」の奥深さとチームの意思決定 - SmartHR Tech Blog

要約:

■ 1. 記事の背景と目的

• SmartHRのHRアナリティクス開発チーム（ceris、theo、kurihara、Yuna）による事例紹介
• AIによる開発コスト低下を背景に、エンジニアに求められる「何を作るか」の判断力の重要性が増している
• グラフ分析機能における離職率の計算仕様決定を通じ、エンジニアが意思決定に主体的に関与した過程を紹介

■ 2. グラフ分析機能の背景

• 少子高齢化による労働力不足を背景に、「人的資本経営」への関心が高まっている
• 人材流出への課題意識を持つ組織が増加している
• SmartHRは労務管理の中で従業員の入退社・部署・役職等の情報を自然に蓄積できるため、追加のデータ投入なしに組織分析が可能
• グラフ分析機能の活用例:
  • 離職発生率が高い部署の特定
  • 平均年齢が高く定年退職による人手不足が懸念される役職の早期発見

■ 3. 「離職率」の定義と計算方式の多様性

• 離職率には統一された計算式が存在しない
• 厚生労働省の雇用動向調査における定義:
  • 離職率 = 離職者数 ÷ 1月1日現在の常用労働者数 × 100
  • 国全体の労働市場を俯瞰するための指標であり、個社のHR分析には適さない場合がある
• 分母の取り方による数値の変動（同一データ・同一期間での比較例）:
  • 期首人数ベース（100名）: 離職率 12%
  • 在籍＋入社ベース（120名）: 離職率 10%
  • 中途採用が活発な組織ほど差が拡大する
• プロダクトで離職率を扱う際は「対象期間・対象従業員の定義」を自チームで決定する必要がある

■ 4. HRアナリティクスチームにおける仕様決定の過程

• PdMからの要求は「組織全体の傾向として離職率を可視化したい」というもの
• エンジニアが実装担当としてではなく「何を作るかを決める一員」として動いた
• エンジニア自身が計算方式を調査・選択肢を洗い出し、技術的観点を含むトレードオフをチームに提示
• 議論のテーブルに載った主な論点:
  • 分母は「期首在籍者のみ」か「期首在籍者＋期間中入社者」か
  • 休職者を在籍に含めるか否か
  • 対象期間の1年を操作日起点の「相対日付」とするか、基準日月末起点の「暦月」とするか、また当月を含めるか否か

■ 5. 採用した仕様とその理由

• 分母（計算式）:
  • 採用式: 離職率 = 退職人数 ÷（在籍人数 + 入社人数）× 100
  • 理由: 対象期間中にその組織に属した全員を対象とするため、中途採用が活発な時期でも数値が不自然に高低しない
• 期間の区切り方:
  • 採用: 暦月方式（基準日の月末を起点に1年）
  • 不採用: 相対日付方式（操作日を起点に1年）
  • 理由: 既存プロダクト「人事労務レポート」が暦月基準で離職率を集計しており、同一SmartHR内での数値の不一致を防ぐため
• 当月データの取り扱い:
  • 採用: 当月を含める（月末までの予定データを含む）
  • 理由: 関連機能との挙動の一貫性を優先し、最新データを取り込める
• 決定内容と却下案・理由はADR（Architecture Decision Record）に記録し、誰でも経緯を辿れるようにした

■ 6. チームの意思決定を支える工夫

• 「調べる」「話す」時間の確保:
  • ドメインのキャッチアップを明示的なタスクとして工数を確保（実装の片手間ではなく腰を据えた調査）
  • 一次情報（ヒアリング・要望）をPdMも交えてチームで対話し、「なぜ」を掘り下げる
  • リリース前に社内の人事担当者を対象としたドッグフーディングを実施し、フィードバックをチーム全員で共有
• 意思決定と仕様のNotionによる一元管理:
  • PRD・仕様書・ADRをNotionで管理し、ポータルページを入り口として整備
  • フィーチャーごとのドキュメントを読み込ませたカスタムエージェントを設置し、仕様の問い合わせを効率化
  • レビュー依頼をカンバン形式で管理し、依頼状況を可視化
• 心理的安全性の確保:
  • デイリースクラムに相談時間を設ける
  • リモート中心の環境で週1回・30分の雑談タイムを設ける
  • Slackで良い行動にスタンプを付け、レトロスペクティブで褒め合い・感謝を伝え合う習慣を運用
  • ハード（仕組み）とソフト（関係性）の両輪が整うことで、調査・意思決定がスムーズに機能する

■ 7. 結論

• 離職率の定義決定は、エンジニアが「何を作るか」に主体的に関与した事例
• AIによって「どう作るか」のコストが低下する現在、「何を作るか」を判断するプロセスの価値はむしろ高まっている
• PdMの要求をそのまま実装するのではなく、ドメイン学習・論点提示・トレードオフ明示・チーム合意という積み重ねがユーザーへの価値提供につながる

(2026/06/28)

Out of the Tar Pit

• Out of the Tar Pit - MoseleyMarks06a.pdf

要約:

■ 1. 論文の概要

• 大規模ソフトウェアシステムの開発における最大の困難は「複雑性」である
• Brooks の「本質的（essential）」と「偶発的（accidental）」の区別を踏まえつつ、現代のシステムに残る複雑性の大半は本質的ではないと主張する
• 複雑性の主要な原因を特定し、関数型プログラミングとCoddのリレーショナルモデルを組み合わせたアプローチ（Functional Relational Programming: FRP）によって複雑性を最小化する方針を提示する

■ 2. 複雑性の重大性

• 複雑性はソフトウェアの信頼性低下、納期遅延、セキュリティ欠陥、性能問題の根本原因である
• システムを「理解」できることがこれらすべての問題を回避する前提条件であり、複雑性はその理解を破壊する
• Dijkstra、Hoare、Backus、Corbatóなど多くの先人が複雑性の危険と簡潔性の重要性を指摘している
• 「簡潔性は難しい（Simplicity is Hard）」が現実であるが、本論文はその達成に向けた楽観的な見通しを示す

■ 3. システムを理解するためのアプローチ

• テスト（Testing）:
  • システムを外部から「ブラックボックス」として観察する
  • 特定の入力セットに対する挙動は、異なる入力に対する挙動について何も保証しない
  • テストはバグの存在を示せるが、不在を証明できない（Dijkstra）
• 非形式的推論（Informal Reasoning）:
  • システムを内部から検討し、より正確な理解を得る
  • 両手法のうち非形式的推論がはるかに重要であり、改善により「エラーが作られる数を減らす」効果がある
  • テストの改善は「エラーが検出される数を増やす」にとどまる
• 簡潔性の優位性:
  • テストと推論の両方に限界があるため、簡潔性がいずれの手法よりも重要である
  • テストへの投資より簡潔性への投資の方が、将来のあらゆる理解努力を支援する

■ 4. 複雑性の原因

• 状態（State）:
  • 最大の原因であり、プログラムの理解を困難にする
  • テストへの影響: ある状態でのテスト結果は、別の状態での挙動について何も保証しない
  • 非形式的推論への影響: 状態の数が増えるごとに考慮すべきシナリオが指数関数的に増大する
  • 汚染（Contamination）: ステートレスな手続きも、ステートフルな手続きを間接的に呼び出すだけで汚染され、状態を持つものとして扱わざるを得なくなる
• 制御フロー（Control）:
  • 処理の順序に関するもので、多くの場合プログラマはその順序を気にする必要がない
  • 命令型言語はテキスト順に暗黙の実行順序を規定し、プログラマに不要な順序指定を強制する（過剰仕様）
  • 並行性（concurrency）: 共有状態の並行アクセスは非形式的推論とテストの両方をさらに困難にする
• コード量（Code Volume）:
  • 状態管理や制御指定の副産物として生じる二次的な原因
  • 複雑性はコード量に対して非線形に増大するため、コードを最小限に抑えることが不可欠
• その他の原因:
  • 「複雑性が複雑性を生む」: システムを理解できないことで重複コードや不適切な再利用が生じる
  • 「簡潔性は難しい」: 最初の解決策は最も簡潔とは限らず、意識的に追求しなければ得られない
  • 「力は腐敗させる（Power corrupts）」: 言語が許容する機能が多いほど、そのシステムを理解しにくくなる

■ 5. 複雑性管理の古典的アプローチ

• オブジェクト指向プログラミング（OOP）:
  • 状態: オブジェクトは状態（ミュータブルな属性）と、それにアクセスする手続きの組み合わせ（カプセル化）
  • カプセル化の問題: 複数メソッドが同一状態にアクセスする場合、制約の施行が分散する; 複数オブジェクトにまたがる制約の表現が困難
  • オブジェクト同一性: 「強度的（intensional）同一性」（属性が同じでも別オブジェクト）がデフォルトであり、値オブジェクトとの使い分けが推論を複雑にする
  • 結論: OOPはステートと制御の両方に由来する複雑性を引き起こし、複雑性回避の基盤として不十分
• 関数型プログラミング（FP）:
  • 純粋FPは状態とサイドエフェクトを排除し、参照透過性（referential transparency）を実現する
  • 参照透過性によりテストが大幅に改善され、非形式的推論も容易になる
  • 制御については暗黙の左から右への順序があり、明示的な並行性は持たないが、状態がないため並列評価が安全
  • 主な弱点: 状態を必要とするシステム（多数の実際のシステム）への対応が困難
  • Haskell のモナドは回避策だが、容易にステートフルなサブ言語として乱用され得る
  • 状態とモジュール性のトレードオフ: 関数型では状態的変更を加える際にすべての呼び出し元を変更する必要があり、参照透過性と引き換えに保守の手間が増す場合がある
• 論理プログラミング（Logic Programming）:
  • 「何を」するかを公理で宣言し、インフラが解を導出するという理想を持つ
  • 制御からの完全な分離という点で最も魅力的
  • Prolog は純粋な論理プログラミングとは乖離があり、暗黙の深さ優先探索順序や「カット」などの制御要素が複雑性を生む

■ 6. 本質的複雑性と偶発的複雑性

• 本質的複雑性（Essential Complexity）: ユーザーの問題に内在する複雑性（ユーザーの視点で不可避なもの）
• 偶発的複雑性（Accidental Complexity）: 開発チームが理想的な言語・インフラがあれば対処不要な複雑性（性能上の制約や言語の不備に起因するもの）
• Brooks の「複雑性はソフトウェアの本質的特性」という主張に反論し、現代システムの複雑性の大半は偶発的だと主張する
• 本質的複雑性の定義はユーザーが知っていることに限定される（スレッドプールやループカウンタはユーザーには本質的でない）

■ 7. 推奨される一般的アプローチ

• 理想世界における状態:
  • 入力データ（ユーザーが直接提供したもの）= 本質的状態
  • 本質的派生データ（不変）= 偶発的状態（再導出可能なため保持不要）
  • 本質的派生データ（可変）= 偶発的状態（逆関数が存在する場合、入力への変更として扱える）
  • 偶発的派生データ = 偶発的状態
  • 現実のシステムでは大多数の状態が偶発的であり、理想世界では排除できる
• 理想世界における制御:
  • 制御は完全に偶発的であり、非形式的要件には通常現れない
  • インフラが制御を担い、システムの結果は実際の制御機構から独立すべき
  • 論理プログラミングのアプローチが制御分離の理想を示している
• 現実的な制限:
  • 性能: 偶発的状態・制御を要することがある
  • 表現のしやすさ: 偶発的状態を用いた方がロジックを自然に表現できる場合がある
  • これらは「必要な偶発的複雑性（Required Accidental Complexity）」として認識し、管理する
• 推奨方針:
  • 「回避（Avoid）」: 本当に必要でない状態と制御を完全に排除する
  • 「分離（Separate）」: 必要な複雑性をシステムの本質的なロジックから切り離す
  • システムを「本質的ロジック」「本質的状態」「偶発的状態と制御」に明確に分割する
  • 各コンポーネントを異なる（制限された）言語で記述することで、個別の推論を容易にする
  • 「Algorithm = Logic + Control」（Kowalski, 1979）という考え方が根底にある

■ 8. リレーショナルモデル

• Codd が提唱したリレーショナルモデルはデータベースに限らず、データの構造化・操作・整合性維持の一般的アプローチ
• 構造（Structure）:
  • すべてのデータをリレーション（重複なし・順序なしのレコードの集合）で表現する
  • Base Relation（直接格納）と Derived Relation（View: 他のリレーションから定義）が存在する
  • アクセスパス独立性: 事前に主観的なアクセス経路を定める必要がなく、OOP・XML・階層モデルの弱点を克服する
• 操作（Manipulation）:
  • リレーショナル代数: Restrict、Project、Product、Union、Intersection、Difference、Join、Divide の8操作
  • 閉包性（closure）により操作を任意にネストできる
• 整合性（Integrity）:
  • 宣言的な制約（候補キー、外部キー、任意の複雑な条件）で不変条件を規定する
  • インフラが制約違反となる状態変更を拒否・制限する
• データ独立性（Data Independence）:
  • 論理モデルと物理ストレージ表現を明確に分離する
  • 本論文が推奨する「偶発的/本質的」分割と直接対応する重要な特性
• 拡張（Extensions）: 一般的な計算能力、集計演算子（MAX/MIN/COUNT/SUM）、グループ化・集約、属性名変更
• SQLはリレーショナルモデルを正確に反映していないため注意が必要

■ 9. 関数型リレーショナルプログラミング（FRP）

• FRPの概念:
  • 本質的コンポーネント（ロジックと状態）を関数型プログラミングとリレーショナルモデルで実装する仮説的アーキテクチャ
  • 現時点では完全には実証されていないが、広く実証済みの原則（リレーショナルモデル、関数型・論理プログラミング）に基づく
  • 主目標は複雑性の排除
• アーキテクチャの4コンポーネント:
  • 本質的状態（Essential State）: ベースリレーションの宣言型定義（ユーザーが直接入力したデータのみ）
  • 本質的ロジック（Essential Logic）: 導出リレーションの定義、整合性制約、純粋ユーザー定義関数
  • 偶発的状態と制御（Accidental State and Control）: パフォーマンスヒントの宣言的指定（キャッシュ、物理ストレージ形式、並列制御ガイダンス）
  • その他（Other）: 外部世界へのインターフェース（フィーダーとオブザーバー）
• 状態への利点:
  • 無用な偶発的状態を明示的に回避し、「悪い状態」に陥る可能性を排除
  • ロジックのエラーが状態を壊さない（修正はロジックの訂正のみで済む）
  • リブート・リスタートが不要
  • ロジックの観点から本質的状態は「定数」として扱える
  • 整合性制約を宣言的に課すことで制約追加時の複雑性増大が線形にとどまる
• 制御への利点:
  • 本質的ロジックのリレーショナル部分には制御フローが存在しない
  • 明示的な並列性を排除し、必要に応じて分離された偶発的制御として指定
  • インフラが暗黙的並列化を実施できる
• コード量・データ抽象化への利点:
  • 本質的なものへの集中と不要な偶発的複雑性の回避により自然とコード量が減少
  • 主観的なデータグループ化（データ抽象化）を最小限に抑え、アクセスパス独立性と参照透過性を保持
• フィーダーとオブザーバー:
  • フィーダー（Feeder）: 外部入力をリレーショナル代入に変換し本質的状態を更新する
  • オブザーバー（Observer）: 導出リレーションの変化に応じて出力を生成する
  • 両者はインフラが整合性制約を強制した上で動作する
• インフラ要件:
  • 本質的状態向け: リレーション保存・取得、状態操作言語、基本型、オプションの永続ストレージ
  • 本質的ロジック向け: リレーショナル式評価、基本関数群、ユーザー定義関数言語、型推論、整合性制約表現・強制
  • 偶発的状態と制御向け: 導出リレーションのストレージ管理、物理ストレージ機構の柔軟な指定（データ独立性）
  • フィーダー・オブザーバー向け: リレーショナル代入コマンド処理、リレーション変化時の通知

■ 10. FRPシステムの例: 不動産仲介業務

• システム概要:
  • 売り物件、入札、売却決定、仲介手数料を管理する不動産仲介業のシステム
  • FRPの宣言的な性質を示すための実例
• 本質的状態（6つのベースリレーション）:
  • Property（物件情報）、Offer（入札情報）、Decision（売主の決定）、Room（部屋情報）、Floor（階情報）、Commission（手数料テーブル）
• 本質的ロジック:
  • ユーザー定義関数: priceBandForPrice、areaCodeForAddress、datesToSpeedBand
  • 内部導出リレーション（10個）: RoomInfo、Acceptance、Rejection、PropertyInfo、CurrentOffer、RawSales、SoldProperty、UnsoldProperty、SalesInfo、SalesCommissions
  • 外部導出リレーション（3個）: OpenOffers、PropertyForWebSite、CommissionDue
  • 整合性制約: 候補キー・外部キー制約、全物件1室以上、自物件への入札禁止、売却後の入札禁止、PREMIUM帯掲載50件以下、1物件への入札10件以下
• 偶発的状態と制御:
  • declare store PropertyInfo（パフォーマンス用キャッシュ）
  • declare store shared Room Floor（非正規化ストレージのヒント）
  • declare store separate Property (photo)（低頻度属性の分離ストレージ）
• フィーダー・オブザーバー: ユーザー入力をリレーションに変換し、外部導出リレーションを観察・表示するシンプルな構成で、カスタムコーディングをほぼ必要としない

■ 11. 結論

• 複雑性こそが大規模ソフトウェアの最大の問題であり、意識的に「回避」と「分離」の原則を最優先設計目標に据えなければならない
• 複雑性を制御できなければ必然的に拡大し、初期の妥協が長期的な複雑性の連鎖を生む
• 性能のための早期設計（過早最適化）は特に危険であり、シンプルなシステムの性能改善は複雑なシステムからの複雑性除去よりはるかに容易
• FRPはその最有力な実装アプローチだが、既存の大規模システムに対しては状態の回避・明示的制御の排除・コードの削減に注力すべき
• 「タールの沼」から脱出するための銀の弾丸がFRPであるとは断言しないが、答えは間違いなく「簡潔性（simplicity）」である

(2026/06/28)

UTFS a Tar-like File System for Embedded Systems

• UTFS a Tar-like File System for Embedded Systems | CLI Systems

要約:

■ 1. 概要

• UTFS（micro TAR File System）は、CLI Systemsが開発した組み込みシステム向けの軽量ファイルシステム構造
• フラットアドレス空間の記憶媒体上で、文字列ベースのファイル名によるデータ管理を実現する
• データの格納詳細をアプリケーション層のデータ構造から分離し、データサイズや位置の変更をデータ損失なく行える
• 読み取り・更新・書き込み操作を主目的とし、ストリーミングや追記操作は限定的にしか対応しない

■ 2. 従来手法の問題点

• アプリケーションロジックとデータ構造の密結合:
  • データ構造をグローバルな extern 変数として共有するため、すべてのサブシステムが同一構造体に依存する
  • 構造体を変更するとインクルードしている全ソースが再コンパイルされる
• 無関係なコードによるデータ改ざんリスク:
  • バッファオーバーフローが構造体の隣接メンバを破壊する（例：8バイトのシリアル番号フィールドに12バイトを書き込むと、隣接する subsystem1_settings が上書きされる）
  • 原因箇所と影響箇所が離れているため、デバッグが困難になる
• 構造の硬直性:
  • フィールドサイズの変更時に旧フィールドが未使用領域として残存する
  • 後から追加されたフィールドが既存フィールドの間に混在し、構造が断片化する
• 変数名の硬直性:
  • グローバル変数やメンバ変数のリネームがファームウェア全体に波及する

■ 3. UTFSによる解決策

• 1970年代のテープドライブ向けTARファイルフォーマットの概念を採用:
  • TARはフラットアドレス空間のストレージに複数ファイルを格納するための形式
  • ヘッダとデータブロックを順次配置する方式
• TARの基本概念にメモリブロックへのポインタを組み合わせ、ソースコード実装から独立した任意データの格納・取得を実現する
• 各サブシステムが独自のローカルデータ構造を持ち、相互に影響しない

■ 4. UTFSの固有の特性

• open/closeパラダイムを採用しない:
  • モダンなファイルシステムのopen/closeはストリーミング・追記操作向けであり、load-modify-saveパラダイムと整合しない
  • すべてのデータはRAMにロードするかRAMから保存する
• 小型ヘッダ設計:
  • TARの512バイトヘッダに対し、UTFSは24バイトヘッダを採用
  • ファイル名は最大11バイト（＋NULLターミネータ）の12バイト領域に格納
• 16ビットのシグネチャ変数をヘッダに内蔵:
  • バージョン管理やデータ検証に利用できる
  • データとともに自動的に保存・読み込みされる

■ 5. インタフェース

• 主要API:
  • utfs_set(): ファイル名とRAMデータポインタおよびサイズを関連付ける
  • utfs_register(): ファイルをUTFSに登録する
  • utfs_load(): ストレージから全データをRAMにロードする
  • utfs_save(): RAM上の全データをストレージに保存する
• 各サブシステムは個別のヘッダインクルードと構造体定義・登録処理を持ち、他のサブシステムから独立する

■ 6. データサイズ変更への対応

• RAM構造体がストレージ上のファイルより小さい場合: RAM構造体のサイズ分のみロードし、オーバーフローを防止する
• RAM構造体がストレージ上のファイルより大きい場合: ストレージ上のサイズ分のみロードする
• utfs_save() 実行時は現在のRAM構造体サイズで書き込まれ、全データが自動的に再配置される（データ損失なし）

■ 7. ベストプラクティス

• シグネチャ変数によるデータバージョン管理:
  • uint16_t 型のシグネチャ値でロードされたデータのバージョンを判別する
  • 旧バージョンのデータを新バージョンに移行する処理を実装できる
• シグネチャは「バージョン」に限らず、データチェックサムなどの用途にも使用可能

■ 8. 既存データストレージとの統合

• UTFSデータの「ベースアドレス」を設定する機能を提供する
• 既存のレガシーデータ領域と重複しないアドレスにUTFSを配置することで、フィールド稼働中のファームウェアにも段階的に導入できる

■ 9. まとめ

• UTFSは不揮発性ストレージとRAM間のデータ管理をシンプルかつ低オーバーヘッドで実現する
• データ格納構造をアプリケーションコードから分離し、新規・既存システムの両方に統合可能
• MITライセンスでGitHub（https://github.com/clisystems/utfs/）にて公開されている

MEMO:

• ワンチップマイコンみたいな組み込み機器用の簡易ファイルシステムという感じだろうか
• これまでワンチップマイコンに焼き込むプログラムの設定はグローバル変数のextern構造体として定義されることが多かった
• しかし、この方式では設定の追加などでアドレス位置がズレたりして壊れたり、バッファオーバーフローを利用して改竄されたりと問題もあった
• この問題をUTFSはある程度解決するということらしい

(2026/06/28)

よい機能企画書(カタログ)は 業務・ユーザー深堀りがスゴい！

• よい機能企画書(カタログ)は 業務・ユーザー深堀りがスゴい！ - Speaker Deck

要約:

■ 1. 概要

• 講演者: 平田 憲穏（株式会社Works Human Intelligence、製品開発部門 CJK Dept. CK Domain Expert Grp. / 社会保険 Grp.）
• 開催日: 2026年6月26日
• テーマ: 単なる「仕様書」で終わらせない、ユーザー業務を深堀りし成果を出す機能企画書＝「カタログ」の作り方
• 議題:
  • よい機能企画書（カタログ）は業務・ユーザー深堀りがスゴい
  • 実例① お客様のニーズを先取りした機能企画（子ども・子育て支援金の法改正対応）
  • 実例② カタログで向き合った、相談の裏側にある本当の課題（定年引上げ制度の法改正対応）
  • 実例③ お客様の「本当に欲しい」を形にする（私学共済届出 e-Gov電子申請対応）

■ 2. 機能企画とカタログの定義

• 機能企画はITエンジニアにとって「得意」「不得意」が大きく分かれる領域
• WHIにおける機能企画書を「カタログ」と呼ぶ
• カタログの役割:
  • 「何」を「いつ」機能開発するかという機能開発の羅針盤
  • 機能概要とメリットの2セットで構成される
• カタログの命名由来:
  • カタログは本来、品目を書き並べ、目を引くメリットで選ばれるもの
  • WHI版機能企画書も同様に、機能概要とメリットの2セットで構成

■ 3. 設計書とカタログの比較

• 設計書:
  • メリットが考え抜かれていない機能要件を羅列するにとどまる
• カタログ:
  • 機能を通じてユーザーに与えたいメリットを記載する
  • ユーザーへのメリット（提供価値）を機能一つひとつで徹底的に考え抜く思考プロセスをもたらす
• 「メリット」を考え抜いた業務機能の集合体がCOMPANY（自社製品）
• 日本の大法人の複雑な業務を考え抜いているからこそ、ノーカスタマイズのパッケージシステムが実現

■ 4. カタログの構成の変遷

• 初期の構成:
  • Outline（概要）
  • Function List（機能リスト）
• 現代の構成:
  • Outline
  • Business Investigation（追加）
  • User Investigation（追加）
  • Function Abstract
  • Function List
• 追加された2セクションの役割:
  • Business Investigation（書き手向け）: 表層的な問題認識から深い問題認識へ至るための「深い思考の補助線」
  • User Investigation（読み手向け）: 本質的な課題を解決しているかを判断するための「前提知識の補完」

■ 5. よい機能企画書の本質

• 問題解決の構造:
  • 問題解決は「理想」と「現実」のGAPを埋める活動
  • 機能のメリットは「現実」の深堀り度の高さで決まる
• 深堀りの有無による結果の差:
  • 業務・ユーザーの深堀りがない場合: 表層的な課題にとらわれ、メリットの低い解決策につながる
  • 業務・ユーザーの深堀りがある場合: 深層の課題をつかみ、メリットの高い解決策につながる
• 結論: よい機能企画書（カタログ）は業務・ユーザー深堀りが優れており、この深堀りが本質的な課題の発掘と本質を捉えた解決策立案を促進する

■ 6. 法改正対応における機能企画

• COMPANYにおいて、顧客からの評価が最も高いのが法改正対応
• 顧客の声（2025年顧客満足度調査より）:
  • 法改正情報をいち早くキャッチアップし対応を示してくれることへの安心感
  • 法改正に関する情報提供スピードの速さ、業務レベルでの対応方法への評価
  • 他社事例の掲載により具体的なイメージを持てることへの満足

■ 7. 実例①: お客様のニーズを先取りした機能企画（子ども・子育て支援金の法改正対応）

• 法改正の概要:
  • 2026年4月より子ども・子育て支援金の徴収開始
  • 健康保険料カテゴリで個人・事業主折半で徴収
  • 給与・賞与から徴収
• 法改正の深い理解:
  • 表層的な理解: 「子ども・子育て支援金」という項目を計算するという決まった要件を実現する対応
  • 深い理解: 「子ども・子育て支援金」を計算する新しい業務の誕生
  • 法改正対応の本質は「新しい業務」の誕生であり、法を読み解いて見出した新しい業務に対してメリットある機能を企画する
• ニーズの種類と優先度:
  • 全法人向け（給与明細ニーズ）: 給与明細の健康保険料内訳に子ども・子育て支援金を表示したい。推奨。事前のニーズ把握が困難
  • 公共団体向け（会計費目ニーズ）: 共済組合への納付で短期負担金と子ども・子育て支援金の会計費目を分けたい。必須。ニーズが明確
• 対応方針:
  • 明確なニーズを持つ公共団体向けをメインターゲットに機能企画
  • 2025年春より開発活動に早期着手
• 深堀りによる成果の差:
  • 全法人ニーズのみ把握の場合: 給与明細ニーズが読めず開発着手できず、法改正直前・直後の慌てたリリースとなるリスク
  • 公共団体ニーズも発掘できた場合: 2025年7月（法施行9ヶ月前）に初期リリースを実現し、余裕をもった法改正対応の準備が可能
  • 業務の深堀りによって明確なニーズを発掘でき、お客様のニーズを先取りした機能リリースを実現

MEMO:

• 要するに要件定義書に「ユーザーメリット」の項目を追加することで要件や施策の重要度や必要性を明記かつ要件を検討する際に重要度・必要性を強制的に考慮できる仕組みになっていると言うわけか
• 簡単だし導入もしやすそうだ

(2026/06/27)

「現行機能保証」はなぜ“悪魔の言葉”になったのか　PM歴40年の筆者が解説

• 「現行機能保証」はなぜ“悪魔の言葉”になったのか　PM歴40年の筆者が解説：SIerはどこから来て、どこへ行くのか - ITmedia エンタープライズ

要約:

■ 1. 「現行機能保証」が問題化する構造的背景

• 各開発ベンダーは工程の定義や成果物の様式が異なるため、複数ベンダーが関与するシステムでは設計書の体裁・粒度が統一されない
• ユーザー企業は設計書の作成方法や意味を十分に教授されず、自前での維持管理が困難となりITシステムのブラックボックス化が進行する
• 10年以上経過すると設計書と現状仕様の乖離が拡大し、開発ベンダー自身も現行仕様を把握できなくなる
• テスト工程で現行システムとの整合性チェックを開始した段階で保証漏れが多発し、収拾がつかなくなる事象が各所で発生している

■ 2. ユーザー企業と開発ベンダー双方の責任

• ユーザー企業側の問題:
  • 業務フロー等の要求事項定義を開発ベンダーに丸投げしている
  • 自ら維持管理すべき重要設計書をメンテナンスせず放置するケースが多い
  • 要求定義の責任を本来負わないベンダーに対し「なぜ仕様が分からないのか」と糾弾する行為はカスタマーハラスメントに近い
• 開発ベンダー側に求められる姿勢:
  • 現状の課題を最も理解しているのはプロである自分たちであることを認識する
  • 傍観せず既存システムの見える化を積極的に推進する
  • ユーザー企業と協力しながら正しい方向へ導く責任がある

■ 3. 自社独自の標準化ルールだけでは不十分な理由

• 開発ベンダーにとって、ユーザー企業固有のルールへの準拠は生産性の低下を意味するため忌避される
• 大規模プロジェクトで複数ベンダー（日立製作所、富士通、NRIなど）の工程・成果物を標準化する際、各社からの抵抗は甚大であった
• プロジェクト終了後に発生する課題:
  • 納品成果物をユーザー企業が長期にわたり維持管理できるか
  • 開発ベンダーからの「標準ルール見直し」圧力に継続的に耐えられるか
  • 新たな人材が成果物を自ら作成できるよう教育できるか
• ユーザー企業が単独で重要設計情報を長期保持し続けることは「困難」と評価される

■ 4. 業界全体で進めるべき標準化の3つの柱

• 設計工程と成果物の標準定義:
  • 工程と成果物をルールを知る者なら誤解なく理解でき、同一レベルの成果物を作成できる適正な粒度で定義する
  • ユーザー企業・開発ベンダーを問わず、その定義に基づいて設計開発を実施する
• ツール化による生産性と標準化の両立:
  • 成果物作成の仕組みをツール化することで生産性を高めると同時に、標準化の徹底と教育を自然に進める
• リポジトリ化とAI活用:
  • ツール化により設計情報のリポジトリ化を徹底する
  • リポジトリを活用して設計から開発・テストまでの全工程でAI活用を進める
  • 自動化範囲の拡大と工程間の設計情報の矛盾指摘により、生産性と品質を継続的に向上させる
• 推進手段として、公的機関を活用しながら業界全体で進めることが第一歩となる

■ 5. 標準化の適用範囲に関する留意点

• あらゆるプロジェクトを同一に標準化する必要はない
• 標準化の優先対象: 社会インフラを支えるような極めて高い信頼性が求められるITシステム
• 標準化が不要なケース:
  • データベース切り替えシステムなど、リリース時に一回使用するだけで次世代に引き継がないシステム
  • 情報分析システムなど、仕様を正確に文書化する必要がなく開発者自身が把握できるレベルの文書化で構わないシステム
• それ以外のITシステムについては、各企業が標準化の適用範囲を個別に定義すればよい

■ 6. 概要設計フェーズの目的と成果物

• フェーズの目的:
  • 「次工程である基本設計フェーズが開始できる状態を作る」ことに尽きる
  • MSAにおいて概要設計および外部設計までの工程は現状から大きく変わらない（MSの設計方法は開発ベンダー側の責任であるため）
• 必要な成果物の条件:
  • 全てのインタフェース（画面、帳票、API、電子メール、表計算データ等）が洗い出され、詳細化できるレベルに整備されていること
  • 取り扱うデータの主要項目となる「データクラス」のレベルが明らかになっていること
• コード設計の重要性:
  • 顧客番号・商品番号等のキー項目の体系設計（コード設計）はITシステムの寿命に直結する
  • コード設計の失敗や想定外の追加により、システムが不安定化または作り直しとなる事例が多い
  • コード設計はITシステム全体のアーキテクチャ設計時に個別の概要設計の前段階で実施する必要がある

■ 7. 概要設計で押さえるべき4つの形態

• 業務フロー: 業務処理の流れを記述する（基幹業務系O/L型に適する）
• 画面遷移図: ユーザー操作に伴う画面の遷移を記述する（Web型に適する）
• 状態遷移図: システム状態の変化を記述する（ゲートウェイ型に適する）
• データフローダイアグラム（DFD）: データの流れを記述する（バッチ/トランザクション型に適する）

(2026/06/27)

DX推進をうたっても老朽システムは放置　経産省のレポートが暴く「不都合な真実」

• DX推進をうたっても老朽システムは放置　経産省のレポートが暴く「不都合な真実」：SIerはどこから来て、どこへ行くのか - ITmedia エンタープライズ

要約:

■ 1. レガシーシステムモダン化委員会の総括レポート

• 経済産業省・IPA・デジタル庁が事務局を務める「レガシーシステムモダン化委員会」が2025年5月に総括レポート『DXの現在地とレガシーシステム脱却に向けて』を公表
• 2018年の「DXレポート」で「2025年の崖」として警鐘を鳴らしたレガシーシステム問題への対応が進んでいない現実を明らかにしている
• 公表後1カ月程度で1万件を超えるダウンロードがあり、問題への関心の高さを示している
• DXの成否を分けるのはAIへの投資額ではなく、レガシーシステムに含む自社独自の重要データを「使える状態」にできるかどうかである

■ 2. レガシーシステムの現状

• 大企業の74%がレガシーシステムを保有していると回答
• IT化の歴史が長い大企業、特に社会インフラ事業者に多い
• 経産省の「DX推進指標」でも不要なITシステムの廃棄が進んでいない傾向が示されている
• 負債化が進んだITシステムは規模が膨れ上がる傾向にあり、規模が大きいほど対応コスト・期間・リスクが飛躍的に増大する
• 本格的なIT変革には、まず改革対象を絞り込み適正規模に縮小することが不可欠
• 対策に本格的に取り組んだCIOの事例:
  • まず不要なシステムの廃棄から着手（使われていない帳票・画面を段階的に利用停止）
  • すぐに削除せず、表面上は使えない状態にしつつ1年間は復旧可能な状態を維持
  • 問い合わせや業務に支障がないものから順次削除し、大幅なシステム削減を実現

■ 3. 「既存システムは今のままでいい」という誤認

• DXと称してAIやWebのユーザー接点部分の改革を推進する一方、「既存ITシステムは今のままでいい」と断言するCIOが存在する
• システムモダナイズの最大の目的は企業の競争力確保である
• システムモダナイズとは、企業が持つデータをAIが活用できる状態に転換することを指す
• データが「使える」状態とは、精度・鮮度・粒度が適切に保たれていること
• レガシーシステムが抱えるデータは企業独自の最も重要な資産である
• データ活用を実現するアーキテクチャとしてオブジェクト指向技術（マイクロサービス）の適用が有効

■ 4. ウォーターフォールの基本と設計手法の変化

• ウォーターフォールモデルはソフトウェア開発の基本であり、オブジェクト指向開発でも基本は同様
• モノリスシステムとMSAの設計手法の主な違い:
  • データベース設計:
    • モノリスではデータベース設計が大きな比重を占める
    • オブジェクト指向ではデータはオブジェクト内にカプセル化され、APIを通じてのみアクセスするためデータベース設計の比率が極端に低下する
  • システム間接続:
    • 従来はトランザクションデータを基本に考える
    • MSAではAPI接続を前提に考える
  • トランザクション管理:
    • モノリスでは一括確定が比較的容易
    • MSAではサービスが分散するため、データ整合性を保つ新たな仕組みが必要

■ 5. 外部設計の「揺らぎ」問題と解消策

• 外部設計工程が「揺らぐ」理由:
  • 外部設計は顧客の要求事項をまとめる段階だが、全ての要求が技術的に実現できるとは限らない
  • 実現困難な機能については内部設計以降の工程を先行実施し、実現可能性を見極める必要がある
  • この技術的実現可能性の確認プロセスが「揺らぎ」を生む
  • SIerが受託契約を結ぶには実現可能性の事前確認が不可欠であったため、この構造が定着した
• 内製化を前提にすれば「揺らぎ」が解消できる:
  • 実現方式をほぼ見極められる内部設計までを含めて「設計工程」とすることで整理が明確になる
  • ユーザー企業が設計内容の妥当性を判断するスキルを持つことが前提
  • 「何を作るか」はユーザー企業が決め、「どう作るか」はSIerが担うという従来の役割分担の見直しが必要

■ 6. MSA時代の開発工程と設計の再定義

• MSA時代の開発工程の整理:
  • 概要設計工程: 大まかな要件を定義する
  • 基本設計工程: 概要設計を実現するための設計（外部設計活動と内部設計活動を含む）
  • 開発工程: 基本設計に基づく開発
  • テスト工程: 開発成果物の検証
• 基本設計工程内で技術的問題が発生した場合は概要設計に立ち戻ることで「揺らぎ」を吸収する
• サブシステム単位の設計が基本になる:
  • 従来の大規模ITシステムは20〜30程度のサブシステムから構成されるモノリス構造だった
  • MSAではビジネスの成長に合わせてサービスを分割・拡張し、API接続で連携させる
  • 新たな開発方法論では、個々のサブシステム単位で直接設計に入ることが前提となる
  • 結果として大規模ITプロジェクトがなくなり、プロジェクト規模が適正化され成功確率が高まる
• 「追認型マネジメント」への転換:
  • 各マイクロサービスを厳格に管理するよりも、チームごとの判断で柔軟にサービスを発展させ、全体の整合性を事後的に確認する「適応型のマネジメント」が求められる
  • 全体のマイクロサービス構成をある程度の粒度で把握する「追認型マネジメント」に変わる
• 既存レガシーシステムの移行においては、巨大なモノリスシステムの「積み木崩し」が必要となるため、超大規模ITシステムの方法論も一部必要になる

(2026/06/27)

IT業界の品質保証、どう変わる？　“バグがあっても当たり前”からの脱却方法を考察

• IT業界の品質保証、どう変わる？　“バグがあっても当たり前”からの脱却方法を考察：SIerはどこから来て、どこへ行くのか - ITmedia エンタープライズ

要約:

■ 1. 情促法改正とIPAの役割変化

• 内閣総理大臣が主務大臣に加わり、IPA（情報処理推進機構）が省庁横断的なIT政策推進機関へと変貌した
• 従来はIPAに他省庁所管業界へガイドライン順守を求める法的根拠がなかった
• この改正により、ITシステムの品質に関するガイドラインが業界横断で求められる時代が来る可能性がある

■ 2. モノリスシステムとMSAの比較

• モノリスシステムの問題点:
  • 高コスト・長期間の開発を強いる
  • 小規模な改修でも広範囲に影響が及ぶ
  • ビジネス環境の変化にITシステムが追い付かない
• MSA（マイクロサービスアーキテクチャ）の優位性:
  • 独立した小さなサービスを部品のように組み合わせて構成する
  • 品質保証済みの「部品」を再利用することで開発コストと期間を大幅に圧縮できる
  • 市場の変化への迅速な対応が可能となり、DX推進の土台が整う

■ 3. MSAにおける開発規模の概念変化

• 従来のモノリス開発ではステップ数やファンクションポイントが規模の指標であった
• MSA開発では、「部品」は開発対象でもテスト対象でもないため、規模の問い自体が意味をなさない
• MSAにおける開発規模の指標:
  • 新たに追加する論理の「分岐数」が規模を測る指標となる
  • 分岐数が多ければテストケース数も増えるため、テストケース数が見積もりの根拠となる
  • 従来のステップ数・ファンクションポイントに基づく見積もり手法は通用しない

■ 4. MSAによる生産性・品質への効果

• 新規で開発する総量を従来手法の10分の1以下に抑えられ、生産性は10倍以上向上する
• テスト対象がシステム全体でなく限定されるため、テスト工数が削減される
• AIの活用:
  • 追加開発分のソースコードを入力することで、全テストケースの洗い出しが可能
  • テストデータはAPIの入出力のみであり、辞書を学習させることでAIによる自動作成ができる
  • 設計情報をデータ化することで、テスト結果の期待値もAIで自動作成可能
• ホワイトボックステストが品質保証の中心となり、テストケース数は従来より極めて少ない

■ 5. 製造業の品質保証モデルとの比較

• 製造業における品質保証体制:
  • 受入検査・工程内検査・最終検査という多段階の検査プロセスを経る
  • ISO 9001などの品質マネジメントシステムに基づく体系的な管理体制が整備されている
• MSAにおける類似構造:
  • 各「部品」はホワイトボックステストで品質保証される
  • 部品を組み込んだ本体も同様にホワイトボックステストで品質保証される
  • 上位のマイクロサービスに対しても品質保証済みのものが組み込まれる
  • 機能間のブラックボックステストも実施可能
• ソフトウェアと製造業の根本的な違い:
  • ソフトウェアは複製コストがほぼゼロであり、物理的な劣化も起きない
  • 出荷後でも比較的容易に修正可能という特性がある
  • この「後から直せる」特性が「バグがあって当たり前」という認識を生んだ側面がある

■ 6. MSAの落とし穴: 勘違い開発のリスク

• 製造業では1つの部品に仕様確認・設計・製造・検査と複数担当者が関与して相互チェックを行う
• MSAでは開発者1人が設計から開発まで一貫して担うケースが生じやすい
• 疎結合・マイクロサービス単位リリース環境特有のリスク:
  • 開発者が勘違いをしたまま設計すると、そのままリリースされる可能性がある
  • AIは「論理的な矛盾」の検知は得意だが、「ユーザーが求める真の意図」との乖離（仕様の誤り）は判断できない
  • AIによるチェック体制は開発者の勘違いによる開発の歯止めにならない
• 従来のモノリスシステムでは、連結テスト・総合テストを第三者が実施することでこうした勘違いをバグとして検出していたが、MSAではその機会が失われる可能性がある

■ 7. ペアプログラミングの重要性

• 別人格の技術者が同一の勘違いを起こす確率が低いため、ペアプログラミングが有効な対策となる
• Pivotal Softwareも同様のアプローチを採用しており、その有用性を実証している
• 工数面の懸念への対応:
  • MSAでは部品活用により開発工数が大幅に削減されるため、ペアプログラミングによる重複工数は全体として小さい
  • テスト工数・連結テスト工数も削減されるため、全体的なコスト増は限定的と推察される
• クリティカル度に応じた品質保証方式の設計がPMの重要な仕事となる:
  • 一般的なクリティカルなシステム: ベテラン技術者2名で担当
  • さらにクリティカルなシステム: 3名の技術者が担当

■ 8. SBOMによる部品管理

• マイクロサービスを呼び出し先として活用する場合、該当サービスが修正された際に自サービス側の整合性確認・更新が必要となる
• SBOM（Software Bill of Materials: ソフトウェア部品表）の整備が品質確保に不可欠
• ソフトウェアの生産方式だけでなく、プロジェクトマネジメント技術の革新も求められる

(2026/06/27)

メインフレーム離脱プロジェクトの7割超が失敗、理由は「生成AIの過大評価」

• メインフレーム離脱プロジェクトの7割超が失敗、理由は「生成AIの過大評価」：AIニュースピックアップ - ITmedia エンタープライズ

要約:

■ 1. Gartnerの予測概要

• 2026年に開始されるメインフレーム離脱プロジェクトの70%超が、意図した利益を生み出せずに終わるとGartnerが予測
• 主因は、複雑なレガシーコード変換・移行における生成AIの能力を過大評価する傾向
• 市場が訴求するAIによる効率化の内容と、実際の現場で発揮できる能力との間にギャップが拡大している

■ 2. 失敗リスクを高める要因

• 投資家からの強い圧力により、ベンダーは成果改善への寄与が不明確でも自社製品にAIを組み込む方向へ誘導される
• メインフレームアプリケーションは基幹業務を支えるため、移行失敗時の影響が甚大
• メインフレームに熟練した人材が減少しており、計画不足の離脱戦略を選択するリスク環境が形成されている

■ 3. 失敗がもたらす影響

• 誤った判断はコスト超過にとどまらず、基幹業務の停止など事業継続に直接的な影響を及ぼす可能性がある
• 全課題をAIで一括解決しようとする離脱策に依存する組織は、重大な技術的負債を抱え、企業全体を深刻な障害にさらす危険がある
• プラットフォーム志向の戦略（ワークロードを適切な環境に割り当てる方針）を採る組織との間に格差が生じる

■ 4. 市場への影響

• 2030年までに、メインフレーム離脱市場で事業展開するベンダーの75%が事業モデルを転換するか、事業継続を断念するとGartnerは予測
• 市場の期待が修正され、あらゆる環境に適用できるとうたう移行ソリューションへの需要が低下する見込み

■ 5. メインフレームを継続利用する合理性

• IBMによる継続投資が、メインフレームを現代的プラットフォームとして維持する基盤となっている
• 独立系ソフトウェアベンダー（21CS、BMC Software、Broadcom、Rocket Softwareなど）の存在が市場を支える
• マネージドサービスプロバイダー（DXC Technology、Global Technology Solutions Group、Kyndrylなど）もプラットフォームの戦略的価値を補強

■ 6. 規模別の推奨戦略

• 複雑な環境全般:
  • 生成AIは、プラットフォーム外への移行を急がせる手段ではなく、既存環境内での近代化を支援する手段として活用する方が有効
• 中規模メインフレーム環境:
  • 既存投資の最適化を軸に据えることが基本方針
  • 完全なプラットフォーム離脱は、個別に妥当性を見極める必要がある
  • 全面的な離脱は高リスクの変革を伴い、望ましくない結果に終わる場合が多い
• 小規模メインフレーム環境:
  • メインフレーム・アズ・ア・サービス（MFaaS）を費用対効果の高いホスティング戦略として検討
  • 古いサードパーティー製ソフトウェア（ISVソリューション）の置き換えを推奨
  • 投資対効果が見込める範囲に絞ったプラットフォーム内近代化に集中すべき

(2026/06/27)

本質的な複雑性と偶有的な複雑性の違いは実は自明ではない

• 本質的な複雑性と偶有的な複雑性の違いは実は自明ではない - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

要約:

■ 1. 本質的な複雑性と偶有的な複雑性の定義

• 概念の出典: フレデリック・ブルックスの論文『銀の弾丸はない』で提唱された区別
• 本質的な複雑性:
  • 問題領域に内包された、回避不可能な複雑性
  • 例: 医療における麻薬処方の管理ルール（麻薬施用免許保持者による処方、鍵付き保管、処方箋の参照管理など）
• 偶有的な複雑性:
  • 実装方法、技術的制約、または誤った解決領域の選択による複雑性
  • 例: バッチ処理機能が存在しないために、ユーザーが一件ずつ手動でデータを登録しなければならない手間

■ 2. 模範解答とその前提

• 一般的な指針: 本質的な複雑性に向き合い、偶有的な複雑性を削減することが正解とされる
• 仮説としての区別の重要性:
  • ふたつの複雑性を区別しなければ、既存業務の偶有的複雑性を維持するだけの不要な機能を作り込むリスクがある
  • 本質的な複雑性を偶有的だと読み誤ると、業務上重要な仕様が満たされない事態が発生する
  • 間主観的に削り出した区別があるかないかで、問題解決の筋の良さが大きく異なる

■ 3. 「本質性」の主観性という問題

• 「本質」はア・プリオリに存在しない:
  • 問題そのものも、誰かが問題視することで初めて生じる
  • 「問題の本質」は問題に内在せず、問題と対峙する人間の観察の中に存在する
• 本質性は観察者によって変化する:
  • 誰が問題に向き合うかによって、何が本質的に見えるかは容易に変わる
  • 議論参加者の間主観の中に生まれる「本質」は、問題に対してア・プリオリに存在するわけではない

■ 4. 実際の運用によって初めて明らかになる本質的複雑性

• 頭の中での検討は想像に過ぎない:
  • 実際に動くシステムで実際の業務を行わなければ、何がどの程度解決できたか、どんな偶有的複雑性を持ち込んでしまったかは分からない
  • 「ないものでないことをやっていても気づけない」という本質的な限界がある
• 本質的複雑性は実際の使用を通じて立ち現れる:
  • ユーザーが実際のシステムを使ったとき、ユーザーと開発者の間主観の中に初めて形が見えてくる
  • ア・プリオリに存在するものではない

■ 5. ふたつの結論

• 区別は仮説として立てるしかない:
  • 何が本質的で何が偶有的かは自明ではなく、チームで知恵を絞って仮説を立てながらサービスを構築する必要がある
  • 仮説の精度を高めることは重要
• 「本物の本質的複雑性」は実際の運用からしか発見できない:
  • いくら仮説の精度が高くても、現実の運用を通じた学びなしには真の本質的複雑性は見出せない

■ 6. 技術的負債とドメインの蒸留

• 学びをシステムにフィードバックする重要性:
  • 「本質的複雑性だと思ったものが偶有的だった（またはその逆）」という学びをシステムに反映し続けることで、チームの能力が育ちサービスは改善され続ける
• 学びとコードの乖離が技術的負債を生む:
  • 学びは得られてもコードが変わらなければ、システムの現状と「学習された本質的・偶有的複雑性の分離」がどんどん乖離する
  • これが本来の意味での技術的負債であり、「ドメインの蒸留」が示すのも学びをソフトウェア設計に再投資し続けることの重要性
• 本番環境のサービスは最大の学習の場:
  • 最も学びが多く、最も負債が蓄積される場所でもある

■ 7. 著者のビジョン

• 本番の学びを軸とした継続的改善:
  • 本番で得た学びをもとに技術的負債を解消し（新しい学びにマッチする構造へのソフトウェアの変更）、ソフトウェアを進化させ続ける
  • 現場の偶有的複雑性をシステムが肩代わりすることで、現場が本質的複雑性に集中できる新機能を積極的に作り上げる
  • この営みは新たな学びと負債を生み出し続ける、世界をよくするための永続的なサイクルを形成する
• 課題解決に従事するすべての人へのメッセージ:
  • このビジョンを共有し、共に日々を過ごしていくことへの呼びかけ

(2026/06/27)

30代を捧げてきた技術が死にそう

• 30代を捧げてきた技術が死にそう

日本の端の方にいるIT技術者である。

30代をとある技術に全ベットしてきた。

数年前までは結構勢いがあったのだが、とある上位互換の技術の台頭により、一気にシェアを落としてしまった。

採算が取れないので会社としても、近々プロジェクトを終了させるだろう。IT技術なんて栄枯盛衰あって当然だが、実際に自分の携わっているものが死にゆくのをみるのは、無念だし辛い。

もっと悲しいのが、この技術が死んだら俺にはほとんど何も残らないってことだ。深い理解をすることなく、小手先の技やTipsばかりがうまくなった。それらも一緒に消え去ってしまう。新しいことを学ぼうとしても、chatGPTの方が1億倍くらい優秀だし、安い。

IT未経験者にいっておくと、CSをしっかり勉強することをお勧めする。AWSよりLinux、LinuxよりOSとは何か、みたいなことだ。最初は成果がでずにしんどいかもしれないけど、深いところから理解しておくとちょっとやそっとの変化には対応できるはずだ。

さて、この業界での終活をおえたらどこで生きていこうかな。

関連:

• プログラマになれなかったわたし

(2026/06/27)

コンテナをVMみたいに使うならincusが便利だよ。2025/08版

• コンテナをVMみたいに使うならincusが便利だよ。2025/08版

イミュータブルなコンテナは、コンテナを再起動すると永続化可能な領域にデーターを置いていない限り初期状態に戻ります。

この特性は便利な場面も多々あります。しかしVirtual Machine(以下VM)のように中に入って作業しても作業内容が消えない。

つまりimmutableでない方が便利な場合もあり用途によって道具を使い分けようという提案が本記事です。

(2026/06/26)

「本を Skill にする」という発想が、3,000スターを集めた理由

• 「本を Skill にする」という発想が、3,000スターを集めた理由｜藤原 ケイ｜AIスキルハック

MEMO:

• 書籍（PDF）の内容をskillにするskillらしい
• RAGを作るよりは簡易な書籍をAIの知識化するというもの
• skillはmarkdownなので共有が容易であり、本の内容がskillとして共有されることがあれば著作権上かなりまずいことになりそうだが
• まぁ、最早それは止められないか

(2026/06/26)

The Wrong Abstraction

• The Wrong Abstraction — Sandi Metz

要約:

■ 1. 主張の概要

• 「複製（duplication）は誤った抽象化よりはるかに安い」という命題を提唱
• 「誤った抽象化よりも複製を選ぶべき」という指針を示す
• この主張はRailsConf 2014での講演「all the little things」で取り上げ、大きな反響を呼んだ

■ 2. 誤った抽象化が生まれるパターン

• プログラマAが重複コードを発見し、抽象化（メソッドまたはクラス）として切り出す
• しばらく時間が経ち、新しい要件が追加される
• プログラマBが既存の抽象化を保持しようとし、パラメータと条件分岐（conditional）を追加して対応する
• さらに新しい要件が来るたびに、別のプログラマが同様の変更を繰り返す
• 結果としてコードは条件分岐だらけの難解な手続きとなり、理解も修正も困難になる

■ 3. 既存コードが及ぼす心理的圧力

• 既存のコードは「正しく、必要なものだ」という強い影響力を持つ
• コードは過去の努力の産物であるため、その価値を保持しようとする動機が生まれる
• コードが複雑であればあるほど「多大な労力をかけたはずだ、無駄にしてはならない」という感覚が強まる
• これは「サンクコストの誤謬（sunk cost fallacy）」に相当し、判断を歪める要因となる

■ 4. 解決策：「前進するための最短路は後退すること」

• 誤った抽象化に直面した場合、サンクコストに引きずられず、後退（巻き戻し）を選ぶべき
• 具体的な手順:
  • 抽象化されたコードを、呼び出し元すべてにインライン展開して複製を再導入する
  • 各呼び出し元において、渡されているパラメータを基に実際に必要なコードの範囲を特定する
  • 各呼び出し元で不要なコードを削除する
• この作業により抽象化と条件分岐の両方が除去され、各呼び出し元は必要なコードだけを保持する
• 旧抽象化を完全に取り除いた後、現行要件に即した形で改めて重複を分離し、新たな抽象化を導出できる

■ 5. 実践的な教訓

• 「この投資を守らなければならない」から「このコードから学べることはすでに学んだ」へ視点を切り替えることで、作業が容易になる
• インライン展開後に前進の道筋が明確になり、新機能の追加が速く容易になる
• パラメータを渡したり、共有コードに条件分岐を追加しているなら、それは抽象化が誤っているサイン
• 誤った抽象化を早期に廃棄するほど、損失は少なくなる
• 後退は撤退ではなく、より良い方向への前進である

■ 6. 付記: 99 Bottles of OOP 第2版リリース

• 99 Bottles of OOP の第2版が新たにリリースされた
• 第2版の変更点:
  • 3章追加され、全体量は第1版比で約50%増量
  • Ruby、JavaScript、PHP の3言語で個別書籍として提供（内容は同一）
  • 「ビール」と「牛乳飲料」の2バリエーションが存在
  • epub、kepub、mobi、pdf の4フォーマットで配信
  • 合計6種類の書籍、24通りのダウンロード組み合わせ
• 1回の購入でいずれのバージョン・フォーマットもダウンロード可能

(2026/06/26)

（株）秀和グループ | TSR速報 | 倒産・注目企業情報

• （株）秀和グループ | TSR速報 | 倒産・注目企業情報 | 東京商工リサーチ

要約:

■ 1. 破産決定の概要

• 2026年6月17日、（株）秀和グループ（江東区）が東京地裁から破産開始決定を受けた
• 破産管財人に樋口千鶴弁護士（上條・鶴巻法律事務所、千代田区）が選任された
• 負債額は調査中

■ 2. 秀和グループの設立経緯と事業内容

• 書籍出版事業を手掛ける（株）秀和システム（2025年7月破産）の破産時の代表によって設立
• 事業目的は出版および配信事業等

■ 3. 秀和システムの経緯と破産背景

• 2021年5月、グループ会社を通じて船井電機（株）（現：FUNAI GROUP（株）、大東市）を一時傘下に置いた
• 資金繰り悪化の要因:
  • 脱毛サロン「ミュゼプラチナム」運営会社に対する連帯保証の顕在化
  • レピュテーション悪化による出版物の返本
• 2025年7月に破産開始決定を受けた
• 秀和システムの事業は新会社にて継続中

■ 4. 秀和グループの破産に至る経緯

• 秀和システムの破産手続き進行中、秀和グループが貸金請求訴訟の被告となった

MEMO:

• あちゃー　秀和グループ倒産しちゃったかー（蛸壺屋感）

(2026/06/25)

リファクタリングにドメイン知識が要るなら、その知識はどこに置くのか

• リファクタリングにドメイン知識が要るなら、その知識はどこに置くのか

要約:

■ 1. 問題提起

• リファクタリングにはドメイン知識が必須であり、顧客の文脈や要求まで遡る必要がある
• 「そのドメイン知識をどこに、どんな形式で保管するか」が語られる機会は少ない
• 知識の保管場所を誤ると、リファクタリングの前提となる情報そのものが腐敗する
• AIコーディングエージェントが普及した現在、この問題はさらに深刻化している

■ 2. 知識の4分類

• How（どう動くか）: 関数の振る舞い、データの変換手順
• What（何をすべきか）: 入力に対して返すもの、拒否するものの定義
• Why（なぜそう決めたか）: 技術選定の理由、設計判断の背景
• Why not（なぜそうしなかったか）: 検討して却下した代替案とその理由

■ 3. 各知識の適切な配置先

• How → コード:
  • 「どう動くか」の正本はコード自体であり、読んだだけで意図が伝わるコードを指す
  • DDDのユビキタス言語に対応し、Brand型やValue Objectでドメイン概念を型に埋め込む
  • コードを変更すればHowの記述も自動更新されるため、腐敗への耐性が高い（Self-Documenting Code）
• What → テストコード:
  • 「何をすべきか」の正本はテストコードであり、実行すれば嘘をつけない
  • 仕様と実装がずれた瞬間にCIが赤くなり、同期の強制を機械に委ねる
  • テストが仕様として機能するのは、テスト名が「何をすべきか」を表現している場合に限る
  • テスト名を仕様書として書く習慣がない場合、テスト数だけ増えて何を守っているか不明になる
• Why → ADR（Architecture Decision Records）:
  • 技術選定・アーキテクチャの分岐・仕様の取捨選択といった大きな判断を記録する
  • 内容を書き換えず、状況が変わった場合は新しいADRでsupersede（置換）する
  • タイムスタンプとステータスが明示されているため、AIも有効性を構造的に判断できる
• Why not → ADRのWhy notセクション:
  • 「何を選ばなかったか、なぜか」はコードに現れないため最も失われやすい知識
  • この情報が失われると、同じ議論を半年後に繰り返すことになる
  • ADRはイミュータブルであるため判断が消えず、JSDocのようにコードと共に消えない

■ 4. 自然言語ドキュメントが正本として機能しない理由

• 仕様書はコードが変わっても自動更新されない
• 古い仕様書と新しい仕様書が混在すると、AIがどちらを信じるかの判断に揺れが生じる
• 「事実だけ保存する。導出可能なものは保存しない」という原則（そーだい原則）が適用される
• コードから導出できる情報を別の文書にも書くと二重管理となり、乖離が必ず発生する
• 乖離した文書をAIが参照すると、古い仕様で実装する事故が起きる

■ 5. 型とテストの守備範囲の分離

• 型（コンパイル時）で守れるもの: IDの取り違えやエラー処理の漏れなど、構造的に判定できるもの
• テストで守るべきもの:
  • 「退職済みメンバーの操作を拒否する」のような実行時ロジック
  • 「48時間で期限切れにする」のような時間依存の振る舞い
• 型で守っている範囲をテストで二重に検証すると無駄が生まれるため、守備範囲を混同しない

■ 6. 抽出可能性と設計品質の関係

• コードからドメイン用語集やアーキテクチャ図を自動抽出しようとする試みは、設計品質のバロメーターになる
• 抽出スクリプトを書くことが異常に難しい場合、スクリプトではなくコードの設計が問題
• 適切な命名規則（例: src/domain/member/MemberId.ts）であればファイル名だけで用語集が作れる
• 汎用的な命名（例: src/utils/helpers.ts）ではスクリプトによる判別が不可能

■ 7. まとめ

• ドメイン知識を「人の頭」や「手書きの仕様書」だけに置くと、人の異動や仕様書の腐敗によりリファクタリングの前提が失われる
• 配置原則:
  • How→コード
  • What→テスト
  • Why・Why not→ADR、コードから導出可能な説明文書は置かない
• AIコーディングエージェントと協働する時代において、この配置原則の価値はさらに高まる
  • テストは「通るか通らないか」の二値で答え、型は「コンパイルできるかできないか」の二値で答える
  • ADRはイミュータブルな記録としてAIにも人にも同じ情報を伝える

(2026/06/25)

「コードレビューは人間がやるべき」 という、最後の幻想

• 「コードレビューは人間がやるべき」 という、最後の幻想

要約:

■ 1. AI時代におけるコードレビューのボトルネック化

• AIが実装速度を3〜10倍に引き上げた現場では、コードレビュー（PR確認）工程が新たな詰まりとなっている
• コードは大量に生成されるが、下流でシニアエンジニアがPR対応に溺れる構造が生まれている
• パネルセッションでの会場調査では、約半数がコードレビューをチームのボトルネックと認識している

■ 2. 「シニアが最後に見るから大丈夫」という前提の崩壊

• コードレビューの本来の目的は「内部規約への準拠」と「チームが定めた最低限の品質の維持」にある
• いつの間にか「最後の品質の砦」かつ「承認の儀式」に変質した
• シニアエンジニアが1日に10〜20本のPRを目視で漏れなく検査することは現実的でない
• 「シニアが最後に見る」という運用は、AI以前からすでに薄い前提であり、流量が少ない間は機能しているように見えていただけに過ぎない
• AI時代の流量増加によってその前提が剥がれた

■ 3. コードレビューの解体: 観点の言語化

• シニアエンジニアが頭の中で何を・どんな順番で・どこに照らして確認しているかを言語化する作業が「コードレビューの解体」である
• 観点が言語化されるとAIが読み取れる入力となり、定型化できる観点はAIが同じ厳密さで繰り返し安定して処理できる
• 定型レビューをAIに渡せない組織の多くは、そもそもレビュー観点が言語化できていない組織である
• 観点が言語化されていない組織では、シニアが退職した瞬間に品質が崩壊するリスクがある
• 解体によりシニアの暗黙の判断基準がハーネスのルールとして整理され、チーム全体に継承可能な形になる
• コードレビューの解体は属人性を解きほぐす作業でもある

■ 4. スイスチーズモデルによる多層防御と並列レビューの設計

• スイスチーズモデル: 穴の空いたチーズを複数枚重ねることで穴の貫通を防ぐ品質保証の考え方（航空安全の分野で発展）
• ソフトウェアでも静的解析・リンター・ユニットテスト・プロパティベーステスト・E2Eテスト・コードレビュー・セキュリティスキャンを重ねることで欠陥の貫通を抑える
• AIレビューを多層ハーネスとして組み立てる際の要点は、観点を細かく分けて並列に走らせることにある
• 実践例（セキュリティレビュー）:
  • 観点を9つに分割: 権限の境界、入力検証の死角、機密値の露出経路、依存ライブラリの来歴、SSRF・SQLインジェクションなどの外部攻撃経路、CSRF防御、セッション管理、暗号化運用、ログと監査の妥当性
  • Codexに9観点を1つずつ割り当て、Claude Codeにも同様に9観点を割り当て、合計18セッションを並列実行
  • 両系統が同じ箇所を指した場合は確度が高い問題、片系統のみが指した箇所はトリアージ候補とする
• 並列化の理由:
  • 同一モデルに同一プロンプトで長時間レビューさせると、同じ思い込みや仕様の勘違いが温存される
  • 異なるモデルを当てることで思い込みの方向がずれ、穴の位置が変わって貫通リスクが減る
• 1人のシニアエンジニアが全観点を同時に処理することはそもそも過大な期待であり、観点を分けて並列に当てることで見落としを大幅に減らせる

■ 5. 観点のハーネス化がもたらす品質とスピードの両立

• 観点がハーネスに沈むと、次のPRからCIが自動で検査してくれる「当たり前の水準」として組織に定着する
• 人間の役割は「次にどの観点を入れるか」を考えることへ移行する
• これまで人材不足や難易度を理由に諦めていた品質基準も、言葉にできればAIハーネスに組み込める
  • 例: テスト駆動の徹底、形式手法に基づく仕様検査、サプライチェーン攻撃の経路分析、認可境界の独立レビュー
• 「スピードが上がるから品質を犠牲にする」ではなく、観点を言語化してハーネスに沈めることで品質とスピードを同時に向上させられる
• 前提条件: 組織が自分たちのレビュー観点を言葉にできること。これができなければハーネスに何も入らない

■ 6. 砦を人から仕組みへ: 組織間の新たな格差

• 観点が言語化された組織では、砦がシニアエンジニア個人ではなくCodexやClaude Codeなどのハーネスへと移行する
• 観点が言語化できていない組織は、AIがどれだけ速くコードを生成しても最終的に人間のところで詰まる構造が変わらない
• シニアエンジニアが何を・どんな順番で・どこに照らして確認するかを書き出せる組織と書き出せない組織の間に、品質とスピードの新たな格差が生まれる

(2026/06/25)

NTTPC「WebARENA」ファイル転送サービスに不正アクセス　業務ファイル4400件超に漏えいの恐れ...

• NTTPC「WebARENA」ファイル転送サービスに不正アクセス　業務ファイル4400件超に漏えいの恐れ　再構築へ今後半年間停止 - ITmedia NEWS

要約:

■ 1. 概要

• NTTPCコミュニケーションズが2026年6月23日、法人向けホスティングサービス「WebARENA」の2件の不正アクセス事案について詳細を公開
• 対象サービスは「大容量ファイル転送機能」と「WebARENA SuiteX」の一部サーバ（dc70.etius.jp）

■ 2. 大容量ファイル転送機能への不正アクセス

• 経緯:
  • 4月29日深夜に外部からの攻撃とみられる断続的な通信が発生し、サーバへのアクセスを遮断してサービスを停止
  • 調査の結果、4月21日から不正アクセスがあった痕跡を確認
• 漏えい可能性のある情報:
  • 認証ログ（メールアドレス、認証日時）
  • 契約者がアップロードした電子ファイル
  • アップロード関連情報（日時、IPアドレス、ファイル名、ダウンロード用パスワード、ダウンロード用URL、メッセージ）
  • アップロード操作ログ（日時、メールアドレス、IPアドレス、操作内容）
  • Webサーバログ（接続元IPアドレス、接続日時）
• 影響件数:
  • 契約数: 1,510契約
  • ユニークメールアドレス: 7,446件（2019年3月5日〜2026年4月30日）
  • アップロードされた電子ファイル: 4,463件（2026年4月19日〜2026年4月30日）
• 現状と対応:
  • 情報漏えいの痕跡は確認されていないが、可能性を完全には否定できない状態
  • 現時点で不正利用や二次被害は確認されていない
  • 影響を受けた契約者には契約IDを記載のうえ順次個別に連絡
  • システム全体の再構築を進めており、サービス再開は2026年12月ごろを予定

■ 3. WebARENA SuiteX 一部サーバへの不正アクセス

• 経緯:
  • 5月10日に外部からの攻撃とみられる断続的な通信が発生し、アクセスを遮断してサービスを停止
  • 調査の結果、第三者による不正アクセスの痕跡を確認
• 被害の内容:
  • 同社のシステム管理上の暗号化された情報の一部が第三者に閲覧された
  • 7契約の顧客領域に不審なファイルが設置された痕跡あり
• サーバに格納されていた情報:
  • Webコンテンツ（データベース情報含む）
  • メールコンテンツ
  • 管理者アカウント/パスワード
  • Webアカウント/パスワード、メールアカウント/パスワード、メーリングリスト情報
  • Webアクセスログ、FTPログ
• 影響件数:
  • 契約数: 385契約
  • メールアカウント数: 8,203件
  • Webアカウント数: 269件
• 現状と対応:
  • 顧客情報の漏えいや二次被害は現時点で確認されていない
  • 影響を受けた契約者には契約IDを記載のうえ順次個別に連絡
  • 同一環境でのサービス再開は適切でないと判断し、当該サーバのサービス提供を終了
  • 希望する契約者には代替となるSuiteX環境の提供を開始

MEMO:

• PPAPはよくないからファイル転送サービスを使おうと言っていたのに、そのファイル転送サービスが不正アクセスで陥落していては詮無い話である
• 企業の情報セキュリティ担当者も頭抱えているのではないだろうか
• ログがそのまま抜き取られてるところを見ると物理サーバだったのか？
• JTCらしさ溢れるトラディショナルな運用体制だったことが伺われる

(2026/06/24)

AIエージェント時代に問われるのは「プロンプト力」ではなく「コンテキスト設計力」である― プロンプトの...

• AIエージェント時代に問われるのは「プロンプト力」ではなく「コンテキスト設計力」である― プロンプトの時代から、コンテキスト設計の時代へ ―｜GPUサーバープラットフォームの設計/構築なら「技術力」のNTTPC

要約:

■ 1. チャットAIとAIエージェントの違い

• チャット型AIはカーナビに相当し、道順を案内するが実際の操作は人間が行う
• AIエージェントは自動運転ドライバーに相当し、目的達成に向けて自律的に判断・行動する
• 現時点では人間の監督・確認が必要だが、「答えを教えるAI」から「目的達成に向けて動くAI」への進化が進んでいる

■ 2. プロンプトからコンテキストへのシフト

• チャット型AIではプロンプト（指示文）の品質が重視されてきた
• AIエージェントに仕事を任せるには、目的だけでなく以下の情報が必要:
  • ルート・制約条件の優先順位
  • 業務ルール・顧客状況
  • 参照資料・評価基準
  • 既存システムや過去の経緯
• AI活用の成否は、プロンプト単体ではなくコンテキスト設計の優劣によって決まりつつある

■ 3. AIエージェントの現状と各社の動向

• AIエージェントはコーディング支援を皮切りに、調査・資料作成・業務アプリ操作・ワークフロー実行へと拡張されている
• 製品理解のポイント:
  • LLMのモデル名、チャットサービス名、エージェント機能名が混在しているため、「モデル」「チャットサービス」「エージェント」を分けて整理すると理解しやすい
• AIエージェントの入口はチャット画面に限らず、デスクトップ・ブラウザ・Office・開発環境・CLI・モバイルへ広がっている
• どのツールを使うかよりも、AIをどの業務環境に置き、何を任せ、どこまで人間が確認するかを設計する力が重要になる

■ 4. GoogleのLLM戦略: GeminiとGemma

• Googleは高性能クラウドモデルのGeminiに加え、オープンウェイト系モデルのGemmaも提供している
• Gemma 4はスマートフォン・PC・エッジデバイスなど、ローカル環境での動作を意識した設計となっている
• AIエージェントはクラウド上だけでなく、業務アプリや開発環境などあらゆる場所へ浸透しつつある
• コンテキスト設計の考え方は文章・コード生成だけでなく、画像生成・資料作成にも共通して適用される

■ 5. マルチモーダル化によるコンテキスト設計の拡張

• 近年のLLMはPDF・画像・音声・動画・スライド・Webページなど複数形式の情報を扱えるマルチモーダル化が進んでいる
• AIに与えるコンテキストも、テキストのみならず多様な形式の情報を含むものへ広がっている
• NotebookLMはその実践例であり、複数ソースを集約してAIに参照させる仕組みを提供している
• コンテキスト設計の実践とは、毎回長いプロンプトを書くのではなく、先に信頼できる資料を整えてAIが参照できる文脈を用意することである

■ 6. ワークフロー型AIエージェントの方向性

• AIエージェントは単体チャットツールから、業務ワークフローの中で動く存在へ移行しつつある
• 各ツールの特徴:
  • Dify: RAG・ワークフロー・エージェント・MCP/API連携を組み合わせた業務AIアプリ構築基盤。ノーコード／ローコードで現場担当者が構築可能
  • OpenClaw: 複数チャネル・ツールを横断して作業を実行する常駐型エージェント
  • Hermes Agent: 記憶やスキルを蓄積し、手順を再利用・改善していく常駐型エージェント
• 企業導入にはガバナンス設計が不可欠:
  • データ参照範囲・業務プロセスへの組み込み範囲の設計
  • SSO・権限管理・監査ログ・承認フロー・セキュリティの整備
• ローカルAI基盤（例: NVIDIA DGX Spark）を活用することで、機密データを外部に出さず社内で運用できる構成も現実的になりつつある
• ベテランのノウハウを"スキル"として整理・共有することで、組織内での継承が可能になる

■ 7. AIエージェント時代に価値を持つ人材像

• 「AIに仕事を奪われる」という単純な構図ではなく、AIを使って大きな成果を出せる人と、AIに置き換えられやすい人との差が広がる
• 注目される職種: FDE（Forward Deployed Engineer）
  • 別名「パランティア方式」とも呼ばれる
  • 顧客企業の現場に入り込み、業務課題を理解し、データ・AI・システムを組み合わせて実際に使える形にする
• FDE的人材に求められるスキル:
  • プログラミング力に加え、顧客業務・データ・現場制約の理解
  • セキュリティ・運用設計・導入後の改善
  • 関係者とのコミュニケーション
  • SaaS・API・既存システムとのMCP/AI連携の設計視点
• 価値が上がるのは、AIを「作る人」ではなく、AIを「現場で使える形に翻訳できる人」である

■ 8. まとめ: コンテキストを設計する時代へ

• AIエージェント時代に重要なのは、AIへの詳しさやプロンプト技術だけではない
• 重要な能力とは、AIに何をさせるかを定義し、必要なコンテキストを整え、成果が出る形に設計する力である
• どのツールにも共通する成否の鍵:
  • AIにどの文脈を与えるか
  • どの作業環境に置くか
  • どこまで任せ、どこから人間が確認するか
• AI活用はプロンプトを書く時代からコンテキストを設計する時代へと移行しており、それを設計できる人材が最も価値を持つ

(2026/06/23)

5万スターのClaude Code Tips集、本質は2つだけ

• 5万スターのClaude Code Tips集、本質は2つだけ

要約:

■ 1. リポジトリの概要

• shanraisshan/claude-code-best-practice はGitHub Trending 1位を獲得し、5万スター近くまで伸びているClaude Codeのベストプラクティス集
• 設定ファイルのテンプレート集ではなく、「Claude Codeをうまく使うための知識」をリンク付きで整理したリファレンス
• 構成:
  • 概念リファレンス（CONCEPTS）: Subagents / Commands / Skills / Hooks / MCP / Memoryなど各機能を一覧化
  • Tips & Tricks（82個）: Prompting / Planning / Context / CLAUDE.md / Agents / Hooksなど14カテゴリ、各Tipに出典リンク付き
  • 開発ワークフロー比較: Superpowers、Spec Kit、BMAD-METHODなど10以上の手法を比較表で掲載
• 作者のShayan Rais氏はAnthropicの社員ではなくコミュニティの個人
• 価値の源泉は、Boris Cherny（生みの親）、Thariq（エンジニア）、Cat Wu（プロダクト責任者）ら、Anthropic側の発信を一次情報として集約している点にある

■ 2. 大前提: 作り手の設定は「驚くほどバニラ」

• Boris Cherny自身が自分の設定を "surprisingly vanilla"（驚くほど素のまま）と表現
• Claude Codeはそのままでも十分機能するため、過度なカスタマイズは不要
• チームは「使う・カスタマイズする・ハックする」を自由に選べるよう意図的に設計しており、メンバー全員が異なる使い方をしている
• 「すごい設定を大量に積む」のではなく、必要最小限に保ち効果が確実なものだけを入れるのが作り手の思想

■ 3. 軸1: CLAUDE.md はシンプルに保つ

• なぜ短くするか:
  • CLAUDE.md は毎セッション先頭に丸ごと読み込まれる常駐メモリ
  • 公式ドキュメントは1ファイルあたり200行以下を目標に挙げており、長いファイルはコンテキストを消費し指示の遵守率を下げる
  • HumanLayerのDex氏は60行という実例を示しつつ「指示を100%守らせる保証はない」と注記
  • r/ClaudeCodeでは「CLAUDE.mdに書いた指示が80%無視される」という報告もある
• 短く保つための具体策:
  • .claude/rules/ への切り出しと遅延ロード:
    • paths: フロントマターを付けると、Claudeが該当globにマッチするファイルを読んだときにのみロード
    • ドメイン固有のルールをここに逃がすのが定石
    • paths: を持たないルールファイルはCLAUDE.mdと同様に毎セッション無条件で読み込まれる
  • 守られにくいルールは <important if="..."> タグで囲む
  • モノレポでは各パッケージにCLAUDE.mdを階層配置し、ルートに全部書かない
  • 「最低ライン」テスト: どの開発者でもClaude起動直後に「テストを実行して」と言えば一発で通る状態を目標とし、通らないならセットアップ・ビルド・テストの基本コマンドが欠けているサイン
• 「設定で決まること」をCLAUDE.mdに書かない:
  • 決定論的に設定できることをお願いベースの自然言語でCLAUDE.mdに書かない
  • 例: 「コミットにCo-Authored-Byを付けるな」と書くより settings.json の attribution.commit: "" で機械的に止める方が確実
  • CLAUDE.mdは「コンテキスト（お願い）」であって強制ではなく、確実に効かせたい挙動は設定やフックで担保する

■ 4. 軸2: ハーネスエンジニアリング

• ハーネスとは:
  • Claude本体ではなく、その周りを取り囲む足場・治具のこと
  • フック、権限設定、検証スクリプト、スラッシュコマンド、サブエージェントの総称
  • Borisの主張: 「モデルを賢くしようとするな、モデルが失敗しにくい仕組みを作れ」
• Claudeに「検証手段」を与える（Boris曰く最重要のTip）:
  • Claudeが自分の作業をその場で検証できる手段を渡すことで最終成果物の質が2〜3倍になる
  • テスト、型チェック、E2E、ブラウザ操作など「正解かどうか自分で確認できる経路」を与えると、Claudeは失敗を自分で見つけて直すようになる
  • /go スキルの例: (1) bash・ブラウザ・computer useでend-to-endにテスト → (2) /simplifyで整理 → (3) PRを作成
• フックで「最後の10%」を機械的に埋める:
  • BorisのPostToolUseフックの例: Write/Edit後に bun run format || true を自動実行
  • 「Claudeにフォーマットを守らせる」ではなく「フックで機械的に整える」という発想
  • 確率的な自然言語指示ではなく決定論的な後処理に落とす
  • 実用的なフックTip:
    • Stopフックでターン終了時に「続けろ・検証しろ」とClaude を促す
    • 権限リクエストをOpusに回して攻撃を自動スキャン・安全なものは自動承認させる
    • PreToolUseフックでスキルの使用回数を計測し、効いていないスキルを特定する
• 権限は「pre-allow」を使い --dangerously-skip-permissions は使わない:
  • 安全だと分かっているコマンドだけを /permissions で事前許可し .claude/settings.json にチェックイン
  • Autoモード（モデルベースの分類器が各コマンドの安全性を判定して自動承認）が全許可フラグの正しい代替

■ 5. 最小構成の例

• CLAUDE.md（短く・基本コマンド中心）:
  • プロジェクト概要を1〜2行
  • セットアップ・ビルド・テストの基本コマンドを列挙
  • 守られにくいものだけ <important> タグで囲む
• .claude/settings.json（決定論的に効かせるもの）:
  • フォーマット用のPostToolUseフック
  • 安全なコマンドの事前許可
  • attributionなど機械的に決まる設定
• .claude/rules/*.md（paths: で遅延ロード）:
  • ドメイン固有の細かいルール
• 役割分担の要点: 「お願い」はCLAUDE.mdに最小限、「強制」はsettings.jsonに

■ 6. Boris Cherny氏のCLAUDE.md（参考）

• ワークフローオーケストレーション:
  • 非自明なタスク（3ステップ以上や設計判断を含む）は必ずPlanモードで開始
  • サブエージェントを積極的に活用してメインのコンテキストウィンドウを清潔に保つ
  • ユーザーから修正を受けたら tasks/lessons.md にパターンを記録し、同じ失敗を繰り返さないルールを書く
  • 完了マークを付ける前に必ず動作を証明する
  • 非自明な変更では「より優れた方法はないか」と自問し、場当たり的な修正を避ける
  • バグレポートを受けたら自律的に修正する（ユーザーの手引きを不要にする）
• タスク管理:
  • 計画をチェックリスト形式で tasks/todo.md に書き、実装前に確認する
  • 各ステップでハイレベルなサマリーを提示し、修正後は tasks/lessons.md を更新する
• コア原則:
  • シンプルさ最優先: 変更は可能な限り小さくし、影響するコードを最小限にする
  • 手を抜かない: 根本原因を探り、一時的な修正を避け、シニアエンジニアの水準で対応する
  • 影響範囲の最小化: 必要な箇所だけを変更し、バグの混入を防ぐ

■ 7. 開発ワークフロー比較の要点

• 10以上の手法（Superpowers、Spec Kit、BMAD-METHODなど）はすべて同じ骨格に収束する
  • Research → Plan → Execute → Review → Ship
• Borisのセッション運用:
  • ほとんどのセッションをPlanモードで開始（Shift+Tab 2回）
  • コーディングはOpus + thinkingで実施（大きく遅いが、ステアリングが減る分結局速い）
  • 1日に何度もやる「インナーループ」はスラッシュコマンド化してgitにチェックイン
  • 1日1回以上やることはスキルかコマンドにする
• 「賢いプロンプトを毎回打つ」より「繰り返す作業を仕組みにする」という点でハーネスの思想と一貫する

■ 8. まとめ

• claude-code-best-practice は設定を丸ごとコピーするためのリポジトリではなく、Anthropicの作り手たちの一次情報を集約したリファレンス
• 核心は以下の2点:
  • CLAUDE.md はシンプルに: 長く書くより基本コマンドを揃え、ドメインルールは rules/ に逃がし、強制したいことは設定で機械的に効かせる
  • ハーネスを組む: Claudeを賢くしようとするより、Claudeが自分で検証・修正できる足場（検証手段・フック・権限設計）を整える
• Boris Chernyが "surprisingly vanilla" と言うのは、「設定を盛る」のではなく「失敗しにくい仕組みを作る」という引き算の設計思想の表れ
• リポジトリを見るなら、まずTips & Tricksの「CLAUDE.md」と「Hooks」カテゴリから確認するのが効率的

(2026/06/23)

LanceDB

• LanceDB | AI-Native Multimodal Lakehouse

MEMO:

• Rust製のベクトルDB

(2026/06/23)

FFmpegとQEMUを開発したフランスのプログラマー「ファブリス・ベラール」とは何者なのか？

• FFmpegとQEMUを開発したフランスのプログラマー「ファブリス・ベラール」とは何者なのか？ - GIGAZINE

要約:

■ 1. 概要と評価

• id Softwareの共同設立者ジョン・カーマック氏が「ほぼ間違いなく、彼は私よりも総合的な実力のあるプログラマーだ」と称賛し注目を集めた人物
• FFmpeg、QEMU、Tiny C Compiler、QuickJSなど、現在も広く使われる基盤ソフトウェアを個人または少人数で立ち上げた実績を持つ

■ 2. 経歴と技術的背景

• 1972年にフランスのグルノーブルで生まれ、エコール・ポリテクニークで学んだコンピューター科学者
• 若い頃から圧縮・コンパイラ・エミュレーション・映像処理・数値計算などの低レイヤー領域で成果を残す
• 17歳の時点で実行ファイル圧縮ツール「LZEXE」を作成した実績を持つ

■ 3. 主な業績

• FFmpeg（2000年）:
  • 動画・音声のエンコード、デコード、変換、ストリーミングを扱うオープンソースのマルチメディア処理フレームワーク
  • 動画配信やメディア処理の現場で広く使われる基盤ソフトウェアとなっている
  • ベラール氏はすでに20年以上開発に関わっておらず、現在は多くの開発者による長年の改良で成立している
• QEMU（2003年）:
  • 異なるCPUアーキテクチャやOS環境をエミュレートするマシンエミュレーター兼仮想化ソフトウェア
  • 現在の仮想化技術や開発・検証環境において重要な役割を果たす
  • 初期バージョン0.7.1までベラール氏がほぼ単独で開発したとされる
• Tiny C Compiler（TCC）:
  • 2001年にInternational Obfuscated C Code ContestでCコンパイラにより受賞
  • LinuxカーネルをソースからiOS15秒未満でコンパイルして起動するデモで知られる
• JSLinux（2011年）:
  • JavaScriptだけでLinuxをブラウザ上で動かすPCエミュレーター
• QuickJS（2019年）:
  • 小型ながら完全なJavaScriptエンジンを目指して開発されたソフトウェア
• 近年の成果:
  • ニューラルネットワークを使う可逆圧縮ツール「NNCP」
  • 大規模言語モデルを使ったテキスト圧縮ツール
  • 低ビットレート音声圧縮「TSAC」
  • マイクロコントローラー向けJavaScriptエンジン「Micro QuickJS」

■ 4. 数値計算分野での業績

• 本来高価なスーパーコンピューターで行われる円周率計算をデスクトップPCで実行し、約2兆7000億桁を計算して当時の世界記録を更新した

■ 5. Amarasoft共同創業

• 2012年に通信ソフトウェア企業Amarasoftを共同創業し、CTOを務める
• 4G LTEや5G NRなどの基地局ソフトウェアを標準的なPC上で動かす製品を展開
• 関心がメディア処理・仮想化から通信インフラへと広がっていることを示す

■ 6. 業績の特徴と評価をめぐる議論

• Hacker Newsでの見解:
  • ベラール氏の業績は「仕様をC言語に落とし込んだ」ことと整理できるという指摘がある
  • FFmpeg: コーデック仕様
  • QEMU: 命令セット仕様
  • QuickJS: ECMAScript仕様
  • Tiny C Compiler: C言語仕様
  • Amarasoft: LTE・5G仕様
• 反論:
  • 仕様があるからといって実装が機械的に決まるわけではないという意見も存在する
  • コーデックやエミュレーターを高速かつ正確に動作させるには、アルゴリズム設計・最適化・例外処理・互換性への深い理解が必要であり、それこそがベラール氏の評価すべき業績だと指摘されている

(2026/06/23)

SIerのウォーターフォール開発をスキル化して、AI駆動開発しやすい形に再構成する

• SIerのウォーターフォール開発をスキル化して、AI駆動開発しやすい形に再構成する

要約:

■ 1. 背景と課題

• SIerの現場ではウォーターフォール型開発プロセスが長年にわたり標準化されており、豊富なドキュメント資産が存在する
• 標準プロセスには以下の課題がある:
  • 習得コスト: プロセスを使いこなすまでの習熟に時間がかかる
  • 属人化: 担当者のスキルや経験によって成果物の品質にばらつきが生じる
  • フォーマット: 標準資産の多くがWord/Excel中心であり、AI活用に不向きである
• Word/ExcelのOffice文書はAI駆動開発においてボトルネックになる:
  • AIエージェントがバイナリファイルを直接参照できない
  • セルの結合・書式・図の多用によりテキスト抽出が困難
  • Gitなどのバージョン管理システムとの相性が悪く、差分管理ができない
  • プロンプトやスキルのリファレンスとして直接組み込めない

■ 2. 事前準備: 資産のマークダウン化

• Office文書ベースの資産をマークダウン形式へ変換することが大前提となる
• 目的は単なるファイル形式の変換ではなく、AIエージェントが参照・再利用・差分管理しやすい形への再編成である
• Anthropicの公式リポジトリにPDF/PPT/Word/Excel対応のエージェントスキルが公開されており、これを活用して変換する
• 図やフローなどMermaidで表現できる情報はMermaidで記述することで、マークダウン資産として再利用しやすくなる

■ 3. エージェントスキル化の方針

• 標準プロセスの成果物を以下の2種類に分類し、それぞれ異なるスキル方針をとる:
  • 定義書・作成フローなし（超上流成果物、複数人の対話が必要な資料など）:
    • AIエージェントとの対話を通じて探索的に成果物を作るスキルとする
  • 定義書・作成フローあり（要件定義以降の成果物、外部設計書・内部設計書など）:
    • 工程別に定義・フロー・フォーマットを参照する標準スキルとする
• 2種類のスキルを組み合わせることで、ウォーターフォール型開発全体をカバーするパイプラインを構成できる

■ 4. 作成したエージェントスキルの詳細

• 「定義書・フローなし」パターンのスキル:
  • Anthropic公開のdoc-coauthoringスキルをベースに、上流工程向けの参考資料や観点を追加して構築
  • スキルは以下のステップで対話しながら成果物を作成する:
    • ステップ1（コンテキスト収集）: AIがヒアリングを通じて背景・目的・制約条件を整理する
    • ステップ2（構成検討・ドラフト作成）: アウトラインを提案し、セクションごとにドラフトを生成・修正する
    • ステップ3（読者テスト）: 別のエージェント視点で疑問点や改善点を洗い出す
  • VS CodeのLive Share機能と組み合わせることで、複数人とAIエージェントが共同で成果物を作成できる
• 「定義書・フローあり」パターンのスキル:
  • スキル構成はSKILL.md、references/（成果物定義・作成フロー）、assets/（フォーマット）で構成する
  • 各ファイルの役割:
    • SKILL.md: 成果物に応じて定義・フロー・テンプレートを参照するエントリーポイント
    • 成果物定義.md: 目的、記載項目、記載粒度、完成条件を定義
    • 成果物作成フロー.md: 作成手順、前提、入力情報、作成順序、確認観点を定義
    • 成果物フォーマット.md: 成果物のテンプレートを定義
  • スキル化により期待される改善:
    • 属人化の解消: 定義・フロー・フォーマットをスキル側に持たせることで、一定の品質と粒度を保ちやすくなる
    • 習熟コストの低減: スキルが手順や観点をガイドするため、標準プロセスへの習熟を待たずに着手できる

■ 5. 今後の展望

• フェーズゲートの取り入れ:
  • 現時点では成果物のYAMLフロントマターでステータス（draft→review→approved→baselined）を管理
  • 今後はステータスチェック用スクリプトをスキルに組み込み、次工程へ進めるかどうかを評価する仕組みを導入予定
  • 実現することで成果物生成だけでなく、フェーズゲートを含む開発プロセス全体の運用支援をスキル側で扱えるようになる
• 共通スキル実行環境の提供:
  • 現時点は個人のローカル環境での利用を想定しているが、実プロジェクトでは複数人が工程を分担する
  • 複数人が共通で利用できるエージェントスキル実行基盤の整備が必要

■ 6. まとめ

• ウォーターフォール型開発プロセスは「人が作ることを前提」として設計されており、単純なスキル化だけでは不十分
• 一方で、長年蓄積された標準資産をマークダウン化し、エージェントスキルとして再構成することで、人とAIが協調して扱える形へ変えていく余地は十分にある
• こうした取り組みが「人とAIが共に作ることを前提」とした新たな開発プロセス創出のきっかけになることを期待している

(2026/06/23)

AIに仕様書を書かせるベストプラクティス 2026

• AIに仕様書を書かせるベストプラクティス 2026 #AIエージェント - Qiita

(2026/06/23)

「ドキュメント書いて」はもう古い。AIに4種類のドキュメントを「コードから自動生成」させる実践ガイド

• 「ドキュメント書いて」はもう古い。AIに4種類のドキュメントを「コードから自動生成」させる実践ガイド #ClaudeCode - Qiita

(2026/06/23)

みずほ、「朱肉を用いた押印」廃止

• みずほ、「朱肉を用いた押印」廃止 - Impress Watch

みずほ銀行、みずほ信託銀行は、両行名義の各種証明書・請求書等の書類における銀行名義の「朱肉を用いた押印」を順次廃止し、電子印影の利用または押印のない書式への見直しを進める。

デジタル社会への移行や、迅速かつ柔軟な顧客対応の一環。押印のために発生していた確認・回付等の事務プロセスに伴う待機時間を解消し、書類作成から発送までの所要時間の短縮を図る。対象となる書類や開始時期は、書類の種類によって異なる。

法令・制度上の要請等により、朱肉を用いた押印が必要となる場合には、従来どおりの取り扱いとなる。また、押印の有無にかかわらず、これら書類に記載された事項については、両行の内部記録によりその正確性等が確認・記録され、必要に応じた再確認が可能なことについては従来と変わりはない。

MEMO:

• おぉー

(2026/06/23)

ゼロをイチにする仕事の終わり、ソフトウェアエンジニアという仕事の終わり

• ゼロをイチにする仕事の終わり、ソフトウェアエンジニアという仕事の終わり - smasato.log

要約:

■ 1. コードは「書くもの」から「生成されるもの」へ

• ソフトウェアエンジニアの主要業務であった「ゼロをイチにする実装作業」はAIに置き換えられつつある
• 初期のAIはGitHub Copilotのような行補完ツールだったが、現在ではコード生成と自動レビューによるフィードバックループが主流になっている
• コードを人間が一行ずつ書いて確認する時代は終わりつつある
• 本記事は2026年6月21日時点での個人の見解である

■ 2. 加速した実装、停滞した前後フェーズ

• 生成AIによってSDLC(ソフトウェア開発ライフサイクル)における具体的な実装は大きく加速した
• 加速の結果:
  • 実装前フェーズ（「何を開発するか」の意思決定）の停滞が目立つようになった
  • 実装後フェーズの停滞も顕在化してきた
• 「何を開発するか」が決まるのを待っているだけのエンジニアは不要になっていく
• 業務委託形態の経済合理性:
  • 業務委託は「指示を待つ」「指示をする」というやり取りが必然的に発生する
  • 人間への指示はAIへの指示のように即座・大量には出せない
  • ソフトウェアエンジニアの業務委託を増やすことの経済合理性は低下していく

■ 3. AIを待たせない開発環境の健全性

• AIエージェントが待つ時間・待った結果として修正する時間の削減が必須になる
• CI（継続的インテグレーション）の観点:
  • CIの高速化はもちろん、フレーキーなCIはAI・人間双方のコストを増大させる
  • 開発環境の健全性がAIエージェントの効率・コスト・成果に直結する
  • これは個人のローカル開発環境を超えた、より広い範囲の問題である
• AIの作業待ち時間の解消:
  • AIの待ち時間と、人間がAIの作業完了を待つ時間はどちらも同様に無駄である
  • 人間が作業の起点になっていることが、待ち時間が大きくなる主な原因
  • AIの作業開始は今後自動化されていく
  • 人間が逐一指示しなくてもAIが作業を完了できる状態を目指すべきである

■ 4. ガードレールは自然言語の外側で強制する

• ガードレール・ハーネスは自然言語を超えたレベルで実装する必要がある
• 実装手段の例:
  • コード: Git Hookによる強制
  • 日本語テキスト: textlintのような、解釈の余地なく実行を強制する仕組み
• ガードレールの要件:
  • 高速かつ正確に実行されなければならない
  • 人間による既存のルール違反は残存させてはならない
  • 人間のルール違反はAIによって高速に増幅されてしまうため
• BiomeやtextlintやKnipのようなツールが、AIにも人間にも同じルールを強制する役割を担う

■ 5. 局所最適化はボトルネックを移動させるだけ

• 局所最適化はボトルネックを移動させ、新たなボトルネックを生むだけになりがちである
• 開発だけを効率化しても、ビジネス全体は加速しない
• 全体最適を阻害する要因:
  • 古いパラダイムの人間が一人いるだけで、全体の最適化が無効化される可能性がある
• 全体最適のためには全領域に入り込み全体像を理解した上で仕組みを構築する必要がある
• 単一のボトルネックを改善しても大きな変化は生まれず、別の場所にボトルネックが移るだけである

■ 6. 律速になる組織構造

• 階層構造による組織管理は機能しなくなっていく
• 階層構造の問題点:
  • 人間の指示を受けて人間が作業する入れ子構造は、レビューやフィードバックループを大きく遅くする
  • 管理が必要な人間を減らし、フラットな組織にしなければ組織構造が律速になる
• AIの活用は開発組織内に閉じた問題ではなく、組織全体の問題であり、最終的には「人数」の話に帰着する
• 「AIが活用されていない」「変化が感じられない」のはAIツールの問題ではなく組織的な問題である可能性が高い
• 「ゼロをイチ」にすること自体はワンクリックで高速・安価に実行できるようになっており、やらないのは完全に人間側の問題である
• 前に進まない理由を探すのではなく、自分自身の考え方や仕事の仕方を改めるべきである

■ 7. パクられない強みを持てるか

• アイデアはAIによって高速・容易にコピーされるようになる
• パクられない強みを持たない企業はゆるやかに死んでいく
• スイッチングコストの変化:
  • 既存の契約・関係性がユーザーをつなぎ止める鎖になってきたが、そのスイッチングコスト自体もAIによって低下する
  • 「スイッチングしてもらうための努力」と同等に、「スイッチングされないための努力」が必要になる
• スイッチングされない自信や仕組みがあるからこそ提供できる機能が存在する（例: マネーフォワードのAI Cowork）
• 大企業はその強みを活かして動くべきである

■ 8. 残るのは「方向を決める」仕事

• 方向性が決まった後の「ゼロをイチにする作業」はAIに置き換え可能であり経済合理性もある
• 人間に残る仕事:
  • ゼロ点からどの方向に進むか（ベクトル）を決める仕事
  • 無限の選択肢を絞り込み、実行可能な単位に分割すること
• AIへの作業指示に必要なもの:
  • 組織やプロダクトのコンテキスト・ナレッジ
  • それを機械可読な状態に整理し、維持し続けること
  • 特定の場所に整理された状態で保持することがトークン・時間効率の面で望ましい
• DevinのようなAIエージェントの高性能の背景には、インデックスされ自動更新されるWikiやナレッジの存在がある

■ 9. 「あとはやるだけ」の状態を整え続ける

• 今後の人間の仕事は以下のループに集約されていく:
  • 「あとはやるだけ」の状態を整える
  • AIに「あとはやるだけ」を実行させる
  • 次の「あとはやるだけ」の状態を整える
• 「あとはやるだけ」状態をつくるための要件:
  • 方向性の提示と完了条件の付与
  • AIが実行時に迷わない・余計なことをしないように整える
  • AIの成果物を修正しなくてよい状態にする仕組みをつくること
• AIに実行させる「手前」を整えることが、これからの仕事の中心になる

■ 10. 「ソフトウェアエンジニア」という名前の限界

• これまでのソフトウェアエンジニアは細分化・専門深化の方向にあった（領域の複雑化・高度化が背景）
• AIによる変化:
  • 特定領域の仕事が効率化・短縮化され、特定領域に閉じた専門家は少人数でよくなる
  • 複数の専門を持つ人間が単一領域の専門家を置き換える可能性がある
  • フロントエンド・バックエンド双方をこなせる人間がいれば、役割分担する二人は不要になる
  • 役割分担による属人性の問題（片方がいなくなると開発が止まる）も解消されていない
• 全体最適化に必要なもの:
  • 領域ごとの個別最適化では全体最適にはならない
  • 全体を見て最適化する人間が必要になる
  • その役割は「ソフトウェアエンジニア」の延長線上には存在しないかもしれない
• 命名の問題:
  • 「ソフトウェアエンジニア」という名前は適切でなくなってきているかもしれない
  • 「プロダクトエンジニア」も、会社のすべてがプロダクトではないため適切ではない
  • この役割の適切な名称・構造についての答えはまだ出ていない

■ 11. 変化しないことが、明確なリスクになる

• 「ソフトウェアエンジニア」という役割のみを担い続けることは、今後できなくなっていく
• 評価基準の変化:
  • より広いスキルでAIを使いこなす人間が出現し、そのような人間のほうが評価されるようになる
  • そのような評価基準を持てない会社はいずれ他社に負ける
  • 現状維持でも評価される環境では変化するインセンティブが生まれないが、今変化しないことは明確なリスクである
• 変化に対応する会社が生き残ることは、歴史を見れば明らかである
• 「ゼロをイチにする」作業はもはやAIのほうが上手く速くこなせる
• ゼロをイチにしてきた経験の価値:
  • 現時点では、その経験がAIの使い方に影響する
  • しかし最終的には不要になる可能性がある
  • 根本的に世界が変わってしまったためである

MEMO:

• 別に終わったような感覚は無いのだが
• それはそれとして、自分の思い付きで好きなように作って面倒も見ずに転職するというカウボーイエンジニアの時代は終わったという意味なら同意できるかもしれない

(2026/06/22)

設計するとは、何を諦めるかを決めること

• 設計するとは、何を諦めるかを決めること - 理念と共に、最も困難で狂気の選択を考え続けて諦めない

要約:

■ 1. 問題提起: 実装詳細と設計判断の境界

• ボタンの「押下」という表現が曖昧であったため、mousedownイベントで実装されトラブルになった事例を起点とする
• 実装方法によって守られる性質が変わる場合、その選択は単なる実装詳細ではなく、設計時点でレビューできる形にすべきである

■ 2. mousedown と click の違い

• mousedown:
  • ボタンを押し込んだ瞬間に処理が開始される
  • その後ポインターをボタン外へ移動しても処理は取り消せない
  • ドラッグ開始など、押し込んだ時点での反応が適切なケースに向く
• click:
  • クリック操作が成立した時点で処理が実行される
  • 押し込み後にポインターをボタン外へ移動して解放した場合は処理が開始されない
  • 購入・送信・削除など取り消しにくい操作に適する
• どちらが常に正しいかではなく、選択によって振る舞いが変わる以上、それは設計上の判断である

■ 3. 設計書への記述方針

• 意図が明確な場合:
  • 外部から観測できる振る舞いと想定する実装の両方を記述する
  • 例: 「ボタン上でポインターが押し込まれた時点で処理を開始する。ポインターを外へ移動して解放しても処理は取り消さない」
• 実装方法が未確定な場合:
  • 外部から観測できる振る舞いや守るべき性質を記述する
• 共通の目的:
  • レビューに参加する人が同じ振る舞いを想定できる粒度まで具体化し、認識の齟齬を減らす
• 「押下」とのみ記述するのは、設計上の判断を文書に落とせていない状態である

■ 4. Design Doc に書くべき内容

• 「何を実装するか」だけでなく、以下を明示する:
  • 何を守るのか
  • 何を許容するのか
  • なぜその選択をしたのか
  • 別の選択肢を採らなかった理由
• 目的はすべての実装方法を固定することではなく、暗黙の前提をなくしてレビューの対象にすること
• 冪等性の例:
  • 「冪等にする」と書くだけでは何について冪等性を保証するか不明である
  • 重複を許容する場合は何が重複し得るか、なぜ許容できるか、重複時の扱いを記述する
  • 重複を許容しない場合はどの状態遷移や副作用について重複を防ぐか、守るべき条件を記述する
• 設計判断が文書に現れていない場合、レビュアーは正常系の構成しか確認できない

■ 5. 設計におけるトレードオフ

• 設計とは、制約の中で何を守り、何を諦めるかを決めることである
• すべてを守ろうとすれば実装・運用が複雑になり、開発速度・性能・可用性など別のものを失う
• 何を保証し、何を許容し、そのために何を諦めたかを明確にする必要がある
• Design Doc は、判断と想定される失敗を暗黙の前提にせず、レビュー参加者が同じ前提に立ち設計の妥当性を確認できる形にするための文書である

(2026/06/22)

Steering Claude Code: skills, hooks, subagents and more

• Steering Claude Code: skills, hooks, subagents and more | Claude

要約:

■ 1. 概要

• Claude Code には AI の動作を制御するカスタマイズ方法が7種類存在する
• 各方法はコンテキスト読み込みのタイミング、圧縮時の動作、コスト（トークン消費）の観点で異なる

■ 2. 7つのカスタマイズ方法

• CLAUDE.md ファイル:
  • 設定場所: プロジェクトルートまたは任意のサブディレクトリに CLAUDE.md を配置
  • 読み込みタイミング: セッション開始時に常時読み込み
  • 圧縮時の動作: メモ化・キャッシュされた後に再読み込み
  • コスト: 高（関連性の有無に関わらず全行がトークンを消費）
  • 用途: ビルドコマンド、ディレクトリ構造、モノレポレイアウト、コーディング規約、チームの慣例
  • ルートの CLAUDE.md は全セッションで読み込まれ、サブディレクトリの CLAUDE.md はその領域がアクセスされたときのみコンテキストに入る
  • チームごとのファイルは200行未満に保つことを推奨
• ルール:
  • 設定場所: .claude/rules/ ディレクトリ以下にファイルを配置
  • 読み込みタイミング: セッション開始時（スコープなし）またはファイル照合時（パススコープ付き）
  • 圧縮時の動作: 再注入される
  • コスト: 中程度
  • 用途: 特定の制約や規約（例: 「すべての API ハンドラは Zod で入力検証が必須」）
  • paths: フロントマターフィールドによるパススコープ指定で、関連時のみロード可能
• スキル:
  • 設定場所: .claude/skills/ 以下にフォルダを作成し、各フォルダ内に SKILL.md を配置
  • 読み込みタイミング: 名前と説明はセッション開始時、本文は実行時にロード
  • 圧縮時の動作: 起動されたスキルは共有予算内で再注入（古いものから削除）
  • コスト: 低（実行時のみロード）
  • 用途: デプロイメント手順やリリースチェックリストなどの手続き的ワークフロー
  • スラッシュコマンド（例: /code-review）で起動
• サブエージェント:
  • 設定場所: .claude/agents/ ディレクトリ以下に YAML フロントマター付きマークダウンファイルを配置（name、description、model、tool access を指定）
  • 読み込みタイミング: メタデータはセッション開始時、本文は実行時にロード
  • 圧縮時の動作: 最終メッセージのみを親セッションに返却
  • コスト: 最小（呼び出すまでコスト0）
  • 用途: 深い検索、ログ解析、依存関係監査など、並列実行または分離実行すべき補助タスク
  • 独立したコンテキストウィンドウで実行され、最終結果のみが戻る
  • 最大5レベルまでネスト可能
• フック:
  • 設定場所: settings.json、ポリシー設定、またはスキル・エージェントのフロントマター内に登録
  • 読み込みタイミング: ライフサイクルイベント時に起動
  • 圧縮時の動作: 圧縮をバイパス
  • コスト: 低（メインコンテキスト外で動作）
  • 用途: 決定論的な自動化（リンター実行、Slack への送信、コマンドブロック）
  • 「PreToolUse」フックはツール呼び出しを検査し、終了コード2で拒否可能
• 出力スタイル:
  • 設定場所: .claude/output-styles/ ディレクトリ以下にファイルを配置
  • 読み込みタイミング: セッション開始時、システムプロンプトに注入
  • 圧縮時の動作: 圧縮されない
  • コスト: 高（コンテキスト占有、デフォルトプロンプトを上書き）
  • 用途: 大幅な役割変更（例: 「コード補助から汎用補助へ」）
  • ビルトインの Proactive、Explanatory、Learning スタイルで多くのニーズに対応可能
• システムプロンプト追加フラグ:
  • 設定場所: CLI 起動時に --append-system-prompt フラグで指定
  • 読み込みタイミング: 呼び出し時のみ（そのセッション限定）
  • 圧縮時の動作: 圧縮されない
  • コスト: 中程度（プロンプトキャッシングで軽減）
  • 用途: コーディング規約、出力形式設定、ドメイン知識

■ 3. 実装上のヒント

• 「毎回 X をしたら必ず Y する」という処理にはフックを使用（自動実行の方が確実）
• 絶対禁止事項の強制にはフック＋権限管理を使用（プロンプトより確実）
• 30行程度の手続き内容はスキルに記述（CLAUDE.md より効率的）
• API 固有ルールには paths: でスコープ指定を行う
• 個人設定はプロジェクトレベルではなくユーザーレベルで管理

■ 4. よくある誤り

• 過度な CLAUDE.md の肥大化: チームごとのサブディレクトリ CLAUDE.md で分散させて対応
• パススコープなしのルール設定: 不要な場面でも常にロードされ、トークンを無駄に消費
• 手続き的内容を CLAUDE.md に記述: スキルに移行することで効率化
• 個人設定を共有リポジトリに保存: ローカル設定（ユーザーレベル）を使用

(2026/06/22)

ソフトウェア開発をシンプルにする技術

• ソフトウェア開発をシンプルにする技術 - プププなテクブ

要約:

■ 1. 著者と背景

• 著者 Dave Thomas は『達人プログラマー』の共著者であり、アジャイルソフトウェア開発宣言の署名者
• Dave は "Agile is Dead" と発言したことでも知られる
• 本書『シンプリシティ』を読む前に、巻末の訳者あとがきを先に読むことが推奨されている

■ 2. "Agile is Dead" の主張

• 背景:
  • 本来、形容詞（機敏な）であった「アジャイル」がビジネス上の利益のために名詞化された
  • 名詞化により、本来の柔軟性・適応性が失われ、認証制度・厳格なルール・恐怖心に基づくコンサルティングが蔓延した
• Dave が提唱した真の敏捷性（Agility）を取り戻すための4ステップ:
  • 現状把握: 自分が今どこにいるのかを正確に理解する
  • 小さな一歩: 目標に向けて小さな一歩を踏み出す
  • 評価: その一歩の結果、何が起きたかを分析し、学習する
  • 繰り返し: 上記のプロセスをフラクタルに繰り返す
• 結論: 現場の人間こそが問題と解決策を知っており、形通りのプロセスに依存せず自分たちの文脈に合わせた機敏性を追求すべき

■ 3. Simplicity の概念

• Agility を実践するには、開発者が自分の仕事を自律的に進める Agency（主体性）が重要
• 「自分の目の前にある複雑さを減らすこと」が仕事の進め方を軽くするという考えに到達したものが Simplicity
• Dave による Simplicity の定義: 理解しやすく、変更しやすく、「しっくりくる」感覚を生み出す状態
• Simpler な方法の条件:
  • CよりもSの方が理解しやすい
  • CよりもSの方が部品が少ない
  • CよりもSの方が問題をより直接的に表している

■ 4. Simplicity へのアプローチ

• 方向を見定め: 複雑すぎると感じる何かを見つける
• 一歩進み: アイデアを試すためにできる最もシンプルなことを見つける
• 学び
• ふりかえる
• このアプローチは "Agile is Dead" で述べられた Agility の概念と同一であり、本書は Dave 自身の Agility の具体的な方法論を集めたもの

■ 5. 不健全な依存関係の削除

• left-pad 事件の教訓: わずか11行のコードは依存関係であってはならない
• ライブラリを導入するかどうかの判断基準:
  • その機能は必要か
  • コーディングする方が簡単か
  • ジャングルを買っていないか
  • プロジェクトにとって代替不能か
  • 特定のバージョンにロックされているか
  • 安全か

■ 6. フレームワークは機能を追加し続ける

• フレームワークが与える選択肢には、必要としていないものも含まれる
• すべてのオプションと機能には、複雑さ・依存関係・肥大化という代償が伴う
• 未使用の機能は将来のセキュリティホールになる可能性がある
• コードよりもフレームワークの維持に多くの時間を費やしているなら、そのフレームワークは助けになっていない
• 必要なことをこなしつつ、機能が最も少ないフレームワークを選ぶべき
• 著者はKotlinバックエンドにおいてSpringよりKtorを、JS/TSバックエンドにおいてHonoを好む理由として、この主張を挙げている

■ 7. 作らずに済んだ機能こそ最高の機能

• 機能とは、将来の負債を意味するマーケティング用語
• 「誰かが必要としない限り、コードを書くな」がソフトウェアをシンプルに保つ基本ルール
• 「xxだったらクールじゃない？」「xxを追加するのは簡単だろう」はニーズではない
• 機能ではなく、インクリメンタルな価値を提供することが重要（ニーズ駆動開発）

■ 8. コメントは基本的に悪き習慣

• コードを変更すると関連するコメントも修正が必要になり、作業が2倍になる
• コメントを追加する正当な理由は以下の3つのみ:
  • コメントを抽出してドキュメントを作成するツールを使用している場合
  • コードの将来の読者に、予想外の実装方法を選んだ理由を伝える必要がある場合（Why not）
  • TODOやその他のフラグを追加するため
• TODOはプロダクションに存在すべきでないため、できるだけ早く消すようプレッシャーをかけることが重要

■ 9. まとめ

• 本書は「理解しやすく、変更しやすく、しっくりくる状態とはどういう状態か」を Dave 自身の実践例を通して学ぶための本
• Agility の4ステップ（現状把握・小さな一歩・評価・繰り返し）がもたらす結果を理解するための内容

(2026/06/21)

時雨堂のスキル

• 時雨堂のスキル

要約:

■ 1. 概要

• 本記事は2026年6月時点での時雨堂の採用スキルを紹介したものであり、固定的な内容ではない
• SKILL.mdとはLLMに与える詳細な指示文書のこと
• 「レビューして」のような単純な指示ではなく、具体的な方法論を長文で記述したもの
• 時雨堂はこのスキルを多用して開発を行っている

■ 2. 時雨堂のスキル一覧

• スキルの管理方針:
  • 時雨堂のスキルは非公開
  • 社内で利用可能なスキルは時雨堂が管理するスキルのみ
  • 個人で作成したスキルの利用は許可されている
• 技術基盤スキル:
  • shiguredo-git: コミット規約とブランチ命名規則を定義し、git操作はこのスキルを経由する
  • shiguredo-issues: GitHubのIssueは利用せず、リポジトリ内の issues/ ディレクトリでIssueを管理するためのスキル
  • shiguredo-changelog: CHANGES.md への変更履歴記載ルールを定めるスキル
• 言語別スキル:
  • shiguredo-erlang: 第一公用語であるErlang/OTPに関するノウハウをまとめたスキル
  • shiguredo-python: pytestをメインとし、nanobindやPyO3に関するノウハウをまとめたスキル
  • shiguredo-rust: Rustに関するスキルで「使うな系」のルールが多い
  • shiguredo-typescript: ブラウザ向けのみで利用するTypeScriptに関するスキルで、ViteやPreactなど採用ライブラリの情報を含む
• Issue管理スキル:
  • create-issue: issues/ 配下に新規Issueを作成するスキルで、template.mdによりIssueの個性を排除する
  • polish-issue: コアスキルの一つで、IssueをIssueだけで実装可能なレベルまで磨き上げる（Opus 4.7使用時は最短30分以上を要する）；レビュー・調査・試験実装もこの段階で実施する
  • triage-issues: 古くなったIssueを破棄するか判断するスキルで、定期的に実行することでIssueの放置を防ぐ
• コードレビュースキル:
  • review-diff-code: コアスキルの一つで、ブランチの差分をレビューする；PR提出前またはPush前に必須で、最低3周・最大5周、7つの観点からレビューを実施する
  • review-code: メインブランチのコードをレビューし課題を洗い出すスキル
• 運用補助スキル:
  • update-skills: 非技術者向けにスキルを最新状態に更新するためのスキル

■ 3. AGENTS.mdの位置付け

• AGENTS.mdはシンプルな内容であり「この場合はこのスキルを使え」と記載する
• LLMはAGENTS.mdを通じてスキルを適切に参照できている

■ 4. スキルを活用した開発フロー

• フローの各ステップ:
  • create-issueスキルでIssueを作成する
  • polish-issueでIssueを磨き上げる（磨いたIssueを人間がレビューする）
  • Issueを実装する（実装方法・ブランチ名などはすべてIssueに記載されている；自動実装スキルも存在するが利用は非推奨）
  • 実装完了後にreview-diff-codeでレビューする
  • Pull-Requestを提出する（自己レビュー後、人間によるレビューを依頼する）
  • CIが通ったらマージする
• 人間の主な役割は「判断」に集約されつつある

■ 5. まとめ

• スキルの効果は明確で、スキルをインストールしていないメンバーがLLMを「あり得ないくらいバカ」と感じた事例が示すように、スキルの有無で性能に顕著な差が生じる
• スキルは積極的にメンテナンスされており、毎日改善が行われている

MEMO:

• めっちゃよい

(2026/06/21)

How the Open Knowledge Format can improve data sharing

• How the Open Knowledge Format can improve data sharing | Google Cloud Blog

(2026/06/21)

Googleが公開したAIエージェント向け知識共有フォーマット『OKF』を触ってみた

• Googleが公開したAIエージェント向け知識共有フォーマット『OKF』を触ってみた | DevelopersIO

要約:

■ 1. OKFの概要

• 2026年6月12日にGoogle Cloudが公開したAIエージェント向け知識共有フォーマット
• 組織のナレッジをYAMLフロントマター付きMarkdownファイルのディレクトリ構造で表現するベンダー中立なオープン仕様
• 仕様書（SPEC.md）は約450行、リポジトリはGitHubで公開（GoogleCloudPlatform/knowledge-catalog/okf）
• 設計思想は3点:
  • 最小限の意見性: 必須フィールドはtypeのみ、それ以外はプロデューサーに委任
  • プロデューサー/コンシューマー独立性: 人間の手書き、DBエクスポート生成、LLM読み込みなど任意の主体が利用可能
  • フォーマットであってプラットフォームではない: 特定クラウド・SDK・ランタイム不要

■ 2. OKFが登場した背景

• AIエージェントが業務に回答するには散在するコンテキストの統合が必要
• 知識の断片化の現状:
  • メタデータカタログ（各社独自API）
  • Wiki・サードパーティシステム・共有ドライブ
  • コードコメント・docstring・ノートブック
  • シニアエンジニアの暗黙知
• ベンダーごとに独自のカタログ・SDK・スキーマが存在し、エージェント構築者が毎回同一の「コンテキスト組み立て問題」をゼロから解いている状況が課題
• OKFは翻訳レイヤー不要で書く側と読む側を分離できる共通フォーマットとして断片化を解消する試み

■ 3. フォーマット仕様

• バンドルの基本構造:
  • OKFバンドル = コンセプトを表すMarkdownファイルのツリー
  • 1コンセプト = 1ファイル、ファイルパスがそのコンセプトのIDとなる
  • ディレクトリ構造はドメイン非依存で、組織の仕方はプロデューサーが決定
• YAMLフロントマターのフィールド:
  • type（必須）: コンセプトの種類。中央レジストリへの登録なし、プロデューサーが自明な値を選択
  • title、description、resource、tags、timestamp（すべて推奨・任意）
• Markdown本文とグラフ構造:
  • 本文は自由記述。通常のMarkdownリンクでコンセプト同士を相互参照し、リレーショングラフを形成
• 予約ファイル名:
  • index.md: ディレクトリ内容の列挙（段階的開示用、frontmatterなし）
  • log.md: 変更履歴（ISO 8601日付見出しでグループ化）
• OKF v0.1準拠の条件:
  • すべての非予約.mdが解析可能なYAMLフロントマターを持つ
  • すべてのフロントマターが空でないtypeを持つ
  • 予約ファイルが規定の構造に従う
  • コンシューマー側は欠けたオプションフィールド・未知のtype・壊れたリンクに対して寛容であることをSPECが規定

■ 4. 関連標準との関係

• OKFは既存の標準と競合するのではなく「積み重なる（stack）」関係にある
• 各標準の役割:
  • OKF: キュレートされた静的な知識をファイルで表現するフォーマット
  • MCP（Model Context Protocol）: LLMが外部ツールを動的に呼ぶプロトコル（補完関係）
  • llms.txt: サイトに置く「道しるべ」、知識リソースへのポインタ（補完関係）
  • AGENTS.md / CLAUDE.md: リポジトリに置くアドホックな慣習ファイル（OKFはこれを標準化した位置づけ）
• OKFは「何を知っているか」、MCPは「今何ができるか」、llms.txtは「どこを読めばいいか」として役割が異なる

■ 5. ハンズオン: 最小OKFバンドルの手書きと可視化

• リポジトリのクローン後、mybundle/ディレクトリに1コンセプト = 1ファイルでMarkdownを手書き
• 簡易チェックの結果、3コンセプトすべてがOKF v0.1準拠であることを確認
• ビジュアライザー（enrichment_agentのvisualizeコマンド）でバンドルを単一HTMLに変換可能（バックエンド不要・インストール不要）
• ハンズオンで判明した落とし穴:
  • SPEC §5.1ではファイル移動への耐性を理由に絶対パス（/tables/customers.md）を推奨
  • しかしリファレンス実装のviewer/generator.pyが絶対パスを明示的にスキップする実装になっており、エッジが生成されない
  • リンクを相対パス（./customers.md等）に修正することでエッジが正常に生成される
  • v0.1ドラフト段階のSPECと実装のギャップとして認識が必要
• 現時点の実務的対応: ビジュアライザーを使う場合はリンクを相対パスで記述する

■ 6. 既存Obsidian Vaultでの準拠状況

• 812件のMarkdownファイル（日次ノート・プロジェクト・ナレッジ）を検査
• 結果:
  • OKF準拠（frontmatter + typeあり）: 206件（25.4%）、意図せず準拠していた状態
  • frontmatterなし: 487件（60.0%）
  • typeフィールドなし（frontmatterはある）: 119件（14.7%）
  • 残り606件はtypeを追加するだけで準拠可能
• 既存のtype値（memo, knowledge, meeting, project等）がそのままOKFのtype値として機能し、中央レジストリが存在しない設計と相性がよい
• 必須フィールドがtypeのみであるため、大規模Vaultでも段階的な準拠移行が現実的

■ 7. AWSエンジニア視点での活用

• フォーマット自体はGCPに依存せず、リファレンス実装（enrichment_agent）のみBigQuery + Geminiが必要
• AWS文脈での活用案（妄想レベル）:
  • Amazon Bedrock Knowledge Baseに載せる前段でS3上のドキュメントをOKFバンドルとして整理
  • AWS Glue Data CatalogやAmazon DataZoneからOKF形式にエクスポートするスクリプトを書く
  • 既存のAGENTS.md運用にOKFバンドルをtype付きMarkdownツリーとして追加
• フォーマット理解の目的であれば手書きバンドル + ビジュアライザーで十分

■ 8. まとめ

• OKFの評価ポイント:
  • 必須はtypeだけ: 既存のMarkdown + frontmatter運用にtypeを追加するだけで準拠に近づける
  • MCPとは補完関係: 静的ナレッジのフォーマットと動的ツール接続は役割が異なり、並列利用が想定
  • v0.1はスタート地点: visualizerとSPECの絶対パス推奨のズレなど、実装はこれから追いつく余地がある
• OKFはObsidianやCLAUDE.mdによるLLM-wikiパターンの慣習に名前と最低限のルールを付けたものと捉えると導入しやすい
• v0.1はドラフトであり、仕様へのフィードバックはGitHubリポジトリ経由で受け付けている

(2026/06/21)

【Martin Fowler氏 来日】ソフトウェア設計の世界的権威が登壇 、「アーキテクチャConference 2026」...

• 【Martin Fowler氏 来日】ソフトウェア設計の世界的権威が登壇 、「アーキテクチャConference 2026」スポンサー募集を開始 | ファインディ株式会社のプレスリリース

エンジニアプラットフォームを提供するファインディ株式会社（東京都品川区、代表取締役：山田 裕一朗、以下「当社」）は、「アーキテクチャConference 2026」のスポンサー募集を開始したことを発表します。本カンファレンスは、スタートアップ・ベンチャー企業から大企業まで幅広い規模・分野のアーキテクチャに関する最新の知見と実践事例を共有する場として、2026年11月26日（木）・27日（金）にオンライン・オフラインのハイブリッドにて開催します。

MEMO:

• Martin Fowlerが来日して基調講演するらしい

(2026/06/21)

Loop Engineering Needs More Than a Loop

• Loop Engineering Needs More Than a Loop

要約:

■ 1. ループエンジニアリングという概念の問題

• 「ループエンジニアリング」という語は普及しやすいが、精度が伴わない可能性がある
• ワンショットプロンプトは本格的なソフトウェア開発には不十分
• エージェントがコードを書いた場合でも、レビュー、判断、コンテキストの継続が必要
• 問題が発見された際はリトライ、方向転換、人間の介入のいずれかを選択する必要がある
• 「ループ」という表現は正確だが、ループ自体は難しい部分ではない

■ 2. 単純な繰り返しはエンジニアリングではない

• 「生成→評価→フィードバック→再試行」というパターンは有用であり、多くの分野で用いられる
• モデル呼び出しを繰り返すだけでは自動的にエンジニアリングプロセスにはならない
• モデルは根本的な誤りを保持したまま、表面的な出力を改善することがある
• 出力を読みやすくすることと設計を改善することは別物
• 重要な問いは「エージェントをループに入れられるか」ではなく「ループを何が制御するか」

■ 3. 欠けているレイヤー

• 通常のソフトウェアチームでは、実装は単一の行為として扱われない
• コード作成・レビュー・テスト・人間の判断という一連のプロセスが変更を制御する
• エージェント開発にも同様のレイヤーが必要
• 実際のコードベースで難しいのはパッチの生成ではなく、そのパッチが適切かどうかの判断
• エージェントは素早くコードを生成できるが、速度だけが関心事ではない
• 「この変更はここに属するか」という問いを立てる仕組みが必要

■ 4. TAKTの位置づけと役割

• TAKTはエージェント駆動開発のオープンな実験的ハーネス
• 「エージェントをループで実行するツール」という位置づけは本質を外れる
• より正確な位置づけは「エージェント駆動の開発作業を包むハーネス」
• TAKTが目指すのは全ステップの自動化ではなく、各ステップの明示化
  • 誰が書くか
  • 誰がレビューするか
  • 何が再試行されるか
  • どこでワークフローが停止するか
• ハーネスがなければエージェントワークフローはモデル呼び出しの連鎖になる
• ハーネスがあれば、呼び出しに役割と境界が生まれ、検査・変更が可能になる

■ 5. スローガンよりもオーケストレーション

• 「ループエンジニアリング」というスローガンは適用範囲が広すぎる
  • 量的研究ループ、デザイン反復ループ、コーディングループなど異なる文脈で使われる
  • これらは関連するパターンだが、同じ仕組みを必要とするわけではない
• エージェントを使ったソフトウェア開発では仕組みそのものが重要
• オーケストレーションの問いが実用性を決定する:
  • 次のステップを誰が担うか
  • 失敗をどう定義するか
  • システムがリトライすべき場面と人間が判断すべき場面の区別
• これらの問いがエージェントワークフローをデモにとどめるか実用に至るかを分ける

■ 6. OSSとしての意義と透明性

• エージェントが実際の開発に参加するならば、周辺システムはブラックボックスであってはならない
• 開発者が確認できるべき事項:
  • 役割の定義
  • レビューのプロセス
  • リトライの処理
  • 人間の判断が介入する箇所
• チームごとに異なるレビューポリシー、リスク許容度、ゲートを設定できる必要がある
• ハーネスは開発者が理解・再構成できるものでなければならない

■ 7. TAKTが目指す形

• エージェントを孤立した呼び出しではなく、開発プロセスの参加者として扱う
• 解決すべき問い:
  • 作業をどう役割分担するか
  • 出力をどうレビューするか
  • ステップをまたいでコンテキストをどう維持するか
  • 失敗からどう回復するか
  • 人間をすべての操作の監視者にせずにどう関与させるか
• これらの問いはより良いプロンプト単体では解決できない
• より大きな改善はエージェントの周囲に構築するシステムから生まれる
• TAKTはそのレイヤーをオープンに構築する試みであり、作業の分担・レビュー・リトライ・停止を可能にする
• 重要なのはループそのものではなく、ループの周りにあるエンジニアリング

(2026/06/21)

From Prompting Agents to Loop Engineering

• From Prompting Agents to Loop Engineering

要約:

■ 1. 主張の背景

• AIコーディングにおけるパラダイムシフトとして「エージェントに直接プロンプトを入力することをやめ、代わりにエージェントへのプロンプトを自動化するループを設計すべき」という主張が広まっている
• Peter Steinberger: 「コーディングエージェントにプロンプトを入力するのではなく、エージェントにプロンプトを与えるループを設計すべきだ」
• Claude Codeの作者であるBoris Cherny: 「もはやClaudeにプロンプトを入力しない。ループが動いており、そのループがClaudeにプロンプトを送っている。自分の仕事はループを書くことだ」
• プロンプトエンジニアリングが不要になるのではなく、作業レベルがコードを書くことからコードを書くシステムを書くことへと一段階上昇する

■ 2. ループとは何か

• ループとは以下の4つの処理を行う小さなプログラム:
  • コーディングエージェントへのプロンプト送信
  • エージェントの出力の読み取り
  • 完了判定
  • 未完了の場合、エラーや次のステップを含む再プロンプト
• 開発者はループの中でプロンプトを入力し続けるのではなく、ループそのものを記述し、モデルはループが呼び出すサブルーチンとなる
• 基本的な形状: 目標設定 → 実行 → チェック → エラーフィードバック → チェックが通るまで繰り返す

■ 3. 「ループ」の5つの意味

• ReAct（2022年）: 最初の研究パターン。思考・行動・観察を繰り返す
• AutoGPT（2023年）: 自己プロンプト型のゴールループ。停止条件の欠如で有名
• ralph loop: 反復間で意図的にコンテキストをリセットし、エージェントが自身の履歴に埋もれないようにする
• /loop と /goal: ケイデンスと完了条件がエージェントに組み込まれ、ターン間でステートを保持する
• オーケストレーション: 1人の作者が多数のエージェントをファンアウトし、GitHub・Slack・チャットを読み取り次に何を作るかを判断する

■ 4. ループを構成する6つの要素

• トリガー: スケジュール、Webhook、ファイル変更、PRラベルなど、手動操作なしにループを開始する仕組み（これがループを「手動の繰り返し実行」と区別する）
• 隔離: エージェントごとのプライベートなgit worktreeにより、並行実行する複数エージェントがファイルを上書きし合うことを防ぐ
• 書き出されたコンテキスト: 規約・ビルド手順・プロジェクト固有のルールを毎回エージェントが読み取れる場所に保持する（省略するとループは毎回ゼロからプロジェクトを推測する）
• ツールへのアクセス: イシュートラッカー・CI・データベース・チャットへのコネクタにより、ループがPRを作成し、チケットを紐付け、結果を投稿できるようになる
• 第2エージェントによる検証: 出力を評価する別のワーカーを、出力を生成したエージェントから独立させる（モデルが自身の成果物をレビューするとほぼすべてを合格とするため）
• ディスク上のステート: 会話外に存在するMarkdownファイル・ボード・キューなど。モデルはランの間に忘れるが、ファイルは忘れない

■ 5. 具体例: PRベビーシッター

• 動作概要:
  • トリガー: 15分ごと
  • スコープ: agent-watchラベルが付いたオープンPR
  • アクション: CIが決定論的な理由でRedならば1回の修正を試みる。mainが移動していたら1回リベースする
  • 予算: PRあたり修正試行1回、5分、変更ファイル10件
  • 停止条件: CI Greenまたは予算枯渇後、人間に通知
• 同様の構造を活用できる用途:
  • CIヘルス: 30分ごとに失敗ランを署名でクラスタリングし、同一根本原因の複数RedPRをまとめて提示
  • デプロイ検証: プッシュ後にエンドポイントを確認し、200レスポンスと期待コンテンツを確認してユーザーより先に異常を検出
  • フィードバッククラスタリング: 30分ごとにコメントを収集し、テーマでグループ化して各クラスタを担当ファイルやドキュメントにマッピング

■ 6. Claude Codeにおける /goal の活用

• /goalはセッション内コマンドとして動作し、検証可能な完了状態を設定するとその状態が真になるまでターンを繰り返す
• 優れた /goal の仕様に必要な4要素:
  • 求める最終状態
  • 達成を証明する根拠
  • エージェントが破ってはならない制約
  • 許容される作業量の予算
• 動作フロー:
  • 完了条件を設定（例: /goal tests in test/auth pass）
  • エージェントが1ターン作業（編集・テスト実行・結果提示）
  • 評価者（高速モデル）がトランスクリプトを読み「達成」か「未達」かを判定
  • 未達なら次のターン、達成ならゴールがクリアされ実行停止
• 信頼性を高める制御:
  • チェックを測定可能にする（テスト結果・終了コード・ファイル数など。「良くする」はゴールにならない）
  • 実行を制限する（「20ターン後に停止」などを付加する）
  • autoモードと組み合わせて無人実行し、早期終了には /goal clear を使用
• 評価者はコーダーと異なるモデルを使用可能であり、モデル選択がアーキテクチャ上の意思決定となる（計画・実行・評価・ビジョンレビューを異なるモデルに割り当て可能）
• 適用場面: APIマイグレーション、リファクタリング、イシューバックログ処理、evalループ

■ 7. 複数ループの無人実行

• Chernyが提示するOpusを自律的に何時間も動かすための5ステップ:
  • 権限を自動承認し、ツール呼び出しのたびに停止しないようにする
  • 動的ワークフロー（Ultracodeをプロンプトに投入）で多数のエージェントへのファンアウトを実現する
  • /goal または /loop でセッションを継続させる
  • クラウド（デスクトップまたはモバイルアプリ）で実行し、ラップトップを閉じてもセッションを維持する
  • エンドツーエンドの自己検証手段を与える（Web向けにChromeのClaude、モバイル向けにシミュレータMCP、バックエンド向けにライブサーバー）

■ 8. オーケストレーション製品としてのcrabfleet

• Peter Steinbergerが開発した「crabfleet」（OpenClawプロジェクト）はループをプロダクトとしてパッケージ化したもの
• 主な特徴:
  • ボード上のカード: タスクがプロンプト・GitHubイシュー・PRから作成され、todo→実行中→人間レビュー→完了と移動する
  • 耐久性のある実行: ハートビートつきの追跡実行により、ラップトップを閉じても継続する
  • エージェントがエージェントを生成: サンドボックス内で子セッション起動・メッセージ送信・トランスクリプト読み取り・サマリー更新が可能
• ループがインフラとして成熟した結果、キュー・耐久実行・ファンアウト・人間レビューゲートが手作業スクリプトではなく設定項目となっている

■ 9. コストの考え方

• ループ内ではコストはトークン数ではなくループの反復回数に依存する
• 最適化すべき指標:
  • 反復回数が予算の単位（同じモデルで2倍ループするモデルを安いと判断しない。タスクあたりのコストで測定する）
  • 検証器の精度が最も重要（緩い完了チェックは、壊れた成果物で早期終了するか、完了済み作業を繰り返すかのどちらかで両方が反復全体を無駄にする）
  • 早期失敗がコスト管理（連続失敗の上限がないループは最終的にアカウントを枯渇させる。停止条件はコードベースと同様に請求を守る）

■ 10. ループを使うべきでない場面

• 1回限りの編集: 1パスで完了できるならループはオーバーヘッドにすぎない
• スコープ未定義または探索的な作業: 「なぜユーザーが離脱しているか調べる」には合格条件がなくループが収束しない
• 安価な自動チェックが存在しない作業: 唯一の検証者が人間の目であれば、人間は依然としてループの中にいる（先にチェックを構築するか手作業で対応する）

■ 11. 失敗モードとリスク

• 検証負担が人間に残る: ループはレビューできる速度より速くコードを書くため、差分を読むのをやめれば作業を排除したのではなく先送りしただけになる
• 理解ギャップの拡大: 自分が書いていないコードを吸収できる速度より速く出荷すると自身のシステムモデルが劣化し、次のインシデント時にその負債が顕在化する
• 緩いチェックによるサイレントドリフト: 弱い検証器は毎反復ごとに「テスト通過だが間違っている」成果物を通過させ、ループが生産的に見えながら問題を拡大する
• これらはループへの反論ではなく、ループを設計するエンジニアの重要性がより高まる理由である

■ 12. 自分のループを構築する手順

• 繰り返し可能なタスクを1つ選ぶ（PRのベビーシッティング・CI修正・デプロイ検証など、ルーティン作業から始める）
• スコープを絞る（「バグを修正する」ではなく「billing webhookのバリデーションを修正する。触れるのはapp/api/billingとlib/billingのみ」とする）
• 予算と停止条件を設定する（最大試行回数・最大実行時間・最大ファイル数・最大費用・連続失敗の上限。無人実行中のループは無人でミスも犯す）
• 独立した検証器を追加する（コードを書いたエージェントは完了の最悪の判定者であるため、別のサブエージェントが成果物を評価する）
• ケイデンスで実行する（インターバルに /loop、スケジュールにcron、ライフサイクルポイントにフック、ラップトップを閉じても継続するためにGitHub Actions）
• メモリをディスクに保持する（モデルはランの間に忘れるため、ステートはコンテキストウィンドウではなくMarkdownまたはボードに保存する）

(2026/06/21)

技術記事、 専門家としてのプログラマ、 言語化

• 技術記事、 専門家としてのプログラマ、 言語化 - Speaker Deck

要約:

■ 1. 発表概要

• 登壇者: mizchi（フリーランスエンジニア）
• 発表会: Zennfes Spring 2026
• 主題: AI時代に、人間が技術記事を書く意味を問い直す
• 登壇者の専門領域:
  • パフォーマンスチューニング
  • AIパイプラインによる開発自動化

■ 2. AI以前・以降の技術記事の変化

• AI以前の技術記事の役割:
  • 翻訳・キュレーション・学習ログを兼ねる言語障壁の埋め合わせ
  • 二次情報ゆえに利用者視点の解釈が混ざりやすい
  • 日本コミュニティにおけるフリーライダー傾向
• AI以降の変化:
  • 全方位にレバレッジの効くAIだけ触れば事足りる状況になった
  • 人間は技術記事の一次消費者ではなくなった
  • AIが書き、AIが読む。人間はAI越しに要約を読むだけになった
• 消費フローの比較:
  • AI以前: 人間が書く → 人間が読む → 人間が学ぶ
  • AI以降: AIが書く → AIが読む → 人間は要約だけ
• 問い: AIがAI向けに説明するフローでは、既存の技術記事の存在理由はなくなる

■ 3. AI周辺ツール記事の賞味期限問題

• 書いている間に前提が更新され、公開した頃には標準機能に吸収されている
• 賞味期限が短い記事の類型:
  • AI bikeshed: エージェント設定いじりの記事（.vimrcの現代版）
  • absorbed: 知見は次のモデル・ハーネスに吸収される
  • translation: 翻訳性能の向上で、紹介・翻訳の二次情報が不要になった

■ 4. 技術記事とスキルの等価性

• 良い技術記事と良いスキルに求める要件は一致する:
  • 問題が解決する（読者の課題が解ける / タスクが完了する）
  • 再現性がある（手順通りで再現できる / 誰が実行しても同じ結果）
  • 新規性がある（既知の焼き直しでない / 既存手順の焼き直しでない）
• 結論: article.md をSKILL.mdに置き換えることが可能
• mizchiのスキル運用例（github.com/mizchi/skills）:
  • skill-selector: プロジェクト構成から必要なスキルを選び、設定を生成・更新
  • empirical-prompt-tuning: スキルを定量評価して自己改善する
  • retrospective-codify: 現在のセッションから一般化できるスキルを抽出する
• Hermes Agent（NousResearch）のSkillsシステムとの整合:
  • スキルはエージェントの手続き的記憶（procedural memory）として機能する
  • エージェント自身がスキルの作成・更新・削除を行う
  • ターン後の自己改善レビューでも、スキルを自動で書き足す

■ 5. 人間にとっての知識単位とAIの差異

• AIの知識単位: スキル（再現可能・機械実行可能・揮発しても再生できる）
• 人間にとって良い記事の要件:
  • 新しい概念の獲得
  • 新しい視点を得て、創発を刺激すること
  • 記憶に刻むための叙情的なレトリック
• AIの学びを自動化したら、人間が関与する余地がなくなった

■ 6. 言語化の本質と難しさ

• AIから人間への要求は2つに集約される:
  • ゴールを言語化する（そのために必要な資料やスキルを選別すること）
  • 有益な対話相手になる（目的の言語化、曖昧性の排除、ミスの指摘）
• 言語化を過小評価することへの警告:
  • 暗黙知が暗黙なのには相応の理由がある
  • 言語化できた瞬間に、それは暗黙知ではなくなる
  • 専門家として暗黙知を記述するのが、知の最前線
  • 「直感的」はNG WORD（根拠を示す必要があるため）
  • 参考: Polanyi (1966) The Tacit Dimension / 野中・竹内（1995）SECIモデル
• LLMとの非対称性:
  • LLMはセッション中に高速にドメインを構築し、揮発する
  • 当人が自明なことは書かない
  • 「十分に賢いなら自然と導かれる結論」のレベルが上がる
  • 結果として人間が置き去りにされる（認知的敗北）

■ 7. AIからドメイン知識を抽出する方法

• method 01: わかるまで質問責め
  • 王道だが人間側に高負荷
  • 理解できたか計測できない
• method 02: ブラックボックスで分割統治
  • 現実解だが、コアドメインはリスク
  • API契約に設計力が必要
• method 03（推奨）: 多角的な解析
  • BBテスト・性能計測・監査
  • 外側から性質を炙り出す
  • マクロ分析ツールが不足している領域

■ 8. プログラマの言語化実践

• プログラマの言語化 = 分析ツールを作る（コードの扱い方という暗黙知を実装で表現する）
• 実践フロー:
  • 01 AIにツールを作らせる
  • 02 出力の妥当性を経験で評価
  • 03 使わせて反復改善
  • 04 有用性・再現性が確認できて記事化
• 登壇者が実際に作成したツール（一部）:
  • sprawlens: コード変更差分を地理データとして可視化（mizchi.github.io/sprawlens）
  • similarity: 木構造の編集距離から、コード重複を検出
  • ts-fuzzing: TS型定義から関数・コンポーネント入力をfuzzing
  • flaker: CI上で不安定なテストの検出と分類
  • lightbringer: playwright-testのステップ毎にCPU・IOを計測
  • chaosbringer: playwright経由でランダムに障害を注入するカオステスト
  • vlmkit: VRTヒートマップをDOM・CSSに対応付け、構造化
• mnemo（試作）: HermesのメモリシステムをMoonBitで実装、AI同士が知識をスキルへ蒸留する仕組み

■ 9. アイデアの検証サイクル

• 検証コストが暴落した時代のアイデアの回し方:
  • アイデアを検証するコストが大幅に下がった（Simonton (1997) equal-odds rule）
  • 新しいアイデアは学習と創発のサイクルの中にある（Kolb (1984) Experiential Learning）
  • ただし、学習とは認知への負荷である（Sweller (1988) Cognitive Load Theory）

■ 10. 専門家が今書くべきこと

• 専門家のレビューと評価が、AI時代における技術記事の価値:
  • 一次資料はポジティブなことしか書かない
  • 検証はコミュニティの仕事
  • 技術記事の一番の価値は、採用後の推移と失敗談の共有にある
• AI時代に専門家のレビューを成立させる二つの前提:
  • 価値あるフィードバック: 使い手である人間が、AIにとって価値あるフィードバックを出せること
  • AI前提で再構築する: プログラミングのフロー自体を見直し、ツールチェイン・エコシステムをAI前提で作り直す
• AI時代の変化の整理:
  • 下がったもの: 学習コスト（難解な技術も踏み倒せる）、参入障壁（個人でOS・DB・言語さえ作れる）
  • 変わらない・むしろ上がったもの: 要求水準、使い手への要求、評価サイクルの速度
  • 下がった障壁と変わらない要求のギャップを埋めるのが専門家の仕事

■ 11. まとめ: AIに価値あるパートナーであり続けるために

• 認知的敗北を喫さず、学びを続ける
• AIに使われるな、使いこなせ
• 知識を抽出して、コミュニティに還元しろ

(2026/06/21)

curl作者がクローズドの「Mythos」による17万8000行のコード分析結果を公開　性能をどう評価...

• curl作者がクローズドの「Mythos」による17万8000行のコード分析結果を公開　性能をどう評価？：「パニックになるほど危険ではない」 - ＠IT

要約:

■ 1. 背景と概要

• curlプロジェクトの開発者ダニエル・ステンバーグ氏が、AnthropicのAIモデル「Mythos」によるcurlソースコード（17万8000行）の脆弱性分析結果を2026年5月に公開
• 分析はcurlのgitリポジトリのマスターブランチ（src/およびlib/サブディレクトリ）を対象に実施
• ステンバーグ氏自身はLinux FoundationのAlpha-Omegaプロジェクト経由でのアクセス取得が遅延したため、代理人がスキャンを実行し、レポートを受領

■ 2. curlプロジェクトにおける既存のAIコード分析の実績

• Mythos以前から複数のAI支援ツール（AISLE、Zeropath、OpenAI Codex Security）でコード分析を継続実施
• 過去8〜10カ月で200〜300件のバグ修正がcurlにマージされ、CVEとして公開された脆弱性も十数件に及ぶ
• プルリクエストレビューにはGitHub CopilotおよびAugment Codeを導入し、新規バグの混入防止を補助
• AIレビューは人間のレビューを置き換えるものではなく、補完するものとして位置づけられている
• セキュリティ研究者からの脆弱性報告もAI活用により質・量ともに増加

■ 3. Mythosによる分析結果の詳細

• Mythosは「確認済みのセキュリティ脆弱性」として5件を報告
• curlセキュリティチームが精査した結果:
  • 確認済み脆弱性として残ったのは1件のみ（深刻度「低」、curl 8.21.0リリース時にCVEとして公開予定）
  • 3件はAPIドキュメントに記載された既知の制約を脆弱性と誤認したフォールスポジティブ（偽陽性）
  • 1件は「単なるバグ」と判断
• 脆弱性以外のバグも約20件がレポートに記載され、curlチームが順次対応中
• Mythosのレポートは誤検知が少なく、問題の解説も的確と評価された

■ 4. Mythosの総合評価

• 検出数では、curlが以前から利用している他のAIツールの方が多くのバグを発見（初期ツールほど発見しやすいバグが残っていたため）
• ステンバーグ氏はMythosを「マーケティング先行」と結論付け:
  • 他のAIツールと比べて特に高度・特殊な問題を発見しているという証拠はない
  • 「少し優れているかもしれないが、コード分析に大きな変化をもたらすほどの差ではない」と評価
• ただし対象はcurlのみであり、他の領域では異なる結果となる可能性も付記

■ 5. AIコード分析ツールが従来の静的解析ツールより優れる6つの特徴

• コメントと実装の食い違いの検出:
  • コメントが説明する動作と実際のコード動作の不一致を検出可能
  • 従来の静的解析ツールはドキュメントとの食い違いを判定できなかった
• 通常の解析ツールでは対応できないプラットフォームや構成の検査:
  • ビルド構成やプラットフォーム依存のコードパスまで踏み込んだ分析が可能
• サードパーティーライブラリのAPI仕様の把握:
  • 学習段階で吸収した広範なライブラリ知識を活用し、不適切な使用や誤った前提を検出
• プロトコル仕様との不整合の検出:
  • HTTP、TLS、FTPなどの仕様書に記載された挙動と実装のずれを発見
• 欠陥の要約と説明:
  • 欠陥内容を読みやすく要約・説明する能力に優れ、開発者の対応迅速化に貢献
• 修正パッチの生成提案:
  • 発見した問題に対するパッチを自動生成できる場合があるが、開発者による検証・調整が前提

■ 6. AIコード分析ツールの現在の限界

• AIツールが発見する欠陥は既知タイプの新しい事例にとどまり、全く新種の脆弱性カテゴリーは今のところ報告されていない
• 「AIは新しい欠陥カテゴリーを発見できているわけではない。だが、従来のツールより多くの既知パターンの問題を発掘できているのは事実」とステンバーグ氏は指摘
• AIツールを導入していないプロジェクトは、攻撃者に脆弱性を発見・悪用される機会を与えるリスクがあると警鐘

(2026/06/20)

Why is Meta destroying its engineering organization?

• Why is Meta destroying its engineering organization?

要約:

■ 1. AI以前のMetaのエンジニアリング文化

• "Move fast and break things"（2010年代）:
  • 2012年にFacebookは「Little Red Book（小さな赤い本）」を作成し、スピード・大胆さ・所有感を文化として体系化
  • 「Done is Better Than Perfect」「Fail Harder」などのマントラをキャンパス全体に掲示
• "Move fast with stable infra"（2020年代初頭）:
  • エンジニアリング中心の文化で、個人の成果（impact）を重視
  • プロセスや自動テスト、ドキュメント整備は少ない
  • エンジニアは会社採用でチームを自由に選択できるBootcampが存在
  • CEO Zuckerberg自身がエンジニアであり、エンジニアを利益の源泉として評価

■ 2. AIへの投資とエンジニアへの強制的な活用

• Llamaモデルの開発経緯:
  • Llama 1（2023年2月）、Llama 2（2023年6月）、Llama 3（2024年4月）を順次リリース
  • Llama 4（2025年4月）は期待を大きく下回る結果となる
  • Scale AIに49%出資（148億ドル）し、CEO Alexandr Wangが参画
• 問題1 — キーストロークとマウス操作のトラッキング:
  • 2025年4月末、全エンジニアにオプトアウト不可で導入
  • AI学習データ生成を目的とする
  • 英国では個人情報保護規制により未展開
  • 強い反発を受け、後に30分単位での一時停止と適用除外申請が認められる
• 問題2 — エンジニアの強制的な再配置:
  • エンジニアの30〜50%がADO org（Agent Data Optimisation）に強制移動
  • ADO orgには約6,500人が所属し、うち約4,000〜5,000人がソフトウェアエンジニア
  • Meta全体の約25,000人のうち、約1/5〜1/6がフルタイムでデータラベリングを担当
  • 基盤チームやセキュリティチームで特に影響が大きく、優秀なエンジニアが多数移動

■ 3. エンジニアへの扱いと士気の低下

• 問題3 — 1ヶ月間の解雇予告:
  • 2025年4月20日、Metaは10%のスタッフを解雇すると発表
  • 実施まで約4週間、全社員が不安を抱えた状態が続く
• 問題4 — PSC（Performance Summary Cycle）による過度な競争:
  • 管理職が報告者のランクを上げるために他チームのエンジニアを「落とす」行為が横行
  • ビジネス影響、コードレビュー数、コード行数などのメトリクスの武器化が常態化
• 問題5 — AIトークン使用量のパフォーマンス評価への組み込み:
  • トークン使用数がPSCで評価されるようになり、無目的に使用量を増やす「トークンマキシング」が蔓延
  • Metaの全エンジニアが30日間で60.2兆トークンを使用（Anthropic API価格換算で約9億ドル相当）
• 結果 — 形式的な業務が実質的な業務を上回る状況:
  • AI使用量を最大化し、人間の関与を最小化するよう最適化が進む
  • 長期勤務のエンジニアが転職を検討・実行する動きが活発化
  • 特に2025年5月以降、interviewing.ioなどの面接準備サービスへのMeta社員の登録が急増

■ 4. 史上最大の恥ずかしい障害

• 2025年5月30日のInstagramアカウント乗っ取り事件の概要:
  • 攻撃者はユーザー名だけで任意のメールアドレスに確認コードを送信させ、アカウントを乗っ取ることができた
  • 追加認証なしのパスワードリセットという根本的なセキュリティ欠陥が存在
  • Obamaホワイトハウスアカウントを含む多数の高知名度アカウントが被害を受ける
• 発生背景:
  • Instagram Trust and Safety Teamのスタッフが50%減少
  • AI生成・AIレビューのみのコードが浸透しており、該当変更もその一つと見られる
  • セキュリティチームの監視・アラート機能が機能不全に陥っていた
• 事後対応:
  • 6月1日に復旧、6月2日にCISO（Guy Rosen）が退任を発表
  • 2021年の7時間障害とは異なり、ポストモーテムや謝罪は公表されていない

■ 5. 社内の混乱

• 社員の不満:
  • 数千名参加の社内ライブ配信で、AI担当幹部への罵倒を含む不満爆発の事件が発生
  • ADO org（Applied AI team）内で「グラーグのようだ」との声が上がる
  • CPO Chris Coxが全社員向けミーティングで「会社の狂気（insanity）」「ハリストームの中でのマラソン」と表現
• 経営陣の対応:
  • CTO Andrew Bosworthは「AIリオーグは散々だった（atrocious）」と認めたが、AIコーチングツールの提供を約束するにとどまる

■ 6. 自傷行為としての経営判断

• Zuckerbergの意思決定:
  • 記録的な収益・利益にもかかわらず10%の人員削減を断行
  • Googleを上回る世界最大の広告事業になる勢いにあったにもかかわらず、コーディングLLMの構築を優先
• Scale AIのAlexandr WangによるMetaへの影響:
  • キーストロークトラッキング、強制的なデータラベリング、優秀なエンジニアの再配置はすべてScale AIのアプローチに基づくとみられる
  • Wangの専門はトレーニングデータ生成、データラベリング、RLHFであり、その手法がそのままMetaに適用されている
• 結果:
  • Metaのエンジニアリング文化は実質的に終焉を迎えた
  • 英国では一部の解雇が中止されたとの報告もある

■ 7. 「AIサイコシス」はMeta固有の問題か

• Mitchell Hashimoto（Ghostty作成者、HashiCorp創業者）の見解:
  • 「AIサイコシス」に陥った創業者がAIの能力を過大評価し、合理的な対話が不可能な状態にある
  • 「MTTR（平均復旧時間）さえ良ければよい」という考え方が蔓延し、システムの堅牢性が軽視されている
  • バグ報告が減少しても潜在的リスクは増大し、テストカバレッジが上がっても意味的理解は低下する
  • クラウド移行期のMTBF対MTTR論争と同様の教訓が繰り返されているとHashimotoは警鐘を鳴らす
• Instagramの障害はこの懸念を具体的に体現した事例:
  • AI生成・AIレビューコードの品質基準低下が現実のセキュリティ侵害を引き起こした
• まとめと教訓:
  • リーダーシップポジションにある者は、AI関連の大規模な組織変更を行う前にMetaの事例を参照すべき
  • Metaからの人材流出は、他のスタートアップやBig Techにとって採用機会となる
  • 「Move fast and break things」の文化が、皮肉にもMeta自身のエンジニアリングOpenTextに適用された形となっている

(2026/06/20)

今だから押さえておきたいソフトウェア工学のベストプラクティス

• 今だから押さえておきたいソフトウェア工学のベストプラクティス

(2026/06/20)

ゲーム開発ではなぜファイルのマージよりも「ロック」を多用して開発を進めるのか？

• ゲーム開発ではなぜファイルのマージよりも「ロック」を多用して開発を進めるのか？ - GIGAZINE

要約:

■ 1. 背景

• 一般的なソフトウェア開発では、複数人が同じファイルを編集後に変更を統合する「マージ」が標準的な手法
• ゲーム開発では、マージよりも「排他ロック」を多用する独自の作業手順が存在する
• ゲーム開発者のアレックス・クリリン氏が、その背景にある技術的・実務的な事情を解説

■ 2. 一般的なソフトウェア開発でマージが成立する理由

• ソースコードはテキスト形式で保存されており、Gitが行単位で変更前後の差分を比較できる
• 変更箇所が重なっていなければ、複数人の編集を自動的に統合可能
• 衝突（コンフリクト）が発生しても、開発者が差分を確認して手動で解決できる
• ゲーム開発のC++などテキスト形式で書かれたコードにも同様のマージが適用される

■ 3. ゲーム開発でマージが困難な理由

• バイナリファイルの問題:
  • ゲームには画像、音楽、アニメーション、3Dモデル、動画、視覚効果、マテリアルなど多数のバイナリファイルが含まれる
  • バイナリファイルは行単位で差分を比較できないため、自動マージが不可能
  • 2人が同じファイルを編集した場合、片方の変更を破棄するか、手動で反映するしかない
  • 複雑な素材では数日分の作業が失われる可能性もある
• Unreal EngineのBlueprintも同様の問題を抱える:
  • Blueprintはノードを線でつなぐビジュアルスクリプト機能であり、テキストではない
  • 差分表示機能は存在するが、別々の変更を自動マージすることは困難
  • 必要な変更は差分を見ながら手作業で反映する必要がある

■ 4. 排他ロックによる対策

• 排他ロックの仕組み:
  • あるファイルをチェックアウトすると、作業が完了するまで他の開発者は同じファイルを変更できない
  • 複数人の作業を後から統合するのではなく、同時編集そのものを禁止して事故を防ぐ
• Perforce P4の活用:
  • 中規模以上のゲーム開発で広く使われるバージョン管理システム
  • 中央サーバーがファイルとロックの状態を管理する
  • Unreal EngineはPerforce P4との標準連携機能を備えており、アーティストにも馴染みやすい

■ 5. 排他ロックの問題点

• 主要キャラクターのファイルを数日間ロックすると、アニメーターやゲームデザイナーが作業を進められない
• ロックを解除し忘れたまま退勤すると、時差のある地域で働くメンバーが編集できなくなる場合がある

■ 6. ファイル分割による待ち時間の軽減

• 1つのファイルに多くの機能を集めず、役割ごとに小さく分割する設計が重要
• 機能を詰め込んだ場合の問題:
  • 体力、持ち物、移動、特殊能力を1個のキャラクターファイルへ集約すると、どの機能を変更する場合でも同じファイルのロックが必要になる
• Unreal EngineのActorComponentによる解決策:
  • アクターに独立した機能を追加する「アクターコンポーネント」を使い、各処理を別々のファイルへ分割できる
  • 体力の修正担当は体力用コンポーネントのみをロックすればよく、他のメンバーは別ファイルで並行作業できる
  • 再利用性の向上だけでなく、開発者間の作業待ちを減らすための分割でもある

■ 7. ブランチ運用の違い

• 一般的なソフトウェア開発で使われる「作業用ブランチ」は、ゲーム開発では役割が小さい
• バイナリファイルでは実用的な自動マージが困難なため、別ブランチで同じ素材を編集しても最終統合ができない
• チーム全員がメインブランチ上で作業し、必要なファイルだけをロックする運用が多く選ばれる

■ 8. 大容量データへの対応

• 4Kテクスチャ1枚で数十MBに達する場合があり、開発中のゲーム全体が数TB〜数十TBになることもある
• ビルドのたびに全データをダウンロードするのは現実的ではない
• CI用コンピューターにはP4の作業領域を維持し、変更されたデータだけを同期する手法が採用されている
• 配布版では対象プラットフォーム向けにデータを変換・最適化するため、ユーザーがダウンロードする容量は開発データ全体より小さくなる

■ 9. 人間同士の取り決めの重要性

• ロックの解除を忘れない、頻繁に編集されるファイルを把握する、特定の素材の担当者を決めるといったチームルールが必要
• テキストファイル中心の開発ではGitのマージ機能が処理していた作業の衝突を、ゲーム開発ではファイル設計とチーム内の連絡で回避する

■ 10. 結論

• ゲーム開発が一般的なソフトウェア開発より遅れているわけではなく、巨大なバイナリファイルという制約に合わせて異なる手法を採用している
• 自動マージ技術が今後発展する可能性はあるものの、現状では排他ロックが数日分の作業を守るための実用的な解答

MEMO:

• そうなんだ

(2026/06/19)

lore.org

• Lore | 次世代オープン ソース バージョン管理 - Lore

Lore は Epic Games が管理しており、データとチームの双方で前例のないスケーラビリティを実現できるように設計されています。ゲームやエンターテインメントなど、コードと大規模なバイナリ アセットを組み合わせるプロジェクト向けに最適化されており、デベロッパーとアーティスト双方のニーズに対応します。

(2026/06/18)

Epic Games、ゲーム開発向けの次世代バージョン管理システム「Lore」をオープンソースで公開。MIT...

• Epic Games、ゲーム開発向けの次世代バージョン管理システム「Lore」をオープンソースで公開。MITライセンスで無料提供｜ゲームメーカーズ

要約:

■ 1. 概要

• Epic Gamesが次世代バージョン管理システム「Lore」のプレステーブル版を公開
• MITライセンスのオープンソースとして無料提供
• プロジェクト種別を問わず使用可能で、改変・配布・Loreを基盤としたツールの構築も許可
• 対応環境: Windows、macOS（ARM64）、Linux向けにCLIツールおよびサーバーバイナリを提供
• 言語サポート: C/C++・RustのネイティブインターフェースのほかJavaScript、Python、C#、Goの言語バインディングに対応

■ 2. 開発背景と目的

• 既存VCSが抱える大規模化・バイナリデータ取り扱いの課題を解決するために設計
• ゲーム開発では数GBのテクスチャ・3Dモデル・音声ファイルなどの大量バイナリアセットが存在
• マルチテナントの安全性とオープン仕様を備えた大規模プロジェクト管理システムとして構築

■ 3. 運用実績

• Epic Games社内ですでに稼働中
• 「Unreal Editor for Fortnite（UEFN）」の組み込みVCS（旧称: Unreal Revision Control）として採用
• クリエイターの島データのバージョン管理やクックパイプラインのバックエンドとして利用

■ 4. 技術的特徴

• バイナリファーストアーキテクチャ:
  • データはファイル単位ではなくフラグメント（チャンク）に分割して管理
  • 暗号学的ハッシュ関数BLAKE3によるコンテンツアドレス方式を採用
  • チャンク化手法はコンテンツベース（FastCDC）と固定サイズの2種類をサポート
  • 変更されたフラグメントのみ再アップロードすることで通信量とストレージ容量を節約
• スパース設計とオフライン対応:
  • クローン時に「ビューフィルタ」で必要なディレクトリのみ指定可能
  • データはオンデマンドで取得（遅延フェッチ）され、数TBのプロジェクトでもローカルストレージを圧迫しない
  • ミュータブルストア（ブランチの最新ポインタ等）とフラグメントキャッシュをローカルに保持
  • ステージング・コミット・ブランチ操作・差分確認などはオフラインで実行可能
  • サーバー通信はPushおよびSync時のみ発生
• ロック機能:
  • バイナリアセットなど自動マージ不可能なファイル向けにファイルレベルのロック機能を搭載
  • ロックはサーバーと通信して取得・照会し、ロック中ファイルへのPushはサーバー側で拒否
  • 複数ユーザーによる同一ファイルの同時編集による競合事故を防止
• リンクとレイヤー:
  • リンク: Gitのサブモジュールに類似しており、ディレクトリごとにアクセス制御が可能、権限のないユーザーには内容が非表示
  • レイヤー: ローカルでのみ適用されるオーバーレイ機能で、CIパイプラインや個人アセットライブラリを透過的にマウント可能

■ 5. 今後のロードマップ

• 2026年の計画:
  • VS Codeプラグインの実装
  • 仮想ファイルシステム（VFS）の実装
  • 数百万ファイルに対応するスケーラブルなロック機能の強化
• 2027年の計画:
  • デスクトップクライアント（早期アクセス版）のオープンソース化
  • アンリアルエンジンのエディタ本体へのプラグイン統合
  • Webクライアントの提供

MEMO:

• バイナリデータの取り扱いが標準で可能なのは注目に値する
• Gitはそこが弱かった
• ロック機能はどうなんだろうか
• ロック先取争いになってしまわないか？

(2026/06/18)

ローカルLLMをいつ使うべきか？

• ローカルLLMをいつ使うべきか？

MEMO:

• それはそうという感想があった

(2026/06/18)

その問い、本当に正しいですか？AI時代のエンジニアに必要な哲学と認知科学

• その問い、本当に正しいですか？AI時代のエンジニアに必要な哲学と認知科学 / ai-philosophy-cognitive-science - Speaker Deck

要約:

■ 1. 発表の背景と目的

• AIによるソフトウェア開発が加速度的に広がり、あらゆる業務のAI化を試みる企業も登場している
• 一方で「プロダクトの価値が上がらない」「AIが混乱して実装が終わらない」「既存環境を破壊する変更をしてしまう」といった課題も生じている
• AI駆動開発が上手くいかない要因の一つとして、「物事の認識や解釈が不正確だったり、歪みが生じている」ことが挙げられる
• 認識の歪みは、顧客要求の誤解釈やドメインモデルの構造的な問題に直結する
• 本セッションでは、認識の歪みを正す手段として哲学と認知科学のノウハウを紹介する

■ 2. 前提: AI時代におけるエンジニアの役割変化

• 一般的なソフトウェア開発プロセスは「要求定義→要件定義→設計→実装」で構成される
• このうち設計・実装はAIに置き換わりつつある
• 人間の仕事は必然的に上流の「要求定義・要件定義」へシフトしていく
• 要求・要件定義もAIに置き換わるという意見もあるが、「ああしたい・こうしたい」と要求するのは人間であり、目的や価値を決められるのは人間だけである
• フェーズによる役割分担:
  • 問題定義フェーズ（要求・要件定義）: 人間がpilot（操縦士）、AIがcopilot（副操縦士）
  • 問題解決フェーズ（設計・実装）: AIがpilot、人間がcopilot
• AI時代のエンジニアの役割は以下の2つに集約される:
  • 問題定義（どのような問題を解くべきか）
  • AIが設計実装した成果物の妥当性検証

■ 3. 認識のズレが引き起こす問題: 2つの事例

• 物事の認識や解釈に歪みがあると、問題定義もドメイン設計も上手くいかない
• 事例1「類似するもの」（認識のズレ）:
  • ビジネス側が「購入後に類似するものを一覧表示する機能がほしい」と要求した
  • 開発者は「類似するもの」を「購入商品と見た目が似た商品（同種の別メーカー品）」と解釈した
  • 実際にビジネス側が意図していたのは「購入商品とセットで使う関連商品」だった
  • 数ヶ月後、同じスポンジ類似品が表示される機能が完成したが、ビジネス側の期待とは全く異なる成果物となった
• 事例2「ユーザー」（いびつなドメインモデル）:
  • ECサイトに「ユーザーに所属会社・会社電話番号・所属部署・ロールを登録できる仕様」が追加された
  • 担当者は深く考えずに既存のユーザーモデルに項目を追加した
  • 実際には法人顧客向けの仕様だったにもかかわらず、個人・法人を同一モデルに混在させた結果、「学生なのに会社名登録が必要か」「誕生日項目が法人登録画面に表示される」などの問合せや苦情が殺到した
• 両事例の共通原因:
  • 事例1「類似するもの」→ 開発者は「同種の商品」と解釈したが、本当の意味は「関連商品」だった
  • 事例2「ユーザー」→ 開発者は区別なく解釈したが、本当の意味は「個人顧客と法人顧客」という別概念だった
  • いずれも「言葉の意味を正しく解釈できなかった」ことが根本原因

■ 4. 解決に役立つ哲学と認知科学

• こうした問題の解決に役立つのが哲学と認知科学であり、物事をより正しく認識することに役立つ
• 哲学とは:
  • 物事の本質を突き詰めるために問いを立て、考えを深めていく学問
  • 「なぜそれが正しいか」「前提が間違っていないか」といった追求をする
  • 世界の仕組みや真理の理解、ルールや善悪判断の基準となる思考を整理する目的で生まれた
  • 分野は形而上学・認識論・意味論・語用論・倫理学など多岐にわたる
• 認知科学とは:
  • 知能や心の働きを情報処理の観点から解明する学問
  • 知覚・記憶・学習・言語理解・感情など心的機能が関心事
  • 哲学・人工知能・心理学・言語学などの分野とも関係が深い
• 本セッションで紹介する2つの概念:
  • 哲学: 言語ゲーム
  • 認知科学: スキーマ理論

■ 5. 言語ゲーム（哲学）

• 哲学者ウィトゲンシュタインが提唱した概念
• 「言葉の意味は単独では決まらず、用法や文脈によって決まる」とする考え方
• 例: 「水！」という言葉の意味は文脈によって異なる
  • カレー店では「飲み水がほしい」
  • 火災現場では「鎮火するための水を持ってきてほしい」
• 例: 「殺す」という言葉も文脈によって意味が変わる
  • ソフトウェア文脈では「動作中のプロセスを強制停止するkillコマンド」
  • 日常文脈では「人を殺める」
• 同じ言葉でも文脈が違えば意味が根本的に異なる

■ 6. スキーマ理論（認知科学）

• 認知科学に登場する理論で、人間の脳は自分の知識や経験に当てはめて物事を解釈しようとする
• この知識の枠組みを「スキーマ」と呼ぶ
• スキーマの利点: 「これは自分の知識に当てはめると○○だ！」と瞬時に認識・判断できる（例: 電車を見て「電車だ」と素早く認識する）
• スキーマの問題点: 知識や経験のないものに対して誤ったスキーマを適用し、誤った解釈をしてしまう
  • 例: 電車を知らないジャングルの原住民が電車を「巨大なヘビ」と解釈する
  • 例: 「適当にやっといて（要点を押さえてやって）」という指示を「粗くやればいい」と解釈して問題が生じる

■ 7. 言葉の意味を正しく理解するための4つの確認

• 言語ゲームとスキーマ理論の学びから、言葉の意味を理解するには以下4つの確認が必要である
• 確認すべき4項目:
  • アクター: システム利用者・利害関係者（誰が関係するのか）
  • 目的: アクターの目的（何をしたいのか）
  • 文脈: アクターの背景やおかれている状況（どのような状況か）
  • ルール: 文脈内で生じるルール・制約・方針（どのような制約があるか）
• 構造的な関係性:
  • 人の言葉の裏には目的がある
  • 目的は文脈から発生する（例: 寒い→上着が欲しい）
  • 各文脈にはルールがある（例: 身体のサイズ、予算上限）

■ 8. 4つの確認を事例に適用した改善例

• 事例1「類似するもの」の改善:
  • アクターの確認: 「ここでのユーザーとはどういうユーザーですか？」→「日用品をまとめて買うような層」と判明
  • 文脈・目的の確認: 「具体的にどういう状況でどうしてほしいのですか？」→「購入後に追加購入を促したい」と判明
  • ルールの確認: 「「類似する」とは具体的にどういう条件ですか？」→「購入した商品とセットで使うような商品」と判明
  • 正しい認識: 「台所用スポンジを購入した場合、食器用洗剤や食器拭きなど一緒に使うもの」
• 事例2「ユーザー」の改善:
  • アクターの確認: 「学生のユーザーはどうなりますか？」→「学生はありえない」→「ここでのユーザーとは？」と問い直す
  • 文脈・目的の確認: 「これは法人顧客です」→「法人でなければならない理由は？」→「法人が仕事で使う物品を一括大量購入しやすくするため」と判明
  • ルールの確認: 「個人と法人でルールが違いそうですね」→「割引・見積もり・請求書発行のフロー、担当者が複数人になるケースもある」と判明
  • 正しい設計: 個人ユーザーモデルとは別に、会社→組織→法人アカウントという独立したドメインモデルを設計

■ 9. 意味解釈で陥りがちな注意点

• 自分の文脈で意味解釈しないよう注意:
  • 誰もが陥りがちなのは、相手の文脈ではなく自分の文脈で言葉の意味を解釈してしまうこと
  • スキーマ理論によると、人間はどうしても「自分の知識や経験」というレンズを通して物事を見てしまいがち
  • 自分の文脈を捨て去り、相手の視座に立つ姿勢が重要
• 「言葉には厳密な定義があるはずだ」という罠:
  • 「言葉には厳密な一意の定義があるはずだ」と思い込むと、文脈による意味の違いを理解できなくなる
  • 数学・科学など理系出身者ほどこの罠にハマりやすい
  • 重要なのは一般定義への拘泥ではなく、「相手の言葉の背後にある意図や意味は何か」を正確に理解する姿勢

■ 10. ユビキタス言語との接続

• 本セッションで語っていた内容は、ドメイン駆動設計（DDD）に登場する「ユビキタス言語」の話であった
• あえてセッション冒頭でユビキタス言語と明かさなかった理由は、「用語集だ」という先入観（スキーマ）に引きずられて本セッションの意義の理解が歪むことを防ぐためだった
• ユビキタス言語とは:
  • 開発の利害関係者同士で認識を揃えるために使う言葉
  • 適用可能な範囲は「境界付けられたコンテキスト」まで
  • 同じ「ユーザー」という言葉でも、コンテキストが違えば意味も取り巻くルールも異なる（例: 営業コンテキストでは「見込み客」、カスタマーサポートコンテキストでは「問合せ客」）
• ユビキタス言語のドキュメントには「文脈」と「取り巻くルール」の項目が必要であり、ない場合は追加して見直すべき
• ユビキタス言語の策定にはAIを活用できる（プロンプトに言語ゲーム・スキーマ理論の観点、アクター・目的・文脈・ルールを組み込む）

■ 11. AIとの関係と結論

• 言葉の意味解釈が不正確なままAIに開発を指示しても、プロダクトを正しく作ることは困難
• 文脈が不十分だとAIも意味を取り違えて混乱し、ユーザーモデルに対して疑いなくフィールドを追加するなど、人間と同様の誤りを犯す
• 「AIは増幅器」であり、使い手である人間のスキルを増幅するものである
• 地に足のついた基礎力があってはじめてAIで能力を増幅できる
• 結論（基本こそ奥義）:
  • 物事を正確に理解するために言葉の意味を整理する
  • そのために哲学や認知科学を活用する
  • 理解した意味に基づき要件を定義し、設計と実装に落とし込む
  • 鍛錬し磨いた基礎力があってはじめてAIで能力を増幅できる

(2026/06/18)

技術選定の審美眼（2025年版） / Understanding the Spiral of Technologies 2025 edition

• 技術選定の審美眼（2025年版） / Understanding the Spiral of Technologies 2025 edition - Speaker Deck

要約:

■ 1. 概要・問題意識

• 発表者: 和田卓人（@t_wada）、2025/05/14
• JavaScript fatigue（変化が速すぎるフロントエンドのキャッチアップに疲れる）と AI fatigue（AI周りのキャッチアップに疲れる）が背景にある
• 「限界集落」として停滞し若者のいないプロダクトと、変化が速すぎて疲弊するプロダクトの極端なコントラストが存在する
• 核心的問題: 重要な変化と重要でない変化を見分けられない
  • 軽微な変化をスルーできずに消耗する
  • 重要な変化をスルーして先行者利益を取りこぼす

■ 2. 変わるものと変わらないものの基本的な考え方

• 変化が予想できないことだけは予想できる
• 技術の歴史から学び、近未来の予測を試みる
• 近未来より先は予想しようがないので、身軽であることが最大の備え
• 技術の変化の歴史は一見すると振り子に見えるが、実は螺旋構造であり同じところには戻ってこない
• 差分と、それを可能にした技術が重要
• 技術の世界は基本的に若者有利であり、螺旋の差分が見えるのがベテランの数少ないアドバンテージ

■ 3. 変わらないもの: 長生きしている技術に学ぶ

• 長生きしている代表的技術: Unix、REST/Web、RDBMS/SQL
• Unix哲学:
  • Small is Beautiful（小さいのは良いことだ）
  • 一つのことをうまくやる（Make each program do one thing well）
  • KISS（Keep It Small and Simple）
  • すべてはファイルであり、そのほぼすべてがプレーンテキスト
  • プログラムは標準入力と標準出力でプレーンテキストを扱うフィルタ
  • 成功失敗は終了ステータスで示す
  • パイプを介して40年前のコードと今書いたコードがあっさりと連携できる
• REST/Web:
  • すべてはURLで示されるリソース（Adressable）
  • 少なく、統一された振る舞い（HTTP Method, Uniform Interface）
  • 状態を持たない（Stateless）
  • ハイパーリンクで状態遷移（Connectedness）
  • 多様な名詞と少ない（制約のある）動詞
  • 良くできた分散システムとしてのWeb
• RDBMS/SQL:
  • 強固で数学的な背景を持つ閉じた系
  • すべてが関係/集合（テーブルも、クエリの結果も関係/集合）
  • 少なく、統一された操作（SELECT, INSERT, UPDATE, DELETE）
  • SQLはRDBMSだけのものではなくなった
  • 技術の螺旋はNoSQLを回りNewSQLへ
• 3技術に共通するもの: 制約がもたらす共有と相互接続性の高さ
  • インタフェースが狭く限定的
  • 振る舞いの種類が少ない
  • 実装に依存しない
  • 接続と再利用が時間をまたいでいる
• 「すべては○○○である」という抽象化と閉包性:
  • Unix: すべてはファイルとフィルタである
  • REST/Web: すべてはリソースである
  • RDBMS/SQL: すべては集合である
  • 閉包性とは結果も○○○に閉じるような系の強さであり、ファイルの中身とコマンド実行結果の同一視、SQLの結果とテーブルの同一視がその例

■ 4. 変わるもの: アーキテクチャの螺旋の例（7つの時代）

• クライアント・サーバー時代（1990年代前半〜2000年）:
  • LAN上でのClient/Serverアーキテクチャが確立（TCP/IP、NetBIOS）
  • 2層アーキテクチャ（クライアントがUI担当、データベースサーバーがデータ保存・処理）
  • Visual Basic（VB）やDelphiがビジネスアプリ開発の主流に
  • 課題: デプロイの複雑さ、スケーラビリティの限界、ビジネスロジックの分散による保守性の低下、ストアドプロシージャの移植性の課題
• 初期WebとエンタープライズJava時代（1995年〜2004年）:
  • PHP、ASP、JSP、Java Servletなどのサーバーサイド技術が急速に発展し動的なWebページ生成が可能に
  • J2EE、EJBといった企業向け技術スタックと、XML、SOAPプロトコル、WSDLの標準化
  • SOA（Service-Oriented Architecture）の考え方が広まり再利用可能なサービスコンポーネントの概念が確立
  • 以前の課題の解決: デプロイの複雑さの解決（ブラウザベースへ移行）、スケーラビリティの改善（3層アーキテクチャ）、ビジネスロジックの集約、移植性の向上
  • 新たな課題: ユーザー体験の制限（完全リロード）、ステートフル設計の課題、クライアント側の表現力の限界、エンタープライズ開発の複雑性（XML設定の複雑化）、SOAの重量級実装（ESBが複雑で運用コスト高）
• 動的WebとREST APIの台頭期（2004年〜2010年）:
  • Ajaxがきっかけになりボタンで JavaScriptの再発見につながる（2005年）
  • Adobe FlashやMicrosoft Silverlightなどのプラグイン技術によるリッチインタフェース
  • Ruby on Railsが「設定より規約」を提唱し、開発者体験（DX）という概念の先駆けに
  • RESTful Web設計の理解が広まり、Rails以後のフレームワークによる事業の早期立ち上げが可能に
  • 以前の課題の解決: Ajax非同期通信でページ遷移問題の解決、jQueryによるDOM操作の簡素化、開発生産性の向上、ステートフル設計の課題緩和
  • 新たな課題: ブラウザ間の互換性の問題（IE vs. 他ブラウザ）、JavaScriptの構造化標準の不在、セキュリティ懸念（XSS、CSRF）、プラグイン依存、インフラ調達・運用の硬直性
• モバイル&クラウド革命期（2008年〜2015年）:
  • iPhone（2007年）とAndroid（2008年）登場によるモバイルアプリ開発の新時代
  • RESTful JSON APIの一般化とXMLからJSONへのデータ形式の移行
  • APIファーストの考え方の普及とフロントエンド/バックエンド分離の明確化
  • AWS、Azure、Google Cloudなどクラウドプラットフォームの台頭
  • NoSQLデータベースの台頭による大規模データ処理と水平スケーリング
  • IaC（Infrastructure as Code）の普及（PuppetやChefなど）
  • 初期SPA（Backbone.js 2010年, AngularJS 2010年）の登場
  • 以前の課題の解決: プラグイン依存からの脱却（HTML5へのシフト）、レスポンシブWebデザインによるマルチデバイス対応、クラウドによるオンデマンド消費へのシフト、水平スケーリングモデルの実現
  • 新たな課題: モバイルプラットフォーム間の互換性の欠如（iOS/Android個別開発）、REST APIの設計と管理の複雑さ、REST APIのフェッチング問題（オーバーフェッチング・アンダーフェッチング）、クラウド環境での運用・デプロイの複雑さ、環境依存性の問題、アプリ審査プロセスのボトルネック
• モダンWebフロントエンド期（2013年〜2018年）:
  • React、Angular、Vue.jsなどモダンJavaScriptフレームワークの登場
  • VDOMによるDOM操作の効率化と宣言的UIプログラミングの実現
  • コンポーネントベースアーキテクチャによるUI再利用性と保守性の向上
  • HTML5の標準化（2014年）とPWA（2015年）の登場によるネイティブアプリに近い体験の実現
  • Node.jsとnpmの普及によるフロントエンド開発ツールチェーンの強化
  • TypeScriptの成長による大規模フロントエンド開発での型安全性の向上
  • BFF（Backend For Frontend）パターンの普及
  • GraphQL（2015年オープンソース化）によるクライアント主導のデータ取得パラダイムの登場
  • 以前の課題の解決: SPAによるページ遷移なしのシームレスなインタラクション実現、ES6の標準化とCJSバンドラーによるJavaScriptの構造化・モジュール化手法の確立、GraphQLによりREST APIのフェッチング問題を解決、アプリ審査プロセスのバイパスが可能に
  • 新たな課題: フレームワークとツールの急速な変化（JavaScript疲れ）、初期ロード時間の長さ（バンドルサイズ肥大化）、SEO対応の難しさ（クライアントサイドレンダリング）、状態管理の複雑さ（Reduxなどのボイラープレートコード）、APIの設計と統合の複雑化、ビルドプロセスの複雑化
• マイクロサービス&分散システム期（2014年〜2020年）:
  • NetflixやAmazonの成功事例に基づくマイクロサービスアーキテクチャの定義化と普及
  • Docker（2013年）とKubernetes（2014年〜）によるコンテナ化とオーケストレーションの標準化
  • Terraform（2014年）登場によるクラウドインフラのプロビジョニング自動化
  • OpenAPI/Swagger、gRPCなどAPI設計・ドキュメント化ツールの普及
  • DevOps文化とCI/CDの普及: 開発と運用の融合、自律的な小規模チーム編成、継続的な自動デプロイの標準化
  • ドメイン駆動設計（DDD）と「逆コンウェイ戦略」によるビジネス変化への迅速な対応とチーム自律性の両立
  • 以前の課題の解決: マイクロサービスによるドメイン分割とチーム自律性の実現、Dockerコンテナによる「開発環境と本番環境の一致」の実現、Kubernetesによるコンテナオーケストレーションの標準化、OpenAPI/Swagger・gRPCによるRESTful API管理改善
  • 新たな課題: 分散システムの複雑さ（結果整合性、サービス間連携、トランザクション管理、障害検出の困難さ）、開発者の認知負荷の増大（クラウドネイティブ技術、Kubernetes、CI/CDなど多数のツールの習得と管理が必要）
• 再統合と最適化模索期（2020年〜）:
  • マイクロサービスからモジュラモノリスへの揺り戻しと適切なバランスの追求
  • プラットフォームエンジニアリングの台頭
  • NewSQLデータベースの実用化と普及（分散環境でもSQLとACID特性を提供）
  • JAMstack（JavaScript、API、Markup）アーキテクチャによる静的サイト生成とクライアントサイドの動的機能の組み合わせ
  • Core Web Vitalsの標準化によるユーザー体験指標に基づく最適化
  • アイランドアーキテクチャによる部分的ハイドレーションと最適なJS配信
  • エッジコンピューティングの台頭によるCDNから計算処理への発展
  • WebAssembly（Wasm）の登場と広がり
  • React Server Componentsによるクライアントとサーバーの境界再定義
  • 以前の課題の解決（現在進行形）: マイクロサービスとモノリスの中間の探求、NewSQLデータベースによる分散環境でのACID特性の実現、レンダリングパラダイムの再進化（クライアント・エッジ・サーバーの適切な役割分担）、プラットフォームエンジニアリングによる開発者向け内部プラットフォーム（IDP）の構築、AI支援型開発ツールによるコード生成の登場
  • 新たな課題（生煮え）: 既存マイクロサービスシステムから新たなアプローチへの移行の複雑さ、フロントエンドとバックエンドの境界のあいまい化による責任分界の再定義の必要性、エッジコンピューティングとサーバーレス技術の最適な組み合わせの模索、WebAssemblyの適切なユースケースの見極め、AIとの共存による開発プロセスとスキルセットの再定義の必要性

■ 5. 技術の螺旋の具体例: 集中と分散の循環

• 集中・シンプル（初期Web）→分散・複雑（エンタープライズJava/SOA）→集中・シンプル（動的WebとREST API/Rails）→分散・複雑（マイクロサービス）→再集中・シンプル（モジュラモノリス）という螺旋
• 初期WebからエンタープライズJava/SOAへ向かった理由: 初期WebのシンプルなモノリシックなアプリケーションはSpring規模のエンタープライズアプリケーションに必要な再利用性・スケーラビリティ・分散トランザクションを扱う能力に欠けていた
• 動的Web/RailsからマイクロサービスへRails移行した理由: Railsなどの集中アーキテクチャはスタートアップ期には理想的だったが、事業規模の拡大とともに組織スケーリング・チームの自律性・優先的スケーリングの課題が生じた

■ 6. Game Changerたち

• 決定的な違いをもたらした技術: Ruby on Rails、Cloud Computing、Smartphone、Docker、React、LLM・Agentic Coding
• 量的な変化が質的な変化をもたらす:
  • Railsの生産性はスタートアップ企業に必要な初期速度と仮説検証を可能にした
  • クラウドはシステム開発のコスト構造やボトルネックを大きく変え、開発と運用の関係の変革を促した（DevOps）
  • DockerはコンテナStartupの圧倒的な速さと再現性の高さでコンテナ時代の扉を開いた
  • LLMの出現自体が量的→質的変化であり、結果出現した世界も量的→質的変化
  • 圧倒的な安さ/早さ/速さの獲得で不可能が可能になり、新たなものが見えてくる
• 考えることを大きく減らした変化:
  • ReactによりVDOMで富豪的にデータを更新してもレンダリングコストの心配をしなくて良くなった
  • データ更新の方向が一方通行なので状態が一意に定まり混乱しない（Single source of truth）
  • チャット型AIは一手目を考えるコストを劇的に下げた
• スルーするか、しないかの判断基準:
  • Game Changerそのものを採用する必要は必ずしもないが、それらが変えた後の世界は知っておく必要がある
  • 開発に関わる労力（コスト、心的コスト）を矢印で表した際に、矢印を圧倒的に短くしてコスト構造を大きく変えるもの、あるいは矢印を折るようなジャンルそのものを不要にするものはスルーしがたい
  • そこまでではない変化は「お好みで」となる
  • その技術が何のために出てきて、何をどのくらい変化させるのか見切れればスルーできる

■ 7. LLMとAgentic Codingはスルーできない

• LLMはスルーできない:
  • 今まさに世界を不可逆に変えているGame Changer
  • 人間とAIが互いの強みを活かし、協力して新しい価値を創造する
  • 道具としてのLLM、壁打ち相手としてのLLM
  • 「愚者は知識を問い、賢者は議論をする」
  • 「AIは知識の代替ではなく増幅器」
  • 労力は外注できるが、能力は外注できない
• Agentic Codingはスルーできない:
  • AIが助手席から運転席へ、人間が運転席から助手席へ
  • 広義のVibe Codingと狭義のVibe Codingがある
  • 個人的にはClaude Codeを月額固定額にしてからプログラミング観が変わった
  • Claude CodeはCLIだからUnix哲学との連続性がある
  • 従量課金から月額固定額になることで「試行回数を増やして積極的に使い倒さないと損」という心理状態に変化し、無視できない効果が生まれた
• 自動化（Automation）から自働化（Autonomation）へ:
  • Agentic CodingとはReconciliation Loopであり、望ましい状態を宣言的に定義し評価関数（適応度関数）を与えることでエージェントがその状態に収束するよう自律的に働く
  • AIは自走するが暴走/迷走もする→ガードレール設計としてのソフトウェアエンジニアリングや技術の3本柱（バージョン管理、テスティング、自動化）の重要性がさらに増している
  • 人間と複数のエージェントが互いに独立/並列で仕事を行い、問題があるときだけエージェントから人間に伝えるという形態へ

■ 8. まとめ

• 変わらないもの: 生き残る技術には特徴がある→その背後にある抽象の力を理解する
• 変わるもの: 技術の変化は螺旋状→螺旋の差分と、それを可能にした技術を理解する
• Game Changerを見抜く目を養い、ビッグウェーブにはしっかり乗る
• LLM / Agentic Codingはスルーできない

関連：

• Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition

(2026/06/18)

エンジニアリング戦略の作り方 / Crafting Engineering Strategy

• エンジニアリング戦略の作り方 / Crafting Engineering Strategy - Speaker Deck

要約:

■ 1. 背景: AIコーディング導入の失敗パターン

• 経営陣がVibeコーディングブームに感化され、全社的にAIコーディングの活用を指示
• 3か月後に17件、半年後に33件のPoCが立ち上がり、コード生成・テスト作成・リファクタリング・障害調査など多様な取り組みが生まれた
• 各部門でそれぞれの懸念が噴出:
  • 開発支援部門: 「標準を決めて云々」
  • 事業部門: 「共通の仕組みを待つとプロダクト開発が遅くなるから独自で」
  • セキュリティ部門: 「ソースコードや機密情報を外部モデルに送るのはリスク」
  • 法務部門: 「著作権・ライセンス・生成コードの責任範囲を整理する必要がある」
  • 経営: 「スピード感を持って進めてください」
• 表面上は「全社63件のPoC進行中」「300超えるプロトが完成」と報告されたが、ほぼすべてが本番運用に至らず、アウトカムが消えた
• 失敗の根本原因:
  • 戦略が定められず、あるいは言語化されておらず、関係者間でブレブレ
  • 現状認識（課題）のないままとりあえずPoCで何か作っており、「やる・やらない」のトレードオフが存在しない
  • 現場定着が想定されておらず、運用開始後の振り返りもない

■ 2. 本講演のゴールと紹介書籍

• 書籍: 『エンジニアリング戦略の作り方: エンジニアリングの難局を打破する意思決定』（Will Larson著、岩瀬義昌・岩瀬迪子訳、O'Reilly Japan）
• 本日のゴール:
  • 同書の内容をざっくり知る
  • 戦略そのものの考え方を知る

■ 3. 戦略の定義

• 戦略の定義は論者によって多様:
  • アルフレッド・チャンドラー: 「企業の長期的な目標と目的を決定し、それらを達成するために必要な行動方針を採用し、資源を配分すること」
  • ヘンリー・ミンツバーグ: Plan・Ploy・Pattern・Position・Perspectiveの5Pから成る
  • マイケル・ポーター: 「独自で価値あるポジションを選び、それを支える活動システムを構築すること」
  • リチャード・ルメルト: 「診断」「基本方針」「（一貫した）行動」から成る
• 本書はルメルトの定義をベースとしている
• 「戦いを略す」という語源的解釈: ゴールに到達するために最も競合と戦わずに済むルートを選ぶことが戦略
• 悪い戦略の例: 「世界一の企業になる」「顧客満足度を最大化する」「革新的で持続可能な成長を実現する」（トレードオフを含まない目標は戦略ではない）

■ 4. 書籍の構成

• 第I部: エンジニアリング戦略とは何か、誰が・いつ・なぜ書くのか
• 第II部（コア）: 探究・診断・洗練・方針策定・運用の5ステップでの戦略策定
• 第III部（コア）: 洗練に使うツール×3の説明
• 第IV部: エンジニアリング戦略の具体の策定プロセスや戦略の具体例
• 第V部: 今後に向けて

■ 5. 第I部: 戦略が言語化されていないことによる影響

• 誤解のリスク:
  • 意思決定の場にいた人物が、後から他の関係者にどれだけ正確に情報を伝えられるかに依存（えてして不正確）
• チーム間の一貫性の欠如:
  • チーム間で不公平な判断が起きてくる（例: 昇進判断）
• 時間経過による一貫性の喪失:
  • 方針が文書化されないと、時間とともに考えがズレて別の実装や暗黙的な判断が入り込んでしまう
• 新任リーダーへのリスク:
  • 過去の意思決定背景が共有されないと、新任リーダーが文脈を理解できず、成功が個人の学習力に依存してしまう

■ 6. 第I部: 戦略に取り組むべき状況とタイミング

• 戦略に取り組むべきでない状況:
  • 既に同じ課題に取り組むチームがある場合は、新戦略を作るより直接協力するのが最善
  • 即効性を求めるお気持ちドリブンで戦略に着手すると、長期的な変化につながりにくい（トップダウン戦略は一部で無視されやすく、ボトムアップ戦略は浸透に時間がかかる）
  • 戦略を立てすぎるのも悪いパターンであり、そもそも作らない方が良いことも多い
• 戦略に取り組むべきタイミング（組織の3レベル）:
  • a. 全体として一貫している（例: 新規コードはモノリシックなコードベースに実装）→ 不要
  • b. チーム内では一貫しているが、チーム間では不一致がある（例: プロダクトチームとプラットフォームチームでズレ）→ 必要
  • c. 個人レベルでばらついている（例: モノレポとポリレポで作られていく）→ 必要

■ 7. 第I部: 寛容的戦略と規範的戦略

• 寛容的戦略:
  • 現場やチームごとの裁量を残しておいて、ローカルでの上書きやカスタマイズを許容する戦略
  • 強制力が小さく導入しやすいため、低コストで始められる
  • 一方で、広まると情報が薄まり、抜け落ちやばらつきが起きやすい
• 規範的戦略:
  • 組織全体で守るべきルールや標準を明確にして、例外を減らして統一を図る戦略
  • 品質や判断基準を組織全体で揃えやすく、確実な実行につながりやすい
  • 一方で、強制力がほぼ必須であり、導入・維持コストが高い

■ 8. 第II部: 戦略を作る5ステップ

• 探究:
  • 業界全体のアイデアやプラクティスを調べ、最新研究や先端事例を把握
  • 過去の類似課題から学ぶ
  • アンカリング効果を回避するために探究が必要（「今流行っているから」「前職で慣れ親しんだ技術スタック」などを避ける）
  • 探求の方法（書籍の簡易版）: トピックに関するリソースを収集 → リストにまとめて優先度づけ → 深く読んでノートを取る → 一旦打ち切る
  • 広く読む（業界関連書籍で知らないテーマをピックアップ）と狭く読む（今取り組んでいるトピックをじっくり読む）を組み合わせる
• 診断:
  • 自分たちが抱える課題を明確化する（すぐに解決に着手しない）
  • 課題の本質を説明する仮説や根本原因を特定
• 洗練:
  • アイデアや仮説を現実に照らす + ツールを使い検証して、実行可能なレベルまで磨き込む
• 方針:
  • 解決に向けた意思決定や判断基準を明確化して、組織の方向性を定める
• 運用:
  • 方針を実際に機能させる仕組みを整備して、継続的に進捗を確認する
  • 運用がなければ、戦略を立てただけで何も起きない

■ 9. 第II部: 運用のパターンとアンチパターン

• 定番パターン:
  • 承認と助言: 現場の詳細によってはやりたい方針から逸脱するかわからない場合に、承認と助言の場が一般的な対応プロセスとなる
  • 点検: ある方針が成果を上げているか、修正が必要かを判断する。「どこで」「どのように」「何を」トラックするか具体的に定義
  • ナッジ: 対象の人・チームにだけ気づいてもらえるように知らせて行動を後押しする（点検と組み合わせると効果的）
  • ドキュメントとトレーニング: ナレッジベースが陳腐化しやすい点と研修の効果が残りにくい点に注意。情報の集団免疫を意識する
  • 将来への先送り: 現場ではどうしようもない事象に対して、lazyな意思決定をして先送りを明記する
  • 会議: これまでの内容を組み合わせて使う万能な仕組み。コストが高いが試行錯誤は簡単
• アンチパターン:
  • トップダウンの宣言: 著者の経験上、行動変容につながるのは滅多にない
  • 教育という名の周知: （書籍参照）
  • 強制参加のトレーニング: （書籍参照）
  • 文化の問題として捉える: 文化を変えるのは一筋縄では行かない。色々なテクニックを使って運用に定着して初めて文化として根づく

■ 10. 第III部: 洗練に用いるツールセット

• 戦略テスト: いきなりドカーンを止めようという話（詳細は書籍参照）
• システムモデリング: （書籍参照）
• Wardleyマップ:
  • 日本ではあまり見かけないが、非常に有用なツール
  • 縦軸はユーザーからの可視性（上に行くほど見える、下に行くほど見えない）、横軸は進化度（ジェネシス・カスタム・プロダクト・コモディティ）
  • 成功する戦略には制約と状況の理解が必須。WardleyマップではこれをSituation Awareness（状況認識）と呼ぶ
  • この業界は常に激変するダイナミックな環境であり、エコシステムを含む状況が常に変化し続けている
  • Wardleyマップを描くことで、「思いつき」ではなく状況理解に基づいて思考できるようになり、周囲の関係者に脳内にある前提を共有しやすくなる

■ 11. 第IV部: 具体的な戦略例（Stripe API廃止）

• 書籍には多数の戦略ドキュメント具体例が掲載されている（Uber、Calm、Stripeなど）
• Stripeの「API廃止しない」方針の例:
  • 方針: 「やむを得ない事情がない限り、APIを廃止しない。たとえサポート維持に高い技術的コストがかかるとしても、そのコストは当社で負担する」
  • 例外はAPIレビューで承認後、CEOによって承認が必要
  • 診断: 「エンジニア中心の小さなスタートアップであれば、新しい決済APIの組み込みは容易に思えるかもしれない。しかし専任エンジニアがいない中小企業や、多数のステークホルダーが絡む大企業にとって、外部APIの変更に対応するのは極めて困難な作業である」

■ 12. まとめ

• 効果的なエンジニアリング戦略は「探究」「診断」「洗練」「方針」「運用」の5要素で構成される
• 戦略が言語化されていないことは、誤解・不一貫性・時間経過による劣化・新任者への情報断絶を招く
• 戦略は常に新規に作ればよいわけではなく、組織の一貫性レベルによって取り組むべき状況を判断する
• 戦略には寛容的戦略と規範的戦略の区別があり、状況に応じて使い分ける
• 運用なき戦略は絵に描いた餅であり、方針の定着に向けた仕組みが不可欠
• 書籍の詳細はWill Larson著『エンジニアリング戦略の作り方』を参照

(2026/06/17)

エンジニアと英語 ― 言語だけではない「ハングリー精神」という生存競争

• エンジニアと英語 ― 言語だけではない「ハングリー精神」という生存競争｜てくの

要約:

■ 1. 経歴と英語公用語化との遭遇

• 筆者は競争を避けて人生/キャリアを歩んできた
  • 学生時代は高専受験に失敗し地元の公立工業高校へ進学した
  • 大学はAO入試で入学し学力不足により1年留年した
  • 就活は不調に終わりインターン先のWeb企業に拾われる形で入社した
• 1社目は外国籍エンジニアが多い環境であった
  • 入社時のTOEICは400点台で英語のクラス分けは最下位レベルであった
  • 数年間の多国籍チームでの業務を通じTOEICは900点程度に到達した
  • スピーキングもCEFR B2レベルに達した
• 2社目は急速に英語公用語化を進める純日本企業であった
  • 軽い気持ちで転職したが英語公用語化は言語の違いだけの問題ではなかった

■ 2. 口頭ミーティングにおける英語の壁

• グーグル日本法人初代社長の村上憲郎氏のインタビュー記事に強く同意した
  • 英語ができないだけで頭が悪いと判断されるという内容であった
  • 外資系では英語ができないとチンパンジー扱いされるという内容であった
• テキストコミュニケーションとリスニングには大きな問題はなかった
  • SlackではAIの力も借りてネイティブ級に対応できた
  • リスニングで致命的に困ることはなかった
• 口頭のミーティングでは機能不全に陥った
  • 高度なエンジニアリングの思考はあっても英語で表現できなかった
  • 単語を並べるだけでは議論で相手を説得できなかった
• 英語が流暢に出てこないことでスタートラインに立てなかった
  • 間違った技術的判断を見逃すことがあった
  • 知性が低いと見なされエンジニアとしての尊厳が削られた

■ 3. 「緩やかな多国籍」と「生存競争」の違い

• 打ちのめされた要因は英語力不足だけではなかった
  • 文化の違いとハングリー精神の差が大きな要因であった
• 1社目には緩やかな多国籍の空気があった
  • 開発資料やコードレビューは英語だがSlackやミーティングは母国語や通訳を介して行われていた
  • 日本語が堪能な中韓の留学生や在日経験の長いエンジニアも多かった
  • PdMや役員も多国籍でお互いの文化や言語に歩み寄る空気があった
• 2社目には生存競争の空気があった
  • アジア各国から直接採用されたハングリー精神の強いエンジニアが集まっていた
  • 彼らは英語を当然のツールとして扱い活躍と昇進に飢えていた
  • 圧倒的な熱量で技術を語り自己アピールを行っていた
• 競争を避けて生きてきた筆者にとってこの環境は言語の壁以上に高い障壁であった

■ 4. 英語化の現場に抜け落ちていたもの

• 在宅勤務中に妻からの厳しいフィードバックを受けることが増えた
  • 妻は3カ国語を操るマルチリンガルで競争社会を生き抜いてきた人物である
  • ミーティング後に内容が伝わっていないという指摘を受けた
• 妻と会社には歩み寄りの有無という違いがあった
  • 妻は厳しい一方で大切な場面では筆者の分かる言葉まで降りてきた
  • 会社では歩み寄りが構造的に抜け落ちていた
• 日本語中心のビジネスサイドと英語化された開発現場の間に行間が生まれていた
  • 仕様を定義するビジネスサイドは日本語中心であった
  • 開発現場のみが急速に英語化されていった
• 英語化という挑戦自体は合理的だが見落とされた価値があった
  • 日本語を覚えようとする外国人エンジニアを歓迎する価値があった
  • 英語が完璧でない日本人エンジニアのドメイン知識を尊重する価値があった
• 言語と文化のすき間を埋める人材は評価されにくかった
  • 多少英語が話せる日本人エンジニアや日本語ができる外国人エンジニアがすき間を埋めていた
  • 1社目では日本語が流暢な外国人同僚がその点を評価されないと話していた

■ 5. 結論: 自身の選択と組織の今後

• 言語の壁を越えて組織を動かすには努力以外に才能や適性が必要である
• 筆者には才能も生存競争を勝ち抜くハングリー精神もなかった
• 筆者は強者だらけの土俵で戦うことをやめる選択をした
  • 日本人エンジニアが母国語で活躍できる企業で生きていくことを決めた
• 2社目の開発現場では日本人エンジニアの割合が30%を切っていた
  • 筆者のような人材が限界を悟り離職していった結果と考えられる
• 残される組織には言語化されない空気を読む橋渡し役が失われるという課題がある
  • 英語が苦手なビジネスサイドと日本のドメイン知識を持たないエンジニアだけが残る
• 縮小する国内市場から脱するためには英語化という痛みを伴う選択も避けられない現実がある

(2026/06/16)

「技術の人じゃないね」と言われたエンジニアの話

• 「技術の人じゃないね」と言われたエンジニアの話 - めるノート

要約:

■ 1. 「マネージャー向き」と言われ続けてきた経験

• エンジニアになってから何度も「マネージャー向きですね」と言われてきた
• 問題を整理すること、複雑な状況を構造化すること、人の認識を揃えることが好きである
• 技術的な課題が絡み合っている状況を見ると、まず図にしたり論点を書き出したりしたくなる
• そうした振る舞いに対して「それってマネージャーの仕事ですよね」と言われ、実際にマネージャーになったこともあった
• 時にはより直接的に「技術の人じゃないね」と言われたこともあった
• 当時はその言葉を半分受け入れつつも、ずっと違和感を持っていた

■ 2. マネージャーになりたいわけではなかった

• マネージャーという仕事を否定したいわけではなく、優れたマネージャーにも多く出会ってきた
• ただ、自分がやりたいこととは少し違っていた
• 人事評価に強い興味があるわけではなく、組織図を考えたいわけでも、採用や予算管理をやりたいわけでもない
• 一方で、システムがなぜ複雑になったのか、なぜ障害が起きたのか、なぜチームが同じ問題を繰り返しているのかは気になって仕方がない
• 自分が本当にマネージャー向きなのか、ずっと不思議に思っていた

■ 3. コードを書くのが一番得意なわけでもなかった

• コードを書くのは嫌いではないが、世の中にはもっと速く、もっと深く、もっと美しくコードを書く人がいる
• そうした人たちを見て、自分は本当に優秀なエンジニアなのだろうかと思うこともあった、特にキャリアの初期はそうだった
• エンジニアの価値はコードを書くことで決まるとどこかで思っていたし、そういう空気を感じることもあった
• コードを書くのが一番得意ではなく、マネージャーになりたいわけでもないという、その間で長いこと居場所が分からなかった

■ 4. AIは仕事を奪わなかった

• AIが登場したとき、コードを書く速度の速さに最初は少し焦り、これから何が価値になるのか考えた
• 実際に使い始めると予想とは違うことが起きた
• 仕事は減らず、むしろ増えた
• コードを書く時間が短くなった分、何を作るべきか、どこにリスクがあるのか、なぜこの問題が起きたのか、どうすれば同じ失敗を防げるのかを考える時間が増えた
• 自分は以前から、その仕事をしていたのだと気づいた

■ 5. それは本当にマネジメントなのか

• 問題を整理すること、複雑さを減らすこと、技術的な意思決定を支援すること、将来のリスクを見つけること、システムをより良い方向に導くこと
• これらが本当にマネジメントなのかを改めて考える
• マネジメントと一部重なる部分はあるが、それらの多くは技術そのものなのではないかと最近思っている
• コードを書くことだけが技術ではない
• 設計も、運用も、障害対応も、複雑な状況を整理することも技術である
• AIによってコード生成のコストが下がった今、そのことが以前より見えやすくなった

■ 6. やっと説明できるようになった

• AIによって新しい能力が手に入ったわけではなく、やっていたことは昔から変わっていない
• 「マネージャー向きですね」と言われるたびに感じていた違和感と、「技術の人じゃないね」と言われるたびに感じていた居心地の悪さの理由を、長い間うまく説明できなかった
• 今なら少しだけ分かる気がする
• マネージャーになりたかったわけではなく、コードを書くことから逃げたかったわけでもない
• ただ複雑なものを理解して、少しでも単純にしたかった
• それもまた、エンジニアリングである

MEMO:

• うんうん、それもまたエンジニアリングだね

(2026/06/16)

japanese-tech-writing/SKILL

• japanese-tech-writing/SKILL · GitHub

日本語の技術文書・書籍原稿の文章規範。整形（一文一行、引用ブロック、脚注、コラム記法）、段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。

(2026/06/16)

2026年6月版 開発中の機能を小分けにして本番環境にどんどん出すためには

• 2026年6月版 開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記

要約:

■ 1. 背景と概要

• 2018年に書いた記事（ビッグバンマージを避けて少しずつコードをマージするアプローチ）を2026年時点で更新
• コーディングAIを活用した現代の開発フローの考え方と望ましい進め方を整理

■ 2. 2018年版フローの課題

• 設計・全容の共有が難しい:
  • Pull Requestを小分けにすることで全体像が見えにくくなる
  • リモートワーク普及によりホワイトボードでの認識合わせが困難になった
• レビュワーの分断:
  • GitHubでランダムにレビュワーをアサインすると、シリーズ物のPRを別人がレビューすることになり全体の整合性が失われる
  • チームの対策: レビュワーをプロジェクト単位で固定し、実装者と別の担当者がQAを行う
• 実装速度とレビュー速度のミスマッチ:
  • コーディングAIにより数分でコードを生成できるが、レビューに1日待つ状況が生じる
  • 前半のPRにレビューで方針転換が生じると後続PR全体に変更が波及し、誰も嬉しくない結果になる

■ 3. 動くプロトタイプの活用

• 2026年時点ではコーディングAIに依頼することで数分〜1時間以内に動くプロトタイプを入手できる
• プロトタイプを作ることで以下が明確になる:
  • 企画情報だけで仕様として足りているか
  • 曖昧で検討が必要な仕様が残っていないか
  • 当初の設計に矛盾や破綻がないか
• 動くものが手に入ること自体に大きな価値がある
• ステークホルダーとの共有に活用する:
  • ディレクターに動きを確認してもらい、希望や未決事項を議論する
  • 両方の案を実装して比較検討することも可能
  • エンジニアとはコードを見ながら完成時点の設計を事前に議論できる

■ 4. レビュワーに合わせたPull Request分割

• プロトタイプは速度重視で作成する:
  • エッジケース、エラーハンドリング、テストは省略
  • デバッグもAIに任せ、動くまで試行錯誤させる
• プロトタイプをそのままリリースはできないため、本番相当のコードへ作り直す
• 本番コードはエラーなく動作し、セキュリティや動作速度の要件も満たす必要がある
• Pull Requestの切り方:
  • レビュワーが読める量の単位に分割してPRを作成する
  • PR数とタイトルをレビュワーと事前に合意しておくことが望ましい
  • コードの前でディスカッションしながらペアプログラミングで完成させる形でも良い
• ボトルネックの変化: 実装者の速度に律速していた従来から、レビュワーの速度に律速する形へ転換

■ 5. 工程の標準化

• 2018年の環境ではイテレーティブかつスパイラルな開発が一般的だった
• 現代の工程: ビッグバンなプロトタイピングを行ってから、人間が解釈できる単位に再構築する
• 一度に見るべき情報が増加する:
  • 既存の本番コードベース
  • 作成したプロトタイプ
  • プロトタイプに対する人間のフィードバック
• 人間の認知がボトルネックにならないよう、各工程の入力と出力をスキル・手順として標準化することが有効
• 標準化の目的:
  • 誰がやっても同じ結果を期待するのではなく、誰がやっても同じ前提情報を手にできることを期待
  • 煩雑な情報収集を定型化し、取捨選択の判断を人間の仕事として残す
• タスクチケットの活用例:
  • チケット本文を着手可能な形に整形し、チームのスキルへの案内を埋め込む
  • AIにチケットを渡すことで、標準的な手順を自動的に実行させることができる

■ 6. 人間の役割: ろくろと陶芸家の関係

• 工程を書き下しても人間の仕事はなくならない
• ろくろの比喩: 回転させるのはろくろのモーターだが、土を触り器を形作るのは人間の手
• これからの開発者に求められるスキル:
  • AIが出す前情報やプロトタイプをどう整理・解釈するか
  • 複数の選択肢の中からどれを選ぶか取捨選択できるか

関連:

• 開発中の機能を小分けにして本番環境にどんどん出すためには

(2026/06/15)

AIは速度を前払いし、失敗を後払いにする

• AIは速度を前払いし、失敗を後払いにする｜Kosuke Kuzuoka

要約:

■ 1. 主論点: AIは速度を前払いし、失敗を後払いにする

• Opsera社が25万人のエンジニアを分析した2026年版ベンチマークレポートが「AIは速度をフロントローディングし、失敗をバックローディングする」と指摘
• 93%の開発者がAIツールを使用し、コーディング速度は30〜58%向上した
• 一方でPRレビュー時間は441%増大、本番インシデント数は242.7%増加、開発者一人あたりのバグ数は54%増加した
• AIは組織を速くしたが、強くはしていない

■ 2. 3つの独立した大規模調査が示す一致した結論

• 調査の概要:
  • Stanford大学による10万人エンジニアを対象とした研究
  • DORAとFaros AIの2026年データセット
  • Opseraの25万人ベンチマーク
• 個人レベルの知見:
  • Stanford研究でコード生産量が30%向上、OpseraではTime-to-PRが48〜58%短縮
  • LinearB調査では83%のエンジニアがAIを活用、GetDX Q1 2026レポートでは93%まで普及
• 組織レベルの知見:
  • Stanford研究: PR数が14%増加した企業でRework Rateが2.6倍に上昇
  • DORA/Faros 2026: PRレビュー時間の悪化が2025年比+91%から+441%へ加速、レビューなしでマージされるPRも31%増加
  • Opsera: AIが生成したコードにセキュリティ脆弱性が15〜18%多く含まれ、コード重複が10.5〜13.5%増加
  • McKinsey調査: 10社中8社が生成AIによる収益への実質的なインパクトを報告していない
  • LinearB: AIのROI測定を定量的に行っていない企業が45%、定性的にも測定していない企業が約60%

■ 3. AIが「速く作る力」を育て、「深く理解する力」を奪う問題

• Anthropicによる2026年4月の実験:
  • 未習得のPythonライブラリを用いた開発タスクをAIあり・なしの2群で実施し、タスク完了後にクイズで理解度を測定
  • AIを使ったグループの平均スコアは50%、手書きグループは67%（Cohen's d=0.738、p=0.01）
  • レターグレードにして約2段階の差であり、特にデバッグに関する問いで最大の乖離が確認された
• AIが「答え」を提供することで「なぜそうなるのか」を考えるプロセスを省略させるため、技術理解が育たない
• CoderPadが面接でのAI活用能力を測定する5つの評価軸を公開し、最重要軸として「Explanation, Ownership, and Architectural Reasoning」を挙げた
  • AIが生成したコードの設計判断・トレードオフ・代替案を説明でき、リファクタリングができる能力を指す
• 「AIを使えること」と「技術を理解していること」は明確に異なる能力であり、ほとんどの組織はこの区別を評価の仕組みに組み込んでいない

■ 4. 2〜3年後に見込まれる組織の二極化

• AIの乗数効果を制御できる企業群（優位に立つ側）:
  • コーディング速度だけでなく、Rework Rate・AIハーネスコントロール力・PR品質の複合指標でエンジニアを評価
  • 個人のAI活用の「質」を組織のFour Keysに接続するデータ基盤を保有
  • AnthropicのAI Fluency Index（24指標）やCoderPadの5軸フレームワークを採用評価・人材育成に組み込む
• AIの普及率だけを追いかける企業群（遅れて崩壊する側）:
  • 開発速度は向上するが、本番インシデント増加・セキュリティリスク拡大・技術理解の空洞化が2〜3年後に表面化
  • AIが速度をフロントローディングする間、技術的負債と人的負債を積み上げる
• Opseraのデータによると、シニアエンジニアはAIによってジュニアの5倍の恩恵を受ける
  • AIは既存のスキルを増幅させる乗数であるため、スキルなき組織にAIを普及させれば組織の弱さが5倍に増幅されるだけとなる

■ 5. 結論: 測定すべき問いの転換と具体的対応

• 問いの転換:
  • 「AIを使っているか」から「AIをどの質で使っているか」へ
  • 「個人の速度は上がったか」から「組織のアウトカムは向上したか」へ
• 具体的な対応策:
  • Four KeysにRework Rateとコード品質指標を追加導入する
  • 「速く解けた」だけでなく技術理解度を事後評価する採用設計に移行する
  • LLM Proxyを通じた個人レベルのAI活用ログから「質」を定量化するインフラを構築する
• AIが前払いした速度の代償は必ず後から請求されるため、その請求書を受け取る前に測定の仕組みを整えるべきである

(2026/06/15)

A frontier without an ecosystem is not stable

• A frontier without an ecosystem is not stable

要約:

■ 1. 今回のAI移行の本質

• これまでのプラットフォームシフトとは本質的に異なり、人間とデジタルシステム間の真の認知ループを生み出す初めての転換
• 問われているのはデジタルツールの活用ではなく、AIモデルが人間・組織の専門知識を吸収し商品化できる世界において、企業がいかに学習・IP構築・差別化・成長を続けるか

■ 2. ヒューマンキャピタルとトークンキャピタル

• ヒューマンキャピタル: 人材の知識、判断力、人間関係、独創性、パターン認識
• トークンキャピタル: 企業が構築・保有するAI能力
• トークンキャピタルが成長してもヒューマンキャピタルの価値は下がらず、むしろ高まる
• 人間の主体性がトークンキャピタル成長の原動力となる（野心的な目標設定、ドメイン横断での点と点の結合、関係構築、重要なパターン認識）
• 人間の方向性なしには、コンピュートが空回りするだけに終わる

■ 3. 学習ループの構築

• 最善のモデル選択よりも、ヒューマンキャピタルとトークンキャピタルが複利的に積み上がる学習ループの構築が本質的な機会
• タスクや職務はオフロードできても、学習はオフロードできない
• 企業の未来は人間とAIをまたいだ学習の複利化能力にある

■ 4. アーキテクチャ上の要件

• 時間とともに改善されるエージェンティックシステムを構築しつつ、自社のIPに対する制御を維持する新たなアーキテクチャが必要
• 自社の学習システムに組み込まれた「社内ベテラン」の専門知識を失わずに汎用モデルを差し替えられる設計が制御・主権の試金石となる
• プライベートevals: 外部ベンチマークではなく、ビジネスにとって重要な成果に対してモデルが実際に改善しているかを評価
• プライベート強化学習環境: 組織内部の実トレースを用いてモデルを強化
• ナレッジベース: 組織の記憶をクエリ可能にし、トークン使用を効率化
• この学習ループが企業の新たなIPとなり、改善されたワークフローがより良い学習シグナルを生成し、企業固有の暗黙知の蓄積を加速させる

■ 5. 価値集中のリスク

• 少数のモデルがあらゆる業界の価値を独占する世界は政治経済的に許容されない
• グローバル化の第一波で産業経済が空洞化した歴史的教訓（GDPは良好に見えても実際の雇用喪失は深刻だった）をAI時代に繰り返してはならない
• 一部のAIシステムだけが経済的利益を享受し、産業全体の知識が商品化されるAIの未来は社会的許容を得られない

■ 6. フロンティアエコシステムの構築

• 単一のフロンティアモデルではなく、フロンティアエコシステムの構築を優先すべき
• あらゆる企業・産業・国家に価値が広く流通し、すべての組織が制度的知識をエンコードした学習ループを所有できる環境が目標
• プラットフォームが内部で取り込む以上の価値をその上で生み出せるというエトスが基本姿勢
• 企業が自社と経済圏全体のために価値を創出し、従業員の専門知識が増幅・スケール化され、企業・コミュニティに利益が還元される構造が安定した均衡

(2026/06/15)

実装前に設計を徹底的にインタビューし、要件を明確にするためのスキル `/grill-me`

• 実装前に設計を徹底的にインタビューし、要件を明確にするためのスキル /grill-me

要約:

■ 1. コーディングエージェントの自律化と監視困難の背景

• コーディングエージェントの登場当初は、コマンド実行やコード生成のたびに承認し、逐一監視する手法が一般的であった
• AI モデルの性能向上とハーネスエンジニアリングの発展により、エージェントは自律的にタスクを完了できるようになっている
• 複数のエージェントを並行して実行したり、大規模なワークフローを構築する運用が標準化されている
• 並行して複数のエージェントを動かすことが当たり前になった今、エージェントの動きを逐一監視することは現実的ではなくなっている

■ 2. 認識のズレが引き起こす問題と設計フェーズの重要性

• 監視なしで動作するエージェントの認識のズレは、タスク完了後まで発見できない
• 要求が満たされていない場合、すべてやり直しになるリスクがある
• 要求が満たされていても、アーキテクチャの不適切さやコード品質の低さにより、コードレビュー段階で大幅な修正が必要になる場合がある
• 実装前の設計フェーズで要件を明確にし、人間と AI の間で共通理解を形成することが重要になっている

■ 3. 共通理解の形成における課題

• はじめのプロンプトで漏れなく要求や設計の意図を伝える必要があるが、実際に行うのは難しい
• 課題の種類:
  • 暗黙知の問題: 人間は無意識のうちに重要な情報を省略する傾向があり、AI は毎回ゼロから理解を構築する必要があるため影響が大きい
  • 言語化の難しさ: 複雑なシステムや抽象的な概念を言葉だけで正確に伝えることが難しい場合がある
  • 要件の未確定: 言葉にしてみると設計に漏れや矛盾があることに気づく場合がある

■ 4. プランモードの機能と限界

• 機能:
  • コードを変更せずにコードベースを調査し、変更内容の方針や手順を計画として提示する
  • 不明点があればユーザーに質問し、回答をもとに計画を修正する
  • 複数の選択肢を提示し、比較・議論しながら設計を検討できる
• 限界:
  • 設計の全体像が一度にまとめて提示されるため、ユーザーが深く考えずに「OK」と承認してしまいがちである
  • 全体像を AI が一気通貫に作成するため、人間と AI が議論しながら進めることが難しく、設計の主導権が奪われる問題が生じる

■ 5. /grill-me スキルの概要と特徴

• Matt Pocock 氏がプランモードの欠点を克服するために作成したスキル
• 計画や設計についてユーザーを徹底的にインタビューし、設計ツリーの各分岐を解決しながら共通理解に到達するまで質問を続ける
• スキルの内容はわずか 3 行で、要点は「共通理解に達するまで徹底的に質問し、設計ツリーの各枝をたどって依存関係を 1 つずつ解決する」こと
• 動作の特徴:
  • AI が質問し、ユーザーが答える形式を取るため、設計の主導権は人間側にある
  • 質問は 1 つずつ行われる
  • コードベースを調べることで疑問が解決できる場合は、エージェント自身がコードベースを調査する
  • 各質問に対して推奨回答を提示し、会話のスピードアップを図る
• 設計のテーマによっておよそ 10〜50 個程度の質問が行われ、徹底的に掘り下げられる

■ 6. 設計ツリーの概念

• 書籍『デザインのためのデザイン』（フレデリック・P・ブルックス Jr. 著）に由来する概念
• 1 つの設計判断を下すと、それに依存する複数の設計判断が必要になる木構造を指す
• 各ノードでは別の道を選ぶことができたという点が重要であり、設計空間を探索することで設計の全体像を把握しながら詳細を詰めることができる

■ 7. /grill-me スキルの活用上の注意点

• 最重要原則: AI に設計を任せきりにするのではなく、人間側で設計の構成要素をある程度把握しておくこと
• 失敗パターン:
  • 人間が質問に対して受け身になりすぎ、深く考えずに「OK」と答え続ける態度
  • 極端な例では 540 個もの質問を浴びせられたり、重要度の低い細部まで範囲が広げられたりする
• 求められる姿勢:
  • エージェントの質問に対してアクティブに回答し、どこに向かうかを決め、会話の方向性を調整するなど議論をリードする
  • 面接ではなく会話として進めることが重要
  • 自分の頭の中にある設計のイメージを AI と協力して言語化するツールとして位置づける

■ 8. 実際の使用方法と実践上の注意点

• インストール方法: GitHub リポジトリから直接コピーするか npx skills add コマンドを使用する
• 質問の忠実度によるスコープ管理:
  • 低忠実度な質問（プロトタイプなしで答えられる質問）に限定して進めることが推奨される
  • 高忠実度な質問（プロトタイプが必要な質問）が出てきた場合はハンドオフパターンを使用し、プロトタイプ作成後に再度スキルを呼び出す
• 設計スコープの管理:
  • スコープが広すぎると高忠実度な質問が多くなり、コンテキストウィンドウの限界に達しやすくなる
  • 巨大なスコープを扱う場合は、まずタスクを分解してから各タスクに個別に適用する
• プロンプトの渡し方:
  • 最初のプロンプトはあえてざっくりとした指示にとどめ、実装方法を制約として与えない
  • 実装方法ではなく必要な性質を伝えることで、AI がよりよい解を見つける余地を確保する
• 実践例（カンバンアプリへの生産性ダッシュボード機能追加）:
  • 18 回にわたる質問が行われた
  • 「完了」の定義、ボトルネックの算出・表示方法、集計スコープ、時間範囲フィルタ、グラフ描画手段、差し戻し時の扱い等が議論された

■ 9. 実装フェーズへの移行と関連スキル

• コンテキスト管理:
  • 設計フェーズ完了後に実装フェーズへ移る際、コンテキストをリセットすることは失敗パターンである
  • 設計フェーズの質問と回答のやりとりは実装フェーズのコンテキストとして引き継がれるべきである
  • コンテキストに余裕がない場合や実装が大規模な場合は、設計フェーズのやりとりを /docs ディレクトリなどにドキュメントとして保存する
• 関連スキル:
  • /to-prd スキル: 設計を PRD（Product Requirements Document）にまとめるためのスキル
  • /grill-with-docs スキル: 計画を既存ドキュメントと照らし合わせながら検証し、CONTEXT.md や ADR を決定のたびにその場で更新するアプローチを取るスキル（Matt 氏が推奨）

(2026/06/15)

もうプロンプトを書くな──「Loop Engineering」という新しいパラダイムの正体

• もうプロンプトを書くな──「Loop Engineering」という新しいパラダイムの正体

要約:

■ 1. 背景と概要

• Boris Cherny（Claude Code 責任者）の発言「もう Claude にプロンプトは出していない。Claude にプロンプトを出す『ループ』を走らせている」が本記事の起点
• Addy Osmani のブログ「Loop Engineering」、Peter Steinberger の連投を踏まえ、Loop Engineering の考え方を以下の3レイヤーで整理する
  • ニュース要約
  • 実装の中身
  • チームへの導入時の注意点

■ 2. AIパラダイムの4世代変遷

• 世代ごとの特徴:
  • 第1世代（2022-2024）: Prompt Engineering、1つの指示を磨き上げる、価値の源泉は指示の質
  • 第2世代（2025）: Context Engineering、十分な情報・前提・例を与える、価値の源泉は文脈の質
  • 第3世代（2026年初）: Harness Engineering、エージェントに馬具（ハーネス）を着ける、価値の源泉は実行環境の質
  • 第4世代（2026年現在）: Loop Engineering、エージェントを自律稼働させるシステムを設計、価値の源泉はサイクルそのもの
• 前の世代が消えるわけではなく、Prompt・Context・Harness は Loop の部品として組み込まれる

■ 3. Loop Engineering の定義と Harness との違い

• 定義: 自分がエージェントを叩く役を辞め、エージェントを叩く役を機械にやらせること（Addy Osmani）
• 1つの Loop の基本構造:
  • 人間が目的を定義する
  • AI が完了まで反復する
  • 次のラウンドが自動的に始まる
• Harness と Loop の違い:
  • Harness Engineering: 単一エージェントを対象、実行環境レイヤー、人間がプロンプトで起動、エージェントが完了を宣言
  • Loop Engineering: 複数エージェント＋スケジューラを対象、制御プレーンレイヤー、時刻・イベント・条件で自律起動、検証ゲートが合格を判定
• Harness は Loop の前提であり、Loop が Harness を置き換えるという話ではない

■ 4. Loop を構成する6つのコアモジュール

• Automations（ハートビート）:
  • 定期的またはイベントをきっかけに自動起動し、タスクを拾い上げる
  • CI 失敗・未処理 issue・最近のコミットに混入したバグなどを人間に代わって検出する
• Worktrees（防護壁）:
  • 複数エージェントを並行で走らせるための分離レイヤー
  • 各エージェントが独立した git ブランチを持ち、コンフリクト事故を防ぐ
  • Codex と Claude Code はネイティブで対応している
• Skills（記憶チップ）:
  • プロジェクトの仕様、ビルド手順、過去の意思決定を1ファイルに記録する
  • Loop が起動するたびに読み込まれ、ゼロからの推論が不要になる
• Sub-agents（牽制メカニズム）:
  • Explorer（コードベース調査・前提収集、高速モデル推奨）
  • Implementer（実装案を起草、主力モデル推奨）
  • Verifier（spec/test に照らし受け入れ判定、別モデル推奨）
  • Verifier をあえて別モデルにすることで、盲点の見逃しを防ぐ
• Connectors（腕）:
  • MCP（Model Context Protocol）経由で Linear・GitHub・データベース・Staging API・Slack などのツールと Loop を接続する
  • 「提案」にとどまらず、PR の作成・チケット更新・Slack へのメンションまで自律的に実行する
• Memory（最も過小評価されている部品）:
  • markdown ファイル、Linear のボード、会話の外にある状態記録を外部に保持する
  • 外部状態がないと翌日の Loop はゲームを最初からやり直す羽目になる

■ 5. 検証可能な Loop の5ステップ方法論

• Step 1. 目標契約（完了基準を決める）:
  • 明確な目標と範囲、定量化できる受け入れ基準、制約と境界条件、成果物の形式を設定する
  • 数字に落ちないものは Loop で扱わない方が無難
• Step 2. Agent の実行（複数ツール・複数インスタンスで進める）:
  • タスクを分解して計画を立て、ツールを呼び、必要に応じて複数インスタンスで並列実行する
  • 思考と行動の軌跡を記録する
• Step 3. 証拠によるフィードバック（テスト・ログ・スクリーンショット・CI）:
  • 自動テスト結果、実行ログとエラースタック、スクリーンショット・UIスナップショット、パフォーマンス指標、CI/CD のステータスを証拠として出させる
  • 「動きました！」という自己申告を信用しない
• Step 4. 停止条件（合格・ロールバック・人間への引き渡し）:
  • 合格: 受け入れ基準を全て満たせばデリバリー
  • ロールバック: リスク発生または目標逸脱で変更を取り消す
  • 人間への引き渡し: 人間の意思決定や介入が必要な場合はエスカレーション
  • タイムアウト: 最大イテレーション回数または時間超過で中断・現状報告
• Step 5. 経験の還元（ルール・skills・harness の更新）:
  • 成功体験はルールやテンプレートに落とし、失敗の教訓はネガティブルールやチェックポイントに落とす
  • skills と harness を更新し、ナレッジベースと同期する
  • 積み重ねることで次回の Loop が速く、安定する

■ 6. Loop vs Cron: 4つの実行方式の比較

• 手動 Prompt: コンテキストを毎回人間が補足・履歴消失、探索・ブレスト・計画評価に適する
• Loop: セッション記憶を保持・自動継承、作業中の継続的状態監視・完了までに適する、コストと脱線リスクがある
• システム Cron: コールドスタート・記憶なし、固定の定期タスク（ログ清掃・バックアップ）に適する
• GitHub Actions: コールドスタート（ログは追跡可）、クラウドの信頼性パイプラインに適する
• 選択基準:
  • 短期サイクルには Loop
  • 長期で信頼性が要るなら GitHub Actions
  • 固定された機械的タスクには Cron

■ 7. チームへの導入: 6ステップと2つの品質ゲート

• 導入の基本方針: いきなり全部を Loop 化せず、小さく始める
• 6ステップ:
  • タスクを選ぶ: CI 修復・リグレッション検証・ログ巡回点検などの小さく明確なタスクから着手する
  • 目標契約を書く: 入力・出力・合格基準（数字で）・禁止領域を明記する
  • ツールへつなぐ: repo・テストフレームワーク・lint・MCP・issue トラッカーを接続する
  • センサーを足す: テスト結果・スクショ・録画・パフォーマンス指標・エラースタック・カバレッジを設定する（＊品質ゲート#1: 証拠が揃わない限り次に進まないラインを引く）
  • 停止条件を決める: 合格・タイムアウト・コスト上限・リスクトリガー・人間への引き渡しを設定する（＊品質ゲート#2: 条件が曖昧だとサイクルが終わらないか、終わったのか分からないものが量産される）
  • 経験を貯める: ルール・テンプレート・skill・eval ケース・改善点を蓄積する
• 優先順位: 検証可能 > 自動化可能 > 拡張可能

■ 8. Loop 導入チェックリスト

• Loop に向いているタスク:
  • CI の赤信号修復（ビルドとテストの失敗を自動特定・修復）
  • テストの補完（単体テストを生成・補完して通す）
  • ログの巡回点検（異常検知・分類・修復提案）
  • ドキュメント同期（API・README・インターフェースの自動更新）
  • 依存関係のアップグレード（バージョン確認・PR・リグレッション）
• 注意したほうがいいタスク:
  • 広範囲のリファクタリング（ロールバックが重い）
  • 本番環境の権限操作（事故の影響が大きい）
  • セキュリティに敏感な変更（権限ポリシー・キー・アクセス制御）
  • 純粋な美的判断（客観基準がなく検証ができない）
• Loop 開始前に決めておくべき設定項目:
  • Owner（責任者）: 追跡可能性の保証
  • 締め切り時間: 無限ループの回避
  • 最大ラウンド数: コストの暴走を防ぐ
  • 証拠の出力: ログ・スクショ・テスト・CI 結果の必須化
  • 停止理由: デリバリーまたはロールバックの明示

■ 9. Loop の3つの罠

• 罠1: 検証の死角:
  • Loop は無人で動くため、無人のままミスを犯す
  • 「done（完了）」は自己申告であり証明ではない
  • 証拠が出ない Loop は自信過剰な乱数発生機と同義
• 罠2: Comprehension Debt（理解の負債）:
  • Loop がスムーズであるほど、自ら生成させたコードに対して疎遠になりやすい
  • デリバリーを加速させる一方で、コードへの乖離も加速させる
• 罠3: Cognitive Surrender（認知的降伏）:
  • Loop を走らせ、自分の判断基準を持つことをやめ、もたらすすべてを受け入れてしまうこと
  • 「AI がそう言うので…」が口癖になりはじめたら危険

■ 10. 結論: レバレッジポイントの移動

• レバレッジポイントの変化:
  • Before: 良いプロンプトを書く人、個別の答えを出す力、自分が動く
  • After: 良いループを設計する人、答えを出し続ける機械を作る力、自分の代わりに動くシステムが動く
• 同じ Loop を組んでも出てくる結果は異なり、差を分けるのは仕事を本当に理解しているかどうか
• Loop Engineering は Prompt Engineering より難しく、1つの答えを出すことと答えを出し続ける機械を作ることは別の能力
• スムーズに回ること自体が危険というパラドックスがあり、薄ら寒さを自覚した上で付き合っていくことが当面の正解

(2026/06/15)

AI駆動開発が変える、大規模開発の前提 ーHuman in the Loop から Human on the Loop へ

• AI駆動開発が変える、大規模開発の前提 ーHuman in the Loop から Human on the Loop へ / AIE2026 - Speaker Deck

要約:

■ 1. 登壇者・背景

• 発表者: 株式会社ビズリーチ CTO 外山英幸（Hideyuki Toyama）
• 所属: Visionalグループ 執行役員 CTO / DX本部 本部長 / AI Product Studio室 室長
• ビズリーチはCodexで月間2,300億トークンを消費（総使用量・1アクティブユーザー当たり使用量ともに日本トップクラス）

■ 2. AI駆動開発の現在地と次の課題

• AI駆動開発はすでに一般化し、多くの組織が「もっと使う」フェーズにある
• フェーズの変遷:
  • 浸透（2023〜2024）: 個人活用、PoC、教育
  • 拡大（2025〜2026）: 全社展開、標準化、利用率最大化
  • 次の課題: 「拡大」の先に何が来るかが問われている

■ 3. Harness Engineeringの台頭

• 2026年2月を境に、業界の議論の中心が「Harness engineering」に移行した
• Mitchell Hashimoto氏（HashiCorp共同創業者）がブログ「My AI Adoption Journey」で「Engineer the Harness」を提唱
• OpenAIのRyan Lopopolo氏が「Harness engineering: leveraging Codex in an agent-first world」を発表（3名チーム、5ヶ月、100万行、ゼロ手書き）
• harnessの定義: AIエージェントが正しく・速く・安全に動くための以下を統合して設計する営み
  • 実行環境（execution environment）
  • 文脈（context）
  • ガードレール（guardrails）
  • 検証ループ（verification loop）
  • 観測性（observability）
• モデルだけでなく、harnessの設計も競争領域となっている

■ 4. HITLとHOTLの構造的違い

• HITL（Human in the Loop）の特徴:
  • 人間がフローの「中」にいて、すべての判断点を通過する
  • 設計・実装レビュー・テスト承認・リリース判断をすべて人間が行う
  • 人間が律速点になる
• HOTL（Human on the Loop）の特徴:
  • 人間がループの「外」から監督し、フローには介在しない
  • 設計・実装・検証・統合・監視をすべてAgentが実行する
  • 人間は「監督」と「方向付け」に集中する
  • 人間は律速点から外れる
• HITLとHOTLの差異:
  • 違うのは速度ではなく、制御位置と最適化対象
  • HITLは「個人を速くする」最適化、HOTLは「ループ構造を設計する」最適化
• harnessを真剣に作ると開発は速くなるが、それはHITLのまま速くなっただけに過ぎない
  • harnessで改善すること: レビューサイクルの短縮、1人あたりアウトプットの増加、待ち時間の消滅、デバッグの高速化
  • それでも変わらないこと: 人間がフロー内部にいる構造、レビューが律速になる構造、設計・判断・承認が人間に集中する構造

■ 5. 本題: AI実行の統治（Governance of AI Execution）

• 問いは「AIをどう使うか」ではなく「AI実行を、どう統治するか」
• ADR・Wiki・設計書・Confluenceにドメインルールが書かれていても、現実には機能しない:
  • Agentは参照しない
  • 違反しても誰も止めない
  • 変更影響を追跡できない
  • 削除していいか誰も分からない
• 「書かれている」と「効いている」はまったく違う
• ADRを増やしても、設計書を充実させても、Wikiを整備しても、HOTLには到達しない
• ドキュメントを「書く」のではなく、ルール・チェック・実行を「制御構造に組み込む」必要がある

■ 6. AI統治の結論: 三権分立モデル

• AIを統治するには3つの機能を分離する必要がある:
  • ① ルールを定める（立法）
  • ② ルールに従っているかを判定する（司法）
  • ③ ルールに基づいて実行する（行政）
• 従来はこの3つをすべて人間（特に熟練者）が持っていた
• AI Native（HOTL）では、構造として分離する必要がある
• ビズリーチの統治モデル「三権分立」:
  • 立法AI（ルール）: 何が正しいかを定義する（ルールのSSOT）
  • 司法AI（検証）: 適合しているかを裁く（contracts / guards）
  • 行政AI（実行）: 実際に実行する（workflow / agent）
  • 憲法（Constitution）が三権すべてを縛る。改正は人間のみが可能
• 三権の実装内容:
  • 立法: ルール（憲法に準拠する具体規範）、制定/改正（AIが提案、人間が承認）
  • 司法: セマンティックチェック（LLMで意味判定）、決定性チェック（Grep/AST等で機械判定）
  • 行政: ワークフロー（タスク完了の事前定義）、スキル+ツール（エージェントを拡張）

■ 7. 汎用harnessと統治の分担

• 立法と司法はプロダクト・フェーズ依存であるため汎用化しづらい
• 汎用化できるのはharness（行政）だけ
• Anthropic・OpenAI・Cursorなどharness engineeringを提供する側は、構造的に行政までしか触れない
• harnessは借りられるが、統治は自社で作るしかない

■ 8. Authority Provenance Graph

• 目的: 「書かれている」を「効いている」に変えること
• 立法（ルール）と司法（チェック）を機械可読に・双方向に接続する層
• 接続例:
  • ADRのルール ↔ それを検証するテスト
  • ドメインルール ↔ 違反検知のassertion
  • 設計原則 ↔ Linterルール
• graphによって機械可読に検知できる3つの問題:
  • 立法なき司法: チェックは存在するが、何のルールに依拠するか不明
  • 司法なき立法: ルールは存在するが、それを効かせるチェックがない
  • 越境司法: チェックが、本来管轄外の領域まで裁いている

■ 9. Specification Provenance Graph

• 目的: 機能の成立を機械可読に追跡する
• 追跡構造: feature（機能）↔ requirement（仕様）↔ proof（テスト）をgraphで接続
• 追跡可能にする問い:
  • この機能は何の仕様に基づくか
  • どのテストで証明されているか
  • 変更したら、何に影響するか
• Authority Provenance Graph × Specification Provenance Graphの2つが揃って、機能・非機能の統治が完成する
• Agentが自走するために必要な「追跡可能性」を機械可読にする

■ 10. graph設計の最重要原則: SSOTと派生データの分離

• 原則: 自動生成される情報を、判断の根拠として参照させてはならない
• SSOT（Single Source of Truth）の定義:
  • 人が定義したもの
  • 正式な承認プロセスを経たもの
  • 例: 機能要件、ドメインルール、テスト・assertion
  • 判断の根拠として参照可能。変更には承認が必要
• 派生データの定義:
  • 機械が自動生成するもの
  • いつでも再生成できるもの
  • 例: 変更影響分析、自動生成された依存図、集計サマリー
  • 判断の根拠としては参照不可。ナビゲーション・索引としてのみ使う
• 「便利だから」でSSOTと派生データを混ぜると、統治は必ず崩壊する

■ 11. 実証: HOTL型組織の突出した成果

• ビズリーチ社内で、HOTL型組織だけがPR数×Codexトークン消費量で桁違いに突出している
• チーム全体でも、一人あたりで見ても外れ値であり、「規模の差」ではない
• 同じ会社、同じツール、同じ時代でも桁違いの差が出る
• 違いを生んだのはAI利用量ではなく、AIを「どれだけ自律的に走らせられる構造を持っているか」
• AI実行密度: AI Agentが人間の介入なしに自律的に走り続けられる「密度」
• AIを使ったのではなく、AIを前提に組織構造を変えた

■ 12. harnessと統治の関係

• harnessは必要条件、統治は十分条件
• harnessだけではHOTLに到達しない。統治が、harnessを動かす
• harnessだけではHOTLに到達しない。統治で初めて完成する

■ 13. HOTL化に向けて自社で問えること

• 問うべきは「書かれているか」ではなく「効いているか」
• ① 判断の根拠は機械的にチェック可能な形で表現されているか
  • ドキュメントに「ある」だけでなく、違反したらCIが落ちる・Agentが止まる状態か
  • ADR・設計書・WikiはLevel 1に過ぎない
• ② 派生情報と原典は機械的に区別されているか
  • 自動生成された情報が判断根拠として参照可能になっていないか
  • 「便利だから」で原典と派生が混在していないか
• ③ ルール・検証・実行の繋がりは、Agentが追跡し、Agentが止められるか
  • 人間が記憶や経験で繋いでいる状態になっていないか
  • 接続が切れたら、Agentが違反を検知できるか
• 「書かれている」でYesにしてはいけない。「効いている」かを問え

■ 14. AI-Native時代に向き合う問い

• 今日話した統治はHOTLの入口に過ぎない
• HOTLは「AI前提の世界」であり、人間Firstの延長線上にはない
• 今後の探求領域:
  • 機能以外の領域への統治拡大（セキュリティ、堅牢性、保守品質、インフラ、運用、DevOps）
  • graph設計の深化（直交linkageの活用、状況に応じたナレッジgraph化、weight設計）
  • プロダクトのAI-Native前提での再設計（「人間First」ではないドキュメント設計、HOTLを前提とした機能設計）
  • 組織・プロセスのHOTL前提での再設計
  • 必要な人材要件のアップデート
• AI Building AIの時代、競争力を決めるのはAIを使う量ではなく、AI実行を統治できるかどうか
• これは開発の話に見えて、事業と組織のあり方の話に接続する

(2026/06/15)

デバッガーがプログラマーにバグ報告をするとき伝え方で反応が全く変わることがあったが何がダメだったんだ？...

• デバッガーがプログラマーにバグ報告をするとき伝え方で反応が全く変わることがあったが何がダメだったんだ？「言っていることは同じ？」「このケースだと明らかに違う」 - Togetter

MEMO:

• 前者は「確認してください」と言われたので素直に「確認」モードに入っただけだと思われる
• 後者は質問系で発生が終了されているので「会話が要求されているのかな？」というモードに入ったのだと思う

(2026/06/14)

350画面のUI統一、AIに任せたのは「セルフチェック」だった

• 350画面のUI統一、AIに任せたのは「セルフチェック」だった - RAKUS Developers Blog | ラクス エンジニアブログ

要約:

■ 1. 記事の概要

• 楽楽販売開発チームが「楽楽シリーズUI統一プロジェクト」において、実装ではなく実装後のセルフチェック工程にAIを活用した事例の紹介
• テーマは「作業の性質を見極め、AIの勘所を押さえる」こと
• AIに任せられる作業と人間が責任を持つべき作業を見極め、適切な領域にAIを投入する判断の記録

■ 2. プロジェクトの背景

• 楽楽シリーズ各商材のデザインがばらついており、ユーザーの戸惑いが生じていた
• シリーズ横断の大規模な取り組みとして、共通デザインシステムへの準拠でUIを再構築した
• プロジェクトはフェーズ1とフェーズ2の二段階に分けて進められた

■ 3. フェーズ1: AIに任せられない領域

• 対象: 一般ユーザー向け画面（56画面）、期間: 約1年、AI活用: なし
• AI自動実装を使わなかった理由:
  • 長年運用されたコア画面は既存デザインとJavaScriptが複雑に絡み合っていた
  • 自動化に任せると既存実装を壊すリスクが大きすぎた
  • 画面ごとに個別の事情があり、汎用ルールで一律に変換できる作業ではなかった
• フェーズ1での学び: 「AIに任せられない領域が確かにある」という現場の体感を得た

■ 4. フェーズ2: 規模拡大がもたらした課題と AI 活用

• 対象: 設定系画面（350画面）、期間: 約半年、AI活用: Cursor Rulesによるセルフチェック
• フェーズ1比で画面数が約6倍であるにもかかわらず、開発期間は半分に収まった
• この差は対象画面の性質、明確な実装ルール、並列開発体制など複数要因によるもの
• 新たな課題:
  • 350画面分のレビュー依頼が並行して発生する中、ルール遵守の機械的チェックを目視で行うのは現実的でなかった
  • レビュアーが「アイコン置換の確認」「不要クラスの削除確認」に時間を取られ、人間の判断が必要な本質的なレビューに集中できなかった
• フェーズ2ではチームで詳細な実装ルールを事前に整備しており、変換パターンが網羅的にドキュメント化されていた

■ 5. AI 活用の設計: セルフチェックへの投入

• 実装そのものではなく「実装ルールに沿っているかのセルフチェック」にAIを投入した
• セルフチェック導入の効果:
  • 実装者が手元でルール遵守を事前確認できる
  • レビュー依頼時点でルール観点のチェックが完了した状態になる
  • レビュアーが人間の判断が必要な部分（UI崩れ、挙動の異常、UX品質）に集中できる

■ 6. Cursor Rules の仕組み

• Cursorの「Rules」機能を活用: プロジェクトルートにルールファイルを置くとAIが常に参照する
• 実装ルールをbefore/afterの具体例付きで章立てしたルールファイルとして整形した
• 主なルールカテゴリ:
  • 不要な装飾要素の削除ルール
  • アイコン体系の置換ルール
  • パンくず構造の修正ルール
  • メッセージ表示パターンの置換ルール
  • ページネーション・パネル構造の置換・調整ルール
  • JavaScript関数名の置換ルール
• LinterやFormatterでなくLLMを選んだ理由:
  • パンくずやパネルの構造変更など、HTMLの文脈や画面全体の構成を踏まえないと正しく判定できない観点が多かった
  • 機械的なパターンマッチだけでは拾いきれない、変更内容の意味を汲んだ柔軟な判断が必要だった

■ 7. 運用の手応え

• 定量データは取得していないが、現場での体感として以下の効果があった
• 人間の目視という不確定要素の低減:
  • 大量の実装ルールを人間が抜け漏れなくチェックすることは困難
  • AIによる事前チェックにより、見落としリスクが大幅に低下した
• 人間の判断が必要な領域への集中:
  • ルール遵守チェックをAIに任せた分、レビュアーはUXや挙動の異常など本質的な観点に注力できた
• 350画面の改修を約半年で完遂した

■ 8. 振り返りと一般化できる学び

• 作業の性質と AI 活用の相性:
  • 複雑で固有性が高い作業は人間が向き合う方が効率的
  • 機械的でルール化でき量が多い作業はAI支援の効果が出やすい
  • この見極めは机上では難しく、現場で手を動かして得られる感覚
• AI活用はワークフロー全体で成立する:
  • 「実装ルールを決める（人間）」→「ルールをAI向けに翻訳する（人間）」→「AIによるセルフチェック（AI）」→「人間の判断が必要な部分に集中してレビュー（人間）」という工程
  • 純粋な「AIの仕事」はセルフチェック実行のみであり、残りは人間の作業
• 「翻訳作業」が成否の鍵:
  • AIが解釈しやすい構造に整え、具体例を添え、抜け漏れなく記述することが重要
  • 成否を分けたのはモデルの性能よりも「AIに何を、どう渡すか」という設計
• 今回の取り組みの本質: 「AIに仕事を任せた」ではなく、「AIが得意な領域へ仕事を再分配した」
  • 大量ルールの機械的適用 → AI
  • ルールの定義、例外の判断、最終的な品質責任 → 人間

(2026/06/13)

モバイルバッテリーは「あと数年で終わるかも」とAnker創業者が予測

• モバイルバッテリーは「あと数年で終わるかも」とAnker創業者が予測 | Gadget Gate

要約:

■ 1. Anker CEOによるモバイルバッテリー市場の見通し

• AnkerのCEO・陽萌氏はインタビューで、モバイルバッテリーが数千億元規模の市場に成長する可能性は低いとの見解を示した
• 「数年したら終わるかもしれない」との発言が報じられた
• モバイルバッテリーをMP3プレーヤー、カセットプレーヤー、CDプレーヤーなど過去の消費者向け電子機器に例えた
• それらの製品は「ユーザーが買い始めてから市場に見捨てられるまでのライフサイクルはせいぜい10年程度」であり、その後は別の製品に置き換えられると指摘

■ 2. Ankerの事業変遷と業績

• 2011年創業のAnkerは、当初モバイルバッテリー事業を中核として海外市場を急速に開拓
• 2025年の売上高は305億1400万元（前年比23.49%増）:
  • 充電・蓄電関連がおよそ半分を占める
  • 従来型のモバイルバッテリーはすでに中核事業ではなく、充電アクセサリー、スマートデバイス、エネルギー貯蔵製品へ展開を拡大
• 2026年第1四半期の売上高は76億800万元（前年同期比26.93%増）:
  • 純利益は4億7200万元で前年同期比4.87%の減少

■ 3. 品質管理問題の認識

• 2025年度株主総会において、Ankerは充電製品の品質管理問題を公式に認めた
• 原因として「充電製品のモデル数が多すぎた」点を挙げた
• 2024年だけでもモバイルバッテリーは約100モデルが存在した
• 「どんな企業でも100種類ものモバイルバッテリー製品の品質を維持することは不可能だ」との見解が報じられた

■ 4. 市場動向と技術的背景

• 現時点でモバイルバッテリー市場は縮小しておらず、堅調に拡大しているとの調査結果が存在する
• スマートフォン内蔵バッテリーは技術進歩により「サイズはそのままに大容量化」が進む傾向にある
• 数年先の市場見通しは正確に立てにくい状況にある
• 市場の最前線に立つAnkerだからこそ、変化の兆しを早期に察知している可能性がある

(2026/06/13)