AI駆動開発が「使える」となってきたことで、20代後半から30代中盤のミドルエンジニアが疲弊しているという話を聞きました。たしかに、エンジニアの中でも「AIは楽しい・これでもっと良くなる」という意見と「不安だ・これからどうなるのだろう」という意見に分かれているようです。 私の周りでは、特にベテランが楽しんで、ミドルが不安になっているような構図を感じています。 この記事では、システム開発における30年間の分業と統合の歴史を振り返りつつ、それぞれの世代が何を経験してきたのかを整理します。そのうえで、AI駆動開発が既存の分業をどのように統合しようとしているのかを見ていきます。そして、これがベテランとミドルの違いに、どのように影響しているのかを考えます。 最後には、AI駆動開発が「分業の終わり」ではなく、AIを前提にした「新たな分業の始まり」でもある、という見方を提示します。 この30年の歴史を振

結論 人を増やしてもアウトプットの量は人数に比例して増えませんし、人を減らしてもアウトプットの品質は下がります。優秀な人やAIエージェントを増やしても、組織のあちこちでバラバラなものができたり、ナレッジが古くなって信用できなくなったり、特定の人に判断が集中して燃え尽きたりといった問題は残ります。 これを防ぐためには、組織として「何を許し、何を禁じるか」を、できるだけ少ないルールとして明文化することが必要だと考えています。ただし、ルールを増やしすぎると、組織はそれを守ることに気を取られて動きが遅くなります。だからこそ、壊れると最も困る機能や品質に絞って、リスクの大きさに応じて詳しさを決めることが大切です。 「人を増やすか減らすか」の前にある問い チームの人数が増えるほど、それぞれのメンバーに求められる情報の発信量・受信量が増えていき、やがて情報の伝搬速度がチーム開発のボトルネックになりがちで

はじめに「AIは速度をフロントローディングし、失敗をバックローディングする」 Opsera社が25万人のエンジニアを分析した2026年版ベンチマークレポートに記されたこの一文は、AI時代のソフトウェア開発組織が直面している本質的な矛盾を的確に言い当てている（出典: Opsera AI Coding Impact Benchmark Report 2026）。93%の開発者がAIツールを使い、コーディング速度は30〜58%向上した。しかしその代償として、PR レビュー時間は441%増大し、本番インシデント数は242.7%増加し、開発者一人あたりのバグ数は54%増加した（出典: Faros AI Engineering Impact Report 2026）。 AIは組織を速くした。しかし、強くはしていない。 3つの独立した大規模調査が同じ結論を示すStanfordが10万人のエンジニアを対象

Findyでは数年前から全スタッフに週報を書いてもらっています。以前もnoteで書いたのですが、週報の効能は大きく2つあって、一つは経営陣が現場の解像度を持ち続けて意思決定レベルを上げること、もう一つはメンバー個人の振り返りと成長の機会を作ることです。 ただ、最近ちょっと困ったことが起きていて、週報を読むのが苦痛になっています。人によってですが、つまらなくなってきています。 なぜ週報はつまらなくなったのか正直に言うと、明らかにAIで生成されたと分かる週報が増えてきました。カレンダーの予定をそのまま拾ってきたり、NotionのメモやGitHubのイシューをまとめただけの内容になっていたりする週報が出てきていて、まず読むのが大変なくらい長い。そして何より、経営として本当に読みたいのはその人の考えや気づき、現場でしか拾えない一次情報なのに、それがすっぽり抜け落ちてしまっています。 AIが週次の業

背景: 何が起きているか 2025年9月、Shai-Hulud攻撃がnpmエコシステムを直撃した。ngx-bootstrap、ng2-file-upload、@ctrl/tinycolor等の正規パッケージが改ざんされ、postinstallフックで難読化済みのbundle.jsを実行、npm/GitHub/クラウドの認証情報を窃取しwebhook経由で外部へ送信した。最終的に数百パッケージが汚染された。[1] 2025年11月のSHA1-Hulud(第2波)では、被害者をGitHub Actions self-hosted runnerに変換し、リポジトリにワークフローを注入してAWS/Azure/GCP認証情報を吸い出す手口に進化。600以上のパッケージ(Zapier、PostHog、Postman等)が影響を受けた。[2] 2026年3月にはAxiosが直接侵害された。攻撃者はメンテ

はじめに こんにちは！Acsim 開発チームの笹沢です。 AI 駆動開発の浸透でコードの生産量は飛躍的に増えました。一方、人間がレビューに割ける時間は変わらないため、レビュー待ちで PR がスタックする場面が以前より増えていきました。 私たちのチームでは「人間のレビューを必須とするもの」と「AI レビューで OK とするもの」を線引きし、セルフマージ制度として日々の開発に組み込みました。直近では PR の 約 8 割が人間レビューを介さずにマージできています。マージまでのリードタイムも短縮されています。 この記事では、セルフマージ制度の設計と運用上の工夫、導入後の変化を紹介します。AI レビューが十分使えるレベルになった今、自チームのレビュー運用を見直したい方の参考になれば嬉しいです。 すべての PR に人間レビューは必要か 最近の AI レビューはコード品質の担保という意味では十分使える

みなさまこんにちは！エアークローゼットでCTOをしている辻です。 これまでに DB Graph MCP、社内MCP群の全体像、Biz Graph MCP と、社内向けに作っている MCP サーバーを順に紹介してきました。 今回はその中でもちょっと毛色が違うものを取り上げます。Sandbox MCP ── 非エンジニアの社員が AI と一緒に作ったアプリを、ワンコマンドで社内に安全に公開できるプラットフォームです。 「Claude Code でアプリを作れるなら、それをそのまま社内に出せばいいじゃん」という話を、安全に実現する仕組みです。 背景：作るのは簡単になったが、公開は難しいまま Claude Code をはじめとする AI コーディングエージェントの普及で、いま社内の景色が大きく変わりつつあります。 これまで「アプリを作る」と言うと、エンジニアの仕事でした。要件定義してデザインを起こ

こんにちは！逆瀬川 (@gyakuse) です！ Claude Code v2.1.80で待ちに待ったステータスライン用のrate_limitsフィールドが追加されました。これがないために本当にみんな頑張ってきたのです。本当につらい世界でした。 何が変わったのか 2026年3月19日リリースのv2.1.80で、ステータスラインに渡されるJSONにrate_limitsフィールドが追加されました。 changelogの記載はこうです。 Added rate_limits field to statusline scripts for displaying Claude.ai rate limit usage (5-hour and 7-day windows with used_percentage and resets_at) これにより、Claude Codeのサブスクリプションの使用量

Introduction Claude Codeのv2.1.83で新たに追加された CwdChanged と FileChanged フックイベントを使うと、 ディレクトリ移動やファイル変更をトリガーに処理を自動実行できます。 この記事ではdirenvと組み合わせて環境変数を自動でロードする処理を確認してみました。 Claude Code のフックシステム Claude Code には、特定のイベントが発生した際にシェルを実行する「フック（Hooks）」機能があります。 従来は以下のようなイベントが利用可能でした。 従来のイベント トリガー条件

GitHub Quick Review (ghqr) is a powerful command-line interface (CLI) tool that analyzes GitHub enterprises, organizations, and repositories to ensure compliance with GitHub best practices and security recommendations. Its main objective is to offer users a comprehensive assessment of their GitHub resources, allowing them to easily identify security gaps, misconfigured settings, and areas for impr

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 海外のハーネスエンジニアリングの状況をみていると、いかにその実装を薄くするか、そしてself-healingにするか、という言及が増えているように感じます。 ただこれは、単に「機能を減らせ」という話ではないと考えています。事前に予測してハーネスに詰め込む設計から、必要になった瞬間にモデルがハーネスを書き足す設計へ。API 設計そのもののパラダイムシフトとして読める気がしています。今回はそのあたりを少し書いてみます。 browser-harness の self-healingbrowser-harness は、LLM に Chrome を生の CDP 経由で操作させるためのハーネスです。 中身を読んでみたところ、全体で 592 行の Python しかなく、内訳も `run.py`

Published Apr 23, 2026 We traced recent reports of Claude Code quality issues to three separate changes. Here's what happened and what we're changing. Over the past month, we’ve been looking into reports that Claude’s responses have worsened for some users. We’ve traced these reports to three separate changes that affected Claude Code, the Claude Agent SDK, and Claude Cowork. The API was not impac

唯識思想（八識・三性・種子薫習・転識得智）をソフトウェア設計の読み解き枠組みとして使う試みです。前五識・第六意識・末那識・阿頼耶識の各層をセンサー／モデリング／バイアス／状態管理に対応させ、「なぜ認識がズレるのか」「チームの共通理解はどう形成されるか」を問い直します。唯識の哲学的背景から丁寧に説明するため、仏教の予備知識は不要です。

ボトルネックを見つけて解消する。それで問題は解決するはずでした。 しかし実際には、別の場所にボトルネックが現れ続けます。その繰り返しの中で、問題はやがてコードや工程ではなく、「人と人の間」に移っていく。 TOC（制約理論）の考え方から出発し、複雑な組織における問題の捉え方と、「視点を動かす」という立ち振る舞いを掘り下げます。 ボトルネックを見つけたい ボトルネックが移動する 問題の種類が違う──工場から熱帯雨林へ 複雑な現場でどうするか──着眼大局、着手小局 分解した瞬間に壊れるもの 信頼貯金を育てる おわりに──視点を動かす 信頼貯金で変化に対応する ボトルネックを見つけたい 予算が足りない。時間がない。その割にやることが多過ぎる。 開発の現場で日々直面するこうした問題には、ある共通点があります。問題が「見えている」ということです。誰が見ても「ここが詰まっている」と分かる。テストが手作業

はじめに Claude Code をはじめとする AI コーディング支援ツールの高度化により、マークダウンで構造化された仕様書を AI に渡して実装を進める、いわゆる仕様駆動型の開発スタイルが広まりつつあります。 実装速度は目に見えて向上し、かつてであれば数日かかった作業が数時間で完了するケースも珍しくありません。 一方で、現場で開発に携わっていると、速度向上だけでは説明しきれない違和感が蓄積していきます。残業は減った、納期も守れている、上層部からの評価も悪くない。 それなのに、現場の開発者の間に静かな疲労感が漂っている ― そんな状況を見聞きすることが増えてきました。 この記事では、AI 駆動開発が当たり前になりつつある現在において、生産性向上の裏側で起きている構造的な課題を整理します。課題の整理にとどまらず、開発者・マネジメント・経営それぞれが明日から変えられることを具体的に提示するこ

【Harness Engineering入門】AIエージェントを制御するアプローチの登壇資料です。 https://findy.connpass.com/event/388471/

AI の技術記事は食傷気味なんですが、さすがにこれは効くと思ったパターンを見つけたので紹介します。 tl;dr プロンプト (skill / slash command) を書いた直後は「これで伝わるはず！」と思うのに、別のセッションで使うと暗黙知が不足していて、再現性がなくなる 思い込みは当人に修正できないバイアスなので、別の AI に実際にやらせて詰まった箇所をレポートさせる これを繰り返す。プロンプトが段階的に洗練される (TDD のテストと同じ位置づけ) 実際に手元 8 個の skill で試して、初稿 50 点が (AI 主観で) 80〜90 点まで上がった。ただし、モデルを変えての評価してないので、過剰に適応している可能性はある。 自分が書いたプロンプトを評価していますか? 自分は大学時代に暗黙知の研究をしていたのだが、世の人々は主観バイアスを過小評価している。また、AIは人間

嫌悪の裏側にある肯定 AI生成コンテンツに対する嫌悪感が、じわじわと広がっているように感じる。 2025年、Merriam-Websterが「slop（スロップ）」を年間ワードに選出した[1]。もともとエンジニアコミュニティの俗語だったものが辞書に載るほど一般化した。文法的には正しいけど中身がない、書く側はほぼゼロコストなのに読む側が苦労する、そして止める理由がない。そういうコンテンツがスロップと呼ばれるようになった。 この嫌悪は正当なものだと思う。 「『AI臭い』と言われるけど、AIだし、どうすりゃいいんだよ」[2]という記事は、AI臭さの正体を表面的なマーカー（語尾、emダッシュ等）ではなく、コミットメントの不在として整理した。LLMは統計的に最もありそうな次の語の連鎖なので、安全な中央に収束する。あらゆる方向に保険をかけた文章は情報量がゼロになる。これは自分にとっても納得感のある分析

はじめに 最近、海外のLLMコミュニティで 「caveman prompt」「speak like a caveman」 と呼ばれるプロンプト技法がちらほら話題になっています。Claude Codeに「原始人のように喋れ」と指示することで、挨拶・クッション言葉・冗長な前置きを削って応答を短くする ― ひいてはトークン消費を削減できる、という主張です。Reddit や X の一部スレッドでは「出力が劇的に短くなった」「コストが大幅に下がった」といった体験報告が流れており、日本語圏にも「原始人プロンプト」として紹介・翻案される事例が出てきました。 代表的な実装である JuliusBrussee/caveman は、出力トークンを~65-75%削減すると謳っており、Claude Code・Codex・Gemini CLI などに広くプラグインを提供しています。 そのうえで、この手法を「Claud

※これはマジで高純度の「お前が言うな」案件なので絶対にわたくしのブックマークを見ないで聴いてください。 仕事でもプライベートでもわりと長いこと記事を扱っているんですけど、記事をたくさんの人に読んでもらうというのがなかなか難しい時代になってきました。みんな動画や配信ばっかり見てるからね～、というのはまあそうなんですけど、それだけじゃなくてそもそも流入ルートがないんですよね。今。 このブログの話をすると、ここははてなブログなので、主な流入ルートははてな関連サービスです。 記事を書いたときに最初に見にきてくれるのは、たぶんはてなブログ上で読者登録をしている人。あとはXに「書きました」って書くのでそこから来てくれる人もいます。 で、その人たちが気に入ってくれてはてなブックマークを３人くらいつけてくれると、はてなブックマークの新着エントリに載ります。 そうするとはてなブックマーク側の新着一覧ページに