技術選定の合理性：社内SEからクラウドエンジニアへ至る技術軸の変遷と、あえて選ばなかった技術の記録

はじめに：この記事で書くのは「判断の記録」だ

転職体験記や資格取得ログは、すでに世の中に溢れている。この記事で書くのは技術判断の変遷だ——どのフェーズで、何を選択肢として持ち、何を採用し、何を捨てたか。

そして、もう一つ重要なことがある。

エンジニアの技術力は「何を使えるか」だけでは測れない。「何を、なぜ使わなかったか」を言語化できるか——この問いへの答えが、技術選定の成熟度をより正確に示す。新しいツールが登場するたびに「とりあえず試す」のは悪くない。しかし本番環境・クライアント案件・長期保守が前提になった瞬間、「流行っているから」という理由は失効する。

この記事は2章構成になっている。

前半 ── キャリア4フェーズを通じた「選定軸の変遷」。何を選んで、何を捨てたか。
後半 ── 実案件で「意識的に却下した技術」7つとその判断根拠。

第1章：選定軸の変遷 ── 4フェーズで何を選び、何を捨てたか

Phase 0：職業訓練校（2020年9月〜2021年3月）── 体系を得る

選んだもの：基礎の体系的な吸収

未経験からのスタートで最初に取り組んだのは、技術の体系を正しく掴むことだった。ネットワーク・ハードウェア・プログラミングの基礎を半年間集中的に学んだ。

このフェーズで得た最も重要な思考習慣は「OSI参照モデルで問題を分解する」ことだ。L1（物理）〜L7（アプリケーション）のどのレイヤで問題が起きているかを切り分けるこの思考は、後のインフラ障害対応で何度も直接機能することになる。

Physical → Data Link → Network → Transport → Session → Presentation → Application
                                  ↑
                         「ここまでは通っている」という
                          切り分けが障害解決の核心

捨てたもの：「広く浅く触る」学習スタイル

当時のIT学習コンテンツには「とにかく触ってみよう」という傾向があった。しかし体系なき経験は、応用が効かない。先に地図を持つことが、実務での最短経路を生む——このフェーズでその確信を得た。

Phase 1：社内SE / 私立高校常駐（2021年4月〜2022年5月）── 「運用」の現実を知る

選んだもの：Xserver（AWSではなく）

社内SEとして最初の大きな仕事は、老朽化したWebサーバー・メールサーバーのXserverへの移行だった。このプロジェクトで「技術選定とはコスト・リスク・運用負荷のバランスである」という感覚を、初めて実感を持って理解した。

移行先の選定基準（2021年当時の判断）:

Xserver を選んだ理由
  ✅ 学校の技術スタッフが独力で保守できるレベルの管理UI
  ✅ WordPress / メール / SSL が同一パネルで管理可能
  ✅ 移行手順が日本語で充実しており、ロールバック設計が立てやすい

AWSは採用せず
  ❌ 運用担当が不在になった際のリスクが高すぎる
  ❌ IAM・VPC・EC2の管理を引き継げる人材が組織内にいない

「最先端かどうか」ではなく「引き継ぎ後に誰が運用するか」——これが技術選定の第一原則として刻み込まれた瞬間だった。

選んだもの：IBM Watson × Slack ヘルプデスクBot

もう一つの大きなプロジェクトが、IBM Watson AssistantとSlack APIを組み合わせた社内ヘルプデスクBotの開発だ。2人チームで設計・開発・テスト・リリースまでを担当した。

この経験で得た技術的知見は「APIの結合設計」だ。WatsonとSlackというサードパーティAPIを組み合わせる際、エラー境界をどこに置くか・どちらのAPIが落ちても影響を局所化できるかという設計思考が必要だった。

Watson → Slack 連携アーキテクチャの思考:

[Slack Event API] → [Node.js Middleware] → [Watson Assistant]
                           ↑
               ここでエラーハンドリングを集約
               Watson API障害時 → フォールバック応答
               Slack API障害時 → ログのみ・再試行

採用判断のポイント： IBMCloudを選んだのは「当時の学校組織のMicrosoft契約とのライセンス整合性」と「Watson Assistantの日本語FAQ学習精度」が理由だった。2026年現在であれば Claude / GPT-4o + Function Calling + MCP で同等以上の構成が圧倒的に簡単に実現できる。技術選定は常に「その時点での最適解」だ。

捨てたもの：オンプレミスへの執着

この時期、「サーバーを自前で持つ」という選択肢を意識的に捨て始めた。ハードウェア障害・ライセンス管理・物理セキュリティ——オンプレの運用コストを実体験として知ったことで、クラウドへの移行が「節約」ではなく「リスクの適正化」であるという視点が生まれた。

Phase 2：独立後の技術選定（2022年6月〜）── 「再現性」と「疎結合」へ

なぜ AWS を選んだか

フリーランスとして最初に向き合った問いが「どのクラウドを主戦場にするか」だった。

選定時の比較軸:

                AWS         GCP         Azure
シェア(2024)   33%         11%         25%
中小企業採用率   ◎          △           △（Microsoft契約除く）
サービス成熟度   ◎          ○           ○
日本語ドキュメント ◎          △           ○
フリーランス案件数 ◎          △           △

AWS を選んだ決定的な理由は「中小企業での採用率」と「サービスの成熟度」だ。 個人事業主として中小企業を顧客にする場合、既存環境がAWSである確率が最も高い。移行案件でも新規構築案件でも、AWSを深く知ることが最も多くの課題に直接対応できる。

なぜ Terraform を選んだか（CloudFormationではなく）

クラウドリソースの管理をTerraformに統一した理由は、**「差分検知と冪等性」**だ。

AWSコンソールから手作業でリソースを作ると、必ず「何を作ったか」の記録が曖昧になる。Terraformを使えば：

# 状態が常にコードとして存在する
resource "aws_s3_bucket" "lp" {
  bucket = "my-lp-bucket-${var.env}"
  tags = {
    Project = var.project_name
    Env     = var.env
  }
}

# → terraform plan で「これから何が変わるか」が常に可視化される
# → 同じコードを実行すれば同じ環境が再現できる

CloudFormationではなくTerraformを選んだ理由は 「マルチクラウド・マルチプロバイダ対応」 だ。

比較軸	CloudFormation	Terraform
マルチプロバイダ対応	AWS専用	AWS・Cloudflare・GitHub等
エラーメッセージの品質	曖昧（ロールバック後に原因不明になることがある）	スタック・属性レベルで明示
State管理	AWSマネージド（変更履歴が追いにくい）	S3+DynamoDBで完全制御可能
差分プレビュー	Change Sets（UIが煩雑）	`terraform plan`（CLIで完結）

Cloudflare・GitHub・Route53などを同一のHCL記法で管理できるTerraformは、AWSオンリーなCloudFormationでは代替できない。インフラのコードベースが一元化される価値は、プロジェクトが増えるほど大きくなる。

なぜ GitHub Actions + OIDC を選んだか

CI/CDの認証方式として、アクセスキーの永続管理を最初から捨てた。

# OIDC認証: シークレットキーを一切保持しない
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
    aws-region: ap-northeast-1
    # ↑ GitHub → AWS 間でJWTを使った一時的認証
    # アクセスキーは存在しない → 漏洩リスクがゼロ

「アクセスキーを.env管理」という選択肢は、管理コストと漏洩リスクの両面で合理的でないと判断した。OIDC連携を標準にすることで、セキュリティと運用のシンプルさを同時に得られる。

Phase 3：2025年以降の選定軸 ── 「エッジ」と「AI」の統合

Cloudflare Pages + Hono へのシフト（Next.jsではなく）

静的サイト・ポートフォリオ・軽量APIの領域で、Cloudflare Pages + Honoが最適解になりつつある。理由は3つだ：

コールドスタートなし ── V8 Isolateモデルにより、低トラフィックサイトでも一貫したレイテンシ
バンドルサイズの圧縮 ── Next.jsの400KB+に対し、Honoは全ページ込みで262KB
インフラ管理ゼロ ── Cloudflare Pagesは「サーバーの概念」がない。デプロイ = git push

// Honoのルーティング: Expressライクだがランタイム依存なし
const app = new Hono()
app.get('/api/health', (c) => c.json({ status: 'ok' }))
export default app
// ↑ このコードがCloudflareの全世界PoP上で動く

Next.jsが正当化されるのは「ユーザーごとに変わるダイナミックなUI」「React Server Components」「ISRが必要な更新頻度」「既存Reactエコシステムとの密結合」が揃ったときに限られる。

AI（LLM）の開発ワークフローへの統合

Claude・ChatGPTなどのLLMを、コードレビュー・エラー解析・ドキュメント生成のワークフローに統合している。ここで重要なのは「AIに何を任せ、何を自分で判断するか」の境界設計だ：

自分が判断する領域:
  - アーキテクチャの選択（トレードオフの評価）
  - セキュリティ設計（IAMポリシー・ネットワーク境界）
  - 本番環境へのデプロイ判断

AIに委譲できる領域:
  - ボイラープレートコードの生成
  - エラーメッセージの解析と修正候補の提示
  - ドキュメントの初稿作成
  - テストケースの網羅性チェック

AIをただのコード補完として使うのではなく、「調査・検証・実装の各フェーズで役割を明確に分担する」ことが、AI活用の生産性を最大化する。

第2章：あえて選ばなかった技術とその理由

「選ばなかった技術」の記録は、技術選定の成熟度を示す。以下では、実際のプロジェクトで意識的に却下した技術を、却下理由と採用した代替とともに記録する。

1. EC2 常時起動 ── LP・静的サイトの配信基盤として

却下した理由

小規模事業者向けのLP案件で、EC2 + Nginx構成は最初から選択肢から外した。

EC2 (t3.micro) の実コスト試算:
  インスタンス料金:  ~$8.5/月
  EBS (20GB gp3):   ~$1.6/月
  データ転送:        ~$0.5/月 (少量)
  ────────────────────────────
  合計:             ~$10.6/月 = 年間約 $127

S3 + CloudFront の実コスト:
  S3 ストレージ:    ~$0.023/GB  → 100MB = $0.003/月
  CloudFront:      ~$0.01/1万リクエスト
  ────────────────────────────
  合計:             ~$1〜3/月 = 年間約 $12〜36

コストだけではない。EC2を選んだ場合、以下の運用タスクが継続的に発生する：

OSパッチ適用：カーネル更新・セキュリティパッチの定期適用
Nginxのバージョン管理：CVE対応のたびに再起動が必要
ディスク容量監視：ログローテーション・肥大化対応
ヘルスチェックと障害対応：プロセスダウン時の手動復旧

LPは本来「コンテンツを安定配信する」だけでいい。インフラ管理タスクを発生させる構成は、要件に対してオーバーエンジニアリングだ。

採用した代替

S3（静的ホスティング）+ CloudFront（CDN）+ Lambda@Edge（問い合わせフォーム）+ SES（メール送信）

サーバーレスで高可用性・低コスト・管理ゼロを同時に実現できる。EC2が必要になるのは「ステートフルな処理」「長時間実行タスク」「特定のミドルウェアが必要な場合」に限られる。

2. AWS CloudFormation ── IaCツールとして

却下した理由

IaCを始めるにあたり、CloudFormationとTerraformを比較検討した結果、CloudFormationは採用しなかった。

# CloudFormation の典型的な記述（S3バケット1つの定義）
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "${AWS::StackName}-bucket"
      VersioningConfiguration:
        Status: Enabled

# Terraform の同等定義
resource "aws_s3_bucket" "main" {
  bucket = "${var.stack_name}-bucket"
}

resource "aws_s3_bucket_versioning" "main" {
  bucket = aws_s3_bucket.main.id
  versioning_configuration { status = "Enabled" }
}

CloudFormationを却下した具体的な理由は3点だ：

比較軸	CloudFormation	Terraform
マルチプロバイダ対応	AWS専用	AWS・Cloudflare・GitHub等
エラーメッセージの品質	曖昧（ロールバック後に原因不明になることがある）	スタック・属性レベルで明示
State管理	AWSマネージド（変更履歴が追いにくい）	S3+DynamoDBで完全制御可能
差分プレビュー	Change Sets（UIが煩雑）	`terraform plan`（CLIで完結）

特に致命的だったのはマルチプロバイダ対応のなさだ。Cloudflare DNS・GitHub Actionsのシークレット・Route53を同一のHCLで管理できるTerraformは、AWSオンリーなCloudFormationでは代替できない。

3. AWS Amplify ── フロントエンドホスティングとして

却下した理由

Amplifyは「フルスタック開発を簡単に」という価値提案が強力だ。しかし実際のLP案件での採用を見送った。

却下の核心は**「Amplifyのレイヤーが、問題発生時のデバッグを困難にする」**点だ。

Amplify が内部的に管理するもの:
  - CloudFront ディストリビューション
  - S3 バケット
  - IAM ロール
  - Cognito（認証使用時）
  - AppSync（GraphQL使用時）

問題: これらのリソースはAmplify CLIが管理するため、
     直接Terraformで管理できない。
     → 一部をTerraform管理、一部をAmplify管理という
       「二重管理」状態になる。

小規模LP案件では、Amplifyの提供する抽象化レイヤーが必要ない。直接S3+CloudFrontをTerraformで管理する方が、構成が透明で、トラブルシュートが速い。

Amplifyが有効なのは「Cognitoによる認証・AppSyncによるGraphQL API・React/Next.jsとの密結合」が必要な、より大規模なフルスタックアプリケーションだと判断している。

4. AWS SAM ── Lambdaのデプロイフレームワークとして

却下した理由

サーバーレス構成でLambdaを使う際、SAM（Serverless Application Model）は一見便利に見える。しかし複数プロジェクトを管理する立場では採用しなかった。

# SAM template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ContactFormFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      Events:
        Api:
          Type: Api
          Properties:
            Path: /contact
            Method: post

SAMの問題はCloudFormationの上に乗っている点だ。つまりCloudFormationの問題（マルチプロバイダ非対応・エラーの不透明さ）をそのまま引き継ぐ。

Terraformのaws_lambda_functionリソースとAPI Gatewayの組み合わせであれば、SAMと同等のことをHCL一元管理で実現できる。ツールを増やさない、という選択が長期的な保守コストを下げる。

5. Ansible ── サーバー構成管理ツールとして

却下した理由

Ansibleはオンプレ・EC2環境でのサーバー構成管理において広く使われる。しかし現在のサーバーレス主体のアーキテクチャでは、管理対象のサーバーが存在しない。

管理対象の変化:

  旧来の構成:               現在の構成:
  ┌──────────────┐          ┌──────────────────┐
  │  EC2 × 複数台  │  →      │  Lambda + S3     │
  │  Nginx設定    │          │  CloudFront      │
  │  OS設定       │          │  API Gateway     │
  └──────────────┘          └──────────────────┘
  ↑ Ansibleが有効            ↑ Ansibleの出番なし
                              Terraform が全て管理

「Immutable Infrastructure」——サーバーを設定変更するのではなく、新しいデプロイで置き換える——という設計方針を取る限り、Ansibleのような「ミュータブルな設定管理ツール」は不要になる。

6. Next.js ── ポートフォリオ・LP用途として

却下した理由

バンドルサイズとコールドスタートが許容できないケースでは選ばない。Next.jsは「動的ルーティング・SSR・大規模なフロントエンド状態管理」が必要な用途に適しており、静的コンテンツ主体のLP・ポートフォリオでは過剰な依存が問題になる。

補足として「いつNext.jsが有効になるか」の境界を記録しておく。

Next.js が正当化されるユースケース:

  必要条件（いずれか一つ以上）:
  ✅ ユーザーごとにコンテンツが変わるダイナミックなUI
  ✅ React Server Componentsによる段階的レンダリングが有効な複雑なデータフロー
  ✅ ISR（Incremental Static Regeneration）が必要な更新頻度
  ✅ 既存のReactエコシステムとの統合が必須

  却下条件:
  ❌ 静的コンテンツの配信が主目的
  ❌ クライアントサイドのインタラクションがほぼない
  ❌ チームにReact経験者がいない
  ❌ バンドルサイズ・コールドスタートをシビアに管理したい

7. Docker / ECS Fargate ── LP・軽量APIの本番環境として

却下した理由

ローカル開発環境でDockerを使うことと、本番環境でDockerを使うことは別の問題だ。

LP・問い合わせフォームのバックエンド程度のワークロードに対して、ECS/Fargate構成を採用すると：

ECS Fargate の最小構成コスト試算:
  タスク (0.25vCPU / 0.5GB) × 720h:  ~$11/月
  ALB:                                 ~$16/月
  ECR (イメージ保存):                  ~$0.5/月
  ────────────────────────────────
  合計:                                ~$27.5/月

Lambda の同等構成:
  100万リクエスト/月 以下:             ~$0.2/月
  ────────────────────────────────
  合計:                                < $1/月

Dockerコンテナが本番で有効になるのは「長時間実行プロセス・ステートフルな処理・特定のランタイム依存が必要なワークロード」だ。単なるHTTPリクエストの受け口に対しては、Lambdaの方が圧倒的にコスト・管理負荷ともに優れる。

Conclusion：技術選定の軸は「要件への解像度」

振り返ると、各フェーズでの技術選定の質は「要件への解像度」に比例していた。

フェーズ	主な選定	判断の軸
職業訓練校	OSI体系・基礎学習	体系的な知識地図の取得
社内SE	Xserver移行・Watson Bot	引き継ぎ後の運用可能性
独立初期	AWS・Terraform・OIDC	中小企業市場での再現性
現在	Cloudflare Edge・AI統合	コスト・レイテンシ・管理ゼロ

「あえて選ばなかった」理由を言語化することには、2つの実用的な価値がある。

① 次回の意思決定の速度が上がる
同じ判断を繰り返さずに済む。要件が似た案件でも「前回Amplifyを却下した理由はXだった。今回はその条件が変わるか？」という問いから始められる。

② チームやクライアントへの説明責任を果たせる
「なぜこの構成にしたか」だけでなく「なぜこの構成にしなかったか」まで答えられると、技術的な信頼性が上がる。採用面接でも「検討したが却下した」という回答の方が「そもそも知らなかった」より遥かに価値がある。

技術選定は加算ではなく減算だ。要件に対して最小の構成要素で最大の価値を出す——この原則は、インフラ設計においても、コードの設計においても変わらない。

「流行っているから」でも「使い慣れているから」でもなく、その時点での要件・制約・リスクから逆算して選ぶ——これが、技術選定の唯一の合理的な姿だ。