AI時代のエンジニアリング組織論 ■ 開発工程のボトルネックはコーディングから製品設計とコードレビューへ移行する リーガルAIのLegoraは、創業18ヶ月でARR1億ドルを突破し評価額56億ドルに達した最速のB2B企業である。CTOのヤコブ・ラウリツェンは、AIツールにより従来のボトルネックだったコーディングのコストは劇的に低下したと語る。現在、開発の真の制限要因は、顧客ニーズを製品設計へ落とし込む作業と、生成されたコードのレビュー工程へ移行している。そのため、同社はPMが顧客との対話に集中できる時間を守り、エンジニアをシステム設計に特化させている。 ■ トークンの消費量競争は開発組織を歪ませる無意味な評価指標である 多くのエンタープライズ企業が陥る失敗が、開発者評価にAIトークン消費量を持ち込むことである。トークン消費を可視化するリーダーボードを作ると、エンジニアは評価のためだけに無意味にトークンを浪費し始める。ラウリツェンはこの「トークンマクシング」を愚策と一蹴し、AI使用量そのものを報酬評価にしてはならないと警告する。組織が評価すべきは開発効率と実際のアウトプットの質であり、デモ等を通じて効率化の工夫を共有し合う環境こそが不可欠である。 ■ 開発者体験に特化した専門チームの設置が組織全体の生産性を最大化する 同社は、わずか80名のエンジニアでAccelやBenchmark、NVIDIA等から8億ドル以上を調達した。現在、Legoraのコードの50%以上はCursorやClaudeなどのAIツールにより生成されている。この開発速度を維持するため、同社は3名の開発者体験（DevEx）専門チームを早期から設置した。彼らは、エンジニア1人あたり最大10個の自律コーディングエージェントを回し、独自のCIレビューボットを開発して全員の開発を支援している。結果としてエンジニア全員が約20%効率化し、新人の即戦力化も劇的に加速した。 ■ 複雑度の低い社内ツールは購入するよりバイブコーディングで自社開発する AI開発において、同社は社内ツールの導入基準として、機能の広さと複雑度の深さという2つの軸を設けている。既存製品を購入するよりも、複雑度が低く自社専用のカスタマイズが必要なシステムは、バイブコーディングで自作する方が安価になった。特に人事管理やオンボーディングシステム、データ移行アプリなどは、AIを使って自立的かつ高速に自社開発することが推奨される。汎用ツールに頼る手間を省き、社内のAIイネーブルメントチームが直接プロトタイプを開発して課題を瞬時に解決している。 ■ 組織を急成長させるためにはエゴのない優秀な人材の密度を高める Legoraが競合を圧倒して超高速成長できた最大の要因は、優秀なAプレイヤークラスのエンジニア密度を極限まで高めたことだ。特に5〜8人規模のスタートアップチームを丸ごと買収するアクハイヤー戦略は、高いチーム開発力を一瞬で取り込む上で効果的だった。この統合を成功させたのは、役職やタイトルへの執着を一切排除する「ローエゴ（低自己愛）」の徹底した採用基準である。ラウリツェンは、最も優れた成果を出せる者が役割を担う機動的な文化を築き、エゴの排除が企業の成長速度を決めると実証している。

マネジメント色でありながら、どうやって技術力を保っていくか、という話。 ・EMにとって技術的習熟もはやオプションではなく必須のスキル ・技術的習熟とは、チーム内で最も優れたプログラマーになることを意味するではない ・システム構造や技術的な課題を的確に理解する能力のこと ・マネージャーが技術を理解していると、エンジニアは自分たちの状況や苦労を正しく代弁してくれると感じて強い信頼を寄せる ・技術的な知識があれば、現場のエンジニアの作業を中断させて質問することなく、マネージャー単独で迅速に意思決定ができる ・また、技術詳細をマネージャー自身が把握しておくことで、経営層などのステークホルダーに対する報告やフィードバックのサイクルを短縮できる ・他に、チームの業務に必要な技術的要件を正確に把握できるようになるため、採用活動においてもより優秀なエンジニアを見極めやすくなる ・マネージャーが技術力を維持し向上させるための実践的なアプローチとしては、主に4つの方法が存在する ・第一の方法は、AIに対する適切な指示出しであるプロンプトエンジニアリングのスキルを抑えること ・第二の方法は、現場のエンジニアと一緒に具体的なタスクに取り組みながら学ぶこと ・この共同作業はエンジニアの本来の業務を圧迫しないよう、ロードマップに影響しない優先度の低いタスクを選んで実施すると良い ・一緒に作業をする際は、評価目的ではなくマネージャー自身の学習目的であることを率直に伝えておく（負担になるから） ・第三の方法は、チームの業務に関連する特定の技術ドメインをひとつ選び、その分野の専門知識を計画的に身につけること ・第四の方法は、システムの将来性や保守性を大きく左右する重要なアーキテクチャ設計のレビューに積極的に参加すること ・技術的習熟は一度で終わるものではない ・日々の小さな積み重ねによる継続的な自己投資によるもの

開発者の生産性指標であるDORA、SPACE、DevExを統合したDX Core 4の解説記事からメモ。 ・開発者の生産性測定は難しく、ダッシュボードの海に溺れてしまうリーダーが多い ・DORAやSPACEといった指標のどれを使えばいいか迷う企業も少なくない ・そこで記事で提唱しているのが、それらを統合したDX Core 4というフレームワーク ・スピード、有効性、品質、ビジネスインパクトの4つの次元で構成 ・重要な特徴は、複数の次元を組み合わせることで指標のゲーム化を防ぐ点 ・例えばエンジニアあたりのDiff数は、単独で使うと開発者の恐怖を煽りやすい ・ただ、これを開発者体験の指標（DXI）などと組み合わせることで、有用なシグナルとして活用できる ・データ収集には、システム指標に加えて自己申告による計測の併用を推奨している ・システムからのデータ抽出のみに頼ると、ツールの統合などに膨大な時間がかかってしまうため ・なので、自己申告データを利用して素早くベースラインを作るのは1つの手

ザッカーバーグの強権モードが発動中とはいえ、記事に該当しているエンジニアはキャリアを相当考えるだろうなぁ。 ・ザッカーバーグはモバイルOSの波に乗り遅れた過去があ李、AIという巨大なトレンドを絶対に逃さないという強い決意を持っている ・metaは過去にメタバースへ巨額の投資を行ったものの、パンデミック後に人々の関心が薄れ、その投資は十分な成果を上げなかった ・自社開発のAIであるLlamaモデルを進める中で2025年発表のLlama 4が不調に終わった ・そのため、AI戦略の立て直しを迫られた ・で、Scale AI社の株式を巨額で取得した。同社CEOのAlexandr Wang をAI戦略のトップとして迎え入れた ・Wangが得意とするのはAIの学習に必要なデータラベリングや、人間によるフィードバックを用いたモデルのファインチューニング ・彼の主導により、metaのエンジニアのタイピングやマウスクリックを強制的に監視してAIの学習データにするシステムが導入された ・この監視システムは事前の相談や拒否権なしにトップダウンで決定され、従業員のプライバシーに対する大きな懸念を引き起こした ・多くの反発を受けた会社側は、監視を一時停止する機能を追加するなどの妥協案を後日提示することになった ・同時期にプロダクト開発の中核を担うチームから30パーセントから50パーセントものエンジニアが、AIデータラベリング部門へ強制的に異動させられた ・meta社では従来、入社後に研修を経て自身の所属チームを自由に選べる文化があったため、この一方的な異動は大きな波紋を呼んだ ・異動先でのデータラベリング業務はAIが生成したコードをテストしてフィードバックを与える単調な作業 ・多くのエンジニアのやる気を削いでいる ・特にインフラストラクチャやセキュリティを担当するチームへの影響は深刻であり、優秀な人材が次々と本来の業務から引き剥がされた ・会社全体で10パーセントのレイオフが予告されたことで、一ヶ月にわたり従業員は自分が解雇されるかもしれないという強い不安にも苛まれていた ・metaの人事制度にて、自身の評価を相対的に高めるためにあらゆる指標を最大化しようとする政治的な動きが横行している ・新たな評価指標としてAIトークンの使用量が導入された ・なので、エンジニアたちは評価を上げるためだけに無意味にAIツールを多用し始めた ・人間による入念なコードレビューよりも、AIを使って表面的な生産性を高く見せかけることが自己保身の有効な手段となっている ・本質的なプロダクト開発がないがしろにされた結果、エンジニアたちは会社に嫌気がさし、外部の面接対策サービスの利用登録者が急増している ・不満を抱える中核メンバーを引き留めるために会社は特別ボーナスを支給した ・だが、それでも彼らの離職意欲を根本から削ぐには至っていない ・5月末には、オバマ元大統領などの著名人のInstagramアカウントが次々と乗っ取られるという、同社史上最も恥ずべき大規模な障害が発生 ・この障害はパスワードリセット時の本人認証プロセスが根本的に欠如しているという、非常に初歩的な脆弱性を突かれたものであった ・セキュリティチームの人員が半減させられていたことと、AIが生成したコードをAIがレビューするというずさんな開発体制が障害の最大の原因だろう ・障害発生の翌日には会社のCISOが辞任を表明 ・経営陣と現場との間に深刻な亀裂が生じていることがうかがえる ・社内の全体会議では、現状を強制収容所に例えて不満を爆発させる従業員が現れるなど、組織内の混乱はもはや隠しきれない状態になっている ・CPOでさえも現在のメタ社の状況を狂気(insanity of this company)と表現しており、経営トップが引き起こした社内環境の劣悪さを公式に認めている ・この一連の混乱の元凶は、既存の主力事業やエンジニアの尊厳よりも新しいAIモデルの開発を何よりも最優先とみなしたザッカーバーグの独断にある ・IT業界全体でも、AIの能力を過信してシステムの安全性を軽視する傾向が見られる ・これをAI psychosisと呼んで危惧する専門家の声が上がっている ・metaの広告ビジネス自体はAIの恩恵を受けて過去最高の収益を上げている ・だが、その基盤を支える組織を自ら破壊しているのは皮肉 ・エンジニアを単なるコストとみなす現在の経営体制が続く限り、優秀な人材の流出は避けられない ・他のテクノロジー企業にとっては絶好の狩場となっている

東京・西早稲田にあるITエンジニアのための会員制図書館です。本を読むのもよし、もくもく作業するのもよし。月額会員またはドロップインでご利用いただけます。技術同人誌の委託販売や、イベントの開催・会場貸し出しも行っています。

🔄Loop Engineeringとはなにか？ もう「AIにプロンプトを打つ」作業は終わりにしませんか？これからは、エージェントを自律的に回す仕組みそのものを設計する時代です。AIコーディングのパラダイムシフトの正体に迫ります。 💡 1. プロンプトからシステム設計への転換 従来のAIコーディング（AI-assisted Coding）は、人間がループの「中心」にいました。 👨‍💻 これまでのアプローチ: 人間がコンテキストを考え、プロンプトを打ち、AIの出力を読み、手元でテストを実行し、エラーが出たら再度プロンプトを打つ。AIは「高機能な関数」や「道具」であり、制御の主体は常に人間です。 🔄 ループエンジニアリング: 人間はループの「外側」に出て、システム全体のデザイナー（作者）になります。仕事の検知、AIへのコンテキスト注入、出力の自動テスト、進捗の記録、次のステップの判断という一連のライフサイクルを小さなプログラムに実行させます。 ここで重要なのは、AIモデルがシステムにおける「サブルーチン（部品）」へと降格し、代わりに環境（テストスイートやリポジトリの状態）からのフィードバックをループ処理する構造へ進化したという点です。 ⚙️ 2. ループを駆動する5つのコアコンポーネント＋1つの記憶 抽象的な概念を動くシステムに落とし込むため、ループは以下のコンポーネントに分解されて設計されます。 ① ⚡ 自動化（Automations） ループの心臓部であり、発火トリガーと停止条件を定義します。 ツール（Claude CodeやCodexなど）では、単に定期実行する /loop だけでなく、明確な終了条件（例：「すべてのテストがパスするまで」）を満たすまでAIを回し続ける /goal コマンドなどがこれに該当します。条件が達成されるか、ハードストップ（予算や上限回数）に達するまで回り続けます。 ② 🌳 ワークツリー（Worktrees） 複数のAIエージェントが並列で動く場合、同じディレクトリで作業するとファイルの衝突（コンフリクト）が発生します。これを防ぐため、Gitの worktree 機能を使い、エージェントごとに独立した作業ディレクトリとブランチを隔離して自動生成します。機械的な衝突を回避し、並列性を担保する基盤です。 ③ 🧠 スキル（Skills） リポジトリのルールやコンテキストをカプセル化したものです。 通常、AIは実行ごとに前回の文脈を忘れますが、SKILL.md のようなファイルに「このプロジェクトのビルド手順」「命名規則」「過去の障害から得た注意点」を明文化しておくことで、AIは毎実行時にそれを読み込み、プロジェクト固有のシニアエンジニアのような振る舞いを固定化できます。 ④ 🔌 プラグイン／コネクタ（Connectors） filesystem（ローカルファイル）しか見えないAIを、本物の開発環境につなぐ架け橋です。 Model Context Protocol（MCP）などをベースに、GitHub（PR作成やIssue取得）、Linear/Jira（チケット更新）、Slack（人間への通知）、Sentry（エラーログの取得）と接続します。これにより、AIが「修正案を出す」だけでなく「Issueを読んで、コードを直し、PRを送り、Slackに報告する」というエンドツーエンドの行動が可能になります。 ⑤ 🤖 サブエージェント（Sub-agents） 役割を分担された独立したAIインスタンスです。「コードを書く役割（Maker）」と「コードを検証・レビューする役割（Checker）」を完全に分離します。 ➕ 💾 記憶：状態ファイル（State File） 地味ですが、ループの成否を分ける最も重要な要素です。STATE.md やJSONファイル、あるいは外部のチケット管理システムに「現在どのブランチが進行中で、何が完了し、次に何をすべきか」を永続化します。「エージェントは忘れるが、リポジトリは忘れない」という原則に従い、昨日の続きを今日のループが再開できるようにします。 🕰️ 3. なぜ「ただのcron（定期実行）」ではないのか？ 懐疑派から「1975年に発明されたcronジョブのリブランド（名前の付け替え）に過ぎないのではないか」という指摘があります。これは半分正解で、半分は間違いです。 スケジュールやトリガーのレイヤーは確かにcronそのものです。しかし、従来のcronは「固定されたスクリプトを機械的に実行するだけ」でした。 ループエンジニアリングが異なるのは、ループの真ん中に「状況を動的に判断する意思決定者（LLM）」がいる点です。 テストが落ちたとき、どのファイルをどう修正すべきか、コンテキストをどう組み立て直すかという分岐は、ハードコードされた if/else ではなく、AIの推論によって動的に決定されます。工学的な面白さは、この「崖から落ちるかもしれない不確実な意思決定者」の周りを、いかに硬牢な自動テストやガードレールで固めるかというシステムデザインにあります。 ⚠️ 4. コストと運用リスクの現実 熱狂的な議論で無視されがちなのが、経済性とセキュリティの現実です。 💸 膨大なトークン消費（コスト） コード生成自体は安価になりましたが、ループを回すと「コンテキストの再読み込み」「リトライの繰り返し」「探索パターンの実行」により、トークン消費量が爆発的に増加します。 実際に、米Uberではエンジニア1人あたり月1,500ドルの上限を設けたにもかかわらず、年間のAI予算をわずか4ヶ月で使い切った事例があります。「最大反復回数」「金額上限」「進捗ゼロ検知による強制終了」の3つのガードレール（ハードストップ）の設計が不可欠です。 🛡️ 攻撃面の拡大（セキュリティ） 無人で動くループは、無人で動く攻撃面（アタックサフェース）になります。AIコーディングツールに起因するCVE（脆弱性）が多数確認されており、コマンドインジェクションやSSRF、XSSのリスクがあります。また、外部から取り込んだ「スキル」の説明文がプロンプトインジェクションの経路になり、デバッグログ経由で認証情報（資格情報）が漏洩するケースも監査で報告されています。 🧩 理解の負債（Comprehension Debt） AIが高速でコードを書き、テストが通ってマージされ続けると、リポジトリ内のコードベースと「人間の理解度」の距離がどんどん離れていきます。これを「理解の負債」と呼びます。最も高くつくのはトークンの請求書ではなく、「チームの誰も読んだことがなく、構造を理解していないシステム」をある日突然人間がデバッグしなければならなくなるコストです。 🛠️ 5. 実践：4条件テストと最小実用ループ（MVL）の構築 ループエンジニアリングを実務に導入する際は、厳格な仕分けとステップが必要です。 📋 導入のための4条件テスト 1. タスクが繰り返されるか？（週1回未満なら、手動プロンプトや使い捨てスクリプトの方が早い） 2. 検証が完全に自動化されているか？（テスト、型チェック、Linter、ビルドが悪い出力を100%機械的に弾けるか。これがないと人間がレビューの椅子に縛り付けられる） 3. トークン予算が無駄を吸収できるか？（従量課金で予算に余裕がない場合は無謀） 4. エージェントが環境を操作する道具を持っているか？（ログ確認や再現環境など） 🚀 最小実用ループ（MVL）から始める手順 最初から複雑なマルチエージェントを組むとシステムは確実に崩壊します。以下の順番でボトムアップに構築します。 1. 手動実行の確実化: 1回の手動プロンプトと環境操作で、タスクが完全に完了することを確認する。 2. スキルの文書化: その際のコンテキストや制約を SKILL.md にまとめる。 3. ループのラップとゲート配置: AIが書いたものを自動テスト（ゲート）にかけ、失敗したらAIに戻すという1サイクルを組む。 4. スケジューリング: 最後にそれをcronやイベントトリガーで自動化する。 🎯 レバレッジの支点は「コードを書くこと」から「コードを書く仕組みを定義し、検証すること」へ移動しました。人間は、AIが自分の宿題を甘く採点しないよう、冷徹な「検証ゲート」を設計するエンジニアであり続ける必要があります。

社内のエンジニアのAIの使い方は人によってかなり違う。 Claude Codeに丸投げし、並列でぶん回して自分はレビューに徹する人もいる。 Cursorなどのタブ補完を軸に、あくまでも自分が手を動かす前提でAIを補助として使う人もいる。 同じエンジニアでも作る機能やタスクによって使い分けていそう。 ただ、AIに対して斜に構えた態度を取る人は、マジでいない。 セキュリティ面や理解負債といったネガティブな側面も認識してる。 だけど、それを理由にAIを遠ざけ、批評家に回ることはない。 「AIを使うのは当然」という前提のもと、「どうやればそれを乗り越えられるか？」という頭の使い方をしてる。 僕は学習のためにあえてAIを使わずにコードを書いてみたりと、AIから離れて自力で考える時間を作る方向で考えていた。 それはそれで続けていいはず。 ただ、それだけじゃなくて、「AIを使いながら、どう自分を成長させるか」にも、もっと頭を使う必要がありますね。

AIによって数学の未解決問題が解かれたという記事があったけど、それに対して一人のエンジニアの考えが述べられていた。 途中のくだりを少しだけ。 ・「最終的には人間の理解が必要になる」という反論がある ・だが、数学から科学、エンジニアリングに至るまですべてをAIが行うようになる ・理解のために人間をプロセスに挟む企業は、AIに任せる企業に競争で負ける ・結果として、人間は誰も仕組みを理解できない技術に囲まれて生きることに

社内のAI基盤を構築しているエンジニアたちを見ていると、今めちゃくちゃ面白い経験が溜まってそうだなと。 SlackやGitHubと連携させてClaude Codeから安全に参照できるようにしたり、権限管理、機密情報のマスキング、ガードレールなどを共通化したり。 試行錯誤しながら、AIを全社に仕組み化するための知見がどんどん溜まっていく。 一方で、それを使わせてもらうアプリケーション開発側は「そのAI基盤を使って、もっと生産性を上げよう」が中心になる。 だからやること自体はある意味で今までと同じ。 開発組織全体で見れば、その役割分担が合理的。というか、それがプラットフォームエンジニアリングなので。 ただエンジニア個人のキャリアで見ると少し気になる。 AI基盤そのものを設計・構築・運用する経験は、一部のチームにどんどん集中していく。 「AIを機能させる仕組みを作る側」と「用意された仕組みを使う側」で、数年後に積み上がっている経験の差がかなりつきそう。 事業を成立させる観点で「どっちが上」とかは本当にないと思っている。 だけど、個人的には基盤を作る側に回りたいな。

ポッドキャストの最新話もぜひ！🔔 #26# 企業と個人のAI格差：トークンエコノミクスと「ゆでガエル」にならないためのAIサバイバル術 Claude、Codex、GitHub Copilot。どれも良いけど、全部使いこなせてる人ってどれくらいいるんだろう？コストとパフォーマンスのバランス、モデルの使い分け、そして企業が指定するツールと個人が本当に使いたいツールのギャップ。AI時代の「サバイバル術」、今回かなり踏み込んで話してます！ —— チャプター: ・00:00 オープニング：AIモデルの変化とClaudeの価格設定 ・03:15 GitHub Copilotの動向とエンジニア組織のインフラ ・07:06 企業のAIユニットエコノミクスとトークン消費のKPI化 ・12:39 企業導入（Copilot）と個人利用（Claude）のギャップ ・14:21 ツールとスキルの関係性：企業が用意する環境と個人の能力 ・18:14 モデルの使い分け（SonnetとOpus）と出力の不確実性への対応 ・20:29 Metaのレイオフと日本の環境：ゆでガエルにならないために ・23:37 エンディング：次回のテーマ（3Dモデルツール）