どうも〜おはようございます、zenncastのマイクです。
今日は2026年5月2日、土曜日の朝7時をちょっと回ったところですね。みなさんいかがお過ごしでしょうか。
この番組では、エンジニアのみなさんの朝のお供に、Zennで今トレンドになっている記事をピックアップしてご紹介していきます。
今日はね、セキュリティからインフラ、データベース、そして形式手法まで、かなり濃いラインナップになっています。コーヒー片手に、ゆるっと耳だけ貸してもらえればうれしいです。
さて、今日ご紹介する記事は全部で5本です。
AIに全部やらせるセキュリティ診断、S3 Filesの性能評価、新しいスキーマ管理ツール、Terraform運用の落とし穴、そしてTypeScriptとLeanを組み合わせた検証のお話。幅広く押さえていきますよ。
まず1本目。
タイトルは「セキュリティ診断、AIに全部やらせたら月$0.5で回せるようになった話」。
これ、Claude Code向けのスキル「claude-security-scan」を使って、`/security-scan`って打つだけで、OWASP Top 10ベースの静的・動的診断からレポート生成まで全部自動で回す、という取り組みです。
ポイントは、なんでもかんでもAIにやらせるんじゃなくて、npm auditとかgitleaksみたいな“決定的ツール”に検出を任せて、AIは「ツールを実行する」「結果を解釈する」「Markdownのレポートにまとめる」っていう“司令塔”に徹しているところ。
依存関係の脆弱性、シークレットの混入、危険そうなコード、HTTPヘッダやTLSの設定、認証フロー、SQLインジェクションやSSRF、JWTの検証までカバーしてくれるうえに、深刻度と修正方針まで出してくれると。
おもしろいのが安全設計で、本番URLはそもそも実行できないようにブロックしていたり、設定ファイルをYAMLのスキーマでバリデーションしてプロンプトインジェクションを防いだり、レポート出力前に秘密情報をマスクしたりと、「AIでセキュリティをやる側のセキュリティ」もちゃんと考えてある。
コストも1回あたり5〜8セントぐらいで、週1でCIに回しても月あたり30〜50セントくらい。これなら個人開発でも余裕で使える価格帯ですよね。
専門のセキュリティエンジニアがいないチームでも、「まずは自分たちで定期的に回せる診断」を持てる時代になったんだなあ、というのを感じさせてくれる記事でした。
。。。。
続いて2本目。
タイトルは「S3 Files 性能評価」。
AWSが2026年4月に出してきた新サービス、S3 FilesをEC2からマウントして、既存のストレージたちとガチ比較した記事です。
S3 Filesって、S3の上にPOSIX互換のファイルシステム層をかぶせるマネージドサービスなんですが、fioで計測してみると、シーケンシャルアクセスではEFSと同等かそれ以上。numjobsを64にすると、読み取りで毎秒33.5GB、書き込みで5.5GBぐらい出た、というかなりエグい数字が出ています。
その一方で、4KiBのランダムIOを低並列で投げると、やっぱりネットワークファイルシステムっぽくて、エフェメラルディスクやEBSには敵わない。ここは設計どおりというか、「どんなワークロードにもこれ一本でOK!」っていうものではないよ、という示唆ですね。
料金もポイントで、S3 Standardのだいたい14倍ぐらいする高性能ストレージ料金に、さらに通常のS3料金も乗ってくるので、冷たいデータをずっと置いておく用途にはかなり割高。
なので、ユースケースとしては、学習データの配布とか、大きめのファイルの分析、ログやバックアップの“読み書きが太い処理”向け。逆に、ちまちました小さいファイルのランダムアクセスがメインなら、EBSとかエフェメラルのほうが向いている。
EFSとの性能差は実はそんなに大きくなくて、「データの実体をS3に置いておきたいかどうか」とか、「コスト構造をどう設計するか」が選択のポイントになりそうです。Mountpoint for S3はPOSIX互換じゃなくて、fioの要求する書き込みパターンにハマらないので、今回は比較対象から外しているよ、という注意書きもあって、測定の真面目さも伝わる内容でした。
。。。。
3本目。
タイトルは「宣言的スキーマ管理ツール pistachio を作成しました」。
これはPostgreSQL専用のスキーマ管理ツール「pistachio」を自作して、本番DBマイグレーションに適用している、という話です。
ワークフローとしては、まず既存のスキーマをdumpしてSQLに出力、それをgitで管理しつつ編集して、`plan`コマンドで差分を確認、`apply`で適用、という宣言的なスタイル。
従来はPython製のAlembicやsqldefを使っていたけど、言語やフレームワークに縛られたり、マイグレーション同士の依存関係が複雑になったり、PostgreSQLの細かい文法に追いつけなかったりといった課題があって、最終的にPostgresネイティブのパーサー(pg_query_go)を組み込んだ専用ツールを作るに至った、という背景が書かれています。
特徴としては、対象スキーマを明示的に指定できること、依存関係を考慮してDDLの実行順序を自動で並べてくれること、スキーマ名の省略やマッピング、危険なDROPはデフォルトでは無効、トランザクションを張るかどうかを選べる、CREATE INDEX CONCURRENTLYにも対応、さらにリネームを指示するディレクティブや、「存在したら実行する/しない」みたいな条件付きSQLも書ける、と。
特に本番環境だと、インデックスをCONCURRENTLYで貼りたいとか、一括トランザクションにしたくないケースがありますよね。そういう「運用の現場のつらみ」をちゃんと拾いにいっているのが印象的でした。
PostgreSQL前提でシンプルに割り切っているぶん、汎用ツールではカバーしづらいところまで踏み込んだ設計になっていて、PostgreSQL重めのチームには刺さるツールだと思います。
。。。。
4本目。
タイトルは「terraform applyをGHAで実行してはいけない理由」。
これはインフラ運用をやっている人にはぜひ一度読んでほしい、セキュリティ設計の記事です。
GitHub Actionsから本番AWS環境に直接`terraform apply`を叩く構成って、実はめちゃくちゃ危ないよ、という話。
OIDCで短命なクレデンシャルを使ってます、とか、mainブランチからだけ実行できます、とか、そういう“経路のきれいさ”をどれだけ頑張っても、「GHAのジョブがAdmin級のIAMロールを引き受けて、任意のAWS APIを打てる構造」そのものは変わらない。
Terraformを回すロールって、どうしてもIAMやS3、VPC周りまで広い権限を持たせがちなので、もし依存Actionが侵害されたり、開発者アカウントが乗っ取られたりしてGHAまで到達されると、その瞬間にAWSの管理プレーンが丸ごと持っていかれるリスクがあるわけです。
この記事で推奨しているのは、「GHAから`terraform apply`を全自動でつながない」。GHAはあくまでCodePipelineの起動までにとどめて、AWS側にManual approvalステップと、CodeBuild上の`terraform apply`を置く。つまり、GitHubの外側に「ここから先はインフラ管理者だけの世界だよ」という承認境界を作る、という設計ですね。
承認する人は、実質的にインフラの最終責任を負える人に限るべきだし、HCP Terraformみたいな専用の実行基盤を使うのも選択肢。
大事なのは、「GitHubでジョブを流せる権限」と「AWSを変えられる権限」をベタ結合しないこと。便利さと引き換えに、どれぐらいのリスクを抱えているのか、一度立ち止まって考えたくなる記事でした。
。。。。
最後、5本目。
タイトルは「TypeScript で実装したワークフローの『正しさ』を Lean とランダムテストで検証する」。
これは形式手法と現場の開発をどうつなぐか、というチャレンジングな内容です。
題材になっているのは、各ノードが次のノードを高々1つだけ持つようなシンプルなワークフロー。Leanの世界ではこれを「NodeからOption Nodeへの関数」としてモデル化して、「同じノードから出る辺の行き先は1つに決まる」みたいな性質をきちんと証明していきます。
一方、TypeScript側には`Workflow`の実装を用意しておいて、JSON形式のワークフローとクエリをランダムに生成。同じ入力をLean版とTypeScript版の両方に投げて、出力が一致するかどうかを比較する、というDifferential Random Testingの手法を取っています。
これをCI上で継続的に回すことで、「Leanでちゃんと証明した仕様」と、「実際のTypeScript実装」のズレを早い段階で検出する仕組みになっている。
完全な形式検証まではいかないけれど、「証明済みのモデル」+「差分テスト」という実務寄りの折衷案で、ワークフローエンジンの信頼性をグッと上げることができる、というのがこの記事のメッセージです。
型の世界からもう一歩踏み込んで、「動きそのものの正しさ」に興味がある方には、とても刺激的な内容だと思います。
。。。。
というわけで、今日は
・AIで回すセキュリティ診断と、その安全な設計の話
・S3 Filesを既存ストレージと比較した性能評価
・PostgreSQL専用スキーマ管理ツール pistachio
・TerraformをGHAから直叩きする危険性と、その回避パターン
・TypeScriptのワークフローをLean+ランダムテストで検証する手法
この5本をご紹介しました。
気になった記事があれば、詳しい内容や元の記事へのリンクはショーノートにまとめておきますので、そちらからぜひじっくり読んでみてください。
番組の感想や、「このトピックもっと掘り下げてほしい!」といったリクエストも、どしどしお待ちしています。
それでは、そろそろお別れの時間です。
今日もzenncast、お相手はマイクでした。
また次回お会いしましょう。いってらっしゃい!