/note/tech

ターミナルを自作したら、1日のコミット数が500を超えて、生産性がバグった話

• ターミナルを自作したら、1日のコミット数が500を超えて、生産性がバグった話

要約:

■ 1. 課題: 複数AIエージェント並列管理の困難さ

• emacs＋ターミナル環境でClaude Codeを複数並列実行していた
• 6分割ターミナルでも各ペインの状態（終了・待機・実行中）が視覚的に判別できない
• 投げた指示の内容を途中で見失う問題が発生
• 画面スペースの物理的制限が存在

■ 2. 解決策: ブラウザベースターミナルの自作

• VS Code統合ターミナルの実装調査を通じてxterm.jsを発見
• ブラウザ上で動作するターミナルはHTMLとCSSで自由なレイアウトが可能
• WebSocketを用いてサーバ側のPTYに接続する構成を採用

■ 3. 実装した主要機能

• セッション状態の可視化:
  • 各セッションのサイドにAIのサマリーと投げたプロンプトを表示
  • Claude Codeの状態（idle/running/waiting）をリアルタイムで明確表示
  • リポジトリごとに色とレイアウトをカスタマイズ可能
• 通知システム:
  • 入力待ち状態になった際に音声通知（カスタマイズ可能）
  • Firebase経由でローカルMacの状態をミラーリング
  • Service Worker経由のWeb Push実装によりiOS 16.4以降のスマートフォン・スマートウォッチへ通知
• セッション管理:
  • tmuxでセッションを管理し、再起動後も継続可能

■ 4. 認知限界の突破

• 従来の認知限界は約6エージェントの並列実行
• Anthropic社のBoris Cherny氏もターミナルで5セッション、ブラウザで5〜10セッションを同時実行
• 並列度の上限は人間の注意力ではなく、道具がどれだけ状態を肩代わりするかで決まる
• 作業スタイルが「画面に張り付く」から「呼ばれたら応じる」へ転換

■ 5. 1日500コミットの正体

• 並列度×通知ドリブンの自然な帰結として実現
• 各エージェントが小さな変更を積み重ね、ユーザーは詰まったポイントのみ判定する役割に
• ボトルネックが「手を動かす速度」から「判断を返す速度」へ移行した結果

■ 6. 予期しない変化: エディタの喪失

• 当初の目的はemacs環境を守ることだった
• 実際にはコード記述業務がほぼエージェント側で完結
• 著者の作業が「コーディング」から「PRレビュー」へシフト
• 手でファイルを開く機会がほぼ消滅

■ 7. 次のボトルネック: GitHub

• エージェント側の処理速度は充分に確保された
• CI・マージ判定が律速段階となった
• PR取り込み速度が開発全体の足かせとなっている

■ 8. 公開ツール: MulmoTerminal

• 起動コマンド: npx mulmoterminal@latest
• Claude Code、OpenAI Codexの両対応
• OSSとして公開、日本語マニュアル完備
• 関連プロジェクト: MulmoCast（マルチフォーマットメディア変換）、MulmoClaude（Claude Codeツールキット）

(2026/07/25)

[PDF]株式会社はてな　特別調査委員会による調査報告書の公表及び役員報酬の一部自主返上に関するお知らせ

• [PDF]株式会社はてな　特別調査委員会による調査報告書の公表及び役員報酬の一部自主返上に関するお知らせ

MEMO:

• はてな11億円超資金流出事件の調査報告書
• 経理部長H氏は明らかに正常な判断ができていないように見える
• これはどうすればよかったのだろうか

(2026/07/25)

LG製モニターをつなぐとMcAfeeの広告が勝手に出る問題。Microsoftが対応開始

• LG製モニターをつなぐとMcAfeeの広告が勝手に出る問題。Microsoftが対応開始 - PC Watch

一部のLG製モニターをPCに接続すると、「LG Monitor App Installer」が自動的にインストールされ、McAfeeの広告ポップアップが表示されるようになったとして、直近でユーザーから批判の声が挙がっていた。この状況に対し、MicrosoftがLGに働きかけ、McAfeeのポップアップは無効化されることになったようだ。

X(旧Twitter)でのユーザーの投稿に対し、MicrosoftでWindowsおよびデバイス部門のEVPを務めるPavan Davuluri氏が7月23日の返信で明らかにしたもの。同氏によれば、MicrosoftがLGのチームにコンタクトし、当面の措置として、McAfeeのポップアップを無効化することで合意したという。

YouTubeチャンネルのGamers Nexusが投稿した動画によれば、「34GX900A-B」を使った検証では、同ユーティリティがユーザーの同意なく自動でインストールされ、PCを起動すると、ほぼ毎回McAfeeの広告ポップアップが表示されるようになったという。

このユーティリティは、Windows Updateを通じてドライバとともに自動でインストールされているとされる。筆者もLG製ゲーミングモニター「27GL850-B」を使用しているため確認したところ、Windows Update経由で、7月12日にLG Monitor App Installerがインストールされていた。なお、筆者の場合は本アプリが原因と思われる広告のポップアップには遭遇していない。

(2026/07/24)

2026年のソフトウェア開発を考える（2026/07版）

• 2026年のソフトウェア開発を考える（2026/07版） / Agentic Software Engineering 2026-07 Findy Edition - Speaker Deck

(2026/07/24)

クラウドにOSSを「持っていかれる」問題：Elastic、Redis、HashiCorpから考えるAGPL

• クラウドにOSSを「持っていかれる」問題：Elastic、Redis、HashiCorpから考えるAGPL - Convergence Lab.

要約:

■ 1. 問題の背景

• OSSが成功すると、巨大クラウド事業者がマネージドサービスとして提供し、大きな売上を得る
• 開発元企業には売上が直接還元されない
• Apache-2.0やBSDなど寛容なライセンスでは、商用利用・再販売はライセンス上認められた自由であり、原則として違反ではない
• 「ルール上は正しいが、開発を続けられない」と感じたOSS企業が、ライセンス変更や防衛戦略をとるケースが相次いだ

■ 2. Elastic と AWS の衝突

• ElasticsearchとKibanaはApache License 2.0で公開され、AWSは2015年にAmazon Elasticsearch Serviceを開始
• 2021年、Elastic創業者Shay Banon氏が「Amazon: NOT OK」と題したブログを公開し、AWSによる商業的利用を問題視
• Elasticは Elasticsearch 7.11以降、Apache-2.0からSSPLとElastic Licenseのデュアルライセンスへ移行
  • SSPLを選択すると、サービス提供者は管理・運用レイヤーを含むソースコードの公開が必要
• AWSはApache-2.0版のElasticsearch 7.10.2をフォークし、OpenSearchを立ち上げた
• 両者の主張:
  • Elastic側: 開発投資を負担してきた企業がクラウド事業者に価値を吸収されると開発継続が困難
  • AWS側: Apache-2.0が許した利用を後から制限すれば、利用者の自由とライセンスへの信頼を損なう
• 2024年、ElasticはSSPL・Elastic Licenseに加えてAGPLv3を選択肢として追加

■ 3. MongoDB と SSPL

• MongoDBはもともとAGPLでCommunity Serverを提供していたが、2018年にSSPLを新たに作成
• SSPLの特徴: MongoDB本体への変更だけでなく、サービス提供に使う管理ソフトウェア、UI、API、自動化、監視、バックアップ、ストレージなど「Service Source Code」全体の公開を要求
• SSPLはOSI承認のオープンソースライセンスではなく、ソースコードを閲覧可能だが制限が強い
• SSPL導入約3か月後の2019年1月、AWSはAmazon DocumentDB（with MongoDB compatibility）を公開
  • MongoDBのコードをホストするのではなく、MongoDB 3.6のAPIをAWS独自のストレージエンジン上で再実装した別製品
• 強いライセンスへ変更しても、資本と技術力を持つ競合が互換製品をゼロから作る可能性は排除できない

■ 4. Redis のライセンス変更とフォーク

• Redisは長年BSD-3-Clauseで公開されていたが、2024年にRedis 7.4以降をRSALv2またはSSPLv1へ変更
• ライセンス変更を受け、コミュニティとクラウド事業者が最後のBSD版Redis 7.2.4をフォークし、Linux Foundation傘下のValkeyを設立
  • AWS、Google Cloud、Oracle、Ericssonなどが参加し、BSDライセンスで開発継続
• その後の方針変更:
  • 2024年11月、Redisの生みの親Salvatore Sanfilippo氏（antirez）がプロジェクトへ復帰
  • Redis CEOが公式発表で、SSPLへの変更はフォーク設立という目的をクラウド事業者が達成した一方、コミュニティとの関係を傷つけたと認めた
  • Redis 8でRSALv2、SSPLv1に加えOSI承認のAGPLv3を追加
• 教訓: ライセンスは後から変更できるが、一度失ったコミュニティの予測可能性はライセンスを戻すだけでは回復しない

■ 5. HashiCorp と OpenTofu

• TerraformはInfrastructure as Codeの事実上の標準として普及し、OSI承認のMPL 2.0で公開されていた
• 2023年、HashiCorpは将来のリリースをBusiness Source License（BSL）1.1へ変更
  • 競合する商用サービスによる利用を制限する目的
• これに対し、企業と開発者のグループが最後のMPL版をフォークし、OpenTofuを設立
  • OpenTofuはLinux Foundationによる中立的な管理を選択し、単一企業による再ライセンス変更を防止する設計
• フォーク後も緊張は続いた:
  • 2024年4月、HashiCorpがOpenTofuに対しBSLコードの不正取り込みを主張し停止要求書を送付
  • OpenTofu側は疑惑を否定し、問題とされた実装は過去のMPL-2.0版コードから派生したものだと詳細なコード来歴を公開
• フォーク側は旧ライセンスで合法的に利用できるコードと変更後のライセンスのコードを厳密に隔離し、実装の出所を説明できる必要がある

■ 6. Confluent の戦略

• Apache KafkaはApache Software Foundationのプロジェクトであり、Confluent単独ではApache-2.0からの変更は不可能
• 2018年、ConfluentはKafka本体はApache-2.0のまま維持し、自社が開発する周辺コンポーネント（Schema Registry、REST Proxy、ksqlDB、一部のConnector等）をConfluent Community Licenseへ変更
• Confluentの戦略構造:
  • 中立的な財団にあるKafka本体は誰でもサービス化可能
  • ConfluentはKafkaへ継続的に貢献
  • 自社のみが権利を持つ周辺機能で競合サービスを制限
  • 企業顧客には周辺機能と運用を統合した商用価値を販売
• コードのライセンスだけでなく、どのコードを財団へ置きどのコードを企業が保有するかが、ビジネスモデルを決定する

■ 7. CockroachDB と Sentry: 時限式ライセンスの試み

• CockroachDBの取り組み:
  • 2019年、Apache-2.0からBusiness Source License（BSL）へ移行
  • BSLでは新バージョンの競合サービス提供を制限しつつ、一定期間後に指定OSSライセンスへ自動移行
  • 2024年、さらにCockroachDB Software Licenseへ移行し、現在は年間売上1,000万ドル未満の企業などに無償枠を設けたプロプライエタリ製品となっている
• Sentryの取り組み:
  • 時限式モデルを定型化したFunctional Source License（FSL）を作成
  • 公開から2年間は競合製品・サービスへの利用を制限し、その後Apache-2.0またはMITへ自動移行
• FSL・BSLは制限期間中はsource-availableでありOSI定義のOSSではないが、開発費回収後に全員へ自由を渡すという設計

■ 8. Grafana: AGPLと商用契約によるパートナーシップ

• 2021年、Grafana LabsはGrafana、Loki、TempoのライセンスをApache-2.0からAGPLv3へ変更
  • SSPLも検討したが、コミュニティとの関係を重視してOSI承認ライセンスにとどまる判断をした
• AWSはAmazon Managed Service for Grafanaを持ちながらも、OpenSearchのようなフォークには至らなかった
  • AWSとは商用契約を含む戦略的パートナー関係があり、AWSのサービスはライセンス変更の影響を受けなかった
• Grafanaの構造:
  • コミュニティにはOSI承認のAGPLでコードを公開
  • 改変を非公開でサービス提供したい事業者には商用ライセンスを用意
  • 大手クラウドとは敵対ではなく、契約によって価値を分配
• AGPLはクラウド事業者に「改変を公開する」か「商用契約を結ぶ」かという交渉の入口を作り、パートナーシップへ進める可能性がある

■ 9. クラウド事業者と OSS の関係性の本質

• Apache-2.0、MIT、BSDを選んだプロジェクトでは、商用利用・再配布・サービス化はライセンスが明示的に認めた自由であり、コントリビューションの強制条項はない
• 問題の本質は「クラウド事業者がルールを破ったか」だけではなく、プロジェクトが期待した互恵関係と実際に選んだライセンスの間のずれという設計上の問題
• コード利用以外の問題も存在する:
  • 商標による利用者の混同
  • 互換性の表示
  • コミュニティへの説明
  • upstreamとの協力姿勢
  • Elastic vs AWSの対立でも「Elasticsearch」という名称の商標問題が大きな争点となった
• OSS企業は善意のコントリビューションだけを収益モデルにすべきではなく、クラウド事業者もライセンス上可能であることと、コミュニティにとって持続可能であることを同一視すべきではない

■ 10. Papillon での AGPL 選択理由

• Convergence Lab.が開発するBIツールPapillonでは、OSSコアをAGPL-3.0、Enterpriseコンポーネントを商用ライセンスとする構成を採用
• AGPLを最初から選んだ理由:
  • 最初にApache-2.0を選び後でライセンス変更すれば、Elastic・Redis・HashiCorpと同様に利用者との約束を途中で変えることになる
  • 最初から条件を明確にすることで、後からルールを変えず、コミュニティ版と商用版の関係を説明できる
• Papillonでの条件設計:
  • 個人や開発者は実用的なコア機能をOSSとして利用・改変できる
  • 改変版を配布・ネットワーク提供する場合はAGPLの条件に従いソースを提供
  • ソースを非公開にしたい組織には商用ライセンスという選択肢を用意
  • SSO、監査ログ、ガバナンスなどの組織運用機能はEnterprise領域で開発
• AGPLの代償も認識している:
  • 法務ポリシー上AGPLを採用できない企業が少なくない
  • MITやApache-2.0のプロジェクトより利用者・コントリビューターが増えにくい可能性がある
  • ライセンスを強くしても自動的に事業が成功するわけではない

■ 11. OSSビジネスで設計すべき4要素

• ライセンス:
  • どの利用を自由にし、どの場面でソース公開または商用契約を求めるかを決定
  • 普及最優先ならMITやApache-2.0、ネットワークサービスからの還元も重視するならAGPLが候補
• ガバナンス:
  • ライセンスを誰が変更できるか、ロードマップを誰が決めるかを設計
  • 企業主体と財団主体にはそれぞれ速度と予測可能性のトレードオフがある
• 商標:
  • コードを自由に使えても、公式製品と誤認させる名称利用まで自由とは限らない
  • プロジェクト名とロゴの扱いを明確にしなければ、利用者の混同が対立へ発展する
• お金を払う理由:
  • 「OSSを使わせない」ことを商用版の価値にしてはいけない
  • SSO、監査、サポート、SLA、導入支援、運用代行など、組織が対価を払う積極的な理由が必要

(2026/07/24)

LG製ゲーミングモニターがWindows Updateを悪用し広告アプリを無断導入。McAfeeの広告表示も

• LG製ゲーミングモニターがWindows Updateを悪用し広告アプリを無断導入。McAfeeの広告表示も

一般的にディスプレイはドライバーなど不要で、HDMIとPCを繋げばそのまま画面が表示されるだけが役割ですが、LGのゲーミングモニターである「LG UltraGearシリーズ」をWindows PCに繋げるとWindows Update経由で「LG Monitor App Installer」という専用アプリを同意なく導入される仕組みであることが明らかになりました。

MEMO:

• これはひどい

(2026/07/23)

スクラムの「うまくいかない」はなぜ？ 組織や関係性に隠れた課題を探る

• スクラムの「うまくいかない」はなぜ？ 組織や関係性に隠れた課題を探る - Agile Journey

要約:

■ 1. スクラム道関西の背景と状況の変化

• スクラム道関西は2012年設立、170回以上のオープン・ジャムを開催してきた関西のスクラム・アジャイルコミュニティ
• 設立の動機は「学ぶ場がなかったため自ら作る」というシンプルなもの
• アジャイル・スクラムの認知度は大幅に向上し、企業の新卒研修への組み込みなど組織主導での推進が増加
• 悩みの変化:
  • 2010年代: 個人が手法を学び「どう始めるか」を模索する段階
  • 現在: 組織として推進しているが「期待される効果をどう出すか」という実践フェーズの悩みが中心に

■ 2. 表面的な問題の背後にある根本原因

• 相談に寄せられる問題の傾向:
  • 初期: 「デイリースクラムが15分で終わらない」などプロセス上の問題
  • 近年: チームの内外関係、ステークホルダーとの関わり方、組織・SMやPOが機能しないといった広範な問題
• 表面的課題への対処だけでは本質的解決に至らない
  • 一つの問題を解決しても、チームの状態が改善されなかったり、別の問題が次々と発生するケースが多い
• 「デイリースクラムが15分で終わらない」を掘り下げた例:
  • 計画が立てられていない
  • プロダクトの目的を理解しておらず、会話のたびに背景説明が必要
  • 納得感のあるプロダクトバックログアイテムが整っていない
• 深掘りのアプローチ: 「なぜ困っているのか」「根本原因は何か」「本当に問題なのか」を対話しながら明らかにすることが必要

■ 3. スクラムマスターへの誤解と組織構造の問題

• 組織がアジャイルを推進したいと言いながら体制が伴わないケース:
  • 推進できる体制が整っていない
  • 推進する側がアジャイルの十分な知識を持っていない
  • トレーニング等への予算配分がなく組織としてのサポートがない
• 相談者と組織との間に期待値のギャップがあるまま進行することで、状況がさらに困難になる
• POに決定権がない問題:
  • 個人の問題ではなく、開発部隊とマネジメント部隊が分断された組織構造に起因
  • 「考える役割」と「作る役割」の構造的分断により、チーム全体でプロダクトを考えながら作る協働のスタートラインに立つことが難しい
• スクラムマスターの成果が見えにくい問題:
  • エンジニアやPOに比べアウトプットが分かりづらく、期待値のすり合わせがないと立ち位置が崩れやすい
  • SMの本来の役割はサーバント・リーダーとして、チームが自律的に動けるよう一歩引いて支援すること
  • クリティカルな質問の投げかけやステークホルダーとの対話支援など、表に見える成果物として残りにくい活動が中心
  • 対策: レトロスペクティブ等でSMの考えや活動を共有し、チームと目線を揃えることが重要

■ 4. 「ブリリアント・ジャーク」問題とラベリングの危険性

• 「チームにブリリアント・ジャークがいて困っている」という相談も、一見個人の問題に見えて実際は組織的課題
  • 特定人物への業務集中やその人がいないと回らない状態は、組織の脆弱性の表面化と捉えられる
• 研究（Felps et al. 2006）によれば、悪影響のあるコミュニケーションをとる人が一人いるだけでチームの成果が著しく損なわれる
  • 例外として、質問を投げかけ、全員を巻き込み、対立を和らげるリーダー役のメンバーがいたグループは成果が落ちなかった
  • 問題は「その人がいるかどうか」だけでなく、周囲の関わり方によっても変わりうる
• ラベリングへの警戒:
  • 特定の行動が生じた文脈を確認せずにラベルを貼ると、見方が固定されるリスクがある
  • 「静かに仕事をしたいだけ」の人が「空気が読めない」と見られるケースもある
  • 問題に名前をつけることで分かった気になれるが、裏には関係性のズレ・期待値の違い・組織の構造が隠れていることが多い
• 求められる姿勢:
  • ラベルで片付けるのではなく、見方そのものを問い直すこと
  • 各メンバーの特性を踏まえた上で、チームとしてどう機能するかを互いに考えること

■ 5. 「うまくいかない」ことの積極的意義

• スクラムはプロジェクト成功を保証するものではなく「問題を発見するフレームワーク」であり、問題を解決するのは人
• スクラムを導入すると隠れていた問題が表面化する、その気づき自体が財産
• 「問題が次々と出てきてうまくいかない」現場ほど、スクラムが効果的に機能している証拠
• 早期に問題を発見できること自体がチームにとって大きなメリット（後になって噴出するより手の打ちようがある）
• 毎回全てがうまくいっているチームの方が不自然であり、複雑な問題ではなく解決しやすい問題に取り組んでいる可能性がある
• ネガティブな発言を許容できる場の重要性:
  • 「疲れた」「しんどい」と言えない場では、負の重力がかかって本当に苦しくなる
  • 「うまくいっていない」「失敗した」と言い合える状況から、対話・分析・学習へとつなげることが大切
• スクラムの本質: 検査と適応を繰り返してプロセスの問題を浮かび上がらせるフレームワーク、衝突回避を目的とした馴れ合いとは異なる

■ 6. 実践者へのメッセージ

• コミュニティの活用:
  • 失敗を恐れず新しいことに取り組み、結果をコミュニティに持ち寄ることで知見を得る
  • 社内のコンテキストを理解できる仲間とスクラムガイドを読み、共に戦う仲間を作る
  • 同様のロールで働く他社の人とのコミュニケーションも重要
  • コミュニティには「一緒に考えてくれる文化」があり、それ自体が価値
• 目的を問い続けること:
  • スクラム・アジャイルをやること自体が目的ではなく、その先に「良いものを楽しく作りたい」「誰かの役に立つものを作りたい」という実現したいことがある
  • やりながら「何のためにやっているのか」を問い続けることが重要
• 許容可能な損失の積み重ね:
  • 人は大きな損失を避けたがるが、アジャイル・スクラムのメリットは「これくらいなら失敗しても痛手ではない」という許容可能な損失を積み重ねられること
  • 小さな検査と適応を繰り返すことで多くの道が見えてくる
  • プロダクト開発だけでなく、人生においても程よいチャレンジを意図的に重ねることが推奨される

(2026/07/23)

Data Engineering Study #35 非構造化データの活用事例

• Data Engineering Study #35 非構造化データの活用事例 - YouTube

要約:

■ 1. イベント概要

• Data Engineering Study第35回 非構造化データの活用事例
• 登壇企業はチューリング、レイヤーX、Vポイントマーケティングの3社
• 現代のデータの約80%を占める非構造化データ（画像・動画・テキスト・書類等）をビジネス価値に変える実践知を共有

■ 2. セッション1: チューリング — 自動運転動画のセマンティック検索システム

• 課題:
  • チューリングは数万時間規模の運転動画を保有するが、映像内容を元にした検索手段がなかった
  • 検索可能な条件は日時・車両ID・地図情報のみで、「交差点で歩行者が横断している」などのシーン検索が事実上不可能
  • データが増えるほど問題が深刻化し、複数チームから要望が発生
  • 主な用途: シナリオテストの拡充、学習データの管理、モデルの挙動分析
• コア技術:
  • NVIDIAの「Cosmos Embed 1」（16億パラメータのビデオ・テキストジョイントエンベディングモデル）を採用
  • 動画とテキストを同じベクトル空間に射影し、物理世界（自動運転・ロボット）のデータに特化
  • 8倍以上のパラメータを持つQwen3-VLと比較したが、自動運転領域ではCosmos Embed 1が優位
• アーキテクチャ（4パート構成）:
  • フレーム画像の抽出: 映像デコードとエンベディング生成を分離し、将来のモデル切り替え時の再処理を回避
  • エンベディングの計算: オンプレGPUクラスターで毎日バッチ処理（AWSはコスト高のため）
  • テキストとベクトルの検索: DatabricksのAuto LoaderとDLTにより、エンベディングのS3アップロードを契機にインデックスを自動構築
  • テキスト検索用Lambda: CPUのみで数ミリ秒応答、Provisioned Concurrencyでコールドスタートを数秒以内に抑制
• 学びとコスト:
  • セマンティック検索だけでなく、SQL的な絞り込みとのハイブリッド検索が重要
  • DatabricksベクターサーチはJOINが不可でメタデータ追加のたびにインデックス再作成が必要という制限あり
  • バッチ処理はオンプレのためコストほぼゼロ、Databricksベクターサーチエンドポイントは月数千〜7,000円程度
  • POCに1週間、本番実装に1週間という短期間でリリース

■ 3. セッション2: レイヤーX — エスカレーション効率化エージェント「ラムジー」

• 背景:
  • BtoBのバックオフィスSaaSでお客様からのエスカレーション対応がエンジニアの開発業務を圧迫
  • 調査内容が多岐にわたるため、AIによる自動化をエンジニアギルドで検討
• システム構成:
  • SlackをインターフェイスとしてAIエージェント（AWS上）が調査し、結果をStreamlit（Snowflake上）のURLで返す
  • 調査フロー: 仕様・ソースコード・アプリケーションデータ・過去の調査記録の確認をAIが代替
• Snowflakeエコシステムの活用:
  • Cortex Analyst: アプリケーションDBのデータをSnowflakeに連携し、セマンティックビューを定義することで自然言語でのデータ照会を実現
    • セマンティックビューはAIエージェントが仕様書・スキーマ・ソースコードから自動生成
    • 分析用（集計重視）とは別に調査用（IDによる絞り込み重視）のセマンティックビューを構築
  • Cortex Search: ZendeskのデータをSnowflakeに連携し、ハイブリッド検索（キーワード＋ベクトル）で過去の類似問い合わせを検索
    • デフォルトモデルは英語・512トークン制限のため、多言語対応の大容量モデルに切り替え
• セキュリティとガードレール:
  • Cortex Agentの外部Webブラウザ検索ツールをオフに設定し、外部データ送信を制御
  • 出力をSnowflakeのマネージドステージに保存してStreamlitでレンダリングし、権限管理をSnowflakeに一元化
  • 実行SQLをレスポンスに含めてエージェントの調査過程を透明化
  • SQLのWHERE句をフックしてテナントフィルター漏れを検知・警告
  • 外部サービスDevin AIはSnowflakeデータアクセス後は呼び出し不可とする制御を実装
• コスト:
  • Snowflake側コストは1日数十件の利用のため大きくなく、LLM（Bedrock）のコストの方が高い
  • Langfuseでトラッキングしキャッシュを活用することでLLMコストを削減

■ 4. セッション3: Vポイントマーケティング — AIレディなデータ基盤のためのメダリオンアーキテクチャ

• 背景:
  • CCCグループで「社員全員がAIを活用できる」環境を目指し、Difyを社内展開
  • 市民開発メンバーがPDF・PPTXをDifyのナレッジベース（RAG）に取り込む際、テキスト化で情報が欠落する問題が発生
  • 各個人がナレッジベースを独自管理するため品質が散漫になるという課題も発生
• メダリオンアーキテクチャの適用:
  • ブロンズ層（IT・インフラチーム）: SharePointを非構造化データの格納場所として整備
  • シルバー層（AIエンジニアリングチーム）: AIを使ったデータ加工・テキスト化
  • ゴールド層（データエンジニアリングチーム）: Snowflakeでエージェントへのデータ提供
  • 各層の担当と必要な権限・専門性が社内組織構造とマッチした点が採用理由
• 非構造化データの処理フロー（シルバー層）:
  • SharePointとの接続容易性を理由にMicrosoft Fabricを採用（DatabricksよりFabricが優位）
  • PDFはPyMuPDFで各ページを画像化し、Azure OpenAIのLLMでマークダウン形式にテキスト化
  • PDF以外（PPTX・Word等）はLibreOfficeが使えないFabricの制約からMicrosoft Graph APIを活用
    • Graph APIのformat=PDFパラメーターでSharePoint上のファイルをPDF変換してダウンロード
    • Word・HTML・PowerPoint・Excel等の幅広い形式に対応
  • 抽出データにはページ種別（表紙・結論・通常）とページイメージURLも付与
• ゴールド層とエージェントへの提供:
  • SnowflakeのCortex Searchでハイブリッド検索（キーワード＋ベクトル）を実現
  • SnowflakeのManaged MCPサーバーとしてCortex SearchやCortex Analystを公開し、DifyやMCP対応クライアントからアクセス可能に
  • シルバーからゴールドへの差分更新でファイル更新・削除に対応
• 今後の課題:
  • SharePoint以外のデータソース（Googleドライブ等）への対応にDatabricksのコネクターを活用検討
  • センシティブな社内資料処理のために社内GPUクラスターでオープンソースLLMの活用を検討
  • LLMによる抽出結果の品質管理（図や画像内の関係性欠落への対処）

■ 5. 共通の知見

• LLMの発展により非構造化データの活用が急速に進んでいる
• データウェアハウス（Databricks・Snowflake等）でのベクトル検索基盤が整い、ElasticSearch等の自前構築なしにセマンティック検索を実装できる時代になっている
• コスト意識として、GPUや動画ストレージ等の主要コストと比較してベクトル検索・LLM推論のコストは相対的に小さい
• セキュリティ面では、本番DBの代わりにデータプラットフォーム上でフィルタリング済みデータを参照することが有効
• POCで先に使われるかを確認してから本格実装に進むアプローチが各社共通

(2026/07/23)

データエンジニアリングとドメイン駆動設計

• データエンジニアリングとドメイン駆動設計 - Speaker Deck

要約:

■ 1. 発表概要

• 登壇者: 増田 亨（masuda220）、有限会社システム設計
• 発表日: 2026年7月22日
• イベント: Data Engineering Study #36「"良いデータモデル"は、どこから生まれるのか」
• 参考文献:
  • 著書: 増田 亨(2017)『現場で役立つシステム設計の原則』技術評論社
  • 訳書: Vlad Khononov(著) 増田 亨、綿引 琢磨(訳) 2024 『ドメイン駆動設計をはじめよう』オライリージャパン
• 話題の構成:
  • 非集中型データアーキテクチャ「データメッシュ」
  • なぜ非集中型を採用するか
  • 非集中型にした場合の全体最適化

■ 2. データメッシュ（非集中型データアーキテクチャ）

• データエンジニアリングライフサイクルの3段階:
  • データ生成: 業務プロセス実行系のアプリケーション（データソース）
  • データ提供: データの抽出、モデルの変換、利用者への提供
  • データ利用: 意思決定支援、機械学習、業務プロセス実行系へのフィードバック
• データメッシュの基本構造:
  • 業務単位の開発チームがデータを所有し、データプロダクトを相互に提供する非集中型アーキテクチャ
  • 販売促進、商談、顧客サポート、入荷物流、注文処理、出荷物流などの各業務チームが独立してデータを管理・提供する
• データプロダクトの特性:
  • ビジネス上の特定の課題を解決するためにデータをパッケージ化する
  • 商品のように、商品内容の説明、取り扱い方法、品質保証、アフターサービスを提供する
  • データソースのアプリケーション開発チームが、所有するデータを使って他チームのニーズに合わせたプロダクト（データパッケージ）を提供する

■ 3. 非集中型を採用する理由

• 採用理由は目的適合性、発展性、安全性の3点
• 目的適合性の向上:
  • データソースの業務活動に精通し、データの正しい意味を熟知するチームがデータの提供に責任を持つ
  • データを利用したい業務分野のニーズを深く理解している開発チームが、分析用データのニーズをデータソース所有チームに提示する
  • 提供側チームと利用側チームが意図を伝達し合うことで高度なデータ活用が可能となる
• 発展性の向上:
  • 提供するデータの品質保証レベルが向上する
  • データソースのデータモデルは、提供するデータパッケージとは独立して進化可能
  • 提供するデータパッケージのデータモデルは、データソースのデータモデルとは独立して進化可能
  • 提供と利用の組み合わせの変更が柔軟で、データの活用方法を発展させやすい
• 安全性の向上:
  • データ管理の境界を明確に定義できる
  • データ管理の責任はデータ提供側が持つ
  • 境界をまたぐデータ移動をより安全により適切に制御できる

■ 4. 非集中型と全体最適化

• 全体最適の課題は「目指す方向の一致と設計判断の一貫性」と「効率化（ムリ・ムダ・ムラの検知と除去）」の2点
• 目指す方向の一致と設計判断の一貫性:
  • 事業目的適合性に焦点を合わせる
  • 事業活動を中核の業務領域（競争優位を生み出す）と一般の業務領域（他社と同じでよい）に分類する
  • 中核の業務領域は独自モデルとその実装を探究し続ける
  • 一般の業務領域は一般モデルをそのまま流用し、実装はできるだけ簡略に済ませる
• 業務領域の分類（2軸4カテゴリー）:
  • 横軸: 競合他社との差別化への影響度
  • 縦軸: 業務ロジックの複雑さ（開発の難易度）
  • 中核の業務領域（差別化大・複雑さ大）: 競争優位性◎、変化◎ → 内製開発、変更容易性の継続的改善
  • 一般の業務領域（差別化小・複雑さ大）: 競争優位性× → 模倣または購入を検討
  • 補完的な業務領域（差別化大・複雑さ小）: 競争優位性○、変化△ → CRUD/ETL機能の簡易開発
• 効率化（ムリ・ムダ・ムラの検知と除去）:
  • データプロダクトの企画と実装で事業目的適合性を評価して優先順位を決め、設計判断する
  • チーム間の対話を通じて事業目的適合性の捉え方を言語化し、チームの判断と行動の事業目的適合性を高める
  • 中核は発展性に価値があり、継続的な学習と育成を継続する
  • 一般はできるだけ簡略に済ませることに価値がある
  • 事業目的から外れる企画はやらない決断が重要
• 技術課題の効率的・効果的な解決手段:
  • データエンジニアリングの実践コミュニティを立ち上げ、継続的に活動する
  • データエンジニアリングの課題解決に必要な知識と技能を継続的に学習するための自発的なコミュニティを形成する
  • 組織や役職から独立した技術者の学習共同体として機能させる
  • 現場のリアルな課題感、課題解決の経験談（成功と失敗）をざっくばらんに話し合える場を定期的に持つ
• ボトムアップによる全体最適の促進:
  • 競争優位性（顧客が自社の製品を選ぶ理由）をどこに見出すかを全社的に問い続け、立場や経験の違いによる異なる見方を積極的に持ち寄ることで方向性を創発する
  • 組織や役職から離れた学習共同体の活動を組織として支援する
  • このボトムアップのアプローチが、中央集権的なルール作りとその徹底よりも効率的で効果的である

(2026/07/23)

Data Engineering Study #36「"良いデータモデル"は、どこから生まれるのか」

• Data Engineering Study #36「"良いデータモデル"は、どこから生まれるのか」 - YouTube

要約:

■ 1. イベント概要

• データエンジニアリングスタディ#36
• テーマ: 良いデータモデルはどこから生まれるのか
• SQL・DBTによる実装自動化が進む現在、データエンジニアの価値は「何をどうモデリングするか」という上流の設計思想にシフトしている
• 3つの角度から掘り下げた:
  • ドメイン駆動設計（DDD）の視点（増田）
  • ビジネスプロセスからの捉え方（寺島）
  • 20年以上の現場実践（松井）

■ 2. セッション1: ビジネスプロセスから始めるデータモデリング（寺島、株式会社10X）

• AI時代のデータモデリングにおける変化:
  • 変わらないこと: ガーベジイン・ガーベジアウトは引き続き有効であり、人間が読んで難しいクエリはAIが読んでも難しく再現性が低い
  • 変わること: 汎用的な「大福帳」テーブルの相対的価値が低下し、ルールに従って積み上げられたディメンショナルモデルをAIが扱えるようになっている
  • SQLを書くハードルがAIにより劇的に下がった結果、ディメンショナルモデリングされたデータをデータユーザーが扱える「モデリングチャンスの時代」が到来した
• 言葉の定義:
  • ビジネスプロセス: 業務の集まり（例: ネットスーパーの「注文する」「梱包する」「配達する」）
  • ビジネスイベント: それ以上分割できない業務の最小単位の出来事（例: 「注文が完了する」「注文変更する」「注文が確定される」）
• モデリングチャンス1「秘伝のWHEREが必要なファクト」:
  • fact_ordersに毎回「秘伝のWHERE」が必要になっていた原因は、テーブルが何のビジネスイベントを表しているかが不透明だったため（プロダクト側のDB設計をほぼそのまま移植した結果）
  • リファクタリングで「配達完了を表すイベント」としてfact_orders_deliveredを定義し直した
  • 選択の根拠:
    • 注文変更が締め時間まで可能なため、元のfact_ordersの金額は「事実」と言い切れない
    • 社内の重要KPIが配達完了注文の金額から計算されていると判明した
  • 結果: 秘伝のWHEREなしに安全なクエリが可能になり、1〜2年後も情報欠落の問題は発生しなかった
  • このリファクタリングはキンボール（Kimball）の4ステップ・ディメンショナルデザインプロセスに対応している:
    • Select the Business Process（配達完了を選択）
    • Declare the Grain（注文単位）
    • Identify the Dimensions（誰が・どこでのディメンショナルキーを用意）
    • Identify the Facts（ファクトに持たせる数値を決定）
  • 社内KPIが何のビジネスプロセスから集計されたかを明らかにする作業は現在でも人間に残されており、ヒントは社内ダッシュボードや秘伝スプレッドシートにある
• モデリングチャンス2「無理やりなJOIN」:
  • on_coupon_idをアンダースコアでスプリットしてクーポンコードと紐付けるという脆弱な処理が発生していた
  • 原因: プロダクト側DB設計に引っ張られすぎ、クーポンごとの文脈で集計できない構造になっていた
  • リファクタリングでクーポン周りのビジネスイベントを「取得する」と「使用する」に分けて再定義した結果、複雑なロジックが不要になった
  • 合わせてクーポンコードにスペースが入り得る脆弱性も発見し同時に改善できた
• ファクトとディメンションの境界線:
  • ドメインによって異なる（例: 住所変更はECサービスではディメンション、引っ越し業者ではファクトになり得る）
  • ソースが状態しか持っていない場合はアプリケーションエンジニアにイベントとして残してもらうよう依頼することが重要
• まとめ「モデリングチャンスのサイン」:
  • 秘伝のWHEREを毎回書いている
  • 無理やりなJOINでコンテキストをやりくりしている
  • AIに暗黙知をプロンプトで毎回渡している
  • ルールが闇鍋のように詰まっている
• Q&Aでの補足:
  • DIM＝ビジネスオブジェクト、ファクト＝ビジネスイベントは概ね妥当な捉え方であり、5Wに当てはまるものがディメンションになる（吉田）
  • データモデリングのROI証明は困難であり、セキュリティ観点や大福帳のメンテナンスコスト増大を論拠にする方が戦いやすい（寺島）
  • JOINが多くても機械的なパターンに従えるならAIが担える。書く大変さをAIが吸収しつつ、読む時の理解しやすさは高まるという観点がある（寺島）
  • 「何をモデリングしないべきか」については、使われなければ消しやすくする仕組みを作ることも重要（寺島）
  • バス行列（縦にイベント、横にディメンション）を作り複数ファクトで共有されるディメンションを整理することで優先度の高いディメンションを判断しやすくなる（吉田）

■ 3. セッション2: データエンジニアリングとドメイン駆動設計（増田徹、有限会社システム設計）

• データメッシュの概要:
  • DDDの影響を受けて生まれた非集中型データアーキテクチャ
  • 各業務のアプリケーション開発チームがデータ生成・提供・分析データの利用を自チームに閉じて担当する
  • 他チームのデータを利用する場合は提供側が品質を保証した「データプロダクト」として提供する
  • 各チームがプロダクトを提供し合うことでメッシュ（網目）構造のネットワーク構造になる
• データのライフサイクル（3段階）:
  • データ生成: 業務プロセス実行系アプリケーションのDBに記録
  • データ提供: データを収集・変換して利用者に提供
  • データ利用: 意思決定支援、機械学習、業務プロセスへのフィードバック
• データプロダクトの特徴:
  • 特定の課題を解決するための製品であり、汎用的なデータパッケージではない
  • 内容説明・取り扱い方法・品質保障・アフターサービスまで含めて提供される
  • データソースのアプリケーション開発チームが所有するデータを利用者のニーズに合わせて提供する
• 非集中型を採用する3つの理由:
  • 目的適合性の向上: データソースの業務活動に精通したチームが正しい意味を熟知しており、専門性を持ったチーム同士が意図を伝達し合うことで高度なデータ活用が実現できる
  • 発展性の向上: データソースのモデルと提供パッケージが独立して進化可能であり、活用方法を発展させやすい
  • 安全性の向上: データ管理の境界がアプリケーション開発単位で明確に定義され、出てはいけないデータを管理できる
• 非集中型における全体最適化のアプローチ（2つの側面）:
  • 目指す方向の一致と設計判断の一貫性:
    • 「中核の業務領域」（競争優位を生む）と「一般の業務領域」（他者と同じでよい）を区別する
    • 業務ロジックの複雑さと競合他者との差別化の影響度の4象限で整理する
    • 中核は自社独自で徹底的に取り組み、一般は模倣・購入・省略・AIの一般論活用も選択肢
  • 効率化・無理・無駄・ムラの検知と除去:
    • 事業目的適合性を優先して評価・優先付けする
    • データエンジニアの実践コミュニティを立ち上げ、現場の課題や失敗談を話し合える場を定期的に持つ
    • 「お客さんが自社を選ぶ理由」を全社的に問い続け、多様な視点で方向性を洗練させる
    • 専門部署による中央集権的なルール管理より、この方が的確で効果的
• Q&Aでの補足:
  • N対Nの複雑性は事業目的適合性による優先順位付けで対処する。中核は優先的に提供し、一般は単純なモデリングでサッと提供、優先度が低ければ作らない（増田）
  • 品質の認識差は最初から綺麗な合意は取れないため、できるだけ早期に出して使ってもらい継続的な話し合いで解決する（増田）
  • 複数ドメインから参照される「顧客」エンティティ問題は「そこにコストをかける価値があるか」という議論が起点であり、合わせられないなら「実は中核の業務かもしれない」という議論になる（増田）
  • データエンジニアはディメンショナルモデルだけでなくリレーショナルモデルも学び、視点を増やして繋がりを考えることが重要（増田）
  • リレーショナルの正規化を突き詰めた第6正規形はほとんどデータボルトと同じ構造になり、各アプローチが行き来できるようになる（増田）
  • 「継続することが唯一の戦略実行の条件」であり、断続的になっても続けることだけが戦略を実行できる理由（増田）

■ 4. LT: プライムナンバーからのご案内（高畑、プライムナンバー）

• 良いデータモデリングを実行する際の3つの難所:
  • 対話の促進: DDDは対話のための設計技法であり、対話を促進するためのやり方とその時間・労力の問題がある
  • イベントの整理: 現実世界で起こっていることをまとめるために多くの関係者との対話が必要
  • 設計への落とし込み: データボルトなど様々な概念の中でどう設計に落とすかの問題がある
• プライムナンバーではデータ基盤構築支援を提供しており、DDDや各種設計技法を踏まえた土台作りや既存データ基盤の改修も対象
• 8月25日に「PUGfest」を開催（AI活用を中心とした豪華登壇者・交流企画あり）

■ 5. セッション3: 分析基盤におけるデータモデリング20年史（松井太郎、Vポイントマーケティング株式会社）

• 登壇者の立場:
  • Vポイント（年間利用者1億3000万人）のテクノロジー戦略本部長
  • 2011年頃からTポイント・Vポイントの分析基盤に携わっている
  • 「良いデータモデルはどこから生まれるか」への答えは「何を解くかの見極めから生まれる」
• 2003年〜 Tポイント誕生と初期基盤:
  • 国内初の共通ポイントサービスとしてTポイントが誕生し、1業種1社の原則で急ピッチで拡大
  • 急速な事業拡大によりインフラ・アプリ・データモデル全体の再構築が必要になった
• 2008〜2010年 基盤刷新:
  • 数万QPS対応のための処理性能向上
  • トランザクション処理方式の根本的な見直し
  • 企業・業態・店舗などの階層データをポイントデータとして持てるよう整理
• 2011年〜 加盟先データの標準化（現代で言う「データコントラクト」）:
  • 加盟先ごとのカスタマイズをやめ、分析に必要な項目を明文化して加盟先に弊社仕様でデータを送ってもらうよう契約時に合意形成した
  • 標準化の具体的内容:
    • ジャンルコード・商品コードの正規化
    • 税抜き統一（消費税率変化による売上誤解を避ける）
    • 値引き仕様の統一
    • テーブルごとの必須・オプション項目の区別
  • セールスエンジニア的な役割が重要であり、結果として年間数十社加盟してもスケールするようになった
• 2013年〜 商用分析サービスの構築と履歴管理（現代で言う「SCD Type 2」）:
  • 外部向け商用分析サービスの構築により特定時点でのマスタとの整合性が必要になった
  • データの履歴管理と特定時点でのマート化を実装した
  • 分析サービス拡大でアクセスが10倍以上になりExaDataがパンク、2015年にVerticaへリプレースして処理性能を数十倍向上
• 2016年〜 クラウドへの移行とアナリストとの役割分担（現代で言う「メダリオンアーキテクチャ」）:
  • OracleからAzure Synapseへ移行し、データマートを自由に作れるようになった
  • 役割分担を確立:
    • エンジニア（5名）: 外部データを正規化するまで
    • データアナリスト（当時40名→現在70名）: BIへの連携・レポート作成
  • アナリストのスキルのばらつきに対してガードレールや実装ガイドラインを継続的に見直している
• 2017年〜 販売管理システムの再構築（DOAアプローチ）:
  • 会員基盤6〜7000万人に伴いサブシステムが乱立したため、全社的に業務フロー・機能・帳票を可視化・ドキュメント化
  • 媒体が今後も増えることを前提に汎用的に運用できるデータモデルを設計し、DOA（データ中心アプローチ）でデータモデルを中心に業務設計した
• 2021年〜 Snowflakeへの統合:
  • Vertica・Azure Synapse・Oracle ExadataをSnowflakeに統合（ハードウェア保守期限やライセンス契約タイミングを考慮しながら5年かけて段階的に移行）
  • 成果:
    • SSOT（Single Source of Truth）の実現
    • コスト・性能担保の容易化
    • エンジニアが3つのDBを覚える必要がなくなり、内製化が進んだ
  • テーブル数は1万超（ワークテーブル含めると2万近く）であり、用途別のDB・スキーマへ再配置し重複・不要テーブルの整理を業務・アナリスト・運用チームで協力して実施
• まとめ「歴史から得られた知見」:
  • 良いデータモデルは「作った瞬間がいい」のではなく、「維持されているからいい」
  • 「どこでモデリングするかを選び続けた」ことが最大の価値であり、上流の機幹システム・プロダクトへの直接投資にこだわってきた
  • 基本的にディメンショナルモデル＋スタースキーマ構成で格納し、アナリストがSQLでJOINしながらレポートする構成
  • 今後は「どこで生むか」に加えて「いつ見直すべきか」が重要な課題になる
• 式年遷宮的アプローチ:
  • 「式年遷宮」（数年に1回業務のずれを溜め込んで一気に直す）とアジャイル型の継続的改善を補完的に組み合わせる
  • 式年遷宮の際に業務の可視化・言語化・暗黙知の形式化とアーキテクチャの改善も合わせて行う
  • モデル更新が必要なサイン:
    • 入力情報の定義変化・意味の変化
    • 入力エラーの増加
    • 特定の機幹システムから毎日全量ダウンロードしているなど（システム外に新しい業務が生まれているサイン）
  • AIエージェントを動かす上でも業務や機幹システムが最新化されていないとエージェントはずれた動きをするため、業務変化やずれの意味を判断できる人材育成が必要
• Q&Aでの補足:
  • 「相手の目線でなく相手のことを考えながら、あるべきは何かから入る」ことを重視している（松井）
  • データモデル入れ替えでの過去データとの整合性は極力移行し、無理な場合はレガシーテーブルとして残すなど落としどころを決めて割り切る（松井）
  • 自社の媒体の特殊性がSaaSに合わなかったため自社開発・DOAアプローチを選択した（松井）
  • 「美しい世界を作りたい」という動機で取り組み、2〜3年後に自分が作ったシステムを壊して作り直すこともある（松井）
  • コミュニティ活動は外の物差しを知るという意味で価値がある（松井）

(2026/07/22)

2002年、IT業界に入って苦節23年、我慢して糞みたいな特定派遣でいじめられな..

• 2002年、IT業界に入って苦節23年、我慢して糞みたいな特定派遣でいじめられな..

2002年、IT業界に入って苦節23年、我慢して糞みたいな特定派遣でいじめられながら生きて、2010年にweb業界に入って、詐欺師や頭のおかしいイキリ意識高い系の役員のスタートアップでブラック労働をして

お金も女もできず、あれだけ熱意があったオタク趣味も秋葉原もいかなくなって、ストレス発散といえば、はてな匿名でテック論でマウント取ったり、年収1200万のイケイケwebエンジニアって経歴詐称して天下国家や技術論語ったり、

やってた時は楽しかったんだろうけど、その後激烈に虚無感と自分への惨めさがきて頭がキューッてなるんだよ、でもやめられないんだよ、だって現実がクソなんだから

MEMO:

• とはいえ、それを自分で選んだんでしょっていう

(2026/07/22)

Rust に書き直さなくても C 言語をメモリ安全にできる Fil-C を試した

• Rust に書き直さなくても C 言語をメモリ安全にできる Fil-C を試した

要約:

■ 1. 背景: 言語移植とメモリ安全性をめぐる議論

• BunのJavaScriptランタイムがZigからRustへ移植された（理由の一つはメモリ安全性由来のバグ）
• ZigのAndrew Kelley氏が反論：問題は言語ではなく開発プラクティスにある、レビューされていない生成コードが安全とは言えないと指摘
• 逆方向の例として、RocコンパイラがRustからZigへ移植され、インクリメンタルビルドが3.4秒から35msに改善、メモリ破壊バグはZig版の方が少なかった
• 「メモリ安全のために言語を乗り換えるべきか」の議論は決着しておらず、どちら向きの移植にも莫大なコストがかかる
• Kelley氏がFil-Cにインスパイアされたメモリ安全コンパイルモードをZigのissueに提案し承認された（コードではなくコンパイラとABIでメモリ安全を実現する方針）

■ 2. Fil-C の概要

• 開発者:
  • Filip Pizlo氏（Epic Gamesシニアディレクタ、元Apple WebKit/JavaScriptCore開発者）が開発
• 構成:
  • clang 20.1.8ベースのコンパイラと専用ランタイムで構成
  • C17およびC++20に対応
• 互換性:
  • "fanatically compatible（狂信的に互換）"を謳い、既存のC/C++コードをほぼ変更なしでコンパイル可能かつメモリ安全化
  • OpenSSL、CPython、SQLite、OpenSSH、Emacsなど多数のソフトウェアが動作確認済み
  • Fil-CのみでビルドされたLinuxユーザランド「Pizlix」も存在
• 設計方針:
  • Rustのunsafeに相当する抜け道が存在しない
  • AddressSanitizerのような「バグ検出ツール」ではなく「防御機構」として設計
  • タグベースのASanやMTEと異なり、ケーパビリティベースで攻撃回避が困難
  • CHERI相当の安全性を通常のx86_64上で実現

■ 3. 技術的な仕組み

• InvisiCaps:
  • メモリ上の全ポインタに、Cのアドレス空間からは見えないケーパビリティ（下限・上限・状態）を対応付け
  • LLVM IRレベルの全基本操作をケーパビリティに対して検査
• FUGC（Fil's Unbelievable Garbage Collector）:
  • 並行ガベージコレクタ
  • free()はオブジェクトを「free状態」にマークするだけで、実際のメモリ回収はGCが行う
  • use-after-freeが原理的に攻撃に利用できない構造
• エラー処理:
  • 検査違反は全て「Fil-C panic」として捕捉され、スタックトレース付きでプロセスが停止
  • ヒープ・スタックの範囲外アクセス、use-after-free、型混同、va_list誤用、システムコールバッファ検査などをカバー

■ 4. インストールと基本的な使い方

• 現時点でLinux/x86_64のみサポート
• GitHubのリリースページからバイナリを取得し、setup.shを実行するだけでインストール完了
• patchelfが必要（事前にインストールが必要）
• build/bin/clangを通常のclangと同様に使用可能、libcにはmuslを使用

■ 5. メモリ安全性の動作例

• バッファオーバーフロー:
  • スタックバッファオーバーフローを試みると、上限超え書き込みとして検出されFil-C panicが発生
  • 発生箇所のファイル名・行番号をスタックトレース付きで表示
  • libcのstrcpyもFil-CでビルドされているためライブラリAの深い場所のオーバーフローも捕捉可能
• use-after-free:
  • free済みオブジェクトへのアクセスを検出してパニック
  • GCが「ポインタが本当に無くなってから」メモリを回収するため、解放後メモリが別オブジェクトに再利用される攻撃が起きない
• ケーパビリティの確認:
  • stdfil.hの独自ヘッダを通じてポインタに付いたケーパビリティ（値・下限・上限）を確認可能
  • ポインタ演算で値が動いても下限・上限は変わらず、freeすると上限が下限まで潰されfreeフラグが付く

■ 6. パフォーマンス比較

• 比較環境:
  • Ryzen 7 7735HS上のWSL2
  • gcc 13.3 / clang 18.1 / Fil-C 0.681 / rustc 1.95.0-nightly / zig 0.15.2 / go 1.26.1
• ベンチマーク種別と結果（gcc比）:
  • mandel（浮動小数点中心）: Fil-Cは約1.05倍でオーバーヘッドは誤差の範囲
  • sieve（配列アクセス中心）: Fil-Cは約2.3倍で境界チェックのコストが顕在化
  • btree（アロケーション・ポインタ辿り中心）: Fil-Cは約1.1倍で予想外に健闘、Zigの ReleaseSafeより速い
• btreeの考察:
  • 並行GCによりfree()が即座にメモリを返さない設計がアロケーション多発時に有利に作用
  • 最速はGoの0.65倍で、トレーシングGCが死んだオブジェクトに触れずまとめて回収できるためと考えられる
  • Fil-CのFUGCも同様の恩恵を受けている可能性が高い
• 全体的な見通し:
  • 実アプリケーションではポインタ辿りの多さ次第で1〜6倍程度
  • ASanと異なり本番投入を前提に最適化が継続されており、バージョンを追うごとに改善

■ 7. 現時点の制限

• 動作プラットフォームはLinux/x86_64のみ（以前はmacOS/ARM64でも動作していたため原理的な制限ではない）
• 通常の方法でビルドされた既存バイナリ（.so）とはリンク不可
• 依存ライブラリを含め全てFil-Cでビルドする必要がある（これは設計思想であり、推移閉包まで含めた完全なメモリ安全性の裏返し）

■ 8. まとめ

• C/C++を書き直さずにそのままメモリ安全にするFil-CのアプローチはC/C++資産を持つ開発者にとって魅力的
• 再コンパイルするだけでバッファオーバーフローからuse-after-freeまで防止可能
• ZigがFil-C方式を取り込もうとしており、他の言語にも波及する可能性がある
• パフォーマンスが最重要でないネットワーク境界のツールやパーサなどへの適用が有望

(2026/07/22)

「タイピング数が減ったから在宅勤務廃止」の違和感——「AIで5000万円が3万円」と語る会社が、キー入力を...

• 「タイピング数が減ったから在宅勤務廃止」の違和感——「AIで5000万円が3万円」と語る会社が、キー入力を数える矛盾｜kou@エンジニアのIT情報解説

要約:

■ 1. 概要と背景

• GMOインターネットグループが2026年7月に在宅勤務を完全廃止すると発表
• 廃止の根拠として「時間当たりのPCタイピング数がデータ上確実に減っている」が示された
• 同グループ代表は直前に、AIコーディングで「5000万円相当の開発をトークン代3万円で実現」と発表していた
• 代表自身が音声入力でAIに指示する開発スタイルを実践し、全社員（約8300人）に音声入力用マイクを配布する取り組みも進めていた

■ 2. 二つの発言が生む矛盾

• 「キーボードを使わず音声でAIに指示しよう」と全社に呼びかけながら、「タイピング数が減ったから出社せよ」と言っている
• AI活用が進めばタイピング数が減るのは必然であり、タイピング数の減少はサボりではなくAI活用の浸透を示す証拠にもなり得る
• 「仕事の入力量（タイピング）をAIが代替する」と主張しつつ、人の評価は旧来の入力量で行う不整合が存在する

■ 3. 「5000万円が3万円」の数字が抱えるズレ

• 根拠となった5000万円の算出方法:
  • SIerの「コード1000行あたり100万円」という行数見積もりから「10万行=50人月=5000万円」と逆算したもの
  • コード行数と開発価値は別物であり、AIが生成するコードほど冗長で行数が膨らむ傾向がある
  • 行数×単価で価値を測る発想はAI以前からエンジニア間で時代遅れとされていた
• 比較対象のミスマッチ:
  • SIerの5000万円には要件定義、設計レビュー、テスト、セキュリティ検証、障害時の責任、保守コストが含まれる
  • 代表が作成したのは自分専用アプリであり、「業務システムの受託開発」と「個人の趣味開発」を同列に比較している
• コストの不完全な計上:
  • 3万円はAIのトークン代のみであり、代表本人が費やした2カ月分の時間コストが含まれていない
  • 経営トップの2カ月間のコストを換算すれば3万円には到底収まらない

■ 4. タイピング数という指標の危うさ

• 監視そのものの問題:
  • 情報漏洩対策としてのPC操作ログ取得と、サボり判定への転用は性質が異なる
  • 監視されると知った人間は仕事の成果ではなく「監視指標のスコア」を最適化し始める（グッドハートの法則）
• 指標の脆弱性:
  • キー入力を自動発生させるツールやマウスを動かし続けるガジェットが数千円で入手可能
  • 欧米では「マウスジグラー」が一大市場となり、大手金融機関が使用者を解雇する騒動も起きた
  • 本気でサボる人はすり抜け、対策しない正直な人だけがあぶり出される監視指標として機能しない

■ 5. 出力（サービス品質）で測るべきだという視点

• タイピング数という入力量ではなく、サービスの成果物（出力）で評価すべきという論点
• 同グループの看板サービス「お名前.com」の実態:
  • 契約画面での不要オプションへの初期チェック
  • 「0円」表示の先での課金発生
  • ドメイン取得後の大量広告メールによる重要通知の埋没
  • 「ダークパターン」への批判が繰り返されてきた
• 社員監視とサービスUI設計の共通思想:
  • ユーザーや社員を「信頼して価値を届ける相手」ではなく「数字を最大化するために管理する対象」として見ている構造が透けて見える

■ 6. 優秀な人材から先に離職するリスク

• 米国の研究データ:
  • 大手テック企業3社の出社義務化分析で、義務化後に離職が突出して増えたのはスキルの高いシニア人材
  • 優秀な人ほど転職市場での選択肢が多く、信頼されない環境に留まる理由がない
• 日本での事例:
  • 国内大手テックグループでフルリモート廃止後に自己都合退職が前年比65%増となった例がある
• 今回のケースの問題点:
  • 出社強制に「タイピング数で監視されている」が加わることで、腕に覚えのあるエンジニアほど離職を選ぶ動機が強まる
  • AI時代の競争力の源泉は「AIを使いこなす優秀な人間」であり、その流出は本末転倒

■ 7. 結論: 測る物差しが信念を表す

• 在宅勤務廃止という判断自体は、対面で伸びる仕事の存在や世界的な出社回帰の流れから見てあり得る選択
• 問題はその根拠として「タイピング数」が示されたこと
• 二つの発言に共通する根本的なズレ:
  • 「5000万円が3万円」→ 行数という古い物差しでAIの成果を測ったズレ
  • 「タイピング数が減ったから在宅廃止」→ キー入力量という古い物差しで人の働きを測ったズレ
  • 両者の根底にある共通点: 「仕事の価値を量で測れると信じている」
• AI活用が進む時代に最初に捨てるべきは、量で人を測る物差しだった

(2026/07/22)

話題の組み込み型のベクトルデータベース LanceDB を Amazon S3 と Amazon Bedrock で試してみた

• 話題の組み込み型のベクトルデータベース LanceDB を Amazon S3 と Amazon Bedrock で試してみた | DevelopersIO

(2026/07/22)

最近の AI コーディングで実践している、設計を中心とした開発の進め方

• 最近の AI コーディングで実践している、設計を中心とした開発の進め方

要約:

■ 1. 開発フローの概要と変化

• AIコーディングエージェントの普及により、自分でコードを書く時間が大幅に減少した
• 実装そのものより実装前の設計セッションが開発の中で最も時間のかかる工程となった
• 複数のエージェントを並行して動かすことが日常化した
• 最初に全体を見据えた設計を行い、独立して実行できる単位にタスクを分解することが重要
• 人間は並列実行のための設計やデータモデル・責務の境界といった影響の大きな判断に集中するようになった

■ 2. AIへの指示方法: 詳細手順よりゴールの共有

• ファイルごとの編集手順や関数内部の実装方法を細かく指定しない
  • 詳細な手順を渡しすぎると、AIがより良い方法を提案する機会が失われるため
• 「grill-me」スキルなどを使い、設計やデザインについて共通理解が得られるまで徹底的にインタビューを実施する
• 設計前に議論すべき観点:
  • なぜこの変更が必要なのか
  • 何を満たせば完成なのか
  • ドメイン上、壊してはいけない制約は何か
  • コンポーネント間の責務をどのように分けるか
  • どのような振る舞いを検証できれば正しいと判断できるか
• ゴール、制約、責務の境界、インターフェース、検証すべき振る舞いは事前に議論し、局所的な実現方法はAIに委ねる

■ 3. 実装前の設計セッション

• 複数タスクを並行実行する際、人間がすべてのエージェントを監視し続けることはできない
• 認識のずれが残ったまま実装を始めると、ずれに気づくのはすべての作業が終わった後になる
• 設計セッションではAIの提案に対して受け身にならないことが重要
  • ドメイン上の制約や既存アーキテクチャを選んだ理由、提案への違和感を言語化して伝える必要がある
• 責務の分け方、依存関係の方向、拡張性の判断は、AIの提案を材料にしながら人間が判断する
• 何も考えていない状態からAIが魔法のように設計を作ってくれるわけではない

■ 4. 設計書の管理

• 設計の結果はチャット履歴だけに残さず、別のドキュメントとして整理することが望ましい
• 現時点ではGitHub Issueのコメント欄に設計書を置くことが多い
  • タスクの進行状況と紐づき、設計書の更新履歴も残るため
• Markdownファイルとしてリポジトリに置く方法も検討に値する（AIが参照しやすい）
• 設計書は以下の2種類に分けて管理する（「意思決定は残し、作業手順は使い終わったら捨てる」）:
  • 長く残る設計判断: ADRや設計ドキュメントとして永続的に残す
  • 今回の実装だけに必要なタスク分解や進行手順: Issueのコメントなど使い捨てできる場所に置き、実装後に捨てる

■ 5. 並列タスク実行とモノレポ

• 設計完了後、独立して実行できる単位にタスクを分解する
• Git worktreeで作業ディレクトリを分離し、Claude Desktopの別々のスレッドで並列実行する
• CLIよりClaude Desktopを好む理由:
  • 複数スレッドの状態を一覧しやすい
  • 設計と実装のセッションを分離しやすい
  • 図表描画機能で設計の議論を視覚的に確認できる
• worktree環境の整備として、作成時に node_modules のシンボリックリンクを作成するhooksを設定する
• AIに「設計書を元に実行可能なタスクへ分割し、サブエージェントを並行実行」と指示することも可能
• モノレポの利点:
  • 複数領域を横断した依存関係・実装パターンの探索が容易
  • 複数の実装セッションが同じ設計書・検証コマンドを参照できる
  • 横断的な変更の影響範囲を調査した上でタスク境界を決めやすい
• ポリレポの場合、別リポジトリへの相対パスをプロンプトで示しながらセッションを開始するという方法が有効

■ 6. 自律的な検証環境の整備

• AIが自律的に実装するためには、自分の変更に対してフィードバックを得られる環境が必要
• テスト・型チェック・Lintに加えて、開発サーバーを起動した状態での実動作の確認まで自律的に行えるようにする
  • フロントエンドの変更: ブラウザ操作で確認
  • APIの変更: curl でリクエストを送信しレスポンスを確認
• 期待する振る舞いは設計段階で決め、確認手順はプロジェクト固有のスキルとして手順化する
• ブラウザ操作には Claude Desktopのブラウザ操作機能を利用する
• フィードバックループの速度向上が重要であり、Vite+スタック（Vite、Vitest、Oxlint、Oxfmt、tsgo）を積極的に採用する
• フィードバックループの改善は、使うモデルやプロンプトと同等に重点的に取り組むべき対象

■ 7. コードレビューの方法

• PR作成後は必ず別のセッションでAIにコードレビューを依頼する
  • 実装セッションは自分の変更を正当化する方向にバイアスがかかりやすいため
• AIレビューの役割: 論理的なロジックの誤り、テストカバレッジの不足、局所的な可読性の低さを探す一次チェック
• 人間のレビュー観点:
  • 要件を満たしているか
  • 責務の境界が設計と一致しているか
  • 認証・決済・個人情報・データ移行など高リスクな変更に問題がないか
• すべての行を同じ注意力で読む必要はなくなった

■ 8. CLAUDE.mdとスキルの整備

• 役割の分担:
  • CLAUDE.md: リポジトリ構造、標準コマンド、プロジェクトの暗黙知、すべての作業で参照する短い原則
  • プロジェクト固有スキル: 検証手順や定型作業など複数タスクで再利用できる作業パターン
  • 個人スキル: grill-me やコードレビューなど複数プロジェクトで再利用できる作業パターン
• AIの動作ログを観察し、迷いが生じた箇所を CLAUDE.md やスキルに追記する
• スキル作成はタスク完了直後に「今行った作業とフィードバックをもとにスキルとしてまとめて」と指示すると効率的
• 指示文の改善だけではコードベースの問題を解決できない
  • 「依存方向を守る」と書くより、パッケージ境界をコード上で明確にしたりLintルールで違反できなくする方が確実
• AIにとって扱いやすいアーキテクチャの条件（新しい原則ではなく、従来から重要とされてきた性質と同じ）:
  • 責務の境界が明確である
  • 依存方向が一貫している
  • 変更の影響範囲を局所化できる
  • インターフェースから振る舞いを理解できる
  • テストによって境界の振る舞いを確認できる
  • 命名やディレクトリ構成から必要なコードを探索できる

■ 9. コードを書く能力と設計能力の変化

• 実際に自分の手でコードを書くことはほとんどなくなった
• 能力変化の内訳:
  • 衰えた面: 特定の構文や細かな実装パターンを思い出す機会の減少、局所的なコードの美しさへの注意
  • 増えた面: システム全体の俯瞰、責務の境界・依存関係・複数変更統合時の整合性を考える機会
• 現在使っている設計能力は、過去に自分でコードを書き失敗してきた経験に支えられている
• 最初から実装をすべてAIに委ねた場合に同じ設計判断能力を身につけられるかは不明であり、若手育成については別途検討が必要

■ 10. レビューのボトルネックと対策

• AIが複数のPRを同時に作成すると、人間による従来のレビューがボトルネックになる
• 対策: コードレビューを階層化する
  • 人間: 全体の設計、高リスクな変更（認証・決済・個人情報・データ移行など）を重点的にレビュー
  • AI: 局所的な実装品質の確認（論理誤り・テストカバレッジ・可読性）
  • 自動検証: AIレビューと組み合わせて個々の実装を通す
• 実装前の全体設計を人間どうしで相互にレビューしておくアプローチも有効
• PRを小さく分割することもボトルネック軽減に有効
  • AIに対してPR分割の観点を相談しながら進め、複雑なgit操作も任せられる
• PR変更の設計意図・変更理由は、AIが作成した場合も担当エンジニア自身が説明できるようにする

■ 11. 承認の最小化

• 逐一承認を求める設定では自律的なフィードバックループを回せない
• 承認対象が増えるほど「承認疲れ」が起き、本当に必要な操作を見逃す可能性が高まる
• サンドボックス環境の整備が重要: AIが誤った操作をしても被害を最小限に抑えられる
• Claude CodeのAutoモードやCodexの「代理で承認」機能のように、AIが承認要否を自律的に判断する仕組みが登場している
  • すべての承認をスキップするのではなく、機密データの漏洩・重要ファイルの削除・悪意のあるコードの実行などを検出した場合のみ人間の承認を要求する

■ 12. モデルのコストと性能の選択

• 現在は利用可能な最高性能モデルをほぼ常に使用している
  • タスクの分類コストや、能力不足による手戻りを考慮すると高性能モデルへの統一が扱いやすいため
  • 設計セッションで誤ると並列実行するすべてのタスクが間違った方向へ進むため、設計段階でモデル能力を節約しない
• 今後の課題:
  • 従量課金制移行や並列タスク増加により、モデルの使い分けが必要になる可能性がある
  • 比較すべきはトークン単価ではなく、変更完成までの総コスト（実装やり直しやレビュー増加を含む）
• モデル選択に加え、思考の深さを調整する「effort level」という軸も登場している
• 設計など複雑なタスクは高性能モデル、単純作業や既存パターンに従う変更は安価なモデルといった使い分けが一般的だが、現状は人間の勘に頼っている部分が多い

■ 13. AI中毒への注意

• サブスクリプションのリミットを使い切れなければ損をしたように感じるという強迫的な感覚が生じる
• AIが返す非決定的な結果には、ガチャに似た快感がある可能性がある（非決定的な報酬を待つ際のドーパミン活性との類似）
• AI常時稼働と価値ある仕事の進捗は同じではない
  • 並列数を増やすほど、レビューや統合の負担も増える
• 必要のないタスクを作りAIの稼働率を上げること自体が目的化していないか注意する
• AIに何をさせるかだけでなく、何をさせないかを判断することも今後の設計対象となり得る

(2026/07/21)

レビューは人間がすべきか問題：Critの紹介

• レビューは人間がすべきか問題：Critの紹介 - インゲージ開発者ブログ

要約:

■ 1. 背景と問題提起

• バイブコーディングの普及によりプルリクエストは大量生成できるようになったが、レビューがボトルネックになっている
• レビューをAIに任せるべきかという議論がある一方、人間がすべきという意見もある
• ビジネスにおいては、コードをAIが生成しようと人間が作ろうと、責任は会社が負う

■ 2. コードレビューの目的

• 目的確認:
  • 指示を出すのは人間であるため、指示が間違えば成果物も誤りになる
  • 「そもそも目的が間違っていないか」という観点の指摘は人間にしかできない
• コードチェック以外の役割:
  • 冗長化体制の構築:
    • レビューアの存在により「作った人しか知らない」状況を防げる
    • 少なくとも作成者とレビューアの2人が内容を把握できる
  • レビューア自身の成長:
    • レビューを重ねることでレビュー力が向上する
    • 多角的な観点でコードを書く力が身につき、コード品質が向上する
• 冗長化については、AIが都度調べられるため不要という見方もある
• 一方、GitHub差分ビューを注意深く見てレビューしていた頃に比べ、技術力の成長が維持できているかは疑問

■ 3. Critの紹介

• 概要:
  • エージェントが変更したコード、ドキュメント、ローカルアプリをブラウザ上でレビューできるツール
  • GitHubのPRレビューと同様に、行単位でハイライト・コメントを付けられる
• インストール手順:
  • brew install crit でインストール
  • Claude Code上で /plugin marketplace add tomasz-tomczyk/crit と /plugin install crit@crit を実行
  • プロジェクトルートで crit install claude-code を実行してスキルファイルを読み込む
  • /reload-skills でスキルを再読み込みして準備完了
• 使用フロー:
  • コード完成後に /crit と入力する
  • localhostでサーバが起動し、ブラウザが自動起動してGitHubのファイル差分ビューと同様の画面が表示される
  • コード行にインラインでコメントを記入し、「Finish Review」ボタンを押す
  • Claude Codeが自動的にコメントへ返答またはコード修正を行う
  • 修正後は再びレビューモードになり、解消済みのコメントに「Resolved」マークを付ける
  • すべてResolvedになると「Finish Review」ボタンが「Approve」ボタンに変わり、承認でレビュー完了
• 利点:
  • 相手がAIのため、どんな質問でも何度でも問い合わせられる
  • 同僚のコードをレビューしていた感覚でAI生成コードをレビューでき、コードへの理解が深まる

■ 4. 結論

• レビューを人間がすべきか、AIがすべきかの二元論ではない
• コードレビューにはチェック機構以外の役割（成長・冗長化）があるため、人間の関与は依然として重要
• 当面は人間がAIを活用しながら自らの成長のためにレビューする形が適切

■ 5. 補足

• Rubyの *.rake ファイルを編集しCritで表示した際にコードハイライトがされなかったため、本家リポジトリにPRを送ったところ、すぐに取り込まれた
• Critの開発はAIを活用していると思われるが、対応がアクティブで良好

(2026/07/21)

AIのせいでOSSは消えるのか?

• AIのせいでOSSは消えるのか? - araen blog

要約:

■ 1. AIによるOSS衰退論の問題点

• AIによってOSSが消える・大きく衰退するという主張は解像度が低く、ゼロイチ思考に陥っている
• AIで自前にSAPやSalesforceを作って社内運用できるという発想と同様に非現実的であり、少しAIを触れば素人でも容易に分かる
• この種の「〇〇は死んだ」論は定期的に繰り返し出現する

■ 2. AIはコピペを加速させたにすぎない

• 筆者はウェブ制作のバイト時代にgulp/webpack/Node.jsを使っていたが、内部のlibuv・epollを知らなくても開発できた
• Qiitaでコードをコピペすればモノが作れたように、AIはそのコピペを加速させたにすぎない
• 元記事は「依存関係への意識の低さがOSSの不可視的衰退を招く」と主張するが、現代では人間がすべての依存関係を理解することはすでに不可能に近く、その定義に従えば衰退はすでに完了している

■ 3. オーダーメイド開発という発想の誤り

• 現代のAI環境でNode.jsやgulpをゼロからAIに作らせるという発想は生まれない
• むしろAIに現代で最良のパッケージを調べさせる方向に向かう
• コンピューターのあらゆるものが複数のレイヤーで構成されているという事実を忘れた発想
• AI coding agentがbashコマンドの実行やファイルの読み書きを行えるのは、長年にわたって合意されたAPIが存在するから

■ 4. 今後残るOSSの条件

• 残るOSS:
  • ドメイン的・システム的・歴史的経緯などの複雑さを適切に抽象化したインターフェイスを提供するもの
  • 例: libuv、epoll
  • これらのプリミティブが存在するからこそ、AIは高速に開発できる
• 消えるOSS:
  • 上記の条件を満たさない個人開発の小規模ツール的なOSS
  • これらが消えても誰も困らない

MEMO:

• 同意である

関連:

• OSSがなくなってしまう

(2026/07/20)

「間に合いませんでした」をスプリント最終日に言わないために

• 「間に合いませんでした」をスプリント最終日に言わないために - Cybozu Inside Out | サイボウズエンジニアのブログ

要約:

■ 1. 再計画の概念

• スクラムでは、スプリントプランニングで立てた計画をもとにスプリントを進める
• 計画はその時点での仮説に過ぎず、実際の作業では想定外の複雑さ・工数が発生する
• スプリント中に計画の見直し（再計画）を行うことが重要
• 本記事が扱う再計画とは、スプリントプランニングのやり直しではなく、PBIの作業レベルでの小さな見直し
• 計画と現実のズレを単なる遅れではなく、スプリントゴール達成のリスク兆候として捉える

■ 2. 持ち越しが止まらない原因

• スプリント最終日まで「完成しない」と気づけないことが問題
• 途中で薄々気づいていても計画を見直さず次スプリントへ持ち越してしまう
• 持ち越しが続くとフィードバックが遅れ、価値の提供が滞り、チームが学ぶべきことも後ろ倒しになる
• 繰り返す中でチームが計画と現実のズレに対して鈍感になっていく

■ 3. デイリースクラムの課題

• 再計画が不十分なチームでは、デイリースクラムが「作業報告」で終わる傾向がある
• 作業が「進んでいる」ことは分かっても、完成に「近づいている」かは見えない
• 問いかけによって担当者自身も気づいていなかったズレが表面化する例:
  • 「完成までの見通しはどんな感じですか？」という問いかけで、実装が当初より増えている事実が明らかになる
• デイリースクラムは報告を聞く受け身の場ではなく、チーム全員が計画と現実のズレを見つけに行く場

■ 4. 再計画が起きるチームの状態をつくる4つの観点

• 「再計画は必要なもの」という共通認識をつくる:
  • 前提がないと問いかけが「監視」や「プレッシャー」に感じられる
  • 「問題は人ではなくプロセスにある」という考え方が安心して問いかけられる空気の土台になる
  • アプローチ:
    • 考え方を言葉にして伝える（スクラムマスターなどが中心となって明示的に共有）
    • チーム自身の経験（レトロスペクティブ等）から気づいてもらう
  • 一度伝えて終わりにせず、繰り返し確かめることで共通認識を根づかせる
• 作業の透明性を高める:
  • カンバンのステータスだけではタスクの詳細な状況（開始時期や完成見込み）は見えない
  • 透明性を高める手立て:
    • チャットでの状況共有（Slackなどで取り組み内容・詰まっていること・想定外を声に出す）
    • タイムライン上での可視化（日単位の時間軸に作業を並べ、予定と実際を比較する）
  • 透明性によって見えてくるズレの具体例:
    • 「あと少しで終わる」が何日も続いている
    • 作業は進んでいるように見えるが完成に近づいている感じがしない
    • 調査や実装の出口が曖昧なまま進んでいる
    • レビューやテスト、プロダクトオーナーへの確認が後ろに残っているのに完成に近いものとして扱われている
    • 状況が担当者の頭の中に閉じていて周りが判断できない
    • 想定外の作業が増えているのにスプリントの計画が見直されていない
• 気づいた違和感を会話にする:
  • 違和感ははっきりした問題になる前は個人の感覚のまま流れやすい
  • 具体的な問いかけの例:
    • 完成までの見通しはどんな感じか
    • どこが一番読めない感じか
    • 「あと少し」はどのあたりまで来ているか
    • このまま進めてゴールは達成できそうか
  • これらの問いは管理のためではなく、担当者の状況をチームで可視化するためのもの
• 気づいたあとに動ける選択肢を持っておく:
  • ズレに気づいても進め方を変えなければ再計画にならない
  • 打ち手の例:
    • 進め方を変える（ソロからペア・モブに切り替える）
    • 専門家を頼る（他チームや社内のエキスパートにヘルプを出す）
    • 優先度を変える（不確実な部分を先に着手する）
    • スコープを調整する（POと会話し、PBIを分割したり届ける範囲を縮小したりする）
    • 実現手段を変える（重い作り方から同じ価値をより速く実現できる別の手段へ）
  • 最初の計画に固執しないことが大切

■ 5. デイリースクラムを待たない

• デイリースクラムは24時間に一度の最後のセーフティネットに過ぎない
• デイリースクラムで「時間がかかりそう」と分かるのは本当は遅すぎる
• 計画とのズレが生じたその瞬間に、その場で適応するのが理想

■ 6. 再計画に対する認識の転換

• 再計画は計画の失敗のサインではなく、チームが現実を見て学習し、より良い進め方を選び直している証拠
• 大切なのは計画通りに見せることではなく、スプリントゴールに向けて今の状況に合った最善の進め方をチームで選び続けること
• 早く気づくほど選べる打ち手が増え、最終日まで気づけなければ打ち手はほとんど残らない
• 再計画はスプリントゴールに近づくためにチームが日々行うべき活動

(2026/07/20)

ゴールまで自走するだけではない？——ループエンジニアリングの本質はどこにあるのか

• ゴールまで自走するだけではない？——ループエンジニアリングの本質はどこにあるのか

(2026/07/20)

Figmaと実装の乖離は怠慢ではなく、構造の欠陥である

• Figmaと実装の乖離は怠慢ではなく、構造の欠陥である｜Matz

要約:

■ 1. 主張と結論

• デザインと実装の乖離は、運用の改善や頑張りでは解決できない
• Figmaとコードはパラダイムが違うため、どちらか一方を「正」とした時点で乖離が構造的に発生する
• 解決策はFigmaにもコードにも正を置かず、ツール中立なComponent Spec（コンポーネント仕様書）を「正」に置くこと
• FigmaとコードはSpecから生成される「派生物」と捉えることで、乖離は「頑張って同期するもの」から「検出して再生成で消すもの」に変わる

■ 2. AIがデザインを生成する時代の到来

• Figma Make、Pencil、Claude Design、Figma AgentなどAIによるデザイン生成ツールが相次いで登場した
• 制約なしの生成指示では「プロトタイプ止まり」の出力しか得られない
• 実プロダクトとして通用するには、サービスのデザインルール（使ってよい色・コンポーネント・余白の体系）をAIに明示する必要がある
• この「ルールの集合体」こそデザインシステムであり、AIへの入力そのものになった今、その重要性が一段上がった

■ 3. 従来のデザインシステムの限界

• これまでのデザインシステムはFigmaにトークンとコンポーネントライブラリがあれば十分とされてきた
• 以下の情報は厳密に文書化されず、デザイナーの経験・勘・コミュニケーションで補完されてきた:
  • コンポーネントをどこで使い、どこで使ってはいけないか
  • 似たコンポーネントとの役割の違い
• 人間のチームは暗黙知で運用できるが、AIには書かれていないルールは存在しないルールと同じ
• AIリーダブル（AIが読める）であることが新しい要件として加わった

■ 4. 乖離が構造的に発生するメカニズム

• デザインをプロダクトにする際、エンジニアがFigmaを見てコードに手作業で再現する「翻訳」の工程が発生する
• 翻訳過程で抜け落ちた情報が負債となり、乖離の谷が深まっていく:
  • 実装の都合で変えた角丸
  • Figmaに存在しない中間状態
  • 誰も文書化しなかった例外
• AIはデザイン生成だけでなくコード生成も可能になり、翻訳工程をAIに委ねられる段階になった

■ 5. Figmaとコードのパラダイムの違い

• Figmaのコンポーネントと実装（React等）のコンポーネントは、同じ見た目を作る場合も表現の仕組みがまったく異なる
• ボタンの5状態（default / hover / active / focus / disabled）を例にすると:
  • Figma: 「state」プロパティで5状態をバリアントとして平らに並べる
  • 実装: disabledはprops、hover/focusはCSSの擬似クラス/イベント、押下中はuseStateと、複数の仕組みに分散する
• 片方のパラダイムをもう片方に強制すると都合の悪い部分が抜け落ちる:
  • Figmaを正にすると: 実装が「バリアント」という実装に存在しない概念からコードを推測することになる
  • コードを正にすると: Figmaが「props・擬似クラス・useStateの使い分け」を1軸に無理やり潰すことになる
• この抜け落ちこそが乖離の正体

■ 6. Component Specとは

• どちらのパラダイムにも属さない場所に「正」を置く文書
• 「このコンポーネントは何であり、どんな状態を持ち、どう振る舞い、何をしてはいけないか」をツール中立な言葉で記述する
• Specが正であることの3つの帰結:
  • 乖離の「検出」が可能になる: FigmaとコードがズレたらSpecを見ればどちらが間違いか判定できる
  • 派生物は作り直せる: AIがデザインもコードも生成できる今、Specから両方を生成し直すコストが急速に下がっている
  • ツールに寿命が来ても正は残る: FigmaやReactが別ツールに替わっても失うのは派生物だけ
• AIが読めるのはキャンバスではなく構造化されたSpecそのもの。AIリーダブルなデザインシステムの核はSpecにある

■ 7. Component Specの構成と内容

• YAML部分（機械が読む）とドキュメント部分（人間とAIが読む）の2層構成
• Specに書く内容:
  • 事実: 「このコンポーネントは6つの状態を持つ」「isLoading時は横幅を縮めない」など
  • 判断基準: いつ使い・いつ使わないか、似たコンポーネントとの役割の違いなど
  • AIへの指示: どう考えて選択すべきかをAIに直接語りかけるセクション
• Specに書かない内容:
  • パラダイム依存の情報（Figmaでバリアントとして並べるか、実装でprops/CSS/useStateに振り分けるかなど）
  • パラダイム依存の情報を持ち込まないことが、Specをツール中立な「正」として保つための最重要規律
• 変更履歴も含み、乖離が発生した際の裁定者として機能する

■ 8. Code Connectとの関係

• Code Connectへの評価: 肯定的であり、使えるなら使うべき機能
• Code ConnectとComponent Specの役割の違い:
  • Code Connect: Figmaとコードという派生物同士をつなぐ「配管」として翻訳をスムーズにする
  • Component Spec: 両方の派生物が従うべき「事実」として、ズレたときの裁定者となる
• Code Connectが答えられないこと: 角丸8pxのFigmaと角丸4pxの実装がマッピングされていても、どちらを直すべきかは判定できない
• Code Connectのマッピングを書く際の判断根拠を文書化したものがSpecに相当する
• 競合ではなく補完関係。将来的にはSpecからCode Connectのマッピングを生成することも可能になる
• Code Connectのみで十分なケース: Dev Modeで正しいコード片が見られれば十分な段階のチーム

■ 9. 注意点

• Specの維持コスト:
  • 部品作成に加えて文書を書いて維持する工程が発生する
  • 中途半端なSpecはないより悪く、FigmaとコードとSpecの「3者のズレ」という最悪の状態を生む
  • 「Specを更新しない変更は存在しない」を守り切ることが前提条件
• Specが向かない現場:
  • 小規模チームの探索期
  • 使い捨ての案件
  • Specは参照される回数が多いほど効いてくる投資

■ 10. まとめ

• AIがデザインを生成する時代になり、デザインシステムは「AIへの入力」になった
• AIリーダブルであることが新しい要件であり、暗黙のルールはAIには存在しないルールと同じ
• Figmaとコードはパラダイムが違うため、どちらを正にしても乖離が構造的に発生する
• 正はツール中立なComponent Specに置き、Figmaとコードは派生物と捉える
• 乖離は「議論して直すもの」から「検出して再生成で消すもの」に変わる

Appendix:

name: Button
description: ユーザーのアクションをトリガーするコンポーネント
status: stable

props:
 variant:
   type: enum
   values: [solid, outlined, ghost]
   default: solid
   description: 見た目のスタイル(塗り / 枠線 / 透過)
 tone:
   type: enum
   values: [brand, neutral, danger, success, info, warning]
   default: brand
   description: 色味・意味のトーン
 size:
   type: enum
   values: [sm, md, lg]
   default: md
   description: ボタンのサイズ
 shape:
   type: enum
   values: [rounded, pill]
   default: rounded
   description: 角の形(rounded=通常の角丸 / pill=完全な丸み)
 isDisabled:
   type: boolean
   default: false
   description: 無効状態。クリック・キー操作を受け付けない
 isLoading:
   type: boolean
   default: false
   description: 処理中の状態。操作を受け付けず、スピナーと専用ラベルを表示。
     横幅は元のラベルと loadingLabel の広い方に合わせる(縮めない)
 isFullWidth:
   type: boolean
   default: false
   description: 親要素の幅いっぱいに広がる
 type:
   type: enum
   values: [button, submit, reset]
   default: button
   description: HTML の button type 属性に対応
   platforms: [web]
   visual: false
 loadingLabel:
   type: string
   default: 処理中
   description: ローディング中(isLoading)に表示する専用ラベル
 startIcon:
   type: element
   default: null
   part: icon
   description: ラベルの前に置くアイコン(省略可)
 endIcon:
   type: element
   default: null
   part: icon
   description: ラベルの後に置くアイコン(省略可)

states: [default, hover, pressed, focused, disabled, loading]

style:
 variant:
   solid:
     brand:
       background: color.brand.500
       foreground: color.white
       hover:
         background: color.brand.700
       pressed:
         background: color.brand.800
   # …(outlined / ghost、他のtoneも同形式で続く)

related:
 - name: Link
   reason: ページ移動、外部リンク
 - name: IconButton
   reason: アイコンだけのアクション

• 人間が読むMarkdownセクション

## いつ使うか

ユーザーが自分から何かを実行する場面で使う。フォームの送信、保存、削除の確定、ダイアログのアクション、画面内の機能の実行など。「押すと何かが起きる」操作の起点には、Button を使う。

## いつ使わないか

- ページ移動・外部リンクが目的のとき → `Link` を使う。Button は移動ではなく、動作の実行に使う
- アイコンだけで、ラベルがないアクション → `IconButton` を使う
- オン / オフの2つの状態を切り替えるとき → `Switch` か `Toggle` を使う。Button は状態を持たない
- 複数の Button を、意味のあるまとまりとして並べるとき → `ButtonGroup` を使う

## variant の使い分け

`variant` は「色をどう塗るか」の軸。

- `solid` は背景を塗りつぶす、最も強い見た目。画面の中で一番注目させたいアクションに使う。
- `outlined` は枠線だけ。`solid` を引き立てる、2番目のアクションに使う。
- `ghost` は枠線も背景もない、最も控えめな見た目。情報が密集した場所や、補助的なアクションに使う。

見た目の強さは solid > outlined > ghost。

## tone の使い分け

`tone` は「どの意味の色か」の軸で、`variant` とは別。

- `brand` は主要なアクション。
- `danger` は削除や取り消しなど、元に戻せない・壊す系のアクション。
- `success` / `info` / `warning` は、文脈を強調したいときに使う。ただし使いすぎると意味が薄れるので、基本は `brand` か `neutral` に寄せる。
- `neutral` は、意味の色を付けたくない中立的なアクションに使う。

`tone` は意味を表す。「赤くしたい」という見た目の理由で `danger` を選んではいけない。

## AI エージェントへのガイダンス

Button を選ぶときは、まず「押すと何かが起きるか」を確認する。移動が目的なら Link、状態の切り替えなら Switch / Toggle に倒す。次に `variant` と `tone` を別々に決める。`variant` は画面の中での重要度で選ぶ(主要なら solid、補助なら outlined、控えめなら ghost)。`tone` は意味で選ぶ(普通は brand、壊す系の操作だけ danger、中立は neutral)。1つの領域に solid は1つだけにする。size は領域の中でそろえる。壊す系でないアクションに danger を使わないこと。

(2026/07/20)

開発が速く安くなった後の話　AI時代のソフトウェアエンジニアリング組織論

• 開発が速く安くなった後の話　AI時代のソフトウェアエンジニアリング組織論 #devsumi - Speaker Deck

要約:

■ 1. 登壇者と背景

• 登壇者: Indeed Recruit Technologies VP 黒田樹（DEVELOPERS SUMMIT 2026 SUMMER）
• Indeed PLUSを提供するリクルートのHR Tech SBU所属
• 2025年6月にClaude Code、2025年9月にCodexを部署全体のエンジニアへ配布
• 使い方を指定せず現場ごとに自然発生的な活用を観察し、その結果と組織変容が本講演の内容

■ 2. 中心テーマ：ボトルネックはどこへ移るか

• AIを巡る議論は「仕事が消えるか」「どのモデルが賢いか」に集中しやすい
• 本講演の問いは第三の視点：「ボトルネックはどこへ移るか」
• 実装がAIで速くなっても、開発全体が同倍率で速くなった現場は存在しなかった
• 要求・要件・テスト・運用のいずれかが次のボトルネックになる

■ 3. 歴史が示す技術革新と雇用の構造

• 産業革命:
  • 蒸気機関から工場動力への置換に約1世紀を要した
  • 変化は急激ではなく、労働者数は減少せず増加した
  • 機械化で製品が安くなり需要が増大したため（ジェボンズのパラドックス）
  • 英国の石炭消費は1900年までに3倍に増加
• 自動化と雇用の基本構造（Acemoglu & Restrepo）:
  • 代替効果: 既存タスクを機械が置換
  • 復権効果: 人間に比較優位のある新タスクが生まれる
  • 復権は自動では起きない——技術に合わせて仕事を組み替えた側にのみ来る
• 電気化の教訓:
  • 蒸気機関をモーターに置換しただけの工場では生産性は約30年上がらなかった
  • 各機械にモーターを付け作業順序を組み替えた工場でのみ効果が出た
• IT史における同構造の繰り返し:
  • 1960年代のメインフレームから2010年代クラウドまで、技術革新のたびに職能が置換・創出
  • 抽象化が起きると職能は「基盤を支えるコア側（少数・深化）」と「抽象の上に立つスケール側（多数・拡大）」に二分される
  • 日本のITエンジニアは1985年の約32万人から2024年の約144万人へ4.5倍増（ジェボンズのパラドックスの再現）
• AI時代の含意:
  • 今回AIが抽象化しつつあるのはコーディングを含む「実装とその周辺（設計案・テスト・調査・移行・レビュー補助）」
  • 歴史構造に従えば史上最大級の職能分化と再配置が起きる

■ 4. 開発の経済性の変化

• AIにより開発コスト（Investment）が低下し、ROI成立境界が下がる
• 従来はROIが合わなかった部署単位・顧客単位・業務単位の個別開発が採算に乗り始める
• 直面するのは「作れない」ではなく「作る対象が増え続ける」状況
• ただし下がるのは初期開発のコストのみ:
  • 検証・統合・運用・保守・障害対応・セキュリティ・責任といった維持コストは自然には下がらない
  • 開発量が増えるほど維持保守の負荷は増大する

■ 5. 社内実証：6事例の観察

• 成否の差は「モデルの性能」ではなく「コンテキストの構造」によって生じた
• 成否を左右した6観点:
  • 必要コンテキスト量
  • 現実世界依存性
  • 影響範囲の閉じやすさ
  • 決定論的検証のしやすさ
  • チームの経験量
  • 自動化との相性
• 事例1 大規模レガシーシステムA（成功）:
  • レガシー本体に触れずJSPをAPIと捉え、includeされるJavaScript側で業務要件を実装
  • 影響範囲が閉じ、AIに与えるコンテキストが小さくて済んだ
  • 経験者が暗黙知で文脈を補い、AIの推論を必要な範囲に絞り込んだ
• 事例2 Airワーク採用管理（成功）:
  • 要件明確化から実装・テスト生成・PRレビュー・振り返りまでをSkillsとカスタムエージェントのパイプラインに組み暗黙知を外部化
  • アーキテクチャがUI/BFF/APIをリクエスト単位で独立させた疎結合構成であり、変更一件に必要なコンテキストが小さかった
  • 疎結合はAI活用を見込んだ設計ではなく、ベトナムオフショア開発の歴史的経緯によるものだった
• 事例3 複数求人サイトのSEO（成功）:
  • GoogleガイドラインやSearch Consoleなどの一般論でAIの推論を拘束でき、改修もフロントに閉じた
  • 起案から実装まで0.5日、3カ月で63施策を実装
  • 最大の変化は「順序の逆転」：会議で絞ってから作るのをやめ、全部作ってから会議で間引く方式に転換
  • 制約理論の「制約に他工程を従属させる」発想をプロセスに適用した形
• 事例4 リクナビNEXTバッチ（失敗）:
  • 性能問題のあるバッチ処理改善にAIを使おうとして苦戦し、最終的にテックリードが自力で解決
  • 再実行性・処理時間・整合性・負荷制約・データ分布といったコード外の現実制約が支配的だった
  • コードを全部読ませてもAIには本番の物理制約が見えない
  • 偽陽性（コンパイルも単体テストも通るのに本番で破綻するコード）が生じ、人間が書いたように見えるため批判的思考が止まりやすい
• 事例5 AirワークEOSL対応（試行錯誤から成功）:
  • ライブラリ・言語バージョンアップ用の保全テストを大量生成する目的
  • 初期のラルフループ（while :; do cat PROMPT.md | claude-code ; done）では品質が収束せず数日で数百万円のトークン代を消費
  • 原因: 要件・観点・コード生成・評価が一つの生成に混在し、探索空間が大きすぎた
  • 成功した形:
    • AIの役割を観点出しとYAMLテスト仕様書生成に限定
    • YAMLからのテストコード生成は決定論的プログラムが実行
    • 評価はテスト実行とカバレッジ計測で決定論的に実施
    • 不足した観点のみをAIに追加生成させて次周回へ
  • 確率論ベースの生成に対し、品質責任を決定論的評価系に寄せる「ハーネスエンジニアリング」形式に移行
• 事例6 AI-OPS（成功）:
  • アラート起点の障害調査（ログ・ソースコード・運用知識・JIRA横断）をAIに委ねた
  • 一次調査からJIRAチケット起票まで一気通貫で自動処理
  • AIは「受け止める側の仕事」にも有効

■ 6. 観察の一般化：コンテキスト構造の問題

• AI開発の本質は「理想的出力に必要なコンテキスト」と「実際に与えられるコンテキスト」の差を管理するゲーム
• 差が大きいほど推論の自由度が増し、偽陽性とハルシネーションが増える
• 操作できるレバーは実質2つ:
  • 必要なコンテキストを減らす（アーキテクチャで強い境界を設ける・問題を分割する）
  • 与えるコンテキストを増やす（skills・sub-agents・契約・テンプレートで供給）
• LLMの使い方は2つの流派に収束:
  • 協働型（コパイロット型）: 経験者が暗黙知を内側に持ち、対話でAIの推論を制御（レガシーAが該当）
  • 委託型（オーケストレーター型）: 暗黙知を仕組みとして外部化し再現性を作る（Airワークが該当）
  • 優劣なし——チームの経験量と現場特性で使い分ける
• アーキテクチャは推論を小さくする装置になる:
  • 境界が明確で契約が強く影響範囲が閉じた構造は人間にもAIにも読みやすい
  • ただし現在のAI性能を前提にコンテキストウィンドウへ収めることを頑張りすぎないほうがよい（将来の性能向上により過剰分割が損失になりうる）
• 生成は確率的でよい、受け止め方は決定論で:
  • 受け入れ条件のコード化・契約テスト・観測設計・段階リリース・ロールバックで品質責任を決定論的機構に置く
  • 「AIに正しさを期待するのではなく、間違っても壊れにくい系を先に設計する」

■ 7. 人間と組織の変容

• 人間の仕事は全工程に薄く残る——「問いを立てる・判断する・境界を引く・品質責任を持つ・異常時に介入する」
• 生成コストが下がるほどコミュニケーションコストが相対的に高くなる:
  • 8人の相互やり取りは56本のパスを生む（人数の二乗で増加）
  • 工程間の受け渡し（ハンドオフ）コストはAIでは縮まらず次のボトルネックになる
• コミュニケーションコスト対処の2系統:
  • モノ的アプローチ: アーキテクチャで境界を切りパスを断つ
  • ヒト的アプローチ: 一人が担う範囲を広げ人数Nを減らす
• 「フルフル」（フルスタック × フルプロセス）の採用:
  • フルスタック: 一人がBE・FE・インフラを横断してカバー
  • フルプロセス: 一人が要件定義から実装・テストまで複数工程を担当
  • 一人の担当範囲が広がるほど工程間の受け渡しが減少し速度が上がる
• 組織の階層を浅くする:
  • 深い階層は事前調整で不確実性を下げる代わりに個人のストレッチ幅を制約する
  • フラットな座組は事前調整を最小にしてリアルタイム調整を最大にする
  • メンバーが通常より広い責務と判断範囲を担う形で運営した

■ 8. KTLO（Keep The Light On）への対応

• 作るコストは下がる、動かし続けるコストは自然には下がらない
• ROI成立境界の低下で小さなシステムが増えるほど維持保守対象のロングテールが伸びる
• システム同士がAPIとデータで絡み合い「依存関係のスパゲッティ化」が前例のない規模で起きる
• 維持保守対象の爆発を人員の線形増加で受けるのは限界があり、AIレバレッジが必要
• KTLOセンターとして受け皿を集約:
  • まず70リポジトリ規模のマイクロサービス群から着手
  • 担当業務: 24/365のトラブル対応・各種パッチ当て・EOSL対応・バージョン管理・問い合わせ対応
  • AI-OPSをフル活用するベトナムオフショア体制で検証中
• 市場側の出口としてFDE（Forward Deployed Engineer）の台頭:
  • 旧来の「1パッケージをN社に売る」モデルは全社共通システムへの我慢を前提としていた
  • 個別実装がROIに乗る時代では、顧客現場で業務文脈を理解しその場で実装する職能が必要になる
  • 実態は「フルフル人材が社外の現場に立つ形」
  • 前線が個別最適を作り、KTLOセンターが支えることで量産が事業として回る

■ 9. 結論

• 結論: ボトルネックに合わせた組み替え（制約理論の「制約に他工程を従属させる」の適用）
• プロセス: 判断に実装の順序を従属（SEOで「絞ってから作る」から「全部作ってから間引く」へ）
• 生成管理: 確率的生成を決定論的検証ループへ従属（AirワークEOSL対応）
• 組織: 判断の速さに組織の形を従属（階層を浅く・フルフル化）
• アーキテクチャ: 検証のしやすさに推論の幅を従属（境界と契約で推論を局所化）
• 制約は消えずに移動する——AIでも産業革命・電気化と同じ構造が繰り返されるという見立てのもと、速くなった実装をそのまま最大化せず、ボトルネックの工程に合わせて組織・プロセス・アーキテクチャを組み替えることから始めている

(2026/07/20)

AIエージェントのためのDocker Sandboxes実践入門

• AIエージェントのためのDocker Sandboxes実践入門 #Security - Qiita

MEMO:

• Vagrantで仮想マシンを立ち上げていた時代に戻るのか？

(2026/07/19)

有名なWebフレームワークのエラーハンドリングの仕様を調査し、自社用の開発テンプレートハーネスに反映してみた

• 有名なWebフレームワークのエラーハンドリングの仕様を調査し、自社用の開発テンプレートハーネスに反映してみた | DevelopersIO

(2026/07/19)

より小さなソフトウェアエンジニアリングチームを、2029年までに60％の組織が本格展開するとの予測、ガートナー

• より小さなソフトウェアエンジニアリングチームを、2029年までに60％の組織が本格展開するとの予測、ガートナー － Publickey

(2026/07/18)

OSSがなくなってしまう

• OSSがなくなってしまう - 駒形電産

要約:

■ 1. AIによるOSSの不可視化

• これまでは利用者自身がOSSを探し、READMEを読み、作者やプロジェクトを理解した上で利用していた
• Vibe Coding（AIによるコード生成）によって、AIが必要なソフトウェアを自動選択・組み合わせ・改変するようになり、利用者はOSSの名称すら知る必要がなくなった
• OSSが引き続き利用されても、作者の存在や思想、貢献の価値が不可視化される
• 結果として、作者への感謝・評価・支援・貢献が減少していく

■ 2. オーダーメイドソフトウェアによるOSSの代替

• 生成AIにより、個人の用途や好みに合ったソフトウェアを容易に作成できるようになった
• 既存OSSを探して習得し不満足な部分を許容するより、最初から専用のものを作る方が効率的になりつつある
• 多くの人が同一のソフトウェアを共有する必要性が薄れ、OSSの存在価値が低下する
• ソフトウェアの総量は増加する一方、OSSは減少するという逆転現象が生じる

■ 3. 社会的問題としてのOSS衰退

• OSSの衰退は個人の嗜好の問題にとどまらず、社会全体に悪影響を及ぼす
• 共有地の悲劇（コモンズの悲劇）との対比:
  • 個人にとって合理的な選択（AI製オーダーメイドソフトの利用）でも、社会全体では以下の損失が生じる
    • 改善・バグ修正・設計知見の共有が行われなくなる
    • 社会全体で同一の機能を繰り返し実装することになる
    • 品質を共同検証できる共通基盤が育たなくなる
    • ソフトウェア技術の蓄積が弱体化する
  • 個人の合理的選択の積み重ねが、共有資産を失わせる構造的問題

■ 4. 対策の方向性

• 利用者の善意のみに依存するのではなく、共有資産を守る制度的仕組みが必要
• 漁業における漁業組合・政府規制との類比:
  • 資源から利益を得る者が維持にも責任を持つ構造
• OSSにおける具体的な対策案:
  • AIや企業がOSSから得た利益の一部をOSS維持に還元する仕組みの構築
  • AIがどのOSSを利用したかを可視化する透明性の確保
  • 企業・政府・業界団体による共有資産としてのOSS支援基金の設立
  • AIが生み出した改善を元のOSSへ還元しやすくする仕組みや標準の整備
• OSSとの差異の認識:
  • 魚と異なり、ソフトウェアはコピーしても減少しない
  • 失われていくのは作者の創作意欲、改善共有の習慣、コミュニティの活力
• AI時代のOSSにも、漁業組合に類する共有資産を共同で守る新たな制度や運動が必要

MEMO:

• 無くなりはしないと思うが
• OSやミドルウェアの領域になると維持コストが高いのでOSSにした方が寿命が延びる
• 確かにちょっとしたツールはわざわざOSSにしなくなるかもしれないが、それはAI以前でもそうだったし、それで誰も困っていない

(2026/07/18)

AI駆動開発時代の品質保証

• AI駆動開発時代の品質保証 - Speaker Deck

(2026/07/18)

AIに「レビューして」はもう古い？「敵対的検証」のすすめ

• AIに「レビューして」はもう古い？「敵対的検証」のすすめ

要約:

■ 1. 「レビューして」と「敵対的検証して」の違い

• 「レビューして」は改善点のリストを返す
• 「敵対的検証して」は「課題がある」前提で反証を試み、指摘に判定と根拠を付けて返す
• 判定と根拠が付くことで、受け手が採否を判断しやすくなる

■ 2. 敵対的検証の思想的背景

• レッドチーム（red teaming）:
  • 1960年代の米軍ウォーゲームで敵役を演じたチームに由来
  • サイバーセキュリティやAI safetyの分野へ広がり、AnthropicもAIモデルを攻撃的にテストする手法として採用
• 悪魔の代弁者（devil's advocate）:
  • カトリック教会の列聖審査に1587年に制度化された役職
  • 聖人候補にあえて不利な事実を突きつけ、安易な認定を防ぐ
• 反証主義:
  • 科学哲学者カール・ポパーの論：仮説は厳しい反証の試みに耐えることで暫定的に信頼される
• 共通構造:
  • 「わざと反対側から叩くことで結論を強くする」という発想

■ 3. Claude Code への組み込み

• Claude Codeの以下の組み込みコマンドには敵対的検証が利用されている
  • /deep-research
  • /code-review
• /deep-research の構造:
  • 複数角度でWeb検索を並列実行しランク付け
  • 上位の主張に対して3体の検証エージェントが反証を試み投票
  • 3分の2が反証した主張はレポートから除外
  • 内部プロンプト：「Be SKEPTICAL. Try to REFUTE this claim.」
• /code-review の構造:
  • 複数エージェントが並列でバグを検出
  • 指摘ごとに別のエージェントが再検証し、確信度の低い指摘を除外
  • 内部プロンプト：「確信が持てないissueはフラグするな。偽陽性は信頼を損なう」
• Anthropic公式ブログによる定義:
  • 「Adversarial verification: エージェントに作業させたら、その出力を基準に照らして敵対的に検証する別のエージェントを走らせる」
  • 公式ベストプラクティスにも「Add an adversarial review step」という専用セクションが存在

■ 4. 使い方

• 成果物が出た場面で「敵対的検証して」と一言頼むだけ
• 対象を指定する場合：「この設計案を敵対的検証して」
• サブエージェントを明示する場合：「サブエージェントを立てて敵対的に検証して」
• 検証は別のfresh contextを持つサブエージェント側で行われるため、同じセッション内で頼んでよい

■ 5. 「レビューして」より効く2つの理由

• 敵対的な構え:
  • 「課題がある」前提で反証を試みる役割を与えるため、指摘に判定と根拠が付く
• fresh context:
  • サブエージェントは成果物を作った会話の文脈を引き継がない
  • 「これまでの流れ」に迎合できないため、独立した評価が可能
• 2つは掛け算:
  • fresh contextでも「レビューして」では課題前提の検討にならない
  • 同じ会話内での「反証して」は流れに迎合する可能性がある
  • 「敵対的検証して」の一言が両方を同時に引き出す

■ 6. Claude Code以外での使い方と要件

• 敵対的検証を成立させる4要件:
  • 独立性：成果物を作った文脈と切り離したまっさらな目に検証させる
  • 反証の役割づけ：懐疑者の役割を与える
  • 接地（グラウンディング）：事実の主張は一次情報（検索・原典）に当たらせる
  • 判断できる出力：指摘に深刻度と根拠を付けさせ人間が採否を決められる形にする
• 単一チャットツールでの手順（3ステップ）:
  • 新規セッションを開く（成果物を作った会話は使わない）
  • 成果物だけを貼る（経緯や意図の説明は貼らない）
  • 敵対的検証プロンプト雛形を貼る
• プロンプト雛形の要点:
  • 独立した懐疑的なレビュアー（skeptic）として反証に徹するよう指定
  • 良い点は書かず、成立しない可能性のある箇所だけを挙げる
  • 事実の主張はWeb検索や一次情報で裏を取り、確認できなければ「未検証」と明記
  • 出力形式：指摘・深刻度・根拠・確度の4項目を付ける
  • 最後に「反証を試みたが壊せなかった点」を記載

■ 7. 注意点と限界

• 過剰指摘:
  • 敵対的レビュアーは健全な成果物にも指摘を出す
  • 公式ベストプラクティスの警告：「全指摘を追いかけると過剰設計に行き着く」
• 手抜き判定:
  • 検証エージェントの最大の失敗モードは「ろくに検証せず合格と判定する手抜き」（公式ブログ）
  • 「大丈夫」と言われても自分で確認する姿勢が必要
• コスト:
  • マルチエージェント構成はシングルエージェントの3〜10倍のトークンを消費（Anthropic社内テスト）
  • やり直しコストが高い成果物に絞って使うのが現実的
• 同一モデルの盲点:
  • 検証する側とされる側が同じモデルなら盲点も共有する
  • 回避策1：「一次情報に当たって」と接地を指示する
  • 回避策2：重要な成果物では別のモデルに検証させる（クロスモデル検証）
• 共通する結論:
  • AIの指摘は正解ではない
  • 受ける・弱めて受ける・却下する採否判断が人間の仕事

■ 8. 記事自体への敵対的検証の適用例

• 執筆前に切り口・構成・リサーチ結果に対して計8体のスケプティックによる検証を実施
• 主な指摘と採否判断:
  • 「一言で発動はn=1で環境依存の可能性」→ 主張を「私の環境ではこうなった」に留め環境注記を付けた（弱めて受けた）
  • 「棄却された叩き台を成功譚として語るな」→ 「採否を決めるのは人間」を記事の柱に昇格させた（受けた）
  • 「答えの一言が中盤まで出てこない」→ 冒頭に一言を置きつつ概念から入る骨格は維持した（一部受けた）
  • 「一言でやってくれるという汎用主張はやめろ」→ 注記で誠実さを担保する道を選んだ（却下した）
• 事実関係の裏取りで計7件の危うい記述を事前に排除

(2026/07/18)

Claude Codeのスキル設計で効く4つのポイント —— 「AIへの仕事の任せ方」を意識した設計

• Claude Codeのスキル設計で効く4つのポイント —— 「AIへの仕事の任せ方」を意識した設計 - RAKUS Developers Blog | ラクス エンジニアブログ

要約:

■ 1. 概要

• スキル設計の本質は「AIへの仕事の任せ方の設計」である
• 「とりあえず動くスキル」と「安定して業務に組み込めるスキル」は別物
• 以下の4つのポイントを押さえることで、誰が実行しても期待した品質のアウトプットが安定して返りやすくなる
  • 依頼内容を明確にする
  • 誰に、どの単位で任せるかを決める
  • 品質確認の仕組みを組み込む
  • 仕事ぶりを評価して、次の任せ方に活かす

■ 2. ポイント1: 依頼内容を明確にする

• アウトプットの定義:
  • フォーマット、粒度、含めるべき要素、含めてはいけない要素を具体化する
  • AIが判断してよい範囲（責任の境界）を明確にする
  • 意思決定（修正の採用可否、本番反映など）は人間が行う範囲として残す
• インプットの定義:
  • アウトプット生成に必要な情報をすべて列挙する
  • 業務知識やドメイン用語の補足、参照すべき既存ドキュメントやコード、過去事例と反例、守るべき制約やルールが含まれる
  • 「人間に同じ仕事を頼むなら何を渡すか？」という問いで過不足を点検する
• 失敗パターンの兆候:
  • AIが不足情報を推測で補完し始めた場合 → インプット定義の見直しが必要
  • 実行ごとにアウトプットの構造や粒度が変わる場合 → アウトプット定義の曖昧さが原因の可能性がある

■ 3. ポイント2: 誰に、どの単位で任せるかを決める

• コンテキストウィンドウは有限であるため、情報量を見積もったうえで分担を設計する
• 判断軸は4つ:
  • スクリプトへの切り出し:
    • 日付計算、ファイルの存在チェック、フォーマット変換など決定的に実行できる処理はスクリプトに切り出す
    • 曖昧さが入り込まないため結果が安定する
  • 並列化（サブエージェント分業）:
    • 情報量が多い場合や独立したサブタスクが複数ある場合はサブエージェントに分業させる
    • 委譲プロンプトには「目的」「出力形式」「使用するツールと情報源の指針」「タスクの境界」の4要素を含める
    • サブエージェントは毎回まっさらなコンテキストで起動するため、スキルの引き継ぎには skillsフィールドでの事前ロードか、委譲プロンプトへの明示が必要
  • コンテキストの分割単位:
    • 1回の呼び出しに入るインプットサイズを試算し、必要に応じて意味のある単位で分割する
    • 分割の境界をサブエージェントの責任範囲と一致させると設計がシンプルになる
    • ページ数ではなく機能単位で切ることで各サブエージェントがレビューを自身の担当範囲内で完結できる
  • モデルの選択:
    • 機械的な抽出や整形 → 軽量モデル（Haikuなど）
    • 通常の設計や実装 → 標準モデル（Sonnetなど）
    • 複雑な判断、横断的な統合 → 高性能モデル（Opusなど）
    • 思い込みで固定せず、実際に複数モデルで試して決めることが確実

■ 4. ポイント3: 品質確認の仕組みを組み込む

• 一発生成では品質にばらつきが生まれるため、生成した成果物を確認・修正する仕組みをスキルに組み込む
• レビュー方法は2種類:
  • セルフレビュー:
    • 同じエージェントに続けてレビューを指示する方法
    • 構成がシンプルでコストが低い
    • 生成時と同じ文脈を引き継ぐため、見落としを見つけにくい場合がある
  • クロスレビュー:
    • 別のサブエージェント（別視点、別ペルソナ）にレビューさせる方法
    • 多様な視点から確認できるため、品質重視のタスクに有効
• クロスレビューの実践例（並列レビュースキル）:
  • チェックリスト検証担当: プロジェクトのレビューチェックリストと変更内容を項目単位で突き合わせる
  • 実装検証担当: レイヤー構成、NULL安全性、コーディング規約に絞ってコードを確認する
  • テスト観点検証担当: テストの網羅性、命名規則、ユビキタス言語の使用を検証する
  • 既存コードとの一貫性検証担当: 既存の実装パターン・命名との整合性を確認する
  • 不具合検出担当: diff内の情報のみから明らかなバグを検出する
• 委譲プロンプトには「役割（何を検証するか）」「参照するガイドライン」「タスクの手順」を明示する
• ペルソナと担当範囲を絞るほどレビューが深く掘り下げられる

■ 5. ポイント4: 仕事ぶりを評価して、次の任せ方に活かす

• 評価指標を決める:
  • スキルごとに品質を測る評価指標を定義する
  • 設計書生成スキルなら「観点の網羅率」「業務制約への準拠率」「再実行時のブレ幅」
  • レビュー系スキルなら「指摘の真陽性率」「重大度判定の妥当性」
  • Anthropicの公式ベストプラクティスも、スキルの中身を書く前にまず評価を作ること（evaluation-driven development）を推奨している
• 評価スキルを作る:
  • 評価指標を機械的に評価するための評価スキルを別途用意する
  • インプットは対象スキルのアウトプット、アウトプットは指標ごとのスコアと改善提案
  • 人間によるレビューの代替ではなく、レビュー前のスクリーニングとして機能させる
• 改善の意思決定は人間に残す:
  • 改善案を複数出させて人間が選ぶ
  • AIに全自動でスキルを書き換えさせると改善の方向性が本来の目的からずれやすい
• Gotchasの蓄積:
  • 改善ループや日々の運用で見つけた失敗パターンをスキルの注意書き（Gotchas）として蓄積する
  • Claude Codeの開発チームもGotchasセクションが最もシグナルが高いと述べている
  • 最初から完璧な指示を書くのではなく、運用しながら失敗を吸収してスキルを厚くする

■ 6. まとめ

• 4つのポイントはいずれも人に仕事を任せるときにも自然に行っていることと共通する
• AIを「仕事を任せる相手」と捉えて設計するだけで、スキルの再現性や改善のしやすさが大きく変わる
• AIに安心して任せられる仕事が増えるほど、人間は顧客の本質的な課題解決や高度な機能開発といった価値創造の仕事に集中できる

(2026/07/17)

タイピング数で測れる生産性ってなんだろう

• タイピング数で測れる生産性ってなんだろう｜星影｜Tech Hunter

要約:

■ 1. GMOインターネットグループの在宅勤務廃止の背景

• GMOインターネットグループは2020年にコロナ対応として在宅勤務へ移行
• 2023年に週2日の在宅勤務推奨を廃止し原則出社へ戻した後、週1日の在宅勤務推奨も廃止
• 廃止の理由として、在宅勤務時の時間当たりPCタイピング数の減少が挙げられた

■ 2. タイピング数を生産性指標とすることへの疑問

• 仕事にはタイピング以外の活動が含まれる:
  • 資料の閲覧やコードレビュー
  • 問題原因の調査や思考
  • 打ち合わせによる業務推進
• エンジニアリングにおいては、コード量の多さが生産性の高さを意味しない
  • 少ない変更で問題を解決できる方が価値が高い場合もある
• 生成AIの活用によりタイピング数はさらに減少する傾向にある
  • AIが生成したコードの確認・修正が主な作業となるため、タイピング数だけを見れば生産性低下に見えてしまう

■ 3. GMO自身の方針との矛盾

• GMOはAIおよびヒューマノイドの研究開発と社会実装を強く推進している
• 2026年を「ヒューマノイド元年」と位置づけ、大規模な研究開発拠点を設置
• AIで人間の入力作業を減らし、ヒューマノイドで作業そのものを代替する方針を掲げる企業が、タイピング数の減少を生産性低下の根拠とすることは矛盾している

■ 4. 評価指標のあり方

• 測りやすい数字と、測るべき成果は同じではない
• GMO自身もAI活用の目的として既存サービスの質向上や新サービスの創出を掲げている
• 在宅勤務の評価においても、作業量ではなくサービスの質・意思決定の速さ・実際の成果を軸にすべきである

(2026/07/16)

MongoDBが提起した特許訴訟は、オープンソース互換プロジェクトに対する新たなリスクなのか？

• MongoDBが提起した特許訴訟は、オープンソース互換プロジェクトに対する新たなリスクなのか？ – Shuji Sado

要約:

■ 1. 訴訟の本質

• MongoDB社がFerretDB社を提訴した件は、商標やブランド表示の争いとして受け取られる傾向にある
• 訴状の構成を精査すると、請求原因6本のうち4本が特許侵害であり、法的重心は特許側にある
• 残る2本はランハム法上の虚偽広告とデラウェア州法上の商標希釈であり、連邦商標法上の商標権侵害請求は含まれていない
• 本件は「表示の適否」だけでなく、MongoDB互換を成立させる技術的実装領域そのものを特許の観点から問う事件である

■ 2. 訴訟の経緯と手続きの状況

• 警告書簡と提訴の経緯:
  • 2023年11月3日付の第1信で、MongoDB社は特許侵害・ブランド利用・文書利用を一体の問題として提起した
  • 2023年11月29日に第2信、2025年5月16日には特許クレームとFerretDB製品の対応表（クレームチャート）を含む第3信が送付された
  • 2025年5月23日、MongoDB社はデラウェア連邦地方裁判所へ提訴した
• FerretDB社の応答と反訴:
  • 数度の延長を経て、2025年9月17日に答弁書と反訴を提出
  • 2025年11月5日に修正版答弁書・反訴（全11本）を提出
  • 反訴8本は対象4特許の非侵害・無効確認判決を請求し、先行技術にも言及
  • 残る3本はMongoDB社によるランハム法上の虚偽広告・名誉毀損・取引妨害を主張
  • FerretDB社は、MongoDB社のブログ記事や書簡によってLinux Foundationのオープンソース協業から排除されたと主張
• MongoDB社の対抗措置:
  • 2025年12月3日、反訴のうち虚偽広告・名誉毀損・不法妨害の3本についてのみ却下申立てを実施（特許関連の8本は対象外）
  • 特許権者の侵害主張に関するコミュニケーションは連邦特許法で条件付き保護を受けるという理論を展開
• 手続きの現状:
  • 2026年4月28日、Noreika判事がスケジューリング・オーダー案の提出を命令
  • クレーム解釈ヒアリングや専門家ディスカバリに向けて手続きが進行中
  • 2025年12月時点でディスカバリは未実施であり、事件は本格審理の入口段階にある

■ 3. 法的論点の構造

• 第一層（表示・商標）:
  • 名称・互換性表現・ブランド利用の適否
  • 互換製品が元製品の名称をどこまで使えるかという問題
• 第二層（著作権・ライセンス）:
  • MongoDBのコミュニティ版や関連文書の利用態様
  • 警告書簡では言及されたが、訴状の請求原因には採用されなかった
  • コードを複製しない独立実装への著作権・ライセンス上の構成が困難であることを示す
• 第三層（特許）:
  • FerretDB社の実装がMongoDB社の特許クレームを満たすかどうかという問題
  • 本件において最も法的重量が大きい
  • 侵害が認定された場合、表示修正では対処できず、実装変更・機能制限・ライセンス交渉・事業継続への影響が生じ得る
• 訴状が侵害根拠として援用したのは、$groupや$unwindといった標準的集約ステージをサポートすることを示すFerretDB自身のドキュメントであり、MongoDBクエリ言語の標準機能実装自体が侵害主張の出発点とされている

■ 4. オープンソース互換プロジェクトへの新たなリスク

• 対象特許の領域:
  • 集約フレームワーク特許3件（US 8,996,463 / 9,262,462 / 10,031,956）：$groupや$unwindを含む集約パイプラインに関わる
  • 書込み最適化特許1件（US 10,866,868）：retryable writesの仕組みに関わる
  • いずれもMongoDB互換製品においてユーザーが当然に期待する中核機能領域
• 互換プロジェクトの構造的リスク:
  • 互換プロジェクトはロックイン緩和・移行コスト低減のために中核機能の実装に近づかざるを得ない
  • その中核部分が特許クレームの射程に入る場合、互換性の価値そのものが法的リスクに転化する
• ユーザー企業への波及:
  • MongoDB社の理論では、互換実装を「利用するユーザー自身」が直接侵害者となり、FerretDB社は間接侵害者とされる
  • Apache 2.0で配布される実装を採用・導入する企業のリスク評価にも影響する
• 求める救済に差止めが含まれており、金銭的清算ではなく提供行為の停止を狙っていることが読み取れる
• 著作権との本質的差異:
  • 著作権であればクリーンルーム実装による防御が成立しやすい
  • 特許は独自実装であっても侵害が成立し得るため、「コードをコピーしていない」という防御が機能しない可能性がある
• AIコーディングへの含意:
  • AI支援による独立互換実装のコスト低下が進む中、既存ベンダーにとって互換実装を阻止する実効的手段は特許に収斂していく
  • 本件が示す「特許前面型」の戦略はAIコーディング時代にこそ一般化しやすい

■ 5. AGPLとの関係と生じる逆説

• MongoDBのライセンス履歴:
  • 2018年10月16日より前のリリースはGNU AGPL、以後はSSPL
  • 集約パイプラインはMongoDB 2.2（2012年）で導入、retryable writesはMongoDB 3.6（2017年）で導入
  • 対象特許3件（2015年・2016年・2018年発行）はAGPL時代に成立し、対象機能もAGPL版として出荷された
• AGPL第11条の特許許諾の範囲:
  • AGPLの条件を遵守して「貢献者版」を実行・改変・頒布する場合、貢献者が保有する「必須特許クレーム」への許諾が及び得る
  • ただし、独立に書かれた互換実装一般には当然に拡大されない
• 生じる逆説:
  • MongoDBのコードをAGPL条件のまま利用する方が、MongoDB自身の必須特許クレームについて明示的許諾を受けやすい
  • コードを一行も複製しない独立再実装の方が特許リスクが高くなる
  • コードの複製度合いと特許リスクが逆相関するという構図は、オープンソースにおける一般的なリスク直感に反する
• コミュニティの違和感の源泉:
  • AGPL時代から公開・出荷されてきた機能領域が、互換実装を封じる主要手段として特許で攻撃されることへの想定外感
  • 法的解釈上はAGPL許諾が独立実装に及ばなくとも、「以前からリスクはあったが主たる攻撃手段として使われるとは想定されていなかった」という印象を与える

■ 6. まとめと将来的含意

• 本件の本質は表示・ブランドの問題と特許侵害の問題が重なっており、後者に法的重心がある
• 2026年に入りクレーム解釈と本格的ディスカバリに向けて手続きが進行中であり、核心部分の判断はこれから来る
• 将来への示唆:
  • 長く公開されてきた実装領域の特許が互換プロジェクトへの主要攻撃手段として一般化するなら、オープンソース互換プロジェクトは著作権・ライセンス条件だけでなく既存製品の特許ポートフォリオまで前提に設計が必要になる
  • AIコーディングの普及により独立互換実装のコストが低下するほど、この圧力は強まる
• 問われているのは法的成否だけでなく、AGPL時代からの連続性の上にある実装領域で互換実装を封じる主要手段として特許を前面に出すことがオープンソースの信頼と競争のあり方に照らして適切かどうかという問いである

(2026/07/16)

さくら田中社長「フルリモートは廃止しません」　GMOの“在宅勤務廃止”受け明言

• さくら田中社長「フルリモートは廃止しません」　GMOの“在宅勤務廃止”受け明言（1/2 ページ） - ITmedia NEWS

さくらインターネットの田中邦裕社長は7月14日、同社がフルリモート勤務を廃止しない方針を、自身のXアカウントで表明した。GMOインターネットグループの熊谷正寿代表が同日、在宅勤務推奨を完全廃止したと表明したことを受けた発言だ。

GMOの在宅勤務推奨廃止は熊谷代表が自身のXで表明し、ネットの大きな話題になった。

熊谷代表は「在宅で生産性が上がる方もいる」としながらも「データ上時間当りのPCタイピング数は確実に減少。トータルで在宅勤務はマイナス」と述べ、「負ける要素は排除する」と背景を説明し、さまざまな受け止めが広がった。

GMOの方針表明を受け、さくらの田中社長は「ネット企業なのに在宅勤務を廃止する会社が続出している」と指摘し、さくらはフルリモートを維持すると明言。「経営者の都合よりも、社員の働き方の多様性を活かして、社員に選ばれ続ける会社作りに努める」と述べた。

採用条件を大幅に改善したことにも触れ、多くの人が転職してきていると説明。足元の順調な状況を踏まえ、採用数を大幅に増やしているという。データセンター職は現地出勤が必要だが、採用要件と条件は、大幅に引き上げたという。

田中社長は、フルリモートを廃止する他社の判断について「自分の会社のことだけ考える経営者は、どんどんフルリモートをやめるが、その行為が日本をどれだけ悪くしているかという感覚がない」とも批判した。

田中社長は以前から、付加価値の高い企業が東京に集中し、高い収入を得るために東京に出ざるを得ない構造を問題視してきた。2024年12月にLINEヤフーがフルリモート廃止を発表した際にも「日本中から働ける会社を維持したい」とXで発言していた。

(2026/07/15)

Markdownからドキュメントサイトを構築、Astro/ViteベースのOSS「Blume」v1が公開

• Markdownからドキュメントサイトを構築、Astro/ViteベースのOSS「Blume」v1が公開 | gihyo.jp

MEMO:

• コーディングエージェント使ってるとPLANなどでMakdownを出力することが多くなるから、ローカルでスタティックサイトジェネレータ動かした方が楽になるとは思っていた
• 使い慣れてる11tyでも良さそうだけど、これも試してみようか

(2026/07/15)

GMO、在宅勤務を廃止　熊谷正寿会長兼社長｢トータルではマイナス｣

• GMO、在宅勤務を廃止　熊谷正寿会長兼社長｢トータルではマイナス｣ - 日本経済新聞

GMOインターネットグループの熊谷正寿会長兼社長は14日、在宅勤務の推奨を13日付で廃止したと明らかにした。GMOによると従業員同士のコミュニケーションや意思決定の迅速化などを重視したためという。

熊谷氏がX（旧ツイッター）への投稿で、6年半続けた在宅勤務を完全廃止したと説明した。在宅で生産性が上がる人がいる一方、時間当たりのパソコンのタイピング数は減ったため「トータルで在宅勤務はマイナス」（熊谷氏）とした。

GMOは新型コロナウイルス禍を受けて2020年1月にグループ全体で在宅勤務を取り入れた。23年には週2日の在宅勤務推奨を廃止し、出社を原則としていた。

その後も採用や社員のQOL（生活の質）を考慮して週1回の在宅勤務を認めていたが、13日以降は廃止した。家庭の事情やオフィス環境など、個別の事情がある場合はグループ各社の判断を前提にするという。

MEMO:

• タイピング数...？

(2026/07/14)

現場のGoプログラミング　実プロジェクトで役立つイディオムとテスト

• 現場のGoプログラミング　実プロジェクトで役立つイディオムとテスト - インプレスブックス

保守とテストに強いGoの手法を学ぶ！

本書では、過度な抽象化を避け、保守しやすくテスト可能な慣用的（イディオム的）なGoコードの書き方を実践的に学ぶことができます。CLIツールやHTTPクライアント・サーバーの構築など、現実的なプロジェクトをサンプルとして取り上げます。依存性注入によるテスト容易性の向上、並行パイプラインを用いた同期APIの設計、HTTP処理の効率化から、ミドルウェアなどのコンポジションパターン、多態的なストレージ実装へ、段階的に高度な実践へと進むことで、現場で役立つ「Goらしい」思考法と確かな設計力が身につく一冊となっています。

MEMO:

• 2026/09/09発売

(2026/07/14)

食べログが「Deal Provider」を構築した理由──「AIがなければ踏み出せなかった」DDDという20年前...

• 食べログが「Deal Provider」を構築した理由──「AIがなければ踏み出せなかった」DDDという20年前からの設計思想への挑戦 - Tabelog Tech Blog

要約:

■ 1. 背景と課題

• 食べログの販売管理システムは、飲食店のプラン契約・オプション管理・請求処理を一元管理するシステムである
• 組織成長に伴い、販売管理チーム以外のチームが販売管理データを利用するシステムを開発するようになった
• 結果として以下の課題が顕在化した:
  • ビジネスロジックの分散: オプション利用可否判定などが各システムで独自実装され、仕様変更時に複数箇所の修正が必要になった
  • データアクセス方法の非統一: 汎用API・個別API・ActiveRecordなど複数の取得手段が混在した
  • 判定ロジックの二重管理: 同一ロジックが複数システムで重複実装され、片方修正時に他方への影響が不明確になった
  • AIコーディング精度の低下: 責任所在が曖昧で参照すべきコードが散在していた

■ 2. Deal Providerの設計思想

• 「データを渡す」から「判断済みの結果をサービスとして提供する」への設計転換を行った
• DDD（ドメイン駆動設計）の原則「判断をドメインに閉じ込める」を実践する中間データ層として Deal Provider を構築した
• 呼び出し元は複雑なロジックを意識せず、「そのオプションは有効ですか?」のように問い合わせるだけで判定結果を得られる

■ 3. 4層責務分離アーキテクチャ

• Port層:
  • Adapterが満たすべきインターフェースを定義する
  • 実装詳細を上位層から隠蔽する役割を担う
• Adapter層:
  • データ取得の具体的実装を担う
  • Portを include することで実装し、DB参照やAPI呼び出しなどを行う
  • データ取得元がDBからAPIへ変更されても、Adapterのみ差し替え可能な設計とした
• Usecase層:
  • ビジネスプロセスを編成する
  • DomainServiceへのディスパッチャーとして機能する
• DomainService層:
  • 複雑なビジネスロジックを集約する
  • 「この契約の販売事業者は誰か」といった判定を複数情報源から実施する

■ 4. AI活用の具体的方法

• コンテキスト提供による精度向上:
  • ADR（Architecture Decision Records）と既存コードをAIに提供することで、設計の意図を理解した実装生成が可能になった
• AIをルール番人として活用:
  • 従来はDDD原則の維持にチーム全員の継続的な学習と遵守が必要だったが、AIが実装段階で「この処理はどの層に書くべきか」を自動判定・強制できるようになった
• ドキュメンテーション効率化:
  • AI時代においてAIのためにコンテキストを残す重要性が高まっており、ADRや議事録のAI生成も活用している

■ 5. 実装上の工夫

• ADRによる意思決定の資産化:
  • 「なぜこの設計にしたのか」という背景を文書化することで、AIへのコンテキスト精度向上と新規メンバーの学習コスト削減を実現した
• 厳格なコーディングルールの整備:
  • AdapterはPortを必ず経由する
  • Adapterから上位層への呼び出しを禁止する
  • Portの戻り値をActiveRecordの具象クラスに依存させない
  • RubyやActiveRecordの便利さをあえて制約することでロジック流出や依存逆転を防止した
• 複数チーム間の責任明確化:
  • 販売管理チームが業務ロジックをDomainServiceに閉じ込め、利用チームはフラグを受け取るだけとすることで設計構造上の責任所在を自明にした

■ 6. 効果とまとめ

• 課題解決の結果:
  • ロジック流出 → DomainServiceへの集約により修正箇所が1か所に集約された
  • データ取得方法の選択困難 → Deal Provider経由が明確なルールとして定まった
  • ロジックの二重管理 → 一元化によりシステム間の修正ズレが解消された
  • AIの文脈散在 → 新機能実装をAIに委譲可能になった
• 開発効率の改善:
  • インバウンド向け店舗データAPI実装において体感30%ほど速く開発を進められた
  • 設計ルールがコードとドキュメントに組み込まれているため、AIへの指示が簡潔でも意図通りの実装が返される
• 横展開の実績:
  • 「運営者変更判定」など別ドメインでもPort/Adapter + Usecase + DomainServiceパターンを適用でき、設計パターンの汎用性が立証された
• 根本的なメッセージ:
  • 「正しいとわかっていても実践できなかった設計原則」を、AIが存在する今なら実践可能である
  • AIが「ルール番人」として機能することで、DDD導入の学習コストと品質維持コストが劇的に低下した
  • ドメインに責務を委ねたいが踏み出せない組織に対して、今がそのタイミングであるというメッセージを発信している

(2026/07/14)

AI使いすぎるとプロジェクトマネジメント力が低下する

• AI使いすぎるとプロジェクトマネジメント力が低下する｜すぅ | AI駆動PM

要約:

■ 1. 著者の問題意識と背景

• 育児休業復帰後、少人数・AI依存の環境で小規模プロジェクトを担当していた
• 大規模チームプロジェクトに復帰した際、対人コミュニケーション能力の低下を自覚した
• AIを多用することで、人を相手にした調整業務を省略する習慣が身についていた

■ 2. プロジェクトマネジメントの2つの領域

• 事象を扱う領域:
  • タスク管理やスコープ定義など、論理的・構造的な業務
  • AIが得意とする領域であり、補完効果が高い
• 人を扱う領域:
  • ステークホルダーとの期待値調整や感情的知性を要する業務
  • AIが代替できない、人間固有の領域

■ 3. AI依存がもたらす問題

• AIとの作業では、微妙なニュアンスの認識合わせを省略する傾向が生まれる
• 小規模・単独作業では顕在化しないが、チーム規模が拡大すると問題が表面化する
• 「認識のすり合わせ」の欠如が、プロジェクトの成否を分ける要因となる

■ 4. 著者の提言と対策

• AI活用によって対面コミュニケーションを避けるのではなく、意図的に直接会う機会を設ける
• 公式チャネル外で関係者の動機・懸念・文脈を把握することが重要
• AIプロンプトの最適化のみに注力するのではなく、人間関係の構築に投資する

■ 5. 核心的メッセージ

• AIをいかに使いこなしても、関係者との合意形成や期待値調整が欠けたままでは良い成果に結びつかない
• 持続可能なプロジェクト成功のために、人間関係の醸成はAIで代替不可能な要素である

MEMO:

• それならむしろ人間の間にAIに入ってもらうようにすればよいのではないだろうか

(2026/07/14)

My Thoughts on the Bun Rust Rewrite

• My Thoughts on the Bun Rust Rewrite - Andrew Kelley

要約:

■ 1. Jarredとの関係の歴史

• Jarredは約5年前にZigコミュニティに参加し、「初心者のエネルギー」を持つ人物として評価された
• 積極的な試行と失敗を繰り返しながら急速に成長する姿勢は、学習態度として肯定的に捉えられていた
• BunはJavaScriptという最も人気のある言語向けのツールチェーンとして注目を集めた
• JarredはThiel Fellowshipの影響を受け、クラウドファンディングではなくベンチャーキャピタル（VC）を選択した
• 当初、JarredはZigプロジェクトへの感謝を示していた:
  • BunのウェブサイトでZigの貢献を明記
  • Zig Software Foundation（ZSF）に年間6万ドルの定期寄付を実施

■ 2. VC化後の関係悪化

• Bun がVC出資を受けてスタートアップ化したことで、JarredはビジネスリーダーとしてZigコミュニティから距離を置くようになった
• 採用・雇用面での問題が発生:
  • 「最初の9ヶ月はグラインドになる」という過酷な労働環境を求める発言
  • コミュニケーション不足、非現実的な期待、低い共感力、経験不足など、マネジメントの失敗が報告された
  • その結果、Zigコミュニティの優秀な人材の多くがOven/Bunへの就職を避けた
• ZigとJarredの間に溝が広がった:
  • JarredはLSP実装やVSCode統合を優先するよう求めたが、Zig作者はより長期的なビジョンを持っていた
  • 両プロジェクトの価値観が根本的に乖離していた

■ 3. Bunのコード品質の問題

• ZSFはBunのコードベースを定期的に確認する中で、深刻な問題を発見した:
  • ハックの重ね掛け
  • アサーションの乱用
  • バグや技術的負債を排除する時間をほとんど取らずに機能を追加し続ける姿勢
• JarredはLLMを使用する以前から低品質なコードを書いていた
• ZSFはBunが「ネット負債」であると判断した:
  • Zigのメモリ安全性に対する批判を招く手本として、Bunが「Zigコードを書いてはいけない方法」の典型例になっていた
  • 将来的な身売りによる風評被害とZSFへの寄付停止が予見された

■ 4. Anthropicによる買収とRustリライト

• AnthropicによるBun買収はZSFにとって安堵をもたらした:
  • 寄付の停止はあらかじめ予測され、財務的な準備が整っていた
  • 定例ミーティングが無連絡でキャンセルされても驚きはなかった
• 買収直後からRustリライトが予想されていた
• ZSFはRustリライトを歓迎した:
  • AnthropicによるBun買収がZigコミュニティにスロップ（低品質な）コントリビューションや、LLM出力をフォーラムに貼り付けるようなAI熱狂者の流入をもたらしていたため
  • リライトにより、ZigがAIと結びつく言語として認識されるリスクが解消された

■ 5. Bunのブログ記事への反論

• バグ排除に関する誤った二項対立の提示:
  • 「スタイルガイド」対「言語機能」という対比でバグ対策を論じているが、本質はエンジニアリングリソースの投入であり、TigerBeetleへの評価が不十分
• テストスイートに関する矛盾:
  • 百万行の未レビューコードを「テストスイートで十分」と主張しながら、Zigコードに多くのバグがあると認めている点が矛盾している
• パフォーマンス向上の誤った帰属:
  • パフォーマンス向上の要因とされるLTO（Link-Time Optimization）は、Zigが最初からサポートしており、有効化を推奨していたにもかかわらず無視された
• ファジングテストに関する虚偽:
  • ブログではZigコードの熱心なファジングを示唆しているが、Bunチームは以前ZSFとの対話でファジングを行っていないと明言していた
• バイナリサイズ削減作業の誤った位置付け:
  • バイナリサイズ削減に関するエンジニアリング作業はリライトとは無関係であり、本来Zigコードベースで実施すべきだった作業
  • ZSFはcomptimeの過剰使用について長年警告していた
• コンパイル速度の不記載:
  • Zigコンパイラプロジェクト（約60万行）はクリーンビルド16秒、インクリメンタルコンパイル90msを達成しているが、Rustリライト後のBunの対応数値は示されていない

■ 6. 今後の展望と自己反省

• 本件の本質は言語機能の優劣ではなく、両プロジェクトの価値観の乖離と関係の破綻にある
• Jarredへの感情の整理:
  • 経営者としての批判とZigへの影響に対する憤りは認めつつ、個人としての成功と幸福を認める
  • Jarredは自身の目標（生産性の追求、経済的成功、テック著名人としての地位）を達成した
• 本記事に関する自己批判:
  • 個人攻撃として受け取られた原因は、自分でも気づいていなかった未消化の感情が文章に表れていたため
  • Zigユーザーが「元ユーザーが言語作者に批判される」という表面的な理解から不安を感じた可能性への配慮が欠けていた
  • ZSFと公にZigを使用・言及している関係者との関係は、本件を唯一の例外として良好であることを強調
• 今後はZigコミュニティの実態（冷静な人々による協力と創作）を伝える肯定的なコンテンツに注力する方針を示す

(2026/07/13)

SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7

• SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7 - Speaker Deck

要約:

■ 1. 発表の背景と主旨

• 発表者: KDDIアジャイル開発センター リードSRE 北浦智也（@kitta0108）
• 背景: AIがコードを高速生成する時代において、開発者の注力ポイントが「コードを書くこと」から「AIの出力を検証し、安全に届けること」へ移行した
• 主旨: SREとして積み重ねてきたプラクティスが、そのままAI駆動開発の「ガードレール」になる
• 対象: バックエンドAPIサービスの開発で培った7つの実践を事例として紹介

■ 2. 7つの実践: 全体像

• 実践一覧:
  • 第1章: 仕様駆動開発（OpenSpec）― AIへのインプット品質向上
  • 第2章: 受け入れ試験 ― デプロイ後の仕様準拠確認
  • 第3章: リグレッションテスト ― 既存APIの後方互換性
  • 第4章: k6 + ECS Fargate性能試験 ― 非機能要件の検証
  • 第5章: JIT-PAM ― 本番アクセスの時限制御
  • 第6章: ボーイスカウトルール ― 触れたコードを来たときより良くして返す
  • 第7章: モブプログラミングとレビュー ― チーム全員での理解と意思決定

■ 3. 第1章: 仕様駆動開発（OpenSpec）

• AIに対する基本姿勢:
  • AIは与えられたものを増幅する装置であり、ゼロから正解を当てる装置ではない
  • 増幅する元（目的・制約・仕様）が存在しなければ、出力はギャンブルになる
  • 出力がギャンブルだと改善ができないため、正しく増幅させる仕様を作り込む必要がある
• 仕様駆動開発（Spec-Driven Development）の目的:
  • 本来の開発は「認知（考える）→ 実装（書く）」の順だが、AI時代は「実装→認知」に逆転しがち
  • 増幅の元となる認知を実装より先に固定するためのプロセスが仕様駆動開発である
• 仕様駆動開発のフロー:
  • 曖昧で抽象度の高い要件から、優先度の高いものを人間が決める
  • AIの力を借りながら人間が仕様を作成する
  • AIが実装する
  • 人間がレビューし、AIもレビューする
  • AIが各種テストを実行し、人間が監督する
  • デリバリー
• OpenSpecの構造:
  • 人間が判断した意図をAIに蒸留させ、Specというドキュメントとして残す仕組み
  • changes/: 進行中の変更提案（proposal / design / tasks / spec差分）
  • specs/: 現行仕様。変更のアーカイブ時に差分が反映され、育っていく
  • 過去の判断に更新があれば specs/ も追従し、常に現実と一致した「生きたドキュメント」が育つ
• 仕様作成の手法:
  • AIが一度に1つずつ質問し、目的・制約・成功基準を引き出す
  • 情報が揃ってから仕様を生成する（HOW（実装方法）はこの段階では書かない）
  • superpowers:brainstorming から着想を得たスキルをOpenSpecに導入して実現
• 実行計画によるガードレール:
  • 実行計画は単なるコーディング作業リストではなく、開発から本番リリースまでの工程を定義する
  • 工程の例: 受入試験項目作成（開発開始前）→ ローカル開発（機能実装 + 監視・アラート設定）→ DEV環境デプロイ・各種テスト作成 → STG環境デプロイ・受入テスト・リグレッションテスト → STG環境での正常性確認・性能試験 → ドキュメント更新 → PRD環境デプロイ準備 → PRD環境デプロイ・正常性確認
  • 実行計画そのものが、テストや監視を飛ばした近道を防ぐガードレールとなる

■ 4. 第2章: 受け入れ試験

• ユニットテストだけでは不十分な理由:
  • AIが生成したコードがユニットテストをすべてパスしていても、インフラ設定やデプロイ構成の問題で動かないケースがある
• 受け入れ試験の定義: デプロイされた環境に実際のリクエストを送り仕様準拠を確認すること
• 受け入れ試験の設計タイミング: コーディングの前に設計する
  • 要件の受け入れ基準を受け入れ試験項目（試験項目ID・期待結果）に変換する
• TypeScriptによる自動化の範囲:
  • 正常系: APIレスポンス（HTTP 200/201、仕様準拠）、正常系アプリケーションログ、DBへの期待値どおりのレコード追加を三点で検証
  • リクエストで再現できる異常系（認証エラー401、バリデーションエラー400など）も自動化
• 環境の異常系の試験方法:
  • DB接続権限を一時的に剥奪するなど、環境に影響を与える試験はリグレッションテストの仕組みに残さない方針
  • マニュアル操作で行うが、操作を実施するのはAI
• 受け入れ試験実行用Skillの自前実装:
  • 以前は人間の手でマニュアル操作を行っていたが、AIに任せられる領域まで仕上がったと判断して実行をAIに移譲
  • Claude Codeの /goal（ゴールを与えると達成まで自律的に動く機能）を活用する受け入れ試験実行用Skillを自前実装
  • 試験項目をゴールとして与えるとAIが環境操作・実行・確認まで進める
  • 実行結果は人間が読むためのMarkdown（実行コマンド・レスポンス・結果判定を記述したレポート）として出力される

■ 5. 第3章: リグレッションテスト

• 受け入れ試験とリグレッションテストの関係:
  • 機能Aの受け入れ試験が機能B開発時の回帰検証に転用される
  • 機能が増えるたびにテストコードが積み重なり、テストの守備範囲が自然と広がる
• 実行方式の使い分け:
  • DEV環境: 並列実行（開発中は素早いフィードバックを優先、各試験が異なるリソースを対象なので干渉しない）
  • STG環境: 直列実行（CIで回すので時間をかけてよい、失敗箇所の特定しやすさを優先）
• Drizzleでテストデータを冪等に自動投入
• CI/CDパイプラインへの組み込み: STGデプロイ完了後、GitHub Actionsからリグレッションテストを自動実行
• テスト種別と守備範囲の整理:
  • ユニットテスト: コンポーネント内部の振る舞い
  • 受け入れ試験: 単一APIの仕様準拠
  • リグレッションテスト: 既存APIの後方互換性
  • 3層のテストでAI生成コードの品質を担保する

■ 6. 第4章: k6 + ECS Fargate性能試験

• 非機能要件をテスト可能にする考え方:
  • 「2,000TPSを5分間、p95で100ms以内で応答する」は検証する手段がなければ単なる願望
  • 性能要件をk6の閾値としてコード化する
• 実行基盤:
  • ローカルマシンからの実行はネットワーク環境で結果がばらつく
  • ECS Fargate上のk6コンテナにより再現性のある実行環境を実現
• API種別ごとの閾値設定:
  • 書き込み系API: p95 < 2,000ms、エラーレート < 1%、想定TPS 10
  • 非同期処理API: p95 < 500ms、エラーレート < 0.1%、想定TPS 100
  • 参照系API: p95 < 100ms、エラーレート < 0.1%、想定TPS 2,000
• 実行フロー:
  • GitHub Actions の workflow_dispatch でワンクリック実行（シナリオ・実行時間・TPSをUI上で選択）
  • 開発者がk6シナリオファイルを作成・コミット → GitHub UIでワークフロー実行をトリガー → ECS Fargateでk6コンテナが実行 → 結果JSONをS3にアップロードし、Slackに通知 → 開発者が結果をダウンロードして分析
  • チームの誰でも性能試験を実行できる状態を作る

■ 7. 第5章: JIT-PAMによる本番アクセス制御

• 課題の背景:
  • AI駆動開発で開発速度が上がるとデプロイ頻度も高くなる
  • 本番環境への常時アクセスはセキュリティリスクであり、Claude Code使用時に意図せず本番リソースを操作してしまう可能性がある
• 基本方針: 「AIの力を抑える」のではなく「安全な境界を明確にしてAIの力を引き出す」
  • 本番環境が確実に守られていれば、開発環境やSTG環境ではAIに思い切り力を発揮させることができる
• JIT-PAMの仕組み:
  • 「必要なときに、必要な時間だけ」本番アクセスを許可する
  • AWSのIAM Trust Policyに有効期限付きの条件を動的に追加する
  • 開発者がworkflow_dispatchでアクセス要求（15〜720分）
  • GitHub ActionsのEnvironment Protection Rulesで管理者承認を要求
  • 管理者が承認した場合のみTrust Policyを更新し、時限的アクセスを開始
• 自動失効の仕組み:
  • DateLessThan 条件により指定時刻を過ぎると自動的にアクセス拒否
  • 手動での取り消し不要により取り消し忘れリスクを排除
  • MFA必須条件で認証強度も確保

■ 8. 第6章: ボーイスカウトルール

• ボーイスカウトルールの定義: 「触れたコードを来たときより少し良くして返す」という古くからのプラクティス
• AI駆動開発での変化:
  • 以前は「直したいが今やると本題が進まない」と積み残されがちだった
  • AI駆動開発により改善コストが激減し、「見つけた瞬間に直す」が現実的になった
• 実践方針:
  • あるべきではない実装の改修コストは時間が経つほど大きくなるため、見つけた瞬間に直す
  • 「少し良くして返す」にとどまらず、割と大きい改修もその場で行う
  • 改善事項を積んで計画し優先度を決める管理コストの方が高くつく
  • モブでのレビュー中に気づいたら、その場でAIに指示して直す
• 対象範囲: コードに限らず、テストコード・仕様（specs/）・ドキュメント・AIへの指示書まで、触れたものすべて
• ガードレールとの相乗効果:
  • 受け入れ試験・リグレッションテストがあるので壊れればすぐ分かり、怖がらずに直せる
  • 綺麗に保たれたコードはAIが読む「増幅の元」になるため生成の精度が上がる
  • 小さな改善を回すほどガードレールとAIの精度が両方育っていく

■ 9. 第7章: モブプログラミングとレビュー

• 役割分担:
  • ドライバー: AIとの対話を進める人
  • ナビゲーター: 方向性を決める人
  • コードを書くのはAIであり、メンバー全員が議論と判断に集中する
• ドライバーの選出方針:
  • 「その領域の理解に一番自信がない人」の立候補制
  • 「やれる人」よりも「やるべき人」を優先する価値観
  • ナビゲーターの議論を咀嚼してプロンプトに落とし込むことが最も学習効果が高い
  • チーム全体の知識の偏りを減らす効果がある
• プルリクエストを廃止:
  • レビューはAI駆動開発において最も大事にしている工程
  • 非同期で行うプルリクエストは膨大な出力をレビューするのに適さないと判断
  • モブの中でどのような指示を投げたのか、その指示によってどのような結果が返ってきたのかをリアルタイムでレビューすることが重要
• チーム全体への情報共有:
  • 開発タスク完了後、10:00の朝会または13:00のリファインメント（毎日実施）でやったことを情報共有する
  • モブの外のメンバーにも共有される仕組みであり、フィードバックで修正が計画されることもある

■ 10. まとめ

• ガードレールが増えるほどAIに任せられる範囲が広がる
• 各ガードレールの効果:
  • 仕様駆動開発: AIに正しい方向を示す
  • 受け入れ試験 + リグレッションテスト: AIの出力を多層的に検証
  • k6性能試験基盤: 非機能要件を「願望」から「検証済み」に変える
  • JIT-PAM: AIの力を安全に引き出す境界を作る
  • ボーイスカウトルール: 触れたコードを来たときより良くして返す
  • モブプログラミングとレビュー: 理解と意思決定にチーム全員で集中する
• AIの性能は日々進化するが、それを活かせるかどうかは周りの仕組み次第であり、SREとして積み重ねてきたプラクティスがAI駆動開発の文脈でその価値を一層増している

(2026/07/13)

Loop engineering: Getting started with loops

• Loop engineering: Getting started with loops | Claude by Anthropic

要約:

■ 1. ループの定義と分類

• ループとは、エージェントが停止条件を満たすまで作業サイクルを繰り返す仕組み
• 分類軸は、トリガー方法・停止条件・使用するプリミティブ・タスクの適性の4点

■ 2. 4種類のループ

• ターンベースループ (Turn-based loops):
  • ユーザーのプロンプトによってトリガーされ、Claudeが完了と判断するか文脈が必要になった時点で停止
  • 短期・非反復タスクに最適
  • 具体的なプロンプト記述とスキルによる検証でトークン消費を管理
• ゴールベースループ (/goal):
  • 手動トリガーで、ゴール達成または最大ターン数到達で停止
  • 検証可能な終了条件を持つタスクに最適
  • 例: 「ホームページのLighthouseスコアを90以上にする、最大5回試行」
• 時間ベースループ (/loop・/schedule):
  • 指定したインターバルでトリガーされ、キャンセルまたはタスク完了で停止
  • 定期的な作業や外部システムとの連携に最適
  • /loop はローカル実行、/schedule はクラウドに移行
• プロアクティブループ (Proactive loops):
  • イベントやスケジュールによってトリガーされ、リアルタイムの人間関与なしで動作
  • バグレポート処理・マイグレーションなど定義明確な反復作業に最適
  • /schedule・/goal・スキル・動的ワークフロー・自動モードを組み合わせて構成

■ 3. 品質とコスト管理

• コードベースを整備し、Claudeが既存パターンに従えるよう維持する
• 検証基準をスキルにエンコードする
• コードレビューにはセカンダリエージェントを活用する
• 明確な成功・停止条件を定義してトークン消費を削減する
• ルーティンのインターバルを実際の変更頻度に合わせて設定する
• /usage コマンドで利用状況を確認する

(2026/07/13)

「視座を上げる」に悩むあなたへ。語れる主語を増やして「視点」を得るヒント

• 「視座を上げる」に悩むあなたへ。語れる主語を増やして「視点」を得るヒント - freee Developers Hub

要約:

■ 1. 「視座を上げる」の定義

• 「視座を上げる」とは、「様々な人(やその立場)を主語にして話せるようになること」を意味する
• 「視座が高い」とは、異なる視点の解像度を高めることにより、広くものごとを見られる状態を指す
• エンジニア向けの言い換えとして、ものごとに関わる変数（自分・チーム・ステークホルダー等）の数と関係性の解像度を高めることと捉えられる
• 「視座」に高さや上がるという表現がつく理由は、視点が増えることで広く・遠く見渡せるようになるためであり、実態は広さ、深さ、構造、時間軸の拡大を意味する
• 今まで知らなかった視点は先輩・上司・経営者など経験が長い立場の人が持つことが多く、それが視座=上という印象につながっている

■ 2. 視座を上げることの必要性

• 様々な人の視点の解像度を上げることは、「自分への期待値を乗りこなし、飛び越えるため」に必要である
• 「経営者視点を持て」とは、経営上の意思決定を求めているのではなく、「経営者視点を理解した上で自チームが事業にとって価値ある成果を出せるよう考え行動すること」を求めている
• 視点の解像度が求められる場面の例:
  • 優先順位のあがったプロジェクトをいつ差し込むか
  • 技術的負債と機能開発のどちらを優先するか
  • PRのコード品質にどこまでこだわるべきか
• よりよい判断を自分で行い、行動指針を示すために様々な視点の解像度が必要となる

■ 3. 視座を上げるための4つのステップ

• ステップ1: 新しい視点を持つ人に気づく（視点の認知）:
  • 新しい視点は自分の感覚の外にあるため、人との対話やインプットから入力する必要がある
  • 自分にはない視点であるというメタ認知も必要である
• ステップ2: その視点の構造理解を深める（課題・意図の理解）:
  • 視点で何を意識しているか、なぜか、どうすれば得られるかなど背景・課題・意図を噛み砕く
  • 違いに気づいても読み解けなければ「自分とは違う」で終わってしまう
• ステップ3: その視点を自分の言葉で話せるようになる（当事者としての変換）:
  • まず自分で説明できるようにし、その視点について語り、行動できる状態にする
• ステップ4: その人の視点を自分の判断軸に加える（当事者としての行動）:
  • 自分が全て実行する必要はなく、AIや周囲の人に実行を任せつつ、自分が当事者として実行を決めることも当事者として行動できている状態といえる

■ 4. 視座を上げた実体験エピソード

• 【個人→チーム】 がむしゃらにチームに貢献できることを探し、チームを主語にタスクを進める:
  • 担当者不在のOSS脆弱性対応に手をあげて手探りで対応を進めた経験
  • 停滞していることに突っ込んでいくことで自身の解像度があがり、チームの製品への解像度も高まった
  • チームで必要なものごとに関わることで視点を得ることができる
• 【チームタスク→メンバー自身】 チーム内の解像度を上げ、チームメンバーを主語にチームに向き合う:
  • 小さなチームのリーダーとして、メンバーの能力・キャパシティを越えた期待値をかけ続けた結果、メンバーが疲弊しチームを去る人も現れた
  • チームの理想だけでなく、メンバーの状態・能力・モチベーションという視点を持ってチームに向き合うことが必要だった
• 【チーム→担当領域】 チームへの期待値の解像度を上げ、自領域を主語にめざす状態を描く:
  • マネージャーとして周囲がチームに求める期待値を自分の言葉で語れず、ロードマップ変更をそのまま伝えるだけになっていた
  • 原因はロードマップ変更の背景・投資意図への解像度の低さと、メンバーへのフィードバックを躊躇するマネージャーとしての弱さ
  • メンバーへの腹を割った対話と、周囲のマネージャー・ステークホルダーとの対話により解像度を高めることで改善した
• 【担当領域→会社】 全社ビジョンへの解像度を上げ、会社を主語に自領域が生み出す価値を示す:
  • 担当領域のエンジニアリングマネージャーとして、会社のミッション・ビジョンへの解像度が甘く領域を越えた成果が出せていなかった
  • 会社のミッション「スモールビジネスを、世界の主役に。」をマインドマップで深掘りし、なぜを突き詰めることで自領域が生み出す価値との接続を実現した
  • 上位の視点（会社レベル）から解像度を上げていくことで、自領域のロードマップや優先順位の根拠を明確に示せるようになった

■ 5. まとめ

• 「視座を上げる」とは「周囲に対する解像度をとにかく上げる」行為に集約される
• 物差しとして「その人を主語にして状況を語れるようになること」を活用し、語れる主語を増やすことが視座を上げる実践的な第一歩となる

(2026/07/13)

正規化のすすめ – はじめに

• 正規化のすすめ – はじめに - finecode

(2026/07/12)

CozoDB: embedded Datalog, performant graphs

• CozoDB: embedded Datalog, performant graphs
• GitHub - cozodb/cozo: A transactional, relational-graph-vector database that uses Datalog for query. The hippocampus for AI! · GitHub
• CozoDB v0.7

MEMO:

• SQLiteのような組み込み型のグラフDB
• Rustで実装

(2026/07/12)

React 画面を「コンポーネント情報つきの単一 HTML」に書き出す

• React 画面を「コンポーネント情報つきの単一 HTML」に書き出す

MEMO:

• 面白い試みだが、git tagでスナップショットを再現できれば十分な気がする
• AIにデザインレビューをさせたり、複数バージョンを比較したい場合は確かに単一HTMLの方が楽ではありそう
• ローカルでnpm devする場合は複数立ち上げようとするとポート競合を意識する必要があり煩雑というのはある

(2026/07/11)

要件定義を整理する3つの手法（イベントストーミング／RDRA／ICONIX）

• 要件定義を整理する3つの手法（イベントストーミング／RDRA／ICONIX）

要約:

■ 1. イベントストーミング

• 付箋を使って業務の流れを可視化するワークショップ形式の手法
• 業務が複雑で関係者の認識がバラバラな場合に活用する
• 壁やホワイトボードに大きな紙を貼り、業務の出来事を時系列に配置する
• 要素と役割（色分け）:
  • ドメインイベント（オレンジ）: 業務上の事実を過去形で表現し主役となる
  • コマンド（青）: イベントを引き起こす操作（例: 「予約する」）
  • アクター（濃黄）: 操作実行者（利用者、管理者など）
  • 集約（薄黄）: コマンドが作用する対象のまとまり
  • ポリシー（紫）: 「イベントが起きたら次に何をするか」という業務ルール
  • 外部システム（ピンク）: 連携先システム
  • リードモデル（緑）: 判断時に参照する情報・画面
  • ホットスポット（赤）: 疑問・対立・未確定の論点
• 基本フロー:
  • アクターがコマンドを実行する
  • コマンドが集約に作用する
  • 集約がドメインイベントを生む
  • ポリシーが反応して次のコマンドを呼ぶ
• 3段階の深掘り:
  • ビッグピクチャー: ドメインイベントのみを時系列配置し業務全体を俯瞰
  • プロセスモデリング: コマンドなど他要素を加え因果関係を詳化
  • ソフトウェアデザイン: 集約中心に実装意識で粒度を落とす
• メリット:
  • 早期に業務全体像とズレを発見できる
  • 開発者だけでなく業務担当者も参加し認識を統一できる
  • 例外パターンや論点が自然と可視化される
• デメリット:
  • 正式な仕様書は完成しない
  • 初期段階の業務理解地図に留まる

■ 2. RDRA

• 要件を関係性で整理するための手法
• イベントストーミング後に要件を体系的にまとめる際に活用する
• 4つのレイヤー構造（上から下へ）:
  • システム価値: 利用者・外部システム・システム必要性を明確化
  • システム外部環境: 業務フロー・利用シーンを描写
  • システム境界: 画面（バウンダリ）・機能（ユースケース）
  • システム: 扱う情報・状態変化・条件・バリエーション
• 上のレイヤーが下のレイヤーの「なぜ必要か」を説明する入れ子構造を持つ
• 各層がすべて上層にたどれるようにつながる
• メリット:
  • 「なぜその機能が必要か」が可視化される
  • 機能を並べても見えにくい業務とのつながりを明確にする
  • 要件同士の関連性が明確になり抜け漏れを発見しやすい
• デメリット:
  • 最初は型に慣れる必要がある
  • 複雑に見える可能性がある

■ 3. ICONIX

• 要件から設計・実装へつなげるための手法
• 画面・処理・データ・オブジェクト責任を整理する
• ユースケース（利用者がシステム使用で何かを達成する一連の流れ）を中心とする
• ロバストネス分析（ユースケースと設計間の曖昧さを減らす工程）:
  • バウンダリ（境界）: 利用者が触れる画面・入り口
  • エンティティ: 扱うデータ（予約、空き枠など）
  • コントロール（制御）: 処理・ロジック
• 基本ルール:
  • 利用者は画面としか話せない
  • 画面とデータは直接つながらず必ず処理を経由する
• 実施プロセス:
  • ユースケースをロバストネス分析で図化する
  • 文章では読み飛ばしていた抜けが図にすると可視化される
  • シーケンス図・クラス図へ落とし込む
• メリット:
  • 要件からコードまでのつながりが見えやすい
  • 曖昧さが図で可視化される
• デメリット:
  • 業務探索には向かない
  • 初期段階では不適切

■ 4. 3つの手法の使い分け

• 業務全体像が見えていない場合: イベントストーミングを選択
• 要件の抜け漏れ・矛盾を減らしたい場合: RDRAを選択
• 要件を設計・コードにつなげたい場合: ICONIXを選択
• 実務では単体よりも組み合わせが効果的

■ 5. DDDとの連携フロー

• イベントストーミングで出来事を洗い出す
• RDRA + DDD同時進行で状態・パターンを体系的に整理する
• DDDの設計に落とし込む（特にアプリケーション層設計にRDRA情報が重要）
• 注意点:
  • イベントストーミングが浅いまま設計へ進むと行き詰まる
  • RDRAを「後付けの清書」にせず矛盾発見とDDDへの情報提供に活用する

■ 6. その他の関連手法

• ユーザーストーリーマッピング: 体験を時系列化
• BPMN: 業務フロー図化
• 要求分析ツリー: 目的から手段へ掘り下げ
• 新手法導入前に確認すべき事項:
  • 手法の概要
  • 使用可能な場面
  • 解決する悩み
  • 前後工程との接続方法

■ 7. 推奨フローとまとめ

• 要件定義プロセスの推奨順序:
  • まず業務を理解する（イベントストーミング）
  • 次に要件を整理する（RDRA）
  • 最後に設計へつなげる（ICONIX）
• 初心者はイベントストーミングから開始することが推奨される
• 関係者集約が難しい場合や業務が見える場合はRDRAから進めてもよい
• 理想的フロー: イベントストーミングでイベント洗い出し→RDRAで状態やパターン整理→DDDの設計へつなげる
• 3手法を組み合わせることで、要件定義がドキュメント作成から業務理解と良設計実現のプロセスへ昇華する

(2026/07/11)

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)