2026年7月 Flociアップデートまとめ、認可の作り込みとCloudTrailのイベント記録が入った1ヵ月

こんにちは。サービス開発部の武田です。

LocalStackの代替として登場したオープンソースのAWSエミュレータ「Floci」を、これまでも取り上げてきました。

• 導入と主要サービスの動作検証（2026年3月）
• 公開から1ヵ月のアップデートまとめ（2026年4月30日）
• さらに1ヵ月のアップデートまとめ（2026年5月30日）
• CloudFormationとWebコンソールに対応した1ヵ月（2026年6月30日）

前回からまた1ヵ月が経ちました。今回もこの1ヵ月の更新を、いくつか手元で動かしながらまとめていきます。

今回は新しく増えたサービスが少ない一方で、既存サービスの中身を詰める変更が多く入りました。合わせて、リリースノートの見出しだけでは分からない部分がいくつかあったので、そこも含めて確認します。動かしてみて気になった点は、issueとPRにして投げています。

この1ヵ月の主な変化（2026年7月30日時点）

前回記事（1.5.28時点）から現在（1.5.34）までの変化をサマリーすると、次のとおりです。

• リリース 6回（1.5.29 → 1.5.34）、 170コミット
• 対応サービスが 65 → 69 へ（公式表記）。ただし内訳には数え直しが含まれる
• GitHubスターが 14,528 → 18,022 へ
• READMEの互換性テスト件数が 1,969 → 2,506 へ
• 認可の作り込みが進んだ。IAMのAssumeRole信頼ポリシー、STSのセッションポリシー、S3の認可チェックがそれぞれ設定で有効にできる
• 前回書いた!Cidrのショートハンド記法の問題が 1.5.30で解消。出したPRが取り込まれた
• Step Functionsが多方面に拡張。ステートマシンのバージョンAPI、ecs:runTask、JSONataのAssign、HTTP呼び出しなど
• 新サービスはAmazon MQ（1.5.30）とLightsail（1.5.32）の2つ。CloudTrailは1.5.34でプロセス内実装になり、S3のデータイベントを記録するようになった

順に見ていきます。

更新状況と互換性テスト

GitHub APIで集計したところ、前回記事の集計時点（2026年6月29日）から1.5.34がリリースされた7月29日までに、リリースは6回、コミットは170件でした。前回は8回・284件だったので、いずれも件数としては減っています。

リリース日を並べると、1.5.29（6月30日）から1.5.33（7月15日）までは3〜4日おきでしたが、そこから1.5.34（7月29日）までは2週間空いています。この2週間に入ったPRは25件でした。3日間で44件が入った1.5.30と比べると、ペースとしては落ち着いた月です。

スター数は14,528から18,022まで増えました。

互換性テストの件数は、READMEの表記で1,969件から2,506件になっています。ただしこの差分をそのまま「537件追加された」とは書けません。内訳を1.5.28時点のREADMEと比べると、次のようになっていました（2,506件という数字は1.5.33と1.5.34で変わっていません）。

Rust向けのテストスイートは1.5.30で削除されています（#1717）。削除の理由はリリースノートには書かれていません。増加分の大半はJava SDKのテスト（+427）でした。

前回は件数が横ばいで「間口を広げた月」と書きましたが、今回はテスト側が積み増されました。

前回の宿題: !Cidrのショートハンド記法

前回の記事で、CloudFormationのFn::Cidr・Fn::GetAZsについて注意点を挙げました。フル記法では動くものの、ショートハンド（!Cidr・!GetAZs）ではYAMLのパース段階で落ちる、というものです。リポジトリを確認したところタグの登録が漏れていたので、追加するPRを出していました。

このPRは7月3日にマージされ、同日リリースの1.5.30に入っています。確認してみます。環境構築はこれまでと同じくdocker-compose.ymlを用意するだけです。

services:
  floci:
    image: floci/floci:1.5.34
    ports:
      - "4566:4566"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

$ export AWS_ENDPOINT_URL=http://localhost:4566
$ export AWS_DEFAULT_REGION=us-east-1
$ export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test

前回はフル記法に書き換えて動かしたテンプレートを、今回はショートハンドのまま書きます。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  Vpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
  SubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref Vpc
      CidrBlock: !Select [0, !Cidr [!GetAtt Vpc.CidrBlock, 4, 8]]
      AvailabilityZone: !Select [0, !GetAZs ""]
  SubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref Vpc
      CidrBlock: !Select [1, !Cidr [!GetAtt Vpc.CidrBlock, 4, 8]]
      AvailabilityZone: !Select [1, !GetAZs ""]
Outputs:
  SubnetIds:
    Value: !Join [",", [!Ref SubnetA, !Ref SubnetB]]

$ aws cloudformation create-stack --stack-name shorthand-demo \
    --template-body file://stack-shorthand.yaml

$ aws cloudformation describe-stacks --stack-name shorthand-demo \
    --query 'Stacks[0].StackStatus' --output text
CREATE_COMPLETE

$ aws ec2 describe-subnets \
    --query "Subnets[?starts_with(CidrBlock, '10.0')].[SubnetId,CidrBlock,AvailabilityZone]" \
    --output text
subnet-50549f44  10.0.0.0/24  us-east-1a
subnet-89ae5138  10.0.1.0/24  us-east-1b

前回could not determine a constructor for the tag !Cidrで落ちていたテンプレートが、そのまま通るようになりました。Fn::CidrによるCIDRの分割とFn::GetAZsによるAZの割り当ても、フル記法のときと同じ結果です。

issueで報告する手もありましたが、原因が特定できていたので直接PRにしました。マージまで中2日、その3時間後にはリリースに入っています。動きの速いプロジェクトでは、気付いた側から直しにいくほうが早いですね。

認可の作り込み

今月まとまって入ったのが、認可周りです。これまでのFlociは、アクセスキーの中身を問わずリクエストを通していました。この1ヵ月で、次のような設定が入っています。

いずれもデフォルトでは無効で、環境変数で有効にする形です。S3の認可を試してみます。

関係する環境変数は2つあります。それぞれ次のように説明されています。

両方を有効にして起動し、S3の許可をもつIAMユーザーと、何も許可をもたないIAMユーザーを作ります。

$ aws iam create-user --user-name s3-user
$ aws iam put-user-policy --user-name s3-user --policy-name s3-access \
    --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:*","Resource":"*"}]}'
$ aws iam create-access-key --user-name s3-user

許可をもつユーザーの認証情報では、これまでどおりバケットの作成もオブジェクトの取得もできます。許可のないユーザーと、そもそも登録されていないアクセスキーで同じ操作をすると、こうなりました。

# 許可を持たないIAMユーザー
$ aws s3api get-object --bucket auth-demo --key o.txt /tmp/out.txt
An error occurred (AccessDenied) when calling the GetObject operation:
User is not authorized to perform: s3:GetObject

# 登録されていないアクセスキー
$ aws s3api get-object --bucket auth-demo --key o.txt /tmp/out.txt
An error occurred (InvalidAccessKeyId) when calling the GetObject operation:
The AWS Access Key Id you provided does not exist in our records.

実際のAWS環境と同じエラーコードが返ってきました。

なお、2つの環境変数は役割が違います。片方ずつ有効にして確認したところ、次のように分かれました。

FLOCI_SERVICES_S3_ENFORCE_AUTHはS3側でアクセスキーの実在と公開/非公開を見るもので、IAMポリシーの評価まではしません。ポリシーの拒否まで再現したい場合はFLOCI_SERVICES_IAM_ENFORCEMENT_ENABLEDが必要でした。ポリシーの挙動をローカルで試したいときは、両方を有効にしておくのがよさそうです。

ついでに、1.5.33でデフォルト暗号化の挙動も修正されています。以前は設定していないバケットにGetBucketEncryptionを投げると404が返っていましたが、実環境と同じくSSE-S3の設定が返るようになりました。

$ aws s3api get-bucket-encryption --bucket auth-demo
{
    "ServerSideEncryptionConfiguration": {
        "Rules": [
            {
                "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "AES256"
                },
                "BucketKeyEnabled": false
            }
        ]
    }
}

69サービスへ: 新サービスと新機能

対応サービスは公式表記で65から69になりました。ただし増えた4つがすべて新サービスというわけではありません。1.5.30で、すでに対応済みだったIoT CoreとS3 Vectorsがサービス一覧に加えられ、同じリリースで入ったAmazon MQと合わせて表記が68に訂正されています（#1716）。その後Lightsailが加わって69です。

この1ヵ月に新しく入ったサービスと、既存サービス内の大きめの機能を挙げます。

Amazon MQはRabbitMQのコンテナを立てる形で、RDSやElastiCacheと同じ「実エンジンをバックエンドに置く」路線です。一方Lightsailはプロセス内の実装で、実際のVMが起動するわけではありません。EKSのFargateプロファイルも、Fargate相当の実行基盤ができるわけではなく、プロファイルを含む構成をプロビジョニングできるようになりました。

RDSのモックモードは、Dockerコンテナを起動せずにクラスターやインスタンスを作れるモードです。Docker in Dockerが使えないCI環境や、実際にSQLを流さないテストで使えます。

CloudTrailがイベントを記録するようになった

1.5.34で、CloudTrailがプロセス内の実装になり、S3のデータイベントを実際に記録するようになりました（#1460）。これまでは証跡のライフサイクル（作成・削除・ログ開始）を扱うだけでしたが、操作の記録が残るようになっています。手元で試してみます。

記録先のバケットと、監視対象のバケットを作ります。ログを書き出す間隔はデフォルトで60秒ですが、待ち時間を短くするため10秒にしておきました。

services:
  floci:
    image: floci/floci:1.5.34
    ports:
      - "4566:4566"
    environment:
      FLOCI_SERVICES_CLOUDTRAIL_FLUSH_INTERVAL_SECONDS: "10"

$ aws s3 mb s3://my-source
$ aws s3 mb s3://my-trail-logs

$ aws cloudtrail create-trail --name my-trail --s3-bucket-name my-trail-logs
$ aws cloudtrail put-event-selectors --trail-name my-trail --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": false,
    "DataResources": [{"Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::my-source/"]}]
  }]'
$ aws cloudtrail start-logging --name my-trail

対象バケットに対して、成功する操作と失敗する操作を流します。

$ echo hello | aws s3 cp - s3://my-source/greeting.txt
$ aws s3 cp s3://my-source/greeting.txt -
hello
$ aws s3api get-object --bucket my-source --key nothere /tmp/nope
An error occurred (NoSuchKey) when calling the GetObject operation: ...

しばらく待つと、記録先のバケットにログファイルが現れます。キーの形もAWSと同じ並びです。

$ aws s3api list-objects-v2 --bucket my-trail-logs --query 'Contents[].Key' --output text
AWSLogs/000000000000/CloudTrail/us-east-1/2026/07/30/000000000000_CloudTrail_us-east-1_20260730T0035Z_5eSB3s8UPvfON0jU.json.gz

gzipを展開すると、4件のレコードが入っていました。

aws s3 cpが内部でHeadObjectを呼んでいるところまで記録されています。失敗した操作もerrorCode付きで残るので、エラー時の監査ログを前提にした処理も試せます。レコードの構造もAWSに寄せてあります。

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "IAMUser",
    "accessKeyId": "test",
    "userName": "root"
  },
  "eventTime": "2026-07-30T00:35:25Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "PutObject",
  "awsRegion": "us-east-1",
  "requestParameters": {
    "bucketName": "my-source",
    "key": "greeting.txt"
  }
}

記録されるのはS3の操作のうちPutObject・GetObject・HeadObject・DeleteObject・ListObjects・GetObjectAclの6つです。docs/services/cloudtrail.mdに一覧があります。逆にいうと出るのはS3のデータイベントだけですので、S3以外のAPI呼び出しを監査する用途には使えません。

Logs InsightsとAppSyncを動かしてみる

新機能のうち、リリースノートの見出しからは読み取りにくかったものを2つ動かしてみました。

CloudWatch Logs Insights

1.5.31でLogs Insightsのクエリに対応した、とあります。ロググループにINFOを1件、ERRORを2件入れて、filterで絞り込んでみます。

$ NOW=$(date +%s)
$ QID=$(aws logs start-query --log-group-name /floci/demo \
    --start-time $((NOW-300)) --end-time $((NOW+300)) \
    --query-string 'fields @timestamp, @message | filter @message like /ERROR/' \
    --query queryId --output text)

$ aws logs get-query-results --query-id "$QID" --query '{status:status,stats:statistics}'
{
    "status": "Complete",
    "stats": {
        "recordsMatched": 3.0,
        "recordsScanned": 3.0,
        "bytesScanned": 0.0
    }
}

ERRORを含む2件に絞られるはずが、3件すべてが返っています。クエリ自体はCompleteになり、エラーにはなりません。filter @message like "ERROR"のように書き方を変えても同じでした。stats count()も試しましたが、集計されずに生のレコードが返ります。一方でlimit 1は効きました。

実装を見ると、対応しているのはfields・filter・sort・dedup・limitで、filterの演算子は=・!=・==だけです。この範囲は意図的なもので、Logs Insightsを追加したPRにも「filter (= / !=)」と書かれています。likeは対応表にないので、ステージごと捨てられて全件が返ります。

気になったのは、捨てられ方がもうひとつあることです。>=を使ってみます。

$ aws logs start-query --log-group-name /floci/demo \
    --start-time $((NOW-300)) --end-time $((NOW+300)) \
    --query-string 'fields @timestamp, @message | filter @message >= "x"' \
    --query queryId --output text

返ってきたのは 0件 でした。演算子を探す処理が>=の=の部分を演算子と解釈するため、フィールド名が@message >になります。そんなフィールドは解決できないので、どの行も一致せず0件になります。likeのときはサーバーログに警告が出ますが、この経路では警告も出ません。

# like のときは警告が出る
Ignoring unsupported Logs Insights filter: @message like /ERROR/
Ignoring unsupported Logs Insights command: stats

# >= のときは何も出ない

AWSのドキュメントでは、filterは=・!=・<・<=・>・>=をサポートし、like /ERROR/も正規表現の書き方として載っています。どちらもAWS環境では通るクエリですね。同じロググループに従来のFilterLogEventsを使うと、こちらは絞り込まれます。

$ aws logs filter-log-events --log-group-name /floci/demo \
    --filter-pattern "ERROR" --query 'events[].message' --output text
ERROR database timeout   ERROR connection refused

前回の記事で、S3 Selectが未対応の式に対して黙って空を返していた件を取り上げました。あれは1.5.22でエラーを返すよう改善されています。同じ構図ですので、Logs Insightsについてもissueを立てました（#2042）。未対応の構文はクエリを失敗させるほうが安全ではないか、という趣旨です。>=の誤解析のほうは単独のバグとして直せそうなので、その点も併せて書いています。

なお、1.5.34時点のdocs/services/cloudwatch.mdにはStartQuery・GetQueryResultsの記載がありません。ハンドラが実装している24個のアクションのうち、ドキュメントに載っているのは14個でした。この表は自動生成の対象外で手書き管理になっているためです。こちらは追記するPRを出し、マージされました（#2044）。

AppSync

AppSyncは1.5.29で「Phase 4: VTLエンジン」、1.5.32で「Phase 5」が入り、リリースノートでは5フェーズにわたる作り込みが完了したとされています。前回の記事では、$utilのランタイムライブラリは入ったもののVTLテンプレートの評価自体は未実装だ、と書きました。そこが変わったのかを確認します。

まず管理APIから。スキーマを登録し、NONEデータソースとリゾルバーを作ります。

$ API_ID=$(aws appsync create-graphql-api --name vtl-demo \
    --authentication-type API_KEY --query 'graphqlApi.apiId' --output text)

$ aws appsync start-schema-creation --api-id "$API_ID" --definition fileb://schema.graphql
{
    "status": "PROCESSING"
}

$ aws appsync get-schema-creation-status --api-id "$API_ID"
{
    "status": "SUCCESS"
}

ここまでは問題なく動きます。Phase 5で入った非同期のスキーマ作成も、PROCESSINGからSUCCESSへ遷移しました。データソースとリゾルバーの登録も成功しました。

次に、GraphQLのクエリを投げてみます。エンドポイントはGetGraphqlApiから取得できます。

$ aws appsync get-graphql-api --api-id "$API_ID" \
    --query 'graphqlApi.uris.GRAPHQL' --output text
http://localhost:4566/v1/apis/16bfb9b4149a4c2a905b25cad1/graphql

$ API_KEY=$(aws appsync create-api-key --api-id "$API_ID" \
    --query 'apiKey.id' --output text)

$ curl -s "http://localhost:4566/v1/apis/${API_ID}/graphql" \
    -H "Content-Type: application/json" -H "x-api-key: ${API_KEY}" \
    --data '{"query":"query { hello(name: \"Floci\") { message } }"}'
<?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidArgument</Code>
<Message>POST requires either ?uploads, ?uploadId, ?restore or ?select parameter.</Message>

S3のエラーがXMLで返ってきました。このパスがGraphQLのエンドポイントとして処理されず、S3のルーティングに流れています。Hostヘッダーを{apiId}.appsync-api.us-east-1.amazonaws.comの形にしても、コンテナの中から叩いても結果は同じでした。

リポジトリのドキュメントを確認すると、1.5.34タグのdocs/services/appsync.mdには「Not Implemented」として次のように書かれています。

Execution engine (Phase 5): GraphQL query execution, resolver dispatch, VTL template evaluation

GraphQLクエリの実行・リゾルバーのディスパッチ・VTLテンプレートの評価は未実装、という記載です。ドキュメントの内容と手元の結果は一致しています。

1.5.34には「未知のサービスへのRESTリクエストがS3にフォールバックしないようにする」修正が入っています（#1967）。ルーティングが追いにくい点に対処するものですが、AppSyncのGraphQLエンドポイントについては1.5.34でも同じS3のエラーが返りました。

というわけで、AppSyncについては前回書いた状況から変わっていません。管理API側は充実してきているので、CloudFormationやCDKでAppSyncのリソースを定義するところまでは試せます。ただし、GraphQLのクエリを実行して結果を検証する用途にはまだ届いていません。

なお、実装計画のissue（#1173）を見ると、クエリ実行とHTTPエンドポイントは「Phase 6」として整理されています。対応するPR（#1884）が7月15日から開いていて、1,300行規模の変更です。これが入ればクエリを投げられるようになりそうですね。フェーズの番号の振り方がリリースノートとドキュメントで違うだけで、作業自体は続いています。

Cloud Control APIの対応範囲

1.5.31で、Cloud Control APIのListResourcesに対応しました。前回触れたSteampipeのようなリソース収集ツールにつながる更新です。サービス固有のAPIで作ったリソースを読み戻せるか試してみます。

S3バケット、SQSキュー、ロググループを作り、それぞれのタイプで一覧してみました。

S3とEC2は読み戻せましたが、SQSとCloudWatch Logsは0件でした。ListQueuesやDescribeLogGroupsでは見えているので、リソース自体は存在しています。Cloud Control API側が対応していないタイプでした。実装を見ると、対応しているのはS3バケット・VPC・サブネット・セキュリティグループ・IAMロール・IAMユーザーの6タイプで、それ以外は空のリストを返す作りです。

実際のAWS環境では、この2つはどちらもCloud Control APIの対象です。ユーザーガイドはAWS::Logs::LogGroupを「作成から一覧まで5つの操作すべてに対応するスキーマの例」として挙げています。AWS::SQS::Queueも対応リソースの一覧に載っています。本来なら列挙できるものが、ローカルでは空になるわけですね。

$ aws cloudcontrol list-resources --type-name AWS::SQS::Queue
{
    "ResourceDescriptions": [],
    "TypeName": "AWS::SQS::Queue"
}

未対応のタイプでもエラーにはならず、空のリストが返ります。AWS::NoSuch::Typeのような存在しないタイプ名でも同じ結果でした。レスポンスからは「リソースが無い」のか「タイプが未対応」のか区別がつきません。リソースを横断的に集めるツールから見ると、対応していないタイプが全部「何もなかった」として扱われるので、ひととおり回したつもりで実は大半が空、という状態に気付きにくいところです。

こちらもissueを立てました（#2043）。エラーを返すか、対応タイプを明記するか、対応を増やすかは方針次第なので、選択肢を挙げて相談する形にしています。

その他の改善

手元では確認していませんが、リリースノートから拾える範囲で目立った変更を挙げます。

Step Functions は今月もっとも変更が多かったサービスのひとつです。ステートマシンのバージョンAPI、ResultSelectorやPassのParameters、ecs:runTask統合が1.5.30で入りました。続けてS3上のJSONを読むMapのItemReader（1.5.31）とJSONataのワークフロー変数Assign（1.5.33）が加わりました。1.5.34ではHTTP呼び出しのステップとStates.JsonMergeが入っています。

ECS は実運用に近いパターンを通すための修正が続いています。1.5.32では、タスク定義のsecretsをSSMとSecrets Managerから解決する対応が入りました。合わせて、EFSアクセスポイントのPOSIX所有権の適用と、awsvpcタスクへの動的なホストポート割り当ても加わっています。

エラーの返し方の修正 も多く入りました。EMRは500ではなくAWSのクライアントエラーコードを返すようになりました（1.5.31）。1.5.33では、RDSのDescribeDBSubnetGroupsが存在しないグループにDBSubnetGroupNotFoundFaultを返し、EC2のImportKeyPairが重複した名前を拒否するようになっています。S3ではDeleteBucketReplicationがバケットごと削除してしまう不具合も直りました（1.5.33）。

永続化 の対象も広がり、Elastic Beanstalk、Lambdaのバージョンカウンタ、API Gatewayのキータグ、リソースタグのマッピングが再起動をまたぐようになりました。

配布物の検証 も1.5.34で変わりました。公開されるコンテナイメージに、provenanceとSBOMのアテステーションが付くようになっています（#2032）。リリースノートによると、取得したイメージがソースからビルドされたものと一致するかを暗号学的に検証でき、含まれるソフトウェアの一覧も取り出せるようになったとのことです。

ドキュメントの生成 も変わりました。1.5.31以降、Supported Actionsの表がハンドラのソースコードから自動生成されるようになっています（#1641）。ドキュメントと実装の乖離が構造的に減る変更です。ただし対象は全サービスではありません。生成の設定ファイルには除外リストがあり、CloudWatch LogsやCloud Control APIはそこに入っています。今回Logs Insightsの記載が漏れていたのは、この表が手書きのままだったためです。

まとめ

この1ヵ月のFlociは、新しく増えたサービスが少ない一方で、既存サービスの中身を詰める変更が中心でした。手元では、CloudFormationのショートハンド記法、S3の認可、CloudTrail、Logs Insights、AppSync、Cloud Control APIを動かして確認しました。

• 前回挙げた!Cidr・!GetAZsのショートハンド記法は1.5.30で解消。出したPRが取り込まれた
• 認可の設定が入り、IAMポリシーによる拒否と未登録アクセスキーの拒否をローカルで再現できる。ただし2つの環境変数で役割が分かれている
• 対応サービスは69へ。ただし65からの差分には数え直しが含まれ、実質的な新サービスはAmazon MQとLightsailの2つ
• 互換性テストの件数は1,969から2,506へ。増加分の多くはJava SDK側で、Rustのスイートは削除されている
• CloudTrailがプロセス内実装になり、S3のデータイベントを記録するようになった。成功した操作に加えて失敗した操作も残り、失敗にはerrorCodeが付く

一方で、リリースノートの見出しと実際に動かせる範囲にはずれがありました。AppSyncは「Phase 5で完了」とされていますが、リポジトリのドキュメントには実行エンジンが未実装と書かれており、手元でもGraphQLのクエリは実行できませんでした。こちらは対応中のPRがあります。Logs Insightsも、クエリは受け付けるもののfilterとstatsが結果に反映されません。

気になった点は、そのままにせず投げておきました。

• #2042: Logs Insightsが未対応の構文で結果を静かに変えてしまう件。likeはステージが捨てられて全件、>=は誤解析されて0件になる
• #2043: Cloud Control APIが未対応タイプに空のリストを返す件
• #2044: docs/services/cloudwatch.mdにLogs Insightsのサポート範囲と、記載が漏れていた10個のアクションを追記するPR。こちらはマージされました

このあたりを確認するときは、README冒頭の対応表よりもdocs/services/<service>.mdのほうが実態に近いです。特に各ページの「Not Implemented」の節は見ておく価値があります。ただし今回のように、ドキュメント自体が実装に追いついていないこともあります。使いたい機能があるときは、まず小さく動かして確かめるのが確実です。

リリース回数とコミット数はどちらも前回より減り、1.5.33から1.5.34までは2週間空きました。開発のペースは公開直後の勢いからは落ち着いてきています。それでもAppSyncのように、大きめのPRが開いたまま進んでいるものもあります。引き続き様子を見ていきたいですね。

本記事の数値やリリース内容は、次の一次情報をもとにしています。

• floci-io/floci（GitHubリポジトリ）
• Releases（1.5.29〜1.5.34のリリースノート）
• Floci公式ドキュメント
• 動作確認はfloci/floci:1.5.34で実施しました