S3に、そのままSQL。クラウド技術8選｜Textract・Lambda Function URLs・Cognito

「これ、自分たちで作るしかないよね」。そう思って着手した機能が、実はサービスとして提供されていた。あとから知ると、静かにダメージを受けるやつです。

今回は、AWSを中心にCloudflareまで横断で、「ほぉー」となったものを8つ集めました。作れるけれど、作らなくていい。知っていると構成がすっきりするものです。異論・追加も大歓迎です。

① 帳票を「表のまま」読み取れます

請求書や申込書からデータを取り出したい。普通にOCRを使うと、文字は取れてもどこが表で、どのセルがどの項目かは分かりませんよね。座標から自分で組み立てる羽目になります。

Amazon Textract は、そこまでやってくれるんです。表は行と列の構造として、フォームは「項目名と値のペア」として返してきます。「請求金額」というラベルの隣にある数字を、ちゃんと組にしてくれるんですよね。

紙の申込書をデジタル化する案件だと、ここを自作するかどうかで工数がまるで違ってきます。

② 文字起こしに、話者の区別まで付きます

議事録の自動化で「誰が話したか」が分からないと、使いものにならないですよね。

Amazon Transcribe には話者分離の機能があります。音声を渡すと、「話者1」「話者2」と区別された状態でテキストが返ってくるんです。日本語にも対応しています。

もちろん名前までは分かりませんが、区切りが付いているだけで議事録の整形がぐっと楽になります。

③ S3のファイルに、そのままSQLを投げられます

これは知ると景色が変わるやつです。

S3にログのCSVやJSONが溜まっている。分析したいけれど、そのためにデータベースを立てて取り込むのは大げさすぎる。Amazon Athena なら、S3に置いたまま直接SQLで検索できるんです。

SELECT status, COUNT(*) AS cnt
FROM access_logs
WHERE dt = '2026-08-14'
GROUP BY status
ORDER BY cnt DESC;

サーバーを立てる必要も、取り込みの処理を書く必要もありません。使った分だけの課金なので、たまにしか調べないログの分析にはぴったりなんですよね。「調査のためだけにDBを用意する」から解放されます。

④ Lambdaに、直接URLを生やせます

Webhookの受け口を作りたいだけなのに、API Gatewayの設定に時間を取られたことはありませんか。

Lambda Function URLs を使うと、Lambda関数にHTTPSのエンドポイントを直接付けられるんです。

curl https://xxxxx.lambda-url.ap-northeast-1.on.aws/ \
  -H "Content-Type: application/json" \
  -d '{"event":"test"}'

設定はチェックひとつ。認証なしにも、IAM認証ありにもできます。もちろん本格的なAPIを作るならAPI Gatewayの機能が要りますが、受け取るだけの口ならこれで十分だったりするんですよね。

⑤ AWSの料金表そのものが、APIで取れます

いちばんマニアックなのはこれかもしれません。

AWS Price List API を使うと、料金の一覧をプログラムから取得できます。インスタンスタイプごとの単価、リージョンごとの差、ストレージの料金。ぜんぶデータとして扱えるんです。

構成を変えたときのコスト試算を自動化したり、社内向けの見積ツールを作ったり。「料金ページを人が見に行って、電卓を叩く」という運用から抜けられるんですよね。提案書の概算を出す場面でも効きます。

⑥ 外向きの転送料が、かからないストレージ

画像や動画を大量に配信していると、意外と効いてくるのが外向きの通信料です。

Cloudflare R2 は、S3互換のストレージでありながら、この外向き転送料がかからないという設計になっています。S3向けに書いたコードのほとんどが、そのまま動きます。エンドポイントの向き先を変えるイメージですね。

配信量が多いサービスほど、この差は大きくなります。もちろん保存容量や操作回数には課金があるので、自分の使い方でどちらが得かを計算してみる価値があります。

⑦ エラーを「時系列」ではなく「まとまり」で見る

ログを眺めてエラーを探す作業、つらいですよね。同じエラーが1000件流れてくると、他の重要なものが埋もれてしまいます。

Sentry のようなエラー監視サービスは、同じ原因のエラーを自動でまとめてくれます。「このエラーは3日前から発生していて、影響したユーザーは42人、直近のリリースから始まっている」。こういう形で見えるんですよね。しかも発生箇所のコードと、そのときの変数の中身まで残ります。

ログを検索して原因を探す時間が、そのまま減ります。

⑧ ログイン機能は、自作しないほうが安全です

最後は、少し毛色の違う話を。

ユーザー登録、ログイン、パスワード再設定、二要素認証。作れないことはありません。でも、安全に作り続けるのはかなり大変なんですよね。パスワードの保存方法、総当たり攻撃への対策、セッションの扱い、漏洩時の対応。

Amazon Cognito のような認証サービスを使うと、この部分をまるごと任せられます。自作するかどうかは、その機能が自社の強みになるかで決めるといいと思います。ログイン画面の使い勝手で選ばれるサービスは、あまりないですよね。

守りの機能は、専門のサービスに任せる。攻めの機能に時間を使う。この割り切りが大事かなと思います。

番外編：使う前に確かめたいこと

便利な反面、任せるほど依存も増えます。

料金体系は使い方によって大きく変わるので、自分の想定量で試算するのがおすすめです。無料枠の範囲も見ておくと安心ですね。そして、対応リージョンと日本語対応の有無。サービスによっては、東京リージョンで使えないものもあります。

最後に、乗り換えられるかどうか。S3互換のように標準に寄せた作りのものは、後から移りやすいんですよね。便利さと、抜けられなくなるリスク。ここは天秤にかけるところです。

RJCでも、こうしたサービスを使っています

決済分野のプロジェクトでは、AWSやDynamoDBを使って、要件定義からリリースまで一貫して開発しています。グループ活動でもAWSはテーマのひとつで、検証したことをみんなで持ち寄っているんです。

「インフラ周りの知識を増やしたい」と相談して、実際にインフラの業務を任せてもらった社員もいます。いまはAWSに夢中で、エラーが出ても自力で解決できるようになっているそうです。

よくいただくご質問

Q. どれから触ってみるのがいいですか？
A. ③のAthenaかなと思います。S3にファイルがあれば、すぐ試せます。SQLが書ければ動くので、入口としてやさしいんです。

Q. こういうサービス、どうやって知るんですか？
A. 「これ作るの大変だな」と思った瞬間に検索するのがいちばんです。だいたい誰かが同じことを大変だと思っていて、サービスになっていたりします。

Q. 未経験からでも、使いこなせるようになりますか？
A. なります。まず開発の基礎を固めてから、興味に合わせて広げていく形です。研修でSQLやWeb基礎も扱います。

Q. 話だけ聞くのはアリですか？
A. アリです。まず知るところから。

「作らない判断」も、設計のうちです

今日の8つ、共通しているのは作れるけれど作らなくていいということなんですよね。自作すれば自由度は上がりますが、その分ずっと面倒を見続けることになります。

何を自分たちで持ち、何を任せるか。この線引きこそが設計だなと思います。

ひとつでも「ほぉー」があったら嬉しいです。みなさんの「これも使えるよ」も、ぜひ教えてください。