はじめに

この数ヶ月で、自分の手でコードを書くことはほとんどなくなりました。そういう人が増えているとは聞いていましたが、まさか自分もこんなに早くそうなるとは思っていませんでした。

NearMeでは昨年ごろからAIコーディングを開発フローに取り入れてきました。いま起きているのは、開発がAI主体へと変わる劇的なパラダイムシフトだと感じています。

本記事では、AIコーディングへの適応度をどう捉えているか、現在どのような取り組みを進めているかを紹介します。なお、ここで述べることは、ツールや手法を含め、すべて現時点のスナップショットです。変化のスピードは速く、半年後にどうなっているかは未知数ですが、根底にある考え方は残り続けると思っています。

AI適応のレベル分け

私なりの整理ですが、AIコーディングへの適応度を次のレベルで捉えています。

レベル	AIに任せる単位	イメージ
Lv1	コーディングの補完	エディタ上の数行のサジェスト
Lv2	関数の生成	仕様を伝えて関数単位で書いてもらう
Lv3	小さな機能の生成	1ファイル〜数ファイルの変更を任せる
Lv4 ← 今ここ	大きな機能の生成	複数リポジトリにまたがる機能開発や大規模リファクタリングを任せる
Lv5	開発サイクルの自動化	要件定義から実装、リリース後の評価・改善までを任せる

Lv1〜Lv2は「賢い補完」の延長で、既存の開発フローを変えずに恩恵を受けられます。Lv3あたりから「人がコードを書く」前提が崩れ始め、Lv4では開発がAI主体になり、人の仕事の中心が、コードを書くことから任せ方の設計と結果の検証へ移ります。対象は新機能に限りません。大規模なリファクタリングや、既存コードの深い理解が必要な機能拡張にも使えるようになってきました。

Lv4が現実的になったのは、ここ数ヶ月のことです。昨年はLv1〜Lv2の段階にいたことを思うと、展開が非常に速いです。我々は今、組織としてこのLv4への適応を進めています。

その先には、開発サイクル全体を自動化するLv5も見え始めています。現在はまず、開発の周辺領域から自動化に着手しています。Slack経由の問い合わせをAIが調査して一次回答し、必要に応じてチケットを作成する運用を始めました。バグであれば、そのまま修正の実装までつなげることも試みています。

AI主体の開発を支える組織の仕組み

Lv4では、大きな機能をAIエージェントに任せると次のような問題にぶつかります。

• エージェントがリポジトリごとの規約や設計方針を知らず、動くけれど流儀に合わないコードを量産する
• 大きなタスクを一息で任せると、途中で方向を誤ってもそれに気づけない
• 生成されるコードの量が人間のレビュー能力を超える
• 「動いた」の確認が甘いまま変更が積み上がる

同じモデルを利用できる以上、モデル自体は差別化要因になりにくく、差がつくのは、モデルを取り巻く実行環境 — 指示書、ツール、権限、検証の仕組み — です。これは一般に**ハーネス（harness）**と呼ばれます。Lv4への組織的な適応には、ハーネスを育て続けることが欠かせません。

ハーネスが担うのは、品質の確保だけではありません。自律的に動くエージェントには、誤った操作によるサービス障害や情報漏えいのリスクが伴います。実行できる操作や参照できる情報を権限で制御し、本番に影響する操作には人間の承認を挟むことも、ハーネスの重要な役割です。

ハーネスの育て方には、確立された正解はまだありません。世の中のプラクティスに学びつつ、指示や仕組みを少し変えては挙動を観察する。その繰り返しで手探りしていくしかなく、プログラミングというより化学実験に近い感覚です。以下では、そうした試行錯誤を経て運用に定着した組織の仕組みを紹介します。

1. エージェント向けインストラクションの一元管理

NearMeのサーバースタックは、ride-api（配車注文）、user-api（ユーザー・組織）、payment-api（決済）など20近いリポジトリで構成されています。エージェントに品質の高いコードを書かせるには、各リポジトリの規約 — 言語の流儀、ORMの使い方、テストの書き方 — を教える必要がありますが、リポジトリごとに指示書を手書きしていては、すぐに内容が重複・矛盾していきます。

そこで指示書を レイヤー として一元管理しています。「全リポジトリ共通」「TypeScript」「APIサーバー」「特定ORMの規約」といった関心事ごとにレイヤーを定義し、マニフェストで各リポジトリに適用する組み合わせを宣言します。同期コマンドを実行すると、各リポジトリに指示ファイルとオンデマンドのスキル（定型タスクの手順書）が生成されます。規約の改善は1か所の編集で全リポジトリのエージェントに行き渡ります。

なお、指示ファイルの名前や配置の仕様はプロバイダー（Anthropic、OpenAIなど）ごとに異なりますが、現時点ではシンボリックリンクなどを使い、同じ内容を各プロバイダーの仕様に合わせて展開しています。

運用上のポイントは、セッションごとに必ず読み込まれる指示書を、可能な限り簡潔に保つことです。指示もコンテキストを消費するため、常時ロードするのは普遍的なルールだけに絞り、状況に依存する詳細な手順は必要なときだけ読み込まれるスキルに逃がします。指示書は書いて終わりではなく、育て続ける資産です。

2. プラン駆動の実装

Lv4への移行に最も効いていると感じるのがプラン駆動です。大きな機能は、いきなり実装させず、まず実装計画（プラン）を書かせるところから始めます。プランはチェックリスト形式のMarkdownで、フェーズごとの手順、対象ファイル、決定済みの設計方針を含みます。一つのプランに収まらない仕事は、サブプランに分割します。AIにどこまで任せられるかは、結局、計画を言語化して合意できるかどうかで決まります。

プランは「人がレビューできる中間成果物」であり、「どのエージェントでも作業を再開できる指示書」です。チェックリストを消し込みながら進むため、セッションが途切れても別のエージェントが続きから再開できます。人間はコードより先にプランをレビューするため、方向性の誤りを早い段階で修正できます。

プランには、進行中のタスク管理と、設計判断の背景や理由を残す記録という二つの役割があります。人間向けのタスク管理とは役割が異なるため、エージェントがいつでも参照できるよう、コードと同じリポジトリの docs/plans/ に置き、完了したら docs/plans/archive/ に移すようにしています。

また、プランに沿った実装が完了したら、変更内容を機能仕様ドキュメントにも反映します。仕様とコードの乖離（ドリフト）を検知する仕組みもあわせて運用し、エージェントが参照するドキュメントが陳腐化しないようにしています。

3. 敵対的レビューループ

Lv4で深刻なのがレビューのボトルネックです。

きっかけは、AIで書いたPRをレビュアーがAIでレビューし、実装者がその指摘を受けてまたAIで修正する、という往復が繰り返されるようになったことでした。このやり取りが人間を挟んで何度も続くなら、収束するまでの部分は最初から自動で回せばよい — それが敵対的レビューループです。

実装したエージェントとは独立したレビュアーを立て、レビューには能力の高いモデルの利用を推奨しています。レビュアーには、変更内容を「本当にバグはないか」と敵対的な視点から検証させます。指摘された箇所を実装側が修正し、同じレビュアーが再レビューします。これを指摘がなくなるまで、上限回数付きで自動的に繰り返します。

実際に運用してみると、能力の高いモデルが書いたコードでも、タスクの難易度によっては見過ごせない問題が見つかります。ループを重ねるごとに指摘は減り、どのタスクも収束に向かっています。プランの節目では必ずこのループを回すことをルール化しており、「実装→敵対的レビュー→修正→収束→人間のレビュー」が標準の流れになっています。

AIが実装したコードを独立したAIエージェントがレビューすることで有効な指摘が得られる理由について、いくつかの仮説があります。一つはコンテキストの分離です。実装側は作業経緯や思い込みを引き継いだまま自己チェックするのに対し、レビュアーは実装の経緯を知らず、前提を共有せずに変更を検証できます。もう一つは、「敵対的」という指示が前提条件を疑うよう促すことです。限られた試行では、指示なしの場合より的確な指摘が増える傾向が見られました。追加の推論時間が寄与している可能性もあります。厳密な検証はしていませんが、現時点ではコンテキストの分離と指示の影響が大きいと見ています。

レビューの過程で「今後も注意すべき」教訓が見つかったら、その場で共有インストラクション（前述のレイヤー）に還元するスキルも用意しています。失敗から得た学びを組織の知見として蓄積するためです。

4. 実物で動かして検証する — 変更ごとの検証環境

「テストが通った」と「実際に動く」の間には距離があります。そこで、git worktreeを使い、ブランチやPRごとのサービス群を本体の開発スタックと並行して立ち上げる仕組み（社内ではvariantと呼んでいます）を用意しています。狙いは二つです。AIエージェントによる複数の機能開発を同時に走らせることと、量産されるPRの動作確認を速くすることです。

エージェント自身も、変更後のシステムをブラウザやAPI経由で動かして確認できます。開発スタックはマイクロサービス構成なので、変更のあるサービスだけをコンテナとして立ち上げればよく、複数の並行環境を軽量に維持できます。詳細は技術勉強会の資料で紹介しています。

5. 大量のPRを捌く — リリース運用の補助ツール

コード生成が速くなると、PRの数も増えていきます。リリース前のPR確認の負荷が上がってきたため、PRを機械的に仕分ける補助ツールを開発しました。タスク管理ツール上のリリースタスクとGitHubの実態（レビュー状況・CI・コンフリクト・変更内容）を突き合わせ、各PRを「マージ不能」「マージリスク大（DBスキーマや発行SQLに変更がある、コード変更量が多いなど）」「マージリスク小」などに自動分類します。

このツールは分類と報告だけを行い、マージという状態変更は人間が判断する設計です。自動化で確認の優先度をつけ、人間は最もリスクの高いところに集中する — レビューの負荷を下げる工夫の一つです。

最終的なボトルネックは、人間のコード理解です。仕分けで確認の優先度をつけるだけでなく、各PRを理解しやすくする工夫も重要です。たとえばPRの説明文には、変更の因果フロー — どの変更がどう連なって目的の挙動を実現するか — を番号付きで書かせ、レビュアーが読む順番に迷うことなく差分の意図を追えるようにしています。

エンジニアの役割はどう変わるか

ボトルネックはレビュー・検証へ

コードを書くコストが劇的に下がり、生成されるコードが増えた結果、ボトルネックはレビュー、テスト、検証へ移っています。上記の仕組みは、開発能力そのものを引き上げ、品質を保ちながら成果をユーザー価値につなげるための投資です。

AIエージェントを采配し、成果に責任を持つ

この変化に伴い、エンジニアの仕事の重心も大きく変わります。その役割は、コードを書く人から、AIの成果物に責任を持てる人 — 設計判断を下し、検証の仕組みを整え、最終的な品質を担保する人 — へシフトしています。

仕事の進め方でまず重要になるのが、エージェントの並列化です。エージェントに任せる時間が長くなると、一つのセッションを眺めて待つのは非効率です。複数のワークツリーやセッションでエージェントを並列に走らせ、それらを一覧・監視できる環境（herdrのようなセッション管理ツール）を整えることで、一人で複数の変更を同時に進められます。感覚としては「手を動かす人」から「複数の作業者を采配するリード」への転換です。

同時に、モデルの使い分けと推論レベルの調整も必要です。プランの作成やレビューのように誤りのコストが大きい工程には最も能力の高いモデルと深い推論を割り当て、定型的な実装には軽めの設定を使う — というのが現時点の経験則です。ほかにも、どのコンテキストを与えるか、長くなったコンテキストをどう圧縮するかといった調整も日常的に行っています。

こうした働き方で成果に責任を持つには、自律性がこれまで以上に重要になります。指示を受けて動く受け身の姿勢から、自ら課題を捉え、進むべき方向を定める姿勢へ転換する必要があります。一人で並行して扱うタスクが増えるため、タスク管理の力もあわせて求められます。また、AIの支援で不慣れな領域にも踏み込みやすくなったいま、得意領域に閉じず、越境して開発の幅を広げることも重要です。

AI主体の開発では、AIに最初の方向性を与えることも、人間の重要な役割です。指示の階層で見れば、現時点で最高水準の性能を持つフロンティアモデルを使うエージェントが、サブエージェントを導く上位レイヤーを担う一方、人間はさらにその上で、解くべき課題、守るべき制約、成功の条件を定める最上位レイヤーを担います。最初の指示の質が、その後のプラン、実装、検証のすべてを左右します。

この役割を担うために必要なのは、コーディングの知識だけではありません。ドメイン、インフラ、データ、プロダクトにまたがる幅広く深い知識と、要件を引き出してAIに正確に伝え、成果物の内容について関係者と合意を形成するコミュニケーションスキルの比重も明らかに上がっています。スキルの重心は変わりますが、こうした人材が生み出せる価値はむしろ大きくなるというのが実感です。

開発の前提と制約が変わる

変わるのは、個人の役割だけではありません。ボトルネックの移動は、開発プロセスにも見直しを迫ります。スプリントの長さ、見積もり、タスクの粒度といったスクラムの運用にも、「人がコードを書く速度」を前提に組み立てられている部分があるからです。我々もまだスクラムを大きくは変えられていませんが、継続的に見直すべきテーマと捉えています。

開発が速くなると、課題も早く尽きるのではと思う人もいるかもしれません。しかし、NearMeが挑むモビリティ領域では、その気配は当面ありません。ユーザー向け・運行管理者向け・ドライバー向けのWeb／モバイルアプリ、予約システム、直前予約に対応するリアルタイム配車システム、相乗り・配車の最適化、そしてAIエージェントによる配車手配や問い合わせ対応など、新規・既存を問わず、価値を届けられる余地はまだ数多く残っています。

さらに、これまで開発規模や難易度のために費用対効果が見合わず、着手をためらっていた領域にも手が届くようになりました。事業として取り組める選択肢が広がるとともに、開発基盤の整備やプロダクトの品質向上に回せる余力も生まれています。

AI適応を全社へ広げる

AIの可能性は、開発に限りません。NearMeでは、社内で現時点のAIの実力を評価するなかで、職種を問わずさまざまな業務に活かせる大きな可能性を感じました。そこで、PdM、デザイナー、営業、オペレーション、カスタマーサポート、コーポレート部門を含む全社員にAIのアカウントを配布し、全社的なAI適応を進めています。

まず重視しているのは、実際に使ってみることです。どの業務にAIが効くかは、頭で考えるより使ってみたほうが早く見えてくるからです。

こうした活用を全社に広げ、定着させるため、専任チームも立ち上げました。アカウント管理や利用状況を踏まえた活用促進に加え、開発で培ったAI活用の知見も活かしながら、各業務へのハーネス導入や社内プラクティスの共有を進めています。

実際、エンジニアやPdMにとどまらず、営業までがAIを使ってリポジトリを調査し、課題の切り分けや解決の検討を進められるようになっています。最終的にエンジニアの協力が必要な場合でも、各職種が課題への理解を深めたうえで連携できています。

全社でAIに適応する意義は、個々の業務の効率化だけではありません。さらに、AIを使った開発が広く普及し、コモディティ化するほど、相対的に価値が高まるのが現地現物の情報です。AIはコードやドキュメントに書かれたことはよく理解しますが、そこに書かれていないこと — ドライバーの実際のオペレーション、空港送迎の現場で起きる例外、ユーザーが口にする不満 — を自ら知ることはできません。現場でしか得られない情報をつかみ、それを素早く的確に開発へつなげる力が、AI時代における企業の競争力を左右します。

おわりに

「コーディングの終わり」は、エンジニアの終わりではありません。そしてAI主体の時代に適応するには、ツールを導入すれば済むわけではなく、個人の働き方と、それを支える組織の仕組みの両方を変える必要があります。組織には、個人の工夫や失敗から得た知見を共有資産に変え、ハーネスと開発プロセスを継続的に育てる役割があります。一方、個人はAIの進化に適応し、自ら課題を捉え、その力を最大限に引き出していく必要があります。

Lv4への適応はまだ道半ばで、その先にはLv5が控えています。この変化を楽しみながら、仕組みごと進化していく組織でありたいと思います。