LayerXの「haro」は、バクラクの開発に使う内製のBackground Coding Agentです。Web UIやSlackから依頼すると、クラウド上の開発環境でClaude Codeなどが作業します。公式記事を読むと、独自に作ったものの中心は「賢いモデル」ではなく、社内のコードを動かし、必要な情報を読み、結果を確かめるための基盤だと分かります。

以下は公開資料に基づく設計の読み解きです。haroそのものを導入・実行したレビューではありません。

worktreeを増やしても、実行環境は軽くならない

バクラクでは、多くのプロダクトを一つのmonorepoで開発しています。公式記事が挙げる悩みは、ビルドの重さに加え、Language Serverなどによるメモリ消費。git worktreeで作業場所を分けても、それぞれで開発用プロセスを動かせば、手元の計算資源には限界があります。

ただクラウドへ移せば済むわけでもありません。社内ツールや普段の開発環境を使えなければ、エージェントは修正案を出せても、動作確認の途中で止まります。haroの内製理由は、このリソース不足と、自社のコードベースに既製品を合わせる難しさの両方にあります。一般に内製が安い、あるいは既製品が劣るという話ではなく、バクラクの開発条件から出た選択です。

構成は大きく二つに分かれます。エージェントの制御はTypeScriptのTemporal WorkflowからAI SDKのHarnessAgentを介して行い、実行環境はEKS上に置く。環境のライフサイクルは、Goで実装したKubernetesのCustom ControllerとCRDで管理します。会話や作業の進行と、それを動かす環境の管理を分けているわけです。

さらに、Slack、Notion、Linear、Datadog、SnowflakeなどへMCPで接続し、利用者は普段の自分のアカウントで情報を参照します。「コードがある」だけでなく、「調査に必要な情報へ届く」までを環境に含めています。ただし、公開記事だけで認可の実装や隔離の強度まで検証できるわけではありません。

AndroidのUI変更を、マージの手前までたどる

仕組みが具体的に見えるのは、公式記事にあるモバイルアプリの例です。ちょっとしたUI変更を依頼した後、haro上では次の流れがつながります。

  1. エージェントがコードを変更する。
  2. クラウド環境のAndroidエミュレーターで動作を確認する。
  3. スクリーンショットを撮り、PRを作成する。
  4. 人間がマージ前に差分や確認結果をレビューする。

最後のレビューは人間に残るものとして読むべきで、記事は自動マージの成功を示していません。また、具体的な依頼文や合否基準はここでは補っていません。

この例で見るべき成果物は、変更したコードだけではありません。画面を動かして得たスクリーンショットも、レビュー材料になります。ローカルでは実機やエミュレーターの数が並列開発を制約していたのに対し、haroでは環境側でAndroidエミュレーターを動かす構成です。公開記事はこの制約の解消を報告していますが、クラウドの計算資源や費用まで無制限になるという意味ではありません。

自分たちの環境で同じ方式を検討するなら、いきなりエージェント基盤全体を作るより、小さなUI変更一件で比べるのがよさそうです。コード変更後にアプリが起動できるか、必要な画面に到達できるか、PRへ確認結果を渡せるか。これは本稿からの評価案であり、LayerXの導入手順ではありません。途中で人間がローカル環境を立ち上げ直すなら、そこが先に埋めるべき不足です。

再利用する単位は、プロンプトだけではない

haroでは、利用者が独自のAgentを定義できます。その定義は、system prompt、利用するMCP tools、起動する環境などの組み合わせ。WebやSlackだけでなく、SchedulerやHTTP（Connect RPC）のAPIからも呼び出せます。

公式記事には、flaky testの収集ダッシュボードにあるボタンから、API経由で修正セッションを起動する例もあります。人が問題を選ぶところと、その後の調査・修正を走らせるところを接続する使い方です。ここから得られる設計上のヒントは、「良い指示文」を共有するだけでは足りず、その指示を実行できるツールと環境も一緒に再利用する、ということです。

似た考え方は、haroの記事が参照するRampのInspectにも見られます。InspectはModalのサンドボックスVMに開発環境を用意し、フロントエンドでは目視相当の確認やスクリーンショット、ライブプレビューまで扱います。EKSを選ぶかModalを選ぶかより前に、「エージェントに何を確かめてから返してほしいか」を決める必要がありそうです。

なお、haroの2026年10月時点の「1日のPRの55〜60%程度がharo経由」という数字は、公式記事自身が普及率の間接指標と位置づけています。開発時間の短縮率や品質改善率ではありません。セッションのログからpromptやskillを改善し、使うほど改善が回る構想も、実現済みの効果とは分けて読むべきです。

内製するかを考える入口は、エージェントの選定よりも、修正から検証までのどこで作業が止まるか。その不足が既存サービスの設定で埋まるなら、まずはそこからで十分です。社内固有の実行環境や情報アクセスが繰り返し壁になるとき、haroのような基盤を作る理由がはっきりします。

参考