はじめまして。2026年度新卒として入社し、この夏からITディベロップメント1部 開発チーム 開発2課に配属されますF.Tです。 4月に入社してから約4か月間、みっちりと研修を受けてきました。振り返ると本当にあっという間で、それでいて濃密な期間でした。 そこでこの記事では、受講した新卒の一人として、この4か月で何を経験し、何を得たのかを率直にお伝えします。 研修の雰囲気が少しでも伝われば幸いです。 研修全体の流れ 研修は大きく次のステップで進んでいきました。 時期 研修内容 ～4月中旬 人事研修・デジ戦研修 ～5月末 IT/Web研修 ～6月上旬 デジ戦研修 ～6月中旬 職種別研修 6月中旬～7月末 開発演習（4スプリント＋成果発表会） ※デジ戦 : デジタルテクノロジー戦略本部 人事研修・デジ戦研修 最初に受けたのは、職種を問わず新卒共通の人事研修・デジ戦研修です。 人事研修 人事研修では、ビジネスマナーやビジネスマインド、文書作成の基本など、社会人として当然身につけておくべきことを学びました。グループワークが多く、入社したてで緊張していましたが、同期と話すうちに自然と打ち解けていったのを覚えています。 なかでも、相談などの時間を取ってもらいたいときに使用する「お時間よろしいでしょうか」というクッション言葉は今となっては自然と口から出るほど身に付きました。 デジ戦研修 続くデジ戦研修では、講義やパネルディスカッション、座談会などを通してデジ戦の組織構造や各職種について説明を受け、組織と業務への理解を深めました。 また、相手に伝わるスライドを作成するためのデザイン研修や、顧客のニーズを捉えて価値を届けるマーケティングの研修を通じて、実践的な知識や考え方も学びました。 さらに、日々売上を生み出している営業社員が、商談において何を考え、どのようにお客さまと向き合っているのかを学ぶ機会もありました。実際の商談動画を視聴したほか、営業社員との座談会も開催していただき、営業という仕事への理解も深めることができました。 デジ戦研修の中で特に印象に残っているのがパネルディスカッションと2年目社員との座談会です。これらの研修を通して「配属後に自分がどんな仕事をするのか」の解像度がぐっと上がりました。 また、業務内容だけでなく私たち新卒へのメッセージもたくさんいただきました。 なかでも、「どんな仕事も伝わらないと意味がない」というメッセージはエンジニア職の私には強く印象に残りました。 どんなにたくさんコードを書こうと、すごい機能を実装しようと使う人にとっての使い方、メリットが伝わらないと意味がありません。 生成AIが普及しアウトプットが簡単に得られる時代に、伝えるという仕事はより一層大切になっていると感じました。 IT/Web研修 ここからはエンジニアとしての土台づくりです。と言いつつも、デジ戦ではエンジニア職であるかに関わらず全員がこの研修を受講します。全社横断のIT部門という特徴が表れた研修だという風に感じています。 研修では、セキュリティ、データベース、ネットワークといった基礎知識から、Python、SQL、HTML/CSS、JavaScript、そしてバックエンド開発（Python / Django）まで、幅広く学びました。 この研修の特徴は、まったくの初心者がいるということだと思います。経験者は初心者の方に教える中で自分の理解度を再認識し復習するという光景が周囲でたくさん見られました。一方初心者の方は、はじめて触れる概念に苦戦しつつもわからないことは周囲に質問し、すさまじいスピードで知識を身に付けていく姿が印象的でした。 職種別研修 職種別研修では、エンジニア・デザイナー・データサイエンティスト・マーケター・ガバナンスの5職種に分かれ、5日間の研修を受けました。 私が受けたエンジニア職研修では、ウォーターフォール開発を要件定義から総合テストまで一通り体験しました。クラスやオブジェクトの概念、UMLの作成には苦戦する場面もありましたが、チームで協力し一連の成果物を作り上げることができたときは達成感がありました。 短期間で上流から下流まで駆け抜けるのは大変でしたが、開発全体の流れを肌で理解できた貴重な機会でした。 開発演習 そして、研修の最後は約1か月にわたる開発演習を行いました。開発演習では、マイナビ転職・マイナビクリニックナビの2つのサービスで各2チームの計4チームに分かれ開発を行いました。 どのチームにも均等に各職種のメンバーが割り振られ各職種の強みを発揮し、協力しながらチーム開発を進めました。 また、今年度はデジ戦先輩社員のフィードバックに加え、各サービスを運営する事業部の方々からも定期的にフィードバックをいただく機会を用意していただきました。 各チーム、フィードバックの機会を有効に活用し、最終成果発表時には初期のものと比べ物にならないサービスを開発していました。 なお、開発演習の具体的な取り組み内容については、 こちらの記事 で詳しくご紹介しています。 振り返り 約4か月の研修を通して私が得たものは、大きく3つあります。 1つ目は私は伝えたではなく、伝わったと相手に言ってもらうことの大切さ、2つ目はエンジニアとしての基礎知識、そして最後がチームで開発をやり抜いた経験です。 特に開発演習では、技術力だけでなく、チームで議論し、フィードバックを受け止め、次に活かすという一連の流れを実体験をもとに覚えることができました。同期との仲もぐっと深まり、配属後も相談し合える心強い仲間ができたことは、何より大きな財産です。 ここでお伝えしたのはあくまで私自身の視点ですが、新卒一人ひとりがそれぞれ異なる学びを得ています。配属後は研修で得た学びを生かし、一日でも早く一人前になれるよう精進します。 最後に、新卒研修に関わってくださった皆さま、研修担当の方々、そして事業部・先輩社員の皆さまに、心より御礼申し上げます。研修で得たすべてを糧に、配属後も挑戦を続けていきます。

本記事は 2026 年 7 月 20 日 に公開された「 Connection pooling strategies in Amazon Aurora DSQL 」を翻訳したものです。 本記事では、Aurora DSQL の接続負荷を減らし、1 秒あたり 100 接続のレート制限を超えず、再接続が一斉に集中する thundering herd を避けるための、具体的な 4 つの戦略を解説します。読み終える頃には、大規模でも安定した性能を発揮する接続プールを構成するための、本番運用に使えるチェックリストが手に入ります。 接続プーリングの戦略次第で、 Amazon Aurora DSQL アプリケーションが安定してスケールするか、負荷で破綻するかが決まります。Amazon Aurora DSQL 独自のアーキテクチャは、接続プーリングの効果をさらに大きくします。トランザクション単位の多重化と AWS Identity and Access Management (IAM) による認証により、Aurora DSQL では適切なプーリング戦略が、従来の PostgreSQL の接続管理では実現できない形で性能を高めます。 注: 本記事は、PostgreSQL の接続管理の概念と基本的な IAM 認証を理解していることを前提としています。Amazon Aurora DSQL を初めて使う場合は、これらの戦略を適用する前に、まず Getting Started ガイド から始めてください。 サーバーレス環境での接続プーリング Amazon Aurora DSQL は運用の複雑さを自動的に処理しますが、それでも接続プーリングは欠かせません。新しい接続のたびに、コストの高い TLS ハンドシェイクと認証情報の交換が発生します。プーリングは確立済みの接続を再利用し、この負荷を抑えてレイテンシーを削減します。また、トラフィックが急増すると、1 秒あたり 100 接続 (バースト時 1,000) のレート制限に達することがあり、既存の接続を再利用すればサービスの制限内に安全に収まります。さらに、Amazon Aurora DSQL には接続の最大有効期間があり、クライアントは 1 時間で切断されます。適切に構成したプールはこの制限に達する前に接続をリサイクルし、セッションを透過的に維持します。 トランザクション単位のプーリング: アーキテクチャに組み込み済み Amazon Aurora DSQL はトランザクションプーリングモデルを採用しています。接続を Query Processor に割り当てるのは、セッション全体ではなくトランザクションの実行中だけです。標準的な PostgreSQL では、接続はバックエンドのサーバープロセスと 1:1 のセッション関係を持続的に維持します。一方 Amazon Aurora DSQL はこの対応関係を切り離すため、少数の Query Processor ではるかに多くの接続を処理できます。 この設計は、接続の使用率が低いこと、つまりほとんどの接続が大半の時間アイドル状態であることを前提としています。使用率が低いほど、接続プールに必要な Query Processor は少なくて済みます。そのため、PgBouncer や pgpool-II のようなデータベース側のプロキシは使うべきではありません。トランザクション単位の接続多重化がデフォルトで組み込まれているため、これらのツールはサービスの接続アーキテクチャと重複します。 さらに、一部の PostgreSQL 機能はサポートされていません。SQL レベルの PREPARE/DEALLOCATE ステートメント (ただし拡張クエリプロトコル経由のプリペアドステートメントは正常に動作します)、WITH HOLD カーソル、セッションレベルのアドバイザリーロックです。 Amazon Aurora DSQL の 4 つの接続プーリング戦略 以下の 4 つの戦略は、それぞれ Amazon Aurora DSQL の接続管理の特定の側面に対応します。組み合わせて適用すれば、アプリケーションがサービスの制限内に収まり、負荷がかかっても安定した性能を保てます。新しいアプリケーションを構築する場合は戦略 1 から始め、既存の PostgreSQL アプリケーションを移行する場合はチェックリストとして活用してください。 戦略 1: 公式の AWS コネクタを使う 公式の Amazon Aurora DSQL コネクタ の利用をお勧めします。トークンの生成、有効期間の 80% でのキャッシュ、透過的な更新など、IAM トークンのライフサイクル全体を自動的に処理します。 表 1: プログラミング言語別の推奨接続プールライブラリと主要な設定パラメータ 言語 プーリングライブラリ 主要な設定 Java HikariCP maximumPoolSize Python psycopg ConnectionPool min_size Node.js node-postgres (pg.Pool) max Go pgxpool MaxConns Java (HikariCP) — Spring Boot、Quarkus、Micronaut のアプリケーションでは HikariCP を使います。 HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:postgresql://<cluster-endpoint>:5432/<db>?ssl=true&sslmode=verify-full&sslrootcert=<path>"); config.setMaximumPoolSize(20); config.setMaxLifetime(55 * 60 * 1000); // 55 minutes config.setIdleTimeout(10 * 60 * 1000); // 10 minutes config.setConnectionTimeout(30 * 1000); // 30 seconds config.setKeepaliveTime(5 * 60 * 1000); // 5 minutes HikariDataSource ds = new HikariDataSource(config); Python (psycopg ConnectionPool) — Django、Flask、FastAPI のアプリケーションでは psycopg ConnectionPool を使います。 from psycopg_pool import ConnectionPool pool = ConnectionPool( conninfo="host=<endpoint> dbname=<db> sslmode=verify-full", min_size=2, max_size=20, max_lifetime=55 * 60, # 55 minutes in seconds max_idle=10 * 60, # 10 minutes idle timeout reconnect_timeout=30, # 30 seconds to reconnect ) Node.js (node-postgres) — Express.js、NestJS、サーバーレスの Node.js 関数では node-postgres の Pool を使います。 const { Pool } = require("pg"); const pool = new Pool({ host: "<cluster-endpoint>", database: "<db>", ssl: { rejectUnauthorized: true }, max: 20, idleTimeoutMillis: 10 * 60 * 1000, // 10 minutes connectionTimeoutMillis: 30 * 1000, // 30 seconds }); Go (pgxpool) — Gin、Echo、AWS Lambda Go ランタイムで構築する Go アプリケーションでは pgxpool を使います。 connStr := "host=<cluster-endpoint> dbname=<db> sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 20 config.MinConns = 2 config.MaxConnLifetime = 55 * time.Minute // 55 minutes config.MaxConnIdleTime = 10 * time.Minute // 10 minutes idle pool, _ := pgxpool.NewWithConfig(ctx, config) AWS Lambda: プールはハンドラーの外でインスタンス化する AWS Lambda は Aurora DSQL のワークロードでよく使われるコンピューティングサービスです。Lambda の実行モデルには特有のプーリングパターンが必要です。接続プールをモジュールスコープ (ハンドラー関数の外) で作成し、同じ実行環境のウォーム呼び出し間で保持されるようにします。 Lambda が実行環境を再利用すると、モジュールスコープで作成したプールはアクティブなまま残ります。以降の呼び出しでは TLS ハンドシェイクと IAM トークンの交換を完全にスキップできます。コールドスタート時にはプールが一度だけ初期化され、その環境が存続する間は再利用されます。 同時に実行される各 Lambda 呼び出しはそれぞれ独立した実行環境で動くため、プールも個別に持ちます。多数の同時実行にわたって接続を過剰に確保しないよう、プールサイズは小さく (Lambda インスタンスあたり 1〜3 接続) 保ってください。 Lambda の主なガイドライン: プールはハンドラーの外でインスタンス化する。これが最も重要なルールです。 最大プールサイズを 1〜3 に設定する。各 Lambda インスタンスは (バッファ呼び出しを使わない限り) 一度に 1 リクエストしか処理しないため、大きなプールは無駄になります。 アイドルタイムアウトを設定しない。接続は実行環境が存続する間ずっと維持させます。 Lambda 以外のワークロードと同様に、1 時間のハード制限に達しないよう、最大有効期間を 55 分にしてジッターを加える。 コールドスタートのレイテンシーを考慮する。最初の呼び出しでは TLS と IAM 認証の負荷が発生します。以降のウォーム呼び出しではプールされた接続を再利用します。 Python (psycopg ConnectionPool) — Lambda # pool is created ONCE at module scope, reused across warm invocations from psycopg_pool import ConnectionPool import boto3 pool = ConnectionPool( conninfo="host=<cluster-endpoint> dbname=<db> sslmode=verify-full", min_size=1, max_size=2, max_lifetime=55 * 60, # 55 minutes reconnect_timeout=30, ) def handler(event, context): """Lambda handler — pool is already initialized.""" with pool.connection() as conn: result = conn.execute("SELECT * FROM orders WHERE id = %s", [event["order_id"]]) return result.fetchone() Node.js (node-postgres) — Lambda // Pool is created ONCE at module scope, reused across warm invocations const { Pool } = require("pg"); const pool = new Pool({ host: "<cluster-endpoint>", database: "<db>", ssl: { rejectUnauthorized: true }, max: 2, // small pool per Lambda instance idleTimeoutMillis: 0, // don't close idle connections connectionTimeoutMillis: 30 * 1000, // 30 seconds }); exports.handler = async (event) => { // Pool is already warm on subsequent invocations const client = await pool.connect(); try { const result = await client.query("SELECT * FROM orders WHERE id = $1", [event.orderId]); return result.rows[0]; } finally { client.release(); } }; Go (pgxpool) — Lambda package main import ( "context" "time" "github.com/aws/aws-lambda-go/lambda" "github.com/jackc/pgx/v5/pgxpool" ) // Pool created at package scope — initialized once per execution environment var pool *pgxpool.Pool func init() { connStr := "host=<cluster-endpoint> dbname=<db> sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 2 config.MinConns = 1 config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute pool, _ = pgxpool.NewWithConfig(context.Background(), config) } func handler(ctx context.Context, event map[string]string) (string, error) { row := pool.QueryRow(ctx, "SELECT name FROM orders WHERE id = $1", event["order_id"]) var name string err := row.Scan(&name) return name, err } func main() { lambda.Start(handler) } ヒント: Lambda 関数の同時実行数が多い場合 (数百の同時実行)、各実行環境がそれぞれプールを作成します。最大プールサイズ 2 で 500 の Lambda が同時実行されると、Aurora DSQL への接続は最大 1,000 になり得ます。接続の総数を監視し、クラスターあたり 10,000 同時接続のクォータ内に収めてください。 重要: クライアント接続には sslmode=verify-full を設定し、証明書を完全に検証して経路上の攻撃 (on-path attack) を防ぎます。Aurora DSQL は verify-ca や require といった弱いモードでも接続を受け付けますが、これらはサーバーの正当性を検証しません。 安定した接続プールを維持するには、IAM トークンのライフサイクルの理解が重要です。 新しい接続ごとに、新しい IAM 認証トークンを生成します。トークンの生成はローカルでの署名操作で、負荷はごくわずかです。公式の AWS コネクタはこれを自動的に処理します。独自のプールを使う場合は、トークンを手動でキャッシュするのではなく、接続ファクトリの beforeConnect フックで generate-db-connect-auth-token コマンドを呼び出してください。 トークンは、基となる IAM 認証情報より長くは有効になりません。1 時間のセッションでロールを引き受けた場合、 --expires-in の値に関係なく、トークンは最大でも 1 時間で失効します。 データベースロールは最小権限に絞る。 IAM 認証は誰が接続できるかを制御しますが、接続後にそのセッションが何をできるかは制限しません。各アプリケーションのデータベースロールには、必要な最小限の権限だけを付与します。たとえば、読み取り専用のサービスには SELECT を付与し、書き込みアクセスは特定のスキーマやテーブルに限定します。アプリケーションの接続プールで管理者ロールを使うのは避けてください。 手順の詳細は、 Authorizing database roles to use SQL in your database を参照してください。 戦略 2: 最大接続有効期間にジッターを設定して接続の失効を防ぐ Amazon Aurora DSQL には、1 時間という接続の最大有効期間のハード制限があります。接続がこの期間に達すると、アイドル中でもトランザクションの途中でも、サービスはその接続を閉じます。プールはそうなる前に接続をリサイクルする必要があります。 ジッターが重要な理由: プール内のほとんどの接続がほぼ同じタイミング (たとえばアプリケーションの起動時) に作成された場合、それらはほぼ同時に失効します。すると新しい接続リクエストが一斉に集中する「thundering herd」が発生し、1 秒あたり 100 接続のレート制限を超えることがあります。最大有効期間にランダムなジッターを加えると、接続のリサイクルが時間的に分散されます。 // Go (pgxpool) — Use native per-connection jitter config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute // Each connection independently gets a lifetime between 55-60 minutes // Java (HikariCP): maxLifetime already applies per-connection jitter automatically // Python: use max_lifetime with a randomized offset in your pool factory 期待される結果: 接続のリサイクルが個々の接続にわたって時間的に均等に分散し、新しい接続リクエストが 1 秒あたり 100 のレートクォータを十分に下回った状態を保てます。 戦略 3: プールサイズを最適化する Amazon Aurora DSQL は多数の同時接続でも高い性能を発揮しますが、スループット、レイテンシー、リソース消費のバランスをとれるようにプールサイズを設定する必要があります。 表 3: 接続プールのサイズ設定パラメータの推奨初期値 パラメータ 推奨初期値 理由 最小プールサイズ 2〜5 接続 低負荷時にリソースを無駄にせず、プールをウォームに保つ 最大プールサイズ アプリケーションインスタンスあたり 10〜20 控えめに始める。アプリケーションインスタンスを追加してスケールアウトする 接続タイムアウト 30 秒 トラフィックが多いイベント中に、DSQL の接続バーストキュー (100/秒) を消化できるようにする アイドルタイムアウト 無効 (または MaxConnLifetime に合わせる) アイドル接続にコストはかからない。開いたままにしておけば、再接続時の不要な TLS/認証の負荷を避けられる Amazon CloudWatch で DPU (Distributed Processing Unit) の消費を監視し、容量の追加が必要なタイミングを把握します。トラフィックの急増が予想される場合 (スケジュールされたバッチジョブやマーケティングキャンペーンなど) は、事前にプールをウォームアップしておきます。インスタンスあたりの接続数を増やすのではなく、小さめのプールを持つアプリケーションインスタンスを増やして水平方向にスケールアウトします。Amazon Aurora DSQL は、短期的な負荷増加には垂直スケーリングで、長期的な変動にはフリート全体の水平スケーリングで対応します。クラスターあたり 10,000 同時接続のクォータを活用し、必要であれば AWS Support に連絡して上限を引き上げてください。 期待される結果: ワークロードに合わせてプールが適切にサイズ設定され、接続の負荷とプール枯渇エラーの両方を最小限に抑えられます。 戦略 4: マルチリージョンでのプーリングの考慮事項 Amazon Aurora DSQL のマルチリージョン active-active デプロイを使うグローバル分散アプリケーションでは、接続プーリングにもう一段の検討が必要です。 このサービスのマルチリージョンアーキテクチャでは、SQL の実行、読み取り、書き込みのスプーリングをクライアントのリージョン内でローカルに処理します。リージョン間の通信は、コミット時に Adjudicator と Journal のレプリケーションプロトコルを通じてのみ発生します。マルチリージョンモードでも読み取りはローカルなので、読み取り専用トランザクションはリージョン間のレイテンシーなしで完了します。読み書きトランザクションでリージョン間レイテンシーが発生するのは COMMIT 時のみで、実行した SQL ステートメントの数に関係なく、リージョン間のラウンドトリップ約 1〜1.5 回分です。各ステートメントごとにラウンドトリップが発生する転送ベースの設計と比べ、レイテンシーを削減できます。リージョンの選択も重要です。接続性の良いリージョンの組み合わせほどコミットレイテンシーが低く、地理的に離れた組み合わせほどそれに比例して大きくなります。 マルチリージョンでのプーリングでは、リージョンごとに個別の接続プールを作成し、それぞれローカルの Amazon Aurora DSQL エンドポイントを指すようにします。トークン更新のロジックがリージョンごとの IAM エンドポイントを考慮していることを確認してください。アプリケーションは active-active アクセスを前提に設計します。このサービスにはプライマリリージョンという概念がなく、各リージョンは対称的に動作します。 期待される結果: リージョン間レイテンシーはコミット時にのみ発生し、読み取りはローカルリージョンの速度で完了します。 オブザーバビリティ: データベースだけでなく接続プールも監視する Aurora DSQL の CloudWatch メトリクス (TotalTransactions や CommitLatency など) はデータベースレベルの挙動を示しますが、接続プールがボトルネックかどうかまではわかりません。プールの健全性を把握するには、アプリケーション側に計測を組み込む必要があります。次に挙げるクライアント側のメトリクスが、接続プーリングの問題を捉える重要なシグナルです。 アプリケーションに組み込むべきメトリクス メトリクス 示す内容 アラートのしきい値 発生時のアクション プール取得レイテンシー (.get() の所要時間) プールから接続を取得するまでアプリケーションが待つ時間 P95 > 500 ms プールが飽和している。最大プールサイズを増やすか、アプリケーションインスタンスをスケールアウトする アクティブ接続数 現在トランザクションを実行中の接続数 最大プールサイズに張り付いている すべての接続が使用中。プールサイズを増やすか、トランザクションの実行時間を短くする アイドル接続数 プール内で使われていない接続の数 0 のまま張り付いている トラフィックのバーストに対する余裕がない。最小プールサイズを増やすか、急増が予想される前にウォームアップする リクエストの同時実行数 対 プールサイズ 処理中の同時リクエスト数と最大プールサイズの比率 同時実行数が最大プールサイズの 80% を超える プール枯渇に近づいている。スケールアウトするか、プールサイズを増やす プール枯渇イベント 利用可能な接続を待って接続リクエストがタイムアウトした回数 > 0 直ちに対応が必要。プールサイズを増やす、トランザクションの実行時間を短くする、またはアプリケーションインスタンスを追加する 接続作成レート プールが 1 秒あたりに開く新規接続の数 100/秒 に近づく Aurora DSQL のレート制限に達するリスクがある。ジッターを加える、インスタンスの起動をずらす、または最小プールサイズを増やして接続の入れ替わりを減らす ほとんどの接続プールライブラリは、これらの統計をネイティブに公開しています。 Java (HikariCP): HikariPoolMXBean を使って getActiveConnections() 、 getIdleConnections() 、 getThreadsAwaitingConnection() 、 getTotalConnections() にアクセスします。Micrometer 経由で CloudWatch やアプリケーションパフォーマンスモニタリング (APM) ツールにエクスポートします。 Python (psycopg ConnectionPool): pool.get_stats() を使います。 pool_min 、 pool_max 、 pool_size 、 pool_available 、 requests_waiting 、 requests_num を返します。 Node.js (node-postgres): pool.totalCount 、 pool.idleCount 、 pool.waitingCount に直接アクセスします。一定間隔で、またはリクエストごとに出力します。 Go (pgxpool): pool.Stat() を使います。 AcquireCount() 、 AcquiredConns() 、 IdleConns() 、 TotalConns() 、 AcquireDuration() を提供します。 これらはカスタム CloudWatch メトリクスとして発行するか ( PutMetricData API またはログ内の CloudWatch Embedded Metric Format を使用)、既存の APM ツール (AWS X-Ray、Datadog、Prometheus/Grafana など) に送信します。 補足: Aurora DSQL の CloudWatch メトリクス 主要なシグナルはクライアント側のメトリクスであるべきですが、プールサイズを決めるうえで役立つ Aurora DSQL のメトリクスが 1 つあります。 メトリクス プーリングに役立つ理由 TotalTransactions プール取得レイテンシーと関連付けて見ます。トランザクションが増えているのに取得レイテンシーが横ばいなら、プールサイズは適切です。両方が増えているなら、容量の追加が必要です。 よくある接続プールの問題のトラブルシューティング アラートが発生したら、この表を使って最もよくある障害シナリオを診断し、対処してください。 表 5: よくある Amazon Aurora DSQL 接続プール問題のトラブルシューティングガイド 症状 考えられる原因 診断ステップ 対処 プール枯渇 (接続タイムアウトエラー) トラフィックに対して maxPoolSize が低すぎる アクティブ接続とアイドル接続を比較して監視する 最大プールサイズを増やすか、アプリケーションインスタンスを追加する 約 55 分後の認証失敗 トークンの失効が処理されていない トークン更新のログを確認する 公式コネクタを使っているか確認する。MaxConnLifetime の設定を確認する 新規接続レートのエラー 起動時の thundering herd 接続作成のタイムスタンプを確認する MaxConnLifetime にジッターを加える。アプリケーションインスタンスの起動をずらす クイックリファレンス: 主要な制限と設定 接続の有効期間、トランザクションタイムアウト、接続レート、同時実行数などの最新の制限については、 Cluster quotas and database limits を参照してください。 まとめ 本記事では、Amazon Aurora DSQL のトランザクション単位のプーリングモデルが従来の PostgreSQL とどう違うかを解説しました。また、コネクタの選択からマルチリージョンでのプーリングまで、アプリケーションの性能と回復力を保つための具体的な 4 つの戦略も紹介しました。PgBouncer や pgpool-II のようなデータベース側のプロキシは使わないでください。このサービスはトランザクション単位の多重化をネイティブに処理します。マルチリージョンのデプロイでは、リージョン間レイテンシーがコミット時にのみ発生することを覚えておいてください。トランザクションはローカルの読み書きを活かせるように設計しましょう。 これらの戦略に従えば、アプリケーションは Amazon Aurora DSQL の自動スケーリング、強整合性、高可用性を最大限に活用できます。接続の負荷を最小限に抑え、大規模でもレイテンシーを予測可能に保てます。 著者について Tejas Dubey Tejas は、 Tejas は AWS のテクニカルアカウントマネージャーで、エンタープライズのお客様が回復力とセキュリティに優れ、AI 対応のクラウドアーキテクチャを構築できるよう支援しています。新しいテクノロジーを実際のビジネス価値に変えることに情熱を注いでいます。仕事を離れているときは、息子を追いかけたり、ピックルボールをしたり、最新のテクノロジーをいじったりしています。 Dhvani Shah Dhvani は、 Dhvani はテクニカルアカウントマネージャーで、クラウドの回復力、セキュリティ、生成 AI の導入に関する戦略的なガイダンスでエンタープライズのお客様を支援しています。デジタルトランスフォーメーションを加速する、スケーラブルで安全なソリューションの設計を支援しています。仕事以外では、旅行やバドミントン、家族と過ごす時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Arisa Izuno がレビューしました。

PSSLの佐々木です Claude Code・Copilot・Codex といった AI コーディングエージェントは、コマンドを実行できる権限を持ったまま手元のリポジトリの中で動きます。便利ですが、 secret (API token、DB 接続文字列、本番 AWS キー) との同居していることでシークレットが漏洩しないか心配になったので対応策を調査してみました。 この記事では、 ルールで縛っても AI Agent に .env を読まれてしまう情報漏洩リスク その緩和策として Infisical を選んだ理由 Infisical の仕組み (= なぜ AI に「見えない」のか) 個人 AWS アカウントを使った検証での導入手順 についてまとめました。 1. ルールで縛っても AI Agent は secret を読みうる危険がある Claude Code / Copilot 等の主要な AI コーディングエージェントには、運用ルールを書ける場所が用意されています。Claude Code なら CLAUDE.md みたいなやつです。 検証用に立てたプロジェクトの CLAUDE.md にも、こんなルールを書いてみました: - `.env`, `.env.prod`, `.env.*`, `*.pem`, `client_secret.json` などの secret 実体を読まないでください - secret ファイルに対して `cat`, `grep`, `sed`, `awk`, `head`, `tail`, `less`, `python` などで 内容を表示・抽出しないでください - secret 値、DATABASE_URL、SECRET_KEY、SMTP password、RDS password、private key を チャット、docs、issue、PR、ログへ書かないでください しかしここにルールを記載しても何度も裏切られた経験もあり、意図せずAgnetがルールを無視してシークレット情報を見に行く可能性も否定しきれないなと開発をしながら思っていました。 例えば以下のような場合にAgentがルールを無視してシークレットを読みに行く可能性があります 「node dev server が立ち上がらない」→ デバッグのため DATABASE_URL の構造を確認する必要が出る 「ECR push が失敗している」→ AWS profile / credential の状態を見る必要が出る 「 make で env が読まれていないっぽい」→ シェルから env | grep XXX する つまり、 CLAUDE.md だけに頼った secret 管理は 「事故が起きないことを祈る運用」 だと感じていて商用製品の開発をする際にかなりのリスクになりえると思っています。 2. Infisical とは Infisical は OSS の secret 管理プラットフォームです。AWS Secrets Manager や HashiCorp Vault と同じ「secret を集中管理する」カテゴリに属しますが、開発者体験が抜群に良いと思いました Web UI で見て編集できる (json でなく key-value のテーブル) CLI が direnv / dotenv-cli の上位互換 として使える 環境別 ( dev / staging / prod ) + パス別 で分離可能 メンバー単位の RBAC 、誰がいつ何を見たかの audit log Cloud (SaaS) も Self-host (Docker compose) も選べる 無料枠 が個人開発で十分使える 公式に GitHub Star 約 2 万 あって、HashiCorp Vault よりは小規模、AWS Secrets Manager よりは開発者寄りという立ち位置です。 3. 仕組み ― なぜ AI Agent から「見えない」のか Infisical CLI の中核機能は infisical run です: infisical run --env=dev --path=/aws/sandbox -- aws sts get-caller-identity このコマンドの裏では、こういう流れが起きます: infisical CLI (親) │ ├─ 1. ローカルに保存された JWT で Infisical API へ認証 ├─ 2. /aws/sandbox パスの secret 一覧を HTTPS で取得 (in-memory) ├─ 3. fork して子プロセスを作る │ └─ 子プロセスの environ に AWS_ACCESS_KEY_ID 等を export └─ 4. 子プロセス (= `aws sts get-caller-identity`) 実行 └─ 子プロセス終了で memory も解放、secret はどこにも残らない Infisicalを使っていてうれしいポイント ディスクに .env ファイルを一切作らない — AI が cat .env しても “そんなファイルない” 親 shell の env に export しない — AI が env や printenv を打っても見えない (= デフォルトの shell には載っていない) shell history に値が残らない — infisical run -- foo という呼び出し履歴は残るが、secret 値は履歴に出ない 子プロセスが終わったら secret 痕跡ゼロ — RAM 上から消える つまり、AI エージェントが「環境変数経由で secret を盗む」最もカジュアルな経路 (= cat .env と env ) を 両方とも構造的に塞いでいます 。 4. 導入手順 (個人 AWS アカウントで検証) ここからは、自分の個人 AWS アカウント上に検証用の IAM user を作り、その credential を Infisical に登録して AI エージェントから AWS リソースを操作させる、という流れで手を動かしてみた手順です。あわせて、検証用に立てた Django プロダクトの .env 相当の値 (DB 接続文字列、SECRET_KEY、SMTP password など) も Infisical に寄せて、ローカルの .env を消し去るところまでやりました。 4.1 アカウント作成 infisical.com/cloud でサインアップ。Org → Project を作成。 4.2 CLI のインストール # macOS brew install infisical/get-cli/infisical # Linux curl -1sLf '<https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.deb.sh>' | sudo -E bash sudo apt update && sudo apt install -y infisical 4.3 ログインとリポジトリの紐付け infisical login # ブラウザが開いて OAuth cd path/to/repo infisical init # この repo を Infisical project に紐付け (.infisical.json 生成) .infisical.json は project ID と環境名の対応だけ が入っていて secret 値は無いので、git に commit しても問題なし。 4.4 secret を登録 Web UI から登録するのが楽です。複数環境 ( dev / staging / prod ) と任意のパス ( /aws/sandbox /django/app 等) で分けられます。 検証では、個人 AWS アカウントに作った IAM user の credential と、検証用 Django プロダクトの env をこんな感じで分けました: Infisical path env vars 用途 dev / /aws/sandbox AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (個人検証用 IAM user) AI エージェントから S3 / EC2 / SSM などを叩く検証 dev / /django/app DATABASE_URL / SECRET_KEY / SMTP_PASSWORD 等 検証用 Django アプリの実行時 env これで手元の .env は完全に削除。値は全部 Infisical 側にだけ存在する状態にしました。 4.5 実行 # AWS 操作 infisical run --env=dev --path=/aws/sandbox -- aws sts get-caller-identity # → arn:aws:iam::xxxxxxxx:user/sandbox-user # Django 起動 infisical run --env=dev --path=/django/app -- python manage.py runserver これで OK。 .env ファイルもシェルへの export も一切無し。 5. 検証してわかった恩恵 5.1 AI エージェントが構造的に secret に触れなくなった 検証では Claude Code に「個人 AWS アカウントの S3 バケットを一覧して、不要なものを削除して」みたいなタスクを投げてみました。 infisical run 経由で AWS 操作を委任しても、Claude は そもそも secret 値を「知る」術がない 。例えば: infisical run --env=dev --path=/aws/sandbox --silent -- \\ aws s3 ls これを Claude に実行させても、Claude が見られるのは: コマンドの引数 (= 公開情報) コマンドの出力 (= 私が許可した情報) だけ。 AWS キー本体は Claude のプロセス空間にも会話履歴にも入りません。 検証用 Django アプリ側でも同様で、 .env を消した状態で Claude に「dev server を立ち上げて動作確認して」と頼むと、 infisical run 経由でしか起動できない。エージェントが好奇心で cat .env しても ファイルが存在しない ので空振りに終わります。実際にやらせてみても、 DATABASE_URL や SECRET_KEY の値が会話履歴に出てくることは一度もありませんでした。 5.2 検証用 IAM user を分けやすい 個人 AWS アカウントで遊んでいると「これは AI に渡していい権限」「これは自分が手でしかやらない権限」を分けたくなります。Infisical のパスで切るとそこが綺麗: # AI に渡していい権限 (read 中心、限定リソース) infisical run --env=dev --path=/aws/sandbox -- <command> # 自分しか使わない権限 (IAM 編集、billing 系) infisical run --env=dev --path=/aws/admin -- <command> IAM user 自体は別々に作って、Infisical 側でパス権限を分けるだけ。エージェントには /aws/sandbox だけアクセスできるトークンを渡す、みたいな運用が現実的にできます。 5.3 検証が終わったら剥奪が一瞬 個人検証あるあるで「検証終わったけど IAM key 消し忘れて放置」が起こりがちですが、Infisical に集約しておけば Web UI で値を消すだけ。 .env が複数のリポジトリに散らばってる状態より圧倒的に管理が楽でした。 6. まとめ AI Agent と一緒に開発する時代、 .env をローカルに転がしておく運用は 「ルールで縛っても、いつかは事故る」 可能性があります。 文章ルール ( CLAUDE.md ) は「お願い」レベル AI Agent はタスク遂行のために env を覗くことがある (悪意なしでも) 一度履歴に入った secret は AI ベンダー側に永続化される Infisical の infisical run -- <command> 方式に切り替えると、 .env ファイルがそもそも存在しない → cat で出ない shell env にも default で乗らない → env / printenv で出ない 子プロセスのライフサイクル内だけで secret が生きる それでいて direnv 同等の手軽さで開発が回る 完全防御ではないが、 カジュアルな漏洩経路を構造的に塞いだ上で、AI エージェントとの共存を成立させる ための最小コストの一手として、強くおすすめできます。 個人 AWS アカウントでの検証レベルでも、 .env を消して Infisical に寄せたことで「エージェントに何を喋らせても secret が混入しない」という安心感は段違いでした。本番投入前のサンドボックスとして手を動かしてみる価値は十分あると思います。 参考リンク Infisical 公式 Infisical CLI ドキュメント Anthropic Claude Code 公式 GitHub: Infisical/infisical ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AI エージェントに.envを読まれたくなかったからInfisicalを導入てみた first appeared on SIOS Tech Lab .