皆様こんにちは！iOSDC Japan 2025開催がいよいよ来週末に迫り、今回はスパイダープラスのブースの推しポイントを紹介してまいります。
この記事の中には、iOSDCトークンが隠れていますので探してみてください。
もちろんブースへのご来訪もお忘れなく！
AIでDBを操作 ~ Cursor×MCPでSwiftDataを自然言語で扱う方法
スパイダープラスで iOS アプリの開発を担当している荒井と申します。仕事としてはもちろん、会社外でも趣味としてiOS アプリ開発を続けており、日常的に Swift や周辺の技術に触れています。
これまで趣味で開発していたアプリにはRealmを利用していましたが、近年は Apple が提供するSwiftDataをメインに採用するようになりました。SwiftDataは宣言的で使いやすく、Apple 製ならではの統合感も魅力ですが、登場して日が浅いため「実際の開発では不便だな」と感じる場面も少なくありません。
本記事で扱う内容
今回はCursor と自作 MCP サーバーを連携させて、SwiftData を自然言語で直接操作できる仕組みを作ってみました。
私が日々の開発の中で「こんな機能があればもっと楽になるのに」と思ったポイントを取り上げ、それを解決するための工夫や実践例をご紹介します。
続きを読むプロダクトのビジネス価値を左右するシステムアーキテクチャ設計
スパイダープラスの本田です。
最近は設計をしたり設計のレビューをする機会などが増え、アーキテクチャについて考えたりする時間が多くなってきたので、今までの学習や経験からの気づきをまとめてみたいと思います。
はじめに：ユーザー体験とシステムアーキテクチャの密接な関係
近年のプロダクト開発では「デザインファースト」「ユーザー体験中心」といったアプローチが主流となっています。美しいUIや直感的な操作性は確かに重要ですが、どんなに洗練されたデザインも、システムが遅い、頻繁に落ちる、データが消えるといった問題があれば、その価値は一瞬で失われてしまいます。
今回は、非機能要件を早期に考慮したアーキテクチャ選択が、優れたユーザー体験の実現に不可欠であることを書いていきます。特に、多くの開発現場で見過ごされがちな「結果整合性」という選択肢について、その価値と実現方法について整理したいと思います。
なぜ非機能要件は後回しにされるのか
「当たり前品質」という落とし穴
品質管理の世界では『狩野モデル』における『当たり前品質』という概念があり、システム品質の文脈で考えると、以下のような要素が該当します。これは「あって当然、なければ大きな不満を生む品質」のことです。システム開発において、以下のような要素は典型的な当たり前品質です：
- システムが落ちない（可用性）
- ストレスのない速度で応答する（適切なレスポンス速度）
- データが消えない・壊れない（データ整合性）
ユーザーにとって、これらは「できて当たり前」なのです。しかし皮肉なことに、「当たり前」だからこそ、開発時には後回しにされがちです。
非機能要件が後回しになる現実
開発現場でよく聞かれる声があります：
「まずは動くものを作ろう。性能改善は後からでもできる」
この考え方自体は間違いではありません。特に新規プロダクトの仮説検証フェーズでは、機能が価値を生むかどうかを素早く確認することが重要です。しかし、仮説検証・技術検証と、本番システムの設計は分けて考える必要があります。
多くのプロジェクトでは、以下のような理由で非機能要件が後回しになりがちです：
- 目に見える機能開発が優先される組織的な力学
- 非機能要件の定量化・効果測定の難しさ
- 検証時の技術選択との差から発生する変更コスト （特に本番稼働後は、データ移行やダウンタイムの問題が発生）
後回しにすることで生じる課題
非機能要件を敬遠した結果、以下のような問題が発生することがあります：
- ビジネス機会の損失：人気商品のセール開始時にシステムがダウン
- ユーザー離脱：ページ読み込みに3秒以上かかると50%のユーザーが離脱
- ブランド価値の毀損：頻繁なエラーや遅延による信頼性の低下
せっかくユーザー体験を重視してデザインを作り込んでも、システムの基本的な品質が担保されていなければ、本末転倒な結果になってしまう恐れがあります。
競争力の源泉としての非機能要件
一方で、非機能要件を適切に満たしているサービスは、それだけで強力な競争優位性を持ちます：
- とある動画配信サービス：高い可用性が生む「いつでも見られる」という信頼
- とある大手ECサイト：わずかな遅延が売上に直結するという認識のもと、徹底的な高速化
- 世界的な検索エンジン：検索結果の表示速度が、他社との大きな差別化要因
「当たり前品質」の徹底が、実は最大の差別化要因になる時代なのです。
非機能要件とアーキテクチャ選択：バランスの取れたアプローチ
非機能要件がユーザー体験に与える影響
非機能要件は、直接的にユーザー体験を左右します：
レスポンスタイム(*)
- 100ミリ秒：瞬時と感じる
- 1秒：思考の流れが保たれる限界
- 10秒：注意を保てる限界
可用性
- 99.9%（スリーナイン）：年間8.76時間の停止
- 99.99%（フォーナイン）：年間52.56分の停止
- わずか0.09%の差が、ユーザーの信頼を大きく左右
データ整合性
- 注文が重複する、残高が合わない
- 一時的でも、ユーザーの混乱と不信を招く
技術選定の前に明確にすべきこと
アーキテクチャを選択する前に、以下を明確にする必要があります：
- ビジネス要求の整理
- どの機能にリアルタイム性が必要か
- どのデータに厳密な整合性が必要か
- 想定されるトラフィック規模とその成長率
- ユーザーシナリオの分析
- ユーザーはどの程度の遅延を許容するか
- 一時的な不整合に気づくか、影響はあるか
- サービス停止時の代替手段はあるか
- トレードオフの理解
- すべてを満たすことはできない
- 何を優先し、何を妥協するか
例えば、ECサイトを考えてみましょう。同じサイト内でも、機能によって求められる品質は全く異なります。
- レビュー機能: 「多少の表示遅延や、いいね数の反映の遅れは許容できる（結果整合性でOK）。それよりも、書き込み・読み込みがサクサクできる体験が重要。」
- 決済機能: 「残高や注文内容は1円、1個の間違いも許されない（強整合性が必須）。多少レスポンスが遅くなっても、データの正確性が最優先。」
このように、機能ごとの特性を見極めることが重要です。
ここまで非機能要件の重要性を見てきました。実際のシステム設計では、 これらの要件間でトレードオフが発生します。
特に重要なのが「データの整合性をどう扱うか」という問題です。 現代のWebサービスは、スケールするために分散システムを採用は当たり前になっていますが、そこには避けられない制約があります。
以下では、分散システムにおけるデータ整合性の選択肢と、それがビジネスに 与える影響について、CAP定理を起点に具体的に検討していきます。
CAP定理：分散システムの基本的な制約
CAP定理とは
分散システムには避けられない制約があります。CAP定理は、以下の3つの特性のうち、同時に満たせるのは2つまでであることを示しています：
- C (Consistency：一貫性)：すべてのノードが同じデータを見る
- A (Availability：可用性)：システムは常に応答する
- P (Partition tolerance：分断耐性)：ネットワーク分断に耐える
現実のインターネット環境では、ネットワーク分断は必ず発生するため、実質的にはCかAかの選択になります。
※ より発展的なPACELC（平常時のレイテンシと一貫性のトレードオフも考慮）もありますが、基本的な考え方は同じであり、ここではCAP定理として説明します。
CPシステムとAPシステム
CPシステム（一貫性＋分断耐性）
- 特徴：データの正確性を保証、分断時は一部のリクエストを拒否
- 例：銀行システム、在庫管理システム
- ユーザー体験：「ただいま混雑しています」エラーなどが発生しうるが、間違ったデータが表示されるということがない
APシステム（可用性＋分断耐性）
- 特徴：APシステム：可用性を優先し、ネットワーク分断時でも 可能な限り応答を返す（ただし一時的な不整合を許容）
- 例：SNS、動画配信サービス
- ユーザー体験：いつでも使えるが、情報が少し古い可能性がある
強整合性 vs 結果整合性：適材適所の選択
強整合性の特徴とトレードオフ
強整合性は、従来のRDBMSが提供してきた一貫性モデルです。
メリット
- プログラミングモデルがシンプル
- データの状態が予測可能
- トランザクションによる安全性
デメリット
- スケーラビリティの課題（水平スケール時にコストとレイテンシが増加）
- レスポンスタイムへの影響（ロック待機）
- 可用性の低下（ノード障害時の影響大）
適したケース
- 金融取引：口座残高の正確性が絶対
- 在庫管理：在庫数の過不足は許されない
- 予約システム：ダブルブッキングは避けるべき
結果整合性の特徴とトレードオフ
結果整合性は、一時的な不整合を許容し、最終的に整合性を保証するモデルです。
『最終的に整合性が保たれる』の『最終的』とは：
- 一般的には数秒〜数分程度
- ビジネス要件に応じて許容範囲を定義
- 例：SNSの「いいね」数は1分以内、在庫表示は10秒以内など
メリット
- 高速なレスポンス（ローカル処理で完結）
- 高い可用性（部分的な障害に強い）
- 優れたスケーラビリティ（水平スケール容易）
デメリット
- プログラミングモデルの複雑化
- 一時的な不整合への対処が必要
- デバッグ・テストの難しさ
適したケース
比較表
| 観点 | 強整合性 (Strong Consistency) | 結果整合性 (Eventual Consistency) |
|---|---|---|
| データ | 常に最新・正確 | 一時的な不整合を許容 |
| レスポンス | 遅くなる可能性（ロック等） | 高速（ローカルで応答） |
| 可用性 | 低下する可能性（分断時） | 高い（部分障害に強い） |
| スケール | 垂直スケールが中心 | 水平スケールが容易 |
| 実装複雑度 | シンプル | 複雑（非同期処理等） |
| 適した用途 | 銀行システム、在庫管理 | SNS、レコメンデーション |
※ なお、強整合性とスケーラビリティの両立を目指すNewSQL（Cloud Spanner、Aurora DSQLなど）という選択肢もありますが、この記事ではその前段階として、基本的なCAP定理と整合性モデルの理解に焦点を当てたいため割愛させていただきます。
最適な選択のための観点
以下のような質問に答えることで、より適切な選択ができます：
- ビジネス影響の評価
- 一時的な不整合でユーザーや事業に実害があるか？
- その影響は許容可能な範囲か？
- パフォーマンス要求
- ミリ秒単位のレスポンスが必要か？
- 同時接続数やスループットの要求は？
- 将来の拡張性
- ユーザー数が10倍、100倍になる可能性は？
- グローバル展開の予定は？
- チームの能力
- 分散システムの運用経験は？
- 複雑なアーキテクチャを保守できるか？
現実の課題：結果整合性という選択肢
なぜ結果整合性が検討されないのか
多くの開発現場で、結果整合性という選択肢が検討されない理由があります：
技術的慣性
知識の偏り
心理的障壁
- 「データの不整合」という言葉への恐怖
- 複雑性への漠然とした不安
選択肢を広げることの重要性
しかし、すべてを強整合性で実装する必要はありません。システムの中で：
- コア機能：強整合性で確実性を担保
- 周辺機能：結果整合性で体験を向上
このような使い分けが、システム全体の価値を最大化します。
結果整合性と相性の良いアーキテクチャ：CQRS
CQRSの基本概念
CQRS（Command Query Responsibility Segregation）は、書き込み（Command）と読み取り（Query）を分離するアーキテクチャです。
このアーキテクチャにより：
- 書き込みと読み取りで異なるスケーリング戦略を選択可能
- Commandは即座に受け付けられる
- Read Modelは非同期で更新される
- 読み取りは常に高速
CQRSによる結果整合性の実装例
ECサイトでの超簡易的な実装例を考えてみましょう：
商品閲覧（Query）
// 読み取り専用の最適化されたモデルから取得 const product = readModel.getProduct(productId); // 高速にレスポンス（キャッシュも活用）
カート追加（Command）
// 1. 「カート追加」リクエストを受け付け、キューに登録する // この時点でユーザーには「追加しました」と即座に応答を返す sendCommandToQueue('AddToCart', { userId, productId }); // --- ここから下は非同期（バックグラウンド）で実行される --- // 2. キューからリクエストを取り出し、イベントを処理する onEvent('ProductAddedToCart', (event) => { // 3. ユーザーが見るための「読み取り専用データ」を更新する updateCartView(event.userId, event.productId); });
この設計により：
- ユーザーは即座にフィードバックを得る
- システムは高負荷に耐える
- 一時的にカート表示が遅れても、UXへの影響は最小限
アーキテクチャの進化：マイクロサービスとの関連
マイクロサービスアーキテクチャは、異なる非機能要件を持つ機能を分離する手段として有効です。
例えば、ECサイトを以下のように分割：
- 商品カタログサービス：AP型（高速な検索・閲覧）
- 在庫管理サービス：CP型（正確な在庫数）
- レコメンドサービス：AP型（リアルタイム性重視）
- 決済サービス：CP型（金銭の正確性）
各サービスが最適な整合性モデルを選択することで、システム全体として最高のユーザー体験を実現できます。
※なお、マイクロサービス間でのデータ整合性は別の課題です。 例えば、在庫サービス（CP型）と注文サービス（AP型）の間では、 Sagaパターンや分散トランザクションなどの考慮が必要になります。
複雑性への対処
開発者の負担が増える現実
結果整合性を採用すると、システムの複雑性が増し、開発者のやることが増えるのは事実です。
AIが変えつつある開発体験
結果整合性は確かに開発でやることを増やしますが、近年、AIがその「面倒だが定型的な作業」を肩代わりしてくれるようになりました。例えば、冪等性担保やリトライロジックといった定型的なコードは、AIコーディング支援ツールがかなりの部分を生成してくれます。また、複雑な非同期処理のテストケースをAIに洗い出させることで、考慮漏れを防ぐことも期待できます。
これにより、開発者は本来注力すべき「ビジネスロジック」と「アーキテクチャ設計」に集中できる時代になりつつあり、高い品質を維持しつつ、結果整合性の恩恵を享受できる可能性が高まっています。
まとめ：ビジネス価値を最大化するアーキテクチャ選択
本記事では、システムアーキテクチャの選択がプロダクトのビジネス価値に与える影響について書いてみました。
重要なポイント
- 非機能要件は「当たり前品質」：軽視されがちだが、ユーザー体験の基盤
- CAP定理の理解：すべてを満たすことはできない、トレードオフの認識
- 強整合性と結果整合性：それぞれに適した用途がある
- 選択肢を知ること：デフォルトに縛られず、最適な選択を
アーキテクチャ設計をしっかり行うことはデザインファーストな進め方とは対立しません。むしろ、両方を適切に考慮することで、真に優れたユーザー体験を持つプロダクトが生まれると思います。
技術的な選択肢を理解し、ビジネスに最適な判断に貢献をすることが、これからのエンジニアに求められる重要なスキルの一つではないでしょうか。
最後に、スパイダープラスでは仲間を募集中です。スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。最後までご覧いただき、ありがとうございます。
iOSDC Japan 2025へ出展します！
こんにちは！iOSチームの舘です。
スパイダープラスではiOSDC Japan 2025に昨年に引き続きゴールドスポンサーとして協賛＆ブース出展を行います。
iOSDC Japan 2025に関するお知らせをこの記事でご紹介します！
📝iOSDC Japan 2025 開催概要
- 開催：2025年9月19日（金）〜 9月21日（日）
- 場所：有明セントラルタワーホール＆カンファレンス+ニコニコ生放送
- 公式ウェブサイト：https://iosdc.jp/2025/
※各日の開催時刻やイベントの詳細は公式ウェブサイトでご覧ください。
🎁ボックスノベルティ
まずは、ボックスノベルティについて紹介します。
今回、スパイダープラスからはうちわをお届けします🔖
これまでのカンファレンスではクリアーしおりなどを配布しましたが、今回は「建設現場では電気が使えない場面もあるため電気を使わずに涼を感じられるもの」をイメージしてうちわを封入させていただきました！
さらにスパイダープラスのブースでも、様々なノベルティを配布予定です。
楽しい企画も絶賛準備中ですので、お気軽にお越しください！
関連情報
昨年のiOSDC Japan 2024参加レポートと、これまでに投稿してきたiOS関連記事も紹介いたします。この機会にぜひご一読ください！
昨年のiOSDC Japan 2024参加レポート
これまでのiOS関連記事
最後に
スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
AI仕様駆動開発IDEのKiroは業務で使えるのか妄想してみた
今日もまた、ホワイトボードに描く空想の地図を前に、余白を埋める作業の波が押し寄せる。
こんにちは、takahashiです。
要件定義や設計って頭の中には考えが浮かんできますが、それをドキュメント化するのって大変ですよね。
さて、生成AIを活用した仕様駆動開発の「Kiro」がAWSから7/14に突如公開されました。注目のSpec機能は自然言語から要件定義→設計→タスクを定義し、コードを自動生成するというもので、その開発アプローチは果たして実業務に適用できそうなのか完全プライベート時間で試してみました。
Kiro 注目の機能「Spec」を試そう
まずはアイコンが劇的にかわいい！
実際に新規プロダクトを作ってみました。
続きを読むCREの問い合わせ対応を革新する、私流AI活用術：VSCode中心のモダンワークフロー
はじめまして、スパイダープラスCREチームの藤原です。普段はAIを相棒に、お客様からのお問い合わせ調査や不具合の原因特定に奮闘しています。
CRE（Customer Reliability Engineering）の一員として働く中で、繰り返される問い合わせへの対応や、知識が特定の担当者に依存する「属人化」は、チーム全体の生産性を妨げる大きな課題だと感じていました。
そこで私は、個人の調査効率を劇的に向上させ、チームのナレッジ共有を促進するために、VSCodeを中心としたAI活用ワークフローを構築・実践しています。
本記事では、その具体的な手法を、私自身の調査プロセスに沿って紹介します。
続きを読むAIと二人三脚！Copilotを活用した開発フローと効率化
はじめに
「AIペアプログラミング」に本格的に取り組んでから半年ほどが経ちました。人間だけで開発していた頃と比べ、その進め方は大きく変わっています。さまざまな意見がある中、私は体感で工数を1/3まで削減できたと感じています。
今回は、どのように開発手法が変わったのか、具体的な作業フローを交えながらご紹介します。
開発の主戦場と利用ツール
現在、主に担当しているのは仕様書作成とAPI開発ですが、フロントエンドの修正も行っています。モバイルアプリ開発（iOS/Android）は対象外です。
AIツールは、当初Clineを利用していましたが、タスクによっては参照ファイルが多すぎたり、タスク自体が長くなりすぎたりしたため異常停止することが多発していました。
そこで現在は、GithubCopilotのAgentモードをClaude Sonnet 4と組み合わせて利用しており、現時点では最適な選択肢だと感じています。些細な点に思えるかもしれませんが、アクティブなファイルを自動で優先参照してくれるため、タスクごとにファイルパスを指定する手間が省け、長期的な目で見ると大きな効率化につながっています。
