SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2026 Summer セッションレポート

AIで実装が速くなった後、何がボトルネックになるのか? インディードリクルートテクノロジーズが1年の社内実証で示した答え

【16-B-9】開発は速く安くなる。開発量は増える。ボトルネックは移動する。AI時代のエンジニアリング組織論

成否を分けたのは「コンテキストが推論の幅に収まるか」

 黒田氏は1年間で積み重ねた複数の現場事例を振り返る。使ったモデルに大きな差はなかったが、それでも結果は分かれた。成功した事例はいずれも、「1つの変更に必要なコンテキストをAIが誤りなく推論できる幅に収める工夫」をしていた。

成否を分けたのはモデルの性能ではなく、コンテキストの構造
成否を分けたのはモデルの性能ではなく、コンテキストの構造

 黒田氏がまず、大規模レガシーシステムAの事例を挙げた。JSP(Java Server Pages)とサーバーサイドで実装されたレガシー本体に手を入れず、JSPをAPIと捉えてJavaScript側に業務要件を実装。本体に触れないため影響が閉じ、AIに与えるコンテキストも小さくなった。進め方としては、経験者が暗黙知で文脈を補い、AIの推論を必要な範囲に絞り込んだ。「強い境界のある領域では、AIは安定して機能しました」と黒田氏は説明する。

 また「Airワーク 採用管理」の事例では、要件明確化からテスト生成・PRレビュー・振り返りまでをSkillsとカスタムエージェントのパイプラインに取り入れて、ベテランの暗黙知を仕組みとして外部化した。アーキテクチャはUI・BFF(Backend for Frontend)・APIがリクエスト単位で独立した疎結合構成だ。ベトナムオフショア開発の歴史的経緯から生まれた「冗長だが疎結合」という性質が、結果的にAIの推論と相性がよかったという。「AIを見込んで選んだ設計ではなく、振り返ると噛み合っていた、という順序でした」と黒田氏は振り返った。

 「フロム・エー ナビ」「はたらいく」「とらばーゆ」「リクナビ派遣」におけるSEO対策の事例では、Googleのガイドラインという一般論でAIの推論を拘束しやすく、改修もフロントエンドに閉じた。3カ月で63施策を実装できた一方で、その数字より大きな変化は「順序の逆転」だったという。会議で施策を絞ってから作るというフローをやめ、先にアイデアを全部作り、会議ではどれをリリースしないかを間引く形に変更。「実装が高価だという前提が崩れると、ボトルネックは実装から意思決定に移ります。だから会議の役割を組み替えました」と黒田氏は語る。「制約に従属させる」という考え方を開発プロセスに適用した形だ。

「AIに見えるコード上のロジック」と「コードの外にある本番の物理制約」
「AIに見えるコード上のロジック」と「コードの外にある本番の物理制約」

 だが失敗事例もある。「リクナビNEXT」のバッチ処理改善では、最終的にAIでの解決をあきらめ、テックリードが自力で解決した。重くのしかかったのは、再実行性・処理時間・整合性・負荷制約・データ分布といった、ソースコード上に出てこない現実側の制約だ。コードを全部読ませても、AIには本番の物理側が見えない。コンパイルも単体テストも通るのに本番で破綻するコードが出た。「しかも人間が書いたように見える分、レビューする側の批判的思考が止まりやすかったです」と黒田氏は振り返る。

 「Airワーク 採用管理」のEOSL対応では、当初、人手を挟まずに改善が回り続けるループエンジニアリング的な構造で組んだが、数日で数百万円分のトークン代を消費しても品質が収束しなかった。そこで役割を分離し、AIの担当を観点出しとYAMLのテスト仕様書生成に限定し、テストコードの生成は決定論的なプログラムへ、評価もテスト実行とカバレッジ計測で決定論的に行う構造に変えた。黒田氏は「確率論ベースの生成と、決定論ベースの評価系を分ける、ハーネスエンジニアリング風の形への移行でした」と説明する。

 これらの事例を振り返り、黒田氏はできることは実質2つしかないと整理する。AIが誤りなく推論できる幅に対して、「必要なコンテキスト量を減らす」か「与えられるコンテキストを増やす」かだ。SEOで成功したのは一般論でAIの推論を拘束しやすくコンテキストが構造的に絞り込まれていたから。リクナビNEXTのバッチで苦戦したのは、本番の物理制約というコンテキストがほとんど与えられていなかったからだと分析できる。

 またチームのLLMの使い方は、2つのパターンに分かれてきたという。レガシーシステムAのように経験者が暗黙知で対話しながらAIの推論を制御する「協働型」と、Airワークのように技術者がSkillsやカスタムエージェントで生産ラインを設計し再現性を確保する「委託型」だ。「優劣はなく、不足しているコンテキストを人経由で与えるか、システム経由で与えるかの違いです」と黒田氏は述べる。

AIによって速くなった実装の陰で、浮かび上がってきたもの

生成が安くなると、コミュニケーションコストが高く見えてくる
生成が安くなると、コミュニケーションコストが高く見えてくる

 そして開発コストが下がると、次に浮き上がってくるのが工程間のコミュニケーションコストだ。例えば8人が相互にやり取りすると、パスは56本。人数が増えればパスは2乗で増える。「各工程の作業はAIで速くなりますが、工程間の受け渡しはそのまま残ります。実装がボトルネックだった時代には見えなかったこのコストが、次のボトルネックになります」と黒田氏は指摘する。

 フレデリック・ブルックスが『人月の神話』で指摘したこと、メルヴィン・コンウェイが組織とシステムの相似で示したこと、そして経営学者の竹内弘高氏と野中郁次郎氏が『The New New Product Development Game』で論じたラグビー型オーバーラップ。こうしたコミュニケーションコストという古典的問題が、AIによって再び前面に出てきた。では、インディードリクルートテクノロジーズはこれにどう応えたのか。

次のページ
コミュニケーションコストに立ち向かうための2つのアプローチ

この記事は参考になりましたか?

Developers Summit 2026 Summer セッションレポート連載記事一覧

もっと読む

この記事の著者

森山 咲(編集部)(モリヤマ サキ)

CodeZine編集部所属。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

川又 眞(カワマタ シン)

インタビュー、ポートレート、商品撮影写真をWeb雑誌中心に活動。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29443 2026/09/17 09:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー