• はじめに
• 1. EC2 × ALB × CloudFront でインフラコストを削減
• 2. API Gateway × Lambda × CloudFront で動的コンテンツでもコスト最適化
• 3. 単一リージョン × CloudFront でグローバル配信をシンプルに
• まとめ：CloudFrontは単なる「CDN」ではない！

はじめに

AWSでシステムを構築する時、「とりあえずEC2インスタンスを建てて終わり」としていませんか？もしかするとコストやパフォーマンス、セキュリティで損をしてしまっているかもしれません。特にWebサイトやAPIを外部に公開しているケースでは、Amazon CloudFront（CDN※1）を導入するだけで、AWSコストを削減できる可能性があります。

本記事では、CloudFrontを活用できていない典型的なアンチパターンをもとに、推奨アーキテクチャをご紹介いたします。また、AWSセキュリティ関連サービス（WAF等）やDNS周り（Route53等）は扱わないものとします。

※1 : CDN = Contents Delivery Network（コンテンツ配信ネットワーク）

1. EC2 × ALB × CloudFront でインフラコストを削減

「ALBとEC2で稼働する一見シンプルな構成なのに、なぜかAWSコストが高い...」このようなお悩みは意外と多いのではないでしょうか？

アンチパターン

• EC2インスタンスをターゲットに持つALBをインターネットに直接公開
• API等の動的処理だけではなく、画像等の静的コンテンツも全てALBを経由してEC2インスタンスが処理
• 結果としてALBのデータ処理料金が高騰&EC2インスタンスのCPU使用率が増大

図1-1

推奨アーキテクチャ

• ALBより前段にCloudFrontディストリビューションを配置
• 画像等の静的コンテンツはCloudFrontディストリビューションでキャッシュ
• API等の動的処理は短めにTTLを設定してキャッシュ

図1-2

導入効果

• キャッシュによりALBとEC2が受けるリクエスト総数が減少
  • ALBのデータ処理料金が削減可能！
  • EC2インスタンスのCPU使用率が緩和
    • スケールダウンが可能になり、固定費も削減可能！
• キャッシュによりEC2インスタンスのCPU使用率が安定
  • システム全体でパフォーマンスが軽快に！

2. API Gateway × Lambda × CloudFront で動的コンテンツでもコスト最適化

「なんとなくAPI GatewayとLambdaでサーバレスを構成しているけど、なんだかAWSコストが高いな...」そのようなお悩みはございませんか？

アンチパターン

• Lambda関数をターゲットに持つAPI Gatewayをインターネットに直接公開
• 全リクエストがAPI Gatewayを経由してLambda関数を都度起動
• 結果としてAPI Gateway・Lambdaそれぞれの利用料金が高騰

図2-1

推奨アーキテクチャ

• API Gatewayより前段にCloudFrontディストリビューションを配置
• API等の動的処理は短めにTTLを設定してキャッシュ

図2-2

導入効果

• キャッシュによりAPI GatewayとLambdaが受けるリクエスト総数が減少
  • API Gateway・Lambdaそれぞれの利用料金が削減可能！
• キャッシュによりバックエンドへの到達回数を最小化
  • システム全体でパフォーマンスが軽快に！

3. 単一リージョン × CloudFront でグローバル配信をシンプルに

「支社が海外にあるから、なんとなく複数リージョンにデプロイしてみたけど、管理が大変でAWSコストもかさむな...」そのような状況、ございませんか？

アンチパターン

• 海外に支店があるから等の理由で、特に意図せず複数リージョンに同一システムをデプロイ
• 各リージョンにてAWSインフラ環境を個別で運用
• 結果として運用コストが増大&リソース重複によるインフラ費用が高騰

図3-1

推奨アーキテクチャ

• マルチリージョンではなく単一リージョンにシステムを集約
• 前段にCloudFrontディストリビューションを配置して、世界中にコンテンツを高速配信
• 1システムにアクセスが集中するが、こちらはキャッシュで吸収

図3-2

導入効果

• 単一リージョンに統一することでAWSリソースの無駄な重複を大幅に低減
  • 運用コストおよびインフラ費用が約半分まで削減可能！
• キャッシュによりバックエンドへの負荷を抑制
  • 今までと変わらないユーザ体験を提供！

まとめ：CloudFrontは単なる「CDN」ではない！

本記事で紹介しましたように、CloudFrontは単なる「CDN」ではなく、パフォーマンスやセキュリティを最適化しつつコストを削減する強力なツールです。AWSでシステムを設計する際は、まず「前段にCloudFrontを配置できないか？」を検討してみてください。

それだけで、アンチパターンから脱却し「費用対効果が高いアーキテクチャ」への第一歩を踏み出せるでしょう。

1. 1. はじめに
2. 2. 公式GitHub MCPサーバーを使ってみよう
3. 　2-1. 準備フェーズ
4. 　　①GitHubでPersonal Access Tokenを作成
5. 　　②VS CodeにMCPサーバ情報を設定
6. 　　③作業対象のサンプルプロジェクトを作成
7. 　2-2. 実行フェーズ
8. 3. まとめ

• はじめに
• シナリオ：ネットワーク制御要件を満たすための設計
• 適材適所の判断をする
• コスト最適化の視点
• まとめ

はじめに

AWSでは、あらゆるユースケースを支える豊富なサービス群が提供されています。 しかし、その選択肢の多さゆえに「本当に必要な要件以上のサービスを導入してしまう」ケースも少なくありません。

特に、非機能要件に対して、必要以上に複雑な構成を採用してしまうと、以下のようなデメリットにつながることがあります。

• AWSコストの増大
• 運用負荷の上昇
• トラブルシューティングの難化

本記事では、過剰設計の一例を通して、コスト最適化やシンプルな設計の重要性を考えます。

シナリオ：ネットワーク制御要件を満たすための設計

想定要件

あるシステムで、次のような非機能要件が挙がったとします。

• 「WebサーバからのみDBサーバに接続を許可したい」
• 「SSH接続を特定のグローバルIPアドレスからのみ許可したい」

この要件は非常に一般的です。しかし、このようなシンプルなネットワーク制御要件に対して、意図せず次のような構成を取っていないでしょうか？

過剰な構成の例

• とりあえずAWS Network Firewallを導入

図1

一見「セキュリティを強化した構成」に見えますが、実際には Security Groupだけで十分なケースも多く存在します。

適材適所の判断をする

Security Group で十分なケース

• 同一VPC内のAWSサービス間通信制御
• L3/L4（ネットワーク/トランスポート層）レベルのアクセス制御

図2

これらはステートフルな通信制御が可能な Security Group で実現可能です。 設定も容易で、コストも追加料金なしです。

AWS Network Firewall が必要なケース

一方、AWS Network Firewall が適しているのは次のようなケースです。

• L3/L4（ネットワーク/トランスポート層）レベルからL7（アプリケーション層）レベルまでのアクセス制御が必要
• ステートフルだけではなくステートレス制御も必要
• 高度なネットワークトラフィックの検査・分析が必要

※以下はAWS Network Firewallを導入する大まかなイメージです。

引用 : Network Firewall deployed with AWS managed rules（2025/11/09時点）

これらは単純なSecurity Groupでは対応が難しい要件です。 AWS Network Firewallの導入は、こうした明確な理由がある場合に初めてコストに見合った効果を発揮します。

コスト最適化の視点

AWS Network Firewallは強力なサービスですが、利用するたびにオンデマンド料金が発生します。1つのVPCにデプロイしただけでも、Firewall Endpoints利用料金が継続的に発生します。

単に「セキュリティを強化したいから」といった曖昧な理由で導入してしまうと、月額数万円〜数十万円規模のコストが恒常的に発生するケースもあります。

さらに、アクセス数が多いかつ大きなデータを扱うシステムの場合には、データ処理料金も月額数万円規模で発生する可能性があります。

シンプル設計を意識する

非機能要件に対しては、まず最小限の構成で実現可能かを検討することが重要です。Security Groupで要件を満たせるのであれば、まずはそこから始めてみましょう。

まとめ

• 非機能要件に対して、本当にそのAWSサービスが必要かを見直す
• Security Groupなどの無料で提供される基本機能を活用する
• AWS Network Firewallなどの高機能サービスは明確な根拠がある場合に導入する
• コスト最適化は設計段階から意識する

AWSの設計に「正解」はありませんが、「なぜその構成にしたのか」を説明できることが、アーキテクトとして最も重要なスキルです。

1. はじめに
2. SSM統合コンソールによる一元管理
3. OSなど構成情報の可視化
4. Patch Managerによるパッチ運用の標準化
5. 証明書有効期限の集中監視と自動通知
6. 導入効果と業務改善イメージ
7. 導入時の設計上の留意点
8. 継続的改善を支える「運用の仕組み化」

1.はじめに

クラウド活用が拡大し、AWS環境が複数アカウントで利用されたり、複数システムにまたがって利用されることは、システム運用における構成の一貫性を維持することの難易度を高めています。

特に、チームや事業部ごとに異なる運用ルールが存在する環境では、OSやミドルウェアのバージョンが混在し、パッチ適用や証明書更新のタイミングが統一されないなどの問題が頻発します。これらの状況が続くと、セキュリティリスクの増大や監査対応工数の肥大化につながるだけでなく、継続的な改善活動を阻害する要因ともなります。

本記事では、複数のAWSアカウントを運用する環境においてAWS Systems Managerを中心に、AWS Config AggregatorおよびAWS Organizationsを組み合わせることで、OS・インストールパッケージの構成管理、パッチ適用・証明書管理といった運用を統合的に管理し、標準化されたセキュリティ運用を実現するためのアーキテクチャと考え方を解説します。

2.SSM統合コンソールによる一元管理

AWS Organizations配下で複数のアカウントを運用する場合、各環境を独立して管理するのではなく、中央集権的な監視・統制基盤用のアカウントに情報を集約する構成が有効です。情報集約の中核を担うのがAWS Systems Manager（以下、SSM）です。

各アカウントに配置されたEC2インスタンスや関連リソースの構成情報（OS・ソフトウェア構成情報）をアカウント内のSSM Inventoryで収集します。各アカウントから、SSMにて「委任」の設定を行う（※1、※2）ことで、集約用アカウント（以下SSM委任アカウント）にSSM Inventoryで収集した情報が連携され、SSM委任アカウントの統合コンソールにてアカウント横断的に情報を確認できるようになります。

※1．委任の設定はAWS Organizationsを利用していることが前提です。

※2．AWS Organizations管理アカウントをSSM委任アカウントに指定することは現時点（2025年11月）ではできません。また、Organizations管理アカウント内のリソースはSSM委任アカウントでの一元管理の対象にできません。

AWS Organizations×Systems Manager活用イメージ

3.OSなど構成情報の可視化

SSM Inventoryは、インスタンス上のOSやアプリケーション、パッケージのバージョン情報などを自動的に収集し、最新の構成状態を可視化する機能です。これにより、どのサーバーがどのバージョンで稼働しているのかを即座に把握でき、環境全体の構成ドリフトを早期に検出することが可能となります。収集された全ノードの情報はSSM委任アカウントに連携されます。また、SSM委任アカウントから はResource Data Syncを利用してS3に同期することができます。S3に同期されたデータに対してAmazon Athenaでクエリを実行し、結果をQuickSightに連携することでアカウントを横断して構成情報を集計・可視化・分析することができます。これにより、監査対応時には全システムの構成一覧を迅速に生成でき、コンプライアンス報告の効率化にも寄与します。

引用：複数の AWS アカウント とAWS リージョン とのリソースデータ同期（2025/10/14 時点）

後述のパッチポリシーの遵守状況を含め、AWSリソースのコンプライアンス準拠状況は、各アカウントのAWS Configにてチェックされます。各アカウントからConfig委任アカウントに委任を設定することで、Config委任アカウントのAWS Config Aggregatorにてコンプライアンス準拠状況を一元管理できるようになります。適用すべきパッチ（Patch Baselineにて定義）の未適用など、ルール非準拠が検出された場合はAWS ConfigからEventBridgeを介してSNSで通知します。

4.Patch Managerによるパッチ運用の標準化

システムの脆弱性対策において、パッチ管理の一貫性は極めて重要です。SSM Patch Managerを利用すれば、OSやアプリケーションに対するパッチ適用をルール化し、自動的に実行することが可能です。

例えば、検証環境では毎週土曜日の深夜に最新のセキュリティ更新を適用し、本番環境では日曜日のメンテナンス時間帯に検証済みのパッチのみを適用するといったポリシーを柔軟に設定できます。適用結果はS3に記録されます。未更新インスタンスが存在する場合は非準拠のリソースとしてAWS Configで検出され、EventBridge、SNSを介して管理者に通知されます。これにより、パッチ適用漏れを防ぎつつ、更新状況を定量的に追跡できるようになります。

パッチポリシーはSSM委任アカウントにてクイックセットアップを利用して作成し、各アカウントに共通で適用することが可能です。少ない設定で、Organizations全体やOU単位、アカウント単位など柔軟な範囲に、必要なパッチポリシーを割り当てることができます。ただしリージョンによっては非対応（例：2025年10月時点では大阪リージョンは非対応）のため、非対応のリージョンを利用している場合や、より細かい制御を検討したい場合にはCloudFormation StackSetsを利用したポリシー展開を検討します。

パッチ自動適用の構成例（CloudFormation StackSets利用）
引用：複数の AWS アカウントとリージョンのパッチソリューション設計（2025/10/14 時点）

5.証明書有効期限の集中監視と自動通知

運用現場で発生しやすいインシデントの一つに「証明書の期限切れによるサービス停止」があります。AWS Certificate Manager（ACM）で管理されている証明書について、マネージドの証明書であればいくつかの条件を満たす必要はありますが、自動更新を利用可能です。まずは自動更新の利用を検討し、ヒューマンエラーによる証明書有効期限切れを予防しましょう。

マネージド証明書の更新

自動更新が利用できない場合、AWS Configのマネージドルールにて期限接近を検出可能です。例えばConfigルールによって30日以内に期限切れとなる証明書を検出し、EventBridgeを経由してSNS経由で通知を発行する仕組みを構築すれば、担当者は証明書が期限切れとなる前にSlackやメールでアラートを受け取ることができます。これにより、証明書の残存日数やドメイン名、ARNといった情報が定期的に共有され、運用上のヒューマンエラーを未然に防止できます。

証明書有効期限監視と自動通知フロー 構成例

6.導入効果と業務改善イメージ

これらの仕組みの導入により、運用効率が改善されます。例えば、従来は月20時間かかっていたパッチ適用作業が3時間に短縮され、証明書更新ミスは年間数件からゼロ件に減少します。

また、環境監査の準備期間は約10日から1日以内に短縮され、運用担当者間の情報差異も減少し、日常的な保守対応の削減が実現されます。

7.導入時の設計上の留意点

運用の仕組みを効果的に機能させるために、設計上のポイントを押さえる必要があります。

事前にAWS OrganizationsとOUの設計を整理し、Patch Managerの適用範囲を明確にすることが必要です。

次に、SSM Agentの自動展開を徹底し、未導入のインスタンスを発生させない（= 導入カバレッジを上げる）ことも大切です。そのためには、Launch TemplateやTerraformなどのIaCツールのテンプレートにSSM Agent設定を組み込む運用が推奨されます。

また、SNSによる通知チャネルはSlackやメールなど複数の経路に対応できるよう柔軟に設計し、IaC（Infrastructure as Code）によってPatch BaselineやConfigルールをコード化することで、変更履歴をGitなどの構成管理ツールで追跡可能にし、構成の再現性を高めることも効果的です。

8.継続的改善を支える「運用の仕組み化」

AWS Systems ManagerとConfig Aggregatorを活用した一元管理は、単なる自動化の実現ではなく、持続可能な運用体制そのものの設計を意味します。これにより、OS・パッチ・証明書といった重要要素の更新状況を即時に把握し、構成情報やセキュリティ設定を統合的に監査する仕組みを確立できます。さらに、運用チーム間の情報共有を自動化することで、システムの信頼性とセキュリティを高い水準で両立させることが可能になります。

最終的に、保守運用チームは障害対応や手作業の更新から解放され、改善や機能追加など、システムの価値を高める業務に集中することができます。これこそが、AWSによる運用の仕組み化がもたらす最大の価値であり、組織全体の運用品質を継続的に向上させる基盤と考えています。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. 1. はじめに
2. 2. MCPとは(一般論)
3. 3. 実際に触ってわかったこと: よくある誤解
4. 　3-1. MCPサーバーの誤解
5. 　3-2. MCPクライアントの存在
6. 4. MCPを導入する前に知っておくべきこと
7. 　4-1. 実現できること
8. 　4-2. リスクと注意点
9. 5. まとめ
10. 6. おまけ：現状と今後の展望についての極めて個人的な考察
11. 7. 参考資料

1. はじめに
2. 可用性設計の基礎：リージョンとAZの仕組みを理解する
3. 止まらない設計を妨げる単一点障害：単一AZ構成の限界
4. マルチAZ構成：同一リージョン内での止まらない仕組み
5. マルチリージョン構成：事業継続（BCP）のための冗長化
6. まとめ：設計段階で「どこまで止めないか」を決めよう

1. はじめに

AWSは、数クリックで仮想サーバー（EC2）を立ち上げられるなど、手軽にサービスを構築できるクラウドです。システム企画や開発の初期段階では「とりあえず動いているから大丈夫」と感じてしまうことも多いかもしれません。しかし、「動作確認ができた」＝「安全に運用できる」とは限りません。停電や災害などが発生した場合にも「止まらないこと」や「早期復旧できること」が事業継続計画（BCP）の観点では重要です。
本記事では、システム企画者向けに「可用性設計」の考え方をアベイラビリティゾーン（AZ）、リージョン、事業継続計画（BCP）の3つの視点から整理します。

2. 可用性設計の基礎：リージョンとAZの仕組みを理解する

AWSでは、サービスを提供する地理的な単位を「リージョン（Region）」と呼びます。例えば、東京（ap-northeast-1）、米国バージニア北部（us-east-1）、欧州ロンドン（eu-west-2）など、各リージョンは世界中に分散しています。
各リージョンの中には複数の「アベイラビリティゾーン（Availability Zone：AZ）」が存在し、AZは「物理的に独立したデータセンター群（電力・冷却・ネットワークが分離）」として設計されています。例えば、東京リージョン（ap-northeast-1）には2025年11月時点で3つのAZ（1a、1c、1d）が存在します。（参考：AWSグローバルインフラストラクチャ）

AZが同一地域内にありながら物理的にも論理的にも分離された拠点となっているのは、クラウドの「高可用性（High Availability）」を支える基礎となっています。例えば、東京リージョン（ap-northeast-1）のAZ（1a）で停電などの障害が発生しても、他のAZ（1c、1d）は稼働し続けられる設計になっています。この構造を理解することが可用性設計を考える第一歩です。

3.止まらない設計を妨げる単一障害点：単一AZ構成の限界

AWSでは最小構成であれば1つのAZにEC2とRDSを立てる単一AZ構成でも動作しますが「とりあえず動く」便利さが落とし穴にもなります。もし、AZで障害が起きた場合、EC2もRDSも同時に停止してしまいます。

実際、過去には特定AZの電源障害・ネットワーク障害によって多くのサービスが影響を受けた事例もあります。例えば2025年4月15日、東京リージョン（ap-northeast-1）のアベイラビリティゾーン(ap-northeast-1a)で障害が発生しました。（参考：AWSヘルスダッシュボード）当該AZで起動されたEC2インスタンスや、影響を受けたEC2インスタンスを利用する他のAWS APIで、エラー率やレイテンシーの増加など影響が及んだことが報告されました。

単一AZ構成のような「とりあえず動く構成」は将来的にはリスクを増やすことを認識し、障害発生でシステム全体が停止してしまう「単一障害点」を極力なくすことが重要です。

4.マルチAZ構成：同一リージョン内での止まらない仕組み

AZが物理的に独立したデータセンター群として構成されている仕組みを活かせば、1つのAZに障害が発生しても、別のAZでサービスを継続することができます。同一リージョン内で複数のAZにリソースを配置することで、片方に障害が起きても、もう一方で稼働を継続できる「マルチAZ構成」が可用性設計の第一歩です。

例えば、前節で例に挙げた「1つのAZにEC2とRDSを立てる」単一AZ構成は、LB、AutoScalingやRDS（プライマリ・スタンバイ）を使ってマルチAZ構成にすることができます。以下のマルチAZ構成例では、単一AZに配置したリソースの大きな1サーバで全リクエストを捌くのではなく、小さいサイズのインスタンスをマルチAZに配備して負荷分散およびオートスケーリングをして同じ量のリクエストを捌くようにすることで、1つのAZに障害が発生した場合にも自動回復力の高いサービスを提供することができます。
また、「RDS（マルチAZ）」では、AWSが自動的に別のAZに「待機用（スタンバイ）DB」を複製してくれます。もしプライマリ側のAZで障害が発生しても、AWSが自動的にスタンバイDBへ切り替えてくれるため、データベースの可用性を確保できます。

マルチAZ構成は、ALBやレプリカといった追加リソースの配置が必要になるケースが多くコストが増加する傾向はありますが、「システムが止まらない」安心を比較的低コストで得られる現実的な方法です。

マルチAZ構成例 (引用：3つのAZにデプロイされる多階層アーキテクチャ）

よくあるマルチAZ構成例

5.マルチリージョン構成：BCP（事業継続）のための冗長化

マルチAZ構成で防げないのが「地域全体の障害」です。地震・大規模停電など、AZ単位ではなくリージョン単位で影響が及ぶケースでは「マルチリージョン構成」が有効となります。例えば、東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）を組み合わせるケースが代表的です。
以下の手法を組み合わせることで、片方のリージョンが完全停止しても他方で業務を継続できる仕組みを作ることができます。マルチリージョン構成はコスト・運用負荷も大きくなりますが、金融・医療・公共系など「止まってはいけない」領域では必須の戦略です。

代表的なマルチリージョン設計手法

6.まとめ：設計段階で「どこまで止めないか」を決めよう

最後に、AWSにおける可用性設計を整理すると、以下の3段階に分かれます。

1. 単一AZ構成：開発やテストなど、短期的利用に最適
2. マルチAZ構成：一般的な商用システムの信頼性確保
3. マルチリージョン構成：ミッションクリティカルシステム向け

システム企画者が意識すべきことは「どのレベルの可用性を求めるか」を企画の初期段階で明確にすることです。運用が始まってからの再構築は、コスト・工数・ダウンタイムの面で非常に負担が大きくなるため、企画段階で「どこまで止めないか」を決め、開発・運用チームと共通認識を持つことが大切です。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

1. はじめに
2. 環境構築
3. AI に実装を依頼する
4. 所感
5. まとめ

1. はじめに

こんにちは。エンジニアの齋藤です。

昨今のSNSでは、ChatGPTやClaudeを使ってアプリを作ったという報告を目にすることがあります。一方で、「どんな手順で進めればいいのか」「どこまでAIに任せて、どこから自分で考えるべきか」 といった具体的なプロセスについては、まだ体系的な情報が少ないように感じます。

本記事では、Apple が Xcode 26 で導入した Claude統合機能 を活用し、実際にTODO管理アプリを作る過程を通じて、AIを使った開発の実態を具体的に解説 します。非エンジニアの方でも実践できるよう、環境構築から完成まで、すべてのステップを詳細に記載しました。

AI開発の可能性を体感していただくことで、チームの生産性向上や新規事業の迅速な検証といった、新しいアプローチのヒントを得ていただければ幸いです。

1-1. この記事で分かること

• Claude統合機能を利用したiOSアプリ開発環境の構築手順
• 非エンジニアでも理解できる開発フロー
• 実際に使えるTIPS

1-2. この記事では割愛すること

• Swift/SwiftUIの詳細な文法説明
• UIデザインの詳細
• App Storeへの公開手順
• CLAUDE.mdなどを利用したチーム開発での運用

1-3. 対象読者

• 非エンジニア: 自分でもアプリ開発してみたい方
• iOS開発初心者: AI支援機能を利用してiOS開発を学習したい方
• iOSエンジニア: 最新のAI支援開発を体験したい方
• プロジェクトマネージャー: AI開発の実態を把握したい方

1-4. 今回作成するアプリ

シンプルなTODO管理アプリを作成します。

主な機能

• TODO の作成・編集・削除
• 完了/未完了の切り替え
• 期日設定と期限アラート(色分け表示)
• ステータス管理(未着手/処理中/作業完了/完了)
• ドラッグ&ドロップでの並び替え
• データの永続化(アプリを閉じても保存)

所要時間
約 2〜3 時間(環境構築含む)

2. 環境構築

今回の検証に利用したMac、およびツールのスペックは以下の通りです。

2-1. Xcode のインストール

1. App Storeアプリ を開く
2. 検索で「Xcode」を入力
3. 「入手」をクリック
4. ダウンロード完了まで待つ (10GBほどあるため、回線速度によっては30分ほどかかる場合があります)

2-2. Claude統合機能 の設定

Xcodeを起動して、設定画面を開く

1. メニューバーから Xcode > Settings... をクリック(⌘,)
2. 設定ウィンドウが開きます
3. 左メニューのIntelligenceを選択

Claudeアカウントでログイン

1. 「Sign In...」をクリックして、お手持ちのClaudeアカウントで認証してください
2. 接続要求の画面が表示されたら、「承認する」をクリック

2-3. プロジェクトの作成

新規プロジェクトを作成

1. Xcode を起動
2. "Create New Project" をクリック
3. テンプレート選択画面で:
   • iOS を選択
   • App を選択
   • Next をクリック

プロジェクト設定

以下の項目を入力します:

※ Organization Identifier は逆ドメイン形式(com.会社名.アプリ名)が一般的ですが、個人開発なら jp.yourname.SampleTodoApp のような形式で問題ありません。

プロジェクトの保存先を選択

1. 任意のフォルダを選択
2. "Create Git repository" にチェック(バージョン管理用、推奨)
3. Create をクリック

これでプロジェクトが作成され、Xcode のメイン画面が開きます。

3. AI に実装を依頼する

ここから実際に実装していきます。直接コードを書かずに アプリを完成させます。

3-1. 開発フロー

下記の開発フローで進めます。
肝は、要件定義をもとに全体を一括実装したあとに、個別に細かい部分を修正していくというところになります。

1. 要件定義(必要に応じて設計レベルまで)を作成する
2. 前段で作成した要件定義をXcodeのCoding Assistantに読み込ませる
3. Coding Assistantがコードを自動生成
4. シミュレータで実行
5. エラーや想定と異なる箇所があれば、個別にCoding Assistant経由でコードを修正

3-2. 要件定義の作成

まずは、作りたいアプリの要件を整理します。これが最も重要なステップです。

※ 重要: 要件定義の作成自体も、生成AI(ClaudeやChatGPT)を積極的に活用しましょう。アイデアを箇条書きで伝えるだけで、AIが構造化された要件定義を作成してくれます。

要件定義の作り方

アイデアを簡単に箇条書きする

まず、作りたいアプリのイメージを箇条書きで整理します:

作りたいアプリ: TODO管理アプリ

基本的な機能:
- TODOの追加・編集・削除
- 完了/未完了の管理
- 期限の設定
- 並び替え

欲しい機能:
- ステータス管理(未着手、処理中など)
- 期限が近いTODOを色分け表示
- データはアプリを閉じても保存される

AIに要件定義の作成を依頼

上記の箇条書きを Claude に渡して、要件定義書を作ってもらいます:

以下のアイデアをもとに、iOSアプリ開発用の詳細な要件定義書を作成してください。

【要件定義書に含めてほしい項目】
- アプリ概要
- 機能要件(画面ごとに整理)
- UI/UX仕様
- データ管理(データモデル、永続化方法)
- 技術仕様
- 画面フロー
- ファイル構成

【アイデア】
[上記の箇条書きを貼り付け]

SwiftUIを使用したネイティブiOSアプリとして実装したいです。

生成された要件定義を確認・修正

AIが生成した要件定義を確認し、必要に応じて修正を依頼します:

要件定義ありがとうございます。
以下の点を修正してください:

- ステータスは4段階(未着手/処理中/作業完了/完了)にしたい
- 期限が過ぎたTODOは赤、3日以内は橙色で表示したい
- ドラッグ&ドロップで並び替えできるようにしたい

このように、対話しながら要件定義を磨き上げることで、非エンジニアでも実装可能なレベルの詳細な仕様書が完成します。

完成した要件定義のサンプル

上記のプロセスで作成された要件定義の例を以下に示します:

# SampleTodoApp 要件定義書

## 1. 概要

### 1.1 アプリケーション名
SampleTodoApp

### 1.2 目的
日々のタスクを効率的に管理するためのTODO管理アプリケーション。作成、編集、削除、ステータス管理などの基本機能を備えたiOSネイティブアプリケーション。

### 1.3 対象プラットフォーム
- iOS（SwiftUI使用）

---

## 2. 機能要件

### 2.1 TODO一覧表示機能

#### 2.1.1 基本表示
- TODOアイテムをリスト形式で表示
- 各アイテムに以下の情報を表示：
  - タイトル
  - 完了/未完了チェックボックス
  - ステータスバッジ（カラー付き）
  - 作成日
  - 期日（設定されている場合）

#### 2.1.2 空状態
- TODOが0件の場合、空状態画面を表示
- メッセージ：「TODOがありません」
- システムアイコン：checklist
- 説明文：「右上の + ボタンで新しいTODOを追加してください」

#### 2.1.3 期日表示の色分け
- **赤色**：期日超過
- **オレンジ色**：期日まで3日以内
- **グレー色**：通常（4日以上先）

#### 2.1.4 完了済みアイテムの表示
- タイトルに取り消し線を表示
- チェックマークアイコンを緑色で表示
- テキストカラーをセカンダリカラーに変更

### 2.2 TODO追加機能

#### 2.2.1 入力項目
**基本情報セクション：**
- タイトル（必須）：テキストフィールド
- ステータス：ピッカー（デフォルト：未着手）

**日付セクション：**
- 作成日：日付ピッカー（デフォルト：現在日時）
- 期日設定トグル
- 期日：日付ピッカー（トグルON時のみ表示、作成日以降の日付のみ選択可能）

**説明セクション：**
- 説明：テキストエディター（複数行入力可能、高さ150〜200pt）

#### 2.2.2 バリデーション
- タイトルが空の場合、保存ボタンを無効化
- 保存ボタンの背景色を変更（無効時：グレー、有効時：ブルー）

#### 2.2.3 UI構成
- ナビゲーションタイトル：「新規TODO」
- キャンセルボタン（左上）
- 保存ボタン（画面下部固定、フルワイド）
- スクロール可能なフォーム部分

### 2.3 TODO編集機能

#### 2.3.1 編集可能項目
- タイトル
- ステータス
- 期日（設定/解除/変更）
- 説明

#### 2.3.2 編集不可項目
- 作成日（表示のみ、グレーアウト）

#### 2.3.3 UI構成
- ナビゲーションタイトル：「TODOを編集」
- キャンセルボタン（左上）
- 削除ボタン（右上、赤色のゴミ箱アイコン）
- 保存ボタン（画面下部固定）

#### 2.3.4 削除機能
- 削除ボタンタップ時、確認アラートを表示
- アラートメッセージ：「『[タイトル]』を削除しますか？この操作は取り消せません。」
- ボタン：「キャンセル」「削除」（破壊的アクション）

### 2.4 TODO操作機能

#### 2.4.1 完了/未完了切り替え
- チェックボックスタップで即座に状態を切り替え
- アニメーション付きで表示を更新

#### 2.4.2 並び替え
- 編集モード時にドラッグ&ドロップで順序変更可能
- 変更内容は自動保存

#### 2.4.3 削除
- スワイプ削除に対応
- 編集モード時の削除ボタンにも対応

#### 2.4.4 詳細表示
- リストアイテムタップで編集画面へ遷移

### 2.5 データ管理機能

#### 2.5.1 データ永続化
- UserDefaultsを使用してデータを保存
- JSON形式でエンコード/デコード

#### 2.5.2 自動保存タイミング
- TODO追加時
- TODO更新時
- TODO削除時
- TODO並び替え時
- 完了状態変更時

---

## 3. データモデル

### 3.1 TodoItem構造体

```swift
struct TodoItem: Identifiable, Codable {
    let id: UUID                // 一意識別子
    var title: String           // タイトル（必須）
    var isCompleted: Bool       // 完了フラグ
    let createdAt: Date         // 作成日時
    var dueDate: Date?          // 期日（オプショナル）
    var description: String     // 説明
    var status: TodoStatus      // ステータス
}
```

### 3.2 TodoStatus列挙型

4つのステータスを定義：

| ステータス | 表示名 | カラー | 
|-----------|--------|--------|
| notStarted | 未着手 | グレー |
| inProgress | 処理中 | ブルー |
| workCompleted | 作業完了 | オレンジ |
| completed | 完了 | グリーン |

---

## 4. UI/UX要件

### 4.1 画面構成

#### 4.1.1 一覧画面（ContentView）
- NavigationView構造
- ツールバー：
  - 左側：編集ボタン（日本語表示）
  - 右側：追加ボタン（+アイコン）
- リスト表示エリア
- 上部セーフエリアに16ptのスペーシング

#### 4.1.2 追加/編集画面
- NavigationStack内でシート表示
- ScrollView + Form構造
- 固定された下部ボタンエリア
- フォーム最小高さ：700pt

### 4.2 カラースキーム
- システムカラーを使用（ダークモード対応）
- ステータスバッジの背景：対応カラーの10%透明度
- 保存ボタン有効時：ブルー
- 保存ボタン無効時：グレー
- 削除ボタン：レッド

### 4.3 アクセシビリティ
- EditButtonにロケール設定（ja_JP）を適用
- 日付フォーマットは日本語形式（yyyy/MM/dd）

---

## 5. 技術要件

### 5.1 開発環境
- 言語：Swift
- フレームワーク：SwiftUI
- アーキテクチャ：MVVM
- 非同期処理：Swift Concurrency（MainActor使用）

### 5.2 使用技術
- **データバインディング**：@Published, @StateObject, @ObservedObject
- **ナビゲーション**：NavigationView, NavigationStack
- **モーダル表示**：Sheet
- **状態管理**：@State, @Environment
- **データ永続化**：UserDefaults + Codable

### 5.3 ViewModel（TodoViewModel）
- @MainActorで宣言（UIスレッドで実行）
- ObservableObjectプロトコル準拠
- 提供メソッド：
  - `addTodo()` - TODO追加
  - `updateTodo()` - TODO更新
  - `deleteTodo()` - TODO削除
  - `moveTodo()` - TODO並び替え
  - `toggleCompletion()` - 完了状態切り替え

---

## 6. 制約事項

### 6.1 データ保存
- UserDefaultsを使用するため、大量データには不向き
- データ容量制限に注意

### 6.2 日付選択
- 期日は作成日以降の日付のみ選択可能
- 作成日は編集不可

### 6.3 バリデーション
- タイトルが空の場合は保存不可

---

## 7. 今後の拡張可能性

### 7.1 検討される機能
- カテゴリー/タグ機能
- 検索・フィルター機能
- 優先度設定
- 通知機能（期日アラート）
- iCloudによるデータ同期
- SwiftDataへの移行（より高度なデータ管理）
- ウィジェット対応
- 添付ファイル機能

### 7.2 改善案
- オフライン対応の強化
- パフォーマンス最適化（大量データ対応）
- アニメーション強化
- アクセシビリティの向上（VoiceOver対応など）

---

## 8. 非機能要件

### 8.1 パフォーマンス
- リスト表示：スムーズなスクロール
- データ保存：同期的に実行（データ量が少ないため許容）

### 8.2 ユーザビリティ
- 直感的な操作性
- 即座のフィードバック
- エラー時の適切なメッセージ表示

### 8.3 保守性
- MVVMアーキテクチャによる責務分離
- Codableプロトコルによるシリアライズ処理
- プレビュー機能による開発効率化

---

## 9. ファイル構成

```
SampleTodoApp/
├── SampleTodoAppApp.swift      # アプリケーションエントリーポイント
├── Models/
│   └── TodoItem.swift           # データモデル定義（TodoItem, TodoStatus）
├── ViewModels/
│   └── TodoViewModel.swift      # ビジネスロジックと状態管理
└── Views/
    ├── ContentView.swift        # TODO一覧画面
    ├── AddTodoView.swift        # TODO追加画面
    └── EditTodoView.swift       # TODO編集画面
```

3-3. Claudeへの実装依頼

XcodeのCoding Assistantを表示する

左ペインのCoding Assistantをクリックします

プロンプトを入力

以下のプロンプトをCoding Assistant経由で Claude に送信すると、必要なファイルが自動生成されます。

以下の要件定義に基づいて、SwiftUIでiOS TODO管理アプリを実装してください。

【重要な指示】
1. すべてのファイルを完全な形で出力してください
2. 各ファイルのパス（例: Models/TodoItem.swift）を明示してください
3. 実装の際、適切なフォルダ構成を提案してください
4. すべてのコードにコメントを付けてください（日本語で）
5. エラーハンドリングを適切に実装してください

【要件定義】

[上記の要件定義をそのまま貼り付け]

3-4. ビルドと動作確認

ファイルが生成されたら、いよいよ実行しましょう。

ビルド

⌘ + B (Command + B) を押してビルドします。

エラーが出た場合:

1. Coding Assistantで、Claude に以下のように伝える:

発生しているビルドエラーを解消して。

2. 該当ファイルが修正される
3. 再度ビルドを実行する

※ Coding AssistantがXcode上のエラー情報などを直接読み取るため、エラー内容の添付は不要です

シミュレータで実行

1. Xcode ツールバーでデバイスを選択(例: iPhone 16e)
2. ⌘ + R (Command + R) を押す
3. シミュレータが起動

動作確認

シミュレータが起動すると、自動的にアプリが立ち上がります。
要件定義の仕様をもとに、動作確認を行いましょう。

TODO一覧 (ブランク)	TODO一覧	TODO一覧 (編集)
TODO新規作成画面	TODO編集画面

3-5. 細かい調整

動作確認後、気になる点があれば、Coding AssistantからClaudeに伝えます。

調整例:

現在のアプリでは、期日が表示される位置が少し窮屈です。
TODORowのレイアウトを調整して、期日を右端に表示するように変更してください。

指摘をClaudeへ送信 → Coding Assistantが自動修正 → 確認

このサイクルを繰り返すことで、理想のアプリに近づけます。

4. 所感

今回の開発を通しての所感をまとめます。

4-1. 要件定義が8割

曖昧な要件だと、AIは「推測」で埋めます。後から「これも欲しい」と追加すると、既存コードとの整合性が取れず大幅な修正が必要になる場合もあります。

本記事でも言及しているように、要件定義の作成自体もAIに任せることができます。ぜひ有効活用してください。

悪い例:

TODO管理アプリを作ってください

良い例:

[詳細な要件定義を提示]
- 画面構成(一覧、追加、編集)
- 各画面の具体的な機能
- データ構造(どんな情報を持つか)
- UI/UXの仕様(色分け、アニメーションなど)

4-2. 開発方針と実装規模

今回実装したアプリは比較的小さい規模だったため、「一括実装→修正」の方針を採用しました。
それでは、実装規模が大きくなったときは、どのような開発方針を採るべきでしょうか。
規模に応じて、適切な粒度で実装スコープを分割することが重要そうです。

4-3. スクリーンショットの活用

Claudeは画像解析も可能です。
言葉で説明しづらいUIの改善も、スクリーンショットで伝えることができます。

[アプリのスクリーンショットを添付]

このUIをもっと洗練させてください。
具体的には、余白を増やし、フォントサイズを調整したいです。

5. まとめ

本記事では、非エンジニアでもClaudeを活用すれば、わずか2〜3時間でiOSアプリを開発できることを実証しました。
ここで重要なのは「詳細な要件定義の作成」と「AIへの適切な指示」でした。
非エンジニアにとっても、自らアイデアを形にできる新しい可能性が開かれました。
この機会に、ぜひ他の生成AIサービスも含めて、色々お試しいただけますと幸いです。

1. はじめに
2. スティッキーセッション(Sticky Session)とは
3. Railsのセッション管理とCSRFトークン
4. スティッキーセッションを無効化し、redisにセッションを保持させる場合
5. 負荷分散とスティッキーセッションの設定 × セッションの保存場所

1. はじめに

AWS ECS上でRails on Railsで開発したWebアプリケーション（以下Railsアプリ）を運用する際、ユーザーごとのセッション管理は重要なポイントです。
負荷分散を行いたいのに、スティッキーセッションを無効にするとCSRF（クロスサイトリクエストフォージェリ）のトークンエラーが発生してしまうことがあります。「CSRFトークンエラーを避けるために、やむを得ずスティッキーセッションを有効にしている...」という状況になっていませんか？
この記事では、スティッキーセッションの設定とRailsセッションの保存場所の適切な組み合わせについて紹介します。

2. スティッキーセッション(Sticky Session)とは

AWSにおけるスティッキーセッションとは、ロードバランサー（ALB）が同じユーザーからのリクエストを常に同じサーバー（ECSタスク）へ振り分ける仕組みです。
ALBは独自に生成するCookieを用いてユーザーを識別し、前回接続したサーバーにリクエストを送ります。
ECサイトの購入フローのように、途中の入力内容を保持しておきたいステートフルなアプリや処理に便利です。

3. Railsのセッション管理とCSRFトークン

Railsではユーザーごとのセッション情報は、デフォルトでは Cookie に保存します。
またRailsはCSRF対策として、フォームに埋め込む CSRFトークン をセッションに保存し、次のリクエストで一致するか確認します。

ここで問題となるのが、スティッキーセッションを無効化した場合です。
ECSタスク間でリクエストが振り分けられると、リクエスト先のサーバーにセッションが存在せず、CSRFトークンが一致しなくなりエラーが発生します。

この問題を解決する方法が、RailsセッションをRedisなどの外部ストレージに置くことです。
Redisにセッションを保存することで、全てのサーバーが同じセッション情報を共有できるため、CSRFトークンエラーが解消されます。

4. スティッキーセッションを無効化し、redisにセッションを保持させる場合

gem 'redis-actionpack'

5. 負荷分散とスティッキーセッションの設定 × セッションの保存場所

ECSタスクを複数台使ってアプリを運用しているとき、アプリの規模やステートフル/ステートレスかどうか、またはセキュリティ制約上セッション情報を保持する場所に制限があるかなどによって、負荷分散の必要性とそれに伴うセッション管理方式が決まります。

まとめると、システムの性質や要件に応じて次のように使い分けます：

ステートフルアプリや検証環境の場合

• スティッキーセッションを有効にする
• セッションをCookieに保存

• 負荷分散のため、スティッキーセッションを無効にする
• セッションはRedisなどの外部ストレージに保存

これにより、CSRFトークンエラーを避けつつ、安定したアプリ運用が可能になります。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse