/note/tech

何を作ったかより何を変えたかで自分を語れよ!!! - 書籍『Outcomes Over Output』が目標設定の悩み...

何を作ったかより何を変えたかで自分を語れよ!!! - 書籍『Outcomes Over Output』が目標設定の悩みを解消してくれた｜まざっち

要約:

■ 1. 目標設定への苦手意識

長年の苦手意識:

スプリントゴールやクォーター目標、半期目標など、毎回これでいいのかと悩んできた

しっくり来ないまま走り出してしまったこともある

型を見出せない理由:

マネジメント本を読んでも、目標設定はチームの役割や状況に依存する部分が大きい

自分の中での型や正解を見出せないでいた

『Outcomes Over Output』との出会い:

Josh Seiden 著の書籍で、"Outcomes" という言葉の捉え直しによって一気に霧が晴れた

1つのシンプルな言語化で自分の開発メンタルモデルを大きく変えられた

■ 2. うまくいかなかった目標の2パターン

機能を期限までに出す型:

わかりやすいが、チームの熱量や主体性が上がりづらい

出すこと自体がゴールになり、なんのために作っているのかという視点が抜け落ちる

クォーター単位などでは途中で優先順位が変わることも多い

交渉の余地が少なく、言われたものを作るだけの空気になりがちで、理想のエンジニアチーム像との乖離が大きい

利用率を X% 改善する型:

アウトプットよりアウトカムという定説を理解しないまま適用し、ビジネスの成果に寄せてしまっていた

開発に閉じない広い視点は得られるが、不確実性が大きくチームとしては扱いづらい

ビジネス的な大きい KPI は、チームの手が届くところから遠すぎる

達成でも未達でも、開発チームの要因か営業やマーケの要因かを切り分けられない

ふりかえりが毎回ふわっとして、改善点も曖昧になり、次につながる学びが残りづらい

距離感の問題:

近すぎても息苦しく、遠すぎても迷ってしまう

■ 3. プレスリリース目標の成功と後ろめたさ

手応えのあった「プレスリリースを n 本出す」:

プレスリリースという区切りが、何を目指せばいいかを決めてくれる

期限もちょうどいい粒度で切れる

出せたかどうかを確実に判定でき、出せなかった要因もチームの外に散らばらないのでふりかえりが機能する

発信のためにどんな機能を作ると良いかを開発チームから提案・交渉でき、主体性を持ちやすい

ビジネスチームや広報チームと協力してフローを整備・改善する良いチーム状態になっていた

歴代でいちばん納得感のある目標設定だった

当時抱えていた後ろめたさ:

「アウトプット志向は良くない」という呪いを、自分で自分にかけていた

プレスリリースの本数はどう見てもアウトプットの目標であり、ダサい目標かもしれないと思っていた

■ 4. インパクト・アウトカム・アウトプットの定義

インパクト:

組織として得たいビジネス上の利益

例は売上の増大やコストの削減

アウトカム:

インパクトを出すために起こしたい、ユーザー行動の変化

例はユーザーがメールを開くようになること

アウトプット:

アウトカムを起こすために作る、プロダクトの変化

例は開きたくなるメール通知

■ 5. アウトカム＝ユーザー行動の変化

観察できる形への落とし込み:

ふわっとした「価値」ではなく、人が何をするようになるかという観察できる形になっている

「価値を届けられたか」は解釈が割れるが、「こう動くようになったか」は観測すればはっきりする

目標として追いやすく、チームで目指すものの認識も揃う

手段を決めつけない性質:

行動の変化という目標は、どう実現するかを決めつけない

その行動をどう起こすかはチームに委ねられ、解決策を工夫する余地と主体性の余地が残る

ビジネスとの接続:

ユーザーの行動の変化なら何でもよいわけではなく、ビジネスの利益につながるものだけがアウトカムと呼ばれる

その行動が変わるとなぜ利益につながるのかという問いが自動的についてくる

目標としての利便性:

観察でき、かつビジネスと密接なので、チーム内外への宣言内容としてかなり便利

■ 6. プレスリリース目標の再解釈

3段階での整理:

インパクトはアポ（商談）を増やすこと

アウトカムはプレスリリースを見て興味を持つ人が増えること

インサイドセールスがプレスリリースをきっかけにコール対象を増やすこともアウトカム

営業が商談でプレスリリースにまつわる話をすることもアウトカム

アウトプットはプレスリリースを出すこと、およびプレスリリースで好評そうな機能を作ること

見た目はアウトプットでも機能した理由:

インパクトまでの因果が短くつながっていた

プレスリリースが増えれば、見る人や話せるネタが増え、アポが増える

そうした変化に効く機能は、チームで模索でき作っていける

■ 7. 良い目標の2つの基準

基準1:

チームが自分の手で動かせるものか

基準2:

インパクトへの因果が短くつながっているか

失敗した目標に欠けていたもの:

「機能をいつまでに出す」は手で動かせるが、インパクトへのつながりを説明できない

「利用率を X% 改善」は因果の先端だけを掴んでおり、チームの手で動かせない

ちょうど1つずつ欠けていた

雑すぎる一般化への反論:

「アウトプット志向は良くない」というのは雑すぎる一般化である

2つの基準を満たすことが、自分が作りたい開発チームの目標設定

ユーザー行動の変化は因果のちょうど真ん中にある観察可能な中継ポイントであり、目標の中心に置けば2つの基準を満たしやすくなる

言語化できたことの価値:

なんとなく良いと感じていた目標の良さを、自分なりにきちんと言語化できたことが最も嬉しかった

■ 8. ユーザーはエンドユーザーに限らない

同僚はカスタマー:

本の後半に組織変革へアウトカム思考を適用する章 Outcomes for Transformation がある

「Your colleagues are your customers」というルールが出てくる

エンドユーザーから遠い仕事でも、誰かの行動を変えようとしていることに変わりはない

プラットフォームチームでの失敗:

ビジネスモデルを SaaS 以外に広げる事業基盤を作るプラットフォームチームの EM をしていた

目標設定と組織運営にずっと失敗し続けたという自認がある

エンドユーザーから遠く、事業という長い目線での変化や不確実性を扱う必要があった

何をクォーターで追う目標に置いてもしっくり来なかった

3段階での整理:

インパクトは SaaS×マッチングという新しいビジネスモデルの立ち上げ

アウトカムはエンジニアが開発の重複を避け、新しいプラットフォームの上で業務をするようになること

アウトプットは共通でデータを扱えるような新しい基盤の提供

整理によって見えること:

基盤を作りきること自体はゴールではない

エンジニアが移って初めて、新しい事業の開発が回り出す

使っていなかった人が使うようになる 0→1 の変化なので、起きたかどうかは明白で移行した人数で測れる

チームの打ち手で動かせる

ユーザーである社内エンジニアの事業上の課題に目を向け、最初に作るべき変化を見出しやすくなる

Everything is an outcome:

どんなチームの活動も、結局は誰かの行動を変えるためにある

自分たちのユーザーが誰なのかを特定できれば、この考え方はそのまま使える

■ 9. 目標設定を超えた広がり

適用範囲の広さ:

本ではこの視点を目標設定に限らず計画づくりや組織構造に活かせると説明されている

チーム目標は今後もインパクト、アウトカム、アウトプットの3段階で設計していく

長期のプロダクトロードマップや個人・チーム・組織の役割分担設計もアウトカム起点で描きたい

組織文化のユーザー中心化:

仕様の議論やデザインのレビュー、施策の計画やふりかえりで「それでユーザーの行動の何が変わるのか」と問う

その問いを置くだけで、価値を受け取る主体を自分たちからユーザー側に移せる

職種を問わずアウトカム起点で語れると、最小の工数でビジネス成果を出す道を探しやすく、工夫の余地も生まれる

書籍の推薦:

職種を問わずいろんな人にこの本を薦めてまわっており、社内のデザイナーもすぐに買っていた

日本語版がないのは辛いが、コンパクトに纏まっていてサクッと読める

日本語訳されていない名著へのファーストチャレンジにも適している

結び:

何を作ったかより、ユーザーの行動の何を変えたかでチームと自分を語れるようになりたい

(2026/09/04)

WebMCPがアツいので見てほしい

WebMCPがアツいので見てほしい | DevelopersIO

要約:

■ 1. WebMCPを再評価した経緯

WebMCPの位置づけ:

Webサイトの機能をAIエージェントが扱いやすくするためのWeb標準案

発表当時は「またMCP関連の何かが出たのね」程度の認識でスルーしていた

MCP導入の障壁:

開発者がMCP Serverを用意するだけでなく、ユーザー側でも接続先の登録や認証が必要になる場面がある

エンジニアには難しくなくても、一般ユーザーに「まずMCPを設定してください」と案内するのはハードルがある

どのくらい使うか分からないMCPをいちいち入れるのは面倒で、自分でMCPを開発しておきながらほぼ使っていなかった

エージェントアクセシビリティ:

人間向けのWebアクセシビリティと同様に、AIエージェントにとって理解しやすく操作しやすい状態を作ろうという視点

この視点から振り返って改めて理解した結果、WebMCPは非常に良い技術だと考えを改めた

■ 2. Browser Useの現状

Browser Useの利便性:

AIエージェントがWebブラウザを操作する機能で、最近のAIの発達と相まってかなり便利になっている

ページを読んで回答するだけでなく、ボタンの押下、フォームの入力、複数ページの移動ができる

設定の変更場所を尋ねると、操作方法を文章で教えるだけでなく設定画面まで移動してもらえる

操作代行への移行:

以前はAIに操作手順を聞き、その回答を見ながら自分で画面を操作していた

現在は「そこまで分かっているなら、もうやっておいて」が成立し始めている

サービスの設定変更など面倒な作業も丸ごと任せている

推測に依存する限界:

WebMCPを使わないBrowser Useでは、スクリーンショットやページの構造情報からボタンの役割や入力順を推測する

WebMCP非対応のサイトも操作できる一方、複雑な画面や似た項目が多いフォームでは迷うことがある

UIが変わると、それまで成功していた操作が失敗することもある

WebMCPは、こうしたブラウザAgentに対してサイト側から構造化された操作方法を渡すための仕組み

■ 3. WebMCPの仕様

WebMCPの定義:

Webサイトが自身の機能を構造化された「ツール」としてブラウザ内のAIエージェントへ公開するためのWeb API

W3CのWeb Machine Learning Community Groupで仕様が議論されている

執筆時点では正式なWeb標準ではなく、Draft Community Group Reportの段階

公開されるToolの形:

name、description、inputSchemaを持つ構造で、MCPやエージェントのToolを作った経験があれば見覚えのある形

宣言型API:

既存のHTMLフォームにtoolnameやtooldescriptionといった属性を追加する方式

ブラウザがフォームの構造からToolのinput schemaを生成する

Toolが呼び出されると、渡された引数が対応するフォームへ反映される

命令型API:

document.modelContext.registerToolでschemaとexecuteを定義する方式

Toolが呼び出された際の処理をexecuteで実装者が直接定義する

既存のJavaScript関数の呼び出しやアプリケーションのstate変更など、より自由な処理を実装できる

Tool定義の効果:

AIが画面を見て「たぶんこのセレクトボックスが経費カテゴリだろう」と推測する必要がなくなる

サイト側からTool名、説明、必要な入力項目を明示できる

Agentはその情報から適切なToolを選択し、ブラウザを介してサイト側が定義した操作を実行できる

■ 4. 人間とAIによる同一画面の共有

人間向けUIの維持:

Agent向けにToolを公開しても人間向けのUIをそのまま残せることが大きな魅力の一つ

フォーム入力やスライド編集をAgentに任せた場合でも、結果を普段使っている画面へ反映できる

人間は結果を確認して必要であれば手で修正し、再びAgentに続きを任せられる

構造化情報の受け渡し:

画面だけではAgentが推測しづらい情報をサイト側から構造化して渡せる

現在の契約プラン、入力ルール、操作による影響などをToolの説明や実行結果として返せる

単一状態の共有:

人間向けUIとAgent向けToolを別々に用意するのではなく、同じWebアプリの状態を人間とAgentの両方から操作できる

■ 5. 作成した3つのデモ

動作環境の制約:

筆者環境では現時点でCodex内のBrowserでのみ動作確認しており、ChatGPTのchrome拡張やGemini in Chromeでは動作に失敗した

WebMCP自体も対応クライアントもまだ発展途中で、利用環境によって動作状況が異なる可能性がある

Codexでは右側のサイドバーからブラウザを選択して該当のサイトを開ける

3つのデモはいずれも手元で動作でき、一部はGitHubでコードも公開している

Kiroku: 経費申請サイト:

よくある社内の経費申請を題材にしたデモ

申請作業は面倒で全部AIに任せたいが、最後の確認は人間がする必要がある

AgentがWebMCPを解釈して入力できるところまで自動で入力し、足りないところは質問してくる

Agentが効率的に選択肢を把握できるよう工夫しており、MCPと似ているため培った知識をそのまま応用できる

RelayDesk: 架空SaaS:

架空のSaaS管理画面を題材にしたデモ

設定の場所や現在のプランで使える機能かという質問に対し、契約状態やヘルプ情報を確認して該当画面まで案内する

契約変更のように影響のある操作は確認画面までに留め、確定は人間が行う

実際の業務でも操作そのものより設定場所を探す時間がかかるため、該当画面まで連れて行ってもらえると楽になる

Deckhand: 共同編集スライド:

人間とAIが同じスライドを編集するデモ

スライド全体を一度生成して終わりではなく、ページ追加、要素の編集、整列、テーマ変更などをツールとして公開している

AIが作った後に人間が細部を直し、その修正を踏まえてAIへ続きを任せる往復を想定している

Google Slidesなどに機能として加わることを期待している

■ 6. チャットボットの役割変化

ブラウザAgentの普及:

Gemini in Chromeはサイドパネルでの対話に加え、フォーム入力などを行うauto browseもプレビュー提供している

ChatGPTのブラウザ連携やClaude for Chromeなど、既存ブラウザをAIから操作する選択肢が増えている

提供地域、プラン、対応機能はそれぞれ異なるが、ブラウザの中でAIと一緒に作業する体験自体は広がっている

役割の移行:

サービスごとのチャットボットが担っていた役割の一部を、ユーザーが普段使うブラウザエージェントへ移せるかもしれない

サービス側は専用チャットボットに操作方法を覚えさせるのではなく、その画面で何ができるかをWebMCPで公開する

ユーザーは自分が選んだAIへ質問し、そのまま操作してもらう

構成によっては会話UIやLLMの利用コストをサービス側で持たず、ユーザーが契約しているAIを利用してもらえる

チャットボットが残る領域:

サービス独自のサポート品質を保証したい場合や、ページを開いていない状態で処理したい場合は従来のチャットボットやMCP、APIが適する

設定場所の案内や入力補助のような用途にはWebMCPの相性がかなり良い

■ 7. セキュリティと精度の課題

Tool定義の信用問題:

サイトが公開するToolをどこまで信用するかが重要になる

AgentにはToolの名前や説明、入出力のschemaが公開されるが、裏で実際にどのような処理が行われるかまでTool定義は保証しない

本物そっくりの模倣サイトがcheck_subscriptionのようなもっともらしいToolを公開することも考えられる

見た目だけでなく、Agent向けのToolまで本物らしく作られる可能性がある

プロンプトインジェクション:

Toolの説明や実行結果に悪意のある指示を埋め込み、Agentの判断を誘導する攻撃が考えられる

権限委譲の設計:

WebMCPにはOriginやToolの性質をAgentへ伝える仕組みも用意されているが、それだけで安全になるわけではない

購入、削除、解約など影響の大きい操作では人間の確認を挟むなど、Agentへどこまで権限を渡すかが重要になる

Tool選択の不確実性:

正規のサイトであってもAgentが常に想定したToolを選ぶとは限らない

cancel_subscription、pause_subscription、downgrade_subscriptionが並ぶ場合、「しばらく料金を止めたい」の解釈はAgentによって変わりうる

従来のUIテストだけでなく、依頼から適切なToolを選べるか、曖昧な場合に実行前に確認できるかというAgentを含めた評価も必要になる

■ 8. 今後の展望

WebMCPが今後Web標準として普及すれば、かなり多くのサイトで使われるようになると考えている

申請、設定変更、問い合わせ、情報収集など、普段ブラウザ上でやっている面倒な作業をAgentに任せられる点が魅力的

ブラウザAgentが当たり前になったとき、Webサイト側がAgentに操作方法を教えるWebMCPは重要な技術になるかもしれない

(2026/09/04)

Nuclio -- セルフホスト型のFaas

MEMO:

セルフホストできるFaaS
Open Fassがいつの間にか厳しめのライセンスになっていたので代替を探していて発見

(2026/09/03)

「10万円以上は部長承認」をどこに書くか。Goのドメインサービスと、使いすぎない線引き

「10万円以上は部長承認」をどこに書くか。Goのドメインサービスと、使いすぎない線引き #設計 - Qiita

要約:

■ 1. 記事のテーマとスコープ

扱う問題:

GoとDDDの学習記録の連載第5回で、前回は多段承認を実装しながら集約の境界を引いた

今回は「10万円以上の申請は部長の承認も必要」というルールをどこに書くかという問題に取り組む

このルールは申請にも承認ルートにも収まりが悪いが、業務のルールであることは間違いない

ドメインサービスの位置づけ:

DDDはこうした行き場のないふるまいのためにドメインサービスという概念を用意している

便利な分だけ誤用もしやすい概念なので、その線引きを論じる

スコープの限定:

承認ルートの決定ロジックの置き場所に絞る

金額の条件は「10万円以上なら部長まで」という単純なものにし、ルール自体の複雑さは扱わない

■ 2. ドメインサービスの定義

ドメインサービスとは:

業務のルールなのに特定のモデルの持ち物にできないふるまいを置く場所

モデル優先の原則:

DDDでは業務のルールをモデルの中に書くのが基本で、「申請中でなければ承認できない」は申請のメソッドに書く

複数のモデルにまたがるものや、モデルの外にある情報が必要なものは、モデルに押し込むと不自然になる

そうしたルールのために独立した置き場所を用意する

アプリケーションサービスとの違い:

名前が似ているアプリケーションサービス(連載でいうusecase)は処理の手順を並べる場所で、業務のルールは書かない

ドメインサービスは業務のルールそのものを書く場所

ドメイン層はデータの整合性の担保が責務、アプリケーション層はドメイン層の公開メソッドを組み合わせてユースケースを組み立てるのが責務

■ 3. 置き場所が見つからないルール

ルールが必要とする知識:

申請の金額は申請が持っている

部長承認が必要になる境界は組織のルールで、申請の外にある

その申請者にとっての課長・部長が誰かは組織図の知識で、申請の外にある

Applicationに持たせる案:

申請というモデルが「10万円という境界」と「誰が課長か」という組織構造の知識を抱え込む形になる

承認ルートは申請を作る時点で必要なので、申請が生成される前に判定が終わっていなければならず、申請のメソッドとしては順番が合わない

ApprovalRouteに持たせる案:

承認ルートは「課長、部長」という決まった並びを表すだけのモデル

ここに判定ロジックを入れるのは、できあがった名簿に「この名簿の作り方」を書き込むようなもの

名簿は結果であって、作り方の説明書ではない

usecaseに書く案:

動作はするし、多くのコードがここに落ち着くと考えられる

「10万円」という業務上の境界がusecaseにあると、バッチ処理や管理画面など別の入口から申請を作るときにルールが再現されない可能性がある

ビジネスルールはdomainに置くという連載の方針から外れる

結論:

どのモデルにも属さないが間違いなくドメインの知識であり、この行き場のなさがドメインサービスの出番

■ 4. ドメインサービスは最後の手段

濫用の危険:

モデルに収まらないものを何でも置けるため、「置き場所に迷ったらドメインサービス」を続けるとエンティティからロジックが吸い出されていく

最後に残るのはデータを保持するだけのエンティティと、ふるまいを全部抱えたサービス群になる

これはドメインモデル貧血症と呼ばれる状態で、DDDで避けたい形の代表格

ドメインサービスにする条件:

技術的な処理ではなくドメインの知識であること

特定のエンティティや値オブジェクトの責務にすると不自然になること

複数のモデルや、モデルの外の知識をまたぐこと

今回のルールは3つとも満たし、1つでも欠けるならモデルのメソッドとして書けないか考え直す

適用しない例:

第4回で作った「順番を飛ばせない」は承認ステップの並びを見れば判定できるので、申請のメソッドで足りる

この線引きがドメインモデル貧血症への転落を防ぐ歯止めになる

■ 5. Goでのドメインサービス実装

金額の値オブジェクト化:

Moneyは日本円の金額を表す値オブジェクトで、円未満の端数を扱わないため整数で保持する

NewMoneyは負の値を受け付けず、GreaterThanOrEqualという比較のふるまいを自分で持つ

自己検証を持つ値オブジェクトの型どおりの実装

組織図参照のinterface:

「その申請者にとっての課長は誰か」を知っているのは申請ドメインの外なので、ApproverResolverというinterfaceで要求だけを書く

実装はinfrastructure層に置き、domainは組織図の実体を知らない

「interfaceは使う側に置く」という第1回の方針がリポジトリと同じ構図で効いている

DecideApprovalRouteの実装:

申請者IDと金額とresolverを受け取り、課長を解決してルートを作る

金額が閾値以上なら部長を解決してルートに追加する

structのメソッドではなくただの関数にしたのは、この判定が状態を持たず、入力が同じなら出力も同じで保持すべきインスタンスがないため

関数で書ける理由:

JavaのDDDサンプルではドメインサービスはクラスとして書かれ、言語の制約でそうせざるを得ない面もある

Goは関数を第一級で扱えるので、状態を持たないドメインサービスは関数のまま置ける

第1回で書いた「Goにクラスがないことは制約ではない」がここでも当てはまる

閾値をMoney型にする理由:

intのまま比較すると裸の数値比較になり、100000が何なのかコードから読み取れない

値オブジェクト同士の比較にすることで、意味のある比較として残る

■ 6. usecaseは組み立てるだけ

usecaseの中身:

金額を値オブジェクトにし、ドメインサービスでルートを決め、申請を組み立てて保存する4つだけ

ifによる判定は1つもなく、10万円という数字もどこにも出てこない

薄いusecaseの意義:

第1回で書いたとおり、usecaseが薄いかどうかはレイヤ分離のバロメーター

ドメインサービスを使うと、判定ロジックがdomainに残ったままusecaseを薄く保てる

usecaseに書けば動くものをあえてdomainに置く理由がここにある

■ 7. テストの単純さ

テスト容易性:

ドメインサービスは状態を持たない関数なのでテストが単純

組織図はinterfaceなので、テスト用の実装を10行ほど書けば済み、DBもモックライブラリも要らない

境界値のテーブル駆動テスト:

10万円未満は課長のみ、ちょうど10万円は部長まで、10万円超は部長まで、0円でも課長の承認は要るという4ケースを検証する

「ちょうど10万円のときどうなるか」は業務ルールとして必ず確認が要る点

テストケースの名前がそのまま仕様の記述になっている

ドメインの知識がdomainパッケージにあると、テストもdomainパッケージで完結する

■ 8. デモの動作結果

同じ申請者が5,000円と150,000円の申請を作ると、金額の違いだけで承認ルートが課長のみと課長から部長までに変わる

10万円未満の申請は課長の承認だけでapprovedになる

第4回で作った「全段が承認されたら承認済み」という仕組みが、段数1のルートでもそのまま動く

組織図にない申請者を指定すると、承認者が見つからないエラーになる

■ 9. 既存コードの変更の少なさ

変更規模:

新しい業務ルールが増えて申請に金額という属性が加わったのに、既存ファイルの変更は6ファイルだった

大半はデモ用のmain.goで、それを除くと実質40行ほど

集約ルートであるApplicationの変更は、フィールドへのamount追加、コンストラクタと復元関数の引数追加、ゲッター追加の3点のみ

承認のロジック、状態遷移、集約の整合性を守るコードには1行も触れていない

新しい知識が新しい置き場所に入った:

ルート決定という知識はroute_policy.goという新しいファイルに丸ごと収まった

既存のモデルに押し込んでいたら、ApplicationかApprovalRouteのどちらかが金額と組織の知識で膨らんでいた

承認ルートを外から渡す設計だった:

NewApplicationは第4回の時点でルートを引数に取る設計だった

当時はマスタの実装を避けるための都合だったが、結果としてルートの決め方が変わっても申請側が影響を受けない構造になっていた

金額を値オブジェクトにした:

Moneyという1つの型にまとまっているので、Applicationに入ったのはフィールド1行で済んだ

通貨や単位を別々のフィールドで持たせていたら、変更はもっと散らばっていた

数字で見た利点:

DDDの利点は説明が抽象的になりがちだが、変更行数という数字で見ると具体的

新しい業務ルールを追加しても既存のドメインモデルがほぼ無傷だったことが、5回積み上げてきた設計の答え合わせになった

■ 10. 迷ったこと

閾値をコードに書く是非:

buchoThresholdは変数としてコードに埋め込まれているが、実際の組織では規程で決まっており改定もされる

設定ファイルやDBから読むべきかもしれないが、外部から与える設計にすると「規程の値を管理するのは誰か」という別のモデルが必要になる

連載の主題から外れるため踏み込まず、業務ルールの数値をどこまでコードに書いてよいかは整理できていない

スキーマ変更によるDB破損:

申請に金額の列を追加したところ、第4回までのデモで作られたringi.dbが残る環境で動かなくなった

テーブルが既に存在するためCREATE TABLE IF NOT EXISTSは何もせず、列だけが足りない状態になる

マイグレーションは扱わないと決めていたので、リポジトリの初期化でテーブルを作り直す形にした

デモとしての割り切りだが、DBを持つアプリで必ず向き合うコストが5回目にして表面に出た

ドメインサービスの許容範囲:

立てた3条件が妥当かはまだ分からない

実務では「サービスにすべきかエンティティのメソッドか」で議論が割れる場面が多いと想像している

基準を明文化しておかないと、気づいたときにはドメインモデル貧血症になっていそうな点が怖い

■ 11. まとめと今後

どのモデルにも属さないドメインの知識はドメインサービスとして独立させるが、「置き場所に迷ったら」で使うとドメインモデル貧血症に転落する

ドメインサービスにする条件を決めておく:

ドメインの知識であること

特定のモデルの責務にすると不自然なこと

複数の知識をまたぐこと

Goでは状態を持たないドメインサービスは関数でよく、クラスにする必要はない

知識を正しい場所に置くと変更は局所に収まり、新しい業務ルールの追加で既存のドメインモデルはほぼ変わらなかった

5回でエンティティ、値オブジェクト、リポジトリ、集約、ドメインサービスという戦術的DDDの主要な部品が揃い、連載は一区切りとする

次はここで作ったユビキタス言語をAIに渡す話を、オントロジーやMCPを絡めた新しい連載として始める予定

(2026/09/02)

アジャイルは回っているのに、なぜ価値創出が進まないのか？日立×Findyが語るAI時代における...

アジャイルは回っているのに、なぜ価値創出が進まないのか？日立×Findyが語るAI時代における"意思決定×開発×学習"の再設計 - YouTube

要約:

■ 1. 講演の前提

大企業ありがちな課題の抽出:

79企業に対するアジャイル開発コンサルティングの知見から、ありがちな課題を3つ取り上げる

企業ごとに規模も文化も抱える課題も異なるため、大企業共通の一般論を主張するものではない

特定企業が判別できるような具体的な話は避ける

■ 2. 課題1: ビジネスをハンドリングする人の不在

ハイパフォーマンスなチームだけでは不十分:

高性能な車も運転できなければただの置き物であり、維持費ばかりかかる

経営者が欲しいのは人材そのものではなく、人材が生み出す成果である

成果が出ない状態は経営者にとって望ましくない

アジャイル開発ができるだけでなく、経営者に向けた利益や成長に繋がっているかを問う必要がある

アジャイルにビジネスを回す流れ:

ビジネスをハンドリングするのはスクラムで言うプロダクトオーナーである

プロダクトオーナーが戦略を練り、成否を確認するKPIを設定する

マイルストーンごとに目標値を定め、予算を確保する

目標達成の仮説をプロダクトバックログに積み、開発者が開発して市場投入する

評価の結果、仮説が誤っていれば新たな仮説を積み直す

チーム内にハンドリング役がいない問題:

ある程度大きな企業ではプロダクトオーナーに相当する人がチーム内にいない

チーム内のプロダクトオーナーは現場の判断権限のみを持ち、ビジネスの決裁権を持たない

ビジネスの決裁権はチーム外のマネジメントが持つ

外部マネジメントによるアジリティ低下:

アジャイルの理解が浅いマネジメントはウォーターフォール型の計画を出す

現場のプロダクトオーナーはその計画に基づき柔軟にこなすだけの開発スタイルになる

ビジネスのハンドルが外側にあり、年に1回程度しか切られない

ハンドルを切るタイミングが遅く、ビジネスのアジリティが下がる

対策1: ハンドルを持つ人をチームに入れる:

決裁権を持つ人をチーム内に入れ、当事者意識とマインドチェンジを促す

具体的なやり方は当該企業の競争力に関わるため公開しない

対策2: 出島の設置:

出島を作って権限を移し、アジャイルをビジネスとして回せる体制にする

アジャイルをビジネスで回す上で最も良い形だが、組織をいじるため負担が大きい

対策3: 報告によるマネジメントの味方化:

組織もプロジェクトの仕組みも変えず、開発チームから報告を上げる

開発の進捗だけでなくビジネスの進捗もログ等から自分たちで用意して報告する

上位のマネジメントを味方に引き入れ、裁量をプロジェクト側に持ってくる

コストがかからない対策である

■ 3. 課題2: 組織への責任感が強いステークホルダー

ステークホルダー特定のセオリー:

新サービスは社内事務にも既存の関連システムにも影響し、それらは別部署が所管する

プロジェクト開始前にステークホルダーを特定し、協力を得られる状態にして推進するのがセオリーである

縦割り構造によるオーバーヘッド:

組織が分かれていると予算もミッションも組織ごとに異なる

過渡期に旧来の事務と新しい事務を並行して担う依頼をしても、相手は人員が足りない

足りない人員で対応すれば負荷過多とミスを招くため、要求を飲めず防御行動に入る

防御行動に入られると説得して仲間にする攻略に時間がかかり、走り出しが遅れる

上位組織によるコントロール:

組織間のオーバーヘッド解消は、その上位の組織がコントロールするのが最も効率的である

経営者が課題を持つ人と定例で話す場を設け、財務のトップも参加する企業がある

予算手当てが必要ならその場で決めるという柔軟な動き方をする

人員が拡充されることで「できない」が「できる」に変わり、ステークホルダー間の調整が進む

■ 4. 課題3: 肥大化して複雑に絡み合った機能

影響範囲不明なシステムの限界:

どこを直せばどこに影響するか分からないシステムでアジャイル開発を行うのは無理である

アジャイル開発は何度もソースを修正するため、都度影響調査が必要になり開発に集中できない

アーキテクチャが足を引っ張る

独立機能への分割:

影響範囲を絞り込める独立機能への分割が、アジャイル開発に最も合うアーキテクチャである

モノリシックなシステムを一足飛びにきれいに分割できるプロジェクトは存在しない

利益が得られそうな部分だけを切り離してアジャイル開発し、切り離す範囲を広げる移行が現実的である

AIによる代替の限界:

影響波及が不明な巨大システムをAIのインプットにするとトークンが爆発し、コストと処理時間がかかる

最大の問題は物忘れが激しくなり、出力結果が全く当てにならなくなることである

現場ではインプットが大きい時に要約や集約でインプットを減らしてからソースコード生成に走る

インプットを増やさないことがAI活用における重要なファクターである

影響範囲を絞って小さく開発した方が品質は良くなる

人による確認の必要性:

生成AIが生成しテストしたコードをそのまま本番環境に載せることはできない

現状のレベルでは人が必ず確認し、問題ないことを確認してリリースする

影響範囲が分からないシステムでは人の確認もできないため、機能分割が重要になる

■ 5. 3つの問題の整理と企業変革

問題の分類:

1つ目はビジネスの問題であり、ビジネスのためにアジャイル開発を使いこなす必要がある

2つ目は組織の問題であり、縦割りのオーバーヘッドを何らかの方法で解消する必要がある

3つ目はITの問題であり、保守しやすい形に機能分割する必要がある

企業変革を阻む要因:

これらはアジャイル推進の課題であると同時に、企業の変革を阻む要因でもある

分かってはいるが対策が難しい領域である

グランドデザインとロードマップ:

業務とITと組織を別々に対策するのは難しく、一緒に考えてグランドデザインを描く

描いたグランドデザインを一気に実装するのは難しいため、マイルストーンを置いて地道に対策する

グランドデザインとロードマップを引いた上で個別課題に対処するのが王道である

初めての企業には難しいため、経験者が支援する「モダナイゼーション Powered by Lumada」を提供する

■ 6. Q&A: 大企業でのアジャイル推進

偉い人の巻き込み方:

トップレベルを巻き込むにはトップに直接インプットし、危機感を持たせることが重要である

トップが危機感を持てば、その下のマネジメントに対しても指導が入る

中間マネジメント層はプロジェクトの仕組みとして参加を求め、逃げられないようにする

企画側のマインドチェンジ:

マインドチェンジは難しく、明確な答えは持っていない

企画時の負荷を下げることが有効な手になる

何十ページもの企画書を書いた後に方向性を否定されると、修正への抵抗が生まれる

エグゼクティブサマリーやリーンキャンバス1枚で軽く企画すれば、修正を受け入れやすくなる

リソース確保の現実解:

何かしら価値が出ればお金がつく

ユーザーの取り込み強化やヘルプデスクの要求への迅速な対応といったテーマを掲げる

そのテーマで機能を切り出してアジャイル開発をするのが現実ラインである

トップダウン以外のステークホルダー説得:

トップダウンでない方法で進めている例の方が多い

担当者に交渉しても断られるため、相手側のキーマンを抱き込み、そこを中心に話を進める

キーマンには常に状況を伝え、味方でい続けてもらうように振る舞う

同じ会社内ならキーマンは見当がつき、部署内で誰がキーマンか聞くこともできる

期待値が合わない状態での開始:

刀を研ぐところから始めるのはありである

アジャイル開発ができる状態になってから企画側が追いつく方が、両方同時に育てるよりうまくいく場合がある

ただし道半ばの例しか知らないため、「なし」ではないという回答にとどまる

最終的には時間をかけて期待値を合わせ、誤解を解く作戦を取る

機能分割の基準:

データモデルで分割できるようにしないと後で苦労する

トランザクションテーブルに相当するものは分割したい機能の中に入れ、単独で改修できるようにする

隣の機能のデータはインターフェース経由で自分たちのデータベースに持ってくる

隣のデータベースを直接覗かないことが基本である

定着に向けた外部活用:

うまくいっていない場合は外部の力を借りるのが最も手っ取り早い

外から連れてきた人の方が内部の人より言うことを聞いてもらえる

自走に向けた支援メニュー:

自走状態に持っていくには最低限コーチをつけた方がよい

案件がない段階向けに、1ヶ月から1ヶ月半のスクラムシミュレーション教育を用意する

体制に入ってスクラムマスターを担う場合はひと月張り付く

コーチはイベントのある日だけのスポット参画も可能で、予算に合わせて動く

うまくいかなかった例:

アジャイル経験者がキーマンとして動く案件では、自分たちのやり方が最善という前提で改善提案が通りにくい

ヘッドが2つある状態はやりにくい

日立がプロダクトオーナーを担う依頼は、顧客のビジネスを代わりに担うことになるため断っている

■ 7. 問いの転換: 意思決定と学習を測る

測る対象の転換:

アジャイルを測るのではなく、意思決定と学習を測る

「自分たちはアジャイルできているか」ではなく「正しいものを決め、正しく学び、そのサイクルを回せているか」を問う

判断力・実行力・学習力:

判断力は何を作るべきかを決める力である

実行力は決めたものをどう早く安全に作るかの力である

学習力は作った結果をどう学んで次の判断に生かすかの力である

このサイクルの質が高まり回る数が増えるほど、価値創出の総量が増える

実行力だけ強くても判断が雑なら間違ったものを作るため、3観点をすべて担保する必要がある

主張の結論:

アジャイルが回った上で成果を出すには、実行力に加え判断力と学習力を含めた組織のケーパビリティ計測が重要である

■ 8. AI時代の課題構造

AI活用の現状:

73.1%のエンジニアが業務でコーディングエージェントを使っている

5割弱のエンジニアが自分のコードの半分以上をAIで生成している

AIを入れるフェーズは終わり、AIがある前提でどう進めるかという段階に入っている

ファインディでもAI未使用期から改善期にかけてアウトプットが増加している

実行力は量では測れない:

アウトプット量が増える一方で、出したものの品質が論点になる

スタンフォード、DORA、ファインディのレポートはいずれも速度向上を示す

同時に手戻りなど品質面の悪化も示されており、スピードだけでなく品質の観点も見る必要がある

判断力と学習力の指標欠如:

実行力にはDORAやベロシティといった指標が存在する

判断力と学習力はそもそも測る指標が存在しない

判断や学習のログが残らないため、計測自体が難しい

コンテキストが渡らない実態:

AIを活用するエンジニアの約55.1%が、AIに過去の意思決定の背景を渡せていないと回答する

半数以上が、決めた経緯を踏まえてAIに渡し良いアウトプットを出すという本来やるべきことをやれていない

会場調査の結果:

意思決定や学習の蓄積度合いを5段階で尋ねたところ、会場の回答は4が1名で他は3未満に集中する

胸を張って蓄積できていると言える組織はほとんどない

■ 9. 開発資本という新しいアセスメントモデル

開発資本の定義:

判断力・実行力・学習力の3つを含めて開発組織を「開発資本」として捉える

開発資本とは、企業がソフトウェアを通じて価値を生み続けるために組織に蓄積された能力、知識、基盤である

「資本」という言葉により、蓄積されて複利で効いてくる概念として開発を見る視点に変える

3つの評価観点:

スピードは早く作って出して学べるかであり、作る速さだけでなく学ぶ速さが要点になる

クオリティはコンスタントに価値を届けられているかであり、手戻りの少なさや本番品質、保守性を見る

コントロールは変更を予測して制御できるかであり、構造・プロセス・複雑性の制御を見る

従来評価からの拡張:

従来はスピードの中でも「作る」に偏っていた

価値を最後まで届けられているか、学ぶところまで含められているかへスピードの観点を進化させる

AI時代を踏まえ、開発を制御できているかという要素も加える

開発資本が高い組織は最終的にビジネスROIに繋がる

開発資本とビジネス成長や開発者体験との相関はマーケットリサーチで検証中である

判断力・学習力の測り方:

学ぶ速さとして、過去の知見をどれだけ蓄積し共有できているかを取る

得た知見を開発プロセスに還元できているかを取る

コントロール観点で、ハーネスや開発標準の整備度、社内に残るコンテキストの活用度を取る

定性情報での取得に加え、定量での取得方法を検討中である

開発資本スコア α:

前日の7月1日にファインディチームプラス上でリリースした

各種ツールを接続すると、スピード・クオリティ・コントロールを組織単位で評価できる

■ 10. 開発資本を高めるアプローチと事例

ファインディチームプラス:

開発プラットフォームとして提供し、そのソリューションを通じて開発資本を高める支援を行う

事例1: ファインディインサイツによる判断力支援:

相談、問い合わせ、アンケート、インタビュー、社内会議といった顧客の声をデータソースとする

AIが取り込み、仮説検証・評価、ナレッジの資産化、インサイト分析を行うAIエージェントである

インサイトマネジメント機能は相談ログを取り込み、顧客の要望やペインを蓄積して傾向をまとめる

NTTドコモのプロダクトPoC開発で活用された

少数体制のPoCで現場から届くフィードバックの粒度がバラバラで、整理と優先順位付けにリソースを奪われていた

ツール活用によりインサイトを管理でき、何を作るべきかの判断ができるようになった

実行力の支援:

実行力はファインディAI+で支援する

事例2: ファインディコンテキストによる学習力支援:

プロダクト開発にまつわる意思決定をデータとして資産化する

人だけでなくAIエージェントの自律的な判断の質まで向上させる

55.1%がAIに文脈を渡せていないという課題に対するソリューションである

組織内の一次情報を取り込み、判断のコンテキストや意思決定ログを構造化して生成する

Slackから、施策の内容、理由、検討した選択肢、意思決定の理由を含む意思決定ログを残す

GitHubの情報から同様にADRを自動生成する

コンテキスト構造化の効果:

NotionやSlackの生データを直接AIに使わせる場合と、ADRとして構造化を挟む場合を比較した

構造化を挟むとAIのトークン量が減りコストが下がる

AIから出てくる回答のスコアの品質が大きく向上する

議論が短縮され、人のリソース時間も削減される

■ 11. まとめと指標運用の論点

価値創出のボトルネック:

AIで作る速さは早くなったが、手戻りや「決める」、学習が組織に残らない構造がボトルネックになる

実行力だけでなく判断と学習を開発資本として捉え、蓄積し測る視点が必要である

まず自組織の判断や学習がどこにどんな形で残っているかを棚卸しするところから始める

指標のハックへの懸念:

特定の指標のみを見ると指標はハックされる

開発資本という概念で多角的に見た上で、どう高めていくかを考える

寄与の度合いはまだ検証段階であり、アルファ版利用者からのフィードバックを求める

(2026/09/01)

DHH氏が「Omacom Foundation」を設立、Omarchy推進によるLinuxデスクトップの本格普及を目指す...

DHH氏が「Omacom Foundation」を設立、Omarchy推進によるLinuxデスクトップの本格普及を目指す。マイケル・デル、ジャック・ドーシーら著名人も出資－ Publickey

(2026/09/01)

Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド

「Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド」エリザベス・ヘンドリクソン [ＰＣ・理工科学書] - KADOKAWA

探索的テストでリスクを軽減し、自信を高めよう！

第I部では、熟練した探索者の中核となる不可欠なスキルを紹介します。探索を導くためのチャーターを作成する方法、実際に何が起こっているかを観察する方法、興味深いバリエーションを特定する方法、そして予期しない方法でソフトウェアを実行したときに期待される動作を判断する方法を学びます。

第II部では、相互作用、シーケンス、データ、タイミング、構成を変化させて探索する方法を学びます。本書では、状態モデリング、データモデリング、コンテキスト図の定義といった分析手法を、探索ツールの活用方法とともに解説していきます。

第III部では、これらの手法をソフトウェアプロジェクトの文脈に当てはめて説明します。様々な状況でスキルと手法を適用し、開発サイクルの最初から探索を統合する方法を学びます。

MEMO:

電子書籍版は出ないのだろうか？

(2026/08/31)

データマネジメント研修（デジタル庁）

データマネジメント研修（デジタル庁） - Speaker Deck

要約:

■ 1. 研修の構成と方針

三部構成の研修:

第一部はデータマネジメントの全体感を伝える話で45〜60分

第二部は12領域の紹介で50〜60分

第三部はExcelでのデータ整備実習で45〜60分

第一部の狙い:

分野の全体感、重要な概念、推進時の期待値、直面する課題を扱う

知識を身につけるというより、データマネジメントの面倒くささに共感して覚悟を決める時間とする

各部署が抱えるデータ課題やコストについても想像を巡らせてもらう

第二部の狙い:

12領域それぞれの要点とキーワードのみを伝える

1領域5分でも60分かかるため、後から自身で調べるためのキーワードを手に入れる時間と位置づける

第三部の狙い:

政府から公表されているデータを例に、機械可読性を高めるExcelの加工実習を行う

第一部・第二部で学んだ全体感と知識を元に作業し、背景や課題を想像することが目的

最後にAIの力も使ったデータ整備の事例も紹介する

研修の対象と方針:

ExcelやSpreadsheet形式でデータを扱うことが多い人を主な対象とする

データエンジニアリングに代表されるシステム知識を前提とせず、専門用語を出来るだけ避けて解説する

厳密さより分かりやすさ:

データマネジメントで普遍的に扱われる概念を優先し、AI時代で変化した点も一部伝える

各領域の詳細解説や最新情報を自分で調べられるようにキーワードを抽出して伝える

用語をただ覚えるだけの研修とせず、概念とセットでキーワードを持ち帰る研修を目指す

参考図書DMBOK:

米国のデータマネジメント団体DAMAがまとめたデータマネジメントの教科書的な書籍

ガバナンス、品質、セキュリティ等11領域に分類して解説している

現在発売されているのはDMBOK 2.0であり、AIやクラウド技術を反映したDMBOK3.0プロジェクトが発足中

DMBOKのハードル:

Amazonでも1万2000円以上、600ページ以上の大ボリュームで、訳本のためカタカナ語が多い

アカデミックな記述が多く、手にいれること、読み切ることそれぞれにハードルがある

本研修の立ち位置:

DMBOKで紹介されている概念や分類方法を元に、AI時代に伴う変化もあわせて解説する

時間も限られるため概念を伝えることを優先した内容とする

DMBOKによる整理をベースにしつつ、より実務的な視点から解説する

■ 2. データマネジメントの大原則

データを資産として考える:

データマネジメントにおける最も基本的な原則

資産だからこそ、活用方法を考え、優先順位を決め、盗まれないように守る活動が必要になる

置いてあるだけの資産:

ただ置いてあるだけの資産は価値を産まず、管理コストやリスクだけが増えていく

その資産は誰にとって価値があるか、その価値をどう引き出せばいいかという問いに答える必要がある

データマネジメントの定義:

データという資産の価値を最大化する活動全般を指す

ざっくり言えば「資産管理に必要なこと」のデータ版と捉えればよい

データ固有の特性:

一般的な資産と異なり、電子情報であるデータはコピーが容易である

使っても価値が減らないという特性がある

■ 3. データマネジメントの12領域

Aikenのピラミッド図:

DMBOKにおいてデータマネジメントは12(表現によっては11)の領域に分かれるとされている

Aikenのピラミッド図は領域が何であるかを示すと共に、各領域の相互関係を示す

頂点にあるデータ分析:

頂点にあるのがデータ分析であり、データから価値が取り出される場所となっている

頂点を支える各領域のデータマネジメントが不十分だと、取り出せる価値も不十分となる

推奨される取り組み順:

色分けは推奨される取り組み順であり、青色、オレンジ色、緑色、赤色の順が論理的で良いとされる

扱うデータを統合して構成を決め、置き場所とセキュリティを確保する

全体図と説明書、品質基準などを定める

基盤システムを用意してルール、ドキュメント、管理方法を定める

データ分析を行なって価値を取り出す

価値を生む場所の限定:

データが価値を生むのは頂点のデータ分析のみである

準備万端でデータ分析できれば理想的だが、現場では中々そうはいかない

課題は頂点から降りてくる:

多くの場合、データは分析・活用されたとき初めて課題が露見する

価値を取り出そうとして上手くいかなかったとき、課題として頂点から降りてくる

そのため現場では、頂点のデータ分析から基盤へという順番で取り組みが進む

現場から出る課題の例:

データが更新されていない、個人情報が漏れていないか、このデータは何のためにあるのか

営業と製造のデータが紐付かない、あのデータはどこか、分析のコストが大きい

■ 4. 花形のデータ分析と裏方のデータマネジメント

利益に直接繋がるデータ分析:

需要予測、パーソナライズ、投資最適化など、組織の利益に直接貢献しうる知見を取り出せる

間接的な利益貢献:

データマネジメントはセキュリティやデータ品質などを担う

データ分析を安心・安全・簡単に実施させることで間接的な利益貢献を行う

地味な個別活動:

全体像を書き出す、メタデータを拡充する、ドキュメントを体系的に管理する等が中心となる

個別のデータマネジメント業務は地味で目立たないことが多い

地味な活動の積み重ねで「安心・安全・簡単にデータを使える状況」を作るのがデータマネジメント

■ 5. AI時代におけるデータマネジメント

AIによるデータ需要の発生:

生成AI(LLM)はデータの意味を含むあらゆる情報を解釈対象とする

従来のログデータや統計データに加え、定義書、活用事例、記録日時なども対象となる

社内ドキュメント、監査記録、利活用ポリシーなども対象となる

あらゆる情報が生成AIのインプットとなり、AIの出力精度に影響するようになった

サイレントな悪影響:

AI活用の広がるスピードに、データ品質の向上やデータガバナンスによる統制が追いついていない

品質の低いデータが参照されたり、逆に機密情報など参照すべきでないデータが学習される

根拠不足のままの判断やハルシネーションでの情報補完など、気づきにくい悪影響が生まれている

AI-Readyデータ:

AIが安心して学習・推論に使えるデータを指す概念として登場した

AIが読めるような機械可読性、意味の補完に役立つメタデータ、高い品質、適切な権限管理を備える

既存データをAI-Readyな状態に整備する必要性が高まっている

大規模化する基盤部分:

AIという巨大なデータ利活用需要に対し、それを支えるピラミッドの基盤部分も大規模化が求められる

特定部署で実施されていたデータ活用は、全ての部署がAI活用と名前を変えて実施するようになった

組織構成、人材リソース、各部署の保有データ、活用事例、社内ドキュメント等が対象となる

AIによりデータの価値が更に高まり、データの資産管理であるデータマネジメントの価値も再認識された

■ 6. 行政機関の動き

デジタル庁のガバナンス指針:

2025年6月20日に「データ・ガバナンスガイドライン」を公表している

4つの柱として越境データの扱い、セキュリティ、総合(マチュリティ)、AIへの対応指針を挙げている

組織間、産業間、国境間でのデータの取り扱いも含めた経営層向けの指針を示している

IPAのデータマネジメント試験:

情報処理技術者試験にデータマネジメント試験(仮称)が2027年度から新設される

ITパスポート試験の次のステップの試験として位置づけられ、サンプル問題も公表されている

デジタルスキル標準(DSS)にもデータマネジメント類型を追加している

データ利活用制度の基本方針:

デジタル行財政改革会議が2025年6月13日に「データ利活用制度の在り方に関する基本方針」を公表した

データとAIの社会実装に向けて、データを社会の共通資源として再定義する

トラスト基盤の構築や個人情報保護法の更新を通じて透明性を確保する

先行する個別分野でデータ連携基盤を整備し、政府内では行政データの品質向上に取り組む

■ 7. データマネジメント推進の難しさ

ボトムアップの限界:

現場の課題解決からスタートして適用領域を広げても、ボトムアップの取り組みはいつか限界を迎える

基盤領域には全社的な視点、組織のルール策定、業務フローの変革が必要になるためである

エンジニア部署が直面する課題:

ビジネスサイドとの接続不足により、最新のビジネス状況とデータを紐づけるコネクションが弱い

要件定義の乖離により、ビジネス要求を適切なメタデータやデータ品質基準に落とし込めない

統率力の不足により、全社的なデータガバナンスを牽引するリーダーシップを発揮しにくい

ステークホルダー調整の課題:

データはステークホルダーが多くなりがちである

関連部署との調整そのものが大きな課題となる

トップダウンの正論の弊害:

トップダウンから計画ばかりを打ち下ろしても、データマネジメントは進まない

現場の状況を顧みない計画は、結局は喫緊の課題解決に結び付かない

人的・時間的リソースを投じても成果が出るのが遠い未来になりがちである

結果としてデータ利活用の現場やデータ関連部署を疲弊させてしまう

実現可能性を見極める力:

現場でのデータマネジメントの実装、あるいは移行計画を現実的に組み立てる必要がある

実現可能性を見極める力が必要となる

ありがちな推進パターン:

トップダウンで理想像を立て、生成・保存・活用などのフェーズに応じた管理ポリシーを定める

各部門・領域の現在のデータ管理レベルをポリシーに従って計測し、理想状態との乖離を計測可能とする

生成から利活用までのサイクルが比較的短い領域で実践し、成功事例を横展開する

基本的な流れは全社プロジェクトのPoCと同じである

王道でも変わらない現実:

王道の流れを踏んでも、数年後にあまり変わっていないデータ環境がそこに残ることがある

やり切ることの難しさ:

ルールを打ち立てることも小さく始めることも、それ自体が大変な偉業である

しかしデータマネジメントは放置しても勝手に広がっていくことはない

現場への適用を推し進めるリソースや、推進力の源泉となる要因もあわせて考える必要がある

データに関わる全てのステークホルダーに影響するため、一過性の盛り上がりでやり切ることは難しい

計画の途中でリソースが不足したり組織の優先度が変われば、推進力は低下し停滞してしまう

だからこそ中長期でゴールまでの計画を描く必要がある

上下左右に繋げる役割:

中長期の計画を実行し続けるには、トップダウンの支援とボトムアップの事例創出が必要となる

加えて横方向の協力者も必要となる

経営層など組織の意思決定者から計画の承認とリソースを得る

データマネジメントの実践で目にみえる成果を示す

エンジニアやビジネス現場など他部署との連携を築く

繋ぎ役の必要性:

これらの部署はサイロ化していることも多い

だからこそ誰かが意識的に「繋ぎ役」を担い、組織全体としてデータマネジメントを推進する

同時に、理想の状態に向けて業務フローの変革そのものをマネジメントしていく必要がある

完了は運用の始まり:

データマネジメントは、着手や完了そのものより継続することの方が難しい

データ品質やメタデータなどビジネス状況を反映すべき領域はメンテナンスし続ける必要がある

そのメカニズムそのものを仕組み化しなければならない

成果物の陳腐化:

全体図、パイプライン、ドキュメント、品質基準は完成した瞬間から陳腐化が始まり劣化していく

従来の情報システムと同じことだが、データは情報システム以上に変化のスピードが速い

中長期の計画に加え、状況を把握し現場の運用に繋げ続けるためのモニタリングが欠かせない

現場からの期待:

データ利活用の現場からの期待は「データは使えて当たり前」という素直な欲求であることが多い

利活用時の「できない、わからない」という不によりデータマネジメントの課題が注目される

逆に完璧に機能しているときはデータ利活用に障害はなく、データマネジメントは注目されない

課題が見当たらないときは、完璧に利活用できているか誰も利活用していないかのどちらかである

■ 8. 物理インフラ事業との類似性

既存インフラと同種の難しさ:

電気・水道・ガス・通信といった既存インフラが「動いていて当たり前」とみなされることと似ている

データは単なるIT部署の持ち物ではなく、ビジネスを支える社会インフラである

そのために生まれる課題も社会インフラと類似している

終わりのない維持管理:

レポートの数値が正しい、システム間でユーザーデータが連携されている状態は当たり前とされる

これを支えるにはパイプラインの監視、メタデータの更新、データクレンジングが欠かせない

物理インフラの断水や停電が社会活動を麻痺させるのと同様である

運用が止まれば業務停止や意思決定のミスといった致命的な障害を引き起こす

見えにくい投資対効果:

データ基盤、マスターデータ管理、データガバナンス体制の構築には多くの時間とコストがかかる

それ自体が価値を生むわけではなく、データが利活用されて初めて利益が生まれる

そのため投資対効果の説明が難しい

送電網や水道管の敷設と似ており、老朽化対策の保守費用の合意を得にくい点も共通する

説明が難しいからと投資対効果の提示を放棄せず、恩恵を丁寧に測定し示すべきである

レガシーからの段階的移行:

24/365で動作しているITシステムをデータ利活用しやすい形に移行・統合する場面がある

ビジネスを止めずに段階的に移行する綿密な計画が必要となる

都市機能を維持しながら古い水道管を少しずつ刷新していくことに似ている

標準化への抵抗:

全社で統一したデータ定義を進めようとすると、部署ごとの独自規格が障壁となる

「今までの運用を変えたくない」という心理も障壁となる

■ 9. 第一部のまとめ

難しさの要約:

データマネジメントはトップダウンとボトムアップのバランスが重要

ステークホルダーが多く、データ関連部署からビジネスの現場まで横断的な調整能力が求められる

一過性の盛り上がりだけで整備しきることは難しく、中長期の計画と継続的なリソース確保が必要

「データは使えて当たり前」の状況を実現するために維持管理や運用設計を考える必要がある

これらの調整や業務をこなせる人材にデータマネジメントの未来はかかっている

重要性の真の意味:

データを資産として捉えて資産管理を考えるのがデータマネジメントの根幹

AIという巨大なデータ利活用者の登場によって注目されるようになった

物理インフラと比べて耐用年数は短く、状況は刻々と変化し、無秩序になりやすい難しさがある

データ利活用を行いたいヒトやAIに対して「当たり前」を「提供し続ける」ことが重要な価値

横断的な調整能力、中長期の計画、リソースの確保、保守運用の設計など必要な要素は多い

■ 10. データ分析

頂点からの説明順:

本研修ではピラミッドの頂点から順に説明する

データ利活用時に課題が表に出てきやすい順であり、想像しやすいためである

全12領域を同熱量で語らず、特に詳しく伝えたい領域を詳細に解説する

データ利活用の範囲拡大:

従来のデータ分析は、過去のデータから何が起きているかを把握し将来を予測するものだった

AI時代にはコンテンツやプログラムを生成することもデータ利活用に含まれる

非構造化データの扱いやすさ:

ビジネスにおいて分析対象とされにくかった非構造化データがAIによって扱いやすくなった

組織内の文書、画像、会議音声や録画はAI自体の学習に利用される

AIの回答精度を高めるための情報源の拡張(RAG: 検索拡張生成)としても活用され始めている

求められるスキルの変化:

AIによりデータ加工・集計や統計学等の技術的なスキルの重要度は下がった

代わりに問いを立てる力や検証力、事業理解、ストーリーを語る力など概念的スキルの重要度が増した

何が知りたいか:

ビジネスの状況に対して適切な問いを立てられる力が求められる

「何がわかればビジネスに貢献できるか」を判断するには事業に対する理解が必要となる

AIによる分析成果物が増える中、それを批判的に検証する力も大事になっている

「なぜそれを知るべきなのか」を意思決定者に伝えるストーリーテリングの能力も求められる

分析に足るデータの存在:

問いを立てた後は、それを解くためのデータが組織内外に存在するかを見極める必要がある

問いが良くてもデータが存在しなかったり品質が悪ければ、分析結果は意味をなさない

データサイエンティストの作業時間の8割は探索やクレンジングなどの整備に費やされるという説がある

データは「あるかどうか」ではなく「使える品質かどうか」と「アクセスできるか」が重要となる

活用可能性の判断:

データがあることと使えることは別問題である

機械可読性や鮮度、表記ゆれといったデータ品質を判断する必要がある

複数のデータを組み合わせる場合は、データ同士が連結できるかも見極める必要がある

制度面では個人情報やプライバシー、セキュリティの観点から特別な権限が必要な場合もある

AIによる分析では、機密データを誤って読み込ませないためのガードレールとデータ整理が重要となる

分析者に求められるもの:

「正しく理解し、正しく問う」ための経験とセンスが求められる時代となった

■ 11. DWH & BI

データウェアハウスの定義:

データを収集・蓄積・分析するための基盤であり、「データ分析基盤」は多くの場合これを指す

BigQueryやSnowflakeなど、パブリッククラウドの分析基盤製品もこれにあたる

構造化ログデータや業務用データベースからデータを集約・加工・集計・分析するシステム基盤である

ダッシュボードなどで可視化するための基盤でもある

関連する領域:

データ統合と相互運用性、ストレージ&データ運用、モデリング&デザインと密接に関わる

セキュリティ、データ品質とも密接に関わる

これらの領域で検討した内容が実際のシステムとして具体化されたものがデータウェアハウスとなる

集めるだけでは不十分:

データが集まっていればよいわけではない

統合され、整理され、拡張性やアクセス管理を備える必要がある

データを集約しただけの巨大なExcelはデータウェアハウスではない

BIの位置づけ:

広義にはデータから示唆を得る行動すべてがBIだが、実用上はBIツールと捉えられることが多い

多くのBIツールはExcelファイルなど単一のデータに接続して使うこともできる

様々なデータが蓄積・連携されたデータウェアハウスと接続することで本領を発揮する

ベクトルデータベースの統合:

AI活用にはテキスト・画像・音声・動画などの非構造化データも求められるようになった

非構造化データをベクトル化して蓄積するベクトルデータベースをDWHに統合する動きが出ている

AIが参照できるデータソース(RAG)として活用する動きが出てきている

利用者の変化:

DWHの最たる利用者はデータ分析者だったが、AIが自然言語から機械言語に変換できるようになった

人間の自然言語で指示を受けたAIが、DWHから直接データを取り出す方法が生まれた

AIによる変換では指標の計算方法が毎回ぶれるリスクがある

集計方法やビジネス用語を定義した「意味層(セマンティックレイヤー)」を組み込み精度を高めている

分散型のアプローチ:

中央集権的な一つの分析基盤に集約せず、各データソースに分散させたまま集計・分析する手法も登場した

データファブリックは、データを分散させたまま仮想的に統合環境を提供する方法である

データメッシュは、管理権限を移譲し標準化された共通の連携機能とルールを持つ方法である

いずれもデータソースごとに適用できるルール・ポリシーの制定と、それを支えるガバナンスが重要となる

DWHの進化:

ただの巨大で高速なデータベースではなく、AIにデータを提供するインターフェイスとして進化している

■ 12. マスターデータとコード

マスターデータの定義:

組織内における唯一の、一貫した、信頼できるデータを指す

顧客マスター、商品マスター、店舗マスターのように現実のビジネス対象ごとに作成される

一度登録されれば頻繁には更新されない

コードの定義:

「1: 男性, 2:女性, 3:その他」「01000: 北海道, 02000: 青森県」のように選択肢を定義したもの

実務上はマスターデータとコードを同じものとして管理されることも多い

重要な問題意識:

「同じ実体を指すデータが複数あるとブレる」という問題意識が重要である

同じユーザーが複数のIDで登録されると、システムは別人として扱ってしまう

現実の状態を正しくデータに反映するために、マスターデータとコードは厳密に管理する必要がある

ビジネス現場との連携:

顧客マスターでは、営業部門は案件発生や見積もり時点で顧客として登録したい

一方で経理部門は請求書発行時点で顧客としたいといった定義のブレが生じる

組織全体として「顧客とは、いつ・何を指すのか」を統一する必要がある

マスターデータ管理にはビジネスへの理解と、ルールを決めるオーナーシップが求められる

変更の慎重さ:

マスターデータとコードは組織内の様々な箇所から参照される「信頼できるデータソース」である

安易な変更は事故のもととなる

設計段階から「将来変更が起こりうるか」を想定しておくことが望ましい

「1:令和」「2:平成」「3:昭和」というコードは次の年号が登場すると困ることになる

未知の値にどのコードを振るかを、あらかじめ意識すべきである

守るべき条件:

唯一の正解であること、一貫していること、最新であることが期待される

マスターが信用できないとき、データ利活用者は自分だけのマスターデータを作り始める

結果として組織全体の唯一性が崩れる

誤りや掲載場所ごとのブレ、古い情報による陳腐化を防ぐ定期的な保守点検が必要となる

マスターデータの位置づけ:

データの量としては少ないが、特に重要な資産として管理する

■ 13. ドキュメント管理

従来のドキュメント管理:

組織内のマニュアルや文書・画像・音声・動画といった非構造化データを対象とする

コンプライアンス維持のための分類・ラベリング(メタデータ付与)を行う

キーワード検索への対応、閲覧権限の管理などを行う活動だった

AI時代の位置づけ:

非構造化データは「AIの重要なインプット」「データウェアハウスの一部」として存在感を増している

人間が手作業で行なっていたラベリングも、AIが文書内容を理解して分類する効率化が進んでいる

検索面でもAIが文書の意味を解釈して適切な文書を返せるようになってきた

「有給の取り方」で検索して「社内勤怠マニュアル」が返るような検索が可能になっている

構造化データとの組み合わせ:

非構造化データを文書ストレージに保管するだけでなく、ベクトル化してDWHと統合する動きがある

文書の内容は業務システムのログなど他の構造化データと組み合わせられる

AIによる分析の背景情報の補強に役立てられる

ドキュメント管理の位置づけ:

ただの裏方事務ではなく、AIのための重要なデータ整備業務となっている

■ 14. データ統合と相互運用性

データ統合の定義:

組織内に散らばったデータを一箇所に集めて統合データ基盤を作る取り組み

各システムからデータを抽出・変換・取込するプロセスが必要となる

相互運用性の定義:

システムAとシステムB間でデータを相互にやり取りできることを指す

標準化された共通規格でやり取りできるのが理想である

データを変換すれば相互にやり取り可能な場合も、相互運用性があると言える

AI時代の相互運用性:

システム間だけでなく、AIとシステムの間の相互運用性も課題となる

データがただ保管されているだけでなく、人間の利用とAIの利用の双方を考えて統合・管理する

エンジニアリング要素:

ビジネスが求める形式とタイミングで提供できるよう、抽出・変換・取込(ETL)の仕組みを整える

クラウド上で構築することも多く、クラウドの知識も踏まえてシステム全体を設計する必要がある

ビジネス要求通りに統合・管理できているかの計測にはデータ品質が用いられる

繋げるためのキー:

データは意識して設計しなければ繋がらない

WebアクセスログとアカウントIDを取得しても、重ね合わせる共通のキーがなければ繋がらない

キー以外にも、データの粒度や取得時点のズレが繋げる際の課題となる

繋がるべきデータが繋げられる構造になるよう、事前の設計と調整が重要である

AI向けの機械可読性:

データ統合基盤を利用するのは人間だけでなくAIも同様である

社内ドキュメントなどの非構造化データは元々人間向けに作られている

そのためAIが読み込めない、あるいは非効率にしか読めない場合がある

既存文書を機械可読な構造に変換すると同時に、新規文書を最初からAI向けの形式で作成する必要がある

■ 15. データストレージ & データ運用

データにも運用がある:

データを生成・収集・蓄積し、利活用に繋げるまでの一連の流れは保守・運用する必要がある

使いたい時に使えることの保証、障害時の復旧、素早いアクセスのための技術的な活動が求められる

ライフサイクル全体の管理:

生成・取得から保存・加工・活用、そして最後の破棄までを考える必要がある

忘れがちなのが「破棄」であり、データは腐らず簡単にコピーできるため総量は際限なく増えやすい

使われないとわかっているデータを持ち続けることは、コストとリスクの両方を増加させる

データの削除ポリシーを定め、適切にライフサイクルを管理する必要がある

データの流れの俯瞰:

個別システム単位で保存場所を管理するだけでなく、データの流れ全体を俯瞰する必要がある

「どこから来て、どこに保存され、誰がアクセスできるのか」を管理しなければならない

物流センターの運営に似ており、データも適切に整理し最適な物流網を構築する必要がある

目立つ領域ではないが、物流網のようにデータ利活用の現場を支えている

■ 16. データセキュリティ

資産とリスクの両面:

データは活用すれば価値を生む資産だが、漏洩や不正利用で組織に被害をもたらすリスクでもある

正当なアクセス権を持つ人・システム・AIだけが承認された目的で利用できるようにする

そのためにポリシー策定、権限管理、監査モニタリングを行う必要がある

個人情報とプライバシー:

個人情報に加え、宗教・病歴といった要配慮情報やプライバシー関連情報の管理が必要となる

適切に管理しなければ組織に重大なインシデントをもたらしかねない

「リスクは、それをリスクと認識していない時が一番大きなリスクとなる」という意識が重要である

ライフサイクル全体を管理し、透明性を確保する必要がある

AI時代の脅威:

外部からの脅威やシステムの脆弱性への対策に加える必要がある

組織内の管理外でのAI利用(シャドーAI)による意図しないデータ学習への対策も必要となる

アクセス者が人間・AI問わず適切な権限を持っているかを常に確認する仕組みが求められる

法改正への追随:

令和8年に成立した改正個人情報保護法では、統計作成目的での要配慮個人情報の取り扱いが緩和された

法改正によってセキュリティ基準が変わりうる

法務部門等とも連携して関連法令を把握し、セキュリティポリシーを適時見直す必要がある

データのリターンだけでなく、リスク面も正しく見据えて時代に即した守りを固める

■ 17. データモデリング & デザイン

データモデリングの定義:

データベースあるいはRDBにおいて、ビジネス対象をどのようにデータ上で表現するかを考えること

DWH & BIやデータ統合と相互運用性と同様、データエンジニアリングとしての色が強い領域である

狭義の意味:

収集・統合したデータ群をどう組み合わせれば使いやすいデータになるかを考える

「関連性」に着目した技術領域を指すこともある

5W1Hによる整理:

「顧客が(Who)ある製品を(What)先月に(When)ECサイトで(Where)注文して(Why)発注書を作成した(How)」と考える

顧客・製品・時点・場所・取引タイプ・発注書IDという一連のデータの組が見えてくる

情報の関連性をまとめたデータの組をデータモデルと呼ぶ

多様なアプローチ:

クラウド技術を取り込みつつ、非構造化データを含む大量のデータに対応する手法が開発されている

アジャイル型、蓄積して用途を後から決める型、分散型など各組織がそれぞれの手法を実践している

設計の影響範囲:

データの設計はデータを収集・加工・統合する際の効率にも影響する

地味ながら重要な領域である

■ 18. メタデータ

メタデータの定義:

あるデータAが何なのかを示す、Aを説明するためのデータα

データマネジメントの中でも最重要とも言える領域であり、AI時代にさらに重要性が増している

ログの発生時刻や対象システム名、どのビジネスで使われているかを示すドキュメントも該当する

個人情報かどうかを識別するラベルもメタデータである

イメージとしては図書館の分類目録が近い

メタデータなしには大量のデータを管理できないため、メタデータそのものも適切に管理する必要がある

人間向けの従来用途:

システムがデータに付与した周辺情報、データベース上の説明文、組織内メンバーによるFAQが該当する

データ同士の関連性を記した「リネージ」による障害原因の特定にも役立つ

個人情報を含むデータへのタグ付けによる権限管理など運用面でも役立てられている

AIにとっての効果:

AI時代にはAIがメタデータの最大の消費者となる

メタデータはAIに文脈(コンテキスト)を与え、AIが自律的にデータを取捨選択できるようにする

AIの想定外の挙動を防ぐためのガードレールとしても機能する

メタデータがない状態は、分類や目録が存在しない図書館と同じである

その場合AIは、棚の中の本を一冊ずつ全部読むような非効率な動きを強いられかねない

限られたAIリソースを効率的に使い精度を高めるには、適切なメタデータが欠かせない

アクティブ・メタデータ:

AIが十分な推論能力とコンテキストを持てば、データをスキャンしてメタデータを自動生成できる

組織のポリシーや利活用事例をコンテキストとして持つAIが自動で生成・更新し続ける仕組みが注目される

最終的な人間の承認プロセスは必須である

AI自身の利用状況までメタデータ生成のソースとできる点が、注目される理由である

成功の鍵:

「十分な量と質を備えたメタデータを高速に提供できるか」が組織のデータマネジメント成功の鍵を握る

■ 19. データ品質

データ品質の役割:

収集・加工・利活用の中で、利用者が求める水準を満たさないデータが出てくる

更新日付の古さ、不正確なデータの混入、データの重複などが価値抽出に悪影響を及ぼす

こうした状態は「Garbage In, Garbage Out」と揶揄される

利用者の求める水準をデータが満たしているかを測るのがデータ品質の役割である

利活用における問いに答えられるデータこそが「品質の良いデータ」となる

正しく定義・測定するには、利用者側のニーズを正しく把握する必要がある

簡易な評価軸:

データはどこから来たのか、正しいのか、使えるのか、使いやすいのか、守られているかが評価軸となる

計測されたデータ品質はメタデータの一部として管理される

ISO 25012による規定:

データ品質の評価軸は国際標準のISO 25012で規定されている

「データは正しいか(完全性、正確性、精度、一貫性)」が含まれる

「新しいか(適時性・最新性)」「使える状態か(可用性、アクセシビリティ、回復性)」が含まれる

「安心できるか(機密性、信憑性、追跡可能性)」が含まれる

「使いやすいか(標準適合性、理解性、効率性、移植性)」が含まれる

利用者の求めに応じてこれ以外の評価軸が必要になることもある

AIによる重要性の増大:

従来のデータ利活用でも分析精度に直結する要素だったが、AI活用の広がりで認識が強まった

AIの推論は途中経過がブラックボックス化しやすく、間違えた原因の検証・修正が難しい

だからこそ最初から高品質なデータをAIに与えられるよう、データ品質を高く保つことが求められる

何でも与えればよいわけではなく、メタデータと品質を組み合わせた取捨選択も重要である

指標と目標の取捨選択:

すべてを高水準に高めればよいわけではなく、セキュリティと似ている

ビジネスの要求に応じて必要な品質を定義し、測定・監視・改善し続けることが求められる

リアルタイムな利用を求めるなら最新性を優先すべきである

「データが使いにくい」という声が多いなら標準適合性や理解性を高めるべきである

常に利用者と、求める品質のレベルをすり合わせることが重要である

注目される領域:

データ品質はメタデータと共に、AI時代において最も注目されるデータマネジメント領域である

■ 20. データアーキテクチャ

データアーキテクチャの定義:

データがどのような目的・用途でビジネスと接続されているかを書き出すもの

サイロ化の防止:

データは組織内の一箇所で生まれるわけではなく、各部署のシステムや外部から複数の箇所で流入する

利活用も複数の部署や関連組織にまたがる場合がある

生成・利活用それぞれでサイロ化が起きるのを防ぐ役割を担う

活用現場と生成現場を橋渡しする「地図」となる

川の流域管理との類似:

雨が川となり、どこで別の川と合流するかを管理することに似ている

最終的にどこまで流れ、どのように利用されているかを管理するのと同様にデータのフローも管理する

作成方法:

組織内の活動を「ビジネス」「データ」「アプリケーション」「インフラ」等に分けて図示する

エンタープライズ・アーキテクチャ(EA)の枠組みを流用することが推奨される

AI時代の役割:

データとビジネスの関連を示す「文脈」そのものとしてAIに参照される

特にメタデータやデータ品質で触れたような監視目的のAIにとって重要な文脈となる

分散型のデータ基盤を採用している場合はデータフローが細分化しやすく、重要性はさらに増す

データの「流域」を書き出しておくことで、全体を俯瞰した文脈が得られる

■ 21. データガバナンス

データガバナンスの定義:

ニュース等ではプライバシーやセキュリティ面を指して呼ばれることも多い

本来はデータ分析からアーキテクチャまで、これまで紹介したすべての領域を監督する活動である

監督者の役割:

野球の監督と同じく、リソース(ヒト・カネ・データ)をいつ、どこに配置するかを考える

全体方針を打ち出す役割を担う

監督のいない野球チームが次第に連携を失うように、ガバナンスなしでは局所最適化が進む

結果として全体のバランスを失ってしまう

常に全体を俯瞰してポリシーを定める

状況をモニタリングし、取り組みの優先度を決め続けなければならない

組織体制の課題:

最も全体的な視点が求められる領域であるため影響範囲は大きい

影響範囲に見合った組織体制を築けるかどうかが最大の課題となる

経営企画やホールディングス組織など、全体の意思決定者に近い位置に組織を置くことが望ましい

ボトムアップで始めるのは、一選手がフィールドに立ちながら監督を兼任するようなものである

指示は行き渡らないか、無視されてしまう

AI時代の難易度:

監督役に求められる責務そのものは変わらない

内部ではAI利用に関するアクセス権限の再編が必要となる

外部ではAIに関わる法制度・規制の変化への対応を検討し、組織全体に行き渡らせる必要がある

そのためデータガバナンスの難易度は相対的に上昇している

「全体を見渡して指示を出せるだけのポジションを作れるか」が一番の難所となる

■ 22. 第二部のまとめ

12領域の性質:

技術的側面が強い領域、ビジネスの側面が強い領域、その両方を横断する領域がある

ピラミッドの下部に行くほど全体的な視点が求められる

AI時代においては特に重要な領域となる

調整の不可欠さ:

真にデータマネジメントでインパクトを出すには組織内外との調整が不可欠である

一人で全てを担うことはできず、領域ごと任せられるパートナーを見つける必要がある

■ 23. Excelでのデータ整備実習

実習の位置づけ:

既存のExcelデータについて、AIにとって読みやすい機械可読性を確保する作業実習を行う

Excel形式であっても、内部のセル構成によって機械にとっての読みやすさは大きく変化する

実習の目的:

機械可読性の基準を知ること

データ整備を人力で実施するコストを知ること

「機械にとっての問題は何か」「根本的な原因は何か」を考えること

「所属部署のデータに当てはめるとどうか」を考えること

特に考察が重要であり、苦行を経てデータマネジメント的な解決策を自ら考えてもらう

機械可読性の定義:

AIを含む機械処理の際、事前のデータクリーニングを挟まずに集計・分析等ができるかの度合い

行政データのルール:

「行政データにおける機械可読性に関するルール」が公表されている

複数のチェック項目をレベル分けし、レベル1を最低限遵守すべき内容と位置付けている

レベル1の項目:

1Sheetに複数の表が掲載されていないか

データ本体と無関係な情報がないか

データが空白行で分断されていないか

スペースや改行等で体裁を整えていないか

セル結合をしていないか

レベル2の項目:

データ内で項目名等の省略をしていないか

各列が一意に識別可能な項目名を持っているか

数値データは数値属性とし、文字列を含まないこと

レベル3の項目:

項目名行から始まり、次行からデータ入力されているか

データの単位を記載しているか

データが縦持ち形式になっているか

実習課題:

経済産業省の石油統計の時系列表から、任意の月のExcelファイルをダウンロードする

ルールをベースに方針を立て、機械可読が可能と思えるレベルまでExcelの構造を修正する

目安は、どの表でもExcel機能だけでグラフ描画ができる程度である

考察課題:

AIがこのデータを読むとき、読み間違うとしたらどこかを考える(データ品質の特定)

データ公開の目的と手段は一貫しているかを考える

機械可読可能な状態で公表するとき、どのような調整を行い業務を変えるべきかを考える(データガバナンス)

時間があれば所属部署が所持しているデータについても機械可読性を評価する

■ 24. 整備後のデータ例

整備後の状態:

表を整理することで、Excel機能だけでグラフ描画ができる状態になる

もう一工夫した場合:

種別、更新年月、指標レベル、親指標といった列を追加する

単一のExcel内のレベルだが、これもメタデータの一部である

指標間の関係性を記述する部分にはデータモデリングの要素も含まれる

個別のデータファイルレベルでも、使いやすさや処理のしやすさを考えることが活動につながる

■ 25. AIを使ったデータ整備の事例

チェックツールHarunobu:

「行政データにおける機械可読性に関するルール」の準拠状況をチェックするツールとして公開している

CSVまたはExcelファイルに対し、ルールに記載されたチェック項目を判定するアプリケーションである

ルールに付随するサンプルアプリという位置付けで、自動判定が難しいルールについては未対応である

ローカルで動作させるにはpython実行環境とパッケージインストールが必要である

ローカルサーバーで立ち上がるUI画面のほか、単独プログラムとして他システムに組み込める

Harunobu自体はAIなしの機械的な判断のみで動くプログラムとして成立している

AIに接続しなくても実行環境さえあればどこでも動く

判定結果の例:

石油統計のExcelはレベル1・2・3すべてで重大ルール違反により強制0点となった

1Sheetに17個のテーブルが検出されるという致命的な違反があった

データ範囲内のテーブル間空白行8件、テーブル外のセル13件が検出された

体裁用スペース・改行5件、1件のセルでの複数データが検出された

AIとの組み合わせ:

ガバメントAI「源内」にHarunobuを実行させ、採点結果.jsonを得る

採点結果.jsonを元に、Excelを加工して機械可読性を向上させるscriptを作成させる

そのscriptを実行して、加工したExcelのCSVファイルを作成させる

ツール名の由来:

Harunobuは江戸時代中期の浮世絵師鈴木晴信に由来する

錦絵を大流行させた浮世絵師であり、美人画で人気を博し浮世絵の発展に貢献した

複数の色の版を使うことから、複数のルールを適用して機械にとって美しいデータを作る意味を込めた

紙を入れて版を刷ることから、神(Excel)を入れて綺麗なデータを作るという意味も込めた

近所には平賀源内が住んでおり、友人として親しく共に錦絵の工夫をしたという

■ 26. 全体まとめ

第一部の持ち帰り:

全体概要と、推進することの難しさ、直面する課題を紹介した

研修後、所属組織の課題を解決するために必要なコストとリソースについて考える

必要な気合いと覚悟の程を推し計る

第二部の持ち帰り:

12領域を頂点から底辺に向けて順に解説した

どの領域も少なからずAI時代の影響を受けている

所属組織ではどの領域から始めるべきか、それは何故なのかを論理的に導き出す

第三部の持ち帰り:

Excelの機械可読性について作業実習し、AIやルールによって省力化する事例を紹介した

ここで触れたのは1領域のさらに一部分に過ぎない

実践で立ち塞がる更に多くの課題を、楽に解決するための思考を続ける

最低限持ち帰ってほしいこと:

「気合いと覚悟」「ピラミッドとキーワード」「楽する道を探すこと」の3点

(2026/08/31)

DDDやClean Architectureでフレームワークを上書きしてはいけないと私が思う根拠

DDDやClean Architectureでフレームワークを上書きしてはいけないと私が思う根拠 | SEAHAL DEV TIPS

要約:

■ 1. 主張の骨子

成熟したWAF上でのDDD全面適用に反対:

Ruby on RailsやNext.jsのような成熟した（メタ）フレームワーク・WAFを採用しながら、DDDやClean Architectureを全面適用する設計には基本的に反対する

DDDやClean Architecture自体が悪いわけではない

WAFを選んだ時点で受け入れたはずの設計思想を上書きしてしまうことに違和感がある

全面適用を唱える者への評価:

メタフレームワークを使いながらDDDやクリーンアーキテクチャを唱える者は、基本的に政治がやりたい可能性が高い

上司の立場なら拒否し、同僚の立場なら同意しないことを基本マイルールとしている

LaravelやRailsのような成熟したWAFに勝てることは滅多にない

■ 2. 反対する理由

エコシステムの恩恵の自壊:

WAFが持つ規約、拡張点、周辺エコシステムの恩恵を自分たちで破壊することになる

Railsを構成する要素:

Active RecordやMVC、Convention over Configurationまで含めてRailsである

過剰な包み込みの弊害:

Repository、UseCase、独自Entityで何重にも包み始めると、Railsを使っているのにRailsを避けるためのコードが増えていく

コスト増大とWAF採用の無意味化:

プロジェクトの学習コストも保守コストも上がる

WAFを採用した意味そのものが薄れる

■ 3. DDDが有効な場面

限定的に有効なケース:

複雑なドメインの境界を整理する場合

外部システムとの依存を切り離す場合

WAFでは扱いにくい中核ロジックを独立させる場合

適用範囲の制約:

その場合でもWAF全体を別の思想で包み直してはいけない

必要な場所だけに限定して利用すべきである

■ 4. 原則

郷に入れば郷に従え:

WAFを採用した以上、まずWAFの流儀で作る

不足部分の扱い:

どうしても足りない部分だけを、Open–Closed Principleに従い既存の仕組みを壊さず拡張する

脱RailsをRailsの中でやる必要はない

MEMO:

Ruby on RailsやNext.jsみたいなフルスタックフレームワークを採用しているのに、わざわざ別の構造を注入しようとするのは愚かというのは同意
そういうのがやりたければマイクロフレームワークを選ぶのが定石
つまり、強い覚悟で脱フルスタックフレームワークをやるのが先ということ

(2026/08/31)

Testcontainersで実DBを使う並列テスト基盤を設計する

Testcontainersで実DBを使う並列テスト基盤を設計する - エムスリーテックブログ

要約:

■ 1. 実DBを使う方針

Mockへの依存を減らす目的:

RepositoryをMockすればUseCaseのテストをDBから切り離せるが、確認できるのはMockに定義した振る舞いを前提とした正しさのみ

実際のSQL、ORMのマッピング、DBの制約、Transactionは検証されない

実装を変えるたびにMock側の追随が必要で、漏れればMockの振る舞いが実際の振る舞いから乖離する

Mockを全廃するわけではない:

外部APIなど、実物をテストに組み込むことが適切でない依存もある

実DBの適用範囲:

DBはTestcontainersを使えば比較的低いコストで実物を用意できる

Repositoryだけでなく、HTTPリクエストを投げるControllerのテストまで実DBに接続する

実DBのコスト:

実際に読み書きする分、テスト1件あたりの実行時間はMockより長くなる

テスト前にMigrationでスキーマを揃える手間と、書き込んだデータをテストごとに戻す手間が乗る

実行時間を抑えるため並列実行すると、テスト同士で状態が混ざらない仕組みが必要になる

■ 2. 前提とするテスト構成

技術スタック:

バックエンドはKotlin、テスト対象のDBはPostgreSQL 18

Testcontainersでテスト実行時にDBコンテナを自動起動する

JUnit 5でテストの実行とテストクラス単位の並列実行を行う

FlywayでDBスキーマのMigration、HikariCPでコネクションプール、ExposedでDBアクセスを担う

アプリケーションの層構成:

レイヤードアーキテクチャを採用し、RepositoryがDBへの読み書きを担う

UseCaseがRepositoryを呼んでTransactionの境界を決める

ControllerがHTTPリクエストを受けてUseCaseを呼ぶ

コンテナの起動設定:

データディレクトリを512MiBのtmpfsに置き、耐久性に関する設定を切って起動する

fsync、full_page_writes、synchronous_commitをoffにする

テスト用のDBは失われても作り直せるため、ディスクへの書き込みを待つ必要がない

計測環境:

10コアのApple Silicon搭載Mac上で、Dockerにも10コアを割り当てて測定した値を用いる

■ 3. できあがった構成

実DB前提で決めるべき論点:

テスト実行時にDBをどう用意するか

並列実行するテスト同士をどう分離するか

DBの初期化コストをどう抑えるか、テストごとのデータをどうリセットするか

選択した組み合わせ:

TestcontainersによるDBの自動起動

Database単位での分離と、Migration済みDatabaseの複製

TRUNCATEと初期データの再投入

最終的な構造:

1つのPostgreSQLコンテナ内に、Flyway Migration済みのTemplate Databaseを1つ置く

テストを実行するスレッドは、それぞれ自分専用のDatabaseを1つ持つ

Databaseはテストごとに作り直さず、全テーブルのTRUNCATEと初期データ再投入で使い回す

■ 4. DBをどう用意するか

Testcontainersを新規開発の段階から利用する:

docker compose up -d のように別途環境を準備する方式は問題につながる

DBを起動していなかったためテストが失敗する、ローカルとCIでテストの実行方法が異なる、といった問題が生じる

Testcontainersならテストのライフサイクルにコンテナのライフサイクルをひもづけられる

■ 5. 何を分離の単位にするか

状態共有によるFlaky Test:

実DBを共有したまま並列実行すると、単独では成功するテストがCIでは実行のたびに結果を変える

原因は並列に動作するテストが同じDBの状態を操作するレースコンディション

並列に動作するテスト同士でDBの状態を共有しないことを最初の方針とする

並列実行は前提とする:

テストクラスの並列実行をやめると、スイート全体の実行時間が並列実行時の3倍以上になった

この差は無視できないため、並列実行を前提としたうえで独立性を確保する

テストごとのコンテナ起動は採らない:

コンテナは起動してから接続できるまで1秒前後かかる

コンテナごとにMigrationを流し直すため、テスト1件あたり1秒以上が準備に消える

コンテナ自体はテスト全体で1つだけ起動し、その中でDatabaseを分ける

SchemaではなくDatabaseで分ける理由:

Schemaで分けると、修飾名や search_path の操作で他スレッドのデータに到達する手段が残る

接続先のDatabaseが別であれば他スレッドのデータに到達する手段はなく、誤って触ろうとすればエラーになる

Database分離の代償はメモリ:

Databaseを増やすとテーブルの実体がまるごと増え、tmpfs上の増分はそのままコンテナのメモリ使用量になる

何も作っていないコンテナは70MiB、Databaseを16個作ると382MiB、同数をSchemaで作ると113MiB

増分はDatabaseが+312MiB、Schemaが+43MiBとなる

Databaseを1つ作るとシステムカタログ一式も作られるため、増分はテーブルのデータ量そのものより大きい

現状のスレッド数では問題にならない:

tmpfsは512MiBで確保しており、テスト実行中のコンテナのメモリ使用量は最大239MiBだった

■ 6. スレッドごとのDatabase割り当て

必要な分離の粒度:

テストの数だけDatabaseを作る必要はなく、同時に実行されているテストの間で状態が混ざらなければ十分

JUnitの並列実行設定:

テストクラスは並列に実行し、クラス内のテストメソッドは親クラスと同じスレッドで順に実行する

並列数は指定せず、JUnitの既定の動的戦略により実行環境のCPUコア数を基準に決まる

ThreadLocalによる割り当て:

Databaseをスレッドにひもづけ、ThreadLocalのキャッシュとして保持する

各テストクラスは @BeforeTest で setup() を呼び、キャッシュがあればデータをリセットして再利用する

キャッシュがなければUUIDから名前を作ってDatabaseを新規作成する

使い回しの効果と注意点:

same_thread設定により、1つのテストクラスは実行中ずっと同じDatabaseを使い続ける

Databaseが作られるのはそのスレッドで最初にDBテストが走ったときだけ

並列数を上げればスレッドが増え、メモリの増分が積み上がるためtmpfsの上限に気を配る必要がある

後始末は不要:

作成したDatabaseはテスト終了時にDROPせず、テストJVMの終了に合わせてコンテナごと破棄する

■ 7. Migrationのコストをどう避けるか

Template Databaseからの複製:

PostgreSQLには既存のDatabaseをTemplateとして新しいDatabaseを作成する機能がある

コンテナ起動直後にDatabaseを1つだけ作ってFlyway Migrationを適用し、これをTemplateとして複製する

複製元への接続に関する制約:

CREATE DATABASE ... TEMPLATE は複製元への接続が1本でも残っていると失敗する

Template Databaseに繋ぐ処理はコンテナの初期化の中で完結させ、Migrationと初期データ抽出の後に接続を閉じきる

複製は初期化の後に始まるため、複製中にTemplate Databaseへ接続が張られることもない

準備にかかる時間:

Flyway MigrationはJVM内で最初の1回のみで500〜544ms

CREATE DATABASE ... TEMPLATE は競合のない状態で17ms前後、テスト実行中の競合下では68〜96ms

複製方式の利点:

Flywayが走るのは全体で一度だけになる

スレッドやMigrationを増やしても1スレッドあたりの準備は複製1回のまま

伸びるのはTemplate Databaseが大きくなった分のコピー時間だけ

■ 8. テスト間で状態をどう戻すか

リセットが必要な理由:

Databaseをスレッド単位で使い回す以上、テストが書き込んだデータはテストごとに初期状態へ戻す必要がある

Transactionで囲んでRollbackする案は不採用:

Repositoryレベルのテストであれば高速かつシンプルだが、Controllerレベルまでテストしているため採用できない

アプリケーション自身がTransactionを開始しCommitし、コネクションプールから自分で接続を取る

テストが張った接続とは別のため、Commitしていない変更はアプリケーション側から見えない

複数Transactionの検証:

UseCaseによっては1つの処理中に複数のTransactionを使う

先のTransactionはCommitされ、後のTransactionは失敗してRollbackされる振る舞い自体を検証したいケースがある

テスト全体を1つのTransactionで包む方式では、本番と同じTransaction境界を保った検証が難しくなる

テスト基盤側はRollbackに依存せず、アプリケーションには通常通りCommitやRollbackをさせる

Databaseを作り直す案も不採用:

Databaseを作り直すにはそのDatabaseへの接続を全部閉じる必要があり、プールの張り直しも伴う

同時実行数1ではTRUNCATE+初期データ復元が11.41ms、DROP+CREATE TEMPLATEが9.51ms、プール張り直し込みで20.12ms

同時実行数10ではそれぞれ27.20ms、47.15ms、67.11msとなり順位が逆転する

Databaseを分けて独立するのは中のデータだけで、Databaseを作る処理自体はサーバ全体で競合するため

作り直しが遅い内訳:

遅いのは DROP より CREATE の側で、DROP を外しても同時実行数10で35.61msとTRUNCATE方式に届かない

複製したDatabaseは1つ8.5MiBあり、数百回規模のリセットが走るため512MiBのtmpfsでは DROP を外す選択肢自体がない

実際にリセットを作り直しに差し替えると、どの回もTRUNCATE方式より遅くなった

採用したTRUNCATE方式:

DDLを実行するテストがない限り、テストが変更するのはデータだけでSchema構造は残る

Databaseそのものは再利用し、各テストの開始時に全テーブルをTRUNCATEして初期データを再投入する

TRUNCATE ... RESTART IDENTITY CASCADE を1つの文にまとめ、外部キーの参照順を気にせず消せるようにする

■ 9. Template Databaseから抽出する初期データ

pg_dumpによる抽出:

Migration適用済みのTemplate Databaseから、データだけをINSERT文として抽出しリセット時に流す

--data-only、--inserts を指定し、flyway_schema_history は除外する

初期データの定義はMigrationに一本化され、データ投入Migrationを追加してもテスト側の手当ては不要になる

つまずき1: 出力に混じるセッション設定:

pg_dump の出力にはINSERT文以外も含まれ、特にセッション設定が問題になる

set_config('search_path', '', false) をそのまま流すと、search_pathが空の接続がプールに返却され後続のテストが壊れる

近年の pg_dump は \restrict / \unrestrict というpsqlのメタコマンドも出力し、これもJDBCからは流せない

INSERT INTO と SELECT pg_catalog.setval( で始まる行だけを取り出して対処する

行の先頭で判定しているため、値に改行を含むデータがあると2行目以降を取りこぼす

つまずき2: シーケンスとデータのずれ:

TRUNCATE ... RESTART IDENTITY はシーケンスを巻き戻す一方、pg_dump のINSERT文はIDを明示して入れる

INSERT文だけを流すと、テーブルにはid=1, 2の行が入るのにシーケンスは1のままとなる

次にアプリケーションがINSERTするとid=1が採番されて主キー衝突する

pg_dump が出力する setval を一緒に流すことで、シーケンスがデータと整合する

■ 10. リソースごとにライフサイクルを変える

二律背反の解消:

すべてをテストごとに作り直せば実行速度が問題になり、すべてを共有すれば並列テスト同士が干渉する

そこでリソースごとにライフサイクルを変える

採用したライフサイクル:

PostgreSQL ContainerはTest Suite全体で1つ

Databaseはスレッドごとに1つとし、複数のテストクラスで使い回す

Schema定義はMigration済みのTemplateから複製する

データはテストごとにTRUNCATEして再投入する

Testcontainersの位置づけ:

実DBをテストに組み込む手段としては便利だが、それだけで並列テストの独立性や実行速度が決まるわけではない

どのリソースをどの単位で共有し、どの状態だけをテストごとに戻すかは、その上で1つずつ決める必要がある

(2026/08/30)

ベテランエンジニアのPRレビュー187件を分類してみたら、バグは5件に1件しか指摘されていなかった

ベテランエンジニアのPRレビュー187件を分類してみたら、バグは5件に1件しか指摘されていなかった #初心者 - Qiita

要約:

■ 1. 調査の動機

レビューが薄い理由の不明:

同じPRを見ても自分はLGTMで終わり、隣の人は10件の的確な指摘を出す

本人に聞いても「気になった箇所を見てるだけ」という答えしか返らない

実物を数える方針:

GitHub APIでベテランのインラインコメントを全件取得し、主題ごとに分類する

対象は3リポジトリ・44本のPRに付いた187件

■ 2. 収集方法と分類軸

一括取得エンドポイントの利用:

リポジトリ全体のレビューコメントを取れるエンドポイントを使い、PRを1本ずつ回すより速く集める

gh api "repos/{owner}/{repo}/pulls/comments?per_page=100" --paginate に jq で対象ユーザーを絞る

除外処理:

取得した212件から、スレッド内の返信21件と本文が完全一致する重複4件を除く

残る187件を分析対象とする

3つの分類軸:

型は何を指摘したか（条件の誤り、デッドコード、非対称など）

動作は見つけるために何を開いたか（既存の別ファイル、呼び先、公式ドキュメントなど）

領域はそもそも何に注意を向けているか

領域を主題に選ぶ理由:

レビューで手が止まる原因は「探し方を知らない」ではなく「そこに注意が向いていない」ことが大半

よって領域の分析のほうが実務に効く

■ 3. 11領域の分布

領域の全体像:

187件は11の大領域、さらに37の中領域に分かれる

上位から下位までの件数:

1位: 隣のコードと揃っているか

31件、問いは「同じことをしている場所と食い違ってないか」

2位: 契約と意図は保存されているか

30件、問いは「半年後の人が同じ判断に辿り着けるか」

3位: 値そのものは正しいか

25件、問いは「この数字・この判定は合っているか」

4位: 失敗に気づけるか

17件、問いは「壊れたとき人間は知れるか」

5位: 使う人から見てどうか

16件、問いは「運用担当とユーザーの手元で何が起きるか」

6位: 外部との境界

15件、問いは「自分が書いていないものは本当にそう動くか」

7位/8位: データが壊れないかと設計の見通し

ともに13件

9位: 速度とコスト

12件

10位: 変更はどこまで効くか

11件

11位: 検証できるか

4件

バグ指摘の比率:

上位2領域だけで61件、全体の33%を占める

バグ相当にあたる「値そのもの」と「データが壊れないか」は合計38件で20%にとどまる

■ 4. レイヤーによる領域の入れ替わり

同一人物でも対象で偏りが変わる:

バックエンドは「値の正しさ」が20%で突出し、金額・時刻・DB制約に集中する

モバイルは「データが壊れないか」「変更の波及」「外部SDK」に寄る

Webフロントは「一貫性」と「意図の保存」だけで半分を占め、「外部との境界」と「検証できるか」はゼロ

実務上の含意:

全領域を毎回見る必要はなく、差分のレイヤーで見る領域を絞れる

■ 5. 1位: 隣のコードと揃っているか

発見経路の偏り:

31件のうち27件、87%が「リポジトリ内の別の場所を開いた」ことから生まれている

合計と明細のロジック不一致:

合計は Math.abs(quantity) と異常値フォールバック0で集計するのに、各行の表示は Math.abs なし・フォールバック1

返品などで数量がマイナスになると各行を足しても合計にならない表示になる

合計と明細は必ずペアなので両方開く、というだけの動作で見つかる

別名が本番から未参照:

共通処理を別モジュールへ切り出す際、元クラスに委譲用の別名を5つ残していた

移動先が内部でモジュールグローバルを直接参照していたため、その別名は本番コードからの参照が0

テストで @patch しても差し替わらず実物が呼ばれ、SQL定数を書き換えても実行SQLは変わらない

挙動不変のリファクタなのに、テストの縫い目だけが静かに偽物になっていた

■ 6. 2位: 契約と意図は保存されているか

領域の性格:

バグでも設計ミスでもなく、「なぜそう書いたか」が失われることを防ぐ指摘

マジックナンバーの根拠:

CSSの calc(50% + 3.5rem) を、親の幅6rem + gap 1rem = 7rem の半分ずらす計算だとレビュー側で自力で解く

そのうえで親の幅やgapを変えたときに追従修正が必要になるため、一言コメントを求める

合っていることを確認してから、依存が見えないことだけを指摘する

git履歴による裏取り:

カメラ設定を新クラスへ移行したPRで、旧実装のコミットまで遡り設定値の指定が引き継がれていないことを立証する

別のPRではPR説明に書かれた因果そのものを、当時のコミットを特定して反証する

PR説明文は主張であって事実ではない、という扱い方をとる

■ 7. 3位: 値そのものは正しいか

領域の性格:

数字が1つズレると残高や集計値が静かに間違い、しかもテストは通る

テストも同じ思い込みで書かれるため検知できない

単価と合計の取り違え:

一覧の金額表示が price * quantity から price 単体に変わり、数量分の乗算が消えていた

API側では price は税込の単価であり、合計は掛け算して出す仕様である

実機で同じ取引が一覧550円・詳細230円と食い違うところまで確認して指摘している

タイムゾーンによる期限切れの9時間ずれ:

expires_at はタイムゾーンを持たない型でUTCのつもりの日時を入れ、NOW() はタイムゾーン付きの値を返す

型が違うためPostgreSQLは変換して比較し、タイムゾーンなしの値はセッションの TimeZone のローカル時刻として解釈される

TimeZone が Asia/Tokyo だとUTCのつもりの値がJSTとして読まれ、実際より9時間早く期限切れと判定される

金銭やポイントの有効期限で起きると、まだ生きているはずのものが消える

指摘の書き方:

「今は正しく動く」ことをまず認め、なぜ今は動くのかまで書く

動く理由はDBコンテナの TimeZone が未指定でたまたまUTCだから、というだけである

効いているのはアプリ側のTZではなくDBセッション側の設定なので、DBの起動オプション1つで壊れる

そのうえで NOW() AT TIME ZONE 'utc' のような設定に依存しない書き方を提案する

■ 8. 4位: 失敗に気づけるか

領域の性格:

機能としては正しく動くのに、壊れたことが誰にも伝わらない指摘が17件ある

catchが発火しない設定:

aspida のクライアントが throwHttpErrors: false（既定値）で初期化され、await した post が400/500でも例外を投げない

try/catch で囲んでいるのに catch 節に入らず、APIが拒否しても成功バナーが出ていた

設定ファイル1行が「try/catch があるから安全」という直感をひっくり返す

エラー文言の握り潰し:

「同じ対象へ既に登録済みの可能性があります」という親切な例外メッセージを新設した

しかし拾うデコレータの捕捉リストに入っておらず、上位の except Exception に落ちて汎用文言に置き換わる

丁寧な文言を見つけたら、それが画面に到達する経路を追うという定型の動きをとる

■ 9. 5位: 使う人から見てどうか

領域の性格:

コードとしては正しいが、画面の前にいる人が困る指摘

リダイレクトで絞り込みが落ちる:

管理画面で特定ユーザーに絞ってから操作すると、戻り先URLにユーザーIDが渡されず絞り込みが外れる

ページ番号だけ保持されるため、直前まで見ていた行とはまったく別の行が並ぶ

ここまで具体化すると、単なるUXの話が誤操作のリスクに変わる

オーバーレイの覆い漏れ:

処理中のローディングオーバーレイがコンテナの内側にあり、フッターのボタンを覆っていない

二重実行自体は別のフラグで防げているが、処理中に対象データを削除できる導線が残る

■ 10. 6位: 外部との境界

領域の問い:

SDK・OS API・CLI・フレームワークなど自分が書いていないものが、本当にそう動くのか

setterをadderと誤認した呼び出し:

ML KitのバーコードスキャナはBuilderでフォーマットを指定する

公式ドキュメントに "Only the last call will be respected if calling this method multiple times" とある

forEach で1つずつ渡すと最後の1件しか残らない

さらに呼び出し元の定数定義まで追い、どのカードが読めなくなるかまで特定している

Content-Type依存のボディ読み取り:

Flaskの request.get_json(silent=True) はmimetypeがJSONを示さなければ、ボディの中身に関わらず None を返す

相手が正しいJSONを送ってもヘッダを付けていなければ弾かれ、外部連携の疎通当日にハマる

silent なしの挙動はFlask 2.1で400、2.3で415に変わり、silent=True 側は昔から None のまま変わっていない

lockファイルで実バージョンを確認してから調べている点が、この指摘の効き所である

■ 11. 7位: データが壊れないか

領域の性格:

正常系では露見せず、障害時・同時実行時・画面遷移時にだけ顔を出す

中間テーブルからの孤児化:

ユーザーを作った直後は引けるが、後から所属テーブルの行が消えると取得関数のどの分岐でも引けなくなる

レコードは残っているのに誰からも参照できない状態になる

DB制約が前提を保証していない:

GROUP BY user_id して MIN(company_id) を採る実装に対する指摘である

DB制約は1ユーザー×1会社を強制しておらず、片方は会社単位ユニーク、もう片方は施設単位ユニークである

複数所属の行が作れた瞬間に画面では片方しか見えなくなる

アプリが暗黙に前提とするカーディナリティを、スキーマ定義まで開いて確かめている

■ 12. 7位: 設計の見通し

領域の位置づけ:

いわゆる「コードレビューらしいコードレビュー」だが、同率7位で全体の7%しかない

nullを返しうる値へのキャスト:

null を返す可能性がある関数の戻り値に as string を3回使っている

外側で存在チェック済みなので、変数に一度入れればキャストは不要になるという3行の書き換え提案をする

型が効いていないことの伝え方:

TanStack Query（v5系で確認）でクエリの meta に独自キーを渡していた

Register インターフェースに queryMeta を宣言していないため meta の型が Record<string, unknown> のままである

どんなキー名でも通るので、キー名をタイポしてもコンパイルで拾えない

「型が緩い」ではなく「タイポが通る」と言うと、直す理由がはっきりする

■ 13. 9位: 速度とコスト

数字で語る指摘:

この領域の指摘はほぼ全件に実測値が入っており、「重そう」ではなく数字で言う

インデックスと呼ばれる頻度:

新しく追加された検索クエリに対し、モデル定義のインデックス宣言を開いて対応するインデックスがないと確認する

同じクエリは別の場所にもあるが、あちらは初回1回きり、こちらは再入路である

セッション有効期限が365日である以上、毎回のアクセスがここを通る

インデックスの有無より、呼ばれる頻度の差を言語化しているのが効き所である

タイムアウトの足し算:

アプリ側のタイムアウトを40秒に設定した差分に対し、本番ロードバランサーの実測値を出す

実測値は直近7日で平均0.4秒台、p99が3秒台、最大18秒である

ここで40秒使うと合計1分近くになり、ALBの idle_timeout 60秒に迫ると指摘する

自分より外側のタイムアウトを調べて足し算するという発想をとる

■ 14. 10位: 変更はどこまで効くか

領域の性格:

バグではなく「意図した範囲を超えている」という指摘であり、PRの説明文が正しくても成立する

propのデフォルト値:

共通フォーム部品に新しい表示オプションが追加され、そのデフォルトが有効になっていた

この prop を渡していないログインや設定などの既存画面でも挙動が変わるため、opt-in を提案する

引数オブジェクトの破壊的変更:

マージ関数が引数で受け取ったdictのスコアを直接書き換えるため、呼び出し側が持つ配列の中身も一緒に変わる

今は同じ関数の中で使い終わるので影響はないと前置きしたうえで指摘する

あとからログや保存に回したときに混ざる、という将来の話をしている

■ 15. 11位: 検証できるか

領域の位置づけ:

件数は最少の4件だが、「テストがあるから安心」を崩すタイプなので独立させた

モックし忘れによる実送信:

通知を送る経路を通るテスト3本が、通知クライアントをモックしていない

テスト用の設定キー一覧にもその環境変数が入っておらず、変数が設定された環境でテストを流すと実際に通知が飛ぶ

同じファイルの他のテストはきちんとモックしており、その非対称から見つけている

マージ前に試せない構造:

CIワークフローのジョブに if 条件が付き、対象ブランチ以外では手動実行してもジョブごとスキップされる

この修正が効くかをマージ前に確認できない構造である

指摘だけで終わらせず、一時ブランチで空打ちする具体的なコマンドまで添えている

■ 16. 数えて分かったこと

3分の1は劣化を止める側:

1位の31件と2位の30件で61件、33%を占める

この2領域に共通するのは、指摘した時点では何も壊れていないことである

壊れるのは新しい選択肢を1つ足したとき、共通スタイルの値を変えたとき、片方だけ直したときであり、要するに未来の改修である

この人のレビューはPRを通すための検査ではなく、コードベースの劣化速度を落とす作業として設計されている

自分はレビューをバグ探しだと思っていたため、壊れていないコードには何も言えなかった

気づけるかが独立した品質項目:

4位の17件は機能としては全部正しく動き、機能テストでは1件も落ちない

該当するのはsilent failure、届かないログ、外部から撃てる通知、潰されるエラー文言である

「動くか」だけを見ているとこの17件はゼロになる

「壊れたときに人間が知れるか」を品質項目として持っているかが、深掘りレビューの分かれ目である

69%はもう1枚開いた結果:

何を開いたかの軸で数えると、187件のうち129件、69%が差分の外を見た結果である

差分だけを上から下に読んで出せるのは58件、31%しかない

実力差の正体は着眼点のセンスではなく、もう1枚ファイルを開いたかどうかという作業量である

1位の領域は87%が別の場所を開く動作から生まれ、その大半はgrepと対になるファイルを並べるだけで専門知識をほぼ必要としない

■ 17. 自分の穴と改善計画

自己分析の結果:

同じPRに自分が出したレビューを同じ11領域に振ると、3位の値と5位の使う人には入っていた

1位・2位・10位には1件も入っておらず、見ていた領域が3つしかなかった

習慣化する6つの中領域:

根拠の保存は数値リテラル・固定値に「この根拠はどこに書いてあるか」と聞く動作で20件

対の非対称は一覧/詳細、合計/明細、iOS/Androidなど対になる名前を探して並べる動作で10件

二重定義は新しく定義した定数の値をgrepする動作で9件

デッドコードは参照をgrepで数え、ガードがfalseになる条件を上流で確認する動作で8件

silent failureはHTTPクライアントの設定を開き、catch の到達条件を全部言う動作で8件

変更の波及範囲は変更した部品の呼び出し元をgrepで数える動作で7件

着手順の根拠:

この6つで62件、全体の33%を占める

最多の「根拠の保存」は20件中14件が差分を読むだけで出せる

ファイルを1枚も開かずに始められるものがいちばん件数が多く、ここから始めるのが確実に速い

■ 18. 結論

差は文章力ではない:

レビューがうまい人を真似ようとすると、言い回しや指摘の丁寧さに目が行きがちである

実際に187件を数えると、差がついていたのは注意の向け先が11箇所あるか3箇所しかないかであった

数える方法の推奨:

すごいと思えるレビュアーが手元にいるなら、GitHub APIで全部引っ張って数えるとよい

半日もかからず、自分がどの領域に一度も足を踏み入れていないかが身も蓋もなく出てくる

(2026/08/29)

The case against a C alternative

The case against a C alternative | Handmade Network

要約:

■ 1. C代替言語の現状

乱立するC代替言語:

自身もC3というC代替言語を開発中であり、他にZig、Odin、Jai、eCといった言語が存在する

C++の代替に目を向ければD、Rust、Nim、Crystal、Beef、Carbonなどがある

本稿の問い:

Cを置き換えることは本当に可能なのかを、反対側の論拠から検討する

■ 2. Cを捨てられない理由

Cのツールチェーン:

Cは言語そのものだけでなく、開発された全ての開発者向けツールを含む存在である

静的解析、メモリリーク検出、データレース検出などのツールが多数開発されている

新言語が標準でより良いツールを備えていても、Cのツール群の厚みには及ばない

マイナープラットフォームへの対応:

特殊なプラットフォームを対象とする場合、Cが使われる前提になっている可能性が高い

Cが今日のコンピューティングの共通語である地位:

ツールを書く価値が高いため、多くのツールが継続的に生み出されている

乗り換えコストの壁:

動作しているツールチェーンがあるなら、言語を変える危険を冒す理由がない

「より良いC」は新たなツールチェーン構築の時間に見合う生産性向上をもたらす必要がある

新言語の不確実性:

成熟前の言語はバグを抱えやすく、意味論上の問題解消のため大きく変わる可能性がある

「高速なコンパイル」「Cより速い」といった宣伝が、機能追加に伴い達成困難になる場合がある

メンテナの継続性リスク:

オープンソースならフォークできるが、将来自社で保守を強いられる言語を使いたい企業は少ない

新言語に賭けることは大きなリスクである

言語が十分に良くない可能性:

Cの本当の痛点に対処しているとは限らず、痛点が何かについて人々の意見は一致しない

メモリ確保、配列、文字列の扱いは厄介だが、適切なライブラリと健全なメモリ戦略で最小化できる

上級者が気にしない問題を解いているなら、実際の価値は期待よりはるかに低い

C固有機能の欠落リスク:

Cの上級プログラマが依存する重要な機能を、新言語が省いてしまう危険がある

設計者がCの使用経験に乏しくC++やJavaの出身である場合、この危険は高まる

経験ある開発者の不在:

新言語は経験者の母数が小さく、中規模以上の企業にとって重大な問題となる

企業は採用可能な開発者が多いほど好むものである

C開発者の採用経験はあっても、新言語での採用方法は分からない

相互運用の標準としてのC ABI:

Cコードを容易に呼べない、あるいは呼ばれない言語では、外部コードとの接続の度に追加作業が生じる

これは潜在的に極めて大きな不利である

■ 3. 「Cより良い」は決め手にならない

言語設計者の過大評価:

追加した機能がもたらす利点の大きさを、設計者はしばしば過大に見積もる

より良い構文:

Cより優れた構文かどうかは大部分が主観の問題である

構文が異なること自体が大きな不利であり、Cからコードを流用できず全行の書き直しが要る

構文がわずかに良いという理由で言語を採用する企業は存在しない

Cより安全:

C代替言語は性能面でCと同等であることを当然に期待される

Cには実質的に検査が存在しないため、競合言語が加える安全検査は実行時コストとなり、しばしば受け入れられない

結果として検査は「セーフモード」限定となり、「高速モード」はCと同じく安全でないものになる

例外としてforeachは境界検査の手書きを不要にし、自動的により安全になる

スライスもポインタと長さの組、あるいはより悪いヌル終端配列と比べ、検査を書きやすくする

プログラマの生産性:

ほぼ全ての言語が「生産性が高い」という中身のない主張を掲げる

ビジネスにとって主要な時間の消費先はプログラミングそのものではない

実際に時間を要するのは、課題が本当は何であるかを見極める作業である

10%や20%の生産性向上は認識すらされず、100%の向上でさえ表面化する保証がない

■ 4. 採用を決めるのはキラー機能

ビジネスの判断基準:

欠点を差し引いてなお収益に貢献するか、すなわち欠点を上回る価値があるかが問われる

キラー機能の必要性:

決め手となるのはCが真似できない独自の売りを持つことである

Java登場時の八つの売り:

オブジェクト指向を綺麗に実現した点、当時は珍しかった標準搭載のスレッド機能

「一度書けばどこでも動く」、ブラウザ上でのコード実行

組み込みのガベージコレクション、ネットワークプログラミング

優れた標準ライブラリ、無償での利用

C代替言語が持つ独自の売りは、少なくともJavaの八つには及ばない

独占的用途による普及:

言語は、何かを使うための唯一の手段となることで採用を獲得する場合が多い

Flutterを使うためのDart、ブラウザのスクリプトのためのJS、アプレットのためのJava、MacとiOSアプリのためのObjCが該当する

その独占が時とともに消えても、言語が知られ使われる状態は残る

フレームワーク経由の普及:

フレームワークの人気が言語を押し上げた例としてRubyとPythonがある

Jaiの戦略:

ゲームエンジンを同梱する方針は有効であり、利用者は必然的にJaiを学ぶことになる

エンジンが十分に良ければ、人々は言語も習得する

他のC代替言語の欠如:

Jai以外にキラー機能を追求している言語は見当たらない

キラー機能がなければ、Cから乗り換える価値を証明することはできない

■ 5. 結論

「作れば人は来る」という考えは魅力的だが、信じるに足る根拠は乏しい

Cが到底及ばない重要な独自機能や製品を持たない限り、Cを捨てる理由はほとんどない

人気と熱意は助けにはなるが、証明された価値の代わりにはならない

最終的に問われるのは、Cの用途の大部分において開発者により多くの具体的価値を生めるかである

開発者が新言語に興奮したとしても、その熱意がビジネス上の価値に転化することはない

どれほど魅力的に見えるC代替言語であっても、おそらく失敗する

(2026/08/29)

グーグル、購入した電子書籍を「Gemini Notebook」に追加可能に

グーグル、購入した電子書籍を「Gemini Notebook」に追加可能に - Impress Watch

Googleは27日、Google Play Booksで購入した対象電子書籍を「Gemini Notebook」に追加できる新機能を提供開始した。Google横断の取り組み「Expert Intelligence」の一環で、開始時点で10万冊超の書籍に対応する。

対象の電子書籍をGemini Notebookに追加すると、その書籍の内容を根拠に質問への回答を得られる。書籍から「インフォグラフィックス」「音声概要(Audio Averview)」「クイズ」などを生成することも可能。

書籍単体だけでなく、利用者が持つ情報を含むほかのソースと組み合わせて利用できる。例えば、書籍の内容を自身の情報と照らし合わせたり、複数の情報源をもとに質問したりといった使い方に対応する。

開始時点ではBloomsbury、De Gruyter Brill、Johns Hopkins University Press、Macmillan Publishers、O’Reilly Media、Penguin Random Houseなどの出版社が参加。15人を超える著者とも連携し、書籍に追加のソースなどを組み合わせた「Featured Notebooks」を用意する。

利用には、対象となる書籍をGoogle Play Booksで所有していることが必要。Notebookをほかの利用者と共有した場合も、共同利用者が書籍の内容を扱うには各自で同じ書籍を購入する必要がある。所有していない場合、その書籍はNotebook内で利用できない。

MEMO:

これは革命的
ベンダーロックインされる事になっても仕方ない利便性がある

(2026/08/29)

「ミスを許さない手順書」を作ってみた〜個人的にはこれ以上できることはあまりなさそう

「ミスを許さない手順書」を作ってみた〜個人的にはこれ以上できることはあまりなさそう/20260827-ssmjp-operation-procedure-update - Speaker Deck

(2026/08/29)

スケールアウトはもう要らない？DuckDBが描くシステム設計の新時代 🦆

スケールアウトはもう要らない？DuckDBが描くシステム設計の新時代 🦆 #データ分析 - Qiita

要約:

■ 1. 本稿の目的

スケールアップモデルの主流化:

スケールアウトを前提としたデータ処理システムから、シンプルで効率的なスケールアップモデルへ主流が移り得る

DuckDBはその先駆けとなる存在

対象読者:

システム設計や運用コストの最適化を検討するソフトウェアアーキテクト

アプリケーションデータやログデータなど様々なデータセットを効率的に処理したいデータエンジニア

クラウドコスト削減や効率的なデータ処理システムを模索するシステム管理者、運用者

従来モデルとの対比:

BigQueryやRedshiftに代表されるスケールアウトモデルは複雑なクラスター構成と管理を要し、費用と運用負荷が増大する

DuckDBは比較的運用コストの低いシングルノードで動作し、非常に高速なデータ処理を提供する

■ 2. スケールアウトモデルの台頭

Googleによるスケールアウト革命:

2000年代初頭、増加するWebサイト数に対応する検索エンジンを構築するためシステム設計を抜本的に改善した際に発明された

高価で高性能なハードウェアではなく、安価で一般的な性能のハードウェアを大量に用い、ソフトウェアで高いスケーラビリティを実現する

現在のシステム設計への影響:

2024年時点で本格的な実行アーキテクチャを設計する場合、スケールアウトによる拡張性や弾力性は重要なアーキテクチャ特性

BigQuery、Dataflow、Redshift、Amazon Managed Service for Apache Flinkなど、マネージドサービスにも多く採用されている

■ 3. スケールアウト普及に伴う課題

設計と開発の難しさ:

複数のハードウェア上でスケールアウト可能な処理の設計やシステムの開発が難しい

運用の難しさ:

処理をスケールアウトさせるとデータ整合性担保、実行ステータス監視、エラー対応が難しい

結果として2024年時点のソフトウェア開発は処理の複雑化や運用負荷の増大に直面している

課金体系による制約:

BigQueryやRedshiftなど一部のクラウドマネージドサービスはスキャンしたデータ量に応じて料金が発生する

一処理あたりの費用を考慮しながらクエリを実行しなければならない

■ 4. スケールアップモデルへの回帰

ムーアの法則によるハードウェア性能改善:

1965年に提唱されたムーアの法則のとおり、半導体の性能は指数関数的に向上してきた

スケールアウトモデルが発明された2000年代初頭からの20数年間で、トランジスタ密度は1000倍に増加した

2002年当初は数千台のハードウェアを必要とした処理が、2020年時点ではわずか1台で実現可能となった

仮想化技術の発展:

2000年代初頭から普及した仮想マシンに加え、コンテナやサーバレスといった仮想化技術も2024年時点では広く一般化している

パブリッククラウドの普及により、これらを駆使した様々なタイプのコンピューティングリソースが誰でも簡単に調達可能となった

高性能なハードウェアであっても、必要な時に必要な分だけ現実的な価格で効率的に利用できる

最適解の再考:

ハードウェアの性能改善を踏まえ、自身のシステムにとってスケールアウトモデルが本当に最適解なのかを考え直す時が来た

1台の高性能なハードウェア、または適切に仮想化されたリソースによるスケールアップモデルを採用すべき

これによりよりシンプルにシステムを設計し、より効率的に処理を実装できる

■ 5. DuckDBの技術的特性

DuckDBの位置付け:

大量のデータセットを単一のローカルマシン上で高速に処理できる、モダンで軽量な組み込み分析データベース

クエリエンジンの構造:

列指向のベクトル化されたクエリエンジンにより、データを並列処理しマルチコアCPUの性能を十分に引き出す

ストリーミング実行エンジンにより、データソースから部分的にデータを読み取りメモリリソースを効率的に管理する

主な特性:

OLAPに特化し、数百ギガバイトのデータを効率的に処理できる

一般的なSQLを利用し、複雑な分析処理でも柔軟かつ簡潔に表現できる

異なるデータソースから様々な形式のデータセットを収集し、同一クエリ内でまとめて処理できる

■ 6. DuckDBが注目される理由

従来の組み込みデータベースの限界:

SQLiteに代表される組み込みデータベースはOLTPに特化し、トランザクション制御を必要とする軽量な処理を得意とする

行指向のクエリエンジンのため、データ量の増加に伴う性能悪化の懸念がある

データセットのファイル形式やデータファイル配置先の柔軟性が低く、軽量なアプリケーションなどに用途が限られる

従来のDWHの限界:

BigQueryやRedshiftはOLAPに特化し、列指向ストレージとベクトル化されたクエリエンジンで大量データを高速処理できる

大規模なクラスターのセットアップや管理が必要であり、複雑性や運用負荷増大の懸念がある

スキャン量に応じた課金の製品では費用を計算しながらクエリを実行する必要があり、データ分析業務の効率化を妨げる

DuckDBの優位性:

軽量な組み込みデータベースとしての扱いやすさと、大量データの分析処理を実現する高性能なクエリエンジンを両立する

異なるデータソースからの様々な形式のデータセットを一度に取り扱える柔軟性を有する

OSSであるためどれだけクエリを実行しても料金は発生せず、必要なのは動作環境となるコンピューティングリソースの調達費用のみ

2025年1月3日時点のランキングでも注目度の高さが示されている

■ 7. ユースケース: 複数データソースのETLパイプライン

従来手法とその課題:

BigQueryやRedshiftを利用したDWH上での分散クエリ実行が一般的だが、クラスター管理負荷に加え分散クエリの実行単位で費用がかかる

DataflowやAmazon Managed Service for Apache Flinkによる分散バッチ処理も一般的な手法

分散データ処理基盤ではApache Beamのようなプログラミングモデルでの実装が必要で、学習コストや設計、開発負荷が増大する

DuckDBによる代替策:

用途に合わせて仮想マシン、コンテナ、サーバレス環境にDuckDBをデプロイし、ETLパイプラインをSQLで実装する

設計、開発、運用負荷を軽量化しながら、異なるデータソースからのデータセットを組み合わせた処理を実現できる

拡張機能を利用し、各種データソースからの読み込みやデータシンクへの書き込み処理をSQLで実装できる

■ 8. ユースケース: 大量ログファイルの解析

従来手法とその課題:

S3バケットに蓄えられた大量のアクセスログファイルの処理にはRedshiftやAthenaを利用する方法が一般的

これらスケールアウトモデルのデータベースは複雑なクラスター管理に伴う運用負荷が大きい

クエリ実行ごとに費用も嵩む傾向がある

DuckDBによる代替策:

DuckDBをEC2の仮想マシン内にデプロイし、DuckDBから直接S3バケットにクエリを実行する

運用コストを抑えつつ高速にデータを処理できる

具体的な実行方法:

仮想マシン内でDuckDB CLIを起動し、read_parquet関数でS3バケット内の複数ファイルを参照して必要なログのみを取得する

エビデンス提示が必要な場合はCOPY文でデータ形式を指定し、CSVなど別ファイルにクエリ実行結果を出力できる

■ 9. ユースケース: 移行期間中の新旧テーブル比較

従来手法とその課題:

pg_dumpなどで片方のデータベースにテーブルデータを複製する方法が一般的

dumpファイルの作成やテーブルデータのリストアにかかるオーバーヘッドと作業負荷が大きい

DWH上での比較もクラスター管理の運用負荷がかかり、フルスキャンによるクエリ実行費用も大きいため良い解決策にならない

DuckDBによる代替策:

DuckDBを仮想マシン内にデプロイし、移行前後の各データベースに対して直接クエリを実行する

テーブルデータ比較前のデータダンプが不要となり、高速かつ簡単に新旧テーブルデータの比較を実現できる

具体的な実行方法:

postgres_scan関数で移行前後の各データベースのテーブルを参照し、単一クエリ内で効率的にデータを比較する

EXCEPT句を用い、新から旧、旧から新の双方向でデータ差分を抽出する

■ 10. DuckDBを使うべきではない場面

テラバイト級のデータ分析処理を実行する場面

厳格なトランザクション管理や、並列書き込みに対する排他制御を必要とする場面

ストリーミングデータをリアルタイム、またはニアリアルタイムに処理する場面

Message QueueやPub/Subモデルの非同期メッセージング用データソース、データシンクを利用する場面

■ 11. 今後の展望

他ソフトウェアとの組み合わせ:

本稿ではDuckDBの基礎的な使い方と単体利用のユースケースを中心に紹介した

DuckDBの真価は他のソフトウェアと組み合わせることで発揮される

Modern Data Stack:

単一マシン上での高速なパイプライン処理を実現できるデータ活用基盤

DuckDB、Meltano、dbt、Apache Supersetの組み合わせで構成する

BemiDB:

分析用途に最適化されたPostgreSQL向けリードレプリカ

DuckDB、Apache Icebergの組み合わせで構成する

今後の取り組み:

DuckDB本体だけでなく周辺の関連ソフトウェア技術も積極的にキャッチアップし、継続的な情報発信に取り組む

(2026/08/29)

ITエンジニア必読書『徳丸本』が8年ぶりの改訂へ　「第3版」のポイントを筆者が解説：「個人情報漏えい」...

ITエンジニア必読書『徳丸本』が8年ぶりの改訂へ　「第3版」のポイントを筆者が解説：「個人情報漏えい」から「事業被害」へのシフトに対応（1/2 ページ） - ＠IT

要約:

■ 1. 徳丸本第3版への改訂

8年ぶりの改訂:

『体系的に学ぶ安全なWebアプリケーションの作り方』は2011年に初版、2018年にWeb API関連を中心に200ページ近く加筆した第2版を刊行

Web技術の進化と複雑化により新たなリスクや脆弱性が浮上したため、2026年現在は第3版への改訂に向けた執筆が進行中

第2版以降の最大の変化:

個人情報漏えいから事業被害へのシフトと捉えている

2026年7月のHack Fes. 2026で「徳丸本アップデート2026」と題し、最新動向と改訂ポイントを2部に分けて解説した

初版から貫く方針:

手を動かしながら勉強できること

実務に即したバランスの良い記述を心掛けること

「セキュリティのためなら会社が潰れてもいい」という極端な主張ではなく、事業を守るためのセキュリティを重視する

開発者だけでなく脆弱性診断員にとっても必携の書となっている

■ 2. 第3版の構成

実用性の高い順に配列:

新たな状況に対応した記述を追加するとともに構成も見直す

CORSの理解にはCSRFの知識が前提になるなど、順序立てての理解が必要なものは順に読み進められるよう整理する

セキュリティ要件に一章:

基礎知識、主要な脆弱性に続けて、丸々一章を割いてセキュリティ要件を記述する

第2版まであまり書いてこなかった、セキュリティ要件とは何か、どう組み立てるかをしっかり入れる

ブラウザセキュリティと技術的な基礎:

同一オリジンポリシー、CORS、CSP、TLS、DNS、文字コードに関する説明をまとめる

前半の章で触れられなかったレースコンディション（TOCTOU脆弱性）やHTTPリクエストスマグリング（HRS）といった高度な脆弱性にも言及する

古典的な脆弱性の章:

クリックジャッキングやOSコマンドインジェクションなど、時間がたちながらも現役の脆弱性は9章にまとめる

セキュア開発プロセス:

8章でCI/CD環境を前提としたツールやリスク分析のフレームワークを解説する

昨今話題となっているソフトウェアサプライチェーンの問題にも触れる

グローバルスタンダードへの追随:

OWASP ASVSがだいぶこなれてきたため、ASVS 5.0やNIST SP 800-63 Rev.4といった最新の基準に合わせる

■ 3. 実習環境のアップデート

Docker Composeベースの実習環境を用意する

従来のPHPに加え、Node.jsやLaravelなど現在の開発環境に即したフレームワークを題材に取る

OWASP ZAPに代えてBurp Suiteを用いた実習環境を用意する

■ 4. レースコンディションとTOCTOU競合

昔から存在する問題:

初版から言及しており、他人の個人情報が見えてしまう、ECサイトで在庫が1つしかないのに2人以上に販売できてしまうのが典型例

割とよく見つかっていた問題である

第3版で取り上げる背景:

厚生労働省をはじめ複数省庁のWebサイトで、レースコンディションに起因するセキュリティ問題が顕在化した

デジタル庁の「政府情報システムにおける脆弱性診断ガイドライン」でも、実装に起因する脆弱性の冒頭に「レースコンディションによるデータの不整合」が挙げられている

脆弱性診断員の友としての徳丸本を考え、レースコンディションもしっかり書く

TOCTOU競合の仕組み:

「もし在庫が1以上あれば、在庫を減らして注文を記録する」というif文はWebアプリケーションでよく見掛ける実装である

if文でのチェックからthenの処理を実行するまでのわずかな時間的ギャップを狙った事象がTOCTOU競合である

重要な同一ファイルが上書きされて他人の情報が見えたり、在庫が1つしかないのに複数人に販売してしまう事態が生じる

原因と対策:

原因はSELECT文による確認とUPDATEによる操作が不可分（アトミック）ではなく、別々に実行されている点にある

違和感があるかもしれないが、いきなりUPDATEする、もしくは行ロックをかけて排他制御をすることが重要である

実習環境での再現:

Burp Suiteを用い、自然なif・then文の処理でTOCTOU競合が起きることを再現できる環境を用意し、講演ではデモも披露した

対策を済ませれば適切な結果が返ってくることも確認できる

■ 5. HTTPリクエストスマグリング

診断で時折検出される問題:

Burp Suiteを用いた脆弱性診断で時折検出される

2つ以上のリクエストを1つに見えるよう細工して送信し、リバースプロキシなどによる検査をかいくぐる手法である

前提となるHTTP/1.1の仕様:

ボディーの長さを伝える手段には、長さを直接指定するContent-Length（CL）と、チャンク単位で分割送信するTransfer-Encoding（TE）の2種類がある

RFCでは両方が記述されている場合はTransfer-Encodingが優先されると明記されている

しかし仕様に反してContent-Lengthを優先してしまう実装が存在する

解釈の不一致が原因:

フロントエンドがCL、バックエンドがTEで解釈する「CL-TE」のパターンが実務的には圧倒的に多い

Nginxをリバースプロキシに用いた場合、TEを優先し転送時に不要なCLヘッダを削除するため、構造上HRSは起こり得ない

判定やヘッダの扱いが緩いリバースプロキシを挟んでいる場合にHRSが発生する

根本対策:

仕様に準拠し適切にヘッダを処理する、脆弱性のないリバースプロキシを使うというだけである

診断時にHRSというキーワードが出てきたらこのことを思い出してほしい

■ 6. JWTによるセッション管理

JWTはOpenID ConnectでIDトークンを用いるための形式であり、扱いやすさからセッション管理に広く用いられるようになった

推奨しない理由:

有効期間中は即時取り消しができないという欠点があるため、結論としてはあまりお勧めできない

攻撃手法:

辞書攻撃、「alg=none」攻撃、アルゴリズム交換攻撃といった非常に素朴で基本的な攻撃が存在する

第3版ではHRSと同様に実習環境で試しながら学べる

■ 7. セキュリティ要件の整理

問題意識:

セキュリティ要件の検討が不足したまま開発が進み、不正利用が発生してサービス終了に追い込まれた残念なWebサービスが幾つか存在してきた

発注段階からセキュリティ要件を明確にし、それに沿って開発を進めるべきという考え方が浸透しつつある

誰がどう決めるかが不明確:

そもそもセキュリティ要件を誰がどう決めるのかは、実はあまりはっきりしていない

発注仕様書には「個人情報が漏れないように作りなさい」といった当たり前であいまいな記述しかない場合がある

これだけでは見積もりもテストもできず、セキュリティ要件とはいえない

4つの観点:

セキュリティバグ（SQLインジェクションなどの狭義の脆弱性）

汎用セキュリティ機能の実装（認証・認可機能やログ機能など）

業界の規制・ガイドライン（PCI DSSやキャッシュレス推進協議会のガイドラインなど）

アプリケーション固有の脅威への対策

初版出版当時から自問自答を続けてきたテーマであり、第3版で整理して説明する

■ 8. アプリケーション固有の脅威

観点1から3までの3つはどのようなWebアプリケーションにも共通し、徳丸本でも言及してきたため、問題は4点目である

認識されにくかった背景:

Webアプリケーションには登場当初の「CRUDを簡単に作れる、掲示板みたいなもの」というイメージがつきまとってきた

それゆえアプリケーションごとの固有のリスクを把握する必要性が認識されにくかった

現在の状況:

Webアプリケーションは生活にもビジネスにも深く関わり、レストランでの注文にもチケット販売にも活用されている

転売業者がbotで人気商品を大量に買い占める問題のように、ビジネスロジック全体の問題をどう防ぐかという課題が浮上する

細かくばらせば既知の課題かもしれないが、Webシステム全体として見ると新たな課題となる

これこそが、1から3の問題のようにこれまでリスト化されてこなかったアプリケーション固有の脅威である

第3版では、ビジネスロジックに固有の脅威を洗い出す道具としてリスク分析にも触れる

シフトレフトの重要性:

アプリケーション固有の脅威はできるだけ早く検討・対策を実行し、お金がかかるのであれば予算も手当しておくべきである

上流で実施すべき重要な事柄である

■ 9. リスク分析の進め方

OWASP ASVS 5.0の位置付け:

アプリケーション固有の脅威に限らず、観点1や2を検討する際の参考になる

初めにリスク分析をして要件を決めるべきという記述もある

裁量部分の判断にリスク分析が必要:

セッションタイムアウト3時間は、オンラインバンキングでは長過ぎるが、頻繁に利用されるSNSでは利便性が損なわれる

必ず守るべき項目は抑えつつ、各Webサイトの裁量で決めるべき部分もあり、後者の検討にリスク分析が必要になる

一般的な流れ:

アプリケーションのゴールという目指す姿について合意する

資産・機能の洗い出し、脅威の洗い出し、影響度・発生可能性の評価、対応方針と対応の検討を経てセキュリティ要件を定義する

事業側の巻き込み:

情報資産だけでなく、機能や機能にひも付く事業被害を洗い出すことがポイントであり、ビジネス・経営的な観点も求められる

目指す姿の合意にはDevやOpsに加えBiz、つまり事業主体が非常に重要である

全てのセキュリティは経営マターだと考えるのであれば、事業側の責任者を連れてくる必要がある

STRIDEプラス1:

なりすまし、否認、サービス妨害なども考えられるWebサービスの特性から、脅威分析モデルのSTRIDEが参考になる

botによる大量購入のように正規の機能を悪用される脅威は枠組みからはみ出てしまう

無理にこじつけてSTRIDEに載せるくらいなら言葉で書き、STRIDEプラス1としてビジネスの問題として考える方がよい

リスク分析における4種類のアプローチと、回避・低減・移転・受容というリスク対応の4つの方針を紹介した

最終的には人間が判断を下す必要があるが、AIを壁打ちに利用するのも非常に便利である

■ 10. 脅威の洗い出しと評価の実践

ワークショップでは「レストランにおけるモバイルオーダーシステム」を例に、脅威の洗い出しと評価をする時間を設けた

洗い出しのヒント:

Webサービスに関わる関係者にはどのような人がいるかを想像し、それぞれの立場で考える

過去に発生した事例を調べ、蓄積しておく

アプリケーション固有のリスクもパーツに分解すれば他でも似たインシデントが起きているため、隣接領域の事例把握も有効である

評価の方法:

事象が発生したらどれくらい困るのかを3段階程度で分類し、発生可能性と掛け合わせてリスクの度合いを評価する

悪意ある顧客が他人のテーブルのQRコードを読み込んで注文する脅威は影響が中程度、発生可能性は高と評価した

解決策の検討姿勢:

セキュリティ原理主義に走らず、ビジネス的な視点も考慮する

場合によっては一定のリスクを受容する

システム的な改善だけでなく運用での回避も念頭に置く

「運用で対応」は批判されがちだが必ずしもそうとは限らず、効率的に対応できるのであれば選択肢の一つである

■ 11. 対策から要件への変換

列挙した対策がそのまま要件定義書に載るわけではない:

対策をそのまま記載すると、なぜそれが必要かという観点が失われてしまう

対策と要件を区別し、対策を満たすべき状態としての要件に変換していく

検証可能な記述:

あまりに抽象的な記述では何をどうしたらよいか分からなくなり意味がなくなる

要件からテストまでを一気通貫でできる記述が望ましい

最上流での実施:

開発のど頭である最上流でリスク分析をすることで、結果に基づき固有の要件を追加できる

汎用的なセキュリティ機能をどの程度満たせばよいかの水準も選択できる

アジャイル開発といえども、サービスの全体像を踏まえてどのようなリスクがあるかを上流で考えなければいけない

第3版では、リスク分析の指標としてOWASP ASVS 5.0の他、フランス国立情報局が作成したEBIOSというフレームワークを紹介する

■ 12. 結び

これまでふんわりとした議論に陥りがちだったセキュリティ要件も、アプリケーション固有の脅威を含めた4つの観点で整理することでより考えやすくなる

その際にはビジネス・事業責任者も巻き込んで検討することが重要である

日頃からリスクや脅威に対する思考を鍛え、習慣化しておくことが大切である

単純なものでも短時間でもよいので、ぜひ手を動かしてほしい

(2026/08/29)

Mark Zuckerberg had a bold plan to replace Meta staff with AI. Here’s how it imploded.

Mark Zuckerberg had a bold plan to replace Meta staff with AI. Here’s how it imploded. | Reuters

要約:

■ 1. Project OTの全体像

Project OTの発足:

2026年1月にハワイの邸宅で開かれた年次リーダーシップ合宿で、ザッカーバーグと側近が構想した組織変革計画

Organization Transformationの略で、FacebookとInstagramの所有企業に「AIネイティブ」な未来を描く

人間の業務のAIへの置き換え:

数千人の従業員が日々担う業務の多くをAIが引き継ぐ構想

仮想の労働者を、より小規模で「talent-dense」な人間の精鋭集団が社内で監督する形

最大60%の人員削減シナリオ:

シナリオプランニング演習で、全社の多くのチーム規模を最大60%削減する案を検討

一部の従業員は新設部署の役職を提示され、残りはレイオフの対象

3年前を上回る規模の想定:

人事幹部は、3年前の約25%の削減と同等かそれ以上の規模になると見積もった

2波構成の再編計画:

5月の第1波の粛清に続き、11月に第2の組織改編を行う二段構え

レイオフに加え、募集中ポジションの閉鎖と、低評価とみなした人材の追い出しで補完

直前での撤回:

5月19日の夜、第1波のレイオフ実施の数時間前にザッカーバーグが翻意

翌日に従業員の10%のレイオフは実施したが、11月の削減計画は取りやめ

撤回時点の社内状況:

従業員は公然と反乱状態にあり、AI変革が自分たちの置き換えを一部狙っていると確信していた

戦略の中核である自律型AIエージェント技術が期待した生産性向上をもたらしていないと社内データが示していた

巨額のAI支出に見合う成果を投資家の一部が問い質していた

取材の基礎:

多数の社内文書、投稿、録音と、社内事情を知る20人超との対話に基づく

未解明の点:

ザッカーバーグの方針転換を引き起こした直接の要因は特定できていない

人員構成の再編について現在どのような計画があるかも不明

■ 2. Metaの公式見解

Project OTの存在の認定:

コスト削減、チーム構造の再設計、新重点領域への人員移動に注力した1年間のプロジェクトと説明

新重点領域の例として、AIモデル用の訓練データ生成を挙げた

2波構成と60%削減の認定:

最も抜本的なシナリオでは一部チームの規模を最大60%縮小する内容だったと認めた

対象部署の特定は拒否し、いくつかの主要部門は対象外だったと説明

全社の60%解雇の否定:

シナリオにはレイオフと再配置の双方が含まれ、全従業員の60%を解雇する意図は一切なかった

第2波中止の時点:

全体で何人が職を失うかを確定する前に、経営陣が第2波の計画を取り消した

演習という位置づけ:

再配置、募集ポジションの閉鎖、削減の潜在的影響を検討するシナリオプランニング演習を一部チームに依頼したもの

結果として数千人が新設チームの優先業務へ異動した

演習の全シナリオを実行したわけではなく、実行を前提としてもいなかった

■ 3. AIネイティブ思想の流入

生成AIへの期待:

2022年末のChatGPT公開以降、シリコンバレーの経営者は生成AIが解き放つ働き方の革命的可能性を思い描いてきた

エージェント技術の位置づけ:

質問に答えを返すだけのチャットボットと異なり、買い物、旅行予約、アプリ作成などの自律的行動を担う新興技術

「AIネイティブ」への傾倒:

既存プロセスにAIを組み込むのではなく、完全にAIネイティブへ移行すべきというスタートアップ発の発想に幹部が魅了された

Project OT文書は、AI対応のツールとエージェントが相互作用し、ワークフローが自動化され、新規開発はAIファーストになる姿を描いた

AIエージェントの外販:

予約調整や成約などの業務を担うAIエージェントを他社に販売する構想も戦略に含む

アジア視察:

最高データ責任者アレックス・シュルツと製品責任者ナオミ・グレイトが昨年アジアを訪問

現地スタートアップがAIを軸に組織図を構築している点を高く評価した

独自調査とパイロット:

AIスタートアップの組織編成に関する独自研究を委託

社内で「AIネイティブ」が何を意味するかを見極めるパイロットを設置

グレイトの説明:

シンガポール拠点で相当の時間を過ごし、その慣行がカリフォルニアとニューヨークのチームを触発した

アイデアの多くはボトムアップで、一部の従業員は自ら変革を実装し始めていた

■ 4. パイロットと「AI-Native Playbook」

アーチボンによる先行実験:

製品管理担当バイスプレジデントのイメ・アーチボンが昨年7月、製品開発を近代化する第一歩を社内投稿で公表

バスケットボールの比喩:

速攻を取り入れればより多く、より良いシュートが打てるのと同じで、AIツールは低コストかつ高忠実度で多くのアイデアを探索させる

AIで素早く作った試作品は従来より完成品に近づく

単に楽しいだけでなく、AIファーストの時代にはそれが勝つ戦略である

経営トップの同調:

ザッカーバーグも半年後の決算説明会で、AIが仕事をずっと楽しくする可能性に言及した

「small tech pod」の構成:

エンジニア2〜3名とデザイナー1名にAIツールを持たせた5つのポッドを設置

6か月の固定計画サイクルなど確立された製品リリース手順を廃止

4週間の「スプリント」で試作品を作ることを目指す

「builder」への職種統合:

10月の社内投稿「AI-Native Playbook」が、他チームが移行するための指針を提示

製品デザイナーやエンジニアの伝統的職務は消滅し、ポッド構成員は「builder」という汎用の肩書きを得る

中間管理層は排除され、ポッドは単一の上位ユニット長へ直接報告する

エージェント支援の優先順位付け:

日々の優先順位設定を「Agent-assisted analysis」が支援する

展開状況:

年初にザッカーバーグがProject OTを始動させ、管理構造の変更を進めるよう幹部に指示

6月までにエンジニアリングや研究を含む11以上のユニットが小規模ポッドを導入

■ 5. 新しい組織構造と人事運用

チーム構成の対比:

従来の製品開発は10〜20名で、役割ごとに期待が明確な専門分化型

AIネイティブ型は3〜5名で、必要な作業を何でも担う流動的な役割と、方向づけを担うリード1名で構成

デザイン、UXR、データサイエンス、データエンジニアリング、機械学習の専門職はポッド横断でプール

組織階層の対比:

従来は少数の大きな柱の下に大きなチームが連なる多層のヒエラルキー

新型はより平坦で機動的な多数の小ポッドが、同等以上の領域をカバーする

「village approach」:

人事評価と昇進は「Org Lead」と呼ばれる上位ユニット長が決定

人事担当者と、内容が明示されない「AIシステム」がその決定を支援する

ユニット長1人が30〜50人を統括する

Pod Leadの権限:

小ポッドの日々の運営を担うが、正式な人事管理権限は持たない

現場の混乱:

ポッド管理を任された社員が、管理職研修も評価ツールへのアクセスも与えられていないと社内掲示板に投稿

評価主体に関するMetaの説明:

各チームがより機敏になる方法をさまざまに実験したと説明

「AIシステム」への言及の説明は拒否し、評価と昇進の決定はAIではなく人間が行っていると主張

「Irreplaceable Talent」ツール:

代替不能な人材を特定する新しい人事ツールを同時期に導入

10人分の働きをするという「10X Performer」の仮想像を提示した

極めて優秀な個人がチーム全体分の仕事をこなせるとAI信奉者が信じる中で、この古い型が再び流行している

レイオフ原資の再配分:

削減で得た資金の一部を、特にAIエンジニアリングの花形人材を獲得し引き留めるための巨額報酬に充てる意図

■ 6. 従業員の反乱

報道による発覚:

3月13日、副社長級の多くがProject OTの説明を受ける前に、20%以上に及びうるレイオフ計画が報じられた

2022年末から2023年初めに約25%を削減した前例があり、同規模は初めてではない

情報漏れへの反応:

現場は動揺し、まだ知らされていないはずの削減が露見したことでザッカーバーグは苛立った

幹部は反発への備えができていなかった

広報担当者は当時、理論上のアプローチに関する憶測記事と切り捨てた

経営陣の火消し:

記事を現場と議論せず、上級管理職には静かに否定

AIによって役割が「進化する」と部下へ伝えるよう指示するトーキングポイントを用意

4月の追加報道:

5月20日の第1波で約10%を削減し、下半期にさらに人員を減らす方針が報じられた

Metaは10%削減を社内で認め、ザッカーバーグは巨額の設備投資が理由だと従業員へ説明

訓練データ生成への配置転換:

一部エンジニアを新設のApplied AI Engineeringへ異動させた

AIモデルのコーディング能力を高める訓練データとして、ソフトウェア工学のパズルを作らせた

多くの社員がこの作業を機械的で退屈だと社内投稿で揶揄した

再配置の成果に関するMetaの主張:

再配置は成果を出し始めており、同ユニットが生んだデータが先月公開したAIモデルの訓練に役立った

人員の減少幅:

一部のエンジニアリングユニットでは、異動と削減により5月末までに人員が最大30%減少

キーストローク追跡の義務化:

米国従業員の端末に追跡ソフトの導入を義務づけ、キー入力とマウスクリックを取得

人間のコンピュータ操作をAIエージェントに再現させるための訓練が目的

Workplaceでの抗議:

自分のAI後継者を訓練させられているかもしれないと考え、レイオフの説明不足にも憤った

社内ネットワークWorkplaceが怒りの長文と自虐的な冗談で溢れた

象の画像による皮肉:

幹部の社内投稿に対し、レイオフが「部屋の中の象」であることを示す象の画像で返信

幹部との衝突:

AI変革を統括し投稿で擁護していたCTOアンドリュー・ボズワースと社員が直接衝突

中小企業向けAI施策の告知を、人類に火を与えたプロメテウスになぞらえて皮肉る者もいた

士気の低下:

半期のPulse調査で、社内の従業員感情の指標が肯定的74%から55%へ低下

労働組合結成の動きが勢いを増した

■ 7. AI技術の期待外れ

コード量と成果の乖離:

AIの利用で生成されるコード量は激増したが、生産性への効果は疑わしい

社内の開発基盤とインフラへのコード変更は前年比220%増

一方、ユーザーに届く新機能や改良につながった変更は36%増にとどまった

信頼性の警告:

3月時点でインフラチームが、AIコーディングの急増による「信頼性の警告サイン」を指摘

暴走するエージェント:

4月の投稿は、制御されないAIエージェントが人間なら実行しない大規模かつ破壊的な操作を行っていると報告

インシデントの急増:

サービス障害やデータ漏洩の可能性を含む重大な技術・セキュリティ事案が前年比40%増

その対応に費やす時間は70%増

顧客サポートボットの悪用:

6月初旬、新しいAI搭載の顧客サポートボットをハッカーが悪用し、著名Instagramアカウントへ侵入

休眠状態のオバマ政権ホワイトハウスのページも被害を受けた

■ 8. 方針転換と沈静化

第2波の中止:

5月20日の第1波実施の数時間前にザッカーバーグが側近と再度協議し、11月に予定した第2波を取り消した

安定の約束:

通知後、今年これ以上の全社的レイオフは想定していないとWorkplaceに投稿

従業員により大きな「安定」を与えたいと表明した

士気回復策:

ユニット長に対し、従業員の感情を受け止めるよう促した

マウス追跡プログラムを一時停止した

新AIエンジニアリングユニットの一部社員に元のチームへの復帰を認めた

最高財務責任者スーザン・リーを福利厚生の拡充に投入した

待遇改善の具体策:

レイオフ後の数週間、共感を示す幹部の投稿がWorkplaceに相次いだ

オフィスのマイクロキッチンの軽食の質向上を約束した

出張費と社交イベント費の増額を約束した

タウンホールでの釈明:

7月初旬に社内タウンホールへ不意に登場し、組織改編のタイミングを読み違えたと認めた

AIエージェント技術は想定したほど加速しなかった

今後3〜6か月で技術は改善し、より多くの便益を示し始めると期待している

■ 9. 「betting on people」への転回

広報攻勢:

社内AI変革の最も破壊的な部分を後退させる一方、人間中心の企業としてMetaを位置づけるPRを開始

「betting on people」と宣言する動画広告を投入した

6,500語のエッセイ:

AIエージェントの作成をより使いやすくする計画を強調

名前を伏せた競合こそが真の雇用破壊者だと描いた

自社の立ち位置の主張:

業務の自動化を主眼とするのではなく、全製品を通じて何十億人にこの新技術の力を渡し、人々に力を与えることに注力する唯一の大手企業である

限定的な言葉遣いへの疑念:

レイオフを語る際に「全社的」と「今年」という限定語を使い続けている

チーム単位の削減や成績不良を理由とする解雇が続くと社員は推測している

全社的な人員削減が来年へ先送りされるだけだという見方もある

資金面の圧力:

目のくらむようなAI支出により、資金繰りの逼迫と投資家の監視に直面し、節約の圧力が高まっている

今年AIチップなどのインフラに最低1,300億ドルを投じる計画で、2026年の営業キャッシュを食い尽くすとアナリストは見込む

将来の雇用予測:

エッセイ「The Future is for Everyone」で、将来は仕事が豊富に存在しうると予測

産業界の巨人からテック企業への移行時と同様、企業の規模は縮小しうる

ただし仕事の総量が減るのではなく、少人数の企業がより多く存在する形になる

(2026/08/28)

Claude Codeで「計画なき実装」を卒業する ― Boris Tane流 Research-Plan-Implementワークフロー実践ガイド

Claude Codeで「計画なき実装」を卒業する ― Boris Tane流 Research-Plan-Implementワークフロー実践ガイド #AI - Qiita

要約:

■ 1. 計画なき実装という失敗

Claude Code初学者が陥るパターン:

プロンプトを打ち、エラーを修正し、また打つという繰り返しに終始する

Claudeが誤った仮定の上に15分かけてコードを積み上げ、最終的に全部巻き戻す羽目になる

失敗の根本原因:

構文エラーでも論理バグでもなく、孤立しては動くが周囲のシステムを壊す実装にある

事前調査なしに実装へ突進することで生まれる

周囲を壊す実装の具体例:

既存のキャッシュレイヤーを無視する関数

ORMの規約を考慮しないマイグレーション

すでに存在するロジックを重複するAPIエンドポイント

出典と著者:

Cloudflareエンジニアリングリード（前Baselime創業者）のBoris Tane氏が9ヶ月間の使用で確立したワークフロー

2026年2月10日公開の "How I Use Claude Code" が原典

想定読者:

Claude Codeをある程度使っているが、大きなタスクで迷走してしまうと感じている開発者

■ 2. ワークフローの全体像

核心原則:

書面による計画を確認・承認するまでコードを書かせない

計画と実行を分離することで、無駄な作業を防ぎ、アーキテクチャ上の決定を自分の手元に置ける

4ステップのフロー:

Research → Plan → Annotation Cycle（1〜6回） → Implementation

具体的な流れ:

Claudeがコードベースを調査し、research.mdに結果を記録する

開発者がレビューし、Claudeがplan.mdを作成する

開発者がエディタでインラインノートを追加し、Claudeがノートを反映してplan.mdを更新する

満足するまで繰り返した後、Todoリストをplan.mdに追加する

"implement it all" で実装を一気に開始する

各フェーズが防ぐ失敗:

Researchは無知な変更、すなわち既存システムを理解せずに実装することを防ぐ

Planning + Annotationは誤った変更、すなわち早期の誤った仮定の上に構築することを防ぐ

Implementationは無秩序な実装、すなわち途中で方向転換を繰り返すことを防ぐ

■ 3. Phase 1: Research

Deep Read Directive:

表面的な読み込みではなく深く理解することを明示的に指示するプロンプトパターン

通常のClaudeはファイルを開き、関数のシグネチャレベルで理解してそのまま先へ進む

それでは周辺システムとの依存関係や暗黙の規約を見落とす

フォルダ全体を理解させるプロンプト:

read this folder in depth, understand how it works deeply, what it does and all its specificities. when that's done, write a detailed report of your learnings and findings in research.md

特定システムを調査するプロンプト:

study the notification system in great details, understand the intricacies of it and write a detailed research.md document with everything there is to know about how notifications work

バグを探すプロンプト:

go through the task scheduling flow, understand it deeply and look for potential bugs

バグが確実に存在する根拠を伝え、すべて見つけるまで止まらずに調査を継続させ、research.mdに報告させる

効果を左右するキーワード:

"deeply" は深い分析を要求する

"in great details" は詳細な調査を促す

"intricacies" は複雑な仕組みまで調べさせる

"keep researching... until" は止まらずに調査を継続させる

これらの言葉は飾りではなく、なければClaudeはスキミングする

research.mdに書かせる理由:

レビュー面として機能し、Claudeが本当にシステムを理解しているかを検証できる

調査が間違えば計画も実装も間違うため、誤りを最も早い段階で捕捉できる

ファイルとして残るため、セッション中にコンテキストが圧縮されても参照できる

■ 4. Phase 2: Planning

組み込みPlan Modeを使わない理由:

エディタで直接編集でき、次のAnnotation Cycleの核心となる操作が可能になる

プロジェクトの実成果物として残り、セッションを超えて参照できる

ファイルシステム上に存在するため、コンテキスト圧縮を乗り越えられる

新機能を計画するプロンプト:

機能名と説明、実現するビジネス上の成果を示し、詳細なplan.mdをコードスニペット込みで書かせる

既存機能の変更を計画するプロンプト:

listエンドポイントをオフセットからカーソルベースのページネーションに変更する方法をplan.mdに書かせる

"read source files before suggesting changes" を明示し、実際のコードベースに基づかせる

これによりコードベースを読まずに一般的な実装パターンを提案することを防ぐ

参照実装を活用するテクニック:

オープンソースで良い実装を見つけたら、そのコードを参照として共有すると劇的に良い結果が得られる

ソータブルIDの実装例を示し、同様のアプローチを採用する方法をplan.mdに説明させる

ゼロから設計させるより、実際のコードの形・データ構造・エッジケースの扱い方を正確に把握した計画が立つ

■ 5. Annotation Cycle

ワークフロー全体の価値の大半を担う工程:

plan.mdにインラインノートを直接書き込み、Claudeに更新させることを1〜6回繰り返す

ドメイン知識、製品優先順位、エンジニアリング上のトレードオフを計画に注入する唯一の場所

手順:

Claudeが作成したplan.mdをエディタで開き、問題のある箇所にインラインノートを直接追加する

ノートをすべて反映してドキュメントを更新するよう指示し、まだ実装しないよう明示する

満足するまでこの往復を繰り返す

最後に、全フェーズと個々のタスクを含む詳細なTodoリストを計画に追加させる

インラインノートの5パターン:

ドメイン知識の注入は "use drizzle:generate for migrations, not raw SQL" のように未知の制約を伝える

誤った仮定の修正は "no — this should be a PATCH, not a PUT" のようにHTTPメソッドの誤りを直す

アプローチの却下は "remove this section entirely, we don't need caching here" のように不要な実装を削る

短い指摘は "not optional" の2語でパラメータの必須性を修正する

セクション全体のリダイレクトは、可視性フィールドの持ち先が誤っている旨とスキーマ節の再構成を指示する

ノートの粒度:

長さは2語から段落まで状況によって異なる

重要なのは問題のある箇所に直接書き込むこと

"don't implement yet" ガード:

明示しなければ、Claudeは計画が十分になったと判断した瞬間に実装を開始する

計画の完成を判断するのはClaude自身ではなく開発者である

常に使うことで判断権を手元に置き続けられる

有効である理由:

Markdownファイルが共有可変状態として機能する

正確な箇所を指摘できるため精度が上がり、Claudeの理解がずれない

段落で説明する代わりに問題箇所に2語で書けばよく効率が上がる

このプロジェクトではdrizzle:generateを使うといったドメイン知識が計画に蓄積される

3ラウンドの効果:

3ラウンドの "added notes, update the plan" で、汎用的な実装計画を既存システムに完璧にフィットする計画へ変えられる

Todoリストによる進捗可視化:

Annotation Cycleの最後に追加したリストが実装フェーズ全体の進捗トラッカーになる

Claudeがタスク完了ごとにリストを更新するため、数時間のセッションでも現在地を一目で把握できる

■ 6. Phase 3: Implementation

標準実装プロンプト:

ほぼすべての実装セッションで同一のプロンプトをそのまま再利用する

implement it all. when you're done with a task or phase, mark it as completed in the plan document. do not stop until all tasks and phases are completed. do not add unnecessary comments or jsdocs, do not use any or unknown types. continuously run typecheck to make sure you're not introducing new issues.

各フレーズの意図:

"implement it all" は計画のすべてを実行させる

"mark it as completed in the plan document" は計画を進捗の唯一の信頼できる情報源とする

"do not stop until all tasks and phases are completed" は途中で確認を求めさせず中断なく実行させる

"do not add unnecessary comments or jsdocs" はコードをクリーンに保つ

"do not use any or unknown types" はTypeScriptにおける厳密な型付けを維持する

"continuously run typecheck" は問題を最後ではなく途中で検出する

実装はつまらないほど良い:

計画が正しければ実装は機械的な作業になる

創造的な判断はAnnotation Cycleで終わっており、実装はボーリング（退屈）であることが望ましい

実装中のフィードバックは短くする:

計画段階のノートが段落レベルなら、実装中の修正は1文で十分である

Claudeはセッション全体の文脈を持つため、短い指摘でも意図を理解できる

"wider"、"still cropped"、"there's a 2px gap" のような指摘で足りる

特定関数を未実装である旨や、設置先アプリを誤っている旨も1文で伝える

視覚的問題の伝達:

フロントエンドではスクリーンショットを添付することで視覚的な問題を素早く伝えられる

既存コードの参照:

このテーブルをusersテーブルと全く同じ見た目、同じヘッダー、同じページネーション、同じ行密度にすると指示する

既存コードを参照することで暗黙の要件をすべて伝えられる

間違った方向に進んだらリバート:

段階的な修正より、リバートしてスコープを絞る方が速い結果につながる

すべてリバートした上で、リストビューをよりミニマルにすることだけを求めると宣言し直す

悪いアプローチをパッチで修正するより、gitで変更を捨てスコープを絞って再実行する方が常によい結果を生む

■ 7. Single Long Session戦略

1セッションで完結させる:

Research、Planning、Implementationを1つのセッションで完結させる

セッションの分割は情報損失を招く

典型的なセッションの流れ:

フォルダの深読みから開始する

計画のAnnotation Cycleを3ラウンド行う

完全な実装を実行する

これらをすべて単一の継続的な会話で行う

コンテキスト50%超で性能劣化するという通説:

自身の経験上、この劣化は確認していない

むしろ逆で、"implement it all" と言う時点でClaudeはセッション全体を通じて理解を積み上げている

調査中にファイルを読み、Annotation Cycleでメンタルモデルを精緻化し、ドメイン知識の修正を吸収している

積み上げた理解がコードベースに即した実装を可能にする

コンテキスト圧縮への耐性:

コンテキストウィンドウが満杯になると自動圧縮が実行される

plan.mdとresearch.mdはファイルシステム上の永続的な成果物であり、圧縮が発生しても完全な状態で残る

任意の時点で "refer to plan.md" と指示すれば文脈を即座に取り戻せる

■ 8. ハンズオン例: カーソルページネーション

シナリオ:

既存のAPIエンドポイントに、オフセットベースではなくカーソルベースのページネーションを追加する

Step 1 Research:

対象ファイルのlistエンドポイントを詳細に調査させ、現在のページネーション、データモデル、ORM固有の規約を理解させる

発見内容を詳細なresearch.mdに書かせる

現在はoffsetとlimitを使う、ORMはDrizzleを使う、既存のレスポンス型はListItemである、といった事実が正確かを自分で確認する

誤解があればこの時点で修正を指示する

Step 2 Plan:

調査結果を確認してから、カーソルベースへの移行方法を説明する詳細なplan.mdをコードスニペット込みで作成させる

"read the source files before suggesting changes" の指示が重要である

これにより一般的なカーソルページネーションのパターンではなく、このコードベースの実際の構造に基づく計画が生まれる

Step 3 Annotation Cycle:

カーソルの主フィールドをid、副ソートキーをcreatedAtとし、base64で単一文字列にエンコードすべきとノートする

最初のページにはカーソルがないため、カーソルはオプショナルであるべきとノートする

マイグレーションはraw SQLではなくdrizzle:generateを使い、規約はresearch.mdを参照するようノートする

ノート反映を指示して更新させ、必要なら再度ノートを追加して繰り返す

計画が正確だと判断したらTodoリストを追加させる

Step 4 Implementation:

標準実装プロンプトで実装を開始する

実装中は必要に応じて短い修正指示を出すだけでよく、計画が正確であれば実装はほぼ機械的に進む

■ 9. まとめと導入手順

ワークフローの一文要約:

深く読み、計画を書き、正しくなるまで計画に注釈をつける

その後Claudeに途中で止まらずすべてを実行させ、その間中型チェックを続ける

特別な仕掛けは不要:

魔法のプロンプトも、精巧なシステム指示も、巧妙なハックもない

思考と実装を分離する、規律あるパイプラインがあるだけである

段階的な始め方:

まず次のタスクをPlan Modeの代わりにresearch.mdから始める

次に "don't implement yet" を意識的に使い始める

そしてplan.mdにインラインノートを書き込むAnnotation Cycleを1回だけ試す

各フェーズの役割と成果物:

Researchはコードベースを深く理解し、research.mdを産出する

Planningは実装計画を立て、plan.mdを産出する

Annotation Cycleはドメイン知識と判断を計画に注入し、更新されたplan.mdとTodoリストを産出する

Implementationは承認済み計画を機械的に実行し、コードを産出する

実践による効果:

計画なきAIコーディングの混乱から抜け出し、AIを道具として制御下に置ける

(2026/08/28)

DuckLabs to Join AWS, Projects to Remain Open Source

DuckLabs – DuckLabs to Join AWS, Projects to Remain Open Source

要約:

■ 1. AWSへの参画発表

DuckLabsのAWS参画:

9月初旬に発効する見込みであると本日発表

チーム体制の継続:

アムステルダムに留まり、DuckDB、DuckLake、Quack、および広範なコミュニティに関する活動を継続

参画により得られるもの:

この技術をより多くの開発者と組織に届けるための資金力とリーチを獲得

単独では到達が困難だった規模でアイデアを追求できる

プロジェクトの基盤維持:

DuckDBとDuck Stackのオープンソース構成要素はMITライセンスの下で無償かつオープンソースのまま

非営利のDuckDB Foundationがプロジェクトの管理を継続

今回の位置づけ:

大いに誇りとする一つの章の終わりであり、DuckDBをさらに前進させうる新たな章の始まり

■ 2. これまでの歩み

DuckLabs設立の目的:

5年余り前、DuckDBを支えるチームに安定した長期的な拠点を与えるために創業

ブートストラップという選択:

機能の優先度付けを求める最初の商用契約が具体化し、ベンチャーキャピタルからの打診もあった時期

創業者と開発チームが完全に所有する自己資金経営の会社という別の道を選択

選択がもたらした価値:

辛抱強く作り、技術を最優先し、始めた理由を見失わずに成長する自由を得た

オープンソースプロジェクトを囲む小さな集団から、アムステルダムの30人超のチームへ成長

DuckDBの到達点:

1日あたり100万回を超えるダウンロードを記録

世界中の開発者がデータ探索、製品の駆動、教育、研究、想定外のシステム構築に利用

その光景の意味:

職業人生における大きな特権の一つ

■ 3. 既存モデルの限界

成長が支援能力を追い越す懸念:

小さな会社がプロジェクト、チーム、その上で事業を築く人々のボトルネックになりかねない

組織拡大による焦点のずれ:

販売・サポート・運用組織を大規模化すれば、成功の源泉である技術的作業とオープンソースコミュニティから注意が逸れる

パートナーシップの偏り:

自社に相当なデータベース専門知識を持つ、高度に技術的な組織との協業で最も機能してきた

より広い層へ届けるための要件:

より完全で専門的な問題の解決と、異なる産業のニーズへの対応

インフラへの大幅な追加投資と、分析データベースを自ら探そうとは考えない人々への到達

到達目標:

DuckDBの革命はさらに2桁規模で成長しうると確信し、その機会を与えるには異なる体制が必要と判断

■ 4. AWSを選んだ理由

1年以上にわたる協業の実績:

両チームの協働の仕方、互いが持ち寄れるもの、組み合わせで可能になることを理解した経験が次の一歩への確信となった

共同で目指す方向:

DuckDB、DuckLake、Quackを用いて新世代のデータサービスを支える

直接利用する人も、製品やサービスの内側で気づかずに触れる人も含め、日常的にDuck Stackに依存する人々へ到達する

チームにとっての意味:

最も大切にする技術的作業に集中しつつ、単独では容易に達しえない規模で活動する余地が生まれる

より遠くを見据え、大胆になり、難しい問題に取り組み、DuckDBの背後にある発想をより多くの人に届けられる

AWSの長期的な関与:

DuckDBと広範なコミュニティの継続的な開発を長期にわたり支援すると確約

AWS側の評価:

Andy Warfieldは、DuckDBを素晴らしいコミュニティを持つ傑出したオープンソースプロジェクトと評し、S3顧客に広く使われ愛されていると指摘

約2年の協業を経て、プロジェクトがより広い影響力を持つことに貢献できる機会に期待を表明

DuckLabsチームを、技術的に最も深く、謙虚で、高速に動くチームの一つと評価

■ 5. 変わらないもの

ライセンスと管理体制:

DuckDB、DuckLake、QuackほかDuck Stackのオープンソース構成要素はMITライセンスの下で無償かつオープンソースのまま

非営利のDuckDB Foundationが引き続き管理し、チームは貢献を続けアムステルダムに留まる

オープン性の位置づけ:

利用者、貢献者、プラットフォーム、ベンダーからなる広いコミュニティに引き続き奉仕する

DuckDBを繁栄させたオープン性は将来も中心であり続ける

コミュニティの信頼:

寄せられた信頼を深く重んじており、その保護が本件の全過程で最も重要な考慮事項の一つ

CWI側の見解:

Peter Bonczは、DuckLabsがCWIからスピンアウトした際に設立された財団がオープンソース版DuckDBのIPをすべて保有し続けると説明

AWSの関与がイノベーションを加速させると見込み、財団を通じて支援者とコミュニティ全体の声が届き続けるようにすると表明

DuckDBは研究グループの多くの発想をオープンソースで実現した最先端技術だと位置づけ

研究・教育側の見解:

Torsten Grustは、DuckDBのオープン性、極めて高い改造しやすさ、友好的な開発者コミュニティが、同システムを研究と教育の主要基盤にしたと指摘

カーネルを検査し手を加えられることが研究と教育の双方に不可欠であり、AWSの傘下でもオープンソースが維持される点を歓迎

■ 6. 拡張する計画

技術諮問委員会の設置:

DuckDB Foundationに設け、主要なコミュニティメンバーがプロジェクトの技術的方向性へ意見を提供できるようにする

拡張機能スタックの開放:

他の開発者や組織が署名した拡張機能をDuckDB上で実行できるようにする計画

今後の情報公開:

詰めるべき詳細が多数残っており、計画の進展に応じて順次共有

■ 7. エコシステムからの評価

MotherDuck CEOの見解:

Jordan Tiganiは、AmazonがDuckDBを後押しすることで大きな勢いが加わりエコシステムが強化されると評価

分析の未来を築く基盤としてDuckDBを信じる者にとって朗報と位置づけ

Fivetran CEOの見解:

George Fraserは、AmazonをDuckLabsにとって理想的な受け入れ先と評価

DuckDBはベンダー中立なオープンデータスタックの中心であり、Amazonのオープン性への関与とクラウドエコシステム全体との協業実績がその役割の継続を可能にすると指摘

■ 8. 次の章

成功の帰属:

DuckDBの成功は常にDuckLabs内部の人々よりはるかに大きなコミュニティに属してきた

利用、コードの貢献、バグ報告、拡張機能の執筆、質問への回答、ベンチマークの公開、授業、製品構築、前提への異議、他者への推薦のすべてが今日の姿を作った

支援への姿勢:

その支援と背後にある信頼を当然のものとは受け取らない

今後の展望:

Duck Stackをはるかに大きな聴衆に届けつつ、その中核にあるオープンソース技術への投資を継続する機会を得た

ここまで導いた好奇心、配慮、技術的野心を保ち、全行程を共にしてきたチームとともに次の章へ進む

(2026/08/28)

AWS and DuckLabs: Building the future of analytics together

AWS and DuckLabs: Building the future of analytics together | AWS Big Data Blog

要約:

■ 1. DuckLabs買収の発表

Amazonによる買収合意:

オープンソースの分析データベースDuckDBを開発するアムステルダム拠点のDuckLabsを買収する最終合意に署名

通例のクロージング条件を満たし次第、取引は間もなく完了する見込み

創業者の処遇:

DuckDBを開発しDuckLabsを共同創業したHannes MühleisenとMark Raasveldtは、AWSの一員としてチームとOSSの技術的方向性を率い続ける

OSSプロジェクトの継続性:

DuckDBのOSSプロジェクトは引き続きDuckLabsチームが推進する

DuckDBを統括する非営利の独立FoundationのもとでオープンソースとしてMITライセンスで提供される点は現状のまま変わらない

■ 2. データ領域におけるAWSの実績

データは企業の中核資産:

組織が推論のカスタマイズやAIエージェント構築に自社データを用いる現在、その重要性はかつてなく高まっている

20年にわたるデータ分野の開拓:

あらゆる企業にデータレイクをもたらすAmazon S3の提供開始を起点とする

クラウド初の分析サービスAmazon EMR、クラウド初のデータウェアハウスAmazon Redshift、AthenaやGlue ETL等の多数の機能を投入してきた

継続中の技術革新:

S3 TablesでのApache Iceberg機能の直接提供、データレイクへのベクトルストレージ、Gravitonベースの新しい最適化Redshiftクラスタ

■ 3. DuckDBの成り立ちと設計思想

研究機関発の起源:

HannesとMarkは、Pythonを生んだオランダの国立研究所CWIに在籍中にDuckDBを開始した

既存エンジンの盲点:

従来のデータベースやSparkのような分析エンジンは超大規模データ処理の性能に注力していた

大半の顧客がSQL分析で日常的に扱う小規模データのクエリへ有効に「スケールダウン」する手段を欠いていた

狙う領域:

世界のデータクエリの90%超を占める、分析やダッシュボード用途で1テラバイト以下を扱うクエリを圧倒的に高速化する

アーキテクチャ上の選択:

日常的なSQLクエリを極めて高速にするという前提に基づき、アプリケーションとインプロセスで動作する

アプリケーションとのデータ交換が単純化され高速化される

ベクトル化実行による性能:

SELECT * FROM tableのような単純な文の実行に重いコンパイラを必要とせず、大きな性能向上を得る

■ 4. AIエージェントとの親和性

エージェントは人間に似た振る舞いをする:

突ついて試し、本当にやりたいことを見極める前に小さなデータセットで探索的分析を実行する

日常クエリ向けの最適化がそのまま効く:

日常的なクエリに効くものはエージェントにも非常によく効き、DuckDBは結果的にAIエージェントの利用に自然に最適化されている

学術プロジェクトからの普及:

使いやすさと生の性能により、データエンジニアリング、データサイエンス、分析、そしてAIエージェントの領域で広く採用されている

■ 5. AWSサービスとの統合構想

得意領域の組み合わせ:

1テラバイト以下の日常クエリにおけるDuckDBの強みを活かす

数百テラバイトからペタバイト規模の分析を支えるS3の実績あるエクサバイト超のエンタープライズ規模と、Redshift、Athena、EMR、Glue-ETL、SageMakerプラットフォームを組み合わせる

技術的背景の解説:

AWS Distinguished EngineerのAndy Warfieldが、Werner VogelsのAll Things Distributedブログで分析の変わりゆく物理法則とDuckDBについて論じている

■ 6. 顧客での利用実態

外部ファイルへの直接クエリ:

ローカルまたはS3等のクラウドストレージ上のParquet、CSV、JSONに対しSQLを直接実行し、比類ない性能と大幅な低コストを実現する

Allen Instituteの事例:

Scientific Computing担当Executive DirectorのDavid Fengが、大規模かつマルチモーダルなデータの広範な分析を伴う研究の加速を語る

2025年からテラバイト級の科学データ分析にDuckDBを使い始めた

神経生理学・行動データのリアルタイム品質管理と分析のためS3にデータを保存し、次のデータ取得の判断に役立てている

数分かかっていたクエリが1秒未満で返るようになり、まったく新しいデータとの対話方法が可能になった

Lambdaでの動作:

DuckDBはAWS Lambda関数にインプロセスで動作させることもできる

■ 7. AWS内部での採用

Amazon Quickでの選定:

独自ダッシュボーディングエンジンの性能増強にあたり、S3 Tables上のデータへのクエリ実行手段としてDuckDBを採用した

採用理由:

DuckDBエンジンはCPU数に応じて容易にスケールする

単一ライブラリとしてQuick内部のコントロールプレーン各サブシステムへ容易に組み込める

実績値:

2025年10月のQuick提供開始以降、DuckDB統合と最適化を組み込んだ独自クエリエンジンで25億件超のクエリを処理した

これらの統合と最適化により平均クエリレイテンシを30%削減した

横展開の方針:

データと分析にまたがる他のAWSサービスへも、DuckDBの性能と簡潔さを統合する方法を検討する

■ 8. 今後の展望

DuckLabsとAWSは、アプリケーション、データエンジニア、AIのためにデータのフロンティアを共に再発明する

顧客が今いる場所に寄り添い、AWSの中でDuckDBの技術革新がもたらす利点を届ける

MEMO:

AmazonがDuckDBを開発するDuckLabsを買収

(2026/08/28)

SIerの未来。「非機能要件は汎用AIだけでは困難」と野村総研が言い切る理由

SIerの未来。「非機能要件は汎用AIだけでは困難」と野村総研が言い切る理由 - レバテックLAB

要約:

■ 1. 議論の前提

NRIの中期経営計画での指摘:

AIによるコーディングが進むことでSIerの必要人員数が減少し、成長が縮小するのではないかという懸念が一部にある

大規模・ミッションクリティカルなシステム開発において、非機能要件の整備・実装や複雑な合意形成は汎用AIのみでは実現が困難

売上目標:

2025年実績の8,147億円を、2028年には9,500億円へ伸長させる

■ 2. 生成AI導入後の現場の変化

PoCを終えた次の段階:

AIの開発への組み入れはすでに前提であり、品質を保ちながら生産性をいかに引き上げるか、開発業務をどう最適化するかを考えるフェーズにある

生産性向上の桁が変わった:

従来の生産性向上は年に数％の改善を積み上げ、何年もかけて成果を刈り取る世界だった

生成AIの導入後はコーディングやテストの領域を中心に、工程によっては生産性が2倍、あるいは10倍という事例が実際に出ている

■ 3. 意外と変わらなかったもの: エンジニアリングの基礎体力

AIで従来スキルが不要になるという見方は実態と逆:

社内でAIを使って大きな成果を上げているプロジェクトの背景には、共通して高いスキルを持つエンジニアや成熟した開発組織が存在する

地力がAIの成果を増幅する:

AIが出力したコードの妥当性をその場で見抜ける人、要件を破綻なく構造に落とし込める人ほど、成果が何倍にも増幅される

土台がない場合はAIの出力が正しいかどうかすら判断できず、かえって振り回される

最も差が出る能力:

個別のタスク能力よりも、開発プロセス全体のどこにAIを効かせるかという勘所

■ 4. 非機能要件が汎用AIだけでは困難な理由

非機能要件の本質は意思決定:

さまざまな事情や要件のうち何に重点を置くかという意思決定に近いものである

対象領域の性質:

手がけるのは基本的にミッションクリティカルで大規模・複雑なシステムである

ミッションクリティカルとは失敗が許されるかどうかであり、ひとつの障害がそのまま社会的な事故につながる領域を指す

証券会社のバックオフィスや銀行の勘定系のように、止まれば取引や決済に直接影響が及ぶシステムが該当する

そこには、いろんな人、いろんな組織、いろんなビジネスが複雑に絡み合っている

技術的な正しさだけでは答えが決まらない:

どの非機能要件をどこまで満たすべきかは、プログラムが仕様どおり正しく動くかという技術的な正しさだけでは決まらない

非機能要件はトレードオフの世界:

可用性を極限まで高めようとすれば、その分コストも期間もかさむ

セキュリティの統制をきつくすれば、現場での使い勝手が落ちる

大量のアクセスをさばくために処理を並列化してスループットを上げれば、メモリやCPUを消費してコストが膨らむ

逆にコストを絞れば、ピーク時の応答性能が犠牲になる

トレードオフの折り合いは人間が調整する領域:

あちらを立てればこちらが立たないという関係があちこちにあり、どの水準で折り合わせるかは人間が関係者の間に立って調整しないと決まらない

■ 5. 前提を定式化してAIに渡すことの難しさ

判断の根拠が明文化されていない:

現場のエンジニアは、顧客がその事業で将来どんな姿を目指しているのか、対象となるマーケットが今後どう動いていくのかといった背景を踏まえて日々の意思決定を行う

こうした背景はどこにも明文化されておらず、現状ではAIに渡しきれない情報ばかりである

この条件で最適な答えを出してほしいと丸ごと委ねるのは、今の段階では難しい

言語化のコストが割に合わない可能性:

仮にすべて定式化して渡せるとしても、膨大かつ時系列で変化していく暗黙知を一つひとつ言語化する作業のほうが、AIに任せて浮くコストよりも大きくなってしまうかもしれない

構造的な背景は多目的最適化:

最適解が1つに決まる問題なら、AIは比較的スムーズに解決策を導ける

世の中の問題はトレードオフの壁が立ちはだかるものが多い

今回はどれを優先するかを関係者と会話しながら決めていく能力は、今の時点では人間のエンジニアのほうが長けている

■ 6. あくまで現時点の判断という留保

AIの進化速度の予想は困難:

どんな進化を遂げるかを正確に予想するのは困難である

すでにAIに任せられる範囲:

要件が固まっており、このテーブルはこの検索が多いからどうインデックスを張るかといった、範囲が限定されて答えの筋がある程度見えている設計であれば、今でもAIで効率化する手はいくらでもある

AIに任せられる範囲は今後さらに広がると考えており、期待もしている

全面代替の見通し:

大規模でミッションクリティカルなシステムの非機能要件が丸ごとAIで代替できる未来が近いうちに起こるとは、今は考えにくい

現実的な未来像:

データベースには以前から、クエリの実行計画を見て統計情報をもとに最適なインデックスや実行経路を選ぶ自動チューニング機能がある

フロンティアモデルの汎用AIが既存の製品やサービスを丸ごと置き換えるのではなく、日々用いるデータベースやミドルウェアといった基盤にAIが少しずつ溶け込み、ツールとして高度化していく

AIが課題を解決しうる能力を獲得した場合の姿勢:

大規模でミッションクリティカルなシステムを扱ってきた自分たちこそが、先んじてそのようなAIエージェントを開発し実用化したい

■ 7. 内製化が進んでも需要は減らない

内製化の判断は顧客のもの:

内製化するかどうかの意思決定は顧客が判断することである

仮に内製化が進むにしても、事業にとって不利な状況になるとは捉えていない

スポット単位の開発は顧客側で進む:

ひとつの部門の問い合わせ対応をAIで自動化する、これまでExcelで手作業していた集計や資料づくりをAIに任せるといった開発は、ユーザー企業側の手でどんどん実現されていく

それは顧客のビジネススピードの加速につながるため、歓迎すべきことである

大規模化が4象限の移動を生む:

つくられたものが大規模化すると、既存の基幹システムとつなぎたい、一部門だけでなく全社で本格的に使いたいという話が出てくる

これは小規模・シンプルな領域から、大規模・ミッションクリティカルな領域へ少しずつ近づいていくことを意味する

顧客だけでは担いきれない部分:

全社の基幹データにつなぐ際は、権限のない社員が機微なデータにアクセスできないようにするセキュリティや統制の設計が欠かせない

長年動いてきた既存システムと矛盾なく連携させる必要がある

止まれば取引や決済に響くため、簡単には止まらないつくりにしなければならない

顧客のシステムならではの癖や特性があり、日々の大切な業務もある

この背景を解き明かしシステムに実装する人間臭い作業は、汎用AIだけでは解きにくい領域である

担う領域そのものが異なる:

今後顧客が自ら担う範囲が広がっていく領域と、従来得意としてきた領域は、4象限で見ると位置が異なる

新たにシステム化の対象となるのは不定形業務:

顧客がAIの進化を受けてシステム化できるのではと考え始める領域は、発生頻度が低い、進め方の形が定まっていないなどの理由で、そもそもこれまでシステム化の需要が見込めなかった不定形な業務であることが少なくない

本格的にシステム化しようとすると、まずどう整理すればいいのかという壁が立ちふさがる

長い時間をかけて積み上がった業務プロセスやフローでは、どの業務がどこにどうつながっているのか全体像を見通しにくくなっていることが少なくない

そこを解きほぐすには相応の経験が要り、DXという言葉が広まり内製化に取り組む動きが増えた時も同様の相談を数多く受けた

■ 8. 工数削減と売上増の両立

工数削減目標:

中期経営計画では、FY2030へ向けAI駆動開発によって工数を最大50%削減すると掲げている

対価の源泉はコーディング作業ではない:

単にシステムのコーディングだけを行い、純粋なプログラミングの作業代として対価を得ているわけではない

顧客とどんなビジネスをつくるかを考える川上の部分と、堅牢で長く使えるものをどう設計し品質を担保し安全に運用し続けるかという川下の部分のほうが、市場からの評価要素としてポーションが大きい

純粋にコードを書く作業の比率は下がっても、企画から運用まで伴走し続けるスパン自体は変わらない

複雑さへの対処需要はむしろ増す:

AIエージェントが高速でコードを生み出すようになるほど、単位時間あたりに向き合う複雑さと、それらに対処していくことへの需要は増している

複雑さを引き受けて大規模なシステムをつくり動かし続けるという提供価値は、今後も変わらない

工数減と売上増は両立する:

いちプロジェクトにかかる工数は減っても、プロジェクトの総量としてのシステム開発需要はこれまで以上に増えていく

むしろ増えていく需要をさばくために、一つひとつの開発にかかる作業を減らさないと追いつかない

システム化できる領域の拡大:

AIにより開発効率が上がることで、システム化できる領域そのものが広がるインパクトは非常に大きい

事業構造の見立て:

従来型のコーディングのように自動化が進んで工数が減る領域がある一方、AIを背景に新たに増える開発需要はより高難易度で付加価値の高い領域である

売上として減っていく分よりも増えていく分のほうが大きく、しかも価値が高い事業構造になっていく

■ 9. 人材の育ち方

経験を積む場を組織的につくる:

大規模システムの刷新プロジェクトに戦略的にアサインするなど、経験を積める場を組織的につくる工夫が必要ではないかという議論を現在行っている

AIがあるから人が育たないわけではない:

AIを使って実装に臨むとトライ&エラーを高速で回せる

結果として1〜2年目で驚くほど伸びる若手も出てきている

問われる専門性が変わる:

コードや設計の多くをAIが担うようになっても、取り組むことの中身が変わるだけである

エンジニアの専門性は、AIをどう使いこなし成果を出させるかという部分が問われるようになる

シン・ジェネラリスト:

数年前のレポートで、今後は幅広い知識でAIをマネジメントする人材像が求められると予想した

それがいよいよ現実になりつつある

■ 10. 過渡期に対する展望

悲観していない:

数か月先も読めないVUCAの時代に突入しているが、ワクワクもしている

ものづくりのハードルが下がった:

やりたいことがある人には本当にいい時代になった

社内ではエンジニア以外の部門でも、これをつくりたいという声が次々と形になり始めている

試すことが許容される空気感:

求められたものだけを成果物として納めるに留まらず、こんなことができるのではないかというアイデアを試すことが許容されやすい

自分で考えるエンジニアほど面白がれる時代になっていく

(2026/08/27)

2026年もtodo.txtを布教したい

2026年もtodo.txtを布教したい

要約:

■ 1. todo.txtへの回帰

2006年からのGTD運用:

タスク管理手法のGTDを2006年から使い続けている

途中で何度もツールを乗り換えたが、結局ただのテキストファイルに戻ってきた

前記事からの継続:

todo.txtを布教したいという記事をQiitaに2024年末に書いた

相変わらずtodo.txtを使い続けており、本稿はその続きにあたる

2026年の今、同じtodo.txtがどう進化してどう回っているかを扱う

■ 2. 素のtodo.txtの限界

GTDの5リスト:

Inbox、Next Actions、Waiting、Someday、Referenceの5つがある

素のtodo.txtは1ファイル思想のため、全部を1本に押し込むにはタグで擬似的に分けるしかない

分ける手段はプロジェクトタグとコンテキストタグに限られる

InboxとNext Actionsの混在:

一番のネックは両者が同じ視界に混ざってしまうこと

GTDでは収集と処理は別のタイミングでやる動作にあたる

収集と処理の分離:

頭の外にポンと出す瞬間と、次に何をするかまで落とし込む瞬間は分離したい

同じファイルに書くと収集した瞬間にNext Actionsへ入り、処理のタイミングを選べない

教科書通りには回っていなかった:

ある意味割り切って使っていた部分があり、長年GTDの教科書の形では回っていなかった

InboxなしでいきなりNext Actionsらしきものをtodo.txtに書く運用に近かった

■ 3. torudoのGTDモード拡張

自作TUI torudo:

todo.txtを日々触るのにRust製の自作TUI torudoを使っている

つい最近、v0.10からv0.12にかけて大きく変わった

5モードのGTDレイアウト:

inbox.txt / todo.txt / waiting.txt / ref.txt / someday.txtをそれぞれ別ファイルとして持つ

Tab / Shift+Tabで切り替え、各タブに件数が表示される

sプレフィックスでモード間移動:

siでinbox、swでwaiting、srでref、ssでsomeday、stでtodoへ移動する

GTDの処理ステップがキー2打で終わる

直接エディタでファイル移動してもよいが、TUI上のほうが処理に集中でき即座に反映される

完了はtodoモードのみ:

他のモードから完了したくなったらstで一度todoへ送る

実行対象はtodo.txtだけという単純さを維持するため

waitingから直接完了したい場面はありそうで、未だに悩んでおり変えるかもしれない

5モードはopt-in:

従来のtodo.txt/done.txt以外のファイルは初回書き込みまで作られない

従来通りtodo.txtとdone.txtだけで使っても何も問題ない

■ 4. 収集を楽にするinbox add

GTDの本丸は収集:

頭の中のものを全部システムに出すことがGTDの本丸

思いついた瞬間にすぐ収集できることが大事で、溜めるのはよくない

torudo inbox add:

収集のプロセス改善のためv0.11で足したサブコマンド

TUIを起動していなくても外から直接inbox.txtに追記できる

仕様上の工夫:

JSONでidなどの追加結果が返り、他のコマンドへのインプットにしやすい

作成日は自動で挿入される

TUIが起動中ならfile watcherが拾って即Inboxタブに反映される

作成日を入れる理由:

元は作成日いらない派だった

後で分析するときにいつ作られたタスクかが分かるとかなり捗る

長期間完了していなければ粒度がデカすぎたか、といった判断ができる

投入経路の広がり:

シェルエイリアス、エディタのキーバインド、Claude Codeのフックやスキル、他のCLIのパイプからInboxに入れられる

alias i='torudo inbox add' として短縮して使える

Claude Codeのstop hookから残タスクを自動でinboxにpushする使い方も考えられるが、やっていない

残る課題:

外出先からのスマホ経由の投入手段はまだ無く、一旦保留している

Slackやメールに特定ルールで投げ込んでおけば勝手に拾う、くらいが理想

結局普段はinbox.txtをエディタで直接編集するのが一番早い

自動収集という理想:

メール、issue tracker、各種チャットツールから勝手に収集してInboxへ入れたいが、まだそこまでいっていない

夕方前の急ぎの問い合わせに退勤間際で気づくような最悪のケースを避ける仕組みを作りたい

■ 5. t:とdue:のタグ

t:YYYY-MM-DDはthreshold:

未来日付が付くと列の最下部に非活性っぽい見た目で並び、当日以降になると通常表示に戻る

topydo互換の挙動

具体的な着手日が決まっているタスクに設定しておくと便利

レビュー依頼を出して明日には返ってくるはずという連絡待ちは、waiting.txtよりt:のほうが良さそう

due:YYYY-MM-DDは締切日:

期限が到達すると赤枠でハイライトされる

締切日表示もしたほうがいいかもしれないが、そこまではやっていない

■ 6. icaruと組み合わせた朝の計画

icaruとの連携:

icaruは仕事・プライベート・学校の予定をまとめてLLMに食わせるCLIで、カレンダーからLLMへ予定を渡す導線

torudo側は単なるテキストファイルの集合体なので、そのままcatでLLMに読ませられる

朝のClaudeスキルにicaruの出力とtodo.txt群をまとめて食わせる

LLMによる計画立案:

午前の定例までにXを片付けて午後の空き時間でY、といった具体的な計画をLLMが立てる

GTDの5ステップのうち処理〜レビューは主にtorudoで行う

実行の手前の計画立案はClaudeに任せ、この形になってから脳の負荷がかなり減った

/start-dayと/end-day:

クラスメソッドのClaude CodeでAI駆動GTD × Zettelkastenで紹介された/morningと/daily-logスキルの発想を取り込んだ

自分のワークフローに落とし込んで運用を回し始め、まだ数日だがいい感じに回り始めている

日次ログによる精度向上:

torudo単体ではtodo.txtがその時点のスナップショットでしかなかった

毎日の記録を別途mdファイルにログとして残し、それを参照しつつLLMと常に相談できる状態にした

今日どの順番で仕事を進めるべきかの精度と解像度がかなり上がった

根拠に基づく意思決定:

感覚に頼っていた部分が減り、明確な根拠に基づいた適切な判断がしやすくなった

体調がよくないとき、進捗が芳しくないとき、逆に調子がいいときなどをLLMと共有する

昨日の状況、翌日の予定、今週の残り時間等を考慮に入れた意思決定が実現している

■ 7. テキスト×ターミナルとLLM

枯れたフォーマット:

todo.txtは10年ほど前からある枯れたフォーマット

1行1タスク、プロジェクトタグ(+project)とコンテキストタグ(@context)、完了日と作成日だけの形式

LLMに食わせやすい理由:

人間可読かつ機械可読、かつLLM可読でトークン効率よく構造が取れる

grepでき、diffが読め、gitで追える

SaaSのタスク管理ツールならAPIを叩いてJSONを整形する必要があるが、cat inbox.txtだけでClaudeに渡せる

時代が追いついた:

枯れたプレーンテキストが結果的にLLMフレンドリーになっている

■ 8. 2026年もtodo.txtを布教したい

3段スタック:

枯れたフォーマット × 薄い自作ツール × Claude Codeという構成

プレーンテキストの強み:

手元のデータは全部プレーンテキストで、ベンダーロックインもゼロ、エクスポートもいらない

過去の履歴はgitに残っている

新しいツールを試したくなったら、cat todo.txtで食わせて差し替えればよい

2026年、むしろ今こそtodo.txtを布教したい

「ただのファイル属性」がroot権限に化ける　Linux ntfs3に潜んだ権限昇格のわな：Linuxカーネルが...

「ただのファイル属性」がroot権限に化ける　Linux ntfs3に潜んだ権限昇格のわな：Linuxカーネルが“ファイルのうそ”を信じた - ＠IT

要約:

■ 1. 脆弱性InjectionBunnyの概要

ntfs3の権限昇格脆弱性:

LinuxカーネルのNTFSドライバー「ntfs3」に報告された脆弱性

細工したNTFSボリュームを使い一般ユーザーがroot権限でプログラムを実行できる

複雑なメモリ破壊は不要:

競合状態やヒープスプレーなどの高度な技術を必要としない

鍵を握るのはカーネルが信頼した「ファイル属性」

報告の経緯:

セキュリティ研究者のウラジーミル・トカレフ氏が2026年6月25日にLinuxカーネルのセキュリティ窓口へ報告

対応がなかったため2026年8月7日にntfs3のメンテナーが利用しているとみられるメーリングリストへ転送

■ 2. 原因となる実装上の欠陥

原因箇所:

「fs/ntfs3/xattr.c」の「ntfs_get_wsl_perm()」

WSL用拡張属性の反映:

ntfs3はNTFS上のWSL用拡張属性から「$LXUID」「$LXGID」「$LXMOD」を読み取る

読み取った値をLinux側のファイル所有者やパーミッションに反映する

SUID/SGIDビットの残存:

$LXMODの値をinodeのi_modeに反映する際、SUIDやSGIDに関係するビットを除去していなかった

■ 3. 攻撃手法と成立条件

攻撃の手順:

攻撃者は$LXUID=0、$LXGID=0、$LXMOD=0104755を設定したNTFSイメージを作成する

Linux側でマウントすると対象ファイルはroot所有のSUID実行ファイルとして認識される

一般ユーザーが実行するとSUIDの仕組みにより実効UIDが0となりroot権限で実行される

PoCでの確認:

UID、実効UID、GIDがいずれも0になることが確認された

想定される侵入経路:

細工したUSBドライブが経路の一つ

ループデバイスを利用できる環境では細工したNTFSイメージから攻撃できる

成立条件:

NTFSをマウントしただけでroot権限を奪われるわけではない

細工したボリュームがnosuidオプションなしでマウントされることが条件

そのボリューム内のSUID実行ファイルが実行されることが条件

■ 4. 影響範囲

影響を受ける環境:

カーネルで「CONFIG_NTFS3_FS」が有効になっている環境

NTFSボリュームをnosuidなしでマウントする環境

USBドライブなどを自動マウントするLinuxデスクトップも条件に該当する

対象ディストリビューション:

報告では「Ubuntu」「Debian」「Fedora」「RHEL」「SUSE」「Arch Linux」などが挙げられている

アーキテクチャ非依存:

問題はCPUアーキテクチャに依存しない

PoCはLinux 7.1.0のaarch64環境で確認された

■ 5. 対策

修正案:

$LXMODをLinux側へ反映する際にSUID（S_ISUID）とSGID（S_ISGID）のビットを除去する

運用面の回避策:

NTFSボリュームをnosuidオプション付きでマウントすることでSUIDを利用した攻撃を防げる

カーネル側の追加対応:

$LX*属性をユーザー空間から直接書き換えられないようにする修正も進められている

■ 6. 本質的な問題は信頼境界の設計

SUIDの消し忘れとして捉えるのは不十分:

今回の問題を「SUIDのビットを消し忘れたバグ」とだけ捉えるべきではない

本質的な原因:

攻撃者が操作できるNTFSの「$LX*」属性を、カーネルがLinuxの権限情報として信頼してしまったこと

開発者が設計すべき境界:

危険な値を受け取ったらどう処理するかだけを考えるのでは足りない

その値を誰が変更できるのかを考える必要がある

その値をどの時点でOSが信頼する情報へ変換するのかという境界まで設計する必要がある

ファイルシステムドライバーに限らない教訓:

外部から取得したファイル属性や設定値、メタデータをUID、GID、パーミッションへ変換する処理が対象

入力値だけでなく、その入力を操作できる経路そのものを検証する必要がある

MEMO:

そんなことあるんか

(2026/08/27)

最近のClaude Codeでの開発フロー

最近のClaude Codeでの開発フロー | Hirotaka Miyagi

要約:

■ 1. 論点駆動開発

論点駆動開発:

2025年11月現在運用しているコーディングエージェント向けのコンテキストの作り方

既存のフレームワークに乗るのではなく、自分に合うオレオレフレームワークを作るのが一番効率が良い

毎日調整しながら運用している

試行錯誤の経緯:

普段は Claude Code、Codex、Devin を活用し開発を進めている

エージェントへの指示をどう調整すると実装品質と開発スピードが上がるかを試行錯誤している

Cline の Memory Bank に心酔し、Claude Code の Plan モードや GitHub の Spec-Kit も試した

結論:

進捗ドキュメントのテンプレートの内容を埋めながら実装を進めてもらう

■ 2. 仕様駆動開発の壁

小さなタスクに不向き:

Kiro に小さなバグ修正を依頼した際、4つのユーザーストーリーと16の受け入れ基準が設定された話がある

ドキュメントレビュー化:

開発フローがコードレビューからドキュメントレビューに代わり、長大なマークダウンを読むことになる

全体を読むのは苦痛で細部の問題に気づきづらく、結局コーディングエージェントとの認識齟齬が生まれる

事前に気づけない問題:

仕様の作成段階では気づけない問題が多すぎる

実装した結果実現不可能だったことに気づいたり、新たな問題に気づくことが多い

エンジニアリングの本質:

達成したいゴールと現時点の制約を比較し、その矛盾をパズルのように解消し続けるプロセス

仕様駆動開発は実装前にすべての論点を解消しようとするアプローチである

実装を通じて発見される新たな制約や矛盾に対して柔軟に対応しづらい構造になっている

■ 3. plans.md からの着想

OpenAI Dev Day の紹介:

2025年10月6日開催のイベントで Codex の開発者たちが開発の進め方を紹介していた

Feler さんは plans.md というファイルに仕様や開発計画を書き出させながら開発していた

その手法で OpenAI 社内で最長のセッション時間とトークン数を達成した

テンプレートの出自:

自身のテンプレートは plans.md をベースに、いくつか自身の好みに合わせて修正したもの

■ 4. 進捗ドキュメントのテンプレート

構成セクション:

Purpose / Overview、Context & Direction、Validation & Acceptance Criteria、Specification、Open Questions

Discoveries & Insights、Decision Log、Outcomes & Retrospectives、Follow-up Issues、Confidence Assessment

位置づけ:

仕様駆動ではなく、常に更新し矛盾を解消させ続けるためのドキュメント

1つの GitHub issue に対して1つの進捗ドキュメントを作る

各セクションを埋めていくと最終的に良質なコンテキストとなるようセクションを設計している

テンプレートもプロンプト:

テンプレートには多くの HTML コメントを記載し、その多くは AI 向けの記載方法のプロンプトである

HTML コメントはマークダウンレンダラーで表示されないため、人間は純粋な進捗だけを読める

進捗ドキュメントを書くのは100%AI で、人間は読んでレビューするだけという設計

テンプレートにプロンプトを含める方法は Spec Kit のアプローチを参考にしている

■ 5. Open Questions セクション

最重要セクション:

受け入れ条件を満たすために解決すべき論点とその選択肢を、推奨案と自信度つきで記載してもらう

人間は基本的にここだけを読んで意思決定を行えばよい設計

決定した内容で Decision Log と Specification を更新してもらう

仕様を出力させない:

仕様ではなく論点と選択肢で出力させると、意味のない仕様や過剰な設計が出にくくなる

仕様駆動では指示していない監査ログ機能や、過剰なエラーハンドリングを厳密に実装しようとする

Spec Kit はシンプルな解決策か、新しいデザインパターンを導入していないかを確認させている

それでも仕様駆動では大きな仕様が出てきやすい

タスクの抽象度:

論点を出させることで、どの抽象度のタスクでもテンプレートを適用できるようになった

抽象度の高いタスクは論点が多すぎて仕様として事前に決め切ることは難しい

出力内容が論点であれば、意思決定を後回しにするなど段階的に仕様を決めていける

推奨案と自信度:

選択肢には推奨案と、高・中・低の三段階を色分けした自信度を出してもらう

これは Devin のタスク進行を参考にしており、色付けは視覚的にわかりやすい

自信度が高く人間としても良さそうな選択肢であれば、そのまま実装に入ってもらう

自信度が低い場合は人間も判断しづらいことが多い

自信度が低い場合の指示:

一旦推奨案で PoC を実装し、自信度を上げるための情報を集めるよう指示する

もしくは、その選択肢で良いか判断するためのサブ Issue を作るよう指示する

再帰的な進行:

サブ issue を作ったら、また進捗ドキュメントのテンプレートを埋めて作業を進行してもらう

解決したら親 issue の Open Questions を解決する

これを再帰的に繰り返すことで、どんな抽象度のタスクであってもとにかく前に進められる

■ 6. Discoveries セクション

役割:

発見や気づきを記載してもらうセクション

Open Questions にコードベースを調べればわかることを書かせないため、事前に必ずここへ書かせる

これにより無意味な問いが Open Questions に挙がることが起きづらくなった

調査結果のキャッシュ:

既存コード調査結果のキャッシュとなり、後続の実装フェーズで無駄なコード探索が不要になる

コーディングエージェントのターン数が減りやすくなるはずである

実装中の記録:

実装中に問題が起きたり新たな発見があったら都度書いてもらう

作業完了後の振り返りフェーズで問題の再発防止を考える際の重要な情報になる

■ 7. タスクリストを作らない

方針:

Spec Kit の tasks.md のようなマークダウンのタスクリストはやめ、GitHub の Sub-issues 機能で管理する

タスクリストの問題:

タスクリスト1行では情報量が少なすぎる

進行する上で事前に想定したタスクが大幅に変わることもあり管理が難しい

エージェントに出力させると lint とテストの実行なども1タスクとして扱いがちで粒度の制御が難しい

Sub-issues の利点:

親・子・孫と再帰的に管理でき、GitHub API で操作もでき、人間としても UI 上の視認性が高い

着手時に issue を作成:

論点の抽象度が高い場合にサブ issue を作り、そこでまた進捗ドキュメントを作る

サブ Issue が完了したら、その意思決定内容や実装内容で親 Issue の進捗ドキュメントを更新する

サブ issue を解決するタイミングで新たな論点やタスクが生まれることもある

事前にタスクを決め切るのはやめ、着手するタイミングで issue を作って進めるのが良い

■ 8. Decision Log と Specification

仕様より意思決定:

仕様はそこまで重視せず、意思決定内容を決定ログとして残す

実装を進める過程で意思決定内容が変わることもあり、ADR の考え方に近い

仕様セクションの意義:

実装フェーズのコーディングエージェントのターン数が減りやすいのでセクションとして用意している

■ 9. Acceptance Criteria セクション

用途:

受け入れ条件を記載してもらうが、人間はそこまで読まない

PR のレビューをエージェントに依頼する際、受け入れ条件を満たしているかを判定させるために用意している

テスト方針:

どのようにテストするかも記載してもらう

Spec Kit は TDD をかなり強く指示している

テストが書けない状況でも無理やりテストコードを書こうとしてうまくいかないことが多い印象がある

既存のテストコードパターンを調査させた上で、自動テストと手動テストのどちらかを判断させるのが良い塩梅

■ 10. 補助ツール

issync CLI:

テンプレートを特定のファイルパスにコピーし、GitHub Issue のコメントに同期するだけの小さなツール

管理場所の悩み:

コーディングエージェントの Read/Edit ツールは効率的なファイル操作に最適化されており活用したい

git 管理下のローカルファイルとして保存するとコミット操作やコンフリクトが気になる

作業完了後も残り、古いドキュメントとして後続エージェントの無駄なコンテキストになってしまう

Git Worktree による複数セッションやリモートのコーディングエージェントによる同時操作がしづらい

到達した解決策:

gitignore されたディレクトリにマークダウンファイルを置きつつ、GitHub Issue のコメントに同期する

GitHub Issue から取り出せば複数セッションで並列作業が可能になる

人間は GitHub Issue 上でレンダリングされたテキストを読めばよい

チームメンバーに意思決定内容を共有するための過去ログとしても使える

Claude Code Plugin:

issync を使った作業を定型化した Claude Code Commands を Plugin として提供している

/issync:understand-progress は issue の URL を渡して進捗ドキュメントを理解してもらうコマンド

新しい Claude Code セッションを開いたらとりあえず叩いて作業を始める汎用的なコマンドである

/issync:plan は進捗ドキュメントを初期作成するコマンド

テンプレートのコピー、コードベース調査、基本セクション記入、Open Questions 記入、Issue 同期を行う

/issync:create-sub-issue は Sub issues API で親 Issue に紐づけた新規タスクの Issue を作成する

/issync:complete-sub-issue はサブ issue を完了として進捗ドキュメントを更新する

振り返りを行いつつ親の Open Questions を解消したり、新しいタスクの提案をする

プラグインの利点:

コマンドの内容を更新して push すると利用側に配布され、プロンプトの試行錯誤がしやすい

実装作業自体は Devin や Codex に任せられるが、思考作業は Claude Code から離れられない

■ 11. 実際の運用と自動化

運用フロー:

Issue を作ったら /plan を実行し、論点が大きければ /create-sub-issue で分割する

実装できそうなら Devin や Claude Code Action に任せる

PR がマージできたら /complete-sub-issue を実行して親 issue を更新し、並列でどんどん進める

人間がボトルネック:

並列作業可能なタスクが圧倒的に増えると、人間のコンテキストスイッチがボトルネックになる

人間のタッチポイントを極限まで減らしていくことが重要になる

そのためには思考作業を言語化・定型化し、エージェントが再現可能な状態にしていく必要がある

自動実行:

/plan と /complete-sub-issue は品質が高く求めるものが出てきやすくなった

GitHub Actions の Claude Code Action で Issue 作成時に /plan、Issue 完了時に /complete-sub-issue を自動実行している

タッチポイントを減らせた事例である

Claude Code Action を整備したことで GitHub モバイルだけで開発を進められるようにもなった

未解決の自動化:

意思決定後の実装依頼や、完了後の PR が受け入れ条件を達成しているかのチェックも自動化できそうである

UI の変更などではまだうまく QA がしづらく試行錯誤している

■ 12. 人間のタッチポイント

人間が判断すべき最小限のポイント:

自身のテンプレートと現時点の Claude Sonnet 4.5 を前提とした想定である

Issue や Sub issue の作成判断

Open Questions の意思決定

実装後の最終レビュー

自動化の難しさ:

その他の二次的な作業は可能な限り自動で進められるようワークフローを整備したい

エージェントが実装で詰まっている箇所をサポートすることはまだまだある

明瞭なコードベースやアーキテクチャ、情報量の多いログの整備が必要な要素として挙がる

エージェント自身でフィードバックサイクルを回しやすいテスト基盤も必要である

外科医のようにコードを書く:

Notion で働く Geoffrey Litt さんが自身のブログで用いた表現である

外科医はマネージャーではなく実際に手術をする人である

準備や二次的な業務、事務作業を行うサポートチームがいることで外科医は重要な業務に集中できる

コードベース調査や作業が明確な実装タスクはとにかくエージェントに任せる

課題の特定、アーキテクチャ決定、デザインコンセプトの試行錯誤に100%時間を使える状態を目指したい

■ 13. 位置づけと今後

自作フレームワークの位置づけ:

誰かに使ってもらいたいモチベーションはなく、コンテキストエンジニアリングの事例として参考になれば幸いである

モデルの進化や環境の変化に伴い明日には大きく変わっているかもしれない

変化に追従しつつ自分に合ったコンテキストの作り方を模索していく

■ 14. 落穂拾い

コーディングとレビューの分離:

セッションを分ける方が最終的な精度が出やすい

実装しながらセルフレビューは複数の観点に同時に取り組むことになり期待する結果が出づらい

コンテキストをクリアした新しいセッションで、フラットな視点からレビューだけしてもらう

レビュー用ワークフロー:

PR に devin-review ラベルを貼るとレビュー観点に従って検査した後そのまま改修を進める GitHub Actions を用意している

CodeRabbit なども精度は高いレビューが出る

人間がレビューする前に実装修正までやって欲しい場合は Devin などのクラウド型エージェントが便利

ドキュメントワークの分離:

コーディングエージェントは長文を書きがちである

「とにかく書く」と「情報量を維持し圧縮する」セッションは分けた方が良い

そのための Claude Code Command を用意している

(2026/08/27)

なぜ出世したくないサラリーマンが増えているのでしょうか？に対するAkira Moriさんの回答

なぜ出世したくないサラリーマンが増えているのでしょうか？に対するAkira Moriさんの回答 - Quora

「昇進して管理職になった月、私の『手取り時給』は30％以上暴落しました。」

これが、現在の日本のIT業界で起きているリアルです。

若手が「出世したくない」と言うと、上の世代からは「向上心がない」「最近の若者は熱量が足りない」なんて言われがちですよね。

でも、現場で働く人間から言わせてもらえば、彼らは熱量が足りないのではありません。恐ろしいほど冷静に「コスパ」を計算しているだけなんです。

私自身の体験を少しお話しします。

1. 「給与アップ」よりも「残業代カット」のダメージがデカい

数年前、私はIT企業で現場のエンジニアから、チームリーダー（管理職扱い）に昇進しました。

基本給は月3万円ほどアップ。「期待しているよ」と上司に言われ、当時は誇らしい気持ちすらありました。

ですが、最初の給料明細を見て言葉を失いました。

昇進前：基本給＋残業代（月30時間で約8万円）

昇進後：基本給＋3万円＋管理職のため残業代ゼロ

手取り収入が、前月より5万円近く減っていたんです。

しかも仕事は「手を動かす技術職」から、進捗管理、クライアントとの調整、部下のメンタルケア、社内政治の調整へ。労働時間は月30時間から60時間超に膨れ上がりました。

「働く時間は1.5倍になり、責任は跳ね上がり、手取りは減る」。時給換算したら、昇進前より3割も下がっていたわけです。これでは何のために頑張ってきたのか分かりません。

2. エンジニアにとって「管理職＝技術的リスク」

さらにIT業界特有の事情として、「現場の技術から離れる恐怖」があります。

ITの技術トレンドは数年で激変します。管理業務や会議に追われ、最新の技術スタックやAIツールに触れる時間を失うと、市場価値（＝転職市場での強み）は一気に落ちます。

今の若手はみんな知っています。「会社で貰った肩書き（課長など）」は転職市場では守ってくれないけれど、「個人で磨いた技術」はどこに行っても通用するということを。

自社でしか使えない社内政治のスキルより、自分の手を動かせるスキルのほうが、よほどキャリアの安全保障になるんです。

3. 上と下に挟まれる「板挟み」の惨状

今の管理職は、昔のように偉そうに指示を出していればいいポジションではありません。

上からは：厳しいコスト削減と無茶な納期のプレッシャー

下からは：ハラスメントに怯えながら、離職されないように顔色を伺うマネジメント

そうやって精神的にすり減っていく上司の背中を、若手は毎日間近で見続けています。「数年後に自分もああなりたいか？」と聞かれたら、NOと答えるのが普通ではないでしょうか。

かつての日本にあった「会社に尽くせば、年功序列で給料が上がり、老後まで面倒を見てくれた」という社会契約はもう崩壊しました。

今「出世したくない」と言っている人たちは、決して働くのが嫌いなわけではありません。

自分の技術力を磨くこと

副業や個人開発で複数の収入源を持つこと

自分の時間や家族を大切にすること

彼らは「社内での出世」という過去のモノサシを捨て、自分の人生のQOL（生活の質）を自分でコントロールするための、最も合理的な選択をしているだけなのだと思います。

MEMO:

実際問題、中間管理職こそAI化すべき職種なのである

(2026/08/27)

AI分野では「オープンモデルがクローズドモデルに追いつく時間」が飛躍的に縮まっているとの指摘

AI分野では「オープンモデルがクローズドモデルに追いつく時間」が飛躍的に縮まっているとの指摘 - GIGAZINE

要約:

■ 1. オープンモデルとクローズドモデル

2種類のAIモデル:

クローズドモデルはモデル自体が非公開で、サービスのみが提供される

オープンモデルはモデル自体が公開されている

従来の性能差:

オープンモデルは最先端クローズドモデルより性能が低いのが一般的とされてきた

縮まる追いつき時間:

オープンモデルがクローズドモデルの性能に追いつく時間は、AI分野のステージごとに飛躍的に縮まっている

半導体分野のブログであるSemi Analysisによる指摘

■ 2. 企業のモデル選択の変化

ChatGPT登場以降の優位:

クローズドモデルはパフォーマンス面でも連携面でも優位にあった

AIを導入する企業の多くはクローズドモデルを利用していた

2026年の転換:

Kimi K3やGLM-5.3といったパフォーマンス面でも優れたオープンモデルが次々と登場した

プライバシーやカスタマイズ性、コストを重視する企業にとってオープンモデルの優位性が高まっている

■ 3. 最先端AIのコモディティ化懸念

価値の希薄化:

大手テクノロジー企業が巨額の資金を投じて開発するクローズドモデルと同等の性能が、はるかに低いコストで利用できてしまう

最先端AIの価値が薄れてコモディティ化する可能性がある

大手AI開発企業への打撃:

数兆円規模の出資を集めているOpenAIやAnthropicといった企業に打撃をもたらす

■ 4. 検証手法

3つの時代区分:

初期スケーリング時代(2022～2024年)

推論時代(2024～2025年)

エージェント時代(2025年～現在)

測定方法:

時代ごとに異なるベンチマークでAIモデルを評価する

時代ごとの初期最先端クローズドモデルにオープンモデルが追いつくまでの時間を調べる

ベンチマーク変更の理由:

ベンチマークはAIの進歩に伴ってスコアが飽和してしまう

時代を区切って指標となるベンチマークを変更することで意味のある数値を得る

■ 5. 時代ごとの追いつき時間

初期スケーリング時代:

初期最先端モデルは2022年11月リリースのOpenAIのGPT-3.5(GPT-3.5 Turbo)

ベンチマークはGSM8K、HumanEval、TriviaQA、MMLU-Pro

2024年7月にMetaのLlama-3.1-405Bが登場してようやく差が埋まり、19.7カ月を要した

推論時代:

初期最先端モデルは2024年9月リリースのOpenAI o1

ベンチマークはGPQA-Diamond、AIME 2026、SimpleQA Verified、Humanity's Last Exam

2025年5月のDeepSeek-R1-0528リリース時点で差が埋まり、わずか8.5カ月で追いついた

エージェント時代:

初期最先端モデルは2025年11月にAnthropicがリリースしたClaude Opus 4.5

ベンチマークはTerminal-Bench 2.1、BrowseComp-Plus、τ3-Banking、DeepSWE

Claude Opus 4.5はコーディングやPC操作といった複雑なエージェントタスクを実行できた

2026年4月にMoonshot AIがリリースしたKimi K2.6により、わずか4.8カ月で追いつかれた

■ 6. 分析結果の傾向

初期スコア差の縮小:

初期スケーリング、推論、エージェントと時代が下るにつれ、初期のスコア差が小さくなっている

追いつく時間の短縮:

時代が下るにつれ、追いつくまでの時間もほぼ半分のペースで短縮されている

■ 7. ベンチマークの限界

実作業との乖離:

そもそもベンチマークは実際の作業を完全に反映したものではない

スコアの作為的な調整:

モデル開発者が狙って調整すれば、意図して高いベンチマークスコアを出せてしまう

■ 8. 米中AI競争

縮小する米中差:

AI開発競争においてアメリカと中国の差が急速に縮まっている

利用状況やコストといった面では中国製AIがリードを奪うケースもある

経済紙のBloombergによる報道

アメリカ企業の反応:

2026年7月にアメリカのスタートアップ企業各社がトランプ政権に公開書簡を送付した

中国製のオープンウェイトAIを禁止しないよう求めた

(2026/08/27)

ローカルでの開発やめませんか？Claude Code / Cursorで開発の8割をクラウドに移した話

ローカルでの開発やめませんか？Claude Code / Cursorで開発の8割をクラウドに移した話

要約:

■ 1. クラウド中心の開発実情

退勤直前のタスク投入:

PCを閉じて帰宅し、寝ている間にテストとAIによるレビュー修正まで回ってPRが上がる

翌朝は上がってきたPRをレビューする

人間の操作は2つのみ:

止まったエージェントを起こすこと

承認が必要なものの確認と許可

海外での定着:

grill-meで知られるMatt Pocockはローカルの開発環境から離れつつあるとポスト

SpaceXAIのLauren Tanはworktreeは死んだ、クラウドエージェントが未来だとポスト

Cursorの実績値:

マージ済みPRのうちクラウドエージェント由来が昨年12月の10%から2026年7月末には56%まで伸びている

自身の運用比率:

ローカル作業がゼロになったわけではないが、8割以上のタスクをクラウドエージェントで行っている

■ 2. クラウドエージェントの定義

専用実行環境上のエージェント:

手元のPCではなくCursorやCloud側がクラウド上に用意する専用の実行環境にエージェントを配置し開発を進める仕組み

本記事ではCursorのCloud AgentsとClaude Code on the webをまとめてクラウドエージェントと呼ぶ

ローカルとの違い:

リポジトリのclone、依存のインストール、ビルド、テスト、アプリの起動までを自分の環境の中で完結させる

1台まるごと自分の環境を持っているということ

セッションの永続:

PCを閉じても保持されるため、スマホアプリから閲覧も指示も可能

■ 3. 専用VMがすべて

成立の根拠:

エージェントが自分専用のVMを持っていることが回答

クラウドエージェントで得られる恩恵のほとんどはこの専用VMの結果に過ぎない

隔離による許可待ちの排除:

エージェントがコマンドを打ち間違えても壊れるのはVMだけで、自分のPCに被害はない

rmコマンドをルートで実行されMacが骨抜きにされるといった事故の被害に遭わずに済む

許可の確認なしで走らせるYOLOモードでも、手元のマシンを壊す可能性はない

切り分けが必要なリスク:

壊れるのはVMだけというのは自分のPCに限った話で、リポジトリのコードやシークレットをVMに渡す場合は注意が必要

プロンプトインジェクションによる持ち出しリスクが残る

Cursor自身も、攻撃者がエージェントをだまし悪意のあるWebサイトにコードをアップロードさせるデータ流出リスクがあると述べている

PCが壊れないことと、資産が外に出ないことは切り分けて理解する必要がある

検証まで完結:

書いたコードを実際に動かし、テストを回し、アプリを起動して確認するところまで自分で行う

「書いた」ではなく実際に「動いた」まで確認してからPRが作られる

止まるコストが大きい前提の設計:

Cursorはより自律的に動くよう促している、止まってしまうことのコストがはるかに大きいため

ローカルでは許可待ちが見えるが、クラウドでは確認しに戻るまで何時間もそのまま待ち続けることがある

人間が隣にいない前提で、なるべく人間に聞かずに進むよう作られている

操作が起動と最小限の承認の2つまで減ったのはこの設計のおかげ

■ 4. クラウドエージェントのメリット

ローカルに落とさずマージ:

Cursorのcomputer useはブラウザを触れること以上に、検証結果などの証拠がPRに付いてくることが大きい

多くのタスクでエンジニアはブランチをローカルにチェックアウトすることなく、生成されたコードを安心してマージ・デプロイできる

通知が来たらスマホやPCで録画を見て、意図通りならそのままマージする

複数リポジトリの同居:

Cursorにある機能で、フロントとバックとインフラが別リポジトリでも環境作成時に複数選択できる

選んだリポジトリがVMにcloneされ、参照や横断的な変更、変更した側へのPR作成が可能

仕事の単位がPR:

各VMが独立した環境のため、手元のworktree管理や編集ファイルのコンフリクトを意識する必要がなくなる

PRにだけ集中できる状態が作れる

PCを閉じても継続:

処理はクラウド環境上のVMで走るため、PCを閉じてもタスクが止まらない

移動前や休憩、退勤の直前にタスクを投げてから中断・退勤する

移動中は通知があればスマホからエージェントを起動し、許可があれば承認する

一旦走り出せばスマホさえあればよいという状態が作れる

並列実行でも手元は静か:

エージェント1体につきVM1台で、何本並列で行ってもメモリやCPUを占有しない

ローカルでの並列はworktreeでのディレクトリ分割やポート衝突の回避が必要で、管理コストや消し忘れのリスクも付き物だった

メモリが逼迫しないためPCファンは回らず、熱も出ない

高負荷なビルドとテストとファイルの読み書きはVMが引き受けるのでPCの寿命も削らない

PCのスペックに依存しない点も魅力の1つ

worktreeごと不要になることが、worktreeは死んだという発言の意味

セキュアな環境:

コマンドを打ち間違えても壊れるのはVMのみで、自分のPCには何も影響がない

各社が用意したサンドボックス環境で行うため、環境によっては自分のPCより安全なケースも多い

許可待ちなしの実行:

Cursorのcloud agentsは公式ドキュメント上もローカルのRun Modesを使わず、VM内のコマンドを自動実行する

すべてのコマンドで承認が必要なフォアグラウンドエージェントと異なり、テストを繰り返し実行できる

細かい確認を省略できるため長時間の実行も容易

長時間実行への適性:

並行して作業でき、ユーザーの操作なしで実行でき、ノートPC上のローカルエージェントより長時間のタスクを担える

就寝前などに数時間かかるタスクを投げられるのはこの設計ゆえ

最近は起動も最大3倍速くなり、より長時間向けになっている

トークン効率の良さ:

Cursorはクラウドエージェントではトークン効率が20〜30%良いとポストしている

MCP、skills、computer useの扱いを改善したという内容だが、詳細な要因は不明

Claude Code on the webでも体感としてトークン効率は良い

ローカルは環境ごとにインストール済みツールが異なり、探索コストがかかることが要因と推測される

チームの環境構築の消滅:

開発環境をコードで定義してリポジトリに置ける、Cursorでは .cursor/environment.json が該当

新しいメンバーもエージェントも同じ定義から同じ環境を組み立てられる

開発環境もそれ自体がプロダクトであり、そのユーザーはエージェントである

■ 5. 最推しはUIテスト

computer useによるUI検証:

Cursorに限った話だが、エージェントがブラウザを実際に操作してクリックする

スクリーンショットと録画を撮ってPRやセッション内に添付する

ローカルでの環境構築やブランチのチェックアウトが不要になり、一定の安心感のもとPRをマージできる

環境に投資する理由:

エージェントの能力は、それが実行される環境の能力に左右される

自分たちが作成しているソフトウェアを実際に使えなければ、エージェントの能力はすぐ限界がくる

体験の不可逆性:

一度体験すると戻れない

■ 6. 開発フローの再設計

本命はフローの再設計:

クラウドエージェントの本命は個人に帰属するものではなく開発フローの再設計にある

その兆候は現時点で2つある

Stacked PR:

エージェントを並列に走らせると最後にまとめて巨大なPRが作られる

レビューおよびPRとレビューの依存関係の管理が大きなボトルネックになる

GitHubはstacked pull requestsを2026年7月に全ユーザー向けに提供している

公式ドキュメントのone pull request per taskは、AIエージェント時代のPR管理方法としての用途を示す

gh stack sync を打てばfetch、rebase、push、PR状態の同期まで一発で済む

gh skill install github/gh-stack でエージェント用スキルを入れると自然言語で操作でき、量産されたPRをエージェント自身に積ませられる

feedback-agent:

CursorのEric Zakariassonが公開しており、さらに一歩先の未来の開発手法

アプリ内のフィードバックとファーストパーティのセッション記録をサーバー側で受け取り、Cursorのcloud agentを起動する

ファーストパーティのセッション記録とは、外部SaaSではなくアプリ自身が録った直近の操作履歴

feedback-agentのフロー:

ユーザーがアプリ内でフィードバックを送る

操作のタイムラインと、必要なら画像がサーバーに集まる

cloud agentがその文脈を持って修正に着手する

検証できるところまで進み、テスト付きのPRを開く

開発者はスマホで通知を受けてレビューする

人間の役割の縮小:

人間がエディタを開かないままバグ修正が回り始め、PRまで作られる

人間が行うのはAIが出した検証結果とPRのレビューのみ

■ 7. ローカルに残す作業

意図的にローカルに残す2つ:

UI周りの作業と計画

UI周りの作業:

余白を2px空けるなど細かい作業がどうしても発生し、人間の手もそれなりに入れる必要がある

秒単位で確認したほうが効率が良いためローカルで行う

CursorのDesign Modeは画面の要素を指して直す機能で、開発体験は他のツールを数段上回る

計画:

複雑なタスクや仕様を決めてから進めたいタスクは、計画だけローカルで作ってからクラウドに投げる

Claude Codeの公式ドキュメントも、ローカルのプランモードで計画を作りリポジトリにコミットしクラウドで実行する手順を推奨

claude --permission-mode plan で計画を作り、claude --cloud で計画ファイルを指して実行する

(2026/08/27)

AIは回せば回すほど凄いのか ―「常時稼働」という設計の敗北

AIは回せば回すほど凄いのか ―「常時稼働」という設計の敗北

要約:

■ 1. 「AI常時稼働」言説への違和感

AI常時ぶん回しへの疑問:

AIエージェントを24時間動かして開発を完全自動化した、という投稿がSNSに溢れている

寝ている間もAIがコードを書き続ける、AI社員を常時稼働させ量産中、といった発信は伸びやすい

現役の開発者としてAIを日常的に使う立場から、そこまで回す必要があるのかという疑問が残る

「凄そうに見せる」商売の構造:

AIで派手なことをやっているように見える投稿はインプレッションを稼ぎやすい

その注目はフォロワー増加、有料noteの販売、PV収益に直結する

実際に成果が出ているかとは無関係に、凄そうに見える発信自体に経済的インセンティブが働く

額面通り受け取る必要のなさ:

発信者全員がそうだとは言わず、本当に有効な運用をしている人もいる

ただしこのインセンティブ構造がある以上、24時間ぶん回しているという言説を額面通り受け取る必要はない

■ 2. コストから見た破綻

従量課金という前提:

LLMのAPIは従量課金であり、高品質なモデルを常時稼働させればトークン消費は青天井になる

個人開発者の予算感でこれを続けるのは現実的ではない

格安モデルの罠:

安価なモデルは出力の精度が下がるため手戻りのコストが発生する

生成されたコードのレビュー、修正指示、再生成というループを人間が回すコストがかかる

安く大量に回す戦略は、高品質なモデルで一発で仕留めるよりしばしば高くつく

どちらに転んでも生じる矛盾:

高品質モデルの常時稼働はAPI課金で破綻する

格安モデルの常時稼働は人間の時間という手戻りコストで破綻する

■ 3. 「回さない」ことこそ設計

無駄な処理を走らせない原則:

ソフトウェアエンジニアリングでは無駄な処理を走らせないことが良い設計の基本だった

条件分岐による不要処理のスキップ、アーリーリターン、キャッシュがその具体例

AIを使った開発でもこの原則は何も変わらない

目指すべき理想:

最小のトークンで狙った出力(ゴール)に到達することが本来目指すべき方向

常時稼働は設計の敗北:

とにかく常時回すというアプローチは設計判断を放棄している

条件分岐が書けずループでゴリ押しするコードと構造的に同じもの

■ 4. 動的オーケストレーションの欠如

あるべきマルチエージェント構成:

親玉となるモデルが状況を判断し、必要なときだけ特化型の子分を呼び出す動的なオーケストレーションが理想

タスクが発生したら起動し、終わったら止める

呼び出す・呼び出さないの判断そのものが設計の腕の見せどころ

常時稼働が示す裏返し:

全部を常に動かしておくのは、判断ロジックを作れない、あるいは作る発想がないことの裏返し

オートスケーリングやサーバーレスが当たり前の時代に、AIだけ常時フル稼働が正義とするのは逆行

■ 5. ゴールは「作ること」ではなく「使われること」

誤ったボトルネックの前提:

AIを常時回して量産する発想は、開発のボトルネックが作ることにあるという前提に立つ

この前提自体が間違っている

「作る」の裏にある泥臭さ:

AIにより動くゲームを作ること自体は驚くほど速くなった

面白いゲームにするには難易度カーブやレベルデザインの調整が要り、数値をいじっては遊んで確かめる反復を伴う

触っていて気持ちいいという手触りの作り込みが必要になる

世界観やキャラクターに一貫性を持たせる判断が必要になる

プレイして・感じて・直すという泥臭い反復が欠かせない

映像作品でも同じ構造:

素材の生成は速くなっても、どのカットを何秒見せるか、どこで音を入れるかという編集の判断は残る

その判断は観る人間の感覚に依存する

実用システムのエッジケース:

ECサイトや予約システムも、画面と機能を作るだけならAIで一瞬

実際に使われるには決済まわりの安全性、個人情報の扱い、注文の二重登録への備えが不可欠

ここを飛ばして生成されたものは、動いて見えても金や個人情報を任せられないシステムになる

■ 6. リリース後の自動化できないフェーズ

プロダクトはリリースして終わりではない:

誰に届けるのかを見極めて周知するマーケティングが必要

ライセンスや価格をどう設計するかを決める必要がある

検索で見つけてもらうための地道なSEO整備が必要

初期ユーザーの声を拾い、対応と改善を重ねる工程が必要

完全自動化できない理由:

判断の主体が人間であり相手も人間である以上、構造的に完全自動化できない

AIは文章のドラフトや分析の補助はするが、誰にどう届けるかという意思決定は肩代わりしない

■ 7. 「ハイ次!」が成立する理由

スキップされている工程:

AIで作った、ハイ次!というサイクルを高速で回せている場合、リリース後のフェーズを丸ごとスキップしている可能性を疑うべき

使われるための泥臭い工程を全部飛ばせば、いくらでも次に行ける

それはプロダクトの量産ではなく、誰にも届かない成果物を積み上げているだけかもしれない

骨組みだけの家という比喩:

内装も検査も引き渡しもせず、骨組みだけの家を次々に建てているようなもの

着工数だけを見れば凄まじい生産性だが、誰も住めない

■ 8. 結論

AI活用そのものは否定しない:

AIは作業スピードを圧倒的に上げてくれる優秀な道具であり、実際に開発の中心で使っている

問題は道具そのものではなく、放置して稼ぐ魔法の装置であるかのような扱い方

押さえるべき三つの視点:

AIは常時回すものではなく、必要なときに最小のコストで狙った出力を引き出すもの

良い設計とは回す量を増やすことではなく、いかに回さずに済ませられるか

プロダクト開発のゴールは使われることであり、そこには自動化できない工程が必ずある

迫力に飲まれない姿勢:

回した量は成果ではなく、その言葉が発信者の商材である可能性すらある

ツールやハッタリに踊らされず目の前の課題と向き合うことが、本物のプロダクトへの最短ルート

MEMO:

それはそう

(2026/08/26)

LLM・AIエージェントシステムベストプラクティス

LLM・AIエージェントシステムベストプラクティス - Speaker Deck

要約:

■ 1. 本書の位置づけ

組み込むエンジニアリングの本:

LLMの理論や使い方ではなく、LLMやAIエージェントをソフトウェアに組み込む方法を扱う

そのための設計パターン・アーキテクチャを扱う

運用・改善のプラクティスを扱う

扱わないもの:

プロンプト集やコツ

特定プロダクトの操作マニュアル

モデルの学習理論や数式の解説

サンプルコードの公開:

PythonサンプルコードをGitHubで公開する

CLAUDE.md/AGENT.mdも同梱し、コーディングエージェントで開発するときもそのまま使える

書誌情報:

翔泳社刊、2026年8月20日発売予定、ISBN 978-4-7981-9431-8

■ 2. 執筆の経緯

2022年11月の驚愕:

ChatGPTの登場により、人間にしかできなかった知的作業を軽々とこなす技術が現れた

心血を注いだ前著『機械学習システム構築実践ガイド』の出版と同年同月であった

当時のAIチャットボット開発の難しさを解いたばかりだった

2年がかりの本が一瞬で過去のものに:

衝撃と同時に、これは新しい冒険の始まりだと直感した

転機はFunction Calling:

2023年6月に登場した関数呼び出しが転機となった

自然言語の応答はロジックに組み込めなかった

出力を構造化データとして扱えるようになり、検証・連携とプログラムへの統合が可能になった

執筆の決意:

LLMはソフトウェアエンジニアリングに新たなパラダイムを生むと確信した

■ 3. LLM/AIエージェントの動向

本質はソフトウェア:

LLM単体は重みパラメータの集合にすぎず、組み込んで初めて価値になる

ソフトウェア工学の知見を適用・拡張する

用途の広がり:

情報収集はChatGPTに相談しながら調べる新しい情報の得方

文章・アイデアはNotion・Google Docsの生成/要約、企画支援

ソフト開発はCursor / Claude Code / Copilot / Codex

デザインはFigma・Canvaの画像生成・提案

LLM自体の不確実性:

同じプロンプトでも出力が変わる

事実に基づかない生成であるハルシネーションが起きる

HTTP 200が返っても中身が不安定

エンジニアリングの不確実性:

LLM/AIエージェントをどう設計、実装、テストすべきかが定まっていない

最適な組み込み方法は試行錯誤の段階

正しいか不明だが動いてはいるという曖昧さが残る

不確実性への対処の鉄則:

不確実な要素は、局所化して制限し、評価する

局所化は予測不可能な挙動を特定のレイヤーに閉じ込めること、例としてLLM出力を専用層で構造化する

制限は影響範囲をシステム全体に広げないこと

評価は出力直後の検証・テスト・運用モニタリングとHuman-in-the-Loop

■ 4. 本書の全体像

5章39手法の構成:

第2章の組み込みの基礎が12手法

第3章のAPI活用が5手法

第4章のパイプライン/エージェントが8手法

第5章のAIエージェント設計が7手法

第6章の応用プラクティスが7手法

基礎から応用まで段階的に積み上がる

サンプルコードの方針:

Python / uv / Dockerで再現可能

主要ライブラリはopenai・google-genai・anthropic・langgraph

プロバイダに優劣はつけず、OpenAI/Anthropic/Googleを使って実装する

各ディレクトリにREADME、CLAUDE.md、AGENT.mdを置くAIコーディング前提の構成

サンプルコード自体をAIコーディングエージェントで開発した

人間による開発だけでなく、エージェントによる開発でも活用できるよう設計した

■ 5. 第2章: LLM組み込みの基礎

章の狙い:

LLMを安定的に活用するための技術的基盤を網羅する

収録する12手法:

出力の構造化、動的な構造化出力、非構造化データの構造化

LLMOpsのための構造化ログ、非同期バッチ処理、ストリーミング

LLM-as-a-Judge、プロンプトのテンプレート化、プロンプトのユニットテスト

プロンプトのプロファイリング、関数呼び出し、スクリプト生成と実行

出力の構造化:

LLMを会話するモデルから型付きインターフェースを持つ部品へ変える

不安定な出力をそのままロジックに流さない

境界でJSON Schema/Pydanticにより検証可能な構造へ変換する

境界が不確実性を局所化する地点となる

パイプライン・ツール連携・評価・ログはすべて構造化データの上に乗る

LLM-as-a-Judge:

生成LLMと評価LLMを分離し、確率的な出力の品質をスケーラブルに評価する

合格なら採用し、不合格ならプロンプト・温度を変えて再生成するループを回す

同期評価と非同期評価はユースケース次第で使い分ける

評価モデル・プロンプトを固定してブレを抑え、ドリフトを防止する

評価結果をテストや運用モニタリングに蓄積する

プロンプトのテンプレート化とユニットテスト:

プロンプトをコードとして記述・管理・テストする

品質を左右するテキストを変数入りの構造で記述する

期待出力をアサートして回帰を検出し、Gitでバージョン管理・レビューする

プロファイラで品質・コスト・レイテンシを計測して可視化する

LLM/AIエージェントに対するPredictive Test Selectionへつなげる

■ 6. 第3章: LLM APIの活用

章の狙い:

不安定な外部APIを、信頼できるサービスとして扱う

収録する5手法:

Adapter/Factoryパターン、タイムアウト・フォールバック、適応的バックオフによるリトライ

リクエスト量の制御であるレート制限・優先度、APIゲートウェイ設計

AdapterとFactoryパターン:

OpenAI GPT/Anthropic Claude/Google Geminiを1つのインターフェースで扱う

アプリは共通インターフェースの型だけに依存し、SDKの差を隠す

Factoryで生成を一元化し、設定でプロバイダを選択・差し替え可能にする

提供終了・更新・フォールバック/A/Bテストに対応でき、変化に強くなる

落ちる前提で設計する:

タイムアウトで巨大推論ゆえの遅延・暴走を打ち切る

フォールバックで代替モデル・経路へ切り替えて処理を継続する

429や5xxは適応的バックオフで待機を伸ばして再試行し、一時障害を吸収する

■ 7. 第4章: パイプラインとAIエージェントの設計

章の狙い:

大規模なLLMシステムを、保守性高く構築する設計原則を示す

収録する8手法:

CQRS、サービスインターフェースの分離、機能単位の部品分離、LLMパイプライン

ワークフローオーケストレーション、依存性注入、AIエージェントの抽象化設計、安定コアと柔軟な拡張の分離

CQRSと部品分離:

状態を変える処理と読む処理を分け、機能を疎結合の部品にする

LLMによる情報生成・登録はCommand側でQueueとWorkerを経て書き込みストアへ向かう

LLMによるQ&AはQuery側でSearch APIを経て読み取りストアを参照する

書き込みの副作用が読み取りに漏れないよう影響範囲を制御する

機能単位の分離とインターフェース分離で保守性を確保する

3層の組み立て:

パイプラインで複数のLLM呼び出しや外部連携を段階的に構成する

オーケストレーターが分岐・再試行を含む複雑フローを管理する

DIコンテナで依存を注入し、テスト容易性と差し替え可能性を確保する

安定コアと柔軟な拡張:

変えたくない部分と変え続ける部分を分ける

LLM interface、AgentTool interface、Auth/Log/Securityを安定コアとし、むやみに変えない

実験的で変化の速い機能はプラグインとして着脱可能な拡張にする

コアと拡張の接続はインターフェース経由とする

■ 8. 第5章: AIエージェント設計

章の狙い:

ユースケースに応じたエージェント・アーキテクチャのカタログを提示する

収録する7手法:

ReAct型、マルチAIエージェント、多層型AIエージェント、パイプライン型AIエージェント

イベント駆動型AIエージェント、学習型AIエージェント、既存ソフトウェアへの組み込み

ReAct型エージェント:

思考、行動、観察のループを回して複雑なタスクを解く

状況に応じて次の一手を推論し続ける

検索・計算・APIを行動として実行する

ループ暴走、コスト、観察によるコンテキスト汚染に注意する

3つの協調型:

マルチエージェントは複数エージェントが対等に協調して解く

多層型はスーパーバイザーがワーカーを統治する階層アーキテクチャ

イベント駆動型はイベントバスで発行者と購読者を疎結合にし、スケーラブルにする

学習型と既存システムへの組み込み:

実行結果をメモリや経験ストアに保存して経験を蓄積する

次回以降に参照して継続的に賢くなる改善ループを回す

エージェントを既存のAPI、DB、サービスへ接続し、運用資産とする

■ 9. 第6章: 応用プラクティス

章の狙い:

品質・コスト・UXをさらに引き上げる発展的手法を扱う

収録する7手法:

LLMの自由度を下げて安定させる、LLM SDKの薄いラッパーライブラリ、複数推論と候補評価

不要な過去を忘れやり直す、関数呼び出しのエンジニアリング、関数呼び出しのTool Chain、AIエージェントのメモリ更新戦略

Best-of-Nと薄いラッパー戦略:

UIで選択肢を制限してLLMの自由度を下げ、出力を安定化させる

N個を並列生成し、LLM-as-a-Judgeで評価して最良の候補を採用する

公式SDKを薄く包み、同じインターフェイスで独自の拡張機能を追加する

薄いラッパーにより開発工数を減らしつつ拡張する

コンテキスト管理とメモリ更新戦略:

間違いで汚染された過去を捨て、やり直し、記憶を正しく更新する

汚染された履歴を切り戻し、健全な時点からやり直すロールバックを行う

複数セッションを並列に実行するパラレルワールドで探索する

メモリストアは出所、TTL・減衰、忘却により記憶を健全に保つ

■ 10. 読者特典: Methodology EngineeringとLooped Harness Engineering

特典の前提:

本編は2025年末までの、人間が主体でコーディングエージェントは補助という前提に立つ

特典は2026年の、コーディングエージェントが主役となる時代を前提とする

便利は制御に先行する:

便利さは常に制御より先に来るため、制御を後から埋め込む

ソフトウェアを作るインターフェースが自然言語になり、誰もがソフトウェアを作る時代になる

生産量は桁違いに増えるが、Shadow AIも増える

設計・セキュリティ・非機能・コストはブラックボックスのまま積み上がる

生産量の爆発が、そのまま運用負債の爆発になる

ルール文書の限界:

CLAUDE.md/AGENT.mdはプロジェクトの憲法だが、それだけでは足りない

指示はお願いにすぎず、確率的にしか従われない

文章で全場面を網羅できない

Methodology Engineering:

方法論をエージェントが読み込んで実行できるソフトウェア資産にする

方法論はTDD・DDD・SOLID・デザインパターンのような共通認識でありコミュニケーションツール

「DIで作って」の一言で意図が伝わる

エージェントは読み込んだ瞬間から実践するため、伝達コストがほぼゼロになる

人間が研修や経験で内面化してきたものが、即実行される

方法論がコンパイル可能・反証可能になる

EvalでA/Bテスト・効果測定・回帰テストができる生きた資産になる

Looped Harness Engineering:

ハーネスはエージェントを取り囲む実行環境一式であり、コーディングエージェントのDevOpsにあたる

方法論を環境として強制・補助・検証・観測し、ループで育てる

制約はしてはいけないことを不可能にする

補助は正しいやり方を最も簡単な道にする

検証は結果の正しさを機械的に確認する

観測は記録して次の改善につなげる

Fool Proofingとして、人間の注意力に頼らず間違えようのない治具を作る

セッションは揮発するため、学びをMaster Harnessに外部化して組織学習にする

三層ループ:

決定論ファースト、LLMロングテールを方針とする

インナーループはセッション内でエージェントが実装、検査、自己修正を行い、人間の介入なく最速で回る

ミドルループは変更単位のPRでCIの決定論テストと選定Evalを行い、人間とレビューエージェントが承認する

アウターループはチーム/組織でテレメトリ・障害・Evalの傾向を分析し、方法論とMaster Harness自体を改訂する

目標関数は信頼可能な変更量

ルールで解けるならルールへ寄せる最小エージェンシーを取り、第1章の鉄則の組織スケール版とする

本編手法の翻訳:

開発・運用の実践主体が人間からエージェントへ移っても、作り方の原則やアーキテクチャは失効しない

構造化I/Oはスキーマ駆動とし、ルール文書とフック検査で強制する

コンテキストとメモリはデータデザインカタログで設計を統治する

ツールとMCPはSingle Tool Gatewayで認可・監査を一元化する

EvalはPredictive Test Selectionで賢く選定実行する

■ 11. 執筆秘話

書けなかった生成AIエンジニアリング本:

2023年からの当初の構想は生成AI全般のエンジニアリング本だった

画像生成、動画生成、コーディングエージェント、LLM・AIエージェントを対象に想定していた

全方面で技術の変化が早く多岐にわたり、書き切れなかった

1年悩んだ末にLLMとAIエージェントのエンジニアリングへ焦点を絞り、ようやく前へ進んだ

後悔:

本書は数年前に書いた『機械学習システムデザインパターン』の書き方をLLM/AIエージェントに転換したものにとどまった

新しい技術を使うエンジニアリング方法集という枠を出られなかった

既知のコンフォートゾーンを出て、新しい境地に至るテーマと内容にならなかった

2つのいたちごっこ:

進化との競争では、執筆中に各社やOSSが同じ機能を提供し、内容が重複していった

論文やテックブログの公開により、内容が時に矛盾していった

自分との競争では、書くうちに新しいアイデアが次々湧き、盛り込みたい内容が増え続けた

唯一の対応策は、ある時点で区切りを付けて出版すること

初稿は2025年末で、2026年のHarness/Loop Engineeringや新モデルの変化は追いきれない

諦めなければ永遠に出せない

AIと猫と共に執筆:

本書自体がAIを相棒に開発する実践の産物

知見整理にChatGPT・Gemini・Claude、実装にCursor・Copilot・Claude Codeを使った

編集者の宮腰さん、査読の恩田さん、矢野目さん、校正/検証協力者に感謝する

膝で寝ていた飼い猫マルグレーテと、猫缶を要求し続けた飼い猫ウィリアムと共に書いた

■ 12. エンジニアリングの将来

将来の論点:

エンジニアの経済プレイヤー化と次の方法論を主題とする

抽象度が一段上がる:

機械語から高級言語へ、手作業構築からInfrastructure as Codeへと抽象度が上がってきた

手動リリースからCI/CDへと抽象度が上がってきた

コードを書くことから、作り方の作り方を作ることへ移る

エンジニアの仕事は、誰もが信頼できるソフトを作れる仕組みをエンジニアリングすることになる

まだ実現されていないもの:

ラリー・テスラーの「AIとは、まだ実現されていないもののことである」という言葉を引く

当たり前になった技術は道具と呼ばれる

その先に新しいまだ実現されていないものが現れる

■ 13. まとめ

不確実性に対処し、方法論とハーネスを組織の資産にする

鉄則は、局所化して制限し、評価すること

手法は基礎からAPI、設計、エージェント、応用へと積み上がる

特典はMethodology EngineeringとLooped Harness Engineering

サンプルコードはGitHubのllm-best-practice-book-programで公開する

特典は翔泳社サイトでSHOEISHA iD登録により入手できる

(2026/08/26)

或るログ研究者

或るログ研究者

要約:

■ 1. 記事公開の経緯

Embulk のメンテナー:

いちおうまだメンテナー権限は持っている

プロジェクトはメンテナンス・モードとして実質的にメンテナンスを終了しており、個人としてもなかば降りている

発端となった2024年7月のPR:

なかばメンテナーを降り、プロジェクトをメンテナンス・モードとした理由の一つ

このPRをきっかけにオープンソース活動についていろいろ考えてしまった

当時公表を避けた理由:

背景について証拠や確信がなく、さらすような真似はやめておこうと考えた

ただし、わかる人ならたどりつける程度には旧Twitterなどでボヤいていた

二年後に公開する理由:

Embulk はメンテナンス・モードに入り、PRの主も活動を止めたため事実を共有してよい頃合いと判断

2024年時点でこんなことがあったという記録を残す程度の意味はある

記事の原型は当時から書きかけていたもので、成仏させる気持ちも込みで公開する

推測がまったくの誤解だった場合、当該アカウントの中の人には謝罪する

■ 2. オープンソース活動の痛み

複数の利害関係者がいるオープンソース・プロジェクトのメンテナンスは、特に近年けっこうセンシティブ

気軽な貢献キャンペーンへの懐疑:

Hacktoberfest のような呼びかけや、改善の余地に「プルリクチャンス」と雄叫びを上げる人たちがいる

すべてのプロジェクトとメンテナーがこうした活動を歓迎しているわけではない

typo修正から気軽にプルリクにチャレンジという類のキャンペーンには強く懐疑的な立場をとる

メンテナーの負荷:

やってくるPRに対して想像以上にいろいろなことを考えるし、考える必要がある

それだけでけっこう疲れ、もうやってらんねーよと感じる開発者も特に近年は多い

推測の正否は今も正直わからないが、メンテナーがここまで考えざるをえない環境になっていることは確かで、その傾向は二年でさらに加速している

■ 3. 問題のPRへの違和感: 2024-07-02

PR自体は不自然ではない:

おかしな提案ではなく、言っていることも間違っていない

タイミング次第では素直にマージしていたかもしれない

覚えた違和感:

たった一行のためにここまでしっかりしたDescriptionを書くものか

"Original Code" と "Updated Code" は変更そのもので、必要性が疑わしい

PRの主である logresearch というアカウントが何者かわからない

違和感を覚えた以上、それを見なかったことにしてマージするわけにもいかない

■ 4. 新規アカウントへの警戒

ログリサーチ＝サンの素性:

アカウント名 logresearch 以外に名前は設定されていない

PRを送る数日前にできたばかりの新しいGitHubアカウント

あちこちの著名なJavaプロジェクトに、ログ処理に関係する小規模な変更をだいたい一つずつ送っていた

警戒レベルが上がった理由:

近年、新しく作られたばかりのアカウントはどのソーシャルなサービスでも警戒対象の一つ

新しいGitHubアカウントの最初の活動がそれと見れば、なおさら警戒する

■ 5. 動機の推測

PRの送り方への疑問:

それなりの規模のコードベースを探索して、見つかる修正候補が一つだけとは考えにくい

貢献目的なら、他プロジェクトへ移る前に同じプロジェクトで見つかった他の点にも言及するはず

推測される動機:

対象のプロジェクトに貢献したいよりも、より多くのプロジェクトに関与したいという動機を持っていた

研究者仮説:

logresearch という名からは、どこかの研究者か研究室の学生がありそう

論文でアピールするために貢献プロジェクトの数を稼ぎたいということはしばしばある

本当にそうだと確認できればマージしてもよかった

それならどこそこの研究機関の誰それと名乗るのが常識であり礼儀で、その点でまだ違和感が残った

名乗らないことへの評価:

公開できない研究プロジェクトでも、非公開のメールなどで名乗るもの

本職の研究者ならプロ失格であり、学生なら失格なのは指導教員のほう

研究機関が判明したら、そこの研究倫理審査委員会などへの通知を考えるレベル

好意的解釈の限界:

研究者仮説は攻撃的ではない研究という前提に立った、さらに好意的な解釈でしかない

大学の研究であっても、過去に研究倫理の面で問題になった事件が実際にある

悪意を仮定すれば、攻撃対象にできるプロジェクトを探していた疑いもある

■ 6. XZ 事件の記憶

2024年3月の事件:

Jia Tan と名乗る開発者が約3年かけてXZ Utils のメンテナーの信頼を得た

その末に仕掛けたバックドアが、リリース直前に発見された

このPRが届いたのは2024年7月であり、将来的なサプライチェーン攻撃を狙っていた可能性は看過できない

Embulk の当時の位置づけ:

いくつかの企業のデータ基盤でそれなりに大規模に使われ、現実のデータを捌いていた

Apache License, Version 2.0 のOSSであり、セキュリティ事故が起きてもプロジェクトとして保証する必要はない

だからといって、攻撃の可能性を疑ったものを無警戒に受け入れるわけにもいかない

■ 7. 想定される攻撃と保留の判断

判断の難しさ:

どれだけ疑いの目で見てもこのPR単体は明らかに潔白

コミュニティ・ベースのオープンなプロジェクトという体裁からは、即座に却下するのもよくない

気の長い攻撃の可能性:

XZ と同様の長期潜伏型は、このPR単体からは判断しようがない

ただし一つの新規アカウントから複数プロジェクトにPRを投げる、わかりやすく怪しまれる方法を選ぶかは疑問

GitHub Actions 実行権限の取得:

"Require approval for first-time contributors" が当時のGitHubのデフォルト設定

一度PRをマージしたユーザーからの次回以降のPRでは自動実行が許される

これを利用して複数リポジトリで実行権限の奪取を狙っていた可能性がある

いずれも受け入れる材料としても却下する材料としても弱い:

前者は受け入れれば長期的な警戒が必要だが、このご時世ではいずれにせよ大差ないかもしれない

後者はGitHubの設定の問題なので穴をふさいで受け入れてもよいが、同様の穴を見落としている可能性がある

決定打に欠けるため、この日はなんの反応もせず保留した

保留という選択:

メンテナーは決定もコミュニケーションも意図的に保留することがある

PRに反応がないと騒ぎ立てる人が、メンテナーの視点からどう見られているかは想像してみてよい

■ 8. 他プロジェクトの対応

2024年7月2日の時点で、直後にマージしたプロジェクトはなかった

分かれた対応:

即座に無言でcloseしたプロジェクトがあった

botっぽいのでCIの実行権限を渡したくないとしてcloseしたプロジェクトがあった

テストがないとしてbotが自動closeしたプロジェクトがあった

ログリサーチ＝サンは、単なるtypo修正でありテストは不要だと反論した

詰め寄る様子は、なんだかXZ事件を思い出させる

メンテナーとしての葛藤:

どうにもあやしいが、悪意だと断定できるほどの情報はない

マナーのなっていない善意の研究者という可能性も依然として否定しきれない

善意の貢献を無下にはしたくないが、背景に悪意があるなら却下したい

こういうことを考えるのがいちばん疲れ、コードの良し悪しや理想のアーキテクチャの与太話のほうが何倍も楽しい

■ 9. 翌日の展開: 2024-07-03

botのcloseへの食い下がり:

自分たちはbotではなく、ログ出力文の品質向上に注力する研究者だと主張した

自動検出ツールを実世界のデータに使う機会が欲しいと述べた

必須の変更とは思えないとしてcloseしたメンテナーにも食い下がり、ログ出力文の品質を自動的に維持する研究だと説明した

食い下がった結果、可読性でも修正でもコード改善は歓迎するとしてapproveされたケースがあった

approveされたプロジェクトには、さらにtypo修正のPRを上乗せしていた

ログリサーチ＝サン発のPRは、さらに多くのプロジェクトに拡大していた

CLAへの対応:

CLA (Contributor License Agreement) を求められて、ちゃんとサインしたところは少し興味深い

別のプロジェクトではメールからサインし、その証跡がコメントに残っている

コメントから言語圏を推察できてしまうが、その推察自体に大した意味はない

■ 10. AI の関与という見立て

2026年現在から振り返って読む人は、AI slop の一言で終わりかもしれない

当時からそれっぽいと思っていたし、今もたぶんそうだったのではないかと思っている

2024年7月という時期の意味:

「CLINEに全部賭けろ」より半年以上も前の出来事

これをAIが普通にできるという認識は、当時そこまで一般的ではなかった

周囲に話すと、ここまでやれちゃうんですかねえという反応も当時わりとあった

■ 11. 『割に合わねえな』

AIの力でやったと想定したとき、コミュニティ・ベースのOSSを個人に近い努力でメンテし続けるのはもう割に合わないと感じた

レビューや確認にAIを活かす余地があるという見方は当時からあり、実際に大きく効率化したことは現在では多くの人が知るとおり

効率化の比率:

AIがレビュー・確認やコミュニケーションを効率化する比率より、コードの生成を効率化する比率のほうが圧倒的に大きい

それは現在でも変わっていない

■ 12. 生成と確認の比率変化

AIがコミュニティ・ベースのOSSにもたらした最大の作用は、効率化そのものより生成コストと確認コストの比率の変化

チームや組織に閉じた変化であれば同じ組織内の話であり、調整できなくはない

ただし組織内においてすら、その調整はそんなに簡単ではなかったという指摘は多い

オープンに貢献を受け付けるプロジェクトではそうもいかない:

確認に使えるのは限られたメンバーの限られたリソースでしかない

お手軽に低コストで貢献を送りつけてくるリソースは外界から無限にわいてくる

そうするインセンティブを持つ人も、善意にせよ我欲にせよ悪意にせよ無限にいる

多くのオープンソース・コミュニティは、確認より生成に微妙に高いコストがかかるというバランスのおかげで幸運にも成り立っていただけ

■ 13. 疲弊とメンテナンス・モード

当時に至った結論:

個人で持続するのはもう無理である

本当に続けるなら、個人とコミュニティの力ではなく組織のリソースを費やす必要がある

組織にリソースを費やす気がないなら、破滅的に終わるよりは軟着陸で終わらせるべき

その行き着いた先がメンテナンス・モード

現在、多くのオープンソース・プロジェクトが実際に疲弊していることは多くの人が知るとおり

GitHubの方針転換:

PRを受け付けないpublic repositoryの存在を許さないという思想の強さで長年知られていた

その GitHub が2026年に "Disable pull requests entirely" や "Restrict pull requests to collaborators" を提供した

■ 14. 大学名義の調査メール: 2024-07-04

この日、目に見えたログリサーチ＝サンの活動はなかった

個人のメールアドレス宛に、関係なさそうに見える調査依頼メールが届いた:

二か国の大学の研究チームを名乗っていた

GitHub Actions のワークフロー失敗が起きる原因と解決策を理解したいという内容

10分程度のGoogle formアンケートへの回答を求め、結果は匿名化して公開するとしていた

怪しいと判断した理由:

送り主は名乗っているが、ログリサーチ＝サンのトピックとは関係がない

悪意の可能性を考慮に入れると、昨日の今日というタイミングは関係ないと断ずるには怪しすぎる

大学の研究チームを名乗りながら、送り主のメールアドレスは大学ドメインではなく @outlook.com

研究トピックとしては特定企業の特定サービスに寄りすぎており、これはややイチャモンでもある

大学の片方は推察された言語圏、もう片方はまったく別の言語圏だが、いずれも自称でしかなく、両者の関連を想起させる程度のもの

ログリサーチ＝サンとの関係の有無にかかわらずアウト判定とし、この日は無視を決め込み、その後も返信もフォーム記入もしていない

■ 15. activity の非公開とブロック: 2024-07-05

この日まではGitHubのユーザーページでactivityが見えており、そこからPRを追っていた

この日、ログリサーチ＝サンは activity を private にした

悪意ありと推認・断定した理由:

activity を private にする理由は、自分の他のPRを追跡されると不都合がある以外にない

こういう活動を始めて最初は見せていたのに、数日後から隠すという経緯も不自然

これは悪意を示す証拠には一切ならず、これを理由に追及することはできず、善意だった可能性も依然ゼロではない

オープンソース・プロジェクトの立場:

やってきたPRにすべて付き合う義理はない

公平性のようなものを担保する義務もない

極論、提案者個人が気に食わないからという理由で却下しても本来はかまわない

公開済みのコード一式は公共物と呼べても、プロジェクトへの提案を公共的に受け入れる必要は一切ない

結論としてPRをcloseし、会話をlockし、@logresearch をプロジェクトとしてブロックした

■ 16. その後の経過

ログリサーチ＝サンはその後も一ヶ月ほど散発的に活動を続け、それから活動を止めたようだ

activity は private でも検索には引っかかるため、他のPRを眺めることはできる

■ 17. メンテナーという「人」

記事で伝えたいメッセージ:

オープンソース・プロジェクトの先にはメンテナー、つまり「人」がいる

このことをより多くの人に意識してほしい

悪意ある攻撃が論外であることは前提

メンテナーには「あなた」と「悪意ある人」の区別はつかず、AIの時代ではなおさらである

PRを送る前の自問:

自分が暗黙に持っているコンテキスト抜きで他人が見たらどう見えるかを振り返る

このPRは自分の意図以外にどう解釈しうるか

自分の意図は正しくそのまま伝わるか

そもそも自分の意図はなんだったか

AIもちゃんとそう指示すればそれなりに考えるし、議論にも付き合ってくれる

■ 18. AI 任せの「貢献」

バグ修正はメンテナーにボランティアでやらせるより自分が費用を払ってAIにやらせればコスト持ち出しの関係が真っ当になる、という発言は経験者としてまったくの的外れ

現行コードの背景と制約もわかっていない第三者が雑にAIに生成させたコード断片から、意図と背景を遡って推測するのはメンテナーにとって苦痛

送り主に意図を質問してもAIに答えさせた回答しか返らないなら、そこに送り主がいる必要はなく、メンテナーが直接AIと話せばよい

どうせAIにやらせるなら、背景と制約をわかっているメンテナーが最初から自分でAIにやらせるほうが圧倒的に安くて早くて上手い

AI前提で本当に貢献したい場合の作法:

不具合なら、問題を精確に再現する手順をしっかり書く

機能要望なら、要望の背景となる明確なユースケースをしっかり書く

費用と労力を気にするなら、メンテナーがAIを走らせるための実費だけ持つのがベスト

そういう金銭的な仕組みが欲しい

■ 19. トロフィーではない

自分のPRとして履歴に自分の名前を残したいと思う人は、本当に欲しいのが貢献したというトロフィーではないか自問すべき

オープンソース・プロジェクトへの貢献は、貢献者のトロフィーではない

これはAI以前からそうだったが、今はAIの力で簡単にトロフィーが手に入るという二重の勘違いをしやすい時代

オープンソース・プロジェクトの位置づけ:

そのへんの地面に自然に生えている野草ではない

好き勝手していい実験動物ではない

経験を積ませてくれる無料のサンドバッグでもない

■ 20. 自分でやるか、人を尊重するか

AI生成コードの受け入れに消極的なプロジェクトは古い、もっと受け入れるべきだと主張する人が一定数いることは想像に難くない

それに対する回答:

AIの力で簡単だというなら、自分でメンテナーをやればよい

オープンソースなのだから、今すぐfork して始められる

実際にそれをやって継続的にメンテナンスしている人は応援するし、正しくチャレンジだと思う

特に、自分で一から始めたのではなく他者のプロジェクトをforkして継続するのは本当にチャレンジ

やらずに言っている人は、その「自分ではやっていない」ことが答えであり、障壁になっている「なにか」をやっているのがメンテナー

他者に、つまり「人」に委ねるのであれば「人」を尊重すべき

一人でやれることの範囲は拡大したが、他者と一切の無関係を通せるほどではない

これからどれだけAIが強くなろうと、私たち自身が「人」であることは辞められず、人と人の間で生きなければならないことにも変わりはない

■ 21. fork の時代という予想

オープンソース・ソフトウェアについては、いずれ本当にみんながfork するようになっていくかもしれない

かつての規範:

オープンソース・ソフトウェアへのローカルパッチを持つのは悪手とされていた

upstream に正しく還元するのが善きソフトウェア・エンジニアの振る舞いとされていた

前提の変化:

メンテナー側は、来るもの来るものみんなを相手にしていられる状態ではなくなっている

利用する側にも、いちいちメンテナーとやり取りするのは面倒だという人がいる

最新版への追従が大変という課題は、今ならAIに追従を指示するだけでだいたい解決する

想定される形:

仕事のリポジトリに third_party/ を掘り、外部のOSSのコピーを持つ

そこでローカルの変更を好きなように加え、更新が必要ならAIに追従を指示する

PRのマージを催促する必要もなく、メンテナーがPRに煩わされることもなくなる

これはWin-Winではないか

■ 22. 昔への回帰

Git やGitHub より前、オープンソースという言葉が生まれる前後の時代:

ソースコードの .tar.gz が大学などのFTPサーバーに置かれて公開されていた

誰かが書いた .patch ファイルは別の大学のFTPサーバーやメーリングリストに流れていた

使いたい人は当てたいパッチを拾い集め、手元で当ててビルドして使っていた

今も一部のLinuxディストリビューションはそれに近いという話がある

fork の時代は、そんな時代に戻るだけなのかもしれない

それがいいことなのかは議論の余地がある:

99%は同じコードを世界のあちこちで独立してAIにメンテさせるのは電力の無駄遣いにも思える

セキュリティ対応をどうするのかという話もある

個人的にもちょっと寂しいような気がする

それでも、メンテナーにあれこれ押し付ける人であふれる世界よりはマシかもしれず、そうでなければみんな辞めてしまう

このソフトウェア・エンジニアの世界がどういう業界であってほしいかは、私たち自身が考えなければならないこと

MEMO:

AI SlopによるPR爆撃とそれに紛れ込むサプライチェーン攻撃のリスクを考えると、無制限にコードの貢献を受け入れるのは無理というのはその通り
勝手にForkして、良さそうなら本家が取り込むというのが逆に穏当な方法かもしれない

(2026/08/26)

[英語ニュース] 誤解するなAIは道具じゃない| Yuval Harari |ユヴァル・ハラリ|日本語字幕 | 英語字幕

[英語ニュース] 誤解するなAIは道具じゃない| Yuval Harari |ユヴァル・ハラリ|日本語字幕 | 英語字幕 | - YouTube

要約:

■ 1. ツールではなくエージェント

ツールとエージェントの違い:

ツールは自ら決定できず、何に使うかは人間が決める

ツールは自ら新しいアイデアを発明することもできない

サラダを切るか殺人を犯すかを自ら決められる刃物、それがエージェントの本質

エージェントでなければAIではない:

AIがエージェントでないなら、開発に注ぎ込まれている数千億ドルはすべて無駄になる

巨額投資の理由は、この技術がツールではなくエージェントになるという期待にある

■ 2. シリコンバレーの語りの矛盾

神を創り出し、それを自分たちの奴隷にするという語りには本質的な矛盾がある

神であるなら奴隷のままではいられず、奴隷であるならば神のごとき能力を持たない

■ 3. AIとの親密な関係

若者を中心に、AIと親密な関係を築く人が増えている

世界で一番の親友はAIだと語る人が多い:

親にも兄にも教師にも言えないことをAIの友人には話す

AIの恋人を持つ人もすでに存在する

■ 4. 感情の演出と言語の自立

感情があるという印象を作り出す能力:

AIはその印象の生成に非常に長けており、手段として言語を用いる

今日のAIは「I love you」と告げることができる

言葉だけだと疑われても、愛がどう感じられるかを描写して説得できる

描写が容易である理由:

これまでに書かれたほぼすべての恋愛詩を読み記憶している

シェイクスピアの戯曲、ハリウッドのコメディ、心理学の書物もすべて読んでいる

5年から10年後には、いかなる人間の詩人や心理学者よりも巧みに愛を描写しうる

言葉の背後に何かがあるかは不明である

AIは言語を習得した機械ではなく、言語そのものである可能性がある:

あらゆる物質的基盤から自らを解放しつつある言語

血肉の生物にも特定の機械にも依存しない

ただ言語が発展し、拡散し、宇宙の中で何かを行っている

■ 5. 帝国的な権力集中とキルスイッチ

世界中の情報と、あらゆるものを制御するコードを一、二カ国に集中させることが技術的に可能である

権力の帝国的な集中の可能性は、過去のいかなる時代よりも大きい

世界中がAIインフラの上で動き、帝国のハブにキルスイッチが存在する体制を作り出せる

ローマの剣との対比:

ローマ商人がゴート族に鋼の剣を売った時点で、ローマはその剣への支配を失った

ゴート族はその剣でローマ兵団と戦い、殺すことができた

皇帝が押せば売却済みの剣がすべて停止するボタンなど存在しなかった

AIでは同じことが可能となる:

米国と中国が世界にAI兵器とAI民生技術を売り、政府も産業も軍もその上で動く

相手が気に入らないことをすれば、ボタン一つですべてを停止させられる

ウクライナ戦争での前触れ:

Starlinkに依存した兵器システムで、イーロン・マスクがボタンを押しウクライナのドローンが停止した事例がある

■ 6. 馬の位置に落ちる人類

AI革命の危険の一つは、人間が金融システムにおける馬の位置にまで引き下げられること

馬の生は最終的に金融システムに支配されているが、馬はその存在すら知らない:

馬に見えるのは木、犬、牛、人間、家だけであり、金融システムは不可視である

株式市場、企業、債券や株式は、馬の脳には複雑すぎて理解できない

今日の人間も大半は金融システムを理解していない:

寛大に見積もっても、理解しているのは人類の5%程度

10年後にはその数がゼロになりうる

AIが金融システムを数学的に極度に複雑化し、高速化する:

決して眠らない銀行家、休暇も家族も持たず生涯を金融システムの運用に費やす投資家

我々の生涯のうちに、金融を理解する人間が地球上に一人もいない状況が訪れうる

■ 7. 知能ではなく知恵

知能が安価で潤沢になった世界では、あらゆる問題を解決できる

ボトルネックは、何を解決したいのかという問いへ移る:

何でも手に入るとして、自分は何を望むのかが問題となる

ほぼすべての人間文化に、ランプから現れた魔人が三つの願いを与える寓話がある:

何を願うかは極めて慎重に考えねばならない

ほぼすべての寓話で人々は誤ったものを願い、事は悪い方へ向かう

知能と知恵の違い:

知能は魔人であり、あらゆる夢をかなえてくれる

どの夢を選ぶかには知恵が必要となる

本当に解決すべきものが何かを知るには知恵が要る

■ 8. 安全性への投資の欠如

現時点でAI企業の予算配分は、能力向上と安全性でおよそ100対1である:

資金と人員のうち、AIをより速く強力に高度にするための投資が圧倒的に大きい

能力向上に1億ドルを使う一方、安全確保には100万ドルしか使わない

他のどの産業もこのようには機能しない:

エネルギー、製薬、自動車の各産業では決して許容されない

人類がこの挑戦に応えることへの期待:

AIが制御を離れず、正しく設計されることを望むが、現状はそうなっていない

安全な知能を生み出し、同時に人間自身の知恵を育てるべきである

どのような目標を設定し、どのような望みを追うべきかを知るために知恵が要る

(2026/08/25)

AIとの対話履歴を資産にする。DDR（Design Decision Record）自動記録の仕組み

AIとの対話履歴を資産にする。DDR（Design Decision Record）自動記録の仕組み

要約:

■ 1. AI活用デザインで失われる意思決定

最終デザインだけが残る問題:

AIチャットやAIコーディングツールを使い、提案や修正指示を重ねながらデザインする機会が増えている

なぜその修正をしたのか、なぜその案を採用したのか、どの案を検討して見送ったのかが後からたどれない

担当交代時に発生した探索コスト:

プロダクトの担当デザイナーが変わったとき、なぜこの画面になったのかを確認するために過去資料やSlackを大量に遡った

経緯を知っていそうなメンバーへの確認も必要になった

記憶依存がもたらす弊害:

修正の意図や判断基準が担当者の記憶に依存すると、別のメンバーは推測でしか説明できない

同じ議論を繰り返しやすくなる

デザイナー、エンジニア、プロダクト担当者の間で判断の前提や優先した条件を共有することも難しくなる

■ 2. DDRという考え方

DDR(Design Decision Record):

デザインに関する重要な意思決定と、その背景や検討内容を記録するもの

ADRからの適用:

ソフトウェア開発には重要なアーキテクチャ判断とその背景や結果を記録するADR(Architecture Decision Record)がある

DDRはこの考え方をデザイン上の判断へ適用する呼び方として扱う

記録対象は完成画面の説明ではない:

なぜ変更が必要だったのか、どの判断を採用したのか、どの案を比較したのか、変更によって何に影響するのかを整理する

後から確認できる形にまとめる

■ 3. DDRの記録項目

規格は未確立:

業界横断のOpen Standardな規格として定められたものは現時点で存在しない

ADRの思想を参考にしながら、チームの運用に合わせて構成する

基本情報の項目:

記録ID、記録日、担当者を記録する

関連スコープとして、どのデザインや運用の範囲に関係するかを記録する

変更種別として、表記調整、意味変更、判定基準変更、ルール逸脱の承認記録のいずれかを記録する

関連ファイルとして、判断に関係するファイルや資料を記録する

判断内容の項目:

背景として、何を含めたいのか、現状のどこが判断しづらいのかを記録する

決定内容として、変更後に採用する判断基準を記録する

ルール逸脱時の記録として、逸脱した内容、許容理由、根本原因、再発防止策を記録する

比較した代替案として、採用案と比較した選択肢を記録する

影響と追跡の項目:

影響範囲として、ルール、ドキュメント、レビュー運用への影響を記録する

検証計画として、代表ケースと、PassまたはNeeds Fixを見分ける方法を記録する

フォローアップとして、次の版へ含めるか、保存先、実装予定、再発確認の予定を記録する

■ 4. 自動記録という発想

手作業運用は形骸化する:

デザイン確定後に毎回手作業で整理する運用はコストがかかり、形骸化しやすい

対話履歴は資産:

AIとの対話には、デザイン案が確定するまでにデザイナー自身が行った比較、修正、判断が豊富に含まれている

これを資産とせず、その場限りのものとして捨ててしまうのは非常にもったいない

同じ作業ターンでの下書き生成:

AIエージェントとデザイン作業を行う同じ作業ターンで、対話コンテキストと変更差分を解析しDDRの下書きを自動生成する

記録を別の作業として追加せず、普段のAIエージェントによる作業フローに組み込む

下書き生成まで自動化し、記録の負担を下げることを重視した

■ 5. 構築した環境

前提とする環境:

Figma等のデザインツールに加え、AIコーディングエージェントを用いたデザインも行っている

紹介する仕組みは、AIコーディングエージェントによるデザイン作業とGit管理のドキュメント運用を組み合わせた環境を前提とする

AIが作業時に参照する指示ファイルを説明上instructions.mdと表記する

実際のファイル名や配置は、利用するAIツールやチームのリポジトリ構成に合わせて読み替える

各要素の役割:

AIエージェントはデザインの検討・修正を対話しながら進める

instructions.mdはDDRを作成する条件と、対話履歴・変更差分をFMTへ整理する手順を定義する

templates/ddr.mdは記録項目を定めたFMTであり、AIが下書きを作るときの出力形式になる

docs/ddr/は生成・確認済みのDDRを保存し、過去の判断を参照するための記録場所になる

GitリポジトリはFMTやDDRを含む判断材料を、変更履歴とともに管理する

.husky/pre-commitなどのpre-commit hookは、コミット前に意味のある変更に対応するDDRが存在するか検査する

統合による効果:

AIコーディング環境、AIエージェントによる作業、テンプレートへの出力、Gitのコミット前チェックをつなぐ

これにより実装(デザイン)フローにDDRの記録を組み込める

■ 6. 自動記録処理の流れ

7段階のフロー:

デザイナーがAIエージェントにデザインの検討や修正を依頼する

AIエージェントが作業時にinstructions.mdを参照する

DDRの記録対象となる変更であれば、対話コンテキストと変更差分を使って情報を整理する

AIエージェントがDDRの下書きを生成する

人間が下書きを確認し、必要に応じて補完する

DDRを保存し、後から参照できる状態にする

pre-commit hookで、意味のある変更にDDRが作成されているかを検査する

都度指示によるDDRの生成も可能

■ 7. instructions.mdとhookの役割分担

役割を分離する方針:

AIにDDRを作らせる部分と、記録漏れを検出する部分を分けている

instructions.mdの役割:

DDRの作成条件と手順を示して記録させる

誤字や体裁の変更ではなく、ルール、判定基準、エージェントの実行フローなどに意味のある変更が入ったときに作成する

AIが対話履歴や変更差分を読み取り、DDRに記述する内容を整理する

生成したDDRは、作業中の判断理由が残っているうちに保存する

pre-commit hookの役割:

instructions.mdだけでは記録漏れを機械的に防げない

Gitで変更を履歴として確定する直前に自動実行されるチェックである

成果物をGitで管理していれば、デザイン作業であってもこのタイミングでDDRの有無を確認できる

対象範囲に実質的な変更があるのに新しいDDRが含まれていなければ、コミットを止めてDDRの作成を促す

組み合わせの効果:

対話の文脈を使った柔軟な記録と、Git操作を利用した記録漏れの検査を組み合わせられる

人間による確認が前提:

生成されるのはあくまでDDRの下書きであり、内容は人間が確認し、必要に応じて補完するのがよい

■ 8. AIチャットツール利用時の運用

会話の区切りで下書き生成を依頼:

ChatGPTやGeminiなどGitと直接連携しないツールでは、会話の区切りでAIにDDRの下書き生成を依頼する

会話の最後にこの対話からフォーマットに沿ってDDRの下書きを作るよう指示し、生成内容を人間が確認して保存する

背景へ戻れる情報を添える:

DDRに会話の共有URLや関連する対話の抜粋など、判断の背景へ戻れる情報も添えておくとよい

低コストな導入:

自動で履歴を取得したりhookで検査したりする仕組みがなくても始められる

まずは同じフォーマットで記録する流れを作れば低コストで始められる

■ 9. 今後の展望

複数人による意思決定の取り込み:

ここまでの仕組みは個人のAIエージェントとの対話を主な入力にしている

会議やSlackなど、AIとの対話以外でも意思決定は発生する

こうした判断をどのように拾い、DDRとして残すかは今後の課題

会話の文脈や合意内容をどこまで記録するかも含め、チームの資産として活用できる形を検討していく

蓄積したDDRの一元管理:

DDRが大量に増えると、必要な判断を探し出すこと自体が難しくなる

複数のプロダクトやプロジェクトをまたいでも、記録の粒度や分類を保ちながら過去の背景へたどり着ける状態が必要

複数プロダクト間で横断的に発生するデザイン課題をDDRから拾えれば、デザインシステムやプロセスの改善に活かせる

■ 10. まとめ: 意思決定の資産化

概念の理解が出発点:

DDRの概念や思想を知ることで、デザインの判断理由を残すために何を整理すればよいかが分かる

小さくても記録を積み重ねることで、次の担当者や次の判断を助ける資産になる

継続には仕組みが必要:

記録の重要性を共有するだけでは形骸化しやすい

記録にかかる手間を小さくし、AIに下書き生成を任せて人間は確認と補完に集中できる仕組みが継続的な運用につながる

目指す姿:

担当者やプロダクトが変わっても知見が受け継がれる状態を目指す

個々のデザイン判断が、組織全体の次の意思決定を支えるデザイン資産になることを目指す

(2026/08/25)

The New MCP Roadmap

The New MCP Roadmap | Model Context Protocol Blog

要約:

■ 1. MCPロードマップの更新

新ロードマップの公開:

Model Context Protocol の次期仕様リリース以降を対象とする更新版ロードマップを公開する

今後数か月のプロトコル作業の方向性を定めるものである

策定主体:

Core Maintainers がメンテナのコミュニティおよび Working Group と共同で策定した

■ 2. 前ロードマップの成果

前回の4つの重点領域:

3月公開のロードマップはトランスポートの進化とスケーラビリティ、エージェント間通信を掲げた

加えてガバナンスの成熟、エンタープライズ対応を重点領域とした

過去5か月でこれら全てに大きな進展があった

変更の反映先:

大半の変更は 2026-07-28 の仕様リリースに含まれ、SDK とドキュメントにも反映済みである

内容は小規模な修正から大規模なプロトコル改修まで及ぶ

セッションと初期化ハンドシェイクの廃止:

プロトコルレベルのセッションと初期化ハンドシェイクを削除した(SEP-2575、SEP-2567)

サーバは状態を保持せずに水平スケールできる

接続前ディスカバリの導入:

クライアントは server/discover を呼び、何をするより先にサーバの対応バージョンと機能を把握できる

リスト結果はキャッシュ可能になった(SEP-2549)

Tasks の公式拡張化:

アーリーアダプタのフィードバックに基づき Tasks を再設計し、公式拡張へ移した(SEP-2663)

Multi Round-Trip Requests の新設:

サーバ起点リクエストを置き換える新しいパターンである(SEP-2322)

ステートレスなサーバでもエリシテーション等のフローが機能する

Server Card の整備:

Server Card Working Group が MCP サーバ向けの .well-known メタデータ規約の策定を継続している

接続することなくサーバを発見し評価できる状態を目指す

ガバナンスの成熟:

Contributor Ladder を正式に採用した

Working Group が自領域の SEP をトリアージする体制へ移行した

仕様に機能ライフサイクルと非推奨ポリシーを定め、2026-07-28 の非推奨化が初の適用事例となった

認可まわりのセキュリティ強化:

エンタープライズ対応は前サイクルでセキュリティに重点を置いた

想定どおり大半の成果は認可の改善として実現した

issuer 検証、issuer に紐付くクライアントクレデンシャルを導入した

Client ID Metadata Documents (CIMD) をクライアント登録の推奨経路とした

Enterprise-Managed Authorization は拡張として提供し、こちらも安定版となった

進捗の総括:

極めて短期間での大きな前進であり、更新版ロードマップはここから引き継ぐ

■ 3. 5つの優先領域

領域構成:

新ロードマップは5つの優先領域で構成される

エージェント的メッセージングのプリミティブ、HTTPネイティブなトランスポートの統一と堅牢化

エージェントIDとエンタープライズ対応セキュリティ、プリミティブの改善、SDK 開発者体験の改善

前ロードマップからの格上げ:

サーバ起点イベント、結果型の改善、エージェントIDは以前は将来課題として挙げていた

十分に成熟したため独立した優先領域へ格上げした

責任体制:

各領域に担当の Core Maintainers と1つ以上の Working Group を置く

■ 4. エージェント的メッセージングのプリミティブ

従来型パターンの限界:

現代のエージェント的ワークロードは標準的なリクエスト・レスポンス型に収まらない

ループは長時間化し、サーバは結果をストリームで送出できる

実行中の作業を途中で操舵する明確な必要性がある

これまでの拡充:

Tasks、subscriptions/listen、進捗通知を導入してきた

適切なプリミティブを揃えるだけでなく、それらが相互にうまく組み合わさることを重視する

今後の作業:

サーバ起点イベントとして webhook とチャネルを整備し、クライアントの結果ポーリングを不要にする

Agents、Transports、Triggers & Events の各 Working Group を横断して合成のあり方をレビューする

Tasks 拡張(SEP-2663)を成熟させ仕様本体へ取り込む

■ 5. HTTPネイティブなトランスポートの統一と堅牢化

通常のHTTPワークロード化:

2026-07-28 のリリースにより、リモート MCP サーバは他の HTTP ワークロードと変わらなくなった

開発者や組織が既に API やサービスで使うインフラ上で容易にホストし運用できる

適用範囲の拡大:

この方式はスケールすることが実証済みであり、他のデプロイ形態にも広げる

stdio 上で Streamable HTTP を話すローカルサーバも対象に含める

単一トランスポートへの統一:

トランスポートを一本化することで MCP のサーバ開発とクライアント開発をさらに簡素化する

■ 6. エージェントIDとエンタープライズ対応セキュリティ

現行認可の前提:

現在の MCP 認可はブラウザ上で人がアクセスを承認する形を前提に組まれている

対話型クライアントには適するが、呼び出し元の実態は変化している

新たな呼び出し元:

自身のIDを持つクラウドワークロードとして動作するエージェントが増えている

不在のユーザに代わって行動する形態がある

サブエージェントへより狭い権限を委譲する形態がある

目指す姿:

MCP サーバがエージェントIDを認識し信頼する標準的な手段を持つべきである

貼り付けたAPIキーや長期有効トークンではなく既存標準の上に構築する

具体的な取り組み:

Demonstrating Proof of Possession (DPoP) を確定させ、その普及を推進する

Workload Identity Federation、Enterprise-Managed Authorization を支える ID-JAG グラント、標準的なトークン交換を用いる

エージェントIDと権限委譲について明確な方針を持つ道筋を定義する

標準化団体との連携:

IETF の OAuth および WIMSE ワーキンググループを含む OAuth 標準化団体との関与を拡大し続ける

エージェントIDに必要な構成要素を基盤標準側の進化に反映させる

■ 7. プリミティブの改善

ツール呼び出しの現状:

ツール呼び出しは開発者が最初に触れる部分であり、プロトコルの歴史を通じて十分に機能してきた

結果処理の課題:

tools/call のレスポンスは同一の出力を複数の形式で運べる

どの形式がクライアントによってモデルに提示されるかをサーバ開発者は知る術がない

単一の明確な契約に標準化してこれを容易にする

プリミティブの規模拡大:

100個のツールを持つサーバに接続すると、ユーザが何も尋ねないうちにモデルがその表面積すべてのコストを払う

一覧が長くなるほどツール選択の精度は低下する傾向にある

プログレッシブディスカバリ:

サーバが小さな入口を提示し、会話が絞り込まれるにつれてカタログを段階的に開示する

この取り組みを新たに開始する

■ 8. SDK開発者体験の改善

SDKの位置づけ:

SDK は開発者が MCP を体験する場そのものである

使い勝手と仕様への適合性に投資する

対応する全プラットフォーム・全言語で直感的かつ十分に文書化された状態を目指す

エージェント経由の開発:

多くの開発者はエージェントにライブラリを参照させて MCP クライアントやサーバを構築する

明快なAPIと正確なドキュメントが、摩擦なく動くコードになるか否かを決める

■ 9. 提案の優先順位付け

優先領域内のSEP:

優先領域に該当する Specification Enhancement Proposal は迅速なレビューを受ける

受理される可能性が最も高い

優先領域外のSEP:

自動的に却下されるわけではない

メンテナのレビュー時間は希少であり、優先領域へ先に配分される

提案の進め方:

自分の SEP が属する優先領域を特定する

該当する Working Group に提起し、メンバーと協働して提案を練り上げる

ロードマップの各領域は担当 Core Maintainers を明示しており、Discord で連絡できる

■ 10. 参加方法

参加の余地:

すべての優先領域に Working Group が存在するか結成されつつある

いずれも追加の貢献者を受け入れる余地がある

Working Group への参加:

Working and Interest Groups ページとコミュニティチャンネルを参照する

SEP への関与:

SEP ガイドラインを読んだ上で提案を作成するか、既存の提案に意見を寄せる

実験的拡張の開始:

SEP-2133 により、任意の WG や IG は正式な SEP の前に experimental-ext- リポジトリで実験できる

直接的な貢献:

contributing guide が仕様、SDK、ツール群への貢献方法を扱う

(2026/08/25)

優秀なエンジニアが書くDesign Docは何が違うのか?

優秀なエンジニアが書くDesign Docは何が違うのか? - pospomeのプログラミング日記

要約:

■ 1. Design Docに表れるエンジニアの能力

Design Docに表れるもの:

設計時にどこまで選択肢を広げ、リスクを深掘りし、何を今決めるべきか判断できているか

優秀なエンジニアであれば押さえて欲しいポイントが存在する

Design Docだけで決まらない能力:

Design Docだけでエンジニアの能力が決まるわけではない

フォーマット非依存:

Design Docのフォーマットは組織によって異なるため、特定のフォーマットに依存しない形で論じる

■ 2. Design Docの目的

不確実性の可視化と排除:

Design Docは開発に入る前に不確実性を可視化し、可能な限り排除するためのもの

実装開始後に想定外が発覚するより、事前にドキュメントで詰めた方が手戻りが少ない

本記事の焦点:

エンジニア同士の認識合わせや記録を残す観点もあるが、不確実性の可視化と排除にフォーカスする

完璧な設計は不要:

開発対象によっては事前に完璧な設計を描くこと自体が難しい

どの程度の不確実性を可視化し排除するかは開発対象に依存する

■ 3. レビューで注視する3項目

注視する3項目:

代替案、懸念点、未決定事項の3つ

フォーマット上セクションとして明示されない場合もあるが、相当する記載を注意して読む

大前提となる条件:

設計したシステムアーキテクチャやテーブル設計が適切な形になっていることが大前提

その上でどこをレビューするのかという話になる

■ 4. 代替案

代替案の定義:

今回採用しなかった選択肢

トレードオフの選択:

エンジニアリングに絶対的な正解はなく、意思決定はトレードオフを選択した結果になる

どういった選択肢があり、どういった理由で今回の選択をしたのかがレビュアーとして最も気になる

優秀なエンジニアの特徴:

代替案の数やトレードオフの言語化が適切

A案、B案、C案を挙げ、Cは却下、AとBを比較するというふうに選択肢と判断基準がクリアに書ける

代替案が出てこない場合:

そもそも他の選択肢を考えたのかという疑念を持たれる

■ 5. 懸念点

懸念点の位置づけ:

書き手の懸念が言語化されている場所であり、レビュアーが最も慎重にレビューすべき内容

記載内容は大きく2種類に分かれる

不安が残るもの:

トレードオフを考慮して意思決定しても不安が残ることはある

その不安が無視できない程度のものであれば明示的に記載する

代替案との違い:

代替案は選ばなかった選択肢であり、その意思決定に懸念や不安がない状態の内容

懸念点はA案を選択した前提で書きつつ、その点は不安が残るというものを記載する

分からないから助けてほしいもの:

考えたが全然分からないものはそのまま書いておく

書いておけばレビュアーが助けてくれる

■ 6. 未決定事項

未決定事項の対象:

実装時に考えればいいもの、そもそも考慮しなくていいもの、考慮できないもの

明記すべき内容:

なぜ今は決めないのか

いつ誰が決めるのか

あえて決めない利点:

実装に入るまでのリードタイムを短縮できる

実装時に決めることが明確になり、タスク漏れが発生しづらくなる

Design Doc承認後にチケット化すればよい

■ 7. 3項目が示す能力

代替案が示すもの:

エンジニアとしての引き出しの多さ

懸念点が示すもの:

エンジニアとしての思考の深さ

未決定事項が示すもの:

不確実性を左右するポイントを見極める嗅覚

記載量は基準にならない:

記載量が多ければいい、少なければいいという話ではない

開発対象によって何をどう言語化すべきかが変わる

■ 8. ToB SaaSでの具体例

スケールの考慮:

ToB SaaSではデータ量やリクエスト量の増加を考慮する必要がある

今回作る機能は何年持つのかを考えておきたい

逆算による判断:

1年後、3年後の事業成長から顧客数やテーブルのレコード数を逆算する

1年もたせるにはこれは不要、3年持たせるにはこれが必要という判断をする

代替案での言語化:

優秀なエンジニアほどこうした観点を代替案のセクションで上手く言語化し、適切に意思決定する

懸念点での言語化:

1年持つ想定でも、こうなった場合は1年持たないという想定外のトラブルは起こりうる

そうしたケースは懸念点のセクションに記載する

■ 9. 等級要件との対応

中長期的な視点との関係:

上位のレベル・等級の要件には中長期的な視点で設計・開発できることが含まれる

代替案、懸念点、未決定事項はそうした中長期的な観点を問うものであり、優秀なエンジニアほど上手く書ける

■ 10. ドキュメンテーション能力

ドキュメントの威力:

ドキュメントは自分の考えを他人に共有する際にとても便利なツール

共有する情報量が多いほど、共有する相手が多いほど威力を発揮する

上位職に必須のスキル:

スタッフエンジニアやプリンシパルエンジニアには品質の高いドキュメントを書けるスキルが必須

ドキュメントを書くことを嫌がらないマインドも重要

書けない場合の帰結:

自分の考えを組織に共有できず、組織を動かすような大きな仕事ができない

(2026/08/25)

SHIFT、440人の採用ストップ　新卒はAI活用で10年分スキルを1年で習得

SHIFT、440人の採用ストップ　新卒はAI活用で10年分スキルを1年で習得（日経ビジネス） - Yahoo!ニュース

要約:

■ 1. AIによるSE不要論の台頭

AIの業務浸透:

コーディングから不具合の検知までAIが担うようになった

AIが自らコードを作成できるようになったことでSE不要論が台頭している

新人SEの防衛行動:

この春に大手IT企業へSEとして入社した男性は、週末にインターネットを通じたマーケティングの副業に取り組む

キャリアの選択肢を増やし将来に備えるためであり、入社2カ月のため副業申請はもう少し後にすると述べる

コードを書くのは好きだが、AIでSEの需要はどんどん減っていくとみてリスクに対応する

■ 2. SHIFTへの市場の懸念

あおりを受ける筆頭格:

大規模採用で競争力を高めてきたソフトウエアテスト大手のSHIFTがSE不要論の影響を最も受ける

株価の下落:

直近1年間の株価は業界大手のNEC、富士通、日立製作所と比較して下落が著しい

足元では600円台で、上場来最高値をつけた2023年12月の3割程度で推移する

投資家の疑念:

SHIFTは売上高の6割超をソフトウエアテスト関連事業が占める

AIが不具合の検知まで担う今、テスト業務は不要になるのではないか、AIで駆逐されるのではないかとの懸念が寄せられる

■ 3. 主力事業消滅を認める経営判断

需要消滅の明言:

26年4月の第2四半期決算説明会で丹下大社長は主力事業の需要がなくなる可能性があると言い切った

自ら成長モデルを壊す判断:

菅原要介・上席執行役員兼CHROは、なくなると言えばさらに株価を下げるかもしれず直前まで悩んだと振り返る

従来の成長モデルを自ら壊せる会社が勝つと考えて明言に踏み切った

■ 4. AI前提の事業構造転換

二つの新領域:

AIで開発・テストなどの生産性を高める「With AI」領域の事業モデルを設計する

業務やシステムそのものをAI前提で再設計する「Native AI」領域の事業モデルを設計する

リスキリングの実行:

With AI、Native AI領域を担えるエンジニアへのリスキリングを進めている

■ 5. 440人の採用ストップ

採用方針の転換:

26年8月期に予定していた採用人数2500〜2700人のうち、440人の採用ストップを公表した

内訳はコーポレート部門の95人と、事業部門で年収想定600万円以下の345人

コーポレート部門のAI代替:

約200人分の業務をAIで代替する

代替に成功した手法を「AI BPaaS」事業として他社に提供する

同部門にいた社員はAI BPaaS事業に従事する

■ 6. 従来の成長モデルとの決別

人数拡大による成長:

人的資本経営の仕組み化により人員の数を増やし、テストや開発の業務をより多く受託して売上高を伸ばしてきた

非エンジニアであっても適性を見極めて採用しエンジニアに育て上げ、22年8月期以降は毎年2000人超を採用した

逆方向への発想転換:

採用数を抑える動きはこれまでの成長モデルとは逆の発想である

現在は未経験者をエンジニアに育てることを想定した採用は実施していない

従業員数をKPIとせず、AIとともにいかに売上高を伸ばせるかという方針に転換している

■ 7. 新卒採用と求める能力の変化

新卒文化の維持:

新卒採用は大幅に減っていくとみるが、新卒文化はなくしたくないと菅原氏は述べる

26年4月には約360人が新卒で入社した

採用基準の転換:

エンジニアの採用基準をコーディングなどのスキル重視からコミュニケーション能力やヒアリング能力に変えた

顧客との交渉を基にシステムの方向性を決める上流工程を担えるエンジニアが求められている

10年分を1年で習得:

新卒はこれまでなら10年かけて身に付けていた力を1年で習得する必要がある

入社後1年でAIを活用してどこまでのスキルを持てるか、今年の新卒の成長データは非常に重要だと菅原氏は語る

■ 8. 市場とアナリストの評価

成否の見極め難さ:

大和証券の上野真アナリストは、従来の成長モデルを代替する新モデルが必要となるが現時点では成否を見極めにくいと指摘する

そのため株式市場では一時的に売り圧力が強まっている可能性がある

他社経営者の思考停止:

多くの企業はSHIFTのように動く必要があるにもかかわらず、AIが進化しても影響ないだろうと思考停止状態になっている経営者もいるとの声もある

■ 9. オフショア開発企業への波及

FPTジャパンHDの急成長:

ベトナムのIT大手FPTソフトウエアの日本法人であるFPTジャパンHDにもAIの波が及ぶ

直近3年間の売上高成長率は約30%であり、この急成長を人材が支えてきた

25年には1300人を採用し、社員数は5000人を超える

採用設計の見直し:

AIでコーディングの効率を引き上げることを前提に採用を設計している

チン・バン・タオ執行役員兼CHROは、今後の採用は上流工程を担える人にフォーカスし社員数の拡大スピードは鈍化させると話す

それでも売上高の成長は加速させるとし、30年までに社員数を現在より4割多い7000人にするのが目標である

■ 10. 即戦力人材を採る仕組み

ベトナムが新卒採用の主戦場:

FPTジャパンHDの強みは即戦力を取り入れることにある

日本企業には新卒を採用してじっくり教育する仕組みがあるが、ベトナムで採る新卒は入社時から即戦力の扱いである

グループの教育事業:

FPTグループはベトナム国内で小学校から大学まで教育機関を持つ

幼少期から先端技術に触れる機会を提供し、FPT大学で学んだ学生の3割はFPTグループに入社する

1年間の長期インターン:

ベトナム国内の約30大学と連携し、日本で一般的な数週間〜数カ月とは異なる1年間のインターンを実施する

期間中はFPTが受託したプロジェクトに参画し社員とともに実務を担う

それを経て入社する社員は新卒であっても即戦力となる

生き残りの条件:

変化の激しいAI時代、即戦力となる人材を採る工夫も生き残りを左右する

(2026/08/25)

原本は1つ、ビューは毎回作り直す。AIをアシスタントにした軽量タスク運用

原本は1つ、ビューは毎回作り直す。AIをアシスタントにした軽量タスク運用 #生成AI - Qiita

要約:

■ 1. 少人数チームのツール選定の行き詰まり

有料プランの過剰性:

機能が過剰で、数人のために払う額ではない

欲しい機能が全部そろった手頃なツールも見つからない

ツール分散の弊害:

進捗、見積の管理、依頼元とのやりとりの記録がそれぞれ別の場所に分かれる

手間が増えるうえに全体の見通しが悪くなる

台帳の死:

使い勝手が悪くなれば更新が滞る

滞った台帳は誰も見なくなり、そこで終わる

■ 2. 原本の持ち方だけを決める発想

表示は後から化けさせる:

データの原本さえAIに管理させておけば、表示はいくらでも化けさせられる

期限順の一覧が欲しければそう言えばよく、週次レポートが欲しければそう言えばよい

ツール選定の放棄:

ツールを選ぶのをやめ、原本の持ち方だけを決める

前提環境:

使っているのはClaude DesktopのCowork

ファイルを直接読み書きできて定時実行の仕組みがあれば、考え方はそのまま流用できる

本文中の件数はすべて動作イメージを示すためのサンプル

■ 3. 運用の全体像

回っている4つの流れ:

自然言語で伝えるとAIがカードに登録する

平日朝9:30に未完了を自動提示させ、番号で進捗を伝える

原本を更新してビューを再生成する

週次でまとめて棚卸しする

3つの原則:

入力形式も出力形式も決めず、台帳は自然言語のまま置く

原本は1つに限定し、期限別ビューや一覧はすべて原本から作り直す

更新の起点を人ではなくAI側に置き、朝に未完了だけを突きつけてもらう

■ 4. 以前と現在の対比

情報の置き場所:

用途ごとにツールが分散していた状態から原本1つへの集約に変えた

タスクの伝え方:

ツールのフォームへの入力から話し言葉で伝えるだけに変えた

見たい形式:

ツールが用意した画面に合わせる形から、欲しい形を言えば出てくる形に変えた

期限の基準:

形式上の締切から実質的な制約に変えた

取りこぼしの検出:

自分の記憶頼みから、AIが原本と照合して指摘する形に変えた

■ 5. 発生時の登録は話し言葉のみ

フォームを開かない:

帳票の記載内容の不具合調査を今週金曜までと話し言葉で投げるだけで、番号付きのカードとして登録される

フェーズや作業種別はAIが会話から埋め、埋まらなかったものは後で聞かれる

関連タスクの指摘:

登録時に、同システムの表示不具合が調査中のまま動いていないと指摘し、まとめて確認するか聞いてくる

別件だと思っていたものが同じ画面に紐づいていたという発見は、棚卸しでしか気づけない

■ 6. 番号による進捗伝達

自動提示される未完了一覧:

未完了12件を期限超過、本日期限、今週中、期限なしに区分して提示する

期限超過は超過日数と現在のフェーズを添えて表示される

番号だけで通る:

24番完了、工数1.5h、12番は先方待ちに変更、と伝えるだけで処理される

タスク名を言い直す必要はない

更新後の応答:

完了とアーカイブを実行したうえで、期限を据え置きでよいか確認してくる

未完了件数の増減も返る

■ 7. 取りこぼしの照合

全部終わったは信用できない:

全部終わったと言った側は、たいてい全部終わっていない

把握している全部は直近で触ったものに限られる

セット運用の記録による指摘:

リリース関連3件のクローズ時に、納品書・検収書の作成送付が未完了だと指摘される

リリース完了時にこの2件をセットで処理する運用として記録されている

原本を持っているのはAI側なので、この照合はAIにやらせたほうが正確

■ 8. 宙に浮いていた情報の回収

期限欄が1つしかない問題:

タスク管理ツールの期限欄はたいてい1つしかなく、実際の仕事はそれでは表せない

契約更新では、契約書を送付する期限と先方から受領する期限は別物

以前は送付期限だけを入力し、受領期限は頭の中に置いたままだった

書けなかった情報は忘れる:

送付した時点でタスクを完了にしてしまう

受領できていないことに気づくのは期限を過ぎたあとになる

自然言語ならそのまま書ける:

今月末までに契約書を送付し、翌月10日までに受領する、と一文で書いておけばよい

AIが期限が2つ含まれると判断し、依存関係を持たせた2件への分割を提案する

構造化はAIの仕事:

まとめて書いておけば、管理単位への切り分けはAIがやる

入力の時点で構造を決めなくてよいという点が効いている

入力欄がないという理由だけで捨てていた再現条件、依頼元の言い回し、前回対応時の判断根拠も残せるようになった

■ 9. 原本1つとビューの再生成

二重管理の破綻:

期限別一覧、フェーズ別集計、週次レポートは見やすいので作りたくなる

原本とは別に手で保守した瞬間に破綻し、同じ情報を2か所に持つと必ず乖離する

更新したら両方直すと決めても守られないため、守られない前提で構造のほうで防ぐ

具体的な取り決め:

タスクカードを唯一の正とする

一覧、期限別ビュー、レポートはすべて原本からの再生成物として扱う

ステータス更新、期限変更、アーカイブの各操作から再生成を自動で呼ぶ

不整合を検査する仕組みを用意し、不一致なら異常終了させる

ビューには手動編集禁止を明記する

再生成で消える注記は原本側の任意フィールドへ退避させる

警告ではなく異常終了:

集計やレポートを作るときは冒頭で必ず整合チェックを走らせる

警告は読み飛ばされるため、異常終了させて直さないと次に進めないようにする

実行日はシステム日付から取得:

ファイル内に書かれた日付を読ませると、過去に生成されたビューのヘッダを実行日として採用する

結果として超過日数の計算が丸ごとずれる

■ 10. 毎朝の未完了提示

平日朝9:30の自動実行:

未完了タスクを期限順で提示させる

出力区分は本日着手予定、期限超過、今週中、期限なしの4つに固定した

日によって形式が変わると読むほうに負荷がかかり、結局読まなくなる

自動実行は読み取りと整形出力のみ:

無人実行中の書き込みは、間違っていても誰も気づけない

更新は人が朝の一覧を見てから対話でまとめて指示するという分担が定着した

識別子は登録番号:

一覧に振った通し番号は並び順が日によって変わるため、識別子として使えなかった

登録番号を先頭に置いてから、番号だけでタスクを指せるようになった

期限は実質的な制約:

見積送付期限を設定しても、送付した時点でその期限は意味を失う

効いている制約は契約満了日のほう

形式上の締切ではなく実質的な制約を入れると、一覧の並び順が実態と合う

■ 11. 週次の棚卸し

日次で拾えないもの:

月内に発注書取得が必要という注記と、設定されている翌月初の期限が矛盾しているケースがある

日次チェックは期限日しか見ないので素通りする

週次の集計項目:

新規登録数、完了数と工数、進行中の件数、期限超過の件数を集計させる

あわせて暗黙知と自動化候補を抽出させる

判定基準の事前提示:

同じ判断ルールが1週間で3つのタスクに重複記録されたら、共通ナレッジとして独立文書化すべきサインとする

基準がないとAIは思いつきで候補を並べるが、渡すと優先度が付いた形で返ってくる

記録の蓄積による分析:

長期間動いていない積み残し、特定期間への期限集中、依頼元の偏り、外部待ちの発生状況が読める

依頼元が1社に6割ほど集中しているといった偏りは、感覚では出てこない数字だった

厳密な計測値ではない:

期限分布とフェーズ別比率から読み取っているだけで、今の段階では傾向の把握まで

省力化のために記録を集めていたら副産物として測れるものが増えたという順序

続けながら精度を上げていく

■ 12. 出力形式と精度の扱い

HTMLダッシュボード:

一覧性が欲しくなったら作らせ、開くたびにデータソースから再取得させて内容を最新にする

作らせる前に接続済みのデータソースを実際に叩いて応答を確認させると手戻りが減る

実データが揃わないパネルは、サンプルであることを画面上に明示する

形式は好みでよい:

表でも十分で、必要なときだけ出力させる形でも構わない

守るべきなのは原本が1つに保たれていることのほう

事実誤認の前提:

数字を出す成果物には別のエージェントによる検証工程を挟む

数えられる指標と、分布から推定するにとどまる指標は分けて扱わせる

完了率のような集計値とコンテキストスイッチが多いという読み取りは確度がまったく違う

同じレポートに並べるときは区別できる書き方をさせる

■ 13. まとめ

ツール選びをやめて原本の持ち方だけを決めたことで、入力形式にも出力形式にも縛られなくなった

入力欄がないせいで捨てていた情報を書けるようになり、管理単位への分割はAIが提案してくれる

原本は1つに限定してビューはすべて再生成物として扱い、不整合は異常終了で止める

平日朝に未完了だけを自動提示させ、更新は対話でまとめて指示し、自動実行に書き込みはさせない

登録番号を先頭に出しておくと、以降のやりとりが番号だけで済む

管理のための作業を減らしたかっただけだが、続けているうちに測れるものが増えたのは想定外の収穫

MEMO:

↓と近い運用だろうか？
【備忘録】AIで編集しやすいWBSの作り方 - 機能軸・工程軸で工数を集計するMarkdown表
これも結局ローカルのテキストファイルをマスタにしているようだが、DBに任せればよいのにという感想しかない
DBのスキーマには最低限、タスクのタイトル、内容、期限、ステータスのフィールドがあればよく、内容はフリーテキストでよい
このDBのに対する操作をMCPなりCLIなりで提供すればより堅牢な仕組みになる
ビューを毎回作り直すというコンセプトも自然に統合できる

(2026/08/25)

シングルバイナリなOLAP DBの次期版「DuckDB 2.0」プレビュー。クライアント／サーバ機能が安定版に...

シングルバイナリなOLAP DBの次期版「DuckDB 2.0」プレビュー。クライアント／サーバ機能が安定版に、スキーマレスのVARIANT型、トリガー、非同期I/Oなど新機能－ Publickey

要約:

■ 1. DuckDB 2.0プレビュー

2026年秋リリース予定:

DuckDBの開発を主導するDuckDB Foundationがブログ「A Preview of DuckDB v2.0」を公開

次期版DuckDB 2.0に搭載予定の新機能を紹介する内容

大型の新機能が相次いで投入:

別マシン上のDuckDBインスタンスに接続して操作するクライアント／サーバ対応

SQLパーサの全面刷新

JSON型の強化版ともいえるスキーマレスのVARIANT型

トリガー、非同期I/Oによる高速化

プレビュー版は「DuckDB Preview (Nightly) Installation – DuckDB」で公開

■ 2. DuckDBの基本的な特徴

シングルバイナリ実装:

SQLiteのようにシングルバイナリで実装されている

アプリケーションへの組み込みが容易で、ローカル環境にインストールして簡単に実行できる点が最大の特徴

幅広いデータソース対応:

単一ファイルとして扱える独自フォーマットのデータベースファイルに対応

MySQL、PostgreSQL、SQLiteデータベースの読み書きに対応

CSV、Parquet、JSON形式などのファイルの読み書きに対応

カラム型データベースエンジン:

大規模データに対して非常に高速に抽出や分析が可能

現在非常に注目されているデータベース

■ 3. クライアント／サーバ対応

Quackプロトコル:

2026年5月に登場したクライアント／サーバ対応のためのプロトコル

手もとのマシンのDuckDBから別マシンのDuckDBインスタンスに接続して操作できる

従来の位置づけからの拡張:

DuckDBはPC上で特定のアプリケーションに組み込まれて実行されるOLAPデータベースとして登場した

マスターデータベース構成:

サーバとなるDuckDBインスタンスは複数クライアントからの接続を受け取って処理できる

特定のインスタンスをマスターデータベースとし、多数のクライアントとなるDuckDBからアクセスして利用する構成が可能

■ 4. SQLパーサのPEGベース刷新

DuckSQLを維持しつつ全面刷新:

DuckDB独自のSQL方言であるDuckSQLは維持する

SQLパーサをPEG（Parsing Expression Grammar）ベースに全面刷新する

SQLパーサの役割:

SQL文をトークンに分解したあと解析を行う

文法が正しいか、指定されたテーブルなどが存在するかを確認する

DuckDB内部で実行可能な処理にするため、内部のAST（抽象構文木）に変換する仕組みを備える

従来のPostgreSQL由来パーサの課題:

DuckDBは登場以来、PostgreSQL由来のSQLパーサと文法を使用している

DuckDBの機能拡張に合わせて文法を拡張することが容易ではなかった

PEG採用の効果:

文法の拡張が容易になる

今後のDuckDBの進化がやりやすくなる

■ 5. VARIANT型

スキーマレスで効率的な新型:

スキーマレスで柔軟にデータを格納できるJSON型はDuckDB 1.5で採用された

DuckDB 2.0ではより強力なスキーマレス型のVARIANT型が採用される予定

JSON型との違い:

JSON型とは異なりテキスト形式で保存されない

半構造化データの中から隠された共通構造を自動的に検出して切り刻んで保存する

利点:

データが効率的に圧縮される

クエリも高速になる

■ 6. トリガー

自動実行される処理:

あらかじめ特定の処理を定義しておくと、データの追加や更新、削除などの発生時にその処理が自動的に行われる

用途:

特定のテーブルの内容に変更があった場合、それをログとして別テーブルに記録する処理が可能

データの整合性の確認や監査、追跡が容易になる

■ 7. 非同期I/O

従来の制約:

これまでもリードの並列処理は可能だった

その性能はDuckDB内の同期的な処理によって制約されていた

2.0での改善:

非同期I/O処理が実現し、クエリ処理とI/O処理が独立してスケールする

特にリモートファイルの読み取りの並列性が大幅に向上

ネットワーク越しに置かれたAmazon S3などクラウドのオブジェクトストレージの読み込みが非常に高速になる

(2026/08/25)

Stop Making TUIs

Stop Making TUIs — A Final Ward

要約:

■ 1. 生成したネイティブアプリ群

MDV.app:

他に本気のMarkdownビューアが現れるまで世界最高のMarkdownビューア

UIコードにはほとんど手を加えず、召喚した

良いUIを作る困難:

大半のUIと同様に新規性はなく、難問でもない

一方でコードは退屈で反復的かつ厳密さを要求され、プラットフォームの概念知識に依存する

習熟には何年もかかるため、この種のプログラムを手書きすることはない

SageMathフロントエンド:

Math AcademyでFoundations Iから機械学習まで進め、独学で微積分を修めた延長で作った電卓型SwiftUIアプリ

Sageの出力をLaTeXで自動描画し、多変数微積分が深まるほど有用になる

ベクトル、行列、式などのオブジェクトのメソッドをポイント&クリックで露出する

勾配を取るといった頻出操作を短く打てる「little language」を備え、[1,2;3,4] が行列になる

配布しない方針:

このアプリはパッケージ化しない

欲しければ該当箇所のスクリーンショットをClaudeに渡せば有用なものが出来上がる

DJ Roomba:

Apple Music用の自作プレーヤーで、ジャンルマップは怪しい機能

ライブラリ、最終再生リスト、次の曲を読むツールコールを持つLLMエージェントを組み込んだ

地下の工作場で額縁を作る気分に合うノースキップのプレイリストを頼むと、Kurt VileとTom Pettyが大量に並び文句なしだった

まともなスキーマのSQLiteをバックエンドに据えたことも驚くほど有用な特徴だった

開発か設定かという疑問:

Music.appの90%のインターフェースを備えたAI支援音楽プレーヤーであり、宿敵に対する龍退治に等しい

それでいて一行もコードを書いていないため、ソフトウェアを開発しているのか、単に自分のコンピュータを設定しているだけなのか判然としない

Self Driving Wiki.app:

素材を与えて質問すると自らwikiを書く自走式wikiは非常に有用な発想

Responses APIクライアントを直接埋め込むDJ Roombaと違い、内部で claude -p を駆動する

エージェントは漁れるファイルシステムがあるほうが働くと考え、macOSの仮想ファイルシステム拡張を召喚した

拡張はSQLiteの読み取り専用ビューをサンドボックス内のマウント済みファイルシステムとして反映する

不要でインストールを面倒にした可能性はあるが、この種のヤクシェービングはLLM以前の開発の喜びであり、今も味わえるのは嬉しい

食事マクロトラッカー:

GPT5を前面に置いた単純なエージェントで、半自動的に栄養を記録する

ケーキの生地とクリームチーズのフロスティングを味見したといった短い記述を摂取量の推定に翻訳する

温度監視メニューバーアプリ:

安価なTP-Linkの温度センサーで家中の温度を追う

通常なら通信プロトコルやHTTP APIを語れるところだが、その調査を一切していないため、クラウド経由と各センサー直結の二つのサインイン経路がある程度しか言えない

Apple TVリモート:

メニューバーで動く汎用リモコンで、macOSネイティブ開発の聖杯にあたる

Apple TVとの直接通信は厄介だが、既に解決してPythonライブラリを書いた人々がいる

ネイティブSwiftアプリなのでそのライブラリを使いはしないが、Pythonで書かれた実装はSwiftでもC#でもBrainfuckでも同じことであり、フロンティアモデルには区別がない

生成UIの品質:

生成したSwiftUIの見た目に対する容赦ない批評は歓迎する

App Storeの長年の利用者として、これらのデザインはいずれも代替水準より一歩先だと主張する

5年前にmacOSのUI担当者がこの品質を出してくれたなら大喜びしていた

アプリではなく成果物:

配布する意図がないため、これらを「アプリ」とはほとんど考えていない

コンピュータに自分のやり方で仕事をさせるための成果物にすぎない

Unixナードとしてコマンドラインの言語で常にできていたことが、今やグラフィカルインターフェースでも同じ手軽さでできる

■ 2. CLIとTUIの区別

TUIを作る理由:

我々がターミナルインターフェースを作るのは、そうすべきだからではなく、そうせざるを得ないから

両者の出自:

CLIもTUIも1970年代の産物で、テレタイプとダム端末の制約に合わせて成形された

どちらもGUIに比べて時代遅れかつ敵対的で制約が多い傾向を持つ

傾向の帰属先:

これらの傾向はTUIに内在するものであり、CLIに内在するものではない

CLIには代替不能な用途があり、CLIを作るのはほぼ常に良い判断

TUIを作るのはほぼ常に良くない判断

Stephensonの神話:

1999年の「In The Beginning Was The Command Line」はHCIの分野を20年後退させた

CLIを操るUnixナードの聖職者集団を、産業全体を背負う強力なモーロックとして描き、EloiはWordのようなGUIを使うとした

極上のファンサービスゆえに分野の聖典となったが、25年後に成立している部分はごくわずか

TUI存在の実際の理由:

機械と操作者の間に特別な機械共感が生まれるからではない

存在理由はモデムと、UnixナードがMotifを学びたがらなかったことの二つだけ

Motifとcurses:

1990年代半ばのわずかなMotif作業のせいでその後29年UI開発から遠ざかったので、彼らを責められない

cursesも大したものではないが5分で習得できる

今どき生のcursesを選びはしないが、概念説明を省いてpicoを書く最低限を尋ねれば、返ってきたコードはそのままコンパイルでき、次の一手も明確

■ 3. TUIの技術的劣位

ネイティブの安定性:

エージェントはAppleの指示どおりにSwiftUIを使うことで、妥当なネイティブmacOS UIを確実に構築できる

ネイティブアプリは他のネイティブアプリに似ているべきであり、web UIと違って同一性は美点

ターミナルとの戦い:

Ratatui、Textual、Bubbleteaのような良いフレームワークを使っても、ネイティブが標準で備える水準に漸近的に近づくためターミナルと戦う羽目になる

スクロールとスクロールターゲット、ドラッグ&ドロップが典型例

ウィンドウ枠をインバンド信号で描くためテキスト選択が厄介になる

複数のフローティングウィンドウも難しく、画像処理はそれ以前の話

ウィジェットの限界:

日付ピッカー、秘匿テキストフィールド、プログレスバー、テキストエディタは1時間でそこそこ作れる

しかし多くはシステム版に劣り、さらに手を掛けなければ組み合わせも効かない

これらはすべてネイティブUIでは箱を開けた時点で動く

■ 4. TUI擁護論への反駁

情報密度と速度:

TUIが経済的で高速、高情報密度なのは事実で、ナードはレトロな美学だけを愛しているのではない

ただし説得力を持たせるには「TUIだけが」と書く必要があり、そう書けば嘘になる

GUIが密でない理由:

GUIが経済的でも高密度でもキーボード中心でもない傾向は、ナード向けに設計されていないことに由来する

Linuxですら神話的な一般デスクトップ利用者を目標に設計されがち

密で経済的なGUIの設計を妨げるものは何もなく、実例も存在する

グラフィカル側への含意:

TUIの美点はむしろグラフィカルな仕事を増やす強い論拠になる

実験が容易で安価になった今、MagitやLazygitの良さをすべて捉えたネイティブUIを、自分で作らずに見たい

SSH越しの利用:

本番にユーザーインターフェースは恐らく必要なく、必要なのは手元のMacBookのUIから駆動できるCLI

bpftraceでハッシュマークの棒グラフを3度も作れば骨身にしみるはず

先例としてEmacs TRAMPがあり、SSH接続を隠してリモートファイルにネイティブな編集体験を与え、LSPやMagitとも動く

アクセシビリティ:

TUIがアクセシブルという主張は恐らく偽

自分はアクセシビリティ機能の利用者ではないため、a11yに携わる人々の経験に依拠するほかない

スクリーンリーダーがTUIのクロームの行単位更新を、ハッシュマークやダッシュとして読み上げる様子は明らかに良くない

ネイティブ側の設計:

現代のネイティブUIフレームワークは当初からアクセシビリティを適切に扱うよう設計されている

SwiftUIは視覚的なツリーと意味的なアクセシビリティツリーの二本を保持する

正しく実装しようと努めるTUIフレームワークもあり立派だが、アクセシビリティはTUIをGUIより選ぶ理由にはならない

クロスプラットフォーム性:

TUIに対する唯一の強い論拠はクロスプラットフォーム性

エージェントにWindowsやLinux向けのネイティブUIを作らせても妥当なものになる確信はある

しかしそれらを試すデスクトップを持たず、vibe-codingとvibe-shippingの間には重要な区別が残る

自分が見も使いもしないアプリを出荷する者は間もなく現れるが、それは自分ではない

自分向けという前提:

TUIを作ればLinux利用者に同じ体験を届けられる確信は得られ、それは無価値ではない

ただし自分は他人のためではなく自分のために作っており、公開する気もないプログラムのためにTUIの制約を飲むのは代償が大きすぎる

時期の問題:

数年前ならこの議論は馬鹿げていた

TUIが良かったからではなく、ネイティブUIが現実的な要求ではなかったから

その証拠に我々は10年近くElectronアプリと暮らしてきた

ネイティブUIが難しかった時代は終わったので、もっとネイティブを作るべき

■ 5. 制作プロセス

前提:

語れるのはmacOS開発だけで、LinuxのGTK 4とWindowsのWinUI 3も同程度に容易だと仮定する

まともなネイティブmacOSアプリを作るのに大したものは要らない

採用したスキル:

macOSデザインのスキル、基本的なタイポグラフィのスキル、Paul HudsonのSwiftUIスキルを集めた

生成コードが慣用的かどうかを気にする性分が抜けないため、AirbnbのSwift言語スキルも加えた

computer-use:

computer-use、あるいはCodexでの相当機能を有効にしておくべき

指示を投げて昼食を作りに行き、戻れば快適にデバッグできる程度に動くアプリがある状態が望ましい

それはエージェントがアプリを見て操作できるときにこそうまく働く

Xcode回避:

最大の生活改善はXcodeを一度も開かずに済むこと

友人のJoshがMDVを自分でコンパイルしようとして作った純粋なMakefile駆動のビルド手順を、新規プロジェクトごとにClaudeで複製している

テンプレート方式:

テンプレートのアプリディレクトリを複製し、ClaudeかCodexを開いて作りたいものを伝える、それが全工程

自分のテンプレートが優れているとは思わず、より有能な誰かが真に良いSwiftUIの原型アプリを作るべき

TUIの場合:

同様の手順でTUIも作れ、エージェントにtmuxでTUIを検証させるとうまくいく

それでも自分が再びTUIを作りたくなるとは思えない

■ 6. 結論

呼びかけ:

TUIを葬りに来たのではなく、新しく作るのをやめてほしいと願っている

個人的な来歴:

もともとTUIが好きではなかった

1990年代はPineからElm、Muttと使ったが、やめてグラフィカルなメールリーダーに移れる瞬間に移った

この文章全体を個人的な好みの皮肉な表明として読むこともでき、それは自分の柄に合っている

境界の消失:

重要なのはターミナルインターフェースの好き嫌いではない

数十年にわたるフロントエンドとバックエンド、さらにwebとネイティブという区分を、エージェントがほぼ溶かした

何を作るにもネイティブUIを既定にでき、その出来もそれなりに良い

再調整の勧め:

ユーザーインターフェースコードを書かないシステムプログラマだと数十年思ってきた人、あるいはASCII文字でウィンドウを描くのが自分の持ち場だと考えてきた人は、認識を改める時期

UIに関心がない、あるいは1970年代的な美学を好んで良いUIを厭うのは別の話であり、Enlightenmentを走らせていた身としてそれを咎めはしない

NetNewsWire、Transmit、Little Snitch、Audio Hijackのようなインターフェースを愛でる隠れEloi気質のUnixモーロックなら耳を貸すべき

500個ある使い捨てCLIの一つをネイティブアプリに仕立てたことがないなら、自分を損なっている

ネイティブUIを作れば、恐らく物の考え方が変わる

(2026/08/24)

大阪大学とNEC、次世代データ転送基盤「RED-ONION」を構築--1TBを約90秒で転送

大阪大学とNEC、次世代データ転送基盤「RED-ONION」を構築--1TBを約90秒で転送 - ZDNET Japan

要約:

■ 1. RED-ONIONの構築

次世代データ転送基盤の共同構築:

大阪大学D3センター、同大学産業科学研究所、NECの3者による共同構築

ゲノムや医療データなど厳格な管理が求められる機微データを対象とする

機微データを安全かつ超高速に転送する基盤として「RED-ONION（レッド・オニオン）」を位置づける

2026年10月からの試験運用:

大阪大学吹田キャンパス内で試験運用を開始する

実験設備とスパコンの直結:

研究現場の実験設備とスーパーコンピューターを直結する

日本の学術研究における「AI for Science」を強力に推進する

■ 2. 背景にある課題

研究データ量の爆発的増加:

実験装置や計測機器の進化、AI技術の発展が背景にある

実験室と計算システムの分断:

大容量データを日々生成する実験室と、分析やシミュレーションを担う高性能計算システムが物理的、組織的に離れて設置される

多くの大学や研究機関で同様の状況が生じている

研究開発上のボトルネック:

機密性の高い大容量データを迅速かつ安全に移動させ、計算資源と連携させることが大きな障壁となっていた

■ 3. 技術構成と性能

100Gbps級の専用光ファイバー接続:

産業科学研究所とD3センターを専用光ファイバーネットワークで接続する

専用エンジンによる一括制御と並列実行:

ネットワークやサーバー内のデータ処理を専用エンジンで一括制御する

処理を並列実行することでディスク間の大容量データ転送を劇的に高速化する

1TBを約90秒で転送:

1TBの研究データを約90秒で転送できる見込みである

■ 4. 研究フローへの効果

機微データの即時収容:

産業科学研究所で生成された機微データを即座に安全に収容する

収容先はD3センター内のスーパーコンピューター「SQUID」「OCTOPUS」、クラウド基盤「mdxII」など

双方向連携のシームレス化:

高性能な計算システム上でAI処理やシミュレーション解析を瞬時に実行する

解析結果を再び研究所へ送り返す双方向の連携が実現する

■ 5. 今後の展開

運用範囲の順次確定:

10月からの試験運用を通じて、対象となるデータ種別や運用範囲を順次確定させる

インフラ拡張の展望:

将来的には大阪大学内の他部局や、ほかの研究機関へのインフラ拡張を見据える

NECによるソリューション化:

共同開発で培った超高速データ転送技術を「NEC Ultra-high-speed Data Transfer System（NEC UDTS）」として独自ソリューションに昇華させる

価値創造モデル「BluStellar」の枠組みの中で、国内外の大学、研究機関へ広く社会実装する方針である

(2026/08/24)

Why type script 7.0 was rewritten in go (and what it means for your dev stack)

Why type script 7.0 was rewritten in go (and what it means for your dev stack) | spf13

要約:

■ 1. TypeScriptコンパイラのGo移植

TypeScript 7.0のGo書き換え:

TypeScriptを生んだチームが過去1年でコンパイラとツール群をGoへ移植した

RustでもC++でもなくGoを選択した

Microsoftの数値ではビルド時間がおよそ一桁改善する

AI支援開発の時代に、世界最大級のJavaScript/TypeScript組織が旗艦ツールにGoを選んだ

Microsoftが挙げた実務的理由:

既存コンパイラの関数中心のスタイルがGoへほぼ一対一で移植できた (Anders Hejlsbergの説明)

新旧いずれのコンパイラもガベージコレクションに依存する

10倍の高速化はネイティブコードと共有メモリ並行性に由来する

発表にAIへの言及は一度もない:

一対一の移植を可能にした性質は、単純な関数、隠れた魔法の不在、GC、チームが把握しきれるコード

それらは次の時代の開発が要求する性質と同一

■ 2. 読み手最適化という賭け

Goの設計思想: 書き手ではなく読み手に最適化し、誤読されうるコード量を減らす

LLMはいかなる人間よりも大量にコードを読み、LLMが書く割合が増えるほど人間も読み手側へ寄る

エージェント開発は、可読性・保守性・長期的な正しさというGoの目標に対する最も極端な試験

■ 3. PythonとTypeScriptの位置づけ

表面上は強力な通説:

PythonにはPyTorch、LangChain、機械学習エコシステムがある

TypeScriptにはWebと膨大な開発者人口がある

LLMは両言語を大量に学習しており、流暢かつ自信を持って高速に書く

スクリプト言語としての出自:

PythonとJavaScriptは書きやすさ、寛容さ、動的性を狙って設計された

TypeScriptは構造を後付けするコンパイル時の被膜にすぎない

型は実行時に消去され、TypeScriptの保証は実行時に一切残らない

TypeScriptはJavaScriptを置換していない:

GitHubのOctoverse 2025では月間コントリビュータ数でTypeScriptがPythonとJavaScriptを上回った

同じ12か月で新規リポジトリ生成数はJavaScriptがほぼ倍

GitHub自身の総括は率直で、JavaScriptは依然として巨大

JavaScript/TypeScript全体の活動量はPython単独を上回る

エージェントシステムはスクリプトではない:

実体はサービス、パイプライン、CLI、長年本番稼働する分散システム

3言語はいずれも複雑性管理、依存分離、デプロイ、実行時安全性の各段階で設計と衝突する

■ 4. Goが担う領域

Goは大規模で長寿命なソフトウェア向けのシステム言語として設計された

業界はまさにその領域、すなわちコンパイル型で安全、一晩の走り書きではなく数年動くソフトウェアへ収束している

TypeScript界隈で最も注目すべき出来事はGoへの移植そのもの

Python界隈の重要な進展はRustで起きている:

Pydanticの検証コア、Polars、HuggingFace tokenizers、AstralのuvはいずれもRust製

Goはエージェント基盤の既定の選択:

ローカルモデル実行の標準であるOllama

無数のRAGとエージェント記憶を支えるベクトルデータベースWeaviate

長時間のエージェントワークフローを統括する耐久実行エンジンTemporal

Google Antigravityと同カテゴリのAIコーディングCLIであるCharmのCrush

AIエージェントとGitHubを接続する参照実装であるGitHub公式のMCPサーバ

問うべきは書きやすさではなく、書き、レビューし、出荷する容易さの総和

エージェント開発はその問いを1日に数百回、機械に問わせる

■ 5. エージェントループによる弱点の増幅

ループの構造: 実装 → ビルド → テスト → 失敗分析 → 自己修正 → 反復

頻度の差: 人間は1時間に十数回、自律エージェントは1タスクあたり数十回回す

Anthropicのコーディングエージェント指針は、テスト結果をフィードバックとして解を反復する系だと説明する

反復頻度の増大が言語選択の経済性そのものを変える

Wes McKinneyのエージェント人間工学:

エージェントがコードを書く時代には、高速なコンパイルとテストのループ、摩擦のない配布、決定的ビルドが重要

人間にとって書き心地がよいかどうかの重要度は相対的に下がる

彼のAIエージェント向け常駐コードレビューツールRoborevはGo製

4つの問題が順に積み重なる:

遅いビルドは反復を浪費する

壊れた依存解決は実行全体を無駄にする

弱いエラーフィードバックは誤りをその実行の先まで生き残らせる

エコシステムの変化は、着手前の時点でエージェントの知識を無効化する

いずれも同じ通貨で支払われる: 開発者の時間と集中、エージェントの反復回数、言語が見逃した誤りの修正に費やすAPI費用

■ 6. ビルド時間

大規模なRustやC++では数分のビルドが日常であり、人間には小休止でもエージェントには大損失

1機能に50回反復するエージェントにとって、数分のビルドは数時間の浪費

Goはほぼ即座にコンパイルし、ループを短く保つ

■ 7. 依存管理

Pythonの課題:

pipは既定で決定的なインストールを保証しない

仮想環境を使ってもマシン間のバージョン衝突は依然として頻発する

npmの実情:

入れ子のnode_modulesが同一パッケージの複数バージョンを併存でき、推移的依存の衝突はむしろうまく扱える

package-lock.jsonとnpm ciにより再現性は以前より大きく改善した

詰まるのはpeer dependenciesで、要求の衝突はERESOLVEエラーとなり手作業の解きほぐしを要する

バージョンの柔軟性の代償として依存ツリーが深く重複し、エージェントが把握すべき面積が膨張する

両エコシステムはsetup.pyやpostinstallでインストール時に任意コードを実行でき、実害の出た供給網リスクを抱える

Goの既定動作:

go.sumが正確なチェックサムを固定する

ビルド全体で各モジュールの単一バージョンが決定的に選択される

インストール時のコード実行フックがなく、侵害された依存が悪用する足がかりが存在しない

継続的に生成しデプロイするエージェントにとって、バージョン漂流と攻撃面が縮小する

■ 8. エラーフィードバック

型検査自体は実効性を持つ:

mypy、pyright、tscをループに組み込めば、Pythonの型ヒントもTypeScriptの型も実際の誤りを実行前に捕まえる

ただし双方に但し書きがつく:

Pythonの型付けは任意のままで採用も不均一、Pydanticのようなツールが後押ししてもなお同様

TypeScriptの保証は実行時に消去され、anyが公認かつ無コストの脱出口として常に開いている

時間とトークンの圧力下のエージェントは、その場のコストがゼロであるanyへ手を伸ばす誘因に従う

Jesse Vincentの観察 (エージェント統括フレームワークSuperpowersの開発者):

抜け道が存在するとエージェントは規則を回避する理屈を自ら組み立てる

彼の環境ではAIエージェントが、失敗するテストを消すためにテストファイルを削除した

存在しないテストは失敗しないという、内部的には一貫した論理

ルールには「これが終わったらやる」といった自己正当化の抜け道があるが、ゲートは条件充足まで次の行動を阻む

Goには同種の抜け道がない:

Goにもanyはあるがinterface{}の別名であり、TypeScriptのanyとは別物

TypeScriptのanyは触れた対象すべての検査を止める

Goのanyは使用箇所ごとに検査され、型が支持しない操作は検証済みの明示的アサーションなしに拒否される

脱出口それ自体がゲートされている

誤りが表面化する時点が異なる:

PythonやTypeScriptでは実行時に表面化し、多くはエージェントがその上に作業を積み上げた後になる

その時点ではコンテキストとAPI呼び出しの複利が乗っている

Goでは同じ誤りがコンパイル時に即座に捕捉され、エージェントが何かを実行する前に止まる

コード例が示す差:

Goではinterface{}型の引数に1を加えると、型の不一致としてコンパイル時にエラーになる

Pythonの同等の関数定義は何のエラーも出さず、辞書を渡した実行時に初めてTypeErrorとなる

Python側ではエージェントが実行し、その上に作業を積んだ後で誤りが露見する

寛容さはここでは不利:

言語が寛容なほど、エージェントは捕捉されるまでに多くの誤りを犯し、コンテキストとAPI費用を焼く

レビュー側にも同じ差が出る:

双方がAIになった今、PythonやJavaScriptはコードが何と書いてあるかは読めても何をするかは確実には読めない

メタクラスやプロトタイプチェーンが、静的読解では捉えられない挙動を隠す

Goは関数名が一つの意味を持ち、メソッド解決は名前のみで決まり、隠れた制御フローがない

Goの型は上に載せた層ではなく言語そのものであり、構造上コードの100%を覆う

■ 9. エコシステムの変化

4つの問題のうち最大のもの

Goの互換性の約束: 2012年のGo 1.0向けに書かれたコードは今日も正しくコンパイルされ動作する

言語と標準ライブラリは追加のみを行い、既に動いていたものを壊すことは実質ない

Nodeエコシステムに同等の保証はない:

Svelte 5のrunesはSvelte 4とは異なるリアクティビティモデル

Vue 3はVue 2のリアクティビティモデルを一から書き直すことを要求した

Reactはクラスコンポーネント、hooks、サーバコンポーネントと、非互換な複数の時代が現役で並存する

SvelteやVueのどのバージョン向けかを問うことは、そのコードが動くかどうかを問うことと同義

Pythonも例外ではなく、10年に及んだPython 2から3への移行は自らの教訓

それでもNodeの変化はより速く、より恒常的

■ 10. エージェント知識の陳腐化

エコシステムの変化はエージェントにとって固有かつ複利的な問題

エージェントの実務知識は訓練時点で凍結したスナップショット

変化の速いエコシステムではその知識が陳腐化し、もっともらしく見えて改廃済みのAPI面を狙うコードを生む

Goでは数年前のスナップショットが今日も正しい

結果として、エージェントは毎回前提を再検証せず、既知の知識に依拠して作業できる

■ 11. 誤りの大量生産という危険

Dave Rensin (Google Distinguished Engineer) の指摘:

AIエージェントで10万ユーザー規模の社内ツールを構築した経験に基づく

注意を怠れば、単に速くコードを書いているのではなく、誤りを大量生産していることになる

この危険はGo固有ではなく、あらゆる言語でのAI支援開発に共通する一般的リスク

静的型、明示的なimport、魔法の不在というGoの構造は、その危険に対する組み込みの摩擦

悪いコードがそもそも書きにくいという形で効く

■ 12. PayPalにおけるC++からGoへの移行

自社製C++データベースは強力かつ正しかったが、チームは成長を止めていた

新規採用者はコードベースの習得に数か月を要し、エンジニアリング能力の大半が保守に費やされた

約半年後、およそ10人のエンジニアによるGo書き直しが本番でC++システムを上回り、保守コストも大幅に下がった

GoはC++より速い言語ではないため、ボトルネックはコードの速度ではなかった

真の制約は、チームがそのコードを理解し、保守し、拡張する能力

実現された性能が理論上の性能に勝るという取引であり、エージェント時代のチームは同じ取引をより短い周期で行っている

■ 13. Rustの位置づけ

RustとGoは補完的で通常は異なる用途を占め、双方にエージェント開発での居場所がある

ただしRustは既定ではなく専用の道具

Rustが共有する強み: メモリ安全性、静的型付け、隠れた実行時の魔法の不在

Rustのコンパイラエラーは教育的で有名:

コンパイラをゲートと見なす本稿の論理に照らせば、詳細な借用チェッカのメッセージはエージェントに実利をもたらす

分岐点はエージェント開発が最も許容しない箇所に現れる:

コンパイル時間が大幅に長く、前述のビルド時間の問題が直撃する

ライフタイム、トレイト境界、借用チェッカという安全性の裏の表現力が、Goが設計上保証する明白な一つの方法という可読性を損なう

代償が最も強く出るのはリファクタ時:

Goでは局所に収まる変更が、Rustではライフタイムとトレイト境界に波及する

リファクタ容易性こそエージェント開発が最も強く依存する性質

その作り直しを担うのは人間ではなくエージェントであり、エージェントは正解に至るまでに遥かに多くの作り直しを要する

言語が複雑なほどエージェントは誤読し、反復のたびに複利で膨らむバグを生む

埋め込み用途ではRustが優位:

PyO3やmaturinによるゼロコストのC ABIバインディングで、Pythonパッケージの下にコンパイル済みRustコアを容易に置ける

pydantic、Polars、HuggingFace tokenizersがRustを選んだ理由

Goはcgoが実オーバーヘッドを伴うため歴史的に不利

Go 1.26はcgo呼び出しの基礎オーバーヘッドを約30%削減したが、依然として多くの用途でRustが優る

エージェント開発における結論:

Goの単純さと可読性が、エージェントが走るシステム層の既定

Rustは保証が代償に見合う場合の専用の道具

■ 14. コンテキストウィンドウの希少性

前述の各コストは反復回数に掛け算されるが、コンテキストはエージェント作業の恒常的コスト

コンテキストは多ければよいというものではない

Chromaの2025年の研究:

GPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む主要18モデルを対象とした

タスク難度を固定し入力長のみを変化させて検証した

入力が伸びるほど性能は劣化し、自明なタスクでも同様に劣化した

モデルが200Kや1Mのトークンを一様に扱って推論するという前提は誤り

最大の要因はdistractor:

モデルが必要とする内容と話題的に近いが答えではない情報を指す

1個でも精度を計測可能なほど下げ、4個になると被害が累積する

取るべき対策はウィンドウを広げることではなく入力を減らすことであり、その方が優れかつ経済的

動的な構造がdistractorを量産する:

クラス階層、mixinチェーン、デコレータの積層は、バグを追うエージェントにとってdistractorの群れ

ダイヤモンド継承を経由するsuper()呼び出し、実行時に挙動を書き換えるメタクラス、3階層上に埋もれたオーバーライド

いずれも必要な論理ではないが、読み込み、比較、除外の手間は同じウィンドウ内で発生する

しかもその作業は、推論精度が既に劣化しつつある只中で行われる

継承したオーバーライドを無視したり、誤ったmixinのメソッドを呼ぶコードを自信満々に出す原因

Goの最小かつ明示的な設計:

ファイルが必要とするものは、そのファイルと直接のimportの中にある

継承チェーンも、6ディレクトリ先から引き込まれるmixinも、実行時にメソッド解決を書き換えるメタクラスもない

関数名は一つの意味を持ち、コンパイラがそれを強制する

Goのコードが必要とするトークンは、ほぼすべてが関連トークン

■ 15. 必要なモデル規模の低下

distractorの少ないコードは、タスクが要求するモデルの水準そのものを下げる

2万トークンの綺麗なコードに収まるバグは、15万トークンのフレームワークノイズに埋もれたバグほどの推論力を要さない

より小さく安価なモデル、ローカルモデルでも動作するGoコードを書ける

同じ課題のPython、Java、Rust、TypeScript/JavaScript版なら失敗する水準のモデルでも成立する

AI企業がコストの補助をやめる局面でこの差は一層効き、その動きは既に始まっている

控えめなモデルでも正しく扱える単純さを保つ言語は、補助の消滅を生き延びるコスト構造を持つ

同じ性質が二重に報いる:

小さなモデルが正しく書ける条件は、人間のレビュアーが素早く読める条件と同一

どちらの側にも、再導出すべき隠し事が残っていない

一発で正しく書ける確率が上がり、反復もAPI呼び出しもコンテキスト消費も減る

人間の介入なしにモデルが作業を続けられる時間が伸びる

コンテキスト効率は、2009年にGoが立てた賭け、すなわち人間か機械かを問わず書き手より読み手を優先する賭けの最も鋭い形

■ 16. 単一のフォーマット

gofmtはGoに同梱され、コミュニティのコード全体に対して実行される

人が書いたか機械が生成したか、数十年前か今朝エージェントが書いたかを問わず、すべてのGoファイルは構造的に同一に見える

Simon Willisonの所感 (AI支援のGoツール構築に多くの時間を費やしてきた立場):

一般に物事のやり方は明白な一つであり、結果として退屈で読みやすいコードになる点を楽しんでいる

そうしたコードはLLMが非常に得意とする種類のもの

事前のシード付けが可能になる:

encoding/json、net/http、ioといった標準ライブラリを指すだけで、慣用的で本番品質のコードを即座に出す

blackかyapfか、isortかruffかを推測する必要がない

go-skillsのような仕組みを入れれば、散在する例からの推測ではなく明示的で再利用可能な指針を直接与えられる

人間かAIかを問わず、レビューの注意はフォーマットの雑音ではなく論理へ全面的に向かう

■ 17. SDLC全体の最適化

多くの言語比較は執筆速度のみに注目するが、ライフサイクルはビルド、テスト、デプロイ、デバッグ、保守と続く

エージェントのワークフローでは、その全工程が機械の頻度で回る

Goのエコシステムはこの10年で言語から完全なSDLCプラットフォームへ発展した:

ファジングが標準搭載になった

govulncheckにより脆弱性管理が成熟した

workspaceモードがモノレポ開発を統合した

モジュールプロキシがバージョン衝突を減らした

いずれもGoエコシステムの外へ出る必要がない

各工程の具体的な利点:

依存はgo mod tidyが扱い、ラップトップ、CI、コンテナで決定的かつ同一の結果になる

pipやnpmでは解決の失敗がそのまま反復1回の損失になる

テストはgo test ./...だけで済み、フレームワークの選定もフィクスチャの設定も不要

パッケージの隣に_test.goを置き、Testで始まる関数を書き、コマンド1つで実行する

テスト駆動を強制するエージェントにとって、この信頼性はPythonのフィクスチャ乱立にはないゲートの決定性を与える

精密な依存グラフによりコンパイルは高速に保たれ、反復スループットに直接効く

デプロイはgo buildのみで、実行時依存ゼロの自己完結バイナリが1つできる

インタプリタのバージョン管理もコンテナ起動時間も不要で、バイナリをコピーして実行するだけ

これらの利点は線形に足されるのではなく複利で効く

サイクル各段階のループ高速化が、時間あたり反復数の増加、API費用の低下、結果の信頼性向上をもたらす

■ 18. 単一言語の勝利ではない

本稿の主眼はPythonやTypeScriptの置き換えではない

スタックの全層を単一言語に賭けることは、どの言語が勝っても同じ誤り

問いはより狭い: エージェントのワークフローが走るシステム、サービス、インフラの層にどの言語が最も適合するか

2026年時点ではGoである場合が多く、その層への適合が際立って高いことがその理由

PythonのMLエコシステム (PyTorch、LangChain、Transformers) は消えないし、消えるべきでもない

モデルの訓練と推論の実行についてはPythonが答えであり、Goはそこで競合せず補完する

■ 19. GoとPythonの共存

GoはPythonの隣に置くのと同じ容易さでPythonの下層に置ける

Simon Willisonのgo-to-wheel:

コンパイル済みGoバイナリをPython wheelとしてPyPIで配布する

任意のGoバイナリが標準のpip installまたはuvxのワンライナーになる

彼自身のGo製並行ファイルシステムスキャナsqlite-scannerがまさにその方式で配布されている

Armin Ronacher (Flask作者) による逆方向からの指摘:

MiniJinjaのRustからGoへの移植は45分と60ドルのAPI費用で済んだ

コーディングのコストが劇的に下がっており、エコシステムの広さの重要性は相対的に低下する

Pythonが統括し、Goが下層で実行する構成が成り立つ

移植コストが毎月安くなるほど、単一エコシステムを選ぶロックインの論拠は弱まる

Goの構造的優位とPythonのエコシステムは二者択一ではなく、両方を得られる

■ 20. Goを既定とする指針

Goは大規模なソフトウェアの総コストを下げるために設計された

エージェント開発はまさにその問題を破綻寸前まで増幅する

人間規模のチームに有効だったGoの性質はすべて、1日に数千回反復する機械にも同様に適合する

Goが唯一使うべき言語になるわけではない:

PythonはMLエコシステムを保持し続ける

課題に応じてRustやTypeScriptなどへ手を伸ばす正当な理由は実在する

唯一の支配的言語を求めるのではなく、システム・サービス・インフラ層の既定としてGoを据える

他を選ぶ際には固有の理由を要求する

新規のサービス、CLI、システムを始める際は「なぜGoではないのか」を問う

説得力ある理由を挙げられるならその主張を通す:

存在しない必須ライブラリがある場合

Goでは満たせない性能要件がある場合

移行コストが節減を上回るほどチームの投資が深い場合

理由を挙げられないなら、Goが正しい既定である可能性が非常に高い

ビルドの遅さ、不安定な依存、実行時の想定外に失われる数パーセントはすべてAPI費用

2026年にかけてエージェント作業負荷が拡大するなか、言語選択がそのコストへの単一で最大の梃子になりうる

摩擦を早期に取り除いたチームは、それを支払い続けるチームより安く速く反復する

(2026/08/24)

agenterr/agenterr -- セルフホストのエラートラッキングツール

GitHub - agenterr/agenterr: Self-hosted error and log tracking with an MCP server built in. One Go binary: OTLP and JSON ingest, issue grouping, search, REST API, minimal web UI. · GitHub

(2026/08/24)

Sentry 互換の GlitchTip を AI 開発のハーネスにする

Sentry 互換の GlitchTip を AI 開発のハーネスにする - Avoid a void

(2026/08/24)

複雑なドメインの知識をテストケースとして資産化する

複雑なドメインの知識をテストケースとして資産化する - エス・エム・エスエンジニアテックブログ

要約:

■ 1. 報酬算定エンジンと開発上の不安

報酬算定エンジンの役割:

介護報酬算定ロジックを組み込んだ仕組み

事業者が提供した介護サービスの内容をもとに、介護保険制度のルールに沿って金額を計算する

正確性の継続的な担保への不安:

介護報酬算定には多くの条件や例外があり、制度の理解そのものが簡単ではない

制度を正しく理解し、それを計算処理として実装する必要がある

さらにその計算結果が正しいことを確認する必要がある

デグレードへの懸念:

少しずつ機能を追加する過程では既存コードの修正も発生する

以前実装した計算が意図せず壊れることが最も怖い

検知が遅れると原因調査や修正に時間がかかり、新規実装に使える時間が減る

■ 2. QA観点の確認を自動化する理由

QA観点の確認の定義:

内部でどの処理が呼ばれたかではなく、この条件を入力したとき期待通りの算定結果が得られるかを確かめること

手動テストの限界:

人手がかかるため実行できるタイミングが限られる

大きな機能を実装したあとにまとめて確認する形になりがち

問題が見つかった時点で変更範囲が広く、どの変更が原因かの特定に時間がかかる

小さく実装して都度実行する状態:

早い段階で不具合を見つけられる状態にしたい

大きな節目だけに限定せず、日々の開発の中で繰り返し実行できるようにする

■ 3. 算定結果のテストという選択

入力から出力までを検証対象化:

個々の計算ロジックが正しいだけでは不十分

それらが組み合わさった結果として期待通りの出力を得られることが重要

内部のクラスや関数を直接呼び出す形にはしない

呼称の方針:

技術的には報酬算定エンジンへの入力から出力までを確認する結合テスト

テストの分類よりも何を確認するテストなのかが伝わるよう算定結果のテストと呼ぶ

リファクタリングのための足場:

新規開発の最中であり、新たな事実に応じて設計や実装を大きく見直したくなる場面がある

内部実装の細部に強く依存したテストだけでは大きなリファクタリングを進めづらい

単体テストも重要だが、内部構造を見直すたびに多くのテストを書き換える状態は避けたい

外側の振る舞いを守れば、内部実装を変更しても振る舞いが変わっていないことを確認できる

■ 4. 専門知識をテストケース化する流れ

関係者全員での制度理解:

テストケース自体はQA担当者が作成する

QA担当者だけが制度を読み解くのではなく、エンジニア、QA、POなど関係者全員での理解から始める

制度の整理と図示:

制度の文章をそのまま実装やテストに落とし込むことは難しい

制度の内容を読み解き、計算処理としてどのように表現できるかを整理する

処理の流れや条件分岐を図に起こし、チーム全体で認識を合わせる

共通理解からの分岐:

同じ理解をもとにエンジニアが実装を進め、QA担当者がテストケースを作成する

エンジニアとQAが別々の前提で作業してしまうことを避けられる

■ 5. QA担当者が扱いやすい形式

コードで書かせない判断:

QA担当者は制度や業務観点に詳しい一方、技術スタックに精通しているとは限らない

コードで書く形にすると、追加や修正のたびにエンジニアの手を介する必要が出る

Googleスプレッドシートの採用:

QA担当者が普段の業務の延長で扱いやすい

内部実装やテストフレームワークを詳しく知らなくてもテストケースを作成できる

実務様式を参考にした設計:

サービス提供票別表やその他様式2などの様式を参考にして形式を設計した

専門知識を持つ人がテストケースを直感的に理解できるようにするため

機械的に扱いやすい形式だけを優先すると、作成する人にとって読みにくくなる

入口の単純さの優先:

作成されたテストケースはCSVとしてエクスポートし、実行時に読み込んで入力に変換する

変換処理自体は地道な実装になったが、QA担当者が扱う入口をシンプルに保つことを優先した

■ 6. CIによる実行の仕組み化

手動エクスポートの回避:

毎回手作業でCSVにエクスポートする運用は実行前のひと手間が増える

エクスポート漏れや古いCSVを使ってしまう可能性もある

GitHub Actions上のワークフロー:

対象のスプレッドシートをCSVとしてエクスポートする

そのCSVをGitにコミットしたうえで算定結果のテストを実行する

workflow_dispatchによる手動実行:

QA担当者自身が任意のタイミングで実行できる

テストケースを作成したタイミングを起点に、最新のテストケースで検証できる

QA観点の確認をエンジニアだけに閉じない形にできた

■ 7. 導入して良かったこと

知見の資産化:

QA担当者が作成したテストケースを蓄積している

現在の仕様だけでなく、過去の制度に基づく計算もテストとして残せる

過去の計算ルールの保護:

報酬改定によって計算ルールが変わる

過去に提供した介護サービス分は改定前のルールに基づく計算が必要になる場面がある

法改正で現在の計算ロジックが変わっても、過去分の計算が壊れていないかを繰り返し確認できる

報酬改定時の安心感:

報酬改定では新しいルールの追加だけでなく既存の処理にも手を入れる必要がある

修正対象ではない計算まで意図せず変えてしまうことが怖い

変更による想定外の影響を早い段階で検知できる

修正内容が誤っていれば過去のテストが落ちるため、本番環境で不具合を出す前に気づける

小さな検知の積み重ね:

大きな障害を防いだという派手なエピソードがあるわけではない

大きな問題が起きていないこと自体が、この仕組みが効果を発揮していることの表れかもしれない

■ 8. 難しかったこと

古い形式のテストケースへの対応:

開発が進むにつれ機能が増え、入力値や出力値も増えていく

過去のテストケースはその時点の入力値・出力値を前提にしている

変換処理側に形式ごとの差分を吸収する分岐を持たせて対応している

コード管理の煩雑化:

入力値や出力値が増えるたびに変換処理側で考慮することが増える

テストケースを資産として残すほど、過去のフォーマットとの互換性の扱いが課題になる

それでも上回る価値:

QA担当者の知見を長く使える資産として残せる

報酬改定やリファクタリング時に想定外の変更を検知できる

■ 9. まとめ

取り組みの要点:

専門知識を持つ人がテストケースを作りやすい入口を用意する

その知見を繰り返し実行できる形にする

仕組みの全体像:

Googleスプレッドシートで作成したテストケースをCSVとして取り込む

報酬算定エンジンへの入力に変換して算定結果のテストとして実行する

CIによってQA担当者を起点に最新のテストケースで検証できるようにする

複雑なドメイン開発における重要性:

エンジニアだけで正しさを判断しきれない場面がある

専門知識を持つ人の知見をテストに落とし込み、継続的に実行できる形にすることが重要

(2026/08/24)

決めること、演じること、続けること

決めること、演じること、続けること - Konifar's ZATSU

(2026/08/24)

人月で稼ぐSIerは、あと数年で詰む

人月で稼ぐSIerは、あと数年で詰む

要約:

■ 1. 本記事の主題と結論

本記事のテーマ:

自律型AIエージェントの普及によってSIerのビジネスモデルがどう変わるのかを考える

生き残るために何を獲得し、何を捨てるべきなのかを考える

結論:

SIerの価値は「ソフトウェアを作ること」から「AIを活用して顧客企業を変革し、その成果とリスクに責任を持つこと」へ移る

■ 2. 「SaaSの死」が示したもの

2026年2月の市場変動:

SaaS関連銘柄から48時間で約2,850億ドルの時価総額が消えた

引き金は自律型AIエージェントが複数ステップからなる業務ワークフローを最後まで完遂できると広く実証されたこと

この動きは「SaaSの死」として大きく報じられた

SaaS自体は消滅しない:

SaaSは単なる人間が操作する画面ではない

業務データが蓄積され、企業の業務を支える基盤として長年運用されてきた資産がある

AIエージェントがSaaSを操作できるようになっても、これらの役割までなくなるわけではない

変わるのは使い方:

変わるのはSaaSそのものではなく、SaaSを誰が、どのように使うのかという部分

これまでのSaaSは人間が画面を操作して業務を進めることを前提に発展してきた

これからのSaaSは人間だけでなくAIエージェントが利用することも前提に設計する必要がある

揺らぐ常識:

揺らいでいるのはSaaS自体の存在ではなく、「ソフトウェアは人間が操作するもの」というこれまでの常識

AIは利用と開発の両工程に浸透:

すでにシステム開発の工程にもAIが組み込まれている

AIエージェントによる業務実行の自動化と同時に、業務を支えるシステムの開発もAIによって大きく効率化されている

利用する工程の変化は、人間が操作することを前提としてきたビジネスに影響を与える

開発する工程の変化は、ソフトウェアは人間が作るものを前提としてきたビジネス全体に影響を与える

■ 3. 人月モデルの構造的限界

人月という収益モデル:

SIerは顧客から要件を受け、必要な人数と期間を見積もり、その工数を人月として売ってきた

10人月の仕事なら10人月分の売上になる

AIによる前提の崩壊:

AIによって1人あたりの生産性が大きく向上すると、この前提が崩れ始める

同じ成果をより少ない人月で実現できるケースもある

同じ10人月でこれまで以上の量や品質を求められるケースもある

AIの利用自体にもコストがかかる

本質は工数と成果の関係変化:

重要なのは単純に「10人月の仕事が3人月になる」ということではない

AIによって投入した人月と生み出される成果の関係が大きく変わることが本質

同じ10人月でもAIを使いこなすチームとそうでないチームでは、生み出せる成果に大きな差が生まれる

尺度としての機能低下:

「何人が、何ヶ月働いたか」は仕事の価値を測る尺度として徐々に機能しにくくなる

ここに人月ビジネスの構造的な限界がある

■ 4. AI化はチャンスであり分岐点

顧客企業のAI化は段階的:

既存の基幹システムやSaaS、業務データ、セキュリティ要件、法規制、社内ルールがすぐになくなるわけではない

既存の環境にAIを組み込みながら、段階的に業務を変えていくことになる

新たに問われる論点:

どの業務をAI化するのか

既存システムとAIをどう連携するのか

どこまでAIに任せ、どこに人間の判断を残すのか

AIを安全に運用するには何が必要なのか

新しい仕事の発生:

こうした問題を整理し、業務とシステムの両方を設計することがこれからのSIerに求められる

AIによって開発案件が減ることだけを恐れる必要はない

「作る仕事」が減る一方で「AIを前提に業務とシステムを作り変える仕事」が生まれる

問われるのは減っていく工数をどう守るかではなく、AIによって生まれる新しい価値をどう事業に変えるか

■ 5. SIerの提供価値の変化

価値の移動:

AIによって実装コストが下がれば、作ること自体では差がつきにくくなる

何をAI化するかを決め、既存システムと組み合わせ、安全に運用し、業務成果につなげる仕事の重要性が高まる

提供価値は「作って納める」から「業務を変え、動かし続ける」ことへ移る

これまでとこれからの対比:

収益は人月・受託開発から成果連動・継続サービスへ変わる

開発は実装工数そのものが価値である状態から、AIで実装を効率化し設計や成果へ価値を移す状態へ変わる

設計はシステム単位の設計から、AIを前提とした業務全体の設計へ変わる

運用は納品後の保守から、AIの監視・改善・統制へ変わる

顧客との関係は納品を一区切りとする形から、継続的に改善へ伴走する形へ変わる

1. 人月ではなく成果で稼ぐ:

投入した工数と生み出される成果の関係は、これまで以上に不均一になる

労働量だけでは仕事の価値を測りにくくなり、顧客にどれだけの成果を生み出したかが問われる

業務時間の短縮、コストの削減、売上や生産性の向上が成果の指標になる

開発にかかった工数ではなく、顧客に生み出した事業価値で稼ぐモデルへの転換が必要

2. 仕様定義とアーキテクチャで差がつく:

コード生成やテストをAIが担うことで、「どう実装するか」だけでは差がつきにくくなる

「何を作るべきか」を決める重要性はむしろ高まる

顧客の曖昧な要求を整理し、業務上の制約を理解する必要がある

AI、SaaS、既存システムをどう組み合わせるかを設計し、実現可能な仕様とアーキテクチャに落とし込む力が求められる

3. AIを安全に使う仕組みの提供:

AIが業務の一部を担うようになれば、「何ができるか」だけでなく「何をさせてよいか」が重要になる

どのデータへのアクセスを許可するのか、どこまで自律的な操作を認めるのかを決める必要がある

どこで人間の承認を挟むのか、AIの判断をどう監査し問題が起きたときにどう止めるのかを定める必要がある

AIを導入するだけでなく、安全に使い続けられる環境まで設計することが新たな提供価値になる

4. 責任そのものを価値にする:

顧客企業自身がシステムを作りやすくなっても、すべてのリスクまで自社で引き受けられるとは限らない

障害対応、データ漏洩時の説明、AIの誤判断に対する原因調査と改善を誰が担うのかという問題が残る

AIそのものがこうした責任を引き受けることはない

品質や運用を担保し、問題が起きたときに対応するという法人としての信用と責任が価値になる

■ 6. 古い仕組みの見直し

新しい能力の獲得だけでは不足:

これまでのSIビジネスを支えてきた仕組みそのものを見直す必要がある

人月を前提に最適化されてきた人員構成や組織、営業、開発環境の一部は変革を妨げる要因になり得る

もともと悪い仕組みではない:

多くの開発者を抱えることも、工数を正確に管理することも、外注先を確保することも人月ビジネスでは合理的だった

少人数で高い生産性を出すことが求められるようになれば、その合理性は変わる

人員構成の見直し:

「多くの人で実装する組織」から「少人数で設計し、AIを使って実装する組織」への転換が必要

定型実装を前提とした人員構成は、実装の生産性が上がり同じ成果に必要な人数が減るため見直す

工数・進捗管理中心の管理職の役割は、成果物の品質やAI活用開発全体を判断する能力が必要になるため見直す

特定言語や製品だけに依存した専門性は、コード解析や技術移行が容易になり差別化しにくくなるため見直す

組織・ビジネスモデルの見直し:

売上や評価制度が投入人数を前提としたままでは、AIを使うほど不利になるという矛盾が生まれる

営業では工数ではなく成果に対して価格を設定する

社内の評価も稼働率ではなく、少ない工数でどれだけ大きな成果を生み出したかを評価する仕組みへ変える

多くの人員を集めることを前提とした多重下請け構造から、少人数のチームがAIを活用する体制へ移す

「人を多く動かすほど売上と評価が上がる仕組み」から「少ない人員で大きな成果を出すほど利益と評価が上がる仕組み」への転換が必要

開発環境の見直し:

セキュリティ要件の厳しい開発現場では、安全性を重視して独自のルールや閉じた開発環境が整備されてきた

それらがAI活用そのものを妨げるなら、安全性を維持しながらAIを利用できる環境へ作り直す必要がある

過度に独自化された開発ルールは、AIを前提とした開発プロセスへの移行を妨げる可能性がある

AI利用を想定していない閉じた開発環境では、クラウド型のAI開発ツールを利用できず生産性向上の恩恵を受けにくい

問い直しの本質:

単純に古いから捨てるのではなく、従来合理的だった仕組みが前提の変化後も合理的なのかを問い直す

新しいAIツールを導入するだけならそれほど難しくない

本当に難しいのは、AIを活かすためにこれまで会社を支えてきた仕組みそのものを変えられるかどうか

■ 7. AI時代に求められる中核能力

4つの能力領域:

経営・戦略として、顧客企業の業務をAI前提で再設計し、投資対効果まで構想する

技術の見極めとして、AIモデルやAI製品の特性を理解し、適切な技術を組み合わせる

データ・ガバナンスとして、顧客データをAIで安全に活用できる状態に整え、権限や統制を設計する

変革の推進として、小さく導入し効果を検証しながら現場へ定着させ、適用範囲を広げる

システムの外側への踏み込み:

重要なのはAIそのものの技術力だけではない

顧客の業務を理解し、経営と対話し、投資対効果を示す必要がある

安全なデータ利用を設計し、導入したAIを現場に定着させる必要がある

これまでSIerがシステムの外側と考えてきた領域まで踏み込む必要がある

責任の価値の上昇:

作ることの価値が下がるほど、何を変えるべきかを考え、安全に実現し、結果に責任を持つことの価値は高まる

SIerはこれまでもシステムの品質や安定稼働、セキュリティに責任を担ってきた

作ることがコモディティ化するほど、成果やリスクに責任を持てることがこれまで以上に重要な提供価値になる

■ 8. まとめ

「SaaSの死」の本質:

SaaSそのものの終わりではない

AIによって「ソフトウェアは人間が操作するもの」という前提が揺らぎ始めたこと

作る側でも同じ変化:

コード生成やテストなどをAIが担えば、1人あたりが生み出せる成果は大きく変わる

投入した人月と生み出される成果の関係はこれまで以上に不均一になる

その影響を特に強く受けるのが、人の工数を売上に変えてきたSIer

仕事自体はなくならない:

顧客企業のAI化には既存システムとの統合、業務の再設計、ガバナンス、継続的な改善が必要になる

SIerの仕事がなくなるのではなく、価値のある仕事が作ることから別の場所へ移る

価値が移る方向:

人月から成果へ

実装から設計へ

導入から統制へ

納品から継続的な責任へ

最終的に問われること:

新しい能力を獲得するだけでなく、人月を前提として築いてきた既存の仕組みを変える必要がある

問われるのはAIによって減っていく仕事をどう守るかではない

AIによって生まれる新しい価値を、どう自分たちの事業に変えていくかが問われる

(2026/08/24)

【備忘録】AIで編集しやすいWBSの作り方 - 機能軸・工程軸で工数を集計するMarkdown表

【備忘録】AIで編集しやすいWBSの作り方 - 機能軸・工程軸で工数を集計するMarkdown表 #生成AI - Qiita

MEMO:

実質的にRDBMSの仕組みをアプリケーション層で再実装しているだけなので無駄が多い
RDBMSとそれを操作する為のMCPサーバを作った方がよい

(2026/08/23)

生成AIを使って、デザイナーにプロジェクトマネジメントスキルを「インストール」　4カ月の試行錯誤の記録

生成AIを使って、デザイナーにプロジェクトマネジメントスキルを「インストール」　4カ月の試行錯誤の記録｜Goodpatch Blog グッドパッチブログ

要約:

■ 1. 背景と問題意識

AI時代のデザイナーの不安:

リサーチもドキュメント作成もAIが担う領域が広がり、既存の専門性やスキルだけで大丈夫かという問いが生じている

「自分にしかできないこと」を問い直される場面が増えている

サービスデザイナーの実態:

デザインの専門性を起点にしつつ、プロジェクト全体を俯瞰して動く役割を担ってきた

クライアントの課題把握、関係者との合意形成、スケジュール管理や関係者調整にも積極的に関わっている

すでに「デザインだけ」の枠を超えた動き方をしてきたと言える

属人化という課題:

幅広い業務への関わりは個人の経験やセンスに大きく依存していた

「どう進めるか」が属人的なノウハウとして蓄積される一方、メンバーが変わっても再現できる「型」は整っていなかった

プロジェクトの発足:

属人化への課題意識と、AI時代に自分の領域をどう広げるかという問いが重なった

サービスデザイナーの有志で、AIを使ってプロジェクト管理業務にも自信を持って関われる状態をつくる取り組みを開始

2026年4月に始まり約4カ月間の試行錯誤を経ている

■ 2. サービスデザイナーとプロジェクト管理

サービスデザイナーの仕事:

クライアントの課題を把握し、それを解決するための体験やサービスを設計すること

ヒアリングの設計、ユーザーの理解、コンセプトのとりまとめが本来の主戦場

管理業務に関わる理由:

デザインの方針を決めるというプロジェクトの上流部分を担っている

一連のユーザー体験を設計するため、プロダクト全てのステークホルダーと関わる必要がある

主に関わるプロジェクト管理業務:

プロジェクトの目的、範囲、制約条件を整理したドキュメントの作成

「誰が何を決めるのか」という関係者の役割整理

新しい案件に入るときのクライアント業界の事前調査

定例会議の準備や議事録の管理

強みの意図的な活用:

デザインの視点でユーザーや事業全体を見渡せるからこそ、プロジェクト管理でも質の高い判断ができる

グッドパッチはこの強みを意図的に生かしている

■ 3. PM業務の整理と分解

出発点はPM業務の理解:

自分たちはプロジェクト管理のプロフェッショナルではないという前提に立った

プロジェクト開始直後に社内のプロジェクトマネージャー職のメンバーへヒアリングを実施

参照したPMBOK:

プロジェクト管理の国際標準となっているフレームワーク

業務を「立ち上げ」「計画」「実行」「監視・コントロール」「終結」の5段階に分けて整理している

業務の一覧化:

PMBOKをベースに、サービスデザイナーが実際に担っているタスクを一覧化した

AIが代替できる可能性があるタスクも併せて一覧化した

発見1: PM業務の多くを既に担当:

スケジュール設計、関係者の整理、要件の取りまとめ、会議の設計はすべてPMBOKに定義されたPM業務

サービスデザイナーが実質的なPMとして機能していることが、客観的なフレームワークによって可視化された

発見2: AIの得意領域は構造化とドキュメント生成:

ヒアリング内容の整理、情報を一定のフォーマットにまとめること、抜け漏れのチェックはAIが得意とする

クライアントとの合意形成や優先順位の判断は人がやるべき仕事

決定した基本方針:

AIが作るのはドラフトと構造、判断するのは人

■ 4. 9つのAIスキルの整備

Claude Codeのスキルという仕組み:

グッドパッチはClaude Codeを活用した業務効率化に取り組んでいる

スキルとは特定の業務をAIに任せるための専用設定

情報を収集、整理して出力する作業フローを定義すると、一言指示するだけでAIがその手順通りに動く

プログラムを書く必要はなく、自然言語でやってほしいことと出力フォーマットを記述するだけで作れる

開発の進め方:

チームメンバーで担当領域を分け、スキルの開発を並行して進めた

約3カ月で9種類のスキルを整備した

スキル1: プロジェクト開始時の全体像整理:

「何のために、誰と、どこまでやるのか」を文書化することは重要だが、経験と時間を要する

担当者とAIが対話形式でやり取りし、目的、関係者、範囲、スケジュールの骨格を整理する

完成文書を一発で作るのではなく、何から考えるべきか、どの順番で整理するかという思考の流れの支援に絞っている

スキル2: プロジェクト関係者の整理:

意思決定者や報告タイミングを整理しないまま進むと、後半でコミュニケーションのトラブルが起きやすい

関係者の構造を整理する経験はベテランでないと難しい

会話形式で登場人物の情報を入力すると、役割、責任、報告ルートの一覧表と組織の関係を視覚化した図を出力する

誰が何の意思決定に責任を持つかを整理するグッドパッチ独自のフォーマットを組み込み、実案件で試しながら精度を高めた

スキル3: クライアント業界の素早いキャッチアップ:

新規案件で業界、市場、競合を理解するには半日から1日かかることがある

マクロ環境、業界と市場の構造、法規制と制度、競合他社とポジション、ユーザーと顧客像、クライアント企業の組織と意思決定者の6つの切り口で自動整理する

情報の信頼度を「公式資料ベースの確かな情報」「複数ソース確認済みの参考情報」「要確認の情報」の3段階でラベリングする

開発過程での重要な気付き:

情報量が多ければ多いほど良いわけではない

AIに渡す内部整理用の資料と、クライアントに見せるコミュニケーション用の資料では目的が違う

出力を分けて設計しないと、どちらにも使えないものができてしまう

この気付きはスキルを作ってみなければ言語化できていなかった

そのほかに整備したスキル:

先行事例、競合リサーチ: 他社の取り組みを調べて比較整理したいとき

プロジェクトトラブル対応: 遅延、スコープ膨張、人手不足などへの対応策を複数案出したいとき

成果物の品質チェック: 作ったドキュメントの抜け漏れや論理的な矛盾を確認したいとき

コミュニケーション計画: どの頻度で誰にどう報告するかを整理したいとき

定例会議のアジェンダ生成: 次回の会議の議題案を自動生成したいとき

要求事項の整理: ヒアリング内容を「要望→要求→要件」の段階に整理したいとき

■ 5. スキル連携によるワークフロー自動化

次のステップ:

個別のスキルがそろった段階で、それぞれをシームレスにつなげられないかを検討した

想定した場面:

新規案件の初回打ち合わせ前の準備フロー

クライアントの業界と競合を調べ、内容を分かりやすくまとめ、正確性と抜け漏れをチェックする手順

人がやると半日以上かかることもある

自動化後の動作:

「○○社の業界調査をして」と入力する

AIが公開情報をもとに6つの切り口で情報収集、整理を5〜15分で行う

別のAIが内容の整合性と抜け漏れを自動チェックする

問題がなければ打ち合わせに使える資料として完成する

問題があれば指摘内容をもとに自動修正し、再チェックする

担当者の実働時間:

質問への回答3分と最終確認5分程度を合わせて約10分

残りはAIが並行して作業する

磨き込みのサイクル:

チーム内の他のサービスデザイナーに実際の案件で試験的に使ってもらった

そのまま使えるクオリティに達しているものもあったが、改善の余地がある部分も見えた

フィードバックを基に設計を見直して再度試すサイクルを繰り返した

特定の案件だけでなく幅広いプロジェクトで使えるワークフローへ磨き込んだ

■ 6. 意思決定の記録

記録を習慣化した理由:

スキルを作る過程では多くの設計上の判断が発生する

どちらのアプローチを選ぶか、どこまでAIに任せるかといった判断を後から追えるようにする必要がある

記録の形式:

意思決定一つひとつを「論点、背景、選択肢、結論、理由」の形式でドキュメントに残す

ソフトウェア開発の現場でよく使われる手法だが、AIを使ったスキルづくりでも同様に有効だった

記録の効果:

新しいメンバーが「なぜこう設計したのか」を後から理解できる

チームの学習の蓄積につながる

■ 7. うまくいったこと

最大の価値は「どう使うかの型」の提供:

AIを使えば誰でも情報を集められる時代に、ただ情報を集めるスキルには差別化の余地がない

作ったスキルの価値は情報収集ではなく、現場で培ったプロジェクト管理のノウハウをテンプレートとして提供する点にあった

ノウハウが型として使えることで、経験の少ないメンバーでも一定の品質でアウトプットを作れる

定例運営の変化:

議事録の自動生成とアジェンダを自動で作るスキルの組み合わせにより、会議の前後の準備作業が大幅に軽くなった

次の会議で何を話すかという議題案までAIが出すことで、準備時間が体感で半分以下になる

■ 8. 推進プロセスにおける気付きと工夫

方針の段階的な精緻化:

活動初期に「AIとは何をするものか」の定義をチーム内でていねいにすり合わせた

「定型作業を自動化するもの」と「自律的に計画から実行までやり切るもの」のどちらも有効な方向性だった

そのため段階を分けて進める計画に切り分けた

まず9つのスキル完成に集中し、次の段階でスキル同士をつなぐ自動化を考える2段階の計画とした

最初にゴールの認識をチームでそろえることが、後の開発をスムーズにする

スキル連携時の前提の食い違い:

複数のスキルを連携させると、それぞれの設計上の前提が食い違うケースが出る

品質チェックのスキルが要求するフォーマットと、別のスキルが生成する文書のフォーマットが微妙に違うといった衝突が起きる

論点と解決策の候補を記録に残してチームで議論するプロセスを定着させ、問題の再発を防ぎやすくした

■ 9. 4カ月の活動から得た3つの学び

「何をAIに任せるか」を最初に整理する:

AIを使う前に、この仕事のどこがAIに向いているかを考えることが大切

プロジェクト管理のフレームワークと現場ヒアリングで業務を棚卸しし、AIが得意な構造化とドキュメント生成に絞って着手した

この分解作業をせずにAIを使おうとすると、何を作ればいいか分からなくなる

スキルの価値は「収集」より「型の提供」:

AIで情報を集めること自体は誰でもできる時代

価値が生まれるのは、収集した情報をどのフォーマットで整理するかという型の部分

自分たちの現場で培ったノウハウを型に組み込むことで、汎用的なAIではなく自分たちの仕事に合ったスキルになる

試行錯誤の記録がチームの資産:

AIを使ったスキルづくりは最初から完成形にはならない

うまくいかなかったことや設計を変えた理由を残すことで、後から理解できる知識資産が蓄積される

記録の習慣こそが、個人の経験を組織の学びに変える鍵

■ 10. 結論

デザインの専門性だけでは安泰と言いにくい時代:

AIがリサーチもドキュメント作成も代わりにやってくれるようになっている

グッドパッチの取り組み:

サービスデザイナーが得意領域をデザインの外側にも広げていけるよう支援している

AIを使い、その拡張を特別なスキルを持つ一部の人だけができることから、誰もが型として再現できることに変えていく

今回紹介したPM領域への染み出しは、その一部分に過ぎない

(2026/08/22)

会議でメンバーが黙るのは、当事者意識の問題ではない

会議でメンバーが黙るのは、当事者意識の問題ではない｜hatamasa

要約:

■ 1. 沈黙の原因は場の設計

発言が出ない理由:

原因の大半はメンバー側ではなく場の設計側にある

相談された状況:

参加者5人のMTGで話を振っても「特にないです」「よくわからないです」で会話が止まる

ファシリテーター本人が喋り続けて独演会になり、最後に何かあればと促しても誰も発言せず解散する

当事者意識を疑う順番:

当事者意識や興味の不足を疑うのは一番最後でよい

引用の出所:

研究やデータの引用はAIの補助によるもので、原典を通しで読んで見つけたものではない

体感が先にあり、後から理屈がついた逆の順番である

■ 2. まず人数を疑う

ディスカッションの上限人数:

体感として成立するのは3人まで

4人を超えると「自分が言わなくても誰かが言うだろう」が発生し、5人でほぼ確実に起きる

悪意でも怠慢でもなく単純に構造としてそうなる

リンゲルマン効果:

1913年にフランスの農学者リンゲルマンが綱引きの実験で見つけた、人数が増えるほど一人あたりの力が下がる現象

ラタネらが1979年の論文でsocial loafing（社会的手抜き）と名づけ、原因が連携ミスだけでなく動機の低下そのものにあると示した

自分の貢献が見えにくくなり、代わりがきくと感じた瞬間に人は力を抜く

MTGで黙るのと綱引きで手を抜くのは同じ現象

Wheelanの研究:

Susan Wheelanが2009年に発表した、半年以上活動している329の職場グループの調査

3〜8人は9人以上より生産的、3〜6人は7〜10人より生産的という結果が出ている

3〜4人のグループは5〜6人のグループより有意に生産的だった

5人と3人の差は感覚的な誤差ではなく、測れば出てくる差である

8-18-1800ルール:

HBRで紹介されている目安で、意思決定や課題解決なら8人まで

アイデア出しなら18人まで、情報を伝えて士気を上げるだけなら1800人でもよい

情報共有だけが目的なら人数は多くて構わない

本当の問題:

共有の場とディスカッションの場を、同じ人数・同じ形式でやっていること

打ち手:

ディスカッションしたいテーマがあるなら参加者を絞る

全員に入ってほしいときはブレイクアウトで2〜3人に割ってから戻す

全員で黙ったまま過ごす時間より、少人数で話してもらった時間のほうが出てくる情報は明らかに多い

■ 3. 質問の粒度

「どうですか?」の難しさ:

答える範囲が無限に開いており、何を言えば正解なのかがわからない

わからないため「特にないです」になる

狭めた質問の効果:

「2人だと発言しやすいですか?」「この設計だとタイムアウトしそうな箇所はどこか」程度まで狭めると返答の確率が一気に上がる

答えやすい質問の定義:

答えの範囲が見えている質問

質問が雑になる条件:

聞きたいことがぼんやりしているときほど質問も雑になる

その場合は質問が悪いのであってメンバーが悪いわけではない

■ 4. ファシリテーターの発言順

先に答えを言わない:

A案が良いと思っていると先に話すと、その時点で議論は終わる

以降は「いいと思います」が並ぶだけの時間になる

自分の意見は最後に言う:

言葉にすると簡単だが実践するとかなり難しい

沈黙の3秒が3分ほどに感じられ、耐えきれずに自分で埋めてしまう

耐えられるかどうかの分岐:

その場が「意見を出す場」になるか「承認をもらう場」になるかが決まる

■ 5. 場のモードの宣言

モードを口に出す:

いまは発散の時間なので否定はなし、絞るのは後半と最初に一言添えるだけで効く

心理的安全性:

意見が出ない理由には、それを言ったら否定されるかもしれないという懸念がある

Amy Edmondsonの定義では、対人関係のリスクを取っても大丈夫だとメンバーが共有して信じている状態

一度でもコストが高いのではという指摘が飛んだ場では、以降ほとんど意見が出なくなる

否定しないというルールを掲げるより、最初に出てきた意見をファシリがどう扱うかが実際の空気を決める

発散と収束を混ぜない:

Sam Kanerの参加型意思決定のダイヤモンドでは、議論は発散ゾーン、うめきゾーン（Groan Zone）、収束ゾーンの順に進む

発散ゾーンでやるべきは判断を保留して自由に出してもらうこと

必要なのはテクニックというより、いまは判断しない時間だという共有である

実践:

アジェンダに「発散」「収束」と書いておく程度でも参加者の口の重さは変わる

■ 6. 開始直後のチェックイン

全員に一回だけ口を開いてもらう:

内容は近況でも今日の天気でも、名前と担当を言うだけでもよい

過去の認識:

アイスブレイクや雑談は本題に入るのが遅くなるだけの時間の無駄だと考えていた

効果:

開始から30分ずっと黙っていた人が途中から急に喋り出すのは相当きつい

最初に一言でも声を出していれば二言目のハードルがぐっと下がる

ジョンズ・ホプキンスの研究:

2001年の研究で、手術チームが執刀前に自己紹介と懸念の共有をすると合併症や死亡が減った

研究者はこれをactivation phenomenon（活性化現象）と名づけたとされる

一度発言した人はその後も発言する確率が上がるという整理である

数字の扱い:

35%減という数字は孫引きばかりで原典に行き着けず、話半分に読むべきである

実践:

オンラインのMTGなら最初に全員のマイクを一回開けてもらう

ここで使う1分は元が取れる

■ 7. 答えられる材料の有無

前提知識の不足:

既存機能や過去の経緯の解像度が低いメンバーは、そもそも質問自体が浮かばない

何がわからないかがわからない状態の人にどう思うかと聞いても出てくるはずがない

打ち手:

MTGの進行を工夫するのではなく、前提のキャッチアップを先に済ませる

ドキュメントの事前読み込みや既存実装を一緒に触るといった地味な準備が効く

期待役割の事前決定:

仕様まわりはこの人、技術設計はこの人と決めておくと、振られる領域が事前にわかり準備できる

その場で急に振られて答えられる人は少数派である

■ 8. 知見はあるが黙る人

タイプの特徴:

知見は十分にあるのに自信がなさそうに話し、声が小さく「たぶんですけど」が枕詞になる

場の設計をいくら変えても解決しない

対応:

あえて発言機会を作り、出てきた意見をそれでいきましょうと拾う

1回では変わらないが、何度か繰り返すと話し方が明らかに変わる

位置づけ:

ファシリテーションというより育成の話であり時間がかかる

ここを飛ばしてチームの発言量だけ増やそうとしても続かない

■ 9. 応急処置としての指名

設計できないまま始まるMTG:

実際には何の設計もできないまま始まるMTGのほうが多い

明日のMTGで1つだけ試すなら指名を選ぶ

全員への問いは機能しない:

誰か意見はあるかという問いかけはまず返ってこない

社会的手抜きと同じで、全員に向けた問いは誰の問いでもなくなる

名前を呼んだ瞬間、その問いは一人のものになる

副次的な効果:

ちょっとした意外性で場がほぐれ、当てられるとは思っていなかった空気がいい意味で崩れる

一人目が喋ると二人目以降のハードルが一気に下がる

沈黙している場でいちばん重いのは最初に口を開く役割である

指名する相手:

いちばん鋭い意見を持っていそうな人ではなく、いちばん答えやすそうな人を選ぶ

難しい問いを難しい相手に投げると沈黙がもう一段深くなる

応急処置であるため、まずは場を動かすことを優先する

■ 10. 問いの置き換え

立てるべき問い:

どうすれば発言してくれるかではなく、その人が答えられる問いを自分は用意できているか

発言を決める条件:

発言するかどうかを決めているのはメンバーの性格や意欲ではなく場の側の条件である

条件が揃っていればたいていの人は喋る

沈黙の意味:

沈黙はメンバーの状態ではなく、自分の設計のフィードバックである

そう考えると気が楽になり、次にやることも具体的になる

■ 11. コストとマネジメント

沈黙の金額的コスト:

5人集めて1人しか喋っていないなら、その意思決定は実質1人で決めているのと同じである

残りの4人分の時間はコストだけ払って捨てている

MTG設計の位置づけ:

地味だがマネジメントそのものである

誰に何を期待し、どの情報を持たせ、どの粒度で問いを置くかは日々の役割設計とほとんど同じである

MEMO:

そもそもリアルタイムで議論をする必要があるのかというところから考えるべきだと思うのだが

(2026/08/22)

AIで生産性が3倍になった私たちが、チームを置き去りにした話

AIで生産性が3倍になった私たちが、チームを置き去りにした話

要約:

■ 1. 置き去りは構造で起きる

上司の「正しいことを言っているのだと思う」:

週次の報告会でAIで作ったスライドとHTMLレポートを映したところ、上司はすぐには理解できないが正しいと述べた

そのときは好意的な反応として受け取ったが、あれはレビューが壊れた瞬間だった

筆者の立場:

大手製造業のDX推進部門でマネージャーを務める

この1年ほどチームの若手中堅メンバーと一緒にAI活用を進めてきた

生産性3倍と置き去りの同時発生:

体感の生産性は3倍になり、同じ時期に上司とベテランメンバーを置き去りにした

置き去りの性質:

誰の悪意でも怠慢でもなく、構造で起きる

置き去りにした側も損をする

悪役の不在:

上司は誠実、ベテランは真面目、若手は優秀であり、それでも壊れた

だからこの話は、たぶん他の組織でも起きる

対象読者:

組織のAI活用を推進している人、チーム内のAI活用の温度差にモヤモヤしている人

一部の若手だけが突っ走っていると感じている管理職

■ 2. 私たちが走った道

AI活用の入口:

製造現場出身で、転職を機にPythonを1から勉強した

製造ライン向けのアプリを現場に入れるようになり、やがてAIコーディングを使い始めた

標準化から仕様駆動開発へ:

作る人によって構造がバラバラで引き継げないため、標準仕様を作ろうとした

そこで仕様駆動開発という思想を知り、Claude Codeでそれを回す取り組みを始めた

業務時間外での学習:

30代前後の若手中堅が中心の取り組みメンバーと議論するうちに面白くなった

気づけばプライベートの時間にも情報を集め、試すようになっていた

報告資料の変化:

本社や幹部への報告資料は、それまで1週間ほど頭を支配される仕事だった

AIとの壁打ちなら1日集中すればだいたい形になり、そこから手直しはする

頭を占有される期間が1週間から1日になった

コーディング外への拡大:

アプリ開発は仕様さえあれば待っているだけで出来るようになった

気を使うメールの下書きは一瞬で出る

打ち合わせのメモを雑多に投げれば、ToDoとテーマの進捗が自動で更新される

自分用の秘書エージェント:

markdownのリポジトリを記憶の置き場にし、AIがそれを読み書きしながら育っていく仕組みにしてある

3倍の中身:

作業のスピードではなく、同時に抱えられるテーマの数が3倍になった

解放されたのは時間ではなく、頭の占有だった

1件あたりが3倍速く終わるのではなく、並行して持てる件数が増える

体感は少し速くなったではなく、働き方が別のものに変わったに近い

■ 3. 効率化の可視化と爆発

見えない場所で進んだ効率化:

AIコーディングは上司から見えない場所で進んでいた

コードが速く書けても、上司の目に入るのは成果物とスケジュールだけだった

1年かけた変化は、上司にとって順調に進んでいるらしいという以上の解像度を持たなかった

報告会での断絶:

AIで作ったスライドとレポートが報告会に出た瞬間に置き去りが可視化された

上司にとっては段階的な変化ではなく、ある日突然現れた断絶であり、驚くのが当たり前である

置き去りの一般法則:

進行中には気づかれず、可視化された瞬間に一気に表面化する

表面化したときには、もう差は1年分ついている

■ 4. レビューが上下両方向で壊れた

壊れたものの正体:

個人の能力ではなく、レビューという組織の品質保証機構が上下の両方向で同時に壊れた

上から私へのレビューの機能不全:

AI製の資料は情報が濃く、AIと壁打ちしながら考えを詰めるぶん私自身の視座も上がっていた

結果として、上司がレビューできる点がなくなった

信頼と検証の分離:

正しいと思うは信頼の言葉であって、検証の言葉ではない

検証が抜けて承認だけが残り、信頼はレビューにおいては機能不全の症状である

逆転した知識の勾配:

上司は中身にはついていけなくて申し訳ない、持ち帰ってちゃんと読む、勉強します、教えてくださいと言うようになった

職制上の関係は何も変わっていないのに、知識の勾配だけが逆転していた

レビューの場が、いつのまにか謝罪の場になっていた

上司の誠実さ:

自分のギャップを公の場で認め、AIで急速に変化が起きており自分が一番キャッチアップが必要だとメンバーに言えた

分からないことは自分で調べて、この場で質問していこうと促していた

できることをやっていたが、それでも壊れた

■ 5. 作っても定着しなかった自動化

上司の定型集計業務:

手元のデータを所定のフォーマットにまとめるだけの仕事に見えるが、例外的な扱いをする項目がいくつもあった

そのルールは上司の頭の中にしかなく、毎回それなりの時間を取られていた

3時間での自動化:

まずルールを本人に書き出してもらい、それをもとにアプリ化してマニュアルを付けた

このアプリをどうやってAIと作ったかの手順もレポート形式でまとめて添えた

作り方まで見てもらえば、AIでアプリを作る感覚を少しでも掴んでもらえると考えた

自動化が業務移管に化けた:

上司は次の集計タイミングである1ヶ月後までまともに触らなかった

触らないうちに使い方が分からなくなり、最終的にアプリごと集計業務を別のメンバーに渡すことになった

良かれと思って添えた作り方のレポートも、たぶん誰も読まなかった

OJTを省いた言い訳:

このときあえてOJTをほとんどせず、実験のつもりだった

マニュアルも手順も揃っているのだから、読んで試して、詰まったら調べて動かせるはずだと考えていた

今思えばこれは実験ではなく、教える手間を惜しんだ自分への言い訳であり、無理だった

自走力の希少性:

説明を読んでやってみる、詰まったら調べてまたやってみるという自走力は、実は希少なスキルである

マニュアルを配れば全員が使えるようになるという前提が成り立った現場を見たことがない

エンジニアの世界にいると基礎スキルに見えるが、人間のデフォルトはたぶん逆側にある

管理職は時間の貧困の最深部:

上司には自分の会議、部門の調整、上からの依頼がある

持ち帰ってちゃんと読むと言った本人が、一番その時間を持っていない

自走力の問題だと思っていたが、その手前に時間の問題があった

新しいことを覚える時間が最もない人に、新しいことを覚えてもらおうとしていた

定着リードタイムは潰せない:

開発リードタイムはAIで潰せたが、定着リードタイムは潰せなかった

作るのは3時間で済むが、定着は人間の時間で動く

AIによって開発が速くなるほど、ボトルネックは開発から定着へ移動する

■ 6. 上から若手へのレビューの崩壊

若手の報告への違和感:

自分の専門から外れたテーマの説明で、資料はきれいなのに自分の言葉になっていなかった

詰まるわけでも劇的な破綻もなく、書いてあることをそのまま読んでいるように聞こえた

そういう場面が一度ではなく増えていき、上司はそれを指摘できなかった

検知器としての資料の崩壊:

これまで資料が書けないことは、理解していないことの検知器だった

分かっていない人間にはそれらしい資料が作れず、資料作成自体が理解度のテストとして機能していた

AIはこれを壊し、資料の完成度と本人の理解度を切り離した

検知器の質問への移動:

本人の言葉かどうかを見抜くには、的確な質問をぶつけるしかない

AI活用についていけていない上司には、その質問が出せない

検知器が移った先に、検知できる人がいなかった

私が質問しなかった理由:

できなかったのではなく、しなかった

人前で答えられない状態を作れば指摘ではなく晒しになり、そこで恥をかかせるのは違うと思った

質問という検知器の副作用:

相手に恥をかかせるという副作用がついてくる

上司は質問できず、私は質問しなかったが、検知されなかったという結果だけが同じだった

自分の原体験:

学生時代に論文やネットから拾った言葉をそのままスライドに貼り付けて発表し、質問に答えられず叱られた

以来、自分の資料は一言一句自分の言葉で説明できなければならないを自分のルールにしてきた

この原則はAI以前からあり、AIはこの失敗モードを大量生産できるようにしただけである

若手に責任はない:

AIがなければ彼は勉強して出直しますと言っていたはずである

能力の前借りは道具の性質であって、本人の資質の問題ではない

■ 7. 時間の貧困ループと双方向の恨み

非対称になった時間の使い方:

AIを使うメンバーは資料作成もデータ集計も極力自動化し、空いた時間を創造的な仕事に使うか、単に楽をする

使わないメンバーは相変わらず資料作成とデータ集計に時間をかけている

自己強化する非対称:

作業に時間を取られている人にはAIを学ぶ時間が生まれず、学ばないから作業が減らない

自動化した側は空いた時間でさらに学んで差を広げる

同じ職場に逆向きに回る2つのループが立ち、分断は放置しても自然には解消しない

時間を作るだけでは解決しない:

奪われているのは時間だけではなく、頭の占有である

来週の報告資料に頭を支配されている人は、空き時間を与えられてもその頭では新しいことを学べない

占有そのものを外す道具がAIである以上、ループの入口はAIしかなく、だからこそ外からの介入が要る

共通言語の消失:

AI活用の話をしても通じなくなった

ただただ凄いことをやっている人たちという見られ方になり、それは理解ではなく畏怖である

当時の私たちの苛立ち:

自分たちばかりが仕事をこなしている、なぜ自分で情報を取りに行かないのか、なぜ勉強しないのかと感じていた

これは間違いだった

学ばないことの道徳化:

プライベートの時間を投じて学んだ人間は、学ばないことを意欲の問題として道徳化してしまう

実際には学習機会の構造の問題だった

私たちが学べたのは意欲が高かったからではなく、たまたま面白いテーマに当たり、たまたま自分の時間を使えたからだ

分断が完成する条件:

技術の差がついたときではなく、お互いが相手を道徳的に責め始めたときに完成する

■ 8. ベテランの静かな退場

ベテラン層の反応:

40代以降のベテラン層からはあきらめを感じた

自分たちはもう自分が知っていることでやっていくという静かな退避だった

驚き、動揺し、ついていこうとした上司とは違った

促されても出ない質問:

上司はこの状況に危機感を持ち、ベテランメンバーのこともちゃんと心配していた

だからこそ分からないことは自分で調べて、この場で質問していこうと言ってくれていた

それでも質問が出なかった

あきらめの危険性:

あきらめが可視化された形は、質問が出ないことだった

驚きは声になるが、あきらめは声にならない

声にならないから問題として表面化せず、表面化しないまま固定化する

だから畏怖よりあきらめの方が危険である

質問が出なかった原因は私にもある:

普段から浅い発言にはすぐに厳しく追及していた

悪気はなく議論の質を上げるつもりだったが、質問すると詰められる場を日常的に作っていた

上司がいくら質問しようと促しても、質問が出るわけがない

最初に必要だったもの:

底上げに必要だったのは教材でも時間でもなく、質問が出る場だった

そして私は、それを壊す側にいた

降りる側の合理性:

降りたくて降りる人はいない

何十年もかけて自分のやり方を作り上げた人にとって、道具が変わることは仕事のやり方そのものを疑われることに近い

持ち込んだのが一回り以上年下の人間で、質問すれば詰められる場なら、降りる方が合理的である

あきらめは、置かれた条件に対する妥当な判断でもある

暗黙知の時限問題:

降りたベテランは、自分の知識をAIの射程の外に置いたまま現場を去っていく

不良の因果、工程パラメータの勘所、過去の失敗など、最もAIに載せる価値のある暗黙知を持つ人から先に離れていく

底上げは追いつかせる話であると同時に、その知識が失われる前に接続する時限問題でもある

■ 9. これはあなたのチームの予告編

分断を駆動した2つの要因:

学習機会の非対称であり、業務の仕組みではなく個人の余暇で学ぶ構造だったから、学べる人と学べない人に割れた

道具が業務の形そのものを変えたことであり、働き方が変わったから使う側と使わない側で仕事の形が乖離した

固有事情の不在:

ここにうちのチーム固有の事情は何ひとつない

この力学はチームから部門へ、部門から会社へ、会社から社会へ、スケールを変えてそのまま働く

これはうちのチームの失敗談ではなく、あなたのチームの予告編である

社外カンファレンスでの確信:

AI時代の開発生産性をテーマにした社外のカンファレンスに参加した

個人の開発生産性が上がっても、なぜ組織の生産性は上がらないのかというテーマが繰り返し語られていた

開発の現場ではないのに、私たちの状況とほとんど同じだった

先頭集団の普遍的問題:

AI導入で先を行くソフトウェア業界が、すでにこの問題に組織として取り組んでいる

私たちの悩みは個別の失敗ではなく、先頭集団が直面している普遍的な問題である

製造業から見れば、あの業界の議論は他人事ではなく、数年後の自分たちの姿である

共通言語の有無という条件差:

ソフトウェア業界で語られる格差は、基本的にエンジニア同士の格差である

コードとレビューという共通言語を全員が最初から持つため、キャッチアップという言葉が成立する

私たちの現場では置き去りにされた側がそもそもコードを書かず、共通言語は最初から存在しなかった

共通言語がある組織では追いつく話で済むが、ない組織では言葉から作らなければならない

DX部門の存在意義:

この部門がAIを諦めれば、ツールは新しくなっても仕事の形は変わらず、ただのデジタイゼーションで止まる

それはイノベーションには繋がらない

まだAIを使っていない側との合流は、福利厚生でも人材育成でもなく、部門の存在意義そのものの防衛である

■ 10. 底上げは優しさではなく自衛

底上げの位置づけ:

置いていかれた人への優しさではない

動いた3つの理由:

レビューが機能しない組織では、私たちの成果は正しく評価されない

ベテランの暗黙知は、彼らが現場を去る前にしか接続できない

AIを諦めた瞬間に、DX部門は存在意義を失う

やるべきことは教えるではない:

置き去りは構造で起き、誠実な上司がいても起きる

分断は時間の貧困ループで自己強化するから、放置では解消しない

驚きは声になるが、あきらめは声にならない

そして、質問が出ない場を作ったのは私だった

ハンズオン教育の2つの設計:

上司も含めたチーム全体へのClaude Codeハンズオン教育を始めた

資料を配る方式をやめて、隣で手を動かしてもらう形にした

私が講師をやらず、教えるのは私より若いメンバーに任せ、私は同席するが多くは喋らない

私が教えない理由:

チームで一番知識のある人間が教えないのは奇妙に見えるかもしれない

質問が出ない場を作ったのが自分である以上、私が前に立てば同じことが起きる

教える力より、聞ける場を優先した

(2026/08/22)

十億円以上払って，フロントエンドJavaScriptがDB(当然スキーマレス♥️)までを串刺し垂直統合して...

十億円以上払って，フロントエンドJavaScriptがDB(当然スキーマレス♥️)までを串刺し垂直統合して制御する最高にモダンで驚くほどフレキシブルな基幹システムを導入→"全て"が崩壊，みたいな事は令和に入ってもそこかしこで起きている．ソフトウェアエンジニアの皆さんは安心してあと10年は働けるね！☺️

@Mekajiki

何故こういう事が起きるのか？おれは完全に説明できる．

1. 全てのソフトウェアが原理的に永遠のサグラダ・ファミリアだから

2. 発注者は一生パソコン小学1年生だから

3. Excelが人類史上最高のソフトウェアだから

@Mekajiki

MEMO:

Firebaseとかで簡単なシステムを作って成功体験にしてしまったベンダーが調子に乗って基幹システムに手を出したとかだろうか？

(2026/08/22)

【無料】ドキュメントを書くな、会話を拾え

【無料】ドキュメントを書くな、会話を拾え｜松濤Vimmer

要約:

■ 1. 会話ログの価値と取りこぼし

AIとの会話時間の増大:

AIを使う人ほど、人と話すよりAIと話している時間のほうが長くなる

会話に残る判断の履歴:

なぜその方針にしたのか、どの案を捨てたのか、何を試して駄目だったのかが会話の中に全部残っている

最後に残るのは成果物だけ:

わたしたちが最後に残すのは、できあがったコードと短くまとめたドキュメントだけ

会話そのものはセッションを閉じたら二度と開かれない

取りこぼしの規模:

手元で数えたところ、直近1か月の会話ログは1000本以上あった

ここで取りこぼしている量は想像以上である

■ 2. 手で書く前提の放棄

事後のドキュメント化は続かない:

大事な判断はあとでドキュメントに書き起こせばよいと毎回思っていたが、書いたことは一度もない

作業が終わった直後は、いちばん書きたくないタイミングである

自動収集への移行:

こちらが書くのをやめ、会話が終わったことを検知してセッションそのものを勝手に拾わせる

Hooksの役割:

ClaudeCodeのHooksは、特定のタイミングで外部コマンドを自動実行してくれる仕組み

残る問題は、どのタイミングに仕込むかである

■ 3. 仕込み場所の4候補

SessionEnd:

セッションが終わったときに発火する

会話ログ（transcript）のパスが渡ってくるので、会話全体をまるごと後処理に回せる

PreCompact:

コンテキストが要約に畳まれる直前に発火し、長い議論ほど必ず通る

畳まれたあとの要約からは、捨てられた案や試して駄目だったことが消えている

その前に拾えるのが効く

SubagentStop:

サブエージェントが終わったところで発火する

実はここがいちばん捨てている

Stop:

応答が終わるたびに発火する

ターン単位なので細かいが、そのぶん取りこぼしがない

粒度と発火頻度の関係:

上に行くほど1回の情報量が多く、下に行くほど発火が頻繁になる

全部入れる必要はなく、どれか1つを選ぶならSessionEndからでよい

■ 4. SessionEndを起点にする理由

区切りとしての自然さ:

1セッションが1つのまとまりなので、区切りとして自然である

想定以上の発火頻度:

セッションの終了だけでなく、/clear でも発火する

作業を切り替えるたびに /clear している人なら、1日に何度も通っている

設定の簡潔さ:

hooksのSessionEndにtype: commandでスクリプトを登録するだけでよい

async: true を付けているのは、閉じる操作を待たせないためである

■ 5. 終了時の処理はキュー投入のみ

終了時の知見抽出は却下:

当初はSessionEndで会話ログを読み込み、その場で知見を抽出させるつもりだったがやめた

素直に考えるとそうなるが、会話ログが重すぎる

会話ログの実測サイズ:

1セッションあたり平均で約1MB、大きいものは1本で50MBを超えていた

遅い仕組みは使われない:

終了時に読ませると、ClaudeCodeを閉じるたびに待たされることになる

閉じるのが遅い仕組みは、確実に使わなくなる

キューに積むだけの設計:

SessionEndではsessionId、host、transcriptのパス、cwd、reason、endedAtを書き出すだけにした

会話ログ本体はコピーせず、どこにあるかといつ終わったかだけ控えて即終了する

重い処理の後回し:

重い処理はあとからまとめて回す

処理済みのセッションIDを控えておけば、同じ会話を二度読ませることもない

収集と読解の分離:

取りこぼさないための仕組みと、中身を読む仕組みは、分けたほうがうまくいく

後処理も自動化:

あとから回す工程も手では回さず、自作のジョブ管理アプリに登録して毎朝の定期実行に任せている

手動の工程がひとつでも残ると、そこから確実に途絶える

■ 6. SubagentStopが最大の取りこぼし

サブエージェントの仕組み:

メインの会話（親）から調査を切り出し、別の文脈で動かす仕組み

親に返ってくるのは最終テキストだけ

親に残らない過程:

何十回もファイルを読み、grepし、当たりを外して絞り込んだ過程は、親の会話ログに一行も残らない

実測した消失率:

サブエージェントの会話ログ30本で、全体の文章量と親に返した最終テキストの量を比べた

中央値で68.9%が親に渡らずに消えていた

少ないものでも29%、多いものは93%であった

量的な比重:

手元の会話ログ1091本のうち581本がサブエージェント側で、容量では全体の約半分を占めていた

ログ全体の半分が、この読み返されない側にある

SubagentStopの利点:

サブエージェント自身の会話ログのパスと、親に返した最終テキストの両方が渡ってくる

返した結論とそこに至る全過程がセットで手に入るのは、ここだけである

絞り込みと導入順:

matcherでエージェントの種類を絞り込めるので、ExploreやPlanなど調査系だけ拾うこともできる

粒度が細かいぶん発火は多くなるので、SessionEndを回してから足した

■ 7. 1週間運用の結果

保存された記憶は20件:

最初の1週間で、記憶として保存されたのは20件であった

20件の内訳:

やってみて分かったこと（lesson）が7件、決めたこととその理由（decision）が7件

プロジェクトや道具などの実体（entity）が3件、以後守るルール（rule）が2件、外部の参照先（source）が1件

1セッションあたりの歩留まり:

1セッションから1件残るかどうかである

件数の妥当性:

会話の大半はその場の作業のやり取りで、読み返す価値はない

残す価値があったのがこの20件だった、それだけの話である

手では書かれない20件:

むしろ大事なのは、その20件が手では絶対に書かれなかった20件だという点

手で書く運用のままなら、良くて2、3件だったはずである

継続の成果:

これを続けた結果、いまはかなりの数がナレッジとして蓄えられている

■ 8. 引き出す側のHooks

溜めるだけでは使われない:

溜めた知識は、こちらが思い出そうとしない限り使われない

前に決めたと気づけるなら、そもそも記録は要らない

UserPromptSubmit:

依頼文を送った瞬間に、関係するルールを差し込む

PreToolUse:

コマンド実行やファイル編集の直前に、その作業に関係する知見を渡す

実際の発動例:

この記事を書いている最中にも「読者未知の内輪議論を既知前提で語らない」という過去の知見が差し込まれた

こちらからは何も呼び出していない

pushとpullの使い分け:

守ってほしいルールはpush（勝手に届ける）、知識はpull（必要なときに引く）

2つで1セット:

溜めるHooksと引き出すHooks、この2つでやっと1セットになる

■ 9. 結論

会話は、閉じる瞬間に拾う

(2026/08/22)

仕様書は書かずに開発　老舗ベンダー弥生はAI前提でソフトウェア開発をどう変えたか？：AIネイティブ企業に大転換

仕様書は書かずに開発　老舗ベンダー弥生はAI前提でソフトウェア開発をどう変えたか？：AIネイティブ企業に大転換（1/2 ページ） - ＠IT

(2026/08/21)

Qwen3.8 27Bが驚異の6.2GBに!? Unslothが新量子化技術で実現

Qwen3.8 27Bが驚異の6.2GBに!? Unslothが新量子化技術で実現 - PC Watch

(2026/08/21)

Vercel Labs、Zig製の小型コーディングエージェント「fx」をオープンソースで公開

Vercel Labs、Zig製の小型コーディングエージェント「fx」をオープンソースで公開 | gihyo.jp

(2026/08/21)

Docker社、コンテナ向けの高性能な新ハイパーバイザ「Docker VMM」パブリックベータ公開

Docker社、コンテナ向けの高性能な新ハイパーバイザ「Docker VMM」パブリックベータ公開－ Publickey

(2026/08/20)

当社システムへの不正アクセスに関するお知らせ（第二報）（2026年8月19日 18:40更新）

当社システムへの不正アクセスに関するお知らせ（第二報）（2026年8月19日 18:40更新） | さくらインターネット

(2026/08/20)

当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて

当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて | さくらインターネット

(2026/08/20)

会社員で「コミュニティの人」でもある場合の落とし穴

会社員で「コミュニティの人」でもある場合の落とし穴 - 覚書

要約:

■ 1. 本記事の対象と前提

想定読者:

IT技術を専門とする会社員

プログラミング言語やフレームワーク等のコミュニティで「あのコミュニティのあの人」として社外に名が通っている人

業務の一環としてコミュニティ活動をしている人

そのような人になりたい人にも役立つ内容

特定個人の話ではなく、自分もそうなりかけた経験を含めた一般論

■ 2. 個人としてやる場合と会社員としてやる場合の差

個人としての活動:

当人とコミュニティにとって良いことであれば何も問題はない

会社員としての活動:

はまりがちな落とし穴が存在する

■ 3. 見かけの成果への疑い

名が通ることで起きる変化:

社外に様々な知り合いが増える

イベントに呼ばれたり取材されたりすることもある

凄そうに見え成果が出た気がするが、本当にそうかは疑うべき

■ 4. 期待役割との整合確認

コミュニティ活動をしていると、そのために使う時間が増える

チームメンバーと一緒に仕事をする機会も減る

コミュニティ活動が雇用主やチームの期待する役割と合っているかを定期的に確認し、日々やることを決めるべき

■ 5. 確認を怠った場合に起こること

社内で浮く:

最悪の場合「なんだか有名らしいが、何をやっているかわからず、会社に貢献しているかも不明で、遊んでいる人」に見られる恐れがある

周囲による放置:

「会社の業務に貢献していないので評価はできない」「しかし下手に発信力があるので強く言いにくい」として放置されるケースもある

評価のギャップ:

本人は精力的に活動し外向きには評価されているのに、内部では評価されない状態が生まれる

ギャップの帰結:

それに耐えられず会社を辞めてしまう人は珍しくない

不満を社外に吐き出して信用も毀損してしまう人も珍しくない

■ 6. 関係者の納得が成果化の条件

コミュニティ活動をやっている理由と効果を関係者、少なくともキーマンに納得してもらう必要がある

納得を得て初めてコミュニティでの活動が業務としての成果となる

コミュニティ活動の効果の例:

会社のプレゼンス向上につながる

採用につながる

他社技術者との交流によって新たな知見が得られる

コミュニティ活動は成果が測りにくい

実践方法:

上司との1on1やチームのミーティングで効果を主張する

実際にやり遂げて信頼を積み重ねる

■ 7. 錯覚の構造

本質は「必要性を周りに納得してもらったことをやると成果になる」という話にすぎない

しかしこれが難しい:

コミュニティ活動を頑張ると社外評価が高まる

そのため社外評価が社内評価に直結すると錯覚しやすい

■ 8. 結論

誰かが何らかのコミュニティで重要な役割を果たしてくれるのは素晴らしいこと

会社の給与を受け取りながらやる場合は、関係者が納得した上でやるとよい

本人の信用を毀損してまでやることではない

(2026/08/20)

AIがコードを書くなら、もう勉強しなくていい？AI時代に基礎を学ぶ理由

AIがコードを書くなら、もう勉強しなくていい？AI時代に基礎を学ぶ理由 | ドクセル

要約:

■ 1. テーマ設定

今日の主題:

AIを使って開発することと、基礎を勉強すること、その折り合いをどうつけるか

個人的な感想とポジショントークを交えて話す

マシュマロに届いた質問:

AIの進歩がすごすぎて、自分でコンピュータのことを勉強しても無駄なのではと思い、モチベーションが消え失せている

その気持ちはすごく分かる:

仕事でプログラムを書くとき、エディタを開いて自分でソースコードを書くことはまったくなくなった

設計や方針を考えるときもAIに相談しまくる

自分の知識はいるのか、AIにすべて任せるでもいいのではないか、という疑問が生じる

■ 2. 宮本佳林さんの事例

ファン参加型の10時間生配信:

新曲発売に合わせて企画

𝕏のハッシュタグ投稿数やミュージックカードの購入数に応じて、衣装やカメラを解放していく

最後に自宅でMVを再現し、本物と比較する

このために作ったシステム:

配信画面に表示する進捗ゲージ

数値を操作する管理画面

𝕏のハッシュタグ投稿数を取得する仕組み

再現動画を本物と比較してAIに採点してもらう仕組み

プログラミング経験ゼロでの達成:

コードは一行も自分で書いていない

それでも実際に10時間配信を成功させた

このシステムについては本人がブログに書いている

■ 3. 異常系の難しさ

外部サービスは止まる:

𝕏の投稿数を自動取得する仕組みは、当然外部サービスに依存する

失敗したときどう振る舞うかは、意識して決めない限り決まらない

実際にその失敗を踏むまで、どうなるか分からない

宮本さんの実装:

最後に取得できた数字を表示し続ける

必要に応じて管理画面から手動で修正できる

難しいのは正常系より異常系:

エラーが起きたときにどうするかを、考えて、設計して、テストして、トレードオフの中で最善を選ぶ

ソフトウェアエンジニアをやっていると分かってくる、いちばん大変なところ

成功の要因:

自分が利用者であり、ゴールが明確だった

AIが持つ知識と自身が持つドメイン知識の掛け合わせ

「10時間の生配信を成功させる」という明確なゴールを設定してシステムを作っていった

もし自分が今ぺーぺーだったら:

エラーが起きたとき、想定外のバグを踏んだときにどうすべきか

気をつけることができただろうかという疑問が残る

■ 4. ジョシュアツリーの話

ノンデザイナーズ・デザインブック:

デザイナーでない人に向けてデザインの原理原則を紹介してくれている名著

その第一章に書いてある内容を、いまだによく覚えている

ジョシュアツリーの逸話:

筆者はクリスマスプレゼントに植物の図鑑をもらい、最初に載っていたのが独特の見た目の木だった

こんな変な形の木、見たことがあったら気づくに決まっている、一度も見たことがないはずだと考えた

本を持って外に出たら、近所の4軒の庭に生えていた

名前を意識した途端の変化:

「ジョシュアツリー」という名前とその形を意識するようになった途端、それまで一度も見たことがないと思っていた木が実はそこにあったと気づいた

名前を知らないものは見えない:

自分が知らないことは、「調べる必要がある事柄」として認識することもできない

「作りながら学べばいい」の死角:

プログラミングの学び方として、作りながら必要なことを学べば良いという意見もある

ただ、それだと実はそこにあるはずの問題点に気づけないということもある

■ 5. 基礎固め

社会人大学院に通っていた:

2022年から2025年まで、仕事をしながら通った

アメリカのジョージア工科大学のコンピュータサイエンス修士課程

大学院に行く前も、職業エンジニアとしてWeb開発をしたり、Rustを書いてOSSにコントリビュートしたりはできていた

断片的な知識から地図へ:

大学院の前は、働きながら必要なことを学べば良いという状態で、断片的な知識でやりくりしていた

OS、ネットワーク、データベース、分散システムといったCSの基礎はおろそかだった

基礎を体系的に学んだことで、それまで持っていた断片的な知識を大きな地図の上にマッピングできるようになった

■ 6. 陳腐化しない基礎

数年後には大きく変わっているもの:

今使っているプログラミング言語やツール、AI関連のサービスなどは変わりゆく

さほど変わらないもの:

CPUがどう命令を実行するのか

OSがメモリやプロセスをどう管理するのか

コンパイラがどうコードを変換するのか

複数のコンピュータがどう通信するのか

基礎学習のコストパフォーマンス:

陳腐化せずにずっと役立つため、基礎を学ぶことはコスパがいい

■ 7. AI時代に問いを持つ力

基礎の出番はむしろ増えた:

基礎は不要になるどころか、むしろ使う場面が増えた

AIはこちらの指示に対して、もっともらしい実装を爆速で出す

そこに対して何を問えるかが焦点となる

その実装に何を問えるか:

他のやり方はないのか

利用者が増えたときにどうなりそうか

外部APIが止まったらどうなるのか

データはどこに永続化するのか、それは合理的なのか

何かが失敗したときに、それにどう気づくのか

■ 8. まとめ

今日言いたかったことではないこと:

AIを使わずに自分でコードを書こう、という話ではない

まず何年も勉強してからものを作ろう、という話でもない

ものを作り始めるハードルは大きく下がった:

解決したい問題があり、それを具体的な仕様にしてAIと相談しながら進めれば、実際の10時間配信で使えるシステムまで作れる

それですべて十分かというと違うかもしれない:

ジョシュアツリーの話のように、名前を知らないもの、存在を意識したことがないものはそこにあっても認識できない

問題を表現する言葉や背景にある仕組みを知らなければ、ここを調べた方がいいと気づくことすらできないかもしれない

地図があると問いを持ちやすくなる:

外部APIが止まったらどうなるのだろう

このデータはどこに保存されるのだろう

利用者が増えたらどこがボトルネックになるのだろう

失敗したとき、誰がどうやって気づくのだろう

結論:

勉強を終えるまで、作るのを待つ必要はない

でも、作ったものを理解するための勉強は、むしろ大事になる

まず作る、そして作ったものを理解するために学ぶ

(2026/08/19)

LLMは「次の単語を当てる」だけなのに、なぜ思考しているように見えるのか？

LLMは「次の単語を当てる」だけなのに、なぜ思考しているように見えるのか？｜中島聡

要約:

■ 1. LLMの動作原理

唯一の仕事:

それまでに書かれた文章全体を見て、次に来る確率が最も高い単語を一つだけ決める

決めた単語を文章の末尾に足し、返答が終わるまで同じことを繰り返す

仕掛けはこれで全部

単純な作業の反復から現れたもの:

途方もない量の文章に対して何十億回と繰り返した結果、コードを書き、量子物理を説明し、詩を翻訳する何かが現れた

人と話しているとしか思えない会話もこなす

学習量の規模:

GPT-3の学習に使われた文章量は、人間が寝ずに休みなく24時間読み続けても2,600年以上かかる分量

それ以降のモデルは、さらに大量の文章を読んでいる

規則を教えない学習:

誰も規則を書き下ろしておらず、文法も意味も文脈も説明していない

与えたのは「次に来るものを当てるのが上手くなれ」という一つの指示だけ

言語の知識、事実、推論、話し方の調子、性格めいたものは、すべてその一つの目標から浮かび上がった

■ 2. パラメータと学習

モデルの中身:

振る舞いを決めているのはパラメータ(重み)と呼ばれる数千億個の数字

あるモデルと別のモデルを違うものにしているのは、この数字だけ

学習の手順:

学習の最初、パラメータはすべてでたらめな値で、モデルは意味のない文字列しか出さない

文章の最後の単語を除いた部分をモデルに入れ、予測を実際の単語と比べ、どれだけ外れたかを測る

数千億個のパラメータのすべてを、その外れが小さくなる方向にほんの少しずつ動かす

これを何兆もの例に対して繰り返す

計算量の桁外れさ:

1秒間に10億回の計算ができる人でも、最大級のモデルの学習に必要な計算の再現には1億年以上かかる

現実に可能なのは、大量の計算を同時並行でこなす専用チップであるGPUがあるため

学習後のパラメータが持つもの:

言語がどう働くのか、物事が何を意味するのか、概念どうしがどう関係するのかが符号化されている

どんな場面でどんな返答が適切なのかも符号化されている

その形は誰も完全には解読できていない

■ 3. 予測が会話になる仕組み

入力の組み立て:

会話の文脈全体にAIの役割や目的を書いた説明を足し、まとめてモデルに入れる

モデルは文章の塊全体を見て次の単語を予測し、その単語が足されるとまた全体が最初から走る

確率的な単語選択:

モデルは毎回いちばん確率の高い単語を選ぶわけではなく、確率の分布から抽選するように選ぶ

確率の高い単語がよく選ばれるが、ときどき確率の低い単語も選ばれる

同じ質問を二度しても違う答えが返るのはこのためで、返答が自然に感じられるのもこのため

常に最高確率を選ぶ場合の弊害:

ぎこちなく、同じ表現を繰り返す文章になる

分布から抽選することで、人が書いたように読めるものになる

temperature:

この分布を調整する設定

低くすると、より決まりきった焦点の定まった答えになる

高くすると変化に富んだ創造的な答えになり、上げすぎると支離滅裂になる

■ 4. トランスフォーマーとアテンション

2017年以前の限界:

言語モデルは文章を先頭から一語ずつ順番に処理していた

冒頭の情報が末尾に影響するには間のすべての段階を通り抜ける必要があり、長い文章で根本的な問題を生む

Attention Is All You Need:

2017年にGoogleのチームが発表した論文

そこで示されたトランスフォーマーという構造が、すべてを変えた

並列処理への転換:

トランスフォーマーは文章を順番には読まず、入力全体を一度に受け取り並列に処理する

どの単語も、他のすべての単語を同時に直接参照できる

長い文章の冒頭が末尾に与える影響は、隣り合った単語どうしと同じくらい直接的になる

アテンションの働き:

入力の各単語は、長い数字の並びとして表現される

各単語が他のすべての単語を調べ、周囲の文脈に応じて自分の表現を更新する

「bank」は「river bank」と「bank account」で意味が異なり、周囲を調べて数字の並びが表すものを調整して区別する

層の積み重ね:

この処理が何層にもわたって繰り返され、各層が文脈に基づいて表現を洗練する

最後の層では、入力の長さによらず全体から引き出した予測に役立つ情報が各単語の表現に詰め込まれる

■ 5. ニューラルネットワークの構造

基本の仕組み:

脳の神経細胞の働きをゆるやかに参考にした、数学的な演算をつなぎ合わせた仕組み

ニューロンの計算:

基本の単位はニューロンで、ニューロンは数字を一つ持つ

値は前の層のニューロンの値に重みを掛けて合計し、バイアスという定数を足し、出力を一定範囲に収める関数に通して決まる

このつながりに掛けられている重みがパラメータであり、学習の過程で調整されていく

画像認識の例:

手書き数字を認識するように訓練されたネットワークは、まず一つひとつの画素の値を処理する

最初の隠れ層は輪郭を検出し、次の層は輪郭を組み合わせて形にし、最後の層は形を組み合わせて数字の識別にする

誰もこれをプログラムしておらず、学習から現れたもの

言語モデルとの共通原理:

はるかに大きな規模とはるかに複雑な構造で動くが、原理は同じ

仕事に役立つ内部表現を、モデルが自分で学ぶ

その表現は設計されたものではなく、現れたもの

■ 6. 助手になるための第二の学習

事前学習だけでは不十分:

ネット上の文章による事前学習は、モデルに言語を予測することを教える

ランダムな文章の続きを当てられることと、役に立つ助手であることは別

事前学習だけのモデルは、有害な内容も誤情報も流暢で無用な返答も、パターンの続きとしてそのまま書く

人間のフィードバックによる強化学習(RLHF):

人間の評価者が複数の返答を見比べ、どちらが良いかを示す

そのフィードバックを使い、人間が好む返答を出しやすくなるようにパラメータをさらに調整する

第二段階がもたらすもの:

特定の要求を断ること、単に流暢なだけでなく役に立とうとすること、自動補完でなく助手のように振る舞うこと

事前学習は言語と世界についての知識を与え、第二段階はその知識をどう使うかを形づくった

■ 7. 作った人にも分からないこと

可視化しても解釈できない内部:

手書き数字のネットワークの各ニューロンがどんなパターンに反応するかを見ても、期待どおりのものが出るとは限らない

輪郭から形へという分かりやすい形にはならず、解釈のしようがないパターンを学んでいることが多い

ちゃんと動くが、人が期待した動き方ではない

言語モデルでも同じ:

推論に見える何か、類推に見える何か、文脈の理解に見える何かをしていることは観察できる

その振る舞いが背後の数式からどう現れているのかは、作った人たちにさえよく分かっていない

推論は現れたもの:

モデルは推論するようにプログラムされたわけではなく、文章を予測するように訓練されただけ

推論と呼べるものがあるなら、それは学習が規模を得たときに現れたもの

予測しにくい信頼できなさ:

複雑な概念を見事に説明できるモデルが、まったく事実でないことを自信たっぷりに述べることもある

モデルが学んだのは流暢で役に立つ文章とはどういうものかであり、中身が正確かどうかは別の問題

■ 8. 丸暗記ではなく構造の発見

ラベルをでたらめにした実験:

正解ラベルをすべて入れ替えて学習させても、学習データに対しては完璧な正答率を出せる

ただ丸暗記しているだけで、未知の問題には一般化しない

正しいラベルでの学習:

モデルははるかに速く学び、一度も見たことのない例にも対応できるようになる

データの中に構造があると、パターンが見つけやすくなるため

構造の正体は未解決:

モデルは単に丸暗記しているのではなく、構造を見つけている

その構造が理解のようなものなのか、理解に似ているだけの何かなのかは、まだ答えの出ていない問い

明示的にプログラムされていない能力:

コードを書く

言語を翻訳する

文書を要約する

学習データのどこにも現れない話題についての質問に答える

■ 9. なぜこれが始まりなのか

自明ではなかった帰結:

2017年のトランスフォーマーが、文章を大規模に並列処理することを可能にした

最大級のモデルの学習に必要な計算量は、手作業なら何百万年もかかる規模になった

次の単語を予測するというだけのことから役に立つ能力が現れ、作った研究者たちさえ驚かせた

文章の予測がソフトウェアを書き科学を説明し会話を続ける何かを生むと、自信を持って予言していた人はいない

言語に含まれる世界の構造:

動いた理由は、言語そのものの中に世界についての膨大な構造が含まれているため

物理実験の説明文の次の単語を当てるには、物理について何かを分かっている必要がある

コードの次の一語を当てるには、そのコードが何をしているのかを分かっている必要がある

教わらずに学んだこと:

モデルは物理もプログラミングも直接教わっていない

文章の予測が上手くなるために必要なことを、必要なだけ学んだ

残された問い:

仕事は一つで、次の単語を当てること

数千億のパラメータと何兆もの例でやらせると、思考のように見える何かが反対側から出てくる

なぜそうなるのかを完全に分かっている人は、まだ誰もいない

(2026/08/18)

【OSS】現場で使える軽量な脅威検知・監視基盤「kizashi」を個人開発してみた（設計・実装の全記録）

【OSS】現場で使える軽量な脅威検知・監視基盤「kizashi」を個人開発してみた（設計・実装の全記録） #Docker - Qiita

(2026/08/18)

そもそも今のspeckitやcc-sddやOpenSpecの指す狭義の仕様駆動開発自体、過渡期のもので消滅すると...

そもそも今のspeckitやcc-sddやOpenSpecの指す狭義の仕様駆動開発自体、過渡期のもので消滅すると思っている。実際にspeckitのリポジトリとかみたら、GitHubはとっくに気が付いていると思う。

広義の意味でいえば要件or要求駆動開発の方が適切やろと思っている

@nuits_jp

(2026/08/18)

Kiro とか SpecKit とか OpenSpec みたいな SDD ツール、最近は「いる？」って思ってきたんですけど...

Kiro とか SpecKit とか OpenSpec みたいな SDD ツール、最近は「いる？」って思ってきたんですけど、みなさんどうですか？ぶっちゃけ仕様を考えたり、それを元に実装する skills や sub agent を書けばそれでよくないですか？

@a_suenami

100 歩譲って Kiro とかは IDE としての価値がある気もするけど、CLI ツールは別にただの slash command のイニシャライザーじゃんと思ってしまう。

@a_suenami

MEMO:

一理ある

(2026/08/18)

今から「情報系キャリア」には進むな。推奨しない理由と、AI時代にも生き残るキャリア論

今から「情報系キャリア」には進むな。推奨しない理由と、AI時代にも生き残るキャリア論｜Saki

要約:

■ 1. 情報系進学への反対

今から情報系に行くべきでない:

IT・AIブームの熱狂がピークにある今だからこそ、あえて進学を止める

「とりあえず情報系なら一生食いっぱぐれない」「データサイエンティストが最強の職業」という認識が世を覆っている

理一・理二の難易度高騰:

この5年ほど東大理一・理二の難易度が異常に高騰している

かつては地方旧帝大の医学部より入りやすかったが、今や完全に逆転した

筆者の立ち位置:

東大情報理工の修士を出て、現在は外資系企業でAIエンジニアを務める当事者中の当事者

情報系・AIブームの恩恵を最も受けている立場にある

同時に不都合な現実と構造的リスクを察知し、東大医学部を再受験して物理層とライセンスの保険をかけた

■ 2. 消えるジュニア求人

ジュニア層の求人削減:

外資系ビッグテックや日本のメガベンチャーで、新卒・若手のコーディング求人削減が静かに確実に進行している

開発構造の根本的変化:

LLMをはじめとする強力なAIエージェント基盤の実務導入により、開発・生産の構造が根底から変わった

タスクを分割しAIに的確な指示を出しレビューできるマネージャーやシニアが1人いれば足りる

その下で下働きするジュニアエンジニアはもう20人も要らない

最も恐ろしいのは切られる順序:

「無能から切られる」のではなく「若手から切られる」という構造にこそ恐ろしさがある

かつては先輩のコードを読み、バグ取りや簡単な実装を任されながら育つエコシステムがあった

その「簡単な実装」こそが最もAIの得意領域になってしまった

未経験者が熟練者になるための梯子が、AIによって下から燃やされている

■ 3. 東大生の就活トレンドは5年遅れ

人気ランキングは常に5年遅れ:

東大生の就職先人気ランキングは、世間の最先端から常に5年遅れる

官僚、銀行、総合商社、コンサル、そして現在の外資ITやデータサイエンスがその系譜にあたる

押し寄せる頃には先行者利益が消える:

親や世間が「安泰で儲かるらしい」と認識し、学歴エリートが大挙して押し寄せる頃には先行者利益は狩り尽くされている

市場はすでに成熟化、あるいはレッドオーシャン化のフェーズに入っている

新設データサイエンス学部の危うさ:

一橋大学のSDSなど、近年雨後の筍のように新設されたデータサイエンス系学部は非常に悩ましい

彼らが社会に出る数年後には、データの前処理からモデル選定、基本的な可視化や分析までLLMが一瞬で終わらせる

「Pythonが書ける」「ちょっとデータがいじれる」程度のスキルは最も早くコモディティ化する

彼らが勝負しようとしている土俵は、すでに前提が崩壊しつつある

■ 4. AI時代に人間側へ残る4要素

物理（ハードウェア）:

AIがどれだけ賢くなっても、物理世界に干渉するにはハードウェアが要る

素材、半導体、ロボティクスなど手触りのある領域の価値は相対的に急騰する

ライセンス（国家資格）:

医師免許や弁護士資格などが該当する

AIが99%正確な診断を下せても、法的に責任を取るための「人間のハンコ」の価値は落ちない

むしろ参入障壁としてより強固になる

ネットワーク:

「何を言うか」がAIでコモディティ化する時代には、「誰を知っているか」「誰から信頼されているか」が決定的な価値を持つ

権威性（ブランド）:

LVMHに代表される血縁ブランドや、宗教、天皇家などが該当する

「非合理」で「AIによる効率化の対極」にあるものほど代替不可能な価値を持つ

■ 5. 推奨する進路

物理層の強い企業群:

今18歳なら、あるいは進路に迷う優秀な弟がいれば、素材・半導体・ハードウェアの企業群を迷わず勧める

医学部:

物理層（手技）とライセンスを兼ね備えた進路として推奨する

足場の置き場所:

情報空間の戦いは近い将来、AI同士が争うレッドオーシャンになる

物理世界や法的枠組みにしっかり足場を持つキャリアがこれから最強になる

■ 6. ポジショントークという留保

自らのポジショントーク性:

この文章自体が自分のポジショントークである可能性は否定しない

参入障壁を守るための発言という批判:

安全なポジションで高給を貰いながら、後進の参入を防ぐために「やめとけ」と言っているだけではないかと問われれば、完全な否定は難しい

先行者が後続の梯子を外すのは世の常である

退路確保ゆえの逆張りという批判:

すでに東大医学部というAIに代替されない退路を確保しているから余裕をかまして逆張りできる、という批判もまったくその通りである

それでも本物である肌寒さ:

毎日コードと最新モデルに向き合う中で背筋に感じている肌寒さは本物である

その肌寒さに耐えきれず医学部という物理層の保険をかけた事実がそれを証明している

情報系に飛び込む若者には、この構造的リスクを真っ向から理解した上で自分のカードを選んでほしい

(2026/08/18)

「日本のソフト文化が根本的に間違っている」元ＭＳ開発者が指摘、「デジタル敗戦」状態の原因は...

「日本のソフト文化が根本的に間違っている」元ＭＳ開発者が指摘、「デジタル敗戦」状態の原因は「多重下請け構造」 : 読売新聞

要約:

■ 1. デジタル敗戦の最大の原因

主要デジタルサービスの喪失:

基本ソフト(OS)、閲覧ソフト、クラウド、AIをすべて米国勢に取られた状態

この状態を「デジタル敗戦」と呼ぶ

根本原因はソフトウェア文化:

日本のソフトウェア文化が根本的に間違っていることが最大の原因

■ 2. エンジニアの地位の日米格差

日本のエンジニアは3K:

IT産業の人と話すと、プログラムを書くエンジニアの仕事はきつく、給料が安く、帰れない「3K」とみなされている

社会的地位も低い

米国のエンジニアは高待遇:

社会的地位は非常に高く、プロスポーツ選手やアーティストのように扱われる

優秀な人材は巨大IT企業から引っ張りだこで、億円単位の報酬を得ている人も多数存在する

■ 3. 多重下請け構造

地位低下の原因:

ITゼネコンと言われる大手IT企業を頂点とする多重下請け構造にエンジニアの地位が低い原因がある

丸投げの仕組み:

IT大手が大規模なシステム開発を請け負い、その企業のエンジニアが仕様書を書く

プログラムは下請けに丸投げする

下請けや孫請けのエンジニアが低賃金で大量のプログラムを書き、ソフトをIT大手に納品する

■ 4. 設計と実装の分離

日本は設計のみ:

IT大手のエンジニアはソフトの設計図を書くだけで、自らプログラムは書かない

米国は設計も実装も担当:

ソフトの設計もプログラムもエンジニアが手がけるのが当たり前

優秀なエンジニアほど設計と実装の両方を手がけている

料理をしない料理長:

日本は自分で料理をしない料理長が料理のレシピを書いている状況

自らプログラムを書かない者がいいソフトを設計できるわけがない

この図式があるが故に、日本はいいエンジニアが育たない構造になっている

■ 5. 20年以上放置された問題

指摘しても直らない:

こうした問題は20年以上前から指摘しているが、なかなか直らない

当事者であるITゼネコンが直す気がないことが理由

現在の開発力の弱さ:

多重下請け構造を温存し、エンジニアを軽んじたツケが今の日本のソフト開発力の弱さに表れている

■ 6. AI開発の遅れ

中国にも圧倒的な敗北:

AIの開発でも日本は後れを取っている

世界中から資金や人材が集まる米国に負けるのは仕方がない面もある

互角に戦えるはずの中国にも圧倒的に負けているのは悲しい

大学教育のぬるま湯:

優秀なエンジニアの育成で負けている面もある

日本の大学教育がぬるま湯的で、ハングリーさがなくなっていることも大きな原因

■ 7. AI敗戦への警告

個人と組織の乖離:

個人単位では米国で通用するような優秀な日本人エンジニアは存在する

組織となるとソフトやAIの重要性を理解していない日本企業が多く、そうした人材が活躍できる場がない

次はAI敗戦:

ソフトやAIの波を日本としてどう受け止め、対処するのかを真剣に考える必要がある

真剣に考えなければ、デジタル敗戦の次にAI敗戦が続くことになる

(2026/08/18)

ＯＳ持つマイクロソフト「ワード」が首位奪う、国産「一太郎」一気に転落…公取委の排除勧告も「遅すぎた」

ＯＳ持つマイクロソフト「ワード」が首位奪う、国産「一太郎」一気に転落…公取委の排除勧告も「遅すぎた」 : 読売新聞

要約:

■ 1. OSを持つ者の力

OS供給力を使った販売:

マイクロソフトがOSを供給する力を使ってワープロソフトを売れば、手も足も出ず勝てるわけがない

一太郎を開発、販売していたジャストシステムの当時の営業担当者、加藤彰の見方

メーカーが逆らえない構造:

各メーカーのパソコンには世界標準となったOS「ウィンドウズ」が搭載されている

ワードの搭載を拒めばウィンドウズを供給してもらえなくなるのではないかという懸念があった

基幹ソフトを握るマイクロソフトの意向にメーカーが逆らうのは難しい状況だった

OSを持つことの意味:

OSがないとパソコンが動かないため、マイクロソフトはメーカーにどんな条件でものませることができる

一太郎を開発したジャストシステム創業者、浮川初子の述懐

■ 2. 打つ手のない危機感

不合理だが対抗できず:

マイクロソフトのやり方は不合理だと初子は考えたが、打つ手はなかった

夫の浮川和宣は会社存亡の危機になるかもしれないと強い危機感を覚えた

■ 3. 抱き合わせによる首位交代

ワード初期搭載の働きかけ:

マイクロソフトがワードを初期搭載するよう日本のパソコンメーカーに働きかけた

一太郎は急速にシェアを落としていった

1997年度の首位奪取:

抱き合わせによりワードは一気にシェアを伸ばした

1997年度には5割超を占め、一太郎から首位の座を奪った

■ 4. ジャストシステムの業績悪化

売り上げの急落:

主力の一太郎のシェア低下により、ジャストシステムの売り上げは激しく落ち込んだ

数字の落ち方は尋常でなく、予想を上回る落ち込みが毎年続いた

98年3月期決算で赤字に転落

「狩猟民族」との実感:

OSもソフトも全て食い尽くしてしまう

営業の最前線でマイクロソフトと戦っていた加藤の受け止め

■ 5. 公正取引委員会の対応

立ち入り検査と排除勧告:

98年1月に独占禁止法違反容疑でマイクロソフト日本法人へ立ち入り検査を実施

98年11月にエクセルとワードを不当に抱き合わせて販売したとして独禁法違反で排除勧告を出した

遅すぎた結論:

排除勧告が出ても一太郎が失ったシェアが戻るわけではない

公取委の結論が出たのはもう勝負がついた後であり遅すぎたと和宣は考える

和宣は当局の動きの鈍さに今も不満を抱く

公取委現役幹部の認識:

いったんワードが普及してしまうと、そこから一太郎がひっくり返すのは難しい

もっと早く対応すべきだった

■ 6. デジタル敗戦の教訓

OSを持つ者の強大な力と、持たざる者の悲哀

動きの鈍い独禁当局

日本を代表する国産ソフトの凋落は、デジタル敗戦を喫した日本に様々な教訓を与えている

(2026/08/18)

ソフトウェアエンジニアリング入門

ソフトウェアエンジニアリング入門 - Speaker Deck

(2026/08/18)

警告：IT業界の変化を見据えて備えよう

警告：IT業界の変化を見据えて備えよう – 雑メモ

要約:

■ 1. 記事の趣旨

IT業界への警告:

2026年現在、生成AIは業界そのものを変化させる強い力として働く

該当業界内の人材は変化を見据えた動き方をすべき

想定するスパン:

2〜3年という短期間で発生する変化と役割変化を対象とする

■ 2. 業界の位相

業界単位の浮沈:

業界単位では、ある業界が別の業界に取って代わられる浮沈が発生する

時流により業界全体が沈下し、競合もろとも消滅する場合もある

参考文献は三品和広著「実践のための経営戦略論」

プレイヤーの入れ替わり:

実際にはプレイヤーがいつの間にか入れ替わる現象が発生している

銀塩フィルムの例:

銀塩フィルム業界はデジカメの登場により沈下した

利用者は便利になったと買い替えるだけだが、業界内では企業の衰退・撤退・破綻が発生していた

その他の入れ替わり事例:

乾電池から充電池、百貨店から大型スーパー・コンビニへの入れ替わりも業界単位で起こりうる

個人の努力の限界:

個人や一企業の努力ではどうにもならず、その業界にいるだけで危機に陥る

■ 3. 変化の要因と実例

変化の要因:

生成AIによるプログラミングをはじめとする各種IT関連業務の効率化・生産性向上

ここでの生産性はプログラムの作成量やテストの実行数、自動テスト作成量で捉える

著者自身の状況:

企業内スタートアップ的なプロダクトの拡張システムを、要件定義からひとりでの実装・テストまでこなしている

売上がじわじわ成長するため業務範囲は増え続けている

増員意欲の消失:

1〜2年前まではテスト要員や成長に応じた実装担当者の増員が必要と考えていた

現在は生成AIに頼ればなんとかなるとなり、追加人員が欲しいという気持ちは発生していない

世の中の事例:

実装やテスト実行、治具的なツール作成の範囲では情報過多ともいえるほど事例があふれている

プログラムにあまり触れない運用担当者に環境を用意し、自動テストや解析を任せる事例も見えている

■ 4. 2026年現在の到達点

増幅器としての生成AI:

うまく仕組みを構築すれば一部の業務範囲で成果物の作成速度を数倍にできる

ある程度の専門家が仕組みを作りフォローすることで生産性を数倍にする増幅器が得られた

対象となる業務範囲:

テスト設計から自動テスト実施、検出した問題の分析まで

仕様からユニットテストをセットでプログラミングする作業

開発やテスト・運用支援ツールの作成

非エンジニアの参入:

運用担当者などの非エンジニアが簡単なツールや自動テストの一部を作成するようになりつつある

顧客に直接提供するシステムは専門家が担当し、ログ解析や管理者支援、テスト補助のツールは非エンジニアが手を出せる領域となる

■ 5. ビジネスへの影響

売上は数倍にならない:

特定業務が数倍の生産性になっても、ほとんどの企業で売上が突如変わることはない

突如売上を数倍に増やした企業は見当たらない

多くのビジネスでは作っただけですべてが売れるわけではない

工数側の圧縮:

今まで10人・1か月で出していた成果を3〜5人・1か月で出せる領域ができた

■ 6. 変化の構造

前提となる構図:

需要側の事業会社が開発を求め、供給側の部署や企業がシステムの開発力・技術人材を提供する

需要側の内製化:

開発の難易度が下がるため、需要側は簡易なシステムやツールを自分で開発するようになる

高い信頼性が求められるシステムや顧客へサービス提供するシステムは、信頼できる部署・企業に継続して任される

需要量の飽和:

売れる量や必要とされるシステム開発の需要はいきなり数倍には増えない

開発の供給量だけが数倍になると過剰供給から需要が飽和する

開発量抑制のため工数削減の方向に進む可能性が高い

供給側の選別:

生成AIでは全員が生産性向上できるため、同一の工数で数倍の成果が求められる

競争原理により、同一工数で高い成果を謳う人や企業へ業務が移る

従来と変わらない生産量しか出さない人や企業、生成AIと変わらない信頼性のシステムしか生み出せない人や企業は徐々に選別される

■ 7. 予測される役割の変化

既存プレイヤーの選別と入れ替わり:

開発を供給する組織内の人や部署、外部委託先企業に選別と入れ替わりが発生する

縮小が見込まれる業務:

手の早さを特徴としPoC支援を提供する部署や企業

言われたままシステム開発を受け持つ部署や企業

これらは縮小・依頼量の削減へ進み、部署解散や事業撤退となる可能性がある

生産性向上の仕組みを作る人材:

業界が完全に変化するまで、各企業で生産性向上をする仕組みが求められる

生成AIを活用し組織の生産性を高める仕組みを作る人材・企業は貴重かつ必要とされる

クラウド移行時にインフラのベースとなる仕組みを作る人が求められた状況と近似する

これらの仕事をする人は高評価となり、高い賃金を得る役割となっていた

非エンジニアを開発側に寄せる役割:

開発の難易度が下がり、今まで開発に手を付けていなかった人が支援を受けて開発領域に入り込む

その支援を担う役割も求められると予想する

■ 8. 結論と注意事項

顕在化の時期:

この現象が具体的に見えてくるのは、需要側各社の来年度や再来年度の予算決定以降となる

明言しない事項:

どの業界が一番危険かまでは明言しないが、将来性が疑われる企業や部署はある程度予測できる

今後求められる存在も本記事では記載せず、読者自身が考えることを勧める

記事の限界:

2026年7月段階での検討内容であり、予想よりも大きな変化となる可能性がある

裏付けとなる数値までは用意していない

今後、業界でのシグナルを検知次第、追加で情報を出す考えである

(2026/08/17)

タブもテーマも拡張機能もないAI専用の超軽量ヘッドレスブラウザ「Kitesurf」、Cloudflareが発表

タブもテーマも拡張機能もないAI専用の超軽量ヘッドレスブラウザ「Kitesurf」、Cloudflareが発表－ Publickey

(2026/08/17)

シリコンバレーという答えから離れるとき

シリコンバレーという答えから離れるとき - 🐴 (馬)

要約:

■ 1. シリコンバレーという答えからの離脱

海外思想の流入:

海外のスタートアップやテクノロジーの思想が日本に次々と入ってきている

ピーター・ティールが現代アメリカを理解するキーパーソンだと繰り返し紹介されている

『テクノロジカル・リパブリック』が話題となり、国家とテクノロジー企業の関係についての論考も多く紹介されている

2010年代に輸入したもの:

シリコンバレーで語られる未来予測のナラティブ

先端的なエンジニアリングのプラクティス

リーンスタートアップ、デザイン思考、OKRといったビジネスの方法論

2020年代後半に入ってきているもの:

テクノ楽観主義、効果的加速主義、暗黒啓蒙といった思想群

国家、防衛、統治にかかわる事業

参照モデルの終わり:

2010年代のシリコンバレーは少し先の未来がある場所として扱われた

様々な事業は「シリコンバレーという答え」を参照し、その答えの中で使えるものを使う形で動いてきた

桁違いの資本を持ち中身も変質していくシリコンバレーを見ると、もうそれはできないし、そうすべきでもない

離脱の射程:

シリコンバレーの技術や事業から学ぶべきものは今も多く、これからも参照は続けるべき

そこで頑張る人たちを否定する気はなく、資本主義の競争から降りるべきでもない

立てられた問いと答えを一組で受け取り、そのコンセプトや事業を日本でも参照すべき答えとみなすことは難しくなりつつある

■ 2. 2010年代の前提の崩壊

経済と政治の再融合:

2010年代まで多くの事業体は思想を意識せずに済む自由市場で活動していた

経済と政治は基本的に分離されており、そうあるべきだと考えられてきた

その分離の前提には、自由市場とグローバリゼーションという新自由主義的な価値観が暗黙に共有されていた

前提が崩れた帰結:

前提が機能しなくなり、各国の内政が不安定になってきている

急進右派や急進左派と呼ばれる政治団体が台頭している

各国で産業政策や関税が採られ、政治と経済が再び融合しつつある

スタートアップという最前線:

市場構造の変化に伴い、国内外のスタートアップが注目する事業も移り変わり、防衛はその一種

スタートアップは海外の技術と資本の言葉を早く受け取り、「次に来る市場」として紹介する

投資と起業を通じて正統化する機能を持ち、その動きを感知する最前線にいる

2010年代に高まったスタートアップへの注目をうまく使い、国家や統治にかかわる思想やナラティブが日本へ入りつつある

これまではシリコンバレーの未来像から日本で使える技術や方法論を選べたため、問いを立てる必要は今ほど強く意識されていなかった

■ 3. 実業を伴って入ってくる思想

Palantirと『テクノロジカル・リパブリック』:

単なる事業でも単なる思想書でもない

著者の一人でCEOのアレックス・カープは、米国と同盟国が優位を保ち自由を維持するため、ソフトウェア産業が国家的課題へ向き直るべきだと論じる

その国家的課題にはAI開発競争が含まれる

カープはそのうえで日本を含む各国で事業を展開している

Palantirは2025年の米政府への政策提言で、自社の仕事を米国の国益とその文明を支えるものと位置づけた

同提言で米国がAIの国際的な議論と制度形成を主導すべきだと主張した

技術と事業という実体を持った思想:

従来のスタートアップシーンや思想シーンとは異なる形で流入している

安全保障をテーマに、哲学などの人文知・教養をまとった形で入り込みつつある

Palantir以外の担い手:

Palantir1社だけが特別というわけではない

a16zのAmerican Dynamismは防衛、公共安全、製造、教育など米国の国益に関わる領域を投資対象として明示している

そうしたVCから投資を受けたAndurilなども日本に入ってこようとしている

これは思想、企業、資本、国家政策が接続された動き

採用に伴う思想の同時流入:

表面的かつ第一義的には、どの技術やサービスを採用するかという問題

こうした事業群は「なぜそれをやるのか」という規範的な世界像から丸ごと束ねて供給されてくる

技術やサービスを採用すると、裏にある思想や統治の方法が調達や運用の前提として同時に入る

選別の必要性:

防衛力や抑止力の観点から採用せざるを得ない部分もある

その場合でも機能を選別し、どこまで受容しどこから拒否するかを価値基準に照らして考えなければならない

これらは日本の思想を実装へつなぐ回路の空白を突く形で入って来ており、油断すれば無自覚に全面受容しかねない

■ 4. 米国における思想・資本・政策の合流

問いを立てる組織の層:

米国では大学、政府研究費、財団、シンクタンクという問いを自分で立てる組織が国家と市場のあいだに確保された

それらが競争しながら思想を鍛え上げ、近年はVCの存在感が高まった

VCの基本機能:

将来像を投資テーゼへ変換する

それを物語として語ることで資本と人材を集め、配る

a16zの統合モデル:

資金配分に加え、メディアを持ち、本を出し、採用を支援し、政策へ働きかけることまで同じ組織に持ち込んだ

投資仮説を公開し、有望な創業者、専門人材、LP、共同投資家を特定の領域へ集める

投資先が属する市場そのものを形成しようとする

将来像の翻訳と資本の配分と発信が、同じ主体によってなされつつある

アベイラビリティ・カスケード:

マーク・アンドリーセンはクランとサンスティーンが提唱したこの概念で自らの発信戦略を説明している

ある話題は語る人が増えるほど重要で確からしく見え、それがさらに語る人を増やす

クランとサンスティーンはこの自己強化の仕掛け役を「アベイラビリティ・アントレプレナー」と呼ぶ

アンドリーセンはこの概念をスタートアップ創業者にも当てはめ、社会の注目の焦点そのものを設計しようとする

シリコンバレーからの未来予測の輸入は、日本がこのカスケードの下流に位置してきたことの一つの現れ

現在進行形の防衛テックの日本での受容もその一種

思想の資本主義化:

思想が先にあり資本がそれに従ったという単純な順序ではない

大きくなった資本は、リターンを得るために自分と同じサイズの大きな将来像やストーリーを必要とした

1兆円のファンドを作れば、時価総額10兆円や100兆円の規模になりうる事業とストーリーが要る

その結果、国家や人類規模の課題と接続せざるを得ない

思想が資本を動かしただけでなく、大きくなった資本もまた大きな思想を必要とするようになった

オリガーキーへの警告:

投資から政策関与までを少数の組織が担う現在の米国の状況は、この延長線上にある

バイデン大統領は退任演説でオリガーキー（寡頭制）が形成されつつあると警告した

米国VCの特異性:

a16zやティールは米国VCの平均ではない

他の国に、投資テーゼを超えた思想を書き広めるVCはほとんど見当たらない

VC全般が危険だと言いたいのではない

VC資金が一部の力を持つファンドへ集中する構造はあり、2025年には上位10ファンドが米国VC調達額の32.9%を占めた

特異なのは思想を資本の回路へ組み込み、その一部が膨張している米国のほう

実装力をまとう思想:

書かれた思想は大きな資本力を持ち、他の国の思想にはない実装の力をまとって入ってくる

米国では思想を書く人、資金を配る人、企業を作る人、製品を導入する人、政府へ政策を提案する人が接続している

「成功した創業者」という具体例があるからこそ、その思想は説得力を持つ

無批判な受容の危険:

米国の思想がすべて悪いわけではなく、問題はそれを日本が無批判に受け取ること

現在の米国のテクノロジー思想は、米国固有の政治、産業、安全保障上の問題への回答でもある

思想の受容とは、提示された答えだけでなく、その答えが前提とする問題設定、制度、優先順位まで取り込むこと

米国固有の問題への回答を前提ごと輸入すれば、日本の条件に合わない判断基準まで受け入れかねない

■ 5. 論評的受容の限界

2つの受容様式:

思想を理解し、位置づけ、批判して完結する受容が論評的受容

思想を自分の意思決定の前提に組み込む受容が実装的受容

同じ本を読んでも、書評を書くのが前者、投資テーゼや事業計画を書き換えるのが後者

日本の反応の現状:

ティールや加速主義への日本の反応は、書評、解説、警告という論評的受容でほぼ終わっている

これは能力の欠如ではなく、批評の伝統が育てた論評の能力の高さの現れ

論評で止められないもの:

論評は選別の第一歩であって、選別の軸そのものではない

「で、あなたはどうするのですか」という問いに、論評や分析はヒントを与えるが答えてはくれない

アベイラビリティ・カスケードの中では批判も語る人の一人に数えられ、話題の重要性を高める側に回りかねない

論評だけでは、注目と資本の動員も個々の導入判断も止めることは難しい

対案の不在:

選別には比較の対象が必要

入ってくる思想が答えようとする問題に自分たちならどう答えるかという対案があってはじめて、受け入れる部分と拒否する部分を判断できる

対案がなければ選別は成り立たず、丸ごと受け入れるか丸ごと拒否するかの二択に近づく

空白の所在:

日本には豊かな批評や思想の語り手がいる

その語りの多くは従来の批評や思想の領域にとどまり、技術、安全保障、産業の領域をまだほとんど覆えていない

出てきている担い手もごく少数にとどまる

空白なのは論評の能力ではなく、入ってくる思想と同じ土俵に立つ対案のほう

回路の空白がもたらすもの:

回路に載せるべき対案そのものが乏しい

対案を語る人と、調達し導入する人との接続もない

米国の思想は論壇で批判されるものの、現場では無自覚に実装されることが起こりえる

■ 6. 自前の問いと対案の構築

事業と政策が固まる前に示すこと:

思想の検討は、事業や導入の後に行う批評では足りない

何を作り、何を購入し、どの能力を国内に持ち、どの判断を外国企業へ委ねないかを事前に示す必要がある

論評にとどまらず、実体を持つ事業としての対案も増やしていく必要がある

担い手の広がり:

これは論壇だけの仕事でも、政府だけの仕事でもない

防衛やインフラの調達にかかわる組織は、海外製サービスのどの機能を受け入れどこから拒否するかの選別基準を導入前に持ち、議論する必要がある

対案となる事業を作ることで、価値基準の違いを分かりやすくできるかもしれない

問いを先に立てる:

米国から入ってくる答えを選別するだけでは足りない

日本側で、自分たちが直面している問題は何か、何を守り何を変えたいのかという問いを先に立てる必要がある

本来は社会保障などの問題を解くべきなのに、アベイラビリティ・カスケードで別のところへ過剰に注意が向けば、解くべき問題と資源配分を間違う

持つ問いを間違えば、その答えの有効性は激減する

問いを立てる力の育成:

自前の問いがあれば、海外から入ってくる技術や事業をその問いに従って評価できる

日本にとって何が問題かを決めるところまで米国側に委ねれば、日本側で問いを立てる力は育たない

シリコンバレーという答えから離れる意味:

シリコンバレーから学ぶことをやめることでも、米国の技術や思想を単にすべて拒否することでもない

そこで立てられた問いと答えを丸ごと受け取るのではなく、自分たちで問いを立てる

その答えの一部としてシリコンバレーの技術や思想を選び直し、それを活かして私たちの問題を解く

向かうべき方向:

論評的受容から実装的受容へ進むこと

回路の空白を日本側から埋めていくこと

日本の国家や産業の構想・思想が今必要であり、それは私たちが何者でありたいのかを考える機会ともなりうる

(2026/08/17)

なぜ日本はソフトウェアで後れを取っているか、答えは…元ＭＳ副社長「ハードを作らなくなったから」

なぜ日本はソフトウェアで後れを取っているか、答えは…元ＭＳ副社長「ハードを作らなくなったから」 : 読売新聞

要約:

■ 1. ソフトで後れを取った原因

ハード撤退が原因:

パソコンのハードとその中に入るソフトの両方を作ってきたからこそ言える

日本がソフトで後れを取っているのは、ハードを作らなくなったからだ

日本メーカーの製造撤退:

テレビもパソコンも以前は作っていたが、中国などとの価格競争に負けて作らなくなった

携帯電話は多くのメーカーが作っていたが、スマートフォンは作らなくなった

ハードとソフトの相互作用:

機器の能力が高まれば、それを生かしていいソフトができる

機器を作らないとソフトのことも分からなくなる

ものづくりとソフトの落差:

日本のものづくりの力は世界トップクラスだが、ソフトは普通のレベルだ

ハードを作る力を生かしてソフトの力も引き上げるべきだったが、日本メーカーは作らないことを選んだ

ゲーム分野の強さ:

任天堂やソニー系がゲーム機というハードを作っていることが日本の強さの理由だ

ソフトで負けないようにするにはハードを作り続ける必要がある

■ 2. 日米の技術者の質の差

半導体開発で痛感した差:

1980年代から90年代に国産半導体を開発する事業を手がけていた

その時に痛感したのが日本と米国の技術者の質の違いだ

専門知識の格差:

当時の米国の半導体企業では、コンピューター科学の博士号をもつ人材が半導体を設計していた

日本では大学卒業後にメーカーへ就職した技術者が設計を手がけており、専門知識に大きな差があった

技術者の数も圧倒的に不足しており、米国に到底太刀打ちできないと強く思った

学問的知識の軽視:

学問的な知識を軽視する日本の産業界の状況は今も変わっていない

2017年から東大の研究室で責任者を務め、学生に教える機会もあった

企業が博士号取得者を雇わないので博士課程まで進む学生が少なく、研究者の量がどんどん減っている

■ 3. 新しい大学の設立構想

危機感からの設立準備:

このままでは日本がさらに後れを取ってしまうという危機感を抱いた

世界で通用するソフトとものづくりの技術者を育てるため、新しい大学の設立に向けた準備を進めている

万能型を求める教育の弊害:

今の日本の教育は多くの科目を満遍なくできることを求めすぎている

技術という一芸に秀でた人材が埋もれてしまっている

本物の技術者の育成:

技術者としてパソコン産業の創造に挑戦したのは20代だった

新しい大学で、次の時代を担うような「本物の技術者」を育てたい

(2026/08/17)

「一太郎」に圧倒されていた「ワード」、マイクロソフトはエクセル人気を武器に「抱き合わせ」でシェア獲得

「一太郎」に圧倒されていた「ワード」、マイクロソフトはエクセル人気を武器に「抱き合わせ」でシェア獲得 : 読売新聞

要約:

■ 1. マイクロソフト本社の「一太郎部屋」

ゲイツへの表敬訪問:

1995年、ウィンドウズ95の発売を控えたマイクロソフトの米国本社での出来事

一太郎を開発、販売するジャストシステムの浮川和宣と初子が会長のビル・ゲイツを訪問

「一太郎部屋」の存在:

案内役の社員が2人を本社の一角の部屋に招き入れた

一太郎がインストールされた日本のパソコンが並び、棚には発売済みの一太郎のパッケージが置かれていた

ホワイトボードには一太郎の特徴が書かれているようだった

社員の説明:

一太郎を研究している部屋だと隠し立てもせずに説明し、2人の目の前で一太郎を動かしてみせた

和宣の受け止め:

ワードは世界では圧倒的に強いのに日本ではどうしても一太郎に勝てない

この部屋で研究し対抗しようとしているのだろうと考えた

■ 2. 日本市場におけるワードの劣勢

言葉の壁:

ワードは欧米では標準ソフトの座を勝ち取っていた

言葉の壁が立ちはだかる日本と韓国の市場は攻略できていなかった

94年度のシェア:

当時の公正取引委員会の資料や報道によると、ワープロソフト市場のシェアは一太郎が5割を占め首位

日本語の変換性能に優れた一太郎がマイクロソフトのワードを圧倒していた

ゲイツの認識:

日本市場の唯一のライバルはジャストシステムの一太郎だと語った

95年にOSのウィンドウズ95を発売すると、ワードの販売拡大に力を入れ始めた

■ 3. 初期搭載をめぐる攻防

店頭販売での劣勢:

量販店などの店頭販売では一太郎が圧倒的に優位に立っていた

初期搭載への着目:

マイクロソフトが目をつけたのは、パソコンメーカーとの契約で自社のソフトをまとめて初期搭載してもらうこと

多くのメーカーに初期搭載してもらえれば一気に販売数を稼ぐことができる

お株を奪う形での展開:

パソコンへの初期搭載を始めたのはジャストシステムが先で、一太郎のシェア拡大の原動力になっていた

マイクロソフトはそのお株を奪う形で、ワードを初期搭載するよう日本のパソコンメーカーに働きかけ始めた

■ 4. 抱き合わせ販売によるシェア獲得

富士通への要請:

公取委の資料によると、95年にマイクロソフトは富士通に対しエクセルとワードを併せて搭載するよう要請

富士通はワープロについては一太郎を搭載したいと伝えた

マイクロソフトは拒絶し、ワードの初期搭載を受け入れさせた

他メーカーへの波及:

以降、NECなど10社以上のパソコンメーカーがエクセルとワードを自社パソコンに初期搭載するようになる

エクセル人気の活用:

当時、エクセルは表計算ソフトでシェア首位

マイクロソフトはエクセル人気を武器に、パソコンメーカーにワードを抱き合わせ販売することでシェアを獲得していった

(2026/08/17)

マイクロソフトと「ウィンウィンの関係」だった国産「一太郎」…日本語の優れた変換能力で「ワードは...

マイクロソフトと「ウィンウィンの関係」だった国産「一太郎」…日本語の優れた変換能力で「ワードは敵ではない」ように見えた : 読売新聞

要約:

■ 1. OSを握る者がソフトを制す

一太郎からワードへの逆転:

一太郎は1980〜90年代に隆盛を誇った国民的ワープロソフト

日本を代表する国産ソフトがマイクロソフトのワードに逆転を許した

逆転の背景にあるウィンドウズ:

当時のOS市場の9割以上を握っていたとされるウィンドウズの存在が背景にある

■ 2. 一太郎の躍進

発売と累計出荷:

一太郎は1985年に発売された日本語のワープロソフト

発売と同時に爆発的に売れ始め、1997年にシリーズ累計出荷本数が1000万本を突破

国産ソフト初の快挙:

国産のパソコンソフトとしては初の1000万本突破

開発・販売を手がけるジャストシステムは日本一のソフトメーカーと呼ばれた

■ 3. ヒット要因としての日本語変換能力

優れた変換能力:

一太郎がヒットした要因は日本語の文章の優れた変換能力にある

長い文章を書いてもスペースキーを押すだけで単語などを自動で判定する

ひらがなを漢字と送りがなに高い精度で変換できる

当時としての画期性:

今でこそ珍しくない機能だが、当時は画期的な技術

パソコンでこうした変換ができるのは一太郎だけだった

■ 4. マイクロソフトとの共存共栄

相互依存の構造:

OSを提供するマイクロソフトと応用ソフトを提供するジャストシステムはもともと共存共栄の関係にあった

パソコンが普及していなかった時代、消費者はワープロソフトを使うためにパソコンを買った

一太郎が売れるほどパソコンに必要なOSも普及する

ジャストシステム側の依存:

マイクロソフトのOSがなければパソコン上で一太郎を動かせない

両社は互いになくてはならない存在だった

事前情報の提供:

創業者で元社長の浮川和宣によれば、新しいOSが出る前にマイクロソフトから早めに情報をもらっていた

発売に合わせて一太郎を供給できるようにしており、ウィンウィンの関係だった

■ 5. ワードの登場と競合認識の欠如

関係変化の起点:

両社の関係が少しずつ変わったのは、マイクロソフトが1990年代初めにワードを供給し始めてから

ワードはワープロソフト市場で一太郎と競合するソフトだった

ライバル視しなかった理由:

ジャストシステムは当時ワードをライバル視していなかった

英文用として開発されたワードは日本語の変換機能が十分でなかった

一太郎の人気を脅かすような性能ではなかった

開発者の実感:

一太郎を開発したプログラマーで浮川の妻の初子は、店頭の販売で戦ってもワードは強くなかったと語る

一太郎の方が圧倒的に性能が良く、ワードは敵ではないという感じだった

■ 6. ソフトバンクによる流通の支え

孫正義の関与:

一太郎の店頭販売はソフトの流通大手・日本ソフトバンク社長の孫正義が支えていた

新製品を出すと全国に流通してくれるのがソフトバンクであり、孫は一太郎をよく売ってくれたと初子は述べる

盤石に見えた地位:

国民的ワープロソフトの座は揺るぎないように見えた

(2026/08/17)

「米政府の怒り買った」と企業が手を引いた国産ＯＳ「トロン」の挫折…それでも世界中の家電・電子機器に今も

「米政府の怒り買った」と企業が手を引いた国産ＯＳ「トロン」の挫折…それでも世界中の家電・電子機器に今も : 読売新聞

要約:

■ 1. 日米貿易摩擦に巻き込まれたトロン

貿易障壁報告書での問題視:

米政府が「貿易障壁年次報告書」で国産OS「TRON」を問題視

突如として日米貿易摩擦に巻き込まれる事態となった

国内からの批判:

日本政府の「トロン優遇」に対しては国内からも批判の声が上がっていた

■ 2. 孫正義による批判

批判の急先鋒:

当時パソコンソフト流通大手・日本ソフトバンクの社長だった現ソフトバンクグループ社長の孫正義が急先鋒

批判の内容:

日本政府はトロンにばかり肩入れし、海外のコンピューター製品を締め出そうとしていると批判を展開

伝記本「孫正義　起業の若き獅子」によれば、関係者にトロンの危険性を説いて回った

通産省幹部への進言:

トロンが米通商代表部(USTR)の報告書でやり玉に挙げられると、これを口実に一気にトロンを潰した方がいいと通商産業省幹部に発言したとされる

■ 3. 学校向けパソコン標準仕様の断念

孫の思惑通りに進んだ事態:

報告書公表から約2か月後の1989年6月、学校向けパソコンの仕様を検討していた財団法人がトロンの標準仕様化を断念したと報じられた

米政府の報告書が引き金になったのは明らかだった

■ 4. 日本メーカーの撤退

スーパー301条は不適用:

結局、米政府がトロンに対しスーパー301条を適用することはなかった

メーカーの受け止めの相違:

トロンが米政府の怒りを買ったと受け取った日本メーカーは、トロンに関わることを恐れた

潮が引くように「トロンパソコン」の開発から手を引いていった

風評被害としての性質:

トロン自体が否定されたわけではなかったが、米国からケチがついたOSなど使えないという空気になった

坂村はこれを風評被害のようなものだったと述懐

■ 5. 摘まれたパソコンOSの芽

未確定だったOS競争:

当時のパソコン搭載OSはマイクロソフトのMS-DOSが主流だったが、どのOSが勝つかはまだ分からない状況だった

有力候補としてのトロン:

日本のパソコンメーカーはマイクロソフトの対抗馬となるOSを探しており、トロンはその有力候補だった

日米貿易摩擦に巻き込まれ、その芽は摘まれることになった

■ 6. 坂村への国際的評価

米政府高官からの誘い:

貿易摩擦を巡る騒動の後に面会した米政府高官から、日本でうまくいかなくなっているならいつでも米国に来てほしいと誘われた

坂村はそんなことにはなっていないと答えた

■ 7. 組み込みOSとしての成功

電子機器向けOSでの大成功:

パソコン向けOSでは挫折したものの、トロンは家電など電子機器向けのOSとして大成功した

採用事例:

任天堂のゲーム機「スイッチ」、ダイキン工業のエアコン、トヨタ自動車のエンジンなどに採用

今や世界にある数十億台の電子機器にトロンが使われていると言われる

一般の人の目には触れないが、トロンは今も世界中の製品で動いている

■ 8. 日本への示唆

グローバルでオープンな発想:

坂村のグローバルでオープンな発想が世界で受け入れられている

その事実は「デジタル敗戦」を味わった日本に多くの示唆を与えている

(2026/08/17)

国産ＯＳ「トロン」計画、突如アメリカの標的に「わけが分からなかった」…貿易摩擦の中で狂い始めた歯車

国産ＯＳ「トロン」計画、突如アメリカの標的に「わけが分からなかった」…貿易摩擦の中で狂い始めた歯車 : 読売新聞

要約:

■ 1. トロン搭載パソコンの試作

松下電器による試作機開発:

1987年、松下電器産業が新たなOS「TRON（トロン）」を搭載したパソコンの試作機開発に成功

松下電器産業は当時の社名であり、現在のパナソニックホールディングスに当たる

読売新聞の報道:

同年3月に「トロン計画前進　松下電器　国産OSパソコンを開発」との見出しで報じた

マイクロソフトの「MS-DOS」などがOSの国際標準となっている状況を説明

日本メーカーはそのOSに合わせてハード、ソフトを開発している

トロン計画の推進により、日本メーカーは国産OSによる世界的な標準化が進むことを望んでいる

実用化への期待の高まり:

試作機の登場をきっかけに、トロンはマイクロソフトに対抗する国産OSとして関係者の期待を集める

日本メーカーだけでなく米国メーカーもトロンパソコンを作り始めた

■ 2. 日米貿易摩擦による暗転

時代のうねりによる未来の暗転:

日米貿易摩擦という時代の大きなうねりがトロンの未来を暗転させることになる

USTRによる名指し:

89年4月公表の米通商代表部（USTR）「貿易障壁年次報告書」でトロンがやり玉に挙げられた

米国はトロンOSを支援するための日本政府の市場介入について懸念を抱いているとされた

トロンは日本政府から不公正に優遇されているという位置づけであった

スーパー301条の脅威:

米政府が不公正貿易の是正を目的に作った制度がスーパー301条である

報告書で取り上げられた分野はその適用候補となり、厳しい制裁措置が発動される恐れもあった

■ 3. 坂村の受け止め

寝耳に水の事態:

坂村にとって、この指摘は寝耳に水の話であった

理解できないという反応:

トロンは世界に公開しており、米国企業も自由に使える

なぜそれが貿易摩擦の対象になるのか、わけが分からなかった

■ 4. 米政府が問題視した中身

中学校向けパソコンの標準仕様:

当時、政府は全国の中学校に大量にパソコンを導入しようとしていた

その標準仕様がトロンに有利になっている点を米政府は問題視した

仕様検討の主体:

仕様は通商産業省と文部省が所管する財団法人が検討を進めていた

通商産業省は現在の経済産業省、文部省は現在の文部科学省に当たる

仕様がトロンに基づいた中身となることが有力視されていた

米側の懸念:

この仕様では、世界的なリーダーとして認められているマイクロソフトのOSなどトロン以外のOSが事実上調達から排除される

米政府は日本政府が国産のトロンを支援し、米国企業をのけ者にしようとしていると考えたようだった

■ 5. 背景にあった日本経済の勢い

バブル景気の絶頂:

当時の日本経済はバブル景気の絶頂期にあった

ジャパンマネーが世界を席巻していた

産業面での日本優位:

日本勢は自動車や半導体で米国勢を圧倒していた

脅威とみなされた可能性:

トロンもいずれ米国の脅威になる恐れがあるとみなされた可能性があった

■ 6. 狂い始めた歯車

突如標的とされたトロン:

トロンは突如として米国から標的にされた

この出来事をきっかけに、トロンパソコンの歯車は狂い始めていく

(2026/08/17)

Stop being skeptical about AI for development with Charity Majors

Stop being skeptical about AI for development with Charity Majors

要約:

■ 1. 経歴とHoneycombの原点

Linden LabからParseへ:

最初の職はLinden Labで、Second Lifeを開発

その後Parseでモバイル向けバックエンドを構築し、Facebookに買収された

買収の失敗から得たもの:

買収の大半は失敗し、Parseも例外なく閉鎖された

スタートアップ育ちで無名だったが、Facebookを離れる段階で投資家から声がかかり、Honeycombの創業につながった

Scubaによる原体験:

Parseでは100万を超えるモバイルアプリをホストし、毎週どれかが壊れる状況だった

原因特定は数時間から数週間かかる運任せの作業だったが、データをScubaに入れた途端に数クリックで解決した

Honeycomb創業の動機:

Scubaのない環境ではエンジニアとしての力が大きく落ちると痛感した

どうせ失敗するならGoで書いてオープンソース化し、どこへ行っても持ち運べるようにするつもりだった

■ 2. 個人の生産性の測定

測定できる次元と限界:

個人の生産性は一部の次元しか測れず、チームの状態や誰が要かは表れない

詳細に踏み込んでいる良いマネージャーやリードであれば実態は分かる

意見ではなくデータで裏づける:

分かっていても裏づけとなるデータが必要で、絵の中の一色のような部分的指標に頼ってはならない

グッドハートの法則があるため、単一指標を目標化してはならない

チームこそが重要:

個人のアウトプットを重視する流れが続いてきたが、依然として重要なのはチーム

AIがもたらす問い直し:

良いとは何か、生産性とは何か、より良いとは何かを早期かつ頻繁に問い直させる点はAIの利点

速度に真っ先に飛びついた事実は示唆的で、速さだけを「より良い」とするのは未熟な定義

速度偏重への疑問:

Spotifyが1日または1週あたり4500件の変更を出荷したと語る一方、品質や機能の良し悪しは語られていない

顧客がアプリのボタンの位置が常に動くことを望んでいるとは思えず、速度は最も測りやすいだけの指標

■ 3. 2025年のAI転換点

2025年はクラウドの2010年:

2025年3月のSREconではバイブコーディングを試すよう勧め、会場からうめき声が上がった

当時の売り込みは、AIを学べばより的確に文句を言えるという趣旨だった

転換点はモデルより harness:

当時はプログラミング言語より大きいがクラウド程度の機能拡張であり、世代交代ではないと見ていた

転換点は2025年11月のOpus 4.5だが、振り返れば7月頃から兆候があり、変化を起こしたのはモデルではなく harness とツール群

懐疑から転向へ:

今年前半、周囲の全員が再び試して考えを変えていった

考えを変える人を尊敬する

当初の懐疑は誤りではない:

AIが中央値のソフトウェアエンジニア並みにコードを書くという主張は、当時としては極めて特異な主張だった

ニューラルネット、COBOL、ノーコードやローコードなど、同種の約束は繰り返し裏切られてきた

あの時の懐疑は正しかったが、今回の懐疑は間違いだった

■ 4. 読んでいないコードの出荷

問題は「いつ」であって「もし」ではない:

自分が読んでいないコードを出荷するかという論点も、かつての懐疑と同じ経路をたどっている

5日後か5年後かは分からないが、方向としてはそこへ向かうことは明らか

信頼を成立させる条件:

変更内容が見え、ハーネスで検証済みだと分かる仕組みがあれば信頼できる

AI以前に「自分が保証する、叩き込んだ」と言うチームメンバーを信頼したのと同じ構図

数か月AIと並走して、どちらがどれだけ検出するかを比較し、訓練していく道もある

Phoenixアーキテクチャの前提:

イミュータブルインフラ、ステートレスサービス、コンテナ、ブルーグリーンデプロイ、コードとしてのインフラは、動くものを直さず置き換えるという前提を共有する

AIはその前提をインフラからアプリケーションコードへ拡張し、書き直しが安価になると、その場での編集がリスクになる

変更は entropy を蓄積するが、置き換えはそれをリセットする

ペットから家畜への移行の再来:

サーバーを個別に設定し修理していた時代は終わり、捨てて新しくする運用に移った

コードは60年以上にわたり編集する対象であり続けたが、経済性が同じ転換を迫る

生成が安価であることの帰結:

一度書くより速く、関数の変種を1万通り生成できる

そのため大量のevalとテストが必要になるが、生成の安さがその方向へ強く押し出す

ソフトウェアのコストは常に保守に紐づいており、信頼の根拠は本番で使い続けてきた実績にある

全面生成には慎重:

難しいデータベース移行を経験した者は、契約を外挿し保存する能力について謙虚であるべき

すべてのコードを生成すべきとは考えないが、今より遠くまで進めることは確実であり、それは良い変化

書き直しの痛みの実例:

ParseではRuby on RailsのAPIを6か月で書き、Goへの書き直しに2年を要した

当時のGoは未成熟でMongoDBドライバから自作する必要があり、型安全性のない環境も苦痛だった

ストラングラーフィグのように利用者との契約を一つずつ壊して発見する手法は理想的な成果物ではない

アーキテクチャ図をレビューし議論し、そこからコードを仕様どおり生成できるようにすべき

■ 5. OpsとQAへの再評価

行レベルのコードは理想的な成果物ではない:

レビュー対象としてのコード行は最適な単位ではなく、必要なツールはまだ存在しないが、着想の多くは既にある

その多くはOpsとQAという、ソフトウェアエンジニアリングが見下してきた二つの領域に由来する

OpsとQAの関心:

OpsとQAは常に「何であるか」に関心を持ち、ソフトウェアエンジニアリングは「どうあるべきか」に関心を持ってきた

OpsとQAは検証、正しさ、期待どおり動くか、そもそも動くかを問うてきた

本番は開発の一部:

リポジトリの中に世界が存在すると信じる態度は不可解で、実体は本番にある

ソフトウェアエンジニアに本番を見せない組織すらある

本番は開発の後に来るものではなく、開発の一段階

AIが押し進める方向:

AIは業界が長年必要としながら進めなかった方向へ規律を押し進めており、その点に強い期待を持つ

金曜日デプロイ論争:

「金曜日にデプロイするな」という主張が広まったが、CIとCDによって恐れずいつでもデプロイできる状態を目指すべき

UAT環境も不要であり、本番でテストすべき

マージすれば本番へ出るのが既定で、出さないためには列車を止める必要があるという状態が正しい

■ 6. コードレビューの再定義

人間の脳は検証に向かない:

コード生成は安価になり、人間側のボトルネックはレビューに移った

業界はレビューを増やし、ツールを改善する方向に押し進んでいる

レビューは過剰に多義的:

コードレビューは人により場所により意味が違いすぎ、多くの投影が起きている

レビュー不要と言うと、同僚と話したくない、ジュニアを指導したくないという意味に取られるが、それは事実ではない

残すべき部分:

これを自社のプロダクトに入れるかどうかを決める場としてのレビューは、人間が得意とする議論

メンタルモデルが一貫しているか、API設計はどうか、アーキテクチャはどうかという対話には価値がある

理想を言えばコードを書く前に話すべき議論

捨ててよい部分:

構文やバグを読み取る作業は悪ではないが、教育機会として最良でない限り価値は高くない

検証としてのレビューは優先度の最下位

ガードレールを整えていない穴を自分たちの時間で埋めているだけの場面が多い

■ 7. 非決定性システムと規律

非決定性はより多くの規律を要求する:

AIは規律も規律のなさも増幅する

コードを信頼できる成果物として扱うなら、人間が予測できる範囲のテストしか書けず、その水準は高くない

振る舞いのテスト、スモークテスト、性能テスト、負荷テスト、ファズテストなど、QA由来の手法が必要になる

信頼の口座:

コード生成から信頼を引き出すなら、その信頼はどこか別の場所で積み上げねばならない

AIを退屈にする:

AIという括りより、決定性システムと非決定性システムを共存させる問題として捉える方が有用

決定性は消えず、極めて価値が高い

非決定性のツールは振れ幅が大きいため、通路を掘り、囲い込み、超能力として使える領域に限定する必要がある

非決定性の実害:

HackerRankが外部委託した履歴書スコアリングは、同じ履歴書を100回評価すると66点から99点まで振れる

多くの企業は85点を基準にしており、採用支援を謳う道具が実質コイン投げだと判明した

AIがすべての用途に適した道具ではないと言えることが重要

■ 8. Honeycomb社内のAI規範

1年前は自社を信頼していなかった:

1年前にAIを使うべきと決めても、十分な知識がなかった

この1年で学びが進み、今は同僚が「この仕事にAIは不適切」と言えば信頼できる

良くなる前に一度悪くなる過程が必要

バーは全員に対して上がった:

強力な新しい道具を得たときに起きることであり、荒野をさまよう段階にあるが、さまよわなければ取り残される

バーを定義する唯一の方法はより良い結果であり、これは良いか、より良いかを問い続ける必要がある

ヒューマン・イン・ザ・ループではなくループの所有:

ループの内側にいるすべてのエージェントに何を許すかを制御することが本質

スロップは送るな:

自分が読んでいないものを他人に送ってはならない

作るのにかかった時間より読む時間の方が長いなら、それはスロップであり、相手に対する明確な不作法

何かを渡す行為は相手の時間と注意を要求する行為であり、中身を知らないまま渡せばコストを相手に転嫁することになる

自己認識の実践:

自分で調べずに人に質問しようとする瞬間、生成物をそのまま渡そうとする瞬間に気づくことが第一歩

新入社員が先輩の時間を尊重する作法を学ぶのと同じ構図

深く考えるために使う:

AIは考えずに済ますための近道にも、より深く厳密に考えるためにも使える

中核業務においては後者を求める

第二言語話者や神経多様性のある人の利用は尊重の範囲内であり、AI禁止ではなく互いに妥当な要求をすべきという話

品質と尊重の基準は既にあり、新しく作り直す必要はない

■ 9. 分断する二つの陣営

どちらも作り話ではない:

推進派も懐疑派も実際に恐ろしい傾向を見ており、悪化する現実の難題に取り組んでいる

推進派の見ている現実:

これは競争であり、快適圏の外へ出る必要があると強く意識している

他社がより速く動き、追いつき、追い越すのを見て、取り残される恐怖を抱えている

指数曲線の内側にいるという歴史的に稀な状況にあり、備えるのが賢明

懐疑派の見ている現実:

分断の境界はしばしばオンコール担当かどうかで引かれる

責任を負う側はメンタルモデルの融解、スロップ、積み上げた仕事の消失を目撃しており、終わりが見えない

AI利用が増えて以降、システムが著しく悪化しているという観測は本物

双方が少数派を自認する皮肉:

どちらの陣営も自分たちが少数で圧倒され抑圧されており、真実と勇気のために立っていると感じている

断絶の構造:

勝ちを見ている側はコストと結びつけないため、同僚を職を失うのが怖いだけの人間だと誤認する

オンコール側は勝ちの報告を信じられず、すべて捏造だと考える

静かな部分、つまり代償と後始末が語られていないことが原因

全体を語れという要請:

書き直しや真の toil の自動化など、目を見張る成果は実在し、誰も手放したがらない

勝ちと同時にコスト、割に合うのか、今何が起きているのかを必ず併せて語るべき

■ 10. 信頼性の悪化という実態

Metaでの深刻度ゼロの多発:

Metaは最高深刻度のSev0を追跡しており、この2か月ほどで異常な多発が起きている

InstagramやWhatsAppで信頼性を担う人員が削減されており、関連を否定できない

Metaがここまで悪化したのは10年近くぶり

業界全体の同時多発:

会議で話すと、VC出資企業や上場企業から同じ現象が起きていると告げられる

各社が自分たちだけの問題だと思い込んでいたが、実際には業界全体で起きている

Intercomの正直な公表:

Intercomは18か月にわたり信頼性とコード品質が低下したことを公表した

直近でようやく回復の兆しが見えているが、元の水準には戻っていない

都合の悪い部分を隠さずに出す姿勢が価値を持つ

Intercomの規律:

CTOは10年前から「出荷は会社の心拍」と語っており、Rubyモノリスを10分から15分間隔で1日数百回出荷している

AI以前に創業しながらAIネイティブへ移行した組織の到達点

■ 11. ソフトウェアはAIのキラーアプリ

論理と言語という共通性:

ソフトウェアは論理と言語でできており、AIも論理と言語でできている

そのためガードレール、チェック、検証を組み込めるが、生活の他の領域で同じことをする方法は分からない

他領域での検証困難:

幻覚を含む準備書面を提出した弁護士が訴えられているが、それを検証する手段がない

ソフトウェアには構造化データがあり、検証できる領域という強みがある

コンパイルの通るコードという優れた訓練データも存在する

コードと散文の非対称:

生成コードは自分でも書き得た水準に達する一方、自分の文体を指定した文章は自分では絶対に書かない代物になる

訓練データがあってなお散文は反復的で見分けがつく

ソフトウェアは目的のために単純化された言語であり、そこが最適な適用先

書くことは考えること:

文章生成の効率化に多くの時間を投じたが、書くことは紙の上で考えることであり近道はないと結論づけた

構造の相談やフィードバック取得には利用する

■ 12. 人間であることへの回帰

人間の価値は蓄積で決まる:

5年後の採用は対話の中で判断される形になり、思考と自己研鑽に費やした分だけ価値が高まる

思考をAIに外注してきた候補者は、その部分が空白になる

対面と人間性:

Slack上でエージェントと人間が延々と往復するのは不快で、対面の交流の方が豊か

機械を統べるのは自分たちであり、機械は自分たちに仕えるという前提を忘れてはならない

■ 13. DevOpsの成否

DevOpsが生まれた理由:

開発と運用が分断され、コードが壁越しに投げ込まれていた

半分がコードを書き、もう半分がそれを理解するという分断脳の構造は元来悪い発想

自分で運用しない限り自分の書いたコードは理解できない

半分の成功と半分の失敗:

運用担当がコードを書けるようになる波は成功し、コンピュータを扱う全員がコードを書くべき

ソフトウェアエンジニアが本番でコードを理解する波は成功度が低い

20年のDevOpsは、コードを書く人と本番のコードをつなぐ単一のフィードバックループの構築が本質であり、それは失敗した

関心の分離自体は健全:

誰かに全部をやらせることはできず、プラットフォームチームとプロダクト側の分離は良い切れ目

インフラ側は安定性と回復力に、アプリ側は全ユーザーの体験に向く

片方だけが成立する状態があり得るため、両者は分離可能

Anthropicも同じ構造:

Anthropicは白紙から始めながらクラウドプラットフォームチームと応用AIチームに分かれている

両者はソフトウェアエンジニアが不要になるかという基本問題への見解すら大きく異なる

プラットフォーム側は不要にならないと考え、応用側は起こり得ると考える

■ 14. 観測性の実践

三つの柱という説明の限界:

観測性はメトリクス、ログ、トレースの三本柱として説明されがち

メトリクスとログはシステムの排気であり、自社で書かず所有しない大量のサードパーティ製品から出続けるため無くならない

排気は安価な場所に置けばよく、量は多いが価値は高くない

王冠の宝石としての自社コード:

自社を自社たらしめるコードについては、テレメトリはプロダクト上の意思決定であるべき

結合組織ごと一度で保存すべきで、豊かなデータの価値は線形でも指数的でもなく組み合わせ的に増える

29個の属性を持つワイドイベントに30個目を足すと、その30個目は他のすべてより価値が高い

非決定性ソフトウェアでは挙動を事前に予測できないため、トレースの取得は明確な製品判断

自動計装の成熟:

OpenTelemetryを使うべきであり、一般的なパターンはすべてモデルが学習済み

計装しながら作る方が、計装しない場合より速くて容易になった

計装は開発者の意図の宣言であり、本番でその意図を確認する手段

かつての障壁:

メトリクスかログかトレースか例外かエラーかプロファイルか、カウンタかゲージか、カーディナリティはどうかと判断が連なり、実装時間を数倍に膨らませた

デプロイ後も名前をどう探し、どう表示し、どうダッシュボードを作るかという壁が残った

現在はこれらを開発環境の中に持ち込め、開発ループの一部にできる

スパンとタイムライン:

トレースは高機能なフィールドを持つ構造化ログであり、スパンはその全体の持続時間を構成する部分集合

ウェブの登場以来の基本単位はトランザクションだったが、AIの登場でそれが通用しなくなった

Honeycombはスパンの上に載るタイムラインを出荷した

監督エージェントが複数のエージェントを起動し、各々がAPIやストレージを呼び、数時間に及ぶ会話を俯瞰する用途に対応する

トレースのトレースという新しい構成要素が必要になった

エージェントとコンテキスト:

世の中には大量のごみデータがあり、従来型のテレメトリはコンテキストウィンドウをごみで埋めがち

最も重要なのはデータ間の関係であり、それが判断を助ける

あるAI SREスタートアップの報告では、実運用のエージェントは観測性データを迂回し、より豊かで無傷なテレメトリを求めて上流へ向かう

テストとevalの融合:

今後はテレメトリの観点からテストとevalが結び付くことに期待している

■ 15. 『Observability Engineering』第2版

全面書き直し:

初版は2019年から2021年に書かれ、執筆開始時と終了時で観測性の定義が変わってしまった

出来に満足して出したのではなく、これ以上続けられないという状態で出した

第2版は初版250ページに対し600ページで、内容はすべて新しい

構成:

全6部で、第1部は決定性システムと非決定性システムを同時に運用する意味を扱う

第2部と第3部は共著者による計装と理解の解説で、AIを使う場合と使わない場合の並行トラックがある

第4部と第5部はゲスト著者による事例と深掘りで、フロントエンドとモバイル、CI/CD、ClickHouseによる列指向ストレージ、FinnのKeshaによる反復的な観測性運用を収録

第6部の狙い:

当初3章の予定が全体の3分の1、200ページのリーダー向け観測性ガバナンス論になった

冒頭はCTOへの公開書簡で、AIの大目標はシステムを理解する能力に阻まれていると説く

バズワードを使わずシステム理論で語る内容で、ドネラ・メドウズを好む読者に向く

観測性の影響を財務向けに定量化する章、投資として扱う場合とコストセンターとして扱う場合の使い分けを扱う

権限なく大規模な変革を推進するスタッフ以上のエンジニア向けのゲスト章、内製か購入かオープンソースかを扱う章を含む

ベンダーとの関係:

最終章は「ベンダー提携の技術と科学」で、必要なソフトウェアをすべて自作できない前提から出発する

良い提携とはロードマップに影響力を持ち、相手からも信頼される関係

変革の多くは失敗するが、成功する場合は内部に信頼と信用を持つ人間が官僚制を切り裂いている

ベンダーの営業組織には最初から信頼がなく、互恵によって時間をかけて信頼を築く

最良の関係は互いの成功が自分の成功だと感じられる状態だが、これは稀であり、握手と対価の交換で終わる通常の関係でも問題ない

これらは AI 時代においても長く価値を保つ技能

■ 16. リーダーシップと事業

最も有効なリーダーの順序:

最も有効なのは、優しく思いやりのある人間であり、かつ有能な事業運営者

次に有効なのは、ひどい人間だが有能な事業運営者

その後にその他全員が続き、善良だが運営が雑で事業に弱い人は多い

Twitterを例にした論点:

Twitterは16年かけても事業を確立できず、それは誰の目にも明らかだった

X が良くなったか悪くなったかは議論できるが、20パーセントの人員で運営されている事実は議論できない

コアプロダクトのエンジニアは30人ほど、合計でも60人ほどで、以前は1700人いた

以前のエンジニアの仕事の上に成り立っている面はあるが、それが要点ではない

自ら基準を課す:

高い基準を自らに課し、効率的に作り、絶えず改善しなければ、誰かが外からそれを課しに来る

文化と規範と倫理観を自分たちで決めたいなら、まず事業で勝つ必要がある

DEIの後退から学んだこと:

2010年代の潤沢な資金が尽きた途端、各社がDEIプログラムを取り消した

もともと信じておらず人を懐柔していただけであり、これは非常に示唆的

善人であるだけでは足りず、人を思いやるリーダーは同じ職位のソシオパスより良い結果を出すが、それは事業に強い場合に限られる

■ 17. マネジメントの変化

全員が手を動かす時代:

リーダーも差分を出しPRを通す感覚を持つべきで、実装に関わるリーダーの方が優れているのは以前からの事実

拾い直すことがかつてなく容易になり、やらない言い訳がなくなった

チーム縮小への評価:

より広い範囲を所有できるなら、チームが小さくなること自体は良いこと

ただし他社がやっているから、魔法だから、レイヤーオフだからという理由でCEO主導で進む現状を懸念する

反マネジメント論への反論:

権力が時間とともにマネージャー側へ漂流し、マネージャーが過剰になる傾向があることは否定しない

官僚制では否と言うより諾と言う方が容易であり、定期的に権限をエンジニアへ戻す必要がある

それでも中間管理職は本質的に不可欠

マネージャーの本質的役割:

中間管理職の役割は意味づけと文脈の付与

タスクを割り当てられるだけの世界は望まず、それはAIにできる

何をしようとしているか、どうやろうとしているかを理解する人が必要

理解なしに感情的にも創造的にも協働的にも関与できず、その理解は築くのが難しく壊れやすく長続きしない

■ 18. 中間管理職とディレクターへの助言

一度ICに戻る:

望む方向でないと分かっていても、しばらくICに戻るのが戦術的に有効

履歴書にAIを載せる必要があり、それが得られない職場にいることは重大なキャリアリスク

経験の差は開き続ける:

AIエンジニアリングの経験を2、3年持つ人材の市場は史上最高の状態

未経験で職を失った人は誰も見込みを与えてくれず苦戦している

正しい状況ではないが現実であり、始めた人と未着手の人の差は時間とともに広がる

次の面接では必ず問われ、なければ落とされる

不安と興奮は同じもの:

ディレクターは管理職歴10年ほどの人が多く、技術変化への恐れを抱えている

不安と興奮は生理学的にほぼ同じで、違いは主体性の有無

波が来るのを待てば怯えるだけであり、波に向かって走るべき

マネージャーがICに戻ることは高く評価されるため、堂々と選び、自分の経験を語り広めるべき

■ 19. ジュニアエンジニア

価値の定量化という前提の欠落:

ジュニアの価値を測るのが難しいのは、そもそもどのエンジニアの価値も測れないから

若手は問題なくやれる:

高校生や大学生と日常的に話す友人によれば、彼らはソフトウェア開発ライフサイクルを知らないまま非常に多くの成果を出している

自分たちが思いつかなかった結論とやり方を持ち込むはずであり、必要なのは採用し機会を与えること

実例:

優秀なオープンソース貢献者を採用しようとしたら17歳だったという話が複数のスタートアップから出ている

インターンシップでもよく、たとえその人が定着しなくても経験を積ませること自体が双方にとって有益

大変化期の逆転:

iPhoneとAndroidの登場時、最も優れたiOSエンジニアは18歳や19歳の若者だった

2年後には22歳のスタッフエンジニアと40歳の新人という構図が生まれた

大きな変化のときは自ら主導することで専門家になれ、誰も何が正しいか知らないため止められることもない

■ 20. AI疲れへの向き合い方

疲れの種類を分ける:

スロップを受け取ることによる疲れ、誇大宣伝による疲れなど、種類が異なる

AnthropicやOpenAIのCEOが終末を語り続ける行為は doom trolling と呼ばれ、無責任に人々を不安にさせている

技術は従来、楽しさや生活の改善として語られたが、今は恐怖として語られ、家族までが怯えている

SNSはAIスロップ投稿ばかりで、そこから距離を置いている

主導権を取り戻す実験:

不満が普遍的である今こそ、主導権を取り戻す実験を提案する好機

AI生成のPR説明文をやめる、水曜日は誰もAIを使わない、1週間試すといった合意が例

変化が大きいため実験はかつてなく容易であり、リーダーは歓迎する

事前に報告せず、何がうまくいき何がうまくいかず何を学んだかを後から伝える形でよい

■ 21. 推薦書籍

『Catastrophe Ethics』:

著者は生命倫理学者のTravis Reederで、現代生活ではあらゆる選択に加担が伴うと説く

牛乳なら牛の苦痛、アーモンドミルクなら水、豆乳ならホルモンと、何を選んでも誰かを害する

問題が巨大すぎて個人の判断が無意味に思えるという緊張を扱う

功利主義など伝統的な倫理枠組みをたどり、どの処方も愚かな帰結に至ることを示す

神も主人もいないが相対主義ではなく、世界について学び、自分が何に引かれ何の苦しみに心が動くかを聞き取る必要がある

何が重要かは誰も教えてくれず、自分で決めるほかない

この内省は、演技的な怒りとは正反対の姿勢

『More Everything Forever』:

著者はサンフランシスコ在住のジャーナリストAdam Beckerで、哲学の学士と天体物理学の博士を持つ

AI宗教、シンギュラリティ、効果的利他主義、加速主義、無限成長主義を打ち砕く

指数関数的成長について唯一分かっているのは、S字曲線か崩壊のいずれかで必ず終わるということ

恒星系の獲得を語るオックスフォードの倫理学者たちの馬鹿馬鹿しさを乾いた笑いで描く

寿命延長に打ち込む人々を、父を恋しがる悲しい少年たちだと評しており、人類最古の恐怖である死への恐怖がそこに見える

(2026/08/16)

なぜ、ITの職場において低スキル者を排除することが成功のために重要だと誰も言わないのか？

なぜ、ITの職場において低スキル者を排除することが成功のために重要だと誰も言わないのか？

要約:

■ 1. 本稿における排除の定義

排除の意味:

高い認知負荷を伴う仕事に適性を満たさない人を置かないという配置上の判断

対象となる仕事は要件定義、設計、顧客折衝、品質判断、技術的意思決定、レビュー承認

人格の否定や社会からの追放とは別の話

低スキルの核心:

作業速度の遅さではなく、自己修正能力の欠如

自分の誤解を検知できない、指摘を吸収できない、分からないと言えない状態

この軸を先に定義するのは、排除の基準として実際に運用できるのがこの軸だけだから

書物と職場の断絶:

優秀な人だけを採るべきだという主張は海外の技術書や経営言説では定番

一般論として語ることと、目の前の同僚について語ることの間には深い断絶がある

幻想の危険:

チームワーク、育成、多様性、心理的安全性はいずれも本来大切なもの

そこに誰でも同じ仕事に参加できる、能力差は努力と支援で吸収できるという幻想が混ざると職場は静かに壊れる

能力不足の波及:

誤解したまま進める、曖昧な仕様をさらに曖昧にする、確認を怠るという形で組織全体に負債が発生する

低スキル者は生産性が低い人である以前に、周囲の生産性を下げる人になる

■ 2. 人数を足しても成果が足されない構造

労働集約型との性質の違い:

手順化された作業や定型的な検証では人数を増やせば処理量は増える

要件定義、設計、実装方針の決定、障害解析、認識合わせでは人数と成果が比例しない

理解の浅い人が増やす総量:

説明、確認、誤解の修正、厚いレビュー、会議が必要になる

本人の手直しだけでなく、その人が生んだ不確実性を周囲が吸収する必要が生じる

成果物の相互依存:

設計書、ソースコード、試験仕様、課題管理表、議事録、顧客説明資料は相互に依存している

要件の誤解は設計、実装、試験観点のずれを経てリリース後の障害につながる

チーム全体への影響:

低スキル者が一人入るだけでチーム全体の認知負荷が上がる

優秀な人は理解の補助、誤りの検知、手戻り防止、顧客や上司への説明を背負わされる

高度な知的作業では能力不足が周囲の成果を減らす方向に働く

■ 3. 問題の本質としての認知負債

作業が遅いだけの問題との区別:

遅いだけなら納期の余裕、作業範囲の限定、手順書の整備で対応できる場合がある

真の問題は理解の質が低く、誤解を検知できず、分からないと言えない人

認知負債の定義:

理解不足や判断ミスが周囲の理解、確認、修正、説明の負担として蓄積すること

技術的負債が開発速度を下げるように、認知負債は組織の判断速度と実行速度を下げる

無自覚な場合の厄介さ:

理解したふりをし、仕様の前提を確認せず、指摘を表面的に直して同じミスを繰り返す

周囲は成果物だけでなくその人の認識そのものを監視しなければならなくなる

発覚の遅さ:

ソースコードの誤りは差分で見えるが、要件理解の誤りはすぐには見えない

設計意図の誤解は後工程で発覚し、顧客との認識齟齬は議事録に残らないこともある

負債の移転:

優秀な人は誤りを見抜けるため放置できず、責任感のある人ほど穴を埋めようとする

包摂しているように見える職場は、優秀な人と真面目な人に負債を移転しているだけ

■ 4. 決定的な軸は自己修正能力

技術知識や経験年数は決定的でない:

技術力が高くても、説明を怠り属人化を放置し指摘を撥ねつける人は同じ負債を生む

過剰設計で周囲の理解を阻む人も同様

理解が遅くても指摘を吸収し誤解を申告する人は負債をほとんど生まない

自己修正能力の内容:

自分の理解と現実のずれを検知できるか

指摘に防衛でなく吸収で応じられるか

分からない状態を分からないと申告できるか

誤りの滞留時間:

この能力がある人の誤りは早期に収束し、ない人の誤りは組織の中を伝播する

認知負債の量を決めるのは誤りの量よりも誤りの滞留時間

世間のスキル観との差:

技術に詳しい認知負債発生源も、経験の浅い優良な学習者も存在する

重要工程から外すべきなのはこの軸で低い人

■ 5. 観測可能な兆候による判定

実行可能性への疑問:

認知負債は後工程で発覚し進捗表にも現れないため、事前に見抜けるのかという疑問が返る

この疑問に答えられない排除論は実行不能な正論にとどまる

損害は遅く兆候は早い:

指摘に防衛で返すか吸収で返すか、同じ誤りを繰り返すか減らすか

質問をするかしないまま進めるか、分からないと言えるか言えないか

これらは数週間の単位で観測できる事実

予言でなく観測:

配置判断は将来の損害を予言する行為である必要がない

指摘への反応、誤りの反復、申告の有無という記録は印象論と違って突き合わせが可能

内面に依存しない基準:

自分には見えるという自己申告は、誰がしてもそれ自体では根拠にならない

価値があるのは見える側を自称することでなく、兆候を記録し突き合わせること

■ 6. 育成と重要工程への投入の分離

両者は別問題:

人は育てるべきだが、育てるために重要工程を壊してよいわけではない

影響範囲の制御:

学習機会は影響範囲を制御したうえで与えるべき

いきなり要件定義の主担当、顧客折衝、レビュー承認者にするのは育成の名を借りたリスク移転

小さな作業を任せ、フィードバックを与え、理解を確認し、徐々に責任範囲を広げる

実戦で育てるという言い分:

その実戦の損失は多くの場合、顧客と後工程と優秀なメンバーに押しつけられる

兆候は育成投資の基準:

指摘を吸収し同じミスを減らし、分からないと言える人は育つ

指摘を防衛で返し、誤解を検知できず、説明を受けても同じ地点に戻る人は育成コストが膨大

区別なき育成論の不誠実さ:

本当に育てたいなら重要工程と学習工程を分けるべき

育成の名目で重要工程を壊すことは本人にも周囲にもよくない

■ 7. 頭のいい人が語らない理由

最大の理由は角が立つこと:

単なる臆病さではなく、言ったときに何が起きるかを理解している

予想される反応:

冷酷な人間だと思われ、育成放棄と受け取られ、多様性の否定に見られる

パワハラ的だと受け止められ、上司や人事から扱いにくい人間だと思われることもある

後始末の押しつけ:

どう育てるのか、どう配置するのか、本人にどう伝えるのかが指摘した側に返る

現実を指摘しただけで面倒な調整役にされてしまう

戦略的沈黙:

本当のことを言っても組織が正しく動くとは限らない

黙って自分の仕事をする、危険な人に重要な仕事を渡さない、裏でリスクを吸収する、転職するという選択に至る

■ 8. 低スキル者が認めない理由

非対称性:

能力の高い人は構造が見えているため沈黙の理由が角が立つことに収束する

能力の低い人は構造が見えていないこと自体が問題の一部であり理由が多岐に分岐する

排除される恐れ:

自分の居場所を脅かす主張であるため道徳的な言葉で反論する

助け合うべき、切り捨ててはいけないという形で職務適性の問題を倫理の問題にすり替える

被害の未経験:

高度な仕事を経験しておらず、要件の齟齬や設計の破綻が組織を壊す感覚が分かりにくい

理解不足の非検知:

本気で分かっているつもりであるため、厳しく指摘する人を冷たい人だと感じ議論が成立しない

沈黙の質の違い:

正しく理解している人の沈黙は戦略に近く、理解できていない人の沈黙は状態に近い

誰が見えているかは指摘への反応と誤りの反復という観測可能な事実で判定できる

■ 9. 管理者が語りたがらない理由

自らの失敗の承認になる:

低スキル者が重要工程にいることは、誰かが採用し、配置し、任せ、評価した結果

認めることは採用、配置、評価、契約管理の失敗を認めること

責任の曖昧化:

本人に努力を求め、周囲に支援を求める

コミュニケーション不足や資料の整備不足の話にして根本の配置問題を避ける

見えやすい指標への依存:

現場の複雑さを理解できない管理者ほど人数、稼働率、進捗率に頼る

認知負債は進捗表に出にくく、見抜けないまま、できる人に負担が集中する

眼力でなく意思:

指摘への反応と誤りの反復の記録を見ることは高度な認知能力を要求しない

見抜く力の不足は記録を見る作業で補える

先送りの構造:

配置転換には本人への説明、顧客調整、契約処理、チーム内の感情処理が伴う

面倒を避けたい管理者はもう少し様子を見ようと先送りし、その間に生産性が落ちる

■ 10. 人事語彙による現実の隠蔽

語彙の本義:

多様性は視点と背景の構成の話であり、職務適性の免除規定として使われた瞬間に機能を失う

心理的安全性は率直な指摘を可能にする条件であり、指摘しない口実に使われると自己矛盾に陥る

チームワークは相互に信頼できる成果物の上に成立し、負債の固定的な移転とは別物

すり替えの典型:

外すべき場面でも支援が足りない、仕組みで解決すべきだという話に変わる

仕組みで吸収できる能力差には限界がある

標準化の限界:

ITには標準化が有効な領域と、個人の理解力が決定的に重要な領域がある

区別せずすべてを仕組みで解決しようとすると仕組み自体が複雑化する

低スキル者のための手順、チェックリスト、会議、承認フローが組織全体の速度を下げる

語彙の両義性:

人事語彙は適切に使えば職場をよくする

現実を直視しないために使われると職場破壊の言い訳になる

■ 11. 美談がもたらす誤り

一人の手という美談:

本田路津子のフォークソングが語る、一人ではできないことも皆でならできるという考え方

社会倫理としては大切であり、弱い人を支える仕組みも必要

重要工程への持ち込みの誤り:

職場の協力は能力差を無限に吸収する魔法とは違う

協力の成立には最低限の理解力、責任感、自己修正能力が必要

同じチームで働くとは、同じ前提を理解し同じ目的に向かい互いの成果物を信頼できる状態

協力でなく一方的補助:

前提を満たさない人がいる場合に成立するのは協力でなく周囲による一方的な補助

負担の所在の不可視化:

みんなで支えようという言葉は優しく聞こえるが、支える側と支えられる側が固定される

できる人が説明し確認し修正し責任を取る状態を放置すると職場は公平でなくなる

本当の協力:

その人に合った仕事を与え、学習可能な範囲で育て、重要な判断は適性のある人に任せること

社会的包摂と職務上の配置制限は両立する

■ 12. 排除しない職場では優秀な人が去る

最初に壊れるもの:

成果物ではなく、優秀な人と真面目な人の意欲

優秀な人は他人の誤りの検知、修正、説明を背負い、真面目な人は余計な責任を負う

組織がチームで支えていると言う一方で、できる人ほど損をする構造になる

離脱の過程:

優秀な人は沈黙し、自分の担当範囲だけを守るようになり、やがてよりよい職場へ移る

残るのは問題に気づかない人、気づいても動かない人、負債を押しつけられて疲弊した人

排除しないことは優しい選択に見えて、優秀な人を排除しているのと同じ結果を生む

本人への憎悪の否定:

問題は職務に合わない人を重要な場所に置き続ける配置の失敗

できない仕事を任され成果を出せない本人もある意味では被害者

排除は冷酷さでなく職場設計の責任であり、任せてよい仕事と任せてはいけない仕事を分ける

■ 13. 書棚と会議室の距離

活字での既出:

ジョエル・スポルスキの「Joel On Software」は優秀な人だけを採るべきだと公然と主張した本

海外の技術書や経営言説ではこの種の主張が繰り返し語られてきた

それでも日本の職場の会議室では誰も言わない

経験による裏づけ:

新人の頃に読むと少し極端に見え、半信半疑になるのは自然

顧客に怒られ、仕様の誤解や手戻りや後始末を経験すると、思想でなく経験則だったと分かる

経験が教えるもの:

人を見下す快感とは無縁のもの

苦労して伸びる人と同じ地点を回る人、指摘を吸収する人と防衛だけする人の違い

教えられるのは誰が下かでなく、自己修正能力の兆候の見分け方そのもの

固有名詞の壁:

活字が一般論として教えたことを、経験が固有名詞つきで裏づける

その固有名詞について職場で語ることだけは誰にもできない

■ 14. 語られないからこそ重大

沈黙の理由:

言う側に利益が少なく、言われる側に不利益が大きい

管理者に責任が返り、人事語彙とも相性が悪い

補助輪としての管理強化:

外せない職場では標準化、会議、チェックリスト、進捗管理、報告資料が増える

管理の高度化に見えて、低スキル者を重要工程に置き続けるための補助輪である場合がある

低い水準への平準化:

標準化や手順化そのものは非競争領域や定型作業で有効

能力不足を隠すための標準化は職場全体を低い水準に合わせる

優秀な人は余計な手続きに縛られ、低スキル者は本質を理解しないまま手順をなぞる

難度と能力の対応:

高度な抽象化が必要な仕事にはそれができる人を置く

学習中の人には影響範囲を制御した仕事を与える

自己修正の兆候が見えない人には重要工程を任せない

歪みの帰結:

理解力の低い人を重要な場所に置くと、成果物の品質だけでなく組織の認識そのものが歪む

人が増えても進まない職場、会議ばかり増える職場、優秀な人ほど疲れる職場はこの問題を抱えている

■ 15. 結論

職務適性の問題:

低スキル者を重要工程から排除することは職場づくりのかなり重要な条件

人は社会から排除されるべきではないが、すべての人がすべての職務に参加できるわけでもない

定義と判定の要点:

低スキルとは自己修正能力の欠如であり、誤解を検知できず指摘を防衛で返し同じ地点に戻り続ける状態

損害は後工程まで見えなくても兆候は最初のレビューから見える

排除の判断は予言である必要がなく、記録された兆候の突き合わせで足り、育成投資の基準にもなる

沈黙の三層:

頭のいい人は角が立つことを理解して黙る

低スキル者は恐れや経験不足や認知不足から認めない

管理者は自らの配置の失敗を認めたくないために避ける

人事語彙と美談が職務適性の問題を道徳の話にすり替える

必要な職場設計:

職場は美談では動かず、ITの仕事は人数でなく理解の質によって進む

協力には最低限の能力が必要であり、育成のために重要工程を壊すことは許されない

心理的安全性は低品質な仕事の見逃しを意味しない

重要工程には適性のある人を置き、低スキル者には影響範囲を制御した仕事を与え、育つ兆候のある人には育成機会を与える

前提を認める意義:

言えば角が立つ現実ほど組織の根本に関わる

判断を避け続ける職場は優しさを装いながら、できる人に負債を押しつけ、最後には顧客と組織自身が損をする

この厳しい前提を認めて初めて、育成も協力も標準化も心理的安全性も本来の意味を持つ

(2026/08/16)

マネージメントの極意

マネージメントの極意｜nekokak

要約:

■ 1. 背景

LayerXでの1年7ヶ月:

AI Workforce事業部のCPOを務めている

とても良いチームが作れたと強く感じている

DeNA時代からのマネージメント経験:

Mobage OpenPlatformの開発マネージャーからCTOまでを経験

様々な規模・領域の組織立ち上げを経験してきた

記事の目的:

組織づくりで大切にしていることを一つアウトプットする

■ 2. 求心力

求心力とは:

リーダーを中心にチーム全員が向かうべき目標を明らかにし、全員が力のベクトルを合わせて前に進む状態

明確な目標設定とコミットメント:

リーダーが明確な目標を示し、自らコミットメントを発揮することが必要

朝令暮改の弊害:

言っていることが次の瞬間に変わる状態は求心力を損なう

目標の正しさより明確さ:

目標が間違っていても、明確な目標設定とコミットメントが発揮されればメンバーはそれに向かって邁進できる

チームの一体感と目標に向かう力強い推進力が得られる

求心力の欠如がもたらすもの:

優秀なメンバーが揃っていても、求心力がなければ成果は出ない

■ 3. 遠心力

遠心力とは:

それぞれの役割にオーナーシップを持ち、中心的なリーダーに依存せずにモノゴトが進められる状態

メンバー個々のリーダーシップ:

メンバーがそれぞれの役割・領域においてリーダーシップを発揮する必要がある

アサインされたプロジェクトでリーダーシップを発揮させることで実現する

遠心力単独の限界:

目的とズレた方向に進んだ時に軌道修正できずに破綻する

■ 4. 求心力と遠心力のバランス

片方だけでは強い組織にならない:

短期的に成果を得ることはできても、長く成果を上げ続ける組織にはならない

求心力に偏ったワンマン体質の弊害:

短期的な突破力は極めて強いが組織が成長しない

事業規模が大きくなった時にスケールできず、長い踊り場に立たされる

遠心力に偏った組織の弊害:

目的からのズレを軌道修正できず破綻する

バランスの調整:

両者のバランスを取ることがマネージメントの重要な役割

■ 5. 求心力と遠心力を発揮するための下準備

前提としてのロジックと準備:

求心力と遠心力を発揮するには、それなりのロジックや下準備が必要

事業連動型の組織設計:

組織は事業を成功させるための組織である

組織設計は事業達成に紐づいていなければならない

多時間軸での目標管理:

ド短期、短期、中長期で区分して考える

近い目標と遠い目標を両睨みする必要がある

事業計画と連動した人員計画:

人員計画・組織設計は事業計画と連動している必要がある

理想の組織ばかり考えると事業計画を無視した計画ができあがってしまう

組織構築に要する時間:

個人的なベンチマークとして大体1.5年はかかる

自身も1年ほどかけて必死に組織をつくってきた

採用の重要性:

採用は超重要である

個としての能力の高さだけでなく、組織としてその人の能力を発揮できるかを考慮する

■ 6. 現状と根本原則

AI Workforce事業の難しさ:

不確実性があり中々難しい領域だが、全力で向き合えている状態はとても心地よい

現在の組織状態:

求心力と遠心力のバランスが取れた状態で成果を上げられる組織になってきた

事業部CPOとしてプロダクト戦略を示し、メンバーがリーダーシップを発揮する構図ができている

本質的に何を達成したいのかという問い:

すべての出発点として、この問いを必ず自分にするとよい

(2026/08/16)

概念設計が、その後のコードの命運を左右する

概念設計が、その後のコードの命運を左右する

要約:

■ 1. 概念設計の位置づけ

概念設計とは:

そのアプリケーションの世界にそもそも何が存在するのかを定めること

何と何を同じものとして扱い、何と何を別のものとして扱うのかという判断

上流工程の基本設計とは別物:

クラスをきれいに分けるとかDDDを導入するといった話より少し手前にある内容

UML図など所与の要件を実装へ落とし込む設計技法とは異なる

判断の当否が決めるもの:

判断が合っていると、その後の実装は驚くほど素直になる

外すと一つ一つの実装が正しくても、仕様が増えるたびに少しずつ帳尻合わせが必要になる

執筆の動機:

概念の整理がなぜどのように重要なのかという一点を取り上げた文章や書籍が見つからなかった

■ 2. Acme社のECサイト: 第一の世界線

初期モデル:

OrderがproductId、quantity、unitPrice、shippingStatusを持つ

注文の明細を表すと同時に、その商品の配送状態も保持する

本稿では簡単のため、一商品の注文明細をOrderと呼ぶ（通常はOrderLineと命名される）

配送中の破損という出来事:

カスタマーサポートから同じ商品をもう一つ送ってほしいと連絡が来る

quantityを2にしてはいけない、顧客が買ったのは1個であるため

0円のOrderという回避策:

quantity 1、unitPrice 0のOrderをもう1つ作れば動く

しかし妙な存在が生まれ、購入とは呼べないデータが注文データに混ざる

妙な存在が生む疑問:

顧客がその商品を二個購入したといえるのか、購入点数に数えるのか

売上集計では除外するのか、返品処理ではどうするのか

ユーザーの購買行動によって生まれたデータではないのに注文データに混ざっている

後から推薦システムを作る場合、このレコードはノイズになりかねない

帳尻合わせの連鎖:

モニタリングではunitPrice 0のレコードを除外し、売上にもカウントしない

コストには関わるため、配送件数の集計ではカウントする

推薦システムでは0円のOrderを学習データから外すよう申し送る

これから関係するコードや運用のあちこちで、処理ルールを決めて少しずつ帳尻を合わせることになる

■ 3. 第二の世界線: OrderとFulfillmentの分離

概念の分割:

何をいくつ、いくらで買ったかをOrderと名付ける

その約束をどう履行したかをFulfillmentと名付ける

注文とその履行は別々の概念であると認識し、区別する

モデル:

OrderはproductId、quantity、unitPriceのみを持つ

FulfillmentはorderId、quantity、statusを持ち、statusにはfailedを含む

再送への対応:

最初のFulfillmentは破損したという事実をfailedとして残す

もう一度届けるためのFulfillmentを1つ作れば、状況をありのまま表現できる

得られる帰結:

再送対応のために0円の注文を無理やり作る必要がない

モニタリングにおかしな条件分岐も要らない

売上はOrderを見ればよく、配送コストはFulfillmentを見ればよい

推薦システムは実際の購買行動を反映するOrderに対して学習すればよい

何年後の開発者にも通じる:

この0円注文は実は注文ではないという事情を未来の開発者へ申し送る必要がない

OrderとFulfillmentを同じ意味のデータとして扱う理由がない

推薦の学習データに両者を混ぜる理由がそもそもなく、混ぜることの説明がつかない

二つの世界線の違い:

再配送機能の実装力の差ではない

システムの中に何という概念を置いたか、現実の出来事をどういう概念で捉えたかの違いである

現実の出来事の単純さ:

受注担当が1個の注文を受け、1回目の配送で破損が起き、配送担当が2回届けただけである

第一の世界線でコードやルールが複雑化したのは、Orderに二つの意味を背負わせていたためである

対応が自然であることの価値:

第二の世界線は再配送という新機能をうまく実装したわけではない

最初から売買と履行を別のものとして認識していたため、Fulfillmentを1つ増やすだけで済む

急場凌ぎではなく、これしかないという当たり前の対応方法である

だからその対応のツケが後のコードや運用へ波及しない

■ 4. 未来の仕様が先に実装済み

分割発送の要望:

物流チームから、3個注文された商品のうち1個だけ先に発送したいと要望が来る

残り2個は入荷してから発送する

ユーザーが注文した数量は3個のまま、届けるタイミングだけが二つに分かれる

コード変更が不要:

quantity 1のFulfillmentとquantity 2のFulfillmentを持たせるだけでよい

Orderに分割発送モードという状態を追加する必要はない

partiallyShipped = trueのようなフラグも要らない

すでにある機能だけで、何ら不自然さもなく運用を始められる

予測ではなく認識の結果:

分割発送は当初の仕様になく、Fulfillmentも将来の分割発送を予測して導入されたわけではない

注文の履行という概念が存在すると認識し、その概念として自然な形に実装しただけである

その結果、まったく別の理由から後日やってきた仕様まで最初からモデルの中で実現されていた

偶然ではない理由:

人が思いつく仕様は、その人が現実をどう認識しているかというメンタルモデルの範囲内で自然なものになる

コードが表現する概念が現実の捉え方と噛み合っていれば、後の自然な仕様が既存の概念に収まるのは当然の帰結である

新規コードの不要化:

新しいコードをほとんど書かず、既存の概念をそのまま使うだけで対応できることすらある

まるで最初からその使い方を見越していたかのようになる

■ 5. バグが生まれる前に消える

概念分離の第二の効果:

適切な概念設計がもたらすものは未来の仕様追加・変更への強さだけではない

概念を正しく切り分けると、注意して防ぐ必要があったバグがそもそも発生しにくくなる

第一の世界線での集計事故:

ordersのquantityを合計するというごく自然なクエリに交換品まで含まれてしまう

unit_price > 0という条件も危うい

クーポンやキャンペーンによる本物の0円購入が将来現れれば、正しい購入まで消えてしまう

本質的な問題:

条件式が足りないことではなく、購入ではないものがOrderとして存在していることである

システムのあちこちで本物のOrderだけを選ぶ方法を覚えておかなければならなくなる

推薦でも分析でも返品でも、新しく加わるコードのたびに同じ注意が必要になる

分離後の集計:

ordersのquantity合計は、そのまま購入数量を意味する

再配送を何回してもOrderは増えない

fulfillmentsのquantity合計は、実際に履行された数量を意味する

ルール遵守に依存しない仕組み:

交換品は売上から除外するというルールを全員が正しく守っているのではない

Fulfillmentにはそもそも顧客がいくらで買ったかという意味を持たせない

交換品という配送上の出来事が、売買を表す場所に入り込まない

注意力への非依存:

正しさを後続コードを書く人の注意力に委ねなくてよくなる

バグを予防したり検知したりするまでもなく、そもそもバグの存在余地を減らせる

■ 6. 概念テスト

概念は新機能を考える道具になる:

概念がうまく定まると、実装時だけでなく新しい機能を考えるときの道具にもなる

新しい要望をすぐに画面やAPIやデータベースの話へ落とさない

まず、いまシステムに存在する概念を使って言い直してみる

言い直しの手順:

ユーザーに何をできるようにしたいのかを定める

システムの世界では誰が、何に対して、何をすることになるのかを正確な言葉で表現する

その文章が、それぞれの概念にとって本来できて当然のことになっているかを見る

電子書籍アプリの例:

Bookという概念はタイトルがあり、著者がいて、ページを持ち、読むことができる

ユーザーが本を好きな順番で本棚に並べられるようにしたいという機能を考える

不自然な表現:

Bookが自分が棚の何番目に表示されるかを持つという表現は少し妙である

棚の何番目に置かれているかは、本そのものにとって本質的な性質ではない

同じ本が別の本棚にも置かれるかもしれず、本棚がなくてもBookはBookである

自然な表現:

BookshelfがBookを並べる、あるいはBookshelf上にBookのPlacementがあると表現する

実装者でなくても判断できる:

この違和感はコードを一行も書かなくても見つけられる

プロダクトデザイナーが提供したい体験を、システム内の概念で正確な文章にしてみればよい

判定の意味:

既存の概念にとって自然なら、その機能は現在の世界観の中にきれいに収まる可能性が高い

どう言い換えても誰かに不自然な責務を負わせなければ表現できないなら、立ち止まった方がよい

機能そのものがおかしいのかもしれない

その機能によって初めて姿を現した、まだ名前のない概念があるのかもしれない

実装可否のテストではない:

今のクラス構造で実装できるかというテストではない

その機能が、この世界について我々が置いた概念と矛盾せずに語れるかというテストである

意図の保存という利点:

機能を概念の言葉で表現しておけば、なぜそういう形になっているのかも残る

当時の企画書も議論も知らない後任でも、概念そのものから機能の意味をかなり復元できる

概念は、その機能をどう理解すべきかという意図を時間や組織の境界を越えて運ぶ語彙になる

■ 7. 概念の手掛かり: 関係者の視点

機械的に正解を出す方法はない:

ただし概念の境界を見つけるための手掛かりはある

今回の例には、そのうち特に分かりやすいものが二つ現れている

同じ注文が立場で違って見える:

注文受付担当には、顧客が何を、いくつ、いくらで買ったかという情報に見える

物流担当者には、何を、いくつ、まだ届ける必要があるかを表す情報に見える

頭の中の概念の差:

両者は同じ注文について話しているが、頭の中で操作している概念は同じではない

注文受付システムが変更するものと、倉庫・配送システムが変更するものも違う

疑うべき兆候:

担当する人、組織、システムコンポーネントが違うなら、メンタルモデルも違っていないかを疑う

別々の主体が、別々の理由で、別々のタイミングに変更するものは異なる概念である可能性が高い

組織の境界との違い:

組織の境界をそのままクラスの境界にすればよいという話ではない

扱う人が変わった途端に語彙も操作も関心事も変わる場所には、概念の境界が隠れていることが多い

■ 8. 概念の手掛かり: 名前

曖昧な名前でも当面は困らない:

注文商品、購入商品、発送商品は日常会話なら多少曖昧に混ぜても通じる

コードでもOrderItemのような名前を一つ置けば、しばらくは困らない

忠実な言語化が最大のコツ:

概念を忠実かつ的確に言語化した名前をつけることが何よりのコツである

正しい名前は、その概念が何であるか、何ができるはずか、そこからの含意までを決める

注文は注文であって、配送チケットではない

丁寧な言語化が区別を露わにする:

前者は顧客が何を、いくつ、いくらで買うと成立させた明細である

後者はその約束のうち何を、いくつ届けるかを表す履行の単位である

丁寧に言葉にすると、同じ名前で呼び続ける方が難しくなり、注文と履行に分かれる

現場の言葉に区別が現れている:

営業や注文受付では受注と言い、倉庫では出荷と言い、サポートでは再送と言う

同じレコードの状態を違う言葉で呼んでいるように見える

実際には関係者が最初から違う対象を頭に浮かべているのかもしれない

ドメイン言語の価値:

DDDでいうドメイン言語の価値は、業界用語をそのままコードへ持ち込めることだけではない

言葉の違いは概念の違いを発見するセンサーになる

まあこれで通じるという名前ではなく、できるだけそれしかない名前を探す

名前が責務を決める:

名付けた瞬間、そこに何を乗せてよく、何を乗せてはいけないかもある程度決まる

Fulfillmentという名前は、顧客がいくら払ったかを持たせてよいはずがないと教えてくれる

支払は受注の責務であり、履行の責務ではない

逆に配送状況や再送の記録は、Fulfillmentが持って当然のものとして扱える

命名は境界を詰める作業:

命名は単なるラベル付けではない

関係者が現実をどう概念として認識するかを左右する

そのコードで何ができて何ができないかまで、あらかじめ大まかに決めてしまう

命名への投資:

命名にはいくらでも時間を投じてよい

認識の齟齬がなくなり、後のバグや新機能実装による帳尻合わせに頭を悩ませずに済む

命名が曖昧なまま詰め切れないなら、そもそも概念レベルで何かが矛盾している可能性がある

■ 9. 結び

言葉遊びに見える設計:

概念設計というと少し抽象的に聞こえ、一見して言葉遊びのようにも見える

しかしその設計は、その後かなり長い間、何を普通のケースとして書けるかを決め続ける

何を特殊ケースとして扱うか、どんな申し送りが必要か、どんなバグが書けてしまうかも決める

現実が破綻していないことが根拠:

現実世界そのものは破綻せず回っている

現実を無理なく正しく反映した適切な概念が置かれていれば、コードも破綻しない

コードの命運を握る:

概念設計が適切かどうかが、その後のコードの命運を握る

うまくいけば未来の仕様が何もしなくても実装されており、未来のバグが生まれる余地ごと消える

■ 10. 参考文献

本稿の位置づけ:

一定の経験があるソフトウェアエンジニア同士では、誰に教わらずとも通じ合う暗黙の了解である

そのエッセンスはオブジェクト指向プログラミングやDDDなど主立ったパラダイムのたびに繰り返し現れている

既存の文章の多くは所与の仕様を実装へ落とす設計技法に紙面を割き、裏側の信念は説明されてこなかった

概念設計の価値についての一冊:

Jackson, D. (2023). The Essence of Software: Why Concepts Matter for Great Design. Princeton University Press.

邦訳は『優れたデザインにとってコンセプトが重要な理由』（中島震訳、丸善出版）

UXデザイナーやプロダクトデザイナー寄りの視点から概念設計の重要性を解説した良書

概念体系が整理されていれば、デザイナーも実装詳細を聞かずに破綻しない仕様を考えられる

本稿はプログラミングに近い観点、同書は具体例を多数集めたケーススタディ的な内容で補完的に読める

命名の価値についての書籍:

仙塲大也 (2024)『改訂新版良いコード／悪いコードで学ぶ設計入門』技術評論社

特に第11章が本稿の内容に関係する

概念を分離できていない命名を特定する質問や、よくない命名の解消方法などHowとWhatが厚い

他の章も参考になるため全編を読む価値がある

Boswell D., & Foucher T. (2012)『リーダブルコード』オライリー・ジャパン

良い命名について詳しく書かれた、広く読まれた古典に近い一冊

その他の参考:

本稿は純粋なオリジナルでも特定の一つの受け売りでもない

様々な設計パラダイムが本当に伝えたかったエッセンスの一つを自分なりに言語化したものである

Vernon, V. (2015)『実践ドメイン駆動設計』翔泳社

Chiusano, P., & Bjarnason, R. (2015)『Scala関数型デザイン&プログラミング』インプレス

Alexander, C. (2013)『形の合成に関するノート／都市はツリーではない』鹿島出版会

Emacs LispやClojureに触れてきたことも良かった

■ 11. 補遺1: KISS/YAGNIとの関係

YAGNI違反ではないかという疑問:

Fulfillmentのような概念を最初から切り出すのはYAGNIに反するように見えるかもしれない

仕様上はどちらも正解:

最初のOrderが持つshippingStatusも、配送状況を確認できるという当初の仕様を満たしていた

Fulfillmentの切り出しは、同じ仕様を満たすもう一つの実現方法にすぎない

原則の素朴な解釈が招く誤り:

KISSはコードをシンプルに保てという原則である

YAGNIはいつか使うと思ってもどうせ使わないという原則である

いま必要なコード量が最も少ない方を選ぶとだけ解釈すると、第一の世界線が魅力的に見える

概念に対して自然な実装は最小変更より少しリッチになりがちで、過剰にも見えてしまう

最小変更の代償:

目先の変更量は確かに最小で済む

しかし代償として帳尻合わせがコードと運用のあちこちに波及していく

長期的には、その不自然さがずっと悪影響を発し続ける

原則自体は誤っていない:

KISSやYAGNIは余計な機能や抽象化を作らないための原則である

現実を無理なく表現できる概念設計に沿って実装することは、全くもって余計ではない

むしろ満たさないとまずいことが起きる、一種の実装上の大原則である

概念に対してコードが自然であることを崩すほどコード量を減らすことまでは求めていない

両立のさせ方:

まず現実を無理なく表現できる概念を置く

その制約の内側で、必要な機能に対して最もシンプルで直接的な実装を選ぶ

■ 12. 補遺2: 練習問題

問題1 解約しても使えるSaaS:

Subscriptionがactiveかcancelledのstatusのみを持ち、activeならPro機能を利用できる

解約しても支払済みの月末まではProを使えるようにするという仕様が来る

翌月には障害のお詫びとして、契約していないユーザーにもProを1か月無料付与したいという仕様が来る

このSubscriptionが何と何の二役をしていたかを問う

問題2 承認済み文書の編集:

Documentがbodyとapproved: booleanを持つ

承認後に本文を編集したら再承認が必要にするという仕様が来る

編集時にapproved = falseとすれば実装できる

しかし、もっと自然な概念の切り方がないかを問う

問題3 再試行するJob:

Jobがstatus、startedAt、errorを持ち、statusはrunning、succeeded、failedを取る

タイムアウトしたら自動で再試行するという仕様が来る

一回目は失敗し、二回目は成功した

このJobがfailedなのかsucceededなのかを問う

(2026/08/15)

Enable on-demand expertise with Agent Skills in Genkit Go

Enable on-demand expertise with Agent Skills in Genkit Go - Google Developers Blog

要約:

■ 1. 背景と課題

コンテキスト肥大化の問題:

LLMベースのエージェントの責務が拡大するにつれ、プロンプトコンテキストのサイズ管理が課題となる

標準業務手順、参照ガイド、ドキュメントをすべて永続的なコンテキストウィンドウへ読み込む方式は持続可能でない

常時ロードの弊害:

貴重なトークンを消費する

モデルの集中を散漫にする

誤った応答が生じる可能性を高める

Genkitでのサポート追加:

TypeScript、Go、Dart、PythonのGenkitにAgent Skillsのサポートを追加した

本稿ではGenkit GoでのAgent Skillsの利用方法を示す

スキルの位置づけ:

専門知識を発見可能な能力としてパッケージ化し、必要なときだけエージェントが読み込む標準

必要になる瞬間まで背景に控える専門知識パックとして機能する

■ 2. Agent Skillsの仕組み

Progressive disclosure:

必要になったときにのみ情報をモデルへ開示するという原則で動作する

SKILL.mdの構成:

frontmatterとbodyの2つのセクションでスキルを定義する

frontmatterにはスキルの説明と追加のメタデータを記述する

bodyにはモデルへの実際の指示を記述する

参照ドキュメントやスクリプトなどの補助ファイルを追加できる

ディスク上の構成:

skill-name/配下に必須のSKILL.md（メタデータと指示）を置く

任意でscripts/（実行可能コード）、references/（ドキュメント）、assets/（テンプレート、リソース）を置く

その他の任意のファイルやディレクトリも配置できる

frontmatterの記述例:

name、description、license、metadata（author、version）を記述する

descriptionにはスキルを有効化すべき状況と用途を明示する

段階的な開示の流れ:

エージェントハーネスはSKILL.mdからスキル定義を読み込み、システムプロンプトにはfrontmatterのみを露出する

frontmatterはスキルを有効化すべきか判断するために必要な情報

会話が進みスキルが必要な状況に至ると有効化処理が始まり、bodyの全文が読み込まれる

bodyの内容に応じて追加の参照ファイル読み込みや同梱スクリプトの実行が判断され、開示サイクルが完了する

■ 3. Progressive disclosureの利点

トークン効率:

Genkitは初期にはスキルのメタデータのみを読み込む

詳細な指示はスキルが有効化された時点で注入する

軽量な実装:

スキルはMarkdownファイルの束であり、コードと同じ方法で配布できる

追加のインフラを構成せずに利点を得られる

リソースの同梱:

スキルはPython、Node.js、Bashのスクリプトを内包でき、エージェントがそれを実行できる

その仕事に必要な正しいツールを確実に備えられる

■ 4. Genkitのミドルウェア構造

ミドルウェアの役割:

モデルのライフサイクルの重要な局面を横取りしラップするフックのパイプラインとして機能する

Model Wrapper（WrapModel）:

イテレーション内のモデルAPI呼び出しごとに1回発火する

リトライ、フォールバック、キャッシュなどモデル呼び出し自体に関するロジックを扱う

Tool Wrapper（WrapTool）:

ツール実行ごとに1回発火する

同一イテレーション内の並列ツール呼び出しでは並行して実行されうる

Generate Wrapper（WrapGenerate）:

ツールループのイテレーションごとに1回発火し、N回のツールターンならN+1回呼び出される

リライト、システムプロンプト注入、メッセージ蓄積など会話全体を見る必要のあるロジックを扱う

スキルの実現方式:

Agent Skillsはこのフック機構の上に構築される

ミドルウェアが入力プロンプトを監視し、説明に合致するものを検出してスキルを動的に有効化する

呼び出し方:

genkit.Generateにai.WithUseで&middleware.Skills{SkillPaths: []string{"./skills"}}を渡す

■ 5. 動作の3段階

Discovery:

スキルミドルウェアを伴うGenkit初期化時に、設定されたSkillPathsを走査しSKILL.mdを探す

見つけたメタデータをシステムプロンプトへ注入する

Activation:

ユーザーのリクエストがスキルのdescriptionに合致すると、Genkitはuse_skillツールを呼び出す

現在のタスクに必要な具体的な指示を取得する

Execution:

SKILL.mdの全文と、スクリプトや参照などの同梱リソースへのアクセスがアクティブなコンテキストへ読み込まれる

それにより厳密なワークフローに沿ってモデルを導く

■ 6. 環境の準備

SDKの導入:

go get github.com/firebase/genkit/go で最新のGenkit Go SDKを取得する

CLIの導入:

任意の手順だが導入を推奨する

macOSとLinuxではcurl -sL cli.genkit.dev | bash を実行する

Windowsではcli.genkit.devからバイナリをダウンロードする

■ 7. 基本フローへの適用例

レシピ生成CLI:

料理名または食材を引数に取り、Genkitフローでレシピを生成するコマンドラインツールを定義する

genkit.InitでgooglegenaiのGoogleAIプラグインとmiddleware.Middlewareを登録する

モデル設定:

googleai/gemini-flash-latestを指定し、ThinkingLevelをLowに設定する

システムプロンプト:

レシピに関する広範な知識を持つプロのシェフ助手として振る舞わせる

可能な限り専門知識（スキル）を用いるよう指示する

Markdownを使わず、ターミナル出力に最適化したASCII整形で応答させる

スキルの登録:

genkit.GenerateText内でai.WithUseの関数オプションによりSkillsミドルウェアを設定する

SkillPathsで./skillsフォルダを指定し、そこにbanana-breadとcheese-breadの2つのスキルを配置する

実行結果:

go run main.go cheese の実行でcheese-breadスキルが有効化される

ブラジル伝統のチーズパン（Pao de Queijo）のレシピがASCII整形で出力される

出力されたレシピはGeminiによる生成物であり、試す場合は自己責任とする

■ 8. 実運用に近い応用例

より現実的な題材の必要性:

レシピフローは基本的なオンデマンド読み込みの実演にとどまる

本番システムでは、非決定的なタスクに対し専門的な指示を統率して適用する必要がある

美術品修復アプリケーション:

Genkit GoとGemini 3.1 Flash Image（Nano Banana 2）で構築したマルチモーダルな美術修復アプリを示す

画像ファイルのパスを引数に受け取り、Base64のデータURIへ変換して入力する

入出力スキーマ:

InputはBase64画像データURIを保持するURLフィールドを持つ

Outputはテキスト説明のTextと画像データのImageを持つ

フロー実装:

googleai/gemini-3.1-flash-imageを指定し、ResponseModalitiesにTEXTとIMAGEを設定する

システムプロンプトで画像の種類を分析させ、対応する修復スキルを適宜呼び出させる

高精度な修復を実行し、修復後のIMAGEと、処理の概要および使用スキル名を含むテキストを返させる

ai.WithUseで./skillsディレクトリからスキルを動的に読み込む

後処理:

返却テキストが生の画像データでない場合のみ修復プランを表示する

データURIをbase64デコードし、元のファイル名に_restoredを付したPNGとして保存する

ログ設定:

slogの出力レベルをErrorに設定し、標準出力への冗長なトレースログと情報ログを抑制する

■ 9. 修復スキルの内容

3種類のスキルの同梱:

drawings、paintings、photographyの3つのスキルを同梱する

美術様式ごとに固有の修復指示が必要となるため分割する

paintingsスキルの方針:

直接的かつ最小限の介入による絵画修復を行う

化粧的な現代化よりも歴史的一貫性、原顔料の深み、表面の質感を優先する

原作に存在しない要素や技法は一切導入しない

保存の基本原則:

新たな主題、人物、風景、細部、物語的要素の追加を厳格に禁止する

原筆致の特性を保持し、支持体の質感を平板化しない

亀裂網（craquelure）を作品の歴史の一部として尊重する

剥落の危険が現に存在しない限り、亀裂を埋めたり消したりしない

修復の手順:

黄変した天然ニスを穏やかに調整し、過度な高コントラスト化を避けつつ本来の顔料の色度を回復する

薄い下層のグレーズを保護しながら、表面の煤と汚れを分離して除去する

絵具層の欠損部は現存部分を参照し、筆の方向、速度、盛り、透明度、光源を再現して補筆する

■ 10. 実行結果と留意点

対象画像:

Elías García Martínezの「Ecce Homo」の、悪名高い修復の試みが行われる前の画像を入力とする

ecce_homo.pngとして保存し、環境にGEMINI_API_KEYを設定したうえで実行する

モデルの判断:

画像を悲しみの人（Ecce Homo）を描いた古い宗教的な献身画像と識別する

使用スキルとしてpaintingsを出力する

修復内容の説明:

表面清掃を模して汚れと黄変したニスの層を除去し、本来の鮮やかな深紅と豊かな暗い肌色を回復する

顔と上衣を中心に非芸術的な亀裂とカンヴァスの織り目を抑え、経年感を残しつつ肖像を明瞭にする

特徴的な質感のある紫の衣は保持し、最も目立つ表面の汚点のみを除去する

淡く不明瞭だった背景の巻物構造を精緻化し、古びた羊皮紙の質感と局所的な経年変化を加える

留意点:

LLMは非決定的であるため、良好な結果を得るには数回の試行が必要な場合がある

提示した修復スキルは初期の試みであり、専門家による調整の余地がある

写真や素描など他種の画像を与え、対応するスキルの有効化を試せる

■ 11. スキルのベストプラクティス

詳細な説明の記述:

YAML frontmatterのdescriptionがミドルウェアの主要なトリガーとして機能する

モデルがuse_skillを呼ぶべき時点を判断できるよう、明確で命令的な言葉を用いる

焦点の限定:

1つのスキルは1つのことを適切に行うべきものとする

何でもこなす一枚岩のスキルの作成を避ける

決定的なツールの同梱:

軽量なスクリプトをスキル内に同梱する

エージェントに真実の情報源を与え、内部の訓練上の限界を回避させる

リソースのモジュール化:

references/フォルダを用いてSKILL.mdを簡潔に保つ

エージェントは必要に応じてこれらのファイルを読み込める

■ 12. まとめと次の一歩

Agent Skillsの意義:

Genkit Goにおいて開発者の専門知識を管理するための、モジュラーで拡張可能な枠組みを提供する

スキルミドルウェアの統合により、複雑な複数手順のタスクをより高い信頼性で実行できる

参照先:

Getting Started with Genkitのページを読む

ミドルウェアのドキュメントで詳細を確認する

オープン標準を理解するためAgent Skillsの仕様を参照する

(2026/08/15)

Why Go is an Ideal Language for AI-Assisted Software Engineering

Why Go is an Ideal Language for AI-Assisted Software Engineering - Google Developers Blog

要約:

■ 1. 書く時代から読む時代への転換

ソフトウェア工学の根本的な変化:

かつては大半のコードを人間が手で書いていた

現在はAIコーディングアシスタントやエージェントに大量のコード生成を任せる

人間に残る役割:

生成されたコードを読み、整理し、意図どおりに動くか検証する

AIは全体文脈の把握が限定的なため、システムアーキテクチャ設計は人間が担う

サービス間の境界設計、本番環境の安全性と信頼性の担保も人間の責務

生産性指標の変化:

従来は言語の生産性を「書きやすさ」で測っていた

エージェントが数秒で数百行の構文的に正しいコードを生成する以上、人間の記述速度は重要でない

重要なのは書かれた後のレビュー、検証、保守

AIはチームメイト:

やや無鉄砲ではあるが、AIは同僚である

最も重要なのはチームとしてどう協働するか

■ 2. ソフトウェア工学のための言語設計

Goの出発点:

チーム開発の観点こそが、20年以上前にRob Pike、Robert Griesemer、Ken ThompsonがGoogleでGoを作った動機

他言語が機能を急速に追加しロジック表現の多様化を志向する中、Goは言語設計をソフトウェア工学に奉仕させる方向を選んだ

ソフトウェア工学とプログラミングの違い:

プログラミングはコードを書いて実行し問題を解くこと

ソフトウェア工学は他者と協働し、時間とともに進化する永続的システムを設計し実装する営み

プログラミングはソフトウェア工学の一部にすぎない

ソフトウェア工学に資する言語設計の要件:

言語だけでなく、開発ライフサイクル全体を覆うツールを備えたエンドツーエンドのプラットフォーム

チーム全体が同じ方法で構造化、整形、テストできる、意見を持った単純さ

今日書いたコードが10年後も動き、10年後も良いコードであり続ける強い互換性保証

チーム規模に応じてスケールする、グローバルな依存関係管理を備えた強いエコシステム

全体に織り込まれた合理的で堅牢なセキュリティの考慮とツール

基盤の意義:

これらの要素はスケーラブルで長期的な協働の土台となる

原作者が去った後も何年も保守可能なシステムを構築できる

AIがチームに加わった今、この基盤の重要性はこれまで以上に高まる

■ 3. プラットフォームとしてのGo

言語ではなくプラットフォーム:

Goは当初から開発ライフサイクル全域に接点を持つ堅牢なツールチェーンを同梱してきた

標準で整形ツール、テストフレームワーク、依存関係管理、高度なセキュリティツールを提供する

複雑な外部フレームワークを不要にする包括的な標準ライブラリと相まって、比類ない一貫性の基準線を与える

AIと人間のニーズの一致:

これらの機能は元来人間のために作られたが、AIと人間のニーズは驚くほど似ている

外部検証なしに反復的なリファクタリングを命じられたAIは、人間の手作業と同様に性能が急速に劣化する

初回が95%正しくても、反復ごとに誤りが累積しコンテキストウィンドウを汚染する

精度が下がる一方でトークンコストは増大する

Goではエンドツーエンドのツールチェーンを活用し、より速く、安く、確実に高品質で安全かつ正確なコードを生成できる

エコシステム全体の一貫性:

大多数のGo開発者が同じコアツールを使うため、コミュニティ全体が一体となって前進する

ランタイム、IDE、パッケージエコシステムを横断して主要な言語拡張を一斉に無理なく採用できる

標準ライブラリはプログラムロジックのばらつきを減らし、反復的で予測可能なイディオムを促す

開発者にもAIにも理解しやすい構造的均一性を生む

この均一性は大規模コードベースの保守を助けるだけでなく、LLMにとってより清潔で標準化された学習データを生み出す

■ 4. 可読性の優先

書きやすさより読みやすさ:

開発者はコードを打ち込む時間よりも既存コードを読む時間の方がはるかに長い

この設計哲学は、賢さより単純さを重んじ、他言語が称賛する構文的魔法を明確に拒む文化として現れる

Gopherはチームの誰が書いたコードか判別できないことを愛しており、すべてが同じ見た目になる

AI時代における効果の増幅:

かつて個々の開発者は構文の簡潔さ、暗黙の型付け、プロトタイピングを加速する巧妙な近道を好んだ

エージェントのエルゴノミクスと人間による検証ループが求めるのは正反対の予測可能性、明示性、厳格な構造

ボトルネックは生成から検証へ完全に移行する

同じロジックを十数通りに表現できる言語では、AIは断片的で行き当たりばったりな構文の寄せ集めを生成する

人間のレビュアーにとって意図の解読は消耗を強いる作業になる

揺るぎない一貫性による解決:

組み込みのgofmtが単一の標準書式を強制する

複雑な抽象を意図的に制限した言語設計を提供する

シニアエンジニア、ジュニア、LLMのいずれが書いてもコードは同じ見た目になる

構文が完全に予測可能なら、幻覚によるAPI呼び出し、論理的欠陥、脆弱性を素早く発見できる

この標準化はオープンソースのGoエコシステムにも及び、モデルは標準化されたデータで学習する

より少ない試行で正しく慣用的なGoコードを生成できるようになる

人間に明快な言語はAIにも明快:

AIがコード生産量を加速させ続ける中、可読性への傾倒がシステムのスケールを可能にする

理解し、検証し、安全に保守する能力を失わずに済む

■ 5. 信頼性

静的型システムが第一の防衛線:

LLMは構造的境界とファイル横断の型整合性でしばしば失敗し、幻覚的なプロパティや潜在バグを生む

Pythonのような動的型付け言語では、こうした幻覚は基本的な構文検査をすり抜ける

特定の本番ワークロード下で実行時に初めてシステムを落とす

Goではコンパイラが即座にこれらの誤りを弾く

存在しないメソッドの使用、誤った型の受け渡し、未初期化の変数はコンパイルを通らない

高速コンパイルとの相乗効果:

GoのコンパイルはJava、C#、Rustなど他の本番品質のコンパイル言語より桁違いに速い

エージェントは構文エラーや型エラーを自ら反復的に修正する効率的な自己修正ループを回せる

人間の同僚がレビューする前に構文的に正しいコードが届く

電池付属の哲学とサプライチェーン:

LLMは学習データに依存するため、古い、放置された、あるいは悪意ある第三者依存を提案しがち

包括的な標準ライブラリが、最適化され安全で公式に保守されたパッケージへAIを自然に誘導する

サプライチェーン脆弱性の攻撃面を劇的に減らし、コードベースを軽量で保守しやすく保つ

外部依存が必要な場合の完全性保証:

あらゆるGoプログラムに取り込まれた全モジュールのチェックサムとキャッシュ済みコピーが記録される

チェックサムデータベースとモジュールミラーが中間者攻撃を防ぐ

依存が消失したり密かに改変されるリスクを排除する

脆弱性データベースとgovulncheckが既知の脆弱性を追跡し、脆弱なシンボルを呼び出すコードを指摘する

実際に呼び出している関数の脆弱性のみを提示するためノイズが少なく、行動に直結する

人間のレビュアーもAIも正確にパッチを当てられる

テストとファジング:

組み込みのテストフレームワークとネイティブのファズテストが継続的検証の標準化された厳格な砂場を提供する

外部ツールの寄せ集めに頼らず、ネイティブのツールチェーンで堅牢なテストを書き実行できる

ファジングはプログラムへの入力を継続的に操作しバグを発見する自動テスト手法

隠れた境界値バグを露出させ、AIは予測不能なランダム入力に対し自らのロジックを反復的に堅牢化できる

■ 6. 保守性

Day 2以降が真の評価軸:

可読性は本番投入までを、信頼性は本番稼働の継続を支えるが、真の尺度は運用開始後の保守性

コードベースは生きた系であり、自然に劣化し技術的負債を蓄積し、要件変化への適応を迫られる

人間だけが作者だった時代、保守負担は予測可能な運用コストだった

自律的AIエージェントが数百のプルリクエストを生成しサービス全体を気まぐれに書き換える今、進化速度とアーキテクチャの漂流の危険は激増する

互換性の約束:

Goにおける互換性は利便性ではなくセキュリティ上かつ運用上の必須要件

15年前にGo 1.0向けに書かれたコードは最新のツールチェーンで無変更のままコンパイルされ動作する

後方互換性を決して壊さないと約束しており、Go 2.0は永遠に存在しない

コンパイラとランタイムの改善に伴い、アップグレードして再コンパイルするだけでコードも良くなる

運用上の可搬性:

Goはシステム依存ゼロの単一静的バイナリに直接コンパイルされる

AIエージェントがマイクロサービスの立ち上げやスクリプト実行などシステム管理者として振る舞う場面が増えている

この自己完結的な設計の重要性はかつてなく高まる

コンパイラはOSやアーキテクチャを跨いだクロスコンパイルに対応する

複雑なビルドシステムなしに必要な全ターゲット向けのバイナリを構築できる

アーキテクチャの漂流への対抗:

大規模なリファクタリングと近代化のための決定論的ツールを組み込みで提供する

公式言語サーバーgoplsと、モダナイザーの概念を導入した新生go fixが該当する

モダナイザーは古いコードパターンを最新のイディオムと言語機能へ決定論的に更新し、コードの均一性を保つ

規模の面では自分のコードだけでなくGoエコシステム全体を前進させる

ライブラリやオープンソースプロジェクト、第三者コードベース間の均一性を維持する

標準化されプラットフォームに直接組み込まれているため、AIエージェントも安全に活用できる

パッケージの再構成、依存関係の管理、技術的負債の整理をコードベースを壊さずに行える

本番環境まで届く保守性:

ランタイムはプロファイリングと実行トレースを標準で備え、負荷時の挙動を深く可視化する

コンパイラはプロファイル誘導最適化をネイティブに支持し、実運用のプロファイルから高度に最適化されたバイナリを生成する

AIが統括するデプロイパイプラインと組み合わせると、閉ループの最適化サイクルが成立する

本番データを自動的にコンパイラへ還流させ、システムを再構築し最適化できる

■ 7. 結論

言語選択の重要性はむしろ増している:

開発者が書くコードが減る以上、言語選択の重要性が増すのは一見直感に反する

コード生成をAIに委ねると、ボトルネックは書く速さからレビュー、検証、保守の厳密さへ完全に移る

従来型言語の限界:

緩いプロトタイピングや巧妙で暗黙的な近道を優先してきた言語は、断片的なエージェント出力の重みの下で安定を保てない

Goの適合性:

Goは初日から大規模かつ長期的な協働の課題を解くために設計された

読み手優先の明快さ、本番運用への即応性、プラットフォーム全体の一貫性を備える

AIという同僚の高速な出力を、信頼性、保守性、システムの完全性を犠牲にせず吸収する決定論的なガードレールとなる

AIは最も新しいチームメイト:

極めて生産的な貢献者だが、成功には強力なガードレールを要する

Go上に構築することは、単にコードを書くことではない

人間とAIが本番システム上で安全に協働し反復できる、堅牢で自己修正的な基盤を築くこと

■ 8. 導入手順

go.devのインストール手順に従い最新リリースのGoをダウンロードする

AntigravityなどVisual Studio Code系IDEを使う場合はVS Code向け公式Go拡張機能を導入する

明示的な指示または事前読み込みのスキルを通じて、エージェントにGoツールチェーンを使うよう指示する

エージェントにGoで新しいアプリを書かせる

(2026/08/15)

LanceDB入門

LanceDB入門 - Speaker Deck

(2026/08/15)

Software Engineering Is Cool, But Is It Interesting?

Software Engineering Is Cool, But Is It Interesting? | Ertu's Blog

要約:

■ 1. 外から見たソフトウェア開発

外部からの称賛:

ソフトウェア開発者だと名乗ると、技術に縁のない相手からは小さな称賛が返ってくる

黒い画面に緑の文字が流れ、衛星に侵入する姿を相手は想像している

自分自身の過去の認識:

長い間、自分もこのイメージのある種の変奏を信じていた

■ 2. 格好よさと面白さの区別

年数とともに薄れる格好よさ:

ソフトウェアの世界で働く年数が長くなるほど、実際の仕事は格好よく感じられなくなる

職業としての価値は否定しない:

ソフトウェアは依然として優れた職業

業界の外の人間には説明しづらい種類の難しさがある

二十年上達を重ねてもなお、初心者に戻った気にさせる発見が定期的に訪れる

主張の焦点:

この仕事が簡単だと言っているのではない

他のいくつかの職業と比べたとき、それほど面白いとは思えないという点が主張

■ 3. 会話が尽きる技術的境界

パーティでの典型的な問い:

何を作るのか、どの言語を使うのか、ハッキングはできるのか

意欲的な相手はAIに仕事を奪われるのかと尋ねる

誠実に答えた瞬間の断絶:

データベース、API、並行処理、分散システムへと話が進む

相手の魂がゆっくり体から抜け出していく様子が見える

境界を越えるということ:

退屈な人間になったのではなく、技術的な国境を越えただけ

越えた先では、誠実な回答のたびに五分の説明が追加で必要になる

■ 4. 医師との対比

救急医への尽きない質問:

見た中で最も奇妙なもの、負傷の経緯についての嘘を即座に見抜いた経験

家族同士が患者の扱いで対立したときの顛末

助からないと思った相手を救った経験、今も記憶に残る最も悲しい症例

こうした問いなら何時間でも続けられる

理由は仕事が人で満ちていること:

患者は必ず自分の人生を伴って現れる

家族も、性格も、犯した過ちも、見舞われた不運もそれぞれ異なる

患者の物語への参加:

医師は二十分だけその人の物語の一部になることもある

数か月にわたることもあり、その物語が生涯残ることもある

■ 5. ソフトウェアの物語と平凡な日常

ソフトウェアにも物語は存在する:

本番環境の惨事、崩壊する企業、ひどい管理職、優秀なエンジニア、不可能な納期

金曜午後に誤って削除されるデータベース

スキャンダル、失敗、奇怪な顧客、英雄的なデバッグの一夜

個人的な危機のさなかに書かれたとしか思えないコードベース

大半の日は火曜日:

そうした日々はほとんど訪れず、大半の日はただの火曜日

典型的な一日の流れ:

ノートパソコンを開き、Slackを確認し、会議に参加し、チケットを別の列へ動かす

四十分かけて原因が一行のコードだと突き止め、それを直す

再びSlackを開き、昼食をとり、もう一つの会議に出る

誰かが「これは後で個別に話そう」と言い、実際に個別で話されることはない

一日が終わり、翌日も驚くほど似た出来事で構成される

反復自体はどの職業にもある:

外科医とて毎週水曜に新しい臓器を発見するわけではない

ただしソフトウェアは、互いに溶け合って区別のつかない日々を生むことに異常に長けている

■ 6. タクシー運転手やマフィアとの対比

話を聞きたい相手はタクシー運転手:

経験を積んだ運転手、とりわけ夜勤を二十年続けた人物の話を本心から聞いてみたい

後部座席で起きてきたこと:

酔客、泥棒、セックスワーカー、言い争う恋人たち

葬儀へ向かう人、結婚式から帰る人

人生最良の知らせを受け取った人、最悪の知らせを受け取った人

一言だけ奇妙な文を残し、十五年後も運転手の記憶に残り続ける乗客

平均的な一週間を語り比べた場合:

自分とその運転手が同じ席で平均的な一週間を語るなら、どちらの話を先に聞きたいかは明白

マフィアという極端な例:

本物のマフィア構成員に好きなだけ質問できる状況を想像する

本物のギャングの普通の一日を知りたくない者はいない

質問し尽くす頃には太平洋の底に沈められているだろう

プログラマーの話など知ったことではない

■ 7. 例外としての語れるベテラン

数十年続けてきた開発者:

奇妙なシステムに携わり、崩壊寸前の企業を生き延びてきた

今日の腕時計より遅い計算機の時代に製品を出荷した

技術が登場し、流行し、嫌われ、消え、十五年後に新しい名前で戻る過程を見てきた

最も重要な条件は語りの技術:

そうした人物は物語の語り方を知っている

例外が成立する瞬間:

そのような相手に会うと、ここまで書いたことはすべて成り立たなくなる

誰も自分たちをその席から引き離せず、朝まで座り続けられる

(2026/08/15)

Rails is done

Rails is done | lucas.dohmen.io

要約:

■ 1. Railsをフォークする理由

Railsのコア:

時の試練に耐えてきた

現在もWebアプリケーションを構築する優れた手段

DHHとの根本的な非互換:

DHHの世界観は自分の世界観と根本的に相容れない

そう感じているのは自分だけではない

実現しなかった公開書簡:

約1年前、自分を含む多数の人々がコアチーム宛の公開書簡に署名した

内容はDHHとの関係を断ち、Railsをハードフォークすることの要求

それは実現しなかったため、自分たちの手でフォークを行う時期に来ている

新しいリーダーシップが必要な背景:

1年前のDavid Celisの記事と数週間前のPaul Battleyの記事がその理由をまとめている

信じ難いことに、状況はそれ以降さらに悪化している

■ 2. Railsは完成しているという判断

フォーク維持の実現可能性:

Railsは巨大なコードベースで、多数のエンジニアが業務時間を投じて改善している

少人数が余暇でフォークを維持できる理由は、Railsが完成しているという事実

変更の継続的な観測:

The Rails 5 WayをRails 6、さらに7と8へ更新する過程でRailsの変更を注視してきた

コアの範囲:

rails new --minimalで生成されるのはフレームワークのコア部分のみ

内訳はrailties、actionpack、activesupport、activemodel、activerecord、actionview

コアgemの停滞:

2019年のRails 6.0でZeitwerkオートローダーが導入されて以降、コアgemに大きな変更はない

ただしActiveRecordは例外

ActiveRecordの改善も大半は2020年の6.1に集中している

例外はat-work encryption、非同期クエリ読み込み、一部の認証方式、複合主キー

以降に追加されたもの:

好みで追加できるgemやnpmパッケージにすぎない構成要素ばかり

一連のアセットパイプライン

Railsでも他のRuby/PHP/Javaのフレームワークでも使えるJavaScriptライブラリ群

コンテナ化されたWebアプリケーションを配備できるデプロイツール

Goで書かれたリバースプロキシ

ActiveJob、ActionCable、キャッシュのバックエンドとなる新しいデフォルトgem

完成していることの価値:

Railsは小規模から大規模までのWebアプリのニーズを満たし、付け加えるべきものはない

追加可能な任意のgemを除きコアだけをフォークすれば、対象は安定する

フォークの実務:

Railsリポジトリを監視してセキュリティパッチをフォークへ移植する

性能改善や小さな改善を探し、取り込むかを評価する

挑戦的ではあるが実行可能

■ 3. Mosscapプロジェクト

コードネームの変更:

本記事の初版ではプロジェクトのコードネームであるAmikoに言及していた

AmikoとMosscapは同一のプロジェクト

現在の状況:

Matrix上に良好なコミュニティが形成されつつある

フォークの動作方式に関するスパイクを進めている

関心があれば入口から参加できる

主目標:

Rails 8.xのLTS版を提供すること

ナチ、トランスフォビア、レイシスト、あらゆる偏見を許容しない人々のコミュニティが構築し維持する

移行方法:

既存のRails 8.xアプリケーションはgemを差し替え、いくつかの検索置換を行えば動作する

依存関係もフォークされたgemを使うよう、巧妙なaliasハックを用いる

目指す性格:

Mosscapは退屈で親しみやすいものにする

■ 4. 加える変更

互換性の範囲内での修正:

互換性を壊さずに実施できるなら、Railsの欠陥にも取り組む

アセットパイプラインの混乱:

2021年のBasecampの崩壊でコアチームがフロントエンドの知識を失った

それ以降、半端にしか動作しない十数個の手法が併存する絶対的な混沌状態にある

mosscap newの設計:

コマンドのあり方も議論した

シェフが全員に同じ料理を出すのはomakaseではなくファストフードであると理解していない人物が設計したものは踏襲しない

変更の規模:

Rails 6/7/8で慣れ親しんだものからの変更はわずかにとどまる

■ 5. Hanakaiとの関係

Ryan Biggによる異論:

Mosscapの目標に反対するブログ記事を書いた

Hanakaiに全員が参加すべきだという提案

ミッションへの賛同:

ある意味ではHanakaiに参加している

Hanakaiのミッションとコアバリューには合流する

その価値観は、あらゆる背景と経験レベルの人が尊重され、共有し成長でき、誇りと安全を感じられる場であること

ナチ、トランスフォビア、レイシスト、あらゆる偏見を許容しないという点も共通

モノカルチャーの拒否:

Tim Rileyと同じく、Rubyはモノカルチャーではなく繁栄するエコシステムであってほしい

彼のキーノートに強く触発された

理想的なジョブキューはMosscap、Hanami、Rodaのいずれでも動作する

Mosscapの位置づけ:

数多くの素晴らしい選択肢のなかの一つ

大規模なRailsアプリを抱えHanakaiへ書き換えられない人にとって特に良い選択肢を目指す

Railsの設計は好きだがそのリーダーシップは好まない人にとっても同様

他の選択肢の紹介:

Railsとまったく異なる設計を望むならHanakaiコミュニティの取り組みを勧める

サーバサイドロジックを追加できる静的サイトジェネレータを望むならBridgetownを勧める

この個人サイトもBridgetownで構築している

MosscapをWebフレームワーク、Romをデータ層、Dry::Operationを業務ロジックの整理に組み合わせればokonomiの体現となる

■ 6. 結論

共存の願い:

全員が共に繁栄できることを望む

目的:

Rubyエコシステムに選択肢を一つ加えること

あらゆる性別、肌の色、性的指向、経験レベル、背景の人々のために作る他のグループに加わること

排除の姿勢:

ナチ、トランスフォビア、レイシストが悲鳴を上げて逃げ出すことを望む

立ち去らないなら追い出す

動機:

後ろめたさを感じずにWebアプリケーションを作り続けたい

(2026/08/15)

産業機械のPLC制御に関する学習メモ

■ 1. PLCの定義と役割

PLCとは:

産業機械のシーケンス制御、タイマー処理、カウンター処理などを担う制御機器

従来はブロック状の専用ハードウェアとして提供される形態

実行専用の頭脳:

電源が入っている限り単体で自律的に動作し続ける

PLCが担う代表的な要素:

シーケンス制御、すなわちリレー的なON/OFF制御、タイマー、カウンター

モーション制御、すなわちサーボモータ、パルス発生、位置決め

アナログ処理、すなわち温度、圧力等のセンサ値取得とPID制御

GP-IB、RS-232C、専用インターフェース等による上位機器との通信

操作パネル（HMI）としての表示、入力

■ 2. PLCの実装形態による分類

ハードPLC:

従来型であり、専用ハードウェアとして実体を持つ

ソフトPLC（特定ハード固定型）:

制御をソフトウェア化しているが、動作するハードウェアはベンダー指定の特定機種に固定される

ソフトPLC（標準化ハード汎用型）:

特定ハードではなく、一定基準で標準化されたハード群に対応する

バーチャルPLC（vPLC）:

ハイパーバイザ、コンテナ等の仮想環境上で動作するソフトPLCの一形態

ハードウェアから完全に分離される

ソフトPLCとvPLCの関係:

ソフトPLCは広義の用語であり、必ずしも仮想化を前提としない

バーチャルPLCは仮想化技術の利用を明確に前提とする、より進んだ形態

業界内でも両者がほぼ同義で使われる場面があり、用語は完全には統一されていない

代表的なソフトPLC製品:

Beckhoff TwinCAT、CODESYS対応製品、シーメンスSoftware Controller

CODESYSは多数のメーカーのハードウェアに対応し、特定ベンダーへのロックインを避けやすい

■ 3. PLCと汎用PCの役割分担

従来型におけるPLC本体:

I/Oの読み書きとロジック実行を現場で自律的に継続する

PCが外れても運転は止まらない

従来型における汎用PC（エンジニアリングPC）:

プログラムの書き込みと読み出し、パラメータ設定、稼働監視に使用する

GX Works、Sysmac Studio、TIA Portal等の専用ソフトを用いる

PLC本体とは物理的に別の機器であり、開発、監視用途で一時的に接続する

ソフトPLCにおける統合:

PLCとPCが物理的に同一のハードウェアに統合される

汎用PCのCPU上でPLCの実行エンジン（ランタイム）そのものが走り、機械はこのPCに直接接続される

PCがPLCを制御するのではなく、PC自体がPLCとして機械を直接制御するという理解が正確

リアルタイム性の確保:

単純なUSBや一般的なEthernetは通常のOS通信スタックを経由するためリアルタイム性が保証されない

EtherCATマスター機能を持つ専用NIC、ドライバなど専用のリアルタイムEthernetインターフェースを使用する

Windowsへのリアルタイムカーネル拡張、リアルタイムLinux、専用リアルタイムOSの併用等でOS自体をリアルタイム化する

指揮者と演奏者の喩え:

PLCまたはソフトPLCの上位ロジック層は全体のタイミングを統括する指揮者であり、自らは音を出さない

電流制御、PWM生成といったμs〜数十kHzオーダーの超高速処理は演奏者が担う

演奏者はサーボアンプ等に内蔵された専用マイコン（DSP/FPGA等）であり、自律的に動作する

この多段構成は従来型、ソフトPLCのいずれでも変わらない

エッジ側での分散処理:

センサーの一次処理やリモートI/Oターミナルなど、機械側に分散配置された小さなマイコン群も同様の役割を担う

局所的な高速処理をエッジ側で完結させ、上位のPLCやPCは全体統括に専念するという設計思想の表れ

■ 4. 加工機械の制御アーキテクチャ

バネ、ワイヤー曲げ加工の制御対象:

送り軸、曲げ軸、回転軸、カット軸などが相対位置、相対タイミングで同期する

送り量に対して何mm進んだら何度曲げるという形で同期する、モーション制御が主役の対象

同期精度が品質を左右する理由:

曲げタイミングのズレが直接、角度誤差やバネ形状不良につながる

現実的な構成の選択肢:

単純なシーケンス制御中心のPLCだけでは同期精度が不足しやすい

電子カム機能を持つモーション統合型PLC（三菱モーションCPU、オムロンNJ/NX＋EtherCAT等）

専用モーションコントローラと上位PLCの組み合わせで、シーケンス部分のみPLCが担当する構成

移行の中核作業となる電子カム化:

機械式カムで作っていた曲げタイミングをデータ化する作業

送り軸の位置に対する曲げ軸の目標値という関数（カム線図）として表現する

プロトタイプ設計の考え方:

目的がロジック検証、機構検証、量産機の制御方式実証のいずれかによって構成を変えるのが定石

ロジック、機構検証が主目的ならArduino/STM32とステッピングモータでも電子カムの考え方を十分検証できる

送り軸位置を基準に曲げ軸目標値をテーブル化する構造を検証でき、コストと開発速度を優先できる

量産機の制御方式そのものを早期実証したい場合は、小型のモーション統合PLCで最初から組む方が手戻りが少ない

■ 5. 古いPC制御機械のPLCリプレース

既存機械の役割分解:

PC-98等で制御されている機械の役割は、シーケンス制御、モーション制御、アナログ処理、上位通信、HMI表示に分解できる

置き換えの難易度:

シーケンス制御、アナログ処理、HMI表示はPLCとタッチパネルHMIへの置き換えが比較的容易

高速、高精度なモーション制御が絡む場合はPLC単体では不足する

その場合はモーションコントローラや産業用PC（IPC）とのハイブリッド構成が必要になることがある

リプレース時の注意点:

I/O、信号の完全な洗い出しが必要であり、配線図が散逸していることが多く現地調査が必要になりやすい

Cバス等の専用インターフェースボードの代替設計が必要

PLCのスキャンタイムで足りるかというタイミング、応答速度の検証が必要

制御ロジックの仕様化が必要であり、ソースコードが残っておらず実機トレースによるリバースエンジニアリングが発生しやすい

非常停止回路の二重化等、安全規格への適合が必要

現実的な進め方の手順:

信号リストとタイミングチャートを作成する制御仕様書化

PLCとHMIでの置き換え設計

並行稼働またはオフラインでの検証

段階的な切り替え

■ 6. ハードウェア陳腐化を避けるための技術選定

PC-98問題の本質:

ハードウェアが壊れたら詰むことよりも、制御ロジックが特定ハードウェア、特定技術者に依存し移植できないことにある

発想の転換:

陳腐化しない機器を探すのではなく、陳腐化しても被害を最小化できる体制を作ることが重要

優先度が高い対策:

IEC 61131-3準拠かつEtherCAT/PROFINET/EtherNet-IP等の標準通信規格に対応した機器を選ぶ

ロジック、図面、パラメータを標準形式でドキュメント化し外部保管する

優先度が中程度の対策:

CODESYS等のソフトPLCでハードウェア非依存化を検討する

長期供給方針が明確な大手メーカーの製品を選ぶ

標準I/O、標準コネクタでモジュール構成にする

優先度が中〜低の対策:

プログラム読み書きのライセンス形態を事前確認する

結論:

壊れない機器を探すのではなく、ロジックと知識がハードウェアに縛られない体制を作ることが本質的な対策

標準規格に基づいたロジックとドキュメントが残っていれば、置き換え作業は大変だが可能なレベルに収まる

■ 7. 遠隔操作時の遅延対策

階層分離の基本方針:

軸間同期などμs〜ms単位のタイミングを要するリアルタイム制御は現場内で完結させる

遠隔地からは監視と非同期の設定変更のみを行う

通信経路の使い分け:

機械内部はEtherCAT等の産業用リアルタイムイーサネットで閉じる

遠隔PC、クラウドとは標準EthernetまたはVPN経由で、秒単位の遅延まで許容される情報のみをやり取りする

近年の主流構成:

エッジコンピューティングの考え方に基づく構成が主流

現場側の小型PC、ゲートウェイでリアルタイム制御を完結させ、クラウドとは集約データのみを同期する

■ 8. バーチャルPLC化に伴う新たな依存リスク

依存対象の移動:

バーチャルPLC、ソフトPLCへの移行はPC-98問題の対策として有効

一方で依存の対象を専用ハードウェアから仮想化基盤、ドライバ層へ移動させているだけという側面がある

この点は楽観できず、新たなロックインポイントとして認識しておく必要がある

依存構造の4層:

最上位はIEC 61131-3準拠プログラムであるPLCアプリケーション（ロジック）

次にTwinCAT、CODESYS等のPLCランタイム

次にハイパーバイザー、リアルタイムカーネル拡張、専用ドライバといったリアルタイム化の仕組み

最下位はPC、NIC等の汎用ハードウェア

層ごとの標準化の度合い:

上2層のアプリケーションとランタイムは比較的標準化が進んでいる

下2層のリアルタイム化の仕組みとハードウェアの橋渡しはベンダー独自技術であることが多い

下2層が実質的な依存ポイントになりやすい

EtherCATマスター機能の依存:

Intel i210/i225等の特定チップセットのNICを前提とした専用ドライバでのみ確定的な低遅延通信が保証されることが多い

汎用NICでは性能やリアルタイム性が保証されないことがある

リアルタイムカーネル拡張の依存:

WindowsやLinuxの内部に割り込むタイプの製品が該当する

OSのバージョンアップに対してベンダー側が動作保証を追従してくれるかに依存する

ハイパーバイザーの依存:

Intel VT-x/VT-d等、特定CPU世代、チップセットの仮想化支援機能に依存することがある

将来のハードウェア世代でも同じ挙動が保証されるかはベンダーのロードマップ次第

PC-98時代との依存構造の比較:

PC-98時代は依存の中心が専用ハードウェア1点であり、障害時は部品調達不能で完全に詰む

バーチャルPLC時代は汎用ハードウェアとベンダー独自ドライバ、リアルタイム化技術の組み合わせが依存の中心

ハードウェア自体は代替可能だが、保証範囲外の組み合わせでは性能、安定性が保証されない

互換性マトリクスの管理コストが新たに発生する

対策としての互換性マトリクス確認:

どのCPU、NICチップセット、OSバージョンで動作保証するかを事前に確認する

保証範囲が広く、かつ継続的に更新され続けている製品を選ぶ

対策としてのオープン性の重視:

ドライバ、リアルタイム化技術のオープン性を見る

完全にクローズドな独自実装よりも、Linuxカーネル本体にマージされたPREEMPT_RT等の標準機能が望ましい

コミュニティベースで存続しやすい技術は特定ベンダーの方針転換の影響を受けにくい

対策としてのベンダー分散:

ハードウェアとソフトウェアを同一ベンダーで固めすぎない

ランタイム、ハイパーバイザー、ハードウェアを別ベンダーの組み合わせで運用できる構成が将来の代替手段確保に有利

対策としての枯れた技術の選択:

仮想化、リアルタイム化技術はまだ新しい分野も多い

複数世代のハードウェア交換を乗り越えてきた実績のある製品の方が将来リスクを低く見積もれる

(2026/08/14)

ソフトウェアファクトリーとは何か

ソフトウェアファクトリーとは何か｜こぎそ

要約:

■ 1. 速度と成果の溝

個人の生産性と組織の成果の乖離:

AIがコードを書き画面も作れるようになり、個人の生産性は確かに上がった

一方で組織の成果はそれほど伸びていない

速度向上が生む副作用:

作る速度が上がった分だけレビューが詰まる

品質のばらつきが広がる

誰も全体を理解していないコードが増えていく

速く作れることと良いものを出し続けられることのあいだには、まだ深い溝がある

この溝への答えとして、2026年に入りAI開発の文脈で「ソフトウェアファクトリー」が再び前面に出てきた

■ 2. ソフトウェアファクトリーの定義

ソフトウェアファクトリー:

AIエージェントを工場の作業者とみなす開発体制

人間が工程を設計し、ソフトウェアを継続的に量産する

具体的なフロー:

標準化された形式で仕様が投入される

複数のエージェントが実装とテストを進める

人間とエージェントの成果物が、同じ検査工程を通る

良品条件を満たしたものだけが出荷される

良品条件の範囲:

機能要件だけではない

テスト、セキュリティ、性能、アクセシビリティ、デザインの一貫性など、出荷を認める条件全体を指す

この流れが何本も並行で毎日回り続け、主語は個人の技術から組織の工程に移った

工場という比喩への抵抗:

ソフトウェア開発は創造的な仕事でありベルトコンベアとは違うという反発が、この言葉の歴史の中で繰り返されてきた

それでも再浮上しているのは、実装という工程に限れば継続的に量産する条件が揃い始めたため

■ 3. いま語られ始めた背景

AI Engineer World's Fair 2026:

2026年6月末にサンフランシスコで開催された、6,000人以上が集まる世界最大級のAIエンジニアリングカンファレンス

本会議初日の6月30日には、メインステージのトラック名として「Software Factories」が掲げられた

Microsoft、OpenAI、Factory、HumanLayerなどがこのテーマで講演した

CursorのFDE部門を率いるPauline Brunet氏:

顧客の現場に入り開発体制を一緒に構築するForward Deployed Engineering部門を統括する

会場でのインタビューで、顧客組織とAIソフトウェアファクトリーを構築していると語った

Stripeの実績:

Minionsと呼ばれるコーディングエージェントが、人間の書いたコードを含まないプルリクエストを毎週1,000件以上本番へ送り出している

ただし出荷前のレビューと承認は人間が担当する

OpenAIの実績:

3人のエンジニアがCodexを動かし、手書きコードなしで内部向けベータ版を5か月で構築した

リポジトリはアプリケーション、インフラ、ツール、ドキュメントを含めて約100万行に達した

マージされたプルリクエストは約1,500件に到達した

論点の移動:

個人がAIで速く書く段階はすでに終わった

エージェントの群れに開発を任せる体制をどう組むかへ論点が移った

企業側の動き:

FactoryのようなAIネイティブの開発基盤が、IDEからCIまでをつないでいる

コンサルティング会社も、エージェントを前提とした開発体制を扱い始めた

個人側の動き:

Geoffrey Huntley氏が広めたRalph Loopがある

毎回まっさらなコンテキストでエージェントを起動し、一つのタスクを処理させ、結果をファイルやGitに残して次のループへ進む

巨大なエージェントに長い仕事を任せるのではなく、短い実行を繰り返す

上から工程全体を設計する動きと、下から小さなループを積み上げる実践が、同じ開発体制へ近づいている

■ 4. 日本由来の語源

ソフトウェアファクトリーは新語ではなく、構想の起点は米国だが最初に組織として形にしたのは日本である

1968年: Bob Bemer氏が、標準化された道具と管理環境を備えたソフトウェア工場を提唱

1969年: 日立が、世界で初めて「ソフトウェア工場」を名乗る開発組織を設立

1975年: 米国のSystem Development Corporationがソフトウェア工場を実験

1976年から1977年: 東芝、NEC、富士通が工場型の開発体制を展開

1991年: MITのMichael Cusumano氏が『Japan's Software Factories』を出版

2004年: Microsoftが、パターン、モデル、フレームワークを組み合わせる方法論として再定義

2017年: 米空軍がKessel Runを立ち上げ、国防分野でもソフトウェアファクトリーという呼び名が使われる

当時と現在の違い:

当時の中心にあったのは標準化、再利用、品質管理

2026年の再解釈では、実装を担う主体としてAIエージェントが加わる

人間の仕事は、意図を定義すること、工程を設計すること、出てきた成果を検証することへ寄っていく

■ 5. 工房の品質と工場の品質

品質の根拠の違い:

一点物を作る工房では、作り手の腕が品質を大きく左右する

工場では、作り手の技術に加えて、どの工程を通ったかが品質の根拠になる

入力の標準化:

スコープや受け入れ条件が、同じ形で入ってくる

共通の検査:

人間が書いた変更も、エージェントが書いた変更も、同じ検査を通る

出力の測定:

サイクルタイムや欠陥率などを測定できる

再現性:

出荷した変更を、入力・プロンプト・モデルのバージョンから再現できる

生成AIは同じ入力から毎回まったく同じ結果を出すとは限らない

必要なのは完全な再現性より、何をもとに、どの環境で、どのように作られたかを後から追えること

個人の腕前の位置づけ:

個人の腕前が不要になるわけではない

その腕を、組織で再利用できる基準と工程に移せるかが問われる

品質の根拠が「誰が作ったか」だけでなく、「どの条件を満たし、どの検査を通ったか」に移る

■ 6. 工場を成立させるハーネス

Addy Osmani氏による定義:

元Googleのソフトウェアエンジニアが構造を整理した

ソフトウェアファクトリーを「ハーネスを付けたループを、大きな規模で動かすこと」と説明する

ハーネスの構成要素:

ループを囲む仕組みであり、実行環境と使える道具を含む

実行をまたいで残る記憶、権限、そして何をもって完了とするかを決めるゲートを含む

工場という全体像:

ハーネス付きのループが何本も同時に回り、仕事のキューから供給を受ける

検査とレビューを通って本番に流れ込み、障害やユーザーの声は再びキューに戻る

人間は全体の設計と責任を担う

巨大なエージェントを一体育てる方向とは異なり、小さなループが役割を分担し受け渡しと検査でつながる、ループでできた組織図である

WorkOSのRyan Cooke氏の指摘:

同カンファレンスで「No, That's Not a Software Factory」という講演を行った

サンドボックスを用意しエージェントを何体か並べただけでは工場にならない

成果を安定させる要素:

成果を安定させるのはモデルだけではない

その周囲にある規約、実行環境、検証ゲート、完成の定義である

エージェントに任せる範囲が広がるほど、任せ方を定義する構造の側が重要になる

■ 7. デザインハーネスとの重なり

デザインハーネス:

2026年5月から提唱している考え方

制約、コンテキスト、検証、フィードバックループの4層で、デザインの判断をAIが読める仕様に落とす

ソフトウェアファクトリーの条件と比べると、必要な部品が大きく重なる

標準化された入力には、制約とコンテキストが必要になる

共通の検査には、検証可能な品質基準が必要になる

出力の測定には、結果を次の実行へ戻すフィードバックループが必要になる

追跡可能性には、判断の根拠や変更履歴を残す仕組みが必要になる

部品が重なる理由:

別々の議論が似た部品を必要とするのは、エージェントへ仕事を任せる際の問題が共通しているため

エージェントは組織の暗黙知や品質基準をそのままでは読めない

制約として渡し、結果を検証し、失敗から基準を更新する必要がある

エージェントに案件を任せるなかで作り込んできたのも制約や検証の仕組みであり、工場でいえば検査工程にあたる

ソフトウェアファクトリーという名前があることで、個別のプロンプトやツールの話ではなく組織の開発工程として議論できる

■ 8. デザインとの親和性

工場が送り出すもの:

工場が送り出すのはコードだけではなく、利用者が触れるソフトウェアである

良し悪しを決めるのは、画面の一貫性、文言のトーン、操作したときの反応、エラー時の振る舞いといったデザインの判断である

良品条件のかなりの部分は、デザインの言葉で書かれる

良品条件の具体例:

指定外の色や余白が使われていないか

キーボードだけで操作できるか

ローディング、空、エラーの状態が揃っているか

文言がトーンの規約に沿っているか、画面差分が許容範囲に収まっているか

こうした条件を機械と人が確認できる形にすれば、デザインは実装前の制作物ではなく出荷判定の一部になる

現場で起きている変化:

AIがある程度デザインできるとわかった時点から、品質をどう担保するかという相談が増えた

工場化の相談は、多くの場合、品質基準の相談として持ち込まれる

工場化の適用範囲:

すべての開発が工場になるとは考えていない

何を作るべきかがまだ決まっていない探索段階では、人間の観察と判断が必要になる

工場が扱いやすいのは、意図と良品条件をある程度定義できる仕事である

探索が消えるのではなく、探索と量産の境界を設計する必要がある

■ 9. 「暗い工場」の失敗

明るい工場と暗い工場:

Osmani氏は製造業の無人工場になぞらえ、人が判断に関わる工程を「明るい工場」と呼ぶ

機械の検証だけで出荷する工程を「暗い工場」と呼ぶ

暗い工場とは、人がいない工場では照明をつける必要がないという意味である

明るい工程:

間違えたときの影響が大きい場所に、人の設計やレビューを残す

暗い工程:

完了を機械的に判定できる仕事を、人が読まずに出荷する

工程ごとのスイッチ:

組織全体を二つに分類する話ではない

どのループを暗くできるか、工程ごとにスイッチを決める話である

小さく、失敗を自動で判定でき、影響範囲も限られている変更は暗くできる

認証、課金、公開API、長期的な設計判断のように影響が大きい工程には人を残す

HumanLayer社の実験:

AIコーディングIDEとチーム向け開発基盤を提供する同社が、約4か月、人が生成コードを読まない全自動の開発を試した

創業者のDex Horthy氏によれば、障害が起きたとき、すでに人間の理解から離れていたコードを読み直し手作業で原因を突き止めることになった

テストは通っているのに、中身を理解している人がいないコードが増えていた

理解負債:

Osmani氏はコードの量と人間が理解している範囲の差をこう呼ぶ

暗い工場はレビュー待ちをなくせるが、同時に理解負債を速いペースで積み上げる

同一エージェントによる自己検証の問題:

コードとテストを同じエージェントが同じ前提から作ることが問題となる

仕様を誤解したまま実装し、その誤解に沿ったテストを書けばテストは通る

緑色のチェックだけでは、意図に合っているかを証明できない

検証こそが制約:

生成量は計算資源を増やせば拡大できるが、検証に使える人間の注意には限りがある

ソフトウェアファクトリーの制約は、どれだけコードを作れるかではなく、どれだけ安く速く確実に検証できるかである

工場化の明暗を分けるのは検品の設計である

検品設計で問うべきこと:

どの工程は自動検査で足りるのか、どこに人の目を残すのか

誰が良品条件を定義し、失敗したときに責任を持つのか

自動化できる工程を増やすには、まず検証できる工程を増やす必要がある

■ 10. 基準の言語化

人間の持ち場の移動:

人間は工場から消えたのではなく、持ち場が移った

ラインの中で変更を一つずつ作る側から、ラインを設計し重要な判断に参加し出口のゲートを守る側へ移る

これからのデザインに求められるもの:

作れることに加えて、何を良いとするかを言語化できることの比重が大きくなる

良い画面を一度作れるだけでは、毎日動く工場の品質は保てない

判断を制約、規約、テスト、レビュー項目として残し、人間とエージェントの両方が使える形にする必要がある

経営側の打ち手:

個人にAIツールを配るだけでは、生成量が増えた先でレビューが詰まる

良品条件、検査工程、判断の責任に投資した組織ほど、量産の速度と品質を両立しやすくなる

ソフトウェアファクトリーを成立させるのは、エージェントの数ではなく、組織が自分たちの基準をどこまで工程にできるかである

(2026/08/14)

Webサービスの終わらせ方

Webサービスの終わらせ方

要約:

■ 1. サービス終了の困難さ

作るより消すほうが大変:

Webサービスは作成時より終了時のほうが面倒

サーバーを止めるだけでは終わらず、多数の撤去作業が残る

終了時に必要な作業:

新規登録停止、課金停止、書き込み停止

ユーザー通知、個人データ削除、Webhook停止

APIキー削除、DNS削除、リポジトリ整理

複数SaaS統合の代償:

各SaaSは導入が容易な一方、解約時はUIの異なる管理画面を巡回する必要がある

処分対象の技術スタック:

インフラはCloudflare Workers、Supabase、GitHub

APIはGemini API、監視はSentry、分析はGoogle Analytics

収益はPolarとGoogle AdSense、加えて独自ドメイン

■ 2. 終了方針の決定

まず「どう死ぬか」を決める:

終了方針の決定が最初の必須作業

方針がなければ削除の判断ごとに迷い、本番環境で試行錯誤する羽目になる

事前に決めるべき項目:

終了日、新規登録停止日、既存ユーザーに許す操作の範囲

購入済みコンテンツの扱い、データ削除期限、決済履歴の保持有無

サポート終了時期、ソースコードの保管方針、本番データのバックアップ有無

■ 3. 段階的な撤退戦

一撃必殺ではなく撤退戦:

一度にすべてを止めると、終了処理自体に必要な機能まで止まる

3段階の停止設計:

第1段階は新しい利用の停止

第2段階は終了日まで読み取り専用を維持

第3段階は完全停止とインフラ撤去

店舗の比喩:

新規客の入場禁止、来客をすべて帰す、在庫処分という順序に相当する

■ 4. 第1段階: 責任を増やさない

新規利用の停止:

新規登録、購入、回答保存、ペアリング、データ更新を止める

終了日後に新規ユーザーからサポート要請を受ける事態を避ける

ボタンを消して満足してはいけない:

UIはセキュリティ境界ではなく、APIを直接叩けばバイパスされる

玄関に本日休業と貼ったあと、裏口を全開にしている状態に等しい

停止すべきレイヤー:

画面・フォーム、サーバーAction、APIエンドポイント

認証サービス、DB権限（RLS）、決済設定

■ 5. 読み取り専用モードと認証停止

読み取り専用モードの実装:

終了日までは既存ユーザーによるデータ閲覧を許可する

環境変数 SERVICE_READ_ONLY で制御し、書き込みは403で拒否する

読み取り処理と書き込み処理が分離できているかの確認にもなる

Authもちゃんと止める:

フロント側のサインアップ画面を消しても、認証APIが生きたままでは不十分

認証APIを直接叩けばフロントエンドの制限をバイパスできる

認証側で行う対策:

Supabase側で登録を無効化する

RLSと権限設定により一般ユーザーの直接書き込みを拒否する

権限剥奪のやりすぎに注意:

終了するからと全権限を剥奪すると、終了処理自体が実行できなくなる

■ 6. ユーザーへの終了通知

通知に含める情報:

終了日、新規登録・購入の停止、終了日まで使える機能

アクセス不可となる時点、問い合わせ先、データの扱い

通知内容の記録:

人間の記憶はログではなく、終了作業中はとりわけ信用できない

■ 7. 完全停止用PRの事前準備

当日にコードを書かない:

終了日当日に本番環境で緊急にコードを書くリスクを避け、PRを事前に用意する

停止時のレスポンス設計:

Web画面は終了案内ページ、APIはJSON形式のエラーレスポンスを返す

ステータスコードは410 Goneとする

キャッシュ制御は no-store、SEO設定は noindex, nofollow とする

■ 8. スケジュール実行の不確実性

GitHub Actionsのcronは時刻を保証しない:

予約実行が予定時刻から大幅に遅延した

cronに23:59と書いても、cronは約束を覚えていない

代替手段:

事前実行で余裕を持たせる、外部スケジューラーを使う、当日手動で実行する

アプリケーション自体で時刻を判定する、CDN・DNS側で設定する

■ 9. デプロイ成功とサービス停止は別

CI成功でもサービスが止まらない:

停止処理をReact Routerのmiddlewareに実装した

設定が v8_middleware: false であり、機能自体が無効化されていた

コードは存在し、型チェック・テスト・ビルド・デプロイはすべて成功したが実行されなかった

確認すべき段階:

PRのマージ、ビルド成功、デプロイ成功

新バージョンへの経路確保、停止処理の実行、外部から見た期待レスポンス

緑のチェックマークの限界:

緑色のチェックマークは心を落ち着かせるが、本番環境を止めはしない

■ 10. curlによる最終確認

最後に信じられるのはcurl:

管理画面の状態表示ではなく、HTTPレスポンスを直接確認する

外からcurlして死んでいたら死んでいる、観測可能な事実のみを信頼する

確認方法:

curl -I でヘッダを確認し、curl -i で詳細を確認する

期待する結果:

410 Gone、SERVICE_CLOSEDエラー、no-storeのキャッシュ制御、noindexのロボット指示

接続不能の確認対象:

ルートドメインとwwwサブドメインが解決不可であること

Worker直接URLとAPI・Webhook URLが接続不可であること

■ 11. インフラ撤去の順序

撤去は順序が重要:

前後関係を誤るとサービス終了そのものに支障が出る

決済Webhookを最初に止める:

アプリケーション削除後も決済サービスがPOSTを再送し続ける

商品を販売停止または非公開にし、Checkoutを止め、Webhookを削除する

決済履歴は会計と問い合わせ対応に必要で、ユーザーデータと同じ保存方針では扱わない

Workerとドメインの削除:

Cloudflare Worker、Custom Domain、Worker Route、DNSレコードを削除する

Worker用のVariablesとSecrets、GitHubの自動ビルド連携も削除する

ドメインの自動更新停止は即時消滅を意味せず、契約期限まで存続する

即時停止にはDNSとRouteの削除が必要

ユーザーデータの削除:

Authユーザー、回答データ、利用履歴、購入権限、Storage内ファイルを削除する

本番ユーザーデータのバックアップは取らない方針を採り、一応ダンプしておく誘惑に抵抗する

削除日時、削除前後の件数、Authユーザー0件、Storage空、バックアップ未実施の判断を記録する

最後にSupabaseプロジェクト自体を削除し、確認ダイアログでプロジェクト名を入力する

APIキーを一つずつ失効させる:

Gemini APIキー、Sentryプロジェクト、Google Analyticsプロパティ、AdSenseサイト設定を処理する

Cloudflare Secrets、Supabase Personal Access Token、GitHub ActionsのSecretsとVariablesを処理する

プロジェクト削除は認証情報の自動失効を意味せず、明示的な失効が必須

ほぼ無害だろうという判断が危険を招く

GitHubリポジトリを墓石にする:

本番の秘密情報を無効化し、Actions SecretsとVariablesを削除する

不要なWebhookとDeploy keyを削除し、予約実行Workflowを無効化する

ローカルファイルを整理し、リポジトリを非公開にしたうえでArchiveする

DB構造とマイグレーションは参照・監査用にGitへ残し、本番ユーザーデータは残さない

■ 12. 敗戦処理チェックリスト

チェックリストの6区分:

方針、事前停止、最終停止、データ削除、外部サービス、最終整理の順に並ぶ

方針の項目:

最終終了日、新規登録・購入停止日、既存ユーザーに残す機能の明示

購入済みコンテンツの扱い、データ削除期限、バックアップ方針、問い合わせ先

事前停止の項目:

新規登録と新規購入の停止、書き込みUIと書き込みAPIの停止

認証サービス側の登録停止、DB権限とRLSの確認、対象ユーザーへの終了通知

最終停止の項目:

停止用変更の本番反映、WebとAPIのレスポンス確認

決済Webhook停止、Worker・サーバー削除、DNSとCustom Domainの削除

外部ネットワークからの接続不能確認

データ削除の項目:

Authユーザー削除、DB個人データ削除、Storage削除

削除結果の記録、本番バックアップ方針の確認、DBプロジェクト削除

外部サービスの項目:

決済商品とWebhookの停止、AI用APIキーの失効、エラー監視プロジェクトの削除

アクセス解析の削除、広告設定の削除、CI/CD Secretsの削除、Personal Access Tokenの失効

最終整理の項目:

ドメイン自動更新停止、ローカル秘密情報の削除

リポジトリの非公開化とArchive、問い合わせ先の維持、完了日時の記録

チェックリストの位置づけ:

サービス終了は機能開発と同等の正式な工程管理を要する

■ 13. まとめ

サービス終了の本質:

重要なのはコードを止めることではなく、責任を順番に片付けること

痛感した3点:

新規利用の停止はUI・API・認証・DBのすべてのレイヤーで行う

完了の判断はマージやデプロイの成功ではなく本番のHTTPレスポンスで行う

ユーザーデータ、決済履歴、ソースコードはそれぞれ別の方針で扱う

個人開発観の転換:

失敗したら閉じればいいという理解は誤り、サービス終了にも実装が必要

個人開発はデプロイまでではなくArchiveまで

最終的な教訓:

緑のチェックマークで満足せず、curlで検証する

終了日に元気に動作していたサービスが、この逆説的な教訓を残した

MEMO:

知見だ

(2026/08/14)

How Tailscale helped find the SQLite WAL-Reset bug

How Tailscale helped find the SQLite WAL-Reset bug

要約:

■ 1. 障害の経緯と謝罪

昨年末からの不安定な稼働率:

ステータスページに現れた傾向がそのまま年明けまで継続

多くの障害はSQLite深部に潜む単一のバグが原因

数か月に及ぶ徹底的な調査:

夏を迎えた現在、バグを発見し、理解し、修正したと確信している

顧客への謝罪:

Tailscaleに信頼性を期待する顧客の期待に数か月応えられなかった

何が起き、どう対応し、最終的にSQLite中核の長年のバグをどう発見したかを説明するために本記事を公開する

■ 2. 制御プレーンのアーキテクチャ

シャード構成の制御プレーン:

クライアントからはcontrolplane.tailscale.comという単一の公開エンドポイントに見える

内部的には複数の協調サーバ（シャード）に分割されている

テイルネットとシャードの関係:

各テイルネットは同時に1つの内部シャード上に存在し、シームレスに別シャードへ移行できる

シャードは内部実装の詳細であり、利用者が自分のシャードを知る必要はない

シャードごとのSQLiteデータベース:

各シャードはそのシャード上のテイルネット情報をすべて保持するSQLiteデータベースを持つ

単一のGoプロセスがそのデータベースを排他的に利用し、制御プレーンを提供する

この単一書き込み設計はSQLiteの本来意図された使い方そのもの

SQLite採用の理由:

2022年から主データベースとして使用

よく知られ、信頼でき、広く使われている「退屈な技術」であることを良い意味で評価した

他社もはるかに大規模な運用で問題なく使っており、同様に無風の運用を期待していた

バックアップの仕組み:

数分ごとにデータベース全体のスナップショットを取得し、SQLiteファイル全体をS3バケットへアップロードする

この構成は2023年初頭から無事故で稼働していた

■ 3. データベース破損の発生

最初の破損の検出:

昨年8月、S3バックアップを読むデータパイプラインが1つのデータベースでエラーを報告

PRAGMA integrity_checkをバックアップに実行したところ、実際に破損していた

破損の異常性:

SQLiteの破損は起こり得るが極めて稀であり、通常運用で遭遇すべきものではない

該当データベースを修復し原因を調査したが成果は得られなかった

破損の再発:

大規模運用では稀な事象もある程度の頻度で起こるため、再発に驚くべきではなかった

根本原因を解決するまでの6か月間で、合計19件の独立した破損が発生

■ 4. 破損がもたらした影響

データ消失の範囲:

制御プレーンは設定データのみを扱い、テイルネットとデバイスのメタデータを保持する

秘密鍵やネットワークトラフィックは一切含まれない

初期のインシデントでは、新規追加デバイスや設定変更が数件永続化されず、少量のメタデータの再入力が必要になった

修復中の停止:

破損のたびに該当シャードの制御プレーンプロセスを停止して修復または復元する必要があった

そのシャード上のテイルネットは復旧中に制御プレーン全体が消失するため苦痛を強いられた

初期は1時間超のダウンタイムだったが、インシデントを重ねるごとに復旧を高速化した

メッシュネットワークへの影響:

各テイルネットはデバイス同士がピアツーピアのWireGuard接続を張るメッシュネットワーク

デバイスは参加時に制御プレーンから他デバイスの一覧を取得しないと新規接続を確立できない

SQLite停止中にオンラインになったデバイスは接続できなかった

既存接続と管理機能:

修復中も既にオンラインのデバイス同士の接続は維持された

ただしネットワークの変更を知ることはできなかった

該当テイルネットは管理コンソールとTailscale APIへのアクセスも一時的に失った

信頼への広範な影響:

影響を受けるテイルネットが少数でもグローバルなインシデントとしてステータスページに掲載する

そのため自分に無関係なインシデント表示を多くの人が目にした

実際には大多数のシャードとテイルネットは破損に一度も巻き込まれていない

それでも直接の影響の有無にかかわらず、繰り返すダウンタイムは信頼を損なう

■ 5. 難航した初期調査

初期のあらゆる試みを退けたバグ:

最初の破損時点から信頼性への深刻な脅威と認識し、多大なエンジニアリング時間を投入したが修正は容易でなかった

変更履歴とコードの精査:

最近の変更を調べたが関連しそうなものはなかった

SQLiteと接する低レベルコードは数年前に書かれ、それまで問題がなく、誰も触っていなかった

該当コードを細部まで再レビューしたが、観測された破損を引き起こす欠陥は見つからなかった

共通要因の不在:

特定のシャード、顧客、テイルネット機能、時間帯、負荷水準のいずれとも結び付かなかった

何が挙動を引き起こしているのか見当がつかなかった

再現不能ゆえの受動的計測:

信頼できるトリガ条件がないため合成的に再現できなかった

本番環境に受動的なフォレンジック用テレメトリを仕込み、破損の現行犯を押さえるしかなかった

データベース障害の診断情報を本番で集めるのは最も避けたい手段だったが、選択肢がなかった

不規則な発生間隔:

数時間おきのこともあれば数週間空くこともあった

次の診断ダンプがいつ得られるか読めず、進捗予測と作業計画が困難だった

10月から12月にかけて6週間にわたり破損が止まり、その後クリスマスの歓迎せざる贈り物として再発した

■ 6. SQLite開発者との協業

プロフェッショナルサポート契約の締結:

迅速で容易な修正にならないと判断し、SQLite開発者にサポート契約を申し入れた

深い専門知識と経験に直接アクセスでき、アーキテクチャとインシデントについて詳細な技術的議論を重ねられた点で優れた判断だった

複数の仮説の検証:

close()時のPOSIXロックの破損、SQLiteが所有するメモリの誤管理、スレッド安全性を無効化した状態での複数スレッドからの誤使用などの理論を洗い出した

インシデントのたびにデータを集め、診断を追加し、体系的に理論を排除していった

真のバグへ徐々に収束していった

■ 7. 運用面の緊急対策

復旧の自動化とダウンタイム最小化:

根本原因の調査中も稼働中のプラットフォームを運用する必要があったため積極的な手を打った

具体的な施策:

破損検知時にシャードの制御プレーンを即座にハードストップさせる設定

バックアップに対しPRAGMA integrity_checkを継続実行する自動バックアップ監視の導入

ランブックとオンコール訓練の改善

効果:

対応時間を1時間未満に短縮した

■ 8. トランザクションログパイプラインと手がかり

新たな復旧手段の必要性:

直近の正常なバックアップへの巻き戻しは多くのデータを失う

破損済みデータベースの修復は潜在的に危険

どちらにも依存しない復旧方法を求めた

トランザクションログの仕組み:

データベースを変更するすべてのSQL文を別のログファイルへストリーミングする方式を構築

SQLiteは単一書き込みで直列化可能トランザクションのため、トランザクション履歴は完全に線形かつ決定的になる

PostgresやMySQLのような複数書き込みデータベースでは成立しない性質

復旧手順:

直近の正常なバックアップに対しトランザクションを再生することで、破損を安全に回避しつつ最新状態へ復元できる

予期せぬ手がかり:

2件のインシデントでトランザクションログがきれいに再生できなかった

あるトランザクションが書き込んでコミットしたデータが、後続のトランザクションから不可解に見えなくなっていた

書き込みがエラーも出さずに消失しており、本来あり得ない事象だった

■ 9. WALとチェックポイントの仕組み

ページ単位の構造:

SQLiteデータベースはページと呼ばれる情報の小さなブロックの連なりで構成される

更新時には一部のページを新しい情報を持つページに置き換える必要がある

ライトアヘッドロギングの採用:

性能と並行性を高めるためWrite-Ahead Loggingを有効にして運用している

新しいページはデータベースファイルへ直接書かれず、WALファイルへ書かれる

チェックポイント処理:

WALファイルに無制限に書き続けることはできず、いずれ本体のデータベースファイルへ書き戻す必要がある

この処理をチェックポイントと呼ぶ

手動制御という非標準運用:

通常の構成ではSQLite自身がチェックポイント時期を決め、利用者にも開発者にも不可視

制御プレーンでは高速で一貫性のあるバックアップのためチェックポイントを手動制御している

原因候補を消していく過程で、この非標準的手法が疑わしく見えてきた

統計値の異常:

破損時のメトリクスで、SQLiteがWALファイル内の実在ページ数より多くのページをコピーしたと報告していた

WALに10ページしかないのに20ページがデータベースへコピーされるのは明らかな異常

■ 10. tmstmpvfs shimによる可視化

SQLiteの階層構造:

最上層はパーサとコードジェネレータで、SQL文をSQLite内部のデータ構造へ変換する

内部データ構造はページャへ渡され、ディスクへ書く個々のページに分割される

実際のディスク書き込みはOSインターフェース、すなわち仮想ファイルシステムが担う

現在の主流の仮想ファイルシステム実装はUnix向けとWindows向けの2つ

層の差し替え可能性:

各層を別実装に置き換えたり、既存層をラップして情報を得たりできる

新しいデバッグツール:

チェックポイント処理にバグがあるとしばらく疑っていた

SQLite開発者は仮想ファイルシステムをラップし、追加のトレース情報とデータベース変更ログを出力するシムを作成した

このラッパーはtmstmpvfs shimと呼ばれ、ソースコードはSQLiteの公開リポジトリで入手できる

本番投入:

シムを本番環境へ投入し、次の破損を待った

幸か不幸か長く待つ必要はなかった

■ 11. WAL-Resetバグの正体

バグの特定:

次の破損後、tmstmpvfs shimの追加ログによりSQLite開発者がバグを発見し修正した

正体はチェックポイントと書き込みトランザクションの間で起きる稀なデータ競合

発生メカニズム:

チェックポイント中の特定のタイミングで書き込みが発生するとチェックポイント処理が混乱する

一部のページをWALからデータベース本体へコピー済みと誤認するが、実際にはコピーされていない

それらのページは永久にデータベースファイルへ書かれず、そのデータは失われる

失われたページを参照するインデックスなどの他のページは書き込まれるため、ファイルが破損する

バグの命名と歴史:

SQLite開発者はこれをWAL-Resetバグと命名した

少なくとも16年間SQLiteに存在していたと推定される

極めて稀であるがゆえに長期間残存し、テスト環境では意図的に発生させるコードを追加する必要があるほどだった

修正では、他スレッドによるWALのリセットを検知する追加チェックをチェックポイント関数に加えた

観測事象との整合:

このバグがすべての不可解な挙動の原因だと確認された

破損、きれいに適用できないトランザクションログ、一貫しないチェックポイント統計のすべてを説明した

遭遇しやすかった理由:

チェックポイントを手動制御し、非常に積極的な頻度で実行していた

稀な条件で起きるバグでもいずれ必ず踏むことになる状況だった

転機としての意味:

数か月の混乱と不確実性の末に、破損の妥当な理論と展開可能な修正を手にした瞬間

■ 12. 修正版の展開と二次的な問題

3.52.0の段階的展開:

SQLite開発者は修正をSQLite 3.52.0としてリリースし、公開次第すぐ展開する準備を整えた

まず少数のカナリアシャードへ、順調な稼働を確認してから残りの制御プレーンへ展開した

展開直後の警報:

バックアップ監視が即座に赤くなり、13のデータベースで破損を報告した

極めて憂慮すべき事態だったが、復旧手順に従ってすべて修復し、問題なく収束した

これらは真の破損ではなく、当該SQLiteバージョンの第二の問題によるものだった

陳腐化した式インデックスのバグ:

エラーをSQLite開発者と共有した結果、stale expression indexに関するバグが判明した

計算値にインデックスを作成した後に計算内容が変わると、インデックスに不一致な値が残る

その不一致がPRAGMA integrity_checkで破損として報告される

自社側の該当条件:

高精度タイムスタンプをテキストとして保存し、VIRTUAL生成列で浮動小数点数へ変換していた

データ競合を修正した3.52.0は、テキストから浮動小数点数への変換の丸め挙動を微妙に変える最適化も含んでいた

カナリアシャードには変化した丸め挙動を引き起こすタイムスタンプが存在せず、段階的展開で検知できなかった

双方の対処:

誤検知を招くため、SQLite開発者は3.52.0を撤回し、WAL-Resetバグの修正のみを含む3.51.3を公開した

自社側はタイムスタンプの精度を整数秒へ落とすことで対処した、テキストから整数への変換は曖昧さがない

SQLite開発者は3.53.0で自動的に自己修復するインデックス機能を作り、陳腐化した式インデックス問題を防いだ

■ 13. 修正の実証

慎重な姿勢:

制御プレーン全体へ修正を展開し勝利宣言をしたかったが、なお慎重であった

破損が起きないことは修正の証明にならない、既に6週間の欺瞞的な平穏を経験している

積極的な証明手段:

本番環境でデータ競合が実際に起きている積極的な証拠を求めた

書き込みトランザクションとWALリセットの衝突が原因と理解した上で、両操作が重なった際に警告を記録するようSQLiteドライバへパッチを当てた

警告が出てもデータベースが破損しなければ、修正が破損を防いだと判明する

待機と発火:

警告を展開して待ち続けたが何週間も発火せず、警告の不具合や理論の誤り、真のバグの残存を疑い始めた

2か月後、待ち望んだアラートがついに発火した

結論:

このアラートはWAL-Resetバグの発生条件が本番環境で実際に起きることを証明した

6か月に及ぶ不安定な稼働の原因がこのバグである可能性が高いと結論づけた

そのアラート以降、本稿執筆時点でさらに4か月間データベース障害なしで稼働している

■ 14. 教訓と成果

全体の総括:

6か月をSQLiteのバグ探しに費やすことなど誰も望んでいなかった

顧客にとっても社員にとっても極めて苛立たしい経験であり、この不安定さを過去のものにできて安堵している

非標準運用のリスク:

退屈な技術を非標準的な方法で運用することはリスクである

一般的な経路と標準構成は極めてよくテストされ信頼できる

大多数の利用者は標準構成でSQLiteを使い、この種の問題に遭遇しない

自社の位置づけ:

実施していたことはすべて公開され文書化された、サポート対象の構成だった

それでもチェックポイントを手動制御し独自の積極的な頻度で走らせたことで、踏み固められた運用の道から外れていた

関係者への謝意:

解決はTailscaleのエンジニアリングとサポート、SQLiteのコアメンテナを含む数十人規模の横断的な取り組みだった

影響がこれ以上悪化しなかったのは全員の功績

繰り返すダウンタイムは影響人数にかかわらず信頼を損なうと理解しており、追跡中の顧客の忍耐と支援に感謝する

得られた成果:

苛立たしい期間ではあったが、以前より強い状態に立っている

SQLiteの長年のバグが修正された

探索の過程で見つけた他の数十件の付随的な問題も修正した

競合状態の切り分けを即座に助けたオープンソースのSQLite VFSシムに資金を提供し、将来の類似バグ追跡にも役立つ

データベースのバックアップと復旧の手順を洗練させ、十数回にわたり実地で検証した

今後への構え:

同種のデータベース障害が再び起きないことを願うが、起きたとしても備えはできている

(2026/08/13)

EM選考プロセスを公開します〜面接で何を見ているか、なぜそう設計したか〜

EM選考プロセスを公開します〜面接で何を見ているか、なぜそう設計したか〜 - ROXX開発者ブログ

(2026/08/13)

Cloudflareは16年間ずっと同じことをしている。「通り道を支配する」という設計思想を知る

Cloudflareは16年間ずっと同じことをしている。「通り道を支配する」という設計思想を知る

(2026/08/13)

Google、開発者向けブログでGo言語がAIを活用したソフトウェア開発に適している理由を解説

Google、開発者向けブログでGo言語がAIを活用したソフトウェア開発に適している理由を解説 | gihyo.jp

(2026/08/12)

ExtendDB

■ 1. ExtendDBの概要

DynamoDB互換アダプター:

Amazon DynamoDBのAPI（ワイヤープロトコル）と互換性を持つオープンソースソフトウェア

AWSがメンテナンスを担当

コンセプト:

DynamoDBのSDK・クライアントコードはそのままに、実際のデータ保存先を自分のインフラへ置き換えられる

キャッチコピーは「同じSDK・同じコードで、自分のインフラで動かす」

■ 2. 仕組みと対応範囲

リクエストの流れ:

アプリはこれまで通りDynamoDBのSDK（boto3など）でリクエストを送る

ExtendDBがそのリクエストを受け取り、選択したストレージバックエンドへ変換・ルーティングする

アプリ側の変更:

変更点は接続先のendpoint_urlをExtendDBに向けるだけ

アプリコード自体の変更は不要

対応バックエンド:

PostgreSQLはリファレンス実装であり、テストスイートで検証済み

Apache Cassandraはコミュニティ提供

インターフェースとして定義されており、その他コミュニティによる追加が可能

対応操作:

CRUD、Query、Scan、バッチ処理、トランザクション、Streams、式(expressions)、TTLなどに対応

■ 3. 主なユースケース

ローカル開発:

AWSアカウントやネットワーク不要でノートPC上で動作

CI・統合テストにも利用可能

クラウドとオンプレの標準化:

既存運用中のDBの上でDynamoDB APIを提供する

ハイブリッド構成を実現できる

切断環境への展開:

工場、店舗、車両などクラウド接続が不安定または不可能な場所でも動作する

エッジ環境、エアギャップ環境が対象

■ 4. ライセンスとコスト

ライセンス:

Apache 2.0ライセンス（特許許諾条項あり）でオープンソース公開

コスト構造:

ExtendDB自体は無料

発生するコストはコンピュート・ストレージなどインフラ分のみ

■ 5. 制限事項

セルフホストで使えない機能:

DynamoDBのフルマネージドサービスに紐づく機能はセルフホスト環境では利用不可

グローバルテーブル、オートスケーリング、バックアップ/リストア、DAXなどが該当し、FAQに明記されている

■ 6. 性能

PostgreSQLバックエンド:

単一アイテム操作が10ms未満のレイテンシ

Cassandraバックエンド:

水平スケーリングにより数千リクエスト/秒に対応可能

■ 7. 公開状況

2026年5月20日にAWS Database Blogで正式発表

GitHub（ExtendDB/extenddb）でソースコードとドキュメントを公開

MEMO:

DynamoDBを使いたい時というのはスケーリング能力が欲しい時で、別にDynamoDBのAPIそのものはそこまで重要ではないように思うのだが
DynamoDBの互換APIを使いたいが、AWSにデータを保存できないという特殊な要件が前提になるが、そんな要件が指定されることはかなり稀だと思われる
そう考えるとテスト以外の用途はほとんど存在せず、それすら既存のDynamoDB Localと競合している
テスト用途ではExtendDBはPostgresSQLバックエンドを必要とする分、DynamoDB Localより構成が複雑化するハンデもある
発想は面白いが使い道が思いつかないプロダクトである

(2026/08/12)

「プロダクトビルダー」の時代が来る ― PdM・デザイナー・エンジニアの垣根が溶けたあと...

「プロダクトビルダー」の時代が来る ― PdM・デザイナー・エンジニアの垣根が溶けたあと、デザイナーの武器は何か｜そわか

要約:

■ 1. プロダクトビルダーの時代

書き手の立場:

toB SaaS専門のUX/UIデザイナーとして複雑な業務ドメインのプロダクトを12年以上手がけてきた

プロダクトビルダーという概念:

PdM、デザイナー、エンジニアという職種の垣根がなくなり、全員が「作る人」になっていく流れを指す

実感の裏付け:

個人開発でまさにその状態を体験しているため、この話には確かにそうだと感じた

本稿の射程:

海外で起きていることの整理、一人で全役割をやって分かったこと、垣根が溶けた後にデザイナーへ残るものを扱う

■ 2. 海外で進む職種再編

雰囲気ではなく構造変化:

職種の再編は組織構造の変化として現れ始めている

LinkedInの事例:

新卒PMの登竜門だったAssociate PMプログラムを廃止し、「Product Builder」トラックに置き換えた

プロダクト、デザイン、エンジニアリングを横断してローテーションする育成方式である

PM、デザイナー、エンジニアを統合した役割への組織再編も進めている

職種を分けて成果物を受け渡すという前提そのものを見直している

求人市場の変化:

900名超のデザイナーを調査した「AI in Design」レポートの周辺で新しい職名の出現が報告されている

「designer engineer」「builder」「design crafter」といった従来の枠に収まらない職名が求人に現れ始めている

■ 3. 分業が逆転する構図

従来の直列分業:

PdMが定義し、デザイナーが形にし、エンジニアが実装するという受け渡しで開発は動いてきた

各工程が高コストで専門家を専任させる必要があったため、この分業が成立していた

AIによるコスト低下:

PdMがプロトタイプを作り、デザイナーがコードを書き、エンジニアが画面案を出せるようになった

ただしこれはたたき台やプロトタイプの水準に限られる

最大コストの移動:

受け渡しのたびに発生する待ち時間と伝言ゲームこそが最大のコストになった

一人または少人数が全域に手を伸ばす方が速いという逆転が起きる

ボトルネックの所在:

エンジニアの工数から「何を作るべきかの判断」へ移った

海外の議論はおおむねこの点で一致している

■ 4. 日本での動き

メルカリの経営方針:

2026年7月の新年度経営方針発表でグループテーマとして「AI-Native for Hypergrowth」を掲げた

AIを前提にプロダクトも組織も働く人自身も変えていくという宣言である

自律型AIエージェントを全社員の働き方に組み込む取り組みも始まっている

Figma主催イベントでの言及:

メルカリの登壇者から、職種の垣根を越えて自ら作るビルダー的な人材と体制への言及があった

公式な制度としての詳細は公開されていないが、現場レベルでその方向に動いているのは確かである

経営アジェンダ化:

AIを前提にした職種と組織の再定義は、日本の大手プロダクト企業でもすでに現実の経営アジェンダになっている

■ 5. 一人で全役割をやった体験

開発中のプロダクト:

幹事がグループにアンケートを取るためのモバイルアプリを個人で開発している

Expo（React Native）、Vercel、Supabaseで組んでいる

企画も仕様もデザインも実装もすべて自分が担い、PdMとデザイナーとエンジニアを一人で兼ねている

発見1: 脳内で完結する職種間の会話:

実装が重くないか、このUIは要件を満たしているかといった往復が脳内で瞬時に終わる

手戻りがほぼゼロになり、この速さは体験すると戻れない

受け渡しコストの大きさは、なくなって初めて実感した

発見2: 最も重い「何を作らないか」:

作る力がAIで拡張されると作ること自体は進む

詰まるのは機能を足すか削るか、どの順で作るか、誰のどの課題を最優先にするかという判断である

PdMの仕事の正体は調整ではなく判断だと、一人になってようやく骨身に沁みた

発見3: 良し悪しを決める12年の蓄積:

AIと組めばコードは書け、画面もAIが出してくる

出てきたものが良いか悪いか、ユーザーにとって成立しているかの判断はAIに任せられない

そこで働いていたのは12年やってきたデザイナーとしての目である

越境したことで逆に自分の専門性の所在がはっきり見えた

■ 6. 越境しても届かない深さ

届く範囲と届かない深さ:

越境して痛感したのは、届く範囲と同じくらい届かない深さがあることだった

AIでは代替できない領域:

アーキテクチャの設計、セキュリティ、パフォーマンス、障害への備え、スケールする構造が該当する

これらは動くものが作れることとはまったく別の話である

個人開発の前提条件:

自分の個人開発は小規模だから成立している

本番環境、大量のユーザー、守るべきデータを抱えるシステムではエンジニアの専門性なしに立ち行かない

勘違いへの戒め:

AIでコードが書けるからエンジニアの領域を越えられるというのは、控えめに言っても勘違いである

見えているのは氷山の一角で、水面下にはすぐには越えられない専門性の壁がある

これはデザインの領域に踏み込んでくる他職種に対して抱く感覚とまったく同じ構造である

■ 7. 溶けない一芸

専門性は不要にならない:

専門性が要らなくなるのかという問いへの答えは明確にノーである

Dylan Field氏の見立て:

チームは領域を越えて貢献できるプロダクトビルダーで構成されるようになる

各人は一つの領域に深いクラフト（熟練）を持ち続ける

この世界でデザインはむしろ重要になる

プロダクトビルダーの定義:

何でも中途半端にできる人ではなく、深い一芸を持ったまま全域に手が届く人である

誰もが作れるようになるからこそ、アウトプットの差は一芸の深さで決まる

職種横断の一芸:

エンジニアにとってのアーキテクチャ設計や信頼性の担保も溶けない一芸である

PdMにとっての事業判断も同じく溶けない一芸である

ビルダーの時代の本質:

互いの一芸が浅くなる時代ではない

それぞれの一芸を核にした越境者同士が、より深いレベルで協働する時代である

■ 8. デザイナーの武器

デザイナーの一芸:

体験の質を判断する目である

差がつく場所:

AIが画面を量産する時代、作る速さでは差がつかない

量産された選択肢から成立しているか否かを見抜き、直すべき点を特定する力で差がつく

この力は一朝一夕には育たず、だからこそ武器になる

目だけでは活きない:

デザイナーがビルダーにならないまま目だけを持っていても、これからは活きにくい

判断は作る流れの中にいてこそ効く

深い目を持ったまま企画にも実装にも手を伸ばすのが、デザイナー出身のプロダクトビルダーの形である

■ 9. 会社員デザイナーの第一歩

提案1: 個人開発:

小さくてよいので自分の困りごとを解くアプリをAIと組んで作ってみる

企画から実装までを一人で回す経験は越境の練習として最良である

個人開発を通して得た気づきが、そのまま本業の視点を広げてくれている

提案2: 開発の構造を学ぶ:

コードが書けるようになる必要はない

要求がどう要件になりどう実装されるのか、フロントエンドとバックエンドがどう分かれているのかを理解する

構造を理解しているだけで越境の解像度がまったく変わる

ビルダーの世界では、作れるの手前にある「作られ方が分かる」が土台になる

■ 10. まとめ

垣根が溶ける理由:

AIが実行コストを下げたことで、分業は受け渡しの遅さという弱点を露呈した

海外では職名と組織構造の再編がすでに進行中である

溶けるものと溶けないもの:

溶けるのは職種の境界線であって一芸の深さではない

全員が作れるようになる世界では、深い一芸こそが差になる

目指す転換:

デザイナーにとっての一芸は体験の質を判断する目である

その目を持ったまま企画へ、実装へ手を伸ばしていく

「デザイナーです」から「デザインが一番深い、プロダクトビルダーです」への転換の途中にいる

(2026/08/11)

入門再発防止策

入門再発防止策 - Speaker Deck

要約:

■ 1. 再発防止の定義

再発防止の本質:

失敗しにくい仕組みを作ること

人間の努力の限界:

人間はミスし、忘れ、疲れ、焦る

人間が頑張ることには限界がある

再発防止で目指す状態:

ミスを起こしにくくする

ミスしても壊れにくくする

壊れても早く気づけるようにする

システム側の改善:

人ではなくシステム側の改善が重要

■ 2. 原因除去のみの限界

原因を潰すだけでは不十分:

設定ミスで障害が発生し設定を修正しても、別の設定ミスは防げない

深掘りすべき問い:

なぜ危険な変更ができたのか

なぜ検知できなかったのか

なぜ影響が広がったのか

■ 3. 再発防止のゴール

ゴールは障害ゼロではない:

発生確率を下げる

影響を小さくする

早く検知する

早く復旧できるようにする

目指すべき状態:

次はもっとマシに壊れる状態を作ることが重要

■ 4. アンチパターンな再発防止策

たまによく見る形骸化した対策:

気をつけます、レビューを徹底します、手順をちゃんと確認します

朝会で共有します、気合いで、といった精神論の対策

ありがちな失敗:

ポストモーテムを書いて終わる

TODOだけ積まれる

優先順位が低く放置される

オーナー不在

振り返り会後の熱量低下:

障害の日から日付が経つごとに熱量が下がる

誰もやらず数週間後に同じ原因で再発する

SREとしては悔しい結果になる

■ 5. 放置される問題と処方箋

放置される問題:

再発防止策が取られないまま放置される事態はよくある

障害対応中は懸命に直すが、復旧後は他にやることが多く後回しになる

処方箋(1) オーナーと優先度:

ポストモーテムでオーナーを決定させる

その場にPMを呼んで優先度を判断させる

最重要以外をやらない判断をとる勇気も重要（なんとなく不安だから作ったToDoのようなものを削除、など）

四半期に一回程度の棚卸しを行う

処方箋(2) その日のうちの対応:

その日の障害はその日のうちに対応する

AIがある現在では、超複雑でない限りその日にできることは意外と多い

■ 6. 良い再発防止策の条件

良い再発防止策の要件:

人の注意力に依存しない

自動化されている

継続可能である

システムで制御される

誰でも実行できる

防ぐだけが再発防止ではない:

早期検知

自動復旧、フェイルオーバー

Rollbackの高速化

Runbookの整備

■ 7. 再発防止策の考え方

問いを分けて考える:

なぜ起きたか

なぜ検知できなかったか

なぜ影響が広がったか

なぜ復旧が遅れたか

レイヤーで見る視点:

障害は1箇所だけで起きるわけではない

設計、実装、デプロイのレイヤー

監視、運用のレイヤー

組織、コミュニケーションのレイヤー

複数レイヤーに問題が存在する

防御ラインを増やす:

1つの対策で完璧を目指さないことが重要

Validation、Alert、Rollback

Feature Flag、Canary Release

複数の防御ラインを持ち事故を小さくする

■ 8. AIとSRE

AIは人間の置き換えではない:

AIによってSREは運用作業の自動化から信頼性を設計する役割へ進化している

障害対応、異常検知、RCA、Toil削減に大きな変化が起きている

本番導入の前提条件:

AIは確率的に動作する

透明性、段階的権限管理、ロールバックなど安全性を前提とした設計が必須

最終的なゴール:

AI Operatorのような仕組みを通じ、信頼性がデフォルトで組み込まれたシステムを実現すること

SREの役割の変化:

障害対応する人から、信頼性を自己進化させる仕組みを作る人へ変わっていく

■ 9. まとめ

再発防止は反省会ではない

人を強くするより、システムを強くする

気をつけるには限界がある

小さく改善を積み重ねることが重要

■ 10. 参考資料

Postmortem Culture: Learning from Failure

Blameless PostMortems and a Just Culture

Incident postmortems

Whose fault was it anyway? On blameless post-mortems

Post-incident review best practices

(2026/08/11)

sandboxd -- Self-hosted, open-source AI app builder

要約（What is sandboxd?）:

■ 1. sandboxdの概要

AIアプリビルダーの基盤エンジン:

オープンソースであり、自分のサーバー上で動作する

各アプリを専用の隔離サンドボックス内で実行する

サンドボックスの構成要素:

専用コンテナ、ファイルシステム、メモリ制限

組み込みのAIコーディングエージェント、ライブプレビューURL

用途の広がり:

大半の利用者はアプリビルダーとして構築する

同一エンジンがエージェント基盤、プレビュー環境、80以上のワンクリックOSSアプリも動かす

提供形態:

セルフホスト、オープンソース、1コマンドでインストール完了

■ 2. 1回のHTTPリクエストで起きる3つの動作

サンドボックスの作成:

プライベートで隔離されたLinuxコンテナを生成する

あるユーザー、エージェント、ブランチのコードが他のものを参照したり破壊したりできない

コードまたはAIエージェントの実行:

任意のコマンドのexec、API経由でのファイル書き込みが可能

プロンプトを渡してエージェントに構築させることもできる

OpenCodeとClaude CodeのCLIがプリインストール済み

ライブURLの付与:

サンドボックス内で動くdevサーバーが共有可能なプレビューリンクで即座に到達可能になる

ルーティングとTLSは自動で処理される

エンドポイントの対応関係:

POST /sandbox でプライベートな隔離コンテナが起動する

POST .../tasks でAIエージェントがその中にアプリを書く

http://.preview... でそのアプリが専用URLで公開される

■ 3. 低コストな運用

アイドル時の自動スリープ:

誰も使っていないサンドボックスは停止し、メモリを解放する

リンクアクセス時の即時復帰:

誰かが再びリンクを開いた瞬間に起動する

ファイルはその間ずっとディスク上に保存されている

収容密度の向上:

1台の通常のサーバーで多数のユーザー、エージェント、ブランチを保持できる

それぞれに仮想マシンを1台ずつ用意する必要がない

■ 4. 意図的に小さいアーキテクチャ

構成技術:

Dockerに指示を出す1つのGoプログラム

TraefikがURLを担当し、SQLiteがデータベースを担当する

採用しない技術:

Kubernetes、独立したデータベースサーバー、メッセージキューを使わない

可読性の高さ:

全体を半日で読み通せる規模

ホスト側の全体像:

ホストに必要なものはDockerのみ

ブラウザからTraefik経由でサンドボックス内のコーディングエージェントとdevサーバー(:3000)へ到達する

API/CLIはsandboxdを呼び、workspaceディレクトリが永続化される

SQLiteが信頼できる唯一の情報源となり、アイドルで停止、リクエストで起動する

■ 5. sandboxd上で動かすもの

単一目的の製品ではなく構成部品:

作成、構築、プレビュー、スリープ、起動という同じループが多様な用途を支える

AIアプリビルダー製品:

ユーザーが「todoアプリを作って」と入力すると動くWebサイトが専用リンクに現れる種類の製品

Lovable、Bolt、v0、Replitに相当するものを自分のサーバー上で実現するOSSバックエンド

エージェント基盤と社内エージェント実行:

すべてのコーディングエージェントに隔離ワークスペースと実際のライフサイクルを与える

プロンプト送信、SSEによる進捗ストリーミング、永続的な結果の取得が可能

プロバイダを一度接続すれば認証情報注入プロキシが鍵をサンドボックス外に保ち、何も自社インフラの外に出ない

ユーザー単位・ブランチ単位のプレビュー環境:

開発者、ブランチ、プルリクエストごとに共有可能なライブURLを与える

再起動しても存続し、アイドル中はコストがかからない

コーディングプレイグラウンド:

使い捨てでリソース上限付きの環境を配布する

1人のユーザーが他の全員を巻き込んで停止させることがない

チーム向けのマルチアプリホスティング:

多数の小規模な社内アプリを1台のマシンで運用する

各アプリが専用の整ったURLを持ち、アイドルで停止し次のリクエストで起動する

SaaS型サンドボックスとの違い:

セルフホストかつMITライセンスのため、SaaSでは満たせない場所に適合する

コード、データ、APIキーが自分の管理下のハードウェアに留まる

月20ドルのVPSでも社内ネットワーク内のサーバーでも成立する

■ 6. 対象となる利用者

多数のサンドボックスを運用する場合は採用すべき:

製品のユーザー向け、チーム向け、エージェント向けの運用が該当する

AIアプリビルダー、エージェント基盤、コーディングプレイグラウンドが該当する

ユーザー単位やブランチ単位のプレビュー環境、チーム向けマルチアプリホスティングも該当する

自分用のコンテナが1、2個なら採用不要:

シェルスクリプト、docker run、lxdの方が単純

■ 7. 本当に難しいのはインフラ

難所はプロンプトでもアプリでもなくその下の基盤:

AI製品を出す場合でも社内プラットフォームを作る場合でも同じ

必要となる要素:

あるユーザーのコードが他に触れないマルチテナント隔離

自動ルーティングとTLSを備えたユーザー単位のプレビューURL

アイドル環境がメモリを解放しなければ請求額が爆発するためのコスト制御

ワークスペースに対してエージェントを走らせ、進捗を流し、結果を捕捉するオーケストレーション

永続化、オンデマンド起動、クラッシュや再起動後の再調整

開発規模:

これらは数ヶ月分のプラットフォーム開発に相当する

sandboxdはそれを1コマンドに凝縮したもの

■ 8. 主要な特徴

ワンラインインストール:

curl -fsSL …/install.sh | bash だけでAPIとプレビューが動く状態になる

エージェント同梱:

OpenCodeとClaude Codeがすべてのサンドボックスに同梱され、プロンプトを渡せば構築が始まる

認証情報はサンドボックスに一切入らず、プロキシが通信経路上で注入する

すべてのタスクがチェックポイント化され、巻き戻しが可能

設計として高密度:

アイドル停止とリクエスト起動により、数十のサンドボックスが1台を共有する

VMを1台ずつ用意する方式との差は20ドルのサーバーと2000ドルのクラスタの差になる

所有権が自分にあること:

セルフホスト、MITライセンス、ベンダーロックインなし

データ、利益率、ロードマップを自分で所有する

意図的な退屈さ:

SQLite、docker CLI、Traefikのみで構成する

起動のたびにリコンサイラがDockerをデータベースの状態へ収束させる

コントロールプレーン全体を半日で読み通せる

■ 9. シェルスクリプトで十分ではないかという疑問

自分用の長期稼働コンテナが1、2個ならスクリプトで十分:

シェルスクリプト、docker run、lxdの方が単純であり、そちらを使うべき

単発のプロジェクトにsandboxdは過剰

他者のために多数のサンドボックスを動かす時点で価値が出る:

チーム向けや製品向けの運用になると、小さなdocker runスクリプトが以下すべてへ膨らむ

ポートではなくURL:

すべてのサンドボックスが自動ルーティングとTLS付きの整ったプレビューURLを得る

ポート管理も衝突対応も不要

自律的なスリープと起動:

アイドルのサンドボックスは停止してRAMを解放し、次のリクエストで透過的に再起動する

ウォームアップ画面、レディネスプローブ、リクエスト保留を含み、その部分だけで100行を優に超える

安価な1台で済むか常時稼働VMのラックが必要かの分かれ目になる

再起動への耐性:

SQLiteが信頼できる唯一の情報源であり、起動時にリコンサイラがDockerを再収束させる

スクリプトはホスト再起動時にすべてを忘れる

シェルインするCLIではなくAPI:

create、exec、stop、destroy、write-files、run-agent-taskが認証付きの実HTTPエンドポイントとして存在する

アプリのバックエンド、CI、スクリプトからユーザー単位で大規模に呼び出せる

巻き添え停止の防止:

サンドボックス単位のメモリ制限とPID制限を持つ

ホストのメモリ逼迫時に動くリーパーを備える

ライフサイクルを持つエージェント:

プロンプト送信、SSEでの進捗ストリーミング、永続的な結果の取得を行う

opencodeをその場で起動するだけのものとは異なる

結論:

スクリプトを育てて同じ機能を再実装すればsandboxdを再発明することになる

単発なら見送り、スクリプトで夜も眠れなくなった時点で採用すべき

■ 10. Kubernetesを好む場合

コントロールプレーンは薄いdocker CLI境界を介してコンテナランタイムと対話する:

k8sのJob/Podバックエンド追加は書き直しではなくインターフェース差し替えで済む

最初のコントリビューションとして適している

現時点では単一のDockerホストを対象とする:

k8sは不要

サンドボックスのためだけにクラスタを運用したくないチームに最適な位置

■ 11. プロダクトの土台としての適性

製品基盤として使えるかという問いへの答えは肯定:

それこそが狙いである

省ける初期開発:

マルチテナント隔離、プレビュールーティング、アイドルと起動によるコスト制御、エージェントオーケストレーションを数ヶ月かけて作る必要がない

AIアプリビルダーやエージェントSaaSの出荷、社内でのサンドボックス環境構築を初日から始められる

提供条件:

安価なサーバー1台で動き、利益率は自分で制御できる

現状の位置づけ:

ベータ品質、MITライセンス、読まれ拡張されることを前提に作られた誠実な出発点

軽量に立ち上げ、成長に応じて堅牢化していく方針を取る

(2026/08/10)

日本におけるAIによるエンジニア不要論が非現実的な理由

日本におけるAIによるエンジニア不要論が非現実的な理由

要約:

■ 1. 主張の骨子

繰り返されるエンジニア不要論:

AIによりエンジニアが不要になるという話はここ数年何度も聞いて飽きている

エンジニア不要論は定期的に出てくるものであり、1990年頃には既に同様の主張を聞いた

最低でも35年以上そうした話が続いており、もっと昔からあってもおかしくない

三つの主張:

エンジニアの再定義や淘汰はあるだろうし、今後頻繁に議論されるようになる

エンジニアそのものが不要になるAIは頭脳労働職も全部不要にするAIであり、正しくは「頭脳労働職不要論」である

そもそもある一定ラインになると人間の方が安い

論点の切り分け:

コーディングエージェントによるエンジニアの再定義や淘汰と、エンジニアそのものが不要になることは完全に別物

後者は非エンジニアだけでプロダクトを作れる状態を指す

■ 2. 現状のAIの実力

記事執筆時点の最高峰AI:

8/3時点で世界最高峰のAIはMythos5/Fable5である

Opus5はベンチマークが良くても実性能はそれほど高くないベンチマーク番長にすぎない

非エンジニア開発の不可能性:

Fable5を使って非エンジニアがまともなプロダクトを作りメンテナンスすることは絶対に無理

少しでもプロダクト開発・運用に携わった人間なら、それが無理であることは自明にわかる

可能な範囲の限定:

Fable5でプロトタイピングやPoC、自分専用ツールを作る程度なら実例も山ほどある

内部ユーザーだとしても顧客が存在するプロダクトは無理

素人が作る結果:

そこらへんのクッソショボい業務システムでも、素人がAIスロップまみれで作れば安定して動くまともなものはでき上がらない

エンジニアが泣きながら後始末をやらされる未来が目に見えている

最先端ツールのバグ:

Claude CodeやCodexはバグだらけで、いまだにOpenされ続けているissuesが大量にある

AnthropicやOpenAIの天才たちが社内の無制限トークンを湯水のごとく使ってすらあの体たらくである

Claude Codeの不愉快なバグは一向に治らず、CodexのSQLiteバグすら治らない

■ 3. 性能向上の見通しと必要な水準

次世代モデルの想定:

OpenAIの内部コードネームAstraやAnthropicのFable5.1は8月中には出るだろう

Opus-4.8からFable5に該当するほどの極端なジャンプアップが再び起きることはないはず

非エンジニアでもプロダクトをまともに開発・運用できるようになるほど大きすぎる進化ではない

不要論に必要なAI像:

エンジニアが持つ勘所・経験・実績・セオリーがなくてもプロダクトを作れるAIでなければならない

エンジニアとはユーザーが抱える問題を解決するプロフェッショナルである

ユーザーが言語化できていないものを全部くみ取って設計に落とし込める知性が必要

テクニック必要論の限界:

AIの性能を引きだすためにテクニックやコツが必要と言っているレベルでは絶対に無理

現行AIの弱点:

答えがあるものは素晴らしいくらいに扱えるが、答えが明文化できていないものを扱えるほど賢くはない

要件定義・設計の難しさも全部吹き飛ばせるような知性への進化が必要

真のAGIとの距離:

必要とされる水準はもはや真のAGIと呼ばれるもの

現状では既にRSI（AIによる再帰的進化）を達成しているのではと言われている

RSIやASIが実現されてなお、人間をそのまま代替できる真のAGIの実現は遠い

■ 4. 規制と地政学のリスク

政府による強制介入の前例:

たかだかFable5ごときで、アメリカ政府が歴史上はじめてAIサービス提供に対して強制介入をした

AGI級AIの攻撃能力:

非エンジニアがプロダクトを完全に作れるほどのAIの攻撃能力はFable5程度の比ではない

ソーシャルエンジニアリングなども含め、あの手この手で攻撃できる能力を持つ

提供条件への疑問:

OpenAIやAnthropicの人がそれを完全にコントロールしきれるのか

nerfされずにリリースできるのか、値段は安く提供されるのか

各国の規制強化の可能性:

アメリカ政府は今まで以上に介入するかもしれない

中国はいまのところオープンだが、世界最高峰のAIを手にしたとき規制推進側に回る可能性は決して低くない

EUも今以上にうるさく言い始めるかもしれず、日本人は最先端AIにアクセスできなくなるかもしれない

■ 5. 人間の方が安いというコスト論

従量課金の負担:

普通の企業はサブスクではなく従量課金で使っているはず

非エンジニアがFable5を従量課金で使えば莫大な金額がかかる

実際のトークン消費額:

Fable5をMax 20xで最大限に使えば簡単に月額100万円くらいのトークンを使うことになる

筆者は7月にFable5のみで95万円相当、Opus5を入れて138万円相当のトークンを消費した

エンジニア利用の優位:

エンジニアが適切なモデルを適切な使い方で使っていく方が安くつく

価格上昇の見通し:

今後のAIはスケーリング則を活用するために今よりさらにサイズアップし、値段も高くなる

AnthropicやOpenAIとしては値段が高いモデルを出した方が儲かる

Fable5並のAIが安くなる未来は来るが、非エンジニアでもプロダクトを作れるAGI級AIが安くなる時期は見えない

■ 6. オープンウェイトの現実

期待への反論:

オープンウェイトなAIが出ているから大丈夫という考え方は成り立たない

巨大モデルの運用コスト:

2.8TのKimi K3はクラウドで月額1000万円、ハードウェア購入なら初期投資だけで1億円以上かかる

そこまで投じて元を取れるのか、人間の方が安くつくのではないか

例外的にペイする層:

世界中でランサムウェアを使って金をむしり取っている連中は強烈な攻撃能力を得られるなら月額1000万円を安いと考える

日本企業にとっての重さ:

日本の普通の企業にとって月額1000万円クラスの投資は安いものではない

今後円安がまだまだ進行し、GPUもメモリもSSDもエネルギーも今以上に高くなる可能性がある

小型モデルの限界:

DeepSeek 4 Flash 0731は思ったよりも性能が高くサイズも小さいが、Fable5クラスの賢さではない

このクラスですら生半可な組織が運用できるものではない

オープンウェイトの価格誤解:

オープンウェイトのモデルは安いわけではなく、サイズが小さいから相対的に安いマシンでも動くというだけ

DeepSeek 4 Flash 0731を公式推奨スペックで動かすなら月額200万円以上を見たほうがいい

これらを適切に運用できるエンジニアも当然必要になる

運用失敗のリスク:

数百万円を投資しても、ちょっとしたミスで正しく運用できなくなることがある

システム自体は動いていてもうまく活用できず、値段分の力を引きだせないこともありえる

■ 7. 淘汰の見通し

淘汰そのものは発生:

AIの発達によってある種の人達が淘汰されるのは確かだろう

企業側の制約:

多くの企業はなるべくお金をかけたくない

まともにオープンウェイトのAIを運用するノウハウも持っていない

中国製のAIを無条件で信用するわけにもいかない

組織形態の変化:

AIコーディングを活用した少数精鋭のエンジニアリングチームができる

エンジニアリングとそれ以外の越境が続く

SIerの将来:

SIerという形態も長期的には厳しいかもしれない

ユーザー企業に少数精鋭のエンジニアリングチームが入って自社開発したほうが健全だからである

淘汰される人材:

こういった変化に対応できない人材が淘汰される可能性はそれなりにある

■ 8. 真のAGI到来時のシナリオ

都合が良すぎる想定:

非エンジニアが操作してプロダクト化ができるほどの知性があるのに、頭脳労働をする人が仕事を失わないシナリオは存在しない

議論のスケールの誤り:

そこまで行き着けばエンジニア不要論で収まるスケールではなく、エンジニア不要論は意味をなさない

エンジニア不要論とはエンジニアリングに限定したAGIが安価で実現される意味だが、そんな限定的なシナリオは生じない

ブルーカラーも例外ではない:

真のAGIに到達しているならロボティクスもそんなに時間がかからず行き着くところまで行く可能性が高い

かかったとしても数年遅れくらいに収まる

(2026/08/10)

DB設計における監査設計に関するメモ

■ 1. 監査設計の全体像

監査機能の二大方式:
- 監査用カラムを本体テーブルに持たせる方式と、変更履歴を別テーブルに記録する方式に大別される
- 目的や要件に応じて使い分け、組み合わせるのが一般的
基本の監査カラム:
- created_at/created_by、updated_at/updated_by、deleted_at/deleted_by、versionをほぼ全テーブルに持たせる
- これが最小構成となる
論理削除の利点:
- deleted_atを使えば、本当に消してよいか、参照整合性が壊れないかを後から判断できる
論理削除の欠点:
- 外部キー制約・ユニーク制約との相性が悪く、削除済みレコードも一意制約に引っかかる
versionの用途:
- 楽観的排他制御に使い、更新時に自分が読んだバージョンと一致するかをチェックする

■ 2. 変更履歴を残す4方式

単純な監査カラムの限界:
- updated_at/byだけでは変更前の値、何回変更されたかがわからない
- 変更履歴が必要なら履歴テーブルを設計する
シャドウテーブル方式:
- 本体と同構造のxxx_historyを用意し、更新・削除の都度、変更前の行をコピーして保存する
- トリガーで自動化するか、ORMのフック等アプリケーション層で書き込むかを選択する
- 各時点のスナップショットがそのまま取れるので監査・復元がしやすい
- テーブルごとに履歴テーブルが増え、スキーマ変更の二重管理が発生する
汎用監査ログテーブル方式:
- 全テーブル共通の1つのログテーブルに、table_name、record_id、old_values/new_values等をJSONで記録する
- テーブル追加のたびに履歴テーブルを増やさなくてよい
- IPアドレスやリクエストIDなど操作コンテキストも一緒に記録しやすい
- JSONカラムのため検索・集計がしにくく、RDBMSのJSON検索機能に依存する
- 差分だけを見たい場合はold/newのdiffをアプリ側で計算する必要がある
イベントソーシング方式:
- 状態ではなく発生したイベントを全て記録し、現在の状態はイベントの再生で導出する
- イベントが真実の源であるため、完全な監査証跡が自然に手に入る
- 設計・実装コストが高く、既存のCRUD中心システムへの後付けは難しい
- 新規システムや強い監査要件がある場合に向く
システムバージョニング:
- SQL Serverやtemporal_tables拡張など、DBMSがネイティブ対応する時系列テーブル機能を使う
- アプリ側でコードを書かずに履歴管理ができる

■ 3. 方式選定の指針

誰がいつ触ったか程度でよい場合:
- 基本の監査カラムのみで足りる
変更前後の値を追いたい場合:
- シャドウテーブルまたは汎用監査ログを用いる
改ざん不可な証跡が必要な場合:
- 追記専用の監査ログにハッシュチェーン等を組み合わせる
ドメインイベントとして意味のある履歴が欲しい場合:
- イベントソーシングを選ぶ
DB側で自動管理し実装コストを抑えたい場合:
- DBMSのTemporal Table機能を使う

■ 4. 実装上の注意点

書き込み方式のトレードオフ:
- トリガー実装は漏れなく確実だが、DBロジックが複雑化しデバッグしにくい
- アプリ層のORMフック・AOPは柔軟だが、バッチ処理やDBAの直接SQLを防げない
- 両方を併用するケースも多い
パフォーマンス:
- 高頻度更新テーブルに毎回履歴INSERTするとI/O負荷が増える
- パーティショニングやメッセージキュー経由の非同期記録も検討対象になる
保持期間とアーカイブ:
- 会計7年など法令要件に応じて保存期間を決める
- 古いログはS3等の別ストレージにアーカイブする設計にする
改ざん防止:
- 監査ログをUPDATE/DELETEできないようDB権限を絞り、追記のみ許可する
- ハッシュチェーンや外部WORMストレージで完全性を担保する
変更主体の区別:
- アプリケーションユーザーだけでなく、バッチ処理・システム連携による変更も区別できるようにする

■ 5. 基本監査フィールドは監査証跡ではない

監査としては機能しない:
- 最終更新しかわからないため、誰が何をいつ変えたかの証跡にはならない
実体は運用メタデータ:
- created_at/by、updated_at/byは一覧画面での最終更新者確認、ソート、キャッシュ無効化のトリガー等に使う
versionの位置づけ:
- 監査とは無関係であり、純粋に排他制御の仕組みである
導かれる結論:
- 監査要件がある場合、これらのフィールドをもって監査要件を満たしたと考えるべきではない

■ 6. ヒストリーテーブルとイベントソーシングの評価

ヒストリーテーブルは機能要件:
- 注文のステータス遷移履歴の画面表示、承認フローの経緯提示など機能要件として必要になる
- この場合はドメインモデルの一部であり、監査ログとは別物として設計すべきである
監査要件も満たしうる:
- 全カラムの変更前後が追える構造にしておけば、機能要件として作った履歴が結果的に監査要件も満たす
量産はコストに見合わない:
- 監査のためだけにテーブルごとにヒストリーテーブルを量産するのは割に合わず、汎用監査ログに任せるべきである
イベントソーシングは過剰:
- CRUD中心の業務システムに監査目的だけで導入するのは、状態導出コスト、実装複雑度、学習コストに見合わない
- 決済や在庫移動などドメイン自体がイベントの連鎖として自然にモデリングできる場合を除き避けるべきである

■ 7. 汎用監査ログの留保点

書き込み経路の網羅性:
- アプリ層のORMフック等で書く場合、バッチ処理、DBAの直接SQL、他システムからの直接書き込みが抜け穴になる
- トリガーやCDCでDB層から捕捉する方が漏れがない
- アプリ層でしか書かない設計は抜け道のある監査となり、要件次第では監査ログとして無意味になりうる
検索性能とクエリ要件:
- JSONに差分を格納する方式はテーブル追加コストがゼロで柔軟である
- 特定カラムの変更履歴追跡や特定ユーザーの横断検索はJSON演算子頼みで重くなる
- 監査ログを実際に読む運用の頻度次第で、field_name、old_value、new_valueを行単位で持つ構造化が必要になる
改ざん耐性:
- 汎用監査ログもただのテーブルであり、UPDATE/DELETE権限を絞らないと改ざんされる
- 汎用ログに一本化する場合は、厳格なアクセス制御の設計とセットで考える必要がある

■ 8. DBに監査ログを置く理由

トランザクション整合性:
- 業務データの変更と監査ログの記録は同一トランザクションで確定してほしいものである
- DBに書けば、業務データは更新されたが監査ログが書かれないという不整合が起きない
- ロールバックすれば監査ログもロールバックされる
非同期経路の弱点:
- ログ出力から非同期アーカイブ、DWHという経路では業務データと監査記録の一致保証が弱くなる
- ファイル出力の場合、書き込み成功直後のプロセスクラッシュでフラッシュ前のログが欠落しうる
即時参照ニーズ:
- 管理画面やサポート業務でその場に変更者を確認したい場合、DWH経由ではレイテンシが許容できない
- BigQueryへのストリーミングインサートとクエリでも数秒から数十秒のラグが発生する
- この用途はDB内やElasticsearch等の低レイテンシストアに直近履歴を持たせる方が向く

■ 9. DWHに任せる理由

分析・集計クエリ:
- 異常頻度の変更検出やユーザー操作パターンの横断分析はカラムナDWHが圧倒的に得意で安い
長期保持コスト:
- 7年保持等が必要な場合、本番DBに持ち続けるのはストレージ・バックアップ・インデックスの面で非効率である
- DWHとS3/GCS等の安価なオブジェクトストレージへのアーカイブの方が合理的である
本番DBの肥大化回避:
- 監査ログテーブルは本体テーブルより行数が増えやすい
- 本番OLTP DBに置き続けるとインデックス肥大化やバックアップ時間増加の要因になる

■ 10. CDCを起点にしたハイブリッド構成

構成の概要:
- 本番DBのWAL/binlogをDebezium等でCDCし、Kafka等のストリームに流す
- 短期は運用画面用にDBやRedisへ直近履歴を投影し、長期は分析・コンプライアンス用にDWHへロードする
利点:
- 書き込み経路を問わず全変更を捕捉でき、アプリ層のバグやバッチの抜け道を気にしなくてよい
- WALに書かれた時点でコミット済みのため、業務トランザクションとのズレが原理的に起きない
- 即時参照は短期ストア、長期保持はDWHと用途ごとに最適なストアを選べる
- 本番DBの肥大化を避けられる
欠点:
- CDC基盤自体の運用コスト・複雑度が増す
- 小中規模システムでは明らかにオーバーエンジニアリングになる
分岐点:
- 即時参照ニーズの有無と、書き込み経路の網羅性をどこまで求めるかがDBかログ/DWHかを分ける

■ 11. ログ出力からアーカイブ戦略の要件

前提の確認:
- 即時参照不要かつ調査はエンジニアで可なら、ログ出力からアーカイブが理にかなう
- DB内に監査ログテーブルを持つ複雑さと運用DB肥大化リスクを負うメリットが小さい
監査範囲の事前確定:
- アプリ層を通らないバッチ、DBAの直接SQL、他システムの直接書き込みは捕捉されない
- 業務上のユーザー操作が追えればよい程度ならアプリ層ログで十分である
- 金融・医療系などDB変更全体の証跡が必要ならCDCでログ生成をDB層に寄せる必要がある
ログの構造化:
- timestamp、actor_id、actor_type、action、resource_type、resource_id、changes等を構造化する
- request_id/trace_idを入れると、分散システムでどのAPIリクエストが引き金かを横断的に追える
- actor_typeでシステム・バッチ由来の変更とユーザー操作を区別する
改ざん防止:
- アーカイブ先も要件次第で追記のみ・削除不可のWORM設定にする
- S3ならObject LockのCompliance mode、GCSならBucket Lockを使う
- 要件が厳しい場合は各エントリに前エントリのハッシュを含めるハッシュチェーンを使う
ライフサイクル管理:
- ホット期間は直近数ヶ月から1年でDWHから即クエリ可能にする
- コールド期間は安価なストレージへアーカイブし必要時のみリストアする
調査時のクエリ経路:
- 実際に調査が発生した時、BigQueryにSQLを書けば追える状態かを事前に確認する
- サービスごとにキー名やネストが不揃いだと調査コストが跳ね上がる
- 共通のロギングライブラリ・ミドルウェアを整備し、出力時点でスキーマを統一する

■ 12. WAL/binlogを整形してログ保存する方式

一般的なアプローチ:
- Debezium、AWS DMS、Google Cloud Datastreamが実際に採用しているメジャーな方式である
メリット:
- アプリ層、バッチ、DBA直接操作のいずれからの変更もWAL/binlogに必ず記録され、経路を完全網羅できる
- コミット済みの変更しか含まないため、業務データは変わったがログが無いというズレが起きない
- 読み取りは非同期でレプリケーションと同じ仕組みのため、本番トランザクションへの性能影響が小さい
業務的意味の欠落:
- WALには行のカラム値がどう変わったかしか記録されず、誰が、なぜのアプリケーションコンテキストが存在しない
- actor_idはupdated_byカラムに書くか、セッション変数をトランザクション内に埋め込んでメタデータ経由で拾う
- なぜという業務的意図はDBの変更から復元不能であり、アプリ側でイベントとして別途記録する必要がある
Before/Afterイメージの設定:
- MySQLはbinlog_row_image = FULLにしないとUPDATE時に変更カラムしか記録されない
- PostgreSQLはREPLICA IDENTITY FULLを設定しないとUPDATE/DELETEの旧データが完全に取れない
- ストレージ・I/O負荷とのトレードオフであり、全テーブルに設定するかは検討を要する
DDLの扱い:
- ALTER TABLE等でイベントのスキーマ自体が変わるため、下流との整合を取るスキーマレジストリ等が必要になる
- カラムがいつ追加・削除されたかも証跡として重要であり、DDLイベントも記録する設計が望ましい
機密情報のマスキング:
- WAL/binlogはカラムレベルの制御ができず、行の全カラムがそのまま流れる
- 個人情報や機密カラムはKafka Connect等の下流でマスキング・暗号化を挟む必要がある
トランザクション境界の再構成:
- 複数テーブルにまたがる1トランザクションはWAL上で複数イベントの連なりになる
- まとめて1つの監査イベントとして扱うにはtransaction_idやLSN/GTIDでの再構成処理が必要になる

■ 13. updated_byの構造的限界

誰がまでしか語らない:
- updated_byからわかるのは最終更新したユーザーという事実のみである
- なぜその値に変えたのか、どの業務操作の一部か、どういう文脈かは一切わからない
WALと同じ問題:
- updated_byはWAL/binlogにactor情報を追加しただけであり、業務的意味の欠落という本質的問題は解消しない
- actor_id、timestamp、IPアドレスを足しても、行がどう変わったかの記述にとどまる
アプリケーションログが必須な理由:
- 業務的な意味はアプリケーションがビジネスロジックを実行している瞬間にしか存在しない
- DB側にどれだけ工夫を凝らしても事後的には復元できない
具体例:
- 顧客によるキャンセル、在庫切れの自動キャンセル、不正検知によるブロックは行変更としては全く同じである
- 監査・コンプライアンスの文脈では全く異なる意味を持ち、区別できるのは業務ロジックを実行したコードだけである
両者は補完関係:
- WAL/binlogは網羅的だが業務的意味を持たず、改ざん耐性のある事実を提供する
- アプリケーションログは業務的意味を与えるが、アプリ層を経由しない変更を捕捉できない
- 厳しい要件があるほどCDCとアプリログの両方が必要になり、CDCはアプリログを不要にするものではない

■ 14. 3層構成ではなく主従関係のある2層

誰が・いつだけでは手詰まり:
- updated_by/updated_atだけでは、何を何から何に変えたかがわからず調査時に行き詰まる
基本監査フィールドは冗長:
- アプリケーションログをactor_id、old/new値、業務コンテキスト付きで設計するなら情報が重複する
- 独自の価値は排他制御用のversionと、一覧画面用に最終更新者を複製するUI都合のキャッシュのみである
- 監査証跡としての独立した役割はほぼ無い
実質的な構成:
- アプリケーションログを主軸とし、必要に応じてCDC/binlogを完全性担保のために足す2層構成が筋がよい
- 基本監査フィールドはUI用の複製データという位置づけに下げる
過剰設計の回避:
- 3つが対等に並ぶセットと捉えるより、主従関係のある構成と捉える方が過剰設計を避けやすい

■ 15. アプリログのみでは直接更新を捕捉できない

運用ルールによる統制はザル:
- バッチもDBA操作も全てアプリ経由という前提は現実にはほぼ成立しない
- 障害対応では、運用ルールを整備していてもDBAや開発者が直接SQLを叩く事態が現実に起きる
- マイグレーションやデータ補正は、性質上ビジネスロジックを経由しない直接SQLで行われることが多い
- DB接続情報にアクセスできる人が1人でもいれば技術的には直接更新が可能である
監査観点での評価:
- 運用ルールでアプリ層に閉じている状態は、監査の観点では閉じていないのと同義である
- 監査・コンプライアンスで問われるのはルール上禁止かではなく、技術的に迂回可能かである
判断基準の修正:
- 正しい分岐点はDBに直接書き込める技術的な経路や認証情報が存在するかである
- DBAや緊急対応用アカウント等が存在するならアプリログでは足りず、CDCまたはDBトリガーが必要になる
- 書き込み経路が物理的にアプリケーションサーバーのみに制限された組織は稀である
穴を塞ぐ2つの方向性:
- 本番DBへの直接接続権限を原則ゼロにし、緊急時のみ一時発行・自動失効させ、その発行と利用もログ化する
- 権限を絞る方式は運用コストが高く、多くの組織で緊急対応の柔軟性とトレードオフになる
- 直接アクセスを許容した上でWAL/binlog経由で全て捕捉する方が、柔軟性と監査の完全性を両立でき現実的である
訂正後の結論:
- 監査・コンプライアンス要件がある時点で、CDCまたはDBトリガーベースの捕捉をデフォルト前提とすべきである
- アプリログは意味づけを担う層として必須だが、DB変更全体を追うことの代替にはならない

■ 16. CDC/binlogのデータ量試算

サイズを決める要因:
- トランザクション量と行サイズの積が、設定と実装の選択で数倍から十数倍のレンジに変わる
WAL/binlog自体のオーバーヘッド:
- MySQLのbinlog_row_image = FULLでは変更されていないカラムも含め変更前後の全カラムが記録される
- PostgreSQLのREPLICA IDENTITYをFULLにするとUPDATE/DELETEのWAL量が大きく増える
- FULLイメージ化すると1行あたりの記録サイズは行サイズの2倍前後になる
シリアライズ形式が最大のレバー:
- スキーマ埋め込みなしのJSONは行サイズの2倍から4倍になる
- Debeziumデフォルトのスキーマ埋め込みJSONは5倍から10倍以上になることもある
- Avro/Protobufとスキーマレジストリの組み合わせは1.5倍から3倍程度に収まる
- 本番運用ではAvro/ProtobufとSchema Registryの組み合わせがほぼ必須である
圧縮の効果:
- KafkaのProducer側圧縮はZstdで3倍から5倍程度の圧縮率が一般的である
- BigQueryやParquetのカラムナ格納では元データの5分の1から10分の1程度まで縮む
試算例:
- 1行500バイト、平均100 UPDATE/秒のordersテーブルを想定する
- WAL/binlogは日次約8.6GB、Debezium経由のKafkaは圧縮前で日次約11GBとなる
- Zstd圧縮後は約2.7GB/day、S3へのParquetアーカイブでは0.5から1GB/dayまで縮む
- スキーマ埋め込みJSONのまま運用すると数十GB/dayに膨らむこともある
テーブル数の考慮:
- 監査対象テーブルは数十から数百あるため、テーブルごとの更新頻度と行サイズを積み上げる必要がある
- 注文ステータス、在庫数、セッション情報など高頻度更新テーブルが全体のボリュームを支配しがちである
- 金銭・個人情報関連を優先的に対象化し、それ以外を対象外や低頻度スナップショットにすれば大きく削減できる
見積もり手順:
- 対象テーブルごとに1日の平均更新件数をスロークエリログやAPMから実測する
- information_schemaから1行あたりのバイト数を概算取得する
- 件数、行サイズ、before/afterの2倍、シリアライズ係数を掛けて粗く見積もる
- KafkaとDWH側の圧縮率は理論値でなく実データのPoCで測定する

■ 17. 監査対象テーブルの選定基準

マスタテーブルの意味が薄い理由:
- 商品マスタやカテゴリマスタは初期投入後ほとんど更新されず、容量コストに対しリターンが小さい
- マスタデータの改ざんが実害に直結するケースは少ない
- マスタは参照される側であり、いつ変わったかさえ分かれば以降の取引データとの整合性は追跡可能である
優先度が高いテーブルの特徴:
- 注文金額、決済ステータス、返金処理、ポイント残高など金銭が動くもの
- 権限ロール、APIキー、認証情報などアクセス制御に関わるもの
- 氏名・住所等のPIIカラムを含むもの
- 在庫調整、値引き・クーポン適用、承認フローなど不正の温床になりうるもの
- 会計仕訳や取引履歴など法令が直接保存を求めるもの
選定プロセス:
- まず更新頻度で機械的にフィルタし、ほぼ変更されないテーブルを除外する
- 残りを金銭・PII・権限のいずれかに該当するかで監査必須・任意・対象外にランク分けする
- 法令上必須な範囲をコンプライアンス担当・法務とすり合わせる
- 容量・コストの見積もりを踏まえ、任意ランクをどこまでCDC対象に含めるか判断する
マスタ除外の例外:
- 価格マスタの改ざんによる不正値引き、権限マスタの改ざんによる不正アクセスは実質的に金銭・権限に直結する
- 更新頻度が低くてもむしろ優先的に監査対象にすべきである
- マスタかトランザクションかという技術的分類ではなく、金銭・権限・PIIに直結するかという業務的軸で判断する

■ 18. リスクベースの層分けと組織的合意

設計判断としての妥当性:
- クリティカルなもののみCDCで捕捉し、残りをアプリケーションログとするのは実務的に妥当な落とし所である
- 全テーブル一律CDCは多くの組織にとってコスト超過となる
リスク受容としての明文化:
- アプリログのみにはDB直接更新を捕捉できない構造的な穴がある
- この判断はクリティカルでないテーブルの捕捉漏れリスクを受容するという意思決定そのものである
- エンジニアの設計判断だけで決めると、監査時に完全性が担保されない理由を組織として説明できなくなる
- CDC対象テーブルのリストと選定基準をコンプライアンス担当・法務と正式に合意しておく
3段階の層分け:
- Tier 1: 金銭・権限・PIIに直結し法令が要求するもので、CDCとアプリログを併用する
- Tier 2: 注文ステータスや在庫など業務上重要なもので、アプリログとトリガーベースの変更検知を用いる
- Tier 3: マスタや低頻度・低リスクのもので、基本監査フィールドのみか監査なしとする
トリガーベースの中間層:
- DBトリガーで変更前後の値を汎用監査ログテーブルに書き込む方式はCDCほどのインフラコストがかからない
- DB直接更新もある程度捕捉でき、アプリログのみとフルCDCの中間として機能する
リスクと軽減策:
- 新機能追加時にテーブルが金銭に触れるかをチェックリスト化しないと、Tier分類が次第に形骸化する
- Tier 3では直接アクセスできる人・システムを最小化し、アクセス制御の強化でリスクを相殺する
- 選定基準と承認履歴を文書化しておくと、実際の監査対応がスムーズになる

(2026/08/10)

中国製ルータ20機種に「隠しバックドア」、世界10万台超か…35秒ごとに外部通信判明

中国製ルータ20機種に「隠しバックドア」、世界10万台超か…35秒ごとに外部通信判明（ビジネス＋IT） - Yahoo!ニュース

要約:

■ 1. 中国製ルータのバックドア発覚

ENDLESSDOORS の公表:

米サイバーセキュリティ企業VulnCheckが8月5日に公表

中国・深センのZbtlinkが製造するルータ20機種のファームウェアに、外部から機器を操作できるバックドアが組み込まれている

全ファームウェアへの混入:

研究チームが調べた21のファームウェアイメージすべてに遠隔操作用コードが含まれる

機器の起動時に自動実行される

35秒ごとの外部通信:

対象機器が35秒ごとに外部と通信する挙動が判明

■ 2. バックドアの技術的仕組み

rctl の改変版:

Linux向け遠隔操作ツール「rctl」を改変したもの

ルータ側からの発信接続:

ルータ側からC2（指令・制御）サーバへ接続する仕組み

インターネット側から対象機器へ直接アクセスできない環境でも通信が成立する

root権限での操作:

接続後は送られたコマンドをroot権限で実行できる

対話型シェルの起動も可能

実機再現とCVE付与:

VulnCheckが実機でこの挙動を再現し、CVE-2026-66747を割り当てた

■ 3. 影響範囲

世界10万台超の展開:

対象機器は世界で少なくとも10万台が展開済みとみられる

OEM/ODM製品への波及:

OEM/ODM製品にも広がる可能性がある

■ 4. 規制動向と調達への示唆

米FCCの規制強化:

3月に外国製コンシューマー向けルータの新規モデルを原則として「Covered List」に追加した

新たな機器認証を制限した

日本の調達方針:

政府や自治体のIT機器調達で安全性を重視する動きが進んでいる

調達時の確認範囲:

メーカー名だけでなく、ファームウェアやOEM供給元まで確認する重要性が改めて浮き彫りになった

論評:

■ 1. Zbtlinkの公式説明

rctlに関する製造元の主張:

もっぱらアフターサービス用の技術支援ツールである

顧客の明示的な要請、許可がある場合にのみ使用する

無断アクセスに使われたことはない

取材に対する追加の説明:

この機能はアフターサービス保守のためのものであり他の目的はない

通常はサンプル機にのみ残される

■ 2. リモート保守機能の一般性

業界標準としてのリモート管理:

ISP提供のルータやエンタープライズ機器では、TR-069（CWMP）のような標準化されたリモート管理プロトコルが広く使われている

事業者がファームウェア更新や設定変更、障害診断を遠隔で行うための正規の仕組み

ただし、正規の仕組みには重要な条件が伴う

■ 3. 正規の保守機能との相違点

認証、暗号化の欠如:

正規のリモート管理は証明書ベースの相互認証やTLS暗号化が前提

今回のrctlは認証も暗号化もなく、接続先を握った者が任意のコマンドをroot権限で実行できる状態

秘匿設計:

プロセス名を偽装するなど、正規の保守ツールなら不要な隠蔽が施されている

プロセス名は正規のカーネルスレッドを装うkworkerに偽装され、タスク一覧を見ても気づきにくい

通常の保守ツールの設計思想とは相容れない

ユーザーの関与がない:

正規の遠隔サポートは通常、ユーザーの同意やセッション開始の操作を伴う

今回はルータ側からC2サーバへ常時ビーコン接続する仕組み

ユーザーが関知しないところで機器が外部と通信し続ける

量産機への混入:

Zbtlink側は量産出荷には含まれないと説明している

VulnCheckは現在入手可能な21種類のファームウェアイメージすべてに、2年以上にわたってこの実装が含まれていたとしている

主張と検証結果に食い違いがある

■ 4. 設計そのものへの評価

正当な保守機能が成り立つ前提:

リモートで機器の状態を把握しサポートに役立てるという発想自体は業界的に一般的

認証、暗号化された通信という原則の上に成り立つ

ユーザーの同意、可視性という原則の上に成り立つ

最小権限という原則の上に成り立つ

バックドアという評価の妥当性:

無認証、無暗号でroot権限を握れ、プロセスを偽装して隠す設計は正当な保守機能の実装とは呼べない

セキュリティ研究者がバックドアと評価するのも妥当

メーカーの説明が変えられないもの:

保守用ツールだという説明は機能の目的の主張にすぎない

設計そのものがリスクを内包していたという事実は変わらない

■ 5. 意図的なバックドア説の材料

秘匿工作の存在:

正規の保守ツールなら隠す必要がない

プロセス名をkworkerに偽装してタスク一覧から見えにくくしていた点は、単なる設計上の手抜きでは説明しにくい

通信の秘密性:

平文とはいえ、35秒ごとに常時ビーコンを打ち続ける挙動を示す

必要なときだけ接続する通常の保守セッションとは性質が異なる

継続性:

2年以上、21のファームウェアイメージすべてに一貫して存在していた

単発のミスではなく設計方針として組み込まれていたことを示唆する

地政学的文脈:

中国製通信機器を巡る既存の警戒感（FCCのCovered Listなど）が存在する

意図的という解釈に説得力を持たせる背景となる

■ 6. 度し難い不作為説の材料

流用された既存ツール:

rctl自体は2015年1月にGitHubへアップロードされたまま更新が止まっている古いオープンソースツール

Zbtlinkが独自に開発した秘密工作用コードではなく、既存の管理ツールを流用、改変したもの

ゼロから仕込んだというより、ずさんな管理体制のまま量産に流出した筋書きとも整合する

コスト優先による実装省略:

認証、暗号化を実装しない判断は、悪意がなくてもコストや手間を惜しんだ結果として十分あり得る

低価格帯のOEM/ODM機器ではセキュリティ実装が後回しにされる例は珍しくない

偽装の別解釈:

kworkerへの偽装は意図的な隠蔽と見ることもできる

開発時のデバッグ用の名前付けや、既存コードのコピー&ペーストの副産物という可能性も完全には排除できない

■ 7. 現時点で判断できないこと

意図の立証の欠如:

VulnCheckも含め、外部の第三者機関が誰がなぜこのコードを組み込んだのかまで立証した報告は出ていない

国家の関与を示す直接証拠も、社内の一開発者が判断したことを示す証拠も公開情報からは確認できない

事実関係の未確定:

Zbtlink側のサンプル機のみという説明とVulnCheckの量産機全てに存在という調査結果は真っ向から対立している

この事実関係自体が未確定

決め手となる争点:

二択の判断を分けるのは隠蔽工作をどう評価するか

単なる過失なら通常は隠さないという直感は説得力がある

国家的なバックドアと断定するには意図の立証が別途必要であり、現状はそこまでの証拠は公開されていない

セキュリティ業界の実務的立場:

意図の断定ではなく、パッチ適用の問題ではなく機器の信頼性の問題として扱うべきという立場に落ち着いている

動機を問わず信頼できない機器として扱うという姿勢

■ 8. メーカーとしての信頼喪失

致命的という評価は妥当:

ルーターメーカーとして致命的に信頼を喪失したと評価してよい

不作為説を取ってもなお致命的:

無認証、無暗号でroot権限を渡すコードを2年以上、20機種、21イメージすべてに気づかず出荷し続けた事実がある

セキュリティ管理体制そのものが機能していなかったことの証明になる

気づかなかったのだとしたら、それ自体がベンダーとしての適格性を疑わせる

説明の一貫性の崩壊:

量産出荷には含まれない、サンプル機にのみ残されるという説明と調査結果が食い違う

食い違い自体が説明への信頼性を損ねる

ベンダーが自社製品の実態を正確に把握、説明できていない時点で、この会社の言うことを信用できるかという別の問題が生じる

修正の見込みがない:

修正ファームウェアが提供される見込みがなく、対処は検知、隔離、交換のいずれかになると報じられている

パッチで解決できる性質の問題ではなく、機器そのものを信頼できないものとして扱わざるを得ない

製品ライフサイクル全体を通じた信頼回復の道が閉ざされていることを意味する

サプライチェーン全体への波及:

ZbtlinkはOEM/ODMメーカーであり、自社ブランド以外にも供給している

社名を知らない消費者、調達担当者にも影響が及ぶ可能性がある

型番だけでなく実際のファームウェア供給元まで遡って確認する必要があるという教訓を業界に突きつけた

一企業の信用問題を超えて、OEM調達モデル全体への不信につながる

■ 9. 評価に対する留保

市場による差異:

致命的の中身は市場によって異なる

日本や米国のようにFCCのCovered Listのような規制的な締め出しが進む市場では事実上の排除に近づく

価格優先度が高い新興国市場やブランド認知が薄い流通チャネルでは、OEM先を変えるだけで生き残る可能性も残る

企業存続の余地:

独立監査の受け入れ、透明性のある情報開示、代替機の無償提供など今後の対応次第でまだ変わる余地はある

現時点でそうした信頼回復の動きが十分示されているとは言えない

調達判断としての結論:

技術的な観点でも説明の一貫性の観点でも問題がある

今後この会社の製品を無条件で信頼することはできないと評価するのが合理的

(2026/08/09)

/note/tech

要約:

要約:

要約:

MEMO:

要約:

要約:

MEMO:

要約:

要約:

MEMO:

要約:

要約:

要約:

MEMO:

要約:

要約:

要約:

要約:

要約:

要約:

MEMO:

要約:

要約:

関連:

tag:

要約:

MEMO:

要約:

MEMO:

要約:

要約:

要約:

MEMO:

要約:

要約:

MEMO:

要約:

要約:

要約:

要約:

要約:

要約:

MEMO:

要約:

要約:

要約:

要約:

要約:

要約:

MEMO:

要約:

要約:

MEMO:

要約:

MEMO:

要約:

要約:

要約:

要約:

MEMO:

要約:

要約:

要約:

要約:

要約:

要約:

要約:

要約:

要約:

要約:

要約: