ID:82642さん

プロジェクト経験概要 要件定義の途中から参画し、クロスアカウント連携を前提とした AWS 構築を担当。別組織とのデータ連携要件により API Gateway 利用が必須となったため、当初検討していた VPC 間連携案を見直し、認証・アクセス制御を含めた API 連携方式を再設計した。 チーム情報 要件定義フェーズ途中から参画。 自分の担当は、インフラ関連の作業すべて。 開発・実装内容A 【概要】 別組織とのデータ連携に向けた API 方式の再設計を行った。 【どのような機能の開発・実装か】 クロスアカウント連携前提の AWS 基盤において、外部組織との連携方式を VPC 接続中心の案から API Gateway を利用した方式へ見直し、認証・利用制御の設計観点を整理した。 【課題・問題点】 当初はセキュリティを重視し、VPC 間連携を含む閉域寄りの構成を検討していたが、連携元が別組織であり、要件上 API Gateway の利用が必須となった。そのため、公開エンドポイント前提でも利用主体を限定できる構成へ方針転換する必要があった。 【打ち手・使用した技術】 API Gateway を前提とした連携方式に切り替え、IAM 認証を中心にアクセス制御を設計した。API キーは利用制御上の補助として整理し、認証・認可を主軸に「誰が呼べるか」を明確にする構成を検討した。 要件変更後も、セキュリティと実現性の両立を重視して設計方針を整理した。 【成果】 別組織・クロスアカウントという制約の中で、連携方式の前提条件を整理し直し、実運用に載せられる API 連携構成の方針を提示した。 理想構成に固執せず、要件変化を踏まえて安全性を保ちながら成立する案へ調整した経験。

プロジェクト経験概要 既存の日本製プロキシ製品から海外製プロキシ製品への移行案件に参画。旧製品と新製品で評価観点や挙動が異なる中、設定差分や影響範囲を整理し、移行後に発生した接続不可や利用不可の問い合わせに対する切り分け・ユーザ対応を担当した。 チーム情報 チーム体制で対応した移行案件。 自分は、旧環境と新環境の差分整理、影響項目の洗い出し、移行後問い合わせ対応を担当。 開発・実装内容A 【概要】 旧プロキシと新プロキシの差分整理と影響範囲の洗い出しを行った。 【どのような機能の開発・実装か】 日本製プロキシから海外製プロキシへの移行にあたり、旧環境で成立していた通信や制御内容が新環境でどう評価されるかを確認し、移行時に問題となる項目を整理した。 【課題・問題点】 製品が変わることで、ポリシー評価や通信判定の考え方が異なり、旧環境で問題なく利用できていた通信やサイトアクセスが新環境では同様に動作しない可能性があった。 【打ち手・使用した技術】 旧環境と新環境の挙動差分を確認し、影響が出る項目を洗い出した。 移行前に差分を整理するだけでなく、移行後に発生した「接続できない」「従来利用できていたものが利用できない」といった問い合わせに対し、設定・通信・評価観点から原因を切り分け、利用者対応を行った。 【成果】 移行前後の差分整理から、移行後の業務影響確認、利用者フォローまで一貫して対応した。 単なる設定移行ではなく、製品変更による利用影響を把握しながら運用定着まで支援した経験。 使用技術の使用場面 プロキシ製品運用：旧製品・新製品の評価観点差分の整理 移行対応：設定差分、影響範囲、利用不可事象の洗い出し ユーザ対応：移行後の接続不可・利用不可問い合わせの切り分け セキュリティ運用：通信制御の観点整理、製品差異に伴う影響把握

プロジェクト経験概要 運用を主担当として参画していた案件において、AIサービス利用に伴う追加構築を担当。Azure OpenAI の利用が前提条件であったため、AWS 環境から安全に接続するための構成検討、認証方式の整理、機密情報の取り扱い設計を実施した。 チーム情報 運用案件の一部追加対応として参画。 主担当として、接続方式の検討と設計観点の整理を担当。 開発・実装内容A 【概要】 Azure OpenAI を AWS 環境から利用するための接続方式を検討した。 【どのような機能の開発・実装か】 AIサービス呼び出しに必要な接続構成、認証方式、通信経路、機密情報の保持方法を整理し、運用可能な方式に落とし込むための設計支援を行った。 【課題・問題点】 Bedrock ではなく Azure OpenAI 利用が前提であり、他クラウド連携となるため、単純な接続成立だけではなく、認証情報の管理、通信の安全性、継続運用時のリスク整理が必要だった。 【打ち手・使用した技術】 AWS 側からの利用を前提に、認証方式、通信経路、権限制御、機密情報の保管方法を整理した。 「接続できること」だけでなく、「どのように安全に使い続けるか」を重視し、構成上のリスクと運用負荷の両面から接続方式を検討した。 【成果】 要件制約の中で、他クラウド連携におけるセキュリティと運用性を両立するための構成方針を整理した。 設計時点で認証・通信・情報管理の論点を明確化できたことで、実装時に考慮すべきポイントを事前に揃えられる状態にした。 使用技術の使用場面 AWS：接続元環境として構成整理、権限制御の検討 Azure OpenAI：連携先サービスとして接続前提要件を整理 クラウド間接続設計：通信経路、認証方式、機密情報管理の整理 セキュリティ設計：権限境界、認証情報の扱い、運用時リスクの洗い出し