はじめに こんにちは。2026年4月に新卒で入社したエンジニアの尾形です。 入社してからの半年間は、新卒研修の一環として、最初の3か月と次の3か月でそれぞれ別のチームに入って開発をしてきました。9月末でその研修期間が終わり、ひと区切りついたこのタイミングで半年を振り返ってみることにしました。 この半年でやってきたこと 大学院を修了して入社し、介護/障害福祉事業者向け経営支援サービス「カイポケ」の開発組織に所属しています。カイポケは、長く提供してきたカイポケクラウドから、新しく作り直したカイポケコネクトへの移行を進めています（リニューアルの背景は こちらの記事 にまとめられています）。私はこの半年で、その両方のチームを経験しました。 4〜6月はカイポケコネクトのチームで、小さな修正から始めてモブプログラミングで少しずつ機能開発に入り、帳票の一覧・出力機能をバックエンドからフロントエンドまで通して実装しました。7〜9月はカイポケクラウドのチームに移り、長く運用されてきたコードベースで、不具合修正の施策や画面のパフォーマンス改善を担当しました。9月は次の制度改正への対応準備に加えて、カイポケコネクトのチームの開発にも一部関わり、9月末からは本配属先としてカイポケコネクトのチームで活動しています。 この半年で印象に残ったこと 現場やユーザーに触れた 最初のカイポケコネクトのチームでは、入社1か月目からユーザーインタビューに参加し、現場の声を直接聞きました。入社直後の研修で介護業界の全体像を学んでいたので、業務の大まかな流れは追いながら聞くことができ、研修で学んだ制度が実際の業務で使われているのを感じました。 7月には、デイサービスでの事業所体験にも参加しています。その日は送迎に同行し、レクリエーションの補助をしながら、主に記録業務を手伝いました。印象に残ったのは、利用者さん一人ひとりの状況に合わせた運用があることです。たとえば送迎では、耳の不自由な方の場合はインターホンを鳴らさず、決まった時刻より前から玄関前で待っていました。まだ準備をしていないだろうと予想できる方へは先に声だけかけておき、ほかの方を迎えている間に支度をしてもらうといった工夫も見られました。 記録は、ご家族に渡す連絡帳のもとにもなり、ご家族とのコミュニケーションに欠かせないものです。ただ、ケアに追われると記録は後回しになり、数字では表しづらいけれど連絡帳に書きたい、利用者さんのちょっとした様子ほど残すのが難しいというお話も職員の方から聞きました。 一方で、ドメインの理解には今も苦戦しています。入社直後は、帳票の種類も、それに絡む制度も、ほとんどわかっていませんでした。リファインメントで何の話をしているのかわからず、「何を聞けばわかる状態になるのか」すらわからない時期もありました。カイポケクラウドのチームに移ってからも、次の制度改正に向けた勉強会で介護報酬の単位数計算に初めて取り組み、その複雑さを痛感しました。 ただ、研修や事業所体験など学ぶ機会は多く、知っていることは少しずつ増えています。9月に受けた業界団体の介護請求システムの入門講座では、すでに聞いたことのある内容も多く、ゆっくりではありますが学んできた知識が定着してきたと実感しました。 わからないことをチームに頼った カイポケコネクトのチームでは、入社直後から夕会でタスクと関係ない雑談や相談ができたので、チームに声をかけやすかったです。モブにも気軽に誘ってもらえ、はじめは質問すること自体にハードルを感じていた私も、回数を重ねるうちに慣れていきました。担当した機能は、ほぼモブで実装するところから始めて詰まったときだけ相談する形に移り、最後は1人で実装するという段階を踏ませてもらえたので、自分の手で作りきれました。 カイポケクラウドのチームでは、自分から方針を出して見てもらう、という頼り方へ変わりました。最初の施策はデータ取り込みの不具合の修正です。局所的なバグに見えていたものが、実は仕様上の考慮漏れでした。そこで一通り調べたうえで、根拠を添えて「この方針で直します」とチームに伝え、方針を見てもらってから実装を始めました。先に見てもらえていたので、その後は安心して手を動かせたと感じています。 8月に担当したのは、利用者さんの介護サービスの予定を事業所へ送るときの、送信対象を一覧で表示する画面が重いという問題の改善です。SQLを書き換えると別の箇所で全件を読みにいってしまうなど、すんなりとは進みませんでした。手元で再現しながら原因を詰め、変更が複雑だったので、最後はチームでモブレビューをして一緒に確認してもらいました。5分以上かかってタイムアウトしていた画面は、今は8秒ほどで表示されます。 社内のいろんな人と話した 入社してから、チーム外の人とも1on1を重ねてきました。最初に申し込むときは「何を話そう」「勝手に予定を入れていいのか」と緊張していましたが、話してみるとどの方も快く時間をくださいました。半年で話した相手は20人以上で、職種もさまざまです。 カスタマーサポートの方からはサポートの仕事の様子を、事業部側の方からは事業としての判断の考え方を聞きました。開発チームの中だけでは聞く機会の少ない話で、カイポケという組織やプロダクトを別の角度から見るきっかけになりました。 入社前に心配していたのは、フルリモートの環境では一緒に働く人の顔が見えにくく、コミュニケーションを取りにくいのではないかということです。5月の社外カンファレンスでのブース運営やオフラインのイベント、1on1などで言葉を交わすうちに、Slackのアイコンを見て顔が浮かぶ人も増えてきました。今はリモートでも特に苦労することなく働けていて、心配は杞憂でした。 自分の動き方を自分で決めた 7月にカイポケクラウドのチームに着任したときは、着任から4週目までの過ごし方や、施策担当に期待することを言葉にして共有してもらえました。期待されていることがわかっていたので、自分から動き方を提案しやすかったです。 実際に8月末には、9月の動き方を提案しました。示されていた選択肢は、8月末でカイポケコネクトのチームに移るか、9月までカイポケクラウドのチームに残るかの2つでした。ただ、制度改正は数年に一度しかなく、改正の中身が固まる前の段階から関われる時期は限られています。研修期間中のこのタイミングだからこそ、どのような改正になりうるかを見立てる経験ができると考えました。一方で、カイポケコネクトのチームでは新しい案件が始まるところで、そちらにも早くから関わりたいと思っていました。 そこで、カイポケクラウドのチームで制度改正への対応準備を主に担当しつつ、カイポケコネクトのチームの開発にもサブとして関わる案を、3つ目の選択肢として伝えました。提案は受け入れられ、9月は両方のチームで動く形になりました。 カイポケクラウドのチームで9月に取り組んだのは、次の制度改正に向けて、何に備える必要があるのかを洗い出すことです。その時点でわかっていた厚生労働省の発表や過去の似た制度改正を調べました。そのうえで小さいチームに分かれて、ユーザーの業務やカイポケにどのような影響があるのかを検討し、関係するメンバーに発表しました。並行して、カイポケコネクトのチームでは、開発に向けた業務の流れの整理や調査を担当しました。 2つのチームのことを同時に考えるのは大変でしたが、制度改正への備えを通じて、ドメインのもっと深いところまで学ぶことができました。何より、自分で提案して納得感のある状態で動けたことが良かったと感じています。 2つのチームの違い 同じカイポケの開発でも、2つのチームが向き合っている課題はかなり違いました。 カイポケコネクトのチームは、モダンな技術スタックで新しいプロダクトを作っていて、課題の探索から実装・提供までをチームで一貫して行っています。私が関わったのはデリバリーの側で、ドメイン知識をキャッチアップしながらスクラムで開発を進めました。 一方のカイポケクラウドのチームは、すでに多くのユーザーに使われているサービスを運用しています。制度改正への対応、長く運用されてきたシステムの制約、お客様からの問い合わせなど、チームの内外から課題が次々と持ち込まれます。それらを事業としての優先度と見比べながら、何にどこまで対応するかを決めていきます。私が担当したデータ取り込みの不具合修正や一覧画面の改善も、すでに使われているサービスだからこそ出てきた課題でした。 2つのチームを経験したことで、プロダクトがどう作られ、どう使われ続けているのかを、少し立体的に捉えられるようになったと感じています。 これから 今はカイポケコネクトのチームで、新しい案件に本格的に取り組んでいます。 カイポケクラウドのチームで学んだ、資料を読み解いて調べる力や、チームで不確実なものを形にしていく進め方を、今のチームでも使えると考えています。 半年の研修では、任された範囲の中では自分で考えて動けていたものの、その範囲は1つの機能や施策といった小さな単位で、チームとして動くというよりは個として動く場面のほうが多くありました。これからは本配属となったチームで、周りの人を巻き込みながらプロジェクトを牽引できるようになることが目標です。 おわりに 半年を振り返ると、リファインメントで何の話をしているのかもわからなかったところから、制度改正の資料を読んで議論に加われるところまでは来ました。 入社前に制度やドメインに詳しくなっておく必要はないと思います。私も、研修や事業所体験、チームでのモブを通して、入社してから学んできました。半年経った今、自らの成長を実感しながら働くことができています。 この記事が、エス・エム・エスに入ろうと思っている方の参考になれば幸いです。

はじめに さくらのナレッジ編集部の法林です。 2026年10月5日(月)にオンラインイベント「さくらの夕べ CoderDojoナイト」を開催しました。本記事ではこちらの模様をレポートします。 イベントの開催趣旨 Code […]

本ブログは 2025 年 7 月 11 日に公開された AWS Blog “ Proactive strategies for cyber resilience and business continuity on AWS ” を翻訳したものです。 Amazon Web Services (AWS) は、サイバーセキュリティインシデントや、技術的な障害、自然災害といった事業継続を脅かすイベントに備えて、ワークロードを復旧できるよう準備しておくことを組織に推奨しています。この記事では、公共部門の組織が AWS インフラストラクチャを使用して、クラウド上でレジリエントなシステムを運用するためのガイダンスと戦略を紹介します。AWS がお客様に推奨している内容は次のとおりです。 サイバーセキュリティと AWS アーキテクチャのベストプラクティスに関するフレームワークを使用する マルチアカウント環境を実装する AWS 環境とワークロードのデプロイに Infrastructure as Code (IaC) を使用する プライマリワークロードとは異なるアベイラビリティーゾーンまたは リージョン に復旧用アカウントを準備する すべてのアプリケーションコード、IaC コード、設定ファイル、その他の依存関係を復旧用アカウントに配置する 復旧用アカウントにデータをバックアップする戦略を定義する 復旧用アカウントで、ユニットテストとワークロード全体のテストを自動化する 確立されたフレームワークを使用する ランサムウェアなどのサイバーセキュリティインシデントが増加し続ける中、公共部門の組織は、サイバーセキュリティリスクをより適切に管理するためのガイダンスとして、 NIST Cybersecurity Framework (CSF) 2.0 などのフレームワークを参考にしています。このフレームワークは 米国国立標準技術研究所 (NIST) が策定したものです。CSF はサイバーセキュリティの成果を機能 (統治、識別、防御、検知、対応、復旧) ごとに整理していますが、NIST はその成果を達成する具体的な方法までは規定していません。 より具体的なガイダンスについては、「 AWS Blueprint for Ransomware Defense 」などのリソースを参照してください。このリソースでは、具体的な AWS サービスを CSF の各機能にマッピングしています。AWS でのアーキテクチャ設計のベストプラクティスを深く理解するには、 AWS Well-Architected フレームワーク が役立ちます。このフレームワークは 6 つの柱に沿ってベストプラクティスを詳しく解説しており、クラウドアーキテクトが AWS 責任共有モデル に従って、さまざまなアプリケーションやワークロード向けに、安全で高性能、レジリエントかつ効率的なインフラストラクチャを構築できるよう支援します。さらに、これらのフレームワークを補完するのが AWS Security Reference Architecture (AWS SRA) です。AWS SRA は、AWS の推奨プラクティスに沿って AWS のセキュリティサービスを設計、実装、管理するのに役立ちます。この記事では、CSF と AWS Well-Architected を橋渡しする形で、サイバーセキュリティイベントや災害からの復旧に備えるための重要なパターンを紹介します。 AWS でマルチアカウント戦略を実装する AWS では、ベストプラクティスとして、マルチアカウント戦略に基づいてクラウド環境を構築することを推奨しています。このようにマルチアカウント戦略に基づいて構築した環境は ランディングゾーン とも呼ばれます。 AWS Organizations を AWS Control Tower または Landing Zone Accelerator on AWS と組み合わせて使用すると、管理と自動化が容易な環境を構築できます。複数の AWS アカウントを使用すると、アプリケーションとデータを分離して管理しやすくなり、環境内での意図しない横方向の移動 (ラテラルムーブメント) を排除できます。 マルチアカウント戦略の一環として、AWS は AWS IAM Identity Center を使用してアイデンティティを一元管理することを推奨しています。AWS 外部の ID プロバイダーを IAM Identity Center と統合することも可能です。ただし、復旧時にはルート認証情報を使用しなければならない場合があります。 AWS では、AWS アカウントへのルートアクセスは必要な場合にのみ使用することを推奨しています 。アカウントの乗っ取りや不正アクセスを防ぐために、ルート認証情報は適切に保護する必要があります。AWS は 2024 年 11 月に、ブログ記事「 AWS Organizations を使用するお客様のためのルートアクセスの一元管理 」で、ルート認証情報を一元管理するための新機能を発表しました。ルート認証情報を一元管理することで、長期間有効なルート認証情報を削除し、認証情報が意図せず、または不正にリカバリされることを防止できるため、AWS 環境全体のセキュリティポスチャを強化できます。 自動化によって AWS インフラストラクチャを構築する AWS は、DevSecOps の重要な原則として、すべての AWS インフラストラクチャを IaC でデプロイすることを推奨しています。IaC を使用すると、インフラストラクチャを迅速に反復改善できるほか、一貫性と再現性の向上、設定ミスの削減、バージョン管理も実現できます。復旧の観点で特に重要なのは、IaC がインフラストラクチャのドキュメントとしても機能することです。IaC は、事業継続を脅かすイベントからの復旧と、それに備えたテストを迅速化します。これにより、新しい AWS アカウントや AWS リージョンにインフラストラクチャをすばやくデプロイできます。 AWS のサービスは IaC を前提に設計されており、組織のニーズに合わせてさまざまな IaC ツール から選択できます。AWS は、 AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの選択肢を提供しています。AWS CloudFormation ではテンプレートを使用してインフラストラクチャを定義でき、AWS CDK では使い慣れたプログラミング言語でクラウドリソースを定義できます。また、AWS CloudFormation では 既存のインフラストラクチャからスタックを作成 することもできるため、IaC への移行が容易になります。アプリケーションレベルでは、 AWS サーバーレスアプリケーションモデル (AWS SAM) を利用できます。AWS SAM は、IaC を使用してサーバーレスアプリケーションを構築するためのオープンソースフレームワークです。AWS は HashiCorp Terraform もサポートしています。HashiCorp Terraform は、複数のクラウドサービスプロバイダーにまたがるリソースとオンプレミスのリソースの両方を、人間が読める形式の設定ファイルで定義できる IaC ツールです。この設定ファイルは、バージョン管理、再利用、共有が可能です。 どのツールを使用する場合でも、IaC はリソース名、AWS リージョン、IP 範囲などを変数化して開発できるため、AWS アカウントやリージョンをまたいでコードを簡単に再利用でき、復旧プロセスを迅速化できます。IaC コードは、GitLab などのソースコードリポジトリに保存してください。より迅速に復旧できるよう、独自の DevSecOps パイプラインを構築することも、AWS 規範ガイダンスに従って標準化することもできます。 DevOps Pipeline Accelerator (DPA) は、前述のツールを使用して、アプリケーションやインフラストラクチャをデプロイするための 継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン全体の構築に役立つテンプレート群で構成されたソリューションです。IaC の詳細については、 Infrastructure as Code のホワイトペーパー を参照してください。 復旧先を準備する アイデンティティの侵害などのサイバーセキュリティインシデントに備えて、AWS は前述のマルチアカウント戦略を活用し、復旧用のアカウントを個別に用意することを推奨しています。AWS アカウント内のアイデンティティはロールに基づいて管理すべきですが、悪意のある攻撃者がルートアクセスを取得しているか、自身の権限を昇格させることができる場合は、同じアカウント内のバックアップも侵害される可能性があるためです。 技術的な障害や自然災害への対策として、可能性は低いものの、 AWS アベイラビリティーゾーン が利用できなくなるシナリオからワークロードを保護できます。リージョン内でアベイラビリティーゾーン単位の復旧を行う場合は、復旧用のアベイラビリティーゾーンが、ワークロードのデプロイ先とは別のゾーンであることを確認してください。そのためには、アカウント間で一貫したアベイラビリティーゾーン ID (AZ ID) を使用します。 AWS は、アカウントごとに AZ の名前をランダムに割り当てます 。別のアカウントのアベイラビリティーゾーンを復旧に効果的に使用するには、リージョン内の すべてのアカウントで一貫した AZ ID を使用 してください。この方法により、同じリージョン内の 2 つ以上のアベイラビリティーゾーンにワークロードを分散デプロイしてレジリエンスを確保しつつ、復旧用には別のアベイラビリティーゾーンを使用できます。一貫した AZ ID を使用すれば、復旧用のアベイラビリティーゾーンを、すべてのワークロードのデプロイ先とは確実に異なるゾーンにできます。 訳注: 2025 年 11 月以降に作成されたアカウントでは、従来はアカウントごとに AZ 名の対応がランダムだったリージョンでも、すべてのアカウントで同じ AZ 名が同じ AZ を指します。それより前に作成されたアカウントでは、従来どおり AZ 名がアカウントごとに個別に対応付けられているため、アカウント間で AZ を揃えるには引き続き AZ ID を使用します。参照: AZ IDs – AWS Regions and Availability Zones 次の図は、AZ ID を使用したワークロードアカウントと復旧用アカウントのアーキテクチャを示しています。 図 1. アベイラビリティーゾーン ID を使用したワークロードアカウントと復旧用アカウントの例 より広範囲に及ぶ技術的な障害や自然災害に対するレジリエンスを確保するには、マルチリージョンでの復旧を選択することもできます。AWS は、可能であれば、復旧用アカウントに別のリージョンを使用することを検討するよう推奨しています。例えば、米国東部 (バージニア北部) リージョン ( us-east-1 ) をメインに、米国東部 (オハイオ) リージョン ( us-east-2 ) をバックアップ先にする構成です。少なくとも、データは別のリージョンにバックアップすることを AWS は推奨しています。クロスリージョンのバックアップ先を使用する場合、別のアカウントでバックアップデータを復号できるよう、 AWS Key Management Service (AWS KMS) を使用した暗号化キーの戦略を検討する必要があります。 なお、リージョン間のデータ転送料金はアベイラビリティーゾーン間よりも高くなる可能性があります。この点も、バックアップ先の戦略全体を検討する際に考慮してください。 バックアップ戦略を定義し、自動テストを実装する AWS は、クラウドベースのソリューションに合わせてバックアップ戦略を策定することを推奨しています。前述のとおり復旧先を準備したら、 AWS Backup を使用してワークロードデータを復旧用アカウントにバックアップできます。AWS Backup は、IaC、インフラストラクチャの設定データ、アプリケーションコード、アプリケーションの設定を復旧先に保存する用途にも使用できます。ほとんどのシナリオでは、ワークロードの復元にこれらすべての種類のデータが必要になります。クラウドベースのコードリポジトリを使用している場合は、十分なバックアップ機能がそのソリューションに既に備わっている可能性があります。 バックアップしたデータが実際に使用できるかを検証するために、AWS は復旧用アカウントで自動テストを実装することを推奨しています。例えば、バックアップの完了後に実行され、バックアップを正しく読み取れることを確認する自動プロセスを実装すると、ランサムウェアなどの脅威に対する効果的な緩和策になります。こうした攻撃への対策をさらに強化するために、バックアップしたすべてのコンポーネントについて複数のバージョンを保持し、必要に応じて古いバージョンのバックアップを復元できるようにしておくこともできます。また、バックアップ戦略の一環として、 AWS Backup Vault Lock などの機能を使用したイミュータブルなバックアップの採用を検討するのもよいでしょう。 バックアップと IaC の戦略の一環として、ワークロードに必要なコンポーネントが復旧先に保存されていることを確認してください。対象には、IaC コード、インフラストラクチャの設定データ、 Amazon マシンイメージ (AMI)、アプリケーションコード、アプリケーションの設定が含まれます。このプロセスは、DevSecOps と IaC の戦略全体に組み込む必要があります。DevSecOps パイプラインで変更が行われたときに、これらすべてのコンポーネントのバックアップをトリガーする自動プロセスを実装すれば、復旧用アカウントのバックアップを常に最新の状態に保つことができます。パイプラインの変更が頻繁に発生するシステムでは、毎日など定期的に実行される自動バックアッププロセスを選択することもできます。 復旧用アカウントの準備、IaC の実装、バックアップ戦略の確立が完了したら、復旧用アカウントでワークロード全体をテストすることを AWS は推奨しています。復旧用アカウント内の IaC コードとバックアップを使用して、そのアカウントでワークロード全体を定期的に構築してください。多くの場合、既存のコンポーネントテスト、統合テスト、ユーザー受け入れテストのスクリプトを、定期的な事業継続訓練に活用できます。このようなテストによって復旧機能の有効性を検証でき、事業継続を脅かすイベントが発生した場合にワークロードを復旧できることを確認できます。 まとめ この記事で紹介したベストプラクティスに従うことで、公共部門の組織は AWS の機能を活用して、事業継続を脅かすイベントからの復旧に備えることができます。さらに詳しいガイダンスについては、AWS アカウントチームとソリューションアーキテクトにお問い合わせください。 Devin Gordon Devin は Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、米国連邦政府の文民機関を支援しています。AWS ではセキュリティを専門としており、お客様が新興テクノロジーを活用しながら安全な環境を実装できるよう支援することに情熱を注いでいます。旅行が好きで、特にスキューバダイビングやハイキングなどのアウトドア活動を楽しんでいます。 Henrik Balle Henrik は AWS のプリンシパルソリューションアーキテクトとして、米国の公共部門を支援しています。機械学習から大規模環境でのセキュリティとガバナンスまで、幅広いトピックについてお客様と緊密に連携しています。余暇にはロードバイクやオートバイを楽しむほか、自宅のリフォームに次々と取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。