2026年6月1日付で株式会社10Xに入社しました。
Stailerというネットスーパー・小売業のDXを支えるプラットフォームの開発をやっていきます。まずは1つのクライアントアプリから始まり、追々複数アプリを横断的に見ていったり、バックエンド含めた様々な領域に染み出していければと思います。
Flutterでのアプリ開発となり、Swiftを仕事で使う機会はなくなってしまいますが、今後もiOS・モバイル界隈の方々はどうぞよろしくお願いします🙏
ウィッシュリストはこちら↓
2026年5月末日をもってLINEヤフー株式会社を退職します。本日が最終勤務日となります。
ここから1年9ヶ月の在籍となりました。業務内容やチームメンバーには恵まれていたため、残念ではありますが、遠方居住勢として出社回帰に抗う形での退職となります。
在籍中は、昨年のiOSDC Japan 2025での登壇や、先日の会社のテックブログ記事でのアウトプット、またその裏側にあった多種多様な業務での成果を残すことができたのではないかと思います。LINEのiOSアプリという非常に巨大なプロダクトのビルドシステム・ビルド基盤や開発者体験の改善という仕事に携われたのは代えがたい経験でした。
iOSDC Japan 2025:
会社のテックブログ記事
WWDC25に部署のメンバー達と参加できたのもとてもいい経験・思い出ですね（7年振り3回目）。
4月後半から少しずつ有給休暇を消化し、細く長く引き継ぎをしてきたので、来る6月1日からはもう次の会社で働き始めます。転職先は入社日以降にまたお知らせするかと思います。
最後になりますが、在籍中に一緒に仕事をさせていただいた方々には大変お世話になりました。ありがとうございました！
そして、自分をLINEヤフー、LINEアプリのMDXチームに誘ってくれた 
id:gigi-net さん、本当にありがとうございました！！MDXチームでの日々はとても刺激的で楽しかったです。今後もまたどこかの勉強会やカンファレンスなどでよろしくお願いします👋
すっかりご無沙汰しております。久しぶりのブログ更新です。
会社のテックブログで、LINE iOSアプリへのMergeable Library導入についての記事を書きました。
LINE iOSアプリは数百ものモジュールから成る巨大なプロジェクトで、ほとんどのモジュールがStatic Frameworkとしてビルドされています。それゆえにXcode Previewsが不安定だったり、Debugビルドのリンク時間が伸びがちといった課題がありました。それを解消するためにXcode 15で導入されたMergeable Libraryの段階的な導入を進めています。記事では、その移行戦略や、実際にやってみて踏んだ落とし穴（App ExtensionでのLD_RUNPATH_SEARCH_PATHS問題、direct dependencyの宣言漏れ問題、Debug時のリソースバンドル問題）について書いています。
Xcode Previewsの方の話は昨年のiOSDC Japan 2025で発表しているので、そちらも合わせてどうぞ。
また、Mergeable Libraryの基本的な仕組みや効果については、同僚の id:gigi-net がiOSDC Japan 2024で発表されたスライドが分かりやすいので、興味のある方はぜひ。
テックブログの記事は、Claude Codeにかなりがっつり手伝ってもらって書きました（ついでに、今あなたが読んでいるこのブログ記事もClaude Codeに手伝ってもらって書いています）。
最初に、社内のPRやJIRAチケット、関連するSlackスレッドのリンクをClaude Codeに渡して、「Mergeable Library導入の経緯」を時系列で整理してもらうところから始めました。gh CLI、JIRA MCP、Slack MCPを順に叩いて関連情報を集めてもらい、それらを材料に下書きを生成、その後セクション単位で「ここの説明は不正確」「ここは社内固有なので一般化して」「ここは時系列がおかしい」と細かく指示してリライトしていく、という流れです。
途中で、参考にしたいテックブログ記事のURL（同僚の id:gigi-net や freddiさん、まつじさん が書いた記事）を渡して文体・構成・ボリューム感を参考にしてもらう、という使い方も試してみましたが、なかなか有用でした。同僚・チームメイトが書いた記事を参考にした上で文体を合わせると、「テックブログとして自然な体裁」に寄せやすい印象です。
途中段階では、Claude Codeにセルフレビューもしてもらいました。具体的には以下のような観点です。
これはかなり効果がありました。書いていると自分では気づきにくい繰り返し表現があったり、説明の前提がすっ飛んでいたりするので、第三者視点で見てもらえるのは便利。「ここに依存グラフの図があると分かりやすい」みたいな提案もしてくれて、それを元に図表を追加していきました。
加えて、別視点でのレビュー役としてCodex（執筆当時はGPT-5.3-Codex）にも見てもらいました。Claude Code内からCodexに繋いでレビューを依頼できるCodex pluginを使っています。Claudeとは違うモデルからレビューしてもらうと、Claude自身が見落としていた指摘が出てくることがあって、面白いところでした。
図表については最初Mermaidで書いてもらって、最終的に画像化するという流れにしました。AIに直接画像を作らせるのではなく、構造化されたDSLを介すと、後から微調整したり再生成したりしやすいので良かったです。
社内のレビューでもいくつかフィードバックをもらって、見出しの構成や階層を修正したり、説明の流れを調整したりしました。レビュー対応もClaude Codeに「このPRレビューコメントを読んで、対応方針を一緒に考えて」という形で進めて、各指摘について「これは反映する」「これは見送る」を相談しながらやりました。
記事を書く話とは別に、Mergeable Library導入のための各種ツールやSkillの作成にもAIをかなり使いました。これらの実装にあたっては、XcodeGenのProject Spec（project.yml）を全てパースして依存グラフを構築するという共通の基盤があり、その上で個別の検証や候補抽出を行う、という構成になっています。
LINE iOSには数百のモジュールがあり、Mergeable Library化は依存ツリーの末端（リーフ）から進める必要があります。「今、安全に移行できるモジュールはどれか？」を手で判断するのは現実的ではないので、依存グラフから現時点で移行可能な候補を一覧化するCLIツールをClaude Codeに作ってもらいました。
このツール自体はそんなに複雑ではないですが、LINE iOSアプリのXcodeGen設定の規約（テンプレートの使い方とか、Mergeable Library判定の条件とか）を踏まえてくれる必要があるので、CLAUDE.mdに書いてあるプロジェクト情報を読んだ上で実装してもらえるのは助かりました。
記事の方にも書いた通り、Mergeable Libraryのマージ対象になるためには、MERGED_BINARY_TYPE: manualを持つ全てのターゲットに対して、Mergeable Libraryをdirect dependencyとして明示的に宣言する必要があります。これがApp Extensionだとtransitive dependencyのまま放置されがちで、Releaseビルドで初めて気付いてクラッシュ、ということが何度かありました。
これをCIで検出するためのlintツールを作りました。manualターゲットのtransitive依存にMergeable Libraryが含まれているのに直接依存として宣言されていない場合にエラーを出す、というものです。
このツールも基本的な設計と実装はClaude Codeに任せました。リポジトリ内の他のlinterに倣う形で実装してもらい、テストケースも一通り書いてもらいました。
Claude CodeにはAgent Skillという機能があって、特定のタスクの手順をスキルとして登録しておけば、呼び出すだけでその手順に沿って作業を進めてくれます（条件によっては自動的に呼び出されることもあります）。
Mergeable Library化の作業は、対象モジュールが決まれば次のような流れでパターン化できます。
MergeableLibraryテンプレートを追加するこれをSkillとして定義しておきました。これで「XxxUtilityをMergeable Library化して」と頼むと、必要な変更を一通り行って、linterが通ることを確認した上でPRを作るところまでやってくれます。まだ移行を始めたばかりで実績はそんなに多くはないですが、定型的な作業がAIで自動化されたことで、今後の移行が進めやすくなりそうな手応えはあります。
ここ1年ほどの会社での業務を通じて、Claude CodeをはじめとするコーディングエージェントやAIエージェントを使う経験をかなり積むことができました。今回の移行作業も記事執筆もその延長線上にあって、業務で身につけた使い方をそのまま個人の発信にも活かせた感じがあります。
AIに任せきりにするとそれなりに間違ったことも書くし、技術的な正確性や社内固有情報の除去は気を使う必要があるんですが、こうやって「下書きはAIに書かせて、自分が編集者として手を入れる」スタイルで記事を書くのは結構楽しかったです。
今後も主体性を失わずに、AIを上手く取り入れながらやっていきたいですね👋
まだxcprettyを使っていませんか？今こそxcbeautifyに置き換えよう！ by ikesyo | プロポーザル | iOSDC Japan 2024 #iosdc - fortee.jp で想定していた内容の一部の供養です（落選）。
社内のとあるプロジェクトで、XCTestExpectationがタイムアウトしているケースでもテストが成功扱いになっていたり、XCTSkipを使ったテストケースがログに出力されていないということがあった。CIでのテスト実行にはfastlaneを使っていたので、fastlaneの実行ログからxcodebuildの出力のフォーマッターを確認してみると、xcprettyが使われていた。
fastlane 2.201.0から scan, gym, snapshot に xcodebuild_formatter というオプションが増えていて、そのデフォルトは xcbeautify になっているのだが、これはシステム（PATH？）にxcbeautifyが存在する時だけで、xcbeautifyが存在しない環境ではxcprettyにフォールバックするようになっている。
はてなではiOSアプリのCI/CD環境としてCircleCIを使用している（2024年6月現在）が、CircleCIのMacインスタンスではxcbeautifyはインストールされておらず、xcprettyにフォールバックしていたのだった。
そこでCIのステップとして brew install xcbeautify を先に実行してxcbeautifyをインストールするようにしたところ、XCTestExpectationのタイムアウトも、XCTSkipも正常に拾われるようになってめでたしめでたし。
xcbeautifyがREADMEで次のように謳っているとおり、
- [x] Supports the new build system's output.
- [x] Supports Xcode's parallel testing output.
- [x] Supports formatting Swift Package Manager output.
現代のXcodeやSwiftPM相手にはxcbeautifyを使っていくべきだということを実感した。
ちなみにGitHub ActionsのMacインスタンスについては macos-12 以降のイメージではxcbeautifyがプリインストールされているので安心していい。
その他のCIプロバイダー、例えばBitriseやCodemagicでのxcbeautifyのインストール状況を知っている方がいたらぜひ教えてください。
追記
