5.1さらうどん

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

Xcode上のAIエージェントのMCP/Skillsを簡単に設定できるmacOSアプリAgentHubを作った

  • Xcode上のAI Agent(Claude Code / Codex / Antigravity)のMCP、Skillsの設定をGUIで簡単に管理できるアプリを作った
  • Mac App Storeからダウンロードできるよ

    Download on the Mac App Store

XcodeのAI Agent設定しづらい問題

今年頭に出たXcode 26.4以来、Xcode上のAIエージェント統合がかなり強化された。Xcode上でClaude Code/Codexが高い互換性で動作するようになり、CLI版で利用できる機能の多くはXcode上でも実現できる。

一方で設定ファイルを弄るのが面倒だったり、CLIに慣れていない人は扱いづらい面もある。いつも設定ファイルのパスがわからなくなるし。

というわけで、Xcode上のAI Agentを簡単に設定できるmacOSアプリ、AgentHub for Xcodeを出した!

AgentHub for Xcode

以前、CCMissionControlを作ったときなども思ったが、GitHubでのバイナリ配布はいろいろと面倒だ。ビルドや公証のためのCI環境を作らないとダメだし、アップデートの通知の問題もある。

ユーザー的にも、昨今のセキュリティリスクからGitHub上の野良バイナリをインストールするのも抵抗感が強いし。というわけでMac App Storeにも出してみた。

AgentHub for Xcode

AgentHub for Xcode

  • gigi-net.net
  • 開発ツール
  • 無料

Xcodeという文言を含んでいるとApple製品と誤解を受けるとrejectされたが、他のツールを参考に「for Xcode」などと明示し、Reviewer Noteを丁寧に書いたら無事に審査を通すことができた。サンドボックス化されてるので利用者も安心。

MCPサーバーの設定

まずMCPサーバー設定の管理だ。stdio/HTTPのMCPサーバーを簡単に登録することができる。

Xcode上のエージェントでは/mcpコマンドがCLI版より扱いづらく*1、設定が適応されているかわかりづらい。設定ファイルを弄るのも面倒なので、AgentHubは役立つ。

個人的に使っているのは、以前開発したxcodeproj-mcp-serverだ。Xcode上から接続することで、組み込みのXcodeツールよりも細かくxcodeprojを操作できるようになる。

余談だが、最近apple/containerサポートを追加したので、以前より軽量に使いやすくなっている。この機会にぜひ。

Xcode上のClaudeがMCPをちゃんと認識している

Skillsのインポート

同様に、既存のSkillディレクトリをXcodeにインポートしたり、アプリ上で書いたりすることもできる。

XcodeのAI Agent上では、Claude Code / Codexプラグインの扱いが少し困るのだが、CLI版に入れたpluginへsymlinkすることもできる。これにより、pluginシステムのアップデートを簡単にXcode側に自動反映できる。

これまた同様に自作のapple-icon-composer-skill Pluginなどをimportしている。これでAIだけでそれっぽいアプリアイコンが作れて大変重宝する。

このアプリアイコン自体も全部スキルで作っている

どうぞご利用ください

AIコーディング時代になって、軽い労力で実現できることの射程範囲がかなり広がった。前までは土日潰してライブラリ1個作る程度の出力だったが、今は1日2日でアプリリリースまでできる感じ。

このほかにもXcodeとAI Agentの連携はいろいろ知見が溜まってきたので、どこか出力の場があればいずれまとめたい。

何か機能要望のアイディアがあればIssueやXでお気軽にどうぞ。

*1:27からマシになった

引っ越したのでUniFiで家庭用ネットワークを構築した

最近、6~7年住んだ家を離れて引っ越した。入居以来、マンション組み込みのインターネットが遅かったり、手持ちのルーターではWi-Fiを部屋中カバーできない問題が発生したので、解決のために試行錯誤した話。

新居のインターネットが遅い

新居は大規模住宅のため、インターネットがすでに管理費に含まれていて無料で使えるタイプ。前住居も同じデベロッパーのマンションで、回線契約も同じ座組。6年住んで全く困っていなかったのであまり心配せずに転居した。

転居後も日中は500Mbpsぐらいの速度が出ていて問題なさそうと安心していたが、住んでいるうちに夜間は回線が詰まって20Mbpsぐらいしか出ないケースもあることが判明した。

それに加えて、部屋が広くなったので、従来のルーターだけでは室内全域をカバーできず、場所と時間によっては体感レベルでネットが激遅だった。これはマズい。

新居の現状

管理会社に問い合わせたり、配付資料を見たりして調べていく中であとからわかったことだが、僕の家は以下のような構成になっていた。ちなみに築浅の分譲マンションなので、わりと設備は最新のハズ。

  • マンション全体としてUCOM光レジデンスに加入しており、共用部から各住戸に光分配されている
    • ただし1Gbpsしか来てない
  • ONUは分電盤に設置されていて、そこから家中のLANコンセントにスイッチングしている。ただしCat5e
  • NUROなど他の回線は来ていない
  • 回線を引く場合、共用部への工事は不可。すでに敷設されている光回線を使う光コラボのようなプロバイダ契約は可能

なるほど。

UCOM光回線が遅い問題:Connectixを契約する

まずは夜間に非常に遅くなる問題が出ていて致命的。本当は10Gbpsの回線を引きたいが、建物の構造や規約上、設置は無理そう。

幸い光回線は来ているのでプロバイダを変えるかといろいろ調べている中で、UCOMが提供するConnectixというサービスを発見した。

これは有料契約すると、集合住宅での回線を優先的に利用できるようになるオプションらしい。なんだそれは。

とりあえず契約してみたところ、上流は混雑する時間も含めコンスタントに700Mbps ~ 800Mbpsが出るようになり、一旦の解決を見た。

UniFiによるネットワーク構築

ここからが本題。以前まではルーターとしてNECのAtermシリーズを好んで使っていたが、住居が広くなり1台のAPではカバーが困難になった。

Atermは以前は良かったが、近年は6GHzへの対応状況が微妙だったり、メッシュ互換性の問題などがあり、オススメされたUniFiに統一してみることにした。

とりあえずゲートウェイとアクセスポイントの2台買えば大丈夫だろうとゲートウェイのExpress 7とAPのU7 Proを購入。これだけで8万円ぐらいした。

Dream Routerという更なる上位機種もあったが、一般のご家庭*1にはオーバースペックだと判断。

本当は壁掛けしたかったが壁に穴開けたくなかった

管理アプリが充実していてダッシュボードも細かく見れる

電源周りのハマりどころ

細かいところだが電源周りにハマりどころがあった。

まずExpress 7は、付属しているACアダプタが3ピンのものなので、一般的な家庭用コンセントに繋げるには2ピンへの変換が必要だった。

次にUniFiのAPには電源が付属していない。APはPoE(Power over Ethernet)という規格で給電するらしく、スイッチや配線がPoEに対応していない場合、別途PoE給電用のアダプターが必要になった。U7 Proの場合はPoE+という規格。

どちらも購入前にはわからなかったのでちょっと困った。買う方は要注意。まさか電源が付いてこないなんて考えもしなかった。

ゲートウェイとアクセスポイントでメッシュを構築する

まずは単に2台間でメッシュを構築してみることにする。

Express 7側で親メッシュを有効にし、U7側でメッシュ先を設定する。最初は完全に無線だとうまく認識しなかったが、ゲートウェイにAPを有線で直結し、メッシュの設定をしてから離したところ、うまく動作した。

この設定に至るまでちょっとハマった

ところが、実際に運用してみたところ、Express 7とU7間の物理的距離により、速度が大分減衰してしまうことがわかった。AP経由だと100Mbps台ぐらいしか出ない。一応これでも使えるが、家中で高速インターネットを浴びられないのに我慢できないので、もう少しなんとかしてみることにする。

メッシュは遅かったので分電盤を弄る

現状、部屋から生えているLANコンセントにゲートウェイやAPを差し込んでいた。この配線では、ゲートウェイ側からAPは上流にあることになり、ゲートウェイとAP間は有線接続ができないため、メッシュを組まざるを得なかった。 また、一部他の部屋から有線接続している機器にUniFi側から疎通できないという問題があった。

LANコンセントから雑に刺しただけだと、ゲートウェイから上流が見えない

すなわち、LANコンセントの根元にある部分にゲートウェイを刺せば、家中の有線を1つのUniFiネットワーク下に置けるのではないかと考えた。

理想的にはこう

というわけで、釘留めされていた住戸の情報分電盤を開けた。わりとしっかり封をされていたので、電動ドライバーやバキュームリフターなどの追加投資が必要だった。

開けるの大変だった

Express 7をONUに直結したことで、家庭内の配線を全てUniFiネットワーク化できた。

家中のクライアントが1つのネットワークに集約できた

APもLANコンセント経由で有線接続されるようになったので、メッシュにする必要がなくなり、6GHz対応ならば、家中どこでも700 ~ 800MbpsのWi-Fiに接続できるようになった。めでたしめでたし。

さらにこだわるなら、最初からついていたスイッチが1Gbpsなので、UniFiのものに取り替えるなどすると、家庭内LANがもう少し早くなりそうだが、結局現段階ではWANがこれ以上速くならないので諦めた。

最終的に爆速になったので一安心

綺麗なインターネットを浴びるのは大変

ネットワーク周りの知識が全然ないので試行錯誤をしたお話。意外とUniFiについての日本語の記事が乏しく、かなり調べまくってメッシュなどを組んだので、この記事も少しでも誰かの役に立てば良いなと思う。

Connectixについても、言及している記事が少しだけあって、それによって解決に至ったので、検索で辿り着く人の助けになれば幸い。

*1:すでに逸般の誤家庭かも

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:または徴兵