記事一覧

LayerX を1ヶ月楽しんできました!【インターン参加記】

LayerX で1ヶ月の就業型インターンをしてきた参加記です。今が旬の AI Agent 開発や、勝手に色々と改善した話、CI高速化などについて書いています。

目次はじめに

こんにちは、しーぴー (@cp20) です。9月から10月初めにかけての LayerX でインターンに参加させてもらったので、その参加記です。 時期としては1か月ちょっとですが、実稼働日数としては20日で、ちょうど1か月ぐらい働いていました。 Bet AI している会社に1か月もいると色々あるもので、ここではその色々を書いていこうかと思います。

やったこと

インターン期間中にやったことをいくつか紹介します。1か月のインターンとはいえ、Codex さんと Claude Code さんの力によってある程度の成果を出すことができました。

1. メインタスク (haro 開発)

多くのインターン生はプロダクトチームに配属されると思うのですが、ボクは Enabling チームに応募したので @izumin (@izumin5210) さんの下で Enabling チームとして働くことになりました。 チームに配属された後、izumin さんに「何やりたいですか?」と聞かれたので、「何でもやります」と答えたところ、Enabling チームの一部のメンバーで開発している haro という AI Agent 基盤の開発を一緒にすることになりました。

haro はいろいろ経緯 (詳しい経緯は↑のスライド参照) を経て今開発しているのは v2 なのですが、v2 の開発が始まったのは比較的最近で、まだ社内でもほとんど使われていない状況でした。 ボクも微力ながらいくつかメイン機能を実装したりして、9月の終わりごろには多くのエンジニアに使ってもらえている状況になりました。ありがとう。

haro の利用者数の推移 (週ごと)
インターン期間8/178/248/319/79/149/219/2810/510/12

ちょうど今日 izumin さんによる公式(?)ブログが出たので、haro が何たるかについてはそちらを見てもらうのが手っ取り速いかと思います。

LayerX エンジニアブログHatena Blog内製 Background Coding Agent “haro” で拓く未来の開発体験LayerX バクラク事業部 Platform Engineering 部 Staff Software Engineer の izumin5210 です。バクラク事業部 Platform Engineering 部では、社内のプロダクト開発を支援する、クラウド上で動作する Coding Agent “haro” を開発しています。id:izumin5210 · 2026-10-22

そんな haro 開発に少しばかり貢献してきたわけですが、メインで作った機能のうち大きめのものを2つ紹介します。

カスタムスキル

よく使う作業の手順やレビューの観点を「スキル」として haro に登録して、チームで共有・再利用できるようにする機能です。

スキルの登録や更新は、チャットでエージェントに頼むだけでできます。登録したスキルは版ごとに管理されていて、自分だけで使うことも、特定のメンバーや haro 全体に共有することもできます。ただし共有されたスキルは勝手には有効にならず、中身を確認した上で各自が有効にする形にしています。また、エージェントが共有範囲の変更や削除をしようとしたときは、ユーザーが承認してから反映されるようにしました。

登録済みスキルの一覧。code-review スキルの公開範囲・所有者・最終変更時刻と、「自分に有効」のトグルが並んでいる

有効にしたスキルはセッションを始めるときに Workspace へ同期されるので、チャットで $スキル名 と入力すれば補完から呼び出せます。

チャット入力欄に「$code」と入力すると、候補に「$code-review」が表示されている

GitHub での自動レビューと競合解消

PR を出したあと、レビューやコンフリクトの解消をお願いするためにわざわざ haro を開いてチャットするのは面倒ですよね。そこで、GitHub の PR から直接 haro を動かせるようにしました。

  • 自動レビュー: 設定で有効にしておくと、PR の作成や push のたびに haro がレビューして、総評と行コメントを PR に投稿します。指摘がないときは review を投稿しないので、push のたびに「指摘なし」が積み重なることもありません。
  • コマンド: PR のコメントに /haro review と書けばその場でレビューを、/haro conflicts と書けばマージ先の変更を取り込んで競合を解消し、そのまま push までしてくれます。

レビューは大きい PR だと見る範囲が広くなるので、親のエージェントが変更を整理して、ドメインや機能ごとに子のエージェントへ調査を任せ、結果をまとめて投稿する形にしています。進み具合は PR ごとに1件のコメントにまとまり、レビューや競合解消の途中経過は haro のセッションから確認できます。

2. 勝手にUI改善その他

AI Agent に作業をさせていると、AI の出力待ちという時間が生まれますよね。ついでにそこそこ大きい機能のレビューを投げるとレビュー待ちの時間も結構かかるわけです。その時間を有効活用すべく、haro を使っていて目についた改善点を勝手に改善する、ということをやっていました。 細かいUI修正を勝手に色々やって、劇的に、とまではいかないですが、多少 haro の見た目を良くすることができたと思います。

ツール実行履歴の比較。変更前はツール名だけの折りたたみ枠が縦に6つ続き、思考内容が12行並ぶ。変更後はアイコンと対象・操作が1行ずつ並び、思考内容は8行に収まる

ツール実行履歴を1行ずつ読める形にし、思考内容は8行でスクロールするように

ダークモードのポップオーバーの比較。変更前は背景と同じ色で境界が分かりにくく、変更後は明るい面と外周の線と影で浮いて見える

ダークモードでポップオーバーが背景に埋もれないように (左:変更前、右:変更後)

終盤になると大きめのUX改善も入れるようになりました。例えば haro にはエージェントという概念があり、エージェントごとに使える MCP 連携などが決まっているため、エージェント選択とプロンプトを一緒に送信した後に起動確認カードで MCP 連携などを選んで送信するという2段階のステップに分かれていました。

変更前の起動フロー:エージェントを指定して送信し、数秒待って表示される起動確認カードで設定してから「この内容で起動」を押すと作業が始まる

しかしこれは不必要に面倒なプロセスとなっており、起動確認カードが出るまでに数秒程度のラグがあるのもあり、起動確認カードが出ているのに気付かずに放置してしまい、数十分を無駄にするという現象もたびたび起きていました。 そこで、プロンプトを送信する際に一緒にエージェントも指定できるような導線に変えるようにしました。UI からでもチャットからでも設定できるというのが特徴です。これによって上述の問題が解決されるだけではなく、初見の利用者も使い慣れたユーザーも迷わずスムーズにエージェント選択からの起動ができるようになりました。

変更後の起動フロー:入力欄の上でエージェントと接続先環境を選んでから送信すると、そのまま作業が始まる

3. 勝手にCI高速化

haro の改善は haro の改善でもちろんやっているんですが、大量の PR を出して修正を繰り返していると、CI の待ち時間が気になってきますよね。たまたま AI のトークンが余っていたので調査させてみると、なんと普段使っているモノリポの checkout がありえん遅いことが判明しました。普段使っているリポジトリの checkout は普通数秒で終わると思いますが、大量のプロダクトなどを詰め込んだリポジトリでは shallow clone 相当 (fetch-depth=1) でも60~70秒程度、普通の clone 相当 (fetch-depth=0) では5~6分程度も checkout に費やしているということが分かりました。

CI ジョブの実行時間の内訳
26%checkout・履歴の取得 26%それ以外 74%

まず全ての履歴を使いたいことはそうそうないはずなので fetch-depth=0 の job を撲滅しました。その上で fetch-depth=1 の checkout でどこに時間を使っているか調べた結果、GitHub 側の圧縮操作が非常に重いことが分かりました。そこで定期的に main ブランチを clone した結果の git objects を self-hosted runner のイメージに焼いておくことで、GitHub から転送する objects の量を大幅に削減し、結果として10秒程度での checkout が実現されました。

checkout 1 回の内訳
  • fetch (GitHub からの取得)
  • ファイルの展開
  • 履歴の取得
導入前65.9秒導入後17.5秒

最終的には checkout と履歴の取得が CI 全体の実行時間に占める割合が約26%から約17%まで下がりました。CI の実行量の増加をならすと checkout に費やしていた時間の約35%を削減したことになり、これはself-hosted runner のコストに換算して1か月あたり約800ドルの削減になります。

また checkout 高速化とは別にフロントエンド周りのテスト高速化もやっていて、vitest の設定を調整したり、TypeScript 7 に移行したりして、テスト周りの CI job (build と unit テスト) の時間を約20%削減することができました。

build と unit テストの実行時間
変更前668秒Vitest 5555秒+ TypeScript 7521秒

働いてみた感想

Bet AI を謳っているだけあって、全社員が AI Agent をガンガン活用している様子が見て取れました。特に同じ haro を開発していた他のメンバーもかなり使いこなしていて、AI Agent によって圧倒的なアウトプットを出していました。 チームに入った当初は慣れていないのもあってそこまでアウトプットを出せておらず、他のメンバーの活動量に対して気後れしていたのですが、2週間ほどやっているとだんだん慣れてきて、自分から改善点を見つけて直すなど、アウトプットを出せるようになってきました。

働き方としては、リモートでも出社でもOKというスタイルだったので、自分も基本出社しつつ、大学や体調などに合わせて柔軟に働いていました。 またミーティングもそれほど多くなくて、自分の作業の時間を確保しやすかった印象でした。

終わりに

1ヶ月という短い期間でしたが、インターン期間中サポートしていただいたメンターさん、並びにチームのメンバー方、あと一緒にランチに行ってくださったみなさん、ありがとうございました。


おまけ: ランチ情報

初日、お弁当美味しい

9月1日のランチ

玉寿司、美味しい 席が広くて何人でも入れる(?)

9月2日のランチ

中村屋、美味しい 定食屋って感じ

9月3日のランチ

いな穂、美味しい スマホの使用が禁じられているお店

9月4日のランチ

じげ、美味しい 有り得ん量が多い

9月10日のランチ

玉寿司再び、やっぱり美味しい

9月14日のランチ

中村屋再び、ゴーヤが思ったより苦い

9月15日のランチ

サロンドジュリエ、美味しい デザートが美味しい

9月17日のランチ

& Ovo (アンドオーヴォ)、美味しい (なぜかサラダの写真しかないけど、ちゃんとメインも食べた)

9月18日のランチ

サロンドジュリエ再び、美味しい パスタめっちゃもちもちだった

10月2日のランチ

いしだや、めちゃ美味しい 激混みの人気店で、さすがの美味しさだった

10月9日のランチ