月: 2026年2月

聴講メモ：五反田.mobile Vol.2 – モバイルアプリデザイン最前線

前回初開催だった、五反田.mobile の第二回はデザインがテーマ。間違って前回の開催場所だったウェルスナビさんに行ってしまい、1セッション目は間に合わなかった。

AIコーディング時代におけるデザインとの連携をどう滑らかにするか？を考えてはいるものの、エンジニアサイドは自発的に様々な工夫をする一方で、デザイン側との接点については手探り感があった。今回そのヒントがいくつか得られて良かった。

パネルディスカッションは、プレゼンター以外の社員さんの参加もあってエピソードが豊富だったし、またプレゼンテーションという粒度外の話もてんこもりで（そういえば、みたいな思い出しもあり）素敵な試みだった。

イベントページ：https://gotanda-mobile.connpass.com/event/382518/

Figmaを使ったAI駆動モバイルアプリ開発

@naoele_dev さん

Figmaを使ったAI駆動モバイルアプリ開発 – コード生成しやすいデザイン設計の実例 – by @naoele
  • よくある失敗例
    • レイアウト設計（Auto Layout, Constraints）
    • コンポーネント設計（Components, Variant）
    • トークン設計（Color, Theme）
  • 失敗原因：Figma の設計が曖昧だから
    • Frame 名が初期値のまま→意味のある命名がされている
    • 手動配置されている、色が直接指定されている；Auto Layout や Variants を使っている
    • コンポーネントを使ってない
  • レイアウト設計の悪い例、良い例
    • 重要なのは、レイヤー構造がコード構造になる（Auto Layout, Constraints）
    • 意味のある名前をつける
      • → Figma のデザインデータそのままで生成される（クラス名や変数名にも反映される）
    • Auto Layout = Stack, Column
    • Figma の Constraints: サイズが変わった時に、中のTalkで部品がどの様に振る舞えウカを決める（寄せ方）
  • コンポーネント設計の悪い異例、良い例
    • 状態ごとに別コンポーネントになっているのは悪い例
    • 一つのコンポーネントに Variants が指定されていて、状態管理されている
    • UI部品をメインコンポーネント化し、Variants に切り出すと、その差分をAIが理解してくれる
  • 絶対ルール
    • 数値を直接書かない、Design Token 化する
    • AIのためでも、将来の自分たちのためでもある
  • Figma は絵を描く場所ではない、恒常を定義する場所
  • チェックリスト
    • Auto Layout を使っているか
    • Frame 名に意味があるか(ListItem みたいな名前になっているだけでも違う)
    • Variantsで差分を表現しているか
    • Token を参照になっているか

iOSデザインシステムとデザイナーと連携した取り組み

ひなっこ さん

“聴講メモ：五反田.mobile Vol.2 – モバイルアプリデザイン最前線” の続きを読む

聴講メモ：Mobile Tech Flex 〜4社合同！私たちのモバイル開発自慢大会〜

久々のイベント物理参加。冒頭から高密度なAI活用に関する発表が続いて、AIの勉強会かと錯覚した。が、それほどにAI活用が「AIすごい！」を超え、エンジニアのコーディングにとどまらずQAや顧客対応にも浸透していると感じた時間だった。発表の中で、Claude Code/Copilot/Devinの使い分けの勘所に言及されていて参考になった。仕様駆動が当たり前の様に語られていて、弊社でも実践している。ただ「仕様駆動」で満足するだけでなく、いかに効率性や確実性を高められるかに、世の中の関心ごとが移っていることは明らか。こうした会を通じて各社のナレッジに触れられるのは大変ありがたい。

イベントページ：https://mobiletechflex.connpass.com/event/381976/

AIとなら実現できる事業と品質のシン化の両立

@a_key_bako さん

  • シン化とは？
  • AIによる外部環境の変化（CodexでSoraが28日で）
    • 専門のAndroidチームがいたわけではなかった
    • 爆速で使えるが、品質要求は自ずと高いものが要求される
    • 各社のAI活用法や課題共有に価値がある
  • 現状
    • Deploys/Developer/Day 指標の変化推移
    • デプロイされた数を、開発者x営業日で割る
    • 1を超えた：かなり高い
      • Mobileはデプロイを意識しない：masterブランチへのマージ数をdeployとカウント
    • 変わったこと
      • ジュニア：アウトプット出しながら学習（先輩への質問以外という選択肢）
      • シニア：自身の知識が生産性に直結（ボイラープレートをAIに任せる）
    • 役割での使い分け
      • コーディングはCC、レビューはCopilot、越境はDevin（テストケースを尋ねたり、いろんな職能が使う）
      • CC：低コストでペア作業
        • CLAUDE.md、git worktree、ghコマンド（巨大PRの分割もスムーズ）
      • Devin：
        • 専門街プラットフォーム越境に便利（mobile→BE）
        • 作業プロセスがチームに見える
  • これからの課題
    • 課題1：技術的夫妻
      • 返済はできない
    • 課題2：AI活用の限界
      • 今のプロセスだとせいぜい一人ができることの効率化で限界がある（2倍にはなってもそれ以上には）
    • 納期ベース下での事業と品質のトレードオフ
      • リソースが潤沢でないと大規模リファクタリングができない
      • 課題をブレストすると、課題の洗い出しと優先度づけをした（重要度、漸進可能性、楽しさ）
        • 重要度：プロダクトへの影響度→やらざるを得ない
        • 漸進可能性：少しずつ進められるか（Viewごとに進められる？画面ごと？or一気に置き換え必要？）
          • 高いものはAIによる自律的置き換えに向いている
        • 楽しさ：学びの多さ、賞味期限→投資効果が高い
  • AI支援によって、専門外でも一定品質でコード生成可能に
    • ガードレイルの重要性が増す
    • 原理原則をガードレイルにする

OSアップデート：年に一度の「大仕事」を乗り切るQA戦略

@Myamaguchi75201 さん

  • OSアップデートはなぜ大仕事なのか
    • リリースが多く、クライアントによって機能の紐付け設定が多様
    • OSアップデートによる調査工数が増大
    • リグレッションテストケースが肥大化
  • 現状のテスト戦略の課題
    • テストケースが肥大化しQAリソースが不足
    • 機能仕様の理解の属人化（QA担当者が一番詳しい）
    • 担当者による観点粒度に差分
  • 対策
    • 観点粒度を汎用的にし、テストケースを見直し
    • テスト自動化（勉強会を開催し共有）
    • ↑アウトプットのテストコードをGitHubで一元管理
    • 相互機能影響をAIで抽出（過去実施のテスト観点や実装PRを用いて）

“レビュー”だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか？

@ko_yack さん

  • 活用深化と活用領域のマッピング
    • チームでの半年前はコーディングとレビュー
    • CCに設計テストレビューするまで全て行っている
    • アプリビルドはDevin経由
    • 問い合わせ調査はAtlassian Rovoでエンジニアが一時解凍できる様に
  • CCの活用における課題
    • コンテクストの枯渇：AIが参照不要な情報を読み取ろうとし、コンテクスト枯渇し忘却する
    • AI用ドキュメントをどこに置くか：CLAUDE,mdだとツール入れ替えた時にスイッチできない
    • 広い範囲の修正をしたい
    • メンバー習熟度の違い
  • 課題の解決
    • ドキュメントの構造化：root.instructions.mdを起点として、アーキやコーディングプラクティスを記載する
    • ドキュメントは読むべきタイミングと参照先をセットで管理し、無駄な参照を防ぐ
  • Spec-Driven Development (SDD) の導入
    • Proposal phase, Research & Planning phase, Implementation phase, Retrospective phase
    • フェーズごとにsubagentで分ける
    • 例: Swift移行のために、設計やマイグレーションのナレッジを構造化
    • 例: iOSで作った設計ドキュメントをもとにAndroidでもなぞらせた
  • Snapshotテストを導入
    • UIテストもAIに自律的に修正させる
  • Skills の活用
  • 問い合わせチケット切られたらRovo AgentにJiraなどの情報をRAG経由で参照させ、回答させる

謎現象の解決手段を発見して プチ英雄になりました

@shiosioco40 さん

  • Androidだと、React移行後JSInterface経由のインタラクションができなくなった
  • zod: プロパティアクセスと呼び出しの分離が原因
    • 参照と実行顔同時でないとJSInterfaceのメソッドをWeb側が実行できない
  • 回避策：JSInterfaceの参照を無名関数でラップする（アクセス実行の寸前まで触れない）

Claude × Markdown で仕様書をいい感じに管理したい

@AtriaSoft さん

  • Claude Code を使った仕様書作成管理の便利さと課題
  • 仕様書の老朽化問題（Confluenceの最終更新が2年前、、）
    • メンバー入れ替わりでメンテナンスが宙ぶらり
    • エンジニアに書くモチベーションがない、余裕がない
  • サブエージェント4体
    • reader, writer, reviewe, simpler(簡潔に書き換える)
    • 自然言語で指示したら、readerが既存仕様書やコードベースを読み解いて、writerに渡して仕様書を作成、更新。reviewrがその仕様書の生合成をチェックし、simplerが仕様書を簡潔に書き換える
    • エンジニアがレビューしてPR、レビュー、マージ
    • honkitを利用して、mdファイルは見やすい形にエクスポート
  • 良かったこと
    • 「書く」でなく「レビューする」で知り的ハードルが激減
  • 課題
    • 出力が冗長になりがち、コンテクスト共有に最適化されていない、図表表現に限界（Mermain導入したい）

Kotlin Multiplatform + iOS アーキテクチャの実践

株式会社ディップ 権 さん

  • KMPの実運用での使い分け
  • ビジネスロジックをKMP共有、UIは各OSネイティブ
    • Presentationは書くOS
    • sharedで、Domain/DataをKMP共有
    • modelはPure domain model
    • データ変換フローは、
      • Entity
      • DTO
      • Model
  • iOS側のUIアーキテクチャ
    • 画面ごとの状態管理がバラバラだと、状態遷移の追跡とKMP連携の責務分離が難しくなる、自作アーキテクチャ(Store Pattern)を採用（Intent(ユーザー操作)/Store/State/View）
    • iOS側はMVIをStore Patternで実装し、Android MVIと読み方揃t、チーム認知を統一
    • ObservableでState変更を購読
  • Store Patternのメリット
    • 複雑な機能にスケールしやすい：小規模から大規模まで設計を継続可能
    • チーム運用しやすい：Androidと似た設計で読み方統一、UIイベントの扱い方を共有化でき、レビュー観点揃えられる
  • KMPのSwift側の呼び出し体験をSKIEで改善
    • 今後、Swift Exportで、Obj-Cヘッダ経由の負荷を減らせる可能性があり、experimentalだが、よりSwiftらしいAPI公開に期待

バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計

株式会社ディップ 宮川さん

  • 20年以上続くシステム課題の解消
    • ドメイン駆動設計、AI前提の開発プロセス、AIネイティブな体制
  • SwiftUI、デザインシステム、KMP、Strinct Concurrency Checking…
  • Swift Package Managerによるパッケージ管理
    • 分割の基準、機能画面ごと、外部依存の隔離(Firebase, KMPなど)、再利用性の担保(UI components, design system)
    • 全体構成が把握しやすくなり、循環参照を抑止できた
  • SwiftPMにおける課題
    • KMPなど外部に依存している状態で、SwiftUI Previewが不安定（タイムアウト）
    • 外部サービス依存のモジュールを限定的にし、protocolやmockのみを定義したInterfaceモジュールを定義し、中間に挟む様にし、KMPなどへの直接依存を回避した
      • poinfree / swift-dependencies により実現
  • AIコーディングによる課題（CC）
    • 意図しないモジュールにコードが生成される
    • モジュールごとに定めた依存関係のルールを守らない
    • CLAUDE.mdに全ルールを記述していたが、コンテクスト肥大化するため、.claude/rules/を活用して最適化した
    • レイヤー概念を導入してルールをシンプル化：モジュール数の増大で依存関係が複雑化する、AIにとっての認知負荷も増大するため、モジュールの責務ごとにグルーピングしたレイヤーを導入した（同じレイヤーは、同じ依存ルールに則る）
    • ruleファイル自体が設計ドキュメントとして機能

RELAX PIXEL TUNES CD PLAYER を購入した

10年くらい前から、ONKYOのCR-N755というオーディオレシーバーを使っているのだが、数年前からCDプレイヤーが壊れて聴けない状態が続いていた。

とはいえCDはまだ手元にあるし、Apple Music や Spotify にない音源は買うしかない。さらにコンサートに行けばサイン目当てにCDを買ったりもする。なので聴く手段はないがCDの数は増えていくという不思議な状態に陥っていた。

そんな中この記事で Relax というメーカーのCDプレイヤーを知り、先日とうとう購入した。

初代iMacから着想を得たCDプレーヤー「RELAX PIXEL TUNES」新色「Ray of Light」 – AV Watch

かつてはこうしたCDプレイヤーは珍しくなかったはずだが、時代はMD、iPodと移り、いまやストリーミング意外の手段で聴くのはオーディオマニアくらいに限られた今、逆にポータブルにCDを聴けるという体験が新しい。

さらに、CD主流の当時であってもこうして本体独立で音源再生できるのは決して多くはなかったのではないだろうか？ ラジカセ感あるローファイな音質で、ながら聴きだとかえって疲れしなくて良い。きちんと聴きたければヘッドフォン端子に有線イヤホンや外付けスピーカーを刺すか、Bluetoothイヤホンとペアリングすればよい。

なにより、CDが回転する様子を眺めているのが楽しい。音飛び防止としてオンメモリに音源を読み込む機能が搭載されていて、その都合でCDの回転が途中で止まったり、再開したりする挙動は、何度見ても不思議。この機能はON/OFF可能なので、ずっとCDを回転させ続けることも可能。

こうした機能性抜きにしても、初代iMacを想起させるボンダイブルーの筐体は可愛らしくて眺めてても楽しい。個人的には良い買い物だった。

Android：空白にSpacerを使うべきかpaddingを使うべきか

Android 開発に入門して半年以上が経つ。

画面実装で避けては通れないコンポーネント間の間隔について、Spacer を使うべきか、padding を使うべきか時々悩むことがある。というのは、自分の手で実装する場合は割と手癖的に padding ベースで書くことが多い気がするだが（SiwftUIでもそうしていたので）、Claude に書かせていると惜しげもなく Spacer を挿入してくるので、どちらが適切なのだろう？と疑問に思ったのだった。

もちろん、Spacer / padding の判断は要所要所で行って良いはずだ。代表的な例で言えば、画面幅によって可変する間隔は迷いなく Spacer で表現するだろう。とはいえ、どういうケースでどうするべきか、網羅的には言語化できていなかった。

Android 開発でのデファクトがどうなっているのか、”Jetpack Compose Spacer vs padding” のようなキーワードで検索してみたところ、いくつか興味深い情報を見つけたので、ここで何か結論を出すつもりはないが個人的にメモしてみる。

  • Space Hoisting: Should I use the padding Modifier or the Spacer composable?
    • お馴染み “State Hoisting” の概念をもじって “Space Hoisting” という考え方を紹介している。間隔のレイアウトを子ではなく親に委ねるというもの（子は自身の周囲に空間を持たず、親側で Spacer や Modifier.padding(...) で空間をレイアウトする）
    • その上で、Spacer の有効性を説明している
      • 空白の表現を意図的に伝えられる
      • コンポーネントのカプセル化を保てる
      • 対象がタップ可能の場合、当たり判定や ripple effect への影響を考えるとよりシンプル
      • コンポーネントのサイズ計算に影響しない

ごもっともである。

いっぽう、両者でレイアウト処理のパフォーマンスに違いがありそう（感覚的に、要素数の増える Spacer の方が遅い気がする）だと感じていたのだが、実際に検証している Stack Overflow の投稿を見つけた。

android – Compose Spacer vs view padding performance – Stack Overflow

極端な事例では Spacer のレイアウトコストが顕にはなったが、結論ケースバイケースで、どちらかを一辺倒に選択する根拠にはならないことが分かった。

他の投稿を読んでも共通してケースバイケースに捉えている。あるとすれば、対象要素がコントロールの場合は、タップ（Android では特に ripple effect を含め）どのように作用させたいかで考えれば良さそう。

STORES さんのように、どういったケースでどちらを使うか、ルール化しておくと AI に書かせてもブレないので、これを参考にチームでも検討したいと思った。

Claude Code 生みの親による10のtipsを読んだ

最近開発するときは、仕事・個人共に Claude Code 全振りなのだが、Claude の開発者 Boris Cherny 氏が、Claude Code を使う際の10のチップスを共有していたので、勉強がてら読んでみた。

Claude は雰囲気だけで十二分に使えてしまうので、意識的にこうした手法を取り入れてトライ&エラーしないと、我流のまま世の中の進歩から取り残されてしまう実感がある。

  1. 並行でより多くを行う
    • 複数セッション起動し、それぞれに git worktree (大半の Claude Code チームが好んでいる) を走らせる
  2. 複雑なタスクは必ずプランモードから始める
    • ある Claude にプランを書かせ、別の Claude にそれをレビューさせる
    • 問題があればプランモードに戻し、プランし直す
    • 実装だけでなく、検証時もプランモードを活用する
  3. CLAUDE.md に投資する
    • 修正のたびに、同じ間違いをしないようCLAUDE.md を修正することを、Claude に指示をする
    • CLAUDE.md に惜しみなく修正を加え、目に見えて間違いが減るまで繰り返すこと
  4. スキルを作成し、Git にコミットし、すべてのプロジェクトに流用する
    • 1日のうちに複数行うことは、スキルかコマンドにすること
      • すべてのセッションの終わりで実行し、重複したコードを削除するコマンドを作る
      • 1週間分の Slack、ドライブ、GitHub などの情報をコンテクストダンプに同期するコマンドを作る
  5. Claude はたいていのバグを自身で修正できる
    • Slack MCP を有効にし、Slack URL を Claude Code に与えて修正を依頼する
  6. プロンプトをレベルアップする
    • 自己レビューしてテスト通るまでPR出すな
    • ここまでの知見を活かして、現状を破棄しより良い方法で実装しなおせ
    • 仕様を詳細に書き実装前にあいまいさを減らせ
  7. ターミナルや環境のセットアップ
    • Claude Team 推奨の Ghostty
    • /statusline コマンドでステータスバーをカスタマイズする
    • 音声認識を使う：タイピングよりも3倍早く指示できる
  8. Subagent を利用する
    • “subagents を使うこと” を、より複雑な課題解決を依頼する際に加える
    • 個別タスクを subagent にオフロードすることで、メインのコンテクストをクリーンに保てる
    • 承認リクエストをフック経由で Opus 4.5 にルートして、攻撃をスキャンし安全なリクエストを自動で承認させる
  9. Claude をデータ分析に用いる
    • bq CLI を用いて Claude にデータ取得と分析をさせる
    • BigQuery スキルがコードベースに組み込まれていて、Claude チームの誰もが Claude Code でクエリを書いている
  10. Claude で学ぶ
    • Explanatory または Learning アウトプットスタイルを有効とし（/config で）、Claude が変更の「なぜ」を説明できるようにする
    • HTML 表現による説明、ASCII 図による説明の生成
    • 自分自身の理解を Claude に述べ、Claude がフォローアップをすることで不足を補う（spaced-repetition learning）

This website stores cookies on your computer. These cookies are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to to opt-out of any future tracking, a cookie will be setup in your browser to remember this choice for one year.

Accept or Deny