Floci完全ガイド｜LocalStack 代替のAWSローカル開発環境【起動24ms・29サービス・1873テスト】

この記事ではDevOps・自動化に特化して解説します。AI自動化・DevOps全般は AI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較 をご覧ください。

Floci は LocalStack 代替として注目されるGo製のAWSローカルエミュレータだ。2026年3月にLocalStack Community Editionが認証トークン必須化・セキュリティ更新の凍結へ舵を切ったことで、無料で使える軽量な選択肢を探すチームが一気に増えた。本記事では、Flociで何ができるのか、何を解決するのか、そしてLocalStackを本当に代替できるのかを、実コード付きで整理する。

Floci とは｜LocalStack 代替として選ばれるGo製AWSエミュレータ

FlociはGitHub Stars 3,300超（2026年4月時点）を獲得した、Go製のオープンソースAWSローカルエミュレータ。一言で表すなら「LocalStackの無料・軽量な代替」。MITライセンスで制限なく、起動24ms、アイドル時メモリ13MiB、Dockerイメージサイズ約90MBという軽さが最大の武器だ。

Flociが解決するのは「AWSを使うアプリの開発・テストで、いちいち本物のAWSに繋ぎたくない」という課題だ。本物のAWSに繋げば課金が発生し、ネットワーク遅延も避けられず、権限設定の手間もかかる。ローカルで完結すれば、これらがまとめて消える。AWSインフラのコスト管理にはInfracostによるデプロイ前可視化が有効だが、そもそもローカルで検証できればクラウド料金は1円も発生しない。その役割を担うのがFlociである。

Floci開発の直接的な背景には、2026年3月のLocalStack Community Editionの方針転換がある。これまで無料で気軽に使えたLocalStackが認証トークンを必須化し、無料版のセキュリティ更新を凍結する方向へ動いたことで、「トークン管理なしで、そのままdocker runできる軽量な選択肢」を求める声が一気に高まった。Flociはまさにこの空白に応えるツールで、認証トークン不要・MITライセンス・単一バイナリという設計は、旧来のLocalStackの手軽さを取り戻そうとする姿勢の表れだ。

Floci の読み方と表記ゆれ（フローシ／フロチ／フロキ）

Floci の公式リポジトリでは発音について明示されていないため、英語の音素則に従って読まれることが多い。日本語コミュニティでは表記ゆれがあり、検索クエリにも「floci 読み方」が継続的に発生している。

公式が定義していないため、ローマ字表記「Floci」のまま使うのが最も無難だ。日本語記事内で読み仮名を振るなら「フローシ」が最も普及している。発音問題でつまずく前に、29サービス対応・起動24msの実用性を体感する方が早い。なお、AWS互換ローカル開発環境としての位置付けやLocalStack 代替としての判断基準は、この後のセクションで詳説する。

Floci が対応する29サービスとアーキテクチャ｜何ができるのか

対応サービスは29。コンテナ管理ツールと組み合わせた開発スタックを組む場合はPodman TUIも参照。以下はリクエスト処理の全体像を示す。

主要サービスの対応状況（公式READMEより）。

LocalStack無料版で「Partial」とされていたDynamoDB Streams・IAM・STS・Kinesis・KMSは、Flociで完全対応。さらにLocalStack無料版が未対応のAPI Gateway v2・Cognito・ElastiCache・RDS・ECSも実装済みだ。

「何を代替できるのか」を一言でまとめると、Flociは開発・テスト段階における本物のAWSアカウントへの接続を代替する。S3にファイルを置く、DynamoDBに読み書きする、SQSでジョブをやり取りする、Lambdaを叩く——こうした一連のAWS依存処理を、課金もネットワークも介さずローカルで再現できる。特にサーバーレス構成（API Gateway + Lambda + DynamoDB + SQS）の統合テストを、1つのプロセスで完結させられるのが実務上の強みだ。

3層アーキテクチャ（Stateless / Stateful / Container）

アーキテクチャは3層構造。全サービスがポート4566で統一されているため、AWS SDKのendpoint_urlを1箇所変更するだけで既存コードがそのまま動作する。

Statelessサービス層 — SSM・SQS・SNS・IAM・STS・KMS・Secrets Manager・Cognito・Kinesis・EventBridge・CloudWatch・Step Functions・CloudFormation・EC2・SES・ACM・API Gatewayなど。HTTPリクエストを受け取り、StorageBackendに状態を委譲する。プロセス内で完結するため軽量かつ高速だ。

Statefulサービス層 — S3とDynamoDB（Streams含む）。StorageBackendは4種類：memory（揮発性・最速）、hybrid（頻出データをメモリ保持）、persistent（ディスク永続化）、wal（Write-Ahead Log方式）。

Containerサービス層 — Lambda・ElastiCache・RDS・ECS。実際のDockerコンテナを起動してエミュレーションする。Lambda/ElastiCache/RDS/ECSはIAM認証とSigV4リクエスト署名に対応。ECRはOCIレジストリを共有コンテナとして起動し、通常のdocker push/pullで利用できる。この層だけはDocker Engineが前提になる点を覚えておきたい。

Floci のインストールと基本的な使い方

最も手軽なDocker Compose構成（公式テンプレート）。

# docker-compose.yml
services:
  floci:
    image: hectorvent/floci:latest
    ports:
      - "4566:4566"
    volumes:
      - ./data:/app/data

docker compose up

# 環境変数を設定
export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

# 動作確認
aws s3 mb s3://my-bucket
aws sqs create-queue --queue-name my-queue
aws dynamodb list-tables

認証情報（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY）はtestのようなダミー値で構わない。Flociは実際の認証を行わないため、本物のクレデンシャルを設定する必要はなく、誤って本番AWSへ繋いでしまう事故も起きにくい。

SDK別インテグレーション｜Python・Node.js・Java からの接続

既存のAWS SDKコードはendpoint_url（またはエンドポイントオーバーライド）を1箇所指定するだけで動作する。アプリのロジックを書き換える必要はなく、接続先のURLを差し替えるだけなのが、移行コストの低さにつながっている。

Python（boto3）

import boto3

client = boto3.client(
    "s3",
    endpoint_url="http://localhost:4566",
    region_name="us-east-1",
    aws_access_key_id="test",
    aws_secret_access_key="test"
)

# 通常どおり操作
client.create_bucket(Bucket="my-bucket")

Node.js（AWS SDK v3）

import { S3Client, CreateBucketCommand } from "@aws-sdk/client-s3";

const client = new S3Client({
    endpoint: "http://localhost:4566",
    region: "us-east-1",
    credentials: { accessKeyId: "test", secretAccessKey: "test" },
    forcePathStyle: true,
});

await client.send(new CreateBucketCommand({ Bucket: "my-bucket" }));

Java（AWS SDK v2）

DynamoDbClient client = DynamoDbClient.builder()
    .endpointOverride(URI.create("http://localhost:4566"))
    .region(Region.US_EAST_1)
    .credentialsProvider(StaticCredentialsProvider.create(
        AwsBasicCredentials.create("test", "test")))
    .build();

6言語（Java・Node.js・Python・Go・Rust・AWS CLI）と主要IaC（Terraform/OpenTofu/CDK）向けの互換性テストが公式リポジトリに含まれており、PR単位で自動検証される。S3ではNode.jsから接続する際にforcePathStyle: trueを付けている点に注意したい。仮想ホスト形式（bucket.localhost）ではなくパス形式（localhost/bucket）でアクセスさせるための指定で、ローカルエミュレータでは実質必須になる。

Floci の環境変数・ストレージモードと設定

FLOCI_ プレフィックスの環境変数で全設定を上書きできる。

ストレージモードの選び方（memory / hybrid / persistent / wal）

FLOCI_STORAGE_MODEはFlociの挙動を大きく左右する設定だ。用途に応じて選ぶ。

・memory（デフォルト）：全データをメモリ上に保持し、プロセス終了で消える。最速で、CI/CDの使い捨て環境やユニットテストに最適
・hybrid：頻出データをメモリに保持しつつ、必要に応じてディスクへ退避する折衷案。長めのローカル開発セッション向き
・persistent：ディスクへ永続化し、再起動してもデータが残る。手元で作ったバケットやテーブルを翌日も使いたい場合に選ぶ
・wal：Write-Ahead Log方式で、書き込みの耐障害性を高める。予期しない停止でもデータ整合性を保ちたいケース向け

「テストのたびにクリーンな状態から始めたい」ならmemory、「開発データを残したい」ならpersistent、と覚えておけばまず外さない。walはデータ整合性を重視する場面、hybridはメモリと永続性のバランスを取りたい場面と、要件が明確になってから選べば十分だ。永続化する場合はFLOCI_STORAGE_PERSISTENT_PATH（デフォルト./data）にデータが書き出されるので、Docker Composeのvolumeマウントと組み合わせてホスト側に残すのが定番になる。

# マルチコンテナ構成の例
services:
  floci:
    image: hectorvent/floci:latest
    ports:
      - "4566:4566"
    environment:
      - FLOCI_HOSTNAME=floci        # URLをコンテナ名で解決
      - FLOCI_STORAGE_MODE=persistent
  my-app:
    environment:
      - AWS_ENDPOINT_URL=http://floci:4566
    depends_on:
      - floci

AWS各サービスの使い方例とトラブルシューティング

ここからは代表的なサービスを、AWS CLIを使った具体例で確認する。いずれもAWS_ENDPOINT_URL=http://localhost:4566が設定済みであることが前提だ。

S3・DynamoDB・SQS の基本操作

S3 — バケット作成、アップロード、署名付きURLの発行まで本物同様に動く。

# バケット作成とアップロード
aws s3 mb s3://assets
aws s3 cp ./logo.png s3://assets/logo.png

# バージョニングを有効化
aws s3api put-bucket-versioning --bucket assets \
  --versioning-configuration Status=Enabled

# 署名付きURL（一定時間だけ有効なダウンロードURL）を発行
aws s3 presign s3://assets/logo.png --expires-in 3600

DynamoDB — テーブル作成から項目の書き込み・読み出しまで。GSI/LSIやTTLもエミュレートされる。

# テーブル作成
aws dynamodb create-table \
  --table-name users \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

# 項目の書き込みと読み出し
aws dynamodb put-item --table-name users \
  --item '{"id": {"S": "u001"}, "name": {"S": "Taro"}}'
aws dynamodb get-item --table-name users \
  --key '{"id": {"S": "u001"}}'

SQS — キューを作り、メッセージを送受信する。StandardキューもFIFOキューも扱える。

# キュー作成・送信・受信
aws sqs create-queue --queue-name jobs
aws sqs send-message \
  --queue-url http://localhost:4566/000000000000/jobs \
  --message-body '{"task": "resize-image"}'
aws sqs receive-message \
  --queue-url http://localhost:4566/000000000000/jobs

Lambda 実行と Docker 依存の注意点

Lambdaは前述のとおりContainerサービス層に属し、実際のDockerコンテナ上で関数を起動する。そのためDocker Engineが動作していない環境ではLambdaのエミュレーションが失敗する。同様にElastiCache・RDS・ECSもDockerを必要とする。CIランナーでこれらを使う場合は、Docker-in-Docker（dind）が有効なイメージやサービス設定を選ぶ必要がある。

逆に、S3・DynamoDB・SQS・SNS・IAMなどIn-processで動くサービスだけを使うなら、Dockerなしのネイティブバイナリでも完結する。「どのサービスを使うか」で必要な前提が変わる点を、導入前に整理しておきたい。

Lambda関数のコードそのものは、実AWSにデプロイするものと同じアーティファクトをそのまま流し込める。ハンドラの実装を書き換える必要はなく、Function URLやSQS/Kinesis/DynamoDB Streamsをトリガーとするイベントソースマッピング（ESM）もエミュレートされる。つまり「Lambdaがキューのメッセージを拾って処理する」といった非同期のイベント駆動フローを、ローカルで一気通貫にテストできる。ここまで再現できるローカルエミュレータは多くなく、Flociが単なるモックではなく実行環境寄りのツールであることがよく分かる部分だ。

よくあるトラブルと対処

これらは「本物のAWSではなくエミュレータを使う」ことに起因する定番の詰まりどころだ。裏を返せば、この5点さえ押さえておけば、Floci導入時の初期トラブルの大半は回避できる。

なお、IAM・STSといった認証系サービスもIn-processで動くため、ロールやポリシーを作成してアクセスキーを発行する、といった検証もローカルで完結する。ただしFlociは実際の権限チェックを厳密に強制するわけではなく、あくまで「APIとしての形」を再現する点は理解しておきたい。本番のIAMポリシーが正しく効くかどうかの最終確認は、やはり実AWS環境で行う必要がある。エミュレータの守備範囲は「APIの疎通と挙動の確認」であり、「セキュリティ境界の検証」ではない、という線引きを意識すると使い方を誤らない。

Floci を LocalStack 代替として導入する判断基準（互換性・比較・CI/CD）

2026年3月のLocalStack Community Edition認証トークン必須化を受け、多くのチームがLocalStack 代替を検討している。ここでは互換性・他ツール比較・CI/CD活用の3つの角度から、FlociがLocalStack 代替として適切かどうかを判断する材料を整理する。

互換性テスト（1,873件）で担保される信頼性

公式リポジトリの compatibility-tests/ ディレクトリに、6言語・3 IaCツール向けのテストスイートが含まれる。

これらはPRごとに自動実行されるため、「READMEに書いてあるが実は動かない」という乖離が起きにくい。IaC（Terraform/OpenTofu/CDK）を含めて検証されている点は、インフラをコード管理しているチームにとって特に安心材料になる。

他ツールとの比較｜LocalStack・Moto との違い

Motoはユニットテスト向けモックであり、複数サービスの連携テストには不向き。ElasticMQ+DynamoDB Localはサービスごとにポート管理が煩雑になる。Flociは「1バイナリ・1ポートで29サービス」という統一性が強みだ。LocalStack Proの50以上のサービスが必要な場合はそちらが妥当。

この比較表で特に効いてくるのが、起動時間とメモリの差だ。LocalStackの約3.3秒・約143MiBに対し、Flociは約24ms・約13MiB。1回だけなら誤差に見えるが、テストを何百回も回すCIや、コードを保存するたびに再起動する開発ループでは、この差が積み重なって体感速度を大きく変える。Dockerイメージも約90MB対約1.0GBと10分の1で、pullやキャッシュの待ち時間も短い。「軽さ」は単なるスペック自慢ではなく、開発者の待ち時間を削るという実利に直結している。

LocalStack 代替としてFlociが適しているケース

判断のコアはシンプルで、「必要な29サービスの中に収まり、無料・軽量を重視するならFloci」「50以上のサービスや商用サポートが要るならLocalStack Pro」という切り分けになる。まずはFlociで検証し、足りないサービスが出た時点でProを併用する、という段階的な移行も現実的だ。

Floci AWSエミュレーション：CI/CDでの活用パターン

FlociのAWSエミュレーションをCI/CDパイプラインに統合する具体的な構成例を示す。GitHub ActionsとGitLab CIの両方に対応。

GitHub Actions構成例

# .github/workflows/integration-test.yml
name: Integration Tests with Floci
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    services:
      floci:
        image: hectorvent/floci:latest
        ports:
          - 4566:4566
    steps:
      - uses: actions/checkout@v4
      - name: Run integration tests
        env:
          AWS_ENDPOINT_URL: http://localhost:4566
          AWS_DEFAULT_REGION: us-east-1
          AWS_ACCESS_KEY_ID: test
          AWS_SECRET_ACCESS_KEY: test
        run: |
          # S3バケット作成とテストデータ投入
          aws s3 mb s3://test-bucket
          aws s3 cp testdata/ s3://test-bucket/ --recursive
          # DynamoDBテーブル作成
          aws dynamodb create-table \
            --table-name test-table \
            --attribute-definitions AttributeName=id,AttributeType=S \
            --key-schema AttributeName=id,KeyType=HASH \
            --billing-mode PAY_PER_REQUEST
          # アプリケーションテスト実行
          npm test

GitLab CI構成例

# .gitlab-ci.yml
integration-test:
  image: python:3.12
  services:
    - name: hectorvent/floci:latest
      alias: floci
  variables:
    AWS_ENDPOINT_URL: http://floci:4566
    AWS_DEFAULT_REGION: us-east-1
    AWS_ACCESS_KEY_ID: test
    AWS_SECRET_ACCESS_KEY: test
  script:
    - pip install boto3 pytest
    - pytest tests/integration/ -v

CI/CDでFlociを使う最大のメリットは、Dockerイメージが約90MBと軽量なため、ジョブの起動時間が大幅に短縮される点。LocalStack（約1.0GB）と比較して約10分の1のダウンロードサイズで、CIランナーのキャッシュ効率も向上する。実行のたびにクリーンな環境が欲しいCIでは、デフォルトのmemoryモードとの相性も良い。Terraformの統合テストを含むインフラ管理にはInfracostによるコスト可視化と組み合わせると、開発段階からコスト最適化が可能になる。

制限事項・注意点

・サービス数の上限: 29サービスに留まる。Redshift・Glue・Athenaなど分析系は未対応
・Lambda実行にDockerが必須: Lambdaエミュレーションは実際のDockerコンテナを起動するため、Docker Engineが動作している環境が前提
・API互換性の限界: AWSの全APIパラメータが忠実に再現されているわけではない。エッジケースでの挙動差異に注意
・商用サポートなし: GitHub IssuesまたはSlackコミュニティで対応

これらを踏まえても、「無料・軽量・認証トークン不要」という3点で、FlociはLocalStack 代替の第一候補たり得る。まずはローカルで29サービスの範囲を試し、自分のワークロードが収まるかを確かめるところから始めたい。

参照ソース

• GitHub - floci-io/floci
• Docker Hub - hectorvent/floci
• Floci公式ドキュメント - Services Overview
• Floci公式ドキュメント - Configuration Reference
• LocalStack Community Edition sunset発表
• Floci Slackコミュニティ