■ 1. 登壇者と背景
- 登壇者: Indeed Recruit Technologies VP 黒田樹（DEVELOPERS SUMMIT 2026 SUMMER）
- Indeed PLUSを提供するリクルートのHR Tech SBU所属
- 2025年6月にClaude Code、2025年9月にCodexを部署全体のエンジニアへ配布
- 使い方を指定せず現場ごとに自然発生的な活用を観察し、その結果と組織変容が本講演の内容
■ 2. 中心テーマ：ボトルネックはどこへ移るか
- AIを巡る議論は「仕事が消えるか」「どのモデルが賢いか」に集中しやすい
- 本講演の問いは第三の視点：「ボトルネックはどこへ移るか」
- 実装がAIで速くなっても、開発全体が同倍率で速くなった現場は存在しなかった
- 要求・要件・テスト・運用のいずれかが次のボトルネックになる
■ 3. 歴史が示す技術革新と雇用の構造
- 産業革命:
- 蒸気機関から工場動力への置換に約1世紀を要した
- 変化は急激ではなく、労働者数は減少せず増加した
- 機械化で製品が安くなり需要が増大したため（ジェボンズのパラドックス）
- 英国の石炭消費は1900年までに3倍に増加
- 自動化と雇用の基本構造（Acemoglu & Restrepo）:
- 代替効果: 既存タスクを機械が置換
- 復権効果: 人間に比較優位のある新タスクが生まれる
- 復権は自動では起きない——技術に合わせて仕事を組み替えた側にのみ来る
- 電気化の教訓:
- 蒸気機関をモーターに置換しただけの工場では生産性は約30年上がらなかった
- 各機械にモーターを付け作業順序を組み替えた工場でのみ効果が出た
- IT史における同構造の繰り返し:
- 1960年代のメインフレームから2010年代クラウドまで、技術革新のたびに職能が置換・創出
- 抽象化が起きると職能は「基盤を支えるコア側（少数・深化）」と「抽象の上に立つスケール側（多数・拡大）」に二分される
- 日本のITエンジニアは1985年の約32万人から2024年の約144万人へ4.5倍増（ジェボンズのパラドックスの再現）
- AI時代の含意:
- 今回AIが抽象化しつつあるのはコーディングを含む「実装とその周辺（設計案・テスト・調査・移行・レビュー補助）」
- 歴史構造に従えば史上最大級の職能分化と再配置が起きる
■ 4. 開発の経済性の変化
- AIにより開発コスト（Investment）が低下し、ROI成立境界が下がる
- 従来はROIが合わなかった部署単位・顧客単位・業務単位の個別開発が採算に乗り始める
- 直面するのは「作れない」ではなく「作る対象が増え続ける」状況
- ただし下がるのは初期開発のコストのみ:
- 検証・統合・運用・保守・障害対応・セキュリティ・責任といった維持コストは自然には下がらない
- 開発量が増えるほど維持保守の負荷は増大する
■ 5. 社内実証：6事例の観察
- 成否の差は「モデルの性能」ではなく「コンテキストの構造」によって生じた
- 成否を左右した6観点:
- 必要コンテキスト量
- 現実世界依存性
- 影響範囲の閉じやすさ
- 決定論的検証のしやすさ
- チームの経験量
- 自動化との相性
- 事例1 大規模レガシーシステムA（成功）:
- レガシー本体に触れずJSPをAPIと捉え、includeされるJavaScript側で業務要件を実装
- 影響範囲が閉じ、AIに与えるコンテキストが小さくて済んだ
- 経験者が暗黙知で文脈を補い、AIの推論を必要な範囲に絞り込んだ
- 事例2 Airワーク採用管理（成功）:
- 要件明確化から実装・テスト生成・PRレビュー・振り返りまでをSkillsとカスタムエージェントのパイプラインに組み暗黙知を外部化
- アーキテクチャがUI/BFF/APIをリクエスト単位で独立させた疎結合構成であり、変更一件に必要なコンテキストが小さかった
- 疎結合はAI活用を見込んだ設計ではなく、ベトナムオフショア開発の歴史的経緯によるものだった
- 事例3 複数求人サイトのSEO（成功）:
- GoogleガイドラインやSearch Consoleなどの一般論でAIの推論を拘束でき、改修もフロントに閉じた
- 起案から実装まで0.5日、3カ月で63施策を実装
- 最大の変化は「順序の逆転」：会議で絞ってから作るのをやめ、全部作ってから会議で間引く方式に転換
- 制約理論の「制約に他工程を従属させる」発想をプロセスに適用した形
- 事例4 リクナビNEXTバッチ（失敗）:
- 性能問題のあるバッチ処理改善にAIを使おうとして苦戦し、最終的にテックリードが自力で解決
- 再実行性・処理時間・整合性・負荷制約・データ分布といったコード外の現実制約が支配的だった
- コードを全部読ませてもAIには本番の物理制約が見えない
- 偽陽性（コンパイルも単体テストも通るのに本番で破綻するコード）が生じ、人間が書いたように見えるため批判的思考が止まりやすい
- 事例5 AirワークEOSL対応（試行錯誤から成功）:
- ライブラリ・言語バージョンアップ用の保全テストを大量生成する目的
- 初期のラルフループ（while :; do cat PROMPT.md | claude-code ; done）では品質が収束せず数日で数百万円のトークン代を消費
- 原因: 要件・観点・コード生成・評価が一つの生成に混在し、探索空間が大きすぎた
- 成功した形:
- AIの役割を観点出しとYAMLテスト仕様書生成に限定
- YAMLからのテストコード生成は決定論的プログラムが実行
- 評価はテスト実行とカバレッジ計測で決定論的に実施
- 不足した観点のみをAIに追加生成させて次周回へ
- 確率論ベースの生成に対し、品質責任を決定論的評価系に寄せる「ハーネスエンジニアリング」形式に移行
- 事例6 AI-OPS（成功）:
- アラート起点の障害調査（ログ・ソースコード・運用知識・JIRA横断）をAIに委ねた
- 一次調査からJIRAチケット起票まで一気通貫で自動処理
- AIは「受け止める側の仕事」にも有効
■ 6. 観察の一般化：コンテキスト構造の問題
- AI開発の本質は「理想的出力に必要なコンテキスト」と「実際に与えられるコンテキスト」の差を管理するゲーム
- 差が大きいほど推論の自由度が増し、偽陽性とハルシネーションが増える
- 操作できるレバーは実質2つ:
- 必要なコンテキストを減らす（アーキテクチャで強い境界を設ける・問題を分割する）
- 与えるコンテキストを増やす（skills・sub-agents・契約・テンプレートで供給）
- LLMの使い方は2つの流派に収束:
- 協働型（コパイロット型）: 経験者が暗黙知を内側に持ち、対話でAIの推論を制御（レガシーAが該当）
- 委託型（オーケストレーター型）: 暗黙知を仕組みとして外部化し再現性を作る（Airワークが該当）
- 優劣なし——チームの経験量と現場特性で使い分ける
- アーキテクチャは推論を小さくする装置になる:
- 境界が明確で契約が強く影響範囲が閉じた構造は人間にもAIにも読みやすい
- ただし現在のAI性能を前提にコンテキストウィンドウへ収めることを頑張りすぎないほうがよい（将来の性能向上により過剰分割が損失になりうる）
- 生成は確率的でよい、受け止め方は決定論で:
- 受け入れ条件のコード化・契約テスト・観測設計・段階リリース・ロールバックで品質責任を決定論的機構に置く
- 「AIに正しさを期待するのではなく、間違っても壊れにくい系を先に設計する」
■ 7. 人間と組織の変容
- 人間の仕事は全工程に薄く残る——「問いを立てる・判断する・境界を引く・品質責任を持つ・異常時に介入する」
- 生成コストが下がるほどコミュニケーションコストが相対的に高くなる:
- 8人の相互やり取りは56本のパスを生む（人数の二乗で増加）
- 工程間の受け渡し（ハンドオフ）コストはAIでは縮まらず次のボトルネックになる
- コミュニケーションコスト対処の2系統:
- モノ的アプローチ: アーキテクチャで境界を切りパスを断つ
- ヒト的アプローチ: 一人が担う範囲を広げ人数Nを減らす
- 「フルフル」（フルスタック × フルプロセス）の採用:
- フルスタック: 一人がBE・FE・インフラを横断してカバー
- フルプロセス: 一人が要件定義から実装・テストまで複数工程を担当
- 一人の担当範囲が広がるほど工程間の受け渡しが減少し速度が上がる
- 組織の階層を浅くする:
- 深い階層は事前調整で不確実性を下げる代わりに個人のストレッチ幅を制約する
- フラットな座組は事前調整を最小にしてリアルタイム調整を最大にする
- メンバーが通常より広い責務と判断範囲を担う形で運営した
■ 8. KTLO（Keep The Light On）への対応
- 作るコストは下がる、動かし続けるコストは自然には下がらない
- ROI成立境界の低下で小さなシステムが増えるほど維持保守対象のロングテールが伸びる
- システム同士がAPIとデータで絡み合い「依存関係のスパゲッティ化」が前例のない規模で起きる
- 維持保守対象の爆発を人員の線形増加で受けるのは限界があり、AIレバレッジが必要
- KTLOセンターとして受け皿を集約:
- まず70リポジトリ規模のマイクロサービス群から着手
- 担当業務: 24/365のトラブル対応・各種パッチ当て・EOSL対応・バージョン管理・問い合わせ対応
- AI-OPSをフル活用するベトナムオフショア体制で検証中
- 市場側の出口としてFDE（Forward Deployed Engineer）の台頭:
- 旧来の「1パッケージをN社に売る」モデルは全社共通システムへの我慢を前提としていた
- 個別実装がROIに乗る時代では、顧客現場で業務文脈を理解しその場で実装する職能が必要になる
- 実態は「フルフル人材が社外の現場に立つ形」
- 前線が個別最適を作り、KTLOセンターが支えることで量産が事業として回る
■ 9. 結論
- 結論: ボトルネックに合わせた組み替え（制約理論の「制約に他工程を従属させる」の適用）
- プロセス: 判断に実装の順序を従属（SEOで「絞ってから作る」から「全部作ってから間引く」へ）
- 生成管理: 確率的生成を決定論的検証ループへ従属（AirワークEOSL対応）
- 組織: 判断の速さに組織の形を従属（階層を浅く・フルフル化）
- アーキテクチャ: 検証のしやすさに推論の幅を従属（境界と契約で推論を局所化）
- 制約は消えずに移動する——AIでも産業革命・電気化と同じ構造が繰り返されるという見立てのもと、速くなった実装をそのまま最大化せず、ボトルネックの工程に合わせて組織・プロセス・アーキテクチャを組み替えることから始めている