こんにちは、しーぴー (@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月の終わりごろには多くのエンジニアに使ってもらえている状況になりました。ありがとう。
ちょうど今日 izumin さんによる公式(?)ブログが出たので、haro が何たるかについてはそちらを見てもらうのが手っ取り速いかと思います。
そんな haro 開発に少しばかり貢献してきたわけですが、メインで作った機能のうち大きめのものを2つ紹介します。
カスタムスキル
よく使う作業の手順やレビューの観点を「スキル」として haro に登録して、チームで共有・再利用できるようにする機能です。
スキルの登録や更新は、チャットでエージェントに頼むだけでできます。登録したスキルは版ごとに管理されていて、自分だけで使うことも、特定のメンバーや haro 全体に共有することもできます。ただし共有されたスキルは勝手には有効にならず、中身を確認した上で各自が有効にする形にしています。また、エージェントが共有範囲の変更や削除をしようとしたときは、ユーザーが承認してから反映されるようにしました。

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

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 の見た目を良くすることができたと思います。
ツール実行履歴を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 に費やしているということが分かりました。
まず全ての履歴を使いたいことはそうそうないはずなので fetch-depth=0 の job を撲滅しました。その上で fetch-depth=1 の checkout でどこに時間を使っているか調べた結果、GitHub 側の圧縮操作が非常に重いことが分かりました。そこで定期的に main ブランチを clone した結果の git objects を self-hosted runner のイメージに焼いておくことで、GitHub から転送する objects の量を大幅に削減し、結果として10秒程度での checkout が実現されました。
- fetch (GitHub からの取得)
- ファイルの展開
- 履歴の取得
最終的には checkout と履歴の取得が CI 全体の実行時間に占める割合が約26%から約17%まで下がりました。CI の実行量の増加をならすと checkout に費やしていた時間の約35%を削減したことになり、これはself-hosted runner のコストに換算して1か月あたり約800ドルの削減になります。
また checkout 高速化とは別にフロントエンド周りのテスト高速化もやっていて、vitest の設定を調整したり、TypeScript 7 に移行したりして、テスト周りの CI job (build と unit テスト) の時間を約20%削減することができました。
働いてみた感想
Bet AI を謳っているだけあって、全社員が AI Agent をガンガン活用している様子が見て取れました。特に同じ haro を開発していた他のメンバーもかなり使いこなしていて、AI Agent によって圧倒的なアウトプットを出していました。 チームに入った当初は慣れていないのもあってそこまでアウトプットを出せておらず、他のメンバーの活動量に対して気後れしていたのですが、2週間ほどやっているとだんだん慣れてきて、自分から改善点を見つけて直すなど、アウトプットを出せるようになってきました。
働き方としては、リモートでも出社でもOKというスタイルだったので、自分も基本出社しつつ、大学や体調などに合わせて柔軟に働いていました。 またミーティングもそれほど多くなくて、自分の作業の時間を確保しやすかった印象でした。
終わりに
1ヶ月という短い期間でしたが、インターン期間中サポートしていただいたメンターさん、並びにチームのメンバー方、あと一緒にランチに行ってくださったみなさん、ありがとうございました。
おまけ: ランチ情報
初日、お弁当美味しい

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

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

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

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

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

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

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

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

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

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