自己紹介 こんにちは riataso です。 iOSエンジニアとして、TUNAG のアプリ対応を担当しています。 iOSDC への参加は今回で2回目です。最近は知り合いが次々と iOS から別のポジションへ移っていくことが多く、少し寂しさを感じていました。そんな中で、会場に iOS エンジニアがこれだけ集まっている景色を見ると、やっぱりいいなと思います。 はじめに 9月11日〜13日に有明で開催された iOSDC Japan 2026（ 公式タイムテーブル ）に、現地参加してきました。 今年はAI活用に関するトークが目立ちました。その中で多くの人が悩んでいるのは、 どこまで任せて、どこに人が線を引くか だと感じました。 このレポートでは、特に印象に残った2つのセッションを軸に、iOSエンジニアとしての向き合い方を整理します。 セッション① AI時代におけるiOS設計の守り方と人間の役割（遠藤拓弥さん） 9月12日に Track B で行われた、株式会社TVerの遠藤拓弥さんのスポンサーセッション（20分）です。AIで開発が速くなった結果、設計をどう守るのか、人は何を決めるのか、という話でした。（ fortee / スライド ） 概要 AIの活用で、TVerのマージ済みPR数は 1,619件から5,435件（約3.4倍） になったそうです。一方で、AIが速く書くほど設計は崩れやすくなります。問題はAIそのものではなく、AIにとって崩しやすい設計になっていることだとして、設計を作り替え、人が決めたことを仕組みに落とし込んできた、という内容でした。 人が整えている土台 アーキテクチャガイドラインの整備 機能単位でのパッケージ分割（AIが扱いやすく、壊れにくい境界を作る。Packageモジュールは約1年で22から204に） 依存方向をlintで制限し、CIで確認する 仕様書とテストの拡充 CLAUDE.mdやFigmaへの記録 AIには任せきれない判断 バグと仕様の見分け : 既存コードにある誤り（誤ったエラーコードの説明コメントなど）を正しいものとして読み、そのまま複製・拡散してしまう。 SwiftUIかUIKitかの選択 : UIKitを使っている34箇所には、SDKやOS標準がUIKit前提、SwiftUIに機能がない、特定のOSバージョンでSwiftUIが動かない、といったそれぞれの理由があり、その判断はAIには難しい。 感想 一番参考になったのは、「判断は人がする」で終わらせず、決めた内容をモジュール境界やlint、ルールファイルといった仕組みに落とし込んでいる点でした。レビューのたびに人が止めるのではなく、逆流する依存はlintとCIで検出するというように、人の判断を後から機械的に守れる形にしています。 AIが誤ったエラーコードの説明コメントをそのまま複製し、8ファイルを直す羽目になったという失敗例も印象的でした。AIの出力を確認せずに使わない、理由を説明できないコードは入れない、という当たり前のことを、個人の注意力ではなく仕組みで担保する必要があると感じます。 また、決めることの大変さはAIが速くなっても変わらない、というまとめにも納得しました。実装が速くなるほど、構造や仕様といった後から変えにくいものを先に固める価値は上がると思います。SwiftUIとUIKitの使い分けのような、SDKやOSの制約を踏まえた判断を人が持つ、という整理も、iOSエンジニアとして腹落ちしました。 セッション② スマホアプリ開発におけるハーネスエンジニアリングの取り組み（原隆幸さん） 9月12日に Track B で行われた、食べログを運営するカカクコムの原隆幸さんのスポンサーセッション（20分）です。食べログのアプリ開発チームが、AIを使った開発をどう整えているかが紹介されました。（ fortee ） 概要 食べログのアプリ開発チームは、「アプリ開発を誰でもできるようにする」というミッションのもと、スキルアップ、開発環境、変更容易性、コンテキスト、AI駆動プロセス、テストなど7つの領域に整理して改善を進めているそうです。 その中心にあるのが、ハーネスエンジニアリングです。AIに「何を伝えるか」を整える コンテキスト と、AIの出力を「どう検証し、どう矯正するか」を設計する ハーネス（ガードレール） を両輪として、あわせて「ハーネスエンジニアリング」と捉えている、という内容でした。 ポイント コンテキストは量より質 : 情報を詰め込むのではなく、単一の信頼できる情報源を保つ。 検証の自動化 : MaestroでUIテストを自動実行して、手動QAの負担を減らす。（発表後に公開された 公式ブログ では、テスト項目そのものをAIに作らせる取り組みも紹介されています） 継続的な改善 : CLAUDE.mdを育て続け、フィードバックループを作る。 感想 ハーネスエンジニアリングという考え方自体は以前から意識していましたが、実際にどんな単位で取り組んでいるのかを聞けたのが今回の収穫でした。AI活用をプロンプトの工夫に閉じず、スキルアップやテストも含めた開発環境全体の話として扱っている点が印象的でした。 中でも、AIに渡す情報（コンテキスト）と、出力を検証する仕組み（テスト・自動化）を両輪にしているところが参考になりました。足すのは簡単でも、減らして手入れするのは難しいので、CLAUDE.mdのような指示ファイルも、コードと同じように継続して育てる対象として扱う必要があると感じました。 2つのセッションから考える：「任せる範囲」と「人が引くガードレール」 2つのセッションは、同じことを別の角度から語っていると感じました。 層 人が担うこと 該当セッション 設計 アーキテクチャ、仕様、モジュール境界の決定 ① 情報 AIに渡すコンテキストの品質管理 ② 検証 テストの整備、最終的な動作確認 ①② 守る場所は、①が「構造（モジュールとlint）」、②が「情報（コンテキスト）と検証（テスト・自動化）」と、会社ごとに違っていました。それでも、AIに任せる前提で人が仕組みを整える、という方向は同じだと感じました。 実装そのものはAIに任せる流れが進む一方で、「 何を作るか、何が正しいか、どこで止めるか 」を決めるのは人に残る、というのが2つのセッションから受け取ったことです。 自分たちの現状 自分たちの TUNAG の iOS アプリでは、VIPER と Swift Package Manager によるマルチモジュール構成をとっています。AI向けには、CLAUDE.md にプロジェクトの概要や構成、ブランチ戦略をまとめ、コードスタイル・セキュリティ・テストのルール、PR作成やVIPERの機能追加といった定型作業のスキルやコマンドを用意しています。SwiftLint はビルド時に自動で動きます。レビュー用のガイドラインファイルも置いていますが、中身はコメントを日本語で書くといった最低限のものです。 今回の2社と比べると、次の違いがありました。 構造の守り方 : TVerさんは依存方向をlintで制限し、CIで確認しています。自分たちはVIPERの規約とスキルで案内する形が中心で、機械的に止める仕組みは多くありません。 仕様の持ち方 : TVerさんはMarkdownの仕様書を大きく増やし、機械可読な形にしていました。自分たちは、仕様をAIに渡す形としてまだ整理しきれていません。 検証 : UIの動作確認は人の目に頼る部分が大きく、食べログさんのような自動化は今後の検討課題です。 レビューでは、AIによるレビューと人によるレビューの両方が入る運用です。ただ、AIのレビューだけでは抜け漏れが出ることがあり、人が見て初めて気づく点も残っています。AIが生成したコードは見た目が整っているぶん、確認する側が「たぶん大丈夫」と流してしまう怖さもあります。何をAIに見てもらい、何を人が見るのかは、まだ整理しきれていません。 現地参加ならではの体験 今年も多くのエンジニアが会場に集まっていました。名刺交換アプリがあったおかげで、初めて話す方とも気軽に声をかけ合うことができ、前回よりも多くのエンジニアの方々とお話しできました。 ブースでは、pixivさんの企画アプリが印象に残っています。去年は、SwiftUIのModifierを題材にしたクイズ形式のアプリ「SwiftUIと秘密の修飾子」で、問題を解きながらクリアしていくものでした。今年は「ぴくしーる」という、自分のアイコンからデジタルシールを作り、シール帳のように集めて交換できるアプリでした。端末同士を近づけるNameDropを使って交換する仕組みで、それをきっかけに他の参加者の方と自然に交流できました。 2回目の参加ということもあり、去年よりも iOS について深く理解した状態で臨めました。その分、セッションやブースで得られる学びが増え、考えさせられることも多かったです。 今後見直していきたいこと すぐに何かを変えるというより、 自分たちの開発の進め方を一度立ち止まって点検したい と感じました。特に見直していきたい観点は次のとおりです。 レビューで見る観点 : AIレビューで抜け漏れが出ることがある以上、AIが生成したコードのどこを人が重点的に見るのかを、チームで揃えていきたいです。「既存コードのバグを仕様として実装する」という指摘を踏まえ、仕様の意図に関わる部分は人が確認する、といった整理から始めたいと思います。 AIに任せる範囲の線引き : 実装はAIに任せつつ、「仕様の判断」や「最終的な動作確認」は人が持つ、という整理は、2つのセッションに共通していました。自分たちの現場で、どこまでをAIに任せ、どこからを人が判断しているのかが明文化されているかを見直したいです。 AIに渡すコンテキストの整理 : 食べログさんの事例にあった「量より質」「単一の信頼できる情報源」を踏まえ、CLAUDE.mdなどの指示情報が増えすぎていないか、古い情報や重複がないかを調整していきたいです。 設計の守り方 : TVerさんの事例にあった、アーキテクチャガイドラインや機能単位のパッケージ分割は、AIが速く書くほど効いてくると感じました。ただし、チームの規模やテスト方針に見合わない過剰な整備は逆効果になりかねません。 自分たちの規模に合った粒度 を探りたいです。 おわりに AIで実装が速くなっても、「何を作るか、何が正しいか、どこで止めるか」を決める仕事は人に残ります。今回得た視点をチームで共有しながら、少しずつ自分たちに合った形に調整していきたいです。 スタメンではエンジニアを絶賛募集中です🙌 気になる方はこちらからアクセスをお願いします！ herp.careers

はじめに JADOGは、データセンター事業者をはじめ、ユーザー、メーカー、SIer、ネットワーク事業者など、多様な業界のプレーヤーが業界の枠を超えて集まり、建設的な情報共有と活発な議論を行うコミュニティーです。これにより […]

はじめに 企業の業務改革やシステム刷新についてお客様と会話していると、次のようなテーマで MDM（Master Data Management：マスタデータ管理） の導入が検討されるケースが多いように感じます。 取引先管理業務の改革 顧客管理業務の改革 社員管理業務の改革 製品管理業務の改革 商品管理業務の改革 原材料管理業務の改革 いずれも「取引先」「顧客」「社員」「製品」「商品」「原材料」といった、企業にとって重要なデータを扱う業務です。 そのため、 顧客管理を高度化したいので、顧客MDMを導入する あるいは、 商品管理業務を統合したいので、商品MDMを構築する とい