こんにちは。
PF開発部 / SREチーム所属の平木です。
今年に入って公開されたAmazon ECS MCP Serverを試してみたので、その内容をまとめました。
普段ECSを運用していると、コンテナにログインして hostname を確認したり、
タスクを再起動するなど、ちょっとした操作を行うことがあります。
「これ、自然言語でできたら便利じゃない?」と思ったことはありませんか?
実際にMCP Serverを導入して、チャット画面からECS操作を行える環境 を構築した結果を紹介します。
続きを読む
こんにちは、開発チームの平野です。 当社のプロダクト開発では生成AIの活用が推進されていますが、私のチームも漏れなくそれに当てはまります。 私のチームではプロダクト全体の不具合対応を扱うことも多いのですが、その現場で「生成AIで効率化できたこと／しづらかったこと」をまとめます。
おおよそ、不具合対応では以下のようなことを行っています。
さて、このうち、私が生成AIの利用が効率的だと感じているのはどれだけあるでしょうか？
定型・明確な入力条件のあるタスクは生成AIに任せてしまうのが効率が良いと感じています。
以前にチームメンバーが「Devinを使ったGitHub Issueの作成効率化」という記事を執筆していますが、こうした転記のようなタスクは、生成AIの活用で効率化できていると思います。
不具合の原因究明や対策の立案、ソースコードの修正、テストの作成なども、不具合事象が単純で期待値が明確であれば、生成AIを活用することができると思います。 生成AIにソースコードプロジェクトを入力して依頼すれば、原因を特定して修正提案を上げてくれますし、Pull Requestまで作成してくれます。
リリース判定のための情報整理についても、入力する情報についてのルールを明確に定義すれば、生成AIに任せてしまえるのではないかと思います（これはまだ実施できていませんが）。
ただ、生成AIに任せっきりにはせず、これらの妥当性は人間が確認する必要があります。
先に述べたとおり、単純なタスクや事象であれば生成AIで効率化・解決できることも多いと思います。
しかし、再現手順が複雑な不具合や、複数の要素が関連して発生する不具合については、生成AIでは解決できていないことがほとんどです。 こうした事象については、生成AIを活用するよりも、人間の経験と勘（想像）をもって、地道に対処した方が、早く解決できる場合もあると感じています。
たとえば、当社のプロダクト「SPIDERPLUS」のiPad版には、施工検査用の測定器をBluetoothで接続して、測定値をインポートする機能があります。接続したまま、他の検査機能に切り替えると測定器から誤って値を他の検査に取り込み、データが混在する不具合がありました。 調査開始当初、生成AIに状況を伝えて仮説を探ったものの、なかなか解決の糸口が見つからなかったのです。 現場では複数の検査を並行して実施することもある点に着目し、「接続を切らずに検査の種類を変更する」運用を想定してテストを実施してみました。詳しいことは割愛いたしますが、そこで再現された事象にもとづいて解決に向かうことができたのです。
生成AIを活用することで、効率化できることはたくさんあります。
少し複雑なことでも、分解して、誤解が生まれない言葉で入力すると、とても早く解決することができるようになってきました。
しかしながら、生成AIで解決できないこともまだたくさんあります。 今回紹介した、Bluetooth接続したまま検査機能を切り替えた際の不具合調査が期待どおりには進まず、人による調査に切り替えたように、生成AIの活用で直接解決できなかったケースでは、途中から人による対応に切り替えています。 全体の効率のバランスを考えながら人が行う、業務委託やオフショアを活用する、さらに強力なツールを導入するなど、多段的なアプローチが必要になると考えています。
スパイダープラスでは仲間を募集中です。 スパイダープラスにちょっと興味が出てきたなという方がいらっしゃいましたらお気軽にご連絡ください。
スパイダープラスで iOS アプリの開発を担当している荒井と申します。仕事としてはもちろん、会社外でも趣味としてiOS アプリ開発を続けており、日常的に Swift や周辺の技術に触れています。
これまで趣味で開発していたアプリにはRealmを利用していましたが、近年は Apple が提供するSwiftDataをメインに採用するようになりました。SwiftDataは宣言的で使いやすく、Apple 製ならではの統合感も魅力ですが、登場して日が浅いため「実際の開発では不便だな」と感じる場面も少なくありません。
今回はCursor と自作 MCP サーバーを連携させて、SwiftData を自然言語で直接操作できる仕組みを作ってみました。
私が日々の開発の中で「こんな機能があればもっと楽になるのに」と思ったポイントを取り上げ、それを解決するための工夫や実践例をご紹介します。
続きを読む
スパイダープラスの本田です。
最近は設計をしたり設計のレビューをする機会などが増え、アーキテクチャについて考えたりする時間が多くなってきたので、今までの学習や経験からの気づきをまとめてみたいと思います。
近年のプロダクト開発では「デザインファースト」「ユーザー体験中心」といったアプローチが主流となっています。美しいUIや直感的な操作性は確かに重要ですが、どんなに洗練されたデザインも、システムが遅い、頻繁に落ちる、データが消えるといった問題があれば、その価値は一瞬で失われてしまいます。
今回は、非機能要件を早期に考慮したアーキテクチャ選択が、優れたユーザー体験の実現に不可欠であることを書いていきます。特に、多くの開発現場で見過ごされがちな「結果整合性」という選択肢について、その価値と実現方法について整理したいと思います。
品質管理の世界では『狩野モデル』における『当たり前品質』という概念があり、システム品質の文脈で考えると、以下のような要素が該当します。これは「あって当然、なければ大きな不満を生む品質」のことです。システム開発において、以下のような要素は典型的な当たり前品質です：
ユーザーにとって、これらは「できて当たり前」なのです。しかし皮肉なことに、「当たり前」だからこそ、開発時には後回しにされがちです。
開発現場でよく聞かれる声があります：
「まずは動くものを作ろう。性能改善は後からでもできる」
この考え方自体は間違いではありません。特に新規プロダクトの仮説検証フェーズでは、機能が価値を生むかどうかを素早く確認することが重要です。しかし、仮説検証・技術検証と、本番システムの設計は分けて考える必要があります。
多くのプロジェクトでは、以下のような理由で非機能要件が後回しになりがちです：
非機能要件を敬遠した結果、以下のような問題が発生することがあります：
せっかくユーザー体験を重視してデザインを作り込んでも、システムの基本的な品質が担保されていなければ、本末転倒な結果になってしまう恐れがあります。
一方で、非機能要件を適切に満たしているサービスは、それだけで強力な競争優位性を持ちます：
「当たり前品質」の徹底が、実は最大の差別化要因になる時代なのです。
非機能要件は、直接的にユーザー体験を左右します：
レスポンスタイム(*)
可用性
データ整合性
アーキテクチャを選択する前に、以下を明確にする必要があります：
例えば、ECサイトを考えてみましょう。同じサイト内でも、機能によって求められる品質は全く異なります。
このように、機能ごとの特性を見極めることが重要です。
ここまで非機能要件の重要性を見てきました。実際のシステム設計では、 これらの要件間でトレードオフが発生します。
特に重要なのが「データの整合性をどう扱うか」という問題です。 現代のWebサービスは、スケールするために分散システムを採用は当たり前になっていますが、そこには避けられない制約があります。
以下では、分散システムにおけるデータ整合性の選択肢と、それがビジネスに 与える影響について、CAP定理を起点に具体的に検討していきます。
分散システムには避けられない制約があります。CAP定理は、以下の3つの特性のうち、同時に満たせるのは2つまでであることを示しています：
現実のインターネット環境では、ネットワーク分断は必ず発生するため、実質的にはCかAかの選択になります。
※ より発展的なPACELC（平常時のレイテンシと一貫性のトレードオフも考慮）もありますが、基本的な考え方は同じであり、ここではCAP定理として説明します。
CPシステム（一貫性＋分断耐性）
APシステム（可用性＋分断耐性）
強整合性は、従来のRDBMSが提供してきた一貫性モデルです。
メリット
デメリット
適したケース
結果整合性は、一時的な不整合を許容し、最終的に整合性を保証するモデルです。
『最終的に整合性が保たれる』の『最終的』とは：
メリット
デメリット
適したケース
| 観点 | 強整合性 (Strong Consistency) | 結果整合性 (Eventual Consistency) |
|---|---|---|
| データ | 常に最新・正確 | 一時的な不整合を許容 |
| レスポンス | 遅くなる可能性（ロック等） | 高速（ローカルで応答） |
| 可用性 | 低下する可能性（分断時） | 高い（部分障害に強い） |
| スケール | 垂直スケールが中心 | 水平スケールが容易 |
| 実装複雑度 | シンプル | 複雑（非同期処理等） |
| 適した用途 | 銀行システム、在庫管理 | SNS、レコメンデーション |
※ なお、強整合性とスケーラビリティの両立を目指すNewSQL（Cloud Spanner、Aurora DSQLなど）という選択肢もありますが、この記事ではその前段階として、基本的なCAP定理と整合性モデルの理解に焦点を当てたいため割愛させていただきます。
以下のような質問に答えることで、より適切な選択ができます：
多くの開発現場で、結果整合性という選択肢が検討されない理由があります：
技術的慣性
知識の偏り
心理的障壁
しかし、すべてを強整合性で実装する必要はありません。システムの中で：
このような使い分けが、システム全体の価値を最大化します。
CQRS（Command Query Responsibility Segregation）は、書き込み（Command）と読み取り（Query）を分離するアーキテクチャです。
このアーキテクチャにより：
ECサイトでの超簡易的な実装例を考えてみましょう：
商品閲覧（Query）
// 読み取り専用の最適化されたモデルから取得 const product = readModel.getProduct(productId); // 高速にレスポンス（キャッシュも活用）
カート追加（Command）
// 1. 「カート追加」リクエストを受け付け、キューに登録する // この時点でユーザーには「追加しました」と即座に応答を返す sendCommandToQueue('AddToCart', { userId, productId }); // --- ここから下は非同期（バックグラウンド）で実行される --- // 2. キューからリクエストを取り出し、イベントを処理する onEvent('ProductAddedToCart', (event) => { // 3. ユーザーが見るための「読み取り専用データ」を更新する updateCartView(event.userId, event.productId); });
この設計により：
マイクロサービスアーキテクチャは、異なる非機能要件を持つ機能を分離する手段として有効です。
例えば、ECサイトを以下のように分割：
各サービスが最適な整合性モデルを選択することで、システム全体として最高のユーザー体験を実現できます。
※なお、マイクロサービス間でのデータ整合性は別の課題です。 例えば、在庫サービス（CP型）と注文サービス（AP型）の間では、 Sagaパターンや分散トランザクションなどの考慮が必要になります。
結果整合性を採用すると、システムの複雑性が増し、開発者のやることが増えるのは事実です。
結果整合性は確かに開発でやることを増やしますが、近年、AIがその「面倒だが定型的な作業」を肩代わりしてくれるようになりました。例えば、冪等性担保やリトライロジックといった定型的なコードは、AIコーディング支援ツールがかなりの部分を生成してくれます。また、複雑な非同期処理のテストケースをAIに洗い出させることで、考慮漏れを防ぐことも期待できます。
これにより、開発者は本来注力すべき「ビジネスロジック」と「アーキテクチャ設計」に集中できる時代になりつつあり、高い品質を維持しつつ、結果整合性の恩恵を享受できる可能性が高まっています。
本記事では、システムアーキテクチャの選択がプロダクトのビジネス価値に与える影響について書いてみました。
重要なポイント
アーキテクチャ設計をしっかり行うことはデザインファーストな進め方とは対立しません。むしろ、両方を適切に考慮することで、真に優れたユーザー体験を持つプロダクトが生まれると思います。
技術的な選択肢を理解し、ビジネスに最適な判断に貢献をすることが、これからのエンジニアに求められる重要なスキルの一つではないでしょうか。
最後に、スパイダープラスでは仲間を募集中です。スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。最後までご覧いただき、ありがとうございます。
