5.1さらうどん

@giginetの技術ブログ。ゲーム開発、iOS開発、その他いろいろ

LINEヤフー株式会社に在籍して4年が経った

旧LINEから数えてそろそろ働き始めて4年。少し早いが、私生活の変化で仕事に一区切りが付くので、敢えて在職エントリを書いてみることにした。退職エントリではありません。

LINE iOSアプリのビルドシステム刷新と開発者体験の改善をした

2022年7月、前職からモバイルの開発基盤を生業としていて、その流れでさらに大規模でおそらくiOSアプリとしては国内で最大規模のコードベースを持つLINEの開発チームにjoinした。

入社以来、LINEクライアントチームのデベロッパー・エクスペリエンスチーム*1というところで長くやっていくことになる。このチームはLINE iOS/Androidクライアント開発者の開発者体験を向上させることをミッションにしたチームだ。

2022年当時、LINE開発の最大の課題は、iOSアプリのビルドパイプラインの負債化と凶悪なビルド時間だ。継ぎ接ぎ的に導入されたBazelによってメンテナンスコストが増大しており、当時普及期だったApple Siliconへの移行もままならない状態だった。

ぶっちゃけ、今だから言えるがかなりひどい状態だった。追加された独自のBazel Ruleはテストもドキュメントもなくメンテが困難。統合方法も1度のビルドパイプラインで何度もBazel sandboxを起動する必要があるオーバーヘッドが多い設計になっていた。

メインメンテナだったメンバーの離職により、新しい体制のチームが発足したばかりで、これからどう改善していくかも決まっていない状況。そんな中、ちょうど足りないところにすっぽりと入り込めたので、今考えるととても良いタイミングだった。そんな中でBazelの脱却を進めつつ、新しいビルドシステムを構築することになる。誘ってくれた@freddiに感謝。

大きな発明だったのは、ビルドツール、Scipioの開発だ。これは外部依存をApple標準のSwiftPMベースの依存関係リゾルバを使いつつ、ビルド成果物をXCFramework化して再利用できるツールで、もちろん開発者間でのキャッシュの共有も可能。

この方針は当たり、そこそこ標準的なワークフローを導入しつつも、無駄なビルド時間を大幅に削減することができた。ビルドパイプライン全体の速度を数倍改善した上に、Apple Silicon上での開発体験も向上した。

その他、BazelやShell Scriptを中心として場当たり的に構築されたビルドパイプラインを整理して、ツール全体をSwift CLI化したり、標準的なiOSの開発ツールやプロセスを導入していくことができた。

ビルドシステムを中心としたiOS開発者の体験向上の施策はその後も続き、僕だけではなくイカれたメンバー優秀な仲間と一緒にいろいろな施策を試していけるようになった。 ツール群をSwiftで開発するようになったことで、CI上で高度な静的解析や処理の最適化が行えるようになったし、毎年WWDCで発表されるAppleの新機能を即座に試していけるようになった。最終的にはXcode Previewsの普及や、Mergeable Library、Compilation Cacheといった新しいXcode機能の導入なども進んだ。

最近辞めたチームメイトのid:ikesyoの記事も参照のこと。

モバイル領域の外部発信文化を作れた

入社後の思い出と言えば、Developer Relation的な活動に爪痕を残せたことだ。当時のLINEのクライアント組織は、社内の知見交流のコミュニティはいくつかあれど、対外発表には消極的で、あまりカンファレンスへの登壇者を出せていなかった。

入社直後から、何か声がデカい奴が入ってきたぞと認識されていたようで、高名だったShocoさんや941さんにいきなり全社放送に駆り出され、発信を広めてくれと言われたのは光栄だった。

クライアントチーム内でも発信の熱が上がり、iOSDC 2023では20名近くがCfPを出し、多くの採択に至った。以後、合併後もモバイル領域では発信する文化が根付いたと思う。 この辺りは体感として、自分が活動したことで組織全体として外部発信の機運を作れたと自負している。

そんなこともありつつ、わりと早い段階で当時のLINEにおけるスタッフエンジニア相当になった*2

自分の仕事をアピールするためにメトリクスを設計した

2023年末、周知の通りLINEとYahooの2社が悪魔合体し、クソデカ組織が誕生する。とはいえ、僕が所属する部門はしばらくは合併の影響をあまり受けずに、組織図もネストが深くなっただけでほぼそのまま。

合併後から、裁量労働制の廃止や、賞与制度の変更、そして出社義務化の発表など、細かな福利厚生の廃止・ナーフが建て続けに行われた。現状維持バイアスもあり、当時は反発も必至だったが、3年近く経つとこんなこともあったなあという感想になってきた。これが慣れ。

この時期は、前述の開発基盤の改善は続けつつ、自分の仕事をどうやって評価してもらおうかということを考えていた。開発者体験の改善という業務は成果が見えづらい。ビルドのパフォーマンスチューニングは楽しく、やりがいがあるが、長年続けていくとボリュームゾーンの改善は終わってしまい、効果がサチり気味になる。 負債を掃除していますというだけでは支持を得られづらいし、「コード補完が早くなりました」、「デバッガが快適に使えるようになりました」といった種の改善は成果が説明しづらい。自分たちの仕事を客観的に評価する指標が必要だった。

そんな中、偶然にも、当時のチームメイトの@mntshさんにエンジニアチームの生産性評価について書籍を執筆しないか、というオファーをいただき、それがきっかけで開発者生産性について考えることになった。

結果として、書籍で触れたSPACEという生産性評価フレームワークを使って、LINEクライアント開発者全体の開発生産性を定義したり、自分たちのチームでもビルドメトリクス基盤を整備し、自分たちの仕事の成果をアピールしやすくした。

正直、この辺の話はふわっとしすぎていて、意味のある指標になっているのか未だによくわかっていない。仕事として発信する機も逸してしまった感があるのでここで供養しておく。

そして、AIをやっていく人に

2025年に入ってからは、AIの普及によって開発のパラダイムが破壊的に変わった。いきなりAI驚き屋になったわけではなく、開発者生産性を語る上でAIは無視することはできないものとなり、自然とやりたいことの比重もAI弄りが中心になっていた。

2025年中盤頃まで、会社全体のVibe Coding技術の導入が遅く、大企業あるあるの様々なコンプライアンスに阻まれて導入が進められない状況が進んだ*3。 ようやっと社内でまともに使えるようになったのは2025年の後半。会社の制度設計も進み、今では外部の環境と遜色ないレベルでコーディングエージェントが利用できている。

この頃は新しいツールに熱狂し、Vibe Codingを布教したり、LINEクライアント開発へのAI導入を次々と進めていた。例えば今でいうハーネスエンジニアリング的な概念を取り入れたり。

その他、記事としては出せていないが、前述の生産性分析をAIを使って行うようになったり、CIエラーやビルドログの解析などもAI化できた。

AIの破壊的イノベーションに脳を焼かれ、AI、AIと言い続けていたら、AI人材だと認識されたようで、今年の4月頃からLINEクライアント開発のAI基盤を担当するチームに異動になった。いわゆるハーネスエンジニアリングチームだ。

ビルド基盤の業務からは遠くなったが、開発者生産性を考えていくという軸は大きく変わらず、そこまでやることに変化はない。今はちょうど新しいことを試しているまっただ中だ。

リモートで動くコーディングエージェント基盤、要は簡易なDevin的なものを一から構築しようと試みたり、従来のコードレビューのあり方をAI前提に再考してみたり。直近の取り組みはいつかアウトプットできる機会があれば・・・・・・。

ビッグテックサバイバルガイド

最近は超巨大なエンジニア組織の中でどうやって成果を出してエンジニアグレードを上げていくか、ということを強く考えている。

現状、特段マネジメント職ではない平エンジニアの中ではかなり自由にやらせてもらっていて、恵まれた状況だと思っている。ありがたいことです*4

その一方で、このままやり続けても評価が頭打ちになるなという危機感を感じ始めている。合併によりクソデカカンパニーが誕生したことで、まさにカオスな独特の力学が発生しており、うまく環境を見極めて動かないと、なかなかこれ以上を望むのは難しい。

こんな感じで大きい会社で強い動きを探して、エンジニアグレードのレベリングをしていくというメタゲームにだんだんとやりがいを見いだしてしまった。

というわけで、ここ最近は旧LINE組織からの越境を意識して動いている。これまでの外部発信は継続しつつ、社内でも全社の全エンジニア向けのワークショップの講師をしたり、All Handsに顔を出したり・・・・・・。

良く見るとIRのスクリーンショットに映り込んでいる 👋

出世競争をしているわけではないけど、ポイントを掴んで、組織内で目立っていくのはなかなかと面白い。例えば先日は経営陣肝いりの新しいAIサービスなどが発表されたし、このようなホットな領域に噛んでいけると成果が出しやすい予感はしている。

出社義務化に思うこと

LINEヤフーというと、何かと出社義務化の話題がセンシティブで槍玉に上がりやすい。せっかく渦中にいるので、その辺のことについても触れたい。

個人的には、意外と物理出社には肯定派。COVID前は何の疑問も持たずに週5出社を継続していたので、そこまで強くオフィス回帰への抵抗はないし、オフィスでわいわいできる日々を結構楽しんでいる。

この話題は、物理出社の意義や、突然の不利益変更など様々なトピックが挙がるが、当事者として一番大きな影響は、出社派とリモート派の分断が広がったことに思う。

極端な話、出社義務化など、あまり実効性がないと思っているので適当に運用しておけばいいじゃん、ぐらいに軽く考えているが、無視すればいいとそう単純な話でもない。 仮にリモートワークが許されたとしても、ほかの同僚のオフィス回帰が進む中、その中で自分だけリモートで働き続けるのは難しい。 そんな状況で、出社中心の働き方に合わない人が去っていってしまうのは残念だが仕方ないことだなと思う。

前職では、経営陣がいきなりクーデターで転覆したり横浜への移転を強行したりというイベントを目の当たりにしているので、エグゼクティブが何かやりだすのは、まあどこもこんなもんだろうと思っていて、経営陣のムーブについても特にあまり強い感情がない。経営と合わなかったら、状況を変えるよりただ黙って去る方が楽だとは思う。

今のところは週3出社による影響はそんなに出ていないけど、今後のライフステージの変化でスタンスが変わる可能性もある。まあその時は転職を考えるときという事で・・・・・・。

やっていくぞ!

というわけでネガティブな話題が多い昨今ではありますが、楽しく元気にやっていますということを今のうちに書いておくことにした。そしてまだやりたいことやモチベーションもあるので、まだしばらくは在籍している気がしている。

さて、今回筆を執ることにしたのは、この度しばしの育休*5というものに入ることになったため。変化の激しい昨今、特にAI基盤の整備でやることが盛りだくさんの中、仕事ができなくなるのは正直手痛いと感じているけど、長い人生でちょっとぐらいは仕事から離れる機会も良いかなとも思って休むことにしてみた。AIにギュラれて復帰後に席がなくなってないと良いけど・・・・・・。

*1:何度か名前は変わったが

*2:現在のLINEヤフーではこの呼称は廃止されている

*3:分報では「刑務所じゃん」とかよく愚痴っていた

*4:こいつにEMさせない方が良いと思われている説はあるけど

*5:または徴兵

ポケモン構築管理アプリ『PokeBox』を『Pokémon Champions』サポートした - AI時代のポケモン開発

PokeBoxのPokémon Championsサポート!

Pokémon Champions』ついに出ましたね!!!

僕は、剣盾末期の2022年に『PokeBox』というポケモンの構築管理をするiOSアプリをリリースして未だに細々とメンテしている。

この機会に大幅リニューアルした

PokeBox - 構築管理チャンピオンズ

PokeBox - 構築管理チャンピオンズ

  • gigi-net.net
  • ユーティリティ
  • 無料

新作が出る度にデータは更新しているし、最近ではSwift Dataに移行したり、Liquid Glassに対応したりと、最新のOS機能を試すためのPlaygroundとしてうまく機能している。

直近では『LEGENDS Z-A』と『M次元ラッシュ』の新規追加メガシンカ対応をした。

今回、『Champions』のリリースに当たって、SVのDLC以来の大きな改修となったので、開発手法について共有してみる。

PokeAPIからの脱却!データベースを独自実装にした

『LEGENDS Z-A』と『M次元ラッシュ』対応のデータ更新辺りから、今までデータソースに使っていたPokeAPIを直接使うのをやめ、フォークした独自のデータベース構造に移行した。

PokeAPIにはポケモンにまつわる様々なデータがCSV形式で格納されているので、それをSQLiteに焼いて、アプリから叩く仕組みだ。

ポケモンの様々なツールが世の中に出て欲しく、皆が使えるように当初は貢献のつもりでオープンソースのPokeAPIデータソースに必要なデータを追加するPRを送りまくっていた(30件以上も!)。

SV以降の種族やわざ、とくせい、アイテム、日本語ローカライズなどは大体僕が追加していた

能力値の変更など、チマチマ人力でやっていた

SV DLCの『碧の仮面』『蒼の円盤』辺りまではこの開発体制だったが、次第にオーバーヘッドがデカくなってきて、OSSに貢献するのが大変になってきた。

  • 『PokeBox』に不要なデータの設定まで求められる。例えば対戦に使えないアイテムのデータや日本語、英語以外のローカライズなど
  • 一存で新規テーブルやデータ構造の追加ができない
  • メンテナの文化圏が異なり、レビュー体制やPRへのサポートがやりづらかった

このような不自由さがあり、この機会にオープンデータから袂を分かつことにした。

AI時代のデータベース構築

SVのDLC(2023年末)まではExcelを使い、データを半手動で手打ちしていた。当時もAIによる自動パースのようなことは検討したが、当時の技術水準では困難だった。

しかし時は流れ世はAI時代。データベース構築をほぼClaude Codeのみで行えるようになった。隔世の感!

というわけで、Claude CodeのRulesやSkillを作成して、Pokémon WikiBulbapedia, Serebii.netなどの英語圏の攻略サイトから情報収集ができるように構築した。

データベースとポケモンのドメイン知識を記したRuleの一例

不思議なことにAIはポケモンの基本的な情報をコンテキストとして与えなくても、モデルの時点で3値の仕様ぐらいは完璧に把握していた。

そのため、これぐらいの簡易的な仕組みで自律的にRDBのようなデータ構造を理解し、データ収集と更新をほぼ完璧に行ってくれた。特に覚えるわざのテーブルの作成などは人力では困難だったが、AIにより待つだけで完了して革命的だった。

例えばわざの仕様変更を一括で反映してもらった例

ランクマッチのデータを持たせて「環境」を表現

PokeAPIのデータを使っていたことで一番困っていたのは、いわゆる「ランクマッチ環境」についてのデータを持てなかったこと。現在開催中のレギュレーションのプールを表現したりするデータ構造がなかったので、今回から『Champions』以降のレギュレーションの概念をデータ構造として持たせることにした。

種族とレギュレーションの中間テーブルで、それぞれのレギュレーションにどのポケモンが参加可能か持てるようになったので「環境」を表現することができるようになった。

このデータ作成は、公式が提供している「参加できるポケモン」のページをClaude Codeに渡しただけで生成できた。

種族選択は現在開催中のレギュレーションが優先されるようになった

環境のデータができたことで、ポケモンの選択画面を現在ランクマッチに参加できるもののみに絞れるようになったし、環境内のすばやさ比較ツールのようなものも実現できた。

環境中のすばやさラインを見ながらパラメーターが触れるようになった。欲しかった機能

パラメーターの仕様も『Champions』に完全移行

事前の情報にもあったとおり、『Champions』以降、三値やPP、わざの習得などの仕様が大きく変わった。

『PokeBox』は剣盾時代から運用しているアプリなので、その辺の仕様はメインシリーズに準拠しているのだけど、今回『Champions』専用の仕様に完全に移行した。

『ポケモンチャンピオンズ』は“シリーズが続く限りほぼ永久に続く予定"」とのことで、第10世代以降も末永くガチ対戦はこの仕様が続くと考えられる。というわけで過去作の仕様は思い切って捨てることにした。

今まで保存されていたデータと互換性を保つために、内部的には0-255の値を持つ努力値(EVs)を維持し、UI上のみ0-32までの表示とすることにした。

チャンピオンズ仕様の努力値配分になって調整しやすい!

また、SV以前に作ったポケモンは世代の概念を取り入れそのままアーカイブできるようにした。個体値(IVs)なども内部的には保存されているが、UIから消し、31で固定されるようにした。

アプリ自体の開発ももちろんAI

ここまでデータと仕様ができればあとは開発するだけだ。

アプリ開発自体もほぼAIで自動化した。個人開発だとガッとAIで実装して、動作確認もそこそこにすぐにリリースできて体験が良い。最初に「大規模アップデート」と触れたが、賞味半日ぐらいで全てが完成した。

以前からロードマップに入っていた構築メモの出力機能や、フォルムチェンジプレビュー機能、すばやさ調整ツールのような新機能も数十分程度で完成している。生産性が数百倍になっている・・・・・・。

前述のすばやさ比較ツールはこの程度のプロンプトでできた

Pokémon Champions最高!!!

個人的にゲーム本編もアプリ開発もまだハマっているので、今後自分がゲームで遊びながら欲しいツールをどんどん追加していくつもり。

現状、ゲーム本編での個体作成が気楽すぎて、アプリにメモるよりも直接ゲーム内で作成してしまった方が早いという現象が起きているので、ゲーム画面の写真から自動入力するような機能も検討したいと考えている。特にスマフォ版が出たらスクリーンショットの入力は捗りそう。そのうち作りたいのでお待ちください。

PokeBox - 構築管理チャンピオンズ

PokeBox - 構築管理チャンピオンズ

  • gigi-net.net
  • ユーティリティ
  • 無料

WezTerm上のClaude Codeの稼働状態を監視するmacOSアプリ、CCMissionControlを作った

CCMissionControl

稼働中のClaude Codeセッションが一覧表示!

Claude Codeを複数起動しているとき、ほかのセッションの稼働状況を知りたい需要は高く、様々な方法が提案されてきた。Notification Hookを使ってサウンドを鳴らしたりTerminalのVisual Bellをフックしたり。最近はcmuxなんていうソリューションも出てきた。

どうにもユースケースに微妙に合わないので、WezTermで使える自分用のmacOSアプリ、CCMissionControlを作った。

Mission Controlとは、スペースシャトルの管制室のこと。往年のMacユーザーであれば、古のMission ControlというOS機能を思い出す(実際それは意識した)。

機能としてはこんな感じ。

  • 実行中、待機中のClaude Codeセッションを一覧表示
  • 未読管理。セッションが終わったときに未読表示。WezTerm上でタブを選択すると既読に
  • バックグラウンドのセッションが終わったらmacOSのネイティブ通知
  • メニューバーにも出せるし、フロートウィンドウにもできる
  • GUIからWezTermのタブやペインを切り替えられる
  • システム起動時の自動機能

個人的に嬉しいのは、終了時や認証確認時にmacOSのネイティブ通知も飛ばしてくれること。さらにこの通知はWezTerm上のセッションがバックグラウンド(別のタブで表示されているなど)のときしか飛んでこない。通知をタップしたらそのままWezTermのペインを移動してくれる。最高便利。

クリックすると即座に作業に戻れる

WezTerm専用GUIアプリ!

このアプリはWezTerm専用となっている。これはWeztermが強力なwezterm CLIを提供していて、これ経由でタブやペインの選択状態を取得・操作しているため。

これにより、WezTerm側で、どのClaude Codeセッションを持つttyがアクティブになっているかを外部から監視、操作することができている。

例えば wezterm cli list --format json などを実行すると、現在開かれているペインの情報が返ってくる。

{
    {
        "window_id": 0,
            "tab_id": 14,
            "pane_id": 28,
            "workspace": "default",
            "size": {
                "rows": 63,
                "cols": 79,
                "pixel_width": 1501,
                "pixel_height": 2394,
                "dpi": 144
            },
            "title": "zsh",
            "cwd": "file:///Users/giginet/.ghq/github.com/giginet/blog-articles",
            "cursor_x": 0,
            "cursor_y": 1,
            "cursor_shape": "Default",
            "cursor_visibility": "Visible",
            "left_col": 80,
            "top_row": 0,
            "tab_title": "",
            "window_title": "< (~/.ghq/github.com/giginet/blog-articles/entry/2026/04/10) - Nvim",
            "is_active": true,
            "is_zoomed": false,
            "tty_name": "/dev/ttys011"
    }
}

macOSアプリ側から、このCLIの実行結果を定期的にpollingして情報を更新している。またペインのアクティブ状況も見れたり、wezterm cli activate-paneでペインの選択状態も変更できるため、既読管理をしたり、GUI側からWezTermに反映したりと、双方向のインタラクションを実現している。

Claude Codeプロセスの取得

ttyから紐付いているClaude Codeのセッションと動作状況を取得

基本的なアイディアはこの記事に大変お世話になった。大変ありがとうございました。

この記事で解説されているとおり、psコマンドでclaude PIDを探し、それを実行しているtmuxのペインと紐付けている。

Claude Codeが動作中かどうかの判定

これも記事で解説されているが、Claude Codeは動作中のスリープを抑止するために、子プロセスとしてcaffeinateを発行するらしい。これを監視することで、動作中かどうかを検出している。

記事で紹介されているGoのコードをコンテキストとして与え、Swift移植を頼んだところすぐにできた。

どうぞご利用ください!

macOS + WezTermユーザー専用だけど、使っている人には便利だと思う。

リリースページに公証済みのバイナリも配布しているので、ぜひ使ってもらえると幸い。